From 8de4c860c8b36df9273d804f0e10c95296ea2126 Mon Sep 17 00:00:00 2001
From: Sean Whitton <spwhitton@spwhitton.name>
Date: Wed, 29 May 2024 10:59:06 +0100
Subject: [PATCH] Import git-annex_10.20240430.orig.tar.xz

[dgit import orig git-annex_10.20240430.orig.tar.xz]
---
 .appveyor.yml                                 |  141 +
 .codespellrc                                  |    7 +
 .ghci                                         |    3 +
 .gitattributes                                |    1 +
 .gitignore                                    |   40 +
 .mailmap                                      |   29 +
 Annex.hs                                      |  471 +
 Annex/Action.hs                               |  105 +
 Annex/AdjustedBranch.hs                       |  680 ++
 Annex/AdjustedBranch/Merge.hs                 |  167 +
 Annex/AdjustedBranch/Name.hs                  |   99 +
 Annex/AutoMerge.hs                            |  391 +
 Annex/BloomFilter.hs                          |   54 +
 Annex/Branch.hs                               | 1062 ++
 Annex/Branch/Transitions.hs                   |  108 +
 Annex/BranchState.hs                          |  134 +
 Annex/CatFile.hs                              |  221 +
 Annex/ChangedRefs.hs                          |  111 +
 Annex/CheckAttr.hs                            |   74 +
 Annex/CheckIgnore.hs                          |   64 +
 Annex/Common.hs                               |   16 +
 Annex/Concurrent.hs                           |  113 +
 Annex/Concurrent/Utility.hs                   |   31 +
 Annex/Content.hs                              |  949 ++
 Annex/Content/LowLevel.hs                     |  141 +
 Annex/Content/PointerFile.hs                  |   71 +
 Annex/Content/Presence.hs                     |  215 +
 Annex/Content/Presence/LowLevel.hs            |   36 +
 Annex/CopyFile.hs                             |  179 +
 Annex/CurrentBranch.hs                        |   41 +
 Annex/Debug.hs                                |   35 +
 Annex/Debug/Utility.hs                        |   32 +
 Annex/Difference.hs                           |   60 +
 Annex/DirHashes.hs                            |   90 +
 Annex/Drop.hs                                 |  131 +
 Annex/Environment.hs                          |   73 +
 Annex/Export.hs                               |   72 +
 Annex/ExternalAddonProcess.hs                 |  100 +
 Annex/FileMatcher.hs                          |  278 +
 Annex/Fixup.hs                                |  155 +
 Annex/GitOverlay.hs                           |  124 +
 Annex/HashObject.hs                           |   66 +
 Annex/Hook.hs                                 |   88 +
 Annex/Import.hs                               | 1105 ++
 Annex/Ingest.hs                               |  425 +
 Annex/Init.hs                                 |  466 +
 Annex/InodeSentinal.hs                        |  112 +
 Annex/Journal.hs                              |  294 +
 Annex/Link.hs                                 |  476 +
 Annex/Locations.hs                            |  727 ++
 Annex/LockFile.hs                             |  113 +
 Annex/LockPool.hs                             |   17 +
 Annex/LockPool/PosixOrPid.hs                  |   93 +
 Annex/Magic.hs                                |   74 +
 Annex/MetaData.hs                             |  121 +
 Annex/MetaData/StandardFields.hs              |   67 +
 Annex/Multicast.hs                            |   44 +
 Annex/Notification.hs                         |  108 +
 Annex/NumCopies.hs                            |  333 +
 Annex/Path.hs                                 |  125 +
 Annex/Perms.hs                                |  374 +
 Annex/PidLock.hs                              |  131 +
 Annex/Queue.hs                                |   97 +
 Annex/RemoteTrackingBranch.hs                 |   96 +
 Annex/ReplaceFile.hs                          |   87 +
 Annex/SpecialRemote.hs                        |  135 +
 Annex/SpecialRemote/Config.hs                 |  301 +
 Annex/Ssh.hs                                  |  480 +
 Annex/StallDetection.hs                       |  154 +
 Annex/TaggedPush.hs                           |   68 +
 Annex/Tmp.hs                                  |   74 +
 Annex/Transfer.hs                             |  443 +
 Annex/TransferrerPool.hs                      |  300 +
 Annex/UUID.hs                                 |  123 +
 Annex/UntrustedFilePath.hs                    |   77 +
 Annex/UpdateInstead.hs                        |   23 +
 Annex/Url.hs                                  |  190 +
 Annex/VariantFile.hs                          |   45 +
 Annex/VectorClock.hs                          |   83 +
 Annex/VectorClock/Utility.hs                  |   33 +
 Annex/Verify.hs                               |  352 +
 Annex/Version.hs                              |   68 +
 Annex/View.hs                                 |  636 ++
 Annex/View/ViewedFile.hs                      |  112 +
 Annex/Wanted.hs                               |   75 +
 Annex/WorkTree.hs                             |   60 +
 Annex/WorkerPool.hs                           |  126 +
 Annex/YoutubeDl.hs                            |  410 +
 Assistant.hs                                  |  194 +
 Assistant/Alert.hs                            |  460 +
 Assistant/Alert/Utility.hs                    |  129 +
 Assistant/BranchChange.hs                     |   19 +
 Assistant/Changes.hs                          |   47 +
 Assistant/Commits.hs                          |   32 +
 Assistant/Common.hs                           |   14 +
 Assistant/CredPairCache.hs                    |   53 +
 Assistant/DaemonStatus.hs                     |  273 +
 Assistant/DeleteRemote.hs                     |   89 +
 Assistant/Drop.hs                             |   30 +
 Assistant/Fsck.hs                             |   50 +
 Assistant/Gpg.hs                              |   38 +
 Assistant/Install.hs                          |  175 +
 Assistant/Install/AutoStart.hs                |   41 +
 Assistant/Install/Menu.hs                     |   54 +
 Assistant/MakeRemote.hs                       |  184 +
 Assistant/MakeRepo.hs                         |   98 +
 Assistant/Monad.hs                            |  144 +
 Assistant/NamedThread.hs                      |   99 +
 Assistant/Pairing.hs                          |   97 +
 Assistant/Pairing/MakeRemote.hs               |   98 +
 Assistant/Pairing/Network.hs                  |  132 +
 Assistant/Pushes.hs                           |   37 +
 Assistant/RemoteControl.hs                    |   21 +
 Assistant/Repair.hs                           |  162 +
 Assistant/RepoProblem.hs                      |   34 +
 Assistant/Restart.hs                          |  119 +
 Assistant/ScanRemotes.hs                      |   41 +
 Assistant/Ssh.hs                              |  412 +
 Assistant/Sync.hs                             |  287 +
 Assistant/Threads/Committer.hs                |  505 +
 Assistant/Threads/ConfigMonitor.hs            |   95 +
 Assistant/Threads/Cronner.hs                  |  225 +
 Assistant/Threads/DaemonStatus.hs             |   29 +
 Assistant/Threads/Exporter.hs                 |   80 +
 Assistant/Threads/Glacier.hs                  |   44 +
 Assistant/Threads/Merger.hs                   |  131 +
 Assistant/Threads/MountWatcher.hs             |  182 +
 Assistant/Threads/NetWatcher.hs               |  202 +
 Assistant/Threads/PairListener.hs             |  156 +
 Assistant/Threads/ProblemFixer.hs             |   73 +
 Assistant/Threads/Pusher.hs                   |   50 +
 Assistant/Threads/RemoteControl.hs            |  128 +
 Assistant/Threads/SanityChecker.hs            |  274 +
 Assistant/Threads/TransferPoller.hs           |   56 +
 Assistant/Threads/TransferScanner.hs          |  196 +
 Assistant/Threads/TransferWatcher.hs          |  108 +
 Assistant/Threads/Transferrer.hs              |   27 +
 Assistant/Threads/UpgradeWatcher.hs           |  109 +
 Assistant/Threads/Upgrader.hs                 |   85 +
 Assistant/Threads/Watcher.hs                  |  376 +
 Assistant/Threads/WebApp.hs                   |  136 +
 Assistant/TransferQueue.hs                    |  236 +
 Assistant/TransferSlots.hs                    |  321 +
 Assistant/Types/Alert.hs                      |   79 +
 Assistant/Types/BranchChange.hs               |   20 +
 Assistant/Types/Changes.hs                    |  101 +
 Assistant/Types/Commits.hs                    |   19 +
 Assistant/Types/CredPairCache.hs              |   18 +
 Assistant/Types/DaemonStatus.hs               |  119 +
 Assistant/Types/NamedThread.hs                |   21 +
 Assistant/Types/Pushes.hs                     |   24 +
 Assistant/Types/RemoteControl.hs              |   16 +
 Assistant/Types/RepoProblem.hs                |   28 +
 Assistant/Types/ScanRemotes.hs                |   25 +
 Assistant/Types/ThreadName.hs                 |   14 +
 Assistant/Types/ThreadedMonad.hs              |   40 +
 Assistant/Types/TransferQueue.hs              |   29 +
 Assistant/Types/TransferSlots.hs              |   34 +
 Assistant/Types/UrlRenderer.hs                |   26 +
 Assistant/Unused.hs                           |   85 +
 Assistant/Upgrade.hs                          |  377 +
 Assistant/WebApp.hs                           |   74 +
 Assistant/WebApp/Common.hs                    |   17 +
 Assistant/WebApp/Configurators.hs             |   44 +
 Assistant/WebApp/Configurators/AWS.hs         |  213 +
 Assistant/WebApp/Configurators/Delete.hs      |  121 +
 Assistant/WebApp/Configurators/Edit.hs        |  329 +
 Assistant/WebApp/Configurators/Fsck.hs        |  196 +
 Assistant/WebApp/Configurators/IA.hs          |  194 +
 Assistant/WebApp/Configurators/Local.hs       |  433 +
 Assistant/WebApp/Configurators/Pairing.hs     |  321 +
 Assistant/WebApp/Configurators/Preferences.hs |  114 +
 Assistant/WebApp/Configurators/Ssh.hs         |  674 ++
 Assistant/WebApp/Configurators/Unused.hs      |   80 +
 Assistant/WebApp/Configurators/Upgrade.hs     |   37 +
 Assistant/WebApp/Configurators/WebDAV.hs      |  100 +
 Assistant/WebApp/Control.hs                   |   78 +
 Assistant/WebApp/DashBoard.hs                 |  179 +
 Assistant/WebApp/Documentation.hs             |   42 +
 Assistant/WebApp/Form.hs                      |   94 +
 Assistant/WebApp/Gpg.hs                       |  114 +
 Assistant/WebApp/MakeRemote.hs                |   46 +
 Assistant/WebApp/Notifications.hs             |   86 +
 Assistant/WebApp/OtherRepos.hs                |   39 +
 Assistant/WebApp/Page.hs                      |   75 +
 Assistant/WebApp/Pairing.hs                   |   79 +
 Assistant/WebApp/Repair.hs                    |   35 +
 Assistant/WebApp/RepoId.hs                    |   40 +
 Assistant/WebApp/RepoList.hs                  |  266 +
 Assistant/WebApp/SideBar.hs                   |  109 +
 Assistant/WebApp/Types.hs                     |  197 +
 Assistant/WebApp/routes                       |  115 +
 Author.hs                                     |   35 +
 Backend.hs                                    |  121 +
 Backend/External.hs                           |  378 +
 Backend/Hash.hs                               |  310 +
 Backend/URL.hs                                |   43 +
 Backend/Utilities.hs                          |   84 +
 Backend/VURL.hs                               |  102 +
 Backend/VURL/Utilities.hs                     |   57 +
 Backend/Variety.hs                            |   39 +
 Backend/WORM.hs                               |   70 +
 Benchmark.hs                                  |   47 +
 Build/BuildVersion.hs                         |   13 +
 Build/BundledPrograms.hs                      |   95 +
 Build/Configure.hs                            |  106 +
 Build/DesktopFile.hs                          |   89 +
 Build/DistributionUpdate.hs                   |  261 +
 Build/InstallDesktopFile.hs                   |   19 +
 Build/LinuxMkLibs.hs                          |  200 +
 Build/MakeMans.hs                             |   15 +
 Build/Mans.hs                                 |   65 +
 Build/NullSoftInstaller.hs                    |  224 +
 Build/OSXMkLibs.hs                            |  206 +
 Build/Standalone.hs                           |  240 +
 Build/TestConfig.hs                           |  130 +
 Build/Version.hs                              |   74 +
 Build/collect-ghc-options.sh                  |   12 +
 Build/mdwn2man                                |   58 +
 BuildFlags.hs                                 |   96 +
 BuildInfo.hs                                  |   16 +
 CHANGELOG                                     | 8332 +++++++++++++++
 COPYRIGHT                                     |  840 ++
 CmdLine.hs                                    |  199 +
 CmdLine/Action.hs                             |  348 +
 CmdLine/AnnexSetter.hs                        |   36 +
 CmdLine/Batch.hs                              |  227 +
 CmdLine/GitAnnex.hs                           |  282 +
 CmdLine/GitAnnex/Options.hs                   |  582 ++
 CmdLine/GitAnnexShell.hs                      |  171 +
 CmdLine/GitAnnexShell/Checks.hs               |   84 +
 CmdLine/GitAnnexShell/Fields.hs               |   33 +
 CmdLine/GitRemoteTorAnnex.hs                  |   67 +
 CmdLine/Option.hs                             |   95 +
 CmdLine/Seek.hs                               |  633 ++
 CmdLine/Usage.hs                              |  108 +
 Command.hs                                    |  152 +
 Command/Add.hs                                |  271 +
 Command/AddUnused.hs                          |   43 +
 Command/AddUrl.hs                             |  610 ++
 Command/Adjust.hs                             |   63 +
 Command/Assist.hs                             |   42 +
 Command/Assistant.hs                          |  140 +
 Command/Benchmark.hs                          |   58 +
 Command/CalcKey.hs                            |   35 +
 Command/CheckPresentKey.hs                    |   84 +
 Command/Config.hs                             |  216 +
 Command/ConfigList.hs                         |   53 +
 Command/ConfigRemote.hs                       |   64 +
 Command/ContentLocation.hs                    |   32 +
 Command/Copy.hs                               |   97 +
 Command/Dead.hs                               |   44 +
 Command/Describe.hs                           |   36 +
 Command/DiffDriver.hs                         |  149 +
 Command/Direct.hs                             |   21 +
 Command/Drop.hs                               |  259 +
 Command/DropKey.hs                            |   59 +
 Command/DropUnused.hs                         |   82 +
 Command/EnableRemote.hs                       |  159 +
 Command/EnableTor.hs                          |  152 +
 Command/ExamineKey.hs                         |   83 +
 Command/Expire.hs                             |  117 +
 Command/Export.hs                             |  554 +
 Command/FilterBranch.hs                       |  195 +
 Command/FilterProcess.hs                      |   89 +
 Command/Find.hs                               |  128 +
 Command/FindKeys.hs                           |   49 +
 Command/FindRef.hs                            |   27 +
 Command/Fix.hs                                |  106 +
 Command/Forget.hs                             |   59 +
 Command/FromKey.hs                            |  142 +
 Command/Fsck.hs                               |  756 ++
 Command/FuzzTest.hs                           |  277 +
 Command/GCryptSetup.hs                        |   39 +
 Command/Get.hs                                |  122 +
 Command/Group.hs                              |   46 +
 Command/GroupWanted.hs                        |   32 +
 Command/Help.hs                               |   71 +
 Command/Import.hs                             |  403 +
 Command/ImportFeed.hs                         |  655 ++
 Command/InAnnex.hs                            |   29 +
 Command/Indirect.hs                           |   21 +
 Command/Info.hs                               |  829 ++
 Command/Init.hs                               |   90 +
 Command/InitRemote.hs                         |  171 +
 Command/Inprogress.hs                         |   64 +
 Command/List.hs                               |  109 +
 Command/Lock.hs                               |  104 +
 Command/Log.hs                                |  529 +
 Command/LookupKey.hs                          |   62 +
 Command/Map.hs                                |  289 +
 Command/MatchExpression.hs                    |   98 +
 Command/Merge.hs                              |   68 +
 Command/MetaData.hs                           |  183 +
 Command/Migrate.hs                            |  207 +
 Command/MinCopies.hs                          |   39 +
 Command/Mirror.hs                             |   90 +
 Command/Move.hs                               |  600 ++
 Command/Multicast.hs                          |  256 +
 Command/NotifyChanges.hs                      |   44 +
 Command/NumCopies.hs                          |   53 +
 Command/OldKeys.hs                            |  104 +
 Command/P2P.hs                                |  314 +
 Command/P2PStdIO.hs                           |   50 +
 Command/PostReceive.hs                        |   58 +
 Command/PreCommit.hs                          |   88 +
 Command/Proxy.hs                              |   23 +
 Command/Pull.hs                               |   17 +
 Command/Push.hs                               |   17 +
 Command/ReKey.hs                              |  154 +
 Command/ReadPresentKey.hs                     |   31 +
 Command/RecvKey.hs                            |   42 +
 Command/RegisterUrl.hs                        |   90 +
 Command/Reinit.hs                             |   41 +
 Command/Reinject.hs                           |  137 +
 Command/RemoteDaemon.hs                       |   38 +
 Command/RenameRemote.hs                       |   59 +
 Command/Repair.hs                             |   87 +
 Command/Required.hs                           |   17 +
 Command/ReregisterUrl.hs                      |   79 +
 Command/ResolveMerge.hs                       |   41 +
 Command/Restage.hs                            |   25 +
 Command/RmUrl.hs                              |   68 +
 Command/Satisfy.hs                            |   17 +
 Command/Schedule.hs                           |   53 +
 Command/Semitrust.hs                          |   21 +
 Command/SendKey.hs                            |   64 +
 Command/SetKey.hs                             |   52 +
 Command/SetPresentKey.hs                      |   58 +
 Command/Smudge.hs                             |  335 +
 Command/Status.hs                             |   71 +
 Command/Sync.hs                               | 1160 +++
 Command/Test.hs                               |   29 +
 Command/TestRemote.hs                         |  460 +
 Command/TransferKey.hs                        |   76 +
 Command/TransferKeys.hs                       |  142 +
 Command/Transferrer.hs                        |  139 +
 Command/Trust.hs                              |   54 +
 Command/Unannex.hs                            |  103 +
 Command/Undo.hs                               |   90 +
 Command/Ungroup.hs                            |   35 +
 Command/Uninit.hs                             |  177 +
 Command/Unlock.hs                             |   72 +
 Command/UnregisterUrl.hs                      |   38 +
 Command/Untrust.hs                            |   20 +
 Command/Unused.hs                             |  345 +
 Command/Upgrade.hs                            |   51 +
 Command/VAdd.hs                               |   40 +
 Command/VCycle.hs                             |   42 +
 Command/VFilter.hs                            |   31 +
 Command/VPop.hs                               |   53 +
 Command/Version.hs                            |   83 +
 Command/Vicfg.hs                              |  348 +
 Command/View.hs                               |  133 +
 Command/Wanted.hs                             |   59 +
 Command/Watch.hs                              |   35 +
 Command/WebApp.hs                             |  252 +
 Command/WhereUsed.hs                          |  170 +
 Command/Whereis.hs                            |  167 +
 Common.hs                                     |   36 +
 Config.hs                                     |  101 +
 Config/Cost.hs                                |   82 +
 Config/DynamicConfig.hs                       |   47 +
 Config/Files.hs                               |   36 +
 Config/Files/AutoStart.hs                     |   49 +
 Config/GitConfig.hs                           |   41 +
 Config/Smudge.hs                              |   82 +
 Creds.hs                                      |  241 +
 Crypto.hs                                     |  306 +
 Database/Benchmark.hs                         |  120 +
 Database/ContentIdentifier.hs                 |  194 +
 Database/Export.hs                            |  330 +
 Database/Fsck.hs                              |  111 +
 Database/Handle.hs                            |  338 +
 Database/ImportFeed.hs                        |  211 +
 Database/Init.hs                              |   64 +
 Database/Keys.hs                              |  517 +
 Database/Keys/Handle.hs                       |   69 +
 Database/Keys/SQL.hs                          |  160 +
 Database/Keys/Tables.hs                       |   38 +
 Database/Queue.hs                             |  113 +
 Database/RawFilePath.hs                       |   95 +
 Database/Types.hs                             |  131 +
 Database/Utility.hs                           |   27 +
 Git.hs                                        |  185 +
 Git/AutoCorrect.hs                            |   73 +
 Git/Branch.hs                                 |  270 +
 Git/BuildVersion.hs                           |   21 +
 Git/CatFile.hs                                |  422 +
 Git/CheckAttr.hs                              |  101 +
 Git/CheckIgnore.hs                            |   71 +
 Git/Command.hs                                |  149 +
 Git/Command/Batch.hs                          |   19 +
 Git/Config.hs                                 |  341 +
 Git/ConfigTypes.hs                            |   53 +
 Git/Construct.hs                              |  294 +
 Git/Credential.hs                             |  126 +
 Git/CurrentRepo.hs                            |   96 +
 Git/DiffTree.hs                               |  138 +
 Git/DiffTreeItem.hs                           |   25 +
 Git/Env.hs                                    |   52 +
 Git/FileMode.hs                               |   21 +
 Git/FilePath.hs                               |   96 +
 Git/FilterProcess.hs                          |  170 +
 Git/Fsck.hs                                   |  172 +
 Git/GCrypt.hs                                 |  133 +
 Git/HashObject.hs                             |   98 +
 Git/History.hs                                |  112 +
 Git/Hook.hs                                   |  115 +
 Git/Index.hs                                  |   64 +
 Git/LockFile.hs                               |   80 +
 Git/Log.hs                                    |  115 +
 Git/LsFiles.hs                                |  376 +
 Git/LsTree.hs                                 |  155 +
 Git/Merge.hs                                  |   78 +
 Git/Objects.hs                                |   55 +
 Git/PktLine.hs                                |  154 +
 Git/Queue.hs                                  |  267 +
 Git/Quote.hs                                  |  122 +
 Git/Ref.hs                                    |  220 +
 Git/RefLog.hs                                 |   33 +
 Git/Remote.hs                                 |  138 +
 Git/Remote/Remove.hs                          |   22 +
 Git/Repair.hs                                 |  657 ++
 Git/Sha.hs                                    |   74 +
 Git/Ssh.hs                                    |   72 +
 Git/Status.hs                                 |   79 +
 Git/Tree.hs                                   |  465 +
 Git/Types.hs                                  |  199 +
 Git/UnionMerge.hs                             |  116 +
 Git/UpdateIndex.hs                            |  169 +
 Git/Url.hs                                    |   72 +
 Git/Version.hs                                |   32 +
 Key.hs                                        |  108 +
 Limit.hs                                      |  676 ++
 Limit/Wanted.hs                               |   55 +
 Logs.hs                                       |  291 +
 Logs/Activity.hs                              |   61 +
 Logs/AdjustedBranchUpdate.hs                  |   84 +
 Logs/Chunk.hs                                 |   57 +
 Logs/Chunk/Pure.hs                            |   62 +
 Logs/Config.hs                                |   73 +
 Logs/ContentIdentifier.hs                     |   54 +
 Logs/ContentIdentifier/Pure.hs                |   75 +
 Logs/Difference.hs                            |   42 +
 Logs/Difference/Pure.hs                       |   27 +
 Logs/EquivilantKeys.hs                        |   31 +
 Logs/Export.hs                                |  140 +
 Logs/Export/Pure.hs                           |  119 +
 Logs/File.hs                                  |  192 +
 Logs/FsckResults.hs                           |   63 +
 Logs/Group.hs                                 |   99 +
 Logs/Import.hs                                |   37 +
 Logs/Line.hs                                  |   38 +
 Logs/Location.hs                              |  224 +
 Logs/MapLog.hs                                |  128 +
 Logs/MetaData.hs                              |  164 +
 Logs/MetaData/Pure.hs                         |  111 +
 Logs/Migrate.hs                               |  203 +
 Logs/Multicast.hs                             |   43 +
 Logs/NumCopies.hs                             |   66 +
 Logs/PreferredContent.hs                      |  206 +
 Logs/PreferredContent/Raw.hs                  |   84 +
 Logs/Presence.hs                              |   86 +
 Logs/Presence/Pure.hs                         |  144 +
 Logs/Remote.hs                                |   56 +
 Logs/Remote/Pure.hs                           |  108 +
 Logs/RemoteState.hs                           |   49 +
 Logs/Restage.hs                               |   96 +
 Logs/Schedule.hs                              |   74 +
 Logs/SingleValue.hs                           |   42 +
 Logs/SingleValue/Pure.hs                      |   60 +
 Logs/Smudge.hs                                |   46 +
 Logs/Transfer.hs                              |  343 +
 Logs/Transitions.hs                           |  112 +
 Logs/Trust.hs                                 |   86 +
 Logs/Trust/Basic.hs                           |   36 +
 Logs/Trust/Pure.hs                            |   52 +
 Logs/UUID.hs                                  |   72 +
 Logs/UUIDBased.hs                             |   94 +
 Logs/Unused.hs                                |  112 +
 Logs/Upgrade.hs                               |   53 +
 Logs/View.hs                                  |  160 +
 Logs/Web.hs                                   |  139 +
 Makefile                                      |  239 +
 Messages.hs                                   |  366 +
 Messages/Concurrent.hs                        |  138 +
 Messages/Internal.hs                          |  118 +
 Messages/JSON.hs                              |  256 +
 Messages/Progress.hs                          |  225 +
 Messages/Serialized.hs                        |  111 +
 NEWS                                          |  232 +
 P2P/Address.hs                                |   98 +
 P2P/Annex.hs                                  |  269 +
 P2P/Auth.hs                                   |   66 +
 P2P/IO.hs                                     |  394 +
 P2P/Protocol.hs                               |  623 ++
 README                                        |    7 +
 Remote.hs                                     |  447 +
 Remote/Adb.hs                                 |  496 +
 Remote/BitTorrent.hs                          |  416 +
 Remote/Borg.hs                                |  418 +
 Remote/Bup.hs                                 |  343 +
 Remote/Ddar.hs                                |  239 +
 Remote/Directory.hs                           |  604 ++
 Remote/Directory/LegacyChunked.hs             |  126 +
 Remote/External.hs                            |  929 ++
 Remote/External/AsyncExtension.hs             |  132 +
 Remote/External/Types.hs                      |  486 +
 Remote/GCrypt.hs                              |  529 +
 Remote/Git.hs                                 |  771 ++
 Remote/GitLFS.hs                              |  549 +
 Remote/Glacier.hs                             |  367 +
 Remote/Helper/AWS.hs                          |   86 +
 Remote/Helper/Chunked.hs                      |  580 ++
 Remote/Helper/Chunked/Legacy.hs               |  121 +
 Remote/Helper/Encryptable.hs                  |  322 +
 Remote/Helper/ExportImport.hs                 |  389 +
 Remote/Helper/Git.hs                          |   68 +
 Remote/Helper/Hooks.hs                        |   98 +
 Remote/Helper/Http.hs                         |   93 +
 Remote/Helper/Messages.hs                     |   32 +
 Remote/Helper/P2P.hs                          |   80 +
 Remote/Helper/Path.hs                         |   19 +
 Remote/Helper/ReadOnly.hs                     |   75 +
 Remote/Helper/Special.hs                      |  265 +
 Remote/Helper/Ssh.hs                          |  327 +
 Remote/Helper/ThirdPartyPopulated.hs          |   85 +
 Remote/Hook.hs                                |  183 +
 Remote/HttpAlso.hs                            |  232 +
 Remote/List.hs                                |  119 +
 Remote/List/Util.hs                           |   24 +
 Remote/P2P.hs                                 |  173 +
 Remote/Rclone.hs                              |   31 +
 Remote/Rsync.hs                               |  414 +
 Remote/Rsync/RsyncUrl.hs                      |   53 +
 Remote/S3.hs                                  | 1383 +++
 Remote/Tahoe.hs                               |  310 +
 Remote/Web.hs                                 |  273 +
 Remote/WebDAV.hs                              |  540 +
 Remote/WebDAV/DavLocation.hs                  |   92 +
 RemoteDaemon/Common.hs                        |   71 +
 RemoteDaemon/Core.hs                          |  178 +
 RemoteDaemon/Transport.hs                     |   30 +
 RemoteDaemon/Transport/GCrypt.hs              |   28 +
 RemoteDaemon/Transport/Ssh.hs                 |   88 +
 RemoteDaemon/Transport/Ssh/Types.hs           |   32 +
 RemoteDaemon/Transport/Tor.hs                 |  206 +
 RemoteDaemon/Types.hs                         |  112 +
 Setup.hs                                      |   13 +
 Test.hs                                       | 2119 ++++
 Test/Framework.hs                             |  868 ++
 Types.hs                                      |   31 +
 Types/ActionItem.hs                           |  115 +
 Types/AdjustedBranch.hs                       |   64 +
 Types/Availability.hs                         |   11 +
 Types/Backend.hs                              |   49 +
 Types/Benchmark.hs                            |   26 +
 Types/BranchState.hs                          |   42 +
 Types/CatFileHandles.hs                       |   38 +
 Types/CleanupActions.hs                       |   27 +
 Types/Command.hs                              |  145 +
 Types/Concurrency.hs                          |   25 +
 Types/Creds.hs                                |   14 +
 Types/Crypto.hs                               |   77 +
 Types/DeferredParse.hs                        |   57 +
 Types/DesktopNotify.hs                        |   31 +
 Types/Difference.hs                           |  136 +
 Types/Direction.hs                            |   25 +
 Types/Distribution.hs                         |   80 +
 Types/Export.hs                               |   66 +
 Types/FileMatcher.hs                          |  108 +
 Types/GitConfig.hs                            |  525 +
 Types/Group.hs                                |   38 +
 Types/Import.hs                               |  105 +
 Types/IndexFiles.hs                           |   11 +
 Types/Key.hs                                  |  356 +
 Types/KeySource.hs                            |   30 +
 Types/Link.hs                                 |   13 +
 Types/LockCache.hs                            |   18 +
 Types/Messages.hs                             |   92 +
 Types/MetaData.hs                             |  375 +
 Types/Mime.hs                                 |   12 +
 Types/NumCopies.hs                            |  200 +
 Types/ProposedAccepted.hs                     |   38 +
 Types/RefSpec.hs                              |   52 +
 Types/Remote.hs                               |  415 +
 Types/RemoteConfig.hs                         |   72 +
 Types/RemoteState.hs                          |   19 +
 Types/RepoVersion.hs                          |   11 +
 Types/ScheduledActivity.hs                    |   68 +
 Types/StallDetection.hs                       |   58 +
 Types/StandardGroups.hs                       |  109 +
 Types/StoreRetrieve.hs                        |   52 +
 Types/Test.hs                                 |   26 +
 Types/Transfer.hs                             |   99 +
 Types/Transferrer.hs                          |  162 +
 Types/TransferrerPool.hs                      |   59 +
 Types/Transitions.hs                          |   19 +
 Types/TrustLevel.hs                           |   51 +
 Types/UUID.hs                                 |  109 +
 Types/Upgrade.hs                              |   10 +
 Types/UrlContents.hs                          |   20 +
 Types/VectorClock.hs                          |   31 +
 Types/View.hs                                 |   69 +
 Types/WorkerPool.hs                           |  166 +
 Upgrade.hs                                    |  139 +
 Upgrade/V0.hs                                 |   58 +
 Upgrade/V1.hs                                 |  260 +
 Upgrade/V2.hs                                 |  150 +
 Upgrade/V3.hs                                 |   12 +
 Upgrade/V4.hs                                 |   16 +
 Upgrade/V5.hs                                 |  170 +
 Upgrade/V5/Direct.hs                          |  144 +
 Upgrade/V6.hs                                 |   24 +
 Upgrade/V7.hs                                 |  139 +
 Upgrade/V8.hs                                 |   23 +
 Upgrade/V9.hs                                 |  107 +
 Utility/Aeson.hs                              |  126 +
 Utility/Android.hs                            |   28 +
 Utility/Applicative.hs                        |   20 +
 Utility/Attoparsec.hs                         |   21 +
 Utility/AuthToken.hs                          |  102 +
 Utility/Base64.hs                             |   25 +
 Utility/Batch.hs                              |   87 +
 Utility/Bloom.hs                              |   40 +
 Utility/CoProcess.hs                          |  103 +
 Utility/CopyFile.hs                           |   96 +
 Utility/DBus.hs                               |   91 +
 Utility/Daemon.hs                             |  194 +
 Utility/Data.hs                               |   22 +
 Utility/DataUnits.hs                          |  197 +
 Utility/Debug.hs                              |  102 +
 Utility/DebugLocks.hs                         |   43 +
 Utility/DirWatcher.hs                         |  165 +
 Utility/DirWatcher/FSEvents.hs                |   97 +
 Utility/DirWatcher/INotify.hs                 |  205 +
 Utility/DirWatcher/Kqueue.hs                  |  269 +
 Utility/DirWatcher/Types.hs                   |   28 +
 Utility/DirWatcher/Win32Notify.hs             |   67 +
 Utility/Directory.hs                          |  129 +
 Utility/Directory/Create.hs                   |  105 +
 Utility/Directory/Stream.hs                   |  119 +
 Utility/DiskFree.hs                           |   24 +
 Utility/Dot.hs                                |   75 +
 Utility/DottedVersion.hs                      |   45 +
 Utility/Env.hs                                |   67 +
 Utility/Env/Basic.hs                          |   25 +
 Utility/Env/Set.hs                            |   49 +
 Utility/Exception.hs                          |  120 +
 Utility/FileMode.hs                           |  187 +
 Utility/FileSize.hs                           |   51 +
 Utility/FileSystemEncoding.hs                 |  150 +
 Utility/Format.hs                             |  242 +
 Utility/FreeDesktop.hs                        |  147 +
 Utility/Glob.hs                               |   81 +
 Utility/Gpg.hs                                |  484 +
 Utility/Hash.hs                               |  353 +
 Utility/HtmlDetect.hs                         |   67 +
 Utility/HumanNumber.hs                        |   25 +
 Utility/HumanTime.hs                          |  106 +
 Utility/IPAddress.hs                          |  143 +
 Utility/InodeCache.hs                         |  310 +
 Utility/LinuxMkLibs.hs                        |  100 +
 Utility/LockFile.hs                           |   23 +
 Utility/LockFile/LockStatus.hs                |   13 +
 Utility/LockFile/PidLock.hs                   |  333 +
 Utility/LockFile/Posix.hs                     |  128 +
 Utility/LockFile/Windows.hs                   |   91 +
 Utility/LockPool.hs                           |   34 +
 Utility/LockPool/LockHandle.hs                |   92 +
 Utility/LockPool/PidLock.hs                   |  159 +
 Utility/LockPool/Posix.hs                     |   75 +
 Utility/LockPool/STM.hs                       |  179 +
 Utility/LockPool/Windows.hs                   |   48 +
 Utility/LogFile.hs                            |   69 +
 Utility/Lsof.hs                               |  113 +
 Utility/MD5.hs                                |   24 +
 Utility/MagicWormhole.hs                      |  177 +
 Utility/Matcher.hs                            |  342 +
 Utility/Metered.hs                            |  546 +
 Utility/Misc.hs                               |  147 +
 Utility/Monad.hs                              |   91 +
 Utility/Mounts.hs                             |   21 +
 Utility/MoveFile.hs                           |   83 +
 Utility/Network.hs                            |   24 +
 Utility/NotificationBroadcaster.hs            |   96 +
 Utility/OSX.hs                                |   51 +
 Utility/OpenFd.hs                             |   27 +
 Utility/OptParse.hs                           |   49 +
 Utility/PID.hs                                |   30 +
 Utility/PartialPrelude.hs                     |   79 +
 Utility/Path.hs                               |  279 +
 Utility/Path/AbsRel.hs                        |   86 +
 Utility/Path/Max.hs                           |   38 +
 Utility/Path/Tests.hs                         |   81 +
 Utility/Path/Windows.hs                       |   47 +
 Utility/Percentage.hs                         |   33 +
 Utility/Process.hs                            |  325 +
 Utility/Process/Shim.hs                       |    3 +
 Utility/Process/Transcript.hs                 |   97 +
 Utility/QuickCheck.hs                         |   89 +
 Utility/RawFilePath.hs                        |  125 +
 Utility/ResourcePool.hs                       |   94 +
 Utility/Rsync.hs                              |  188 +
 Utility/SafeCommand.hs                        |  113 +
 Utility/SafeOutput.hs                         |   36 +
 Utility/Scheduled.hs                          |  362 +
 Utility/Scheduled/QuickCheck.hs               |   51 +
 Utility/Shell.hs                              |   58 +
 Utility/ShellEscape.hs                        |   72 +
 Utility/SimpleProtocol.hs                     |  151 +
 Utility/Split.hs                              |   39 +
 Utility/SshConfig.hs                          |  164 +
 Utility/SshHost.hs                            |   29 +
 Utility/StatelessOpenPGP.hs                   |  207 +
 Utility/Su.hs                                 |  122 +
 Utility/SystemDirectory.hs                    |   16 +
 Utility/TList.hs                              |  103 +
 Utility/Tense.hs                              |   60 +
 Utility/Terminal.hs                           |   44 +
 Utility/ThreadLock.hs                         |   23 +
 Utility/ThreadScheduler.hs                    |   67 +
 Utility/TimeStamp.hs                          |   72 +
 Utility/Tmp.hs                                |  116 +
 Utility/Tmp/Dir.hs                            |   72 +
 Utility/Tor.hs                                |  196 +
 Utility/Touch.hs                              |   45 +
 Utility/Tuple.hs                              |   21 +
 Utility/Url.hs                                |  743 ++
 Utility/Url/Parse.hs                          |   64 +
 Utility/UserInfo.hs                           |   74 +
 Utility/Verifiable.hs                         |   46 +
 Utility/WebApp.hs                             |  204 +
 Utility/Yesod.hs                              |   38 +
 Utility/libkqueue.c                           |   74 +
 Utility/libkqueue.h                           |    3 +
 bash-completion.bash                          |   44 +
 debian/NEWS                                   |    1 +
 debian/changelog                              |    1 +
 debian/compat                                 |    1 +
 debian/control                                |  149 +
 debian/copyright                              |    1 +
 debian/create-standalone-changelog            |   17 +
 debian/doc-base                               |    9 +
 debian/patches/series.standalone-build        |    1 +
 debian/patches/standalone-build               |   76 +
 debian/rules                                  |   44 +
 debian/source/format                          |    1 +
 debian/tests/basics                           |    4 +
 debian/tests/control                          |    4 +
 doc/Android.mdwn                              |   77 +
 ..._37aa87a451d4390ed367402eec740855._comment |   12 +
 ..._7f0caccd085a541b117c8583133e94dd._comment |   10 +
 ..._ff03ae378da71c6637959779139ecb12._comment |   11 +
 ..._c7591d06fc444a4462267b000be8d688._comment |    9 +
 ..._9118997c7e892ce163c33a0de963fa11._comment |   17 +
 ..._e9559029d8f2c482a482f7343ffa99a4._comment |   22 +
 doc/android/DCIM.png                          |  Bin 0 -> 95786 bytes
 doc/android/appinstalled.png                  |  Bin 0 -> 16805 bytes
 doc/android/webapp.png                        |  Bin 0 -> 64097 bytes
 doc/assistant.mdwn                            |   38 +
 doc/assistant/addsshserver.png                |  Bin 0 -> 31740 bytes
 doc/assistant/archival_walkthrough.mdwn       |   32 +
 doc/assistant/brokenrepositoryalert.png       |  Bin 0 -> 5806 bytes
 doc/assistant/buddylist.png                   |  Bin 0 -> 4347 bytes
 doc/assistant/cloudnudge.png                  |  Bin 0 -> 7332 bytes
 doc/assistant/combinerepos.png                |  Bin 0 -> 10677 bytes
 ..._f2c4857b7b000e005f0c19279db14eaf._comment |    8 +
 ..._befa1f48e5a43a7965060491430a6bc4._comment |    9 +
 ..._9bd3b532a5c026a1d664c898f8e335e6._comment |    8 +
 ..._c546a24459ca29025f00e424353c40d2._comment |    8 +
 ..._d17de359cdd46659170d373cd09c0979._comment |    8 +
 ..._70193bbaa5d60b829d7636748c641104._comment |    8 +
 ..._831a529c92951f70a27721210204e46b._comment |    7 +
 doc/assistant/connection.png                  |  Bin 0 -> 3181 bytes
 doc/assistant/controlmenu.png                 |  Bin 0 -> 8863 bytes
 doc/assistant/crashrecovery.png               |  Bin 0 -> 6594 bytes
 doc/assistant/dashboard.png                   |  Bin 0 -> 41061 bytes
 doc/assistant/deleterepository.png            |  Bin 0 -> 22780 bytes
 doc/assistant/downloadnotification.png        |  Bin 0 -> 4513 bytes
 doc/assistant/downloadupgrade.png             |  Bin 0 -> 9071 bytes
 doc/assistant/encryptdrive.png                |  Bin 0 -> 42725 bytes
 doc/assistant/example.png                     |  Bin 0 -> 110994 bytes
 doc/assistant/fsckconfig.png                  |  Bin 0 -> 59050 bytes
 doc/assistant/genkey.png                      |  Bin 0 -> 27854 bytes
 doc/assistant/iaitem.png                      |  Bin 0 -> 34868 bytes
 doc/assistant/inotify_max_limit_alert.png     |  Bin 0 -> 12583 bytes
 doc/assistant/konquerormenu.png               |  Bin 0 -> 27159 bytes
 doc/assistant/local_pairing_walkthrough.mdwn  |   90 +
 .../addrepository.png                         |  Bin 0 -> 2259 bytes
 ..._b33deed054d3aa8cfa6c9e3958643f16._comment |    8 +
 ..._39f1162b4d43b61e957e7497df4b9e2b._comment |    8 +
 ..._588869692b290483f58f3a7aa2bfb55f._comment |   17 +
 ..._f6bf82c263fefe38701709d9dbd974cc._comment |   10 +
 ..._bada601ea4b7104f162a3e00def4be2b._comment |   19 +
 ..._01ba0f9bfa0ed066c4b73d2d6028eecc._comment |    8 +
 ..._17d44229e4fa46c50815672b96a9735a._comment |   10 +
 ..._b9d4c29cf2cca0427808df6af08fb789._comment |    8 +
 ..._bf313e490076a4676a632e3ec6129189._comment |    9 +
 .../local_pairing_walkthrough/pairing.png     |  Bin 0 -> 6771 bytes
 .../local_pairing_walkthrough/pairrequest.png |  Bin 0 -> 5383 bytes
 .../local_pairing_walkthrough/secret.png      |  Bin 0 -> 5132 bytes
 .../local_pairing_walkthrough/secretempty.png |  Bin 0 -> 9575 bytes
 doc/assistant/logs.png                        |  Bin 0 -> 33631 bytes
 doc/assistant/makerepo.png                    |  Bin 0 -> 32061 bytes
 doc/assistant/menu.png                        |  Bin 0 -> 22921 bytes
 doc/assistant/nautilusmenu.png                |  Bin 0 -> 59867 bytes
 doc/assistant/osx-app.png                     |  Bin 0 -> 2604 bytes
 doc/assistant/preferences.png                 |  Bin 0 -> 22815 bytes
 doc/assistant/quickstart.mdwn                 |   30 +
 doc/assistant/release_notes.mdwn              |  422 +
 ..._bd8f376c9d0c1d5ed07fb013907a60ee._comment |   14 +
 ..._75e0774ad042717fbd059a8a9ec2db1e._comment |   12 +
 ..._b3bfd8e547e20c51f7c32c6c9424e936._comment |   10 +
 ..._c6caa2b521b456bb4ce594d64919cffe._comment |    8 +
 ..._e9faf88a8eeb9aa8714c8c0514792815._comment |   13 +
 ..._53c2b479dbb53236000b4b3caad8ed04._comment |   13 +
 doc/assistant/remote_sharing_walkthrough.mdwn |   12 +
 doc/assistant/repairrepository.png            |  Bin 0 -> 31791 bytes
 doc/assistant/repogroups.png                  |  Bin 0 -> 15636 bytes
 doc/assistant/repoinfo.png                    |  Bin 0 -> 7603 bytes
 doc/assistant/repositories.png                |  Bin 0 -> 63405 bytes
 doc/assistant/rsync.net.encryption.png        |  Bin 0 -> 40504 bytes
 doc/assistant/rsync.net.png                   |  Bin 0 -> 61465 bytes
 doc/assistant/running.png                     |  Bin 0 -> 24664 bytes
 .../share_with_a_friend_walkthrough.mdwn      |   40 +
 .../enabletor.png                             |  Bin 0 -> 39694 bytes
 .../pairing.png                               |  Bin 0 -> 6892 bytes
 .../wormholepairing.png                       |  Bin 0 -> 59760 bytes
 doc/assistant/thanks.mdwn                     |    1 +
 doc/assistant/thumbnail.png                   |  Bin 0 -> 3491 bytes
 doc/assistant/unused.png                      |  Bin 0 -> 49957 bytes
 doc/assistant/upgradecomplete.png             |  Bin 0 -> 4817 bytes
 doc/assistant/xmpp.png                        |  Bin 0 -> 27753 bytes
 doc/assistant/xmppnudge.png                   |  Bin 0 -> 6156 bytes
 doc/assistant/xmpppairingend.png              |  Bin 0 -> 34379 bytes
 doc/automatic_conflict_resolution.mdwn        |   25 +
 ..._307898855f91a2a189d4fa5eae62cce1._comment |   10 +
 ..._0a8ea42764dde1a33d2112197b961c51._comment |    8 +
 ..._5c587c6633cae1c8547ca970d55ee97e._comment |    8 +
 ..._80539e11e36a0b64cee83b6b373bd843._comment |   17 +
 ..._00ac9e4a47ce9a886dbf573480f151bd._comment |   10 +
 ..._8a0860fee88f5954918305f055a39d8d._comment |   10 +
 ..._3d2250cc26036b8532faa980065e20d0._comment |   23 +
 ..._ef474c258ce8e0ebc6485c1366ae6315._comment |    8 +
 doc/backends.mdwn                             |  115 +
 ..._920cd139dfec8adb1089f5acf26de4d2._comment |    8 +
 ..._f0f6316bbdc971a9ab157de9bbb9f74c._comment |   14 +
 ..._da76dff5fe712318d7d4313f1d827883._comment |   10 +
 ..._578423935bc71cdbdc23c3db06d1e870._comment |    8 +
 ..._57154dcd1041a33f220f9105b709be89._comment |    8 +
 ..._b3445fd1f379346c642a27211c6c798b._comment |   14 +
 ..._c68dfaeee2ef18f420f7e11ff5f604b9._comment |   15 +
 ..._557a622b3304eb86fed52896e0b6cbda._comment |    7 +
 ..._784b29b086503a2b4913558350526ee1._comment |   12 +
 ..._cfcaeea6fdded241f5d36ef251ef8010._comment |   12 +
 ..._375bb1fb5973e8fa67b763f2dd6e404b._comment |   13 +
 ..._29e500adf7e8614a938b3b714c9bd112._comment |   36 +
 ..._7f9cc5f966b28b7461e8ec42ceeb7165._comment |    9 +
 ..._be75c669ed8e127de8b6364961a5c0cb._comment |    9 +
 ..._8c8b08d7e6409756da4f9f3b21d5ad01._comment |   12 +
 ..._f90b8eeae8d150eca6a91416f20eb223._comment |   10 +
 ..._f6a697ac069ab018ccacf8f16b09bc7e._comment |   10 +
 ..._9e9e0f3631c60b0cdcaa9c6dd4ae0d4e._comment |    8 +
 ..._c311551741a671bcb1f32b80431c1d66._comment |   17 +
 ..._44e8d93b1f0a88c36543438d6e33d702._comment |    9 +
 ..._9e14c32713b5607b245972b400286a45._comment |   24 +
 ..._1f2626eca9004b31a0b7fc1a0df8027b._comment |   24 +
 ..._bea2a3f4f673e6e9d5ee99cf10d39460._comment |   12 +
 ..._32df8ec41dd8a6516b88b1871c998eb9._comment |   10 +
 ..._b0a375dcd0932aa380ce01d693462f5e._comment |   14 +
 ..._4c5f9c75cbb8a546e8325b206369aba1._comment |   10 +
 ..._3782e7561607c8ccf1741bd039c2c648._comment |    7 +
 ..._8ac9d37cc2a7b0b361cf686fe27192dd._comment |    9 +
 ..._fdcbf8727fdefb9942a54689234b9698._comment |   12 +
 ..._46591a3ba888fb686b1b319b80ca2c22._comment |    9 +
 ..._2210c7ff2d5812fb3b778ac172291656._comment |    8 +
 ..._82f239b58680a2681bd8074c7ef9584d._comment |    8 +
 ..._4aa8cfaec1090f79fed530720e4ddad4._comment |   18 +
 ..._c40d2c2c929ad3239ee5d529e307c746._comment |    8 +
 ..._5bef7f76f5e5b73a8e404fe6172b4368._comment |   12 +
 doc/bare_repositories.mdwn                    |   53 +
 ..._148e1da70d37d311634a0309a4ff8dcd._comment |   22 +
 ..._c88216da0588562c851c2ceabbfebc0a._comment |   28 +
 ..._26ba93bddb0cd1bb4e1799311f3ca750._comment |   11 +
 ..._7cf6103709a7a2710686681a6f406214._comment |    8 +
 ..._6328134497c0de6a088087fc9cb0e59e._comment |   31 +
 ..._bf227861ec3cb2ea474c143218c68133._comment |   12 +
 ..._9e065a2d8aaf7371ab7c0bb4f0c724b0._comment |   13 +
 ..._d4dff0d6265be941af9f66ba09f36ebe._comment |   12 +
 doc/bugs.mdwn                                 |   11 +
 ...-dir_and_--work-tree_separation_issue.mdwn |   99 +
 ..._fa97996b85c0f949bbd720204db8ed46._comment |   61 +
 ...cannot_probe_for_untrusted_remote_key.mdwn |   26 +
 ..._e35bef8fb0b9a40938022c43c87df597._comment |   15 +
 ..._7z_or_tar_archive_builds_for_windows.mdwn |    5 +
 ..._70480ffd417788f18cd75a9b625ecf3b._comment |   19 +
 ..._afa6a131999feda67876859cd85ebcfc._comment |   15 +
 ...st_--unlock_not_using_--reflink__63__.mdwn |   20 +
 ..._c42743828ddc62f7df7f612c713ee309._comment |   18 +
 doc/bugs/Always_identical_UUIDs.mdwn          |   89 +
 ..._1223fe5e635d771848d7054f0492920f._comment |   15 +
 ..._6c44232cac847f6160f5bec7c8f1434b._comment |   10 +
 ..._cdb2eec514bcf125b7f79c7be5ed810a._comment |   14 +
 ...ndroid__44___unable_to_start_browser_.mdwn |   24 +
 ..._1fc9d5168fec0b277b5ab5321c07385f._comment |   14 +
 ..._8db1f505c02fd6d4e8acc1b6bbded03f._comment |   10 +
 ..._93e260d1cb9de25fe4e2a6a973f05da6._comment |   10 +
 ...everal_error_messages___47___warnings.mdwn |   38 +
 ..._85da61d3dfb528fef17366effe123ff5._comment |   16 +
 ..._97ddaba23e91a903f69cf00931627444._comment |   21 +
 ..._b4ea7ff7deb9626a02dfd0eb459f22a2._comment |   12 +
 ..._5edddd7e90b8f11c52a44abfb891ce25._comment |   20 +
 ..._b38b675a2862d527fad28b7477f7ddde._comment |    8 +
 ...no_such_protocol_name__58___tcp__41__.mdwn |   34 +
 ..._be30193f501c530bd99e97992a9c08ad._comment |   13 +
 ...IM__47__Camera_not_being_configurable.mdwn |   16 +
 ..._1fe5f8c68a430b2436649cf4ba8f4987._comment |   10 +
 ..._files_with_utf-8_characters_in_names.mdwn |   36 +
 ..._bcc3ce19cf26731057a7f3189fcbae19._comment |   10 +
 ...ux_install_fails_with_Bad_system_call.mdwn |   16 +
 ...unable_to_use_external_special_remote.mdwn |   34 +
 ..._17b13329db6fb4788240428ed1e2b212._comment |   13 +
 ..._c235675c07faaecf8e7df2d77fdac3ea._comment |    8 +
 ...__40__git_add__41___to_git-annex_file.mdwn |   57 +
 ...and_only_SHA_instead_of_file_content_.mdwn |  307 +
 ..._f88d08035baf75efa1dbbddc296b591a._comment |   35 +
 ..._c1b86731f0e2fe8ce70931fe4a0d1656._comment |   40 +
 ...shes_with_handle_issues_-_never_works.mdwn |   51 +
 ...en_merging___40__another_report__41__.mdwn |   37 +
 ..._27d96b639bc386132b9e74170532d749._comment |    9 +
 ..._b9a39f172115fc39fee21c8987843faa._comment |   26 +
 ..._324213fb62c67dc9565f0e812500e046._comment |    8 +
 ..._271c48d2cf4b09c27cf47ecba7fe1a64._comment |    8 +
 ...stant_does_not_update_adjusted_branch.mdwn |   90 +
 ...t_doesn__39__t_sync_directory_remotes.mdwn |   34 +
 ...m_remote_repos_that_it_shouldn__39__t.mdwn |   39 +
 ..._5e7d5b0b996a171c641fa560a613d319._comment |   19 +
 ..._2015dfc648d26d6dfabe6ad4f4754034._comment |   13 +
 ..._8f394437982cebeaf878f5b3871afaf3._comment |   18 +
 ..._ccd108a53a9fb747539e269becfb3e05._comment |    9 +
 ..._7ee571496c6d7cd57a206e6356dc2be3._comment |  166 +
 ..._6c88b218b8186242a6106fc3e7b3edf5._comment |   29 +
 ..._fbbf9d1a63fc61a5fd288fd308b24ca1._comment |   13 +
 ..._fe2498f60b02104a8a044c79cb5bea63._comment |   66 +
 ..._c46cdba62da4f5ccfdc42dfc33aec600._comment |   34 +
 ..._created_155_semitrusted_repositories.mdwn |  191 +
 ..._c5508b476fc48e7a0002b6ecb8d5eac0._comment |   18 +
 ..._cb49edcc8a13928c171a2acdde32dce9._comment |   12 +
 ..._a86c8347526e7b0a6f7633f3aea528bb._comment |    8 +
 ..._a26c2b49ee7746be06f4772aa838d5aa._comment |   21 +
 ..._b958da97a69091d283918e0d5a658da5._comment |   26 +
 ..._169b24b34cce3f5c8446c2150beb6827._comment |    8 +
 ..._6acd6f38297772a07d8d5fb999bd2eaa._comment |  183 +
 ..._6a4118e5c5fbe5e84d27094ac72b741b._comment |   22 +
 ..._04daa20d5d7c74bb34ec48e752ed9fe8._comment |    8 +
 ..._11af8ab2587e6eeb671051ba8191995b._comment |   11 +
 ..._26236cdc2bce532017854791bcd727d1._comment |    8 +
 ..._3c532dd5b8a01ecdeda1300b49aba675._comment |   12 +
 ..._119142c5ebc499f0ee0926dbca265308._comment |   10 +
 ..._0651071ee1654eeaa9aa9369873fdf6a._comment |    8 +
 ...er_and_over_and_using_a_lot_of_memory.mdwn |  520 +
 ..._edb2428552cf98bfb1735c2d6daf2b20._comment |    8 +
 ..._ac8c39e362e6c806b9d68befc0199ccd._comment |   10 +
 ..._b2941bf7901a1b2237b7210c8f0af2a5._comment |   22 +
 ..._1429ca784a03bc424b3537cbe0449421._comment |   23 +
 ..._f9e65cf5598b4b14eeee1f41f46d4084._comment |   12 +
 ..._044ecac2d2e670e1ef69809c944093d1._comment |   19 +
 ..._6f4f51e1583bed5e7e601e4f30f4207b._comment |    8 +
 ..._683a0a3d4caea0ee625e41ae8a6c7c06._comment |   81 +
 ..._03dd76b01f46a7cc66eddac3e054c8ad._comment |    8 +
 ..._5f4444f03cbebaa44628288095383679._comment |   89 +
 ...nt_is_stuck_with___39__fuzztest__39__.mdwn |   23 +
 ...tant_only_watches_one_repo_on_startup.mdwn |   29 +
 ..._4606e5c7159e8e9f2f12e010cbd22e6a._comment |   12 +
 ...t_temporary_delete_and_recommit_files.mdwn |  606 ++
 ...to_repair_repository_almost_every_day.mdwn |    5 +
 ...repair_greatly_slows_down_the_machine.mdwn |   21 +
 ..._d46c6314bff75a0ae679bc2358b28c2b._comment |    8 +
 ..._1c2c3adfbccd2b14a7d1c4618800e735._comment |    8 +
 ..._a52e4ef04209d0a2449165e2b4cb9ccc._comment |   10 +
 ..._9f5340ab1012f335af0c246b82c1a777._comment |   16 +
 ..._67bfccf0934075559d439b1deafc001e._comment |    9 +
 ..._5fa785aa759d1a1917f2a292324fe5ec._comment |    8 +
 ..._9fe529034ad0115792b58d7da99c167e._comment |    8 +
 ..._93ed991ef2a74c18575073ca72e06185._comment |    8 +
 ..._4649fa11745ff668e43833209811d005._comment |   10 +
 ..._6138a48f0b7e8be2bb66430397afdf5a._comment |    8 +
 ..._3da5940bb2e9689b00239eec9a073f1c._comment |    8 +
 .../Bootstrap3_icons_missing_on_Android.mdwn  |    7 +
 ..._da4e26c77376a8171493a815bdb51ff1._comment |   10 +
 ..._506e26de284a6429366def33b007bc0c._comment |    8 +
 ..._a77477951576fc657d693811f11f9975._comment |   24 +
 ..._c3ef67bded8ed3c511a8ea85b8bd81a5._comment |    8 +
 ..._97cf233d8401d642337d5fe9dd525e2b._comment |    8 +
 ..._4981a0a894b77e94a3bffec82b0f6e51._comment |   16 +
 ..._dbe960392aaa0839886381820754814a._comment |   10 +
 ..._cdf9621fe3e9f8eb8b7af88f779a7116._comment |    8 +
 ..._a2318f094b30f58fefc072807896c099._comment |    8 +
 ..._7c2f1d914793798708ca13b6ac3dd474._comment |   29 +
 ..._a24b5165590b5d58919da1003cd20c54._comment |    8 +
 ..._71ed14b8e5a898b1643d5e37591c2476._comment |    8 +
 ..._15357e33c2431080d45f7cef5f4f1209._comment |    8 +
 ...inks_in_directory_remote_causes_crash.mdwn |   37 +
 .../Button_to_cancel_conistency_checks.mdwn   |   21 +
 ...PRESENT_could_check_file_size_as_well.mdwn |    7 +
 ..._7bbba896da745a8a6b69ec62bf71fc89._comment |   13 +
 ...perability_Win-Ux__58__..post-receive.mdwn |   64 +
 ..._a9501e2f347b957e7dc53a06fe59cff4._comment |   17 +
 ..._e4cac0d18fd6cde1084e93d0fe997f40._comment |   25 +
 ..._a3a702176a316d6b599eb2a149a293ad._comment |   17 +
 ..._82103077cde68c3b6a70dcf70c4ed837._comment |   22 +
 ..._c22f9e3c5e438b2cc05008bc3f91b7fc._comment |   11 +
 ...epo__47__.git__47__X__34___for_many_X.mdwn |   39 +
 ..._5d23b1f02c6a0db0b43939210c427994._comment |    8 +
 ..._6ede677f8113fcd6215ecd68de237f06._comment |    8 +
 ..._3377120e8e246f5ec74d372015590a6c._comment |    8 +
 ...remote_in_webapp__58___gcrypt_backend.mdwn |   15 +
 doc/bugs/Cannot_clone_an_annex.mdwn           |   69 +
 ..._b40a2652361a79c6c6eab0fc21be8e46._comment |    8 +
 ...not_delete_remote_when_ssh_sync_fails.mdwn |    8 +
 ..._3c8e8fae688a9db8e18e869a187fb4eb._comment |    8 +
 ..._e189617c4ac23df50f02af8c517fa399._comment |   14 +
 ..._35a08daa2776c648d5ee010b77e72bd4._comment |   11 +
 ...ing_sync_to_include_content_breaks_UX.mdwn |   68 +
 ..._ec80bdff87c7b70e4235cd5b2ba6ed05._comment |   51 +
 ..._82e32aca2c23a1e27553bcd9708870b2._comment |   25 +
 ..._4e0746d00d8a596d878c1fe12ec68849._comment |   48 +
 ..._80ba2e4241372ff3ce1505900e17c22f._comment |   32 +
 ..._08f3c3d26d13fd44ae9c26791b90a8fc._comment |   17 +
 ..._38a0eafe91e05a7784dd5e305f38a8f3._comment |   18 +
 ..._ee529ac7b3d27f1cdc7edf5154c0da8f._comment |   12 +
 ..._d60adea3f0c0030a403c33c57f27abda._comment |   24 +
 ..._594ae4ce426c7fd9963a22def58904d8._comment |   12 +
 ..._bdc211b026d3b05de127f6ed5a3d19b0._comment |   21 +
 ..._1541a9323009b20f527501ebedc9d395._comment |   12 +
 ..._c06017f123f1ee34c7310f923086d09a._comment |   21 +
 ..._c03b45321728155eae9470cd8bb2cc93._comment |   17 +
 ..._bb6972e9870a68a98d90c6847228ab31._comment |   22 +
 ..._da9812dd37de7bba4fe2b1785bdca1ae._comment |   14 +
 ..._bc8154b171c460b4590d2b32401f24a2._comment |   16 +
 ..._20febad4aa06d5b39668a858d2b118b1._comment |   33 +
 ..._84d31b8fdde0f0ab0355a5d30760e90d._comment |   43 +
 ..._17a75fa68bf3718230d1d523b7eb0250._comment |   12 +
 ...om_.git_under_Windows__44___get_fails.mdwn |  292 +
 ..._0d619c1a4c9645a6b76619b05b3d518c._comment |   17 +
 ..._0bc5932c037002dac6b096f97d12584c._comment |   10 +
 ...es_Containing_Non_Ascii_Char_on_OS_X_.mdwn |   46 +
 ..._81a4647a9b51bed8c230a2a16990915d._comment |   14 +
 ..._f8e97dded9ba6d2305de1278025924fe._comment |   23 +
 ..._eb34061429cb8c7d0b155825e84b657b._comment |   35 +
 ..._8cf5dc85a94c60b9c88c8e8354f19772._comment |   32 +
 ...pace_exhaustion_from_syncing_metadata.mdwn |   26 +
 ..._93e3deab54b34e9ad608fd549119e221._comment |   26 +
 ..._9401be5e6af886edadaf3ad7ba6a071d._comment |   12 +
 ..._3309c51dbd251cc46a25557a0d25e946._comment |    9 +
 ...any_files_to_bup_remotes_is_very_slow.mdwn |   81 +
 ..._d81f94dfdb1b15b8bc0d9c243ef748db._comment |   15 +
 ..._0f5ff10d84450a6df35cb974cdb4739e._comment |   15 +
 ..._7150178b47a15857d5eece0fbe57a971._comment |   10 +
 ..._d2896b544d6d26663b532735c3924134._comment |   11 +
 ...nex__47__index_when_running_assistant.mdwn |  658 ++
 ..._f2102da5822a35e1600d67326954e059._comment |    7 +
 ..._656986cdc4831a8d2f80432acaf8a884._comment |   25 +
 ..._fa94d1b008a6c1663e40854edcd5504d._comment |    9 +
 ..._5a26a33c34594ec6eb50bd675d68801a._comment |   17 +
 ..._81e2f37e7adbd8f24734b67a1dd209f9._comment |    7 +
 ..._f0999dbd00e06ab2cbf68b58527c2b9b._comment |   16 +
 ...eleted_and_deletes_them_elsewhere_too.mdwn |   36 +
 ..._80ca50f5305eda71fe32f2b0bc922c34._comment |   21 +
 ..._e6bc6d1c0eb8c469e9e00b37bbcc9b86._comment |    9 +
 ..._0d0f6b6b46d0153433fead2bbd1bbe64._comment |   12 +
 ..._6058a22b733cb02126286af950074ed4._comment |   10 +
 ..._593a49669e2fadfb91773f8c84fbb031._comment |    8 +
 ..._5a348c5f327f16e1192ef6bd7f2880bb._comment |   15 +
 ..._but_not_annex__41___controlled_files.mdwn |  102 +
 ..._48f15b40bf3a7cd3beb7cabd4e706337._comment |   15 +
 ...Could_not_read_from_remote_repository.mdwn |   28 +
 ..._da842a9d146bcd5c7773b58364c25597._comment |    8 +
 ..._82746a0cf989d884cd0fd796db092b3c._comment |   36 +
 ..._95d16045dc238dba19a98808de2eeedf._comment |   11 +
 ..._when_disabling_syncing_in_the_webapp.mdwn |   25 +
 ..._e25dd80370820782f9c6a877101d8703._comment |   10 +
 ..._4031c16362137747717e9595cb5c8a15._comment |   10 +
 ..._0667f39f60bdaba6670f5b8304a8a77c._comment |   12 +
 ...S3_does_not_check_for_presence_of_GPG.mdwn |   19 +
 ..._copying_files_with_running_assistant.mdwn |   26 +
 ..._51e7afb030dfb3052044b0fa95e08bed._comment |    8 +
 ..._b9cc9ae227a6dd883a2324b6d70b88ad._comment |  111 +
 ..._15f4fc02d574a2ed55e683dd99e9b72c._comment |    8 +
 ..._c16ecf8fabd0c63a7b59927fe0bb6e2c._comment |   94 +
 ...p_ssh_keys_after_removing_remote_repo.mdwn |   18 +
 ..._88fbf70eae48484988dbb433a437c717._comment |   14 +
 ..._read_eachother__39__s_S3_credentials.mdwn |   66 +
 ..._e307e5d0ec02ed76dc7c3f0894770539._comment |   28 +
 ...g_when_a_special_remote_fails_to_fsck.mdwn |   72 +
 ..._203ebe6fa1bb8d3c6e7c0b948fc7dd6b._comment |   33 +
 ...sitories_still_use_symlinks_sometimes.mdwn |   36 +
 ...rectory_remotes_with_same_mount_point.mdwn |   55 +
 ..._351063bf8fb7779a9a7ecd21bef8b801._comment |    9 +
 ..._90351193c14f4c68f9b92640dae82f13._comment |   23 +
 ..._6b7727db8e2487394a80fc061d76868e._comment |    9 +
 ..._5a4b3daa0f8a0d7f330f5a1d922d0f6a._comment |   15 +
 ..._fb21865b36819a54a23e1ccb7f377fa1._comment |   11 +
 ...ing_remote_auto-enabling_not_possible.mdwn |   65 +
 ..._136c0fa106347bd0474f8298fde227f5._comment |   18 +
 ..._f6b1d513e664d1a5ee51b90f49731eeb._comment |   10 +
 ..._c2c7144fa74bdc455e1bd36b594902c1._comment |   12 +
 ..._4f3e9f15fcc96cd98c6915ec68cc471f._comment |   14 +
 ..._ccb5b6960da43a93ff0b7404190c51de._comment |   33 +
 ..._5b6359663efb608b9a78ab17c02be9ee._comment |   18 +
 ..._995b88efc83f76f14ccb22bc2a6ef4bd._comment |    7 +
 ...name_extensions_with_more_than_4_char.mdwn |   55 +
 ..._ecc9ff2bca0638797f358d5ff0d9e363._comment |    8 +
 ...te_descriptions_cause_confusing_error.mdwn |   46 +
 .../Empty_files_make_git_status_slow.mdwn     |   28 +
 ..._67662686361d345b3b82d1c80adc2452._comment |   15 +
 ..._39876be38934e9056e9aa2a9fcdeaedf._comment |    8 +
 ..._17b400bc03eb176f63009b9e01a862f4._comment |   13 +
 ..._d3a05649e8d7d5d62cc3e80ce0f45fe4._comment |   20 +
 ..._e2c9b041388685bb2ada57244c1735fd._comment |   11 +
 ..._d107491ed7ac97c4732dc96707defaf0._comment |   10 +
 .../Empty_folders_don__39__t_get_remove.mdwn  |    4 +
 ..._9f41638299c214b2ee13f23ab41349da._comment |   10 +
 ..._35f59adc30fe743221f29bbfecff639b._comment |   15 +
 ..._ccc703f8667805ce2886719c57e76ef8._comment |    7 +
 ..._ssh_server_with_multiple_directories.mdwn |   19 +
 ..._e8affeca873c2ef73255f8f77e0ac16f._comment |   10 +
 .../Enabling_useConfigOnly_not_honored.mdwn   |   67 +
 ..._4f0e4da06d8c9a9db771e593be1e2608._comment |   17 +
 ..._5dede8445ba1c20e9750a30fe29de0b0._comment |   11 +
 doc/bugs/Encoding_error_in_webapp.mdwn        |   24 +
 ...r_needs_to_escape_spaces_in_user_name.mdwn |   18 +
 ..._6b289221a65a750444b1b5850df3386c._comment |   10 +
 doc/bugs/FTBFS_for_the_2nd_day.mdwn           |   27 +
 ..._b7278de8f98c9fd96219281d61284461._comment |   29 +
 ..._05c93396766cb9ac6a596db679519718._comment |    8 +
 ..._0037f0e43383f32b22ee1ba2c98d78f8._comment |   15 +
 doc/bugs/FTBFS_on_OSX__47__Windows.mdwn       |   42 +
 ..._04e4ec83077eec6af8ce50d6f1b2c71e._comment |   10 +
 doc/bugs/FTBFS_since_yesterday_on_linux.mdwn  |   28 +
 ...ted_branch_update_after_error_in_drop.mdwn |   56 +
 ..._08b3eafdabe5f60ec2206584dff5d230._comment |   11 +
 ..._a947f8afde3d7f63fd33b0b7e5998e43._comment |   42 +
 ..._c8ce6c9fc35fa6ad5165ecf9a3592c9d._comment |   23 +
 ..._2a4de8981ced7894148ca9a68e5ef60b._comment |   15 +
 ..._7b989f777b211f21ca0e9ca681869bff._comment |   15 +
 ..._f9ef22fcfabc6445060b964f08080c76._comment |   13 +
 ..._f679af07b798cb4bfae75565dd46e8ed._comment |   19 +
 ..._c7c210961b51a87770932f40a9563622._comment |   22 +
 ...move__47__get_over_ssh_in_new_version.mdwn |   97 +
 ..._13252610f5b05251d1dcdf81f295ae7c._comment |   19 +
 ..._ae1807997fe2098f8534d23130039ae4._comment |   22 +
 ..._fcb4b6a62bcee4d2f70c58fb7f270b7a._comment |   23 +
 ..._f2fe8462292a4e80b5df4adeac20ee72._comment |    9 +
 ..._a769702d5d203eb435677bbd423857a6._comment |   10 +
 ..._8b18048e0ba4341ecef60787855cdac3._comment |    9 +
 ..._5c8ac4f42293240cacfb2edceada1a0b._comment |    9 +
 ...nect_to_newly_added_remote_on_Windows.mdwn |   22 +
 ..._on_windows___40__Access_denied__41__.mdwn |  132 +
 ..._fdad38ba9decc434e0d04a446f0a02e5._comment |   52 +
 ..._cdedb5512dc9c27a88632e963a27a389._comment |   39 +
 ..._to_get_small_files_over_P2P_protocol.mdwn |  120 +
 ..._72a8b9b6ed582dad36301cb9beece2f8._comment |   34 +
 ..._53970994816f1de9816e3496fdf0ef71._comment |   15 +
 ..._4c359c12d5c61351484dfcb2f5547222._comment |    9 +
 ..._1e286c1506fc542df85c6158a8ec3d1c._comment |    9 +
 ..._c667e4d4899925a5484c94256044f6ee._comment |   10 +
 ..._5ed6591954aeafe6c99ae152f4f4ad67._comment |   24 +
 ..._247db3d1c03b207296e97975a3554756._comment |   13 +
 ...om_locally_paired_annexes_when_edited.mdwn |   36 +
 ..._bdc97db9dc9954331e4c400baf9e5541._comment |   10 +
 ...rded_with_other_file__39__s_checksums.mdwn |  102 +
 ..._05e3e33e1ca2361546dbe08c6bd476d6._comment |    8 +
 ..._0735ed4187e23ddea6bd0aa408451942._comment |    8 +
 ..._06b7be9e651e528440a054ef43f7142f._comment |   12 +
 ..._bc9cf721f8087cb91954cc2435376bc2._comment |    8 +
 ..._8f0bbd819b95dfa97e2f4848e08a787a._comment |   10 +
 ..._17a0864cec6f28a0445998f3c5fc7f10._comment |   35 +
 ..._d480e85683f0418441f26c7d61c4af02._comment |   15 +
 ..._80763c1c40acdf0915134182d15e4fd8._comment |    8 +
 ..._7c3180616e40b49fc5ddf398d23d0201._comment |    8 +
 ...__41___views_on_a_crippled_filesystem.mdwn |   80 +
 doc/bugs/FreeBSD_patches.mdwn                 |   25 +
 ..._3473c3d4207a8387d962366dd1aa88b1._comment |   33 +
 ..._ba8df081ebf5cbbb5561aa48343e4fcd._comment |   16 +
 ...cognized_as_a_git-annex_enabled_repos.mdwn |   16 +
 ..._8a27545e11b3d9e4e45aea4c9a5c9af4._comment |   42 +
 ..._3e2f01eaaf717710a08ba092856af193._comment |   75 +
 ..._07460def4969896c87e8696955740fa9._comment |   75 +
 ..._f97de485f97d8016a5ab4e276799d230._comment |   36 +
 ..._cf4130cb932d3d884e605d7c6447e61e._comment |   15 +
 doc/bugs/GPG_passphrase_repeated_prompt.mdwn  |   25 +
 ..._6ef1c9725befc84ad57bce196ef630ef._comment |   16 +
 ...hen_remote_contains_non-english_chars.mdwn |  107 +
 ...Get_gpg_subkey_id_used_for_encryption.mdwn |   20 +
 ..._2cbdc33f22d18b8ea25473d361e591eb._comment |   15 +
 ..._81f2725bf6cfbef43cd9253a61eb7cfa._comment |   11 +
 ..._efae569e57322f263f626e330c64aac5._comment |   13 +
 ...ex_and_Microsoft_Office_files_on_OS_X.mdwn |   28 +
 ..._0cf11096ceeb6cf93db5609a42a70641._comment |   41 +
 ...kout_fails_using_--recurse-submodules.mdwn |   83 +
 ..._571703fc4e1e2f4e34f54db7a7da7080._comment |   31 +
 ..._9fe6b56ffda6d0c77ce65786514cd79d._comment |   20 +
 ..._fce2467a0442f98194fa11caffa466ad._comment |   19 +
 ...fails_with_absolute_path_on_mavericks.mdwn |   12 +
 ..._2f0c74aba502533b85b922ea81ded70d._comment |   23 +
 doc/bugs/Git_repos_corrupt_themselves.mdwn    |  109 +
 ..._74e6d17a1b14b2fdc7eddf4ee1895733._comment |  601 ++
 ..._d1f454482feef0350a6fa61bdf7673cc._comment |    8 +
 ..._5a13945d6bec6fa5fac84555f7ef8e21._comment |   21 +
 ..._6715bc3370f115f90627cfc4b06cf0e8._comment |   20 +
 ..._6234b04455acc0b2b2f22a1d8c2ab475._comment |   11 +
 ..._586e591a1e3cc53fd0108da91492c5c2._comment |   19 +
 ..._7a1cdfba17f129f6bf87a71549bbaab6._comment |   10 +
 ..._faaa433ba8df649771469fdbcd9bb69e._comment |   52 +
 ..._238bbbcabd626c33acc14f930a7d536c._comment |   17 +
 ..._c7fbc3da4404fb33a4b0babf068dc4d3._comment |   22 +
 ..._f2368358a0ccdd36a551a2c833cb9c9a._comment |   13 +
 ..._f7d921256107773dcb294747cdc38ebd._comment |   73 +
 ..._cf152fccbdb281dcbeb02cb398686ac0._comment |   85 +
 ..._652928a8f8bd0250973f19fa28cbb029._comment |   36 +
 ..._315606cfa07d2c4b20a6c9ec477c83d1._comment |   13 +
 ..._54aed251ddb9df1c8164a25240e1533f._comment |    8 +
 ..._a1131917149dd07ec73367e7cbc3b3f2._comment |    8 +
 ..._033def91d2a30f1cee498fabbfe5d37f._comment |    8 +
 ...de_archive_directory_at_the_same_time.mdwn |   18 +
 ..._e8bb3d6a2318402b985caed08282d473._comment |   12 +
 ..._ead9fa75a12ef36be9a92637b144e74f._comment |   14 +
 .../Hard_links_not_synced_in_direct_mode.mdwn |  130 +
 ..._aaa781664ae0c62c4f6530cb075ed367._comment |   17 +
 ..._213aa10909d1fd0f20ed078a7ed93e79._comment |    8 +
 ..._e6b783d9aaae20c0d35e9888d878716a._comment |   10 +
 ..._b008ae7b1cf8685d92c9a87a7609de1e._comment |   18 +
 ..._949c891209713a2c0a5e66af11ed4c79._comment |   14 +
 ..._12379a8e89ce8505123f5b24f3dbbaca._comment |    8 +
 doc/bugs/Homebrew_build_broken.mdwn           |    3 +
 ..._c30517144c98faaf592b0e8e2bcc7db4._comment |   14 +
 ..._d3f253a12a77fe4a354144880d0a4935._comment |    7 +
 ...on_Android_when_adding_RSync.net_repo.mdwn |  234 +
 ..._a7a613c3fa1bee42442a446366027381._comment |    8 +
 ..._97bf976e0e04fb27916e245eb9c7709d._comment |   13 +
 doc/bugs/How_to_git_union-merge__63__.mdwn    |   24 +
 ..._58b6c9712d7c209248d9ef87bcc0e110._comment |   13 +
 ..._22701b82e8d53acff66ddea5bf9448bf._comment |    8 +
 ...rate_the_right_key_after_moving_files.mdwn |  118 +
 ..._bbc1e7205d7701afd405c6e62a1c0aa3._comment |   13 +
 ..._52a1800537f1244ad6cf417c5f25ebe0._comment |   29 +
 ..._414bd487619e46b25e8d9a57d9aef1f6._comment |   17 +
 ..._81abd2627672911ba6367effbf5c487b._comment |    9 +
 ..._ce0342e38a87017ad58c9a79b17d759a._comment |   26 +
 ...an_existing_gcrypt_repo_in_the_webapp.mdwn |   23 +
 ..._17814787e333d15da3ab4e57c7d31d4b._comment |   12 +
 doc/bugs/Incompatibility_with_git_2.37.mdwn   |   55 +
 ..._c24657bb9d3b3072698572c4e75ccb5d._comment |   44 +
 ..._4d5eb77736e8512affc25e7bdd5190f1._comment |   11 +
 ..._889ece8b2168b20019253ab6dd5b0e48._comment |   16 +
 ..._95b8ea35cd10ac80e1d01b658e24d7a9._comment |   30 +
 ..._d0e60d224dd48d7c31adb6b250f662df._comment |    9 +
 ..._3bb6424838d4f8a971f3dce6d1b8dbfb._comment |   16 +
 ...ntent_has_changed__34___on_duplicates.mdwn |   54 +
 ..._b9491e9cb432ca3b8bdb08a00c89b346._comment |   37 +
 ..._cf9ce09377da2eae63ff41d07cb222d7._comment |   18 +
 ..._a99df351ed700f908b6aaf3f52d245b4._comment |    9 +
 ..._d370abe891d554577a9af7f959c9e3f0._comment |   47 +
 ..._68a3936700a02a17d0379d96880eea15._comment |   31 +
 ..._4d05a896fd57b55388fb21638ed02233._comment |   24 +
 ..._4a1248ea257c04f1afe233891a606eea._comment |    7 +
 ..._37eb9d35191bcfc0e7e4496f5720cbed._comment |    8 +
 ...n_synchronizing_between_many_machines.mdwn |   27 +
 ..._6d8f42446749f3e697af20626f22cf8b._comment |    8 +
 ..._3b4e529564488e732dd62569247b3d56._comment |   11 +
 ...address__62____41___not_allowed__34__.mdwn |   43 +
 ..._267b252368dca4803d706c70a3ef3244._comment |   29 +
 ...ia_the_command_brew_install_lib_magic.mdwn |   29 +
 ..._43614460d92cfac8a40ad2d6654926b9._comment |    9 +
 ...gument_saving_FreeSurfer_file_on_NTFS.mdwn |   95 +
 ..._181a319138cc10742bc8676d77e8a614._comment |   16 +
 ..._--time-limit__61__1m__39___with_pull.mdwn |   46 +
 ..._limit_uploads_to_an_S3_backend__63__.mdwn |   20 +
 ..._ef97e735ce308f7bcc03f5d9fda588bf._comment |   10 +
 ..._539b89de8743e435386b86119d1e982f._comment |    8 +
 doc/bugs/Issue_fewer_S3_GET_requests.mdwn     |    9 +
 ..._59a6b87d01c003bf55cde4c882e1778c._comment |   18 +
 ..._8fdeb3352ac00a76625ec9c007e5b76a._comment |   14 +
 ..._6ccbb1cff7bc6b4640220d98f7ce21c3._comment |   12 +
 .../Issue_on_OSX_with_some_system_limits.mdwn |   27 +
 ..._5fc1eedb5231edc37c87a2d9b91313b9._comment |   12 +
 ..._b14e697c211843163285aaa8de5bf4c6._comment |   12 +
 ..._18ddf8b5934dd6fb1676cd6adc7d103b._comment |   19 +
 ..._c25a8eb369e546f65e1a72d89f43066f._comment |   12 +
 ..._6407a3e7aa0316cba2994bfef0e3c633._comment |   37 +
 ..._f01887695e8b8386e125464c6d401565._comment |    8 +
 ..._c7776d5b2d073e0d2ae36515185c25aa._comment |   17 +
 ..._easy_to_turn_git-annex_into_a_zombie.mdwn |   25 +
 ..._d5fba6c061fb21795021ea83070dbfa2._comment |    8 +
 ..._12cba707239018989e8d5b6f456fa754._comment |   10 +
 doc/bugs/J1_display_issue.mdwn                |   13 +
 ...tadata_--batch_can__39__t_parse_UTF-8.mdwn |   91 +
 ..._1765400777911cc61eb591b76c84ae89._comment |   45 +
 ...40__ssh__41___fails_to_pair__47__sync.mdwn |  177 +
 ..._bab9cd5bdcffec3c48b9e8657cd9bbf7._comment |   14 +
 ..._104898dce3c67c082a9f2b36e2f45ff8._comment |   10 +
 ...Location_change_of_remote_DNS_ignored.mdwn |   28 +
 ..._449bfb3a594f99cf5e71a6e18d6d3dbc._comment |    8 +
 ..._b097dec73d4965f62c61003ed27e4209._comment |    9 +
 doc/bugs/Low_disk_space_corrupts_state.mdwn   |   61 +
 ..._d8235498e2206c3b5284455e5c4182b9._comment |   20 +
 ..._0e47c63a48e10ae760754df0ce165388._comment |   17 +
 ...chive_folders_not_working_as_expected.mdwn |  126 +
 ..._c8ce2a1978fc1bfa5f31cff9f48690f6._comment |   57 +
 ..._cf9a679c7e6ec5cae4109e748b20b8f9._comment |   14 +
 ..._4026607087a9da2759f841e59aadfcdc._comment |    9 +
 ..._45c1e00e64f916ef8a5f9200144861eb._comment |   37 +
 ..._9501e259e7d813545ff9cfdac22748f6._comment |   37 +
 ..._6c42b7b4c53d2bd547d5ba8d2a3b4c9e._comment |    9 +
 ..._660bf8f60d340feca469cfd4e28b7e43._comment |   10 +
 ..._06c95f066ffc844b0e1e4b4c16d30da8._comment |    9 +
 ..._ab4b7a243f9d1dfddf1c2c2609863d99._comment |   10 +
 ...ot_picked_up_by_the_assistant_on_OS_X.mdwn |   24 +
 ..._75c14b405929a8f771a7c261dcc4b7a2._comment |   42 +
 ..._f52483415c623ea0649c3805728ce761._comment |   35 +
 ..._fd73fbeef61df106f084ac235fca904a._comment |    8 +
 ..._c5e9843a956984efd22bad629930f6bd._comment |    8 +
 ..._40__can__39__t_even_HEAD_files__41__.mdwn |   69 +
 ..._2a1c20b432dd839e0153827e151fbbc0._comment |   17 +
 ..._c227071f23a96ed9928f128e7f77e503._comment |   17 +
 ..._5ac676877feaa7cdb9e05d6b71b1a4c3._comment |   11 +
 ..._3853bebdfcb7dac647edefd6f55ba8d5._comment |   20 +
 .../No_viable_build_plan_for_ghc_9.2.2.mdwn   |   86 +
 ..._8e7f9605f05880899eba7eae4e6f7ea0._comment |   13 +
 ..._e30befdadfd7989de2e214b8e1f6ed07._comment |    9 +
 ...ge_conflicts_while_on_adjusted_branch.mdwn |   74 +
 ..._77c241c5d61b62b1fae552145c6c94ef._comment |   12 +
 ...ed_files_being_annexed_and_not_stored.mdwn |   18 +
 ..._ef6c2dee191e80a46e348c78ba054fc2._comment |   19 +
 ..._6d73b11c55e7b2ed4003e1908558426d._comment |   10 +
 ...Assistant_will_not_automatically_drop.mdwn |  172 +
 ..._9a3a594f983048a9035f385101b394cf._comment |   20 +
 ..._7901e1211ab86429ef8bd95c72ed89f5._comment |   10 +
 ..._1ba89b95a028ba4a84b22dfd983049fd._comment |   16 +
 ..._704ef9c0ed78a00030f7d4d151ecbe5b._comment |   12 +
 ..._47aa5de003b409d3d2a4c58a0f08a14a._comment |   45 +
 ..._69781b2f00afe6150bc5997335b8af90._comment |   17 +
 ...ant_leaves_repo_in_inconsistent_state.mdwn |  151 +
 ..._0dfd9eedccb48f1f3d7939677dc96446._comment |    9 +
 ..._5c5e7356cae8ddf8d2c8964fb69000f5._comment |   11 +
 ..._1e0841d71c33fd3919310f1711b6e0b4._comment |   12 +
 ..._eb5b0f8259d861000510fcfd58f66617._comment |   16 +
 ..._4343ee35e4091fc50268f9fc611f5148._comment |   10 +
 ..._58___Pushed_changes_are_autocommited.mdwn |   88 +
 ..._ff7fc340c34297beb913e8cba5af052b._comment |    8 +
 ..._fb72d7dc7b56c6166c557aa03b951eb1._comment |   10 +
 ..._8420ed892366eb78a874eec793eaa38d._comment |   24 +
 ..._5def2bf7430c4cba0c6ed154e75c967b._comment |   12 +
 ..._72c7566677b4c2f212bddeca49262181._comment |   10 +
 ..._13ad56d86b5bdbaaacdad5b31347551c._comment |   12 +
 ..._download_new_file_after_initial_pass.mdwn |  119 +
 ..._3feba4ba84efb77bd4f8f46b6b4600f1._comment |    8 +
 ..._a33fcd088e419d8e6c459e42f21f8bbe._comment |   10 +
 ..._47196f7e781137751ebd1a1d7083838a._comment |   18 +
 ..._672d98ee06e051430f8e01faa93bb4cf._comment |   28 +
 ..._06fb3031b838cd443326f4ecd689b600._comment |   10 +
 ..._42d447400c15acf6ca031d165b2c781c._comment |    8 +
 ..._edd7d5d5c761ff665840f0ef7bea50c9._comment |   10 +
 ..._18e5334ab89efcf89ba8847436d55065._comment |   13 +
 ..._35b2bbdc24a7bd686527cd1839dee7d0._comment |   10 +
 ..._a771c6b453e6a4b3895dd69a53093440._comment |  246 +
 doc/bugs/OSX_case_insensitive_filesystem.mdwn |   56 +
 ..._2e81165ac03e1d0566c81016e7728ee6._comment |   29 +
 ..._4472d5db7a1cf7242077184912e32e17._comment |   10 +
 ..._4be758c2b70c0aadfe4fc9ecff8e4522._comment |   10 +
 ..._0b0c95a902718dd4e0976bf4e2cf265b._comment |    8 +
 ..._2123944418123c3aaf187d34df5c11e0._comment |   11 +
 ..._f82c803d725829722842c6d54e388719._comment |    8 +
 ..._45e0178ce9598d086f34a89701536eb5._comment |   43 +
 ..._3384bca070d84220efe166a398eed8a4._comment |   17 +
 ...droid_removes_files_and_creates_links.mdwn |   45 +
 ..._a15eb9cd1a7bcdfa4b16459ef978a019._comment |   19 +
 ..._1c061621f0abe435182d763cd871f405._comment |   15 +
 ..._package_update_from_2014-06-30__41__.mdwn |   93 +
 ..._7508685b6f676c72e316642b80e40ee8._comment |   10 +
 ..._c4dd12ea578d1f07464e1b9d68ec96cf._comment |   20 +
 ..._8687c1d1c44d88a8ac13208273565d6c._comment |   37 +
 ..._62be3dd4092b15cdf85cf9a231b2863a._comment |    8 +
 ..._cca4905426a3e01da6e12be855c7a418._comment |   27 +
 ..._ae2ca07169321c4a51b7e8e581fda5e2._comment |   72 +
 ..._ae5c434a9c94aa000b604095f52e3d3c._comment |   14 +
 ...use_a_USB_disk_annex_created_on_Linux.mdwn |   18 +
 ..._f224f4155d857a59595658357f97dac1._comment |   12 +
 ..._a_unix-style_local_remote_configured.mdwn |   22 +
 ..._95655915ff6ba9fb5d873358ff047496._comment |   10 +
 doc/bugs/One_Client_Not_Syncing_Content.mdwn  |   54 +
 ..._b8c8a9d10a12b72ea828b6b35d87fa5e._comment |   14 +
 ..._59921abb184bffb5ac1656cc50054e11._comment |    8 +
 ...-from-anywhere_not_recognized_in_copy.mdwn |   48 +
 ..._92bb18a7a50cf3dcbca75f544d7a0acf._comment |   21 +
 ...ch_digest__58___gcrypt_with_assistant.mdwn |   24 +
 ..._9d4fdddd7ab05de9dfa4cc90f1051ef5._comment |   17 +
 ..._bbd8b537e277d24df254ed058ad40e24._comment |    9 +
 ..._5090e41cf96dfe542d1d2326aebc556c._comment |   20 +
 ..._2bfa76c4083ff9c1d2a4adfe38ced2f0._comment |   10 +
 ..._2274479a1eef9ffc6a53ffb65e2c3511._comment |   52 +
 ..._e8deee63316c8af39d7cf0996d26ecba._comment |   34 +
 ..._2139bcb34591be137ff3da959f08bc76._comment |   23 +
 ..._7fcd45354f94756c34b2f3f912972c19._comment |   32 +
 ..._bf61defadd3be9bc867be961b3149be6._comment |   19 +
 ..._8a8ead857917e7b843f1bdfe07b5d52d._comment |    7 +
 ..._2432df64f920f3962b6ba02adaa9b61d._comment |   15 +
 ..._536fbc38a7f2e7ab42188b5a8700e2cf._comment |    7 +
 ..._f45d09939527be362c586ae1d470afe4._comment |    7 +
 ..._88178fa312f351a7667b3b2c48335b02._comment |    7 +
 ..._cd6a850119dd1aa0d9bb34c6d8fe560c._comment |   11 +
 ..._39139e25175ae265a4dc15f0b6b7b618._comment |    9 +
 ..._16c004fe7c77cbbba113787ce6410c9e._comment |    9 +
 ...mment_in_ssh_public_key_ssh-rsa__34__.mdwn |   23 +
 ...tive_symlinks_in_repo_don__39__t_work.mdwn |  123 +
 ..._d7ca8767953e1ec06740727a0eda4697._comment |    8 +
 ..._c4e6ab98e88add01eefe545551b12929._comment |   23 +
 ...lename_encoding_breaks_Android_client.mdwn |   34 +
 ..._1bb8e3f3a3d190ed557302df8b8e0335._comment |   16 +
 ...n_Android___47___Termux_not_permitted.mdwn |   38 +
 ..._093b92c3a751d32600958f34c3f2122d._comment |   24 +
 ...ide_of_git-annex__41___shared_pgp_key.mdwn |  387 +
 ..._c8e7be58222afff2a4c1df60f657d2ed._comment |   35 +
 ..._720dbf9d959a0050a159713cd1386913._comment |   11 +
 ...pecial_remote_includes_unwanted_files.mdwn |   26 +
 ..._a9d43aaca191a2ea464d13bcba6cd31d._comment |   10 +
 ..._44143f10ac80a979513477fbac2637f3._comment |   15 +
 ...peration___40__handle_is_closed__41__.mdwn |   42 +
 ..._ab1e86667225a0174a4e19210778f97c._comment |   63 +
 ..._cc207e43757c44b4e749488b563fdc87._comment |   15 +
 ..._7cdef9cf264f1b11cef7cea3accf112a._comment |    9 +
 ...tween_watch__47__assistant_and_addurl.mdwn |  195 +
 ..._8f56b8661a600729d7a9d569e8a0ba70._comment |   55 +
 ..._46dc67bdcd174cd50ccc421ec56735ad._comment |   14 +
 ...dition_or_double-locking_with_pidlock.mdwn |   59 +
 ..._bd92615c640ff017cd8a2ebfcc117a37._comment |   27 +
 ..._6db20a7c8ddde72cba76240b3f7faddd._comment |   11 +
 ...eating_remote_repository__39__s_annex.mdwn |   34 +
 ..._9fffb1329a4a06111cf2afd8552aea62._comment |    8 +
 ..._b7f5634e136294ea1a3d4ce6de58fc5d._comment |   12 +
 ...ote_in_the_filepath_with_rsync_remote.mdwn |   49 +
 ..._53d3e78c0fb4d4c398dd47498e6348aa._comment |   10 +
 ...positories_have_to_be_setup_encrypted.mdwn |   28 +
 ..._95f73315657bc35a8d3ff9b4ba207af0._comment |    8 +
 ...bapp_on_debian_stretch_not_responding.mdwn |   16 +
 ..._e2a0d0f458d263eae15640f36d59f071._comment |   59 +
 ...e_cannot_be_reactivated_by_the_webapp.mdwn |   30 +
 ...ipulation_breaks_git-annex_drop_--all.mdwn |   58 +
 ..._22fb9214e6e31d04b0ffe3266d26ea69._comment |   28 +
 ..._fac648fb7550f0c3c433ce423e3ea7f6._comment |    8 +
 ...bility_to_specify_pull_commit_message.mdwn |   26 +
 ..._6d581ea36afab3829cd56d6d6b83c6f3._comment |   23 +
 ..._bdb4b0200ab9d7c15454a2f3fcae474c._comment |    8 +
 ...19.16_still_causes_trouble_with_Win32.mdwn |   94 +
 ..._7fc0ffa7787353cf40fff0bc8da43c1d._comment |   10 +
 ..._0b96112c5d57886add62d79e7bf6044e._comment |    9 +
 ..._79cafc76eb23e54ff70c72c2f528e724._comment |   18 +
 ..._07f1b2eacf7e9e58809ee44fc1d6b574._comment |   17 +
 ...19.33_still_causes_trouble_with_Win32.mdwn |  426 +
 ..._dcc2067ea1bc26510d013ca52096513f._comment |   17 +
 doc/bugs/Resource_exhausted.mdwn              |   45 +
 ..._bccf9528ffe963154c92ce49762e7ea6._comment |   10 +
 ..._24ad3a76a25a787ac59e2c5270709e72._comment |   12 +
 ..._1943ff77f3bccf885229ecc10c82399d._comment |   12 +
 ..._c3cac0717232e04e89df62efa1db0870._comment |    8 +
 ..._a5ef7a62d4ed9365f9448520bb17e3b5._comment |    9 +
 ..._cdba2015e603f3c21f3e1697dd6fafcd._comment |   18 +
 ..._747d16d050fdcf69dd3d2bc5ca469a2e._comment |   39 +
 ..._1e9b74e60da57c3d5f08c1eb3801c1d2._comment |   10 +
 ..._f55d933bce77fd2185ebd0cc46fe57ec._comment |   64 +
 ..._26c98fca45b029a527f9684873db4be5._comment |   18 +
 ..._8bab413b472f900e04977db2bc3951b6._comment |    8 +
 ..._e9bec0b80179b1229b6af0979a21c727._comment |    9 +
 ..._419e24e0b91f569294ece28c42daa246._comment |   15 +
 ...unavailable_when_running_enableremote.mdwn |   23 +
 ..._14a5135c2e822129972feb570e453bc8._comment |   10 +
 doc/bugs/S3_ACL_deprecation.mdwn              |  158 +
 ..._07d0d382b88426180e77bac962306f44._comment |    9 +
 ..._63b541a937cb34cc4c68504e00dc3fb8._comment |   29 +
 ...ote___8212___un-embedding_creds__63__.mdwn |   34 +
 ..._336e1c2a5c2a367cba0ad74896b3895b._comment |   19 +
 ..._282aaaed5e95e8062460f94ac3a68dea._comment |   14 +
 ..._07fb8558238285883d11d8805884bdae._comment |    9 +
 ...S3_remote_errors_with_garage_endpoint.mdwn |   33 +
 ..._ea7a56193439eb63ad45074bd40f4ff5._comment |   42 +
 ..._1d5b499a0cea623aadebf7e3b7fd9752._comment |    8 +
 ..._ca7ffa315cfa49e028fe6ff2d5c3133b._comment |   10 +
 ..._ae9308a3bab8904dd0f501cbe2f09de0._comment |   43 +
 ..._f17018fbc7a8205a3ef0bdea74069fb9._comment |   53 +
 ..._fb7a448a2a4231b08277741805c12c76._comment |   42 +
 ..._513bdbb6595612432fd4f33bd8e4e737._comment |   45 +
 ..._131eb46d499d29b124c576653796e270._comment |   16 +
 ..._d8cdf46fb8de877ea167d14a055813e0._comment |   17 +
 ..._3d2033edcd49e62045339e341996fd28._comment |   10 +
 ...emote_support_for_DigitalOcean_Spaces.mdwn |   33 +
 ..._12fd9dfb47e157e1d38c5e88a543498b._comment |   20 +
 ..._3bbdf23c8a4a480f4f6b8e8a2f8ddecd._comment |   13 +
 ...led_when_copying_to_remote_repository.mdwn |   82 +
 ..._4578b04c1cfc46849e9440f257f49303._comment |   17 +
 ..._a953d5506f30cf19fe97c6ece155b45e._comment |   22 +
 ..._5b2956522ce9c9cdc0c704e63efe8dac._comment |   10 +
 ..._3966cce3267fe134f5c9c6b05e1149b5._comment |   16 +
 ..._0c0aec23302afafffc0f69d1bd89ad8f._comment |   19 +
 ..._031f049fdc2c284303e9db42071ebda7._comment |   10 +
 ..._3d4a7d330d80060275c34d0a13416fb7._comment |   78 +
 ..._1501223d25a03c27a7ceffc6b0ea32a3._comment |    8 +
 ..._192c219b32c95954ec6400367474dd78._comment |   13 +
 ...L_repos_does_not_show_up_in_Assistant.mdwn |   27 +
 ..._5a8e599d6e22e7c1960bd1715666657b._comment |   17 +
 ..._2ad5098c5e2ac9b8651cb464adb974c1._comment |    8 +
 ...rtificates_with_jabber_fail_miserably.mdwn |   26 +
 ..._13d27ba41d9ef78c8db534b6bc26314e._comment |   12 +
 ..._018eed99e71680be9e7c0844020419bb._comment |    8 +
 ..._1e7578dd1321f399b12197056495b0b6._comment |    8 +
 ..._a1948b7cd6ea990c8f1be5e483c835fa._comment |   14 +
 ..._293b333134c97dc666a825cc7a8b2b62._comment |   12 +
 doc/bugs/Share_with_a_friend_fails.mdwn       |   52 +
 ..._d3ba5f786c45e677ea9a7b4a7b36e1a9._comment |    9 +
 ..._1d5568c00a9b11a05b7fde0d2d3bc327._comment |    9 +
 ...en_network_fails___40__esp._DNS__41__.mdwn |   50 +
 ..._dd792bd98a48554a65150c06401ed3e5._comment |   12 +
 ..._function_throws_error_with_git-annex.mdwn |   43 +
 ..._6fd91f615e8d5212674a9748d1b4135b._comment |   12 +
 ..._3dbaf39065c2f0941f8f7092c27fd4cb._comment |   16 +
 ..._996139be157e23e17ece9f131b17240a._comment |   12 +
 ...git-annex_with_encrypted_rsync_remote.mdwn |   61 +
 ..._4038261a4d49694374c37ff029d3540f._comment |   20 +
 doc/bugs/Stress_test.mdwn                     |   45 +
 ..._1694e990eab6592159309c231c6dcc16._comment |   12 +
 ..._ab4cb6eefd279e6c1f229e089f703581._comment |   25 +
 ..._c4c764488ac082f5c48d3a6b4b5fba42._comment |   17 +
 ..._42125bba09a0ea9821cda7183e458100._comment |   47 +
 ..._8240e61106b494d3600ad91f16eb5b1c._comment |   20 +
 ..._c38d84e0dcc834931804c44bce7f7b7a._comment |   11 +
 ..._60ce20ee255451c4ea809ba475561adb._comment |   15 +
 ..._1371562e201393986cd41597f6f288cb._comment |   14 +
 ..._a14be7699da224a8f6c9b34f1b911219._comment |    8 +
 ..._a01995bdca7ade7dde9842b53fbc4e0c._comment |   57 +
 ..._9f7efe81b7e40aaa04a865394c53e20f._comment |   52 +
 ...l_configuration_of_tor_hidden_service.mdwn |   23 +
 ..._643a8e22d6ffd27a5497c077e4ce3bcd._comment |   17 +
 ..._90deb38d083cfac454bf364884ce06c6._comment |   17 +
 ..._59fe23f38b4bb70e629b0c7c698d1438._comment |   17 +
 ..._20c00e22eff7cb5a5f907895bf4b0b44._comment |   11 +
 ..._7e6e7c0ce27504273be3e5bc27685d93._comment |   13 +
 ...0_Creators_Update_with_Developer_Mode.mdwn |   26 +
 ...ails_when_borg_remote_is_inaccessible.mdwn |   83 +
 ..._5e83630a60aa0242969bd1279a70628a._comment |   17 +
 ..._eff73163e8a7ae09ceeb596fca04c507._comment |    8 +
 ...__t_work_after_using_watch_on_Windows.mdwn |   93 +
 ..._e197b8dc0eae0dd6dea4febdc2ecce53._comment |   11 +
 ...n_in_recent_versions_of_the_assistant.mdwn |  134 +
 ..._8100505a7ac74646e0767d03fe643a45._comment |    8 +
 ..._9833e8f77c6148db9572316066a67eee._comment |    8 +
 ..._1504f8767f1f4415222d8c315c734e81._comment |    9 +
 ...__timer__95__create__58___Bad_address.mdwn |   58 +
 ..._8ce2cbdf5b5c31fd42b0ed270c54a824._comment |   23 +
 ..._1316ea67dc7df8d3d6f681ac3caf6d3c._comment |   12 +
 ..._0e098ee460a0ad70dbe34d74c5e9bf3b._comment |   44 +
 ..._64fd17f3537fec02f8356e535a1d0bb4._comment |   21 +
 ..._dacfb426f7e67e984bb9281a40427e85._comment |   26 +
 ..._c85f2c69aa2cff05859e92afc95e9ccf._comment |   45 +
 ..._e8c76f8b9645733a793676dc274744ef._comment |   14 +
 ..._902afcef5ad9c3f2a80d5df1ce99e1d5._comment |   62 +
 ...k__95__gettime__58___Invalid_argument.mdwn |   22 +
 ..._5277a05a17b348a1be80845e697c018c._comment |   10 +
 ...ompat.User_removed_in_unix-compat-0.7.mdwn |   60 +
 ..._cd573b785b7d7feec72387cb0dafdcab._comment |   10 +
 ..._6b15d11b6e25689e2430663a4aa90168._comment |   10 +
 ..._locked__58___rsync_remote__58___FAIL.mdwn |   43 +
 ..._809ca8b986ccadbc3940cc795d1823e8._comment |   15 +
 ..._0327663314d2a8b2f0cab7536fdaa6bd._comment |   32 +
 ...__59__58___hGetLine__58___end_of_file.mdwn |   50 +
 ..._a1392b92efdff82783a4b0cc2c3c7f2f._comment |   14 +
 ..._5e153b7c59c474988fe551a505e545bc._comment |    8 +
 ...ansfers_continue_after_daemon_stopped.mdwn |    5 +
 ..._39eb527d64367e6762281246f1d49b1f._comment |   12 +
 ...oad_to_remote_although_remote_is_dead.mdwn |   51 +
 ..._108b3984891f82429430b503cddfb3c1._comment |   10 +
 ..._fa5b1bc26ed3e5bfe48441490c94fe3a._comment |    8 +
 ..._0a785b5dfbf4eef30854d6bedb12b7d1._comment |   10 +
 doc/bugs/URL_key_potential_data_loss.mdwn     |   32 +
 ..._a921dab2c4335f690df4d5189fe4e4c2._comment |    8 +
 ..._0c9e7b8e00db92e8d638328f0390f6e9._comment |   29 +
 ...le__58____47____47____47___on_Windows.mdwn |   68 +
 ..._c4cfa1d0f90193b127722711285e1210._comment |   12 +
 ..._ff71a541b3df8bb272e576c856b3aa9d._comment |    7 +
 ...iving_files_with_git-annex_to_glacier.mdwn |   43 +
 ..._f68d5ad86d67aa73074389cf9a21469e._comment |   22 +
 ..._f0f1f18265ebb83caf4e6f1fb23ec876._comment |    7 +
 doc/bugs/Upgrade_impossible_om_Mac_OSX.mdwn   |   22 +
 ..._8c1487635f724d017ebe2f8b7bc10e8d._comment |    8 +
 ..._84e52a4d1502fd622bdb25e04b459292._comment |   13 +
 ..._f2b109f6cf92f101d7f0afeb91605240._comment |   24 +
 ..._df9b111aefea82b9d108495b79d7ffb4._comment |   24 +
 ..._e3b5bc815376383bbd1f312cc1c32a41._comment |   12 +
 ..._cd9b77e6670840a9902f5be80e1e658a._comment |   87 +
 ..._4584393333d377532d8607b42319abd9._comment |    8 +
 ..._d9d36ff62267dde98a27c5981951df7f._comment |   10 +
 ..._5b26711c737eeb0b302060f098cb320b._comment |    8 +
 ..._1bf050056dcac7c1e0f497ee6e87a95a._comment |   10 +
 doc/bugs/Upload_to_S3_fails_.mdwn             |   59 +
 ..._b7e912bac673bdffa5775b71d5d39937._comment |    8 +
 ..._65cb9b1dd69cd657f2cfde036eb60417._comment |   11 +
 ..._398c014921f9af957fb5e9a92ed0ef4d._comment |   10 +
 ..._f33ce058c9460cf7d151e739bff0440a._comment |   10 +
 ..._cd1e768fe1e67daf08b5afd460620922._comment |    8 +
 ..._0cdd2e8d6e83c03de717ecd3253e753d._comment |    8 +
 ..._020c055f6c06860dda27c1debb123742._comment |   43 +
 ..._8bc023fca8cedfc517856cdcd20b7f10._comment |   10 +
 ..._32685258748a7cdd177e7af2105f128e._comment |   10 +
 ..._841fd94d0f599c71a76fd22b07944366._comment |    8 +
 ..._dd837a1cb2146224b9c000cbeea4f3b3._comment |    8 +
 .../User-Agent_not_sent_with_S3_remote.mdwn   |    3 +
 ..._68fd5b6a69d90bb9623740752a918657._comment |   12 +
 ...s_to_build_on_Win___40__imports__41__.mdwn |   96 +
 ...y_limit_on_max_filenames_in_directory.mdwn |    2 +
 ...S3_tree_does_not_unexport_git_objects.mdwn |  399 +
 ..._70428ebc4027538253edc483dc5cb971._comment |   50 +
 ..._059b9beb31d9cbc97ea4a59f47d2e63d._comment |   19 +
 ..._176cbc137afb5cf8841ff9114b111fef._comment |   17 +
 ..._a6490af0427bbe4363bea824d55a7593._comment |    9 +
 ...t-annex-add_fails_in_DrvFs_filesystem.mdwn |  123 +
 ..._6b54cc0a268885570170620222b774d7._comment |    9 +
 ..._5634af4cef0d0fe0d2affe40d9c0d5ea._comment |    9 +
 ..._816bae469b0341c6dae2316050a95ad5._comment |   23 +
 ..._ab64e43330e466482f30487b8bd13bbf._comment |   24 +
 ...ite_thread_crashed_-_locking_protocol.mdwn |  125 +
 ..._93c9d3ea6d7a1f2d035f8a52c81790ad._comment |   71 +
 ..._94d00ed84dfebebd7889fa861172df61._comment |   46 +
 ..._76f765e3befd5e263a8863b56cad139b._comment |   45 +
 ..._5e08dcb7e40e7fbcb22425b3ff8b0610._comment |   42 +
 ..._45b1da34ec60d6322477edfd6a3a2bba._comment |    9 +
 ..._0bcbce94586ef96c2dcbe5ef9da4ac6f._comment |   19 +
 ..._bdb3cadf29facd4729120a6cd057b8a8._comment |   18 +
 ..._2a9f0396df93d9500306b3d7039803a2._comment |    8 +
 ..._da42c839f96314ed8c5ad646b614b75d._comment |   26 +
 ..._f8ee3d06a79bdc429a114b5256290206._comment |   17 +
 ..._b7a3837fd6af236e9ecf6d5bae077fd0._comment |   25 +
 ..._276be047d18b2e20a8e3114abe3132ee._comment |   36 +
 ..._cb7ce88ae3d77b9ba0a4e33c2321a3e1._comment |   20 +
 ..._b0700fdf101f6cc883857b293cd35267._comment |   23 +
 ...8___openTempFile__58___does_not_exist.mdwn |   10 +
 ..._9892f6b80597f0b637aeb96d212164d9._comment |    7 +
 ..._687a9fd1c0b760dd2bef9647cd16175c._comment |   11 +
 ..._1ef917c10f944e6c874aa40affae7602._comment |   11 +
 ..._47__storage__47__sdcard1_-_bug__63__.mdwn |   45 +
 ..._71b052be40fbdaca09ca3ede8c59ac7a._comment |    8 +
 ..._0f7cc02e0193c969c9b6ceb27e71af8a._comment |   20 +
 ..._1a7542249b9c37507126e97441057c12._comment |   12 +
 .../Webapp_won__180__t_start_on_MacOS.mdwn    |  315 +
 ..._0a8b46efd3f6b7c9f818fc64af9a5f4f._comment |   12 +
 ..._7eb9cf2b8c7192ae654831cdc0c00253._comment |  283 +
 ..._069b107437b6456d027c8d97bc708d48._comment |   12 +
 ..._1e944c517796ca29f8870fcf76c9a0d4._comment |   20 +
 ..._2c7d2e81cbe943fe9154830fdf958181._comment |   16 +
 .../When_--git-dir_is_not_in_--work-tree.mdwn |   52 +
 ..._handle_files_with_2_dots_in_filename.mdwn |   29 +
 ..._43f6de166d1811e9f9bd6e6d8b152e05._comment |    9 +
 ...e_it_is_being_used_by_another_process.mdwn |   56 +
 ..._79c57a6a8c0b100c07d014d8d2b862cb._comment |   13 +
 ..._6242b7aded8b221aba8a5e3e4374238a._comment |   61 +
 .../Windows__58___git_annex_get_failed.mdwn   |   90 +
 ..._0866038e64aa20c3b9ba3b3190074293._comment |   20 +
 ..._22809831226478bac7f9361ad8d0c79d._comment |   10 +
 ..._8a19ca100d44ab8131e40932f1bcdf29._comment |   10 +
 ..._b70fa3da7e776a6cd6d8467df30839c9._comment |   35 +
 .../Windows__58___support_NTFS_symlinks.mdwn  |   28 +
 ...ailed_to_read_sha_from_git_write-tree.mdwn |   46 +
 ..._5829b551f5e1413ee236055eb3345760._comment |   15 +
 ..._535016130f3307c8104168e6bb8a583d._comment |    7 +
 ..._79c66569c22a1280b807a3c21c2cdc4f._comment |   20 +
 ..._2e5791aa8f568f86d0185a553227afa8._comment |    7 +
 doc/bugs/Windows_build_test_failures.mdwn     | 1234 +++
 ..._ea7523fdbafdc8be2971df52d9038826._comment |   10 +
 ..._and_wget__44___but_not_required_DLLs.mdwn |   17 +
 ..._a7bf0f027f2209e5632e292afd7214d0._comment |   10 +
 ...rmission_when_using_shared_repository.mdwn |   68 +
 ..._bfcb858bfd1c5377c2b15961b59a835a._comment |   10 +
 ..._e3c9e3b9004f1fe964b23d955083089b._comment |   11 +
 ...__58___resource_busy__34___after_copy.mdwn |   44 +
 ..._b05e0060d503a1d58c972796c5be151b._comment |   87 +
 ..._399dcbe7f3772526efbe13bd5b13156d._comment |   11 +
 ..._201c7dcd0e809cb2c22ab4b621079c71._comment |   62 +
 ...on__34___with_partsize__39__d_uploads.mdwn |   29 +
 ..._b3b767b3ab4a73590bf7e2af8640f906._comment |   25 +
 ...when_trying_to_cconnect_to_ftp_server.mdwn |   54 +
 ..._db2b9e26bc01abbc3312731b95cf770f._comment |   18 +
 ...4___during___34__git_annex_sync__34__.mdwn |   52 +
 ...34___special_remote_leaves_empty_dirs.mdwn |  116 +
 ..._8cef8650103d118fbbe56d20a4f59f96._comment |   16 +
 ...___44___after_add__59___cannot_commit.mdwn |   24 +
 ..._8abfe7417167df54b686960319465a65._comment |    8 +
 ..._7776659e257a97c9a3855c8ad008207a._comment |   10 +
 ..._e8bbfb4eb26dae31f90a5fa53b4dc948._comment |    9 +
 ..._aee32c53d2198ba1e82acd0c617d517c._comment |   10 +
 ..._f41116524fb7b423ff03c9440b5f278b._comment |    8 +
 ..._0f61544accba5002edef2bcd4131e69f._comment |    8 +
 ..._9dc2f74dc69ccf867ac4e68cc502fda4._comment |    8 +
 ..._0525b887cd75c183a34de0f486ec022c._comment |    8 +
 ..._fd55979b686b5f83ba2b95300abd1852._comment |    8 +
 ..._bdd9e29413f4407207efa01283ad68ad._comment |   17 +
 ..._2a64a2da445a64149da7335f35142a08._comment |   35 +
 ..._f12f7f14ef09fa765c78dbeef809da7d._comment |   10 +
 ..._3f2ce7b851392ad5285e95f3857d0959._comment |   16 +
 ..._94dc1d1485c3a380fe19dabe8f95aac2._comment |   17 +
 ..._decb1689b8cc2541077e2d0ae273b5e7._comment |   30 +
 ..._1f6443e495cc16a13e2e4175e73dc8f1._comment |   27 +
 ..._522020e71393434834def6c80b82e39e._comment |   16 +
 ..._cc4cba022869b32d298cdafed9545a34._comment |    8 +
 ..._e71b251db2ff1f52a40fec40303cdefc._comment |   15 +
 ..._0b6413f9ca403be3d83bb3306d1e7f8f._comment |    8 +
 ..._f951981f0bf8cbaecfc46e7b9c903d70._comment |    8 +
 ..._7c98c8b291fdf28a09ccb6c7e4001d5a._comment |   22 +
 ...spect_utf8_in_the_commit_author_field.mdwn |   11 +
 ..._6708d83b96b791e4cd829bb0a65cda6d._comment |   11 +
 ..._d28894bc233987f68159e8d1a7a97096._comment |   34 +
 ...ked_indefinitely_in_an_MVar_operation.mdwn |   44 +
 ..._a63994b33b651dccfd4d4cf946ab7170._comment |    9 +
 ..._2166a985e48a31c1b86cb77263f72ce2._comment |   34 +
 ..._17b96f95f44a04063f5a52d690d96b32._comment |   32 +
 ..._df73b69e651c728943a404223f350ebf._comment |   15 +
 ...valid_object__34___errors_cropping_up.mdwn |   91 +
 ..._d146a64ef8d76c2a7e45bf85d8943456._comment |   17 +
 ..._6585b15aa7ae63175482d08b2b5b79fc._comment |   11 +
 ..._973d90a6fde1c6f26fcf594610693fad._comment |   17 +
 ...it-remote-gcrypt_syncing_files_anyway.mdwn |   69 +
 ..._30a0a715fb9d8738e5ec53296375c1b3._comment |    8 +
 ..._b91f9337b7ed536539bb3236b7552d82._comment |    8 +
 ..._79268506a1653220ddfbb45f9c61d8a7._comment |   19 +
 ..._9c2410c55154bc8d9f733377cde58eb9._comment |    9 +
 ..._rename__58___permission_denied__34__.mdwn |   69 +
 ..._19de24208042d09572c114bca80f4854._comment |   20 +
 ..._e70c8b8192eb0f8868e52dc7a287e526._comment |    9 +
 ..._doesn__39__t_pass_testsuite_on_Win32.mdwn |  783 ++
 ..._7ac6938faef9111da701080a62c4d7e9._comment |   67 +
 ..._max_cpu__44___long_run_and_huge_repo.mdwn |   40 +
 ..._3233c29405da296360d57af7d5eb418d._comment |   46 +
 ...ssist__39___doesn__39__t_honor_--jobs.mdwn |   36 +
 ..._96b3c705c7c83b153cde2e8bb16ed380._comment |    7 +
 doc/bugs/__47__exe__47__git-annex.mdwn        |   51 +
 ..._8a9e9d83a3dcf07ed76a22f03636f6d1._comment |    9 +
 ..._381ac4e8b27343cdc470584c05edec76._comment |    7 +
 ...eta__93___ikiwiki_is___42__slow__42__.mdwn |    3 +
 ..._3afce2aadeb2221c66f397e631d0e4a6._comment |    8 +
 ..._220b3ed61dfcce4d6d33fa8516cd1ec1._comment |   20 +
 ..._8fb126d6583014d3e16137e9c18057e6._comment |    8 +
 ..._72204d0647ec808145b6838d5e621107._comment |    8 +
 ...adds_files_unlocked_instead_of_locked.mdwn |   55 +
 ..._58abf8693ed90fc8c6e3f750310c17e4._comment |   12 +
 ...o__96___hangs_with_git_special_remote.mdwn |   84 +
 ..._e3bc14a173600b86c5875d90228aea8b._comment |   25 +
 ..._9274223b32601ead9a508aa9852e4933._comment |   12 +
 ..._8f46a9d4a7ceae80e378149d88dd1f19._comment |   11 +
 ..._c3130a2595fc35525dfdbcc6cec57713._comment |    8 +
 ..._eeb4f35b7609cb36fdcece9b8cb94430._comment |   14 +
 ..._ee21d4d8b276a32b227199175ea30721._comment |   15 +
 ..._9104e12c57bc47cfd0a6c109ad085de1._comment |   21 +
 ..._c5b96e6c35c8969062489d6e03066f34._comment |   10 +
 ...__62____96___swallows_network_failure.mdwn |   68 +
 ...96__lookupkey__96___unexpectedly_slow.mdwn |   25 +
 ..._13003e3b46c5cfab60b6e34fb18731d7._comment |   14 +
 ...nger_to_get_file_than___96__get__96__.mdwn |  728 ++
 ..._43f5ed4a319fcf63387395f32a345852._comment |   38 +
 ..._d485bbc1c0f2fceaaa2e4142dccdc1f7._comment |   17 +
 ..._b0132b0f846e4882a5511b53694a1fa2._comment |    8 +
 ..._fa2fb2493ea1244f334b54e6af2b553b._comment |   73 +
 ..._ccd90a2ad9cb9c896a47d62ecdfc5304._comment |  121 +
 ..._c7e71722379431789f26b5e743e13d9c._comment |   13 +
 ..._f730f3593ab5aeac34e74ec48f943949._comment |    9 +
 ..._934ee22209920f8429c0ac71002bab1e._comment |    8 +
 ..._1611ef71978eeb61da4c42cffcff2411._comment |    8 +
 ..._6700aabc3b4cb02a5b370cf4c71c6a0c._comment |   11 +
 ..._a0b287e187396b7072e4d7bab3664621._comment |   31 +
 ..._0b4e0acecbcc6a8736849801446a189c._comment |   52 +
 ...branch_subtree_regression__58___FAIL_.mdwn |   14 +
 ..._2b2040240fe8f01a6348eb68959d9319._comment |   11 +
 ...6____47__gitlabname__47__reponame.git.mdwn |   36 +
 ..._60db0d6bfc71a62b3c1021527a8d2d60._comment |   23 +
 ..._49682a91147990a578929678880bd226._comment |   26 +
 ..._bf0fa06596338444a3772d1865b17e26._comment |    7 +
 .../acl_not_honoured_in_rsync_remote.mdwn     |   59 +
 ..._aa6fe1d7b029eae7ee71c97e0f0937a6._comment |    8 +
 ..._ffb9424e966ee10a4fe2d446b3042cb2._comment |   10 +
 ..._f93177593a2d90627672647fd5f065c9._comment |    7 +
 ...tes_empty_commits_on_import__47__sync.mdwn |   42 +
 ..._87efdd2a9c7091f92a6bc96e87a59e18._comment |   14 +
 ..._206d98a17319292d4de4c475a7b8d091._comment |   11 +
 ..._522c68d019e5db592e140db9501435ba._comment |   20 +
 ..._5000af944e3a7917a97b65fb7d1c5c3e._comment |   49 +
 ..._a9b3e07f180ab97f5025d7ce9ca58c05._comment |   18 +
 ..._4e9e55d54d9afb2dbb48320156757f11._comment |   24 +
 ..._d500b9ae8e3f57a2f8dcd2314c0022dd._comment |   73 +
 ..._aafa4a00a9579e54c3080586c1b7bb3e._comment |   29 +
 ..._f1e37aa68778408629c53c09f0a0857f._comment |   16 +
 ..._0a7f24a4567ff934cee37a4c0224f000._comment |   16 +
 ..._9b4d104a7255a7618221f9dbb410fdcb._comment |   16 +
 .../adb_pull_does_not_preserve_timestamp.mdwn |   44 +
 ..._b695826d1f948249b496c055b4d745df._comment |   17 +
 ..._2d49693c5f8d826f9a4b1cf2f8dca2c5._comment |   39 +
 ..._cf555d2f0f93248a913014f30ce513b2._comment |   25 +
 ..._9d5cbd2479a07d778bacfdfe0aaaa524._comment |    8 +
 ..._244a5803178b4e44f3ec4460c5daf258._comment |    9 +
 ..._77416807482416c552922d39a0319a65._comment |   49 +
 ..._216316d2db3a728837fd059587ad1928._comment |   23 +
 .../adb_remote_fails_to_import_treeish.mdwn   |   75 +
 ..._8012368012cf53e8552d7670b9b8315d._comment |   24 +
 ..._54867d63c04ee18c76b1d769db71bc00._comment |    9 +
 ..._5e819d0b5f3101e86f0f95a7ab725ad4._comment |   16 +
 ...replaces_symlinks_by_plain_text_files.mdwn |   30 +
 ..._bcc12b77c5069769ab04e448b23b3d85._comment |   11 +
 ..._f5db61aa7efb7a916d0ffebd563cc2c7._comment |   18 +
 ..._7346adcffb3d9056dc880dcf1e2ab03f._comment |   11 +
 ...te_fetches_but_does_not_add_all_files.mdwn |   21 +
 ..._31142cacafa0c975cd33a76c22f60bf3._comment |   22 +
 ..._09f5982e930a04c25ea3ce8caac449c4._comment |   13 +
 ..._3b4100037ee9180346ffc2240a34064e._comment |   12 +
 ...y_treats_files_in_dotdirs_as_dotfiles.mdwn |  103 +
 ..._263bfea4cae5a612de1761b3c3fc32b8._comment |   19 +
 ..._6fbd20761f9388c04fa13b38af2354d9._comment |   19 +
 ..._e8636243a3c98b11e54b6fa8617f9e32._comment |   20 +
 ..._27bf6cfce4f73a1d29a753e33c1e871a._comment |   12 +
 ...g_var_preventing_adjusted_branch_mode.mdwn |   62 +
 ..._d7ca1f4ccb4bc8a72788f6dcf8af9439._comment |   15 +
 ..._0c064717d0b85ff4b9df1bada7c6e7ad._comment |   13 +
 ..._1f4b1f2a32f11da4c9bba95f25dd45c1._comment |    8 +
 ..._0fb992fe4ef5ec14876d2d1912dca4c5._comment |   11 +
 doc/bugs/add_overwrite_race.mdwn              |   59 +
 ...kes___39__git_annex_unused__39___slow.mdwn |   87 +
 ..._d350c39c67031c500e3224e92c0029ea._comment |   19 +
 ..._b2d2b1caa51ffec3d87c36b373cb8d4a._comment |   20 +
 ..._12b20cbbc2b4cd1ab8af7e3eec9589b4._comment |   30 +
 ..._a50b43c15d2650df90f0fa1ced47f532._comment |   10 +
 ..._7328bc51bd001f2b732a92a2ae175839._comment |  114 +
 ..._880ef2ee797221332dbb629b2d55522f._comment |   10 +
 ..._826fd82cdf9b1c79c9b555ca26c2c176._comment |    8 +
 doc/bugs/adding_a_remote_server_fails.mdwn    |   27 +
 ..._cf7ea9171f002c5793a882b42d33a77d._comment |   10 +
 ...metadata_on_Windows_doesn__39__t_work.mdwn |   39 +
 ..._831dc2185919865d418b29cd06ef42be._comment |   42 +
 ..._88b7db5434a56c25c75772caa37bc14a._comment |    8 +
 ...ors_with__git-annex__58___user_error_.mdwn |   73 +
 ..._996a54315c21e1dcb94cca9576d1d5f7._comment |   20 +
 ...ve-filename_still_modifies_file_names.mdwn |   41 +
 ..._88c0a762e2a37f680f6a4419582eddac._comment |   32 +
 ..._386891c1effda6cae17d88eacbfa0daf._comment |   16 +
 ...cause_special_remote_is_not_available.mdwn |    1 +
 ..._7caf2377477495c08378755cdf45dec8._comment |    8 +
 ..._83a864a73f9c1c6bf86dc60b47a965fe._comment |   15 +
 ..._b0e9f373c3439b15a28fd20e9b0e24a6._comment |   51 +
 ...addurl_unittest_failing_under_windows.mdwn |   56 +
 ..._8f723e986d80754a8b68308ab8b15c20._comment |   10 +
 ..._e0bbb72af2852b2210bb1ce520e88f1d._comment |   10 +
 ...cked__41___does_not_honor_addunlocked.mdwn |   43 +
 ..._unlocked__41___not_syncing_with_main.mdwn |   65 +
 ..._e5ebc1cf8621761b559d53884731d0e3._comment |   23 +
 ..._149502c4d8fa2c50507e7e6e312f9703._comment |   16 +
 ...lot_of_files_are_reported_as_modified.mdwn |   57 +
 ..._8a355d509fb2005cfd9da8f2d4bb560e._comment |   23 +
 ..._ee707efce9c5537a1f7d0ffded952af8._comment |   12 +
 ..._0fcdba2f621c8c32f09b2633c11266ee._comment |    8 +
 ..._4719510b78d347f28a0fe8910c086982._comment |   10 +
 ..._05f178a19b8949efc5c6e189ff8fa5e0._comment |   10 +
 ..._ad4621b602e7632d74d58f1728b80cda._comment |   12 +
 ..._fcb259337b70b0d5c5e50c8facb845e4._comment |    8 +
 ..._1df979b8e222dd135a10046c51f0dc0b._comment |   19 +
 ..._5e3482024e20759f8d42e14598d4dc26._comment |   10 +
 ..._4e9f342281b01ecb9354a08200c04ab0._comment |    8 +
 ..._63af8f32512ce8ec07c48361317ce51d._comment |   15 +
 doc/bugs/android_sync_messes_tree.mdwn        |   39 +
 ..._a90afb9011c760843836728d03353619._comment |   14 +
 ..._90d589053c4d1b646edd07978999d001._comment |   45 +
 ..._f964c18aced83ba02d3436941dbcbacc._comment |   30 +
 ..._1f819796ec13f83e56917332efffe54d._comment |   22 +
 ..._7fda943808cc1b7155c1223fea08e8df._comment |   15 +
 ...utocommit_seems_ignored_for_new_files.mdwn |   39 +
 ...upt___40__not_just_missing__41___data.mdwn |   11 +
 ..._d02a1e53cb95b0cb3c4330c668bcb15b._comment |   28 +
 ..._a6806787dc0163f67dc141415c951add._comment |   20 +
 ...s_before_moving__58___stopped_working.mdwn |   70 +
 ..._b3c780a6f888c8afc3bd5cd7d436527c._comment |   29 +
 ..._97df39b9fed0e9bb716b1940c0641140._comment |   11 +
 ..._db0070d2b601e66aca3059248cc24bbb._comment |   22 +
 doc/bugs/annex_get__stalls_over_ssh.mdwn      |   31 +
 ..._335a8901b7992c2041eabed3785a25e0._comment |   18 +
 ...does_not_account_for_versioning_on_S3.mdwn |   16 +
 ..._a04fbb936785456ed99512ea4c29fd53._comment |   10 +
 ..._6015c5488e69307424a3c0281b50a49e._comment |    9 +
 ...nex_remotedaemon_100__37___cpu_hungry.mdwn |   81 +
 ...lently_resets_master_to_previous_sync.mdwn |   26 +
 ..._84346dcb210b86e86bd474820bb5f494._comment |   33 +
 ..._c420c76e5aebb1339f4c478b4d56d5de._comment |   11 +
 ..._80d241b2654856669d82d1ab5de40c00._comment |    8 +
 .../annex_tries_to_start_old_binaray.mdwn     |   45 +
 ..._209c36b737a48a6136eeb85d1f3d01b3._comment |   10 +
 ...nnex__47__uninit_should_handle_copies.mdwn |   20 +
 ..._c896ff6589f62178b60e606771e4f2bf._comment |   10 +
 ..._9249609f83f8e9c7521cd2f007c1a39e._comment |    8 +
 .../apparent_hang_in_git-annex-smudge.mdwn    |   31 +
 ..._80e24b74572d50f648d8aaae228b8827._comment |   20 +
 .../aria2c_display_broken_in_git-annex.mdwn   |  147 +
 ..._770e1d657bba2a3f5782eac2e8bdca57._comment |   14 +
 ..._2f26037c5a67f6f8928204ab0b7b7965._comment |    7 +
 ...autostop_stops_after_nonexistant_repo.mdwn |   25 +
 ..._41___commited_unlocked_link_to_annex.mdwn |  106 +
 ...adding_encrypted_usbdrive_repo_on_mac.mdwn |   53 +
 ..._4ea192e57f86a33087997746722e6acf._comment |   10 +
 ..._622ad5b34780fc8468c5c515ad9f27fa._comment |    8 +
 ...not_sync_files_to_empty_indirect_repo.mdwn |  281 +
 ..._af9b44674bafb63de05b888b90878325._comment |   21 +
 ..._789149eb53162a11cbafde399215e40e._comment |    8 +
 ...committer_crashes_due_to_missing_file.mdwn |   71 +
 ...oes_not_allow_adding_an_existing_repo.mdwn |   10 +
 ..._87e84d56d56abefe8cac8a52b76c9003._comment |    8 +
 ..._55fcf44eefe6abac3f61a14e9ce9206c._comment |   34 +
 ...epo_cost_info_when_queueing_downloads.mdwn |   18 +
 ...__t_notice_changes_to_gitignore_files.mdwn |   41 +
 ...t_doesn__39__t_sync_empty_directories.mdwn |   32 +
 ..._78a3bde607f43c0f518bd2d3d7196022._comment |    8 +
 ..._83777384b72732b1d0a19b32686d3d1f._comment |    8 +
 ..._f9b2a700c060707fae1bcb2ec0e4e4dc._comment |    9 +
 ..._014d213a959dd7993bdd247722a8817e._comment |    8 +
 ..._440f349781d7d9ca2d1ed81386f7dd26._comment |    8 +
 ...nt_doesn__39__t_sync_file_permissions.mdwn |   47 +
 ..._fc8d3ea209a2ab39c1aeff52452d4c58._comment |   10 +
 ..._1a364c422e0dd7418f74e1cc3d543a3c._comment |    8 +
 ..._4d5ae51b4c7e6177d934d7c9f21b912c._comment |    8 +
 ..._ec7b491ad3c9a1f253d886682bff8b82._comment |   11 +
 ..._e04ddcd7a3d260c1dac54e41911bb4bc._comment |   10 +
 ..._13db3474113b157b7431eb1c835e5814._comment |   14 +
 ..._3cc6eeb8eae14ac3727b1e420f96ee7d._comment |   10 +
 ...nsive_scan_unnecessarily_queues_files.mdwn |   65 +
 ..._bc874e077009b81ab36a6d43d793030a._comment |   10 +
 ..._a7e9d8ec500399dd6794e168f85e6a5c._comment |   40 +
 ..._a0824e00f04f95c39823f29d6c76e7fe._comment |   10 +
 doc/bugs/assistant_locked_my_files.mdwn       |   30 +
 ..._74ee7ea12df7bfbb44c9d0485f787b73._comment |    8 +
 doc/bugs/assistant_memory_leak.mdwn           |   22 +
 .../assistant_not_synching_with_content.mdwn  |   97 +
 ..._remotes_using_the_standalone_tarball.mdwn |   21 +
 ...es_does_not_merge_changes_from_remote.mdwn |   12 +
 ..._43bae1f11621232a9133cdef21d1f063._comment |   19 +
 ...etimes_removes_and_re-adds_whole_file.mdwn |   73 +
 ..._52a4748fda6682e6e667501726fd05c6._comment |    9 +
 ...ace_miscomputed_on_large_macOS_volume.mdwn |   78 +
 ..._cb1e92ef1412e68c12f6a1c9a10a7414._comment |   16 +
 ...option_for_init_is_in_no_effect__63__.mdwn |   77 +
 ..._6b40b5ea277d8e28f0b632701a776587._comment |   10 +
 ...ot_automatically_synced_to_local_repo.mdwn |   15 +
 ..._66ffaa679ba0fe86bba114fd9cdc5a53._comment |    9 +
 ..._a7617cc63584dafb16bdc9373fb1e304._comment |    7 +
 ..._ecb57e72c0bf583d1c3461313a83c4f2._comment |   13 +
 ..._bf0e16f9181438c2050521c5ff5bb7d0._comment |   14 +
 ..._aeea3ff59c8493c87c313fbaf7614f20._comment |   36 +
 doc/bugs/bare_remote_safe_directory.mdwn      |   15 +
 ...journalled_changes_made_while_running.mdwn |   12 +
 ...g_http__58____47____47___with___58___.mdwn |   36 +
 ..._c41e4999eb41846eb841b6ce9802b77b._comment |   26 +
 ...d___40__No_space_left_on_device__41__.mdwn |   62 +
 ..._644835e95676da0aa38737b3419022e2._comment |    8 +
 doc/bugs/blake3_hash_support.mdwn             |  377 +
 ..._723a531dad2df722514a7cbf1b8e0d8a._comment |    9 +
 ..._7be0932328ba4f49c33b0ab14429a283._comment |   18 +
 ..._a28c55a1d6158e301cc63d6087d8ab0e._comment |   23 +
 ..._3ef2af8eb62a81299e49a3b7dccd337e._comment |   30 +
 .../broken_repo_when_inodes_exhausted.mdwn    |   62 +
 ..._8ccfac4cea4c54029b96b436ac2114ed._comment |   12 +
 ..._4c6ced0d3163735c7f4bd5a4a7053159._comment |    9 +
 doc/bugs/build_for_OpenBSD_is_outdated.mdwn   |   16 +
 ..._59d9f99747cd3ba93a87ba634824d4ca._comment |   14 +
 ..._cb4f3d710b0c46b27bebed48bd2e9a21._comment |    8 +
 ..._99e6c86785c91b8320ec1e7df1e02e2c._comment |   13 +
 ...bup_often_errors_out_when_-J___62___1.mdwn |   44 +
 ..._1731cfb2662890299ca6daeacdd4bb47._comment |   22 +
 ..._f0f87b7a2c60afba609072566b0048ac._comment |  190 +
 ..._ca2b909c54a772e1eea58b7cbc07bf39._comment |   15 +
 ..._d7156224245542f5468783c1b5763154._comment |   13 +
 ..._90d280582d71f77d75aeedcd30c7c437._comment |   12 +
 doc/bugs/cabal_builds_without_assistant.mdwn  |   14 +
 .../can__39__t_build_without_assistant.mdwn   |   39 +
 ..._41b96b4e7f01b79a2e942b8098faa534._comment |   20 +
 ...jabber_with_custom_google_apps_domain.mdwn |   21 +
 ..._6537e928a0d6d5c41b55370f112f4afb._comment |   10 +
 ..._b639ad750a4635d95f6ad16a1aa39a3e._comment |    8 +
 doc/bugs/can__39__t_get.mdwn                  |   81 +
 ..._ef32287828481c161bd913c9db9052a5._comment |   27 +
 ..._31fe400f4bac516a5c1101612cb06a54._comment |   32 +
 ..._87d123c04815d38abb92f967829c3a23._comment |   16 +
 ..._b99cff87dbe38f08f888200dfe7e2436._comment |   14 +
 ...ace_in_its_path_via_annex-ssh-options.mdwn |   32 +
 ..._d773dee03276e9b0e0b75d0709b76278._comment |   18 +
 ..._01cb7ba7d3c19863d39f6fac0d45d235._comment |   25 +
 ...nnot_add_a_files_with_an_accent_in_it.mdwn |   43 +
 ..._d465d7f88c8f11b4b636fba56711d745._comment |   23 +
 ..._b6886a5c38725d93630562a3172d1a5c._comment |   20 +
 ..._7c34ada3c7b413f2b622149b60757f6e._comment |   37 +
 ...ocal_readonly_repo_through_the_webapp.mdwn |   98 +
 doc/bugs/cannot_ungroup_a_repository.mdwn     |   55 +
 ..._5476ceb9af2fa2d862a868824e5865e4._comment |   39 +
 ..._0be32bc80e98c0e10b2eb949b20b18dc._comment |   16 +
 ..._16f1b5ce3830f9d26df4b14ed666e189._comment |    9 +
 ..._bc93a6cb01e7d5d43cccb0eca81b5f33._comment |    8 +
 doc/bugs/chunks_not_deduplicated.mdwn         |   27 +
 ..._3890af3669ac6b37b88dac938ed79d16._comment |    7 +
 ...gument___40__invalid_character__41__2.mdwn |   24 +
 ..._b56c847c5eda432a4330b4d853a25519._comment |   27 +
 ..._processes_can_lead_to_locking_issues.mdwn |   53 +
 doc/bugs/confirmed.mdwn                       |    5 +
 ...63____41___test_stalls_on_an_occasion.mdwn |   40 +
 ..._ab2c1db51a42a146708b28f4cb3309a6._comment |   34 +
 ..._e7da4a54b27f459d528a7651fd615913._comment |   28 +
 ...me_of_file_on_windows_breaks_original.mdwn |   49 +
 ..._c6e8e3e76185b6ca25067c2a7e5cd8fc._comment |   19 +
 ..._7e2604bad32225682513b51c1be6f571._comment |   10 +
 ..._--from_--to_checks_destination_files.mdwn |   88 +
 ..._2a2997e6f914afb0477f2baa69b174fc._comment |   13 +
 ..._f7bf30e8cc2d1995976bde723dfbfe01._comment |    7 +
 ...-from_--to_does_not_adjust_avail_info.mdwn |   55 +
 ..._d6a1dd2e039dcb6dafcf4675b9244617._comment |   11 +
 ...--to_does_not_copy_if_present_locally.mdwn |   93 +
 ..._ae76f27d9ef4ebac7ad57e6aef9a7586._comment |   57 +
 ..._e857c1d89b350517fcb9829e52d6c6db._comment |    9 +
 ..._492d7c932fe5663aab916aacc829fb5d._comment |   27 +
 ..._8cfb9f2c14559a7574edd29b161cf7c7._comment |   19 +
 ..._fd23d0559018c531595cd06f81290258._comment |   12 +
 ..._c374eb44ea08f220dbcce5ecb88403fb._comment |   16 +
 ..._git_remote_does_not_run_concurrently.mdwn |   36 +
 doc/bugs/corrupt_backend_upon_sync__63__.mdwn |   78 +
 ..._9f248d82f93040b739b56515d18458c7._comment |   24 +
 ...y_where_a_mountpoint_should_have_been.mdwn |   29 +
 ..._41cfd5e48426a6ef52bef70a06a6f46a._comment |   11 +
 ..._bd584ccbe128427fca99e61d66d301c9._comment |   18 +
 ..._5bb0347215b321444643646f25a35759._comment |   10 +
 ..._73848a9c783ecf3d9fccdd41b20fbe36._comment |   56 +
 ..._64bf56f2b0ff206c3caf5cadebfd0cda._comment |   20 +
 .../creating_a_remote_server_repository.mdwn  |   24 +
 ..._de1a370347428245bcfca60eaca96779._comment |   10 +
 ..._482ac9b0f881099910f9bd9f7cda184d._comment |    8 +
 ..._b7c7f684d0eef14fcc00cb2ac0566703._comment |   10 +
 ...orktree_configuration_from_submodules.mdwn |   58 +
 ..._ca12be107b7a7dc36cb71595e347ce28._comment |   15 +
 ..._b7f03cbb85862ed294ecd0f8cbbd2086._comment |   15 +
 ...eads_to_git-annex__58___SQLite3_error.mdwn |  115 +
 ..._aaea812a8f2b04d9b17d1ba9c6fad39f._comment |   60 +
 ..._c55f2d95f7f08e6f6439f36790e5a538._comment |   16 +
 ..._b49a3df3b13f564e588824910a07bc43._comment |   11 +
 ..._a9e6e37dbaa1664d825bdbd64de4fbdd._comment |    9 +
 ..._3a5eaa2492e4c62a15b4fcee7f96d9dd._comment |    8 +
 doc/bugs/cygwin.mdwn                          |  406 +
 ..._88b6c7d1f50d0f17443ee74b5886649c._comment |   16 +
 ...mark_repo_with_empty_description_dead.mdwn |   13 +
 .../describe_what_git-annex_actually_is.mdwn  |   14 +
 ..._25fc9ffb24fc4c96b81a6393427bbe95._comment |    8 +
 ..._1f6ec7cedf56863b261bad0e3f3c80de._comment |    8 +
 ..._as_boolean_true_value_for_autoenable.mdwn |   70 +
 ..._2f13e023228fa4938dd314e040a8ec10._comment |   37 +
 ..._01985a25dbdcfe487e28aaeb5823fded._comment |   25 +
 ..._136e937bdeda3dec080b49d4755d1fba._comment |   90 +
 ..._aa4ae6db181b1261a36ad06f223ec28f._comment |    8 +
 ..._ea204e2190c5a34cfcb3dc0e0710a4e3._comment |   10 +
 ..._2f998fab7d88a9ade53354d1820248ea._comment |   17 +
 ..._bfbc9a9fbae3715fea0f4a11549ec8a9._comment |   40 +
 doc/bugs/done.mdwn                            |    4 +
 ...lustre__58___SQLite3_returned_ErrorIO.mdwn |   52 +
 ..._49e8920ad09ae71874686f50f566b77c._comment |   32 +
 ..._5f5de9dc70bf61c8a369841b24a5ec2a._comment |   13 +
 ...pecial_hybrid_encryption_remote_fails.mdwn |   57 +
 ..._09e26fdacfb5c159997671680dc95ab7._comment |   13 +
 doc/bugs/dropkey_-z_does_not_drop_etc.mdwn    |   45 +
 ..._278595e3bb8fe54357ea3ee78f780ccf._comment |   13 +
 ..._d387dff8a99f9733db7856c4b216beff._comment |   20 +
 ..._52f21e094853f787c18f4b9737d9771f._comment |    8 +
 ..._a2f221d36d538c89fa5786a3ff12bbfa._comment |   15 +
 ..._46d527889606595da1a6b00b631ee2b7._comment |   15 +
 ..._d6377ddfb9d907d56c70141b0c3a8a32._comment |   11 +
 ..._57b63abb8ccb7fbbd71afd599cb9ef5c._comment |   18 +
 ..._c537d9ff75804fe4afc174791c427df4._comment |    9 +
 ..._f3bcf33b3b3882073765250c2d113180._comment |   13 +
 ...urns_ok_but_doesn__39__t_delete_files.mdwn |   55 +
 ..._61fc9ee219d3042e1e32e35b5086ef4e._comment |   13 +
 doc/bugs/duplicate.mdwn                       |    1 +
 doc/bugs/enable-tor_failing_on_Android.mdwn   |  109 +
 ..._7592b563c0ddb338e1f39ff6cf5fa1f0._comment |   24 +
 doc/bugs/enable-tor_unsupported_on_osx.mdwn   |   30 +
 ..._with___34__wrong_reason__34___stated.mdwn |   46 +
 ..._c23de4c4ff536a214c795a805957c9f1._comment |   24 +
 ..._c75d3a033b1b8699e512df4641a38548._comment |   13 +
 ..._39e13618336181485175dddc7185160a._comment |    8 +
 ..._c7a5c3dfaca25fad2edf9575f65629e8._comment |   18 +
 ...ing_fatal_error_on_auto_annex_upgrade.mdwn |   96 +
 ..._041e664be0a5ae635cf5848d9fee380c._comment |    9 +
 ..._b0deace2dcadbd50c0e0cb155041b255._comment |   16 +
 ..._60f745051264fcacdce882eb8646b3fe._comment |   56 +
 ..._9e32aa105bbf11a6d2610a62bfa9517b._comment |   13 +
 ..._28d35ef30f76ec326363d86ab2948ad3._comment |   32 +
 ...e_doesn__39__t_work_with_enableremote.mdwn |   44 +
 ..._ce62150a3bb8c6be05b9f2ddbe64ae8b._comment |   39 +
 ...nnex_filter-process_died_of_signal_15.mdwn |  101 +
 ..._02da33e41e4f4471d1ae08e9fede229a._comment |   17 +
 ..._5ebfc18008cf4bc21ffce57067314fc0._comment |   85 +
 ..._c74018853a4da8e609da1803051a6893._comment |   14 +
 ..._0a80393f055ead9a3a62da0aa4ec3298._comment |   54 +
 ..._8b27c6099afea7011717492f53fcdac4._comment |    7 +
 ...ting_internet_archive_item_via_web_UI.mdwn |   47 +
 ..._4047d926154b444f33674f4db52be04d._comment |    9 +
 doc/bugs/error_during_copy_to_S3.mdwn         |   40 +
 ..._14740dc386510409a8fbda5635eee831._comment |   14 +
 ..._157d4bfcb593cf380445caae0523dbbb._comment |   11 +
 ..._0e1ed01fc34a5a98c67dd290cb58481f._comment |   15 +
 ...rror_on_only_repository_copy_deletion.mdwn |   16 +
 ..._af394ac0956ab33a77256bcb02ef2a0f._comment |   14 +
 ...file_size_0_from_external_spec_remote.mdwn |   90 +
 ..._6af7ba08e93349b2c6176f91ba25a06f._comment |   11 +
 ..._1d78459554bc12d0423a317bd9f466d1._comment |   17 +
 ..._aa083a54e0c77cdba9939a061b509488._comment |   11 +
 ...95__subdir_started_to_fail_some_times.mdwn |   36 +
 ..._cae9d3f611a2b08d47466e5e5c6e80ed._comment |   18 +
 ..._8cfd20ada49f2441ad305b2225a738bb._comment |    8 +
 ..._6b3e21c80fd75d153282cd4170f4b9d2._comment |   20 +
 ..._e49f6175def95abcd353708acbfc3519._comment |   16 +
 ..._45a95910d34d602a916282e4e8ec9a08._comment |    9 +
 ..._78b6f81f900fb4d28808005d223a9da8._comment |   20 +
 ...oesn__39__t_copy_from_adjusted_branch.mdwn |   35 +
 ..._5ff140be453458e84bd6072594e70d8a._comment |   16 +
 ...tree_interaction_with_adjusted_branch.mdwn |    9 +
 ...l_remote_export_sent_to_wrong_process.mdwn |   87 +
 ..._831bdc33451de9ef5c54592a7455683f._comment |   46 +
 ..._8ff0638891c38f423d792f5c3cbfb64f._comment |   16 +
 ..._d774a7319bd1a1778adb2004229f057e._comment |   12 +
 ..._db89603335995755d145141705ac4584._comment |   13 +
 ..._48656a34262fce77ac50836d1d38b9fe._comment |    9 +
 ..._e38b776c73affdbb06f3debdddb07e59._comment |    9 +
 ..._6a85fcfa3eb0b4974733a62bcc0bbab2._comment |   12 +
 ..._c4610009f691ce60940979b73bef4d78._comment |   14 +
 ...mote_protocol_unable_to_parse_command.mdwn |   33 +
 ..._a10012aa7df76a2366ea40da8c37b798._comment |   10 +
 ..._a4556ce5c5f40ca022385cfb3a97ddac._comment |    8 +
 ...enticate_into_S3_for_initremote__63__.mdwn |   32 +
 ..._a7fcd34cf9376e900db832a8010df7d7._comment |   11 +
 ..._on_git-lfs_remote___40__gcrypt__41__.mdwn |  246 +
 ..._ba5b0ed901c99a23ff72d68b83c0d2fa._comment |   18 +
 doc/bugs/fat_support.mdwn                     |   13 +
 ..._04bcc4795d431e8cb32293aab29bbfe2._comment |   12 +
 ..._bb4a97ebadb5c53809fc78431eabd7c8._comment |   14 +
 ..._df3b943bc1081a8f3f7434ae0c8e061e._comment |   11 +
 ..._90a8a15bedd94480945a374f9d706b86._comment |   10 +
 ..._64bbf89de0836673224b83fdefa0407b._comment |    8 +
 ..._a3b6000330c9c376611c228d746a1d55._comment |    8 +
 ..._a0ac7f2c44efc8116940c7b94b35e9d0._comment |    7 +
 ..._acc947643a635eb10a1bff92083a3506._comment |   10 +
 ...al__58___Cannot_handle_files_this_big.mdwn |   96 +
 ..._e4f03a86a7adc6c5421d1e70c37659e0._comment |   17 +
 ..._546782c644230741470f9a9de23bd019._comment |   24 +
 ..._151e7cf96c7d168e1397d111aa47f279._comment |   20 +
 ..._3b47ce467eee2b903c0ed40e251d4bc1._comment |   88 +
 ...d_omitted_from_import_--json-progress.mdwn |   37 +
 ..._bea5a95e6fe120e1ee8c87ce6c55f161._comment |   10 +
 ..._stored_in_exactly_one_metadata_field.mdwn |   10 +
 ..._7fef3484f3019539c0a305d5f4a801ce._comment |   15 +
 ..._32285971869ec56460b3f0eee4edfa23._comment |   30 +
 ..._7bf423111829ec6b358c6925d012a3e2._comment |   11 +
 doc/bugs/filemanager_integration_broken.mdwn  |   44 +
 ..._aa5afe9af21e534a6c0683064296d9e6._comment |   30 +
 doc/bugs/find_by_metadata_is_slow.mdwn        |   19 +
 ...___40__repository_not_available__41__.mdwn |   87 +
 ..._70e050ef94ab57e74b45b18f3f9ca1f3._comment |   49 +
 ..._35df3798ddb3424fb26e11df53420d2d._comment |   13 +
 ..._584fce9a8a501e380426c123505bfdf9._comment |   10 +
 doc/bugs/forwarded.mdwn                       |    2 +
 ...ls__58___hPut__58___invalid_argument_.mdwn |   33 +
 ..._6b2c645f9ca440f4707c671a94566bb7._comment |   20 +
 ..._52185ae4ebdfcb61840444e3ef1e0404._comment |   25 +
 ...sck_--json_incomplete_error_reporting.mdwn |   53 +
 ..._979d52131fe94a9e800f939da88b369e._comment |   17 +
 ..._71fd5ede0aa24fcc6522a03010ccec5c._comment |    8 +
 ...does_not_detect_corruption_on_yt_vids.mdwn |   72 +
 ..._e7f61f04af8cc4c7ff9125fa37b90f4f._comment |   11 +
 ..._8f26d11cbfceb6928648fe40b890c49b._comment |   28 +
 ...es_--json-error-messages_when_--quiet.mdwn |   76 +
 ..._a23d96af8c0e418350a73cbce5bc24be._comment |   23 +
 ..._for_a_file_that_is_not_in_the_remote.mdwn |   47 +
 ..._ce9085e6330625dabf479e6e3beeeb47._comment |    9 +
 ..._59e89c065a3cd8f7c80cfdb3c2c2808d._comment |    8 +
 ..._264a1b39c1677545af4c02901dd23d22._comment |   15 +
 ..._f08e305e39953c5c1906df0fb2eb113b._comment |   10 +
 ..._39__ok__39___also_if_no_file_present.mdwn |   77 +
 ...ING__58___Remote_ID_has_changed__33__.mdwn |   50 +
 .../gcrypt_remotes_using_relative_paths.mdwn  |   39 +
 ..._b4523baf0cdfc2ad70cded93b1629eca._comment |   30 +
 ..._45281c947992c2ab124efd0f109255d6._comment |   36 +
 ...phrase_ask_for_the_2nd_ssh_invocation.mdwn |   60 +
 ..._66386390af02c67c2e5bace223251f53._comment |   15 +
 ..._f818dadfa541520ac7ad2409b9174776._comment |   18 +
 ..._18e194d53646cb6049058635ad54fe1f._comment |   22 +
 ..._2766d9082373c11628006f14262509ad._comment |    8 +
 ..._a15a47b120c0c1c1c8ee5050d6105bb1._comment |   13 +
 ..._72f08e454aad5092acc609a6597d9872._comment |    8 +
 ..._81f23cf6fe835358c9b88af50eab22a5._comment |   14 +
 ..._bbcf4c05813adc2239c1f6017425f1c9._comment |   11 +
 ..._23715781fb5fd3ece5e042be069812ab._comment |    7 +
 ..._a037b7da3c4f2e04b23706592f04b0ac._comment |    9 +
 ..._6efb1a75b236b4384d1d2fccc3ab30b8._comment |   12 +
 doc/bugs/get_is_busy_doing_nothing.mdwn       |   83 +
 ..._10fea4ce67f5f9c6c33ba2a23a185f8a._comment |   14 +
 ..._36dd4a0dba9e544d18376013e879b9c2._comment |    8 +
 ..._795ffef1e6a9f1acbd4394c1fca3818e._comment |   18 +
 ..._afae18b8b3a17f376b9a345059d9dbd4._comment |   11 +
 ..._bdfbcb8b6052a3c904e46678fce6adeb._comment |   14 +
 ..._9f6fde051e877638a56094d3179dc550._comment |   12 +
 ..._4d375d35a0d05d99c7becf591823d6b8._comment |   25 +
 ..._f687c46fb89009712247fe480f0f9566._comment |   41 +
 ..._0e5796c55c76dc8b37f9fd875d87eff0._comment |   41 +
 ..._216aefa4a78d13cc0c46780161921a36._comment |   22 +
 ..._ea9363fac84619b72d6c9f2a3a5c2d6d._comment |   15 +
 ..._981cc786be798a612046d207c0f85955._comment |   28 +
 ..._eabe406ab0d6e71c3f5f30908016a592._comment |   29 +
 ..._711bf1ba8688bdc3bf33e7103340bc11._comment |   11 +
 ..._3671d133d18f6722901ed01a1fa38164._comment |   30 +
 ..._054db0e62994590631737b9bd768d901._comment |    7 +
 ..._4766362f74f135887d5b6103db9a8a06._comment |   42 +
 ..._d02b310b007b304e0eda23bd5e565851._comment |   16 +
 ..._45168f110bded2f8c8f9777e1edda945._comment |   13 +
 ..._8b11e01481065814d2b35f9d728df9f7._comment |   61 +
 ..._f06b9085e1d48298c6c1739afb17d2bb._comment |   84 +
 ..._422aed4fc2729483e1479cadd54f45e1._comment |   15 +
 ..._28da709b2152b1ce1d0c926b099febad._comment |   15 +
 ..._c9594a39c44f7fd6649c418dbb5d2c59._comment |   97 +
 ..._7a7f6e9793817884a309632e4ebaba1b._comment |   18 +
 ..._0b507f49b6c23d9a9e1557fe96ad58b1._comment |   24 +
 ..._6209db4f931bced0f6782d231aa45452._comment |   40 +
 ...nning_on_OSX_with_HOME_on_crippled_FS.mdwn |   32 +
 ...efinitely_in_an_STM_transaction__34__.mdwn |   56 +
 ..._c9d7057b9c7b7811a29dcc59b98f97d0._comment |   27 +
 ...mote_with_same_name_as_special_remote.mdwn |   13 +
 ..._7f28aecc6ecefd7d47979f73330759d2._comment |   18 +
 ...x-import_imports_outside_of_directory.mdwn |   31 +
 ..._30dab036949bd35e026a31974c4e5164._comment |   16 +
 ..._376302b0bac94ee81c0dfdcb647f3b3b._comment |   25 +
 ..._e74c71a5574a8e99503ac83a27d48533._comment |   17 +
 ..._778e176a44aa57e9223aab1a45c931f3._comment |   19 +
 ..._3406ba56525cb59b8b1b366e2b3dc291._comment |   26 +
 ..._5b41c061786fd49c75d49aa2cc70bb9f._comment |   21 +
 ..._6d559ba943ef2a8fed285c463eb2a641._comment |    9 +
 ..._d6aaa0519faa596fa42d22fba405cbff._comment |   11 +
 ..._4f9816f7c9a61289bef98820b1ec25cc._comment |   16 +
 ..._372c44296c1a03778e201a47ec45bee6._comment |    9 +
 ...ort_stalls_and_uses_all_ram_available.mdwn |   66 +
 ..._ca22165fc77a57979ad6e19c60693b21._comment |   25 +
 ..._2025b1662067bbfaab14576d9e20a6ab._comment |   11 +
 ..._5943379450c860b2885121e7f0abd42a._comment |   14 +
 ...Android_crashes_on___34__arm7el__34__.mdwn |   90 +
 ..._af1de40a3c83f8632f98ecde5a5271f5._comment |   15 +
 ...nnex-move_not_using_parallelism__63__.mdwn |   15 +
 ..._1080a771213dc524cbd072591030c98c._comment |   16 +
 ..._a83e833b329df094e1bc7945db9686b0._comment |    8 +
 ..._bdd1aabe7120c4e6b5999aaf396067bc._comment |    8 +
 ...ex-repair_claims_success_then_failure.mdwn |   52 +
 ..._de8dfda0bc321e573ab9d17aec1ecb84._comment |   19 +
 ..._3d2c3827de34509c0a5595eda07dd18f._comment |   13 +
 ...k__44___while_git-annex_expects_it_to.mdwn |   29 +
 ..._b0a4f459d40bca7a0b24d1bec1e0f4a8._comment |    8 +
 ..._335fea47cef83b6dfad7ce8c53193f82._comment |   12 +
 ..._abaeb3d5c0322deeec790d80b2948549._comment |    9 +
 .../git-annex-shell_fails_to_run_true.mdwn    |  166 +
 ..._7573eb95bdecc3ecc9b31599bd309d3d._comment |   31 +
 ..._5be34b5ffaee39013d24daf83a8dd437._comment |   17 +
 ...annex-sync_not_quite_idempotent__63__.mdwn |   90 +
 ..._d90a0f326840137872f551e54c2d2a53._comment |   31 +
 ..._ba60267d8b34ae9e277ae992dcfcde96._comment |    8 +
 ..._2381583c924561cbe46186fbd8fbf654._comment |  120 +
 ..._44c082a9321806ca2a60debf829f9c39._comment |   22 +
 ..._86187583d3128f2d64d1c5d58b31283c._comment |   63 +
 ..._-__62___assistant_requires_s3_bucket.mdwn |   14 +
 ..._5ec1d63e8f2896876fc88d53b6170b74._comment |   18 +
 ...d___40__Operation_not_permitted__41__.mdwn |   46 +
 ..._2d68f1f5019621bccfd59be5066fdcbe._comment |   18 +
 ..._89b9f0cabdfac72ce6b0b9461672705f._comment |   11 +
 ...urce_vanished___40__Broken_pipe__41__.mdwn |   18 +
 ..._e962317a939bf76097ae1a3b53b146e6._comment |   14 +
 ..._b32472b4c9b61e7a33dca802ecafb05b._comment |   11 +
 ..._fcfea3216831df9afbd855fbd842c27e._comment |   20 +
 ..._30d0b40efa59eeecb8a4be6d1baa1520._comment |   10 +
 ..._4af107f3184bc2abd2c9693167018628._comment |    8 +
 ..._f96027f1e3c405809fae42ce8533c6d1._comment |    8 +
 ..._b6fe89deb468a7e4f63f7faab147e3fb._comment |   12 +
 ..._ebec5d9266604f03959dc16d933ff4a4._comment |   13 +
 ...__14__58___hGetLine__58___end_of_file.mdwn |   51 +
 ..._36756f5d9d591cc52113c5cc0c1eae91._comment |    8 +
 ...eadDirStream__58___inappropriate_type.mdwn |   33 +
 ..._1b988c92ae79e6d9ddc487bea358dec1._comment |   22 +
 ...t_being_pushed_after_git-annex_forget.mdwn |   30 +
 ..._babea9a16f25b471026732ea63dd78a8._comment |   14 +
 ..._dd24434631ae3898e8f5c1f878d1965f._comment |    9 +
 ..._70f2b9e61e90528fdbef4d8a6e8dd972._comment |   13 +
 ..._11e9ceb40aa5492a1a3e9ebfbd246832._comment |    7 +
 ..._20ee285d62c35e18b78b121d8e4de81b._comment |   35 +
 ...ch_shows_commit_with_looong_commitlog.mdwn |   74 +
 ..._b83888a98075125dd043f323c99da03b._comment |   25 +
 ..._4a7d824b6e75693cf47f6efbf2c99e2e._comment |   10 +
 ..._cbbeaa691d102bd7d29f5e9bad9d6f53._comment |   32 +
 ..._094191b806ac76b2aef325733fe37136._comment |    8 +
 ..._c97926b15ba320f57a6441f9844cb139._comment |    7 +
 ..._3b70a60ef1c47871a3933176eac38174._comment |   40 +
 ..._fc56ec87725c7427794b70ee2ba2822a._comment |   12 +
 ...t_to_freenet_cloud___40__webdav__41__.mdwn |   36 +
 ..._db7b584c1e932d24e0dcf464b023a659._comment |   41 +
 ..._72e9ecc6acdc555e36f5588120d070fa._comment |   39 +
 ..._b2ef283a3933e22542e05ce9a1acef7d._comment |   38 +
 ..._7a139eb2c11ab2e32d22ca0f8bb648a5._comment |   17 +
 ...ied_of_signal_11_when_syncing_content.mdwn |   30 +
 ..._e982f985e5ca57454725e9e9a482e30c._comment |   12 +
 ..._e920f624ccf2e3a9c71a00105ebc3595._comment |   16 +
 ..._373e63d55e07cb5cdecc4e01d5d52b79._comment |   13 +
 ..._678a0136f143d2d7874226b3fc744eb2._comment |   24 +
 ...stall_on_windows_without_admin_rights.mdwn |   24 +
 ..._2533800ab5a95c5d71c3b47a630e751a._comment |   10 +
 ..._5b71785acf16a8d9ea457726599daef3._comment |    8 +
 ..._63e4ff79bc683a70dd9a85c66e26e56a._comment |    8 +
 ...7____47____47___target_URL_on_Windows.mdwn |   31 +
 ..._f0d30a953f072f8d9a929a4a6ba69914._comment |   48 +
 ..._504ea07f798838710cdbf6133135c815._comment |   39 +
 ..._a9bd50ebe805afefab103da31b88cf89._comment |   20 +
 ..._f2bd555ca36b42dac6a213e7c947f1f9._comment |   32 +
 ..._e00d70ba6b88d9cf60fcb183f7ea4980._comment |    7 +
 ...x_findkeys_does_not_know_--largerthan.mdwn |   50 +
 ..._f6484f69669439ef49513b84d3bd91cf._comment |   12 +
 ...eport_the_files_it_failed_to_download.mdwn |   18 +
 ..._074e49431bd18c43164872de3733b0e8._comment |    8 +
 ...t_with_umlaut_characters_in_filenames.mdwn |   59 +
 ..._0724d70364f7067d864a80a39e2e609a._comment |   17 +
 ...annex_is_slow_at_reading_file_content.mdwn |   55 +
 ..._d04b5bc031f73363d44b81f436b59781._comment |   10 +
 ..._cab37d851237a7798f74867e08aaafb9._comment |   33 +
 ..._466a365bca48065cc6b9e280b5c385a5._comment |   18 +
 ..._0eb12582a3e182b697a07b833cfbe384._comment |   13 +
 ..._ed54af250541e2add89938b939016659._comment |   16 +
 ..._786b21544854ad719eac07d08ba8d206._comment |   14 +
 ..._190a153449f7bb07fb4aca89db236881._comment |   26 +
 ..._492a11bcabc20b02239bc3b12438a51a._comment |   10 +
 ..._1367e6e461a9a049527197c262635c2f._comment |    8 +
 ..._123c81ad10aef15814f1c831e18c0a23._comment |   17 +
 ..._2885c2f164dbe59234568966e901bdd7._comment |    9 +
 ..._559e5c3b5ea9c166b3aa4a2e975643c6._comment |   12 +
 ..._c8b4c2e955b4ef5caaaaf2f834fb37f8._comment |   12 +
 doc/bugs/git-annex_merge_stalls.mdwn          |   18 +
 ..._31578a754945bdcb902c62ff58704bcb._comment |   17 +
 ..._f3b6bf180466b5931bfd20b2f0229422._comment |   10 +
 ..._ced9b0d724fb55c756106b64c3721003._comment |   18 +
 ...immediately_if_run_as_systemd_service.mdwn |  243 +
 ..._8573d3bb5ae9f3490265767128027ed1._comment |   14 +
 ..._34fa48bba13bf896e6b3809ec22fc58e._comment |   10 +
 ..._9b3040c521ec1992ec03c06a579dd627._comment |   16 +
 ...sses_up___126____47__.git-credentials.mdwn |   39 +
 ..._5fafcc62656bdec4eecdf35cee4c6a8f._comment |   23 +
 ..._f8435628336b472107b478fe11628186._comment |    8 +
 ...it-annex_stack.yml_misses_extra-deps..mdwn |   92 +
 ...ng_up_all_available_RAM_after_startup.mdwn |   49 +
 ..._b550f292359b44977481bf69abad4012._comment |   14 +
 ..._76e6c1d4db27bcc1767ba34e13e8211c._comment |    8 +
 ..._14007c8e927b75c5706e80cc4242fae4._comment |    8 +
 ..._f3266b74517b421e5310e67818fe3969._comment |   12 +
 ..._1a07f15eb0353768c1e67a1e47e2e494._comment |    9 +
 ..._7d0d49fd165af5e30606982e05335d34._comment |   10 +
 ..._2b0ba2a15af04731a966a029be9b81aa._comment |   11 +
 ...won__39__t_execute_on_WD_My_Cloud_NAS.mdwn |   58 +
 ..._b87b50ca08bf90ecb7d741a6baa1dc4d._comment |   17 +
 ..._6c95d0fd70fbf41eea4e6575486af3f5._comment |   48 +
 ..._6dd54179aad379bb22638db518bd377f._comment |    7 +
 ..._614da8cad46df5c71539cc5a8ed11831._comment |    8 +
 ..._5fa9d10ebd639eb1a836866b99e90aab._comment |   10 +
 ..._8e05f8769870b3f1aec77fca06f37284._comment |    7 +
 ..._8da1f5fc6656e92dc2e3dabd9808f2d1._comment |   13 +
 ..._48026cf7c187e97d53d15d35ed2c3670._comment |   14 +
 ...ailed__58___No_such_file_or_directory.mdwn |   43 +
 ..._984f75d8078f2809486f38ecb3b16be3._comment |   10 +
 ..._c0f07e2d4bb142389629050479dd1465._comment |   10 +
 ..._7a58a884aaacedca9697b17cd5248214._comment |   33 +
 ..._aa4f1806207138115d2a95935bb0546b._comment |    8 +
 ..._fa95f93416e3d6e66af557df6562f1e5._comment |    8 +
 ...it_annex_assist_adds_gitignored_files.mdwn |   39 +
 ..._assistant_adds_dotfiles_to_the_annex.mdwn |   35 +
 ...it_annex_assistant_exits_with_failure.mdwn |  161 +
 ..._247d4da208cd700851d48f13534d5f7c._comment |   13 +
 ..._c6c04006b1d9aa6be92f5a970ba60618._comment |   15 +
 ..._eabad530a55adfa4be3eae0f743d3309._comment |   14 +
 ..._204764bb40509d8650386227ea166a6e._comment |   12 +
 ..._0453ae9123b359757e63c6eb5f12811b._comment |   40 +
 ..._5b0310038a8b45d2083f39ea75c1a979._comment |    8 +
 ..._63b3ec113d52501237abbe6ee1ef5fa5._comment |   45 +
 ..._annex_assistant_failing_with_ARM_NAS.mdwn |   29 +
 ..._00ca17dca9da3ddb81514d319cae0ef4._comment |   14 +
 ...annex_assistant_leaks_a_lot_of_memory.mdwn |    9 +
 ..._a4805854c448e4bc70a47f5555e0f73c._comment |   21 +
 ..._e9dca04e0456ca7356996365a4b87d59._comment |   14 +
 ..._45ae862d4f940341d48d179583e65d66._comment |   38 +
 ..._d597e15e9693ce6e8c1ca80cb225b044._comment |   21 +
 ...annex_cannot_get_my_files_after_clone.mdwn |   36 +
 ..._52c91f8d2e8086b26a078a02d036c197._comment |   28 +
 ..._545c9daafc63c5cdb80763b929c8d622._comment |   32 +
 ..._ef9b32d9ba1b80c313db48be36cc90d1._comment |   26 +
 ..._d1d13d1f3366026957d572b930cafa4b._comment |    8 +
 ..._f8b58f9c5acb509871cc4a64b66de6f3._comment |    8 +
 ...nex_connecting_over_tor_does_not_work.mdwn |   82 +
 ..._35c33ae1d69382a03c94f4a20ec22f7e._comment |   17 +
 ..._5df90e5ffbd3f089a0f640d4a5b85a1c._comment |    8 +
 ..._9fa2fb82ae3d17a77a9645870e1e12e5._comment |   12 +
 ..._macOS___40__but_works_on_Linux__41__.mdwn |   21 +
 ..._6c044f007e66b951cf08b86f9be49ed3._comment |   10 +
 .../git_annex_copy_to_s3_out_of_memory.mdwn   |   63 +
 ..._5c0b73214c8f0ecb197cf0e109ff2729._comment |   18 +
 ...es_when_authenticating_with_jabber.de.mdwn |   26 +
 ..._5ba4f22bda2f5438fb08753cf149b649._comment |   12 +
 ..._b096cfdf26bfedfff16d882d7b2e060d._comment |   10 +
 ..._210be77aabb0ef5b85865cd08c51861e._comment |   12 +
 ..._bb974d882fbb31aa54e6de38410a2318._comment |    8 +
 ..._be655cbea27b6c87d298a75e1697a87d._comment |    8 +
 ..._72d1dac6627bbe22d5bd140215d82c47._comment |    8 +
 ..._8a8dfb15684525e156d6334e9f67a55c._comment |   66 +
 ..._f1a6e413756066659020e20147373a11._comment |    8 +
 ...remote_gcrypt_failure_leaves_a_remote.mdwn |   31 +
 .../git_annex_enableremote_locking_issue.mdwn |   56 +
 .../git_annex_forget_does_not_propagate.mdwn  |   30 +
 ..._591c3c59d831ed94268f90505a8baaee._comment |    8 +
 ..._9026452178c82d0661acc96d009e3764._comment |   14 +
 .../git_annex_get_--batch_does_not_work.mdwn  |   27 +
 ..._52311b95bf29706d2b1afb3904428047._comment |    9 +
 ..._b4fa614626393e01c51b937401bbaa23._comment |    9 +
 ..._e972b9fb5c6af4ecd295dc954bb2f55a._comment |   35 +
 ..._f0c498dad3f4d51e33de863165f29410._comment |   11 +
 ..._603adcb0b5091ac2fb3c9225d2925dc3._comment |   14 +
 ..._56716644ee1534b8fe90ba502856455c._comment |   14 +
 ..._b0588132d02f982da7c7208087b0afe2._comment |   11 +
 ..._0e776c598c5e0f4f51f5e9ade8c3f0e2._comment |    9 +
 ..._0c802c9c5734e7dfc8cd72962fcf2983._comment |   11 +
 ..._dangerous_if_you_have_unused_objects.mdwn |   42 +
 ..._9f9d5c18c27dfd33a5bf2c593ee65b58._comment |   31 +
 ..._f64891ff6fe0cd0be6a356ab8fe42817._comment |   11 +
 ..._d980c1e2d788324049475e468a0d6fab._comment |   23 +
 ..._09b860a14bb8bd49f2067e8ddb0aacfc._comment |   39 +
 ..._1e737b740bc7d95f3329e3481d55fd35._comment |   20 +
 ..._6def3c88ced56753e4b12ce221d33769._comment |   17 +
 ...x_move_--unused_not_moving_some_files.mdwn |   34 +
 ..._3fe94ad69d28f16598fdb8f98d7ffa54._comment |    9 +
 ..._91cdee93a29eefca78c1e49878b71574._comment |    9 +
 ..._40d839105047f4ac2996b53705601cc4._comment |   62 +
 ..._023fb25740f8363f8e72c12f020aa0f4._comment |   30 +
 ..._85ef3d6a4f2e67f16ee4bd30e58ef4fc._comment |   18 +
 doc/bugs/git_annex_push_fails_on_Windows.mdwn |  107 +
 ..._a7866c2131df8132e9aecebda085294c._comment |   20 +
 ..._d5c9fd2acdd5b320563a708889e82852._comment |   27 +
 ..._fe3818a184e723f86d094253461d8f44._comment |    8 +
 ...x_repair_failed__58___missing_objects.mdwn |   48 +
 ..._9f2166545159890b05ea061e2ab21a4f._comment |  166 +
 ..._7571de4a3ab7030a877fa198fe4810b1._comment |   48 +
 ..._317bee33fe675a5abb6fe65540a33d25._comment |   14 +
 ...stdout_isatty_when_reporting_progress.mdwn |   33 +
 ..._6c7f745ee77e9b7502cb13d3babf211b._comment |    8 +
 ..._e2139a3d1d06772d06992a38140e51d3._comment |   17 +
 ...x_still_deleting_content_when_merging.mdwn |   97 +
 ..._cb51e25c5e1656dcbb73b3ff680341f0._comment |   14 +
 ..._bbbcce7fc5f34d733126c42be8ec0a1d._comment |   27 +
 ..._f31a73e0e2c43f6a7f158455eadaa56c._comment |   27 +
 ..._sync_remove_all_recently_added_files.mdwn |   61 +
 ..._58faf8b37bb276e6176233d3daa24db9._comment |   17 +
 ..._a39ce4a60c1dc7817c84f90eac7251a6._comment |    8 +
 ..._3cb07eabd0e1802dbe477bdc88f647fb._comment |   35 +
 ..._65c5f5f34eb8535d244d6075caf57c21._comment |   23 +
 ...est_fails_when_run_through_powershell.mdwn |   30 +
 ..._014466c5da1922d34a498648baeeba26._comment |    9 +
 ..._241ab999007eecaa2cd5a854e722e315._comment |   16 +
 doc/bugs/git_annex_upgrade_fails.mdwn         |   35 +
 ..._26e3224b9aad57837969c309ae4bdcd2._comment |   28 +
 ...acter___40__and_probably_others__41__.mdwn |   33 +
 ..._861506e40e0d04d2be98bbfe9188be89._comment |   12 +
 ..._wont_work_with_git-dir_and_work-tree.mdwn |   29 +
 ..._cc3ea43301cd17b55794f9b9dd1e91cf._comment |   27 +
 ..._fb75f5941d355947b3f06165825dd012._comment |   16 +
 ..._8c7b21c8e500de719fc2909d0c9027e0._comment |    9 +
 ..._423126c9884267b3466470d4ec7301ce._comment |   10 +
 ..._80d9a46c608117fb9a381c59d4605ff4._comment |    7 +
 doc/bugs/git_commit_smudges_unncessarily.mdwn |   22 +
 ..._202cb8adc7a7b1119f5b4c1f5c6e9c7e._comment |   15 +
 ..._5b230c4b74da48099e8be0e264bbf3e6._comment |   13 +
 ..._c30e84ae438810cbab70c401fd5125c0._comment |    9 +
 ..._update__95__ref_failed_for_ref__34__.mdwn |   38 +
 ..._60ea64baccef82dc03ab300ca9b5e2b5._comment |   26 +
 ...ies_errors_when_using_adjusted_branch.mdwn |   69 +
 ..._1a6674245aed0c325361043d1100daec._comment |   17 +
 ..._ccadd646ec0fe7abec461c110bfb7ae7._comment |   20 +
 ..._2a6ef51c96a914be5d248b526ad37394._comment |   37 +
 ..._f9588887f75c0d17b87f2718b0584a94._comment |   37 +
 ..._a9d6cf6cd38bfa6f391beaf6831b0ef4._comment |   45 +
 ..._cfefa7ac1f538566ee028aa3996e22cd._comment |   12 +
 .../git_init_fails_on_a_worktree_branch.mdwn  |   45 +
 ..._6614fc4b8f191702c1b78c5a3ce5de50._comment |    8 +
 doc/bugs/git_keeps_refreshing_index.mdwn      |   12 +
 ..._bc76561ae4aaf932217c40109a8d04bd._comment |   13 +
 ..._a4c9ccb93a809aff61ae208d31ba0363._comment |   13 +
 ..._919fb06b3fc7fe9b54797a805873e3c8._comment |   26 +
 ..._b73f9c5603bc69867e1619d871a8abb7._comment |   19 +
 ..._f1b07147627b087231c776522ddc2826._comment |   10 +
 ..._e0bfde0d53042ce8d310f356f88c610b._comment |    9 +
 ..._35dff672dfd3c6fdc2b9fcdb9a58e154._comment |   59 +
 ...s_ls-files_without_--exclude-standard.mdwn |   40 +
 ..._81383cf73102346fa8d537e1dde30353._comment |   41 +
 .../git_rename_detection_on_file_move.mdwn    |   14 +
 ..._5ec2f965c80cc5dd31ee3c4edb695664._comment |    8 +
 ..._0531dcfa833b0321a7009526efe3df33._comment |   26 +
 ..._7101d07400ad5935f880dc00d89bf90e._comment |   27 +
 ..._57010bcaca42089b451ad8659a1e018e._comment |    8 +
 ..._79d96599f757757f34d7b784e6c0e81c._comment |   34 +
 ..._d61f5693d947b9736b29fca1dbc7ad76._comment |   12 +
 ..._f63de6fe2f7189c8c2908cc41c4bc963._comment |   19 +
 ..._7f20d0b2f6ed1c34021a135438037306._comment |   10 +
 ..._6a00500b24ba53248c78e1ffc8d1a591._comment |   21 +
 ..._75e0973f6d573df615e01005ebcea87d._comment |    9 +
 doc/bugs/git_worktree_remove_fails.mdwn       |    1 +
 ..._e980c49fb53a785337e206feae34d032._comment |   16 +
 ..._2c6ce2244c885bb21ca82a841987dd47._comment |    9 +
 doc/bugs/glacier_from_multiple_repos.mdwn     |   16 +
 doc/bugs/gpg-agent.mdwn                       | 5049 +++++++++
 ..._86860841aaa38541968693ec02f6a506._comment |   10 +
 ..._de6f9b8f20e44e93759b9bf0db695def._comment |    9 +
 ...es_to_100__37___cpu_on_bad_input_data.mdwn |   18 +
 ..._889218fb7c0115b03d9bad0c07296097._comment |   36 +
 ...high_cpu_usage_in_cat-file_and_webapp.mdwn |  314 +
 ..._7fee933eb54272a0447851279d31825b._comment |   16 +
 ..._f26b8846e1651c507d259b9891d26136._comment |   21 +
 ..._89dbc16c9c1b74ccb3f46d3c558e0c8d._comment |    7 +
 ...multiple_remotes_simultaneously__63__.mdwn |   43 +
 ..._311a8a43d360074abd522fff14bfcb45._comment |   15 +
 ...otes_ignore_annex.web-options_--netrc.mdwn |  294 +
 ..._314bf6c825c8b4cd49de210f20f6cde2._comment |   39 +
 ..._599a66a1833000dc0e54a33511891b36._comment |   33 +
 ..._bed5008a429dd85dbb3389994f6d6295._comment |   15 +
 ..._a67253e52fa4510073d7df60d2bd4adb._comment |   11 +
 ..._d81762737f3854c75e804bad1697b517._comment |   12 +
 ..._e13932ead5920c7599031e85127317bb._comment |   11 +
 ...configured_remotes_behave_differently.mdwn |  134 +
 ..._14fa5263ee9feedff8c36f86e4c33fd8._comment |  351 +
 ...ee_on_adjusted_unlocked_branch_issues.mdwn |   11 +
 ..._a6aed4a1d1958e4734684b78b0f0a3de._comment |    8 +
 ..._7fc16d6ff0f1a61907bc34e8f8b71add._comment |   23 +
 ..._c75eee397fc6a53aa0ff55f993b790a7._comment |    8 +
 ...ee_replaces_files_with_identical_size.mdwn |   65 +
 ..._2742c2cbde12aa85b8254dd6907fcfc1._comment |   36 +
 ..._46336dc995a7cefb8ebbfe98f098e258._comment |   15 +
 ..._2b9bdb906043aa84ea6cf0d74a685769._comment |   20 +
 ..._9363ed782b5dc8d70a323fbc2574e7c7._comment |    8 +
 ...mporttree_spends_hours_reading_cidsdb.mdwn |   50 +
 ..._a2724ab85bc91fba3bb6e55d2b1e3878._comment |   38 +
 ..._a3fc6b67529ddce9e79c0e72996259ad._comment |  136 +
 ..._c1865c88d23873eb4b32489fc387f40c._comment |  121 +
 ..._6043be5152ba2d44fb9aac4063060b56._comment |   24 +
 ..._e961d2b508e3260670bb61a5ae51d109._comment |   12 +
 ..._35d233db5f7410048bd0cf9f5b4fd5cc._comment |   18 +
 ..._d0a7af6aecf8cb070c34edec1b3e2ecb._comment |    9 +
 ..._8fe8c0747a69ea977942a399ac929e77._comment |   23 +
 ..._b5ea8e5a761b254672171c3ab41e09f9._comment |    8 +
 ..._238c26c1a3f4ab7dd6ea3b2f26febaef._comment |   52 +
 ..._41ca70e65a59d620cedc7cf46a8305fc._comment |  257 +
 ..._d6d3db42bda1fe094140d54a458157b1._comment |   67 +
 ..._9320fcfb8bd47d4ee547e81fb9e01f38._comment |   23 +
 ..._333907125ccf24c2ad8286cd40a35b16._comment |   12 +
 ..._8f609e231fdf315d2b658d30d708d471._comment |   16 +
 ..._d54f2c81763b4119c881e283cff80d44._comment |    8 +
 ..._76fe32e5ecbf37b0f173de987c59e39f._comment |   14 +
 ..._512996afefabc75a0b2258fc05ccbfdd._comment |   28 +
 ..._1b6ff858daf39dd84d4ef39a162ca914._comment |   10 +
 ..._b8b3eb5fff4ad3478dfbbd2120d4b00a._comment |   35 +
 ..._1389db945973ed42b8ddd0de3cc8889c._comment |   33 +
 ..._58155dba65976fd92cd212e13f87b888._comment |   33 +
 ...en___34__succeeds__34___on_subsequent.mdwn |   92 +
 ...ang_on_git_status_with_v10___38___nfs.mdwn |   62 +
 ..._be44453dee893cc99759f90e660c0a66._comment |   24 +
 ..._e262ec0e438557b8d70a6adc50545ac1._comment |   19 +
 ..._c863d6940528fcc543815da44e7997d5._comment |    8 +
 ..._d54eb28d30d91088de019b761a340fd3._comment |   18 +
 ..._6439cb8500ad225fc4ef43a18582b18a._comment |   15 +
 ..._a959fa6cb5b4cda423b7e75aeec2eb1c._comment |   22 +
 ...ression__58___exits_on_first_bad_path.mdwn |   59 +
 ..._360a45c65c76e71c967afee1e3d355a1._comment |   11 +
 ..._scan_ignored_dirs_without_permission.mdwn |   34 +
 ..._621066a2d1e8ff9f5edc41001dc4072f._comment |   44 +
 ...ade___60__8_annex_version_to_8_not_10.mdwn |   69 +
 ..._5b9ba56f682a991a57872d021f2ff08e._comment |   18 +
 ..._419bf4e6ebce4bcaae3afc6420da80b8._comment |   10 +
 ..._425e81639f39d723b390d114a6d9e24b._comment |    8 +
 ..._a24860bb39cf920e34fac9ee6154b69e._comment |    9 +
 ..._3293f29b78d10aaf9254ddba1af6731d._comment |   13 +
 ..._f09aa0ebe68b5db72d466ae802ce20d5._comment |   18 +
 ..._2d354e2c1fc2f1f6397fd89f71bf29ca._comment |   17 +
 ..._in_a_folder_with_newline_in_its_name.mdwn |   36 +
 ..._2690ed9441685068c291a182d39c2616._comment |   20 +
 ..._of_aws-0.23_causes_stack_bld_to_fail.mdwn |   53 +
 ...y_even_if_all_sync__39__s_turned_down.mdwn |   60 +
 ..._e4b110f61502b5d37117ec65ec39896b._comment |   12 +
 ...many_stray_processes_on_remote_server.mdwn |  240 +
 ..._b66015587ccd3ca81de52271979bd026._comment |   21 +
 ..._4f417206d5d83bd456c8e501ae272cba._comment |    8 +
 ...aped_characters_not_accepted_as_input.mdwn |  157 +
 ..._823458893eb87f1331da050d68486209._comment |   38 +
 ..._bc1f89afe38c5136beb74160ff26e519._comment |   62 +
 ..._3aafdcc1b32439ec577fb090b94c6ac1._comment |  147 +
 ..._73c1495abff5284c42a8cf0537b19df4._comment |   26 +
 ...oadlocale_error_with_standalone_build.mdwn |   44 +
 ..._96a809060ed05100b6f8e5198ec699be._comment |   13 +
 ..._e1c443ba943a5883ca63fbf05d3e5b41._comment |    9 +
 ..._acb934b9e7d91aa59f49926e658c4bbe._comment |   19 +
 ..._39366d601e4200a953fe375c7c96f106._comment |   35 +
 ..._ce08bf5b13ae0db7fa06196f56a26e8a._comment |   57 +
 ..._a852f4b40506edf9948c7953b01aa340._comment |    8 +
 ..._b387cdacf97c476284640195e9fd03c9._comment |   23 +
 ..._7820a310f6bf5f6f4c6c58fbfea8c85f._comment |    9 +
 ...ons___40__e.g._.numbers__41___dropped.mdwn |   33 +
 ..._0e3e0966f06ded18ecfd41f8084b4658._comment |   16 +
 ..._2836fe9dfa7b5140df1ce893044c254b._comment |   11 +
 ..._1f4bc975621d24e6e43d887693ada800._comment |    8 +
 ..._2cded724d1a4368dca475b89010c23e2._comment |    8 +
 ...ar__40__er__41___on_what_is_unlocked_.mdwn |   65 +
 ..._b855c810464bb22bd76681d669313ae5._comment |   19 +
 ..._71b7b4417aa63e469636a03e460c2427._comment |    8 +
 ...l_doesn__39__t_create_git-annex-shell.mdwn |   62 +
 ..._8c20edd8c6483500f807528d616c6dfd._comment |   14 +
 ..._8b2cf0fe7219e0bc83fd326adbf26c8a._comment |   31 +
 ..._25fe06eb127e59a4a07aeb52a5cfeabe._comment |    8 +
 ..._ec78032ba62d6918baa2c0b07ead5b50._comment |    8 +
 ...on_--onlyingroup_works_only_partially.mdwn |  541 +
 ..._001927fce7b1c194076f76a092af414e._comment |    9 +
 ...e_causes_out_of_memory_on_large_repos.mdwn |   26 +
 ..._6d47485728ea65a9b555f8be7159dea5._comment |   10 +
 ..._06723d13ecdaf87de5ff2b209e3c5198._comment |   10 +
 ..._9f83ef190547b291a715cda55b7977d4._comment |   10 +
 ..._0e32ae0300472c56079cfbcd78a3e386._comment |    9 +
 ..._e8998716107e7ae8d0e8d332812517ad._comment |   14 +
 ...a_view_does_not_vpop_to_original_view.mdwn |   41 +
 ..._91c69150533cb6c2147dcf2eb480ef39._comment |    9 +
 ..._ca1cc0b0e5c53daffd0b5ca78a6ac43f._comment |   11 +
 ..._63bef9006a1e4ba2ebbfafbdf605a9e1._comment |   13 +
 ..._4873f0bc670b193cec3be327ee178a13._comment |   45 +
 ..._bf63c9d3e0de468ffa5856dcf7c313b7._comment |   22 +
 ..._83e389f5fdd58ffd62ead898ddbb5279._comment |    8 +
 ..._a5511e21ee6c09d8edf2bca48482d848._comment |    9 +
 ..._ef3e8e1c47984fc674e58646052205ef._comment |    8 +
 .../migrate_and_move_duplicates_data.mdwn     |   36 +
 ..._ac3c5c141992c7b5d2cc36e085b0cba8._comment |   18 +
 ..._68a876f2eed5c446d92367aae4070408._comment |   16 +
 ...es_associated_URLs_with_custom_scheme.mdwn |  142 +
 ..._6e9a2b3ff2be4e2b3ff5b67ac913efb8._comment |    9 +
 ...d_files_not_showing_up_in_unused_list.mdwn |   62 +
 ..._2cfbf6693b051c758fe5efa5ee885829._comment |   16 +
 ..._acb1abeb32c3aba8ba65151afbea753c._comment |   10 +
 ...mimeencoding_detection_is_not_working.mdwn |   43 +
 ..._dbcdb6ae6fb1d06f4d5cf27cba4c69be._comment |   20 +
 ..._b9df7eb812a4a2fba4b1273fbffe8375._comment |   41 +
 ..._b02a321a1fd8aaeca1680cec96055172._comment |   12 +
 doc/bugs/moreinfo.mdwn                        |    2 +
 ..._when_not_present_displays_misleading.mdwn |   35 +
 ..._drop_stage_does_not_resume_correctly.mdwn |   14 +
 ...debug_for_failing_to_get_uuid_or_key_.mdwn |   45 +
 ..._6c3efd1922015a20daf93bea54fc6431._comment |   24 +
 ...epo_with_git-lfs_as_only_annex_remote.mdwn |   42 +
 ..._804ecf5218ce147767352fea8ea5eae8._comment |   21 +
 doc/bugs/no_git-annex_shell_on_Windows.mdwn   |   28 +
 ..._72b2277c3728f02e4d158ebbd7db41b2._comment |   22 +
 ..._b212c8b8cf361745f35a9f7ff6fee1f5._comment |   11 +
 ..._9d445ddf84e15a59cdc2aa2b8dc30c44._comment |   15 +
 ..._988768c3e4f30c751034a0b0390cdd88._comment |    8 +
 ..._70a6c9af57eed4f8ceb3de63cbf8a5e6._comment |   10 +
 ..._7f48959c6242c5cc52e9d0a79fd3f85d._comment |    8 +
 ..._04b30dd9e510762ee547e7b45bdba660._comment |   12 +
 ..._beebbd4a41cccfc7aac3c19d76c3b978._comment |    8 +
 ..._957c5da5f336c7ef59e4149602471888._comment |   15 +
 ..._a8654cf656de55ccdcf40270a1ef4ca9._comment |   35 +
 ..._3c8bb1b1d67ca1a6e568e381d24a2574._comment |   16 +
 ..._03646c9df9d4f4ea27459660fe65a976._comment |   25 +
 ...ay_to_disable_repository_auto_upgrade.mdwn |   49 +
 ..._aab2cb260b68c25facd652946ea2aff7._comment |    8 +
 ..._dc24c6c0c60bb11d6d871fa62585276d._comment |    8 +
 ..._f3c10f35956dff886d961f1351af71ef._comment |    8 +
 ..._7ea295a6c113ea0cc3e4e5ae28769190._comment |   19 +
 ...rserved_when_exporting_tree_via_rsync.mdwn |   15 +
 ..._b92c67f7d2f0424ce399ca4659e6c805._comment |    9 +
 ...rd_output__41___from_git_annex_status.mdwn |   89 +
 ..._fcd230cbb2ac363c469b98021042c011._comment |   10 +
 ..._23207ecabd4b41d9551d0491fa71e96b._comment |   12 +
 ..._6ea92adfe955b6a5cd2a39fea78b3bf6._comment |  119 +
 ..._d0e55585f1612148163039d157253258._comment |   11 +
 ..._5506dc1b08516677886da4aa97263864._comment |   12 +
 ..._073449cc2cb73efd2b2d3d778a5573de._comment |   14 +
 ..._3516e71ba3b07427a10cbb4965712aa6._comment |   24 +
 ..._ea2e4704adb2f304f9c11c61eb62e919._comment |    8 +
 ..._4d17fedead7977541371a3f2c192e030._comment |   46 +
 ...ys_not_in_Windows_release_10.20230803.mdwn |   38 +
 ..._9969cdc389617f4df2ee286e8d28176e._comment |    7 +
 ..._b265af06b8edda75d305fd836f6c5242._comment |   13 +
 ...se__95__hiddenXXXXX_files_left_behind.mdwn |   52 +
 ..._b96ea3ece44d42e79e4d903ca66065ee._comment |   12 +
 doc/bugs/openTempFile.mdwn                    |   59 +
 ..._48b9ab6e3d4b24ec34d2a99b5a4ff619._comment |    9 +
 ..._a09c4a7d346c3b0f7025e6f3a276adb8._comment |   14 +
 ..._9b9f35c8ed31ca62b34d216c6906304c._comment |   22 +
 ..._3397f9ddb94d4acb8af778ec15487022._comment |   12 +
 ...egression__63___init_takes_times_more.mdwn |   57 +
 ..._7aed761c4843217ea4c90491897224c1._comment |   19 +
 ..._847e04bbe9c59700249136b7fef4d0b7._comment |   12 +
 ..._603d7228668a36dc848e706cdff64035._comment |   50 +
 ..._a79fcbe80060d11582989a9fc31d4a92._comment |   15 +
 ..._8c3b13806adb731435b346a64990527b._comment |   19 +
 ..._145e29b42c46f15efc21c6d1ef9dd82d._comment |   62 +
 ..._783ada9438a00c0a23357bea2f19d0a1._comment |    9 +
 ..._d13e85f691165b533d6630a93111c786._comment |   18 +
 ..._13ce5ec87207d553388ec23663d9abcb._comment |   11 +
 ..._3f32fa3c6de412bfdab8a4e67a30012c._comment |   18 +
 ..._5e0a9e36870cd21bed351ca37ffe9914._comment |   25 +
 ..._d92bd84ab3f218eb6ad38fcc7f54c223._comment |   17 +
 ..._a3a5c3182ecb9fdef82f4959af516d9a._comment |   42 +
 ..._652424afbe5484a679c55d437cf1e7a1._comment |    8 +
 ..._3961ac7f22f42886f0e30f62f1cb0c5d._comment |    9 +
 ..._0894259447bde6d676c629d5bce2a6ba._comment |   21 +
 ..._7ce86149c0d839f6d2b14f76bab288be._comment |    7 +
 ..._d4ba8c726e8b74d4692caf0d4afd214c._comment |    8 +
 ..._choice_of_name_for_adjusted_branches.mdwn |   26 +
 ..._adbbc90054eafefa7de58663868986a3._comment |   30 +
 ..._dc7b2ae4971324d34f6a8d89e888f598._comment |   21 +
 ..._19ce066c0b912398300caf8520f70eb3._comment |    8 +
 ...nt_does_not_allow_spaces_in_filenames.mdwn |   33 +
 ..._ca10638d4b4b178cfd0de8736542c4dc._comment |   12 +
 ..._986a393a512229d35e529ba242b77b1e._comment |   10 +
 ..._a66be1cc2c4ca7e470be1248dcbbe885._comment |    8 +
 ..._7a8f1ba849f6e6f6072c39bdbff49405._comment |   13 +
 ..._directories_are_dropped_after_a_sync.mdwn |   41 +
 ..._9d7591faf99ce48b1e5753c80306ae8b._comment |   10 +
 ..._7316cba69b9dc0415fea1389238edf25._comment |   14 +
 ..._0d53226a3991e3685d1311e4b19c4023._comment |   55 +
 ..._68bd50c6aeffc06d53eda7f38b06edee._comment |    7 +
 doc/bugs/problem_commit_normal_links.mdwn     |   59 +
 .../problem_with_upgrade_v2_-__62___v3.mdwn   |    3 +
 ..._5f60006c9bb095167d817f234a14d20b._comment |    8 +
 ..._cd0123392b16d89db41b45464165c247._comment |   23 +
 ..._86d9e7244ae492bcbe62720b8c4fc4a9._comment |   16 +
 ..._91439d4dbbf1461e281b276eb0003691._comment |    8 +
 ..._ca33a9ca0df33f7c1b58353d7ffb943d._comment |    8 +
 ..._f360f0006bc9115bc5a3e2eb9fe58abd._comment |   10 +
 .../proposal_for_timestamp_semantics.mdwn     |   13 +
 ..._a54fc1bda24e04b15490d0eaa1838d28._comment |   19 +
 ..._8ba9e0c35e7761b99feb55bcdd6065cf._comment |   15 +
 ...oesn__39__t_work_on_adjusted_branches.mdwn |   29 +
 ..._2c5f51483b2f2521d98f943d8ded3acd._comment |   47 +
 ..._632a3616516605de477930ae09d4ca60._comment |  131 +
 ...ce_then_stopped_running_opensuse_13.1.mdwn |   13 +
 ..._a9daf9e8f968b32f25e236f53ea4b845._comment |   14 +
 ...nishing_when_assistant_gets_restarted.mdwn |   34 +
 ..._53b4f388c47c1b3f6ffa4fc2155b30fc._comment |   21 +
 ..._e66532b23b089c9ea61122d6664cddb9._comment |   10 +
 ..._c9d692c867acc076f64f1213ea03ca11._comment |    8 +
 .../redundant_transfer_not_prevented.mdwn     |   56 +
 ..._does_not_register_if_external_remote.mdwn |  106 +
 ..._124bbd63a2a85004ff9cf965ad984fb4._comment |   29 +
 ..._0f4d7c7f208b965ece8f017a38d7d0f1._comment |   13 +
 ..._31330afe2ea5e543219edb9e8071239b._comment |   35 +
 ..._4f2c98add8a4f7b9f49e54e12fd79f10._comment |   64 +
 ..._b9057ce47bb57b3a3dbe390672310898._comment |   18 +
 ..._7a96a8a05e4a45477ec8b4eaea9374b1._comment |   10 +
 ..._649f04c1909ab803eabe2eea7f37c6fd._comment |   19 +
 ..._542bd923122ba24fe9cb14d36b97f15d._comment |   14 +
 .../regression_with_S3_creds_not_used.mdwn    |   59 +
 ..._df5416ee63c8f026f3b3c77c74b67ce4._comment |   20 +
 ...heir_symlink_targets_don__39__t_exist.mdwn |   67 +
 ..._8a1d16b2aaba224e94be3d9dcc036d91._comment |   12 +
 ..._434ed328a22a6657dba3b2929a56e499._comment |   18 +
 ..._1837b70ace42882db3ab82e001680934._comment |   29 +
 ..._ca9c87a10f29e41572540edeb99652f2._comment |   11 +
 ..._69eafc4201e3014ef1b5d74fe319e462._comment |   10 +
 ..._b7a64db9abe006af8c30169ad849efe9._comment |   76 +
 ..._197ac6070f256131c6e18a07aa3834fa._comment |   14 +
 ..._fe07832333b536c71b7dcb46a4a44bd0._comment |   19 +
 ..._540bca4e6fdfc10eeab875ecc0f2b3f3._comment |   10 +
 ..._3f236b35e9820cd88bb77fcd57d6975e._comment |   43 +
 ..._3cc5dae0351201522711a7caeecd60d5._comment |   10 +
 ..._3c3883cb66d02a15d5de84d22aa113da._comment |   38 +
 ..._c8cece9559bd2dc6154cd28772369e48._comment |   10 +
 doc/bugs/remote_not_showing_up_in_webapp.mdwn |  100 +
 ..._2a269732fd528f505777542d3556437a._comment |   17 +
 ..._10638e99e2e11460f99266f56adbc1db._comment |   10 +
 ..._4aa72acc0938f7f824ba10f3f102e8bc._comment |   16 +
 doc/bugs/remotes_disappeared.mdwn             |  300 +
 ..._7b7bfa0b2c9e66edd92c076e5c6ccdd7._comment |   21 +
 ..._b9dae978aeeee5e5d246192fed813b3f._comment |   13 +
 ..._794372fb37621f37478313abc4ee92cf._comment |   38 +
 ...dows_reports_ambiguous_argument_error.mdwn |   77 +
 ...fails_when_unlocked_empty_files_exist.mdwn |  171 +
 ..._66ff5ff20c4a1561943f8fc144a4dfb5._comment |   70 +
 ..._28e204f5db91eaa258428d89cbb9f6c9._comment |   10 +
 ..._68ddf1256149eec1ac01fb915d26bac3._comment |   35 +
 ..._785200bbdc9efabed141ecd51cb015a4._comment |   61 +
 ..._3b5f7c44de6b17e042adaa77a8bed2f8._comment |   17 +
 ..._baa4f1e895ff351b16f54d59851d2a6f._comment |    7 +
 ...rsync__58___protocol_version_mismatch.mdwn |   38 +
 ..._672d89a7d06d5ec336381b670a41a9c7._comment |   12 +
 ..._531b85c911d390b1b93ee55a8cf5d47e._comment |   11 +
 ..._eff8f33134157635387ee681805ff7a8._comment |    7 +
 ..._77e59a25c859b6afec8b75f74885ef5e._comment |    9 +
 ..._7d819c3e4af2b8044a52fa6131f36187._comment |   22 +
 ...nc_error__58___syntax_or_usage_error_.mdwn |   85 +
 ..._464d733de18f6ca438ebd84e88b8cee2._comment |   29 +
 doc/bugs/s3_InternalIOException__63__.mdwn    |   28 +
 ..._42bd2d1e364203f1b34efcc34ac795b8._comment |   14 +
 ..._994dd3ebcf7eaacb0b9e06f1bc14a2d4._comment |    7 +
 ..._a69927ec705efa31aacb5941bf8d8f9d._comment |   14 +
 ..._ee791ad24d5d2c0ad4f82ecf6fc434a9._comment |   28 +
 ..._134d1d0ad9f59a2b7498d1ed335cf91a._comment |    9 +
 ...___public__61__yes_sets_disabled_ACLs.mdwn |   41 +
 ..._0bf1f463133476727129ddf15f24983b._comment |   43 +
 ....bareRepository_breaks_git-annex_uuid.mdwn |   21 +
 ..._0a5faade2dfbb0dfe5d94d37450ba06c._comment |    8 +
 ..._annex__63_____58____47____47____47__.mdwn |   58 +
 ...ecurehashesonly_conflicts_with_addurl.mdwn |   17 +
 ..._808e276381f98b4ebb7d61628db703d9._comment |   18 +
 ...ryption_bypassed_if_gpg_error_on_init.mdwn |   27 +
 ...o_use_ssh_hosts_from_.ssh__47__config.mdwn |   26 +
 ..._3dac095b7cf799e31925868d13888970._comment |    7 +
 ..._342b4913a063184650cdf4f541f7ea02._comment |   10 +
 ...d_create_leading_dirs_for_annex.dbdir.mdwn |   73 +
 ..._20cbcee65bccc3213e437ef347b52612._comment |   20 +
 ...d_error_on_whereis_--batch-keys_--all.mdwn |   25 +
 ..._724ae0427fb306352ff9b26d9fdef27a._comment |   10 +
 ..._when_attempting_to_add_ignored_files.mdwn |   31 +
 ..._f1208fda822d17a3a9e5457324fdd1df._comment |   39 +
 ..._9fe7fd6296db34ee8ee07fe68459e74b._comment |   17 +
 ...flict_resolution_tests_fail_some_time.mdwn |   57 +
 ..._bd9963c2a40b55bf745ce3d801a5da19._comment |   14 +
 ..._f7b38a6da0ce74c1d4224a37aad9246a._comment |   11 +
 ...l_remote_adb_-_Argument_list_too_long.mdwn |   56 +
 ..._34f202f91a16dd4d2bb557aee6fd5a3e._comment |   12 +
 ...e_variables___40__not_under_git__41__.mdwn |   17 +
 ..._3d162dce2af8d84c5582cf63624e9310._comment |   19 +
 ...ed_to_escape_characters_in_the_output.mdwn |   66 +
 ..._1d0f25da3af46d211445d10f0d6c143e._comment |   40 +
 ..._76c80e98cc2d26e4cebaac6e40e76df9._comment |   41 +
 ..._0fe421cd62c36804a78e4b424302e3d7._comment |   37 +
 ..._d3c423c3faecc115bb5bab3471226ee5._comment |   14 +
 ..._783b2bdf1826f472d8f39d01e81adf20._comment |    8 +
 ..._b8da1f30c5bc88f4ddb7878d790823cd._comment |   29 +
 ..._c855cc0728c71e9a4696a192cd331213._comment |   18 +
 ..._ee066c129d808ac511c0efce9a644ab9._comment |   16 +
 ..._41bac25db7cc8978659c2e202960a2a4._comment |   15 +
 doc/bugs/startup_scan_extremely_slow.mdwn     |   69 +
 ..._68f88f04c179800c0ce1ff6925d4c6ab._comment |    7 +
 ..._116e850299372027481c9d0a1667d5af._comment |   25 +
 ..._3eb4c2290e560451e7341b85b58212b0._comment |   14 +
 ..._ade878000a050c87a345e8bc9914deba._comment |    7 +
 ..._4ee924e70d5a8e35e706eaaff4cc76e1._comment |   28 +
 ...ng_errors_with_parallel_git-annex-add.mdwn |   17 +
 ..._b38f13a4c28ad8ce26aef72e7d6fcb11._comment |   15 +
 ..._96312bab546412b1eecfa74aec1d7fee._comment |   11 +
 ..._e76ddebaf9d248c02d16a6914973d7d0._comment |   15 +
 ...h_the_annex_directory_exposed_to_http.mdwn |   20 +
 .../surprising_import_tree_merge_result.mdwn  |   18 +
 ...x_branch_not_syncing_in_the_assistant.mdwn |   49 +
 ..._b832288844a3e7e944fa08a6edb97d29._comment |   18 +
 ..._fbfc8929497f609916d9f3e5a0a9b531._comment |   18 +
 ..._succeeds_w__47__o_fetching_all_files.mdwn |  101 +
 ..._500bc8f48ae80841e0db21ee0de76c50._comment |    8 +
 ..._9581f8135c6eb2ed2135f83a266e5306._comment |   27 +
 ..._dbc8ad383c4968b1ab78ac86bab06329._comment |    8 +
 ..._23a16e94a0f18126caa6cb2f94131277._comment |   20 +
 doc/bugs/sync_-C_can_export_other_files.mdwn  |   17 +
 ..._7a6ab3ee25f0d09df4d7478d26ea2d37._comment |   30 +
 ..._loss_but_seems_to_just_lose_tracking.mdwn |  218 +
 ..._562cf3ab3398c1ef874c0bfe5d89e47b._comment |   10 +
 ..._f686273c6be899d2a8bbaabd03a47fbf._comment |   14 +
 ..._fd518d0601587dc5c718944d0b6f51fc._comment |   10 +
 ..._a6074b68754b0d773385a1e406043952._comment |   10 +
 ..._does_not_merge_after_branch_rollback.mdwn |   34 +
 ..._8c5f4787a6156802d00cfad1f7d2ee31._comment |   30 +
 ...sync_does_not_propagate_forgetfulness.mdwn |   35 +
 ..._acc9744be183c297c6410f9b0a30b46b._comment |    9 +
 ..._content_with_new_remote_on_first_run.mdwn |   23 +
 ..._c1df7f51ac724400dbef664ce10784a8._comment |   10 +
 ...hen_ran_in_other_than_tracking_branch.mdwn |   18 +
 doc/bugs/tahoe_remote_has_no_repair.mdwn      |   27 +
 ...y_test_limiting_broken_by_concurrency.mdwn |   19 +
 ..._e043a71b60999cf97bd872d8b32fcac9._comment |   16 +
 ...posix__95__spawnp_broken_10_on_darwin.mdwn |   25 +
 ..._5741fabaa561b81989cc176e9acb4a99._comment |   30 +
 ..._3fb2b47ade727a1bc6a99120b68d98b7._comment |    8 +
 ...hDirToFileAbs__95__basics_fails_again.mdwn |   55 +
 doc/bugs/testremote_failure_with_s3.mdwn      |   79 +
 .../testremote_is_not_honoring_--backend.mdwn |   41 +
 ..._2b119f8bce39266630dd7c0f4d8add98._comment |    8 +
 ..._f804c33243606cab4495238511e59743._comment |   24 +
 ..._1261222f79d9dbc8cf92f6466361e113._comment |   24 +
 ..._b6b4e0b7446f445591ac617e28e249e3._comment |  245 +
 ..._96a03ff1d7339643e8f74e6e536e8f83._comment |   21 +
 ..._7a9cb82671ff8a459886a84e66cb2417._comment |   15 +
 ..._ed8668ea11a905b90892eb684f93a4ed._comment |    9 +
 ..._3f17e1804ff779c5f9d00e56daf18ee3._comment |    9 +
 ...de_124__34___with_HOME_and_PWD_on_NFS.mdwn |   38 +
 ..._dd4734cec6290cd3eacd58545ef039e4._comment |   15 +
 ..._da46fc7a6bbdae0c3b44d241bc527b55._comment |    8 +
 ..._82b8570c9496ee1b111dbd1ea53e823c._comment |    8 +
 ..._e854aae525b7d4902fe2bc0f2c11ae5a._comment |   10 +
 ...does_not_support_Extended_Main_Secret.mdwn |  101 +
 ..._731db4542017bef831bc7a06b70f79fb._comment |   26 +
 ...ng___34__Transfer_stalled__34____63__.mdwn |   73 +
 ..._db83f6a38cae36da89f0ab4ef83021d8._comment |   40 +
 ..._2aeb065a257729e852055533aff04650._comment |   22 +
 ..._f8bd6a233d835bdc413bbf0127608431._comment |   20 +
 ..._320828c8d39d1f030d1797b539dbb22e._comment |   10 +
 ..._9fc2d7f4b39615e43bce3993e0a6e647._comment |   25 +
 ..._1b2eb9993e220082f3be5dd568deef3e._comment |   21 +
 ...ections_during_sync_of_gcrypt_remotes.mdwn |   27 +
 ..._8522285987f6d231c851861418af633a._comment |   24 +
 ..._f87b3ba05c0cdfadd4d5da894dea0abb._comment |    7 +
 ...s_problems_on_non-linux_based_systems.mdwn |   20 +
 ..._1d38283c9ea87174f3bbef9a58f5cb88._comment |   10 +
 ..._bf112edd075fbebe4fc959a387946eb9._comment |    8 +
 ..._a46080fbe82adf0986c5dc045e382501._comment |    8 +
 ..._760437bf3ba972a775bb190fb4b38202._comment |    8 +
 ..._060ba5ea88dcab2f4a0c199f13ef4f67._comment |   10 +
 ..._548303d6ffb21a9370b6904f41ff49c1._comment |   42 +
 ..._7ca00527ab5db058aadec4fe813e51fd._comment |    8 +
 ..._881aecb9ae671689453f6d5d780d844b._comment |    8 +
 doc/bugs/uftp_5__58___invalid_key_type.mdwn   |   55 +
 ...committed_changes_staged_in_the_index.mdwn |   39 +
 ..._1c0cad1076d5d4d908b8297e7c13ea33._comment |   32 +
 ..._4609f9a1545b08e08021bf786561f5e5._comment |    9 +
 ..._6c99a97d56b1a3b12092c15fafcf8761._comment |   35 +
 ...nit_fails_when_I_symlink_your_symlink.mdwn |   39 +
 ..._3fe7520813dee36ffb5419ed70ea43b5._comment |   24 +
 ..._3afdea4f3705a9cfaa971ed3aa9f114c._comment |   18 +
 doc/bugs/unlocked_files_feel_too_slow_.mdwn   |   35 +
 ...ork_when_drop_cannot_possibly_succeed.mdwn |   30 +
 ...sable_with_ghc_8.10.7_on_DragonFlyBSD.mdwn |   46 +
 ..._70b807c69be263fd53c578fe6ec84561._comment |   26 +
 ..._eeff3cb51df849b783446e238de002a8._comment |   11 +
 ..._641473e43c8da7e7be02658cf8d3bd3e._comment |   16 +
 ..._59e2ea4d59d5f4a8472cc8c945b8a419._comment |    7 +
 ..._27a017a942f805e9b0216e77d4890c86._comment |    8 +
 ...to_export_to_directory_special_remote.mdwn |   44 +
 ...te_format_generates_irritating_output.mdwn |   30 +
 ..._fceba878f1097e27f056580e8d6d5b31._comment |   26 +
 ..._416992874813f120721a56d88b2bef65._comment |    9 +
 ..._a20f470c5226ac5693eb15146a02b3f5._comment |    8 +
 ..._a81f06191bc03a7aad5929af99f0634e._comment |   28 +
 ..._7438caecf78b4fb5d21f9f31dff95cf2._comment |   14 +
 doc/bugs/v6_appears_to_not_thin.mdwn          |   80 +
 ..._d62791da504f6cf9bb26fa588756234c._comment |   36 +
 ..._82ff17c4063791d91a4fbe4e31802595._comment |   82 +
 ..._69afd9bc3f250418ba33cb1abeb2078d._comment |    8 +
 ..._bba7ba9c5b93fa33fc728daa0bb89497._comment |   31 +
 doc/bugs/v8_repo_auto_upgrades_to_v10.mdwn    |   19 +
 ..._446aa74f0b54918dc8737483e3e8564a._comment |   14 +
 ..._and_description_often_not_propagated.mdwn |  154 +
 ..._60c5ba2de0c8b9b4538a4abd146007f6._comment |    8 +
 ..._d56aed617e0791aa17d9f37c8d3fd317._comment |   12 +
 ..._of_adjusted_branch_doesn__39__t_sync.mdwn |  149 +
 ..._3c0be3ff163aae411f323e3445af94b1._comment |   10 +
 ..._utf8_for_chars_that_does_not_need_to.mdwn |   37 +
 ..._a6014d95b0ac0dc20e9495a717d6d615._comment |   17 +
 ..._323f1be80e2422e73ebd99b702a28e80._comment |   12 +
 ..._576c31b2cc5031cfb64ff58a1866b3b5._comment |   34 +
 ..._4097e8dde9d9fe29b540112f7400689a._comment |   20 +
 ..._5e5441cca2f3bbc252029aca358e9a47._comment |   10 +
 ...le_to_convert_submodule_to_form_that_.mdwn |   41 +
 ..._1d3214382c2bb604101a835c0bb7f146._comment |   18 +
 ..._7f4800ee68c98606bc8a3ce959646014._comment |   20 +
 ..._54c9716cd5cab7b196549af2f90bed0a._comment |   19 +
 ..._864988b3ebc11ea9e92c55ee765d6d5c._comment |   27 +
 ..._06d31ed5a8c187cec7bc90339550b5e8._comment |   24 +
 ..._5e7007182372d28ceb11a8692e2cf801._comment |    9 +
 ..._4de04de71792801f50256214f4b5fe9f._comment |   10 +
 ...ebapp_--listen_port_is_not_used__63__.mdwn |   23 +
 ..._275507b26ca13e5d55deec4b7af60699._comment |   25 +
 ..._55315d9013fc6acbde9f8b419757d949._comment |   12 +
 ..._2d18df9587b52cbb7c34bfce2e0f2fb2._comment |   15 +
 ..._ba217465bfa738b77ea9417a33810d75._comment |   22 +
 ..._99a6933f30649bc33ee5c74b33fc7046._comment |    7 +
 ...ifficult_to_abort_adding_a_repository.mdwn |   24 +
 ...40__server__58___radicale_0.9-1__41__.mdwn |   45 +
 ..._487bf264afeef2a3b0a61d306ebfc3c5._comment |   12 +
 ...with_annex.thin_true_about_hard_links.mdwn |   76 +
 ..._cb6c6e7bcbbe3006dd80e89fa545016d._comment |   25 +
 ..._146ed4bf42ce1979815db82bbf9a5b86._comment |   10 +
 ..._57924a0a08da3cafe78b95bf22ae89fd._comment |   18 +
 ..._4a7ec33d4470714c9fb4271d214b3d1f._comment |   11 +
 ...4__numcopies__34___on_duplicate_files.mdwn |  299 +
 ..._169d4f769e4ba6a81aaa7ed32c789b50._comment |   35 +
 ..._d20cb1d0abc9823aa557dcd698e735b2._comment |   12 +
 doc/bugs/weird_unicode_bug_on_windows.mdwn    |   17 +
 ..._69af9bd8c7898fccc2219edd860d547b._comment |   12 +
 ...lable_both_here_and_in_another_remote.mdwn |   30 +
 ..._d823b7ee32183fbadd4a49f65e1a3a8b._comment |    8 +
 ..._f430538101f0ef6114b5e953248fa599._comment |    8 +
 ..._d96ded3c27c705789e5689f19dbcabcb._comment |    8 +
 ..._b70e83a44a85b006c2c6105660cd6a7a._comment |    8 +
 ...uts_no_informaiton_for_unlocked_files.mdwn |   46 +
 ..._47bd0fc8d1c65f8a868d9722e66c71db._comment |   10 +
 ...reated_despite_alwayscommit__61__fals.mdwn |   66 +
 ..._57c55f62ced563f70612cba994b1ea8b._comment |   28 +
 ..._fcdc6ef1dd464d25ec3e26dac828830e._comment |   17 +
 ..._0460c7476fae95048f87cb6dd9d4a2ae._comment |   22 +
 ..._65647b8423127d450b0d1753767943d6._comment |   12 +
 ...y_reminded_to_run___96__restage__96__.mdwn |  182 +
 ..._e738eb3d45bb7c4baa0a5c88cdf7a40a._comment |   13 +
 ..._8ecb958a1a2c8cd9fd37798c0d4eb0cf._comment |   11 +
 ..._aed127be0616464fda064f00de954fc2._comment |    7 +
 ..._42ef3d3d157a97a202718f3b768916f8._comment |   45 +
 ..._8f71510a7547db8d0c63e4a4e3ddbd65._comment |   47 +
 ...repo_tests_fail_after_commit_5a98f2d5.mdwn |  217 +
 ..._af091a5799ac0445033c05173e25a4af._comment |   16 +
 ..._5c7ec0d8520f957ec4f6a4df30941cd8._comment |    8 +
 doc/bugs/windows_autostart.mdwn               |    4 +
 ..._80a2561901554ddb45db719c086629b2._comment |   11 +
 ..._89078768dc9d9efd2d237fff5c7320ad._comment |   12 +
 ..._393899b1630cce0dc6b12ec7d29b81ca._comment |    9 +
 ..._b8d0b38aa7363e97c295b049bd939ad1._comment |    8 +
 ..._43077649e3ca6a132958c2a2b4914c3b._comment |   12 +
 ..._fails_starting_from_commit_54ad1b4cf.mdwn |  122 +
 ..._c353c67f06f40c84b956990160205e0a._comment |   84 +
 ..._bd9a77da095bffdcd3ed30e08192b9d2._comment |   19 +
 ..._c46e7c7f3870b54563eb8e94d451fded._comment |   22 +
 doc/bugs/windows_ftbfs.mdwn                   |   44 +
 doc/bugs/windows_started_to_FTBFS.mdwn        |   35 +
 ..._094012512e6c267f05d3d61c0ed638a0._comment |   52 +
 ..._1ad4a7da4dd4353838fd5c1f9610ee32._comment |   26 +
 ...e_lock_files_withcoresharedrepository.mdwn |   24 +
 doc/builds.mdwn                               |   65 +
 doc/chunking.mdwn                             |   43 +
 ..._ddbc7a66de2def23cbf1e1de7defde08._comment |    8 +
 ..._d43c297db9a31d1c896b48f0e3757229._comment |    9 +
 ..._7305da05dff79b9cabc59af162db9925._comment |   14 +
 ..._f098bf5a5d07b10d5be41658790547ad._comment |   10 +
 doc/coding_style.mdwn                         |  113 +
 ..._70521cf79ad06832b1d73fc2c20c68ec._comment |   20 +
 ..._a820b7c8ae7c2290eb000f61bdb5c514._comment |    8 +
 ..._61c178b997dd044f3531303913f8fa91._comment |    8 +
 ..._433b7ba5e51e746f6b033ebb5c0e50a2._comment |   22 +
 doc/comments.mdwn                             |    9 +
 doc/contact.mdwn                              |   11 +
 doc/contribute.mdwn                           |   77 +
 ..._0b07e1baa5e89ba24f66c077719985e9._comment |    9 +
 ..._c61530e14bdbd7c5ec8b0137c0da92f8._comment |   19 +
 ..._637b05cfd48d2e337c3192989356d183._comment |   10 +
 ..._e7219514f52207fcfb97aeec03241e8d._comment |   12 +
 ..._21a75c774757f27911a9249f9b42368d._comment |   11 +
 ..._c5f7f809da5829f4c259d0a630f0f722._comment |    8 +
 ..._7b53ed13f455879a7462d74571283063._comment |   30 +
 ..._a721a4abf10ae3a1e591f81b9069387f._comment |   10 +
 ..._1b6c02d7ca6a36e4b1ce2bc52570c7fb._comment |   13 +
 ..._62f827dd014481f41d77f4afec0b1de2._comment |    9 +
 doc/copies.mdwn                               |   48 +
 ..._af9bee33777fb8a187b714fc8c5fb11d._comment |    8 +
 ..._1214610c03193cb9dd76dc24e5b7fd76._comment |   10 +
 ..._5beb9a5b87dd6775f9b921ad1e9bc610._comment |   14 +
 ..._0daa1b3ecc2a4cf844b8f1b98a883e67._comment |    8 +
 ..._cc4cd8f739d4e72614c0b98f00e3510d._comment |   11 +
 doc/design.mdwn                               |    6 +
 doc/design/adjusted_branches.mdwn             |  316 +
 ..._5bdbf54ae75f77c69c8f557f4dbac13d._comment |   10 +
 ..._ff7cbdf93f0be5886f212bdd411efb5b._comment |    9 +
 ..._e2a4b1719ba9860da711b802de64daf5._comment |   10 +
 ..._adfcbfa7a9193318cba459766a60c072._comment |    8 +
 ..._882520747d41500d0ea8a18ab817121c._comment |   22 +
 doc/design/assistant.mdwn                     |   45 +
 doc/design/assistant/OSX.mdwn                 |   13 +
 ..._9290f6e6f265e906b08631224392b7bf._comment |   14 +
 doc/design/assistant/android.mdwn             |   42 +
 ..._316bde8d22628e5e9d4f8dabce1d2ad4._comment |   14 +
 ..._cf801ce1f49f0201681f0c9f69a62aae._comment |   14 +
 ..._8be9a74e5fc4641c2bf2e1bb7673dd59._comment |    8 +
 ..._3dd386ac1b757c73d14f14377b9eedd4._comment |    8 +
 ..._5dca47a4599d6e88d19193701c5a571b._comment |   46 +
 ..._054f06311e2b51d73be569f181eb004f._comment |   10 +
 ..._bb3d36e9d29f2fa77bee6d47ef9917fe._comment |   21 +
 ..._fee32a831eeb5736fe1dce52e30320c8._comment |   16 +
 ..._d8e9b0a5287fc96b19dc2cb9da3586ce._comment |   17 +
 ..._79a7b5bb5f4aaeea4a4e8ced0561701a._comment |   11 +
 ..._55ea70a6929523d26248ff6409b04a6e._comment |   10 +
 doc/design/assistant/blog.mdwn                |   11 +
 .../blog/day_100__cursed_clouds.mdwn          |   19 +
 .../day_102__very_high_level_programming.mdwn |   37 +
 ..._c028b403261dd66bcf83e6ffd134b80b._comment |    8 +
 .../assistant/blog/day_103__bugfix_day.mdwn   |   25 +
 doc/design/assistant/blog/day_104__misc.mdwn  |   18 +
 ..._13d7fad2d3f8eab10314784c035e2a16._comment |    8 +
 .../assistant/blog/day_105__lazy_Sunday.mdwn  |   43 +
 .../assistant/blog/day_106__lazy_Monday.mdwn  |   10 +
 .../assistant/blog/day_107__memory_leak.mdwn  |   11 +
 .../day_108__another_zombie_outbreak.mdwn     |   33 +
 ..._194c48d65993462f809a2cfaa774a3e2._comment |   11 +
 ..._ef5ee5933fcadcb81cc81b816db14bda._comment |    8 +
 .../assistant/blog/day_109__dropping.mdwn     |   16 +
 doc/design/assistant/blog/day_10__lsof.mdwn   |   54 +
 ..._9b8c28c85c979f32e5c295b6a03c048e._comment |    9 +
 .../blog/day_110__more_dropping.mdwn          |   55 +
 .../blog/day_111__config_monitor.mdwn         |   18 +
 ...ow_for_something_completely_different.mdwn |   50 +
 ..._5e4fe1538d9ae1c450b0a6602fc6d29b._comment |   10 +
 ..._c5a734f611ecc95729904e645583ee43._comment |    8 +
 ..._46b16dcd0fce07036cd8ed6ed9d2b055._comment |    8 +
 ..._1fe036e4c65fb4211aa2c394f535344a._comment |    8 +
 ..._e4ba3568c4efd98f212dd47427a1cf47._comment |   10 +
 .../blog/day_113__notifier_work.mdwn          |   22 +
 doc/design/assistant/blog/day_114__xmpp.mdwn  |   56 +
 ..._c2b0617a2fc3dc4f19a6be6947913842._comment |    8 +
 ..._d14375dfb5791615802dab3c5438f8e2._comment |    8 +
 ..._6d72ea32c111e605be30ad2153fc71c9._comment |   10 +
 ..._e51d6f854db5f9e74a1aa58bd8923795._comment |   12 +
 .../assistant/blog/day_115__my_new_form.mdwn  |   17 +
 .../assistant/blog/day_116__the_segfault.mdwn |   25 +
 .../blog/day_117__new_topologies.mdwn         |   41 +
 .../blog/day_118__monadic_discontinuity.mdwn  |   15 +
 .../blog/day_119__time_for_testing.mdwn       |   12 +
 .../assistant/blog/day_11__freebsd.mdwn       |   50 +
 .../assistant/blog/day_120__test_day.mdwn     |    2 +
 .../assistant/blog/day_121__buddy_list.mdwn   |   10 +
 .../assistant/blog/day_122__xmpp_pairing.mdwn |   29 +
 ..._e95efb23eb2e67e3f11a5c7de56424a7._comment |   10 +
 ..._30e251e73146512bde8b2f69eddeef2e._comment |    8 +
 .../blog/day_123__xmpp_insanity.mdwn          |   49 +
 ...ay_124__git_push_over_xmpp_groundwork.mdwn |   28 +
 .../blog/day_125__xmpp_push_continues.mdwn    |   15 +
 .../blog/day_126__mr_watson_come_here.mdwn    |   52 +
 ..._ee1361e6b235f4e1c00596ba516b519a._comment |   10 +
 ..._8eb366ae7efb347bd3bbd9a98e0821b3._comment |    8 +
 .../assistant/blog/day_127__xmpp_syncs.mdwn   |   35 +
 .../blog/day_128__last_xmpp_day.mdwn          |   49 +
 ..._fd8c1d6358cb50f4dad8ba11d33d861f._comment |   10 +
 ..._43664b73c71c41d71bc95e665f128106._comment |    8 +
 ..._d369b04f686009a9dbb57b999107a55e._comment |   11 +
 ..._095855d301e7ccd3689ffe507cfb63ee._comment |    8 +
 ..._da7b0586b0b28e1e0fe4126f6543a7bc._comment |    9 +
 ..._2f9ba367e19d77bf52f372b6f0f5938a._comment |    8 +
 .../assistant/blog/day_129__release.mdwn      |    4 +
 .../assistant/blog/day_12__freebsd_redux.mdwn |   23 +
 ..._5da32cf53f1de27bfe6cec2d294db3e1._comment |    8 +
 ..._696d6e22034acf5bb60d80124b72ef2f._comment |    8 +
 ..._5ab7808595e3b51ca4141d15fdd44743._comment |    7 +
 .../assistant/blog/day_130__what_now.mdwn     |   36 +
 ..._402f00cc034351d8253a797dd4de55bf._comment |    8 +
 .../blog/day_131__webdav_groundwork.mdwn      |   28 +
 .../blog/day_132__webdav_continued.mdwn       |   22 +
 .../blog/day_133__webdav_working.mdwn         |   31 +
 .../blog/day_134__box.com_configurator.mdwn   |    8 +
 .../blog/day_135__progress_revisited.mdwn     |   37 +
 doc/design/assistant/blog/day_136__misc.mdwn  |   14 +
 .../assistant/blog/day_137__Glacier.mdwn      |   30 +
 doc/design/assistant/blog/day_138__back.mdwn  |   25 +
 ..._65a8499b284bed38d2bde1886a54a311._comment |    8 +
 .../assistant/blog/day_139__catch_up.mdwn     |   11 +
 .../blog/day_13__kqueue_continued.mdwn        |   34 +
 .../blog/day_140__release_monday.mdwn         |   25 +
 .../blog/day_141__release_tuesday.mdwn        |    6 +
 ..._a5adea7a726df12f9121c744a036f08d._comment |   10 +
 .../assistant/blog/day_142__filling_in.mdwn   |    9 +
 .../assistant/blog/day_143__what_next.mdwn    |   22 +
 ..._40cf25a2ebdd43d8974a28e180e100e5._comment |   13 +
 ..._af9ccbbc5131e6333c029415141bdb51._comment |   10 +
 .../assistant/blog/day_144__webapp_work.mdwn  |    8 +
 .../blog/day_145__more_webapp_work.mdwn       |   12 +
 .../assistant/blog/day_146__meanwhile.mdwn    |   22 +
 .../assistant/blog/day_147__direct_mode.mdwn  |   36 +
 ..._0bd69532afce9dc04e3d88bfd0aed4b2._comment |   16 +
 ..._3b26f0d081c3bf1037bb872d529ce825._comment |    8 +
 .../assistant/blog/day_148__direct_mode.mdwn  |   42 +
 .../assistant/blog/day_149__rainy_day.mdwn    |   15 +
 .../blog/day_14__kqueue_kqueue_kqueue.mdwn    |   23 +
 .../blog/day_14__thinking_about_syncing.mdwn  |   44 +
 .../assistant/blog/day_150__12__58__12.mdwn   |   53 +
 .../blog/day_151__direct_mode_toggle.mdwn     |   59 +
 .../assistant/blog/day_152__bugfixes.mdwn     |   18 +
 ..._46863a875f9daa6f2c9248b66ff91929._comment |    9 +
 ..._a586e617bc024c8a9ff60f1b8345d74d._comment |    8 +
 .../assistant/blog/day_153__hibernation.mdwn  |   26 +
 .../blog/day_154__direct_mode_merging.mdwn    |   21 +
 .../assistant/blog/day_155__bugfixes.mdwn     |   15 +
 ...ay_156_and_157__direct_mode_assistant.mdwn |   45 +
 .../assistant/blog/day_158__fsevents.mdwn     |   20 +
 ..._b278372ac6399f64d5fa9da178278a6d._comment |    8 +
 ..._2d5ce9b2807068c3517e185945662bd2._comment |    8 +
 .../blog/day_159__fsevents_and_assistant.mdwn |   16 +
 ..._b85f446c3fa8d703a2a8882825c6f33f._comment |    8 +
 ..._a150b404e0c39e0bb2f7dd00cda63cdc._comment |    8 +
 ..._37abc41bae23a1d7de0d19d952aec492._comment |    8 +
 .../assistant/blog/day_15__its_aliiive.mdwn   |   33 +
 .../day_160__finishing_up_direct_mode.mdwn    |   10 +
 .../assistant/blog/day_161__release_day.mdwn  |    8 +
 ..._e82c67f3ce216618149537bba1e0b850._comment |   19 +
 ..._b1fe96fd818935c0497b78bb8ad32ffa._comment |   14 +
 ..._40bac0e1756aa77bb966c4654857141c._comment |   44 +
 ..._af65656b0d1179636937595868bb97b0._comment |   30 +
 ..._0c05caaaf9588e124585041bf5f45d75._comment |   20 +
 ..._5dfb5f428633d6062925f61af2b8829b._comment |   23 +
 ..._ac4effb381b08d94d4a2d2482e92c89a._comment |   13 +
 ..._32600e89e3098e52a1280895e03b3f86._comment |   13 +
 ..._07e5d0c3cad0ce2bd4943e53b61f1767._comment |    8 +
 doc/design/assistant/blog/day_162__UI.mdwn    |   17 +
 .../blog/day_163__free_features.mdwn          |   32 +
 .../assistant/blog/day_164__bugfixes.mdwn     |   17 +
 .../assistant/blog/day_165__release_day.mdwn  |   16 +
 .../blog/day_166__a_short_long_day.mdwn       |   25 +
 .../day_167__safe_direct_mode_transfers.mdwn  |   12 +
 ..._f1aa64fe803d8c14b250a4e98b88142a._comment |    8 +
 ..._5ce1db84c9ead713f1272c4975645b93._comment |    8 +
 .../blog/day_168__back_to_theme.mdwn          |   18 +
 ..._f248780bfcbd0384d9d72c2633a4ea46._comment |   12 +
 ..._5beba073373b8e75a32d1fcfdc1a0782._comment |   13 +
 .../blog/day_169__direct_mode_is_safe.mdwn    |   24 +
 ..._65f87656c4e6bc7cdb614f53961341c9._comment |    8 +
 ..._a116a402a126c62be54c06afd82439ab._comment |   19 +
 .../blog/day_16__more_robust_syncing.mdwn     |   44 +
 ..._23e7a90429e4431f90787cd016ebe188._comment |    8 +
 ..._8e7e7cd27791bb47625e60a284e9c802._comment |   10 +
 .../blog/day_170__bugfixes_and_release.mdwn   |    8 +
 doc/design/assistant/blog/day_171__logs.mdwn  |   23 +
 .../assistant/blog/day_172__short_day.mdwn    |   22 +
 ..._b75e26b77a23a45da1c4c3bca1399246._comment |   12 +
 .../assistant/blog/day_173__snow_day.mdwn     |   22 +
 .../blog/day_174__last_weekend_before_AU.mdwn |   25 +
 ..._05a8fd47f54373331741cc869a53b0c3._comment |   10 +
 ..._fc8e65eef954c4caa8321c2fe8b711b7._comment |    8 +
 ..._399534f540d85cac067fbb7be9d373b4._comment |    8 +
 .../blog/day_175__pacific_features.mdwn       |   15 +
 ..._c3ee4386f872b7c76aaecfa638b368cb._comment |    9 +
 .../blog/day_176__thread_management.mdwn      |   13 +
 .../assistant/blog/day_178__bus_hacking.mdwn  |   10 +
 .../blog/day_179__brief_updates.mdwn          |   19 +
 ..._920a84457d40358507a3eb817a4568d9._comment |    8 +
 .../blog/day_17__push_queue_prune.mdwn        |   19 +
 doc/design/assistant/blog/day_180__back.mdwn  |    7 +
 .../assistant/blog/day_181__triage.mdwn       |   23 +
 .../assistant/blog/day_182__it_begins.mdwn    |   50 +
 .../assistant/blog/day_183__plan_b.mdwn       |   19 +
 .../day_184__just_wanna_run_something.mdwn    |   46 +
 ..._689adac7e26cb0b0a4e7ecc787cfd716._comment |   16 +
 .../blog/day_185__android_liftoff.mdwn        |   20 +
 ..._b7d28010a72619a7e9a5ad4f2a0d6c07._comment |    9 +
 ..._ddeb24e86fafb7dae93142cc02767aad._comment |   10 +
 .../blog/day_186__Android_success.mdwn        |   33 +
 ..._1629da240ca7db5f8a32059f561fd435._comment |    8 +
 .../blog/day_187__porting_utilities.mdwn      |   22 +
 ..._0e6a3f4fe8e09f247fa04156bc60f8c7._comment |    8 +
 .../day_188__crippled_filesystem_support.mdwn |   37 +
 ..._32a296fce23ae4b1e18bd5a9964bf619._comment |   14 +
 .../blog/day_189__more_crippling.mdwn         |   44 +
 .../assistant/blog/day_18__merging.mdwn       |   82 +
 ..._7a553ad559519f3b3e3cd20115b4c44e._comment |   15 +
 .../assistant/blog/day_190-191__weekend.mdwn  |   28 +
 ..._dbd692d12c14d08acd7d73a655b34e8b._comment |   10 +
 ..._c813830e53471a9732e010a748d574fc._comment |   28 +
 .../blog/day_192_193__more_porting.mdwn       |   44 +
 .../assistant/blog/day_194__nice_moment.mdwn  |   37 +
 .../blog/day_195__real_android_app.mdwn       |   32 +
 ..._0112007552b30cd9bfeac614a1e399c4._comment |   10 +
 ..._230d3c169c713f613b9d607d84ce5092._comment |   12 +
 ..._8d74ad2a61c02272758d157282ad56ec._comment |   10 +
 ..._4f6bc0680f2debd638933968a26975e0._comment |   10 +
 ..._71539c62608866464e8faa76bc522a55._comment |    9 +
 ..._e1b205289721ae79ac7fbed2f44018b2._comment |   10 +
 ..._4bc0aeae4fa1116944644c64feaf9697._comment |    8 +
 ..._17bb6e7565d4c757f6c1e3514c22f47d._comment |   10 +
 ..._cd8a6bec0f7c6843dd11d3266f25f864._comment |   44 +
 ..._2d2eee4bcbbd1d069a80bff5edc90c3c._comment |   13 +
 ..._3d96568c469a8c53a982f304eae5e7d4._comment |   10 +
 ..._e8667c47d07fc842cf0fe2ebbfbc1c58._comment |    8 +
 ..._cf8da7720ddc20b05955ee671ca4acd5._comment |    8 +
 ..._f4709bdbc739182819b648fd6aa00531._comment |   36 +
 ..._e66af12c7eca0d457b8406e9fb4b69be._comment |    8 +
 .../blog/day_196__android_bugfixes.mdwn       |   26 +
 .../blog/day_197__template_haskell.mdwn       |   36 +
 ..._82d9f9508929d84abf7b718c59436ae8._comment |   18 +
 .../assistant/blog/day_198__bugfixes.mdwn     |   11 +
 ..._5a15b5bad0f9ba2423d2aebe440ac0ea._comment |   19 +
 ..._36d94b838e5e65c85e7afaabe8a578f1._comment |   12 +
 ..._ae9b74341a3bc6e1e84d2c0ca4c5f612._comment |   10 +
 ..._5a4827227c03bcff3b1e4c44b531f816._comment |   12 +
 ..._9c5f4c85217e898be4c57c615e53c36f._comment |    8 +
 ..._bccf1abfb7f56d97673158f3ccfce511._comment |    9 +
 ..._6f1b51b002cc5d2b505d80e3e04bf6f3._comment |    8 +
 ..._8a3542437663028b17442818eba3f7c5._comment |    9 +
 .../day_199__wrapping_up_Android_for_now.mdwn |   26 +
 ..._ec57358afc7e78d2860aa4237793832d._comment |   11 +
 .../blog/day_19__random_improvements.mdwn     |   50 +
 doc/design/assistant/blog/day_1__inotify.mdwn |   57 +
 .../assistant/blog/day_200__release_day.mdwn  |   19 +
 ..._40cfe9bfd9e611fd734dbb5aad348aa3._comment |   10 +
 ..._b26890fdae575d42170988073fb2e45d._comment |    8 +
 ..._710a30c5d31bf549833ecfe9a0997c94._comment |    8 +
 ..._b6f62ab7e810ba6d3a43f0ead370c79a._comment |    8 +
 ..._a68e1ed7829b49086c567d97ddc09912._comment |    8 +
 ..._39d3ad0a029fe56e96f97d28d17fbbd2._comment |    8 +
 ..._5b752d6a8d74e61190f09384b6108206._comment |   31 +
 ..._881274ae0d6230bb4cafa4151ad72b49._comment |   12 +
 ..._e220059be77cf0ef396f37a4f9ccf9b5._comment |    8 +
 ..._ec2152151188dd252cdb61c68cfc12e4._comment |   10 +
 ..._42572411617c287368482bb9dcf94324._comment |   18 +
 ..._6b69aa81a9ba4e07e547ed1869946d51._comment |   15 +
 ..._b070a2e4151d9fbf43d7906efa78515f._comment |   12 +
 .../blog/day_201__real_Android_wrapup.mdwn    |   38 +
 ..._88b9950c51324f0bb89c5646b3170952._comment |   19 +
 .../blog/day_201__real_Android_wrapup/fib.png |  Bin 0 -> 69535 bytes
 .../blog/day_201__working_web_server.mdwn     |   31 +
 .../blog/day_203__procrastination.mdwn        |   25 +
 .../blog/day_204__deprocrastination.mdwn      |   62 +
 .../day_205_206__rainy_day__snow_day.mdwn     |   12 +
 doc/design/assistant/blog/day_207__XMPP.mdwn  |    7 +
 .../assistant/blog/day_208__bugfixes.mdwn     |   17 +
 .../assistant/blog/day_209__The_Bug.mdwn      |   23 +
 .../blog/day_20__data_transfer_design.mdwn    |   22 +
 .../assistant/blog/day_210__spring.mdwn       |   29 +
 .../blog/day_211__zooming_along.mdwn          |   24 +
 .../blog/day_212__accidental_all_nighter.mdwn |   24 +
 ..._6ee1f8056eedb6eb18013faf8f5ec212._comment |    8 +
 ..._07c83d75bb105bb77ada07359ed0ea7a._comment |    8 +
 ..._2c904d33f4f14807fbe718a01e98800a._comment |    8 +
 ..._59ec5c1cab75df87293800a7a03fe9c6._comment |    8 +
 ..._13893f106e835dcc52e03c7c6740c35b._comment |    8 +
 doc/design/assistant/blog/day_213__costs.mdwn |   34 +
 .../assistant/blog/day_214__release_day.mdwn  |    5 +
 .../blog/day_215__dashboard_UI_refresh.mdwn   |   25 +
 .../blog/day_216__more_bugfixes.mdwn          |   42 +
 ..._299462bcdd0e4f6cd7895b5f40ca00ad._comment |   10 +
 ..._1913d65dfe4ba08379d82a4a2ca91c40._comment |    8 +
 ..._92c774599a78540ad398afcd1d05f7ce._comment |   20 +
 .../assistant/blog/day_217__nothing.mdwn      |    2 +
 .../assistant/blog/day_219__bug_triage.mdwn   |   14 +
 ..._c6b977a969cacdce62987a439b7686f5._comment |   16 +
 .../blog/day_21__transfer_tracking.mdwn       |   28 +
 .../assistant/blog/day_220__performance.mdwn  |   40 +
 .../blog/day_221__this_and_that.mdwn          |   28 +
 doc/design/assistant/blog/day_222__back.mdwn  |   16 +
 ..._f05b48231a1ee0cffba7d66e112e5551._comment |    8 +
 ..._4d5f003ccd81580017ebf0dc31bc9cda._comment |    8 +
 .../blog/day_223__progress_revisited.mdwn     |   24 +
 .../blog/day_224__annex.largefiles.mdwn       |   23 +
 ..._408e4021b18f7ff5548d2d19ab558922._comment |    8 +
 ..._b24d1da2bc4307ded0216daffb8f9336._comment |    8 +
 .../blog/day_225__back_from_the_dead.mdwn     |   47 +
 ..._9ac37c3b5c4c72ec8a39dce00bcbe420._comment |    8 +
 ..._26125dd9ef2bd10b597d14b2c6180952._comment |    8 +
 .../assistant/blog/day_226__poll_results.mdwn |   28 +
 ..._1ed980472214be6d0a8cf55f37797fda._comment |    8 +
 ..._6823b0a9a8037f1a5214db4db98fb16e._comment |    8 +
 .../day_227__bigfixing_all_day_today.mdwn     |   21 +
 ...228__more_work_on_repository_removals.mdwn |   27 +
 .../blog/day_229__rainy_day_bugfixes.mdwn     |   17 +
 .../day_22__horrible_option_parsing_hack.mdwn |   34 +
 doc/design/assistant/blog/day_230__Mom.mdwn   |   35 +
 ..._696bba2246c8a9e6ce4aed3071bcc96c._comment |    8 +
 ..._2fa295ab6db0828cb725cfcfb6777822._comment |    8 +
 ..._fafd7abec629290418334ddb015bf62c._comment |   10 +
 ..._450cac0f2e82c94fd34b527ae05ef1b8._comment |    8 +
 .../assistant/blog/day_231__insert_title.mdwn |   26 +
 .../blog/day_232__headless_webapp.mdwn        |   22 +
 ..._0fdd77d143ecba6fdb9f75cb6fc37bfb._comment |   16 +
 ..._0784a2a73c3e2945f3d3f2577b3b9c9c._comment |    8 +
 ..._ccb9fa22422fb913b6a496ebe65c49fb._comment |    8 +
 ..._ceba4468760a2525960327698431cee2._comment |    8 +
 ..._7e51a197ff9970ae50cf47bd3a922257._comment |   18 +
 doc/design/assistant/blog/day_233__taxes.mdwn |   11 +
 ..._9473ffdc42595af9c293fbcd5a1cdb54._comment |   14 +
 ..._5feed8d7053ba03812ccda8c61fd9775._comment |    8 +
 .../blog/day_234__clean_shutdown.mdwn         |   29 +
 .../assistant/blog/day_235__birthday.mdwn     |   31 +
 ..._db558b071067c1e63cde05cca0551094._comment |    8 +
 ..._d1a2c1124781118267599457ae9e0512._comment |    8 +
 ..._b853508d1d15234958b9f4a39277e45c._comment |    8 +
 ..._73aad3398a43bc4d28bca9bf635fa757._comment |    8 +
 .../assistant/blog/day_236__evil_splicer.mdwn |   29 +
 .../day_237__gnome-keyring_craziness.mdwn     |   29 +
 ..._0cb088b732881d1fa92493aa1fd93d43._comment |    8 +
 ..._b855fd710954beebaafe6d2bd03eb368._comment |    8 +
 .../blog/day_238__back_to_Android.mdwn        |   11 +
 .../day_239__bugfixes_and_frustration.mdwn    |   28 +
 .../blog/day_23__transfer_watching.mdwn       |   25 +
 .../assistant/blog/day_240__it_builds.mdwn    |   37 +
 ..._151840ae0020ea63b2f041488c905386._comment |   25 +
 .../assistant/blog/day_241__cleanup.mdwn      |   14 +
 ..._0e283cdf66a25b3cc9423fe651084cb9._comment |    8 +
 .../assistant/blog/day_242__more_porting.mdwn |    4 +
 .../assistant/blog/day_243__in_the_field.mdwn |   21 +
 .../blog/day_244__android_porting.mdwn        |    6 +
 doc/design/assistant/blog/day_245__misc.mdwn  |   15 +
 ..._3a2976617bb0cdc206fb1397a2ef1177._comment |    8 +
 ..._e0f9704e91fedca8ff26356f354cc1c3._comment |   10 +
 ..._93003a0d0983efbdc046d7459be194b0._comment |    8 +
 .../blog/day_246__bug_treadmill.mdwn          |   18 +
 ..._f76f653364fe2b97e85e8356c93b0fce._comment |    8 +
 .../blog/day_247__performance_tuning.mdwn     |   16 +
 .../blog/day_248__Internet_Archive.mdwn       |   28 +
 .../assistant/blog/day_249__quiet_day.mdwn    |    7 +
 .../blog/day_24__airport_digressions.mdwn     |   99 +
 .../assistant/blog/day_250__stymied.mdwn      |   23 +
 ..._330a10d447ccc3db03fcbfe571dbb404._comment |    8 +
 .../blog/day_251__xmpp_improvements.mdwn      |   34 +
 .../assistant/blog/day_252__release_day.mdwn  |    6 +
 doc/design/assistant/blog/day_253__OMG.mdwn   |   22 +
 ..._bbdc61092771163e65a90a4755a807d8._comment |    8 +
 .../blog/day_254__Android_app_polishing.mdwn  |   35 +
 ..._37f4ff5227566ce4b3fa69fc32568841._comment |   14 +
 ..._58bbb105bdbb72bba85c3622195f43b9._comment |   12 +
 .../blog/day_255__Debian_release_day.mdwn     |   26 +
 doc/design/assistant/blog/day_256__8bit.mdwn  |   27 +
 ..._f9b50263e3997d4c5b9836a2e0a346d7._comment |    8 +
 .../assistant/blog/day_257__rainy_day.mdwn    |    6 +
 .../blog/day_258__beginning_of_the_end.mdwn   |   24 +
 .../day_259__Android_dominos_toppling.mdwn    |   15 +
 ..._0b4a6e4893b0157e4768b46468dbbb87._comment |   10 +
 ..._1ebc5aff5d217e1392cb7c8bb6c5156b._comment |   14 +
 ..._eed7792f6142f3fc74d3c384bb16559b._comment |    8 +
 .../blog/day_25__transfer_queueing.mdwn       |   41 +
 ..._59fd4f1ffe96c412f613dc86276e7dbd._comment |   10 +
 ..._93bf768a67117e873af5732ecf08dc78._comment |    7 +
 .../day_260__Windows_dev_environment.mdwn     |   46 +
 ...day_261__Windows_first_stage_complete.mdwn |   29 +
 .../blog/day_262__DOS_path_separators.mdwn    |   14 +
 ..._45ecae90b22e31202c21083980d6b567._comment |   10 +
 .../assistant/blog/day_263_catching_up.mdwn   |   11 +
 ..._9023da0573dfc81644d68128adb331a7._comment |    8 +
 ...ay_264__Windows_second_stage_complete.mdwn |   21 +
 ..._42a7502d6ece75520eb59a76fdb1e2f0._comment |    9 +
 ..._f2b11322ac87e2a36cddc035b2c3c1ea._comment |    8 +
 ..._ea6ee05acb946fc7e8d95e62647cfa2a._comment |    8 +
 ..._9ce106baf28b7f75f7f6febd7bfcea70._comment |    8 +
 .../assistant/blog/day_265__correctness.mdwn  |   23 +
 ..._e8959a6df87eb92310947e66c7471e97._comment |   12 +
 ..._0cb953fcc085eedb34e65c227309ede7._comment |    8 +
 ..._df57628a8969af2995732e7ea2a0fae3._comment |   10 +
 .../assistant/blog/day_266__release_day.mdwn  |    6 +
 ..._92c8d1d9216b46b07dfe69bbc77a923e._comment |    8 +
 .../blog/day_267__windows_autobuilder.mdwn    |    9 +
 ..._978b584d86395f2f621b0e1f7c5e70d7._comment |   21 +
 ..._8f978d2811c8fbf11e3d12f245bdb52b._comment |   10 +
 .../blog/day_268__core_monad_change.mdwn      |    9 +
 .../assistant/blog/day_269__bugfixes.mdwn     |   14 +
 .../assistant/blog/day_26__dying_drives.mdwn  |   28 +
 .../blog/day_270__release_and_xmpp.mdwn       |   39 +
 .../assistant/blog/day_271__more_xmpp.mdwn    |   31 +
 .../assistant/blog/day_272__fuzz_tester.mdwn  |   37 +
 .../assistant/blog/day_273-274__fun.mdwn      |   19 +
 .../blog/day_275__working_hard_or.mdwn        |   12 +
 .../blog/day_276__fuzzing_continues.mdwn      |   12 +
 ..._f5dd0658511a1063c2eb025b0fe98426._comment |   14 +
 ..._a56c4c26a9e7bb8cfe3f598dbeed0813._comment |   10 +
 ...ay_277__private_static_protected_void.mdwn |   19 +
 .../assistant/blog/day_278__winding_down.mdwn |   11 +
 .../blog/day_279__final_release_prep.mdwn     |   14 +
 .../blog/day_27__robust_transfers.mdwn        |   31 +
 .../day_28-35__threaded_runtime_tarpit.mdwn   |   17 +
 doc/design/assistant/blog/day_280__yesod.mdwn |    7 +
 ..._a42213a8cef71f2b54db18606028136d._comment |    8 +
 doc/design/assistant/blog/day_281__back.mdwn  |   37 +
 ..._128809c5a2a9f5cc345a10fdbf55be01._comment |    8 +
 ..._6d0bbdf6ebaff9da399804570f0e606d._comment |   10 +
 .../blog/day_282-283__caught_up.mdwn          |   18 +
 .../assistant/blog/day_284__porting.mdwn      |   13 +
 ...285__fixed_the_archive_directory_loop.mdwn |   23 +
 ..._1065e756dc6d66aefd214eb8ac5ebe1d._comment |   25 +
 .../blog/day_286__Windows_test_suite.mdwn     |   19 +
 .../assistant/blog/day_287__niceness.mdwn     |   13 +
 .../blog/day_288__success_stories.mdwn        |   32 +
 ..._9ddf57b8ae0241268bb33bec1b169e4c._comment |   20 +
 ..._50b8a597bd8677608f2ef176443f23f3._comment |   10 +
 ..._f2df427cf3608377e9a52d8bdeadb26f._comment |   21 +
 ..._8762efed97f21eeba8f0a7be45bd924a._comment |   35 +
 ..._55e1bb15c3a93d582d110f8173ceefc2._comment |    9 +
 ..._5749aef8b585b293385b20b75c40f9d8._comment |   31 +
 ..._911c6d2764906cad7d6324835441ed34._comment |   12 +
 ..._eb6aa8af5aa70877255a11d132d51aba._comment |   10 +
 ..._9a57de4cea407a73b2d023d85afdccc6._comment |   12 +
 ..._1767c86067bee35941004282b96b8e95._comment |   10 +
 ..._22b28ca3d4d3283ad8c21ae052fb9752._comment |   11 +
 ..._1d47f3e1b9f0081649cedae4288bac83._comment |    8 +
 ..._31d3f58cad83cb1ecc4821a15ca258d8._comment |   14 +
 ..._b512bd2bf29dfaab6b36bf204518fdb6._comment |    8 +
 ..._343333356de20e170edb8020faa7400d._comment |   10 +
 ..._4e4034bec789543b562ac263df3e21dd._comment |   15 +
 ..._0c52794c77a9b7afc5112f5edf9cb793._comment |    8 +
 ..._7ca419aa3a187857b19268572d5df297._comment |   18 +
 ..._3edd56b3b04f19faba8d75cca285a662._comment |   10 +
 ..._146331ae2de25a6dc3595dffab9514de._comment |   12 +
 ..._72be9307e75eb120451f3d6ab7c8165e._comment |    8 +
 ..._c27eb0a4181e85a3eed41130402350bf._comment |   12 +
 .../blog/day_289__back_in_the_swing.mdwn      |   16 +
 .../blog/day_290__https_release.mdwn          |   17 +
 doc/design/assistant/blog/day_291__--all.mdwn |   32 +
 ..._eaa9fef19a035bef9c439e87d47c834b._comment |   17 +
 ..._90bbc26bf92048de7cbaf5fb719c9593._comment |   11 +
 ..._75006e9909425dcbf86415a9f7c90372._comment |   10 +
 ..._5440449bbc5a353f7430f72e19c35e92._comment |    8 +
 .../assistant/blog/day_292__bugfixes.mdwn     |   24 +
 ..._bbac3878d80f7540d229183c56664784._comment |    8 +
 ..._8c9e5291ceb257f3a938af0ad967c5d7._comment |   10 +
 ..._02f875e8edd30f47939249f16d92712b._comment |    8 +
 .../assistant/blog/day_293__gpg_builds.mdwn   |   32 +
 ..._4f152de8ea5aca4ec381d439e2a821f7._comment |   12 +
 ..._42f625638638bc875379f6c604d6f673._comment |    8 +
 .../assistant/blog/day_294__release_day.mdwn  |    7 +
 .../blog/day_295__balls_in_the_air.mdwn       |   13 +
 .../day_296__new_crowdfunding_campaign.mdwn   |   41 +
 ..._cccad1a5103c504d21d0f8e69bb39e1b._comment |    8 +
 ..._4fef7bd9c8e15cd57df365fadb95717f._comment |    8 +
 ..._0b9258a1f5079e53c60138f06d0c63b1._comment |    8 +
 ..._46183b97ca904bc06e46569c30db2edc._comment |    8 +
 .../assistant/blog/day_297__back_to_work.mdwn |   16 +
 ..._e300feb821bfe7b76b2cec4376d16ffa._comment |    8 +
 .../assistant/blog/day_298__exceptional.mdwn  |   21 +
 .../assistant/blog/day_299__bugfixing.mdwn    |    8 +
 doc/design/assistant/blog/day_2__races.mdwn   |   45 +
 .../assistant/blog/day_300__new_logo.mdwn     |   36 +
 ..._9fc64e33863b9fce00f6a03417a91e36._comment |    9 +
 ..._e8aac0298f90004e81492d2c7f85eda0._comment |    8 +
 ..._6308c767f6e4bf090102191c91520d04._comment |    8 +
 .../blog/day_301__direct_unannex.mdwn         |   21 +
 .../assistant/blog/day_302_release_day.mdwn   |    6 +
 ..._fe6e572ba706e95188463d9f3e004d03._comment |   17 +
 doc/design/assistant/blog/day_303__oops.mdwn  |    8 +
 .../blog/day_304__dropunused_safety.mdwn      |   28 +
 ..._1bbcf6c74b6437c44ff8604401fb1432._comment |   10 +
 .../blog/day_305__interesting_bugs.mdwn       |   21 +
 .../assistant/blog/day_306__offtopic.mdwn     |    2 +
 .../assistant/blog/day_307__buuuugs.mdwn      |   31 +
 .../assistant/blog/day_308__ssh-agent.mdwn    |   16 +
 ..._5f0fc810cf1e1cd9b3ddba3cd19bb19d._comment |   12 +
 .../assistant/blog/day_309__filenames.mdwn    |   17 +
 .../assistant/blog/day_310__release_day.mdwn  |   18 +
 ..._1e008583cebd8e373e83729529914db7._comment |    8 +
 .../blog/day_311__Windows_porting.mdwn        |   10 +
 ..._8e738f54a72557bee1e19970472b925c._comment |    8 +
 .../blog/day_312__DebConf_midpoint.mdwn       |   30 +
 doc/design/assistant/blog/day_313__back.mdwn  |   34 +
 ..._fbf3fdf9688c18156753d446facd942d._comment |   10 +
 doc/design/assistant/blog/day_314__quvi.mdwn  |   27 +
 ..._3fdfb0742cb5422530ddd97b904f2a42._comment |    8 +
 .../assistant/blog/day_315__backlog.mdwn      |   12 +
 .../assistant/blog/day_316__day_off.mdwn      |    6 +
 doc/design/assistant/blog/day_317__misc.mdwn  |   17 +
 .../blog/day_36__minimal_test_case.mdwn       |    9 +
 doc/design/assistant/blog/day_37__back.mdwn   |   64 +
 .../blog/day_39__twice_is_enemy_action.mdwn   |   66 +
 .../assistant/blog/day_3__more_races.mdwn     |   26 +
 ..._d6015338f602b574a3805de5481fc45e._comment |    8 +
 ..._4d6b23fc6442e0ee0303523cb69d0fba._comment |    8 +
 ..._03f5b2344c2a47dea60086f217d60f9b._comment |   14 +
 ..._860e90e989ec022100001c65e353a91e._comment |    8 +
 doc/design/assistant/blog/day_40__dbus.mdwn   |  100 +
 ..._43ed2a79629868b018ec9f54a32bcacc._comment |   12 +
 ..._6799f2baf6a6ce14b1fa76a8402840c0._comment |   10 +
 ..._fa1d7444bdafcb990cacf2ace7ee6ef1._comment |   10 +
 ..._3399ddad951c1a950281bb6941fc3f6f._comment |    8 +
 ..._40b6b9d741d3081203f0cc94eb8dc3ea._comment |   12 +
 doc/design/assistant/blog/day_41__foo.mdwn    |   46 +
 ..._ace21fa257a4c2fd412b6ff2944a23e8._comment |   10 +
 .../assistant/blog/day_42__the_answer.mdwn    |   27 +
 .../blog/day_43__simple_scanner.mdwn          |   37 +
 .../assistant/blog/day_44__webapp_basics.mdwn |   83 +
 ..._d5fb67f373038e9f583cb2e1992bef67._comment |   18 +
 .../assistant/blog/day_45__long_polling.mdwn  |   66 +
 ..._994bec0978324e268666073e8ff4f6ae._comment |    8 +
 ..._dfa164c86290899139491acccddd8b2b._comment |   10 +
 ..._5526c9dd4fd87da56cb8456083169f55._comment |    8 +
 ..._91630f5bf162dfd4fbb3920f1318535b._comment |    8 +
 ..._b3e41ba77f21e93a4e086483793bf5ce._comment |   10 +
 .../blog/day_45__long_polling/full.png        |  Bin 0 -> 55185 bytes
 .../blog/day_45__long_polling/phone.png       |  Bin 0 -> 41602 bytes
 .../blog/day_46__notification_pools.mdwn      |   68 +
 .../blog/day_47__alert_messages.mdwn          |   14 +
 doc/design/assistant/blog/day_48__intro.mdwn  |    8 +
 .../blog/day_49__first_run_experience.mdwn    |   39 +
 ..._e146cf06c8dd6303dd6a991f152a73fe._comment |    8 +
 ..._5d6adcf6782c02283bef6189582ee467._comment |   12 +
 ..._7ac2e34c2a7bc9b57488ca0c91307d32._comment |   14 +
 ..._549b07bb02c07a5b1b95445b01758db2._comment |   14 +
 doc/design/assistant/blog/day_4__speed.mdwn   |   47 +
 ..._bf3c9c33cc0dea5eaeb6f2af110b924b._comment |    8 +
 ..._33aba4c9abaa3e6a05a2c87ab7df9d0e._comment |    8 +
 .../blog/day_50__directory_name.mdwn          |   20 +
 ..._782cec95a8558a05b2b38a2d2302214d._comment |    8 +
 ..._2b8ceb0a26f25e8ed2711bcbe7225a58._comment |    8 +
 .../assistant/blog/day_51__desktop.mdwn       |   34 +
 .../assistant/blog/day_52__file_browser.mdwn  |   21 +
 ..._cd000c2d56b60cc1f17b221322a32aa7._comment |    8 +
 ..._21d1da67cf9105a545583ba2302c10fb._comment |    7 +
 .../blog/day_54__adding_removable_drives.mdwn |   99 +
 ..._5de4f220a3534f55b1f2208d1d812d63._comment |   10 +
 ..._8dae1ed0a70acf9628b88692dc32ac5f._comment |   10 +
 doc/design/assistant/blog/day_55__alerts.mdwn |   10 +
 ..._6319045500a8a5e049304fdec5ff4cf4._comment |    8 +
 .../blog/day_56__transfer_control.mdwn        |    8 +
 doc/design/assistant/blog/day_57__afk.mdwn    |   40 +
 ..._70e1c9f925f040c1700d3e26bab373d5._comment |    9 +
 ..._c70d3faccfcebf47deb25e270498cb56._comment |   18 +
 ..._89020ebc6d31485339bdea41a872df3c._comment |   11 +
 ..._8b1f65f141ffd9813e7f5a3380f7f520._comment |   27 +
 .../blog/day_58__more_transfer_control.mdwn   |   26 +
 doc/design/assistant/blog/day_59__dinner.mdwn |   10 +
 ..._0c1e2d69496473e7e4a2956a2814f5dd._comment |    9 +
 .../assistant/blog/day_5__committing.mdwn     |   57 +
 .../assistant/blog/day_60__taking_stock.mdwn  |   40 +
 ..._6722f81ee084f1ea9e8fe47f34576397._comment |    8 +
 .../day_61__network_connection_detection.mdwn |   36 +
 ..._09b58f41a8d48f218619711ee19511ac._comment |    8 +
 .../blog/day_62__smarter_syncing.mdwn         |   21 +
 .../blog/day_63__transfer_retries.mdwn        |   26 +
 ..._990d4eb6066c4e2b9ddb3cabef32e4b9._comment |   10 +
 .../blog/day_64__syncing_robustly.mdwn        |   33 +
 .../blog/day_65__transfer_polish.mdwn         |   33 +
 .../assistant/blog/day_66__the_merge.mdwn     |   19 +
 ..._eeccf4e73cc321542a1fe4780805a81e._comment |   12 +
 ..._a34e89316d1662826848f31061c4e46b._comment |    8 +
 ..._09e244d23d05052fa2b11a7181888366._comment |    8 +
 ..._3961a03e167903959b96b054835613f6._comment |    8 +
 ..._12a57af9f580918818b4a9f68396d5c4._comment |   23 +
 ..._8ce638960012367c888e018a5f05db19._comment |    8 +
 ..._f461b856b940e6914bcd2b681cf9505f._comment |   13 +
 ..._6e73aca1fc1747d0e742e054b88b5d78._comment |   12 +
 ..._d85f1ce23ae16d5a8eb88d2c3999acb7._comment |   19 +
 ..._c06dab4d78122c85beeaf300ffc3e376._comment |    8 +
 .../assistant/blog/day_67__progress_bars.mdwn |   10 +
 .../assistant/blog/day_68__transfers.mdwn     |   15 +
 ..._5282960c0b553fbc0f411345b9745324._comment |   14 +
 .../assistant/blog/day_69__build_fixes.mdwn   |    7 +
 doc/design/assistant/blog/day_6__polish.mdwn  |   50 +
 .../blog/day_70__adding_ssh_remotes.mdwn      |   66 +
 ..._2fac85357ac8feccff82beabd3791439._comment |   13 +
 ..._e9e496005fd1bf5a10c9e286b83e51fa._comment |    8 +
 ..._913e6ae7c8f7db90b9767ec35fc84205._comment |   23 +
 ..._634ca3c236e2062289e7df5f0d77a3c5._comment |    8 +
 ..._e365bbcbb7f66ce2b35fcd5b969ab315._comment |   16 +
 ..._b15499722a655489f9ea60ff9d4c47c6._comment |   12 +
 ..._8ea48276f060e75d9f40617d2a1ccd08._comment |   12 +
 ..._9b8bf7e9fa715977fbeb98087deefd1a._comment |   10 +
 ..._42e09eacdc10c7cf579bfc6470b5117c._comment |    8 +
 ..._6c02f31063b3d399d1b4f823bd6543ce._comment |   16 +
 ..._dd0447cb3b39d3a8c1a7cc00f17d8bc2._comment |   10 +
 .../assistant/blog/day_71__ssh_probing.mdwn   |   26 +
 ..._56a0c29f7454cfca5cc30b2849e6e942._comment |    8 +
 ..._f3bd3e366c92c833c7e217da125481b8._comment |    8 +
 ...mote_ssh_server_configurator_finished.mdwn |   34 +
 .../blog/day_73__rsync.net_configurator.mdwn  |   17 +
 .../blog/day_74__bits_and_peices.mdwn         |    7 +
 .../blog/day_75__zeromq_and_pairing.mdwn      |   50 +
 .../assistant/blog/day_76__pairing.mdwn       |   16 +
 ..._09665f269343422cd18051fad1a8c19e._comment |   24 +
 ..._8e1b2233579bc26bfd758bbf6b3bdc07._comment |   10 +
 ..._a8b6a8432da20c468c633da8e7cbc2f3._comment |    8 +
 ..._36a428a2e1803f4391b821d1892f0cd7._comment |   10 +
 ..._11f332fe2050d8c1416e71f9e85ba280._comment |    8 +
 ..._973aeb656b78eca97474ea1a3f5b57b7._comment |   12 +
 ..._03d2b3343f34377a4d6171e06b7609f6._comment |    8 +
 .../assistant/blog/day_77_alert_buttons.mdwn  |   21 +
 .../blog/day_78__pairing_continued.mdwn       |    8 +
 .../blog/day_79__pairing_finished.mdwn        |   33 +
 .../assistant/blog/day_7__bugfixes.mdwn       |   45 +
 .../blog/day_7__bugfixes/profile.png          |  Bin 0 -> 47098 bytes
 .../blog/day_7__bugfixes/profile2.png         |  Bin 0 -> 230937 bytes
 .../blog/day_80__default_backend.mdwn         |   14 +
 ...enabling_pre-existing_special_remotes.mdwn |   34 +
 .../blog/day_82__git-annex_branch_work.mdwn   |   26 +
 doc/design/assistant/blog/day_83__3-way.mdwn  |   73 +
 .../blog/day_84__deferred_downloads.mdwn      |   33 +
 .../blog/day_85__more_foundation_work.mdwn    |   17 +
 .../blog/day_86__towards_the_beta.mdwn        |   33 +
 .../blog/day_87__more_progress_progress.mdwn  |   28 +
 ...ay_88__progressbars_still_progressing.mdwn |   18 +
 .../assistant/blog/day_89__final_polish.mdwn  |   24 +
 doc/design/assistant/blog/day_8__speed.mdwn   |   67 +
 ..._a3dba537b276d5737abc8cb93f1965f4._comment |   10 +
 doc/design/assistant/blog/day_90__beta.mdwn   |   16 +
 ..._5f2a3b18ad7558abe04f51534a29ff13._comment |    9 +
 ..._961c4eba97f4eac75174244d6b2b00c0._comment |    8 +
 ..._c76675a4633cbbe347ed42c222918d38._comment |   24 +
 ..._f0b8f77cb691e747fe35bcf2f51b5baa._comment |    8 +
 ..._99fbc9feac62e66a12b0d357cf86ccc1._comment |    8 +
 doc/design/assistant/blog/day_91__break.mdwn  |    7 +
 doc/design/assistant/blog/day_92__S3.mdwn     |   23 +
 ..._eda656247d11cea7fbed2e33137a39e5._comment |   10 +
 ..._8249d2d9521e44c674da3fda74be077a._comment |   10 +
 .../blog/day_93__OSX_standalone_app.mdwn      |   23 +
 .../assistant/blog/day_93__easy_install.mdwn  |   34 +
 ..._d4f7de723c98577ef28d89ee6b87fd13._comment |   10 +
 ..._6337b341c1cfb2132b59704394e57b36._comment |    8 +
 .../blog/day_95__repository_groups.mdwn       |   21 +
 .../blog/day_96__revisiting_file_adds.mdwn    |   24 +
 ..._da3ca47041168b6c82aeb2c18acc5017._comment |    8 +
 .../assistant/blog/day_97__stuffing.mdwn      |   14 +
 .../blog/day_98__preferred_content.mdwn       |   44 +
 ..._2136618e3515d0ac6369a41f1934ec2a._comment |   17 +
 ..._5f6db00e69628bf2f72b0e6f2981a49b._comment |   14 +
 doc/design/assistant/blog/day_99_shotgun.mdwn |   70 +
 ..._12bb8f54bb13ea20ac4187a2301d77ca._comment |   10 +
 .../assistant/blog/day_9__correctness.mdwn    |   30 +
 ..._564a39cb976767e2c0a9c74fabe10be4._comment |    8 +
 ..._77924e9d50b40f05e792e427a25849a6._comment |    9 +
 ..._92bd86cd06d579e23800af2e5c66a291._comment |    8 +
 ..._0d12b51ccdfc2a94d3e59a5628521e0a._comment |   10 +
 ..._208f9dd3e1d92555b05c29159538a901._comment |   14 +
 ..._90cc6b60718896fb175919417600fdf9._comment |    8 +
 doc/design/assistant/chunks.mdwn              |  271 +
 ..._a3b24ff308664e89c97d23034e4ffe2f._comment |    8 +
 ..._ec5c7a80d1e17db19d178e821f6534e5._comment |    8 +
 doc/design/assistant/cloud.mdwn               |   45 +
 ..._4997778abc171999499487b71b31c9ba._comment |   16 +
 ..._08da8bc74a4845e354dca99184cffd70._comment |    8 +
 ..._faafd1266301997b1822d215ec8e8d8c._comment |    8 +
 ..._3eb557d5439831f6e0032944d12c02cf._comment |   12 +
 ..._f2233fad55c20686cf299bf6788f1f23._comment |   10 +
 ..._a38f0f21c2346e65b786d791b6829f9b._comment |   12 +
 ..._5e991177d6577384f39a36ae02f5f574._comment |   13 +
 ..._f8625c6f43b58847840df338a73b7972._comment |    7 +
 ..._c37ef5931b0f5c1f808083e0d636a208._comment |   11 +
 ..._68c98a27083567f20c2e6bc2a760991b._comment |    9 +
 ..._8e6788c817c60371d2a2f158e1a65f87._comment |    8 +
 ..._97bdfacac5ac492281c9454ee4c0228e._comment |    8 +
 ..._53137b2df4913496c0afb2d895aa4ee2._comment |    8 +
 ..._ff1b0ba57e22ed757ec3fc5400b5e43e._comment |    8 +
 ..._a48fcfbf97f0a373ea375cd8f07f0fc8._comment |    8 +
 ..._099da245e3276fa84f5e14312d186621._comment |    8 +
 ..._6d3552414fdcc2ed3244567e6c67989d._comment |    7 +
 ..._05223be50c889b2ed6bc4abf74116450._comment |    9 +
 ..._fbbd93b55803ae21e6ba4b6568c2fafd._comment |    9 +
 ..._f4e9af3fed6c27e8ff39badb9794064d._comment |   12 +
 ..._c7ad07cade1f44f9a8b61f92225bb9c5._comment |   10 +
 ..._609d38e993267195a80fecd84c93d1e2._comment |    8 +
 ..._22b818e1a2a825efb78139271a14f944._comment |   10 +
 ..._d052e2142da8b4838fb1edf791ea23ae._comment |   10 +
 doc/design/assistant/configurators.mdwn       |   20 +
 doc/design/assistant/deltas.mdwn              |   27 +
 ..._bdb477af913c9782c0e8509e6b294b6e._comment |    8 +
 ..._71889d15ba20ebb0fe13080c68162a5b._comment |   11 +
 ..._c60bbe9b280855a583c7c3e48e803760._comment |   12 +
 ..._d1728f96202b7113b0671b90ed16473d._comment |   11 +
 doc/design/assistant/desymlink.mdwn           |  145 +
 ..._f1bfe250b7f872359f7075998b6e42e3._comment |   11 +
 ..._5e876edfe9853645f761b5ed9b5021aa._comment |    9 +
 ..._538561d74371e53c2f8df7f5ebdf58a8._comment |    8 +
 ..._586ecaa800e6c162377c937da5e65440._comment |   12 +
 ..._8fc703de67814cf2aec2a908852298a4._comment |   10 +
 ..._1b473ad89494afb82250af4b6df5f5c9._comment |   22 +
 doc/design/assistant/disaster_recovery.mdwn   |  185 +
 ..._955dc807196863da23aa8dbd15e04364._comment |   10 +
 .../assistant/encrypted_git_remotes.mdwn      |   22 +
 doc/design/assistant/gpgkeys.mdwn             |   40 +
 ..._a14427f88c9fd8e25ad8708146bb4bff._comment |   15 +
 doc/design/assistant/inotify.mdwn             |  234 +
 ..._3d3ff74447452d65c10ccc3dbfc323cd._comment |    7 +
 ..._a3c0fa6d97397c508b4b8aafdcee8f6f._comment |    7 +
 ..._b346e870c1cd80e4b0a313c3a9fed6b3._comment |    8 +
 ..._32be58b4c3b17a4ea539690d2fb45159._comment |   12 +
 ..._0cdd3046d90ad2012025d846ece0731e._comment |    8 +
 ..._e197d5d0d853572ec1f2e5985762e60d._comment |    9 +
 ..._00809aaad6b68f189a9cc42af810a0a6._comment |    8 +
 doc/design/assistant/leftovers.mdwn           |   17 +
 ..._b20c88bb3c583a32023c1f6b6dc9486d._comment |    8 +
 .../assistant/more_cloud_providers.mdwn       |   22 +
 doc/design/assistant/pairing.mdwn             |   83 +
 doc/design/assistant/partial_content.mdwn     |   36 +
 ..._58c4faa321a5bb71adf9fdee079849f4._comment |   18 +
 ..._588009d2140b7d259cdf191dca539e14._comment |    9 +
 doc/design/assistant/polls.mdwn               |    1 +
 .../assistant/polls/2013_user_survey.mdwn     |    1 +
 doc/design/assistant/polls/Android.mdwn       |   18 +
 ..._fa6c409833f28c67da105d25f4a440e0._comment |    8 +
 .../polls/Android_default_directory.mdwn      |    7 +
 ..._d39655091ac3ed51a9d4325d86b23ad7._comment |   10 +
 ..._2f1eaae95075db26488517720afd1c63._comment |    8 +
 ..._b484012f60789be73d7d5b338cff6203._comment |   10 +
 .../assistant/polls/goals_for_April.mdwn      |   17 +
 ..._9f81fa96db5970a4be0828c74a6d2d55._comment |   22 +
 ..._d8956d220ccacff3d2f6cbeb15718459._comment |   28 +
 ..._aadad6dfd56d068d2e377606910c006f._comment |    8 +
 .../polls/prioritizing_special_remotes.mdwn   |   16 +
 ..._dd9280df27848a7ff132f5809dab0a79._comment |    8 +
 ..._370e0b9c43486ee96c825f9155eebde4._comment |    8 +
 ..._883a003b9c552b89f191135c582f99aa._comment |   14 +
 ..._746006c3fffc7f917c4526fd688051f7._comment |    8 +
 ...ing_me_from_using_git-annex_assistant.mdwn |   16 +
 ..._10a4839a05be39ced54ffbe880a588bb._comment |   25 +
 ..._ac91d866f11c66dd8c86e2cd1a368c85._comment |   10 +
 ..._e244c1bf334b1cc9ad0cc760bf8fe5de._comment |   29 +
 ..._1a0faf4bdc78741937e8a2f5cb5bbec6._comment |   12 +
 ..._8d8a11dbfae7a7bc574bdf37f87e0684._comment |   16 +
 ..._c437adeaccf0b3d134e0f81c64e25b9f._comment |   14 +
 ..._6e3fce3a32ab346dc3d0fd4b69967536._comment |    8 +
 ..._1b7233d88593d0d99b26ea3e7af20d9c._comment |    8 +
 ..._a23d5a0e2718b8e486f036fe8a413b36._comment |   10 +
 ..._f4c84a9d701d52cf2f2e45f3d764a90c._comment |   18 +
 ..._00a0de8190d946caaeeca3b44646146f._comment |   16 +
 ..._199c9807499470771af6cbca6d034cfa._comment |    8 +
 ..._9185b0e05b1b1997533694da1de83073._comment |   22 +
 ..._35f6f121e54260cb960211a6e2e51e8e._comment |   14 +
 ..._acbe4f63b5d552ac5ae5a12c6f42dc18._comment |   25 +
 ..._0d988280865caae498a3b693b6342e37._comment |   16 +
 ..._ac8fe3768c30dd7999c183500f8567bb._comment |   19 +
 ..._36832de705a2bebf8dc6e65dcd661731._comment |   15 +
 ..._3618067e473577a112e36970ca71e0ab._comment |   12 +
 ..._07a13b6f000ddc0ac4472b863d8b50bd._comment |   14 +
 ..._e15eb407d988fda363296c8b566cc8fb._comment |   12 +
 doc/design/assistant/progressbars.mdwn        |   43 +
 ..._3ea263b1f334e8e38e14f00a96202988._comment |    8 +
 doc/design/assistant/rate_limiting.mdwn       |   57 +
 ..._bd0fd62297ff1f87884b41c11fc4320c._comment |    9 +
 doc/design/assistant/screenshot/firstrun.png  |  Bin 0 -> 54347 bytes
 doc/design/assistant/screenshot/intro.png     |  Bin 0 -> 50730 bytes
 doc/design/assistant/sshpassword.mdwn         |   65 +
 ..._24399abe0a0c1de271490ee15e064760._comment |    8 +
 ..._36a811bca209c7ac8a44d64bf8bc5bf3._comment |    8 +
 doc/design/assistant/syncing.mdwn             |  220 +
 ..._c70156174ff19b503978d623bd2df36f._comment |   19 +
 ..._eb992b5b2c7a5ce23443e2a6007e5ff9._comment |    8 +
 ..._e1b5e8a24556de16d1cacd27ee0c1bd1._comment |   80 +
 doc/design/assistant/syncing/efficiency.mdwn  |   77 +
 doc/design/assistant/telehash.mdwn            |  136 +
 ..._8b08b5c30e5aea3fc4599f856fd25df5._comment |    8 +
 doc/design/assistant/todo.mdwn                |    4 +
 doc/design/assistant/transfer_control.mdwn    |  123 +
 ..._d5adaef4712913dc0263d4ebafb79320._comment |   15 +
 ..._3b51474fefa6c0d19055046e06af196d._comment |   14 +
 ..._44a1a6d2db9097de9ae68ea1ff1b08a2._comment |    8 +
 doc/design/assistant/upgrading.mdwn           |   52 +
 doc/design/assistant/webapp.mdwn              |   65 +
 ..._bab6f6fa720273c0f9700a3765150189._comment |    8 +
 ..._3cf0cf460c7869d0cc22940fcc84aec4._comment |   10 +
 ..._428e153135f7a64215730719207d82c4._comment |    8 +
 ..._f4068a7abbb77ba6a3297cbcf1e503e9._comment |   10 +
 ..._2bdb436f35c659316193b89ee6e52fcb._comment |   11 +
 doc/design/assistant/windows.mdwn             |   33 +
 ..._f4b829318b182e1cec29f13babb6498e._comment |   10 +
 doc/design/assistant/xmpp.mdwn                |  136 +
 ..._f20650f93d7f0ca39b9ba3ce0380193f._comment |   10 +
 ..._8c22839a8f5912b4a817415c4a359697._comment |    8 +
 ..._773102522f21844cffc841e6cde9229e._comment |    8 +
 doc/design/assistant/xmpp_security.mdwn       |   29 +
 ..._c714e86553c02600249795efb224be8a._comment |   10 +
 doc/design/balanced_preferred_content.mdwn    |  149 +
 ..._a7eea522b04ddefbd0b9ff49dfb82d15._comment |    8 +
 doc/design/caching_database.mdwn              |  153 +
 doc/design/encryption.mdwn                    |  118 +
 ..._4715ffafb3c4a9915bc33f2b26aaa9c1._comment |   12 +
 ..._a610b3d056a059899178859a3a821ea5._comment |   10 +
 ..._cca186a9536cd3f6e86994631b14231c._comment |   12 +
 ..._8f3ba3e504b058791fc6e6f9c38154cf._comment |   10 +
 ..._520e60aa53217b5ba428d4c05d897dee._comment |   16 +
 ..._d677fead0fe0c543f48f07d85f83f592._comment |   14 +
 ..._c1c38a09b1276e29adc3ba564dc0fe4e._comment |   14 +
 .../exporting_trees_to_special_remotes.mdwn   |  356 +
 ..._75ba45174d3c4b927113a6908061b742._comment |   15 +
 ..._0827f5611c8e7e7ffa2633f8c06ae055._comment |    8 +
 ..._1bb8d57383ca733f3a0069ff30181366._comment |   10 +
 ..._f857e15124b70ae1abc74669f63a2d68._comment |    9 +
 ..._41e8ef74c6e62a4321d2046b2571a246._comment |   17 +
 ..._3fc518cee1a11b28da769c0915d33e3b._comment |   13 +
 ..._29f598eda413c0d5e17536d8f9438d31._comment |   11 +
 ..._32a3240206c5ffff71a47dffa6950c48._comment |   23 +
 ..._fe77370699b7ce0acd547fd1e045e254._comment |   15 +
 ..._00d28c758509939974e4583e9b1b9e12._comment |   10 +
 ..._1eda1af40f6ca82a8bacd19afaa749bc._comment |   18 +
 ..._ea84ee9de604e05b8e02483ba8452186._comment |   15 +
 ..._062098e1f54b874467793e4487a45a9b._comment |    8 +
 ..._d414fb575845770e003a3c8ca4a986be._comment |   10 +
 ..._cb063cdc66df79c40039bce247b7170c._comment |    9 +
 ..._126ee5332ff88b3993d33d59328d4148._comment |   24 +
 ..._fcd9890013371dae6ffcd00561b8c625._comment |   28 +
 ..._3217c2f852e5d9b1e4be2adff995dd24._comment |   19 +
 ..._43a98b4b9d9eb54720a9c92cd8bb3a30._comment |   14 +
 ..._7e512ef81c529b0392071b8a6dfe853b._comment |   11 +
 ..._6c588170f0b53c74c3c28ff08ed3509d._comment |    9 +
 doc/design/external_backend_protocol.mdwn     |  188 +
 ..._7a55199030c3b9f455354139af7dbac0._comment |    8 +
 ..._e6005a7563a65c0fd4615cc3f2c3034b._comment |   16 +
 ..._cd3410e6c1088289f71ed30b34d802f9._comment |    9 +
 ..._5b9814ca55e5fab94725ecdb5b1618f0._comment |   13 +
 ..._75ff466d7eeccd1eda9f8f18f465b296._comment |   10 +
 .../git-annex-backend-XFOO                    |   58 +
 .../external_special_remote_protocol.mdwn     |  554 +
 .../async_appendix.mdwn                       |   98 +
 ..._850d3eb7c04088041c96686b88c36662._comment |    8 +
 ..._897dbfbd4ed9c0f520bd2d4d0c961745._comment |   10 +
 ..._8d3c35eb0a2a9c57b10566fcaf56d248._comment |    8 +
 ..._241e57092d9e5631ac0ec4dd962477a6._comment |   12 +
 ..._e3029c65d34f78272bc11961ebfd8237._comment |   10 +
 ..._472748f03ba8dad773da7f35b70cb6e4._comment |   15 +
 ..._71c3e21a72222250bab933e1c9167fbc._comment |   14 +
 ..._c77386deddc64b2028d9c3a7393d4df7._comment |   10 +
 ..._62b137a138c143a8110886cc0bbb677e._comment |    8 +
 ..._8dc7bbf485c9385a4b506e8b8fa934fe._comment |   23 +
 ..._a0ed457b1b0d71747b6cf0c45897b5e1._comment |   19 +
 ..._89d532a5013af24f15a0d003cbfbab25._comment |   13 +
 ..._5baff75d278394a8818c348fb4f13b8a._comment |   10 +
 ..._546331742e906a68d760c1bf44be63c4._comment |   13 +
 ..._a8e8255516dc4741439615fa43b71829._comment |    8 +
 ..._0387827d94f141be53458807da9c2fc2._comment |    9 +
 ..._7a5af50f7c482d7c02c53be28ddb6a66._comment |   13 +
 ..._3340d3c34f2ec197f9010d97da8eb7af._comment |   11 +
 ..._56f38d934125c28172b6475bdb4de284._comment |   10 +
 ..._4f8addd76a1e64d05a34910d4719a40c._comment |   11 +
 ..._9153a5c49710bf57d11338829f66fa78._comment |   10 +
 ..._74961b12a73a52a700e10a21674e66ee._comment |    7 +
 ..._c1d97815386453c3e433fca9a44c4667._comment |    9 +
 ..._70429b7c4f1e4083a9d5a6e2e238056d._comment |    8 +
 ..._7d045871f9ebbb89e3f9bbfa28e8468f._comment |   18 +
 ..._907597187020180e7730e27e86f6da5e._comment |    8 +
 ..._f6b8306cfdcb3792728aa47af0677338._comment |   11 +
 ..._bee7ff39f3989dfbec292490e47bcaaa._comment |   19 +
 ..._af6ae46fa9228461573dd7b2f0713ef1._comment |    8 +
 ..._2f71f6d0caf4fa5ccd26618026714975._comment |   12 +
 ..._f8081ce200700516efef61ec0ac86f86._comment |    8 +
 ..._2aef2647d7df69876f107247e039f5a6._comment |    9 +
 ..._62f6621259587333a83776cf514b2497._comment |   27 +
 ..._ea321b96df3314a9e2a35cd0f8312972._comment |   13 +
 ..._c763e44d06d9f50f0d357889b180b819._comment |   15 +
 ..._a312c0180bce6dbbd03b14b8ba3dcb5f._comment |    8 +
 ..._7d63261342ea475f696cadb419782dbb._comment |   51 +
 ..._485588573d8d9f74e64cdf560f65e7fe._comment |    9 +
 ..._d942d979773d9361fbf3dde28c26a941._comment |   17 +
 ..._a72db8ed716effc507e7127f9ec95dc4._comment |    8 +
 ..._a25f00fb081e30f639376b6ad94cdb30._comment |   18 +
 ..._7ecdba05cb2bfc7d868b81bbd3e3f964._comment |   20 +
 ..._9d48c85b896f738323dec28c1955ee22._comment |   13 +
 ..._d378ab8adc6a73a17c39d62978cb9e90._comment |   26 +
 ..._9045ad13ad2c2f998173a870174eb3ee._comment |    9 +
 ..._20ff41d82b5f1872698a5b24adcd0c41._comment |   12 +
 ..._fdd9804134e6fe5e6527f35fc782cb80._comment |    8 +
 ..._c0eaa8639ad2b21ac917d9033d77a327._comment |    9 +
 ..._3c8c5a1d388929da4629f14b099d02d1._comment |   12 +
 ..._a2d1778e6d61f9cb606fb83f0a4a73f4._comment |   10 +
 ..._0225736488f9c1e7f78a08eea8ca864d._comment |   24 +
 ..._3ee158e548002badae5bf44dc0442626._comment |   13 +
 ..._ee2828ce25b83bbabc9d5dde35d1e57b._comment |   12 +
 ..._edb649d0019a061ef7bf6534a444429d._comment |   16 +
 ..._1f4c205a5ce6f33ccf2f4d80754e5699._comment |    8 +
 ..._15c4cfe064be37cc104dcb6aa049a449._comment |   14 +
 .../export_and_import_appendix.mdwn           |  347 +
 ..._9bcf18e2bbe04bf5321e4fc33cca577c._comment |    8 +
 ..._6bea5a316df43a8306fb1cb19192db3f._comment |   12 +
 doc/design/gcrypt.mdwn                        |    8 +
 doc/design/git-remote-daemon.mdwn             |  173 +
 ..._bfa8f33a3fdb6e271dfbdd0378b5d364._comment |   16 +
 doc/design/iabackup.mdwn                      |  242 +
 ..._d33c0910973bc37ce81bf434017e11fd._comment |   11 +
 ..._c0a59549409faa355a461e85a1c3f908._comment |    8 +
 ..._560d3f65d543c3af9722ed7e9a11e920._comment |   13 +
 ..._465c0966c96a57d189f678d4fa724aa0._comment |   13 +
 ..._7e4d1db9c69c63e79ca13db2ad87c384._comment |    7 +
 .../importing_trees_from_special_remotes.mdwn |  345 +
 doc/design/metadata.mdwn                      |  182 +
 ..._9bc2825b18ce29d2c9b2f085b95aa68c._comment |   18 +
 ..._402d7d3e8e7f2df57eb6685134226642._comment |   14 +
 ..._22ed80bd8eabaa836e9dfc2432531f04._comment |   22 +
 ..._03ae28acedbe1fa45c366b30b58fcf48._comment |   14 +
 ..._ee850df7d3fa4c56194f13a6e3890a30._comment |   12 +
 ..._c32ade1524487e5fdc6f83b2db39f04c._comment |    8 +
 ..._0ac3132cd7a84f0e170fbe3a6f235fe7._comment |    8 +
 ..._fa51ae544b193122334dbae7960ab3d9._comment |   15 +
 ..._04cd255a516c8520a7bc1a8fad253533._comment |    8 +
 ..._0a7e55e7626f72f63966fa1e1d2cf100._comment |    8 +
 ..._f0bb62c885a925e0da5ae8ce3c5e9003._comment |   10 +
 doc/design/new_repo_versions.mdwn             |  230 +
 ..._b7b4819211910556838ec37bc2b6b37b._comment |   14 +
 ..._8f35254d2cd5d0c273d5392ddd857c2d._comment |   24 +
 doc/design/p2p_protocol.mdwn                  |  212 +
 ..._367bebae5b84408c7592b5fcca993c1e._comment |   30 +
 ..._dbd118a01c31d17a4223a32a7baa8e39._comment |   15 +
 ..._94fff4c163de15cdad2030ac072b19ae._comment |    8 +
 ..._f48e73ea2b6f70597837d09d3c5d3849._comment |    9 +
 ..._08b190ff1c6d1e890311edf7cc7bfcd4._comment |   20 +
 doc/design/passthrough_proxy.mdwn             |  127 +
 doc/design/preferred_content.mdwn             |   21 +
 doc/design/requests_routing.mdwn              |  100 +
 ..._421b14a4dd9d6c431e00333057df1627._comment |   10 +
 ..._a409df0566b308bf2b84efd4fb2c8a8f._comment |    7 +
 ..._924e6254bf51a5b19eb7fe635053a16e._comment |   10 +
 doc/design/requests_routing/simroutes.hs      |  402 +
 doc/design/roadmap.mdwn                       |   12 +
 doc/devblog.mdwn                              |    3 +
 doc/devblog/day_-1__drop_dead.mdwn            |    5 +
 doc/devblog/day_-3__.mdwn                     |   29 +
 doc/devblog/day_-4__forgetting.mdwn           |   80 +
 ..._f3cc7a25af4c59fda3924c737a789419._comment |    8 +
 ..._e47476c80af02a2e9cf76c53fdbb8534._comment |    9 +
 ..._b57956a8ce372d620f21ea9a497e8013._comment |    8 +
 ..._812b630df01ac35254e3c4e677554e2b._comment |    8 +
 ..._a9670eca2aff9ad5f04412a8d8b6df6a._comment |    8 +
 ..._4f87e2ab119f3cd81266159f02952188._comment |    9 +
 ..._a865216046aa91a47d0d2b2f0668ea89._comment |   12 +
 ..._3f7045a00905b4287d950b08d5a77a82._comment |    9 +
 ..._d9121a5172f02df63364f19eae87d011._comment |    8 +
 .../day_100__git-annex_sync_--content.mdwn    |    4 +
 doc/devblog/day_101__old_mistakes.mdwn        |   23 +
 ..._2c6e991efde3296450189b2821f2ccc3._comment |   17 +
 ..._524690d69056737dd296e4f7626737d2._comment |   12 +
 doc/devblog/day_102__cleanups.mdwn            |   10 +
 doc/devblog/day_103__unused.mdwn              |   34 +
 doc/devblog/day_104__unused_II.mdwn           |    7 +
 ..._a693a56123497a39c30cbd35b8e35bce._comment |   10 +
 ..._9833fb9daa50bc838cc46ca2f6c16580._comment |   10 +
 ..._873a882ec1ddc3be473473cb224a9040._comment |   12 +
 ..._5ef1bb4d69cf7206f7ca0e542abad6bd._comment |   13 +
 ..._1964bfce4887c9c0828fd7f54f5b4f6b._comment |   12 +
 ..._0ed4023c9c249024fe0454fc5bab3b14._comment |   10 +
 doc/devblog/day_105__locking.mdwn             |   30 +
 doc/devblog/day_106__catching_up.mdwn         |    5 +
 doc/devblog/day_107__TDD.mdwn                 |   10 +
 ...ay_108__new_use_for_location_tracking.mdwn |   20 +
 .../day_109__elimintating_absNormPath.mdwn    |   18 +
 doc/devblog/day_10__lazy_Sunday.mdwn          |   23 +
 doc/devblog/day_110__release_prep.mdwn        |   25 +
 .../day_111__windows_beta_release.mdwn        |    6 +
 doc/devblog/day_112__metadata_design.mdwn     |   18 +
 doc/devblog/day_113__metadata_groundwork.mdwn |    9 +
 doc/devblog/day_114__windows_porting.mdwn     |    8 +
 doc/devblog/day_115__windows_porting.mdwn     |   17 +
 doc/devblog/day_116__views.mdwn               |   54 +
 doc/devblog/day_117__views_implemented.mdwn   |   76 +
 doc/devblog/day_118__views_refined.mdwn       |    7 +
 doc/devblog/day_119__catching_up.mdwn         |   15 +
 ..._8aa413e75cab411b0aec254f0f33ebb9._comment |    8 +
 ..._db31d08690730836ce6277e797fcae1d._comment |    8 +
 ..._d44da76b18f53a5f51b46e3e15090a48._comment |    8 +
 .../day_11__webapp_encrypted_drives.mdwn      |   12 +
 doc/devblog/day_120__more_metadata.mdwn       |   17 +
 .../day_121__special_remote_maintenance.mdwn  |   23 +
 doc/devblog/day_122_more_windows_porting.mdwn |    4 +
 doc/devblog/day_123__stuck.mdwn               |   13 +
 doc/devblog/day_124__day_off.mdwn             |   13 +
 doc/devblog/day_125__metadata_and_views.mdwn  |   11 +
 doc/devblog/day_128__release_prep.mdwn        |   27 +
 doc/devblog/day_12__gpg_key_generation.mdwn   |   35 +
 ..._48cdfe3bd71fb348ae05fd90e8cf1dab._comment |    8 +
 doc/devblog/day_130__post_release.mdwn        |   17 +
 doc/devblog/day_131__more_bug_squashing.mdwn  |   11 +
 doc/devblog/day_132__database_musings.mdwn    |   17 +
 doc/devblog/day_133__db_and_bugfixes.mdwn     |   20 +
 ...y_134-135__avoiding_the_turing_tarpit.mdwn |   18 +
 doc/devblog/day_136__frustrating_day.mdwn     |   10 +
 ...-138__bug_triage_and_too_much_windows.mdwn |   15 +
 doc/devblog/day_139-140__traveling.mdwn       |   17 +
 .../day_13__encrypted_sneakernet_working.mdwn |   13 +
 doc/devblog/day_141__f-droid_sprint.mdwn      |    3 +
 ..._1cc76207020ac478747117c76d7b5f9c._comment |    8 +
 doc/devblog/day_142__digging_out.mdwn         |   13 +
 doc/devblog/day_143__foolish_hiatus.mdwn      |   20 +
 doc/devblog/day_144__catching_up.mdwn         |   12 +
 ..._311a7245dd12f1a7e432168d16041348._comment |    8 +
 doc/devblog/day_145__a_plan.mdwn              |   16 +
 ..._c0ceea77443be1172527ed8549f000a4._comment |   10 +
 ...day_146__halfway_to_git-remote-daemon.mdwn |   17 +
 .../day_147__git-annex_remotedaemon.mdwn      |    5 +
 doc/devblog/day_148__too_many_documents.mdwn  |    8 +
 .../day_149__remote_control_working.mdwn      |   15 +
 doc/devblog/day_149__signal.mdwn              |   16 +
 ..._14__gcrypt_refinements_and_OOM_fixes.mdwn |   26 +
 doc/devblog/day_15-17__Android_rebuild.mdwn   |   67 +
 doc/devblog/day_151__birthday_bug.mdwn        |   18 +
 .../day_152__more_ssh_connection_caching.mdwn |   37 +
 .../day_153__remotedaemon_has_landed.mdwn     |   10 +
 ..._f19ae6b3d6f33a68e4ffe0c32f788745._comment |   13 +
 ..._fbf0c50f772e958af638d2b72dac73f5._comment |   10 +
 doc/devblog/day_154__catching_up.mdwn         |   13 +
 doc/devblog/day_155__missing_bits.mdwn        |   27 +
 ..._76424498600ba603946035efffb88023._comment |    8 +
 doc/devblog/day_156__release_day.mdwn         |   14 +
 doc/devblog/day_157__upgrade_checking.mdwn    |   22 +
 doc/devblog/day_158__enroute_to_Brazil.mdwn   |   10 +
 doc/devblog/day_159__tmp_file_cleanup.mdwn    |   12 +
 doc/devblog/day_160__.mdwn                    |   20 +
 doc/devblog/day_161__routing_design.mdwn      |   13 +
 ...g_sim_and_massive_contribution_landed.mdwn |   17 +
 .../day_163__request_and_routing_design.mdwn  |    3 +
 doc/devblog/day_164__back.mdwn                |   17 +
 doc/devblog/day_165__sshpassword_merged.mdwn  |   18 +
 doc/devblog/day_166__catching_up.mdwn         |   40 +
 ...e_community_of_git-annex_contributors.mdwn |   11 +
 doc/devblog/day_168__backlog_continued.mdwn   |   16 +
 doc/devblog/day_169-171__juggling.mdwn        |   14 +
 doc/devblog/day_172__.mdwn                    |    7 +
 .../day_173-174__android_rebootstrap.mdwn     |    8 +
 doc/devblog/day_175__encoding_day.mdwn        |   20 +
 doc/devblog/day_176__mostly_a_day_off.mdwn    |    8 +
 doc/devblog/day_177__enabling.mdwn            |   21 +
 ..._820d29f84dade09b0e7bb7435c52fcb8._comment |   12 +
 ...day_178-179__screencast_and_what_next.mdwn |   12 +
 ..._eeba788fed45cb22f9cc2a738ceaa074._comment |    8 +
 ..._d44e67e34615c7b00e29f307556cdd06._comment |    8 +
 doc/devblog/day_180__porting.mdwn             |   13 +
 ..._133875f4435a298b85ddfb8a2cc11a7a._comment |    9 +
 doc/devblog/day_181__tricky_merge.mdwn        |    8 +
 doc/devblog/day_182__service.mdwn             |    6 +
 .../day_183__rubbing_sticks_together.mdwn     |   23 +
 doc/devblog/day_184__windows_month.mdwn       |   22 +
 doc/devblog/day_185__service.mdwn             |    6 +
 doc/devblog/day_186__cracked_it.mdwn          |    8 +
 ..._288b736adf392acd0f45667b2980138d._comment |   11 +
 ..._d1d79e93ac420f6b3a6f8a622e8e00bd._comment |    8 +
 ..._8ca17a51b10b4e4a63d0672d5ce29024._comment |    8 +
 doc/devblog/day_187__release_prep.mdwn        |   10 +
 ..._206692d16177c2a9ca11c0eeff545697._comment |   13 +
 ..._961fb35d9cf7d5e518f8d0bddb8626a6._comment |    8 +
 doc/devblog/day_188__back_sans_laptop.mdwn    |    5 +
 .../day_189__finally_working_again.mdwn       |   18 +
 doc/devblog/day_190__fun_fixes.mdwn           |   13 +
 doc/devblog/day_191__semidistracted.mdwn      |    7 +
 doc/devblog/day_192__release_day.mdwn         |    4 +
 doc/devblog/day_193-194__ugly_bug.mdwn        |   37 +
 doc/devblog/day_195-196__catching_up.mdwn     |   13 +
 .../day_197__autobuilder_rescuscitation.mdwn  |   14 +
 doc/devblog/day_198__branching_out.mdwn       |   23 +
 ..._91ce3dc707ba1ba7c5d9e57e20ffce40._comment |    8 +
 doc/devblog/day_199__ten_minute_cycle.mdwn    |    6 +
 doc/devblog/day_19__moving_on.mdwn            |   37 +
 ..._870106f671f9a055b81e6fc83e0850b5._comment |    8 +
 ..._fad055c8860385ac6c012f897c96408f._comment |   10 +
 ..._69e47d612159587f080ab761566d1830._comment |   18 +
 .../day_1__inauspicious_beginning.mdwn        |   11 +
 ..._cc4dea43caf3126c6f814b589b701d70._comment |   10 +
 doc/devblog/day_200__one_year_along.mdwn      |   17 +
 doc/devblog/day_201__chunky.mdwn              |   12 +
 .../day_202__new_chunk_groundwork.mdwn        |    6 +
 doc/devblog/day_203__in_the_weeds.mdwn        |   39 +
 doc/devblog/day_204__mowing.mdwn              |   64 +
 doc/devblog/day_205__incremental.mdwn         |   21 +
 doc/devblog/day_206__zap.mdwn                 |   83 +
 doc/devblog/day_207__at_last.mdwn             |   34 +
 doc/devblog/day_208__testremote.mdwn          |   10 +
 doc/devblog/day_209__mass_conversion.mdwn     |   32 +
 .../day_20__gcrypt_and_git-annex-shell.mdwn   |   14 +
 .../day_210__conversion_and_digression.mdwn   |   14 +
 doc/devblog/day_211__conversion_complete.mdwn |   12 +
 doc/devblog/day_212__webdav_rewrite.mdwn      |   18 +
 doc/devblog/day_213__newchunks_merged.mdwn    |   15 +
 .../day_214-215__wrapping_up_recent_work.mdwn |   16 +
 doc/devblog/day_216__various_minor_bugs.mdwn  |   16 +
 ..._0d0a0e75b9446f8a1c4cc43f36569473._comment |    8 +
 ..._6b06b3f46f20a6d2e60684d1d59fca07._comment |    8 +
 ..._05177e2ed414d22711dcec57a614e38c._comment |    8 +
 doc/devblog/day_217__autobuilders.mdwn        |   10 +
 doc/devblog/day_218__scary_locking.mdwn       |   24 +
 ...day_219__catching_up_and_looking_back.mdwn |  109 +
 ..._16b13b2510183a9da5f960ae5765e581._comment |   10 +
 ..._460c064bebb5061fcba2a6c79f039362._comment |   19 +
 ..._9699d5a9de5ea64fbc876352e20261c4._comment |    8 +
 ..._23c4ede3db0ea8165311466881cfa6a2._comment |   10 +
 ..._7997305d7ec7db072b78dd0c31ecd824._comment |    8 +
 doc/devblog/day_21__bugfix_day.mdwn           |    5 +
 .../day_220__working_through_backlog.mdwn     |   14 +
 ...ay_221__another_fine_day_of_bugfixing.mdwn |   10 +
 .../day_222_preparing_for_debian_release.mdwn |   12 +
 .../day_223__partial_commit_problem.mdwn      |   26 +
 doc/devblog/day_224-226__long_rainy_slog.mdwn |   14 +
 doc/devblog/day_227__info.mdwn                |   33 +
 doc/devblog/day_229__S3_multipart.mdwn        |   11 +
 doc/devblog/day_22__gcrypt_on_rsync.net.mdwn  |   20 +
 .../day_230__S3_multipart_round_2.mdwn        |    9 +
 .../day_231__S3_multipart_wrapped_up.mdwn     |   13 +
 doc/devblog/day_232__OSX_Yosemite.mdwn        |    6 +
 doc/devblog/day_233__direct_mode_proxy.mdwn   |   29 +
 doc/devblog/day_234__undo_undo.mdwn           |    6 +
 .../day_235__thanksgiving_backlog.mdwn        |   18 +
 doc/devblog/day_236__release_day.mdwn         |   10 +
 doc/devblog/day_237__extending_addurl.mdwn    |   14 +
 .../day_238__extending_addurl_further.mdwn    |   67 +
 .../day_239-240__bittorrent_remote.mdwn       |   16 +
 doc/devblog/day_23__GNU_day.mdwn              |   23 +
 .../day_241-242__end_of_year_cleanup.mdwn     |   22 +
 doc/devblog/day_243__android_5.mdwn           |   16 +
 ..._59a139108f4cf20dd7443a5fa767f614._comment |    9 +
 doc/devblog/day_244__relative_paths.mdwn      |   14 +
 doc/devblog/day_245__yak_shaving.mdwn         |    9 +
 doc/devblog/day_246__old_todos.mdwn           |    9 +
 ...247__hooks_and_large_files_on_windows.mdwn |   30 +
 doc/devblog/day_248__workload_tuning.mdwn     |   54 +
 doc/devblog/day_249_onward.mdwn               |   28 +
 ..._80af832a132ee37a470d0586ae751f2a._comment |   10 +
 ..._ada958a8df4da36b25a456a7700b310f._comment |    8 +
 .../day_24__nearly_done_with_gcrypt.mdwn      |   23 +
 doc/devblog/day_250__backog_bugfixing.mdwn    |   10 +
 .../day_251-252__dusting_off_the_roadmap.mdwn |   12 +
 .../day_253__sqlite_for_incremental_fsck.mdwn |   58 +
 ..._683d669ac6af8e314585609f75cfdaf3._comment |    7 +
 ..._08dd639180ae79addc007ee47d52048a._comment |    7 +
 doc/devblog/day_253__ssh-options.mdwn         |    5 +
 ...55__sqlite_concurrent_writers_problem.mdwn |   34 +
 .../day_256__sqlite_concurrency_argh.mdwn     |   28 +
 doc/devblog/day_257__release_day.mdwn         |   17 +
 .../day_258__database_branch_merged.mdwn      |   25 +
 doc/devblog/day_259__submodules.mdwn          |    8 +
 doc/devblog/day_25__finishing_up_gcrypt.mdwn  |   25 +
 doc/devblog/day_260__random_month.mdwn        |   27 +
 doc/devblog/day_261__random_improvements.mdwn |    5 +
 doc/devblog/day_262__ipfs.mdwn                |   16 +
 doc/devblog/day_263__diving_back_in.mdwn      |    7 +
 doc/devblog/day_264__catching_up.mdwn         |    7 +
 doc/devblog/day_265__at_Dartmouth.mdwn        |    4 +
 doc/devblog/day_266-267__man_page_split.mdwn  |   16 +
 ..._d55600917128cb0ce38002fbf6f0b088._comment |    7 +
 ..._63791201452a6ab30a35cd742434acca._comment |    8 +
 ..._d7764c605ad338c4bf4c4b46b54abd8a._comment |    8 +
 doc/devblog/day_268_stressed_out.mdwn         |   18 +
 ..._d28352c9fbc988ece19688a687d30ffe._comment |   10 +
 ..._f7b04b2e96f0fc7530f1c21ccfcfb0f9._comment |    8 +
 ..._0eb4c17d35fba9db6a7446a5f253ace9._comment |   24 +
 ..._fecf179be92c3a3e25f4a47fcea6b6ec._comment |   10 +
 .../day_269__wildcards_and_podcasts.mdwn      |   26 +
 .../day_26__gcrypt_really_done_this_time.mdwn |   17 +
 doc/devblog/day_270__distributed_fsck.mdwn    |   27 +
 .../day_271__parallel_get_groundwork.mdwn     |   32 +
 doc/devblog/day_272__forest_for_trees.mdwn    |   13 +
 doc/devblog/day_273__unexpected_release.mdwn  |   15 +
 .../day_274__concurrent_annex_state.mdwn      |   42 +
 ..._7414fc0dde7a1d1ee456f8eba0b0c2a9._comment |   11 +
 ..._4ca498ee4b4aaac8ee6dbc2c769dbad7._comment |   21 +
 doc/devblog/day_275-276__mostly_Windows.mdwn  |   20 +
 doc/devblog/day_277__thanks.mdwn              |   20 +
 doc/devblog/day_278__release_day.mdwn         |   25 +
 doc/devblog/day_279__.mdwn                    |   10 +
 doc/devblog/day_27__locking_fun.mdwn          |   49 +
 ..._0eb247235fbf8f563934f3548e1d2e10._comment |    8 +
 ..._e8b1dfe1b0641e031d05733448b7bc8b._comment |    8 +
 ..._b67f8ef4ed42b49c8c2e6c4e53163b16._comment |   18 +
 ..._0759644baf26b75f4e48dbb387d725a5._comment |   10 +
 doc/devblog/day_280__slow_week.mdwn           |   16 +
 ...tching_up__and_arm_autobuilder_needed.mdwn |   43 +
 doc/devblog/day_282__release_day.mdwn         |   16 +
 doc/devblog/day_283__lazy_sunday.mdwn         |    7 +
 ..._fdc6da890e2dc6b86b6a5fe2ebceea4a._comment |    9 +
 doc/devblog/day_284__development.mdwn         |   33 +
 ...day_285__tuning_git-annex_unused_refs.mdwn |   20 +
 ..._a3f0dd4fc8457af7c72040fbe8fd5fee._comment |   13 +
 ..._dae167e473c60dace129c66beb0af384._comment |    7 +
 ..._52179fc326e681d8fbf85ee8963f352c._comment |    9 +
 doc/devblog/day_286-287__rotten_locks.mdwn    |   44 +
 doc/devblog/day_288__microrelease_prep.mdwn   |   22 +
 ..._99e359976acbdb9727598f8a87027de0._comment |    7 +
 ..._27a74d3926083a00c110aafea28420d7._comment |    7 +
 ..._17752e96baaf46f3048b14a9ec288e3b._comment |    8 +
 ..._2838c1d9da3202616e331bb31fd43f20._comment |   10 +
 doc/devblog/day_289__new_arm_autobuilder.mdwn |   21 +
 doc/devblog/day_28__lazy_saturday.mdwn        |   17 +
 doc/devblog/day_290__.mdwn                    |   23 +
 doc/devblog/day_291__public_S3.mdwn           |   20 +
 ..._c0e96b25b764180975cc26b1316f462d._comment |   11 +
 ..._d5223684c09725973b2052425fd30773._comment |   10 +
 doc/devblog/day_292__dead_keys.mdwn           |   21 +
 ...293__last_push_before_summer_vacation.mdwn |   26 +
 .../day_294__back_focusing_on_bugs.mdwn       |    7 +
 doc/devblog/day_295__caught_up.mdwn           |    8 +
 doc/devblog/day_296__into_the_backlog.mdwn    |   16 +
 .../day_297__optparse-applicative.mdwn        |   25 +
 ...day_299__so_many_commands_and_options.mdwn |    9 +
 doc/devblog/day_29__scheduling.mdwn           |   10 +
 doc/devblog/day_2__new_laptop.mdwn            |    8 +
 ..._93447dbd4eb09b4db96770644ea663cb._comment |   10 +
 ..._e1d022b25f2c16dbe72db07ad4b10a2d._comment |    8 +
 .../day_300__optparse-applicative_landed.mdwn |    3 +
 ...day_301__completion_and_er_completion.mdwn |    9 +
 doc/devblog/day_302-305__gitlab.mdwn          |   30 +
 doc/devblog/day_306__release_day.mdwn         |    8 +
 doc/devblog/day_307__two_release_week.mdwn    |   11 +
 doc/devblog/day_308__other_peoples_bugs.mdwn  |   11 +
 doc/devblog/day_309__proxy.mdwn               |    5 +
 doc/devblog/day_30__cronner.mdwn              |   17 +
 ..._53dfd9310e92f5225db52a13e20a46d4._comment |   10 +
 ..._f98357c6f7a6da23873ac27c2e1e9638._comment |   10 +
 doc/devblog/day_310__half_day.mdwn            |    7 +
 ..._81db682a271ebc92cce893762c3930a8._comment |    9 +
 doc/devblog/day_311__SHA-3.mdwn               |    6 +
 doc/devblog/day_312__release_prep.mdwn        |   12 +
 doc/devblog/day_313__optimisation.mdwn        |    7 +
 doc/devblog/day_314__pre_trip_catchup.mdwn    |   13 +
 doc/devblog/day_315__scrambling.mdwn          |    5 +
 ...6-318__chasing_dependencies_and_todos.mdwn |   24 +
 doc/devblog/day_319__release_day.mdwn         |    6 +
 doc/devblog/day_31__blah.mdwn                 |   17 +
 doc/devblog/day_320__caught_up.mdwn           |   13 +
 doc/devblog/day_320__porting_and_such.mdwn    |   13 +
 .../day_321__download_verification.mdwn       |   13 +
 ..._424367fba4db56f4699952572bd3d605._comment |    7 +
 ..._926cc165e99f2e125c909bd706460a05._comment |    7 +
 ..._fb0ed50c27a493c3494bf2efbf9a9c5d._comment |    7 +
 ..._fecb2d6349aa61f1c76525178fea4598._comment |    7 +
 .../day_322-326__concurrent_drop_safety.mdwn  |   49 +
 doc/devblog/day_327__soaking.mdwn             |   16 +
 doc/devblog/day_328__git-annex_is_five.mdwn   |   15 +
 ..._ff7e8d4c37f4a1aa189af0354db8794a._comment |   11 +
 ..._9e18a2c71884229f06b5ba62a6529a33._comment |    9 +
 doc/devblog/day_32__fsck_config_UI.mdwn       |   20 +
 ...y_331__concurrent-output_preparations.mdwn |   11 +
 ...y_332__concurrent_output_at_long_last.mdwn |    6 +
 doc/devblog/day_333__cylons.mdwn              |    5 +
 doc/devblog/day_334__too_easy.mdwn            |    6 +
 ..._2181970ef1a3380407ce9eef311c9ebc._comment |    7 +
 ...335__catching_up_with_the_bug_reports.mdwn |    4 +
 doc/devblog/day_336__green.mdwn               |   15 +
 doc/devblog/day_336__pid_locks.mdwn           |   27 +
 doc/devblog/day_337__who_needs_POSIX.mdwn     |   21 +
 doc/devblog/day_338__week_in_review.mdwn      |   16 +
 .../day_339_smudging_out_direct_mode.mdwn     |   61 +
 ..._6435db0003d2d8414b1a040b8899c7b8._comment |   11 +
 ..._79d19b2b057c2a0b23875a32dae0c2ba._comment |   13 +
 ..._43f7c7c6c2fd227466857c3232e13351._comment |    7 +
 ..._78e16167ca29eb3ed43706b39bf08603._comment |    8 +
 ..._35d0472cd64335eedeeb17d51cdbaf5b._comment |   13 +
 ..._499f3553c4efc35e54f121a7d4abc029._comment |   30 +
 ..._ede48107675edfe40d5fdd3377553aa4._comment |   12 +
 ..._ceb1d2a0e5bbc73590b80ff69292102d._comment |   15 +
 doc/devblog/day_33__fsck_on_connect.mdwn      |    9 +
 doc/devblog/day_340__post_turkey_catchup.mdwn |    9 +
 doc/devblog/day_341__starting_smudge.mdwn     |   24 +
 doc/devblog/day_342__continuing_smudge.mdwn   |   30 +
 .../day_343__get_and_drop_for_smudge.mdwn     |   26 +
 doc/devblog/day_344-345__smudging_along.mdwn  |    7 +
 .../day_346-347__nearly_ready_to_merge.mdwn   |   19 +
 doc/devblog/day_348__v6_assistant.mdwn        |    8 +
 .../day_349__v6_database_optimisation.mdwn    |    7 +
 doc/devblog/day_34__wrapping_up_fsck.mdwn     |    7 +
 .../day_350-351__it_landed_on_xmas_eve.mdwn   |    9 +
 doc/devblog/day_352__had_to_be_done.mdwn      |    3 +
 ...53__one_step_forward_and_N_steps_back.mdwn |    5 +
 ...ay_354-355__beating_on_the_test_suite.mdwn |    8 +
 doc/devblog/day_356__benchmarking.mdwn        |   11 +
 .../day_357__post_release_catchup.mdwn        |    8 +
 ..._6963d1c6be69e531726f62f02d50855c._comment |    7 +
 doc/devblog/day_358__bugfix_release.mdwn      |    9 +
 ..._a9aa122010e576c572ca719638ecf2e6._comment |    7 +
 ...y_359__annex.largefiles_gitattributes.mdwn |   18 +
 ..._ac73ad4147629c25cd51d13cfea206cf._comment |    9 +
 ..._cfbf4fb5a3a1beb582faa051d1627a31._comment |   13 +
 .../day_35__anacron_and_bugfixing.mdwn        |   15 +
 .../day_360__annex.largefiles_mimetype.mdwn   |    8 +
 ..._78a22b96a82f76ab7217d37918a19024._comment |    9 +
 ..._3145e5843e20a037351e5a14fa3d6e9a._comment |   17 +
 ..._bf44404de52b00ff4e4f1effd4cef336._comment |    8 +
 ..._70c337d91f8d0458927c111763041118._comment |   13 +
 .../day_360__results_of_2015_user_survey.mdwn |   56 +
 ..._5f30c583cd20c33e2bcd386f674d6f3b._comment |    9 +
 ..._68479af6dda2f732436b19160297aacd._comment |    7 +
 ..._e38568c6baa30f58c5a7735b2f7985ed._comment |    7 +
 ..._e0bfb67454df205f2c9c566933e7f121._comment |    9 +
 .../day_361__adjusted_branches_design.mdwn    |    5 +
 doc/devblog/day_362__encoding_fun.mdwn        |   19 +
 doc/devblog/day_363__snow_day.mdwn            |   11 +
 doc/devblog/day_364__more_v6_unlocked.mdwn    |    8 +
 .../day_365__some_kind_of_milestone.mdwn      |    6 +
 .../day_366__starting_adjusted_branches.mdwn  |   33 +
 ...7__adjusted_branches_proof_of_concept.mdwn |   18 +
 doc/devblog/day_368__leap.mdwn                |    9 +
 .../day_369-370__paddling_furiously.mdwn      |   72 +
 doc/devblog/day_36__bugfixing.mdwn            |    1 +
 doc/devblog/day_371__catching_up.mdwn         |   21 +
 .../day_372__adjusted_branches_improved.mdwn  |   18 +
 doc/devblog/day_373__away.mdwn                |    6 +
 doc/devblog/day_374__security_fix.mdwn        |    4 +
 doc/devblog/day_375__back.mdwn                |   10 +
 doc/devblog/day_376__in_the_weeds.mdwn        |   18 +
 ..._377__will_adjusted_branches_ever_end.mdwn |   21 +
 ...78__finishing_adjusted_branches_merge.mdwn |   23 +
 ...y_379__bugs_race_conditions_and_taxes.mdwn |   12 +
 doc/devblog/day_37__long_day.mdwn             |    6 +
 doc/devblog/day_380__post_release.mdwn        |    8 +
 .../day_381__executable_unlocked_files.mdwn   |    2 +
 .../day_382-384__pretty_well_caught_up.mdwn   |    9 +
 doc/devblog/day_385__new_features.mdwn        |   16 +
 ..._f76ff85897f24692e96f88236b7f4b7d._comment |   11 +
 doc/devblog/day_386__day_off.mdwn             |   12 +
 doc/devblog/day_387__release_day.mdwn         |   10 +
 ..._3e48e930616917f6db1fc351d0f7e6df._comment |   12 +
 ..._86262439c9056c0e06623cdf79eaf9a6._comment |   15 +
 .../day_388-389__various_and_windows.mdwn     |   13 +
 .../day_38__starting_git_repo_repair.mdwn     |   11 +
 ..._321468d9686db5dde072500bdaeb7d29._comment |   10 +
 doc/devblog/day_390__sharedpubkey.mdwn        |    5 +
 ...__git_smudge_clean_interface_proposal.mdwn |    3 +
 doc/devblog/day_392__v6_fixes.mdwn            |   12 +
 ..._6da0787fa9749ee2d1f91842f10a5d3c._comment |    7 +
 ..._15434848be1951e93a1e5b9fcbccedb0._comment |   12 +
 ..._74e696f147f80162a941a5a5435327ce._comment |    7 +
 doc/devblog/day_393__fun_and_more_fun.mdwn    |   15 +
 .../day_394__implicit_vs_explicit.mdwn        |   23 +
 doc/devblog/day_395__leaky_abstractions.mdwn  |    7 +
 doc/devblog/day_396__misc_fixes.mdwn          |   11 +
 doc/devblog/day_397__befuddled.mdwn           |   28 +
 doc/devblog/day_398__fresh_eyes.mdwn          |   11 +
 doc/devblog/day_399__weird_git_merge_bug.mdwn |   16 +
 .../day_39__git-recover-repository.mdwn       |   54 +
 doc/devblog/day_3__gcrypt_uuids.mdwn          |   63 +
 doc/devblog/day_400-401__git_development.mdwn |   11 +
 ..._402__enhanced_smudge_clean_interface.mdwn |   14 +
 doc/devblog/day_403__update_and_away.mdwn     |    4 +
 doc/devblog/day_404__low_hanging_fruit.mdwn   |   15 +
 .../day_405__more_git_development.mdwn        |    3 +
 .../day_406__low_handing_fruit_continued.mdwn |    3 +
 doc/devblog/day_407__lazy_sunday.mdwn         |    9 +
 doc/devblog/day_408__release_day.mdwn         |    6 +
 .../comment_1_RichiH._comment                 |    3 +
 doc/devblog/day_409__--branch.mdwn            |   17 +
 doc/devblog/day_40__another_fine_mess.mdwn    |   15 +
 .../day_410__better_JSON_for_metadata.mdwn    |   31 +
 doc/devblog/day_411__metadata_--batch.mdwn    |    4 +
 ...day_412__if_at_first_you_dont_succeed.mdwn |   49 +
 ..._8980f56815a2c016ca950aec09e6e839._comment |   18 +
 ..._641ca9bce852cea42cac25fd77518885._comment |    7 +
 doc/devblog/day_413__back.mdwn                |   19 +
 .../day_414__improved_parallel_get.mdwn       |    6 +
 doc/devblog/day_415__catching_up.mdwn         |   19 +
 doc/devblog/day_416__measure_twice.mdwn       |    8 +
 doc/devblog/day_417__cut_once.mdwn            |    6 +
 .../day_418__concurrent_externals.mdwn        |   12 +
 ..._75e6569b143cf3f595ba9b356415a747._comment |   11 +
 ..._067909ed54f3f9295f90233f25ccfd70._comment |    8 +
 ..._39c729fc2ea4b597d13e54d60bb36d0d._comment |    7 +
 ..._6b254fbe92d40abc30d01afe5d039afc._comment |    8 +
 ..._5e851b62bdca1cb8d8062d4890c77956._comment |    7 +
 ..._ea5d42bcb03af937a604119039f9073a._comment |    7 +
 doc/devblog/day_419__catching_up.mdwn         |   23 +
 doc/devblog/day_41__onward.mdwn               |   17 +
 ..._a716c7b5a9ea3c949ff047cfb4e9a0a4._comment |    8 +
 ..._33149e424cd5f03fac376288bcc4dfdc._comment |    8 +
 ..._3b07503bd79089ad3ce3ddd7535ed116._comment |   14 +
 doc/devblog/day_420__delayed_debugging.mdwn   |   17 +
 doc/devblog/day_421__lost_in_the_trees.mdwn   |    6 +
 .../day_422__bugfixes_for_v6_mode.mdwn        |   16 +
 doc/devblog/day_423__ssh_fun.mdwn             |   19 +
 doc/devblog/day_424__the_dog.mdwn             |   11 +
 doc/devblog/day_425__tor.mdwn                 |   23 +
 ..._1dd41fa32eb3867d764f3238005b5b81._comment |   11 +
 doc/devblog/day_426__grab_bag.mdwn            |   63 +
 ..._4d01c756850032d351fa99188a3301a7._comment |   11 +
 doc/devblog/day_427__free_p2p.mdwn            |   51 +
 ..._428-429__git_push_to_hiddden_service.mdwn |   31 +
 doc/devblog/day_42__repair_milestone.mdwn     |   35 +
 doc/devblog/day_430__tor_socket_problem.mdwn  |   13 +
 doc/devblog/day_431__p2p_linking.mdwn         |   27 +
 ..._1d5f809564c25e765f82594af8e174ab._comment |   49 +
 doc/devblog/day_432-433__almost_there.mdwn    |   13 +
 doc/devblog/day_434__it_works.mdwn            |   27 +
 doc/devblog/day_435-436_post_tor_merge.mdwn   |   20 +
 doc/devblog/day_437__catching_up.mdwn         |   20 +
 .../day_438__bi-directional_p2p_links.mdwn    |    6 +
 doc/devblog/day_439__wormhole_pairing.mdwn    |   51 +
 doc/devblog/day_43__bugfix_day.mdwn           |   26 +
 doc/devblog/day_440__holidaze.mdwn            |   11 +
 .../day_441__webapp_wormhole_pairing.mdwn     |   18 +
 doc/devblog/day_442__xmpp_removal.mdwn        |   15 +
 ..._22ff11b84f855ab5e6de6dcf2553a050._comment |   35 +
 ..._eaf64ce3daae790bb27d21887886d73b._comment |   18 +
 .../day_443__yes_it_has_been_a_while.mdwn     |   30 +
 .../day_444__memory_leak_with_a_cold.mdwn     |   21 +
 doc/devblog/day_445__configs.mdwn             |   11 +
 doc/devblog/day_446__quiet_progress.mdwn      |   14 +
 doc/devblog/day_447__bug_class.mdwn           |   48 +
 .../day_448__git_push_to_update_remote.mdwn   |   24 +
 doc/devblog/day_449__SHA1_break_day.mdwn      |   21 +
 ..._44__automatic_removable_drive_repair.mdwn |   16 +
 ...ay_450__hardening_against_SHA_attacks.mdwn |   13 +
 .../day_451__annex.securehashesonly.mdwn      |   16 +
 doc/devblog/day_452__GIT_SSH.mdwn             |   17 +
 doc/devblog/day_453_release_prep.mdwn         |   13 +
 doc/devblog/day_454__multicast.mdwn           |   15 +
 ..._137ea34cd11004513a03f24955719756._comment |   38 +
 ..._09908606fc362cbee516999cd696f718._comment |   19 +
 doc/devblog/day_455__semi-synchronized.mdwn   |    9 +
 doc/devblog/day_456__digging_in.mdwn          |   16 +
 ..._457__improved_ssh_password_prompting.mdwn |   17 +
 doc/devblog/day_458__adeiu_MissingH.mdwn      |   18 +
 doc/devblog/day_459__git_bug.mdwn             |   29 +
 doc/devblog/day_45__command_line.mdwn         |    9 +
 doc/devblog/day_460__move_--to_here.mdwn      |    3 +
 doc/devblog/day_461__shell_completions.mdwn   |    8 +
 ...he_feature_youve_all_been_waiting_for.mdwn |   12 +
 ..._6b13defcdf76691049b9bcd7ec675da6._comment |    9 +
 ...__back_buggy_external_special_remotes.mdwn |   30 +
 doc/devblog/day_466__export_prototype.mdwn    |    6 +
 doc/devblog/day_467__export_progress.mdwn     |   11 +
 doc/devblog/day_467__firming_up_export.mdwn   |   27 +
 ..._382fac60766340481acbcb8c05b70f42._comment |    8 +
 doc/devblog/day_468__export_renames.mdwn      |   23 +
 ..._4c37e6f9ac1e1571495b0d355c8af9ff._comment |   11 +
 ..._7fbbc5beb80acf32eff617ec704d5466._comment |   26 +
 doc/devblog/day_469__export_merged.mdwn       |    8 +
 .../day_46__wrapping_up_the_month.mdwn        |   18 +
 .../day_470__export_to_external_and_S3.mdwn   |   12 +
 .../day_471__export_to_more_remotes.mdwn      |   13 +
 .../day_472__removing_empty_directories.mdwn  |   20 +
 .../day_473__distributed_use_of_exports.mdwn  |   17 +
 doc/devblog/day_474__tracking_exports.mdwn    |   26 +
 doc/devblog/day_475__assistant_exports.mdwn   |    4 +
 doc/devblog/day_476__third_time_lucky.mdwn    |   29 +
 doc/devblog/day_477__windows_build_fixed.mdwn |   10 +
 .../day_478__windows_the_blackhole.mdwn       |   14 +
 .../day_47__fell_off_the_blogging_wagon.mdwn  |    3 +
 .../day_482__website_login_problem.mdwn       |   31 +
 ...3__faster_start_with_removable_drives.mdwn |   27 +
 ...4__special_remote_protocol_extensions.mdwn |   12 +
 doc/devblog/day_485__slow_and_steady.mdwn     |    9 +
 doc/devblog/day_486__time_to_ditch_rsync.mdwn |   14 +
 .../day_487__git-annex-shell_p2pstdio.mdwn    |   38 +
 ...ay_488__groundwork_for_using_p2pstdio.mdwn |   30 +
 doc/devblog/day_489__zooming.mdwn             |   31 +
 ..._d840f371f1d22b0ee8f3c8df25ebe3d3._comment |   12 +
 ..._ec579c84aeb244798a818a20ff0f50b5._comment |   11 +
 .../day_48__direct_mode_guard_design.mdwn     |   29 +
 ..._ec0147ccc55bad3a38652383f4098a65._comment |    8 +
 doc/devblog/day_490__kind_of_annoying.mdwn    |   28 +
 doc/devblog/day_491__annex.verify_redux.mdwn  |   19 +
 doc/devblog/day_492__concurrency_is_hard.mdwn |   12 +
 .../day_493__two_new_special_remotes.mdwn     |   18 +
 .../day_494__url_download_changes.mdwn        |   25 +
 .../day_495__move_numcopies_safety.mdwn       |   20 +
 ..._496__move_numcopies_safety_revisited.mdwn |   12 +
 .../day_497__rethinking_the_android_port.mdwn |   24 +
 ..._cb30ab18753e5f221ed4d92b3ff8a32e._comment |   13 +
 .../day_498__unexpected_release_prep.mdwn     |   21 +
 doc/devblog/day_499__security_hole.mdwn       |   27 +
 ..._49__direct_mode_guard_implementation.mdwn |   14 +
 ..._3ebe5c3f708070f164ecaf36b79f7bfc._comment |    8 +
 .../day_4__unexpected_windows_day.mdwn        |   10 +
 .../day_500__security_hole_part_2.mdwn        |   26 +
 .../day_501__security_hole_part_3.mdwn        |   13 +
 .../day_502__security_hole_part_4.mdwn        |   24 +
 .../day_503__security_hole_part_5.mdwn        |   19 +
 .../day_504__security_hole_part_6.mdwn        |   12 +
 .../day_505__security_fix_release.mdwn        |   15 +
 doc/devblog/day_506__summer_features.mdwn     |   38 +
 doc/devblog/day_507__v6_revisited.mdwn        |   23 +
 doc/devblog/day_508__git-protocol.mdwn        |   20 +
 doc/devblog/day_509__filterdriver.mdwn        |   16 +
 doc/devblog/day_50__grab_bag.mdwn             |   34 +
 ..._01846f6494fe843889391fd09fd127a0._comment |    8 +
 ..._12736014aa2c1af81e4b83072505e7d5._comment |    8 +
 doc/devblog/day_510__v6_get_drop_index.mdwn   |   14 +
 ..._0e2eff8c8c3aaef3499b8f94b2733148._comment |   16 +
 .../day_511__v6_improved_index_update.mdwn    |   13 +
 doc/devblog/day_512__fixed_race.mdwn          |    5 +
 ...ay_513__v6_reconciling_staged_changes.mdwn |   21 +
 doc/devblog/day_514__fixed_5_races_in_v6.mdwn |    9 +
 doc/devblog/day_514__v6_bug_review.mdwn       |   25 +
 ...ay_515__S3_exporttree_with_versioning.mdwn |   10 +
 ..._exporttree_with_versioning_continued.mdwn |   19 +
 .../day_517__return_to_crowdfunding.mdwn      |    9 +
 ..._518__S3_versioning_finishing_touches.mdwn |   39 +
 ..._aed297f65b6e555f338fc622a8678c0f._comment |  121 +
 ..._a981371786ba702ac616cd55b296bc1c._comment |   39 +
 ..._08de1605f1aa8b042ba3c4b710939989._comment |    8 +
 doc/devblog/day_519__release_prep.mdwn        |   10 +
 .../day_51__direct_mode_guard_finished.mdwn   |    6 +
 .../day_520__storm_before_the_calm.mdwn       |   10 +
 .../day_521__newlines_in_filenames.mdwn       |   21 +
 doc/devblog/day_522__multi.mdwn               |    7 +
 doc/devblog/day_523__backlog.mdwn             |   13 +
 doc/devblog/day_524__new_phone.mdwn           |   17 +
 doc/devblog/day_52__slowly_but_surely.mdwn    |    5 +
 doc/devblog/day_545__termux_improvements.mdwn |   13 +
 ...46__deleted_40_thousand_lines_of_code.mdwn |   14 +
 doc/devblog/day_547__v6_almost_complete.mdwn  |   12 +
 .../day_548__hiding_missing_files.mdwn        |   18 +
 .../day_549__operating_on_hidden_files.mdwn   |   52 +
 ..._29ded4a0926cca6f2485efc07c039b62._comment |    9 +
 .../day_54__android_bisection_minions.mdwn    |    9 +
 ..._bea8fbe2b87d4a4865b92fa796298fa0._comment |    8 +
 doc/devblog/day_550__a_plan_to_finish_v6.mdwn |   12 +
 ..._4a839c274832e43664d665e90b93146c._comment |   13 +
 ..._bae3f3303d61126a337f2dac71681e1d._comment |   16 +
 doc/devblog/day_551__v6_or_v7.mdwn            |   19 +
 ..._a46bd8dcc560a681405f82f13fc2e87e._comment |    8 +
 ..._555009f3455129946b0238bc7e3bc52e._comment |    8 +
 ..._0fa5ed098fa850fee538034f4787f35e._comment |    8 +
 doc/devblog/day_552_523__v7_release_prep.mdwn |   34 +
 ..._31c6692172dbc1217d0a7ab90c074823._comment |   12 +
 .../day_554__git-annex_user_survey_draft.mdwn |    7 +
 .../day_555__git_annex_user_survey_live.mdwn  |    7 +
 doc/devblog/day_556__snow_day.mdwn            |    6 +
 doc/devblog/day_557__upgrade_bugfixes.mdwn    |   10 +
 doc/devblog/day_558__new_horizons.mdwn        |   15 +
 doc/devblog/day_559__surprising_win.mdwn      |    9 +
 doc/devblog/day_55__fireside_porting.mdwn     |   22 +
 ..._d690a52db82f9594d99ae65fe51e1f1a._comment |    8 +
 doc/devblog/day_560__into_the_weeds.mdwn      |   14 +
 doc/devblog/day_561__better_benchmarking.mdwn |   17 +
 doc/devblog/day_562__on_to_metadata.mdwn      |   14 +
 doc/devblog/day_563-564__log_conversion.mdwn  |   15 +
 doc/devblog/day_565__bytestring_Key.mdwn      |   15 +
 doc/devblog/day_566__stopping_place.mdwn      |   26 +
 .../day_567__neither_rain_nor_snow.mdwn       |   16 +
 doc/devblog/day_568__release_day.mdwn         |   11 +
 ...day_569__another_week_another_release.mdwn |   11 +
 .../day_56__git-annex_user_survey.mdwn        |   20 +
 doc/devblog/day_570__brrr.mdwn                |   20 +
 doc/devblog/day_571__survey_results.mdwn      |  173 +
 .../day_572__thinking_please_wait.mdwn        |   17 +
 ...__starting_import_tree_implementation.mdwn |   12 +
 doc/devblog/day_574__weeds.mdwn               |   19 +
 .../day_575__core_of_import_tree_done.mdwn    |    9 +
 doc/devblog/day_576__import_export.mdwn       |   39 +
 doc/devblog/day_576__import_tree_details.mdwn |   11 +
 doc/devblog/day_576__import_tree_working.mdwn |   23 +
 ..._2ffd447e05466b806d36b761b4143e56._comment |    8 +
 ...how_am_I_still_working_on_import_tree.mdwn |    7 +
 doc/devblog/day_578__import_tree_merged.mdwn  |   28 +
 doc/devblog/day_579__bug_triage.mdwn          |    3 +
 doc/devblog/day_57__mavericks.mdwn            |   14 +
 doc/devblog/day_580__import_from_android.mdwn |   11 +
 .../day_581__starting_import_from_S3.mdwn     |   27 +
 .../day_582__versioned_S3_import_working.mdwn |    9 +
 ...3__S3_import_and_export_fully_working.mdwn |   17 +
 .../day_584__matching_S3_histories.mdwn       |   16 +
 .../day_585__not_matching_S3_histories.mdwn   |   16 +
 .../day_586__wrapping_up_S3_import.mdwn       |   18 +
 .../s3history.png                             |  Bin 0 -> 16015 bytes
 .../s3rename.png                              |  Bin 0 -> 10321 bytes
 .../day_587__import_preferred_content.mdwn    |   20 +
 .../day_588__export_preferred_content.mdwn    |    8 +
 ...ng_up_import_export_preferred_content.mdwn |    7 +
 doc/devblog/day_58__urgle.mdwn                |   16 +
 ..._bd279f58f614b103a53215dfb0211007._comment |   12 +
 ..._590__toward_importing_from_externals.mdwn |   11 +
 .../day_591__superscalar_pipelining.mdwn      |   17 +
 .../day_592__refactoring_start_messages.mdwn  |    4 +
 doc/devblog/day_593__partial_success.mdwn     |   12 +
 ...ally_background_checksum_verification.mdwn |   14 +
 ..._334c36d503abd06611a46cc102139446._comment |    8 +
 .../day_595__cleaner_worker_pool_stages.mdwn  |   23 +
 .../day_596__back_from_summer_vacation.mdwn   |   17 +
 doc/devblog/day_597__git-lfs_support.mdwn     |   16 +
 .../day_598__Windows_and_test_suite.mdwn      |   21 +
 .../day_599__dropping_direct_mode.mdwn        |   11 +
 doc/devblog/day_59__release_day.mdwn          |   11 +
 .../day_5__gcrypt_special_remote_part_1.mdwn  |    7 +
 doc/devblog/day_600__close_to_v7_default.mdwn |    5 +
 doc/devblog/day_601__v7_default.mdwn          |   17 +
 ..._54af3bf0a521597d49bd8f8ef0ab5555._comment |   17 +
 ..._c2daec80c7834ebb62324d7169c6c158._comment |   16 +
 doc/devblog/day_602__sameas.mdwn              |    9 +
 doc/devblog/day_603__sameas_working.mdwn      |    4 +
 doc/devblog/day_604__unscheduled_release.mdwn |    5 +
 .../day_605__well_Im_done_for_now.mdwn        |    2 +
 ..._7366f7108495129680301d9b93bb8fb6._comment |    8 +
 ..._cd42103ea06ede8352176e66fc5434c5._comment |    8 +
 ..._774f264c555965461d621587cbdf8a1e._comment |    9 +
 doc/devblog/day_606__on_recent_events.mdwn    |    5 +
 doc/devblog/day_607__v8_is_done.mdwn          |   40 +
 ..._7326382d8ff23873c2fe0d6acd984454._comment |   10 +
 ..._802311f91808a13473aa99578a429497._comment |   12 +
 ..._7d3cad862be54dc5a39059f8b82834a6._comment |    8 +
 .../day_608__easier_git-lfs_setup.mdwn        |   25 +
 ..._b72bea21d4445d12cade9f54ecc3767d._comment |   18 +
 doc/devblog/day_609__optimisation.mdwn        |   11 +
 .../day_60__damage_driven_development.mdwn    |   36 +
 ...1__ByteString_optimisation_early_days.mdwn |   12 +
 ..._1601268fd4dba4df9cc3dc84932914a6._comment |   12 +
 ..._21872150f9b2ff9cc08f94d52dbdf3a6._comment |   10 +
 doc/devblog/day_612__building_again.mdwn      |   11 +
 ..._613__end-to-end_ByteString_milestone.mdwn |   17 +
 .../day_614__bytestring_wrapping_up.mdwn      |   15 +
 doc/devblog/day_615__new_year.mdwn            |   21 +
 .../day_616__remote_config_parsing.mdwn       |    9 +
 ..._617__remote_config_parsing_continued.mdwn |   20 +
 ..._d3ab2e85ea775cc6f39f12210374c35f._comment |    8 +
 doc/devblog/day_618__v8_merged.mdwn           |    5 +
 ...__important_bugfix_release_and_v8_too.mdwn |   14 +
 ...day_61__damage_driven_development__II.mdwn |   15 +
 doc/devblog/day_620__emergency_mode.mdwn      |   20 +
 doc/devblog/day_621__back_to_normal-ish.mdwn  |   14 +
 doc/devblog/day_622__behavior_changes.mdwn    |   28 +
 doc/devblog/day_623__started_timeouts.mdwn    |   17 +
 doc/devblog/day_624__timeouts_snag.mdwn       |   13 +
 .../day_625__import_tree_largefiles.mdwn      |   13 +
 doc/devblog/day_626__performance_week.mdwn    |   18 +
 ...ay_627__last_performance_work_for_now.mdwn |   16 +
 .../day_628__external_key_backends.mdwn       |   10 +
 ..._e6ff184245dd1a6cffff2ecdaeff6a66._comment |   11 +
 ...y_629__async_external_special_remotes.mdwn |   25 +
 doc/devblog/day_62__upgrade_alerts.mdwn       |   22 +
 ..._cdb44aaa1d2a784a72613cbf16038f89._comment |    8 +
 ..._b08bb946e4760d7f03b45c852c745b2e._comment |    8 +
 .../day_630__dealing_with_git_changes.mdwn    |   42 +
 .../day_630__introspection_for_speed.mdwn     |   11 +
 doc/devblog/day_631-632__memory_leak.mdwn     |   16 +
 doc/devblog/day_633__ten_years.mdwn           |   12 +
 ..._4842e53398d9ee668053ec6d4da426dd._comment |    9 +
 ..._48b09fc7e66cd9d9fb7c0f78f21c7ac5._comment |    8 +
 doc/devblog/day_634__new_features.mdwn        |   59 +
 doc/devblog/day_635__stall_detection.mdwn     |   19 +
 doc/devblog/day_636__stall_stall.mdwn         |   11 +
 doc/devblog/day_637__thirdparty_of_borg.mdwn  |   17 +
 .../day_638__borg_special_remote_working.mdwn |   26 +
 ...ay_639__major_keys_database_milestone.mdwn |   15 +
 doc/devblog/day_63__leverage.mdwn             |   24 +
 ...ay_640__finally_dealt_with_clock_skew.mdwn |   20 +
 ...day_641__an_alternative_smudge_filter.mdwn |   26 +
 ..._ab7bbff67f34e217df5f0e75dedb7f2c._comment |    8 +
 ..._9bc08810306ceb39ed1f017e9f1d81e3._comment |   10 +
 ..._b9ffc711b4531b6f2b4af4efd1e9d9d6._comment |   12 +
 ..._b2a0a8f646197ce1826bc2e6859139b1._comment |   11 +
 ..._6a5932706a9fee097c3fdf2cd6808f1d._comment |   20 +
 ..._ad1d78a28887af24d77b2b9e3739b68a._comment |   11 +
 ..._3107429d7250a71584ea7947609207ec._comment |   12 +
 ..._45f97189936e7f477850aef9ef745538._comment |    8 +
 ..._3129a6da37ba7a1f8ee11441b7ed4d07._comment |    8 +
 doc/devblog/day_642__cost_model.mdwn          |   28 +
 ..._36ecaafc1d7f6460758d6824a357432c._comment |   33 +
 ..._5bb7a20dd3141423ce4109d8fd4098c4._comment |   14 +
 .../day_643__adjusted_view_branches.mdwn      |   38 +
 ..._5f2dfde34d4ef5048920f3fcabddbd56._comment |   17 +
 ..._51e285666d42e08edbaf22699782392e._comment |    8 +
 ...ay_644-648__terminal_escape_sequences.mdwn |   46 +
 ...649-650__speeding_up_repeated_imports.mdwn |   30 +
 doc/devblog/day_64__overkill.mdwn             |   31 +
 ..._e1db7678aae37af281d31ae211677786._comment |   10 +
 ..._f7a96f0b6d942d0b59d9d0ec1b21c4bf._comment |    8 +
 ...51__a_major_release__and_a_conference.mdwn |   17 +
 doc/devblog/day_65__wrapping_up_upgrades.mdwn |    5 +
 doc/devblog/day_66__upgrade_testing.mdwn      |   17 +
 doc/devblog/day_67_thanksgiving_rush.mdwn     |   19 +
 doc/devblog/day_68__bits_and_pieces.mdwn      |   14 +
 doc/devblog/day_69__catching_up.mdwn          |   14 +
 doc/devblog/day_6__gcrypt_fully_working.mdwn  |    8 +
 ..._136bb7537a9ba93d400ce6f6ea1932ac._comment |    8 +
 ..._1f8faa65bbd56a12588b43a5bc822d96._comment |   10 +
 ..._70__preliminary_user_survey_analysis.mdwn |  104 +
 doc/devblog/day_71__that_was_unexpected.mdwn  |   30 +
 doc/devblog/day_72__windows_webapp_not.mdwn   |   22 +
 doc/devblog/day_73__EvilLinker.mdwn           |   28 +
 doc/devblog/day_74__so_close.mdwn             |   20 +
 ..._b1aa185734c3d74830b81def4fe63bff._comment |   10 +
 doc/devblog/day_75__hallelujah.mdwn           |    8 +
 ..._df04c456e99d47743494a18c1badba8c._comment |    8 +
 doc/devblog/day_76__results.mdwn              |   15 +
 doc/devblog/day_77__it_builds.mdwn            |    8 +
 doc/devblog/day_78__desidetracked.mdwn        |   34 +
 doc/devblog/day_79__catch_up.mdwn             |    3 +
 doc/devblog/day_7__release_day.mdwn           |   10 +
 ..._12bb94d903868ecddb3e348c9c4afeaf._comment |    8 +
 ..._d3e38d6f6bba179dab40d4d75ff061de._comment |    8 +
 doc/devblog/day_80__plumbing.mdwn             |    9 +
 doc/devblog/day_81__more_standalone.mdwn      |   15 +
 ..._25ceb116406b55a8ff28f7b392806bc9._comment |   10 +
 doc/devblog/day_82__rpi_and_synology.mdwn     |   21 +
 ..._d154ddcf22027fd06acf9da73e12c006._comment |    8 +
 doc/devblog/day_83__armel_webapp.mdwn         |   19 +
 doc/devblog/day_84__ho_uh_oh.mdwn             |   11 +
 ...xternal_special_remote_protocol_types.mdwn |   25 +
 ...xternal_special_remote_implementation.mdwn |   11 +
 ..._5116bcf4b60030cb46683df94a75d7ee._comment |    8 +
 ..._7b6e734f785fbd9db7883b63150023dc._comment |    8 +
 ...day_87__external_special_remotes_done.mdwn |   16 +
 doc/devblog/day_88__lazy_sunday.mdwn          |   15 +
 doc/devblog/day_89__reflections.mdwn          |   18 +
 doc/devblog/day_8__ill.mdwn                   |   20 +
 doc/devblog/day_90__slow_start.mdwn           |   23 +
 doc/devblog/day_91__wintry_mix.mdwn           |   11 +
 doc/devblog/day_92-93__reconnection.mdwn      |   34 +
 doc/devblog/day_94__leaks.mdwn                |   12 +
 .../day_95__reconnection_revisited.mdwn       |   13 +
 ..._c1106e573fcf9f3d4524c0e4f4254790._comment |    8 +
 ..._40478739f95e0b56ce0103db6e405ef4._comment |   10 +
 doc/devblog/day_96__catching_up.mdwn          |    7 +
 ...ay_97__exciting_telehash_possiblities.mdwn |   20 +
 ..._7c775d93cbeed0d553e224751d30fbaa._comment |   10 +
 doc/devblog/day_98__old_bug.mdwn              |   17 +
 doc/devblog/day_99__catching_up_again.mdwn    |   19 +
 ..._b871bf0606dc29be9b8c2e5dc150f708._comment |   10 +
 ..._c8363d47223e7bb899420e800bde3e27._comment |    8 +
 doc/devblog/day_9__Friday_the_13th.mdwn       |   21 +
 ..._07195b4ec399ba1be6c8bdb3ae0fa50b._comment |   12 +
 doc/devblog/day__126-127__merge_fixes.mdwn    |   61 +
 doc/devblog/day__228_new_AWS.mdwn             |   13 +
 doc/devblog/day__329-330__a_rising_tide.mdwn  |   15 +
 doc/devblog/moving_blogs.mdwn                 |    5 +
 ..._6caa7e67461a6ea5de8155ae9cf75fab._comment |    8 +
 ..._e3e2048fc2397b87a2f29c9fe49394cb._comment |   10 +
 doc/devblog/whither_XMPP.mdwn                 |   30 +
 doc/devblog/youtube-dl.mdwn                   |   30 +
 ..._ff062ea66ea50d2f31a92c25017bb135._comment |   10 +
 doc/devblog/youtube-dl_day_2.mdwn             |   13 +
 doc/devblog/youtube-dl_day_3.mdwn             |    7 +
 ..._bcf6ccc65f191c446ae4ea70c4e86c87._comment |   27 +
 ..._423d1896981b9d5de85c89fdcde2d1ab._comment |   18 +
 ..._c3735d169bfe81eaba5557197b1c0eb0._comment |    9 +
 ..._d19a698b28a5d6b583c527b9a909370d._comment |   12 +
 doc/direct_mode.mdwn                          |   14 +
 ..._1c79c93f4b17cfc354ab920e3775cc60._comment |   26 +
 ..._1b5218fdb6ee362d6df68ff1229590d4._comment |   10 +
 ..._7d507b6f87085a19d8dd5014f580922b._comment |   24 +
 ..._5169c5541970d3b3bc1e080e07539b22._comment |    8 +
 ..._55108ac736ea450df89332ba5de4a208._comment |   12 +
 ..._03a02e689d92faa596de98e02b2ffe28._comment |   10 +
 ..._ff4ffc2aabc5fd174d7386ef13860f78._comment |   10 +
 ..._1cd32456630b25d5aaa6d2763e6eb384._comment |    8 +
 ..._599b2285d24ae1244a1945d572b2c397._comment |    8 +
 ..._7f6805e090d0acd8a077b65214da5837._comment |    7 +
 ..._e7c066fba8e28c61e8517c7a18a02457._comment |    7 +
 ..._e46f70efa6d8d65d5ef81cdcbd844869._comment |   13 +
 ..._f4f23d9be76fa3c201b6c67efab0d69c._comment |    8 +
 ..._4d0077d7881df05dcbeb460bf7734b6b._comment |   11 +
 ..._8020d74bddf0e38b0a297e5dae7c217b._comment |   12 +
 ..._97c26bd82f623a3b2d56bab4afff0126._comment |   12 +
 ..._42363bf0367f935b3eee8ad3d2eaf5cf._comment |   10 +
 ..._5f03b1686c1fb3f7606a5bc724ac3812._comment |    8 +
 ..._5355ac418bfb26e990762b80f4c36b77._comment |   12 +
 ..._6cd15e2c5fd0bef48f60c6993322c2fc._comment |    9 +
 doc/distributed_version_control.mdwn          |   21 +
 doc/download.mdwn                             |   30 +
 ..._ec2578241a966cfcdd43f2a26a5c8709._comment |   13 +
 ..._ee0d158ac59903737dbc4ef632f11fe3._comment |    7 +
 ..._b59fc32a18a9fda8da120da82fade0a6._comment |    9 +
 ..._bf102d87552f97ac293dd20f6822b84f._comment |   11 +
 doc/encryption.mdwn                           |  157 +
 ..._6416ee43ffad1c306ef71247ae71a6c5._comment |   17 +
 ..._30b926fbabe9a0089de1f55f6f9a5d2d._comment |   15 +
 ..._51fd19bf174906b1dd1461efd6ce3798._comment |    9 +
 ..._44c6a401526a6ee22d5f0316336d453b._comment |   10 +
 ..._5832365e198284c93d4a505856932841._comment |    9 +
 ..._fb6ec1f42789a62358605e293b678318._comment |    8 +
 ..._5dc76b832ae6b1bb7f458bf8e2650e8e._comment |   12 +
 ..._a2195a298f65e427fe8460c8bc380f99._comment |    8 +
 ..._4257e3c4ae559f1c0595a903f738fd7e._comment |   28 +
 ..._5c2da865082de475254ebfd53feb2d0a._comment |   13 +
 ..._46e64e4856975706e06e2a012a5d8f67._comment |    8 +
 ..._fe8b181adef9a39a039ff96a0d587188._comment |   11 +
 ..._5c9897663aaa83ca39a7e8cb292a3fd1._comment |   10 +
 ..._1756ce62906586f876a3491e5d9befde._comment |   13 +
 ..._3849eb24c3682644e263bae107747dee._comment |   20 +
 ..._66e81e89fd483ca95620522b0f63c4fd._comment |   11 +
 ..._5ca10891d642392aaff342c1478b0550._comment |   10 +
 doc/favicon.ico                               |  Bin 0 -> 2550 bytes
 doc/footer/column_a.mdwn                      |    7 +
 doc/footer/column_b.mdwn                      |    7 +
 doc/forum.mdwn                                |    9 +
 .../--verbose_not_really_verbose__63__.mdwn   |    7 +
 ..._9a7927c22a50addafc58028f34c48578._comment |    8 +
 ..._0c846317803019058f6b522bc9abd5a6._comment |   28 +
 ..._a360190fee9a9514f0ba201baeaecd7a._comment |   17 +
 ..._e4d75464af5ced1ce1f9539ddf8755f4._comment |   15 +
 ...d_server_for_syncing_-_possible__63__.mdwn |    3 +
 ..._924521ad5972046bac44d2e04ec296c7._comment |   10 +
 ..._e2a7f34a3ccc1b6467e6da611c067d66._comment |    8 +
 ..._f9a369a6ac69f091e6128990274d3228._comment |   10 +
 ..._91b422f8d55b68077245c606c4f7f87c._comment |   28 +
 ..._f6128fe75ff3453747f69f12e0fd0a5b._comment |   12 +
 ..._9b90b4031a5ed26c375903b33ed65a10._comment |   17 +
 ..._acd64ce1b08a97ddf730622272e9f611._comment |   14 +
 ..._9baacb14fc5eb449cb13e0b4a4995fb0._comment |    8 +
 ...c_on_new_remote___40__USB_drive__41__.mdwn |   92 +
 ..._01a6020d25826a3e0afb087899f6919c._comment |   14 +
 doc/forum/ARM_build_on_Zyxel_NAS.mdwn         |   15 +
 ..._38f38755c0afd76a2b968836fec395e8._comment |   11 +
 ..._44c8f1af0cbe9ad51794e6d8d16be627._comment |    9 +
 ..._b4f6e5ac672e8ece36cceb74ff3315dd._comment |    8 +
 doc/forum/A_git-annex_helper.mdwn             |    6 +
 ...lp_with_headless_server_configuration.mdwn |    2 +
 ..._d32e28e8dcacf89eb357b78aefded274._comment |   22 +
 ...s_to_delete__44___files_to_keep__63__.mdwn |   12 +
 ..._fe291cd6cd8e2d5b8e23f8e3689d824b._comment |   15 +
 ..._f0dbc3c723999bf0f22502e3a89d1d4a._comment |    8 +
 doc/forum/A_really_stupid_question.mdwn       |    3 +
 ..._40e02556de0b00b94f245a0196b5a89f._comment |   31 +
 doc/forum/A_tiny_filesystem__63__.mdwn        |    7 +
 ..._993e3f5dbe4bcbb5b7bd9e08ab9554f3._comment |    8 +
 ..._af57591d42868c8aa1cc1eda43ca8b98._comment |    8 +
 ..._3869c0472b50d7cf5e29ac0720f4f20f._comment |   10 +
 ...ssing_files_directly_on__a_USB_device.mdwn |   11 +
 ...n_SSH_remotes_while_SSHed_into_remote.mdwn |    1 +
 ..._b2f7b4aa5e7c859de9741db440292365._comment |   10 +
 ..._6450ee0b5729beec155fbe0ce304e223._comment |    9 +
 ..._9d8d03bda09596d03d9cfb7138a152f0._comment |    9 +
 ..._650ebbe4e7b57361a42882f3092122f0._comment |   15 +
 .../Accessing_files_in_bare_repository.mdwn   |    5 +
 ..._7eb66e3806f9524e043fae2da9d57d64._comment |   10 +
 ..._f0165d66865ad14f7eb5d50e900c1df4._comment |   10 +
 ..._0e7ea5161b6da6e9bb9425bdb953de33._comment |    8 +
 ..._f804b9bf71f7d04bd23ce32d813dc340._comment |    8 +
 ..._6de649d38febd2240eb5b703da77c2d6._comment |   15 +
 ..._7e8dd09915ddc3267377e900891cb02c._comment |   24 +
 ..._80eae4a73f38d1a7e35f97c33b6401f8._comment |    8 +
 ..._5ec13e98d3ecb69426e974d34f712f9b._comment |    8 +
 ..._dccbf5793998c6381e23eb8ff6497ebf._comment |   17 +
 ..._42d923916232c81f3b8bdbefa34a89d3._comment |   18 +
 ..._43a0a7d222faee582aeb3150a59cef87._comment |    8 +
 ..._ec1024235c1c74c113483a833df84654._comment |   12 +
 ..._c156b8c1ae0f2905566bbdb13b84e577._comment |   37 +
 ...__and_crippled__41___annex_repository.mdwn |   28 +
 ...ect_mode_sync_should_avoid_git_commit.mdwn |    1 +
 ..._06dae5709750ea1da4f7fdbee4e84efc._comment |   16 +
 ..._2069c5c41882ae0a1973fb7da583b60e._comment |   10 +
 ..._b35e3a87c30974eedd71ebe52ecbed96._comment |    8 +
 ..._84e026f9bda87bfd12a3769dcef77f8b._comment |    8 +
 ..._b2ac2ea300a5026832b40a1a6b27a7cd._comment |    8 +
 ..._ed3534196164c6736a8dbf21c65c119d._comment |   10 +
 ..._1e29bcf568f02765c48f0eac6c640673._comment |   45 +
 ..._9ea6803a94b1de15079a3fa20d59c9af._comment |   10 +
 ..._3fae5a7fa5d99d0eb4473adb43e7f6f5._comment |    8 +
 ..._57a5b73cff480266355e75c7bdc762c2._comment |    8 +
 ..._bbcf5e863c8f152e1079536e9011a404._comment |   16 +
 ..._fdcd144c22601bdf98ff844254b0120d._comment |    8 +
 ..._b77243e765b2af7ba71e963fcb5cbbb1._comment |   71 +
 ..._cb0815e96ee211d4778f2e7a4274e855._comment |    8 +
 doc/forum/Add_a___34__local__34___remote.mdwn |   13 +
 ..._c68ad724b465c4be5243be687168c0b3._comment |   12 +
 ...nnex_files_outside_git_root_directory.mdwn |   24 +
 ..._3d7c8917633a6632f22385b8f7a98ccf._comment |   18 +
 ..._312a57883d809857a69216fa47e04f17._comment |   15 +
 ...ile_to_git_index_while_in_direct_mode.mdwn |   20 +
 ..._3eb43a983eba09f500b776f75b299341._comment |    8 +
 ..._6945d9e930e7385f0abe6538622a9aa3._comment |   31 +
 ..._8f77b5dcf582e88099b2e6e77563fb11._comment |   10 +
 doc/forum/Add_files_to_direct_mode_repos.mdwn |    1 +
 ..._41d632853d3160899b04da7e4b95475e._comment |   11 +
 ...x_but_it_doesn__39__t_show_up_in_here.mdwn |   75 +
 ..._6757bfdc2876b5b763c338ad414e74dc._comment |   38 +
 .../Adding_a_URL_from_wayback_machine.mdwn    |   64 +
 ..._bc78c24becbf758da7873cdf01e2adc5._comment |    9 +
 ..._6df0501b103a7cfcd1eaa4120f7fa818._comment |   26 +
 ..._aefbb393c11ab233d145311409d405c7._comment |   31 +
 doc/forum/Adding_a_mounted_network.mdwn       |    1 +
 ..._9b4bab6177856569adfec26ada6b01cd._comment |   13 +
 ..._ae3d4ac918ef002ead859ed0c962ae32._comment |   14 +
 ..._559cfec9210f8c86de6ee13de0ec2175._comment |    7 +
 ...dding_existing_S3_bucket_to_sync_with.mdwn |   16 +
 ..._30b9a70d367dd5b8781e9a86e42d4c3e._comment |   10 +
 ..._a8525c1a7e5f89c30c9503fe8bfed02e._comment |    8 +
 ..._c3878989f74e740c0ed42f440750f3a4._comment |    8 +
 ..._c06cc86496f9d4c0c42a8c89aa5a7b35._comment |    8 +
 ..._0a1c2dd0929511ff824be8de2c8d85eb._comment |    9 +
 ..._1444c2f89885f028f20a4d3ce225a403._comment |   23 +
 ..._1c30944010d541096baff18198a5560d._comment |   23 +
 ...4__recording_state_in_git__34___phase.mdwn |   69 +
 ..._67d8488c421da24702fea4c37afe74c3._comment |    9 +
 ..._f9fb8b2ad05a17e8451d434c783fc7d7._comment |    8 +
 ..._71bbf490cfa2cbfab322aab865d93261._comment |    9 +
 ..._66dbcc3600c1df2df03896935dfce9c0._comment |   22 +
 ..._665bdcd79b486f8d2604eb6de5c10b2b._comment |   11 +
 ..._cf89b44d67752edabfbf577d1212e7ad._comment |   13 +
 ..._a4e2f0e65a9dc92fc4dd85183e8f8090._comment |   21 +
 ...g_files_with_wildcard_on_Mac_Yosemite.mdwn |   10 +
 ..._e0784676aab3388254cdc9e7dd2d97e7._comment |   11 +
 ..._d9a7d2669d1524cab71e7e3139631f2a._comment |   55 +
 ..._a0fdcd19954a38141b1dc2a51638ba30._comment |   24 +
 ..._bc36d8f7b1d4d475018a236f71d06bb5._comment |    8 +
 ..._a02c3cd804c2f6fd80d8839cc5c81af4._comment |   12 +
 ..._703ecd8e1dfc5b5b58655e27c9db838a._comment |    9 +
 ..._dbe40fef2ba65cc0f1c20f41f2daab4d._comment |   11 +
 ..._d8620ce7b3dbb81c0d3d0b09ded1deb0._comment |   18 +
 ..._6a43f52449c4a38a986772ec9d65f9d5._comment |    7 +
 ...0__non-annexed__41___files_in_Windows.mdwn |   31 +
 ..._e40e129fbdae305ad48f810c578fa69f._comment |    9 +
 ..._3f2556b0a0cd8b7523aed1bea1be8484._comment |   29 +
 ..._d50b99393009ba4adf2040f1d5d5078b._comment |   23 +
 ...34__remote_already_exists__34___error.mdwn |    5 +
 ..._fe2f0e7a4688865faf21c2c0467852b7._comment |    8 +
 ...ing_selected_big_binaries_recursively.mdwn |   12 +
 ..._6ff6031a5a44caf17f36c3569cca5512._comment |   23 +
 ..._872bef6902ddb362b62d5e9ec1afe864._comment |   26 +
 ..._4be5ca7a22db19a3152b54bee943f58c._comment |   19 +
 ..._83b62738f79c434f5a2cacc9316e5d2b._comment |    9 +
 ...me_content_under_different_file_names.mdwn |   17 +
 ..._7c659668f62577612eaf8f463383a185._comment |   16 +
 ..._217052fe47822f73ffc765afd6386a7e._comment |   21 +
 ..._58___git-annex_slows_down_my_macbook.mdwn |   21 +
 ..._af8ab0a47cd379fcb1445e50782ad086._comment |   12 +
 ..._a7202bcbdda36a3801833d2432db1965._comment |   25 +
 doc/forum/All_repos_on_same_filesystem.mdwn   |   14 +
 ..._a6666a89f62dc7e2d40e028782e5a25a._comment |   14 +
 .../Alternative_modes_for_annex_repos.mdwn    |   35 +
 ...ative_to_Tor_for_remote_pairing__63__.mdwn |    5 +
 ..._39417a8bd5e6834041d759ea3666d894._comment |   14 +
 .../Alternative_to_XMPP_on_Windows__63__.mdwn |    1 +
 ..._4084abf5b26fcc92e577eea34c331a15._comment |    8 +
 ...opy_which_is_as_fast_as_git_annex_get.mdwn |   15 +
 ..._7f62ed07749308a46f0028a9586a10a4._comment |   13 +
 ..._a0c58c65091f36b426e016c700ec2f1c._comment |    9 +
 ..._102047d2676af0bc62791fa0f18ac49f._comment |   25 +
 ..._717078ebeb3b69dd9c52c8abe457824a._comment |   16 +
 ..._0630abbcb27e1f9dc5e9269b09a99b09._comment |   13 +
 .../Always_sync_all_content_to_remote.mdwn    |    5 +
 ..._241c19cad6249fbd0832c76028c8b373._comment |   11 +
 ..._3eda671cea0f8869f1aac0194cae7146._comment |   34 +
 ...___40__unknown_revision_or_path__41__.mdwn |  148 +
 doc/forum/Ambiguous_repo_names__63__.mdwn     |    8 +
 ..._9695c42113ad6c873b1eae1c1f04e70a._comment |   13 +
 doc/forum/Android_-_ext3__47__4__47__....mdwn |    1 +
 doc/forum/Android__58___Cabal_hell.mdwn       |   32 +
 ..._34e869c1092f2885f54f627fb77a6057._comment |   13 +
 ..._ed5b2b37d37278458fdf2dc37539e741._comment |   10 +
 ..._fe71aa84ed5e1bb1e19a7d0f4e42eccd._comment |    9 +
 ..._da004cee7c0cf5617291dbd520af2e96._comment |   10 +
 ..._12e2cb09ac2ee07b392cd9be064a3cbe._comment |    8 +
 ...Android__58___Encrypted_Remotes__63__.mdwn |    3 +
 ..._6b16cd372a9bd4f99d4c8b09a82ce3ed._comment |   10 +
 ..._--content_not_run_in_all_repos__63__.mdwn |   24 +
 ..._aff6a984ab076433fbce32bacae6660e._comment |   13 +
 ..._5b1565955ed88554e5ef4a00c0f4a754._comment |    8 +
 ...t_high_cpu_usage_to_be_expected__63__.mdwn |    3 +
 ..._7880fc38792a1fcbf3e5c47e8bcaabce._comment |    8 +
 ..._840fbce18b4fdec21ee557fdf52c366e._comment |   10 +
 ...sitory_is_not_initialized_for_use_by_.mdwn |   22 +
 ..._ef3dbc83f24f00c49b7d7cf626af44aa._comment |   12 +
 ..._719abfa1dc9a64b1245376dedbccca6e._comment |   10 +
 ..._027130ce7e8a56551e1d16cbbae6d115._comment |   30 +
 ..._99d78dca3534c4d54f6925a095f1d43f._comment |   23 +
 ...ow_with_moderately_sized_repositories.mdwn |   67 +
 ..._c5c655ee3ec2501c1c3c60fd83574914._comment |    8 +
 .../Android___34__Bad_system_call__34__.mdwn  |   89 +
 ..._d53c57d0f42e3eb5efd6ff5d47b73698._comment |   94 +
 ..._74a33b262400ed74a7e0e3bbeac651d5._comment |   17 +
 ..._818a652075a2e283e0be57a11e10a14b._comment |    8 +
 doc/forum/Android_version_does_not_sync.mdwn  |   23 +
 ..._ed9e33eef2c6d651847dca9d3f7a63f6._comment |    8 +
 ..._4eafd3e989611f835c489b379bd6ec8a._comment |    8 +
 ..._2a4efec37015ea44509e7ed16b36a72d._comment |   13 +
 ..._1ad06842dd96be14e66cde67f32d50f8._comment |   26 +
 ...Annex_contents_just_disappeared__63__.mdwn |   12 +
 ..._4ab5ca00f912c0c95fabc10f2d9600d3._comment |   12 +
 ..._657f737c5d64d440aa133ddb41408fbc._comment |    8 +
 ..._9b4c35feb14b37d43d053d7430da9abf._comment |   12 +
 ..._c3625409652bff5f2165260803269a8a._comment |   10 +
 doc/forum/Annex_dropping_files.mdwn           |   12 +
 ..._62fbea95248fda2ff075b5a8952a728f._comment |    8 +
 doc/forum/Annex_keeps_dropping_content.mdwn   |    9 +
 ...nnex_slow_on_Windows__47__direct_mode.mdwn |   11 +
 ..._d80839f4582fc2a6269db31e30e1dbab._comment |    9 +
 ..._593e1e01b70a2b6a15ad6bca09a80c7b._comment |    8 +
 ..._c4e4c596f31aa97645fe1e1527dc2c31._comment |   12 +
 ..._92db0b99ada9af15a5383da41397ebd7._comment |   19 +
 ..._3d628c9db9ebdfd5bff92af105c47719._comment |   13 +
 ..._db7965fa928c093233769ed52b2fcd43._comment |   10 +
 ..._674f52c5e5484207db403b18efc986c6._comment |    8 +
 .../Annex_v7_repos_and_plain_git_files.mdwn   |   23 +
 ..._3bf39b5e6990d4343d9154465d951a77._comment |    8 +
 ..._a0628a013b57c00ea449b40b93edd385._comment |   15 +
 ..._6095eaa58aa298aca72237381f567ffb._comment |    8 +
 ..._fd1a3658ed6f3b6af2297c768b3f1ac2._comment |    8 +
 ..._f47fec91d4ceebe653bc3fb221e2f8df._comment |   17 +
 ..._21648eecfaf9673b25d40327d11f7b59._comment |    8 +
 ..._official__41___OpenBSD_support__63__.mdwn |   10 +
 ..._0d87a7d0f6ae556deb999403a2fb5461._comment |   13 +
 ..._c7fc9be88dad09f71774664b233bc8a3._comment |   11 +
 ..._89330ea5d2754d59766a096e0c35d791._comment |   19 +
 ..._4cfc6b550dfb24c8468df97428d2cf8a._comment |   10 +
 ..._82ce026c2dc9627ca2f1563caedfa458._comment |    8 +
 ..._dfca53829fbe845f7f56e35638faf9fc._comment |    8 +
 ...d___34__.git__34___to_git-annex__63__.mdwn |    9 +
 ..._51f4392e718d857e2f155d6217727a53._comment |   10 +
 ..._9698c4a8f0d8785ee89a6228e0e85ca9._comment |    8 +
 doc/forum/Apple_M1_Silicon.mdwn               |    1 +
 ..._5646c616f1897c797ce383f6d4210ce4._comment |   24 +
 ..._72129be313d82db95d4fe109793fc3fc._comment |    8 +
 ..._b62bcd53f260613fc9043008f0e9df19._comment |   14 +
 ..._c4ea06ee4c929f171eb6eaea0947bfe7._comment |   10 +
 ..._540e6d6f579174bb953824817f5822aa._comment |   10 +
 ..._e2aaf539d43951a20ea48d827082fe83._comment |    9 +
 ..._eeed553a1684f0b4ed07e5a7de62db5f._comment |    8 +
 ..._bed7d9e5565c6bb462e2ba8f4d815725._comment |   15 +
 ..._07c410bacefa5da582ce2064ef345def._comment |    8 +
 ..._2efc89b2c4f3ff408ccd015f297d743b._comment |    9 +
 ..._0fc6e261c00f1df8698c92c8de6f3a27._comment |   15 +
 ..._c60e046cb8b138aee16af2d4c66c803c._comment |   12 +
 ..._4620929361fb5ad8faea15ed3905d67f._comment |    8 +
 ..._d77519ba5ca217cb3ec6348567731b9d._comment |    9 +
 ...e_USB_drive_not_working_as_documented.mdwn |  171 +
 ..._59de1e101e5e427abb1df3a71c6f1b04._comment |   23 +
 ..._3541fdd31d398a494a8fa452ac2c277f._comment |   14 +
 ...ance_required_for_a_specific_workflow.mdwn |   19 +
 ..._7c803b6f2759f6fa74c514e79a26f369._comment |   10 +
 ..._4a00c4307a492ffe736cf981ced9f57a._comment |   39 +
 ...et_atomic__40__ish__41___states__63__.mdwn |   10 +
 ..._44c97c54066ca0487d8903cc01a356a3._comment |   10 +
 ..._98eb671596e84466e24004f55724660a._comment |    8 +
 ..._e3c506ae998a8ae681727d3c432f95d2._comment |   13 +
 doc/forum/Assistant_Droping_Files.mdwn        |    8 +
 .../Assistant__58___configure_auto-sync.mdwn  |   11 +
 ..._c8cabd38114582bbdbad49f2d81959d7._comment |   13 +
 ...omatically_use_only_available_remotes.mdwn |   18 +
 ...fails_to_authenticate_to_rsync_remote.mdwn |   17 +
 ..._fdbadd7ae4c0236301944136ac62346a._comment |   12 +
 ..._a395406abd3eb4cf07dc6467506a7e77._comment |    7 +
 ...dows_only_watches_one_repo_on_startup.mdwn |   19 +
 ..._48b43fe2ec186cea5930bf641522081d._comment |    8 +
 doc/forum/Assistant_invariants.mdwn           |   20 +
 ..._0426e10ffe45f42658d89756ea5ef5be._comment |   12 +
 ..._7d3990582435203e0f94a8a3a2f1ef5a._comment |   13 +
 .../Assistant_loosing_advantages__63__.mdwn   |   10 +
 ..._cdbc827d9e00aeeaefafe45de64b8d2c._comment |   10 +
 doc/forum/Assistant_not_syncing_to_Rsync.mdwn |   15 +
 ..._2178a7fc0d66643e84597b0938ef65f2._comment |   10 +
 ..._650651398443e128c2adc6a2a2d320d0._comment |   12 +
 ..._e6d0c9620b148acc72342862a8b4cfef._comment |   10 +
 ..._b91f9febdb8b69d8b487ba4ea08c119a._comment |   11 +
 ..._c5ad7c1546a17d8459c995c9c8c26414._comment |   31 +
 ..._4c12587f972eced91c5128d4885800b5._comment |   30 +
 ..._6ecaaee9316bcf0c65688676d60fc055._comment |    8 +
 ..._daa9a9a6188afa0394833e1b682f7cd4._comment |   10 +
 ...pair_fails_with_everincreasing_deltas.mdwn |   21 +
 ..._a8effe196e4a040630d183803768c5a1._comment |   10 +
 ..._9f032e43b132bcad656e1337ab2551ad._comment |   10 +
 ..._5a09f65c77dce3c62236c13aa90a1191._comment |   10 +
 doc/forum/Auto_archiving.mdwn                 |   17 +
 doc/forum/Auto_ignore_non-reachable_repo.mdwn |   15 +
 ..._40d7aab5e43c75ede3414ed48f0c7066._comment |    8 +
 ..._74c297d8d5e9f7d131c461ed5e803071._comment |   16 +
 doc/forum/Auto_sync_with_music_player.mdwn    |    1 +
 ..._81ad1c15cfd753531c01dae8945d1caf._comment |    8 +
 ..._a15e3f298c3d3faa5b3295355f9bb794._comment |   11 +
 ..._99f65a0efaf5d5f9b8ff530acc122860._comment |    8 +
 doc/forum/Auto_update_not_working.mdwn        |    6 +
 ...es_due_to_external_modification__63__.mdwn |   46 +
 ..._dab1099ee56541c194de319c593f1268._comment |    9 +
 ..._b5faccf132fb47e3cda778a6600fd9ef._comment |    8 +
 ...ic_commit_messages_for_git_annex_sync.mdwn |    1 +
 ..._ea2ec57bc695da4df8a30a35d433959d._comment |   15 +
 ..._af71f53dbbca35d5a5c66ff131887ada._comment |    8 +
 doc/forum/Automatically_dropping_files.mdwn   |    7 +
 ..._f5fc608f9cb0edf3272b586b62050637._comment |   12 +
 ...lly_syncronise_centralised_repository.mdwn |   14 +
 ..._6a2047daa9faf4309d2ed27d5cc48b76._comment |   10 +
 ..._3be7b45bc2284019f17a81375637a576._comment |   10 +
 doc/forum/Autostart_the_assistant.mdwn        |    9 +
 ..._a5421711102fb1649d98d916e5ced86b._comment |    7 +
 ..._df70bd0f5caab43503a3c9d805323289._comment |   35 +
 ..._42de896f64adb49c60ec3f7e0aeebda6._comment |   19 +
 ..._5c6e085b1077b0792a1805f032ac6a4b._comment |   11 +
 .../Back_up_videos_to_youtube__63__.mdwn      |   24 +
 ..._e81f72bfe678e2aceded518338be1473._comment |   13 +
 ..._6cb19f9c371d7cb046302ed193c77489._comment |   10 +
 ..._ccb5cb5fe520b3f2a4822d85c246296f._comment |    8 +
 ..._303b4f755dd117f8b22c98669e7bf932._comment |    8 +
 ...Backend_migration_and_special_remotes.mdwn |   22 +
 ..._cf6d45c43b14719fc5ea41d0cbfb612d._comment |   20 +
 doc/forum/Backing_up_photos_to_the_cloud.mdwn |   13 +
 doc/forum/Backup_of_git-annex_repos.mdwn      |   15 +
 ..._ed90e524606e394f7669fcba10846930._comment |   11 +
 doc/forum/Backup_of_whole_Linux_system.mdwn   |   16 +
 ..._bf48d93872bfadb5daaf02a10e699b79._comment |   10 +
 ..._af49edff9174c2ee17391e78ac97d5f3._comment |   11 +
 doc/forum/Balanced_Parity.mdwn                |   41 +
 ...repo_on_USB_drive_not_providing_files.mdwn |   17 +
 ..._0738174fb6984b777ec0a221502106ac._comment |   30 +
 ..._1e07d1a9ddb88c0e1d84d8d88b7b4cc4._comment |   10 +
 ..._65d007284287e709a8f6f07dd8630f15._comment |   12 +
 ..._3bbce5d12ece481b669be10ef9a70f40._comment |   28 +
 ..._5e6202c319e75a9758bb8c2f32152e0f._comment |   16 +
 doc/forum/Basic_set_up_with_one_remote.mdwn   |   14 +
 ..._3ad06a0dbebf62e6440f549e77af59b6._comment |   15 +
 ..._59e18e759c907b8adabf8c34eef08065._comment |   10 +
 ..._5221a713ee3f65fa2740c9fa6cb1db0f._comment |   27 +
 ..._62e554a546e4b50d211f5f65446fd289._comment |   13 +
 ...rocess__44___git_rm__44___and_locking.mdwn |    7 +
 ..._6cb866b48f6426e7ecc4f8d6af5b710d._comment |   16 +
 ..._51667179ddb52ca5fa1166196c5d37e2._comment |    8 +
 ..._593879cc70e9a07a49fa663677f5c045._comment |   22 +
 ...__w_access_on_shared_git-annex_server.mdwn |   13 +
 ..._871b5a42f1134a059df520993bb55268._comment |   11 +
 ..._68d675096d9ea32780b8ec8526544b12._comment |    7 +
 doc/forum/Behaviour_of_fsck.mdwn              |   13 +
 ..._0e40f158b3f4ccdcaab1408d858b68b8._comment |    8 +
 ..._ead36a23c3e6efa1c41e4555f93e014e._comment |   19 +
 ..._97848f9a3db89c0427cfb671ba13300e._comment |   19 +
 ..._e4911dc6793f98fb81151daacbe49968._comment |    8 +
 ..._unlocked_file_mode_V6_vs_locked_mode.mdwn |    4 +
 ..._fef0122752291bdc583fdcfdd400d250._comment |   10 +
 ...or_central_sharing_and_multiple_users.mdwn |    8 +
 ..._48ffb50b92588daec6887bf08f1b97f5._comment |   10 +
 ..._6b9a20f9707da9d2cfc3697a538d6935._comment |   12 +
 ...for_dropable_compression_+_encryption.mdwn |   15 +
 ..._1d55eb39e46eee8c5dd6e142e71289ad._comment |    9 +
 ..._704eed4d3607ebbfc9c6f5c64e7a1507._comment |    8 +
 ...ect_names__41___in_absence_of_git_log.mdwn |   18 +
 ..._a1827481a3ac140d58a4184121328d87._comment |   15 +
 ...manage_files_on_removable_media__63__.mdwn |   18 +
 ..._direct_and_crippled_annex_repository.mdwn |   17 +
 ..._552e74f9573a34ec178f396b83252c3e._comment |   12 +
 ..._33c57922714f204fc63c260b838f3712._comment |    8 +
 ...o_remove_old_version_of_specific_file.mdwn |   24 +
 ..._1663dd9118cb1fee92ae3f8d812df79c._comment |   17 +
 ..._6580f6790404694b55d07a0e57d83336._comment |    8 +
 ..._c1f34ec908d7c4ad05c4360e29e68fb4._comment |    8 +
 ..._160011717157fa8fca3a33b543c4d28d._comment |   14 +
 ..._dfec54344742e2c8d6904333ff848c8c._comment |   50 +
 ..._e854d6b778bcb7dc1578cbc9c8fcaa42._comment |   14 +
 .../Big_repository_vs._multiple_small.mdwn    |    8 +
 ..._8e21ee3c674ef6e595bdab53dd5c2356._comment |    8 +
 ..._656c62351502492d20e8490242e51169._comment |   14 +
 ..._e9c44ea364513f090844f46af2ea46a1._comment |    8 +
 ..._82e13580426dc648688e4c26e7ed91ec._comment |    8 +
 ..._632aceb71dc6a4a9a4bb03de25a9b21a._comment |   23 +
 ..._doesn__39__t_appear_in_the_Assistant.mdwn |   37 +
 ..._239ae08d8eb8b0d7fe52991b0bddc653._comment |   11 +
 ..._8b91328473b384f347710ec634be710a._comment |    8 +
 ..._12a6bc61a7492650fd2baf9a1b796997._comment |   17 +
 ...emoved_any_time_a_copy_is_found__41__.mdwn |   55 +
 ..._a224bf8ed9502053e9b95317db7b4bfa._comment |   24 +
 ..._0f2e7cf29ad9d41e0041924e69425050._comment |   27 +
 ..._a2cac051ef2d36e1ffb550c4a788c111._comment |  101 +
 ..._d95647d91a33d1164a87344939cb769a._comment |   10 +
 doc/forum/Borg_and_xattrs.mdwn                |    2 +
 ..._703c9a9be1e0b0ca9ce4dd0309546a04._comment |    8 +
 ..._a1f4e0758c3e02f4f8558d167a26c0c4._comment |    8 +
 ...sn__39__t_been_working_for_a_few_days.mdwn |   72 +
 ..._6ca872c241399b9129cf9a18f42ebd43._comment |    8 +
 .../Broken_symlinks_remain_after_drop.mdwn    |    7 +
 ..._d4a59b9e58d43d7a3d437e521dd5c4e1._comment |   12 +
 ..._399ba969a17a41a022c69a1f7c480857._comment |    8 +
 doc/forum/Building_Android_app_fails.mdwn     |   69 +
 ..._094b90cbc1e2e069900c0037fec145ad._comment |   11 +
 ...uilding_a_Debian_package_of_git-annex.mdwn |   27 +
 ..._0848513c46f3efa21bc34784554ae88a._comment |   10 +
 .../Building_git-annex-3.20121112-19309.mdwn  |   78 +
 ..._b115e28c77fe748ee6643c41f766beb4._comment |   12 +
 ..._8c6ae1fd74f14da12ccfa77dbd27fc65._comment |   16 +
 ..._2f30b301c14f3a7fa0f52715d6140353._comment |   13 +
 ..._1e3c3903a71a2ff7109372aa4dd5742a._comment |    8 +
 doc/forum/CD-R_as_special_remote.mdwn         |   10 +
 ..._e5d6d72953575d2bbfb6c620bb4c9454._comment |   10 +
 ...esolve_dependencies___40__yesod__41__.mdwn |   19 +
 ..._2eb4f410b54a25fcc895893a3c631c43._comment |    8 +
 ..._44cd6f6dd674df105d6f0b3f320f3236._comment |   19 +
 ..._992af6855901df79a2018a07941cb8b6._comment |    8 +
 .../Calculating_Annex_Cost_by_Ping_Times.mdwn |    1 +
 ..._9b4a6bc8d52ecbbdd537e8cf76757a80._comment |   15 +
 ..._7e04f85c6ba74c18c8dde148aef9bf80._comment |    8 +
 ..._annex__47__transfer_directory___63__.mdwn |   11 +
 ..._3510190e7c5d08f906b24e5743245f87._comment |   13 +
 ..._bfd829aed28817a5aada3f237496c865._comment |   25 +
 ..._cf2ae4db1fdb421b59d85edd9e58b868._comment |   19 +
 ...remove_a_groupwanted_expression__63__.mdwn |    7 +
 ..._23d18b52d87468ffadf0a3e04bf8052d._comment |    8 +
 ...in_the_git-annex_git_repository__63__.mdwn |    6 +
 ..._c8f9923d8dc76b8bed25dce5ae09b520._comment |    8 +
 doc/forum/Can_Not_Sync_to_Git_Repo.mdwn       |    1 +
 ..._e0f82074eb1a4b8258729d9a23a7f421._comment |   33 +
 ..._842aaf685aa843c21bf3eef0b61f8630._comment |    8 +
 ..._b4f8be428a08db01dbd004e1f06dcffd._comment |   10 +
 ..._45132d348807fbf8ed32198e110d2caa._comment |   26 +
 ..._d2bb44a7607f3b2cddfd98cc2fa456d6._comment |   12 +
 ..._80344c54804ddee81d89c0b40731fb9c._comment |    8 +
 ..._1797c2fef5c20e885b56b8a2c6330ff0._comment |    8 +
 ..._fb23d640f9634cab2da91848f1848627._comment |   58 +
 ..._a947736911e68856f2c3494963063df8._comment |    8 +
 ..._ce0e77143cfd2d578b1e5a71e35060da._comment |   18 +
 ..._10e114da6a2bb54b860b44767ba1ca94._comment |   17 +
 ..._415bab6a7ab564e671f42cfad83e0e58._comment |   10 +
 ..._36abd829ea71a44c7cded1123a7c913d._comment |    8 +
 ..._2fb745aaffe544f97bbdc670261fd4fd._comment |   14 +
 ..._file_present_in_special_remotes_only.mdwn |   72 +
 ..._e03ec3be310f5c0e02457ac053e6afdd._comment |   30 +
 ..._1bea8772a170277420faa898dcf2ab83._comment |   10 +
 ..._c061fef62b272d34b605d94a176cd577._comment |    8 +
 ..._2f6d31ada3a8f3f43bc53ce9ee2c70b8._comment |   14 +
 ..._d25b7eb756f08c94a2b2ada472cd0f87._comment |   13 +
 ...git-annex_merge_to_work_from_git_hook.mdwn |   41 +
 ..._8b71cb6772b219c27c17392d5099907a._comment |   12 +
 ..._af2a2634d8d128868022d033d6adb549._comment |   13 +
 ..._31ec762a0684d2ce87d229ed2924db93._comment |   16 +
 ..._cfa52c727baaf683e91c3fbb1c78072c._comment |    8 +
 doc/forum/Can__39__t_get_jabber_working.mdwn  |    7 +
 ..._def20bf0b3c1a188e4dad5ec67b455d8._comment |    8 +
 ..._7cb49c0ebfec6e0fe6784e189ed65d40._comment |    8 +
 ..._852dc402a286e38b77b99f174c33f8d1._comment |    8 +
 ..._259741e146906ff70540390bdfe07002._comment |    8 +
 doc/forum/Can__39__t_get_pairing_to_work.mdwn |    5 +
 ..._b981977b4fb942fd109c37fcf40f35d7._comment |   22 +
 ..._341e2ff6c88ace1b1422e16781edf580._comment |    8 +
 ..._0c8cce48f179f2564ff0844bb7ef6bd1._comment |    8 +
 ..._169d77b30cea05125068ee1eeb2ef328._comment |   25 +
 ..._70e6c4f4f01277be1767b38ca8374793._comment |   11 +
 ..._2cd014a76fac6e08269dfd8146957418._comment |   10 +
 ..._b9b715084d5a5562998b1724699d49e5._comment |    8 +
 ...__39__t_get_some_files_from_bare_repo.mdwn |   21 +
 ..._ead60b63efb06249c99202631ef0b247._comment |   29 +
 ..._82a5d9005dca476916e4b5df671e3111._comment |   25 +
 ..._430c7854e33ff3e821ebd00b436dbf45._comment |    8 +
 doc/forum/Can__39__t_init_git_annex.mdwn      |   15 +
 ..._c4d2ab1ecf69718a2211c3ea7b27092b._comment |   10 +
 ..._fca9ed3707e097bee2cd642424681005._comment |    8 +
 ..._a294b5e7e52aa9f66a708866be16f137._comment |   10 +
 ..._fcf678d5188821d63b4c9ea5b59474a8._comment |   13 +
 ..._c83f7dea7d5304e226e52eb3c43ef14a._comment |    9 +
 ..._06a01dd51ffbfd006c0afb8eab40b530._comment |    8 +
 ..._53c33484bded57abc60f0449331c7b05._comment |   11 +
 ..._9e0ff44f6e62581bfc83f9f1da3e0100._comment |   14 +
 ..._7f96b5ef05e2faf4a3dbe8bfc39b810e._comment |   10 +
 ..._65ab8463716f4ddd7721a5bcfcd18fa0._comment |    8 +
 ..._31a45f6a72266190b3ed7a7b02e03d5b._comment |    8 +
 ...an__39__t_install__58___Mac_OS_10.8.2.mdwn |   36 +
 ..._c44023d81e9e4f7c9341af0e4271a1e4._comment |   10 +
 ..._dfbcd39eedff28dc9ed866a8f1411ef3._comment |   30 +
 ..._b37b2a9906ffb956cca91adb4bb4e521._comment |    8 +
 ..._afddf16f8faedc78d458835480f10dc3._comment |   15 +
 ...__39__t_upload_data_to_glacier_remote.mdwn |   55 +
 ..._cb18d5d63663f73a343c8972faadc83a._comment |    9 +
 ..._9b6a397d1c85da87481d36b8a4bd1ba6._comment |  252 +
 ..._6625da96f8cdc8b367b4c2bc275f2aee._comment |   14 +
 ...d_as___34__must_have_file__63____34__.mdwn |    5 +
 ..._14d4d3f84eacc36dcc55af783d189619._comment |   10 +
 ..._409d6a97f5c3d1f1fc5e932a2965e227._comment |   16 +
 ...icates_honour_multiple_backends__63__.mdwn |   25 +
 ..._5730767d5247e8997b4fa5b20c4cb281._comment |   35 +
 ..._c2846031bd79fa60cd903fb4d5bcebaf._comment |   10 +
 ..._or_Dropbox...__41___substitute__63__.mdwn |   76 +
 ..._a3fbae205c0312436f8861f432643811._comment |   10 +
 ..._de49cf261c644a6e7f6ac881a48d4e6c._comment |   10 +
 doc/forum/Can_not_delete_Repository.mdwn      |    3 +
 ..._b1a9420974e2e50c9c86a379ad62502c._comment |   12 +
 doc/forum/Can_not_drop_unused_file.mdwn       |   14 +
 ..._cea83dfdf4cdb4f6efb3f2b33a39a51f._comment |   16 +
 ..._ed1543cff5e6e81ca18c43b716ca8199._comment |   42 +
 ..._0c9c9c0ed557af4845a67434c21bb4bc._comment |   10 +
 ...40__autocommit__61__false__41____63__.mdwn |    6 +
 ..._bc838634442883e541de1ceab520d71e._comment |   13 +
 ..._676a8c3586d16afedff9e47d9ffd7431._comment |   21 +
 ..._e584a99e46f881358bf848131a94e293._comment |    9 +
 ...motes_that_aren__39__t_tracked__63___.mdwn |   13 +
 ..._35e5a963b9e58ed7773dfcb884f8ecbd._comment |   10 +
 ..._7cde9785886c8450e1475f0b54481ae3._comment |   10 +
 ..._you_use_git_annex_on_gocryptfs__63__.mdwn |    7 +
 ..._3e8c83a9d0a8dbb7a5a3fd25136cf0b4._comment |    8 +
 ..._9a46e613745c8c80dedce6a3cd799e0b._comment |   17 +
 ..._de92ff891493737021cb264394a0a6bb._comment |   16 +
 ..._2689a87a68dc459615d9542ad908b7a3._comment |   75 +
 ..._a1f8d718be941f4dd5e7b06fd6431c10._comment |   73 +
 ..._375b8234fc79d75f3cb39004cbe4d9e3._comment |   25 +
 ..._ff7f26601e375146a08b454a2e448f1b._comment |    9 +
 .../Cannot_find_git-annex_in_server.mdwn      |   10 +
 ..._bf7e98e6130698ad0dc92e3a6a63ade3._comment |   15 +
 ..._168dda4aed09f90a510bc453e8a7cda7._comment |   10 +
 .../Cannot_get_file_from_special_remote.mdwn  |   62 +
 ..._7fd5cebf26042ff0de30746bf8a6adcf._comment |    8 +
 ..._bbb832f022d23b1f020d07f3fe99577f._comment |    7 +
 ..._81a6054bc3b64f1325f4d85979f2b12a._comment |   24 +
 ..._6e7252449b3eb9ca5d45b5c3889cacd4._comment |   23 +
 doc/forum/Cannot_get_file_with_git-annex.mdwn |   95 +
 ..._d16cff700d5899c56011f66b655ad9ff._comment |   33 +
 ..._50c375c6af20b38dec08eff10113dee2._comment |    8 +
 .../Cannot_get_unlocked_file_contents.mdwn    |    8 +
 ..._1905d2a9ae0142838f42aff4efd5c643._comment |    8 +
 ..._496503ae9878d402261910e2dd9bc385._comment |    9 +
 ..._57ee489f24b26b73b28f64566e2b8ff5._comment |   10 +
 ..._be1f3ec26c14ca9adc9d8f24ea096976._comment |   11 +
 ...unch_webapp_on_ubuntu_12.04_using_ppa.mdwn |    6 +
 ..._9345551f5772c3a6f1490b00e1edbf69._comment |    8 +
 ..._0b688a442b6a911a0353e73097a24cb6._comment |   12 +
 ..._7e246caa00005560bb489c927c663046._comment |   12 +
 ..._1d8025aabe8bc72711a77f691f67da5f._comment |    8 +
 ..._7c2f95da65190016192424e7c622122f._comment |    8 +
 ..._9b8465cefe609e7a696e7573b8892e38._comment |    8 +
 ..._af6472762a598a454ba52ac0caa059aa._comment |   10 +
 ...nt_see_git-annex-shell_via_SSH_in_OSX.mdwn |  119 +
 ..._1fafdc4ed4a0f601918361dca688aa6c._comment |   14 +
 ...e_search_with_find_list_whereis__63__.mdwn |    1 +
 ..._b893fd9a250d25ebc62913131cb0a479._comment |    8 +
 ..._e19abfe33b0f071ffc059e9976fc6d91._comment |    7 +
 ...nex_server_that_always_keeps_one_copy.mdwn |    1 +
 ..._e786c8df6e48d88cf15b555af1b8639a._comment |   10 +
 ..._b0a091e11c18c8640888b0aedfbff5c5._comment |   19 +
 ...ith_automatically_merged_working_tree.mdwn |   30 +
 ..._bc850e25e48598a09353850021c6368c._comment |   17 +
 .../Centralized_repository_with_webapp.mdwn   |   13 +
 ..._dcb9b07fd154f4d4fdef4809cc37ce77._comment |   18 +
 ..._08c84f2703f89dc12982eba9dd2a06d1._comment |   11 +
 .../Change_a_special_remote__39__s_type.mdwn  |    7 +
 ..._9d7c23f5c985d44ffa78b3957ddc3d15._comment |    8 +
 ..._c514ca0dd8b883e02de7c70b46991152._comment |    8 +
 ..._b89db83045d4baa82cc96b7610caecda._comment |    7 +
 ...Change_annex_id_after_harddrive_clone.mdwn |    5 +
 ..._2e8ba624f404edf2923d08ae27d12a60._comment |   10 +
 doc/forum/Change_or_add_S3_credentials.mdwn   |    6 +
 ..._864932114dcc7aaf1d88edb0673f1d86._comment |   10 +
 doc/forum/Change_remote_server_address.mdwn   |    6 +
 ..._401c3d2530ac7ba41dd3857ab4737ed5._comment |   10 +
 ..._93a4c44d552efe6d51584e0aab3605e7._comment |   10 +
 .../Changing_files_during_git_annex_runs.mdwn |   12 +
 ..._8067077c49dafbe2afa7d182b3314df4._comment |   14 +
 ..._target_of_an_external_special_remote.mdwn |    1 +
 ..._db1112fb1b4626f2d2c1b7b78ab3f5e5._comment |   11 +
 ...t_test_for_an_initialized_annex__63__.mdwn |   11 +
 ..._abe1af7fc49f91e3aa15915190dc5dfd._comment |   10 +
 ..._3d6f353d087cb945a0288f0594a1d1e0._comment |   11 +
 .../Check_if_remote_is_using_GPG__63__.mdwn   |    1 +
 ..._db8ce8ef50fc33a28860ee475988450f._comment |   14 +
 ..._11c7033904c9c7a1df766e915632c386._comment |    8 +
 ..._a7ab70ad87a334c36761ddb3d830d99b._comment |    8 +
 .../Check_when_your_last_fsck_was__63__.mdwn  |    4 +
 ..._ee98a1fcd796fe4fd7af6f77d0c1837d._comment |   10 +
 ..._7238740d7904a6a9715c1cd7d8a529d4._comment |   21 +
 ..._8fa3680b084fad45d7a184d1191fedce._comment |    9 +
 ..._in_S3___40__reduced_redundancy__41__.mdwn |    5 +
 ..._793b3d9f78562f3aecf27dd926bbcf82._comment |    8 +
 ...Checking_that_everything_is_committed.mdwn |   32 +
 ..._875c22110d65c0d8e6ef6aebced87e95._comment |   23 +
 ...ut_only_some_files_with_the_assistant.mdwn |   14 +
 ..._23d8ab1a05e3e9d3611bd12a4ba70b0c._comment |   10 +
 ..._bf095ff5b5af95b062ae1f7da566a279._comment |   12 +
 ..._7c026e36e1cdd52053c34638c87d793c._comment |   10 +
 doc/forum/Clarification_in_usage_case.mdwn    |    8 +
 ..._555ff0df9be2e25dcc784bc7956dcfe7._comment |   16 +
 ..._8b43bc642656243cdf43cf77ae1c1851._comment |   10 +
 ...ions_about_how_to_work_with_git-annex.mdwn |   11 +
 ..._7f9857887a25df617a99cdab119761d8._comment |   14 +
 ..._up_after_aborted_sync_in_direct_mode.mdwn |   19 +
 ..._3440b2e1662d3b113c18283afcbf4520._comment |    8 +
 ..._9a61ba8ac4a375f1d69cd09b5a6f8091._comment |   14 +
 ..._6b9d8c48547f3d0a911310622ba91df7._comment |   13 +
 doc/forum/Combine_tags_in_view_branches.mdwn  |   24 +
 doc/forum/Coming_from_git_world.mdwn          |    9 +
 ..._098bef38c2688607e869425a557cc482._comment |    8 +
 ..._98d75a1415e0c3689ab4231855e61233._comment |   12 +
 ..._5e7079e9bf3e4d97191333c66ac00e52._comment |   10 +
 ..._357443dc601ae38784c01cf18552f4d5._comment |   14 +
 ..._ed1847dd3f47a9d013b8dd0455fb80ff._comment |    8 +
 ..._09c6bb83a73d34dff2b8bc185a14a1db._comment |   18 +
 ..._6c731bb9a8d21dd9ab8c09612b23f908._comment |   16 +
 ..._e719d99af5afd90da3d3db692eff28dc._comment |   11 +
 ..._85a42106944dba9995fb3f4bfee3443a._comment |   10 +
 ..._90623294b910ceca3dc8ebd41b50fc9b._comment |   38 +
 ..._28dbee30eb54877418f72eb8935302d8._comment |    8 +
 ..._6edb36ea9535030fa3766937398e5bc7._comment |    8 +
 ...arison_with_other_big_files_solutions.mdwn |   11 +
 ..._Problem_with_latest_git_pull_version.mdwn |   23 +
 ..._0b87183756e860d93b8c0197bac3c0b1._comment |   16 +
 ..._1dd40ce31bcf994656fdfee7f8af43d2._comment |    8 +
 ..._f8e52610a592c68f9bc733bd31fa9659._comment |   10 +
 ...tes___40__specifically_S3__41____63__.mdwn |    1 +
 ..._9c6c4ca0c9dc6976ba7cf27e84683bf0._comment |    8 +
 ...usion_about_Webapp___40__on_OSX__41__.mdwn |    9 +
 ..._868b326cc5eb0767390ffdf45a594cff._comment |   10 +
 ..._9b38b92d584395e5468bed03395c927f._comment |   12 +
 ..._7d790a158b7c22206b0b523a4227bacb._comment |    8 +
 doc/forum/Consistency_Check_for_S3.mdwn       |    1 +
 ..._40385806ef1cc082232cd2723a24be1a._comment |    8 +
 ..._ebfe40d9f777c9c0a83c44afd0f5802d._comment |    8 +
 ..._ec9de6882a0eef4d2786e55b583ad020._comment |   10 +
 .../Content-sensitive_chunking__63__.mdwn     |    9 +
 doc/forum/Content_branch.mdwn                 |    5 +
 ..._564724cb1508524700b71950b81a5058._comment |   10 +
 ...sent_and_get_doesn__39__t_retrieve_it.mdwn |    7 +
 ..._55e676477623db9e26e871d7189a1a88._comment |   10 +
 ..._cb404061683de3bfd5c24ce7e5ee6b82._comment |   10 +
 ..._74055eed54696331af07ba1721055562._comment |   16 +
 .../Controlling_content_on_mobile_device.mdwn |   46 +
 ..._708649b7f30d8619d7b34dcb0ef46515._comment |   12 +
 ..._dba1a1b0917332a1dee387b1183bd2cb._comment |    8 +
 ...egular_git-annex_repo_to_a_rsync_repo.mdwn |    1 +
 ..._e6065f9c44c85030c7628e2cfa0fd0fa._comment |   12 +
 ..._76bfb11396dc20a5105376b22e7e773b._comment |   10 +
 ..._b34d6ae0718ab0ff6bc1d7b8f2470b9b._comment |   16 +
 ..._8f5e323b29745591f9f2f0f867353f69._comment |    8 +
 ..._9824c953694770afa0611ff7276737bf._comment |   12 +
 ..._5899741cb7f83e1b22c5ee3509c5ff21._comment |    8 +
 ...ctory_to_rsync_remotes_possible__63__.mdwn |   16 +
 ..._6a598b2a0fc6c241aa051f663dca9842._comment |   11 +
 ..._09b7f1dd1fa4589b3fe0be0086849bf3._comment |    8 +
 ...at_only_wants_content_already_present.mdwn |   14 +
 ..._fb09f84abeebc55df9741b059dc50674._comment |   10 +
 ..._0b13914351aeb57fd7684ff2041618ee._comment |    8 +
 .../Copying_and_dropping_right_after.mdwn     |   18 +
 ..._87d81911964c2628ccb6156b0b631aa0._comment |    8 +
 ..._87a14d14014aefc33f811bb15ea27e13._comment |   15 +
 ...oes_not_work_-_chunking_does_not_work.mdwn |   47 +
 ..._ec390a7d521c697eb6b17e8db1dc9d1d._comment |   10 +
 ..._14a584567ef42d5b7955ee970200e74d._comment |   10 +
 ..._6cbd7329f1f11edf8dd90df27d45158f._comment |   10 +
 ...unreliable_private_server_and_box.com.mdwn |    3 +
 ..._9c357a4a99930936124a58ffe105f87f._comment |    8 +
 ..._b4aec96cbcd8752f273ecd810400acef._comment |   41 +
 .../Corrupt_Repository_Invalid_Object.mdwn    |   10 +
 ..._b7fd4b6212b50400342931e70684b96c._comment |   14 +
 ..._repository__44___can_not_be_repaired.mdwn |   40 +
 ..._297ea9c13096f6360358b3a3e7197c03._comment |   37 +
 ..._c3aabffbe9568cf7acb4018e445f22a5._comment |   13 +
 ..._baee46af6b2dbaf92be406ab22007a85._comment |   12 +
 ...ight_checkouts_on_the_same_filesystem.mdwn |    7 +
 ..._dc219eec54b62803831c854a620aceae._comment |   20 +
 ..._1263830d015a458024a2346540f10f31._comment |   11 +
 ...ating_a_more_secure_shared_encryption.mdwn |    7 +
 ..._read_perms_from_dropped_files__63___.mdwn |    3 +
 ..._53941b83ff173025934e002a26031d9b._comment |   15 +
 doc/forum/Curious_file_in_repository.mdwn     |   17 +
 doc/forum/DBus_on_Ubuntu_12.04__63__.mdwn     |    3 +
 ..._dc14a40b64b7eda94d1a3fd766cd39cc._comment |   28 +
 ..._608a30e274e6a691a39f69503720e320._comment |   10 +
 ..._791b9978b410c1aff7fd8ef05c38f5f9._comment |   40 +
 ..._8665c95299916138c4af375626d9ec7d._comment |    8 +
 ..._NOT_use_ntfs-3g_on_mac_osx_for_annex.mdwn |   41 +
 .../DS__95__Store_files_are_not_added.mdwn    |    3 +
 ..._30687306da9bd35ec02a806193c5e240._comment |    7 +
 ...ompatibility_seems_like_a_showstopper.mdwn |   15 +
 ..._d2640d4cd5bd28df5ecf389d17a2e52b._comment |   13 +
 .../Data_loss_if_symlink_target_edited.mdwn   |    7 +
 ..._599b96a2299f3c998f0317f4321eeff4._comment |   26 +
 ..._synced_from_my_local_repos_to_amazon.mdwn |   45 +
 ...repo_content_is_not_considered_unused.mdwn |   15 +
 ..._e78552e939891b950a8352e4e3bdff92._comment |   22 +
 ...ing_with_crippled_Android_file_system.mdwn |   15 +
 ..._1b17852211108d9ab4d3959d7f57a9df._comment |   20 +
 ..._af66edabeeafcefb45b1d5c5d13dda92._comment |   21 +
 ..._8a555490bf1735c2f05a95cdb281ec80._comment |   11 +
 ..._051a08b7acd718ebae66a6aab69edb6e._comment |   11 +
 ..._a210b77d8567643667bbe92b40b5bef0._comment |   19 +
 ..._91f81669519dbf1dfbad2259f48ab99d._comment |   23 +
 ..._087fdae633144482473c7391ea338c5c._comment |   15 +
 ..._a2bafe08ff3e7a236ba560dafc9c4d85._comment |   18 +
 doc/forum/Dealing_with_long_filenames.mdwn    |    8 +
 ..._373798ea9763d3a0be5ce78f7e3f79f0._comment |   16 +
 doc/forum/Debugging_Git_Annex.mdwn            |    4 +
 ..._ce63b2ee641a2338f1ad5ded9e6f09a8._comment |    7 +
 ..._1d70ff052d00f33c34fd45730ea13040._comment |   12 +
 .../Debugging_of_transfer_considerations.mdwn |    6 +
 ..._e68ab187c15b3b6f9384a990da07f358._comment |   39 +
 ..._f7cd207b08fe365d0a6248316c91ed78._comment |    8 +
 ..._508b5b4155f0f9c0c2a7d2e990a1bf92._comment |   14 +
 doc/forum/Deduplication_in_direct_mode.mdwn   |   18 +
 ..._cb8eaa8c19f5bb9e145a5e4c8995a8ca._comment |   22 +
 doc/forum/Default_annex.largefiles.mdwn       |    1 +
 ..._74a3ad2388e41f1ff17f64a00485a35a._comment |    8 +
 doc/forum/Default_text__47__html_handler.mdwn |    2 +
 ..._4730061916c7e12b7a41906152f847ee._comment |   12 +
 .../Delete_unused_files__47__metadata.mdwn    |    7 +
 ..._3efc19895c8dec89b71ae3778b583fea._comment |   11 +
 ..._23597d9468347b3d94257f3c02afe1b8._comment |    8 +
 ...ing_remotes_doesn__39__t_work__8230__.mdwn |    1 +
 ..._01d244f44d439ad08681af88284103c8._comment |    7 +
 ..._a33c699726e5a913da72671ceb9be989._comment |    8 +
 doc/forum/Desktop_as_transfer_repository.mdwn |   33 +
 ..._b211b8f0ab58b8e59ce31d6ed6cb3c8c._comment |   46 +
 ..._9a943bcfe7679e469acc6fa1f78324b7._comment |   35 +
 ..._17165386df0c8c0085de29659f46f084._comment |    7 +
 ..._986e7d7bb536685f48731ffbbab4dc7c._comment |   10 +
 doc/forum/Detached_git_work_tree__63__.mdwn   |   11 +
 ..._656c737772bf92be2c7a2f33bd2bb0f0._comment |   10 +
 ..._28ac35a325fba250721d9f1b7c994960._comment |    8 +
 ..._7128c26bbc8efea04a5a317edf0ca9f2._comment |   13 +
 ..._a3c22f905748ff2c803e8621c74a87a0._comment |    8 +
 ..._8063921241760458349e7cb0cadf3d4e._comment |    8 +
 ..._4510a787255cb03e7d0c3e7b830b7d52._comment |   16 +
 ..._ffd9c67ecc5b46ae98996018573f5591._comment |   10 +
 ..._36ca007643c983604fc4aed6ec8cb3d2._comment |    8 +
 ..._b7a2da4fbace7156e11c48a496a19dc9._comment |    8 +
 ..._f9fa237a693d28178f0451799209f7e2._comment |    8 +
 ...between_copy__44___move_and_get__63__.mdwn |   24 +
 ..._26ee8192af3a62178c1ccf17c6da5ca5._comment |   10 +
 ...between_unlocked_and_directory_remote.mdwn |    7 +
 ..._6f4501e32029b1dbb52c9a7b4d2f17a0._comment |   10 +
 ..._164489438245c38383645822a93cb80c._comment |   26 +
 ...pointing_to_same_special_remote__63__.mdwn |    6 +
 ..._359f46805e6508d03aadd90429937546._comment |   10 +
 ..._branches_for_different_devices__63__.mdwn |   17 +
 ..._a7d2c26298e8da715e1deb13baaf002e._comment |    9 +
 ..._214c71d2ab43e4d1bf564ea8337909b7._comment |   10 +
 ..._534f1e2cfcc0b6d184ef4968ec33dc89._comment |   10 +
 ...fferent_preferred_content_for_subdirs.mdwn |   13 +
 ..._5c1e1e6375360cc9416821085b5a68a8._comment |   17 +
 ..._cc72b229b0a9a8f0ae0f42d6c2a145fd._comment |   47 +
 ..._c6764ea73c13b59645f1b378e77984b6._comment |   13 +
 ...ile_from_Full_Backup_Repository__63__.mdwn |   14 +
 ..._67ac7e8b53a4374baf640d32dac79030._comment |    8 +
 ..._eb6df2bfcb3892ae22050a8c5f67ee90._comment |    8 +
 ..._15f36487383a631f16e041e2885c44ec._comment |   10 +
 ..._9293831aff5b6cef490f65d03638d34d._comment |   12 +
 doc/forum/Direct_special_remotes.mdwn         |   26 +
 ..._50357130a1c57ad2fab70f71925faf02._comment |    8 +
 ..._e94a722ca056a068bcc16eb822008602._comment |   18 +
 ..._187036bbfee0508e2914afb51ead3c71._comment |   16 +
 ..._6bfbf60f2061d49b7d34c844e7e1dea2._comment |   66 +
 ..._69c34c655e4b153dfc0d1b8580091124._comment |    8 +
 ..._b054cfc3d3f81873f3faae7eb4f5337c._comment |    8 +
 ..._5f9d8a0ef2f13f242594848825d29ee7._comment |    8 +
 ...o_adjusted__40__unlocked__41___branch.mdwn |    3 +
 doc/forum/Disable_ssl_verification__63__.mdwn |   34 +
 ..._39af4df2a16e363f93f75a7a57af048c._comment |   12 +
 ..._8ff8769a1e62caf4f515b04db38d13f0._comment |    9 +
 ..._cf39af1d8ff11ab602363a717be074c6._comment |    8 +
 ...ges_of_WORM__58___long_filename__63__.mdwn |   13 +
 ..._cc5502b55fb71c8fdb235ea9d17216ff._comment |   12 +
 ..._d04b7adcc17a305fb1d7f1c1a3641be1._comment |   24 +
 .../Disconnected_Archive_and_Backups.mdwn     |   18 +
 ..._c56f2d3328c0d127efc21067dc52df15._comment |   20 +
 ..._63b934b773b5f7a3c128dd9685f671ab._comment |   23 +
 ..._fae320f7453cf8c7147a109f19be22ba._comment |   16 +
 ..._b3d39d1b85489ce4059a72b9a912624c._comment |   36 +
 ..._93bed4629304725297f88cfa3d494720._comment |    9 +
 .../Disk_usage_during___96__import__96__.mdwn |    5 +
 ..._3ed4d9a36cacb9be96860cfaae8cee90._comment |    8 +
 .../Distributing_data_to_a_set_of_drives.mdwn |    1 +
 ..._f1fa72879f4e1db13bf59dea33c91624._comment |    8 +
 ..._e13b4e5c1e6f1f503f93d521b504d5c1._comment |   16 +
 ..._I_have_naming_ssh_remote_issue__63__.mdwn |   45 +
 ..._f3e5ef9d7440cba467ebda1f2e8b12ea._comment |   25 +
 ..._work_when_the_buddy_is_offline__63__.mdwn |    1 +
 ..._f290dd8547176793934f8077374e1c0a._comment |   17 +
 ..._c358eb51047f333e582bd824be5e0e65._comment |    8 +
 ..._a2332c0e7b29110b9aed2ab69ce9d8c4._comment |   12 +
 ...oes_git-annex_version_big_files__63__.mdwn |    5 +
 ..._0b44003c1dc53adb807298ae452f8004._comment |    8 +
 ..._ca40b67abd7bd36155d16d0396d7472c._comment |   14 +
 ..._32de3501feedce51b43ed9dcc399c7a9._comment |   15 +
 ..._8c65a7f8bda3c876971c2801fb6a76a1._comment |    8 +
 ...ly___95__read_only__95___source__41__.mdwn |    8 +
 ..._25572571debe2c91447b0ed952f45cb2._comment |   19 +
 ..._46c27b242c6df76f9df198bbd6f14030._comment |    8 +
 ..._2d9baeb81857b354931251a8b8a756e5._comment |   12 +
 ...s_migrate_ensure_data_integrity__63__.mdwn |    7 +
 ..._cef50b32c46f4406c6f918c5866ddc15._comment |   11 +
 ..._f389b924c8531b35fdf5dedd10fc8000._comment |    8 +
 ...sion_install_iStartSurf_malware__63__.mdwn |    3 +
 ..._0536085a1f969802a7e8607093eee97d._comment |   24 +
 ...py_files_to_exporttree__61__no_remote.mdwn |    5 +
 ..._9f8e1ac58e319540b3d9a5b9962e1f8f._comment |    8 +
 ..._f398f38ff29d2e681548b1640080dff3._comment |    8 +
 ..._53759e189b2f13b8ea1f48f3b6fb7fca._comment |   19 +
 ..._c3d9048668596f6be3975026ec1debc1._comment |   23 +
 ..._e9ea995c99785dd6dffba91ef0fceb02._comment |   12 +
 ...tand_how_to_delete__47__recover_files.mdwn |   25 +
 ..._b307bfb0b70d649897f411eb753bd50a._comment |   14 +
 ..._58a6a1476274b8c4feb3d43ecd998759._comment |   41 +
 ..._4b857f481db7b2437ac9f8137a8510e2._comment |   11 +
 ..._828db3bf2863d98c0b0fb4074aa7f066._comment |   33 +
 ..._cb2063d6a4e08a5c12bf3723d0fa74e0._comment |    8 +
 ..._1759bcd5708f591f91b9c410f6dc5c54._comment |   14 +
 ..._2a389f01eb5131042ea1e71a73c9787a._comment |   21 +
 ...39__t_understand_local_vs._known_keys.mdwn |   19 +
 ..._10749c0d76e824217dd1ff8c8a6e42a5._comment |   10 +
 ..._db9f1b6d9638c2b0a7e241c2727e8cfb._comment |   13 +
 ...39__t_understand_sync_with_ssh_remote.mdwn |   54 +
 ..._be10d6b564e130f4a516d438831681d1._comment |   18 +
 ...p__47__move_unused_files_older_than_x.mdwn |    1 +
 ..._626facc640a9018a04f203d10aff7676._comment |   22 +
 ...d_objects_keeping___35__n_more_recent.mdwn |   18 +
 ..._2e16a4c08568ea37c16f4ea74203ae12._comment |   29 +
 doc/forum/Drop_with_assistant.mdwn            |    5 +
 ..._048f5a31c549afb19b76a65bddd0cd24._comment |   13 +
 ..._527d7b6a8efa85b904111f179912d926._comment |    8 +
 ..._c50857506869bb1cd306b66acf37fba8._comment |   14 +
 ..._1ea37445d5eb96c3efa182e88e07b867._comment |    8 +
 ..._c08908ea5232cbe067c73ecd12d0e218._comment |   10 +
 ..._015134228cb865f97326fbb7193636ea._comment |    8 +
 ..._950759930667588f21659cd6d7065fbb._comment |   17 +
 ..._773e540e46adc43487323e8d38ceb2d9._comment |   23 +
 ..._d85d120d7219ea6c179c2619a17bdae9._comment |   15 +
 doc/forum/Dropping_checksum_from_URL_key.mdwn |    9 +
 ..._ce952a9db35d398a9e67adcd7f927d59._comment |   17 +
 ..._bb458296d464c2025f96502338f34000._comment |   16 +
 ..._files_in_an_annex.thin_v7_repository.mdwn |   16 +
 ..._9f2dcdfe6a689902f348211db6b7a758._comment |   15 +
 ...ate_entries_in_location_tracking_logs.mdwn |   25 +
 ..._3afb76397519b8ca8b55958a344f1871._comment |   10 +
 ..._6f327444772ee1e660a12e7442162df5._comment |   10 +
 doc/forum/Duplicate_files_not_detected.mdwn   |    1 +
 ..._d49a34aae5decafed804f45a573c0027._comment |    8 +
 ..._c1afe87e818ac3eea66d5216bb15d727._comment |   10 +
 ..._c07b9634f571b5f12665b368c0ad3c80._comment |    8 +
 ...Editing_Metadata_in_your___36__EDITOR.mdwn |   26 +
 ...Editing_files_in_metadata_driven_view.mdwn |    3 +
 ..._acb4656e0dafc5689c84d4cca760bafa._comment |   22 +
 .../Effectively_replicating_backup_files.mdwn |   25 +
 ..._b1ab0da82db076c5244b0dcc95282ddd._comment |   14 +
 ..._472ab9c973b475f7f3ce7e3934f94281._comment |   19 +
 ..._826493bd59b81786c1f6a56f1c438004._comment |   10 +
 ...y_move_files_from_one_repo_to_another.mdwn |   26 +
 ..._191ca3a984412be76f64aa31b55b8d50._comment |    7 +
 ..._0cc04ef5e511241a5152a0702f943538._comment |    8 +
 ..._be029c0880e76d6b5672eed394140438._comment |   22 +
 ..._c2f4b10fa1789a4966aed298e00dbc75._comment |    8 +
 ..._65bbee3637d09bb6078ec7b118852fd8._comment |   10 +
 ..._45c1788b39953cd7237f014fa94e086b._comment |    8 +
 ..._23b3a1a1412866fa06e736f0f5bab583._comment |    9 +
 ..._fba097cd3187d1d8b7517594d875c373._comment |   14 +
 ..._b8f81522e519bab56036cc8628f29ce9._comment |   12 +
 ..._3e5f41a5cce30c21cea629009f91dd31._comment |   14 +
 .../Encrypted_Content_Remote_Daemon_.mdwn     |    1 +
 ..._96f63e509e23c081c48302274e21db78._comment |   10 +
 ..._acd0ffdc3f5079265858073c2af81557._comment |    8 +
 ...ypted_ssh_remote__44___synced_folders.mdwn |   87 +
 ..._7b9b4ef614c90e0b222d24678d1b9026._comment |   10 +
 .../Ensure_all_versions_are_on_remotes.mdwn   |   36 +
 ..._b8b674dc99999dcdb5a435f34b96c1ea._comment |   10 +
 ..._ad5f1f0b98032361e64bb7275d23e97c._comment |   20 +
 ..._d9bd5f9ef8c8a8cc08cc39396f0a6f67._comment |   10 +
 ..._8d07699b69676d9afd53744f267bb615._comment |  116 +
 ..._2202121e5311b56b1d73f9bb1503c5e3._comment |   12 +
 doc/forum/Equivalent_to_git_bundle__63__.mdwn |   10 +
 ..._e42936a9bc36fbee69f48e32df303dee._comment |    9 +
 ..._2b8b5c237d8572fdd27202f3502bea96._comment |   13 +
 .../Error__58___failed_to_push_some_refs.mdwn |   25 +
 .../Error_adding_ssh_remote_in_assistant.mdwn |   17 +
 ..._eecc0660db4083cc91c5330587f74610._comment |    8 +
 ..._3e6aad22e8020b12ff7ef914b75281d1._comment |    8 +
 ..._3ea529e16502071fc0980c6d5c60a036._comment |    8 +
 ..._on_creation_of_gcrypt_special_remote.mdwn |   28 +
 ..._2a69ce8607f97aabdf3cc402c1091d7a._comment |   30 +
 ..._a112f0bc1a30fa41504e3f52f679053b._comment |   11 +
 ..._does_a_v5_to_v7_upgrade_entail__63__.mdwn |    3 +
 ..._04a920f5b86a203d050ee4a9a0f8a33d._comment |   35 +
 ..._b43fda0acca8cc9027f36f51b9489aa3._comment |   22 +
 ..._380240e562358efb25a8acb65b5d4cc7._comment |    8 +
 ..._752b1c3e2394ef432c1e21a5639648be._comment |   10 +
 ..._e5d4ba2bb9f78380dfa94446cb1f4b54._comment |    8 +
 ..._cec779ef77336ea30728815739be78b6._comment |    8 +
 ..._e349403ef92a96a08195a7dd1dbf9561._comment |    8 +
 ..._bca507381436a8282645a931aa39fb20._comment |   10 +
 ..._specific_files_from_a_special_remote.mdwn |    3 +
 ..._d5a9f3308e09a9b9460014904d23ef48._comment |   18 +
 ..._671790686bd4724aadcadd8d8aad2c98._comment |    8 +
 ...hat_aren__39__t_locally_present__63__.mdwn |    7 +
 ..._278b70c7bd7397e634df4a257fb604f9._comment |    8 +
 ...4___even_if_not_in_preferred_contents.mdwn |    3 +
 ..._8276c225867733e7a79ba47be2447b1e._comment |    8 +
 ..._dc1e718d0043686987abc9526a459dc3._comment |   10 +
 ...it-annex_branch_but_not_master_branch.mdwn |    1 +
 ..._9a909e3d89061adacbd8ed370520250c._comment |    9 +
 ..._0dd489b264374b7b1065b89e1ff7561b._comment |    8 +
 ...xtra___38___missing_folders_on_remote.mdwn |    9 +
 doc/forum/Failed_to_push_on_git-lfs.mdwn      |   23 +
 ..._f83dbcfdd09de3ce908c0d4a9daef458._comment |   13 +
 ..._52051b251bea7a5ed452769d0320602a._comment |    9 +
 ..._get_files_from_rclone_special_remote.mdwn |  104 +
 ..._4a762c369e4049bdedecca4a32242f18._comment |   30 +
 ..._cfb6be6c940350dbed6cc9e98ee1d633._comment |   10 +
 ..._58282be918139a3154938850793a80fb._comment |   11 +
 ..._1360ee3e3b711990f59e0320e7892cd2._comment |   10 +
 ...et_file_from_s3._How_to_recover__63__.mdwn |   16 +
 ..._c769dcbb9d5f082d54b8a091a44c9de4._comment |   21 +
 ..._50e35159f7e670ca6b7280121821b494._comment |   21 +
 ..._471ff0cdb00b311f2a3d801b04e9edef._comment |   26 +
 ..._e0f80d306a2b4d19d65d268cde25ac31._comment |    7 +
 ..._f648049cc1a82f183bbc7dc84cd170e2._comment |    8 +
 ..._c2686480c6c77ea7297f739780ea6d3b._comment |   11 +
 ..._6f3d056e449366746aef4f45673515d5._comment |   12 +
 ..._785e012f478631f4b69fefbd0394f1b8._comment |    9 +
 ..._e021705e0fae6645a0b6459757260084._comment |   18 +
 doc/forum/Fast_cloning_a_repo_initially.mdwn  |    3 +
 ..._0db0caafe30dd1b6f15fb1679dec8f9f._comment |   10 +
 ..._e17abc209c2b3ba20158be76801ce04a._comment |    8 +
 ...size_when_adding_files_to_URL_backend.mdwn |   10 +
 ..._9d2fa7d796fd40718d0df9feeea654aa._comment |   20 +
 ...st__58___add_filename_to_hash_objects.mdwn |    6 +
 ..._73dc0a9cad486cf2d34faf064c6193b1._comment |   10 +
 ..._f818b3ecfeb1d1dd83df4668c061718a._comment |    8 +
 ...quiet_for_fsck__44___import__44___etc.mdwn |    9 +
 ..._cbcc3df01a346c6ee6720c90421ee023._comment |    8 +
 ...t__58___Multiple_concurrent_transfers.mdwn |   19 +
 ..._aa666349e9b524fd5394a259ad622c3b._comment |    8 +
 ...nnex_copy_--auto_does_the_right_thing.mdwn |    5 +
 ..._bbac7d0810a79eb1f42a01e1b31d5c4c._comment |   12 +
 ...pp_support_for_centralized_bare_repos.mdwn |    1 +
 ..._0522e3df450efb6b2d264857e07997dc._comment |    8 +
 ..._e0fc126b0d500d41a563b076a4f6ed6d._comment |    8 +
 .../File_downloaded_again_and_again.mdwn      |   53 +
 ..._666b907935d467d5d7c0e57831d76631._comment |   28 +
 doc/forum/File_history.mdwn                   |   10 +
 ..._6c15cdf71b99ae3bf8fd5de489a7d3ee._comment |   10 +
 ..._ebe8025d4769d22cafa81ad0f2ae969a._comment |    8 +
 ..._16aae9a5fdd5cfed816f5cdd96adf7ba._comment |   10 +
 ..._1b72655106507f111192231ab62cbe7e._comment |    8 +
 ..._72d1b2ff307df69add474a288f92d8c3._comment |   19 +
 ...ill_symlinked_after_git_annex_unannex.mdwn |   22 +
 ..._55f1a5f16fe2f8a85034a85c5450bad2._comment |   12 +
 ...too_big_for_file_system_of_git_remote.mdwn |    1 +
 ..._937df2f51506c42ddd2345735efd8f21._comment |   12 +
 ...4___xfs__44___you_name_it__41____63__.mdwn |   74 +
 ..._fcf7f132f771de28553bd20f4fb014cb._comment |    8 +
 ...kaging_on_downloads.kitenet.net__63__.mdwn |   11 +
 ..._0d89d709e799442d77b0fc92f97fc3ae._comment |    7 +
 ..._cccbc5c1d9b010ae38a8b5cfd9056cfe._comment |   11 +
 ...that_lack_a_certain_field_in_metadata.mdwn |    5 +
 ..._476e52563ccd3ad1b43e3a2da4dfaa82._comment |   10 +
 .../Find_out_if_file_is_in_annex__63__.mdwn   |    8 +
 ..._3936ff53d5c9f7e5795b15beadf437c7._comment |    9 +
 .../Find_unlocked__47__locked_files.mdwn      |   23 +
 ..._a34ce29b644c80789bf8cbfd575ffe1a._comment |    8 +
 ..._85d90a43142d087e7b6183dd9f8be8cf._comment |   11 +
 ...ut_why_file_is_not_being_auto-dropped.mdwn |   22 +
 ..._d3881fe94e3588c90e74c6bb3db2783c._comment |   20 +
 ...t_at_an_OSX_launcher___40__.app__41__.mdwn |    3 +
 ..._97c261b9080c5ecc5424683066bbe05b._comment |   14 +
 ..._ae45f9703b635c235409682cf252d36c._comment |    8 +
 ..._066ca31a2e5dfe55a58092ba85231c7c._comment |   10 +
 ..._a0a9f7f44cadb8036fcddfc21bb0781f._comment |   10 +
 ..._92240b3f8629f1f2bbe1829700082a79._comment |   10 +
 doc/forum/Fix_duplicate_UUID.mdwn             |    5 +
 ..._1186caf5aa6830c2412f8584a43d8d86._comment |   18 +
 ..._b0f06b58ef63dbb770773f28dfa1a29d._comment |    9 +
 ..._525b2838985392eb65e705ad354d02c4._comment |    8 +
 ..._ce58bf264e63a07a214956436d96f1a5._comment |    7 +
 ...ong_rsync_with_git_annex_reinit__63__.mdwn |   38 +
 ..._26cb6d46a408c1002aa2fbc6618242f3._comment |   11 +
 ..._14ddf5ddf2b85c9d5ed5ca070744f1fe._comment |   10 +
 doc/forum/Fixing_up_corrupt_annexes.mdwn      |   10 +
 ..._cea21f96bcfb56aaab7ea03c1c804d2d._comment |    7 +
 ..._5cdd2fcfa61b3f6255e5ad63a3ab00ce._comment |    8 +
 ...ve_disrupted_the_file_structure__63__.mdwn |   20 +
 ...Forcing_offline_copies_seem_available.mdwn |    3 +
 ..._75e8597a24c925981edf83c517d5a799._comment |   32 +
 ..._7d0e219628ad19093c6b6410d24c5f9a._comment |    8 +
 ..._3d57e187679b36be62f3918eb996c3df._comment |   10 +
 ...e_repo_to_contain_a_copy_of_all_files.mdwn |    1 +
 ..._702b1b94c735f1b9cde16daa77a80c12._comment |    8 +
 ..._3df7fcbcd482bb9377ead238b314995b._comment |    8 +
 ...t_about_accidentally_added_file__63__.mdwn |    5 +
 ..._a7e6b1f6abe4caf8bd93be879c960cec._comment |    8 +
 ..._6beeec3a8bc9697481aa08738902203a._comment |   10 +
 ..._6bf46255cd212942d8db8b01c95443b2._comment |    8 +
 ..._2183fee162740918e5f67f9bd460b18d._comment |    8 +
 ..._2b248738c6fb871875cf1aa7413198cc._comment |   12 +
 ..._1fcfcb5dca366d8fd610c03654e15704._comment |   12 +
 ..._a982dd633e7f29ec80c8e4362ebc064a._comment |   15 +
 ..._ed88d2b82fc3283540caf3a255a88188._comment |   14 +
 ..._23cc8cec09f9e8fb56c0cb81c9b361bc._comment |    8 +
 doc/forum/Fsck_by_refs_or_keys__63__.mdwn     |    5 +
 ..._345daa76cdd13538054e886a755bf29d._comment |   14 +
 ..._1d74ad47cf3bef9bcc0ccdff4ccb69b9._comment |    7 +
 ..._b00a9522bb6dd91fed5d1c790153a230._comment |    9 +
 ...tore_from_an_encrypted_special_remote.mdwn |    3 +
 ..._f3a7a766ae1fe8e586cd67148761f156._comment |    9 +
 doc/forum/Full_workflow_guide.mdwn            |   16 +
 ..._14664efebb1218a1449577eaa4653a77._comment |   45 +
 ...very_with_an_encrypted_special_remote.mdwn |    9 +
 ..._2eb2f05477a86f1352e734d163301ffa._comment |   44 +
 ..._c2f7542ac9a4c423c5ae06c16d42a24f._comment |   17 +
 ..._9a9da0ad1538ba59e76a5c4f9fc7fcf7._comment |   18 +
 ..._27901f1c2c5de211f697972d9b21c104._comment |   11 +
 ..._56994d9252e8651b3f33044f5c8599b3._comment |    7 +
 ..._5aecb8c58d501e929e746d5536032c81._comment |   13 +
 ..._ab0b660e5a3d7fc7d3d3a4b460022da5._comment |  139 +
 ..._b96077c98792997cdf344725374abb5c._comment |   27 +
 ..._e9597062bbc530920343e5159a7b7ea1._comment |   10 +
 ..._756aeeee7be8cb67c5cc9dfa6ea7b82c._comment |   25 +
 ...cal_sensitive_hashing___40__LSH__41__.mdwn |    9 +
 ..._29f2396e04251d266b68ba68b8b32215._comment |   11 +
 doc/forum/GIT__95__SSH.mdwn                   |    3 +
 ..._c2e827eeac7524845cad42671d77af95._comment |   14 +
 doc/forum/GPG_passphrase_handling.mdwn        |   78 +
 ..._11ba130e8bea6698858d0a1a5b01830f._comment |   15 +
 ..._ef9d58d15b7bbe0b3c7140bb01d73a31._comment |   15 +
 ..._84eb129c8483b87b3ae6ecaf8b4a8309._comment |   12 +
 ..._8724297f6d7ac140ab395a940bab0d7d._comment |    8 +
 doc/forum/General_questions_and_help.mdwn     |    9 +
 ..._adfef0ecc191dd2ad85b4e0f6a4df67d._comment |   10 +
 ..._972231014d3da4fcd8fb2a77d76e7b77._comment |   10 +
 ..._1a071d4a7e62701c47d8531c4faa9dcb._comment |   10 +
 ..._51b8cd9f1b8b53bcf880ea56d1858f23._comment |   13 +
 ..._0105e241e13f9469bf749735cb9f3e03._comment |   10 +
 ...rating_a_Temp_View_of_Available_Files.mdwn |    1 +
 ..._to_automatically_drop_with_assistant.mdwn |   88 +
 ..._ead4b5b7ec0d085d4fa87fb4e29c4d55._comment |   49 +
 ..._835dba9de7a5eea868635dc793d4e75b._comment |   15 +
 ..._553542a4a2b2530863a006a1afe91637._comment |   19 +
 ..._4540a15672f9b48b0f9310c97f1a0b86._comment |   11 +
 ...ithout_persistent_configuration__63__.mdwn |   83 +
 ..._0ae170680841f86279b95febaafa0440._comment |    8 +
 ..._1f46bcb05d7866af35779830ceb632e2._comment |    9 +
 ..._177db535bf756cfb4c231a41cd02e137._comment |    8 +
 ..._cb4f95866113ac6f689ed9f219a1d8e1._comment |   12 +
 ..._748a794bf4cda242923177352e34976c._comment |   24 +
 ..._994e3e64184a020f9afe21cd9ea34b38._comment |   10 +
 ..._b215a9ab1c37688cc22dbe4ec63347ad._comment |    8 +
 ..._15de9ba04480697bdf4086cdf91226e4._comment |   13 +
 ..._f642798f8d1c753dca3aad67d0bd9ace._comment |    9 +
 ..._018442fba01a2aac43531f2eaecc1117._comment |   14 +
 ..._577c3dfc1f77ad0821ed8fcbbac3772c._comment |    9 +
 ..._7a3a21b3995f79710ebb5a8428709f66._comment |    8 +
 ..._95fe371e2e5083c8dc06b24b2f8d87e1._comment |   68 +
 ..._ae600abfb5a82f69981f59e9de55c056._comment |   11 +
 ..._d97c211a0e87212ffd2617a96263faa2._comment |  107 +
 ...4___that_do_not_exist_in_repository_B.mdwn |   17 +
 ..._c09c45c64f75bd30deaae9c8d8633236._comment |    8 +
 ...ecent_git-annex_version_with_anaconda.mdwn |    1 +
 ..._2987d3516235e90621335d055426a808._comment |   11 +
 ..._3046a4711853c88ba7f763fb04b73a5a._comment |    9 +
 ..._ece2ad657025186c267aeb20405ea1e5._comment |    8 +
 ..._f54f3ef05da471ff4d370511e3629e05._comment |    8 +
 ..._59365f2d382103f1f8c30d4c52085fd6._comment |   15 +
 ...peration___40__handle_is_closed__41__.mdwn |   13 +
 ..._9ff60145d7dfb6785bb11f2a23040948._comment |   19 +
 ..._7c88ebd9d7cdf4a009aa2580cc55787d._comment |   20 +
 ..._976cb63e97774859023123536bdc9d99._comment |    8 +
 doc/forum/Getting_metadata.mdwn               |   30 +
 ..._24bef8f59f370897d6fd6b2b43ed1f39._comment |   13 +
 doc/forum/Getting_started_with_Amazon_S3.mdwn |   28 +
 ..._f50883133d5d4903cc95c0dcaa52d052._comment |   10 +
 ..._e90aa3259d9a12cd67daa27d42d69ab5._comment |    8 +
 ..._c3adce7c0f29e71ed9dd07103ede2c1a._comment |    8 +
 ...atus_of_a_remotely_changed_annex_file.mdwn |   75 +
 ..._e323c21d27bb0946993ba1438429c457._comment |   14 +
 ...roid_sync_files_are_missing_on_Linuxx.mdwn |    4 +
 ..._72d7811990e78fba0b7fc2e1c7ee515f._comment |   15 +
 ..._cfb7139958ed24c1c64f8b133c99f336._comment |   11 +
 doc/forum/Git-Annex_with_Asustor_NAS.mdwn     |    4 +
 ..._44445200e5b716caeec225972a5d5dce._comment |   10 +
 ...ex_and_Microsoft_Office_files_on_OS_X.mdwn |    1 +
 ..._71fdd5e7061d6deb357290057804cc27._comment |    8 +
 ..._files_and_older_versions_saved__63__.mdwn |    9 +
 ..._645af86feb8506c3ea2134badac68e0b._comment |    7 +
 ..._d9acd44c00676d814e19613d6fd276a2._comment |   13 +
 ..._45928886d1ae4a76e2daefb355967729._comment |   19 +
 ..._1249bf921ea7709b4f7ae25e613bf60a._comment |   11 +
 ..._616cb76a510fa32c2aa48c25d24c6044._comment |   10 +
 ..._100fc29a95923e5ef92eaf87d76bbc6f._comment |   37 +
 ..._9b19ae8e8c0c70e3827c9f362c1c1dea._comment |    9 +
 ..._0c1c76bb082c108f3074b725bcc272c9._comment |    9 +
 ..._1d7c8c8c5b34cbc7166f8d4d52b91761._comment |    8 +
 ..._2bfb2eaf1a72e0822341cfeba9058aa7._comment |   13 +
 ...le__40__s__41___location__40__s__41__.mdwn |    6 +
 ..._5baffd4d6994bbcb23614b17777a0ffe._comment |   10 +
 ...es__44___how_can_I_recover_them__63__.mdwn |   19 +
 ..._65b41a6eb28261e04e4fe8732f97a1f1._comment |    9 +
 ..._200a869f335909566b9ddab3032fd5a2._comment |   10 +
 doc/forum/Git-annex_fsck_backend_warning.mdwn |   42 +
 ..._a504439397db6661788d916cb7c96da1._comment |   30 +
 ..._a5415299d07283f393319b37ba9335ff._comment |    7 +
 ..._300bbfdd90d18619e88310de5a128ef0._comment |    8 +
 .../Git-annex_init_gets_stuck_on_exFAT.mdwn   |   30 +
 ..._48da28dbc7da82d4e06fd3ce7962dfc5._comment |   16 +
 ...it-annex_link_to_different_file_names.mdwn |   41 +
 ..._17ab85276bcf495a656c7091753c086f._comment |   60 +
 ...slow._Why__63___How_to_fix_this__63__.mdwn |   35 +
 ..._e102345b520423eafb4c202a0d6e276d._comment |   19 +
 ..._dd1cce225e4d4791b37dad5480936f76._comment |   11 +
 ..._56c132612785da00b09f088c75f903a7._comment |    8 +
 ..._b92198e15a0d6154c951cb731eca828a._comment |   13 +
 ...32_devices_not_a_valid_use_case__63__.mdwn |    5 +
 ..._ee72caf2aeab4a8a2818f87653dc1cd2._comment |   15 +
 ..._3be98f57bcb2ba838046105276d1afd4._comment |   19 +
 ..._b17f2361b18420c950eef25d3fff8841._comment |   13 +
 ..._a8a79961d97fe773c1855632b4772c5b._comment |   11 +
 ..._da422adacdeb36163186a38f1aa6c06b._comment |    9 +
 ..._6f16af7d1668320d1b80472c76f892fb._comment |    9 +
 ..._2d9460736189575a8af99c50557a8e50._comment |   14 +
 .../GitBlit_as_a_centralized_repository.mdwn  |    2 +
 ..._06bedf5fbac45415e0cc81f41b25a5a0._comment |    8 +
 ...oses_Files_and_Gives_Dangling_Symlink.mdwn |    9 +
 ..._7b3cb1d52767b89cf46d57005bf57b06._comment |   11 +
 ..._52ad16f63ec47b34485a0d0f4db9e2c8._comment |   13 +
 ..._a60bc9a6e766c0f29835c088c0863cf5._comment |    8 +
 ..._c8088fd093312685f130af07e5ca2e22._comment |   11 +
 ...stant__58___How_to_add_a_remote__63__.mdwn |   11 +
 ..._d0a3d0090928790d5a05e9f8e5f05320._comment |   12 +
 ...39__t_backup_files_to_removable_drive.mdwn |    3 +
 ..._a1d1ae9488924b08682b355aff51130d._comment |   17 +
 ..._6649077583bc14730a08aaaca7ccb62e._comment |    8 +
 ..._f359d9b9356de7ee10b9e725a011cc43._comment |    8 +
 doc/forum/Git_Annex_Sync_Delinks_Files.mdwn   |   11 +
 ..._8b03707777a9d8e38715cb77d2a0addc._comment |   12 +
 ..._a625e7d88e321532ace103548b31b67b._comment |   18 +
 ..._5278164dab570755ed58afe466dfad42._comment |   12 +
 ..._e43ede0bdc20de9aa10ab6ce387d8582._comment |   92 +
 ..._dc71987f0e19f04a920561201f9552b4._comment |   15 +
 ..._257a89f81858659c4dac4d116e7cf0a3._comment |   32 +
 doc/forum/Git_Annex_Transfer_Protocols.mdwn   |    9 +
 ..._a870ec991078c95a6bb683d6962ab56e._comment |    8 +
 ..._71419376ef50a679ea8f0f9e16991c17._comment |    8 +
 ..._fea43664a500111ca99f4043e0dadb14._comment |    8 +
 ..._56fb2dab1d4030c9820be32b495afdf0._comment |    8 +
 ..._a6ec9c5a4a3c0bac1df87f1df9be140b._comment |    8 +
 ..._1678452fb7114aeabcf0cc3d5f6c69b0._comment |    8 +
 ...Git_Annex_not_dropping_unused_content.mdwn |    9 +
 ..._da47b6af512b19cba077499f41455189._comment |   23 +
 .../Git_Annex_shirts_at_hellotux.com.mdwn     |    3 +
 ..._fa72689070c39054d166d32fa144fabc._comment |   10 +
 doc/forum/Git_LFS_lock_feature.mdwn           |   15 +
 ..._8f5878db6dd2a21893cc6b5a1200b010._comment |   16 +
 ...__44___windows_and_remote_linux_issue.mdwn |    1 +
 ..._c9239f9c67b2441ab0e1ac42c53db531._comment |    9 +
 ...t_annex___39__corrupting__39___itself.mdwn |   34 +
 ..._bcf50a215e2f8771e098aadfff4c300c._comment |   43 +
 ..._75f957e7be6c1ad8936c0a2a5374db3e._comment |   20 +
 ..._ab062b1df3b55fd49852a6220c98249e._comment |   10 +
 ..._45974f60a81ed2d00b87ffb1a7963c6f._comment |    8 +
 ..._t_find_rsync_nor_git-annex_on_server.mdwn |   14 +
 ..._75c599cc26e7d3645f69173861d4f8be._comment |    9 +
 ..._496e2f3a61b609ebb28ab55e5c30022b._comment |   12 +
 ..._e202a6dd2803f733bd30ec8b6ddbe7bf._comment |   19 +
 .../Git_annex_assistant_in_command_line.mdwn  |    2 +
 ..._ce05226307ade8db90ada2dbf290bd58._comment |   10 +
 doc/forum/Git_annex_assistant_on_EC2.mdwn     |    5 +
 ..._bbdb4611373117a2176c225378110a05._comment |    8 +
 ..._614ed11f7134137d6376d36a61c293f5._comment |    8 +
 doc/forum/Git_annex_drop.mdwn                 |    4 +
 ..._541399d5fff0db0627c786f5e056fabb._comment |    8 +
 ..._423ffd4abca9dbb8dba8ce887dee5faf._comment |   17 +
 doc/forum/Git_annex_hangs.mdwn                |    2 +
 ..._ce5355b358f1acc63270331f3749fdcd._comment |   25 +
 ..._e0b4616c25405fa3c496f7e85800ac43._comment |    9 +
 ..._053666d256e26803b911d68622257cd5._comment |   11 +
 ..._f28528c9b9766fe8e2d344e5f27ade65._comment |   19 +
 ..._e6b854d4625ae3015aea9c5de71a28ef._comment |    8 +
 ..._4f848771e60c38321a97361b0d1b33dd._comment |    8 +
 ..._a07abdd1dc21a69ad6be0526edaeffc1._comment |   13 +
 ..._2ba5992c32753ed03ddd5c12264e9acf._comment |    8 +
 ..._5fd749f92343079b3916a4d32ddf39c7._comment |   12 +
 ..._4abe6aa966feea4e1881f6a2fbe7a007._comment |    8 +
 ..._f3ea42dc6699275143ba44e7f57e7d5e._comment |   15 +
 ..._1bad17001364d192e0d9affe5f0ea554._comment |   12 +
 ..._07ae4582a4403b4f0185dbc1830642ad._comment |   54 +
 ...ays_showing_annexed_files_as_modified.mdwn |   33 +
 ..._b6e8f634187d1f5840641633cb82301a._comment |    7 +
 ..._ab24dacf101a1a7e33e5976f72f6fe05._comment |   25 +
 ..._cade18a9487c583329249c2d3e72ca46._comment |    7 +
 ..._1d2281f79cd0c2a1a3599cae42df0187._comment |    8 +
 ..._5f2f2275ee9de47273671a8009217fb9._comment |   10 +
 ..._54155343eef8c6f95574dffb3910fc61._comment |   46 +
 ..._cbf7035b218566a9fa1cb656290a9cf0._comment |    9 +
 ...ex_syncing_speed__44___possible__63__.mdwn |   21 +
 ..._8aa224b3016dc38e4cea8ee1865a3ab6._comment |   12 +
 ...__58___smudgeToFile_and_cleanFromFile.mdwn |    7 +
 ..._f21dc5255ce986ef0317503ebd40b4f5._comment |   27 +
 ..._4ded2a4b866102450ef96c76b7be94fe._comment |   15 +
 ..._____40__bitbucket__44___github__41__.mdwn |    1 +
 ..._8a6de753ac0aa56f470b2aefca628388._comment |   10 +
 doc/forum/Git_repos_in_git_annex__63__.mdwn   |    7 +
 ..._8aaa0d83e8fcd5997f6b0097f3b21622._comment |   14 +
 ..._8546341a561a5f55216c2f437f8ec0c2._comment |   32 +
 ..._88e37911a0280d817559b2d51ddb1d4e._comment |   10 +
 .../Git_repositories_in_the_annex__63__.mdwn  |    5 +
 .../Github_pull_request_with_git-annex.mdwn   |   11 +
 ..._03023d2fba47e84d03573d996e8366cf._comment |   22 +
 doc/forum/Gitolite_problems.mdwn              |   11 +
 ..._3a41f9b6bddc060b1fa9e35b9ce8b55f._comment |   10 +
 ..._ef156bf7a1e17496c5fc1f592d45f2ad._comment |    9 +
 doc/forum/HTTP_uploads.mdwn                   |  133 +
 ..._e22213816c53e6e3555532c452eceb49._comment |   41 +
 ..._d99641f1908073724f45dc3b170f3794._comment |   11 +
 .../Handling_a_large_number_of_files.mdwn     |    3 +
 ..._33d2e19fbfdf5a0bfb7b4fbc840824a2._comment |   13 +
 ..._a46bde96e3be5a105eb1c87bf637f8b6._comment |    7 +
 ..._c6564d8cfc217c5b70b2a7a8fe60039b._comment |    9 +
 ..._f9e25d63417d0354de158c47235cb3be._comment |   20 +
 ...ndling_merge_conflicts_in_direct_mode.mdwn |   27 +
 ..._7046393b0c4329466a0d6803b718f786._comment |   14 +
 ...ndling_permissions_in_a_shared_folder.mdwn |   17 +
 ..._220b33912339f06fbc9f6c9fbe1a4756._comment |   11 +
 ..._f0d010731ad51bf8512e5ff93864fb53._comment |    8 +
 ..._9ceff336ab112ada10db1f22436dee43._comment |    8 +
 ..._9ce6d042fc1826d814f8362ae2716251._comment |    9 +
 ...ial_remote_when_content_changes__63__.mdwn |   19 +
 ..._05ee6a1b1943ef3c90634e52233bde1c._comment |   12 +
 ..._48d82e391812d8ec0d4e6562d0607fe7._comment |   10 +
 ...stead_of_symlinks_in_locked+thin_mode.mdwn |   25 +
 ..._ae978190d2d4fc1c4cdadc8256e6ca3d._comment |   27 +
 ..._6498a44801996cc5a412558c75f6157e._comment |   44 +
 ..._4bd03153c8ad61596ba55b719ad287ee._comment |   12 +
 .../Hashes_instead_of_content_in_files.mdwn   |    1 +
 ..._800d875c0d980614792207641cedb3ea._comment |   11 +
 ..._a111296eecf7d69ff30f6a82e9f1e6d4._comment |    7 +
 ..._574964b83563df3afea9049754b1cfa2._comment |    7 +
 ..._67733580e8f8806b5036406e6712b6a1._comment |    8 +
 doc/forum/Help_Windows_walkthrough.mdwn       |  177 +
 ..._5fc22393a1b28235eabb2871ad83d0a7._comment |   12 +
 doc/forum/Help_fixing_S3_mistake.mdwn         |    7 +
 ..._dc60d08da4c0b90705b0b88b4c834f05._comment |    9 +
 ..._f105714b9bac7f45fdcb9a47e77255ac._comment |   24 +
 ..._a00bca3b6b0d7b6c20ca1ca749c93469._comment |   16 +
 ..._34333d0f3eeaf2929089535632759ba1._comment |   11 +
 ..._7060bcd3424caab3570dcc7cbd3df93e._comment |   12 +
 doc/forum/Help_on_my_usecase.mdwn             |   22 +
 ..._a35b35c7927640f21d47c3df4f91dabb._comment |   12 +
 ...lp_with_assistant_and_Adobe_Lightroom.mdwn |    3 +
 ..._3adf9f5c60558b3c70a8aa041dbbe966._comment |   13 +
 doc/forum/Help_with_get.mdwn                  |    1 +
 ..._439c7562d94a969fd841cc44628abedd._comment |    9 +
 ..._137f89ea9c381cdbf57da78308a46078._comment |    8 +
 ..._f523e44daca53b3d99350e0d3f7a8874._comment |   16 +
 ..._863d03a8e52335d8a210320d8a02c553._comment |   15 +
 ..._92e48d21fd83c0f7e69a5bb7b4c4f4ee._comment |    8 +
 ...Help_with_git-annex_and_controlmaster.mdwn |   42 +
 ..._2742e65d9faebab80bc5fa0877ef7d29._comment |    8 +
 ..._5e57d563d351cc8c850c9cc4726ad23b._comment |   23 +
 ..._4fe0973f6b7f912e2e4163ebf5dfc5d4._comment |    8 +
 ..._51312d1662d0794e4258551c59877434._comment |   10 +
 ..._0b4e2314c23df5eda18661c245f9f057._comment |   11 +
 .../Help_with_syncing_file_contents.mdwn      |   68 +
 ..._7ec34de3140983739080115c82966bf5._comment |   18 +
 ..._7dba58d3c62d6f64a270298e4e4329a4._comment |   10 +
 ..._b26cfa20dc81517d93e760f4809bdc24._comment |   12 +
 doc/forum/HowTo_Conflict_Resolution.mdwn      |   66 +
 ..._81c06a0590ee828749b8d07e008028bb._comment |   19 +
 ..._e0ec78f09e5aba83ad3a7252695e4d96._comment |   16 +
 ..._495aea6e73fd7a2d7a387f539496ac3a._comment |   16 +
 ..._b209d4527bec4620e1014fe759cbdde7._comment |   14 +
 ..._446186626e5b2d08d078e3b48be06bfa._comment |    9 +
 ..._83cafddb480fa9e5b5d87d27b994b2bc._comment |    7 +
 ...ow_To_Permanently_Delete_a_File__63__.mdwn |   13 +
 ..._7f2cefb0991789be5a960eb9c0a9df3f._comment |   22 +
 ..._d13b456c5b3990082c16e78a50f5db91._comment |   14 +
 ..._854c17ff8cb38486c4bef618d1e94919._comment |   24 +
 ..._9572ad02bbf6845b1ab6d7c612c12a2a._comment |   19 +
 ..._9c28faabb7d7bd1e83d551e2938d3532._comment |   14 +
 ...le_handling_the_v8_repo_upgrade__63__.mdwn |   13 +
 ..._30fb300ec5dbdb166f2bb979c6f2ee78._comment |    8 +
 ..._23cfa4b9abe96e4477f06c5271b706b2._comment |   23 +
 ..._b05a8c63d2594290769aeeaabc91f491._comment |   11 +
 ..._and_still_be_reliable_and_fast__63__.mdwn |    8 +
 ..._99e7e1b178bbb17fffea0892538d4049._comment |    9 +
 ..._6a7a3c372599eed7c52d5f54e5287577._comment |   18 +
 ..._cc62f722b3e1db7d75d6976ef3854f94._comment |    7 +
 ..._given_file_is___34__used__34____63__.mdwn |   25 +
 ..._30217e593a04cefa30619025d0a58108._comment |   15 +
 ..._6793035e1c0fb329b3094bf66a982fa3._comment |   18 +
 ..._7cc944d96f4620e98fe22a554684ad22._comment |   12 +
 ..._8323e9160d81a4a65f2ca545c4469869._comment |    8 +
 ..._a74ece6acb2184c4990b434d7357ea00._comment |    7 +
 ...can_I_recover_from_misadventure__63__.mdwn |   10 +
 ..._1e8ce32e1e8adf32acf7af28c7ab0d0b._comment |   10 +
 ..._94f5435529802ea9d1980ee07025c6eb._comment |   36 +
 ..._484fc154c68ba59939aae4452c663ce6._comment |   18 +
 ...in_directory_that_have_content__63___.mdwn |    6 +
 ..._e897d8fc10474cf865279dc22f22ecb7._comment |   10 +
 ..._3af326205db6ee04f2a8644baa1dd566._comment |    8 +
 ...ackup_my_data_to_blue_ray_disks__63__.mdwn |    1 +
 ..._ea2f6ca0768c55fa136606cf091471cd._comment |   25 +
 ..._d79387905af9f8dce77f9aa85f2d6a03._comment |    8 +
 ..._Android_git-annex_installation__63__.mdwn |    1 +
 ..._e14757c2c106770c2d7069ace4987b3b._comment |    8 +
 ...ow_do_I_do_with_.gitrefs__47_____63__.mdwn |    1 +
 ..._5e235af2ea13fd4f6a226c842f69965e._comment |    8 +
 ..._50d0c643537175b514d5eae604fb5bea._comment |   51 +
 ..._3d342c32b14c7edbece596ba970a8415._comment |   10 +
 ...dropunused_with_an_rsync_remote__63__.mdwn |    3 +
 ..._8db3cb5348b845eb99c2c829957db9ea._comment |    8 +
 ..._6cc909d9d74bc1ccb8a7b0d7d234c7cd._comment |   10 +
 ..._f24d678e4192a70322aa164ed9b71fc8._comment |    8 +
 ..._9233decd0aaf9211447f36e0d9346445._comment |   15 +
 ..._e1deb110f752e5495d5c77ec444abac5._comment |    8 +
 ..._get_rid_of_a_wrong_remote_uuid__63__.mdwn |   16 +
 ..._b3c215cedba51fb47992ef10c60d6acc._comment |    8 +
 ..._85415e1fceb737919cc1cd9f37242458._comment |   10 +
 ..._fb3a591dc60182f7922fc2b5c24f50f1._comment |   11 +
 ..._aed0be32e579c7a39c63aa7e3ec5f67b._comment |   29 +
 ..._0c9a6c8a92d6c6e04ae3a8349b799c60._comment |   22 +
 ..._not_present_in_the_local_annex__63__.mdwn |    2 +
 ..._005e9254a1239164df34ab5fbf2115a8._comment |   27 +
 ..._f376604560c36a0aa5afa4619797b396._comment |    9 +
 ..._1ed5e10e51078a0aa7e6968ef48687a3._comment |   10 +
 ...w_do_I_list_links_with_0_copies__63__.mdwn |    5 +
 ..._ee222f0e227f1c65f84f73af399239e5._comment |   10 +
 ..._1528b3c96d6ad5637c2fdda33057c12f._comment |   10 +
 ..._e629a5393e56755a42581be9f6942adb._comment |   12 +
 ..._61a441f83ef690da8e799b0503526c47._comment |   14 +
 ..._66def7cfeef20866eb3caced831b0d3e._comment |   10 +
 ...ack_to_specific_commit_with_git_annex.mdwn |    8 +
 ..._ab8896c4f0e20fb351477e3dc92a35d8._comment |    8 +
 ..._8f02d0c400d22866e38cc521dd55b2c2._comment |   17 +
 ..._1b84261a9e6389bcad1766b82add4930._comment |   52 +
 ..._577f586843c1d7e54d115796988f912d._comment |   15 +
 ..._do_I_set_up_git_annex_with_nextcloud.mdwn |   10 +
 ..._2528e595b04232de60571279ded4c2e8._comment |    8 +
 ..._562dbc96302644f915a0b8e33428c69a._comment |    8 +
 ..._7fa312e85acd3f9afbfd97d46057e6db._comment |    7 +
 ..._7980af82df895cdd4b5c527bbb2f4c72._comment |    7 +
 ..._1fe66285d3369da85c08d8c69ad9746a._comment |    7 +
 ...ync_files_from_mobile_to_a_repo__63__.mdwn |   13 +
 ..._fc914b5998a09943fc8c1917a0e36096._comment |    8 +
 ..._fd5257eff7f94971557c031a94ac2766._comment |    8 +
 ..._5a11c45f92bae1328a5120945bee1fa0._comment |   36 +
 ..._404a8f9daa86c20a046b4c9f9051dfc0._comment |   16 +
 ..._3dcdaef370d0df38e7285f1fa11c6bb3._comment |    8 +
 ...now_when_something_fails_a_fsck__63__.mdwn |    4 +
 ..._1c14981916dd55376d5e9f95023556cb._comment |   32 +
 ...url_on_external_special_remotes__63__.mdwn |   72 +
 ..._3ee29c9b0239af732d3734855417dd5a._comment |   14 +
 ...rent_OSes_with_regards_to_UTF-8__63__.mdwn |    4 +
 ..._f4b439f7d9ce20d4b5dc8d728cb2e180._comment |   13 +
 ..._7393a4b2e94f9d36c3c9ca977a8f67b6._comment |    8 +
 ..._a38e2bbe229cb7e1f4f334bd93d91656._comment |    8 +
 .../How_does_git_annex_handle_swp_files.mdwn  |    1 +
 ..._8f0b81139fb66f28f9262e919692ecbd._comment |    7 +
 ...ex_assistant__39__s_web_browser__63__.mdwn |    7 +
 ..._f4402eabda2327da3a0bbc64ed3baf9a._comment |   12 +
 ..._cdb41f2c7b6bc5bf40d88582dcbf45aa._comment |   10 +
 ..._ca75e928c245eb23a02b5f40ec69cbb1._comment |    8 +
 ..._1635f136909711295b9b70d1255e0378._comment |   11 +
 ..._ee0cbe9498c518de98480a2ad229f685._comment |   10 +
 ..._799b9d9d3ffbc2c14eca8d442e2aff8c._comment |   11 +
 ..._71ff45948487e9ac8de809a5ccc3d874._comment |   29 +
 ...ge_the_number_of_simultaneous_uploads.mdwn |    3 +
 ..._d5559994ee45a5c185a55c9a4d824aa4._comment |   12 +
 ...exing_a_file_with___34__git_add__34__.mdwn |   14 +
 ..._68ed73d8898bf2ce0a14e0e5909cc64b._comment |   24 +
 ..._176a92a6ce5d8f356dafc29021242b2d._comment |    8 +
 ..._0cdd9683709d55bb7340fb41fef265fa._comment |   11 +
 ..._to_add_dotfiles_in_direct_mode__63__.mdwn |    6 +
 ..._d62d4b9ae5f1ec825fc58090689f7571._comment |   16 +
 ..._c7269cde1db02069149268b6c6a50786._comment |   13 +
 ...low_clones_to_get_files_via_URL__63__.mdwn |   52 +
 doc/forum/How_to_cancel_an_add__63__.mdwn     |    5 +
 ..._f768ce5dc7c76f96ee6eb352f167be44._comment |    8 +
 ...change_the_name_of_a_repo_on_S3__63__.mdwn |    2 +
 ..._be74d63e1951f515948d232e096b4862._comment |    8 +
 ..._d54a7163cfe9a94b7ba337860958e5c5._comment |    8 +
 ...king_of_a_deleted_file_in_direct_mode.mdwn |    7 +
 ..._c6bd2ef90516dde928ff18ded36df625._comment |    8 +
 ...7__ssh_backend_to_other_backend__63__.mdwn |   14 +
 ..._7973928b1aa9e0fcfeb6bf80885441f5._comment |   10 +
 ...th_renamed_files_in_direct_mode__63__.mdwn |    3 +
 ..._fe38fedbbc9e4a9e13bf19950e63c7ac._comment |   10 +
 .../How_to_deal_with_spotlight_and_macOS.mdwn |   21 +
 ..._3d76fbb8f13bd66d729819a4d037ab4f._comment |   26 +
 doc/forum/How_to_debug_failing_sync.mdwn      |    5 +
 ..._a597b868182e55e5f39394f154740534._comment |   10 +
 ..._db0a5652d76e4e568a4d7808195bc59c._comment |   10 +
 ...to_define_a_balanced_prefered_content.mdwn |    5 +
 ..._d4c94791a5fc7d2e618a7e11bc5db569._comment |    8 +
 ...url_for_a_git_remote_repository__63__.mdwn |    7 +
 ..._52918b5ec25e55837215439fe1bb1a14._comment |    8 +
 ..._3a1567c9f484b5e12e5560cdcc2cfddd._comment |    8 +
 ..._48c3a80c14a85f27d742482b2ccbe628._comment |    8 +
 ...to_delete_a_file_in_direct_mode__63__.mdwn |   31 +
 ..._995f3b8cf511921719774f8911e24907._comment |   15 +
 doc/forum/How_to_delete_a_remote__63__.mdwn   |    1 +
 ..._8cba186bb67079ff41bf6d0b04613f4a._comment |   10 +
 ..._33c429ffa7e9e2ed9c5fac760ee8e82c._comment |   12 +
 ..._e9c5508092ca2983f458b16bf1e07082._comment |   14 +
 ..._688a8473d074830303133ba939438084._comment |   12 +
 ..._de7dff2dc4357d8cc617d86a06e35b1b._comment |    8 +
 ...tes_with_git_annex_assistant_and_ext4.mdwn |   28 +
 ..._42ca6cfbbb79fe63514805b8119ac16b._comment |    8 +
 ..._c94ce6a9767c624e2445a7d9eea40396._comment |   29 +
 ..._bcda51053b62bbb20ce71a59469e1b26._comment |   10 +
 ..._48e5b9eae920e5f13812de8d6f6bc640._comment |    8 +
 ..._787c0bfdc1d309db1486c3a37723a957._comment |   13 +
 ..._8894beb06443f234e9200b03b5f3badf._comment |    8 +
 ..._457f62ee3e58f68a55f66c5bde6002fd._comment |   10 +
 ..._bd2b412116a66107bc0ff0efd7e39a58._comment |   10 +
 ...ay_sync__34__s_in_a_direct_repo__63__.mdwn |    9 +
 ..._c5226964b4b64bd47d888b5616ff970b._comment |   22 +
 ..._748d243bac14a8d55be4ac324c581c1d._comment |   62 +
 ..._cf9234339bad14ad9a9d3027f9066936._comment |   49 +
 ..._d899cf35801636e618e4675d91d6104a._comment |   24 +
 ..._of_files_that_have_been_edited__63__.mdwn |    7 +
 ..._dccf4dc4483d08e5e2936b2cadeafeaf._comment |    8 +
 ..._5710294c1c8652c12b6df2233255a45e._comment |    8 +
 ...that_I_know_have_been_backed_up__63__.mdwn |    9 +
 ..._8332f71241335a31e270407477bd84f3._comment |   18 +
 ..._984286a35ec828f1e8dda928ea577571._comment |   35 +
 ..._29f6f9df1ad22113e9690b0d1da36ba0._comment |   13 +
 ..._43549b3d231f52cf53a66c477c34a708._comment |   15 +
 ..._94aca10f84783f35d927dbefbeba263a._comment |   16 +
 ...if_assistant_is_still_repairing__63__.mdwn |    1 +
 ..._9dd192a8e0bfa9e533b22070b87792af._comment |    7 +
 ...ransfer_already_in_progress__44___or_.mdwn |    7 +
 ..._345a7439720e8dc2cc6cb5eed6bcf73f._comment |   30 +
 ..._55ad844ee650a6a5026fdf5764dd9470._comment |   11 +
 doc/forum/How_to_fix_bad_merge.mdwn           |    7 +
 ..._4a32a727560ab85203d1dd76feff2e1e._comment |   10 +
 ...t_keys_that_get_can__39__t_find__63__.mdwn |   22 +
 ..._5962c2c7b3a668429a62f7bede990801._comment |    8 +
 ..._f84a8e545da95e72b3e2b03a782335ce._comment |    8 +
 ..._74f14ae50e37d94fbd2950924a7bee28._comment |   10 +
 ..._ee99cdb44671eea30eaa4351dbb9dc96._comment |   15 +
 ..._d0d7674589574ae92e2595d23d000f61._comment |    8 +
 ..._information_on_special_remotes__63__.mdwn |    1 +
 ..._f1eca38ca0c1edb66e64ac64f0321829._comment |    8 +
 ..._73f8b7ebde5870f92bec02d15a533ef3._comment |    7 +
 ...rypted_name_from_special_remote__63__.mdwn |    1 +
 ..._47ce17796de422fe996f45083a6b79b0._comment |   13 +
 ...et_git-annex_to_forget_a_commit__63__.mdwn |   54 +
 ..._65471c42e163ac8ee6ec109f1397271b._comment |   12 +
 ..._cc991abd9155a8e4d935b04ba432744f._comment |    8 +
 .../How_to_handle_cold_storage__63__.mdwn     |    7 +
 ..._ff49a65d4adaff3cf3902c2850227ea2._comment |   16 +
 ..._to_handle_the_git-annex_branch__63__.mdwn |    5 +
 ..._800bd55b322e72f229882d7fd3888b14._comment |    8 +
 doc/forum/How_to_hide_broken_symlinks.mdwn    |   45 +
 ..._07a70090a9ac8f675233b08b24f55544._comment |   22 +
 ..._011f6b97b1eaee1ae513a4a0e445d105._comment |   12 +
 ..._e3606aa746f516fc771d5d9bf93d70af._comment |    7 +
 ..._c6e3ef3ba5f6e9e54d998bcbe3035650._comment |    8 +
 ..._1ed5e10e51078a0aa7e6968ef48687a3._comment |   10 +
 ...prove_performance_with_v6_repos__63__.mdwn |    3 +
 ..._56e0fead15a88ea12262e6091972c6d6._comment |    7 +
 ..._93a6a0779f52bdd3de6e4d2500cfd223._comment |   10 +
 ...ep_connected_files_with_another__63__.mdwn |    5 +
 ..._89e04a7dc25a3df849aa2ada4dbc8439._comment |   14 +
 ..._20e8dba904eff7cc8f72ee12b8119632._comment |   17 +
 ..._7b14aa71a166cf14e852ae896b05ee74._comment |   10 +
 ..._a33437b28ea7fc74eb221d90efaec487._comment |   10 +
 ...ading_a_file_to_a_transfer_repository.mdwn |    3 +
 ..._17db96492e6bc0e243fc7cb62565c4c4._comment |   17 +
 ..._e772ea0383ac690cbcbcf125258986cf._comment |   16 +
 ...ist_all_existing_metadata_types__63__.mdwn |   15 +
 ..._a8c30f697f32a3807661a59482d79b18._comment |   19 +
 ...n_releases_work_with_git_annex___63__.mdwn |    5 +
 ..._9298aa55771b68873de02e6a7964bbdc._comment |    8 +
 .../How_to_make_a_server_store_the_files.mdwn |    1 +
 ..._20196067475918e788afa0debc4d5ce5._comment |    9 +
 ..._to_make_this_workflow_possible__63__.mdwn |   22 +
 ..._38d7c0531d68803b1d7910c598aab38c._comment |   35 +
 ...in_the_same_repo_without_unlocking_it.mdwn |    1 +
 ..._a272d179a77682e8c64bd4fc20cddee0._comment |   10 +
 .../How_to_organise_backup_to_S3__63__.mdwn   |   10 +
 ..._13c6421a3637e30193dc77b54dec4b8d._comment |   11 +
 ..._e0ae05276ef7e1dcb21ef0986b6f7531._comment |   16 +
 ..._7697112a04cdc9a53551257d71143eb5._comment |    8 +
 .../How_to_overwrite_local_changes__63__.mdwn |    7 +
 ..._1753d8c7a0daf04b64d639567a349190._comment |   20 +
 ...play_a_video_from_WSL2_on_Windows_VLC.mdwn |   17 +
 ..._4b2b04e4cd61d08dfa44b2cc86023ba2._comment |   10 +
 ..._single_device_and_use_only_hardlinks.mdwn |   13 +
 ..._b59a72142e8f752d7b68a63a6ac1bbfe._comment |   10 +
 ..._e4bfea21f664a0cb1aa8ec18ee88fc50._comment |   11 +
 ..._ee247d9316df963fd584df2199b80fe2._comment |   12 +
 ..._51548724d72e2cc6cb2c6e8c3b82e3e4._comment |   13 +
 ...stant_from_downloading_all_data__63__.mdwn |    9 +
 ..._fd8b287758ad77b3527ae71017cffabf._comment |    8 +
 ..._e8e75b4451aaf55461edf2f3d68797ed._comment |    8 +
 ...over_from_failed_branch_updates__63__.mdwn |   28 +
 ..._f296d4870a6fdef5c57bc8bb1a1e0474._comment |   11 +
 ..._0edc7239488f78345f9e624ef210ebac._comment |   25 +
 ..._for_an_external_special_remote__63__.mdwn |   11 +
 ..._6dd92d0737b72b927fc6b82636084c54._comment |   13 +
 ..._789445dff9a5905ed105ac344f6949ad._comment |   12 +
 ..._93e91e2ab98c35d4cb6082eea01b6abc._comment |    8 +
 ..._64c0d3c061ff463f9ce16b52d2a70a1f._comment |   16 +
 ..._d1c47c1a2f9b4dd570c0ebd9fbd1ad8b._comment |   10 +
 ..._e0753fef2b93ae5a114894dbdc014ec4._comment |   14 +
 .../How_to_remove_annex_on_osx__63__.mdwn     |    5 +
 ..._18fc46bdb5bc44916e355a9900e9c0d1._comment |   10 +
 doc/forum/How_to_rename_a_remote__63__.mdwn   |    1 +
 ..._a9bfbd82f7bb47661f0d9e0e0d904332._comment |   28 +
 ...nterrupted_merge_in_direct_mode__63__.mdwn |   65 +
 ..._8e2a14842b44844f90c80b862a1b3a6d._comment |   10 +
 ..._031ab6b5a2765ed9e2b185b24a8cbd78._comment |    8 +
 ..._93f20519483837c59a75821621e22dee._comment |   10 +
 doc/forum/How_to_restore_symlinks.mdwn        |    1 +
 ..._c67e752cf7d5431096fab4b3304790a7._comment |   11 +
 ..._f9ec6096595e2c149c48924e3b54542f._comment |   14 +
 ..._4ff80729787a2a4e2baf05dd1db37da3._comment |   12 +
 ...ly_annex_a_file_already_in_a_git_repo.mdwn |    5 +
 doc/forum/How_to_revert_metadata_changes.mdwn |   25 +
 ..._de40f1a3f364ca6d2f9bb489f4d64cb3._comment |   39 +
 ...w_to_see_what_will_go_to_annex_vs_git.mdwn |   10 +
 ..._d26ea587da51a6f663d64ebb19976a2b._comment |    8 +
 ..._316becb188245c1fbbe6daa63505bc34._comment |   14 +
 ..._93f3bc4f8e9e2aeef4e417bba2041ee4._comment |   24 +
 ..._558abc4b928649ff3b199a7154c052bf._comment |    8 +
 ..._ce998d6fc7868a2f129bad755d04b186._comment |   11 +
 ..._based_on_file_size_in_.gitattributes.mdwn |   16 +
 ..._c8ac6b924d4446d4a1a12fb34532fd69._comment |    8 +
 ..._one_shared_transfer_repository__63__.mdwn |   15 +
 ..._bedaf308cfc70b9e751914a400ebcbc2._comment |   10 +
 ..._d665b1514253c8aa487ebf8b2728e3b1._comment |   10 +
 ..._aef42387a3673ab6710fb23e878d7e17._comment |   10 +
 ..._bfbcc041db472f4808979e6b3d7c4be2._comment |   10 +
 .../How_to_shrink_transfer_repo__63__.mdwn    |   27 +
 ..._6b110311f4c147dc315c4f610cf56afa._comment |   19 +
 ..._8e596cd606935d82bd6604f5c9c500a2._comment |   21 +
 ..._c536a946b717e9bdcb883b58cd0336ae._comment |    7 +
 ...tories_handled_by_the_assistant__63__.mdwn |   40 +
 ..._1c913395f076ee203caaab057da8afbe._comment |   13 +
 ..._081793c52bf15c74a7f48a67c49ff818._comment |   12 +
 ..._f8e0376beb486cf8ce52384ff511ecf2._comment |   11 +
 ..._from_a___39__full_backup__39____63__.mdwn |    4 +
 ..._c4e972c8635f2fa460cd6621f3d993c6._comment |   23 +
 ..._e06abc9a2f7cf055523f3d35e4eed9bc._comment |   11 +
 ..._81d128be0fa60475062e795f34d920f7._comment |    9 +
 ..._43615e11f1c6d08f5850458d540f5bac._comment |    9 +
 ..._sync_without_enumerating_files__63__.mdwn |    7 +
 ..._ad78c67ae1bb4dc8ed800779c0298158._comment |   16 +
 ...o_use_--jobs__61__10_by_default__63__.mdwn |    1 +
 ..._3c47ad3f0c17e475ea42438a42085f9c._comment |   13 +
 ..._progress_of_in-progress_upload__63__.mdwn |   17 +
 ..._794cc9bdf728c96dd7c50cf402573cf5._comment |   11 +
 ..._6347e08b599239b6416957e9a7114157._comment |    9 +
 ...rk_with_transfer_repos_manually__63__.mdwn |   18 +
 ..._3dec369405e6b6a4a6e5121546c03712._comment |   11 +
 ..._b8f3c09b470d99578a4a17064498dd39._comment |   12 +
 ..._be2c594bc1d162cfb1acc3a01fc284f2._comment |    7 +
 .../Howto_remove_a_repository__63__.mdwn      |    4 +
 ..._b55fa4e92bb457ecaa5ca8f5cee7be1d._comment |    8 +
 doc/forum/Howto_remove_unused_files.mdwn      |   31 +
 ..._f2a7948268ce3cb3967a9fdd8ccc570a._comment |   16 +
 ..._9b4d198c2d8a52adef3d166a8196fc0d._comment |    8 +
 ..._441d10901d5c055ac3ed2a6cb61c075c._comment |    8 +
 ...ifferent_directories_of_same_machines.mdwn |  127 +
 ..._445766c0f646e9cb5b45b863ad87e85a._comment |  136 +
 ..._b3953f30fb817ee3753f888a871de51f._comment |   12 +
 ...yncing_back_and_forth_creates_commits.mdwn |    7 +
 ..._e6a60889876bd49855fe60849db147ef._comment |    8 +
 ..._1053e88c417e8b46648f645a466145e2._comment |    9 +
 ..._577f62d506a66770e746a50fc103901d._comment |  110 +
 ..._0079c41305493873521d3af45075a2c4._comment |  277 +
 ..._4879d44cc69022a71fc8baf8f31a890f._comment |  175 +
 doc/forum/Ignoring_folders__63__.mdwn         |    1 +
 ..._5fbf4d1ae75434118876470b04e2fd72._comment |    7 +
 ..._1adafdf1fddf8e1256e51b0f56d3a89e._comment |    8 +
 ...remotes__41___from_another_repo__63__.mdwn |    3 +
 ..._32586d9e43dc0c5d0a9e94671586f763._comment |    9 +
 doc/forum/Import_existing_files.mdwn          |   17 +
 ..._890dea22857d0a38260009602ccf0ec6._comment |   14 +
 ..._362ce3b030970db82c8dd0d98791186b._comment |   35 +
 ..._69188f669e6fe5ca1a8c34c3dc3ec201._comment |   20 +
 ..._9c7677838ad28d540a2a514d718f9f1d._comment |   13 +
 ..._d88cedb3d70342071621c1695c8aeb05._comment |   34 +
 ..._be5331f1203b9610259a84c783b429b0._comment |   21 +
 doc/forum/Import_options.mdwn                 |   14 +
 ..._118a5f978090a3909299876a01c0adec._comment |   21 +
 ..._21da91f08cb6b28ae3e79ade033db516._comment |   17 +
 doc/forum/Improving_the_git-annex_forum.mdwn  |   23 +
 ..._63c52c977689a5da34fec65391c25fd6._comment |   34 +
 ..._7b4b8d78148f41df332d8f9125ca9842._comment |   15 +
 ..._71d5568d2ac64f83dba11100124addd1._comment |   30 +
 ..._847be68ea1992e6c2ceb2c79cfb65f5f._comment |    8 +
 ...al_remote_with_already_existing_files.mdwn |   17 +
 ..._f2a2f7309145d26d124c73ce6fcb32a5._comment |   26 +
 ..._c1740ce07be483d198880f5844fea7e0._comment |   52 +
 ...al_macOS_setup_between_two_local_Macs.mdwn |   32 +
 ...l_git_annex_v6_in_Ubuntu_14.04_Trusty.mdwn |    1 +
 ..._9c715cbb0550cad29402dd2fca1917f9._comment |   13 +
 doc/forum/Install_without_root__63__.mdwn     |    3 +
 ..._097bbbde8a91e1d0cee9da6cba23ae5c._comment |    8 +
 ..._891cd24fb0806ae9087cd83d22d8ce6e._comment |   10 +
 ..._23fe7b46c6f48072618f05c1368a8917._comment |    8 +
 ..._f015ab0bfed0b440b915c233be73c316._comment |    8 +
 ...nnex_get_into_git_checkout_with_hooks.mdwn |    7 +
 ..._7258d0203a0578d0f4e0221295511237._comment |   13 +
 ..._9ca7b7dfc039c443c4afa9b6ea7c78bd._comment |   15 +
 ...nex_with_Windows_Git_Extensions__63__.mdwn |   10 +
 ..._2dac6e3ccf559d98f74c456c0ca7aafc._comment |    8 +
 ..._181c6c87c64e4fbe798c108537c6a597._comment |   12 +
 doc/forum/Invalid_cross-device_link.mdwn      |    9 +
 ..._46c35e04c8f8cb7205f08aa71cc4912a._comment |   15 +
 ...e__63___Questions_about_the_long_term.mdwn |   20 +
 ..._9984f65d6e89f0f88b33cbd499e859eb._comment |    9 +
 ..._d7bdfeb33bac7f139b0bdc1c6fb53237._comment |   10 +
 ..._7dc224cb0b88bf07879e03717efffa17._comment |    8 +
 ..._a538f8a4272b5ce134607dc7201e3f04._comment |    9 +
 ...s__34___storage_class_supported__63__.mdwn |    1 +
 ..._ddc2a1f2b1d810a40b459896993d2e8d._comment |   11 +
 ...nup__96___by_default_a_bad_idea__63__.mdwn |    3 +
 ..._51e5f78a1cbd37598f3f0f6746df7320._comment |   17 +
 ...de_of_the_object_directory_safe__63__.mdwn |    9 +
 ..._c25900b9d2d62cc0b8c77150bcfebadf._comment |   13 +
 ...state_before_the_initial_commit__63__.mdwn |   18 +
 ..._f9decde3955f10148febc4646fba5a68._comment |   12 +
 ..._ed32a48edce4f150bedf24cfe91de254._comment |    8 +
 ..._ef9618850e5e688bac3c646983f00ed8._comment |   10 +
 ..._4bf460c5826c36b205e418c4f3f7d770._comment |   15 +
 ...me_parts_of__41___the_git_annex_tools.mdwn |   12 +
 ..._5c593876993bef4dfaa052278a3ba5be._comment |    8 +
 ..._02ecc1b9f370f6bba84dd598030e0fcd._comment |   24 +
 ..._7d9d45716e9e847f3bde214949796222._comment |   20 +
 ..._ba3422afc8ae83bd822616cc1a99a5b9._comment |   10 +
 ..._d8c402765b3a5896db91605f43149001._comment |   38 +
 ..._2d78e647a46cfbb002cf66e6318043ab._comment |   10 +
 ...ible_to_cherry_pick_from_a_repo__63__.mdwn |    5 +
 ..._82efe5c0b37fdcb31b6a4ca62b66123f._comment |   17 +
 ...42__dont__42___have_a_field_set__63__.mdwn |    3 +
 ..._f452c911b24ba40aef3be5bdaac9f9ee._comment |   11 +
 ..._7373ec002ca78f4f382ef9297f39639e._comment |    8 +
 ..._cda315119bd3ccce74bc3df8dd56bf1a._comment |   22 +
 ...e_git-sync_not_nullify_symlinks__63__.mdwn |   23 +
 ..._d6f2d2cdc5f4ffde9eee9f3a8c215a06._comment |   10 +
 ...etup_a_git-annex_Glacier_gatway__63__.mdwn |   25 +
 ..._a35571c77eaab5bcc0d841543a13162f._comment |   14 +
 ..._c8f185b0751ccd17a657e954cbeb2864._comment |   11 +
 ...to_push_to_checked_out_branches__63__.mdwn |   11 +
 ..._e74ddd1bf47f856369568b1fcd8d4f9c._comment |   18 +
 ..._c47c27ce283cc4fcb80949860e2a4927._comment |   23 +
 ..._47511f7b731cdefd108241bedb116f68._comment |    8 +
 ..._07a190aa19006611739cccfc5aac5a6f._comment |    9 +
 ..._different_directories_possible__63__.mdwn |   31 +
 ..._34af73f211cce966927757f7deec88eb._comment |   24 +
 ...reloadindex_safe_with_git_annex__63__.mdwn |    1 +
 ..._c250362236a33d8dc9bf5ed825318c40._comment |   23 +
 ...nex_cat-file__34___type_command__63__.mdwn |   20 +
 ..._fe3dc778b35119d3ede2d341cac7a15b._comment |   11 +
 ...assistant_configuration_attempt__63__.mdwn |   28 +
 ..._d77fbbbe3a7438a1e79f175df1f69ef3._comment |   17 +
 ...have_assistant_add_files_locked__63__.mdwn |    5 +
 ..._70c8e23c87a6c48e728a6685e7189e98._comment |    8 +
 ..._c0c6e38fe99dd273764071574c8b3c1d._comment |   13 +
 ..._c80d15f6844e29dee2bf7ba0a6d6d093._comment |    8 +
 ..._a8ebda7dd8d52e6c1137dbb646e21e5c._comment |   13 +
 ..._022f36242ef57158feab0918f41a7ff1._comment |    8 +
 ..._5527d611a132f3e9bc0d71c593abf673._comment |   20 +
 ..._92bf43545c46d302089820cfdd03141b._comment |   10 +
 ..._a6ae8bc3b5caf0d3d49a919ab5ec5778._comment |    8 +
 ..._7fcc62493d261c22149f85f48bb95efc._comment |   13 +
 ...normally_works_for_coding_files__63__.mdwn |   11 +
 ..._e30310472df6ed2928dfd63464c6bae7._comment |    8 +
 ..._f093b16307bd369399574fc651569b73._comment |   10 +
 ..._1edab7e44e7eae6d8f06a917704b17ec._comment |   12 +
 ...override_the_import_destination__63__.mdwn |    5 +
 ..._5f094cc606eebd2aeeaaa4b861cf2c21._comment |    9 +
 ...ere_a_way_to_unannex_some_file___63__.mdwn |    3 +
 ..._82095cef37dd815bcd1d101a1715e3c7._comment |   12 +
 ..._3b05e9eaa554b70594f0195dfcef831d._comment |    8 +
 ...st__39___to_NEVER_access_remote__63__.mdwn |   19 +
 ..._3760d5b8c8012405eef17e4d07cf151c._comment |   30 +
 ..._b95ce6b13ae45a2fca05260a7f77148f._comment |   19 +
 ..._1c8f023b8d7a50cfce6d3464b12e446b._comment |   17 +
 ..._f1e234e80a6873b33986bec8d51c1001._comment |    7 +
 ..._2c43830a95cd8955da20cc6dba27a9b6._comment |   10 +
 ...handling_for_file_modifications__63__.mdwn |   20 +
 ..._d901ac998c9fdb844c593d782c31cc73._comment |    9 +
 ..._e46cb391ce377c3a8eb40155a5d0f001._comment |    8 +
 .../Issues_with_IPFS_special_remote.mdwn      |    7 +
 ..._d13e439c3c242606d8b4377831e38a2b._comment |   35 +
 ..._e53b0158471605950896cafac7aac4da._comment |    7 +
 ..._74c586e5af079f0d6c42975ac294e766._comment |    8 +
 ..._283aafce5dc1735310daa8329a432002._comment |   10 +
 ..._fa017d01e9eca59074adf2224e20994b._comment |    8 +
 ..._e49c62ca2e0f0d455469d5bc4483aff3._comment |    9 +
 ..._2147808f9b15be995988e2c71bc0b271._comment |   12 +
 ..._3a34db5281419578201f5f74cf97a830._comment |   10 +
 ..._765fef6f0b5da3e5c87c029fea2362a1._comment |  128 +
 ..._edd64d315651d5c7d5e1f802b68b8b68._comment |    8 +
 ..._07b1f3c1e744e910f1738925d79e3d1a._comment |   11 +
 doc/forum/Issues_with_non-sync_workflow.mdwn  |   13 +
 ..._99f89201446005f77d9278a7a889638d._comment |   10 +
 ..._f27ec2462e5a8f6f96c6e2b7dd3f87ca._comment |   10 +
 ..._db02b002a977b57be0102d8ac7c2037f._comment |    8 +
 ..._a93d502253cf9f164fbcd23ca755db9d._comment |    8 +
 ...nt_and_gitlab_as_a_metadata_only_repo.mdwn |   63 +
 ..._b61139816f55dbc4f7eac22207f243c0._comment |   11 +
 ..._f6196f814ed388d276947ffcc92ff37c._comment |    9 +
 ..._1556ebbb2a8db4aa859e3852160df044._comment |   24 +
 ...ypeScript_API_for_git-annex_available.mdwn |   13 +
 ..._69cdea649eb79fa796fb3713dc0ac23f._comment |    7 +
 ..._would_you_guess_v6_to_be_ready__63__.mdwn |    3 +
 ..._08d3fd14a57b5d4dfb2cac411aba757f._comment |   10 +
 ..._ff5b55e81c0d48968e59e1783943f286._comment |   10 +
 ..._f63a66196db731fb04d8e078136eeb3d._comment |   10 +
 ..._a7ea99c0b8bdc257c0c3453bdb5ce1ca._comment |    8 +
 ...ybase_encrypted_git_as_a_remote__63__.mdwn |    6 +
 ..._38d868bf2e93c43091f9f337d9ec840d._comment |   10 +
 ...ebapp_on_Trisquel__47__Ubuntu_Precise.mdwn |    7 +
 ..._6bd27bd31833336c1df783253378ccae._comment |   10 +
 doc/forum/Large_Uploads_to_S3__63__.mdwn      |   12 +
 ..._c1fd2ed0b74ce58f818ab53158e581f3._comment |   26 +
 ...indows_annexes_with___42__nix_remotes.mdwn |   33 +
 ..._a38e0ecef49a81a1d2b3d2eaabab65ab._comment |   17 +
 ..._c59077a9d6500df0cd88ac5a18085085._comment |   28 +
 ..._bfc92cb2117b26eec95687950827c78b._comment |    7 +
 ...ch_between_symlinks_and_annex_objects.mdwn |   14 +
 ..._854786810dc4246cdaa38ff10c55bbca._comment |    9 +
 ..._9134154ba2ef3575c39c7848136b79a9._comment |   21 +
 .../Let_watch_selectively_annex_files.mdwn    |   27 +
 ..._8379de87d16502d9aadf252da01e4d9a._comment |   10 +
 ..._2219ff6b4dc927eb2a299cd1af90aed8._comment |    8 +
 ...ad_of_broken_link_when_possible__63__.mdwn |    4 +
 ..._ce0464d5fca6ada9f1477831fd47ce09._comment |    8 +
 ..._or_actual_files__63___Confused__33__.mdwn |   21 +
 ..._779cee2448d7070b1dd636d01296c01e._comment |    8 +
 ..._bccda88697ab7beec0b9fe9ee0230688._comment |   18 +
 ..._c2a9da3f03b55ff294dc0d2010380119._comment |    8 +
 ...ed_files_in_chronological_order__63__.mdwn |    1 +
 ..._825c950574b3a2f083554f474c9f7b50._comment |   12 +
 ...f_files_are_stored_in_annex_or_in_git.mdwn |    7 +
 ..._9206087f7320982ef26ef401d39a394f._comment |   20 +
 ..._2eeef9505e976288e7a09f31d0c09dda._comment |   12 +
 .../Local_and_remote_in_direct_mode.mdwn      |    7 +
 ..._45f89ebcb6092d1b2582feebc8a5e9d7._comment |   15 +
 ..._90eeb2bffdb2db8032f9a0eac630ed56._comment |    8 +
 ..._859ec2b3a8e938073b2099fdc5781109._comment |    8 +
 doc/forum/Locating_errors_on_fsck.mdwn        |    7 +
 ..._5a4c54b59f2a3f8519f2dab608a1e92d._comment |    8 +
 ..._0277bac79694efffba0e59706aa66c63._comment |    8 +
 ..._file_results_in_file_changed_warning.mdwn |   20 +
 ..._25a04c7345f5b626aa71524603c833ed._comment |    8 +
 ..._7146a3c69749b9b1001fffc6e7a8bcda._comment |   12 +
 ..._fd39e6ceffd9bf0709658c34945d8699._comment |   16 +
 doc/forum/Looking_at_the_webapp_on_OSX.mdwn   |   18 +
 ..._68820f2f469356633c1abb18a47e0c59._comment |   12 +
 ..._4ce86546d8a135df9cfab46b4612fa0b._comment |   23 +
 ..._6d398a2cceff14a1b774b85ee1725073._comment |   12 +
 ..._5e503787a4b1d3534c5e20da5480b763._comment |    8 +
 ..._c735841bc230efc61594ea013fc2902b._comment |    8 +
 ..._0e489fbfc89d282e9eb47f1b814ff70c._comment |    8 +
 ...sitory._Recovery_from_S3_remote__63__.mdwn |   14 +
 ..._a9028f00461ec1eddbeb699dadcbab72._comment |   12 +
 ..._0dbf6fcd15007ba66323ecf2b154ad2e._comment |   12 +
 doc/forum/Lots_of_4k_symlinks.mdwn            |   24 +
 ..._96384eaeef1d067a24678c7aa3613063._comment |   21 +
 ..._be9617e8cbc231069c44bc9f077ce673._comment |   32 +
 ..._80b3a84e6d79871bbbef13d4bc87cc37._comment |   14 +
 ..._be12d26936b3502445e880be997b8877._comment |   14 +
 ..._ab3884748f3271a77ba3320f25d74414._comment |   25 +
 ..._fa72056ee788ac0f2c15bb57d9876cf6._comment |   16 +
 ..._bd6b81815e5888c26d7a8a96e565519e._comment |   23 +
 doc/forum/Lyve_Home.mdwn                      |    6 +
 ...5E_backends_no_longer_available__63__.mdwn |    5 +
 ..._e21fa57a2f2dc4e99737877c6a48cbfe._comment |   11 +
 ..._5025d16f59f314711e49537e542b7c83._comment |    7 +
 ...ke_GA_aware_of_externally-made_copies.mdwn |   15 +
 ..._0e2edea494810a8614f628ec46b934e4._comment |    9 +
 ..._b7fcfd87efb17d5159ec49eb218fbd8e._comment |   32 +
 ..._c1d69396c7bb208b6f82f2f65a282cfb._comment |   14 +
 ..._b0d7ef111f4862d6b759cde45696a676._comment |   10 +
 .../Make_whereis_output_more_compact.mdwn     |   13 +
 ...efox_not_dereference_symlinks_on_open.mdwn |    3 +
 ..._a7b092f2291fa515279cf7dce23df20d._comment |    8 +
 ...nnexy_symlink___34__known__34____63__.mdwn |    7 +
 ..._e04edbe950a41887c4c11a226ca77dce._comment |   20 +
 ..._de77cc2bee45706c4bbe407d8846778e._comment |   13 +
 ...ng_a_public_read-write_git-annex_repo.mdwn |    9 +
 ..._8279171695a9a7a7501d5ee8c7bab66c._comment |   10 +
 ..._2cd770a12bfe3b44531b024c41570758._comment |    8 +
 ..._19694d397813fe1bb949fd3b6ae49f4b._comment |   10 +
 ..._c8b104eb34efdd7c7670f2133081d1d8._comment |   12 +
 ..._48e247fddb0d302102c74cac7f2228ff._comment |   10 +
 ...git-annex_a_self-funded_project__63__.mdwn |   10 +
 ..._4a1ba95b7231ba973ddb672d2419e28c._comment |    8 +
 ..._7c476ae92e63c991f229708678874ca2._comment |    8 +
 .../Making_git-annex_less_necessary.mdwn      |    5 +
 ..._03faaa3866778d24cd03887b85dc9954._comment |   12 +
 ..._2db02a94dffd525885c9d7fc6c5fa464._comment |   12 +
 ..._429ec656e0ac02f98843f8d7f3c02d6a._comment |   11 +
 ..._384813dd022dfd9c1ef14e0f1479a123._comment |   18 +
 ...reserve_file_name__44___and_directory.mdwn |   10 +
 ..._03a5369518a96c0550e68af520ed0060._comment |    8 +
 ..._64863e149cc62a778b006ffe2bf82d06._comment |   10 +
 ..._bbd3ea45cf560031856e9e8416b4d126._comment |    8 +
 ..._2c36e30b3e2f6874c63e03307207a6b9._comment |   11 +
 doc/forum/Malicious_autoenabled_remotes.mdwn  |    9 +
 ..._c82464f40eb1442aadd0f1e89b72f41e._comment |   42 +
 ..._37456c0a159453fa984c5a003578d1eb._comment |   21 +
 ..._608213f5d0df482b731ae1502cdd87af._comment |   20 +
 ...ead-only_medium___40__E.G._DVDs__41__.mdwn |  118 +
 ..._a061d300b718ad943c940e122cc57220._comment |   23 +
 ..._76529080054407570611b4357ce4f3ed._comment |    8 +
 ..._9acf5ce41a023f3848a51891cceeb51b._comment |   21 +
 ..._0a343a8fdad66765371ca22581b35b84._comment |   24 +
 ..._b315c50d796d73bfc35acebee1836f40._comment |   66 +
 ..._9ddd6278ea00c5594083347b5b9b8405._comment |   24 +
 ..._c3f6cb58dd2328b7af8dd2657c2e2a1e._comment |   31 +
 ..._455ab8b72c477769d68eb4348e911234._comment |   10 +
 ..._679ad639cbba7f9a4d28131219d20178._comment |   25 +
 ..._854531569edbb5c152c4d6b0d764a6c5._comment |    8 +
 ..._25e65ee3949e7d918376298cf11585f2._comment |   10 +
 ..._a80b9ce3a78fb44c9d60e877146d9e59._comment |   12 +
 ..._8a71ca048f9de29a198a6afb17d5315e._comment |   11 +
 ..._e3d1d3a3d3d831432ec940a8ab6f31e9._comment |   14 +
 ..._26a33eae98b4faaf6baf6635e3d28a8f._comment |   27 +
 ..._49ac298d39c824b0e52a239961463e09._comment |   14 +
 ..._55a4a3616ea59654da1c2f9902561e3b._comment |   13 +
 ..._92a2af3e0e328bb48bcc67a69187ee57._comment |   13 +
 ..._f6e39e71882d55cdc061166aea3e2bd3._comment |   26 +
 ..._6c45a6264d69e22800c329a0f8a2d470._comment |    8 +
 ...multiple_annexes_with_assistant__63__.mdwn |   13 +
 ..._ba8c70e4a46441b48ad910625636eee5._comment |    8 +
 ..._4b4f0a7d84a51ae92536e2c190256069._comment |   10 +
 ..._86daadc565f96db5db13b6dbcbc66db3._comment |    8 +
 ..._e43d71ddfdfdb7bcb13bfb894de6a5ec._comment |    8 +
 ..._e94d33be83b45918d1a39d6e16fba4b4._comment |    8 +
 ...tiple_repositories_concurrently__63__.mdwn |    5 +
 ..._ebec1ddad71e961cdc9b21cbddfbcdaf._comment |   10 +
 ..._a_git-annex_repo_from_an_Android_app.mdwn |   21 +
 ..._c59ec715eb02fbdd63780b2450ff2de1._comment |   12 +
 ..._20ee5f900a2ff6154c0d90263579723e._comment |   13 +
 doc/forum/Manual_Setup_of_a_Central_Repo.mdwn |    1 +
 ..._3a163fd5629dc40423f1290a78ae1c07._comment |   12 +
 .../Manual_commit_message_in_direct_mode.mdwn |    3 +
 ..._32f95eefec25bb127ed96248446c21b1._comment |    8 +
 ..._bf1d10067379c802ac5020d8becd6d35._comment |   10 +
 ...al_local_pairing_without_webapp__63__.mdwn |    5 +
 ..._1f280e38bf5fa81d3a8cc4887f32e590._comment |   22 +
 ..._d83cc10b2359eb3578c6c4dd299cf308._comment |   10 +
 ...l_mode_option_in_assistant_auto-syncs.mdwn |   11 +
 ..._4a0468b6ca2ffff8ef8f19800597567d._comment |   10 +
 doc/forum/Manual_webapp_behaviour_on_ARM.mdwn |   15 +
 ..._5431a57aa7d659faf0aee12e638dd1ba._comment |   56 +
 ...ally_moving_annex_objects_to_new_repo.mdwn |   12 +
 ..._f9b894bafc5ab19ec7b0b500ddfe00ef._comment |    8 +
 ..._6125e6a7d6b15dee7bf6a6bfe99bcf73._comment |   12 +
 ..._8203d8e0444471b9360b679f49f67fac._comment |    8 +
 ...rop_in_performance_with_--jobs_option.mdwn |    9 +
 ..._8a9b5bc3b8a8ef947f2620422307c465._comment |   27 +
 ..._c9fea9db7116e7ee82a09c23f22b54e9._comment |   30 +
 ...hing_options_not_working_in_windows_7.mdwn |   18 +
 ..._616f6c6d26088207ce9c044f4b61eec5._comment |   16 +
 ..._b0319c1214c26f64058eb9c38ef6fb0d._comment |    7 +
 ..._d834a6cb0ae1bd47e5280b10ecbaa72d._comment |   16 +
 doc/forum/MegaAnnex_not_working.mdwn          |   32 +
 ..._5aa3fd366d4c78ca79bb58005a49791c._comment |    8 +
 ..._f3eaf1ee06ebac951514d865f298f9d3._comment |    8 +
 ...git-annex_repositories_together__63__.mdwn |    7 +
 ..._b96bb95cdbbc78c0b4b348861e2264bd._comment |    8 +
 ..._539a33b268be5c6954f3112d89dd34ef._comment |   10 +
 ...ed_up_repo_by_syncing_to_wrong_remote.mdwn |   40 +
 ..._d1358e46d488532e1922a1bf7c471980._comment |   13 +
 ...chanism_for_special_remote_to_another.mdwn |   44 +
 ..._6e8e3350ae26b6c59daa56b7e86cc46a._comment |   14 +
 ..._db4b772371ee49c743605c728e23c91a._comment |   19 +
 doc/forum/Migrate_mark_files_dead.mdwn        |  254 +
 ..._fa155c961d5aecbe055f67d8ace0c208._comment |    8 +
 ..._a4512fb8a59f3a4d4ee85651a979f00f._comment |   11 +
 ..._a10dbdd505742d5cf03fd435e206d9a2._comment |   15 +
 ...Missing_git-annex.linux__47__runshell.mdwn |   44 +
 ..._f29a5105649579ef15e79d983c4e1f8e._comment |    8 +
 ..._content_repos_with_import_and_export.mdwn |    7 +
 ..._0486a067491456d92220ca638e3095bf._comment |   13 +
 ..._d0e73dbcf22704cf1c9af8a56533aebe._comment |   10 +
 ..._d15b0e5a034deeac85806790e53aefaf._comment |   11 +
 ..._3f7d0f8d1a48d60612aa8477e32fb6f1._comment |    8 +
 ..._9f11132002d2fee9917e91a7b80a94b3._comment |   84 +
 ...d_in_synchronized_remote_copies__63__.mdwn |    5 +
 ..._2b13584998108af0522b898c5d396ba4._comment |    8 +
 .../Modus_operandi_for_local_full_backup.mdwn |   20 +
 ..._fa8ac55ebd94312a36b284047b6cf932._comment |    9 +
 ..._fc2ac75608e91018f67c3753e9b09f76._comment |    8 +
 ..._6089f53d8af5746f2a410d0214567943._comment |   15 +
 ..._4c27aae1361465993fb60997bb0eadf8._comment |    8 +
 ..._in_git_annex___40__direct_mode__41__.mdwn |   22 +
 ..._6426aca2296b5e03b333d5253ae7d88c._comment |   12 +
 doc/forum/Move_history.mdwn                   |    5 +
 ..._da64814a7dfc2322200130a17bb79923._comment |    8 +
 ..._46ce6990e5921238f98749af830ac5ec._comment |   11 +
 ..._b720837e8e4ab8f4b0648f8ac336a605._comment |    8 +
 ..._17b8c2fd3ac706cd666ad5f5c0a21715._comment |   11 +
 ..._9ff881c26c3bd7f3a61595ffc1df743a._comment |   33 +
 ..._d0c97744e9ccca21e4023f657e9f5f30._comment |   28 +
 ..._0655707fe70710408b93b5f53f8d6f26._comment |   20 +
 ..._f2e1d20e269648358b1eced616727e63._comment |   26 +
 ..._acd690861b31e55352497b32b7c0fd6e._comment |   12 +
 ..._0e4b1629d2bb9d360a1ba65494dd8ccd._comment |   28 +
 ..._1153476304000f417292fdce1f9727bf._comment |   14 +
 .../Move_unsynced_file_in_direct_mode.mdwn    |   97 +
 ..._12a797cba753168dfde9e6339c00f481._comment |   10 +
 ..._f3aec24668c35780a033f2b035df10ee._comment |   20 +
 doc/forum/Moving_S3_special_remote.mdwn       |    1 +
 ..._b030a7afcbf1a329bb35260cf338ff96._comment |    9 +
 ..._3c4b8afa81590a1f1e2291a08d633b16._comment |   10 +
 ...ithin_the_repo_without_copying___63__.mdwn |   19 +
 ..._9e3290138133d5a23a80f72342f47ec4._comment |    8 +
 ..._232b77894dda51d02cbc34bd25d3213b._comment |   13 +
 ..._d35ac1bdb3fa6e303ad92348ba174158._comment |   11 +
 ..._4b443ec6b47eaabe214d0c2222083e4a._comment |    8 +
 ...s_file_content_without_doing_checkout.mdwn |    4 +
 ..._f114b75b29123453758b493fae7f5167._comment |    8 +
 ..._e377b7614c2961b460a10e285f3db274._comment |   10 +
 ..._d251958795ab0867c65cf182e54a6ffe._comment |    8 +
 ...tiple_group_groupwanted_settings_help.mdwn |   34 +
 ..._e78d0aa6b23225c509b9e97549fe915b._comment |   34 +
 ..._b3d95d5c03c7b985d39a4d5a45ba3dec._comment |   27 +
 .../Multiple_interface_to_the_same_annex.mdwn |   29 +
 ..._ea9e3a987112d8bf6421be234bf61d3c._comment |   15 +
 ...ple_machine_remotes_on_external_drive.mdwn |    7 +
 .../Multiple_prefered_content_groups.mdwn     |   66 +
 ..._b401d234c0730412053f0f6a6f9cf2d6._comment |   32 +
 ..._a91177f4f02500e8fa6594933e128ef0._comment |   11 +
 .../Multiple_remotes_with_the_same_path.mdwn  |   67 +
 ..._78f2d8e3906c11ba5753478d08973bd2._comment |   18 +
 ..._8cd3edf2e71e904f1b651abdfd7a4499._comment |    8 +
 doc/forum/Multiple_repos_on_same_path.mdwn    |   12 +
 ..._67ed823c4c40f5acf12b48eb75d7afa8._comment |   32 +
 ..._e1c4ac71eb0f9ff6ae1701b3a6d738dd._comment |   26 +
 doc/forum/Multisession_compatible__63__.mdwn  |    8 +
 ..._dab5a92416314a7d4c02663d4e46cd60._comment |   11 +
 ..._1c8d0f97d353c3e1d290edbe0a48b359._comment |   16 +
 ..._c1dc4294cc2a43cfecfb7279d6411924._comment |   21 +
 ..._b7148c3afd31ce1effd135a4f7c92dbc._comment |   16 +
 ..._d0ddac05268d978e950c91e76b023ffe._comment |   11 +
 ..._e2319f774eda62600c27ab9d2d0d1e50._comment |   10 +
 ..._0e6c8ab32c589f0d971d4c208a8d1645._comment |   10 +
 ...es_be_accessible_to_one_another__63__.mdwn |    9 +
 ..._7af462f69b9efc3bbe18d0dbc839cb39._comment |    8 +
 ..._882d9e6b7b2297dfd29266bbd429b046._comment |    9 +
 ...r_some_weeks_with_git-annex_assistant.mdwn |   57 +
 ..._9d4019a54fb508e286a5d6d2660361d9._comment |   26 +
 ..._109534a45881ce94a4586c8a83945f9f._comment |   85 +
 doc/forum/NTFS_drive_mounted_on_Linux.mdwn    |    6 +
 ...linux_unable_to_connect_to_ssh_remote.mdwn |   29 +
 ..._b2d2bf6be441dc2e4443d06ef8db7134._comment |   12 +
 ..._75abe6da74cd0432e616e391f5be6fe3._comment |   14 +
 ..._build_instructions_for_Debian_stable.mdwn |    5 +
 ..._8c1eea6dfec8b7e1c7a371b6e9c26118._comment |    8 +
 ..._f6ff8306c946219dbe39bb8938a349ab._comment |   21 +
 ..._bcda70cbfc7c1a14fa82da70f9f876e2._comment |    8 +
 .../Need_some_help_installing_on_freeBSD.mdwn |   48 +
 ..._3962871e646280e2c4fdff8a08bed485._comment |   14 +
 ..._528fdd2c385809b971eceee1eb70ee38._comment |   11 +
 ..._5ae3cd6e24a25d6dc803ec2adea0414f._comment |    9 +
 ..._1dcc43aaad2099bb1684873d24da668f._comment |    9 +
 ..._527bf6df2485c5e906f1d50930ec01fe._comment |    9 +
 .../Need_some_help_to_fix_my_repository.mdwn  |   31 +
 ..._f0d279c530b796b2c93d793f85d147e8._comment |   13 +
 ..._a3fcfa1f8eadec5fa8a9efacca174048._comment |   10 +
 ..._7878f9b76ddfa3392c9ec6a1810cb745._comment |   10 +
 ...nused_files_because_of_bad_sync__63__.mdwn |   23 +
 ..._af0ed0730645c1e3c9a4946acd48c18a._comment |    8 +
 ..._12f3c2bb2458b69e6355c8f94bab868f._comment |   13 +
 ..._b233b4daac32c452776e1e3d9a29f2cc._comment |   12 +
 ..._8e079e92929dcfdf19f6adec16f800e5._comment |   23 +
 .../New_Arch_Linux_package_for_git-annex.mdwn |    7 +
 ..._5881a5974ec1c4f701775c30b814ee2f._comment |    7 +
 ..._f41f9248f4d5039309e8fd98524e86bc._comment |    8 +
 ..._ab1f6e45625e6ab80770d4ff65ec4242._comment |    7 +
 ...ew_external_special_remote_for_rclone.mdwn |    7 +
 ..._8845852338bbb7e46c0d5585d5884faf._comment |   15 +
 ..._4057e28ed32aeab048f7c97a733f180f._comment |   11 +
 ..._4412a5a25ac933de71772afd23cd66bd._comment |    8 +
 ..._9a23f4e9d673b4dcf60b3425fa4df4aa._comment |   16 +
 ..._cf45b8efbb296013493e7756cdfcf291._comment |   24 +
 ..._36a0260f013ccbd06460dea83fe22278._comment |    7 +
 ..._4d7f07a872ef3cc2c4928dcd1580bd0a._comment |    9 +
 ...nnex_integration_mode_for_Emacs_users.mdwn |    3 +
 doc/forum/New_user_misunderstandings.mdwn     |   24 +
 ..._c1785924109b5d5cde9aa3d3460cf955._comment |   10 +
 .../Newb_question_on_sneekernet_sync.mdwn     |    7 +
 ..._409cc5ba605d63331b386066d32f797b._comment |   31 +
 .../Newbie_question_for_a_simple_task.mdwn    |   11 +
 ..._51cf643c8d843dd2ab49c83aaf4fd218._comment |    9 +
 ..._a9d18e6fb1c6b064f50467c23bc89d2e._comment |    9 +
 ...to_connect_to_the_Jabber_server__34__.mdwn |    5 +
 ..._59158afcedac18a7285d57491b2a468a._comment |    8 +
 ..._2a70ac08bb95774415b09dab7d7f8605._comment |    8 +
 ..._92a52b523ed4c68b70ddcabc2a050b76._comment |   12 +
 ..._c52a75761ea107f6d69c09bac64f0f0a._comment |   12 +
 ..._2685e3a87464ccd37d593516d94ba5cf._comment |   10 +
 doc/forum/No_SSL_traffic_for_S3__63__.mdwn    |    8 +
 ..._f509bf273896180e6df8c771438dd093._comment |   11 +
 ..._358635d19c82202c63014ca84de7fc3b._comment |    8 +
 doc/forum/No_known_copies_exist_of.mdwn       |   31 +
 ...ting_forgetfulness_does_not_propagate.mdwn |   26 +
 ..._b4aaabb50743dd11b70ce0cd2b85df5e._comment |    9 +
 ..._81c98f50953860c15473e958c55d1e4b._comment |   15 +
 ..._350cc2d2025655804a58ed520a157c2e._comment |    9 +
 ...git-annex_status_v5.20131224-g692aa01.mdwn |   16 +
 ..._b014f1edcb7ce39da9b582683d3b80c0._comment |   10 +
 ..._24602de6cfe1f3d988c5105e7266a518._comment |    8 +
 doc/forum/Non-ASCII_filenames.mdwn            |   64 +
 doc/forum/Not_enough_free_space.mdwn          |   42 +
 ..._4721e6e6c263c2a624d6cc77f6575860._comment |    8 +
 ..._69e5a25b63457e702436b54d26f6d482._comment |   18 +
 ..._c6ad0934136448a014f6b1c317bba3e6._comment |   15 +
 ..._c05f95ae6d69cdc214a2b31ebc296a3b._comment |   16 +
 ..._f8206862e22fa354d97cc3d9d2af8d5c._comment |   10 +
 ..._06d27155323cf5609b17c4e1197ab9ac._comment |   41 +
 ..._7cf8cf6d15324b840336be561423d34b._comment |   29 +
 ...Not_sure_how_to_get_my_s3_remote_back.mdwn |   31 +
 ..._ed35a6ec605e8f79ec107856af6d1a46._comment |   18 +
 ..._e48b6efa42159dc83e1be11bfb54abcd._comment |   14 +
 ..._b58232d0e3fa4649565c0c7d4ce2e82e._comment |   31 +
 ..._85368b60091dc3ce2efb58013ffe9f83._comment |   10 +
 ..._e65281bef23e0076936c508728a87897._comment |   25 +
 ..._fffb59ad5a197d2980dd0ec35cf4aafa._comment |   10 +
 ..._0cfcc2075bff556b9fde5acc3dc1d599._comment |    8 +
 ..._6fe2ff1282fb14a4ce26ef8dc775d07e._comment |    8 +
 ..._64338d2d77dcbabd16b55eb145f40dc6._comment |   12 +
 ..._dd66c9ea0c83388f6826751944330d10._comment |   16 +
 ..._dc0c5e395e4c443b7227afdb157194e5._comment |   10 +
 ..._3c0ea4c76cdd889707f7308576e3efa0._comment |   65 +
 ..._36519ee4499a19f0864e4fcd264e9933._comment |   20 +
 ..._85b23f375e53469fb09b24b945b3aba9._comment |   17 +
 doc/forum/OSX_Finder_extension.mdwn           |    5 +
 ..._4aa37c3fbe3c260d71f2ed16fd4f20bc._comment |    7 +
 ..._e16092041890f81dc65a6ab28b2224a6._comment |   12 +
 doc/forum/OSX_Mavericks_anyone__63__.mdwn     |    3 +
 ..._3075b02aeb57adcbf4addf9fb4c123ba._comment |   11 +
 ..._c2b6110fc4a3d3481ed8a4b48efb9635._comment |   17 +
 ..._7df9ba63cb1f385681242b4b58d6a87c._comment |    8 +
 ..._740fee31c4ca9d84428f97f63ffc075a._comment |    8 +
 ..._sshd_behaviour_has_limited_paths_set.mdwn |   12 +
 ..._a136ff877389f0930c066ba118edd9fd._comment |   10 +
 ..._5fcc52a62770fb932a4a2101f5badbc0._comment |   17 +
 ..._521f34c340ad54cef6458a8b6cfff8a9._comment |   13 +
 ...kell-platform_statically_links_things.mdwn |   17 +
 ...iled_to_check_if_upgrade_is_available.mdwn |   36 +
 ..._ac7c1f39e723cbcd49d6497649e7e44f._comment |   13 +
 doc/forum/Odd_Hybrid_Symlinks_To_Content.mdwn |   27 +
 ...opped_even_though_enough_copies_exist.mdwn |   45 +
 ..._d43c3b97af1d9d2d4534b40a43567420._comment |   13 +
 ..._81e3664c6746fbeb2d76cca7160cf58a._comment |   11 +
 ..._d5b2b68f22796c3ecd2929f47db3601e._comment |    8 +
 doc/forum/One_repo_with_multiple_remotes.mdwn |   20 +
 ..._4b9b3137396a3e830fe96726401270b8._comment |    9 +
 doc/forum/OpenOffice___47___Libre_Office.mdwn |    5 +
 ..._98ed542fedd820d47bf8deb7d3232725._comment |    8 +
 ..._f313fdaa23863c2ae99cfbfe9ec2e1e0._comment |    8 +
 ...th_files_bigger_than_available_memory.mdwn |   34 +
 ..._2e89bcc3fbd069e5d9eb12c1c19993ad._comment |   14 +
 ..._cf8065e697a0a83cf3461672cb6421e0._comment |    9 +
 ..._e6bd4eb070a094116e13064dca6d5bb5._comment |   11 +
 ..._42adc29a2c3216910a3bcda04d6f6a6b._comment |   17 +
 .../Overwriting_data_without_getting_it.mdwn  |    3 +
 ..._f1c0199ee9bffcc84287370b89361294._comment |   26 +
 ..._6a1d08dbca206129ef6cf8aa97daeee1._comment |    8 +
 ..._52958e76e506fdbb6b533681ab619b3b._comment |    8 +
 ...ing_git-annex-add_or_git-annex-status.mdwn |   15 +
 ..._4df2625cc1f1de8f164aa9500eb80e13._comment |    8 +
 ...anged_in_.git__47__annex__47__objects.mdwn |   31 +
 ..._e89aa61303d97bfd433e24173867723a._comment |   10 +
 ..._3e467d256ef7c2f4d469073c00cacbca._comment |   17 +
 ..._119c181afe351a412e8a13c59175ec45._comment |   19 +
 ..._0a9cec8f4e26c2e2365b54b29c91ee3d._comment |   41 +
 ..._df986910016ce53a6155edf96f4c312d._comment |    8 +
 ..._c4fe35a93ed32f7b14c5ffd5a4a8ec27._comment |   77 +
 doc/forum/Per_directory_numcopies.mdwn        |    5 +
 ..._33497e3a46926595920eb3dcdb58447c._comment |    9 +
 ..._00572e3c15e5a9d253fb4ea57b45ff0d._comment |    8 +
 ...ns_of_triply_nested_objects_directory.mdwn |   23 +
 ..._068a8f120d188b8fa5d3e5b687fd02dc._comment |    8 +
 ..._cc0f5be21fd1523bdddc7bcf6ff04435._comment |   10 +
 ..._1133795276371c86cdd52b25a8b20c52._comment |   28 +
 ..._4e44289e6913797844e103f9cdf4c5a2._comment |    8 +
 ...ormance_of_V6__44___V7__44___V8_repos.mdwn |    8 +
 ..._981279bae881a07185707c29e6c58b28._comment |   17 +
 ..._01e6d32c85524a23399a33b5fb12ec06._comment |   14 +
 ..._71e8d6ed7b1a6088cdb5abb5667ee619._comment |   16 +
 ...rmission_denied_-_what_is_wrong__63__.mdwn |   28 +
 ..._b850a32cce4c9782e59fc91076b6cae7._comment |   14 +
 ..._e8d2170e5f830d0f98bc8251caf8bc5e._comment |   14 +
 ...ickey__41___On_second_Step_...___63__.mdwn |   36 +
 ..._6c74f0b43c457fe97b2d8630ca4fde29._comment |   10 +
 ..._b7a384e853e1756a684774348fad29e6._comment |   22 +
 ..._3a8a7f51cb04a92c576549d379b57248._comment |   12 +
 ..._582ad3ba0c62a77b08a10b37a780c670._comment |   15 +
 ...with_ssh_key_authentication_to_remote.mdwn |   24 +
 ..._39a096f92f0280db9502397b9fc55541._comment |    9 +
 ...g__58___drop_jpeg_if_raw_is_available.mdwn |    1 +
 ..._3f365138be319ac2c81bdefb3f59b0d8._comment |   12 +
 ..._0186f593ec084e12216ad2f7da49474e._comment |    8 +
 ..._0bc307a3fbe000059b23cf681d125ce6._comment |   17 +
 ..._0dc16ef1d592be0dfeb63c28014a70b2._comment |    8 +
 ..._9eb36b5b43b77de790f99ae1d764e4ea._comment |   10 +
 ..._a34d404dbecd6730c1cc28af9c0eac26._comment |   16 +
 ..._88b04371b3906f01c7b33d110838dc71._comment |   12 +
 ..._b3e9100b92aaed66b22c76141f7c08d5._comment |   14 +
 ...emove_sha-inside-sha_single-file-dirs.mdwn |   20 +
 ..._616f610876e08828e6ad6b89b9e561be._comment |   10 +
 ...git_status__96___is_slow_after_update.mdwn |   74 +
 ..._68429f9e44ce24250c608da8ffffe643._comment |    8 +
 ..._cefd5742da29e19f5ab3406698a13f9f._comment |   17 +
 ..._ab005dba805922597a533ddd661f20c8._comment |   10 +
 ...Please_fix_compatibility_with_ghc_7.0.mdwn |    1 +
 ..._d1d10217ebd0151e947b3a6cd37399ce._comment |    8 +
 ..._help__44___half_my_files_disappeared.mdwn |   14 +
 ..._ba7c79dd7805aa9ec1b90d643f6bf555._comment |   16 +
 ..._help_me_help_my_photographer_friends.mdwn |   18 +
 ...new_releases_not_shorter_than_11_days.mdwn |    6 +
 ..._da3d39de5be47ebe8b25a42ed1f36510._comment |    8 +
 doc/forum/Podcast_syncing_use-case.mdwn       |   34 +
 ..._ace6f9d3a950348a3ac0ff592b62e786._comment |   10 +
 ..._930a6620b4d516e69ed952f9da5371bb._comment |    8 +
 doc/forum/Poor_man__39__s_IMAP.mdwn           |    6 +
 ..._258ff23c462dc88b88ced405c4f5040f._comment |   11 +
 ..._c88d1abdda4cb526a6ee45a710c75bc4._comment |   10 +
 ..._3847e371db1c2788c075e7dca1fbd33e._comment |    8 +
 ..._cf6cc21f2cf2aa5c949844e24a7b4075._comment |    8 +
 ..._d861fa69475ce526841b3195be8ee356._comment |   10 +
 ..._1e81bd4bb62652bc674cdcd7ed57ac5c._comment |   12 +
 ..._b3929281dff6078d77f1b9ae42e25bb6._comment |   16 +
 ..._69506e8c519196f44b9ed15b32f00106._comment |   22 +
 ...able_version_of_git-annex_for_windows.mdwn |   22 +
 ..._e5e60fa8d104a09152a8164d5a906aec._comment |   10 +
 ..._d8d1aa0920351e880ba6678bb97585de._comment |   10 +
 ...le_bug_in_setting_up_Rsync.net_remote.mdwn |   24 +
 ..._dba203d6c701365685f1a0d4269633a3._comment |   18 +
 ..._47b14e71ce0dd653a300dabe8ab0ac3a._comment |   33 +
 ..._753ff00c43be5f9bef6bcb529ad68bb9._comment |   11 +
 ..._43f04bfbaeb4f04a5980ade59a36ae91._comment |    8 +
 ..._6dd6819103814056d8b71356804be56a._comment |   12 +
 ..._b90f349f00ea283d018681505b4feaf5._comment |   35 +
 ...ore_from_an_encrypted_s3_remote__63__.mdwn |    5 +
 ..._98033f3324bf78af886fa0f003f5eff8._comment |    9 +
 ..._ddd6a56d583fd5b9d676365f4ebd9b68._comment |   30 +
 doc/forum/Post-Kickstarter.mdwn               |    5 +
 ...tings_for_sets_of_backup_drives__63__.mdwn |    3 +
 ..._54cdea3a60d61dad6332af31b2968bdd._comment |   16 +
 ..._c21e128f6bdd5408607b51c963854d4d._comment |    8 +
 ...ed_contents_based_on_presence_in_repo.mdwn |    5 +
 ..._2109fe43fccc6576e782a2e765eb6b50._comment |   17 +
 ..._f3adab92e7015245735f4bcad1d7a146._comment |   10 +
 ..._6aaf8226051e9dd104da206b032cfe5a._comment |   30 +
 ..._ffda2c94cbccab1d462a4e333816773b._comment |    8 +
 ...simple_USB_backup___40__for_WAF__41__.mdwn |    5 +
 ..._a02dd00950793814ea9617e0eec738ba._comment |    8 +
 ...serving_Directories_in_Metadata_Views.mdwn |   47 +
 ..._30332d3828324455600b0b452e3b6c5a._comment |   16 +
 ..._0decf76e18bb9fbc9b55e94f647a466d._comment |   19 +
 doc/forum/Preserving_extended_attributes.mdwn |    5 +
 ...in_directory_tree_below_objects__47__.mdwn |   77 +
 ..._5dd978f9b5a0771f44ab9e086bf5a07f._comment |   14 +
 ..._9f51947b35ee04e473655e20d56c740a._comment |   16 +
 doc/forum/Preserving_the_v5_experience.mdwn   |   14 +
 ..._9b188fecb7eaeb3ec3ba47f4c5e17e37._comment |   10 +
 ..._d2da6d56980b535431d7f0360f58d04c._comment |   10 +
 ..._b15c92675cf6a5087ced6a649dd1b6c7._comment |   13 +
 ...n_Android___47___Termux_not_permitted.mdwn |   13 +
 .../Preventing_annex.ignore_for_remote.mdwn   |    3 +
 ..._ec28f3ed75f2abad3d01a90c5b79c4b8._comment |   12 +
 ..._57703f8d610aae7fadb8980e77a408b0._comment |    8 +
 ...revious_versions_in_direct_mode__63__.mdwn |    3 +
 ..._352d460acd5500587e679d934180eee4._comment |   10 +
 .../Problem_compiling_current_master.mdwn     |   14 +
 ..._135df61ec850c06e3b48ccfef7b5b031._comment |    8 +
 ..._fb3e27b6014e84bd919a7a4a95e39ef9._comment |   20 +
 ..._b737b3945103c5e2aa798b4e65fbce06._comment |    8 +
 ..._28c1b335ae388d4e1f22b711ac1c001f._comment |    8 +
 ...ith_Anaconda_and_git-annex_on_Windows.mdwn |    1 +
 doc/forum/Problem_with_corrupt_SQLite_DB.mdwn |   17 +
 ..._4e10e6d1882feba8d0c1ad058e01143c._comment |    9 +
 ..._98020b857e5b52ebbbaaeba1313f2697._comment |    7 +
 ..._079359513b6b9fcf0030f49df0eaf64d._comment |    8 +
 ..._6a5f8590e6a60be5afe6bc6ffce1c94e._comment |   17 +
 doc/forum/Problems_syncing_with_box.com.mdwn  |   26 +
 ..._8db642849da4d42cd9a43142e2b7cb70._comment |   12 +
 ..._cd18f33647aebc04af5469e4ce1fbcd2._comment |   11 +
 doc/forum/Problems_using_blake2_backend.mdwn  |   26 +
 ..._f3ffd27a9b515e867041b6cebfeeafad._comment |   12 +
 ...using_submodules_with_git-annex__63__.mdwn |    1 +
 ..._c7a927736d419d3c31c912001ff16ee4._comment |    7 +
 ..._26f6581b5969eb2cb77495c40de88951._comment |   11 +
 .../Problems_when_cloning_a_repository.mdwn   |   22 +
 ..._191c091c384d8d97d24f8a77e8ff90ee._comment |    9 +
 ..._74ccbb09677444478074e9eab405fbaf._comment |   16 +
 ..._3436e26dd9fe07233a070d4e95d81cdf._comment |   16 +
 .../Problems_with_Assistant_on_Android.mdwn   |    1 +
 doc/forum/Problems_with_FAT_links.mdwn        |   52 +
 ..._1628c68ef7bdaedb01fcb897a447bb91._comment |    8 +
 ..._734850345a66d5df38c468ffaa1182cd._comment |   25 +
 ..._2728cd609cb5e792d1dc722d450e4c8d._comment |   17 +
 ..._0a5f0239b3b6376672c8d91eaf68a460._comment |   20 +
 ..._3c9dd1e2586b27911422066ca71f5298._comment |   20 +
 .../Problems_with_large_numbers_of_files.mdwn |    8 +
 ..._08791cb78b982087c2a07316fe3ed46c._comment |   22 +
 ..._0392a11219463e40c53bae73c8188b69._comment |   25 +
 ..._537e9884c1488a7a4bcf131ea63b71f7._comment |    8 +
 ..._7cb65d013e72bd2b7e90452079d42ac9._comment |   29 +
 ..._86a42ee3173a5d38f803e64b79496ab3._comment |   14 +
 ..._4551274288383c9cc27cbf85b122d307._comment |   11 +
 ..._d18cf944352f8303799c86f2c0354e8e._comment |    8 +
 ...te_changes_and_remove_adjusted_branch.mdwn |   55 +
 ..._84651b939b10b84df5e685393546732e._comment |   30 +
 ..._git_annex_proxy_to_mimc_undo_--depth.mdwn |   15 +
 .../Pruning_out_unwanted_Git_objects.mdwn     |    3 +
 ..._0cf7a12bfa2957260f4b2f79b0cadf2f._comment |    8 +
 ..._7472943c02cfe2808b0d566e06caa1a5._comment |    8 +
 ..._6a1e7a83d94394454fc085f6d2728cd7._comment |    8 +
 doc/forum/Pull_files_through_cloud.mdwn       |   10 +
 ..._ae71f9876c8376ba0d0ab424bfb66e72._comment |    8 +
 ..._f4dfc4b212e23f7443abfb28b5613f63._comment |   10 +
 doc/forum/Purge_a_remote.mdwn                 |    2 +
 ..._78b3b77f457c65d31fd8a5abf714905d._comment |    8 +
 ..._dc65719157dee63b3979563ed57ee0ce._comment |   10 +
 ..._63e0280273b816fa4b837724e102f813._comment |    8 +
 ..._7fad1c4798ca03a4095ac3241c279f6d._comment |   11 +
 doc/forum/Purge_whereis.mdwn                  |    9 +
 ..._89d2446e3c9a58ab7b2a85ff941f7c8d._comment |    9 +
 ..._0307ce47de9b719adc2096600d94dff6._comment |    8 +
 ..._e87b53ebbf8053bb17caeb2aed871212._comment |    7 +
 ..._72b6c28d8a4865ad8c84b1f7dfefb78a._comment |   10 +
 ..._966e0285639a41ee9db3e9fb337e2699._comment |   11 +
 .../Push__47__Pull_with_the_Assistant.mdwn    |    1 +
 ..._f7b63d379c2d21794adf8658f546f8a7._comment |   10 +
 ..._aec8cc20576e7ffd5a8be4348d1a0073._comment |   21 +
 ...to_repair_hangs__44___broken_symlinks.mdwn |   77 +
 ..._c89b64b0dc7c5a760a84a9d2cfd8982c._comment |   11 +
 ..._c511691c4ea6c77e63ef85c28c921be9._comment |   12 +
 ...g_git_annex_repo_to_a_remote_ssh_host.mdwn |    1 +
 ..._4008b735809161d5950b7991d69d3f68._comment |   12 +
 ..._git_repo_to_AWS_S3_from_behind_proxy.mdwn |    9 +
 ...tion__58___git-annex-only_repo___63__.mdwn |    3 +
 ..._ada27f7b8c7dc3c388e6c56ef095e682._comment |    8 +
 ..._531e6a091c8d005626e4e8290ba317d7._comment |   12 +
 ..._321632cc794c00181932f5737db9aff0._comment |    8 +
 ..._941b62a63c11caa1ada5d544c2e926ca._comment |    8 +
 ..._0c0dad1ffa11f2f8708906d310a189db._comment |   11 +
 ..._426160c2237db790b133b9c9f0abd4b2._comment |   10 +
 ..._36bd0a398b385e65df7eda26fa5c50d0._comment |    7 +
 ..._32fb6930bcaac36d00b088d8ee09face._comment |   14 +
 ..._8278ee493da14aac86e928d2349d8173._comment |    9 +
 ..._3e24c9f9042d6abdafaae45015645b11._comment |   10 +
 ..._182c66e98086dbfde29b615d0cf0e8e4._comment |   19 +
 .../Questions_about_borg_special_remotes.mdwn |   12 +
 ..._bbeb30671d707f2a1d7ac0dbf342136e._comment |   23 +
 ..._5c10ff05b8e1714aa9b413d6b01e275e._comment |   16 +
 ...Reappearing_repos_in_webapp_and_vicfg.mdwn |   43 +
 ..._bd977e864ae89816fa7f4ff69879b15f._comment |    8 +
 ..._05749f9e75689d0111339b7126c12300._comment |   15 +
 ..._b1531994eea0fbbf4cb097e604378a53._comment |   12 +
 ..._f1eba3e8aa4116e3c20747ec1d6e24e5._comment |   12 +
 ...chive_bypassing___34__here__34___repo.mdwn |   46 +
 ..._901272a6f738bfe8a0289c4900fd0c20._comment |    8 +
 ..._aec1d16cb47b59dd4f2811b2956e5fdf._comment |   13 +
 ..._652d9957ead7dbf4feb3ba096137d22b._comment |    8 +
 ...nd_.git__47__annex__47__objects__63__.mdwn |   69 +
 ..._456772b5b0deb0c121d7feb5dcf41979._comment |   12 +
 ..._410f329fb47f13afc59b5b37b88a8c3a._comment |   84 +
 ...tChanges__58___link_to_the_diff__63__.mdwn |    1 +
 ..._85254a327ffed22b407d25610558c15b._comment |   15 +
 ...Recomended_Setup_for_Syncthing_Remote.mdwn |    5 +
 .../Recommended_number_of_repositories.mdwn   |    4 +
 ..._3ef256230756be8a9679b107cdbfd018._comment |   15 +
 ..._with_semi-permanent_filename_changes.mdwn |    8 +
 ..._ec1c86e41ce3ee243df9a5008db87070._comment |   10 +
 ..._47b248b36146c5ad9986b69c8d212b4e._comment |   21 +
 ..._47951337fa2155b797b40fe19446ef51._comment |   17 +
 ..._12ae880e559bde5f75cb0c451b56b322._comment |    8 +
 .../Recover_files__44___annex_stuck.mdwn      |   28 +
 ..._6d85c3ec73ddc0682d9643f4d5eeda70._comment |   18 +
 ..._52e799bb6f24a1ebed58fad6cebd3a71._comment |   17 +
 ..._686a285bc7e950aae67856c47e7cb21e._comment |   18 +
 ..._a4d62d494b340458e6535d573bade965._comment |   12 +
 ..._c10f0fe1440ccd170804a433db2267ee._comment |   12 +
 ..._14446cafac6c33a3f95b5344c42c0bef._comment |   14 +
 ..._63c19f58b7e95e39ba25a735bdcc0bcf._comment |   10 +
 ..._8e5c7572ab8d1f0e41fedf6f805b942a._comment |    8 +
 ..._e5357c63107f79571bd3ff609b4406a7._comment |   26 +
 ..._3316652073710f39965cd49ceea5c4ff._comment |    8 +
 ..._d605f755c363d56cf5f1060ad06ee173._comment |    8 +
 ..._f3ee184a4d3b8d82a8a362a6c03a54a3._comment |   54 +
 ..._341b47663d133411587ec70ef2b178c6._comment |   14 +
 ..._66c0d9284d5edbac189a64b03c4fe50a._comment |   10 +
 ..._8b32f6597f447f88bee7a80698fb4df6._comment |   18 +
 ..._4cc81169e99a453cdb6e83e57e638f37._comment |    8 +
 ..._2d104cf4682e04906f8ca0ced7288cf1._comment |   17 +
 ..._d356c4fce9f1197e5292f9dedf85bbc9._comment |   22 +
 ..._856c7e1575f5d99530ecd54004315487._comment |   12 +
 ...ecover_repository_from_bup_repository.mdwn |    1 +
 ..._6e3b1ff58fbdc10bcaca6d660eb1156f._comment |   35 +
 ...special_remote_after_git-annex-forget.mdwn |   11 +
 ..._265563f95a8ec5918314afc7e6226b56._comment |    8 +
 ..._4da1d3f6a37b8772838bae762d4c43be._comment |   10 +
 ..._5aff48172bb767ed03e96812e4f89f38._comment |    9 +
 ...ecovering_deleted_file_in_direct_mode.mdwn |   13 +
 ..._a3e6fc93669ec76656c84793d1f59149._comment |   11 +
 ..._98c01a756c5f2dda28cffa5dd1dea385._comment |   16 +
 doc/forum/Recovering_from_a_cross-merge.mdwn  |   80 +
 ...ry_after_freeze_while_importing_files.mdwn |    3 +
 ..._d033b77b9417468e13076ff9302f2963._comment |    7 +
 ..._e14f330de3e9ebfa9a99c32e65d59d11._comment |    7 +
 ...ing_older_versions_in_local_git_annex.mdwn |    9 +
 ..._2a84bf661e0cbd5c8a558d3dbf5aef65._comment |   15 +
 ...oes_not_have_expected_content_of_file.mdwn |   44 +
 .../Reloading_.git__47__config_mid-sync.mdwn  |    1 +
 ..._69e8879e0fed0e1b1589a721f9c6e3c7._comment |    8 +
 doc/forum/Relocating_annex_directory.mdwn     |    1 +
 ..._13ff5438baa1db110beb6aab3a783def._comment |   11 +
 ..._6d88ff03fcf00ae872442e8a86c968ed._comment |   10 +
 ...e__39__s_git-annex-shell_not_detected.mdwn |   20 +
 ..._8354782cf0fab248e607c7eae59d6bb2._comment |   12 +
 ..._35e5d9b427963fc7b9618eb522bd1273._comment |    8 +
 ..._7fb6168197c3f16de9775a60b7941cde._comment |    8 +
 ...bled_but_is_enabled___40__maybe__41__.mdwn |    5 +
 ..._04144280b69a7ba0cfa4fa3e1b5ef4ec._comment |    7 +
 ..._2c0340e5eac6d712045614886a8403a5._comment |   22 +
 ..._2b1ac09cb8b5f5ec62a201785c2f6531._comment |   23 +
 ..._a8e68a41e069803d89f18d1645876298._comment |    7 +
 ...ote_listed_in_whereis_but_not_in_info.mdwn |   29 +
 ..._85cc355213f894e8c1aeece432de67c3._comment |   20 +
 ..._ddede3236f1d91ac4f0117b76267a021._comment |   12 +
 ..._607d5b01eb95906391337f7351e0193c._comment |   15 +
 ...te_server_only_for_the_git_repository.mdwn |    3 +
 ..._d4d8d8cfebf9a98ca8878c5684d5bb50._comment |   10 +
 ..._a62dec8ab98ac7bd65059a9e425a01e2._comment |    9 +
 ..._portable_HDD_like_normal_but_indexed.mdwn |   13 +
 ..._7caf32756f799b67b0c0588ea5e17a20._comment |    9 +
 ..._36c202f5883b66a431ae5e72c5ecede1._comment |   12 +
 ...unused_content_from_S3_special_remote.mdwn |   11 +
 ..._acfd4eab2cd80d722479dbb410ccfe2e._comment |   26 +
 ..._adc602d325b8639ac5bfed088c504e1e._comment |    8 +
 ...bly_restore_the_original_naming__41__.mdwn |    1 +
 ..._dfc64d8618e07177bb196d9af4474698._comment |   19 +
 ...g_files_not_found_by_git_annex_unused.mdwn |   29 +
 ..._420c6230e68de0a0ac7d7da91ac60801._comment |    8 +
 ..._58fcceb96647a8c7f33d188ae908f3bd._comment |    8 +
 ...e_local_repository_for_git-annex-info.mdwn |   32 +
 ..._6df9b666f7d948b9e03b2ecf9858f6c5._comment |   12 +
 ..._a13ef241d6d24b4abee3eedff18032a8._comment |   21 +
 ..._c75652b23bc4554d43593d1984c9c5d9._comment |    8 +
 ..._695a821eee66f8c4d4e22518edd15c40._comment |    8 +
 doc/forum/Repair_in_steps__63__.mdwn          |    5 +
 ..._6a512ab2d6ea583a1913c9837e953760._comment |   19 +
 doc/forum/Replace_glacier-cli__63__.mdwn      |   13 +
 ..._318cd0ca9f4e997161ed22fffa5d5da3._comment |   18 +
 ..._c91e393951825cdcceac845e234d7497._comment |    8 +
 ..._405aad8dd28ea035226f7fda470fde33._comment |   10 +
 ..._a863eb91006df199fcdbc98f42b2d40b._comment |    9 +
 ..._fda6c754437385afa0851e680bf17cf0._comment |   15 +
 ..._2e7b5b6cc7c2e33be36c3c510adec01c._comment |   10 +
 ...acing_a_special_remote_by_another_one.mdwn |    3 +
 ..._File_system_view_of_Git_repositories.mdwn |    1 +
 ...__dumb__34___client_without_git-annex.mdwn |   11 +
 ..._077c492fd37d335f74a5c886ff0d524f._comment |   32 +
 ..._00e6576e3e60d2650461eeb0f918e6e5._comment |    8 +
 ..._c36a9562c53ac683b62fc4471405aa2a._comment |   15 +
 doc/forum/Repository_backup.mdwn              |    5 +
 ..._4d3197a1fefeb744e8b1e1b5fcf9b104._comment |   12 +
 ..._e362221ef3d13bd417b2b6b0c51738a8._comment |   14 +
 ..._ead30baf0a6d718569feb4002ba19b9e._comment |    8 +
 ..._6f20653dff70aaaea4460a5efb28081f._comment |   13 +
 ..._287510b4e8b9043fe361b7c5dc1f4e9f._comment |    7 +
 .../Repository_operations_stuck_suddenly.mdwn |    9 +
 ..._b0fa5b0e1b507e9a99e62849b1d66b7e._comment |    8 +
 ..._ff76dc687c2f632b39240d5e242d41f4._comment |   16 +
 ...g___34__get__34___or___34__sync__34__.mdwn |    9 +
 ..._8adf9c6d2a3ef29120703bfa1b8f9ae2._comment |    8 +
 ...___40____61____62___cannot_drop__41__.mdwn |   82 +
 ..._1db8c68e8d82ed169b4687dfb5da1ba6._comment |    8 +
 ..._ea362bb99294571f0b0e808e87b7d422._comment |    8 +
 doc/forum/Restoring_files__63__.mdwn          |   11 +
 ..._735b98419b3ba6207cc364426b03ce74._comment |   40 +
 doc/forum/Restricting_SSH_+_supply_key.mdwn   |    7 +
 ..._8bbd0b6488c23ce8b182bd6b1765c94b._comment |   11 +
 ..._3b946519c9f52569ce60ac04bdc3380a._comment |    8 +
 ..._cac35ac1ac0b300ddfac5ffc74291bce._comment |   12 +
 ..._e9803dd1794b4d078efa9435ff5ba295._comment |   19 +
 ..._1c3beb859e76cb69d2bacd2473ec72b7._comment |   10 +
 ..._1c541fc9a44e5cfb13c7d3ef0eeba2c7._comment |   23 +
 ..._4dbd5605f2638de0a3edfb3886a47938._comment |   22 +
 ..._a9c5b424a6acb2da152bf87b2e7617bb._comment |    8 +
 ..._93b7c2a5947fb6904c88cd5c120e404c._comment |   16 +
 ..._beaa350751eca4642545d1b83e528dd7._comment |   10 +
 ..._2faceeaf0d39f82e5d624eae19e4ca53._comment |   31 +
 ...-annex-shell_to_a_specific_repository.mdwn |   25 +
 ..._66544520bff71181e4a03ca583b0b458._comment |   12 +
 ..._2a210255e8535712c71fa183e56ab600._comment |   13 +
 ..._52cd4bd9694b2100b0e0dd2eafa9e828._comment |    8 +
 ..._4712a74774f60c29704d1e0f598caa78._comment |    7 +
 ..._27aa66428410cb8e77fcebccd2c6d1f4._comment |   10 +
 ..._b3a0db1c2f11770b7c6f13964f2d1784._comment |    7 +
 ...rieve_previous_version_in_direct_mode.mdwn |    5 +
 ..._ca3a999ed64c42b8df810115de205d2f._comment |   12 +
 ..._1292b34ff6d9976b2bd08748e1ba4e7a._comment |    8 +
 ..._699e816c0397f6db924feeab906f1151._comment |    8 +
 ..._d900388753de5870b7b9c0e8b8c06ed7._comment |    8 +
 ..._1360b936aa389a0ab5e5e453824b2ece._comment |    9 +
 doc/forum/Reusing_existing_annex.uuid.mdwn    |   27 +
 ..._dc3d6efbf5c076bedd0c7a75ff5314bc._comment |   11 +
 ..._cdb21c9c47c8a116e82062c9354d9339._comment |   10 +
 ..._5544f712897e06024342aa1bdd68df1a._comment |    8 +
 ...verse_index_key_to_list_of_file_paths.mdwn |    8 +
 ..._acae766349a036040a03e75fa8ed34c6._comment |   17 +
 ..._716efb07d216d9a063bb9498c8e76ea1._comment |   15 +
 ..._6b75bd75623004f05f609a39e95250ab._comment |   33 +
 ..._e54268d93837b3b8e216ec6af074f3c6._comment |    9 +
 ..._022728be6cd3ac168a74d16baf29c0e1._comment |   16 +
 ...Revert_file_linkage_to_original_files.mdwn |    9 +
 ..._898ca2c9976e92d22470c7404aa9813f._comment |   10 +
 ...t_to_a_precedent_state_in_direct_mode.mdwn |    3 +
 ..._1ae9f7defbab44621c3108973a4f683a._comment |   26 +
 ..._0bcfc0e89de7072bfdf1e3cdeaa16a1b._comment |   11 +
 ..._e49a37f92a3dd7d386e1e5f37ab37df4._comment |   12 +
 ...evisiting_migration_and_multiple_keys.mdwn |   22 +
 ..._a85c3c7af6b1e01f887e0e1ffe2cde6f._comment |   10 +
 ..._b5545aba08c7af2f8f56caba66232c41._comment |   13 +
 ..._a712ec9b616ca45976154fd0c98ae1c4._comment |   17 +
 ..._7d367f38250a4a3454299170700d5c6c._comment |   58 +
 ..._93b85fbe5c36e986cf7c1fc87070c04c._comment |   10 +
 ..._3db8d28e13f6508e22e8488a6faaa8b2._comment |   22 +
 doc/forum/Robustness_on_failing_hardware.mdwn |   30 +
 ..._d89ffbebe59d05fb2c47d957792cf97e._comment |   21 +
 ...n_a_server___40__no_X_available__41__.mdwn |    2 +
 ..._dd75d78ef63f2689199a302ed1846017._comment |    8 +
 ..._df654df60c5fa6a84d786d248928a352._comment |   11 +
 .../Running_assistant_steps_manually.mdwn     |   20 +
 ..._e14e0a1d55d01cb4f67a94bbe349b872._comment |   20 +
 ..._3192f614c929b8060d4fbde56a7adec1._comment |   14 +
 doc/forum/Running_out_of__inodes.mdwn         |   17 +
 ..._abc73d9ad662ef642337b683bf0a0253._comment |   12 +
 ..._30d58cb046b13d6ddd435ad0ae2f0ae1._comment |   44 +
 ..._31926fc5c095a1d12d4005958047a3d0._comment |   15 +
 doc/forum/S3_Host_Question.mdwn               |   11 +
 ..._8c8ecea703405753e47e0da5e8325929._comment |   11 +
 ..._3d6fa3147d59a5e0d10b005388b23c7a._comment |    8 +
 ..._797edf3ad41561ab8960f3b28d20611e._comment |    8 +
 ...nsafe_to_drop_from_another_repo__63__.mdwn |    5 +
 ..._536a526a78a775142ad66c0689411c6a._comment |    8 +
 ..._48d27b557d31f25fc4b2fc7e4ef55df3._comment |   17 +
 doc/forum/S3_remote_not_available.mdwn        |   31 +
 ..._0caf92239fb1475cf03de45f0d25291d._comment |   15 +
 ..._5895bd050237d08314e3595d93455830._comment |    9 +
 ..._b685f1d172cca4c488a517024c86ba21._comment |    8 +
 ..._ff5ce14bd27b32fc1707426f8c2a5487._comment |    7 +
 ...mote_transfers_queued_but_no_movement.mdwn |    3 +
 ..._fea4e2317f850d6166480cddba088ae5._comment |   10 +
 ..._Jabber_account_for_different_annexes.mdwn |    1 +
 ..._90c3954fe11980eef42b5f5d34f83488._comment |    8 +
 ..._802600b3568e5f94d0550092b22975db._comment |    8 +
 ...er_group_multiple_time_during_syncing.mdwn |    8 +
 ..._files_are_synced_over_and_over_again.mdwn |   58 +
 ..._1260b5ede5a88a95e98855363455ca41._comment |    7 +
 ...ching_metadata_and_file_content__63__.mdwn |   11 +
 ..._25ac180194a59b659e0b02bb95dd26aa._comment |   45 +
 ..._5dd29566dacb5ca70340d54b469c40a5._comment |   12 +
 ..._67715b73349dc92e9746b234024057ef._comment |   18 +
 ..._b8fbd129664c9680cd77f89185974741._comment |    9 +
 doc/forum/Securing_a_shared_ssh_server.mdwn   |    3 +
 ..._ea971b57d94db5b8d487f728faa5e9a8._comment |   10 +
 ..._421a19f6e1fb40db6ee205daf8e3f867._comment |   15 +
 ..._acdbf92f646dbbf691621f08b3d94c26._comment |   12 +
 ..._67533d08e1b8706b844262e9c483d982._comment |   15 +
 ..._bf193e02b388b4358632a169d2425b5c._comment |   10 +
 ..._50d391992cd444080ebc70db30b215c5._comment |    9 +
 .../Sending_requests_across_the_network.mdwn  |   15 +
 ..._8ff713d4c968705061bf2044ea0fe5a0._comment |   10 +
 ..._cb29e5346a8775d87d30b18b7fc005a7._comment |   10 +
 ..._9859c46db3527ad329c8e0df06edd153._comment |   11 +
 ..._b228914d2a3d7838ebc8f1cae4d8b59a._comment |   11 +
 ..._3dba5baa95b43f542fe3737397b8c7a8._comment |    8 +
 ..._6ef44abc1c279abf315b949d2f947fa4._comment |    8 +
 ...ying_the_groupwanted_expression_does..mdwn |   27 +
 ...ial_remote_with_non-standard_ssh_port.mdwn |   13 +
 ..._1eb6990e93ec92cb6fd7dbee59f31072._comment |   13 +
 ..._c85d5167e7ccce1ecf1de396e72ce7bc._comment |    8 +
 doc/forum/Several_concurrent_operations.mdwn  |    1 +
 ..._885edabc67687e727ab1a111d7d10d1f._comment |    7 +
 ..._581e53306e47ddb826c030333f9ae9c2._comment |    9 +
 ..._fe49537fa9e0a284705543b010e7aea9._comment |   13 +
 ...al_lines_for_one_remote_in_remote.log.mdwn |    3 +
 ..._fdfb0099924f19fcbf334498d31f1656._comment |    8 +
 ..._f45a9c92de2d0271e6a427810794b0e4._comment |    7 +
 ...files_of_a_repo___40__Assistant__41__.mdwn |    6 +
 ..._ec0d56cb31b918023a9184cee168b406._comment |    8 +
 ...are_with_friend_copies_only_sym_links.mdwn |   38 +
 ..._a8d22dfefb219f0c9130cc294364b198._comment |   17 +
 ..._Encryption_does_not_Work_as_Expected.mdwn |   11 +
 ..._793c71a1efcf160e1829bec3ef0b1be6._comment |   10 +
 ..._6b603265a2fc78bd2df54102bf94234f._comment |   12 +
 ...ed_directory_with_non_git-annex_users.mdwn |   15 +
 ..._a56cb4993982e030eb9fd4cdb3b0c368._comment |   50 +
 ..._in_special_remotes_without_git-annex.mdwn |   16 +
 ..._d214446e2b5a95a6e14b288457e53305._comment |   20 +
 ..._d7cf8754a3e923d3f90be44ebd224d18._comment |   10 +
 ..._cf81a5c0d055875a858dd1e6a137b53c._comment |   17 +
 ..._82be119d86818f63da519fa1669d8cdd._comment |   82 +
 ..._9852ed3def9f7c73924d8be88b8581e5._comment |   10 +
 ..._cd56ee6915acb9389876b7a4b7c0e728._comment |   10 +
 ..._feda43ef61bc7676c3fd8c9308605650._comment |   16 +
 ..._da33ab62284728f832257014c351f151._comment |   18 +
 ..._eb448e997e4dc77c845bc4a9462ee128._comment |   19 +
 ..._7001fb7530f2ee1591b400195f702cd9._comment |    8 +
 ..._a27a661e8b589cffb4acad3591586433._comment |   12 +
 ...y_without_git-annex_on_central_server.mdwn |   10 +
 ..._286c963b30eee46b261d64937cf66d06._comment |    8 +
 ..._d1f803b68c3789854e483da1318d043d._comment |   17 +
 .../Sharing_annex_with_local_clones.mdwn      |    1 +
 ..._2b60e13e5f7b8cee56cf2ddc6c47f64d._comment |   12 +
 ..._24ff2c1eb643077daa37c01644cebcd2._comment |    8 +
 ..._5359b8eada24d27be83214ac0ae62f23._comment |    8 +
 ..._5c870c49d8093e1a2895224cc6e91ca0._comment |    8 +
 ..._0bf4c0aa3258b156a3df794d5fabb6a2._comment |   23 +
 ..._d2ebe3cc20ec8b7c778c7b22aa62896c._comment |    8 +
 ...47__NFS_while_running_assistant__63__.mdwn |   15 +
 ...al_remote_verify_source_content__63__.mdwn |   74 +
 ..._6de754a926c5ad0e2da6cf6a1c58ce69._comment |   13 +
 ...Simple_check_out_with_assistant__63__.mdwn |    2 +
 ..._ade8a0743ef1ec933c8a40ed64eeac2d._comment |    8 +
 .../Simple_question_about_web_remote.mdwn     |   27 +
 ..._a732a7264b60faed29782a034c0bc592._comment |   24 +
 ..._274810bdc176984c056304e17668c63b._comment |   16 +
 ..._984a3b05bcc6b24430210d9ae039a026._comment |   30 +
 ..._510abbb4deca924020b87f1eb7d61005._comment |   15 +
 ...y_finer_control_over_file_whereabouts.mdwn |   18 +
 ..._bcb883d46a637dd1a8ef9a92733d202a._comment |   10 +
 ..._b7a8b9eaf114f883866fbf2be51b622f._comment |    8 +
 ..._6236bcfa9beba705ead3ec2141c5d835._comment |    8 +
 ..._ea935b37ca93e73c85d04df7c9bf6057._comment |   12 +
 ..._f89a8e38283ac4c8c4a3b74c413d67a1._comment |    8 +
 ..._07a0a754a089c46ff69dc97ea7ba9384._comment |   22 +
 ..._e884c001a556a0c693d1cc9a97c068ac._comment |    8 +
 ..._3e8674b5857e4994dfbc26be4f4b2855._comment |   25 +
 ..._7aeabc2e52a39423e83fbd04560e8f91._comment |    8 +
 ..._53b95449cfad2fe0f72d2ad642822c03._comment |   15 +
 ..._a17c102a45e4fc3f101a79acb8eb4081._comment |   18 +
 doc/forum/Slow_direct_mode_repository.mdwn    |   48 +
 ..._63656f103d418b35712a68f771ed559c._comment |    9 +
 ...ow_transfer_speeds_on_copy_in_Windows.mdwn |    3 +
 ..._dd4ebb10ac87e3ee6158b7e7b1273a81._comment |   12 +
 ..._9ebd40fe286f6c13f1021bf360e9c48e._comment |    8 +
 ..._c169ad6205c998f3d44f9c0859071b2d._comment |    8 +
 ..._aee3fc6be01bb75709451eea0decf112._comment |   13 +
 ..._b1841fc129a9ce6d1c22840ee648f958._comment |   13 +
 ..._1ce9bb47dadd2b1c500b2a20fd669907._comment |    9 +
 ..._4b78b200b884c4ac7c052055b3e26784._comment |    8 +
 ..._97ef11581c5dc6eeeabb4b244bdc6c30._comment |    7 +
 ...rrassing__59___git_export_not_working.mdwn |  243 +
 ..._70a68381641ea3369cd19e2864de753c._comment |   16 +
 ..._57ce71a398b0e2c947164e97ba8d0e2d._comment |   13 +
 ..._b7dcb0a5e69e620278d1aa4d6f5829cd._comment |   79 +
 ..._a5822d922a107e2a0e8972b7f55d92cc._comment |   17 +
 ..._edbc4191d6444dfe50f4c1d7bbab572d._comment |   29 +
 ..._b5072042bda56ad5a781aab8419ede74._comment |   13 +
 ...Some_files_missing_extension_in_annex.mdwn |   11 +
 ..._12ab578a4390c0f5896106906997de4b._comment |    9 +
 ..._7fa25274fb00ba823b112d587c52df76._comment |   11 +
 ..._b05b478e91f58bd4ccd6d8ccf3b7ddf1._comment |   12 +
 .../Some_mounted_devices_not_detected.mdwn    |    3 +
 ..._0ba07b95f12f57ea63bb450b88430c45._comment |    8 +
 ..._4f8c7bcd0f20dafa5635a3580ec8d1f6._comment |   13 +
 ..._06c0db7d670d9b82823102d22db15a36._comment |   10 +
 ..._80820a29361c5be4a94672dacfdefa6f._comment |    8 +
 ..._directories_in_root__58___000...ffff.mdwn |   22 +
 ..._20147b287fd995fa8ac9e868b5974d8a._comment |   12 +
 ..._f6d977a534264b4368401e1b13628931._comment |    8 +
 ..._d534da276b79a40fdb7d8d158f6eae26._comment |    8 +
 ..._8c817d08ca9d94a1228fb21cd0b15744._comment |    8 +
 ...al_remote_public_key_encryption_issue.mdwn |   18 +
 ..._a9caafea017a3c148f89d4ddeee15a4c._comment |   10 +
 ..._adfa582d611ca501e21110282df07315._comment |   18 +
 ..._eac16bf98a6e87461ba2f3ab7e990b2b._comment |   10 +
 ..._097f52aaf178340b3abb5bfc80f0d447._comment |    8 +
 doc/forum/Special_remote_without_chmod.mdwn   |   12 +
 ..._4f5f9506cae72a1f321296fc5a5f339a._comment |    8 +
 ...pecial_remotes_description_misleading.mdwn |   17 +
 ..._5226553dd5f529e3e4882ea18c3be600._comment |    8 +
 ..._616cc2f7d729682c69a9379df785dda5._comment |   12 +
 ...Specifying_private_key_for_ssh_remote.mdwn |    7 +
 ..._94d38f788ab5bc34da9ba56c2fb729b5._comment |    9 +
 doc/forum/Speed_up_remote_transfers.mdwn      |    5 +
 ..._bd97e1c47338322c5232cea7cdbc26fc._comment |   18 +
 ..._723b3b69d47c947e5cbe8e94b84df022._comment |    9 +
 doc/forum/Split_annex_into_multiple.mdwn      |   16 +
 ..._e934b404f738cbd67df928fd6769e3ff._comment |   17 +
 ..._eec6bc8c49c08411a4bb2cf7cc1c4697._comment |   13 +
 doc/forum/Ssh_remote_on_NAS.mdwn              |   34 +
 ..._1dd8a0d0e70a1fb36fce62e89c99b404._comment |   10 +
 ..._261601313d8825c52322949b8509bc74._comment |   16 +
 ..._ed602f4f972b78bce4f62bdfca8cfe47._comment |   11 +
 ..._423244f174123318f1ece7b5794aeea5._comment |   28 +
 ..._07348ed61ccdd93417365f1525a05bf2._comment |    8 +
 ..._26d444afe2edea3500f80bb5c62ba491._comment |   14 +
 ..._3c70f8b9ac2a77462c6f21929c02d9d3._comment |   11 +
 ..._left_in_.git__47__annex__47__objects.mdwn |   39 +
 ..._2aa80b317863a99e676a375d907d0e84._comment |   13 +
 ...andard_groups__47__preferred_contents.mdwn |   14 +
 ..._143aa3095d7222c869c36a5039282e35._comment |   16 +
 ..._65bef012eb113986a2e9b02470a6cbd1._comment |   15 +
 ..._202a7e2820e0adf079ccd14a7993ad25._comment |   21 +
 ..._e0faf9ebd3162e0de860eba0fd28c67c._comment |   15 +
 ..._eb47696244931173bddcbeb8d5f78637._comment |   13 +
 ..._c70c9fa97bce8e4eb9b3880d8f843aef._comment |   25 +
 ..._413593ea0663874196305c9eb602e7c4._comment |    7 +
 doc/forum/Standards_usage_pattern__63__.mdwn  |    8 +
 ..._1ccbfaefe3bbaf767e999cd1c61debfb._comment |    9 +
 doc/forum/Starting_assistant_from_CLI.mdwn    |    9 +
 ..._afd51ddb0f1bb3cac528e1d96829ef83._comment |   12 +
 ..._76c34c00cf2065809b15a594023a688b._comment |   11 +
 ..._f7826867f78b1adbfc2dad2fad4d6720._comment |   17 +
 ..._fa7055a232a1dcb743db47308f7acf0b._comment |   14 +
 ..._8d657646080bf2b99b7792993b877502._comment |   15 +
 ..._Google_Cloud_Storage___40__GSC__41__.mdwn |    1 +
 ..._addbedd6ee8a534c5c4f0e639c05591c._comment |   79 +
 ...crypted_on_special_remote_with_gcrypt.mdwn |   12 +
 ..._5a643827a1ced7c0b9bba5303f71a52c._comment |    8 +
 ..._92e1aef2ce26210b15a908e2cf729b80._comment |    9 +
 ..._12a72b294e2808b09bff6788cf2b19dd._comment |   10 +
 .../Storing_copies_on_LTO_tapes__63__.mdwn    |   13 +
 ..._9ae9ca3983f7d4209fd1de65d982731d._comment |   31 +
 ..._6d16d00c7ef8d846e370e1b298a7bc7a._comment |   18 +
 doc/forum/Storing_git_repos_in_git-annex.mdwn |   27 +
 ..._ac7b52c0b0f75d79760ffe6a9b5c8759._comment |   20 +
 ..._3bec1f02ff1a61791e3cbb428c7acb4c._comment |   12 +
 ..._76ddbd27cc2f3785bb5aaebb0bb6e087._comment |   14 +
 ..._f9520cbc6669622aa342acad35581943._comment |   14 +
 ..._4a5ddb1980b9ba0378531a8d4fb93523._comment |    8 +
 ..._d5676400e7148b7d3408f2bdb3d54b7d._comment |    8 +
 ...toring_uncontrolled_files_in_an_annex.mdwn |    3 +
 ..._175645a90be0c79221c129308adf643e._comment |   27 +
 ..._d29f214eadfe3bfd098bbc3bcf07129a._comment |    8 +
 ..._286b502e7906cca50e9e747db735bc88._comment |   10 +
 ...for_dealing_with_an_old_archive_drive.mdwn |   12 +
 ..._7405e507dd15f207445be1e5099e02f3._comment |   23 +
 ..._bafde6d22fdb5106c2e4a519e5945072._comment |   12 +
 ...__15__58___hGetLine__58___end_of_file.mdwn |   24 +
 ..._7bcc0111015985bde398a2a1a02b28ba._comment |    7 +
 ..._b1dfc6168bb7127312d3e06cc0939b8d._comment |   11 +
 doc/forum/Stuck_in_a_bad_state.mdwn           |   10 +
 ...tupid_mistake__58___recoverable__63__.mdwn |   31 +
 ..._00ceb3a5e37825c4bbc806f532893706._comment |   23 +
 ..._cbedc29678d9b6af3b3c0bb1915d2391._comment |   12 +
 ..._86aa4d92a1330811862da1ba568b3037._comment |   42 +
 ..._6d15bf8a3c3c27cc92957070161675a9._comment |   12 +
 ..._f836b9b1d03d94c49e3798961790b2ba._comment |   21 +
 ...bmodule_.git_not_converted_to_symlink.mdwn |   13 +
 ..._5d95da69235eb3c6b60227544380a4e8._comment |   11 +
 ..._351c58b21d36770729c52991901d668c._comment |   12 +
 ..._636fe0ff273cd8987168e3095929aa7f._comment |   15 +
 ..._ssh_server_back_into_android_version.mdwn |    9 +
 ..._5c2f376a82458c6387560355940419d3._comment |   12 +
 ..._6321dec0b2f22f841f3cb986e063113f._comment |    8 +
 .../Suggestion__58___downgrade_error.mdwn     |    5 +
 ...tion.1_on_git-annex_windows_installer.mdwn |   13 +
 ..._3b1da8ce0dcf43efcdc9b264ef21fb3a._comment |    9 +
 doc/forum/Symlink_points_to_old_version.mdwn  |   13 +
 ..._c9c777333a01865e95332ea7ff1e6cf7._comment |   41 +
 ..._9bf097d27a64743a420cba0136787165._comment |   10 +
 doc/forum/Sync_All_Missing_Content__63__.mdwn |    1 +
 ..._fbe27e8dc9dd85e860b3382f99426c14._comment |   18 +
 ..._d77b7f56dcb8bf384f5a19bf54fe629e._comment |    9 +
 .../Sync_Enabled__47__Disabled_Status.mdwn    |    1 +
 ..._cfe98bdd50cea0fd0e36a42892262084._comment |   15 +
 .../Sync_files_from_remote_to_remote.mdwn     |    5 +
 ..._c5247657a5b3cd68fd55112efe97ef99._comment |    8 +
 ..._634e399d21271f26f7f77c15c5fb132b._comment |    7 +
 ..._b89701582b40e2c337a1a49733877210._comment |   10 +
 ..._b3ad93e032c3c9d2312970711540bf92._comment |    7 +
 ..._bdf293d30692311983d0586231535bd4._comment |   20 +
 ..._fda62d735035213f2a0b5b2fc95991ab._comment |   11 +
 ..._77c6550397435e9601fbae467be90976._comment |   12 +
 ..._4d3c05acc310a21f6c8ab77fb2638a8c._comment |   11 +
 doc/forum/Sync_files_via_remote_server.mdwn   |    5 +
 ...her___40__rsync.net_to_s3__41____63__.mdwn |    1 +
 ..._68e73ffa29338214fa030c5f0e2823c6._comment |    8 +
 ..._3d57de3c12527e5a4b30ff7982ae749d._comment |    8 +
 ..._94b40e68418f732322c9a01418688165._comment |    8 +
 ...ot_available_from_my_central_git_repo.mdwn |    7 +
 ..._b31d02c97447996495de73705ac39f71._comment |   12 +
 ..._098465ae8af32931779d2cd63750d5dc._comment |   10 +
 doc/forum/Sync_with_one_offline_peer.mdwn     |   11 +
 ..._3859d842d4f7e2ef44877b05ebe881fb._comment |   20 +
 ..._c9ba3983b37b0c1868269616fd81e518._comment |   14 +
 ..._28b9c003b4560c3ce90c9ebf808b091b._comment |   10 +
 doc/forum/Sync_without_jabber_account.mdwn    |    9 +
 ..._3e95ac2e67451f953cf0538094109f8b._comment |   10 +
 ...ize_large_files___40__VM_images__41__.mdwn |   10 +
 ..._619f6ed2d7da5832ab253d61b6dd8044._comment |   10 +
 ..._bbd98d0b5d77dc7efc55ef8c2a18d612._comment |   13 +
 ..._6488bbe6f39e7154f950530498e9b548._comment |   22 +
 ...chronize_two_latops_with_a_ssh_remote.mdwn |    3 +
 doc/forum/Syncing_Compressed_files.mdwn       |    1 +
 ..._e44598cd735830a8df9a29e0031d34f1._comment |   10 +
 ..._db1ea446ae9720fe1651c56da38e7088._comment |  158 +
 ..._885c045c8ddfccbd426a6bc1bc053435._comment |    7 +
 ..._d619d9b7ad4ca3f2fa9505ea928d5bf7._comment |   17 +
 ..._0c7af752cc35013273a07a5fa1f71f6e._comment |    7 +
 ...yncing_machines_on_different_networks.mdwn |    9 +
 ..._1c3523c722c178a96b096a68b9be4165._comment |    8 +
 ..._d7b14ffee65072329cfe9ab08a0dba50._comment |    8 +
 ..._65d1dae9b76fccb5f2b8fd8c69b60075._comment |   15 +
 ..._2ec67428af69d6c0ea051c6a67d58905._comment |   10 +
 ..._5ce093f82a2aad3fd8d7ccd5fdcab94f._comment |    8 +
 ..._a55982c28d7b90e0b70ec2bb5e594e08._comment |    8 +
 ..._c519d546e1a2a4e834609f3de3a605b0._comment |    8 +
 ..._84a822238ddbaf211cce5f527c3559d3._comment |    8 +
 ...nclude__39___rule_for_duplicate_files.mdwn |   17 +
 ..._5d776e90c24c4eed14ae01c6019c76b8._comment |    8 +
 ...emote_from_a_different_computer__63__.mdwn |    4 +
 ..._cd55d06a4065b9d3f14d50674c3fcaf7._comment |    8 +
 ..._25cbdf478091af9923090e049c432a7d._comment |   22 +
 ..._7e71d355457d6b1a0391d4cdae6895e6._comment |   16 +
 ..._a73f67f2fcf0762fbd7c8366b3844af6._comment |   11 +
 ...nisation_between_3_repositories__63__.mdwn |   11 +
 ..._ca5192a26950627a1c2efcb55d6d2fa3._comment |   10 +
 doc/forum/Termux_Android_8.1_Proot_Error.mdwn |   17 +
 ..._1ef5f1b83e1bc0061d9fb1bba601a692._comment |    8 +
 doc/forum/Thank_you.mdwn                      |    5 +
 ..._3be1d5e92c3abc222713c75169b43dfb._comment |    8 +
 ..._while_committing_it_repeatedly__63__.mdwn |    3 +
 ..._3cbe520b184d323219cb402ff046c3b4._comment |   29 +
 ..._6afe7f593e955db2eefe87d9fa01882b._comment |    8 +
 ..._209399487fc4f76b29f03ad82dbc2d6f._comment |    8 +
 ..._f33fd6f72cb9ad7dd20a04c82199413b._comment |   26 +
 doc/forum/The_future_of_Direct_Mode.mdwn      |   32 +
 ..._f16f6e41f01d59ccef9666a2ec46d294._comment |   32 +
 ..._c7408d45d0a2a854020e4169fe757d51._comment |    7 +
 ...lowed_commands__58___scp_rsync__160__.mdwn |    5 +
 ..._68e911629da672473bd6188407a68be2._comment |   13 +
 ..._glacier_remotes_for_archive_purposes.mdwn |   22 +
 ..._c874e49e668baa1fed293318cef88dd0._comment |    8 +
 ..._28926e01b82de55352702182730a6b4b._comment |   12 +
 .../Time_for_another_user_survey__63__.mdwn   |    2 +
 ..._e746e11d30049906758a015059658e16._comment |   10 +
 doc/forum/Timeline_of_git_reinject__63__.mdwn |   50 +
 ..._e88d612590d3cd0c2ea824c1e8a38678._comment |   19 +
 doc/forum/Timeout_sync_faster__63__.mdwn      |    8 +
 ..._eb4c13c1ad9803f402215478c0baab2b._comment |   12 +
 ..._16d655b754d2d512c2b01bac8276f31c._comment |   13 +
 ...ory_with_some_hg_and_git_repositories.mdwn |    1 +
 ..._9fc3f6c2f7379755e0084a850fa9acd4._comment |   10 +
 ..._f024d6a105143af1e06aafe49661ee06._comment |    8 +
 ..._aff0093c38bda8b093f05e8cbe8775e9._comment |    8 +
 ..._c889050d3079edefc4633451bd5baff8._comment |   11 +
 doc/forum/Transfer_remotes.mdwn               |    3 +
 ..._c08cf3bda00d7f20a3ca3d0fdba19c9c._comment |    8 +
 ..._98930629d398329f1161135464a966a5._comment |   12 +
 .../Transparent_compression_of_files.mdwn     |    5 +
 ..._7242325defa000572ca8e78e29012451._comment |    9 +
 ..._a75e32b0825de0b405c45de14b9711c0._comment |   14 +
 ..._a876239d4a2fe96f2e2fe1c16e7f202b._comment |   11 +
 ...ssh_remote_using_assistant_on_windows.mdwn |   19 +
 ..._0055392bfead0dd1d9dc1a196a6e5269._comment |   14 +
 ..._3ec8af32b8148d31aaa3ba781b4dcf89._comment |    7 +
 ..._8ddec87534a9025c26394fecd5456b84._comment |    9 +
 ..._9c12c508f62f2e76d09f4ed15af9c74e._comment |    8 +
 ..._b496f6938bd463de501eaa5c1850ce5c._comment |    7 +
 ...stalling_from_cabal_on_debian-testing.mdwn |   17 +
 ..._0d3e9d7cffafc34bc212557e8bbb987d._comment |   12 +
 ...public_repo_cloneable_from_a_web_site.mdwn |   35 +
 ..._34a858688c46faf624fa7d98b05e6519._comment |   11 +
 ..._409103144cf803ced9d81d3380ca76fb._comment |   13 +
 .../Truly_purging_dead_repositories.mdwn      |    1 +
 ..._a4c75d49714b3543a9f1617a15d4a2d1._comment |    8 +
 ..._3da60a02e7323a204c5c5dd02ba04d6c._comment |    8 +
 ..._2576e45436008ff5a7ae5a38cade658e._comment |    8 +
 ..._477e3c213c5a5d4a33afd42a5b94c718._comment |   10 +
 .../Trying_to_delete_an_S3_repo_fails.mdwn    |    3 +
 ..._d8ab7757cd224439d55a18bfec405772._comment |    9 +
 ..._94653e0c2c9e3e3be45c383442c7ec9b._comment |    8 +
 ...backup_repos_that_sync_with_eachother.mdwn |   30 +
 ...nd_git-annex__44___need_some_feedback.mdwn |   39 +
 ..._86a86f1f3ea2e778e4022689391b887b._comment |   16 +
 ..._77d61eceec24d2f41f044a643d8542cc._comment |   25 +
 ..._529cada8df4888c12254818c26231835._comment |   10 +
 ..._1561613ff2f0f3d7b42159d09ae1c7f7._comment |   10 +
 ..._59991756981681648070d03e2277ccbb._comment |    8 +
 ..._eeafd62249d44b89d1091f0be79b3086._comment |   18 +
 ..._24a20071d43ded3be9c4c68a637ca4f5._comment |    8 +
 ..._8ad6bd5fce8f9bc1622f225c162ae167._comment |   43 +
 ..._6406fcf0021ac8266b4f2ef850be0fa0._comment |   12 +
 ..._backup__34___repository_groups__63__.mdwn |   18 +
 ..._b8702892280447193e6e80be22a580a0._comment |   11 +
 ..._50cafde7e30b928480d1f142ddd763d2._comment |   10 +
 ..._no_Jabber_-_how_to_setup_sync__63___.mdwn |    7 +
 ..._b90aef011d853ad9feb6f8edc08bf7d9._comment |   16 +
 doc/forum/USB_backup_with_files_visible.mdwn  |    7 +
 ..._b90b18ca57f9299f1920254bb2aa699b._comment |    7 +
 ..._2832f8ae24dfb0f101e06f7c18283028._comment |   14 +
 ..._6163e01aa441f8435091f026cc6da337._comment |    8 +
 ..._ee92ff320eb5d9a031bdd1896aee0d86._comment |   11 +
 ..._437c8342c0b65e3a89129800313eb73c._comment |   10 +
 ..._5e10cffe8465ea4ecaa71c03a4c29ea4._comment |    8 +
 ..._add048a16837f7940a859f21426cdbe9._comment |    8 +
 ..._de227ca9911fe57d7a6d3e037f574fe9._comment |   14 +
 ..._0c0ed0e038f7f0e2d2d4ed69b7b29fbc._comment |   10 +
 ..._dfb830fb00c10b797c3d26179e6dfefd._comment |   14 +
 ...nsfer_group_keeps_growing_-_assistant.mdwn |   22 +
 ..._0a6f6054d70009979f4a036e24b7c500._comment |   10 +
 ..._f9eef3019fe690e90c1228d62a16f70a._comment |   10 +
 ..._7fb74f7fab6c1baff4ffc270cf15ef0a._comment |   15 +
 ..._5925b609aff0954f2860269cff107284._comment |    8 +
 ..._45062d5776f8aefb0850d70f2a517c75._comment |   12 +
 doc/forum/Ubuntu_PPA.mdwn                     |    3 +
 ..._b55535258b1b4bcfc802235f0cba075d._comment |    8 +
 ..._adc4d644fed058d1811acf0b35db9c18._comment |    8 +
 ..._fc9cd51558c47718f243437202a11803._comment |    8 +
 ..._3a8bbd0a7450a7f5323cd13144824aea._comment |   12 +
 ..._2e1beaeebda0201c635db8b276cedf20._comment |   12 +
 ..._bd99fb70399fc58d98781a89c6d38428._comment |    8 +
 ..._c3f7ec8573934c59d70a48e36e321c13._comment |   12 +
 ..._feecd478a4d44cb5ffc7020c646174ba._comment |    8 +
 doc/forum/Un-git-annex__63__.mdwn             |    6 +
 ..._6059265afb66190d325083e0f28bcf33._comment |   10 +
 ..._fac4bfb81dbbf0dc82059aace261eb51._comment |   10 +
 doc/forum/Unable_to_change_RSS_feeds.mdwn     |    8 +
 ..._9f6517f3c6dc8cd4e27d0011efcf2bb5._comment |    8 +
 ..._9ed0f746a199bb0ce474b2e9fa4f0a9e._comment |   28 +
 ...pping__34_____38___cleanup_of_history.mdwn |    9 +
 ..._08dbad67df1d8f07d3883c6fed2fe0c4._comment |   16 +
 ...ndo_Git_Annex_Changes_To_Linked_Files.mdwn |    7 +
 ..._568dde820c2608d86d05b07444146a26._comment |   13 +
 ..._a8cf71cdf1217d9c8596cd9006eb83f5._comment |    8 +
 doc/forum/Undo_git_merge_git-annex.mdwn       |    3 +
 ..._0b15f7a8c3bca87dcbf748a229e13a4b._comment |    8 +
 ..._c5a8839c53145a3b0d44950096c5180f._comment |    9 +
 doc/forum/Unknown_remote_type_S3.mdwn         |    5 +
 ..._2aea2cd51286c809427d16519606cd37._comment |    8 +
 ..._06f775062cd30767979fe56bcb3cf7bf._comment |    8 +
 ...files_when_assistant_is_running__63__.mdwn |   13 +
 ..._3f4aadf0c856c81e15c6f5ae7f1992b4._comment |   10 +
 ..._a76797ee9e05e43af7947508cadd7bed._comment |    9 +
 ...3___Having_all_its_new_files_unlocked.mdwn |   13 +
 ..._cd08064d171bea606df1cb7dafbdd381._comment |    8 +
 ..._6da3347c2d9243a9fe61fd75999d6f36._comment |   12 +
 ..._78dfedd93393709d3d7e417b779109d4._comment |   12 +
 ..._bdd6cb9cdf2366e5d930c0cdd80b3984._comment |   13 +
 ..._7a2109bbe16de4c05db48763d00bfaf1._comment |   18 +
 ..._9ed97ec6e540f2b795bf5bc11fcfdc90._comment |   13 +
 ..._c6f1dd606d2aa9aa473cdd3a6d92bd33._comment |   11 +
 doc/forum/Unlocked_files_confusion.mdwn       |   40 +
 ..._6442aa304b4d44bfc6bc038f4b55f37a._comment |   15 +
 ...data_also_under_.git__47__annex__63__.mdwn |   13 +
 ..._d35829cd466139e0e77a79c251a79ad8._comment |   32 +
 ..._07861ab33ec31659ec3cfa8520580fd4._comment |    8 +
 ..._ce7ff5d0ea390649af64a296fecf9113._comment |    9 +
 ..._b7eead64e39b5ebb1a22131b4e35251e._comment |    8 +
 ..._97fd65626991b1e8012e15595941d25d._comment |   24 +
 ..._f2572320e3cc93c7dd6db51e78f31c10._comment |   14 +
 ...Unlocking_files_gives_symlink_content.mdwn |   14 +
 ..._f8032a5ea72f2cd833a626a197f94ba2._comment |   14 +
 ..._f50b8ef54737798183490d5a660248f2._comment |   11 +
 ..._29e467b112a94736147708c6892dae9c._comment |   10 +
 doc/forum/Update_on_remote_repo.mdwn          |    6 +
 ..._d58cfe914d6c36d8bff8d1342e1c2102._comment |   11 +
 .../Updating_a_podcast_episode_checksum.mdwn  |   27 +
 ..._8a4c7119f55dba5ff3cb858dbc96f1a5._comment |   13 +
 .../Updating_repository_permissions.mdwn      |   18 +
 doc/forum/Upspin.mdwn                         |    5 +
 ..._30adffff50a043c14b765ebdc6d637d2._comment |    9 +
 ..._addurl_with_a_file_on_an_HPC_cluster.mdwn |    2 +
 ..._55d285c796f04049e26b6810c7c879ad._comment |    8 +
 ..._7c7c0b3442902dbe0b9f875e0f1b634a._comment |   17 +
 ..._bc5ffcf6d3b72c1ed7b7763549880560._comment |   21 +
 ..._3bd66bf73386821c3837fe9da841fd1e._comment |   12 +
 ..._a5bd659bc98d6879b5175dc53915fdc8._comment |   14 +
 ..._9ec91c1eb9fe119c52831a4ce5c44e25._comment |    8 +
 ..._bc7a29f8da461439cfb3cb270403181b._comment |    8 +
 ..._4c8eb6c893ccd0a075500f4b9d4bccd9._comment |    8 +
 ..._12f6a1b93c36095f12e2a721311dee2a._comment |    8 +
 ..._83228ff27a74b575b77f0e380e13cc8a._comment |    8 +
 ..._23ae2824d52b1f165b02294b0f89d704._comment |   10 +
 ...ssistant_to_sync_just_git_repos__63__.mdwn |   11 +
 ..._d487c7097db97e316f086742e851b01f._comment |    8 +
 ..._f0bb3c9461a6b84ca034ebfff814dc77._comment |   11 +
 ..._809b8a20c4de0da47e3f6bf794043744._comment |    7 +
 ..._fc4f3e2692c98e8168c8cbc696726f98._comment |   11 +
 ..._e9d1f0a0b10a16079f06b63251806b0e._comment |   55 +
 ..._0bd5e37ad9428eb38d2fdb84e58a0c2a._comment |   11 +
 ..._4ba1e89d84fedfd6508f37717310893d._comment |   14 +
 ..._d57eb0b4d41600a6709c03f00a9091be._comment |   10 +
 ...__portable_drive__44___backup_machine.mdwn |   26 +
 ..._d2991b94eb067f0a6e47cd77f922411d._comment |    8 +
 ..._0b778710b23eab1413256e289f0aa180._comment |   32 +
 ...e__58___backup_on_multiple_USB_Drives.mdwn |   19 +
 ..._5d45ee72f91af9ec8384b178af77bc2d._comment |    8 +
 ..._502fedae83c3b6e0b32897ce4c1a8317._comment |   13 +
 doc/forum/Use_case_for_addurl.mdwn            |    8 +
 ..._2205b1857158cca4f6e2225c53bec1d5._comment |   16 +
 ..._syncing_only_a_subset_possible__63__.mdwn |   13 +
 ..._a0a272a0931b27e5c94b93e42656b62c._comment |   10 +
 doc/forum/Use_existing_S3_bucket.mdwn         |    8 +
 ..._ed0ead0b09ddbe52d42150a281d84f5c._comment |   16 +
 ..._6b108846fca4a514d507f56d1052fdde._comment |   13 +
 ...tead_of_re-downloading_from_S3_remote.mdwn |    3 +
 ..._cfb6021a36eee087705967a69967f327._comment |   10 +
 ..._7268b194ba72331858bc3274996b780e._comment |   11 +
 ...media_collection_without_modifying_it.mdwn |   34 +
 ..._76307d95cf46992fbc5f084f9c056edc._comment |   16 +
 ..._b89b598844b0709a5b6709d0fb2ef60c._comment |   12 +
 ..._2d707dc516dad666fb2a647f65fcedcf._comment |    8 +
 ..._4529364f2919bd05f53da94cf8ba4268._comment |   23 +
 ...keypair_without_password_prompt__63__.mdwn |    7 +
 ..._b177f16daeab7f02022f18154cfa1c3c._comment |   14 +
 ..._6d88e5a48de78e6add0e4e4b6ebc3f1b._comment |    8 +
 ..._a2eb4244788eebba5167cd32a73ff204._comment |   11 +
 ...s_on_BTRFS_instead_of_symlinks___63__.mdwn |    1 +
 ..._85806316ed28d7a891f04fab4027141b._comment |    8 +
 ..._ecb411a2c4d67917b734a90bd460d44b._comment |   10 +
 ..._83dc719be1883d5369d27a787a5b5705._comment |   14 +
 ..._bbe2e6359f7b754bde9d61b5a8d5e672._comment |   18 +
 ...___while_also_cloning_and_syncing_too.mdwn |   11 +
 ..._30205c1ba18e5dca2314f593e1a0e236._comment |    8 +
 ..._f8df728de28218a6b060ae9f08adac79._comment |    8 +
 ..._ba438b3a371261ee841665f1ae57eba2._comment |    8 +
 ..._9f72e6c7c14a77330297526aef260762._comment |   11 +
 ..._a06e8c9b4e30c1cd6cbed40d2db50abc._comment |   10 +
 ...4____40__+__41___Local_computer__34__.mdwn |    9 +
 ..._f803fc1fb340587fc4b55640fbae6604._comment |    9 +
 ...__41___to_manage_photos_with_Shotwell.mdwn |   13 +
 ..._5e8d54daf6b7ff357619ac65fe39a2d7._comment |   12 +
 doc/forum/Using_Linux_static_builds.mdwn      |   25 +
 ..._22fd266cbe68af3e754a10f1f1295e9b._comment |   13 +
 ..._36f69f30117ff8696425a754ab19a08b._comment |    8 +
 ..._64506833dad0202626239e00d1eb6490._comment |   23 +
 ...sync__34___to_sink_all_branches__63__.mdwn |    9 +
 ..._ef3d5c5e2600ffa36dd933c8a42cdf96._comment |   16 +
 ..._424b0c6fdfe87ca08f5d408b7684ab08._comment |   10 +
 ..._adaf9114c69f1268330adcebd8018fa0._comment |   10 +
 ...9___in_mixed_content_repository__63__.mdwn |   46 +
 ..._4b524cbbd40aedeb7d44f0c6dec9ffa1._comment |   16 +
 .../Using_a_glacier_remote_as_a_backup.mdwn   |   28 +
 ..._bb6022943ec739b1e80351c76f259e89._comment |   17 +
 ..._41d47f0ca2e05e3296face5f89b819da._comment |   15 +
 ..._e572b7bd25b4e7f6c6f83c7354d7407f._comment |    7 +
 ...ltiple_independent_client_repos__63__.mdwn |   36 +
 ..._c61c28600f1079fb03ddabc950307f27._comment |   11 +
 doc/forum/Using_for_Music_repo.mdwn           |   13 +
 ..._3488ed85ad98f14cb17f229225ece26e._comment |   10 +
 ..._c794648878cfc77558f8db862271f997._comment |   25 +
 ..._8c5e820f5ff7d717d64b1fd66927941b._comment |    8 +
 doc/forum/Using_git-annex.mdwn                |   73 +
 ..._ac386ca07e9aaf009c264f3deed83832._comment |   16 +
 ..._bf5e13a490e16943acd2732f093695fc._comment |   16 +
 ..._471c9268b028f47ef3fac3f0be14b2b1._comment |   15 +
 doc/forum/Using_git-annex_as_a_library.mdwn   |    1 +
 ..._cfded5c6325007c3f3f83818bd2e1dbc._comment |   16 +
 ..._1f8e74c5856f21c53d5a91892cbef0c6._comment |    8 +
 ..._11a243fa7d8ac947aa9a798228dbd191._comment |   12 +
 ..._ac52304a096ebc66967352efaffb060a._comment |    8 +
 ..._d502fea60bf3a82f8a50f72a90a80c25._comment |    8 +
 ..._a4ab4173620b72ac0a24d575fa9c810c._comment |   13 +
 ..._45d9520ebc13d1b4fd88c25abc61f1b4._comment |   11 +
 ..._909628f1edd0d3448498fc434c61a3a4._comment |   10 +
 ..._cef28b8639b6c6e84804b485fb5037f1._comment |   37 +
 ..._6d8ebdedf76fdf0c267444a7a07e225e._comment |   10 +
 ..._git-annex_to_manage_git_repositories.mdwn |    5 +
 ..._f221717814f62e0779d691d2f601ab12._comment |   27 +
 ..._ab24098c2f4519cbbfdcd00ba3e21d2b._comment |   10 +
 ..._5cf9e2ff83bb76650469444c80fee4fb._comment |    8 +
 ...ng_git-annex_via_command_line_in_OS_X.mdwn |    3 +
 ..._1c9e121f60fb6868c07f1a53b03c4ed0._comment |    8 +
 ..._52d8ffba82e29ac2722a8e43e469cc47._comment |    9 +
 doc/forum/Using_git_annex_as_a_library.mdwn   |    6 +
 ..._42cd26878e4e5c2c238c1227e3c372d9._comment |    8 +
 ..._1323238fc63e121fbc0f408a23d1ada5._comment |    7 +
 ..._which_only_has_exFAT_and_no_symlinks.mdwn |    8 +
 ..._b9f202a30ba7e3bc264064d24454c099._comment |   12 +
 ..._1334a8d9f4bb60f3bf3ebabc656d98d9._comment |   18 +
 ..._076f22d05fad140068a540e4d835106f._comment |    8 +
 ..._c8446ee1b817f1824fa0df07e742015c._comment |   12 +
 ..._f746c1b85ee8e4b57b6819ccceabd28b._comment |    8 +
 ...7__FTP_TV_NAS_with_preconfigured_dirs.mdwn |    5 +
 ..._bd73c8d10028e1b45da9ea8f657e5064._comment |   10 +
 ..._16c3c994ee8fcb466e52ca0e812e5915._comment |    8 +
 ..._ac60f6edb76bdd541711e472eec9591a._comment |   10 +
 ..._2194f0600d9a90f0d9c947ea9cc213a3._comment |    8 +
 ..._eb7d13f6b6fa674a2536bde51bfc3fd1._comment |   48 +
 ..._ae323b16ddb9342e91be955408eca3b1._comment |    8 +
 ...dirlower_layout_for_S3_special_remote.mdwn |    3 +
 ..._ff8c84af9d08dfe7d8e502d1b84732f4._comment |    8 +
 ..._9f22f7f14fab759caa1ddecda435311c._comment |   13 +
 ..._d90ee84a9b0cf190961d92d089dbf7a6._comment |    8 +
 ..._5aa6dff353af7beffdd56652d6fc6d3e._comment |   10 +
 ..._79519a4c0fc25d41226a7048cd3a8306._comment |   24 +
 .../Using_integer_ranges_with_metadata.mdwn   |   40 +
 ..._36298a679379e807892cd6af18ec1dd6._comment |   13 +
 ..._064e2c5706d1acc0f9e4576ff80407f7._comment |    9 +
 ..._c3ce727f93cce19db1f76de9f7216cee._comment |    8 +
 ..._c3301d1b2b57994666947fd518fb9922._comment |    9 +
 ..._9d310fac003f1cd9e6ca9bc96a210def._comment |   11 +
 ..._ead2b08bf4631547c34486ce58559017._comment |    7 +
 ...ve_history__58___--all_not_recognised.mdwn |   33 +
 ..._c3dd239d4b5b372229f2cec42a8a6eb4._comment |   10 +
 ..._b76dd79aabe87ec717eea164aa965d74._comment |   12 +
 ...stant_as_a_Backup_and_Syncing_Service.mdwn |    5 +
 ..._7070f6e7e05fba7686d8620d62906a83._comment |   12 +
 doc/forum/Verification.mdwn                   |    9 +
 ..._d56818a8f5b3a94ecf5159c76f24768c._comment |   18 +
 ..._7df45d1e20a32458791603d5b9fe3dc4._comment |   15 +
 ..._74db3ec8b03f48912306e48b8d5f7242._comment |    8 +
 ..._eb4d936a9bd577f58483b278ae5dc5f6._comment |   15 +
 ..._c327c72ceced27920681d5f93bc256c8._comment |    9 +
 ...th_git-annex_client_8.20211123___63__.mdwn |   28 +
 ..._780fb88d5cfcde6e8a8b6f025be6a043._comment |   11 +
 .../View_for_locally_existing_files.mdwn      |    8 +
 ..._8ede4c8f1ca48e34629c46a77ba01f11._comment |    8 +
 ..._e8d7672850518f4859643a0ee40e57e1._comment |    8 +
 ...iew_performance_with_7__44__000_files.mdwn |   26 +
 ..._e45ea752100d09d29efb6136a722eab3._comment |   34 +
 ..._b1942eed65e9b5c046095a094191a38c._comment |    8 +
 ..._e6e19339c9d72cf8eaae32ef4269e850._comment |   10 +
 ...View_special_remote_information__63__.mdwn |    1 +
 ..._7c106e0679890f7279c73b5c52d648e2._comment |   10 +
 ...r__58__git-annex_has_text_relocations.mdwn |    7 +
 ..._fee360353f0b46aab6ee7a902c0837bb._comment |   11 +
 ..._me__44___what_am_i_doing_wrong__63__.mdwn |   16 +
 ..._cdac15fec6fc41d5487b7f653fa718a4._comment |   14 +
 ..._82050b7dc367ca5968ab0306db9bd7e3._comment |   10 +
 .../Walkthrough_for_direct_mode__63__.mdwn    |    1 +
 doc/forum/Want_to_stop_using_Git-Annex.mdwn   |    9 +
 ..._32e37515bd4f5d22ff9aedd3c9d98046._comment |   10 +
 ..._e29e6d052ef3677ad7d5615721f3fe33._comment |    8 +
 ...ync_slow_on_thin_copy_of_large_annex..mdwn |   22 +
 .../Wanted_content_based_on_date_added.mdwn   |   12 +
 ..._af2a6e6cba4cdfe24e9ee2c819a007eb._comment |   17 +
 ...er_on_each_command_Android_8.20210429.mdwn |   23 +
 ..._02c38a5dc1c2213dd5f12c4b7fb0c72e._comment |   11 +
 ..._02e5631245348bcef541360b5ca0e9e5._comment |    8 +
 ..._12c9af06c1473de6740b782ca42d6a5a._comment |    8 +
 ..._daa8522e3be6a0563d7cd107e79577b8._comment |   27 +
 ..._32c3cae8fb69c42747bb3ec4f3926dfb._comment |    8 +
 ..._95e16558f7010627ef4136043f63b937._comment |   10 +
 ..._733131f7608bc0309c034a954f297275._comment |   16 +
 ..._c73d26803fcc932edd7049efd0318aab._comment |   13 +
 ..._3eb65e0d204832d7d8700a85b3f4e51e._comment |    8 +
 ...__assistant__47__webapp_documentation.mdwn |   12 +
 ..._adb377589dbae7fc91001df235c6b48e._comment |   14 +
 ..._other_directory_without_change__63__.mdwn |   14 +
 ..._1c324fdc46fe9db3778bf21d9fbdd021._comment |    8 +
 ..._9d18e0752ae4b1ded9611759fbe2eeec._comment |   20 +
 ..._61841267c85651158652b20b137fb5fb._comment |   21 +
 ..._f414a1d2c54eda4602d224a937d413b7._comment |   20 +
 ..._8290c580d2788dbefb4e41cb9671eecb._comment |   32 +
 ..._files___40__the_symbolic_links__41__.mdwn |   12 +
 ..._5f452eeb652e1bbec54cddc3735a6d4a._comment |   17 +
 ..._56617a9d760e7528d7b30ed479e5070a._comment |   28 +
 ..._8c8f09c8a916dd44d787a02f1570bd82._comment |    9 +
 doc/forum/Way_to_list_missing_files.mdwn      |    1 +
 ..._d302a4b64cfca76e8af756018768ff08._comment |    8 +
 .../Web_app_on_server_without_X11__63__.mdwn  |    3 +
 ..._bee409ad389e5fb5f3e8de4b5c68278d._comment |   10 +
 .../Web_interface_to_git-annex__63__.mdwn     |    5 +
 ..._371586edbeca15724121a5123bce66d6._comment |   12 +
 doc/forum/Webapp_not_watching_repos.mdwn      |    1 +
 ..._02735050122afdb6498d91b462d32767._comment |   12 +
 ..._8ab2d4c18ddc99774e44c4f4401bfa57._comment |   12 +
 ..._b448aa5a95a57a5228b361390e5fc838._comment |    8 +
 doc/forum/Webapp_on_ARM.mdwn                  |    6 +
 ..._82ac40cef5b59070136527b8d81a5ce2._comment |   10 +
 ...vior_with_OS_X_Finder_and_Preview.app.mdwn |   12 +
 ..._8c8d86790a9d31518f9bb96a2d2dafee._comment |   18 +
 ..._b538dc2c6f122b9ce5f7569de1b03f3e._comment |    8 +
 ..._16e6724fa184392d4decbe0c4eb6efe6._comment |   14 +
 ..._e514fe2d4d0ad6a10e281939e6ab4266._comment |   15 +
 ..._e0eec765f72f7bf6f5a2a92c9b5dacad._comment |   10 +
 ...etween_encryption___38___gcrypt__63__.mdwn |   11 +
 ..._e4e9c6858fe905b17154e19cbe7ee2f5._comment |    8 +
 ..._359e52a73f236bce4e8e31e76436fba7._comment |   10 +
 ..._d43cf2928e2ebbf2793911e49cffd671._comment |   13 +
 ...What_am_I_doing_wrong_with_move__63__.mdwn |   48 +
 ..._a49d98426ef8dd17e6cca6b5fba5c9bf._comment |   21 +
 ..._eeae2f172b4481fcb08745fc28aa4d4e._comment |   42 +
 ..._f2770f86138d9b8489fbf9a25462b4ce._comment |   10 +
 ..._76aa27cdeefb1413baaa1c891ccd4d0d._comment |   27 +
 .../What_can_be_done_in_case_of_conflict.mdwn |    7 +
 ..._5ca86b099dfa08a50f656ea03bf1dcd9._comment |   12 +
 ..._69ee17959a92bb8359c0fd7b2a9d8dfb._comment |   10 +
 ..._017f4bac57a040c496e0c9d068dcfd9e._comment |   41 +
 ..._expiry_after_X_days__34___mean__63__.mdwn |    1 +
 ..._face45c85e4713325bb23bbca7b07502._comment |   28 +
 ...es_a___91__RepoName__93___means__63__.mdwn |    5 +
 ..._9b1cb4beea0f67d7e7375e7ec189b802._comment |    8 +
 ..._a233086f100fec27cd26f4d39c25a385._comment |   26 +
 ..._4b62bf0c03fed86270a7873a8835dc7f._comment |   12 +
 ...hat_happened_to_the_walkthrough__63__.mdwn |    1 +
 ..._70db0e3cfb1318e95671c23726e5541d._comment |    8 +
 ..._f9305dd19b9b5f35e66d915b8c30374b._comment |    7 +
 ...ated_add_of_huge_picture_folder__63__.mdwn |   77 +
 ..._0ba60f9625ccda45d59adbd385f5fe98._comment |   12 +
 ..._f0a2ec3d0b05d84fb05a1708313a6762._comment |   12 +
 ..._f628f146a0c652f812c09f78bd574b77._comment |   24 +
 ..._34___on_an_existing_repository__63__.mdwn |    1 +
 ..._d844cfe5f9907a766e871b64d68966c2._comment |    8 +
 doc/forum/What_is_going_on_here__63__.mdwn    |  187 +
 ..._499bf04c32c86a747bd7c38d13f5de50._comment |   18 +
 ..._0acd71ec48c69da62886e69afa496120._comment |   54 +
 ..._a1221c0a0585b7e60643a8e4a50b282b._comment |    8 +
 ..._a9fa5282774cc32ece9196b864435957._comment |   28 +
 ..._8e35d10c208d0d1e93254a1a275fcba6._comment |   20 +
 ..._536adad665f481a15d4096360d0106c1._comment |   10 +
 .../What_is_the_assistant_up_to__63__.mdwn    |    5 +
 ..._9baa0e54c19105c7cce946c19c587866._comment |    8 +
 ...o___34__git_annex_mv__34___file__63__.mdwn |    1 +
 ..._02d305f307b4d2ff7acd98cb36508a2f._comment |   10 +
 ..._9f7daf0a3e53b2cf64b2b64ca6fbfd9b._comment |   13 +
 ..._06b137018b4c995afc8891032704c1d8._comment |   36 +
 ..._138d9067831e26407404b993199d5a0f._comment |   35 +
 ...r__34___and___34__remote_server__34__.mdwn |    3 +
 ..._68734a118b7dc0c88ba67eca20953a55._comment |   10 +
 ...perations_are_safe_to_interrupt__63__.mdwn |   34 +
 ..._03d8ddc049cf073e5579ca829b352367._comment |   24 +
 ..._207435949b2674ea82390c66549873e5._comment |   28 +
 ..._279302a0f5bb0a8d8d87182e03c6b475._comment |   20 +
 ..._8d36d42e34f5deae04bfa83c568b89d5._comment |   11 +
 ...f_special_remotes_refuses_drops__63__.mdwn |    9 +
 ..._0b523b2b6c361346c36ad456bbbac645._comment |   15 +
 ...an_encrypted_ssh_remote_is_left__63__.mdwn |    1 +
 ..._67ee446ca6d66e2c259ea771c2c9a2b2._comment |   12 +
 ..._6d3cce3c8048e4aea8f0ed76473f6af1._comment |    8 +
 ..._bd506e1ca7307660b3b9769eb97beddb._comment |    8 +
 .../When_--git-dir_is_not_in_--work-tree.mdwn |  108 +
 ..._0169812633d92bed8883e903e03056e3._comment |   29 +
 ..._0c101e5b017f56897599c2cbd37b1754._comment |    8 +
 ...reuse_UUIDs_and_avoiding_UUID_clutter.mdwn |   15 +
 .../Where_are_my_remote_ssh_files__63__.mdwn  |   10 +
 doc/forum/Where_did_my_files_go__63__.mdwn    |   20 +
 ..._3ff3ffa95eb2745ff9ec2a903e071d97._comment |    9 +
 ..._9d902e66ca19b3332f4454f694d4a12e._comment |   16 +
 doc/forum/Where_is_the_S3_config__63__.mdwn   |   10 +
 ..._63009ad122cfafc9682e06f984eaefe1._comment |   11 +
 ..._61403be4cc347fecedd8b19d6604e6d3._comment |   32 +
 doc/forum/Where_is_the_content__63__.mdwn     |    8 +
 ..._812e1cf740cbfa449ab3ef4dd5f2df08._comment |  132 +
 ..._5e2cfdfab6c4f84fe7a19447b417b5a7._comment |    8 +
 ..._bd4cbc8f256a94ffde4f57d2c406a9ec._comment |   16 +
 ..._a36b35d47472b5db779b0489bf3d4893._comment |   10 +
 ...ich_branches_are___34__required__34__.mdwn |   31 +
 ..._78d9ac05c66b7ccec031e0c57095af39._comment |   10 +
 ..._cloud_providers_are_supported__63___.mdwn |    3 +
 ..._1f9398840144e0452a2fed9336046547._comment |   10 +
 ...are_ignored_files_being_deleted__63__.mdwn |   22 +
 ..._3081bda5bb600fc564185499ddfb5cf9._comment |   35 +
 ..._178aa574855a3bfffab4b21f90a84092._comment |    8 +
 ..._v5__63___Should_I_be_concerned__63__.mdwn |    5 +
 ..._b7fc905780f941314c99b94a87e0438a._comment |   11 +
 ..._are_we_stopping_at_a_duplicate__63__.mdwn |    7 +
 ..._dd3b610032cd3091effdb3f0828f45a8._comment |    9 +
 ...be_enabled_for_removable_drives__63__.mdwn |    7 +
 ..._4341898d5ae4f09a5b06d24f5fe6192d._comment |    8 +
 ...t_annex_does_not_want_that_file__63__.mdwn |   33 +
 ..._44cd6ca1f7215395e19ce654513197a9._comment |   38 +
 ...up_remote_use___126____47__.bup__63__.mdwn |    5 +
 ..._da9c7c0e93aefc2da7409de5b138d86f._comment |    8 +
 ...thin_a_newly_git-annexed_subdir__63__.mdwn |   42 +
 ..._abae8a95b60f17052a5e2ac30a7ece32._comment |    8 +
 ..._dfd69ac96065f8146f5ea87b957cca6e._comment |   10 +
 ..._8d36f559d7f8b61f5633f0d24b424cec._comment |    9 +
 ..._a318582d30f5483f3738e8f0f1a2e1df._comment |   11 +
 ..._bc2e255f8732f6ec02e90a6623ffc8af._comment |    9 +
 ..._691dc07b192f077f50611544d488b394._comment |   10 +
 ..._71d7a08600dcba07dd895ddf6ad1331a._comment |   29 +
 ..._a5d60323c2c6b2d263514b33ad774aa9._comment |    9 +
 ..._83e52bd3d66ce87ba7d2913d21c76b08._comment |    9 +
 ..._0bd122e2e664d29dca027719721b1523._comment |    9 +
 .../Why_is_git_annex_status_slow__63__.mdwn   |   20 +
 ..._a5139c5a9fc94486cf62fc9a9fa9f8d9._comment |   18 +
 ..._2f61c2cdf9d1ffd298fd906207012818._comment |    8 +
 ..._8d9e5a1aef2648d7a844623e6237d551._comment |   14 +
 ...Will_git-annex_solve_my_problem__63__.mdwn |    7 +
 ..._35acbdd1a7727df204d776c2e8f02b53._comment |    8 +
 ..._230256c19ac139dea207d89c06f70782._comment |    8 +
 ...x_work_on_a_FAT32_formatted_key__63__.mdwn |    3 +
 ..._426482e6eb3a27687a48f24f6ef2332f._comment |    8 +
 ..._af4f8b52526d8bea2904c95406fd2796._comment |    8 +
 .../Windows_-_You_don__39__t_have_access.mdwn |   42 +
 ..._5c1da63922cc71483c9519e8670d532b._comment |   17 +
 ..._aa6ea60465df9fab7990bd6f510b74c5._comment |    8 +
 ..._593a8a54fa80258d5048f5c061992664._comment |   10 +
 ..._aa28602eb0b7fa7103eaf90dc1d5cf8f._comment |   54 +
 ..._f9041e48b911dbdd37ad3c1bbc801709._comment |   12 +
 ..._7656eb72bb9e39db59092557c57a2489._comment |    8 +
 ...ws_-_gpg_fails_with_shared_encryption.mdwn |   82 +
 ..._708da81b0678576a240ce7a388806e07._comment |   27 +
 ..._9f5d0e8d0c6eff548318b54797cefd09._comment |   11 +
 doc/forum/Windows_S3_host_issue.mdwn          |   11 +
 ..._8c0a1e84713a04a25fdc1f74919d34aa._comment |   10 +
 ..._06ecc76797c430b27a2e24776761d043._comment |    8 +
 ..._1715557daa15b9e9e17b4850141e62af._comment |   10 +
 doc/forum/Windows_eol_issues.mdwn             |  552 +
 ..._72e4c3a200e3fceb2afd4df563eaa5d4._comment |   31 +
 ..._77383b959d576c7930c726c55097c964._comment |  137 +
 ..._926b386f5ca59f1c5232cf5cba69e12a._comment |   18 +
 ..._dc470ae359ee4ce017770a89441a8b65._comment |    8 +
 ..._e711bdfcee4ec9a2860662e8c65a9c0f._comment |   20 +
 ..._62f748e40324bc988366e19088b33295._comment |   11 +
 ..._f9b71ea2158c02dfa8a7c59891aea679._comment |   26 +
 ...nex__39___is_not_a_git_command.__34__.mdwn |    6 +
 ..._b051dc30bf5a0fc9f5710c664f487ea9._comment |   14 +
 ..._8775a1483b29e2cc8f0456473c24e51e._comment |    8 +
 ..._cbaa3e0fa4e2347332b3929411f60d1d._comment |   11 +
 ..._3dc3cc824256b1f7530c7f516b0abbec._comment |   24 +
 doc/forum/Windows_installation_notes.mdwn     |  146 +
 ..._54c253ab61fea4f5aaefa04bb078c7b0._comment |   12 +
 ..._c8c2744e30f2950d9830936d2bd51617._comment |   14 +
 doc/forum/Windows_support.mdwn                |    6 +
 ..._23fa9aa3b00940a1c1b3876c35eef019._comment |    9 +
 doc/forum/Windows_usage_instructions.mdwn     |   25 +
 ..._d43dbd9406da3b9747b147715eca94ac._comment |    8 +
 ...hlist__58___Bittorrent-like_transfers.mdwn |    5 +
 ..._13544d54fb0418af4ca9200cdb045d91._comment |   15 +
 ..._9a7dad35bf80c684ad97892420d7370c._comment |   16 +
 ..._e5de748bc5da12a4a01e08cde2407dd1._comment |   14 +
 ..._e51530178f1e034c0fdd5c9aa9945567._comment |    8 +
 ..._81ea9c129d8c02097f09ef8c68f1bb11._comment |   27 +
 ..._3b5798414f89686526da3dfa72c0c4f2._comment |   10 +
 ...__58___Don__39__t_make_files_readonly.mdwn |    3 +
 ..._7148527961e2d27793810966588c8d35._comment |   10 +
 ...s_without_copying_the_file_data__63__.mdwn |    6 +
 ..._1cf4ab29dfa2cff59b86305fc0018251._comment |   10 +
 ..._f5ebb7f43dcef861ecc13373fb1e263f._comment |   15 +
 ...cting_files_based_on_meta-information.mdwn |   15 +
 ..._818f38aa988177d3a9415055e084f0fb._comment |   15 +
 ..._97e2ed48bd552d02918c4f98f963e6e1._comment |    9 +
 .../Wishlist__58___automatic_reinject.mdwn    |   14 +
 ..._6bf093f228353130e80e7a30bcf0075d._comment |    8 +
 ...g_the_disk_used_by_a_subtree_of_files.mdwn |   10 +
 ..._7abb1155081a23ce4829ee69b2064541._comment |    9 +
 ..._b4c6ebada7526263e04c70eac312fda9._comment |   18 +
 ..._ded71b270b94617a8ebb3a713d46a274._comment |   19 +
 ..._daemon___40__for_the_assistant__41__.mdwn |    1 +
 ..._42aa2b61b880f4048d874210212aa63b._comment |    8 +
 ..._3e201039fa0e611554171ee30e69a414._comment |    8 +
 ..._d1074724c44f3296cb438b2d526d8728._comment |    8 +
 .../Wishlist__58___mark_remotes_offline.mdwn  |   12 +
 ..._9e3901f0123abb66034cce95cc5a941a._comment |   14 +
 ..._d10e3d90cf421ae425e64ab266ea811b._comment |   12 +
 ...ptions_for_syncing_meta-data_and_data.mdwn |   13 +
 ...ecial_characters_if_filesystem_is_FAT.mdwn |    5 +
 ..._5d33bcbd862537f53edd91dcff2b8977._comment |   13 +
 doc/forum/Workarounds_for_git-annex.mdwn      |    8 +
 doc/forum/Workflow_for_adding_files.mdwn      |   32 +
 ..._a60dae97db827bc641d6256d1f382b5f._comment |    8 +
 ..._28dd15ac50f79fb07bacf8b8326c7edc._comment |   19 +
 ...ing_git-annex_only_on_external_drives.mdwn |    8 +
 ..._c3c495efb7cdd242b51cc7fa7719d95f._comment |   21 +
 ..._f29471761e95b25e35e4cb09ad89737a._comment |   15 +
 ...annex__58___I_need_a_sparring_partner.mdwn |   22 +
 ..._ee783a968a5948e2f50bd2d090a2238b._comment |   19 +
 ..._259b67a887dd6aa327b752f455c24bff._comment |   17 +
 ..._a072a5c8f0798094d9ab0b7dc6c34f98._comment |   15 +
 ...StreamSize_exporting_large_file_to_S3.mdwn |   30 +
 ..._8b066ad9628073a3ae045087b4ea79b5._comment |   21 +
 ..._c9eff9a83ea5ee71cbe87022be9d0875._comment |   16 +
 .../Wrong_symlink_target_on_usb_drive.mdwn    |   55 +
 ..._9a50df886c0c23ee6f5586bd9f6b61c3._comment |   11 +
 ..._75df13154d3ea662119e9d701a0d9c97._comment |   29 +
 ..._7f2fb4e7f0c0db9f9d9cbb637f02c9ff._comment |   10 +
 ..._f6ee6bfd5d82f0925f0e174b4c75e592._comment |   27 +
 ..._e5a152cef3c48ef05cb183907377f128._comment |   24 +
 ..._be59fcc5633b352eefe993871df1ec4a._comment |   14 +
 ..._64e1cdf144a17319831a58b04b22b7ea._comment |   17 +
 .../XBMC__44___NFS___38___git-annex_.mdwn     |   27 +
 ..._86480f31d410e903766f82e6ecf83e1c._comment |   12 +
 ..._d8ed4dd51d3050db691a8abdec24cd42._comment |   10 +
 ..._42b80ee51ce25775bf4532f53a8ecfe3._comment |   11 +
 ..._01767f3f864954cf8080274e206da9d4._comment |    8 +
 doc/forum/XMPP_authentication_failure.mdwn    |   15 +
 ..._19c7c3aa79d209d613d2e061e3129690._comment |    8 +
 ..._870059fed451e8377e5d382464ecc34b._comment |    8 +
 ..._1a7ff955e9173f13d10b75f203792384._comment |   10 +
 ..._d59031ebc0dd3abc1f4c96878328362c._comment |    8 +
 ..._c37ef477bef7efdb79dd05dce90dfde6._comment |   10 +
 ..._48cabea4c2caf5b3bd854df3aaa17d3d._comment |    8 +
 ..._14cd9b67806db93c3af055d88c9a910a._comment |   10 +
 ..._151d3fd7d3cceb30fd20a8f3bd54036c._comment |   24 +
 ..._fbb9eba65fbb72201f08511945fbcf8c._comment |    9 +
 ...provide_some_kind_of_debug_data__63__.mdwn |    9 +
 ..._1ba0735141fc6a21ac15913f4cacefae._comment |    8 +
 ..._16994dc86b87592fc62799e2d206d172._comment |   10 +
 ..._6afd424edc4095b8f71b136de2a9e64d._comment |   10 +
 ..._1381b6a927410642c6a93aa8354be791._comment |   17 +
 ..._c5b33c7a8aa8e6d0f9349510dac2366d._comment |   12 +
 ..._9913d2983ba2744ed24911f74988e4c7._comment |   11 +
 ..._ad6f385a2b95803eb9d81dfe76359551._comment |   10 +
 doc/forum/XMPP_problem_behind_router.mdwn     |    3 +
 ..._25a7f8dc5cf14cda4d76b2f8c6ca77d5._comment |    8 +
 ..._3186ebe32c30764b9fd53625dd3e4eda._comment |    8 +
 ..._7fa8fe8cb92993c935ba2dbfb2aef728._comment |    8 +
 ..._6497ca72904dfdefe4e02f8a55127a8e._comment |    9 +
 ...tch_queries_to_the_location_log__63__.mdwn |   45 +
 ..._01cbfc513c790faef3a3ede5315d3589._comment |   10 +
 ..._fe28dfb360caa12d5d5bc186def3eb45._comment |   35 +
 ..._9bb30ab62febe4ef63bed49f831a473a._comment |    8 +
 ..._7832f0347a41b8204538c01b72487803._comment |   19 +
 ...71__Locking__187___files_until_synced.mdwn |    7 +
 ..._8bf59f47fee0a8d5741fe209b5899863._comment |    8 +
 ..._0c683547a6178e4303f0b1ed1f5605a5._comment |    8 +
 ...st__34___data__63___Maybe_a_bug__63__.mdwn |   14 +
 ..._52e4453432184524d84d88f6382cac9d._comment |   16 +
 ..._4d80b96e788d233706fa8f3e363d2f76._comment |   12 +
 ...Pairing__34___more_than_two_computers.mdwn |   11 +
 ..._80f7a4bb3c66b11e566043407b611bbf._comment |   10 +
 ...34__Preseeding__34___a_special_remote.mdwn |    5 +
 ..._b0c46d0eba900d0f6169a2c698d7a222._comment |   12 +
 ..._5e63f5e6f45c11cc86b293ce8acad77f._comment |   65 +
 ..._Scanning_for_files_to_transfer__34__.mdwn |    9 +
 ..._4fa6d0d5264707886e1e9b5184090386._comment |   36 +
 ...e_filesystem_for_external_drive__63__.mdwn |    3 +
 ..._31e5e55e9f8f391309b16c6591bb0bb0._comment |   28 +
 ..._abb716dc8b39e1b20d8725d83a7cc662._comment |   17 +
 ...du__34___equivalent_on_an_annex__63__.mdwn |    5 +
 ..._a80eccce0bdb33748ab1ccba9b88a65f._comment |   16 +
 ..._e3f82edf70d28f00d30cfd98f189cd86._comment |   12 +
 ..._041ae920e2e6fd83967dc98646452fa7._comment |   16 +
 ..._a41bd02361aa961e5285aeaf1ea062be._comment |   10 +
 ..._28ba62a546f5cc8f416491423d743d8a._comment |   10 +
 ..._8d97f40c1d14b7230f3656a00a99cf80._comment |    8 +
 ..._baa8fbbdd5c449a0dc2bb622cb4a47ce._comment |   18 +
 ..._2ee6cbbfe54a2e7b6e8eb539c18e663d._comment |   10 +
 ..._48f6a2761a34b7f991325f1d24e2c5ff._comment |    8 +
 ..._d632baff41b8582f1a79bc5018c68545._comment |    8 +
 ..._6a51c22d9893fa5b1503f5a14b1eb8ce._comment |    7 +
 ..._a2bda4c74ef09a58709c0c5f6ee1b726._comment |    7 +
 ...___vs___34__git_annex_add__34___in_v6.mdwn |    5 +
 ..._285032a01ca754c539ce0634823db23c._comment |   29 +
 ..._93eec60060bc7bca8dd1633b670f9a53._comment |    8 +
 ...34___doesn__39__t_work_in_OSX_10.11.4.mdwn |    1 +
 ..._34bd938e8cd0cba6ec48020932858485._comment |    7 +
 ..._3ec07e7f0e713e6fa925abb99c646bc7._comment |    7 +
 ..._3dce000eb6db22e07ed2f53c4f62a1e0._comment |   27 +
 ..._5bed42e467859d2310f3da35e55acd38._comment |    7 +
 ..._5cb379490b0e85c24bff48db8201c7d4._comment |    9 +
 ..._46eb0f4dcbccea5140a26dca36c6f1d1._comment |   11 +
 ...n__39__t_send_it_to_working_directory.mdwn |   11 +
 ..._0c0a5999a92bf5880f2113177dc67cc2._comment |   11 +
 ..._c18083d9054f66f0bd51d63452af07eb._comment |    8 +
 ...s_while___34__locking_origin...__34__.mdwn |   12 +
 ..._09fbe4362fea8f2a53a1f955b0519019._comment |   18 +
 ...4___on_windows_fails_with_rsync_error.mdwn |   20 +
 ..._a1a881d7b0f0c32b1bfdd3bc5ee4dd18._comment |    7 +
 ..._50d0b68fcf0e239037a5d7950595b1d6._comment |    9 +
 ..._9bc58c6c2333655870c5e42138f9749e._comment |   15 +
 ..._958e887dd83b8b636df2d81ade0dbbf1._comment |    7 +
 ..._24782f9b1012a2935466ac358acea97b._comment |   11 +
 ...nex_lock__34___very_slow_for_big_repo.mdwn |    7 +
 ..._044f1c5e5f7a939315c28087495a8ba8._comment |   16 +
 ..._e854b93415d5ab80eda8e3be3b145ec2._comment |   13 +
 ..._95c110500bc54013bc1969c1a9c8f842._comment |    8 +
 ..._a4fd212cb066cd53d0d66eb09f3b39a8._comment |   18 +
 ..._remote_of_type___34__directory__34__.mdwn |   17 +
 ..._c51363e109bcc5cd1df40c5d0ec993b3._comment |   38 +
 ..._be52a6d21df4732c9f83463bb5e6f612._comment |    8 +
 ...annex_sync__34___synced_after_8_hours.mdwn |   40 +
 ..._e815ac48a17cc4296473d61e712d95e0._comment |   13 +
 ..._d13a0af48b8831c81276a0b2c8e25303._comment |   37 +
 ..._c50b62e5a84b861117a4405c2a2f5cfb._comment |   16 +
 ..._0051e83196945b97e2f3ed14a58daaea._comment |   14 +
 ..._26de32ea240621e23717c55866ad9764._comment |    9 +
 ..._0714eca58513f1059fc246ee152078e7._comment |   16 +
 ...files_after_git_history_was_rewritten.mdwn |   17 +
 ..._8f2ced0b9039968f485943e1525dcf6e._comment |   10 +
 ...I_would_like_to_have_file_x_y_z__34__.mdwn |    5 +
 ..._bfeb1446dee4d2f52ef25fabfb8cc8f6._comment |   11 +
 ..._e60f2bbc1c058993472fd920edbc75fc._comment |    8 +
 ...n_denied__34___in_fsck_on_shared_repo.mdwn |   17 +
 ..._3a5202ef2116ebb5559b6f4d920755fc._comment |   10 +
 ..._86663eeb75b0477f53c45f26c8e4b051._comment |    8 +
 ..._c336b2b07cd006d378e5be9639ff17ec._comment |   10 +
 ..._1339cd27ca2955f30b01ecf4da7d6fe8._comment |   10 +
 ...recovering__34___from_git-annex_usage.mdwn |   24 +
 ..._4a2a68ec0d0075f0d2fd7e8c9fac5e75._comment |    8 +
 ..._refs__47__heads__47__git-annex__34__.mdwn |   34 +
 ..._e50188896df347f1d92e20a52053aa14._comment |   10 +
 ..._d67793f7c969f64943d1fd54a1208c2b._comment |   15 +
 ..._3523884833b5fd458a35f898797bf897._comment |   10 +
 ..._02c32c2521ba1a1eaa19eaca7281f2a6._comment |   10 +
 ...onality_as_opposed_to___39__get__39__.mdwn |   14 +
 ..._b2b7de0bf4494721b02280857474fd6c._comment |    9 +
 ...9__wget_--mirror__39___like_behaviour.mdwn |    7 +
 ..._9c874a74f25fa06b8e515482b4706032._comment |   24 +
 ..._format_for_.mat_.tif_and_.json_files.mdwn |   29 +
 ..._debe9a878896ead4957db288203cae14._comment |    8 +
 ....3.2_requires_syb___61____61__0.1.0.2.mdwn |   18 +
 ..._fae6e88115d175239fc55cef4c33fb2c._comment |   13 +
 ..._4c7a75638e8717132ccde949018d6008._comment |   10 +
 ...nual_ssh_remote_setup_with_shared_key.mdwn |   19 +
 ..._811cab17410ba6e07ae7af3249cd98df._comment |   14 +
 ..._Mixing_.thin_and_default_repos__63__.mdwn |   15 +
 ..._41f7bb65b85c3ab54f692e04d26a2891._comment |   11 +
 ...unce__93___metadata_extration_utility.mdwn |   30 +
 ..._replace_all_files_with_pointer_file..mdwn |   31 +
 ...__44___estimate_how_much_data_to_copy.mdwn |    3 +
 ..._785e4fe097ef2a2d51d84146fc91b2ca._comment |   19 +
 ...__from_directory_loses_contents__63__.mdwn |   76 +
 ..._776b5b8099125aad3bc8839d9cc1abeb._comment |   29 +
 ..._c36d32db2b1dcd3cd36c68f2bb726f6f._comment |   12 +
 .../__96__git_annex_sync__96___hangs.mdwn     |  113 +
 ..._ffd16cb94b39b93dfb0a2932b70938fc._comment |    8 +
 ..._fad59a54d92ed7cb230f0f365fddb0f4._comment |   10 +
 ..._29cd5e9acd78d8ac6b58fe535fee9650._comment |    8 +
 ..._7a24236bc511cbfa869aaeb431a003d2._comment |   18 +
 ...ror_if_it_can__39__t_get_wanted__63__.mdwn |   14 +
 ..._41d3a4774dd5ada5036247eb6f562392._comment |   10 +
 ..._a971d9d85eb7f86d4ea18a71bd0db25d._comment |   12 +
 ...ers_in_pairing_message__59___ignoring.mdwn |   40 +
 ..._99975a677f832c410050ba721be6d904._comment |   15 +
 ..._f4dd76879e2b2bd0da557ee6a539533c._comment |   95 +
 ..._d437dc44114f59d5717c177831ae0d53._comment |    9 +
 ..._dd29ac2b5615ff6f79458a36bce44306._comment |   55 +
 ..._e07b69bb36cd8aa2c4fd689744f12df1._comment |   15 +
 ..._f61a390f304e1f6d1e8c4a90cdfbd9b9._comment |    9 +
 ..._625df33e70f2f959c574d918a706648d._comment |   13 +
 .../_preferred_content__58___lastpresent.mdwn |    1 +
 ..._7610cd866b256d36646b642eb5f8cae5._comment |   14 +
 ..._d25666a173b78213d583f029fd166d06._comment |   10 +
 doc/forum/add_only_binary_files__63__.mdwn    |    1 +
 ..._7ce3be5bafd62ce5ed78bcd9323039cc._comment |   16 +
 .../adding_files_without_hashing_them.mdwn    |    1 +
 ..._c3113d7aff6b64a325a32b8b281df605._comment |   12 +
 .../adding_remote_bup_repo_using_ssh.mdwn     |   42 +
 ..._d1ab38bccc415a94fa3906f7f5e823f3._comment |   18 +
 ..._6698ecb746e6edb25130c8dbceb36fc0._comment |    8 +
 .../adjustedbranchrefresh_ignored__63__.mdwn  |   50 +
 ..._999bd4a511c7fa39f5455df895c435f3._comment |    8 +
 .../advantages_of_SHA__42___over_WORM.mdwn    |    5 +
 ..._96c354cac4b5ce5cf6664943bc84db1d._comment |    8 +
 doc/forum/agent_keep_deleting_local_file.mdwn |   24 +
 .../alternativeto.net___34__Like__34__.mdwn   |    3 +
 .../ancient_linux_build_for_arm__63__.mdwn    |    5 +
 ..._c4ebfb2136bb4b3e21a52aa23717b22a._comment |   13 +
 ..._f5a7d7e4ac5d9885230d08684416cff4._comment |   13 +
 .../android_-_assistant_-_local_pairing_.mdwn |   15 +
 doc/forum/android_binary-only_download.mdwn   |    9 +
 ..._aab206e0bf0bb5ff47c7cc9795f12f92._comment |    8 +
 doc/forum/android_installation.mdwn           |    7 +
 ..._8908256ecd48d7b5207799aa02102d87._comment |   18 +
 ..._3c2a1e7542993528250ad72079894364._comment |   19 +
 .../annex.largefile_include_from_file.mdwn    |    5 +
 ..._9016a64a654151ab9a478686382193b4._comment |    8 +
 ..._09258e59eab492afc37efeac325c2de1._comment |    9 +
 ..._f857505bde5f03d9c17e8df0512c0e99._comment |    8 +
 ..._f9c2acc07dad646cd04a51ca85f45502._comment |   11 +
 doc/forum/annex.largefile_not_working.mdwn    |   20 +
 ..._b2ecb8b60603929bae91c3007817585f._comment |   12 +
 ..._18bc73688897728d0bcae6df1225e6e3._comment |   12 +
 ..._81085c1a526ac804edba689043e58944._comment |    9 +
 .../annex.largefiles__58___two_quesitons.mdwn |    9 +
 ..._75fc6cd2315e9ad6897b94bcc527ddc1._comment |   11 +
 ..._f34cf28c3f8354e6fc055d4dba6ed555._comment |   13 +
 ...34__synced__47____42____34___branches.mdwn |    7 +
 ..._4667fadb05c594b0a212bf455ee65298._comment |   12 +
 ..._cb6971a766a28bd8c094d0b986272c65._comment |   11 +
 ..._1a0384edd20cc379e53fe7d7f650f7e2._comment |    8 +
 ..._79219e920a6beb4bd3265571f59f51cb._comment |   36 +
 ..._39009651c3f65e2ecd225e17d157c8d8._comment |   10 +
 ...y_for_web_remote_with_SHA256E_backend.mdwn |   12 +
 ..._d1605a6e3b4d6863f4089218994ce564._comment |   29 +
 ..._d249ff27fa3d9ac3ca32485cdef49930._comment |    8 +
 doc/forum/archaeology_of_deleted_files.mdwn   |   36 +
 ..._48f27df03ec18d2c27cf6b70dcf71dc5._comment |   10 +
 ..._c698cd10c8038bac45bd1049506a27c3._comment |    8 +
 doc/forum/archival_and_multiple_users.mdwn    |    8 +
 ..._fc4ee256f03a7c189d687caf4a34e21e._comment |    9 +
 ..._a96d57d4bb567ac9b0b9167d5b1be011._comment |   12 +
 ..._bd44634b04732ffb91154c61ef9cf828._comment |   14 +
 ..._b89a56a5f1cd641f87925c7a5f74bcec._comment |   13 +
 ..._81293bf5dc8ad4552712c2083fd589c9._comment |   19 +
 doc/forum/armhf_binary.mdwn                   |    3 +
 ..._9ca7ff6cb1f5dfc1e5ce8527e7e0a45f._comment |    8 +
 ..._743ecf263d1ec1bc4f24e32c0a178f2b._comment |    8 +
 ...ne_-_how_do_these_play_together__63__.mdwn |   10 +
 ..._d90d1d599ce557af03c6f0f2ea188212._comment |   10 +
 ..._58b1af497cab132acb28cb5f9283ec2a._comment |    8 +
 ..._37d4fd8f69e8066b5aa19454b714e443._comment |   11 +
 ..._a974e2105774d4f82ad286ff0792ba84._comment |   10 +
 doc/forum/assistant_and_archive_folder.mdwn   |   13 +
 ..._ab8808372b886fd1a9f55588d1cef602._comment |   12 +
 ...ckup_remote__58___Howto_restore__63__.mdwn |   38 +
 ..._70200f871b9df49261f32752a6bb0e67._comment |   14 +
 ..._173da510b45f0320ae8aa2df9f14ae7b._comment |   11 +
 ..._1ecea12a4be5ad09013cddb62df6ab20._comment |    8 +
 ..._af4bc222d1479482bd83952353c97f05._comment |    8 +
 ..._c1d247fa128c0a0fc899284f5f95002c._comment |    8 +
 ..._cf877a3502802492cd2bc3012cb2d779._comment |   12 +
 ...zealously_moving_stuff_to_other_repos.mdwn |    7 +
 ..._6bd240edf1868615024ff11c24c3d52c._comment |   13 +
 ..._37c5e9a7669b5b94fbadb8792a765316._comment |    8 +
 ..._87aa4c5942929be81ddc1e2795d56f0e._comment |    9 +
 .../assistant_periodical_unused_moves.mdwn    |   11 +
 ..._98e30e1f3ca63790c4a8ce11d29634ae._comment |   14 +
 .../assistant_to_have_synced_folders.mdwn     |    9 +
 ..._3bf1a44e76855e4fbdd270f97a54bcc5._comment |    8 +
 ..._b5f9f527597acd8f44f529f85ac305fd._comment |    9 +
 ..._f38a88b82328ee2d2b411f3df5c3d043._comment |    8 +
 ..._9b8631b1fb4c9992203efc2d29cfae8d._comment |    8 +
 ..._e2e49f5278b921f8817ad6ac89a6aaf8._comment |    8 +
 ..._690a144201e7df5972fd48af8c1d46f7._comment |    9 +
 ..._49b00584ef4388e130cce63f4f33572f._comment |   10 +
 ..._53ceb18128de33311d65b39f34b3d9b7._comment |    9 +
 ..._6db901470af7dc7e1da90839fc08c121._comment |    8 +
 ..._0ec093a51b3dab465907074beb423848._comment |    8 +
 ..._83fdf8c0027c860f37716f975838497a._comment |   11 +
 ..._52237edb2f6cbf9c96f7285ebf6abe6c._comment |   14 +
 ..._a7a5a4c97663211e2fb4337117ec0cb0._comment |   69 +
 doc/forum/assistant_without_watch__63__.mdwn  |   13 +
 ..._be1f7c038426e53209a85ae1119269d5._comment |   15 +
 ...e_server___40__needs_ssh_tunnel__41__.mdwn |   10 +
 ..._817a3ed424e4fb76fcd33295f2953250._comment |    8 +
 ...ing_annexed_files_on_open__40____41__.mdwn |    8 +
 ...ders_for_git-annex_to_aid_development.mdwn |   34 +
 ..._7e88f815e8d9652ef18ea6d54b118962._comment |    8 +
 ..._fef17a10226af5671495c2929653c337._comment |    8 +
 ...ing_existing_backups_into_new_remotes.mdwn |    3 +
 ..._7d0b479244fefd933193d921adcd897c._comment |    8 +
 ..._d42222ef94f4d409ac40e523f8211ffc._comment |    8 +
 ..._dc93ae2a58de5620c440531f43f1237d._comment |   25 +
 ..._e6bb8a33608908d02eeb921d039f22b9._comment |    9 +
 ...ng_copies_across_mutiple_file_systems.mdwn |   13 +
 ..._2ff3e4d2af575b27b14a0a936ad8c52f._comment |   14 +
 ..._96e72de1dc7cefdaa3beedc837639f57._comment |   40 +
 ..._43db664a00fb9956ad392b5dc23565ca._comment |   16 +
 ..._6584f98910d91746203405d57d17b8b0._comment |   12 +
 doc/forum/backblaze_s3.mdwn                   |   13 +
 ..._854390b9a781da82ecb85ad85eecad04._comment |   13 +
 ..._5f1407460b6a56a8e267f8eecf4427aa._comment |   17 +
 ..._55362a91c4592775994999a843e648dc._comment |    9 +
 ..._bd008868a576bf09c6fa188dc8a5907c._comment |    9 +
 ..._474ca16386680fd359474f05bfbd0375._comment |    9 +
 ..._c84400e7dc58ed7e5db8c7883587e8f8._comment |   18 +
 ...ming__58___git_annex_push___38___pull.mdwn |   28 +
 ..._3a0bf74b51586354b7a91f8b43472376._comment |   11 +
 ..._b02ca09914e788393c01196686f95831._comment |   14 +
 doc/forum/balance_git_annex_remotes.mdwn      |    9 +
 doc/forum/bash_completion.mdwn                |    1 +
 ..._5c42c0c8e7fc3224bf5406880f9fd0c4._comment |    8 +
 ..._6cbe3c825db99bf9188a0de8bb937d5b._comment |    8 +
 ..._948c40f1e46ca220d61365aebcd4f6d7._comment |  136 +
 ..._dbae348b230b780cda91ed8576b8f9fa._comment |    8 +
 ..._d45570fd750ae8d69dedc3edeef0cc10._comment |   13 +
 ..._2dbfa336ad8957ff0cafd8301ca1150f._comment |    8 +
 ..._2fd198746dc7351fe957e7a8150fcb89._comment |   13 +
 ..._7802f4bd08dddd24ac9d19ee7847735f._comment |    8 +
 doc/forum/basic_usage_questions.mdwn          |    5 +
 ..._c2a5fedc24f8c301d9042999a0371d9f._comment |   11 +
 ..._67d047a107b20874cb71ba311681e181._comment |   16 +
 ..._94b4efa49efbee741c051227b3204562._comment |   13 +
 ...batch_check_on_remote_when_using_copy.mdwn |   34 +
 .../benefit_of_splitting_a_repository.mdwn    |   10 +
 ..._93a86cb03b66e7ab5dd7146e7b86c9e8._comment |   15 +
 ..._4e2fed247298d620fee7be883a1e86a6._comment |   15 +
 ..._practices_for_importing_photos__63__.mdwn |   13 +
 ..._37f0ae4b552ec2a4a144ddcdc17c8453._comment |   19 +
 ..._7f96f0fe0fc073321bd7c5bbd9048425._comment |   11 +
 ..._a_git_annex_repo_trought_file_system.mdwn |    6 +
 ..._50b0f3b42c5c7185c51451af80749718._comment |   14 +
 ..._e3e30ca123cd840288655c25b688cd66._comment |    8 +
 ..._00418ada32a4d93dfd3334686e391a23._comment |   11 +
 doc/forum/big_overhead.mdwn                   |   46 +
 ..._d5f4e353e7f711d8c38cdcc222339bca._comment |   14 +
 ..._cbf25217e4149f2cfad4e2bf94f2b4ca._comment |    8 +
 ..._475d5af95adcfcd3a51e10f270205eb7._comment |   71 +
 ..._1c8cc992f04fc63179094c494bd25025._comment |   10 +
 ..._cbfb3d557915258e72c65a4e84df77a9._comment |    8 +
 ..._b973529bae549bcbaaae792f0403989b._comment |   10 +
 ..._0c184520c30a89bd2604ab7c0eb7ac45._comment |    8 +
 ..._13a017c6c84511894ded2d89d86eb541._comment |   10 +
 ..._b4761cacc02396b5bdf34bcf3457cb91._comment |   10 +
 ..._633f8538f368220eaca82b8bbfe9b49d._comment |   16 +
 ..._599092b8d4f1fc8f378796328ef42931._comment |    8 +
 ..._adb4b4e7eb4dac7760f3425bae6cbbc2._comment |    8 +
 ..._a762eb55addf81c1c5350c7968598d0f._comment |   16 +
 ..._4a66f57c6c0bdc6123618cb69a719be5._comment |   65 +
 ..._5fa681ea0d6bd0dcac7142d40df9d54f._comment |   12 +
 doc/forum/browse_files_on_server.mdwn         |    1 +
 ..._5023c6f9f4a8a7724ff057076f64ec1d._comment |    8 +
 ..._67096b34041fed07bbf1d0cb243e1efc._comment |   15 +
 ..._148f1aa0d46dcf51b855b6fb18b6a549._comment |   14 +
 doc/forum/btsync_equivalent__63__.mdwn        |    8 +
 ..._6bfdc6f595a8aa8979a7c2a10925812f._comment |    8 +
 doc/forum/bug-fix_release.mdwn                |    2 +
 ..._c3c23f4c0a8bdea8619479656af63af3._comment |   10 +
 ...Linux_fails___40__out_of_memory__41__.mdwn |   74 +
 ..._cd004b531ae384e134e16600b64473e0._comment |   18 +
 ...tions__58___Flag_HttpClientRestricted.mdwn |    7 +
 ..._67ab203f26e7b446fe96e01ec3706540._comment |   22 +
 ...from_source__58___dependency_versions.mdwn |    1 +
 ..._442b37aa559512eb85695f0a9e3b8197._comment |   10 +
 ...e_standalone_distribution_from_source.mdwn |    3 +
 ..._ae23bbd2da15e8ae115b4030994502cc._comment |   98 +
 ..._5c580c8fce388b9808c2afc778da853b._comment |   38 +
 ..._9b0a7c108855d9db63092dd5f93bc5e5._comment |    8 +
 ..._27f987a16d931a02f5a4ab3f80bf327a._comment |   33 +
 ..._44606ec8db82f75f37aabcd7df5c24bb._comment |   10 +
 ..._204eda1dc4b935ee357a6675ee14317b._comment |    9 +
 ..._ff968f9f9d6644b9e8607c8e76f45c1e._comment |    8 +
 ..._e94f70e19b77c9ad6b6349fa65dcc60f._comment |    8 +
 ..._0b7824acaf031d8ba69700674c82f472._comment |   13 +
 ..._bfec6091cc312a9d4c87163b845454f6._comment |    8 +
 ..._044da90b6cc18534de74ee5d38d6becb._comment |   14 +
 ..._5187f5f40bc47b5b079cfdd3eb5f1fc3._comment |   13 +
 ..._eb0c565043164c17b2a6d2c6361b6e35._comment |   22 +
 ..._edb3a79772f81dd3ffd00b81e79f67e5._comment |   13 +
 .../bup_backups_to_amazon_cloud_drive.mdwn    |   12 +
 ..._e8f6fdc70cedd5482da6a185c6c6b9b9._comment |    7 +
 doc/forum/cabal_install_fails_on_uuid.mdwn    |   23 +
 ..._2a3963e21bc7ff526124b902cb0b6ad2._comment |    8 +
 ..._1609525998e2b36c04d67f4d988139c0._comment |   10 +
 .../can_I_only_add_my_own_files__63__.mdwn    |   27 +
 ..._767d647af9d0345f337338d6319071fa._comment |   10 +
 ..._0c3306ffb38b97b54e1e0436d12c1876._comment |    8 +
 doc/forum/can__39__t_sync_content.mdwn        |   35 +
 ..._0d6c6f5967c91e7dda55fbf716dd88a0._comment |   15 +
 ..._e9c476eeac7427950573c07313a8a175._comment |   10 +
 .../can_git-annex_replace_ddm__63__.mdwn      |   13 +
 ..._aa05008dfe800474ff76678a400099e1._comment |   12 +
 ..._008554306dd082d7f543baf283510e92._comment |   19 +
 ..._4c69097fe2ee81359655e59a03a9bb8d._comment |   12 +
 .../canceling_wrong_repository_merge.mdwn     |    3 +
 ..._7230f2be014afcb40514ef521d53c170._comment |    7 +
 ..._87aabff41a1c6aec773b8f52ead51105._comment |   11 +
 ..._d6e45d7e4f4bdf0a08ab91a08e0c1be6._comment |   37 +
 ...ncrypted__41___rsync_remote_on_MacOSX.mdwn |   18 +
 ..._21f0101447623f5a0cf9e72c3ff463bb._comment |    8 +
 ..._6234ca64bd03a0e15efbe8f5c204338a._comment |    8 +
 ..._5ac2b520a907e232984eb513ce088054._comment |    8 +
 ..._183dd1c29f66539193e7c0b73f329430._comment |    9 +
 ..._c920d04ffe332caed9d223fa0ac42746._comment |    7 +
 ..._7a3cf0853a8ec7b996e19b5e80145d21._comment |    8 +
 .../cannot_sync___39__unused__39___files.mdwn |   45 +
 ..._d7c88a5cdf8ce8206795ff7ab215d372._comment |    9 +
 doc/forum/central_non-bare_and_git_push.mdwn  |    9 +
 ..._76d0c73c8985e860eb86333c63be6340._comment |    8 +
 ...ut_view_to_directory_outside_of_annex.mdwn |   23 +
 ..._a31a501bdc28eabc60588502f7219e50._comment |   20 +
 ..._b4abbb048ebcd3c4b59d20e103948fd8._comment |    7 +
 ..._2139407a3a556023a2458148a4a2c009._comment |   12 +
 doc/forum/clear_box.com_repository.mdwn       |    1 +
 ..._2e839d8f974269c80a9fca183712350f._comment |    8 +
 ..._8f9c7248a148a24ae2aba39c4a79a6d1._comment |    8 +
 ..._f64ad21e5abfbf4e1f925b3d651bdba3._comment |   10 +
 ..._f8c06ac9b23b51cf18d362c260fc47a9._comment |   13 +
 ..._61d401b29322802cb25896503f3e6514._comment |    8 +
 .../client_repositories_setup_problem.mdwn    |  156 +
 ..._be53f90b66de690b39f487d394866a66._comment |   17 +
 ..._f9660534c3f3346f322de57c2da0eb27._comment |   87 +
 doc/forum/cloud_services_to_support.mdwn      |   16 +
 doc/forum/cloudcmd.mdwn                       |    6 +
 ..._current_workdir_state_in_direct_mode.mdwn |    5 +
 ..._748481ff00374f570284bd4571584874._comment |   10 +
 doc/forum/compiling_on_MacOS.mdwn             |    3 +
 ..._143ae6d4f2704d4ab74e110a2d7a3c82._comment |   17 +
 ...itory_vs._working_copy_in_direct_mode.mdwn |   10 +
 ..._a6b4db0cefa439f72b97089d48dfacbd._comment |   16 +
 doc/forum/conda-forge_build_problem.mdwn      |   10 +
 ..._22e01f5f110593796b539fc7630ccb3c._comment |   17 +
 ...t_annex_sync_only_sync_metadata__63__.mdwn |    7 +
 ..._ce9d638b8a07375a79a9ee04b02d6e95._comment |   27 +
 ..._11b9261bc5c32d3e36357afc021ac4e1._comment |   11 +
 ..._07e6f767e38d9812b176ee3fdb00adf0._comment |   10 +
 doc/forum/conflict_with_git-crypt.mdwn        |    3 +
 ..._b81a3cd99ff04e21ef520a497c0bd46a._comment |   12 +
 ..._cda648fcc5f213af06fe98428910f561._comment |   15 +
 ..._6e7ea4ed29e6b526c27979988d09d883._comment |   27 +
 doc/forum/confused_about_external_drives.mdwn |   30 +
 ..._8340e5ff17a4846b41789e4966fed70c._comment |   12 +
 ..._ad10bd0ec14c16bcad089b3ebe64580e._comment |   10 +
 .../confusion_with_remotes__44___map.mdwn     |  113 +
 ..._a38ded23b7f288292a843abcb1a56f38._comment |   10 +
 ..._cd1c98b1276444e859a22c3dbd6f2a79._comment |    8 +
 ..._18531754089c991b6caefc57a5c17fe9._comment |   24 +
 ..._3b89b6d1518267fcbc050c9de038b9ca._comment |   11 +
 ..._27801584325d259fa490f67273f2ff71._comment |   16 +
 ..._496b0d9b86869bbac3a1356d53a3dda4._comment |    8 +
 ..._9a456f61f956a3d5e81e723d5a90794c._comment |   27 +
 ...t_annex_sync__34___resolves_conflicts.mdwn |    6 +
 ..._48be720ff150112f30273960f677056c._comment |   20 +
 ..._c091e5a668b15aca7b2faa955beab403._comment |    8 +
 ..._d8dddf7b565273390ce4ba1c22dabf46._comment |   15 +
 ..._c019c5b4d1c2a7941aed8791b6749f5b._comment |   13 +
 ...v5_repo_to_an_always_unlocked_v6_repo.mdwn |   34 +
 ..._e08eb54547bfd4dbfcc79a5a4a529647._comment |   35 +
 ..._85946916ac9c2a19c0d65e2b1a3e5832._comment |   21 +
 ...py_--auto_copies_already_synced_files.mdwn |   24 +
 ..._cc5e2e7630a33b73d1eb92eebe254cea._comment |    7 +
 ..._3cfd11d8199a4d5e442d207a1edb38e0._comment |   12 +
 doc/forum/copy_and_move__63__.mdwn            |   19 +
 ..._a24b1ab4608fcf8129c9890a5ae9e943._comment |    7 +
 doc/forum/copy_symlinks.mdwn                  |   11 +
 ..._950de173a042a7671a43adbab02e0669._comment |   10 +
 ..._198f3e9db08ebcdb7ec36b76cc1d9473._comment |    8 +
 ..._annex_between_remotes_manually__63__.mdwn |    5 +
 ..._c13a0cded3a5fee06106f101f122eb33._comment |   50 +
 ..._1237297cfb596d59a48c8359d43a3928._comment |    8 +
 ..._875474a913d23823e3866cca27cfa3ac._comment |   16 +
 ...t_way_to_add_two_preexisting_datasets.mdwn |   25 +
 ..._c5c3ff25c9f5e34db222b5f4ae58b093._comment |   10 +
 ..._ee3ecc86990ac5a8d0c4fdfb482a7594._comment |   16 +
 ..._e29bf8b848da04c761dc601ac979ac14._comment |   11 +
 ...could_not_read_from_remote_repository.mdwn |   36 +
 ..._27d4d1556a80c06505ed3d8a9422d082._comment |    8 +
 ..._cf7d5e231675921c3d98faab3613c92f._comment |   49 +
 ...s___40__use_case__58___dnanexus__41__.mdwn |    2 +
 ..._55c2a5c932ccc5a2a49a54239cfba139._comment |   16 +
 ..._db80224d61ca549557af558e9a5f099a._comment |    8 +
 ..._8b69aa113bc35a042c90beddf8b0f3a9._comment |   17 +
 ..._94e2fbb04c553b2c8c7992541e634017._comment |   10 +
 ..._33a833e1037df7ce0fa55876e4154250._comment |    8 +
 doc/forum/dangling_blobs.mdwn                 |   27 +
 ..._120681851a595909e19afcc0334383ec._comment |   22 +
 doc/forum/dbus_and_magicmime_build_flags.mdwn |    1 +
 ..._9d2ae829a085582c69dcf994c26f5a0c._comment |   15 +
 ..._5421641e133cdadd0be5587b882ed3e5._comment |    8 +
 ...default_repo_version_is_still_5__63__.mdwn |    1 +
 ..._5f63f10cf79ef8ca33214ceaefd1271e._comment |    9 +
 doc/forum/deploy.mdwn                         |    5 +
 ..._bd9855cc19f0f49620258564845f1f77._comment |   16 +
 ...dev_machine_-__62___NAS_-__62___cloud.mdwn |    7 +
 ..._f77818a766f2b41d13ced2bcf4447de0._comment |   11 +
 .../differenc_in_webapp_icons__63__.mdwn      |    4 +
 ..._c38e2692b13a1b76777bf88312a03966._comment |    8 +
 ...ull_backup_and_number_of_copies__63__.mdwn |    9 +
 ..._df1850059a7a3006db7cb5c588dac3d7._comment |    8 +
 .../difference_between_uninit_and_unlock.mdwn |   10 +
 ..._6b89cffc10650c087dbbfbdd3e099b5f._comment |   10 +
 doc/forum/distributed_borg.mdwn               |   37 +
 ..._133d5adb83e9df38c513e17d128486d1._comment |   18 +
 ..._1dcf100a28991c664681d78ed4c12e39._comment |   13 +
 ..._f56ac8a714facc8aafb60d3da815021b._comment |   17 +
 ..._cf173923509ec826a1962f9a934b5a64._comment |   11 +
 ...not_use_git-annex_inside_your_Dropbox.mdwn |    5 +
 ..._5a1dc9da6e6861829e321446ec7991ee._comment |    8 +
 ...x_parallelize_different_remotes__63__.mdwn |   46 +
 ..._764f43b51a075a8c94b433eda0cff946._comment |   27 +
 ..._dff46561e15ba5f386dc9cecb9c88e20._comment |   18 +
 ..._47269e2c40c5ce27ca197ddfd5ac85c3._comment |    8 +
 ..._b9444184ab653718fca9df5c2068ad3c._comment |   10 +
 ..._5098db1fad3290cba49ea1c1163cc168._comment |   24 +
 ..._ac6b01d2ff9dfe6060be5956d5adb632._comment |    8 +
 ..._101543247268097f7535660efe0d39d8._comment |   15 +
 doc/forum/done_bugs_are_missing.mdwn          |    5 +
 ..._400c15824ec84bd67583102a023edcf8._comment |   10 +
 ..._1fdcfb4ed807e424fe73f134c4ad9526._comment |   11 +
 ..._6eb74e1bcf6b062b61b25e59b0b1ddc6._comment |    8 +
 doc/forum/dot_git_slash_annex_slash_tmp.mdwn  |    5 +
 ..._14b74438bb1e3e02cff7926d774ba09a._comment |    8 +
 ..._b1f717342c1c8ea42a451caa2d936622._comment |    8 +
 ..._e2c6ad99333018c8c46e736da416b8ef._comment |    8 +
 ..._35ae9d6bcb8d9762a92e3564b686ed72._comment |    8 +
 ..._92b1e8956513dbf52da31cec3f58e2c5._comment |  104 +
 ..._839e29d41de9dcc8f01dfdc585a51d12._comment |   12 +
 ..._1a35ef8cb89e0cd392f6e9fcee1fb92c._comment |    8 +
 ..._f4cc36c493d7c20fbaf949edd38e1252._comment |   15 +
 ..._69268f8aa29e807a56248f1fac86aa41._comment |   10 +
 ..._0ffb0c803c232a1587f956f16113aeb7._comment |   27 +
 ..._c303e28825241733d69fca74f2015fc6._comment |   13 +
 ..._3f0b376e37bd092b8d46c46bb1940e35._comment |   14 +
 ..._615641b3dd176d4b3a5bbfb521098e38._comment |    9 +
 ..._4600fa9234a787004ea0e0dbb36184b9._comment |    8 +
 ..._4f5cd0d0d4db0479c1ad86ffdc5ae434._comment |    8 +
 ...oad_from_multiple_remotes_in_parallel.mdwn |    9 +
 ..._81e2612ddaffefec81455e9ff706c4c9._comment |   14 +
 doc/forum/downloading_from_moodle.mdwn        |   76 +
 ..._3f677130d268de4288e87cfa86ea055c._comment |   10 +
 ..._dcef60ec144f123dadd165fb602ab950._comment |    8 +
 ..._d3efb767bf9b20f96242dcf64817bd4b._comment |    8 +
 ...oading_mp4_by_default_with_importfeed.mdwn |    1 +
 ..._c9e5a3700764faa33d2c68de6a8236dc._comment |   15 +
 ..._ade70b45f49eb3eaf127ba7b2bd37900._comment |    7 +
 ...t_showing_gcrypted_special_ssh_remote.mdwn |   11 +
 ..._968bc2be595008790e9b93d82342714c._comment |   10 +
 ..._2c14d88e55ea7d4edc90ce0091025f32._comment |   10 +
 doc/forum/drop_old_versions_of_a_file.mdwn    |    3 +
 ..._799a413248fb8f98efbf226b1bc4300d._comment |    8 +
 doc/forum/dropped_files_keep_coming_back.mdwn |   25 +
 ..._84655c21f59b3904c950ddccccde53d8._comment |    8 +
 ..._223550574fa69effabe57c4bf257e54b._comment |    9 +
 ..._1a2ee19bfb3d56a2e2641dbcd89d8be2._comment |   12 +
 ..._02a6e3591acfa410ed7c7917dc573663._comment |   12 +
 ...0__user_error__41__._How_to_fix__63__.mdwn |   24 +
 ..._bb6d749b758b17178227929bf7327fe1._comment |    8 +
 ..._d834df30633f7d5569797ee818cf38c3._comment |   20 +
 ..._1e02eff33c9fa7bea03aa6d58b910175._comment |   14 +
 ..._with_suffixes_differing_only_in_case.mdwn |   27 +
 ..._0c1bb4347902054ec97ef86eb903f060._comment |   12 +
 ..._62bb4be1b31bd64a046763f68a2953ce._comment |   19 +
 ..._99a2e752c75e5ad2ea36254627be8d18._comment |   20 +
 doc/forum/empty_directory_handling.mdwn       |    3 +
 ..._34ac97b9337b6230ed8a4748203fe543._comment |    8 +
 ..._73a39e28d5a09ac342cb4195d263d91e._comment |    8 +
 ...nabling_git-annex-diffdriver_for_gitk.mdwn |    5 +
 doc/forum/endless_password_prompt_loop.mdwn   |    8 +
 ..._cceba12ed25cd671c7cee5a28631163e._comment |   10 +
 ..._f0cb86b45eb289f35197c43f83660a8f._comment |    8 +
 ..._eb1dce6d9af6e19cf77df63da1a68425._comment |   16 +
 ...at_in_GIT__95__CONFIG__95__PARAMETERS.mdwn |   52 +
 ..._aa740c16099f24fd8a067ef23435d0d4._comment |   13 +
 ..._5bcd8554e33a716208ca205d7c0467df._comment |    8 +
 ..._c3bca82915cc8bd35d3f41fc95436a18._comment |   14 +
 ...oes_not_point_to_a_valid_object__33__.mdwn |   17 +
 ..._d370b044da3bfebf9e4c90ce1e243587._comment |   18 +
 ...error_in_installation_of_base-4.5.0.0.mdwn |   14 +
 ..._0b2f79c014e0dd9badd52b8b6aa47e0c._comment |   19 +
 ..._3badd64e48fbb174cd7de1ac9589bedf._comment |   31 +
 ..._d8190061ac1c683a7b699cf42e9db694._comment |    8 +
 ..._49a4fcd2dc4f97d4055b5051feea5e3b._comment |    8 +
 ...id_configuration_of_repository_origin.mdwn |   19 +
 ..._943ff286824bd59a164b161553d65698._comment |   15 +
 ...e_of_massively_disconnected_operation.mdwn |   33 +
 doc/forum/exclude_files_from_annex.mdwn       |   10 +
 ..._82e7de5e631bae3b347815586274a936._comment |   25 +
 ..._03d4599fdceb3dff184eed82824674bc._comment |   12 +
 ...xpire_files__44___move_to_other_hosts.mdwn |   19 +
 ..._ddcc2a00be1ae96a352d75a443458bcf._comment |   14 +
 ..._7a4c3858c5eae409d04de3f9da43b57e._comment |   17 +
 doc/forum/export_single_file.mdwn             |    3 +
 ..._36d97e3c3f07411f3d367da546759ea5._comment |    8 +
 ..._ec3d3fb7beb3312571ffa471c39aaf95._comment |   10 +
 ..._0761201bf68e1086d263776eb953c1e1._comment |   20 +
 ...acking_not_enabled_when_branch_is_set.mdwn |   34 +
 ..._c007c52d0a038c26e4f8fc50a2d23a18._comment |   29 +
 ..._12c90792bd8c0c37bc53806843583733._comment |   32 +
 doc/forum/exporting_annexed_files.mdwn        |    4 +
 ..._e08e4c79588e17fb2f1cdf53d9fab7ea._comment |   16 +
 ..._15dc3024417b5b2ff3544a08beacab34._comment |    8 +
 ..._86f0e0f767a84a0f583e121d36cb7d48._comment |    8 +
 ...ttree__61__yes_always_untrusted__63__.mdwn |    5 +
 ..._fb579729238a36d5c3369ed07dd772ae._comment |    7 +
 ...l_special_remote_protocol_and_threads.mdwn |    3 +
 ..._f29c2b0f0f5e349e36eb47176e33498f._comment |   20 +
 ..._df97223aad2c8c95ce109944d64a59fe._comment |   10 +
 ...oes_not_exist__40__v_3.20111231__41__.mdwn |   26 +
 ..._990197bf01351dc1ccbe1940d5084adb._comment |    7 +
 ..._3bb1d21b7f0d0bd6d59190ae9d246d46._comment |   12 +
 ..._692f268218690437138ae0540c879425._comment |   16 +
 doc/forum/failed_to_push_anonymously.mdwn     |   19 +
 ..._bdf93b0e9fb109b7a4052a99110f6079._comment |    7 +
 ...n_usb_drive_made_me_lose_all_symlinks.mdwn |   27 +
 ..._3167052f67706797b00423a50f2ae7f1._comment |   23 +
 ..._0082ac7a148db69293a4e37fa6d6c891._comment |   11 +
 ..._6411aa3e6f5c1515845f3223bbcdabf1._comment |   14 +
 doc/forum/faking_location_information.mdwn    |   19 +
 doc/forum/fatal_-_corrupt_loose_object.mdwn   |   14 +
 ..._7b0da4185861fd5ff2a7345410678f82._comment |   10 +
 ...___Not_a_valid_object_name_repository.mdwn |   49 +
 ..._48f1ee21d24a99723ff455c0c9c96629._comment |   26 +
 ..._eef07cc389400c38b666da4e1adc255e._comment |   20 +
 ..._2760c9b8b755e1ed5e01b98ea3b99177._comment |   10 +
 ..._344561606daab9bc1a05ec3b857b2d62._comment |    9 +
 ...ailed__58___No_such_file_or_directory.mdwn |  112 +
 ..._d98a155fa01d10ecff9058d79290156d._comment |   13 +
 ..._3b9ea7a1254ac5b50a5ab59cd331ec3f._comment |    8 +
 ..._5ee300034819c5825c676cd7e3af659f._comment |   12 +
 ..._cf7f5c91d3c15f72d2a714b7362c1197._comment |   30 +
 ...8___export-tree_object_is_unavailable.mdwn |   15 +
 ..._e101855120be3639fce9f3725737b189._comment |    9 +
 .../files_being_dropped_undesirably.mdwn      |   47 +
 ..._d03f8ed7d3f3da58612bf238c1790fb4._comment |   11 +
 ..._7d885abebfec789348639494b1bb1829._comment |   24 +
 ..._7c70b58f89408304055eefb1b166ef2e._comment |   10 +
 ...inks__44___how_to_get_them_back__63__.mdwn |   23 +
 ..._4d07f87b433228fdaebce2805fc64492._comment |   17 +
 ..._97d24db6027270b9f2d759e98d5f428f._comment |   38 +
 ..._e61107dd83efecc3266217acad9c943b._comment |    9 +
 ..._362370f02ea77addf9efaed9cb4b433a._comment |   13 +
 ..._4333c2f189cea3430104ece6769143bc._comment |   11 +
 ..._8c4c2e8dc4706ca824cbbc9b2ed62be4._comment |   12 +
 ..._24b09f1263f6bc6b219085c17ced915c._comment |   49 +
 .../files_only_visible_in_.git_annex.mdwn     |   15 +
 ..._a967dc488d4fb0fd6079b0a1b087679f._comment |    9 +
 ..._e024e26b943f49a5e63c8fd1cd90a420._comment |   51 +
 ..._2c3d5991056d5915225b2707ad7d25dd._comment |   14 +
 doc/forum/files_vanishing.mdwn                |   12 +
 ..._eb69e88aee0005fca74dd540293e57ca._comment |   14 +
 ...nding_out_why_git_annex_import_failed.mdwn |   43 +
 ..._276bbd2dab64e4bbc297e0e53e02215d._comment |   12 +
 doc/forum/first-time_setup_git-annex.mdwn     |    7 +
 ..._a58d83ee3a7c2251d9a775847223f8ca._comment |   13 +
 .../flickrannex_--_not_sure_I_get_it.mdwn     |    7 +
 ..._57ea9f26760f970a70f09934d31a79b5._comment |    8 +
 ..._ba93563b4ce1f6497a9f1d5e6eb0d1bb._comment |    8 +
 ..._74f143965f48c89a3583acf1b6a7635a._comment |    9 +
 ..._493bb86dedfa91ccc0c9be4045953ee4._comment |    8 +
 ..._2c410aa478b21c0e6eb0e4d54bc8c362._comment |    8 +
 doc/forum/folder_size_question.mdwn           |    3 +
 ..._782cbf836335d86ff29853c34f00fec3._comment |   12 +
 ..._391aa62e4d8c496a58be4707522d8edb._comment |   22 +
 ..._1e850dbe36fafe0505b60dd2ce0bd5d7._comment |    8 +
 ..._907f3b1cfe745abf94a6a8ba0dbd4396._comment |   25 +
 doc/forum/forumbug.mdwn                       |    3 +
 ...-annex_seems_to_be_in_an_upgrade_loop.mdwn |   16 +
 ..._ce8e7f58c3b81ec334436726be70bde5._comment |   14 +
 ..._43cdcdfff3aaa4482e6182d3dd77b61a._comment |   17 +
 doc/forum/fsck_gives_false_positives.mdwn     |    6 +
 ..._b91070218b9d5fb687eeee1f244237ad._comment |   15 +
 ..._f51c53f3f6e6ee1ad463992657db5828._comment |   10 +
 ..._692d6d4cd2f75a497e7d314041a768d2._comment |   10 +
 ..._7ceb395bf8a2e6a041ccd8de63b1b6eb._comment |   10 +
 ..._86484a504c3bbcecd5876982b9c95688._comment |   13 +
 ..._1d4fbbd212fa92967abda346323031f4._comment |    8 +
 doc/forum/ga-ncdu.mdwn                        |    5 +
 ..._cde3f7bbd099b303bacdaa5e1588b71e._comment |    7 +
 ..._8d369dc264ccaf80490c1cb37a330239._comment |    8 +
 ..._c5ce3b663de76b50754de70b3fb23bf0._comment |   15 +
 ...start_playing_with_metadata_cache_plz.mdwn |   13 +
 ..._0547fcabefe0b8e99a43977ffec3e28c._comment |   10 +
 ..._606281f102d8c3168cbc55142a996e05._comment |   39 +
 ..._ca138f01184631135d07835d79a95112._comment |   15 +
 ..._750e5eaac44e53030be18858c03cbe6c._comment |   22 +
 doc/forum/gadu_-_git-annex_disk_usage.mdwn    |    7 +
 ..._f632a62c4dbbf01b29f146893d7725f9._comment |   15 +
 ..._73461da2d55d040cb43e0db286975821._comment |   21 +
 ..._6c4fb123091bde435c18ac3dfd5a9b77._comment |    8 +
 ..._8e0e86ae716ff018025808f417e1f7f6._comment |   14 +
 ..._d8f69914b88feb3f3ed4f72c26dd74e5._comment |  231 +
 ..._067d0ffe8900751bd2d2743254ac4d77._comment |   11 +
 ..._ec8b57426e4d82c3392eb7dd683f2ddc._comment |   17 +
 ..._38296fef5a2dc5794c2dc09df676b8c1._comment |   18 +
 ..._1bcc94f9982c6cfd0888f3dba0f9221e._comment |    8 +
 ..._4365cd3031456fac1b563ee72984638e._comment |   18 +
 ..._2b03d7b857497cb811e992f85700cdcc._comment |   12 +
 ..._03a4dfaf3bd73d41c6f3c3fab0a6a922._comment |    8 +
 ..._fc6ddb4dc075ee42368863c1b026dbf7._comment |   13 +
 ..._f03254e518cbdda73e4b88e72476275d._comment |    8 +
 doc/forum/gcrypt_os_x_app_vs_brew.mdwn        |   18 +
 ..._cce5e2c16720cc8e32a4a479f50ce6b3._comment |    8 +
 ..._8df8ba1ccea0f68110593ed90a9cad6d._comment |    8 +
 ..._be4de1663a37f49a4e42d6b21c0178fe._comment |   10 +
 .../get_and_copy_with_bare_repositories.mdwn  |    7 +
 ..._a6e4628c0770e3f5e81348a6f29dd845._comment |   10 +
 ..._652fa1bae5c2bb63dcffcbda97a567c4._comment |    8 +
 .../get_content_of_a_file_from_a_file.mdwn    |    5 +
 ..._174fe84e87b31419295af3397db19671._comment |   10 +
 ..._9cc8905f867fedbf2b10c9ad84294543._comment |    8 +
 doc/forum/get_fails.mdwn                      |   11 +
 ..._9c81adaedf2b526f735ed39cb9d24709._comment |    8 +
 ..._4ef8a59e82e38861fd36befde1ff9542._comment |   16 +
 ..._b4359d19a002a2903a895beae3888b4e._comment |    9 +
 ..._6227b1df801927cdf7a2edcc86bbdfee._comment |    8 +
 ..._472d50770325a87cc0daae3e6067558c._comment |  193 +
 ..._35174be903f055adf06af2fcdef807e3._comment |   18 +
 ..._annex_to_do_a_force_copy_to_a_remote.mdwn |   11 +
 ..._3deb2c31cad37a49896f00d600253ee3._comment |   14 +
 ..._627f54d158d3ca4b72e45b4da70ff5cd._comment |   12 +
 ..._3f49dab11aae5df0c4eb5e4b8d741379._comment |    8 +
 doc/forum/ghost_semitrusted_repositories.mdwn |   28 +
 ..._99bea1a964da9c5603b8cfbdc19bcde8._comment |   19 +
 ..._fe5fe5539d06c6b1ef69f3ed805f1ab4._comment |    8 +
 ..._588325ef52c80cfc67d1dd80a9d5bd13._comment |    8 +
 ...t-annes_assistant_+_MAC_OSX_questions.mdwn |   16 +
 ..._e661f31acd08a6459842f7f95e5c062b._comment |    9 +
 ..._e71a9d1fcf1f945fec0b7834b6038e91._comment |   21 +
 ..._372d9da8295d093b8b316f0a48b60ee1._comment |   12 +
 ..._573537a49e082515bfb1be84c91b5d1b._comment |   10 +
 ...addunused_with_original_path+filename.mdwn |   11 +
 ..._b24b20d6351d0373f9517438c33f05c1._comment |   12 +
 ..._cddedfd83ee154f44b83f2414eb103d0._comment |    8 +
 doc/forum/git-annex-import_questions.mdwn     |    2 +
 ..._e353e5ae20ba379c42fb39825c57147e._comment |   23 +
 ...pair_not_able_to_see_external_remotes.mdwn |    9 +
 ..._b30811d84190110b9d084e42bd4a6282._comment |    8 +
 .../git-annex-sync_and_git-annex-config.mdwn  |    1 +
 ..._1372a7d54e7ef017cc4fa34358c122e0._comment |    8 +
 ..._dd5cd6f18b3d0d9cf6ad97181fcbf4b1._comment |    8 +
 ..._46b1ab0fcc3b9e5a974d1bf1c4d912e6._comment |    9 +
 ..._e4e1d59b43fc954189306de242c37dcc._comment |    8 +
 doc/forum/git-annex-sync_with_bitbucket.mdwn  |   11 +
 ..._b95e03d119c83ac061c470801b157d55._comment |    8 +
 ..._31f7eae218447a17f316a8d13dd97ca0._comment |    9 +
 ..._eddbd42891a1877148a8920f19fb780e._comment |   19 +
 ...git-annex-sync_without_syncing_master.mdwn |    6 +
 ..._8ed0014e53a7ab49d76c072de074adda._comment |   22 +
 ..._585648a04a02760a1f16394c00728d79._comment |   19 +
 ..._233c20435643d2701c94a2cf30ca6483._comment |   25 +
 ..._a8f681ec33f2fef16b9b8eb6633f8fe4._comment |   10 +
 ..._a125638afe0cf57fe97e6051da943406._comment |   12 +
 doc/forum/git-annex-watch_clarification.mdwn  |    5 +
 ..._66de424e6d09b67cb75f6ddfef1424b2._comment |   10 +
 ..._aa709c1ee602ae3211f36cba68c155c4._comment |    8 +
 ..._db050d4b4d08100c6be204cd64ebfbf3._comment |    9 +
 ..._7255d87f5802a8d12204e4afc797070d._comment |   15 +
 ..._4a1b1176bf2499db67ffea2cce3115df._comment |   10 +
 ..._69a3377204ea4b102d9c15fb160e71b2._comment |    9 +
 ...esn__39__t_build_with_QuickCheck_2.10.mdwn |    8 +
 ..._0e25ab25c0fa3d41336e6b7551ef9e47._comment |   11 +
 .../git-annex_SSH_server_+_cloud_remote.mdwn  |   13 +
 ...s_not_exist___40__no_such_user__41___.mdwn |   24 +
 ..._94d92b7e64ad31db8837dcf3d131cf23._comment |   28 +
 ..._c9474c4e925948d0cabdfe7f988e1ebe._comment |   15 +
 ..._3a9e1cb8f36a44fd1917b5fc191776a3._comment |   10 +
 .../git-annex__58___map__58___1_failed.mdwn   |   12 +
 ..._35ff3256e823ab8cfc53276a2123ad5f._comment |    8 +
 ..._b0826073ebbd2847f4ab0d9bdba2dce5._comment |   14 +
 ...ource_busy___40__file_is_locked__41__.mdwn |    8 +
 ..._0a5894ed2c5e0b8155e69ff85741a51a._comment |    9 +
 ..._85dc89b0f0ad813321b034f3fd3a83a9._comment |   29 +
 ..._4462c0640e11e20a8655743ecc78eaaa._comment |   76 +
 ...___unknown_response_from_git_cat-file.mdwn |   10 +
 ..._96ad30294a6f18c0f73be1136de47632._comment |   22 +
 .../git-annex___38___ikiwiki_experiment.mdwn  |   28 +
 ..._9f74449ec91577dbf6095f4beafac293._comment |   10 +
 ..._e034585c8b51cc30b35c1f7ae68205bf._comment |   14 +
 ..._fbbd47c3dbe8de24b0df664e4afd5cb8._comment |   14 +
 ..._55da5c3c41c13b08590ce1ff8117cef6._comment |   23 +
 ..._f67823351164ddfe7d595685c3679652._comment |   10 +
 ..._d5cc91164772849d027fed5f962d9000._comment |   10 +
 ..._cb4ec7ed3c39d0649133191a85ea6ab3._comment |   17 +
 ..._86565e5e1508ff1862f88975446650a2._comment |   12 +
 .../git-annex_across_two_filesystems.mdwn     |   30 +
 ..._53167648b8b70b41d19ca662a5f3687e._comment |   26 +
 ..._39adeebc1af9c437f1fc2e00c07509bf._comment |   11 +
 ..._f4e3f28db005301adeef7ccd2c9998fb._comment |   18 +
 ..._53fa7ac6f80e3281768a7bfd3d438b34._comment |   10 +
 ..._2e1be54c01970ef3456e8af4aaf00cbf._comment |   10 +
 ..._aa6b153478f79c78e778865a99f01373._comment |   21 +
 ..._b87281c6a8b068cec60d2d5b7d015a23._comment |   25 +
 .../git-annex_add_out_of_memory_error.mdwn    |   38 +
 ..._d90d392db9a4962f9f8eb0ee95bf2914._comment |   24 +
 ..._459f810fd06aab3ddeeba8207d774dc0._comment |   21 +
 ..._d7d3785b65b0608424b25056c9e3a139._comment |    8 +
 ..._a2331032781c2fa3cdf22c0dc6b5b869._comment |   19 +
 ..._de9d956d95cb41e2372eabbf672e0f67._comment |   18 +
 ..._91af8300d640c34ff2466c89ec7a234c._comment |    8 +
 ..._ef913a45e3d865d088cf11460cd88020._comment |   14 +
 ..._64008199df70f77ab64882339aa079f9._comment |   11 +
 ..._6a8580087688b4bbfc3241292df5422e._comment |   10 +
 ..._76a65b4edf4f6e3896f1593a197f24eb._comment |    8 +
 ..._ffbb059664541c92dcbf97c150d9b951._comment |   42 +
 ..._7ef671c0036c77ee5707a6e00dd4dd6a._comment |   43 +
 ...e_other_way_around___63____63____63__.mdwn |   28 +
 ..._0bb5e21b4cbaaaa61fbdb2e0066f0ebf._comment |   12 +
 ..._ab6420f7bc18e8143201c603c09a0d7e._comment |   10 +
 doc/forum/git-annex_and_tagfs.mdwn            |   14 +
 ..._887c74cb61d30198322ef74ebc80f950._comment |    8 +
 ..._8769d6e57061023c0828af3e38faafba._comment |    7 +
 ..._d96948c444f9f485a329420b7c9e3b16._comment |    7 +
 ...ts_to_repair__44___but_never_finishes.mdwn |    1 +
 ..._a12892b2881969ddd6faa92d860e1bc8._comment |    7 +
 ...ex_assistant_with_2_dedicated_servers.mdwn |   11 +
 ..._533ade2215c879cd46782fd66a97b167._comment |   16 +
 ..._c9ae51d7b772cf7a91d90925f74d2b60._comment |   10 +
 ..._41fbee0ec9bc890e309bcd48a58c3851._comment |   18 +
 ..._571cffc0beb8ba5fc936db6971cd3d62._comment |    8 +
 ..._0fb62af673a4bc8183e8fef048ceedd4._comment |   10 +
 ..._53a79af2d8e3abe50b983bf91972b8f2._comment |   14 +
 ..._c0ba3e8b7fbf8a5ed718001cec8df676._comment |   35 +
 ..._60c39bc8ef74e80e72381d514b6dd223._comment |    8 +
 ..._6241120b4325c905661ef72881f4d7af._comment |   20 +
 ..._cab00b8fa195340f4d3fdaf5af975b57._comment |    8 +
 ..._e24df9a1c68724a912b8ac6533d9bd25._comment |   16 +
 ..._ace3dc7c60c710a04b0a587206b341c4._comment |    8 +
 ..._9a96bc970a17ed62b0ceb7aa3f0a6f8b._comment |   14 +
 ..._ea88e0696f6e25e6904248a323f6cc36._comment |    8 +
 ...Meego_Harmattan__41___and_Sailfish_OS.mdwn |    7 +
 ..._301a51c48c3d54f9d37feace26a772f8._comment |    8 +
 ...sing_zombie_git_processes_to_build_up.mdwn |   27 +
 ..._3bc5af3b28094fc042c207e307fe0c18._comment |   21 +
 ..._89b9fe9c689515a8f874dee96864ff33._comment |   14 +
 ..._b48f8d801305d9bde08060f06634b88e._comment |   12 +
 ..._41e0fada90d795b9be12929ed66231e1._comment |    7 +
 ..._4bd86a227f117dbf5d1b12fbcf873e62._comment |    9 +
 ..._a63df20ab1888e4dc5e7f002b4a68b5f._comment |    8 +
 ..._3908d1552421edb054dc1a56c449ad23._comment |    8 +
 ..._5adf7777f9495e28432a0d60a15493ee._comment |    8 +
 ..._b8a7f87aa1e9101fbb3e1d4e29febff5._comment |    9 +
 ..._122c584af1b1b6894cfccd4e16d2d76a._comment |   15 +
 ..._4668f6cc692c49a456418f783655602b._comment |   40 +
 ..._8e9feaea0e807cefee95166508c9c7de._comment |   17 +
 ..._02c5903bf4de4b94e6db84bc43b3b3d8._comment |   27 +
 ..._b6780a99d7a175d2ff3e33e198c28a9d._comment |   37 +
 ...o_and_GDrive_special_remote_in_common.mdwn |   20 +
 ..._10fa70e1e5e08e12ab7c1570881b38f8._comment |   18 +
 ..._ff0dab8dc544f7aa8e4ebfbec8f2a081._comment |    9 +
 .../git-annex_communication_channels.mdwn     |   10 +
 ..._198325d2e9337c90f026396de89eec0e._comment |   17 +
 ..._c7aeefa6ef9a2e75d8667b479ade1b7f._comment |    8 +
 ..._1ff08a3e0e63fa0e560cbc9602245caa._comment |    8 +
 ..._1ba6ddf54843c17c7d19a9996f2ab712._comment |    8 +
 ..._404b723a681eb93fee015cea8024b6bc._comment |    8 +
 ..._0d87d0e26461494b1d7f8a701a924729._comment |    8 +
 ..._2c87c7a0648fe87c2bf6b4391f1cc468._comment |   10 +
 ...by_a_case-preserving_filesystem__63__.mdwn |   73 +
 ...x_does_not_protect_files_on_NTFS-Fuse.mdwn |    8 +
 ..._4aef65f680e4801eb110fefa1f947f02._comment |   11 +
 ...ot_respect_preferred_content_settings.mdwn |   18 +
 ..._ea347ea6ebdfe5ccfb0ed8786638f279._comment |   17 +
 ..._5fac7c41c9841cea4234afa0a98b1636._comment |    8 +
 ..._e2ea1843bbc9580ca7b4ec494f53b552._comment |    8 +
 ..._59ede467a902f27b81f14e4706a7503a._comment |    8 +
 ..._doesn__39__t_build_with_feed-1.0.0.0.mdwn |  209 +
 ..._0be4545b1d93232a721c5ae65030334c._comment |    7 +
 doc/forum/git-annex_fails_on_Windows.mdwn     |   56 +
 ..._451a2cdfa6f26e2bd319ebf4ce09da68._comment |   15 +
 ..._57b4fd347f74b3536ab0f0a5d7709af8._comment |    8 +
 ...e_repositories___40__ssh_server__41__.mdwn |   73 +
 ..._cb691410d2a9ef4393af5362000a768c._comment |   12 +
 .../git-annex_help_import_outdated__63__.mdwn |   13 +
 ..._ada30e2fead4b5b8f5e53388f941eb07._comment |   13 +
 ..._ca898237f42af1205acab509e4d67d38._comment |   15 +
 ..._language_for_mere_humans_of_us__63__.mdwn |    1 +
 ..._29eda7ec1519f339d5b3601559fe0bb0._comment |   14 +
 ..._a2b2183ee86377cdfef7c3acbe9552fb._comment |   11 +
 ..._5605d42a68b3140cb660eb710ce5031e._comment |   12 +
 ..._f56508164c71b2080150bc354e5de4b7._comment |    9 +
 ..._c8cdb0faa342fe1f9407ad4c97e6bc3c._comment |   10 +
 ..._25ce5eddeb1b65aacd5d86e09c3719b8._comment |   13 +
 doc/forum/git-annex_memory_usage.mdwn         |   29 +
 ..._50753a133c200cdf6d855c65e6d4422b._comment |   15 +
 ..._does_not_appear_to_respect_numcopies.mdwn |   36 +
 ..._5dba0ff04c86c7b2697a0750fd1e4b5d._comment |   15 +
 ..._114cc3c9236ba930117cc14a0dddc3dd._comment |   18 +
 doc/forum/git-annex_on_OSX.mdwn               |    1 +
 doc/forum/git-annex_on_Samba_share.mdwn       |    9 +
 ..._3e9cfdf2c088e48c967ad08f79966742._comment |   12 +
 ..._9d3df393b7b727653598453d94dd33db._comment |   12 +
 ...on_Ubuntu_13.04_and_13.10_not_working.mdwn |   12 +
 ..._209956f3812450a43986d4ca5e647da6._comment |   10 +
 ..._12a58b8efe545e09b64760c87849839b._comment |   12 +
 ..._e0f7328603256f25c3be3706ecc9c76c._comment |   12 +
 ..._6bb8e4522241556fb82784d9b834cbfe._comment |   10 +
 ..._89a5296b461d400b51006074a13a4560._comment |    8 +
 ..._62daef4b4392c951b914a01b3effac11._comment |    8 +
 ...git-annex_on_archlinuxarm__44___armv6.mdwn |   20 +
 ..._88fa644df8614c2db0d092b3eb1d3156._comment |   10 +
 ..._b25ca7520ff7e339ec887a379d5100ee._comment |   10 +
 ..._eda0e90c1285396b1ab20ecc04ea6e29._comment |    8 +
 doc/forum/git-annex_on_openSUSE.mdwn          |   20 +
 ..._97313a8a7fc7f558b5956989442a0f0b._comment |   13 +
 ..._bbe6925ca465d13b050639c18abcd890._comment |    8 +
 ...loses__47__doesn__39__t_run_on_launch.mdwn |    7 +
 ..._a47174f8438bfaa42fb8067bca77bf4c._comment |    8 +
 ..._567bb460cec7cd2135386acf4e7dceb4._comment |    8 +
 ...l_invocation_and_the_git-annex_branch.mdwn |    1 +
 ..._3ece379be6645e75eff0d0acdc0a832f._comment |   12 +
 ..._5aa79212878820270d9148275829727b._comment |   11 +
 ..._8a46c0146f81d6d6147d8cfdc1277595._comment |   22 +
 ..._aec9399cdf7b11011c9b577a6800b490._comment |    7 +
 ..._aa4091341c7a067b46b57dea9dd02c22._comment |    8 +
 ..._7d6d0da2243967b9660d8222c546112d._comment |   18 +
 ..._ae5fb82005702e9b5ed14fa37f80a91a._comment |   10 +
 ..._b0bc7c10d97a03497354aef2b011e1f1._comment |    8 +
 ..._deb88db3c97645b1aa180813401fa436._comment |    9 +
 ...nex_pre-commit_eats_all_my_4GB_of_ram.mdwn |   24 +
 ..._ff16c7932b60b85c744bafc48bb040e4._comment |   13 +
 ..._5599cddf579d18f70cab6e48d04ae99d._comment |   12 +
 ..._412941e9385f63153b23695641e71deb._comment |   15 +
 ..._112ad140d9006c530db2121bec24de30._comment |   10 +
 ..._9178023b95683a649355f291165a1467._comment |    8 +
 ..._9251203421c1c3c3aed7828c4b97ecb8._comment |   17 +
 doc/forum/git-annex_s3_failure.mdwn           |   33 +
 ..._099023ae32a6a3417cc9c8bdcce9a89d._comment |   16 +
 ..._c869b85bb2bea4a7a99e107f4a3cfb0f._comment |    8 +
 ..._b9e52fe4d14104398d57a6bcc7f2deaf._comment |   10 +
 ...nt_available_from_which_version__63__.mdwn |   12 +
 ..._104e1b7e7643844f221f85dcbe9c9c4b._comment |    8 +
 ..._sync_fails_in_repo1_but_not_in_repo2.mdwn |   45 +
 ..._5cca2fbce3db1c691f43e43f9343f9bd._comment |   10 +
 ..._1dfeb722edd54c68b4220d00c0a175e5._comment |   35 +
 doc/forum/git-annex_sync_here.mdwn            |   19 +
 ..._3ebef27614bd72b38404c1940007e68c._comment |    8 +
 ..._1b0543443759202ec6a85a26088ddb43._comment |    9 +
 doc/forum/git-annex_teams___47___groups.mdwn  |    5 +
 ..._0450673ab74f184a47ac7bab568d26dc._comment |    8 +
 .../git-annex_tor_remote_not_working.mdwn     |   15 +
 ..._15cce70b24769832ccf9782d1215d605._comment |   20 +
 ..._e17a7f8a98f4614f46f05228f604a562._comment |   10 +
 ..._8ca1bc7358ad96ffb711d7ab1e4fd22a._comment |   10 +
 ...nex_unused_not_dropping_deleted_files.mdwn |   34 +
 ..._2152cfb09675e46e7492e198dd3ea094._comment |    8 +
 ..._97e666dbac9de2a5e688921cba8a42e9._comment |   20 +
 ..._d7b0e9515bface28f3650b8aa20ec2f4._comment |    8 +
 ..._5816f6cab42e27e724e735368f693b09._comment |    8 +
 ..._8e97f39225515f0bf8b168dfd6a0efab._comment |   10 +
 ..._bef37f8ec9c337387b79ffd6d56fe425._comment |   10 +
 ..._bff3bcf9f1b7c458afa98cdb18883153._comment |   28 +
 ..._7259b8e9616009472ad3a10426f3d8ea._comment |   17 +
 ...sed_on_directory_special_remote__63__.mdwn |   15 +
 ..._5fb31042ed7c5c52969451b6fc0f4ddc._comment |   12 +
 ..._content_settings_are_not_being_saved.mdwn |    1 +
 ..._81111f59caea9f70cb9d597381e42c96._comment |    8 +
 ..._8ca9156d21d9f3db0d83d6aa9b69caa0._comment |   17 +
 ..._9da6ca0250ab0dcfc9a012df75e2e711._comment |   12 +
 ..._55c52c45f3aaddfb63a1f53efe2ee582._comment |    8 +
 ...x_webapp_launch_behavior_is_confusing.mdwn |    8 +
 doc/forum/git-assistant_clarification.mdwn    |   11 +
 ..._8f553e59da12f798b854a457b96b5778._comment |   14 +
 ..._06cf62b599edea6ad8396776f0081494._comment |   10 +
 ..._36f0bd6e7a824e6ef40a309850bb087b._comment |   15 +
 doc/forum/git-like_git-annex_diff.mdwn        |   11 +
 doc/forum/git-remote-gcrypt.mdwn              |    1 +
 ..._175c8c35d9bbb470fcc17697eb8cc6b8._comment |   12 +
 ..._fdcaf507e14c995636dd93a41e488df3._comment |    8 +
 ..._f4e830f961dbe1c60ddd277b9d888133._comment |    8 +
 doc/forum/git-remote-gcrypt_and_rsyncd.mdwn   |   32 +
 ..._34dd343ed75918f5969f6a23dfae3317._comment |   15 +
 ..._78b89867bd1af78a91826022651a57ad._comment |   18 +
 ...air_doesn__39__t_build_with_GHC_8.0.2.mdwn |   10 +
 ..._0a6ea834f6515b888e5c40fef08f4e2d._comment |    9 +
 ..._bb490f71aed0cfe119beac66cecae99c._comment |    9 +
 .../git-status_typechange_in_direct_mode.mdwn |   48 +
 ..._12c8b67aadbfa2b073e12997a55d49a7._comment |   12 +
 ..._005d1b17f3c2ae192aa30c6e5163989e._comment |    8 +
 doc/forum/git-subtree_support__63__.mdwn      |    9 +
 ..._4f333cb71ed1ff259bbfd86704806aa6._comment |   10 +
 ..._73d2a015b1ac79ec99e071a8b1e29034._comment |    8 +
 ..._c533400e22c306c033fcd56e64761b0b._comment |    8 +
 ..._75b0e072e668aa46ff0a8d62a6620306._comment |    8 +
 ..._f5ec9649d9f1dc122e715de5533bc674._comment |    8 +
 ..._85df530f7b6d76b74ac8017c6034f95e._comment |    8 +
 ...re_too_many_unreachable_loose_objecs_.mdwn |   29 +
 ..._e3c37fc6e45de48a4d5c1eb36e8d44df._comment |   19 +
 ..._c77b9790da099a94ee368de6a557d4b2._comment |   18 +
 ..._f0c6869f31a31803adec0fdc0befa178._comment |   18 +
 ..._a_git_command_error_after_installing.mdwn |   38 +
 ..._8a2e3be32800b7b8a6fa78bbdcba7608._comment |    8 +
 ..._451b3c89d1b98212d5c21efa4e535424._comment |    8 +
 ...nex_add_crash_and_subsequent_recovery.mdwn |   25 +
 ..._062d0153a379c1ba1df8585b90220d3d._comment |   18 +
 ..._6fc6be43c488c468a4811cd0a1360225._comment |   19 +
 ..._45efaaf27d9b580c4c75cbcdc4f65b64._comment |   10 +
 ..._c560eae40867512b0af2cbef161fc8ac._comment |    8 +
 .../git_annex_add_freezes_on_direct_repo.mdwn |   21 +
 ..._290df6fdd3c9042308638f1e8b66b805._comment |    8 +
 ..._3aa5d0ef823592baab79382851385979._comment |   11 +
 ..._cba1ba0c8b0f2e0f4186e7695d9df569._comment |    8 +
 doc/forum/git_annex_alternative.mdwn          |   10 +
 ...ant_-_Changing_repository_information.mdwn |    1 +
 ..._cde71a410200a7478180748fdcde0352._comment |    8 +
 ...istant__44___share_with_other_devices.mdwn |    3 +
 ...ex_assistant_repository_history__63__.mdwn |    7 +
 ..._6f87f31e18cefedcc6bce95dbeb85a0b._comment |    8 +
 ...-to_blah_much_slower_than_--from_blah.mdwn |   15 +
 ..._5b6e0b749b01a97a6b52a2c1cca6e35a._comment |   12 +
 ..._8f2567f4c4f6db2078211a87689757d3._comment |   17 +
 ..._ab98121076b88f351fc8cd9197e6bf64._comment |    8 +
 ..._cb13328add1b7a812efd817ad3dd1a4f._comment |    8 +
 ...e_about_why_some_files_are_not_copied.mdwn |   59 +
 ..._75445fc0e01ee99bae1c1f5a60e314bc._comment |   12 +
 ...nex_copy_to_google_drive_is_very_slow.mdwn |   11 +
 ..._f3085ef9ddff51ee4110cc1000d26da2._comment |   16 +
 ..._539dbce8852a9b6ae20ff0e55e74fc2a._comment |   17 +
 ..._drop_not_freeing_space_on_filesystem.mdwn |   25 +
 ..._ce1b32c2765edb695e5d9dc8f0ac86e3._comment |   16 +
 ..._248cb012c87605479fb17fa4aadc1185._comment |   16 +
 ..._de4aa12c84a6025497f8c743a397ef63._comment |   14 +
 ..._368b2c07dc7d98534a77c6153e8486ae._comment |   18 +
 ...glish_filenames.__Rsync_problem__63__.mdwn |   24 +
 ..._292ee7c8b37cbd13f03eb67d0359b99e._comment |   10 +
 ..._f6341119fcfde5d8160c8f603b1a6fea._comment |   10 +
 ..._8ad3a1d1fe5995d61e5e137280bc76c3._comment |    8 +
 ..._86b61b0484f3f4ecff657e46333b3d4f._comment |    8 +
 ..._5ffac00d08d26acaba8c3513b24c4d65._comment |   10 +
 ...content_replaced_with_symlink_content.mdwn |   32 +
 ..._f6f4be7161d4c35c7de1d9751ddbd3c3._comment |   14 +
 ..._da848024c40eb65e6214bd95b73e078e._comment |   11 +
 ..._cc703ef5015527425572002295568923._comment |   13 +
 ...nnex_get_--want-get_another__95__repo.mdwn |   68 +
 ..._0be0b3981ddd0743ff26cf6d396e521d._comment |   16 +
 ..._b1ead1085a87818625579bf1ef151b5d._comment |    8 +
 ..._cf2018852c84b0bf1ac061def6f0ac5d._comment |   27 +
 ..._22562e8f1f2f91b9f9a5939ec9006cb5._comment |   38 +
 ...ils___40__Action_blocked_by_GIT__41__.mdwn |   11 +
 ..._476b96f4ffd57bfe6e66c5388a19e9a5._comment |   17 +
 ..._6da3b78489ea140b321d780ef669bcd3._comment |   17 +
 .../git_annex_get_creates_a_new_uuid.mdwn     |    6 +
 ..._004c87183968c326058bd3159a5baa0b._comment |   14 +
 ...x_hanging_in_smudge_on_2k_file_on_rpi.mdwn |   11 +
 ..._06b5d0c9c6037ffdafab6c01763061de._comment |   25 +
 ..._471a44594af15057dd4781e759013627._comment |    9 +
 ..._66f89cded0da36e96099d29542f2455b._comment |    9 +
 ...nex_info__58___local_annex_keys__63__.mdwn |   27 +
 doc/forum/git_annex_init_timeout.mdwn         |   43 +
 ..._e456f5367af5a5a3a31fc982952079e3._comment |   22 +
 ..._bf15b686b07c5e6e95796affa497a541._comment |   13 +
 ..._1e733fad01e6b420c7fd9f7832e9b3f7._comment |   10 +
 ...nlock__47__fix_on_non-committed_files.mdwn |   15 +
 ...___47___metadata_in_git_annex_whereis.mdwn |    1 +
 ..._7fba10b85f4d9289c7782eccef46949e._comment |    8 +
 ..._7dcec124ea7d0291ed40d80e2ffd5c7e._comment |    8 +
 ..._24c54ed70220974b98700bf717d1e770._comment |   29 +
 ...sx_only_creating_symlinks__63____63__.mdwn |   18 +
 ..._6889c4452e636474b4e70798b404fed2._comment |   10 +
 ..._978fc11c463a457382fddd668cd1d0dd._comment |   20 +
 ..._4420bd3afaecd7536b02fc08cee82dbe._comment |    8 +
 ..._99286f17a87049c303f2aa34c0a90286._comment |   13 +
 ..._39bad7441dcea4da4b389700301233de._comment |    8 +
 ...air_--force_fails_without_explanation.mdwn |   34 +
 ..._716cbfe900552a453965ac4abd44e7a4._comment |    9 +
 ..._f8ff4c8663d8b7bb30f7b7763be33501._comment |    8 +
 ..._682cb114d133713f80bdda97a4435a5e._comment |    8 +
 ..._cbc49405ab99e8722216739732ce394d._comment |   20 +
 .../git_annex_repairs_since_thursday.mdwn     |    5 +
 ..._38b4563db47ce9bdc52eab5506de20f8._comment |    8 +
 ..._b072ad2864e1caa7459d17d3426c8eee._comment |   12 +
 .../git_annex_sync__58___only_git-annex.mdwn  |    3 +
 ..._2be68ed36a1e6bfc896d5aea9463d3c7._comment |   14 +
 ..._50e137e4d278dfd0103a41aff0cfa3a9._comment |   10 +
 ..._7753f8276478e0e05c10dba2b84bbc49._comment |   12 +
 ..._52010f21a15d76d68986aa1fba29aaf1._comment |   10 +
 ..._df94154fbbc4edbf7ff658f61bde48b5._comment |   11 +
 ..._sync_destroys_data_on_shallow_clones.mdwn |    2 +
 ..._431fef51e00f19cdf206a5ab97570be5._comment |   84 +
 ...annex_sync_dies___40__sometimes__41__.mdwn |   22 +
 ..._48bbac0545bf13bbf04da723e418d037._comment |   14 +
 ..._sync_remove_all_recently_added_files.mdwn |   40 +
 ..._6c059f7b2eb9d213bc0865739832b5d2._comment |    8 +
 ..._27a56e101f7c3fcba90b4c69fa39f4c4._comment |   10 +
 doc/forum/git_annex_sync_update_remote.mdwn   |   50 +
 ..._d6410587c442bd6323991f7839c1b5b2._comment |   10 +
 ..._704cf62eb4add2459e509cc5fdbfeb68._comment |   24 +
 ..._9b6ecb7342aab7f0320ed7567ee5fa0b._comment |    8 +
 ..._221e01e024595f444e629db510eb60be._comment |   22 +
 doc/forum/git_annex_test_on_windows.mdwn      |    5 +
 ..._258ac5cfa2f5d24e737d94dc48f06899._comment |   10 +
 ..._annex_uninit_creates_broken_symlinks.mdwn |    7 +
 ..._b7fb7fac51f59b23aafbc8dcce0aef07._comment |   11 +
 ..._40__preferred_content__41___examples.mdwn |   37 +
 ..._1e59c9476b206613285e4f39b2c9efa8._comment |   14 +
 ..._9d0cfb1d221e3ac6ed15db9cefab60fa._comment |    7 +
 ..._78bc3e56502e425f4f77bc35ed2199b8._comment |   41 +
 ...le_exists___40__it_doesn__39__t__41__.mdwn |    7 +
 ..._08e3d99b682e640b72d0094d593f9d53._comment |    7 +
 doc/forum/git_annex_view_tags_failing.mdwn    |   16 +
 ...o_repair_every_time_it__39__s_running.mdwn |    5 +
 ..._c182b03bae6e691eb68465fedf5c77d5._comment |    9 +
 ..._6b3427b2d3e1c5f4c0582be1020c89f8._comment |   12 +
 ...put_with_two_variables_with_same_name.mdwn |   21 +
 ..._3bfde59729b904aa1ef815427dd35ae6._comment |    8 +
 ..._d08a955a11953cc783f09bfba180dbd6._comment |    8 +
 doc/forum/git_annex_windows_and_rsync.mdwn    |   26 +
 ..._33249bf910446fcf98ffb2e7e35017bf._comment |    7 +
 ...annex_with_local_apache_webdav_server.mdwn |   23 +
 ..._a3b89f90f9ac70e0a9b0711ede1cb810._comment |   12 +
 ..._d8e9237cf6e7f7558f836ba1352f5517._comment |   13 +
 doc/forum/git_clone_over_ssh_hangs.mdwn       |   17 +
 ..._07ffe356ef5c441118cc9329060812f2._comment |   12 +
 ...git_lfs_special_remote_implementation.mdwn |    9 +
 ..._a61494b02c831e84903f28d9900850ac._comment |    7 +
 doc/forum/git_pull_remote_git-annex.mdwn      |   11 +
 ..._9c245db3518d8b889ecdf5115ad9e053._comment |   36 +
 ..._0f7f4a311b0ec1d89613e80847e69b42._comment |   14 +
 ..._1aa89725b5196e40a16edeeb5ccfa371._comment |   14 +
 ..._646f2077edcabc000a7d9cb75a93cf55._comment |   37 +
 ..._4f2a05ef6551806dd0ec65372f183ca4._comment |   10 +
 ..._3925d1aa56bce9380f712e238d63080f._comment |    8 +
 ..._24c45ee981b18bc78325c768242e635d._comment |    8 +
 ..._7e76ee9b6520cbffaf484c9299a63ad3._comment |   12 +
 ..._status_is_slow_twice__44___then_fast.mdwn |   39 +
 ..._a32e4d4255a1afcfd05c374d0fffccab._comment |   10 +
 ..._1aba5ad6deb4634fca187ecc69a6adf9._comment |   11 +
 ..._status_typechange_in_v5_direct_false.mdwn |   33 +
 ..._eb4e2b1fd7615e2b6936b5df01d68d1f._comment |   16 +
 ..._19df04820aa80549cfabac0141c372c0._comment |    8 +
 ..._20e04806a59e05a453431cb90086ccac._comment |   10 +
 doc/forum/git_tag_missing_for_3.20111011.mdwn |    1 +
 ..._7a53bf273f3078ab3351369ef2b5f2a6._comment |    8 +
 doc/forum/git_unannex_speed.mdwn              |    1 +
 ..._10cf326248f4e89e1f75bf97d7574763._comment |    7 +
 doc/forum/git_unlock_failed.mdwn              |   22 +
 ..._483dbd405b41b7bce343d7c08be8d92f._comment |    8 +
 ..._76903b206b8cf6dced44a2da29f57201._comment |   27 +
 ..._3331c627e0a48f8d2698b2bda1e0748f._comment |   11 +
 ..._a24ddc8effd6983d6ed1d3a5e1c62b45._comment |    9 +
 ..._e88de8c0fdd998236ba18a60d9308df8._comment |    8 +
 ...ate-index_message_after_git-annex_get.mdwn |   17 +
 ..._606b627b91a6e9864653ed86252b4bd7._comment |   15 +
 ...ls_and_daily_free_retrieval_allowance.mdwn |    6 +
 doc/forum/got_confused_by_fsck.mdwn           |   43 +
 ..._ab35fea4d46ee93e62ab67e5af3dfcbf._comment |    8 +
 ..._19c730cb1337dc8794721cf5679c930b._comment |   18 +
 doc/forum/handling_MP3_metadata_changes.mdwn  |   12 +
 ..._aa4955fd64ea5aa836f1a591e185c4a2._comment |    8 +
 doc/forum/hashing_objects_directories.mdwn    |   27 +
 ..._c55c56076be4f54251b0b7f79f28a607._comment |   12 +
 ..._504c96959c779176f991f4125ea22009._comment |   14 +
 ..._9134bde0a13aac0b6a4e5ebabd7f22e8._comment |   12 +
 ..._0de9170e429cbfea66f5afa8980d45ac._comment |   12 +
 ..._ef6cfd49d24c180c2d0a062e5bd3a0be._comment |   12 +
 ...lp__44___a_bunch_of_files_disappeared.mdwn |   15 +
 ..._56cffd43ad7056a34c23b139f95ea58e._comment |   15 +
 ..._7675ff78cf1b5f58618c5c57da8591b5._comment |   23 +
 ..._4b700ccba2b40fdc1d172a3dcbc441e5._comment |   10 +
 ...ing_git-annex_on_top_of_existing_repo.mdwn |   12 +
 ..._4cb38d71c943657c5ba0896cd70d2e64._comment |    8 +
 ..._b5e94c10ebbed9125c7e2332f75709ca._comment |   13 +
 ..._2b3b93bbc60fbc24d436231954d6822a._comment |   10 +
 ..._2dfda33ffa39b92b16c8bd9005e1cefe._comment |   21 +
 ..._96b1eb1e8e9f315c646f4686870f9b52._comment |   10 +
 ..._e85c3fa1d17f1d6ec625b9c4f9b698c3._comment |   47 +
 ..._15d918ededb5b8375b0ca13d0b3523ff._comment |    8 +
 ..._dcc3f2c6d55006776610e8d770b61d12._comment |    9 +
 ...ith_building_git-annex_on_conda-forge.mdwn |    8 +
 ..._369460f5de3219b80a7b2da5bda9aced._comment |   13 +
 ..._e72eaf736e2a534fa5970183a2f671af._comment |    8 +
 .../how_do_automated_upgrades_work__63__.mdwn |   11 +
 ..._cfd00ac3a3eaa3c2a1d430f6544c32f0._comment |   15 +
 ..._5ef98e46c514e9b794ee719e4cc8fda4._comment |    7 +
 ...manually_sync_my_external_drive__63__.mdwn |    9 +
 ..._4fd8722cafd55b0503c802289206645a._comment |   10 +
 ...annex_commands_supposed_to_take__63__.mdwn |    9 +
 ..._26d959bb3cfdc690b1eab41c9b0b5dc4._comment |   31 +
 ..._move__34___URL_between_remotes__63__.mdwn |    6 +
 ..._d4fb3eff1b61c60224fec112df9f1136._comment |   37 +
 ..._c122906fd03bd723aa027fe32fd4fab6._comment |    9 +
 ..._adebe3ba65ba9fc0a4a7f4b664afc069._comment |   20 +
 ..._46ad0779ff71cfbadd663fe413d32ffb._comment |   14 +
 ..._712f40f27b27dfaf58c416ca7dc19045._comment |   17 +
 ..._260c238435f8f5e53511de7e574dd53f._comment |   29 +
 ..._742fde3d8f7aa0caa39dadc961c1b3d3._comment |    8 +
 ..._removed_files_as_repo-droped_entries.mdwn |    9 +
 ..._a9a4baebfb647898a76ee3d5ab6febfd._comment |   13 +
 ..._68392de15bae234de1332b8bc80cc2ff._comment |   26 +
 ...e_from_encrypted_special_remote__63__.mdwn |   14 +
 ..._d4dc451892e7a6e230bf32adb7f3f9fa._comment |    8 +
 ..._79340bf3c0691073a9808c5ac2da0a3d._comment |   14 +
 ..._6302fb6e5bb7cbddf2cfe74d98d32897._comment |   12 +
 ..._e3d95bc09c9fb21e8e9bbacc642aa60f._comment |    8 +
 ..._f2f0a1c2fb0c6323707b11e2b06aa2db._comment |    8 +
 ..._66fe80e634a8f13cce18fe68974ec67a._comment |    8 +
 doc/forum/how_to_disaster_recovery.mdwn       |    6 +
 ..._be3cf3736166855012e10c2d251043e9._comment |   13 +
 ..._7fa36912ae21a66d3174fec35356d7ba._comment |    7 +
 ..._f2e570dc60a6f16e8f696d94e253775f._comment |    7 +
 ..._c8db90fd7af13b9605e152ea884b5241._comment |   15 +
 ..._31cce673114eb9733e0f1c732c8f08e6._comment |   12 +
 ..._52ad88121efa92d2c64bb2816884d66b._comment |   67 +
 ..._444579d0dac2ca14e6b1cbadcca5fcf3._comment |   24 +
 ..._9b9403a80c5b0a1a441dfb94feece37d._comment |   20 +
 ..._e8ec7b1fbbb81d61d06a7def61b06354._comment |   16 +
 ..._7e08eb18e965f47782a39d0426b75b93._comment |    9 +
 ..._78720819bea58f30146451dd953f10a5._comment |    7 +
 ..._b16c74c0add6d15b75163859a752d207._comment |    9 +
 ...ow_to_edit_the_git-annex_branch__63__.mdwn |    9 +
 ..._fa1936401d1abe1a28dc88968528e186._comment |    7 +
 ...force_read-only_in_enableremote__63__.mdwn |    3 +
 ..._a1206c8517f467d9a584ba89ef0e101a._comment |   23 +
 ...lly_running___96__git_add__96____63__.mdwn |    5 +
 ..._440dcd19ea2512f968858b780c2a2913._comment |   22 +
 ..._e9b70386774996a3d0446faaa3219120._comment |    8 +
 ..._3dbd76accad2df2fff14b55452c828ef._comment |    8 +
 ..._bfb4758fdb2a4afafd9c4d45de5c5c6b._comment |   28 +
 ...nks_but_keep_historical_file_contents.mdwn |    7 +
 ..._cba76311e146dabb8ffc789bf4c8b714._comment |   14 +
 ..._8d99c50fc1347367ccc0714e8d1af385._comment |   40 +
 ..._a7a9c55c2ad448179dff5d5b69976c7d._comment |   10 +
 ...omputer_and_a_centralized_backup_unit.mdwn |    9 +
 ..._a0551431a57ccab2463f2a6d43553337._comment |   15 +
 ..._e96e8cf6e08e3a21bfcefbc202e78fe2._comment |    8 +
 ..._2ad4c1a4bfe00c22444ab878c84a8830._comment |   47 +
 ..._44639388349a9ea5eabda9ebf79817b3._comment |    8 +
 ..._339123ab87b69b11d6e999ad6eaf6df5._comment |    8 +
 ...w_to_speed_up_metadata_view_genration.mdwn |    1 +
 ..._56044eef4cee8940a9bd5f66d2b1cd8f._comment |   14 +
 ...k_to_existing_direct_mode_git-annexes.mdwn |    5 +
 ..._7bd0edaf2352293678f0942aaa885d13._comment |    8 +
 doc/forum/howto_update_feed.mdwn              |   14 +
 ..._bec356619f370a618f19a187d09d2e35._comment |    8 +
 ..._84dfb80ba3db8d41164eb97022becae3._comment |    8 +
 ..._20166db298c10074e062aecad59ffd71._comment |   20 +
 ..._f040e31b763fc9a7aa092442b4d6b8e8._comment |   20 +
 ...les___40__not_binary__41___-_compress.mdwn |    4 +
 ..._bd0925e056c275c52b59f947e23afe86._comment |   19 +
 ..._44eb5f14dbf3c5061afeb847958f27fe._comment |    9 +
 ..._4788a41425d4cc65e9f529dbcdb2bf73._comment |    8 +
 ..._4dbb0b18905d30ae6b187745859e75c2._comment |   12 +
 .../ignore_changes_made_by_a_remote.mdwn      |    8 +
 ..._825676069d2e1554499b76fd8c306c30._comment |   10 +
 ..._dff49b72f7e072fddaf68584beb97f3c._comment |   10 +
 ...d_export_treeish_for_rsync_and_webdav.mdwn |    3 +
 ..._6a8ee189ff2fee0697b67a405f22c5a4._comment |   28 +
 ..._58___comments_in_file_with_feed_urls.mdwn |    5 +
 ..._370f5165fdda5c01a5335c864321a348._comment |   23 +
 ...ed_does_not_work_with_youtube_anymore.mdwn |    1 +
 ..._2fcbc85d7aa51dfdb2025a00c37fa8ac._comment |    8 +
 ..._58733a5065493dbac5cb8d12a029dace._comment |   14 +
 ..._aef7c172d485f8f6570ada5756446480._comment |   19 +
 ...es_a_second_time_prepending_a_2__95__.mdwn |    8 +
 ..._1623344457fbe10c464506e41fbac3d8._comment |   19 +
 ...ple___34__overlapping__34___playlists.mdwn |    1 +
 ..._ecd0764e7f15469217fd5e04a563f34c._comment |    8 +
 ..._b9885808ebe447c26283f910f4fc37c3._comment |   17 +
 ..._aa1077117a83ecffccb8d2095818fa02._comment |   10 +
 ..._0bf6d5b03032c0b9fd35c8410aea832c._comment |   16 +
 ...rerred_content_expression_not_working.mdwn |   31 +
 doc/forum/incompatible_versions__63__.mdwn    |    1 +
 ..._629f28258746d413e452cbd42a1a43f4._comment |    8 +
 doc/forum/initremote_type__61__web.mdwn       |    5 +
 ..._9ad92da9525cd89e515d1c5745a59c13._comment |   18 +
 ..._acc1dce80c3ed3b13fdfba55ab362581._comment |   10 +
 ..._b222de7b3d4397fe8bcafd20c661bc64._comment |   18 +
 ..._d128b2abef6cfdcac679aeff7a52d493._comment |    7 +
 ..._8de26c367ccb68b917b0b5f91eec8d1a._comment |    9 +
 ...e_assistant___40__android__41____63__.mdwn |   12 +
 ..._d9e0c9471c14178a1b3d07d3c6d76897._comment |   10 +
 ..._a73cbde4297d1be734c768d7b8f9d597._comment |    7 +
 ...retry_when_special_remotes_fail__63__.mdwn |   37 +
 ..._82820ce711b87b092a21e31fd381ffce._comment |   19 +
 ..._160e80583b647eae53aa120ca734e34a._comment |    9 +
 ..._6d81a41edf052e310e1f80cc6add3c09._comment |    7 +
 ...mmit_some_files_in_direct-mode___63__.mdwn |    5 +
 ..._804e43111ee97dff15e49e50b6c29d91._comment |   14 +
 ..._299ad6cd0225daa166d36af3726a9ef2._comment |   14 +
 doc/forum/is_windows_really_slow__63__.mdwn   |   16 +
 ...ecame_readonly_after_really_long_fsck.mdwn |   16 +
 ..._6c094472d7f6f5f0257a445805200a82._comment |    8 +
 doc/forum/keys__44___URLs_and_URIs.mdwn       |    1 +
 ..._d285566ca97e720a7bb497c0db8cc0c2._comment |   20 +
 doc/forum/known_and_local_annex_keys.mdwn     |   14 +
 ..._3cb4828dc7116e4cf49e119f055ae9a3._comment |   20 +
 ..._68f20c881eafe986694bde10571cf1c0._comment |   10 +
 ..._e195a7091a06ce0427bb28aca9a17d04._comment |    8 +
 ..._d81f0bf7465832cb676fd89f5d53ec18._comment |    8 +
 ...__58___fail-on-unspecified_mode__63__.mdwn |    8 +
 ..._0bddf22d95cccf68a2852d7ef3a6dc19._comment |   23 +
 ...library__44___backup_and_music_player.mdwn |   11 +
 ..._a6e38a1678c433e5a5d96afae4ae4332._comment |   26 +
 doc/forum/linux_standalone_tarballs.mdwn      |    1 +
 ..._5c3ceb845a45e50784f7098bfbf94df1._comment |   13 +
 doc/forum/local_pairing_with_2_mac.mdwn       |   27 +
 ..._508585e72c81d197a9a1e193c25a702a._comment |   15 +
 ..._6ca4fed183340a2902d1d4d91284b772._comment |    8 +
 ..._7c2b3d0a8a69c7056508f8ec73ebefcd._comment |   13 +
 ..._07fa468aac1288e770487973052bccea._comment |   12 +
 ..._dc0494213d2b57b5b9a489b096a5b8d0._comment |   31 +
 ..._bcac18e137c00d4279774dec51963289._comment |   10 +
 ..._76b62eafda1ecbf88abe288cbe778e17._comment |   17 +
 ..._13fe788f2e9a823ad2e4844f114675a7._comment |   10 +
 ..._f81b454e9cfc14dcb33148798be55de3._comment |   16 +
 ..._f7a1ce9627ebfc854dfde2f6c924db80._comment |    8 +
 .../local_subtree_and_broken_symlinks.mdwn    |   21 +
 ..._779cc4e49cb4da8aea7f5743e6257f21._comment |   10 +
 doc/forum/location_tracking_cleanup.mdwn      |   24 +
 ..._7d6319e8c94dfe998af9cfcbf170efb2._comment |   10 +
 ..._e7395cb6e01f42da72adf71ea3ebcde4._comment |   15 +
 ..._c15428cec90e969284a5e690fb4b2fde._comment |   10 +
 .../locks_during_--batch_operations.mdwn      |    3 +
 ..._190f6a52d9e49b2a092ad4c848e9d0b4._comment |   21 +
 ..._b19ed6657064c11bf54673f1b2ff4860._comment |   20 +
 ...long_paths_on_windows_10_-_workaround.mdwn |    9 +
 doc/forum/lost_in_walkthrough.mdwn            |   78 +
 ..._51b703b961ca762f0359e1c169f1ee75._comment |    8 +
 ..._a9de0401a103bdd4401ba2d5983dc54a._comment |   11 +
 doc/forum/lsof_resource_use_problems.mdwn     |   42 +
 ..._a5e5d410545fa7f93f08936ec6aeee42._comment |   10 +
 ..._7b0d4109c04c47e65420105f0de3b7a2._comment |    8 +
 doc/forum/luks_encrypted_disk_support.mdwn    |    3 +
 ..._0ea476c778888f34196d9031f72b1844._comment |   10 +
 ..._0af149bfe1868dde0a132c5d835c50df._comment |    8 +
 ...sck__34___only_display__44___not_move.mdwn |    3 +
 ..._018cb2fd618a448088d9e91e4872333d._comment |   11 +
 ..._fdfd1d1ded3fb98a83f2593605250a87._comment |   22 +
 ..._369daddf95ab43f2c3d6b81c35810c19._comment |    8 +
 ...shot_backup_into_a___34__remote__34__.mdwn |   13 +
 ..._4974480f1c75152a05c2305d21ed1842._comment |   13 +
 ..._e18fba58bcd5259125e6e36194234136._comment |   10 +
 ...use_of_my_shiny_new_rsync.net_account.mdwn |   20 +
 ..._0ebe509b768d46081db2100f5b712ef7._comment |   10 +
 ..._ef63d893531d93d2eb09f48f8baff4dd._comment |   13 +
 ...n_pages_in_the_prebuilt_linux_tarball.mdwn |    1 +
 ..._a7bc2e84e6d7c0e2de5900685207af78._comment |    9 +
 ...ction_between_external_HDD_and_server.mdwn |   32 +
 ..._ba8ed548bf228a7d1c82b68283f99a5b._comment |   25 +
 doc/forum/managing_git-annex_with_java.mdwn   |   11 +
 ..._fd12f0d0727b5bdddef1d7ef6236fe57._comment |   11 +
 doc/forum/managing_multiple_repositories.mdwn |    3 +
 ...pdate_of_.git__47__annex__47__objects.mdwn |    8 +
 ..._ea6ec91150c8962e2711631f2422bf3a._comment |   10 +
 ..._a7bbf304b26650a786e358bdc01e3069._comment |   33 +
 ..._a855096b683c4c4f84e72c797e065d59._comment |   12 +
 doc/forum/many_remotes.mdwn                   |   24 +
 doc/forum/mesh_configurations.mdwn            |  181 +
 ..._dc99216ee2fc0bd3d43234915a0305ab._comment |   19 +
 ..._0712fa3d50ca6092bd7d98c945b5cc31._comment |   23 +
 ..._0d9ba4017343475a96975145c9db29c5._comment |   15 +
 ..._d228158cf00cd04dc9ef5602acebdaac._comment |   14 +
 ..._d5c8e99cadf976434460d6d0f410136e._comment |  282 +
 ..._a181fde7b7f6d0559331e1afa395ba0a._comment |   15 +
 ..._7cb33d2416289f744828d8d9d24e9ef6._comment |  117 +
 ..._6c9d499f64067ee9d3721dc763f3c425._comment |  123 +
 ..._a2b5da1ea55a222dd30f0e982d5ee807._comment |  197 +
 ..._ac3e1faaefaed222f725345ab4b5f01a._comment |   89 +
 ...messed_up_annex_by_using_git_checkout.mdwn |   40 +
 ..._04f33895f6451690372595c576be2811._comment |   11 +
 doc/forum/metadata_limits.mdwn                |   10 +
 ..._a20bbe49f2f23d23131221ec79c8b973._comment |   28 +
 ..._4e8995ccd5fc2e5ee5d89a0780e5df9d._comment |   10 +
 ..._existing_git_repository_to_git-annex.mdwn |   66 +
 ..._4181bf34c71e2e8845e6e5fb55d53381._comment |   10 +
 ..._5f08da5e21c0b3b5a8d1e4408c0d6405._comment |   60 +
 ..._f483038c006cf7dcccf1014fa771744f._comment |   12 +
 ..._057f0079fbee3451ccda08026bab21d4._comment |   20 +
 .../migration_to_git-annex_and_rsync.mdwn     |   33 +
 doc/forum/misctmp_filling_up.mdwn             |   11 +
 ..._2739dec72fe0950dd070c8fab9fbd751._comment |   10 +
 ..._440081b5e2b9b5b19e8cd5db3649a976._comment |   10 +
 ..._b6ab64f02f204fc7e8741b9c04c5349d._comment |   11 +
 ...2__files__42___into_an_annex.__bummer.mdwn |    3 +
 ..._752db25abb647804a1cc12c5b247378a._comment |   10 +
 ..._db6f4959c35732f72e7a90bd9f4c665c._comment |    8 +
 ...sage_by_different_repos_on_same_drive.mdwn |    7 +
 ..._04718e5f87a7e0521a3165bc9fc951a8._comment |   12 +
 doc/forum/more_intelligent_copy_.mdwn         |   15 +
 ..._526f6a007f44f389ef7c904024752541._comment |    8 +
 ..._7b3f5d2e9de4b13de821177db2f57bcd._comment |   15 +
 ...der_git-annex_and_graft_history__63__.mdwn |   15 +
 ..._345f9a32f5fc1ea21af9fe18f902d1b0._comment |   78 +
 ..._aab850db06cbd3c33067cff567d2699e._comment |   11 +
 ..._4cff971451dd7038ffe8f7f2fa3b28c9._comment |    8 +
 ..._73e37a27ae3ff6673f34d8b1a6bed4a0._comment |   26 +
 ..._d536cb5c2622d18802e6a32b03102f14._comment |    8 +
 .../moving_annex_across_filesystems.mdwn      |   26 +
 ...inside_git_annex_assistant_repository.mdwn |   19 +
 ..._419b27cb1c71bce021ef9f2e471aa92e._comment |   10 +
 ..._dae4c7a42080dd89150159b2946839b1._comment |    8 +
 ..._9d9fa65559ba4bb0e4676289b5a65684._comment |    8 +
 ..._4e89b3590cc33b2565cd173ef7c85013._comment |   11 +
 .../multiple_repositories_single_backup.mdwn  |    6 +
 ..._4a479fa78e0b366fcff1a27bc37081de._comment |   12 +
 ..._bbe19eec0969385a0d4682bf9e9de21a._comment |   11 +
 ..._1b18ea058e3eb34852055cffe51de176._comment |    8 +
 .../multiple_routes_to_same_repository.mdwn   |    2 +
 ..._26c1734d41d5374f18fc688d862d6b8e._comment |    8 +
 ..._d119ab485fb2d5512c15372efdb2327d._comment |    8 +
 ...___40__for_tagging_photos__41____63__.mdwn |   11 +
 ..._96beb9ea895c80285748adb940b4f57d._comment |    9 +
 ..._985065c1feed9300631dac7a2701f669._comment |    8 +
 .../multiple_urls_for_the_same_UUID.mdwn      |   26 +
 ..._de7410d8824a864c4d106c9f1afaec3f._comment |    8 +
 ..._309a86cf7e08448be64357a30d8b56ae._comment |   13 +
 ..._fa97a45fc1392935fd5e0714db999bc2._comment |   14 +
 ..._139178b1ba45b62eec0c89a660c0c81e._comment |    8 +
 ..._7237986a34228282c6b764309afc1d57._comment |   33 +
 ..._392819ba657569a1b997b58aa921a0ad._comment |   25 +
 ..._276cb5d94cbd10e9fc7d1cf4ac607273._comment |   27 +
 ..._c44144c677d54aaea6e900d0d7e000a3._comment |    8 +
 ..._38f3007635b0a7b7d30bad0af8a2d0a9._comment |   13 +
 ..._a_tree_that_contains_git_repos__63__.mdwn |    7 +
 ..._ac45ad341f026289ce56183b9ff463af._comment |   10 +
 ..._53e0ffe901a1a1c22361bfd7cf71affd._comment |    8 +
 ..._f7416c26daca543ad08c11e187e1589e._comment |   37 +
 ..._9c6386710387f7334ea44c1de7cc8729._comment |   13 +
 doc/forum/name_resolution_of_dne.mdwn         |   31 +
 ..._7309e109d1f6eba8fc92659372d64b19._comment |    9 +
 ..._54ed13db673cff7177cd371143a295b4._comment |    9 +
 doc/forum/named_pipes_as_arguments.mdwn       |    1 +
 ..._0fff7a842609af3531d151425a94df0a._comment |   16 +
 doc/forum/new_linux_arm_tarball_build.mdwn    |   12 +
 ..._5f9735ec62478c99b8c814055206cff0._comment |   12 +
 ..._859c44046b00fe885f6878cfe0e46360._comment |   10 +
 ..._35ade68d62e95036344ad33db3279c21._comment |    8 +
 ..._36f48c30894b9b225b812ba5e5b2f504._comment |   17 +
 ..._67021b6d239690c9d18e8630aa2254ff._comment |    9 +
 ..._646a19555f982fb7ab302289400adc3d._comment |   16 +
 ..._442015225a14f60064aa3ba3cfbdf2ae._comment |    9 +
 ..._653448e38c3bb71a97023cb5d6b21af6._comment |   16 +
 ..._0a76ce3895ba9598bd79625268d95ef4._comment |    8 +
 ..._7211ddc626bae97d4140c723c3cf028f._comment |    8 +
 ..._fcbe3f7fa9d012b21c7a771553fa9142._comment |    8 +
 ..._2702cdbae4179a7a103d2a7098a8ed5e._comment |   34 +
 ..._e1d802fbcc9d699ece5267e80990255a._comment |   10 +
 ..._257b91ecbf5a6040a8e4c9a360c775ba._comment |    9 +
 ..._bd8cca86a63be7e330111618c1959a74._comment |    8 +
 ..._6814bdeca94328fe6c3f407795ff923a._comment |   10 +
 ..._6db99d998ca990494c8f2826ff1ca273._comment |   11 +
 ..._2802b24ccb24f1615c9d61904f916d05._comment |   12 +
 doc/forum/new_microfeatures.mdwn              |   59 +
 ..._058bd517c6fffaf3446b1f5d5be63623._comment |    8 +
 ..._41ad904c68e89c85e1fc49c9e9106969._comment |    8 +
 ..._a1a9347b5bc517f2a89a8b292c3f8517._comment |   15 +
 ..._5a6786dc52382fff5cc42fdb05770196._comment |   18 +
 ..._3c627d275586ff499d928a8f8136babf._comment |    8 +
 ..._31ea08c008500560c0b96c6601bc6362._comment |    8 +
 ..._94045b9078b1fff877933b012d1b49e2._comment |   10 +
 .../nntp__47__usenet_special_remote.mdwn      |   18 +
 ..._171a0b95b1f95cfd82073e88bdefaab9._comment |   10 +
 ..._48736ed17c98ffcfb13ec00b901b2dd6._comment |   13 +
 doc/forum/non-bare_repo_on_cloud_remote.mdwn  |    6 +
 ..._da0c023af7c78f1ef1cfe1143a900a9f._comment |   12 +
 ..._71baea93f6caaf7b81a9ac00bee91e5e._comment |   67 +
 ...ast_forward_error_with_git_annex_sync.mdwn |   34 +
 ..._48d66e5314de5b6a26f78622a4e93ba6._comment |    9 +
 ..._f7101a8e84bbbfb2fbea6c65ca62fdb9._comment |    9 +
 ..._bbb3a5572fa2427d9bf859ae1ba68764._comment |    9 +
 .../noob_question._VPS_web_assistant.mdwn     |    7 +
 ..._49f349192d64048753bedcf10ee22355._comment |   11 +
 ...not_finding_git-annex-shell_on_remote.mdwn |   21 +
 ..._84881cad02c251a2515cec50fc22bf16._comment |   16 +
 ..._f32412f8d3b84cd5cb3c4d5d6bb60f32._comment |   36 +
 ..._dfbf7f41dd4d17f2ce8b67daa9dcd11d._comment |    8 +
 ..._71ae60efcacdba5e11548923b2c85b95._comment |   10 +
 doc/forum/not_getting_file_contents.mdwn      |    1 +
 ..._4a0f7f4de9c9bc4d13db033cb75d20af._comment |   10 +
 ..._dc7403e1b551552f9fd00da6a1453570._comment |    8 +
 ...t_and_notify-finish_for_the_assistant.mdwn |    5 +
 ..._d3da4ce5cfea6c0a3277e83e0181102d._comment |   11 +
 ..._01dfd865c469a5bc465f73347a65ce44._comment |    8 +
 doc/forum/offsite_repo.mdwn                   |    8 +
 ..._1f3ab9a39baa16e3e307b23fd1aabeb8._comment |   10 +
 ..._d4ecd0dc29597e3e0988e06ee9c4d245._comment |    8 +
 ..._4b233762116c52bd2a754f49152201b7._comment |   29 +
 ..._2e3dfd605df004330396040737a7c5ee._comment |   10 +
 ..._59a7718fde634c96dd781ed5fca1f61a._comment |    9 +
 ...ked_annex_files_that_go_against_large.mdwn |   69 +
 ..._9e4604f3c7ca9be1fe6a7020fee2fd96._comment |    8 +
 ..._9bd32b89d0521fd1bec94683dffb4ecd._comment |   13 +
 ..._3c3c4b9ee0a99f0638717922785de675._comment |   29 +
 ..._8d1ba01f4e25606b960023eab38ec483._comment |   10 +
 ..._789e8ada06063f6a1c6d6358180dc202._comment |   10 +
 .../one_annex_versus_many_annexes__63__.mdwn  |   10 +
 doc/forum/one_or_many_annexes__63__.mdwn      |    7 +
 ..._656d96011801d67a45b0b3bb3d70fa63._comment |    8 +
 ...keep_current_version_of_files_in_repo.mdwn |   23 +
 ..._dd03f7cd46a8c12a34e2b1cf78e7a057._comment |    8 +
 ..._b45120f0a11428b75c099ca3d85d9016._comment |   31 +
 doc/forum/optimising_lookupkey.mdwn           |   13 +
 ..._e06db4754805c1e0ee298ecc676427d2._comment |   18 +
 ..._7dbfa3da6ae72a1f0669396664dd0c1a._comment |   11 +
 ..._2c895e4494cddab70ba761c6c48e7cf8._comment |   11 +
 doc/forum/original_filename_on_s3.mdwn        |    5 +
 ..._870f3f01f95b5878d483ffedd2ae2698._comment |    7 +
 ..._2a0d5d77219ae2410090eb1811ee1fec._comment |   13 +
 ..._0aea0eef336dd648013a9cf7789fc445._comment |   10 +
 ..._createDirectory__58___already_exists.mdwn |   38 +
 ..._6fb34a361417e4cac08edc20fd2bc3e7._comment |   12 +
 ..._0a9372f3dba83b6cee3a33933bf2b006._comment |   14 +
 .../overmounting_repository_at_home.mdwn      |   12 +
 ..._399ac5014c489698e1e45deec4db7311._comment |   10 +
 ..._d006d89ba204568cdee0731b6251ec1a._comment |   11 +
 ..._3734b50c37cbec675813cbeca7bf4ce9._comment |    8 +
 ...e_files_with_export_to_special_remote.mdwn |   10 +
 ..._8091fc1d63ad0a96e086c91a26e2af70._comment |   10 +
 doc/forum/partial_annex_repository.mdwn       |   14 +
 ..._5e594914724a04e21087e1e4e57c2d30._comment |   14 +
 ..._e6a9584bacc3ec98c4757c82a195b414._comment |   15 +
 ...artial_synchronisation._android_phone.mdwn |    7 +
 ..._2a48569277945a9c334bdfc51f8fd01f._comment |    8 +
 ..._550ae91c8a1fe060368c4682d37514b6._comment |    8 +
 ...ce_with_parallel_git-annex_operations.mdwn |    1 +
 ..._5f3b51692797f56656f313e8455c1b5f._comment |    9 +
 ...nce_and_multiple_replication_problems.mdwn |   17 +
 ..._a2cdf1a4840f099f6bc941fd8de966c7._comment |   16 +
 ..._e65b360706c66ede6e0e841b2ebbbfbc._comment |    8 +
 ..._ad7cb4c510e2ab26959ea7cb40a43fef._comment |   14 +
 ..._23a6dc7ea569944ca55bd21851dd770d._comment |   14 +
 ..._8df6cc8b72e0e78c7380f7d471124498._comment |   12 +
 .../performance_for_FTP_site_mirroring.mdwn   |   23 +
 ..._7648fced001ce1c34726e913e06273e9._comment |   32 +
 ..._fa2b7400c85356d4de6da8459a5c3b50._comment |    7 +
 ..._cb4d7b283f20b43283036f20ebc648ec._comment |    7 +
 ...it_on_ssd__44___annex_on_spindle_disk.mdwn |   12 +
 ..._b3f22f9be02bc4f2d5a121db3d753ff5._comment |    8 +
 ..._f94abce32ef818176b42a3cc860691ae._comment |   20 +
 ..._0c8e77fe248e00bd990d568623e5a5c9._comment |   10 +
 ..._4b7e8f9521d61900d9ad418e74808ffb._comment |    8 +
 ..._7abbbe7db3988a2d239d11b0a4c597e7._comment |   10 +
 ..._46bd45fdc25d9c583f4ebe3a9730ab9f._comment |    8 +
 ..._log_file_after_upgrade_to_5.20140517.mdwn |   13 +
 ..._807d7da99f732f2fa5f9d3cb1ba9f1a1._comment |    8 +
 ..._92a7509fc42ab2347d57f080081d14b5._comment |    8 +
 doc/forum/possible_gpg_issue.mdwn             |   28 +
 ..._c5a33ff375cddd001e6cb7be8d0ce940._comment |    8 +
 ..._e5ea7fc9be496f71516a238522193744._comment |    8 +
 ..._d505b6e5050d2afa7c8543e21918193d._comment |   31 +
 ..._e52099d461d0df99040f664a3af23caf._comment |   17 +
 ..._a0c8afc2d8583d30073b62396b254a6e._comment |   17 +
 ..._2a0120d6b586594cfd9baabbd6605373._comment |   15 +
 ..._f095eadcd9f6947f64e6830acea8228e._comment |   11 +
 doc/forum/post-copy__47__sync_hook.mdwn       |   14 +
 ..._c8322d4b9bbf5eac80b48c312a42fbcf._comment |   11 +
 ...to_use_git_annex_for_only_large_files.mdwn |   55 +
 ..._01db183b1f1d081066d88332e2b6166a._comment |   15 +
 ..._2b76809869e0289f78f137afbdcf36c8._comment |    8 +
 doc/forum/preferred_content.mdwn              |   11 +
 ..._9c9e5f2ee5ae4d8459358ad16f879ef1._comment |   10 +
 .../preferred_content_globs_question.mdwn     |    1 +
 ..._de4212f2e70fde49063b45b33498ade7._comment |    7 +
 ...ontent_settings_for_multiple_symlinks.mdwn |    7 +
 ..._70da012d96ab576151fe3e081ef905d1._comment |   10 +
 ..._ccea74d8b5a4de1f3cd1f6da6694ae0e._comment |    8 +
 ..._fab70c642d5aaf26de05270860281030._comment |   10 +
 ..._3cbd06de53b6a13e2741124a8e7b5b5b._comment |   10 +
 ..._963558ab261d8a6315402d371e8348f9._comment |   10 +
 ..._23279af1d49d22e880d078c59f58c492._comment |    7 +
 ..._73bf2c6dfa71cdb10b36c5cda2d2dc11._comment |    8 +
 .../problem_with_non-ascii_filenames.mdwn     |    5 +
 ..._ad7e7d7ef4b25ef59f93246dab0e3048._comment |    9 +
 doc/forum/public-web-frontend.mdwn            |   16 +
 ..._c73bd2dfe020c25eaad1c0707dd2db01._comment |    9 +
 ..._0026d7be6b17e50d86b3b54985882f80._comment |   14 +
 ..._only_annex_without_location_tracking.mdwn |    7 +
 ..._47262f048a87fd6b781090f880a9bf99._comment |   12 +
 ..._ec3ff6487c9e5c89c7e508d72518bd50._comment |   10 +
 doc/forum/pulling_from_encrypted_remote.mdwn  |   12 +
 ..._e9d6a9a6e01d01edb41a11b0da11d74d._comment |   10 +
 ..._8d0db2ff65ce935c6e68044a3e0721a8._comment |   16 +
 doc/forum/pure_git-annex_only_workflow.mdwn   |   46 +
 ..._683768c9826b0bf0f267e8734b9eb872._comment |    8 +
 ..._6b541ed834ef45606f3b98779a25a148._comment |   30 +
 ..._ca8ca35d6cd4a9f94568536736c12adc._comment |   10 +
 ..._00c82d320c7b4bb51078beba17e14dc8._comment |    8 +
 ..._b63568b327215ef8f646a39d760fdfc0._comment |   32 +
 ..._cb7c856d8141b2de3cc95874753f1ee5._comment |   12 +
 ..._a32f7efd18d174845099a4ed59e6feae._comment |   32 +
 ..._66dc9b65523a9912411db03c039ba848._comment |   15 +
 ..._9b7d89da52f7ebb7801f9ec8545c3aba._comment |   12 +
 ..._dc8a3f75533906ad3756fcc47f7e96bb._comment |   20 +
 ..._afe5035a6b35ed2c7e193fb69cc182e2._comment |   24 +
 ..._3660d45c5656f68924acbd23790024ee._comment |   12 +
 ..._33db51096f568c65b22b4be0b5538c0d._comment |   15 +
 ..._6e5b42fdb7801daadc0b3046cbc3d51e._comment |   12 +
 ..._ace319652f9c7546883b5152ddc82591._comment |   14 +
 doc/forum/purge_files_with_no_copies.mdwn     |    3 +
 ..._12b578689eb8d5d38c06261ec65e2109._comment |   12 +
 doc/forum/pushing_to_android.mdwn             |    1 +
 ..._1a7f6d21a3eef88d20d6f2bbad4c39d5._comment |   19 +
 ...out_assistant_and___47__archive__47__.mdwn |   22 +
 ..._97890e26072af9277144651e3fdcada0._comment |   10 +
 ..._542bf265e35a976ac76767762d67d617._comment |  104 +
 ..._bafe99159df2adcd5fecc0d67bbf05a5._comment |    8 +
 ..._e77fa2992d9302a49a05f514c81612ca._comment |   10 +
 .../race_condition_with_drop_-J__63__.mdwn    |    7 +
 ..._0607c11410d99a6933e02c28b54c1f65._comment |   12 +
 doc/forum/read_directly_from_annex.mdwn       |    1 +
 ..._d8c4a60a672e60f89d6e57e515ef86cd._comment |   20 +
 ...ld_location_log_from_encrypted_remote.mdwn |   35 +
 ..._f84f955fed7b96ae6208b6ff2ec650cd._comment |   12 +
 ..._c0b2ce3bc7cd55a0c77ddc31493068c2._comment |   10 +
 ..._06a73ca3dc73399ff000b642cca72de7._comment |   10 +
 ...ndirect_renames_on_direct_repo___63__.mdwn |  254 +
 ..._f4b0a14373c75cb752597c832e296bcc._comment |   17 +
 ..._8c86dfc99f0b9040402c9d746decda53._comment |   41 +
 ..._0246fff6c7c75f6be45bd257ec3872a5._comment |   75 +
 doc/forum/recover_deleted_files___63__.mdwn   |   66 +
 ..._d7abb7c45c6ec2723a04f153ed215453._comment |    8 +
 ..._8ea2acaa30d3ee7e9f75310f4ec859b2._comment |    8 +
 ..._376de81c70799bf409be189a48234815._comment |   12 +
 ..._2e73ac530d65a01768a57058b7220a29._comment |    8 +
 .../recovering_from_repo_corruption.mdwn      |   11 +
 ..._01fc85037e24fc70e5c5329898cf6781._comment |   15 +
 ..._3bd1c0bf25a0e892e711a60f53cd5298._comment |    8 +
 ..._679dde8ca0081fc6854d6d2e8a42abdb._comment |    8 +
 doc/forum/recovery_from_failed_merge.mdwn     |    7 +
 ..._84e5b55d473d16bc9bdba5d88dc29bc3._comment |   10 +
 doc/forum/reflog_of_pruned_commits.mdwn       |   27 +
 ..._edb31e8722edc58be7e2593556dc3ddf._comment |    8 +
 ..._cd0f057a730389509bd12dcaf21e3150._comment |    9 +
 ...annex_receives_from_more_than_one_src.mdwn |   12 +
 ..._c805561fa714ff3930742bb330b340c9._comment |   20 +
 ...annex__44___does_not_recognize_remote.mdwn |    8 +
 ..._c1962d757dd22f49e774afa13a9862ca._comment |   10 +
 ..._1f0f4a1dc89643cee81ff7199b55e747._comment |    8 +
 ...ion_for_macOS_called_git-annex-turtle.mdwn |   12 +
 ..._58f236c940ca20bfbae53324a530da0d._comment |   22 +
 ..._54ba7672150ee32df4d2d92390a960c1._comment |   21 +
 ..._107d0a3c9de6880d0ee164a651d2c20e._comment |   10 +
 ..._ddb6d671ddd28ba79efce74e41eab7e1._comment |   10 +
 ..._d496549c4f8bf3500e8ac5c2f2ae0d6e._comment |   12 +
 ..._8b3555fe33da55c01b199efd492951b0._comment |   37 +
 ...ity__47__completeness_of_XMPP_updates.mdwn |    7 +
 ..._e0f7aa48d54fc0564f41c3a569c723b7._comment |   12 +
 ..._4e74039a673c16c0163f2cfb406dc4c3._comment |    8 +
 ..._41ade4fe72804b2f06cd4dbf405c1746._comment |    8 +
 doc/forum/relying_on_git_for_numcopies.mdwn   |   47 +
 ..._8ad3cccd7f66f6423341d71241ba89fc._comment |   36 +
 ..._be6acbc26008a9cb54e7b8f498f2c2a2._comment |   18 +
 ..._43d8e1513eb9947f8a503f094c03f307._comment |    8 +
 doc/forum/remembering_state.mdwn              |    5 +
 ..._4a6ac5f50dfa5a17a0f0ccd0c2e7a466._comment |    8 +
 ..._1b02d3713a2986bc027d166589a11c3f._comment |    9 +
 ..._b48775ea1e90b061b084f61a4a9baca5._comment |   19 +
 ..._cbebcc6ed4bdae6815c0576475e96f6a._comment |    8 +
 doc/forum/remote-specific_meta-data.mdwn      |    5 +
 ..._179ec4787d93ca4710c5bd448754d404._comment |    8 +
 ..._51347629414ac42a6709d00d38ebef9c._comment |    9 +
 ..._repo_is_invisible_due_to_+__47__.git.mdwn |   19 +
 ..._8333d1f8d773cd114aee8899d51b8fa1._comment |   12 +
 ..._174f467144d1977c6bc313f6461fc5c6._comment |   13 +
 ..._cea5b2a55fd82e4e42ad045d1bdda0a0._comment |   13 +
 ..._5bd942d53cf0a4978883eed1b61cfe91._comment |   25 +
 ..._6863faa0a64ff72abcf82435bfabf7b0._comment |   10 +
 ..._df69e9d176b14c687098d52dbe3cacd3._comment |    9 +
 ...ent_repositories_are_bare__33____63__.mdwn |   17 +
 ..._234241460f6c75a8376b303b8dd4e882._comment |   11 +
 ..._42dfc382d07af2a4f29c76016084f87c._comment |   12 +
 ..._32bf10cf837db16566dcc99d0b9aaf67._comment |   10 +
 ..._cd04cfaf97f200d5e581b83bb8d018b2._comment |   26 +
 ..._information_from_special_remote_file.mdwn |    8 +
 ..._a3c41731dbbcd53715c205e29ab99e4e._comment |   17 +
 ...ing_remote.log_information_completely.mdwn |    9 +
 ..._033f5b8f2b306c756b3f12e0a9bc6637._comment |   14 +
 ...aming_directories_not_supported__63__.mdwn |   45 +
 ..._94bb80e70fe619c6f1913b4a233e47ec._comment |   15 +
 ..._4bd6386dbd5cb907a9c85fb240265ee5._comment |    8 +
 .../repair_stuck_on_ls-tree_command.mdwn      |   54 +
 ..._791c50f8a2284b704e34cacf15637341._comment |   14 +
 ..._1d951126a9633b206dffbc77bfc65f6a._comment |   12 +
 ..._1a844376915c6a40ad03c2b9b599367b._comment |   10 +
 ..._9555c925516ce3be83b4dd17d587100f._comment |   37 +
 ..._17327b90d09f8dd0bf7f359c16cf69dd._comment |   21 +
 ..._2ae0c755f5a0bf5c93afe5e081fcb915._comment |   19 +
 ..._875f9e36a94264a92eb097e9f4bda444._comment |   20 +
 ..._d5c29dc4ea49542f7053bf2e83e0f07f._comment |   17 +
 ..._061770159851c0f06a962937dff035b9._comment |   30 +
 ..._5d9e5fd148d5f9e918ad818e07009d69._comment |   30 +
 ..._726c9a887b7df1833d7aef3bdce50517._comment |    7 +
 ..._163cdd18380a13aaa13d68d516af1e30._comment |    7 +
 ...a_locked_file_without_unlocking_first.mdwn |    1 +
 ..._637598d027bc6194dad89d63aea511d4._comment |    8 +
 ..._b3ee1b086bf0add1e5f286635c02959a._comment |   10 +
 ..._ed4137413812467d67dd84aa5fde6263._comment |   16 +
 ..._8aa708a1bf76e452ef12c35999774791._comment |    8 +
 ...eplacing_a_union_mount_with_git-annex.mdwn |   18 +
 ..._b627a4028d98f1a137c4af85918f49c0._comment |   10 +
 ...repo_corruption_in_usb_external_drive.mdwn |   41 +
 ..._d9122bb0cc3551d92877c299a25b9c9e._comment |   10 +
 ..._fails_to_show_files_in_one_direction.mdwn |    7 +
 ..._412c319a1610b447fcf372584c2bb15c._comment |   49 +
 ..._c10d614039b82c5be289e8e34bc70f86._comment |   17 +
 ..._4fec14b132bea863b58aa07e03fc31cc._comment |   11 +
 ..._space_with_directory_special_remotes.mdwn |    2 +
 ..._cd17b624704d93b51931023f69573323._comment |    8 +
 ..._877ca1be23d1484a8a30cdaeb6630053._comment |   15 +
 ..._65910eeaf3c6fcfd03f22c2957293232._comment |    8 +
 doc/forum/retrieving_previous_versions.mdwn   |    7 +
 ..._a4e83f688d4ec9177e7bf520f12ed26d._comment |   11 +
 ..._e9251f66154e49a77be661c4b4918e18._comment |   16 +
 ..._5b0ca6fbc000727bf78f5fc4ba34b91a._comment |    9 +
 doc/forum/root_assistant__63__.mdwn           |    3 +
 ..._fccab2e36d393f420d0fa23958e6a9d2._comment |   15 +
 ...es_for___42____42____42____42____42__.mdwn |   13 +
 ..._7754e2cfb72b034effe8642c1b3e593e._comment |   11 +
 ..._04e1da4352ef9f9be90253ea726e5f24._comment |   12 +
 ..._84aceb9a9d3e5bd14c044861f47e3b9d._comment |   10 +
 ..._2cd17d01edeb230197865e6ea0884de0._comment |    8 +
 .../rsync_asking_for_an_unknown_password.mdwn |   60 +
 ..._f23d1c04a27625089eaef5b4bb7f8456._comment |   12 +
 ..._ce4b399fdb2f04e30bd8a951994f1c80._comment |   10 +
 ...annex_without_overwriting_links__63__.mdwn |   13 +
 ..._baa5351a0653838cfbf5f194f6252bcc._comment |   23 +
 ..._598cc6e65f57e941be1319255e66a55f._comment |   11 +
 ..._d765f93511e0ba446f54f3ad30e91e6f._comment |   30 +
 ..._62cf96d62228b52bf7dd52eab0b94f67._comment |   22 +
 ..._40e4e9fe7d301b5e75140136d0132860._comment |   26 +
 doc/forum/rsync_over_ssh__63__.mdwn           |    2 +
 ..._ee21f32e90303e20339e0a568321bbbe._comment |    8 +
 ..._aa690da6ecfb2b30fc5080ad76dc77b1._comment |    8 +
 ...protocol_mismatch_due_to_encfs_folder.mdwn |   24 +
 doc/forum/rsync_regression_on_Windows.mdwn    |   16 +
 ..._0e713f8949a3e5a949489fc89c0b9078._comment |    7 +
 ..._2e340c5a6473f165dc06cc35db38e5c0._comment |    8 +
 doc/forum/rsync_test_remote_fail.mdwn         |   84 +
 ..._deffffd5112a60ad7837479da045d39f._comment |    8 +
 ..._824e45450cc01b30144ac5f8265b930e._comment |    8 +
 ..._0b910e98485832dd7f305decdc39fa7f._comment |    9 +
 ...rsyncing_.git__47__annex__47__objects.mdwn |   24 +
 ..._25eb9f7be5730337b9efd96dce9efd2e._comment |   10 +
 ..._d7ceae666c8a1951021d3c6e6ac39a11._comment |    8 +
 ...andwidth_limitations_and_next_release.mdwn |    7 +
 ..._6fba752ada4ca86c96a026a4d09ef16b._comment |   11 +
 doc/forum/s3_server_side_encryption.mdwn      |    9 +
 ..._68345d01b016abf96c226d2bfa17c641._comment |   16 +
 ..._b2ccef6dc00d58e103ac0fda48ee94d3._comment |   10 +
 ..._3eb57b98e4136b8550ea5d19393fe967._comment |   12 +
 ..._71d6c2356af8974cb848c3574cf3eb6d._comment |    8 +
 doc/forum/s3_vs_ssh_Performance_Problems.mdwn |    8 +
 ..._65f064f09d7850abecab97007b0d30f0._comment |   12 +
 ..._baaf2384d9196077268e9ca9bbe3b871._comment |    8 +
 ..._dc44be42070c073d150c476406e9b425._comment |   10 +
 ..._f9c3ef3b1b44bfb29125acb6ec621f38._comment |   10 +
 .../safely_dropping_git-annex_history.mdwn    |   20 +
 ..._a4b93a3fbc98d9b86e942f95e0039862._comment |    8 +
 ..._383882fafd32f25ed22b5eb2fb3691b9._comment |   18 +
 ..._47794a2abf29bf4ea2763ff89d872ab4._comment |    8 +
 ..._b7b920862fc82eaa5d7deae34b4aebc4._comment |   12 +
 ..._979bbccf31dbee1707d403957bde3493._comment |   16 +
 ..._4fd76d10a93fe01588fce7a621f9254d._comment |   12 +
 ..._10ecf3220ffcbbe94ba09da225458f18._comment |   12 +
 ..._e3beb8acb075faaeef6c052aecbf0a41._comment |   50 +
 ..._61a5fe2e7e47c60a8b237ea69404a37f._comment |    8 +
 ..._426d02e2f2a2ae4ec7eae02dfe4519b3._comment |    9 +
 ..._410a7296c2cee16d3d5bb618a5a41c1d._comment |   10 +
 ..._42cf492fc98a9eba8176387749ef12e0._comment |    8 +
 ..._c0327ada073d8b69535f71b4dc6aa57e._comment |   21 +
 ..._f83d6090aea2b7d5d54c876df940cbad._comment |   40 +
 doc/forum/scalability_with_lots_of_files.mdwn |   43 +
 ..._b9bb0a71d81b8cbc2a751bb7bab84812._comment |   18 +
 ...ule_repository___91__expression__93__.mdwn |    1 +
 ..._b123b657a92897017973927e3e47673b._comment |   12 +
 ...__files_for_files_not_in_local_remote.mdwn |    8 +
 ..._76453756be78f06ef3a3d7d1bf011b9f._comment |   11 +
 ...ty_risk_presented_by_remote.log__63__.mdwn |    5 +
 ..._9715488033f2a8939a32ed12259377ba._comment |    9 +
 ..._40383346237de0bae4760dc85fefc348._comment |   15 +
 ..._b1ddf06b34f750e9bbd88e6d5348e765._comment |   29 +
 ..._428bbced6406a35eb093a27e35831f38._comment |    7 +
 ..._df1eab397c8e08698064391438bbff1b._comment |    9 +
 ..._6a3911dc346d506d4350b5aec7619462._comment |   21 +
 ...o_build_fine_on_haskell_platform_2011.mdwn |    1 +
 ..._multiple_repositories_on_one_machine.mdwn |   28 +
 ..._1606849eb13b6069394455297395dc30._comment |   15 +
 ..._f60c43ec9d493db03e2a5a5595501e55._comment |   11 +
 ..._b041da6694d9d9d21a67f7bbdda0f62e._comment |   20 +
 doc/forum/shared_cipher_tries_to_use_gpg.mdwn |   10 +
 ..._760961eaaa7d5c254dd71c5792437c9e._comment |   12 +
 ..._f3260aea3a5bb9b95a9bdf1d0dfce090._comment |    8 +
 ...efspec_notation_for_git_annex_unused_.mdwn |   22 +
 ..._0aeb5702e74fcf158f1e9aca16ca9e6b._comment |   19 +
 doc/forum/slow_ikiwiki_server__63__.mdwn      |    1 +
 ..._f734812a94c0f6c7612257f82e0c4b36._comment |   14 +
 ..._1eb8334b06b784211eb93405dbf93a77._comment |    8 +
 ..._d73e4ff5f273160a3df5590ebafd440c._comment |   11 +
 doc/forum/slow_s3_transfer.mdwn               |   20 +
 ..._a6e3f8579447d85c22f3bb99c4e6cf0d._comment |   11 +
 ..._f66a8d597de5065049a9a9b245166540._comment |   15 +
 ...directory__34___special_remote_on_fat.mdwn |   26 +
 ..._a6f0ae755b9e24fd0de5868b57c6a497._comment |   13 +
 ..._9fe4a596aea6bd1a898b4c235126dce2._comment |   14 +
 ..._02eae41ba9ad2f2fb15cbd20069bf1da._comment |   11 +
 .../some_symlinks_left_in_direct_mode.mdwn    |    5 +
 ..._fd8d8107861453f0aa6b2c390e369307._comment |   17 +
 ..._63f61caf28e834d48e12467bf09b2e3d._comment |    9 +
 ..._really_good_happened_with_3.20130124.mdwn |    5 +
 ..._1712bddd2f483a353f6313aa626445f1._comment |    8 +
 .../sparse_git_checkouts_with_annex.mdwn      |   31 +
 ..._c7dc199c5740a0e7ba606dfb5e3e579a._comment |   12 +
 ..._e357db3ccc4079f07a291843975535eb._comment |    8 +
 ..._fcfafca994194d57dccf5319c7c9e646._comment |    8 +
 ..._04dc14880f31eee2b6d767d4d4258c5a._comment |   20 +
 doc/forum/special_remote_for_IMAP.mdwn        |   44 +
 ..._7c7d4b57a1b6508fff1a6b0508c861f8._comment |   10 +
 ..._9c46fe8a857aa7a5ce797288144386bd._comment |    8 +
 ..._27e3b644df6942ce4c103236d0d5cb1b._comment |   23 +
 ..._0f8e01c453afb02aebf44b3fb2c9a7c1._comment |    8 +
 doc/forum/special_remote_for_iPods.mdwn       |    5 +
 ..._37cc3dc740341cc663074fd3bfb85947._comment |    8 +
 ...lies_a_lossless_operation_in__47__out.mdwn |    9 +
 ..._195f52aaaa36ce20955f2eb40af3c79a._comment |   11 +
 ...sistant_startup_on_large_repositories.mdwn |    1 +
 ..._5ba637a0f6d01ba24fe25e6265134e0a._comment |   10 +
 ..._d65746697977f8971a4b59f5b413f926._comment |   13 +
 ..._be6c4fe5a0c745688438b716973791cc._comment |   12 +
 ..._a07472338a08c068a9b88b2176fc2bee._comment |    9 +
 ...__read__58___Connection_reset_by_peer.mdwn |   28 +
 ..._87b9540e37abb16c0ec7605f5ab204a5._comment |    8 +
 ..._bd3383c142bf93d9cd496cb668d7782c._comment |   12 +
 ..._9b1911ae6468d09dae74ab1a60d2757b._comment |   12 +
 doc/forum/ssh_key_setup_woes_in_Android.mdwn  |   15 +
 ..._f16fbff27a449409699f3dbcf9590622._comment |   10 +
 doc/forum/ssh_password.mdwn                   |    3 +
 ..._a3e5a41e1d4da683d577976b134b11ee._comment |   10 +
 ..._fa261676a99d49d4b237b0d43048d76d._comment |   10 +
 ...itory__34___option_during_setup__63__.mdwn |    3 +
 ..._7244794579a191a677190c60758f32e7._comment |    8 +
 ..._277cf12907bd7c5930eb4f137b115e29._comment |    8 +
 doc/forum/ssh_vs_cifs__47__webdav.mdwn        |    7 +
 doc/forum/ssl_errors_with_special_remote.mdwn |    7 +
 ..._a3d68cc1af06c54d29818644a9943cc4._comment |    9 +
 ..._6ef51ec4daa0c4d3abae22dafe6f068b._comment |    9 +
 ..._d0e4921bd6d71c7b43418722008d2c22._comment |   10 +
 ...dalone_tarballs_for_specific_versions.mdwn |    2 +
 ..._3c41c48d40ae44129a80f2d2bef284ae._comment |   12 +
 ..._543bb94e6a6c1313a09328402a191995._comment |    8 +
 ..._b187721c1480debba3d391c965d17800._comment |    9 +
 ..._121ae7a2803975e3bdcb5f9df0c4af3f._comment |   12 +
 ..._5183f3d940ef116b07f88bac25cb97a8._comment |    8 +
 ..._b822c789e2736caa2c7bce27e619c463._comment |    8 +
 ..._33af5c294ccdff942f078ff366470342._comment |    8 +
 ..._a8d92991f13993d0beb72c7dd51e23a6._comment |   28 +
 ..._28f604900388b087eed76e7c03b8945b._comment |   28 +
 ..._00592c4cdcd7c3f63d5eacd16abdc88b._comment |   13 +
 ..._945d08e40897ee964be5e6945ad9914a._comment |   11 +
 ..._59066dc14b5b45a3a15ee65cf6746bab._comment |   10 +
 ..._c4fcf4abe2550b677ee312c597556e66._comment |    9 +
 ..._fe5049bba125e20d766595cb30bf7ce2._comment |   10 +
 ..._23bf8b9ab7e7850d801dcaec60ccf22d._comment |   14 +
 ..._3dd596dc5f09564932dacd90fbb5be2b._comment |    8 +
 ..._dd482d39c746dd6845382e9503731b6f._comment |   20 +
 ..._7fb08748b8610ad33f800c1bd173b120._comment |    8 +
 ..._211e260fbc60dc83a8986fac4e9700b7._comment |   16 +
 ..._9002aa86c44c19f28ab74724daad5422._comment |   11 +
 ..._ea42a5cb83e9cc8e24673bb805cfd4e1._comment |    8 +
 ..._c6d2c756b51247c784786e3a02d3840a._comment |    8 +
 ..._f7de3190366e81fc898393c1ed168c56._comment |    7 +
 ..._6ac3fa868ab0dfa6cc26928098abc334._comment |   11 +
 ..._74875c799f20d051739227e2b79de18f._comment |    8 +
 ..._febd89250e37af938c723e4a204c5cef._comment |    8 +
 .../start_assistant_from_command_line.mdwn    |   11 +
 ..._f8dfce1fca9f1212ccaf84e431db71a9._comment |   12 +
 ..._e769c5d09afbff85961363ddc5eb4019._comment |   10 +
 doc/forum/status_of_v7.mdwn                   |    3 +
 ..._88d3bcb329bce6dfe33707f39b843b39._comment |   25 +
 ...nnex_in_different_place_on_hard_drive.mdwn |    2 +
 ..._a95add69028ad71f3c66b544c1a28db6._comment |   16 +
 .../support_for_git_sparse_checkout.mdwn      |    1 +
 doc/forum/switching_backends.mdwn             |   12 +
 ..._ecf4109c1148dafde3519243ae3c5a03._comment |   10 +
 ..._21f465a18f40b95dafd307fce0de659a._comment |    8 +
 ..._4c13d22c1695195e6b101bd20ef6bb42._comment |   35 +
 ..._e1d4a48baac23fd3f67b20eba4eee8af._comment |    8 +
 ...irect_mode_while_assistant_is_running.mdwn |    2 +
 ..._7832243a36613c48d0077b438dbf8b4a._comment |   10 +
 ...k_in_textfile__44___100_bytes_of_size.mdwn |    7 +
 ..._ee6ec862a391c54c8e1254891d4d477e._comment |    8 +
 ..._0748b20c8a0d7d4704003c0ecfc27716._comment |    8 +
 ...___fatal_is_outside_repository_errors.mdwn |   50 +
 ..._d4a649874ee9c9e6a4c0252700607713._comment |   12 +
 ..._668dae37dd46047b46c9e1c23f7bcec4._comment |   11 +
 ..._09c62e4abf4ccc0d2e030ef5e1bcdf71._comment |   12 +
 ..._8f694afa77f5a835c826d29d46d44615._comment |   30 +
 ..._a7f476aeacf88679f25badc78fad886a._comment |   57 +
 ..._e96503f38cba755b2e6bd89b1ffab6ff._comment |   28 +
 ..._7443fe5f7384431914c714c2b462cf5c._comment |   24 +
 ..._63225cc9557886ae12b3450f68812815._comment |    7 +
 ..._baefe35266021184ee78440226fe2a8d._comment |   25 +
 ..._a9ed50cd4a1f436822ae97bfcd1ced48._comment |    8 +
 ...ent_sometimes_iterates_over_all_files.mdwn |   35 +
 ..._a276f0f6aa87a491c2fba3d58217b75a._comment |   12 +
 ..._1f8ae9a0099d456e25f387798f99eec9._comment |    9 +
 ...sync_between_indirect_and_direct_mode.mdwn |    6 +
 ..._7efc0d79196675582571c05fdd133b53._comment |    8 +
 ..._8ac84dbaf7a4d503497487cbdb1749d8._comment |    8 +
 ..._9acb237711669ec6046a8d07f9ed3b2c._comment |    8 +
 ...ntent_through_repo_that_wants_nothing.mdwn |    7 +
 ..._6c014bc88fc8a685ef79a044c8938c7d._comment |    8 +
 ..._ef89154903395025bb0a0408e1c23bdf._comment |   13 +
 ..._e05a3e3d991617bb2b323b5572cd771e._comment |   17 +
 ...ts_after_first_non-successfull_remote.mdwn |   27 +
 ..._dbca6ea763702a82ae7563722cdc7fab._comment |   11 +
 ...nc_remote_repo_on_local_sync_upstream.mdwn |   21 +
 ..._db650b4b5764e33219cb28eba2987ea5._comment |    8 +
 .../sync_stages_deletions_on_remote.mdwn      |   72 +
 ..._2b639066095e450c2d9be3b2775d24b3._comment |    8 +
 ..._da5775526a2a476b6ead1cd1a735b8bd._comment |    8 +
 ..._9e07593228915936fadcf90373be9f4e._comment |   14 +
 ..._e5a3dc34c6229ec40bc999c3cab28041._comment |    8 +
 ..._f3350d336c6c66c3aacc7caade2ef12c._comment |   31 +
 doc/forum/syncing_home_directories.mdwn       |    7 +
 ..._220a6e0ffe0ea610921a63c0a6e3beab._comment |   16 +
 .../syncing_music_to_my_android_device.mdwn   |   17 +
 ..._81653a23424ac04675651fb7632c57ae._comment |   11 +
 ..._e49c9e5da5c5d1db228b9b753bed53ff._comment |   18 +
 .../syncing_non-git_trees_with_git-annex.mdwn |   46 +
 ..._7f9593bdfd95e4a8814e6cc5c44619e6._comment |   24 +
 ..._49f15478781a0ad5e46e75319070335c._comment |   16 +
 ..._6d8f399f0549eddd1d1f5c9c9a10c654._comment |   13 +
 ..._won__39__t_prompt_with_pinentry-gtk2.mdwn |    3 +
 ..._daf41d0e59d384dfe5c86a53600ea3f7._comment |    8 +
 doc/forum/taskwarrior.mdwn                    |   11 +
 ..._1c3a29e7d292cb602d9d349f8009b51e._comment |   10 +
 ..._4b3d70501763f6d36c927ae37bbd33c2._comment |    8 +
 doc/forum/telehash_syncing.mdwn               |   10 +
 ...ll_us_how_you__39__re_using_git-annex.mdwn |    6 +
 ..._4884803ddee7f642a3ac995a19967a6a._comment |   17 +
 ..._61f5054918e7b36c191454365bc7f3b7._comment |   10 +
 ..._db07e8703be606c998c831e91d300d69._comment |   10 +
 ..._a58595969cdd42ed20210e9615b42e42._comment |   22 +
 ..._4de0a5431431e80f4a81d87e649d4598._comment |    8 +
 doc/forum/temporary_AWS_credentials.mdwn      |    2 +
 ..._655825b3aa981e97969e226c98034c4b._comment |    7 +
 ..._d4b66fd587c3a0ce74436ec09b398f10._comment |    9 +
 ...est_whether_a_file_is_already_annexed.mdwn |    1 +
 ..._55bcb41abae2b70c046e3da1c4d8c761._comment |    8 +
 ..._e2531c7e77bbc75f24af7ce5f789826e._comment |   22 +
 ..._21f51c99b1aac8b3292f60bd83493e94._comment |   15 +
 ..._2c61629777f47ce3e697298d5736f997._comment |   22 +
 doc/forum/the___39__here__39___remote.mdwn    |    1 +
 ..._8100ed97a671afea207efe3f70230707._comment |   12 +
 doc/forum/time_profiling_the_assistant.mdwn   |   19 +
 ..._0227d9c0db24c6abadfe091f92848ec6._comment |   16 +
 ...95__remotes__47__hook_with_tahoe-lafs.mdwn |   22 +
 ..._76bb33ce45ce6a91b86454147463193b._comment |   10 +
 ..._4d9b9d47d01d606a475678f630797bf9._comment |   10 +
 ..._8a812b11fcc2dc3b6fcf01cdbbb8459d._comment |   12 +
 ..._fc98c819bc5eb4d7c9e74d87fb4f6f3b._comment |   39 +
 ..._c459fb479fe7b13eaea2377cfc1923a6._comment |    8 +
 ..._2e9da5a919bbbc27b32de3b243867d4f._comment |   23 +
 ..._d636c868524b2055ee85832527437f90._comment |   20 +
 ..._39dc449cc60a787c3bfbfaaac6f9be0c._comment |   10 +
 ..._2592749c2f02b3e151896e31acba359b._comment |    8 +
 .../transfer_bare_repo_setup_problem.mdwn     |  111 +
 ..._3b6c15b81c5df09587bc75c5e358b39c._comment |   48 +
 ..._c011e8fcda61b6ee0067020abbddf61a._comment |   18 +
 ..._with_multiple_files_as_a_single_item.mdwn |    7 +
 ..._89d2819893ae954041d65a5758993be8._comment |   11 +
 ..._6889f4695bca77c18efe0000fc491b57._comment |   11 +
 ..._61924cf10643a6d2d011899d95b4ae56._comment |   12 +
 ...tes_syncing_to_gcrypt_based_ssh_repo_.mdwn |    7 +
 ..._4ad9a6a7cf5678ac0bc6d46a54f64cd3._comment |   10 +
 ..._82dc18ed14879936d04133f248879fb9._comment |   10 +
 ...ries__58___fatal__58___not_a_git_repo.mdwn |   32 +
 ..._0a755a4a281c3bd130722093c8ddd080._comment |   10 +
 ...ssistant_sync_with_ssh_special_remote.mdwn |   32 +
 ..._d42def5dfc1cf814fdb07f7cf808bb12._comment |   24 +
 doc/forum/two_lines_back_to_remote__63__.mdwn |   10 +
 ..._064d786c5550e4470440717994e62051._comment |    8 +
 ..._b1debe6f63e811c79ad97b9e38dd2935._comment |    7 +
 ..._70ee40b99e06c4f64d3e2e4433c8b4ba._comment |   12 +
 doc/forum/ui.mdwn                             |   11 +
 ..._f3e3446b05d6b573e29e6cad300fb635._comment |   10 +
 ..._b493ee97eb2378e72c12f3d137109580._comment |   15 +
 ..._remotes_when_cloning_a_gcrypt_remote.mdwn |   28 +
 ..._cbcc4be05aa6d8f030d5ab0dc46858f4._comment |   11 +
 ..._3623a37d918d08e8681276206137f5af._comment |   19 +
 ...unable_to_clone_annex_repo_in_windows.mdwn |   29 +
 ..._588af0e0b655966c2d344f3f4b4d2e5f._comment |   18 +
 ..._e4fcc8329b2deb058b7368ce1c226a3e._comment |   11 +
 ..._20aa8de2513fdb6b19a4b24f20983f0a._comment |   12 +
 ...in_.git__47__annex__47__objects__63__.mdwn |   47 +
 ..._4aaf93801119b36a01e452c7bb0fc7e9._comment |   18 +
 doc/forum/unannex_alternatives.mdwn           |    9 +
 ..._dcd4cd41280b41512bbdffafaf307993._comment |   46 +
 ..._58a72a9fe0f58c7af0b4d7927a2dd21d._comment |   36 +
 ..._b1687fc8f9e7744327bbeb6f0635d1cd._comment |   16 +
 .../unknown_response_from_git_cat-file.mdwn   |    8 +
 ..._f26ba569e715fe69b6de3093930362ee._comment |    8 +
 ..._bba450e83609225c161b4fec1e006f8a._comment |    8 +
 ..._8e0458e86764242e9e35940b4db302b7._comment |   32 +
 ..._275fcf1e6643cb247f8ed5afc4c69e56._comment |   15 +
 .../unlock__47__lock_always_gets_me.mdwn      |   11 +
 ..._dee73a7ea3e1a5154601adb59782831f._comment |   12 +
 ..._f89b4349dde840c355a3bc28908decdf._comment |    8 +
 ..._acbab7b75726d34dccb5c9dab7b3e728._comment |    8 +
 doc/forum/unrelated_repositories_sync.mdwn    |   15 +
 ..._c899b7b05a96d14e25c2efadff3b4e52._comment |   10 +
 doc/forum/unsynced_folder.mdwn                |    3 +
 ..._7d7a262f067c7b02d76e82637223934c._comment |   22 +
 doc/forum/untitled.mdwn                       |    5 +
 ..._0176d1d50bd62b113ff690346ba4161b._comment |   15 +
 doc/forum/update_via_cabal_fails.mdwn         |   35 +
 ..._e1235dc2acd3bac3dd51b7614dabbb88._comment |    8 +
 ...ting_the___34__number_of_copies__34__.mdwn |   14 +
 ..._327bdb0d9c190c60c7147b3acf07af09._comment |   10 +
 ..._7e11c839637e0894332e413cde02cee9._comment |    8 +
 ..._8b7a70fb3bb41e4eda412302834730bb._comment |    8 +
 ...ng_an_archive_on_a_new_external_drive.mdwn |   13 +
 ..._27b5283c65c402f330263426e4ca6ac1._comment |   10 +
 ..._b3a6b5ff0aaddd78903fc7bc7fbd6ee2._comment |   10 +
 ..._aab934c0e37771d7f834d2567a9e76a1._comment |   13 +
 ..._42beace277e009ddff449cb220775d44._comment |   13 +
 ...8___what_are_those_arrow_things__63__.mdwn |   29 +
 ..._bf34c169c725f9504e0f2114ba53be4b._comment |   10 +
 ..._364ce8b369fd0ba7ddaec3127840ff39._comment |   16 +
 ...tifier_of_objets___40__doi_like__41__.mdwn |   20 +
 ..._955f3aac12c1ddb41267c5a23ccb79e3._comment |   12 +
 ..._0aff36755f49afddd5482a602a1ccd2b._comment |   10 +
 ...question__58___developer_repo_with_s3.mdwn |    6 +
 ..._3e48d0a6c74e1bd67b1128d6b52f5fc4._comment |   24 +
 ..._751d3f5855729d493ee2042b19117a70._comment |   20 +
 ..._69ec3fedc166d68c10103b97c231e3d4._comment |    9 +
 ..._4afea3a65b6b5c57a4dac5cdbbf89432._comment |    8 +
 ..._743d7435c4e94efb293f4d6b1e83483d._comment |    9 +
 doc/forum/use_existing_ssh_keys__63__.mdwn    |    5 +
 ..._c420c53f022bbd1b28494bc44d076feb._comment |    8 +
 ..._e4cae848e5701852073ced307832872b._comment |   12 +
 ..._a97c20b6df74c49e5f57c7caf962f1e2._comment |   10 +
 ..._8977bb8ee662c30dfcecae73cede9dfa._comment |   12 +
 doc/forum/using_--quiet_with_sync.mdwn        |    9 +
 ..._69c2034761a8b92b001b142e49f0449e._comment |    9 +
 doc/forum/using_git-annex_with_lightroom.mdwn |    6 +
 ..._ec977efd277f0644767a4fc7064e4baf._comment |    8 +
 ..._4dc4f1ea91c72418843a682fab1854d2._comment |   28 +
 ...2_directories___40__like_unison__41__.mdwn |    7 +
 ..._5c3ee8a8aaa6d0918c0cc9683ce177ae._comment |   10 +
 ..._648946353c6d90c57351cce4010f1301._comment |   10 +
 ....net_as_backup_and_glacier_as_archive.mdwn |   13 +
 doc/forum/uuid_mismatch.mdwn                  |   17 +
 ..._ed29dcf70b916bdd094015c1c9616550._comment |   32 +
 ..._de4beb1eb76ae7084387e8efc28e55d3._comment |   15 +
 ..._a681a4847acbe890c4e486288b3c81d3._comment |   19 +
 doc/forum/v5_to_v6_upgrade_strategy.mdwn      |   21 +
 ..._1505166c806ab3d1a3148a245faa713a._comment |   15 +
 ..._ef2648a58037b867e2d745eb4b3a15a2._comment |   17 +
 ..._46fb3f5b0a7fa13b6f16ccb9832dac7e._comment |   22 +
 ...inning_seems_to_be_not_working_for_me.mdwn |   42 +
 ..._751e603141513faaa43abc38f3329a3e._comment |    8 +
 ...illa_git_repo_as_special_remote__63__.mdwn |   27 +
 ..._67e186265ae21f2cd8451750152f2a6d._comment |   13 +
 ..._6314256da98966f4c7d02aa0d6bf94ff._comment |   17 +
 doc/forum/version_3_upgrade.mdwn              |    9 +
 ..._05fc9c9cad26c520bebb98c852c71e35._comment |   13 +
 .../version_5_repo_with_version_6_repo.mdwn   |    3 +
 ..._95037082d15758d7b2c23ad041d7f6f0._comment |   12 +
 doc/forum/very_slow_on_exfat_drives.mdwn      |    7 +
 ..._5f67c870fc7e43ae75d8e1f8ced975c2._comment |    9 +
 ..._65460ed123404478ae59fed1b5cff627._comment |   18 +
 ..._77cd7b20abd0cd1eadee0ebeb186b3cf._comment |   18 +
 ..._1d6588477082dd6de6eaad02fdc53463._comment |    8 +
 ..._6487a9a170f7caa7c9db06ac3bee8c0e._comment |   11 +
 ..._1d7c3ff1eaeffe03fe7e3e25af822e4e._comment |   19 +
 ..._0f16c72ed7bcba01398b36cb8b3cee08._comment |   14 +
 ..._769b971263b9124ec08079336d03869d._comment |    8 +
 ..._b6ee8c6384c73b44ae9ccc0ba32c3135._comment |    8 +
 ..._b1dbbf57a46c79e8e32885c2ee8f45d2._comment |   12 +
 ..._ec5d339021f2a26942248962ea818a80._comment |   11 +
 ..._a6c5e8dc86ed6b4b5ff45f66f5bad50a._comment |   12 +
 ..._3e66ef8493d2839cb26418788c510463._comment |    8 +
 ..._ae7380ff84e4200985c22deb647853e3._comment |   18 +
 ..._5b69d3cb7d3a51ce8a9cbdb608be676c._comment |    8 +
 doc/forum/view_from_numeric_values.mdwn       |    9 +
 ..._f3c440f3f0104002a0020ba96ddcf87b._comment |   11 +
 ..._2414e1a8cfd154c339d8fc0e4a630ae9._comment |   12 +
 ..._7879a11cc9767cdaac14f9993182dc25._comment |   13 +
 ..._517c7659654a6fc608eb3332053df8a4._comment |   28 +
 .../view_including_files_with_no_tags.mdwn    |    5 +
 ..._b0aafc023fbec33af268576c4c199af3._comment |   24 +
 ..._5ae9d5308371bdb1f94342c9f9b01aff._comment |    8 +
 ..._40__branches__41___never_get_deleted.mdwn |   16 +
 ..._ff53fa0b5f0c4a6554a37e3309e26925._comment |   12 +
 ..._1d4a3f4e83b288262e291262a6636602._comment |   21 +
 ..._4e96e5325fd12e48f190fe551a6ac07e._comment |   12 +
 ..._a4764b5bfb08ebe90430ea14fcb6e8e0._comment |   10 +
 ..._02e08dffb01246010b390aeef8f32234._comment |    8 +
 doc/forum/vlc_and_git-annex.mdwn              |   11 +
 ..._9c9ab8ce463cf74418aa2f385955f165._comment |   10 +
 ..._037f94c1deeac873dbdb36cd4c927e45._comment |    8 +
 ...ough_report_setting_up_tor_p2p_remote.mdwn |   91 +
 ...existent_ref__44___unable_to_checkout.mdwn |   69 +
 ..._c0d9758be80d1a349ffe82c80075bebd._comment |   12 +
 ..._c28dae2eb0ab825ee6d43735e04a18a3._comment |   22 +
 doc/forum/web-browser_for_the_repository.mdwn |   10 +
 ..._1f8e7e54e9f377417cd672d66ae9bd9d._comment |    9 +
 ..._551d5bb2d24212de65720d796365177f._comment |    9 +
 ..._d410df4b7160f17e3846674c3e0e9368._comment |    9 +
 ..._d06217403bf53a713b845bbc9ca8b962._comment |    7 +
 ...p__58___disabling_a_paired_repository.mdwn |   12 +
 ..._9dd316fedf55afecbc77f3b99e66d837._comment |   18 +
 ..._28cf58629b9774426c084d80964151d7._comment |   19 +
 ..._799d66b116e8ddf42e624bb4a082337c._comment |    8 +
 ...webapp___47___assistant_without_watch.mdwn |    9 +
 ..._1bcd99aa81f937ded683e19a69d33dd9._comment |   10 +
 ..._9f5b3f5bf7fedcd5baec519d97d3aa8c._comment |   16 +
 doc/forum/webapp_and_manual_mode.mdwn         |    7 +
 ..._5b5df5ffeb6ee15779972f13fdc11729._comment |   10 +
 ..._a1f06b50d1317c78a301b47eb05d2617._comment |   19 +
 ..._f0739bf4304a91a5d4ec33ac2421c966._comment |    9 +
 doc/forum/webapp_does_not_start.mdwn          |   72 +
 ..._dd27d30ce305562a1552f46c87b1cd27._comment |   12 +
 ..._ef37f40288a1181ca619ae13b0f7a994._comment |    8 +
 ..._6e625dba9f7fa36bf9c7e9d77fbadeff._comment |    9 +
 .../webapp_listen_port_with_autostart.mdwn    |    3 +
 ..._65dbcf3d8f6c16568f5a326242eab9c5._comment |   20 +
 ..._39664f833dedc1a4fe083eec9bc4a7cd._comment |   75 +
 doc/forum/weird_view_file_naming.mdwn         |   13 +
 ..._24a44f94194231bb8efe9b20ee311d4c._comment |   12 +
 ..._2ff3002e45a7443f0502243b3690df9d._comment |   11 +
 ..._git-annex_when_using_it_like_dropbox.mdwn |    6 +
 ..._b76e6d3c4d530fd6735460aa5ab03ad5._comment |    8 +
 .../what_happens_to_deleted_files__63__.mdwn  |   24 +
 ..._a476174646ad3adfbbe0cafdd7d42d08._comment |   10 +
 ...ync_--content_using_to_send_files_out.mdwn |   31 +
 ..._86428fc8286266d01cc51af8ae4aa335._comment |   34 +
 ..._50c1a19a7278e8748c2e6e789f6b418a._comment |   16 +
 ..._368403625451415c66b9e62005d9ddea._comment |   14 +
 ..._53ccb5c7c8f15f44fb2f113742fe77f3._comment |   10 +
 .../when_repo_offline_list_whereis_slow.mdwn  |    2 +
 ..._79052583012da5097ca7bdc52dcdfb7d._comment |    9 +
 ..._caa2b4ca2826444bdfb47616a549f4e6._comment |    7 +
 ...mit_pull_requests_for_git-annex__63__.mdwn |    4 +
 ..._f5e6022798ba63b55bff197b5937f9fe._comment |   14 +
 .../whereis__58___Why_not_here__63__.mdwn     |   33 +
 ..._02a423918efcc760bb89dfb78586dc2a._comment |   12 +
 ..._e55ce8cbb6bbabc654ba743d755a6eee._comment |   10 +
 ..._7de87ad1fd8a0f53562d3083af1410d6._comment |   33 +
 ...and_with_file_names_instead_of_hashes.mdwn |    7 +
 ..._4eaca07152916adc18032fb404e4dd92._comment |   10 +
 ..._94b43ac23ff8332b35723422eede8997._comment |    8 +
 ..._45ffa6dd17667ecd6685f85f34046eff._comment |   10 +
 ..._d459fbcf0db59b821ae67f4949e48103._comment |   14 +
 ..._e52a8c9cb418fbc2e2cba71f37bd44ad._comment |    8 +
 .../which_version_should_I_install__63__.mdwn |    8 +
 ..._147f12392f6f546ab50dc346052ad4b7._comment |   12 +
 ..._c85c107a60b4b642ed9a8de7d233f95e._comment |   46 +
 ..._f627212a612f5d746bb8bcc5e1ea48df._comment |    8 +
 ..._1c8201cf1de60fde73a2370a6e6c3ad3._comment |   15 +
 ..._c0f850927683d45dbe4d6d1d61788b4a._comment |    8 +
 ..._b563b2be227a1a128d8ac0679108f5b5._comment |   11 +
 ..._e24a8a8edd7d0b314f26406d17775fdc._comment |   10 +
 ..._ef725153df7a9b65f7ade4d7e6cecffb._comment |   12 +
 ..._git_annex_fix__96___fix_a_link__63__.mdwn |   32 +
 ..._865245182d765fed7bbeb42a35dd605e._comment |    9 +
 ..._c1f5a285b7cfb92d218b9b0d31caeed6._comment |    7 +
 ..._be2816c47091842b829cd626e18c5fda._comment |    9 +
 doc/forum/windows_port__63__.mdwn             |    2 +
 ..._23fa9aa3b00940a1c1b3876c35eef019._comment |    9 +
 ...et__47__drop_via_webapp_file_explorer.mdwn |    1 +
 ..._c818a6d44dc13a56460b1865f70eb97c._comment |    8 +
 ...ake_copy_stop_on_exhausted_disk_space.mdwn |    4 +
 ..._467e5e3db3e836030bc4b4f15846951f._comment |   12 +
 ..._e3ca3db9bea11d3e085ee9c3c56b33fe._comment |    8 +
 ..._0ef8c37350fc192d9b784fbab1d9f318._comment |    8 +
 .../working_without_git-annex_commits.mdwn    |   20 +
 ...peared__44___broken_symlink_showed_up.mdwn |   27 +
 ..._00b084f9786de6516f46065c0cb00e79._comment |   11 +
 ..._138499b36d28c5e267b4aad8792dc87e._comment |   48 +
 ..._6c59c494b563e56d061417eb2216bb19._comment |    8 +
 ..._ccbba61cdd6fce3e5de82417bcc0cbfb._comment |   12 +
 ..._50526283b35997cece2f087507cdd4ee._comment |   12 +
 ...de_to_track_my___47__home__63____63__.mdwn |    7 +
 ..._b011442de2f67f3ad340031a0767e990._comment |    8 +
 ..._c69865c08c3eb49d64310fc76e80c65d._comment |    8 +
 ..._7651fb48fc71b2c7b4e7b6830a0f9865._comment |   10 +
 ..._7d88f1aa163185c801b7697846086c7f._comment |   12 +
 doc/future_proofing.mdwn                      |   53 +
 ..._2614eb2e9b7b23fa9bb4251c0d025909._comment |   16 +
 doc/git-annex-add.mdwn                        |  137 +
 ..._0e6b855afb4fba540ea5560df26839c5._comment |   11 +
 ..._43cf725964c63a2d2545d9f204316a57._comment |   11 +
 ..._8517f9634d217f731efd704405d3f2ca._comment |   10 +
 ..._3bbbe94633b6cb4ef93b7942eb36cc6c._comment |    9 +
 ..._f67bd5fdbe9deeeea1d48175a6b5c536._comment |   14 +
 ..._be9e67994aacebedb478f68a8ae542a5._comment |   14 +
 ..._bb9d72f90f4d3c93d71de1a1bbc244b6._comment |   14 +
 doc/git-annex-addunused.mdwn                  |   42 +
 doc/git-annex-addurl.mdwn                     |  190 +
 ..._66051cf22495e661828f2ef3291f8578._comment |    8 +
 ..._a09a85bbabc112369ab661b7ac5f277d._comment |   10 +
 ..._f75e35ae6f739e98aeb15c3f8708be8a._comment |   15 +
 ..._f413cc1febfa70e3ad885c6fa031a209._comment |    9 +
 ..._5719924fbda2daabe83ef2fde447d620._comment |   12 +
 ..._460d474cb8ef32d41eae71ee070de0b3._comment |   27 +
 ..._c6e1743647bb4d45b5a1b237f53d77a6._comment |    7 +
 ..._ce9c660be160a22c28aeb6de8b3b5818._comment |   16 +
 ..._9bc984fb80d77309b62a4e915e65a31a._comment |   14 +
 ..._46e1b62d37619521a60eb2339b8d094f._comment |   21 +
 ..._0951800d761d18614eb6c5f08cdbb885._comment |   18 +
 ..._47dfa82fc6426fb9ad050dd00290dc03._comment |    9 +
 ..._8d8ac07a0f0fe599ea5ed1e4089b13fa._comment |    8 +
 ..._88aea3014245634d42f23a22ccf2fcc9._comment |   17 +
 ..._b261e7bfeeffb2c5264aaadae1d78817._comment |    9 +
 ..._48741c1c625dc1ecba2db4f7be2f644c._comment |   41 +
 doc/git-annex-adjust.mdwn                     |  137 +
 ..._364d1d5546c0f448a4b27cfe69a59a07._comment |   14 +
 ..._383af8e1e26e4119671437aace0a58f5._comment |   20 +
 ..._c5af3a73af8925839413467a7d1e0e14._comment |    8 +
 ..._597c5e0254012e3a4ecafa49cfa23cb6._comment |    8 +
 ..._f00c27078cce5ad75fcf0cec1033751b._comment |   14 +
 ..._a9c88b1d83d5e874f8f8063fcdd9e624._comment |    8 +
 doc/git-annex-assist.mdwn                     |   69 +
 doc/git-annex-assistant.mdwn                  |   72 +
 doc/git-annex-backends.mdwn                   |   24 +
 doc/git-annex-benchmark.mdwn                  |   65 +
 ..._fe0e8d2e2e875521e715ee2e68818570._comment |   21 +
 ..._3d8dcde00f8df7961490ef81f5400824._comment |   19 +
 doc/git-annex-calckey.mdwn                    |   47 +
 doc/git-annex-checkpresentkey.mdwn            |   40 +
 ..._756f276929a0b0ff73baea141d3ef07d._comment |    8 +
 ..._e277962791b64e67b08ccff47dd22447._comment |   14 +
 doc/git-annex-common-options.mdwn             |  155 +
 doc/git-annex-config.mdwn                     |  238 +
 ..._26bd743439e87e71b1eea2c620e6fc12._comment |   10 +
 ..._0cf3e61f86b217b89dcace22bdfaaa44._comment |    8 +
 ..._cd443c49f9d1122f078872259e342683._comment |    8 +
 ..._e1c484811ea276532ed1b5c965d4de1b._comment |    8 +
 doc/git-annex-configremote.mdwn               |   41 +
 doc/git-annex-contentlocation.mdwn            |   36 +
 doc/git-annex-copy.mdwn                       |  151 +
 ..._9be279110a112335bc72ee8c8a347da2._comment |   12 +
 ..._599958b0a57d2f8f4383733d28ad9c8d._comment |    7 +
 ..._a9408822e314c32bebf8230f9d40216b._comment |   12 +
 ..._44dcb42a011cc203655bccca06de2e10._comment |    8 +
 ..._fe7c2c6617b3a5ca153af2225fc66498._comment |   11 +
 doc/git-annex-dead.mdwn                       |   65 +
 doc/git-annex-describe.mdwn                   |   45 +
 doc/git-annex-diffdriver.mdwn                 |   64 +
 ..._b45fd606668e2eee0a37bf1db3391f37._comment |    9 +
 ..._05c3a29d7827dd6fc5babe0ac1ff2a94._comment |    9 +
 doc/git-annex-direct.mdwn                     |   27 +
 ..._5d6f9e9393e534e027ddcd555861196b._comment |    9 +
 ..._ef8ac748470549776c1ee299b062add2._comment |    7 +
 doc/git-annex-drop.mdwn                       |  152 +
 ..._9ed8d998831414436e5d0e100ed96fb7._comment |    8 +
 ..._95c5be6e2be84dc0903e3d7384f67313._comment |    8 +
 ..._ecb863aea64eadbaeb7759c5cb0bf5a5._comment |   12 +
 ..._c9017041b01d803b346b1b14b8d1e066._comment |   14 +
 ..._16095aad685d142672911e799450634a._comment |   14 +
 ..._156873ca9820b316a2099b6646562891._comment |    9 +
 ..._655f0bcaafdf03eb637af715e7642e27._comment |    8 +
 ..._ed46bc0407457fc5db0d5241ba69d9ed._comment |   10 +
 ..._f9b255923bdb20c92b878d86998b7ae2._comment |   11 +
 ..._cf6fbdc5355aebe33188825d578690c1._comment |   11 +
 ..._55d96bb12b325954bb7e7817f1a8ff3f._comment |    8 +
 doc/git-annex-dropkey.mdwn                    |   49 +
 doc/git-annex-dropunused.mdwn                 |   65 +
 doc/git-annex-edit.mdwn                       |   18 +
 doc/git-annex-enable-tor.mdwn                 |   40 +
 doc/git-annex-enableremote.mdwn               |   88 +
 ..._43876327581d6bcfb69c318c02d6389a._comment |   21 +
 ..._78223f5c6ad120d5e0b98583543425db._comment |   37 +
 ..._4bc11d1df0ff6962b12f5b8a1bb6188e._comment |    9 +
 doc/git-annex-examinekey.mdwn                 |   91 +
 doc/git-annex-expire.mdwn                     |   79 +
 doc/git-annex-export.mdwn                     |  175 +
 doc/git-annex-filter-branch.mdwn              |  151 +
 doc/git-annex-filter-process.mdwn             |   52 +
 doc/git-annex-find.mdwn                       |   96 +
 ..._8d931c135df8f9eba201a3dbb94af87e._comment |   18 +
 ..._b9d4cc7438ce5dbe22b62e9decc6cbee._comment |   10 +
 ..._d5846a41e2e227569d7d90dbb8edf7d8._comment |    8 +
 doc/git-annex-findkeys.mdwn                   |   75 +
 doc/git-annex-findref.mdwn                    |   27 +
 doc/git-annex-fix.mdwn                        |   49 +
 doc/git-annex-forget.mdwn                     |   43 +
 doc/git-annex-fromkey.mdwn                    |   60 +
 doc/git-annex-fsck.mdwn                       |  134 +
 doc/git-annex-fuzztest.mdwn                   |   27 +
 doc/git-annex-get.mdwn                        |  156 +
 ..._9914f6f6c99757927eed9b5d0217908e._comment |   19 +
 ..._ce5c85afa01019afe58c79df151c65ff._comment |   12 +
 doc/git-annex-group.mdwn                      |   39 +
 doc/git-annex-groupwanted.mdwn                |   46 +
 doc/git-annex-import.mdwn                     |  250 +
 ..._8961635a772b4ddb5ba1e04a50034e6a._comment |   11 +
 ..._e62b59d5c9cee04a77c51799624a3357._comment |    8 +
 ..._3891ccc35010e1e5c328a9aa6b9e596b._comment |   15 +
 doc/git-annex-importfeed.mdwn                 |  147 +
 ..._d0197108d07873040e46577df1faadbd._comment |   16 +
 ..._25d4ed016e98609066597a8d2b956f87._comment |   15 +
 ..._bce2b233e4d42fc87a2e17d51e2c2606._comment |   11 +
 doc/git-annex-indirect.mdwn                   |   27 +
 doc/git-annex-info.mdwn                       |   99 +
 doc/git-annex-init.mdwn                       |   86 +
 doc/git-annex-initremote.mdwn                 |  148 +
 doc/git-annex-inprogress.mdwn                 |   72 +
 doc/git-annex-list.mdwn                       |   40 +
 doc/git-annex-lock.mdwn                       |   50 +
 doc/git-annex-log.mdwn                        |  147 +
 doc/git-annex-lookupkey.mdwn                  |   48 +
 ..._100fcc1559449ae99a2dc6eade61662c._comment |   49 +
 ..._897eaca8174d5f568a19805f90d9e1c3._comment |    8 +
 doc/git-annex-map.mdwn                        |   52 +
 doc/git-annex-matchexpression.mdwn            |   75 +
 doc/git-annex-matching-expression.mdwn        |   92 +
 doc/git-annex-matching-options.mdwn           |  310 +
 ..._09d1a7961a79dff47bef8797b3775766._comment |    9 +
 ..._78a5e7090e5ac3e6710813bac600fde0._comment |    7 +
 doc/git-annex-merge.mdwn                      |   56 +
 doc/git-annex-metadata.mdwn                   |  182 +
 ..._278fca1c579d0acdcce819449aec8eee._comment |   13 +
 ..._deee9a4c3a812c9c8097d89f2f6c7d76._comment |   10 +
 ..._45492400069021adbe048978be6957ef._comment |   12 +
 ..._12e615b99bf9999df0678cb6dc09d398._comment |   11 +
 ..._6537bd785997501a9708682acd91f9f6._comment |   18 +
 ..._49c885bd5840aba9f9e011a1618931a1._comment |    9 +
 ..._b4f928a4e8a81165e3845219483a9b25._comment |   10 +
 ..._11b1fa357953736925cfbbc1079590dd._comment |   13 +
 ..._fe7d15a1a4cd729b6ffec26f49d8b47a._comment |    9 +
 ..._54cff011e3e13882cfbd7a30fb43d078._comment |   11 +
 ..._a14b21109aa12eaf13e8c215e108cc29._comment |    8 +
 doc/git-annex-migrate.mdwn                    |  112 +
 doc/git-annex-mincopies.mdwn                  |   48 +
 doc/git-annex-mirror.mdwn                     |  100 +
 doc/git-annex-move.mdwn                       |  146 +
 ..._b69fbe2f3892deddb269dd3eb1fdcd84._comment |   12 +
 ..._f2908113a633034aa73b8564d22abba6._comment |    8 +
 ..._82cfbc0f3600c7c4c9dffc1d35e81123._comment |   11 +
 ..._013e20add9a007d3f9a9c2a2ceb6cb06._comment |   13 +
 ..._e7608b7fac4ec80781cb4281dc2bf596._comment |    8 +
 ..._eb62a9020575d89799815f6e4b98b28c._comment |   10 +
 ..._e23e2a133db02112ca99aeda0499e841._comment |    8 +
 doc/git-annex-multicast.mdwn                  |   97 +
 doc/git-annex-numcopies.mdwn                  |   45 +
 doc/git-annex-oldkeys.mdwn                    |   54 +
 doc/git-annex-p2p.mdwn                        |   82 +
 ..._d5a6a2eab5d32a9c2f4ed194e01d95e8._comment |   10 +
 doc/git-annex-post-receive.mdwn               |   36 +
 doc/git-annex-pre-commit.mdwn                 |   32 +
 doc/git-annex-preferred-content.mdwn          |  317 +
 ..._4c24f4513af72214bd5feb69f1ab86bc._comment |    8 +
 ..._e4e0f34466db1fecd21db0e929530ad0._comment |    8 +
 ..._73c14351e041ac5ba86f6ab21487fd12._comment |    7 +
 ..._4f30e99af93a2eb571f5b084cfa72d0d._comment |   11 +
 ..._b05949f87e0073e93a7e09658bd21f05._comment |   13 +
 ..._f10a0c185fa2f2b4b8ec9fceaed6e8e1._comment |   10 +
 doc/git-annex-proxy.mdwn                      |   25 +
 doc/git-annex-pull.mdwn                       |  153 +
 doc/git-annex-push.mdwn                       |  147 +
 doc/git-annex-readpresentkey.mdwn             |   32 +
 doc/git-annex-registerurl.mdwn                |   77 +
 doc/git-annex-reinit.mdwn                     |   52 +
 doc/git-annex-reinject.mdwn                   |   97 +
 ..._070a87e0cb1bbc49088989293334e1fb._comment |   48 +
 ..._d1a04e31fea877ae5fe873fbd01fdcaa._comment |    8 +
 ..._2dcdd82efbd6dcac0f3b729d55a09386._comment |    8 +
 doc/git-annex-rekey.mdwn                      |   59 +
 doc/git-annex-remotedaemon.mdwn               |   58 +
 doc/git-annex-renameremote.mdwn               |   47 +
 doc/git-annex-repair.mdwn                     |   59 +
 ..._088ce57c74a653478e03968e1d6bba23._comment |   16 +
 doc/git-annex-required.mdwn                   |   49 +
 doc/git-annex-reregisterurl.mdwn              |   64 +
 doc/git-annex-resolvemerge.mdwn               |   70 +
 doc/git-annex-restage.mdwn                    |   34 +
 doc/git-annex-rmurl.mdwn                      |   53 +
 ..._fc99b7e905c81183f78320af266ae1a5._comment |    8 +
 ..._181581caac6ee439ba1003ebca79ed09._comment |   11 +
 doc/git-annex-satisfy.mdwn                    |   74 +
 doc/git-annex-schedule.mdwn                   |   55 +
 doc/git-annex-semitrust.mdwn                  |   46 +
 doc/git-annex-setkey.mdwn                     |   33 +
 doc/git-annex-setpresentkey.mdwn              |   44 +
 ..._58c98aafb5f6c20c6b71126cd17d3a40._comment |    8 +
 ..._57b0ae8a49df6c8809aa3050610191b2._comment |   10 +
 ..._30a5d3fbd8e02726989ab80ed98b4a54._comment |   15 +
 ..._df3018b9b3491963311063e8ff202df4._comment |    9 +
 doc/git-annex-shell.mdwn                      |  194 +
 doc/git-annex-smudge.mdwn                     |   66 +
 doc/git-annex-status.mdwn                     |   46 +
 doc/git-annex-sync.mdwn                       |   92 +
 ..._2e12ed1c1a594dfbd06a3f25f5e25e57._comment |   10 +
 ..._cc11f83a06352e5049dcbc588d216f27._comment |   10 +
 ..._cf05eba2bcc10f48092334f9ce889863._comment |    8 +
 ..._bd5e45a7e668063df9159033a0857075._comment |    8 +
 ..._5bf6c2b9750dbe5cff87d630f59f511a._comment |    9 +
 ..._2c989d6d9f2ad2821db970cb3aed83c7._comment |   18 +
 ..._8f9a5457020bed293e9a93ccc9461a65._comment |   10 +
 doc/git-annex-test.mdwn                       |   71 +
 ..._5fbd7f75fef7a9f504baab1fae05d72c._comment |    8 +
 ..._752ca0ba483203cc4f5ccf36752e656d._comment |    9 +
 ..._cac436ddf4dec95006d1ebb4171a3289._comment |    8 +
 doc/git-annex-testremote.mdwn                 |   60 +
 doc/git-annex-transferkey.mdwn                |   39 +
 doc/git-annex-transferkeys.mdwn               |   31 +
 doc/git-annex-transferrer.mdwn                |   28 +
 doc/git-annex-trust.mdwn                      |   52 +
 doc/git-annex-unannex.mdwn                    |   56 +
 ..._281aea2f018ea0fc98452c0d180c3bcb._comment |   62 +
 ..._d325e4201ec2964c5633e00c473df755._comment |   10 +
 ..._034db8e67e4bf5321e022918902f38e8._comment |   27 +
 ..._2a5334f59a4bdf242d53d2d5c120283c._comment |   12 +
 ..._d549796a3b1bdd3e980cb2c05f30fe2e._comment |   14 +
 ..._d5a8450349b0383ec29d150420189937._comment |   97 +
 ..._a6b64c4d90f4d228b8facce5e2399eca._comment |   25 +
 ..._54a6008e1db73d16d72587830912d772._comment |    9 +
 doc/git-annex-undo.mdwn                       |   49 +
 ..._3466520304aa164ec44ed4e9d67590e7._comment |   55 +
 ..._3dba1a993cbd357bdaa453366c0185cd._comment |   16 +
 ..._ac1369c0417c1dc5f1b41b5cc88fe2fd._comment |   18 +
 ..._18ed23e07ffed1cbf63e71fb115b0654._comment |   66 +
 doc/git-annex-ungroup.mdwn                    |   27 +
 doc/git-annex-uninit.mdwn                     |   41 +
 ..._075670e8e153e1d9f420b7d53c6ec06d._comment |    9 +
 ..._c695775bdb2c7491314a33dd6bcb447d._comment |   14 +
 ..._3386d8419830354b4422d38448467e95._comment |    9 +
 ..._53358bdd6093e2fb787df8de7190c5fd._comment |   17 +
 doc/git-annex-unlock.mdwn                     |   79 +
 ..._1f5ca7ccd35e9b102bf24b3f14deeee1._comment |   17 +
 ..._26ad80a6ad142e7dac6c8af955a4413f._comment |   17 +
 ..._d7f38f681be51db1244988847840d735._comment |   11 +
 ..._51158d4484ecb39633ec828beb8d9ce3._comment |    8 +
 ..._516a1522db3d1c14cc5131a24d672a8f._comment |   11 +
 ..._d04a1d4159306939b91a34fd17ab0325._comment |    9 +
 ..._40abc819288a97753747562f16b8febe._comment |    8 +
 ..._047355b1ba5e90b71fc85b42f52d1aeb._comment |   16 +
 ..._7ab5b674d0fc18da262e6c0264953e21._comment |    9 +
 ..._d10c8b6e2dd8800cbfc11a7fa8536065._comment |   10 +
 ..._31c72f60ddf029f09c1850223d5a8a55._comment |    8 +
 doc/git-annex-unregisterurl.mdwn              |   68 +
 doc/git-annex-untrust.mdwn                    |   45 +
 doc/git-annex-unused.mdwn                     |  110 +
 ..._5c1ea2e8ac475d8c0ddca2c38f968b95._comment |   13 +
 ..._573e68def90ffd899271c6a9f80eae3c._comment |    8 +
 ..._4a935c0c8862b24202c877031c35e238._comment |    8 +
 ..._029c4bee59e48806c9f3d83579fdbb90._comment |    8 +
 ..._c4d994706f69024788e6653d02a09517._comment |    8 +
 ..._ca010846ef8eed4a302b6755f1f521f4._comment |    8 +
 ..._5eb913bb96a04a174c04fe5d119977f4._comment |   10 +
 ..._5b208cb45335f0d383a456865068e659._comment |   29 +
 ..._65ab9f687f2817199eda7455d9b82677._comment |    8 +
 ..._962097729f8b4a657bb7b9863fdffb68._comment |    8 +
 ..._e21b036767651c5cfdd34bbd24a31fb5._comment |    8 +
 ..._10ee2770ffe1cde367f3d310b2670539._comment |   10 +
 ..._cfcc0bab810d58b7db66c2fa4e92f769._comment |    8 +
 doc/git-annex-upgrade.mdwn                    |   60 +
 doc/git-annex-vadd.mdwn                       |   42 +
 doc/git-annex-vcycle.mdwn                     |   38 +
 doc/git-annex-version.mdwn                    |   38 +
 doc/git-annex-vfilter.mdwn                    |   36 +
 doc/git-annex-vicfg.mdwn                      |   32 +
 doc/git-annex-view.mdwn                       |   77 +
 doc/git-annex-vpop.mdwn                       |   38 +
 doc/git-annex-wanted.mdwn                     |   39 +
 doc/git-annex-watch.mdwn                      |   47 +
 doc/git-annex-webapp.mdwn                     |   60 +
 ..._443c5595412a19ef9c6948c4224297a3._comment |   12 +
 ..._7b1c4c4356e801006081588b32075fb4._comment |    9 +
 ..._aee70625f7cff6e7312f9bc2cbbb02d0._comment |    8 +
 ..._c1754cdb4087ad278867ed8fddd99409._comment |    8 +
 ..._31301895752f0dd81db72c463f0dc732._comment |    9 +
 doc/git-annex-whereis.mdwn                    |  122 +
 ..._6a1f97de22983127bfc351d14838fb0e._comment |    8 +
 ..._69a861de80c7d2b939aae7103b1b7359._comment |   14 +
 ..._d06a33bfaeb2a9274d12639fdedcfa8a._comment |   10 +
 ..._3f06096e582178b4c69d63e84735d911._comment |   11 +
 doc/git-annex-whereused.mdwn                  |   53 +
 ..._bebd4ad86c6a64cc48e6f0dd5861f3de._comment |   30 +
 ..._f926fbe7c558a242a2af949daed415f7._comment |    8 +
 ..._bc04457bf320e81437c2eb858793c5ca._comment |    7 +
 doc/git-annex.mdwn                            | 2203 ++++
 doc/git-remote-tor-annex.mdwn                 |   36 +
 doc/git-union-merge.mdwn                      |   38 +
 doc/how_it_works.mdwn                         |   44 +
 ..._b3bdd6a06d5764db521ae54878131f5f._comment |   14 +
 ..._2a8ce5859040d815e6234fc18f5f1961._comment |   10 +
 ..._806c0fe325942a425e43afb9b78327ec._comment |    8 +
 ..._0ef6b8c9dbd5a7f9b9f274dc6f9988f0._comment |    9 +
 ..._11e5141c9ffb37db4fa0c1bfb32c51a9._comment |   15 +
 ..._2ad3441a02f1bcc2cca0c10ecf7b216f._comment |   35 +
 doc/index.mdwn                                |   40 +
 doc/install.mdwn                              |   41 +
 doc/install/AlpineLinux.mdwn                  |    3 +
 doc/install/Android.mdwn                      |    7 +
 doc/install/Android/git-annex-install         |   58 +
 doc/install/Android/oldapp.mdwn               |   11 +
 ..._225f2c6fe255be93702cfbd4dc172f3b._comment |    8 +
 ..._4b565e73f02f0e84bdf7e686b0d7bf5f._comment |    8 +
 ..._3e7980603749665fafbdeb1b7ab068a5._comment |    8 +
 ..._4e970633d9073fcf4bc33f3fff2525b2._comment |   10 +
 ..._57867e2b13b83cc9815df56b027d388a._comment |    9 +
 ..._87da4f379a0276b662583e7e22061218._comment |    8 +
 ..._169025cf0b415d5a45dd89856e53cca9._comment |   26 +
 ..._19909ddf4e7e6da0e814e165c5c9b44a._comment |    9 +
 ..._f9ced494a530e6ae3e76cfbaddb89f5d._comment |    8 +
 ..._74cccae04ea23a8600069c7e658143aa._comment |    8 +
 ..._82c7cb31d19d4e18ca5548da5ca19a79._comment |    8 +
 ..._cebaa8ee5bbed27d9b2d032ca7bdec6e._comment |    8 +
 ..._34f7c42050fa48769a6bfae60d72e477._comment |    8 +
 ..._f3d289b78d6bdb3cc65689495a8439a5._comment |   11 +
 doc/install/ArchLinux.mdwn                    |   21 +
 ..._b68c42b3804481808dfe83ae557edec3._comment |   10 +
 ..._0d51aaebe5929b03cba38156a97bf3cc._comment |   13 +
 ..._e5f923e6d81cfb3fba7a72f60baaf4ab._comment |   16 +
 ..._8e607cd883ec174571e9dfe3b25bfd05._comment |    8 +
 ..._a378391dd218859f381c479259dd8fe3._comment |   10 +
 ..._1d597d6a95f9c2df7dae6e98813e4865._comment |   36 +
 ..._2d708977e2fad6b68803494576382df5._comment |   10 +
 ..._97d611f1ae6d4fbe91f84f9fe739f368._comment |   13 +
 ..._5b5f5e0b64e5bfb1ea12e8b251c6fb5f._comment |   15 +
 ..._ddc13b45286933e7dd06f5bd6ea8fac9._comment |   10 +
 ..._b5f1bd5d92cf35002e2ea75e07040bea._comment |    9 +
 doc/install/Debian.mdwn                       |   14 +
 ..._b44ed53973ac26eedd3838df28f74a7e._comment |    7 +
 ..._a0105d7f045511b9c80ea9bb0eac3708._comment |    8 +
 ..._435fb1359ea7f481ae23a973216085d8._comment |    8 +
 ..._a34e23d9aa3027012ab1236aa4f7d5cb._comment |    8 +
 ..._20d8271ba3f6cfe3c8849c3d41607630._comment |    8 +
 ..._89f67da4a4a6a626a7db9c6674b244b6._comment |   11 +
 ..._ef7f3e88d61833e51f0302e938343818._comment |   10 +
 ..._029486088d098c2d4f1099f2f0e701a9._comment |    9 +
 ..._648e3467e260cdf233acdb0b53313ce0._comment |    8 +
 ..._4d922e11249627634ecc35bba4044d9e._comment |    8 +
 ..._2a93ab18b05ccb90e7acc5885866fca2._comment |    9 +
 ..._1bccc7bf7a4ef61a9b30024b9b22ba7d._comment |   12 +
 ..._5b5a3b0e8abe8831a6a15a4e258d14fd._comment |   10 +
 doc/install/Docker.mdwn                       |    6 +
 ..._909e3b2da0050ce1102c289cc5aac522._comment |   66 +
 doc/install/Fedora.mdwn                       |   40 +
 ..._c4db84e672ad4b45b522db735706b00f._comment |   16 +
 ..._f98c488c09bef86e2b0414589ce9e141._comment |   25 +
 ..._d872acf8865fe7c99a9b712db5b38ea4._comment |    8 +
 ..._93b3402e4c51e1a5c96f907bb528164b._comment |   16 +
 ..._0427e0503764b29e57abf9e97155136b._comment |   15 +
 ..._1b1b38a79251fe2e8c1e4debbe3bc3c5._comment |   12 +
 ..._4832d271dcc63a6cd1c40fe38ad5e367._comment |   24 +
 ..._80e167cde1a6511683a8f6e8029c0da6._comment |   10 +
 doc/install/FreeBSD.mdwn                      |    2 +
 doc/install/Gentoo.mdwn                       |    3 +
 doc/install/Guix.mdwn                         |    7 +
 doc/install/Linux_standalone.mdwn             |   68 +
 ..._1adc00aecc51f1e74701bd67cd74155d._comment |    8 +
 ..._7983285b56fd10359a7cc3615fd1e2fe._comment |   12 +
 ..._eaa9b0532d4629b61f3a684886b1d4f9._comment |    7 +
 ..._070689ea45739d06260da07d1369dff9._comment |    7 +
 ..._9046b80114fc03179c971bfb3e4d666d._comment |    8 +
 doc/install/NixOS.mdwn                        |   10 +
 ..._4e487ddd2654a8a992c1538b9c3bf003._comment |   21 +
 doc/install/OSX.mdwn                          |   42 +
 doc/install/OSX/Homebrew.mdwn                 |   25 +
 ..._61cad5a309c3c4e3f278dec1890c9f40._comment |   12 +
 ..._2f89cfbc42590885fb7e92a89d0f7895._comment |   38 +
 doc/install/OSX/MacPorts.mdwn                 |   27 +
 ..._987f1302f56107c926b6daf83e124654._comment |   11 +
 ..._47a77a03040fe628109bd54f82f9ad7a._comment |   17 +
 ..._e5172de344908f85ce6cf976e3c3806b._comment |   10 +
 ..._8d53c477b441ab0984257b21003c7cc7._comment |   12 +
 ..._17b84f51de6bed88e373350b194c8a8d._comment |   10 +
 ..._f4b39e2009274539d60b29711a4a2c8d._comment |   22 +
 ..._5581b7d1c09e6a78419d626bb25261b6._comment |   10 +
 ..._dda16b58686b0e5d061521f8e1831f89._comment |    9 +
 ..._277249620801bd4305776a3d598bd074._comment |   24 +
 ..._06e8fc7a4670a42c249f90a3602c3523._comment |   11 +
 ..._5eca3153048d2b3b4fa707d6b8a5ebeb._comment |    9 +
 ..._040d388c94ee0e537990f0cd782d8554._comment |    8 +
 ..._3e6a3c00444badf2cf7a9ee3d54af11e._comment |    8 +
 ..._951e6bb1f70d8f02374e9e3fb91dc182._comment |    9 +
 ..._6ae394921280d3cd4907f210b9845a2f._comment |    8 +
 ..._895d4e837d05a318512730d66f14db22._comment |   11 +
 ..._af10ed56c037499d002fcf0114b9426a._comment |   15 +
 ..._db90984062a07576a4777b2d743161f1._comment |   24 +
 ..._25552ff2942048fafe97d653757f1ad6._comment |    8 +
 ..._25cac8bcd84a5210fc0a5243260b8cc7._comment |   18 +
 ..._39b4b748b4586bf32b37edfefef84bba._comment |    8 +
 ..._1a9c91ef43edc4148947f202ff604114._comment |    8 +
 ..._892f7e65f95f43697164267c4b71c0d5._comment |    8 +
 ..._b94193a0583605920effa7179a6164d9._comment |   10 +
 ..._f11f726d1fee3c4c91f3c984e792037d._comment |    8 +
 doc/install/OSX/old_comments.mdwn             |    1 +
 ..._4d15bfc4fc26e7249953bebfbb09e0aa._comment |   11 +
 ..._798000aab19af2944b6e44dbc550c6fe._comment |   10 +
 ..._707a1a27a15b2de8dfc8d1a30420ab4c._comment |   10 +
 ..._60d13f2c8e008af1041bea565a392c83._comment |    8 +
 ..._a6f48c87c2d6eabe379d6e10a6cac453._comment |    8 +
 ..._6ef2ddb7b11ce6ad54578ae118ed346e._comment |    9 +
 ..._6fd1fad5b6d9f36620e5a0e99edd2f89._comment |    9 +
 ..._af6fe3540032cdf4400478de87771058._comment |   30 +
 ..._8d3a0596db67108041728b20f2790f31._comment |    7 +
 ..._0a1760bf0db1f1ba89bdb4c62032f631._comment |   13 +
 ..._0327c64b15249596add635d26f4ce67f._comment |   19 +
 ..._7683740a98182de06cb329792e0c0a25._comment |   25 +
 ..._c9362141d15a2f68a75df9f8bfe29da0._comment |   17 +
 ..._8106196c3fef70652cb2106e2d5857db._comment |    8 +
 ..._47c682a779812dda77601c24a619923c._comment |    8 +
 ..._733147cebe501c60f2141b711f1d7f24._comment |   16 +
 ..._b090f40fe5a32e00b472a5ab2b850b4a._comment |    8 +
 ..._fc092412e99cf4c5f095b0ef710bc4de._comment |    8 +
 ..._d513e21512a9b207983d38abf348d00f._comment |   16 +
 ..._d68c36432c7be3f4a76f4f0d7300bac9._comment |   20 +
 ..._e6109a964064a2a799768a370e57801d._comment |   30 +
 ..._50777853f808d57b957f8ce9a0f84b3d._comment |   10 +
 ..._626a4b4bf302d4ae750174f860402f70._comment |    8 +
 ..._18a8df794aa0ddd294dbf17d3d4c7fe2._comment |    7 +
 ..._2ce7acab15403d3f993cec94ec7f3bc6._comment |   14 +
 ..._a93ad4b67c5df4243268bcf32562f6be._comment |   39 +
 ..._ae3ed5345bc84f57e44251d2e6c39342._comment |   14 +
 ..._c6b1b31d16f2144ad08abd8c767b6ab9._comment |   23 +
 doc/install/OSX/porting.mdwn                  |    7 +
 ..._cd2120552ef894a37933b328136fa4cc._comment |    8 +
 ..._740fa80e2e54e6fb570f820ff1f56440._comment |    8 +
 ..._a84028080578a8b60115b6c4ef823627._comment |    8 +
 ..._d6f1db401858ffea23c123db49f5b296._comment |    8 +
 ..._035f856923276b0edad879e196e94097._comment |    9 +
 ..._336e0acb00e84943715e69917643a69e._comment |   35 +
 ..._1befafa862b7d07b1f6e57c0182497cf._comment |   36 +
 ..._19c08b2c6c2c5cd88bf96d2bcbbd9055._comment |   10 +
 ..._537fad5d8854e765499d47602d1ab398._comment |    8 +
 ..._18d4377f4ded5604d395d73783ba82c9._comment |    8 +
 ..._6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment |   12 +
 ..._3d82a270dd4b0159f4aab5675166e1e3._comment |   30 +
 ..._b9d3563a2cc3d769f27876e028dc344d._comment |   12 +
 ..._2a60108a440231ba83f5a54b6bcc5488._comment |   14 +
 ..._d453510b9bb62072a4c663206c12c8a4._comment |    8 +
 ..._0970bfd63137ea48701dff6aea1b4bcb._comment |   18 +
 ..._8622ed56c6a8034c20fb311418d94003._comment |    8 +
 ..._ce58633ef5b2f8f4caa7e626358f33be._comment |    8 +
 ..._09084a7b3cf06bfa3add0f4991476ffe._comment |   10 +
 ..._a46d8e3e7795b9afb1e1c2be943d12af._comment |   10 +
 ..._203a36322b3c453c05c8906c64e62e06._comment |    8 +
 ..._874ff01f27911baf6ef0f559d5d5f5a0._comment |   27 +
 ..._38d9c2eea1090674de2361274eab5b0e._comment |   29 +
 ..._35bf3812db6f3ef25da9b3bc84f147c5._comment |    8 +
 doc/install/OpenBSD.mdwn                      |    1 +
 doc/install/RHEL.mdwn                         |    4 +
 doc/install/ScientificLinux.mdwn              |    6 +
 doc/install/Ubuntu.mdwn                       |   11 +
 doc/install/Ubuntu/Phone.mdwn                 |   20 +
 ..._490e065314693423ab6969d8ae6978fe._comment |    8 +
 ..._4ebac3fb43de854ed1a3b1d2ea94011a._comment |   10 +
 ..._38f69dffe2db0d15e4c4e5cb47f40ef8._comment |    8 +
 ..._7964374bb2332940677eea570bdb0b69._comment |    8 +
 ..._b511063001af2e2170bef657cf016ff2._comment |   12 +
 ..._4ea052431b49a0505b4a58a760054bed._comment |    8 +
 ..._b5dd1d73309e427d6e817a3a69beea74._comment |   12 +
 ..._d1c511153fe94bf33e19a1281f1c92f2._comment |    8 +
 ..._ad13886c1c1f76d1cd995ea7b7d8471c._comment |    8 +
 ..._a08817322739b03cf0fec97283b16f1a._comment |    8 +
 ..._fe0997e56136bd30749f0995cbf19b56._comment |   12 +
 ..._fbb5306a162db1a1ee9efa3523aac952._comment |   11 +
 ..._a97e7f0e62ac685c3ded423bddeaa67f._comment |   14 +
 ..._921a223fd7e679b9ced3d8ba5ce688e0._comment |    8 +
 ..._1f943cb084fa8e21bc6ee5fc3118f02f._comment |    8 +
 ..._c2f8b35ada873acb1ce593b04e2899fe._comment |   11 +
 doc/install/Void.mdwn                         |    1 +
 doc/install/Windows.mdwn                      |   37 +
 ..._39edee046193c7d36daaf245fa87007c._comment |    9 +
 ..._6310a850074cf65b1c0b5b49e2e5b582._comment |    8 +
 ..._3a7080a31d30ccb32fede56a98bb635a._comment |    9 +
 ..._6a998c400070059477de18a81a3ba0b5._comment |   12 +
 ..._7b5f0c6b31d9c409ea0989123788bacf._comment |   13 +
 ..._19226be8cae0c29b0e9a54cebcf1f17b._comment |   15 +
 ..._b4b60bed666355ace286775afe87860d._comment |    9 +
 ..._165ac8b0e1cd4f250e681eb88c0624d3._comment |    9 +
 ..._e0adfbf74754f847dc4705685cf00640._comment |   10 +
 ..._e5e5c7b75859493a7d94cbf7df746fb9._comment |    8 +
 ..._ef329ea100b36a1180e232a1f97369d6._comment |   12 +
 ..._10fb90bc434b4da189ed7235818ef30f._comment |    9 +
 ..._c81a36e387ca11050cf8cb977fff98ff._comment |    9 +
 ..._88ad2f657bf92e8c6144608612b9be49._comment |    8 +
 ..._90ef5d5a4f66ac3e440aadf302a625a9._comment |   23 +
 ..._0589dd8c33572dd1d0ef5cb7b29ebba7._comment |    8 +
 ..._35c66016c971a623ec86318adf7923b4._comment |   11 +
 ..._2687128ff7aa4b6f29e8b880b5d4d13d._comment |    8 +
 ..._0aa16754fb08d8f2a54c8c3f78b6c187._comment |   14 +
 ..._ba3985a5cbd9f5682807d2bdbb9874e2._comment |    8 +
 ..._9a2118d6f967585cb21f9d9b372f4017._comment |    8 +
 ..._a2532a0fea59d15a2efa11748ff0d70a._comment |    8 +
 ..._4ae37152bc9765cea921b436fb2785d8._comment |   10 +
 ..._bc273d60cb74241231183186aefbc147._comment |   36 +
 ..._1330a5413b720eca0103a0880d24eb2d._comment |    7 +
 ..._768498659909c37044f2b4dd08bacda3._comment |    8 +
 doc/install/conda.mdwn                        |   15 +
 ..._d9fbae3aca8853a13919350d405d686b._comment |   23 +
 ..._8968f1e04a08fb95644910089438b02d._comment |    9 +
 doc/install/fromsource.mdwn                   |  121 +
 ..._7ebe353b05d4df29897dc9a4f45c8a91._comment |    8 +
 ..._0d06702e6e0ae3cd331cf748a9f6f273._comment |   44 +
 ..._b93ca271dffca3f948645d3e1326c1d9._comment |   12 +
 ..._3dac019cda71bf99878c0a1d9382323b._comment |    8 +
 ..._14b46470593f84f8c3768a91cb77bdab._comment |    9 +
 ..._c3a5b0aad28a90e0bb8da31a430578eb._comment |    8 +
 ..._4faf214f97f9516898d7c17d743ef825._comment |   10 +
 ..._2a9d6807a3a13815c824985521757167._comment |   10 +
 ..._1efa0c7a963ec452fc6336fbe4964f6e._comment |   10 +
 ..._6f42f9234f9ff6a2ca6bbb4d2643843e._comment |   44 +
 ..._9d085e460553fa045999ab7cb945cdec._comment |   13 +
 ..._f04df6bcd50d1d01eb34868bb00ac35c._comment |   18 +
 ..._0f553be2a4c666e3bed58b2bce549406._comment |    8 +
 ..._f91a6ec21e96eced73ea9579fd8cbd15._comment |    8 +
 ..._2f27b78215f97ade1986ca806c634cb3._comment |   16 +
 ..._c34d2b1d95830a3e58671a5b566a1758._comment |    8 +
 ..._40cbde8ec067b3a860e6df1a9bea5f76._comment |    8 +
 ..._8a7664e6f9271718dc607a0782366c5b._comment |    8 +
 ..._bd455c732639728bce2bfc39e32871d2._comment |    8 +
 ..._c080e9239b6eec88d329c28da7bb4141._comment |   17 +
 ..._15951dd070a675300420eea137a28ef9._comment |   10 +
 ..._ac082dca67f4a29b06070c0283130f52._comment |   39 +
 ..._a69d17c55e56a707ec6606d5cdddee25._comment |   17 +
 ..._b7954521d9ab40622b665f278dd72e17._comment |   10 +
 ..._ad639c07cb79e89406e95c1dafce3a01._comment |   35 +
 ..._4763b24a29627d55f465b9ea260ea7ec._comment |   22 +
 ..._1d34c294486c85b1149675fa5861ae35._comment |   10 +
 ..._8d4dfc33cada6091c30d3a43ce404b8b._comment |   21 +
 ..._38451e751add6daf479b559c4b6a7c61._comment |    8 +
 ..._4d44e4531e6686bd340f26836ad40026._comment |    8 +
 ..._2a095a5af53a356bd29abd22a9cb1bea._comment |   16 +
 ..._f33e1a4575dccc20b0d3d7c00e6db709._comment |   69 +
 ..._5c1e96221154a4ae4ebd636232044ced._comment |   16 +
 ..._a86057d7e6d47113330f79e1812c3a5d._comment |   10 +
 ..._55bed050bdb768543dbe1b86edec057d._comment |   10 +
 ..._a3bf3ce57ea73515a059267f25b816eb._comment |   23 +
 ..._d9cccbb9620cc8218e72b5380fd89a05._comment |    8 +
 ..._954de34275d33bc4590927f911761563._comment |   10 +
 ..._6de25c1e450e1e3b1d18d2c76235ccb8._comment |    7 +
 ..._9c08300c5d172ba9223042a00c8acb2b._comment |   18 +
 ..._c8370525547b435d963a2c1192a21124._comment |   93 +
 ..._2ff7f8a3b03bea7e860248829d595bd1._comment |   14 +
 ..._765334858ef1eedff2c5d89ed42aa7f6._comment |   37 +
 ..._c1ce6084ba1e96afa30e18f0f6433aa4._comment |   10 +
 ..._514bac1020c4227a23380d1675184fc7._comment |   18 +
 ..._df7d36e4d169fbc4199026d7af1aa581._comment |    8 +
 ..._e4bb31024aa4a317be2f45667b6d6f9f._comment |    8 +
 ..._d7fabada8101596954ed7e401a8c460b._comment |   31 +
 ..._0592c3d36ab569cd777009a491e25ba2._comment |   13 +
 ..._13a198daa871e001b02b9df2e8d7c446._comment |   13 +
 ..._efac370d382fc79e1f207e8090e0f06b._comment |   45 +
 ..._64b44da5ec93fe4f50ad8b856823558d._comment |    9 +
 ..._4ef618a5de9b86ffa54ae849cbb329bb._comment |   49 +
 ..._4aea55dc5b24d84e0953382ccfea1a01._comment |   12 +
 ..._8789fc27466714faa5a3a7a6b8ec6e5d._comment |   24 +
 ..._55ec2dcb5e1b5e272fdd53aa063bc162._comment |    8 +
 ..._7fb2a70b6d39ad95ee701a99b9e19961._comment |    8 +
 ..._4cf71016c3b42ec972760a938031cbf9._comment |    8 +
 ..._dddfc7e7d2fa09008f538abde3213b45._comment |   63 +
 ..._c3195cbc42058593ea6ca9d2eaaf9722._comment |   16 +
 ..._663426a5014e5a38d477fb6fed411c17._comment |   16 +
 ..._849c4c2cfc34991c13d55495e391cce3._comment |   78 +
 ..._5655a80d206bd1f7cf1f326c645df7ed._comment |    8 +
 ..._059f1cd929228e131bf88d80aca0b573._comment |   24 +
 ..._444e529f8838ef127ff115eb6c2ef8ca._comment |  140 +
 ..._5afb2d081e8b603bc338cd460ad9317d._comment |   21 +
 ..._ab27934713fa6032ec9992f7e04fa9c5._comment |    8 +
 ..._3075af9a88b717c8ff1a489177e689f4._comment |   18 +
 ..._fb9581f4949efe1e8c90851fce9d61bf._comment |   10 +
 ..._bc163a82180b00a8b757edf269cebc06._comment |   24 +
 ..._473d320a05f08ce3cbe24789dcb01200._comment |   22 +
 ..._58dfd18135aa187d8b3977521ecff2d2._comment |   16 +
 ..._129c4f2e404c874e5adfa52902a81104._comment |   22 +
 ..._738c108f131e3aab0d720bc4fd6a81fd._comment |    8 +
 ..._5ddbba419d96a7411f7edddaa4d7b739._comment |   12 +
 doc/install/openSUSE.mdwn                     |    7 +
 ..._a5aea1ef644d0402d3caf593fef2456f._comment |   26 +
 ..._095d48e7dffe57421b2d3384a83d7183._comment |   19 +
 doc/install/rpm_standalone.mdwn               |   12 +
 ..._7d234e64f3b6e97cd6d91c339ebb0025._comment |    9 +
 ..._11f0fdc5be4fd6620732867070c53477._comment |    9 +
 ..._3a38ab16ca034025476b4df0a566b4a9._comment |    8 +
 doc/install/verifying_downloads.mdwn          |   33 +
 doc/internals.mdwn                            |  366 +
 ..._c4298babd96b2596bd4f6ad828212c92._comment |   31 +
 ..._9758bb3a17f63b4dcf51742ea482dbe9._comment |    8 +
 ..._f0325cefa5cd53a5a897046606137cef._comment |   18 +
 ..._e45b6fa035a30703618448a0f764f935._comment |    9 +
 ..._3f62751c2dd041f4ead1c6580ea5eec1._comment |   10 +
 ..._c3d12d14e4d044f39829c5d92f523655._comment |    8 +
 ..._2455c898d6c77a5437a2c1532144bb8a._comment |    9 +
 ..._df13b7e66963a6d2673e49f52afb978a._comment |   14 +
 ..._1adce7945940b9c384c2383261388dd9._comment |   17 +
 ..._4b8ed353dca4f484b3b6eb463fa02fd8._comment |    8 +
 ..._c19232d5cc4976c2e5b014aef6e8d9ec._comment |    8 +
 ..._5a26ee5aab274f321a4ea6f8527f53bd._comment |   12 +
 ..._81293b180fb09105ec158fdfef73d249._comment |    7 +
 ..._354012b6a9ac11160eb926234d38051f._comment |   12 +
 ..._7e40f744f9ac7f0403df9d1a2162a516._comment |   14 +
 ..._9c82a2878f3feb1b2a95662ed25b234b._comment |   15 +
 ..._9dccdd3a9556ceef54e318cd5c8a50ad._comment |   10 +
 ..._40442b012886ad698f448c262f0d7f4c._comment |    8 +
 doc/internals/hashing.mdwn                    |   44 +
 ..._9153e4f4f9335e524cf1b96a51bef41f._comment |   10 +
 ..._086ea37acf15e2a8694b8386222b73f6._comment |   11 +
 ..._19b7d20ca392078f14f9f10992f288ec._comment |    7 +
 ..._7642d6ce5fd4d37d464b05d0b4f869c6._comment |    8 +
 ..._b0cb207a85cda5a0ff2ea71caca22c0d._comment |   11 +
 ..._edb5c3388b5ac3481403c7accf9bb3f2._comment |    7 +
 ..._843592cf125be06fb316be43b85b0524._comment |    8 +
 doc/internals/key_format.mdwn                 |   31 +
 ..._4ec126bffafc81fae04e183874ffce39._comment |   11 +
 ..._1e46521ab48805c36233dbb69b11e389._comment |   16 +
 doc/internals/lockdown.mdwn                   |   48 +
 ..._caa8b378e8c35177083e6cc2f6937180._comment |   15 +
 ..._7bf74adb5556b7fc74a94e751c5fd3d6._comment |   13 +
 ..._caf6d5318703d188a2135737093d8323._comment |  421 +
 ..._0253bf642148ea853f6d1c8580e09db2._comment |   17 +
 ..._3d7ab5c8e813b21812b5132c708aad68._comment |   13 +
 doc/internals/pointer_file.mdwn               |   25 +
 doc/license.mdwn                              |    6 +
 doc/license/AGPL                              |  661 ++
 doc/license/GPL                               |  674 ++
 doc/links/key_concepts.mdwn                   |    7 +
 doc/links/other_stuff.mdwn                    |    9 +
 doc/links/the_details.mdwn                    |    9 +
 doc/location_tracking.mdwn                    |   30 +
 doc/logo-old-bw.svg                           |   60 +
 doc/logo-old.png                              |  Bin 0 -> 9092 bytes
 doc/logo-old.svg                              |   77 +
 doc/logo-old_small.png                        |  Bin 0 -> 4713 bytes
 doc/logo-with-cli.png                         |  Bin 0 -> 39440 bytes
 doc/logo-with-cli.svg                         |  107 +
 doc/logo.mdwn                                 |   30 +
 doc/logo.svg                                  |   92 +
 doc/logo_16x16.png                            |  Bin 0 -> 233 bytes
 doc/logo_32x32.png                            |  Bin 0 -> 473 bytes
 doc/logo_small.png                            |  Bin 0 -> 4749 bytes
 doc/meta.mdwn                                 |    5 +
 doc/metadata.mdwn                             |   49 +
 ..._d367fdaf0425b59d694bf16059d47192._comment |    9 +
 ..._e15d2b5a405db4ccdb91d6aad4a22983._comment |   10 +
 ..._50b17af1cf75ce88c4aef59dcd971b82._comment |    7 +
 ..._237721c5e8f66f303a1828810573a23d._comment |   15 +
 ..._fd30444aecfc4792eb4dbfdebc230786._comment |    9 +
 doc/news.mdwn                                 |   11 +
 doc/news/2013_git-annex_user_survey.mdwn      |    5 +
 doc/news/2015_git-annex_user_survey.mdwn      |    5 +
 doc/news/2018_git-annex_user_survey.mdwn      |    7 +
 doc/news/Distribits_meeting.mdwn              |   12 +
 ..._774494da38afecc425aceca21d047b5e._comment |    7 +
 ..._bbdde32c4bd9c7a1a62450d59a1e879b._comment |    8 +
 doc/news/LWN_article.mdwn                     |    2 +
 doc/news/Presentation_at_FOSDEM.mdwn          |    4 +
 ..._shirts_now_available_at_hellotux.com.mdwn |    3 +
 doc/news/git_annex_fall_of_code.mdwn          |   27 +
 doc/news/security_fix_release.mdwn            |   32 +
 ...rebox_a_FUSE_filesystem_for_git-annex.mdwn |   19 +
 ..._e238d1734238e37bb55ff952b32e06b8._comment |    9 +
 ..._341b567722797eb02bd96ffada431b0c._comment |    8 +
 ..._d6f6e7181f30094339a49ab420bee380._comment |    9 +
 ..._ab0d45c5058595a71656035c962c1143._comment |   13 +
 ..._b92045c91d92da7db794aed2c67dde0d._comment |    9 +
 ..._6f3b5d5a5781b3a570f46481dc2ebca2._comment |    9 +
 ..._6202ae898f24b3e02bc343d0fd2ac35a._comment |    9 +
 ..._884a0b9571544a95fad55cb5fc5963d8._comment |   15 +
 ..._32b5d0fb9c328fbcd8105dfa31f032d3._comment |   16 +
 doc/news/version_10.20230926.mdwn             |   17 +
 ..._6edf64272975935ac4874d7e8dd44390._comment |    8 +
 ..._b1bb446c48a4abc4df73354980f9f7cf._comment |    8 +
 doc/news/version_10.20231129.mdwn             |   22 +
 doc/news/version_10.20231227.mdwn             |   28 +
 doc/news/version_10.20240129.mdwn             |   24 +
 doc/news/version_10.20240227.mdwn             |   16 +
 doc/not.mdwn                                  |   70 +
 ..._d8fb9add7e98dadea2a39f8827f75447._comment |   10 +
 ..._6c23aba5a9c341f2d5e2007e4b43f2ea._comment |    8 +
 ..._a0ef1a045257659f0f8722e4987e0ccc._comment |    8 +
 ..._c5c20576388f18daba3af913b44fb001._comment |    8 +
 ..._837e3699014b73e8f2bd2a668eea9eef._comment |   23 +
 ..._ac7396ca125abb80a42f9aaaf61a6ab4._comment |   10 +
 ..._d2ae9613ad81508dbda6ed425d441ccb._comment |   17 +
 ..._ab41bec1ccc884e71780cb9458439170._comment |    8 +
 ..._0e19ff7deb5ed65f2bc685d4c516d816._comment |    8 +
 ..._bab9584c41a25dda934ad230e3eb732d._comment |    8 +
 ..._b2a0d5a45ab8ddd66c29dde9412d7a12._comment |   51 +
 ..._f2829ecbe80a61aa9a8411d2403de69e._comment |   14 +
 ..._547fc59b19ad66d7280c53a7f923ea08._comment |   13 +
 ..._581e23cca0219711f8a4500a8d5d20fc._comment |   16 +
 ..._5c61457f117de38ef487e5cc2780d554._comment |   24 +
 ..._69aa47398a3c13ce64f146de985b727d._comment |   10 +
 doc/polls.mdwn                                |    3 +
 doc/polls/2013.mdwn                           |    5 +
 doc/preferred_content.mdwn                    |   71 +
 ..._d9eb7d8efe731cbcdb456fc56935d886._comment |   12 +
 ..._f0bce3c67f293eaba97b92f0942876b6._comment |    8 +
 ..._fa7249ebbd7d5b499b486311c0a8f96d._comment |   16 +
 ..._7d45e21dfb016e9ffa4715346dd0c1a6._comment |   19 +
 ..._1ccd90b009245667ad59f4d29d2a3a37._comment |    8 +
 ..._384025b5fa23a3f175985a081438149f._comment |    8 +
 ..._6a9bc657bc7415f0e118357d8c6664c6._comment |   18 +
 ..._f0a957e67297c4bb5a8778c11b3c9fd4._comment |    9 +
 ..._b434c0e2aaa132020fd4a01551285376._comment |   12 +
 ..._c4acaa237bf1a8512c5e8ea4cdbd11b9._comment |   10 +
 ..._f82538be42428691d7cab60a7add2e74._comment |   13 +
 doc/preferred_content/standard_groups.mdwn    |  133 +
 ..._026e47e425d06c4b2580238b3187a379._comment |   13 +
 ..._460bae34ba7c05357318a202b2932d25._comment |    8 +
 ..._f5cd38886b58917fa3c417861fd10a10._comment |    9 +
 ..._22434bd01b2b9ce62ddc9fb64b18f8b8._comment |    8 +
 ..._9288dfe6b89885fe287db27cf941be64._comment |    8 +
 ..._31fa43557e7585dec5dd105531b0fc10._comment |   18 +
 ..._258ce07e607fa8eba80d142651393a95._comment |    9 +
 ..._2d4737488451f1376500098919652808._comment |   11 +
 doc/privacy.mdwn                              |   47 +
 doc/profiling.mdwn                            |    3 +
 ..._c1f99493f5e5c362d5c39f048280b11b._comment |   45 +
 ..._f4d802a28b79905da0cb24af6cb65b0a._comment |   42 +
 ..._1af4ac0d37c876912678522895c1656b._comment |   61 +
 ..._1ca8d9765e6e3a18ae09df74bc390a00._comment |   49 +
 ..._1ca8d9765e6e3a18ae09df74bc390a00._comment |   80 +
 ..._ca4ac016a0fb0132fc5c746dfb6fefb3._comment |   70 +
 ..._95f5afb616c7eba60473cdeb85a070b0._comment |   40 +
 ..._951c1c047ef414268295626218474677._comment |   29 +
 doc/projects.mdwn                             |    5 +
 doc/projects/annextimelog.mdwn                |   10 +
 doc/projects/dandi.mdwn                       |   26 +
 ...d_be_taken_as_is_without_obfuscation_.mdwn |   49 +
 ..._6450f220a0d4252ceafdd82f0cc24486._comment |   42 +
 ..._f787daed9b02af18b81f033cc2f84d0b._comment |   26 +
 ..._a1aeed36b8317144bc5df6fe7bcfd488._comment |   18 +
 ..._a32f922bb12d6cfd96c5116b20cff828._comment |   20 +
 ..._fad1fe49c2c545aeeb388176d2f5a893._comment |   15 +
 ...durl_failure_has_empty_error-messages.mdwn |    6 +
 ..._86b9cb50635c8ef8cf5918ab9a76d013._comment |   16 +
 ..._2a151ccc0d9ef464df1452adc6ca449a._comment |    8 +
 ..._1732be4c1d48acefcf3174cf8a7c8434._comment |    8 +
 ..._74e37e96d01bfb8b9521000d5faa7e53._comment |   14 +
 ..._1b87390e69204b42878930cc1614437e._comment |   26 +
 ...ke_git_and_ask_for_credentials_if_404.mdwn |   21 +
 ..._aa0be7b60156b1b8a036081b36d120e0._comment |   17 +
 ..._0bbf38af3012493cee0ada5248f32525._comment |    8 +
 ..._d36533f093ced2a0fa5aa74de492b69f._comment |   22 +
 ..._7f8537172df5da79bdedd66bdc5cd231._comment |  112 +
 ..._1993718701b7ad180ec683f80c87003f._comment |   29 +
 ..._a84145c6537ac1a81db59cdc03bc625d._comment |    8 +
 ..._3fd3445beec2a6cc6e8c71bd8e90cc83._comment |   11 +
 ...s__58___init_tests_FAIL_resource_busy.mdwn |   88 +
 ..._0c17cba36b1feddc956e0075f73536ed._comment |   23 +
 ..._33143a5f2467c58201496c8f59532b53._comment |   24 +
 ..._1241df23fa4861554cf9a5d65235c8a1._comment |   50 +
 ..._8c64d10dbfcd8189465affbf5329c63e._comment |   10 +
 ...tion_in_git-annex_does_not_try_chunks.mdwn |   28 +
 ..._5d11bb90105b4d0cf14f85e6d8795023._comment |   26 +
 ..._f48e4d3571a8fc2b45fbaad7a9f8fb60._comment |   29 +
 ..._ff3bcc2cce6e0cbbeef10a187541f5d3._comment |    8 +
 ...-lfs_remote_URL_is_not_recorded__63__.mdwn |  119 +
 ..._e2bcd52490fc04850738b72255692e32._comment |   24 +
 ...while_keeping_original_files_in_place.mdwn |   49 +
 ..._d385d0fffdd6ac18f38828f805e4daff._comment |   13 +
 ..._0c6006b53f97515c1ed31d8d4ab464cc._comment |    7 +
 ..._300f74178ef17e2e549fd7a04a262428._comment |   59 +
 ...1__git_is_not_working_for_unkn_reason.mdwn |   70 +
 ..._182b9cc42f7287c8b022422404fc74b7._comment |   26 +
 ..._0baadee49b21451a99a38306a98e3e56._comment |   10 +
 ..._d51bb87dc5ed0f4ede808c5a9594240d._comment |   13 +
 ..._ea413a9dec0243688cbfcaf8a5998ac5._comment |    8 +
 ...ad_downloaded___34__config__34___file.mdwn |  150 +
 ..._08af564539efb1b0d85905c0aa862c43._comment |    8 +
 ..._9a63b2918f5621efbfe8cdb33b23ff21._comment |    8 +
 ..._3df07b6c8ef25ad96ff4f198931347ad._comment |   31 +
 ..._051d22f0bd0eb601476cd3b74a9b98b8._comment |   10 +
 ...leeping__hash-object__processes__63__.mdwn |   48 +
 ..._c01d8d2e4aa2cb0d064ab223e615a75c._comment |   16 +
 ...tadata_cmd._vs._--json-error-messages.mdwn |    8 +
 ..._198df45c72d0c9b4997d1342ffb666ca._comment |   13 +
 ...ource_busy___40__file_is_locked__41__.mdwn |   44 +
 ..._14d5ba72397406620ac0a9fb05f2862d._comment |   22 +
 ..._6216c1eb6991cec787333284463fcc9d._comment |    8 +
 ...34__modified__34___whenever_it_is_not.mdwn |   96 +
 ..._43f1eec4aa317ff3b1a4fc18def96c6f._comment |   15 +
 ..._f8a54670d8eaf00624e9b8f85e803864._comment |   11 +
 ..._5cdddca4ca03216b68d443eeb49af581._comment |    8 +
 ..._68a79183b04b99d4b00b363e3cbe3f3c._comment |   32 +
 ..._5c03731700b2a025755fb06c9a96f331._comment |   30 +
 ..._df08c2530b890544d5eb2df792c8fd4b._comment |   12 +
 ..._4b8a360c38dfa4c8d22e3a96fbace0e5._comment |   33 +
 ..._5dead4bf9fe9a9c7627843c91613caf5._comment |   12 +
 ..._49e075aaa89e60fe1d35513dd4d4d755._comment |   46 +
 ..._2a08321045a8ede5c3b5a690232020b3._comment |   30 +
 ..._ac9c166c2b0c3aad8391abb56654ecf2._comment |   29 +
 ..._7d339e9a04a7c303949523b235a046ec._comment |   10 +
 ..._48819ddcb8713087c78db8941e4c1151._comment |   33 +
 ..._3186ec45f20c4d768c7682e1d42fa24c._comment |   58 +
 ..._927028d040b0e24d772b667324b1a5e1._comment |    9 +
 ..._64ba2901154b629a9697b427f3ad92e2._comment |   19 +
 ..._needs_more_depends_-_libgcc-s1__63__.mdwn |   72 +
 ..._93f4c8f86c58da7988bf1550867f8945._comment |   23 +
 doc/projects/dandi/done.mdwn                  |    1 +
 doc/projects/dandi/potential.mdwn             |    5 +
 doc/projects/datalad.mdwn                     |   30 +
 ...debug_is_not_in_effect_if_precedes_-c.mdwn |   69 +
 ..._0f66414e629e31c2de868f8b7eeb7af5._comment |   24 +
 ...__58___prop__95__view__95__roundtrips.mdwn |   34 +
 ..._3a2be0a1cd74c7dba3b07e1300ce2a30._comment |   17 +
 ..._1945040bcdf209b9a0faecd4a77e0f35._comment |    8 +
 ..._06dd9606225cf881f7681fc27fb4833d._comment |   42 +
 ..._0c6b8a3b0a6fbd700b3c8934bfec199f._comment |   19 +
 ..._c2f248745388b508337c5097baaa1979._comment |   18 +
 ...d_FS__58___Unable_to_remove_all_write.mdwn |   42 +
 ..._22a1f4b025a6046e4d11f90590a6e4bd._comment |   34 +
 ..._71e985981c14780cc172a07beb0e9854._comment |   10 +
 ..._ac3fe75560c020015ecca615cf0e7abe._comment |    7 +
 ..._3bdf724f5e9203424b7cb5630fb49a46._comment |   27 +
 ..._46acb87752c0f0574d8f3b91fdfb1697._comment |    7 +
 ...2_ssh_connection_prompts_for_password.mdwn |   66 +
 ..._f78784304b46b77d334f74c827d0889b._comment |   34 +
 ..._62a5cc7cd6b8b06850fb32b76121ad82._comment |   25 +
 ..._f621e615a745910b4e28f91b27132c0e._comment |   43 +
 ..._43e5a90d6215b414f4e3357ea91af663._comment |   21 +
 ..._27b5669cecba4863ce296049804e82af._comment |    8 +
 ...expectedly_becomes_annex_pointer_file.mdwn |   79 +
 ..._ea82bf47752807531870651653160f1c._comment |   97 +
 ..._27faf0663265bd3855e98f7f1f382bdd._comment |   42 +
 ..._37fb6d6361068f57c2068270ceb72ac0._comment |   16 +
 ..._4c3b233aa1c6b0b6c0b0d7519b5877a1._comment |   45 +
 ..._d1d23d3884fcbef3c8715ebdf8791f01._comment |   58 +
 ..._b713bf610c4f4d9c2463b61721bce406._comment |    8 +
 ...l_special_remote_stalls_after_7245a9e.mdwn |   66 +
 ..._c0a98d1391d4426182d3d43651ad67e5._comment |   27 +
 ..._952d0856b79cdf1637a84c74f396d9e8._comment |   44 +
 ..._ed02f45c96f7eedf2c15add673ca84f2._comment |   57 +
 ..._639337906e441523a610c7080f215aa8._comment |   27 +
 ..._746ffcf575f91bc3d156b279bcdf8ae2._comment |   20 +
 ..._e4f249bc78e870c91b3fcbf34596a9ed._comment |   11 +
 ..._a9b594ecd43c0d2f35029c934ba7e143._comment |   10 +
 ..._9fdcef0d78d04ce05765693fe296bb3d._comment |    8 +
 ...es_not_resolve___64__loader__95__path.mdwn |   15 +
 ..._138124e29ad5a27751fcd133e9dbf6df._comment |    8 +
 ..._4f68ed79045c93831cb8b41888057f29._comment |   25 +
 ..._72d271ac0612e13b3ceaf736e9e50fd9._comment |   10 +
 ..._69ae4b847873d039d790cd2b1cfa97c0._comment |    7 +
 ..._ca662cade7153349ce644cd93c379815._comment |   19 +
 ..._c75c9bcbcc8e68c60323dfde9c0248a7._comment |   13 +
 ...ing_because_MonadFail_is_not_in_scope.mdwn |   31 +
 ..._3ebe2e53fd8e8ce673267ac2715d964c._comment |   12 +
 ...ld_failing_on_Windows_since_ef3ab0769.mdwn |   76 +
 ...ils_on_Windows_as_of_commit_0a9a9c44e.mdwn |    6 +
 ...ils_on_Windows_as_of_commit_4b1b9d7a8.mdwn |    6 +
 ...ils_on_Windows_as_of_commit_a706708d1.mdwn |    6 +
 ...ils_on_Windows_as_of_commit_ddd7d1d11.mdwn |    6 +
 ...annex.largefiles_leaves_repo_modified.mdwn |  179 +
 ..._7cd205f8f5560420d117d5a2bde48532._comment |   14 +
 ..._725d46358366ea79e375fd47beac6acd._comment |   77 +
 ...with_wanted__61____34__anything__34__.mdwn |   80 +
 ..._03eebb6527c364552b8f81c12616e926._comment |   21 +
 ..._fded8e94841cb23a9d2715b00f63ae98._comment |   13 +
 ...lude_submodules_from_export_to_WEBDAV.mdwn |   37 +
 ..._43cde828704e54cad344c066ba1e2821._comment |    8 +
 ..._f1d89a826b5a2847328f6eec36b9f452._comment |   14 +
 ..._38d687454c618c3321ad6d9b3c4e7a38._comment |    7 +
 ..._8f31a065f5f97285adeb3f9614c1f3c9._comment |   10 +
 ...ype___96__Annex.AnnexState__39___..._.mdwn |   59 +
 ..._special_remote_on_GitLab_not_working.mdwn |  119 +
 ..._e821d8666ace3a760a2a335220844b29._comment |   56 +
 ..._3cdbe5b9b7150f9ad9fd5d7af01b247b._comment |    8 +
 ..._1dcf8d6a37bec46a7e7c2d9a65becf28._comment |    9 +
 ...es_being_converted_to_git_files__63__.mdwn |   68 +
 ..._e9f5fdf1078c87718fb6ca2559323b1e._comment |   18 +
 ..._5d0e1468f7ab2e8cd42452812d9ce49b._comment |   17 +
 ..._a9837edeacdf55c74d8fed2b8d7bf1f9._comment |    8 +
 ...rt__96___have_file__58__null_property.mdwn |   26 +
 ..._bf743f047b8063b8ecbd8c87d12fa475._comment |   12 +
 ..._d6e28d84238cb79c1df927da491f50db._comment |    8 +
 ...rtened_output_string__dies_off_with_4.mdwn |   42 +
 ...tch_for_compilation_errors_on_Windows.mdwn |   38 +
 ..._eb8d464da14af1fead372b4b61b20f17._comment |    8 +
 ...O_permissions_are_stalking_me_somehow.mdwn |   58 +
 ..._9e4ba1e03a89c219c5e62280757311ba._comment |   12 +
 ...stems___40__Xenial__44___Jessie__41__.mdwn |  167 +
 ..._d9dc3550012a618ba674119dd1163642._comment |   34 +
 ..._5dc1d7c54fc4768849d39affac51fcae._comment |    9 +
 ..._7cb4c4e1bc100e8f3241ece74ce463e3._comment |    8 +
 ..._a1bce716987b0d8d00a4a9aa07e9ac65._comment |   24 +
 ..._dd51471ec6a8f380663c62d6f9edb176._comment |    8 +
 ..._93e2dd2b30cdeddd5e273eae78a422e0._comment |   16 +
 ..._b2d1550e20e8c4cc07dbd0ebba64c603._comment |   78 +
 ..._5274e7f715ef060383046e8f5da08164._comment |   58 +
 ..._8976d014def1910f5140b1e5cdd37fb0._comment |    8 +
 ..._efccd6c930ea37f782cbd3b029f4fa71._comment |   37 +
 ..._282d1a5a2942820785b9cdacc1126545._comment |   20 +
 ..._34d7c2fb1b46f61e348a92f86a3d732c._comment |   29 +
 ..._279dfc4d611e2dbcb2523b9756f13a9d._comment |    8 +
 ..._815bf1b8985a49a0fafbcddc7c96f9d6._comment |   55 +
 ..._6f5e18dec962aba505ed15bed328f11f._comment |   17 +
 ..._bcc64259541b35eed34a63f4955884e5._comment |   16 +
 ..._contains_invalid_Windows_paths_again.mdwn |   15 +
 ...stems___40__Xenial__44___Jessie__41__.mdwn |  115 +
 ..._ce71734986fe4c86a43a5805628dd3de._comment |   59 +
 ..._8e7487f2f093e79dcce0be34274d7fa2._comment |   10 +
 ..._4ddca3bdc573ed3c7f6d846c4309ac2e._comment |   10 +
 ..._c480f7fad76759742bbdc4837d8c0c36._comment |   31 +
 ..._8a5b1e1cb4482fb787bde97a6066de59._comment |    8 +
 ...e_calls_to_git_repeat_--config_values.mdwn |   69 +
 ...etion_not_synced_from_adjusted_branch.mdwn |  124 +
 ..._6473d7eceae5141e36c87156044b9d06._comment |    8 +
 ...ot_propagate_changed_submodule_commit.mdwn |   94 +
 ..._5b56b989145a8ef6a6203e4df38e2288._comment |   50 +
 ..._e37aaf6d440b6c2a7567b3df1c344ff7._comment |   13 +
 ..._9e1cc48bb2125cc8fd375e3ff2f3310f._comment |    8 +
 .../Syntax_error_in_comit_f29d49d47.mdwn      |   31 +
 .../bugs-done/Tests_failing_on_Windows.mdwn   |  149 +
 ..._69e29a9c9b6690684ce1f4f8df3f3a2a._comment |  170 +
 ..._e95cf7f151ba51fd4324dc212afd5467._comment |    7 +
 ...n_v6_without_employing_.gitattributes.mdwn |  111 +
 ..._5eb0622b326a8094b06f5f0de627e288._comment |   20 +
 ..._a3b5e2047185bbd3972ada07ddb79172._comment |   31 +
 ..._db64ae67b8aa974bd6d00aad005058ac._comment |   31 +
 ..._5f11262639d60ef63a44de09b191e0b6._comment |   21 +
 ..._cfab68df294195498fe71daa376e9f68._comment |   15 +
 ..._e42f03c3e880dcd71d57bc2f6292d95d._comment |    9 +
 ..._045f90b5693de55958c6ad1b825cbc9e._comment |   10 +
 ..._ead7e348547da0598a82be8d064c0c08._comment |   36 +
 ..._ff0746f08600fb9729b8e1773317a52d._comment |    9 +
 ..._598622df322c56da71320d1b15e0348f._comment |   10 +
 ..._9707d9dda7ebb2c94c71f1ea2f99064d._comment |    8 +
 ..._56c8ddb604b54b8a5cfd077225971582._comment |   13 +
 ..._6b2a763f3d07f0cdc035008638e08194._comment |   14 +
 ..._5aa63bf0d8e4145974702a86b36bd435._comment |   25 +
 ..._5a22839b8dc11965a879dd2654bd5d60._comment |   76 +
 ...export_has_wrong_subdirectory_content.mdwn |   58 +
 ..._0598b1ccc9d7002d6b7fa08f29f8edc9._comment |   14 +
 ..._03ea7014854be4fa9f40a8815616b81d._comment |   16 +
 ..._e4b3597a6be74b10f03af3cdbc9ab4b2._comment |   16 +
 ..._aa11bebaa9ca341434fbc1382bbbbee4._comment |   34 +
 ..._22290ea94d5e547a199411d696657708._comment |   13 +
 ..._b6c36a9f466cbd0a09ae83ada7bc728c._comment |   41 +
 ..._201fb2f59e3143145f9f0b07a5f3ac30._comment |    8 +
 ..._e1051429a09bf5d7e5887d0eb378d72f._comment |    8 +
 ..._e50ed095c335c616b8e27fe20dae00d9._comment |   18 +
 ..._c1f5a71c217b965ece29fe8d9a01e6b2._comment |   10 +
 ..._b25f2c71675f4d8f6a6e22bb5cd98b23._comment |    7 +
 ...ToFileAbs__95__basics_started_to_fail.mdwn |   19 +
 ...ms_that___34__content_is_locked__34__.mdwn |   99 +
 ..._ddf822288da76a16eaaade2da51c5b43._comment |   16 +
 ..._00fa93b8a064bd1e6ca6c35b1a10d5aa._comment |   33 +
 ..._26e80ddbcb3f0c149e6565552558f6c7._comment |    7 +
 ..._5f9a1e4468a4531a7676d1b749ba0b9e._comment |    8 +
 ...ial_per-file_cost_for___96__add__96__.mdwn |   62 +
 ..._4e3cec5a4ce33dadfd0ce7a8d17bfaa0._comment |   12 +
 ..._f1a92680ab7874aa0c102cbf4b8a445a._comment |   17 +
 ..._e38a372b6d9f498160369a9c3071939a._comment |   20 +
 ..._26472db382e75e03cf10c6e5770ef42b._comment |   53 +
 ..._94d2048dcd33712e08f2206a5182b23f._comment |   18 +
 ..._0a170534b266ca55afbfcfe191ff18fc._comment |   30 +
 ..._7db34973cb362bee271545c3c58690b4._comment |   16 +
 ..._2e8e840cabbc547ef758568bb2779f9a._comment |   10 +
 ..._c89853eca5c16e9dfa4a4acc982ab526._comment |   14 +
 ..._8623b98bf21427ae5734d74e2576af5b._comment |   28 +
 ..._281ded4caa0dd407431b205ce6746c05._comment |    8 +
 ..._cc08c222cc36e3a0462f370df12eb129._comment |   22 +
 ..._1c001d885bd4d7f60b3260d494406e5c._comment |   16 +
 ..._cedee281d3f6f97499e70dacd0560f70._comment |    8 +
 ..._80c5ec6993e8a720fbd1841fdd21e311._comment |   68 +
 ..._85f07d906b836ac968ab877258180c0c._comment |   33 +
 ..._0d2ab75208877136534040b726c7f97b._comment |   62 +
 ..._891b532bd662b1198351803b82ed634e._comment |   21 +
 ..._3947b44c88820da49d8a2d1afd3595ff._comment |   12 +
 ..._1c867ba26de03f921dd347c14b8ec402._comment |   35 +
 ..._4ee757b45706816c3296dd4b29f05fbf._comment |   69 +
 ..._b46545c78628379dd50d306c87550b9d._comment |   58 +
 ..._409a95cb01a4b26d46d7aaff042026a0._comment |   44 +
 ...ws_build_failing_as_of_commit_cb7bb3e.mdwn |    6 +
 ...ests_failed__34___on_NFS_lustre_mount.mdwn |  138 +
 ..._61c1fe6f14a30082a325c0efea9632f6._comment |   20 +
 ..._541e257ea04d6a7647a337998d79232c._comment |   44 +
 ..._80b15bc4e0c8c9ed4680da9408c1d559._comment |   12 +
 ..._8f305fa196210899d2215324849a8fab._comment |    8 +
 ..._66d72d1d214124eaa57681df21b9b121._comment |   18 +
 ..._6354d1e144830bea5a0d7872f698ccc0._comment |    8 +
 ..._945d45b37b0548deacddab19568dd5b3._comment |    8 +
 ..._4e89c558748c370e8bbb1ef50f4cdcf7._comment |   42 +
 ..._1c0abfb39eafb73527c99dd56b41c0bd._comment |   19 +
 ..._ff06b532b0ec6edc17ae26a7a80233af._comment |   15 +
 ..._86eed28bf04fd293851afcbea5312271._comment |   22 +
 ..._71f5f1704b97cf4e809a55a71e9da3eb._comment |   14 +
 ..._78258166fed7a555e59ed2b78143fad1._comment |    8 +
 ..._1219295230f196c00744058ed3441a98._comment |   66 +
 ..._640a2685ca0efb7367da6bc502354735._comment |   67 +
 ...ailed_to_send_content_to_remote__34__.mdwn |  222 +
 ..._755703a901687283f1a9b3bfcdf1ea68._comment |    8 +
 ..._539c272450ceb56badde88702afb4e4d._comment |   23 +
 ..._67567cf57d9b7d57fb5e10ff7a54a99f._comment |   17 +
 ..._a4643d9f91947714b6105ca81164cb26._comment |   10 +
 ..._41f1271bdc7a4d62b30f6254a0f6ffd6._comment |    9 +
 ..._0d6bfbc5539ef2083e0bc2e32762a9c0._comment |   29 +
 ..._6ef33d110d709e46768549c59b02841a._comment |   16 +
 ..._7c7b953b2366fbfc1b95cc6048473ddb._comment |   27 +
 ..._eb8b597167a6708a27ac03ef4fbf3632._comment |   31 +
 ..._9a1c92462a5393155298d70ef90d3019._comment |   11 +
 ..._c36b1968c69e9794c723ff29d1738759._comment |   14 +
 ..._e6ed93310ad694f6c52b52530c63f8f5._comment |   14 +
 ..._79ccde86a33f486b77857720d97185f3._comment |   16 +
 ..._4b6cf4221ff9d4f106d595f2897ea85f._comment |   35 +
 ..._503d0507c55412ca8c625b32feb7f80e._comment |   20 +
 ..._4345e2d7f30318dc7565e90ac8578086._comment |   19 +
 ..._5b1148d1d771b71f6af654f974dbf427._comment |  144 +
 ..._ac650ab647f5fda2623a958b30b40c18._comment |   10 +
 ..._af8d80956d3ccedfe9aeb0fe22b2592a._comment |   27 +
 ..._93cb28a06189d349a59d8d79c44d3b51._comment |   15 +
 ..._d76a32758b58695dcef7d4ec83abb1ea._comment |    8 +
 ..._40094333a89de09f7e64ca715ba20f16._comment |   11 +
 ..._4da389b802a114dc18e0264a4df36dee._comment |   16 +
 ..._c43d7b153cc8b68f31ea007922326ee8._comment |   24 +
 ...k_error_when_link_is_upstream_of_repo.mdwn |   81 +
 ..._a2d1112b0a9338b7c093546a985a5f90._comment |   51 +
 ..._c6e30af134a73bc8b3faee83c7c3b378._comment |   11 +
 ..._9ac6e3436ab4866993ebf4e469b13636._comment |   12 +
 ..._efe4490c33e874bd78fd567c70874088._comment |   41 +
 ...39___failures_introduced_by_75aab72d2.mdwn |  142 +
 ...__N__39___can_land_on_unsupported_N+1.mdwn |   53 +
 ..._c67521dc54f12efbbf7e13c828775e30._comment |   23 +
 ..._d65fc129524c92fa1c783d8dbc516f5f._comment |    8 +
 ...e_introduced_a___34__regression__34__.mdwn |   62 +
 ..._0bc5a3d36900d9bd8c978a08383d409d._comment |   10 +
 ..._ecc658185b485a5ccaf592ab8a255241._comment |   14 +
 ..._38baec012d7ebc95f92df59c85c6d525._comment |   11 +
 ..._ee9f695290b1bcaf2c9320d8042047cc._comment |   11 +
 ..._3fb410419608d725ea15a4849266396e._comment |    8 +
 ..._2455f440750a285768746e764fbfb9cd._comment |    8 +
 ..._c8f6ee2cb993b22b2531d1a4b7c3da8e._comment |   12 +
 ...ce-small_fails_on_modified_submodules.mdwn |  128 +
 ..._95e4a43684338e28a74b6df8d2e5281a._comment |   14 +
 ..._annex_into_git_in___39__addurl__39__.mdwn |   42 +
 ...dd_file_into_git_until_pipe_is_closed.mdwn |   99 +
 ..._correctly_if_non-annexed_file_exists.mdwn |   22 +
 ...o_talk_to_ssh_remotes_for_some_reason.mdwn |   22 +
 ...redownload_even_if_it_already_present.mdwn |   33 +
 ...-ssh-options_dropped_since_8.20200330.mdwn |   50 +
 ..._2ba303f406a0be7c3bb4a8466ce4b9c3._comment |   10 +
 ..._d3fdcfe9e75f2fa6a7c4d12e318455db._comment |    8 +
 ...t___34__in_effect__34___in_thin_mode_.mdwn |  113 +
 ..._cc1417bb8173e3b2636d465967a704d9._comment |    9 +
 ..._60ab40449991dbb3f64d08f01c5458c4._comment |   47 +
 ..._86e8f44191a004da20db8e97577744a9._comment |   11 +
 ..._d6039a6d2df740600e98b50fe90fbdfb._comment |   10 +
 ...ex_add_ignores_.-prefixed_directories.mdwn |   79 +
 ..._path__95__to__95__repo__34___is_used.mdwn |   84 +
 ..._b90f22ce0ab931658856e949ac227985._comment |   23 +
 ...lity_on_a_http_url_redirecting_to_ftp.mdwn |  132 +
 ...--batch__34__ed_but_not_yet_committed.mdwn |   67 +
 .../annex_get_-J_16_via_ssh_stalls_.mdwn      |   99 +
 ..._4b053c393627e2efb746a2b81838e518._comment |   21 +
 ..._e8ff5342533744617248104b04aa227f._comment |   29 +
 ..._7b5857e8415f386813b1b174e39e899f._comment |   14 +
 ..._552c0283748b64d84e84f5117f697d3b._comment |    8 +
 ..._7e3f849312d824cfbd10cce1f024c80b._comment |    8 +
 ..._666dcda30f5a34588c4357c3fa43e8d8._comment |   66 +
 ..._39227b7dc49d141556680980aa558318._comment |   55 +
 ..._c39c3b0978777987dcd8c86906aa6532._comment |   16 +
 ..._bffd59a35ae162f4141b6de7efcc7422._comment |   11 +
 ..._b3fc7c5f6acfa23b6bfd0f709d2f6b96._comment |   20 +
 ..._4916bb94a700e72d42302d2938693daa._comment |    8 +
 ..._3070880ace124795e07c4f8d1f47e81b._comment |   23 +
 ..._797c40af56ddb435db3d4affa86d49a2._comment |    8 +
 ..._35fbdb89eb658439e4125c22a04173a7._comment |   16 +
 ..._301141057296da0e01fcc622b4f14dcc._comment |   69 +
 ..._1c96a68c27ba09cd1f8c035dd026582b._comment |   14 +
 ..._d107200df348bc2b97e2fefc4342e49a._comment |   13 +
 ..._a3d803f25795365c9651d2ec023d9145._comment |   25 +
 ..._0f2e6c7dbfbb3007d4e3f7faa63d16b4._comment |    8 +
 ..._0812ef7942034a4ece952dd8069813a3._comment |   10 +
 ..._c18ec0797bd55780a0851c3b0c71b184._comment |    8 +
 ..._8d391bacf291492846d9253057653082._comment |   12 +
 ..._2bee4762be30b9864083ed1d32fe942e._comment |    9 +
 ..._6f228fa6770aad308d0f99647ac21347._comment |   26 +
 ..._3eaebe28f2925cac21a49f30aed3fa3c._comment |  239 +
 ..._c31884e8d52324c0e04cdbbee42d4d35._comment |   43 +
 ..._0707380cc043d9bbb84f0232eb1c1322._comment |  105 +
 ..._f7fd86a45b6d5440cdd0588ebb8753c8._comment |   21 +
 ..._7eee5a23aa67cb156aa31fe9fd92dd50._comment |    8 +
 ..._ee7333607930d8e3fbd4cca2b974c55b._comment |   68 +
 ...should_retry_failed_downloads_from_S3.mdwn |   62 +
 ..._1cbef11391d23210230872a75f8e5414._comment |    8 +
 ..._4de90238d57de0d49b75418411135dbc._comment |   18 +
 ..._5da78a05b781029fa7f0f9d8ead7e093._comment |   61 +
 ..._b279da2a2db1ba5a24a76a9112e691aa._comment |   11 +
 ..._089f1d2d7de435a98dc1098ebf1cf3df._comment |    8 +
 ..._3b840d50a1ecc9cb6e161e3c039fe332._comment |    7 +
 ..._2c83482ead69a902c99fca3ae63dfc34._comment |   15 +
 ..._51f6745c4abce7b3cdfcf1c5998f8329._comment |    8 +
 ..._d8ccfe3fe0d5123c1065ace73b623b44._comment |   20 +
 ..._df98c47016e79f15218880a009e671ea._comment |   14 +
 ...re_of_files_added_via_addurls_--batch.mdwn |   46 +
 ..._4169fceac6ef95400ddc79652558dc13._comment |   20 +
 ..._c479f19eb55dce35364eea30d0b727b7._comment |   81 +
 ..._f694e35efa09aa60daf17d63270968af._comment |   17 +
 ...ctually_update_local_branch__47__tree.mdwn |  117 +
 ..._6fb5a4fec435eccc0528744c55b7468c._comment |   15 +
 ...e_to_add___40__null__41___to_database.mdwn |   36 +
 ..._9c91eef41c51737f85d4df3c737fc6c7._comment |   14 +
 ..._f6759af83ddd62293593a276e089188d._comment |    8 +
 ..._798629780fa04dc1a8bf1c21ca813d40._comment |   11 +
 ..._b7c2abf63c9f350402b3176e028bda03._comment |   21 +
 ...61__true_seems_to_not_work_any_longer.mdwn |   82 +
 ..._457027471d09aa4ae8718c1508cfae1d._comment |   27 +
 ...7__git-annex.desktop_gets_resurrected.mdwn |   13 +
 ..._020c0c7a51638cf28efc518da4ccdb9d._comment |   13 +
 ..._0378843b9c7281d587304ac9c42d46f5._comment |    8 +
 ..._935f2fe1f7ff1a46b1038cd4458317a4._comment |    7 +
 ..._5bb365e15cd27002b0104d9eb9b5f28d._comment |   13 +
 ..._operating_on_a_clone_with_submodules.mdwn |   64 +
 ..._86b409dc4b7824f601deeed0a14cc8e4._comment |   11 +
 ..._f5bf66e8494b4ee2c6da7f3a6de8da18._comment |    9 +
 ..._40__e.g._application__47__json__41__.mdwn |   24 +
 ..._a18cfae149effed2375b3b0be021ac3a._comment |    8 +
 ..._08448687578634b6281ea285f18d87e7._comment |   23 +
 ...ead__95__write__95__transferinfo_test.mdwn |   22 +
 ..._e9db58f71eedc99ccfd7a7a446843316._comment |   31 +
 ..._make_annex_happy_in_freeze__47__thaw.mdwn |  179 +
 ..._07ee2e1b3e0bf8959001c22273a71afe._comment |   24 +
 ..._ad34ddcf5bd0466b66eb1b93f65297fe._comment |   43 +
 ..._223df2a9cebd99a312537137863b1781._comment |   19 +
 ..._c78b91393ca917f9d231c39702c70e14._comment |    9 +
 ..._1bf2ff8d5ddbc8121ea69a5f4042f190._comment |    8 +
 ..._e12bd42ef9690d3bb74236d55da66bff._comment |   55 +
 ..._f0a3a944479e52a7789ff9a346001a6d._comment |   10 +
 ...standalone_git_annex_within_afs_mount.mdwn |   25 +
 ...ile_status_to_be_committed_to_git_now.mdwn |   73 +
 ..._ad19d064dd9c175debe647a6928e4f35._comment |   16 +
 ..._19de1d89dd0a266ce43e0f25cd2b74cd._comment |   12 +
 ..._92b71940fe9d00bf58ee08b327f4a991._comment |   55 +
 ..._010b0b10ce6f9cd2b9a3f9847ff2a91a._comment |   10 +
 ..._8ab0f0852a1dc6c51a502f07faba61eb._comment |    8 +
 ..._7081b1386ca8807dff79e8613088b619._comment |   17 +
 ..._d987bcd1f589cd9f19a4df92461f9e1a._comment |   15 +
 ..._a9100e161d004729db9e3157fcb78343._comment |   18 +
 ..._220be99862a8a24263bd5f5f27988a1c._comment |   13 +
 ...ing_pathspec_with_git-commit_leaves_s.mdwn |  119 +
 ..._a71ce38ec25075ac7037550094da2bf7._comment |   44 +
 .../change_in_behavior_after_8.20210621.mdwn  |    7 +
 ..._ba8a5b590d2f690bcabeb63c0ef6f46c._comment |   13 +
 ..._28ea6b8a7addc23f2eaf5626705fc789._comment |    8 +
 ..._bd3faa20f746fcf4fd99a011b7453b38._comment |   18 +
 ...j__in_copy_for_--json_--json-progress.mdwn |   19 +
 ...commit__61__false_as_of_recent_change.mdwn |   95 +
 ..._793ab4d52a3a4a3a30b0e72b72ac18eb._comment |   18 +
 ..._1c0e6f07f1da2872455401ac97c4ccc8._comment |   36 +
 ..._d064cceaaded97ce52169ca176959187._comment |   11 +
 ..._8209bed5e7c10f74b3ac17c368c92023._comment |    9 +
 ...t_some_failed_copies_in_--json_output.mdwn |   28 +
 ..._4ed0e29f0b599135b1b1c9197d58873b._comment |   15 +
 ..._cae2883d41b495a6722a7039f0ec2726._comment |   45 +
 ...ks_samples_as_well_as_stock_git__63__.mdwn |   62 +
 ...stem__58___SQLite3_returned_ErrorBusy.mdwn |   90 +
 ..._b96755e44bedf262cbb32403f8edaf0b._comment |   21 +
 ..._9356da08c06aeae254fc84e44b0b3d14._comment |    8 +
 ..._918ed48f23dfdc1fc95e3df9526b489c._comment |   16 +
 ..._baafac7f80ff4b7cc4cf078e4ab969c3._comment |   21 +
 ..._ac112e35d792bdaeff268aae7ef0dc6a._comment |   40 +
 ..._e1c7bd12aba40c6d9e9c039fa0de8631._comment |   11 +
 ..._e524de262247edc4c541ce3af92c48e0._comment |   43 +
 ..._1e0f10f694f7d07c0ab75136daec669c._comment |   20 +
 ..._bc9b8c1b80a3308c997fdccbf8465f08._comment |   22 +
 ..._21e8b47c5f100196f3d2062001a484d8._comment |   61 +
 ..._36f796f2ed8cd91716ee5a083e5a5ace._comment |   19 +
 ..._0d34bfeab48421e35c6880bca639cbb2._comment |   16 +
 ..._d0d441c94af2fe63ed1b20fb031181a3._comment |   15 +
 ..._annex-init_crash_when_remote_name_is.mdwn |   55 +
 ...es_not_workout_on_unlocked_file__63__.mdwn |  121 +
 ..._f5f0bb494672fb6b959c2a72a042467d._comment |   29 +
 ...ption_value_passed_within_arg_for__-c.mdwn |   27 +
 ...__47__XX__47__YY__47__KEY_dir_behind_.mdwn |  198 +
 ..._ef17dd348b2404000c29e7b41f1e5253._comment |   26 +
 ..._51a060d64f2dead1aa030596b0b34bc8._comment |   17 +
 ..._6c79c41676318bd976eff9988463d167._comment |   13 +
 ...h_--json_--force_is_always_succesfull.mdwn |   36 +
 ...s_reports_in_parallel___39__get__39__.mdwn |   25 +
 ...mote_stuck_with_a_recentish_git-annex.mdwn |   26 +
 ..._1a3d3ade491f97e68a7bfcd853062875._comment |    8 +
 ..._d53e63d817a71ae88580c5b08ce28956._comment |   71 +
 ..._435c4cad7d3837aa09292642b983f041._comment |   14 +
 ..._afc2af08abebba808886464fbcd0b9d7._comment |   16 +
 ..._a532adc63a5ad97ab37a0a775cda0d0e._comment |   10 +
 ..._ba2420e2d8f41dbdafc839246b8362aa._comment |   15 +
 ..._8768afda308d5afeee2002f53f5cbf2c._comment |    9 +
 ..._06103ccf5423718b35d35d6b2e4f04d2._comment |   15 +
 ..._e47d2cae9fa224bef2433eba4d21ec7e._comment |   15 +
 ..._de71be6bdc853567ad52a05c591b3bb5._comment |   36 +
 ..._36b91cb600c0a14dedd58e91e97132d5._comment |  100 +
 ..._2a15295f0a6f907d684ca5a7134619ac._comment |   15 +
 ..._e7a571699a2e564bb8364e353d9a1245._comment |    9 +
 ..._362351708d543f1d219dfcf8d71b5a14._comment |   32 +
 ..._1fbf8751d378f4e838e7f5ba6b43a6ca._comment |   13 +
 ..._03d750b6461b965b33e1e4bed1242658._comment |   10 +
 ..._3f8ca763326523a79184192332107879._comment |   14 +
 ..._be_treated_as_crippled_already__63__.mdwn |   98 +
 ..._a3111068628efcfe8c5dbbe653805481._comment |   26 +
 ...nvalid_object__while_setting_metadata.mdwn |   28 +
 ..._d027727bb0063e82ef9f92c8558e191d._comment |    8 +
 ..._e7d11326148bf27a0233d36e26e08e6a._comment |   12 +
 ..._3ef1310132adf09cd426e49c93503a88._comment |   23 +
 ...son_record_with_--json-error-messages.mdwn |   29 +
 ...S3__58___transfer_already_in_progress.mdwn |   98 +
 ..._f81e00b5293f2df894dc3cd1678530c1._comment |   16 +
 ..._0efd2da2e467c0607d1903ada98a3f20._comment |    8 +
 ...import_fails_on_crippled_FS_on_ubuntu.mdwn |   30 +
 ..._fcf8372714c74e5001b5a18c7100c7a1._comment |   18 +
 ..._1fb916ff03e0b8c96c554caf1558ecab._comment |   15 +
 ..._18d4577c331bceceaffed7518902975a._comment |    8 +
 ..._d949841feb6a035e20a3d0f31634d388._comment |   30 +
 ...t_where_versioning_info_was_forgotten.mdwn |   95 +
 ..._917b46d9ca69c4e8181d041d5414d373._comment |   22 +
 ..._363c4a87018de7be3286d88d0d5f8ebf._comment |  231 +
 ..._1fd43cf6dd14f50ef8087f0b22ad640f._comment |    8 +
 ..._4a4d5b62af4a42ab9072ccaa6d8bed7d._comment |   18 +
 ..._6c1e74df4c7e566c4c1ba43fbbbd3beb._comment |   14 +
 ..._http_while_wget_fetches_it_just_fine.mdwn |   52 +
 ..._fa6649208f1882a6bb412ba40cf57fec._comment |   25 +
 ...ch_reports_files_that_have_no_content.mdwn |   68 +
 ...s_with_--__123__un__44____125__locked.mdwn |   84 +
 ..._d0dcd56a0af59bb53092c518a4e3eefd._comment |   21 +
 ..._3f1980c96f795c30886b3decba69819d._comment |   10 +
 ..._5299bafc9ae75788d2e7e9aa7f48d00e._comment |    8 +
 ..._b68abf3a46bf0137c02e439c58ce0014._comment |   12 +
 ...34__trust__58____34___-_trust_failed_.mdwn |   17 +
 ...e_directories_for_pointer_files__63__.mdwn |   96 +
 ...7__fix_some_key_directories_correctly.mdwn |   46 +
 ..._1d627cb46d9ecdf0b526a9c8e9764011._comment |    8 +
 ..._eb7c6445b1ca53d5552506d8ae93b5d4._comment |    8 +
 ..._c7d43b06f88d2000fcf574ebab971ae1._comment |    8 +
 ..._9d7c83cfb6154bdfc51caae00da4c4b7._comment |   38 +
 ..._09bb754f4e7e19cd52d68f91368f57fc._comment |   12 +
 ..._3cba6bde1e5c1e978519672bf4c2d33f._comment |   11 +
 ...get_works___40__with_https_urls__41__.mdwn |   55 +
 ..._a9aee679a5069dc8ee8960e975bf020b._comment |   27 +
 ..._f1e97aa8b9927c01e3365b940061d3c2._comment |   10 +
 ...___getFileStatus__58___does_not_exist.mdwn |   22 +
 ..._83448258af56b5872a9530cf60c72eb0._comment |   20 +
 ..._92dec3e0c31ffbef1a70ea3038ba6ca1._comment |    7 +
 ..._ab590b41983d84c8fe7d5dc7276689b8._comment |    8 +
 .../bugs-done/get_-J8_resource_exhausted.mdwn |   54 +
 ..._61622483d4f1962f191fb6a791c6817d._comment |   15 +
 ..._ccc6f5f1ac5743b0857f68cf21eaa6ea._comment |    7 +
 ..._5f9e9600d65c1270b479cc8910d507d0._comment |   26 +
 ..._54cf519a09cfaa0c85d60734daf58d72._comment |   26 +
 ..._132ea480f90af577e3cad67f2f01c73d._comment |    8 +
 ..._06e99c29eaa770ab96ea5fd832ee04b8._comment |   55 +
 ..._0e7b492da14e067c34693b7be02e6864._comment |   14 +
 ..._db1ae584fc803c0dbb48c7e31a540c4e._comment |   21 +
 ..._f584dc15789b371569e1925c4ee5ae36._comment |  127 +
 ..._83eccac19016c971f1b799d935a4c0bb._comment |    8 +
 ..._5db907d77c5f5490c1bdc8e51387a9e9._comment |   27 +
 ...lready_in_progress_..._for_some_files.mdwn |   33 +
 ..._57844bc289adacc6a53162cd224e6df3._comment |    8 +
 ..._ea5d3efc56b70de03a5b0b5e908bf11f._comment |    8 +
 ..._ed5fa01a2263ebb4a24bfe0e46ee820f._comment |    8 +
 ..._5964e40963325975e5de37506a2852ca._comment |   11 +
 ..._64705f2eddbb6fcb55edc797bbd3b22c._comment |   36 +
 ..._e51841ae57dd9d2f48cd21fbdb90ac29._comment |    8 +
 ..._2f7f87db7ca4d379d439ab88bdeee5b5._comment |    9 +
 ..._36bcdc23439c4f19c5aaedff85213db0._comment |   10 +
 ..._7ce83c16509bd42b2460ce59470f70c0._comment |    8 +
 ...__34___to_get_files_with_the_same_key.mdwn |   53 +
 ..._5b3879d1bb992ddf2aafa3fcb41b968f._comment |   19 +
 ..._af7078b291d99569070f6a76579787aa._comment |   10 +
 ..._86e1be495262a7f57428e92eb27a559f._comment |   47 +
 ..._3428942e9b52091b2297cd9823f17219._comment |    8 +
 ..._525ac8695b6253fc435112f336238c41._comment |    8 +
 ..._5f2ed95bcad2e3d1c4260d1fb0440052._comment |   19 +
 ...ed_with_password-based_authentication.mdwn |   44 +
 ..._236d2b897a550e7db4b266814d4e778d._comment |   25 +
 ..._c877de08f959dee4ace34e66f42c8615._comment |   21 +
 ..._daac1d424bc9e5b56772fa49707bc5a5._comment |    7 +
 ..._05bf20db275b911e2d89311182f289f6._comment |    7 +
 ..._b094509fe0194313666b5b1db0a68156._comment |   14 +
 ..._f5fe8d4cecfceec5cb4a03dd054d2e0a._comment |   42 +
 ..._0118a107147f6b94a7da907e599e58db._comment |   15 +
 ..._5da63cf5fa93120c85b98077fba51488._comment |   11 +
 ...tries_to_lock_in_home_directory__63__.mdwn |   50 +
 ..._362a858ce78fa0b8d7949fb39fb247d9._comment |    8 +
 ..._3f985fc652c9a15b5989cc82cb5da1ad._comment |   29 +
 ...nly_in_--debug__41___with_rsync_error.mdwn |   83 +
 ..._d30e7f8eecfb73f2f97ec87285966f21._comment |   10 +
 ..._6ec6e02bfb94b27b8da1ed68e4f9f121._comment |    8 +
 ...____41___-_lack_of_further_debug_info.mdwn |   94 +
 ...y_explicitly___34__annex_init__34__ed.mdwn |   78 +
 ..._dee4b1e8c5cc15a5d362df3b97a886a8._comment |    8 +
 ..._16bf63e639626f5dfedd6f3809216747._comment |    9 +
 ..._3b3dc5b946e405955b68b0c4c3d7df3d._comment |   47 +
 ..._91cdb022987aa3a8852a82ace092a929._comment |   10 +
 ..._b2c7517a7482071111514a68c70ce8dc._comment |   22 +
 ..._76433ca072233f8cd24600d3e45f97c5._comment |    9 +
 ..._21dbdbf7e4e889dc7c2475a0b9d4c5d7._comment |    7 +
 ...__58___hClose__58___resource_vanished.mdwn |   69 +
 ..._dd7883772bb37fa85aa1332633184071._comment |   18 +
 ..._375e6d23c43a2cc0ef8bb81b06c3bcc9._comment |   47 +
 ..._032dfcb0dc7e5c54a0cbc6634ad77268._comment |    8 +
 ..._1c079d165831b790676dc6bec0549773._comment |   21 +
 ..._d83330ad40f4f2c2c55f29acf6680620._comment |    8 +
 ..._129a1946d7c76b89ae2f45b8a804959f._comment |   10 +
 ..._1713d56b81db533db4532f2a79250c87._comment |   21 +
 ..._a14f999b63905c1f29999bd68ded42f2._comment |   16 +
 ..._31ecf1c31511e6454a274e3c9a9bef75._comment |   26 +
 ..._3aecc3467427b4ebecbd53012e111004._comment |   42 +
 ..._dfb1b7ee4e674cf18d6f41e4f4b6c879._comment |   21 +
 ..._trying_to_move_under_NFS_and_pidlock.mdwn |   43 +
 ..._d44de6a250694b25ce9c3169d62db8d1._comment |   20 +
 ..._56ae0f15bbdea2331df3b261b74d0b0b._comment |    7 +
 ..._d499a2f44e8ee2f39ee959f4d6373570._comment |   13 +
 ..._05687dca2462eb79872879bd7695d665._comment |   51 +
 ..._cb1df663b03f3ce9cb27e311e5a70198._comment |   15 +
 ..._a98a54c04fa4e81f35fe958e746d61cb._comment |    7 +
 ..._18169e7bbd2caba5ee4bb0286961ac95._comment |   10 +
 ..._e3b623ff6714a9fe5fa0d332c72fe32f._comment |    9 +
 ..._58eebd8cfd664b32ef6fd0ddc34c5e86._comment |    9 +
 ..._e5e24428ac02b78d38cd4f197ae3807b._comment |   31 +
 ..._01dc7a1ff67783ce672d72cefe7b4bb5._comment |    7 +
 ..._458518805b8d6613930b38b9ccc3c1bc._comment |    7 +
 ..._853bc273b19bd6d84ca8f5da6c3dfb56._comment |   20 +
 ..._86656a409ab25c7fa24de8ac3e68b254._comment |    7 +
 ..._createDirectory__58___does_not_exist.mdwn |   35 +
 ..._88439da4b9df6e07aa0300700b66d910._comment |    9 +
 ..._020d7c6292c2a8238a5ec891fba9eddd._comment |   17 +
 ..._f533ffdb2b37f98094fc7633cd686e5c._comment |    8 +
 ..._301ac4a37a0f2da6b9c394509a369484._comment |   26 +
 ..._f2a25cca5d72ce1dcecf36c2780abec2._comment |   14 +
 ..._b8f96a403990a125bf181f0ce8bea44e._comment |   72 +
 ..._2899ef72aa2a5488eb945d14f7a2d76e._comment |   18 +
 ...-annex_looses_itself_on_Windows__63__.mdwn |   43 +
 ..._e809445ff0109d8aa98093b024b3b35c._comment |   24 +
 ...vides_remote_name_with_GETCONFIG_name.mdwn |   21 +
 ..._005fd5bb4e8a025f1b15c7bf5f22d2c5._comment |   14 +
 ...igration_of_a_file_to_another_backend.mdwn |   61 +
 ...austed___40__No_locks_available__41__.mdwn |   49 +
 ..._6c595bec40f6bf470e9170c8ae4bb573._comment |   14 +
 ..._4c2e143b8b3283734963e0a6e68755ac._comment |   10 +
 ..._dac1401bd3661397a9388a5b6ce673a5._comment |   14 +
 ...leanup_commits_--_really_needed__63__.mdwn |   62 +
 ..._7bc271ddeafc92d36d2b90fcb1481891._comment |   21 +
 ..._d0a7283aac4f3c231e20ab284a1f2253._comment |    8 +
 ...le_instance_of_a_special_remote__63__.mdwn |   41 +
 ..._447c9cf5e9e137238fb2c662a54ee2d7._comment |   19 +
 ..._8432a49e6af69efbfcb4d615e147f873._comment |   38 +
 ..._f66844b716e48c5befbe99346e940962._comment |   10 +
 ..._e90ba33f7506745582d18841ae9a9531._comment |   13 +
 ..._098b2e2c51f70d495fe1587220173f55._comment |   30 +
 ..._306afca0827aabc092fd99e56a5b658c._comment |   28 +
 ..._987b2c1de4638e01c4f4feb028d47b88._comment |    8 +
 ..._d0d8a729badb551bb8d0f77e7104c159._comment |   15 +
 ..._7159b17d64ee147822969d79d5a1c48c._comment |   15 +
 ..._39__.panfs__42____39___being_created.mdwn |   41 +
 ..._833cf2db9881a401a3d5db6d4f3c450a._comment |   19 +
 ..._ae3d42be1a15dda2cfe97c99248ceacb._comment |    7 +
 ..._bea29c2596ddcc7f8cd7f02ff7bfd9ef._comment |   14 +
 ...ible_to_login_to_the_website_at_times.mdwn |   14 +
 ..._a5824d9099dc4035e09086166b13f133._comment |    8 +
 ..._fceb64e98fb7566f7cb999e9b37914f5._comment |    9 +
 ..._49b8cf8de638190b3b29ffdca3fe0bdd._comment |    8 +
 ..._dc940fed174b32dfdb4b4ff8c10529f0._comment |    8 +
 ..._c76fddc3aab4d3580c79f105c97d6998._comment |   14 +
 ..._annex_info_without_write_permissions.mdwn |   23 +
 ..._8b60c52d8fe41718377d6d15a25cae97._comment |   20 +
 ..._066d2f95ffab1b36b69aa84643d67765._comment |    8 +
 ..._05f7eec04634e5b4e200cf3dca1bb1b1._comment |   33 +
 ..._705616c61fe7a0779df3794fa8a1d6dc._comment |    8 +
 ...ot_forbids_reliable_parsing_of_output.mdwn |   25 +
 ...ackend_usage_stats_as_a_list_of_lists.mdwn |   35 +
 ...ax_warnings_in_diff_driver_on_Windows.mdwn |  125 +
 ..._65fda26959f82d1f3d110e72d7aaec9a._comment |   13 +
 ..._61__git_fresh___34__regression__34__.mdwn |   22 +
 ..._54456b2ce0964933db23257149b5a651._comment |    8 +
 ..._23398e5403c3a9f40d3b544139ee9915._comment |   45 +
 ..._7fd5d3decc2d6b40d6d2f2d7e6dcabdd._comment |    8 +
 ..._307e7328ca24ff386e0dd734b9ff103e._comment |   24 +
 ..._e9800d53c4f88d1555aad2e0e945b40b._comment |   12 +
 ...___34__debug__34___messages_to_stdout.mdwn |   42 +
 ..._fc8fa8020a9e542d90dd459799d6ec6e._comment |    9 +
 ..._dac0fc9914eff0e187d4cfe3c21348bc._comment |    9 +
 ...ynopsis_for_git-annex-checkpresentkey.mdwn |   19 +
 ...ches__61__false_-_automate_and_extend.mdwn |   31 +
 ..._d2242b526c7cce1084bbb63ef2bfe06a._comment |    8 +
 ..._c3fbb6eb15a510ae9b1af13cd7df028a._comment |   29 +
 ..._c33bf0bdf6bf85e4ee9e1286208c0b73._comment |   21 +
 ..._4c957c33a1c8dc179e0e6cd67a5a29d9._comment |   10 +
 ..._497bbe4e351a66731c920ca5a2048c92._comment |    9 +
 ..._53c317adf0ef48d9ba4af0571f9ded3f._comment |   36 +
 ..._7fac2098e6d7cce997a540592e20c97a._comment |   41 +
 ..._05e4e6936d7b87cb21e312a7aa1731eb._comment |    8 +
 ..._ccb6c9756a2fcf75be8049d89731a5bf._comment |   52 +
 ..._49cda6f52fa4fb527b392f6ee6bae078._comment |   17 +
 ...adata_--remove_stalls_as_of_88a7fb5cb.mdwn |   54 +
 ..._5a7d8371910b27a82e479bdf3bb63d8f._comment |   10 +
 ..._bdc4f86afd827beb20b3d888d96aefe9._comment |    8 +
 ..._d3c6aa8c91630d4bb40b3267bfdebfbf._comment |    8 +
 ...annex_status_output_of_the_added_file.mdwn |   84 +
 ..._4d7eb95c73eceb079a176db1957df25e._comment |   13 +
 ..._ef55541955a6a8840a63309aa403ecae._comment |    9 +
 ...if_other_special_remotes_provide_them.mdwn |   94 +
 ..._for___34__find_..._nonexisting__34__.mdwn |   24 +
 ..._ac192db19137f8b65a13a2c3f7f454a9._comment |   13 +
 ..._88d08c4b269c075e0724fa1bce70f671._comment |   11 +
 ..._28060f4bb31730e3334cf3db56fc032b._comment |   30 +
 ...1___cp_from_coreutils_lacks_--reflink.mdwn |   45 +
 ..._53714ec51d6ae4769f6c4dd9ee46ebae._comment |   25 +
 ..._44965e93c65148f06bf4fe4cad95993c._comment |   28 +
 ..._4a704f47a709a9de35358d6d2fb9fe20._comment |    8 +
 ..._fea65a7f0218ccf27446ee7ce6fc017e._comment |   24 +
 ..._c2d4485b2a49ada5ab5266e30df91b0b._comment |   17 +
 ..._94d4cc9baf46fbc09c21abd08b441b0c._comment |    9 +
 ..._db5de257e8cfb468bf31d46065b7d251._comment |   14 +
 ..._644826ed86849eb4babf37bea3937a7c._comment |    8 +
 ..._dd50ae03bc9a71e04528ac793e79a8b2._comment |   15 +
 ..._552e36f88bc39bc68b65ccba06002082._comment |   26 +
 ...r__44___ignores_--json-error-messages.mdwn |   60 +
 ..._a7ad806ceb76f13ff8fdcce62bc0ed8a._comment |   17 +
 ..._495820d777c889f88466d725c11895f9._comment |    7 +
 ...ome_downloads_and_require_re-getting_.mdwn |   34 +
 ..._1173126bd91dcb7fd13c57f06fd16c2b._comment |   14 +
 ..._2ba8101ed0e91df7079744d1b37779fd._comment |   51 +
 ..._6674e4dbc7437ce941bcef6272c3433b._comment |   40 +
 ..._480df575c68bfb37b8bb4fb43737726f._comment |   29 +
 ..._03e474b00b1cb2a5b8244d9161857b9b._comment |   15 +
 ...ed_indefinitely_in_an_STM_transaction.mdwn |   73 +
 ..._46420a92dbd8655af9b16349da24d0fc._comment |   20 +
 ..._b1f4dc12ad00a4aa73e5bdc7c0a8f489._comment |   83 +
 ..._d8ba7cc5a860e9ccaab32c637cc2a7cd._comment |   17 +
 ..._eecaa7f7b0279c56902c90ed58d1444f._comment |   83 +
 ..._052acf169f9c2b8b0233adddabb02559._comment |   25 +
 ..._880c962d5ca77c494c984e7f74725265._comment |   10 +
 ..._e33df0ec76069deb069b94c944d62c76._comment |   69 +
 ...ne__41___marks_remote_as_annex-ignore.mdwn |   30 +
 ...AWS_creds_ruins_access_to_public_urls.mdwn |   87 +
 ..._9222f76d21e8260327b4f127cc90782d._comment |   25 +
 ..._9e694fdee4a40581a86d21b962f99f25._comment |   16 +
 ..._79626c62d4ce8be2524f9ef3a1351363._comment |   10 +
 ..._40d710dd89b305a64ff8df5d238778e8._comment |   12 +
 ...nt_silent_data_loss_on_unlocked_files.mdwn |   76 +
 ..._9b101babc7cb9e697a6195366d4a0a67._comment |   35 +
 ..._9bfcb8386d5589623423f4d3f040df3c._comment |   14 +
 ..._704ecfd2888a8153eaa5e4a8e6e3d011._comment |   14 +
 ..._3291fcd5100fda8d41fb8714cec15b30._comment |   30 +
 ..._adb69305a31cf55ff62497b6de8e2f6a._comment |   10 +
 ...e_fails_with_external_backend_changes.mdwn |   37 +
 ..._7f23940cfa4451e4cd7137e2d7a46d86._comment |   16 +
 ...__95__basics_fail_on_crippled___126__.mdwn |   18 +
 ..._23bf4756af808d1b2cf89f7da119031f._comment |   11 +
 ..._63d3ff9c10ef530d318653bfadccab22._comment |   16 +
 ..._e8432845460fd0598f8fea5d00c70993._comment |    9 +
 ...1_wo_--debug__44___and_1_with_--debug.mdwn |  106 +
 ..._3c2578d17ce519f80aa278a546df29cf._comment |   24 +
 ...__prefix_for___34__regular__34___urls.mdwn |   32 +
 ..._56cd6e167c86f4419ac0971922f2e5d1._comment |    8 +
 ..._1cebe1385d2b8a244afc259a78f72ada._comment |    6 +
 ..._ca0bf1079acc89a4a79e55f8f58403c0._comment |   26 +
 ..._f05e1047c5d22dddba21a9faa3397f0d._comment |    8 +
 ..._811ba6ec07f6f30c701201178cdb00ac._comment |    9 +
 ..._2cd156baab77dc3b3c248a2368b59040._comment |  105 +
 ..._9f3f7c04524063960f1451c90948a41f._comment |   33 +
 ..._55b111079ecb9732a42d3486160e77b5._comment |    9 +
 ...___annex_add_of_moved_file_errors_out.mdwn |   48 +
 ...__39__add_.__39___if_file_was_renamed.mdwn |   51 +
 ..._bd132d7cfa21b2ea3236b76dffaff156._comment |    8 +
 ..._bceb84ed261a160c4041c146372fc551._comment |   11 +
 ..._index.lck_in_shared-group_is_not_g+w.mdwn |   68 +
 ..._7f25fd487c60f8b6fcaddd1444d898af._comment |    7 +
 ..._92c7a561537e0c6628f30be233b9d7f6._comment |   23 +
 ..._621beade26a1dbbdea000ca43d93a325._comment |   14 +
 ..._3b19a1d3e0e13e407af476b54b725bd1._comment |   14 +
 ..._0655ad5ece1ccd1892ea217aac493594._comment |    8 +
 ..._9dce3bf28e416dbcc08b314dbc08c8a4._comment |    8 +
 ...-g908476a9b-1__126__ndall+1_some_time.mdwn |   79 +
 ..._1735409e62ce82f7ba7258b0167fda06._comment |    8 +
 ...ent_failure_with_absolute_path_to_poi.mdwn |   43 +
 ..._10590563da0f80fa8326a90977966509._comment |   37 +
 ..._1b9b2ebc78949c7b39a255c291d11891._comment |    7 +
 ..._0ec752dbe8ef55a9884c1c5e83887505._comment |    8 +
 ...to_have_copied_files_appear_correctly.mdwn |   48 +
 ...ch__a_file_which_is_.gitignore__39__d.mdwn |   37 +
 .../return_--backend_for_addurl___63___.mdwn  |   29 +
 ...ME_does_not_exit_cleanly__58___gpgtmp.mdwn |   27 +
 ..._84a2d253843903f9811652b78d0fa7ba._comment |   25 +
 ..._key_to_another_during_rename_of_file.mdwn |   50 +
 ..._cd7043b66977b2a668bbd52f4d8e31ff._comment |   21 +
 ..._e5b43f5733181fba9f79ae0035b354ef._comment |   10 +
 ..._10d6135ad4b0c9706ff7b932323118d3._comment |   21 +
 ..._fda77062452ac619a23298007bc0148a._comment |   10 +
 ..._fa6d5d0afdc00824da0e04d9bf23d6f4._comment |   20 +
 ...x__39__ed_files_to_be_writeable__33__.mdwn |   32 +
 ..._2e61ccc41839b8da70ad26d31e40ad74._comment |   25 +
 ..._e9af4784ffb84b49b6faaa21aa7c8efc._comment |   29 +
 ..._fc10e403f35f47a6c4464f3f68d01eca._comment |   36 +
 ..._43a09de767ed9060dd91d6eca5e0b3a3._comment |    8 +
 ..._df04a6bd62a60789d8a59cce4b62728e._comment |   22 +
 ..._0619eec44cddf3d3b1aae27c7bd1389a._comment |   22 +
 ..._aae8dd8b3b0ce4647ec2d30e1d682339._comment |   22 +
 ..._c72e6646e39cc487ea52cd17925a548f._comment |    8 +
 ..._d8c8b725ee91a899a131bf505bd9a2e3._comment |   20 +
 ..._d0d8065b78c22e62ef780c27e4d5952c._comment |   10 +
 ..._a82064795fdbdb0187763aeee4a308ff._comment |    9 +
 ..._c3d447a8f4e63f6a28a02ccb4eed1ad4._comment |    9 +
 ..._f74642e1dfc4e533b9582e5a13a16898._comment |   41 +
 ..._entire_name_to_be_an_extension__63__.mdwn |   63 +
 ...p_permissions_of_the_ssh_remote__63__.mdwn |   15 +
 ..._35eeb15c0031c18ba6d0922bb7ae8ed3._comment |   89 +
 ..._65232a9c2bbba075d325ce00b7c5e13f._comment |    7 +
 ...erformance_regression_impacting_datal.mdwn |   19 +
 ..._37d5186dfa2da31526c4eafbbbfdbc33._comment |   14 +
 ..._51a3a86a290b0e3994507f3f64e7c72a._comment |   28 +
 ..._c841c9db2000c65c56ce8e26e58a3f62._comment |  153 +
 ..._f6bec279f43603719694e44d99309fc7._comment |    8 +
 ..._4d2998ea843dd8adee8b7b066d97d942._comment |   28 +
 ..._c9488d6180e741dfec0793f546c9eb29._comment |   10 +
 ..._65aaf8e15cd15187cd63863634f25091._comment |   33 +
 ..._045fd8ebe1f9441e42c9c6fbf5c06563._comment |   93 +
 ..._8df0e346ed85e52ec94763d11c174ab3._comment |   12 +
 ..._3e57d7d4640de95a059b2ab3d1e9d54e._comment |    8 +
 ..._80372cd15a6a8812072a446c41fed4e7._comment |    8 +
 ..._3eb1b092f41dc5c04d74f7a03249aa0f._comment |   10 +
 ..._0119751108d8d9fe6848269594bec273._comment |  104 +
 ..._192f2055345f1156a06d93b4c25e6722._comment |   16 +
 ..._8693e7e9c800f25cbd274b6781d834d6._comment |   31 +
 ..._6d11f6aa4b1a435bdf6d165eb8e6db8a._comment |   17 +
 ..._5525b58ec94084a926c71f749d1f4233._comment |    8 +
 ..._cb64b1798af6ad507ce4a4196e9c5b1d._comment |   16 +
 ..._db91e10d0bea246686ba2241b348e67d._comment |    8 +
 ..._0d6a37f823cd9cb3ed1e6e90066ebd2c._comment |    9 +
 ..._0f3c8949ae362b43ac7db02eb4e11890._comment |   13 +
 ..._521f784d686fcaeb5e081599fbdf9903._comment |   12 +
 ..._386c0cfe688effb1543ffd01a54717e0._comment |   10 +
 ..._97fa9b7729805704a6a22cf18082e203._comment |    7 +
 ..._0ab5e774dad1e6e74a5c72b95e40d659._comment |   35 +
 ..._6e5121e066998a303cf68ebc53e9fc15._comment |   23 +
 ..._86d07025980e0b50d1a52f73c049944a._comment |    8 +
 ..._d3437076c759eedc0c8d5d15db035455._comment |    9 +
 ..._25fa8b726e06dc69e3a0d9ed675da1d1._comment |   28 +
 ..._d30a515103d04fd966aadee7f141aeee._comment |   13 +
 ..._4011786784a140442dd7ecd1cefe559b._comment |   11 +
 ..._85d1031d2b51c0fc1271c283d8ee7888._comment |   14 +
 ..._b0f1e94e96cf8fe992425cf81f8d1105._comment |    9 +
 ..._35217e61ccf6936e105df8de7e1775d0._comment |   16 +
 ..._29bde900ef625702b49cf020118f940f._comment |   16 +
 ..._431582f1c218f27e50849df1444dc845._comment |   33 +
 ...n-error-messages_--batch__do_not_quit.mdwn |  128 +
 ..._4123b5b93a220c1ba46126a5d97b6ff9._comment |   34 +
 ..._7d37b8d79fcb6a0edd99e0bd6f2b0515._comment |   16 +
 ..._7ec51c8996c7cc4b555313e84634e406._comment |   26 +
 ..._7bd5a28d5ba1eefd5a96483b5f00a89e._comment |   10 +
 ..._3c407c1924e21aa1ec300875680dc3b3._comment |   19 +
 ..._58997665e5aa0a237a3ec90efca92891._comment |   14 +
 ...41___regularly_fail_starting_recently.mdwn |   36 +
 ..._d4c417df9a8e6c13c06ccfc21853de02._comment |   18 +
 ..._16a96277aecccfa32cd918ac662ce6f8._comment |   14 +
 ...me_tests_fail_while_running_under_NFS.mdwn |   57 +
 ..._8e0f72f633ec79bd373b009046ab66b7._comment |    8 +
 ..._ee9cc13cf34432be00a906bf65cebafd._comment |   10 +
 ...over_ssh__47__rsync_and_require_retry.mdwn |   35 +
 ..._b762aa4a31f2153c00988d185ce5efbe._comment |   10 +
 ..._7d5c57bf17659769d9cf4d56774ba67e._comment |   36 +
 ..._8a5ceb261338ab55b5c8c2daa56d04ce._comment |    9 +
 ..._bedf66f7257511d1d245ff0c6bcfe5f6._comment |   13 +
 ..._63____41___fail_of_crypto_test__63__.mdwn |   38 +
 ..._9909507b034e25db04e5407717fab315._comment |   14 +
 ..._a254c4de61a74bf314eb33e301c199f0._comment |   26 +
 ..._89e9d65073a58188024290a2b32fda2e._comment |   22 +
 ...ndalone_build_is_slightly_out_of_date.mdwn |   48 +
 ..._349f2d8f6ef0fddcfe576fc08b3cccb6._comment |   15 +
 ...h_with_helpers_merely_upon_annex_init.mdwn |   19 +
 ...t-annex__47__locales__47____96___dirs.mdwn |   36 +
 ..._343ac13424b0b65db2094c595bcabd7f._comment |   10 +
 ..._c43bb7ffa7b900f5824b4495a6a82d0e._comment |    9 +
 ..._57681d5959095d9a3e6ea9e4d0679c85._comment |   19 +
 ..._5c2c6003b45d78b9e0bee95f5a12c48c._comment |   38 +
 ..._57834ef04f206e1b351b36ba32ce447f._comment |   12 +
 ..._9ee31c8d92178b38bbc920df395ee284._comment |    8 +
 ..._2abc6e368033bc636debbcd83dd2b4ed._comment |   11 +
 ..._IFS__61____36____39____92__013__39__.mdwn |   28 +
 ..._ab8017246c0075b731c7d31235672c01._comment |   66 +
 ..._2b7afff24ba025fe3e272ff6f607eadf._comment |   10 +
 ..._ba1b34111d47d58517ea64f537214e98._comment |    9 +
 ..._297b462c0344b8c7e5e113fdda3642f4._comment |    8 +
 ...n_already_present_failures_on_Windows.mdwn |   19 +
 ..._7e089c436af03ffd8ad00dba45156a14._comment |   26 +
 ..._07f7881be6b0d29cdf64a7839b669b3e._comment |    8 +
 ..._c570246b0484ed3694efff62feff968c._comment |   11 +
 ..._2f701f39286c3a75a88407dcc6947081._comment |    8 +
 ..._096b3af691987ef20281c87519a31935._comment |    8 +
 ...__from_extensions_in_E_backends__63__.mdwn |   18 +
 ...l_on_windows__58___permission_denied_.mdwn |   32 +
 ..._9f46a99e5f570de2313a5521b58640b3._comment |   78 +
 ...any_instances_of_the_externals_remote.mdwn |  221 +
 ..._6c4afa18ad31f46ff8c0b827415373e4._comment |   23 +
 ..._daa09ac406dea6cd3ab74fe19d89d956._comment |   21 +
 ...mote_failures_starting_with_aeca7c220.mdwn |   83 +
 ..._d779827a6cc3d3d7bb6edfa410170e09._comment |   13 +
 ..._4cfb0979773618a0bc18d52bf0f274e4._comment |   11 +
 ..._d53b98bca623d4d25bab58563e7577b3._comment |   22 +
 ..._a80f9277eb6f6c49710d5008bc2c2c42._comment |    9 +
 ...emote_hangs_after_asyncexternal_merge.mdwn |   60 +
 ..._854aecbc440dc3a5aa15f9de5f36c9e8._comment |    9 +
 ...ng_build_inside_singularity_container.mdwn |   45 +
 ..._d36c27dca4d266d1e6639e3435198016._comment |   35 +
 ..._c61b14b76cf06c0b10257c1a84d9478a._comment |   17 +
 ..._ea210a22073919be434884f006212e6a._comment |   23 +
 ..._0cfd7d0d93d0747d42d20f13b788fe43._comment |   16 +
 ..._944a4474401b2fa0b4f3631bac63a07d._comment |   10 +
 ..._fa8c65c2223d2be21aa95e5889c1f352._comment |   30 +
 ..._d358bf55d89f5d0609d792a26757d0f4._comment |   11 +
 .../bugs-done/tests_fail_on_Linux_build.mdwn  |   27 +
 ..._9932a7c60bb369fbffba52092e03bce3._comment |   26 +
 ..._c042d95b58500933e5932176037ead8f._comment |    8 +
 ...n__while_moving_within__a_local_clone.mdwn |   41 +
 ...ddurl_--fast___40__or_--relaxed__41__.mdwn |   30 +
 ...t_content_via_ssh_without_write_perms.mdwn |   76 +
 ..._2562d33a1cafb01b2cddb9a42a635616._comment |    8 +
 ..._8b4fd2331ff62c984f91a9536a3a7e2b._comment |   16 +
 ..._3889b10d60b007de72b3af87e920e74e._comment |    9 +
 ..._a4f9bb23f0682a66e951b96aed6ae214._comment |   20 +
 ..._1b01ff1b092976af137bdfc2c9e28fba._comment |    8 +
 ..._9e4b82d27ddbb42d74f10a85635590e7._comment |   49 +
 ..._11cb8251521014ef81b53090f5c78376._comment |   14 +
 ..._ba7e53135285dbf198f5aa12d7edc1cd._comment |   22 +
 ..._95ff27c621afe43abfd7403f343b612c._comment |    8 +
 ..._b70343f8cb81807a7da0da5637d8c750._comment |   12 +
 ...S3_remote_without_clear_reasoning_why.mdwn |   80 +
 ..._87983a598cacaa8800db4a01ec23ba1b._comment |   18 +
 ..._b9e5b868dd5379de18ed77907d1b42a3._comment |    9 +
 ..._667c5b94580e2ca0305d4ed97c2e199f._comment |   11 +
 ...ic_S3_bucket_where_it_exported_before.mdwn |  126 +
 ..._08514c489b916b2ae8e4e0122051856f._comment |   18 +
 ..._1ae05c24612f50cfe03e2569b332a522._comment |   51 +
 ..._ae81a2ac4b2167d48c8a447811a492a2._comment |    8 +
 ..._c49e48ea12ed0a0edb675b532279a5a8._comment |    8 +
 ...without_stating_any_reason__47__hints.mdwn |  153 +
 ..._replaces_.git_with_incorrect_symlink.mdwn |   50 +
 ...r_magic_file__warning_pollutes_stderr.mdwn |   26 +
 ...____44___git_commit___34__blows__34__.mdwn |   52 +
 ..._1c86937cee067b5980852fcb066b0bfb._comment |   15 +
 ..._bd552525b7bb2ceaad72c8fa3bf41c6b._comment |   28 +
 ..._8cfa8fe790ff2586374f46ed10cc8fbe._comment |   22 +
 ..._40e9a5b641200c92725df31a654b6a05._comment |   16 +
 ..._eaafc970cce2c71ce29f136c90e04504._comment |   57 +
 ...__40__adjusted_branch__41___teststuck.mdwn |   62 +
 ..._d530fb679b76e995c466fe17c3aab830._comment |   11 +
 ..._dcc764525370338fbf9b6f2728e3e5ac._comment |    9 +
 ..._7c9fc177fcb76b76765cece36b4f939e._comment |    8 +
 ..._981d6d42f411476d1a5e38d987af6035._comment |   34 +
 .../wanted_on_read-only_repo_crashes_.mdwn    |   61 +
 ...arted_to_dump_debug_output_to_stdout_.mdwn |   68 +
 ...___34__drivers__34___is_not_available.mdwn |   40 +
 ..._3f8100a4d9e6ab4302c89eeafd0f843e._comment |   13 +
 doc/projects/datalad/done.mdwn                |    1 +
 doc/projects/datalad/potential.mdwn           |    5 +
 doc/projects/neurohub.mdwn                    |   25 +
 doc/projects/openneuro.mdwn                   |   28 +
 doc/projects/repronim.mdwn                    |   26 +
 ...it_annex_6.20181011+git109-gff9ba1f4d.mdwn |   43 +
 ..._244e138f7621c901dd7763159db84677._comment |    9 +
 ..._cbdfb3dea5c125b52d53811b96b3e01e._comment |    8 +
 ..._fails_tests_during_neurodebian_build.mdwn |   29 +
 ..._ddd60096d409a820358d5a57a3a449c9._comment |   14 +
 ..._b496a4967b6bcc0a4e1cc55e06ba90c8._comment |    9 +
 ..._bdadf679a2f82c2a1cae747d437add85._comment |   22 +
 ..._90bc2857c83afae250834135a5884898._comment |   14 +
 ..._d29518fef1b3b0b8937e078f9303d41c._comment |    8 +
 ..._24eca56dc972ecff0b553e93b7c649c4._comment |   17 +
 ..._3adce9695e4e3786f0c68b092d8f6400._comment |    8 +
 ..._within___34__git_annex_version__34__.mdwn |    6 +
 ...ion_in___96__find_--json__96___output.mdwn |   35 +
 ..._034f772098dfb9d3622c6f84976e69a2._comment |    8 +
 ...8___InvalidHeader___34__preload__34__.mdwn |   80 +
 ..._247f3c1dfea3cdb0b398c015f4c4d44b._comment |   44 +
 ..._an_error_message_in_case_of_an_error.mdwn |   19 +
 ..._636a375fbd8cf8573b3806d7a815b59f._comment |    9 +
 ..._50d096934badd3e59756939b5c418bcb._comment |    7 +
 ..._potentially_access_any_address__34__.mdwn |   34 +
 ..._longer_generates_default_description.mdwn |  100 +
 ..._eb415152db43c02e4d474dade4a1faca._comment |   18 +
 ..._c51d386f294529d6ebe7058438577ffe._comment |   36 +
 ..._6edae77c6ee7e4c4f94f9c0daff375ad._comment |   13 +
 ..._d92a7f2bc72b27c74cd86811c9bbf098._comment |    8 +
 ..._0dd1d4e6cd16da2865c3153b61b9e282._comment |    8 +
 ..._539039e237d9b0db0c97f64d877de7f7._comment |    7 +
 ...red_while_running_in_docker_container.mdwn |   88 +
 ..._130f2600057aa5b648f7798c49b4ea60._comment |   16 +
 ..._802f85441c42ac079b6ecaea39a63c81._comment |  351 +
 ..._4d03d12bfba811e0a67551e10201200b._comment |    8 +
 ..._1ea0f89c3c9e8bf1142b2c234cdf90c3._comment |   12 +
 ..._72c67ef575c90071040cf5347d81ce01._comment |   10 +
 ..._dcfb1dfb33a690a73547a5855e0ee55d._comment |    9 +
 ...ectory_with_a___34__tricky__34___name.mdwn |   70 +
 ..._10045d7efa652ded4c41fd8c3e089bf4._comment |   10 +
 ..._6d57bda8ddc603f24e16018969ac780a._comment |   46 +
 ..._1a982c19fc7360a2a231b5a23142bbba._comment |   18 +
 ..._397686077b5a63196204327c178a7064._comment |   11 +
 ..._b95c1da49c3a4eecca8038c03a46c709._comment |    8 +
 ..._d2f9a37824dd2bb49892430f9f271f1c._comment |    7 +
 ...ld_for_neurodebian__58___test_failure.mdwn |   36 +
 ..._ec7aa500a826beb813bc5313af9aa983._comment |   24 +
 ..._a61ed5b8f438caf0b8c7a53e08e1986a._comment |    8 +
 ..._09343b67a0c6e82203b76ef591233869._comment |   11 +
 ..._8be6e27e081d4bc8c0fa178088a10a91._comment |   58 +
 ..._b08d8859f873fcbdc78f938042fe0fbd._comment |   12 +
 ..._357f297d1afab22a59b2bafe4b85facd._comment |   36 +
 ..._2181d91c9b5b374c6102fdcc227349fc._comment |    9 +
 ...tree_in_v7_in_repo_with_detached_HEAD.mdwn |   59 +
 ..._a377e26b2eb75956c9de9beed0534cc2._comment |    8 +
 ..._d1ae8ccbfc3a9dd90cc03e68d5a78071._comment |   65 +
 ..._cd7cc008c3d37caa76416bd2452da90d._comment |   21 +
 ...nterrupted___96__annex_add__96___call.mdwn |  102 +
 ..._25dd2f0ba99913f26cbcbf55352bb1ab._comment |   14 +
 ..._f5e21a674c54c5dc4c8474ce1b4ffaf1._comment |   21 +
 ..._028eca36967a89e5f479802499232a90._comment |   33 +
 ..._6657ceac22df80251b74c6e4b47f8ba0._comment |    7 +
 ..._96f485e38778448804ae253f9032babc._comment |    8 +
 ..._0e3ae1862408b6d0c5e0acd9e9fa20b5._comment |   54 +
 ..._7fcb97b7d7f26fb6964a574ba1c8cd20._comment |   29 +
 ..._ba2dd3b91147e2979bc90a022f6e0252._comment |   12 +
 ..._fe629ccb023c2564dbf78402d92bef66._comment |   10 +
 .../git_annex_test_never_exits__63__.mdwn     |   47 +
 ..._d258114e6e8f8db28b65a39cb13f2a04._comment |   29 +
 ..._adc040aad7d339e22fef76a2cbc4a312._comment |    8 +
 ..._e07a5dd0abb2049b4bb0bf26fa2ebab5._comment |   51 +
 ..._419de3fe25c490b251b8a6a7a9b24ed6._comment |   44 +
 ..._2bb944b19503dcf90fdf55e5098a2c02._comment |   10 +
 ..._a8847e219a57f3cf41330745e6a67b10._comment |    8 +
 ..._4e7be0dd1eb70af4790e2bcba7bb6ea1._comment |    8 +
 ..._d12ddfb48706454eba1bd552a681e5ba._comment |   19 +
 ..._d897d97bfe8f13431f8c5d92e61bbd3d._comment |  114 +
 ..._b3f282a0a0d4c5f174cf6831dbf3014c._comment |   56 +
 ..._230038504d75704baacd4d3ac750ee95._comment |    8 +
 ..._--kill__34_____40__gpg_2.0.22__41___.mdwn |   35 +
 ..._0351276d5eeb5d8af0cf0e72c3a213fd._comment |   13 +
 ..._a8565fb1657318092a22e8ed18ae6cbc._comment |   17 +
 ..._d3a478e3f7da91ab14c9b1e24d3e07d6._comment |   58 +
 ..._9add6c8e1d5b722eaeb2e5a0fe67cd32._comment |    7 +
 ..._b411b96c73bba30557c2f3aa9d6077e7._comment |    8 +
 ..._e3a79f9480a7123feb924f3c1e72ce62._comment |   26 +
 ...al_get_-J_on_exported_S3_bucket_fails.mdwn |   52 +
 ..._005874771ab14efb94c4a739da31b523._comment |   11 +
 ..._in_an___63____63____63___transaction.mdwn |   63 +
 ..._d2a5b1eb72cf0abbd0143339ff81a92a._comment |    7 +
 ..._5ee016343b74fac9d6235db88744734a._comment |    7 +
 ..._c640da31be6bcd50dec6eabb2e792e07._comment |    8 +
 ..._4bb69f0bc73b5d368cc9278b88223a5e._comment |   16 +
 ..._2d8cf0d8b020941d143abd424729c6bc._comment |   32 +
 ..._7cc13b150c19a3c08f2b9cdeb880cfe9._comment |   10 +
 ..._9d1f902cc0e029b483115c3c0de5d113._comment |   25 +
 ..._0e4efb1686564f4d8e834b1e0843d397._comment |   58 +
 ..._01371e8b9d56d4470af5277456763d12._comment |   10 +
 ..._a171911a9bb7a278e673e4b6905c971d._comment |   36 +
 ..._ffcede72f600ecc98b906f0d9b6d6d0a._comment |   12 +
 ..._2b76e74756e684a09387396fa2177d57._comment |   34 +
 ..._8f7fd9bc58d8c2eff32f5fa200b57119._comment |   20 +
 ..._0827ffb4beb55f6553a40c722bc2ec12._comment |    8 +
 ..._c9102fdb9d99d2c19585e74b0dc0dff7._comment |    8 +
 ..._d69e0931e520391551eb4c37eb2f809d._comment |    7 +
 ..._115c584098501e16292dc6c776141074._comment |   16 +
 ..._1adec4fa4c8af5409d2f5dc7adcaecf4._comment |    8 +
 ..._e8b00ab555e94cf8826493ca6ce2d082._comment |   10 +
 ..._2fb1c54c41b31698909594106cb08cd4._comment |   35 +
 ..._750dbe3e118b1b6b8d0cca7d26ea1366._comment |    8 +
 ..._50c0db38a664adbb0c5a2290326195a6._comment |   11 +
 ..._cd1362901ff08323ca134fc8de914318._comment |    8 +
 ..._e2cc841198c91709980cc2b2a8297925._comment |   65 +
 ..._eff60d2ee47af65f18dede31cc283adb._comment |   19 +
 ..._3338f896a983292bef576dcd369bba5a._comment |   30 +
 ..._fe7e5c3340282f89c3393d8c5a2bc17c._comment |   13 +
 ..._296739c184ac8d0cc453aeeeff5b6f74._comment |   12 +
 ..._75f52900d12931b4c6172e10401f28d3._comment |   37 +
 ..._eea08486fa9669bd197eb9e957b65ef8._comment |   24 +
 ..._817a9d27a0b15798671f4dc5cd661164._comment |   72 +
 ..._c2df4fa0420c0db31b38e65a8d7dbf92._comment |    8 +
 ..._288741ae44f2dddbe53ab1dc294e2fb7._comment |   58 +
 ..._44d25c37e26e71b2aff759a0d39c5803._comment |   23 +
 ..._24ab22004dd25169bb9191a92f1e0ac4._comment |   10 +
 ..._c8a52578b5d7482683443bd5d95a5265._comment |   12 +
 ...tect_need_for_pidlock_on_an_NSF_mount.mdwn |   67 +
 ..._82a71d4e9656c83e2d50143cb8a31602._comment |   16 +
 ..._9bd5f0acb9761dcf59ecd38092e3e14d._comment |   49 +
 ..._6d2fceb790e675cb73b193bf67f7a6f4._comment |   29 +
 ..._bf6487c1740f163745b7dcc41468ec4d._comment |   12 +
 ...ecting_to_ftp_are_no_longer_supported.mdwn |   71 +
 ..._5184c1b87e249f203541f610278ed08e._comment |   32 +
 ..._860458173cb4d745e8c9833b804398d8._comment |    8 +
 ..._921d2493f51ecb61b711773238c9f7e7._comment |   17 +
 ..._b15837921956ad166cf53a5dd23cb7dd._comment |   20 +
 ..._2a66b890e3c60d1102acb7cef0b86308._comment |   20 +
 ..._c42192a94651f34d32f6d5b91b1c09e8._comment |    8 +
 ..._11f4424d3b9fb6c54fa510320affac73._comment |    7 +
 ...rks_url_not_available_in_wrong_remote.mdwn |   83 +
 ..._2aa17a7067a183f5837b5a41d74fcde9._comment |   14 +
 ...start_for_annex_64bit_looks_under_x86.mdwn |   12 +
 ..._b8a4128b08ef8dd25a8141b27531b9ae._comment |   13 +
 ..._0f23c377b22788d9c540bd480398f47b._comment |   14 +
 doc/projects/repronim/done.mdwn               |    1 +
 doc/publicrepos.mdwn                          |   47 +
 doc/related_software.mdwn                     |   72 +
 doc/repomap.png                               |  Bin 0 -> 67316 bytes
 doc/required_content.mdwn                     |   22 +
 ..._b9576aaa31258e9bdf18a4eac8d61bfb._comment |   10 +
 ..._d475f4afc84a58afe7af6d492de3ebe5._comment |    7 +
 doc/scalability.mdwn                          |   41 +
 ..._a6656ae397277719d67d0953a28fe1d8._comment |   12 +
 ..._71c7c3aa97284602d0f64c11a98d1782._comment |    8 +
 doc/security.mdwn                             |    7 +
 doc/security/CVE-2014-6274.mdwn               |   10 +
 doc/security/CVE-2017-12976.mdwn              |   10 +
 .../CVE-2018-10857_and_CVE-2018-10859.mdwn    |   92 +
 ...exposure_to_encrypted_special_remotes.mdwn |   12 +
 ..._285da453a385bd4bd225e26377a47cd5._comment |   10 +
 ..._261b1904e41f4566490b977010ce8734._comment |   19 +
 ..._0cc44e032fc94f4d374fb297ca9a8f2d._comment |   12 +
 ..._3822244fb9becc32385d57233fa036a4._comment |   11 +
 ..._616b08553430a64beab196571c5b9cdc._comment |    8 +
 doc/shortcuts.mdwn                            |   12 +
 doc/sidebar.mdwn                              |   12 +
 doc/sitemap.mdwn                              |    4 +
 doc/special_remotes.mdwn                      |  136 +
 doc/special_remotes/S3.mdwn                   |  165 +
 ..._c366f020c9b97a365e21878a33360079._comment |   10 +
 ..._c1da387e082d91feec13dde91ccb111a._comment |   12 +
 ..._59c3ecab7dbc8be53258460473cac21c._comment |    8 +
 ..._0789a21d980825188bb09f7fc8bba8be._comment |   33 +
 ..._29574a51d5831c51e2e765eb2c06e567._comment |   12 +
 ..._ceb9048c743135f6beca57a23505f0a3._comment |    8 +
 ..._7b79f8b5ef88a2775d61b5ac5774d3e0._comment |    8 +
 ..._52d3510016c099d083553f9b3fa40db9._comment |   10 +
 ..._0dcb84048563fc9e45b66ca8f365f320._comment |    7 +
 ..._9d0d622b6202698f09eb06c097579fbb._comment |   19 +
 ..._4a1f7a230dad6caa84831685b236fd73._comment |    8 +
 ..._ce4ce50d51675ee4746a2528d4bea750._comment |    8 +
 ..._26cbfd805dd45a80121f5e2079afba37._comment |    9 +
 ..._55a7e513713285b8ced84c8cfd525364._comment |    9 +
 ..._b503ce70a4f008be580a069420361686._comment |   20 +
 ..._b209474b90befc79a7139d6c5703e2d8._comment |    9 +
 ..._29f2760e433a0e6229e46e728c380275._comment |    8 +
 ..._6b99242a6a681a1848041a8b8875743d._comment |   21 +
 ..._163d81443ca5a05138e6f570b068ac6e._comment |   14 +
 ..._c4dafad82a898eafd6d9e3703fad2c48._comment |   12 +
 ..._37430a66a9f39a635b32f04ff82db194._comment |    9 +
 ..._5b22d67de946f4d34a4a3c7449d32988._comment |    8 +
 ..._db7e1e3506cf7a912cf88ffe4caea20b._comment |   10 +
 ..._e46934941fca2de536f3705185098b6e._comment |   13 +
 ..._197d0c6d632c201a4ea9680653895c07._comment |    8 +
 ..._36788d742259b3b078e02d7b2a251ce5._comment |   16 +
 ..._cf57e8dbd9fdc7c487565b61808b6bb2._comment |   10 +
 ..._a141196a77d77cc6e130185dbf01e48b._comment |   10 +
 ..._9c900d777c9add9c277d40bd5b32bdf6._comment |   90 +
 ..._fef35384191078ed9ac6ee819eea4aa7._comment |    8 +
 ..._03ba1dcf23e04b8c54b53b10a93e1c45._comment |    9 +
 ..._bcab2bd0f168954243aa9bcc9671bd94._comment |    8 +
 ..._38c0b062997fde1ad28facc05d973e83._comment |   12 +
 ..._409bc2b56382417cf26bb222fb783ba7._comment |    8 +
 ..._78da9e233882ec0908962882ea8c4056._comment |   10 +
 ..._6af9781004d982d8e6b20a83ad29eead._comment |    8 +
 ..._0fa68d584ee7f6b5c9058fba7e911a11._comment |   12 +
 ..._7ad757b3865b04967c79af0a263bb3b0._comment |   10 +
 doc/special_remotes/adb.mdwn                  |   49 +
 ..._df47283c499cddd1d92a262679514531._comment |    9 +
 ..._f1f6c0a6f8c34c3d205988d2f69693ea._comment |   16 +
 ..._1d08d2ded354328461e9a7288287779e._comment |   20 +
 ..._9f5edeb544f6a26e9278410ef67e99ba._comment |   14 +
 ..._c9a3427bc8e924cd1f50246b3ec7c081._comment |   19 +
 ..._73ea2ada02df871b0c9795a5b769f7db._comment |   13 +
 doc/special_remotes/bittorrent.mdwn           |   32 +
 ..._4ef590d88bacd763abd5ce209e6b9640._comment |   17 +
 ..._bccc7409111e4df4f4aab3b21fa4d321._comment |    8 +
 ..._1e2372988e37c07b47a407f2eb979190._comment |    9 +
 ..._aedac7a8482f710637493464b9e76fa7._comment |   12 +
 doc/special_remotes/borg.mdwn                 |   44 +
 ..._2a650af185a4eee5fd7fc350ed395e2c._comment |   10 +
 ..._6e6baf5467efcae70729e18975d8eb1a._comment |   10 +
 doc/special_remotes/bup.mdwn                  |   40 +
 ..._f78c1ed97d2e4c6ebffaa7482cfe0c9b._comment |   23 +
 ..._b53bceb0058acf4d1ab12ea4853ee443._comment |   24 +
 ..._65d923226cf6120349d807c5c60f640c._comment |    8 +
 ..._fca579678edde073716f099c767767e1._comment |   10 +
 ..._ce960bc69b27dfc2a233c9baa5b2cd2b._comment |   10 +
 ..._940b778f97377e83dc16439c0c7e5b38._comment |   21 +
 ..._c4665d089f2ceb2ed798cf264d490a8c._comment |    8 +
 ..._4787e0373eeec3c7d1d562e47217566c._comment |    8 +
 ..._360caa8972c2daa94044cc95188306e9._comment |   18 +
 ..._96179a003da4444f6fc08867872cda0a._comment |   43 +
 ..._612b038c15206f9f3c2e23c7104ca627._comment |   12 +
 ..._1186def82741ddab1ade256fb2e59e6f._comment |   17 +
 ..._7d22a805dd2914971e7ca628ceea69be._comment |   10 +
 ..._5942333cde09fd98e26c4f1d389cb76f._comment |   10 +
 ..._cb1a0d3076e9d06e7a24204478f6fa98._comment |   10 +
 ..._4cbc67e5911748d13cee3c483d7ece8a._comment |   12 +
 ..._ca7096a759961af375e6bd49663b45b3._comment |   10 +
 ..._e9881290486a1770bd260f8650ada9c6._comment |    8 +
 ..._e01b5cc5a0d81b071e93e27e7b91fe2a._comment |    8 +
 ..._13237170ef5b6646e0e25d3421af3fe5._comment |   10 +
 ..._1a36a0483a9db04d36e0234a192ebad8._comment |   12 +
 ..._a8419963dc024b1d9eb73807596012dc._comment |    8 +
 ..._95ccfdd22a2391daa99e0beb04adedd6._comment |   11 +
 ..._b9d238fb15ad7628e33c90b071e07bb0._comment |   12 +
 ..._cc21b81a8f809f6efa5f5b6332513fc3._comment |   12 +
 ..._3fe750118ff1edbe91a110b86fb5b662._comment |   10 +
 ..._6794eb52bd87c28ef1df3172aa7d5780._comment |    9 +
 ..._961276c18e9353ca8e25cad53e7ec51f._comment |    8 +
 ..._6b7242721f2f2c77b634568cb737e3e3._comment |   13 +
 ..._308afc586b86c66bbb3437d63864d9cb._comment |   16 +
 ..._0f5440e0e54cf7ac2a68b1ba115b0930._comment |   10 +
 ..._96ef232e13bc2dc102a667a06c856ee7._comment |   13 +
 ..._2c9eda62766c9d5000346a092fe5d0d8._comment |   16 +
 ..._d9f298f284d66fb0aff029eb01f1ce23._comment |   90 +
 ..._606c1bee71a265f9df3a8cf50fce9a21._comment |   20 +
 ..._b37c6ed2444bd7e8b4d7937abdfcbd1c._comment |   13 +
 ..._c7ab32e1e63fc114b3b2f56bab62eafa._comment |    8 +
 ..._8393a14f084d022986c8245ee01f4198._comment |    8 +
 ..._97543acfa7434e332ebea5672e446317._comment |    8 +
 ..._8e5b17431507ee2115b992e5156b749b._comment |    7 +
 ..._20ac13d009a4f451eb895ca16446ba88._comment |    7 +
 ..._8dea734fed26e5d9336a2da5bd81eabc._comment |   19 +
 ..._317c4d5edc9de8159c3b03a3e161e257._comment |   12 +
 ..._31256dd4b74d344aa49902adec4bcf02._comment |   10 +
 ..._5801755d10149f0d3971fef0b6e1b62f._comment |   19 +
 ..._48859c5ea8f63e37b7531ed0e07f4a54._comment |   17 +
 ..._9fa2adc324ba25428a681158e58a5300._comment |   14 +
 ..._04366bcb840b7628d13546daf65650dc._comment |   18 +
 ..._990a0e67fdd30680631a90231d07c611._comment |   17 +
 ..._9229776623c234204c8b164edff95da0._comment |    8 +
 ..._2a36f9c874b00fd5de94836e3dcde782._comment |   18 +
 ..._26a29fe6169eee1c62dd10672040851c._comment |   14 +
 ..._85e354eb058aea02be7b847bceb02313._comment |   10 +
 ..._75a7c567db2b5256182b2cf06091dc12._comment |    8 +
 ..._bc5871052d29f25eddcc0e02bb2e5a25._comment |    9 +
 ..._7553ddfb96499b52ddc300a457972645._comment |   15 +
 ..._f3f5348ceeffb458bcd7bfaa5c420751._comment |    8 +
 ..._780e9ba56a2a83d64583521b8d987e33._comment |    8 +
 ..._ee5aa6762ca9403c1a2afe1819984fef._comment |   10 +
 ..._044a3d6c35fa1b522f7aeea2cec4199a._comment |    8 +
 ..._3bbda479d13f6bf393dcd59ed94ddeaa._comment |   10 +
 ..._4485e72f90f46beef3f216ffab82386e._comment |   15 +
 ..._1a8a217dc31b0a36dfa9975f72d40b3a._comment |   18 +
 ..._02172d2b81de8c5e212e5ed093a01aa1._comment |    9 +
 ..._f7000975d38077828ab11a99095b39eb._comment |    8 +
 ..._5d2bd7c1e1493d3c3784708a9b0bc001._comment |    8 +
 ..._af01ee5ce31b1490af565cb087d65277._comment |   10 +
 ..._3d4ffec566d68d601eafe8758a616756._comment |   13 +
 ..._26af468952f0403171370b56e127830a._comment |    8 +
 doc/special_remotes/ddar.mdwn                 |   40 +
 doc/special_remotes/directory.mdwn            |   55 +
 ..._86f8c1b09cbd82bcd76378dfa1b3ca07._comment |   49 +
 .../directory/comment_12._comment             |   16 +
 ..._311cd013fd8db47856d84161119e059d._comment |   12 +
 ..._019660abe79fb1a3e6dbeb9a87a4c546._comment |    8 +
 ..._80d962f856de7510a437437fc0ca75e1._comment |   13 +
 ..._3d091c87c1e4d1c086fb88ae21137a57._comment |   12 +
 ..._32f6695042fe1f6e40a64a785fab59b9._comment |   13 +
 ..._01559b914ed43c4468e0980f3f794ea7._comment |   23 +
 ..._1b24ac6abc99e2e4bc8c9f4687c81395._comment |    8 +
 ..._0a6ae6ba0d2835da21fa62b2b376bf3f._comment |   41 +
 ..._e8a53592adb13f7d7f212a2eb5a18a31._comment |   12 +
 ..._981eeeaee76f89a59e2dcbb368c14387._comment |    8 +
 ..._4df82f23228dd2f95353f774d9bd8173._comment |   12 +
 ..._2be4b4e74a41723b72ef92a28f81a4dd._comment |    7 +
 ..._d949edad6a330079f9e15f703f9091e3._comment |   10 +
 ..._49009f4e9e335c9a9d0422aa59c9a432._comment |    8 +
 ..._f5e9b0b477c4e521f8633fd274757fa3._comment |    8 +
 ..._e790718423c41f5ea8047ea5225bfacd._comment |   11 +
 ..._325aac80b86588912c4fd61339ccbd0b._comment |   10 +
 ..._4206db69d68d9917623ce02500387021._comment |   12 +
 ..._acd9023511fe43817718bc89430f96c3._comment |    8 +
 ..._d330eb808a990bb71034613c297a265e._comment |    8 +
 doc/special_remotes/external.mdwn             |   39 +
 doc/special_remotes/external/example.sh       |  309 +
 .../external/git-annex-remote-ipfs            |  127 +
 .../external/git-annex-remote-torrent         |  205 +
 doc/special_remotes/gcrypt.mdwn               |   65 +
 ..._16a7b4978a58284b5ab3c58f2102e9d0._comment |    8 +
 ..._08245fd6716ee3ed5ac98fe95e7d5ca1._comment |   10 +
 ..._2b22c692fb98be1a964430b5b1a329a9._comment |   53 +
 doc/special_remotes/git-lfs.mdwn              |   93 +
 doc/special_remotes/git.mdwn                  |   18 +
 ..._4c76e1f29065cfb2f8bc05c187c1cc31._comment |    9 +
 ..._12c53dbbdb77f98f337ad60c67171337._comment |   12 +
 doc/special_remotes/glacier.mdwn              |   47 +
 ..._c0e841c3e305712d960e43a10e674215._comment |   63 +
 ..._e062b823b4d0b365698a6488d756b85c._comment |   13 +
 ..._a097d78d15e103c10f67e237c852b222._comment |   59 +
 ..._6ef8735fbd357a09dafe254c8da3b1a8._comment |   16 +
 ..._53c965ab49c75fe2220a04f014ba577f._comment |   56 +
 ..._e9df327e60ad0e69ace7102deef1efd8._comment |   22 +
 ..._ceb6a0cc74eea65fa60b58d1d000acf0._comment |   10 +
 ..._fcd856b99dc6b3f9141b65fe639ef76b._comment |   10 +
 ..._38fcca87074f6ea31a12569a822aa8c9._comment |   12 +
 ..._cea5bcb162e4288847ba5f25464a0406._comment |   28 +
 ..._0c92cc82c7ac513130f862391a02d329._comment |    8 +
 ..._8d1dcb4bf48386314bfb248ea6eeeb68._comment |    8 +
 ..._adb1db354dc4941e4b004e4ba34660d7._comment |    8 +
 ..._747e403aac5acaba00e220931e926951._comment |   10 +
 ..._a04bb5f27c1a7cfffe881903f973dbec._comment |   24 +
 ..._89c4506e079c299fd098d0fe746d032a._comment |    8 +
 doc/special_remotes/hook.mdwn                 |  112 +
 ..._6a74a25891974a28a8cb42b87cb53c26._comment |   32 +
 ..._ee7c43b93c5b787216334f019643f6a0._comment |   17 +
 ..._2593291795e732994862d08bf2ed467b._comment |   17 +
 ..._35d79b5ffa5a19056efcdc805070bc4b._comment |   18 +
 ..._6fbf1e963fa3ea4b2eb8ca5a3819762d._comment |   10 +
 ..._e0ab48d5333e5de85f016b097e6fdac1._comment |   12 +
 ..._cc2b1243c2c36e63241513bcaddfea67._comment |   10 +
 ..._bbae315233bda48eb04662dfd48cf1ae._comment |   30 +
 ..._037523d1994c702239ca96791156fe65._comment |   10 +
 doc/special_remotes/httpalso.mdwn             |   38 +
 ..._128e53b20a2f01bf55c83d52c4d42e93._comment |   10 +
 ..._aeeb2122814552f9cf83d950995b16ba._comment |    8 +
 ..._1c9384afe2779ab6c6ae689deea37b31._comment |    8 +
 ..._0bf4d78dec7ec997f781c5a46460b27b._comment |   13 +
 ..._500374b5826e87293dbd4e3aae570185._comment |   13 +
 ..._ee2c2a34e11bbbac835be7660830e298._comment |   10 +
 ..._cea7241b64264f3485e6759b9dc0dfaf._comment |    8 +
 ..._a5198f57b7eb6c458d5e88f8fc9776fa._comment |    9 +
 doc/special_remotes/ipfs.mdwn                 |   84 +
 ..._9fe1bef94c60fb47cad8b80b0cf0d722._comment |   10 +
 ..._1e38459dccd1ef3e23335e9bebca3241._comment |    8 +
 ..._5f8f72a832c8439e3769a1199dc46c4e._comment |    9 +
 ..._551c4dc55b73d6f07c4ddee546b5e938._comment |   12 +
 ..._8cfb0f54444e78089837e62502ef9f61._comment |   17 +
 ..._82b398be82a0b4ec7765606352ec0942._comment |   12 +
 ..._331655ed1b7ebb02444aa693b551e728._comment |   12 +
 ..._d1b2da148715476015716a2f866558b9._comment |    7 +
 ..._564271a8660d7bbade6e4ed396fcfb57._comment |   18 +
 ..._b8c7e402e0ee63d659ae33e3e2504ca2._comment |    8 +
 ..._06611859079239659ba7d73d655f517e._comment |   23 +
 ..._ba7d08b2bcb6614102c48b4cb3de5b1a._comment |   30 +
 ..._8621bbd87982f73cf401cfa09d95d1e4._comment |   10 +
 ..._062f266f26b5788b418de6955bff442d._comment |    8 +
 ..._eedf260df630192b49557bfc84c9ce82._comment |    7 +
 ..._630964c11465751773d1082e35737e70._comment |    8 +
 doc/special_remotes/rclone.mdwn               |   37 +
 ..._3fa761ad2e7a87e160b6d0e86814801c._comment |   10 +
 ..._e5babe3bc4535946ee04e8339403fda4._comment |   19 +
 ..._d946b28311da5e3632c651f52357a2c1._comment |    8 +
 doc/special_remotes/rsync.mdwn                |   61 +
 ..._43e8fa3517c1f5935f02ad06fbed63dc._comment |    8 +
 ..._8cafc1a8b37e6fb056185ec058c0c3e8._comment |    8 +
 ..._fa21b66a1722d226f1819646b9c45308._comment |    9 +
 ..._368f90773db9522c373168e127a39ae6._comment |   12 +
 ..._2261b1b7441eff9e28ec8e1f98d77980._comment |    9 +
 ..._a4a0491a7dcee2e7b7786127518866af._comment |   22 +
 ..._509514d6e3d790a80a2125068f499a72._comment |   11 +
 ..._9e180c397486989beab21699b8e8f103._comment |   16 +
 ..._25545dc0b53f09ae73b29899c8884b02._comment |    8 +
 ..._960a89b1ae7e3888ffba06baa963dc21._comment |   20 +
 ..._db84816c31239953dd21f23a8c557b43._comment |   15 +
 ..._ccaffa4aded9dab88c76a856b96ea5b9._comment |    9 +
 ..._e687b9482b177e1351c8c65ea617d3fa._comment |    8 +
 ..._e122979ea811d9ef835ba05bb936190f._comment |   10 +
 ..._d566113318d0aa7500d76ffe1bd46069._comment |   10 +
 ..._5dcf10a502b2d4feac46b620d43e9d00._comment |    8 +
 doc/special_remotes/tahoe.mdwn                |   47 +
 ..._90d6937e95301f83268e0c9190f0f8c5._comment |   19 +
 ..._d30f5958cca5dbcb93e4ea56a25586da._comment |   20 +
 ..._84d59f41949987381369ab75efc1b65e._comment |   24 +
 ..._8a425ab612c3b46efb9658ab79038661._comment |   18 +
 ..._11513056ee7de3dc8bf54c7e0948538d._comment |    7 +
 ..._588d129cc2eaf0a8df9fc2fc6de014a9._comment |   14 +
 ..._9b23112d568a7edfce05e95478c30e4f._comment |   14 +
 ..._5aa703bb3d3f7de9e78a6d831bd515dc._comment |    9 +
 ..._75eccd07ea57f44d5a198533a907225a._comment |   12 +
 ..._f5e45af55cd18af73e2d3d5911039418._comment |   17 +
 doc/special_remotes/tor.mdwn                  |   10 +
 doc/special_remotes/web.mdwn                  |   42 +
 ..._0bd570025f6cd551349ea88a4729ac8e._comment |    8 +
 ..._333141cc9ec6c26ffd19aa95303a91e3._comment |   11 +
 ..._e6ce9bb92c973350852c9498b7ffb50f._comment |   32 +
 ..._8a8369e0398a7ec6c65e493e4d836db9._comment |   22 +
 ..._1ad36ff51dfe69256fb0c8803da4efd6._comment |    9 +
 doc/special_remotes/webdav.mdwn               |   44 +
 ..._2c087a132c2203ac20636800bf73dfa7._comment |    8 +
 ..._cde4fccaf551ba1eab8235ebf6654316._comment |   10 +
 ..._76423262fceeced32ab18fa38ed53bdb._comment |   15 +
 ..._2390020fa7daac8a6d3e8b713bd3b8e7._comment |   12 +
 ..._45e3b7094d0611b2e082be352f74151a._comment |   18 +
 ..._d43673b8c8ed3534f31d026098ab673c._comment |    8 +
 ..._2a11dfc1fd159a6b9a25cde71ffec80b._comment |   17 +
 ..._cfd2786a998af5034dc707f23aa81678._comment |   29 +
 ..._c0aff1c36b500ae67c6cb4b34292a54b._comment |   16 +
 ..._8bf8d365c0a13f684ed9f9cb013396e7._comment |   10 +
 ..._6b523eea78eae1d19fe2a9950ee33e3a._comment |   26 +
 ..._a85a41709bbc0c7c138838ac94ba499f._comment |    9 +
 ..._e86cfc56014df46412f08b36bc019fb6._comment |   10 +
 ..._556386f26497f4075ab533e21e2077ce._comment |   13 +
 ..._b57fdd5322088e9b08dca7512c7e7793._comment |   28 +
 ..._6c16a7c9abb257be4d046e27e11bacdf._comment |   10 +
 ..._83fc4e7d9ba7a05c8500da659f561b8f._comment |   10 +
 ..._239367ad639c61ecdf87a89f7ac53efe._comment |   10 +
 ..._ffa52f7776cdc8caa28667b5eadae123._comment |    8 +
 ..._5b8cbdb5e9a1b90d748a5074997e1cd5._comment |   12 +
 ..._d3be3e588c3a2abb2025ceb82c18b0ef._comment |   10 +
 ..._6fa7e11331db5a943015bd5367eb3d73._comment |   12 +
 ..._2627b41f80c7511b27464e2040b128a8._comment |    8 +
 ..._b8f17efe524bb45a3e16705996df1265._comment |    8 +
 doc/special_remotes/xmpp.mdwn                 |    4 +
 ..._c7c2e2e81cb5b2b9a5272430c835dd39._comment |   10 +
 ..._05d9a67b9331656b4035399641cedb1b._comment |   22 +
 ..._568247938929a2934e8198fca80b7184._comment |   11 +
 ..._9fc3f512020b7eb2591d6b7b2e8de2d7._comment |   10 +
 ..._48ddbba1402d89acaea07cff747c48e0._comment |   28 +
 ..._59857879abaae22bde444a215e00bf18._comment |   14 +
 ..._583ee374bd34fcc9ae26c2fd690e8c47._comment |   73 +
 ..._8f0b5bba1271d031a67e7f0c175d67d5._comment |    8 +
 ..._ac7acbded03325b015959d82ae77faf1._comment |   10 +
 ..._81a9636a1e8a36a58185468a26f8633d._comment |    8 +
 ..._eda76b826491c96b1ce072aacf9d3adf._comment |   23 +
 doc/stickers.mdwn                             |   21 +
 ..._96f9b35048793c1cc0902cced82b65c5._comment |   13 +
 ..._39cfee29eae5e69d88d84b2c65eb83fe._comment |   11 +
 doc/stickers/hex.svg                          | 1017 ++
 doc/stickers/hexdemos.svg                     |  628 ++
 doc/submodules.mdwn                           |   22 +
 ..._936e145bbe3b6bd928571c17d3416937._comment |   12 +
 ..._78fffae9facce1600915bc19429d81e2._comment |   17 +
 ..._d59882712e0547c748d3b354e8607d62._comment |   19 +
 ..._15a2633524fc376b6a6c4f76187e435b._comment |   14 +
 ..._fb006a18240230aefb80ee8aeebdccb7._comment |   12 +
 ..._92cdc81ccc4831f5ad493736ca87e87d._comment |    8 +
 ..._9da0d19529dfb8a997ad469169e55895._comment |    8 +
 ..._9ccb133a957498724188a8749359a422._comment |   21 +
 ..._d1877da19346bbd6067ff95252974a9b._comment |   15 +
 ..._899cf2aa74cbb8160b1e249b314e7d60._comment |    8 +
 ..._8755b0d18c1b013ed0dc121ecfb83360._comment |   12 +
 ..._5e3a7d5c81fb37efbfe22cbbe8b8a247._comment |   16 +
 doc/summary.mdwn                              |   12 +
 doc/sync.mdwn                                 |   49 +
 ..._2cd8ab86f498d6f676f859b552f831eb._comment |    8 +
 ..._7683879f6982c0eb0aa39b66ff5a5ea9._comment |   10 +
 ..._2fea14fa314ddb7ab645a5cca5a95fd9._comment |   14 +
 ..._690f66be9cefe28844d8df653b7a0331._comment |   10 +
 ..._db342785a4dade30b5b75cb95031bed1._comment |    8 +
 ..._168e0ab10b4084e13df1a3058fa7e8a9._comment |    8 +
 ..._96096f994fc55f921f2b24b274f998f7._comment |    8 +
 ..._44a4ae4685c4bf2b4e7c61897eb3ff80._comment |   14 +
 ..._838fb249cd5be83962770d5cc394389a._comment |    9 +
 ..._d409ad20c5a6671f0d0b834232368030._comment |   23 +
 ..._59681be5568f568f5c54eb0445163dd2._comment |    8 +
 ..._537b27219871a565ae7bb7f357cd3793._comment |   10 +
 ..._9c0368eb796f1191c22c186cbb06c642._comment |   10 +
 ..._e83ed5c0034c48baed7943c596f708ae._comment |   17 +
 ..._e5e7ec9fbafe5e0429161b977e483752._comment |   24 +
 ..._1d1eb1bddc835644c7f9d6e83e09b752._comment |   19 +
 ..._7e69a963102ceaa5b691ad9ed15c5a42._comment |   10 +
 ..._ea6f4e1f5ab31cd74d67fe95e83084cb._comment |    8 +
 ..._8925805ff8902d7b2d1f47c1395aadc7._comment |   54 +
 ..._e5c5da7fc0d0d034bfae33481f1ae067._comment |    8 +
 ..._161c5d3f693de45070e037d27ee7e8aa._comment |   27 +
 ..._9301ff5e81d37475f594e74fbe32f24e._comment |   11 +
 ..._f75f5957dbd0f6fd7b2d7291f06e7489._comment |    9 +
 ..._c85edac65571caff70e87dff2317a4e5._comment |    9 +
 ..._49560003da47490e4fabd4ab0089f2d7._comment |    8 +
 ..._cf29326408e62575085d1f980087c923._comment |    8 +
 ..._18c396c59907147bb2bf713e55392b6b._comment |    8 +
 ..._012e9d4468d0b88ee3c5dad3911c3606._comment |   10 +
 ..._6276e100d1341f1a0be368f54de0ae7b._comment |    8 +
 ..._b89161c82c05634d35f6b65bf8360a96._comment |   14 +
 ..._849883b7cc05bfcb01914d8737098010._comment |   18 +
 doc/templates/bare.tmpl                       |    1 +
 doc/templates/blogpost.tmpl                   |   16 +
 doc/templates/buglist.tmpl                    |   27 +
 doc/templates/bugtemplate.mdwn                |   22 +
 doc/templates/note.mdwn                       |   12 +
 doc/templates/walkthrough.tmpl                |    2 +
 doc/testimonials.mdwn                         |   34 +
 ..._2bf439f7a3bc3d6fab91849017946182._comment |    8 +
 doc/thanks.mdwn                               |  448 +
 doc/thanks/list                               |  119 +
 doc/thanks/list.2018                          |  108 +
 doc/thanks/list.2023                          |  145 +
 doc/tips.mdwn                                 |    4 +
 ...les_in_bare_remotes_without_git-annex.mdwn |    8 +
 ..._9243af1c87fdaf33e336ec34e99c0f74._comment |    9 +
 ..._40__re__41__podcast__from_your_annex.mdwn |   15 +
 ..._37____38____34____35___Haskell__33__.mdwn |  111 +
 ..._835a3608df3e9d044cabe822d0f3e7e4._comment |   27 +
 ..._080b30cba72a718e73ea715e259e1cfb._comment |    8 +
 doc/tips/Bup_repositories_in_git-annex.mdwn   |   51 +
 ..._738959a699755704baab6df778ecd120._comment |    7 +
 doc/tips/Crude_Windows_Sync.mdwn              |   35 +
 ...tralized_repository_behind_a_Firewall.mdwn |   59 +
 ..._78b9035234a690ca5a7c9f3cc78fa092._comment |    8 +
 ..._in_special_remotes_without_git-annex.mdwn |  123 +
 ..._9288805fae0710b19da6c82f9dc32f2a._comment |    8 +
 .../Delay_Assistant_Startup_on_Login.mdwn     |   13 +
 ..._c63917150527efab4b1106183b3aa7ef._comment |    8 +
 ...h_autocompletion_with_big_annex_repos.mdwn |   50 +
 ..._a41fb1037186319bbb44f7a67df6120f._comment |    7 +
 doc/tips/Git_annex_and_Calibre.mdwn           |  108 +
 ..._b0ef346eaab9ff616aa1ba6b5f4530bc._comment |    7 +
 ..._9e8122ea81bbd0a86bd6c5173db801f8._comment |    7 +
 ..._ee1372977919229d17d216cfc3fb0f61._comment |   11 +
 ...ly_annex_a_file_already_in_a_git_repo.mdwn |   19 +
 ..._7eaf73fb3355bd706ab18a43790b3c10._comment |    8 +
 ..._dac1a171204f30d7c906e878eb6bd461._comment |   45 +
 ..._b62ec0b848d2487d68d7032682622193._comment |   36 +
 ..._2423904e41a86cd1c6bc155d7b733642._comment |    9 +
 ..._3062c0794ecd7c6237efae66f4d9b62f._comment |   13 +
 ..._1eceb980814f95b28caac9d4d9894f01._comment |   17 +
 ..._603db6818d33663b70b917c04fd8485b._comment |   30 +
 ..._834410421ccede5194bd8fbaccea8d1a._comment |   82 +
 doc/tips/Internet_Archive_via_S3.mdwn         |   80 +
 ..._d53a3848c20dce61867283fc03c2adaa._comment |   34 +
 ..._91c1472da27b00e5d682d22bc1ef04e0._comment |   10 +
 ..._e23cf781c532f80d47d52265f2b2c87e._comment |    8 +
 ...positories_with_large_number_of_files.mdwn |   55 +
 ..._3fac08b817ca3dbfcac3a03ce521464e._comment |    8 +
 ..._49585db4fbf9f22bf806ee08d73b7db1._comment |   10 +
 ..._e1f3b19d1dd62b1c9314e1e826fec54f._comment |    8 +
 ..._6b4cd0667d700c0c5ec6e0054b43f2e7._comment |   12 +
 ..._f8af84e301d271e9822556f23395dde7._comment |   22 +
 ..._71def7a311980e89a3b877175ea5bbe2._comment |   20 +
 ..._fac49a6d3f6a18c9925c34521221307d._comment |    7 +
 ..._f8417d9ebcfdcba34dfbbf76070ad95c._comment |    8 +
 ..._992f2a85ce0cdcef2f97ff978560fdb8._comment |   19 +
 ..._8ff3aa032fb778ff69276984152578b0._comment |   11 +
 ..._8540bf807eaf1b4e927eafc03deef304._comment |   21 +
 ..._9169a33c06cf8aea231cdd8f51ce17b6._comment |    8 +
 ..._f56f1ffeb5e1f382d3227b4ace7f84a1._comment |    9 +
 ..._25a26f5210986655808992533aa48d3d._comment |   14 +
 ..._c2b44076201d8152f16e12cb23c50397._comment |   10 +
 .../Shamir_secret_sharing_and_git-annex.mdwn  |   21 +
 doc/tips/Synology_NAS_and_git_annex.mdwn      |   59 +
 ..._ee03a12ac5ba760b038ac5b93eea4be3._comment |   10 +
 ..._ab2487da061a23e14198875a00ae801e._comment |   10 +
 ..._44b28cff77db57a83d9448f768695d2b._comment |   42 +
 ..._ef7e19f1fd2005eb7cc74509ffb92766._comment |    9 +
 ..._5e723ccf026fe970ad31207f9f036b69._comment |   30 +
 ..._8beb2b4b79c7787a92689aaad3bfc452._comment |   10 +
 ..._b04a1245378d3580432e85dff8eefdec._comment |   26 +
 ..._7e4ec2b22fb15e653d3b2274493e460c._comment |   11 +
 ..._954fc1b423208928fafdeb8cdac47c50._comment |    8 +
 ..._b862cb6ad0f912cc2ffede21df10c2fe._comment |    7 +
 ..._38775efe367033a9a96cf98a49f8cdde._comment |    8 +
 ..._52e1684fc40d1ab487a06cf13530871b._comment |    7 +
 doc/tips/Systemd_unit.mdwn                    |  103 +
 ..._06399a293f08401032bef1b94f05547c._comment |   25 +
 ..._389a2b36c3115eb3342429b0b68ddef2._comment |    9 +
 ...content_settings_for_my_android_phone.mdwn |   36 +
 ..._393d1636bb313530be383a075bd3440a._comment |   14 +
 ..._51a013213118660bdc06ff4d6c8110ba._comment |   12 +
 ...Git-annex_as_a_web_browsing_assistant.mdwn |   40 +
 .../Using_git-annex_on_NTFS_with_WSL1.mdwn    |  250 +
 ..._426bcb5c31f6ddf078b5f7c9bba00672._comment |   10 +
 ..._df6e152f1291c3dc1ba2b1b03b18083e._comment |   15 +
 doc/tips/Using_git-worktree_with_annex.mdwn   |   18 +
 ..._8e1493eae66a483ece338649c763115a._comment |   12 +
 doc/tips/ZSH_completion.mdwn                  |   13 +
 ..._a810be47633dc83d737a9ef6e8870431._comment |   12 +
 ..._0e6f7035350ec0c9c61eeafb02ab7af7._comment |    8 +
 ..._2bdaf6a00723b975808a52863e417321._comment |    8 +
 ..._182c13292016baf46d8f53a306cb4b05._comment |   15 +
 doc/tips/a_gui_for_metadata_operations.mdwn   |   13 +
 ..._1ce311d8328ea370a6a3494adea0f5db._comment |    8 +
 doc/tips/android_sync_with_adb.mdwn           |  116 +
 ..._18e0b24a2907ba8df033454315e50212._comment |   37 +
 ..._ae0ae08f76cce010999ec8d366f52400._comment |   19 +
 ..._68affd1a753abdeca0f161698cc63413._comment |   10 +
 ..._d3e6d777a26c6719df4fd2b4cf89763b._comment |   24 +
 ..._1ac315bee17c7f4cdc5de1427852d609._comment |   19 +
 ..._4aefa716b1d37b89c3dc002f85ab6607._comment |   18 +
 ..._44a985a0cbd0adfe3a2ca4ef20443083._comment |   28 +
 ..._036ff21f5eee0c165a41e472ffdfa341._comment |   43 +
 ..._af84d2eaeba2d5a8df087e097095eba5._comment |   10 +
 doc/tips/antipatterns.mdwn                    |  150 +
 doc/tips/assume-unstaged.mdwn                 |   31 +
 ..._44abd811ef79a85e557418e17a3927be._comment |   10 +
 ..._5b589f37cfc03bf7be33a51826cc4dba._comment |   13 +
 doc/tips/automatically_adding_metadata.mdwn   |   49 +
 ..._cf770ba8eed7963f08517877bd460d3f._comment |   20 +
 ..._6eeb21b66aa3541491ddc0dd3058ddc7._comment |   12 +
 ..._92c28dee004562d7085191f3b9e29fec._comment |   15 +
 ..._065b018dc290549b5ef00b50c3b09fcc._comment |   15 +
 ..._ffc308cc6aedabbc55820db4f401e0fb._comment |    8 +
 ..._bd64a53914107bc000c887b4d4bdf6af._comment |   12 +
 ..._02e5314f827d17d482343e8f22c42fd9._comment |   10 +
 ..._cd3c8e2f45db93576d1b82cfbfbe601b._comment |   12 +
 ..._888f0a77405d616a0d51a6176b44f605._comment |   11 +
 ..._34f0c55d09ddee3de642f6b25a9f6269._comment |    9 +
 ..._94877b21bf80374c2874b971f26f0e55._comment |   16 +
 ..._3880fb7f13e74d33d9c4e86772cc6b0e._comment |   10 +
 ..._db9c2fa8545188520d4bdda5ba545624._comment |   12 +
 .../pre-commit-annex                          |  118 +
 ...tomatically_getting_files_on_checkout.mdwn |   15 +
 ...n_doing_fsck_on_large_special_remotes.mdwn |    2 +
 ..._e7c5c46112a2406b873d08bbf53c40d8._comment |    8 +
 ..._daf45ce29fed986fa9aa8b173760d0b7._comment |   14 +
 ..._72d222020af4a9c6c753eb1ee7e1f1cf._comment |    8 +
 ...epository__58___starting_from_nothing.mdwn |   71 +
 ..._b0d22822017646775869ce1292e676f4._comment |    8 +
 .../centralized_git_repository_tutorial.mdwn  |   18 +
 ..._9072ebc0c61446d7b151fcfab616fea9._comment |   33 +
 ..._528e92b21f0551fde4adb956654953ae._comment |    8 +
 ..._8894229043935e70089caf67f0cc4ddb._comment |   10 +
 ..._b496622537d2491854b02884acf1672c._comment |   11 +
 ..._c6e3468c95bc875e17724ee4a3a283a3._comment |   11 +
 .../on_GitHub.mdwn                            |  129 +
 ..._98a1986ff2047de981d77755c462b690._comment |   14 +
 .../on_GitLab.mdwn                            |   78 +
 ..._9d0694204984ec96379a62f0f70ba696._comment |   15 +
 ..._1c33d3f62ec7119c116ad02b75c91f8a._comment |    8 +
 ..._7d3ea328a42c3a1df01f87e5233eca62._comment |    8 +
 ..._3c40b855e9914d8987b2f89d9abc29ae._comment |   14 +
 .../on_your_own_server.mdwn                   |   94 +
 ..._ae5af47faf95f008f1b07dbed5181286._comment |   28 +
 ..._b6a70e698eb4c46e753a620716c5956c._comment |   14 +
 ..._371f22ec58cf953c2b8abe3af71d3f91._comment |   10 +
 ..._6610f58b031d587f07f05b31754e4d97._comment |   17 +
 ..._b18e841b77cbec354d7641f37d030f49._comment |   15 +
 ..._a75d657dc322e1ccb02871492bef6f12._comment |   13 +
 ..._e818be55d40623167ce2d0381e7168e3._comment |   28 +
 ..._0778c23a67f7474753fb143ced6227a5._comment |    9 +
 ..._915965b46b03186eec466c51131c734c._comment |   50 +
 doc/tips/cloning_a_repository_privately.mdwn  |   57 +
 ..._f5490d034074ca80a712bdd41c307139._comment |   39 +
 ..._0fb78b2183932da08809d60dfc5a7374._comment |   37 +
 doc/tips/deleting_unwanted_files.mdwn         |   38 +
 ..._2d3cf347c754047875a26d7f73c6fbb2._comment |   15 +
 ..._8471758f2e02ebcfd9c015691ba9f15f._comment |    8 +
 doc/tips/disabling_a_special_remote.mdwn      |   35 +
 ..._8762ffef0024a9396979fc2586965c5d._comment |   28 +
 ..._325dc29b8e82595806741b0ff8dd6215._comment |    8 +
 ..._6c7c92a9c5ce9cee1450117f0bab1354._comment |   18 +
 doc/tips/downloading_podcasts.mdwn            |   94 +
 ..._4d4f6c22070b58918ee8d34c5e7290ad._comment |    8 +
 ..._d8d77048c7e2524968c188e1ad517873._comment |   24 +
 ..._0859317471b43c88744dd3df95c879f7._comment |   10 +
 ..._e8c3c97282d17e2a1d47fb9d5e2b2f7b._comment |   18 +
 ..._05a3694052de36848fbbad6eeeada895._comment |    8 +
 ..._21028bed8858c2dae1ac9c2d014fd2a1._comment |    8 +
 ..._4869fb5c9f896acc477c44de06c36ca7._comment |    8 +
 ..._2e278ff200c1c15efd27c46a3e0aed40._comment |    9 +
 ..._382f2b970738d9b1af577955c3083e90._comment |   15 +
 ..._f76fc6835e5787b0156380bf09fd81ca._comment |    8 +
 ..._f04bc32a34baeeffcd691e9f7cce0230._comment |   13 +
 ..._65ebf3a3bbf0a2aebd2b69640b757e16._comment |   10 +
 ..._98a1dacc8d264ff31801e6c5c5f2612d._comment |    8 +
 ..._00cc7a2fb936d7ea3d5d3764a1637663._comment |   10 +
 ..._62603cda8e581a2eb2cc799dffe8a740._comment |   15 +
 ..._e75af243654d15bc7b917fcd888bcf2f._comment |   13 +
 ..._2ee88c3375eca23fe34cab65df1e7aeb._comment |   17 +
 ..._a69b4c033d85406675bb70e6996590ce._comment |   18 +
 ..._e343aeda7c16c834599fb3caab2a51a2._comment |   14 +
 ..._f57a89a32a55dfae0dfa237a8981a667._comment |    8 +
 ..._a9a98cad7358d16792853a2ee413fe6c._comment |    8 +
 ..._5a8068a5cb0fd864581157a3aa5d1113._comment |   10 +
 ..._e7072a9da30b4c4b4c526013144238d4._comment |   10 +
 ..._79b3f8d678ac9f67df4c0cd649657283._comment |    8 +
 ..._35106fee5458bdd5c21868fbc49d3616._comment |   10 +
 ..._ceb16498b7aadbf04a27acd5d6561d46._comment |    8 +
 ..._147397603f0b3fdb42ca387d1da7c5ef._comment |    8 +
 ..._6a26a6cc7683d38fae0f23c5a52d1e23._comment |   24 +
 doc/tips/dropboxannex.mdwn                    |   12 +
 .../dumb_metadata_extraction_from_xbmc.mdwn   |   29 +
 .../git-annex-xbmc-playcount.pl               |  227 +
 doc/tips/emacs_integration.mdwn               |   25 +
 doc/tips/enable_tor_on_nixos.mdwn             |   55 +
 doc/tips/file_manager_integration.mdwn        |  123 +
 ..._0f82520f415b4715946358658e1799a8._comment |    8 +
 ..._9cb6b7fcb8e33a75efd2f92d7e40a9c5._comment |    8 +
 ..._e7096737268cf66fce2709e9e4937f51._comment |    8 +
 doc/tips/finding_duplicate_files.mdwn         |   21 +
 ..._5efc6b6ee1dfec88512183e9679ca616._comment |   24 +
 ..._630b065f41019716a5f6848e0adcd0f0._comment |   29 +
 ..._21f6ff2f7c51ca148fb8836a5e325e23._comment |   11 +
 ..._cd191275a277aee5de80507d5b5da69b._comment |   17 +
 ..._05827cf95647c56c344d150564cdf01d._comment |    8 +
 ..._9ea2c23d6099281f55122e39655d7353._comment |   49 +
 ..._ddb477ca242ffeb21e0df394d8fdf5d2._comment |    8 +
 ..._900eafe0a781018ff44b35ac232e3ad3._comment |    8 +
 .../comment_3._comment                        |   39 +
 ..._1494143a74cc1e9fbe4720c14b73d42b._comment |    8 +
 ..._1a35ca360468bcb84a67ad8d62a2ef7d._comment |    8 +
 ..._a6e88c93b31f67c933523725ff61b287._comment |   16 +
 ..._347b0186755a809594bd42feda6363e2._comment |   10 +
 ..._3af51722da0980b724facb184f0f66e9._comment |   10 +
 ..._7b4b78a5cd253abfe4f6001049bf64f3._comment |   10 +
 .../finding_which_file_matches_a_key.mdwn     |   18 +
 ..._0379aaad5d1dc13e90c13ddd82719ce5._comment |    9 +
 ..._8feecf0ed92b958c902ea2032b5d9576._comment |   13 +
 ..._1775ca681b8471938a0173b21019f743._comment |    8 +
 doc/tips/flickrannex.mdwn                     |   50 +
 ..._50707f259abe5829ce075dfbecd5a4ba._comment |   13 +
 ..._ab5bcb025381b3da4d7c6dfd0c7310dd._comment |   46 +
 ..._90a331275d888221bc695003c8acbe46._comment |   58 +
 ..._1596e70dca71c853fd1d6fc9bde02b18._comment |   12 +
 ..._c728f10074d194efa8b2c60e97d275e7._comment |   12 +
 ..._2dd75800e4db58761fcbbd1954a36f1f._comment |   11 +
 ..._2f65093ec9f6d67d2cfe5b5fae201123._comment |   10 +
 ..._5bfe0988260b7825eeec204cd8f79b98._comment |   31 +
 ..._ef71e2f8c48b0399d9fbc419e850dc5d._comment |   12 +
 ..._d74c4fc7edf8e47f7482564ce0ef4d12._comment |   10 +
 ..._f53d0d5520e2835e9705bea4e75556f0._comment |   30 +
 ..._9ebba4d61140f6c2071e988c9328cf7e._comment |   14 +
 ..._4470dae270613dd8712623474bc80ab0._comment |   24 +
 ..._d395cdcf815cb430e374ff05c1a63ff4._comment |   17 +
 ..._8cf730097001ffe106f2c743edce9d0a._comment |   12 +
 ..._a80c8087c4e1562a4c98a24edc182e5a._comment |   12 +
 ..._94f84254c32cf0f7dd1441b7da5d2bc6._comment |    8 +
 ..._5299b4cab4a4cb8e8fd4d2b39f0ea59c._comment |    9 +
 ...ncrypted_git_repositories_with_gcrypt.mdwn |  156 +
 ..._4440a80d64c60c7312d5c405d54e607a._comment |   15 +
 ..._28eb9d4ebf28ca310f9b357b1dad244a._comment |   30 +
 ..._b697b2ab10705b090a78e7717ec59b18._comment |   10 +
 ..._4e37146a870576f09f56d2e5ee784ed7._comment |   23 +
 ..._2044e821d841fcd37a51ae768fa88df2._comment |   12 +
 ..._de4838d82987685896d4c76dac7cdb6c._comment |    9 +
 ..._c1194234e9f4fd469fa4b9fea72219e1._comment |   32 +
 ..._098998132fb0bcf130b5bf8a16ac8b8a._comment |   54 +
 ..._bdcb4bace530ac8b2018916893ae7e93._comment |   87 +
 ..._5c54690586f2a781905ea4b25aa1147f._comment |   18 +
 ..._07feedb4348f8c31176cc744c19368a1._comment |   21 +
 ..._c2f873dffa015f1d72ad0c3921909316._comment |    8 +
 ..._f8a6e4415f4fe6da14f6a3b7334bc952._comment |   18 +
 ..._11b8e82d2a234f65b58b823e71c6d6a2._comment |   10 +
 ..._3e41948e1beffcf279bb05ef8e61cc07._comment |   16 +
 ..._4ce0b26b25b336f07b2e27246cdfba3e._comment |   16 +
 ..._49aa34d75d24a2066baa8a585bc9c2e9._comment |   14 +
 ..._3784e0c828cd60b6a9075c2d32d070cc._comment |   14 +
 doc/tips/get_git-annex-shell_into_PATH.mdwn   |   55 +
 ...ons_for_ranger__44___the_file_manager.mdwn |   28 +
 ..._358d4041c0158c247340cd4588286df4._comment |   20 +
 doc/tips/git-annex_on_NFS.mdwn                |   75 +
 ..._e2e99f2c484597c0d314ae597be078c3._comment |    9 +
 ..._06f2ee5095cd35063a434560375e172e._comment |   26 +
 doc/tips/hashdeep_integration.mdwn            |  114 +
 doc/tips/hiding_missing_files.mdwn            |  146 +
 ..._eba2b140f9d5a9f7ee23cb3ba7da7612._comment |   16 +
 ..._9bff461eb281f67d169d4be30129bc13._comment |   10 +
 doc/tips/imapannex.mdwn                       |   25 +
 doc/tips/install_on_Android_in_Termux.mdwn    |    1 +
 ..._dc277facdcfba4e175831467b0e450d5._comment |    8 +
 .../old_comments.mdwn                         |    1 +
 ..._8c24553afc5352c8a4c9cd0555423325._comment |   18 +
 ..._8f5f8f47305b45dca53222ac0e3bde29._comment |    9 +
 ..._a7bbf9e61e2e993eca9a9222de899920._comment |   15 +
 ..._b46679eac8d4d86b2abe9baff1f0a609._comment |   15 +
 ..._20a995c941f9a3582a8913d412e3d090._comment |   35 +
 ..._387e69f3ed94a00c01b0a097132f989c._comment |   12 +
 ..._2d7181f765cdbf545f161825c4cfeca9._comment |   11 +
 ..._37ba50a8378b2ac3d920fc8155eea42a._comment |    9 +
 ..._c1b5fefdc9a654579d0ada3db7a40ad8._comment |    8 +
 ..._5e0aa7c4341867374a67f5fe0a242e00._comment |    8 +
 ..._320b1fa3328cf8b8e584e72a9cd7735a._comment |   13 +
 ..._9651ab0e1e43d193cca16963f5fde858._comment |    9 +
 ..._3d1c6a1dc4ff8f04dffa4a02ad56fef2._comment |   18 +
 ..._39e2f2100a49f986760db389cf10240b._comment |    9 +
 ..._3a8c8facaa8b2989c88ebaabb984c7de._comment |    8 +
 ..._663de2e553ea050dd5a00fc88aeb6412._comment |   26 +
 ..._338e7f1b0fdf273d5fa453fe8ed2578b._comment |    8 +
 ..._82c4de6ad0ff016e72133d2552b5158d._comment |    9 +
 ..._66bfd7ca3dd81bb7632cb91fd8637dae._comment |   13 +
 ..._b475d3c36cf6d52d6b4720d00a5ae245._comment |   10 +
 ..._35329178895fc03395f08a37044e7c94._comment |    8 +
 ..._7ae18460ca6201cc313215a8a03e0d57._comment |   44 +
 doc/tips/largefiles.mdwn                      |  123 +
 ..._18f17926c44ea4b0c17a61a91c6bb5b5._comment |    9 +
 ..._e7c83e38c92b8fc91bae140c1d7c007d._comment |    9 +
 ..._16176199c4c98c66dd40b5eae95122ed._comment |   13 +
 ..._b541d011d4c7f23227426c783a4bdc20._comment |   11 +
 ..._2f8d8e73e4218b1e36e358770016cabe._comment |    9 +
 ..._cd71d1c6e69a9fc7feadf9aa6a39c406._comment |   14 +
 ..._d1f24df21ac577b89a8ae385532de6f2._comment |    8 +
 ..._4c6f52958246757dfbedd0b410d43ffe._comment |   11 +
 ..._066fdebc2655dd11077fda1ef6e102e4._comment |    9 +
 ..._b84e5cb8316c30fc7b355234384a5899._comment |   10 +
 ..._825b72391117f88062a585684cf62eeb._comment |   13 +
 ..._f4df42fe943011cc8feb2921a59616e9._comment |    8 +
 ..._b6380286f60c1cd46a82a2e90c7aa05f._comment |   14 +
 ..._20c6702f83dbade1ac4d6eee30c40b4b._comment |   32 +
 ..._639b1492271643566846b48fe13f7b8d._comment |   22 +
 ..._35a634c5e6d780972b9e938065837988._comment |    9 +
 ..._f036356b23a4690705a2b4df604e82ba._comment |   21 +
 doc/tips/local_caching_of_annexed_files.mdwn  |  105 +
 ..._c93895a509ab4e458043450bccf930dc._comment |   23 +
 ..._5bf79eae24dd6b69daa1cd10e0b4d296._comment |   14 +
 ..._cbc8fbd8a98574683008ca363d3ac6b7._comment |    8 +
 ..._18514bbfab0ff0d8a70ce5b08436cd44._comment |   11 +
 ..._7afa02db922ef1ad9d4031a87e4b688c._comment |    8 +
 ..._a1ce74ef47a0512bc56ff323c2c03c75._comment |   12 +
 ..._3f4950f7dc51472b5f0405baeac187a0._comment |   10 +
 ..._d1f0d7ac76f704ea71c4971ee7ed0cde._comment |   11 +
 ..._6b21f1ed5a2cbbba7c7042dcfec080a8._comment |   10 +
 ..._490c15d7673c535e83c7f1df3082e7ed._comment |   10 +
 ..._ad1ab9d78cc0c45fcda54bf9f03b4f8f._comment |   30 +
 ..._af084d315d82c1bae85122939042305b._comment |   76 +
 ..._3776a0371faccc673c868323278f3b0d._comment |    8 +
 ..._b047ea1c6b9247a42b560a111d4fdeae._comment |   17 +
 ..._994f408b01fa09e80599538a4ff28485._comment |   32 +
 ..._d3ac760cfee0decfbcb4f81ddbc39a3f._comment |   11 +
 ..._2a80533f259cde64662db7e6a1c1742c._comment |   28 +
 ..._42906e52528907a0960ab8b08c2eedd4._comment |   20 +
 ..._dc1e5e3d256a2618f6c2a7864b01c08e._comment |   51 +
 ..._c0d79b07a4c83c9d081d7c8f702fa4dc._comment |   10 +
 ..._ffdf07bac38a6c29b799281441fd32c9._comment |    9 +
 ..._0e4571cc81ade6510b7a1ddfff9cb055._comment |   12 +
 ..._7db7787a306c70ba3c1687c1d103608d._comment |    9 +
 ..._update_when_changes_are_pushed_to_it.mdwn |   25 +
 doc/tips/mc_menu_integration.mdwn             |   18 +
 doc/tips/megaannex.mdwn                       |   14 +
 ..._eec701662debd2a78c48243dbcebf59a._comment |    8 +
 ..._c1158b7ec15646d64cae8215ce845642._comment |   10 +
 doc/tips/metadata_driven_views.mdwn           |  152 +
 ..._1d6793701fd8a1a66bae04662cf853ce._comment |   12 +
 ..._13ae4e3668b693c0eefaca23b88515cf._comment |    9 +
 ..._196f55e52a5d8a8f061603ab87ad04ad._comment |   18 +
 doc/tips/migrating_data_to_a_new_backend.mdwn |   31 +
 ...disconnected_directories_to_git_annex.mdwn |   77 +
 ..._d94ae69945416e57faa6e6dd5536f66e._comment |   59 +
 ..._c6c11a9d5f9f136fa541404cdc49f45c._comment |    8 +
 ...remotes_accessing_the_same_data_store.mdwn |   61 +
 doc/tips/offline_archive_drives.mdwn          |   69 +
 ..._3d4fdf42191a9d81434d00f51c3609ff._comment |   12 +
 ..._864c752aa8d064791a4b14dbbe2e6882._comment |   15 +
 ..._7be2ccaf70c9ecfc9a34384e0e31f490._comment |   10 +
 ..._f9f2f8c59818d3d48475fa3cbf339ba3._comment |   19 +
 ..._25c92a3602a1365d68e6bab080e4a41d._comment |   28 +
 ..._f64f48f2bb5325bf9e14e2aa96a94429._comment |   17 +
 ..._c8b506c4b2da98be430016e219680e34._comment |    7 +
 doc/tips/owncloudannex.mdwn                   |   14 +
 ..._129652308c3c499462828dcaf8e747a4._comment |   40 +
 ..._38604990368666f654d41891ba99ac61._comment |   15 +
 ..._1bfd290d00d6536da7d31818db46f8ec._comment |   87 +
 ..._492b6922a7c5bb5464fedb46b0c5303b._comment |   17 +
 ..._1d48ac08714fadcb06d874570d745bd8._comment |   16 +
 ..._65959f49a2f56bffd6fe48670c0c8d5a._comment |    8 +
 ..._7482002991672ef67836bae43b8d0be8._comment |    8 +
 ..._6579203d726f4a39db02fcdda156e12c._comment |    8 +
 ..._e52582d76e9b57cc11791f2730389605._comment |    8 +
 doc/tips/peer_to_peer_network_with_tor.mdwn   |  232 +
 ..._72d4ea5ffa23f5048c453c2e7510e2f0._comment |   12 +
 ..._8180e202fc493ad07999a3367ccd9425._comment |   15 +
 ..._9fc514cf5273dd4a29dfb3ab81346425._comment |   12 +
 ..._917eee70600e13470f70555abe06597d._comment |   16 +
 ..._6db70bb9266a92e249587bc4d095c472._comment |    9 +
 doc/tips/playlist_fetch.mdwn                  |   29 +
 ..._5310fd53406d35f36deff68e8c2cb599._comment |   14 +
 doc/tips/powerful_file_matching.mdwn          |   36 +
 doc/tips/public_Amazon_S3_remote.mdwn         |   61 +
 ..._a2684b49dbc2de45b644523f47b3c891._comment |   48 +
 ..._f155c3aa054a23df1ab057baaa300a62._comment |   15 +
 .../publishing_your_files_to_the_public.mdwn  |   78 +
 ..._40f690c59de96159da96855c61bb5963._comment |   14 +
 ..._0287fd56eea34fcd5831768252335a7b._comment |   23 +
 ..._4ae6d6c5137e5f9b667417c2c77fca85._comment |   18 +
 ..._33b50a2de3f1268c875fc388a85c0296._comment |   11 +
 ..._3216edeefa99f484194d6de061283170._comment |    8 +
 ..._06cba66922cc382c112fdac52b98bb4d._comment |    9 +
 ..._caf9ad71e3805347df98f4d6df352cec._comment |   19 +
 .../old_method.mdwn                           |   88 +
 ..._48f545ce26dbec944f96796ed3b9204d._comment |   21 +
 ..._27a40806d009d617b3ad56873197bf87._comment |    7 +
 ..._2f5045629e40e8d881725876190c7846._comment |    9 +
 ..._37405f20da790141187e9f780c999448._comment |   11 +
 ..._29c3ee4aed6a5b53b6767a96a7b85ad9._comment |    7 +
 doc/tips/recover_data_from_lost+found.mdwn    |   18 +
 ..._f0901527a4f0faf0b1fd916d5b809314._comment |    9 +
 ..._ac405575058beeac992d07c55f7c53a8._comment |    8 +
 ..._02cb9efd54d8447d0bd11e5981e7dca7._comment |   13 +
 ..._960fcfe8c5c7bcb7350f61ecfb84f36c._comment |   27 +
 ..._e887b2d2ecbce3de22c517afd500e783._comment |   13 +
 ...overing_from_a_corrupt_git_repository.mdwn |   17 +
 ..._f5827be97f78dbae113a5ba0c9ced896._comment |    8 +
 ..._e98df7275bb032308bb87e3607bdde32._comment |    8 +
 ..._11bece6dfac090edbcd783b266c482a3._comment |    8 +
 ..._86e99017f7585ac2f76753051214637e._comment |    8 +
 ..._c8953732ce353cdf0c4fb81ddc98c04a._comment |    8 +
 ..._d0da84df0241dc6ccf0aa0c7598917df._comment |    8 +
 ..._addf49556e4c33d55a41c393f519d0a4._comment |   10 +
 ..._505a2fc2b841fe8eb419801f923ef35f._comment |    8 +
 ...ry_by_converting_git_files_to_annexed.mdwn |   53 +
 ..._aece062800c6ed78988161d40e36bba4._comment |   11 +
 ..._6b682415956756b969767f7de267f1f0._comment |   13 +
 ..._7e92db3d8a392e43b305fa8ecc0e39d3._comment |   39 +
 doc/tips/remote_webapp_setup.mdwn             |   49 +
 ...e_or_dvcs-autosync_with_the_assistant.mdwn |   41 +
 ..._d1bd5d6b33951f6d11185bb4a8228269._comment |    8 +
 ..._54692ebf854ecbcc5314bb29c33ecc66._comment |    8 +
 ..._907e4032ca4a39adb846cf16dbf447dc._comment |    8 +
 ..._902d001ba86657ef0f8cca5b175f99ca._comment |    8 +
 ..._a1cf93f9b29658f0f26e9e0ae6057ee3._comment |   60 +
 ..._e10671908b58c554375787d0f76e2366._comment |   13 +
 ..._4114380f66b6376c851e93f6876d590b._comment |    8 +
 ..._6a5d6af107b297afd008b021f73d787b._comment |    8 +
 ..._74d57cf503a86d8f7ace2d769dbb58be._comment |   10 +
 ..._85765c0cfeb5b326c06cf60c98147cbf._comment |   21 +
 ..._082b5d90ffc836e7c86e40b63a75780d._comment |    8 +
 doc/tips/semi-synchronized_remotes.mdwn       |  138 +
 ..._d0459d72b7e0441fe833a5c8e1588a4f._comment |   19 +
 ...tup_a_public_repository_on_a_web_site.mdwn |   31 +
 ..._5554d52c568fdd5235c498ba999545cb._comment |   11 +
 ..._5fc7b153f1822c8ae2d415963fcb9ce2._comment |    7 +
 ..._eb732e9c1c44942bc313aa1ab3ff56fc._comment |    8 +
 ..._4332e21dcbe4fdcbab58f01aca295fc9._comment |    9 +
 ..._1d0fa6da33e401df1d7ff31979247fec._comment |   10 +
 ..._b98b761dee9d923153e3c288c1d987ee._comment |   11 +
 ..._a6698218f15c598c9b32e0af850133bf._comment |   12 +
 ..._e20ea0dc04d4d62b699271483f81a136._comment |    9 +
 ..._0bb7c62b71d2c9da6fbfe8f889baff38._comment |   48 +
 ..._89eac454cfbdffabb916355b355e1b94._comment |    8 +
 ..._6015b7ad6a19f412d0b50bfb3a661fe2._comment |    8 +
 ..._ceb528ff60b9c7544eae28292ef74ddb._comment |   25 +
 ..._2dfb5b225ed62c0310ddadb0d83ceb79._comment |   55 +
 ...nnex_directory_between_multiple_users.mdwn |   39 +
 ..._01db8cf9dff016bd8e0498d36f325418._comment |    8 +
 ..._07ad0b2f6fd2644241a605a10d8fb8d0._comment |    7 +
 ..._3bfb9e0e028f71c8a47e5363dcfdbd36._comment |   12 +
 doc/tips/skydriveannex.mdwn                   |   32 +
 ..._c3465b5587548dea56b80b32cd66d653._comment |   16 +
 ..._13692d8cb9ccf10ced26d90739385a6a._comment |   47 +
 ..._bf383481b2bbb962fbfe783b9f2f213a._comment |    8 +
 ..._1f747018b35ab8accd2bf0905e6ad926._comment |    8 +
 ..._8b9444006734262693f71e50a40eae1d._comment |   19 +
 ..._8b01dc6ca1082a8c24ff65fec9d759d8._comment |    8 +
 ..._1d220d96945d497f3a93b5d848eb3995._comment |    8 +
 ..._a7a3afdc7eed9a0eda48dcb57f1e87c6._comment |   12 +
 ..._7fcd9c6b5e2a3fc7b753eeac06164036._comment |   18 +
 ..._856eaa1b167033aede91a937099c7833._comment |   18 +
 ..._cfcf767a1bf07957b76d7f44ef8a9500._comment |   14 +
 doc/tips/splitting_a_repository.mdwn          |  126 +
 ..._654527ef2350fe871e2d7ff6addc6713._comment |   25 +
 ..._2437e95397e1b06ade5360405e399591._comment |    8 +
 ..._c0ccbf6758eabf645075d3b84188825e._comment |   12 +
 ..._fbf9d86fd3aee4542a7cabacce9578cd._comment |   31 +
 ..._baf4871cb78b337c627a352333c4e39d._comment |   25 +
 ..._ce243a141a286e5e1a55af8321238b5c._comment |   94 +
 ..._0d11c72712da0cf36b8cc91ba7501d52._comment |   15 +
 ..._72ebd848d406190e12e3291cff824f7e._comment |  137 +
 doc/tips/storing_data_in_git-lfs.mdwn         |   69 +
 ..._e4eb406a4bf146c1f442047a4c1b1e1a._comment |   24 +
 doc/tips/transmission_integration.mdwn        |   11 +
 .../transmission_integration.sh               |   38 +
 doc/tips/unlocked_files.mdwn                  |  160 +
 ..._add35d419c7735571208aa5e47437f99._comment |    8 +
 ..._08102655fbb13e4977e82f3f097f28db._comment |    8 +
 ..._8cd7855dc6419297174a32e847e5f49a._comment |    8 +
 ..._99f82c84aa9d886062aa3e3956e1acf8._comment |    8 +
 ..._e3425d219001fc34470f0cd55fc7241e._comment |    8 +
 ..._4be14df022612d6301442b3210a17d0a._comment |   11 +
 ..._61121c6b95e1310df8132aca13924b88._comment |    8 +
 ..._15c6f8db289812e76859b21d158b1b2e._comment |   21 +
 ..._29cef6b8e48e722fafed3fe9b7cefe08._comment |   14 +
 ..._54a1811ef2f57f0843e48572ab6713b8._comment |   15 +
 ..._f5f29661bd04a6bba6158307465981d9._comment |   10 +
 ..._a8139747da8cbb2510b3647ba448d72d._comment |   20 +
 ..._8225cb96640697d4955badfee5b75e39._comment |   22 +
 ..._666d88b862a7f6f5cd719e454a8a6469._comment |   11 +
 ..._46ff6b142c4cc9ad07b0c8dc07ba9c09._comment |   16 +
 ..._9e5d1a9523239cb601612951af5eb9f1._comment |    9 +
 ..._1cfd5f680f2d19ea1039ff0e7324083f._comment |    8 +
 doc/tips/untrusted_repositories.mdwn          |   28 +
 doc/tips/using_Amazon_Glacier.mdwn            |   74 +
 ..._ccee7f4f5a483a3650270b6e09ab7293._comment |   36 +
 ..._d34e05f9244d3a4fcec87b3c360adb4e._comment |   10 +
 ..._4c504fd22775afe36296cf54d3e04a8e._comment |    8 +
 ..._e6ac76b0c20285f4f96b3d0975e8ac66._comment |   21 +
 ..._7788890f58f714b0cdf1462c718ea536._comment |    8 +
 ..._0fbe528a57552622e8128196ad80c863._comment |    8 +
 ..._a83cfe55f4c70bd8801e0c05c5be8323._comment |   22 +
 ..._ddef6cc5d1a5fd3d69cfe8cccfa58a53._comment |    8 +
 doc/tips/using_Amazon_S3.mdwn                 |   43 +
 ..._43f3f12a83e3ace1674eae395b865409._comment |    9 +
 ..._70b4e62aabb93d078811cbdcd3cced20._comment |   24 +
 ..._d00472bf4ac5f7b2212073c081ba04c2._comment |   12 +
 ..._30bdbd217fd2b603984cf7d3a3dce266._comment |   37 +
 ..._5bb12e6fa51da00ecf48f2dee1bfb050._comment |   14 +
 ..._d8cc20706debc17f4f738d2019577dea._comment |   25 +
 ..._bb2cb128d9c6a8e9176604cef1f6fc91._comment |    9 +
 ..._666a26f95024760c99c627eed37b1966._comment |    8 +
 ..._f5a0883be7dbb421b584c6dc0165f1ef._comment |    8 +
 ..._32acba030c2ad252e2f7027075e4303e._comment |    8 +
 ..._92df5a9f923beafba55a1c455728112e._comment |   13 +
 ..._6b288e06010bedbb71e0afed6b427704._comment |    8 +
 ..._3b6c74b40ea666389ac04b52ab0819a0._comment |   10 +
 ..._cf6755d88463878f2ea6e4c300899027._comment |   33 +
 ..._4f9c2f6627f8ed3423bcc8b7bf2f76cb._comment |   10 +
 ..._47e4ea77d0262d332d86a06d7aaeddd8._comment |   11 +
 doc/tips/using_Backblaze_B2.mdwn              |   25 +
 ..._b8b045d5f3d2bed1905c05b4fa00c5ca._comment |    9 +
 ..._d7fd727cb38a0290de10f06539a23d27._comment |   12 +
 doc/tips/using_Google_Cloud_Storage.mdwn      |   19 +
 ..._c576182f39563ae68767391c4227a177._comment |   18 +
 ..._0843bfb776b8b6d5de4de7fda4489f34._comment |   15 +
 ..._9738f145014d8eae1f1aae7c39e71d31._comment |   12 +
 ..._63f29692ef270cd4a196ec94ff97185a._comment |    8 +
 ..._865f27a393f24fd5723c895d4d70dde3._comment |   17 +
 ..._d1462d9d1d425e609bf8ad8fb8f0a9d5._comment |   14 +
 ..._6896ea720bb29db35db4c5e2463fa818._comment |   13 +
 ..._1b4eb7e0f44865cd5ff0f8ef507d99c1._comment |    9 +
 doc/tips/using_Google_Drive.mdwn              |    9 +
 doc/tips/using_Hubic.mdwn                     |    9 +
 ...fficient_storage_of_old_annexed_files.mdwn |   60 +
 .../using_box.com_as_a_special_remote.mdwn    |   81 +
 ..._be39f063e8a6155cc2eb71829e884a63._comment |    8 +
 .../using_git-annex_from_your_program.mdwn    |  100 +
 ..._no_fixed_hostname_and_optimising_ssh.mdwn |   59 +
 ..._c0b7682a2b6f3078457b85683c825baf._comment |   10 +
 doc/tips/using_gitolite_with_git-annex.mdwn   |  149 +
 ..._8767bc8014b459a3cd76f275fd4fa8d6._comment |    8 +
 ..._00715e0b47f09130e0e536e29f7b9258._comment |   31 +
 ..._7027ce60265b8f24c8ab54553e544068._comment |    8 +
 ..._75218b7409c0e281cb01c9b2791e8cdf._comment |   20 +
 ..._7d4d4515218d1259d32be3baeb5ee56e._comment |   13 +
 ..._dc6f21b5a3d5931c8d949a9753411b9e._comment |   29 +
 ..._8e5039e6655fc80dc863b6cdf44ef02a._comment |   15 +
 ..._9c40e1da8bb44f7207e802377f5cf923._comment |   11 +
 ..._f1a180d5cf65b7a870a13ddb4f76d00d._comment |   21 +
 ..._33c19097b6f2b48dfe09ec4c8d952d06._comment |   11 +
 ..._9a2a2a8eac9af97e0c984ad105763a73._comment |   15 +
 ..._c82af00db3dd74ee9bfe12668e76e57b._comment |   13 +
 ..._d2feaaf22d41413048dabf706d1b267e._comment |    8 +
 ..._90ead0e1fe8615fe11f6f1bd7dcd7e84._comment |   13 +
 ..._70dcb7e7ffdd14351adaf4c40ee7fdd0._comment |   29 +
 ..._a62f59295b3912dc38def5e493bdb55a._comment |   23 +
 ..._08b3b257b3dbd32cb807e29f512ea9c9._comment |    8 +
 ..._d8efea4ab9576555fadbb47666ecefa9._comment |    8 +
 ..._807035f38509ccb9f93f1929ecd37417._comment |    8 +
 ..._eb81f824aadc97f098379c5f7e4fba4c._comment |   33 +
 ..._f688309532d2993630e9e72e87fb9c46._comment |   20 +
 ..._3e203e010a4df5bf03899f867718adc5._comment |   25 +
 ..._f8fd08b6ab47378ad88c87348057220d._comment |   10 +
 ..._8249772c142117f88e37975d058aa936._comment |   29 +
 ..._28418635a6ed7231b89e02211cd3c236._comment |    8 +
 doc/tips/using_nested_git_repositories.mdwn   |    7 +
 ..._cd7f673de1c39d2f37d9958357d5e72d._comment |   11 +
 ..._63f30b652c0cbdb0acf6745891f9f09e._comment |   19 +
 ..._029571d8331ba2dcf0b149d071fef75c._comment |   13 +
 ..._3c701a4c6789fc6c73f71217e7ed8c65._comment |   14 +
 doc/tips/using_signed_git_commits.mdwn        |   79 +
 ..._82241dc5666e1b573a24b3e84f3991ae._comment |   10 +
 ..._5fb568fcd3aa376d2ee36c660a4a02a2._comment |    9 +
 ..._3edce6f128e96e1156601c6136118427._comment |    8 +
 ..._5ad0596373cc363ec9bc0b69efbac03c._comment |   21 +
 .../using_the_web_as_a_special_remote.mdwn    |  150 +
 ..._9889828caa47aad88267d0ec35f2240d._comment |    7 +
 ..._1704dcd7fc94432af5aa18459495c9ab._comment |    7 +
 ..._2ce018f181e039b5dd52e2b712f63eea._comment |    7 +
 ..._39122e2587f84633fda262bfc9d076eb._comment |   11 +
 ..._3a923511cf20d816b468044c03eb171f._comment |   13 +
 ..._8981dfd222cbf349bac3d74f53675fde._comment |    8 +
 ..._321a41d611c6fe45e047af9c96c5176c._comment |   26 +
 ..._dfe9c8c49aadff80d2020288584e0390._comment |   10 +
 ..._ed8dd3bbd9b9ae7f2309b72b94f61eb1._comment |   18 +
 ..._c1133a524989a940f1b5db588707157a._comment |   10 +
 ..._5ee9717e74ca2afed98e81fc0ea98a95._comment |   18 +
 ..._dceb15bd656e69eefa3ca975d9d642de._comment |    8 +
 ..._0bde977c62a53c90cb20491936bc399d._comment |    8 +
 ..._3f32d536f51d5e9908953caf5736b0a0._comment |   16 +
 ..._b420b1f320d620a9909cce5086c549bf._comment |    8 +
 .../visualizing_repositories_with_gource.mdwn |   22 +
 ..._01c5cd21375990c612b8f291904ddb3e._comment |   10 +
 .../screenshot.jpg                            |  Bin 0 -> 78509 bytes
 ..._to_do_when_a_repository_is_corrupted.mdwn |   27 +
 ..._c3543190eae2af594f3e050057e80db6._comment |    8 +
 ..._025178c2b11affe2d42a87544b897dc8._comment |    8 +
 ..._9a6bae9c0326ecc7610f5415db20f49e._comment |    8 +
 ..._d4178d99179e8761162c74673042e28a._comment |    9 +
 ..._9b3738aa678015a58f30a22baa2012df._comment |    9 +
 ..._0e3224af10362a10aa1c8786423960a9._comment |    7 +
 ...what_to_do_when_you_lose_a_repository.mdwn |   19 +
 ..._cf19b8dc304dc37c26717174c4a98aa4._comment |   11 +
 ..._fa9ca81668f5faebf2f61b10f82c97d2._comment |    8 +
 ..._fdcfca8707e310ca7bb94d359adf8607._comment |    8 +
 ..._679eb9be0bfb9d48a2b96383c4816f62._comment |   10 +
 ..._4fb04b70d88ec93ff9ed4f884747d5d4._comment |   12 +
 ..._05db504cbff2ec2a6346bf43e57a3c25._comment |    8 +
 ..._4e6baa41bfee6edf2b17d4ade2909c7b._comment |   16 +
 ..._596bcfa25a4fa6e81bb6a0940c55a2f2._comment |    7 +
 ..._525e58e5941220b23b0ed73fa7611db1._comment |   14 +
 ...nother_simple_disk_usage_like_utility.mdwn |    9 +
 ..._41b212bde8bc88d2a5dea93bd0dc75f1._comment |    9 +
 ..._73698913837bfd5a58cf15721211e43e._comment |    8 +
 doc/todo.mdwn                                 |    8 +
 doc/todo/--batch_for_add.mdwn                 |    8 +
 ..._b1362c86e162a49717d7e3b0816025ba._comment |   12 +
 doc/todo/--batch_for_find.mdwn                |    6 +
 ..._d164ad661617d29cb1ceb3d6fc3bb37f._comment |   12 +
 ..._9873396186f4d24088fd746f42373678._comment |   27 +
 ..._598a0500a3a4573c50a559d1931f1918._comment |    8 +
 ..._830cf616968e25cee8e7d35f9709f79b._comment |    7 +
 doc/todo/--batch_for_info.mdwn                |    6 +
 ...more_debug_information_from_git-annex.mdwn |    7 +
 ..._58e729e2fa58b28d247eeda579bb9329._comment |   20 +
 ..._66a32cef4ff6bc93ad04346612f543ec._comment |   22 +
 ..._ea60112be683188e43b27942667ddd77._comment |   39 +
 ..._03cd162638a9b4f2b7981cee141693f6._comment |   23 +
 ..._f27efaef3d9cb8db3de9dd42df252059._comment |   14 +
 ..._d9014e7e964f47a4fdc680ffc53e17b8._comment |   13 +
 ..._5ae9913b8b9a9fe443c211976adce002._comment |   29 +
 doc/todo/--get_option_for_diffdriver.mdwn     |    5 +
 ..._6b2501b2dc0318242e444e8d4b8b314f._comment |   17 +
 ..._cb4eb05f447a214353a5bd5c29d207d0._comment |    8 +
 doc/todo/--json_for_registerurl.mdwn          |   14 +
 ..._68fd330b6f20ef2d56234a639a5323c4._comment |   22 +
 ...annex__and_ideally_any_other_command_.mdwn |  118 +
 ..._9cc7829b4742f21077a27caad7ae638e._comment |   17 +
 ...me__62____61__VALUE_string_comparison.mdwn |   95 +
 ..._e2da4d1fceb5f7c37e3c19d42256c8d5._comment |   10 +
 ..._38c46dee95ef2f246cd403717faaaa09._comment |   37 +
 ..._9c298fbda8d395fe9b8395105708c3bd._comment |   10 +
 ..._b8f2602e633dae4c85f89c97c8f03d81._comment |   24 +
 ..._afba02fb24eddc6569dce63ffe606dcf._comment |   16 +
 ...nfig_for___39__ephemeral_clones__39__.mdwn |    8 +
 ..._7815551c0ec6d933ae5537e28fb183ad._comment |   78 +
 ..._2debe0cb11763f0673255cfd7f764815._comment |   14 +
 ..._b559ac06e7fc622b8bbb5e73d4cc0930._comment |   11 +
 ..._8cb8cdef0cc563714d7bc7d91743762b._comment |    7 +
 ...or___39__recently_touched_files__39__.mdwn |   46 +
 ..._bcb54e40904b04006dd7f8962add6994._comment |   15 +
 .../Adding_unmatched_files_to_a_view.mdwn     |   15 +
 ..._dee34c34b2df1d430a4f6c2792d35e28._comment |   52 +
 ..._271f37d6c3e0f61324f9f50cb9cf24c7._comment |    8 +
 ..._2e2a15ffc429db4b09215e7a7118e502._comment |    8 +
 ...Adressing_.gitattributes_inefficiency.mdwn |   22 +
 ..._335b8d3c5a903c1e83a7f84b7bfc2998._comment |   28 +
 ..._where_key_could_now_be_obtained_from.mdwn |   14 +
 ..._9f4245bd016f9283464a25698563786c._comment |   18 +
 ..._34d1eab194b7913dd453131d9187287a._comment |   24 +
 ..._f667aa26dadadede318d31176292102d._comment |   31 +
 ..._16d30e86132d6a3cefaa8e2fecbda7ca._comment |   21 +
 ...ization_WITHIN___40__web__41___remote.mdwn |   34 +
 ..._ff4c23b4ccaf649a9914f4aa4435968d._comment |   22 +
 ..._a7087acb84b3139418c597496e18f4a1._comment |    9 +
 ..._69e39ee8140ef0cafd1b0f21be6a8d37._comment |    9 +
 ..._afb7fb3750e3b16bf144c52ffc68c153._comment |    9 +
 ..._f2172080e8e3e324a739d8769dca2ed0._comment |    8 +
 ..._1ab2634c8a7058c5aa09f1ba72be3471._comment |   10 +
 ..._6970e60b7d826beb025fda452cc1bc13._comment |   50 +
 ..._8fe7f4c03784f519fd184e6d59fb0b2a._comment |   49 +
 ..._4d8e8abe8b31174ccc536387a96b0228._comment |   10 +
 ..._b6261ff8e442ee6df79834844f6b3565._comment |    8 +
 ..._50516fc4b3c315a9e5d771777fb27e9f._comment |   11 +
 ..._87ad54a694bde70713e71acd4e074894._comment |   10 +
 ..._4029b264ea2b0d47e6949f832af69282._comment |   16 +
 ...low_globally_limiting_filename_length.mdwn |   11 +
 ..._and_ignore__42___in_git_annex_config.mdwn |   12 +
 ..._7a55c03691a6b6738d1a0e2555cb4cea._comment |   15 +
 ...4___shortcut___34__Add_to_Annex__34__.mdwn |    1 +
 ..._286279b96fc7940c9e7eeb0eb57cc279._comment |   13 +
 ...Scanning_for_unlocked_files_...__34__.mdwn |    9 +
 ..._41cf16d6d14d1551c43736f854da3d05._comment |   10 +
 ..._2ad0467b36d7e7be3b346dd54ba4f46b._comment |   12 +
 ..._70c4c9f6c35acd7ca1134ac74356e5be._comment |   16 +
 ..._440624874dd3697dd538655765f2b6a2._comment |   18 +
 ..._cf70ca1f6dac58c44ee3ece2199d25a9._comment |    9 +
 ..._06641815750038a0ed908d929868c1c3._comment |    7 +
 ..._adf57675c5fa1047ee48b16dd356f4fe._comment |   11 +
 ..._c41b669837be95b731bd68f1b3269fef._comment |   11 +
 ..._4e1e8fd89ea9be43d89e72562236c979._comment |   14 +
 ..._b34a9cf4114ed943fe4ba2de78eb0bbc._comment |   19 +
 ..._94395a48d99e4737dd0ee28a597bfe70._comment |   29 +
 ..._e9a36e9600561201969c4d21499833af._comment |   28 +
 ..._8f5dd9ba761e636ce5413da4e596296d._comment |    8 +
 ..._bd7c278922a52004540db79099e35763._comment |    8 +
 ..._c3f029b865bcd489d03bcf722dfa4e44._comment |   26 +
 ..._2cb31617bb7003c5bf0e5def358da0e4._comment |   20 +
 ..._2aab5c685ad934486e60065b3c8da1bf._comment |   46 +
 ..._a5089531b5d9bdcc90a07cb9d3f1da7d._comment |   12 +
 ..._e2718b6492d5da64a8bd6b13ad1cfa45._comment |   10 +
 ..._71d3936dc37349392e6f7b0bd8292b7b._comment |   16 +
 ..._7ada8d7e9438f2740b700e2e54b045da._comment |    8 +
 doc/todo/Bidirectional_metadata.mdwn          |   23 +
 ..._9974d17e407fab14b12399016d3d66c2._comment |    8 +
 ..._c791aca6da2bb1be70991bc1a76982a4._comment |   20 +
 doc/todo/Bittorrent-like_features.mdwn        |   66 +
 ..._f4c110ef35ebf4fd89f06edf2c4f0c48._comment |   13 +
 ..._83148bd5c5c5e6c2eff3ad6e1d4fb82c._comment |    8 +
 ..._84f149b30de1562593623aa23dc0396c._comment |   10 +
 ..._7c54c83e582c0d4848aaf3d70e312707._comment |   10 +
 ..._194dd0e8404ea72af9fb6ff34b994998._comment |   20 +
 ..._489505da4143fb1c2bf21e7af695cdef._comment |    9 +
 doc/todo/CHECKPRESENT-MULTI.mdwn              |    5 +
 ..._181a908a9f77a4c51d1d09f1aff526b7._comment |    8 +
 ..._87857aeaf45927846cde8cea70f9e6f4._comment |   27 +
 ..._5228016c35ca0b13545b82bbd3b9455e._comment |   20 +
 ...rive__39___repo_even_if_set_as_client.mdwn |   22 +
 ..._e33dddf4d1f104107c86800a0a9a89b2._comment |    7 +
 ..._25eb2d7d0a9cdd1c55df0cec68472723._comment |   10 +
 ..._9e9b96e5113a50533251e946c2560d81._comment |   17 +
 ..._6b091198ddd6ed709b076df1296aeb77._comment |   11 +
 ..._118b588685b535cca4c02eb6ef297c67._comment |   21 +
 ..._5cead277493e1c020e16be6f9245fe33._comment |   12 +
 ..._0f135f97c2808dce094628dc6608e617._comment |    8 +
 ..._1d6f47f9e6cf935f19d68af6d5aa92fa._comment |   10 +
 ..._c5758fdb32348b9cd804ff17d27864e1._comment |   16 +
 ..._3f0bfc5a79aa59ac76a6968aacda6655._comment |   10 +
 .../Configuring_metadata_view_filenames.mdwn  |    1 +
 ..._08f8f27e5a8dbd80a91ffd9fd6f64e6c._comment |   23 +
 ..._34efe1424a9b02dca706565517900bd6._comment |    9 +
 ..._dd7aa7560412d4589d2fc28eb978a71e._comment |   10 +
 ..._1873c7cdd142dffc210ec0172bf29997._comment |   14 +
 ..._b222634d9f97e2ef604b476df357d54b._comment |   26 +
 ..._1eb8c2d70ff9e3e5b3dbebf88270eb93._comment |    9 +
 ..._ae259f68ab5b366b6fd29e5df1a05469._comment |   10 +
 ..._2bcfc677da72637f34904b84fdd95c10._comment |    9 +
 ...flink__47__clonefile_support_on_macOS.mdwn |   11 +
 ..._81bf4ac2fe810cc4e7a21c8bb4d0f15a._comment |    8 +
 ...7__reflink_support_for_unlocked_files.mdwn |    3 +
 ..._52db92711e28abb0eb7a346646b91573._comment |   13 +
 ...be_a_file_in_function_of_another_file.mdwn |   17 +
 ..._b0132288c67054485e9681f3f5138768._comment |    8 +
 ..._4efe2044282c8ccd6d570e84bb2ab68a._comment |    8 +
 ..._a9e02d7a27fd4448c1afd19e3f171a5c._comment |   12 +
 ...__34__create_encrypted_new_repo__34__.mdwn |   14 +
 ...s_already_in_.git__47__annex__47__tmp.mdwn |    1 +
 ..._0650918c86fca0554755aede19a12fd3._comment |   53 +
 ..._aa6bf987de3dfc9f78eba30b4b2c8c16._comment |   11 +
 ..._3419d2603af199fd311f6898adef5ed3._comment |   28 +
 ..._conflict_resolution_to_git_conflicts.mdwn |   13 +
 ..._c08e7f51503f103c447064a01b085783._comment |   19 +
 ...71__git_annex_watch__187___is_running.mdwn |    5 +
 ..._e5f2630591ffa7758ca4250a061a8589._comment |   12 +
 ..._f8a5cc905d5b06bdbb1a778ab866a28c._comment |   44 +
 ..._626c629654508d0d948ece849d43ed86._comment |    8 +
 doc/todo/File_deletion_workflow.mdwn          |   24 +
 ..._7b80d9a202ede51730cbd443731e1fa7._comment |   39 +
 ..._60b54e6bbb37464697b4f5c4ebe561da._comment |   23 +
 doc/todo/Filter_a_tree_with_pattern.mdwn      |   55 +
 ..._17dac31227b8f95c5ca50f4a4cf5a425._comment |   14 +
 ..._e2b0b3eafdfdab1e315066ac57c8b838._comment |    9 +
 ..._ca3058fe82eff771f3664ab2f8aa78ae._comment |    9 +
 doc/todo/Fsck_remote_files_in-flight.mdwn     |    7 +
 ..._1a70ae7c9821d664ddf72fd4c431be29._comment |   28 +
 ..._3baff888fbc3068571cdc9fee73fbe36._comment |   29 +
 ...eys_with_same_hash_but_differrent_ext.mdwn |   13 +
 ..._5af33851bdac4f34d83e8ef2e1d45355._comment |    8 +
 ..._ad76bcde941d6f1719260179a7bd27ba._comment |   33 +
 ..._51945c553d70ae76297ed4aaf3c8b624._comment |   30 +
 ..._2f496cb303c90eaefef955082e2bfb00._comment |   18 +
 ..._272be474bd9ee8d087821bd8a6e88175._comment |   32 +
 ..._be9a58f2028fb3c155ff2020dee2b46b._comment |    8 +
 ..._fed82ecac17e6ed86eb18232d4b5ae6a._comment |   15 +
 ..._82c04709fe3b69d6a75e44d71b500681._comment |   12 +
 ...__git_annex_sync__39___optionally_add.mdwn |   38 +
 ..._6d9ef10f9534c7b95ca58913cfe3b5fd._comment |   31 +
 ..._25be855ca688e37644fa86357b96b3d2._comment |   14 +
 ..._8327e0a3f3d4bf35c52b1f2f4089dcbc._comment |   15 +
 ..._8b150a2a4b9b0de8039ee8995c01bf8c._comment |    9 +
 ..._0156a70246f19beeee6ce5cfb510de86._comment |    8 +
 ..._b0f6d52ef7a94badd572c6cfa759efb3._comment |   18 +
 ..._6c4c1541a146c66c11ebe6abaf7f1810._comment |   24 +
 ..._2160800299fff5dc920847bec1ab0220._comment |    8 +
 ..._eeb1bb0b1a02a74291daa41e9a8eb725._comment |   17 +
 ..._a49dcb3963a986c530571f69fa9326b4._comment |   18 +
 ..._cf4ed68e05fd7d553a314746b444b7c0._comment |   37 +
 ..._3a2fe8d0c0dd6f5066370086c0f03300._comment |   32 +
 ..._2e0ad0cdb9d813d0fbc514c1642669ca._comment |   21 +
 ..._bb6b5503ec5f699749fa8e3ffce59aab._comment |   23 +
 ..._e6e6b344d533de57ce7661b5f1ada027._comment |   12 +
 ..._e128886c09b9ca2127ff540c2af0beda._comment |    8 +
 ...FO_message_for_custom_special_remotes.mdwn |    6 +
 ..._ea99a5099f78767859c05aeb5217a12d._comment |   11 +
 ..._69535d7d9b7266eaac6f9bb70d2660dc._comment |   10 +
 ...for_emulating_a_versioned_tree_export.mdwn |   72 +
 ..._d944fd707130be6ebe35302794a0b73f._comment |   24 +
 ..._e0f6d78620a89f60010607b37328f754._comment |   14 +
 ..._19e77a51911d3c2d39a558162223e78e._comment |    8 +
 doc/todo/Improving_diffdriver_--text.mdwn     |   32 +
 ..._a38b0f30f9b4011d703e70c093f139ab._comment |   26 +
 ..._2a59862281c1be5ee92912912c2045e9._comment |    8 +
 ...mental_git_annex_sync_--content_--all.mdwn |   21 +
 ..._9d812c6dd2fd7b4c255ea88580da4396._comment |   10 +
 ..._9fff9eb8a7a897c5aabe9878f4d0b23b._comment |   10 +
 ..._638f40462d4bb2a447350ce0a5dc7a92._comment |   35 +
 ..._c232e1e1cfcc47f70079f2d32c2b4633._comment |   11 +
 ..._e81719f23565579674249db5d0a883da._comment |   27 +
 doc/todo/Invert_remote_selection.mdwn         |   32 +
 ..._5aa12a96f54a40adbfe18267a6bde87b._comment |    9 +
 ..._9ad4c9b2217f739e67198d16d14d32e7._comment |   12 +
 ..._2aec5f535c84c37d59802e4759a1c242._comment |    7 +
 ..._f5ab9eec7ed0f080c57dbb594deafd13._comment |    8 +
 ..._a_repo__39__s_description_up_to_date.mdwn |   14 +
 ..._2fcce6a8fcfec28a6edeab40291deaba._comment |   22 +
 ..._1c73d94cc84bbfdeb65a71995265491f._comment |   17 +
 ..._394c87782dd3318a6fa3705322fea4fb._comment |   16 +
 .../LIst_of_Available_Remotes_in_Webapp.mdwn  |    1 +
 ..._23fe2f3cd44c4357a385452dcd5eedef._comment |   10 +
 doc/todo/Long_Running_Filter_Process.mdwn     |   24 +
 ..._f155ffc7dbd074964dd53165274ec8a0._comment |    8 +
 ..._24d89d0e8eb2da6e43d107caa71e042b._comment |   16 +
 ..._96c20518a6bd2806fed3646331b3ca1c._comment |   21 +
 ...ase_extension_for_SHA256E_and_similar.mdwn |   19 +
 ..._71a32962c081e42be0bfc468f74230e8._comment |   13 +
 ..._db432973421d3974e027cef13caa3033._comment |    9 +
 ..._15ec3c411b0a92b073eb8c65e192c8b8._comment |    9 +
 ..._2ef3cc0ff00cc735e3400120ae49d14a._comment |   41 +
 ...unlocked_configurable_like_largefiles.mdwn |   45 +
 ..._823bddc3b3824419f1123748f163e0ff._comment |   19 +
 ..._89ea6c764e18ed4335733f979fb31140._comment |   22 +
 ..._8f32ef554635d852383eeaf3f0629d45._comment |   10 +
 ..._17d12c5d9f5aa40aa8c20ae478b324b2._comment |    7 +
 ...ex_sync_--content_trust_location_logs.mdwn |    4 +
 ..._006e3e3ab0c08852239c0f8fec851201._comment |   18 +
 doc/todo/Make_webapp_port_configurable.mdwn   |   42 +
 doc/todo/Mbps.mdwn                            |   17 +
 ...a_changes_are_not_reflected_in_a_view.mdwn |   33 +
 ..._5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment |   18 +
 ..._74597dc57b426adccfa5aab456e499d2._comment |   10 +
 ..._39d7b5588595067332909c53b232c413._comment |   27 +
 ..._6ab0e38d8be8a70d501108f207d41d82._comment |   29 +
 ..._b1b381c560fd81f372fc393ec5d63d8d._comment |    8 +
 ..._9d3d9877e8581f986257dd3d495a8eab._comment |   12 +
 ..._f97d171fdd715d984e43c1a8139bb8ae._comment |    8 +
 ..._e10e8e6daf155fc493454f1d0d8595a8._comment |    9 +
 ...ts___40__blob__44___trees__41____63__.mdwn |    1 +
 ..._30c513b68101442dbcdec0eb109203fe._comment |   35 +
 doc/todo/More_precise_jobs_count_config.mdwn  |    7 +
 ..._8b7dbf6025c99172925f037e9096ead1._comment |   20 +
 .../More_space_savings_for_annex.thin.mdwn    |   11 +
 ..._cd571b1b3b6e73041ee629d031481d09._comment |    8 +
 ..._95d195f2bad7e6a912e5d201928a94b9._comment |    9 +
 ..._15cc8f9e428df04199d139e2677afd8a._comment |   14 +
 ..._a87baf5ad6b7688bb40a6c463cb1b8db._comment |   47 +
 ...___47__ssh__47__git-annex__47__config.mdwn |    9 +
 ..._284c806e83a32af81b02aea7c7bc285a._comment |   10 +
 ..._1f55ad6b39906458779b2d604b003ffe._comment |   10 +
 ..._b00dce2374aac6968317d05d23bcfaf7._comment |    8 +
 ..._743d0b077110c5cac1e2f47187b75333._comment |   10 +
 ..._for_addurl__44___get__44___etc__41__.mdwn |   29 +
 ..._ed3a47b10ce2303041d9b9271bb9a2c8._comment |    8 +
 ..._2afa6133bfa8932ea1fb02b2052e2939._comment |    8 +
 ..._6c9336be070b04d5736b943889370c13._comment |   23 +
 ..._20184de38c2adeed7e20fa323d9a3ba4._comment |    8 +
 ..._58965ac55e2e9aebdd0e38f8eef097a3._comment |   12 +
 ..._312f32bd35f06837463e541773986b4f._comment |    9 +
 ..._7ea1c35ce23a57fea52a593c41a8fb69._comment |   26 +
 ..._337217fc0ae8cfd432c7df45942b86ef._comment |   10 +
 ..._8778b93dbc123c484727bb55e39608c9._comment |    8 +
 ..._9c7bdcb483b371f421bcdca3d8c2073c._comment |   18 +
 ..._c94fdab4db1d5f94929ae068c546b533._comment |   10 +
 ..._e3c50b7ab1c5cd49a3e5376e20b7d4c0._comment |    8 +
 ..._72eb9bc8d12bc8719f49f6528a086234._comment |   17 +
 ..._6d1a630fbf036144c9559c9c01fca845._comment |    8 +
 ..._checksum__41___in_a_single_operation.mdwn |   16 +
 ..._695d1269ab20c66630ddfa2d8cbabbef._comment |   10 +
 ..._f85f81450c5d59e6722b46299f2ae29c._comment |   17 +
 ..._a19823409648828b8b9f7a0f2fa7d935._comment |   10 +
 ..._14f46277adb38d5cb802cd23eb2cde04._comment |   19 +
 ..._85e2368381e15cd86b5340fcec1a083b._comment |   30 +
 ..._fbbcf1d8b35078274cfe322cea6de21c._comment |   14 +
 ..._39db598e93d0d858984052e3894cd96e._comment |   11 +
 ..._29e601ea3ea4f22301c6cf6eed403ba4._comment |   11 +
 ..._fa9e2c0a83bad2e0c2da3016b9bf2100._comment |   12 +
 ..._529c38fc63540b32c51ae75529e9005e._comment |    8 +
 ..._82707d36ed580d62c73e441f959ccd9e._comment |   41 +
 ..._aad1896b58e58cbc870c4526ebb824ec._comment |    8 +
 ..._3d2f62f0946528c9986135f8db86a237._comment |    9 +
 ..._48842fb1e006a05573ab34048db45c8b._comment |   47 +
 ..._593b8710c25bec1182409b36d6c44b4a._comment |   11 +
 ..._4f4f4a42adafe52207ed32a5d20e94be._comment |   25 +
 ..._b92774b0feec3049bf6aef89614543df._comment |   12 +
 ...58___drop_url_parameters_from_extension.hs |   56 +
 doc/todo/Package_for_Lacie_NasOS__63__.mdwn   |    3 +
 ..._1b1b23b95b1fa29a8d71848a5cec9008._comment |   12 +
 ..._81b181781da615c56aa30eab131cec53._comment |   14 +
 ..._fd7eeee6a86101867f0ab17f883f0c6a._comment |    8 +
 ..._all_annexes_watched_by_the_assistant.mdwn |   11 +
 ...ultaneous_pushing_to_idential_remotes.mdwn |   22 +
 ...rks___40__not_just_specific_IPs__41__.mdwn |    5 +
 ..._26d81cbc8732b65c2f0a86a33ef0f8fd._comment |   25 +
 ..._64ffa9a560bf11ba22c715da0b4b1cfe._comment |   10 +
 ..._da5363a268008a88014972987de10323._comment |    7 +
 ..._620fd718bd2c97a6fa4ce775e311a2d6._comment |   17 +
 doc/todo/RawFilePath_conversion.mdwn          |   75 +
 ...uest__58___Date_limit_with_importfeed.mdwn |    3 +
 ..._5d3d762eaf755410f5ee70a22fc95ab6._comment |   10 +
 ...export_redirecting_to_key-value_store.mdwn |    5 +
 .../S3_multipart_interruption_cleanup.mdwn    |   14 +
 ...tal_storage_limit_for_special_remotes.mdwn |    3 +
 ..._8945025ad54e28f48474f8931746a775._comment |    9 +
 ..._86aa368db46dfedb065a18edfa7c9ad4._comment |   11 +
 ...default_preferred_content_expressions.mdwn |   26 +
 ..._45d57933a45ddc1e31ba46519b944239._comment |    7 +
 ..._575320e07f005d46d26cc6db9ad3ebd3._comment |   12 +
 ..._971b3efe8a6ebdeede0184f13774e86b._comment |    8 +
 ...nex_diffdriver_fetch_non-present_file.mdwn |    9 +
 doc/todo/Show_repo_type_in_repo_list.mdwn     |    1 +
 ..._ac6eb1072ef902a094b79dd8e0917c4d._comment |   10 +
 ..._6979c487f707a724a048d20e2e5744e6._comment |   14 +
 ..._529254a6cc20de7259d60a3cbc5ccaf7._comment |    8 +
 ...ription_in___96__git_annex_info__96__.mdwn |    5 +
 ...remotes__58___support_for_MULTIREMOVE.mdwn |    3 +
 ..._cc95104ae0803db35fee504152db046a._comment |   38 +
 ..._f58cc7b04948a8c758f97778631b0f02._comment |   41 +
 ..._4f18712f974f85c3cef810714d304d85._comment |   16 +
 ..._2dbf3558c7c969281f1cc5e1738d2c0b._comment |   21 +
 ..._4a9f2e1e3f30b472d4c5aa9c07684cc0._comment |   96 +
 ..._f756a8ea12af1a01406f1bf05d9dba11._comment |   58 +
 ..._993ed66935c0d95488751a0e0e2c57b8._comment |   23 +
 ...ecify_maximum_usable_space_per_remote.mdwn |    9 +
 ..._fdc0c518b6cbc5dc7e5b64748c2d7b01._comment |   17 +
 ..._b81af6dac4042c0d4dab58c91a46b09d._comment |   15 +
 ..._afc7f278c02d7bf9f92a90e51cb5a2a9._comment |   19 +
 ..._a760351ed7a6d3d232af7c22b2063871._comment |    7 +
 ..._c5069ffed5e8c4e1d001aedb971aca75._comment |   13 +
 ..._bef44c8f571f2be177d6ee949c721a6a._comment |   13 +
 ...__39__import_--clean-duplicates__39__.mdwn |    7 +
 ..._9268c639d3d21cce4ca7b60d08e9cb65._comment |   10 +
 ..._9c6688901ef20badd834419202627d5c._comment |   21 +
 ..._b53f2e881af1426adb0f45e2b11e4be6._comment |   19 +
 doc/todo/Split_autocommit_option.mdwn         |   20 +
 ..._fc127bc73c650404df4f21c9a04b3dd4._comment |   14 +
 ...ore_git_pack_files_on_special_remotes.mdwn |    5 +
 ...ffing_with___39__git_annex_diff__39__.mdwn |   29 +
 ..._2f5ea091b7f6defa397d15055d04a67d._comment |   28 +
 ..._cae9e0be287bd42498caf1f61c518f0e._comment |    8 +
 .../Usability_improvements_for_new_users.mdwn |   21 +
 ..._70ecef547308f9b049bd67f3d2f14117._comment |   37 +
 ..._ea77f0894802a17854aeedeceababf8a._comment |   29 +
 ...Use_MediaScannerConnection_on_Android.mdwn |    7 +
 ...g_site_for_files_with_obfuscated_URLs.mdwn |    7 +
 ..._1a1f34f4f389267d67e79409c0ca8b1d._comment |    9 +
 ..._735afa6f87a93cdf333c17da32010620._comment |    8 +
 ...Use_editorconfig_for_formatting_rules.mdwn |    3 +
 ..._20e6d6467dcc9e4814c657355a7f2e74._comment |   11 +
 doc/todo/View_for_old_versions_of_a_file.mdwn |   24 +
 ..._8e233fd006bd8f16533df63579f02fb1._comment |   12 +
 ..._9b1c6f41f77ec6ba9c90a5e9ec088647._comment |    8 +
 ...tant_on_boot_delay_the_execution_2min.mdwn |   36 +
 ..._49990eaf4a3d6ee89f668dfc159f5eae._comment |   17 +
 ...hlist__58___Parity_files_on_all_files.mdwn |   67 +
 ..._3900fa7c3ed1455fe07d097c3dc0c9f2._comment |   21 +
 ..._60dc7823a1814af18861b459a9b3cd0e._comment |   16 +
 ..._d69eba0afc48c49bdcd7f1f6a7716bbb._comment |   10 +
 ..._01c382342237e4713ab32a3e95497926._comment |   15 +
 ...ional_environment_variables_for_hooks.mdwn |   19 +
 ..._d82cbbb478a81a651fbe6cb8b71c1192._comment |    8 +
 ...disable_auto-repair_for_the_assistant.mdwn |    3 +
 ..._3274820a0d1f10c505f15cd29a37b95a._comment |   12 +
 ..._2cf5aef3f1d340c4ed6249ef94c1b607._comment |    8 +
 ..._6c53d82e62b2d269a941ba967d05adf5._comment |    8 +
 ..._fix_wrong_UUID__47__duplicate_remote.mdwn |    9 +
 ..._a9e54e4bc540cbab7cdbbfdeaa973f4a._comment |   16 +
 doc/todo/Workflow_guide.mdwn                  |   15 +
 ..._f4242a3bdeffb90336f562f9ec182e5d._comment |    9 +
 ..._ee6da4cc639bca0b17156d51ebfc05c2._comment |   29 +
 ..._8cf0f9913dc307cd18001656ba390159._comment |   12 +
 ..._b6f5ce361529356a77b0e6141a62c06d._comment |    8 +
 ..._6ec6fb45021ba82ed6a4bb9a6f3cfceb._comment |   19 +
 ..._640e5c6cdea8a6fae63c3fab6970f1f2._comment |   10 +
 ..._805e877b23adcf562feeb7d927fca08d._comment |   15 +
 ...ion_either_content_is_locally_present.mdwn |    7 +
 ...nsistency_check_while_on_battery-only.mdwn |   14 +
 ..._b557db02c3719152d392fa454c9c5ce5._comment |   15 +
 ..._374567f37635613a5d671c877d601367._comment |    7 +
 ...copies__39___meta_parameter_to_NUMBER.mdwn |   31 +
 ...ix_annex.adviceNoSshCaching_no_effect.mdwn |   30 +
 ...freeze__47__thaw_hooks_on_crippled_fs.mdwn |   76 +
 ..._b943081483e4f1f9897b214004d48493._comment |    7 +
 ...o_figure_out_the_origin_of_largefiles.mdwn |   10 +
 ..._9b0826c1d5b063a3e63d4d2cc030a55b._comment |    8 +
 ..._6bfe8e1b6b2c3334803d8a6676862e8a._comment |   20 +
 ..._def75a3ad8907cb62eb5d96c85aabd5e._comment |   12 +
 doc/todo/absolute_symlinks.mdwn               |    7 +
 ...0__or_alike__41___to_find_and_findref.mdwn |   10 +
 ..._8407146882e97ee8510f28df2ba5129c._comment |   26 +
 doc/todo/add_--dry-run.mdwn                   |   25 +
 ..._4daf51eec7db67a89bec8f81b742a094._comment |   31 +
 ..._312127fc2780fd894332d7d8b7f7a209._comment |   25 +
 .../add_--jobs_for_dropunused_command.mdwn    |    3 +
 ..._bcd06faab6b5f6394333e74a17249d08._comment |    8 +
 ...son-progress_support_in_push_and_pull.mdwn |    1 +
 ..._403acf073a2a8d53eaa880cc2564347d._comment |   29 +
 ..._ff0b1ca16b03d2e6c8331645adad84a6._comment |   22 +
 ..._a11ee71f4ee907b011aebcfe270b7ee3._comment |   24 +
 ..._0f3c22853b50550237f9659ed2120ab2._comment |   24 +
 ...progress_to___96__git_annex_add__96__.mdwn |    8 +
 ..._9acc343305dd5a2aaf569a6396d09896._comment |   11 +
 .../add_--json-progress_to_fsck_--json.mdwn   |   17 +
 ..._170acd9fc5b5a40ae22de0bf418b424c._comment |   11 +
 ..._2ce9c3c35ea5c4033bfa42e2f3365a64._comment |   19 +
 ..._5c0c3bdf1e5cf68f2dcebdd85a8253ac._comment |   20 +
 doc/todo/add_ancient_armel_build.mdwn         |    3 +
 ..._704f1a854e5ef62edbca60ab209d2123._comment |   14 +
 ..._0b02f96699e9ec9447e336b74b255801._comment |    9 +
 ..._eaeb9aec42fde6b8a25199b1e1e6a78c._comment |    8 +
 ..._da51390e7b67cd1dc075c793e99d4367._comment |   12 +
 doc/todo/add_import_--to_command.mdwn         |    8 +
 ..._b70d10190722c0d21c2343fe51e38414._comment |    9 +
 ..._c7a95793a46ed948301b01a1f29bfac1._comment |    9 +
 ..._f393450ae2daa14e1e7008db2b3c7dc8._comment |   14 +
 ..._4a30627ac78b32911604c3377b958cd0._comment |   40 +
 ..._549edb19b222bf4bd1b87aceba007005._comment |   14 +
 ...e_to_external_special_remote_protocol.mdwn |   28 +
 doc/todo/add_limit_to_matching_options.mdwn   |   16 +
 ..._2358e0503ca6c65644ca68c0ebd89723._comment |   10 +
 ..._187a47171265eeaf2aa144beed53bfc3._comment |   16 +
 ..._cfff69317903879bba2a9a9de1e73a8e._comment |   28 +
 ...axextensionlength_to_git-annex-config.mdwn |    1 +
 ..._df1113eb2b0b9cf6c13b1e8ea0995f1d._comment |   14 +
 ..._580ed143221abbcced40f020b849cc27._comment |   14 +
 ..._6bcf92e8cc78b47ed42f58a610e27d76._comment |   21 +
 ..._f0894e2797e1188bdf4bdc09bd10553e._comment |   17 +
 ..._9499ecd6136102803f1d6691c03e6b20._comment |   26 +
 ..._9ff852c12549985f6e88bd2316a69def._comment |    8 +
 ..._2b02c97fc9cfdb30d89676ec82760538._comment |    8 +
 ..._6302aa8c3ff1f1096bc9978dd6407744._comment |    8 +
 ..._5027255cc1b0dec41e315df8472fe60e._comment |   29 +
 ..._disable_fsck_upgradable_key_warnings.mdwn |    3 +
 ..._f91174aef6f7a5a41fb9b9b54249be1c._comment |   19 +
 ..._eb2a5ee55df954b243bf0ea87801fbce._comment |   39 +
 ..._3b9f1387cc5de5d0bce5fee5fff91002._comment |   26 +
 ...whereis_to_avoid_network_interactions.mdwn |   22 +
 doc/todo/add_sftp_special_remote.mdwn         |   25 +
 ..._28c98e879c16f56da2a89ed9d50e4398._comment |   12 +
 ..._1fcefc50041b363a86f596f8d4121611._comment |    8 +
 doc/todo/add_testremote_cleanup.mdwn          |    1 +
 ..._9dc28d46dfcd693def4cbb3837de55e0._comment |   19 +
 ..._a87de50ab7c39d955d5c1f6a1c51f761._comment |   11 +
 ..._976fd7b1db867bf5fe785e0d32acddcb._comment |   16 +
 ..._ef144de6384eb89a2d4caa13e6895872._comment |   11 +
 ..._0a3c3cc6c9b4efd7a6c4cf7333f2b120._comment |   10 +
 doc/todo/add_tests_under_concurrency.mdwn     |    3 +
 ..._9879c63f9de342b6831d5794d8f6212e._comment |   24 +
 ..._3713c706c8a0689f527c4558176a7b48._comment |   12 +
 doc/todo/add_xxHash_backend.mdwn              |    1 +
 ..._8993f493a8b43ffda9f8e0b6d5e186ac._comment |    8 +
 ..._945217badfaeba8672329d4f6ac4b8e2._comment |    8 +
 ..._93892ef71d40f0b10e5fdcb703faf3ad._comment |   18 +
 ...ional_git-annex-config_settings__63__.mdwn |    5 +
 ..._74d61d6a4412223092f468628d3f2f45._comment |   11 +
 ..._2973d438e8f3fda50cfb151534a8ec73._comment |   11 +
 ..._3abeddccdf5c742962b25b7dbe8fb69e._comment |    8 +
 ..._1d777383fda7c50d630e19ec1d1ade52._comment |   14 +
 ..._ba2cbf8dcf14a1d0b20621b48b8e8600._comment |   16 +
 ..._4ec0261f3b8bc6d2492fa3dabb0121e5._comment |   35 +
 ..._c1768ab8568c8e58525ed40e76cc13f2._comment |    8 +
 ..._845a504ea9f038a19a21d8a985585b2b._comment |   11 +
 .../addurl_--raw-except_REMOTEs__63__.mdwn    |    7 +
 ..._d9b88a0f157ce8143d52a35256beaaab._comment |   17 +
 ..._2cd05802f25c9868b1b975dd359b66b4._comment |    8 +
 .../addurl___8211__force-torrent_option.mdwn  |    1 +
 ..._15be1914c8d05cd1ad8220bcfea9d0bf._comment |    8 +
 ..._52c04c388b807993cecacc7f98b73cd3._comment |    8 +
 ...justed_branch_with_hashdirlower_links.mdwn |   18 +
 doc/todo/aeson_2.0.mdwn                       |    7 +
 ...iguring_assistant_to_add_files_locked.mdwn |   12 +
 ..._quota_independent_of_free_disk_space.mdwn |    7 +
 .../allow_for_annonymous_AWS_S3_access.mdwn   |   20 +
 ..._0723643146ba36131218be090e6d5c73._comment |   18 +
 ..._2626e1d0b2aa5a2af19d7fef1d13beaa._comment |   10 +
 ..._6f79f3ecab275d594182fff5e2fd81f9._comment |   50 +
 ..._9cf7360f849964689133af60b8e1175b._comment |    7 +
 ..._b680494cd2fb1cf117b110e08e0ff476._comment |   49 +
 ..._b1e14d6baef8d03aaa6ace717aebc0f9._comment |   14 +
 ..._d44dea0d8c0d46dd8c75ae40f66072e1._comment |   11 +
 ..._b0d9dbe81f01e80809381a9e5f6a883d._comment |   27 +
 ..._7fa3b2aafcad92c20f8a3467aa3ae6b9._comment |   10 +
 doc/todo/alternate_keys_for_same_content.mdwn |   12 +
 ..._22ff867952875856b20339a8829c5944._comment |   22 +
 ..._3323eff3d94d366595bf2b7e78c01dce._comment |    7 +
 ..._7a7f287bcde5353072100294dd8edce6._comment |   14 +
 ..._0f464f4970e499371fcb65e0d06202cf._comment |    8 +
 ..._c99b23e878e37e205a3182d3b6d3f2b2._comment |   15 +
 ..._a5fb6045595da0c490098e46f76db9b8._comment |    8 +
 ..._230d35bd623189818002901455964ca4._comment |   12 +
 ..._ae8355ec917e7a7a240cdb88714c55d0._comment |   19 +
 ..._1c0a975893c63c14b3f6e17712b5191c._comment |   10 +
 ..._4b16c48a2d9f4926d63f6ab54fe801d3._comment |   19 +
 ..._42d240bbfc6ab858219ffa0f873c3eb4._comment |   50 +
 .../annex.addunlocked_in_gitattributes.mdwn   |   13 +
 ..._1d21cde3d21a9b5bb129b17b9e0fc95d._comment |    8 +
 ..._38f248f7596646dfc11248f0149c0beb._comment |    8 +
 ..._270c5156c8adce0aff86eda5f2746703._comment |    9 +
 ..._d87e08ccdec98867dd52b629e6fad330._comment |   12 +
 ..._be25f3b3c2279eb3fd3ef69c4d1cb52d._comment |   12 +
 ..._f672dee4c1712e0d20dd820999598d87._comment |   10 +
 ..._d06e3412f07d98c784b420d82d2d8d49._comment |   34 +
 ..._73a402df13f30b279dfd2914adec5f35._comment |   12 +
 ..._02866c504617c2914eff01d3529d5cc7._comment |   13 +
 ...dd___40__-u__124__--update__41___mode.mdwn |    6 +
 ..._bde2b1e2c45e110d56ce98b43dd77743._comment |    7 +
 doc/todo/annex_merge_--remotes.mdwn           |    8 +
 ..._d4d1c3dae7cff4119b7c111ac6e6f947._comment |   29 +
 ..._be8596676823e916a56d774e0a161945._comment |   68 +
 ..._35614da544e315529b236a36e1b28e2d._comment |   17 +
 ..._8cb7787fbfae63c45a155ee6ef270922._comment |   12 +
 ...n_nonexistant_or_non_git_files_passed.mdwn |   29 +
 ..._32ebb1ea1278b891b58dd3c4a8546453._comment |    8 +
 ..._672457817d5dca898f5aefbe97da9b23._comment |   12 +
 ..._b6a76bfc063dcba439b2ead004caabc9._comment |   14 +
 ..._3f0872f13160a77a82bd5a95fc3f397d._comment |   38 +
 ..._0217c8acd2a9eb3bba1fc497856cd96a._comment |   27 +
 ..._7501eed2e6cb732966277ef2f1ff28e9._comment |   10 +
 ..._7a5b3d2694a48e4e44436f6bf7ed6642._comment |   37 +
 ..._2550e1760dcfb90c9c2ca1ee145adcf1._comment |   19 +
 ..._f34293aa30b8b9abc71fac4e713aded3._comment |   34 +
 ..._d7e879ae1e7ae5e27e15dab9d5b99f16._comment |    8 +
 .../arm64_autobuild_broken_since_2022.mdwn    |   10 +
 ..._0642002d8ad1eb318de5fdb63956a2fc._comment |   10 +
 ..._48e40f76e0480adc965505543a4f25e5._comment |    8 +
 ..._better_repo-wide___40__regexes__41__.mdwn |   62 +
 ..._55652562111e83129eb19a61da14ee4a._comment |   25 +
 ..._0d1e17e92d6022552406fef144e8c104._comment |   20 +
 ...epo_via_an_ssh_alias_or_an_ip_address.mdwn |   50 +
 ..._6b71a390fd16f593216793aec590d9a8._comment |    8 +
 doc/todo/assistant_importtree.mdwn            |    2 +
 .../assistant_parallel_file_transfers.mdwn    |   15 +
 ...assistant_should_detect_added_remotes.mdwn |    7 +
 ..._1cadcd0d5c61a04bd1118d94e3fc7f45._comment |   13 +
 ..._2a282fcacad94b9590f5bc440ff6ea64._comment |   10 +
 ..._35435a0b4d98483fa5c67759ae5baa35._comment |   10 +
 doc/todo/assistant_support_hide-missing.mdwn  |   13 +
 ...web_switch_repo_Internal_Server_Error.mdwn |   55 +
 ..._b4add1998a9a81fb2c95539408bbeb64._comment |    9 +
 ...__41___for_special_remotes_parameters.mdwn |   18 +
 ..._63d48db769863cdfe411404e8c26a399._comment |   30 +
 ..._afa8c10bd3b1df649c1f643430b300e9._comment |   37 +
 ..._f19ff768a3903f80dbaa378b74d2a7e3._comment |   11 +
 ..._b031ee12622b1ed28b6ffc8c037f7d30._comment |   13 +
 doc/todo/auto-lock_files_after_one_edit.mdwn  |    5 +
 ..._afc78ecd06f0ee9a70ea6c89a8b63e46._comment |   10 +
 ..._4a6274dd1da7746a5be673ffb0c5d520._comment |   11 +
 ...toring_contentidentifier_log_for_borg.mdwn |   20 +
 doc/todo/batch_async.mdwn                     |   75 +
 ..._b68dcc98856f7b757e539c499db7ebd1._comment |    7 +
 doc/todo/batch_operations_for_remotes.mdwn    |    3 +
 ..._9a2f21febec8f49c782e464973dbc4fc._comment |   16 +
 ...t_message_for_git-annex_branch_commit.mdwn |    6 +
 ..._c8836a164c8c1efedd5467233237bfd0._comment |   24 +
 ..._41a25215d9a1f635573d5e5f5c30fd62._comment |   25 +
 ..._5241eace21e873678a0fbb353f4ece69._comment |   16 +
 ..._caf913b53a54ac010dba253fca1ef76e._comment |    9 +
 ...etter_error_messages_for_local_remote.mdwn |   13 +
 ..._094e6a7b62c8b81185cda06a62104f1f._comment |   11 +
 ..._4c8115fa0a41bd1cbecdcf7a4d9608ed._comment |    8 +
 ..._2dd5e994a8ce6352eac78cfd69934316._comment |   11 +
 ...ing_of_filenames_in_views_via_unicode.mdwn |   28 +
 ..._85eb622f3e651ad3cd42def62e2a83fd._comment |    8 +
 ..._b6d583625aa8821bde31464e8f19a34f._comment |   20 +
 ...rnal_special_remote_protocol_mismatch.mdwn |   27 +
 doc/todo/better_way_to_get_missing_files.mdwn |   26 +
 ...rt_offline_operation_and_verification.mdwn |   77 +
 ..._ab16dfb6c3fe2a70ddfb0cee287c6127._comment |   35 +
 ..._262f9d68a865300d894c4077e0e8a70c._comment |   11 +
 doc/todo/build_a_user_guide.mdwn              |   45 +
 doc/todo/cache_key_info.mdwn                  |   42 +
 ..._578df1b3b2cbfdc4aa1805378f35dc48._comment |   11 +
 ...__given_a_checksum_and_filename__63__.mdwn |   12 +
 ..._c81e5d438b06e28392e4ae789a84a2e8._comment |   27 +
 ..._2cdaffbc72d5ef197a3ef7ffb306312e._comment |   21 +
 ..._4520660c0f66bd73158887f22586886e._comment |    7 +
 ..._ee750e205acefe400d13c3a5e967ca3b._comment |    7 +
 ..._ec644589ec44a442dc2f3bd2244c9800._comment |   43 +
 ..._aa8c191593789900e966a37f9117dd97._comment |    7 +
 ...ey_cannot_be_used_outside_of_git_repo.mdwn |   11 +
 ..._c54b53c5f81132bedf75eb6b439a202d._comment |   21 +
 ...t_to_delete_original_files_by_default.mdwn |    7 +
 ..._4eb794daaeef843b104bd480e11f7b42._comment |   22 +
 ..._f2d436822490e74544bf58a4f1c9ee79._comment |   10 +
 ..._6a7c2cbd85b5ac8e90933aaa9147e004._comment |    7 +
 ...eckpresentkey_without_explicit_remote.mdwn |    6 +
 doc/todo/cleaner_hack_for_man_pages.mdwn      |  119 +
 ..._d51be0df42cba6f3eba2b5157dc9d427._comment |   10 +
 ..._3dd91f4c788c81a4f7368f673778c106._comment |    7 +
 ..._34__migrate__34___from_adjusted_mode.mdwn |    9 +
 ..._551012fe6261269363719d83113d4e3c._comment |   45 +
 ..._8e9ecd2a3f9fc5cb80785b100aeb6e36._comment |   13 +
 ..._845206fa688ed4786262fe6d82464d97._comment |    8 +
 ..._4375a63a864306c39323fa4b159425d6._comment |   22 +
 ..._a0d4ffdf3edadb5381f242f65fa38932._comment |   15 +
 ..._55b5beaeba0de7bb1efcc2626570d3b5._comment |   38 +
 ..._a383c7303f1e942a830d9f730f1c0f00._comment |    8 +
 ..._e8ab74bb4951fe7f0c71630bb278ad6f._comment |   26 +
 ..._0ccaf798086a8c9511d3733b12b24c8b._comment |   13 +
 ..._e2d45ac485456ed9cb86f8e6bd23617c._comment |    8 +
 ...o_list_keys_for_old_versions_of_files.mdwn |   46 +
 ..._43c11d9467b4d4460aa97bfb88b4896f._comment |   18 +
 ..._5062a0f8b57fdebf74fef8a65ac0a0b2._comment |    8 +
 ..._3c605fbd4c20522e265ef080675c3669._comment |   16 +
 ..._98d09316dc39619203e507f862716bab._comment |   14 +
 ..._annex.skipunknown_transition_in_2022.mdwn |    6 +
 doc/todo/compute_special_remote.mdwn          |   62 +
 ..._9f4835cd08d9d02009b685f4a366a245._comment |   15 +
 ..._bdb9c77b3ac97cef8d1b8eeaaf300d8b._comment |   18 +
 ...progress_reporting_for_some_git_calls.mdwn |   10 +
 ..._06d6dd17b7bd45b96276770b09bedca9._comment |    9 +
 ..._d9135802f29b78749833b7fd9967cc0b._comment |   17 +
 ..._8a6027fb58c4b7aaa3f82b5fd1c2812a._comment |   11 +
 ..._ceb543ebac42bf7a5f1571ff3f4ef977._comment |   17 +
 ..._ec99ba117fac299fc361a32de4ff29a5._comment |   12 +
 ...__mode__34___on_crippled_file_systems.mdwn |    7 +
 ..._e3cd8d86869d8a63337f7eff0b91ddbc._comment |    7 +
 ..._3580025d828b27072530eb8ccda9bdf4._comment |    9 +
 ..._d300407d70f799958734df1722fe923b._comment |   18 +
 ..._9367cfc5e12e43db6b53f43dc468757f._comment |   12 +
 doc/todo/confirmed.mdwn                       |    8 +
 ..._to_copy__47__merge_availability_info.mdwn |   18 +
 ..._68c86b06b3b0c8cc9c3faac97e3f6c3f._comment |   27 +
 ..._8993cf9badc8348604c662e35ba6f199._comment |   10 +
 ..._53a7a0d5ba6be411bdae10a6f8ba16fc._comment |   46 +
 ..._d82ee205451cf55eb283952c4774d32a._comment |   17 +
 ..._3565680846a8d547d0912d1ef31430b2._comment |   39 +
 ..._e479e9b65a512727f2816d4abd72b900._comment |    7 +
 ..._d64e8d82f139146338ce2fd4af1b7ad7._comment |    8 +
 ...__47__move_support_for_pushinsteadOf_.mdwn |   58 +
 ..._c5eec865ac5493f8bedf4fcba6759d6e._comment |   15 +
 ..._b6d694d34e6d5a684249b11f53a8532f._comment |   24 +
 ..._e53e69ae3adc42bb2bf36af1f07a4c83._comment |   25 +
 .../copy_instead_of_rename_on_reinject.mdwn   |   36 +
 ..._8e1fefa8231cc93f0f1958e44d869c47._comment |   22 +
 doc/todo/copy_with_both_--to_and_--from_.mdwn |   18 +
 ..._81fb304a2cdd50aa58f839a89d25f2ae._comment |    8 +
 ..._0c42c2269e2fe2888254cc14a4967535._comment |    8 +
 ..._7db9f62f5aa3640d1f4aeeb599e02e7c._comment |   16 +
 ..._05a8fbcf2b069c561b6e24286565af5f._comment |    8 +
 ..._b4d6b876c8f36a61268e2144d3bcf082._comment |    9 +
 ..._8fbf7e5ef86892f05b63e73373a97f0f._comment |   53 +
 ..._4397649b4a2115891cb0f597999cca66._comment |    8 +
 ..._959f6081cb3cb777ea4fad70bad07da3._comment |   35 +
 ..._a230b52cd5985437827bb432a85349ce._comment |   13 +
 ..._3152d196f56561d31a00514c343669ad._comment |    8 +
 ...git-annex_binaries_be_prelinked__63__.mdwn |    8 +
 ..._debug_logs_but_erase_them_on_success.mdwn |    5 +
 ..._72b1e3b25a221f42ea7919aaecd6012d._comment |   21 +
 ..._8809f216aac308962917053ea24b9022._comment |   36 +
 ...ntent_changed_while_it_was_being_sent.mdwn |   29 +
 ..._bce631c26907d03314cfc2e94933cce9._comment |   10 +
 ..._8093d410c2b359967ee7ee8886d7e4c4._comment |   10 +
 ..._78551b601b04b8336a858adfcff29507._comment |    8 +
 ..._d9faaaf2dd44e609fcf361189b247bed._comment |    8 +
 doc/todo/deferred_update_mode.mdwn            |   42 +
 .../deleting_a_repository_from_history.mdwn   |   11 +
 ..._bcaa591f37f3496c2f7a2e1f06450002._comment |   12 +
 ..._69de586c7c030f75fd540d05a6ca4ddb._comment |   16 +
 ...e_submodules_after_path_changed_by_mv.mdwn |   75 +
 ..._9f9da126a031d2a4c98555b381dbcbdc._comment |   11 +
 doc/todo/distributed_migration.mdwn           |   71 +
 ..._8734d30aa0c1cb27dce81a0277d24948._comment |   10 +
 ..._fdaef5d870221d44c57fc3bd1501e7ee._comment |   17 +
 ...ributed_migration_for_special_remotes.mdwn |   41 +
 doc/todo/ditch_yesod.mdwn                     |   36 +
 ..._976dcb99ebe30c02c9b223f19a67c875._comment |    7 +
 ...o_not_bug_me_about_intermediate_files.mdwn |    7 +
 ..._count_trusted_repos_toward_mincopies.mdwn |   56 +
 ..._66a71fdd9bdc2387870f4216841b9900._comment |   12 +
 ..._058f521451ff38d2072af6c944143ab1._comment |   20 +
 .../dockerized_external_special_remotes.mdwn  |    3 +
 ..._82d0eba3b5658990aa1e909758d75291._comment |   15 +
 ..._d1a0106951c070b56bc30a67c8804374._comment |    8 +
 ..._61a23adb5b871b178d3fb5a51602cf46._comment |    9 +
 ..._a044848ea54aebc2196376f9a59ccc70._comment |   24 +
 ..._3ace886382ff165db6f36df8743ca7c1._comment |    9 +
 ..._4e09e2a08f07924ef791d63da56df066._comment |    8 +
 ..._c43d5137b595edc3db130158293431ff._comment |   13 +
 ..._dc3e46508758b1df241ba0af78fbc692._comment |   11 +
 ..._a32b4ec09da1bee3c960fa8fcfa0d797._comment |   23 +
 ..._f5c0b77e06b7a65f2582c56011217d5c._comment |   14 +
 doc/todo/document_git-annex_dependencies.mdwn |    3 +
 ..._bb9cbd703e57adb9ca45e2cea94308a0._comment |   12 +
 ..._bcd0fa1ace9a22b0cc09cea2e7cad84c._comment |   10 +
 ..._ac0b1db3d447240b49686920a71ff91b._comment |    8 +
 ...ard_groups_more_extensively_in_the_UI.mdwn |   14 +
 ...tion__58___improve_on_special_remotes.mdwn |   12 +
 ..._edd0a4e9894d07e7bae9fef1fe4acf6d._comment |   14 +
 .../documenting_sqlite_database_schemas.mdwn  |    5 +
 ..._cc94cb2467c2b261c0b79c64853103a5._comment |   11 +
 ..._06bc5d625d9a3e7522c7f6df53a7ac3d._comment |   26 +
 doc/todo/does_not_preserve_timestamps.mdwn    |   18 +
 ..._8cce043ff86fefc3dcd97cf5c4428786._comment |   14 +
 ..._eea115becce4ac79932d8cfa2903f20c._comment |   21 +
 ..._a8b69299c9278c16c6c5061d88bc7eca._comment |    8 +
 ..._e37ea5188bd48817ccac82141906ee83._comment |    8 +
 ..._9a3f50f1b8cfd1cc0da83937a36e1369._comment |   18 +
 ..._caf5e5cb17f4d05fff8c2fab661cd93f._comment |    8 +
 ..._c337fca1474b5b78f61ad6f421138ae4._comment |   12 +
 ..._9a3eeddc46e5a420575f00cb47caf703._comment |    8 +
 ..._99b064259fc2e3c6eb83c3da3b2d3bac._comment |   10 +
 ..._c95c8b9bd617830604500213c962fc7a._comment |    9 +
 ..._b99e00d0bc4258c4cb28b544b19ea3b8._comment |   12 +
 ..._eefa6afce824f1069bb5216b392405b7._comment |    7 +
 ..._f2a32e39356f7b772ab9cf3136436700._comment |   10 +
 ..._62736ee2f299d62f685800353fc36ccf._comment |    8 +
 doc/todo/done.mdwn                            |    4 +
 doc/todo/drop_--batch.mdwn                    |    7 +
 doc/todo/drop_from_export_remote.mdwn         |   32 +
 doc/todo/dynamic_stall_detection.mdwn         |   24 +
 ..._a_discussion_forum_or_support_system.mdwn |  134 +
 ..._578c0ab40d53dd56bb3f2d98491c5e85._comment |   13 +
 ..._b1129b4cdfe39e740c4f7cf0d6ff2b91._comment |   12 +
 ..._52598af3d7b050981e32ad1569f69db9._comment |    8 +
 doc/todo/encrypt_only_the_credentials.mdwn    |    3 +
 ..._7c3911e8fbc981c7e1f32b1464ce4122._comment |   30 +
 ..._76fdfa927562d33dfea9630b3b729220._comment |    8 +
 ..._6f0ba120ef655d5250fdf3db53464fe6._comment |    8 +
 .../encrypted_keys_in_git_repository.mdwn     |   61 +
 ..._4d17c427756127f22dc472984259f8d7._comment |   23 +
 ..._6679caba100bee0a0fe32c8eef50758e._comment |   21 +
 ..._a79ea55e2f8a1095f0110f2f0853dee1._comment |   21 +
 ..._e88664a0939b7bca730a61efb47d34ab._comment |   14 +
 ..._05b0e2e88b233691b403d4c908b50c52._comment |   14 +
 ..._9e25b4d05d61fc3a3cca4f7111681a5f._comment |    8 +
 doc/todo/encrypting_URLs.mdwn                 |   10 +
 ..._9d0dda82d1f3907e6478a95608388836._comment |   12 +
 ...data_needed_for_view_inclusion_or_not.mdwn |  116 +
 ..._17f8adc8555ea0a2716308e3f5188a25._comment |   16 +
 ...--json-progress_--json-error-messages.mdwn |    6 +
 .../export_paired_rename_innefficenctcy.mdwn  |   12 +
 .../expose_fsck_last_run_information.mdwn     |    5 +
 ..._44f5eb2e601ba1a6cb22f5de7a6d3ff6._comment |   22 +
 ..._9a1729dfbec291159000d3412dd147d7._comment |    8 +
 doc/todo/external_backends.mdwn               |    9 +
 ..._4c0f8a338a58cef8e239613292d5aa38._comment |   11 +
 ..._56224638fde7b46ee6f52211474cd047._comment |   15 +
 ..._268cd038b7beb9d42cf0bd8803efce94._comment |   28 +
 ..._6e8452f06da80458bb2cccde05cc9813._comment |   10 +
 ..._6edc4008ce8eec17e283dd7db8dbcbf0._comment |   26 +
 ..._7880557cb94706d82a6d2bfc785288ea._comment |    8 +
 ..._9d73d6dbfabe3d58a41b661825bf3dcb._comment |   61 +
 ..._a2528865e48f85feab5569951f13caa9._comment |   14 +
 ..._9451d002f6768dd5975d5816c12b1350._comment |   15 +
 ..._2983bbf5e1cc485da3e8e9628a4bea89._comment |   13 +
 ..._37fd824cf9f2dcc59616b9d49e38c262._comment |   10 +
 ..._d871bdf09932035acc6260c839f45757._comment |    8 +
 ..._090e62b5d37beb5d62d56cfb3b1e2134._comment |    8 +
 ..._e3c66820da36fe255d07059226690ca4._comment |   16 +
 ..._bf2de8fdc134684f0af2b53bc9b78f08._comment |   20 +
 .../external_remote_querying_transition.mdwn  |   53 +
 ..._838311ffa7f00d65c9ab23717dd117aa._comment |    9 +
 ...orMsg_to_-FAILURE_messages_lacking_it.mdwn |   32 +
 ..._a096df37d5bc5543b574b32554311af9._comment |   19 +
 ...es_not_using_git-annex-remote_in_name.mdwn |   48 +
 ..._8bb17f1a8297b500dcc5bdf9412a5d6c._comment |    8 +
 ..._to_realize_the_need_in_pidlock__63__.mdwn |  219 +
 ..._9c77d8cf628025308c2561a8a46d2365._comment |   20 +
 ..._0d7eb254ec9ff7ba8b1831898008747f._comment |   16 +
 ..._26f82b5ef0ce9dc0a5a8fc64f4a3b335._comment |    7 +
 ..._3e2b49710772340238358041ba91bc25._comment |   39 +
 ..._009ffc560a14061feb8d748e1d2d9b71._comment |   10 +
 ...date_of_view_branch_by_git-annex_sync.mdwn |   27 +
 doc/todo/filter-branch_for_objects.mdwn       |   14 +
 ..._prefer_keys_by_file_extension_in_key.mdwn |    1 +
 ..._fcf6f2c6ecf49930f4ddbf9b35301bf3._comment |   55 +
 ..._751137f0fd1815adfef69bec6a2cbe22._comment |   15 +
 doc/todo/findkeys.mdwn                        |   20 +
 ..._da758b20bca40e0580526e52ea3e9a61._comment |    8 +
 doc/todo/finish_sync_content_transition.mdwn  |   14 +
 .../force_star_topology_on_a_repository.mdwn  |   27 +
 ..._cffe5ae2b85022ac9f58ce668ec9bf97._comment |   21 +
 ..._6e735205024588497a116ce9e7e621a9._comment |   12 +
 ..._154614345d2b8f4260c88e9061bf4255._comment |    8 +
 ..._a722bce9ea8c94864657415395eadb43._comment |   37 +
 ..._60d832d97923d3aac047dd525dc8df12._comment |   17 +
 ..._8bb1f37233055c53d98c73fed4224b50._comment |   40 +
 ..._6b08f09f690f7791f59cb90db01c4cf0._comment |   26 +
 ..._f840a405028df2630a7c8eac5091833f._comment |   18 +
 doc/todo/forget_dead_keys.mdwn                |   25 +
 ..._e4c7db734087dc4c2f6b86bb774136fd._comment |   27 +
 ...ce_checking_for_local_special_remotes.mdwn |    4 +
 ..._47c254cec58cbbb3ea84c93ef8282f01._comment |    8 +
 doc/todo/fsck_scrub.mdwn                      |   18 +
 doc/todo/fsverify.mdwn                        |   53 +
 ..._5fcd23950ed5409e52d7954abf71afa9._comment |    9 +
 ..._c81b458a8ee0f15950adbd32dd168972._comment |   48 +
 ..._6d95fc858ca780f087c48e4a6a4ab25b._comment |   14 +
 ..._551bbaf8f22add6ad1e2774e76a1d078._comment |   13 +
 ..._bfbec043d803ff1aa649f2661f6918f4._comment |   27 +
 doc/todo/get_--batch.mdwn                     |    8 +
 doc/todo/git-annex-addunused-historical.mdwn  |    7 +
 doc/todo/git-annex-cat.mdwn                   |    7 +
 ..._a5da8264c2d662e96802535820cb2249._comment |   15 +
 ..._a43a3568e48e6b5e93998bc473178d5c._comment |   10 +
 ..._347a33a4a77fd385ab8f3551138b75e1._comment |    8 +
 ..._8708bf0aef0025e2ed1a8b9d2a7f0112._comment |   15 +
 ..._f78a6a136610f3fca7a02a3af9c19e25._comment |   11 +
 doc/todo/git-annex-export_--from_option.mdwn  |   10 +
 ..._10f107aa0094d5ee4886878f5b1aaf06._comment |   13 +
 ..._72e7dc2a6b3cec21c941a5f7a2914050._comment |   11 +
 .../git-annex-migrate_using_git-replace.mdwn  |    7 +
 ..._6a317be851dfb72c4aaaf5786dd1a1ff._comment |   16 +
 ..._e760213fc51f6a2cfc68dec711622f25._comment |   14 +
 ...nex-sync_handling_of_linked_worktrees.mdwn |    3 +
 ..._3e542583247177f9cdf44122ec483a0c._comment |   18 +
 ...tests_if_external_utils_have_problems.mdwn |    3 +
 ..._240c9c45a629124dc35f4ed0dddd7355._comment |   15 +
 doc/todo/git-annex-unused_--history.mdwn      |   15 +
 ..._9b9518a88e5f90d68b4131c430e66881._comment |   14 +
 ..._d0aa8cc29e38510b2bb1c4ce356aa2ac._comment |   12 +
 ..._21797e55d27356411430b3ec07af5264._comment |   10 +
 ..._sanity-check_git-annex_branch_pushes.mdwn |   57 +
 .../git-lfs_special_remote_simpler_setup.mdwn |   27 +
 ..._4e9f8b60dd1b705d4755200dada8801c._comment |    8 +
 doc/todo/git-remote-annex.mdwn                |   24 +
 ...ist_all_the_parameters_for_the_remote.mdwn |   34 +
 ..._875fdf1aacff3cc2c3732450f052d711._comment |   17 +
 ..._information_about_repo_version__63__.mdwn |    6 +
 ..._783c53fd99747bc65bd832f918c50a59._comment |   10 +
 ..._60d3b088de83c86243b19c3d0d050080._comment |    7 +
 ..._d6e84551319439ba50bc10edbd25335c._comment |   11 +
 ..._5b3e45c746e6cfa7f511790bbd9f6c9f._comment |   10 +
 ...smal__44___huge_improvements_possible.mdwn |   30 +
 ..._4828098be3e7cd6109bd1934bf029f1f._comment |   90 +
 ...to_not_care_about_submod_status__63__.mdwn |   21 +
 ..._607ec43498187636312693932f66cc6d._comment |   13 +
 ...etch_and_push_to_import_export_remote.mdwn |   17 +
 ...repo_tracking___40__not_storage__41__.mdwn |   10 +
 ..._e47bc088880a9e839f5c437117c58b68._comment |   26 +
 ..._4af24f7207f63eb4cc127a64c1fc5fc3._comment |   10 +
 ...it_smudge_clean_interface_suboptiomal.mdwn |  123 +
 ..._2247cea7e7ca09389073fb32e98394e7._comment |   18 +
 ..._39e671908522b79b8054ed9ddcaf918c._comment |   16 +
 ..._bb2bf0e82985bf2045741205c4682813._comment |    9 +
 ..._b41830b59c47ce5041c6005d41baf550._comment |   12 +
 ..._8ad0fa4f67af60313d3195bc8c0acfb8._comment |   20 +
 ..._778d21703afc5c08bfbc387b442cc193._comment |    8 +
 ..._ef42e80aac54e02000c1a61b1f42aed0._comment |    8 +
 ..._8da190f9f0cece7215df28b0bc47b151._comment |   15 +
 ..._69b4455c0e54834503794f6f65de1fc8._comment |    9 +
 ..._d52b1ab7d6a186919b3edfd51347e161._comment |   10 +
 ..._e99ecb0ac561dd670f3ea7b2915de872._comment |   16 +
 ..._ccea12d55706ab2fc1b0ba46818354a3._comment |    8 +
 ...tus_smudges_unncessarily_after_unlock.mdwn |   39 +
 ...mote_as_a___34__transport__34___layer.mdwn |    6 +
 ..._f2c68afc949f54939fc760bd0d916b89._comment |   21 +
 ..._89be9eea4304897c639fa80db92cfe2c._comment |    7 +
 ..._43107f1bec1ad141af2e97f715a70fe9._comment |   12 +
 ..._9c557a788841bd34e5fa902e171d2b52._comment |   11 +
 ..._3bea0473d4805b1ef56b955ba30166e8._comment |   11 +
 ..._28aabb525a1a487eaecdfe591cc7108b._comment |   14 +
 ..._51b2078904c6a7c0fff2dd7d38791e6b._comment |   10 +
 doc/todo/hidden_files.mdwn                    |   38 +
 doc/todo/hiding_a_repository.mdwn             |  240 +
 ..._68636f0a35a1cd62e0390d1a752eba47._comment |   10 +
 ..._5d8224fdb6c77834b3bf55b2148d9f97._comment |   12 +
 ..._64ba3f1d5099e066d554566ca818bdd6._comment |    8 +
 ...4__async__34___protocol_for_transfers.mdwn |   12 +
 ..._64397d2700c9ab13885024b65d4d5adc._comment |   57 +
 ..._f2f2986f643c654c3d87be832687fc68._comment |   20 +
 ..._7e07ab418734d22ab032bb655b4b3645._comment |   42 +
 ..._0c4110101bf810816d4568b37018211e._comment |   22 +
 ..._ab2c969b5b561b75fec1d95c52598cb4._comment |   19 +
 ..._877ae38938a279fa100e58c03990e81a._comment |   17 +
 ..._59aa5bd5ac6cfe5976666853b5ce9fdc._comment |    7 +
 ..._c0f5b5098252df0f86528078f3c96ec7._comment |    9 +
 doc/todo/immediate_stream-to-sync.mdwn        |    9 +
 ..._457523845c5e63bae90ea5a84d57bf96._comment |    7 +
 ...tory_does_not_use_cp_--reflink__63___.mdwn |   21 +
 ..._7a297f170720daf25f7ecf133aafc6a4._comment |   17 +
 ..._04b63e4e2092ed455d23657e2b396d3b._comment |    9 +
 ..._20e31ffc7c490215db7a3f1a0a3b813c._comment |   10 +
 ..._50ae4126d701dbd3a0c9ed8770404228._comment |   13 +
 ..._fca845bb9869e8ce9a279952813ce481._comment |    7 +
 ..._f1475420fd16e664b907c4f24910a8d1._comment |   10 +
 ..._b57afb61d622d9f5b2555e7d80d0ff4e._comment |   12 +
 ...motes_need_a_way_to_resolve_conflicts.mdwn |    9 +
 ...ymlinks_when_importing_from_directory.mdwn |   15 +
 ..._60b1a3ab291bc7eec2ba2ad6ee044bfe._comment |   14 +
 ...import_tree_from_rsync_special_remote.mdwn |   40 +
 ..._b1f97f8d62c4e2f9bbe02955c7a4dec4._comment |   15 +
 ..._7e62dbfc5540a8737d77f25ad2acc4af._comment |    8 +
 ..._1d3acf47e3eff3680c1639de12823940._comment |   10 +
 ...ort_tree_preferred_content_expansions.mdwn |   17 +
 ..._df8ca8665e1dfc530a832b6d24d60ea4._comment |   29 +
 ...s_more_memory_the_more_urls_there_are.mdwn |   19 +
 doc/todo/importfeed_parallell.mdwn            |    5 +
 doc/todo/importtree_only_remotes.mdwn         |   79 +
 doc/todo/improve_memory_usage_of_--all.mdwn   |   23 +
 .../improve_unused_for_special_remotes.mdwn   |   29 +
 ...._add__41___failed_into_--json_output.mdwn |   21 +
 ..._f02e43b68c219b2d7d65ea868fac125f._comment |   23 +
 ..._3a7043652c692796b1a438a2c4c26828._comment |    9 +
 ..._2d41d67dcb6e700b1ecda3106e444a5e._comment |   15 +
 ..._c2e5041a07787ae84f85b898b1aae6b7._comment |   20 +
 ..._429e42b9c1989dade01300f08fc3c13c._comment |   12 +
 ..._3d5a33476a3fa773fda1e5f7a2d8c453._comment |   10 +
 ..._246e35f32f77af3b2924577b1bf45001._comment |   14 +
 ..._2e0ec2bb51a2a06184b94710616f211c._comment |    8 +
 doc/todo/incremental_hashing_for_add.mdwn     |   40 +
 ..._d00827f5edd7b270aa6dfc011e7c9f22._comment |  449 +
 ..._30b4c0f3b1c13e9a1a2ddba5f88eb6ee._comment |    9 +
 doc/todo/info_--size-history.mdwn             |   62 +
 ...ow_file_matching_options_for_all_keys.mdwn |   13 +
 ..._3b96becda1db6ae23adb5077b6332718._comment |   19 +
 ..._2d0a6abd5be8afce677eeea575aae548._comment |   25 +
 ..._aae866dc71811074d69b91c2390ccb01._comment |   17 +
 ..._371d53b4539bee6e3d595154033a2471._comment |   13 +
 ...how_total_annex_sizes_of_repositories.mdwn |   10 +
 ...other_scanning_if_in_git-annex_branch.mdwn |   34 +
 ..._2ff094dd4ff1fb05db90782d381441d3._comment |   22 +
 ..._2cbfb22e8f1d89d4f78ade565554cb1c._comment |    9 +
 ..._fe771be800a6b26157c3075e632ee1b7._comment |    9 +
 ...4__progress__34___of_annex_operations.mdwn |   20 +
 ...ep_git-annex_branch_checked_out__63__.mdwn |    3 +
 ..._cd967b89dbebd431a14b0dcd08ebc67c._comment |   25 +
 ..._620cfbb2e2507d340dfb25d1fcd2cdfa._comment |    8 +
 .../key_checksum_from_chunk_checksums.mdwn    |    4 +
 ..._946e2679cafd2c74a3b0b408e39f2d8d._comment |   10 +
 ..._aaff896ff99366d3b96c523284c1248e._comment |    8 +
 ..._352bc3eb419184a4ec70ddaffd78968e._comment |    9 +
 ..._e766f725e22ea0a38ac2277e08fd3839._comment |   18 +
 ..._561b9bb28c5d375334ce915da75d5ce6._comment |   11 +
 ...emotes_that_are_currently_unavailable.mdwn |   30 +
 ...motes_declare_support_for_named_pipes.mdwn |    5 +
 ...-matching-options_query_gitattributes.mdwn |    3 +
 ..._3e7c731037b8ce7148a6a597783d2ba3._comment |   16 +
 doc/todo/lockContent_for_special_remotes.mdwn |   76 +
 ..._835d075d22fd1544fc27b912ad3326d8._comment |   11 +
 ..._948993c967f7908adaea068e352e0607._comment |    8 +
 ..._432fc28c4e09fd514fd780ec16b9423e._comment |    8 +
 ..._13f4b8e180c727b775807e8e2aa5a11f._comment |   11 +
 ..._b006d6bca93a50e1f23a2b6d20584c91._comment |   12 +
 ..._01cc0fba0368fcda594d2835247dd884._comment |   61 +
 ..._463e336fd7f2cb21eff2d87d25851c39._comment |   13 +
 doc/todo/lockdown_hooks.mdwn                  |   59 +
 ..._649dbc3c951bbabc550e12e87e45b319._comment |   10 +
 ..._575c33970014662c664d71e573e718e7._comment |   28 +
 ..._f57299385578914f5bca05f06b76cd46._comment |    8 +
 ..._614d2c8c758f9920cd84748f8f0d384e._comment |   21 +
 ...out_reason_of_failure_in_enableremote.mdwn |    8 +
 ..._dbe339cb1860d27ebc7116ab4d6e50fb._comment |   37 +
 ..._06e98b0e0704dce8ced214600d0d6347._comment |    9 +
 ..._1c1aaecf15ee220ed5c39def48ccd734._comment |   12 +
 ...e_add_--batch_add_directories_content.mdwn |   54 +
 ..._e5707f72bb086c342c89fc3b5ccf00e5._comment |    8 +
 ..._5083e5a729f56dab76bdc97fb247b902._comment |   16 +
 ..._e320d2c3b625f24e2b93c5dab21a1e0f._comment |   10 +
 ..._98c678aefbc62aed7ceec8c7519d343a._comment |   15 +
 ..._4cfd430f9e9196ec293fb118e5118160._comment |   10 +
 ..._93cb877bf71acddcf15a6c1ed48d2768._comment |   14 +
 ..._2155ce0ab07a84a4f36bcf92c29ec792._comment |   11 +
 ..._5d63312c2efe3f1a25f9254ed230c66b._comment |   18 +
 ..._0bbdcf13e0ea7869c1633a34457d9a86._comment |    8 +
 ...ddurl_respect_annex.largefiles_option.mdwn |    7 +
 ...it__47__hooks__47__prepare-commit-msg.mdwn |  138 +
 ..._e7f759dccbfa134a772f15bc5f9c4b29._comment |   14 +
 ..._acd656bf30f7e0b5def7ad7a564cf914._comment |   39 +
 ..._0f49414f9b4a68a16a8d47a336242f13._comment |   16 +
 ..._203a356c1edfaf8c0c9cf01bedc2ec5d._comment |   13 +
 ..._c7a888605dd063fe7df7c569f1193f8c._comment |   36 +
 ..._b8bb9e5c7156e4defd7a2e8b7777e1ba._comment |   36 +
 doc/todo/make_annex_info_more_efficient.mdwn  |    6 +
 ..._afd5c806f7285442401b027f82a8c629._comment |    8 +
 ..._0770ef5c4c261949a565723073480dcb._comment |   10 +
 ..._c022caab61061b1f77b78485089a9052._comment |   18 +
 ..._923dd7c22920b389488ca2625225164c._comment |    7 +
 ..._c6c8850aefe3ab81f1f113daa734695b._comment |   17 +
 ..._804dbb72757b09e3abad3e249f704da0._comment |   11 +
 ..._44efc2bfcdde576aaca002595476a2a2._comment |   10 +
 ..._90a22c51b19707ee0cecbe652c6ffa98._comment |   15 +
 ..._3bec13ce0c9f0932715d73106d576e86._comment |   10 +
 doc/todo/make_copy_--fast__faster.mdwn        |    8 +
 ..._1af4ac0d37c876912678522895c1656b._comment |   61 +
 ..._1ca8d9765e6e3a18ae09df74bc390a00._comment |   49 +
 ..._14856a2886cf73d1bee57ef9fad01661._comment |    8 +
 ..._0f8e2127cea96c4f9609fa7599b1eec9._comment |   10 +
 ..._24a9ca652007a18f18b368232cf549da._comment |    7 +
 ..._0c67f467d730a0966b43171de0382c42._comment |   49 +
 ..._5cd9e6b5d6d015120b5852bd212314aa._comment |   22 +
 ..._3ac10a07c74e5debafc9ae574d26c955._comment |   11 +
 ..._eb7008151a59e35c7850df3a86cf3587._comment |   11 +
 ..._3a08de49e9661f9df5bab272e170461a._comment |   28 +
 ..._3f52b6e19035d3c891356c6d98035987._comment |   58 +
 ..._c1f99493f5e5c362d5c39f048280b11b._comment |   45 +
 ..._f4d802a28b79905da0cb24af6cb65b0a._comment |   42 +
 ...___while_addurl_--batch_--fast___63__.mdwn |   33 +
 ..._f8ea668cd8a405226113ef2edeb9e678._comment |   14 +
 ..._50d04e85c0504f920ed7d2ccb9cdb6dd._comment |    8 +
 ..._2ebd0de2fe55230f4e589bd295c828a2._comment |    8 +
 ..._7d1154d80feca270f6226374a51a0609._comment |   39 +
 ..._8e931e54738640cecf0bbaf80a3e8660._comment |    8 +
 ..._3874f5da5a300b7d443e1ad6373b4099._comment |   11 +
 ...how_avoid_all_the_failing_opens__63__.mdwn |   65 +
 ..._20db4ecf9debcc2662ec69a6ad9b37c6._comment |   21 +
 ..._b3c5851c3603976d59927b591ba1d126._comment |   20 +
 ..._2363dac7701b9c36eb1896a09e68c17d._comment |   35 +
 ..._5d65192366f7690c22d1a209fb1e8f78._comment |   20 +
 ..._16aae09d0e1d80240fc3ae81e5b06972._comment |   45 +
 ..._013afa9d45970397bfcd60e57a519d67._comment |   17 +
 ..._c43788c8730619c3590d1a0a2bb87148._comment |   14 +
 ..._77a2f7d18cbcf780d8e2bb4a3e40b4fa._comment |   12 +
 ..._7650d349ba50972b64cd6d81673bf1c9._comment |    8 +
 ..._13b21a0523b8837f4e27bb78e35ad5e0._comment |   23 +
 ..._c67d403cb5bb67c3486ff9ade9607b2f._comment |   13 +
 ..._c67fe4be932b8e7e365ed336e612b526._comment |   72 +
 ..._6ae9e999b6af6b6bfe078dd187f7ff22._comment |   72 +
 ..._bfb9b94048fc239f29351a9d38c8d4e3._comment |   38 +
 ..._7a57b6713788778f6a6e8144cf3931b2._comment |   38 +
 ..._3a849428b335964f80a8503d44d51c5a._comment |   39 +
 ..._5f5d9af7ed807b8ef203426f717822b2._comment |   39 +
 ..._b45863d81e3790ea44714a18c1721abd._comment |   72 +
 ..._ce5fb75f944816b134fd2dc7a389b913._comment |  180 +
 doc/todo/metadata_--batch.mdwn                |    4 +
 doc/todo/migration_to_VURL_by_default.mdwn    |   29 +
 ...em_efficient__34___journalling__63___.mdwn |   39 +
 ..._5bbc2d651e4ce0ea5b20f199be5cb717._comment |   38 +
 ..._5a29f3bc596b463b6710a6654b2e271e._comment |   12 +
 ..._6486a0cf500f6ba3a9306cdc137f7b4d._comment |    8 +
 ..._3d1a1ede9d1b5048723a542996121dd4._comment |   59 +
 ...esolution_of_trivial_export_conflicts.mdwn |   20 +
 ..._5a2d7ea060f5e1be11c39521c0a5631d._comment |   19 +
 ..._70c3cfa9b95f3aa6c2e2e2f6dbbc50d0._comment |   66 +
 ..._d0549f8a07032ce61e88b4ccb2c6ef3b._comment |   31 +
 ...4____63____41___credentials_mechanism.mdwn |   15 +
 ..._7078d380be9e78fea9fd5bec4ef9594b._comment |   36 +
 ..._9e2c1d58f0d91dc55524d2e164b89b97._comment |   14 +
 doc/todo/moreinfo.mdwn                        |    5 +
 .../move_readonly_values_to_AnnexRead.mdwn    |    8 +
 doc/todo/multiple_-m.mdwn                     |    4 +
 ..._for_adding_git-annex-config_settings.mdwn |  108 +
 ..._bcc5d69426fc6af6affdaf251dd9dd5d._comment |    8 +
 doc/todo/needsthought.mdwn                    |    3 +
 doc/todo/network_test_suite.mdwn              |   34 +
 .../new_command_for_syncing_content_only.mdwn |   23 +
 ..._7f983de645430d970c75f25fee27b2ed._comment |   11 +
 ..._311cd71d61bea5782c71ee33282d152e._comment |    8 +
 ..._19398beb81c56b3b7cc3aff7081a2886._comment |   10 +
 ..._c72cbc566af9585b4701f833883f878e._comment |   14 +
 ..._857157a775711330df39b57828cf9bd4._comment |    9 +
 ..._3ca0ef151b73781d2fe168c56d54faad._comment |    8 +
 ..._084e139c8325bb8607f6c0a9f3873afe._comment |   26 +
 ..._c666e3ef20e823230392a70d6b588e7d._comment |   10 +
 ..._one_column_per_UUID_in_git_annex_lis.mdwn |   13 +
 ..._e6d9efa01ddeb129469b3b8a4205cb3f._comment |   16 +
 ..._049625685f6147f38392e2df1dadac33._comment |    8 +
 ...redentials_for_password_per_each_file.mdwn |   35 +
 ..._ae15355f54b5137e696aaf5d2111806b._comment |   16 +
 ..._0c60c791513acff3910a29513f7f2f78._comment |    8 +
 ..._2d8902e343e65a39b5a23278793ec921._comment |   13 +
 ..._39ccd0fe773200166d0727dc903c34e3._comment |   30 +
 ..._4dca41df7506fa7aedf88d7618bbcf39._comment |   19 +
 ...yingroup_preferred_content_expression.mdwn |   24 +
 ..._eddf28997789400398fbdd58ec64861d._comment |    8 +
 ..._b1a22e4fbc594c3085e7fbc6fbaab69a._comment |   34 +
 ..._8f205160e62aa1312b8e2ef4cafe8c50._comment |   22 +
 doc/todo/openwrt_package.mdwn                 |    6 +
 ..._100d76109e04bc43979775d71b4152ac._comment |   12 +
 ..._2cb7dd4c0cc4413a4588b13cf7700de2._comment |    9 +
 ..._5ba8a325a683ff543d81a366c873070d._comment |    8 +
 ..._132e67b34f9c616217e037e4ecac70a4._comment |    8 +
 ...optimise_by_converting_Map_to_HashMap.mdwn |   12 +
 ...timise_use_of_keys_db_on_local_remote.mdwn |    7 +
 ...optimization_needed__58___slow_uninit.mdwn |   24 +
 ..._3d01d125ffea8dd247e68f716a9c636a._comment |   12 +
 ...al_remotes_like___34__directory__34__.mdwn |    9 +
 ..._8620167702725aa8fb0e42dfe3820520._comment |    8 +
 ..._f964bb1a14f099e69f1e780ee7c7ef68._comment |   18 +
 ..._d4672f72a00509186cfc5dd85e1da140._comment |   15 +
 ..._4560eff896578ac2779b03ec3484d0b2._comment |   12 +
 ..._a154a025d441db4e0140fee821d1791c._comment |   39 +
 ...___to_not_drop___34__all_copies__34__.mdwn |   10 +
 ..._8f40b2663c9f48ddb07969af1b6632a8._comment |   27 +
 ..._32383ff5db43f0f4dc9e7470613f04fd._comment |   10 +
 ..._2665f3fc268dff1de24d6ee9648c5d8c._comment |    8 +
 ..._5fb82eb18c6d935ac07ec9220d9037c0._comment |   10 +
 ..._c7b9cbdbc4be36ea4d56a1eec13c6f34._comment |   23 +
 ..._aa58624e8d0de174a06c6c2c0e33dc14._comment |   25 +
 ..._150a87dea1bd24e3d4e18cf3bcfb937f._comment |    7 +
 ..._1e87a33fe71ec2d5f4df887b94dae7c6._comment |   13 +
 ..._references_to_not-yet-saved_contents.mdwn |    5 +
 ..._4e813660a7743ecc3378b87adb0cd0f8._comment |    8 +
 ..._8aec191966e5633ae6b1b008f8990d3e._comment |   15 +
 ..._7337c487d7118e0bfdf931a741f3d5a4._comment |    8 +
 doc/todo/option_to_explain.mdwn               |   42 +
 ..._81644886e14851a276dc3c89965df62e._comment |   10 +
 ..._71616074104ab70eb76ad5edb9207b5c._comment |   12 +
 ..._2179a7fec079045d82a58993d3f09995._comment |    8 +
 ..._28919c6f816f11811b1e8c73b07403f7._comment |   32 +
 .../option_to_individually_hash_chunks.mdwn   |    5 +
 ..._c6d5133efb3ddc9ac632530600257bdf._comment |   13 +
 ..._29821c673e5e8ce88c62086a67346357._comment |    8 +
 ..._3cd814797e837fae3dba8d6d99f41ec1._comment |   17 +
 ..._b2a78d90e7e2ee8a98f12663c9e1041a._comment |   11 +
 ...files_that_are_expected_to_be_present.mdwn |    7 +
 ...ption_to_put_temp_files_on_a_RAM_disk.mdwn |    5 +
 ..._28a5627604d2d4b25c51779a7216931d._comment |   15 +
 ..._1df752ac3b9cb2cc0e4a7dd4af71897f._comment |    8 +
 ..._12a1b6f9fd616f5c498d5aff1cf1bcb6._comment |   15 +
 ..._8c6aa3f5aee359f2f161b6664cdb5c32._comment |   22 +
 ...th___34__informational__34___messages.mdwn |   14 +
 ..._bfbf428da46eaea52cc54878f119512a._comment |    8 +
 ..._c43e838b750448fe4d1519e72c43242f._comment |    8 +
 ..._e006b8efab713d4965316c9846ec437c._comment |   18 +
 doc/todo/parallel_get.mdwn                    |   86 +
 .../patch_generation_with_annexed_files.mdwn  |  121 +
 ..._file_extensions_in_WORM_and_URL_keys.mdwn |    3 +
 ..._3cf91bca8e01f98644b0d25a45ecf092._comment |   16 +
 ..._to_download_remote___47__config_file.mdwn |   42 +
 ...files_using_all_disk_space_by_default.mdwn |   18 +
 ..._in_--json-progress_record_for_addurl.mdwn |   20 +
 ...41___version_of_initremote_--whatelse.mdwn |   61 +
 ..._5ed9864ef616d9e9b77a3d62561363fd._comment |   24 +
 ..._e9647b34aa79c414faf0f57ba17e6af4._comment |   14 +
 .../provide_windows_build_with_MagicMime.mdwn |    9 +
 ..._11adb1623314e8a43c50704c5e6e62d4._comment |   17 +
 ..._8f2d350c853f8827e1d5f95897dc2bd8._comment |   14 +
 ..._15509110c5900aee2cc977372da16f0b._comment |    9 +
 ..._4727291eefa07a40da13dace75a2e255._comment |    8 +
 ..._4633d2a40bca1ba8fa93f7038569715f._comment |    8 +
 ..._5542a421c6c7c878394d7dd7a3bce9c1._comment |   12 +
 ..._d16e4fb3d0be2acd23d158272171b842._comment |   12 +
 .../proving_preferred_content_behavior.mdwn   |   75 +
 ...licurl_config_for_all_special_remotes.mdwn |    8 +
 ..._58b2ec259bd3d9e368240e459330a738._comment |    9 +
 ..._d9933855e8521ebed00406a6350837b7._comment |    8 +
 ..._42ac954b120205650a2a5f03872085c2._comment |   13 +
 ..._3c144c0323d49f7ca2d6b9971ad3160a._comment |   28 +
 ..._1d9186506f8f44415706f3b4394c9008._comment |   21 +
 ..._7f027aa4b5b495a93aee3cd3417862a8._comment |   22 +
 ..._c35df3621c7b6a1b518787fdc8967ee7._comment |    8 +
 doc/todo/read-only_removable_drives.mdwn      |   17 +
 ..._979455e3694ae2403134ed6fa2add2fa._comment |   21 +
 ..._08fced29b86b21f63bb0868747227e08._comment |   12 +
 ..._2675e211c7bd248b7f7c1bbc6fd46679._comment |   10 +
 ..._9e9bc6dd5fa8c4cf7f2511b771bd1bc7._comment |    8 +
 ..._a693c5744bfc6c33f5605aa9d9c0bfe0._comment |    8 +
 ..._737e3d315f29a4fc61597ce4f9ec6206._comment |   20 +
 ..._16c8652d38ae57db4ed1860a4733a18b._comment |    8 +
 ..._a802e0617c9ef72eb8d3842de99e44ae._comment |   11 +
 .../record_ETag_when_using_addurl_--fast.mdwn |    3 +
 ..._cf15e943ba9405240aecc3dc83b4ef08._comment |   14 +
 doc/todo/registerurl_--remote_REMOTE.mdwn     |    7 +
 ..._9d99569edd7ee8331626ec9fffeaa1b7._comment |   13 +
 ..._59f6ff108c40b4597a7a870fafdaabc2._comment |   39 +
 ..._70244d4f7f81b6799cd541ad14b38ee0._comment |   14 +
 ..._334ce2eb815d6d8489f9cb00c09b0bd7._comment |    8 +
 ...in_journal___34__in_place__34____63__.mdwn |   33 +
 ..._0de07ff7054e7d71a6cf1d08051664f9._comment |   39 +
 ..._b41f6266e341ec05586e6ec32b6cf68a._comment |   73 +
 ..._3994a27f274ef2025300291ff1bce8bb._comment |   10 +
 ..._0154b05e0b0edccd8e69657501938d92._comment |   31 +
 ..._aafc89e24d5640dad3b8f6134c1ac26b._comment |   11 +
 ..._41ba5600367f6893e8ed0bf01be3d539._comment |   33 +
 ..._b120af2367cc3667934c088b496331f6._comment |    8 +
 ..._fe41f306edfb0ae608dfb3a8f153bcbf._comment |   13 +
 ..._6b4df9d81c523e090b83c56bfdce373a._comment |   16 +
 ..._b23a39f88879b3c770e112f9e82c4607._comment |   35 +
 ..._98cd9e5dd449cbd834f53d97fd5dfc13._comment |   19 +
 ..._532690bc7b9707aa053814c3e84b1dca._comment |    8 +
 ..._fc54794546e8e14b31aa063d93c328de._comment |   24 +
 ..._953eaa6ca651597897a6c6ad7a259d1d._comment |   20 +
 ..._4b576c9c33ff2a322cd832027484606b._comment |   15 +
 ..._fb760c2566b6f37ed7378bbcca5875c5._comment |   12 +
 ..._148392f465864f19593de0b1aa56f7f8._comment |    7 +
 ..._a4fce84f5777ed582fa599778835455f._comment |   56 +
 ..._56c313fdcb88e95abaa10647678bc108._comment |   10 +
 ..._13c0eecd57ea56bb1e21e130d7343778._comment |    8 +
 ..._52a1fe104856968488b386b701c4a4bd._comment |   27 +
 ..._29a487203bf620e44c3e9db2d22f5ee3._comment |   14 +
 ..._6bf718a1c6185b6aed0b6d0d5c4c9cf8._comment |   14 +
 ..._e041fcd11c50d47eada124368a5bb7b5._comment |   17 +
 ..._dd5a1bdc1cc3ecd6ac68cc83fb2195ed._comment |   19 +
 doc/todo/reinit_current_repo_to_new_uuid.mdwn |    3 +
 ..._2274082a0d130127eb2fcc12e3404d08._comment |   12 +
 ..._d7f2a6de08a3559a1d76ae8aba5a6702._comment |   10 +
 ..._94434f7e76df4a25d922eed28ca6b559._comment |   16 +
 ..._9d2b98c15d78781f943f0f2ddf775706._comment |    8 +
 doc/todo/remote-ready-command.mdwn            |   21 +
 ..._55cbea73adb94e85fc2e2252d6f2f03c._comment |   20 +
 ..._0e79b93a9c614a259b9a7d7c1f6cb6dc._comment |   19 +
 ...ove_legacy_import_directory_interface.mdwn |  148 +
 ..._335ab41b3539f605ace1830577794913._comment |   11 +
 ...34__process_done__34___debug_messages.mdwn |   50 +
 ..._3b069234f20378fc231802c594eb213d._comment |   12 +
 ...ries_that_count_as_more_than_one_copy.mdwn |    9 +
 ..._cc1ea7d1c6aac3749b4ecd789594e3f9._comment |    7 +
 doc/todo/required_content.mdwn                |   25 +
 ..._42620a3c958666be2a0d5f5b8eadf7b4._comment |   23 +
 ..._132ec6378db63af6281569cf5748b9d3._comment |   14 +
 ..._b16a8e8b45ceee887c8c0167b7859654._comment |    8 +
 ...motes_from_standalone_git-annex__63__.mdwn |    3 +
 ..._8a59da3012b9d177b4baa72610b72fc9._comment |   36 +
 ..._96f1138462fecac628751d872e2ceb9e._comment |    8 +
 ...rl___40__and_future_add__41___--batch.mdwn |    6 +
 doc/todo/reuse_desktop_notifications.mdwn     |   30 +
 ..._6193ed5a4ad0a908af82da33d14bd654._comment |    8 +
 ..._3fb10a432a57ce14cb7bc2946467ab22._comment |   15 +
 ..._ac0e5f437b5d2677e916224d6dfaf666._comment |   13 +
 ...entkey_option_to_record_chunked_state.mdwn |    3 +
 ..._99bf00b8f78d75888dc7bc69d36cd112._comment |   12 +
 ..._42e9309fff6a71c1a0a625dd2bc6aae2._comment |   12 +
 ..._97ed902a268ebad53f534dd48a6f5fc9._comment |   14 +
 ...itory_mode_not_supported_by_git-annex.mdwn |    9 +
 ..._b219d62cd7d21002ae73d0dbd4b792be._comment |    8 +
 ..._7140ad0abbb54f5a4e20b165a08793e2._comment |   14 +
 ..._c3dff87829e3f055881829eb4598f903._comment |   10 +
 doc/todo/shorten_git-annex_manpage.mdwn       |   38 +
 ..._4b82eb4af9b923b23c6ecd8d355c0651._comment |   24 +
 ..._859444d7e2826ac4448b0ba0f716328f._comment |   17 +
 ..._3543a2edda668c3f0a90c46aeee94812._comment |    8 +
 ..._fa6c2870f4a83d0f5680b76b05009e4b._comment |   14 +
 .../shorter_keys_through_better_encoding.mdwn |    7 +
 ..._4bd588a3cdca5cb94132549b7d78e6af._comment |   10 +
 ..._454cb3b2b1102ce4da18f245bc583e7c._comment |    8 +
 ..._9f5f16a7ab5d3e28cdddc333d97b87ea._comment |   19 +
 ..._720012572e1d748bc628fdb17a55a3bd._comment |    8 +
 ..._41857b7f25f8a922640378a41574b84d._comment |   11 +
 ..._de3f0be0f6b560ca7bb66f7b5c8f0592._comment |    8 +
 ..._d499c66c9a1981bb14d0ce63f4983ea5._comment |   17 +
 ..._5592ac9d1887183daf3173a0c27b672f._comment |   15 +
 ..._75f611c63bf1e9c8b4885fea8e9d467f._comment |   10 +
 ..._info___40__behind_option__63____41__.mdwn |    3 +
 ..._74c3bbb7819368a894ff1189988e4cd3._comment |   44 +
 ..._0cc7a3c53ffbabcb13807956541d83ec._comment |   10 +
 ...here_unused_file_was__44___i_can_wait.mdwn |    9 +
 ..._732f726f72f2540372d434974fda60f2._comment |   11 +
 ...adonly_removable_drives_in_the_webapp.mdwn |   15 +
 ..._c41140289f9b062e96cfd5d9d5382155._comment |   15 +
 ..._b9236ea884a2934dd0c8e511a80f4fda._comment |    8 +
 ..._time_of_last_interaction_with_a_repo.mdwn |    1 +
 ..._4ec9597df62dc4a2f7320f13f6a0ee8e._comment |    8 +
 ..._997d9968782f7fd96d9edd9c380a3ee9._comment |   32 +
 .../simpler__44___trusted_export_remotes.mdwn |    5 +
 ..._cc6a862519677ea18f78d24f40a48be1._comment |   29 +
 ..._5528a5dd5f8d7746b175552a077ba313._comment |    8 +
 ..._3e7be2ba92559a767ea09b764daef2db._comment |   22 +
 ..._be525962211e8c4da681279aba132c71._comment |   14 +
 ..._aeefb4803340ff993a1d6673c8e5e97b._comment |   11 +
 ..._0d27b08792112cbee7a368bc94044bb4._comment |    7 +
 ..._for_a_special_remote_of_a_given_type.mdwn |   17 +
 ..._8ea993d1acc92f3aa9594ed8e2d3ec7d._comment |   30 +
 ..._96fae68472f7f9ef720c27149556f7a0._comment |   10 +
 ..._b75ffc63f0e9a85c3d1f01bdce21c97c._comment |   18 +
 .../specify_gitconfig_for_test_suite.mdwn     |    8 +
 ...__58___extension_of_speculate-present.mdwn |    6 +
 ..._264538d1cbf07254a2857ca4cf40e9ac._comment |   39 +
 ..._93450de83c4843f6828e971a948d12e3._comment |   12 +
 ..._272d66c3549892687879ef20e0cd9cf1._comment |    8 +
 ..._8627a8073fe0b4c144f26d32626e0c1b._comment |    8 +
 ...up_VURL_by_avoiding_redundant_hashing.mdwn |   10 +
 ...ndalone_build__34___and__47__or_tests.mdwn |   41 +
 ..._0e070bc39eb0b8d9cf307af8a06504dc._comment |    8 +
 ..._41749c4c9b317a58e02df99f748844a1._comment |   23 +
 ..._f462ee4719b4c459c12e36ce29ab82b5._comment |   13 +
 ..._dfd20b6c6a49c99243945a267e041d58._comment |   38 +
 ..._650e5dd2471cdfd0223d712771067d55._comment |   24 +
 ..._0ee51fffee1f591173418212919bcd30._comment |   12 +
 ..._b4aecfd9f1b7f0e16d5f1dcb3c16af3e._comment |   16 +
 ..._e11ae8ba6dd6e6c53891db954d28bfff._comment |   45 +
 ..._b06360071e05df18b895322382357b61._comment |   17 +
 ..._2253c6916a1c6e4f1393b8656617aa10._comment |   17 +
 .../speed_up_annex.adjustedbranchrefresh.mdwn |  105 +
 ...eed_up_drop_on___34__heavy__34___repo.mdwn |   38 +
 ..._5c92b3e7c2fc0e8a8e943690c1806322._comment |   15 +
 ..._a5587ebc2a406d52855868cdeb39b83e._comment |   15 +
 doc/todo/speed_up_import_tree.mdwn            |   50 +
 ..._import_tree_with_many_excluded_files.mdwn |   89 +
 doc/todo/ssh_special_remote.mdwn              |   44 +
 .../stalldetection_for_import_and_export.mdwn |   13 +
 ..._growing_number_of_libpcre.so_lookups.mdwn |   55 +
 ..._ef6645a9b6d69a652cd042185c864677._comment |   33 +
 ..._181175a281f3a4298341d109064eeff8._comment |    8 +
 ..._0358f9e216271ba0be8684eea4a3e1d1._comment |   10 +
 ..._5e3c73faeaefee8f0ec1227c672f2be5._comment |   18 +
 ..._91ab4b860a074c90e5cbeb03e3515ad4._comment |   13 +
 ..._2e435cc8fe61c7ca7c59f2a63fbbee20._comment |    8 +
 doc/todo/stop_after_these_files.mdwn          |   27 +
 ..._specs_as_was_done_when_wget_was_used.mdwn |   29 +
 ..._0f2f5b58020879252d716930f2396b81._comment |   14 +
 doc/todo/support_for_storing_xattrs.mdwn      |   17 +
 ..._55c839d1b8af5150a5df29f0314e4b79._comment |   12 +
 ..._c10f87259aef110510014ba16d0792ad._comment |   26 +
 ...c___40__cp_--reflink_equivalent__41__.mdwn |    3 +
 ..._d94d813bdd6bea17347c87597788aec7._comment |   10 +
 ..._e5b9898f69fa9143519e58378ac668f8._comment |    8 +
 ..._9fd59c3ec54d54790050eb8860964783._comment |   10 +
 ..._1b23963d04c5bd53d3de09970816fad8._comment |    8 +
 ..._e506d7b173bd04ad7f32db52dcc1ea03._comment |   25 +
 ..._d812c6dbd672e3dcdeb5c87806dcef91._comment |   16 +
 ..._8fbd3cdc5a077cbd51d41db30c19a005._comment |    8 +
 ..._4580926755ee2802c80baa9f9bcc0661._comment |   10 +
 ..._bd610770eff9ef1eb68085e28c1175fa._comment |    7 +
 ..._f09b99a17d52a55e609bb3ca02db781a._comment |   32 +
 ..._f1c3cf11cddb9e5c7747e5824cd4b608._comment |   12 +
 ..._5097e4ac096d1b0b9c06c544b9217e22._comment |   19 +
 ..._via___34__built-in__34___ssh_support.mdwn |   40 +
 ..._7932fd28b14898a0b4846856a27405b8._comment |    9 +
 ..._048a8f7b52a0baf4c0abbae37de00257._comment |   10 +
 ..._04be2f010aeb792e070f1ff93435fabc._comment |   14 +
 ...sing_Stateless_OpenPGP_instead_of_gpg.mdwn |   52 +
 .../symlinks_to_symlinks_to_the_annex.mdwn    |    5 +
 ..._54bae401b8de13c9973ef5e6d2cf7e88._comment |    9 +
 ..._f5c08ecd3b0b4099186d78c85b7f1e6f._comment |   24 +
 ..._409de39da33b7ecfe5b8c7b2e866225e._comment |   28 +
 ..._818c85d1a199d40daca7371fefb18bc3._comment |    9 +
 ..._94b84cd27c36d14dc16837484d232d72._comment |    9 +
 ...d_branches___40__e.g._git-annex__41__.mdwn |    6 +
 ..._06fd59c8bdd451b5608e1e0191f4d5cb._comment |    8 +
 ..._436fd00970867a8bb0806a753ac24963._comment |   14 +
 ..._2e768899c332cacffcb1fa6edb195325._comment |   19 +
 ..._741720c1b65fff2f8ecb87abbcf16223._comment |   10 +
 ..._73bd5d343286f61c9ac753ed3b00c149._comment |   10 +
 ..._bab52f2fd4f66cac6a178cdd9ef71c6d._comment |   14 +
 ..._a765e998ffaecc2af681947263cd80d7._comment |   27 +
 ..._8f19d38c815dd3051004301a15657cf6._comment |   22 +
 ..._15e336ea35f0233e22f7c5b656b616d2._comment |   56 +
 ..._757f97ac10035ec6b28720c0570b19f0._comment |   10 +
 ..._6c683fcba5d69a4c0051eb42b8c558a0._comment |   48 +
 ..._5bef9faa4df40b84c991b9ea5e1ab7a3._comment |   36 +
 doc/todo/syncthing_special_remote.mdwn        |  110 +
 doc/todo/tahoe_lfs_for_reals.mdwn             |   23 +
 ..._0a4793ce6a867638f6e510e71dd4bb44._comment |   10 +
 ..._80b9e848edfdc7be21baab7d0cef0e3a._comment |   13 +
 doc/todo/terminal_escapes_in_filenames.mdwn   |   70 +
 doc/todo/test_suite_unsafe_use_of_setEnv.mdwn |   22 +
 ...ooked_up_3_times_for_libpcre__42__.so.mdwn |   41 +
 ..._35e85e3088c4453751ebffb7357a9f9b._comment |    8 +
 ..._61d70f4a06edaa593a17d47019be53de._comment |   27 +
 ..._89701d7011c3c9085afaab33aa16c39f._comment |   12 +
 doc/todo/timeout_support_for_importfeed.mdwn  |    7 +
 doc/todo/to_and_from_multiple_remotes.mdwn    |   69 +
 ..._2c055c3f55e0796b6842df8c2733726b._comment |    8 +
 ...____40__and_probably_copy__41___to_S3.mdwn |    8 +
 ..._42256576a4b5e8312b12e785fbc8fb1f._comment |   38 +
 ..._6b655d30bf07518f33ec42cdeabef4ef._comment |    8 +
 ..._fb3e0585f6700050db7a06e27d8e1099._comment |    7 +
 doc/todo/tor.mdwn                             |   28 +
 ...e_space_in_repos_via_git-annex_branch.mdwn |   88 +
 doc/todo/tracking_changes_to_metadata.mdwn    |   14 +
 ..._825c15ba36324aad58faf643057b256a._comment |   28 +
 ..._03a631beaa20a479f5016def7585d363._comment |   12 +
 ..._a05652472c37c463eca22f11cf6596a4._comment |   14 +
 doc/todo/transitive_transfers.mdwn            |   29 +
 ..._d244295696be5a8164db45f7fad1701a._comment |   47 +
 ..._7255f5083283b0ae7e7fc41e127bd829._comment |   26 +
 ..._e5c2ede203e7bdb5af8432df6c09268f._comment |   81 +
 ..._cb92e81c1ea00ca72f9a5ee729d627f4._comment |   11 +
 ..._50670cb52b29dc9c0c6c981e6f6d198b._comment |   15 +
 ..._ddef2f127a49c2eb8a15b5848756d888._comment |    9 +
 ..._6417ec94a5723776b6688ccbb0453ffc._comment |   10 +
 ..._7ffe073c582fc9392213ce52ba6ba398._comment |    8 +
 ..._6d5c2697bc985627199e425962f23189._comment |   13 +
 .../trust_based_on_time_since_last_fsck.mdwn  |    5 +
 ..._3805e8dd9e6dd986c097c6f1b78ab244._comment |   32 +
 ..._ec1b87b389dc06440df04c9a719e0cbc._comment |   13 +
 ..._23f37b9d8b877b829e34e6c8ea6b40c4._comment |   22 +
 ..._29729772f7600dfb459e3be9cf2c43ea._comment |   26 +
 ...r_specific_remotes_for_specified_time.mdwn |    5 +
 ..._96e12b8ecba4bacfbfa5c58025bedaab._comment |   12 +
 doc/todo/unify_adjust_with_view.mdwn          |   73 +
 doc/todo/union_mounting.mdwn                  |   10 +
 ..._cb08435812dd7766de26199c73f38e8b._comment |    8 +
 ..._240b1736f6bd4fbf87c372d3a46e661b._comment |    9 +
 ..._cf0a0d4fbd929f24f7056115b2acb7de._comment |    8 +
 ..._2f02fe00a84bf94b7c8e437d8b80293f._comment |   67 +
 ..._58c38383a7ac2df843772960fa10204f._comment |    9 +
 ..._65055977d7c8db3c9c29d90e033e5bb4._comment |   17 +
 doc/todo/universal_batch_mode.mdwn            |    4 +
 ..._83264867c7f58d92148d1585e4361ee5._comment |    8 +
 ..._c662c1e2410285e9bf6d01135851fdc8._comment |   28 +
 ..._c8232195fa3db718dc2b246d528e6c00._comment |   46 +
 doc/todo/unlikely.mdwn                        |    6 +
 doc/todo/unlock_--json.mdwn                   |   10 +
 ..._4cd41dca533de8147027eeb9a8ad89db._comment |   16 +
 ..._f00fda45d300ce14a5ea6fd32a20defe._comment |   12 +
 doc/todo/unlock_--read-only.mdwn              |    8 +
 ..._c2a1f402a28c44f842d88747fa3741cc._comment |   18 +
 ..._e8f1576e67d6368eb28aa89c30aaa34c._comment |    8 +
 ..._19da9b33836df34b7d747039e6863586._comment |   13 +
 ..._1658f775ef9340e65711512049085dd7._comment |   20 +
 ..._305c1b867c38edf74cdff1638e5b1cfa._comment |   11 +
 ..._515e21cf5c2dfbf9fd780af9cef2e726._comment |   22 +
 ..._645bccbcd3499eb552a24563cb613af2._comment |    8 +
 ..._eda5475b89536726ec29a831e2748f43._comment |   13 +
 ..._3ea1a354bb631539df1ac941e76988e1._comment |   14 +
 ..._c39e204047bd9a1999b69a433b22b16d._comment |   12 +
 ..._82a8bfe07d78fc29d306fa5545e866a7._comment |   13 +
 doc/todo/unregisterurl_KEY_URL.mdwn           |   19 +
 ..._9562b4583203b49ec68162f3a4816ad7._comment |   20 +
 ..._87ec9a2037eaa84011f7e7ecf43d31aa._comment |   13 +
 ..._22edc4e69a686511c76c7c7608da5793._comment |   20 +
 ...ge_chunks_without_buffering_in_memory.mdwn |   26 +
 ...use_git-mktree_rather_than_index_file.mdwn |   29 +
 ...tial_system_for_git-annex_credentials.mdwn |   15 +
 ..._preferred___40__wanted__41___content.mdwn |   12 +
 ..._8c377382b772e4c2d0c1f981010b8d91._comment |   17 +
 doc/todo/v11_changes.mdwn                     |   30 +
 doc/todo/v9_changes.mdwn                      |   22 +
 doc/todo/verified_relaxed_urls.mdwn           |  127 +
 ...of_breaking_changes_same_way_git_does.mdwn |   31 +
 ...t_on_how_to_decide_on_extension__63__.mdwn |   16 +
 ..._b3e9fcb09b6455301a5f7a9bf50a8a49._comment |   22 +
 ...rust_without_unncessary_branch_update.mdwn |   15 +
 .../webapp__58___show_times_of_events.mdwn    |    5 +
 ...export_remote_configuration_interface.mdwn |   12 +
 ...nudge_when_less_than_numcopies_clones.mdwn |    7 +
 ...h_locked_down_git-annex-shell_account.mdwn |    7 +
 doc/todo/wherewas.mdwn                        |   29 +
 ...hlist__58___GPG_alternatives_like_AGE.mdwn |    8 +
 ..._92a7d08946a3ed95d0f0413e6c6208ae._comment |    8 +
 ..._18ae790f59a9dbeda745e6f6f45384cb._comment |   35 +
 ..._09b89df28a3a3dab2f0fbf2f56feafe1._comment |   36 +
 ..._b9de19ba8382225ac8c65ee1ad8110a8._comment |   18 +
 ..._c81d61a221fd93eb25765998b67bbde7._comment |   32 +
 ..._991bf6846513818c00b75b7962b0fb2e._comment |   13 +
 ..._d86cf1376fbbd85e9ea63d7b7afbd1fc._comment |    8 +
 ..._d784886328bc00b2adaba2391776d2c8._comment |   13 +
 ..._18861f94b677a40c2d1c0014338231c6._comment |   22 +
 ...list__58___kde-connect_as_a_transport.mdwn |    9 +
 ..._14426ad1fa5dfc32d290da484c1e4c7b._comment |   21 +
 ...for_Win32_not_export_c__95___entities.mdwn |   57 +
 ..._40985c5919f20fd47fa57caec09bfa3c._comment |   19 +
 ..._1d9c331e774138ceb89b1f7920bb76d4._comment |   14 +
 ..._88b58dd27cbff3f046b6f8d1c612f87f._comment |   50 +
 ..._28e5593e0a58fb7d7a2a297fa63e8208._comment |    9 +
 ..._43603d84801cfe0ecfcdc408db97ae22._comment |   11 +
 ..._a623b2e131dd85f50e04483d262abc9a._comment |   26 +
 ..._91c17601eed0936bab17cdf9ec5f3ecb._comment |    7 +
 doc/todo/windows_support.mdwn                 |  136 +
 ..._394127e34e07ab3dc0e7b94ee6898866._comment |    8 +
 ..._c91eb7da8ee05064a5bc4a6e2203314b._comment |    8 +
 ..._0775dc22516cfa8c5e7deea954084947._comment |   18 +
 ..._4dfb65242280c2e28796f1ab8f022dea._comment |   13 +
 ..._a8519b722cb94f9363d4a8a8bd40e942._comment |    9 +
 ..._61d1281072de2bb418cf96fd8b563d45._comment |   10 +
 ..._6bbcf900874e950b08cdf0410f7a75d2._comment |   11 +
 ..._653b36e0838308dd85d38b05d3df5077._comment |   11 +
 ..._fbd19cd8365808daa007f44ff167c635._comment |   11 +
 ..._87e06eb2968856ce97b6162bc14203c1._comment |    9 +
 ..._3cc26ad8101a22e95a8c60cf0c4dedcc._comment |   10 +
 ..._7d83963db52d5dedd65f8cf7937dff4f._comment |   12 +
 ..._49ef5997d36ade4797ef77b1b62f5405._comment |   15 +
 ..._8e5b8ec9e6a63bcde7390511c92d2940._comment |   17 +
 ..._616a7d579730e5a4f5cc314d6328bfd0._comment |   23 +
 ..._f50de72a082476e0a2e7587368191788._comment |   11 +
 ..._5eb1a4693db88a9e05500ad66edce61d._comment |   18 +
 ..._99d0541d1c7f7c82a67d481c61209670._comment |   13 +
 ..._8acae818ce468967499050bbe3c532ea._comment |   12 +
 ..._bd0a12f4c9b884ab8a06082842381a01._comment |    8 +
 ..._ad06b98b2ddac866ffee334e41fee6a8._comment |    8 +
 ..._444fc7251f57db241b6e80abae41851c._comment |   10 +
 ..._34f1f60b570c389bb1e741b990064a7e._comment |    8 +
 ..._a5ca56c487257434650420acfa60e39f._comment |    8 +
 ..._61214de7d967740d42905f3823ce2f65._comment |   12 +
 ..._259a0b1a6f4d8d1944173380adc5e7c8._comment |    8 +
 ...8___--dry-run_option_for_all_commands.mdwn |    6 +
 ..._03bf493d5a7f957339f9aa388ba85ef8._comment |   20 +
 ..._8ac7ae6937d219854bc60b56b8646d8b._comment |    8 +
 ..._411cabdfebe353d35f8dc78364f4a507._comment |   16 +
 ..._2824eb6fd3fe9a44d48639c38d478351._comment |   17 +
 ..._e139434d88638d05c84b721abdbb406c._comment |   17 +
 ..._cd430ea90286759eb5311ef376f63929._comment |    7 +
 ..._--maxdepth_option_for_git_annex_find.mdwn |   24 +
 ..._c355878ac49bbb23a4cf82fe685da9ee._comment |   10 +
 ..._da30a066c4de465fe172ad01057e2380._comment |   10 +
 ..._f3eadd6241f5cc2886515b2826dc5cf9._comment |   10 +
 ..._c766c1465407324fc933db78be325b33._comment |   12 +
 ..._dcda795ff29de150ced0c839c85f7837._comment |   17 +
 ...ishlist__58___Add_--byte-limit_option.mdwn |   16 +
 ...ist__58___Freeing_X_space_on_remote_Y.mdwn |    5 +
 ...__Option_to_specify_max_transfer_rate.mdwn |    5 +
 ..._4fd870e14b5b70c8a6ade41406294387._comment |   10 +
 ..._dd854f297ad6a94b54be9f3edfd0f766._comment |    8 +
 ..._a8b7e90a473d5937807cc7eb456efe33._comment |   10 +
 ..._53c43e480a37b20bc8fed9d38527651b._comment |    9 +
 ..._428d638e1f41d84df7e6c51675fe65da._comment |    9 +
 ...___Parity_files_for_encrypted_remotes.mdwn |    7 +
 ..._5fbffd74f9d89857b807093cd7a5941e._comment |    9 +
 ...8___Restore_s3_files_moved_to_Glacier.mdwn |    7 +
 ..._eb934756cb2af7fa13ad3b5fad7f85b2._comment |    9 +
 ..._____39__get__39___queue_and_schedule.mdwn |   32 +
 ..._d6ab311beee2ce5f73ae325a4ae463d4._comment |   11 +
 ..._c2e9ab3ff49c22f27dd800512e7b7961._comment |   10 +
 ...__whereis__39___support_in_the_webapp.mdwn |    4 +
 ...___96__git_annex_drop_--relaxed__96__.mdwn |    5 +
 ..._c83a6cddd0ce222205a149cfa41ca395._comment |   10 +
 ..._353fbc2bcc40cb8c9af42907a34c6e5a._comment |   11 +
 ..._3e830035df580601f038ce3a7003c39d._comment |   63 +
 ..._e5516689bc128c061dcd66649dc69584._comment |   10 +
 ..._be740e4b06d9130ae6afc5783da3c0e0._comment |   14 +
 ..._79d115f95cec46bb51e7fba078524db1._comment |   17 +
 ...__58_____96__git_annex_optimize__96__.mdwn |   12 +
 ...t__58___allow_custom_S3_url_in_webapp.mdwn |    3 +
 ..._3d1ea5579a6ad0c0efde58dca11c10aa._comment |   10 +
 ..._f96bb81fde4185368dc6ea5a5aed87da._comment |   10 +
 ...tracking_the_sources_of_the_downloads.mdwn |    1 +
 ..._36ae3c75053d5ec278b5e6eb2084d57a._comment |    8 +
 ..._be8eb800523db8cf7a2c68a28fbf5ea5._comment |    8 +
 ..._d9f725de41a8572c85e4c6d9b4bcc927._comment |    8 +
 ..._f52492e4cc6f965515800bd1c0e05c90._comment |   10 +
 ..._5b36656fc5fa124e763f06711d9da32b._comment |   10 +
 ..._285215a4466806baf85b8606f680494a._comment |   12 +
 ..._15bf62e46db4b84ed3156f550f03de42._comment |   12 +
 ...iles_configuration_in_webapp_and_sync.mdwn |    4 +
 ..._db632de391ce9fce42af51a770ed3aeb._comment |   10 +
 ..._4a0931d9884054d764fde315d4fe4851._comment |   14 +
 ...from_remote_with_the_least_free_space.mdwn |    1 +
 ..._6813fdc7ecc98765a5d35d34163a1712._comment |    8 +
 ..._21a249cedca1ceb80d10784004735524._comment |    8 +
 ...__58___assistant_logging_improvements.mdwn |    3 +
 ..._683e2e3c94345cb6f35028cd130a4dcc._comment |    8 +
 ...ishlist__58___derived_content_support.mdwn |    8 +
 ...hlist__58___disable_automatic_commits.mdwn |   37 +
 ..._3f76bc558b59f90d0276be8cd24c6797._comment |   25 +
 ..._a031373f7251b5395100bcfc57519049._comment |   11 +
 ..._53b1321d5bcaf4139f9fbbd17f26fe75._comment |   17 +
 ..._e021de3647a00aa0259a247441de50eb._comment |    8 +
 ..._701ef8d7bca858150bc0ae070d21755d._comment |   15 +
 ..._195815446f3ec78901c1ddd245b86c4c._comment |   37 +
 ...splay_status_of_remotes_in_the_webapp.mdwn |    1 +
 ...it_remote_on_hosting_site_from_webapp.mdwn |    1 +
 ...list__58___generic_annex.cost-command.mdwn |   17 +
 ..._b2060ec194e3ae53bd286f2bae799984._comment |   14 +
 ...wishlist__58___global_progress_status.mdwn |    3 +
 ..._d915dce144071f768ee9bcdead07a0e5._comment |    9 +
 ..._816f41f5436543fc09e7d7df82a8c8d5._comment |    9 +
 ..._587e8befa0e52d8880362a32799df492._comment |   14 +
 ..._60b7597af2b86ce6bcb31731f6d8c54e._comment |   26 +
 .../wishlist__58___history_of_operations.mdwn |    8 +
 ..._f9a77ce83c6f39b6272d5c577ffbb9f9._comment |    8 +
 ...t__58___matching_options_for_branches.mdwn |    1 +
 ..._c0d442b646dc40d870b10098a0ee5408._comment |   20 +
 ...o_the_end_of_the_queue_when_one_fails.mdwn |    7 +
 ..._82ee9de610a0ac55cd1c27c211079e5b._comment |   10 +
 ..._bea55156bd32cf9e6dd9b946ba1bb8c1._comment |   10 +
 ..._output_of_checkpresentkey_batch_mode.mdwn |    3 +
 ..._f95f2c92a46c1bd00c627aa19b08c875._comment |   13 +
 ..._bb756ddf06c52ca52d73af319f0265b0._comment |   14 +
 .../wishlist__58___perform_fsck_remotely.mdwn |   39 +
 ..._db92311dcdb1ef0ab0413f83e191c70c._comment |   15 +
 ..._2f0dbaf143d94290bfbebb6869eb7241._comment |   12 +
 ..._5ec2e0e248dfd4ca46aef89cc5658d18._comment |    8 +
 ...ew_hashing_scheme_in_non-bare_remotes.mdwn |    8 +
 ...ve_directory_remote_setup__47__addurl.mdwn |   10 +
 ..._b79976afc2242791523e63831f30af71._comment |   12 +
 ..._1741d2392006a9af9cfd1f3b847600b9._comment |    9 +
 ..._b6fb39030f98bbc9915712e3d35d1838._comment |    9 +
 ...58___traffic_accounting_for_git-annex.mdwn |    3 +
 ..._unify_directory_scheme_for_the_store.mdwn |   20 +
 ..._44da58beaaab359ecaba7fb905ca4ae1._comment |   10 +
 ..._bc698c501ecdb56df57171f4f3bb831a._comment |   16 +
 ..._e555d0dbbaa05528806905c6a940724b._comment |    8 +
 ...git-annex-__123__copy__44__get__125__.mdwn |    5 +
 ..._bbbb9c4c71b8c56eaf134b794d2345c3._comment |    8 +
 ..._1eb09a234616cb0df7fed9016827dd0c._comment |    8 +
 ..._942c2decd6dda0730e2efe4ed6e6cd16._comment |   22 +
 ..._stamps_to_annex_log_popups_in_webapp.mdwn |    1 +
 ..._ec90432a7d46383071401b05243d621f._comment |    8 +
 doc/todo/wishlist_degraded_files.mdwn         |    5 +
 .../withExclusiveLock_blocking_issue.mdwn     |   83 +
 doc/todo/worktree_overwrite_races.mdwn        |   45 +
 ...r__41_____34__Video_unavailable__34__.mdwn |   94 +
 ..._8b761cfc9b2ca784efc15b39689c31f5._comment |   20 +
 doc/transferring_data.mdwn                    |   19 +
 doc/trust.mdwn                                |   65 +
 ..._305e4e7c6b75db29212b758e8504d8c9._comment |   10 +
 ..._2262eaa830306d3dc75999bc0433b6a8._comment |    8 +
 doc/tuning.mdwn                               |   47 +
 ..._f8af8e9b696d32d238ebd56a3b8058c4._comment |   17 +
 ..._a0091dbb39b79dfe101d05f9a5db216f._comment |   12 +
 ..._1c576f9a5e0a0b5d7d8edf9d40462874._comment |   10 +
 ..._5b782975263480a405c5e8dcfe058007._comment |   17 +
 ..._0143b798e75ad25c5917794a49a879fb._comment |   13 +
 doc/upgrades.mdwn                             |  179 +
 doc/upgrades/SHA_size.mdwn                    |   20 +
 ..._20f9b7b75786075de666b2146dc13a60._comment |   12 +
 doc/upgrades/gcrypt.mdwn                      |   25 +
 ..._606c1527735996ae671f78948e4ad84b._comment |    8 +
 doc/upgrades/insecure_embedded_creds.mdwn     |   42 +
 doc/use_case/Alice.mdwn                       |   24 +
 doc/use_case/Bob.mdwn                         |   25 +
 doc/users.mdwn                                |    9 +
 doc/users/Ilya__95__Shlyakhter.mdwn           |    1 +
 doc/users/anarcat.mdwn                        |   55 +
 doc/users/andrew.mdwn                         |    4 +
 doc/users/ben.mdwn                            |    1 +
 doc/users/chris.mdwn                          |    1 +
 doc/users/chrysn.mdwn                         |   11 +
 doc/users/clacke.mdwn                         |    3 +
 doc/users/claes.wallin.mdwn                   |    1 +
 doc/users/dandi.mdwn                          |    1 +
 doc/users/datalad.mdwn                        |    1 +
 doc/users/dave.mdwn                           |    1 +
 doc/users/dckc.mdwn                           |    1 +
 doc/users/falsifian.mdwn                      |    1 +
 doc/users/fmarier.mdwn                        |    6 +
 doc/users/frederik.mdwn                       |    1 +
 doc/users/gebi.mdwn                           |    1 +
 doc/users/greg.mdwn                           |    3 +
 doc/users/james.mdwn                          |    1 +
 doc/users/jgoerzen.mdwn                       |    1 +
 doc/users/jkniiv.mdwn                         |   10 +
 doc/users/joey.mdwn                           |    2 +
 ..._0ccf207fd817f9b5555aad030bd4957f._comment |   17 +
 ..._7e0b8d499d2bededf01591a7c5686f8f._comment |    9 +
 doc/users/kolam.mdwn                          |    1 +
 doc/users/mih.mdwn                            |   23 +
 doc/users/nobodyinperson.mdwn                 |   13 +
 doc/users/parhuzamos.mdwn                     |    8 +
 doc/users/petersjt014.mdwn                    |    1 +
 doc/users/ptilopteri.mdwn                     |    1 +
 doc/users/sameerds.mdwn                       |    3 +
 doc/users/thk.mdwn                            |   26 +
 doc/users/timothe.mdwn                        |    5 +
 doc/users/tobiastheviking.mdwn                |   13 +
 doc/users/unqueued.mdwn                       |    7 +
 doc/users/wzhd.mdwn                           |    1 +
 doc/users/yarikoptic.mdwn                     |   15 +
 doc/users/yoh.mdwn                            |   23 +
 doc/videos.mdwn                               |    8 +
 doc/videos/FOSDEM2012.mdwn                    |    7 +
 doc/videos/LCA2013.mdwn                       |    8 +
 doc/videos/git-annex_assistant_archiving.mdwn |    5 +
 .../git-annex_assistant_introduction.mdwn     |    5 +
 ..._f42ad4183c2c28319d3705a82fceb82f._comment |   15 +
 ..._b62f4eeeac1138570f7cb8c98d41c2cb._comment |   12 +
 doc/videos/git-annex_assistant_lan.mdwn       |    6 +
 ..._df8c8b6d9d63fbf5462b225edbb23c82._comment |    8 +
 ..._d4e3122da9c9e27fbe872e09fcde762b._comment |   10 +
 ..._d43ee0a335c2f010b437cf28437455c2._comment |    8 +
 ..._c710e27db41311b157d8caaafc32dc7e._comment |    8 +
 doc/videos/git-annex_assistant_sync_demo.mdwn |    8 +
 doc/videos/git-annex_views_demo.mdwn          |   11 +
 doc/videos/git-annex_watch_demo.mdwn          |    7 +
 doc/videos/git-annex_weppapp_demo.mdwn        |    8 +
 doc/videos/tuebix.mdwn                        |   11 +
 doc/walkthrough.mdwn                          |   32 +
 doc/walkthrough/adding_a_remote.mdwn          |   22 +
 ..._0a59355bd33a796aec97173607e6adc9._comment |    8 +
 ..._f8cd79ef1593a8181a7f1086a87713e8._comment |    9 +
 ..._60691af4400521b5a8c8d75efe3b44cb._comment |    9 +
 ..._6f7cf5c330272c96b3abeb6612075c9d._comment |   10 +
 ..._bcbe480aa710ce693ee03d86884f1820._comment |   10 +
 ..._15ea28114e69dddac82fddaf009079ca._comment |    9 +
 ..._caea7e4e9ec904617c6ec1a33368090f._comment |   16 +
 doc/walkthrough/adding_files.mdwn             |   11 +
 .../automatically_managing_content.mdwn       |   45 +
 doc/walkthrough/backups.mdwn                  |   27 +
 ..._d0244791d2abbf29553546a6a6568a0f._comment |   10 +
 doc/walkthrough/creating_a_repository.mdwn    |    6 +
 .../fsck__58___verifying_your_data.mdwn       |   36 +
 .../fsck__58___when_things_go_wrong.mdwn      |   13 +
 doc/walkthrough/getting_file_content.mdwn     |   12 +
 doc/walkthrough/modifying_annexed_files.mdwn  |   31 +
 ..._624b4a0b521b553d68ab6049f7dbaf8c._comment |   14 +
 ..._b000622304535d32b69db17d51156b21._comment |   10 +
 doc/walkthrough/more.mdwn                     |    3 +
 ...ing_file_content_between_repositories.mdwn |   13 +
 ..._4c30ade91fc7113a95960aa3bd1d5427._comment |   19 +
 ..._7d90e1e150e7524ba31687108fcc38d6._comment |   10 +
 ..._558d80384434207b9cfc033763863de3._comment |   12 +
 ..._a2f343eceed9e9fba1670f21e0fc6af4._comment |    8 +
 ...___When_git-annex_seems_to_skip_files.mdwn |   27 +
 doc/walkthrough/removing_files.mdwn           |   17 +
 ..._cb65e7c510b75be1c51f655b058667c6._comment |    8 +
 ..._64709ea4558915edd5c8ca4486965b07._comment |    8 +
 ..._91e995867a731325dfdf3331f69a238c._comment |    8 +
 ..._9b575f7f2b67b36599890dd5455dcf47._comment |    9 +
 ...ving_files__58___When_things_go_wrong.mdwn |   24 +
 doc/walkthrough/renaming_files.mdwn           |   13 +
 ..._c05f70079c265d23e882f92aaa4d28f8._comment |   31 +
 ..._fe83c600e080131b3109fe616940a25e._comment |    9 +
 ..._6b579a4f2990a28b33a8170ebd39da5c._comment |   15 +
 ..._1cf4cb6be73223755cb611ec097d1498._comment |   12 +
 ..._bc3e37868b276c52a51586641cdb92ae._comment |   13 +
 ..._2ae2cc3dba5db4d4354a5b49c490272e._comment |   32 +
 doc/walkthrough/syncing.mdwn                  |   32 +
 ...ring_files__58___When_things_go_wrong.mdwn |   17 +
 doc/walkthrough/unused_data.mdwn              |   35 +
 ..._684b7b652d3a8ec04f32129c5528f1ab._comment |   22 +
 ..._e2ccd9a209c7a104004e998135d4b675._comment |   13 +
 ..._5f973eb7c265015fcd400b6b0bbdf235._comment |   10 +
 ..._2110ed6316b6a0df4ef3e1c8bc97ab99._comment |   11 +
 ..._46acb9fbbd5ef19f65115723888f3eb6._comment |   14 +
 doc/walkthrough/using_bup.mdwn                |   37 +
 doc/walkthrough/using_ddar.mdwn               |   32 +
 doc/walkthrough/using_special_remotes.mdwn    |   53 +
 doc/walkthrough/using_ssh_remotes.mdwn        |   36 +
 ..._98e97c4d7fbbcd449eddf683967a71d6._comment |    8 +
 ..._f2775a151ed50caba27057bd9c38bae2._comment |   13 +
 ..._a8bc6110128431ca2a8624ddc75ea364._comment |   10 +
 ..._365db5820d96d5daa62c19fd76fcdf1e._comment |   13 +
 ..._451fd0c6a25ee61ef137e8e5be0c286b._comment |   16 +
 ..._b2f15a46620385da26d5fe8f11ebfc1a._comment |   15 +
 ..._433ccc87fbb0a13e32d59d77f0b4e56c._comment |    8 +
 ..._a9805c7965da0b88a1c9f7f207c450a1._comment |   18 +
 ..._9d5c12c056892b706cf100ea01866685._comment |   12 +
 ..._725e7dbb2d0a74a035127cb01ee0442c._comment |   16 +
 ..._8448e55026d2c2b50d8da41707686bea._comment |   16 +
 ..._61833299a9878f23ac57598fa6da8839._comment |   23 +
 doc/walkthrough/using_tags_and_branches.mdwn  |   14 +
 doc/workflow.mdwn                             |  102 +
 ..._e4b2199944c3a248562bddf3cf9e2829._comment |   17 +
 ..._67edac29c0e7b5a768511a0fd0878947._comment |   10 +
 git-annex.cabal                               | 1101 ++
 git-annex.hs                                  |   56 +
 git-union-merge.hs                            |   50 +
 stack-lts-18.13.yaml                          |   28 +
 stack.yaml                                    |   17 +
 standalone/licences.gz                        |  Bin 0 -> 58148 bytes
 standalone/linux/skel/README                  |   20 +
 standalone/linux/skel/git                     |   24 +
 standalone/linux/skel/git-annex               |   24 +
 standalone/linux/skel/git-annex-shell         |   24 +
 standalone/linux/skel/git-annex-webapp        |   24 +
 standalone/linux/skel/git-receive-pack        |   24 +
 standalone/linux/skel/git-shell               |   24 +
 standalone/linux/skel/git-upload-pack         |   24 +
 standalone/linux/skel/runshell                |  274 +
 standalone/linux/stack-i386ancient.yaml       |   44 +
 standalone/osx/Info.plist.template            |   41 +
 .../osx/git-annex.app/Contents/MacOS/README   |    9 +
 .../osx/git-annex.app/Contents/MacOS/git      |   31 +
 .../git-annex.app/Contents/MacOS/git-annex    |   31 +
 .../Contents/MacOS/git-annex-shell            |   31 +
 .../Contents/MacOS/git-annex-webapp           |   32 +
 .../Contents/MacOS/git-receive-pack           |   31 +
 .../git-annex.app/Contents/MacOS/git-shell    |   31 +
 .../Contents/MacOS/git-upload-pack            |   31 +
 .../osx/git-annex.app/Contents/MacOS/runshell |  104 +
 .../Contents/Resources/git-annex.icns         |  Bin 0 -> 77548 bytes
 standalone/rpm/git-annex-standalone.spec      |   44 +
 .../rpm/rpmbuild-from-standalone-tarball      |   38 +
 standalone/trustedkeys.gpg                    |  Bin 0 -> 4979 bytes
 static/activityicon.gif                       |  Bin 0 -> 529 bytes
 static/css/bootstrap-theme.css                |  347 +
 static/css/bootstrap.css                      | 5785 +++++++++++
 static/favicon.ico                            |  Bin 0 -> 2550 bytes
 static/fonts/glyphicons-halflings-regular.eot |  Bin 0 -> 20335 bytes
 static/fonts/glyphicons-halflings-regular.svg |  229 +
 static/fonts/glyphicons-halflings-regular.ttf |  Bin 0 -> 41280 bytes
 .../fonts/glyphicons-halflings-regular.woff   |  Bin 0 -> 23320 bytes
 static/js/bootstrap.js                        | 1951 ++++
 static/js/jquery.full.js                      | 9111 +++++++++++++++++
 static/js/jquery.ui.core.js                   |  320 +
 static/js/jquery.ui.mouse.js                  |  169 +
 static/js/jquery.ui.sortable.js               | 1289 +++
 static/js/jquery.ui.widget.js                 |  521 +
 static/js/longpolling.js                      |   46 +
 static/syncicon.gif                           |  Bin 0 -> 847 bytes
 templates/README                              |    7 +
 templates/actionbutton.hamlet                 |    3 +
 templates/bootstrap.hamlet                    |   14 +
 templates/configurators/adddrive.hamlet       |   36 +
 .../configurators/adddrive/combine.hamlet     |   22 +
 .../configurators/adddrive/encrypt.hamlet     |   29 +
 .../configurators/adddrive/setupmodal.hamlet  |    9 +
 templates/configurators/addglacier.hamlet     |   38 +
 templates/configurators/addia.hamlet          |   36 +
 templates/configurators/addrepository.hamlet  |   19 +
 .../addrepository/archive.hamlet              |   13 +
 .../configurators/addrepository/cloud.hamlet  |   17 +
 .../addrepository/connection.hamlet           |    3 +
 .../configurators/addrepository/misc.hamlet   |   26 +
 .../configurators/addrepository/ssh.hamlet    |    7 +
 .../addrepository/wormholepairing.hamlet      |   13 +
 templates/configurators/adds3.hamlet          |   33 +
 .../delete/currentrepository.hamlet           |   36 +
 .../configurators/delete/finished.hamlet      |   15 +
 templates/configurators/delete/start.hamlet   |   13 +
 .../configurators/edit/nonannexremote.hamlet  |   19 +
 .../configurators/edit/repository.hamlet      |   40 +
 .../configurators/edit/webrepository.hamlet   |    8 +
 templates/configurators/enableaws.hamlet      |   34 +
 .../configurators/enabledirectory.hamlet      |   11 +
 templates/configurators/enableia.hamlet       |   26 +
 templates/configurators/enablewebdav.hamlet   |   26 +
 templates/configurators/fsck.cassius          |    4 +
 templates/configurators/fsck.hamlet           |   32 +
 templates/configurators/fsck/form.hamlet      |    2 +
 .../configurators/fsck/formcontent.hamlet     |   21 +
 .../configurators/fsck/preferencesform.hamlet |    7 +
 templates/configurators/fsck/status.hamlet    |    5 +
 templates/configurators/genkeymodal.hamlet    |   15 +
 templates/configurators/main.hamlet           |   29 +
 templates/configurators/needconnection.hamlet |   14 +
 templates/configurators/needgcrypt.hamlet     |   11 +
 templates/configurators/needglaciercli.hamlet |   11 +
 .../configurators/needmagicwormhole.hamlet    |   11 +
 templates/configurators/needtor.hamlet        |   11 +
 templates/configurators/newrepository.hamlet  |   14 +
 .../newrepository/combine.hamlet              |   20 +
 .../configurators/newrepository/first.hamlet  |   21 +
 .../configurators/newrepository/form.hamlet   |   13 +
 .../configurators/pairing/disabled.hamlet     |    6 +
 .../pairing/local/inprogress.hamlet           |   19 +
 .../configurators/pairing/local/prompt.hamlet |   53 +
 .../pairing/wormhole/prompt.hamlet            |   59 +
 .../pairing/wormhole/start.hamlet             |   35 +
 templates/configurators/preferences.hamlet    |   16 +
 templates/configurators/rsync.net/add.hamlet  |   43 +
 .../configurators/rsync.net/encrypt.hamlet    |   49 +
 templates/configurators/ssh/add.hamlet        |   26 +
 templates/configurators/ssh/combine.hamlet    |   22 +
 templates/configurators/ssh/confirm.hamlet    |   74 +
 templates/configurators/ssh/enable.hamlet     |   28 +
 templates/configurators/ssh/error.hamlet      |   13 +
 .../configurators/ssh/expiredpassword.hamlet  |   12 +
 templates/configurators/ssh/setupmodal.hamlet |   13 +
 templates/configurators/ssh/testmodal.hamlet  |    9 +
 templates/configurators/unused.hamlet         |   42 +
 templates/configurators/unused/form.hamlet    |    6 +
 templates/control/log.hamlet                  |    7 +
 templates/control/notrunning.hamlet           |   13 +
 templates/control/notrunning.julius           |    3 +
 templates/control/repairrepository.hamlet     |   29 +
 .../control/repairrepository/done.hamlet      |   14 +
 templates/control/repositoryswitcher.hamlet   |   15 +
 templates/control/shutdown.hamlet             |   10 +
 templates/controlmenu.hamlet                  |   22 +
 templates/dashboard/main.hamlet               |   11 +
 templates/dashboard/metarefresh.hamlet        |    2 +
 templates/dashboard/transfers.cassius         |    8 +
 templates/dashboard/transfers.hamlet          |   40 +
 templates/documentation/about.hamlet          |   35 +
 templates/documentation/license.hamlet        |    2 +
 templates/documentation/repogroup.hamlet      |   61 +
 templates/error.cassius                       |    3 +
 templates/error.hamlet                        |   31 +
 templates/notifications/longpolling.julius    |   11 +
 templates/page.cassius                        |   34 +
 templates/page.hamlet                         |   29 +
 templates/page.julius                         |   22 +
 templates/repolist.hamlet                     |   84 +
 templates/repolist.julius                     |   28 +
 templates/sidebar/alert.hamlet                |   27 +
 templates/sidebar/main.hamlet                 |    3 +
 14843 files changed, 450445 insertions(+)
 create mode 100644 .appveyor.yml
 create mode 100644 .codespellrc
 create mode 100644 .ghci
 create mode 100644 .gitattributes
 create mode 100644 .gitignore
 create mode 100644 .mailmap
 create mode 100644 Annex.hs
 create mode 100644 Annex/Action.hs
 create mode 100644 Annex/AdjustedBranch.hs
 create mode 100644 Annex/AdjustedBranch/Merge.hs
 create mode 100644 Annex/AdjustedBranch/Name.hs
 create mode 100644 Annex/AutoMerge.hs
 create mode 100644 Annex/BloomFilter.hs
 create mode 100644 Annex/Branch.hs
 create mode 100644 Annex/Branch/Transitions.hs
 create mode 100644 Annex/BranchState.hs
 create mode 100644 Annex/CatFile.hs
 create mode 100644 Annex/ChangedRefs.hs
 create mode 100644 Annex/CheckAttr.hs
 create mode 100644 Annex/CheckIgnore.hs
 create mode 100644 Annex/Common.hs
 create mode 100644 Annex/Concurrent.hs
 create mode 100644 Annex/Concurrent/Utility.hs
 create mode 100644 Annex/Content.hs
 create mode 100644 Annex/Content/LowLevel.hs
 create mode 100644 Annex/Content/PointerFile.hs
 create mode 100644 Annex/Content/Presence.hs
 create mode 100644 Annex/Content/Presence/LowLevel.hs
 create mode 100644 Annex/CopyFile.hs
 create mode 100644 Annex/CurrentBranch.hs
 create mode 100644 Annex/Debug.hs
 create mode 100644 Annex/Debug/Utility.hs
 create mode 100644 Annex/Difference.hs
 create mode 100644 Annex/DirHashes.hs
 create mode 100644 Annex/Drop.hs
 create mode 100644 Annex/Environment.hs
 create mode 100644 Annex/Export.hs
 create mode 100644 Annex/ExternalAddonProcess.hs
 create mode 100644 Annex/FileMatcher.hs
 create mode 100644 Annex/Fixup.hs
 create mode 100644 Annex/GitOverlay.hs
 create mode 100644 Annex/HashObject.hs
 create mode 100644 Annex/Hook.hs
 create mode 100644 Annex/Import.hs
 create mode 100644 Annex/Ingest.hs
 create mode 100644 Annex/Init.hs
 create mode 100644 Annex/InodeSentinal.hs
 create mode 100644 Annex/Journal.hs
 create mode 100644 Annex/Link.hs
 create mode 100644 Annex/Locations.hs
 create mode 100644 Annex/LockFile.hs
 create mode 100644 Annex/LockPool.hs
 create mode 100644 Annex/LockPool/PosixOrPid.hs
 create mode 100644 Annex/Magic.hs
 create mode 100644 Annex/MetaData.hs
 create mode 100644 Annex/MetaData/StandardFields.hs
 create mode 100644 Annex/Multicast.hs
 create mode 100644 Annex/Notification.hs
 create mode 100644 Annex/NumCopies.hs
 create mode 100644 Annex/Path.hs
 create mode 100644 Annex/Perms.hs
 create mode 100644 Annex/PidLock.hs
 create mode 100644 Annex/Queue.hs
 create mode 100644 Annex/RemoteTrackingBranch.hs
 create mode 100644 Annex/ReplaceFile.hs
 create mode 100644 Annex/SpecialRemote.hs
 create mode 100644 Annex/SpecialRemote/Config.hs
 create mode 100644 Annex/Ssh.hs
 create mode 100644 Annex/StallDetection.hs
 create mode 100644 Annex/TaggedPush.hs
 create mode 100644 Annex/Tmp.hs
 create mode 100644 Annex/Transfer.hs
 create mode 100644 Annex/TransferrerPool.hs
 create mode 100644 Annex/UUID.hs
 create mode 100644 Annex/UntrustedFilePath.hs
 create mode 100644 Annex/UpdateInstead.hs
 create mode 100644 Annex/Url.hs
 create mode 100644 Annex/VariantFile.hs
 create mode 100644 Annex/VectorClock.hs
 create mode 100644 Annex/VectorClock/Utility.hs
 create mode 100644 Annex/Verify.hs
 create mode 100644 Annex/Version.hs
 create mode 100644 Annex/View.hs
 create mode 100644 Annex/View/ViewedFile.hs
 create mode 100644 Annex/Wanted.hs
 create mode 100644 Annex/WorkTree.hs
 create mode 100644 Annex/WorkerPool.hs
 create mode 100644 Annex/YoutubeDl.hs
 create mode 100644 Assistant.hs
 create mode 100644 Assistant/Alert.hs
 create mode 100644 Assistant/Alert/Utility.hs
 create mode 100644 Assistant/BranchChange.hs
 create mode 100644 Assistant/Changes.hs
 create mode 100644 Assistant/Commits.hs
 create mode 100644 Assistant/Common.hs
 create mode 100644 Assistant/CredPairCache.hs
 create mode 100644 Assistant/DaemonStatus.hs
 create mode 100644 Assistant/DeleteRemote.hs
 create mode 100644 Assistant/Drop.hs
 create mode 100644 Assistant/Fsck.hs
 create mode 100644 Assistant/Gpg.hs
 create mode 100644 Assistant/Install.hs
 create mode 100644 Assistant/Install/AutoStart.hs
 create mode 100644 Assistant/Install/Menu.hs
 create mode 100644 Assistant/MakeRemote.hs
 create mode 100644 Assistant/MakeRepo.hs
 create mode 100644 Assistant/Monad.hs
 create mode 100644 Assistant/NamedThread.hs
 create mode 100644 Assistant/Pairing.hs
 create mode 100644 Assistant/Pairing/MakeRemote.hs
 create mode 100644 Assistant/Pairing/Network.hs
 create mode 100644 Assistant/Pushes.hs
 create mode 100644 Assistant/RemoteControl.hs
 create mode 100644 Assistant/Repair.hs
 create mode 100644 Assistant/RepoProblem.hs
 create mode 100644 Assistant/Restart.hs
 create mode 100644 Assistant/ScanRemotes.hs
 create mode 100644 Assistant/Ssh.hs
 create mode 100644 Assistant/Sync.hs
 create mode 100644 Assistant/Threads/Committer.hs
 create mode 100644 Assistant/Threads/ConfigMonitor.hs
 create mode 100644 Assistant/Threads/Cronner.hs
 create mode 100644 Assistant/Threads/DaemonStatus.hs
 create mode 100644 Assistant/Threads/Exporter.hs
 create mode 100644 Assistant/Threads/Glacier.hs
 create mode 100644 Assistant/Threads/Merger.hs
 create mode 100644 Assistant/Threads/MountWatcher.hs
 create mode 100644 Assistant/Threads/NetWatcher.hs
 create mode 100644 Assistant/Threads/PairListener.hs
 create mode 100644 Assistant/Threads/ProblemFixer.hs
 create mode 100644 Assistant/Threads/Pusher.hs
 create mode 100644 Assistant/Threads/RemoteControl.hs
 create mode 100644 Assistant/Threads/SanityChecker.hs
 create mode 100644 Assistant/Threads/TransferPoller.hs
 create mode 100644 Assistant/Threads/TransferScanner.hs
 create mode 100644 Assistant/Threads/TransferWatcher.hs
 create mode 100644 Assistant/Threads/Transferrer.hs
 create mode 100644 Assistant/Threads/UpgradeWatcher.hs
 create mode 100644 Assistant/Threads/Upgrader.hs
 create mode 100644 Assistant/Threads/Watcher.hs
 create mode 100644 Assistant/Threads/WebApp.hs
 create mode 100644 Assistant/TransferQueue.hs
 create mode 100644 Assistant/TransferSlots.hs
 create mode 100644 Assistant/Types/Alert.hs
 create mode 100644 Assistant/Types/BranchChange.hs
 create mode 100644 Assistant/Types/Changes.hs
 create mode 100644 Assistant/Types/Commits.hs
 create mode 100644 Assistant/Types/CredPairCache.hs
 create mode 100644 Assistant/Types/DaemonStatus.hs
 create mode 100644 Assistant/Types/NamedThread.hs
 create mode 100644 Assistant/Types/Pushes.hs
 create mode 100644 Assistant/Types/RemoteControl.hs
 create mode 100644 Assistant/Types/RepoProblem.hs
 create mode 100644 Assistant/Types/ScanRemotes.hs
 create mode 100644 Assistant/Types/ThreadName.hs
 create mode 100644 Assistant/Types/ThreadedMonad.hs
 create mode 100644 Assistant/Types/TransferQueue.hs
 create mode 100644 Assistant/Types/TransferSlots.hs
 create mode 100644 Assistant/Types/UrlRenderer.hs
 create mode 100644 Assistant/Unused.hs
 create mode 100644 Assistant/Upgrade.hs
 create mode 100644 Assistant/WebApp.hs
 create mode 100644 Assistant/WebApp/Common.hs
 create mode 100644 Assistant/WebApp/Configurators.hs
 create mode 100644 Assistant/WebApp/Configurators/AWS.hs
 create mode 100644 Assistant/WebApp/Configurators/Delete.hs
 create mode 100644 Assistant/WebApp/Configurators/Edit.hs
 create mode 100644 Assistant/WebApp/Configurators/Fsck.hs
 create mode 100644 Assistant/WebApp/Configurators/IA.hs
 create mode 100644 Assistant/WebApp/Configurators/Local.hs
 create mode 100644 Assistant/WebApp/Configurators/Pairing.hs
 create mode 100644 Assistant/WebApp/Configurators/Preferences.hs
 create mode 100644 Assistant/WebApp/Configurators/Ssh.hs
 create mode 100644 Assistant/WebApp/Configurators/Unused.hs
 create mode 100644 Assistant/WebApp/Configurators/Upgrade.hs
 create mode 100644 Assistant/WebApp/Configurators/WebDAV.hs
 create mode 100644 Assistant/WebApp/Control.hs
 create mode 100644 Assistant/WebApp/DashBoard.hs
 create mode 100644 Assistant/WebApp/Documentation.hs
 create mode 100644 Assistant/WebApp/Form.hs
 create mode 100644 Assistant/WebApp/Gpg.hs
 create mode 100644 Assistant/WebApp/MakeRemote.hs
 create mode 100644 Assistant/WebApp/Notifications.hs
 create mode 100644 Assistant/WebApp/OtherRepos.hs
 create mode 100644 Assistant/WebApp/Page.hs
 create mode 100644 Assistant/WebApp/Pairing.hs
 create mode 100644 Assistant/WebApp/Repair.hs
 create mode 100644 Assistant/WebApp/RepoId.hs
 create mode 100644 Assistant/WebApp/RepoList.hs
 create mode 100644 Assistant/WebApp/SideBar.hs
 create mode 100644 Assistant/WebApp/Types.hs
 create mode 100644 Assistant/WebApp/routes
 create mode 100644 Author.hs
 create mode 100644 Backend.hs
 create mode 100644 Backend/External.hs
 create mode 100644 Backend/Hash.hs
 create mode 100644 Backend/URL.hs
 create mode 100644 Backend/Utilities.hs
 create mode 100644 Backend/VURL.hs
 create mode 100644 Backend/VURL/Utilities.hs
 create mode 100644 Backend/Variety.hs
 create mode 100644 Backend/WORM.hs
 create mode 100644 Benchmark.hs
 create mode 100644 Build/BuildVersion.hs
 create mode 100644 Build/BundledPrograms.hs
 create mode 100644 Build/Configure.hs
 create mode 100644 Build/DesktopFile.hs
 create mode 100644 Build/DistributionUpdate.hs
 create mode 100644 Build/InstallDesktopFile.hs
 create mode 100644 Build/LinuxMkLibs.hs
 create mode 100644 Build/MakeMans.hs
 create mode 100644 Build/Mans.hs
 create mode 100644 Build/NullSoftInstaller.hs
 create mode 100644 Build/OSXMkLibs.hs
 create mode 100644 Build/Standalone.hs
 create mode 100644 Build/TestConfig.hs
 create mode 100644 Build/Version.hs
 create mode 100755 Build/collect-ghc-options.sh
 create mode 100755 Build/mdwn2man
 create mode 100644 BuildFlags.hs
 create mode 100644 BuildInfo.hs
 create mode 100644 CHANGELOG
 create mode 100644 COPYRIGHT
 create mode 100644 CmdLine.hs
 create mode 100644 CmdLine/Action.hs
 create mode 100644 CmdLine/AnnexSetter.hs
 create mode 100644 CmdLine/Batch.hs
 create mode 100644 CmdLine/GitAnnex.hs
 create mode 100644 CmdLine/GitAnnex/Options.hs
 create mode 100644 CmdLine/GitAnnexShell.hs
 create mode 100644 CmdLine/GitAnnexShell/Checks.hs
 create mode 100644 CmdLine/GitAnnexShell/Fields.hs
 create mode 100644 CmdLine/GitRemoteTorAnnex.hs
 create mode 100644 CmdLine/Option.hs
 create mode 100644 CmdLine/Seek.hs
 create mode 100644 CmdLine/Usage.hs
 create mode 100644 Command.hs
 create mode 100644 Command/Add.hs
 create mode 100644 Command/AddUnused.hs
 create mode 100644 Command/AddUrl.hs
 create mode 100644 Command/Adjust.hs
 create mode 100644 Command/Assist.hs
 create mode 100644 Command/Assistant.hs
 create mode 100644 Command/Benchmark.hs
 create mode 100644 Command/CalcKey.hs
 create mode 100644 Command/CheckPresentKey.hs
 create mode 100644 Command/Config.hs
 create mode 100644 Command/ConfigList.hs
 create mode 100644 Command/ConfigRemote.hs
 create mode 100644 Command/ContentLocation.hs
 create mode 100644 Command/Copy.hs
 create mode 100644 Command/Dead.hs
 create mode 100644 Command/Describe.hs
 create mode 100644 Command/DiffDriver.hs
 create mode 100644 Command/Direct.hs
 create mode 100644 Command/Drop.hs
 create mode 100644 Command/DropKey.hs
 create mode 100644 Command/DropUnused.hs
 create mode 100644 Command/EnableRemote.hs
 create mode 100644 Command/EnableTor.hs
 create mode 100644 Command/ExamineKey.hs
 create mode 100644 Command/Expire.hs
 create mode 100644 Command/Export.hs
 create mode 100644 Command/FilterBranch.hs
 create mode 100644 Command/FilterProcess.hs
 create mode 100644 Command/Find.hs
 create mode 100644 Command/FindKeys.hs
 create mode 100644 Command/FindRef.hs
 create mode 100644 Command/Fix.hs
 create mode 100644 Command/Forget.hs
 create mode 100644 Command/FromKey.hs
 create mode 100644 Command/Fsck.hs
 create mode 100644 Command/FuzzTest.hs
 create mode 100644 Command/GCryptSetup.hs
 create mode 100644 Command/Get.hs
 create mode 100644 Command/Group.hs
 create mode 100644 Command/GroupWanted.hs
 create mode 100644 Command/Help.hs
 create mode 100644 Command/Import.hs
 create mode 100644 Command/ImportFeed.hs
 create mode 100644 Command/InAnnex.hs
 create mode 100644 Command/Indirect.hs
 create mode 100644 Command/Info.hs
 create mode 100644 Command/Init.hs
 create mode 100644 Command/InitRemote.hs
 create mode 100644 Command/Inprogress.hs
 create mode 100644 Command/List.hs
 create mode 100644 Command/Lock.hs
 create mode 100644 Command/Log.hs
 create mode 100644 Command/LookupKey.hs
 create mode 100644 Command/Map.hs
 create mode 100644 Command/MatchExpression.hs
 create mode 100644 Command/Merge.hs
 create mode 100644 Command/MetaData.hs
 create mode 100644 Command/Migrate.hs
 create mode 100644 Command/MinCopies.hs
 create mode 100644 Command/Mirror.hs
 create mode 100644 Command/Move.hs
 create mode 100644 Command/Multicast.hs
 create mode 100644 Command/NotifyChanges.hs
 create mode 100644 Command/NumCopies.hs
 create mode 100644 Command/OldKeys.hs
 create mode 100644 Command/P2P.hs
 create mode 100644 Command/P2PStdIO.hs
 create mode 100644 Command/PostReceive.hs
 create mode 100644 Command/PreCommit.hs
 create mode 100644 Command/Proxy.hs
 create mode 100644 Command/Pull.hs
 create mode 100644 Command/Push.hs
 create mode 100644 Command/ReKey.hs
 create mode 100644 Command/ReadPresentKey.hs
 create mode 100644 Command/RecvKey.hs
 create mode 100644 Command/RegisterUrl.hs
 create mode 100644 Command/Reinit.hs
 create mode 100644 Command/Reinject.hs
 create mode 100644 Command/RemoteDaemon.hs
 create mode 100644 Command/RenameRemote.hs
 create mode 100644 Command/Repair.hs
 create mode 100644 Command/Required.hs
 create mode 100644 Command/ReregisterUrl.hs
 create mode 100644 Command/ResolveMerge.hs
 create mode 100644 Command/Restage.hs
 create mode 100644 Command/RmUrl.hs
 create mode 100644 Command/Satisfy.hs
 create mode 100644 Command/Schedule.hs
 create mode 100644 Command/Semitrust.hs
 create mode 100644 Command/SendKey.hs
 create mode 100644 Command/SetKey.hs
 create mode 100644 Command/SetPresentKey.hs
 create mode 100644 Command/Smudge.hs
 create mode 100644 Command/Status.hs
 create mode 100644 Command/Sync.hs
 create mode 100644 Command/Test.hs
 create mode 100644 Command/TestRemote.hs
 create mode 100644 Command/TransferKey.hs
 create mode 100644 Command/TransferKeys.hs
 create mode 100644 Command/Transferrer.hs
 create mode 100644 Command/Trust.hs
 create mode 100644 Command/Unannex.hs
 create mode 100644 Command/Undo.hs
 create mode 100644 Command/Ungroup.hs
 create mode 100644 Command/Uninit.hs
 create mode 100644 Command/Unlock.hs
 create mode 100644 Command/UnregisterUrl.hs
 create mode 100644 Command/Untrust.hs
 create mode 100644 Command/Unused.hs
 create mode 100644 Command/Upgrade.hs
 create mode 100644 Command/VAdd.hs
 create mode 100644 Command/VCycle.hs
 create mode 100644 Command/VFilter.hs
 create mode 100644 Command/VPop.hs
 create mode 100644 Command/Version.hs
 create mode 100644 Command/Vicfg.hs
 create mode 100644 Command/View.hs
 create mode 100644 Command/Wanted.hs
 create mode 100644 Command/Watch.hs
 create mode 100644 Command/WebApp.hs
 create mode 100644 Command/WhereUsed.hs
 create mode 100644 Command/Whereis.hs
 create mode 100644 Common.hs
 create mode 100644 Config.hs
 create mode 100644 Config/Cost.hs
 create mode 100644 Config/DynamicConfig.hs
 create mode 100644 Config/Files.hs
 create mode 100644 Config/Files/AutoStart.hs
 create mode 100644 Config/GitConfig.hs
 create mode 100644 Config/Smudge.hs
 create mode 100644 Creds.hs
 create mode 100644 Crypto.hs
 create mode 100644 Database/Benchmark.hs
 create mode 100644 Database/ContentIdentifier.hs
 create mode 100644 Database/Export.hs
 create mode 100644 Database/Fsck.hs
 create mode 100644 Database/Handle.hs
 create mode 100644 Database/ImportFeed.hs
 create mode 100644 Database/Init.hs
 create mode 100644 Database/Keys.hs
 create mode 100644 Database/Keys/Handle.hs
 create mode 100644 Database/Keys/SQL.hs
 create mode 100644 Database/Keys/Tables.hs
 create mode 100644 Database/Queue.hs
 create mode 100644 Database/RawFilePath.hs
 create mode 100644 Database/Types.hs
 create mode 100644 Database/Utility.hs
 create mode 100644 Git.hs
 create mode 100644 Git/AutoCorrect.hs
 create mode 100644 Git/Branch.hs
 create mode 100644 Git/BuildVersion.hs
 create mode 100644 Git/CatFile.hs
 create mode 100644 Git/CheckAttr.hs
 create mode 100644 Git/CheckIgnore.hs
 create mode 100644 Git/Command.hs
 create mode 100644 Git/Command/Batch.hs
 create mode 100644 Git/Config.hs
 create mode 100644 Git/ConfigTypes.hs
 create mode 100644 Git/Construct.hs
 create mode 100644 Git/Credential.hs
 create mode 100644 Git/CurrentRepo.hs
 create mode 100644 Git/DiffTree.hs
 create mode 100644 Git/DiffTreeItem.hs
 create mode 100644 Git/Env.hs
 create mode 100644 Git/FileMode.hs
 create mode 100644 Git/FilePath.hs
 create mode 100644 Git/FilterProcess.hs
 create mode 100644 Git/Fsck.hs
 create mode 100644 Git/GCrypt.hs
 create mode 100644 Git/HashObject.hs
 create mode 100644 Git/History.hs
 create mode 100644 Git/Hook.hs
 create mode 100644 Git/Index.hs
 create mode 100644 Git/LockFile.hs
 create mode 100644 Git/Log.hs
 create mode 100644 Git/LsFiles.hs
 create mode 100644 Git/LsTree.hs
 create mode 100644 Git/Merge.hs
 create mode 100644 Git/Objects.hs
 create mode 100644 Git/PktLine.hs
 create mode 100644 Git/Queue.hs
 create mode 100644 Git/Quote.hs
 create mode 100644 Git/Ref.hs
 create mode 100644 Git/RefLog.hs
 create mode 100644 Git/Remote.hs
 create mode 100644 Git/Remote/Remove.hs
 create mode 100644 Git/Repair.hs
 create mode 100644 Git/Sha.hs
 create mode 100644 Git/Ssh.hs
 create mode 100644 Git/Status.hs
 create mode 100644 Git/Tree.hs
 create mode 100644 Git/Types.hs
 create mode 100644 Git/UnionMerge.hs
 create mode 100644 Git/UpdateIndex.hs
 create mode 100644 Git/Url.hs
 create mode 100644 Git/Version.hs
 create mode 100644 Key.hs
 create mode 100644 Limit.hs
 create mode 100644 Limit/Wanted.hs
 create mode 100644 Logs.hs
 create mode 100644 Logs/Activity.hs
 create mode 100644 Logs/AdjustedBranchUpdate.hs
 create mode 100644 Logs/Chunk.hs
 create mode 100644 Logs/Chunk/Pure.hs
 create mode 100644 Logs/Config.hs
 create mode 100644 Logs/ContentIdentifier.hs
 create mode 100644 Logs/ContentIdentifier/Pure.hs
 create mode 100644 Logs/Difference.hs
 create mode 100644 Logs/Difference/Pure.hs
 create mode 100644 Logs/EquivilantKeys.hs
 create mode 100644 Logs/Export.hs
 create mode 100644 Logs/Export/Pure.hs
 create mode 100644 Logs/File.hs
 create mode 100644 Logs/FsckResults.hs
 create mode 100644 Logs/Group.hs
 create mode 100644 Logs/Import.hs
 create mode 100644 Logs/Line.hs
 create mode 100644 Logs/Location.hs
 create mode 100644 Logs/MapLog.hs
 create mode 100644 Logs/MetaData.hs
 create mode 100644 Logs/MetaData/Pure.hs
 create mode 100644 Logs/Migrate.hs
 create mode 100644 Logs/Multicast.hs
 create mode 100644 Logs/NumCopies.hs
 create mode 100644 Logs/PreferredContent.hs
 create mode 100644 Logs/PreferredContent/Raw.hs
 create mode 100644 Logs/Presence.hs
 create mode 100644 Logs/Presence/Pure.hs
 create mode 100644 Logs/Remote.hs
 create mode 100644 Logs/Remote/Pure.hs
 create mode 100644 Logs/RemoteState.hs
 create mode 100644 Logs/Restage.hs
 create mode 100644 Logs/Schedule.hs
 create mode 100644 Logs/SingleValue.hs
 create mode 100644 Logs/SingleValue/Pure.hs
 create mode 100644 Logs/Smudge.hs
 create mode 100644 Logs/Transfer.hs
 create mode 100644 Logs/Transitions.hs
 create mode 100644 Logs/Trust.hs
 create mode 100644 Logs/Trust/Basic.hs
 create mode 100644 Logs/Trust/Pure.hs
 create mode 100644 Logs/UUID.hs
 create mode 100644 Logs/UUIDBased.hs
 create mode 100644 Logs/Unused.hs
 create mode 100644 Logs/Upgrade.hs
 create mode 100644 Logs/View.hs
 create mode 100644 Logs/Web.hs
 create mode 100644 Makefile
 create mode 100644 Messages.hs
 create mode 100644 Messages/Concurrent.hs
 create mode 100644 Messages/Internal.hs
 create mode 100644 Messages/JSON.hs
 create mode 100644 Messages/Progress.hs
 create mode 100644 Messages/Serialized.hs
 create mode 100644 NEWS
 create mode 100644 P2P/Address.hs
 create mode 100644 P2P/Annex.hs
 create mode 100644 P2P/Auth.hs
 create mode 100644 P2P/IO.hs
 create mode 100644 P2P/Protocol.hs
 create mode 100644 README
 create mode 100644 Remote.hs
 create mode 100644 Remote/Adb.hs
 create mode 100644 Remote/BitTorrent.hs
 create mode 100644 Remote/Borg.hs
 create mode 100644 Remote/Bup.hs
 create mode 100644 Remote/Ddar.hs
 create mode 100644 Remote/Directory.hs
 create mode 100644 Remote/Directory/LegacyChunked.hs
 create mode 100644 Remote/External.hs
 create mode 100644 Remote/External/AsyncExtension.hs
 create mode 100644 Remote/External/Types.hs
 create mode 100644 Remote/GCrypt.hs
 create mode 100644 Remote/Git.hs
 create mode 100644 Remote/GitLFS.hs
 create mode 100644 Remote/Glacier.hs
 create mode 100644 Remote/Helper/AWS.hs
 create mode 100644 Remote/Helper/Chunked.hs
 create mode 100644 Remote/Helper/Chunked/Legacy.hs
 create mode 100644 Remote/Helper/Encryptable.hs
 create mode 100644 Remote/Helper/ExportImport.hs
 create mode 100644 Remote/Helper/Git.hs
 create mode 100644 Remote/Helper/Hooks.hs
 create mode 100644 Remote/Helper/Http.hs
 create mode 100644 Remote/Helper/Messages.hs
 create mode 100644 Remote/Helper/P2P.hs
 create mode 100644 Remote/Helper/Path.hs
 create mode 100644 Remote/Helper/ReadOnly.hs
 create mode 100644 Remote/Helper/Special.hs
 create mode 100644 Remote/Helper/Ssh.hs
 create mode 100644 Remote/Helper/ThirdPartyPopulated.hs
 create mode 100644 Remote/Hook.hs
 create mode 100644 Remote/HttpAlso.hs
 create mode 100644 Remote/List.hs
 create mode 100644 Remote/List/Util.hs
 create mode 100644 Remote/P2P.hs
 create mode 100644 Remote/Rclone.hs
 create mode 100644 Remote/Rsync.hs
 create mode 100644 Remote/Rsync/RsyncUrl.hs
 create mode 100644 Remote/S3.hs
 create mode 100644 Remote/Tahoe.hs
 create mode 100644 Remote/Web.hs
 create mode 100644 Remote/WebDAV.hs
 create mode 100644 Remote/WebDAV/DavLocation.hs
 create mode 100644 RemoteDaemon/Common.hs
 create mode 100644 RemoteDaemon/Core.hs
 create mode 100644 RemoteDaemon/Transport.hs
 create mode 100644 RemoteDaemon/Transport/GCrypt.hs
 create mode 100644 RemoteDaemon/Transport/Ssh.hs
 create mode 100644 RemoteDaemon/Transport/Ssh/Types.hs
 create mode 100644 RemoteDaemon/Transport/Tor.hs
 create mode 100644 RemoteDaemon/Types.hs
 create mode 100644 Setup.hs
 create mode 100644 Test.hs
 create mode 100644 Test/Framework.hs
 create mode 100644 Types.hs
 create mode 100644 Types/ActionItem.hs
 create mode 100644 Types/AdjustedBranch.hs
 create mode 100644 Types/Availability.hs
 create mode 100644 Types/Backend.hs
 create mode 100644 Types/Benchmark.hs
 create mode 100644 Types/BranchState.hs
 create mode 100644 Types/CatFileHandles.hs
 create mode 100644 Types/CleanupActions.hs
 create mode 100644 Types/Command.hs
 create mode 100644 Types/Concurrency.hs
 create mode 100644 Types/Creds.hs
 create mode 100644 Types/Crypto.hs
 create mode 100644 Types/DeferredParse.hs
 create mode 100644 Types/DesktopNotify.hs
 create mode 100644 Types/Difference.hs
 create mode 100644 Types/Direction.hs
 create mode 100644 Types/Distribution.hs
 create mode 100644 Types/Export.hs
 create mode 100644 Types/FileMatcher.hs
 create mode 100644 Types/GitConfig.hs
 create mode 100644 Types/Group.hs
 create mode 100644 Types/Import.hs
 create mode 100644 Types/IndexFiles.hs
 create mode 100644 Types/Key.hs
 create mode 100644 Types/KeySource.hs
 create mode 100644 Types/Link.hs
 create mode 100644 Types/LockCache.hs
 create mode 100644 Types/Messages.hs
 create mode 100644 Types/MetaData.hs
 create mode 100644 Types/Mime.hs
 create mode 100644 Types/NumCopies.hs
 create mode 100644 Types/ProposedAccepted.hs
 create mode 100644 Types/RefSpec.hs
 create mode 100644 Types/Remote.hs
 create mode 100644 Types/RemoteConfig.hs
 create mode 100644 Types/RemoteState.hs
 create mode 100644 Types/RepoVersion.hs
 create mode 100644 Types/ScheduledActivity.hs
 create mode 100644 Types/StallDetection.hs
 create mode 100644 Types/StandardGroups.hs
 create mode 100644 Types/StoreRetrieve.hs
 create mode 100644 Types/Test.hs
 create mode 100644 Types/Transfer.hs
 create mode 100644 Types/Transferrer.hs
 create mode 100644 Types/TransferrerPool.hs
 create mode 100644 Types/Transitions.hs
 create mode 100644 Types/TrustLevel.hs
 create mode 100644 Types/UUID.hs
 create mode 100644 Types/Upgrade.hs
 create mode 100644 Types/UrlContents.hs
 create mode 100644 Types/VectorClock.hs
 create mode 100644 Types/View.hs
 create mode 100644 Types/WorkerPool.hs
 create mode 100644 Upgrade.hs
 create mode 100644 Upgrade/V0.hs
 create mode 100644 Upgrade/V1.hs
 create mode 100644 Upgrade/V2.hs
 create mode 100644 Upgrade/V3.hs
 create mode 100644 Upgrade/V4.hs
 create mode 100644 Upgrade/V5.hs
 create mode 100644 Upgrade/V5/Direct.hs
 create mode 100644 Upgrade/V6.hs
 create mode 100644 Upgrade/V7.hs
 create mode 100644 Upgrade/V8.hs
 create mode 100644 Upgrade/V9.hs
 create mode 100644 Utility/Aeson.hs
 create mode 100644 Utility/Android.hs
 create mode 100644 Utility/Applicative.hs
 create mode 100644 Utility/Attoparsec.hs
 create mode 100644 Utility/AuthToken.hs
 create mode 100644 Utility/Base64.hs
 create mode 100644 Utility/Batch.hs
 create mode 100644 Utility/Bloom.hs
 create mode 100644 Utility/CoProcess.hs
 create mode 100644 Utility/CopyFile.hs
 create mode 100644 Utility/DBus.hs
 create mode 100644 Utility/Daemon.hs
 create mode 100644 Utility/Data.hs
 create mode 100644 Utility/DataUnits.hs
 create mode 100644 Utility/Debug.hs
 create mode 100644 Utility/DebugLocks.hs
 create mode 100644 Utility/DirWatcher.hs
 create mode 100644 Utility/DirWatcher/FSEvents.hs
 create mode 100644 Utility/DirWatcher/INotify.hs
 create mode 100644 Utility/DirWatcher/Kqueue.hs
 create mode 100644 Utility/DirWatcher/Types.hs
 create mode 100644 Utility/DirWatcher/Win32Notify.hs
 create mode 100644 Utility/Directory.hs
 create mode 100644 Utility/Directory/Create.hs
 create mode 100644 Utility/Directory/Stream.hs
 create mode 100644 Utility/DiskFree.hs
 create mode 100644 Utility/Dot.hs
 create mode 100644 Utility/DottedVersion.hs
 create mode 100644 Utility/Env.hs
 create mode 100644 Utility/Env/Basic.hs
 create mode 100644 Utility/Env/Set.hs
 create mode 100644 Utility/Exception.hs
 create mode 100644 Utility/FileMode.hs
 create mode 100644 Utility/FileSize.hs
 create mode 100644 Utility/FileSystemEncoding.hs
 create mode 100644 Utility/Format.hs
 create mode 100644 Utility/FreeDesktop.hs
 create mode 100644 Utility/Glob.hs
 create mode 100644 Utility/Gpg.hs
 create mode 100644 Utility/Hash.hs
 create mode 100644 Utility/HtmlDetect.hs
 create mode 100644 Utility/HumanNumber.hs
 create mode 100644 Utility/HumanTime.hs
 create mode 100644 Utility/IPAddress.hs
 create mode 100644 Utility/InodeCache.hs
 create mode 100644 Utility/LinuxMkLibs.hs
 create mode 100644 Utility/LockFile.hs
 create mode 100644 Utility/LockFile/LockStatus.hs
 create mode 100644 Utility/LockFile/PidLock.hs
 create mode 100644 Utility/LockFile/Posix.hs
 create mode 100644 Utility/LockFile/Windows.hs
 create mode 100644 Utility/LockPool.hs
 create mode 100644 Utility/LockPool/LockHandle.hs
 create mode 100644 Utility/LockPool/PidLock.hs
 create mode 100644 Utility/LockPool/Posix.hs
 create mode 100644 Utility/LockPool/STM.hs
 create mode 100644 Utility/LockPool/Windows.hs
 create mode 100644 Utility/LogFile.hs
 create mode 100644 Utility/Lsof.hs
 create mode 100644 Utility/MD5.hs
 create mode 100644 Utility/MagicWormhole.hs
 create mode 100644 Utility/Matcher.hs
 create mode 100644 Utility/Metered.hs
 create mode 100644 Utility/Misc.hs
 create mode 100644 Utility/Monad.hs
 create mode 100644 Utility/Mounts.hs
 create mode 100644 Utility/MoveFile.hs
 create mode 100644 Utility/Network.hs
 create mode 100644 Utility/NotificationBroadcaster.hs
 create mode 100644 Utility/OSX.hs
 create mode 100644 Utility/OpenFd.hs
 create mode 100644 Utility/OptParse.hs
 create mode 100644 Utility/PID.hs
 create mode 100644 Utility/PartialPrelude.hs
 create mode 100644 Utility/Path.hs
 create mode 100644 Utility/Path/AbsRel.hs
 create mode 100644 Utility/Path/Max.hs
 create mode 100644 Utility/Path/Tests.hs
 create mode 100644 Utility/Path/Windows.hs
 create mode 100644 Utility/Percentage.hs
 create mode 100644 Utility/Process.hs
 create mode 100644 Utility/Process/Shim.hs
 create mode 100644 Utility/Process/Transcript.hs
 create mode 100644 Utility/QuickCheck.hs
 create mode 100644 Utility/RawFilePath.hs
 create mode 100644 Utility/ResourcePool.hs
 create mode 100644 Utility/Rsync.hs
 create mode 100644 Utility/SafeCommand.hs
 create mode 100644 Utility/SafeOutput.hs
 create mode 100644 Utility/Scheduled.hs
 create mode 100644 Utility/Scheduled/QuickCheck.hs
 create mode 100644 Utility/Shell.hs
 create mode 100644 Utility/ShellEscape.hs
 create mode 100644 Utility/SimpleProtocol.hs
 create mode 100644 Utility/Split.hs
 create mode 100644 Utility/SshConfig.hs
 create mode 100644 Utility/SshHost.hs
 create mode 100644 Utility/StatelessOpenPGP.hs
 create mode 100644 Utility/Su.hs
 create mode 100644 Utility/SystemDirectory.hs
 create mode 100644 Utility/TList.hs
 create mode 100644 Utility/Tense.hs
 create mode 100644 Utility/Terminal.hs
 create mode 100644 Utility/ThreadLock.hs
 create mode 100644 Utility/ThreadScheduler.hs
 create mode 100644 Utility/TimeStamp.hs
 create mode 100644 Utility/Tmp.hs
 create mode 100644 Utility/Tmp/Dir.hs
 create mode 100644 Utility/Tor.hs
 create mode 100644 Utility/Touch.hs
 create mode 100644 Utility/Tuple.hs
 create mode 100644 Utility/Url.hs
 create mode 100644 Utility/Url/Parse.hs
 create mode 100644 Utility/UserInfo.hs
 create mode 100644 Utility/Verifiable.hs
 create mode 100644 Utility/WebApp.hs
 create mode 100644 Utility/Yesod.hs
 create mode 100644 Utility/libkqueue.c
 create mode 100644 Utility/libkqueue.h
 create mode 100644 bash-completion.bash
 create mode 120000 debian/NEWS
 create mode 120000 debian/changelog
 create mode 100644 debian/compat
 create mode 100644 debian/control
 create mode 120000 debian/copyright
 create mode 100755 debian/create-standalone-changelog
 create mode 100644 debian/doc-base
 create mode 100644 debian/patches/series.standalone-build
 create mode 100644 debian/patches/standalone-build
 create mode 100755 debian/rules
 create mode 100644 debian/source/format
 create mode 100644 debian/tests/basics
 create mode 100644 debian/tests/control
 create mode 100644 doc/Android.mdwn
 create mode 100644 doc/Android/comment_29_37aa87a451d4390ed367402eec740855._comment
 create mode 100644 doc/Android/comment_2_7f0caccd085a541b117c8583133e94dd._comment
 create mode 100644 doc/Android/comment_3_ff03ae378da71c6637959779139ecb12._comment
 create mode 100644 doc/Android/comment_4_c7591d06fc444a4462267b000be8d688._comment
 create mode 100644 doc/Android/comment_5_9118997c7e892ce163c33a0de963fa11._comment
 create mode 100644 doc/Android/comment_6_e9559029d8f2c482a482f7343ffa99a4._comment
 create mode 100644 doc/android/DCIM.png
 create mode 100644 doc/android/appinstalled.png
 create mode 100644 doc/android/webapp.png
 create mode 100644 doc/assistant.mdwn
 create mode 100644 doc/assistant/addsshserver.png
 create mode 100644 doc/assistant/archival_walkthrough.mdwn
 create mode 100644 doc/assistant/brokenrepositoryalert.png
 create mode 100644 doc/assistant/buddylist.png
 create mode 100644 doc/assistant/cloudnudge.png
 create mode 100644 doc/assistant/combinerepos.png
 create mode 100644 doc/assistant/comment_1_f2c4857b7b000e005f0c19279db14eaf._comment
 create mode 100644 doc/assistant/comment_2_befa1f48e5a43a7965060491430a6bc4._comment
 create mode 100644 doc/assistant/comment_3_9bd3b532a5c026a1d664c898f8e335e6._comment
 create mode 100644 doc/assistant/comment_4_c546a24459ca29025f00e424353c40d2._comment
 create mode 100644 doc/assistant/comment_5_d17de359cdd46659170d373cd09c0979._comment
 create mode 100644 doc/assistant/comment_6_70193bbaa5d60b829d7636748c641104._comment
 create mode 100644 doc/assistant/comment_7_831a529c92951f70a27721210204e46b._comment
 create mode 100644 doc/assistant/connection.png
 create mode 100644 doc/assistant/controlmenu.png
 create mode 100644 doc/assistant/crashrecovery.png
 create mode 100644 doc/assistant/dashboard.png
 create mode 100644 doc/assistant/deleterepository.png
 create mode 100644 doc/assistant/downloadnotification.png
 create mode 100644 doc/assistant/downloadupgrade.png
 create mode 100644 doc/assistant/encryptdrive.png
 create mode 100644 doc/assistant/example.png
 create mode 100644 doc/assistant/fsckconfig.png
 create mode 100644 doc/assistant/genkey.png
 create mode 100644 doc/assistant/iaitem.png
 create mode 100644 doc/assistant/inotify_max_limit_alert.png
 create mode 100644 doc/assistant/konquerormenu.png
 create mode 100644 doc/assistant/local_pairing_walkthrough.mdwn
 create mode 100644 doc/assistant/local_pairing_walkthrough/addrepository.png
 create mode 100644 doc/assistant/local_pairing_walkthrough/comment_1_b33deed054d3aa8cfa6c9e3958643f16._comment
 create mode 100644 doc/assistant/local_pairing_walkthrough/comment_2_39f1162b4d43b61e957e7497df4b9e2b._comment
 create mode 100644 doc/assistant/local_pairing_walkthrough/comment_3_588869692b290483f58f3a7aa2bfb55f._comment
 create mode 100644 doc/assistant/local_pairing_walkthrough/comment_4_f6bf82c263fefe38701709d9dbd974cc._comment
 create mode 100644 doc/assistant/local_pairing_walkthrough/comment_5_bada601ea4b7104f162a3e00def4be2b._comment
 create mode 100644 doc/assistant/local_pairing_walkthrough/comment_6_01ba0f9bfa0ed066c4b73d2d6028eecc._comment
 create mode 100644 doc/assistant/local_pairing_walkthrough/comment_7_17d44229e4fa46c50815672b96a9735a._comment
 create mode 100644 doc/assistant/local_pairing_walkthrough/comment_8_b9d4c29cf2cca0427808df6af08fb789._comment
 create mode 100644 doc/assistant/local_pairing_walkthrough/comment_9_bf313e490076a4676a632e3ec6129189._comment
 create mode 100644 doc/assistant/local_pairing_walkthrough/pairing.png
 create mode 100644 doc/assistant/local_pairing_walkthrough/pairrequest.png
 create mode 100644 doc/assistant/local_pairing_walkthrough/secret.png
 create mode 100644 doc/assistant/local_pairing_walkthrough/secretempty.png
 create mode 100644 doc/assistant/logs.png
 create mode 100644 doc/assistant/makerepo.png
 create mode 100644 doc/assistant/menu.png
 create mode 100644 doc/assistant/nautilusmenu.png
 create mode 100644 doc/assistant/osx-app.png
 create mode 100644 doc/assistant/preferences.png
 create mode 100644 doc/assistant/quickstart.mdwn
 create mode 100644 doc/assistant/release_notes.mdwn
 create mode 100644 doc/assistant/release_notes/comment_1_bd8f376c9d0c1d5ed07fb013907a60ee._comment
 create mode 100644 doc/assistant/release_notes/comment_2_75e0774ad042717fbd059a8a9ec2db1e._comment
 create mode 100644 doc/assistant/release_notes/comment_3_b3bfd8e547e20c51f7c32c6c9424e936._comment
 create mode 100644 doc/assistant/release_notes/comment_4_c6caa2b521b456bb4ce594d64919cffe._comment
 create mode 100644 doc/assistant/release_notes/comment_5_e9faf88a8eeb9aa8714c8c0514792815._comment
 create mode 100644 doc/assistant/release_notes/comment_6_53c2b479dbb53236000b4b3caad8ed04._comment
 create mode 100644 doc/assistant/remote_sharing_walkthrough.mdwn
 create mode 100644 doc/assistant/repairrepository.png
 create mode 100644 doc/assistant/repogroups.png
 create mode 100644 doc/assistant/repoinfo.png
 create mode 100644 doc/assistant/repositories.png
 create mode 100644 doc/assistant/rsync.net.encryption.png
 create mode 100644 doc/assistant/rsync.net.png
 create mode 100644 doc/assistant/running.png
 create mode 100644 doc/assistant/share_with_a_friend_walkthrough.mdwn
 create mode 100644 doc/assistant/share_with_a_friend_walkthrough/enabletor.png
 create mode 100644 doc/assistant/share_with_a_friend_walkthrough/pairing.png
 create mode 100644 doc/assistant/share_with_a_friend_walkthrough/wormholepairing.png
 create mode 100644 doc/assistant/thanks.mdwn
 create mode 100644 doc/assistant/thumbnail.png
 create mode 100644 doc/assistant/unused.png
 create mode 100644 doc/assistant/upgradecomplete.png
 create mode 100644 doc/assistant/xmpp.png
 create mode 100644 doc/assistant/xmppnudge.png
 create mode 100644 doc/assistant/xmpppairingend.png
 create mode 100644 doc/automatic_conflict_resolution.mdwn
 create mode 100644 doc/automatic_conflict_resolution/comment_1_307898855f91a2a189d4fa5eae62cce1._comment
 create mode 100644 doc/automatic_conflict_resolution/comment_2_0a8ea42764dde1a33d2112197b961c51._comment
 create mode 100644 doc/automatic_conflict_resolution/comment_3_5c587c6633cae1c8547ca970d55ee97e._comment
 create mode 100644 doc/automatic_conflict_resolution/comment_4_80539e11e36a0b64cee83b6b373bd843._comment
 create mode 100644 doc/automatic_conflict_resolution/comment_5_00ac9e4a47ce9a886dbf573480f151bd._comment
 create mode 100644 doc/automatic_conflict_resolution/comment_6_8a0860fee88f5954918305f055a39d8d._comment
 create mode 100644 doc/automatic_conflict_resolution/comment_7_3d2250cc26036b8532faa980065e20d0._comment
 create mode 100644 doc/automatic_conflict_resolution/comment_8_ef474c258ce8e0ebc6485c1366ae6315._comment
 create mode 100644 doc/backends.mdwn
 create mode 100644 doc/backends/comment_10_920cd139dfec8adb1089f5acf26de4d2._comment
 create mode 100644 doc/backends/comment_11_f0f6316bbdc971a9ab157de9bbb9f74c._comment
 create mode 100644 doc/backends/comment_12_da76dff5fe712318d7d4313f1d827883._comment
 create mode 100644 doc/backends/comment_13_578423935bc71cdbdc23c3db06d1e870._comment
 create mode 100644 doc/backends/comment_14_57154dcd1041a33f220f9105b709be89._comment
 create mode 100644 doc/backends/comment_15_b3445fd1f379346c642a27211c6c798b._comment
 create mode 100644 doc/backends/comment_16_c68dfaeee2ef18f420f7e11ff5f604b9._comment
 create mode 100644 doc/backends/comment_17_557a622b3304eb86fed52896e0b6cbda._comment
 create mode 100644 doc/backends/comment_18_784b29b086503a2b4913558350526ee1._comment
 create mode 100644 doc/backends/comment_19_cfcaeea6fdded241f5d36ef251ef8010._comment
 create mode 100644 doc/backends/comment_1_375bb1fb5973e8fa67b763f2dd6e404b._comment
 create mode 100644 doc/backends/comment_20_29e500adf7e8614a938b3b714c9bd112._comment
 create mode 100644 doc/backends/comment_21_7f9cc5f966b28b7461e8ec42ceeb7165._comment
 create mode 100644 doc/backends/comment_22_be75c669ed8e127de8b6364961a5c0cb._comment
 create mode 100644 doc/backends/comment_23_8c8b08d7e6409756da4f9f3b21d5ad01._comment
 create mode 100644 doc/backends/comment_24_f90b8eeae8d150eca6a91416f20eb223._comment
 create mode 100644 doc/backends/comment_25_f6a697ac069ab018ccacf8f16b09bc7e._comment
 create mode 100644 doc/backends/comment_26_9e9e0f3631c60b0cdcaa9c6dd4ae0d4e._comment
 create mode 100644 doc/backends/comment_27_c311551741a671bcb1f32b80431c1d66._comment
 create mode 100644 doc/backends/comment_28_44e8d93b1f0a88c36543438d6e33d702._comment
 create mode 100644 doc/backends/comment_29_9e14c32713b5607b245972b400286a45._comment
 create mode 100644 doc/backends/comment_2_1f2626eca9004b31a0b7fc1a0df8027b._comment
 create mode 100644 doc/backends/comment_30_bea2a3f4f673e6e9d5ee99cf10d39460._comment
 create mode 100644 doc/backends/comment_31_32df8ec41dd8a6516b88b1871c998eb9._comment
 create mode 100644 doc/backends/comment_32_b0a375dcd0932aa380ce01d693462f5e._comment
 create mode 100644 doc/backends/comment_33_4c5f9c75cbb8a546e8325b206369aba1._comment
 create mode 100644 doc/backends/comment_34_3782e7561607c8ccf1741bd039c2c648._comment
 create mode 100644 doc/backends/comment_35_8ac9d37cc2a7b0b361cf686fe27192dd._comment
 create mode 100644 doc/backends/comment_3_fdcbf8727fdefb9942a54689234b9698._comment
 create mode 100644 doc/backends/comment_4_46591a3ba888fb686b1b319b80ca2c22._comment
 create mode 100644 doc/backends/comment_5_2210c7ff2d5812fb3b778ac172291656._comment
 create mode 100644 doc/backends/comment_6_82f239b58680a2681bd8074c7ef9584d._comment
 create mode 100644 doc/backends/comment_7_4aa8cfaec1090f79fed530720e4ddad4._comment
 create mode 100644 doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment
 create mode 100644 doc/backends/comment_9_5bef7f76f5e5b73a8e404fe6172b4368._comment
 create mode 100644 doc/bare_repositories.mdwn
 create mode 100644 doc/bare_repositories/comment_1_148e1da70d37d311634a0309a4ff8dcd._comment
 create mode 100644 doc/bare_repositories/comment_2_c88216da0588562c851c2ceabbfebc0a._comment
 create mode 100644 doc/bare_repositories/comment_3_26ba93bddb0cd1bb4e1799311f3ca750._comment
 create mode 100644 doc/bare_repositories/comment_4_7cf6103709a7a2710686681a6f406214._comment
 create mode 100644 doc/bare_repositories/comment_5_6328134497c0de6a088087fc9cb0e59e._comment
 create mode 100644 doc/bare_repositories/comment_6_bf227861ec3cb2ea474c143218c68133._comment
 create mode 100644 doc/bare_repositories/comment_7_9e065a2d8aaf7371ab7c0bb4f0c724b0._comment
 create mode 100644 doc/bare_repositories/comment_8_d4dff0d6265be941af9f66ba09f36ebe._comment
 create mode 100644 doc/bugs.mdwn
 create mode 100644 doc/bugs/--git-dir_and_--work-tree_separation_issue.mdwn
 create mode 100644 doc/bugs/--git-dir_and_--work-tree_separation_issue/comment_1_fa97996b85c0f949bbd720204db8ed46._comment
 create mode 100644 doc/bugs/10.20220525_cannot_probe_for_untrusted_remote_key.mdwn
 create mode 100644 doc/bugs/10.20220525_cannot_probe_for_untrusted_remote_key/comment_1_e35bef8fb0b9a40938022c43c87df597._comment
 create mode 100644 doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows.mdwn
 create mode 100644 doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_1_70480ffd417788f18cd75a9b625ecf3b._comment
 create mode 100644 doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_2_afa6a131999feda67876859cd85ebcfc._comment
 create mode 100644 doc/bugs/Adjust_--unlock_not_using_--reflink__63__.mdwn
 create mode 100644 doc/bugs/Adjust_--unlock_not_using_--reflink__63__/comment_1_c42743828ddc62f7df7f612c713ee309._comment
 create mode 100644 doc/bugs/Always_identical_UUIDs.mdwn
 create mode 100644 doc/bugs/Always_identical_UUIDs/comment_1_1223fe5e635d771848d7054f0492920f._comment
 create mode 100644 doc/bugs/Always_identical_UUIDs/comment_2_6c44232cac847f6160f5bec7c8f1434b._comment
 create mode 100644 doc/bugs/Always_identical_UUIDs/comment_3_cdb2eec514bcf125b7f79c7be5ed810a._comment
 create mode 100644 doc/bugs/Android__44___unable_to_start_browser_.mdwn
 create mode 100644 doc/bugs/Android__44___unable_to_start_browser_/comment_1_1fc9d5168fec0b277b5ab5321c07385f._comment
 create mode 100644 doc/bugs/Android__44___unable_to_start_browser_/comment_2_8db1f505c02fd6d4e8acc1b6bbded03f._comment
 create mode 100644 doc/bugs/Android__44___unable_to_start_browser_/comment_3_93e260d1cb9de25fe4e2a6a973f05da6._comment
 create mode 100644 doc/bugs/Android__58___Several_error_messages___47___warnings.mdwn
 create mode 100644 doc/bugs/Android__58___Several_error_messages___47___warnings/comment_1_85da61d3dfb528fef17366effe123ff5._comment
 create mode 100644 doc/bugs/Android__58___Several_error_messages___47___warnings/comment_2_97ddaba23e91a903f69cf00931627444._comment
 create mode 100644 doc/bugs/Android__58___Several_error_messages___47___warnings/comment_3_b4ea7ff7deb9626a02dfd0eb459f22a2._comment
 create mode 100644 doc/bugs/Android__58___Several_error_messages___47___warnings/comment_4_5edddd7e90b8f11c52a44abfb891ce25._comment
 create mode 100644 doc/bugs/Android__58___Several_error_messages___47___warnings/comment_4_b38b675a2862d527fad28b7477f7ddde._comment
 create mode 100644 doc/bugs/Android__58___addurl__58___Network.BSD.getProtocolByName__58___does_not_exist___40__no_such_protocol_name__58___tcp__41__.mdwn
 create mode 100644 doc/bugs/Android__58___addurl__58___Network.BSD.getProtocolByName__58___does_not_exist___40__no_such_protocol_name__58___tcp__41__/comment_1_be30193f501c530bd99e97992a9c08ad._comment
 create mode 100644 doc/bugs/Android___58___handling_DCIM__47__Camera_not_being_configurable.mdwn
 create mode 100644 doc/bugs/Android___58___handling_DCIM__47__Camera_not_being_configurable/comment_1_1fe5f8c68a430b2436649cf4ba8f4987._comment
 create mode 100644 doc/bugs/Android_can__39__t_sync_files_with_utf-8_characters_in_names.mdwn
 create mode 100644 doc/bugs/Android_can__39__t_sync_files_with_utf-8_characters_in_names/comment_1_bcc3ce19cf26731057a7f3189fcbae19._comment
 create mode 100644 doc/bugs/Android_termux_install_fails_with_Bad_system_call.mdwn
 create mode 100644 doc/bugs/Android_unable_to_use_external_special_remote.mdwn
 create mode 100644 doc/bugs/Android_unable_to_use_external_special_remote/comment_1_17b13329db6fb4788240428ed1e2b212._comment
 create mode 100644 doc/bugs/Android_unable_to_use_external_special_remote/comment_2_c235675c07faaecf8e7df2d77fdac3ea._comment
 create mode 100644 doc/bugs/Android_version_converts_plain_git_file___40__git_add__41___to_git-annex_file.mdwn
 create mode 100644 doc/bugs/Assistant__39__s_transfer_bar_often_stuck_at_100__37___and_only_SHA_instead_of_file_content_.mdwn
 create mode 100644 doc/bugs/Assistant__39__s_transfer_bar_often_stuck_at_100__37___and_only_SHA_instead_of_file_content_/comment_1_f88d08035baf75efa1dbbddc296b591a._comment
 create mode 100644 doc/bugs/Assistant__39__s_transfer_bar_often_stuck_at_100__37___and_only_SHA_instead_of_file_content_/comment_2_c1b86731f0e2fe8ce70931fe4a0d1656._comment
 create mode 100644 doc/bugs/Assistant_crashes_with_handle_issues_-_never_works.mdwn
 create mode 100644 doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__.mdwn
 create mode 100644 doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_1_27d96b639bc386132b9e74170532d749._comment
 create mode 100644 doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_2_b9a39f172115fc39fee21c8987843faa._comment
 create mode 100644 doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_3_324213fb62c67dc9565f0e812500e046._comment
 create mode 100644 doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_4_271c48d2cf4b09c27cf47ecba7fe1a64._comment
 create mode 100644 doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn
 create mode 100644 doc/bugs/Assistant_doesn__39__t_sync_directory_remotes.mdwn
 create mode 100644 doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn
 create mode 100644 doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_1_5e7d5b0b996a171c641fa560a613d319._comment
 create mode 100644 doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_2_2015dfc648d26d6dfabe6ad4f4754034._comment
 create mode 100644 doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_3_8f394437982cebeaf878f5b3871afaf3._comment
 create mode 100644 doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_4_ccd108a53a9fb747539e269becfb3e05._comment
 create mode 100644 doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_5_7ee571496c6d7cd57a206e6356dc2be3._comment
 create mode 100644 doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_6_6c88b218b8186242a6106fc3e7b3edf5._comment
 create mode 100644 doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_7_fbbf9d1a63fc61a5fd288fd308b24ca1._comment
 create mode 100644 doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_8_fe2498f60b02104a8a044c79cb5bea63._comment
 create mode 100644 doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories.mdwn
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_10_c5508b476fc48e7a0002b6ecb8d5eac0._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_11_cb49edcc8a13928c171a2acdde32dce9._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_12_a86c8347526e7b0a6f7633f3aea528bb._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_13_a26c2b49ee7746be06f4772aa838d5aa._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_14_b958da97a69091d283918e0d5a658da5._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_1_169b24b34cce3f5c8446c2150beb6827._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_2_6acd6f38297772a07d8d5fb999bd2eaa._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_3_6a4118e5c5fbe5e84d27094ac72b741b._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_4_04daa20d5d7c74bb34ec48e752ed9fe8._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_5_11af8ab2587e6eeb671051ba8191995b._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_6_26236cdc2bce532017854791bcd727d1._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_7_3c532dd5b8a01ecdeda1300b49aba675._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_8_119142c5ebc499f0ee0926dbca265308._comment
 create mode 100644 doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_9_0651071ee1654eeaa9aa9369873fdf6a._comment
 create mode 100644 doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory.mdwn
 create mode 100644 doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_10_edb2428552cf98bfb1735c2d6daf2b20._comment
 create mode 100644 doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_1_ac8c39e362e6c806b9d68befc0199ccd._comment
 create mode 100644 doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_2_b2941bf7901a1b2237b7210c8f0af2a5._comment
 create mode 100644 doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_3_1429ca784a03bc424b3537cbe0449421._comment
 create mode 100644 doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_4_f9e65cf5598b4b14eeee1f41f46d4084._comment
 create mode 100644 doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_5_044ecac2d2e670e1ef69809c944093d1._comment
 create mode 100644 doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_6_6f4f51e1583bed5e7e601e4f30f4207b._comment
 create mode 100644 doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_7_683a0a3d4caea0ee625e41ae8a6c7c06._comment
 create mode 100644 doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_8_03dd76b01f46a7cc66eddac3e054c8ad._comment
 create mode 100644 doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_9_5f4444f03cbebaa44628288095383679._comment
 create mode 100644 doc/bugs/Assistant_is_stuck_with___39__fuzztest__39__.mdwn
 create mode 100644 doc/bugs/Assistant_only_watches_one_repo_on_startup.mdwn
 create mode 100644 doc/bugs/Assistant_only_watches_one_repo_on_startup/comment_1_4606e5c7159e8e9f2f12e010cbd22e6a._comment
 create mode 100644 doc/bugs/Assistant_temporary_delete_and_recommit_files.mdwn
 create mode 100644 doc/bugs/Attempting_to_repair_repository_almost_every_day.mdwn
 create mode 100644 doc/bugs/Auto-repair_greatly_slows_down_the_machine.mdwn
 create mode 100644 doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_10_d46c6314bff75a0ae679bc2358b28c2b._comment
 create mode 100644 doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_11_1c2c3adfbccd2b14a7d1c4618800e735._comment
 create mode 100644 doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_1_a52e4ef04209d0a2449165e2b4cb9ccc._comment
 create mode 100644 doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_2_9f5340ab1012f335af0c246b82c1a777._comment
 create mode 100644 doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_3_67bfccf0934075559d439b1deafc001e._comment
 create mode 100644 doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_4_5fa785aa759d1a1917f2a292324fe5ec._comment
 create mode 100644 doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_5_9fe529034ad0115792b58d7da99c167e._comment
 create mode 100644 doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_6_93ed991ef2a74c18575073ca72e06185._comment
 create mode 100644 doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_7_4649fa11745ff668e43833209811d005._comment
 create mode 100644 doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_8_6138a48f0b7e8be2bb66430397afdf5a._comment
 create mode 100644 doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_9_3da5940bb2e9689b00239eec9a073f1c._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android.mdwn
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_10_da4e26c77376a8171493a815bdb51ff1._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_11_506e26de284a6429366def33b007bc0c._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_12_a77477951576fc657d693811f11f9975._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_13_c3ef67bded8ed3c511a8ea85b8bd81a5._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_1_97cf233d8401d642337d5fe9dd525e2b._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_2_4981a0a894b77e94a3bffec82b0f6e51._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_3_dbe960392aaa0839886381820754814a._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_4_cdf9621fe3e9f8eb8b7af88f779a7116._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_5_a2318f094b30f58fefc072807896c099._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_6_7c2f1d914793798708ca13b6ac3dd474._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_7_a24b5165590b5d58919da1003cd20c54._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_8_71ed14b8e5a898b1643d5e37591c2476._comment
 create mode 100644 doc/bugs/Bootstrap3_icons_missing_on_Android/comment_9_15357e33c2431080d45f7cef5f4f1209._comment
 create mode 100644 doc/bugs/Broken_symlinks_in_directory_remote_causes_crash.mdwn
 create mode 100644 doc/bugs/Button_to_cancel_conistency_checks.mdwn
 create mode 100644 doc/bugs/CHECKPRESENT_could_check_file_size_as_well.mdwn
 create mode 100644 doc/bugs/CHECKPRESENT_could_check_file_size_as_well/comment_1_7bbba896da745a8a6b69ec62bf71fc89._comment
 create mode 100644 doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive.mdwn
 create mode 100644 doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_1_a9501e2f347b957e7dc53a06fe59cff4._comment
 create mode 100644 doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_2_e4cac0d18fd6cde1084e93d0fe997f40._comment
 create mode 100644 doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_3_a3a702176a316d6b599eb2a149a293ad._comment
 create mode 100644 doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_4_82103077cde68c3b6a70dcf70c4ed837._comment
 create mode 100644 doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_5_c22f9e3c5e438b2cc05008bc3f91b7fc._comment
 create mode 100644 doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X.mdwn
 create mode 100644 doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_1_5d23b1f02c6a0db0b43939210c427994._comment
 create mode 100644 doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_2_6ede677f8113fcd6215ecd68de237f06._comment
 create mode 100644 doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_3_3377120e8e246f5ec74d372015590a6c._comment
 create mode 100644 doc/bugs/Cannot_add_gcrypt_remote_in_webapp__58___gcrypt_backend.mdwn
 create mode 100644 doc/bugs/Cannot_clone_an_annex.mdwn
 create mode 100644 doc/bugs/Cannot_clone_an_annex/comment_1_b40a2652361a79c6c6eab0fc21be8e46._comment
 create mode 100644 doc/bugs/Cannot_delete_remote_when_ssh_sync_fails.mdwn
 create mode 100644 doc/bugs/Cannot_delete_remote_when_ssh_sync_fails/comment_1_3c8e8fae688a9db8e18e869a187fb4eb._comment
 create mode 100644 doc/bugs/Cannot_delete_remote_when_ssh_sync_fails/comment_2_e189617c4ac23df50f02af8c517fa399._comment
 create mode 100644 doc/bugs/Cannot_delete_remote_when_ssh_sync_fails/comment_3_35a08daa2776c648d5ee010b77e72bd4._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX.mdwn
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_10_ec80bdff87c7b70e4235cd5b2ba6ed05._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_11_82e32aca2c23a1e27553bcd9708870b2._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_12_4e0746d00d8a596d878c1fe12ec68849._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_13_80ba2e4241372ff3ce1505900e17c22f._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_14_08f3c3d26d13fd44ae9c26791b90a8fc._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_15_38a0eafe91e05a7784dd5e305f38a8f3._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_16_ee529ac7b3d27f1cdc7edf5154c0da8f._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_17_d60adea3f0c0030a403c33c57f27abda._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_18_594ae4ce426c7fd9963a22def58904d8._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_19_bdc211b026d3b05de127f6ed5a3d19b0._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_1_1541a9323009b20f527501ebedc9d395._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_2_c06017f123f1ee34c7310f923086d09a._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_3_c03b45321728155eae9470cd8bb2cc93._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_4_bb6972e9870a68a98d90c6847228ab31._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_5_da9812dd37de7bba4fe2b1785bdca1ae._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_6_bc8154b171c460b4590d2b32401f24a2._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_7_20febad4aa06d5b39668a858d2b118b1._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_8_84d31b8fdde0f0ab0355a5d30760e90d._comment
 create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_9_17a75fa68bf3718230d1d523b7eb0250._comment
 create mode 100644 doc/bugs/Cloned_from_.git_under_Windows__44___get_fails.mdwn
 create mode 100644 doc/bugs/Cloned_from_.git_under_Windows__44___get_fails/comment_1_0d619c1a4c9645a6b76619b05b3d518c._comment
 create mode 100644 doc/bugs/Cloned_from_.git_under_Windows__44___get_fails/comment_2_0bc5932c037002dac6b096f97d12584c._comment
 create mode 100644 doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_.mdwn
 create mode 100644 doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_1_81a4647a9b51bed8c230a2a16990915d._comment
 create mode 100644 doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_2_f8e97dded9ba6d2305de1278025924fe._comment
 create mode 100644 doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_3_eb34061429cb8c7d0b155825e84b657b._comment
 create mode 100644 doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_4_8cf5dc85a94c60b9c88c8e8354f19772._comment
 create mode 100644 doc/bugs/Continual_space_exhaustion_from_syncing_metadata.mdwn
 create mode 100644 doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_1_93e3deab54b34e9ad608fd549119e221._comment
 create mode 100644 doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_2_9401be5e6af886edadaf3ad7ba6a071d._comment
 create mode 100644 doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_3_3309c51dbd251cc46a25557a0d25e946._comment
 create mode 100644 doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow.mdwn
 create mode 100644 doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_1_d81f94dfdb1b15b8bc0d9c243ef748db._comment
 create mode 100644 doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_2_0f5ff10d84450a6df35cb974cdb4739e._comment
 create mode 100644 doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_3_7150178b47a15857d5eece0fbe57a971._comment
 create mode 100644 doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_4_d2896b544d6d26663b532735c3924134._comment
 create mode 100644 doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant.mdwn
 create mode 100644 doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_1_f2102da5822a35e1600d67326954e059._comment
 create mode 100644 doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_2_656986cdc4831a8d2f80432acaf8a884._comment
 create mode 100644 doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_3_fa94d1b008a6c1663e40854edcd5504d._comment
 create mode 100644 doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_4_5a26a33c34594ec6eb50bd675d68801a._comment
 create mode 100644 doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_5_81e2f37e7adbd8f24734b67a1dd209f9._comment
 create mode 100644 doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_6_f0999dbd00e06ab2cbf68b58527c2b9b._comment
 create mode 100644 doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too.mdwn
 create mode 100644 doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_1_80ca50f5305eda71fe32f2b0bc922c34._comment
 create mode 100644 doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_2_e6bc6d1c0eb8c469e9e00b37bbcc9b86._comment
 create mode 100644 doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_5_0d0f6b6b46d0153433fead2bbd1bbe64._comment
 create mode 100644 doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_5_6058a22b733cb02126286af950074ed4._comment
 create mode 100644 doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_6_593a49669e2fadfb91773f8c84fbb031._comment
 create mode 100644 doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_6_5a348c5f327f16e1192ef6bd7f2880bb._comment
 create mode 100644 doc/bugs/Corrupted_git___40__but_not_annex__41___controlled_files.mdwn
 create mode 100644 doc/bugs/Corrupted_git___40__but_not_annex__41___controlled_files/comment_1_48f15b40bf3a7cd3beb7cabd4e706337._comment
 create mode 100644 doc/bugs/Could_not_read_from_remote_repository.mdwn
 create mode 100644 doc/bugs/Could_not_read_from_remote_repository/comment_1_da842a9d146bcd5c7773b58364c25597._comment
 create mode 100644 doc/bugs/Could_not_read_from_remote_repository/comment_2_82746a0cf989d884cd0fd796db092b3c._comment
 create mode 100644 doc/bugs/Could_not_read_from_remote_repository/comment_3_95d16045dc238dba19a98808de2eeedf._comment
 create mode 100644 doc/bugs/Crash_when_disabling_syncing_in_the_webapp.mdwn
 create mode 100644 doc/bugs/Crash_when_disabling_syncing_in_the_webapp/comment_1_e25dd80370820782f9c6a877101d8703._comment
 create mode 100644 doc/bugs/Crash_when_disabling_syncing_in_the_webapp/comment_2_4031c16362137747717e9595cb5c8a15._comment
 create mode 100644 doc/bugs/Crash_when_disabling_syncing_in_the_webapp/comment_3_0667f39f60bdaba6670f5b8304a8a77c._comment
 create mode 100644 doc/bugs/Creating_an_encrypted_S3_does_not_check_for_presence_of_GPG.mdwn
 create mode 100644 doc/bugs/Data_loss_when_copying_files_with_running_assistant.mdwn
 create mode 100644 doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_1_51e7afb030dfb3052044b0fa95e08bed._comment
 create mode 100644 doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_2_b9cc9ae227a6dd883a2324b6d70b88ad._comment
 create mode 100644 doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_3_15f4fc02d574a2ed55e683dd99e9b72c._comment
 create mode 100644 doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_4_c16ecf8fabd0c63a7b59927fe0bb6e2c._comment
 create mode 100644 doc/bugs/Deasn__39__t_clean_up_ssh_keys_after_removing_remote_repo.mdwn
 create mode 100644 doc/bugs/Deasn__39__t_clean_up_ssh_keys_after_removing_remote_repo/comment_1_88fbf70eae48484988dbb433a437c717._comment
 create mode 100644 doc/bugs/Debian_and_MacOSX_cannot_read_eachother__39__s_S3_credentials.mdwn
 create mode 100644 doc/bugs/Debian_and_MacOSX_cannot_read_eachother__39__s_S3_credentials/comment_1_e307e5d0ec02ed76dc7c3f0894770539._comment
 create mode 100644 doc/bugs/Delete_data__47__update_location_log_when_a_special_remote_fails_to_fsck.mdwn
 create mode 100644 doc/bugs/Delete_data__47__update_location_log_when_a_special_remote_fails_to_fsck/comment_1_203ebe6fa1bb8d3c6e7c0b948fc7dd6b._comment
 create mode 100644 doc/bugs/Direct_mode_repositories_still_use_symlinks_sometimes.mdwn
 create mode 100644 doc/bugs/Directory_remotes_with_same_mount_point.mdwn
 create mode 100644 doc/bugs/Directory_remotes_with_same_mount_point/comment_1_351063bf8fb7779a9a7ecd21bef8b801._comment
 create mode 100644 doc/bugs/Directory_remotes_with_same_mount_point/comment_2_90351193c14f4c68f9b92640dae82f13._comment
 create mode 100644 doc/bugs/Directory_remotes_with_same_mount_point/comment_3_6b7727db8e2487394a80fc061d76868e._comment
 create mode 100644 doc/bugs/Directory_remotes_with_same_mount_point/comment_4_5a4b3daa0f8a0d7f330f5a1d922d0f6a._comment
 create mode 100644 doc/bugs/Directory_remotes_with_same_mount_point/comment_5_fb21865b36819a54a23e1ccb7f377fa1._comment
 create mode 100644 doc/bugs/Disabling_remote_auto-enabling_not_possible.mdwn
 create mode 100644 doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_1_136c0fa106347bd0474f8298fde227f5._comment
 create mode 100644 doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_2_f6b1d513e664d1a5ee51b90f49731eeb._comment
 create mode 100644 doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_3_c2c7144fa74bdc455e1bd36b594902c1._comment
 create mode 100644 doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_4_4f3e9f15fcc96cd98c6915ec68cc471f._comment
 create mode 100644 doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_5_ccb5b6960da43a93ff0b7404190c51de._comment
 create mode 100644 doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_6_5b6359663efb608b9a78ab17c02be9ee._comment
 create mode 100644 doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_7_995b88efc83f76f14ccb22bc2a6ef4bd._comment
 create mode 100644 doc/bugs/Dropping_filename_extensions_with_more_than_4_char.mdwn
 create mode 100644 doc/bugs/Dropping_filename_extensions_with_more_than_4_char/comment_1_ecc9ff2bca0638797f358d5ff0d9e363._comment
 create mode 100644 doc/bugs/Duplicate_descriptions_cause_confusing_error.mdwn
 create mode 100644 doc/bugs/Empty_files_make_git_status_slow.mdwn
 create mode 100644 doc/bugs/Empty_files_make_git_status_slow/comment_1_67662686361d345b3b82d1c80adc2452._comment
 create mode 100644 doc/bugs/Empty_files_make_git_status_slow/comment_2_39876be38934e9056e9aa2a9fcdeaedf._comment
 create mode 100644 doc/bugs/Empty_files_make_git_status_slow/comment_3_17b400bc03eb176f63009b9e01a862f4._comment
 create mode 100644 doc/bugs/Empty_files_make_git_status_slow/comment_4_d3a05649e8d7d5d62cc3e80ce0f45fe4._comment
 create mode 100644 doc/bugs/Empty_files_make_git_status_slow/comment_5_e2c9b041388685bb2ada57244c1735fd._comment
 create mode 100644 doc/bugs/Empty_files_make_git_status_slow/comment_6_d107491ed7ac97c4732dc96707defaf0._comment
 create mode 100644 doc/bugs/Empty_folders_don__39__t_get_remove.mdwn
 create mode 100644 doc/bugs/Empty_folders_don__39__t_get_remove/comment_1_9f41638299c214b2ee13f23ab41349da._comment
 create mode 100644 doc/bugs/Empty_folders_don__39__t_get_remove/comment_2_35f59adc30fe743221f29bbfecff639b._comment
 create mode 100644 doc/bugs/Empty_folders_don__39__t_get_remove/comment_3_ccc703f8667805ce2886719c57e76ef8._comment
 create mode 100644 doc/bugs/Enable__47__paus_syncing_to_remote_ssh_server_with_multiple_directories.mdwn
 create mode 100644 doc/bugs/Enable__47__paus_syncing_to_remote_ssh_server_with_multiple_directories/comment_1_e8affeca873c2ef73255f8f77e0ac16f._comment
 create mode 100644 doc/bugs/Enabling_useConfigOnly_not_honored.mdwn
 create mode 100644 doc/bugs/Enabling_useConfigOnly_not_honored/comment_1_4f0e4da06d8c9a9db771e593be1e2608._comment
 create mode 100644 doc/bugs/Enabling_useConfigOnly_not_honored/comment_2_5dede8445ba1c20e9750a30fe29de0b0._comment
 create mode 100644 doc/bugs/Encoding_error_in_webapp.mdwn
 create mode 100644 doc/bugs/EvilLinker_needs_to_escape_spaces_in_user_name.mdwn
 create mode 100644 doc/bugs/EvilLinker_needs_to_escape_spaces_in_user_name/comment_1_6b289221a65a750444b1b5850df3386c._comment
 create mode 100644 doc/bugs/FTBFS_for_the_2nd_day.mdwn
 create mode 100644 doc/bugs/FTBFS_for_the_2nd_day/comment_1_b7278de8f98c9fd96219281d61284461._comment
 create mode 100644 doc/bugs/FTBFS_for_the_2nd_day/comment_2_05c93396766cb9ac6a596db679519718._comment
 create mode 100644 doc/bugs/FTBFS_for_the_2nd_day/comment_3_0037f0e43383f32b22ee1ba2c98d78f8._comment
 create mode 100644 doc/bugs/FTBFS_on_OSX__47__Windows.mdwn
 create mode 100644 doc/bugs/FTBFS_on_OSX__47__Windows/comment_1_04e4ec83077eec6af8ce50d6f1b2c71e._comment
 create mode 100644 doc/bugs/FTBFS_since_yesterday_on_linux.mdwn
 create mode 100644 doc/bugs/Failed_adjusted_branch_update_after_error_in_drop.mdwn
 create mode 100644 doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_1_08b3eafdabe5f60ec2206584dff5d230._comment
 create mode 100644 doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_2_a947f8afde3d7f63fd33b0b7e5998e43._comment
 create mode 100644 doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_3_c8ce6c9fc35fa6ad5165ecf9a3592c9d._comment
 create mode 100644 doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_4_2a4de8981ced7894148ca9a68e5ef60b._comment
 create mode 100644 doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_5_7b989f777b211f21ca0e9ca681869bff._comment
 create mode 100644 doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_6_f9ef22fcfabc6445060b964f08080c76._comment
 create mode 100644 doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_7_f679af07b798cb4bfae75565dd46e8ed._comment
 create mode 100644 doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_8_c7c210961b51a87770932f40a9563622._comment
 create mode 100644 doc/bugs/Failed_move__47__get_over_ssh_in_new_version.mdwn
 create mode 100644 doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_1_13252610f5b05251d1dcdf81f295ae7c._comment
 create mode 100644 doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_2_ae1807997fe2098f8534d23130039ae4._comment
 create mode 100644 doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_3_fcb4b6a62bcee4d2f70c58fb7f270b7a._comment
 create mode 100644 doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_4_f2fe8462292a4e80b5df4adeac20ee72._comment
 create mode 100644 doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_5_a769702d5d203eb435677bbd423857a6._comment
 create mode 100644 doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_6_8b18048e0ba4341ecef60787855cdac3._comment
 create mode 100644 doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_7_5c8ac4f42293240cacfb2edceada1a0b._comment
 create mode 100644 doc/bugs/Fails_to_connect_to_newly_added_remote_on_Windows.mdwn
 create mode 100644 doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__.mdwn
 create mode 100644 doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__/comment_1_fdad38ba9decc434e0d04a446f0a02e5._comment
 create mode 100644 doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__/comment_2_cdedb5512dc9c27a88632e963a27a389._comment
 create mode 100644 doc/bugs/Failure_to_get_small_files_over_P2P_protocol.mdwn
 create mode 100644 doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_1_72a8b9b6ed582dad36301cb9beece2f8._comment
 create mode 100644 doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_2_53970994816f1de9816e3496fdf0ef71._comment
 create mode 100644 doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_3_4c359c12d5c61351484dfcb2f5547222._comment
 create mode 100644 doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_4_1e286c1506fc542df85c6158a8ec3d1c._comment
 create mode 100644 doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_5_c667e4d4899925a5484c94256044f6ee._comment
 create mode 100644 doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_6_5ed6591954aeafe6c99ae152f4f4ad67._comment
 create mode 100644 doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_7_247db3d1c03b207296e97975a3554756._comment
 create mode 100644 doc/bugs/Files_disappear_from_locally_paired_annexes_when_edited.mdwn
 create mode 100644 doc/bugs/Files_disappear_from_locally_paired_annexes_when_edited/comment_1_bdc97db9dc9954331e4c400baf9e5541._comment
 create mode 100644 doc/bugs/Files_recorded_with_other_file__39__s_checksums.mdwn
 create mode 100644 doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_1_05e3e33e1ca2361546dbe08c6bd476d6._comment
 create mode 100644 doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_2_0735ed4187e23ddea6bd0aa408451942._comment
 create mode 100644 doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_3_06b7be9e651e528440a054ef43f7142f._comment
 create mode 100644 doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_4_bc9cf721f8087cb91954cc2435376bc2._comment
 create mode 100644 doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_5_8f0bbd819b95dfa97e2f4848e08a787a._comment
 create mode 100644 doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_6_17a0864cec6f28a0445998f3c5fc7f10._comment
 create mode 100644 doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_7_d480e85683f0418441f26c7d61c4af02._comment
 create mode 100644 doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_8_80763c1c40acdf0915134182d15e4fd8._comment
 create mode 100644 doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_9_7c3180616e40b49fc5ddf398d23d0201._comment
 create mode 100644 doc/bugs/Files_unaccessible_in___40__some__63____41___views_on_a_crippled_filesystem.mdwn
 create mode 100644 doc/bugs/FreeBSD_patches.mdwn
 create mode 100644 doc/bugs/FreeBSD_patches/comment_1_3473c3d4207a8387d962366dd1aa88b1._comment
 create mode 100644 doc/bugs/FreeBSD_patches/comment_2_ba8df081ebf5cbbb5561aa48343e4fcd._comment
 create mode 100644 doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos.mdwn
 create mode 100644 doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_1_8a27545e11b3d9e4e45aea4c9a5c9af4._comment
 create mode 100644 doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_2_3e2f01eaaf717710a08ba092856af193._comment
 create mode 100644 doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_3_07460def4969896c87e8696955740fa9._comment
 create mode 100644 doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_4_f97de485f97d8016a5ab4e276799d230._comment
 create mode 100644 doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_5_cf4130cb932d3d884e605d7c6447e61e._comment
 create mode 100644 doc/bugs/GPG_passphrase_repeated_prompt.mdwn
 create mode 100644 doc/bugs/GPG_passphrase_repeated_prompt/comment_1_6ef1c9725befc84ad57bce196ef630ef._comment
 create mode 100644 doc/bugs/Get_crashes_when_remote_contains_non-english_chars.mdwn
 create mode 100644 doc/bugs/Get_gpg_subkey_id_used_for_encryption.mdwn
 create mode 100644 doc/bugs/Get_gpg_subkey_id_used_for_encryption/comment_1_2cbdc33f22d18b8ea25473d361e591eb._comment
 create mode 100644 doc/bugs/Get_gpg_subkey_id_used_for_encryption/comment_2_81f2725bf6cfbef43cd9253a61eb7cfa._comment
 create mode 100644 doc/bugs/Get_gpg_subkey_id_used_for_encryption/comment_3_efae569e57322f263f626e330c64aac5._comment
 create mode 100644 doc/bugs/Git-annex_and_Microsoft_Office_files_on_OS_X.mdwn
 create mode 100644 doc/bugs/Git-annex_and_Microsoft_Office_files_on_OS_X/comment_1_0cf11096ceeb6cf93db5609a42a70641._comment
 create mode 100644 doc/bugs/Git_checkout_fails_using_--recurse-submodules.mdwn
 create mode 100644 doc/bugs/Git_checkout_fails_using_--recurse-submodules/comment_1_571703fc4e1e2f4e34f54db7a7da7080._comment
 create mode 100644 doc/bugs/Git_checkout_fails_using_--recurse-submodules/comment_2_9fe6b56ffda6d0c77ce65786514cd79d._comment
 create mode 100644 doc/bugs/Git_checkout_fails_using_--recurse-submodules/comment_3_fce2467a0442f98194fa11caffa466ad._comment
 create mode 100644 doc/bugs/Git_copy_fails_with_absolute_path_on_mavericks.mdwn
 create mode 100644 doc/bugs/Git_copy_fails_with_absolute_path_on_mavericks/comment_1_2f0c74aba502533b85b922ea81ded70d._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves.mdwn
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_10_74e6d17a1b14b2fdc7eddf4ee1895733._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_11_d1f454482feef0350a6fa61bdf7673cc._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_12_5a13945d6bec6fa5fac84555f7ef8e21._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_13_6715bc3370f115f90627cfc4b06cf0e8._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_14_6234b04455acc0b2b2f22a1d8c2ab475._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_16_586e591a1e3cc53fd0108da91492c5c2._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_16_7a1cdfba17f129f6bf87a71549bbaab6._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_17_faaa433ba8df649771469fdbcd9bb69e._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_18_238bbbcabd626c33acc14f930a7d536c._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_1_c7fbc3da4404fb33a4b0babf068dc4d3._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_2_f2368358a0ccdd36a551a2c833cb9c9a._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_3_f7d921256107773dcb294747cdc38ebd._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_4_cf152fccbdb281dcbeb02cb398686ac0._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_5_652928a8f8bd0250973f19fa28cbb029._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_6_315606cfa07d2c4b20a6c9ec477c83d1._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_7_54aed251ddb9df1c8164a25240e1533f._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_8_a1131917149dd07ec73367e7cbc3b3f2._comment
 create mode 100644 doc/bugs/Git_repos_corrupt_themselves/comment_9_033def91d2a30f1cee498fabbfe5d37f._comment
 create mode 100644 doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time.mdwn
 create mode 100644 doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_1_e8bb3d6a2318402b985caed08282d473._comment
 create mode 100644 doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_2_ead9fa75a12ef36be9a92637b144e74f._comment
 create mode 100644 doc/bugs/Hard_links_not_synced_in_direct_mode.mdwn
 create mode 100644 doc/bugs/Hard_links_not_synced_in_direct_mode/comment_1_aaa781664ae0c62c4f6530cb075ed367._comment
 create mode 100644 doc/bugs/Hard_links_not_synced_in_direct_mode/comment_2_213aa10909d1fd0f20ed078a7ed93e79._comment
 create mode 100644 doc/bugs/Hard_links_not_synced_in_direct_mode/comment_3_e6b783d9aaae20c0d35e9888d878716a._comment
 create mode 100644 doc/bugs/Hard_links_not_synced_in_direct_mode/comment_4_b008ae7b1cf8685d92c9a87a7609de1e._comment
 create mode 100644 doc/bugs/Hard_links_not_synced_in_direct_mode/comment_5_949c891209713a2c0a5e66af11ed4c79._comment
 create mode 100644 doc/bugs/Hard_links_not_synced_in_direct_mode/comment_6_12379a8e89ce8505123f5b24f3dbbaca._comment
 create mode 100644 doc/bugs/Homebrew_build_broken.mdwn
 create mode 100644 doc/bugs/Homebrew_build_broken/comment_1_c30517144c98faaf592b0e8e2bcc7db4._comment
 create mode 100644 doc/bugs/Homebrew_build_broken/comment_2_d3f253a12a77fe4a354144880d0a4935._comment
 create mode 100644 doc/bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo.mdwn
 create mode 100644 doc/bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo/comment_1_a7a613c3fa1bee42442a446366027381._comment
 create mode 100644 doc/bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo/comment_2_97bf976e0e04fb27916e245eb9c7709d._comment
 create mode 100644 doc/bugs/How_to_git_union-merge__63__.mdwn
 create mode 100644 doc/bugs/How_to_git_union-merge__63__/comment_1_58b6c9712d7c209248d9ef87bcc0e110._comment
 create mode 100644 doc/bugs/How_to_git_union-merge__63__/comment_2_22701b82e8d53acff66ddea5bf9448bf._comment
 create mode 100644 doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files.mdwn
 create mode 100644 doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_1_bbc1e7205d7701afd405c6e62a1c0aa3._comment
 create mode 100644 doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_2_52a1800537f1244ad6cf417c5f25ebe0._comment
 create mode 100644 doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_3_414bd487619e46b25e8d9a57d9aef1f6._comment
 create mode 100644 doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_4_81abd2627672911ba6367effbf5c487b._comment
 create mode 100644 doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_5_ce0342e38a87017ad58c9a79b17d759a._comment
 create mode 100644 doc/bugs/Impossible_to_enable_an_existing_gcrypt_repo_in_the_webapp.mdwn
 create mode 100644 doc/bugs/Impossible_to_enable_an_existing_gcrypt_repo_in_the_webapp/comment_1_17814787e333d15da3ab4e57c7d31d4b._comment
 create mode 100644 doc/bugs/Incompatibility_with_git_2.37.mdwn
 create mode 100644 doc/bugs/Incompatibility_with_git_2.37/comment_1_c24657bb9d3b3072698572c4e75ccb5d._comment
 create mode 100644 doc/bugs/Incompatibility_with_git_2.37/comment_2_4d5eb77736e8512affc25e7bdd5190f1._comment
 create mode 100644 doc/bugs/Incompatibility_with_git_2.37/comment_3_889ece8b2168b20019253ab6dd5b0e48._comment
 create mode 100644 doc/bugs/Incompatibility_with_git_2.37/comment_4_95b8ea35cd10ac80e1d01b658e24d7a9._comment
 create mode 100644 doc/bugs/Incompatibility_with_git_2.37/comment_5_d0e60d224dd48d7c31adb6b250f662df._comment
 create mode 100644 doc/bugs/Incompatibility_with_git_2.37/comment_6_3bb6424838d4f8a971f3dce6d1b8dbfb._comment
 create mode 100644 doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates.mdwn
 create mode 100644 doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_1_b9491e9cb432ca3b8bdb08a00c89b346._comment
 create mode 100644 doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_2_cf9ce09377da2eae63ff41d07cb222d7._comment
 create mode 100644 doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_3_a99df351ed700f908b6aaf3f52d245b4._comment
 create mode 100644 doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_4_d370abe891d554577a9af7f959c9e3f0._comment
 create mode 100644 doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_5_68a3936700a02a17d0379d96880eea15._comment
 create mode 100644 doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_6_4d05a896fd57b55388fb21638ed02233._comment
 create mode 100644 doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_7_4a1248ea257c04f1afe233891a606eea._comment
 create mode 100644 doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_8_37eb9d35191bcfc0e7e4496f5720cbed._comment
 create mode 100644 doc/bugs/Infinite_loop_when_synchronizing_between_many_machines.mdwn
 create mode 100644 doc/bugs/Infinite_loop_when_synchronizing_between_many_machines/comment_1_6d8f42446749f3e697af20626f22cf8b._comment
 create mode 100644 doc/bugs/Infinite_loop_when_synchronizing_between_many_machines/comment_2_3b4e529564488e732dd62569247b3d56._comment
 create mode 100644 doc/bugs/Initial___34__Make_repository__34___fails_due_to___34__empty_ident_name___40__for___60__email-address__62____41___not_allowed__34__.mdwn
 create mode 100644 doc/bugs/Initial___34__Make_repository__34___fails_due_to___34__empty_ident_name___40__for___60__email-address__62____41___not_allowed__34__/comment_1_267b252368dca4803d706c70a3ef3244._comment
 create mode 100644 doc/bugs/Installing_git-annex_on_macOS_10.13_HighSierra_via_brew_install_git-annex_require_to_install_lib_magic_via_the_command_brew_install_lib_magic.mdwn
 create mode 100644 doc/bugs/Installing_git-annex_on_macOS_10.13_HighSierra_via_brew_install_git-annex_require_to_install_lib_magic_via_the_command_brew_install_lib_magic/comment_1_43614460d92cfac8a40ad2d6654926b9._comment
 create mode 100644 doc/bugs/Invalid_argument_saving_FreeSurfer_file_on_NTFS.mdwn
 create mode 100644 doc/bugs/Invalid_argument_saving_FreeSurfer_file_on_NTFS/comment_1_181a319138cc10742bc8676d77e8a614._comment
 create mode 100644 doc/bugs/Invalid_option___96__--time-limit__61__1m__39___with_pull.mdwn
 create mode 100644 doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__.mdwn
 create mode 100644 doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__/comment_1_ef97e735ce308f7bcc03f5d9fda588bf._comment
 create mode 100644 doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__/comment_2_539b89de8743e435386b86119d1e982f._comment
 create mode 100644 doc/bugs/Issue_fewer_S3_GET_requests.mdwn
 create mode 100644 doc/bugs/Issue_fewer_S3_GET_requests/comment_1_59a6b87d01c003bf55cde4c882e1778c._comment
 create mode 100644 doc/bugs/Issue_fewer_S3_GET_requests/comment_2_8fdeb3352ac00a76625ec9c007e5b76a._comment
 create mode 100644 doc/bugs/Issue_fewer_S3_GET_requests/comment_3_6ccbb1cff7bc6b4640220d98f7ce21c3._comment
 create mode 100644 doc/bugs/Issue_on_OSX_with_some_system_limits.mdwn
 create mode 100644 doc/bugs/Issue_on_OSX_with_some_system_limits/comment_1_5fc1eedb5231edc37c87a2d9b91313b9._comment
 create mode 100644 doc/bugs/Issue_on_OSX_with_some_system_limits/comment_2_b14e697c211843163285aaa8de5bf4c6._comment
 create mode 100644 doc/bugs/Issue_on_OSX_with_some_system_limits/comment_3_18ddf8b5934dd6fb1676cd6adc7d103b._comment
 create mode 100644 doc/bugs/Issue_on_OSX_with_some_system_limits/comment_4_c25a8eb369e546f65e1a72d89f43066f._comment
 create mode 100644 doc/bugs/Issue_on_OSX_with_some_system_limits/comment_5_6407a3e7aa0316cba2994bfef0e3c633._comment
 create mode 100644 doc/bugs/Issue_on_OSX_with_some_system_limits/comment_6_f01887695e8b8386e125464c6d401565._comment
 create mode 100644 doc/bugs/Issue_on_OSX_with_some_system_limits/comment_7_c7776d5b2d073e0d2ae36515185c25aa._comment
 create mode 100644 doc/bugs/It_is_very_easy_to_turn_git-annex_into_a_zombie.mdwn
 create mode 100644 doc/bugs/It_is_very_easy_to_turn_git-annex_into_a_zombie/comment_1_d5fba6c061fb21795021ea83070dbfa2._comment
 create mode 100644 doc/bugs/It_is_very_easy_to_turn_git-annex_into_a_zombie/comment_2_12cba707239018989e8d5b6f456fa754._comment
 create mode 100644 doc/bugs/J1_display_issue.mdwn
 create mode 100644 doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8.mdwn
 create mode 100644 doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8/comment_1_1765400777911cc61eb591b76c84ae89._comment
 create mode 100644 doc/bugs/Local_network___40__ssh__41___fails_to_pair__47__sync.mdwn
 create mode 100644 doc/bugs/Local_network___40__ssh__41___fails_to_pair__47__sync/comment_1_bab9cd5bdcffec3c48b9e8657cd9bbf7._comment
 create mode 100644 doc/bugs/Local_network___40__ssh__41___fails_to_pair__47__sync/comment_2_104898dce3c67c082a9f2b36e2f45ff8._comment
 create mode 100644 doc/bugs/Location_change_of_remote_DNS_ignored.mdwn
 create mode 100644 doc/bugs/Location_change_of_remote_DNS_ignored/comment_1_449bfb3a594f99cf5e71a6e18d6d3dbc._comment
 create mode 100644 doc/bugs/Location_change_of_remote_DNS_ignored/comment_2_b097dec73d4965f62c61003ed27e4209._comment
 create mode 100644 doc/bugs/Low_disk_space_corrupts_state.mdwn
 create mode 100644 doc/bugs/Low_disk_space_corrupts_state/comment_1_d8235498e2206c3b5284455e5c4182b9._comment
 create mode 100644 doc/bugs/Low_disk_space_corrupts_state/comment_2_0e47c63a48e10ae760754df0ce165388._comment
 create mode 100644 doc/bugs/MacOSX__58___archive_folders_not_working_as_expected.mdwn
 create mode 100644 doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_1_c8ce2a1978fc1bfa5f31cff9f48690f6._comment
 create mode 100644 doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_2_cf9a679c7e6ec5cae4109e748b20b8f9._comment
 create mode 100644 doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_3_4026607087a9da2759f841e59aadfcdc._comment
 create mode 100644 doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_4_45c1e00e64f916ef8a5f9200144861eb._comment
 create mode 100644 doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_5_9501e259e7d813545ff9cfdac22748f6._comment
 create mode 100644 doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_6_6c42b7b4c53d2bd547d5ba8d2a3b4c9e._comment
 create mode 100644 doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_7_660bf8f60d340feca469cfd4e28b7e43._comment
 create mode 100644 doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_8_06c95f066ffc844b0e1e4b4c16d30da8._comment
 create mode 100644 doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_9_ab4b7a243f9d1dfddf1c2c2609863d99._comment
 create mode 100644 doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X.mdwn
 create mode 100644 doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_1_75c14b405929a8f771a7c261dcc4b7a2._comment
 create mode 100644 doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_2_f52483415c623ea0649c3805728ce761._comment
 create mode 100644 doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_3_fd73fbeef61df106f084ac235fca904a._comment
 create mode 100644 doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_4_c5e9843a956984efd22bad629930f6bd._comment
 create mode 100644 doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__.mdwn
 create mode 100644 doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_1_2a1c20b432dd839e0153827e151fbbc0._comment
 create mode 100644 doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_2_c227071f23a96ed9928f128e7f77e503._comment
 create mode 100644 doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_3_5ac676877feaa7cdb9e05d6b71b1a4c3._comment
 create mode 100644 doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_4_3853bebdfcb7dac647edefd6f55ba8d5._comment
 create mode 100644 doc/bugs/No_viable_build_plan_for_ghc_9.2.2.mdwn
 create mode 100644 doc/bugs/No_viable_build_plan_for_ghc_9.2.2/comment_1_8e7f9605f05880899eba7eae4e6f7ea0._comment
 create mode 100644 doc/bugs/No_viable_build_plan_for_ghc_9.2.2/comment_2_e30befdadfd7989de2e214b8e1f6ed07._comment
 create mode 100644 doc/bugs/No_way_to_merge_conflicts_while_on_adjusted_branch.mdwn
 create mode 100644 doc/bugs/No_way_to_merge_conflicts_while_on_adjusted_branch/comment_1_77c241c5d61b62b1fae552145c6c94ef._comment
 create mode 100644 doc/bugs/Non-annexed_files_being_annexed_and_not_stored.mdwn
 create mode 100644 doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_1_ef6c2dee191e80a46e348c78ba054fc2._comment
 create mode 100644 doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_2_6d73b11c55e7b2ed4003e1908558426d._comment
 create mode 100644 doc/bugs/OSX_Assistant_will_not_automatically_drop.mdwn
 create mode 100644 doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_1_9a3a594f983048a9035f385101b394cf._comment
 create mode 100644 doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_2_7901e1211ab86429ef8bd95c72ed89f5._comment
 create mode 100644 doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_3_1ba89b95a028ba4a84b22dfd983049fd._comment
 create mode 100644 doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_4_704ef9c0ed78a00030f7d4d151ecbe5b._comment
 create mode 100644 doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_5_47aa5de003b409d3d2a4c58a0f08a14a._comment
 create mode 100644 doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_6_69781b2f00afe6150bc5997335b8af90._comment
 create mode 100644 doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state.mdwn
 create mode 100644 doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_1_0dfd9eedccb48f1f3d7939677dc96446._comment
 create mode 100644 doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_2_5c5e7356cae8ddf8d2c8964fb69000f5._comment
 create mode 100644 doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_3_1e0841d71c33fd3919310f1711b6e0b4._comment
 create mode 100644 doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_4_eb5b0f8259d861000510fcfd58f66617._comment
 create mode 100644 doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_5_4343ee35e4091fc50268f9fc611f5148._comment
 create mode 100644 doc/bugs/OSX__58___Pushed_changes_are_autocommited.mdwn
 create mode 100644 doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_1_ff7fc340c34297beb913e8cba5af052b._comment
 create mode 100644 doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_2_fb72d7dc7b56c6166c557aa03b951eb1._comment
 create mode 100644 doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_3_8420ed892366eb78a874eec793eaa38d._comment
 create mode 100644 doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_4_5def2bf7430c4cba0c6ed154e75c967b._comment
 create mode 100644 doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_5_72c7566677b4c2f212bddeca49262181._comment
 create mode 100644 doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_6_13ad56d86b5bdbaaacdad5b31347551c._comment
 create mode 100644 doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass.mdwn
 create mode 100644 doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_10_3feba4ba84efb77bd4f8f46b6b4600f1._comment
 create mode 100644 doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_1_a33fcd088e419d8e6c459e42f21f8bbe._comment
 create mode 100644 doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_2_47196f7e781137751ebd1a1d7083838a._comment
 create mode 100644 doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_3_672d98ee06e051430f8e01faa93bb4cf._comment
 create mode 100644 doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_4_06fb3031b838cd443326f4ecd689b600._comment
 create mode 100644 doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_5_42d447400c15acf6ca031d165b2c781c._comment
 create mode 100644 doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_6_edd7d5d5c761ff665840f0ef7bea50c9._comment
 create mode 100644 doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_7_18e5334ab89efcf89ba8847436d55065._comment
 create mode 100644 doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_8_35b2bbdc24a7bd686527cd1839dee7d0._comment
 create mode 100644 doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_9_a771c6b453e6a4b3895dd69a53093440._comment
 create mode 100644 doc/bugs/OSX_case_insensitive_filesystem.mdwn
 create mode 100644 doc/bugs/OSX_case_insensitive_filesystem/comment_1_2e81165ac03e1d0566c81016e7728ee6._comment
 create mode 100644 doc/bugs/OSX_case_insensitive_filesystem/comment_2_4472d5db7a1cf7242077184912e32e17._comment
 create mode 100644 doc/bugs/OSX_case_insensitive_filesystem/comment_3_4be758c2b70c0aadfe4fc9ecff8e4522._comment
 create mode 100644 doc/bugs/OSX_case_insensitive_filesystem/comment_4_0b0c95a902718dd4e0976bf4e2cf265b._comment
 create mode 100644 doc/bugs/OSX_case_insensitive_filesystem/comment_5_2123944418123c3aaf187d34df5c11e0._comment
 create mode 100644 doc/bugs/OSX_case_insensitive_filesystem/comment_6_f82c803d725829722842c6d54e388719._comment
 create mode 100644 doc/bugs/OSX_case_insensitive_filesystem/comment_7_45e0178ce9598d086f34a89701536eb5._comment
 create mode 100644 doc/bugs/OSX_case_insensitive_filesystem/comment_8_3384bca070d84220efe166a398eed8a4._comment
 create mode 100644 doc/bugs/Offline_editing_in_Android_removes_files_and_creates_links.mdwn
 create mode 100644 doc/bugs/Offline_editing_in_Android_removes_files_and_creates_links/comment_1_a15eb9cd1a7bcdfa4b16459ef978a019._comment
 create mode 100644 doc/bugs/Offline_editing_in_Android_removes_files_and_creates_links/comment_2_1c061621f0abe435182d763cd871f405._comment
 create mode 100644 doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__.mdwn
 create mode 100644 doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_1_7508685b6f676c72e316642b80e40ee8._comment
 create mode 100644 doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_2_c4dd12ea578d1f07464e1b9d68ec96cf._comment
 create mode 100644 doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_3_8687c1d1c44d88a8ac13208273565d6c._comment
 create mode 100644 doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_4_62be3dd4092b15cdf85cf9a231b2863a._comment
 create mode 100644 doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_5_cca4905426a3e01da6e12be855c7a418._comment
 create mode 100644 doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_6_ae2ca07169321c4a51b7e8e581fda5e2._comment
 create mode 100644 doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_7_ae5c434a9c94aa000b604095f52e3d3c._comment
 create mode 100644 doc/bugs/On_Windows__44___can__39__t_use_a_USB_disk_annex_created_on_Linux.mdwn
 create mode 100644 doc/bugs/On_Windows__44___can__39__t_use_a_USB_disk_annex_created_on_Linux/comment_1_f224f4155d857a59595658357f97dac1._comment
 create mode 100644 doc/bugs/On_Windows__44___can__39__t_use_repository_that_has_a_unix-style_local_remote_configured.mdwn
 create mode 100644 doc/bugs/On_Windows__44___can__39__t_use_repository_that_has_a_unix-style_local_remote_configured/comment_1_95655915ff6ba9fb5d873358ff047496._comment
 create mode 100644 doc/bugs/One_Client_Not_Syncing_Content.mdwn
 create mode 100644 doc/bugs/One_Client_Not_Syncing_Content/comment_1_b8c8a9d10a12b72ea828b6b35d87fa5e._comment
 create mode 100644 doc/bugs/One_Client_Not_Syncing_Content/comment_2_59921abb184bffb5ac1656cc50054e11._comment
 create mode 100644 doc/bugs/Option_--from-anywhere_not_recognized_in_copy.mdwn
 create mode 100644 doc/bugs/Option_--from-anywhere_not_recognized_in_copy/comment_1_92bb18a7a50cf3dcbca75f544d7a0acf._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant.mdwn
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_10_9d4fdddd7ab05de9dfa4cc90f1051ef5._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_11_bbd8b537e277d24df254ed058ad40e24._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_12_5090e41cf96dfe542d1d2326aebc556c._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_13_2bfa76c4083ff9c1d2a4adfe38ced2f0._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_14_2274479a1eef9ffc6a53ffb65e2c3511._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_15_e8deee63316c8af39d7cf0996d26ecba._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_16_2139bcb34591be137ff3da959f08bc76._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_17_7fcd45354f94756c34b2f3f912972c19._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_1_bf61defadd3be9bc867be961b3149be6._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_2_8a8ead857917e7b843f1bdfe07b5d52d._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_3_2432df64f920f3962b6ba02adaa9b61d._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_4_536fbc38a7f2e7ab42188b5a8700e2cf._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_5_f45d09939527be362c586ae1d470afe4._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_6_88178fa312f351a7667b3b2c48335b02._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_7_cd6a850119dd1aa0d9bb34c6d8fe560c._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_8_39139e25175ae265a4dc15f0b6b7b618._comment
 create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_9_16c004fe7c77cbbba113787ce6410c9e._comment
 create mode 100644 doc/bugs/Pairing_locally_shows__58_____34__bad_comment_in_ssh_public_key_ssh-rsa__34__.mdwn
 create mode 100644 doc/bugs/Paths_behind_relative_symlinks_in_repo_don__39__t_work.mdwn
 create mode 100644 doc/bugs/Paths_behind_relative_symlinks_in_repo_don__39__t_work/comment_1_d7ca8767953e1ec06740727a0eda4697._comment
 create mode 100644 doc/bugs/Paths_behind_relative_symlinks_in_repo_don__39__t_work/comment_2_c4e6ab98e88add01eefe545551b12929._comment
 create mode 100644 doc/bugs/Podcast_filename_encoding_breaks_Android_client.mdwn
 create mode 100644 doc/bugs/Podcast_filename_encoding_breaks_Android_client/comment_1_1bb8e3f3a3d190ed557302df8b8e0335._comment
 create mode 100644 doc/bugs/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted.mdwn
 create mode 100644 doc/bugs/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted/comment_1_093b92c3a751d32600958f34c3f2122d._comment
 create mode 100644 doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key.mdwn
 create mode 100644 doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key/comment_1_c8e7be58222afff2a4c1df60f657d2ed._comment
 create mode 100644 doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit/comment_1_720dbf9d959a0050a159713cd1386913._comment
 create mode 100644 doc/bugs/Push_to_special_remote_includes_unwanted_files.mdwn
 create mode 100644 doc/bugs/Push_to_special_remote_includes_unwanted_files/comment_1_a9d43aaca191a2ea464d13bcba6cd31d._comment
 create mode 100644 doc/bugs/Push_to_special_remote_includes_unwanted_files/comment_2_44143f10ac80a979513477fbac2637f3._comment
 create mode 100644 doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__.mdwn
 create mode 100644 doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__/comment_1_ab1e86667225a0174a4e19210778f97c._comment
 create mode 100644 doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__/comment_2_cc207e43757c44b4e749488b563fdc87._comment
 create mode 100644 doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__/comment_3_7cdef9cf264f1b11cef7cea3accf112a._comment
 create mode 100644 doc/bugs/Race_condition_between_watch__47__assistant_and_addurl.mdwn
 create mode 100644 doc/bugs/Race_condition_between_watch__47__assistant_and_addurl/comment_1_8f56b8661a600729d7a9d569e8a0ba70._comment
 create mode 100644 doc/bugs/Race_condition_between_watch__47__assistant_and_addurl/comment_2_46dc67bdcd174cd50ccc421ec56735ad._comment
 create mode 100644 doc/bugs/Race_condition_or_double-locking_with_pidlock.mdwn
 create mode 100644 doc/bugs/Race_condition_or_double-locking_with_pidlock/comment_1_bd92615c640ff017cd8a2ebfcc117a37._comment
 create mode 100644 doc/bugs/Race_condition_or_double-locking_with_pidlock/comment_2_6db20a7c8ddde72cba76240b3f7faddd._comment
 create mode 100644 doc/bugs/Recreating_remote_repository__39__s_annex.mdwn
 create mode 100644 doc/bugs/Recreating_remote_repository__39__s_annex/comment_1_9fffb1329a4a06111cf2afd8552aea62._comment
 create mode 100644 doc/bugs/Recreating_remote_repository__39__s_annex/comment_2_b7f5634e136294ea1a3d4ce6de58fc5d._comment
 create mode 100644 doc/bugs/Redundant_quote_in_the_filepath_with_rsync_remote.mdwn
 create mode 100644 doc/bugs/Redundant_quote_in_the_filepath_with_rsync_remote/comment_1_53d3e78c0fb4d4c398dd47498e6348aa._comment
 create mode 100644 doc/bugs/Remote_repositories_have_to_be_setup_encrypted.mdwn
 create mode 100644 doc/bugs/Remote_repositories_have_to_be_setup_encrypted/comment_1_95f73315657bc35a8d3ff9b4ba207af0._comment
 create mode 100644 doc/bugs/Remote_webapp_on_debian_stretch_not_responding.mdwn
 create mode 100644 doc/bugs/Remote_webapp_on_debian_stretch_not_responding/comment_1_e2a0d0f458d263eae15640f36d59f071._comment
 create mode 100644 doc/bugs/Renamed_special_remote_cannot_be_reactivated_by_the_webapp.mdwn
 create mode 100644 doc/bugs/Repo_manipulation_breaks_git-annex_drop_--all.mdwn
 create mode 100644 doc/bugs/Repo_manipulation_breaks_git-annex_drop_--all/comment_1_22fb9214e6e31d04b0ffe3266d26ea69._comment
 create mode 100644 doc/bugs/Repo_manipulation_breaks_git-annex_drop_--all/comment_2_fac648fb7550f0c3c433ce423e3ea7f6._comment
 create mode 100644 doc/bugs/Request_the_ability_to_specify_pull_commit_message.mdwn
 create mode 100644 doc/bugs/Request_the_ability_to_specify_pull_commit_message/comment_1_6d581ea36afab3829cd56d6d6b83c6f3._comment
 create mode 100644 doc/bugs/Request_the_ability_to_specify_pull_commit_message/comment_2_bdb4b0200ab9d7c15454a2f3fcae474c._comment
 create mode 100644 doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32.mdwn
 create mode 100644 doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_1_7fc0ffa7787353cf40fff0bc8da43c1d._comment
 create mode 100644 doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_2_0b96112c5d57886add62d79e7bf6044e._comment
 create mode 100644 doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_3_79cafc76eb23e54ff70c72c2f528e724._comment
 create mode 100644 doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_4_07f1b2eacf7e9e58809ee44fc1d6b574._comment
 create mode 100644 doc/bugs/Resolver_lts-19.33_still_causes_trouble_with_Win32.mdwn
 create mode 100644 doc/bugs/Resolver_lts-19.33_still_causes_trouble_with_Win32/comment_1_dcc2067ea1bc26510d013ca52096513f._comment
 create mode 100644 doc/bugs/Resource_exhausted.mdwn
 create mode 100644 doc/bugs/Resource_exhausted/comment_10_bccf9528ffe963154c92ce49762e7ea6._comment
 create mode 100644 doc/bugs/Resource_exhausted/comment_11_24ad3a76a25a787ac59e2c5270709e72._comment
 create mode 100644 doc/bugs/Resource_exhausted/comment_12_1943ff77f3bccf885229ecc10c82399d._comment
 create mode 100644 doc/bugs/Resource_exhausted/comment_13_c3cac0717232e04e89df62efa1db0870._comment
 create mode 100644 doc/bugs/Resource_exhausted/comment_1_a5ef7a62d4ed9365f9448520bb17e3b5._comment
 create mode 100644 doc/bugs/Resource_exhausted/comment_2_cdba2015e603f3c21f3e1697dd6fafcd._comment
 create mode 100644 doc/bugs/Resource_exhausted/comment_3_747d16d050fdcf69dd3d2bc5ca469a2e._comment
 create mode 100644 doc/bugs/Resource_exhausted/comment_4_1e9b74e60da57c3d5f08c1eb3801c1d2._comment
 create mode 100644 doc/bugs/Resource_exhausted/comment_5_f55d933bce77fd2185ebd0cc46fe57ec._comment
 create mode 100644 doc/bugs/Resource_exhausted/comment_6_26c98fca45b029a527f9684873db4be5._comment
 create mode 100644 doc/bugs/Resource_exhausted/comment_7_8bab413b472f900e04977db2bc3951b6._comment
 create mode 100644 doc/bugs/Resource_exhausted/comment_8_e9bec0b80179b1229b6af0979a21c727._comment
 create mode 100644 doc/bugs/Resource_exhausted/comment_9_419e24e0b91f569294ece28c42daa246._comment
 create mode 100644 doc/bugs/Resource_temporarily_unavailable_when_running_enableremote.mdwn
 create mode 100644 doc/bugs/Resource_temporarily_unavailable_when_running_enableremote/comment_1_14a5135c2e822129972feb570e453bc8._comment
 create mode 100644 doc/bugs/S3_ACL_deprecation.mdwn
 create mode 100644 doc/bugs/S3_ACL_deprecation/comment_1_07d0d382b88426180e77bac962306f44._comment
 create mode 100644 doc/bugs/S3_ACL_deprecation/comment_2_63b541a937cb34cc4c68504e00dc3fb8._comment
 create mode 100644 doc/bugs/S3_remote___8212___un-embedding_creds__63__.mdwn
 create mode 100644 doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_1_336e1c2a5c2a367cba0ad74896b3895b._comment
 create mode 100644 doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_2_282aaaed5e95e8062460f94ac3a68dea._comment
 create mode 100644 doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_3_07fb8558238285883d11d8805884bdae._comment
 create mode 100644 doc/bugs/S3_remote_errors_with_garage_endpoint.mdwn
 create mode 100644 doc/bugs/S3_remote_errors_with_garage_endpoint/comment_10_ea7a56193439eb63ad45074bd40f4ff5._comment
 create mode 100644 doc/bugs/S3_remote_errors_with_garage_endpoint/comment_1_1d5b499a0cea623aadebf7e3b7fd9752._comment
 create mode 100644 doc/bugs/S3_remote_errors_with_garage_endpoint/comment_2_ca7ffa315cfa49e028fe6ff2d5c3133b._comment
 create mode 100644 doc/bugs/S3_remote_errors_with_garage_endpoint/comment_3_ae9308a3bab8904dd0f501cbe2f09de0._comment
 create mode 100644 doc/bugs/S3_remote_errors_with_garage_endpoint/comment_4_f17018fbc7a8205a3ef0bdea74069fb9._comment
 create mode 100644 doc/bugs/S3_remote_errors_with_garage_endpoint/comment_5_fb7a448a2a4231b08277741805c12c76._comment
 create mode 100644 doc/bugs/S3_remote_errors_with_garage_endpoint/comment_6_513bdbb6595612432fd4f33bd8e4e737._comment
 create mode 100644 doc/bugs/S3_remote_errors_with_garage_endpoint/comment_7_131eb46d499d29b124c576653796e270._comment
 create mode 100644 doc/bugs/S3_remote_errors_with_garage_endpoint/comment_8_d8cdf46fb8de877ea167d14a055813e0._comment
 create mode 100644 doc/bugs/S3_remote_errors_with_garage_endpoint/comment_9_3d2033edcd49e62045339e341996fd28._comment
 create mode 100644 doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces.mdwn
 create mode 100644 doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces/comment_1_12fd9dfb47e157e1d38c5e88a543498b._comment
 create mode 100644 doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces/comment_2_3bbdf23c8a4a480f4f6b8e8a2f8ddecd._comment
 create mode 100644 doc/bugs/SQlite_failed_when_copying_to_remote_repository.mdwn
 create mode 100644 doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_1_4578b04c1cfc46849e9440f257f49303._comment
 create mode 100644 doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_2_a953d5506f30cf19fe97c6ece155b45e._comment
 create mode 100644 doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_3_5b2956522ce9c9cdc0c704e63efe8dac._comment
 create mode 100644 doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_4_3966cce3267fe134f5c9c6b05e1149b5._comment
 create mode 100644 doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_5_0c0aec23302afafffc0f69d1bd89ad8f._comment
 create mode 100644 doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_6_031f049fdc2c284303e9db42071ebda7._comment
 create mode 100644 doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_7_3d4a7d330d80060275c34d0a13416fb7._comment
 create mode 100644 doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_8_1501223d25a03c27a7ceffc6b0ea32a3._comment
 create mode 100644 doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_9_192c219b32c95954ec6400367474dd78._comment
 create mode 100644 doc/bugs/SSL_repos_does_not_show_up_in_Assistant.mdwn
 create mode 100644 doc/bugs/SSL_repos_does_not_show_up_in_Assistant/comment_1_5a8e599d6e22e7c1960bd1715666657b._comment
 create mode 100644 doc/bugs/SSL_repos_does_not_show_up_in_Assistant/comment_2_2ad5098c5e2ac9b8651cb464adb974c1._comment
 create mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably.mdwn
 create mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_1_13d27ba41d9ef78c8db534b6bc26314e._comment
 create mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_2_018eed99e71680be9e7c0844020419bb._comment
 create mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_3_1e7578dd1321f399b12197056495b0b6._comment
 create mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_4_a1948b7cd6ea990c8f1be5e483c835fa._comment
 create mode 100644 doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_5_293b333134c97dc666a825cc7a8b2b62._comment
 create mode 100644 doc/bugs/Share_with_a_friend_fails.mdwn
 create mode 100644 doc/bugs/Share_with_a_friend_fails/comment_1_d3ba5f786c45e677ea9a7b4a7b36e1a9._comment
 create mode 100644 doc/bugs/Share_with_a_friend_fails/comment_2_1d5568c00a9b11a05b7fde0d2d3bc327._comment
 create mode 100644 doc/bugs/Should_try_again_when_network_fails___40__esp._DNS__41__.mdwn
 create mode 100644 doc/bugs/Should_try_again_when_network_fails___40__esp._DNS__41__/comment_1_dd792bd98a48554a65150c06401ed3e5._comment
 create mode 100644 doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex.mdwn
 create mode 100644 doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex/comment_1_6fd91f615e8d5212674a9748d1b4135b._comment
 create mode 100644 doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex/comment_2_3dbaf39065c2f0941f8f7092c27fd4cb._comment
 create mode 100644 doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex/comment_3_996139be157e23e17ece9f131b17240a._comment
 create mode 100644 doc/bugs/Strange_case_of_data_loss__44___possibly_linked_to_git-annex_with_encrypted_rsync_remote.mdwn
 create mode 100644 doc/bugs/Strange_case_of_data_loss__44___possibly_linked_to_git-annex_with_encrypted_rsync_remote/comment_1_4038261a4d49694374c37ff029d3540f._comment
 create mode 100644 doc/bugs/Stress_test.mdwn
 create mode 100644 doc/bugs/Stress_test/comment_10_1694e990eab6592159309c231c6dcc16._comment
 create mode 100644 doc/bugs/Stress_test/comment_11_ab4cb6eefd279e6c1f229e089f703581._comment
 create mode 100644 doc/bugs/Stress_test/comment_1_c4c764488ac082f5c48d3a6b4b5fba42._comment
 create mode 100644 doc/bugs/Stress_test/comment_2_42125bba09a0ea9821cda7183e458100._comment
 create mode 100644 doc/bugs/Stress_test/comment_3_8240e61106b494d3600ad91f16eb5b1c._comment
 create mode 100644 doc/bugs/Stress_test/comment_4_c38d84e0dcc834931804c44bce7f7b7a._comment
 create mode 100644 doc/bugs/Stress_test/comment_5_60ce20ee255451c4ea809ba475561adb._comment
 create mode 100644 doc/bugs/Stress_test/comment_6_1371562e201393986cd41597f6f288cb._comment
 create mode 100644 doc/bugs/Stress_test/comment_7_a14be7699da224a8f6c9b34f1b911219._comment
 create mode 100644 doc/bugs/Stress_test/comment_8_a01995bdca7ade7dde9842b53fbc4e0c._comment
 create mode 100644 doc/bugs/Stress_test/comment_9_9f7efe81b7e40aaa04a865394c53e20f._comment
 create mode 100644 doc/bugs/Support_manual_configuration_of_tor_hidden_service.mdwn
 create mode 100644 doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_1_643a8e22d6ffd27a5497c077e4ce3bcd._comment
 create mode 100644 doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_2_90deb38d083cfac454bf364884ce06c6._comment
 create mode 100644 doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_3_59fe23f38b4bb70e629b0c7c698d1438._comment
 create mode 100644 doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_4_20c00e22eff7cb5a5f907895bf4b0b44._comment
 create mode 100644 doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_5_7e6e7c0ce27504273be3e5bc27685d93._comment
 create mode 100644 doc/bugs/Symlink_support_on_Windows_10_Creators_Update_with_Developer_Mode.mdwn
 create mode 100644 doc/bugs/Sync_fails_when_borg_remote_is_inaccessible.mdwn
 create mode 100644 doc/bugs/Sync_fails_when_borg_remote_is_inaccessible/comment_1_5e83630a60aa0242969bd1279a70628a._comment
 create mode 100644 doc/bugs/Sync_fails_when_borg_remote_is_inaccessible/comment_2_eff73163e8a7ae09ceeb596fca04c507._comment
 create mode 100644 doc/bugs/Syncing_bare_repository_doesn__39__t_work_after_using_watch_on_Windows.mdwn
 create mode 100644 doc/bugs/Syncing_bare_repository_doesn__39__t_work_after_using_watch_on_Windows/comment_1_e197b8dc0eae0dd6dea4febdc2ecce53._comment
 create mode 100644 doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant.mdwn
 create mode 100644 doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant/comment_1_8100505a7ac74646e0767d03fe643a45._comment
 create mode 100644 doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant/comment_2_9833e8f77c6148db9572316066a67eee._comment
 create mode 100644 doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant/comment_3_1504f8767f1f4415222d8c315c734e81._comment
 create mode 100644 doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address.mdwn
 create mode 100644 doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_1_8ce2cbdf5b5c31fd42b0ed270c54a824._comment
 create mode 100644 doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_2_1316ea67dc7df8d3d6f681ac3caf6d3c._comment
 create mode 100644 doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_3_0e098ee460a0ad70dbe34d74c5e9bf3b._comment
 create mode 100644 doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_4_64fd17f3537fec02f8356e535a1d0bb4._comment
 create mode 100644 doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_5_dacfb426f7e67e984bb9281a40427e85._comment
 create mode 100644 doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_6_c85f2c69aa2cff05859e92afc95e9ccf._comment
 create mode 100644 doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_7_e8c76f8b9645733a793676dc274744ef._comment
 create mode 100644 doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_8_902afcef5ad9c3f2a80d5df1ce99e1d5._comment
 create mode 100644 doc/bugs/Synology___40__armel__41___clock__95__gettime__58___Invalid_argument.mdwn
 create mode 100644 doc/bugs/Synology___40__armel__41___clock__95__gettime__58___Invalid_argument/comment_1_5277a05a17b348a1be80845e697c018c._comment
 create mode 100644 doc/bugs/System.PosixCompat.User_removed_in_unix-compat-0.7.mdwn
 create mode 100644 doc/bugs/System.PosixCompat.User_removed_in_unix-compat-0.7/comment_1_cd573b785b7d7feec72387cb0dafdcab._comment
 create mode 100644 doc/bugs/System.PosixCompat.User_removed_in_unix-compat-0.7/comment_2_6b15d11b6e25689e2430663a4aa90168._comment
 create mode 100644 doc/bugs/Tests_v8_locked__58___rsync_remote__58___FAIL.mdwn
 create mode 100644 doc/bugs/Tests_v8_locked__58___rsync_remote__58___FAIL/comment_1_809ca8b986ccadbc3940cc795d1823e8._comment
 create mode 100644 doc/bugs/Tests_v8_locked__58___rsync_remote__58___FAIL/comment_2_0327663314d2a8b2f0cab7536fdaa6bd._comment
 create mode 100644 doc/bugs/TransferScanner_crashed__58___fd__58__59__58___hGetLine__58___end_of_file.mdwn
 create mode 100644 doc/bugs/TransferScanner_crashed__58___fd__58__59__58___hGetLine__58___end_of_file/comment_1_a1392b92efdff82783a4b0cc2c3c7f2f._comment
 create mode 100644 doc/bugs/TransferScanner_crashed__58___fd__58__59__58___hGetLine__58___end_of_file/comment_2_5e153b7c59c474988fe551a505e545bc._comment
 create mode 100644 doc/bugs/Transfers_continue_after_daemon_stopped.mdwn
 create mode 100644 doc/bugs/Transfers_continue_after_daemon_stopped/comment_1_39eb527d64367e6762281246f1d49b1f._comment
 create mode 100644 doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead.mdwn
 create mode 100644 doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_1_108b3984891f82429430b503cddfb3c1._comment
 create mode 100644 doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_2_fa5b1bc26ed3e5bfe48441490c94fe3a._comment
 create mode 100644 doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_3_0a785b5dfbf4eef30854d6bedb12b7d1._comment
 create mode 100644 doc/bugs/URL_key_potential_data_loss.mdwn
 create mode 100644 doc/bugs/URL_key_potential_data_loss/comment_1_a921dab2c4335f690df4d5189fe4e4c2._comment
 create mode 100644 doc/bugs/URL_key_potential_data_loss/comment_2_0c9e7b8e00db92e8d638328f0390f6e9._comment
 create mode 100644 doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows.mdwn
 create mode 100644 doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows/comment_1_c4cfa1d0f90193b127722711285e1210._comment
 create mode 100644 doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows/comment_2_ff71a541b3df8bb272e576c856b3aa9d._comment
 create mode 100644 doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier.mdwn
 create mode 100644 doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_1_f68d5ad86d67aa73074389cf9a21469e._comment
 create mode 100644 doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_2_f0f1f18265ebb83caf4e6f1fb23ec876._comment
 create mode 100644 doc/bugs/Upgrade_impossible_om_Mac_OSX.mdwn
 create mode 100644 doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_10_8c1487635f724d017ebe2f8b7bc10e8d._comment
 create mode 100644 doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_1_84e52a4d1502fd622bdb25e04b459292._comment
 create mode 100644 doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_2_f2b109f6cf92f101d7f0afeb91605240._comment
 create mode 100644 doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_3_df9b111aefea82b9d108495b79d7ffb4._comment
 create mode 100644 doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_4_e3b5bc815376383bbd1f312cc1c32a41._comment
 create mode 100644 doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_5_cd9b77e6670840a9902f5be80e1e658a._comment
 create mode 100644 doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_6_4584393333d377532d8607b42319abd9._comment
 create mode 100644 doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_7_d9d36ff62267dde98a27c5981951df7f._comment
 create mode 100644 doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_8_5b26711c737eeb0b302060f098cb320b._comment
 create mode 100644 doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_9_1bf050056dcac7c1e0f497ee6e87a95a._comment
 create mode 100644 doc/bugs/Upload_to_S3_fails_.mdwn
 create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_10_b7e912bac673bdffa5775b71d5d39937._comment
 create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_11_65cb9b1dd69cd657f2cfde036eb60417._comment
 create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment
 create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_2_f33ce058c9460cf7d151e739bff0440a._comment
 create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_3_cd1e768fe1e67daf08b5afd460620922._comment
 create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_4_0cdd2e8d6e83c03de717ecd3253e753d._comment
 create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_5_020c055f6c06860dda27c1debb123742._comment
 create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_6_8bc023fca8cedfc517856cdcd20b7f10._comment
 create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_7_32685258748a7cdd177e7af2105f128e._comment
 create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_8_841fd94d0f599c71a76fd22b07944366._comment
 create mode 100644 doc/bugs/Upload_to_S3_fails_/comment_9_dd837a1cb2146224b9c000cbeea4f3b3._comment
 create mode 100644 doc/bugs/User-Agent_not_sent_with_S3_remote.mdwn
 create mode 100644 doc/bugs/User-Agent_not_sent_with_S3_remote/comment_1_68fd5b6a69d90bb9623740752a918657._comment
 create mode 100644 doc/bugs/Utility.Url.Parse_fails_to_build_on_Win___40__imports__41__.mdwn
 create mode 100644 doc/bugs/VFAT_crazy_limit_on_max_filenames_in_directory.mdwn
 create mode 100644 doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects.mdwn
 create mode 100644 doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_1_70428ebc4027538253edc483dc5cb971._comment
 create mode 100644 doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_2_059b9beb31d9cbc97ea4a59f47d2e63d._comment
 create mode 100644 doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_3_176cbc137afb5cf8841ff9114b111fef._comment
 create mode 100644 doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_4_a6490af0427bbe4363bea824d55a7593._comment
 create mode 100644 doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem.mdwn
 create mode 100644 doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_1_6b54cc0a268885570170620222b774d7._comment
 create mode 100644 doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_2_5634af4cef0d0fe0d2affe40d9c0d5ea._comment
 create mode 100644 doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_3_816bae469b0341c6dae2316050a95ad5._comment
 create mode 100644 doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_4_ab64e43330e466482f30487b8bd13bbf._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol.mdwn
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_10_93c9d3ea6d7a1f2d035f8a52c81790ad._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_11_94d00ed84dfebebd7889fa861172df61._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_12_76f765e3befd5e263a8863b56cad139b._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_13_5e08dcb7e40e7fbcb22425b3ff8b0610._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_14_45b1da34ec60d6322477edfd6a3a2bba._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_1_0bcbce94586ef96c2dcbe5ef9da4ac6f._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_2_bdb3cadf29facd4729120a6cd057b8a8._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_3_2a9f0396df93d9500306b3d7039803a2._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_4_da42c839f96314ed8c5ad646b614b75d._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_5_f8ee3d06a79bdc429a114b5256290206._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_6_b7a3837fd6af236e9ecf6d5bae077fd0._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_7_276be047d18b2e20a8e3114abe3132ee._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_8_cb7ce88ae3d77b9ba0a4e33c2321a3e1._comment
 create mode 100644 doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_9_b0700fdf101f6cc883857b293cd35267._comment
 create mode 100644 doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist.mdwn
 create mode 100644 doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist/comment_1_9892f6b80597f0b637aeb96d212164d9._comment
 create mode 100644 doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist/comment_2_687a9fd1c0b760dd2bef9647cd16175c._comment
 create mode 100644 doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist/comment_3_1ef917c10f944e6c874aa40affae7602._comment
 create mode 100644 doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__.mdwn
 create mode 100644 doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__/comment_1_71b052be40fbdaca09ca3ede8c59ac7a._comment
 create mode 100644 doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__/comment_3_0f7cc02e0193c969c9b6ceb27e71af8a._comment
 create mode 100644 doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__/comment_3_1a7542249b9c37507126e97441057c12._comment
 create mode 100644 doc/bugs/Webapp_won__180__t_start_on_MacOS.mdwn
 create mode 100644 doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_1_0a8b46efd3f6b7c9f818fc64af9a5f4f._comment
 create mode 100644 doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_2_7eb9cf2b8c7192ae654831cdc0c00253._comment
 create mode 100644 doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_3_069b107437b6456d027c8d97bc708d48._comment
 create mode 100644 doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_4_1e944c517796ca29f8870fcf76c9a0d4._comment
 create mode 100644 doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_5_2c7d2e81cbe943fe9154830fdf958181._comment
 create mode 100644 doc/bugs/When_--git-dir_is_not_in_--work-tree.mdwn
 create mode 100644 doc/bugs/Windows__58___Doesn__39__t_want_to_handle_files_with_2_dots_in_filename.mdwn
 create mode 100644 doc/bugs/Windows__58___Doesn__39__t_want_to_handle_files_with_2_dots_in_filename/comment_1_43f6de166d1811e9f9bd6e6d8b152e05._comment
 create mode 100644 doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process.mdwn
 create mode 100644 doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process/comment_1_79c57a6a8c0b100c07d014d8d2b862cb._comment
 create mode 100644 doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process/comment_2_6242b7aded8b221aba8a5e3e4374238a._comment
 create mode 100644 doc/bugs/Windows__58___git_annex_get_failed.mdwn
 create mode 100644 doc/bugs/Windows__58___git_annex_get_failed/comment_2_0866038e64aa20c3b9ba3b3190074293._comment
 create mode 100644 doc/bugs/Windows__58___git_annex_get_failed/comment_3_22809831226478bac7f9361ad8d0c79d._comment
 create mode 100644 doc/bugs/Windows__58___git_annex_get_failed/comment_3_8a19ca100d44ab8131e40932f1bcdf29._comment
 create mode 100644 doc/bugs/Windows__58___git_annex_get_failed/comment_4_b70fa3da7e776a6cd6d8467df30839c9._comment
 create mode 100644 doc/bugs/Windows__58___support_NTFS_symlinks.mdwn
 create mode 100644 doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree.mdwn
 create mode 100644 doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_1_5829b551f5e1413ee236055eb3345760._comment
 create mode 100644 doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_2_535016130f3307c8104168e6bb8a583d._comment
 create mode 100644 doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_3_79c66569c22a1280b807a3c21c2cdc4f._comment
 create mode 100644 doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_4_2e5791aa8f568f86d0185a553227afa8._comment
 create mode 100644 doc/bugs/Windows_build_test_failures.mdwn
 create mode 100644 doc/bugs/Windows_build_test_failures/comment_1_ea7523fdbafdc8be2971df52d9038826._comment
 create mode 100644 doc/bugs/Windows_installer_includes_curl_and_wget__44___but_not_required_DLLs.mdwn
 create mode 100644 doc/bugs/Windows_installer_includes_curl_and_wget__44___but_not_required_DLLs/comment_1_a7bf0f027f2209e5632e292afd7214d0._comment
 create mode 100644 doc/bugs/Wrong_permission_when_using_shared_repository.mdwn
 create mode 100644 doc/bugs/Wrong_permission_when_using_shared_repository/comment_1_bfcb858bfd1c5377c2b15961b59a835a._comment
 create mode 100644 doc/bugs/Wrong_permission_when_using_shared_repository/comment_2_e3c9e3b9004f1fe964b23d955083089b._comment
 create mode 100644 doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy.mdwn
 create mode 100644 doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy/comment_1_b05e0060d503a1d58c972796c5be151b._comment
 create mode 100644 doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy/comment_2_399dcbe7f3772526efbe13bd5b13156d._comment
 create mode 100644 doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy/comment_3_201c7dcd0e809cb2c22ab4b621079c71._comment
 create mode 100644 doc/bugs/__34__Missing_location__34___with_partsize__39__d_uploads.mdwn
 create mode 100644 doc/bugs/__34__Missing_location__34___with_partsize__39__d_uploads/comment_1_b3b767b3ab4a73590bf7e2af8640f906._comment
 create mode 100644 doc/bugs/__34__Unsupported_url_scheme__34___message_when_trying_to_cconnect_to_ftp_server.mdwn
 create mode 100644 doc/bugs/__34__Unsupported_url_scheme__34___message_when_trying_to_cconnect_to_ftp_server/comment_1_db2b9e26bc01abbc3312731b95cf770f._comment
 create mode 100644 doc/bugs/__34__commitBuffer__58___invalid_argument___40__invalid_character__41____34___during___34__git_annex_sync__34__.mdwn
 create mode 100644 doc/bugs/__34__directory__34___special_remote_leaves_empty_dirs.mdwn
 create mode 100644 doc/bugs/__34__directory__34___special_remote_leaves_empty_dirs/comment_1_8cef8650103d118fbbe56d20a4f59f96._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit.mdwn
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_10_8abfe7417167df54b686960319465a65._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_11_7776659e257a97c9a3855c8ad008207a._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_12_e8bbfb4eb26dae31f90a5fa53b4dc948._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_13_aee32c53d2198ba1e82acd0c617d517c._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_14_f41116524fb7b423ff03c9440b5f278b._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_15_0f61544accba5002edef2bcd4131e69f._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_16_9dc2f74dc69ccf867ac4e68cc502fda4._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_17_0525b887cd75c183a34de0f486ec022c._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_18_fd55979b686b5f83ba2b95300abd1852._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_19_bdd9e29413f4407207efa01283ad68ad._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_1_2a64a2da445a64149da7335f35142a08._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_20_f12f7f14ef09fa765c78dbeef809da7d._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_21_3f2ce7b851392ad5285e95f3857d0959._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_22_94dc1d1485c3a380fe19dabe8f95aac2._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_2_decb1689b8cc2541077e2d0ae273b5e7._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_3_1f6443e495cc16a13e2e4175e73dc8f1._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_4_522020e71393434834def6c80b82e39e._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_5_cc4cba022869b32d298cdafed9545a34._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_6_e71b251db2ff1f52a40fec40303cdefc._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_7_0b6413f9ca403be3d83bb3306d1e7f8f._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_8_f951981f0bf8cbaecfc46e7b9c903d70._comment
 create mode 100644 doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_9_7c98c8b291fdf28a09ccb6c7e4001d5a._comment
 create mode 100644 doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field.mdwn
 create mode 100644 doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field/comment_1_6708d83b96b791e4cd829bb0a65cda6d._comment
 create mode 100644 doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field/comment_2_d28894bc233987f68159e8d1a7a97096._comment
 create mode 100644 doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation.mdwn
 create mode 100644 doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_1_a63994b33b651dccfd4d4cf946ab7170._comment
 create mode 100644 doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_2_2166a985e48a31c1b86cb77263f72ce2._comment
 create mode 100644 doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_3_17b96f95f44a04063f5a52d690d96b32._comment
 create mode 100644 doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_4_df73b69e651c728943a404223f350ebf._comment
 create mode 100644 doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn
 create mode 100644 doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_1_d146a64ef8d76c2a7e45bf85d8943456._comment
 create mode 100644 doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_2_6585b15aa7ae63175482d08b2b5b79fc._comment
 create mode 100644 doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_3_973d90a6fde1c6f26fcf594610693fad._comment
 create mode 100644 doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway.mdwn
 create mode 100644 doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_1_30a0a715fb9d8738e5ec53296375c1b3._comment
 create mode 100644 doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_2_b91f9337b7ed536539bb3236b7552d82._comment
 create mode 100644 doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_3_79268506a1653220ddfbb45f9c61d8a7._comment
 create mode 100644 doc/bugs/__34__no_such_file_or_directory__34___when_using_bundle/comment_1_9c2410c55154bc8d9f733377cde58eb9._comment
 create mode 100644 doc/bugs/__34__rename__58___permission_denied__34__.mdwn
 create mode 100644 doc/bugs/__34__rename__58___permission_denied__34__/comment_1_19de24208042d09572c114bca80f4854._comment
 create mode 100644 doc/bugs/__34__rename__58___permission_denied__34__/comment_2_e70c8b8192eb0f8868e52dc7a287e526._comment
 create mode 100644 doc/bugs/__39__Production__39___build_doesn__39__t_pass_testsuite_on_Win32.mdwn
 create mode 100644 doc/bugs/__39__Production__39___build_doesn__39__t_pass_testsuite_on_Win32/comment_1_7ac6938faef9111da701080a62c4d7e9._comment
 create mode 100644 doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo.mdwn
 create mode 100644 doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo/comment_1_3233c29405da296360d57af7d5eb418d._comment
 create mode 100644 doc/bugs/__39__git_annex_assist__39___doesn__39__t_honor_--jobs.mdwn
 create mode 100644 doc/bugs/__39__git_annex_assist__39___doesn__39__t_honor_--jobs/comment_1_96b3c705c7c83b153cde2e8bb16ed380._comment
 create mode 100644 doc/bugs/__47__exe__47__git-annex.mdwn
 create mode 100644 doc/bugs/__47__exe__47__git-annex/comment_1_8a9e9d83a3dcf07ed76a22f03636f6d1._comment
 create mode 100644 doc/bugs/__47__exe__47__git-annex/comment_2_381ac4e8b27343cdc470584c05edec76._comment
 create mode 100644 doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__.mdwn
 create mode 100644 doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_1_3afce2aadeb2221c66f397e631d0e4a6._comment
 create mode 100644 doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_2_220b3ed61dfcce4d6d33fa8516cd1ec1._comment
 create mode 100644 doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_3_8fb126d6583014d3e16137e9c18057e6._comment
 create mode 100644 doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_4_72204d0647ec808145b6838d5e621107._comment
 create mode 100644 doc/bugs/__96__git_add__96___adds_files_unlocked_instead_of_locked.mdwn
 create mode 100644 doc/bugs/__96__git_add__96___adds_files_unlocked_instead_of_locked/comment_1_58abf8693ed90fc8c6e3f750310c17e4._comment
 create mode 100644 doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote.mdwn
 create mode 100644 doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_1_e3bc14a173600b86c5875d90228aea8b._comment
 create mode 100644 doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_2_9274223b32601ead9a508aa9852e4933._comment
 create mode 100644 doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_3_8f46a9d4a7ceae80e378149d88dd1f19._comment
 create mode 100644 doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_4_c3130a2595fc35525dfdbcc6cec57713._comment
 create mode 100644 doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_5_eeb4f35b7609cb36fdcece9b8cb94430._comment
 create mode 100644 doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_6_ee21d4d8b276a32b227199175ea30721._comment
 create mode 100644 doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_7_9104e12c57bc47cfd0a6c109ad085de1._comment
 create mode 100644 doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_8_c5b96e6c35c8969062489d6e03066f34._comment
 create mode 100644 doc/bugs/__96__git_annex_sync___60__REMOTE__62____96___swallows_network_failure.mdwn
 create mode 100644 doc/bugs/__96__lookupkey__96___unexpectedly_slow.mdwn
 create mode 100644 doc/bugs/__96__lookupkey__96___unexpectedly_slow/comment_1_13003e3b46c5cfab60b6e34fb18731d7._comment
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__.mdwn
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_11_d485bbc1c0f2fceaaa2e4142dccdc1f7._comment
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_12_b0132b0f846e4882a5511b53694a1fa2._comment
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_1_fa2fb2493ea1244f334b54e6af2b553b._comment
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_2_ccd90a2ad9cb9c896a47d62ecdfc5304._comment
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_3_c7e71722379431789f26b5e743e13d9c._comment
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_4_f730f3593ab5aeac34e74ec48f943949._comment
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_5_934ee22209920f8429c0ac71002bab1e._comment
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_6_1611ef71978eeb61da4c42cffcff2411._comment
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_7_6700aabc3b4cb02a5b370cf4c71c6a0c._comment
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_7_a0b287e187396b7072e4d7bab3664621._comment
 create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_8_0b4e0acecbcc6a8736849801446a189c._comment
 create mode 100644 doc/bugs/____adjusted_branch_subtree_regression__58___FAIL_.mdwn
 create mode 100644 doc/bugs/____adjusted_branch_subtree_regression__58___FAIL_/comment_1_2b2040240fe8f01a6348eb68959d9319._comment
 create mode 100644 doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git.mdwn
 create mode 100644 doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git/comment_1_60db0d6bfc71a62b3c1021527a8d2d60._comment
 create mode 100644 doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git/comment_2_49682a91147990a578929678880bd226._comment
 create mode 100644 doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git/comment_3_bf0fa06596338444a3772d1865b17e26._comment
 create mode 100644 doc/bugs/acl_not_honoured_in_rsync_remote.mdwn
 create mode 100644 doc/bugs/acl_not_honoured_in_rsync_remote/comment_1_aa6fe1d7b029eae7ee71c97e0f0937a6._comment
 create mode 100644 doc/bugs/acl_not_honoured_in_rsync_remote/comment_2_ffb9424e966ee10a4fe2d446b3042cb2._comment
 create mode 100644 doc/bugs/acl_not_honoured_in_rsync_remote/comment_3_f93177593a2d90627672647fd5f065c9._comment
 create mode 100644 doc/bugs/adb_creates_empty_commits_on_import__47__sync.mdwn
 create mode 100644 doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_10_87efdd2a9c7091f92a6bc96e87a59e18._comment
 create mode 100644 doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_11_206d98a17319292d4de4c475a7b8d091._comment
 create mode 100644 doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_1_522c68d019e5db592e140db9501435ba._comment
 create mode 100644 doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_2_5000af944e3a7917a97b65fb7d1c5c3e._comment
 create mode 100644 doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_3_a9b3e07f180ab97f5025d7ce9ca58c05._comment
 create mode 100644 doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_4_4e9e55d54d9afb2dbb48320156757f11._comment
 create mode 100644 doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_4_d500b9ae8e3f57a2f8dcd2314c0022dd._comment
 create mode 100644 doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_6_aafa4a00a9579e54c3080586c1b7bb3e._comment
 create mode 100644 doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_7_f1e37aa68778408629c53c09f0a0857f._comment
 create mode 100644 doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_8_0a7f24a4567ff934cee37a4c0224f000._comment
 create mode 100644 doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_9_9b4d104a7255a7618221f9dbb410fdcb._comment
 create mode 100644 doc/bugs/adb_pull_does_not_preserve_timestamp.mdwn
 create mode 100644 doc/bugs/adb_pull_does_not_preserve_timestamp/comment_1_b695826d1f948249b496c055b4d745df._comment
 create mode 100644 doc/bugs/adb_pull_does_not_preserve_timestamp/comment_2_2d49693c5f8d826f9a4b1cf2f8dca2c5._comment
 create mode 100644 doc/bugs/adb_pull_does_not_preserve_timestamp/comment_3_cf555d2f0f93248a913014f30ce513b2._comment
 create mode 100644 doc/bugs/adb_pull_does_not_preserve_timestamp/comment_4_9d5cbd2479a07d778bacfdfe0aaaa524._comment
 create mode 100644 doc/bugs/adb_pull_does_not_preserve_timestamp/comment_5_244a5803178b4e44f3ec4460c5daf258._comment
 create mode 100644 doc/bugs/adb_pull_does_not_preserve_timestamp/comment_6_77416807482416c552922d39a0319a65._comment
 create mode 100644 doc/bugs/adb_pull_does_not_preserve_timestamp/comment_7_216316d2db3a728837fd059587ad1928._comment
 create mode 100644 doc/bugs/adb_remote_fails_to_import_treeish.mdwn
 create mode 100644 doc/bugs/adb_remote_fails_to_import_treeish/comment_1_8012368012cf53e8552d7670b9b8315d._comment
 create mode 100644 doc/bugs/adb_remote_fails_to_import_treeish/comment_2_54867d63c04ee18c76b1d769db71bc00._comment
 create mode 100644 doc/bugs/adb_remote_fails_to_import_treeish/comment_3_5e819d0b5f3101e86f0f95a7ab725ad4._comment
 create mode 100644 doc/bugs/adb_replaces_symlinks_by_plain_text_files.mdwn
 create mode 100644 doc/bugs/adb_replaces_symlinks_by_plain_text_files/comment_1_bcc12b77c5069769ab04e448b23b3d85._comment
 create mode 100644 doc/bugs/adb_replaces_symlinks_by_plain_text_files/comment_2_f5db61aa7efb7a916d0ffebd563cc2c7._comment
 create mode 100644 doc/bugs/adb_replaces_symlinks_by_plain_text_files/comment_3_7346adcffb3d9056dc880dcf1e2ab03f._comment
 create mode 100644 doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files.mdwn
 create mode 100644 doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_1_31142cacafa0c975cd33a76c22f60bf3._comment
 create mode 100644 doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_2_09f5982e930a04c25ea3ce8caac449c4._comment
 create mode 100644 doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_3_3b4100037ee9180346ffc2240a34064e._comment
 create mode 100644 doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles.mdwn
 create mode 100644 doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_1_263bfea4cae5a612de1761b3c3fc32b8._comment
 create mode 100644 doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_2_6fbd20761f9388c04fa13b38af2354d9._comment
 create mode 100644 doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_3_e8636243a3c98b11e54b6fa8617f9e32._comment
 create mode 100644 doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_4_27bf6cfce4f73a1d29a753e33c1e871a._comment
 create mode 100644 doc/bugs/add_config_var_preventing_adjusted_branch_mode.mdwn
 create mode 100644 doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_1_d7ca1f4ccb4bc8a72788f6dcf8af9439._comment
 create mode 100644 doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_2_0c064717d0b85ff4b9df1bada7c6e7ad._comment
 create mode 100644 doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_3_1f4b1f2a32f11da4c9bba95f25dd45c1._comment
 create mode 100644 doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_4_0fb992fe4ef5ec14876d2d1912dca4c5._comment
 create mode 100644 doc/bugs/add_overwrite_race.mdwn
 create mode 100644 doc/bugs/added_branches_makes___39__git_annex_unused__39___slow.mdwn
 create mode 100644 doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_1_d350c39c67031c500e3224e92c0029ea._comment
 create mode 100644 doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_2_b2d2b1caa51ffec3d87c36b373cb8d4a._comment
 create mode 100644 doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_3_12b20cbbc2b4cd1ab8af7e3eec9589b4._comment
 create mode 100644 doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_4_a50b43c15d2650df90f0fa1ced47f532._comment
 create mode 100644 doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_5_7328bc51bd001f2b732a92a2ae175839._comment
 create mode 100644 doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_6_880ef2ee797221332dbb629b2d55522f._comment
 create mode 100644 doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_7_826fd82cdf9b1c79c9b555ca26c2c176._comment
 create mode 100644 doc/bugs/adding_a_remote_server_fails.mdwn
 create mode 100644 doc/bugs/adding_a_remote_server_fails/comment_1_cf7ea9171f002c5793a882b42d33a77d._comment
 create mode 100644 doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work.mdwn
 create mode 100644 doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work/comment_1_831dc2185919865d418b29cd06ef42be._comment
 create mode 100644 doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work/comment_2_88b7db5434a56c25c75772caa37bc14a._comment
 create mode 100644 doc/bugs/addurl_--batch_errors_with__git-annex__58___user_error_.mdwn
 create mode 100644 doc/bugs/addurl_--batch_errors_with__git-annex__58___user_error_/comment_1_996a54315c21e1dcb94cca9576d1d5f7._comment
 create mode 100644 doc/bugs/addurl_--preserve-filename_still_modifies_file_names.mdwn
 create mode 100644 doc/bugs/addurl_--preserve-filename_still_modifies_file_names/comment_1_88c0a762e2a37f680f6a4419582eddac._comment
 create mode 100644 doc/bugs/addurl_--preserve-filename_still_modifies_file_names/comment_2_386891c1effda6cae17d88eacbfa0daf._comment
 create mode 100644 doc/bugs/addurl_fails_because_special_remote_is_not_available.mdwn
 create mode 100644 doc/bugs/addurl_fails_because_special_remote_is_not_available/comment_1_7caf2377477495c08378755cdf45dec8._comment
 create mode 100644 doc/bugs/addurl_fails_because_special_remote_is_not_available/comment_2_83a864a73f9c1c6bf86dc60b47a965fe._comment
 create mode 100644 doc/bugs/addurl_fails_because_special_remote_is_not_available/comment_3_b0e9f373c3439b15a28fd20e9b0e24a6._comment
 create mode 100644 doc/bugs/addurl_unittest_failing_under_windows.mdwn
 create mode 100644 doc/bugs/addurl_unittest_failing_under_windows/comment_1_8f723e986d80754a8b68308ab8b15c20._comment
 create mode 100644 doc/bugs/addurl_unittest_failing_under_windows/comment_2_e0bbb72af2852b2210bb1ce520e88f1d._comment
 create mode 100644 doc/bugs/adjusted__40__unlocked__41___does_not_honor_addunlocked.mdwn
 create mode 100644 doc/bugs/adjusted__47__main__40__unlocked__41___not_syncing_with_main.mdwn
 create mode 100644 doc/bugs/adjusted__47__main__40__unlocked__41___not_syncing_with_main/comment_1_e5ebc1cf8621761b559d53884731d0e3._comment
 create mode 100644 doc/bugs/adjusted__47__main__40__unlocked__41___not_syncing_with_main/comment_2_149502c4d8fa2c50507e7e6e312f9703._comment
 create mode 100644 doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified.mdwn
 create mode 100644 doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_10_8a355d509fb2005cfd9da8f2d4bb560e._comment
 create mode 100644 doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_11_ee707efce9c5537a1f7d0ffded952af8._comment
 create mode 100644 doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_1_0fcdba2f621c8c32f09b2633c11266ee._comment
 create mode 100644 doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_2_4719510b78d347f28a0fe8910c086982._comment
 create mode 100644 doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_3_05f178a19b8949efc5c6e189ff8fa5e0._comment
 create mode 100644 doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_4_ad4621b602e7632d74d58f1728b80cda._comment
 create mode 100644 doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_5_fcb259337b70b0d5c5e50c8facb845e4._comment
 create mode 100644 doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_6_1df979b8e222dd135a10046c51f0dc0b._comment
 create mode 100644 doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_7_5e3482024e20759f8d42e14598d4dc26._comment
 create mode 100644 doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_8_4e9f342281b01ecb9354a08200c04ab0._comment
 create mode 100644 doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_9_63af8f32512ce8ec07c48361317ce51d._comment
 create mode 100644 doc/bugs/android_sync_messes_tree.mdwn
 create mode 100644 doc/bugs/android_sync_messes_tree/comment_1_a90afb9011c760843836728d03353619._comment
 create mode 100644 doc/bugs/android_sync_messes_tree/comment_2_90d589053c4d1b646edd07978999d001._comment
 create mode 100644 doc/bugs/android_sync_messes_tree/comment_3_f964c18aced83ba02d3436941dbcbacc._comment
 create mode 100644 doc/bugs/android_sync_messes_tree/comment_4_1f819796ec13f83e56917332efffe54d._comment
 create mode 100644 doc/bugs/android_sync_messes_tree/comment_5_7fda943808cc1b7155c1223fea08e8df._comment
 create mode 100644 doc/bugs/annex.autocommit_seems_ignored_for_new_files.mdwn
 create mode 100644 doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data.mdwn
 create mode 100644 doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_1_d02a1e53cb95b0cb3c4330c668bcb15b._comment
 create mode 100644 doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_2_a6806787dc0163f67dc141415c951add._comment
 create mode 100644 doc/bugs/annex_add_freezes_before_moving__58___stopped_working.mdwn
 create mode 100644 doc/bugs/annex_add_freezes_before_moving__58___stopped_working/comment_1_b3c780a6f888c8afc3bd5cd7d436527c._comment
 create mode 100644 doc/bugs/annex_add_freezes_before_moving__58___stopped_working/comment_2_97df39b9fed0e9bb716b1940c0641140._comment
 create mode 100644 doc/bugs/annex_add_freezes_before_moving__58___stopped_working/comment_3_db0070d2b601e66aca3059248cc24bbb._comment
 create mode 100644 doc/bugs/annex_get__stalls_over_ssh.mdwn
 create mode 100644 doc/bugs/annex_get__stalls_over_ssh/comment_1_335a8901b7992c2041eabed3785a25e0._comment
 create mode 100644 doc/bugs/annex_import_does_not_account_for_versioning_on_S3.mdwn
 create mode 100644 doc/bugs/annex_import_does_not_account_for_versioning_on_S3/comment_1_a04fbb936785456ed99512ea4c29fd53._comment
 create mode 100644 doc/bugs/annex_import_does_not_account_for_versioning_on_S3/comment_2_6015c5488e69307424a3c0281b50a49e._comment
 create mode 100644 doc/bugs/annex_remotedaemon_100__37___cpu_hungry.mdwn
 create mode 100644 doc/bugs/annex_sync_silently_resets_master_to_previous_sync.mdwn
 create mode 100644 doc/bugs/annex_sync_silently_resets_master_to_previous_sync/comment_1_84346dcb210b86e86bd474820bb5f494._comment
 create mode 100644 doc/bugs/annex_sync_silently_resets_master_to_previous_sync/comment_2_c420c76e5aebb1339f4c478b4d56d5de._comment
 create mode 100644 doc/bugs/annex_sync_silently_resets_master_to_previous_sync/comment_3_80d241b2654856669d82d1ab5de40c00._comment
 create mode 100644 doc/bugs/annex_tries_to_start_old_binaray.mdwn
 create mode 100644 doc/bugs/annex_tries_to_start_old_binaray/comment_1_209c36b737a48a6136eeb85d1f3d01b3._comment
 create mode 100644 doc/bugs/annex_unannex__47__uninit_should_handle_copies.mdwn
 create mode 100644 doc/bugs/annex_unannex__47__uninit_should_handle_copies/comment_1_c896ff6589f62178b60e606771e4f2bf._comment
 create mode 100644 doc/bugs/annex_unannex__47__uninit_should_handle_copies/comment_2_9249609f83f8e9c7521cd2f007c1a39e._comment
 create mode 100644 doc/bugs/apparent_hang_in_git-annex-smudge.mdwn
 create mode 100644 doc/bugs/apparent_hang_in_git-annex-smudge/comment_1_80e24b74572d50f648d8aaae228b8827._comment
 create mode 100644 doc/bugs/aria2c_display_broken_in_git-annex.mdwn
 create mode 100644 doc/bugs/aria2c_display_broken_in_git-annex/comment_1_770e1d657bba2a3f5782eac2e8bdca57._comment
 create mode 100644 doc/bugs/aria2c_display_broken_in_git-annex/comment_2_2f26037c5a67f6f8928204ab0b7b7965._comment
 create mode 100644 doc/bugs/assistant_--autostop_stops_after_nonexistant_repo.mdwn
 create mode 100644 doc/bugs/assistant___40__webapp__41___commited_unlocked_link_to_annex.mdwn
 create mode 100644 doc/bugs/assistant_bails_when_adding_encrypted_usbdrive_repo_on_mac.mdwn
 create mode 100644 doc/bugs/assistant_bails_when_adding_encrypted_usbdrive_repo_on_mac/comment_1_4ea192e57f86a33087997746722e6acf._comment
 create mode 100644 doc/bugs/assistant_bails_when_adding_encrypted_usbdrive_repo_on_mac/comment_2_622ad5b34780fc8468c5c515ad9f27fa._comment
 create mode 100644 doc/bugs/assistant_cannot_sync_files_to_empty_indirect_repo.mdwn
 create mode 100644 doc/bugs/assistant_cannot_sync_files_to_empty_indirect_repo/comment_1_af9b44674bafb63de05b888b90878325._comment
 create mode 100644 doc/bugs/assistant_cannot_sync_files_to_empty_indirect_repo/comment_2_789149eb53162a11cbafde399215e40e._comment
 create mode 100644 doc/bugs/assistant_committer_crashes_due_to_missing_file.mdwn
 create mode 100644 doc/bugs/assistant_does_not_allow_adding_an_existing_repo.mdwn
 create mode 100644 doc/bugs/assistant_does_not_allow_adding_an_existing_repo/comment_1_87e84d56d56abefe8cac8a52b76c9003._comment
 create mode 100644 doc/bugs/assistant_does_not_allow_adding_an_existing_repo/comment_2_55fcf44eefe6abac3f61a14e9ce9206c._comment
 create mode 100644 doc/bugs/assistant_does_not_always_use_repo_cost_info_when_queueing_downloads.mdwn
 create mode 100644 doc/bugs/assistant_doesn__39__t_notice_changes_to_gitignore_files.mdwn
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_empty_directories.mdwn
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_1_78a3bde607f43c0f518bd2d3d7196022._comment
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_2_83777384b72732b1d0a19b32686d3d1f._comment
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_3_f9b2a700c060707fae1bcb2ec0e4e4dc._comment
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_4_014d213a959dd7993bdd247722a8817e._comment
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_5_440f349781d7d9ca2d1ed81386f7dd26._comment
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_file_permissions.mdwn
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_1_fc8d3ea209a2ab39c1aeff52452d4c58._comment
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_2_1a364c422e0dd7418f74e1cc3d543a3c._comment
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_3_4d5ae51b4c7e6177d934d7c9f21b912c._comment
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_4_ec7b491ad3c9a1f253d886682bff8b82._comment
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_5_e04ddcd7a3d260c1dac54e41911bb4bc._comment
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_6_13db3474113b157b7431eb1c835e5814._comment
 create mode 100644 doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_7_3cc6eeb8eae14ac3727b1e420f96ee7d._comment
 create mode 100644 doc/bugs/assistant_expensive_scan_unnecessarily_queues_files.mdwn
 create mode 100644 doc/bugs/assistant_expensive_scan_unnecessarily_queues_files/comment_1_bc874e077009b81ab36a6d43d793030a._comment
 create mode 100644 doc/bugs/assistant_expensive_scan_unnecessarily_queues_files/comment_2_a7e9d8ec500399dd6794e168f85e6a5c._comment
 create mode 100644 doc/bugs/assistant_expensive_scan_unnecessarily_queues_files/comment_3_a0824e00f04f95c39823f29d6c76e7fe._comment
 create mode 100644 doc/bugs/assistant_locked_my_files.mdwn
 create mode 100644 doc/bugs/assistant_locked_my_files/comment_1_74ee7ea12df7bfbb44c9d0485f787b73._comment
 create mode 100644 doc/bugs/assistant_memory_leak.mdwn
 create mode 100644 doc/bugs/assistant_not_synching_with_content.mdwn
 create mode 100644 doc/bugs/assistant_should_set_up_dedicated_ssh_keys_for_remotes_using_the_standalone_tarball.mdwn
 create mode 100644 doc/bugs/assistant_sometimes_does_not_merge_changes_from_remote.mdwn
 create mode 100644 doc/bugs/assistant_sometimes_does_not_merge_changes_from_remote/comment_1_43bae1f11621232a9133cdef21d1f063._comment
 create mode 100644 doc/bugs/assistant_sometimes_removes_and_re-adds_whole_file.mdwn
 create mode 100644 doc/bugs/assistant_sometimes_removes_and_re-adds_whole_file/comment_1_52a4748fda6682e6e667501726fd05c6._comment
 create mode 100644 doc/bugs/available_space_miscomputed_on_large_macOS_volume.mdwn
 create mode 100644 doc/bugs/available_space_miscomputed_on_large_macOS_volume/comment_1_cb1e92ef1412e68c12f6a1c9a10a7414._comment
 create mode 100644 doc/bugs/backend_option_for_init_is_in_no_effect__63__.mdwn
 create mode 100644 doc/bugs/backend_option_for_init_is_in_no_effect__63__/comment_1_6b40b5ea277d8e28f0b632701a776587._comment
 create mode 100644 doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo.mdwn
 create mode 100644 doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_1_66ffaa679ba0fe86bba114fd9cdc5a53._comment
 create mode 100644 doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_2_a7617cc63584dafb16bdc9373fb1e304._comment
 create mode 100644 doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_3_ecb57e72c0bf583d1c3461313a83c4f2._comment
 create mode 100644 doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_4_bf0e16f9181438c2050521c5ff5bb7d0._comment
 create mode 100644 doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_5_aeea3ff59c8493c87c313fbaf7614f20._comment
 create mode 100644 doc/bugs/bare_remote_safe_directory.mdwn
 create mode 100644 doc/bugs/batch_commands_miss_journalled_changes_made_while_running.mdwn
 create mode 100644 doc/bugs/be_consistent_with_git_in_handling_http__58____47____47___with___58___.mdwn
 create mode 100644 doc/bugs/be_consistent_with_git_in_handling_http__58____47____47___with___58___/comment_1_c41e4999eb41846eb841b6ce9802b77b._comment
 create mode 100644 doc/bugs/bla__47__.git__47__annex__47__transfer__47__failed__47__download__47__...tmp__58___rename__58___resource_exhausted___40__No_space_left_on_device__41__.mdwn
 create mode 100644 doc/bugs/bla__47__.git__47__annex__47__transfer__47__failed__47__download__47__...tmp__58___rename__58___resource_exhausted___40__No_space_left_on_device__41__/comment_1_644835e95676da0aa38737b3419022e2._comment
 create mode 100644 doc/bugs/blake3_hash_support.mdwn
 create mode 100644 doc/bugs/blake3_hash_support/comment_1_723a531dad2df722514a7cbf1b8e0d8a._comment
 create mode 100644 doc/bugs/blake3_hash_support/comment_2_7be0932328ba4f49c33b0ab14429a283._comment
 create mode 100644 doc/bugs/blake3_hash_support/comment_3_a28c55a1d6158e301cc63d6087d8ab0e._comment
 create mode 100644 doc/bugs/blake3_hash_support/comment_4_3ef2af8eb62a81299e49a3b7dccd337e._comment
 create mode 100644 doc/bugs/broken_repo_when_inodes_exhausted.mdwn
 create mode 100644 doc/bugs/broken_repo_when_inodes_exhausted/comment_1_8ccfac4cea4c54029b96b436ac2114ed._comment
 create mode 100644 doc/bugs/broken_repo_when_inodes_exhausted/comment_2_4c6ced0d3163735c7f4bd5a4a7053159._comment
 create mode 100644 doc/bugs/build_for_OpenBSD_is_outdated.mdwn
 create mode 100644 doc/bugs/build_for_OpenBSD_is_outdated/comment_1_59d9f99747cd3ba93a87ba634824d4ca._comment
 create mode 100644 doc/bugs/build_for_OpenBSD_is_outdated/comment_2_cb4f3d710b0c46b27bebed48bd2e9a21._comment
 create mode 100644 doc/bugs/build_for_OpenBSD_is_outdated/comment_3_99e6c86785c91b8320ec1e7df1e02e2c._comment
 create mode 100644 doc/bugs/bup_often_errors_out_when_-J___62___1.mdwn
 create mode 100644 doc/bugs/bup_often_errors_out_when_-J___62___1/comment_1_1731cfb2662890299ca6daeacdd4bb47._comment
 create mode 100644 doc/bugs/bup_often_errors_out_when_-J___62___1/comment_2_f0f87b7a2c60afba609072566b0048ac._comment
 create mode 100644 doc/bugs/bup_often_errors_out_when_-J___62___1/comment_3_ca2b909c54a772e1eea58b7cbc07bf39._comment
 create mode 100644 doc/bugs/bup_often_errors_out_when_-J___62___1/comment_4_d7156224245542f5468783c1b5763154._comment
 create mode 100644 doc/bugs/bup_often_errors_out_when_-J___62___1/comment_5_90d280582d71f77d75aeedcd30c7c437._comment
 create mode 100644 doc/bugs/cabal_builds_without_assistant.mdwn
 create mode 100644 doc/bugs/can__39__t_build_without_assistant.mdwn
 create mode 100644 doc/bugs/can__39__t_build_without_assistant/comment_1_41b96b4e7f01b79a2e942b8098faa534._comment
 create mode 100644 doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain.mdwn
 create mode 100644 doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_1_6537e928a0d6d5c41b55370f112f4afb._comment
 create mode 100644 doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_b639ad750a4635d95f6ad16a1aa39a3e._comment
 create mode 100644 doc/bugs/can__39__t_get.mdwn
 create mode 100644 doc/bugs/can__39__t_get/comment_1_ef32287828481c161bd913c9db9052a5._comment
 create mode 100644 doc/bugs/can__39__t_get/comment_2_31fe400f4bac516a5c1101612cb06a54._comment
 create mode 100644 doc/bugs/can__39__t_get/comment_3_87d123c04815d38abb92f967829c3a23._comment
 create mode 100644 doc/bugs/can__39__t_get/comment_4_b99cff87dbe38f08f888200dfe7e2436._comment
 create mode 100644 doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options.mdwn
 create mode 100644 doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options/comment_1_d773dee03276e9b0e0b75d0709b76278._comment
 create mode 100644 doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options/comment_2_01cb7ba7d3c19863d39f6fac0d45d235._comment
 create mode 100644 doc/bugs/cannot_add_a_files_with_an_accent_in_it.mdwn
 create mode 100644 doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_1_d465d7f88c8f11b4b636fba56711d745._comment
 create mode 100644 doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_2_b6886a5c38725d93630562a3172d1a5c._comment
 create mode 100644 doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_3_7c34ada3c7b413f2b622149b60757f6e._comment
 create mode 100644 doc/bugs/cannot_add_local_readonly_repo_through_the_webapp.mdwn
 create mode 100644 doc/bugs/cannot_ungroup_a_repository.mdwn
 create mode 100644 doc/bugs/cannot_ungroup_a_repository/comment_1_5476ceb9af2fa2d862a868824e5865e4._comment
 create mode 100644 doc/bugs/cannot_ungroup_a_repository/comment_2_0be32bc80e98c0e10b2eb949b20b18dc._comment
 create mode 100644 doc/bugs/cannot_ungroup_a_repository/comment_3_16f1b5ce3830f9d26df4b14ed666e189._comment
 create mode 100644 doc/bugs/cannot_ungroup_a_repository/comment_4_bc93a6cb01e7d5d43cccb0eca81b5f33._comment
 create mode 100644 doc/bugs/chunks_not_deduplicated.mdwn
 create mode 100644 doc/bugs/chunks_not_deduplicated/comment_1_3890af3669ac6b37b88dac938ed79d16._comment
 create mode 100644 doc/bugs/commitBuffer__58___invalid_argument___40__invalid_character__41__2.mdwn
 create mode 100644 doc/bugs/commitBuffer__58___invalid_argument___40__invalid_character__41__2/comment_1_b56c847c5eda432a4330b4d853a25519._comment
 create mode 100644 doc/bugs/concurrent_git-annex_processes_can_lead_to_locking_issues.mdwn
 create mode 100644 doc/bugs/confirmed.mdwn
 create mode 100644 doc/bugs/conflict_resolution___40____63____41___test_stalls_on_an_occasion.mdwn
 create mode 100644 doc/bugs/conflict_resolution___40____63____41___test_stalls_on_an_occasion/comment_1_ab2c1db51a42a146708b28f4cb3309a6._comment
 create mode 100644 doc/bugs/conflict_resolution___40____63____41___test_stalls_on_an_occasion/comment_2_e7da4a54b27f459d528a7651fd615913._comment
 create mode 100644 doc/bugs/copy+rename_of_file_on_windows_breaks_original.mdwn
 create mode 100644 doc/bugs/copy+rename_of_file_on_windows_breaks_original/comment_1_c6e8e3e76185b6ca25067c2a7e5cd8fc._comment
 create mode 100644 doc/bugs/copy+rename_of_file_on_windows_breaks_original/comment_2_7e2604bad32225682513b51c1be6f571._comment
 create mode 100644 doc/bugs/copy_--fast_--from_--to_checks_destination_files.mdwn
 create mode 100644 doc/bugs/copy_--fast_--from_--to_checks_destination_files/comment_1_2a2997e6f914afb0477f2baa69b174fc._comment
 create mode 100644 doc/bugs/copy_--fast_--from_--to_checks_destination_files/comment_2_f7bf30e8cc2d1995976bde723dfbfe01._comment
 create mode 100644 doc/bugs/copy_--from_--to_does_not_adjust_avail_info.mdwn
 create mode 100644 doc/bugs/copy_--from_--to_does_not_adjust_avail_info/comment_1_d6a1dd2e039dcb6dafcf4675b9244617._comment
 create mode 100644 doc/bugs/copy_--from_--to_does_not_copy_if_present_locally.mdwn
 create mode 100644 doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_1_ae76f27d9ef4ebac7ad57e6aef9a7586._comment
 create mode 100644 doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_2_e857c1d89b350517fcb9829e52d6c6db._comment
 create mode 100644 doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_3_492d7c932fe5663aab916aacc829fb5d._comment
 create mode 100644 doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_4_8cfb9f2c14559a7574edd29b161cf7c7._comment
 create mode 100644 doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_5_fd23d0559018c531595cd06f81290258._comment
 create mode 100644 doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_6_c374eb44ea08f220dbcce5ecb88403fb._comment
 create mode 100644 doc/bugs/copy_-J_--to_local_git_remote_does_not_run_concurrently.mdwn
 create mode 100644 doc/bugs/corrupt_backend_upon_sync__63__.mdwn
 create mode 100644 doc/bugs/corrupt_backend_upon_sync__63__/comment_1_9f248d82f93040b739b56515d18458c7._comment
 create mode 100644 doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been.mdwn
 create mode 100644 doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_1_41cfd5e48426a6ef52bef70a06a6f46a._comment
 create mode 100644 doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_2_bd584ccbe128427fca99e61d66d301c9._comment
 create mode 100644 doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_3_5bb0347215b321444643646f25a35759._comment
 create mode 100644 doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_4_73848a9c783ecf3d9fccdd41b20fbe36._comment
 create mode 100644 doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_5_64bf56f2b0ff206c3caf5cadebfd0cda._comment
 create mode 100644 doc/bugs/creating_a_remote_server_repository.mdwn
 create mode 100644 doc/bugs/creating_a_remote_server_repository/comment_1_de1a370347428245bcfca60eaca96779._comment
 create mode 100644 doc/bugs/creating_a_remote_server_repository/comment_2_482ac9b0f881099910f9bd9f7cda184d._comment
 create mode 100644 doc/bugs/creating_a_remote_server_repository/comment_3_b7c7f684d0eef14fcc00cb2ac0566703._comment
 create mode 100644 doc/bugs/creating_dot-git-as-symlink_workaround_drops_worktree_configuration_from_submodules.mdwn
 create mode 100644 doc/bugs/creating_dot-git-as-symlink_workaround_drops_worktree_configuration_from_submodules/comment_1_ca12be107b7a7dc36cb71595e347ce28._comment
 create mode 100644 doc/bugs/creating_dot-git-as-symlink_workaround_drops_worktree_configuration_from_submodules/comment_2_b7f03cbb85862ed294ecd0f8cbbd2086._comment
 create mode 100644 doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error.mdwn
 create mode 100644 doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_1_aaea812a8f2b04d9b17d1ba9c6fad39f._comment
 create mode 100644 doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_2_c55f2d95f7f08e6f6439f36790e5a538._comment
 create mode 100644 doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_3_b49a3df3b13f564e588824910a07bc43._comment
 create mode 100644 doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_4_a9e6e37dbaa1664d825bdbd64de4fbdd._comment
 create mode 100644 doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_5_3a5eaa2492e4c62a15b4fcee7f96d9dd._comment
 create mode 100644 doc/bugs/cygwin.mdwn
 create mode 100644 doc/bugs/cygwin/comment_1_88b6c7d1f50d0f17443ee74b5886649c._comment
 create mode 100644 doc/bugs/dead_with_no_params_can_mark_repo_with_empty_description_dead.mdwn
 create mode 100644 doc/bugs/describe_what_git-annex_actually_is.mdwn
 create mode 100644 doc/bugs/describe_what_git-annex_actually_is/comment_1_25fc9ffb24fc4c96b81a6393427bbe95._comment
 create mode 100644 doc/bugs/describe_what_git-annex_actually_is/comment_2_1f6ec7cedf56863b261bad0e3f3c80de._comment
 create mode 100644 doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable.mdwn
 create mode 100644 doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_1_2f13e023228fa4938dd314e040a8ec10._comment
 create mode 100644 doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_2_01985a25dbdcfe487e28aaeb5823fded._comment
 create mode 100644 doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_3_136e937bdeda3dec080b49d4755d1fba._comment
 create mode 100644 doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_4_aa4ae6db181b1261a36ad06f223ec28f._comment
 create mode 100644 doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_5_ea204e2190c5a34cfcb3dc0e0710a4e3._comment
 create mode 100644 doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_6_2f998fab7d88a9ade53354d1820248ea._comment
 create mode 100644 doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_7_bfbc9a9fbae3715fea0f4a11549ec8a9._comment
 create mode 100644 doc/bugs/done.mdwn
 create mode 100644 doc/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO.mdwn
 create mode 100644 doc/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO/comment_1_49e8920ad09ae71874686f50f566b77c._comment
 create mode 100644 doc/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO/comment_2_5f5de9dc70bf61c8a369841b24a5ec2a._comment
 create mode 100644 doc/bugs/drop_from_special_hybrid_encryption_remote_fails.mdwn
 create mode 100644 doc/bugs/drop_from_special_hybrid_encryption_remote_fails/comment_1_09e26fdacfb5c159997671680dc95ab7._comment
 create mode 100644 doc/bugs/dropkey_-z_does_not_drop_etc.mdwn
 create mode 100644 doc/bugs/dropkey_-z_does_not_drop_etc/comment_1_278595e3bb8fe54357ea3ee78f780ccf._comment
 create mode 100644 doc/bugs/dropkey_-z_does_not_drop_etc/comment_2_d387dff8a99f9733db7856c4b216beff._comment
 create mode 100644 doc/bugs/dropkey_-z_does_not_drop_etc/comment_3_52f21e094853f787c18f4b9737d9771f._comment
 create mode 100644 doc/bugs/dropkey_-z_does_not_drop_etc/comment_4_a2f221d36d538c89fa5786a3ff12bbfa._comment
 create mode 100644 doc/bugs/dropkey_-z_does_not_drop_etc/comment_5_46d527889606595da1a6b00b631ee2b7._comment
 create mode 100644 doc/bugs/dropkey_-z_does_not_drop_etc/comment_6_d6377ddfb9d907d56c70141b0c3a8a32._comment
 create mode 100644 doc/bugs/dropkey_-z_does_not_drop_etc/comment_7_57b63abb8ccb7fbbd71afd599cb9ef5c._comment
 create mode 100644 doc/bugs/dropkey_-z_does_not_drop_etc/comment_8_c537d9ff75804fe4afc174791c427df4._comment
 create mode 100644 doc/bugs/dropkey_-z_does_not_drop_etc/comment_9_f3bcf33b3b3882073765250c2d113180._comment
 create mode 100644 doc/bugs/dropunused_returns_ok_but_doesn__39__t_delete_files.mdwn
 create mode 100644 doc/bugs/dropunused_returns_ok_but_doesn__39__t_delete_files/comment_1_61fc9ee219d3042e1e32e35b5086ef4e._comment
 create mode 100644 doc/bugs/duplicate.mdwn
 create mode 100644 doc/bugs/enable-tor_failing_on_Android.mdwn
 create mode 100644 doc/bugs/enable-tor_failing_on_Android/comment_1_7592b563c0ddb338e1f39ff6cf5fa1f0._comment
 create mode 100644 doc/bugs/enable-tor_unsupported_on_osx.mdwn
 create mode 100644 doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated.mdwn
 create mode 100644 doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_1_c23de4c4ff536a214c795a805957c9f1._comment
 create mode 100644 doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_2_c75d3a033b1b8699e512df4641a38548._comment
 create mode 100644 doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_3_39e13618336181485175dddc7185160a._comment
 create mode 100644 doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_4_c7a5c3dfaca25fad2edf9575f65629e8._comment
 create mode 100644 doc/bugs/encountering_fatal_error_on_auto_annex_upgrade.mdwn
 create mode 100644 doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_1_041e664be0a5ae635cf5848d9fee380c._comment
 create mode 100644 doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_2_b0deace2dcadbd50c0e0cb155041b255._comment
 create mode 100644 doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_3_60f745051264fcacdce882eb8646b3fe._comment
 create mode 100644 doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_4_9e32aa105bbf11a6d2610a62bfa9517b._comment
 create mode 100644 doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_5_28d35ef30f76ec326363d86ab2948ad3._comment
 create mode 100644 doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote.mdwn
 create mode 100644 doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote/comment_1_ce62150a3bb8c6be05b9f2ddbe64ae8b._comment
 create mode 100644 doc/bugs/error__58___git-annex_filter-process_died_of_signal_15.mdwn
 create mode 100644 doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_1_02da33e41e4f4471d1ae08e9fede229a._comment
 create mode 100644 doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_2_5ebfc18008cf4bc21ffce57067314fc0._comment
 create mode 100644 doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_3_c74018853a4da8e609da1803051a6893._comment
 create mode 100644 doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_4_0a80393f055ead9a3a62da0aa4ec3298._comment
 create mode 100644 doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_5_8b27c6099afea7011717492f53fcdac4._comment
 create mode 100644 doc/bugs/error_creating_internet_archive_item_via_web_UI.mdwn
 create mode 100644 doc/bugs/error_creating_internet_archive_item_via_web_UI/comment_1_4047d926154b444f33674f4db52be04d._comment
 create mode 100644 doc/bugs/error_during_copy_to_S3.mdwn
 create mode 100644 doc/bugs/error_during_copy_to_S3/comment_1_14740dc386510409a8fbda5635eee831._comment
 create mode 100644 doc/bugs/error_during_copy_to_S3/comment_2_157d4bfcb593cf380445caae0523dbbb._comment
 create mode 100644 doc/bugs/error_during_copy_to_S3/comment_3_0e1ed01fc34a5a98c67dd290cb58481f._comment
 create mode 100644 doc/bugs/error_on_only_repository_copy_deletion.mdwn
 create mode 100644 doc/bugs/error_on_only_repository_copy_deletion/comment_1_af394ac0956ab33a77256bcb02ef2a0f._comment
 create mode 100644 doc/bugs/error_out_on_file_size_0_from_external_spec_remote.mdwn
 create mode 100644 doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_1_6af7ba08e93349b2c6176f91ba25a06f._comment
 create mode 100644 doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_2_1d78459554bc12d0423a317bd9f466d1._comment
 create mode 100644 doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_3_aa083a54e0c77cdba9939a061b509488._comment
 create mode 100644 doc/bugs/export__95__import__95__subdir_started_to_fail_some_times.mdwn
 create mode 100644 doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_1_cae9d3f611a2b08d47466e5e5c6e80ed._comment
 create mode 100644 doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_2_8cfd20ada49f2441ad305b2225a738bb._comment
 create mode 100644 doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_3_6b3e21c80fd75d153282cd4170f4b9d2._comment
 create mode 100644 doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_4_e49f6175def95abcd353708acbfc3519._comment
 create mode 100644 doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_5_45a95910d34d602a916282e4e8ec9a08._comment
 create mode 100644 doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_6_78b6f81f900fb4d28808005d223a9da8._comment
 create mode 100644 doc/bugs/export_doesn__39__t_copy_from_adjusted_branch.mdwn
 create mode 100644 doc/bugs/export_doesn__39__t_copy_from_adjusted_branch/comment_1_5ff140be453458e84bd6072594e70d8a._comment
 create mode 100644 doc/bugs/exporttree_interaction_with_adjusted_branch.mdwn
 create mode 100644 doc/bugs/external_remote_export_sent_to_wrong_process.mdwn
 create mode 100644 doc/bugs/external_remote_export_sent_to_wrong_process/comment_1_831bdc33451de9ef5c54592a7455683f._comment
 create mode 100644 doc/bugs/external_remote_export_sent_to_wrong_process/comment_2_8ff0638891c38f423d792f5c3cbfb64f._comment
 create mode 100644 doc/bugs/external_remote_export_sent_to_wrong_process/comment_3_d774a7319bd1a1778adb2004229f057e._comment
 create mode 100644 doc/bugs/external_remote_export_sent_to_wrong_process/comment_4_db89603335995755d145141705ac4584._comment
 create mode 100644 doc/bugs/external_remote_export_sent_to_wrong_process/comment_5_48656a34262fce77ac50836d1d38b9fe._comment
 create mode 100644 doc/bugs/external_remote_export_sent_to_wrong_process/comment_6_e38b776c73affdbb06f3debdddb07e59._comment
 create mode 100644 doc/bugs/external_remote_export_sent_to_wrong_process/comment_7_6a85fcfa3eb0b4974733a62bcc0bbab2._comment
 create mode 100644 doc/bugs/external_remote_export_sent_to_wrong_process/comment_8_c4610009f691ce60940979b73bef4d78._comment
 create mode 100644 doc/bugs/external_remote_protocol_unable_to_parse_command.mdwn
 create mode 100644 doc/bugs/external_remote_protocol_unable_to_parse_command/comment_1_a10012aa7df76a2366ea40da8c37b798._comment
 create mode 100644 doc/bugs/external_remote_protocol_unable_to_parse_command/comment_2_a4556ce5c5f40ca022385cfb3a97ddac._comment
 create mode 100644 doc/bugs/fails_to_authenticate_into_S3_for_initremote__63__.mdwn
 create mode 100644 doc/bugs/fails_to_authenticate_into_S3_for_initremote__63__/comment_1_a7fcd34cf9376e900db832a8010df7d7._comment
 create mode 100644 doc/bugs/failure_getting__47__copying_on_git-lfs_remote___40__gcrypt__41__.mdwn
 create mode 100644 doc/bugs/failure_getting__47__copying_on_git-lfs_remote___40__gcrypt__41__/comment_1_ba5b0ed901c99a23ff72d68b83c0d2fa._comment
 create mode 100644 doc/bugs/fat_support.mdwn
 create mode 100644 doc/bugs/fat_support/comment_1_04bcc4795d431e8cb32293aab29bbfe2._comment
 create mode 100644 doc/bugs/fat_support/comment_2_bb4a97ebadb5c53809fc78431eabd7c8._comment
 create mode 100644 doc/bugs/fat_support/comment_3_df3b943bc1081a8f3f7434ae0c8e061e._comment
 create mode 100644 doc/bugs/fat_support/comment_4_90a8a15bedd94480945a374f9d706b86._comment
 create mode 100644 doc/bugs/fat_support/comment_5_64bbf89de0836673224b83fdefa0407b._comment
 create mode 100644 doc/bugs/fat_support/comment_6_a3b6000330c9c376611c228d746a1d55._comment
 create mode 100644 doc/bugs/fat_support/comment_7_a0ac7f2c44efc8116940c7b94b35e9d0._comment
 create mode 100644 doc/bugs/fat_support/comment_8_acc947643a635eb10a1bff92083a3506._comment
 create mode 100644 doc/bugs/fatal__58___Cannot_handle_files_this_big.mdwn
 create mode 100644 doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_1_e4f03a86a7adc6c5421d1e70c37659e0._comment
 create mode 100644 doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_2_546782c644230741470f9a9de23bd019._comment
 create mode 100644 doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_3_151e7cf96c7d168e1397d111aa47f279._comment
 create mode 100644 doc/bugs/file_extension_not_used_for_URIs_from_special_remotes/comment_1_3b47ce467eee2b903c0ed40e251d4bc1._comment
 create mode 100644 doc/bugs/file_field_omitted_from_import_--json-progress.mdwn
 create mode 100644 doc/bugs/file_field_omitted_from_import_--json-progress/comment_1_bea5a95e6fe120e1ee8c87ce6c55f161._comment
 create mode 100644 doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field.mdwn
 create mode 100644 doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_1_7fef3484f3019539c0a305d5f4a801ce._comment
 create mode 100644 doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_2_32285971869ec56460b3f0eee4edfa23._comment
 create mode 100644 doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_3_7bf423111829ec6b358c6925d012a3e2._comment
 create mode 100644 doc/bugs/filemanager_integration_broken.mdwn
 create mode 100644 doc/bugs/filemanager_integration_broken/comment_1_aa5afe9af21e534a6c0683064296d9e6._comment
 create mode 100644 doc/bugs/find_by_metadata_is_slow.mdwn
 create mode 100644 doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__.mdwn
 create mode 100644 doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/comment_1_70e050ef94ab57e74b45b18f3f9ca1f3._comment
 create mode 100644 doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/comment_2_35df3798ddb3424fb26e11df53420d2d._comment
 create mode 100644 doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/comment_3_584fce9a8a501e380426c123505bfdf9._comment
 create mode 100644 doc/bugs/forwarded.mdwn
 create mode 100644 doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_.mdwn
 create mode 100644 doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_/comment_1_6b2c645f9ca440f4707c671a94566bb7._comment
 create mode 100644 doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_/comment_2_52185ae4ebdfcb61840444e3ef1e0404._comment
 create mode 100644 doc/bugs/fsck_--json_incomplete_error_reporting.mdwn
 create mode 100644 doc/bugs/fsck_--json_incomplete_error_reporting/comment_1_979d52131fe94a9e800f939da88b369e._comment
 create mode 100644 doc/bugs/fsck_--json_incomplete_error_reporting/comment_2_71fd5ede0aa24fcc6522a03010ccec5c._comment
 create mode 100644 doc/bugs/fsck_does_not_detect_corruption_on_yt_vids.mdwn
 create mode 100644 doc/bugs/fsck_does_not_detect_corruption_on_yt_vids/comment_1_e7f61f04af8cc4c7ff9125fa37b90f4f._comment
 create mode 100644 doc/bugs/fsck_does_not_detect_corruption_on_yt_vids/comment_2_8f26d11cbfceb6928648fe40b890c49b._comment
 create mode 100644 doc/bugs/fsck_ignores_--json-error-messages_when_--quiet.mdwn
 create mode 100644 doc/bugs/fsck_ignores_--json-error-messages_when_--quiet/comment_1_a23d96af8c0e418350a73cbce5bc24be._comment
 create mode 100644 doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote.mdwn
 create mode 100644 doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_1_ce9085e6330625dabf479e6e3beeeb47._comment
 create mode 100644 doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_2_59e89c065a3cd8f7c80cfdb3c2c2808d._comment
 create mode 100644 doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_3_264a1b39c1677545af4c02901dd23d22._comment
 create mode 100644 doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_4_f08e305e39953c5c1906df0fb2eb113b._comment
 create mode 100644 doc/bugs/fsck_tells___39__ok__39___also_if_no_file_present.mdwn
 create mode 100644 doc/bugs/gcrypt__58___WARNING__58___Remote_ID_has_changed__33__.mdwn
 create mode 100644 doc/bugs/gcrypt_remotes_using_relative_paths.mdwn
 create mode 100644 doc/bugs/gcrypt_remotes_using_relative_paths/comment_1_b4523baf0cdfc2ad70cded93b1629eca._comment
 create mode 100644 doc/bugs/gcrypt_remotes_using_relative_paths/comment_2_45281c947992c2ab124efd0f109255d6._comment
 create mode 100644 doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation.mdwn
 create mode 100644 doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_10_66386390af02c67c2e5bace223251f53._comment
 create mode 100644 doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_11_f818dadfa541520ac7ad2409b9174776._comment
 create mode 100644 doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_1_18e194d53646cb6049058635ad54fe1f._comment
 create mode 100644 doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_2_2766d9082373c11628006f14262509ad._comment
 create mode 100644 doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_3_a15a47b120c0c1c1c8ee5050d6105bb1._comment
 create mode 100644 doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_4_72f08e454aad5092acc609a6597d9872._comment
 create mode 100644 doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_5_81f23cf6fe835358c9b88af50eab22a5._comment
 create mode 100644 doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_6_bbcf4c05813adc2239c1f6017425f1c9._comment
 create mode 100644 doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_7_23715781fb5fd3ece5e042be069812ab._comment
 create mode 100644 doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_8_a037b7da3c4f2e04b23706592f04b0ac._comment
 create mode 100644 doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_9_6efb1a75b236b4384d1d2fccc3ab30b8._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing.mdwn
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_10_10fea4ce67f5f9c6c33ba2a23a185f8a._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_11_36dd4a0dba9e544d18376013e879b9c2._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_13_795ffef1e6a9f1acbd4394c1fca3818e._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_13_afae18b8b3a17f376b9a345059d9dbd4._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_13_bdfbcb8b6052a3c904e46678fce6adeb._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_14_9f6fde051e877638a56094d3179dc550._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_16_4d375d35a0d05d99c7becf591823d6b8._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_17_f687c46fb89009712247fe480f0f9566._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_18_0e5796c55c76dc8b37f9fd875d87eff0._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_19_216aefa4a78d13cc0c46780161921a36._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_1_ea9363fac84619b72d6c9f2a3a5c2d6d._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_20_981cc786be798a612046d207c0f85955._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_21_eabe406ab0d6e71c3f5f30908016a592._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_22_711bf1ba8688bdc3bf33e7103340bc11._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_23_3671d133d18f6722901ed01a1fa38164._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_24_054db0e62994590631737b9bd768d901._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_25_4766362f74f135887d5b6103db9a8a06._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_26_d02b310b007b304e0eda23bd5e565851._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_27_45168f110bded2f8c8f9777e1edda945._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_2_8b11e01481065814d2b35f9d728df9f7._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_3_f06b9085e1d48298c6c1739afb17d2bb._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_4_422aed4fc2729483e1479cadd54f45e1._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_5_28da709b2152b1ce1d0c926b099febad._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_6_c9594a39c44f7fd6649c418dbb5d2c59._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_7_7a7f6e9793817884a309632e4ebaba1b._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_8_0b507f49b6c23d9a9e1557fe96ad58b1._comment
 create mode 100644 doc/bugs/get_is_busy_doing_nothing/comment_9_6209db4f931bced0f6782d231aa45452._comment
 create mode 100644 doc/bugs/gets_stuck_in_Remote_Tests___40____63____41___while_running_on_OSX_with_HOME_on_crippled_FS.mdwn
 create mode 100644 doc/bugs/git-annex-copy_fails_with___34__thread_blocked_indefinitely_in_an_STM_transaction__34__.mdwn
 create mode 100644 doc/bugs/git-annex-copy_fails_with___34__thread_blocked_indefinitely_in_an_STM_transaction__34__/comment_1_c9d7057b9c7b7811a29dcc59b98f97d0._comment
 create mode 100644 doc/bugs/git-annex-enableremote_confusing_behavior_when_there_is_a_git_remote_with_same_name_as_special_remote.mdwn
 create mode 100644 doc/bugs/git-annex-enableremote_confusing_behavior_when_there_is_a_git_remote_with_same_name_as_special_remote/comment_1_7f28aecc6ecefd7d47979f73330759d2._comment
 create mode 100644 doc/bugs/git-annex-import_imports_outside_of_directory.mdwn
 create mode 100644 doc/bugs/git-annex-import_imports_outside_of_directory/comment_10_30dab036949bd35e026a31974c4e5164._comment
 create mode 100644 doc/bugs/git-annex-import_imports_outside_of_directory/comment_1_376302b0bac94ee81c0dfdcb647f3b3b._comment
 create mode 100644 doc/bugs/git-annex-import_imports_outside_of_directory/comment_2_e74c71a5574a8e99503ac83a27d48533._comment
 create mode 100644 doc/bugs/git-annex-import_imports_outside_of_directory/comment_3_778e176a44aa57e9223aab1a45c931f3._comment
 create mode 100644 doc/bugs/git-annex-import_imports_outside_of_directory/comment_4_3406ba56525cb59b8b1b366e2b3dc291._comment
 create mode 100644 doc/bugs/git-annex-import_imports_outside_of_directory/comment_5_5b41c061786fd49c75d49aa2cc70bb9f._comment
 create mode 100644 doc/bugs/git-annex-import_imports_outside_of_directory/comment_6_6d559ba943ef2a8fed285c463eb2a641._comment
 create mode 100644 doc/bugs/git-annex-import_imports_outside_of_directory/comment_6_d6aaa0519faa596fa42d22fba405cbff._comment
 create mode 100644 doc/bugs/git-annex-import_imports_outside_of_directory/comment_7_4f9816f7c9a61289bef98820b1ec25cc._comment
 create mode 100644 doc/bugs/git-annex-import_imports_outside_of_directory/comment_9_372c44296c1a03778e201a47ec45bee6._comment
 create mode 100644 doc/bugs/git-annex-import_stalls_and_uses_all_ram_available.mdwn
 create mode 100644 doc/bugs/git-annex-import_stalls_and_uses_all_ram_available/comment_1_ca22165fc77a57979ad6e19c60693b21._comment
 create mode 100644 doc/bugs/git-annex-import_stalls_and_uses_all_ram_available/comment_2_2025b1662067bbfaab14576d9e20a6ab._comment
 create mode 100644 doc/bugs/git-annex-import_stalls_and_uses_all_ram_available/comment_3_5943379450c860b2885121e7f0abd42a._comment
 create mode 100644 doc/bugs/git-annex-install_for_Android_crashes_on___34__arm7el__34__.mdwn
 create mode 100644 doc/bugs/git-annex-install_for_Android_crashes_on___34__arm7el__34__/comment_1_af1de40a3c83f8632f98ecde5a5271f5._comment
 create mode 100644 doc/bugs/git-annex-move_not_using_parallelism__63__.mdwn
 create mode 100644 doc/bugs/git-annex-move_not_using_parallelism__63__/comment_1_1080a771213dc524cbd072591030c98c._comment
 create mode 100644 doc/bugs/git-annex-move_not_using_parallelism__63__/comment_2_a83e833b329df094e1bc7945db9686b0._comment
 create mode 100644 doc/bugs/git-annex-move_not_using_parallelism__63__/comment_3_bdd1aabe7120c4e6b5999aaf396067bc._comment
 create mode 100644 doc/bugs/git-annex-repair_claims_success_then_failure.mdwn
 create mode 100644 doc/bugs/git-annex-repair_claims_success_then_failure/comment_1_de8dfda0bc321e573ab9d17aec1ecb84._comment
 create mode 100644 doc/bugs/git-annex-shell/comment_1_3d2c3827de34509c0a5595eda07dd18f._comment
 create mode 100644 doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to.mdwn
 create mode 100644 doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/comment_1_b0a4f459d40bca7a0b24d1bec1e0f4a8._comment
 create mode 100644 doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/comment_3_335fea47cef83b6dfad7ce8c53193f82._comment
 create mode 100644 doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/comment_3_abaeb3d5c0322deeec790d80b2948549._comment
 create mode 100644 doc/bugs/git-annex-shell_fails_to_run_true.mdwn
 create mode 100644 doc/bugs/git-annex-shell_fails_to_run_true/comment_1_7573eb95bdecc3ecc9b31599bd309d3d._comment
 create mode 100644 doc/bugs/git-annex-shell_fails_to_run_true/comment_2_5be34b5ffaee39013d24daf83a8dd437._comment
 create mode 100644 doc/bugs/git-annex-sync_not_quite_idempotent__63__.mdwn
 create mode 100644 doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_1_d90a0f326840137872f551e54c2d2a53._comment
 create mode 100644 doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_2_ba60267d8b34ae9e277ae992dcfcde96._comment
 create mode 100644 doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_3_2381583c924561cbe46186fbd8fbf654._comment
 create mode 100644 doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_4_44c082a9321806ca2a60debf829f9c39._comment
 create mode 100644 doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_5_86187583d3128f2d64d1c5d58b31283c._comment
 create mode 100644 doc/bugs/git-annex.linux.6.20180914_-__62___assistant_requires_s3_bucket.mdwn
 create mode 100644 doc/bugs/git-annex.linux.6.20180914_-__62___assistant_requires_s3_bucket/comment_1_5ec1d63e8f2896876fc88d53b6170b74._comment
 create mode 100644 doc/bugs/git-annex__58___.git__47__annex__47__keys.tmp__47__db__58___setFileMode__58___permission_denied___40__Operation_not_permitted__41__.mdwn
 create mode 100644 doc/bugs/git-annex__58___.git__47__annex__47__keys.tmp__47__db__58___setFileMode__58___permission_denied___40__Operation_not_permitted__41__/comment_1_2d68f1f5019621bccfd59be5066fdcbe._comment
 create mode 100644 doc/bugs/git-annex__58___.git__47__annex__47__keys.tmp__47__db__58___setFileMode__58___permission_denied___40__Operation_not_permitted__41__/comment_2_89b9f0cabdfac72ce6b0b9461672705f._comment
 create mode 100644 doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__.mdwn
 create mode 100644 doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_1_e962317a939bf76097ae1a3b53b146e6._comment
 create mode 100644 doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_2_b32472b4c9b61e7a33dca802ecafb05b._comment
 create mode 100644 doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_3_fcfea3216831df9afbd855fbd842c27e._comment
 create mode 100644 doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_4_30d0b40efa59eeecb8a4be6d1baa1520._comment
 create mode 100644 doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_5_4af107f3184bc2abd2c9693167018628._comment
 create mode 100644 doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_6_f96027f1e3c405809fae42ce8533c6d1._comment
 create mode 100644 doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_7_b6fe89deb468a7e4f63f7faab147e3fb._comment
 create mode 100644 doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_8_ebec5d9266604f03959dc16d933ff4a4._comment
 create mode 100644 doc/bugs/git-annex__58___fd__58__14__58___hGetLine__58___end_of_file.mdwn
 create mode 100644 doc/bugs/git-annex__58___fd__58__14__58___hGetLine__58___end_of_file/comment_1_36756f5d9d591cc52113c5cc0c1eae91._comment
 create mode 100644 doc/bugs/git-annex__58___readDirStream__58___inappropriate_type.mdwn
 create mode 100644 doc/bugs/git-annex__58___readDirStream__58___inappropriate_type/comment_1_1b988c92ae79e6d9ddc487bea358dec1._comment
 create mode 100644 doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget.mdwn
 create mode 100644 doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_1_babea9a16f25b471026732ea63dd78a8._comment
 create mode 100644 doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_2_dd24434631ae3898e8f5c1f878d1965f._comment
 create mode 100644 doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_3_70f2b9e61e90528fdbef4d8a6e8dd972._comment
 create mode 100644 doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_4_11e9ceb40aa5492a1a3e9ebfbd246832._comment
 create mode 100644 doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_5_20ee285d62c35e18b78b121d8e4de81b._comment
 create mode 100644 doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog.mdwn
 create mode 100644 doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_1_b83888a98075125dd043f323c99da03b._comment
 create mode 100644 doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_2_4a7d824b6e75693cf47f6efbf2c99e2e._comment
 create mode 100644 doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_3_cbbeaa691d102bd7d29f5e9bad9d6f53._comment
 create mode 100644 doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_4_094191b806ac76b2aef325733fe37136._comment
 create mode 100644 doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_5_c97926b15ba320f57a6441f9844cb139._comment
 create mode 100644 doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_6_3b70a60ef1c47871a3933176eac38174._comment
 create mode 100644 doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_7_fc56ec87725c7427794b70ee2ba2822a._comment
 create mode 100644 doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__.mdwn
 create mode 100644 doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_1_db7b584c1e932d24e0dcf464b023a659._comment
 create mode 100644 doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_2_72e9ecc6acdc555e36f5588120d070fa._comment
 create mode 100644 doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_3_b2ef283a3933e22542e05ce9a1acef7d._comment
 create mode 100644 doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_4_7a139eb2c11ab2e32d22ca0f8bb648a5._comment
 create mode 100644 doc/bugs/git-annex_died_of_signal_11_when_syncing_content.mdwn
 create mode 100644 doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_1_e982f985e5ca57454725e9e9a482e30c._comment
 create mode 100644 doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_2_e920f624ccf2e3a9c71a00105ebc3595._comment
 create mode 100644 doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_3_373e63d55e07cb5cdecc4e01d5d52b79._comment
 create mode 100644 doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_4_678a0136f143d2d7874226b3fc744eb2._comment
 create mode 100644 doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights.mdwn
 create mode 100644 doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_1_2533800ab5a95c5d71c3b47a630e751a._comment
 create mode 100644 doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_2_5b71785acf16a8d9ea457726599daef3._comment
 create mode 100644 doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_3_63e4ff79bc683a70dd9a85c66e26e56a._comment
 create mode 100644 doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows.mdwn
 create mode 100644 doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_1_f0d30a953f072f8d9a929a4a6ba69914._comment
 create mode 100644 doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_2_504ea07f798838710cdbf6133135c815._comment
 create mode 100644 doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_3_a9bd50ebe805afefab103da31b88cf89._comment
 create mode 100644 doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_4_f2bd555ca36b42dac6a213e7c947f1f9._comment
 create mode 100644 doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_5_e00d70ba6b88d9cf60fcb183f7ea4980._comment
 create mode 100644 doc/bugs/git-annex_findkeys_does_not_know_--largerthan.mdwn
 create mode 100644 doc/bugs/git-annex_findkeys_does_not_know_--largerthan/comment_1_f6484f69669439ef49513b84d3bd91cf._comment
 create mode 100644 doc/bugs/git-annex_fsck_in_quiet_mode_don__39__t_report_the_files_it_failed_to_download.mdwn
 create mode 100644 doc/bugs/git-annex_fsck_in_quiet_mode_don__39__t_report_the_files_it_failed_to_download/comment_1_074e49431bd18c43164872de3733b0e8._comment
 create mode 100644 doc/bugs/git-annex_get_with_umlaut_characters_in_filenames.mdwn
 create mode 100644 doc/bugs/git-annex_get_with_umlaut_characters_in_filenames/comment_1_0724d70364f7067d864a80a39e2e609a._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content.mdwn
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_10_d04b5bc031f73363d44b81f436b59781._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_11_cab37d851237a7798f74867e08aaafb9._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_12_466a365bca48065cc6b9e280b5c385a5._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_13_0eb12582a3e182b697a07b833cfbe384._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_1_ed54af250541e2add89938b939016659._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_2_786b21544854ad719eac07d08ba8d206._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_3_190a153449f7bb07fb4aca89db236881._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_4_492a11bcabc20b02239bc3b12438a51a._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_5_1367e6e461a9a049527197c262635c2f._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_6_123c81ad10aef15814f1c831e18c0a23._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_7_2885c2f164dbe59234568966e901bdd7._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_8_559e5c3b5ea9c166b3aa4a2e975643c6._comment
 create mode 100644 doc/bugs/git-annex_is_slow_at_reading_file_content/comment_9_c8b4c2e955b4ef5caaaaf2f834fb37f8._comment
 create mode 100644 doc/bugs/git-annex_merge_stalls.mdwn
 create mode 100644 doc/bugs/git-annex_merge_stalls/comment_1_31578a754945bdcb902c62ff58704bcb._comment
 create mode 100644 doc/bugs/git-annex_merge_stalls/comment_2_f3b6bf180466b5931bfd20b2f0229422._comment
 create mode 100644 doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment
 create mode 100644 doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
 create mode 100644 doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_1_8573d3bb5ae9f3490265767128027ed1._comment
 create mode 100644 doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_2_34fa48bba13bf896e6b3809ec22fc58e._comment
 create mode 100644 doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_3_9b3040c521ec1992ec03c06a579dd627._comment
 create mode 100644 doc/bugs/git-annex_sometimes_messes_up___126____47__.git-credentials.mdwn
 create mode 100644 doc/bugs/git-annex_sometimes_messes_up___126____47__.git-credentials/comment_1_5fafcc62656bdec4eecdf35cee4c6a8f._comment
 create mode 100644 doc/bugs/git-annex_sometimes_messes_up___126____47__.git-credentials/comment_2_f8435628336b472107b478fe11628186._comment
 create mode 100644 doc/bugs/git-annex_stack.yml_misses_extra-deps..mdwn
 create mode 100644 doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup.mdwn
 create mode 100644 doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_1_b550f292359b44977481bf69abad4012._comment
 create mode 100644 doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_2_76e6c1d4db27bcc1767ba34e13e8211c._comment
 create mode 100644 doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_3_14007c8e927b75c5706e80cc4242fae4._comment
 create mode 100644 doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_4_f3266b74517b421e5310e67818fe3969._comment
 create mode 100644 doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_5_1a07f15eb0353768c1e67a1e47e2e494._comment
 create mode 100644 doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_6_7d0d49fd165af5e30606982e05335d34._comment
 create mode 100644 doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_7_2b0ba2a15af04731a966a029be9b81aa._comment
 create mode 100644 doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS.mdwn
 create mode 100644 doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_1_b87b50ca08bf90ecb7d741a6baa1dc4d._comment
 create mode 100644 doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_2_6c95d0fd70fbf41eea4e6575486af3f5._comment
 create mode 100644 doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_3_6dd54179aad379bb22638db518bd377f._comment
 create mode 100644 doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_4_614da8cad46df5c71539cc5a8ed11831._comment
 create mode 100644 doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_5_5fa9d10ebd639eb1a836866b99e90aab._comment
 create mode 100644 doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_6_8e05f8769870b3f1aec77fca06f37284._comment
 create mode 100644 doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment
 create mode 100644 doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_8_48026cf7c187e97d53d15d35ed2c3670._comment
 create mode 100644 doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory.mdwn
 create mode 100644 doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_1_984f75d8078f2809486f38ecb3b16be3._comment
 create mode 100644 doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_2_c0f07e2d4bb142389629050479dd1465._comment
 create mode 100644 doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_3_7a58a884aaacedca9697b17cd5248214._comment
 create mode 100644 doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_aa4f1806207138115d2a95935bb0546b._comment
 create mode 100644 doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_5_fa95f93416e3d6e66af557df6562f1e5._comment
 create mode 100644 doc/bugs/git_annex_assist_adds_gitignored_files.mdwn
 create mode 100644 doc/bugs/git_annex_assistant_adds_dotfiles_to_the_annex.mdwn
 create mode 100644 doc/bugs/git_annex_assistant_exits_with_failure.mdwn
 create mode 100644 doc/bugs/git_annex_assistant_exits_with_failure/comment_1_247d4da208cd700851d48f13534d5f7c._comment
 create mode 100644 doc/bugs/git_annex_assistant_exits_with_failure/comment_2_c6c04006b1d9aa6be92f5a970ba60618._comment
 create mode 100644 doc/bugs/git_annex_assistant_exits_with_failure/comment_3_eabad530a55adfa4be3eae0f743d3309._comment
 create mode 100644 doc/bugs/git_annex_assistant_exits_with_failure/comment_4_204764bb40509d8650386227ea166a6e._comment
 create mode 100644 doc/bugs/git_annex_assistant_exits_with_failure/comment_5_0453ae9123b359757e63c6eb5f12811b._comment
 create mode 100644 doc/bugs/git_annex_assistant_exits_with_failure/comment_6_5b0310038a8b45d2083f39ea75c1a979._comment
 create mode 100644 doc/bugs/git_annex_assistant_exits_with_failure/comment_7_63b3ec113d52501237abbe6ee1ef5fa5._comment
 create mode 100644 doc/bugs/git_annex_assistant_failing_with_ARM_NAS.mdwn
 create mode 100644 doc/bugs/git_annex_assistant_failing_with_ARM_NAS/comment_1_00ca17dca9da3ddb81514d319cae0ef4._comment
 create mode 100644 doc/bugs/git_annex_assistant_leaks_a_lot_of_memory.mdwn
 create mode 100644 doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_1_a4805854c448e4bc70a47f5555e0f73c._comment
 create mode 100644 doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_2_e9dca04e0456ca7356996365a4b87d59._comment
 create mode 100644 doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_3_45ae862d4f940341d48d179583e65d66._comment
 create mode 100644 doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_4_d597e15e9693ce6e8c1ca80cb225b044._comment
 create mode 100644 doc/bugs/git_annex_cannot_get_my_files_after_clone.mdwn
 create mode 100644 doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_1_52c91f8d2e8086b26a078a02d036c197._comment
 create mode 100644 doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_2_545c9daafc63c5cdb80763b929c8d622._comment
 create mode 100644 doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_3_ef9b32d9ba1b80c313db48be36cc90d1._comment
 create mode 100644 doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_4_d1d13d1f3366026957d572b930cafa4b._comment
 create mode 100644 doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_5_f8b58f9c5acb509871cc4a64b66de6f3._comment
 create mode 100644 doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn
 create mode 100644 doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment
 create mode 100644 doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment
 create mode 100644 doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_3_9fa2fb82ae3d17a77a9645870e1e12e5._comment
 create mode 100644 doc/bugs/git_annex_copy_fails_without_error_message_on_macOS___40__but_works_on_Linux__41__.mdwn
 create mode 100644 doc/bugs/git_annex_copy_fails_without_error_message_on_macOS___40__but_works_on_Linux__41__/comment_1_6c044f007e66b951cf08b86f9be49ed3._comment
 create mode 100644 doc/bugs/git_annex_copy_to_s3_out_of_memory.mdwn
 create mode 100644 doc/bugs/git_annex_copy_to_s3_out_of_memory/comment_1_5c0b73214c8f0ecb197cf0e109ff2729._comment
 create mode 100644 doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de.mdwn
 create mode 100644 doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_1_5ba4f22bda2f5438fb08753cf149b649._comment
 create mode 100644 doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_2_b096cfdf26bfedfff16d882d7b2e060d._comment
 create mode 100644 doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_3_210be77aabb0ef5b85865cd08c51861e._comment
 create mode 100644 doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_4_bb974d882fbb31aa54e6de38410a2318._comment
 create mode 100644 doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_5_be655cbea27b6c87d298a75e1697a87d._comment
 create mode 100644 doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_6_72d1dac6627bbe22d5bd140215d82c47._comment
 create mode 100644 doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_7_8a8dfb15684525e156d6334e9f67a55c._comment
 create mode 100644 doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_8_f1a6e413756066659020e20147373a11._comment
 create mode 100644 doc/bugs/git_annex_enableremote_gcrypt_failure_leaves_a_remote.mdwn
 create mode 100644 doc/bugs/git_annex_enableremote_locking_issue.mdwn
 create mode 100644 doc/bugs/git_annex_forget_does_not_propagate.mdwn
 create mode 100644 doc/bugs/git_annex_forget_does_not_propagate/comment_1_591c3c59d831ed94268f90505a8baaee._comment
 create mode 100644 doc/bugs/git_annex_forget_does_not_propagate/comment_2_9026452178c82d0661acc96d009e3764._comment
 create mode 100644 doc/bugs/git_annex_get_--batch_does_not_work.mdwn
 create mode 100644 doc/bugs/git_annex_get_--batch_does_not_work/comment_1_52311b95bf29706d2b1afb3904428047._comment
 create mode 100644 doc/bugs/git_annex_get_--batch_does_not_work/comment_2_b4fa614626393e01c51b937401bbaa23._comment
 create mode 100644 doc/bugs/git_annex_get_--batch_does_not_work/comment_3_e972b9fb5c6af4ecd295dc954bb2f55a._comment
 create mode 100644 doc/bugs/git_annex_get_--batch_does_not_work/comment_4_f0c498dad3f4d51e33de863165f29410._comment
 create mode 100644 doc/bugs/git_annex_get_--batch_does_not_work/comment_5_603adcb0b5091ac2fb3c9225d2925dc3._comment
 create mode 100644 doc/bugs/git_annex_get_--batch_does_not_work/comment_6_56716644ee1534b8fe90ba502856455c._comment
 create mode 100644 doc/bugs/git_annex_get_--batch_does_not_work/comment_7_b0588132d02f982da7c7208087b0afe2._comment
 create mode 100644 doc/bugs/git_annex_get_--batch_does_not_work/comment_8_0e776c598c5e0f4f51f5e9ade8c3f0e2._comment
 create mode 100644 doc/bugs/git_annex_get_--batch_does_not_work/comment_9_0c802c9c5734e7dfc8cd72962fcf2983._comment
 create mode 100644 doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects.mdwn
 create mode 100644 doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_1_9f9d5c18c27dfd33a5bf2c593ee65b58._comment
 create mode 100644 doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_2_f64891ff6fe0cd0be6a356ab8fe42817._comment
 create mode 100644 doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_3_d980c1e2d788324049475e468a0d6fab._comment
 create mode 100644 doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_4_09b860a14bb8bd49f2067e8ddb0aacfc._comment
 create mode 100644 doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_5_1e737b740bc7d95f3329e3481d55fd35._comment
 create mode 100644 doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_6_6def3c88ced56753e4b12ce221d33769._comment
 create mode 100644 doc/bugs/git_annex_move_--unused_not_moving_some_files.mdwn
 create mode 100644 doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_1_3fe94ad69d28f16598fdb8f98d7ffa54._comment
 create mode 100644 doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_2_91cdee93a29eefca78c1e49878b71574._comment
 create mode 100644 doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_3_40d839105047f4ac2996b53705601cc4._comment
 create mode 100644 doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_4_023fb25740f8363f8e72c12f020aa0f4._comment
 create mode 100644 doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_5_85ef3d6a4f2e67f16ee4bd30e58ef4fc._comment
 create mode 100644 doc/bugs/git_annex_push_fails_on_Windows.mdwn
 create mode 100644 doc/bugs/git_annex_push_fails_on_Windows/comment_1_a7866c2131df8132e9aecebda085294c._comment
 create mode 100644 doc/bugs/git_annex_push_fails_on_Windows/comment_2_d5c9fd2acdd5b320563a708889e82852._comment
 create mode 100644 doc/bugs/git_annex_push_fails_on_Windows/comment_3_fe3818a184e723f86d094253461d8f44._comment
 create mode 100644 doc/bugs/git_annex_repair_failed__58___missing_objects.mdwn
 create mode 100644 doc/bugs/git_annex_repair_failed__58___missing_objects/comment_1_9f2166545159890b05ea061e2ab21a4f._comment
 create mode 100644 doc/bugs/git_annex_repair_failed__58___missing_objects/comment_2_7571de4a3ab7030a877fa198fe4810b1._comment
 create mode 100644 doc/bugs/git_annex_repair_failed__58___missing_objects/comment_3_317bee33fe675a5abb6fe65540a33d25._comment
 create mode 100644 doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress.mdwn
 create mode 100644 doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress/comment_1_6c7f745ee77e9b7502cb13d3babf211b._comment
 create mode 100644 doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress/comment_2_e2139a3d1d06772d06992a38140e51d3._comment
 create mode 100644 doc/bugs/git_annex_still_deleting_content_when_merging.mdwn
 create mode 100644 doc/bugs/git_annex_still_deleting_content_when_merging/comment_1_cb51e25c5e1656dcbb73b3ff680341f0._comment
 create mode 100644 doc/bugs/git_annex_still_deleting_content_when_merging/comment_2_bbbcce7fc5f34d733126c42be8ec0a1d._comment
 create mode 100644 doc/bugs/git_annex_still_deleting_content_when_merging/comment_3_f31a73e0e2c43f6a7f158455eadaa56c._comment
 create mode 100644 doc/bugs/git_annex_sync_remove_all_recently_added_files.mdwn
 create mode 100644 doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_1_58faf8b37bb276e6176233d3daa24db9._comment
 create mode 100644 doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_2_a39ce4a60c1dc7817c84f90eac7251a6._comment
 create mode 100644 doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_3_3cb07eabd0e1802dbe477bdc88f647fb._comment
 create mode 100644 doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_4_65c5f5f34eb8535d244d6075caf57c21._comment
 create mode 100644 doc/bugs/git_annex_test_fails_when_run_through_powershell.mdwn
 create mode 100644 doc/bugs/git_annex_test_fails_when_run_through_powershell/comment_1_014466c5da1922d34a498648baeeba26._comment
 create mode 100644 doc/bugs/git_annex_test_fails_when_run_through_powershell/comment_2_241ab999007eecaa2cd5a854e722e315._comment
 create mode 100644 doc/bugs/git_annex_upgrade_fails.mdwn
 create mode 100644 doc/bugs/git_annex_upgrade_fails/comment_1_26e3224b9aad57837969c309ae4bdcd2._comment
 create mode 100644 doc/bugs/git_annex_upgrade_loses_track_of_files_with___34____38____34___character___40__and_probably_others__41__.mdwn
 create mode 100644 doc/bugs/git_annex_upgrade_loses_track_of_files_with___34____38____34___character___40__and_probably_others__41__/comment_1_861506e40e0d04d2be98bbfe9188be89._comment
 create mode 100644 doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree.mdwn
 create mode 100644 doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_1_cc3ea43301cd17b55794f9b9dd1e91cf._comment
 create mode 100644 doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_2_fb75f5941d355947b3f06165825dd012._comment
 create mode 100644 doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_3_8c7b21c8e500de719fc2909d0c9027e0._comment
 create mode 100644 doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_4_423126c9884267b3466470d4ec7301ce._comment
 create mode 100644 doc/bugs/git_checkout_slow_with_unlocked_files/comment_1_80d9a46c608117fb9a381c59d4605ff4._comment
 create mode 100644 doc/bugs/git_commit_smudges_unncessarily.mdwn
 create mode 100644 doc/bugs/git_commit_smudges_unncessarily/comment_1_202cb8adc7a7b1119f5b4c1f5c6e9c7e._comment
 create mode 100644 doc/bugs/git_commit_smudges_unncessarily/comment_2_5b230c4b74da48099e8be0e264bbf3e6._comment
 create mode 100644 doc/bugs/git_commit_smudges_unncessarily/comment_3_c30e84ae438810cbab70c401fd5125c0._comment
 create mode 100644 doc/bugs/git_error___34__update__95__ref_failed_for_ref__34__.mdwn
 create mode 100644 doc/bugs/git_error___34__update__95__ref_failed_for_ref__34__/comment_1_60ea64baccef82dc03ab300ca9b5e2b5._comment
 create mode 100644 doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch.mdwn
 create mode 100644 doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_1_1a6674245aed0c325361043d1100daec._comment
 create mode 100644 doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_2_ccadd646ec0fe7abec461c110bfb7ae7._comment
 create mode 100644 doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_3_2a6ef51c96a914be5d248b526ad37394._comment
 create mode 100644 doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_4_f9588887f75c0d17b87f2718b0584a94._comment
 create mode 100644 doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_5_a9d6cf6cd38bfa6f391beaf6831b0ef4._comment
 create mode 100644 doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_6_cfefa7ac1f538566ee028aa3996e22cd._comment
 create mode 100644 doc/bugs/git_init_fails_on_a_worktree_branch.mdwn
 create mode 100644 doc/bugs/git_init_fails_on_a_worktree_branch/comment_1_6614fc4b8f191702c1b78c5a3ce5de50._comment
 create mode 100644 doc/bugs/git_keeps_refreshing_index.mdwn
 create mode 100644 doc/bugs/git_keeps_refreshing_index/comment_1_bc76561ae4aaf932217c40109a8d04bd._comment
 create mode 100644 doc/bugs/git_keeps_refreshing_index/comment_2_a4c9ccb93a809aff61ae208d31ba0363._comment
 create mode 100644 doc/bugs/git_keeps_refreshing_index/comment_3_919fb06b3fc7fe9b54797a805873e3c8._comment
 create mode 100644 doc/bugs/git_keeps_refreshing_index/comment_4_b73f9c5603bc69867e1619d871a8abb7._comment
 create mode 100644 doc/bugs/git_keeps_refreshing_index/comment_5_f1b07147627b087231c776522ddc2826._comment
 create mode 100644 doc/bugs/git_keeps_refreshing_index/comment_6_e0bfde0d53042ce8d310f356f88c610b._comment
 create mode 100644 doc/bugs/git_keeps_refreshing_index/comment_7_35dff672dfd3c6fdc2b9fcdb9a58e154._comment
 create mode 100644 doc/bugs/git_proxy_uses_ls-files_without_--exclude-standard.mdwn
 create mode 100644 doc/bugs/git_proxy_uses_ls-files_without_--exclude-standard/comment_1_81383cf73102346fa8d537e1dde30353._comment
 create mode 100644 doc/bugs/git_rename_detection_on_file_move.mdwn
 create mode 100644 doc/bugs/git_rename_detection_on_file_move/comment_10_5ec2f965c80cc5dd31ee3c4edb695664._comment
 create mode 100644 doc/bugs/git_rename_detection_on_file_move/comment_1_0531dcfa833b0321a7009526efe3df33._comment
 create mode 100644 doc/bugs/git_rename_detection_on_file_move/comment_2_7101d07400ad5935f880dc00d89bf90e._comment
 create mode 100644 doc/bugs/git_rename_detection_on_file_move/comment_3_57010bcaca42089b451ad8659a1e018e._comment
 create mode 100644 doc/bugs/git_rename_detection_on_file_move/comment_4_79d96599f757757f34d7b784e6c0e81c._comment
 create mode 100644 doc/bugs/git_rename_detection_on_file_move/comment_5_d61f5693d947b9736b29fca1dbc7ad76._comment
 create mode 100644 doc/bugs/git_rename_detection_on_file_move/comment_6_f63de6fe2f7189c8c2908cc41c4bc963._comment
 create mode 100644 doc/bugs/git_rename_detection_on_file_move/comment_7_7f20d0b2f6ed1c34021a135438037306._comment
 create mode 100644 doc/bugs/git_rename_detection_on_file_move/comment_8_6a00500b24ba53248c78e1ffc8d1a591._comment
 create mode 100644 doc/bugs/git_rename_detection_on_file_move/comment_9_75e0973f6d573df615e01005ebcea87d._comment
 create mode 100644 doc/bugs/git_worktree_remove_fails.mdwn
 create mode 100644 doc/bugs/git_worktree_remove_fails/comment_1_e980c49fb53a785337e206feae34d032._comment
 create mode 100644 doc/bugs/git_worktree_remove_fails/comment_2_2c6ce2244c885bb21ca82a841987dd47._comment
 create mode 100644 doc/bugs/glacier_from_multiple_repos.mdwn
 create mode 100644 doc/bugs/gpg-agent.mdwn
 create mode 100644 doc/bugs/gpg-agent/comment_1_86860841aaa38541968693ec02f6a506._comment
 create mode 100644 doc/bugs/gpg-agent/comment_2_de6f9b8f20e44e93759b9bf0db695def._comment
 create mode 100644 doc/bugs/gpg_goes_to_100__37___cpu_on_bad_input_data.mdwn
 create mode 100644 doc/bugs/gpg_goes_to_100__37___cpu_on_bad_input_data/comment_1_889218fb7c0115b03d9bad0c07296097._comment
 create mode 100644 doc/bugs/high_cpu_usage_in_cat-file_and_webapp.mdwn
 create mode 100644 doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_1_7fee933eb54272a0447851279d31825b._comment
 create mode 100644 doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_2_f26b8846e1651c507d259b9891d26136._comment
 create mode 100644 doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_3_89dbc16c9c1b74ccb3f46d3c558e0c8d._comment
 create mode 100644 doc/bugs/how_to_copy_tp_multiple_remotes_simultaneously__63__.mdwn
 create mode 100644 doc/bugs/how_to_copy_tp_multiple_remotes_simultaneously__63__/comment_1_311a8a43d360074abd522fff14bfcb45._comment
 create mode 100644 doc/bugs/http_remotes_ignore_annex.web-options_--netrc.mdwn
 create mode 100644 doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_1_314bf6c825c8b4cd49de210f20f6cde2._comment
 create mode 100644 doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_2_599a66a1833000dc0e54a33511891b36._comment
 create mode 100644 doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_3_bed5008a429dd85dbb3389994f6d6295._comment
 create mode 100644 doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_4_a67253e52fa4510073d7df60d2bd4adb._comment
 create mode 100644 doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_5_d81762737f3854c75e804bad1697b517._comment
 create mode 100644 doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_6_e13932ead5920c7599031e85127317bb._comment
 create mode 100644 doc/bugs/identically_configured_remotes_behave_differently.mdwn
 create mode 100644 doc/bugs/identically_configured_remotes_behave_differently/comment_1_14fa5263ee9feedff8c36f86e4c33fd8._comment
 create mode 100644 doc/bugs/import_tree_on_adjusted_unlocked_branch_issues.mdwn
 create mode 100644 doc/bugs/import_tree_on_adjusted_unlocked_branch_issues/comment_1_a6aed4a1d1958e4734684b78b0f0a3de._comment
 create mode 100644 doc/bugs/import_tree_on_adjusted_unlocked_branch_issues/comment_2_7fc16d6ff0f1a61907bc34e8f8b71add._comment
 create mode 100644 doc/bugs/import_tree_on_adjusted_unlocked_branch_issues/comment_3_c75eee397fc6a53aa0ff55f993b790a7._comment
 create mode 100644 doc/bugs/importtree_replaces_files_with_identical_size.mdwn
 create mode 100644 doc/bugs/importtree_replaces_files_with_identical_size/comment_1_2742c2cbde12aa85b8254dd6907fcfc1._comment
 create mode 100644 doc/bugs/importtree_replaces_files_with_identical_size/comment_2_46336dc995a7cefb8ebbfe98f098e258._comment
 create mode 100644 doc/bugs/importtree_replaces_files_with_identical_size/comment_3_2b9bdb906043aa84ea6cf0d74a685769._comment
 create mode 100644 doc/bugs/importtree_replaces_files_with_identical_size/comment_4_9363ed782b5dc8d70a323fbc2574e7c7._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb.mdwn
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_10_a2724ab85bc91fba3bb6e55d2b1e3878._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_11_a3fc6b67529ddce9e79c0e72996259ad._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_12_c1865c88d23873eb4b32489fc387f40c._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_13_6043be5152ba2d44fb9aac4063060b56._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_14_e961d2b508e3260670bb61a5ae51d109._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_15_35d233db5f7410048bd0cf9f5b4fd5cc._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_16_d0a7af6aecf8cb070c34edec1b3e2ecb._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_17_8fe8c0747a69ea977942a399ac929e77._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_18_b5ea8e5a761b254672171c3ab41e09f9._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_19_238c26c1a3f4ab7dd6ea3b2f26febaef._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_1_41ca70e65a59d620cedc7cf46a8305fc._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_20_d6d3db42bda1fe094140d54a458157b1._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_21_9320fcfb8bd47d4ee547e81fb9e01f38._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_22_333907125ccf24c2ad8286cd40a35b16._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_2_8f609e231fdf315d2b658d30d708d471._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_3_d54f2c81763b4119c881e283cff80d44._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_4_76fe32e5ecbf37b0f173de987c59e39f._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_5_512996afefabc75a0b2258fc05ccbfdd._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_6_1b6ff858daf39dd84d4ef39a162ca914._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_6_b8b3eb5fff4ad3478dfbbd2120d4b00a._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_8_1389db945973ed42b8ddd0de3cc8889c._comment
 create mode 100644 doc/bugs/importtree_spends_hours_reading_cidsdb/comment_8_58155dba65976fd92cd212e13f87b888._comment
 create mode 100644 doc/bugs/in_case_of___34__incomplete__34_____40__no_rmets__41___export_to_versioned_S3__44___fails_on_initial___96__get_-J__96___call__44___but_then___34__succeeds__34___on_subsequent.mdwn
 create mode 100644 doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs.mdwn
 create mode 100644 doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_1_be44453dee893cc99759f90e660c0a66._comment
 create mode 100644 doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_2_e262ec0e438557b8d70a6adc50545ac1._comment
 create mode 100644 doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_c863d6940528fcc543815da44e7997d5._comment
 create mode 100644 doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_4_d54eb28d30d91088de019b761a340fd3._comment
 create mode 100644 doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_5_6439cb8500ad225fc4ef43a18582b18a._comment
 create mode 100644 doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_6_a959fa6cb5b4cda423b7e75aeec2eb1c._comment
 create mode 100644 doc/bugs/info_regression__58___exits_on_first_bad_path.mdwn
 create mode 100644 doc/bugs/info_regression__58___exits_on_first_bad_path/comment_1_360a45c65c76e71c967afee1e3d355a1._comment
 create mode 100644 doc/bugs/info_tries_to_scan_ignored_dirs_without_permission.mdwn
 create mode 100644 doc/bugs/info_tries_to_scan_ignored_dirs_without_permission/comment_1_621066a2d1e8ff9f5edc41001dc4072f._comment
 create mode 100644 doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10.mdwn
 create mode 100644 doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_1_5b9ba56f682a991a57872d021f2ff08e._comment
 create mode 100644 doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_2_419bf4e6ebce4bcaae3afc6420da80b8._comment
 create mode 100644 doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_3_425e81639f39d723b390d114a6d9e24b._comment
 create mode 100644 doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_4_a24860bb39cf920e34fac9ee6154b69e._comment
 create mode 100644 doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_5_3293f29b78d10aaf9254ddba1af6731d._comment
 create mode 100644 doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_6_f09aa0ebe68b5db72d466ae802ce20d5._comment
 create mode 100644 doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_7_2d354e2c1fc2f1f6397fd89f71bf29ca._comment
 create mode 100644 doc/bugs/init_fails_in_a_folder_with_newline_in_its_name.mdwn
 create mode 100644 doc/bugs/init_fails_in_a_folder_with_newline_in_its_name/comment_1_2690ed9441685068c291a182d39c2616._comment
 create mode 100644 doc/bugs/introduction_of_aws-0.23_causes_stack_bld_to_fail.mdwn
 create mode 100644 doc/bugs/keeps_demanding_ssh_key_even_if_all_sync__39__s_turned_down.mdwn
 create mode 100644 doc/bugs/keeps_demanding_ssh_key_even_if_all_sync__39__s_turned_down/comment_1_e4b110f61502b5d37117ec65ec39896b._comment
 create mode 100644 doc/bugs/leaves_many_stray_processes_on_remote_server.mdwn
 create mode 100644 doc/bugs/leaves_many_stray_processes_on_remote_server/comment_1_b66015587ccd3ca81de52271979bd026._comment
 create mode 100644 doc/bugs/leaves_many_stray_processes_on_remote_server/comment_2_4f417206d5d83bd456c8e501ae272cba._comment
 create mode 100644 doc/bugs/list__58___escaped_characters_not_accepted_as_input.mdwn
 create mode 100644 doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_1_823458893eb87f1331da050d68486209._comment
 create mode 100644 doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_2_bc1f89afe38c5136beb74160ff26e519._comment
 create mode 100644 doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_3_3aafdcc1b32439ec577fb090b94c6ac1._comment
 create mode 100644 doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_4_73c1495abff5284c42a8cf0537b19df4._comment
 create mode 100644 doc/bugs/loadlocale_error_with_standalone_build.mdwn
 create mode 100644 doc/bugs/loadlocale_error_with_standalone_build/comment_1_96a809060ed05100b6f8e5198ec699be._comment
 create mode 100644 doc/bugs/loadlocale_error_with_standalone_build/comment_2_e1c443ba943a5883ca63fbf05d3e5b41._comment
 create mode 100644 doc/bugs/loadlocale_error_with_standalone_build/comment_3_acb934b9e7d91aa59f49926e658c4bbe._comment
 create mode 100644 doc/bugs/loadlocale_error_with_standalone_build/comment_4_39366d601e4200a953fe375c7c96f106._comment
 create mode 100644 doc/bugs/loadlocale_error_with_standalone_build/comment_5_ce08bf5b13ae0db7fa06196f56a26e8a._comment
 create mode 100644 doc/bugs/loadlocale_error_with_standalone_build/comment_6_a852f4b40506edf9948c7953b01aa340._comment
 create mode 100644 doc/bugs/loadlocale_error_with_standalone_build/comment_6_b387cdacf97c476284640195e9fd03c9._comment
 create mode 100644 doc/bugs/loadlocale_error_with_standalone_build/comment_8_7820a310f6bf5f6f4c6c58fbfea8c85f._comment
 create mode 100644 doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped.mdwn
 create mode 100644 doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_1_0e3e0966f06ded18ecfd41f8084b4658._comment
 create mode 100644 doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_2_2836fe9dfa7b5140df1ce893044c254b._comment
 create mode 100644 doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_3_1f4bc975621d24e6e43d887693ada800._comment
 create mode 100644 doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_4_2cded724d1a4368dca475b89010c23e2._comment
 create mode 100644 doc/bugs/make___39__find__39___clear__40__er__41___on_what_is_unlocked_.mdwn
 create mode 100644 doc/bugs/make___39__find__39___clear__40__er__41___on_what_is_unlocked_/comment_1_b855c810464bb22bd76681d669313ae5._comment
 create mode 100644 doc/bugs/make___39__find__39___clear__40__er__41___on_what_is_unlocked_/comment_2_71b7b4417aa63e469636a03e460c2427._comment
 create mode 100644 doc/bugs/make_install_doesn__39__t_create_git-annex-shell.mdwn
 create mode 100644 doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_1_8c20edd8c6483500f807528d616c6dfd._comment
 create mode 100644 doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_2_8b2cf0fe7219e0bc83fd326adbf26c8a._comment
 create mode 100644 doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_3_25fe06eb127e59a4a07aeb52a5cfeabe._comment
 create mode 100644 doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_4_ec78032ba62d6918baa2c0b07ead5b50._comment
 create mode 100644 doc/bugs/matching_option_--onlyingroup_works_only_partially.mdwn
 create mode 100644 doc/bugs/matching_option_--onlyingroup_works_only_partially/comment_1_001927fce7b1c194076f76a092af414e._comment
 create mode 100644 doc/bugs/merge_causes_out_of_memory_on_large_repos.mdwn
 create mode 100644 doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_1_6d47485728ea65a9b555f8be7159dea5._comment
 create mode 100644 doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_2_06723d13ecdaf87de5ff2b209e3c5198._comment
 create mode 100644 doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_3_9f83ef190547b291a715cda55b7977d4._comment
 create mode 100644 doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_4_0e32ae0300472c56079cfbcd78a3e386._comment
 create mode 100644 doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_5_e8998716107e7ae8d0e8d332812517ad._comment
 create mode 100644 doc/bugs/metadata_view_does_not_vpop_to_original_view.mdwn
 create mode 100644 doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_1_91c69150533cb6c2147dcf2eb480ef39._comment
 create mode 100644 doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_2_ca1cc0b0e5c53daffd0b5ca78a6ac43f._comment
 create mode 100644 doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_3_63bef9006a1e4ba2ebbfafbdf605a9e1._comment
 create mode 100644 doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_4_4873f0bc670b193cec3be327ee178a13._comment
 create mode 100644 doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_5_bf63c9d3e0de468ffa5856dcf7c313b7._comment
 create mode 100644 doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_6_83e389f5fdd58ffd62ead898ddbb5279._comment
 create mode 100644 doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_7_a5511e21ee6c09d8edf2bca48482d848._comment
 create mode 100644 doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_8_ef3e8e1c47984fc674e58646052205ef._comment
 create mode 100644 doc/bugs/migrate_and_move_duplicates_data.mdwn
 create mode 100644 doc/bugs/migrate_and_move_duplicates_data/comment_1_ac3c5c141992c7b5d2cc36e085b0cba8._comment
 create mode 100644 doc/bugs/migrate_and_move_duplicates_data/comment_2_68a876f2eed5c446d92367aae4070408._comment
 create mode 100644 doc/bugs/migrate_removes_associated_URLs_with_custom_scheme.mdwn
 create mode 100644 doc/bugs/migrate_removes_associated_URLs_with_custom_scheme/comment_1_6e9a2b3ff2be4e2b3ff5b67ac913efb8._comment
 create mode 100644 doc/bugs/migrated_files_not_showing_up_in_unused_list.mdwn
 create mode 100644 doc/bugs/migrated_files_not_showing_up_in_unused_list/comment_1_2cfbf6693b051c758fe5efa5ee885829._comment
 create mode 100644 doc/bugs/migrated_files_not_showing_up_in_unused_list/comment_2_acb1abeb32c3aba8ba65151afbea753c._comment
 create mode 100644 doc/bugs/mimeencoding_detection_is_not_working.mdwn
 create mode 100644 doc/bugs/mimeencoding_detection_is_not_working/comment_1_dbcdb6ae6fb1d06f4d5cf27cba4c69be._comment
 create mode 100644 doc/bugs/mimeencoding_detection_is_not_working/comment_2_b9df7eb812a4a2fba4b1273fbffe8375._comment
 create mode 100644 doc/bugs/mimeencoding_detection_is_not_working/comment_3_b02a321a1fd8aaeca1680cec96055172._comment
 create mode 100644 doc/bugs/moreinfo.mdwn
 create mode 100644 doc/bugs/move_from_ssh_when_not_present_displays_misleading.mdwn
 create mode 100644 doc/bugs/move_that_fails_at_drop_stage_does_not_resume_correctly.mdwn
 create mode 100644 doc/bugs/need_more_debug_for_failing_to_get_uuid_or_key_.mdwn
 create mode 100644 doc/bugs/need_more_debug_for_failing_to_get_uuid_or_key_/comment_1_6c3efd1922015a20daf93bea54fc6431._comment
 create mode 100644 doc/bugs/new_repo_with_git-lfs_as_only_annex_remote.mdwn
 create mode 100644 doc/bugs/new_repo_with_git-lfs_as_only_annex_remote/comment_1_804ecf5218ce147767352fea8ea5eae8._comment
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows.mdwn
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows/comment_10_72b2277c3728f02e4d158ebbd7db41b2._comment
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows/comment_11_b212c8b8cf361745f35a9f7ff6fee1f5._comment
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows/comment_12_9d445ddf84e15a59cdc2aa2b8dc30c44._comment
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows/comment_1_988768c3e4f30c751034a0b0390cdd88._comment
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows/comment_2_70a6c9af57eed4f8ceb3de63cbf8a5e6._comment
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows/comment_3_7f48959c6242c5cc52e9d0a79fd3f85d._comment
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows/comment_4_04b30dd9e510762ee547e7b45bdba660._comment
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows/comment_5_beebbd4a41cccfc7aac3c19d76c3b978._comment
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows/comment_6_957c5da5f336c7ef59e4149602471888._comment
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows/comment_7_a8654cf656de55ccdcf40270a1ef4ca9._comment
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows/comment_8_3c8bb1b1d67ca1a6e568e381d24a2574._comment
 create mode 100644 doc/bugs/no_git-annex_shell_on_Windows/comment_9_03646c9df9d4f4ea27459660fe65a976._comment
 create mode 100644 doc/bugs/no_way_to_disable_repository_auto_upgrade.mdwn
 create mode 100644 doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_1_aab2cb260b68c25facd652946ea2aff7._comment
 create mode 100644 doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_2_dc24c6c0c60bb11d6d871fa62585276d._comment
 create mode 100644 doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_3_f3c10f35956dff886d961f1351af71ef._comment
 create mode 100644 doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_4_7ea295a6c113ea0cc3e4e5ae28769190._comment
 create mode 100644 doc/bugs/non-git-annex_symlinks_not_perserved_when_exporting_tree_via_rsync.mdwn
 create mode 100644 doc/bugs/non-git-annex_symlinks_not_perserved_when_exporting_tree_via_rsync/comment_1_b92c67f7d2f0424ce399ca4659e6c805._comment
 create mode 100644 doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status.mdwn
 create mode 100644 doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_1_fcd230cbb2ac363c469b98021042c011._comment
 create mode 100644 doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_2_23207ecabd4b41d9551d0491fa71e96b._comment
 create mode 100644 doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_3_6ea92adfe955b6a5cd2a39fea78b3bf6._comment
 create mode 100644 doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_4_d0e55585f1612148163039d157253258._comment
 create mode 100644 doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_6_5506dc1b08516677886da4aa97263864._comment
 create mode 100644 doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_7_073449cc2cb73efd2b2d3d778a5573de._comment
 create mode 100644 doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_7_3516e71ba3b07427a10cbb4965712aa6._comment
 create mode 100644 doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_8_ea2e4704adb2f304f9c11c61eb62e919._comment
 create mode 100644 doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_9_4d17fedead7977541371a3f2c192e030._comment
 create mode 100644 doc/bugs/oldkeys_not_in_Windows_release_10.20230803.mdwn
 create mode 100644 doc/bugs/oldkeys_not_in_Windows_release_10.20230803/comment_1_9969cdc389617f4df2ee286e8d28176e._comment
 create mode 100644 doc/bugs/oldkeys_not_in_Windows_release_10.20230803/comment_2_b265af06b8edda75d305fd836f6c5242._comment
 create mode 100644 doc/bugs/on_encfs__44___.fuse__95__hiddenXXXXX_files_left_behind.mdwn
 create mode 100644 doc/bugs/on_encfs__44___.fuse__95__hiddenXXXXX_files_left_behind/comment_1_b96ea3ece44d42e79e4d903ca66065ee._comment
 create mode 100644 doc/bugs/openTempFile.mdwn
 create mode 100644 doc/bugs/openTempFile/comment_1_48b9ab6e3d4b24ec34d2a99b5a4ff619._comment
 create mode 100644 doc/bugs/openTempFile/comment_2_a09c4a7d346c3b0f7025e6f3a276adb8._comment
 create mode 100644 doc/bugs/openTempFile/comment_3_9b9f35c8ed31ca62b34d216c6906304c._comment
 create mode 100644 doc/bugs/openTempFile/comment_4_3397f9ddb94d4acb8af778ec15487022._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more.mdwn
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_10_7aed761c4843217ea4c90491897224c1._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_11_847e04bbe9c59700249136b7fef4d0b7._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_12_603d7228668a36dc848e706cdff64035._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_13_a79fcbe80060d11582989a9fc31d4a92._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_14_8c3b13806adb731435b346a64990527b._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_15_145e29b42c46f15efc21c6d1ef9dd82d._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_16_783ada9438a00c0a23357bea2f19d0a1._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_17_d13e85f691165b533d6630a93111c786._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_18_13ce5ec87207d553388ec23663d9abcb._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_1_3f32fa3c6de412bfdab8a4e67a30012c._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_1_5e0a9e36870cd21bed351ca37ffe9914._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_3_d92bd84ab3f218eb6ad38fcc7f54c223._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_4_a3a5c3182ecb9fdef82f4959af516d9a._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_5_652424afbe5484a679c55d437cf1e7a1._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_6_3961ac7f22f42886f0e30f62f1cb0c5d._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_7_0894259447bde6d676c629d5bce2a6ba._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_8_7ce86149c0d839f6d2b14f76bab288be._comment
 create mode 100644 doc/bugs/performance_regression__63___init_takes_times_more/comment_9_d4ba8c726e8b74d4692caf0d4afd214c._comment
 create mode 100644 doc/bugs/poor_choice_of_name_for_adjusted_branches.mdwn
 create mode 100644 doc/bugs/poor_choice_of_name_for_adjusted_branches/comment_1_adbbc90054eafefa7de58663868986a3._comment
 create mode 100644 doc/bugs/poor_choice_of_name_for_adjusted_branches/comment_2_dc7b2ae4971324d34f6a8d89e888f598._comment
 create mode 100644 doc/bugs/poor_choice_of_name_for_adjusted_branches/comment_3_19ce066c0b912398300caf8520f70eb3._comment
 create mode 100644 doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames.mdwn
 create mode 100644 doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_1_ca10638d4b4b178cfd0de8736542c4dc._comment
 create mode 100644 doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_2_986a393a512229d35e529ba242b77b1e._comment
 create mode 100644 doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_3_a66be1cc2c4ca7e470be1248dcbbe885._comment
 create mode 100644 doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_4_7a8f1ba849f6e6f6072c39bdbff49405._comment
 create mode 100644 doc/bugs/present_files__47__directories_are_dropped_after_a_sync.mdwn
 create mode 100644 doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_1_9d7591faf99ce48b1e5753c80306ae8b._comment
 create mode 100644 doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_2_7316cba69b9dc0415fea1389238edf25._comment
 create mode 100644 doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_3_0d53226a3991e3685d1311e4b19c4023._comment
 create mode 100644 doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_4_68bd50c6aeffc06d53eda7f38b06edee._comment
 create mode 100644 doc/bugs/problem_commit_normal_links.mdwn
 create mode 100644 doc/bugs/problem_with_upgrade_v2_-__62___v3.mdwn
 create mode 100644 doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_1_5f60006c9bb095167d817f234a14d20b._comment
 create mode 100644 doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_2_cd0123392b16d89db41b45464165c247._comment
 create mode 100644 doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_3_86d9e7244ae492bcbe62720b8c4fc4a9._comment
 create mode 100644 doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_4_91439d4dbbf1461e281b276eb0003691._comment
 create mode 100644 doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_5_ca33a9ca0df33f7c1b58353d7ffb943d._comment
 create mode 100644 doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_6_f360f0006bc9115bc5a3e2eb9fe58abd._comment
 create mode 100644 doc/bugs/proposal_for_timestamp_semantics.mdwn
 create mode 100644 doc/bugs/proposal_for_timestamp_semantics/comment_1_a54fc1bda24e04b15490d0eaa1838d28._comment
 create mode 100644 doc/bugs/proposal_for_timestamp_semantics/comment_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment
 create mode 100644 doc/bugs/pull_doesn__39__t_work_on_adjusted_branches.mdwn
 create mode 100644 doc/bugs/pull_doesn__39__t_work_on_adjusted_branches/comment_1_2c5f51483b2f2521d98f943d8ded3acd._comment
 create mode 100644 doc/bugs/pull_doesn__39__t_work_on_adjusted_branches/comment_2_632a3616516605de477930ae09d4ca60._comment
 create mode 100644 doc/bugs/ran_once_then_stopped_running_opensuse_13.1.mdwn
 create mode 100644 doc/bugs/ran_once_then_stopped_running_opensuse_13.1/comment_1_a9daf9e8f968b32f25e236f53ea4b845._comment
 create mode 100644 doc/bugs/random_files_vanishing_when_assistant_gets_restarted.mdwn
 create mode 100644 doc/bugs/random_files_vanishing_when_assistant_gets_restarted/comment_1_53b4f388c47c1b3f6ffa4fc2155b30fc._comment
 create mode 100644 doc/bugs/random_files_vanishing_when_assistant_gets_restarted/comment_2_e66532b23b089c9ea61122d6664cddb9._comment
 create mode 100644 doc/bugs/random_files_vanishing_when_assistant_gets_restarted/comment_3_c9d692c867acc076f64f1213ea03ca11._comment
 create mode 100644 doc/bugs/redundant_transfer_not_prevented.mdwn
 create mode 100644 doc/bugs/registerurl_does_not_register_if_external_remote.mdwn
 create mode 100644 doc/bugs/registerurl_does_not_register_if_external_remote/comment_1_124bbd63a2a85004ff9cf965ad984fb4._comment
 create mode 100644 doc/bugs/registerurl_does_not_register_if_external_remote/comment_2_0f4d7c7f208b965ece8f017a38d7d0f1._comment
 create mode 100644 doc/bugs/registerurl_does_not_register_if_external_remote/comment_3_31330afe2ea5e543219edb9e8071239b._comment
 create mode 100644 doc/bugs/registerurl_does_not_register_if_external_remote/comment_4_4f2c98add8a4f7b9f49e54e12fd79f10._comment
 create mode 100644 doc/bugs/registerurl_does_not_register_if_external_remote/comment_5_b9057ce47bb57b3a3dbe390672310898._comment
 create mode 100644 doc/bugs/registerurl_does_not_register_if_external_remote/comment_6_7a96a8a05e4a45477ec8b4eaea9374b1._comment
 create mode 100644 doc/bugs/registerurl_does_not_register_if_external_remote/comment_7_649f04c1909ab803eabe2eea7f37c6fd._comment
 create mode 100644 doc/bugs/registerurl_does_not_register_if_external_remote/comment_8_542bd923122ba24fe9cb14d36b97f15d._comment
 create mode 100644 doc/bugs/regression_with_S3_creds_not_used.mdwn
 create mode 100644 doc/bugs/regression_with_S3_creds_not_used/comment_1_df5416ee63c8f026f3b3c77c74b67ce4._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist.mdwn
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_10_8a1d16b2aaba224e94be3d9dcc036d91._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_11_434ed328a22a6657dba3b2929a56e499._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_12_1837b70ace42882db3ab82e001680934._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_13_ca9c87a10f29e41572540edeb99652f2._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_1_69eafc4201e3014ef1b5d74fe319e462._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_2_b7a64db9abe006af8c30169ad849efe9._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_3_197ac6070f256131c6e18a07aa3834fa._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_4_fe07832333b536c71b7dcb46a4a44bd0._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_5_540bca4e6fdfc10eeab875ecc0f2b3f3._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_6_3f236b35e9820cd88bb77fcd57d6975e._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_7_3cc5dae0351201522711a7caeecd60d5._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_8_3c3883cb66d02a15d5de84d22aa113da._comment
 create mode 100644 doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_9_c8cece9559bd2dc6154cd28772369e48._comment
 create mode 100644 doc/bugs/remote_not_showing_up_in_webapp.mdwn
 create mode 100644 doc/bugs/remote_not_showing_up_in_webapp/comment_1_2a269732fd528f505777542d3556437a._comment
 create mode 100644 doc/bugs/remote_not_showing_up_in_webapp/comment_2_10638e99e2e11460f99266f56adbc1db._comment
 create mode 100644 doc/bugs/remote_not_showing_up_in_webapp/comment_3_4aa72acc0938f7f824ba10f3f102e8bc._comment
 create mode 100644 doc/bugs/remotes_disappeared.mdwn
 create mode 100644 doc/bugs/remotes_disappeared/comment_1_7b7bfa0b2c9e66edd92c076e5c6ccdd7._comment
 create mode 100644 doc/bugs/remotes_disappeared/comment_2_b9dae978aeeee5e5d246192fed813b3f._comment
 create mode 100644 doc/bugs/remotes_disappeared/comment_3_794372fb37621f37478313abc4ee92cf._comment
 create mode 100644 doc/bugs/repair_on_Windows_reports_ambiguous_argument_error.mdwn
 create mode 100644 doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist.mdwn
 create mode 100644 doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_1_66ff5ff20c4a1561943f8fc144a4dfb5._comment
 create mode 100644 doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_2_28e204f5db91eaa258428d89cbb9f6c9._comment
 create mode 100644 doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_3_68ddf1256149eec1ac01fb915d26bac3._comment
 create mode 100644 doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_4_785200bbdc9efabed141ecd51cb015a4._comment
 create mode 100644 doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_5_3b5f7c44de6b17e042adaa77a8bed2f8._comment
 create mode 100644 doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_6_baa4f1e895ff351b16f54d59851d2a6f._comment
 create mode 100644 doc/bugs/rsync__58___protocol_version_mismatch.mdwn
 create mode 100644 doc/bugs/rsync__58___protocol_version_mismatch/comment_1_672d89a7d06d5ec336381b670a41a9c7._comment
 create mode 100644 doc/bugs/rsync__58___protocol_version_mismatch/comment_2_531b85c911d390b1b93ee55a8cf5d47e._comment
 create mode 100644 doc/bugs/rsync__58___protocol_version_mismatch/comment_3_eff8f33134157635387ee681805ff7a8._comment
 create mode 100644 doc/bugs/rsync__58___protocol_version_mismatch/comment_4_77e59a25c859b6afec8b75f74885ef5e._comment
 create mode 100644 doc/bugs/rsync__58___protocol_version_mismatch/comment_5_7d819c3e4af2b8044a52fa6131f36187._comment
 create mode 100644 doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_.mdwn
 create mode 100644 doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_/comment_1_464d733de18f6ca438ebd84e88b8cee2._comment
 create mode 100644 doc/bugs/s3_InternalIOException__63__.mdwn
 create mode 100644 doc/bugs/s3_InternalIOException__63__/comment_1_42bd2d1e364203f1b34efcc34ac795b8._comment
 create mode 100644 doc/bugs/s3_InternalIOException__63__/comment_2_994dd3ebcf7eaacb0b9e06f1bc14a2d4._comment
 create mode 100644 doc/bugs/s3_InternalIOException__63__/comment_3_a69927ec705efa31aacb5941bf8d8f9d._comment
 create mode 100644 doc/bugs/s3_InternalIOException__63__/comment_4_ee791ad24d5d2c0ad4f82ecf6fc434a9._comment
 create mode 100644 doc/bugs/s3_InternalIOException__63__/comment_5_134d1d0ad9f59a2b7498d1ed335cf91a._comment
 create mode 100644 doc/bugs/s3_remote__58___public__61__yes_sets_disabled_ACLs.mdwn
 create mode 100644 doc/bugs/s3_remote__58___public__61__yes_sets_disabled_ACLs/comment_1_0bf1f463133476727129ddf15f24983b._comment
 create mode 100644 doc/bugs/safe.bareRepository_breaks_git-annex_uuid.mdwn
 create mode 100644 doc/bugs/safe.bareRepository_breaks_git-annex_uuid/comment_1_0a5faade2dfbb0dfe5d94d37450ba06c._comment
 create mode 100644 doc/bugs/schedule.log_added_to_annex__63_____58____47____47____47__.mdwn
 create mode 100644 doc/bugs/securehashesonly_conflicts_with_addurl.mdwn
 create mode 100644 doc/bugs/securehashesonly_conflicts_with_addurl/comment_1_808e276381f98b4ebb7d61628db703d9._comment
 create mode 100644 doc/bugs/shared_encryption_bypassed_if_gpg_error_on_init.mdwn
 create mode 100644 doc/bugs/should_be_possible_to_use_ssh_hosts_from_.ssh__47__config.mdwn
 create mode 100644 doc/bugs/should_be_possible_to_use_ssh_hosts_from_.ssh__47__config/comment_1_3dac095b7cf799e31925868d13888970._comment
 create mode 100644 doc/bugs/should_be_possible_to_use_ssh_hosts_from_.ssh__47__config/comment_2_342b4913a063184650cdf4f541f7ea02._comment
 create mode 100644 doc/bugs/should_create_leading_dirs_for_annex.dbdir.mdwn
 create mode 100644 doc/bugs/should_create_leading_dirs_for_annex.dbdir/comment_1_20cbcee65bccc3213e437ef347b52612._comment
 create mode 100644 doc/bugs/should_error_on_whereis_--batch-keys_--all.mdwn
 create mode 100644 doc/bugs/should_error_on_whereis_--batch-keys_--all/comment_1_724ae0427fb306352ff9b26d9fdef27a._comment
 create mode 100644 doc/bugs/silently_failing_when_attempting_to_add_ignored_files.mdwn
 create mode 100644 doc/bugs/silently_failing_when_attempting_to_add_ignored_files/comment_1_f1208fda822d17a3a9e5457324fdd1df._comment
 create mode 100644 doc/bugs/silently_failing_when_attempting_to_add_ignored_files/comment_2_9fe7fd6296db34ee8ee07fe68459e74b._comment
 create mode 100644 doc/bugs/some_conflict_resolution_tests_fail_some_time.mdwn
 create mode 100644 doc/bugs/some_conflict_resolution_tests_fail_some_time/comment_1_bd9963c2a40b55bf745ce3d801a5da19._comment
 create mode 100644 doc/bugs/some_conflict_resolution_tests_fail_some_time/comment_2_f7b38a6da0ce74c1d4224a37aad9246a._comment
 create mode 100644 doc/bugs/special_remote_adb_-_Argument_list_too_long.mdwn
 create mode 100644 doc/bugs/special_remote_adb_-_Argument_list_too_long/comment_1_34f202f91a16dd4d2bb557aee6fd5a3e._comment
 create mode 100644 doc/bugs/special_remote_protocol__58___adding_local_state_variables___40__not_under_git__41__.mdwn
 create mode 100644 doc/bugs/special_remote_protocol__58___adding_local_state_variables___40__not_under_git__41__/comment_1_3d162dce2af8d84c5582cf63624e9310._comment
 create mode 100644 doc/bugs/started_to_escape_characters_in_the_output.mdwn
 create mode 100644 doc/bugs/started_to_escape_characters_in_the_output/comment_1_1d0f25da3af46d211445d10f0d6c143e._comment
 create mode 100644 doc/bugs/started_to_escape_characters_in_the_output/comment_2_76c80e98cc2d26e4cebaac6e40e76df9._comment
 create mode 100644 doc/bugs/started_to_escape_characters_in_the_output/comment_3_0fe421cd62c36804a78e4b424302e3d7._comment
 create mode 100644 doc/bugs/started_to_escape_characters_in_the_output/comment_4_d3c423c3faecc115bb5bab3471226ee5._comment
 create mode 100644 doc/bugs/started_to_escape_characters_in_the_output/comment_6_783b2bdf1826f472d8f39d01e81adf20._comment
 create mode 100644 doc/bugs/started_to_escape_characters_in_the_output/comment_6_b8da1f30c5bc88f4ddb7878d790823cd._comment
 create mode 100644 doc/bugs/started_to_escape_characters_in_the_output/comment_7_c855cc0728c71e9a4696a192cd331213._comment
 create mode 100644 doc/bugs/started_to_escape_characters_in_the_output/comment_8_ee066c129d808ac511c0efce9a644ab9._comment
 create mode 100644 doc/bugs/started_to_escape_characters_in_the_output/comment_9_41bac25db7cc8978659c2e202960a2a4._comment
 create mode 100644 doc/bugs/startup_scan_extremely_slow.mdwn
 create mode 100644 doc/bugs/startup_scan_extremely_slow/comment_1_68f88f04c179800c0ce1ff6925d4c6ab._comment
 create mode 100644 doc/bugs/startup_scan_extremely_slow/comment_2_116e850299372027481c9d0a1667d5af._comment
 create mode 100644 doc/bugs/startup_scan_extremely_slow/comment_3_3eb4c2290e560451e7341b85b58212b0._comment
 create mode 100644 doc/bugs/startup_scan_extremely_slow/comment_4_ade878000a050c87a345e8bc9914deba._comment
 create mode 100644 doc/bugs/startup_scan_extremely_slow/comment_5_4ee924e70d5a8e35e706eaaff4cc76e1._comment
 create mode 100644 doc/bugs/still_seeing_errors_with_parallel_git-annex-add.mdwn
 create mode 100644 doc/bugs/still_seeing_errors_with_parallel_git-annex-add/comment_1_b38f13a4c28ad8ce26aef72e7d6fcb11._comment
 create mode 100644 doc/bugs/still_seeing_errors_with_parallel_git-annex-add/comment_2_96312bab546412b1eecfa74aec1d7fee._comment
 create mode 100644 doc/bugs/still_seeing_errors_with_parallel_git-annex-add/comment_3_e76ddebaf9d248c02d16a6914973d7d0._comment
 create mode 100644 doc/bugs/support_bare_git_repo__44___with_the_annex_directory_exposed_to_http.mdwn
 create mode 100644 doc/bugs/surprising_import_tree_merge_result.mdwn
 create mode 100644 doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant.mdwn
 create mode 100644 doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant/comment_1_b832288844a3e7e944fa08a6edb97d29._comment
 create mode 100644 doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant/comment_2_fbfc8929497f609916d9f3e5a0a9b531._comment
 create mode 100644 doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files.mdwn
 create mode 100644 doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_1_500bc8f48ae80841e0db21ee0de76c50._comment
 create mode 100644 doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_1_9581f8135c6eb2ed2135f83a266e5306._comment
 create mode 100644 doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_3_dbc8ad383c4968b1ab78ac86bab06329._comment
 create mode 100644 doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_4_23a16e94a0f18126caa6cb2f94131277._comment
 create mode 100644 doc/bugs/sync_-C_can_export_other_files.mdwn
 create mode 100644 doc/bugs/sync_-C_can_export_other_files/comment_1_7a6ab3ee25f0d09df4d7478d26ea2d37._comment
 create mode 100644 doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking.mdwn
 create mode 100644 doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_1_562cf3ab3398c1ef874c0bfe5d89e47b._comment
 create mode 100644 doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_2_f686273c6be899d2a8bbaabd03a47fbf._comment
 create mode 100644 doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_3_fd518d0601587dc5c718944d0b6f51fc._comment
 create mode 100644 doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_4_a6074b68754b0d773385a1e406043952._comment
 create mode 100644 doc/bugs/sync_does_not_merge_after_branch_rollback.mdwn
 create mode 100644 doc/bugs/sync_does_not_merge_after_branch_rollback/comment_1_8c5f4787a6156802d00cfad1f7d2ee31._comment
 create mode 100644 doc/bugs/sync_does_not_propagate_forgetfulness.mdwn
 create mode 100644 doc/bugs/sync_does_not_propagate_forgetfulness/comment_1_acc9744be183c297c6410f9b0a30b46b._comment
 create mode 100644 doc/bugs/sync_does_not_sync_content_with_new_remote_on_first_run.mdwn
 create mode 100644 doc/bugs/sync_does_not_sync_content_with_new_remote_on_first_run/comment_1_c1df7f51ac724400dbef664ce10784a8._comment
 create mode 100644 doc/bugs/sync_with_export_remote_deletes_files_from_it_when_ran_in_other_than_tracking_branch.mdwn
 create mode 100644 doc/bugs/tahoe_remote_has_no_repair.mdwn
 create mode 100644 doc/bugs/tasty_test_limiting_broken_by_concurrency.mdwn
 create mode 100644 doc/bugs/tasty_test_limiting_broken_by_concurrency/comment_1_e043a71b60999cf97bd872d8b32fcac9._comment
 create mode 100644 doc/bugs/test__58___posix__95__spawnp_broken_10_on_darwin.mdwn
 create mode 100644 doc/bugs/test__58___posix__95__spawnp_broken_10_on_darwin/comment_1_5741fabaa561b81989cc176e9acb4a99._comment
 create mode 100644 doc/bugs/test__58___posix__95__spawnp_broken_10_on_darwin/comment_2_3fb2b47ade727a1bc6a99120b68d98b7._comment
 create mode 100644 doc/bugs/test_prop__95__relPathDirToFileAbs__95__basics_fails_again.mdwn
 create mode 100644 doc/bugs/testremote_failure_with_s3.mdwn
 create mode 100644 doc/bugs/testremote_is_not_honoring_--backend.mdwn
 create mode 100644 doc/bugs/testremote_is_not_honoring_--backend/comment_1_2b119f8bce39266630dd7c0f4d8add98._comment
 create mode 100644 doc/bugs/testremote_is_not_honoring_--backend/comment_2_f804c33243606cab4495238511e59743._comment
 create mode 100644 doc/bugs/testremote_is_not_honoring_--backend/comment_3_1261222f79d9dbc8cf92f6466361e113._comment
 create mode 100644 doc/bugs/testremote_is_not_honoring_--backend/comment_4_b6b4e0b7446f445591ac617e28e249e3._comment
 create mode 100644 doc/bugs/testremote_is_not_honoring_--backend/comment_5_96a03ff1d7339643e8f74e6e536e8f83._comment
 create mode 100644 doc/bugs/testremote_is_not_honoring_--backend/comment_6_7a9cb82671ff8a459886a84e66cb2417._comment
 create mode 100644 doc/bugs/testremote_is_not_honoring_--backend/comment_7_ed8668ea11a905b90892eb684f93a4ed._comment
 create mode 100644 doc/bugs/testremote_is_not_honoring_--backend/comment_8_3f17e1804ff779c5f9d00e56daf18ee3._comment
 create mode 100644 doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS.mdwn
 create mode 100644 doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_1_dd4734cec6290cd3eacd58545ef039e4._comment
 create mode 100644 doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_2_da46fc7a6bbdae0c3b44d241bc527b55._comment
 create mode 100644 doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_3_82b8570c9496ee1b111dbd1ea53e823c._comment
 create mode 100644 doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_4_e854aae525b7d4902fe2bc0f2c11ae5a._comment
 create mode 100644 doc/bugs/tls__58___peer_does_not_support_Extended_Main_Secret.mdwn
 create mode 100644 doc/bugs/tls__58___peer_does_not_support_Extended_Main_Secret/comment_1_731db4542017bef831bc7a06b70f79fb._comment
 create mode 100644 doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__.mdwn
 create mode 100644 doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_1_db83f6a38cae36da89f0ab4ef83021d8._comment
 create mode 100644 doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_2_2aeb065a257729e852055533aff04650._comment
 create mode 100644 doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_3_f8bd6a233d835bdc413bbf0127608431._comment
 create mode 100644 doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_4_320828c8d39d1f030d1797b539dbb22e._comment
 create mode 100644 doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_5_9fc2d7f4b39615e43bce3993e0a6e647._comment
 create mode 100644 doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_6_1b2eb9993e220082f3be5dd568deef3e._comment
 create mode 100644 doc/bugs/too_many_ssh_connections_during_sync_of_gcrypt_remotes.mdwn
 create mode 100644 doc/bugs/too_many_ssh_connections_during_sync_of_gcrypt_remotes/comment_1_8522285987f6d231c851861418af633a._comment
 create mode 100644 doc/bugs/too_many_ssh_connections_during_sync_of_gcrypt_remotes/comment_2_f87b3ba05c0cdfadd4d5da894dea0abb._comment
 create mode 100644 doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems.mdwn
 create mode 100644 doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_1_1d38283c9ea87174f3bbef9a58f5cb88._comment
 create mode 100644 doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_2_bf112edd075fbebe4fc959a387946eb9._comment
 create mode 100644 doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_3_a46080fbe82adf0986c5dc045e382501._comment
 create mode 100644 doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_4_760437bf3ba972a775bb190fb4b38202._comment
 create mode 100644 doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_5_060ba5ea88dcab2f4a0c199f13ef4f67._comment
 create mode 100644 doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_6_548303d6ffb21a9370b6904f41ff49c1._comment
 create mode 100644 doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_7_7ca00527ab5db058aadec4fe813e51fd._comment
 create mode 100644 doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_8_881aecb9ae671689453f6d5d780d844b._comment
 create mode 100644 doc/bugs/uftp_5__58___invalid_key_type.mdwn
 create mode 100644 doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn
 create mode 100644 doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_1_1c0cad1076d5d4d908b8297e7c13ea33._comment
 create mode 100644 doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_2_4609f9a1545b08e08021bf786561f5e5._comment
 create mode 100644 doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_3_6c99a97d56b1a3b12092c15fafcf8761._comment
 create mode 100644 doc/bugs/uninit_fails_when_I_symlink_your_symlink.mdwn
 create mode 100644 doc/bugs/uninit_fails_when_I_symlink_your_symlink/comment_5_3fe7520813dee36ffb5419ed70ea43b5._comment
 create mode 100644 doc/bugs/uninit_fails_when_I_symlink_your_symlink/comment_6_3afdea4f3705a9cfaa971ed3aa9f114c._comment
 create mode 100644 doc/bugs/unlocked_files_feel_too_slow_.mdwn
 create mode 100644 doc/bugs/unnecessary_work_when_drop_cannot_possibly_succeed.mdwn
 create mode 100644 doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD.mdwn
 create mode 100644 doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_1_70b807c69be263fd53c578fe6ec84561._comment
 create mode 100644 doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_2_eeff3cb51df849b783446e238de002a8._comment
 create mode 100644 doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_3_641473e43c8da7e7be02658cf8d3bd3e._comment
 create mode 100644 doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_4_59e2ea4d59d5f4a8472cc8c945b8a419._comment
 create mode 100644 doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_5_27a017a942f805e9b0216e77d4890c86._comment
 create mode 100644 doc/bugs/use_reflink_to_export_to_directory_special_remote.mdwn
 create mode 100644 doc/bugs/using_old_remote_format_generates_irritating_output.mdwn
 create mode 100644 doc/bugs/using_old_remote_format_generates_irritating_output/comment_1_fceba878f1097e27f056580e8d6d5b31._comment
 create mode 100644 doc/bugs/using_old_remote_format_generates_irritating_output/comment_2_416992874813f120721a56d88b2bef65._comment
 create mode 100644 doc/bugs/using_old_remote_format_generates_irritating_output/comment_3_a20f470c5226ac5693eb15146a02b3f5._comment
 create mode 100644 doc/bugs/using_old_remote_format_generates_irritating_output/comment_4_a81f06191bc03a7aad5929af99f0634e._comment
 create mode 100644 doc/bugs/using_old_remote_format_generates_irritating_output/comment_5_7438caecf78b4fb5d21f9f31dff95cf2._comment
 create mode 100644 doc/bugs/v6_appears_to_not_thin.mdwn
 create mode 100644 doc/bugs/v6_appears_to_not_thin/comment_1_d62791da504f6cf9bb26fa588756234c._comment
 create mode 100644 doc/bugs/v6_appears_to_not_thin/comment_2_82ff17c4063791d91a4fbe4e31802595._comment
 create mode 100644 doc/bugs/v6_appears_to_not_thin/comment_3_69afd9bc3f250418ba33cb1abeb2078d._comment
 create mode 100644 doc/bugs/v6_appears_to_not_thin/comment_4_bba7ba9c5b93fa33fc728daa0bb89497._comment
 create mode 100644 doc/bugs/v8_repo_auto_upgrades_to_v10.mdwn
 create mode 100644 doc/bugs/v8_repo_auto_upgrades_to_v10/comment_1_446aa74f0b54918dc8737483e3e8564a._comment
 create mode 100644 doc/bugs/vicfg_and_description_often_not_propagated.mdwn
 create mode 100644 doc/bugs/vicfg_and_description_often_not_propagated/comment_1_60c5ba2de0c8b9b4538a4abd146007f6._comment
 create mode 100644 doc/bugs/vicfg_and_description_often_not_propagated/comment_2_d56aed617e0791aa17d9f37c8d3fd317._comment
 create mode 100644 doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync.mdwn
 create mode 100644 doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync/comment_1_3c0be3ff163aae411f323e3445af94b1._comment
 create mode 100644 doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to.mdwn
 create mode 100644 doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_1_a6014d95b0ac0dc20e9495a717d6d615._comment
 create mode 100644 doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_2_323f1be80e2422e73ebd99b702a28e80._comment
 create mode 100644 doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_3_576c31b2cc5031cfb64ff58a1866b3b5._comment
 create mode 100644 doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_4_4097e8dde9d9fe29b540112f7400689a._comment
 create mode 100644 doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_5_5e5441cca2f3bbc252029aca358e9a47._comment
 create mode 100644 doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_.mdwn
 create mode 100644 doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_2_1d3214382c2bb604101a835c0bb7f146._comment
 create mode 100644 doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_2_7f4800ee68c98606bc8a3ce959646014._comment
 create mode 100644 doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_3_54c9716cd5cab7b196549af2f90bed0a._comment
 create mode 100644 doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_4_864988b3ebc11ea9e92c55ee765d6d5c._comment
 create mode 100644 doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_5_06d31ed5a8c187cec7bc90339550b5e8._comment
 create mode 100644 doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_6_5e7007182372d28ceb11a8692e2cf801._comment
 create mode 100644 doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_7_4de04de71792801f50256214f4b5fe9f._comment
 create mode 100644 doc/bugs/webapp_--listen_port_is_not_used__63__.mdwn
 create mode 100644 doc/bugs/webapp_--listen_port_is_not_used__63__/comment_1_275507b26ca13e5d55deec4b7af60699._comment
 create mode 100644 doc/bugs/webapp_--listen_port_is_not_used__63__/comment_2_55315d9013fc6acbde9f8b419757d949._comment
 create mode 100644 doc/bugs/webapp_--listen_port_is_not_used__63__/comment_3_2d18df9587b52cbb7c34bfce2e0f2fb2._comment
 create mode 100644 doc/bugs/webapp_--listen_port_is_not_used__63__/comment_4_ba217465bfa738b77ea9417a33810d75._comment
 create mode 100644 doc/bugs/webapp_--listen_port_is_not_used__63__/comment_5_99a6933f30649bc33ee5c74b33fc7046._comment
 create mode 100644 doc/bugs/webapp__58___difficult_to_abort_adding_a_repository.mdwn
 create mode 100644 doc/bugs/webdav_fails___40__server__58___radicale_0.9-1__41__.mdwn
 create mode 100644 doc/bugs/webdav_fails___40__server__58___radicale_0.9-1__41__/comment_1_487bf264afeef2a3b0a61d306ebfc3c5._comment
 create mode 100644 doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links.mdwn
 create mode 100644 doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_1_cb6c6e7bcbbe3006dd80e89fa545016d._comment
 create mode 100644 doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_2_146ed4bf42ce1979815db82bbf9a5b86._comment
 create mode 100644 doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_3_57924a0a08da3cafe78b95bf22ae89fd._comment
 create mode 100644 doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_4_4a7ec33d4470714c9fb4271d214b3d1f._comment
 create mode 100644 doc/bugs/weird_interaction_between___34__required__34___and___34__numcopies__34___on_duplicate_files.mdwn
 create mode 100644 doc/bugs/weird_interaction_between___34__required__34___and___34__numcopies__34___on_duplicate_files/comment_1_169d4f769e4ba6a81aaa7ed32c789b50._comment
 create mode 100644 doc/bugs/weird_interaction_between___34__required__34___and___34__numcopies__34___on_duplicate_files/comment_2_d20cb1d0abc9823aa557dcd698e735b2._comment
 create mode 100644 doc/bugs/weird_unicode_bug_on_windows.mdwn
 create mode 100644 doc/bugs/weird_unicode_bug_on_windows/comment_1_69af9bd8c7898fccc2219edd860d547b._comment
 create mode 100644 doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote.mdwn
 create mode 100644 doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_1_d823b7ee32183fbadd4a49f65e1a3a8b._comment
 create mode 100644 doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_2_f430538101f0ef6114b5e953248fa599._comment
 create mode 100644 doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_3_d96ded3c27c705789e5689f19dbcabcb._comment
 create mode 100644 doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_4_b70e83a44a85b006c2c6105660cd6a7a._comment
 create mode 100644 doc/bugs/whereis_outputs_no_informaiton_for_unlocked_files.mdwn
 create mode 100644 doc/bugs/whereis_outputs_no_informaiton_for_unlocked_files/comment_1_47bd0fc8d1c65f8a868d9722e66c71db._comment
 create mode 100644 doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals.mdwn
 create mode 100644 doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_1_57c55f62ced563f70612cba994b1ea8b._comment
 create mode 100644 doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_2_fcdc6ef1dd464d25ec3e26dac828830e._comment
 create mode 100644 doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_3_0460c7476fae95048f87cb6dd9d4a2ae._comment
 create mode 100644 doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_4_65647b8423127d450b0d1753767943d6._comment
 create mode 100644 doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__.mdwn
 create mode 100644 doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_1_e738eb3d45bb7c4baa0a5c88cdf7a40a._comment
 create mode 100644 doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_2_8ecb958a1a2c8cd9fd37798c0d4eb0cf._comment
 create mode 100644 doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_3_aed127be0616464fda064f00de954fc2._comment
 create mode 100644 doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_4_42ef3d3d157a97a202718f3b768916f8._comment
 create mode 100644 doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_5_8f71510a7547db8d0c63e4a4e3ddbd65._comment
 create mode 100644 doc/bugs/windows__58___two_repo_tests_fail_after_commit_5a98f2d5.mdwn
 create mode 100644 doc/bugs/windows__58___two_repo_tests_fail_after_commit_5a98f2d5/comment_1_af091a5799ac0445033c05173e25a4af._comment
 create mode 100644 doc/bugs/windows__58___two_repo_tests_fail_after_commit_5a98f2d5/comment_2_5c7ec0d8520f957ec4f6a4df30941cd8._comment
 create mode 100644 doc/bugs/windows_autostart.mdwn
 create mode 100644 doc/bugs/windows_autostart/comment_1_80a2561901554ddb45db719c086629b2._comment
 create mode 100644 doc/bugs/windows_autostart/comment_2_89078768dc9d9efd2d237fff5c7320ad._comment
 create mode 100644 doc/bugs/windows_autostart/comment_3_393899b1630cce0dc6b12ec7d29b81ca._comment
 create mode 100644 doc/bugs/windows_autostart/comment_4_b8d0b38aa7363e97c295b049bd939ad1._comment
 create mode 100644 doc/bugs/windows_autostart/comment_5_43077649e3ca6a132958c2a2b4914c3b._comment
 create mode 100644 doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf.mdwn
 create mode 100644 doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf/comment_1_c353c67f06f40c84b956990160205e0a._comment
 create mode 100644 doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf/comment_2_bd9a77da095bffdcd3ed30e08192b9d2._comment
 create mode 100644 doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf/comment_3_c46e7c7f3870b54563eb8e94d451fded._comment
 create mode 100644 doc/bugs/windows_ftbfs.mdwn
 create mode 100644 doc/bugs/windows_started_to_FTBFS.mdwn
 create mode 100644 doc/bugs/windows_started_to_FTBFS/comment_1_094012512e6c267f05d3d61c0ed638a0._comment
 create mode 100644 doc/bugs/windows_started_to_FTBFS/comment_2_1ad4a7da4dd4353838fd5c1f9610ee32._comment
 create mode 100644 doc/bugs/wrong_modes_for_some_lock_files_withcoresharedrepository.mdwn
 create mode 100644 doc/builds.mdwn
 create mode 100644 doc/chunking.mdwn
 create mode 100644 doc/chunking/comment_1_ddbc7a66de2def23cbf1e1de7defde08._comment
 create mode 100644 doc/chunking/comment_2_d43c297db9a31d1c896b48f0e3757229._comment
 create mode 100644 doc/chunking/comment_3_7305da05dff79b9cabc59af162db9925._comment
 create mode 100644 doc/chunking/comment_4_f098bf5a5d07b10d5be41658790547ad._comment
 create mode 100644 doc/coding_style.mdwn
 create mode 100644 doc/coding_style/comment_1_70521cf79ad06832b1d73fc2c20c68ec._comment
 create mode 100644 doc/coding_style/comment_2_a820b7c8ae7c2290eb000f61bdb5c514._comment
 create mode 100644 doc/coding_style/comment_3_61c178b997dd044f3531303913f8fa91._comment
 create mode 100644 doc/coding_style/comment_4_433b7ba5e51e746f6b033ebb5c0e50a2._comment
 create mode 100644 doc/comments.mdwn
 create mode 100644 doc/contact.mdwn
 create mode 100644 doc/contribute.mdwn
 create mode 100644 doc/contribute/comment_10_0b07e1baa5e89ba24f66c077719985e9._comment
 create mode 100644 doc/contribute/comment_1_c61530e14bdbd7c5ec8b0137c0da92f8._comment
 create mode 100644 doc/contribute/comment_2_637b05cfd48d2e337c3192989356d183._comment
 create mode 100644 doc/contribute/comment_3_e7219514f52207fcfb97aeec03241e8d._comment
 create mode 100644 doc/contribute/comment_4_21a75c774757f27911a9249f9b42368d._comment
 create mode 100644 doc/contribute/comment_5_c5f7f809da5829f4c259d0a630f0f722._comment
 create mode 100644 doc/contribute/comment_6_7b53ed13f455879a7462d74571283063._comment
 create mode 100644 doc/contribute/comment_7_a721a4abf10ae3a1e591f81b9069387f._comment
 create mode 100644 doc/contribute/comment_8_1b6c02d7ca6a36e4b1ce2bc52570c7fb._comment
 create mode 100644 doc/contribute/comment_9_62f827dd014481f41d77f4afec0b1de2._comment
 create mode 100644 doc/copies.mdwn
 create mode 100644 doc/copies/comment_1_af9bee33777fb8a187b714fc8c5fb11d._comment
 create mode 100644 doc/copies/comment_2_1214610c03193cb9dd76dc24e5b7fd76._comment
 create mode 100644 doc/copies/comment_3_5beb9a5b87dd6775f9b921ad1e9bc610._comment
 create mode 100644 doc/copies/comment_4_0daa1b3ecc2a4cf844b8f1b98a883e67._comment
 create mode 100644 doc/copies/comment_5_cc4cd8f739d4e72614c0b98f00e3510d._comment
 create mode 100644 doc/design.mdwn
 create mode 100644 doc/design/adjusted_branches.mdwn
 create mode 100644 doc/design/adjusted_branches/comment_1_5bdbf54ae75f77c69c8f557f4dbac13d._comment
 create mode 100644 doc/design/adjusted_branches/comment_2_ff7cbdf93f0be5886f212bdd411efb5b._comment
 create mode 100644 doc/design/adjusted_branches/comment_3_e2a4b1719ba9860da711b802de64daf5._comment
 create mode 100644 doc/design/adjusted_branches/comment_4_adfcbfa7a9193318cba459766a60c072._comment
 create mode 100644 doc/design/adjusted_branches/comment_5_882520747d41500d0ea8a18ab817121c._comment
 create mode 100644 doc/design/assistant.mdwn
 create mode 100644 doc/design/assistant/OSX.mdwn
 create mode 100644 doc/design/assistant/OSX/comment_1_9290f6e6f265e906b08631224392b7bf._comment
 create mode 100644 doc/design/assistant/android.mdwn
 create mode 100644 doc/design/assistant/android/comment_10_316bde8d22628e5e9d4f8dabce1d2ad4._comment
 create mode 100644 doc/design/assistant/android/comment_11_cf801ce1f49f0201681f0c9f69a62aae._comment
 create mode 100644 doc/design/assistant/android/comment_1_8be9a74e5fc4641c2bf2e1bb7673dd59._comment
 create mode 100644 doc/design/assistant/android/comment_2_3dd386ac1b757c73d14f14377b9eedd4._comment
 create mode 100644 doc/design/assistant/android/comment_3_5dca47a4599d6e88d19193701c5a571b._comment
 create mode 100644 doc/design/assistant/android/comment_4_054f06311e2b51d73be569f181eb004f._comment
 create mode 100644 doc/design/assistant/android/comment_5_bb3d36e9d29f2fa77bee6d47ef9917fe._comment
 create mode 100644 doc/design/assistant/android/comment_6_fee32a831eeb5736fe1dce52e30320c8._comment
 create mode 100644 doc/design/assistant/android/comment_7_d8e9b0a5287fc96b19dc2cb9da3586ce._comment
 create mode 100644 doc/design/assistant/android/comment_8_79a7b5bb5f4aaeea4a4e8ced0561701a._comment
 create mode 100644 doc/design/assistant/android/comment_9_55ea70a6929523d26248ff6409b04a6e._comment
 create mode 100644 doc/design/assistant/blog.mdwn
 create mode 100644 doc/design/assistant/blog/day_100__cursed_clouds.mdwn
 create mode 100644 doc/design/assistant/blog/day_102__very_high_level_programming.mdwn
 create mode 100644 doc/design/assistant/blog/day_102__very_high_level_programming/comment_1_c028b403261dd66bcf83e6ffd134b80b._comment
 create mode 100644 doc/design/assistant/blog/day_103__bugfix_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_104__misc.mdwn
 create mode 100644 doc/design/assistant/blog/day_104__misc/comment_1_13d7fad2d3f8eab10314784c035e2a16._comment
 create mode 100644 doc/design/assistant/blog/day_105__lazy_Sunday.mdwn
 create mode 100644 doc/design/assistant/blog/day_106__lazy_Monday.mdwn
 create mode 100644 doc/design/assistant/blog/day_107__memory_leak.mdwn
 create mode 100644 doc/design/assistant/blog/day_108__another_zombie_outbreak.mdwn
 create mode 100644 doc/design/assistant/blog/day_108__another_zombie_outbreak/comment_1_194c48d65993462f809a2cfaa774a3e2._comment
 create mode 100644 doc/design/assistant/blog/day_108__another_zombie_outbreak/comment_2_ef5ee5933fcadcb81cc81b816db14bda._comment
 create mode 100644 doc/design/assistant/blog/day_109__dropping.mdwn
 create mode 100644 doc/design/assistant/blog/day_10__lsof.mdwn
 create mode 100644 doc/design/assistant/blog/day_10__lsof/comment_1_9b8c28c85c979f32e5c295b6a03c048e._comment
 create mode 100644 doc/design/assistant/blog/day_110__more_dropping.mdwn
 create mode 100644 doc/design/assistant/blog/day_111__config_monitor.mdwn
 create mode 100644 doc/design/assistant/blog/day_112__and_now_for_something_completely_different.mdwn
 create mode 100644 doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_1_5e4fe1538d9ae1c450b0a6602fc6d29b._comment
 create mode 100644 doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_2_c5a734f611ecc95729904e645583ee43._comment
 create mode 100644 doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_3_46b16dcd0fce07036cd8ed6ed9d2b055._comment
 create mode 100644 doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_4_1fe036e4c65fb4211aa2c394f535344a._comment
 create mode 100644 doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_5_e4ba3568c4efd98f212dd47427a1cf47._comment
 create mode 100644 doc/design/assistant/blog/day_113__notifier_work.mdwn
 create mode 100644 doc/design/assistant/blog/day_114__xmpp.mdwn
 create mode 100644 doc/design/assistant/blog/day_114__xmpp/comment_1_c2b0617a2fc3dc4f19a6be6947913842._comment
 create mode 100644 doc/design/assistant/blog/day_114__xmpp/comment_2_d14375dfb5791615802dab3c5438f8e2._comment
 create mode 100644 doc/design/assistant/blog/day_114__xmpp/comment_3_6d72ea32c111e605be30ad2153fc71c9._comment
 create mode 100644 doc/design/assistant/blog/day_114__xmpp/comment_4_e51d6f854db5f9e74a1aa58bd8923795._comment
 create mode 100644 doc/design/assistant/blog/day_115__my_new_form.mdwn
 create mode 100644 doc/design/assistant/blog/day_116__the_segfault.mdwn
 create mode 100644 doc/design/assistant/blog/day_117__new_topologies.mdwn
 create mode 100644 doc/design/assistant/blog/day_118__monadic_discontinuity.mdwn
 create mode 100644 doc/design/assistant/blog/day_119__time_for_testing.mdwn
 create mode 100644 doc/design/assistant/blog/day_11__freebsd.mdwn
 create mode 100644 doc/design/assistant/blog/day_120__test_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_121__buddy_list.mdwn
 create mode 100644 doc/design/assistant/blog/day_122__xmpp_pairing.mdwn
 create mode 100644 doc/design/assistant/blog/day_122__xmpp_pairing/comment_1_e95efb23eb2e67e3f11a5c7de56424a7._comment
 create mode 100644 doc/design/assistant/blog/day_122__xmpp_pairing/comment_2_30e251e73146512bde8b2f69eddeef2e._comment
 create mode 100644 doc/design/assistant/blog/day_123__xmpp_insanity.mdwn
 create mode 100644 doc/design/assistant/blog/day_124__git_push_over_xmpp_groundwork.mdwn
 create mode 100644 doc/design/assistant/blog/day_125__xmpp_push_continues.mdwn
 create mode 100644 doc/design/assistant/blog/day_126__mr_watson_come_here.mdwn
 create mode 100644 doc/design/assistant/blog/day_126__mr_watson_come_here/comment_1_ee1361e6b235f4e1c00596ba516b519a._comment
 create mode 100644 doc/design/assistant/blog/day_126__mr_watson_come_here/comment_2_8eb366ae7efb347bd3bbd9a98e0821b3._comment
 create mode 100644 doc/design/assistant/blog/day_127__xmpp_syncs.mdwn
 create mode 100644 doc/design/assistant/blog/day_128__last_xmpp_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_128__last_xmpp_day/comment_1_fd8c1d6358cb50f4dad8ba11d33d861f._comment
 create mode 100644 doc/design/assistant/blog/day_128__last_xmpp_day/comment_2_43664b73c71c41d71bc95e665f128106._comment
 create mode 100644 doc/design/assistant/blog/day_128__last_xmpp_day/comment_3_d369b04f686009a9dbb57b999107a55e._comment
 create mode 100644 doc/design/assistant/blog/day_128__last_xmpp_day/comment_4_095855d301e7ccd3689ffe507cfb63ee._comment
 create mode 100644 doc/design/assistant/blog/day_128__last_xmpp_day/comment_5_da7b0586b0b28e1e0fe4126f6543a7bc._comment
 create mode 100644 doc/design/assistant/blog/day_128__last_xmpp_day/comment_6_2f9ba367e19d77bf52f372b6f0f5938a._comment
 create mode 100644 doc/design/assistant/blog/day_129__release.mdwn
 create mode 100644 doc/design/assistant/blog/day_12__freebsd_redux.mdwn
 create mode 100644 doc/design/assistant/blog/day_12__freebsd_redux/comment_1_5da32cf53f1de27bfe6cec2d294db3e1._comment
 create mode 100644 doc/design/assistant/blog/day_12__freebsd_redux/comment_2_696d6e22034acf5bb60d80124b72ef2f._comment
 create mode 100644 doc/design/assistant/blog/day_12__freebsd_redux/comment_3_5ab7808595e3b51ca4141d15fdd44743._comment
 create mode 100644 doc/design/assistant/blog/day_130__what_now.mdwn
 create mode 100644 doc/design/assistant/blog/day_130__what_now/comment_1_402f00cc034351d8253a797dd4de55bf._comment
 create mode 100644 doc/design/assistant/blog/day_131__webdav_groundwork.mdwn
 create mode 100644 doc/design/assistant/blog/day_132__webdav_continued.mdwn
 create mode 100644 doc/design/assistant/blog/day_133__webdav_working.mdwn
 create mode 100644 doc/design/assistant/blog/day_134__box.com_configurator.mdwn
 create mode 100644 doc/design/assistant/blog/day_135__progress_revisited.mdwn
 create mode 100644 doc/design/assistant/blog/day_136__misc.mdwn
 create mode 100644 doc/design/assistant/blog/day_137__Glacier.mdwn
 create mode 100644 doc/design/assistant/blog/day_138__back.mdwn
 create mode 100644 doc/design/assistant/blog/day_138__back/comment_1_65a8499b284bed38d2bde1886a54a311._comment
 create mode 100644 doc/design/assistant/blog/day_139__catch_up.mdwn
 create mode 100644 doc/design/assistant/blog/day_13__kqueue_continued.mdwn
 create mode 100644 doc/design/assistant/blog/day_140__release_monday.mdwn
 create mode 100644 doc/design/assistant/blog/day_141__release_tuesday.mdwn
 create mode 100644 doc/design/assistant/blog/day_141__release_tuesday/comment_1_a5adea7a726df12f9121c744a036f08d._comment
 create mode 100644 doc/design/assistant/blog/day_142__filling_in.mdwn
 create mode 100644 doc/design/assistant/blog/day_143__what_next.mdwn
 create mode 100644 doc/design/assistant/blog/day_143__what_next/comment_1_40cf25a2ebdd43d8974a28e180e100e5._comment
 create mode 100644 doc/design/assistant/blog/day_143__what_next/comment_2_af9ccbbc5131e6333c029415141bdb51._comment
 create mode 100644 doc/design/assistant/blog/day_144__webapp_work.mdwn
 create mode 100644 doc/design/assistant/blog/day_145__more_webapp_work.mdwn
 create mode 100644 doc/design/assistant/blog/day_146__meanwhile.mdwn
 create mode 100644 doc/design/assistant/blog/day_147__direct_mode.mdwn
 create mode 100644 doc/design/assistant/blog/day_147__direct_mode/comment_1_0bd69532afce9dc04e3d88bfd0aed4b2._comment
 create mode 100644 doc/design/assistant/blog/day_147__direct_mode/comment_2_3b26f0d081c3bf1037bb872d529ce825._comment
 create mode 100644 doc/design/assistant/blog/day_148__direct_mode.mdwn
 create mode 100644 doc/design/assistant/blog/day_149__rainy_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_14__kqueue_kqueue_kqueue.mdwn
 create mode 100644 doc/design/assistant/blog/day_14__thinking_about_syncing.mdwn
 create mode 100644 doc/design/assistant/blog/day_150__12__58__12.mdwn
 create mode 100644 doc/design/assistant/blog/day_151__direct_mode_toggle.mdwn
 create mode 100644 doc/design/assistant/blog/day_152__bugfixes.mdwn
 create mode 100644 doc/design/assistant/blog/day_152__bugfixes/comment_1_46863a875f9daa6f2c9248b66ff91929._comment
 create mode 100644 doc/design/assistant/blog/day_152__bugfixes/comment_2_a586e617bc024c8a9ff60f1b8345d74d._comment
 create mode 100644 doc/design/assistant/blog/day_153__hibernation.mdwn
 create mode 100644 doc/design/assistant/blog/day_154__direct_mode_merging.mdwn
 create mode 100644 doc/design/assistant/blog/day_155__bugfixes.mdwn
 create mode 100644 doc/design/assistant/blog/day_156_and_157__direct_mode_assistant.mdwn
 create mode 100644 doc/design/assistant/blog/day_158__fsevents.mdwn
 create mode 100644 doc/design/assistant/blog/day_158__fsevents/comment_1_b278372ac6399f64d5fa9da178278a6d._comment
 create mode 100644 doc/design/assistant/blog/day_158__fsevents/comment_2_2d5ce9b2807068c3517e185945662bd2._comment
 create mode 100644 doc/design/assistant/blog/day_159__fsevents_and_assistant.mdwn
 create mode 100644 doc/design/assistant/blog/day_159__fsevents_and_assistant/comment_1_b85f446c3fa8d703a2a8882825c6f33f._comment
 create mode 100644 doc/design/assistant/blog/day_159__fsevents_and_assistant/comment_2_a150b404e0c39e0bb2f7dd00cda63cdc._comment
 create mode 100644 doc/design/assistant/blog/day_159__fsevents_and_assistant/comment_3_37abc41bae23a1d7de0d19d952aec492._comment
 create mode 100644 doc/design/assistant/blog/day_15__its_aliiive.mdwn
 create mode 100644 doc/design/assistant/blog/day_160__finishing_up_direct_mode.mdwn
 create mode 100644 doc/design/assistant/blog/day_161__release_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_161__release_day/comment_1_e82c67f3ce216618149537bba1e0b850._comment
 create mode 100644 doc/design/assistant/blog/day_161__release_day/comment_2_b1fe96fd818935c0497b78bb8ad32ffa._comment
 create mode 100644 doc/design/assistant/blog/day_161__release_day/comment_3_40bac0e1756aa77bb966c4654857141c._comment
 create mode 100644 doc/design/assistant/blog/day_161__release_day/comment_4_af65656b0d1179636937595868bb97b0._comment
 create mode 100644 doc/design/assistant/blog/day_161__release_day/comment_5_0c05caaaf9588e124585041bf5f45d75._comment
 create mode 100644 doc/design/assistant/blog/day_161__release_day/comment_6_5dfb5f428633d6062925f61af2b8829b._comment
 create mode 100644 doc/design/assistant/blog/day_161__release_day/comment_7_ac4effb381b08d94d4a2d2482e92c89a._comment
 create mode 100644 doc/design/assistant/blog/day_161__release_day/comment_8_32600e89e3098e52a1280895e03b3f86._comment
 create mode 100644 doc/design/assistant/blog/day_161__release_day/comment_9_07e5d0c3cad0ce2bd4943e53b61f1767._comment
 create mode 100644 doc/design/assistant/blog/day_162__UI.mdwn
 create mode 100644 doc/design/assistant/blog/day_163__free_features.mdwn
 create mode 100644 doc/design/assistant/blog/day_164__bugfixes.mdwn
 create mode 100644 doc/design/assistant/blog/day_165__release_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_166__a_short_long_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_167__safe_direct_mode_transfers.mdwn
 create mode 100644 doc/design/assistant/blog/day_167__safe_direct_mode_transfers/comment_1_f1aa64fe803d8c14b250a4e98b88142a._comment
 create mode 100644 doc/design/assistant/blog/day_167__safe_direct_mode_transfers/comment_2_5ce1db84c9ead713f1272c4975645b93._comment
 create mode 100644 doc/design/assistant/blog/day_168__back_to_theme.mdwn
 create mode 100644 doc/design/assistant/blog/day_168__back_to_theme/comment_1_f248780bfcbd0384d9d72c2633a4ea46._comment
 create mode 100644 doc/design/assistant/blog/day_168__back_to_theme/comment_2_5beba073373b8e75a32d1fcfdc1a0782._comment
 create mode 100644 doc/design/assistant/blog/day_169__direct_mode_is_safe.mdwn
 create mode 100644 doc/design/assistant/blog/day_169__direct_mode_is_safe/comment_1_65f87656c4e6bc7cdb614f53961341c9._comment
 create mode 100644 doc/design/assistant/blog/day_169__direct_mode_is_safe/comment_2_a116a402a126c62be54c06afd82439ab._comment
 create mode 100644 doc/design/assistant/blog/day_16__more_robust_syncing.mdwn
 create mode 100644 doc/design/assistant/blog/day_16__more_robust_syncing/comment_1_23e7a90429e4431f90787cd016ebe188._comment
 create mode 100644 doc/design/assistant/blog/day_16__more_robust_syncing/comment_2_8e7e7cd27791bb47625e60a284e9c802._comment
 create mode 100644 doc/design/assistant/blog/day_170__bugfixes_and_release.mdwn
 create mode 100644 doc/design/assistant/blog/day_171__logs.mdwn
 create mode 100644 doc/design/assistant/blog/day_172__short_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_172__short_day/comment_1_b75e26b77a23a45da1c4c3bca1399246._comment
 create mode 100644 doc/design/assistant/blog/day_173__snow_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_174__last_weekend_before_AU.mdwn
 create mode 100644 doc/design/assistant/blog/day_174__last_weekend_before_AU/comment_1_05a8fd47f54373331741cc869a53b0c3._comment
 create mode 100644 doc/design/assistant/blog/day_174__last_weekend_before_AU/comment_2_fc8e65eef954c4caa8321c2fe8b711b7._comment
 create mode 100644 doc/design/assistant/blog/day_174__last_weekend_before_AU/comment_3_399534f540d85cac067fbb7be9d373b4._comment
 create mode 100644 doc/design/assistant/blog/day_175__pacific_features.mdwn
 create mode 100644 doc/design/assistant/blog/day_175__pacific_features/comment_1_c3ee4386f872b7c76aaecfa638b368cb._comment
 create mode 100644 doc/design/assistant/blog/day_176__thread_management.mdwn
 create mode 100644 doc/design/assistant/blog/day_178__bus_hacking.mdwn
 create mode 100644 doc/design/assistant/blog/day_179__brief_updates.mdwn
 create mode 100644 doc/design/assistant/blog/day_179__brief_updates/comment_1_920a84457d40358507a3eb817a4568d9._comment
 create mode 100644 doc/design/assistant/blog/day_17__push_queue_prune.mdwn
 create mode 100644 doc/design/assistant/blog/day_180__back.mdwn
 create mode 100644 doc/design/assistant/blog/day_181__triage.mdwn
 create mode 100644 doc/design/assistant/blog/day_182__it_begins.mdwn
 create mode 100644 doc/design/assistant/blog/day_183__plan_b.mdwn
 create mode 100644 doc/design/assistant/blog/day_184__just_wanna_run_something.mdwn
 create mode 100644 doc/design/assistant/blog/day_184__just_wanna_run_something/comment_1_689adac7e26cb0b0a4e7ecc787cfd716._comment
 create mode 100644 doc/design/assistant/blog/day_185__android_liftoff.mdwn
 create mode 100644 doc/design/assistant/blog/day_185__android_liftoff/comment_1_b7d28010a72619a7e9a5ad4f2a0d6c07._comment
 create mode 100644 doc/design/assistant/blog/day_185__android_liftoff/comment_2_ddeb24e86fafb7dae93142cc02767aad._comment
 create mode 100644 doc/design/assistant/blog/day_186__Android_success.mdwn
 create mode 100644 doc/design/assistant/blog/day_186__Android_success/comment_1_1629da240ca7db5f8a32059f561fd435._comment
 create mode 100644 doc/design/assistant/blog/day_187__porting_utilities.mdwn
 create mode 100644 doc/design/assistant/blog/day_187__porting_utilities/comment_1_0e6a3f4fe8e09f247fa04156bc60f8c7._comment
 create mode 100644 doc/design/assistant/blog/day_188__crippled_filesystem_support.mdwn
 create mode 100644 doc/design/assistant/blog/day_188__crippled_filesystem_support/comment_1_32a296fce23ae4b1e18bd5a9964bf619._comment
 create mode 100644 doc/design/assistant/blog/day_189__more_crippling.mdwn
 create mode 100644 doc/design/assistant/blog/day_18__merging.mdwn
 create mode 100644 doc/design/assistant/blog/day_18__merging/comment_1_7a553ad559519f3b3e3cd20115b4c44e._comment
 create mode 100644 doc/design/assistant/blog/day_190-191__weekend.mdwn
 create mode 100644 doc/design/assistant/blog/day_190-191__weekend/comment_1_dbd692d12c14d08acd7d73a655b34e8b._comment
 create mode 100644 doc/design/assistant/blog/day_190-191__weekend/comment_2_c813830e53471a9732e010a748d574fc._comment
 create mode 100644 doc/design/assistant/blog/day_192_193__more_porting.mdwn
 create mode 100644 doc/design/assistant/blog/day_194__nice_moment.mdwn
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app.mdwn
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_10_0112007552b30cd9bfeac614a1e399c4._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_11_230d3c169c713f613b9d607d84ce5092._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_12_8d74ad2a61c02272758d157282ad56ec._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_13_4f6bc0680f2debd638933968a26975e0._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_14_71539c62608866464e8faa76bc522a55._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_15_e1b205289721ae79ac7fbed2f44018b2._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_1_4bc0aeae4fa1116944644c64feaf9697._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_2_17bb6e7565d4c757f6c1e3514c22f47d._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_3_cd8a6bec0f7c6843dd11d3266f25f864._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_4_2d2eee4bcbbd1d069a80bff5edc90c3c._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_6_3d96568c469a8c53a982f304eae5e7d4._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_6_e8667c47d07fc842cf0fe2ebbfbc1c58._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_7_cf8da7720ddc20b05955ee671ca4acd5._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_8_f4709bdbc739182819b648fd6aa00531._comment
 create mode 100644 doc/design/assistant/blog/day_195__real_android_app/comment_9_e66af12c7eca0d457b8406e9fb4b69be._comment
 create mode 100644 doc/design/assistant/blog/day_196__android_bugfixes.mdwn
 create mode 100644 doc/design/assistant/blog/day_197__template_haskell.mdwn
 create mode 100644 doc/design/assistant/blog/day_197__template_haskell/comment_1_82d9f9508929d84abf7b718c59436ae8._comment
 create mode 100644 doc/design/assistant/blog/day_198__bugfixes.mdwn
 create mode 100644 doc/design/assistant/blog/day_198__bugfixes/comment_1_5a15b5bad0f9ba2423d2aebe440ac0ea._comment
 create mode 100644 doc/design/assistant/blog/day_198__bugfixes/comment_2_36d94b838e5e65c85e7afaabe8a578f1._comment
 create mode 100644 doc/design/assistant/blog/day_198__bugfixes/comment_3_ae9b74341a3bc6e1e84d2c0ca4c5f612._comment
 create mode 100644 doc/design/assistant/blog/day_198__bugfixes/comment_4_5a4827227c03bcff3b1e4c44b531f816._comment
 create mode 100644 doc/design/assistant/blog/day_198__bugfixes/comment_5_9c5f4c85217e898be4c57c615e53c36f._comment
 create mode 100644 doc/design/assistant/blog/day_198__bugfixes/comment_6_bccf1abfb7f56d97673158f3ccfce511._comment
 create mode 100644 doc/design/assistant/blog/day_198__bugfixes/comment_7_6f1b51b002cc5d2b505d80e3e04bf6f3._comment
 create mode 100644 doc/design/assistant/blog/day_198__bugfixes/comment_8_8a3542437663028b17442818eba3f7c5._comment
 create mode 100644 doc/design/assistant/blog/day_199__wrapping_up_Android_for_now.mdwn
 create mode 100644 doc/design/assistant/blog/day_199__wrapping_up_Android_for_now/comment_1_ec57358afc7e78d2860aa4237793832d._comment
 create mode 100644 doc/design/assistant/blog/day_19__random_improvements.mdwn
 create mode 100644 doc/design/assistant/blog/day_1__inotify.mdwn
 create mode 100644 doc/design/assistant/blog/day_200__release_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_10_40cfe9bfd9e611fd734dbb5aad348aa3._comment
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_11_b26890fdae575d42170988073fb2e45d._comment
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_13_710a30c5d31bf549833ecfe9a0997c94._comment
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_13_b6f62ab7e810ba6d3a43f0ead370c79a._comment
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_1_a68e1ed7829b49086c567d97ddc09912._comment
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_2_39d3ad0a029fe56e96f97d28d17fbbd2._comment
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_3_5b752d6a8d74e61190f09384b6108206._comment
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_4_881274ae0d6230bb4cafa4151ad72b49._comment
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_5_e220059be77cf0ef396f37a4f9ccf9b5._comment
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_6_ec2152151188dd252cdb61c68cfc12e4._comment
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_7_42572411617c287368482bb9dcf94324._comment
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_8_6b69aa81a9ba4e07e547ed1869946d51._comment
 create mode 100644 doc/design/assistant/blog/day_200__release_day/comment_9_b070a2e4151d9fbf43d7906efa78515f._comment
 create mode 100644 doc/design/assistant/blog/day_201__real_Android_wrapup.mdwn
 create mode 100644 doc/design/assistant/blog/day_201__real_Android_wrapup/comment_1_88b9950c51324f0bb89c5646b3170952._comment
 create mode 100644 doc/design/assistant/blog/day_201__real_Android_wrapup/fib.png
 create mode 100644 doc/design/assistant/blog/day_201__working_web_server.mdwn
 create mode 100644 doc/design/assistant/blog/day_203__procrastination.mdwn
 create mode 100644 doc/design/assistant/blog/day_204__deprocrastination.mdwn
 create mode 100644 doc/design/assistant/blog/day_205_206__rainy_day__snow_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_207__XMPP.mdwn
 create mode 100644 doc/design/assistant/blog/day_208__bugfixes.mdwn
 create mode 100644 doc/design/assistant/blog/day_209__The_Bug.mdwn
 create mode 100644 doc/design/assistant/blog/day_20__data_transfer_design.mdwn
 create mode 100644 doc/design/assistant/blog/day_210__spring.mdwn
 create mode 100644 doc/design/assistant/blog/day_211__zooming_along.mdwn
 create mode 100644 doc/design/assistant/blog/day_212__accidental_all_nighter.mdwn
 create mode 100644 doc/design/assistant/blog/day_212__accidental_all_nighter/comment_1_6ee1f8056eedb6eb18013faf8f5ec212._comment
 create mode 100644 doc/design/assistant/blog/day_212__accidental_all_nighter/comment_2_07c83d75bb105bb77ada07359ed0ea7a._comment
 create mode 100644 doc/design/assistant/blog/day_212__accidental_all_nighter/comment_3_2c904d33f4f14807fbe718a01e98800a._comment
 create mode 100644 doc/design/assistant/blog/day_212__accidental_all_nighter/comment_4_59ec5c1cab75df87293800a7a03fe9c6._comment
 create mode 100644 doc/design/assistant/blog/day_212__accidental_all_nighter/comment_5_13893f106e835dcc52e03c7c6740c35b._comment
 create mode 100644 doc/design/assistant/blog/day_213__costs.mdwn
 create mode 100644 doc/design/assistant/blog/day_214__release_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_215__dashboard_UI_refresh.mdwn
 create mode 100644 doc/design/assistant/blog/day_216__more_bugfixes.mdwn
 create mode 100644 doc/design/assistant/blog/day_216__more_bugfixes/comment_1_299462bcdd0e4f6cd7895b5f40ca00ad._comment
 create mode 100644 doc/design/assistant/blog/day_216__more_bugfixes/comment_2_1913d65dfe4ba08379d82a4a2ca91c40._comment
 create mode 100644 doc/design/assistant/blog/day_216__more_bugfixes/comment_3_92c774599a78540ad398afcd1d05f7ce._comment
 create mode 100644 doc/design/assistant/blog/day_217__nothing.mdwn
 create mode 100644 doc/design/assistant/blog/day_219__bug_triage.mdwn
 create mode 100644 doc/design/assistant/blog/day_219__bug_triage/comment_1_c6b977a969cacdce62987a439b7686f5._comment
 create mode 100644 doc/design/assistant/blog/day_21__transfer_tracking.mdwn
 create mode 100644 doc/design/assistant/blog/day_220__performance.mdwn
 create mode 100644 doc/design/assistant/blog/day_221__this_and_that.mdwn
 create mode 100644 doc/design/assistant/blog/day_222__back.mdwn
 create mode 100644 doc/design/assistant/blog/day_222__back/comment_1_f05b48231a1ee0cffba7d66e112e5551._comment
 create mode 100644 doc/design/assistant/blog/day_222__back/comment_2_4d5f003ccd81580017ebf0dc31bc9cda._comment
 create mode 100644 doc/design/assistant/blog/day_223__progress_revisited.mdwn
 create mode 100644 doc/design/assistant/blog/day_224__annex.largefiles.mdwn
 create mode 100644 doc/design/assistant/blog/day_224__annex.largefiles/comment_1_408e4021b18f7ff5548d2d19ab558922._comment
 create mode 100644 doc/design/assistant/blog/day_224__annex.largefiles/comment_2_b24d1da2bc4307ded0216daffb8f9336._comment
 create mode 100644 doc/design/assistant/blog/day_225__back_from_the_dead.mdwn
 create mode 100644 doc/design/assistant/blog/day_225__back_from_the_dead/comment_1_9ac37c3b5c4c72ec8a39dce00bcbe420._comment
 create mode 100644 doc/design/assistant/blog/day_225__back_from_the_dead/comment_2_26125dd9ef2bd10b597d14b2c6180952._comment
 create mode 100644 doc/design/assistant/blog/day_226__poll_results.mdwn
 create mode 100644 doc/design/assistant/blog/day_226__poll_results/comment_1_1ed980472214be6d0a8cf55f37797fda._comment
 create mode 100644 doc/design/assistant/blog/day_226__poll_results/comment_2_6823b0a9a8037f1a5214db4db98fb16e._comment
 create mode 100644 doc/design/assistant/blog/day_227__bigfixing_all_day_today.mdwn
 create mode 100644 doc/design/assistant/blog/day_228__more_work_on_repository_removals.mdwn
 create mode 100644 doc/design/assistant/blog/day_229__rainy_day_bugfixes.mdwn
 create mode 100644 doc/design/assistant/blog/day_22__horrible_option_parsing_hack.mdwn
 create mode 100644 doc/design/assistant/blog/day_230__Mom.mdwn
 create mode 100644 doc/design/assistant/blog/day_230__Mom/comment_1_696bba2246c8a9e6ce4aed3071bcc96c._comment
 create mode 100644 doc/design/assistant/blog/day_230__Mom/comment_2_2fa295ab6db0828cb725cfcfb6777822._comment
 create mode 100644 doc/design/assistant/blog/day_230__Mom/comment_3_fafd7abec629290418334ddb015bf62c._comment
 create mode 100644 doc/design/assistant/blog/day_230__Mom/comment_4_450cac0f2e82c94fd34b527ae05ef1b8._comment
 create mode 100644 doc/design/assistant/blog/day_231__insert_title.mdwn
 create mode 100644 doc/design/assistant/blog/day_232__headless_webapp.mdwn
 create mode 100644 doc/design/assistant/blog/day_232__headless_webapp/comment_1_0fdd77d143ecba6fdb9f75cb6fc37bfb._comment
 create mode 100644 doc/design/assistant/blog/day_232__headless_webapp/comment_2_0784a2a73c3e2945f3d3f2577b3b9c9c._comment
 create mode 100644 doc/design/assistant/blog/day_232__headless_webapp/comment_3_ccb9fa22422fb913b6a496ebe65c49fb._comment
 create mode 100644 doc/design/assistant/blog/day_232__headless_webapp/comment_4_ceba4468760a2525960327698431cee2._comment
 create mode 100644 doc/design/assistant/blog/day_232__headless_webapp/comment_5_7e51a197ff9970ae50cf47bd3a922257._comment
 create mode 100644 doc/design/assistant/blog/day_233__taxes.mdwn
 create mode 100644 doc/design/assistant/blog/day_233__taxes/comment_1_9473ffdc42595af9c293fbcd5a1cdb54._comment
 create mode 100644 doc/design/assistant/blog/day_233__taxes/comment_2_5feed8d7053ba03812ccda8c61fd9775._comment
 create mode 100644 doc/design/assistant/blog/day_234__clean_shutdown.mdwn
 create mode 100644 doc/design/assistant/blog/day_235__birthday.mdwn
 create mode 100644 doc/design/assistant/blog/day_235__birthday/comment_1_db558b071067c1e63cde05cca0551094._comment
 create mode 100644 doc/design/assistant/blog/day_235__birthday/comment_2_d1a2c1124781118267599457ae9e0512._comment
 create mode 100644 doc/design/assistant/blog/day_235__birthday/comment_3_b853508d1d15234958b9f4a39277e45c._comment
 create mode 100644 doc/design/assistant/blog/day_235__birthday/comment_5_73aad3398a43bc4d28bca9bf635fa757._comment
 create mode 100644 doc/design/assistant/blog/day_236__evil_splicer.mdwn
 create mode 100644 doc/design/assistant/blog/day_237__gnome-keyring_craziness.mdwn
 create mode 100644 doc/design/assistant/blog/day_237__gnome-keyring_craziness/comment_1_0cb088b732881d1fa92493aa1fd93d43._comment
 create mode 100644 doc/design/assistant/blog/day_237__gnome-keyring_craziness/comment_2_b855fd710954beebaafe6d2bd03eb368._comment
 create mode 100644 doc/design/assistant/blog/day_238__back_to_Android.mdwn
 create mode 100644 doc/design/assistant/blog/day_239__bugfixes_and_frustration.mdwn
 create mode 100644 doc/design/assistant/blog/day_23__transfer_watching.mdwn
 create mode 100644 doc/design/assistant/blog/day_240__it_builds.mdwn
 create mode 100644 doc/design/assistant/blog/day_240__it_builds/comment_1_151840ae0020ea63b2f041488c905386._comment
 create mode 100644 doc/design/assistant/blog/day_241__cleanup.mdwn
 create mode 100644 doc/design/assistant/blog/day_241__cleanup/comment_1_0e283cdf66a25b3cc9423fe651084cb9._comment
 create mode 100644 doc/design/assistant/blog/day_242__more_porting.mdwn
 create mode 100644 doc/design/assistant/blog/day_243__in_the_field.mdwn
 create mode 100644 doc/design/assistant/blog/day_244__android_porting.mdwn
 create mode 100644 doc/design/assistant/blog/day_245__misc.mdwn
 create mode 100644 doc/design/assistant/blog/day_245__misc/comment_1_3a2976617bb0cdc206fb1397a2ef1177._comment
 create mode 100644 doc/design/assistant/blog/day_245__misc/comment_2_e0f9704e91fedca8ff26356f354cc1c3._comment
 create mode 100644 doc/design/assistant/blog/day_245__misc/comment_3_93003a0d0983efbdc046d7459be194b0._comment
 create mode 100644 doc/design/assistant/blog/day_246__bug_treadmill.mdwn
 create mode 100644 doc/design/assistant/blog/day_246__bug_treadmill/comment_1_f76f653364fe2b97e85e8356c93b0fce._comment
 create mode 100644 doc/design/assistant/blog/day_247__performance_tuning.mdwn
 create mode 100644 doc/design/assistant/blog/day_248__Internet_Archive.mdwn
 create mode 100644 doc/design/assistant/blog/day_249__quiet_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_24__airport_digressions.mdwn
 create mode 100644 doc/design/assistant/blog/day_250__stymied.mdwn
 create mode 100644 doc/design/assistant/blog/day_250__stymied/comment_1_330a10d447ccc3db03fcbfe571dbb404._comment
 create mode 100644 doc/design/assistant/blog/day_251__xmpp_improvements.mdwn
 create mode 100644 doc/design/assistant/blog/day_252__release_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_253__OMG.mdwn
 create mode 100644 doc/design/assistant/blog/day_253__OMG/comment_1_bbdc61092771163e65a90a4755a807d8._comment
 create mode 100644 doc/design/assistant/blog/day_254__Android_app_polishing.mdwn
 create mode 100644 doc/design/assistant/blog/day_254__Android_app_polishing/comment_1_37f4ff5227566ce4b3fa69fc32568841._comment
 create mode 100644 doc/design/assistant/blog/day_254__Android_app_polishing/comment_2_58bbb105bdbb72bba85c3622195f43b9._comment
 create mode 100644 doc/design/assistant/blog/day_255__Debian_release_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_256__8bit.mdwn
 create mode 100644 doc/design/assistant/blog/day_256__8bit/comment_1_f9b50263e3997d4c5b9836a2e0a346d7._comment
 create mode 100644 doc/design/assistant/blog/day_257__rainy_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_258__beginning_of_the_end.mdwn
 create mode 100644 doc/design/assistant/blog/day_259__Android_dominos_toppling.mdwn
 create mode 100644 doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_1_0b4a6e4893b0157e4768b46468dbbb87._comment
 create mode 100644 doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_2_1ebc5aff5d217e1392cb7c8bb6c5156b._comment
 create mode 100644 doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_3_eed7792f6142f3fc74d3c384bb16559b._comment
 create mode 100644 doc/design/assistant/blog/day_25__transfer_queueing.mdwn
 create mode 100644 doc/design/assistant/blog/day_25__transfer_queueing/comment_1_59fd4f1ffe96c412f613dc86276e7dbd._comment
 create mode 100644 doc/design/assistant/blog/day_25__transfer_queueing/comment_2_93bf768a67117e873af5732ecf08dc78._comment
 create mode 100644 doc/design/assistant/blog/day_260__Windows_dev_environment.mdwn
 create mode 100644 doc/design/assistant/blog/day_261__Windows_first_stage_complete.mdwn
 create mode 100644 doc/design/assistant/blog/day_262__DOS_path_separators.mdwn
 create mode 100644 doc/design/assistant/blog/day_262__DOS_path_separators/comment_1_45ecae90b22e31202c21083980d6b567._comment
 create mode 100644 doc/design/assistant/blog/day_263_catching_up.mdwn
 create mode 100644 doc/design/assistant/blog/day_263_catching_up/comment_1_9023da0573dfc81644d68128adb331a7._comment
 create mode 100644 doc/design/assistant/blog/day_264__Windows_second_stage_complete.mdwn
 create mode 100644 doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_1_42a7502d6ece75520eb59a76fdb1e2f0._comment
 create mode 100644 doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_2_f2b11322ac87e2a36cddc035b2c3c1ea._comment
 create mode 100644 doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_3_ea6ee05acb946fc7e8d95e62647cfa2a._comment
 create mode 100644 doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_4_9ce106baf28b7f75f7f6febd7bfcea70._comment
 create mode 100644 doc/design/assistant/blog/day_265__correctness.mdwn
 create mode 100644 doc/design/assistant/blog/day_265__correctness/comment_1_e8959a6df87eb92310947e66c7471e97._comment
 create mode 100644 doc/design/assistant/blog/day_265__correctness/comment_2_0cb953fcc085eedb34e65c227309ede7._comment
 create mode 100644 doc/design/assistant/blog/day_265__correctness/comment_3_df57628a8969af2995732e7ea2a0fae3._comment
 create mode 100644 doc/design/assistant/blog/day_266__release_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_266__release_day/comment_1_92c8d1d9216b46b07dfe69bbc77a923e._comment
 create mode 100644 doc/design/assistant/blog/day_267__windows_autobuilder.mdwn
 create mode 100644 doc/design/assistant/blog/day_267__windows_autobuilder/comment_1_978b584d86395f2f621b0e1f7c5e70d7._comment
 create mode 100644 doc/design/assistant/blog/day_267__windows_autobuilder/comment_2_8f978d2811c8fbf11e3d12f245bdb52b._comment
 create mode 100644 doc/design/assistant/blog/day_268__core_monad_change.mdwn
 create mode 100644 doc/design/assistant/blog/day_269__bugfixes.mdwn
 create mode 100644 doc/design/assistant/blog/day_26__dying_drives.mdwn
 create mode 100644 doc/design/assistant/blog/day_270__release_and_xmpp.mdwn
 create mode 100644 doc/design/assistant/blog/day_271__more_xmpp.mdwn
 create mode 100644 doc/design/assistant/blog/day_272__fuzz_tester.mdwn
 create mode 100644 doc/design/assistant/blog/day_273-274__fun.mdwn
 create mode 100644 doc/design/assistant/blog/day_275__working_hard_or.mdwn
 create mode 100644 doc/design/assistant/blog/day_276__fuzzing_continues.mdwn
 create mode 100644 doc/design/assistant/blog/day_276__fuzzing_continues/comment_1_f5dd0658511a1063c2eb025b0fe98426._comment
 create mode 100644 doc/design/assistant/blog/day_276__fuzzing_continues/comment_2_a56c4c26a9e7bb8cfe3f598dbeed0813._comment
 create mode 100644 doc/design/assistant/blog/day_277__private_static_protected_void.mdwn
 create mode 100644 doc/design/assistant/blog/day_278__winding_down.mdwn
 create mode 100644 doc/design/assistant/blog/day_279__final_release_prep.mdwn
 create mode 100644 doc/design/assistant/blog/day_27__robust_transfers.mdwn
 create mode 100644 doc/design/assistant/blog/day_28-35__threaded_runtime_tarpit.mdwn
 create mode 100644 doc/design/assistant/blog/day_280__yesod.mdwn
 create mode 100644 doc/design/assistant/blog/day_280__yesod/comment_1_a42213a8cef71f2b54db18606028136d._comment
 create mode 100644 doc/design/assistant/blog/day_281__back.mdwn
 create mode 100644 doc/design/assistant/blog/day_281__back/comment_1_128809c5a2a9f5cc345a10fdbf55be01._comment
 create mode 100644 doc/design/assistant/blog/day_281__back/comment_2_6d0bbdf6ebaff9da399804570f0e606d._comment
 create mode 100644 doc/design/assistant/blog/day_282-283__caught_up.mdwn
 create mode 100644 doc/design/assistant/blog/day_284__porting.mdwn
 create mode 100644 doc/design/assistant/blog/day_285__fixed_the_archive_directory_loop.mdwn
 create mode 100644 doc/design/assistant/blog/day_285__fixed_the_archive_directory_loop/comment_1_1065e756dc6d66aefd214eb8ac5ebe1d._comment
 create mode 100644 doc/design/assistant/blog/day_286__Windows_test_suite.mdwn
 create mode 100644 doc/design/assistant/blog/day_287__niceness.mdwn
 create mode 100644 doc/design/assistant/blog/day_288__success_stories.mdwn
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_10_9ddf57b8ae0241268bb33bec1b169e4c._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_11_50b8a597bd8677608f2ef176443f23f3._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_12_f2df427cf3608377e9a52d8bdeadb26f._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_13_8762efed97f21eeba8f0a7be45bd924a._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_14_55e1bb15c3a93d582d110f8173ceefc2._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_15_5749aef8b585b293385b20b75c40f9d8._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_16_911c6d2764906cad7d6324835441ed34._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_17_eb6aa8af5aa70877255a11d132d51aba._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_18_9a57de4cea407a73b2d023d85afdccc6._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_19_1767c86067bee35941004282b96b8e95._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_1_22b28ca3d4d3283ad8c21ae052fb9752._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_20_1d47f3e1b9f0081649cedae4288bac83._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_21_31d3f58cad83cb1ecc4821a15ca258d8._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_22_b512bd2bf29dfaab6b36bf204518fdb6._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_2_343333356de20e170edb8020faa7400d._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_3_4e4034bec789543b562ac263df3e21dd._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_4_0c52794c77a9b7afc5112f5edf9cb793._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_5_7ca419aa3a187857b19268572d5df297._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_6_3edd56b3b04f19faba8d75cca285a662._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_7_146331ae2de25a6dc3595dffab9514de._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_8_72be9307e75eb120451f3d6ab7c8165e._comment
 create mode 100644 doc/design/assistant/blog/day_288__success_stories/comment_9_c27eb0a4181e85a3eed41130402350bf._comment
 create mode 100644 doc/design/assistant/blog/day_289__back_in_the_swing.mdwn
 create mode 100644 doc/design/assistant/blog/day_290__https_release.mdwn
 create mode 100644 doc/design/assistant/blog/day_291__--all.mdwn
 create mode 100644 doc/design/assistant/blog/day_291__--all/comment_1_eaa9fef19a035bef9c439e87d47c834b._comment
 create mode 100644 doc/design/assistant/blog/day_291__--all/comment_2_90bbc26bf92048de7cbaf5fb719c9593._comment
 create mode 100644 doc/design/assistant/blog/day_291__--all/comment_3_75006e9909425dcbf86415a9f7c90372._comment
 create mode 100644 doc/design/assistant/blog/day_291__--all/comment_4_5440449bbc5a353f7430f72e19c35e92._comment
 create mode 100644 doc/design/assistant/blog/day_292__bugfixes.mdwn
 create mode 100644 doc/design/assistant/blog/day_292__bugfixes/comment_1_bbac3878d80f7540d229183c56664784._comment
 create mode 100644 doc/design/assistant/blog/day_292__bugfixes/comment_2_8c9e5291ceb257f3a938af0ad967c5d7._comment
 create mode 100644 doc/design/assistant/blog/day_292__bugfixes/comment_3_02f875e8edd30f47939249f16d92712b._comment
 create mode 100644 doc/design/assistant/blog/day_293__gpg_builds.mdwn
 create mode 100644 doc/design/assistant/blog/day_293__gpg_builds/comment_1_4f152de8ea5aca4ec381d439e2a821f7._comment
 create mode 100644 doc/design/assistant/blog/day_293__gpg_builds/comment_2_42f625638638bc875379f6c604d6f673._comment
 create mode 100644 doc/design/assistant/blog/day_294__release_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_295__balls_in_the_air.mdwn
 create mode 100644 doc/design/assistant/blog/day_296__new_crowdfunding_campaign.mdwn
 create mode 100644 doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_1_cccad1a5103c504d21d0f8e69bb39e1b._comment
 create mode 100644 doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_2_4fef7bd9c8e15cd57df365fadb95717f._comment
 create mode 100644 doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_3_0b9258a1f5079e53c60138f06d0c63b1._comment
 create mode 100644 doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_4_46183b97ca904bc06e46569c30db2edc._comment
 create mode 100644 doc/design/assistant/blog/day_297__back_to_work.mdwn
 create mode 100644 doc/design/assistant/blog/day_297__back_to_work/comment_1_e300feb821bfe7b76b2cec4376d16ffa._comment
 create mode 100644 doc/design/assistant/blog/day_298__exceptional.mdwn
 create mode 100644 doc/design/assistant/blog/day_299__bugfixing.mdwn
 create mode 100644 doc/design/assistant/blog/day_2__races.mdwn
 create mode 100644 doc/design/assistant/blog/day_300__new_logo.mdwn
 create mode 100644 doc/design/assistant/blog/day_300__new_logo/comment_1_9fc64e33863b9fce00f6a03417a91e36._comment
 create mode 100644 doc/design/assistant/blog/day_300__new_logo/comment_2_e8aac0298f90004e81492d2c7f85eda0._comment
 create mode 100644 doc/design/assistant/blog/day_300__new_logo/comment_3_6308c767f6e4bf090102191c91520d04._comment
 create mode 100644 doc/design/assistant/blog/day_301__direct_unannex.mdwn
 create mode 100644 doc/design/assistant/blog/day_302_release_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_302_release_day/comment_1_fe6e572ba706e95188463d9f3e004d03._comment
 create mode 100644 doc/design/assistant/blog/day_303__oops.mdwn
 create mode 100644 doc/design/assistant/blog/day_304__dropunused_safety.mdwn
 create mode 100644 doc/design/assistant/blog/day_304__dropunused_safety/comment_1_1bbcf6c74b6437c44ff8604401fb1432._comment
 create mode 100644 doc/design/assistant/blog/day_305__interesting_bugs.mdwn
 create mode 100644 doc/design/assistant/blog/day_306__offtopic.mdwn
 create mode 100644 doc/design/assistant/blog/day_307__buuuugs.mdwn
 create mode 100644 doc/design/assistant/blog/day_308__ssh-agent.mdwn
 create mode 100644 doc/design/assistant/blog/day_308__ssh-agent/comment_1_5f0fc810cf1e1cd9b3ddba3cd19bb19d._comment
 create mode 100644 doc/design/assistant/blog/day_309__filenames.mdwn
 create mode 100644 doc/design/assistant/blog/day_310__release_day.mdwn
 create mode 100644 doc/design/assistant/blog/day_310__release_day/comment_1_1e008583cebd8e373e83729529914db7._comment
 create mode 100644 doc/design/assistant/blog/day_311__Windows_porting.mdwn
 create mode 100644 doc/design/assistant/blog/day_311__Windows_porting/comment_1_8e738f54a72557bee1e19970472b925c._comment
 create mode 100644 doc/design/assistant/blog/day_312__DebConf_midpoint.mdwn
 create mode 100644 doc/design/assistant/blog/day_313__back.mdwn
 create mode 100644 doc/design/assistant/blog/day_313__back/comment_1_fbf3fdf9688c18156753d446facd942d._comment
 create mode 100644 doc/design/assistant/blog/day_314__quvi.mdwn
 create mode 100644 doc/design/assistant/blog/day_314__quvi/comment_1_3fdfb0742cb5422530ddd97b904f2a42._comment
 create mode 100644 doc/design/assistant/blog/day_315__backlog.mdwn
 create mode 100644 doc/design/assistant/blog/day_316__day_off.mdwn
 create mode 100644 doc/design/assistant/blog/day_317__misc.mdwn
 create mode 100644 doc/design/assistant/blog/day_36__minimal_test_case.mdwn
 create mode 100644 doc/design/assistant/blog/day_37__back.mdwn
 create mode 100644 doc/design/assistant/blog/day_39__twice_is_enemy_action.mdwn
 create mode 100644 doc/design/assistant/blog/day_3__more_races.mdwn
 create mode 100644 doc/design/assistant/blog/day_3__more_races/comment_1_d6015338f602b574a3805de5481fc45e._comment
 create mode 100644 doc/design/assistant/blog/day_3__more_races/comment_2_4d6b23fc6442e0ee0303523cb69d0fba._comment
 create mode 100644 doc/design/assistant/blog/day_3__more_races/comment_3_03f5b2344c2a47dea60086f217d60f9b._comment
 create mode 100644 doc/design/assistant/blog/day_3__more_races/comment_4_860e90e989ec022100001c65e353a91e._comment
 create mode 100644 doc/design/assistant/blog/day_40__dbus.mdwn
 create mode 100644 doc/design/assistant/blog/day_40__dbus/comment_1_43ed2a79629868b018ec9f54a32bcacc._comment
 create mode 100644 doc/design/assistant/blog/day_40__dbus/comment_2_6799f2baf6a6ce14b1fa76a8402840c0._comment
 create mode 100644 doc/design/assistant/blog/day_40__dbus/comment_3_fa1d7444bdafcb990cacf2ace7ee6ef1._comment
 create mode 100644 doc/design/assistant/blog/day_40__dbus/comment_4_3399ddad951c1a950281bb6941fc3f6f._comment
 create mode 100644 doc/design/assistant/blog/day_40__dbus/comment_5_40b6b9d741d3081203f0cc94eb8dc3ea._comment
 create mode 100644 doc/design/assistant/blog/day_41__foo.mdwn
 create mode 100644 doc/design/assistant/blog/day_41__foo/comment_1_ace21fa257a4c2fd412b6ff2944a23e8._comment
 create mode 100644 doc/design/assistant/blog/day_42__the_answer.mdwn
 create mode 100644 doc/design/assistant/blog/day_43__simple_scanner.mdwn
 create mode 100644 doc/design/assistant/blog/day_44__webapp_basics.mdwn
 create mode 100644 doc/design/assistant/blog/day_44__webapp_basics/comment_1_d5fb67f373038e9f583cb2e1992bef67._comment
 create mode 100644 doc/design/assistant/blog/day_45__long_polling.mdwn
 create mode 100644 doc/design/assistant/blog/day_45__long_polling/comment_1_994bec0978324e268666073e8ff4f6ae._comment
 create mode 100644 doc/design/assistant/blog/day_45__long_polling/comment_2_dfa164c86290899139491acccddd8b2b._comment
 create mode 100644 doc/design/assistant/blog/day_45__long_polling/comment_3_5526c9dd4fd87da56cb8456083169f55._comment
 create mode 100644 doc/design/assistant/blog/day_45__long_polling/comment_4_91630f5bf162dfd4fbb3920f1318535b._comment
 create mode 100644 doc/design/assistant/blog/day_45__long_polling/comment_5_b3e41ba77f21e93a4e086483793bf5ce._comment
 create mode 100644 doc/design/assistant/blog/day_45__long_polling/full.png
 create mode 100644 doc/design/assistant/blog/day_45__long_polling/phone.png
 create mode 100644 doc/design/assistant/blog/day_46__notification_pools.mdwn
 create mode 100644 doc/design/assistant/blog/day_47__alert_messages.mdwn
 create mode 100644 doc/design/assistant/blog/day_48__intro.mdwn
 create mode 100644 doc/design/assistant/blog/day_49__first_run_experience.mdwn
 create mode 100644 doc/design/assistant/blog/day_49__first_run_experience/comment_1_e146cf06c8dd6303dd6a991f152a73fe._comment
 create mode 100644 doc/design/assistant/blog/day_49__first_run_experience/comment_2_5d6adcf6782c02283bef6189582ee467._comment
 create mode 100644 doc/design/assistant/blog/day_49__first_run_experience/comment_3_7ac2e34c2a7bc9b57488ca0c91307d32._comment
 create mode 100644 doc/design/assistant/blog/day_49__first_run_experience/comment_4_549b07bb02c07a5b1b95445b01758db2._comment
 create mode 100644 doc/design/assistant/blog/day_4__speed.mdwn
 create mode 100644 doc/design/assistant/blog/day_4__speed/comment_1_bf3c9c33cc0dea5eaeb6f2af110b924b._comment
 create mode 100644 doc/design/assistant/blog/day_4__speed/comment_2_33aba4c9abaa3e6a05a2c87ab7df9d0e._comment
 create mode 100644 doc/design/assistant/blog/day_50__directory_name.mdwn
 create mode 100644 doc/design/assistant/blog/day_50__directory_name/comment_1_782cec95a8558a05b2b38a2d2302214d._comment
 create mode 100644 doc/design/assistant/blog/day_50__directory_name/comment_2_2b8ceb0a26f25e8ed2711bcbe7225a58._comment
 create mode 100644 doc/design/assistant/blog/day_51__desktop.mdwn
 create mode 100644 doc/design/assistant/blog/day_52__file_browser.mdwn
 create mode 100644 doc/design/assistant/blog/day_52__file_browser/comment_1_cd000c2d56b60cc1f17b221322a32aa7._comment
 create mode 100644 doc/design/assistant/blog/day_52__file_browser/comment_2_21d1da67cf9105a545583ba2302c10fb._comment
 create mode 100644 doc/design/assistant/blog/day_54__adding_removable_drives.mdwn
 create mode 100644 doc/design/assistant/blog/day_54__adding_removable_drives/comment_1_5de4f220a3534f55b1f2208d1d812d63._comment
 create mode 100644 doc/design/assistant/blog/day_54__adding_removable_drives/comment_2_8dae1ed0a70acf9628b88692dc32ac5f._comment
 create mode 100644 doc/design/assistant/blog/day_55__alerts.mdwn
 create mode 100644 doc/design/assistant/blog/day_55__alerts/comment_1_6319045500a8a5e049304fdec5ff4cf4._comment
 create mode 100644 doc/design/assistant/blog/day_56__transfer_control.mdwn
 create mode 100644 doc/design/assistant/blog/day_57__afk.mdwn
 create mode 100644 doc/design/assistant/blog/day_57__afk/comment_1_70e1c9f925f040c1700d3e26bab373d5._comment
 create mode 100644 doc/design/assistant/blog/day_57__afk/comment_2_c70d3faccfcebf47deb25e270498cb56._comment
 create mode 100644 doc/design/assistant/blog/day_57__afk/comment_3_89020ebc6d31485339bdea41a872df3c._comment
 create mode 100644 doc/design/assistant/blog/day_57__afk/comment_4_8b1f65f141ffd9813e7f5a3380f7f520._comment
 create mode 100644 doc/design/assistant/blog/day_58__more_transfer_control.mdwn
 create mode 100644 doc/design/assistant/blog/day_59__dinner.mdwn
 create mode 100644 doc/design/assistant/blog/day_59__dinner/comment_1_0c1e2d69496473e7e4a2956a2814f5dd._comment
 create mode 100644 doc/design/assistant/blog/day_5__committing.mdwn
 create mode 100644 doc/design/assistant/blog/day_60__taking_stock.mdwn
 create mode 100644 doc/design/assistant/blog/day_60__taking_stock/comment_1_6722f81ee084f1ea9e8fe47f34576397._comment
 create mode 100644 doc/design/assistant/blog/day_61__network_connection_detection.mdwn
 create mode 100644 doc/design/assistant/blog/day_61__network_connection_detection/comment_1_09b58f41a8d48f218619711ee19511ac._comment
 create mode 100644 doc/design/assistant/blog/day_62__smarter_syncing.mdwn
 create mode 100644 doc/design/assistant/blog/day_63__transfer_retries.mdwn
 create mode 100644 doc/design/assistant/blog/day_63__transfer_retries/comment_1_990d4eb6066c4e2b9ddb3cabef32e4b9._comment
 create mode 100644 doc/design/assistant/blog/day_64__syncing_robustly.mdwn
 create mode 100644 doc/design/assistant/blog/day_65__transfer_polish.mdwn
 create mode 100644 doc/design/assistant/blog/day_66__the_merge.mdwn
 create mode 100644 doc/design/assistant/blog/day_66__the_merge/comment_10_eeccf4e73cc321542a1fe4780805a81e._comment
 create mode 100644 doc/design/assistant/blog/day_66__the_merge/comment_1_a34e89316d1662826848f31061c4e46b._comment
 create mode 100644 doc/design/assistant/blog/day_66__the_merge/comment_2_09e244d23d05052fa2b11a7181888366._comment
 create mode 100644 doc/design/assistant/blog/day_66__the_merge/comment_3_3961a03e167903959b96b054835613f6._comment
 create mode 100644 doc/design/assistant/blog/day_66__the_merge/comment_4_12a57af9f580918818b4a9f68396d5c4._comment
 create mode 100644 doc/design/assistant/blog/day_66__the_merge/comment_5_8ce638960012367c888e018a5f05db19._comment
 create mode 100644 doc/design/assistant/blog/day_66__the_merge/comment_6_f461b856b940e6914bcd2b681cf9505f._comment
 create mode 100644 doc/design/assistant/blog/day_66__the_merge/comment_7_6e73aca1fc1747d0e742e054b88b5d78._comment
 create mode 100644 doc/design/assistant/blog/day_66__the_merge/comment_8_d85f1ce23ae16d5a8eb88d2c3999acb7._comment
 create mode 100644 doc/design/assistant/blog/day_66__the_merge/comment_9_c06dab4d78122c85beeaf300ffc3e376._comment
 create mode 100644 doc/design/assistant/blog/day_67__progress_bars.mdwn
 create mode 100644 doc/design/assistant/blog/day_68__transfers.mdwn
 create mode 100644 doc/design/assistant/blog/day_68__transfers/comment_1_5282960c0b553fbc0f411345b9745324._comment
 create mode 100644 doc/design/assistant/blog/day_69__build_fixes.mdwn
 create mode 100644 doc/design/assistant/blog/day_6__polish.mdwn
 create mode 100644 doc/design/assistant/blog/day_70__adding_ssh_remotes.mdwn
 create mode 100644 doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_10_2fac85357ac8feccff82beabd3791439._comment
 create mode 100644 doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_11_e9e496005fd1bf5a10c9e286b83e51fa._comment
 create mode 100644 doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_1_913e6ae7c8f7db90b9767ec35fc84205._comment
 create mode 100644 doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_2_634ca3c236e2062289e7df5f0d77a3c5._comment
 create mode 100644 doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_3_e365bbcbb7f66ce2b35fcd5b969ab315._comment
 create mode 100644 doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_4_b15499722a655489f9ea60ff9d4c47c6._comment
 create mode 100644 doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_5_8ea48276f060e75d9f40617d2a1ccd08._comment
 create mode 100644 doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_6_9b8bf7e9fa715977fbeb98087deefd1a._comment
 create mode 100644 doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_7_42e09eacdc10c7cf579bfc6470b5117c._comment
 create mode 100644 doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_8_6c02f31063b3d399d1b4f823bd6543ce._comment
 create mode 100644 doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_9_dd0447cb3b39d3a8c1a7cc00f17d8bc2._comment
 create mode 100644 doc/design/assistant/blog/day_71__ssh_probing.mdwn
 create mode 100644 doc/design/assistant/blog/day_71__ssh_probing/comment_1_56a0c29f7454cfca5cc30b2849e6e942._comment
 create mode 100644 doc/design/assistant/blog/day_71__ssh_probing/comment_2_f3bd3e366c92c833c7e217da125481b8._comment
 create mode 100644 doc/design/assistant/blog/day_72__remote_ssh_server_configurator_finished.mdwn
 create mode 100644 doc/design/assistant/blog/day_73__rsync.net_configurator.mdwn
 create mode 100644 doc/design/assistant/blog/day_74__bits_and_peices.mdwn
 create mode 100644 doc/design/assistant/blog/day_75__zeromq_and_pairing.mdwn
 create mode 100644 doc/design/assistant/blog/day_76__pairing.mdwn
 create mode 100644 doc/design/assistant/blog/day_76__pairing/comment_1_09665f269343422cd18051fad1a8c19e._comment
 create mode 100644 doc/design/assistant/blog/day_76__pairing/comment_2_8e1b2233579bc26bfd758bbf6b3bdc07._comment
 create mode 100644 doc/design/assistant/blog/day_76__pairing/comment_3_a8b6a8432da20c468c633da8e7cbc2f3._comment
 create mode 100644 doc/design/assistant/blog/day_76__pairing/comment_4_36a428a2e1803f4391b821d1892f0cd7._comment
 create mode 100644 doc/design/assistant/blog/day_76__pairing/comment_5_11f332fe2050d8c1416e71f9e85ba280._comment
 create mode 100644 doc/design/assistant/blog/day_76__pairing/comment_6_973aeb656b78eca97474ea1a3f5b57b7._comment
 create mode 100644 doc/design/assistant/blog/day_76__pairing/comment_7_03d2b3343f34377a4d6171e06b7609f6._comment
 create mode 100644 doc/design/assistant/blog/day_77_alert_buttons.mdwn
 create mode 100644 doc/design/assistant/blog/day_78__pairing_continued.mdwn
 create mode 100644 doc/design/assistant/blog/day_79__pairing_finished.mdwn
 create mode 100644 doc/design/assistant/blog/day_7__bugfixes.mdwn
 create mode 100644 doc/design/assistant/blog/day_7__bugfixes/profile.png
 create mode 100644 doc/design/assistant/blog/day_7__bugfixes/profile2.png
 create mode 100644 doc/design/assistant/blog/day_80__default_backend.mdwn
 create mode 100644 doc/design/assistant/blog/day_81__enabling_pre-existing_special_remotes.mdwn
 create mode 100644 doc/design/assistant/blog/day_82__git-annex_branch_work.mdwn
 create mode 100644 doc/design/assistant/blog/day_83__3-way.mdwn
 create mode 100644 doc/design/assistant/blog/day_84__deferred_downloads.mdwn
 create mode 100644 doc/design/assistant/blog/day_85__more_foundation_work.mdwn
 create mode 100644 doc/design/assistant/blog/day_86__towards_the_beta.mdwn
 create mode 100644 doc/design/assistant/blog/day_87__more_progress_progress.mdwn
 create mode 100644 doc/design/assistant/blog/day_88__progressbars_still_progressing.mdwn
 create mode 100644 doc/design/assistant/blog/day_89__final_polish.mdwn
 create mode 100644 doc/design/assistant/blog/day_8__speed.mdwn
 create mode 100644 doc/design/assistant/blog/day_8__speed/comment_1_a3dba537b276d5737abc8cb93f1965f4._comment
 create mode 100644 doc/design/assistant/blog/day_90__beta.mdwn
 create mode 100644 doc/design/assistant/blog/day_90__beta/comment_1_5f2a3b18ad7558abe04f51534a29ff13._comment
 create mode 100644 doc/design/assistant/blog/day_90__beta/comment_2_961c4eba97f4eac75174244d6b2b00c0._comment
 create mode 100644 doc/design/assistant/blog/day_90__beta/comment_3_c76675a4633cbbe347ed42c222918d38._comment
 create mode 100644 doc/design/assistant/blog/day_90__beta/comment_4_f0b8f77cb691e747fe35bcf2f51b5baa._comment
 create mode 100644 doc/design/assistant/blog/day_90__beta/comment_5_99fbc9feac62e66a12b0d357cf86ccc1._comment
 create mode 100644 doc/design/assistant/blog/day_91__break.mdwn
 create mode 100644 doc/design/assistant/blog/day_92__S3.mdwn
 create mode 100644 doc/design/assistant/blog/day_92__S3/comment_1_eda656247d11cea7fbed2e33137a39e5._comment
 create mode 100644 doc/design/assistant/blog/day_92__S3/comment_2_8249d2d9521e44c674da3fda74be077a._comment
 create mode 100644 doc/design/assistant/blog/day_93__OSX_standalone_app.mdwn
 create mode 100644 doc/design/assistant/blog/day_93__easy_install.mdwn
 create mode 100644 doc/design/assistant/blog/day_93__easy_install/comment_1_d4f7de723c98577ef28d89ee6b87fd13._comment
 create mode 100644 doc/design/assistant/blog/day_93__easy_install/comment_2_6337b341c1cfb2132b59704394e57b36._comment
 create mode 100644 doc/design/assistant/blog/day_95__repository_groups.mdwn
 create mode 100644 doc/design/assistant/blog/day_96__revisiting_file_adds.mdwn
 create mode 100644 doc/design/assistant/blog/day_96__revisiting_file_adds/comment_1_da3ca47041168b6c82aeb2c18acc5017._comment
 create mode 100644 doc/design/assistant/blog/day_97__stuffing.mdwn
 create mode 100644 doc/design/assistant/blog/day_98__preferred_content.mdwn
 create mode 100644 doc/design/assistant/blog/day_98__preferred_content/comment_1_2136618e3515d0ac6369a41f1934ec2a._comment
 create mode 100644 doc/design/assistant/blog/day_98__preferred_content/comment_2_5f6db00e69628bf2f72b0e6f2981a49b._comment
 create mode 100644 doc/design/assistant/blog/day_99_shotgun.mdwn
 create mode 100644 doc/design/assistant/blog/day_99_shotgun/comment_1_12bb8f54bb13ea20ac4187a2301d77ca._comment
 create mode 100644 doc/design/assistant/blog/day_9__correctness.mdwn
 create mode 100644 doc/design/assistant/blog/day_9__correctness/comment_1_564a39cb976767e2c0a9c74fabe10be4._comment
 create mode 100644 doc/design/assistant/blog/day_9__correctness/comment_2_77924e9d50b40f05e792e427a25849a6._comment
 create mode 100644 doc/design/assistant/blog/day_9__correctness/comment_3_92bd86cd06d579e23800af2e5c66a291._comment
 create mode 100644 doc/design/assistant/blog/day_9__correctness/comment_4_0d12b51ccdfc2a94d3e59a5628521e0a._comment
 create mode 100644 doc/design/assistant/blog/day_9__correctness/comment_5_208f9dd3e1d92555b05c29159538a901._comment
 create mode 100644 doc/design/assistant/blog/day_9__correctness/comment_6_90cc6b60718896fb175919417600fdf9._comment
 create mode 100644 doc/design/assistant/chunks.mdwn
 create mode 100644 doc/design/assistant/chunks/comment_1_a3b24ff308664e89c97d23034e4ffe2f._comment
 create mode 100644 doc/design/assistant/chunks/comment_2_ec5c7a80d1e17db19d178e821f6534e5._comment
 create mode 100644 doc/design/assistant/cloud.mdwn
 create mode 100644 doc/design/assistant/cloud/comment_1_4997778abc171999499487b71b31c9ba._comment
 create mode 100644 doc/design/assistant/cloud/comment_2_08da8bc74a4845e354dca99184cffd70._comment
 create mode 100644 doc/design/assistant/cloud/comment_3_faafd1266301997b1822d215ec8e8d8c._comment
 create mode 100644 doc/design/assistant/cloud/comment_4_3eb557d5439831f6e0032944d12c02cf._comment
 create mode 100644 doc/design/assistant/comment_10_f2233fad55c20686cf299bf6788f1f23._comment
 create mode 100644 doc/design/assistant/comment_11_a38f0f21c2346e65b786d791b6829f9b._comment
 create mode 100644 doc/design/assistant/comment_12_5e991177d6577384f39a36ae02f5f574._comment
 create mode 100644 doc/design/assistant/comment_13_f8625c6f43b58847840df338a73b7972._comment
 create mode 100644 doc/design/assistant/comment_14_c37ef5931b0f5c1f808083e0d636a208._comment
 create mode 100644 doc/design/assistant/comment_15_68c98a27083567f20c2e6bc2a760991b._comment
 create mode 100644 doc/design/assistant/comment_16_8e6788c817c60371d2a2f158e1a65f87._comment
 create mode 100644 doc/design/assistant/comment_17_97bdfacac5ac492281c9454ee4c0228e._comment
 create mode 100644 doc/design/assistant/comment_18_53137b2df4913496c0afb2d895aa4ee2._comment
 create mode 100644 doc/design/assistant/comment_19_ff1b0ba57e22ed757ec3fc5400b5e43e._comment
 create mode 100644 doc/design/assistant/comment_1_a48fcfbf97f0a373ea375cd8f07f0fc8._comment
 create mode 100644 doc/design/assistant/comment_20_099da245e3276fa84f5e14312d186621._comment
 create mode 100644 doc/design/assistant/comment_2_6d3552414fdcc2ed3244567e6c67989d._comment
 create mode 100644 doc/design/assistant/comment_3_05223be50c889b2ed6bc4abf74116450._comment
 create mode 100644 doc/design/assistant/comment_4_fbbd93b55803ae21e6ba4b6568c2fafd._comment
 create mode 100644 doc/design/assistant/comment_5_f4e9af3fed6c27e8ff39badb9794064d._comment
 create mode 100644 doc/design/assistant/comment_6_c7ad07cade1f44f9a8b61f92225bb9c5._comment
 create mode 100644 doc/design/assistant/comment_7_609d38e993267195a80fecd84c93d1e2._comment
 create mode 100644 doc/design/assistant/comment_8_22b818e1a2a825efb78139271a14f944._comment
 create mode 100644 doc/design/assistant/comment_9_d052e2142da8b4838fb1edf791ea23ae._comment
 create mode 100644 doc/design/assistant/configurators.mdwn
 create mode 100644 doc/design/assistant/deltas.mdwn
 create mode 100644 doc/design/assistant/deltas/comment_1_bdb477af913c9782c0e8509e6b294b6e._comment
 create mode 100644 doc/design/assistant/deltas/comment_2_71889d15ba20ebb0fe13080c68162a5b._comment
 create mode 100644 doc/design/assistant/deltas/comment_3_c60bbe9b280855a583c7c3e48e803760._comment
 create mode 100644 doc/design/assistant/deltas/comment_4_d1728f96202b7113b0671b90ed16473d._comment
 create mode 100644 doc/design/assistant/desymlink.mdwn
 create mode 100644 doc/design/assistant/desymlink/comment_1_f1bfe250b7f872359f7075998b6e42e3._comment
 create mode 100644 doc/design/assistant/desymlink/comment_2_5e876edfe9853645f761b5ed9b5021aa._comment
 create mode 100644 doc/design/assistant/desymlink/comment_3_538561d74371e53c2f8df7f5ebdf58a8._comment
 create mode 100644 doc/design/assistant/desymlink/comment_4_586ecaa800e6c162377c937da5e65440._comment
 create mode 100644 doc/design/assistant/desymlink/comment_5_8fc703de67814cf2aec2a908852298a4._comment
 create mode 100644 doc/design/assistant/desymlink/comment_6_1b473ad89494afb82250af4b6df5f5c9._comment
 create mode 100644 doc/design/assistant/disaster_recovery.mdwn
 create mode 100644 doc/design/assistant/disaster_recovery/comment_1_955dc807196863da23aa8dbd15e04364._comment
 create mode 100644 doc/design/assistant/encrypted_git_remotes.mdwn
 create mode 100644 doc/design/assistant/gpgkeys.mdwn
 create mode 100644 doc/design/assistant/gpgkeys/comment_1_a14427f88c9fd8e25ad8708146bb4bff._comment
 create mode 100644 doc/design/assistant/inotify.mdwn
 create mode 100644 doc/design/assistant/inotify/comment_1_3d3ff74447452d65c10ccc3dbfc323cd._comment
 create mode 100644 doc/design/assistant/inotify/comment_2_a3c0fa6d97397c508b4b8aafdcee8f6f._comment
 create mode 100644 doc/design/assistant/inotify/comment_3_b346e870c1cd80e4b0a313c3a9fed6b3._comment
 create mode 100644 doc/design/assistant/inotify/comment_4_32be58b4c3b17a4ea539690d2fb45159._comment
 create mode 100644 doc/design/assistant/inotify/comment_5_0cdd3046d90ad2012025d846ece0731e._comment
 create mode 100644 doc/design/assistant/inotify/comment_6_e197d5d0d853572ec1f2e5985762e60d._comment
 create mode 100644 doc/design/assistant/inotify/comment_7_00809aaad6b68f189a9cc42af810a0a6._comment
 create mode 100644 doc/design/assistant/leftovers.mdwn
 create mode 100644 doc/design/assistant/leftovers/comment_1_b20c88bb3c583a32023c1f6b6dc9486d._comment
 create mode 100644 doc/design/assistant/more_cloud_providers.mdwn
 create mode 100644 doc/design/assistant/pairing.mdwn
 create mode 100644 doc/design/assistant/partial_content.mdwn
 create mode 100644 doc/design/assistant/partial_content/comment_1_58c4faa321a5bb71adf9fdee079849f4._comment
 create mode 100644 doc/design/assistant/partial_content/comment_2_588009d2140b7d259cdf191dca539e14._comment
 create mode 100644 doc/design/assistant/polls.mdwn
 create mode 100644 doc/design/assistant/polls/2013_user_survey.mdwn
 create mode 100644 doc/design/assistant/polls/Android.mdwn
 create mode 100644 doc/design/assistant/polls/Android/comment_1_fa6c409833f28c67da105d25f4a440e0._comment
 create mode 100644 doc/design/assistant/polls/Android_default_directory.mdwn
 create mode 100644 doc/design/assistant/polls/Android_default_directory/comment_1_d39655091ac3ed51a9d4325d86b23ad7._comment
 create mode 100644 doc/design/assistant/polls/Android_default_directory/comment_2_2f1eaae95075db26488517720afd1c63._comment
 create mode 100644 doc/design/assistant/polls/Android_default_directory/comment_3_b484012f60789be73d7d5b338cff6203._comment
 create mode 100644 doc/design/assistant/polls/goals_for_April.mdwn
 create mode 100644 doc/design/assistant/polls/goals_for_April/comment_1_9f81fa96db5970a4be0828c74a6d2d55._comment
 create mode 100644 doc/design/assistant/polls/goals_for_April/comment_2_d8956d220ccacff3d2f6cbeb15718459._comment
 create mode 100644 doc/design/assistant/polls/goals_for_April/comment_3_aadad6dfd56d068d2e377606910c006f._comment
 create mode 100644 doc/design/assistant/polls/prioritizing_special_remotes.mdwn
 create mode 100644 doc/design/assistant/polls/prioritizing_special_remotes/comment_1_dd9280df27848a7ff132f5809dab0a79._comment
 create mode 100644 doc/design/assistant/polls/prioritizing_special_remotes/comment_2_370e0b9c43486ee96c825f9155eebde4._comment
 create mode 100644 doc/design/assistant/polls/prioritizing_special_remotes/comment_3_883a003b9c552b89f191135c582f99aa._comment
 create mode 100644 doc/design/assistant/polls/prioritizing_special_remotes/comment_4_746006c3fffc7f917c4526fd688051f7._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant.mdwn
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_10_10a4839a05be39ced54ffbe880a588bb._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_11_ac91d866f11c66dd8c86e2cd1a368c85._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_12_e244c1bf334b1cc9ad0cc760bf8fe5de._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_13_1a0faf4bdc78741937e8a2f5cb5bbec6._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_14_8d8a11dbfae7a7bc574bdf37f87e0684._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_15_c437adeaccf0b3d134e0f81c64e25b9f._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_16_6e3fce3a32ab346dc3d0fd4b69967536._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_17_1b7233d88593d0d99b26ea3e7af20d9c._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_18_a23d5a0e2718b8e486f036fe8a413b36._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_19_f4c84a9d701d52cf2f2e45f3d764a90c._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_1_00a0de8190d946caaeeca3b44646146f._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_20_199c9807499470771af6cbca6d034cfa._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_21_9185b0e05b1b1997533694da1de83073._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_2_35f6f121e54260cb960211a6e2e51e8e._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_3_acbe4f63b5d552ac5ae5a12c6f42dc18._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_4_0d988280865caae498a3b693b6342e37._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_5_ac8fe3768c30dd7999c183500f8567bb._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_6_36832de705a2bebf8dc6e65dcd661731._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_7_3618067e473577a112e36970ca71e0ab._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_8_07a13b6f000ddc0ac4472b863d8b50bd._comment
 create mode 100644 doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_9_e15eb407d988fda363296c8b566cc8fb._comment
 create mode 100644 doc/design/assistant/progressbars.mdwn
 create mode 100644 doc/design/assistant/progressbars/comment_1_3ea263b1f334e8e38e14f00a96202988._comment
 create mode 100644 doc/design/assistant/rate_limiting.mdwn
 create mode 100644 doc/design/assistant/rate_limiting/comment_1_bd0fd62297ff1f87884b41c11fc4320c._comment
 create mode 100644 doc/design/assistant/screenshot/firstrun.png
 create mode 100644 doc/design/assistant/screenshot/intro.png
 create mode 100644 doc/design/assistant/sshpassword.mdwn
 create mode 100644 doc/design/assistant/sshpassword/comment_1_24399abe0a0c1de271490ee15e064760._comment
 create mode 100644 doc/design/assistant/sshpassword/comment_2_36a811bca209c7ac8a44d64bf8bc5bf3._comment
 create mode 100644 doc/design/assistant/syncing.mdwn
 create mode 100644 doc/design/assistant/syncing/comment_1_c70156174ff19b503978d623bd2df36f._comment
 create mode 100644 doc/design/assistant/syncing/comment_2_eb992b5b2c7a5ce23443e2a6007e5ff9._comment
 create mode 100644 doc/design/assistant/syncing/comment_3_e1b5e8a24556de16d1cacd27ee0c1bd1._comment
 create mode 100644 doc/design/assistant/syncing/efficiency.mdwn
 create mode 100644 doc/design/assistant/telehash.mdwn
 create mode 100644 doc/design/assistant/thanks/comment_1_8b08b5c30e5aea3fc4599f856fd25df5._comment
 create mode 100644 doc/design/assistant/todo.mdwn
 create mode 100644 doc/design/assistant/transfer_control.mdwn
 create mode 100644 doc/design/assistant/transfer_control/comment_1_d5adaef4712913dc0263d4ebafb79320._comment
 create mode 100644 doc/design/assistant/transfer_control/comment_2_3b51474fefa6c0d19055046e06af196d._comment
 create mode 100644 doc/design/assistant/transfer_control/comment_3_44a1a6d2db9097de9ae68ea1ff1b08a2._comment
 create mode 100644 doc/design/assistant/upgrading.mdwn
 create mode 100644 doc/design/assistant/webapp.mdwn
 create mode 100644 doc/design/assistant/webapp/comment_1_bab6f6fa720273c0f9700a3765150189._comment
 create mode 100644 doc/design/assistant/webapp/comment_2_3cf0cf460c7869d0cc22940fcc84aec4._comment
 create mode 100644 doc/design/assistant/webapp/comment_3_428e153135f7a64215730719207d82c4._comment
 create mode 100644 doc/design/assistant/webapp/comment_4_f4068a7abbb77ba6a3297cbcf1e503e9._comment
 create mode 100644 doc/design/assistant/webapp/comment_5_2bdb436f35c659316193b89ee6e52fcb._comment
 create mode 100644 doc/design/assistant/windows.mdwn
 create mode 100644 doc/design/assistant/windows/comment_1_f4b829318b182e1cec29f13babb6498e._comment
 create mode 100644 doc/design/assistant/xmpp.mdwn
 create mode 100644 doc/design/assistant/xmpp/comment_1_f20650f93d7f0ca39b9ba3ce0380193f._comment
 create mode 100644 doc/design/assistant/xmpp/comment_2_8c22839a8f5912b4a817415c4a359697._comment
 create mode 100644 doc/design/assistant/xmpp/comment_4_773102522f21844cffc841e6cde9229e._comment
 create mode 100644 doc/design/assistant/xmpp_security.mdwn
 create mode 100644 doc/design/assistant/xmpp_security/comment_1_c714e86553c02600249795efb224be8a._comment
 create mode 100644 doc/design/balanced_preferred_content.mdwn
 create mode 100644 doc/design/balanced_preferred_content/comment_1_a7eea522b04ddefbd0b9ff49dfb82d15._comment
 create mode 100644 doc/design/caching_database.mdwn
 create mode 100644 doc/design/encryption.mdwn
 create mode 100644 doc/design/encryption/comment_1_4715ffafb3c4a9915bc33f2b26aaa9c1._comment
 create mode 100644 doc/design/encryption/comment_2_a610b3d056a059899178859a3a821ea5._comment
 create mode 100644 doc/design/encryption/comment_3_cca186a9536cd3f6e86994631b14231c._comment
 create mode 100644 doc/design/encryption/comment_4_8f3ba3e504b058791fc6e6f9c38154cf._comment
 create mode 100644 doc/design/encryption/comment_5_520e60aa53217b5ba428d4c05d897dee._comment
 create mode 100644 doc/design/encryption/comment_6_d677fead0fe0c543f48f07d85f83f592._comment
 create mode 100644 doc/design/encryption/comment_7_c1c38a09b1276e29adc3ba564dc0fe4e._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes.mdwn
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_10_75ba45174d3c4b927113a6908061b742._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_11_0827f5611c8e7e7ffa2633f8c06ae055._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_12_1bb8d57383ca733f3a0069ff30181366._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_13_f857e15124b70ae1abc74669f63a2d68._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_14_41e8ef74c6e62a4321d2046b2571a246._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_15_3fc518cee1a11b28da769c0915d33e3b._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_16_29f598eda413c0d5e17536d8f9438d31._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_17_32a3240206c5ffff71a47dffa6950c48._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_18_fe77370699b7ce0acd547fd1e045e254._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_19_00d28c758509939974e4583e9b1b9e12._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_19_1eda1af40f6ca82a8bacd19afaa749bc._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_1_ea84ee9de604e05b8e02483ba8452186._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_21_062098e1f54b874467793e4487a45a9b._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_2_d414fb575845770e003a3c8ca4a986be._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_3_cb063cdc66df79c40039bce247b7170c._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_4_126ee5332ff88b3993d33d59328d4148._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_5_fcd9890013371dae6ffcd00561b8c625._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_6_3217c2f852e5d9b1e4be2adff995dd24._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_7_43a98b4b9d9eb54720a9c92cd8bb3a30._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_8_7e512ef81c529b0392071b8a6dfe853b._comment
 create mode 100644 doc/design/exporting_trees_to_special_remotes/comment_9_6c588170f0b53c74c3c28ff08ed3509d._comment
 create mode 100644 doc/design/external_backend_protocol.mdwn
 create mode 100644 doc/design/external_backend_protocol/comment_1_7a55199030c3b9f455354139af7dbac0._comment
 create mode 100644 doc/design/external_backend_protocol/comment_2_e6005a7563a65c0fd4615cc3f2c3034b._comment
 create mode 100644 doc/design/external_backend_protocol/comment_3_cd3410e6c1088289f71ed30b34d802f9._comment
 create mode 100644 doc/design/external_backend_protocol/comment_4_5b9814ca55e5fab94725ecdb5b1618f0._comment
 create mode 100644 doc/design/external_backend_protocol/comment_5_75ff466d7eeccd1eda9f8f18f465b296._comment
 create mode 100755 doc/design/external_backend_protocol/git-annex-backend-XFOO
 create mode 100644 doc/design/external_special_remote_protocol.mdwn
 create mode 100644 doc/design/external_special_remote_protocol/async_appendix.mdwn
 create mode 100644 doc/design/external_special_remote_protocol/async_appendix/comment_1_850d3eb7c04088041c96686b88c36662._comment
 create mode 100644 doc/design/external_special_remote_protocol/async_appendix/comment_2_897dbfbd4ed9c0f520bd2d4d0c961745._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_11_8d3c35eb0a2a9c57b10566fcaf56d248._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_12_241e57092d9e5631ac0ec4dd962477a6._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_12_e3029c65d34f78272bc11961ebfd8237._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_13_472748f03ba8dad773da7f35b70cb6e4._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_14_71c3e21a72222250bab933e1c9167fbc._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_15_c77386deddc64b2028d9c3a7393d4df7._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_16_62b137a138c143a8110886cc0bbb677e._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_17_8dc7bbf485c9385a4b506e8b8fa934fe._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_18_a0ed457b1b0d71747b6cf0c45897b5e1._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_19_89d532a5013af24f15a0d003cbfbab25._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_1_5baff75d278394a8818c348fb4f13b8a._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_20_546331742e906a68d760c1bf44be63c4._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_21_a8e8255516dc4741439615fa43b71829._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_22_0387827d94f141be53458807da9c2fc2._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_23_7a5af50f7c482d7c02c53be28ddb6a66._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_24_3340d3c34f2ec197f9010d97da8eb7af._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_25_56f38d934125c28172b6475bdb4de284._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_26_4f8addd76a1e64d05a34910d4719a40c._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_27_9153a5c49710bf57d11338829f66fa78._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_28_74961b12a73a52a700e10a21674e66ee._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_29_c1d97815386453c3e433fca9a44c4667._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_2_70429b7c4f1e4083a9d5a6e2e238056d._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_30_7d045871f9ebbb89e3f9bbfa28e8468f._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_31_907597187020180e7730e27e86f6da5e._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_32_f6b8306cfdcb3792728aa47af0677338._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_33_bee7ff39f3989dfbec292490e47bcaaa._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_34_af6ae46fa9228461573dd7b2f0713ef1._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_35_2f71f6d0caf4fa5ccd26618026714975._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_36_f8081ce200700516efef61ec0ac86f86._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_37_2aef2647d7df69876f107247e039f5a6._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_39_62f6621259587333a83776cf514b2497._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_39_ea321b96df3314a9e2a35cd0f8312972._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_3_c763e44d06d9f50f0d357889b180b819._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_40_a312c0180bce6dbbd03b14b8ba3dcb5f._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_41_7d63261342ea475f696cadb419782dbb._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_42_485588573d8d9f74e64cdf560f65e7fe._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_43_d942d979773d9361fbf3dde28c26a941._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_44_a72db8ed716effc507e7127f9ec95dc4._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_45_a25f00fb081e30f639376b6ad94cdb30._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_46_7ecdba05cb2bfc7d868b81bbd3e3f964._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_47_9d48c85b896f738323dec28c1955ee22._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_48_d378ab8adc6a73a17c39d62978cb9e90._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_49_9045ad13ad2c2f998173a870174eb3ee._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_4_20ff41d82b5f1872698a5b24adcd0c41._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_50_fdd9804134e6fe5e6527f35fc782cb80._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_51_c0eaa8639ad2b21ac917d9033d77a327._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_52_3c8c5a1d388929da4629f14b099d02d1._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_53_a2d1778e6d61f9cb606fb83f0a4a73f4._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_54_0225736488f9c1e7f78a08eea8ca864d._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_5_3ee158e548002badae5bf44dc0442626._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_6_ee2828ce25b83bbabc9d5dde35d1e57b._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_7_edb649d0019a061ef7bf6534a444429d._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_8_1f4c205a5ce6f33ccf2f4d80754e5699._comment
 create mode 100644 doc/design/external_special_remote_protocol/comment_9_15c4cfe064be37cc104dcb6aa049a449._comment
 create mode 100644 doc/design/external_special_remote_protocol/export_and_import_appendix.mdwn
 create mode 100644 doc/design/external_special_remote_protocol/export_and_import_appendix/comment_1_9bcf18e2bbe04bf5321e4fc33cca577c._comment
 create mode 100644 doc/design/external_special_remote_protocol/export_and_import_appendix/comment_2_6bea5a316df43a8306fb1cb19192db3f._comment
 create mode 100644 doc/design/gcrypt.mdwn
 create mode 100644 doc/design/git-remote-daemon.mdwn
 create mode 100644 doc/design/git-remote-daemon/comment_1_bfa8f33a3fdb6e271dfbdd0378b5d364._comment
 create mode 100644 doc/design/iabackup.mdwn
 create mode 100644 doc/design/iabackup/comment_1_d33c0910973bc37ce81bf434017e11fd._comment
 create mode 100644 doc/design/iabackup/comment_2_c0a59549409faa355a461e85a1c3f908._comment
 create mode 100644 doc/design/iabackup/comment_3_560d3f65d543c3af9722ed7e9a11e920._comment
 create mode 100644 doc/design/iabackup/comment_4_465c0966c96a57d189f678d4fa724aa0._comment
 create mode 100644 doc/design/iabackup/comment_5_7e4d1db9c69c63e79ca13db2ad87c384._comment
 create mode 100644 doc/design/importing_trees_from_special_remotes.mdwn
 create mode 100644 doc/design/metadata.mdwn
 create mode 100644 doc/design/metadata/comment_10_9bc2825b18ce29d2c9b2f085b95aa68c._comment
 create mode 100644 doc/design/metadata/comment_11_402d7d3e8e7f2df57eb6685134226642._comment
 create mode 100644 doc/design/metadata/comment_1_22ed80bd8eabaa836e9dfc2432531f04._comment
 create mode 100644 doc/design/metadata/comment_2_03ae28acedbe1fa45c366b30b58fcf48._comment
 create mode 100644 doc/design/metadata/comment_3_ee850df7d3fa4c56194f13a6e3890a30._comment
 create mode 100644 doc/design/metadata/comment_4_c32ade1524487e5fdc6f83b2db39f04c._comment
 create mode 100644 doc/design/metadata/comment_5_0ac3132cd7a84f0e170fbe3a6f235fe7._comment
 create mode 100644 doc/design/metadata/comment_6_fa51ae544b193122334dbae7960ab3d9._comment
 create mode 100644 doc/design/metadata/comment_7_04cd255a516c8520a7bc1a8fad253533._comment
 create mode 100644 doc/design/metadata/comment_8_0a7e55e7626f72f63966fa1e1d2cf100._comment
 create mode 100644 doc/design/metadata/comment_9_f0bb62c885a925e0da5ae8ce3c5e9003._comment
 create mode 100644 doc/design/new_repo_versions.mdwn
 create mode 100644 doc/design/new_repo_versions/comment_1_b7b4819211910556838ec37bc2b6b37b._comment
 create mode 100644 doc/design/new_repo_versions/comment_2_8f35254d2cd5d0c273d5392ddd857c2d._comment
 create mode 100644 doc/design/p2p_protocol.mdwn
 create mode 100644 doc/design/p2p_protocol/comment_1_367bebae5b84408c7592b5fcca993c1e._comment
 create mode 100644 doc/design/p2p_protocol/comment_2_dbd118a01c31d17a4223a32a7baa8e39._comment
 create mode 100644 doc/design/p2p_protocol/comment_4_94fff4c163de15cdad2030ac072b19ae._comment
 create mode 100644 doc/design/p2p_protocol/comment_4_f48e73ea2b6f70597837d09d3c5d3849._comment
 create mode 100644 doc/design/p2p_protocol/comment_5_08b190ff1c6d1e890311edf7cc7bfcd4._comment
 create mode 100644 doc/design/passthrough_proxy.mdwn
 create mode 100644 doc/design/preferred_content.mdwn
 create mode 100644 doc/design/requests_routing.mdwn
 create mode 100644 doc/design/requests_routing/comment_1_421b14a4dd9d6c431e00333057df1627._comment
 create mode 100644 doc/design/requests_routing/comment_2_a409df0566b308bf2b84efd4fb2c8a8f._comment
 create mode 100644 doc/design/requests_routing/comment_3_924e6254bf51a5b19eb7fe635053a16e._comment
 create mode 100644 doc/design/requests_routing/simroutes.hs
 create mode 100644 doc/design/roadmap.mdwn
 create mode 100644 doc/devblog.mdwn
 create mode 100644 doc/devblog/day_-1__drop_dead.mdwn
 create mode 100644 doc/devblog/day_-3__.mdwn
 create mode 100644 doc/devblog/day_-4__forgetting.mdwn
 create mode 100644 doc/devblog/day_-4__forgetting/comment_1_f3cc7a25af4c59fda3924c737a789419._comment
 create mode 100644 doc/devblog/day_-4__forgetting/comment_2_e47476c80af02a2e9cf76c53fdbb8534._comment
 create mode 100644 doc/devblog/day_-4__forgetting/comment_3_b57956a8ce372d620f21ea9a497e8013._comment
 create mode 100644 doc/devblog/day_-4__forgetting/comment_4_812b630df01ac35254e3c4e677554e2b._comment
 create mode 100644 doc/devblog/day_-4__forgetting/comment_5_a9670eca2aff9ad5f04412a8d8b6df6a._comment
 create mode 100644 doc/devblog/day_-4__forgetting/comment_6_4f87e2ab119f3cd81266159f02952188._comment
 create mode 100644 doc/devblog/day_-4__forgetting/comment_7_a865216046aa91a47d0d2b2f0668ea89._comment
 create mode 100644 doc/devblog/day_-4__forgetting/comment_8_3f7045a00905b4287d950b08d5a77a82._comment
 create mode 100644 doc/devblog/day_-4__forgetting/comment_9_d9121a5172f02df63364f19eae87d011._comment
 create mode 100644 doc/devblog/day_100__git-annex_sync_--content.mdwn
 create mode 100644 doc/devblog/day_101__old_mistakes.mdwn
 create mode 100644 doc/devblog/day_101__old_mistakes/comment_1_2c6e991efde3296450189b2821f2ccc3._comment
 create mode 100644 doc/devblog/day_101__old_mistakes/comment_2_524690d69056737dd296e4f7626737d2._comment
 create mode 100644 doc/devblog/day_102__cleanups.mdwn
 create mode 100644 doc/devblog/day_103__unused.mdwn
 create mode 100644 doc/devblog/day_104__unused_II.mdwn
 create mode 100644 doc/devblog/day_104__unused_II/comment_1_a693a56123497a39c30cbd35b8e35bce._comment
 create mode 100644 doc/devblog/day_104__unused_II/comment_2_9833fb9daa50bc838cc46ca2f6c16580._comment
 create mode 100644 doc/devblog/day_104__unused_II/comment_3_873a882ec1ddc3be473473cb224a9040._comment
 create mode 100644 doc/devblog/day_104__unused_II/comment_4_5ef1bb4d69cf7206f7ca0e542abad6bd._comment
 create mode 100644 doc/devblog/day_104__unused_II/comment_5_1964bfce4887c9c0828fd7f54f5b4f6b._comment
 create mode 100644 doc/devblog/day_104__unused_II/comment_6_0ed4023c9c249024fe0454fc5bab3b14._comment
 create mode 100644 doc/devblog/day_105__locking.mdwn
 create mode 100644 doc/devblog/day_106__catching_up.mdwn
 create mode 100644 doc/devblog/day_107__TDD.mdwn
 create mode 100644 doc/devblog/day_108__new_use_for_location_tracking.mdwn
 create mode 100644 doc/devblog/day_109__elimintating_absNormPath.mdwn
 create mode 100644 doc/devblog/day_10__lazy_Sunday.mdwn
 create mode 100644 doc/devblog/day_110__release_prep.mdwn
 create mode 100644 doc/devblog/day_111__windows_beta_release.mdwn
 create mode 100644 doc/devblog/day_112__metadata_design.mdwn
 create mode 100644 doc/devblog/day_113__metadata_groundwork.mdwn
 create mode 100644 doc/devblog/day_114__windows_porting.mdwn
 create mode 100644 doc/devblog/day_115__windows_porting.mdwn
 create mode 100644 doc/devblog/day_116__views.mdwn
 create mode 100644 doc/devblog/day_117__views_implemented.mdwn
 create mode 100644 doc/devblog/day_118__views_refined.mdwn
 create mode 100644 doc/devblog/day_119__catching_up.mdwn
 create mode 100644 doc/devblog/day_119__catching_up/comment_1_8aa413e75cab411b0aec254f0f33ebb9._comment
 create mode 100644 doc/devblog/day_119__catching_up/comment_2_db31d08690730836ce6277e797fcae1d._comment
 create mode 100644 doc/devblog/day_119__catching_up/comment_3_d44da76b18f53a5f51b46e3e15090a48._comment
 create mode 100644 doc/devblog/day_11__webapp_encrypted_drives.mdwn
 create mode 100644 doc/devblog/day_120__more_metadata.mdwn
 create mode 100644 doc/devblog/day_121__special_remote_maintenance.mdwn
 create mode 100644 doc/devblog/day_122_more_windows_porting.mdwn
 create mode 100644 doc/devblog/day_123__stuck.mdwn
 create mode 100644 doc/devblog/day_124__day_off.mdwn
 create mode 100644 doc/devblog/day_125__metadata_and_views.mdwn
 create mode 100644 doc/devblog/day_128__release_prep.mdwn
 create mode 100644 doc/devblog/day_12__gpg_key_generation.mdwn
 create mode 100644 doc/devblog/day_12__gpg_key_generation/comment_1_48cdfe3bd71fb348ae05fd90e8cf1dab._comment
 create mode 100644 doc/devblog/day_130__post_release.mdwn
 create mode 100644 doc/devblog/day_131__more_bug_squashing.mdwn
 create mode 100644 doc/devblog/day_132__database_musings.mdwn
 create mode 100644 doc/devblog/day_133__db_and_bugfixes.mdwn
 create mode 100644 doc/devblog/day_134-135__avoiding_the_turing_tarpit.mdwn
 create mode 100644 doc/devblog/day_136__frustrating_day.mdwn
 create mode 100644 doc/devblog/day_137-138__bug_triage_and_too_much_windows.mdwn
 create mode 100644 doc/devblog/day_139-140__traveling.mdwn
 create mode 100644 doc/devblog/day_13__encrypted_sneakernet_working.mdwn
 create mode 100644 doc/devblog/day_141__f-droid_sprint.mdwn
 create mode 100644 doc/devblog/day_141__f-droid_sprint/comment_1_1cc76207020ac478747117c76d7b5f9c._comment
 create mode 100644 doc/devblog/day_142__digging_out.mdwn
 create mode 100644 doc/devblog/day_143__foolish_hiatus.mdwn
 create mode 100644 doc/devblog/day_144__catching_up.mdwn
 create mode 100644 doc/devblog/day_144__catching_up/comment_1_311a7245dd12f1a7e432168d16041348._comment
 create mode 100644 doc/devblog/day_145__a_plan.mdwn
 create mode 100644 doc/devblog/day_145__a_plan/comment_1_c0ceea77443be1172527ed8549f000a4._comment
 create mode 100644 doc/devblog/day_146__halfway_to_git-remote-daemon.mdwn
 create mode 100644 doc/devblog/day_147__git-annex_remotedaemon.mdwn
 create mode 100644 doc/devblog/day_148__too_many_documents.mdwn
 create mode 100644 doc/devblog/day_149__remote_control_working.mdwn
 create mode 100644 doc/devblog/day_149__signal.mdwn
 create mode 100644 doc/devblog/day_14__gcrypt_refinements_and_OOM_fixes.mdwn
 create mode 100644 doc/devblog/day_15-17__Android_rebuild.mdwn
 create mode 100644 doc/devblog/day_151__birthday_bug.mdwn
 create mode 100644 doc/devblog/day_152__more_ssh_connection_caching.mdwn
 create mode 100644 doc/devblog/day_153__remotedaemon_has_landed.mdwn
 create mode 100644 doc/devblog/day_153__remotedaemon_has_landed/comment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment
 create mode 100644 doc/devblog/day_153__remotedaemon_has_landed/comment_2_fbf0c50f772e958af638d2b72dac73f5._comment
 create mode 100644 doc/devblog/day_154__catching_up.mdwn
 create mode 100644 doc/devblog/day_155__missing_bits.mdwn
 create mode 100644 doc/devblog/day_155__missing_bits/comment_1_76424498600ba603946035efffb88023._comment
 create mode 100644 doc/devblog/day_156__release_day.mdwn
 create mode 100644 doc/devblog/day_157__upgrade_checking.mdwn
 create mode 100644 doc/devblog/day_158__enroute_to_Brazil.mdwn
 create mode 100644 doc/devblog/day_159__tmp_file_cleanup.mdwn
 create mode 100644 doc/devblog/day_160__.mdwn
 create mode 100644 doc/devblog/day_161__routing_design.mdwn
 create mode 100644 doc/devblog/day_162__routing_sim_and_massive_contribution_landed.mdwn
 create mode 100644 doc/devblog/day_163__request_and_routing_design.mdwn
 create mode 100644 doc/devblog/day_164__back.mdwn
 create mode 100644 doc/devblog/day_165__sshpassword_merged.mdwn
 create mode 100644 doc/devblog/day_166__catching_up.mdwn
 create mode 100644 doc/devblog/day_167__growing_the_community_of_git-annex_contributors.mdwn
 create mode 100644 doc/devblog/day_168__backlog_continued.mdwn
 create mode 100644 doc/devblog/day_169-171__juggling.mdwn
 create mode 100644 doc/devblog/day_172__.mdwn
 create mode 100644 doc/devblog/day_173-174__android_rebootstrap.mdwn
 create mode 100644 doc/devblog/day_175__encoding_day.mdwn
 create mode 100644 doc/devblog/day_176__mostly_a_day_off.mdwn
 create mode 100644 doc/devblog/day_177__enabling.mdwn
 create mode 100644 doc/devblog/day_177__enabling/comment_1_820d29f84dade09b0e7bb7435c52fcb8._comment
 create mode 100644 doc/devblog/day_178-179__screencast_and_what_next.mdwn
 create mode 100644 doc/devblog/day_178-179__screencast_and_what_next/comment_1_eeba788fed45cb22f9cc2a738ceaa074._comment
 create mode 100644 doc/devblog/day_178-179__screencast_and_what_next/comment_2_d44e67e34615c7b00e29f307556cdd06._comment
 create mode 100644 doc/devblog/day_180__porting.mdwn
 create mode 100644 doc/devblog/day_180__porting/comment_1_133875f4435a298b85ddfb8a2cc11a7a._comment
 create mode 100644 doc/devblog/day_181__tricky_merge.mdwn
 create mode 100644 doc/devblog/day_182__service.mdwn
 create mode 100644 doc/devblog/day_183__rubbing_sticks_together.mdwn
 create mode 100644 doc/devblog/day_184__windows_month.mdwn
 create mode 100644 doc/devblog/day_185__service.mdwn
 create mode 100644 doc/devblog/day_186__cracked_it.mdwn
 create mode 100644 doc/devblog/day_186__cracked_it/comment_1_288b736adf392acd0f45667b2980138d._comment
 create mode 100644 doc/devblog/day_186__cracked_it/comment_2_d1d79e93ac420f6b3a6f8a622e8e00bd._comment
 create mode 100644 doc/devblog/day_186__cracked_it/comment_3_8ca17a51b10b4e4a63d0672d5ce29024._comment
 create mode 100644 doc/devblog/day_187__release_prep.mdwn
 create mode 100644 doc/devblog/day_187__release_prep/comment_1_206692d16177c2a9ca11c0eeff545697._comment
 create mode 100644 doc/devblog/day_187__release_prep/comment_2_961fb35d9cf7d5e518f8d0bddb8626a6._comment
 create mode 100644 doc/devblog/day_188__back_sans_laptop.mdwn
 create mode 100644 doc/devblog/day_189__finally_working_again.mdwn
 create mode 100644 doc/devblog/day_190__fun_fixes.mdwn
 create mode 100644 doc/devblog/day_191__semidistracted.mdwn
 create mode 100644 doc/devblog/day_192__release_day.mdwn
 create mode 100644 doc/devblog/day_193-194__ugly_bug.mdwn
 create mode 100644 doc/devblog/day_195-196__catching_up.mdwn
 create mode 100644 doc/devblog/day_197__autobuilder_rescuscitation.mdwn
 create mode 100644 doc/devblog/day_198__branching_out.mdwn
 create mode 100644 doc/devblog/day_198__branching_out/comment_1_91ce3dc707ba1ba7c5d9e57e20ffce40._comment
 create mode 100644 doc/devblog/day_199__ten_minute_cycle.mdwn
 create mode 100644 doc/devblog/day_19__moving_on.mdwn
 create mode 100644 doc/devblog/day_19__moving_on/comment_1_870106f671f9a055b81e6fc83e0850b5._comment
 create mode 100644 doc/devblog/day_19__moving_on/comment_2_fad055c8860385ac6c012f897c96408f._comment
 create mode 100644 doc/devblog/day_19__moving_on/comment_3_69e47d612159587f080ab761566d1830._comment
 create mode 100644 doc/devblog/day_1__inauspicious_beginning.mdwn
 create mode 100644 doc/devblog/day_1__inauspicious_beginning/comment_1_cc4dea43caf3126c6f814b589b701d70._comment
 create mode 100644 doc/devblog/day_200__one_year_along.mdwn
 create mode 100644 doc/devblog/day_201__chunky.mdwn
 create mode 100644 doc/devblog/day_202__new_chunk_groundwork.mdwn
 create mode 100644 doc/devblog/day_203__in_the_weeds.mdwn
 create mode 100644 doc/devblog/day_204__mowing.mdwn
 create mode 100644 doc/devblog/day_205__incremental.mdwn
 create mode 100644 doc/devblog/day_206__zap.mdwn
 create mode 100644 doc/devblog/day_207__at_last.mdwn
 create mode 100644 doc/devblog/day_208__testremote.mdwn
 create mode 100644 doc/devblog/day_209__mass_conversion.mdwn
 create mode 100644 doc/devblog/day_20__gcrypt_and_git-annex-shell.mdwn
 create mode 100644 doc/devblog/day_210__conversion_and_digression.mdwn
 create mode 100644 doc/devblog/day_211__conversion_complete.mdwn
 create mode 100644 doc/devblog/day_212__webdav_rewrite.mdwn
 create mode 100644 doc/devblog/day_213__newchunks_merged.mdwn
 create mode 100644 doc/devblog/day_214-215__wrapping_up_recent_work.mdwn
 create mode 100644 doc/devblog/day_216__various_minor_bugs.mdwn
 create mode 100644 doc/devblog/day_216__various_minor_bugs/comment_1_0d0a0e75b9446f8a1c4cc43f36569473._comment
 create mode 100644 doc/devblog/day_216__various_minor_bugs/comment_2_6b06b3f46f20a6d2e60684d1d59fca07._comment
 create mode 100644 doc/devblog/day_216__various_minor_bugs/comment_3_05177e2ed414d22711dcec57a614e38c._comment
 create mode 100644 doc/devblog/day_217__autobuilders.mdwn
 create mode 100644 doc/devblog/day_218__scary_locking.mdwn
 create mode 100644 doc/devblog/day_219__catching_up_and_looking_back.mdwn
 create mode 100644 doc/devblog/day_219__catching_up_and_looking_back/comment_1_16b13b2510183a9da5f960ae5765e581._comment
 create mode 100644 doc/devblog/day_219__catching_up_and_looking_back/comment_2_460c064bebb5061fcba2a6c79f039362._comment
 create mode 100644 doc/devblog/day_219__catching_up_and_looking_back/comment_3_9699d5a9de5ea64fbc876352e20261c4._comment
 create mode 100644 doc/devblog/day_219__catching_up_and_looking_back/comment_4_23c4ede3db0ea8165311466881cfa6a2._comment
 create mode 100644 doc/devblog/day_219__catching_up_and_looking_back/comment_5_7997305d7ec7db072b78dd0c31ecd824._comment
 create mode 100644 doc/devblog/day_21__bugfix_day.mdwn
 create mode 100644 doc/devblog/day_220__working_through_backlog.mdwn
 create mode 100644 doc/devblog/day_221__another_fine_day_of_bugfixing.mdwn
 create mode 100644 doc/devblog/day_222_preparing_for_debian_release.mdwn
 create mode 100644 doc/devblog/day_223__partial_commit_problem.mdwn
 create mode 100644 doc/devblog/day_224-226__long_rainy_slog.mdwn
 create mode 100644 doc/devblog/day_227__info.mdwn
 create mode 100644 doc/devblog/day_229__S3_multipart.mdwn
 create mode 100644 doc/devblog/day_22__gcrypt_on_rsync.net.mdwn
 create mode 100644 doc/devblog/day_230__S3_multipart_round_2.mdwn
 create mode 100644 doc/devblog/day_231__S3_multipart_wrapped_up.mdwn
 create mode 100644 doc/devblog/day_232__OSX_Yosemite.mdwn
 create mode 100644 doc/devblog/day_233__direct_mode_proxy.mdwn
 create mode 100644 doc/devblog/day_234__undo_undo.mdwn
 create mode 100644 doc/devblog/day_235__thanksgiving_backlog.mdwn
 create mode 100644 doc/devblog/day_236__release_day.mdwn
 create mode 100644 doc/devblog/day_237__extending_addurl.mdwn
 create mode 100644 doc/devblog/day_238__extending_addurl_further.mdwn
 create mode 100644 doc/devblog/day_239-240__bittorrent_remote.mdwn
 create mode 100644 doc/devblog/day_23__GNU_day.mdwn
 create mode 100644 doc/devblog/day_241-242__end_of_year_cleanup.mdwn
 create mode 100644 doc/devblog/day_243__android_5.mdwn
 create mode 100644 doc/devblog/day_243__android_5/comment_1_59a139108f4cf20dd7443a5fa767f614._comment
 create mode 100644 doc/devblog/day_244__relative_paths.mdwn
 create mode 100644 doc/devblog/day_245__yak_shaving.mdwn
 create mode 100644 doc/devblog/day_246__old_todos.mdwn
 create mode 100644 doc/devblog/day_247__hooks_and_large_files_on_windows.mdwn
 create mode 100644 doc/devblog/day_248__workload_tuning.mdwn
 create mode 100644 doc/devblog/day_249_onward.mdwn
 create mode 100644 doc/devblog/day_249_onward/comment_1_80af832a132ee37a470d0586ae751f2a._comment
 create mode 100644 doc/devblog/day_249_onward/comment_2_ada958a8df4da36b25a456a7700b310f._comment
 create mode 100644 doc/devblog/day_24__nearly_done_with_gcrypt.mdwn
 create mode 100644 doc/devblog/day_250__backog_bugfixing.mdwn
 create mode 100644 doc/devblog/day_251-252__dusting_off_the_roadmap.mdwn
 create mode 100644 doc/devblog/day_253__sqlite_for_incremental_fsck.mdwn
 create mode 100644 doc/devblog/day_253__sqlite_for_incremental_fsck/comment_1_683d669ac6af8e314585609f75cfdaf3._comment
 create mode 100644 doc/devblog/day_253__sqlite_for_incremental_fsck/comment_2_08dd639180ae79addc007ee47d52048a._comment
 create mode 100644 doc/devblog/day_253__ssh-options.mdwn
 create mode 100644 doc/devblog/day_255__sqlite_concurrent_writers_problem.mdwn
 create mode 100644 doc/devblog/day_256__sqlite_concurrency_argh.mdwn
 create mode 100644 doc/devblog/day_257__release_day.mdwn
 create mode 100644 doc/devblog/day_258__database_branch_merged.mdwn
 create mode 100644 doc/devblog/day_259__submodules.mdwn
 create mode 100644 doc/devblog/day_25__finishing_up_gcrypt.mdwn
 create mode 100644 doc/devblog/day_260__random_month.mdwn
 create mode 100644 doc/devblog/day_261__random_improvements.mdwn
 create mode 100644 doc/devblog/day_262__ipfs.mdwn
 create mode 100644 doc/devblog/day_263__diving_back_in.mdwn
 create mode 100644 doc/devblog/day_264__catching_up.mdwn
 create mode 100644 doc/devblog/day_265__at_Dartmouth.mdwn
 create mode 100644 doc/devblog/day_266-267__man_page_split.mdwn
 create mode 100644 doc/devblog/day_266-267__man_page_split/comment_1_d55600917128cb0ce38002fbf6f0b088._comment
 create mode 100644 doc/devblog/day_266-267__man_page_split/comment_2_63791201452a6ab30a35cd742434acca._comment
 create mode 100644 doc/devblog/day_266-267__man_page_split/comment_3_d7764c605ad338c4bf4c4b46b54abd8a._comment
 create mode 100644 doc/devblog/day_268_stressed_out.mdwn
 create mode 100644 doc/devblog/day_268_stressed_out/comment_1_d28352c9fbc988ece19688a687d30ffe._comment
 create mode 100644 doc/devblog/day_268_stressed_out/comment_2_f7b04b2e96f0fc7530f1c21ccfcfb0f9._comment
 create mode 100644 doc/devblog/day_268_stressed_out/comment_3_0eb4c17d35fba9db6a7446a5f253ace9._comment
 create mode 100644 doc/devblog/day_268_stressed_out/comment_4_fecf179be92c3a3e25f4a47fcea6b6ec._comment
 create mode 100644 doc/devblog/day_269__wildcards_and_podcasts.mdwn
 create mode 100644 doc/devblog/day_26__gcrypt_really_done_this_time.mdwn
 create mode 100644 doc/devblog/day_270__distributed_fsck.mdwn
 create mode 100644 doc/devblog/day_271__parallel_get_groundwork.mdwn
 create mode 100644 doc/devblog/day_272__forest_for_trees.mdwn
 create mode 100644 doc/devblog/day_273__unexpected_release.mdwn
 create mode 100644 doc/devblog/day_274__concurrent_annex_state.mdwn
 create mode 100644 doc/devblog/day_274__concurrent_annex_state/comment_1_7414fc0dde7a1d1ee456f8eba0b0c2a9._comment
 create mode 100644 doc/devblog/day_274__concurrent_annex_state/comment_2_4ca498ee4b4aaac8ee6dbc2c769dbad7._comment
 create mode 100644 doc/devblog/day_275-276__mostly_Windows.mdwn
 create mode 100644 doc/devblog/day_277__thanks.mdwn
 create mode 100644 doc/devblog/day_278__release_day.mdwn
 create mode 100644 doc/devblog/day_279__.mdwn
 create mode 100644 doc/devblog/day_27__locking_fun.mdwn
 create mode 100644 doc/devblog/day_27__locking_fun/comment_1_0eb247235fbf8f563934f3548e1d2e10._comment
 create mode 100644 doc/devblog/day_27__locking_fun/comment_2_e8b1dfe1b0641e031d05733448b7bc8b._comment
 create mode 100644 doc/devblog/day_27__locking_fun/comment_3_b67f8ef4ed42b49c8c2e6c4e53163b16._comment
 create mode 100644 doc/devblog/day_27__locking_fun/comment_4_0759644baf26b75f4e48dbb387d725a5._comment
 create mode 100644 doc/devblog/day_280__slow_week.mdwn
 create mode 100644 doc/devblog/day_281__catching_up__and_arm_autobuilder_needed.mdwn
 create mode 100644 doc/devblog/day_282__release_day.mdwn
 create mode 100644 doc/devblog/day_283__lazy_sunday.mdwn
 create mode 100644 doc/devblog/day_283__lazy_sunday/comment_1_fdc6da890e2dc6b86b6a5fe2ebceea4a._comment
 create mode 100644 doc/devblog/day_284__development.mdwn
 create mode 100644 doc/devblog/day_285__tuning_git-annex_unused_refs.mdwn
 create mode 100644 doc/devblog/day_285__tuning_git-annex_unused_refs/comment_1_a3f0dd4fc8457af7c72040fbe8fd5fee._comment
 create mode 100644 doc/devblog/day_285__tuning_git-annex_unused_refs/comment_2_dae167e473c60dace129c66beb0af384._comment
 create mode 100644 doc/devblog/day_285__tuning_git-annex_unused_refs/comment_3_52179fc326e681d8fbf85ee8963f352c._comment
 create mode 100644 doc/devblog/day_286-287__rotten_locks.mdwn
 create mode 100644 doc/devblog/day_288__microrelease_prep.mdwn
 create mode 100644 doc/devblog/day_288__microrelease_prep/comment_1_99e359976acbdb9727598f8a87027de0._comment
 create mode 100644 doc/devblog/day_288__microrelease_prep/comment_2_27a74d3926083a00c110aafea28420d7._comment
 create mode 100644 doc/devblog/day_288__microrelease_prep/comment_3_17752e96baaf46f3048b14a9ec288e3b._comment
 create mode 100644 doc/devblog/day_288__microrelease_prep/comment_4_2838c1d9da3202616e331bb31fd43f20._comment
 create mode 100644 doc/devblog/day_289__new_arm_autobuilder.mdwn
 create mode 100644 doc/devblog/day_28__lazy_saturday.mdwn
 create mode 100644 doc/devblog/day_290__.mdwn
 create mode 100644 doc/devblog/day_291__public_S3.mdwn
 create mode 100644 doc/devblog/day_291__public_S3/comment_1_c0e96b25b764180975cc26b1316f462d._comment
 create mode 100644 doc/devblog/day_291__public_S3/comment_2_d5223684c09725973b2052425fd30773._comment
 create mode 100644 doc/devblog/day_292__dead_keys.mdwn
 create mode 100644 doc/devblog/day_293__last_push_before_summer_vacation.mdwn
 create mode 100644 doc/devblog/day_294__back_focusing_on_bugs.mdwn
 create mode 100644 doc/devblog/day_295__caught_up.mdwn
 create mode 100644 doc/devblog/day_296__into_the_backlog.mdwn
 create mode 100644 doc/devblog/day_297__optparse-applicative.mdwn
 create mode 100644 doc/devblog/day_299__so_many_commands_and_options.mdwn
 create mode 100644 doc/devblog/day_29__scheduling.mdwn
 create mode 100644 doc/devblog/day_2__new_laptop.mdwn
 create mode 100644 doc/devblog/day_2__new_laptop/comment_1_93447dbd4eb09b4db96770644ea663cb._comment
 create mode 100644 doc/devblog/day_2__new_laptop/comment_2_e1d022b25f2c16dbe72db07ad4b10a2d._comment
 create mode 100644 doc/devblog/day_300__optparse-applicative_landed.mdwn
 create mode 100644 doc/devblog/day_301__completion_and_er_completion.mdwn
 create mode 100644 doc/devblog/day_302-305__gitlab.mdwn
 create mode 100644 doc/devblog/day_306__release_day.mdwn
 create mode 100644 doc/devblog/day_307__two_release_week.mdwn
 create mode 100644 doc/devblog/day_308__other_peoples_bugs.mdwn
 create mode 100644 doc/devblog/day_309__proxy.mdwn
 create mode 100644 doc/devblog/day_30__cronner.mdwn
 create mode 100644 doc/devblog/day_30__cronner/comment_1_53dfd9310e92f5225db52a13e20a46d4._comment
 create mode 100644 doc/devblog/day_30__cronner/comment_2_f98357c6f7a6da23873ac27c2e1e9638._comment
 create mode 100644 doc/devblog/day_310__half_day.mdwn
 create mode 100644 doc/devblog/day_310__half_day/comment_1_81db682a271ebc92cce893762c3930a8._comment
 create mode 100644 doc/devblog/day_311__SHA-3.mdwn
 create mode 100644 doc/devblog/day_312__release_prep.mdwn
 create mode 100644 doc/devblog/day_313__optimisation.mdwn
 create mode 100644 doc/devblog/day_314__pre_trip_catchup.mdwn
 create mode 100644 doc/devblog/day_315__scrambling.mdwn
 create mode 100644 doc/devblog/day_316-318__chasing_dependencies_and_todos.mdwn
 create mode 100644 doc/devblog/day_319__release_day.mdwn
 create mode 100644 doc/devblog/day_31__blah.mdwn
 create mode 100644 doc/devblog/day_320__caught_up.mdwn
 create mode 100644 doc/devblog/day_320__porting_and_such.mdwn
 create mode 100644 doc/devblog/day_321__download_verification.mdwn
 create mode 100644 doc/devblog/day_321__download_verification/comment_1_424367fba4db56f4699952572bd3d605._comment
 create mode 100644 doc/devblog/day_321__download_verification/comment_2_926cc165e99f2e125c909bd706460a05._comment
 create mode 100644 doc/devblog/day_321__download_verification/comment_3_fb0ed50c27a493c3494bf2efbf9a9c5d._comment
 create mode 100644 doc/devblog/day_321__download_verification/comment_4_fecb2d6349aa61f1c76525178fea4598._comment
 create mode 100644 doc/devblog/day_322-326__concurrent_drop_safety.mdwn
 create mode 100644 doc/devblog/day_327__soaking.mdwn
 create mode 100644 doc/devblog/day_328__git-annex_is_five.mdwn
 create mode 100644 doc/devblog/day_328__git-annex_is_five/comment_1_ff7e8d4c37f4a1aa189af0354db8794a._comment
 create mode 100644 doc/devblog/day_328__git-annex_is_five/comment_2_9e18a2c71884229f06b5ba62a6529a33._comment
 create mode 100644 doc/devblog/day_32__fsck_config_UI.mdwn
 create mode 100644 doc/devblog/day_331__concurrent-output_preparations.mdwn
 create mode 100644 doc/devblog/day_332__concurrent_output_at_long_last.mdwn
 create mode 100644 doc/devblog/day_333__cylons.mdwn
 create mode 100644 doc/devblog/day_334__too_easy.mdwn
 create mode 100644 doc/devblog/day_334__too_easy/comment_1_2181970ef1a3380407ce9eef311c9ebc._comment
 create mode 100644 doc/devblog/day_335__catching_up_with_the_bug_reports.mdwn
 create mode 100644 doc/devblog/day_336__green.mdwn
 create mode 100644 doc/devblog/day_336__pid_locks.mdwn
 create mode 100644 doc/devblog/day_337__who_needs_POSIX.mdwn
 create mode 100644 doc/devblog/day_338__week_in_review.mdwn
 create mode 100644 doc/devblog/day_339_smudging_out_direct_mode.mdwn
 create mode 100644 doc/devblog/day_339_smudging_out_direct_mode/comment_1_6435db0003d2d8414b1a040b8899c7b8._comment
 create mode 100644 doc/devblog/day_339_smudging_out_direct_mode/comment_2_79d19b2b057c2a0b23875a32dae0c2ba._comment
 create mode 100644 doc/devblog/day_339_smudging_out_direct_mode/comment_3_43f7c7c6c2fd227466857c3232e13351._comment
 create mode 100644 doc/devblog/day_339_smudging_out_direct_mode/comment_3_43f7c7c6c2fd227466857c3232e13351/comment_1_78e16167ca29eb3ed43706b39bf08603._comment
 create mode 100644 doc/devblog/day_339_smudging_out_direct_mode/comment_4_35d0472cd64335eedeeb17d51cdbaf5b._comment
 create mode 100644 doc/devblog/day_339_smudging_out_direct_mode/comment_5_499f3553c4efc35e54f121a7d4abc029._comment
 create mode 100644 doc/devblog/day_339_smudging_out_direct_mode/comment_6_ede48107675edfe40d5fdd3377553aa4._comment
 create mode 100644 doc/devblog/day_339_smudging_out_direct_mode/comment_7_ceb1d2a0e5bbc73590b80ff69292102d._comment
 create mode 100644 doc/devblog/day_33__fsck_on_connect.mdwn
 create mode 100644 doc/devblog/day_340__post_turkey_catchup.mdwn
 create mode 100644 doc/devblog/day_341__starting_smudge.mdwn
 create mode 100644 doc/devblog/day_342__continuing_smudge.mdwn
 create mode 100644 doc/devblog/day_343__get_and_drop_for_smudge.mdwn
 create mode 100644 doc/devblog/day_344-345__smudging_along.mdwn
 create mode 100644 doc/devblog/day_346-347__nearly_ready_to_merge.mdwn
 create mode 100644 doc/devblog/day_348__v6_assistant.mdwn
 create mode 100644 doc/devblog/day_349__v6_database_optimisation.mdwn
 create mode 100644 doc/devblog/day_34__wrapping_up_fsck.mdwn
 create mode 100644 doc/devblog/day_350-351__it_landed_on_xmas_eve.mdwn
 create mode 100644 doc/devblog/day_352__had_to_be_done.mdwn
 create mode 100644 doc/devblog/day_353__one_step_forward_and_N_steps_back.mdwn
 create mode 100644 doc/devblog/day_354-355__beating_on_the_test_suite.mdwn
 create mode 100644 doc/devblog/day_356__benchmarking.mdwn
 create mode 100644 doc/devblog/day_357__post_release_catchup.mdwn
 create mode 100644 doc/devblog/day_357__post_release_catchup/comment_1_6963d1c6be69e531726f62f02d50855c._comment
 create mode 100644 doc/devblog/day_358__bugfix_release.mdwn
 create mode 100644 doc/devblog/day_358__bugfix_release/comment_1_a9aa122010e576c572ca719638ecf2e6._comment
 create mode 100644 doc/devblog/day_359__annex.largefiles_gitattributes.mdwn
 create mode 100644 doc/devblog/day_359__annex.largefiles_gitattributes/comment_1_ac73ad4147629c25cd51d13cfea206cf._comment
 create mode 100644 doc/devblog/day_359__annex.largefiles_gitattributes/comment_2_cfbf4fb5a3a1beb582faa051d1627a31._comment
 create mode 100644 doc/devblog/day_35__anacron_and_bugfixing.mdwn
 create mode 100644 doc/devblog/day_360__annex.largefiles_mimetype.mdwn
 create mode 100644 doc/devblog/day_360__annex.largefiles_mimetype/comment_2_78a22b96a82f76ab7217d37918a19024._comment
 create mode 100644 doc/devblog/day_360__annex.largefiles_mimetype/comment_3_3145e5843e20a037351e5a14fa3d6e9a._comment
 create mode 100644 doc/devblog/day_360__annex.largefiles_mimetype/comment_3_bf44404de52b00ff4e4f1effd4cef336._comment
 create mode 100644 doc/devblog/day_360__annex.largefiles_mimetype/comment_4_70c337d91f8d0458927c111763041118._comment
 create mode 100644 doc/devblog/day_360__results_of_2015_user_survey.mdwn
 create mode 100644 doc/devblog/day_360__results_of_2015_user_survey/comment_1_5f30c583cd20c33e2bcd386f674d6f3b._comment
 create mode 100644 doc/devblog/day_360__results_of_2015_user_survey/comment_2_68479af6dda2f732436b19160297aacd._comment
 create mode 100644 doc/devblog/day_360__results_of_2015_user_survey/comment_3_e38568c6baa30f58c5a7735b2f7985ed._comment
 create mode 100644 doc/devblog/day_360__results_of_2015_user_survey/comment_4_e0bfb67454df205f2c9c566933e7f121._comment
 create mode 100644 doc/devblog/day_361__adjusted_branches_design.mdwn
 create mode 100644 doc/devblog/day_362__encoding_fun.mdwn
 create mode 100644 doc/devblog/day_363__snow_day.mdwn
 create mode 100644 doc/devblog/day_364__more_v6_unlocked.mdwn
 create mode 100644 doc/devblog/day_365__some_kind_of_milestone.mdwn
 create mode 100644 doc/devblog/day_366__starting_adjusted_branches.mdwn
 create mode 100644 doc/devblog/day_367__adjusted_branches_proof_of_concept.mdwn
 create mode 100644 doc/devblog/day_368__leap.mdwn
 create mode 100644 doc/devblog/day_369-370__paddling_furiously.mdwn
 create mode 100644 doc/devblog/day_36__bugfixing.mdwn
 create mode 100644 doc/devblog/day_371__catching_up.mdwn
 create mode 100644 doc/devblog/day_372__adjusted_branches_improved.mdwn
 create mode 100644 doc/devblog/day_373__away.mdwn
 create mode 100644 doc/devblog/day_374__security_fix.mdwn
 create mode 100644 doc/devblog/day_375__back.mdwn
 create mode 100644 doc/devblog/day_376__in_the_weeds.mdwn
 create mode 100644 doc/devblog/day_377__will_adjusted_branches_ever_end.mdwn
 create mode 100644 doc/devblog/day_378__finishing_adjusted_branches_merge.mdwn
 create mode 100644 doc/devblog/day_379__bugs_race_conditions_and_taxes.mdwn
 create mode 100644 doc/devblog/day_37__long_day.mdwn
 create mode 100644 doc/devblog/day_380__post_release.mdwn
 create mode 100644 doc/devblog/day_381__executable_unlocked_files.mdwn
 create mode 100644 doc/devblog/day_382-384__pretty_well_caught_up.mdwn
 create mode 100644 doc/devblog/day_385__new_features.mdwn
 create mode 100644 doc/devblog/day_385__new_features/comment_1_f76ff85897f24692e96f88236b7f4b7d._comment
 create mode 100644 doc/devblog/day_386__day_off.mdwn
 create mode 100644 doc/devblog/day_387__release_day.mdwn
 create mode 100644 doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment
 create mode 100644 doc/devblog/day_387__release_day/comment_2_86262439c9056c0e06623cdf79eaf9a6._comment
 create mode 100644 doc/devblog/day_388-389__various_and_windows.mdwn
 create mode 100644 doc/devblog/day_38__starting_git_repo_repair.mdwn
 create mode 100644 doc/devblog/day_38__starting_git_repo_repair/comment_1_321468d9686db5dde072500bdaeb7d29._comment
 create mode 100644 doc/devblog/day_390__sharedpubkey.mdwn
 create mode 100644 doc/devblog/day_391__git_smudge_clean_interface_proposal.mdwn
 create mode 100644 doc/devblog/day_392__v6_fixes.mdwn
 create mode 100644 doc/devblog/day_392__v6_fixes/comment_1_6da0787fa9749ee2d1f91842f10a5d3c._comment
 create mode 100644 doc/devblog/day_392__v6_fixes/comment_2_15434848be1951e93a1e5b9fcbccedb0._comment
 create mode 100644 doc/devblog/day_392__v6_fixes/comment_3_74e696f147f80162a941a5a5435327ce._comment
 create mode 100644 doc/devblog/day_393__fun_and_more_fun.mdwn
 create mode 100644 doc/devblog/day_394__implicit_vs_explicit.mdwn
 create mode 100644 doc/devblog/day_395__leaky_abstractions.mdwn
 create mode 100644 doc/devblog/day_396__misc_fixes.mdwn
 create mode 100644 doc/devblog/day_397__befuddled.mdwn
 create mode 100644 doc/devblog/day_398__fresh_eyes.mdwn
 create mode 100644 doc/devblog/day_399__weird_git_merge_bug.mdwn
 create mode 100644 doc/devblog/day_39__git-recover-repository.mdwn
 create mode 100644 doc/devblog/day_3__gcrypt_uuids.mdwn
 create mode 100644 doc/devblog/day_400-401__git_development.mdwn
 create mode 100644 doc/devblog/day_402__enhanced_smudge_clean_interface.mdwn
 create mode 100644 doc/devblog/day_403__update_and_away.mdwn
 create mode 100644 doc/devblog/day_404__low_hanging_fruit.mdwn
 create mode 100644 doc/devblog/day_405__more_git_development.mdwn
 create mode 100644 doc/devblog/day_406__low_handing_fruit_continued.mdwn
 create mode 100644 doc/devblog/day_407__lazy_sunday.mdwn
 create mode 100644 doc/devblog/day_408__release_day.mdwn
 create mode 100644 doc/devblog/day_408__release_day/comment_1_RichiH._comment
 create mode 100644 doc/devblog/day_409__--branch.mdwn
 create mode 100644 doc/devblog/day_40__another_fine_mess.mdwn
 create mode 100644 doc/devblog/day_410__better_JSON_for_metadata.mdwn
 create mode 100644 doc/devblog/day_411__metadata_--batch.mdwn
 create mode 100644 doc/devblog/day_412__if_at_first_you_dont_succeed.mdwn
 create mode 100644 doc/devblog/day_412__if_at_first_you_dont_succeed/comment_1_8980f56815a2c016ca950aec09e6e839._comment
 create mode 100644 doc/devblog/day_412__if_at_first_you_dont_succeed/comment_2_641ca9bce852cea42cac25fd77518885._comment
 create mode 100644 doc/devblog/day_413__back.mdwn
 create mode 100644 doc/devblog/day_414__improved_parallel_get.mdwn
 create mode 100644 doc/devblog/day_415__catching_up.mdwn
 create mode 100644 doc/devblog/day_416__measure_twice.mdwn
 create mode 100644 doc/devblog/day_417__cut_once.mdwn
 create mode 100644 doc/devblog/day_418__concurrent_externals.mdwn
 create mode 100644 doc/devblog/day_418__concurrent_externals/comment_1_75e6569b143cf3f595ba9b356415a747._comment
 create mode 100644 doc/devblog/day_418__concurrent_externals/comment_2_067909ed54f3f9295f90233f25ccfd70._comment
 create mode 100644 doc/devblog/day_418__concurrent_externals/comment_3_39c729fc2ea4b597d13e54d60bb36d0d._comment
 create mode 100644 doc/devblog/day_418__concurrent_externals/comment_4_6b254fbe92d40abc30d01afe5d039afc._comment
 create mode 100644 doc/devblog/day_418__concurrent_externals/comment_5_5e851b62bdca1cb8d8062d4890c77956._comment
 create mode 100644 doc/devblog/day_418__concurrent_externals/comment_6_ea5d42bcb03af937a604119039f9073a._comment
 create mode 100644 doc/devblog/day_419__catching_up.mdwn
 create mode 100644 doc/devblog/day_41__onward.mdwn
 create mode 100644 doc/devblog/day_41__onward/comment_1_a716c7b5a9ea3c949ff047cfb4e9a0a4._comment
 create mode 100644 doc/devblog/day_41__onward/comment_2_33149e424cd5f03fac376288bcc4dfdc._comment
 create mode 100644 doc/devblog/day_41__onward/comment_3_3b07503bd79089ad3ce3ddd7535ed116._comment
 create mode 100644 doc/devblog/day_420__delayed_debugging.mdwn
 create mode 100644 doc/devblog/day_421__lost_in_the_trees.mdwn
 create mode 100644 doc/devblog/day_422__bugfixes_for_v6_mode.mdwn
 create mode 100644 doc/devblog/day_423__ssh_fun.mdwn
 create mode 100644 doc/devblog/day_424__the_dog.mdwn
 create mode 100644 doc/devblog/day_425__tor.mdwn
 create mode 100644 doc/devblog/day_425__tor/comment_1_1dd41fa32eb3867d764f3238005b5b81._comment
 create mode 100644 doc/devblog/day_426__grab_bag.mdwn
 create mode 100644 doc/devblog/day_426__grab_bag/comment_1_4d01c756850032d351fa99188a3301a7._comment
 create mode 100644 doc/devblog/day_427__free_p2p.mdwn
 create mode 100644 doc/devblog/day_428-429__git_push_to_hiddden_service.mdwn
 create mode 100644 doc/devblog/day_42__repair_milestone.mdwn
 create mode 100644 doc/devblog/day_430__tor_socket_problem.mdwn
 create mode 100644 doc/devblog/day_431__p2p_linking.mdwn
 create mode 100644 doc/devblog/day_431__p2p_linking/comment_1_1d5f809564c25e765f82594af8e174ab._comment
 create mode 100644 doc/devblog/day_432-433__almost_there.mdwn
 create mode 100644 doc/devblog/day_434__it_works.mdwn
 create mode 100644 doc/devblog/day_435-436_post_tor_merge.mdwn
 create mode 100644 doc/devblog/day_437__catching_up.mdwn
 create mode 100644 doc/devblog/day_438__bi-directional_p2p_links.mdwn
 create mode 100644 doc/devblog/day_439__wormhole_pairing.mdwn
 create mode 100644 doc/devblog/day_43__bugfix_day.mdwn
 create mode 100644 doc/devblog/day_440__holidaze.mdwn
 create mode 100644 doc/devblog/day_441__webapp_wormhole_pairing.mdwn
 create mode 100644 doc/devblog/day_442__xmpp_removal.mdwn
 create mode 100644 doc/devblog/day_442__xmpp_removal/comment_1_22ff11b84f855ab5e6de6dcf2553a050._comment
 create mode 100644 doc/devblog/day_442__xmpp_removal/comment_2_eaf64ce3daae790bb27d21887886d73b._comment
 create mode 100644 doc/devblog/day_443__yes_it_has_been_a_while.mdwn
 create mode 100644 doc/devblog/day_444__memory_leak_with_a_cold.mdwn
 create mode 100644 doc/devblog/day_445__configs.mdwn
 create mode 100644 doc/devblog/day_446__quiet_progress.mdwn
 create mode 100644 doc/devblog/day_447__bug_class.mdwn
 create mode 100644 doc/devblog/day_448__git_push_to_update_remote.mdwn
 create mode 100644 doc/devblog/day_449__SHA1_break_day.mdwn
 create mode 100644 doc/devblog/day_44__automatic_removable_drive_repair.mdwn
 create mode 100644 doc/devblog/day_450__hardening_against_SHA_attacks.mdwn
 create mode 100644 doc/devblog/day_451__annex.securehashesonly.mdwn
 create mode 100644 doc/devblog/day_452__GIT_SSH.mdwn
 create mode 100644 doc/devblog/day_453_release_prep.mdwn
 create mode 100644 doc/devblog/day_454__multicast.mdwn
 create mode 100644 doc/devblog/day_454__multicast/comment_1_137ea34cd11004513a03f24955719756._comment
 create mode 100644 doc/devblog/day_454__multicast/comment_2_09908606fc362cbee516999cd696f718._comment
 create mode 100644 doc/devblog/day_455__semi-synchronized.mdwn
 create mode 100644 doc/devblog/day_456__digging_in.mdwn
 create mode 100644 doc/devblog/day_457__improved_ssh_password_prompting.mdwn
 create mode 100644 doc/devblog/day_458__adeiu_MissingH.mdwn
 create mode 100644 doc/devblog/day_459__git_bug.mdwn
 create mode 100644 doc/devblog/day_45__command_line.mdwn
 create mode 100644 doc/devblog/day_460__move_--to_here.mdwn
 create mode 100644 doc/devblog/day_461__shell_completions.mdwn
 create mode 100644 doc/devblog/day_462__the_feature_youve_all_been_waiting_for.mdwn
 create mode 100644 doc/devblog/day_462__the_feature_youve_all_been_waiting_for/comment_1_6b13defcdf76691049b9bcd7ec675da6._comment
 create mode 100644 doc/devblog/day_463-465__back_buggy_external_special_remotes.mdwn
 create mode 100644 doc/devblog/day_466__export_prototype.mdwn
 create mode 100644 doc/devblog/day_467__export_progress.mdwn
 create mode 100644 doc/devblog/day_467__firming_up_export.mdwn
 create mode 100644 doc/devblog/day_467__firming_up_export/comment_1_382fac60766340481acbcb8c05b70f42._comment
 create mode 100644 doc/devblog/day_468__export_renames.mdwn
 create mode 100644 doc/devblog/day_468__export_renames/comment_1_4c37e6f9ac1e1571495b0d355c8af9ff._comment
 create mode 100644 doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment
 create mode 100644 doc/devblog/day_469__export_merged.mdwn
 create mode 100644 doc/devblog/day_46__wrapping_up_the_month.mdwn
 create mode 100644 doc/devblog/day_470__export_to_external_and_S3.mdwn
 create mode 100644 doc/devblog/day_471__export_to_more_remotes.mdwn
 create mode 100644 doc/devblog/day_472__removing_empty_directories.mdwn
 create mode 100644 doc/devblog/day_473__distributed_use_of_exports.mdwn
 create mode 100644 doc/devblog/day_474__tracking_exports.mdwn
 create mode 100644 doc/devblog/day_475__assistant_exports.mdwn
 create mode 100644 doc/devblog/day_476__third_time_lucky.mdwn
 create mode 100644 doc/devblog/day_477__windows_build_fixed.mdwn
 create mode 100644 doc/devblog/day_478__windows_the_blackhole.mdwn
 create mode 100644 doc/devblog/day_47__fell_off_the_blogging_wagon.mdwn
 create mode 100644 doc/devblog/day_482__website_login_problem.mdwn
 create mode 100644 doc/devblog/day_483__faster_start_with_removable_drives.mdwn
 create mode 100644 doc/devblog/day_484__special_remote_protocol_extensions.mdwn
 create mode 100644 doc/devblog/day_485__slow_and_steady.mdwn
 create mode 100644 doc/devblog/day_486__time_to_ditch_rsync.mdwn
 create mode 100644 doc/devblog/day_487__git-annex-shell_p2pstdio.mdwn
 create mode 100644 doc/devblog/day_488__groundwork_for_using_p2pstdio.mdwn
 create mode 100644 doc/devblog/day_489__zooming.mdwn
 create mode 100644 doc/devblog/day_489__zooming/comment_1_d840f371f1d22b0ee8f3c8df25ebe3d3._comment
 create mode 100644 doc/devblog/day_489__zooming/comment_2_ec579c84aeb244798a818a20ff0f50b5._comment
 create mode 100644 doc/devblog/day_48__direct_mode_guard_design.mdwn
 create mode 100644 doc/devblog/day_48__direct_mode_guard_design/comment_1_ec0147ccc55bad3a38652383f4098a65._comment
 create mode 100644 doc/devblog/day_490__kind_of_annoying.mdwn
 create mode 100644 doc/devblog/day_491__annex.verify_redux.mdwn
 create mode 100644 doc/devblog/day_492__concurrency_is_hard.mdwn
 create mode 100644 doc/devblog/day_493__two_new_special_remotes.mdwn
 create mode 100644 doc/devblog/day_494__url_download_changes.mdwn
 create mode 100644 doc/devblog/day_495__move_numcopies_safety.mdwn
 create mode 100644 doc/devblog/day_496__move_numcopies_safety_revisited.mdwn
 create mode 100644 doc/devblog/day_497__rethinking_the_android_port.mdwn
 create mode 100644 doc/devblog/day_497__rethinking_the_android_port/comment_1_cb30ab18753e5f221ed4d92b3ff8a32e._comment
 create mode 100644 doc/devblog/day_498__unexpected_release_prep.mdwn
 create mode 100644 doc/devblog/day_499__security_hole.mdwn
 create mode 100644 doc/devblog/day_49__direct_mode_guard_implementation.mdwn
 create mode 100644 doc/devblog/day_49__direct_mode_guard_implementation/comment_1_3ebe5c3f708070f164ecaf36b79f7bfc._comment
 create mode 100644 doc/devblog/day_4__unexpected_windows_day.mdwn
 create mode 100644 doc/devblog/day_500__security_hole_part_2.mdwn
 create mode 100644 doc/devblog/day_501__security_hole_part_3.mdwn
 create mode 100644 doc/devblog/day_502__security_hole_part_4.mdwn
 create mode 100644 doc/devblog/day_503__security_hole_part_5.mdwn
 create mode 100644 doc/devblog/day_504__security_hole_part_6.mdwn
 create mode 100644 doc/devblog/day_505__security_fix_release.mdwn
 create mode 100644 doc/devblog/day_506__summer_features.mdwn
 create mode 100644 doc/devblog/day_507__v6_revisited.mdwn
 create mode 100644 doc/devblog/day_508__git-protocol.mdwn
 create mode 100644 doc/devblog/day_509__filterdriver.mdwn
 create mode 100644 doc/devblog/day_50__grab_bag.mdwn
 create mode 100644 doc/devblog/day_50__grab_bag/comment_1_01846f6494fe843889391fd09fd127a0._comment
 create mode 100644 doc/devblog/day_50__grab_bag/comment_2_12736014aa2c1af81e4b83072505e7d5._comment
 create mode 100644 doc/devblog/day_510__v6_get_drop_index.mdwn
 create mode 100644 doc/devblog/day_510__v6_get_drop_index/comment_1_0e2eff8c8c3aaef3499b8f94b2733148._comment
 create mode 100644 doc/devblog/day_511__v6_improved_index_update.mdwn
 create mode 100644 doc/devblog/day_512__fixed_race.mdwn
 create mode 100644 doc/devblog/day_513__v6_reconciling_staged_changes.mdwn
 create mode 100644 doc/devblog/day_514__fixed_5_races_in_v6.mdwn
 create mode 100644 doc/devblog/day_514__v6_bug_review.mdwn
 create mode 100644 doc/devblog/day_515__S3_exporttree_with_versioning.mdwn
 create mode 100644 doc/devblog/day_516__S3_exporttree_with_versioning_continued.mdwn
 create mode 100644 doc/devblog/day_517__return_to_crowdfunding.mdwn
 create mode 100644 doc/devblog/day_518__S3_versioning_finishing_touches.mdwn
 create mode 100644 doc/devblog/day_518__S3_versioning_finishing_touches/comment_1_aed297f65b6e555f338fc622a8678c0f._comment
 create mode 100644 doc/devblog/day_518__S3_versioning_finishing_touches/comment_2_a981371786ba702ac616cd55b296bc1c._comment
 create mode 100644 doc/devblog/day_518__S3_versioning_finishing_touches/comment_3_08de1605f1aa8b042ba3c4b710939989._comment
 create mode 100644 doc/devblog/day_519__release_prep.mdwn
 create mode 100644 doc/devblog/day_51__direct_mode_guard_finished.mdwn
 create mode 100644 doc/devblog/day_520__storm_before_the_calm.mdwn
 create mode 100644 doc/devblog/day_521__newlines_in_filenames.mdwn
 create mode 100644 doc/devblog/day_522__multi.mdwn
 create mode 100644 doc/devblog/day_523__backlog.mdwn
 create mode 100644 doc/devblog/day_524__new_phone.mdwn
 create mode 100644 doc/devblog/day_52__slowly_but_surely.mdwn
 create mode 100644 doc/devblog/day_545__termux_improvements.mdwn
 create mode 100644 doc/devblog/day_546__deleted_40_thousand_lines_of_code.mdwn
 create mode 100644 doc/devblog/day_547__v6_almost_complete.mdwn
 create mode 100644 doc/devblog/day_548__hiding_missing_files.mdwn
 create mode 100644 doc/devblog/day_549__operating_on_hidden_files.mdwn
 create mode 100644 doc/devblog/day_549__operating_on_hidden_files/comment_1_29ded4a0926cca6f2485efc07c039b62._comment
 create mode 100644 doc/devblog/day_54__android_bisection_minions.mdwn
 create mode 100644 doc/devblog/day_54__android_bisection_minions/comment_1_bea8fbe2b87d4a4865b92fa796298fa0._comment
 create mode 100644 doc/devblog/day_550__a_plan_to_finish_v6.mdwn
 create mode 100644 doc/devblog/day_550__a_plan_to_finish_v6/comment_2_4a839c274832e43664d665e90b93146c._comment
 create mode 100644 doc/devblog/day_550__a_plan_to_finish_v6/comment_2_bae3f3303d61126a337f2dac71681e1d._comment
 create mode 100644 doc/devblog/day_551__v6_or_v7.mdwn
 create mode 100644 doc/devblog/day_551__v6_or_v7/comment_1_a46bd8dcc560a681405f82f13fc2e87e._comment
 create mode 100644 doc/devblog/day_551__v6_or_v7/comment_2_555009f3455129946b0238bc7e3bc52e._comment
 create mode 100644 doc/devblog/day_551__v6_or_v7/comment_3_0fa5ed098fa850fee538034f4787f35e._comment
 create mode 100644 doc/devblog/day_552_523__v7_release_prep.mdwn
 create mode 100644 doc/devblog/day_552_523__v7_release_prep/comment_1_31c6692172dbc1217d0a7ab90c074823._comment
 create mode 100644 doc/devblog/day_554__git-annex_user_survey_draft.mdwn
 create mode 100644 doc/devblog/day_555__git_annex_user_survey_live.mdwn
 create mode 100644 doc/devblog/day_556__snow_day.mdwn
 create mode 100644 doc/devblog/day_557__upgrade_bugfixes.mdwn
 create mode 100644 doc/devblog/day_558__new_horizons.mdwn
 create mode 100644 doc/devblog/day_559__surprising_win.mdwn
 create mode 100644 doc/devblog/day_55__fireside_porting.mdwn
 create mode 100644 doc/devblog/day_55__fireside_porting/comment_1_d690a52db82f9594d99ae65fe51e1f1a._comment
 create mode 100644 doc/devblog/day_560__into_the_weeds.mdwn
 create mode 100644 doc/devblog/day_561__better_benchmarking.mdwn
 create mode 100644 doc/devblog/day_562__on_to_metadata.mdwn
 create mode 100644 doc/devblog/day_563-564__log_conversion.mdwn
 create mode 100644 doc/devblog/day_565__bytestring_Key.mdwn
 create mode 100644 doc/devblog/day_566__stopping_place.mdwn
 create mode 100644 doc/devblog/day_567__neither_rain_nor_snow.mdwn
 create mode 100644 doc/devblog/day_568__release_day.mdwn
 create mode 100644 doc/devblog/day_569__another_week_another_release.mdwn
 create mode 100644 doc/devblog/day_56__git-annex_user_survey.mdwn
 create mode 100644 doc/devblog/day_570__brrr.mdwn
 create mode 100644 doc/devblog/day_571__survey_results.mdwn
 create mode 100644 doc/devblog/day_572__thinking_please_wait.mdwn
 create mode 100644 doc/devblog/day_573__starting_import_tree_implementation.mdwn
 create mode 100644 doc/devblog/day_574__weeds.mdwn
 create mode 100644 doc/devblog/day_575__core_of_import_tree_done.mdwn
 create mode 100644 doc/devblog/day_576__import_export.mdwn
 create mode 100644 doc/devblog/day_576__import_tree_details.mdwn
 create mode 100644 doc/devblog/day_576__import_tree_working.mdwn
 create mode 100644 doc/devblog/day_576__import_tree_working/comment_1_2ffd447e05466b806d36b761b4143e56._comment
 create mode 100644 doc/devblog/day_577__how_am_I_still_working_on_import_tree.mdwn
 create mode 100644 doc/devblog/day_578__import_tree_merged.mdwn
 create mode 100644 doc/devblog/day_579__bug_triage.mdwn
 create mode 100644 doc/devblog/day_57__mavericks.mdwn
 create mode 100644 doc/devblog/day_580__import_from_android.mdwn
 create mode 100644 doc/devblog/day_581__starting_import_from_S3.mdwn
 create mode 100644 doc/devblog/day_582__versioned_S3_import_working.mdwn
 create mode 100644 doc/devblog/day_583__S3_import_and_export_fully_working.mdwn
 create mode 100644 doc/devblog/day_584__matching_S3_histories.mdwn
 create mode 100644 doc/devblog/day_585__not_matching_S3_histories.mdwn
 create mode 100644 doc/devblog/day_586__wrapping_up_S3_import.mdwn
 create mode 100644 doc/devblog/day_586__wrapping_up_S3_import/s3history.png
 create mode 100644 doc/devblog/day_586__wrapping_up_S3_import/s3rename.png
 create mode 100644 doc/devblog/day_587__import_preferred_content.mdwn
 create mode 100644 doc/devblog/day_588__export_preferred_content.mdwn
 create mode 100644 doc/devblog/day_589__wrapping_up_import_export_preferred_content.mdwn
 create mode 100644 doc/devblog/day_58__urgle.mdwn
 create mode 100644 doc/devblog/day_58__urgle/comment_1_bd279f58f614b103a53215dfb0211007._comment
 create mode 100644 doc/devblog/day_590__toward_importing_from_externals.mdwn
 create mode 100644 doc/devblog/day_591__superscalar_pipelining.mdwn
 create mode 100644 doc/devblog/day_592__refactoring_start_messages.mdwn
 create mode 100644 doc/devblog/day_593__partial_success.mdwn
 create mode 100644 doc/devblog/day_594__finally_background_checksum_verification.mdwn
 create mode 100644 doc/devblog/day_594__finally_background_checksum_verification/comment_1_334c36d503abd06611a46cc102139446._comment
 create mode 100644 doc/devblog/day_595__cleaner_worker_pool_stages.mdwn
 create mode 100644 doc/devblog/day_596__back_from_summer_vacation.mdwn
 create mode 100644 doc/devblog/day_597__git-lfs_support.mdwn
 create mode 100644 doc/devblog/day_598__Windows_and_test_suite.mdwn
 create mode 100644 doc/devblog/day_599__dropping_direct_mode.mdwn
 create mode 100644 doc/devblog/day_59__release_day.mdwn
 create mode 100644 doc/devblog/day_5__gcrypt_special_remote_part_1.mdwn
 create mode 100644 doc/devblog/day_600__close_to_v7_default.mdwn
 create mode 100644 doc/devblog/day_601__v7_default.mdwn
 create mode 100644 doc/devblog/day_601__v7_default/comment_1_54af3bf0a521597d49bd8f8ef0ab5555._comment
 create mode 100644 doc/devblog/day_601__v7_default/comment_2_c2daec80c7834ebb62324d7169c6c158._comment
 create mode 100644 doc/devblog/day_602__sameas.mdwn
 create mode 100644 doc/devblog/day_603__sameas_working.mdwn
 create mode 100644 doc/devblog/day_604__unscheduled_release.mdwn
 create mode 100644 doc/devblog/day_605__well_Im_done_for_now.mdwn
 create mode 100644 doc/devblog/day_605__well_Im_done_for_now/comment_1_7366f7108495129680301d9b93bb8fb6._comment
 create mode 100644 doc/devblog/day_605__well_Im_done_for_now/comment_2_cd42103ea06ede8352176e66fc5434c5._comment
 create mode 100644 doc/devblog/day_605__well_Im_done_for_now/comment_3_774f264c555965461d621587cbdf8a1e._comment
 create mode 100644 doc/devblog/day_606__on_recent_events.mdwn
 create mode 100644 doc/devblog/day_607__v8_is_done.mdwn
 create mode 100644 doc/devblog/day_607__v8_is_done/comment_1_7326382d8ff23873c2fe0d6acd984454._comment
 create mode 100644 doc/devblog/day_607__v8_is_done/comment_2_802311f91808a13473aa99578a429497._comment
 create mode 100644 doc/devblog/day_607__v8_is_done/comment_3_7d3cad862be54dc5a39059f8b82834a6._comment
 create mode 100644 doc/devblog/day_608__easier_git-lfs_setup.mdwn
 create mode 100644 doc/devblog/day_608__easier_git-lfs_setup/comment_1_b72bea21d4445d12cade9f54ecc3767d._comment
 create mode 100644 doc/devblog/day_609__optimisation.mdwn
 create mode 100644 doc/devblog/day_60__damage_driven_development.mdwn
 create mode 100644 doc/devblog/day_610-611__ByteString_optimisation_early_days.mdwn
 create mode 100644 doc/devblog/day_610-611__ByteString_optimisation_early_days/comment_1_1601268fd4dba4df9cc3dc84932914a6._comment
 create mode 100644 doc/devblog/day_610-611__ByteString_optimisation_early_days/comment_2_21872150f9b2ff9cc08f94d52dbdf3a6._comment
 create mode 100644 doc/devblog/day_612__building_again.mdwn
 create mode 100644 doc/devblog/day_613__end-to-end_ByteString_milestone.mdwn
 create mode 100644 doc/devblog/day_614__bytestring_wrapping_up.mdwn
 create mode 100644 doc/devblog/day_615__new_year.mdwn
 create mode 100644 doc/devblog/day_616__remote_config_parsing.mdwn
 create mode 100644 doc/devblog/day_617__remote_config_parsing_continued.mdwn
 create mode 100644 doc/devblog/day_617__remote_config_parsing_continued/comment_1_d3ab2e85ea775cc6f39f12210374c35f._comment
 create mode 100644 doc/devblog/day_618__v8_merged.mdwn
 create mode 100644 doc/devblog/day_619__important_bugfix_release_and_v8_too.mdwn
 create mode 100644 doc/devblog/day_61__damage_driven_development__II.mdwn
 create mode 100644 doc/devblog/day_620__emergency_mode.mdwn
 create mode 100644 doc/devblog/day_621__back_to_normal-ish.mdwn
 create mode 100644 doc/devblog/day_622__behavior_changes.mdwn
 create mode 100644 doc/devblog/day_623__started_timeouts.mdwn
 create mode 100644 doc/devblog/day_624__timeouts_snag.mdwn
 create mode 100644 doc/devblog/day_625__import_tree_largefiles.mdwn
 create mode 100644 doc/devblog/day_626__performance_week.mdwn
 create mode 100644 doc/devblog/day_627__last_performance_work_for_now.mdwn
 create mode 100644 doc/devblog/day_628__external_key_backends.mdwn
 create mode 100644 doc/devblog/day_628__external_key_backends/comment_1_e6ff184245dd1a6cffff2ecdaeff6a66._comment
 create mode 100644 doc/devblog/day_629__async_external_special_remotes.mdwn
 create mode 100644 doc/devblog/day_62__upgrade_alerts.mdwn
 create mode 100644 doc/devblog/day_62__upgrade_alerts/comment_1_cdb44aaa1d2a784a72613cbf16038f89._comment
 create mode 100644 doc/devblog/day_62__upgrade_alerts/comment_2_b08bb946e4760d7f03b45c852c745b2e._comment
 create mode 100644 doc/devblog/day_630__dealing_with_git_changes.mdwn
 create mode 100644 doc/devblog/day_630__introspection_for_speed.mdwn
 create mode 100644 doc/devblog/day_631-632__memory_leak.mdwn
 create mode 100644 doc/devblog/day_633__ten_years.mdwn
 create mode 100644 doc/devblog/day_633__ten_years/comment_1_4842e53398d9ee668053ec6d4da426dd._comment
 create mode 100644 doc/devblog/day_633__ten_years/comment_2_48b09fc7e66cd9d9fb7c0f78f21c7ac5._comment
 create mode 100644 doc/devblog/day_634__new_features.mdwn
 create mode 100644 doc/devblog/day_635__stall_detection.mdwn
 create mode 100644 doc/devblog/day_636__stall_stall.mdwn
 create mode 100644 doc/devblog/day_637__thirdparty_of_borg.mdwn
 create mode 100644 doc/devblog/day_638__borg_special_remote_working.mdwn
 create mode 100644 doc/devblog/day_639__major_keys_database_milestone.mdwn
 create mode 100644 doc/devblog/day_63__leverage.mdwn
 create mode 100644 doc/devblog/day_640__finally_dealt_with_clock_skew.mdwn
 create mode 100644 doc/devblog/day_641__an_alternative_smudge_filter.mdwn
 create mode 100644 doc/devblog/day_641__an_alternative_smudge_filter/comment_1_ab7bbff67f34e217df5f0e75dedb7f2c._comment
 create mode 100644 doc/devblog/day_641__an_alternative_smudge_filter/comment_2_9bc08810306ceb39ed1f017e9f1d81e3._comment
 create mode 100644 doc/devblog/day_641__an_alternative_smudge_filter/comment_3_b9ffc711b4531b6f2b4af4efd1e9d9d6._comment
 create mode 100644 doc/devblog/day_641__an_alternative_smudge_filter/comment_4_b2a0a8f646197ce1826bc2e6859139b1._comment
 create mode 100644 doc/devblog/day_641__an_alternative_smudge_filter/comment_5_6a5932706a9fee097c3fdf2cd6808f1d._comment
 create mode 100644 doc/devblog/day_641__an_alternative_smudge_filter/comment_6_ad1d78a28887af24d77b2b9e3739b68a._comment
 create mode 100644 doc/devblog/day_641__an_alternative_smudge_filter/comment_7_3107429d7250a71584ea7947609207ec._comment
 create mode 100644 doc/devblog/day_641__an_alternative_smudge_filter/comment_8_45f97189936e7f477850aef9ef745538._comment
 create mode 100644 doc/devblog/day_641__an_alternative_smudge_filter/comment_9_3129a6da37ba7a1f8ee11441b7ed4d07._comment
 create mode 100644 doc/devblog/day_642__cost_model.mdwn
 create mode 100644 doc/devblog/day_642__cost_model/comment_1_36ecaafc1d7f6460758d6824a357432c._comment
 create mode 100644 doc/devblog/day_642__cost_model/comment_2_5bb7a20dd3141423ce4109d8fd4098c4._comment
 create mode 100644 doc/devblog/day_643__adjusted_view_branches.mdwn
 create mode 100644 doc/devblog/day_643__adjusted_view_branches/comment_1_5f2dfde34d4ef5048920f3fcabddbd56._comment
 create mode 100644 doc/devblog/day_643__adjusted_view_branches/comment_2_51e285666d42e08edbaf22699782392e._comment
 create mode 100644 doc/devblog/day_644-648__terminal_escape_sequences.mdwn
 create mode 100644 doc/devblog/day_649-650__speeding_up_repeated_imports.mdwn
 create mode 100644 doc/devblog/day_64__overkill.mdwn
 create mode 100644 doc/devblog/day_64__overkill/comment_1_e1db7678aae37af281d31ae211677786._comment
 create mode 100644 doc/devblog/day_64__overkill/comment_3_f7a96f0b6d942d0b59d9d0ec1b21c4bf._comment
 create mode 100644 doc/devblog/day_651__a_major_release__and_a_conference.mdwn
 create mode 100644 doc/devblog/day_65__wrapping_up_upgrades.mdwn
 create mode 100644 doc/devblog/day_66__upgrade_testing.mdwn
 create mode 100644 doc/devblog/day_67_thanksgiving_rush.mdwn
 create mode 100644 doc/devblog/day_68__bits_and_pieces.mdwn
 create mode 100644 doc/devblog/day_69__catching_up.mdwn
 create mode 100644 doc/devblog/day_6__gcrypt_fully_working.mdwn
 create mode 100644 doc/devblog/day_6__gcrypt_fully_working/comment_1_136bb7537a9ba93d400ce6f6ea1932ac._comment
 create mode 100644 doc/devblog/day_6__gcrypt_fully_working/comment_2_1f8faa65bbd56a12588b43a5bc822d96._comment
 create mode 100644 doc/devblog/day_70__preliminary_user_survey_analysis.mdwn
 create mode 100644 doc/devblog/day_71__that_was_unexpected.mdwn
 create mode 100644 doc/devblog/day_72__windows_webapp_not.mdwn
 create mode 100644 doc/devblog/day_73__EvilLinker.mdwn
 create mode 100644 doc/devblog/day_74__so_close.mdwn
 create mode 100644 doc/devblog/day_74__so_close/comment_1_b1aa185734c3d74830b81def4fe63bff._comment
 create mode 100644 doc/devblog/day_75__hallelujah.mdwn
 create mode 100644 doc/devblog/day_75__hallelujah/comment_1_df04c456e99d47743494a18c1badba8c._comment
 create mode 100644 doc/devblog/day_76__results.mdwn
 create mode 100644 doc/devblog/day_77__it_builds.mdwn
 create mode 100644 doc/devblog/day_78__desidetracked.mdwn
 create mode 100644 doc/devblog/day_79__catch_up.mdwn
 create mode 100644 doc/devblog/day_7__release_day.mdwn
 create mode 100644 doc/devblog/day_7__release_day/comment_1_12bb94d903868ecddb3e348c9c4afeaf._comment
 create mode 100644 doc/devblog/day_7__release_day/comment_2_d3e38d6f6bba179dab40d4d75ff061de._comment
 create mode 100644 doc/devblog/day_80__plumbing.mdwn
 create mode 100644 doc/devblog/day_81__more_standalone.mdwn
 create mode 100644 doc/devblog/day_81__more_standalone/comment_1_25ceb116406b55a8ff28f7b392806bc9._comment
 create mode 100644 doc/devblog/day_82__rpi_and_synology.mdwn
 create mode 100644 doc/devblog/day_82__rpi_and_synology/comment_1_d154ddcf22027fd06acf9da73e12c006._comment
 create mode 100644 doc/devblog/day_83__armel_webapp.mdwn
 create mode 100644 doc/devblog/day_84__ho_uh_oh.mdwn
 create mode 100644 doc/devblog/day_85__external_special_remote_protocol_types.mdwn
 create mode 100644 doc/devblog/day_86__external_special_remote_implementation.mdwn
 create mode 100644 doc/devblog/day_86__external_special_remote_implementation/comment_1_5116bcf4b60030cb46683df94a75d7ee._comment
 create mode 100644 doc/devblog/day_86__external_special_remote_implementation/comment_2_7b6e734f785fbd9db7883b63150023dc._comment
 create mode 100644 doc/devblog/day_87__external_special_remotes_done.mdwn
 create mode 100644 doc/devblog/day_88__lazy_sunday.mdwn
 create mode 100644 doc/devblog/day_89__reflections.mdwn
 create mode 100644 doc/devblog/day_8__ill.mdwn
 create mode 100644 doc/devblog/day_90__slow_start.mdwn
 create mode 100644 doc/devblog/day_91__wintry_mix.mdwn
 create mode 100644 doc/devblog/day_92-93__reconnection.mdwn
 create mode 100644 doc/devblog/day_94__leaks.mdwn
 create mode 100644 doc/devblog/day_95__reconnection_revisited.mdwn
 create mode 100644 doc/devblog/day_95__reconnection_revisited/comment_1_c1106e573fcf9f3d4524c0e4f4254790._comment
 create mode 100644 doc/devblog/day_95__reconnection_revisited/comment_2_40478739f95e0b56ce0103db6e405ef4._comment
 create mode 100644 doc/devblog/day_96__catching_up.mdwn
 create mode 100644 doc/devblog/day_97__exciting_telehash_possiblities.mdwn
 create mode 100644 doc/devblog/day_97__exciting_telehash_possiblities/comment_1_7c775d93cbeed0d553e224751d30fbaa._comment
 create mode 100644 doc/devblog/day_98__old_bug.mdwn
 create mode 100644 doc/devblog/day_99__catching_up_again.mdwn
 create mode 100644 doc/devblog/day_99__catching_up_again/comment_1_b871bf0606dc29be9b8c2e5dc150f708._comment
 create mode 100644 doc/devblog/day_99__catching_up_again/comment_2_c8363d47223e7bb899420e800bde3e27._comment
 create mode 100644 doc/devblog/day_9__Friday_the_13th.mdwn
 create mode 100644 doc/devblog/day_9__Friday_the_13th/comment_1_07195b4ec399ba1be6c8bdb3ae0fa50b._comment
 create mode 100644 doc/devblog/day__126-127__merge_fixes.mdwn
 create mode 100644 doc/devblog/day__228_new_AWS.mdwn
 create mode 100644 doc/devblog/day__329-330__a_rising_tide.mdwn
 create mode 100644 doc/devblog/moving_blogs.mdwn
 create mode 100644 doc/devblog/moving_blogs/comment_1_6caa7e67461a6ea5de8155ae9cf75fab._comment
 create mode 100644 doc/devblog/moving_blogs/comment_2_e3e2048fc2397b87a2f29c9fe49394cb._comment
 create mode 100644 doc/devblog/whither_XMPP.mdwn
 create mode 100644 doc/devblog/youtube-dl.mdwn
 create mode 100644 doc/devblog/youtube-dl/comment_1_ff062ea66ea50d2f31a92c25017bb135._comment
 create mode 100644 doc/devblog/youtube-dl_day_2.mdwn
 create mode 100644 doc/devblog/youtube-dl_day_3.mdwn
 create mode 100644 doc/devblog/youtube-dl_day_3/comment_1_bcf6ccc65f191c446ae4ea70c4e86c87._comment
 create mode 100644 doc/devblog/youtube-dl_day_3/comment_2_423d1896981b9d5de85c89fdcde2d1ab._comment
 create mode 100644 doc/devblog/youtube-dl_day_3/comment_3_c3735d169bfe81eaba5557197b1c0eb0._comment
 create mode 100644 doc/devblog/youtube-dl_day_3/comment_4_d19a698b28a5d6b583c527b9a909370d._comment
 create mode 100644 doc/direct_mode.mdwn
 create mode 100644 doc/direct_mode/comment_11_1c79c93f4b17cfc354ab920e3775cc60._comment
 create mode 100644 doc/direct_mode/comment_12_1b5218fdb6ee362d6df68ff1229590d4._comment
 create mode 100644 doc/direct_mode/comment_12_7d507b6f87085a19d8dd5014f580922b._comment
 create mode 100644 doc/direct_mode/comment_13_5169c5541970d3b3bc1e080e07539b22._comment
 create mode 100644 doc/direct_mode/comment_13_55108ac736ea450df89332ba5de4a208._comment
 create mode 100644 doc/direct_mode/comment_14_03a02e689d92faa596de98e02b2ffe28._comment
 create mode 100644 doc/direct_mode/comment_14_ff4ffc2aabc5fd174d7386ef13860f78._comment
 create mode 100644 doc/direct_mode/comment_15_1cd32456630b25d5aaa6d2763e6eb384._comment
 create mode 100644 doc/direct_mode/comment_15_599b2285d24ae1244a1945d572b2c397._comment
 create mode 100644 doc/direct_mode/comment_16_7f6805e090d0acd8a077b65214da5837._comment
 create mode 100644 doc/direct_mode/comment_17_e7c066fba8e28c61e8517c7a18a02457._comment
 create mode 100644 doc/direct_mode/comment_18_e46f70efa6d8d65d5ef81cdcbd844869._comment
 create mode 100644 doc/direct_mode/comment_19_f4f23d9be76fa3c201b6c67efab0d69c._comment
 create mode 100644 doc/direct_mode/comment_20_4d0077d7881df05dcbeb460bf7734b6b._comment
 create mode 100644 doc/direct_mode/comment_3_8020d74bddf0e38b0a297e5dae7c217b._comment
 create mode 100644 doc/direct_mode/comment_4_97c26bd82f623a3b2d56bab4afff0126._comment
 create mode 100644 doc/direct_mode/comment_5_42363bf0367f935b3eee8ad3d2eaf5cf._comment
 create mode 100644 doc/direct_mode/comment_6_5f03b1686c1fb3f7606a5bc724ac3812._comment
 create mode 100644 doc/direct_mode/comment_7_5355ac418bfb26e990762b80f4c36b77._comment
 create mode 100644 doc/direct_mode/comment_8_6cd15e2c5fd0bef48f60c6993322c2fc._comment
 create mode 100644 doc/distributed_version_control.mdwn
 create mode 100644 doc/download.mdwn
 create mode 100644 doc/download/comment_1_ec2578241a966cfcdd43f2a26a5c8709._comment
 create mode 100644 doc/download/comment_2_ee0d158ac59903737dbc4ef632f11fe3._comment
 create mode 100644 doc/download/comment_3_b59fc32a18a9fda8da120da82fade0a6._comment
 create mode 100644 doc/download/comment_4_bf102d87552f97ac293dd20f6822b84f._comment
 create mode 100644 doc/encryption.mdwn
 create mode 100644 doc/encryption/comment_10_6416ee43ffad1c306ef71247ae71a6c5._comment
 create mode 100644 doc/encryption/comment_11_30b926fbabe9a0089de1f55f6f9a5d2d._comment
 create mode 100644 doc/encryption/comment_12_51fd19bf174906b1dd1461efd6ce3798._comment
 create mode 100644 doc/encryption/comment_13_44c6a401526a6ee22d5f0316336d453b._comment
 create mode 100644 doc/encryption/comment_14_5832365e198284c93d4a505856932841._comment
 create mode 100644 doc/encryption/comment_14_fb6ec1f42789a62358605e293b678318._comment
 create mode 100644 doc/encryption/comment_16_5dc76b832ae6b1bb7f458bf8e2650e8e._comment
 create mode 100644 doc/encryption/comment_17_a2195a298f65e427fe8460c8bc380f99._comment
 create mode 100644 doc/encryption/comment_1_4257e3c4ae559f1c0595a903f738fd7e._comment
 create mode 100644 doc/encryption/comment_2_5c2da865082de475254ebfd53feb2d0a._comment
 create mode 100644 doc/encryption/comment_3_46e64e4856975706e06e2a012a5d8f67._comment
 create mode 100644 doc/encryption/comment_4_fe8b181adef9a39a039ff96a0d587188._comment
 create mode 100644 doc/encryption/comment_5_5c9897663aaa83ca39a7e8cb292a3fd1._comment
 create mode 100644 doc/encryption/comment_6_1756ce62906586f876a3491e5d9befde._comment
 create mode 100644 doc/encryption/comment_8_3849eb24c3682644e263bae107747dee._comment
 create mode 100644 doc/encryption/comment_8_66e81e89fd483ca95620522b0f63c4fd._comment
 create mode 100644 doc/encryption/comment_9_5ca10891d642392aaff342c1478b0550._comment
 create mode 100644 doc/favicon.ico
 create mode 100644 doc/footer/column_a.mdwn
 create mode 100644 doc/footer/column_b.mdwn
 create mode 100644 doc/forum.mdwn
 create mode 100644 doc/forum/--verbose_not_really_verbose__63__.mdwn
 create mode 100644 doc/forum/--verbose_not_really_verbose__63__/comment_1_9a7927c22a50addafc58028f34c48578._comment
 create mode 100644 doc/forum/--verbose_not_really_verbose__63__/comment_2_0c846317803019058f6b522bc9abd5a6._comment
 create mode 100644 doc/forum/--verbose_not_really_verbose__63__/comment_3_a360190fee9a9514f0ba201baeaecd7a._comment
 create mode 100644 doc/forum/--verbose_not_really_verbose__63__/comment_4_e4d75464af5ced1ce1f9539ddf8755f4._comment
 create mode 100644 doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__.mdwn
 create mode 100644 doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_1_924521ad5972046bac44d2e04ec296c7._comment
 create mode 100644 doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_2_e2a7f34a3ccc1b6467e6da611c067d66._comment
 create mode 100644 doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_3_f9a369a6ac69f091e6128990274d3228._comment
 create mode 100644 doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_4_91b422f8d55b68077245c606c4f7f87c._comment
 create mode 100644 doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_5_f6128fe75ff3453747f69f12e0fd0a5b._comment
 create mode 100644 doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_6_9b90b4031a5ed26c375903b33ed65a10._comment
 create mode 100644 doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_7_acd64ce1b08a97ddf730622272e9f611._comment
 create mode 100644 doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_8_9baacb14fc5eb449cb13e0b4a4995fb0._comment
 create mode 100644 doc/forum/4hr+_sync_on_new_remote___40__USB_drive__41__.mdwn
 create mode 100644 doc/forum/4hr+_sync_on_new_remote___40__USB_drive__41__/comment_1_01a6020d25826a3e0afb087899f6919c._comment
 create mode 100644 doc/forum/ARM_build_on_Zyxel_NAS.mdwn
 create mode 100644 doc/forum/ARM_build_on_Zyxel_NAS/comment_1_38f38755c0afd76a2b968836fec395e8._comment
 create mode 100644 doc/forum/ARM_build_on_Zyxel_NAS/comment_2_44c8f1af0cbe9ad51794e6d8d16be627._comment
 create mode 100644 doc/forum/ARM_build_on_Zyxel_NAS/comment_3_b4f6e5ac672e8ece36cceb74ff3315dd._comment
 create mode 100644 doc/forum/A_git-annex_helper.mdwn
 create mode 100644 doc/forum/A_little_help_with_headless_server_configuration.mdwn
 create mode 100644 doc/forum/A_little_help_with_headless_server_configuration/comment_1_d32e28e8dcacf89eb357b78aefded274._comment
 create mode 100644 doc/forum/A_question_an_the_nomad_use_cases__58___files_to_fetch__44___files_to_delete__44___files_to_keep__63__.mdwn
 create mode 100644 doc/forum/A_question_an_the_nomad_use_cases__58___files_to_fetch__44___files_to_delete__44___files_to_keep__63__/comment_1_fe291cd6cd8e2d5b8e23f8e3689d824b._comment
 create mode 100644 doc/forum/A_question_an_the_nomad_use_cases__58___files_to_fetch__44___files_to_delete__44___files_to_keep__63__/comment_2_f0dbc3c723999bf0f22502e3a89d1d4a._comment
 create mode 100644 doc/forum/A_really_stupid_question.mdwn
 create mode 100644 doc/forum/A_really_stupid_question/comment_1_40e02556de0b00b94f245a0196b5a89f._comment
 create mode 100644 doc/forum/A_tiny_filesystem__63__.mdwn
 create mode 100644 doc/forum/A_tiny_filesystem__63__/comment_1_993e3f5dbe4bcbb5b7bd9e08ab9554f3._comment
 create mode 100644 doc/forum/A_tiny_filesystem__63__/comment_2_af57591d42868c8aa1cc1eda43ca8b98._comment
 create mode 100644 doc/forum/A_tiny_filesystem__63__/comment_3_3869c0472b50d7cf5e29ac0720f4f20f._comment
 create mode 100644 doc/forum/Accessing_files_directly_on__a_USB_device.mdwn
 create mode 100644 doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote.mdwn
 create mode 100644 doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_1_b2f7b4aa5e7c859de9741db440292365._comment
 create mode 100644 doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_2_6450ee0b5729beec155fbe0ce304e223._comment
 create mode 100644 doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_3_9d8d03bda09596d03d9cfb7138a152f0._comment
 create mode 100644 doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_4_650ebbe4e7b57361a42882f3092122f0._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository.mdwn
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_10_7eb66e3806f9524e043fae2da9d57d64._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_11_f0165d66865ad14f7eb5d50e900c1df4._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_12_0e7ea5161b6da6e9bb9425bdb953de33._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_13_f804b9bf71f7d04bd23ce32d813dc340._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_1_6de649d38febd2240eb5b703da77c2d6._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_2_7e8dd09915ddc3267377e900891cb02c._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_3_80eae4a73f38d1a7e35f97c33b6401f8._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_4_5ec13e98d3ecb69426e974d34f712f9b._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_5_dccbf5793998c6381e23eb8ff6497ebf._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_6_42d923916232c81f3b8bdbefa34a89d3._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_7_43a0a7d222faee582aeb3150a59cef87._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_8_ec1024235c1c74c113483a833df84654._comment
 create mode 100644 doc/forum/Accessing_files_in_bare_repository/comment_9_c156b8c1ae0f2905566bbdb13b84e577._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository.mdwn
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/bugs/direct_mode_sync_should_avoid_git_commit.mdwn
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_10_06dae5709750ea1da4f7fdbee4e84efc._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_11_2069c5c41882ae0a1973fb7da583b60e._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_12_b35e3a87c30974eedd71ebe52ecbed96._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_13_84e026f9bda87bfd12a3769dcef77f8b._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_14_b2ac2ea300a5026832b40a1a6b27a7cd._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_1_ed3534196164c6736a8dbf21c65c119d._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_2_1e29bcf568f02765c48f0eac6c640673._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_3_9ea6803a94b1de15079a3fa20d59c9af._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_4_3fae5a7fa5d99d0eb4473adb43e7f6f5._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_5_57a5b73cff480266355e75c7bdc762c2._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_6_bbcf5e863c8f152e1079536e9011a404._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_7_fdcd144c22601bdf98ff844254b0120d._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_8_b77243e765b2af7ba71e963fcb5cbbb1._comment
 create mode 100644 doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_9_cb0815e96ee211d4778f2e7a4274e855._comment
 create mode 100644 doc/forum/Add_a___34__local__34___remote.mdwn
 create mode 100644 doc/forum/Add_a___34__local__34___remote/comment_1_c68ad724b465c4be5243be687168c0b3._comment
 create mode 100644 doc/forum/Add_annex_files_outside_git_root_directory.mdwn
 create mode 100644 doc/forum/Add_annex_files_outside_git_root_directory/comment_1_3d7c8917633a6632f22385b8f7a98ccf._comment
 create mode 100644 doc/forum/Add_annex_files_outside_git_root_directory/comment_2_312a57883d809857a69216fa47e04f17._comment
 create mode 100644 doc/forum/Add_file_to_git_index_while_in_direct_mode.mdwn
 create mode 100644 doc/forum/Add_file_to_git_index_while_in_direct_mode/comment_1_3eb43a983eba09f500b776f75b299341._comment
 create mode 100644 doc/forum/Add_file_to_git_index_while_in_direct_mode/comment_2_6945d9e930e7385f0abe6538622a9aa3._comment
 create mode 100644 doc/forum/Add_file_to_git_index_while_in_direct_mode/comment_3_8f77b5dcf582e88099b2e6e77563fb11._comment
 create mode 100644 doc/forum/Add_files_to_direct_mode_repos.mdwn
 create mode 100644 doc/forum/Add_files_to_direct_mode_repos/comment_1_41d632853d3160899b04da7e4b95475e._comment
 create mode 100644 doc/forum/Added_file_to_annex_but_it_doesn__39__t_show_up_in_here.mdwn
 create mode 100644 doc/forum/Added_file_to_annex_but_it_doesn__39__t_show_up_in_here/comment_1_6757bfdc2876b5b763c338ad414e74dc._comment
 create mode 100644 doc/forum/Adding_a_URL_from_wayback_machine.mdwn
 create mode 100644 doc/forum/Adding_a_URL_from_wayback_machine/comment_1_bc78c24becbf758da7873cdf01e2adc5._comment
 create mode 100644 doc/forum/Adding_a_URL_from_wayback_machine/comment_2_6df0501b103a7cfcd1eaa4120f7fa818._comment
 create mode 100644 doc/forum/Adding_a_URL_from_wayback_machine/comment_3_aefbb393c11ab233d145311409d405c7._comment
 create mode 100644 doc/forum/Adding_a_mounted_network.mdwn
 create mode 100644 doc/forum/Adding_a_mounted_network/comment_1_9b4bab6177856569adfec26ada6b01cd._comment
 create mode 100644 doc/forum/Adding_a_mounted_network/comment_2_ae3d4ac918ef002ead859ed0c962ae32._comment
 create mode 100644 doc/forum/Adding_a_mounted_network/comment_3_559cfec9210f8c86de6ee13de0ec2175._comment
 create mode 100644 doc/forum/Adding_existing_S3_bucket_to_sync_with.mdwn
 create mode 100644 doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_1_30b9a70d367dd5b8781e9a86e42d4c3e._comment
 create mode 100644 doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_2_a8525c1a7e5f89c30c9503fe8bfed02e._comment
 create mode 100644 doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_3_c3878989f74e740c0ed42f440750f3a4._comment
 create mode 100644 doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_4_c06cc86496f9d4c0c42a8c89aa5a7b35._comment
 create mode 100644 doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_5_0a1c2dd0929511ff824be8de2c8d85eb._comment
 create mode 100644 doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_6_1444c2f89885f028f20a4d3ce225a403._comment
 create mode 100644 doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_7_1c30944010d541096baff18198a5560d._comment
 create mode 100644 doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase.mdwn
 create mode 100644 doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_1_67d8488c421da24702fea4c37afe74c3._comment
 create mode 100644 doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_2_f9fb8b2ad05a17e8451d434c783fc7d7._comment
 create mode 100644 doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_3_71bbf490cfa2cbfab322aab865d93261._comment
 create mode 100644 doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_4_66dbcc3600c1df2df03896935dfce9c0._comment
 create mode 100644 doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_5_665bdcd79b486f8d2604eb6de5c10b2b._comment
 create mode 100644 doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_6_cf89b44d67752edabfbf577d1212e7ad._comment
 create mode 100644 doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_7_a4e2f0e65a9dc92fc4dd85183e8f8090._comment
 create mode 100644 doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite.mdwn
 create mode 100644 doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_1_e0784676aab3388254cdc9e7dd2d97e7._comment
 create mode 100644 doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_2_d9a7d2669d1524cab71e7e3139631f2a._comment
 create mode 100644 doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_3_a0fdcd19954a38141b1dc2a51638ba30._comment
 create mode 100644 doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_3_bc36d8f7b1d4d475018a236f71d06bb5._comment
 create mode 100644 doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_5_a02c3cd804c2f6fd80d8839cc5c81af4._comment
 create mode 100644 doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_6_703ecd8e1dfc5b5b58655e27c9db838a._comment
 create mode 100644 doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_7_dbe40fef2ba65cc0f1c20f41f2daab4d._comment
 create mode 100644 doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_8_d8620ce7b3dbb81c0d3d0b09ded1deb0._comment
 create mode 100644 doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_9_6a43f52449c4a38a986772ec9d65f9d5._comment
 create mode 100644 doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows.mdwn
 create mode 100644 doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_1_e40e129fbdae305ad48f810c578fa69f._comment
 create mode 100644 doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_2_3f2556b0a0cd8b7523aed1bea1be8484._comment
 create mode 100644 doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_3_d50b99393009ba4adf2040f1d5d5078b._comment
 create mode 100644 doc/forum/Adding_public_key_to_hybrid_encrypted_repo_causes___34__remote_already_exists__34___error.mdwn
 create mode 100644 doc/forum/Adding_public_key_to_hybrid_encrypted_repo_causes___34__remote_already_exists__34___error/comment_1_fe2f0e7a4688865faf21c2c0467852b7._comment
 create mode 100644 doc/forum/Adding_selected_big_binaries_recursively.mdwn
 create mode 100644 doc/forum/Adding_selected_big_binaries_recursively/comment_1_6ff6031a5a44caf17f36c3569cca5512._comment
 create mode 100644 doc/forum/Adding_selected_big_binaries_recursively/comment_2_872bef6902ddb362b62d5e9ec1afe864._comment
 create mode 100644 doc/forum/Adding_selected_big_binaries_recursively/comment_3_4be5ca7a22db19a3152b54bee943f58c._comment
 create mode 100644 doc/forum/Adding_selected_big_binaries_recursively/comment_4_83b62738f79c434f5a2cacc9316e5d2b._comment
 create mode 100644 doc/forum/Adding_the_same_content_under_different_file_names.mdwn
 create mode 100644 doc/forum/Adding_the_same_content_under_different_file_names/comment_1_7c659668f62577612eaf8f463383a185._comment
 create mode 100644 doc/forum/Adding_the_same_content_under_different_file_names/comment_2_217052fe47822f73ffc765afd6386a7e._comment
 create mode 100644 doc/forum/Advice_needed__58___git-annex_slows_down_my_macbook.mdwn
 create mode 100644 doc/forum/Advice_needed__58___git-annex_slows_down_my_macbook/comment_1_af8ab0a47cd379fcb1445e50782ad086._comment
 create mode 100644 doc/forum/Advice_needed__58___git-annex_slows_down_my_macbook/comment_2_a7202bcbdda36a3801833d2432db1965._comment
 create mode 100644 doc/forum/All_repos_on_same_filesystem.mdwn
 create mode 100644 doc/forum/All_repos_on_same_filesystem/comment_1_a6666a89f62dc7e2d40e028782e5a25a._comment
 create mode 100644 doc/forum/Alternative_modes_for_annex_repos.mdwn
 create mode 100644 doc/forum/Alternative_to_Tor_for_remote_pairing__63__.mdwn
 create mode 100644 doc/forum/Alternative_to_Tor_for_remote_pairing__63__/comment_1_39417a8bd5e6834041d759ea3666d894._comment
 create mode 100644 doc/forum/Alternative_to_XMPP_on_Windows__63__.mdwn
 create mode 100644 doc/forum/Alternative_to_XMPP_on_Windows__63__/comment_1_4084abf5b26fcc92e577eea34c331a15._comment
 create mode 100644 doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get.mdwn
 create mode 100644 doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_1_7f62ed07749308a46f0028a9586a10a4._comment
 create mode 100644 doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_2_a0c58c65091f36b426e016c700ec2f1c._comment
 create mode 100644 doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_3_102047d2676af0bc62791fa0f18ac49f._comment
 create mode 100644 doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_4_717078ebeb3b69dd9c52c8abe457824a._comment
 create mode 100644 doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_5_0630abbcb27e1f9dc5e9269b09a99b09._comment
 create mode 100644 doc/forum/Always_sync_all_content_to_remote.mdwn
 create mode 100644 doc/forum/Always_sync_all_content_to_remote/comment_1_241c19cad6249fbd0832c76028c8b373._comment
 create mode 100644 doc/forum/Always_sync_all_content_to_remote/comment_4_3eda671cea0f8869f1aac0194cae7146._comment
 create mode 100644 doc/forum/Ambigous_argument___40__unknown_revision_or_path__41__.mdwn
 create mode 100644 doc/forum/Ambiguous_repo_names__63__.mdwn
 create mode 100644 doc/forum/Ambiguous_repo_names__63__/comment_1_9695c42113ad6c873b1eae1c1f04e70a._comment
 create mode 100644 doc/forum/Android_-_ext3__47__4__47__....mdwn
 create mode 100644 doc/forum/Android__58___Cabal_hell.mdwn
 create mode 100644 doc/forum/Android__58___Cabal_hell/comment_1_34e869c1092f2885f54f627fb77a6057._comment
 create mode 100644 doc/forum/Android__58___Cabal_hell/comment_2_ed5b2b37d37278458fdf2dc37539e741._comment
 create mode 100644 doc/forum/Android__58___Cabal_hell/comment_3_fe71aa84ed5e1bb1e19a7d0f4e42eccd._comment
 create mode 100644 doc/forum/Android__58___Cabal_hell/comment_4_da004cee7c0cf5617291dbd520af2e96._comment
 create mode 100644 doc/forum/Android__58___Cabal_hell/comment_5_12e2cb09ac2ee07b392cd9be064a3cbe._comment
 create mode 100644 doc/forum/Android__58___Encrypted_Remotes__63__.mdwn
 create mode 100644 doc/forum/Android__58___Encrypted_Remotes__63__/comment_1_6b16cd372a9bd4f99d4c8b09a82ce3ed._comment
 create mode 100644 doc/forum/Android__58___git_annex_sync_--content_not_run_in_all_repos__63__.mdwn
 create mode 100644 doc/forum/Android__58___git_annex_sync_--content_not_run_in_all_repos__63__/comment_1_aff6a984ab076433fbce32bacae6660e._comment
 create mode 100644 doc/forum/Android__58___git_annex_sync_--content_not_run_in_all_repos__63__/comment_2_5b1565955ed88554e5ef4a00c0f4a754._comment
 create mode 100644 doc/forum/Android__58___is_constant_high_cpu_usage_to_be_expected__63__.mdwn
 create mode 100644 doc/forum/Android__58___is_constant_high_cpu_usage_to_be_expected__63__/comment_1_7880fc38792a1fcbf3e5c47e8bcaabce._comment
 create mode 100644 doc/forum/Android__58___is_constant_high_cpu_usage_to_be_expected__63__/comment_2_840fbce18b4fdec21ee557fdf52c366e._comment
 create mode 100644 doc/forum/Android__58___repository_is_not_initialized_for_use_by_.mdwn
 create mode 100644 doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_1_ef3dbc83f24f00c49b7d7cf626af44aa._comment
 create mode 100644 doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_2_719abfa1dc9a64b1245376dedbccca6e._comment
 create mode 100644 doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_3_027130ce7e8a56551e1d16cbbae6d115._comment
 create mode 100644 doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_4_99d78dca3534c4d54f6925a095f1d43f._comment
 create mode 100644 doc/forum/Android__58___unusably_slow_with_moderately_sized_repositories.mdwn
 create mode 100644 doc/forum/Android__58___unusably_slow_with_moderately_sized_repositories/comment_3_c5c655ee3ec2501c1c3c60fd83574914._comment
 create mode 100644 doc/forum/Android___34__Bad_system_call__34__.mdwn
 create mode 100644 doc/forum/Android___34__Bad_system_call__34__/comment_1_d53c57d0f42e3eb5efd6ff5d47b73698._comment
 create mode 100644 doc/forum/Android___34__Bad_system_call__34__/comment_2_74a33b262400ed74a7e0e3bbeac651d5._comment
 create mode 100644 doc/forum/Android___34__Bad_system_call__34__/comment_3_818a652075a2e283e0be57a11e10a14b._comment
 create mode 100644 doc/forum/Android_version_does_not_sync.mdwn
 create mode 100644 doc/forum/Android_version_does_not_sync/comment_1_ed9e33eef2c6d651847dca9d3f7a63f6._comment
 create mode 100644 doc/forum/Android_version_does_not_sync/comment_2_4eafd3e989611f835c489b379bd6ec8a._comment
 create mode 100644 doc/forum/Android_version_does_not_sync/comment_3_2a4efec37015ea44509e7ed16b36a72d._comment
 create mode 100644 doc/forum/Android_version_does_not_sync/comment_4_1ad06842dd96be14e66cde67f32d50f8._comment
 create mode 100644 doc/forum/Annex_contents_just_disappeared__63__.mdwn
 create mode 100644 doc/forum/Annex_contents_just_disappeared__63__/comment_1_4ab5ca00f912c0c95fabc10f2d9600d3._comment
 create mode 100644 doc/forum/Annex_contents_just_disappeared__63__/comment_2_657f737c5d64d440aa133ddb41408fbc._comment
 create mode 100644 doc/forum/Annex_contents_just_disappeared__63__/comment_3_9b4c35feb14b37d43d053d7430da9abf._comment
 create mode 100644 doc/forum/Annex_contents_just_disappeared__63__/comment_4_c3625409652bff5f2165260803269a8a._comment
 create mode 100644 doc/forum/Annex_dropping_files.mdwn
 create mode 100644 doc/forum/Annex_dropping_files/comment_1_62fbea95248fda2ff075b5a8952a728f._comment
 create mode 100644 doc/forum/Annex_keeps_dropping_content.mdwn
 create mode 100644 doc/forum/Annex_slow_on_Windows__47__direct_mode.mdwn
 create mode 100644 doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_1_d80839f4582fc2a6269db31e30e1dbab._comment
 create mode 100644 doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_2_593e1e01b70a2b6a15ad6bca09a80c7b._comment
 create mode 100644 doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_3_c4e4c596f31aa97645fe1e1527dc2c31._comment
 create mode 100644 doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_4_92db0b99ada9af15a5383da41397ebd7._comment
 create mode 100644 doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_5_3d628c9db9ebdfd5bff92af105c47719._comment
 create mode 100644 doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_6_db7965fa928c093233769ed52b2fcd43._comment
 create mode 100644 doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_7_674f52c5e5484207db403b18efc986c6._comment
 create mode 100644 doc/forum/Annex_v7_repos_and_plain_git_files.mdwn
 create mode 100644 doc/forum/Annex_v7_repos_and_plain_git_files/comment_1_3bf39b5e6990d4343d9154465d951a77._comment
 create mode 100644 doc/forum/Annex_v7_repos_and_plain_git_files/comment_2_a0628a013b57c00ea449b40b93edd385._comment
 create mode 100644 doc/forum/Annex_v7_repos_and_plain_git_files/comment_3_6095eaa58aa298aca72237381f567ffb._comment
 create mode 100644 doc/forum/Annex_v7_repos_and_plain_git_files/comment_4_fd1a3658ed6f3b6af2297c768b3f1ac2._comment
 create mode 100644 doc/forum/Annex_v7_repos_and_plain_git_files/comment_5_f47fec91d4ceebe653bc3fb221e2f8df._comment
 create mode 100644 doc/forum/Annex_v7_repos_and_plain_git_files/comment_6_21648eecfaf9673b25d40327d11f7b59._comment
 create mode 100644 doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__.mdwn
 create mode 100644 doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_1_0d87a7d0f6ae556deb999403a2fb5461._comment
 create mode 100644 doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_2_c7fc9be88dad09f71774664b233bc8a3._comment
 create mode 100644 doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_3_89330ea5d2754d59766a096e0c35d791._comment
 create mode 100644 doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_4_4cfc6b550dfb24c8468df97428d2cf8a._comment
 create mode 100644 doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_5_82ce026c2dc9627ca2f1563caedfa458._comment
 create mode 100644 doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_6_dfca53829fbe845f7f56e35638faf9fc._comment
 create mode 100644 doc/forum/Any_way_to_add_a_folder_called___34__.git__34___to_git-annex__63__.mdwn
 create mode 100644 doc/forum/Any_way_to_add_a_folder_called___34__.git__34___to_git-annex__63__/comment_1_51f4392e718d857e2f155d6217727a53._comment
 create mode 100644 doc/forum/Any_way_to_add_a_folder_called___34__.git__34___to_git-annex__63__/comment_2_9698c4a8f0d8785ee89a6228e0e85ca9._comment
 create mode 100644 doc/forum/Apple_M1_Silicon.mdwn
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_10_5646c616f1897c797ce383f6d4210ce4._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_11_72129be313d82db95d4fe109793fc3fc._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_12_b62bcd53f260613fc9043008f0e9df19._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_13_c4ea06ee4c929f171eb6eaea0947bfe7._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_14_540e6d6f579174bb953824817f5822aa._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_1_e2aaf539d43951a20ea48d827082fe83._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_2_eeed553a1684f0b4ed07e5a7de62db5f._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_3_bed7d9e5565c6bb462e2ba8f4d815725._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_4_07c410bacefa5da582ce2064ef345def._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_5_2efc89b2c4f3ff408ccd015f297d743b._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_6_0fc6e261c00f1df8698c92c8de6f3a27._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_7_c60e046cb8b138aee16af2d4c66c803c._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_8_4620929361fb5ad8faea15ed3905d67f._comment
 create mode 100644 doc/forum/Apple_M1_Silicon/comment_9_d77519ba5ca217cb3ec6348567731b9d._comment
 create mode 100644 doc/forum/Archive_USB_drive_not_working_as_documented.mdwn
 create mode 100644 doc/forum/Archive_USB_drive_not_working_as_documented/comment_1_59de1e101e5e427abb1df3a71c6f1b04._comment
 create mode 100644 doc/forum/Archive_USB_drive_not_working_as_documented/comment_2_3541fdd31d398a494a8fa452ac2c277f._comment
 create mode 100644 doc/forum/Assistance_required_for_a_specific_workflow.mdwn
 create mode 100644 doc/forum/Assistance_required_for_a_specific_workflow/comment_1_7c803b6f2759f6fa74c514e79a26f369._comment
 create mode 100644 doc/forum/Assistance_required_for_a_specific_workflow/comment_2_4a00c4307a492ffe736cf981ced9f57a._comment
 create mode 100644 doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__.mdwn
 create mode 100644 doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__/comment_1_44c97c54066ca0487d8903cc01a356a3._comment
 create mode 100644 doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__/comment_2_98eb671596e84466e24004f55724660a._comment
 create mode 100644 doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__/comment_3_e3c506ae998a8ae681727d3c432f95d2._comment
 create mode 100644 doc/forum/Assistant_Droping_Files.mdwn
 create mode 100644 doc/forum/Assistant__58___configure_auto-sync.mdwn
 create mode 100644 doc/forum/Assistant__58___configure_auto-sync/comment_1_c8cabd38114582bbdbad49f2d81959d7._comment
 create mode 100644 doc/forum/Assistant__58___run_with___34__sync_--fast__34___to_automatically_use_only_available_remotes.mdwn
 create mode 100644 doc/forum/Assistant_fails_to_authenticate_to_rsync_remote.mdwn
 create mode 100644 doc/forum/Assistant_fails_to_authenticate_to_rsync_remote/comment_1_fdbadd7ae4c0236301944136ac62346a._comment
 create mode 100644 doc/forum/Assistant_fails_to_authenticate_to_rsync_remote/comment_2_a395406abd3eb4cf07dc6467506a7e77._comment
 create mode 100644 doc/forum/Assistant_in_windows_only_watches_one_repo_on_startup.mdwn
 create mode 100644 doc/forum/Assistant_in_windows_only_watches_one_repo_on_startup/comment_1_48b43fe2ec186cea5930bf641522081d._comment
 create mode 100644 doc/forum/Assistant_invariants.mdwn
 create mode 100644 doc/forum/Assistant_invariants/comment_1_0426e10ffe45f42658d89756ea5ef5be._comment
 create mode 100644 doc/forum/Assistant_invariants/comment_2_7d3990582435203e0f94a8a3a2f1ef5a._comment
 create mode 100644 doc/forum/Assistant_loosing_advantages__63__.mdwn
 create mode 100644 doc/forum/Assistant_loosing_advantages__63__/comment_1_cdbc827d9e00aeeaefafe45de64b8d2c._comment
 create mode 100644 doc/forum/Assistant_not_syncing_to_Rsync.mdwn
 create mode 100644 doc/forum/Assistant_not_syncing_to_Rsync/comment_1_2178a7fc0d66643e84597b0938ef65f2._comment
 create mode 100644 doc/forum/Assistant_not_syncing_to_Rsync/comment_2_650651398443e128c2adc6a2a2d320d0._comment
 create mode 100644 doc/forum/Assistant_not_syncing_to_Rsync/comment_3_e6d0c9620b148acc72342862a8b4cfef._comment
 create mode 100644 doc/forum/Assistant_not_syncing_to_Rsync/comment_4_b91f9febdb8b69d8b487ba4ea08c119a._comment
 create mode 100644 doc/forum/Assistant_not_syncing_to_Rsync/comment_5_c5ad7c1546a17d8459c995c9c8c26414._comment
 create mode 100644 doc/forum/Assistant_not_syncing_to_Rsync/comment_6_4c12587f972eced91c5128d4885800b5._comment
 create mode 100644 doc/forum/Assistant_not_syncing_to_Rsync/comment_7_6ecaaee9316bcf0c65688676d60fc055._comment
 create mode 100644 doc/forum/Assistant_not_syncing_to_Rsync/comment_8_daa9a9a6188afa0394833e1b682f7cd4._comment
 create mode 100644 doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas.mdwn
 create mode 100644 doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_1_a8effe196e4a040630d183803768c5a1._comment
 create mode 100644 doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_2_9f032e43b132bcad656e1337ab2551ad._comment
 create mode 100644 doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_3_5a09f65c77dce3c62236c13aa90a1191._comment
 create mode 100644 doc/forum/Auto_archiving.mdwn
 create mode 100644 doc/forum/Auto_ignore_non-reachable_repo.mdwn
 create mode 100644 doc/forum/Auto_ignore_non-reachable_repo/comment_1_40d7aab5e43c75ede3414ed48f0c7066._comment
 create mode 100644 doc/forum/Auto_ignore_non-reachable_repo/comment_2_74c297d8d5e9f7d131c461ed5e803071._comment
 create mode 100644 doc/forum/Auto_sync_with_music_player.mdwn
 create mode 100644 doc/forum/Auto_sync_with_music_player/comment_1_81ad1c15cfd753531c01dae8945d1caf._comment
 create mode 100644 doc/forum/Auto_sync_with_music_player/comment_2_a15e3f298c3d3faa5b3295355f9bb794._comment
 create mode 100644 doc/forum/Auto_sync_with_music_player/comment_3_99f65a0efaf5d5f9b8ff530acc122860._comment
 create mode 100644 doc/forum/Auto_update_not_working.mdwn
 create mode 100644 doc/forum/Automatic___96__git_annex_get__96___after_invalidation_of_local_files_due_to_external_modification__63__.mdwn
 create mode 100644 doc/forum/Automatic___96__git_annex_get__96___after_invalidation_of_local_files_due_to_external_modification__63__/comment_1_dab1099ee56541c194de319c593f1268._comment
 create mode 100644 doc/forum/Automatic___96__git_annex_get__96___after_invalidation_of_local_files_due_to_external_modification__63__/comment_2_b5faccf132fb47e3cda778a6600fd9ef._comment
 create mode 100644 doc/forum/Automatic_commit_messages_for_git_annex_sync.mdwn
 create mode 100644 doc/forum/Automatic_commit_messages_for_git_annex_sync/comment_1_ea2ec57bc695da4df8a30a35d433959d._comment
 create mode 100644 doc/forum/Automatic_commit_messages_for_git_annex_sync/comment_2_af71f53dbbca35d5a5c66ff131887ada._comment
 create mode 100644 doc/forum/Automatically_dropping_files.mdwn
 create mode 100644 doc/forum/Automatically_dropping_files/comment_1_f5fc608f9cb0edf3272b586b62050637._comment
 create mode 100644 doc/forum/Automatically_syncronise_centralised_repository.mdwn
 create mode 100644 doc/forum/Automatically_syncronise_centralised_repository/comment_1_6a2047daa9faf4309d2ed27d5cc48b76._comment
 create mode 100644 doc/forum/Automatically_syncronise_centralised_repository/comment_2_3be7b45bc2284019f17a81375637a576._comment
 create mode 100644 doc/forum/Autostart_the_assistant.mdwn
 create mode 100644 doc/forum/Autostart_the_assistant/comment_1_a5421711102fb1649d98d916e5ced86b._comment
 create mode 100644 doc/forum/Autostart_the_assistant/comment_2_df70bd0f5caab43503a3c9d805323289._comment
 create mode 100644 doc/forum/Autostart_the_assistant/comment_3_42de896f64adb49c60ec3f7e0aeebda6._comment
 create mode 100644 doc/forum/Autostart_the_assistant/comment_4_5c6e085b1077b0792a1805f032ac6a4b._comment
 create mode 100644 doc/forum/Back_up_videos_to_youtube__63__.mdwn
 create mode 100644 doc/forum/Back_up_videos_to_youtube__63__/comment_1_e81f72bfe678e2aceded518338be1473._comment
 create mode 100644 doc/forum/Back_up_videos_to_youtube__63__/comment_2_6cb19f9c371d7cb046302ed193c77489._comment
 create mode 100644 doc/forum/Back_up_videos_to_youtube__63__/comment_3_ccb5cb5fe520b3f2a4822d85c246296f._comment
 create mode 100644 doc/forum/Back_up_videos_to_youtube__63__/comment_4_303b4f755dd117f8b22c98669e7bf932._comment
 create mode 100644 doc/forum/Backend_migration_and_special_remotes.mdwn
 create mode 100644 doc/forum/Backend_migration_and_special_remotes/comment_1_cf6d45c43b14719fc5ea41d0cbfb612d._comment
 create mode 100644 doc/forum/Backing_up_photos_to_the_cloud.mdwn
 create mode 100644 doc/forum/Backup_of_git-annex_repos.mdwn
 create mode 100644 doc/forum/Backup_of_git-annex_repos/comment_1_ed90e524606e394f7669fcba10846930._comment
 create mode 100644 doc/forum/Backup_of_whole_Linux_system.mdwn
 create mode 100644 doc/forum/Backup_of_whole_Linux_system/comment_1_bf48d93872bfadb5daaf02a10e699b79._comment
 create mode 100644 doc/forum/Backup_of_whole_Linux_system/comment_2_af49edff9174c2ee17391e78ac97d5f3._comment
 create mode 100644 doc/forum/Balanced_Parity.mdwn
 create mode 100644 doc/forum/Bare_repo_on_USB_drive_not_providing_files.mdwn
 create mode 100644 doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_1_0738174fb6984b777ec0a221502106ac._comment
 create mode 100644 doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_2_1e07d1a9ddb88c0e1d84d8d88b7b4cc4._comment
 create mode 100644 doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_2_65d007284287e709a8f6f07dd8630f15._comment
 create mode 100644 doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_4_3bbce5d12ece481b669be10ef9a70f40._comment
 create mode 100644 doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_5_5e6202c319e75a9758bb8c2f32152e0f._comment
 create mode 100644 doc/forum/Basic_set_up_with_one_remote.mdwn
 create mode 100644 doc/forum/Basic_set_up_with_one_remote/comment_1_3ad06a0dbebf62e6440f549e77af59b6._comment
 create mode 100644 doc/forum/Basic_set_up_with_one_remote/comment_2_59e18e759c907b8adabf8c34eef08065._comment
 create mode 100644 doc/forum/Basic_set_up_with_one_remote/comment_3_5221a713ee3f65fa2740c9fa6cb1db0f._comment
 create mode 100644 doc/forum/Basic_set_up_with_one_remote/comment_4_62e554a546e4b50d211f5f65446fd289._comment
 create mode 100644 doc/forum/Batch_process__44___git_rm__44___and_locking.mdwn
 create mode 100644 doc/forum/Batch_process__44___git_rm__44___and_locking/comment_1_6cb866b48f6426e7ecc4f8d6af5b710d._comment
 create mode 100644 doc/forum/Batch_process__44___git_rm__44___and_locking/comment_2_51667179ddb52ca5fa1166196c5d37e2._comment
 create mode 100644 doc/forum/Batch_process__44___git_rm__44___and_locking/comment_3_593879cc70e9a07a49fa663677f5c045._comment
 create mode 100644 doc/forum/Beginners_questions__58___limit_content_on_special_remotes___38___use_non-git_clients_for_r__47__w_access_on_shared_git-annex_server.mdwn
 create mode 100644 doc/forum/Beginners_questions__58___limit_content_on_special_remotes___38___use_non-git_clients_for_r__47__w_access_on_shared_git-annex_server/comment_1_871b5a42f1134a059df520993bb55268._comment
 create mode 100644 doc/forum/Beginners_questions__58___limit_content_on_special_remotes___38___use_non-git_clients_for_r__47__w_access_on_shared_git-annex_server/comment_2_68d675096d9ea32780b8ec8526544b12._comment
 create mode 100644 doc/forum/Behaviour_of_fsck.mdwn
 create mode 100644 doc/forum/Behaviour_of_fsck/comment_1_0e40f158b3f4ccdcaab1408d858b68b8._comment
 create mode 100644 doc/forum/Behaviour_of_fsck/comment_2_ead36a23c3e6efa1c41e4555f93e014e._comment
 create mode 100644 doc/forum/Behaviour_of_fsck/comment_3_97848f9a3db89c0427cfb671ba13300e._comment
 create mode 100644 doc/forum/Behaviour_of_fsck/comment_4_e4911dc6793f98fb81151daacbe49968._comment
 create mode 100644 doc/forum/Benefit_and_drawback_of_new_unlocked_file_mode_V6_vs_locked_mode.mdwn
 create mode 100644 doc/forum/Benefit_and_drawback_of_new_unlocked_file_mode_V6_vs_locked_mode/comment_1_fef0122752291bdc583fdcfdd400d250._comment
 create mode 100644 doc/forum/Best_approach_for_central_sharing_and_multiple_users.mdwn
 create mode 100644 doc/forum/Best_approach_for_central_sharing_and_multiple_users/comment_1_48ffb50b92588daec6887bf08f1b97f5._comment
 create mode 100644 doc/forum/Best_approach_for_central_sharing_and_multiple_users/comment_2_6b9a20f9707da9d2cfc3697a538d6935._comment
 create mode 100644 doc/forum/Best_option_for_dropable_compression_+_encryption.mdwn
 create mode 100644 doc/forum/Best_option_for_dropable_compression_+_encryption/comment_1_1d55eb39e46eee8c5dd6e142e71289ad._comment
 create mode 100644 doc/forum/Best_option_for_dropable_compression_+_encryption/comment_2_704eed4d3607ebbfc9c6f5c64e7a1507._comment
 create mode 100644 doc/forum/Best_way_to_extract_git-annex_object_files___40__with_correct_names__41___in_absence_of_git_log.mdwn
 create mode 100644 doc/forum/Best_way_to_extract_git-annex_object_files___40__with_correct_names__41___in_absence_of_git_log/comment_1_a1827481a3ac140d58a4184121328d87._comment
 create mode 100644 doc/forum/Best_way_to_manage_files_on_removable_media__63__.mdwn
 create mode 100644 doc/forum/Best_way_to_re-add_a_file_in_a_direct_and_crippled_annex_repository.mdwn
 create mode 100644 doc/forum/Best_way_to_re-add_a_file_in_a_direct_and_crippled_annex_repository/comment_1_552e74f9573a34ec178f396b83252c3e._comment
 create mode 100644 doc/forum/Best_way_to_re-add_a_file_in_a_direct_and_crippled_annex_repository/comment_2_33c57922714f204fc63c260b838f3712._comment
 create mode 100644 doc/forum/Best_way_to_remove_old_version_of_specific_file.mdwn
 create mode 100644 doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_1_1663dd9118cb1fee92ae3f8d812df79c._comment
 create mode 100644 doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_2_6580f6790404694b55d07a0e57d83336._comment
 create mode 100644 doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_3_c1f34ec908d7c4ad05c4360e29e68fb4._comment
 create mode 100644 doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_4_160011717157fa8fca3a33b543c4d28d._comment
 create mode 100644 doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_5_dfec54344742e2c8d6904333ff848c8c._comment
 create mode 100644 doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_6_e854d6b778bcb7dc1578cbc9c8fcaa42._comment
 create mode 100644 doc/forum/Big_repository_vs._multiple_small.mdwn
 create mode 100644 doc/forum/Big_repository_vs._multiple_small/comment_1_8e21ee3c674ef6e595bdab53dd5c2356._comment
 create mode 100644 doc/forum/Big_repository_vs._multiple_small/comment_2_656c62351502492d20e8490242e51169._comment
 create mode 100644 doc/forum/Big_repository_vs._multiple_small/comment_3_e9c44ea364513f090844f46af2ea46a1._comment
 create mode 100644 doc/forum/Big_repository_vs._multiple_small/comment_4_82e13580426dc648688e4c26e7ed91ec._comment
 create mode 100644 doc/forum/Big_repository_vs._multiple_small/comment_5_632aceb71dc6a4a9a4bb03de25a9b21a._comment
 create mode 100644 doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant.mdwn
 create mode 100644 doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant/comment_1_239ae08d8eb8b0d7fe52991b0bddc653._comment
 create mode 100644 doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant/comment_2_8b91328473b384f347710ec634be710a._comment
 create mode 100644 doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant/comment_3_12a6bc61a7492650fd2baf9a1b796997._comment
 create mode 100644 doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__.mdwn
 create mode 100644 doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_1_a224bf8ed9502053e9b95317db7b4bfa._comment
 create mode 100644 doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_2_0f2e7cf29ad9d41e0041924e69425050._comment
 create mode 100644 doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_3_a2cac051ef2d36e1ffb550c4a788c111._comment
 create mode 100644 doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_4_d95647d91a33d1164a87344939cb769a._comment
 create mode 100644 doc/forum/Borg_and_xattrs.mdwn
 create mode 100644 doc/forum/Borg_and_xattrs/comment_1_703c9a9be1e0b0ca9ce4dd0309546a04._comment
 create mode 100644 doc/forum/Borg_and_xattrs/comment_2_a1f4e0758c3e02f4f8558d167a26c0c4._comment
 create mode 100644 doc/forum/Box.com_hasn__39__t_been_working_for_a_few_days.mdwn
 create mode 100644 doc/forum/Box.com_hasn__39__t_been_working_for_a_few_days/comment_1_6ca872c241399b9129cf9a18f42ebd43._comment
 create mode 100644 doc/forum/Broken_symlinks_remain_after_drop.mdwn
 create mode 100644 doc/forum/Broken_symlinks_remain_after_drop/comment_1_d4a59b9e58d43d7a3d437e521dd5c4e1._comment
 create mode 100644 doc/forum/Broken_symlinks_remain_after_drop/comment_2_399ba969a17a41a022c69a1f7c480857._comment
 create mode 100644 doc/forum/Building_Android_app_fails.mdwn
 create mode 100644 doc/forum/Building_Android_app_fails/comment_1_094b90cbc1e2e069900c0037fec145ad._comment
 create mode 100644 doc/forum/Building_a_Debian_package_of_git-annex.mdwn
 create mode 100644 doc/forum/Building_a_Debian_package_of_git-annex/comment_1_0848513c46f3efa21bc34784554ae88a._comment
 create mode 100644 doc/forum/Building_git-annex-3.20121112-19309.mdwn
 create mode 100644 doc/forum/Building_git-annex-3.20121112-19309/comment_1_b115e28c77fe748ee6643c41f766beb4._comment
 create mode 100644 doc/forum/Building_git-annex-3.20121112-19309/comment_2_8c6ae1fd74f14da12ccfa77dbd27fc65._comment
 create mode 100644 doc/forum/Building_git-annex-3.20121112-19309/comment_3_2f30b301c14f3a7fa0f52715d6140353._comment
 create mode 100644 doc/forum/Building_git-annex-3.20121112-19309/comment_4_1e3c3903a71a2ff7109372aa4dd5742a._comment
 create mode 100644 doc/forum/CD-R_as_special_remote.mdwn
 create mode 100644 doc/forum/CD-R_as_special_remote/comment_1_e5d6d72953575d2bbfb6c620bb4c9454._comment
 create mode 100644 doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__.mdwn
 create mode 100644 doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__/comment_1_2eb4f410b54a25fcc895893a3c631c43._comment
 create mode 100644 doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__/comment_2_44cd6f6dd674df105d6f0b3f320f3236._comment
 create mode 100644 doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__/comment_3_992af6855901df79a2018a07941cb8b6._comment
 create mode 100644 doc/forum/Calculating_Annex_Cost_by_Ping_Times.mdwn
 create mode 100644 doc/forum/Calculating_Annex_Cost_by_Ping_Times/comment_1_9b4a6bc8d52ecbbdd537e8cf76757a80._comment
 create mode 100644 doc/forum/Calculating_Annex_Cost_by_Ping_Times/comment_2_7e04f85c6ba74c18c8dde148aef9bf80._comment
 create mode 100644 doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__.mdwn
 create mode 100644 doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__/comment_1_3510190e7c5d08f906b24e5743245f87._comment
 create mode 100644 doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__/comment_2_bfd829aed28817a5aada3f237496c865._comment
 create mode 100644 doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__/comment_3_cf2ae4db1fdb421b59d85edd9e58b868._comment
 create mode 100644 doc/forum/Can_I_remove_a_groupwanted_expression__63__.mdwn
 create mode 100644 doc/forum/Can_I_remove_a_groupwanted_expression__63__/comment_2_23d18b52d87468ffadf0a3e04bf8052d._comment
 create mode 100644 doc/forum/Can_I_store_normal_files_in_the_git-annex_git_repository__63__.mdwn
 create mode 100644 doc/forum/Can_I_store_normal_files_in_the_git-annex_git_repository__63__/comment_1_c8f9923d8dc76b8bed25dce5ae09b520._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo.mdwn
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_10_e0f82074eb1a4b8258729d9a23a7f421._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_11_842aaf685aa843c21bf3eef0b61f8630._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_12_b4f8be428a08db01dbd004e1f06dcffd._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_13_45132d348807fbf8ed32198e110d2caa._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_14_d2bb44a7607f3b2cddfd98cc2fa456d6._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_1_80344c54804ddee81d89c0b40731fb9c._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_2_1797c2fef5c20e885b56b8a2c6330ff0._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_3_fb23d640f9634cab2da91848f1848627._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_4_a947736911e68856f2c3494963063df8._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_5_ce0e77143cfd2d578b1e5a71e35060da._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_6_10e114da6a2bb54b860b44767ba1ca94._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_7_415bab6a7ab564e671f42cfad83e0e58._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_8_36abd829ea71a44c7cded1123a7c913d._comment
 create mode 100644 doc/forum/Can_Not_Sync_to_Git_Repo/comment_9_2fb745aaffe544f97bbdc670261fd4fd._comment
 create mode 100644 doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only.mdwn
 create mode 100644 doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_1_e03ec3be310f5c0e02457ac053e6afdd._comment
 create mode 100644 doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_2_1bea8772a170277420faa898dcf2ab83._comment
 create mode 100644 doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_3_c061fef62b272d34b605d94a176cd577._comment
 create mode 100644 doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_4_2f6d31ada3a8f3f43bc53ce9ee2c70b8._comment
 create mode 100644 doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_5_d25b7eb756f08c94a2b2ada472cd0f87._comment
 create mode 100644 doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook.mdwn
 create mode 100644 doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_1_8b71cb6772b219c27c17392d5099907a._comment
 create mode 100644 doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_2_af2a2634d8d128868022d033d6adb549._comment
 create mode 100644 doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_3_31ec762a0684d2ce87d229ed2924db93._comment
 create mode 100644 doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_4_cfa52c727baaf683e91c3fbb1c78072c._comment
 create mode 100644 doc/forum/Can__39__t_get_jabber_working.mdwn
 create mode 100644 doc/forum/Can__39__t_get_jabber_working/comment_1_def20bf0b3c1a188e4dad5ec67b455d8._comment
 create mode 100644 doc/forum/Can__39__t_get_jabber_working/comment_2_7cb49c0ebfec6e0fe6784e189ed65d40._comment
 create mode 100644 doc/forum/Can__39__t_get_jabber_working/comment_3_852dc402a286e38b77b99f174c33f8d1._comment
 create mode 100644 doc/forum/Can__39__t_get_jabber_working/comment_4_259741e146906ff70540390bdfe07002._comment
 create mode 100644 doc/forum/Can__39__t_get_pairing_to_work.mdwn
 create mode 100644 doc/forum/Can__39__t_get_pairing_to_work/comment_1_b981977b4fb942fd109c37fcf40f35d7._comment
 create mode 100644 doc/forum/Can__39__t_get_pairing_to_work/comment_2_341e2ff6c88ace1b1422e16781edf580._comment
 create mode 100644 doc/forum/Can__39__t_get_pairing_to_work/comment_3_0c8cce48f179f2564ff0844bb7ef6bd1._comment
 create mode 100644 doc/forum/Can__39__t_get_pairing_to_work/comment_4_169d77b30cea05125068ee1eeb2ef328._comment
 create mode 100644 doc/forum/Can__39__t_get_pairing_to_work/comment_5_70e6c4f4f01277be1767b38ca8374793._comment
 create mode 100644 doc/forum/Can__39__t_get_pairing_to_work/comment_6_2cd014a76fac6e08269dfd8146957418._comment
 create mode 100644 doc/forum/Can__39__t_get_pairing_to_work/comment_7_b9b715084d5a5562998b1724699d49e5._comment
 create mode 100644 doc/forum/Can__39__t_get_some_files_from_bare_repo.mdwn
 create mode 100644 doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_1_ead60b63efb06249c99202631ef0b247._comment
 create mode 100644 doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_2_82a5d9005dca476916e4b5df671e3111._comment
 create mode 100644 doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_3_430c7854e33ff3e821ebd00b436dbf45._comment
 create mode 100644 doc/forum/Can__39__t_init_git_annex.mdwn
 create mode 100644 doc/forum/Can__39__t_init_git_annex/comment_10_c4d2ab1ecf69718a2211c3ea7b27092b._comment
 create mode 100644 doc/forum/Can__39__t_init_git_annex/comment_12_fca9ed3707e097bee2cd642424681005._comment
 create mode 100644 doc/forum/Can__39__t_init_git_annex/comment_1_a294b5e7e52aa9f66a708866be16f137._comment
 create mode 100644 doc/forum/Can__39__t_init_git_annex/comment_2_fcf678d5188821d63b4c9ea5b59474a8._comment
 create mode 100644 doc/forum/Can__39__t_init_git_annex/comment_3_c83f7dea7d5304e226e52eb3c43ef14a._comment
 create mode 100644 doc/forum/Can__39__t_init_git_annex/comment_4_06a01dd51ffbfd006c0afb8eab40b530._comment
 create mode 100644 doc/forum/Can__39__t_init_git_annex/comment_5_53c33484bded57abc60f0449331c7b05._comment
 create mode 100644 doc/forum/Can__39__t_init_git_annex/comment_6_9e0ff44f6e62581bfc83f9f1da3e0100._comment
 create mode 100644 doc/forum/Can__39__t_init_git_annex/comment_7_7f96b5ef05e2faf4a3dbe8bfc39b810e._comment
 create mode 100644 doc/forum/Can__39__t_init_git_annex/comment_8_65ab8463716f4ddd7721a5bcfcd18fa0._comment
 create mode 100644 doc/forum/Can__39__t_init_git_annex/comment_9_31a45f6a72266190b3ed7a7b02e03d5b._comment
 create mode 100644 doc/forum/Can__39__t_install__58___Mac_OS_10.8.2.mdwn
 create mode 100644 doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_1_c44023d81e9e4f7c9341af0e4271a1e4._comment
 create mode 100644 doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_2_dfbcd39eedff28dc9ed866a8f1411ef3._comment
 create mode 100644 doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_3_b37b2a9906ffb956cca91adb4bb4e521._comment
 create mode 100644 doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_4_afddf16f8faedc78d458835480f10dc3._comment
 create mode 100644 doc/forum/Can__39__t_upload_data_to_glacier_remote.mdwn
 create mode 100644 doc/forum/Can__39__t_upload_data_to_glacier_remote/comment_1_cb18d5d63663f73a343c8972faadc83a._comment
 create mode 100644 doc/forum/Can__39__t_upload_data_to_glacier_remote/comment_2_9b6a397d1c85da87481d36b8a4bd1ba6._comment
 create mode 100644 doc/forum/Can__39__t_upload_data_to_glacier_remote/comment_3_6625da96f8cdc8b367b4c2bc275f2aee._comment
 create mode 100644 doc/forum/Can_a_repo_be_marked_as___34__must_have_file__63____34__.mdwn
 create mode 100644 doc/forum/Can_a_repo_be_marked_as___34__must_have_file__63____34__/comment_1_14d4d3f84eacc36dcc55af783d189619._comment
 create mode 100644 doc/forum/Can_a_repo_be_marked_as___34__must_have_file__63____34__/comment_2_409d6a97f5c3d1f1fc5e932a2965e227._comment
 create mode 100644 doc/forum/Can_git-annex-import_--clean-duplicates_honour_multiple_backends__63__.mdwn
 create mode 100644 doc/forum/Can_git-annex-import_--clean-duplicates_honour_multiple_backends__63__/comment_1_5730767d5247e8997b4fa5b20c4cb281._comment
 create mode 100644 doc/forum/Can_git-annex-import_--clean-duplicates_honour_multiple_backends__63__/comment_2_c2846031bd79fa60cd903fb4d5bcebaf._comment
 create mode 100644 doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__.mdwn
 create mode 100644 doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__/comment_1_a3fbae205c0312436f8861f432643811._comment
 create mode 100644 doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__/comment_2_de49cf261c644a6e7f6ac881a48d4e6c._comment
 create mode 100644 doc/forum/Can_not_delete_Repository.mdwn
 create mode 100644 doc/forum/Can_not_delete_Repository/comment_1_b1a9420974e2e50c9c86a379ad62502c._comment
 create mode 100644 doc/forum/Can_not_drop_unused_file.mdwn
 create mode 100644 doc/forum/Can_not_drop_unused_file/comment_1_cea83dfdf4cdb4f6efb3f2b33a39a51f._comment
 create mode 100644 doc/forum/Can_not_drop_unused_file/comment_2_ed1543cff5e6e81ca18c43b716ca8199._comment
 create mode 100644 doc/forum/Can_not_drop_unused_file/comment_3_0c9c9c0ed557af4845a67434c21bb4bc._comment
 create mode 100644 doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__.mdwn
 create mode 100644 doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_1_bc838634442883e541de1ceab520d71e._comment
 create mode 100644 doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_2_676a8c3586d16afedff9e47d9ffd7431._comment
 create mode 100644 doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_3_e584a99e46f881358bf848131a94e293._comment
 create mode 100644 doc/forum/Can_we_have_remotes_that_aren__39__t_tracked__63___.mdwn
 create mode 100644 doc/forum/Can_we_have_remotes_that_aren__39__t_tracked__63___/comment_1_35e5a963b9e58ed7773dfcb884f8ecbd._comment
 create mode 100644 doc/forum/Can_we_have_remotes_that_aren__39__t_tracked__63___/comment_2_7cde9785886c8450e1475f0b54481ae3._comment
 create mode 100644 doc/forum/Can_you_use_git_annex_on_gocryptfs__63__.mdwn
 create mode 100644 doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_1_3e8c83a9d0a8dbb7a5a3fd25136cf0b4._comment
 create mode 100644 doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_2_9a46e613745c8c80dedce6a3cd799e0b._comment
 create mode 100644 doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_3_de92ff891493737021cb264394a0a6bb._comment
 create mode 100644 doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_4_2689a87a68dc459615d9542ad908b7a3._comment
 create mode 100644 doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_5_a1f8d718be941f4dd5e7b06fd6431c10._comment
 create mode 100644 doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_7_375b8234fc79d75f3cb39004cbe4d9e3._comment
 create mode 100644 doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_7_ff7f26601e375146a08b454a2e448f1b._comment
 create mode 100644 doc/forum/Cannot_find_git-annex_in_server.mdwn
 create mode 100644 doc/forum/Cannot_find_git-annex_in_server/comment_1_bf7e98e6130698ad0dc92e3a6a63ade3._comment
 create mode 100644 doc/forum/Cannot_find_git-annex_in_server/comment_2_168dda4aed09f90a510bc453e8a7cda7._comment
 create mode 100644 doc/forum/Cannot_get_file_from_special_remote.mdwn
 create mode 100644 doc/forum/Cannot_get_file_from_special_remote/comment_1_7fd5cebf26042ff0de30746bf8a6adcf._comment
 create mode 100644 doc/forum/Cannot_get_file_from_special_remote/comment_2_bbb832f022d23b1f020d07f3fe99577f._comment
 create mode 100644 doc/forum/Cannot_get_file_from_special_remote/comment_3_81a6054bc3b64f1325f4d85979f2b12a._comment
 create mode 100644 doc/forum/Cannot_get_file_from_special_remote/comment_4_6e7252449b3eb9ca5d45b5c3889cacd4._comment
 create mode 100644 doc/forum/Cannot_get_file_with_git-annex.mdwn
 create mode 100644 doc/forum/Cannot_get_file_with_git-annex/comment_1_d16cff700d5899c56011f66b655ad9ff._comment
 create mode 100644 doc/forum/Cannot_get_file_with_git-annex/comment_2_50c375c6af20b38dec08eff10113dee2._comment
 create mode 100644 doc/forum/Cannot_get_unlocked_file_contents.mdwn
 create mode 100644 doc/forum/Cannot_get_unlocked_file_contents/comment_1_1905d2a9ae0142838f42aff4efd5c643._comment
 create mode 100644 doc/forum/Cannot_get_unlocked_file_contents/comment_2_496503ae9878d402261910e2dd9bc385._comment
 create mode 100644 doc/forum/Cannot_get_unlocked_file_contents/comment_3_57ee489f24b26b73b28f64566e2b8ff5._comment
 create mode 100644 doc/forum/Cannot_get_unlocked_file_contents/comment_3_be1f3ec26c14ca9adc9d8f24ea096976._comment
 create mode 100644 doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa.mdwn
 create mode 100644 doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_1_9345551f5772c3a6f1490b00e1edbf69._comment
 create mode 100644 doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_2_0b688a442b6a911a0353e73097a24cb6._comment
 create mode 100644 doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_3_7e246caa00005560bb489c927c663046._comment
 create mode 100644 doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_4_1d8025aabe8bc72711a77f691f67da5f._comment
 create mode 100644 doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_5_7c2f95da65190016192424e7c622122f._comment
 create mode 100644 doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_6_9b8465cefe609e7a696e7573b8892e38._comment
 create mode 100644 doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_7_af6472762a598a454ba52ac0caa059aa._comment
 create mode 100644 doc/forum/Cant_see_git-annex-shell_via_SSH_in_OSX.mdwn
 create mode 100644 doc/forum/Cant_see_git-annex-shell_via_SSH_in_OSX/comment_1_1fafdc4ed4a0f601918361dca688aa6c._comment
 create mode 100644 doc/forum/Case-insensitive_search_with_find_list_whereis__63__.mdwn
 create mode 100644 doc/forum/Case-insensitive_search_with_find_list_whereis__63__/comment_1_b893fd9a250d25ebc62913131cb0a479._comment
 create mode 100644 doc/forum/Case-insensitive_search_with_find_list_whereis__63__/comment_2_e19abfe33b0f071ffc059e9976fc6d91._comment
 create mode 100644 doc/forum/Central_git_annex_server_that_always_keeps_one_copy.mdwn
 create mode 100644 doc/forum/Central_git_annex_server_that_always_keeps_one_copy/comment_1_e786c8df6e48d88cf15b555af1b8639a._comment
 create mode 100644 doc/forum/Central_git_annex_server_that_always_keeps_one_copy/comment_2_b0a091e11c18c8640888b0aedfbff5c5._comment
 create mode 100644 doc/forum/Central_server_with_automatically_merged_working_tree.mdwn
 create mode 100644 doc/forum/Central_server_with_automatically_merged_working_tree/comment_1_bc850e25e48598a09353850021c6368c._comment
 create mode 100644 doc/forum/Centralized_repository_with_webapp.mdwn
 create mode 100644 doc/forum/Centralized_repository_with_webapp/comment_1_dcb9b07fd154f4d4fdef4809cc37ce77._comment
 create mode 100644 doc/forum/Centralized_repository_with_webapp/comment_2_08c84f2703f89dc12982eba9dd2a06d1._comment
 create mode 100644 doc/forum/Change_a_special_remote__39__s_type.mdwn
 create mode 100644 doc/forum/Change_a_special_remote__39__s_type/comment_1_9d7c23f5c985d44ffa78b3957ddc3d15._comment
 create mode 100644 doc/forum/Change_a_special_remote__39__s_type/comment_2_c514ca0dd8b883e02de7c70b46991152._comment
 create mode 100644 doc/forum/Change_a_special_remote__39__s_type/comment_3_b89db83045d4baa82cc96b7610caecda._comment
 create mode 100644 doc/forum/Change_annex_id_after_harddrive_clone.mdwn
 create mode 100644 doc/forum/Change_annex_id_after_harddrive_clone/comment_1_2e8ba624f404edf2923d08ae27d12a60._comment
 create mode 100644 doc/forum/Change_or_add_S3_credentials.mdwn
 create mode 100644 doc/forum/Change_or_add_S3_credentials/comment_1_864932114dcc7aaf1d88edb0673f1d86._comment
 create mode 100644 doc/forum/Change_remote_server_address.mdwn
 create mode 100644 doc/forum/Change_remote_server_address/comment_1_401c3d2530ac7ba41dd3857ab4737ed5._comment
 create mode 100644 doc/forum/Change_remote_server_address/comment_2_93a4c44d552efe6d51584e0aab3605e7._comment
 create mode 100644 doc/forum/Changing_files_during_git_annex_runs.mdwn
 create mode 100644 doc/forum/Changing_files_during_git_annex_runs/comment_1_8067077c49dafbe2afa7d182b3314df4._comment
 create mode 100644 doc/forum/Changing_the_target_of_an_external_special_remote.mdwn
 create mode 100644 doc/forum/Changing_the_target_of_an_external_special_remote/comment_1_db1112fb1b4626f2d2c1b7b78ab3f5e5._comment
 create mode 100644 doc/forum/Cheapest_test_for_an_initialized_annex__63__.mdwn
 create mode 100644 doc/forum/Cheapest_test_for_an_initialized_annex__63__/comment_1_abe1af7fc49f91e3aa15915190dc5dfd._comment
 create mode 100644 doc/forum/Cheapest_test_for_an_initialized_annex__63__/comment_2_3d6f353d087cb945a0288f0594a1d1e0._comment
 create mode 100644 doc/forum/Check_if_remote_is_using_GPG__63__.mdwn
 create mode 100644 doc/forum/Check_if_remote_is_using_GPG__63__/comment_1_db8ce8ef50fc33a28860ee475988450f._comment
 create mode 100644 doc/forum/Check_if_remote_is_using_GPG__63__/comment_2_11c7033904c9c7a1df766e915632c386._comment
 create mode 100644 doc/forum/Check_if_remote_is_using_GPG__63__/comment_3_a7ab70ad87a334c36761ddb3d830d99b._comment
 create mode 100644 doc/forum/Check_when_your_last_fsck_was__63__.mdwn
 create mode 100644 doc/forum/Check_when_your_last_fsck_was__63__/comment_1_ee98a1fcd796fe4fd7af6f77d0c1837d._comment
 create mode 100644 doc/forum/Check_when_your_last_fsck_was__63__/comment_2_7238740d7904a6a9715c1cd7d8a529d4._comment
 create mode 100644 doc/forum/Check_when_your_last_fsck_was__63__/comment_3_8fa3680b084fad45d7a184d1191fedce._comment
 create mode 100644 doc/forum/Checking_for_missing_files_in_S3___40__reduced_redundancy__41__.mdwn
 create mode 100644 doc/forum/Checking_for_missing_files_in_S3___40__reduced_redundancy__41__/comment_2_793b3d9f78562f3aecf27dd926bbcf82._comment
 create mode 100644 doc/forum/Checking_that_everything_is_committed.mdwn
 create mode 100644 doc/forum/Checking_that_everything_is_committed/comment_1_875c22110d65c0d8e6ef6aebced87e95._comment
 create mode 100644 doc/forum/Checkout_only_some_files_with_the_assistant.mdwn
 create mode 100644 doc/forum/Checkout_only_some_files_with_the_assistant/comment_1_23d8ab1a05e3e9d3611bd12a4ba70b0c._comment
 create mode 100644 doc/forum/Checkout_only_some_files_with_the_assistant/comment_2_bf095ff5b5af95b062ae1f7da566a279._comment
 create mode 100644 doc/forum/Checkout_only_some_files_with_the_assistant/comment_3_7c026e36e1cdd52053c34638c87d793c._comment
 create mode 100644 doc/forum/Clarification_in_usage_case.mdwn
 create mode 100644 doc/forum/Clarification_in_usage_case/comment_1_555ff0df9be2e25dcc784bc7956dcfe7._comment
 create mode 100644 doc/forum/Clarification_in_usage_case/comment_2_8b43bc642656243cdf43cf77ae1c1851._comment
 create mode 100644 doc/forum/Clarifications_about_how_to_work_with_git-annex.mdwn
 create mode 100644 doc/forum/Clarifications_about_how_to_work_with_git-annex/comment_1_7f9857887a25df617a99cdab119761d8._comment
 create mode 100644 doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode.mdwn
 create mode 100644 doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode/comment_1_3440b2e1662d3b113c18283afcbf4520._comment
 create mode 100644 doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode/comment_2_9a61ba8ac4a375f1d69cd09b5a6f8091._comment
 create mode 100644 doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode/comment_3_6b9d8c48547f3d0a911310622ba91df7._comment
 create mode 100644 doc/forum/Combine_tags_in_view_branches.mdwn
 create mode 100644 doc/forum/Coming_from_git_world.mdwn
 create mode 100644 doc/forum/Coming_from_git_world/comment_10_098bef38c2688607e869425a557cc482._comment
 create mode 100644 doc/forum/Coming_from_git_world/comment_11_98d75a1415e0c3689ab4231855e61233._comment
 create mode 100644 doc/forum/Coming_from_git_world/comment_12_5e7079e9bf3e4d97191333c66ac00e52._comment
 create mode 100644 doc/forum/Coming_from_git_world/comment_1_357443dc601ae38784c01cf18552f4d5._comment
 create mode 100644 doc/forum/Coming_from_git_world/comment_2_ed1847dd3f47a9d013b8dd0455fb80ff._comment
 create mode 100644 doc/forum/Coming_from_git_world/comment_3_09c6bb83a73d34dff2b8bc185a14a1db._comment
 create mode 100644 doc/forum/Coming_from_git_world/comment_4_6c731bb9a8d21dd9ab8c09612b23f908._comment
 create mode 100644 doc/forum/Coming_from_git_world/comment_5_e719d99af5afd90da3d3db692eff28dc._comment
 create mode 100644 doc/forum/Coming_from_git_world/comment_6_85a42106944dba9995fb3f4bfee3443a._comment
 create mode 100644 doc/forum/Coming_from_git_world/comment_7_90623294b910ceca3dc8ebd41b50fc9b._comment
 create mode 100644 doc/forum/Coming_from_git_world/comment_8_28dbee30eb54877418f72eb8935302d8._comment
 create mode 100644 doc/forum/Coming_from_git_world/comment_9_6edb36ea9535030fa3766937398e5bc7._comment
 create mode 100644 doc/forum/Comparison_with_other_big_files_solutions.mdwn
 create mode 100644 doc/forum/Compile_Problem_with_latest_git_pull_version.mdwn
 create mode 100644 doc/forum/Compile_Problem_with_latest_git_pull_version/comment_1_0b87183756e860d93b8c0197bac3c0b1._comment
 create mode 100644 doc/forum/Compile_Problem_with_latest_git_pull_version/comment_2_1dd40ce31bcf994656fdfee7f8af43d2._comment
 create mode 100644 doc/forum/Compile_Problem_with_latest_git_pull_version/comment_3_f8e52610a592c68f9bc733bd31fa9659._comment
 create mode 100644 doc/forum/Compression_in_special_remotes___40__specifically_S3__41____63__.mdwn
 create mode 100644 doc/forum/Compression_in_special_remotes___40__specifically_S3__41____63__/comment_1_9c6c4ca0c9dc6976ba7cf27e84683bf0._comment
 create mode 100644 doc/forum/Confusion_about_Webapp___40__on_OSX__41__.mdwn
 create mode 100644 doc/forum/Confusion_about_Webapp___40__on_OSX__41__/comment_1_868b326cc5eb0767390ffdf45a594cff._comment
 create mode 100644 doc/forum/Confusion_about_Webapp___40__on_OSX__41__/comment_2_9b38b92d584395e5468bed03395c927f._comment
 create mode 100644 doc/forum/Confusion_about_Webapp___40__on_OSX__41__/comment_3_7d790a158b7c22206b0b523a4227bacb._comment
 create mode 100644 doc/forum/Consistency_Check_for_S3.mdwn
 create mode 100644 doc/forum/Consistency_Check_for_S3/comment_1_40385806ef1cc082232cd2723a24be1a._comment
 create mode 100644 doc/forum/Consistency_Check_for_S3/comment_2_ebfe40d9f777c9c0a83c44afd0f5802d._comment
 create mode 100644 doc/forum/Consistency_Check_for_S3/comment_3_ec9de6882a0eef4d2786e55b583ad020._comment
 create mode 100644 doc/forum/Content-sensitive_chunking__63__.mdwn
 create mode 100644 doc/forum/Content_branch.mdwn
 create mode 100644 doc/forum/Content_branch/comment_1_564724cb1508524700b71950b81a5058._comment
 create mode 100644 doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it.mdwn
 create mode 100644 doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it/comment_1_55e676477623db9e26e871d7189a1a88._comment
 create mode 100644 doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it/comment_2_cb404061683de3bfd5c24ce7e5ee6b82._comment
 create mode 100644 doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it/comment_3_74055eed54696331af07ba1721055562._comment
 create mode 100644 doc/forum/Controlling_content_on_mobile_device.mdwn
 create mode 100644 doc/forum/Controlling_content_on_mobile_device/comment_1_708649b7f30d8619d7b34dcb0ef46515._comment
 create mode 100644 doc/forum/Controlling_content_on_mobile_device/comment_2_dba1a1b0917332a1dee387b1183bd2cb._comment
 create mode 100644 doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo.mdwn
 create mode 100644 doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_1_e6065f9c44c85030c7628e2cfa0fd0fa._comment
 create mode 100644 doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_2_76bfb11396dc20a5105376b22e7e773b._comment
 create mode 100644 doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_3_b34d6ae0718ab0ff6bc1d7b8f2470b9b._comment
 create mode 100644 doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_4_8f5e323b29745591f9f2f0f867353f69._comment
 create mode 100644 doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_5_9824c953694770afa0611ff7276737bf._comment
 create mode 100644 doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_6_5899741cb7f83e1b22c5ee3509c5ff21._comment
 create mode 100644 doc/forum/Copy_contents_of_directory_to_rsync_remotes_possible__63__.mdwn
 create mode 100644 doc/forum/Copy_contents_of_directory_to_rsync_remotes_possible__63__/comment_1_6a598b2a0fc6c241aa051f663dca9842._comment
 create mode 100644 doc/forum/Copy_contents_of_directory_to_rsync_remotes_possible__63__/comment_3_09b7f1dd1fa4589b3fe0be0086849bf3._comment
 create mode 100644 doc/forum/Copy_modified_content_to_a_repo_that_only_wants_content_already_present.mdwn
 create mode 100644 doc/forum/Copy_modified_content_to_a_repo_that_only_wants_content_already_present/comment_1_fb09f84abeebc55df9741b059dc50674._comment
 create mode 100644 doc/forum/Copy_modified_content_to_a_repo_that_only_wants_content_already_present/comment_2_0b13914351aeb57fd7684ff2041618ee._comment
 create mode 100644 doc/forum/Copying_and_dropping_right_after.mdwn
 create mode 100644 doc/forum/Copying_and_dropping_right_after/comment_1_87d81911964c2628ccb6156b0b631aa0._comment
 create mode 100644 doc/forum/Copying_and_dropping_right_after/comment_2_87a14d14014aefc33f811bb15ea27e13._comment
 create mode 100644 doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work.mdwn
 create mode 100644 doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work/comment_1_ec390a7d521c697eb6b17e8db1dc9d1d._comment
 create mode 100644 doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work/comment_2_14a584567ef42d5b7955ee970200e74d._comment
 create mode 100644 doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work/comment_3_6cbd7329f1f11edf8dd90df27d45158f._comment
 create mode 100644 doc/forum/Correct_way_to_use_somewhat_unreliable_private_server_and_box.com.mdwn
 create mode 100644 doc/forum/Correct_way_to_use_somewhat_unreliable_private_server_and_box.com/comment_1_9c357a4a99930936124a58ffe105f87f._comment
 create mode 100644 doc/forum/Correct_way_to_use_somewhat_unreliable_private_server_and_box.com/comment_2_b4aec96cbcd8752f273ecd810400acef._comment
 create mode 100644 doc/forum/Corrupt_Repository_Invalid_Object.mdwn
 create mode 100644 doc/forum/Corrupt_Repository_Invalid_Object/comment_1_b7fd4b6212b50400342931e70684b96c._comment
 create mode 100644 doc/forum/Corrupted_repository__44___can_not_be_repaired.mdwn
 create mode 100644 doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_1_297ea9c13096f6360358b3a3e7197c03._comment
 create mode 100644 doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_2_c3aabffbe9568cf7acb4018e445f22a5._comment
 create mode 100644 doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_3_baee46af6b2dbaf92be406ab22007a85._comment
 create mode 100644 doc/forum/Create_lightweight_checkouts_on_the_same_filesystem.mdwn
 create mode 100644 doc/forum/Create_lightweight_checkouts_on_the_same_filesystem/comment_1_dc219eec54b62803831c854a620aceae._comment
 create mode 100644 doc/forum/Create_lightweight_checkouts_on_the_same_filesystem/comment_2_1263830d015a458024a2346540f10f31._comment
 create mode 100644 doc/forum/Creating_a_more_secure_shared_encryption.mdwn
 create mode 100644 doc/forum/Crippled_FS__58___remove_read_perms_from_dropped_files__63___.mdwn
 create mode 100644 doc/forum/Crippled_FS__58___remove_read_perms_from_dropped_files__63___/comment_1_53941b83ff173025934e002a26031d9b._comment
 create mode 100644 doc/forum/Curious_file_in_repository.mdwn
 create mode 100644 doc/forum/DBus_on_Ubuntu_12.04__63__.mdwn
 create mode 100644 doc/forum/DBus_on_Ubuntu_12.04__63__/comment_1_dc14a40b64b7eda94d1a3fd766cd39cc._comment
 create mode 100644 doc/forum/DBus_on_Ubuntu_12.04__63__/comment_2_608a30e274e6a691a39f69503720e320._comment
 create mode 100644 doc/forum/DBus_on_Ubuntu_12.04__63__/comment_3_791b9978b410c1aff7fd8ef05c38f5f9._comment
 create mode 100644 doc/forum/DBus_on_Ubuntu_12.04__63__/comment_4_8665c95299916138c4af375626d9ec7d._comment
 create mode 100644 doc/forum/DO_NOT_use_ntfs-3g_on_mac_osx_for_annex.mdwn
 create mode 100644 doc/forum/DS__95__Store_files_are_not_added.mdwn
 create mode 100644 doc/forum/DS__95__Store_files_are_not_added/comment_1_30687306da9bd35ec02a806193c5e240._comment
 create mode 100644 doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper.mdwn
 create mode 100644 doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper/comment_1_d2640d4cd5bd28df5ecf389d17a2e52b._comment
 create mode 100644 doc/forum/Data_loss_if_symlink_target_edited.mdwn
 create mode 100644 doc/forum/Data_loss_if_symlink_target_edited/comment_1_599b96a2299f3c998f0317f4321eeff4._comment
 create mode 100644 doc/forum/Data_not_synced_from_my_local_repos_to_amazon.mdwn
 create mode 100644 doc/forum/Dead_repo_content_is_not_considered_unused.mdwn
 create mode 100644 doc/forum/Dead_repo_content_is_not_considered_unused/comment_1_e78552e939891b950a8352e4e3bdff92._comment
 create mode 100644 doc/forum/Dealing_with_crippled_Android_file_system.mdwn
 create mode 100644 doc/forum/Dealing_with_crippled_Android_file_system/comment_1_1b17852211108d9ab4d3959d7f57a9df._comment
 create mode 100644 doc/forum/Dealing_with_crippled_Android_file_system/comment_2_af66edabeeafcefb45b1d5c5d13dda92._comment
 create mode 100644 doc/forum/Dealing_with_crippled_Android_file_system/comment_3_8a555490bf1735c2f05a95cdb281ec80._comment
 create mode 100644 doc/forum/Dealing_with_crippled_Android_file_system/comment_4_051a08b7acd718ebae66a6aab69edb6e._comment
 create mode 100644 doc/forum/Dealing_with_crippled_Android_file_system/comment_5_a210b77d8567643667bbe92b40b5bef0._comment
 create mode 100644 doc/forum/Dealing_with_crippled_Android_file_system/comment_6_91f81669519dbf1dfbad2259f48ab99d._comment
 create mode 100644 doc/forum/Dealing_with_crippled_Android_file_system/comment_7_087fdae633144482473c7391ea338c5c._comment
 create mode 100644 doc/forum/Dealing_with_crippled_Android_file_system/comment_8_a2bafe08ff3e7a236ba560dafc9c4d85._comment
 create mode 100644 doc/forum/Dealing_with_long_filenames.mdwn
 create mode 100644 doc/forum/Dealing_with_long_filenames/comment_1_373798ea9763d3a0be5ce78f7e3f79f0._comment
 create mode 100644 doc/forum/Debugging_Git_Annex.mdwn
 create mode 100644 doc/forum/Debugging_Git_Annex/comment_1_ce63b2ee641a2338f1ad5ded9e6f09a8._comment
 create mode 100644 doc/forum/Debugging_Git_Annex/comment_2_1d70ff052d00f33c34fd45730ea13040._comment
 create mode 100644 doc/forum/Debugging_of_transfer_considerations.mdwn
 create mode 100644 doc/forum/Debugging_of_transfer_considerations/comment_1_e68ab187c15b3b6f9384a990da07f358._comment
 create mode 100644 doc/forum/Debugging_of_transfer_considerations/comment_2_f7cd207b08fe365d0a6248316c91ed78._comment
 create mode 100644 doc/forum/Debugging_of_transfer_considerations/comment_3_508b5b4155f0f9c0c2a7d2e990a1bf92._comment
 create mode 100644 doc/forum/Deduplication_in_direct_mode.mdwn
 create mode 100644 doc/forum/Deduplication_in_direct_mode/comment_1_cb8eaa8c19f5bb9e145a5e4c8995a8ca._comment
 create mode 100644 doc/forum/Default_annex.largefiles.mdwn
 create mode 100644 doc/forum/Default_annex.largefiles/comment_1_74a3ad2388e41f1ff17f64a00485a35a._comment
 create mode 100644 doc/forum/Default_text__47__html_handler.mdwn
 create mode 100644 doc/forum/Default_text__47__html_handler/comment_1_4730061916c7e12b7a41906152f847ee._comment
 create mode 100644 doc/forum/Delete_unused_files__47__metadata.mdwn
 create mode 100644 doc/forum/Delete_unused_files__47__metadata/comment_1_3efc19895c8dec89b71ae3778b583fea._comment
 create mode 100644 doc/forum/Delete_unused_files__47__metadata/comment_2_23597d9468347b3d94257f3c02afe1b8._comment
 create mode 100644 doc/forum/Deleting_remotes_doesn__39__t_work__8230__.mdwn
 create mode 100644 doc/forum/Deleting_remotes_doesn__39__t_work__8230__/comment_1_01d244f44d439ad08681af88284103c8._comment
 create mode 100644 doc/forum/Deleting_remotes_doesn__39__t_work__8230__/comment_2_a33c699726e5a913da72671ceb9be989._comment
 create mode 100644 doc/forum/Desktop_as_transfer_repository.mdwn
 create mode 100644 doc/forum/Desktop_as_transfer_repository/comment_1_b211b8f0ab58b8e59ce31d6ed6cb3c8c._comment
 create mode 100644 doc/forum/Desktop_as_transfer_repository/comment_2_9a943bcfe7679e469acc6fa1f78324b7._comment
 create mode 100644 doc/forum/Desktop_as_transfer_repository/comment_3_17165386df0c8c0085de29659f46f084._comment
 create mode 100644 doc/forum/Desktop_as_transfer_repository/comment_4_986e7d7bb536685f48731ffbbab4dc7c._comment
 create mode 100644 doc/forum/Detached_git_work_tree__63__.mdwn
 create mode 100644 doc/forum/Detached_git_work_tree__63__/comment_10_656c737772bf92be2c7a2f33bd2bb0f0._comment
 create mode 100644 doc/forum/Detached_git_work_tree__63__/comment_1_28ac35a325fba250721d9f1b7c994960._comment
 create mode 100644 doc/forum/Detached_git_work_tree__63__/comment_2_7128c26bbc8efea04a5a317edf0ca9f2._comment
 create mode 100644 doc/forum/Detached_git_work_tree__63__/comment_3_a3c22f905748ff2c803e8621c74a87a0._comment
 create mode 100644 doc/forum/Detached_git_work_tree__63__/comment_4_8063921241760458349e7cb0cadf3d4e._comment
 create mode 100644 doc/forum/Detached_git_work_tree__63__/comment_5_4510a787255cb03e7d0c3e7b830b7d52._comment
 create mode 100644 doc/forum/Detached_git_work_tree__63__/comment_6_ffd9c67ecc5b46ae98996018573f5591._comment
 create mode 100644 doc/forum/Detached_git_work_tree__63__/comment_7_36ca007643c983604fc4aed6ec8cb3d2._comment
 create mode 100644 doc/forum/Detached_git_work_tree__63__/comment_8_b7a2da4fbace7156e11c48a496a19dc9._comment
 create mode 100644 doc/forum/Detached_git_work_tree__63__/comment_9_f9fa237a693d28178f0451799209f7e2._comment
 create mode 100644 doc/forum/Difference_between_copy__44___move_and_get__63__.mdwn
 create mode 100644 doc/forum/Difference_between_copy__44___move_and_get__63__/comment_1_26ee8192af3a62178c1ccf17c6da5ca5._comment
 create mode 100644 doc/forum/Differences_between_unlocked_and_directory_remote.mdwn
 create mode 100644 doc/forum/Differences_between_unlocked_and_directory_remote/comment_1_6f4501e32029b1dbb52c9a7b4d2f17a0._comment
 create mode 100644 doc/forum/Differences_between_unlocked_and_directory_remote/comment_2_164489438245c38383645822a93cb80c._comment
 create mode 100644 doc/forum/Different_annexes_pointing_to_same_special_remote__63__.mdwn
 create mode 100644 doc/forum/Different_annexes_pointing_to_same_special_remote__63__/comment_1_359f46805e6508d03aadd90429937546._comment
 create mode 100644 doc/forum/Different_branches_for_different_devices__63__.mdwn
 create mode 100644 doc/forum/Different_branches_for_different_devices__63__/comment_1_a7d2c26298e8da715e1deb13baaf002e._comment
 create mode 100644 doc/forum/Different_branches_for_different_devices__63__/comment_2_214c71d2ab43e4d1bf564ea8337909b7._comment
 create mode 100644 doc/forum/Different_branches_for_different_devices__63__/comment_3_534f1e2cfcc0b6d184ef4968ec33dc89._comment
 create mode 100644 doc/forum/Different_preferred_content_for_subdirs.mdwn
 create mode 100644 doc/forum/Different_preferred_content_for_subdirs/comment_1_5c1e1e6375360cc9416821085b5a68a8._comment
 create mode 100644 doc/forum/Different_preferred_content_for_subdirs/comment_2_cc72b229b0a9a8f0ae0f42d6c2a145fd._comment
 create mode 100644 doc/forum/Different_preferred_content_for_subdirs/comment_3_c6764ea73c13b59645f1b378e77984b6._comment
 create mode 100644 doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__.mdwn
 create mode 100644 doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_1_67ac7e8b53a4374baf640d32dac79030._comment
 create mode 100644 doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_2_eb6df2bfcb3892ae22050a8c5f67ee90._comment
 create mode 100644 doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_3_15f36487383a631f16e041e2885c44ec._comment
 create mode 100644 doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_4_9293831aff5b6cef490f65d03638d34d._comment
 create mode 100644 doc/forum/Direct_special_remotes.mdwn
 create mode 100644 doc/forum/Direct_special_remotes/comment_1_50357130a1c57ad2fab70f71925faf02._comment
 create mode 100644 doc/forum/Direct_special_remotes/comment_2_e94a722ca056a068bcc16eb822008602._comment
 create mode 100644 doc/forum/Direct_special_remotes/comment_4_187036bbfee0508e2914afb51ead3c71._comment
 create mode 100644 doc/forum/Direct_special_remotes/comment_4_6bfbf60f2061d49b7d34c844e7e1dea2._comment
 create mode 100644 doc/forum/Direct_special_remotes/comment_5_69c34c655e4b153dfc0d1b8580091124._comment
 create mode 100644 doc/forum/Direct_special_remotes/comment_6_b054cfc3d3f81873f3faae7eb4f5337c._comment
 create mode 100644 doc/forum/Direct_special_remotes/comment_7_5f9d8a0ef2f13f242594848825d29ee7._comment
 create mode 100644 doc/forum/Disable_autoswitching_to_adjusted__40__unlocked__41___branch.mdwn
 create mode 100644 doc/forum/Disable_ssl_verification__63__.mdwn
 create mode 100644 doc/forum/Disable_ssl_verification__63__/comment_1_39af4df2a16e363f93f75a7a57af048c._comment
 create mode 100644 doc/forum/Disable_ssl_verification__63__/comment_2_8ff8769a1e62caf4f515b04db38d13f0._comment
 create mode 100644 doc/forum/Disable_ssl_verification__63__/comment_3_cf39af1d8ff11ab602363a717be074c6._comment
 create mode 100644 doc/forum/Disadvantages_of_WORM__58___long_filename__63__.mdwn
 create mode 100644 doc/forum/Disadvantages_of_WORM__58___long_filename__63__/comment_1_cc5502b55fb71c8fdb235ea9d17216ff._comment
 create mode 100644 doc/forum/Disadvantages_of_WORM__58___long_filename__63__/comment_2_d04b7adcc17a305fb1d7f1c1a3641be1._comment
 create mode 100644 doc/forum/Disconnected_Archive_and_Backups.mdwn
 create mode 100644 doc/forum/Disconnected_Archive_and_Backups/comment_1_c56f2d3328c0d127efc21067dc52df15._comment
 create mode 100644 doc/forum/Disconnected_Archive_and_Backups/comment_2_63b934b773b5f7a3c128dd9685f671ab._comment
 create mode 100644 doc/forum/Disconnected_Archive_and_Backups/comment_3_fae320f7453cf8c7147a109f19be22ba._comment
 create mode 100644 doc/forum/Disconnected_Archive_and_Backups/comment_4_b3d39d1b85489ce4059a72b9a912624c._comment
 create mode 100644 doc/forum/Disconnected_Archive_and_Backups/comment_5_93bed4629304725297f88cfa3d494720._comment
 create mode 100644 doc/forum/Disk_usage_during___96__import__96__.mdwn
 create mode 100644 doc/forum/Disk_usage_during___96__import__96__/comment_1_3ed4d9a36cacb9be96860cfaae8cee90._comment
 create mode 100644 doc/forum/Distributing_data_to_a_set_of_drives.mdwn
 create mode 100644 doc/forum/Distributing_data_to_a_set_of_drives/comment_1_f1fa72879f4e1db13bf59dea33c91624._comment
 create mode 100644 doc/forum/Distributing_data_to_a_set_of_drives/comment_2_e13b4e5c1e6f1f503f93d521b504d5c1._comment
 create mode 100644 doc/forum/Do_I_have_naming_ssh_remote_issue__63__.mdwn
 create mode 100644 doc/forum/Do_I_have_naming_ssh_remote_issue__63__/comment_1_f3e5ef9d7440cba467ebda1f2e8b12ea._comment
 create mode 100644 doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__.mdwn
 create mode 100644 doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__/comment_1_f290dd8547176793934f8077374e1c0a._comment
 create mode 100644 doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__/comment_2_c358eb51047f333e582bd824be5e0e65._comment
 create mode 100644 doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__/comment_3_a2332c0e7b29110b9aed2ab69ce9d8c4._comment
 create mode 100644 doc/forum/Does_git-annex_version_big_files__63__.mdwn
 create mode 100644 doc/forum/Does_git-annex_version_big_files__63__/comment_1_0b44003c1dc53adb807298ae452f8004._comment
 create mode 100644 doc/forum/Does_git-annex_version_big_files__63__/comment_2_ca40b67abd7bd36155d16d0396d7472c._comment
 create mode 100644 doc/forum/Does_git-annex_version_big_files__63__/comment_3_32de3501feedce51b43ed9dcc399c7a9._comment
 create mode 100644 doc/forum/Does_git-annex_version_big_files__63__/comment_4_8c65a7f8bda3c876971c2801fb6a76a1._comment
 create mode 100644 doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__.mdwn
 create mode 100644 doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_1_25572571debe2c91447b0ed952f45cb2._comment
 create mode 100644 doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_2_46c27b242c6df76f9df198bbd6f14030._comment
 create mode 100644 doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_3_2d9baeb81857b354931251a8b8a756e5._comment
 create mode 100644 doc/forum/Does_migrate_ensure_data_integrity__63__.mdwn
 create mode 100644 doc/forum/Does_migrate_ensure_data_integrity__63__/comment_1_cef50b32c46f4406c6f918c5866ddc15._comment
 create mode 100644 doc/forum/Does_migrate_ensure_data_integrity__63__/comment_2_f389b924c8531b35fdf5dedd10fc8000._comment
 create mode 100644 doc/forum/Does_the_windows_version_install_iStartSurf_malware__63__.mdwn
 create mode 100644 doc/forum/Does_the_windows_version_install_iStartSurf_malware__63__/comment_1_0536085a1f969802a7e8607093eee97d._comment
 create mode 100644 doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote.mdwn
 create mode 100644 doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_1_9f8e1ac58e319540b3d9a5b9962e1f8f._comment
 create mode 100644 doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_2_f398f38ff29d2e681548b1640080dff3._comment
 create mode 100644 doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_3_53759e189b2f13b8ea1f48f3b6fb7fca._comment
 create mode 100644 doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_4_c3d9048668596f6be3975026ec1debc1._comment
 create mode 100644 doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_5_e9ea995c99785dd6dffba91ef0fceb02._comment
 create mode 100644 doc/forum/Don__39__t_understand_how_to_delete__47__recover_files.mdwn
 create mode 100644 doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_1_b307bfb0b70d649897f411eb753bd50a._comment
 create mode 100644 doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_2_58a6a1476274b8c4feb3d43ecd998759._comment
 create mode 100644 doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_3_4b857f481db7b2437ac9f8137a8510e2._comment
 create mode 100644 doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_4_828db3bf2863d98c0b0fb4074aa7f066._comment
 create mode 100644 doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_5_cb2063d6a4e08a5c12bf3723d0fa74e0._comment
 create mode 100644 doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_6_1759bcd5708f591f91b9c410f6dc5c54._comment
 create mode 100644 doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_7_2a389f01eb5131042ea1e71a73c9787a._comment
 create mode 100644 doc/forum/Don__39__t_understand_local_vs._known_keys.mdwn
 create mode 100644 doc/forum/Don__39__t_understand_local_vs._known_keys/comment_1_10749c0d76e824217dd1ff8c8a6e42a5._comment
 create mode 100644 doc/forum/Don__39__t_understand_local_vs._known_keys/comment_2_db9f1b6d9638c2b0a7e241c2727e8cfb._comment
 create mode 100644 doc/forum/Don__39__t_understand_sync_with_ssh_remote.mdwn
 create mode 100644 doc/forum/Don__39__t_understand_sync_with_ssh_remote/comment_1_be10d6b564e130f4a516d438831681d1._comment
 create mode 100644 doc/forum/Drop__47__move_unused_files_older_than_x.mdwn
 create mode 100644 doc/forum/Drop__47__move_unused_files_older_than_x/comment_1_626facc640a9018a04f203d10aff7676._comment
 create mode 100644 doc/forum/Drop_some_unused_objects_keeping___35__n_more_recent.mdwn
 create mode 100644 doc/forum/Drop_some_unused_objects_keeping___35__n_more_recent/comment_1_2e16a4c08568ea37c16f4ea74203ae12._comment
 create mode 100644 doc/forum/Drop_with_assistant.mdwn
 create mode 100644 doc/forum/Drop_with_assistant/comment_1_048f5a31c549afb19b76a65bddd0cd24._comment
 create mode 100644 doc/forum/Drop_with_assistant/comment_2_527d7b6a8efa85b904111f179912d926._comment
 create mode 100644 doc/forum/Drop_with_assistant/comment_3_c50857506869bb1cd306b66acf37fba8._comment
 create mode 100644 doc/forum/Drop_with_assistant/comment_4_1ea37445d5eb96c3efa182e88e07b867._comment
 create mode 100644 doc/forum/Drop_with_assistant/comment_5_c08908ea5232cbe067c73ecd12d0e218._comment
 create mode 100644 doc/forum/Drop_with_assistant/comment_6_015134228cb865f97326fbb7193636ea._comment
 create mode 100644 doc/forum/Drop_with_assistant/comment_7_950759930667588f21659cd6d7065fbb._comment
 create mode 100644 doc/forum/Drop_with_assistant/comment_8_773e540e46adc43487323e8d38ceb2d9._comment
 create mode 100644 doc/forum/Drop_with_assistant/comment_9_d85d120d7219ea6c179c2619a17bdae9._comment
 create mode 100644 doc/forum/Dropping_checksum_from_URL_key.mdwn
 create mode 100644 doc/forum/Dropping_checksum_from_URL_key/comment_1_ce952a9db35d398a9e67adcd7f927d59._comment
 create mode 100644 doc/forum/Dropping_checksum_from_URL_key/comment_2_bb458296d464c2025f96502338f34000._comment
 create mode 100644 doc/forum/Dropping_files_in_an_annex.thin_v7_repository.mdwn
 create mode 100644 doc/forum/Dropping_files_in_an_annex.thin_v7_repository/comment_1_9f2dcdfe6a689902f348211db6b7a758._comment
 create mode 100644 doc/forum/Duplicate_entries_in_location_tracking_logs.mdwn
 create mode 100644 doc/forum/Duplicate_entries_in_location_tracking_logs/comment_1_3afb76397519b8ca8b55958a344f1871._comment
 create mode 100644 doc/forum/Duplicate_entries_in_location_tracking_logs/comment_2_6f327444772ee1e660a12e7442162df5._comment
 create mode 100644 doc/forum/Duplicate_files_not_detected.mdwn
 create mode 100644 doc/forum/Duplicate_files_not_detected/comment_1_d49a34aae5decafed804f45a573c0027._comment
 create mode 100644 doc/forum/Duplicate_files_not_detected/comment_2_c1afe87e818ac3eea66d5216bb15d727._comment
 create mode 100644 doc/forum/Duplicate_files_not_detected/comment_3_c07b9634f571b5f12665b368c0ad3c80._comment
 create mode 100644 doc/forum/Editing_Metadata_in_your___36__EDITOR.mdwn
 create mode 100644 doc/forum/Editing_files_in_metadata_driven_view.mdwn
 create mode 100644 doc/forum/Editing_files_in_metadata_driven_view/comment_1_acb4656e0dafc5689c84d4cca760bafa._comment
 create mode 100644 doc/forum/Effectively_replicating_backup_files.mdwn
 create mode 100644 doc/forum/Effectively_replicating_backup_files/comment_1_b1ab0da82db076c5244b0dcc95282ddd._comment
 create mode 100644 doc/forum/Effectively_replicating_backup_files/comment_2_472ab9c973b475f7f3ce7e3934f94281._comment
 create mode 100644 doc/forum/Effectively_replicating_backup_files/comment_3_826493bd59b81786c1f6a56f1c438004._comment
 create mode 100644 doc/forum/Efficiently_move_files_from_one_repo_to_another.mdwn
 create mode 100644 doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_10_191ca3a984412be76f64aa31b55b8d50._comment
 create mode 100644 doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_1_0cc04ef5e511241a5152a0702f943538._comment
 create mode 100644 doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_2_be029c0880e76d6b5672eed394140438._comment
 create mode 100644 doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_3_c2f4b10fa1789a4966aed298e00dbc75._comment
 create mode 100644 doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_4_65bbee3637d09bb6078ec7b118852fd8._comment
 create mode 100644 doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_5_45c1788b39953cd7237f014fa94e086b._comment
 create mode 100644 doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_6_23b3a1a1412866fa06e736f0f5bab583._comment
 create mode 100644 doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_7_fba097cd3187d1d8b7517594d875c373._comment
 create mode 100644 doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_8_b8f81522e519bab56036cc8628f29ce9._comment
 create mode 100644 doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_9_3e5f41a5cce30c21cea629009f91dd31._comment
 create mode 100644 doc/forum/Encrypted_Content_Remote_Daemon_.mdwn
 create mode 100644 doc/forum/Encrypted_Content_Remote_Daemon_/comment_1_96f63e509e23c081c48302274e21db78._comment
 create mode 100644 doc/forum/Encrypted_Content_Remote_Daemon_/comment_2_acd0ffdc3f5079265858073c2af81557._comment
 create mode 100644 doc/forum/Encrypted_ssh_remote__44___synced_folders.mdwn
 create mode 100644 doc/forum/Encrypted_ssh_remote__44___synced_folders/comment_1_7b9b4ef614c90e0b222d24678d1b9026._comment
 create mode 100644 doc/forum/Ensure_all_versions_are_on_remotes.mdwn
 create mode 100644 doc/forum/Ensure_all_versions_are_on_remotes/comment_1_b8b674dc99999dcdb5a435f34b96c1ea._comment
 create mode 100644 doc/forum/Ensure_all_versions_are_on_remotes/comment_2_ad5f1f0b98032361e64bb7275d23e97c._comment
 create mode 100644 doc/forum/Ensure_all_versions_are_on_remotes/comment_3_d9bd5f9ef8c8a8cc08cc39396f0a6f67._comment
 create mode 100644 doc/forum/Ensure_all_versions_are_on_remotes/comment_4_8d07699b69676d9afd53744f267bb615._comment
 create mode 100644 doc/forum/Ensure_all_versions_are_on_remotes/comment_5_2202121e5311b56b1d73f9bb1503c5e3._comment
 create mode 100644 doc/forum/Equivalent_to_git_bundle__63__.mdwn
 create mode 100644 doc/forum/Equivalent_to_git_bundle__63__/comment_1_e42936a9bc36fbee69f48e32df303dee._comment
 create mode 100644 doc/forum/Equivalent_to_git_bundle__63__/comment_2_2b8b5c237d8572fdd27202f3502bea96._comment
 create mode 100644 doc/forum/Error__58___failed_to_push_some_refs.mdwn
 create mode 100644 doc/forum/Error_adding_ssh_remote_in_assistant.mdwn
 create mode 100644 doc/forum/Error_adding_ssh_remote_in_assistant/comment_1_eecc0660db4083cc91c5330587f74610._comment
 create mode 100644 doc/forum/Error_adding_ssh_remote_in_assistant/comment_2_3e6aad22e8020b12ff7ef914b75281d1._comment
 create mode 100644 doc/forum/Error_adding_ssh_remote_in_assistant/comment_3_3ea529e16502071fc0980c6d5c60a036._comment
 create mode 100644 doc/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote.mdwn
 create mode 100644 doc/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote/comment_1_2a69ce8607f97aabdf3cc402c1091d7a._comment
 create mode 100644 doc/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote/comment_2_a112f0bc1a30fa41504e3f52f679053b._comment
 create mode 100644 doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__.mdwn
 create mode 100644 doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_3_04a920f5b86a203d050ee4a9a0f8a33d._comment
 create mode 100644 doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_4_b43fda0acca8cc9027f36f51b9489aa3._comment
 create mode 100644 doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_5_380240e562358efb25a8acb65b5d4cc7._comment
 create mode 100644 doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_5_752b1c3e2394ef432c1e21a5639648be._comment
 create mode 100644 doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_6_e5d4ba2bb9f78380dfa94446cb1f4b54._comment
 create mode 100644 doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_7_cec779ef77336ea30728815739be78b6._comment
 create mode 100644 doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_7_e349403ef92a96a08195a7dd1dbf9561._comment
 create mode 100644 doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_8_bca507381436a8282645a931aa39fb20._comment
 create mode 100644 doc/forum/Exclude_specific_files_from_a_special_remote.mdwn
 create mode 100644 doc/forum/Exclude_specific_files_from_a_special_remote/comment_1_d5a9f3308e09a9b9460014904d23ef48._comment
 create mode 100644 doc/forum/Exclude_specific_files_from_a_special_remote/comment_2_671790686bd4724aadcadd8d8aad2c98._comment
 create mode 100644 doc/forum/Export_files_that_aren__39__t_locally_present__63__.mdwn
 create mode 100644 doc/forum/Export_files_that_aren__39__t_locally_present__63__/comment_1_278b70c7bd7397e634df4a257fb604f9._comment
 create mode 100644 doc/forum/Exporting_files_to_special_remote__44___even_if_not_in_preferred_contents.mdwn
 create mode 100644 doc/forum/Exporting_files_to_special_remote__44___even_if_not_in_preferred_contents/comment_1_8276c225867733e7a79ba47be2447b1e._comment
 create mode 100644 doc/forum/Exporting_files_to_special_remote__44___even_if_not_in_preferred_contents/comment_2_dc1e718d0043686987abc9526a459dc3._comment
 create mode 100644 doc/forum/External_drive_syncs_git-annex_branch_but_not_master_branch.mdwn
 create mode 100644 doc/forum/External_drive_syncs_git-annex_branch_but_not_master_branch/comment_1_9a909e3d89061adacbd8ed370520250c._comment
 create mode 100644 doc/forum/External_drive_syncs_git-annex_branch_but_not_master_branch/comment_2_0dd489b264374b7b1065b89e1ff7561b._comment
 create mode 100644 doc/forum/Extra___38___missing_folders_on_remote.mdwn
 create mode 100644 doc/forum/Failed_to_push_on_git-lfs.mdwn
 create mode 100644 doc/forum/Failed_to_push_on_git-lfs/comment_1_f83dbcfdd09de3ce908c0d4a9daef458._comment
 create mode 100644 doc/forum/Failed_to_push_on_git-lfs/comment_2_52051b251bea7a5ed452769d0320602a._comment
 create mode 100644 doc/forum/Failing_to_get_files_from_rclone_special_remote.mdwn
 create mode 100644 doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_1_4a762c369e4049bdedecca4a32242f18._comment
 create mode 100644 doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_2_cfb6be6c940350dbed6cc9e98ee1d633._comment
 create mode 100644 doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_3_58282be918139a3154938850793a80fb._comment
 create mode 100644 doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_4_1360ee3e3b711990f59e0320e7892cd2._comment
 create mode 100644 doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__.mdwn
 create mode 100644 doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_1_c769dcbb9d5f082d54b8a091a44c9de4._comment
 create mode 100644 doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_2_50e35159f7e670ca6b7280121821b494._comment
 create mode 100644 doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_3_471ff0cdb00b311f2a3d801b04e9edef._comment
 create mode 100644 doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_4_e0f80d306a2b4d19d65d268cde25ac31._comment
 create mode 100644 doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_4_f648049cc1a82f183bbc7dc84cd170e2._comment
 create mode 100644 doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_6_c2686480c6c77ea7297f739780ea6d3b._comment
 create mode 100644 doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_7_6f3d056e449366746aef4f45673515d5._comment
 create mode 100644 doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_8_785e012f478631f4b69fefbd0394f1b8._comment
 create mode 100644 doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_9_e021705e0fae6645a0b6459757260084._comment
 create mode 100644 doc/forum/Fast_cloning_a_repo_initially.mdwn
 create mode 100644 doc/forum/Fast_cloning_a_repo_initially/comment_1_0db0caafe30dd1b6f15fb1679dec8f9f._comment
 create mode 100644 doc/forum/Fast_cloning_a_repo_initially/comment_2_e17abc209c2b3ba20158be76801ce04a._comment
 create mode 100644 doc/forum/Feature_Request__58___Specify_file_size_when_adding_files_to_URL_backend.mdwn
 create mode 100644 doc/forum/Feature_Request__58___Specify_file_size_when_adding_files_to_URL_backend/comment_1_9d2fa7d796fd40718d0df9feeea654aa._comment
 create mode 100644 doc/forum/Feature_Request__58___add_filename_to_hash_objects.mdwn
 create mode 100644 doc/forum/Feature_Request__58___add_filename_to_hash_objects/comment_1_73dc0a9cad486cf2d34faf064c6193b1._comment
 create mode 100644 doc/forum/Feature_Request__58___add_filename_to_hash_objects/comment_2_f818b3ecfeb1d1dd83df4668c061718a._comment
 create mode 100644 doc/forum/Feature_request__58___--quiet_for_fsck__44___import__44___etc.mdwn
 create mode 100644 doc/forum/Feature_request__58___--quiet_for_fsck__44___import__44___etc/comment_1_cbcc3df01a346c6ee6720c90421ee023._comment
 create mode 100644 doc/forum/Feature_request__58___Multiple_concurrent_transfers.mdwn
 create mode 100644 doc/forum/Feature_request__58___Multiple_concurrent_transfers/comment_1_aa666349e9b524fd5394a259ad622c3b._comment
 create mode 100644 doc/forum/Feature_request__58___git_annex_copy_--auto_does_the_right_thing.mdwn
 create mode 100644 doc/forum/Feature_request__58___git_annex_copy_--auto_does_the_right_thing/comment_1_bbac7d0810a79eb1f42a01e1b31d5c4c._comment
 create mode 100644 doc/forum/Feature_request__58___webapp_support_for_centralized_bare_repos.mdwn
 create mode 100644 doc/forum/Feature_request__58___webapp_support_for_centralized_bare_repos/comment_1_0522e3df450efb6b2d264857e07997dc._comment
 create mode 100644 doc/forum/Feature_request__58___webapp_support_for_centralized_bare_repos/comment_2_e0fc126b0d500d41a563b076a4f6ed6d._comment
 create mode 100644 doc/forum/File_downloaded_again_and_again.mdwn
 create mode 100644 doc/forum/File_downloaded_again_and_again/comment_1_666b907935d467d5d7c0e57831d76631._comment
 create mode 100644 doc/forum/File_history.mdwn
 create mode 100644 doc/forum/File_history/comment_1_6c15cdf71b99ae3bf8fd5de489a7d3ee._comment
 create mode 100644 doc/forum/File_history/comment_2_ebe8025d4769d22cafa81ad0f2ae969a._comment
 create mode 100644 doc/forum/File_history/comment_3_16aae9a5fdd5cfed816f5cdd96adf7ba._comment
 create mode 100644 doc/forum/File_history/comment_4_1b72655106507f111192231ab62cbe7e._comment
 create mode 100644 doc/forum/File_history/comment_5_72d1b2ff307df69add474a288f92d8c3._comment
 create mode 100644 doc/forum/File_still_symlinked_after_git_annex_unannex.mdwn
 create mode 100644 doc/forum/File_still_symlinked_after_git_annex_unannex/comment_1_55f1a5f16fe2f8a85034a85c5450bad2._comment
 create mode 100644 doc/forum/File_too_big_for_file_system_of_git_remote.mdwn
 create mode 100644 doc/forum/File_too_big_for_file_system_of_git_remote/comment_1_937df2f51506c42ddd2345735efd8f21._comment
 create mode 100644 doc/forum/Filesystem_recommendation___40__ext4__44___btrfs__44___xfs__44___you_name_it__41____63__.mdwn
 create mode 100644 doc/forum/Filesystem_recommendation___40__ext4__44___btrfs__44___xfs__44___you_name_it__41____63__/comment_1_fcf7f132f771de28553bd20f4fb014cb._comment
 create mode 100644 doc/forum/Filing_issues_with_Mac_dmg_packaging_on_downloads.kitenet.net__63__.mdwn
 create mode 100644 doc/forum/Filing_issues_with_Mac_dmg_packaging_on_downloads.kitenet.net__63__/comment_1_0d89d709e799442d77b0fc92f97fc3ae._comment
 create mode 100644 doc/forum/Filing_issues_with_Mac_dmg_packaging_on_downloads.kitenet.net__63__/comment_2_cccbc5c1d9b010ae38a8b5cfd9056cfe._comment
 create mode 100644 doc/forum/Find_files_that_lack_a_certain_field_in_metadata.mdwn
 create mode 100644 doc/forum/Find_files_that_lack_a_certain_field_in_metadata/comment_1_476e52563ccd3ad1b43e3a2da4dfaa82._comment
 create mode 100644 doc/forum/Find_out_if_file_is_in_annex__63__.mdwn
 create mode 100644 doc/forum/Find_out_if_file_is_in_annex__63__/comment_1_3936ff53d5c9f7e5795b15beadf437c7._comment
 create mode 100644 doc/forum/Find_unlocked__47__locked_files.mdwn
 create mode 100644 doc/forum/Find_unlocked__47__locked_files/comment_1_a34ce29b644c80789bf8cbfd575ffe1a._comment
 create mode 100644 doc/forum/Find_unlocked__47__locked_files/comment_2_85d90a43142d087e7b6183dd9f8be8cf._comment
 create mode 100644 doc/forum/Finding_out_why_file_is_not_being_auto-dropped.mdwn
 create mode 100644 doc/forum/Finding_out_why_file_is_not_being_auto-dropped/comment_1_d3881fe94e3588c90e74c6bb3db2783c._comment
 create mode 100644 doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__.mdwn
 create mode 100644 doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_1_97c261b9080c5ecc5424683066bbe05b._comment
 create mode 100644 doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_2_ae45f9703b635c235409682cf252d36c._comment
 create mode 100644 doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_3_066ca31a2e5dfe55a58092ba85231c7c._comment
 create mode 100644 doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_4_a0a9f7f44cadb8036fcddfc21bb0781f._comment
 create mode 100644 doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_5_92240b3f8629f1f2bbe1829700082a79._comment
 create mode 100644 doc/forum/Fix_duplicate_UUID.mdwn
 create mode 100644 doc/forum/Fix_duplicate_UUID/comment_1_1186caf5aa6830c2412f8584a43d8d86._comment
 create mode 100644 doc/forum/Fix_duplicate_UUID/comment_2_b0f06b58ef63dbb770773f28dfa1a29d._comment
 create mode 100644 doc/forum/Fix_duplicate_UUID/comment_3_525b2838985392eb65e705ad354d02c4._comment
 create mode 100644 doc/forum/Fix_duplicate_UUID/comment_4_ce58bf264e63a07a214956436d96f1a5._comment
 create mode 100644 doc/forum/Fix_wrong_rsync_with_git_annex_reinit__63__.mdwn
 create mode 100644 doc/forum/Fix_wrong_rsync_with_git_annex_reinit__63__/comment_1_26cb6d46a408c1002aa2fbc6618242f3._comment
 create mode 100644 doc/forum/Fix_wrong_rsync_with_git_annex_reinit__63__/comment_2_14ddf5ddf2b85c9d5ed5ca070744f1fe._comment
 create mode 100644 doc/forum/Fixing_up_corrupt_annexes.mdwn
 create mode 100644 doc/forum/Fixing_up_corrupt_annexes/comment_1_cea21f96bcfb56aaab7ea03c1c804d2d._comment
 create mode 100644 doc/forum/Fixing_up_corrupt_annexes/comment_2_5cdd2fcfa61b3f6255e5ad63a3ab00ce._comment
 create mode 100644 doc/forum/Folders_for___34__actions__34___-_now_that_views_have_disrupted_the_file_structure__63__.mdwn
 create mode 100644 doc/forum/Forcing_offline_copies_seem_available.mdwn
 create mode 100644 doc/forum/Forcing_offline_copies_seem_available/comment_1_75e8597a24c925981edf83c517d5a799._comment
 create mode 100644 doc/forum/Forcing_offline_copies_seem_available/comment_2_7d0e219628ad19093c6b6410d24c5f9a._comment
 create mode 100644 doc/forum/Forcing_offline_copies_seem_available/comment_3_3d57e187679b36be62f3918eb996c3df._comment
 create mode 100644 doc/forum/Forcing_one_repo_to_contain_a_copy_of_all_files.mdwn
 create mode 100644 doc/forum/Forcing_one_repo_to_contain_a_copy_of_all_files/comment_1_702b1b94c735f1b9cde16daa77a80c12._comment
 create mode 100644 doc/forum/Forcing_one_repo_to_contain_a_copy_of_all_files/comment_2_3df7fcbcd482bb9377ead238b314995b._comment
 create mode 100644 doc/forum/Forget_about_accidentally_added_file__63__.mdwn
 create mode 100644 doc/forum/Forget_about_accidentally_added_file__63__/comment_1_a7e6b1f6abe4caf8bd93be879c960cec._comment
 create mode 100644 doc/forum/Forget_about_accidentally_added_file__63__/comment_2_6beeec3a8bc9697481aa08738902203a._comment
 create mode 100644 doc/forum/Forget_about_accidentally_added_file__63__/comment_3_6bf46255cd212942d8db8b01c95443b2._comment
 create mode 100644 doc/forum/Forget_about_accidentally_added_file__63__/comment_4_2183fee162740918e5f67f9bd460b18d._comment
 create mode 100644 doc/forum/Forget_about_accidentally_added_file__63__/comment_5_2b248738c6fb871875cf1aa7413198cc._comment
 create mode 100644 doc/forum/Forget_about_accidentally_added_file__63__/comment_6_1fcfcb5dca366d8fd610c03654e15704._comment
 create mode 100644 doc/forum/Forget_about_accidentally_added_file__63__/comment_7_a982dd633e7f29ec80c8e4362ebc064a._comment
 create mode 100644 doc/forum/Forget_about_accidentally_added_file__63__/comment_8_ed88d2b82fc3283540caf3a255a88188._comment
 create mode 100644 doc/forum/Forget_about_accidentally_added_file__63__/comment_9_23cc8cec09f9e8fb56c0cb81c9b361bc._comment
 create mode 100644 doc/forum/Fsck_by_refs_or_keys__63__.mdwn
 create mode 100644 doc/forum/Fsck_by_refs_or_keys__63__/comment_1_345daa76cdd13538054e886a755bf29d._comment
 create mode 100644 doc/forum/Fsck_by_refs_or_keys__63__/comment_2_1d74ad47cf3bef9bcc0ccdff4ccb69b9._comment
 create mode 100644 doc/forum/Fsck_by_refs_or_keys__63__/comment_3_b00a9522bb6dd91fed5d1c790153a230._comment
 create mode 100644 doc/forum/Full_restore_from_an_encrypted_special_remote.mdwn
 create mode 100644 doc/forum/Full_restore_from_an_encrypted_special_remote/comment_1_f3a7a766ae1fe8e586cd67148761f156._comment
 create mode 100644 doc/forum/Full_workflow_guide.mdwn
 create mode 100644 doc/forum/Full_workflow_guide/comment_1_14664efebb1218a1449577eaa4653a77._comment
 create mode 100644 doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote.mdwn
 create mode 100644 doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_10_2eb2f05477a86f1352e734d163301ffa._comment
 create mode 100644 doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_1_c2f7542ac9a4c423c5ae06c16d42a24f._comment
 create mode 100644 doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_2_9a9da0ad1538ba59e76a5c4f9fc7fcf7._comment
 create mode 100644 doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_3_27901f1c2c5de211f697972d9b21c104._comment
 create mode 100644 doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_4_56994d9252e8651b3f33044f5c8599b3._comment
 create mode 100644 doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_5_5aecb8c58d501e929e746d5536032c81._comment
 create mode 100644 doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_6_ab0b660e5a3d7fc7d3d3a4b460022da5._comment
 create mode 100644 doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_7_b96077c98792997cdf344725374abb5c._comment
 create mode 100644 doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_8_e9597062bbc530920343e5159a7b7ea1._comment
 create mode 100644 doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_9_756aeeee7be8cb67c5cc9dfa6ea7b82c._comment
 create mode 100644 doc/forum/Fuzzy_local_sensitive_hashing___40__LSH__41__.mdwn
 create mode 100644 doc/forum/Fuzzy_local_sensitive_hashing___40__LSH__41__/comment_1_29f2396e04251d266b68ba68b8b32215._comment
 create mode 100644 doc/forum/GIT__95__SSH.mdwn
 create mode 100644 doc/forum/GIT__95__SSH/comment_1_c2e827eeac7524845cad42671d77af95._comment
 create mode 100644 doc/forum/GPG_passphrase_handling.mdwn
 create mode 100644 doc/forum/GPG_passphrase_handling/comment_1_11ba130e8bea6698858d0a1a5b01830f._comment
 create mode 100644 doc/forum/GPG_passphrase_handling/comment_2_ef9d58d15b7bbe0b3c7140bb01d73a31._comment
 create mode 100644 doc/forum/GPG_passphrase_handling/comment_3_84eb129c8483b87b3ae6ecaf8b4a8309._comment
 create mode 100644 doc/forum/GPG_passphrase_handling/comment_4_8724297f6d7ac140ab395a940bab0d7d._comment
 create mode 100644 doc/forum/General_questions_and_help.mdwn
 create mode 100644 doc/forum/General_questions_and_help/comment_1_adfef0ecc191dd2ad85b4e0f6a4df67d._comment
 create mode 100644 doc/forum/General_questions_and_help/comment_2_972231014d3da4fcd8fb2a77d76e7b77._comment
 create mode 100644 doc/forum/General_questions_and_help/comment_3_1a071d4a7e62701c47d8531c4faa9dcb._comment
 create mode 100644 doc/forum/General_questions_and_help/comment_4_51b8cd9f1b8b53bcf880ea56d1858f23._comment
 create mode 100644 doc/forum/General_questions_and_help/comment_5_0105e241e13f9469bf749735cb9f3e03._comment
 create mode 100644 doc/forum/Generating_a_Temp_View_of_Available_Files.mdwn
 create mode 100644 doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant.mdwn
 create mode 100644 doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_1_ead4b5b7ec0d085d4fa87fb4e29c4d55._comment
 create mode 100644 doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_2_835dba9de7a5eea868635dc793d4e75b._comment
 create mode 100644 doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_3_553542a4a2b2530863a006a1afe91637._comment
 create mode 100644 doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_4_4540a15672f9b48b0f9310c97f1a0b86._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__.mdwn
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_10_0ae170680841f86279b95febaafa0440._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_11_1f46bcb05d7866af35779830ceb632e2._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_12_177db535bf756cfb4c231a41cd02e137._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_13_cb4f95866113ac6f689ed9f219a1d8e1._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_14_748a794bf4cda242923177352e34976c._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_15_994e3e64184a020f9afe21cd9ea34b38._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_1_b215a9ab1c37688cc22dbe4ec63347ad._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_2_15de9ba04480697bdf4086cdf91226e4._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_3_f642798f8d1c753dca3aad67d0bd9ace._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_4_018442fba01a2aac43531f2eaecc1117._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_5_577c3dfc1f77ad0821ed8fcbbac3772c._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_6_7a3a21b3995f79710ebb5a8428709f66._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_7_95fe371e2e5083c8dc06b24b2f8d87e1._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_8_ae600abfb5a82f69981f59e9de55c056._comment
 create mode 100644 doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_9_d97c211a0e87212ffd2617a96263faa2._comment
 create mode 100644 doc/forum/Get_files_in_repository_A__44___that_do_not_exist_in_repository_B.mdwn
 create mode 100644 doc/forum/Get_files_in_repository_A__44___that_do_not_exist_in_repository_B/comment_1_c09c45c64f75bd30deaae9c8d8633236._comment
 create mode 100644 doc/forum/Get_most_recent_git-annex_version_with_anaconda.mdwn
 create mode 100644 doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_1_2987d3516235e90621335d055426a808._comment
 create mode 100644 doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_2_3046a4711853c88ba7f763fb04b73a5a._comment
 create mode 100644 doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_3_ece2ad657025186c267aeb20405ea1e5._comment
 create mode 100644 doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_4_f54f3ef05da471ff4d370511e3629e05._comment
 create mode 100644 doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_5_59365f2d382103f1f8c30d4c52085fd6._comment
 create mode 100644 doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__.mdwn
 create mode 100644 doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__/comment_1_9ff60145d7dfb6785bb11f2a23040948._comment
 create mode 100644 doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__/comment_2_7c88ebd9d7cdf4a009aa2580cc55787d._comment
 create mode 100644 doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__/comment_3_976cb63e97774859023123536bdc9d99._comment
 create mode 100644 doc/forum/Getting_metadata.mdwn
 create mode 100644 doc/forum/Getting_metadata/comment_1_24bef8f59f370897d6fd6b2b43ed1f39._comment
 create mode 100644 doc/forum/Getting_started_with_Amazon_S3.mdwn
 create mode 100644 doc/forum/Getting_started_with_Amazon_S3/comment_1_f50883133d5d4903cc95c0dcaa52d052._comment
 create mode 100644 doc/forum/Getting_started_with_Amazon_S3/comment_2_e90aa3259d9a12cd67daa27d42d69ab5._comment
 create mode 100644 doc/forum/Getting_started_with_Amazon_S3/comment_3_c3adce7c0f29e71ed9dd07103ede2c1a._comment
 create mode 100644 doc/forum/Getting_the_status_of_a_remotely_changed_annex_file.mdwn
 create mode 100644 doc/forum/Getting_the_status_of_a_remotely_changed_annex_file/comment_1_e323c21d27bb0946993ba1438429c457._comment
 create mode 100644 doc/forum/Git-Annex_Android_sync_files_are_missing_on_Linuxx.mdwn
 create mode 100644 doc/forum/Git-Annex_Android_sync_files_are_missing_on_Linuxx/comment_1_72d7811990e78fba0b7fc2e1c7ee515f._comment
 create mode 100644 doc/forum/Git-Annex_Android_sync_files_are_missing_on_Linuxx/comment_2_cfb7139958ed24c1c64f8b133c99f336._comment
 create mode 100644 doc/forum/Git-Annex_with_Asustor_NAS.mdwn
 create mode 100644 doc/forum/Git-Annex_with_Asustor_NAS/comment_1_44445200e5b716caeec225972a5d5dce._comment
 create mode 100644 doc/forum/Git-annex_and_Microsoft_Office_files_on_OS_X.mdwn
 create mode 100644 doc/forum/Git-annex_and_Microsoft_Office_files_on_OS_X/comment_1_71fdd5e7061d6deb357290057804cc27._comment
 create mode 100644 doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__.mdwn
 create mode 100644 doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_10_645af86feb8506c3ea2134badac68e0b._comment
 create mode 100644 doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_1_d9acd44c00676d814e19613d6fd276a2._comment
 create mode 100644 doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_2_45928886d1ae4a76e2daefb355967729._comment
 create mode 100644 doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_3_1249bf921ea7709b4f7ae25e613bf60a._comment
 create mode 100644 doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_4_616cb76a510fa32c2aa48c25d24c6044._comment
 create mode 100644 doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_5_100fc29a95923e5ef92eaf87d76bbc6f._comment
 create mode 100644 doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_6_9b19ae8e8c0c70e3827c9f362c1c1dea._comment
 create mode 100644 doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_7_0c1c76bb082c108f3074b725bcc272c9._comment
 create mode 100644 doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_8_1d7c8c8c5b34cbc7166f8d4d52b91761._comment
 create mode 100644 doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_9_2bfb2eaf1a72e0822341cfeba9058aa7._comment
 create mode 100644 doc/forum/Git-annex_assistant_configuration_file__40__s__41___location__40__s__41__.mdwn
 create mode 100644 doc/forum/Git-annex_assistant_configuration_file__40__s__41___location__40__s__41__/comment_1_5baffd4d6994bbcb23614b17777a0ffe._comment
 create mode 100644 doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__.mdwn
 create mode 100644 doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__/comment_1_65b41a6eb28261e04e4fe8732f97a1f1._comment
 create mode 100644 doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__/comment_2_200a869f335909566b9ddab3032fd5a2._comment
 create mode 100644 doc/forum/Git-annex_fsck_backend_warning.mdwn
 create mode 100644 doc/forum/Git-annex_fsck_backend_warning/comment_1_a504439397db6661788d916cb7c96da1._comment
 create mode 100644 doc/forum/Git-annex_fsck_backend_warning/comment_2_a5415299d07283f393319b37ba9335ff._comment
 create mode 100644 doc/forum/Git-annex_fsck_backend_warning/comment_3_300bbfdd90d18619e88310de5a128ef0._comment
 create mode 100644 doc/forum/Git-annex_init_gets_stuck_on_exFAT.mdwn
 create mode 100644 doc/forum/Git-annex_init_gets_stuck_on_exFAT/comment_1_48da28dbc7da82d4e06fd3ce7962dfc5._comment
 create mode 100644 doc/forum/Git-annex_link_to_different_file_names.mdwn
 create mode 100644 doc/forum/Git-annex_link_to_different_file_names/comment_1_17ab85276bcf495a656c7091753c086f._comment
 create mode 100644 doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__.mdwn
 create mode 100644 doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_1_e102345b520423eafb4c202a0d6e276d._comment
 create mode 100644 doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_2_dd1cce225e4d4791b37dad5480936f76._comment
 create mode 100644 doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_3_56c132612785da00b09f088c75f903a7._comment
 create mode 100644 doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_4_b92198e15a0d6154c951cb731eca828a._comment
 create mode 100644 doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__.mdwn
 create mode 100644 doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_1_ee72caf2aeab4a8a2818f87653dc1cd2._comment
 create mode 100644 doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_2_3be98f57bcb2ba838046105276d1afd4._comment
 create mode 100644 doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_3_b17f2361b18420c950eef25d3fff8841._comment
 create mode 100644 doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_4_a8a79961d97fe773c1855632b4772c5b._comment
 create mode 100644 doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_5_da422adacdeb36163186a38f1aa6c06b._comment
 create mode 100644 doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_6_6f16af7d1668320d1b80472c76f892fb._comment
 create mode 100644 doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_7_2d9460736189575a8af99c50557a8e50._comment
 create mode 100644 doc/forum/GitBlit_as_a_centralized_repository.mdwn
 create mode 100644 doc/forum/GitBlit_as_a_centralized_repository/comment_1_06bedf5fbac45415e0cc81f41b25a5a0._comment
 create mode 100644 doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink.mdwn
 create mode 100644 doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_1_7b3cb1d52767b89cf46d57005bf57b06._comment
 create mode 100644 doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_2_52ad16f63ec47b34485a0d0f4db9e2c8._comment
 create mode 100644 doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_3_a60bc9a6e766c0f29835c088c0863cf5._comment
 create mode 100644 doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_4_c8088fd093312685f130af07e5ca2e22._comment
 create mode 100644 doc/forum/Git_Annex_Assistant__58___How_to_add_a_remote__63__.mdwn
 create mode 100644 doc/forum/Git_Annex_Assistant__58___How_to_add_a_remote__63__/comment_1_d0a3d0090928790d5a05e9f8e5f05320._comment
 create mode 100644 doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive.mdwn
 create mode 100644 doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive/comment_1_a1d1ae9488924b08682b355aff51130d._comment
 create mode 100644 doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive/comment_2_6649077583bc14730a08aaaca7ccb62e._comment
 create mode 100644 doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive/comment_3_f359d9b9356de7ee10b9e725a011cc43._comment
 create mode 100644 doc/forum/Git_Annex_Sync_Delinks_Files.mdwn
 create mode 100644 doc/forum/Git_Annex_Sync_Delinks_Files/comment_1_8b03707777a9d8e38715cb77d2a0addc._comment
 create mode 100644 doc/forum/Git_Annex_Sync_Delinks_Files/comment_2_a625e7d88e321532ace103548b31b67b._comment
 create mode 100644 doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment
 create mode 100644 doc/forum/Git_Annex_Sync_Delinks_Files/comment_4_e43ede0bdc20de9aa10ab6ce387d8582._comment
 create mode 100644 doc/forum/Git_Annex_Sync_Delinks_Files/comment_5_dc71987f0e19f04a920561201f9552b4._comment
 create mode 100644 doc/forum/Git_Annex_Sync_Delinks_Files/comment_6_257a89f81858659c4dac4d116e7cf0a3._comment
 create mode 100644 doc/forum/Git_Annex_Transfer_Protocols.mdwn
 create mode 100644 doc/forum/Git_Annex_Transfer_Protocols/comment_1_a870ec991078c95a6bb683d6962ab56e._comment
 create mode 100644 doc/forum/Git_Annex_Transfer_Protocols/comment_2_71419376ef50a679ea8f0f9e16991c17._comment
 create mode 100644 doc/forum/Git_Annex_Transfer_Protocols/comment_3_fea43664a500111ca99f4043e0dadb14._comment
 create mode 100644 doc/forum/Git_Annex_Transfer_Protocols/comment_4_56fb2dab1d4030c9820be32b495afdf0._comment
 create mode 100644 doc/forum/Git_Annex_Transfer_Protocols/comment_5_a6ec9c5a4a3c0bac1df87f1df9be140b._comment
 create mode 100644 doc/forum/Git_Annex_Transfer_Protocols/comment_6_1678452fb7114aeabcf0cc3d5f6c69b0._comment
 create mode 100644 doc/forum/Git_Annex_not_dropping_unused_content.mdwn
 create mode 100644 doc/forum/Git_Annex_not_dropping_unused_content/comment_1_da47b6af512b19cba077499f41455189._comment
 create mode 100644 doc/forum/Git_Annex_shirts_at_hellotux.com.mdwn
 create mode 100644 doc/forum/Git_Annex_shirts_at_hellotux.com/comment_1_fa72689070c39054d166d32fa144fabc._comment
 create mode 100644 doc/forum/Git_LFS_lock_feature.mdwn
 create mode 100644 doc/forum/Git_LFS_lock_feature/comment_1_8f5878db6dd2a21893cc6b5a1200b010._comment
 create mode 100644 doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue.mdwn
 create mode 100644 doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue/comment_1_c9239f9c67b2441ab0e1ac42c53db531._comment
 create mode 100644 doc/forum/Git_annex___39__corrupting__39___itself.mdwn
 create mode 100644 doc/forum/Git_annex___39__corrupting__39___itself/comment_1_bcf50a215e2f8771e098aadfff4c300c._comment
 create mode 100644 doc/forum/Git_annex___39__corrupting__39___itself/comment_3_75f957e7be6c1ad8936c0a2a5374db3e._comment
 create mode 100644 doc/forum/Git_annex___39__corrupting__39___itself/comment_3_ab062b1df3b55fd49852a6220c98249e._comment
 create mode 100644 doc/forum/Git_annex___39__corrupting__39___itself/comment_4_45974f60a81ed2d00b87ffb1a7963c6f._comment
 create mode 100644 doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server.mdwn
 create mode 100644 doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_1_75c599cc26e7d3645f69173861d4f8be._comment
 create mode 100644 doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_2_496e2f3a61b609ebb28ab55e5c30022b._comment
 create mode 100644 doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_3_e202a6dd2803f733bd30ec8b6ddbe7bf._comment
 create mode 100644 doc/forum/Git_annex_assistant_in_command_line.mdwn
 create mode 100644 doc/forum/Git_annex_assistant_in_command_line/comment_1_ce05226307ade8db90ada2dbf290bd58._comment
 create mode 100644 doc/forum/Git_annex_assistant_on_EC2.mdwn
 create mode 100644 doc/forum/Git_annex_assistant_on_EC2/comment_1_bbdb4611373117a2176c225378110a05._comment
 create mode 100644 doc/forum/Git_annex_assistant_on_EC2/comment_2_614ed11f7134137d6376d36a61c293f5._comment
 create mode 100644 doc/forum/Git_annex_drop.mdwn
 create mode 100644 doc/forum/Git_annex_drop/comment_1_541399d5fff0db0627c786f5e056fabb._comment
 create mode 100644 doc/forum/Git_annex_drop/comment_2_423ffd4abca9dbb8dba8ce887dee5faf._comment
 create mode 100644 doc/forum/Git_annex_hangs.mdwn
 create mode 100644 doc/forum/Git_annex_hangs/comment_10_ce5355b358f1acc63270331f3749fdcd._comment
 create mode 100644 doc/forum/Git_annex_hangs/comment_11_e0b4616c25405fa3c496f7e85800ac43._comment
 create mode 100644 doc/forum/Git_annex_hangs/comment_12_053666d256e26803b911d68622257cd5._comment
 create mode 100644 doc/forum/Git_annex_hangs/comment_13_f28528c9b9766fe8e2d344e5f27ade65._comment
 create mode 100644 doc/forum/Git_annex_hangs/comment_1_e6b854d4625ae3015aea9c5de71a28ef._comment
 create mode 100644 doc/forum/Git_annex_hangs/comment_2_4f848771e60c38321a97361b0d1b33dd._comment
 create mode 100644 doc/forum/Git_annex_hangs/comment_3_a07abdd1dc21a69ad6be0526edaeffc1._comment
 create mode 100644 doc/forum/Git_annex_hangs/comment_4_2ba5992c32753ed03ddd5c12264e9acf._comment
 create mode 100644 doc/forum/Git_annex_hangs/comment_5_5fd749f92343079b3916a4d32ddf39c7._comment
 create mode 100644 doc/forum/Git_annex_hangs/comment_6_4abe6aa966feea4e1881f6a2fbe7a007._comment
 create mode 100644 doc/forum/Git_annex_hangs/comment_7_f3ea42dc6699275143ba44e7f57e7d5e._comment
 create mode 100644 doc/forum/Git_annex_hangs/comment_8_1bad17001364d192e0d9affe5f0ea554._comment
 create mode 100644 doc/forum/Git_annex_hangs/comment_9_07ae4582a4403b4f0185dbc1830642ad._comment
 create mode 100644 doc/forum/Git_annex_status_always_showing_annexed_files_as_modified.mdwn
 create mode 100644 doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_1_b6e8f634187d1f5840641633cb82301a._comment
 create mode 100644 doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_2_ab24dacf101a1a7e33e5976f72f6fe05._comment
 create mode 100644 doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_3_cade18a9487c583329249c2d3e72ca46._comment
 create mode 100644 doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_4_1d2281f79cd0c2a1a3599cae42df0187._comment
 create mode 100644 doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_5_5f2f2275ee9de47273671a8009217fb9._comment
 create mode 100644 doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_6_54155343eef8c6f95574dffb3910fc61._comment
 create mode 100644 doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_7_cbf7035b218566a9fa1cb656290a9cf0._comment
 create mode 100644 doc/forum/Git_annex_syncing_speed__44___possible__63__.mdwn
 create mode 100644 doc/forum/Git_annex_syncing_speed__44___possible__63__/comment_1_8aa224b3016dc38e4cea8ee1865a3ab6._comment
 create mode 100644 doc/forum/Git_filters__58___smudgeToFile_and_cleanFromFile.mdwn
 create mode 100644 doc/forum/Git_filters__58___smudgeToFile_and_cleanFromFile/comment_1_f21dc5255ce986ef0317503ebd40b4f5._comment
 create mode 100644 doc/forum/Git_filters__58___smudgeToFile_and_cleanFromFile/comment_2_4ded2a4b866102450ef96c76b7be94fe._comment
 create mode 100644 doc/forum/Git_remote__63_____40__bitbucket__44___github__41__.mdwn
 create mode 100644 doc/forum/Git_remote__63_____40__bitbucket__44___github__41__/comment_1_8a6de753ac0aa56f470b2aefca628388._comment
 create mode 100644 doc/forum/Git_repos_in_git_annex__63__.mdwn
 create mode 100644 doc/forum/Git_repos_in_git_annex__63__/comment_1_8aaa0d83e8fcd5997f6b0097f3b21622._comment
 create mode 100644 doc/forum/Git_repos_in_git_annex__63__/comment_2_8546341a561a5f55216c2f437f8ec0c2._comment
 create mode 100644 doc/forum/Git_repos_in_git_annex__63__/comment_3_88e37911a0280d817559b2d51ddb1d4e._comment
 create mode 100644 doc/forum/Git_repositories_in_the_annex__63__.mdwn
 create mode 100644 doc/forum/Github_pull_request_with_git-annex.mdwn
 create mode 100644 doc/forum/Github_pull_request_with_git-annex/comment_1_03023d2fba47e84d03573d996e8366cf._comment
 create mode 100644 doc/forum/Gitolite_problems.mdwn
 create mode 100644 doc/forum/Gitolite_problems/comment_1_3a41f9b6bddc060b1fa9e35b9ce8b55f._comment
 create mode 100644 doc/forum/Gitolite_problems/comment_2_ef156bf7a1e17496c5fc1f592d45f2ad._comment
 create mode 100644 doc/forum/HTTP_uploads.mdwn
 create mode 100644 doc/forum/HTTP_uploads/comment_1_e22213816c53e6e3555532c452eceb49._comment
 create mode 100644 doc/forum/HTTP_uploads/comment_2_d99641f1908073724f45dc3b170f3794._comment
 create mode 100644 doc/forum/Handling_a_large_number_of_files.mdwn
 create mode 100644 doc/forum/Handling_a_large_number_of_files/comment_1_33d2e19fbfdf5a0bfb7b4fbc840824a2._comment
 create mode 100644 doc/forum/Handling_a_large_number_of_files/comment_2_a46bde96e3be5a105eb1c87bf637f8b6._comment
 create mode 100644 doc/forum/Handling_a_large_number_of_files/comment_3_c6564d8cfc217c5b70b2a7a8fe60039b._comment
 create mode 100644 doc/forum/Handling_a_large_number_of_files/comment_4_f9e25d63417d0354de158c47235cb3be._comment
 create mode 100644 doc/forum/Handling_merge_conflicts_in_direct_mode.mdwn
 create mode 100644 doc/forum/Handling_merge_conflicts_in_direct_mode/comment_1_7046393b0c4329466a0d6803b718f786._comment
 create mode 100644 doc/forum/Handling_permissions_in_a_shared_folder.mdwn
 create mode 100644 doc/forum/Handling_permissions_in_a_shared_folder/comment_1_220b33912339f06fbc9f6c9fbe1a4756._comment
 create mode 100644 doc/forum/Handling_permissions_in_a_shared_folder/comment_2_f0d010731ad51bf8512e5ff93864fb53._comment
 create mode 100644 doc/forum/Handling_permissions_in_a_shared_folder/comment_3_9ceff336ab112ada10db1f22436dee43._comment
 create mode 100644 doc/forum/Handling_permissions_in_a_shared_folder/comment_4_9ce6d042fc1826d814f8362ae2716251._comment
 create mode 100644 doc/forum/Handling_web_special_remote_when_content_changes__63__.mdwn
 create mode 100644 doc/forum/Handling_web_special_remote_when_content_changes__63__/comment_1_05ee6a1b1943ef3c90634e52233bde1c._comment
 create mode 100644 doc/forum/Handling_web_special_remote_when_content_changes__63__/comment_2_48d82e391812d8ec0d4e6562d0607fe7._comment
 create mode 100644 doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode.mdwn
 create mode 100644 doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode/comment_1_ae978190d2d4fc1c4cdadc8256e6ca3d._comment
 create mode 100644 doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode/comment_2_6498a44801996cc5a412558c75f6157e._comment
 create mode 100644 doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode/comment_3_4bd03153c8ad61596ba55b719ad287ee._comment
 create mode 100644 doc/forum/Hashes_instead_of_content_in_files.mdwn
 create mode 100644 doc/forum/Hashes_instead_of_content_in_files/comment_1_800d875c0d980614792207641cedb3ea._comment
 create mode 100644 doc/forum/Hashes_instead_of_content_in_files/comment_2_a111296eecf7d69ff30f6a82e9f1e6d4._comment
 create mode 100644 doc/forum/Hashes_instead_of_content_in_files/comment_3_574964b83563df3afea9049754b1cfa2._comment
 create mode 100644 doc/forum/Hashes_instead_of_content_in_files/comment_4_67733580e8f8806b5036406e6712b6a1._comment
 create mode 100644 doc/forum/Help_Windows_walkthrough.mdwn
 create mode 100644 doc/forum/Help_Windows_walkthrough/comment_1_5fc22393a1b28235eabb2871ad83d0a7._comment
 create mode 100644 doc/forum/Help_fixing_S3_mistake.mdwn
 create mode 100644 doc/forum/Help_fixing_S3_mistake/comment_1_dc60d08da4c0b90705b0b88b4c834f05._comment
 create mode 100644 doc/forum/Help_fixing_S3_mistake/comment_2_f105714b9bac7f45fdcb9a47e77255ac._comment
 create mode 100644 doc/forum/Help_fixing_S3_mistake/comment_3_a00bca3b6b0d7b6c20ca1ca749c93469._comment
 create mode 100644 doc/forum/Help_fixing_S3_mistake/comment_4_34333d0f3eeaf2929089535632759ba1._comment
 create mode 100644 doc/forum/Help_fixing_S3_mistake/comment_5_7060bcd3424caab3570dcc7cbd3df93e._comment
 create mode 100644 doc/forum/Help_on_my_usecase.mdwn
 create mode 100644 doc/forum/Help_on_my_usecase/comment_1_a35b35c7927640f21d47c3df4f91dabb._comment
 create mode 100644 doc/forum/Help_with_assistant_and_Adobe_Lightroom.mdwn
 create mode 100644 doc/forum/Help_with_assistant_and_Adobe_Lightroom/comment_1_3adf9f5c60558b3c70a8aa041dbbe966._comment
 create mode 100644 doc/forum/Help_with_get.mdwn
 create mode 100644 doc/forum/Help_with_get/comment_1_439c7562d94a969fd841cc44628abedd._comment
 create mode 100644 doc/forum/Help_with_get/comment_2_137f89ea9c381cdbf57da78308a46078._comment
 create mode 100644 doc/forum/Help_with_get/comment_3_f523e44daca53b3d99350e0d3f7a8874._comment
 create mode 100644 doc/forum/Help_with_get/comment_4_863d03a8e52335d8a210320d8a02c553._comment
 create mode 100644 doc/forum/Help_with_get/comment_5_92e48d21fd83c0f7e69a5bb7b4c4f4ee._comment
 create mode 100644 doc/forum/Help_with_git-annex_and_controlmaster.mdwn
 create mode 100644 doc/forum/Help_with_git-annex_and_controlmaster/comment_1_2742e65d9faebab80bc5fa0877ef7d29._comment
 create mode 100644 doc/forum/Help_with_git-annex_and_controlmaster/comment_2_5e57d563d351cc8c850c9cc4726ad23b._comment
 create mode 100644 doc/forum/Help_with_git-annex_and_controlmaster/comment_3_4fe0973f6b7f912e2e4163ebf5dfc5d4._comment
 create mode 100644 doc/forum/Help_with_git-annex_and_controlmaster/comment_4_51312d1662d0794e4258551c59877434._comment
 create mode 100644 doc/forum/Help_with_git-annex_and_controlmaster/comment_5_0b4e2314c23df5eda18661c245f9f057._comment
 create mode 100644 doc/forum/Help_with_syncing_file_contents.mdwn
 create mode 100644 doc/forum/Help_with_syncing_file_contents/comment_1_7ec34de3140983739080115c82966bf5._comment
 create mode 100644 doc/forum/Help_with_syncing_file_contents/comment_2_7dba58d3c62d6f64a270298e4e4329a4._comment
 create mode 100644 doc/forum/Help_with_syncing_file_contents/comment_3_b26cfa20dc81517d93e760f4809bdc24._comment
 create mode 100644 doc/forum/HowTo_Conflict_Resolution.mdwn
 create mode 100644 doc/forum/HowTo_Conflict_Resolution/comment_1_81c06a0590ee828749b8d07e008028bb._comment
 create mode 100644 doc/forum/HowTo_Conflict_Resolution/comment_2_e0ec78f09e5aba83ad3a7252695e4d96._comment
 create mode 100644 doc/forum/HowTo_Conflict_Resolution/comment_3_495aea6e73fd7a2d7a387f539496ac3a._comment
 create mode 100644 doc/forum/HowTo_Conflict_Resolution/comment_4_b209d4527bec4620e1014fe759cbdde7._comment
 create mode 100644 doc/forum/HowTo_Conflict_Resolution/comment_5_446186626e5b2d08d078e3b48be06bfa._comment
 create mode 100644 doc/forum/HowTo_Conflict_Resolution/comment_6_83cafddb480fa9e5b5d87d27b994b2bc._comment
 create mode 100644 doc/forum/How_To_Permanently_Delete_a_File__63__.mdwn
 create mode 100644 doc/forum/How_To_Permanently_Delete_a_File__63__/comment_1_7f2cefb0991789be5a960eb9c0a9df3f._comment
 create mode 100644 doc/forum/How_To_Permanently_Delete_a_File__63__/comment_2_d13b456c5b3990082c16e78a50f5db91._comment
 create mode 100644 doc/forum/How_To_Permanently_Delete_a_File__63__/comment_3_854c17ff8cb38486c4bef618d1e94919._comment
 create mode 100644 doc/forum/How_To_Permanently_Delete_a_File__63__/comment_4_9572ad02bbf6845b1ab6d7c612c12a2a._comment
 create mode 100644 doc/forum/How_To_Permanently_Delete_a_File__63__/comment_5_9c28faabb7d7bd1e83d551e2938d3532._comment
 create mode 100644 doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__.mdwn
 create mode 100644 doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__/comment_1_30fb300ec5dbdb166f2bb979c6f2ee78._comment
 create mode 100644 doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__/comment_2_23cfa4b9abe96e4477f06c5271b706b2._comment
 create mode 100644 doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__/comment_3_b05a8c63d2594290769aeeaabc91f491._comment
 create mode 100644 doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__.mdwn
 create mode 100644 doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_1_99e7e1b178bbb17fffea0892538d4049._comment
 create mode 100644 doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_2_6a7a3c372599eed7c52d5f54e5287577._comment
 create mode 100644 doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_3_cc62f722b3e1db7d75d6976ef3854f94._comment
 create mode 100644 doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__.mdwn
 create mode 100644 doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_1_30217e593a04cefa30619025d0a58108._comment
 create mode 100644 doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_1_6793035e1c0fb329b3094bf66a982fa3._comment
 create mode 100644 doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_3_7cc944d96f4620e98fe22a554684ad22._comment
 create mode 100644 doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_4_8323e9160d81a4a65f2ca545c4469869._comment
 create mode 100644 doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_5_a74ece6acb2184c4990b434d7357ea00._comment
 create mode 100644 doc/forum/How_can_I_recover_from_misadventure__63__.mdwn
 create mode 100644 doc/forum/How_can_I_recover_from_misadventure__63__/comment_1_1e8ce32e1e8adf32acf7af28c7ab0d0b._comment
 create mode 100644 doc/forum/How_can_I_recover_from_misadventure__63__/comment_2_94f5435529802ea9d1980ee07025c6eb._comment
 create mode 100644 doc/forum/How_can_I_recover_from_misadventure__63__/comment_3_484fc154c68ba59939aae4452c663ce6._comment
 create mode 100644 doc/forum/How_can_I_use_git-annex_get_a_list_of_files_in_directory_that_have_content__63___.mdwn
 create mode 100644 doc/forum/How_can_I_use_git-annex_get_a_list_of_files_in_directory_that_have_content__63___/comment_1_e897d8fc10474cf865279dc22f22ecb7._comment
 create mode 100644 doc/forum/How_can_I_use_git-annex_get_a_list_of_files_in_directory_that_have_content__63___/comment_2_3af326205db6ee04f2a8644baa1dd566._comment
 create mode 100644 doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__.mdwn
 create mode 100644 doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/comment_1_ea2f6ca0768c55fa136606cf091471cd._comment
 create mode 100644 doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/comment_2_d79387905af9f8dce77f9aa85f2d6a03._comment
 create mode 100644 doc/forum/How_do_I_cleanly_remove_an_Android_git-annex_installation__63__.mdwn
 create mode 100644 doc/forum/How_do_I_cleanly_remove_an_Android_git-annex_installation__63__/comment_1_e14757c2c106770c2d7069ace4987b3b._comment
 create mode 100644 doc/forum/How_do_I_do_with_.gitrefs__47_____63__.mdwn
 create mode 100644 doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_1_5e235af2ea13fd4f6a226c842f69965e._comment
 create mode 100644 doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_2_50d0c643537175b514d5eae604fb5bea._comment
 create mode 100644 doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_3_3d342c32b14c7edbece596ba970a8415._comment
 create mode 100644 doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__.mdwn
 create mode 100644 doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_1_8db3cb5348b845eb99c2c829957db9ea._comment
 create mode 100644 doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_2_6cc909d9d74bc1ccb8a7b0d7d234c7cd._comment
 create mode 100644 doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_3_f24d678e4192a70322aa164ed9b71fc8._comment
 create mode 100644 doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_4_9233decd0aaf9211447f36e0d9346445._comment
 create mode 100644 doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_5_e1deb110f752e5495d5c77ec444abac5._comment
 create mode 100644 doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__.mdwn
 create mode 100644 doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_1_b3c215cedba51fb47992ef10c60d6acc._comment
 create mode 100644 doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_2_85415e1fceb737919cc1cd9f37242458._comment
 create mode 100644 doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_3_fb3a591dc60182f7922fc2b5c24f50f1._comment
 create mode 100644 doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_4_aed0be32e579c7a39c63aa7e3ec5f67b._comment
 create mode 100644 doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_5_0c9a6c8a92d6c6e04ae3a8349b799c60._comment
 create mode 100644 doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__.mdwn
 create mode 100644 doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_1_005e9254a1239164df34ab5fbf2115a8._comment
 create mode 100644 doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_2_f376604560c36a0aa5afa4619797b396._comment
 create mode 100644 doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_5_1ed5e10e51078a0aa7e6968ef48687a3._comment
 create mode 100644 doc/forum/How_do_I_list_links_with_0_copies__63__.mdwn
 create mode 100644 doc/forum/How_do_I_list_links_with_0_copies__63__/comment_1_ee222f0e227f1c65f84f73af399239e5._comment
 create mode 100644 doc/forum/How_do_I_list_links_with_0_copies__63__/comment_2_1528b3c96d6ad5637c2fdda33057c12f._comment
 create mode 100644 doc/forum/How_do_I_list_links_with_0_copies__63__/comment_3_e629a5393e56755a42581be9f6942adb._comment
 create mode 100644 doc/forum/How_do_I_list_links_with_0_copies__63__/comment_4_61a441f83ef690da8e799b0503526c47._comment
 create mode 100644 doc/forum/How_do_I_list_links_with_0_copies__63__/comment_5_66def7cfeef20866eb3caced831b0d3e._comment
 create mode 100644 doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex.mdwn
 create mode 100644 doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_1_ab8896c4f0e20fb351477e3dc92a35d8._comment
 create mode 100644 doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_2_8f02d0c400d22866e38cc521dd55b2c2._comment
 create mode 100644 doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_3_1b84261a9e6389bcad1766b82add4930._comment
 create mode 100644 doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_4_577f586843c1d7e54d115796988f912d._comment
 create mode 100644 doc/forum/How_do_I_set_up_git_annex_with_nextcloud.mdwn
 create mode 100644 doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_1_2528e595b04232de60571279ded4c2e8._comment
 create mode 100644 doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_2_562dbc96302644f915a0b8e33428c69a._comment
 create mode 100644 doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_3_7fa312e85acd3f9afbfd97d46057e6db._comment
 create mode 100644 doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_4_7980af82df895cdd4b5c527bbb2f4c72._comment
 create mode 100644 doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_5_1fe66285d3369da85c08d8c69ad9746a._comment
 create mode 100644 doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__.mdwn
 create mode 100644 doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_1_fc914b5998a09943fc8c1917a0e36096._comment
 create mode 100644 doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_2_fd5257eff7f94971557c031a94ac2766._comment
 create mode 100644 doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_3_5a11c45f92bae1328a5120945bee1fa0._comment
 create mode 100644 doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_4_404a8f9daa86c20a046b4c9f9051dfc0._comment
 create mode 100644 doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_5_3dcdaef370d0df38e7285f1fa11c6bb3._comment
 create mode 100644 doc/forum/How_do_you_know_when_something_fails_a_fsck__63__.mdwn
 create mode 100644 doc/forum/How_do_you_know_when_something_fails_a_fsck__63__/comment_1_1c14981916dd55376d5e9f95023556cb._comment
 create mode 100644 doc/forum/How_does_addurl_work_with_claimurl_on_external_special_remotes__63__.mdwn
 create mode 100644 doc/forum/How_does_addurl_work_with_claimurl_on_external_special_remotes__63__/comment_1_3ee29c9b0239af732d3734855417dd5a._comment
 create mode 100644 doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__.mdwn
 create mode 100644 doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__/comment_1_f4b439f7d9ce20d4b5dc8d728cb2e180._comment
 create mode 100644 doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__/comment_2_7393a4b2e94f9d36c3c9ca977a8f67b6._comment
 create mode 100644 doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__/comment_3_a38e2bbe229cb7e1f4f334bd93d91656._comment
 create mode 100644 doc/forum/How_does_git_annex_handle_swp_files.mdwn
 create mode 100644 doc/forum/How_does_git_annex_handle_swp_files/comment_1_8f0b81139fb66f28f9262e919692ecbd._comment
 create mode 100644 doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__.mdwn
 create mode 100644 doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_1_f4402eabda2327da3a0bbc64ed3baf9a._comment
 create mode 100644 doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_2_cdb41f2c7b6bc5bf40d88582dcbf45aa._comment
 create mode 100644 doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_3_ca75e928c245eb23a02b5f40ec69cbb1._comment
 create mode 100644 doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_4_1635f136909711295b9b70d1255e0378._comment
 create mode 100644 doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_5_ee0cbe9498c518de98480a2ad229f685._comment
 create mode 100644 doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_6_799b9d9d3ffbc2c14eca8d442e2aff8c._comment
 create mode 100644 doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_7_71ff45948487e9ac8de809a5ccc3d874._comment
 create mode 100644 doc/forum/How_does_one_change_the_number_of_simultaneous_uploads.mdwn
 create mode 100644 doc/forum/How_does_one_change_the_number_of_simultaneous_uploads/comment_1_d5559994ee45a5c185a55c9a4d824aa4._comment
 create mode 100644 doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__.mdwn
 create mode 100644 doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__/comment_1_68ed73d8898bf2ce0a14e0e5909cc64b._comment
 create mode 100644 doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__/comment_2_176a92a6ce5d8f356dafc29021242b2d._comment
 create mode 100644 doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__/comment_3_0cdd9683709d55bb7340fb41fef265fa._comment
 create mode 100644 doc/forum/How_to_add_dotfiles_in_direct_mode__63__.mdwn
 create mode 100644 doc/forum/How_to_add_dotfiles_in_direct_mode__63__/comment_1_d62d4b9ae5f1ec825fc58090689f7571._comment
 create mode 100644 doc/forum/How_to_add_dotfiles_in_direct_mode__63__/comment_2_c7269cde1db02069149268b6c6a50786._comment
 create mode 100644 doc/forum/How_to_allow_clones_to_get_files_via_URL__63__.mdwn
 create mode 100644 doc/forum/How_to_cancel_an_add__63__.mdwn
 create mode 100644 doc/forum/How_to_cancel_an_add__63__/comment_1_f768ce5dc7c76f96ee6eb352f167be44._comment
 create mode 100644 doc/forum/How_to_change_the_name_of_a_repo_on_S3__63__.mdwn
 create mode 100644 doc/forum/How_to_change_the_name_of_a_repo_on_S3__63__/comment_1_be74d63e1951f515948d232e096b4862._comment
 create mode 100644 doc/forum/How_to_change_the_name_of_a_repo_on_S3__63__/comment_2_d54a7163cfe9a94b7ba337860958e5c5._comment
 create mode 100644 doc/forum/How_to_completely_remove_tracking_of_a_deleted_file_in_direct_mode.mdwn
 create mode 100644 doc/forum/How_to_completely_remove_tracking_of_a_deleted_file_in_direct_mode/comment_1_c6bd2ef90516dde928ff18ded36df625._comment
 create mode 100644 doc/forum/How_to_copy__47__duplicate_all_data_from_rsync__47__ssh_backend_to_other_backend__63__.mdwn
 create mode 100644 doc/forum/How_to_copy__47__duplicate_all_data_from_rsync__47__ssh_backend_to_other_backend__63__/comment_1_7973928b1aa9e0fcfeb6bf80885441f5._comment
 create mode 100644 doc/forum/How_to_deal_with_renamed_files_in_direct_mode__63__.mdwn
 create mode 100644 doc/forum/How_to_deal_with_renamed_files_in_direct_mode__63__/comment_1_fe38fedbbc9e4a9e13bf19950e63c7ac._comment
 create mode 100644 doc/forum/How_to_deal_with_spotlight_and_macOS.mdwn
 create mode 100644 doc/forum/How_to_deal_with_spotlight_and_macOS/comment_1_3d76fbb8f13bd66d729819a4d037ab4f._comment
 create mode 100644 doc/forum/How_to_debug_failing_sync.mdwn
 create mode 100644 doc/forum/How_to_debug_failing_sync/comment_1_a597b868182e55e5f39394f154740534._comment
 create mode 100644 doc/forum/How_to_debug_failing_sync/comment_2_db0a5652d76e4e568a4d7808195bc59c._comment
 create mode 100644 doc/forum/How_to_define_a_balanced_prefered_content.mdwn
 create mode 100644 doc/forum/How_to_define_a_balanced_prefered_content/comment_1_d4c94791a5fc7d2e618a7e11bc5db569._comment
 create mode 100644 doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__.mdwn
 create mode 100644 doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__/comment_1_52918b5ec25e55837215439fe1bb1a14._comment
 create mode 100644 doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__/comment_2_3a1567c9f484b5e12e5560cdcc2cfddd._comment
 create mode 100644 doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__/comment_3_48c3a80c14a85f27d742482b2ccbe628._comment
 create mode 100644 doc/forum/How_to_delete_a_file_in_direct_mode__63__.mdwn
 create mode 100644 doc/forum/How_to_delete_a_file_in_direct_mode__63__/comment_1_995f3b8cf511921719774f8911e24907._comment
 create mode 100644 doc/forum/How_to_delete_a_remote__63__.mdwn
 create mode 100644 doc/forum/How_to_delete_a_remote__63__/comment_1_8cba186bb67079ff41bf6d0b04613f4a._comment
 create mode 100644 doc/forum/How_to_delete_a_remote__63__/comment_2_33c429ffa7e9e2ed9c5fac760ee8e82c._comment
 create mode 100644 doc/forum/How_to_delete_a_remote__63__/comment_3_e9c5508092ca2983f458b16bf1e07082._comment
 create mode 100644 doc/forum/How_to_delete_a_remote__63__/comment_4_688a8473d074830303133ba939438084._comment
 create mode 100644 doc/forum/How_to_delete_a_remote__63__/comment_5_de7dff2dc4357d8cc617d86a06e35b1b._comment
 create mode 100644 doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4.mdwn
 create mode 100644 doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_1_42ca6cfbbb79fe63514805b8119ac16b._comment
 create mode 100644 doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_2_c94ce6a9767c624e2445a7d9eea40396._comment
 create mode 100644 doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_3_bcda51053b62bbb20ce71a59469e1b26._comment
 create mode 100644 doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_4_48e5b9eae920e5f13812de8d6f6bc640._comment
 create mode 100644 doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_5_787c0bfdc1d309db1486c3a37723a957._comment
 create mode 100644 doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_6_8894beb06443f234e9200b03b5f3badf._comment
 create mode 100644 doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_7_457f62ee3e58f68a55f66c5bde6002fd._comment
 create mode 100644 doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_8_bd2b412116a66107bc0ff0efd7e39a58._comment
 create mode 100644 doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__.mdwn
 create mode 100644 doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_1_c5226964b4b64bd47d888b5616ff970b._comment
 create mode 100644 doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_2_748d243bac14a8d55be4ac324c581c1d._comment
 create mode 100644 doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_3_cf9234339bad14ad9a9d3027f9066936._comment
 create mode 100644 doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_4_d899cf35801636e618e4675d91d6104a._comment
 create mode 100644 doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__.mdwn
 create mode 100644 doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__/comment_1_dccf4dc4483d08e5e2936b2cadeafeaf._comment
 create mode 100644 doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__/comment_2_5710294c1c8652c12b6df2233255a45e._comment
 create mode 100644 doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__.mdwn
 create mode 100644 doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_1_8332f71241335a31e270407477bd84f3._comment
 create mode 100644 doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_2_984286a35ec828f1e8dda928ea577571._comment
 create mode 100644 doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_3_29f6f9df1ad22113e9690b0d1da36ba0._comment
 create mode 100644 doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_4_43549b3d231f52cf53a66c477c34a708._comment
 create mode 100644 doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_5_94aca10f84783f35d927dbefbeba263a._comment
 create mode 100644 doc/forum/How_to_find_out_if_assistant_is_still_repairing__63__.mdwn
 create mode 100644 doc/forum/How_to_find_out_if_assistant_is_still_repairing__63__/comment_1_9dd192a8e0bfa9e533b22070b87792af._comment
 create mode 100644 doc/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_.mdwn
 create mode 100644 doc/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_/comment_1_345a7439720e8dc2cc6cb5eed6bcf73f._comment
 create mode 100644 doc/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_/comment_2_55ad844ee650a6a5026fdf5764dd9470._comment
 create mode 100644 doc/forum/How_to_fix_bad_merge.mdwn
 create mode 100644 doc/forum/How_to_fix_bad_merge/comment_1_4a32a727560ab85203d1dd76feff2e1e._comment
 create mode 100644 doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__.mdwn
 create mode 100644 doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_1_5962c2c7b3a668429a62f7bede990801._comment
 create mode 100644 doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_2_f84a8e545da95e72b3e2b03a782335ce._comment
 create mode 100644 doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_3_74f14ae50e37d94fbd2950924a7bee28._comment
 create mode 100644 doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_4_ee99cdb44671eea30eaa4351dbb9dc96._comment
 create mode 100644 doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_5_d0d7674589574ae92e2595d23d000f61._comment
 create mode 100644 doc/forum/How_to_get_detailed_information_on_special_remotes__63__.mdwn
 create mode 100644 doc/forum/How_to_get_detailed_information_on_special_remotes__63__/comment_1_f1eca38ca0c1edb66e64ac64f0321829._comment
 create mode 100644 doc/forum/How_to_get_detailed_information_on_special_remotes__63__/comment_2_73f8b7ebde5870f92bec02d15a533ef3._comment
 create mode 100644 doc/forum/How_to_get_encrypted_name_from_special_remote__63__.mdwn
 create mode 100644 doc/forum/How_to_get_encrypted_name_from_special_remote__63__/comment_1_47ce17796de422fe996f45083a6b79b0._comment
 create mode 100644 doc/forum/How_to_get_git-annex_to_forget_a_commit__63__.mdwn
 create mode 100644 doc/forum/How_to_get_git-annex_to_forget_a_commit__63__/comment_1_65471c42e163ac8ee6ec109f1397271b._comment
 create mode 100644 doc/forum/How_to_get_git-annex_to_forget_a_commit__63__/comment_2_cc991abd9155a8e4d935b04ba432744f._comment
 create mode 100644 doc/forum/How_to_handle_cold_storage__63__.mdwn
 create mode 100644 doc/forum/How_to_handle_cold_storage__63__/comment_1_ff49a65d4adaff3cf3902c2850227ea2._comment
 create mode 100644 doc/forum/How_to_handle_the_git-annex_branch__63__.mdwn
 create mode 100644 doc/forum/How_to_handle_the_git-annex_branch__63__/comment_1_800bd55b322e72f229882d7fd3888b14._comment
 create mode 100644 doc/forum/How_to_hide_broken_symlinks.mdwn
 create mode 100644 doc/forum/How_to_hide_broken_symlinks/comment_1_07a70090a9ac8f675233b08b24f55544._comment
 create mode 100644 doc/forum/How_to_hide_broken_symlinks/comment_2_011f6b97b1eaee1ae513a4a0e445d105._comment
 create mode 100644 doc/forum/How_to_hide_broken_symlinks/comment_3_e3606aa746f516fc771d5d9bf93d70af._comment
 create mode 100644 doc/forum/How_to_hide_broken_symlinks/comment_4_c6e3ef3ba5f6e9e54d998bcbe3035650._comment
 create mode 100644 doc/forum/How_to_hide_broken_symlinks/comment_5_1ed5e10e51078a0aa7e6968ef48687a3._comment
 create mode 100644 doc/forum/How_to_improve_performance_with_v6_repos__63__.mdwn
 create mode 100644 doc/forum/How_to_improve_performance_with_v6_repos__63__/comment_1_56e0fead15a88ea12262e6091972c6d6._comment
 create mode 100644 doc/forum/How_to_improve_performance_with_v6_repos__63__/comment_2_93a6a0779f52bdd3de6e4d2500cfd223._comment
 create mode 100644 doc/forum/How_to_keep_connected_files_with_another__63__.mdwn
 create mode 100644 doc/forum/How_to_keep_connected_files_with_another__63__/comment_1_89e04a7dc25a3df849aa2ada4dbc8439._comment
 create mode 100644 doc/forum/How_to_keep_connected_files_with_another__63__/comment_2_20e8dba904eff7cc8f72ee12b8119632._comment
 create mode 100644 doc/forum/How_to_keep_connected_files_with_another__63__/comment_3_7b14aa71a166cf14e852ae896b05ee74._comment
 create mode 100644 doc/forum/How_to_keep_connected_files_with_another__63__/comment_4_a33437b28ea7fc74eb221d90efaec487._comment
 create mode 100644 doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository.mdwn
 create mode 100644 doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment
 create mode 100644 doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_2_e772ea0383ac690cbcbcf125258986cf._comment
 create mode 100644 doc/forum/How_to_list_all_existing_metadata_types__63__.mdwn
 create mode 100644 doc/forum/How_to_list_all_existing_metadata_types__63__/comment_1_a8c30f697f32a3807661a59482d79b18._comment
 create mode 100644 doc/forum/How_to_make_Maven_releases_work_with_git_annex___63__.mdwn
 create mode 100644 doc/forum/How_to_make_Maven_releases_work_with_git_annex___63__/comment_1_9298aa55771b68873de02e6a7964bbdc._comment
 create mode 100644 doc/forum/How_to_make_a_server_store_the_files.mdwn
 create mode 100644 doc/forum/How_to_make_a_server_store_the_files/comment_1_20196067475918e788afa0debc4d5ce5._comment
 create mode 100644 doc/forum/How_to_make_this_workflow_possible__63__.mdwn
 create mode 100644 doc/forum/How_to_make_this_workflow_possible__63__/comment_1_38d7c0531d68803b1d7910c598aab38c._comment
 create mode 100644 doc/forum/How_to_mv_file___40__symlink__41___to_another_dir_in_the_same_repo_without_unlocking_it.mdwn
 create mode 100644 doc/forum/How_to_mv_file___40__symlink__41___to_another_dir_in_the_same_repo_without_unlocking_it/comment_1_a272d179a77682e8c64bd4fc20cddee0._comment
 create mode 100644 doc/forum/How_to_organise_backup_to_S3__63__.mdwn
 create mode 100644 doc/forum/How_to_organise_backup_to_S3__63__/comment_1_13c6421a3637e30193dc77b54dec4b8d._comment
 create mode 100644 doc/forum/How_to_organise_backup_to_S3__63__/comment_2_e0ae05276ef7e1dcb21ef0986b6f7531._comment
 create mode 100644 doc/forum/How_to_organise_backup_to_S3__63__/comment_3_7697112a04cdc9a53551257d71143eb5._comment
 create mode 100644 doc/forum/How_to_overwrite_local_changes__63__.mdwn
 create mode 100644 doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment
 create mode 100644 doc/forum/How_to_play_a_video_from_WSL2_on_Windows_VLC.mdwn
 create mode 100644 doc/forum/How_to_play_a_video_from_WSL2_on_Windows_VLC/comment_1_4b2b04e4cd61d08dfa44b2cc86023ba2._comment
 create mode 100644 doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks.mdwn
 create mode 100644 doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_1_b59a72142e8f752d7b68a63a6ac1bbfe._comment
 create mode 100644 doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_2_e4bfea21f664a0cb1aa8ec18ee88fc50._comment
 create mode 100644 doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_3_ee247d9316df963fd584df2199b80fe2._comment
 create mode 100644 doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_4_51548724d72e2cc6cb2c6e8c3b82e3e4._comment
 create mode 100644 doc/forum/How_to_prevent_the_assistant_from_downloading_all_data__63__.mdwn
 create mode 100644 doc/forum/How_to_prevent_the_assistant_from_downloading_all_data__63__/comment_1_fd8b287758ad77b3527ae71017cffabf._comment
 create mode 100644 doc/forum/How_to_prevent_the_assistant_from_downloading_all_data__63__/comment_2_e8e75b4451aaf55461edf2f3d68797ed._comment
 create mode 100644 doc/forum/How_to_recover_from_failed_branch_updates__63__.mdwn
 create mode 100644 doc/forum/How_to_recover_from_failed_branch_updates__63__/comment_1_f296d4870a6fdef5c57bc8bb1a1e0474._comment
 create mode 100644 doc/forum/How_to_recover_from_failed_branch_updates__63__/comment_2_0edc7239488f78345f9e624ef210ebac._comment
 create mode 100644 doc/forum/How_to_register_arguments_for_an_external_special_remote__63__.mdwn
 create mode 100644 doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_1_6dd92d0737b72b927fc6b82636084c54._comment
 create mode 100644 doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_2_789445dff9a5905ed105ac344f6949ad._comment
 create mode 100644 doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_3_93e91e2ab98c35d4cb6082eea01b6abc._comment
 create mode 100644 doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_4_64c0d3c061ff463f9ce16b52d2a70a1f._comment
 create mode 100644 doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_5_d1c47c1a2f9b4dd570c0ebd9fbd1ad8b._comment
 create mode 100644 doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_6_e0753fef2b93ae5a114894dbdc014ec4._comment
 create mode 100644 doc/forum/How_to_remove_annex_on_osx__63__.mdwn
 create mode 100644 doc/forum/How_to_remove_annex_on_osx__63__/comment_1_18fc46bdb5bc44916e355a9900e9c0d1._comment
 create mode 100644 doc/forum/How_to_rename_a_remote__63__.mdwn
 create mode 100644 doc/forum/How_to_rename_a_remote__63__/comment_1_a9bfbd82f7bb47661f0d9e0e0d904332._comment
 create mode 100644 doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__.mdwn
 create mode 100644 doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__/comment_1_8e2a14842b44844f90c80b862a1b3a6d._comment
 create mode 100644 doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__/comment_2_031ab6b5a2765ed9e2b185b24a8cbd78._comment
 create mode 100644 doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__/comment_3_93f20519483837c59a75821621e22dee._comment
 create mode 100644 doc/forum/How_to_restore_symlinks.mdwn
 create mode 100644 doc/forum/How_to_restore_symlinks/comment_1_c67e752cf7d5431096fab4b3304790a7._comment
 create mode 100644 doc/forum/How_to_restore_symlinks/comment_2_f9ec6096595e2c149c48924e3b54542f._comment
 create mode 100644 doc/forum/How_to_restore_symlinks/comment_3_4ff80729787a2a4e2baf05dd1db37da3._comment
 create mode 100644 doc/forum/How_to_retroactively_annex_a_file_already_in_a_git_repo.mdwn
 create mode 100644 doc/forum/How_to_revert_metadata_changes.mdwn
 create mode 100644 doc/forum/How_to_revert_metadata_changes/comment_1_de40f1a3f364ca6d2f9bb489f4d64cb3._comment
 create mode 100644 doc/forum/How_to_see_what_will_go_to_annex_vs_git.mdwn
 create mode 100644 doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_1_d26ea587da51a6f663d64ebb19976a2b._comment
 create mode 100644 doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_2_316becb188245c1fbbe6daa63505bc34._comment
 create mode 100644 doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_3_93f3bc4f8e9e2aeef4e417bba2041ee4._comment
 create mode 100644 doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_4_558abc4b928649ff3b199a7154c052bf._comment
 create mode 100644 doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_5_ce998d6fc7868a2f129bad755d04b186._comment
 create mode 100644 doc/forum/How_to_set_backend_based_on_file_size_in_.gitattributes.mdwn
 create mode 100644 doc/forum/How_to_set_backend_based_on_file_size_in_.gitattributes/comment_1_c8ac6b924d4446d4a1a12fb34532fd69._comment
 create mode 100644 doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__.mdwn
 create mode 100644 doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_1_bedaf308cfc70b9e751914a400ebcbc2._comment
 create mode 100644 doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_2_d665b1514253c8aa487ebf8b2728e3b1._comment
 create mode 100644 doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_3_aef42387a3673ab6710fb23e878d7e17._comment
 create mode 100644 doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_4_bfbcc041db472f4808979e6b3d7c4be2._comment
 create mode 100644 doc/forum/How_to_shrink_transfer_repo__63__.mdwn
 create mode 100644 doc/forum/How_to_shrink_transfer_repo__63__/comment_1_6b110311f4c147dc315c4f610cf56afa._comment
 create mode 100644 doc/forum/How_to_shrink_transfer_repo__63__/comment_2_8e596cd606935d82bd6604f5c9c500a2._comment
 create mode 100644 doc/forum/How_to_shrink_transfer_repo__63__/comment_3_c536a946b717e9bdcb883b58cd0336ae._comment
 create mode 100644 doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__.mdwn
 create mode 100644 doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__/comment_1_1c913395f076ee203caaab057da8afbe._comment
 create mode 100644 doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__/comment_2_081793c52bf15c74a7f48a67c49ff818._comment
 create mode 100644 doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__/comment_3_f8e0376beb486cf8ce52384ff511ecf2._comment
 create mode 100644 doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__.mdwn
 create mode 100644 doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_1_c4e972c8635f2fa460cd6621f3d993c6._comment
 create mode 100644 doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_2_e06abc9a2f7cf055523f3d35e4eed9bc._comment
 create mode 100644 doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_3_81d128be0fa60475062e795f34d920f7._comment
 create mode 100644 doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_4_43615e11f1c6d08f5850458d540f5bac._comment
 create mode 100644 doc/forum/How_to_sync_without_enumerating_files__63__.mdwn
 create mode 100644 doc/forum/How_to_sync_without_enumerating_files__63__/comment_1_ad78c67ae1bb4dc8ed800779c0298158._comment
 create mode 100644 doc/forum/How_to_use_--jobs__61__10_by_default__63__.mdwn
 create mode 100644 doc/forum/How_to_use_--jobs__61__10_by_default__63__/comment_1_3c47ad3f0c17e475ea42438a42085f9c._comment
 create mode 100644 doc/forum/How_to_view_progress_of_in-progress_upload__63__.mdwn
 create mode 100644 doc/forum/How_to_view_progress_of_in-progress_upload__63__/comment_1_794cc9bdf728c96dd7c50cf402573cf5._comment
 create mode 100644 doc/forum/How_to_view_progress_of_in-progress_upload__63__/comment_2_6347e08b599239b6416957e9a7114157._comment
 create mode 100644 doc/forum/How_to_work_with_transfer_repos_manually__63__.mdwn
 create mode 100644 doc/forum/How_to_work_with_transfer_repos_manually__63__/comment_1_3dec369405e6b6a4a6e5121546c03712._comment
 create mode 100644 doc/forum/How_to_work_with_transfer_repos_manually__63__/comment_1_b8f3c09b470d99578a4a17064498dd39._comment
 create mode 100644 doc/forum/How_to_work_with_transfer_repos_manually__63__/comment_3_be2c594bc1d162cfb1acc3a01fc284f2._comment
 create mode 100644 doc/forum/Howto_remove_a_repository__63__.mdwn
 create mode 100644 doc/forum/Howto_remove_a_repository__63__/comment_1_b55fa4e92bb457ecaa5ca8f5cee7be1d._comment
 create mode 100644 doc/forum/Howto_remove_unused_files.mdwn
 create mode 100644 doc/forum/Howto_remove_unused_files/comment_1_f2a7948268ce3cb3967a9fdd8ccc570a._comment
 create mode 100644 doc/forum/Howto_remove_unused_files/comment_2_9b4d198c2d8a52adef3d166a8196fc0d._comment
 create mode 100644 doc/forum/Howto_remove_unused_files/comment_3_441d10901d5c055ac3ed2a6cb61c075c._comment
 create mode 100644 doc/forum/Huge_differences_in_sync_times_in_different_directories_of_same_machines.mdwn
 create mode 100644 doc/forum/Huge_differences_in_sync_times_in_different_directories_of_same_machines/comment_1_445766c0f646e9cb5b45b863ad87e85a._comment
 create mode 100644 doc/forum/Huge_differences_in_sync_times_in_different_directories_of_same_machines/comment_2_b3953f30fb817ee3753f888a871de51f._comment
 create mode 100644 doc/forum/Idly_syncing_back_and_forth_creates_commits.mdwn
 create mode 100644 doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_1_e6a60889876bd49855fe60849db147ef._comment
 create mode 100644 doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_2_1053e88c417e8b46648f645a466145e2._comment
 create mode 100644 doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_3_577f62d506a66770e746a50fc103901d._comment
 create mode 100644 doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_4_0079c41305493873521d3af45075a2c4._comment
 create mode 100644 doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_5_4879d44cc69022a71fc8baf8f31a890f._comment
 create mode 100644 doc/forum/Ignoring_folders__63__.mdwn
 create mode 100644 doc/forum/Ignoring_folders__63__/comment_1_5fbf4d1ae75434118876470b04e2fd72._comment
 create mode 100644 doc/forum/Ignoring_folders__63__/comment_2_1adafdf1fddf8e1256e51b0f56d3a89e._comment
 create mode 100644 doc/forum/Import_availability_info___40__logs__47__refs__47__remotes__41___from_another_repo__63__.mdwn
 create mode 100644 doc/forum/Import_availability_info___40__logs__47__refs__47__remotes__41___from_another_repo__63__/comment_1_32586d9e43dc0c5d0a9e94671586f763._comment
 create mode 100644 doc/forum/Import_existing_files.mdwn
 create mode 100644 doc/forum/Import_existing_files/comment_1_890dea22857d0a38260009602ccf0ec6._comment
 create mode 100644 doc/forum/Import_existing_files/comment_2_362ce3b030970db82c8dd0d98791186b._comment
 create mode 100644 doc/forum/Import_existing_files/comment_3_69188f669e6fe5ca1a8c34c3dc3ec201._comment
 create mode 100644 doc/forum/Import_existing_files/comment_4_9c7677838ad28d540a2a514d718f9f1d._comment
 create mode 100644 doc/forum/Import_existing_files/comment_5_d88cedb3d70342071621c1695c8aeb05._comment
 create mode 100644 doc/forum/Import_existing_files/comment_6_be5331f1203b9610259a84c783b429b0._comment
 create mode 100644 doc/forum/Import_options.mdwn
 create mode 100644 doc/forum/Import_options/comment_1_118a5f978090a3909299876a01c0adec._comment
 create mode 100644 doc/forum/Import_options/comment_2_21da91f08cb6b28ae3e79ade033db516._comment
 create mode 100644 doc/forum/Improving_the_git-annex_forum.mdwn
 create mode 100644 doc/forum/Improving_the_git-annex_forum/comment_1_63c52c977689a5da34fec65391c25fd6._comment
 create mode 100644 doc/forum/Improving_the_git-annex_forum/comment_2_7b4b8d78148f41df332d8f9125ca9842._comment
 create mode 100644 doc/forum/Improving_the_git-annex_forum/comment_3_71d5568d2ac64f83dba11100124addd1._comment
 create mode 100644 doc/forum/Improving_the_git-annex_forum/comment_4_847be68ea1992e6c2ceb2c79cfb65f5f._comment
 create mode 100644 doc/forum/Init_a_directory_special_remote_with_already_existing_files.mdwn
 create mode 100644 doc/forum/Init_a_directory_special_remote_with_already_existing_files/comment_1_f2a2f7309145d26d124c73ce6fcb32a5._comment
 create mode 100644 doc/forum/Init_a_directory_special_remote_with_already_existing_files/comment_2_c1740ce07be483d198880f5844fea7e0._comment
 create mode 100644 doc/forum/Initial_macOS_setup_between_two_local_Macs.mdwn
 create mode 100644 doc/forum/Install_git_annex_v6_in_Ubuntu_14.04_Trusty.mdwn
 create mode 100644 doc/forum/Install_git_annex_v6_in_Ubuntu_14.04_Trusty/comment_1_9c715cbb0550cad29402dd2fca1917f9._comment
 create mode 100644 doc/forum/Install_without_root__63__.mdwn
 create mode 100644 doc/forum/Install_without_root__63__/comment_1_097bbbde8a91e1d0cee9da6cba23ae5c._comment
 create mode 100644 doc/forum/Install_without_root__63__/comment_2_891cd24fb0806ae9087cd83d22d8ce6e._comment
 create mode 100644 doc/forum/Install_without_root__63__/comment_3_23fe7b46c6f48072618f05c1368a8917._comment
 create mode 100644 doc/forum/Install_without_root__63__/comment_4_f015ab0bfed0b440b915c233be73c316._comment
 create mode 100644 doc/forum/Integrating_annex_get_into_git_checkout_with_hooks.mdwn
 create mode 100644 doc/forum/Integrating_annex_get_into_git_checkout_with_hooks/comment_1_7258d0203a0578d0f4e0221295511237._comment
 create mode 100644 doc/forum/Integrating_annex_get_into_git_checkout_with_hooks/comment_2_9ca7b7dfc039c443c4afa9b6ea7c78bd._comment
 create mode 100644 doc/forum/Integrating_git-annex_with_Windows_Git_Extensions__63__.mdwn
 create mode 100644 doc/forum/Integrating_git-annex_with_Windows_Git_Extensions__63__/comment_1_2dac6e3ccf559d98f74c456c0ca7aafc._comment
 create mode 100644 doc/forum/Integrating_git-annex_with_Windows_Git_Extensions__63__/comment_2_181c6c87c64e4fbe798c108537c6a597._comment
 create mode 100644 doc/forum/Invalid_cross-device_link.mdwn
 create mode 100644 doc/forum/Invalid_cross-device_link/comment_1_46c35e04c8f8cb7205f08aa71cc4912a._comment
 create mode 100644 doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term.mdwn
 create mode 100644 doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_1_9984f65d6e89f0f88b33cbd499e859eb._comment
 create mode 100644 doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_2_d7bdfeb33bac7f139b0bdc1c6fb53237._comment
 create mode 100644 doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_3_7dc224cb0b88bf07879e03717efffa17._comment
 create mode 100644 doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_4_a538f8a4272b5ce134607dc7201e3f04._comment
 create mode 100644 doc/forum/Is_S3___34__Standard-Infrequent_Access__34___storage_class_supported__63__.mdwn
 create mode 100644 doc/forum/Is_S3___34__Standard-Infrequent_Access__34___storage_class_supported__63__/comment_1_ddc2a1f2b1d810a40b459896993d2e8d._comment
 create mode 100644 doc/forum/Is___96__sync_--cleanup__96___by_default_a_bad_idea__63__.mdwn
 create mode 100644 doc/forum/Is___96__sync_--cleanup__96___by_default_a_bad_idea__63__/comment_1_51e5f78a1cbd37598f3f0f6746df7320._comment
 create mode 100644 doc/forum/Is_an_automagic_upgrade_of_the_object_directory_safe__63__.mdwn
 create mode 100644 doc/forum/Is_an_automagic_upgrade_of_the_object_directory_safe__63__/comment_1_c25900b9d2d62cc0b8c77150bcfebadf._comment
 create mode 100644 doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__.mdwn
 create mode 100644 doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_1_f9decde3955f10148febc4646fba5a68._comment
 create mode 100644 doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_2_ed32a48edce4f150bedf24cfe91de254._comment
 create mode 100644 doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_3_ef9618850e5e688bac3c646983f00ed8._comment
 create mode 100644 doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_4_4bf460c5826c36b205e418c4f3f7d770._comment
 create mode 100644 doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools.mdwn
 create mode 100644 doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_1_5c593876993bef4dfaa052278a3ba5be._comment
 create mode 100644 doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_2_02ecc1b9f370f6bba84dd598030e0fcd._comment
 create mode 100644 doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_4_7d9d45716e9e847f3bde214949796222._comment
 create mode 100644 doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_4_ba3422afc8ae83bd822616cc1a99a5b9._comment
 create mode 100644 doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_5_d8c402765b3a5896db91605f43149001._comment
 create mode 100644 doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_6_2d78e647a46cfbb002cf66e6318043ab._comment
 create mode 100644 doc/forum/Is_it_possible_to_cherry_pick_from_a_repo__63__.mdwn
 create mode 100644 doc/forum/Is_it_possible_to_cherry_pick_from_a_repo__63__/comment_1_82efe5c0b37fdcb31b6a4ca62b66123f._comment
 create mode 100644 doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__.mdwn
 create mode 100644 doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_1_f452c911b24ba40aef3be5bdaac9f9ee._comment
 create mode 100644 doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_2_7373ec002ca78f4f382ef9297f39639e._comment
 create mode 100644 doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_3_cda315119bd3ccce74bc3df8dd56bf1a._comment
 create mode 100644 doc/forum/Is_it_possible_to_make_git-sync_not_nullify_symlinks__63__.mdwn
 create mode 100644 doc/forum/Is_it_possible_to_make_git-sync_not_nullify_symlinks__63__/comment_1_d6f2d2cdc5f4ffde9eee9f3a8c215a06._comment
 create mode 100644 doc/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__.mdwn
 create mode 100644 doc/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__/comment_1_a35571c77eaab5bcc0d841543a13162f._comment
 create mode 100644 doc/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__/comment_2_c8f185b0751ccd17a657e954cbeb2864._comment
 create mode 100644 doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__.mdwn
 create mode 100644 doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_1_e74ddd1bf47f856369568b1fcd8d4f9c._comment
 create mode 100644 doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_2_c47c27ce283cc4fcb80949860e2a4927._comment
 create mode 100644 doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_3_47511f7b731cdefd108241bedb116f68._comment
 create mode 100644 doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_4_07a190aa19006611739cccfc5aac5a6f._comment
 create mode 100644 doc/forum/Is_parallel_fsck_for_two_or_more_different_directories_possible__63__.mdwn
 create mode 100644 doc/forum/Is_parallel_fsck_for_two_or_more_different_directories_possible__63__/comment_1_34af73f211cce966927757f7deec88eb._comment
 create mode 100644 doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__.mdwn
 create mode 100644 doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__/comment_1_c250362236a33d8dc9bf5ed825318c40._comment
 create mode 100644 doc/forum/Is_there_a___34__git_annex_cat-file__34___type_command__63__.mdwn
 create mode 100644 doc/forum/Is_there_a___34__git_annex_cat-file__34___type_command__63__/comment_1_fe3dc778b35119d3ede2d341cac7a15b._comment
 create mode 100644 doc/forum/Is_there_a_way_to_get_back_to_clean-state_after_unworking_annex_assistant_configuration_attempt__63__.mdwn
 create mode 100644 doc/forum/Is_there_a_way_to_get_back_to_clean-state_after_unworking_annex_assistant_configuration_attempt__63__/comment_1_d77fbbbe3a7438a1e79f175df1f69ef3._comment
 create mode 100644 doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__.mdwn
 create mode 100644 doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_1_70c8e23c87a6c48e728a6685e7189e98._comment
 create mode 100644 doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_2_c0c6e38fe99dd273764071574c8b3c1d._comment
 create mode 100644 doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_3_c80d15f6844e29dee2bf7ba0a6d6d093._comment
 create mode 100644 doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_4_a8ebda7dd8d52e6c1137dbb646e21e5c._comment
 create mode 100644 doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_5_022f36242ef57158feab0918f41a7ff1._comment
 create mode 100644 doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_6_5527d611a132f3e9bc0d71c593abf673._comment
 create mode 100644 doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_7_92bf43545c46d302089820cfdd03141b._comment
 create mode 100644 doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_8_a6ae8bc3b5caf0d3d49a919ab5ec5778._comment
 create mode 100644 doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_9_7fcc62493d261c22149f85f48bb95efc._comment
 create mode 100644 doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__.mdwn
 create mode 100644 doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__/comment_1_e30310472df6ed2928dfd63464c6bae7._comment
 create mode 100644 doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__/comment_2_f093b16307bd369399574fc651569b73._comment
 create mode 100644 doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__/comment_3_1edab7e44e7eae6d8f06a917704b17ec._comment
 create mode 100644 doc/forum/Is_there_a_way_to_override_the_import_destination__63__.mdwn
 create mode 100644 doc/forum/Is_there_a_way_to_override_the_import_destination__63__/comment_1_5f094cc606eebd2aeeaaa4b861cf2c21._comment
 create mode 100644 doc/forum/Is_there_a_way_to_unannex_some_file___63__.mdwn
 create mode 100644 doc/forum/Is_there_a_way_to_unannex_some_file___63__/comment_1_82095cef37dd815bcd1d101a1715e3c7._comment
 create mode 100644 doc/forum/Is_there_a_way_to_unannex_some_file___63__/comment_2_3b05e9eaa554b70594f0195dfcef831d._comment
 create mode 100644 doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__.mdwn
 create mode 100644 doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_1_3760d5b8c8012405eef17e4d07cf151c._comment
 create mode 100644 doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_2_b95ce6b13ae45a2fca05260a7f77148f._comment
 create mode 100644 doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_3_1c8f023b8d7a50cfce6d3464b12e446b._comment
 create mode 100644 doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_4_f1e234e80a6873b33986bec8d51c1001._comment
 create mode 100644 doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_5_2c43830a95cd8955da20cc6dba27a9b6._comment
 create mode 100644 doc/forum/Is_there_any_delta_handling_for_file_modifications__63__.mdwn
 create mode 100644 doc/forum/Is_there_any_delta_handling_for_file_modifications__63__/comment_1_d901ac998c9fdb844c593d782c31cc73._comment
 create mode 100644 doc/forum/Is_there_any_delta_handling_for_file_modifications__63__/comment_2_e46cb391ce377c3a8eb40155a5d0f001._comment
 create mode 100644 doc/forum/Issues_with_IPFS_special_remote.mdwn
 create mode 100644 doc/forum/Issues_with_IPFS_special_remote/comment_10_d13e439c3c242606d8b4377831e38a2b._comment
 create mode 100644 doc/forum/Issues_with_IPFS_special_remote/comment_11_e53b0158471605950896cafac7aac4da._comment
 create mode 100644 doc/forum/Issues_with_IPFS_special_remote/comment_1_74c586e5af079f0d6c42975ac294e766._comment
 create mode 100644 doc/forum/Issues_with_IPFS_special_remote/comment_2_283aafce5dc1735310daa8329a432002._comment
 create mode 100644 doc/forum/Issues_with_IPFS_special_remote/comment_3_fa017d01e9eca59074adf2224e20994b._comment
 create mode 100644 doc/forum/Issues_with_IPFS_special_remote/comment_4_e49c62ca2e0f0d455469d5bc4483aff3._comment
 create mode 100644 doc/forum/Issues_with_IPFS_special_remote/comment_5_2147808f9b15be995988e2c71bc0b271._comment
 create mode 100644 doc/forum/Issues_with_IPFS_special_remote/comment_6_3a34db5281419578201f5f74cf97a830._comment
 create mode 100644 doc/forum/Issues_with_IPFS_special_remote/comment_7_765fef6f0b5da3e5c87c029fea2362a1._comment
 create mode 100644 doc/forum/Issues_with_IPFS_special_remote/comment_8_edd64d315651d5c7d5e1f802b68b8b68._comment
 create mode 100644 doc/forum/Issues_with_IPFS_special_remote/comment_9_07b1f3c1e744e910f1738925d79e3d1a._comment
 create mode 100644 doc/forum/Issues_with_non-sync_workflow.mdwn
 create mode 100644 doc/forum/Issues_with_non-sync_workflow/comment_1_99f89201446005f77d9278a7a889638d._comment
 create mode 100644 doc/forum/Issues_with_non-sync_workflow/comment_2_f27ec2462e5a8f6f96c6e2b7dd3f87ca._comment
 create mode 100644 doc/forum/Issues_with_non-sync_workflow/comment_3_db02b002a977b57be0102d8ac7c2037f._comment
 create mode 100644 doc/forum/Issues_with_non-sync_workflow/comment_4_a93d502253cf9f164fbcd23ca755db9d._comment
 create mode 100644 doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo.mdwn
 create mode 100644 doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo/comment_1_b61139816f55dbc4f7eac22207f243c0._comment
 create mode 100644 doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo/comment_2_f6196f814ed388d276947ffcc92ff37c._comment
 create mode 100644 doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo/comment_3_1556ebbb2a8db4aa859e3852160df044._comment
 create mode 100644 doc/forum/JavaScript__47__TypeScript_API_for_git-annex_available.mdwn
 create mode 100644 doc/forum/JavaScript__47__TypeScript_API_for_git-annex_available/comment_1_69cdea649eb79fa796fb3713dc0ac23f._comment
 create mode 100644 doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__.mdwn
 create mode 100644 doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_1_08d3fd14a57b5d4dfb2cac411aba757f._comment
 create mode 100644 doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_2_ff5b55e81c0d48968e59e1783943f286._comment
 create mode 100644 doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_3_f63a66196db731fb04d8e078136eeb3d._comment
 create mode 100644 doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_4_a7ea99c0b8bdc257c0c3453bdb5ce1ca._comment
 create mode 100644 doc/forum/Keybase_encrypted_git_as_a_remote__63__.mdwn
 create mode 100644 doc/forum/Keybase_encrypted_git_as_a_remote__63__/comment_1_38d868bf2e93c43091f9f337d9ec840d._comment
 create mode 100644 doc/forum/Lacking_webapp_on_Trisquel__47__Ubuntu_Precise.mdwn
 create mode 100644 doc/forum/Lacking_webapp_on_Trisquel__47__Ubuntu_Precise/comment_1_6bd27bd31833336c1df783253378ccae._comment
 create mode 100644 doc/forum/Large_Uploads_to_S3__63__.mdwn
 create mode 100644 doc/forum/Large_Uploads_to_S3__63__/comment_1_c1fd2ed0b74ce58f818ab53158e581f3._comment
 create mode 100644 doc/forum/Large_Windows_annexes_with___42__nix_remotes.mdwn
 create mode 100644 doc/forum/Large_Windows_annexes_with___42__nix_remotes/comment_1_a38e0ecef49a81a1d2b3d2eaabab65ab._comment
 create mode 100644 doc/forum/Large_Windows_annexes_with___42__nix_remotes/comment_1_c59077a9d6500df0cd88ac5a18085085._comment
 create mode 100644 doc/forum/Large_Windows_annexes_with___42__nix_remotes/comment_2_bfc92cb2117b26eec95687950827c78b._comment
 create mode 100644 doc/forum/Layout_mismatch_between_symlinks_and_annex_objects.mdwn
 create mode 100644 doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_1_854786810dc4246cdaa38ff10c55bbca._comment
 create mode 100644 doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment
 create mode 100644 doc/forum/Let_watch_selectively_annex_files.mdwn
 create mode 100644 doc/forum/Let_watch_selectively_annex_files/comment_1_8379de87d16502d9aadf252da01e4d9a._comment
 create mode 100644 doc/forum/Let_watch_selectively_annex_files/comment_2_2219ff6b4dc927eb2a299cd1af90aed8._comment
 create mode 100644 doc/forum/Link_to_local_remote_instead_of_broken_link_when_possible__63__.mdwn
 create mode 100644 doc/forum/Link_to_local_remote_instead_of_broken_link_when_possible__63__/comment_1_ce0464d5fca6ada9f1477831fd47ce09._comment
 create mode 100644 doc/forum/Links_or_actual_files__63___Confused__33__.mdwn
 create mode 100644 doc/forum/Links_or_actual_files__63___Confused__33__/comment_1_779cee2448d7070b1dd636d01296c01e._comment
 create mode 100644 doc/forum/Links_or_actual_files__63___Confused__33__/comment_2_bccda88697ab7beec0b9fe9ee0230688._comment
 create mode 100644 doc/forum/Links_or_actual_files__63___Confused__33__/comment_3_c2a9da3f03b55ff294dc0d2010380119._comment
 create mode 100644 doc/forum/List_annexed_files_in_chronological_order__63__.mdwn
 create mode 100644 doc/forum/List_annexed_files_in_chronological_order__63__/comment_1_825c950574b3a2f083554f474c9f7b50._comment
 create mode 100644 doc/forum/List_if_files_are_stored_in_annex_or_in_git.mdwn
 create mode 100644 doc/forum/List_if_files_are_stored_in_annex_or_in_git/comment_1_9206087f7320982ef26ef401d39a394f._comment
 create mode 100644 doc/forum/List_if_files_are_stored_in_annex_or_in_git/comment_2_2eeef9505e976288e7a09f31d0c09dda._comment
 create mode 100644 doc/forum/Local_and_remote_in_direct_mode.mdwn
 create mode 100644 doc/forum/Local_and_remote_in_direct_mode/comment_1_45f89ebcb6092d1b2582feebc8a5e9d7._comment
 create mode 100644 doc/forum/Local_and_remote_in_direct_mode/comment_2_90eeb2bffdb2db8032f9a0eac630ed56._comment
 create mode 100644 doc/forum/Local_and_remote_in_direct_mode/comment_3_859ec2b3a8e938073b2099fdc5781109._comment
 create mode 100644 doc/forum/Locating_errors_on_fsck.mdwn
 create mode 100644 doc/forum/Locating_errors_on_fsck/comment_1_5a4c54b59f2a3f8519f2dab608a1e92d._comment
 create mode 100644 doc/forum/Locating_errors_on_fsck/comment_2_0277bac79694efffba0e59706aa66c63._comment
 create mode 100644 doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning.mdwn
 create mode 100644 doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_1_25a04c7345f5b626aa71524603c833ed._comment
 create mode 100644 doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_2_7146a3c69749b9b1001fffc6e7a8bcda._comment
 create mode 100644 doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_3_fd39e6ceffd9bf0709658c34945d8699._comment
 create mode 100644 doc/forum/Looking_at_the_webapp_on_OSX.mdwn
 create mode 100644 doc/forum/Looking_at_the_webapp_on_OSX/comment_1_68820f2f469356633c1abb18a47e0c59._comment
 create mode 100644 doc/forum/Looking_at_the_webapp_on_OSX/comment_2_4ce86546d8a135df9cfab46b4612fa0b._comment
 create mode 100644 doc/forum/Looking_at_the_webapp_on_OSX/comment_3_6d398a2cceff14a1b774b85ee1725073._comment
 create mode 100644 doc/forum/Looking_at_the_webapp_on_OSX/comment_4_5e503787a4b1d3534c5e20da5480b763._comment
 create mode 100644 doc/forum/Looking_at_the_webapp_on_OSX/comment_5_c735841bc230efc61594ea013fc2902b._comment
 create mode 100644 doc/forum/Looking_at_the_webapp_on_OSX/comment_6_0e489fbfc89d282e9eb47f1b814ff70c._comment
 create mode 100644 doc/forum/Lost_git_repository._Recovery_from_S3_remote__63__.mdwn
 create mode 100644 doc/forum/Lost_git_repository._Recovery_from_S3_remote__63__/comment_1_a9028f00461ec1eddbeb699dadcbab72._comment
 create mode 100644 doc/forum/Lost_git_repository._Recovery_from_S3_remote__63__/comment_2_0dbf6fcd15007ba66323ecf2b154ad2e._comment
 create mode 100644 doc/forum/Lots_of_4k_symlinks.mdwn
 create mode 100644 doc/forum/Lots_of_4k_symlinks/comment_1_96384eaeef1d067a24678c7aa3613063._comment
 create mode 100644 doc/forum/Lots_of_4k_symlinks/comment_2_be9617e8cbc231069c44bc9f077ce673._comment
 create mode 100644 doc/forum/Lots_of_4k_symlinks/comment_3_80b3a84e6d79871bbbef13d4bc87cc37._comment
 create mode 100644 doc/forum/Lots_of_4k_symlinks/comment_4_be12d26936b3502445e880be997b8877._comment
 create mode 100644 doc/forum/Lots_of_4k_symlinks/comment_5_ab3884748f3271a77ba3320f25d74414._comment
 create mode 100644 doc/forum/Lots_of_4k_symlinks/comment_6_fa72056ee788ac0f2c15bb57d9876cf6._comment
 create mode 100644 doc/forum/Lots_of_4k_symlinks/comment_7_bd6b81815e5888c26d7a8a96e565519e._comment
 create mode 100644 doc/forum/Lyve_Home.mdwn
 create mode 100644 doc/forum/MD5_and_MD5E_backends_no_longer_available__63__.mdwn
 create mode 100644 doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_1_e21fa57a2f2dc4e99737877c6a48cbfe._comment
 create mode 100644 doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_2_5025d16f59f314711e49537e542b7c83._comment
 create mode 100644 doc/forum/Make_GA_aware_of_externally-made_copies.mdwn
 create mode 100644 doc/forum/Make_GA_aware_of_externally-made_copies/comment_1_0e2edea494810a8614f628ec46b934e4._comment
 create mode 100644 doc/forum/Make_GA_aware_of_externally-made_copies/comment_2_b7fcfd87efb17d5159ec49eb218fbd8e._comment
 create mode 100644 doc/forum/Make_GA_aware_of_externally-made_copies/comment_3_c1d69396c7bb208b6f82f2f65a282cfb._comment
 create mode 100644 doc/forum/Make_GA_aware_of_externally-made_copies/comment_4_b0d7ef111f4862d6b759cde45696a676._comment
 create mode 100644 doc/forum/Make_whereis_output_more_compact.mdwn
 create mode 100644 doc/forum/Making_Firefox_not_dereference_symlinks_on_open.mdwn
 create mode 100644 doc/forum/Making_Firefox_not_dereference_symlinks_on_open/comment_1_a7b092f2291fa515279cf7dce23df20d._comment
 create mode 100644 doc/forum/Making_a_git-annexy_symlink___34__known__34____63__.mdwn
 create mode 100644 doc/forum/Making_a_git-annexy_symlink___34__known__34____63__/comment_1_e04edbe950a41887c4c11a226ca77dce._comment
 create mode 100644 doc/forum/Making_a_git-annexy_symlink___34__known__34____63__/comment_2_de77cc2bee45706c4bbe407d8846778e._comment
 create mode 100644 doc/forum/Making_a_public_read-write_git-annex_repo.mdwn
 create mode 100644 doc/forum/Making_a_public_read-write_git-annex_repo/comment_1_8279171695a9a7a7501d5ee8c7bab66c._comment
 create mode 100644 doc/forum/Making_a_public_read-write_git-annex_repo/comment_2_2cd770a12bfe3b44531b024c41570758._comment
 create mode 100644 doc/forum/Making_a_public_read-write_git-annex_repo/comment_3_19694d397813fe1bb949fd3b6ae49f4b._comment
 create mode 100644 doc/forum/Making_a_public_read-write_git-annex_repo/comment_4_c8b104eb34efdd7c7670f2133081d1d8._comment
 create mode 100644 doc/forum/Making_a_public_read-write_git-annex_repo/comment_5_48e247fddb0d302102c74cac7f2228ff._comment
 create mode 100644 doc/forum/Making_git-annex_a_self-funded_project__63__.mdwn
 create mode 100644 doc/forum/Making_git-annex_a_self-funded_project__63__/comment_1_4a1ba95b7231ba973ddb672d2419e28c._comment
 create mode 100644 doc/forum/Making_git-annex_a_self-funded_project__63__/comment_2_7c476ae92e63c991f229708678874ca2._comment
 create mode 100644 doc/forum/Making_git-annex_less_necessary.mdwn
 create mode 100644 doc/forum/Making_git-annex_less_necessary/comment_1_03faaa3866778d24cd03887b85dc9954._comment
 create mode 100644 doc/forum/Making_git-annex_less_necessary/comment_2_2db02a94dffd525885c9d7fc6c5fa464._comment
 create mode 100644 doc/forum/Making_git-annex_less_necessary/comment_3_429ec656e0ac02f98843f8d7f3c02d6a._comment
 create mode 100644 doc/forum/Making_git-annex_less_necessary/comment_4_384813dd022dfd9c1ef14e0f1479a123._comment
 create mode 100644 doc/forum/Making_git-annex_preserve_file_name__44___and_directory.mdwn
 create mode 100644 doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_1_03a5369518a96c0550e68af520ed0060._comment
 create mode 100644 doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_2_64863e149cc62a778b006ffe2bf82d06._comment
 create mode 100644 doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_3_bbd3ea45cf560031856e9e8416b4d126._comment
 create mode 100644 doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_4_2c36e30b3e2f6874c63e03307207a6b9._comment
 create mode 100644 doc/forum/Malicious_autoenabled_remotes.mdwn
 create mode 100644 doc/forum/Malicious_autoenabled_remotes/comment_1_c82464f40eb1442aadd0f1e89b72f41e._comment
 create mode 100644 doc/forum/Malicious_autoenabled_remotes/comment_2_37456c0a159453fa984c5a003578d1eb._comment
 create mode 100644 doc/forum/Malicious_autoenabled_remotes/comment_3_608213f5d0df482b731ae1502cdd87af._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__.mdwn
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_10_a061d300b718ad943c940e122cc57220._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_11_76529080054407570611b4357ce4f3ed._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_12_9acf5ce41a023f3848a51891cceeb51b._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_13_0a343a8fdad66765371ca22581b35b84._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_14_b315c50d796d73bfc35acebee1836f40._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_15_9ddd6278ea00c5594083347b5b9b8405._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_16_c3f6cb58dd2328b7af8dd2657c2e2a1e._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_17_455ab8b72c477769d68eb4348e911234._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_18_679ad639cbba7f9a4d28131219d20178._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_19_854531569edbb5c152c4d6b0d764a6c5._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_1_25e65ee3949e7d918376298cf11585f2._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_20_a80b9ce3a78fb44c9d60e877146d9e59._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_2_8a71ca048f9de29a198a6afb17d5315e._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_3_e3d1d3a3d3d831432ec940a8ab6f31e9._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_4_26a33eae98b4faaf6baf6635e3d28a8f._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_5_49ac298d39c824b0e52a239961463e09._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_6_55a4a3616ea59654da1c2f9902561e3b._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_7_92a2af3e0e328bb48bcc67a69187ee57._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_8_f6e39e71882d55cdc061166aea3e2bd3._comment
 create mode 100644 doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_9_6c45a6264d69e22800c329a0f8a2d470._comment
 create mode 100644 doc/forum/Managing_multiple_annexes_with_assistant__63__.mdwn
 create mode 100644 doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_1_ba8c70e4a46441b48ad910625636eee5._comment
 create mode 100644 doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_2_4b4f0a7d84a51ae92536e2c190256069._comment
 create mode 100644 doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_3_86daadc565f96db5db13b6dbcbc66db3._comment
 create mode 100644 doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_4_e43d71ddfdfdb7bcb13bfb894de6a5ec._comment
 create mode 100644 doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_5_e94d33be83b45918d1a39d6e16fba4b4._comment
 create mode 100644 doc/forum/Managing_multiple_repositories_concurrently__63__.mdwn
 create mode 100644 doc/forum/Managing_multiple_repositories_concurrently__63__/comment_1_ebec1ddad71e961cdc9b21cbddfbcdaf._comment
 create mode 100644 doc/forum/Manipulate_a_git-annex_repo_from_an_Android_app.mdwn
 create mode 100644 doc/forum/Manipulate_a_git-annex_repo_from_an_Android_app/comment_1_c59ec715eb02fbdd63780b2450ff2de1._comment
 create mode 100644 doc/forum/Manipulate_a_git-annex_repo_from_an_Android_app/comment_2_20ee5f900a2ff6154c0d90263579723e._comment
 create mode 100644 doc/forum/Manual_Setup_of_a_Central_Repo.mdwn
 create mode 100644 doc/forum/Manual_Setup_of_a_Central_Repo/comment_1_3a163fd5629dc40423f1290a78ae1c07._comment
 create mode 100644 doc/forum/Manual_commit_message_in_direct_mode.mdwn
 create mode 100644 doc/forum/Manual_commit_message_in_direct_mode/comment_1_32f95eefec25bb127ed96248446c21b1._comment
 create mode 100644 doc/forum/Manual_commit_message_in_direct_mode/comment_2_bf1d10067379c802ac5020d8becd6d35._comment
 create mode 100644 doc/forum/Manual_local_pairing_without_webapp__63__.mdwn
 create mode 100644 doc/forum/Manual_local_pairing_without_webapp__63__/comment_1_1f280e38bf5fa81d3a8cc4887f32e590._comment
 create mode 100644 doc/forum/Manual_local_pairing_without_webapp__63__/comment_2_d83cc10b2359eb3578c6c4dd299cf308._comment
 create mode 100644 doc/forum/Manual_mode_option_in_assistant_auto-syncs.mdwn
 create mode 100644 doc/forum/Manual_mode_option_in_assistant_auto-syncs/comment_1_4a0468b6ca2ffff8ef8f19800597567d._comment
 create mode 100644 doc/forum/Manual_webapp_behaviour_on_ARM.mdwn
 create mode 100644 doc/forum/Manual_webapp_behaviour_on_ARM/comment_1_5431a57aa7d659faf0aee12e638dd1ba._comment
 create mode 100644 doc/forum/Manually_moving_annex_objects_to_new_repo.mdwn
 create mode 100644 doc/forum/Manually_moving_annex_objects_to_new_repo/comment_1_f9b894bafc5ab19ec7b0b500ddfe00ef._comment
 create mode 100644 doc/forum/Manually_moving_annex_objects_to_new_repo/comment_2_6125e6a7d6b15dee7bf6a6bfe99bcf73._comment
 create mode 100644 doc/forum/Manually_moving_annex_objects_to_new_repo/comment_3_8203d8e0444471b9360b679f49f67fac._comment
 create mode 100644 doc/forum/Massive_drop_in_performance_with_--jobs_option.mdwn
 create mode 100644 doc/forum/Massive_drop_in_performance_with_--jobs_option/comment_2_8a9b5bc3b8a8ef947f2620422307c465._comment
 create mode 100644 doc/forum/Massive_drop_in_performance_with_--jobs_option/comment_2_c9fea9db7116e7ee82a09c23f22b54e9._comment
 create mode 100644 doc/forum/Matching_options_not_working_in_windows_7.mdwn
 create mode 100644 doc/forum/Matching_options_not_working_in_windows_7/comment_1_616f6c6d26088207ce9c044f4b61eec5._comment
 create mode 100644 doc/forum/Matching_options_not_working_in_windows_7/comment_2_b0319c1214c26f64058eb9c38ef6fb0d._comment
 create mode 100644 doc/forum/Matching_options_not_working_in_windows_7/comment_3_d834a6cb0ae1bd47e5280b10ecbaa72d._comment
 create mode 100644 doc/forum/MegaAnnex_not_working.mdwn
 create mode 100644 doc/forum/MegaAnnex_not_working/comment_1_5aa3fd366d4c78ca79bb58005a49791c._comment
 create mode 100644 doc/forum/MegaAnnex_not_working/comment_2_f3eaf1ee06ebac951514d865f298f9d3._comment
 create mode 100644 doc/forum/Merging_two_git-annex_repositories_together__63__.mdwn
 create mode 100644 doc/forum/Merging_two_git-annex_repositories_together__63__/comment_1_b96bb95cdbbc78c0b4b348861e2264bd._comment
 create mode 100644 doc/forum/Merging_two_git-annex_repositories_together__63__/comment_2_539a33b268be5c6954f3112d89dd34ef._comment
 create mode 100644 doc/forum/Messed_up_repo_by_syncing_to_wrong_remote.mdwn
 create mode 100644 doc/forum/Messed_up_repo_by_syncing_to_wrong_remote/comment_1_d1358e46d488532e1922a1bf7c471980._comment
 create mode 100644 doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another.mdwn
 create mode 100644 doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another/comment_1_6e8e3350ae26b6c59daa56b7e86cc46a._comment
 create mode 100644 doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another/comment_2_db4b772371ee49c743605c728e23c91a._comment
 create mode 100644 doc/forum/Migrate_mark_files_dead.mdwn
 create mode 100644 doc/forum/Migrate_mark_files_dead/comment_1_fa155c961d5aecbe055f67d8ace0c208._comment
 create mode 100644 doc/forum/Migrate_mark_files_dead/comment_2_a4512fb8a59f3a4d4ee85651a979f00f._comment
 create mode 100644 doc/forum/Migrate_mark_files_dead/comment_3_a10dbdd505742d5cf03fd435e206d9a2._comment
 create mode 100644 doc/forum/Missing_git-annex.linux__47__runshell.mdwn
 create mode 100644 doc/forum/Missing_git-annex.linux__47__runshell/comment_1_f29a5105649579ef15e79d983c4e1f8e._comment
 create mode 100644 doc/forum/Mixed_content_repos_with_import_and_export.mdwn
 create mode 100644 doc/forum/Mixed_content_repos_with_import_and_export/comment_1_0486a067491456d92220ca638e3095bf._comment
 create mode 100644 doc/forum/Mixed_content_repos_with_import_and_export/comment_2_d0e73dbcf22704cf1c9af8a56533aebe._comment
 create mode 100644 doc/forum/Mixed_content_repos_with_import_and_export/comment_3_d15b0e5a034deeac85806790e53aefaf._comment
 create mode 100644 doc/forum/Mixed_content_repos_with_import_and_export/comment_4_3f7d0f8d1a48d60612aa8477e32fb6f1._comment
 create mode 100644 doc/forum/Mixed_content_repos_with_import_and_export/comment_5_9f11132002d2fee9917e91a7b80a94b3._comment
 create mode 100644 doc/forum/Modification_time_of_files_retained_in_synchronized_remote_copies__63__.mdwn
 create mode 100644 doc/forum/Modification_time_of_files_retained_in_synchronized_remote_copies__63__/comment_1_2b13584998108af0522b898c5d396ba4._comment
 create mode 100644 doc/forum/Modus_operandi_for_local_full_backup.mdwn
 create mode 100644 doc/forum/Modus_operandi_for_local_full_backup/comment_1_fa8ac55ebd94312a36b284047b6cf932._comment
 create mode 100644 doc/forum/Modus_operandi_for_local_full_backup/comment_2_fc2ac75608e91018f67c3753e9b09f76._comment
 create mode 100644 doc/forum/Modus_operandi_for_local_full_backup/comment_3_6089f53d8af5746f2a410d0214567943._comment
 create mode 100644 doc/forum/Modus_operandi_for_local_full_backup/comment_4_4c27aae1361465993fb60997bb0eadf8._comment
 create mode 100644 doc/forum/Move_files_in_git_annex___40__direct_mode__41__.mdwn
 create mode 100644 doc/forum/Move_files_in_git_annex___40__direct_mode__41__/comment_1_6426aca2296b5e03b333d5253ae7d88c._comment
 create mode 100644 doc/forum/Move_history.mdwn
 create mode 100644 doc/forum/Move_history/comment_10_da64814a7dfc2322200130a17bb79923._comment
 create mode 100644 doc/forum/Move_history/comment_11_46ce6990e5921238f98749af830ac5ec._comment
 create mode 100644 doc/forum/Move_history/comment_1_b720837e8e4ab8f4b0648f8ac336a605._comment
 create mode 100644 doc/forum/Move_history/comment_2_17b8c2fd3ac706cd666ad5f5c0a21715._comment
 create mode 100644 doc/forum/Move_history/comment_3_9ff881c26c3bd7f3a61595ffc1df743a._comment
 create mode 100644 doc/forum/Move_history/comment_4_d0c97744e9ccca21e4023f657e9f5f30._comment
 create mode 100644 doc/forum/Move_history/comment_6_0655707fe70710408b93b5f53f8d6f26._comment
 create mode 100644 doc/forum/Move_history/comment_6_f2e1d20e269648358b1eced616727e63._comment
 create mode 100644 doc/forum/Move_history/comment_7_acd690861b31e55352497b32b7c0fd6e._comment
 create mode 100644 doc/forum/Move_history/comment_8_0e4b1629d2bb9d360a1ba65494dd8ccd._comment
 create mode 100644 doc/forum/Move_history/comment_9_1153476304000f417292fdce1f9727bf._comment
 create mode 100644 doc/forum/Move_unsynced_file_in_direct_mode.mdwn
 create mode 100644 doc/forum/Move_unsynced_file_in_direct_mode/comment_1_12a797cba753168dfde9e6339c00f481._comment
 create mode 100644 doc/forum/Move_unsynced_file_in_direct_mode/comment_2_f3aec24668c35780a033f2b035df10ee._comment
 create mode 100644 doc/forum/Moving_S3_special_remote.mdwn
 create mode 100644 doc/forum/Moving_S3_special_remote/comment_1_b030a7afcbf1a329bb35260cf338ff96._comment
 create mode 100644 doc/forum/Moving_S3_special_remote/comment_2_3c4b8afa81590a1f1e2291a08d633b16._comment
 create mode 100644 doc/forum/Moving_large_files_within_the_repo_without_copying___63__.mdwn
 create mode 100644 doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_1_9e3290138133d5a23a80f72342f47ec4._comment
 create mode 100644 doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_2_232b77894dda51d02cbc34bd25d3213b._comment
 create mode 100644 doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_3_d35ac1bdb3fa6e303ad92348ba174158._comment
 create mode 100644 doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_4_4b443ec6b47eaabe214d0c2222083e4a._comment
 create mode 100644 doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout.mdwn
 create mode 100644 doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout/comment_1_f114b75b29123453758b493fae7f5167._comment
 create mode 100644 doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout/comment_2_e377b7614c2961b460a10e285f3db274._comment
 create mode 100644 doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout/comment_3_d251958795ab0867c65cf182e54a6ffe._comment
 create mode 100644 doc/forum/Multiple_group_groupwanted_settings_help.mdwn
 create mode 100644 doc/forum/Multiple_group_groupwanted_settings_help/comment_1_e78d0aa6b23225c509b9e97549fe915b._comment
 create mode 100644 doc/forum/Multiple_group_groupwanted_settings_help/comment_2_b3d95d5c03c7b985d39a4d5a45ba3dec._comment
 create mode 100644 doc/forum/Multiple_interface_to_the_same_annex.mdwn
 create mode 100644 doc/forum/Multiple_interface_to_the_same_annex/comment_1_ea9e3a987112d8bf6421be234bf61d3c._comment
 create mode 100644 doc/forum/Multiple_machine_remotes_on_external_drive.mdwn
 create mode 100644 doc/forum/Multiple_prefered_content_groups.mdwn
 create mode 100644 doc/forum/Multiple_prefered_content_groups/comment_1_b401d234c0730412053f0f6a6f9cf2d6._comment
 create mode 100644 doc/forum/Multiple_prefered_content_groups/comment_2_a91177f4f02500e8fa6594933e128ef0._comment
 create mode 100644 doc/forum/Multiple_remotes_with_the_same_path.mdwn
 create mode 100644 doc/forum/Multiple_remotes_with_the_same_path/comment_1_78f2d8e3906c11ba5753478d08973bd2._comment
 create mode 100644 doc/forum/Multiple_remotes_with_the_same_path/comment_2_8cd3edf2e71e904f1b651abdfd7a4499._comment
 create mode 100644 doc/forum/Multiple_repos_on_same_path.mdwn
 create mode 100644 doc/forum/Multiple_repos_on_same_path/comment_1_67ed823c4c40f5acf12b48eb75d7afa8._comment
 create mode 100644 doc/forum/Multiple_repos_on_same_path/comment_2_e1c4ac71eb0f9ff6ae1701b3a6d738dd._comment
 create mode 100644 doc/forum/Multisession_compatible__63__.mdwn
 create mode 100644 doc/forum/Multisession_compatible__63__/comment_1_dab5a92416314a7d4c02663d4e46cd60._comment
 create mode 100644 doc/forum/Multisession_compatible__63__/comment_2_1c8d0f97d353c3e1d290edbe0a48b359._comment
 create mode 100644 doc/forum/Multisession_compatible__63__/comment_2_c1dc4294cc2a43cfecfb7279d6411924._comment
 create mode 100644 doc/forum/Multisession_compatible__63__/comment_4_b7148c3afd31ce1effd135a4f7c92dbc._comment
 create mode 100644 doc/forum/Multisession_compatible__63__/comment_5_d0ddac05268d978e950c91e76b023ffe._comment
 create mode 100644 doc/forum/Multisession_compatible__63__/comment_6_e2319f774eda62600c27ab9d2d0d1e50._comment
 create mode 100644 doc/forum/Multisession_compatible__63__/comment_7_0e6c8ab32c589f0d971d4c208a8d1645._comment
 create mode 100644 doc/forum/Must_all_nodes_be_accessible_to_one_another__63__.mdwn
 create mode 100644 doc/forum/Must_all_nodes_be_accessible_to_one_another__63__/comment_1_7af462f69b9efc3bbe18d0dbc839cb39._comment
 create mode 100644 doc/forum/Must_all_nodes_be_accessible_to_one_another__63__/comment_2_882d9e6b7b2297dfd29266bbd429b046._comment
 create mode 100644 doc/forum/My_first_impressions_after_some_weeks_with_git-annex_assistant.mdwn
 create mode 100644 doc/forum/My_first_impressions_after_some_weeks_with_git-annex_assistant/comment_1_9d4019a54fb508e286a5d6d2660361d9._comment
 create mode 100644 doc/forum/My_first_impressions_after_some_weeks_with_git-annex_assistant/comment_2_109534a45881ce94a4586c8a83945f9f._comment
 create mode 100644 doc/forum/NTFS_drive_mounted_on_Linux.mdwn
 create mode 100644 doc/forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote.mdwn
 create mode 100644 doc/forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote/comment_1_b2d2bf6be441dc2e4443d06ef8db7134._comment
 create mode 100644 doc/forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote/comment_2_75abe6da74cd0432e616e391f5be6fe3._comment
 create mode 100644 doc/forum/Need_new_build_instructions_for_Debian_stable.mdwn
 create mode 100644 doc/forum/Need_new_build_instructions_for_Debian_stable/comment_1_8c1eea6dfec8b7e1c7a371b6e9c26118._comment
 create mode 100644 doc/forum/Need_new_build_instructions_for_Debian_stable/comment_2_f6ff8306c946219dbe39bb8938a349ab._comment
 create mode 100644 doc/forum/Need_new_build_instructions_for_Debian_stable/comment_3_bcda70cbfc7c1a14fa82da70f9f876e2._comment
 create mode 100644 doc/forum/Need_some_help_installing_on_freeBSD.mdwn
 create mode 100644 doc/forum/Need_some_help_installing_on_freeBSD/comment_1_3962871e646280e2c4fdff8a08bed485._comment
 create mode 100644 doc/forum/Need_some_help_installing_on_freeBSD/comment_2_528fdd2c385809b971eceee1eb70ee38._comment
 create mode 100644 doc/forum/Need_some_help_installing_on_freeBSD/comment_3_5ae3cd6e24a25d6dc803ec2adea0414f._comment
 create mode 100644 doc/forum/Need_some_help_installing_on_freeBSD/comment_4_1dcc43aaad2099bb1684873d24da668f._comment
 create mode 100644 doc/forum/Need_some_help_installing_on_freeBSD/comment_5_527bf6df2485c5e906f1d50930ec01fe._comment
 create mode 100644 doc/forum/Need_some_help_to_fix_my_repository.mdwn
 create mode 100644 doc/forum/Need_some_help_to_fix_my_repository/comment_1_f0d279c530b796b2c93d793f85d147e8._comment
 create mode 100644 doc/forum/Need_some_help_to_fix_my_repository/comment_2_a3fcfa1f8eadec5fa8a9efacca174048._comment
 create mode 100644 doc/forum/Need_some_help_to_fix_my_repository/comment_3_7878f9b76ddfa3392c9ec6a1810cb745._comment
 create mode 100644 doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__.mdwn
 create mode 100644 doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_1_af0ed0730645c1e3c9a4946acd48c18a._comment
 create mode 100644 doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_2_12f3c2bb2458b69e6355c8f94bab868f._comment
 create mode 100644 doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_3_b233b4daac32c452776e1e3d9a29f2cc._comment
 create mode 100644 doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_4_8e079e92929dcfdf19f6adec16f800e5._comment
 create mode 100644 doc/forum/New_Arch_Linux_package_for_git-annex.mdwn
 create mode 100644 doc/forum/New_Arch_Linux_package_for_git-annex/comment_1_5881a5974ec1c4f701775c30b814ee2f._comment
 create mode 100644 doc/forum/New_Arch_Linux_package_for_git-annex/comment_2_f41f9248f4d5039309e8fd98524e86bc._comment
 create mode 100644 doc/forum/New_Arch_Linux_package_for_git-annex/comment_3_ab1f6e45625e6ab80770d4ff65ec4242._comment
 create mode 100644 doc/forum/New_external_special_remote_for_rclone.mdwn
 create mode 100644 doc/forum/New_external_special_remote_for_rclone/comment_1_8845852338bbb7e46c0d5585d5884faf._comment
 create mode 100644 doc/forum/New_external_special_remote_for_rclone/comment_2_4057e28ed32aeab048f7c97a733f180f._comment
 create mode 100644 doc/forum/New_external_special_remote_for_rclone/comment_3_4412a5a25ac933de71772afd23cd66bd._comment
 create mode 100644 doc/forum/New_external_special_remote_for_rclone/comment_4_9a23f4e9d673b4dcf60b3425fa4df4aa._comment
 create mode 100644 doc/forum/New_external_special_remote_for_rclone/comment_5_cf45b8efbb296013493e7756cdfcf291._comment
 create mode 100644 doc/forum/New_external_special_remote_for_rclone/comment_6_36a0260f013ccbd06460dea83fe22278._comment
 create mode 100644 doc/forum/New_external_special_remote_for_rclone/comment_7_4d7f07a872ef3cc2c4928dcd1580bd0a._comment
 create mode 100644 doc/forum/New_git-annex_integration_mode_for_Emacs_users.mdwn
 create mode 100644 doc/forum/New_user_misunderstandings.mdwn
 create mode 100644 doc/forum/New_user_misunderstandings/comment_1_c1785924109b5d5cde9aa3d3460cf955._comment
 create mode 100644 doc/forum/Newb_question_on_sneekernet_sync.mdwn
 create mode 100644 doc/forum/Newb_question_on_sneekernet_sync/comment_1_409cc5ba605d63331b386066d32f797b._comment
 create mode 100644 doc/forum/Newbie_question_for_a_simple_task.mdwn
 create mode 100644 doc/forum/Newbie_question_for_a_simple_task/comment_1_51cf643c8d843dd2ab49c83aaf4fd218._comment
 create mode 100644 doc/forum/Newbie_question_for_a_simple_task/comment_2_a9d18e6fb1c6b064f50467c23bc89d2e._comment
 create mode 100644 doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__.mdwn
 create mode 100644 doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_1_59158afcedac18a7285d57491b2a468a._comment
 create mode 100644 doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_2_2a70ac08bb95774415b09dab7d7f8605._comment
 create mode 100644 doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_3_92a52b523ed4c68b70ddcabc2a050b76._comment
 create mode 100644 doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_4_c52a75761ea107f6d69c09bac64f0f0a._comment
 create mode 100644 doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_5_2685e3a87464ccd37d593516d94ba5cf._comment
 create mode 100644 doc/forum/No_SSL_traffic_for_S3__63__.mdwn
 create mode 100644 doc/forum/No_SSL_traffic_for_S3__63__/comment_1_f509bf273896180e6df8c771438dd093._comment
 create mode 100644 doc/forum/No_SSL_traffic_for_S3__63__/comment_2_358635d19c82202c63014ca84de7fc3b._comment
 create mode 100644 doc/forum/No_known_copies_exist_of.mdwn
 create mode 100644 doc/forum/No_luck_getting_forgetfulness_does_not_propagate.mdwn
 create mode 100644 doc/forum/No_luck_getting_forgetfulness_does_not_propagate/comment_1_b4aaabb50743dd11b70ce0cd2b85df5e._comment
 create mode 100644 doc/forum/No_luck_getting_forgetfulness_does_not_propagate/comment_2_81c98f50953860c15473e958c55d1e4b._comment
 create mode 100644 doc/forum/No_luck_getting_forgetfulness_does_not_propagate/comment_3_350cc2d2025655804a58ed520a157c2e._comment
 create mode 100644 doc/forum/No_output_from_git-annex_status_v5.20131224-g692aa01.mdwn
 create mode 100644 doc/forum/No_output_from_git-annex_status_v5.20131224-g692aa01/comment_1_b014f1edcb7ce39da9b582683d3b80c0._comment
 create mode 100644 doc/forum/No_output_from_git-annex_status_v5.20131224-g692aa01/comment_2_24602de6cfe1f3d988c5105e7266a518._comment
 create mode 100644 doc/forum/Non-ASCII_filenames.mdwn
 create mode 100644 doc/forum/Not_enough_free_space.mdwn
 create mode 100644 doc/forum/Not_enough_free_space/comment_1_4721e6e6c263c2a624d6cc77f6575860._comment
 create mode 100644 doc/forum/Not_enough_free_space/comment_2_69e5a25b63457e702436b54d26f6d482._comment
 create mode 100644 doc/forum/Not_enough_free_space/comment_3_c6ad0934136448a014f6b1c317bba3e6._comment
 create mode 100644 doc/forum/Not_enough_free_space/comment_4_c05f95ae6d69cdc214a2b31ebc296a3b._comment
 create mode 100644 doc/forum/Not_enough_free_space/comment_5_f8206862e22fa354d97cc3d9d2af8d5c._comment
 create mode 100644 doc/forum/Not_enough_free_space/comment_6_06d27155323cf5609b17c4e1197ab9ac._comment
 create mode 100644 doc/forum/Not_enough_free_space/comment_7_7cf8cf6d15324b840336be561423d34b._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back.mdwn
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_10_ed35a6ec605e8f79ec107856af6d1a46._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_11_e48b6efa42159dc83e1be11bfb54abcd._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_12_b58232d0e3fa4649565c0c7d4ce2e82e._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_13_85368b60091dc3ce2efb58013ffe9f83._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_14_e65281bef23e0076936c508728a87897._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_1_fffb59ad5a197d2980dd0ec35cf4aafa._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_2_0cfcc2075bff556b9fde5acc3dc1d599._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_3_6fe2ff1282fb14a4ce26ef8dc775d07e._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_4_64338d2d77dcbabd16b55eb145f40dc6._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_5_dd66c9ea0c83388f6826751944330d10._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_6_dc0c5e395e4c443b7227afdb157194e5._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_7_3c0ea4c76cdd889707f7308576e3efa0._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_8_36519ee4499a19f0864e4fcd264e9933._comment
 create mode 100644 doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_9_85b23f375e53469fb09b24b945b3aba9._comment
 create mode 100644 doc/forum/OSX_Finder_extension.mdwn
 create mode 100644 doc/forum/OSX_Finder_extension/comment_1_4aa37c3fbe3c260d71f2ed16fd4f20bc._comment
 create mode 100644 doc/forum/OSX_Finder_extension/comment_2_e16092041890f81dc65a6ab28b2224a6._comment
 create mode 100644 doc/forum/OSX_Mavericks_anyone__63__.mdwn
 create mode 100644 doc/forum/OSX_Mavericks_anyone__63__/comment_1_3075b02aeb57adcbf4addf9fb4c123ba._comment
 create mode 100644 doc/forum/OSX_Mavericks_anyone__63__/comment_2_c2b6110fc4a3d3481ed8a4b48efb9635._comment
 create mode 100644 doc/forum/OSX_Mavericks_anyone__63__/comment_3_7df9ba63cb1f385681242b4b58d6a87c._comment
 create mode 100644 doc/forum/OSX_Mavericks_anyone__63__/comment_4_740fee31c4ca9d84428f97f63ffc075a._comment
 create mode 100644 doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set.mdwn
 create mode 100644 doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set/comment_1_a136ff877389f0930c066ba118edd9fd._comment
 create mode 100644 doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set/comment_2_5fcc52a62770fb932a4a2101f5badbc0._comment
 create mode 100644 doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set/comment_3_521f34c340ad54cef6458a8b6cfff8a9._comment
 create mode 100644 doc/forum/OSX__39__s_haskell-platform_statically_links_things.mdwn
 create mode 100644 doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available.mdwn
 create mode 100644 doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available/comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment
 create mode 100644 doc/forum/Odd_Hybrid_Symlinks_To_Content.mdwn
 create mode 100644 doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist.mdwn
 create mode 100644 doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist/comment_1_d43c3b97af1d9d2d4534b40a43567420._comment
 create mode 100644 doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist/comment_2_81e3664c6746fbeb2d76cca7160cf58a._comment
 create mode 100644 doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist/comment_3_d5b2b68f22796c3ecd2929f47db3601e._comment
 create mode 100644 doc/forum/One_repo_with_multiple_remotes.mdwn
 create mode 100644 doc/forum/One_repo_with_multiple_remotes/comment_1_4b9b3137396a3e830fe96726401270b8._comment
 create mode 100644 doc/forum/OpenOffice___47___Libre_Office.mdwn
 create mode 100644 doc/forum/OpenOffice___47___Libre_Office/comment_1_98ed542fedd820d47bf8deb7d3232725._comment
 create mode 100644 doc/forum/OpenOffice___47___Libre_Office/comment_2_f313fdaa23863c2ae99cfbfe9ec2e1e0._comment
 create mode 100644 doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory.mdwn
 create mode 100644 doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_1_2e89bcc3fbd069e5d9eb12c1c19993ad._comment
 create mode 100644 doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_2_cf8065e697a0a83cf3461672cb6421e0._comment
 create mode 100644 doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_3_e6bd4eb070a094116e13064dca6d5bb5._comment
 create mode 100644 doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_4_42adc29a2c3216910a3bcda04d6f6a6b._comment
 create mode 100644 doc/forum/Overwriting_data_without_getting_it.mdwn
 create mode 100644 doc/forum/Overwriting_data_without_getting_it/comment_1_f1c0199ee9bffcc84287370b89361294._comment
 create mode 100644 doc/forum/Overwriting_data_without_getting_it/comment_2_6a1d08dbca206129ef6cf8aa97daeee1._comment
 create mode 100644 doc/forum/Overwriting_data_without_getting_it/comment_3_52958e76e506fdbb6b533681ab619b3b._comment
 create mode 100644 doc/forum/PDF-related_error_when_running_git-annex-add_or_git-annex-status.mdwn
 create mode 100644 doc/forum/PDF-related_error_when_running_git-annex-add_or_git-annex-status/comment_1_4df2625cc1f1de8f164aa9500eb80e13._comment
 create mode 100644 doc/forum/Paths_changed_in_.git__47__annex__47__objects.mdwn
 create mode 100644 doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_1_e89aa61303d97bfd433e24173867723a._comment
 create mode 100644 doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_2_3e467d256ef7c2f4d469073c00cacbca._comment
 create mode 100644 doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_3_119c181afe351a412e8a13c59175ec45._comment
 create mode 100644 doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_4_0a9cec8f4e26c2e2365b54b29c91ee3d._comment
 create mode 100644 doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_5_df986910016ce53a6155edf96f4c312d._comment
 create mode 100644 doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_6_c4fe35a93ed32f7b14c5ffd5a4a8ec27._comment
 create mode 100644 doc/forum/Per_directory_numcopies.mdwn
 create mode 100644 doc/forum/Per_directory_numcopies/comment_1_33497e3a46926595920eb3dcdb58447c._comment
 create mode 100644 doc/forum/Per_directory_numcopies/comment_2_00572e3c15e5a9d253fb4ea57b45ff0d._comment
 create mode 100644 doc/forum/Performance_implications_of_triply_nested_objects_directory.mdwn
 create mode 100644 doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_1_068a8f120d188b8fa5d3e5b687fd02dc._comment
 create mode 100644 doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_2_cc0f5be21fd1523bdddc7bcf6ff04435._comment
 create mode 100644 doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_3_1133795276371c86cdd52b25a8b20c52._comment
 create mode 100644 doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_4_4e44289e6913797844e103f9cdf4c5a2._comment
 create mode 100644 doc/forum/Performance_of_V6__44___V7__44___V8_repos.mdwn
 create mode 100644 doc/forum/Performance_of_V6__44___V7__44___V8_repos/comment_1_981279bae881a07185707c29e6c58b28._comment
 create mode 100644 doc/forum/Performance_of_V6__44___V7__44___V8_repos/comment_2_01e6d32c85524a23399a33b5fb12ec06._comment
 create mode 100644 doc/forum/Performance_of_V6__44___V7__44___V8_repos/comment_3_71e8d6ed7b1a6088cdb5abb5667ee619._comment
 create mode 100644 doc/forum/Permission_denied_-_what_is_wrong__63__.mdwn
 create mode 100644 doc/forum/Permission_denied_-_what_is_wrong__63__/comment_1_b850a32cce4c9782e59fc91076b6cae7._comment
 create mode 100644 doc/forum/Permission_denied_-_what_is_wrong__63__/comment_2_e8d2170e5f830d0f98bc8251caf8bc5e._comment
 create mode 100644 doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__.mdwn
 create mode 100644 doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_1_6c74f0b43c457fe97b2d8630ca4fde29._comment
 create mode 100644 doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_2_b7a384e853e1756a684774348fad29e6._comment
 create mode 100644 doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_3_3a8a7f51cb04a92c576549d379b57248._comment
 create mode 100644 doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_4_582ad3ba0c62a77b08a10b37a780c670._comment
 create mode 100644 doc/forum/Permissions_error_with_ssh_key_authentication_to_remote.mdwn
 create mode 100644 doc/forum/Permissions_error_with_ssh_key_authentication_to_remote/comment_1_39a096f92f0280db9502397b9fc55541._comment
 create mode 100644 doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available.mdwn
 create mode 100644 doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_1_3f365138be319ac2c81bdefb3f59b0d8._comment
 create mode 100644 doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_2_0186f593ec084e12216ad2f7da49474e._comment
 create mode 100644 doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_4_0bc307a3fbe000059b23cf681d125ce6._comment
 create mode 100644 doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_4_0dc16ef1d592be0dfeb63c28014a70b2._comment
 create mode 100644 doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_5_9eb36b5b43b77de790f99ae1d764e4ea._comment
 create mode 100644 doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_6_a34d404dbecd6730c1cc28af9c0eac26._comment
 create mode 100644 doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_7_88b04371b3906f01c7b33d110838dc71._comment
 create mode 100644 doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_8_b3e9100b92aaed66b22c76141f7c08d5._comment
 create mode 100644 doc/forum/Plans_on_tunable_to_remove_sha-inside-sha_single-file-dirs.mdwn
 create mode 100644 doc/forum/Plans_on_tunable_to_remove_sha-inside-sha_single-file-dirs/comment_1_616f610876e08828e6ad6b89b9e561be._comment
 create mode 100644 doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update.mdwn
 create mode 100644 doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update/comment_1_68429f9e44ce24250c608da8ffffe643._comment
 create mode 100644 doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update/comment_2_cefd5742da29e19f5ab3406698a13f9f._comment
 create mode 100644 doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update/comment_3_ab005dba805922597a533ddd661f20c8._comment
 create mode 100644 doc/forum/Please_fix_compatibility_with_ghc_7.0.mdwn
 create mode 100644 doc/forum/Please_fix_compatibility_with_ghc_7.0/comment_1_d1d10217ebd0151e947b3a6cd37399ce._comment
 create mode 100644 doc/forum/Please_help__44___half_my_files_disappeared.mdwn
 create mode 100644 doc/forum/Please_help__44___half_my_files_disappeared/comment_1_ba7c79dd7805aa9ec1b90d643f6bf555._comment
 create mode 100644 doc/forum/Please_help_me_help_my_photographer_friends.mdwn
 create mode 100644 doc/forum/Please_publish_new_releases_not_shorter_than_11_days.mdwn
 create mode 100644 doc/forum/Please_publish_new_releases_not_shorter_than_11_days/comment_1_da3d39de5be47ebe8b25a42ed1f36510._comment
 create mode 100644 doc/forum/Podcast_syncing_use-case.mdwn
 create mode 100644 doc/forum/Podcast_syncing_use-case/comment_1_ace6f9d3a950348a3ac0ff592b62e786._comment
 create mode 100644 doc/forum/Podcast_syncing_use-case/comment_2_930a6620b4d516e69ed952f9da5371bb._comment
 create mode 100644 doc/forum/Poor_man__39__s_IMAP.mdwn
 create mode 100644 doc/forum/Poor_man__39__s_IMAP/comment_1_258ff23c462dc88b88ced405c4f5040f._comment
 create mode 100644 doc/forum/Poor_man__39__s_IMAP/comment_2_c88d1abdda4cb526a6ee45a710c75bc4._comment
 create mode 100644 doc/forum/Poor_man__39__s_IMAP/comment_3_3847e371db1c2788c075e7dca1fbd33e._comment
 create mode 100644 doc/forum/Poor_man__39__s_IMAP/comment_4_cf6cc21f2cf2aa5c949844e24a7b4075._comment
 create mode 100644 doc/forum/Poor_man__39__s_IMAP/comment_5_d861fa69475ce526841b3195be8ee356._comment
 create mode 100644 doc/forum/Poor_man__39__s_IMAP/comment_6_1e81bd4bb62652bc674cdcd7ed57ac5c._comment
 create mode 100644 doc/forum/Poor_man__39__s_IMAP/comment_7_b3929281dff6078d77f1b9ae42e25bb6._comment
 create mode 100644 doc/forum/Poor_man__39__s_IMAP/comment_8_69506e8c519196f44b9ed15b32f00106._comment
 create mode 100644 doc/forum/Portable_version_of_git-annex_for_windows.mdwn
 create mode 100644 doc/forum/Portable_version_of_git-annex_for_windows/comment_1_e5e60fa8d104a09152a8164d5a906aec._comment
 create mode 100644 doc/forum/Portable_version_of_git-annex_for_windows/comment_2_d8d1aa0920351e880ba6678bb97585de._comment
 create mode 100644 doc/forum/Possible_bug_in_setting_up_Rsync.net_remote.mdwn
 create mode 100644 doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_1_dba203d6c701365685f1a0d4269633a3._comment
 create mode 100644 doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_2_47b14e71ce0dd653a300dabe8ab0ac3a._comment
 create mode 100644 doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_3_753ff00c43be5f9bef6bcb529ad68bb9._comment
 create mode 100644 doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_4_43f04bfbaeb4f04a5980ade59a36ae91._comment
 create mode 100644 doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_5_6dd6819103814056d8b71356804be56a._comment
 create mode 100644 doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_6_b90f349f00ea283d018681505b4feaf5._comment
 create mode 100644 doc/forum/Possible_to_restore_from_an_encrypted_s3_remote__63__.mdwn
 create mode 100644 doc/forum/Possible_to_restore_from_an_encrypted_s3_remote__63__/comment_1_98033f3324bf78af886fa0f003f5eff8._comment
 create mode 100644 doc/forum/Possible_to_restore_from_an_encrypted_s3_remote__63__/comment_2_ddd6a56d583fd5b9d676365f4ebd9b68._comment
 create mode 100644 doc/forum/Post-Kickstarter.mdwn
 create mode 100644 doc/forum/Preferred_content_settings_for_sets_of_backup_drives__63__.mdwn
 create mode 100644 doc/forum/Preferred_content_settings_for_sets_of_backup_drives__63__/comment_1_54cdea3a60d61dad6332af31b2968bdd._comment
 create mode 100644 doc/forum/Preferred_content_settings_for_sets_of_backup_drives__63__/comment_2_c21e128f6bdd5408607b51c963854d4d._comment
 create mode 100644 doc/forum/Preferred_contents_based_on_presence_in_repo.mdwn
 create mode 100644 doc/forum/Preferred_contents_based_on_presence_in_repo/comment_1_2109fe43fccc6576e782a2e765eb6b50._comment
 create mode 100644 doc/forum/Preferred_contents_based_on_presence_in_repo/comment_2_f3adab92e7015245735f4bcad1d7a146._comment
 create mode 100644 doc/forum/Preferred_contents_based_on_presence_in_repo/comment_3_6aaf8226051e9dd104da206b032cfe5a._comment
 create mode 100644 doc/forum/Preferred_contents_based_on_presence_in_repo/comment_4_ffda2c94cbccab1d462a4e333816773b._comment
 create mode 100644 doc/forum/Prepare_simple_USB_backup___40__for_WAF__41__.mdwn
 create mode 100644 doc/forum/Prepare_simple_USB_backup___40__for_WAF__41__/comment_1_a02dd00950793814ea9617e0eec738ba._comment
 create mode 100644 doc/forum/Preserving_Directories_in_Metadata_Views.mdwn
 create mode 100644 doc/forum/Preserving_Directories_in_Metadata_Views/comment_1_30332d3828324455600b0b452e3b6c5a._comment
 create mode 100644 doc/forum/Preserving_Directories_in_Metadata_Views/comment_2_0decf76e18bb9fbc9b55e94f647a466d._comment
 create mode 100644 doc/forum/Preserving_extended_attributes.mdwn
 create mode 100644 doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__.mdwn
 create mode 100644 doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__/comment_1_5dd978f9b5a0771f44ab9e086bf5a07f._comment
 create mode 100644 doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__/comment_2_9f51947b35ee04e473655e20d56c740a._comment
 create mode 100644 doc/forum/Preserving_the_v5_experience.mdwn
 create mode 100644 doc/forum/Preserving_the_v5_experience/comment_1_9b188fecb7eaeb3ec3ba47f4c5e17e37._comment
 create mode 100644 doc/forum/Preserving_the_v5_experience/comment_2_d2da6d56980b535431d7f0360f58d04c._comment
 create mode 100644 doc/forum/Preserving_the_v5_experience/comment_3_b15c92675cf6a5087ced6a649dd1b6c7._comment
 create mode 100644 doc/forum/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted.mdwn
 create mode 100644 doc/forum/Preventing_annex.ignore_for_remote.mdwn
 create mode 100644 doc/forum/Preventing_annex.ignore_for_remote/comment_1_ec28f3ed75f2abad3d01a90c5b79c4b8._comment
 create mode 100644 doc/forum/Preventing_annex.ignore_for_remote/comment_2_57703f8d610aae7fadb8980e77a408b0._comment
 create mode 100644 doc/forum/Previous_versions_in_direct_mode__63__.mdwn
 create mode 100644 doc/forum/Previous_versions_in_direct_mode__63__/comment_1_352d460acd5500587e679d934180eee4._comment
 create mode 100644 doc/forum/Problem_compiling_current_master.mdwn
 create mode 100644 doc/forum/Problem_compiling_current_master/comment_1_135df61ec850c06e3b48ccfef7b5b031._comment
 create mode 100644 doc/forum/Problem_compiling_current_master/comment_2_fb3e27b6014e84bd919a7a4a95e39ef9._comment
 create mode 100644 doc/forum/Problem_compiling_current_master/comment_3_b737b3945103c5e2aa798b4e65fbce06._comment
 create mode 100644 doc/forum/Problem_compiling_current_master/comment_4_28c1b335ae388d4e1f22b711ac1c001f._comment
 create mode 100644 doc/forum/Problem_with_Anaconda_and_git-annex_on_Windows.mdwn
 create mode 100644 doc/forum/Problem_with_corrupt_SQLite_DB.mdwn
 create mode 100644 doc/forum/Problem_with_corrupt_SQLite_DB/comment_1_4e10e6d1882feba8d0c1ad058e01143c._comment
 create mode 100644 doc/forum/Problem_with_corrupt_SQLite_DB/comment_2_98020b857e5b52ebbbaaeba1313f2697._comment
 create mode 100644 doc/forum/Problem_with_corrupt_SQLite_DB/comment_3_079359513b6b9fcf0030f49df0eaf64d._comment
 create mode 100644 doc/forum/Problem_with_corrupt_SQLite_DB/comment_4_6a5f8590e6a60be5afe6bc6ffce1c94e._comment
 create mode 100644 doc/forum/Problems_syncing_with_box.com.mdwn
 create mode 100644 doc/forum/Problems_syncing_with_box.com/comment_1_8db642849da4d42cd9a43142e2b7cb70._comment
 create mode 100644 doc/forum/Problems_syncing_with_box.com/comment_2_cd18f33647aebc04af5469e4ce1fbcd2._comment
 create mode 100644 doc/forum/Problems_using_blake2_backend.mdwn
 create mode 100644 doc/forum/Problems_using_blake2_backend/comment_1_f3ffd27a9b515e867041b6cebfeeafad._comment
 create mode 100644 doc/forum/Problems_using_submodules_with_git-annex__63__.mdwn
 create mode 100644 doc/forum/Problems_using_submodules_with_git-annex__63__/comment_1_c7a927736d419d3c31c912001ff16ee4._comment
 create mode 100644 doc/forum/Problems_using_submodules_with_git-annex__63__/comment_2_26f6581b5969eb2cb77495c40de88951._comment
 create mode 100644 doc/forum/Problems_when_cloning_a_repository.mdwn
 create mode 100644 doc/forum/Problems_when_cloning_a_repository/comment_1_191c091c384d8d97d24f8a77e8ff90ee._comment
 create mode 100644 doc/forum/Problems_when_cloning_a_repository/comment_2_74ccbb09677444478074e9eab405fbaf._comment
 create mode 100644 doc/forum/Problems_when_cloning_a_repository/comment_3_3436e26dd9fe07233a070d4e95d81cdf._comment
 create mode 100644 doc/forum/Problems_with_Assistant_on_Android.mdwn
 create mode 100644 doc/forum/Problems_with_FAT_links.mdwn
 create mode 100644 doc/forum/Problems_with_FAT_links/comment_1_1628c68ef7bdaedb01fcb897a447bb91._comment
 create mode 100644 doc/forum/Problems_with_FAT_links/comment_2_734850345a66d5df38c468ffaa1182cd._comment
 create mode 100644 doc/forum/Problems_with_FAT_links/comment_3_2728cd609cb5e792d1dc722d450e4c8d._comment
 create mode 100644 doc/forum/Problems_with_FAT_links/comment_4_0a5f0239b3b6376672c8d91eaf68a460._comment
 create mode 100644 doc/forum/Problems_with_FAT_links/comment_5_3c9dd1e2586b27911422066ca71f5298._comment
 create mode 100644 doc/forum/Problems_with_large_numbers_of_files.mdwn
 create mode 100644 doc/forum/Problems_with_large_numbers_of_files/comment_1_08791cb78b982087c2a07316fe3ed46c._comment
 create mode 100644 doc/forum/Problems_with_large_numbers_of_files/comment_2_0392a11219463e40c53bae73c8188b69._comment
 create mode 100644 doc/forum/Problems_with_large_numbers_of_files/comment_3_537e9884c1488a7a4bcf131ea63b71f7._comment
 create mode 100644 doc/forum/Problems_with_large_numbers_of_files/comment_4_7cb65d013e72bd2b7e90452079d42ac9._comment
 create mode 100644 doc/forum/Problems_with_large_numbers_of_files/comment_5_86a42ee3173a5d38f803e64b79496ab3._comment
 create mode 100644 doc/forum/Problems_with_large_numbers_of_files/comment_6_4551274288383c9cc27cbf85b122d307._comment
 create mode 100644 doc/forum/Problems_with_large_numbers_of_files/comment_7_d18cf944352f8303799c86f2c0354e8e._comment
 create mode 100644 doc/forum/Propagate_changes_and_remove_adjusted_branch.mdwn
 create mode 100644 doc/forum/Propagate_changes_and_remove_adjusted_branch/comment_1_84651b939b10b84df5e685393546732e._comment
 create mode 100644 doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn
 create mode 100644 doc/forum/Pruning_out_unwanted_Git_objects.mdwn
 create mode 100644 doc/forum/Pruning_out_unwanted_Git_objects/comment_1_0cf7a12bfa2957260f4b2f79b0cadf2f._comment
 create mode 100644 doc/forum/Pruning_out_unwanted_Git_objects/comment_2_7472943c02cfe2808b0d566e06caa1a5._comment
 create mode 100644 doc/forum/Pruning_out_unwanted_Git_objects/comment_3_6a1e7a83d94394454fc085f6d2728cd7._comment
 create mode 100644 doc/forum/Pull_files_through_cloud.mdwn
 create mode 100644 doc/forum/Pull_files_through_cloud/comment_1_ae71f9876c8376ba0d0ab424bfb66e72._comment
 create mode 100644 doc/forum/Pull_files_through_cloud/comment_2_f4dfc4b212e23f7443abfb28b5613f63._comment
 create mode 100644 doc/forum/Purge_a_remote.mdwn
 create mode 100644 doc/forum/Purge_a_remote/comment_1_78b3b77f457c65d31fd8a5abf714905d._comment
 create mode 100644 doc/forum/Purge_a_remote/comment_2_dc65719157dee63b3979563ed57ee0ce._comment
 create mode 100644 doc/forum/Purge_a_remote/comment_3_63e0280273b816fa4b837724e102f813._comment
 create mode 100644 doc/forum/Purge_a_remote/comment_4_7fad1c4798ca03a4095ac3241c279f6d._comment
 create mode 100644 doc/forum/Purge_whereis.mdwn
 create mode 100644 doc/forum/Purge_whereis/comment_1_89d2446e3c9a58ab7b2a85ff941f7c8d._comment
 create mode 100644 doc/forum/Purge_whereis/comment_2_0307ce47de9b719adc2096600d94dff6._comment
 create mode 100644 doc/forum/Purge_whereis/comment_3_e87b53ebbf8053bb17caeb2aed871212._comment
 create mode 100644 doc/forum/Purge_whereis/comment_4_72b6c28d8a4865ad8c84b1f7dfefb78a._comment
 create mode 100644 doc/forum/Purge_whereis/comment_5_966e0285639a41ee9db3e9fb337e2699._comment
 create mode 100644 doc/forum/Push__47__Pull_with_the_Assistant.mdwn
 create mode 100644 doc/forum/Push__47__Pull_with_the_Assistant/comment_1_f7b63d379c2d21794adf8658f546f8a7._comment
 create mode 100644 doc/forum/Push__47__Pull_with_the_Assistant/comment_2_aec8cc20576e7ffd5a8be4348d1a0073._comment
 create mode 100644 doc/forum/Pusher_crashed__44___attempt_to_repair_hangs__44___broken_symlinks.mdwn
 create mode 100644 doc/forum/Pusher_crashed__44___attempt_to_repair_hangs__44___broken_symlinks/comment_1_c89b64b0dc7c5a760a84a9d2cfd8982c._comment
 create mode 100644 doc/forum/Pusher_crashed__44___attempt_to_repair_hangs__44___broken_symlinks/comment_2_c511691c4ea6c77e63ef85c28c921be9._comment
 create mode 100644 doc/forum/Pushing_an_existing_git_annex_repo_to_a_remote_ssh_host.mdwn
 create mode 100644 doc/forum/Pushing_an_existing_git_annex_repo_to_a_remote_ssh_host/comment_1_4008b735809161d5950b7991d69d3f68._comment
 create mode 100644 doc/forum/Pushing_git_repo_to_AWS_S3_from_behind_proxy.mdwn
 create mode 100644 doc/forum/Question__58___git-annex-only_repo___63__.mdwn
 create mode 100644 doc/forum/Question__58___git-annex-only_repo___63__/comment_10_ada27f7b8c7dc3c388e6c56ef095e682._comment
 create mode 100644 doc/forum/Question__58___git-annex-only_repo___63__/comment_11_531e6a091c8d005626e4e8290ba317d7._comment
 create mode 100644 doc/forum/Question__58___git-annex-only_repo___63__/comment_1_321632cc794c00181932f5737db9aff0._comment
 create mode 100644 doc/forum/Question__58___git-annex-only_repo___63__/comment_2_941b62a63c11caa1ada5d544c2e926ca._comment
 create mode 100644 doc/forum/Question__58___git-annex-only_repo___63__/comment_3_0c0dad1ffa11f2f8708906d310a189db._comment
 create mode 100644 doc/forum/Question__58___git-annex-only_repo___63__/comment_4_426160c2237db790b133b9c9f0abd4b2._comment
 create mode 100644 doc/forum/Question__58___git-annex-only_repo___63__/comment_5_36bd0a398b385e65df7eda26fa5c50d0._comment
 create mode 100644 doc/forum/Question__58___git-annex-only_repo___63__/comment_6_32fb6930bcaac36d00b088d8ee09face._comment
 create mode 100644 doc/forum/Question__58___git-annex-only_repo___63__/comment_7_8278ee493da14aac86e928d2349d8173._comment
 create mode 100644 doc/forum/Question__58___git-annex-only_repo___63__/comment_8_3e24c9f9042d6abdafaae45015645b11._comment
 create mode 100644 doc/forum/Question__58___git-annex-only_repo___63__/comment_9_182c66e98086dbfde29b615d0cf0e8e4._comment
 create mode 100644 doc/forum/Questions_about_borg_special_remotes.mdwn
 create mode 100644 doc/forum/Questions_about_borg_special_remotes/comment_1_bbeb30671d707f2a1d7ac0dbf342136e._comment
 create mode 100644 doc/forum/Questions_about_borg_special_remotes/comment_2_5c10ff05b8e1714aa9b413d6b01e275e._comment
 create mode 100644 doc/forum/Reappearing_repos_in_webapp_and_vicfg.mdwn
 create mode 100644 doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_1_bd977e864ae89816fa7f4ff69879b15f._comment
 create mode 100644 doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_2_05749f9e75689d0111339b7126c12300._comment
 create mode 100644 doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_3_b1531994eea0fbbf4cb097e604378a53._comment
 create mode 100644 doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_4_f1eba3e8aa4116e3c20747ec1d6e24e5._comment
 create mode 100644 doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo.mdwn
 create mode 100644 doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/comment_1_901272a6f738bfe8a0289c4900fd0c20._comment
 create mode 100644 doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/comment_2_aec1d16cb47b59dd4f2811b2956e5fdf._comment
 create mode 100644 doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/comment_3_652d9957ead7dbf4feb3ba096137d22b._comment
 create mode 100644 doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__.mdwn
 create mode 100644 doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__/comment_1_456772b5b0deb0c121d7feb5dcf41979._comment
 create mode 100644 doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__/comment_2_410f329fb47f13afc59b5b37b88a8c3a._comment
 create mode 100644 doc/forum/RecentChanges__58___link_to_the_diff__63__.mdwn
 create mode 100644 doc/forum/RecentChanges__58___link_to_the_diff__63__/comment_1_85254a327ffed22b407d25610558c15b._comment
 create mode 100644 doc/forum/Recomended_Setup_for_Syncthing_Remote.mdwn
 create mode 100644 doc/forum/Recommended_number_of_repositories.mdwn
 create mode 100644 doc/forum/Recommended_number_of_repositories/comment_1_3ef256230756be8a9679b107cdbfd018._comment
 create mode 100644 doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes.mdwn
 create mode 100644 doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_1_ec1c86e41ce3ee243df9a5008db87070._comment
 create mode 100644 doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_2_47b248b36146c5ad9986b69c8d212b4e._comment
 create mode 100644 doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_3_47951337fa2155b797b40fe19446ef51._comment
 create mode 100644 doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_4_12ae880e559bde5f75cb0c451b56b322._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck.mdwn
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_10_6d85c3ec73ddc0682d9643f4d5eeda70._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_11_52e799bb6f24a1ebed58fad6cebd3a71._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_12_686a285bc7e950aae67856c47e7cb21e._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_13_a4d62d494b340458e6535d573bade965._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_14_c10f0fe1440ccd170804a433db2267ee._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_15_14446cafac6c33a3f95b5344c42c0bef._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_16_63c19f58b7e95e39ba25a735bdcc0bcf._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_17_8e5c7572ab8d1f0e41fedf6f805b942a._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_18_e5357c63107f79571bd3ff609b4406a7._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_19_3316652073710f39965cd49ceea5c4ff._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_1_d605f755c363d56cf5f1060ad06ee173._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_2_f3ee184a4d3b8d82a8a362a6c03a54a3._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_3_341b47663d133411587ec70ef2b178c6._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_4_66c0d9284d5edbac189a64b03c4fe50a._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_5_8b32f6597f447f88bee7a80698fb4df6._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_6_4cc81169e99a453cdb6e83e57e638f37._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_7_2d104cf4682e04906f8ca0ced7288cf1._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_8_d356c4fce9f1197e5292f9dedf85bbc9._comment
 create mode 100644 doc/forum/Recover_files__44___annex_stuck/comment_9_856c7e1575f5d99530ecd54004315487._comment
 create mode 100644 doc/forum/Recover_repository_from_bup_repository.mdwn
 create mode 100644 doc/forum/Recover_repository_from_bup_repository/comment_1_6e3b1ff58fbdc10bcaca6d660eb1156f._comment
 create mode 100644 doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget.mdwn
 create mode 100644 doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget/comment_1_265563f95a8ec5918314afc7e6226b56._comment
 create mode 100644 doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget/comment_2_4da1d3f6a37b8772838bae762d4c43be._comment
 create mode 100644 doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget/comment_3_5aff48172bb767ed03e96812e4f89f38._comment
 create mode 100644 doc/forum/Recovering_deleted_file_in_direct_mode.mdwn
 create mode 100644 doc/forum/Recovering_deleted_file_in_direct_mode/comment_1_a3e6fc93669ec76656c84793d1f59149._comment
 create mode 100644 doc/forum/Recovering_deleted_file_in_direct_mode/comment_2_98c01a756c5f2dda28cffa5dd1dea385._comment
 create mode 100644 doc/forum/Recovering_from_a_cross-merge.mdwn
 create mode 100644 doc/forum/Recovery_after_freeze_while_importing_files.mdwn
 create mode 100644 doc/forum/Recovery_after_freeze_while_importing_files/comment_1_d033b77b9417468e13076ff9302f2963._comment
 create mode 100644 doc/forum/Recovery_after_freeze_while_importing_files/comment_2_e14f330de3e9ebfa9a99c32e65d59d11._comment
 create mode 100644 doc/forum/Reduce_disk_space_by_dropping_older_versions_in_local_git_annex.mdwn
 create mode 100644 doc/forum/Reduce_disk_space_by_dropping_older_versions_in_local_git_annex/comment_1_2a84bf661e0cbd5c8a558d3dbf5aef65._comment
 create mode 100644 doc/forum/Reinject_does_not_have_expected_content_of_file.mdwn
 create mode 100644 doc/forum/Reloading_.git__47__config_mid-sync.mdwn
 create mode 100644 doc/forum/Reloading_.git__47__config_mid-sync/comment_1_69e8879e0fed0e1b1589a721f9c6e3c7._comment
 create mode 100644 doc/forum/Relocating_annex_directory.mdwn
 create mode 100644 doc/forum/Relocating_annex_directory/comment_1_13ff5438baa1db110beb6aab3a783def._comment
 create mode 100644 doc/forum/Relocating_annex_directory/comment_2_6d88ff03fcf00ae872442e8a86c968ed._comment
 create mode 100644 doc/forum/Remote__39__s_git-annex-shell_not_detected.mdwn
 create mode 100644 doc/forum/Remote__39__s_git-annex-shell_not_detected/comment_1_8354782cf0fab248e607c7eae59d6bb2._comment
 create mode 100644 doc/forum/Remote__39__s_git-annex-shell_not_detected/comment_2_35e5d9b427963fc7b9618eb522bd1273._comment
 create mode 100644 doc/forum/Remote__39__s_git-annex-shell_not_detected/comment_2_7fb6168197c3f16de9775a60b7941cde._comment
 create mode 100644 doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__.mdwn
 create mode 100644 doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_1_04144280b69a7ba0cfa4fa3e1b5ef4ec._comment
 create mode 100644 doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_2_2c0340e5eac6d712045614886a8403a5._comment
 create mode 100644 doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_3_2b1ac09cb8b5f5ec62a201785c2f6531._comment
 create mode 100644 doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_4_a8e68a41e069803d89f18d1645876298._comment
 create mode 100644 doc/forum/Remote_listed_in_whereis_but_not_in_info.mdwn
 create mode 100644 doc/forum/Remote_listed_in_whereis_but_not_in_info/comment_1_85cc355213f894e8c1aeece432de67c3._comment
 create mode 100644 doc/forum/Remote_listed_in_whereis_but_not_in_info/comment_2_ddede3236f1d91ac4f0117b76267a021._comment
 create mode 100644 doc/forum/Remote_listed_in_whereis_but_not_in_info/comment_3_607d5b01eb95906391337f7351e0193c._comment
 create mode 100644 doc/forum/Remote_server_only_for_the_git_repository.mdwn
 create mode 100644 doc/forum/Remote_server_only_for_the_git_repository/comment_1_d4d8d8cfebf9a98ca8878c5684d5bb50._comment
 create mode 100644 doc/forum/Remote_server_only_for_the_git_repository/comment_2_a62dec8ab98ac7bd65059a9e425a01e2._comment
 create mode 100644 doc/forum/Remote_type_to_make_portable_HDD_like_normal_but_indexed.mdwn
 create mode 100644 doc/forum/Remote_type_to_make_portable_HDD_like_normal_but_indexed/comment_1_7caf32756f799b67b0c0588ea5e17a20._comment
 create mode 100644 doc/forum/Remote_type_to_make_portable_HDD_like_normal_but_indexed/comment_2_36c202f5883b66a431ae5e72c5ecede1._comment
 create mode 100644 doc/forum/Remove_unused_content_from_S3_special_remote.mdwn
 create mode 100644 doc/forum/Remove_unused_content_from_S3_special_remote/comment_1_acfd4eab2cd80d722479dbb410ccfe2e._comment
 create mode 100644 doc/forum/Remove_unused_content_from_S3_special_remote/comment_2_adc602d325b8639ac5bfed088c504e1e._comment
 create mode 100644 doc/forum/Remove_variants_from_all_repositories___40__and_possibly_restore_the_original_naming__41__.mdwn
 create mode 100644 doc/forum/Remove_variants_from_all_repositories___40__and_possibly_restore_the_original_naming__41__/comment_1_dfc64d8618e07177bb196d9af4474698._comment
 create mode 100644 doc/forum/Removing_files_not_found_by_git_annex_unused.mdwn
 create mode 100644 doc/forum/Removing_files_not_found_by_git_annex_unused/comment_1_420c6230e68de0a0ac7d7da91ac60801._comment
 create mode 100644 doc/forum/Removing_git-annex_repo/comment_1_58fcceb96647a8c7f33d188ae908f3bd._comment
 create mode 100644 doc/forum/Rename_local_repository_for_git-annex-info.mdwn
 create mode 100644 doc/forum/Rename_local_repository_for_git-annex-info/comment_1_6df9b666f7d948b9e03b2ecf9858f6c5._comment
 create mode 100644 doc/forum/Rename_local_repository_for_git-annex-info/comment_2_a13ef241d6d24b4abee3eedff18032a8._comment
 create mode 100644 doc/forum/Rename_local_repository_for_git-annex-info/comment_3_c75652b23bc4554d43593d1984c9c5d9._comment
 create mode 100644 doc/forum/Rename_local_repository_for_git-annex-info/comment_4_695a821eee66f8c4d4e22518edd15c40._comment
 create mode 100644 doc/forum/Repair_in_steps__63__.mdwn
 create mode 100644 doc/forum/Repair_in_steps__63__/comment_1_6a512ab2d6ea583a1913c9837e953760._comment
 create mode 100644 doc/forum/Replace_glacier-cli__63__.mdwn
 create mode 100644 doc/forum/Replace_glacier-cli__63__/comment_1_318cd0ca9f4e997161ed22fffa5d5da3._comment
 create mode 100644 doc/forum/Replace_glacier-cli__63__/comment_2_c91e393951825cdcceac845e234d7497._comment
 create mode 100644 doc/forum/Replace_glacier-cli__63__/comment_3_405aad8dd28ea035226f7fda470fde33._comment
 create mode 100644 doc/forum/Replace_glacier-cli__63__/comment_4_a863eb91006df199fcdbc98f42b2d40b._comment
 create mode 100644 doc/forum/Replace_glacier-cli__63__/comment_5_fda6c754437385afa0851e680bf17cf0._comment
 create mode 100644 doc/forum/Replace_glacier-cli__63__/comment_6_2e7b5b6cc7c2e33be36c3c510adec01c._comment
 create mode 100644 doc/forum/Replacing_a_special_remote_by_another_one.mdwn
 create mode 100644 doc/forum/RepoFS__58___File_system_view_of_Git_repositories.mdwn
 create mode 100644 doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex.mdwn
 create mode 100644 doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex/comment_1_077c492fd37d335f74a5c886ff0d524f._comment
 create mode 100644 doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex/comment_2_00e6576e3e60d2650461eeb0f918e6e5._comment
 create mode 100644 doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex/comment_3_c36a9562c53ac683b62fc4471405aa2a._comment
 create mode 100644 doc/forum/Repository_backup.mdwn
 create mode 100644 doc/forum/Repository_backup/comment_1_4d3197a1fefeb744e8b1e1b5fcf9b104._comment
 create mode 100644 doc/forum/Repository_backup/comment_2_e362221ef3d13bd417b2b6b0c51738a8._comment
 create mode 100644 doc/forum/Repository_backup/comment_3_ead30baf0a6d718569feb4002ba19b9e._comment
 create mode 100644 doc/forum/Repository_backup/comment_4_6f20653dff70aaaea4460a5efb28081f._comment
 create mode 100644 doc/forum/Repository_backup/comment_5_287510b4e8b9043fe361b7c5dc1f4e9f._comment
 create mode 100644 doc/forum/Repository_operations_stuck_suddenly.mdwn
 create mode 100644 doc/forum/Repository_operations_stuck_suddenly/comment_1_b0fa5b0e1b507e9a99e62849b1d66b7e._comment
 create mode 100644 doc/forum/Repository_operations_stuck_suddenly/comment_2_ff76dc687c2f632b39240d5e242d41f4._comment
 create mode 100644 doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__.mdwn
 create mode 100644 doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__/comment_1_8adf9c6d2a3ef29120703bfa1b8f9ae2._comment
 create mode 100644 doc/forum/Required_Content_Always_True___40____61____62___cannot_drop__41__.mdwn
 create mode 100644 doc/forum/Required_Content_Always_True___40____61____62___cannot_drop__41__/comment_1_1db8c68e8d82ed169b4687dfb5da1ba6._comment
 create mode 100644 doc/forum/Required_Content_Always_True___40____61____62___cannot_drop__41__/comment_2_ea362bb99294571f0b0e808e87b7d422._comment
 create mode 100644 doc/forum/Restoring_files__63__.mdwn
 create mode 100644 doc/forum/Restoring_files__63__/comment_1_735b98419b3ba6207cc364426b03ce74._comment
 create mode 100644 doc/forum/Restricting_SSH_+_supply_key.mdwn
 create mode 100644 doc/forum/Restricting_SSH_+_supply_key/comment_10_8bbd0b6488c23ce8b182bd6b1765c94b._comment
 create mode 100644 doc/forum/Restricting_SSH_+_supply_key/comment_11_3b946519c9f52569ce60ac04bdc3380a._comment
 create mode 100644 doc/forum/Restricting_SSH_+_supply_key/comment_1_cac35ac1ac0b300ddfac5ffc74291bce._comment
 create mode 100644 doc/forum/Restricting_SSH_+_supply_key/comment_2_e9803dd1794b4d078efa9435ff5ba295._comment
 create mode 100644 doc/forum/Restricting_SSH_+_supply_key/comment_3_1c3beb859e76cb69d2bacd2473ec72b7._comment
 create mode 100644 doc/forum/Restricting_SSH_+_supply_key/comment_4_1c541fc9a44e5cfb13c7d3ef0eeba2c7._comment
 create mode 100644 doc/forum/Restricting_SSH_+_supply_key/comment_5_4dbd5605f2638de0a3edfb3886a47938._comment
 create mode 100644 doc/forum/Restricting_SSH_+_supply_key/comment_6_a9c5b424a6acb2da152bf87b2e7617bb._comment
 create mode 100644 doc/forum/Restricting_SSH_+_supply_key/comment_7_93b7c2a5947fb6904c88cd5c120e404c._comment
 create mode 100644 doc/forum/Restricting_SSH_+_supply_key/comment_8_beaa350751eca4642545d1b83e528dd7._comment
 create mode 100644 doc/forum/Restricting_SSH_+_supply_key/comment_9_2faceeaf0d39f82e5d624eae19e4ca53._comment
 create mode 100644 doc/forum/Restricting_git-annex-shell_to_a_specific_repository.mdwn
 create mode 100644 doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_1_66544520bff71181e4a03ca583b0b458._comment
 create mode 100644 doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_2_2a210255e8535712c71fa183e56ab600._comment
 create mode 100644 doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_3_52cd4bd9694b2100b0e0dd2eafa9e828._comment
 create mode 100644 doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_4_4712a74774f60c29704d1e0f598caa78._comment
 create mode 100644 doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_5_27aa66428410cb8e77fcebccd2c6d1f4._comment
 create mode 100644 doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_6_b3a0db1c2f11770b7c6f13964f2d1784._comment
 create mode 100644 doc/forum/Retrieve_previous_version_in_direct_mode.mdwn
 create mode 100644 doc/forum/Retrieve_previous_version_in_direct_mode/comment_1_ca3a999ed64c42b8df810115de205d2f._comment
 create mode 100644 doc/forum/Retrieve_previous_version_in_direct_mode/comment_2_1292b34ff6d9976b2bd08748e1ba4e7a._comment
 create mode 100644 doc/forum/Retrieve_previous_version_in_direct_mode/comment_3_699e816c0397f6db924feeab906f1151._comment
 create mode 100644 doc/forum/Retrieve_previous_version_in_direct_mode/comment_4_d900388753de5870b7b9c0e8b8c06ed7._comment
 create mode 100644 doc/forum/Retrieve_previous_version_in_direct_mode/comment_5_1360b936aa389a0ab5e5e453824b2ece._comment
 create mode 100644 doc/forum/Reusing_existing_annex.uuid.mdwn
 create mode 100644 doc/forum/Reusing_existing_annex.uuid/comment_1_dc3d6efbf5c076bedd0c7a75ff5314bc._comment
 create mode 100644 doc/forum/Reusing_existing_annex.uuid/comment_2_cdb21c9c47c8a116e82062c9354d9339._comment
 create mode 100644 doc/forum/Reusing_existing_annex.uuid/comment_3_5544f712897e06024342aa1bdd68df1a._comment
 create mode 100644 doc/forum/Reverse_index_key_to_list_of_file_paths.mdwn
 create mode 100644 doc/forum/Reverse_index_key_to_list_of_file_paths/comment_1_acae766349a036040a03e75fa8ed34c6._comment
 create mode 100644 doc/forum/Reverse_index_key_to_list_of_file_paths/comment_2_716efb07d216d9a063bb9498c8e76ea1._comment
 create mode 100644 doc/forum/Reverse_index_key_to_list_of_file_paths/comment_3_6b75bd75623004f05f609a39e95250ab._comment
 create mode 100644 doc/forum/Reverse_index_key_to_list_of_file_paths/comment_4_e54268d93837b3b8e216ec6af074f3c6._comment
 create mode 100644 doc/forum/Reverse_index_key_to_list_of_file_paths/comment_5_022728be6cd3ac168a74d16baf29c0e1._comment
 create mode 100644 doc/forum/Revert_file_linkage_to_original_files.mdwn
 create mode 100644 doc/forum/Revert_file_linkage_to_original_files/comment_1_898ca2c9976e92d22470c7404aa9813f._comment
 create mode 100644 doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn
 create mode 100644 doc/forum/Revert_to_a_precedent_state_in_direct_mode/comment_1_1ae9f7defbab44621c3108973a4f683a._comment
 create mode 100644 doc/forum/Revert_to_a_precedent_state_in_direct_mode/comment_2_0bcfc0e89de7072bfdf1e3cdeaa16a1b._comment
 create mode 100644 doc/forum/Revert_to_a_precedent_state_in_direct_mode/comment_3_e49a37f92a3dd7d386e1e5f37ab37df4._comment
 create mode 100644 doc/forum/Revisiting_migration_and_multiple_keys.mdwn
 create mode 100644 doc/forum/Revisiting_migration_and_multiple_keys/comment_1_a85c3c7af6b1e01f887e0e1ffe2cde6f._comment
 create mode 100644 doc/forum/Revisiting_migration_and_multiple_keys/comment_2_b5545aba08c7af2f8f56caba66232c41._comment
 create mode 100644 doc/forum/Revisiting_migration_and_multiple_keys/comment_3_a712ec9b616ca45976154fd0c98ae1c4._comment
 create mode 100644 doc/forum/Revisiting_migration_and_multiple_keys/comment_4_7d367f38250a4a3454299170700d5c6c._comment
 create mode 100644 doc/forum/Revisiting_migration_and_multiple_keys/comment_5_93b85fbe5c36e986cf7c1fc87070c04c._comment
 create mode 100644 doc/forum/Revisiting_migration_and_multiple_keys/comment_6_3db8d28e13f6508e22e8488a6faaa8b2._comment
 create mode 100644 doc/forum/Robustness_on_failing_hardware.mdwn
 create mode 100644 doc/forum/Robustness_on_failing_hardware/comment_1_d89ffbebe59d05fb2c47d957792cf97e._comment
 create mode 100644 doc/forum/Running_assistant_on_a_server___40__no_X_available__41__.mdwn
 create mode 100644 doc/forum/Running_assistant_on_a_server___40__no_X_available__41__/comment_1_dd75d78ef63f2689199a302ed1846017._comment
 create mode 100644 doc/forum/Running_assistant_on_a_server___40__no_X_available__41__/comment_2_df654df60c5fa6a84d786d248928a352._comment
 create mode 100644 doc/forum/Running_assistant_steps_manually.mdwn
 create mode 100644 doc/forum/Running_assistant_steps_manually/comment_1_e14e0a1d55d01cb4f67a94bbe349b872._comment
 create mode 100644 doc/forum/Running_assistant_steps_manually/comment_2_3192f614c929b8060d4fbde56a7adec1._comment
 create mode 100644 doc/forum/Running_out_of__inodes.mdwn
 create mode 100644 doc/forum/Running_out_of__inodes/comment_1_abc73d9ad662ef642337b683bf0a0253._comment
 create mode 100644 doc/forum/Running_out_of__inodes/comment_2_30d58cb046b13d6ddd435ad0ae2f0ae1._comment
 create mode 100644 doc/forum/Running_out_of__inodes/comment_3_31926fc5c095a1d12d4005958047a3d0._comment
 create mode 100644 doc/forum/S3_Host_Question.mdwn
 create mode 100644 doc/forum/S3_Host_Question/comment_1_8c8ecea703405753e47e0da5e8325929._comment
 create mode 100644 doc/forum/S3_Host_Question/comment_2_3d6fa3147d59a5e0d10b005388b23c7a._comment
 create mode 100644 doc/forum/S3_Host_Question/comment_3_797edf3ad41561ab8960f3b28d20611e._comment
 create mode 100644 doc/forum/S3_copies__58___unsafe_to_drop_from_another_repo__63__.mdwn
 create mode 100644 doc/forum/S3_copies__58___unsafe_to_drop_from_another_repo__63__/comment_1_536a526a78a775142ad66c0689411c6a._comment
 create mode 100644 doc/forum/S3_copies__58___unsafe_to_drop_from_another_repo__63__/comment_2_48d27b557d31f25fc4b2fc7e4ef55df3._comment
 create mode 100644 doc/forum/S3_remote_not_available.mdwn
 create mode 100644 doc/forum/S3_remote_not_available/comment_1_0caf92239fb1475cf03de45f0d25291d._comment
 create mode 100644 doc/forum/S3_remote_not_available/comment_2_5895bd050237d08314e3595d93455830._comment
 create mode 100644 doc/forum/S3_remote_not_available/comment_3_b685f1d172cca4c488a517024c86ba21._comment
 create mode 100644 doc/forum/S3_remote_not_available/comment_4_ff5ce14bd27b32fc1707426f8c2a5487._comment
 create mode 100644 doc/forum/SSH_remote_transfers_queued_but_no_movement.mdwn
 create mode 100644 doc/forum/SSH_remote_transfers_queued_but_no_movement/comment_1_fea4e2317f850d6166480cddba088ae5._comment
 create mode 100644 doc/forum/Same_Jabber_account_for_different_annexes.mdwn
 create mode 100644 doc/forum/Same_Jabber_account_for_different_annexes/comment_1_90c3954fe11980eef42b5f5d34f83488._comment
 create mode 100644 doc/forum/Same_Jabber_account_for_different_annexes/comment_2_802600b3568e5f94d0550092b22975db._comment
 create mode 100644 doc/forum/Same_file_sent_to_a_webdav_remote_in_transfer_group_multiple_time_during_syncing.mdwn
 create mode 100644 doc/forum/Same_files_are_synced_over_and_over_again.mdwn
 create mode 100644 doc/forum/Same_files_are_synced_over_and_over_again/comment_1_1260b5ede5a88a95e98855363455ca41._comment
 create mode 100644 doc/forum/Searching_metadata_and_file_content__63__.mdwn
 create mode 100644 doc/forum/Searching_metadata_and_file_content__63__/comment_1_25ac180194a59b659e0b02bb95dd26aa._comment
 create mode 100644 doc/forum/Searching_metadata_and_file_content__63__/comment_2_5dd29566dacb5ca70340d54b469c40a5._comment
 create mode 100644 doc/forum/Searching_metadata_and_file_content__63__/comment_3_67715b73349dc92e9746b234024057ef._comment
 create mode 100644 doc/forum/Searching_metadata_and_file_content__63__/comment_4_b8fbd129664c9680cd77f89185974741._comment
 create mode 100644 doc/forum/Securing_a_shared_ssh_server.mdwn
 create mode 100644 doc/forum/Securing_a_shared_ssh_server/comment_1_ea971b57d94db5b8d487f728faa5e9a8._comment
 create mode 100644 doc/forum/Securing_a_shared_ssh_server/comment_2_421a19f6e1fb40db6ee205daf8e3f867._comment
 create mode 100644 doc/forum/Securing_a_shared_ssh_server/comment_3_acdbf92f646dbbf691621f08b3d94c26._comment
 create mode 100644 doc/forum/Securing_a_shared_ssh_server/comment_4_67533d08e1b8706b844262e9c483d982._comment
 create mode 100644 doc/forum/Securing_a_shared_ssh_server/comment_5_bf193e02b388b4358632a169d2425b5c._comment
 create mode 100644 doc/forum/Securing_a_shared_ssh_server/comment_6_50d391992cd444080ebc70db30b215c5._comment
 create mode 100644 doc/forum/Sending_requests_across_the_network.mdwn
 create mode 100644 doc/forum/Sending_requests_across_the_network/comment_1_8ff713d4c968705061bf2044ea0fe5a0._comment
 create mode 100644 doc/forum/Sending_requests_across_the_network/comment_2_cb29e5346a8775d87d30b18b7fc005a7._comment
 create mode 100644 doc/forum/Sending_requests_across_the_network/comment_3_9859c46db3527ad329c8e0df06edd153._comment
 create mode 100644 doc/forum/Sending_requests_across_the_network/comment_4_b228914d2a3d7838ebc8f1cae4d8b59a._comment
 create mode 100644 doc/forum/Sending_requests_across_the_network/comment_5_3dba5baa95b43f542fe3737397b8c7a8._comment
 create mode 100644 doc/forum/Sending_requests_across_the_network/comment_6_6ef44abc1c279abf315b949d2f947fa4._comment
 create mode 100644 doc/forum/Setting_required_to___34__groupwanted__34___doesn__39__t_work__44___but_copying_the_groupwanted_expression_does..mdwn
 create mode 100644 doc/forum/Setup_of_rsync_special_remote_with_non-standard_ssh_port.mdwn
 create mode 100644 doc/forum/Setup_of_rsync_special_remote_with_non-standard_ssh_port/comment_1_1eb6990e93ec92cb6fd7dbee59f31072._comment
 create mode 100644 doc/forum/Setup_of_rsync_special_remote_with_non-standard_ssh_port/comment_2_c85d5167e7ccce1ecf1de396e72ce7bc._comment
 create mode 100644 doc/forum/Several_concurrent_operations.mdwn
 create mode 100644 doc/forum/Several_concurrent_operations/comment_1_885edabc67687e727ab1a111d7d10d1f._comment
 create mode 100644 doc/forum/Several_concurrent_operations/comment_2_581e53306e47ddb826c030333f9ae9c2._comment
 create mode 100644 doc/forum/Several_concurrent_operations/comment_3_fe49537fa9e0a284705543b010e7aea9._comment
 create mode 100644 doc/forum/Several_lines_for_one_remote_in_remote.log.mdwn
 create mode 100644 doc/forum/Several_lines_for_one_remote_in_remote.log/comment_1_fdfb0099924f19fcbf334498d31f1656._comment
 create mode 100644 doc/forum/Several_lines_for_one_remote_in_remote.log/comment_2_f45a9c92de2d0271e6a427810794b0e4._comment
 create mode 100644 doc/forum/Share_only_certain_files_of_a_repo___40__Assistant__41__.mdwn
 create mode 100644 doc/forum/Share_only_certain_files_of_a_repo___40__Assistant__41__/comment_1_ec0d56cb31b918023a9184cee168b406._comment
 create mode 100644 doc/forum/Share_with_friend_copies_only_sym_links.mdwn
 create mode 100644 doc/forum/Share_with_friend_copies_only_sym_links/comment_1_a8d22dfefb219f0c9130cc294364b198._comment
 create mode 100644 doc/forum/Shared_Encryption_does_not_Work_as_Expected.mdwn
 create mode 100644 doc/forum/Shared_Encryption_does_not_Work_as_Expected/comment_1_793c71a1efcf160e1829bec3ef0b1be6._comment
 create mode 100644 doc/forum/Shared_Encryption_does_not_Work_as_Expected/comment_2_6b603265a2fc78bd2df54102bf94234f._comment
 create mode 100644 doc/forum/Shared_directory_with_non_git-annex_users.mdwn
 create mode 100644 doc/forum/Shared_directory_with_non_git-annex_users/comment_1_a56cb4993982e030eb9fd4cdb3b0c368._comment
 create mode 100644 doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex.mdwn
 create mode 100644 doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_10_d214446e2b5a95a6e14b288457e53305._comment
 create mode 100644 doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_11_d7cf8754a3e923d3f90be44ebd224d18._comment
 create mode 100644 doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_1_cf81a5c0d055875a858dd1e6a137b53c._comment
 create mode 100644 doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_2_82be119d86818f63da519fa1669d8cdd._comment
 create mode 100644 doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_3_9852ed3def9f7c73924d8be88b8581e5._comment
 create mode 100644 doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_4_cd56ee6915acb9389876b7a4b7c0e728._comment
 create mode 100644 doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_5_feda43ef61bc7676c3fd8c9308605650._comment
 create mode 100644 doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_6_da33ab62284728f832257014c351f151._comment
 create mode 100644 doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_7_eb448e997e4dc77c845bc4a9462ee128._comment
 create mode 100644 doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_8_7001fb7530f2ee1591b400195f702cd9._comment
 create mode 100644 doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_9_a27a661e8b589cffb4acad3591586433._comment
 create mode 100644 doc/forum/Shared_repository_without_git-annex_on_central_server.mdwn
 create mode 100644 doc/forum/Shared_repository_without_git-annex_on_central_server/comment_1_286c963b30eee46b261d64937cf66d06._comment
 create mode 100644 doc/forum/Shared_repository_without_git-annex_on_central_server/comment_2_d1f803b68c3789854e483da1318d043d._comment
 create mode 100644 doc/forum/Sharing_annex_with_local_clones.mdwn
 create mode 100644 doc/forum/Sharing_annex_with_local_clones/comment_1_2b60e13e5f7b8cee56cf2ddc6c47f64d._comment
 create mode 100644 doc/forum/Sharing_annex_with_local_clones/comment_2_24ff2c1eb643077daa37c01644cebcd2._comment
 create mode 100644 doc/forum/Sharing_annex_with_local_clones/comment_3_5359b8eada24d27be83214ac0ae62f23._comment
 create mode 100644 doc/forum/Sharing_annex_with_local_clones/comment_4_5c870c49d8093e1a2895224cc6e91ca0._comment
 create mode 100644 doc/forum/Sharing_annex_with_local_clones/comment_5_0bf4c0aa3258b156a3df794d5fabb6a2._comment
 create mode 100644 doc/forum/Sharing_annex_with_local_clones/comment_6_d2ebe3cc20ec8b7c778c7b22aa62896c._comment
 create mode 100644 doc/forum/Sharing_over_SMB__47__NFS_while_running_assistant__63__.mdwn
 create mode 100644 doc/forum/Should_transfer_to_a_special_remote_verify_source_content__63__.mdwn
 create mode 100644 doc/forum/Should_transfer_to_a_special_remote_verify_source_content__63__/comment_1_6de754a926c5ad0e2da6cf6a1c58ce69._comment
 create mode 100644 doc/forum/Simple_check_out_with_assistant__63__.mdwn
 create mode 100644 doc/forum/Simple_check_out_with_assistant__63__/comment_1_ade8a0743ef1ec933c8a40ed64eeac2d._comment
 create mode 100644 doc/forum/Simple_question_about_web_remote.mdwn
 create mode 100644 doc/forum/Simple_question_about_web_remote/comment_1_a732a7264b60faed29782a034c0bc592._comment
 create mode 100644 doc/forum/Simple_question_about_web_remote/comment_2_274810bdc176984c056304e17668c63b._comment
 create mode 100644 doc/forum/Simple_question_about_web_remote/comment_3_984a3b05bcc6b24430210d9ae039a026._comment
 create mode 100644 doc/forum/Simple_question_about_web_remote/comment_4_510abbb4deca924020b87f1eb7d61005._comment
 create mode 100644 doc/forum/Slightly_finer_control_over_file_whereabouts.mdwn
 create mode 100644 doc/forum/Slightly_finer_control_over_file_whereabouts/comment_10_bcb883d46a637dd1a8ef9a92733d202a._comment
 create mode 100644 doc/forum/Slightly_finer_control_over_file_whereabouts/comment_11_b7a8b9eaf114f883866fbf2be51b622f._comment
 create mode 100644 doc/forum/Slightly_finer_control_over_file_whereabouts/comment_1_6236bcfa9beba705ead3ec2141c5d835._comment
 create mode 100644 doc/forum/Slightly_finer_control_over_file_whereabouts/comment_2_ea935b37ca93e73c85d04df7c9bf6057._comment
 create mode 100644 doc/forum/Slightly_finer_control_over_file_whereabouts/comment_3_f89a8e38283ac4c8c4a3b74c413d67a1._comment
 create mode 100644 doc/forum/Slightly_finer_control_over_file_whereabouts/comment_4_07a0a754a089c46ff69dc97ea7ba9384._comment
 create mode 100644 doc/forum/Slightly_finer_control_over_file_whereabouts/comment_5_e884c001a556a0c693d1cc9a97c068ac._comment
 create mode 100644 doc/forum/Slightly_finer_control_over_file_whereabouts/comment_6_3e8674b5857e4994dfbc26be4f4b2855._comment
 create mode 100644 doc/forum/Slightly_finer_control_over_file_whereabouts/comment_7_7aeabc2e52a39423e83fbd04560e8f91._comment
 create mode 100644 doc/forum/Slightly_finer_control_over_file_whereabouts/comment_8_53b95449cfad2fe0f72d2ad642822c03._comment
 create mode 100644 doc/forum/Slightly_finer_control_over_file_whereabouts/comment_9_a17c102a45e4fc3f101a79acb8eb4081._comment
 create mode 100644 doc/forum/Slow_direct_mode_repository.mdwn
 create mode 100644 doc/forum/Slow_direct_mode_repository/comment_1_63656f103d418b35712a68f771ed559c._comment
 create mode 100644 doc/forum/Slow_transfer_speeds_on_copy_in_Windows.mdwn
 create mode 100644 doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_1_dd4ebb10ac87e3ee6158b7e7b1273a81._comment
 create mode 100644 doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_2_9ebd40fe286f6c13f1021bf360e9c48e._comment
 create mode 100644 doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_c169ad6205c998f3d44f9c0859071b2d._comment
 create mode 100644 doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_4_aee3fc6be01bb75709451eea0decf112._comment
 create mode 100644 doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_5_b1841fc129a9ce6d1c22840ee648f958._comment
 create mode 100644 doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_6_1ce9bb47dadd2b1c500b2a20fd669907._comment
 create mode 100644 doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_7_4b78b200b884c4ac7c052055b3e26784._comment
 create mode 100644 doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_8_97ef11581c5dc6eeeabb4b244bdc6c30._comment
 create mode 100644 doc/forum/So_this_is_embarrassing__59___git_export_not_working.mdwn
 create mode 100644 doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_1_70a68381641ea3369cd19e2864de753c._comment
 create mode 100644 doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_2_57ce71a398b0e2c947164e97ba8d0e2d._comment
 create mode 100644 doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_3_b7dcb0a5e69e620278d1aa4d6f5829cd._comment
 create mode 100644 doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_4_a5822d922a107e2a0e8972b7f55d92cc._comment
 create mode 100644 doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_5_edbc4191d6444dfe50f4c1d7bbab572d._comment
 create mode 100644 doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_6_b5072042bda56ad5a781aab8419ede74._comment
 create mode 100644 doc/forum/Some_files_missing_extension_in_annex.mdwn
 create mode 100644 doc/forum/Some_files_missing_extension_in_annex/comment_1_12ab578a4390c0f5896106906997de4b._comment
 create mode 100644 doc/forum/Some_files_missing_extension_in_annex/comment_2_7fa25274fb00ba823b112d587c52df76._comment
 create mode 100644 doc/forum/Some_files_missing_extension_in_annex/comment_3_b05b478e91f58bd4ccd6d8ccf3b7ddf1._comment
 create mode 100644 doc/forum/Some_mounted_devices_not_detected.mdwn
 create mode 100644 doc/forum/Some_mounted_devices_not_detected/comment_1_0ba07b95f12f57ea63bb450b88430c45._comment
 create mode 100644 doc/forum/Some_mounted_devices_not_detected/comment_2_4f8c7bcd0f20dafa5635a3580ec8d1f6._comment
 create mode 100644 doc/forum/Some_mounted_devices_not_detected/comment_3_06c0db7d670d9b82823102d22db15a36._comment
 create mode 100644 doc/forum/Some_mounted_devices_not_detected/comment_4_80820a29361c5be4a94672dacfdefa6f._comment
 create mode 100644 doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff.mdwn
 create mode 100644 doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_1_20147b287fd995fa8ac9e868b5974d8a._comment
 create mode 100644 doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_2_f6d977a534264b4368401e1b13628931._comment
 create mode 100644 doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_3_d534da276b79a40fdb7d8d158f6eae26._comment
 create mode 100644 doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment
 create mode 100644 doc/forum/Special_remote_public_key_encryption_issue.mdwn
 create mode 100644 doc/forum/Special_remote_public_key_encryption_issue/comment_1_a9caafea017a3c148f89d4ddeee15a4c._comment
 create mode 100644 doc/forum/Special_remote_public_key_encryption_issue/comment_2_adfa582d611ca501e21110282df07315._comment
 create mode 100644 doc/forum/Special_remote_public_key_encryption_issue/comment_3_eac16bf98a6e87461ba2f3ab7e990b2b._comment
 create mode 100644 doc/forum/Special_remote_public_key_encryption_issue/comment_6_097f52aaf178340b3abb5bfc80f0d447._comment
 create mode 100644 doc/forum/Special_remote_without_chmod.mdwn
 create mode 100644 doc/forum/Special_remote_without_chmod/comment_1_4f5f9506cae72a1f321296fc5a5f339a._comment
 create mode 100644 doc/forum/Special_remotes_description_misleading.mdwn
 create mode 100644 doc/forum/Special_remotes_description_misleading/comment_1_5226553dd5f529e3e4882ea18c3be600._comment
 create mode 100644 doc/forum/Special_remotes_description_misleading/comment_2_616cc2f7d729682c69a9379df785dda5._comment
 create mode 100644 doc/forum/Specifying_private_key_for_ssh_remote.mdwn
 create mode 100644 doc/forum/Specifying_private_key_for_ssh_remote/comment_1_94d38f788ab5bc34da9ba56c2fb729b5._comment
 create mode 100644 doc/forum/Speed_up_remote_transfers.mdwn
 create mode 100644 doc/forum/Speed_up_remote_transfers/comment_1_bd97e1c47338322c5232cea7cdbc26fc._comment
 create mode 100644 doc/forum/Speed_up_remote_transfers/comment_2_723b3b69d47c947e5cbe8e94b84df022._comment
 create mode 100644 doc/forum/Split_annex_into_multiple.mdwn
 create mode 100644 doc/forum/Split_annex_into_multiple/comment_1_e934b404f738cbd67df928fd6769e3ff._comment
 create mode 100644 doc/forum/Split_annex_into_multiple/comment_2_eec6bc8c49c08411a4bb2cf7cc1c4697._comment
 create mode 100644 doc/forum/Ssh_remote_on_NAS.mdwn
 create mode 100644 doc/forum/Ssh_remote_on_NAS/comment_1_1dd8a0d0e70a1fb36fce62e89c99b404._comment
 create mode 100644 doc/forum/Ssh_remote_on_NAS/comment_2_261601313d8825c52322949b8509bc74._comment
 create mode 100644 doc/forum/Ssh_remote_on_NAS/comment_3_ed602f4f972b78bce4f62bdfca8cfe47._comment
 create mode 100644 doc/forum/Ssh_remote_on_NAS/comment_4_423244f174123318f1ece7b5794aeea5._comment
 create mode 100644 doc/forum/Ssh_remote_on_NAS/comment_5_07348ed61ccdd93417365f1525a05bf2._comment
 create mode 100644 doc/forum/Ssh_remote_on_NAS/comment_6_26d444afe2edea3500f80bb5c62ba491._comment
 create mode 100644 doc/forum/Ssh_remote_on_NAS/comment_7_3c70f8b9ac2a77462c6f21929c02d9d3._comment
 create mode 100644 doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects.mdwn
 create mode 100644 doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects/comment_1_2aa80b317863a99e676a375d907d0e84._comment
 create mode 100644 doc/forum/Standard_groups__47__preferred_contents.mdwn
 create mode 100644 doc/forum/Standard_groups__47__preferred_contents/comment_1_143aa3095d7222c869c36a5039282e35._comment
 create mode 100644 doc/forum/Standard_groups__47__preferred_contents/comment_2_65bef012eb113986a2e9b02470a6cbd1._comment
 create mode 100644 doc/forum/Standard_groups__47__preferred_contents/comment_3_202a7e2820e0adf079ccd14a7993ad25._comment
 create mode 100644 doc/forum/Standard_groups__47__preferred_contents/comment_4_e0faf9ebd3162e0de860eba0fd28c67c._comment
 create mode 100644 doc/forum/Standard_groups__47__preferred_contents/comment_5_eb47696244931173bddcbeb8d5f78637._comment
 create mode 100644 doc/forum/Standard_groups__47__preferred_contents/comment_6_c70c9fa97bce8e4eb9b3880d8f843aef._comment
 create mode 100644 doc/forum/Standard_groups__47__preferred_contents/comment_7_413593ea0663874196305c9eb602e7c4._comment
 create mode 100644 doc/forum/Standards_usage_pattern__63__.mdwn
 create mode 100644 doc/forum/Standards_usage_pattern__63__/comment_1_1ccbfaefe3bbaf767e999cd1c61debfb._comment
 create mode 100644 doc/forum/Starting_assistant_from_CLI.mdwn
 create mode 100644 doc/forum/Starting_assistant_from_CLI/comment_1_afd51ddb0f1bb3cac528e1d96829ef83._comment
 create mode 100644 doc/forum/Starting_assistant_from_CLI/comment_2_76c34c00cf2065809b15a594023a688b._comment
 create mode 100644 doc/forum/Starting_assistant_from_CLI/comment_3_f7826867f78b1adbfc2dad2fad4d6720._comment
 create mode 100644 doc/forum/Starting_assistant_from_CLI/comment_4_fa7055a232a1dcb743db47308f7acf0b._comment
 create mode 100644 doc/forum/Starting_assistant_from_CLI/comment_5_8d657646080bf2b99b7792993b877502._comment
 create mode 100644 doc/forum/Steps_for_setting_up_Google_Cloud_Storage___40__GSC__41__.mdwn
 create mode 100644 doc/forum/Steps_for_setting_up_Google_Cloud_Storage___40__GSC__41__/comment_1_addbedd6ee8a534c5c4f0e639c05591c._comment
 create mode 100644 doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt.mdwn
 create mode 100644 doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt/comment_1_5a643827a1ced7c0b9bba5303f71a52c._comment
 create mode 100644 doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt/comment_2_92e1aef2ce26210b15a908e2cf729b80._comment
 create mode 100644 doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt/comment_3_12a72b294e2808b09bff6788cf2b19dd._comment
 create mode 100644 doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
 create mode 100644 doc/forum/Storing_copies_on_LTO_tapes__63__/comment_1_9ae9ca3983f7d4209fd1de65d982731d._comment
 create mode 100644 doc/forum/Storing_copies_on_LTO_tapes__63__/comment_2_6d16d00c7ef8d846e370e1b298a7bc7a._comment
 create mode 100644 doc/forum/Storing_git_repos_in_git-annex.mdwn
 create mode 100644 doc/forum/Storing_git_repos_in_git-annex/comment_1_ac7b52c0b0f75d79760ffe6a9b5c8759._comment
 create mode 100644 doc/forum/Storing_git_repos_in_git-annex/comment_3_3bec1f02ff1a61791e3cbb428c7acb4c._comment
 create mode 100644 doc/forum/Storing_git_repos_in_git-annex/comment_4_76ddbd27cc2f3785bb5aaebb0bb6e087._comment
 create mode 100644 doc/forum/Storing_git_repos_in_git-annex/comment_5_f9520cbc6669622aa342acad35581943._comment
 create mode 100644 doc/forum/Storing_git_repos_in_git-annex/comment_6_4a5ddb1980b9ba0378531a8d4fb93523._comment
 create mode 100644 doc/forum/Storing_git_repos_in_git-annex/comment_9_d5676400e7148b7d3408f2bdb3d54b7d._comment
 create mode 100644 doc/forum/Storing_uncontrolled_files_in_an_annex.mdwn
 create mode 100644 doc/forum/Storing_uncontrolled_files_in_an_annex/comment_1_175645a90be0c79221c129308adf643e._comment
 create mode 100644 doc/forum/Storing_uncontrolled_files_in_an_annex/comment_2_d29f214eadfe3bfd098bbc3bcf07129a._comment
 create mode 100644 doc/forum/Storing_uncontrolled_files_in_an_annex/comment_3_286b502e7906cca50e9e747db735bc88._comment
 create mode 100644 doc/forum/Strategy_for_dealing_with_an_old_archive_drive.mdwn
 create mode 100644 doc/forum/Strategy_for_dealing_with_an_old_archive_drive/comment_1_7405e507dd15f207445be1e5099e02f3._comment
 create mode 100644 doc/forum/Strategy_for_dealing_with_an_old_archive_drive/comment_2_bafde6d22fdb5106c2e4a519e5945072._comment
 create mode 100644 doc/forum/Structure_needs_cleaning_git-annex__58___fd__58__15__58___hGetLine__58___end_of_file.mdwn
 create mode 100644 doc/forum/Structure_needs_cleaning_git-annex__58___fd__58__15__58___hGetLine__58___end_of_file/comment_1_7bcc0111015985bde398a2a1a02b28ba._comment
 create mode 100644 doc/forum/Structure_needs_cleaning_git-annex__58___fd__58__15__58___hGetLine__58___end_of_file/comment_2_b1dfc6168bb7127312d3e06cc0939b8d._comment
 create mode 100644 doc/forum/Stuck_in_a_bad_state.mdwn
 create mode 100644 doc/forum/Stupid_mistake__58___recoverable__63__.mdwn
 create mode 100644 doc/forum/Stupid_mistake__58___recoverable__63__/comment_1_00ceb3a5e37825c4bbc806f532893706._comment
 create mode 100644 doc/forum/Stupid_mistake__58___recoverable__63__/comment_2_cbedc29678d9b6af3b3c0bb1915d2391._comment
 create mode 100644 doc/forum/Stupid_mistake__58___recoverable__63__/comment_3_86aa4d92a1330811862da1ba568b3037._comment
 create mode 100644 doc/forum/Stupid_mistake__58___recoverable__63__/comment_4_6d15bf8a3c3c27cc92957070161675a9._comment
 create mode 100644 doc/forum/Stupid_mistake__58___recoverable__63__/comment_5_f836b9b1d03d94c49e3798961790b2ba._comment
 create mode 100644 doc/forum/Submodule_.git_not_converted_to_symlink.mdwn
 create mode 100644 doc/forum/Submodule_.git_not_converted_to_symlink/comment_1_5d95da69235eb3c6b60227544380a4e8._comment
 create mode 100644 doc/forum/Submodule_.git_not_converted_to_symlink/comment_2_351c58b21d36770729c52991901d668c._comment
 create mode 100644 doc/forum/Submodule_.git_not_converted_to_symlink/comment_3_636fe0ff273cd8987168e3095929aa7f._comment
 create mode 100644 doc/forum/Suggestion__58___Put_ssh_server_back_into_android_version.mdwn
 create mode 100644 doc/forum/Suggestion__58___Put_ssh_server_back_into_android_version/comment_1_5c2f376a82458c6387560355940419d3._comment
 create mode 100644 doc/forum/Suggestion__58___Put_ssh_server_back_into_android_version/comment_2_6321dec0b2f22f841f3cb986e063113f._comment
 create mode 100644 doc/forum/Suggestion__58___downgrade_error.mdwn
 create mode 100644 doc/forum/Symantec_endpoint_protection_raises_WS.Reputation.1_on_git-annex_windows_installer.mdwn
 create mode 100644 doc/forum/Symantec_endpoint_protection_raises_WS.Reputation.1_on_git-annex_windows_installer/comment_1_3b1da8ce0dcf43efcdc9b264ef21fb3a._comment
 create mode 100644 doc/forum/Symlink_points_to_old_version.mdwn
 create mode 100644 doc/forum/Symlink_points_to_old_version/comment_1_c9c777333a01865e95332ea7ff1e6cf7._comment
 create mode 100644 doc/forum/Symlink_points_to_old_version/comment_2_9bf097d27a64743a420cba0136787165._comment
 create mode 100644 doc/forum/Sync_All_Missing_Content__63__.mdwn
 create mode 100644 doc/forum/Sync_All_Missing_Content__63__/comment_1_fbe27e8dc9dd85e860b3382f99426c14._comment
 create mode 100644 doc/forum/Sync_All_Missing_Content__63__/comment_2_d77b7f56dcb8bf384f5a19bf54fe629e._comment
 create mode 100644 doc/forum/Sync_Enabled__47__Disabled_Status.mdwn
 create mode 100644 doc/forum/Sync_Enabled__47__Disabled_Status/comment_1_cfe98bdd50cea0fd0e36a42892262084._comment
 create mode 100644 doc/forum/Sync_files_from_remote_to_remote.mdwn
 create mode 100644 doc/forum/Sync_files_from_remote_to_remote/comment_1_c5247657a5b3cd68fd55112efe97ef99._comment
 create mode 100644 doc/forum/Sync_files_from_remote_to_remote/comment_2_634e399d21271f26f7f77c15c5fb132b._comment
 create mode 100644 doc/forum/Sync_files_from_remote_to_remote/comment_3_b89701582b40e2c337a1a49733877210._comment
 create mode 100644 doc/forum/Sync_files_from_remote_to_remote/comment_4_b3ad93e032c3c9d2312970711540bf92._comment
 create mode 100644 doc/forum/Sync_files_from_remote_to_remote/comment_5_bdf293d30692311983d0586231535bd4._comment
 create mode 100644 doc/forum/Sync_files_from_remote_to_remote/comment_6_fda62d735035213f2a0b5b2fc95991ab._comment
 create mode 100644 doc/forum/Sync_files_from_remote_to_remote/comment_7_77c6550397435e9601fbae467be90976._comment
 create mode 100644 doc/forum/Sync_files_from_remote_to_remote/comment_8_4d3c05acc310a21f6c8ab77fb2638a8c._comment
 create mode 100644 doc/forum/Sync_files_via_remote_server.mdwn
 create mode 100644 doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__.mdwn
 create mode 100644 doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__/comment_1_68e73ffa29338214fa030c5f0e2823c6._comment
 create mode 100644 doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__/comment_3_3d57de3c12527e5a4b30ff7982ae749d._comment
 create mode 100644 doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__/comment_3_94b40e68418f732322c9a01418688165._comment
 create mode 100644 doc/forum/Sync_only_what_is_not_available_from_my_central_git_repo.mdwn
 create mode 100644 doc/forum/Sync_only_what_is_not_available_from_my_central_git_repo/comment_1_b31d02c97447996495de73705ac39f71._comment
 create mode 100644 doc/forum/Sync_only_what_is_not_available_from_my_central_git_repo/comment_2_098465ae8af32931779d2cd63750d5dc._comment
 create mode 100644 doc/forum/Sync_with_one_offline_peer.mdwn
 create mode 100644 doc/forum/Sync_with_one_offline_peer/comment_1_3859d842d4f7e2ef44877b05ebe881fb._comment
 create mode 100644 doc/forum/Sync_with_one_offline_peer/comment_2_c9ba3983b37b0c1868269616fd81e518._comment
 create mode 100644 doc/forum/Sync_with_one_offline_peer/comment_3_28b9c003b4560c3ce90c9ebf808b091b._comment
 create mode 100644 doc/forum/Sync_without_jabber_account.mdwn
 create mode 100644 doc/forum/Sync_without_jabber_account/comment_1_3e95ac2e67451f953cf0538094109f8b._comment
 create mode 100644 doc/forum/Synchronize_large_files___40__VM_images__41__.mdwn
 create mode 100644 doc/forum/Synchronize_large_files___40__VM_images__41__/comment_1_619f6ed2d7da5832ab253d61b6dd8044._comment
 create mode 100644 doc/forum/Synchronize_large_files___40__VM_images__41__/comment_2_bbd98d0b5d77dc7efc55ef8c2a18d612._comment
 create mode 100644 doc/forum/Synchronize_large_files___40__VM_images__41__/comment_3_6488bbe6f39e7154f950530498e9b548._comment
 create mode 100644 doc/forum/Synchronize_two_latops_with_a_ssh_remote.mdwn
 create mode 100644 doc/forum/Syncing_Compressed_files.mdwn
 create mode 100644 doc/forum/Syncing_Compressed_files/comment_1_e44598cd735830a8df9a29e0031d34f1._comment
 create mode 100644 doc/forum/Syncing_Compressed_files/comment_2_db1ea446ae9720fe1651c56da38e7088._comment
 create mode 100644 doc/forum/Syncing_Compressed_files/comment_3_885c045c8ddfccbd426a6bc1bc053435._comment
 create mode 100644 doc/forum/Syncing_Compressed_files/comment_4_d619d9b7ad4ca3f2fa9505ea928d5bf7._comment
 create mode 100644 doc/forum/Syncing_Compressed_files/comment_5_0c7af752cc35013273a07a5fa1f71f6e._comment
 create mode 100644 doc/forum/Syncing_machines_on_different_networks.mdwn
 create mode 100644 doc/forum/Syncing_machines_on_different_networks/comment_1_1c3523c722c178a96b096a68b9be4165._comment
 create mode 100644 doc/forum/Syncing_machines_on_different_networks/comment_2_d7b14ffee65072329cfe9ab08a0dba50._comment
 create mode 100644 doc/forum/Syncing_machines_on_different_networks/comment_3_65d1dae9b76fccb5f2b8fd8c69b60075._comment
 create mode 100644 doc/forum/Syncing_machines_on_different_networks/comment_4_2ec67428af69d6c0ea051c6a67d58905._comment
 create mode 100644 doc/forum/Syncing_machines_on_different_networks/comment_5_5ce093f82a2aad3fd8d7ccd5fdcab94f._comment
 create mode 100644 doc/forum/Syncing_machines_on_different_networks/comment_6_a55982c28d7b90e0b70ec2bb5e594e08._comment
 create mode 100644 doc/forum/Syncing_machines_on_different_networks/comment_7_c519d546e1a2a4e834609f3de3a605b0._comment
 create mode 100644 doc/forum/Syncing_machines_on_different_networks/comment_8_84a822238ddbaf211cce5f527c3559d3._comment
 create mode 100644 doc/forum/Syncing_with___39__include__39___rule_for_duplicate_files.mdwn
 create mode 100644 doc/forum/Syncing_with___39__include__39___rule_for_duplicate_files/comment_1_5d776e90c24c4eed14ae01c6019c76b8._comment
 create mode 100644 doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__.mdwn
 create mode 100644 doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_1_cd55d06a4065b9d3f14d50674c3fcaf7._comment
 create mode 100644 doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_2_25cbdf478091af9923090e049c432a7d._comment
 create mode 100644 doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_3_7e71d355457d6b1a0391d4cdae6895e6._comment
 create mode 100644 doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_4_a73f67f2fcf0762fbd7c8366b3844af6._comment
 create mode 100644 doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__.mdwn
 create mode 100644 doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__/comment_1_ca5192a26950627a1c2efcb55d6d2fa3._comment
 create mode 100644 doc/forum/Termux_Android_8.1_Proot_Error.mdwn
 create mode 100644 doc/forum/Termux_Android_8.1_Proot_Error/comment_1_1ef5f1b83e1bc0061d9fb1bba601a692._comment
 create mode 100644 doc/forum/Thank_you.mdwn
 create mode 100644 doc/forum/Thank_you/comment_1_3be1d5e92c3abc222713c75169b43dfb._comment
 create mode 100644 doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__.mdwn
 create mode 100644 doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_1_3cbe520b184d323219cb402ff046c3b4._comment
 create mode 100644 doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_2_6afe7f593e955db2eefe87d9fa01882b._comment
 create mode 100644 doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_3_209399487fc4f76b29f03ad82dbc2d6f._comment
 create mode 100644 doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_4_f33fd6f72cb9ad7dd20a04c82199413b._comment
 create mode 100644 doc/forum/The_future_of_Direct_Mode.mdwn
 create mode 100644 doc/forum/The_future_of_Direct_Mode/comment_1_f16f6e41f01d59ccef9666a2ec46d294._comment
 create mode 100644 doc/forum/The_future_of_Direct_Mode/comment_2_c7408d45d0a2a854020e4169fe757d51._comment
 create mode 100644 doc/forum/This_account_is_restricted_by_rssh._Allowed_commands__58___scp_rsync__160__.mdwn
 create mode 100644 doc/forum/This_account_is_restricted_by_rssh._Allowed_commands__58___scp_rsync__160__/comment_1_68e911629da672473bd6188407a68be2._comment
 create mode 100644 doc/forum/Thoughts_on_glacier_remotes_for_archive_purposes.mdwn
 create mode 100644 doc/forum/Thoughts_on_glacier_remotes_for_archive_purposes/comment_1_c874e49e668baa1fed293318cef88dd0._comment
 create mode 100644 doc/forum/Thoughts_on_glacier_remotes_for_archive_purposes/comment_2_28926e01b82de55352702182730a6b4b._comment
 create mode 100644 doc/forum/Time_for_another_user_survey__63__.mdwn
 create mode 100644 doc/forum/Time_for_another_user_survey__63__/comment_1_e746e11d30049906758a015059658e16._comment
 create mode 100644 doc/forum/Timeline_of_git_reinject__63__.mdwn
 create mode 100644 doc/forum/Timeline_of_git_reinject__63__/comment_1_e88d612590d3cd0c2ea824c1e8a38678._comment
 create mode 100644 doc/forum/Timeout_sync_faster__63__.mdwn
 create mode 100644 doc/forum/Timeout_sync_faster__63__/comment_1_eb4c13c1ad9803f402215478c0baab2b._comment
 create mode 100644 doc/forum/Timeout_sync_faster__63__/comment_2_16d655b754d2d512c2b01bac8276f31c._comment
 create mode 100644 doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories.mdwn
 create mode 100644 doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_1_9fc3f6c2f7379755e0084a850fa9acd4._comment
 create mode 100644 doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_2_f024d6a105143af1e06aafe49661ee06._comment
 create mode 100644 doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_3_aff0093c38bda8b093f05e8cbe8775e9._comment
 create mode 100644 doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_4_c889050d3079edefc4633451bd5baff8._comment
 create mode 100644 doc/forum/Transfer_remotes.mdwn
 create mode 100644 doc/forum/Transfer_remotes/comment_1_c08cf3bda00d7f20a3ca3d0fdba19c9c._comment
 create mode 100644 doc/forum/Transfer_remotes/comment_2_98930629d398329f1161135464a966a5._comment
 create mode 100644 doc/forum/Transparent_compression_of_files.mdwn
 create mode 100644 doc/forum/Transparent_compression_of_files/comment_1_7242325defa000572ca8e78e29012451._comment
 create mode 100644 doc/forum/Transparent_compression_of_files/comment_2_a75e32b0825de0b405c45de14b9711c0._comment
 create mode 100644 doc/forum/Transparent_compression_of_files/comment_3_a876239d4a2fe96f2e2fe1c16e7f202b._comment
 create mode 100644 doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows.mdwn
 create mode 100644 doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_1_0055392bfead0dd1d9dc1a196a6e5269._comment
 create mode 100644 doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_2_3ec8af32b8148d31aaa3ba781b4dcf89._comment
 create mode 100644 doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_3_8ddec87534a9025c26394fecd5456b84._comment
 create mode 100644 doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_4_9c12c508f62f2e76d09f4ed15af9c74e._comment
 create mode 100644 doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_5_b496f6938bd463de501eaa5c1850ce5c._comment
 create mode 100644 doc/forum/Trouble_installing_from_cabal_on_debian-testing.mdwn
 create mode 100644 doc/forum/Trouble_installing_from_cabal_on_debian-testing/comment_1_0d3e9d7cffafc34bc212557e8bbb987d._comment
 create mode 100644 doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site.mdwn
 create mode 100644 doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site/comment_1_34a858688c46faf624fa7d98b05e6519._comment
 create mode 100644 doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site/comment_2_409103144cf803ced9d81d3380ca76fb._comment
 create mode 100644 doc/forum/Truly_purging_dead_repositories.mdwn
 create mode 100644 doc/forum/Truly_purging_dead_repositories/comment_1_a4c75d49714b3543a9f1617a15d4a2d1._comment
 create mode 100644 doc/forum/Truly_purging_dead_repositories/comment_2_3da60a02e7323a204c5c5dd02ba04d6c._comment
 create mode 100644 doc/forum/Truly_purging_dead_repositories/comment_3_2576e45436008ff5a7ae5a38cade658e._comment
 create mode 100644 doc/forum/Truly_purging_dead_repositories/comment_4_477e3c213c5a5d4a33afd42a5b94c718._comment
 create mode 100644 doc/forum/Trying_to_delete_an_S3_repo_fails.mdwn
 create mode 100644 doc/forum/Trying_to_delete_an_S3_repo_fails/comment_1_d8ab7757cd224439d55a18bfec405772._comment
 create mode 100644 doc/forum/Trying_to_delete_an_S3_repo_fails/comment_2_94653e0c2c9e3e3be45c383442c7ec9b._comment
 create mode 100644 doc/forum/Trying_to_setup_2_full_backup_repos_that_sync_with_eachother.mdwn
 create mode 100644 doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback.mdwn
 create mode 100644 doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_1_86a86f1f3ea2e778e4022689391b887b._comment
 create mode 100644 doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_2_77d61eceec24d2f41f044a643d8542cc._comment
 create mode 100644 doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_3_529cada8df4888c12254818c26231835._comment
 create mode 100644 doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_4_1561613ff2f0f3d7b42159d09ae1c7f7._comment
 create mode 100644 doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_5_59991756981681648070d03e2277ccbb._comment
 create mode 100644 doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_6_eeafd62249d44b89d1091f0be79b3086._comment
 create mode 100644 doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_7_24a20071d43ded3be9c4c68a637ca4f5._comment
 create mode 100644 doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_8_8ad6bd5fce8f9bc1622f225c162ae167._comment
 create mode 100644 doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_9_6406fcf0021ac8266b4f2ef850be0fa0._comment
 create mode 100644 doc/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__.mdwn
 create mode 100644 doc/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__/comment_1_b8702892280447193e6e80be22a580a0._comment
 create mode 100644 doc/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__/comment_2_50cafde7e30b928480d1f142ddd763d2._comment
 create mode 100644 doc/forum/Two_computers__44___one_networked_repository__44___no_Jabber_-_how_to_setup_sync__63___.mdwn
 create mode 100644 doc/forum/Two_computers__44___one_networked_repository__44___no_Jabber_-_how_to_setup_sync__63___/comment_1_b90aef011d853ad9feb6f8edc08bf7d9._comment
 create mode 100644 doc/forum/USB_backup_with_files_visible.mdwn
 create mode 100644 doc/forum/USB_backup_with_files_visible/comment_10_b90b18ca57f9299f1920254bb2aa699b._comment
 create mode 100644 doc/forum/USB_backup_with_files_visible/comment_1_2832f8ae24dfb0f101e06f7c18283028._comment
 create mode 100644 doc/forum/USB_backup_with_files_visible/comment_2_6163e01aa441f8435091f026cc6da337._comment
 create mode 100644 doc/forum/USB_backup_with_files_visible/comment_3_ee92ff320eb5d9a031bdd1896aee0d86._comment
 create mode 100644 doc/forum/USB_backup_with_files_visible/comment_4_437c8342c0b65e3a89129800313eb73c._comment
 create mode 100644 doc/forum/USB_backup_with_files_visible/comment_5_5e10cffe8465ea4ecaa71c03a4c29ea4._comment
 create mode 100644 doc/forum/USB_backup_with_files_visible/comment_6_add048a16837f7940a859f21426cdbe9._comment
 create mode 100644 doc/forum/USB_backup_with_files_visible/comment_7_de227ca9911fe57d7a6d3e037f574fe9._comment
 create mode 100644 doc/forum/USB_backup_with_files_visible/comment_8_0c0ed0e038f7f0e2d2d4ed69b7b29fbc._comment
 create mode 100644 doc/forum/USB_backup_with_files_visible/comment_9_dfb830fb00c10b797c3d26179e6dfefd._comment
 create mode 100644 doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant.mdwn
 create mode 100644 doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_1_0a6f6054d70009979f4a036e24b7c500._comment
 create mode 100644 doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_2_f9eef3019fe690e90c1228d62a16f70a._comment
 create mode 100644 doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_3_7fb74f7fab6c1baff4ffc270cf15ef0a._comment
 create mode 100644 doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_4_5925b609aff0954f2860269cff107284._comment
 create mode 100644 doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_5_45062d5776f8aefb0850d70f2a517c75._comment
 create mode 100644 doc/forum/Ubuntu_PPA.mdwn
 create mode 100644 doc/forum/Ubuntu_PPA/comment_1_b55535258b1b4bcfc802235f0cba075d._comment
 create mode 100644 doc/forum/Ubuntu_PPA/comment_2_adc4d644fed058d1811acf0b35db9c18._comment
 create mode 100644 doc/forum/Ubuntu_PPA/comment_3_fc9cd51558c47718f243437202a11803._comment
 create mode 100644 doc/forum/Ubuntu_PPA/comment_4_3a8bbd0a7450a7f5323cd13144824aea._comment
 create mode 100644 doc/forum/Ubuntu_PPA/comment_5_2e1beaeebda0201c635db8b276cedf20._comment
 create mode 100644 doc/forum/Ubuntu_PPA/comment_6_bd99fb70399fc58d98781a89c6d38428._comment
 create mode 100644 doc/forum/Ubuntu_PPA/comment_7_c3f7ec8573934c59d70a48e36e321c13._comment
 create mode 100644 doc/forum/Ubuntu_PPA/comment_8_feecd478a4d44cb5ffc7020c646174ba._comment
 create mode 100644 doc/forum/Un-git-annex__63__.mdwn
 create mode 100644 doc/forum/Un-git-annex__63__/comment_1_6059265afb66190d325083e0f28bcf33._comment
 create mode 100644 doc/forum/Un-git-annex__63__/comment_2_fac4bfb81dbbf0dc82059aace261eb51._comment
 create mode 100644 doc/forum/Unable_to_change_RSS_feeds.mdwn
 create mode 100644 doc/forum/Unable_to_change_RSS_feeds/comment_1_9f6517f3c6dc8cd4e27d0011efcf2bb5._comment
 create mode 100644 doc/forum/Unable_to_change_RSS_feeds/comment_2_9ed0f746a199bb0ce474b2e9fa4f0a9e._comment
 create mode 100644 doc/forum/Understanding___34__deletion__34___and___34__dropping__34_____38___cleanup_of_history.mdwn
 create mode 100644 doc/forum/Understanding___34__deletion__34___and___34__dropping__34_____38___cleanup_of_history/comment_1_08dbad67df1d8f07d3883c6fed2fe0c4._comment
 create mode 100644 doc/forum/Undo_Git_Annex_Changes_To_Linked_Files.mdwn
 create mode 100644 doc/forum/Undo_Git_Annex_Changes_To_Linked_Files/comment_1_568dde820c2608d86d05b07444146a26._comment
 create mode 100644 doc/forum/Undo_Git_Annex_Changes_To_Linked_Files/comment_2_a8cf71cdf1217d9c8596cd9006eb83f5._comment
 create mode 100644 doc/forum/Undo_git_merge_git-annex.mdwn
 create mode 100644 doc/forum/Undo_git_merge_git-annex/comment_1_0b15f7a8c3bca87dcbf748a229e13a4b._comment
 create mode 100644 doc/forum/Undo_git_merge_git-annex/comment_2_c5a8839c53145a3b0d44950096c5180f._comment
 create mode 100644 doc/forum/Unknown_remote_type_S3.mdwn
 create mode 100644 doc/forum/Unknown_remote_type_S3/comment_1_2aea2cd51286c809427d16519606cd37._comment
 create mode 100644 doc/forum/Unknown_remote_type_S3/comment_2_06f775062cd30767979fe56bcb3cf7bf._comment
 create mode 100644 doc/forum/Unlock_files_when_assistant_is_running__63__.mdwn
 create mode 100644 doc/forum/Unlock_files_when_assistant_is_running__63__/comment_1_3f4aadf0c856c81e15c6f5ae7f1992b4._comment
 create mode 100644 doc/forum/Unlock_files_when_assistant_is_running__63__/comment_2_a76797ee9e05e43af7947508cadd7bed._comment
 create mode 100644 doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked.mdwn
 create mode 100644 doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_1_cd08064d171bea606df1cb7dafbdd381._comment
 create mode 100644 doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_2_6da3347c2d9243a9fe61fd75999d6f36._comment
 create mode 100644 doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_3_78dfedd93393709d3d7e417b779109d4._comment
 create mode 100644 doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_4_bdd6cb9cdf2366e5d930c0cdd80b3984._comment
 create mode 100644 doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_5_7a2109bbe16de4c05db48763d00bfaf1._comment
 create mode 100644 doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_6_9ed97ec6e540f2b795bf5bc11fcfdc90._comment
 create mode 100644 doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_7_c6f1dd606d2aa9aa473cdd3a6d92bd33._comment
 create mode 100644 doc/forum/Unlocked_files_confusion.mdwn
 create mode 100644 doc/forum/Unlocked_files_confusion/comment_1_6442aa304b4d44bfc6bc038f4b55f37a._comment
 create mode 100644 doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__.mdwn
 create mode 100644 doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_1_d35829cd466139e0e77a79c251a79ad8._comment
 create mode 100644 doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_2_07861ab33ec31659ec3cfa8520580fd4._comment
 create mode 100644 doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_3_ce7ff5d0ea390649af64a296fecf9113._comment
 create mode 100644 doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_4_b7eead64e39b5ebb1a22131b4e35251e._comment
 create mode 100644 doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_5_97fd65626991b1e8012e15595941d25d._comment
 create mode 100644 doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_6_f2572320e3cc93c7dd6db51e78f31c10._comment
 create mode 100644 doc/forum/Unlocking_files_gives_symlink_content.mdwn
 create mode 100644 doc/forum/Unlocking_files_gives_symlink_content/comment_1_f8032a5ea72f2cd833a626a197f94ba2._comment
 create mode 100644 doc/forum/Unlocking_files_gives_symlink_content/comment_2_f50b8ef54737798183490d5a660248f2._comment
 create mode 100644 doc/forum/Unlocking_files_gives_symlink_content/comment_3_29e467b112a94736147708c6892dae9c._comment
 create mode 100644 doc/forum/Update_on_remote_repo.mdwn
 create mode 100644 doc/forum/Update_on_remote_repo/comment_1_d58cfe914d6c36d8bff8d1342e1c2102._comment
 create mode 100644 doc/forum/Updating_a_podcast_episode_checksum.mdwn
 create mode 100644 doc/forum/Updating_a_podcast_episode_checksum/comment_1_8a4c7119f55dba5ff3cb858dbc96f1a5._comment
 create mode 100644 doc/forum/Updating_repository_permissions.mdwn
 create mode 100644 doc/forum/Upspin.mdwn
 create mode 100644 doc/forum/Upspin/comment_1_30adffff50a043c14b765ebdc6d637d2._comment
 create mode 100644 doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster.mdwn
 create mode 100644 doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_10_55d285c796f04049e26b6810c7c879ad._comment
 create mode 100644 doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_11_7c7c0b3442902dbe0b9f875e0f1b634a._comment
 create mode 100644 doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_1_bc5ffcf6d3b72c1ed7b7763549880560._comment
 create mode 100644 doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_2_3bd66bf73386821c3837fe9da841fd1e._comment
 create mode 100644 doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_3_a5bd659bc98d6879b5175dc53915fdc8._comment
 create mode 100644 doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_4_9ec91c1eb9fe119c52831a4ce5c44e25._comment
 create mode 100644 doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_5_bc7a29f8da461439cfb3cb270403181b._comment
 create mode 100644 doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_6_4c8eb6c893ccd0a075500f4b9d4bccd9._comment
 create mode 100644 doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_7_12f6a1b93c36095f12e2a721311dee2a._comment
 create mode 100644 doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_8_83228ff27a74b575b77f0e380e13cc8a._comment
 create mode 100644 doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_9_23ae2824d52b1f165b02294b0f89d704._comment
 create mode 100644 doc/forum/Use_assistant_to_sync_just_git_repos__63__.mdwn
 create mode 100644 doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_1_d487c7097db97e316f086742e851b01f._comment
 create mode 100644 doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_2_f0bb3c9461a6b84ca034ebfff814dc77._comment
 create mode 100644 doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_3_809b8a20c4de0da47e3f6bf794043744._comment
 create mode 100644 doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_4_fc4f3e2692c98e8168c8cbc696726f98._comment
 create mode 100644 doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_5_e9d1f0a0b10a16079f06b63251806b0e._comment
 create mode 100644 doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_6_0bd5e37ad9428eb38d2fdb84e58a0c2a._comment
 create mode 100644 doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_7_4ba1e89d84fedfd6508f37717310893d._comment
 create mode 100644 doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_8_d57eb0b4d41600a6709c03f00a9091be._comment
 create mode 100644 doc/forum/Use_case__58___Main_machine__44___portable_drive__44___backup_machine.mdwn
 create mode 100644 doc/forum/Use_case__58___Main_machine__44___portable_drive__44___backup_machine/comment_1_d2991b94eb067f0a6e47cd77f922411d._comment
 create mode 100644 doc/forum/Use_case__58___Main_machine__44___portable_drive__44___backup_machine/comment_2_0b778710b23eab1413256e289f0aa180._comment
 create mode 100644 doc/forum/Use_case__58___backup_on_multiple_USB_Drives.mdwn
 create mode 100644 doc/forum/Use_case__58___backup_on_multiple_USB_Drives/comment_1_5d45ee72f91af9ec8384b178af77bc2d._comment
 create mode 100644 doc/forum/Use_case__58___backup_on_multiple_USB_Drives/comment_2_502fedae83c3b6e0b32897ce4c1a8317._comment
 create mode 100644 doc/forum/Use_case_for_addurl.mdwn
 create mode 100644 doc/forum/Use_case_for_addurl/comment_1_2205b1857158cca4f6e2225c53bec1d5._comment
 create mode 100644 doc/forum/Use_case_with_syncing_only_a_subset_possible__63__.mdwn
 create mode 100644 doc/forum/Use_case_with_syncing_only_a_subset_possible__63__/comment_1_a0a272a0931b27e5c94b93e42656b62c._comment
 create mode 100644 doc/forum/Use_existing_S3_bucket.mdwn
 create mode 100644 doc/forum/Use_existing_S3_bucket/comment_1_ed0ead0b09ddbe52d42150a281d84f5c._comment
 create mode 100644 doc/forum/Use_existing_S3_bucket/comment_2_6b108846fca4a514d507f56d1052fdde._comment
 create mode 100644 doc/forum/Use_local_files_instead_of_re-downloading_from_S3_remote.mdwn
 create mode 100644 doc/forum/Use_local_files_instead_of_re-downloading_from_S3_remote/comment_1_cfb6021a36eee087705967a69967f327._comment
 create mode 100644 doc/forum/Use_local_files_instead_of_re-downloading_from_S3_remote/comment_2_7268b194ba72331858bc3274996b780e._comment
 create mode 100644 doc/forum/Use_on_large_media_collection_without_modifying_it.mdwn
 create mode 100644 doc/forum/Use_on_large_media_collection_without_modifying_it/comment_1_76307d95cf46992fbc5f084f9c056edc._comment
 create mode 100644 doc/forum/Use_on_large_media_collection_without_modifying_it/comment_2_b89b598844b0709a5b6709d0fb2ef60c._comment
 create mode 100644 doc/forum/Use_on_large_media_collection_without_modifying_it/comment_3_2d707dc516dad666fb2a647f65fcedcf._comment
 create mode 100644 doc/forum/Use_on_large_media_collection_without_modifying_it/comment_4_4529364f2919bd05f53da94cf8ba4268._comment
 create mode 100644 doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__.mdwn
 create mode 100644 doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_1_b177f16daeab7f02022f18154cfa1c3c._comment
 create mode 100644 doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_2_6d88e5a48de78e6add0e4e4b6ebc3f1b._comment
 create mode 100644 doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_3_a2eb4244788eebba5167cd32a73ff204._comment
 create mode 100644 doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__.mdwn
 create mode 100644 doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_1_85806316ed28d7a891f04fab4027141b._comment
 create mode 100644 doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_2_ecb411a2c4d67917b734a90bd460d44b._comment
 create mode 100644 doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_3_83dc719be1883d5369d27a787a5b5705._comment
 create mode 100644 doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_4_bbe2e6359f7b754bde9d61b5a8d5e672._comment
 create mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too.mdwn
 create mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_1_30205c1ba18e5dca2314f593e1a0e236._comment
 create mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_2_f8df728de28218a6b060ae9f08adac79._comment
 create mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_3_ba438b3a371261ee841665f1ae57eba2._comment
 create mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_4_9f72e6c7c14a77330297526aef260762._comment
 create mode 100644 doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment
 create mode 100644 doc/forum/User_name_with_whitespace_not_working_with___34____40__+__41___Local_computer__34__.mdwn
 create mode 100644 doc/forum/User_name_with_whitespace_not_working_with___34____40__+__41___Local_computer__34__/comment_1_f803fc1fb340587fc4b55640fbae6604._comment
 create mode 100644 doc/forum/Using_Git-Annex___40__Assistant__41___to_manage_photos_with_Shotwell.mdwn
 create mode 100644 doc/forum/Using_Git-Annex___40__Assistant__41___to_manage_photos_with_Shotwell/comment_1_5e8d54daf6b7ff357619ac65fe39a2d7._comment
 create mode 100644 doc/forum/Using_Linux_static_builds.mdwn
 create mode 100644 doc/forum/Using_Linux_static_builds/comment_1_22fd266cbe68af3e754a10f1f1295e9b._comment
 create mode 100644 doc/forum/Using_Linux_static_builds/comment_2_36f69f30117ff8696425a754ab19a08b._comment
 create mode 100644 doc/forum/Using_Linux_static_builds/comment_3_64506833dad0202626239e00d1eb6490._comment
 create mode 100644 doc/forum/Using___34__sync__34___to_sink_all_branches__63__.mdwn
 create mode 100644 doc/forum/Using___34__sync__34___to_sink_all_branches__63__/comment_1_ef3d5c5e2600ffa36dd933c8a42cdf96._comment
 create mode 100644 doc/forum/Using___34__sync__34___to_sink_all_branches__63__/comment_2_424b0c6fdfe87ca08f5d408b7684ab08._comment
 create mode 100644 doc/forum/Using___34__sync__34___to_sink_all_branches__63__/comment_3_adaf9114c69f1268330adcebd8018fa0._comment
 create mode 100644 doc/forum/Using___39__git_add__39___in_mixed_content_repository__63__.mdwn
 create mode 100644 doc/forum/Using___39__git_add__39___in_mixed_content_repository__63__/comment_1_4b524cbbd40aedeb7d44f0c6dec9ffa1._comment
 create mode 100644 doc/forum/Using_a_glacier_remote_as_a_backup.mdwn
 create mode 100644 doc/forum/Using_a_glacier_remote_as_a_backup/comment_1_bb6022943ec739b1e80351c76f259e89._comment
 create mode 100644 doc/forum/Using_a_glacier_remote_as_a_backup/comment_2_41d47f0ca2e05e3296face5f89b819da._comment
 create mode 100644 doc/forum/Using_a_glacier_remote_as_a_backup/comment_3_e572b7bd25b4e7f6c6f83c7354d7407f._comment
 create mode 100644 doc/forum/Using_a_single_backup_repo_for_multiple_independent_client_repos__63__.mdwn
 create mode 100644 doc/forum/Using_a_single_backup_repo_for_multiple_independent_client_repos__63__/comment_1_c61c28600f1079fb03ddabc950307f27._comment
 create mode 100644 doc/forum/Using_for_Music_repo.mdwn
 create mode 100644 doc/forum/Using_for_Music_repo/comment_1_3488ed85ad98f14cb17f229225ece26e._comment
 create mode 100644 doc/forum/Using_for_Music_repo/comment_2_c794648878cfc77558f8db862271f997._comment
 create mode 100644 doc/forum/Using_for_Music_repo/comment_3_8c5e820f5ff7d717d64b1fd66927941b._comment
 create mode 100644 doc/forum/Using_git-annex.mdwn
 create mode 100644 doc/forum/Using_git-annex/comment_1_ac386ca07e9aaf009c264f3deed83832._comment
 create mode 100644 doc/forum/Using_git-annex/comment_2_bf5e13a490e16943acd2732f093695fc._comment
 create mode 100644 doc/forum/Using_git-annex/comment_3_471c9268b028f47ef3fac3f0be14b2b1._comment
 create mode 100644 doc/forum/Using_git-annex_as_a_library.mdwn
 create mode 100644 doc/forum/Using_git-annex_as_a_library/comment_10_cfded5c6325007c3f3f83818bd2e1dbc._comment
 create mode 100644 doc/forum/Using_git-annex_as_a_library/comment_1_1f8e74c5856f21c53d5a91892cbef0c6._comment
 create mode 100644 doc/forum/Using_git-annex_as_a_library/comment_2_11a243fa7d8ac947aa9a798228dbd191._comment
 create mode 100644 doc/forum/Using_git-annex_as_a_library/comment_3_ac52304a096ebc66967352efaffb060a._comment
 create mode 100644 doc/forum/Using_git-annex_as_a_library/comment_4_d502fea60bf3a82f8a50f72a90a80c25._comment
 create mode 100644 doc/forum/Using_git-annex_as_a_library/comment_5_a4ab4173620b72ac0a24d575fa9c810c._comment
 create mode 100644 doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment
 create mode 100644 doc/forum/Using_git-annex_as_a_library/comment_7_909628f1edd0d3448498fc434c61a3a4._comment
 create mode 100644 doc/forum/Using_git-annex_as_a_library/comment_8_cef28b8639b6c6e84804b485fb5037f1._comment
 create mode 100644 doc/forum/Using_git-annex_as_a_library/comment_9_6d8ebdedf76fdf0c267444a7a07e225e._comment
 create mode 100644 doc/forum/Using_git-annex_to_manage_git_repositories.mdwn
 create mode 100644 doc/forum/Using_git-annex_to_manage_git_repositories/comment_1_f221717814f62e0779d691d2f601ab12._comment
 create mode 100644 doc/forum/Using_git-annex_to_manage_git_repositories/comment_2_ab24098c2f4519cbbfdcd00ba3e21d2b._comment
 create mode 100644 doc/forum/Using_git-annex_to_manage_git_repositories/comment_3_5cf9e2ff83bb76650469444c80fee4fb._comment
 create mode 100644 doc/forum/Using_git-annex_via_command_line_in_OS_X.mdwn
 create mode 100644 doc/forum/Using_git-annex_via_command_line_in_OS_X/comment_1_1c9e121f60fb6868c07f1a53b03c4ed0._comment
 create mode 100644 doc/forum/Using_git-annex_via_command_line_in_OS_X/comment_2_52d8ffba82e29ac2722a8e43e469cc47._comment
 create mode 100644 doc/forum/Using_git_annex_as_a_library.mdwn
 create mode 100644 doc/forum/Using_git_annex_as_a_library/comment_1_42cd26878e4e5c2c238c1227e3c372d9._comment
 create mode 100644 doc/forum/Using_git_annex_as_a_library/comment_2_1323238fc63e121fbc0f408a23d1ada5._comment
 create mode 100644 doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks.mdwn
 create mode 100644 doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_1_b9f202a30ba7e3bc264064d24454c099._comment
 create mode 100644 doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_2_1334a8d9f4bb60f3bf3ebabc656d98d9._comment
 create mode 100644 doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_3_076f22d05fad140068a540e4d835106f._comment
 create mode 100644 doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_4_c8446ee1b817f1824fa0df07e742015c._comment
 create mode 100644 doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_5_f746c1b85ee8e4b57b6819ccceabd28b._comment
 create mode 100644 doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs.mdwn
 create mode 100644 doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_1_bd73c8d10028e1b45da9ea8f657e5064._comment
 create mode 100644 doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_2_16c3c994ee8fcb466e52ca0e812e5915._comment
 create mode 100644 doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_3_ac60f6edb76bdd541711e472eec9591a._comment
 create mode 100644 doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_4_2194f0600d9a90f0d9c947ea9cc213a3._comment
 create mode 100644 doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_5_eb7d13f6b6fa674a2536bde51bfc3fd1._comment
 create mode 100644 doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_6_ae323b16ddb9342e91be955408eca3b1._comment
 create mode 100644 doc/forum/Using_hashdirlower_layout_for_S3_special_remote.mdwn
 create mode 100644 doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_1_ff8c84af9d08dfe7d8e502d1b84732f4._comment
 create mode 100644 doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_2_9f22f7f14fab759caa1ddecda435311c._comment
 create mode 100644 doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_3_d90ee84a9b0cf190961d92d089dbf7a6._comment
 create mode 100644 doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_4_5aa6dff353af7beffdd56652d6fc6d3e._comment
 create mode 100644 doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_5_79519a4c0fc25d41226a7048cd3a8306._comment
 create mode 100644 doc/forum/Using_integer_ranges_with_metadata.mdwn
 create mode 100644 doc/forum/Using_integer_ranges_with_metadata/comment_1_36298a679379e807892cd6af18ec1dd6._comment
 create mode 100644 doc/forum/Using_integer_ranges_with_metadata/comment_2_064e2c5706d1acc0f9e4576ff80407f7._comment
 create mode 100644 doc/forum/Using_integer_ranges_with_metadata/comment_3_c3ce727f93cce19db1f76de9f7216cee._comment
 create mode 100644 doc/forum/Using_integer_ranges_with_metadata/comment_4_c3301d1b2b57994666947fd518fb9922._comment
 create mode 100644 doc/forum/Using_integer_ranges_with_metadata/comment_5_9d310fac003f1cd9e6ca9bc96a210def._comment
 create mode 100644 doc/forum/Using_integer_ranges_with_metadata/comment_6_ead2b08bf4631547c34486ce58559017._comment
 create mode 100644 doc/forum/Using_standard_groups_and_sync_to_preserve_history__58___--all_not_recognised.mdwn
 create mode 100644 doc/forum/Using_standard_groups_and_sync_to_preserve_history__58___--all_not_recognised/comment_1_c3dd239d4b5b372229f2cec42a8a6eb4._comment
 create mode 100644 doc/forum/Using_standard_groups_and_sync_to_preserve_history__58___--all_not_recognised/comment_2_b76dd79aabe87ec717eea164aa965d74._comment
 create mode 100644 doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn
 create mode 100644 doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service/comment_1_7070f6e7e05fba7686d8620d62906a83._comment
 create mode 100644 doc/forum/Verification.mdwn
 create mode 100644 doc/forum/Verification/comment_1_d56818a8f5b3a94ecf5159c76f24768c._comment
 create mode 100644 doc/forum/Verification/comment_2_7df45d1e20a32458791603d5b9fe3dc4._comment
 create mode 100644 doc/forum/Verification/comment_3_74db3ec8b03f48912306e48b8d5f7242._comment
 create mode 100644 doc/forum/Verification/comment_4_eb4d936a9bd577f58483b278ae5dc5f6._comment
 create mode 100644 doc/forum/Verification/comment_5_c327c72ceced27920681d5f93bc256c8._comment
 create mode 100644 doc/forum/Version_5_repo_with_git-annex_client_8.20211123___63__.mdwn
 create mode 100644 doc/forum/Version_5_repo_with_git-annex_client_8.20211123___63__/comment_1_780fb88d5cfcde6e8a8b6f025be6a043._comment
 create mode 100644 doc/forum/View_for_locally_existing_files.mdwn
 create mode 100644 doc/forum/View_for_locally_existing_files/comment_1_8ede4c8f1ca48e34629c46a77ba01f11._comment
 create mode 100644 doc/forum/View_for_locally_existing_files/comment_2_e8d7672850518f4859643a0ee40e57e1._comment
 create mode 100644 doc/forum/View_performance_with_7__44__000_files.mdwn
 create mode 100644 doc/forum/View_performance_with_7__44__000_files/comment_1_e45ea752100d09d29efb6136a722eab3._comment
 create mode 100644 doc/forum/View_performance_with_7__44__000_files/comment_2_b1942eed65e9b5c046095a094191a38c._comment
 create mode 100644 doc/forum/View_performance_with_7__44__000_files/comment_3_e6e19339c9d72cf8eaae32ef4269e850._comment
 create mode 100644 doc/forum/View_special_remote_information__63__.mdwn
 create mode 100644 doc/forum/View_special_remote_information__63__/comment_1_7c106e0679890f7279c73b5c52d648e2._comment
 create mode 100644 doc/forum/WARNING__58___linker__58__git-annex_has_text_relocations.mdwn
 create mode 100644 doc/forum/WARNING__58___linker__58__git-annex_has_text_relocations/comment_1_fee360353f0b46aab6ee7a902c0837bb._comment
 create mode 100644 doc/forum/Walkthrough_does_not_work_for_me__44___what_am_i_doing_wrong__63__.mdwn
 create mode 100644 doc/forum/Walkthrough_does_not_work_for_me__44___what_am_i_doing_wrong__63__/comment_1_cdac15fec6fc41d5487b7f653fa718a4._comment
 create mode 100644 doc/forum/Walkthrough_does_not_work_for_me__44___what_am_i_doing_wrong__63__/comment_2_82050b7dc367ca5968ab0306db9bd7e3._comment
 create mode 100644 doc/forum/Walkthrough_for_direct_mode__63__.mdwn
 create mode 100644 doc/forum/Want_to_stop_using_Git-Annex.mdwn
 create mode 100644 doc/forum/Want_to_stop_using_Git-Annex/comment_1_32e37515bd4f5d22ff9aedd3c9d98046._comment
 create mode 100644 doc/forum/Want_to_stop_using_Git-Annex/comment_2_e29e6d052ef3677ad7d5615721f3fe33._comment
 create mode 100644 doc/forum/Wanted___39__present__39___makes_sync_slow_on_thin_copy_of_large_annex..mdwn
 create mode 100644 doc/forum/Wanted_content_based_on_date_added.mdwn
 create mode 100644 doc/forum/Wanted_content_based_on_date_added/comment_1_af2a6e6cba4cdfe24e9ee2c819a007eb._comment
 create mode 100644 doc/forum/Warning__58___linker_on_each_command_Android_8.20210429.mdwn
 create mode 100644 doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_1_02c38a5dc1c2213dd5f12c4b7fb0c72e._comment
 create mode 100644 doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_2_02e5631245348bcef541360b5ca0e9e5._comment
 create mode 100644 doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_3_12c9af06c1473de6740b782ca42d6a5a._comment
 create mode 100644 doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_4_daa8522e3be6a0563d7cd107e79577b8._comment
 create mode 100644 doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_5_32c3cae8fb69c42747bb3ec4f3926dfb._comment
 create mode 100644 doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_6_95e16558f7010627ef4136043f63b937._comment
 create mode 100644 doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_7_733131f7608bc0309c034a954f297275._comment
 create mode 100644 doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_8_c73d26803fcc932edd7049efd0318aab._comment
 create mode 100644 doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_9_3eb65e0d204832d7d8700a85b3f4e51e._comment
 create mode 100644 doc/forum/Watch__47__assistant__47__webapp_documentation.mdwn
 create mode 100644 doc/forum/Watch__47__assistant__47__webapp_documentation/comment_1_adb377589dbae7fc91001df235c6b48e._comment
 create mode 100644 doc/forum/Way_to_add_file_in_other_directory_without_change__63__.mdwn
 create mode 100644 doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_1c324fdc46fe9db3778bf21d9fbdd021._comment
 create mode 100644 doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_9d18e0752ae4b1ded9611759fbe2eeec._comment
 create mode 100644 doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_3_61841267c85651158652b20b137fb5fb._comment
 create mode 100644 doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_4_f414a1d2c54eda4602d224a937d413b7._comment
 create mode 100644 doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_5_8290c580d2788dbefb4e41cb9671eecb._comment
 create mode 100644 doc/forum/Way_to_copy_files___40__the_symbolic_links__41__.mdwn
 create mode 100644 doc/forum/Way_to_copy_files___40__the_symbolic_links__41__/comment_1_5f452eeb652e1bbec54cddc3735a6d4a._comment
 create mode 100644 doc/forum/Way_to_copy_files___40__the_symbolic_links__41__/comment_2_56617a9d760e7528d7b30ed479e5070a._comment
 create mode 100644 doc/forum/Way_to_copy_files___40__the_symbolic_links__41__/comment_3_8c8f09c8a916dd44d787a02f1570bd82._comment
 create mode 100644 doc/forum/Way_to_list_missing_files.mdwn
 create mode 100644 doc/forum/Way_to_list_missing_files/comment_1_d302a4b64cfca76e8af756018768ff08._comment
 create mode 100644 doc/forum/Web_app_on_server_without_X11__63__.mdwn
 create mode 100644 doc/forum/Web_app_on_server_without_X11__63__/comment_1_bee409ad389e5fb5f3e8de4b5c68278d._comment
 create mode 100644 doc/forum/Web_interface_to_git-annex__63__.mdwn
 create mode 100644 doc/forum/Web_interface_to_git-annex__63__/comment_1_371586edbeca15724121a5123bce66d6._comment
 create mode 100644 doc/forum/Webapp_not_watching_repos.mdwn
 create mode 100644 doc/forum/Webapp_not_watching_repos/comment_1_02735050122afdb6498d91b462d32767._comment
 create mode 100644 doc/forum/Webapp_not_watching_repos/comment_2_8ab2d4c18ddc99774e44c4f4401bfa57._comment
 create mode 100644 doc/forum/Webapp_not_watching_repos/comment_3_b448aa5a95a57a5228b361390e5fc838._comment
 create mode 100644 doc/forum/Webapp_on_ARM.mdwn
 create mode 100644 doc/forum/Webapp_on_ARM/comment_1_82ac40cef5b59070136527b8d81a5ce2._comment
 create mode 100644 doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app.mdwn
 create mode 100644 doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_1_8c8d86790a9d31518f9bb96a2d2dafee._comment
 create mode 100644 doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_2_b538dc2c6f122b9ce5f7569de1b03f3e._comment
 create mode 100644 doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_3_16e6724fa184392d4decbe0c4eb6efe6._comment
 create mode 100644 doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_4_e514fe2d4d0ad6a10e281939e6ab4266._comment
 create mode 100644 doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_5_e0eec765f72f7bf6f5a2a92c9b5dacad._comment
 create mode 100644 doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__.mdwn
 create mode 100644 doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__/comment_1_e4e9c6858fe905b17154e19cbe7ee2f5._comment
 create mode 100644 doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__/comment_2_359e52a73f236bce4e8e31e76436fba7._comment
 create mode 100644 doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__/comment_3_d43cf2928e2ebbf2793911e49cffd671._comment
 create mode 100644 doc/forum/What_am_I_doing_wrong_with_move__63__.mdwn
 create mode 100644 doc/forum/What_am_I_doing_wrong_with_move__63__/comment_1_a49d98426ef8dd17e6cca6b5fba5c9bf._comment
 create mode 100644 doc/forum/What_am_I_doing_wrong_with_move__63__/comment_2_eeae2f172b4481fcb08745fc28aa4d4e._comment
 create mode 100644 doc/forum/What_am_I_doing_wrong_with_move__63__/comment_3_f2770f86138d9b8489fbf9a25462b4ce._comment
 create mode 100644 doc/forum/What_am_I_doing_wrong_with_move__63__/comment_4_76aa27cdeefb1413baaa1c891ccd4d0d._comment
 create mode 100644 doc/forum/What_can_be_done_in_case_of_conflict.mdwn
 create mode 100644 doc/forum/What_can_be_done_in_case_of_conflict/comment_1_5ca86b099dfa08a50f656ea03bf1dcd9._comment
 create mode 100644 doc/forum/What_can_be_done_in_case_of_conflict/comment_2_69ee17959a92bb8359c0fd7b2a9d8dfb._comment
 create mode 100644 doc/forum/What_can_be_done_in_case_of_conflict/comment_3_017f4bac57a040c496e0c9d068dcfd9e._comment
 create mode 100644 doc/forum/What_does___34__disable__47__enable_expiry_after_X_days__34___mean__63__.mdwn
 create mode 100644 doc/forum/What_does___34__disable__47__enable_expiry_after_X_days__34___mean__63__/comment_1_face45c85e4713325bb23bbca7b07502._comment
 create mode 100644 doc/forum/What_does_a___91__RepoName__93___means__63__.mdwn
 create mode 100644 doc/forum/What_does_a___91__RepoName__93___means__63__/comment_1_9b1cb4beea0f67d7e7375e7ec189b802._comment
 create mode 100644 doc/forum/What_does_a___91__RepoName__93___means__63__/comment_2_a233086f100fec27cd26f4d39c25a385._comment
 create mode 100644 doc/forum/What_does_a___91__RepoName__93___means__63__/comment_3_4b62bf0c03fed86270a7873a8835dc7f._comment
 create mode 100644 doc/forum/What_happened_to_the_walkthrough__63__.mdwn
 create mode 100644 doc/forum/What_happened_to_the_walkthrough__63__/comment_1_70db0e3cfb1318e95671c23726e5541d._comment
 create mode 100644 doc/forum/What_happened_to_the_walkthrough__63__/comment_2_f9305dd19b9b5f35e66d915b8c30374b._comment
 create mode 100644 doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__.mdwn
 create mode 100644 doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__/comment_1_0ba60f9625ccda45d59adbd385f5fe98._comment
 create mode 100644 doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__/comment_3_f0a2ec3d0b05d84fb05a1708313a6762._comment
 create mode 100644 doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__/comment_3_f628f146a0c652f812c09f78bd574b77._comment
 create mode 100644 doc/forum/What_happens_when_in_the_git-annex_assistant_you___34__Add_another_local_repository__34___on_an_existing_repository__63__.mdwn
 create mode 100644 doc/forum/What_happens_when_in_the_git-annex_assistant_you___34__Add_another_local_repository__34___on_an_existing_repository__63__/comment_1_d844cfe5f9907a766e871b64d68966c2._comment
 create mode 100644 doc/forum/What_is_going_on_here__63__.mdwn
 create mode 100644 doc/forum/What_is_going_on_here__63__/comment_1_499bf04c32c86a747bd7c38d13f5de50._comment
 create mode 100644 doc/forum/What_is_going_on_here__63__/comment_2_0acd71ec48c69da62886e69afa496120._comment
 create mode 100644 doc/forum/What_is_going_on_here__63__/comment_3_a1221c0a0585b7e60643a8e4a50b282b._comment
 create mode 100644 doc/forum/What_is_going_on_here__63__/comment_4_a9fa5282774cc32ece9196b864435957._comment
 create mode 100644 doc/forum/What_is_going_on_here__63__/comment_5_8e35d10c208d0d1e93254a1a275fcba6._comment
 create mode 100644 doc/forum/What_is_going_on_here__63__/comment_6_536adad665f481a15d4096360d0106c1._comment
 create mode 100644 doc/forum/What_is_the_assistant_up_to__63__.mdwn
 create mode 100644 doc/forum/What_is_the_assistant_up_to__63__/comment_1_9baa0e54c19105c7cce946c19c587866._comment
 create mode 100644 doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__.mdwn
 create mode 100644 doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_1_02d305f307b4d2ff7acd98cb36508a2f._comment
 create mode 100644 doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_2_9f7daf0a3e53b2cf64b2b64ca6fbfd9b._comment
 create mode 100644 doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_3_06b137018b4c995afc8891032704c1d8._comment
 create mode 100644 doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_4_138d9067831e26407404b993199d5a0f._comment
 create mode 100644 doc/forum/What_is_the_difference_between___34__local_computer__34___and___34__remote_server__34__.mdwn
 create mode 100644 doc/forum/What_is_the_difference_between___34__local_computer__34___and___34__remote_server__34__/comment_1_68734a118b7dc0c88ba67eca20953a55._comment
 create mode 100644 doc/forum/What_operations_are_safe_to_interrupt__63__.mdwn
 create mode 100644 doc/forum/What_operations_are_safe_to_interrupt__63__/comment_1_03d8ddc049cf073e5579ca829b352367._comment
 create mode 100644 doc/forum/What_operations_are_safe_to_interrupt__63__/comment_2_207435949b2674ea82390c66549873e5._comment
 create mode 100644 doc/forum/What_operations_are_safe_to_interrupt__63__/comment_4_279302a0f5bb0a8d8d87182e03c6b475._comment
 create mode 100644 doc/forum/What_operations_are_safe_to_interrupt__63__/comment_5_8d36d42e34f5deae04bfa83c568b89d5._comment
 create mode 100644 doc/forum/What_to_do_if_special_remotes_refuses_drops__63__.mdwn
 create mode 100644 doc/forum/What_to_do_if_special_remotes_refuses_drops__63__/comment_1_0b523b2b6c361346c36ad456bbbac645._comment
 create mode 100644 doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__.mdwn
 create mode 100644 doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__/comment_1_67ee446ca6d66e2c259ea771c2c9a2b2._comment
 create mode 100644 doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__/comment_2_6d3cce3c8048e4aea8f0ed76473f6af1._comment
 create mode 100644 doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__/comment_3_bd506e1ca7307660b3b9769eb97beddb._comment
 create mode 100644 doc/forum/When_--git-dir_is_not_in_--work-tree.mdwn
 create mode 100644 doc/forum/When_--git-dir_is_not_in_--work-tree/comment_1_0169812633d92bed8883e903e03056e3._comment
 create mode 100644 doc/forum/When_--git-dir_is_not_in_--work-tree/comment_2_0c101e5b017f56897599c2cbd37b1754._comment
 create mode 100644 doc/forum/When_to_reuse_UUIDs_and_avoiding_UUID_clutter.mdwn
 create mode 100644 doc/forum/Where_are_my_remote_ssh_files__63__.mdwn
 create mode 100644 doc/forum/Where_did_my_files_go__63__.mdwn
 create mode 100644 doc/forum/Where_did_my_files_go__63__/comment_1_3ff3ffa95eb2745ff9ec2a903e071d97._comment
 create mode 100644 doc/forum/Where_did_my_files_go__63__/comment_2_9d902e66ca19b3332f4454f694d4a12e._comment
 create mode 100644 doc/forum/Where_is_the_S3_config__63__.mdwn
 create mode 100644 doc/forum/Where_is_the_S3_config__63__/comment_1_63009ad122cfafc9682e06f984eaefe1._comment
 create mode 100644 doc/forum/Where_is_the_S3_config__63__/comment_2_61403be4cc347fecedd8b19d6604e6d3._comment
 create mode 100644 doc/forum/Where_is_the_content__63__.mdwn
 create mode 100644 doc/forum/Where_is_the_content__63__/comment_1_812e1cf740cbfa449ab3ef4dd5f2df08._comment
 create mode 100644 doc/forum/Where_is_the_content__63__/comment_2_5e2cfdfab6c4f84fe7a19447b417b5a7._comment
 create mode 100644 doc/forum/Where_is_the_content__63__/comment_3_bd4cbc8f256a94ffde4f57d2c406a9ec._comment
 create mode 100644 doc/forum/Where_is_the_content__63__/comment_4_a36b35d47472b5db779b0489bf3d4893._comment
 create mode 100644 doc/forum/Which_branches_are___34__required__34__.mdwn
 create mode 100644 doc/forum/Which_branches_are___34__required__34__/comment_1_78d9ac05c66b7ccec031e0c57095af39._comment
 create mode 100644 doc/forum/Which_cloud_providers_are_supported__63___.mdwn
 create mode 100644 doc/forum/Which_cloud_providers_are_supported__63___/comment_1_1f9398840144e0452a2fed9336046547._comment
 create mode 100644 doc/forum/Why_are_ignored_files_being_deleted__63__.mdwn
 create mode 100644 doc/forum/Why_are_ignored_files_being_deleted__63__/comment_1_3081bda5bb600fc564185499ddfb5cf9._comment
 create mode 100644 doc/forum/Why_are_ignored_files_being_deleted__63__/comment_2_178aa574855a3bfffab4b21f90a84092._comment
 create mode 100644 doc/forum/Why_are_new_repos_v5__63___Should_I_be_concerned__63__.mdwn
 create mode 100644 doc/forum/Why_are_new_repos_v5__63___Should_I_be_concerned__63__/comment_1_b7fc905780f941314c99b94a87e0438a._comment
 create mode 100644 doc/forum/Why_are_we_stopping_at_a_duplicate__63__.mdwn
 create mode 100644 doc/forum/Why_are_we_stopping_at_a_duplicate__63__/comment_1_dd3b610032cd3091effdb3f0828f45a8._comment
 create mode 100644 doc/forum/Why_can__39__t_encryption_be_enabled_for_removable_drives__63__.mdwn
 create mode 100644 doc/forum/Why_can__39__t_encryption_be_enabled_for_removable_drives__63__/comment_1_4341898d5ae4f09a5b06d24f5fe6192d._comment
 create mode 100644 doc/forum/Why_does_git_annex_does_not_want_that_file__63__.mdwn
 create mode 100644 doc/forum/Why_does_git_annex_does_not_want_that_file__63__/comment_1_44cd6ca1f7215395e19ce654513197a9._comment
 create mode 100644 doc/forum/Why_does_the_bup_remote_use___126____47__.bup__63__.mdwn
 create mode 100644 doc/forum/Why_does_the_bup_remote_use___126____47__.bup__63__/comment_1_da9c7c0e93aefc2da7409de5b138d86f._comment
 create mode 100644 doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__.mdwn
 create mode 100644 doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_10_abae8a95b60f17052a5e2ac30a7ece32._comment
 create mode 100644 doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_1_dfd69ac96065f8146f5ea87b957cca6e._comment
 create mode 100644 doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_2_8d36f559d7f8b61f5633f0d24b424cec._comment
 create mode 100644 doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_3_a318582d30f5483f3738e8f0f1a2e1df._comment
 create mode 100644 doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_4_bc2e255f8732f6ec02e90a6623ffc8af._comment
 create mode 100644 doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_5_691dc07b192f077f50611544d488b394._comment
 create mode 100644 doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_6_71d7a08600dcba07dd895ddf6ad1331a._comment
 create mode 100644 doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_7_a5d60323c2c6b2d263514b33ad774aa9._comment
 create mode 100644 doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_8_83e52bd3d66ce87ba7d2913d21c76b08._comment
 create mode 100644 doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_9_0bd122e2e664d29dca027719721b1523._comment
 create mode 100644 doc/forum/Why_is_git_annex_status_slow__63__.mdwn
 create mode 100644 doc/forum/Why_is_git_annex_status_slow__63__/comment_1_a5139c5a9fc94486cf62fc9a9fa9f8d9._comment
 create mode 100644 doc/forum/Why_is_git_annex_status_slow__63__/comment_2_2f61c2cdf9d1ffd298fd906207012818._comment
 create mode 100644 doc/forum/Why_is_git_annex_status_slow__63__/comment_3_8d9e5a1aef2648d7a844623e6237d551._comment
 create mode 100644 doc/forum/Will_git-annex_solve_my_problem__63__.mdwn
 create mode 100644 doc/forum/Will_git-annex_solve_my_problem__63__/comment_1_35acbdd1a7727df204d776c2e8f02b53._comment
 create mode 100644 doc/forum/Will_git-annex_solve_my_problem__63__/comment_2_230256c19ac139dea207d89c06f70782._comment
 create mode 100644 doc/forum/Will_git_annex_work_on_a_FAT32_formatted_key__63__.mdwn
 create mode 100644 doc/forum/Will_git_annex_work_on_a_FAT32_formatted_key__63__/comment_1_426482e6eb3a27687a48f24f6ef2332f._comment
 create mode 100644 doc/forum/Will_git_annex_work_on_a_FAT32_formatted_key__63__/comment_2_af4f8b52526d8bea2904c95406fd2796._comment
 create mode 100644 doc/forum/Windows_-_You_don__39__t_have_access.mdwn
 create mode 100644 doc/forum/Windows_-_You_don__39__t_have_access/comment_1_5c1da63922cc71483c9519e8670d532b._comment
 create mode 100644 doc/forum/Windows_-_You_don__39__t_have_access/comment_2_aa6ea60465df9fab7990bd6f510b74c5._comment
 create mode 100644 doc/forum/Windows_-_You_don__39__t_have_access/comment_3_593a8a54fa80258d5048f5c061992664._comment
 create mode 100644 doc/forum/Windows_-_You_don__39__t_have_access/comment_4_aa28602eb0b7fa7103eaf90dc1d5cf8f._comment
 create mode 100644 doc/forum/Windows_-_You_don__39__t_have_access/comment_5_f9041e48b911dbdd37ad3c1bbc801709._comment
 create mode 100644 doc/forum/Windows_-_You_don__39__t_have_access/comment_6_7656eb72bb9e39db59092557c57a2489._comment
 create mode 100644 doc/forum/Windows_-_gpg_fails_with_shared_encryption.mdwn
 create mode 100644 doc/forum/Windows_-_gpg_fails_with_shared_encryption/comment_1_708da81b0678576a240ce7a388806e07._comment
 create mode 100644 doc/forum/Windows_-_gpg_fails_with_shared_encryption/comment_2_9f5d0e8d0c6eff548318b54797cefd09._comment
 create mode 100644 doc/forum/Windows_S3_host_issue.mdwn
 create mode 100644 doc/forum/Windows_S3_host_issue/comment_1_8c0a1e84713a04a25fdc1f74919d34aa._comment
 create mode 100644 doc/forum/Windows_S3_host_issue/comment_2_06ecc76797c430b27a2e24776761d043._comment
 create mode 100644 doc/forum/Windows_S3_host_issue/comment_3_1715557daa15b9e9e17b4850141e62af._comment
 create mode 100644 doc/forum/Windows_eol_issues.mdwn
 create mode 100644 doc/forum/Windows_eol_issues/comment_1_72e4c3a200e3fceb2afd4df563eaa5d4._comment
 create mode 100644 doc/forum/Windows_eol_issues/comment_2_77383b959d576c7930c726c55097c964._comment
 create mode 100644 doc/forum/Windows_eol_issues/comment_3_926b386f5ca59f1c5232cf5cba69e12a._comment
 create mode 100644 doc/forum/Windows_eol_issues/comment_4_dc470ae359ee4ce017770a89441a8b65._comment
 create mode 100644 doc/forum/Windows_eol_issues/comment_5_e711bdfcee4ec9a2860662e8c65a9c0f._comment
 create mode 100644 doc/forum/Windows_eol_issues/comment_6_62f748e40324bc988366e19088b33295._comment
 create mode 100644 doc/forum/Windows_eol_issues/comment_7_f9b71ea2158c02dfa8a7c59891aea679._comment
 create mode 100644 doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__.mdwn
 create mode 100644 doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_1_b051dc30bf5a0fc9f5710c664f487ea9._comment
 create mode 100644 doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_2_8775a1483b29e2cc8f0456473c24e51e._comment
 create mode 100644 doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_3_cbaa3e0fa4e2347332b3929411f60d1d._comment
 create mode 100644 doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_4_3dc3cc824256b1f7530c7f516b0abbec._comment
 create mode 100644 doc/forum/Windows_installation_notes.mdwn
 create mode 100644 doc/forum/Windows_installation_notes/comment_1_54c253ab61fea4f5aaefa04bb078c7b0._comment
 create mode 100644 doc/forum/Windows_installation_notes/comment_2_c8c2744e30f2950d9830936d2bd51617._comment
 create mode 100644 doc/forum/Windows_support.mdwn
 create mode 100644 doc/forum/Windows_support/comment_1_23fa9aa3b00940a1c1b3876c35eef019._comment
 create mode 100644 doc/forum/Windows_usage_instructions.mdwn
 create mode 100644 doc/forum/Windows_usage_instructions/comment_1_d43dbd9406da3b9747b147715eca94ac._comment
 create mode 100644 doc/forum/Wishlist__58___Bittorrent-like_transfers.mdwn
 create mode 100644 doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_1_13544d54fb0418af4ca9200cdb045d91._comment
 create mode 100644 doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_2_9a7dad35bf80c684ad97892420d7370c._comment
 create mode 100644 doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_3_e5de748bc5da12a4a01e08cde2407dd1._comment
 create mode 100644 doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_4_e51530178f1e034c0fdd5c9aa9945567._comment
 create mode 100644 doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_5_81ea9c129d8c02097f09ef8c68f1bb11._comment
 create mode 100644 doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_6_3b5798414f89686526da3dfa72c0c4f2._comment
 create mode 100644 doc/forum/Wishlist__58___Don__39__t_make_files_readonly.mdwn
 create mode 100644 doc/forum/Wishlist__58___Don__39__t_make_files_readonly/comment_1_7148527961e2d27793810966588c8d35._comment
 create mode 100644 doc/forum/Wishlist__58___Is_it_possible_to___34__unlock__34___files_without_copying_the_file_data__63__.mdwn
 create mode 100644 doc/forum/Wishlist__58___Is_it_possible_to___34__unlock__34___files_without_copying_the_file_data__63__/comment_1_1cf4ab29dfa2cff59b86305fc0018251._comment
 create mode 100644 doc/forum/Wishlist__58___Is_it_possible_to___34__unlock__34___files_without_copying_the_file_data__63__/comment_2_f5ebb7f43dcef861ecc13373fb1e263f._comment
 create mode 100644 doc/forum/Wishlist__58___Ways_of_selecting_files_based_on_meta-information.mdwn
 create mode 100644 doc/forum/Wishlist__58___Ways_of_selecting_files_based_on_meta-information/comment_1_818f38aa988177d3a9415055e084f0fb._comment
 create mode 100644 doc/forum/Wishlist__58___Ways_of_selecting_files_based_on_meta-information/comment_2_97e2ed48bd552d02918c4f98f963e6e1._comment
 create mode 100644 doc/forum/Wishlist__58___automatic_reinject.mdwn
 create mode 100644 doc/forum/Wishlist__58___automatic_reinject/comment_1_6bf093f228353130e80e7a30bcf0075d._comment
 create mode 100644 doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files.mdwn
 create mode 100644 doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files/comment_1_7abb1155081a23ce4829ee69b2064541._comment
 create mode 100644 doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files/comment_2_b4c6ebada7526263e04c70eac312fda9._comment
 create mode 100644 doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files/comment_3_ded71b270b94617a8ebb3a713d46a274._comment
 create mode 100644 doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__.mdwn
 create mode 100644 doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__/comment_1_42aa2b61b880f4048d874210212aa63b._comment
 create mode 100644 doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__/comment_2_3e201039fa0e611554171ee30e69a414._comment
 create mode 100644 doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__/comment_3_d1074724c44f3296cb438b2d526d8728._comment
 create mode 100644 doc/forum/Wishlist__58___mark_remotes_offline.mdwn
 create mode 100644 doc/forum/Wishlist__58___mark_remotes_offline/comment_1_9e3901f0123abb66034cce95cc5a941a._comment
 create mode 100644 doc/forum/Wishlist__58___mark_remotes_offline/comment_2_d10e3d90cf421ae425e64ab266ea811b._comment
 create mode 100644 doc/forum/Wishlist__58___options_for_syncing_meta-data_and_data.mdwn
 create mode 100644 doc/forum/Wishlist__58___rename_files__47__dirs_w__47___special_characters_if_filesystem_is_FAT.mdwn
 create mode 100644 doc/forum/Wishlist__58___rename_files__47__dirs_w__47___special_characters_if_filesystem_is_FAT/comment_1_5d33bcbd862537f53edd91dcff2b8977._comment
 create mode 100644 doc/forum/Workarounds_for_git-annex.mdwn
 create mode 100644 doc/forum/Workflow_for_adding_files.mdwn
 create mode 100644 doc/forum/Workflow_for_adding_files/comment_1_a60dae97db827bc641d6256d1f382b5f._comment
 create mode 100644 doc/forum/Workflow_for_adding_files/comment_2_28dd15ac50f79fb07bacf8b8326c7edc._comment
 create mode 100644 doc/forum/Workflow_for_using_git-annex_only_on_external_drives.mdwn
 create mode 100644 doc/forum/Workflow_for_using_git-annex_only_on_external_drives/comment_1_c3c495efb7cdd242b51cc7fa7719d95f._comment
 create mode 100644 doc/forum/Workflow_for_using_git-annex_only_on_external_drives/comment_2_f29471761e95b25e35e4cb09ad89737a._comment
 create mode 100644 doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner.mdwn
 create mode 100644 doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner/comment_1_ee783a968a5948e2f50bd2d090a2238b._comment
 create mode 100644 doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner/comment_2_259b67a887dd6aa327b752f455c24bff._comment
 create mode 100644 doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner/comment_3_a072a5c8f0798094d9ab0b7dc6c34f98._comment
 create mode 100644 doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3.mdwn
 create mode 100644 doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3/comment_1_8b066ad9628073a3ae045087b4ea79b5._comment
 create mode 100644 doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3/comment_2_c9eff9a83ea5ee71cbe87022be9d0875._comment
 create mode 100644 doc/forum/Wrong_symlink_target_on_usb_drive.mdwn
 create mode 100644 doc/forum/Wrong_symlink_target_on_usb_drive/comment_1_9a50df886c0c23ee6f5586bd9f6b61c3._comment
 create mode 100644 doc/forum/Wrong_symlink_target_on_usb_drive/comment_2_75df13154d3ea662119e9d701a0d9c97._comment
 create mode 100644 doc/forum/Wrong_symlink_target_on_usb_drive/comment_3_7f2fb4e7f0c0db9f9d9cbb637f02c9ff._comment
 create mode 100644 doc/forum/Wrong_symlink_target_on_usb_drive/comment_4_f6ee6bfd5d82f0925f0e174b4c75e592._comment
 create mode 100644 doc/forum/Wrong_symlink_target_on_usb_drive/comment_5_e5a152cef3c48ef05cb183907377f128._comment
 create mode 100644 doc/forum/Wrong_symlink_target_on_usb_drive/comment_6_be59fcc5633b352eefe993871df1ec4a._comment
 create mode 100644 doc/forum/Wrong_symlink_target_on_usb_drive/comment_7_64e1cdf144a17319831a58b04b22b7ea._comment
 create mode 100644 doc/forum/XBMC__44___NFS___38___git-annex_.mdwn
 create mode 100644 doc/forum/XBMC__44___NFS___38___git-annex_/comment_1_86480f31d410e903766f82e6ecf83e1c._comment
 create mode 100644 doc/forum/XBMC__44___NFS___38___git-annex_/comment_2_d8ed4dd51d3050db691a8abdec24cd42._comment
 create mode 100644 doc/forum/XBMC__44___NFS___38___git-annex_/comment_3_42b80ee51ce25775bf4532f53a8ecfe3._comment
 create mode 100644 doc/forum/XBMC__44___NFS___38___git-annex_/comment_4_01767f3f864954cf8080274e206da9d4._comment
 create mode 100644 doc/forum/XMPP_authentication_failure.mdwn
 create mode 100644 doc/forum/XMPP_authentication_failure/comment_1_19c7c3aa79d209d613d2e061e3129690._comment
 create mode 100644 doc/forum/XMPP_authentication_failure/comment_2_870059fed451e8377e5d382464ecc34b._comment
 create mode 100644 doc/forum/XMPP_authentication_failure/comment_3_1a7ff955e9173f13d10b75f203792384._comment
 create mode 100644 doc/forum/XMPP_authentication_failure/comment_4_d59031ebc0dd3abc1f4c96878328362c._comment
 create mode 100644 doc/forum/XMPP_authentication_failure/comment_5_c37ef477bef7efdb79dd05dce90dfde6._comment
 create mode 100644 doc/forum/XMPP_authentication_failure/comment_6_48cabea4c2caf5b3bd854df3aaa17d3d._comment
 create mode 100644 doc/forum/XMPP_authentication_failure/comment_7_14cd9b67806db93c3af055d88c9a910a._comment
 create mode 100644 doc/forum/XMPP_authentication_failure/comment_8_151d3fd7d3cceb30fd20a8f3bd54036c._comment
 create mode 100644 doc/forum/XMPP_authentication_failure/comment_9_fbb9eba65fbb72201f08511945fbcf8c._comment
 create mode 100644 doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__.mdwn
 create mode 100644 doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_1_1ba0735141fc6a21ac15913f4cacefae._comment
 create mode 100644 doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_2_16994dc86b87592fc62799e2d206d172._comment
 create mode 100644 doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_3_6afd424edc4095b8f71b136de2a9e64d._comment
 create mode 100644 doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_4_1381b6a927410642c6a93aa8354be791._comment
 create mode 100644 doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_5_c5b33c7a8aa8e6d0f9349510dac2366d._comment
 create mode 100644 doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_6_9913d2983ba2744ed24911f74988e4c7._comment
 create mode 100644 doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_7_ad6f385a2b95803eb9d81dfe76359551._comment
 create mode 100644 doc/forum/XMPP_problem_behind_router.mdwn
 create mode 100644 doc/forum/XMPP_problem_behind_router/comment_1_25a7f8dc5cf14cda4d76b2f8c6ca77d5._comment
 create mode 100644 doc/forum/XMPP_problem_behind_router/comment_2_3186ebe32c30764b9fd53625dd3e4eda._comment
 create mode 100644 doc/forum/XMPP_problem_behind_router/comment_3_7fa8fe8cb92993c935ba2dbfb2aef728._comment
 create mode 100644 doc/forum/XMPP_problem_behind_router/comment_4_6497ca72904dfdefe4e02f8a55127a8e._comment
 create mode 100644 doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__.mdwn
 create mode 100644 doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_1_01cbfc513c790faef3a3ede5315d3589._comment
 create mode 100644 doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_2_fe28dfb360caa12d5d5bc186def3eb45._comment
 create mode 100644 doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_3_9bb30ab62febe4ef63bed49f831a473a._comment
 create mode 100644 doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_4_7832f0347a41b8204538c01b72487803._comment
 create mode 100644 doc/forum/__171__Locking__187___files_until_synced.mdwn
 create mode 100644 doc/forum/__171__Locking__187___files_until_synced/comment_1_8bf59f47fee0a8d5741fe209b5899863._comment
 create mode 100644 doc/forum/__171__Locking__187___files_until_synced/comment_2_0c683547a6178e4303f0b1ed1f5605a5._comment
 create mode 100644 doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__.mdwn
 create mode 100644 doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_1_52e4453432184524d84d88f6382cac9d._comment
 create mode 100644 doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment
 create mode 100644 doc/forum/__34__Pairing__34___more_than_two_computers.mdwn
 create mode 100644 doc/forum/__34__Pairing__34___more_than_two_computers/comment_1_80f7a4bb3c66b11e566043407b611bbf._comment
 create mode 100644 doc/forum/__34__Preseeding__34___a_special_remote.mdwn
 create mode 100644 doc/forum/__34__Preseeding__34___a_special_remote/comment_1_b0c46d0eba900d0f6169a2c698d7a222._comment
 create mode 100644 doc/forum/__34__Preseeding__34___a_special_remote/comment_2_5e63f5e6f45c11cc86b293ce8acad77f._comment
 create mode 100644 doc/forum/__34__Scanning_for_files_to_transfer__34__.mdwn
 create mode 100644 doc/forum/__34__Scanning_for_files_to_transfer__34__/comment_1_4fa6d0d5264707886e1e9b5184090386._comment
 create mode 100644 doc/forum/__34__best__34___portable_filesystem_for_external_drive__63__.mdwn
 create mode 100644 doc/forum/__34__best__34___portable_filesystem_for_external_drive__63__/comment_1_31e5e55e9f8f391309b16c6591bb0bb0._comment
 create mode 100644 doc/forum/__34__best__34___portable_filesystem_for_external_drive__63__/comment_2_abb716dc8b39e1b20d8725d83a7cc662._comment
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__.mdwn
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_10_a80eccce0bdb33748ab1ccba9b88a65f._comment
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_11_e3f82edf70d28f00d30cfd98f189cd86._comment
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_12_041ae920e2e6fd83967dc98646452fa7._comment
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_1_a41bd02361aa961e5285aeaf1ea062be._comment
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_2_28ba62a546f5cc8f416491423d743d8a._comment
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_3_8d97f40c1d14b7230f3656a00a99cf80._comment
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_4_baa8fbbdd5c449a0dc2bb622cb4a47ce._comment
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_5_2ee6cbbfe54a2e7b6e8eb539c18e663d._comment
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_6_48f6a2761a34b7f991325f1d24e2c5ff._comment
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_7_d632baff41b8582f1a79bc5018c68545._comment
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_8_6a51c22d9893fa5b1503f5a14b1eb8ce._comment
 create mode 100644 doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_9_a2bda4c74ef09a58709c0c5f6ee1b726._comment
 create mode 100644 doc/forum/__34__git_add__34___vs___34__git_annex_add__34___in_v6.mdwn
 create mode 100644 doc/forum/__34__git_add__34___vs___34__git_annex_add__34___in_v6/comment_1_285032a01ca754c539ce0634823db23c._comment
 create mode 100644 doc/forum/__34__git_add__34___vs___34__git_annex_add__34___in_v6/comment_2_93eec60060bc7bca8dd1633b670f9a53._comment
 create mode 100644 doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4.mdwn
 create mode 100644 doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_1_34bd938e8cd0cba6ec48020932858485._comment
 create mode 100644 doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_2_3ec07e7f0e713e6fa925abb99c646bc7._comment
 create mode 100644 doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_3_3dce000eb6db22e07ed2f53c4f62a1e0._comment
 create mode 100644 doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_4_5bed42e467859d2310f3da35e55acd38._comment
 create mode 100644 doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_5_5cb379490b0e85c24bff48db8201c7d4._comment
 create mode 100644 doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_6_46eb0f4dcbccea5140a26dca36c6f1d1._comment
 create mode 100644 doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory.mdwn
 create mode 100644 doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_1_0c0a5999a92bf5880f2113177dc67cc2._comment
 create mode 100644 doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_2_c18083d9054f66f0bd51d63452af07eb._comment
 create mode 100644 doc/forum/__34__git_annex_drop__34___freezes_while___34__locking_origin...__34__.mdwn
 create mode 100644 doc/forum/__34__git_annex_drop__34___freezes_while___34__locking_origin...__34__/comment_1_09fbe4362fea8f2a53a1f955b0519019._comment
 create mode 100644 doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error.mdwn
 create mode 100644 doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_1_a1a881d7b0f0c32b1bfdd3bc5ee4dd18._comment
 create mode 100644 doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_3_50d0b68fcf0e239037a5d7950595b1d6._comment
 create mode 100644 doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_3_9bc58c6c2333655870c5e42138f9749e._comment
 create mode 100644 doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_4_958e887dd83b8b636df2d81ade0dbbf1._comment
 create mode 100644 doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_5_24782f9b1012a2935466ac358acea97b._comment
 create mode 100644 doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo.mdwn
 create mode 100644 doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_1_044f1c5e5f7a939315c28087495a8ba8._comment
 create mode 100644 doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_2_e854b93415d5ab80eda8e3be3b145ec2._comment
 create mode 100644 doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_3_95c110500bc54013bc1969c1a9c8f842._comment
 create mode 100644 doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_4_a4fd212cb066cd53d0d66eb09f3b39a8._comment
 create mode 100644 doc/forum/__34__git_annex_sync_--content__34___with_special_remote_of_type___34__directory__34__.mdwn
 create mode 100644 doc/forum/__34__git_annex_sync_--content__34___with_special_remote_of_type___34__directory__34__/comment_1_c51363e109bcc5cd1df40c5d0ec993b3._comment
 create mode 100644 doc/forum/__34__git_annex_sync_--content__34___with_special_remote_of_type___34__directory__34__/comment_2_be52a6d21df4732c9f83463bb5e6f612._comment
 create mode 100644 doc/forum/__34__git_annex_sync__34___synced_after_8_hours.mdwn
 create mode 100644 doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_1_e815ac48a17cc4296473d61e712d95e0._comment
 create mode 100644 doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_2_d13a0af48b8831c81276a0b2c8e25303._comment
 create mode 100644 doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_3_c50b62e5a84b861117a4405c2a2f5cfb._comment
 create mode 100644 doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_4_0051e83196945b97e2f3ed14a58daaea._comment
 create mode 100644 doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_5_26de32ea240621e23717c55866ad9764._comment
 create mode 100644 doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_6_0714eca58513f1059fc246ee152078e7._comment
 create mode 100644 doc/forum/__34__git_annex_unused__34___doesn__39__t_find_unused_files_after_git_history_was_rewritten.mdwn
 create mode 100644 doc/forum/__34__git_annex_unused__34___doesn__39__t_find_unused_files_after_git_history_was_rewritten/comment_1_8f2ced0b9039968f485943e1525dcf6e._comment
 create mode 100644 doc/forum/__34__next_time_Im_online_I_would_like_to_have_file_x_y_z__34__.mdwn
 create mode 100644 doc/forum/__34__next_time_Im_online_I_would_like_to_have_file_x_y_z__34__/comment_1_bfeb1446dee4d2f52ef25fabfb8cc8f6._comment
 create mode 100644 doc/forum/__34__next_time_Im_online_I_would_like_to_have_file_x_y_z__34__/comment_2_e60f2bbc1c058993472fd920edbc75fc._comment
 create mode 100644 doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo.mdwn
 create mode 100644 doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_1_3a5202ef2116ebb5559b6f4d920755fc._comment
 create mode 100644 doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_2_86663eeb75b0477f53c45f26c8e4b051._comment
 create mode 100644 doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_3_c336b2b07cd006d378e5be9639ff17ec._comment
 create mode 100644 doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_4_1339cd27ca2955f30b01ecf4da7d6fe8._comment
 create mode 100644 doc/forum/__34__recovering__34___from_git-annex_usage.mdwn
 create mode 100644 doc/forum/__34__recovering__34___from_git-annex_usage/comment_1_4a2a68ec0d0075f0d2fd7e8c9fac5e75._comment
 create mode 100644 doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__.mdwn
 create mode 100644 doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_1_e50188896df347f1d92e20a52053aa14._comment
 create mode 100644 doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_2_d67793f7c969f64943d1fd54a1208c2b._comment
 create mode 100644 doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_3_3523884833b5fd458a35f898797bf897._comment
 create mode 100644 doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_4_02c32c2521ba1a1eaa19eaca7281f2a6._comment
 create mode 100644 doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__.mdwn
 create mode 100644 doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__/comment_1_b2b7de0bf4494721b02280857474fd6c._comment
 create mode 100644 doc/forum/__39__wget_--mirror__39___like_behaviour.mdwn
 create mode 100644 doc/forum/__39__wget_--mirror__39___like_behaviour/comment_1_9c874a74f25fa06b8e515482b4706032._comment
 create mode 100644 doc/forum/__91__ERROR____93___unknown_archive_format_for_.mat_.tif_and_.json_files.mdwn
 create mode 100644 doc/forum/__91__ERROR____93___unknown_archive_format_for_.mat_.tif_and_.json_files/comment_1_debe9a878896ead4957db288203cae14._comment
 create mode 100644 doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2.mdwn
 create mode 100644 doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2/comment_1_fae6e88115d175239fc55cef4c33fb2c._comment
 create mode 100644 doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2/comment_2_4c7a75638e8717132ccde949018d6008._comment
 create mode 100644 doc/forum/__91__NEED_HELP__93___manual_ssh_remote_setup_with_shared_key.mdwn
 create mode 100644 doc/forum/__91__NEED_HELP__93___manual_ssh_remote_setup_with_shared_key/comment_1_811cab17410ba6e07ae7af3249cd98df._comment
 create mode 100644 doc/forum/__91__Question__93___Mixing_.thin_and_default_repos__63__.mdwn
 create mode 100644 doc/forum/__91__Question__93___Mixing_.thin_and_default_repos__63__/comment_1_41f7bb65b85c3ab54f692e04d26a2891._comment
 create mode 100644 doc/forum/__91__announce__93___metadata_extration_utility.mdwn
 create mode 100644 doc/forum/__96__git_annex_assistant__96___command_replace_all_files_with_pointer_file..mdwn
 create mode 100644 doc/forum/__96__git_annex_copy__96____44___estimate_how_much_data_to_copy.mdwn
 create mode 100644 doc/forum/__96__git_annex_copy__96____44___estimate_how_much_data_to_copy/comment_1_785e4fe097ef2a2d51d84146fc91b2ca._comment
 create mode 100644 doc/forum/__96__git_annex_import__96___from_directory_loses_contents__63__.mdwn
 create mode 100644 doc/forum/__96__git_annex_import__96___from_directory_loses_contents__63__/comment_1_776b5b8099125aad3bc8839d9cc1abeb._comment
 create mode 100644 doc/forum/__96__git_annex_import__96___from_directory_loses_contents__63__/comment_2_c36d32db2b1dcd3cd36c68f2bb726f6f._comment
 create mode 100644 doc/forum/__96__git_annex_sync__96___hangs.mdwn
 create mode 100644 doc/forum/__96__git_annex_sync__96___hangs/comment_1_ffd16cb94b39b93dfb0a2932b70938fc._comment
 create mode 100644 doc/forum/__96__git_annex_sync__96___hangs/comment_2_fad59a54d92ed7cb230f0f365fddb0f4._comment
 create mode 100644 doc/forum/__96__git_annex_sync__96___uses_too_much_space__63__/comment_1_29cd5e9acd78d8ac6b58fe535fee9650._comment
 create mode 100644 doc/forum/__96__git_annex_sync__96___uses_too_much_space__63__/comment_2_7a24236bc511cbfa869aaeb431a003d2._comment
 create mode 100644 doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__.mdwn
 create mode 100644 doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__/comment_1_41d3a4774dd5ada5036247eb6f562392._comment
 create mode 100644 doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__/comment_2_a971d9d85eb7f86d4ea18a71bd0db25d._comment
 create mode 100644 doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring.mdwn
 create mode 100644 doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_1_99975a677f832c410050ba721be6d904._comment
 create mode 100644 doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_2_f4dd76879e2b2bd0da557ee6a539533c._comment
 create mode 100644 doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_3_d437dc44114f59d5717c177831ae0d53._comment
 create mode 100644 doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_dd29ac2b5615ff6f79458a36bce44306._comment
 create mode 100644 doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_5_e07b69bb36cd8aa2c4fd689744f12df1._comment
 create mode 100644 doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_6_f61a390f304e1f6d1e8c4a90cdfbd9b9._comment
 create mode 100644 doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_7_625df33e70f2f959c574d918a706648d._comment
 create mode 100644 doc/forum/_preferred_content__58___lastpresent.mdwn
 create mode 100644 doc/forum/_preferred_content__58___lastpresent/comment_1_7610cd866b256d36646b642eb5f8cae5._comment
 create mode 100644 doc/forum/_preferred_content__58___lastpresent/comment_2_d25666a173b78213d583f029fd166d06._comment
 create mode 100644 doc/forum/add_only_binary_files__63__.mdwn
 create mode 100644 doc/forum/add_only_binary_files__63__/comment_1_7ce3be5bafd62ce5ed78bcd9323039cc._comment
 create mode 100644 doc/forum/adding_files_without_hashing_them.mdwn
 create mode 100644 doc/forum/adding_files_without_hashing_them/comment_1_c3113d7aff6b64a325a32b8b281df605._comment
 create mode 100644 doc/forum/adding_remote_bup_repo_using_ssh.mdwn
 create mode 100644 doc/forum/adding_remote_bup_repo_using_ssh/comment_1_d1ab38bccc415a94fa3906f7f5e823f3._comment
 create mode 100644 doc/forum/adding_remote_bup_repo_using_ssh/comment_2_6698ecb746e6edb25130c8dbceb36fc0._comment
 create mode 100644 doc/forum/adjustedbranchrefresh_ignored__63__.mdwn
 create mode 100644 doc/forum/adjustedbranchrefresh_ignored__63__/comment_1_999bd4a511c7fa39f5455df895c435f3._comment
 create mode 100644 doc/forum/advantages_of_SHA__42___over_WORM.mdwn
 create mode 100644 doc/forum/advantages_of_SHA__42___over_WORM/comment_1_96c354cac4b5ce5cf6664943bc84db1d._comment
 create mode 100644 doc/forum/agent_keep_deleting_local_file.mdwn
 create mode 100644 doc/forum/alternativeto.net___34__Like__34__.mdwn
 create mode 100644 doc/forum/ancient_linux_build_for_arm__63__.mdwn
 create mode 100644 doc/forum/ancient_linux_build_for_arm__63__/comment_1_c4ebfb2136bb4b3e21a52aa23717b22a._comment
 create mode 100644 doc/forum/ancient_linux_build_for_arm__63__/comment_1_f5a7d7e4ac5d9885230d08684416cff4._comment
 create mode 100644 doc/forum/android_-_assistant_-_local_pairing_.mdwn
 create mode 100644 doc/forum/android_binary-only_download.mdwn
 create mode 100644 doc/forum/android_binary-only_download/comment_1_aab206e0bf0bb5ff47c7cc9795f12f92._comment
 create mode 100644 doc/forum/android_installation.mdwn
 create mode 100644 doc/forum/android_installation/comment_1_8908256ecd48d7b5207799aa02102d87._comment
 create mode 100644 doc/forum/android_installation/comment_2_3c2a1e7542993528250ad72079894364._comment
 create mode 100644 doc/forum/annex.largefile_include_from_file.mdwn
 create mode 100644 doc/forum/annex.largefile_include_from_file/comment_1_9016a64a654151ab9a478686382193b4._comment
 create mode 100644 doc/forum/annex.largefile_include_from_file/comment_2_09258e59eab492afc37efeac325c2de1._comment
 create mode 100644 doc/forum/annex.largefile_include_from_file/comment_3_f857505bde5f03d9c17e8df0512c0e99._comment
 create mode 100644 doc/forum/annex.largefile_include_from_file/comment_4_f9c2acc07dad646cd04a51ca85f45502._comment
 create mode 100644 doc/forum/annex.largefile_not_working.mdwn
 create mode 100644 doc/forum/annex.largefile_not_working/comment_1_b2ecb8b60603929bae91c3007817585f._comment
 create mode 100644 doc/forum/annex.largefile_not_working/comment_2_18bc73688897728d0bcae6df1225e6e3._comment
 create mode 100644 doc/forum/annex.largefile_not_working/comment_3_81085c1a526ac804edba689043e58944._comment
 create mode 100644 doc/forum/annex.largefiles__58___two_quesitons.mdwn
 create mode 100644 doc/forum/annex.largefiles__58___two_quesitons/comment_1_75fc6cd2315e9ad6897b94bcc527ddc1._comment
 create mode 100644 doc/forum/annex.largefiles__58___two_quesitons/comment_2_f34cf28c3f8354e6fc055d4dba6ed555._comment
 create mode 100644 doc/forum/annex_merge_creates___34__synced__47____42____34___branches.mdwn
 create mode 100644 doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_1_4667fadb05c594b0a212bf455ee65298._comment
 create mode 100644 doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_2_cb6971a766a28bd8c094d0b986272c65._comment
 create mode 100644 doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_3_1a0384edd20cc379e53fe7d7f650f7e2._comment
 create mode 100644 doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_4_79219e920a6beb4bd3265571f59f51cb._comment
 create mode 100644 doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_5_39009651c3f65e2ecd225e17d157c8d8._comment
 create mode 100644 doc/forum/annexed_file_key_for_web_remote_with_SHA256E_backend.mdwn
 create mode 100644 doc/forum/annexed_file_key_for_web_remote_with_SHA256E_backend/comment_1_d1605a6e3b4d6863f4089218994ce564._comment
 create mode 100644 doc/forum/annexed_file_key_for_web_remote_with_SHA256E_backend/comment_2_d249ff27fa3d9ac3ca32485cdef49930._comment
 create mode 100644 doc/forum/archaeology_of_deleted_files.mdwn
 create mode 100644 doc/forum/archaeology_of_deleted_files/comment_1_48f27df03ec18d2c27cf6b70dcf71dc5._comment
 create mode 100644 doc/forum/archaeology_of_deleted_files/comment_2_c698cd10c8038bac45bd1049506a27c3._comment
 create mode 100644 doc/forum/archival_and_multiple_users.mdwn
 create mode 100644 doc/forum/archival_and_multiple_users/comment_1_fc4ee256f03a7c189d687caf4a34e21e._comment
 create mode 100644 doc/forum/archival_and_multiple_users/comment_2_a96d57d4bb567ac9b0b9167d5b1be011._comment
 create mode 100644 doc/forum/archival_and_multiple_users/comment_3_bd44634b04732ffb91154c61ef9cf828._comment
 create mode 100644 doc/forum/archival_and_multiple_users/comment_4_b89a56a5f1cd641f87925c7a5f74bcec._comment
 create mode 100644 doc/forum/archival_and_multiple_users/comment_5_81293bf5dc8ad4552712c2083fd589c9._comment
 create mode 100644 doc/forum/armhf_binary.mdwn
 create mode 100644 doc/forum/armhf_binary/comment_1_9ca7ff6cb1f5dfc1e5ce8527e7e0a45f._comment
 create mode 100644 doc/forum/armhf_binary/comment_2_743ecf263d1ec1bc4f24e32c0a178f2b._comment
 create mode 100644 doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__.mdwn
 create mode 100644 doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_1_d90d1d599ce557af03c6f0f2ea188212._comment
 create mode 100644 doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_2_58b1af497cab132acb28cb5f9283ec2a._comment
 create mode 100644 doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_3_37d4fd8f69e8066b5aa19454b714e443._comment
 create mode 100644 doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_4_a974e2105774d4f82ad286ff0792ba84._comment
 create mode 100644 doc/forum/assistant_and_archive_folder.mdwn
 create mode 100644 doc/forum/assistant_and_archive_folder/comment_1_ab8808372b886fd1a9f55588d1cef602._comment
 create mode 100644 doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__.mdwn
 create mode 100644 doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_1_70200f871b9df49261f32752a6bb0e67._comment
 create mode 100644 doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_2_173da510b45f0320ae8aa2df9f14ae7b._comment
 create mode 100644 doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_3_1ecea12a4be5ad09013cddb62df6ab20._comment
 create mode 100644 doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_4_af4bc222d1479482bd83952353c97f05._comment
 create mode 100644 doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_5_c1d247fa128c0a0fc899284f5f95002c._comment
 create mode 100644 doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_6_cf877a3502802492cd2bc3012cb2d779._comment
 create mode 100644 doc/forum/assistant_overzealously_moving_stuff_to_other_repos.mdwn
 create mode 100644 doc/forum/assistant_overzealously_moving_stuff_to_other_repos/comment_1_6bd240edf1868615024ff11c24c3d52c._comment
 create mode 100644 doc/forum/assistant_overzealously_moving_stuff_to_other_repos/comment_2_37c5e9a7669b5b94fbadb8792a765316._comment
 create mode 100644 doc/forum/assistant_overzealously_moving_stuff_to_other_repos/comment_3_87aa4c5942929be81ddc1e2795d56f0e._comment
 create mode 100644 doc/forum/assistant_periodical_unused_moves.mdwn
 create mode 100644 doc/forum/assistant_periodical_unused_moves/comment_1_98e30e1f3ca63790c4a8ce11d29634ae._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders.mdwn
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_10_3bf1a44e76855e4fbdd270f97a54bcc5._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_11_b5f9f527597acd8f44f529f85ac305fd._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_12_f38a88b82328ee2d2b411f3df5c3d043._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_13_9b8631b1fb4c9992203efc2d29cfae8d._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_1_e2e49f5278b921f8817ad6ac89a6aaf8._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_2_690a144201e7df5972fd48af8c1d46f7._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_3_49b00584ef4388e130cce63f4f33572f._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_4_53ceb18128de33311d65b39f34b3d9b7._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_5_6db901470af7dc7e1da90839fc08c121._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_6_0ec093a51b3dab465907074beb423848._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_7_83fdf8c0027c860f37716f975838497a._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_8_52237edb2f6cbf9c96f7285ebf6abe6c._comment
 create mode 100644 doc/forum/assistant_to_have_synced_folders/comment_9_a7a5a4c97663211e2fb4337117ec0cb0._comment
 create mode 100644 doc/forum/assistant_without_watch__63__.mdwn
 create mode 100644 doc/forum/assistant_without_watch__63__/comment_1_be1f7c038426e53209a85ae1119269d5._comment
 create mode 100644 doc/forum/assitant__58___special_remote_server___40__needs_ssh_tunnel__41__.mdwn
 create mode 100644 doc/forum/assitant__58___special_remote_server___40__needs_ssh_tunnel__41__/comment_1_817a3ed424e4fb76fcd33295f2953250._comment
 create mode 100644 doc/forum/auto-fetching_annexed_files_on_open__40____41__.mdwn
 create mode 100644 doc/forum/autobuilders_for_git-annex_to_aid_development.mdwn
 create mode 100644 doc/forum/autobuilders_for_git-annex_to_aid_development/comment_1_7e88f815e8d9652ef18ea6d54b118962._comment
 create mode 100644 doc/forum/autobuilders_for_git-annex_to_aid_development/comment_2_fef17a10226af5671495c2929653c337._comment
 create mode 100644 doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes.mdwn
 create mode 100644 doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_1_7d0b479244fefd933193d921adcd897c._comment
 create mode 100644 doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_2_d42222ef94f4d409ac40e523f8211ffc._comment
 create mode 100644 doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_3_dc93ae2a58de5620c440531f43f1237d._comment
 create mode 100644 doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_4_e6bb8a33608908d02eeb921d039f22b9._comment
 create mode 100644 doc/forum/avoiding_copies_across_mutiple_file_systems.mdwn
 create mode 100644 doc/forum/avoiding_copies_across_mutiple_file_systems/comment_1_2ff3e4d2af575b27b14a0a936ad8c52f._comment
 create mode 100644 doc/forum/avoiding_copies_across_mutiple_file_systems/comment_2_96e72de1dc7cefdaa3beedc837639f57._comment
 create mode 100644 doc/forum/avoiding_copies_across_mutiple_file_systems/comment_3_43db664a00fb9956ad392b5dc23565ca._comment
 create mode 100644 doc/forum/avoiding_copies_across_mutiple_file_systems/comment_4_6584f98910d91746203405d57d17b8b0._comment
 create mode 100644 doc/forum/backblaze_s3.mdwn
 create mode 100644 doc/forum/backblaze_s3/comment_1_854390b9a781da82ecb85ad85eecad04._comment
 create mode 100644 doc/forum/backblaze_s3/comment_2_5f1407460b6a56a8e267f8eecf4427aa._comment
 create mode 100644 doc/forum/backblaze_s3/comment_3_55362a91c4592775994999a843e648dc._comment
 create mode 100644 doc/forum/backblaze_s3/comment_4_bd008868a576bf09c6fa188dc8a5907c._comment
 create mode 100644 doc/forum/backblaze_s3/comment_5_474ca16386680fd359474f05bfbd0375._comment
 create mode 100644 doc/forum/backblaze_s3/comment_6_c84400e7dc58ed7e5db8c7883587e8f8._comment
 create mode 100644 doc/forum/bainstorming__58___git_annex_push___38___pull.mdwn
 create mode 100644 doc/forum/bainstorming__58___git_annex_push___38___pull/comment_1_3a0bf74b51586354b7a91f8b43472376._comment
 create mode 100644 doc/forum/bainstorming__58___git_annex_push___38___pull/comment_2_b02ca09914e788393c01196686f95831._comment
 create mode 100644 doc/forum/balance_git_annex_remotes.mdwn
 create mode 100644 doc/forum/bash_completion.mdwn
 create mode 100644 doc/forum/bash_completion/comment_1_5c42c0c8e7fc3224bf5406880f9fd0c4._comment
 create mode 100644 doc/forum/bash_completion/comment_2_6cbe3c825db99bf9188a0de8bb937d5b._comment
 create mode 100644 doc/forum/bash_completion/comment_3_948c40f1e46ca220d61365aebcd4f6d7._comment
 create mode 100644 doc/forum/bash_completion/comment_4_dbae348b230b780cda91ed8576b8f9fa._comment
 create mode 100644 doc/forum/bash_completion/comment_5_d45570fd750ae8d69dedc3edeef0cc10._comment
 create mode 100644 doc/forum/bash_completion/comment_6_2dbfa336ad8957ff0cafd8301ca1150f._comment
 create mode 100644 doc/forum/bash_completion/comment_7_2fd198746dc7351fe957e7a8150fcb89._comment
 create mode 100644 doc/forum/bash_completion/comment_8_7802f4bd08dddd24ac9d19ee7847735f._comment
 create mode 100644 doc/forum/basic_usage_questions.mdwn
 create mode 100644 doc/forum/basic_usage_questions/comment_1_c2a5fedc24f8c301d9042999a0371d9f._comment
 create mode 100644 doc/forum/basic_usage_questions/comment_2_67d047a107b20874cb71ba311681e181._comment
 create mode 100644 doc/forum/basic_usage_questions/comment_3_94b4efa49efbee741c051227b3204562._comment
 create mode 100644 doc/forum/batch_check_on_remote_when_using_copy.mdwn
 create mode 100644 doc/forum/benefit_of_splitting_a_repository.mdwn
 create mode 100644 doc/forum/benefit_of_splitting_a_repository/comment_1_93a86cb03b66e7ab5dd7146e7b86c9e8._comment
 create mode 100644 doc/forum/benefit_of_splitting_a_repository/comment_2_4e2fed247298d620fee7be883a1e86a6._comment
 create mode 100644 doc/forum/best_practices_for_importing_photos__63__.mdwn
 create mode 100644 doc/forum/best_practices_for_importing_photos__63__/comment_1_37f0ae4b552ec2a4a144ddcdc17c8453._comment
 create mode 100644 doc/forum/best_practices_for_importing_photos__63__/comment_2_7f96f0fe0fc073321bd7c5bbd9048425._comment
 create mode 100644 doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system.mdwn
 create mode 100644 doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system/comment_1_50b0f3b42c5c7185c51451af80749718._comment
 create mode 100644 doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system/comment_2_e3e30ca123cd840288655c25b688cd66._comment
 create mode 100644 doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system/comment_3_00418ada32a4d93dfd3334686e391a23._comment
 create mode 100644 doc/forum/big_overhead.mdwn
 create mode 100644 doc/forum/big_overhead/comment_10_d5f4e353e7f711d8c38cdcc222339bca._comment
 create mode 100644 doc/forum/big_overhead/comment_11_cbf25217e4149f2cfad4e2bf94f2b4ca._comment
 create mode 100644 doc/forum/big_overhead/comment_12_475d5af95adcfcd3a51e10f270205eb7._comment
 create mode 100644 doc/forum/big_overhead/comment_13_1c8cc992f04fc63179094c494bd25025._comment
 create mode 100644 doc/forum/big_overhead/comment_14_cbfb3d557915258e72c65a4e84df77a9._comment
 create mode 100644 doc/forum/big_overhead/comment_15_b973529bae549bcbaaae792f0403989b._comment
 create mode 100644 doc/forum/big_overhead/comment_1_0c184520c30a89bd2604ab7c0eb7ac45._comment
 create mode 100644 doc/forum/big_overhead/comment_2_13a017c6c84511894ded2d89d86eb541._comment
 create mode 100644 doc/forum/big_overhead/comment_3_b4761cacc02396b5bdf34bcf3457cb91._comment
 create mode 100644 doc/forum/big_overhead/comment_4_633f8538f368220eaca82b8bbfe9b49d._comment
 create mode 100644 doc/forum/big_overhead/comment_5_599092b8d4f1fc8f378796328ef42931._comment
 create mode 100644 doc/forum/big_overhead/comment_6_adb4b4e7eb4dac7760f3425bae6cbbc2._comment
 create mode 100644 doc/forum/big_overhead/comment_7_a762eb55addf81c1c5350c7968598d0f._comment
 create mode 100644 doc/forum/big_overhead/comment_8_4a66f57c6c0bdc6123618cb69a719be5._comment
 create mode 100644 doc/forum/big_overhead/comment_9_5fa681ea0d6bd0dcac7142d40df9d54f._comment
 create mode 100644 doc/forum/browse_files_on_server.mdwn
 create mode 100644 doc/forum/browse_files_on_server/comment_1_5023c6f9f4a8a7724ff057076f64ec1d._comment
 create mode 100644 doc/forum/browse_files_on_server/comment_2_67096b34041fed07bbf1d0cb243e1efc._comment
 create mode 100644 doc/forum/browse_files_on_server/comment_3_148f1aa0d46dcf51b855b6fb18b6a549._comment
 create mode 100644 doc/forum/btsync_equivalent__63__.mdwn
 create mode 100644 doc/forum/btsync_equivalent__63__/comment_1_6bfdc6f595a8aa8979a7c2a10925812f._comment
 create mode 100644 doc/forum/bug-fix_release.mdwn
 create mode 100644 doc/forum/bug-fix_release/comment_1_c3c23f4c0a8bdea8619479656af63af3._comment
 create mode 100644 doc/forum/build_from_source_on_Linux_fails___40__out_of_memory__41__.mdwn
 create mode 100644 doc/forum/build_from_source_on_Linux_fails___40__out_of_memory__41__/comment_1_cd004b531ae384e134e16600b64473e0._comment
 create mode 100644 doc/forum/build_questions__58___Flag_HttpClientRestricted.mdwn
 create mode 100644 doc/forum/build_questions__58___Flag_HttpClientRestricted/comment_1_67ab203f26e7b446fe96e01ec3706540._comment
 create mode 100644 doc/forum/building_from_source__58___dependency_versions.mdwn
 create mode 100644 doc/forum/building_from_source__58___dependency_versions/comment_1_442b37aa559512eb85695f0a9e3b8197._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source.mdwn
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_10_ae23bbd2da15e8ae115b4030994502cc._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_11_5c580c8fce388b9808c2afc778da853b._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_12_9b0a7c108855d9db63092dd5f93bc5e5._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_13_27f987a16d931a02f5a4ab3f80bf327a._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_14_44606ec8db82f75f37aabcd7df5c24bb._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_1_204eda1dc4b935ee357a6675ee14317b._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_2_ff968f9f9d6644b9e8607c8e76f45c1e._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_3_e94f70e19b77c9ad6b6349fa65dcc60f._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_4_0b7824acaf031d8ba69700674c82f472._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_5_bfec6091cc312a9d4c87163b845454f6._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_6_044da90b6cc18534de74ee5d38d6becb._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_7_5187f5f40bc47b5b079cfdd3eb5f1fc3._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_8_eb0c565043164c17b2a6d2c6361b6e35._comment
 create mode 100644 doc/forum/building_the_standalone_distribution_from_source/comment_9_edb3a79772f81dd3ffd00b81e79f67e5._comment
 create mode 100644 doc/forum/bup_backups_to_amazon_cloud_drive.mdwn
 create mode 100644 doc/forum/bup_backups_to_amazon_cloud_drive/comment_1_e8f6fdc70cedd5482da6a185c6c6b9b9._comment
 create mode 100644 doc/forum/cabal_install_fails_on_uuid.mdwn
 create mode 100644 doc/forum/cabal_install_fails_on_uuid/comment_1_2a3963e21bc7ff526124b902cb0b6ad2._comment
 create mode 100644 doc/forum/cabal_install_fails_on_uuid/comment_2_1609525998e2b36c04d67f4d988139c0._comment
 create mode 100644 doc/forum/can_I_only_add_my_own_files__63__.mdwn
 create mode 100644 doc/forum/can_I_only_add_my_own_files__63__/comment_1_767d647af9d0345f337338d6319071fa._comment
 create mode 100644 doc/forum/can_I_only_add_my_own_files__63__/comment_2_0c3306ffb38b97b54e1e0436d12c1876._comment
 create mode 100644 doc/forum/can__39__t_sync_content.mdwn
 create mode 100644 doc/forum/can__39__t_sync_content/comment_1_0d6c6f5967c91e7dda55fbf716dd88a0._comment
 create mode 100644 doc/forum/can__39__t_sync_content/comment_2_e9c476eeac7427950573c07313a8a175._comment
 create mode 100644 doc/forum/can_git-annex_replace_ddm__63__.mdwn
 create mode 100644 doc/forum/can_git-annex_replace_ddm__63__/comment_1_aa05008dfe800474ff76678a400099e1._comment
 create mode 100644 doc/forum/can_git-annex_replace_ddm__63__/comment_2_008554306dd082d7f543baf283510e92._comment
 create mode 100644 doc/forum/can_git-annex_replace_ddm__63__/comment_3_4c69097fe2ee81359655e59a03a9bb8d._comment
 create mode 100644 doc/forum/canceling_wrong_repository_merge.mdwn
 create mode 100644 doc/forum/canceling_wrong_repository_merge/comment_1_7230f2be014afcb40514ef521d53c170._comment
 create mode 100644 doc/forum/canceling_wrong_repository_merge/comment_2_87aabff41a1c6aec773b8f52ead51105._comment
 create mode 100644 doc/forum/canceling_wrong_repository_merge/comment_3_d6e45d7e4f4bdf0a08ab91a08e0c1be6._comment
 create mode 100644 doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX.mdwn
 create mode 100644 doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_1_21f0101447623f5a0cf9e72c3ff463bb._comment
 create mode 100644 doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_2_6234ca64bd03a0e15efbe8f5c204338a._comment
 create mode 100644 doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_3_5ac2b520a907e232984eb513ce088054._comment
 create mode 100644 doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_4_183dd1c29f66539193e7c0b73f329430._comment
 create mode 100644 doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_5_c920d04ffe332caed9d223fa0ac42746._comment
 create mode 100644 doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_6_7a3cf0853a8ec7b996e19b5e80145d21._comment
 create mode 100644 doc/forum/cannot_sync___39__unused__39___files.mdwn
 create mode 100644 doc/forum/cannot_sync___39__unused__39___files/comment_1_d7c88a5cdf8ce8206795ff7ab215d372._comment
 create mode 100644 doc/forum/central_non-bare_and_git_push.mdwn
 create mode 100644 doc/forum/central_non-bare_and_git_push/comment_1_76d0c73c8985e860eb86333c63be6340._comment
 create mode 100644 doc/forum/checkout_view_to_directory_outside_of_annex.mdwn
 create mode 100644 doc/forum/checkout_view_to_directory_outside_of_annex/comment_1_a31a501bdc28eabc60588502f7219e50._comment
 create mode 100644 doc/forum/checkout_view_to_directory_outside_of_annex/comment_2_b4abbb048ebcd3c4b59d20e103948fd8._comment
 create mode 100644 doc/forum/checkout_view_to_directory_outside_of_annex/comment_3_2139407a3a556023a2458148a4a2c009._comment
 create mode 100644 doc/forum/clear_box.com_repository.mdwn
 create mode 100644 doc/forum/clear_box.com_repository/comment_1_2e839d8f974269c80a9fca183712350f._comment
 create mode 100644 doc/forum/clear_box.com_repository/comment_2_8f9c7248a148a24ae2aba39c4a79a6d1._comment
 create mode 100644 doc/forum/clear_box.com_repository/comment_3_f64ad21e5abfbf4e1f925b3d651bdba3._comment
 create mode 100644 doc/forum/clear_box.com_repository/comment_4_f8c06ac9b23b51cf18d362c260fc47a9._comment
 create mode 100644 doc/forum/clear_box.com_repository/comment_5_61d401b29322802cb25896503f3e6514._comment
 create mode 100644 doc/forum/client_repositories_setup_problem.mdwn
 create mode 100644 doc/forum/client_repositories_setup_problem/comment_1_be53f90b66de690b39f487d394866a66._comment
 create mode 100644 doc/forum/client_repositories_setup_problem/comment_2_f9660534c3f3346f322de57c2da0eb27._comment
 create mode 100644 doc/forum/cloud_services_to_support.mdwn
 create mode 100644 doc/forum/cloudcmd.mdwn
 create mode 100644 doc/forum/commit_current_workdir_state_in_direct_mode.mdwn
 create mode 100644 doc/forum/commit_current_workdir_state_in_direct_mode/comment_1_748481ff00374f570284bd4571584874._comment
 create mode 100644 doc/forum/compiling_on_MacOS.mdwn
 create mode 100644 doc/forum/compiling_on_MacOS/comment_1_143ae6d4f2704d4ab74e110a2d7a3c82._comment
 create mode 100644 doc/forum/comprehension_question__58___repository_vs._working_copy_in_direct_mode.mdwn
 create mode 100644 doc/forum/comprehension_question__58___repository_vs._working_copy_in_direct_mode/comment_1_a6b4db0cefa439f72b97089d48dfacbd._comment
 create mode 100644 doc/forum/conda-forge_build_problem.mdwn
 create mode 100644 doc/forum/conda-forge_build_problem/comment_1_22e01f5f110593796b539fc7630ccb3c._comment
 create mode 100644 doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__.mdwn
 create mode 100644 doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__/comment_1_ce9d638b8a07375a79a9ee04b02d6e95._comment
 create mode 100644 doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__/comment_2_11b9261bc5c32d3e36357afc021ac4e1._comment
 create mode 100644 doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__/comment_3_07e6f767e38d9812b176ee3fdb00adf0._comment
 create mode 100644 doc/forum/conflict_with_git-crypt.mdwn
 create mode 100644 doc/forum/conflict_with_git-crypt/comment_1_b81a3cd99ff04e21ef520a497c0bd46a._comment
 create mode 100644 doc/forum/conflict_with_git-crypt/comment_2_cda648fcc5f213af06fe98428910f561._comment
 create mode 100644 doc/forum/conflict_with_git-crypt/comment_3_6e7ea4ed29e6b526c27979988d09d883._comment
 create mode 100644 doc/forum/confused_about_external_drives.mdwn
 create mode 100644 doc/forum/confused_about_external_drives/comment_1_8340e5ff17a4846b41789e4966fed70c._comment
 create mode 100644 doc/forum/confused_about_external_drives/comment_2_ad10bd0ec14c16bcad089b3ebe64580e._comment
 create mode 100644 doc/forum/confusion_with_remotes__44___map.mdwn
 create mode 100644 doc/forum/confusion_with_remotes__44___map/comment_1_a38ded23b7f288292a843abcb1a56f38._comment
 create mode 100644 doc/forum/confusion_with_remotes__44___map/comment_2_cd1c98b1276444e859a22c3dbd6f2a79._comment
 create mode 100644 doc/forum/confusion_with_remotes__44___map/comment_3_18531754089c991b6caefc57a5c17fe9._comment
 create mode 100644 doc/forum/confusion_with_remotes__44___map/comment_4_3b89b6d1518267fcbc050c9de038b9ca._comment
 create mode 100644 doc/forum/confusion_with_remotes__44___map/comment_5_27801584325d259fa490f67273f2ff71._comment
 create mode 100644 doc/forum/confusion_with_remotes__44___map/comment_6_496b0d9b86869bbac3a1356d53a3dda4._comment
 create mode 100644 doc/forum/confusion_with_remotes__44___map/comment_7_9a456f61f956a3d5e81e723d5a90794c._comment
 create mode 100644 doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts.mdwn
 create mode 100644 doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_1_48be720ff150112f30273960f677056c._comment
 create mode 100644 doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_2_c091e5a668b15aca7b2faa955beab403._comment
 create mode 100644 doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_2_d8dddf7b565273390ce4ba1c22dabf46._comment
 create mode 100644 doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_4_c019c5b4d1c2a7941aed8791b6749f5b._comment
 create mode 100644 doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo.mdwn
 create mode 100644 doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo/comment_1_e08eb54547bfd4dbfcc79a5a4a529647._comment
 create mode 100644 doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo/comment_2_85946916ac9c2a19c0d65e2b1a3e5832._comment
 create mode 100644 doc/forum/copy_--auto_copies_already_synced_files.mdwn
 create mode 100644 doc/forum/copy_--auto_copies_already_synced_files/comment_1_cc5e2e7630a33b73d1eb92eebe254cea._comment
 create mode 100644 doc/forum/copy_--auto_copies_already_synced_files/comment_2_3cfd11d8199a4d5e442d207a1edb38e0._comment
 create mode 100644 doc/forum/copy_and_move__63__.mdwn
 create mode 100644 doc/forum/copy_and_move__63__/comment_1_a24b1ab4608fcf8129c9890a5ae9e943._comment
 create mode 100644 doc/forum/copy_symlinks.mdwn
 create mode 100644 doc/forum/copy_symlinks/comment_1_950de173a042a7671a43adbab02e0669._comment
 create mode 100644 doc/forum/copy_symlinks/comment_2_198f3e9db08ebcdb7ec36b76cc1d9473._comment
 create mode 100644 doc/forum/copying_annex_between_remotes_manually__63__.mdwn
 create mode 100644 doc/forum/copying_annex_between_remotes_manually__63__/comment_1_c13a0cded3a5fee06106f101f122eb33._comment
 create mode 100644 doc/forum/copying_annex_between_remotes_manually__63__/comment_2_1237297cfb596d59a48c8359d43a3928._comment
 create mode 100644 doc/forum/copying_annex_between_remotes_manually__63__/comment_3_875474a913d23823e3866cca27cfa3ac._comment
 create mode 100644 doc/forum/correct_way_to_add_two_preexisting_datasets.mdwn
 create mode 100644 doc/forum/correct_way_to_add_two_preexisting_datasets/comment_1_c5c3ff25c9f5e34db222b5f4ae58b093._comment
 create mode 100644 doc/forum/correct_way_to_add_two_preexisting_datasets/comment_2_ee3ecc86990ac5a8d0c4fdfb482a7594._comment
 create mode 100644 doc/forum/correct_way_to_add_two_preexisting_datasets/comment_3_e29bf8b848da04c761dc601ac979ac14._comment
 create mode 100644 doc/forum/could_not_read_from_remote_repository.mdwn
 create mode 100644 doc/forum/could_not_read_from_remote_repository/comment_1_27d4d1556a80c06505ed3d8a9422d082._comment
 create mode 100644 doc/forum/could_not_read_from_remote_repository/comment_2_cf7d5e231675921c3d98faab3613c92f._comment
 create mode 100644 doc/forum/custom_URLs___40__use_case__58___dnanexus__41__.mdwn
 create mode 100644 doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_1_55c2a5c932ccc5a2a49a54239cfba139._comment
 create mode 100644 doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_2_db80224d61ca549557af558e9a5f099a._comment
 create mode 100644 doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_3_8b69aa113bc35a042c90beddf8b0f3a9._comment
 create mode 100644 doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_4_94e2fbb04c553b2c8c7992541e634017._comment
 create mode 100644 doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_5_33a833e1037df7ce0fa55876e4154250._comment
 create mode 100644 doc/forum/dangling_blobs.mdwn
 create mode 100644 doc/forum/dangling_blobs/comment_1_120681851a595909e19afcc0334383ec._comment
 create mode 100644 doc/forum/dbus_and_magicmime_build_flags.mdwn
 create mode 100644 doc/forum/dbus_and_magicmime_build_flags/comment_1_9d2ae829a085582c69dcf994c26f5a0c._comment
 create mode 100644 doc/forum/dbus_and_magicmime_build_flags/comment_2_5421641e133cdadd0be5587b882ed3e5._comment
 create mode 100644 doc/forum/default_repo_version_is_still_5__63__.mdwn
 create mode 100644 doc/forum/default_repo_version_is_still_5__63__/comment_1_5f63f10cf79ef8ca33214ceaefd1271e._comment
 create mode 100644 doc/forum/deploy.mdwn
 create mode 100644 doc/forum/deploy/comment_1_bd9855cc19f0f49620258564845f1f77._comment
 create mode 100644 doc/forum/dev_machine_-__62___NAS_-__62___cloud.mdwn
 create mode 100644 doc/forum/dev_machine_-__62___NAS_-__62___cloud/comment_1_f77818a766f2b41d13ced2bcf4447de0._comment
 create mode 100644 doc/forum/differenc_in_webapp_icons__63__.mdwn
 create mode 100644 doc/forum/differenc_in_webapp_icons__63__/comment_1_c38e2692b13a1b76777bf88312a03966._comment
 create mode 100644 doc/forum/difference_between_full_backup_and_number_of_copies__63__.mdwn
 create mode 100644 doc/forum/difference_between_full_backup_and_number_of_copies__63__/comment_1_df1850059a7a3006db7cb5c588dac3d7._comment
 create mode 100644 doc/forum/difference_between_uninit_and_unlock.mdwn
 create mode 100644 doc/forum/difference_between_uninit_and_unlock/comment_1_6b89cffc10650c087dbbfbdd3e099b5f._comment
 create mode 100644 doc/forum/distributed_borg.mdwn
 create mode 100644 doc/forum/distributed_borg/comment_1_133d5adb83e9df38c513e17d128486d1._comment
 create mode 100644 doc/forum/distributed_borg/comment_2_1dcf100a28991c664681d78ed4c12e39._comment
 create mode 100644 doc/forum/distributed_borg/comment_3_f56ac8a714facc8aafb60d3da815021b._comment
 create mode 100644 doc/forum/distributed_borg/comment_4_cf173923509ec826a1962f9a934b5a64._comment
 create mode 100644 doc/forum/do_not_use_git-annex_inside_your_Dropbox.mdwn
 create mode 100644 doc/forum/do_not_use_git-annex_inside_your_Dropbox/comment_1_5a1dc9da6e6861829e321446ec7991ee._comment
 create mode 100644 doc/forum/does_git-annex_parallelize_different_remotes__63__.mdwn
 create mode 100644 doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_1_764f43b51a075a8c94b433eda0cff946._comment
 create mode 100644 doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_2_dff46561e15ba5f386dc9cecb9c88e20._comment
 create mode 100644 doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_3_47269e2c40c5ce27ca197ddfd5ac85c3._comment
 create mode 100644 doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_4_b9444184ab653718fca9df5c2068ad3c._comment
 create mode 100644 doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_5_5098db1fad3290cba49ea1c1163cc168._comment
 create mode 100644 doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_6_ac6b01d2ff9dfe6060be5956d5adb632._comment
 create mode 100644 doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_7_101543247268097f7535660efe0d39d8._comment
 create mode 100644 doc/forum/done_bugs_are_missing.mdwn
 create mode 100644 doc/forum/done_bugs_are_missing/comment_1_400c15824ec84bd67583102a023edcf8._comment
 create mode 100644 doc/forum/done_bugs_are_missing/comment_2_1fdcfb4ed807e424fe73f134c4ad9526._comment
 create mode 100644 doc/forum/done_bugs_are_missing/comment_3_6eb74e1bcf6b062b61b25e59b0b1ddc6._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp.mdwn
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_10_14b74438bb1e3e02cff7926d774ba09a._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_11_b1f717342c1c8ea42a451caa2d936622._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_12_e2c6ad99333018c8c46e736da416b8ef._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_13_35ae9d6bcb8d9762a92e3564b686ed72._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_14_92b1e8956513dbf52da31cec3f58e2c5._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_15_839e29d41de9dcc8f01dfdc585a51d12._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_1_1a35ef8cb89e0cd392f6e9fcee1fb92c._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_2_f4cc36c493d7c20fbaf949edd38e1252._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_3_69268f8aa29e807a56248f1fac86aa41._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_4_0ffb0c803c232a1587f956f16113aeb7._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_5_c303e28825241733d69fca74f2015fc6._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_6_3f0b376e37bd092b8d46c46bb1940e35._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_7_615641b3dd176d4b3a5bbfb521098e38._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_8_4600fa9234a787004ea0e0dbb36184b9._comment
 create mode 100644 doc/forum/dot_git_slash_annex_slash_tmp/comment_9_4f5cd0d0d4db0479c1ad86ffdc5ae434._comment
 create mode 100644 doc/forum/download_from_multiple_remotes_in_parallel.mdwn
 create mode 100644 doc/forum/download_from_multiple_remotes_in_parallel/comment_1_81e2612ddaffefec81455e9ff706c4c9._comment
 create mode 100644 doc/forum/downloading_from_moodle.mdwn
 create mode 100644 doc/forum/downloading_from_moodle/comment_1_3f677130d268de4288e87cfa86ea055c._comment
 create mode 100644 doc/forum/downloading_from_moodle/comment_2_dcef60ec144f123dadd165fb602ab950._comment
 create mode 100644 doc/forum/downloading_from_moodle/comment_3_d3efb767bf9b20f96242dcf64817bd4b._comment
 create mode 100644 doc/forum/downloading_mp4_by_default_with_importfeed.mdwn
 create mode 100644 doc/forum/downloading_mp4_by_default_with_importfeed/comment_1_c9e5a3700764faa33d2c68de6a8236dc._comment
 create mode 100644 doc/forum/downloading_mp4_by_default_with_importfeed/comment_2_ade70b45f49eb3eaf127ba7b2bd37900._comment
 create mode 100644 doc/forum/drop__47__whereis_not_showing_gcrypted_special_ssh_remote.mdwn
 create mode 100644 doc/forum/drop__47__whereis_not_showing_gcrypted_special_ssh_remote/comment_1_968bc2be595008790e9b93d82342714c._comment
 create mode 100644 doc/forum/drop__47__whereis_not_showing_gcrypted_special_ssh_remote/comment_2_2c14d88e55ea7d4edc90ce0091025f32._comment
 create mode 100644 doc/forum/drop_old_versions_of_a_file.mdwn
 create mode 100644 doc/forum/drop_old_versions_of_a_file/comment_1_799a413248fb8f98efbf226b1bc4300d._comment
 create mode 100644 doc/forum/dropped_files_keep_coming_back.mdwn
 create mode 100644 doc/forum/dropped_files_keep_coming_back/comment_1_84655c21f59b3904c950ddccccde53d8._comment
 create mode 100644 doc/forum/dropped_files_keep_coming_back/comment_2_223550574fa69effabe57c4bf257e54b._comment
 create mode 100644 doc/forum/dropped_files_keep_coming_back/comment_3_1a2ee19bfb3d56a2e2641dbcd89d8be2._comment
 create mode 100644 doc/forum/dropped_files_keep_coming_back/comment_4_02a6e3591acfa410ed7c7917dc573663._comment
 create mode 100644 doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__.mdwn
 create mode 100644 doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__/comment_1_bb6d749b758b17178227929bf7327fe1._comment
 create mode 100644 doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__/comment_2_d834df30633f7d5569797ee818cf38c3._comment
 create mode 100644 doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__/comment_3_1e02eff33c9fa7bea03aa6d58b910175._comment
 create mode 100644 doc/forum/duplicates_with_suffixes_differing_only_in_case.mdwn
 create mode 100644 doc/forum/duplicates_with_suffixes_differing_only_in_case/comment_1_0c1bb4347902054ec97ef86eb903f060._comment
 create mode 100644 doc/forum/duplicates_with_suffixes_differing_only_in_case/comment_2_62bb4be1b31bd64a046763f68a2953ce._comment
 create mode 100644 doc/forum/duplicates_with_suffixes_differing_only_in_case/comment_3_99a2e752c75e5ad2ea36254627be8d18._comment
 create mode 100644 doc/forum/empty_directory_handling.mdwn
 create mode 100644 doc/forum/empty_directory_handling/comment_1_34ac97b9337b6230ed8a4748203fe543._comment
 create mode 100644 doc/forum/empty_directory_handling/comment_2_73a39e28d5a09ac342cb4195d263d91e._comment
 create mode 100644 doc/forum/enabling_git-annex-diffdriver_for_gitk.mdwn
 create mode 100644 doc/forum/endless_password_prompt_loop.mdwn
 create mode 100644 doc/forum/endless_password_prompt_loop/comment_1_cceba12ed25cd671c7cee5a28631163e._comment
 create mode 100644 doc/forum/endless_password_prompt_loop/comment_2_f0cb86b45eb289f35197c43f83660a8f._comment
 create mode 100644 doc/forum/endless_password_prompt_loop/comment_3_eb1dce6d9af6e19cf77df63da1a68425._comment
 create mode 100644 doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS.mdwn
 create mode 100644 doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS/comment_1_aa740c16099f24fd8a067ef23435d0d4._comment
 create mode 100644 doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS/comment_2_5bcd8554e33a716208ca205d7c0467df._comment
 create mode 100644 doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS/comment_3_c3bca82915cc8bd35d3f41fc95436a18._comment
 create mode 100644 doc/forum/error__58___refs__47__heads__47__git-annex_does_not_point_to_a_valid_object__33__.mdwn
 create mode 100644 doc/forum/error__58___refs__47__heads__47__git-annex_does_not_point_to_a_valid_object__33__/comment_1_d370b044da3bfebf9e4c90ce1e243587._comment
 create mode 100644 doc/forum/error_in_installation_of_base-4.5.0.0.mdwn
 create mode 100644 doc/forum/error_in_installation_of_base-4.5.0.0/comment_1_0b2f79c014e0dd9badd52b8b6aa47e0c._comment
 create mode 100644 doc/forum/error_in_installation_of_base-4.5.0.0/comment_2_3badd64e48fbb174cd7de1ac9589bedf._comment
 create mode 100644 doc/forum/error_in_installation_of_base-4.5.0.0/comment_3_d8190061ac1c683a7b699cf42e9db694._comment
 create mode 100644 doc/forum/error_in_installation_of_base-4.5.0.0/comment_4_49a4fcd2dc4f97d4055b5051feea5e3b._comment
 create mode 100644 doc/forum/error_setting_up_centralized_server_on_OSX_-_failed_to_get_annex.uuid_configuration_of_repository_origin.mdwn
 create mode 100644 doc/forum/error_setting_up_centralized_server_on_OSX_-_failed_to_get_annex.uuid_configuration_of_repository_origin/comment_1_943ff286824bd59a164b161553d65698._comment
 create mode 100644 doc/forum/example_of_massively_disconnected_operation.mdwn
 create mode 100644 doc/forum/exclude_files_from_annex.mdwn
 create mode 100644 doc/forum/exclude_files_from_annex/comment_1_82e7de5e631bae3b347815586274a936._comment
 create mode 100644 doc/forum/exclude_files_from_annex/comment_2_03d4599fdceb3dff184eed82824674bc._comment
 create mode 100644 doc/forum/expire_files__44___move_to_other_hosts.mdwn
 create mode 100644 doc/forum/expire_files__44___move_to_other_hosts/comment_1_ddcc2a00be1ae96a352d75a443458bcf._comment
 create mode 100644 doc/forum/expire_files__44___move_to_other_hosts/comment_2_7a4c3858c5eae409d04de3f9da43b57e._comment
 create mode 100644 doc/forum/export_single_file.mdwn
 create mode 100644 doc/forum/export_single_file/comment_1_36d97e3c3f07411f3d367da546759ea5._comment
 create mode 100644 doc/forum/export_single_file/comment_2_ec3d3fb7beb3312571ffa471c39aaf95._comment
 create mode 100644 doc/forum/export_single_file/comment_3_0761201bf68e1086d263776eb953c1e1._comment
 create mode 100644 doc/forum/export_tracking_not_enabled_when_branch_is_set.mdwn
 create mode 100644 doc/forum/export_tracking_not_enabled_when_branch_is_set/comment_1_c007c52d0a038c26e4f8fc50a2d23a18._comment
 create mode 100644 doc/forum/export_tracking_not_enabled_when_branch_is_set/comment_2_12c90792bd8c0c37bc53806843583733._comment
 create mode 100644 doc/forum/exporting_annexed_files.mdwn
 create mode 100644 doc/forum/exporting_annexed_files/comment_1_e08e4c79588e17fb2f1cdf53d9fab7ea._comment
 create mode 100644 doc/forum/exporting_annexed_files/comment_2_15dc3024417b5b2ff3544a08beacab34._comment
 create mode 100644 doc/forum/exporting_annexed_files/comment_3_86f0e0f767a84a0f583e121d36cb7d48._comment
 create mode 100644 doc/forum/exporttree__61__yes_always_untrusted__63__.mdwn
 create mode 100644 doc/forum/exporttree__61__yes_always_untrusted__63__/comment_1_fb579729238a36d5c3369ed07dd772ae._comment
 create mode 100644 doc/forum/external_special_remote_protocol_and_threads.mdwn
 create mode 100644 doc/forum/external_special_remote_protocol_and_threads/comment_1_f29c2b0f0f5e349e36eb47176e33498f._comment
 create mode 100644 doc/forum/external_special_remote_protocol_and_threads/comment_2_df97223aad2c8c95ce109944d64a59fe._comment
 create mode 100644 doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__.mdwn
 create mode 100644 doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__/comment_1_990197bf01351dc1ccbe1940d5084adb._comment
 create mode 100644 doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__/comment_2_3bb1d21b7f0d0bd6d59190ae9d246d46._comment
 create mode 100644 doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__/comment_3_692f268218690437138ae0540c879425._comment
 create mode 100644 doc/forum/failed_to_push_anonymously.mdwn
 create mode 100644 doc/forum/failed_to_push_anonymously/comment_1_bdf93b0e9fb109b7a4052a99110f6079._comment
 create mode 100644 doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks.mdwn
 create mode 100644 doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks/comment_1_3167052f67706797b00423a50f2ae7f1._comment
 create mode 100644 doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks/comment_2_0082ac7a148db69293a4e37fa6d6c891._comment
 create mode 100644 doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks/comment_2_6411aa3e6f5c1515845f3223bbcdabf1._comment
 create mode 100644 doc/forum/faking_location_information.mdwn
 create mode 100644 doc/forum/fatal_-_corrupt_loose_object.mdwn
 create mode 100644 doc/forum/fatal_-_corrupt_loose_object/comment_1_7b0da4185861fd5ff2a7345410678f82._comment
 create mode 100644 doc/forum/fatal__58___Not_a_valid_object_name_repository.mdwn
 create mode 100644 doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_1_48f1ee21d24a99723ff455c0c9c96629._comment
 create mode 100644 doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_2_eef07cc389400c38b666da4e1adc255e._comment
 create mode 100644 doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_3_2760c9b8b755e1ed5e01b98ea3b99177._comment
 create mode 100644 doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_4_344561606daab9bc1a05ec3b857b2d62._comment
 create mode 100644 doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory.mdwn
 create mode 100644 doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_1_d98a155fa01d10ecff9058d79290156d._comment
 create mode 100644 doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_2_3b9ea7a1254ac5b50a5ab59cd331ec3f._comment
 create mode 100644 doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_3_5ee300034819c5825c676cd7e3af659f._comment
 create mode 100644 doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment
 create mode 100644 doc/forum/fatal__58___export-tree_object_is_unavailable.mdwn
 create mode 100644 doc/forum/fatal__58___export-tree_object_is_unavailable/comment_1_e101855120be3639fce9f3725737b189._comment
 create mode 100644 doc/forum/files_being_dropped_undesirably.mdwn
 create mode 100644 doc/forum/files_being_dropped_undesirably/comment_1_d03f8ed7d3f3da58612bf238c1790fb4._comment
 create mode 100644 doc/forum/files_being_dropped_undesirably/comment_2_7d885abebfec789348639494b1bb1829._comment
 create mode 100644 doc/forum/files_being_dropped_undesirably/comment_3_7c70b58f89408304055eefb1b166ef2e._comment
 create mode 100644 doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__.mdwn
 create mode 100644 doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_1_4d07f87b433228fdaebce2805fc64492._comment
 create mode 100644 doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_2_97d24db6027270b9f2d759e98d5f428f._comment
 create mode 100644 doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_3_e61107dd83efecc3266217acad9c943b._comment
 create mode 100644 doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_4_362370f02ea77addf9efaed9cb4b433a._comment
 create mode 100644 doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_5_4333c2f189cea3430104ece6769143bc._comment
 create mode 100644 doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_6_8c4c2e8dc4706ca824cbbc9b2ed62be4._comment
 create mode 100644 doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_7_24b09f1263f6bc6b219085c17ced915c._comment
 create mode 100644 doc/forum/files_only_visible_in_.git_annex.mdwn
 create mode 100644 doc/forum/files_only_visible_in_.git_annex/comment_1_a967dc488d4fb0fd6079b0a1b087679f._comment
 create mode 100644 doc/forum/files_only_visible_in_.git_annex/comment_2_e024e26b943f49a5e63c8fd1cd90a420._comment
 create mode 100644 doc/forum/files_only_visible_in_.git_annex/comment_3_2c3d5991056d5915225b2707ad7d25dd._comment
 create mode 100644 doc/forum/files_vanishing.mdwn
 create mode 100644 doc/forum/files_vanishing/comment_1_eb69e88aee0005fca74dd540293e57ca._comment
 create mode 100644 doc/forum/finding_out_why_git_annex_import_failed.mdwn
 create mode 100644 doc/forum/finding_out_why_git_annex_import_failed/comment_1_276bbd2dab64e4bbc297e0e53e02215d._comment
 create mode 100644 doc/forum/first-time_setup_git-annex.mdwn
 create mode 100644 doc/forum/first-time_setup_git-annex/comment_1_a58d83ee3a7c2251d9a775847223f8ca._comment
 create mode 100644 doc/forum/flickrannex_--_not_sure_I_get_it.mdwn
 create mode 100644 doc/forum/flickrannex_--_not_sure_I_get_it/comment_1_57ea9f26760f970a70f09934d31a79b5._comment
 create mode 100644 doc/forum/flickrannex_--_not_sure_I_get_it/comment_2_ba93563b4ce1f6497a9f1d5e6eb0d1bb._comment
 create mode 100644 doc/forum/flickrannex_--_not_sure_I_get_it/comment_3_74f143965f48c89a3583acf1b6a7635a._comment
 create mode 100644 doc/forum/flickrannex_--_not_sure_I_get_it/comment_4_493bb86dedfa91ccc0c9be4045953ee4._comment
 create mode 100644 doc/forum/flickrannex_--_not_sure_I_get_it/comment_5_2c410aa478b21c0e6eb0e4d54bc8c362._comment
 create mode 100644 doc/forum/folder_size_question.mdwn
 create mode 100644 doc/forum/folder_size_question/comment_1_782cbf836335d86ff29853c34f00fec3._comment
 create mode 100644 doc/forum/folder_size_question/comment_2_391aa62e4d8c496a58be4707522d8edb._comment
 create mode 100644 doc/forum/folder_size_question/comment_3_1e850dbe36fafe0505b60dd2ce0bd5d7._comment
 create mode 100644 doc/forum/folder_size_question/comment_4_907f3b1cfe745abf94a6a8ba0dbd4396._comment
 create mode 100644 doc/forum/forumbug.mdwn
 create mode 100644 doc/forum/freebsd_git-annex_seems_to_be_in_an_upgrade_loop.mdwn
 create mode 100644 doc/forum/freebsd_git-annex_seems_to_be_in_an_upgrade_loop/comment_1_ce8e7f58c3b81ec334436726be70bde5._comment
 create mode 100644 doc/forum/freebsd_git-annex_seems_to_be_in_an_upgrade_loop/comment_2_43cdcdfff3aaa4482e6182d3dd77b61a._comment
 create mode 100644 doc/forum/fsck_gives_false_positives.mdwn
 create mode 100644 doc/forum/fsck_gives_false_positives/comment_1_b91070218b9d5fb687eeee1f244237ad._comment
 create mode 100644 doc/forum/fsck_gives_false_positives/comment_2_f51c53f3f6e6ee1ad463992657db5828._comment
 create mode 100644 doc/forum/fsck_gives_false_positives/comment_3_692d6d4cd2f75a497e7d314041a768d2._comment
 create mode 100644 doc/forum/fsck_gives_false_positives/comment_4_7ceb395bf8a2e6a041ccd8de63b1b6eb._comment
 create mode 100644 doc/forum/fsck_gives_false_positives/comment_5_86484a504c3bbcecd5876982b9c95688._comment
 create mode 100644 doc/forum/fsck_gives_false_positives/comment_6_1d4fbbd212fa92967abda346323031f4._comment
 create mode 100644 doc/forum/ga-ncdu.mdwn
 create mode 100644 doc/forum/ga-ncdu/comment_1_cde3f7bbd099b303bacdaa5e1588b71e._comment
 create mode 100644 doc/forum/ga-ncdu/comment_2_8d369dc264ccaf80490c1cb37a330239._comment
 create mode 100644 doc/forum/ga-ncdu/comment_3_c5ce3b663de76b50754de70b3fb23bf0._comment
 create mode 100644 doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz.mdwn
 create mode 100644 doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_1_0547fcabefe0b8e99a43977ffec3e28c._comment
 create mode 100644 doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_2_606281f102d8c3168cbc55142a996e05._comment
 create mode 100644 doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_3_ca138f01184631135d07835d79a95112._comment
 create mode 100644 doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_4_750e5eaac44e53030be18858c03cbe6c._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage.mdwn
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_10_f632a62c4dbbf01b29f146893d7725f9._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_11_73461da2d55d040cb43e0db286975821._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_12_6c4fb123091bde435c18ac3dfd5a9b77._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_13_8e0e86ae716ff018025808f417e1f7f6._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_14_d8f69914b88feb3f3ed4f72c26dd74e5._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_1_067d0ffe8900751bd2d2743254ac4d77._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_2_ec8b57426e4d82c3392eb7dd683f2ddc._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_3_38296fef5a2dc5794c2dc09df676b8c1._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_4_1bcc94f9982c6cfd0888f3dba0f9221e._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_5_4365cd3031456fac1b563ee72984638e._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_6_2b03d7b857497cb811e992f85700cdcc._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_7_03a4dfaf3bd73d41c6f3c3fab0a6a922._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_8_fc6ddb4dc075ee42368863c1b026dbf7._comment
 create mode 100644 doc/forum/gadu_-_git-annex_disk_usage/comment_9_f03254e518cbdda73e4b88e72476275d._comment
 create mode 100644 doc/forum/gcrypt_os_x_app_vs_brew.mdwn
 create mode 100644 doc/forum/gcrypt_os_x_app_vs_brew/comment_1_cce5e2c16720cc8e32a4a479f50ce6b3._comment
 create mode 100644 doc/forum/gcrypt_os_x_app_vs_brew/comment_2_8df8ba1ccea0f68110593ed90a9cad6d._comment
 create mode 100644 doc/forum/gcrypt_os_x_app_vs_brew/comment_3_be4de1663a37f49a4e42d6b21c0178fe._comment
 create mode 100644 doc/forum/get_and_copy_with_bare_repositories.mdwn
 create mode 100644 doc/forum/get_and_copy_with_bare_repositories/comment_1_a6e4628c0770e3f5e81348a6f29dd845._comment
 create mode 100644 doc/forum/get_and_copy_with_bare_repositories/comment_2_652fa1bae5c2bb63dcffcbda97a567c4._comment
 create mode 100644 doc/forum/get_content_of_a_file_from_a_file.mdwn
 create mode 100644 doc/forum/get_content_of_a_file_from_a_file/comment_1_174fe84e87b31419295af3397db19671._comment
 create mode 100644 doc/forum/get_content_of_a_file_from_a_file/comment_2_9cc8905f867fedbf2b10c9ad84294543._comment
 create mode 100644 doc/forum/get_fails.mdwn
 create mode 100644 doc/forum/get_fails/comment_1_9c81adaedf2b526f735ed39cb9d24709._comment
 create mode 100644 doc/forum/get_fails/comment_2_4ef8a59e82e38861fd36befde1ff9542._comment
 create mode 100644 doc/forum/get_fails/comment_3_b4359d19a002a2903a895beae3888b4e._comment
 create mode 100644 doc/forum/get_fails/comment_4_6227b1df801927cdf7a2edcc86bbdfee._comment
 create mode 100644 doc/forum/get_fails/comment_5_472d50770325a87cc0daae3e6067558c._comment
 create mode 100644 doc/forum/get_fails/comment_6_35174be903f055adf06af2fcdef807e3._comment
 create mode 100644 doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote.mdwn
 create mode 100644 doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote/comment_1_3deb2c31cad37a49896f00d600253ee3._comment
 create mode 100644 doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote/comment_2_627f54d158d3ca4b72e45b4da70ff5cd._comment
 create mode 100644 doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote/comment_3_3f49dab11aae5df0c4eb5e4b8d741379._comment
 create mode 100644 doc/forum/ghost_semitrusted_repositories.mdwn
 create mode 100644 doc/forum/ghost_semitrusted_repositories/comment_1_99bea1a964da9c5603b8cfbdc19bcde8._comment
 create mode 100644 doc/forum/ghost_semitrusted_repositories/comment_2_fe5fe5539d06c6b1ef69f3ed805f1ab4._comment
 create mode 100644 doc/forum/ghost_semitrusted_repositories/comment_3_588325ef52c80cfc67d1dd80a9d5bd13._comment
 create mode 100644 doc/forum/git-annes_assistant_+_MAC_OSX_questions.mdwn
 create mode 100644 doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_1_e661f31acd08a6459842f7f95e5c062b._comment
 create mode 100644 doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_2_e71a9d1fcf1f945fec0b7834b6038e91._comment
 create mode 100644 doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_3_372d9da8295d093b8b316f0a48b60ee1._comment
 create mode 100644 doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_4_573537a49e082515bfb1be84c91b5d1b._comment
 create mode 100644 doc/forum/git-annex-addunused_with_original_path+filename.mdwn
 create mode 100644 doc/forum/git-annex-addunused_with_original_path+filename/comment_1_b24b20d6351d0373f9517438c33f05c1._comment
 create mode 100644 doc/forum/git-annex-addunused_with_original_path+filename/comment_2_cddedfd83ee154f44b83f2414eb103d0._comment
 create mode 100644 doc/forum/git-annex-import_questions.mdwn
 create mode 100644 doc/forum/git-annex-import_questions/comment_1_e353e5ae20ba379c42fb39825c57147e._comment
 create mode 100644 doc/forum/git-annex-repair_not_able_to_see_external_remotes.mdwn
 create mode 100644 doc/forum/git-annex-repair_not_able_to_see_external_remotes/comment_1_b30811d84190110b9d084e42bd4a6282._comment
 create mode 100644 doc/forum/git-annex-sync_and_git-annex-config.mdwn
 create mode 100644 doc/forum/git-annex-sync_and_git-annex-config/comment_1_1372a7d54e7ef017cc4fa34358c122e0._comment
 create mode 100644 doc/forum/git-annex-sync_and_git-annex-config/comment_2_dd5cd6f18b3d0d9cf6ad97181fcbf4b1._comment
 create mode 100644 doc/forum/git-annex-sync_and_git-annex-config/comment_3_46b1ab0fcc3b9e5a974d1bf1c4d912e6._comment
 create mode 100644 doc/forum/git-annex-sync_and_git-annex-config/comment_4_e4e1d59b43fc954189306de242c37dcc._comment
 create mode 100644 doc/forum/git-annex-sync_with_bitbucket.mdwn
 create mode 100644 doc/forum/git-annex-sync_with_bitbucket/comment_1_b95e03d119c83ac061c470801b157d55._comment
 create mode 100644 doc/forum/git-annex-sync_with_bitbucket/comment_2_31f7eae218447a17f316a8d13dd97ca0._comment
 create mode 100644 doc/forum/git-annex-sync_with_bitbucket/comment_3_eddbd42891a1877148a8920f19fb780e._comment
 create mode 100644 doc/forum/git-annex-sync_without_syncing_master.mdwn
 create mode 100644 doc/forum/git-annex-sync_without_syncing_master/comment_1_8ed0014e53a7ab49d76c072de074adda._comment
 create mode 100644 doc/forum/git-annex-sync_without_syncing_master/comment_2_585648a04a02760a1f16394c00728d79._comment
 create mode 100644 doc/forum/git-annex-sync_without_syncing_master/comment_3_233c20435643d2701c94a2cf30ca6483._comment
 create mode 100644 doc/forum/git-annex-sync_without_syncing_master/comment_4_a8f681ec33f2fef16b9b8eb6633f8fe4._comment
 create mode 100644 doc/forum/git-annex-sync_without_syncing_master/comment_5_a125638afe0cf57fe97e6051da943406._comment
 create mode 100644 doc/forum/git-annex-watch_clarification.mdwn
 create mode 100644 doc/forum/git-annex-watch_clarification/comment_1_66de424e6d09b67cb75f6ddfef1424b2._comment
 create mode 100644 doc/forum/git-annex-watch_clarification/comment_2_aa709c1ee602ae3211f36cba68c155c4._comment
 create mode 100644 doc/forum/git-annex-watch_clarification/comment_3_db050d4b4d08100c6be204cd64ebfbf3._comment
 create mode 100644 doc/forum/git-annex-watch_clarification/comment_4_7255d87f5802a8d12204e4afc797070d._comment
 create mode 100644 doc/forum/git-annex-watch_clarification/comment_5_4a1b1176bf2499db67ffea2cce3115df._comment
 create mode 100644 doc/forum/git-annex-watch_clarification/comment_6_69a3377204ea4b102d9c15fb160e71b2._comment
 create mode 100644 doc/forum/git-annex_6.20170520_doesn__39__t_build_with_QuickCheck_2.10.mdwn
 create mode 100644 doc/forum/git-annex_6.20170520_doesn__39__t_build_with_QuickCheck_2.10/comment_1_0e25ab25c0fa3d41336e6b7551ef9e47._comment
 create mode 100644 doc/forum/git-annex_SSH_server_+_cloud_remote.mdwn
 create mode 100644 doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___.mdwn
 create mode 100644 doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___/comment_1_94d92b7e64ad31db8837dcf3d131cf23._comment
 create mode 100644 doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___/comment_2_c9474c4e925948d0cabdfe7f988e1ebe._comment
 create mode 100644 doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___/comment_3_3a9e1cb8f36a44fd1917b5fc191776a3._comment
 create mode 100644 doc/forum/git-annex__58___map__58___1_failed.mdwn
 create mode 100644 doc/forum/git-annex__58___map__58___1_failed/comment_1_35ff3256e823ab8cfc53276a2123ad5f._comment
 create mode 100644 doc/forum/git-annex__58___map__58___1_failed/comment_2_b0826073ebbd2847f4ab0d9bdba2dce5._comment
 create mode 100644 doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__.mdwn
 create mode 100644 doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_1_0a5894ed2c5e0b8155e69ff85741a51a._comment
 create mode 100644 doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_2_85dc89b0f0ad813321b034f3fd3a83a9._comment
 create mode 100644 doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_3_4462c0640e11e20a8655743ecc78eaaa._comment
 create mode 100644 doc/forum/git-annex__58___unknown_response_from_git_cat-file.mdwn
 create mode 100644 doc/forum/git-annex__58___unknown_response_from_git_cat-file/comment_1_96ad30294a6f18c0f73be1136de47632._comment
 create mode 100644 doc/forum/git-annex___38___ikiwiki_experiment.mdwn
 create mode 100644 doc/forum/git-annex___38___ikiwiki_experiment/comment_1_9f74449ec91577dbf6095f4beafac293._comment
 create mode 100644 doc/forum/git-annex___38___ikiwiki_experiment/comment_2_e034585c8b51cc30b35c1f7ae68205bf._comment
 create mode 100644 doc/forum/git-annex___38___ikiwiki_experiment/comment_3_fbbd47c3dbe8de24b0df664e4afd5cb8._comment
 create mode 100644 doc/forum/git-annex___38___ikiwiki_experiment/comment_4_55da5c3c41c13b08590ce1ff8117cef6._comment
 create mode 100644 doc/forum/git-annex___38___ikiwiki_experiment/comment_5_f67823351164ddfe7d595685c3679652._comment
 create mode 100644 doc/forum/git-annex___38___ikiwiki_experiment/comment_6_d5cc91164772849d027fed5f962d9000._comment
 create mode 100644 doc/forum/git-annex___38___ikiwiki_experiment/comment_7_cb4ec7ed3c39d0649133191a85ea6ab3._comment
 create mode 100644 doc/forum/git-annex___38___ikiwiki_experiment/comment_8_86565e5e1508ff1862f88975446650a2._comment
 create mode 100644 doc/forum/git-annex_across_two_filesystems.mdwn
 create mode 100644 doc/forum/git-annex_across_two_filesystems/comment_1_53167648b8b70b41d19ca662a5f3687e._comment
 create mode 100644 doc/forum/git-annex_across_two_filesystems/comment_2_39adeebc1af9c437f1fc2e00c07509bf._comment
 create mode 100644 doc/forum/git-annex_across_two_filesystems/comment_3_f4e3f28db005301adeef7ccd2c9998fb._comment
 create mode 100644 doc/forum/git-annex_across_two_filesystems/comment_4_53fa7ac6f80e3281768a7bfd3d438b34._comment
 create mode 100644 doc/forum/git-annex_across_two_filesystems/comment_5_2e1be54c01970ef3456e8af4aaf00cbf._comment
 create mode 100644 doc/forum/git-annex_across_two_filesystems/comment_6_aa6b153478f79c78e778865a99f01373._comment
 create mode 100644 doc/forum/git-annex_across_two_filesystems/comment_7_b87281c6a8b068cec60d2d5b7d015a23._comment
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error.mdwn
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error/comment_10_d90d392db9a4962f9f8eb0ee95bf2914._comment
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error/comment_11_459f810fd06aab3ddeeba8207d774dc0._comment
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error/comment_12_d7d3785b65b0608424b25056c9e3a139._comment
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error/comment_1_a2331032781c2fa3cdf22c0dc6b5b869._comment
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error/comment_2_de9d956d95cb41e2372eabbf672e0f67._comment
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error/comment_3_91af8300d640c34ff2466c89ec7a234c._comment
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error/comment_4_ef913a45e3d865d088cf11460cd88020._comment
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error/comment_5_64008199df70f77ab64882339aa079f9._comment
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error/comment_5_6a8580087688b4bbfc3241292df5422e._comment
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error/comment_8_76a65b4edf4f6e3896f1593a197f24eb._comment
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error/comment_8_ffbb059664541c92dcbf97c150d9b951._comment
 create mode 100644 doc/forum/git-annex_add_out_of_memory_error/comment_9_7ef671c0036c77ee5707a6e00dd4dd6a._comment
 create mode 100644 doc/forum/git-annex_and_bup_-_the_other_way_around___63____63____63__.mdwn
 create mode 100644 doc/forum/git-annex_and_bup_-_the_other_way_around___63____63____63__/comment_1_0bb5e21b4cbaaaa61fbdb2e0066f0ebf._comment
 create mode 100644 doc/forum/git-annex_and_bup_-_the_other_way_around___63____63____63__/comment_2_ab6420f7bc18e8143201c603c09a0d7e._comment
 create mode 100644 doc/forum/git-annex_and_tagfs.mdwn
 create mode 100644 doc/forum/git-annex_and_tagfs/comment_1_887c74cb61d30198322ef74ebc80f950._comment
 create mode 100644 doc/forum/git-annex_and_tagfs/comment_2_8769d6e57061023c0828af3e38faafba._comment
 create mode 100644 doc/forum/git-annex_and_tagfs/comment_3_d96948c444f9f485a329420b7c9e3b16._comment
 create mode 100644 doc/forum/git-annex_assistant_atempts_to_repair__44___but_never_finishes.mdwn
 create mode 100644 doc/forum/git-annex_assistant_atempts_to_repair__44___but_never_finishes/comment_1_a12892b2881969ddd6faa92d860e1bc8._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers.mdwn
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_10_533ade2215c879cd46782fd66a97b167._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_11_c9ae51d7b772cf7a91d90925f74d2b60._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_12_41fbee0ec9bc890e309bcd48a58c3851._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_13_571cffc0beb8ba5fc936db6971cd3d62._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_14_0fb62af673a4bc8183e8fef048ceedd4._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_1_53a79af2d8e3abe50b983bf91972b8f2._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_2_c0ba3e8b7fbf8a5ed718001cec8df676._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_3_60c39bc8ef74e80e72381d514b6dd223._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_4_6241120b4325c905661ef72881f4d7af._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_5_cab00b8fa195340f4d3fdaf5af975b57._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_6_e24df9a1c68724a912b8ac6533d9bd25._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_7_ace3dc7c60c710a04b0a587206b341c4._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_8_9a96bc970a17ed62b0ceb7aa3f0a6f8b._comment
 create mode 100644 doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_9_ea88e0696f6e25e6904248a323f6cc36._comment
 create mode 100644 doc/forum/git-annex_build_for_Nokia_N9___40__Meego_Harmattan__41___and_Sailfish_OS.mdwn
 create mode 100644 doc/forum/git-annex_build_for_Nokia_N9___40__Meego_Harmattan__41___and_Sailfish_OS/comment_1_301a51c48c3d54f9d37feace26a772f8._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up.mdwn
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_10_3bc5af3b28094fc042c207e307fe0c18._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_12_89b9fe9c689515a8f874dee96864ff33._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_12_b48f8d801305d9bde08060f06634b88e._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_13_41e0fada90d795b9be12929ed66231e1._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_14_4bd86a227f117dbf5d1b12fbcf873e62._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_1_a63df20ab1888e4dc5e7f002b4a68b5f._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_2_3908d1552421edb054dc1a56c449ad23._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_3_5adf7777f9495e28432a0d60a15493ee._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_4_b8a7f87aa1e9101fbb3e1d4e29febff5._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_5_122c584af1b1b6894cfccd4e16d2d76a._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_6_4668f6cc692c49a456418f783655602b._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_7_8e9feaea0e807cefee95166508c9c7de._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_8_02c5903bf4de4b94e6db84bc43b3b3d8._comment
 create mode 100644 doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_9_b6780a99d7a175d2ff3e33e198c28a9d._comment
 create mode 100644 doc/forum/git-annex_clients_with_only_a_gitLab_repo_and_GDrive_special_remote_in_common.mdwn
 create mode 100644 doc/forum/git-annex_clients_with_only_a_gitLab_repo_and_GDrive_special_remote_in_common/comment_1_10fa70e1e5e08e12ab7c1570881b38f8._comment
 create mode 100644 doc/forum/git-annex_clients_with_only_a_gitLab_repo_and_GDrive_special_remote_in_common/comment_2_ff0dab8dc544f7aa8e4ebfbec8f2a081._comment
 create mode 100644 doc/forum/git-annex_communication_channels.mdwn
 create mode 100644 doc/forum/git-annex_communication_channels/comment_1_198325d2e9337c90f026396de89eec0e._comment
 create mode 100644 doc/forum/git-annex_communication_channels/comment_2_c7aeefa6ef9a2e75d8667b479ade1b7f._comment
 create mode 100644 doc/forum/git-annex_communication_channels/comment_3_1ff08a3e0e63fa0e560cbc9602245caa._comment
 create mode 100644 doc/forum/git-annex_communication_channels/comment_4_1ba6ddf54843c17c7d19a9996f2ab712._comment
 create mode 100644 doc/forum/git-annex_communication_channels/comment_5_404b723a681eb93fee015cea8024b6bc._comment
 create mode 100644 doc/forum/git-annex_communication_channels/comment_6_0d87d0e26461494b1d7f8a701a924729._comment
 create mode 100644 doc/forum/git-annex_communication_channels/comment_7_2c87c7a0648fe87c2bf6b4391f1cc468._comment
 create mode 100644 doc/forum/git-annex_confused_by_a_case-preserving_filesystem__63__.mdwn
 create mode 100644 doc/forum/git-annex_does_not_protect_files_on_NTFS-Fuse.mdwn
 create mode 100644 doc/forum/git-annex_does_not_protect_files_on_NTFS-Fuse/comment_1_4aef65f680e4801eb110fefa1f947f02._comment
 create mode 100644 doc/forum/git-annex_does_not_respect_preferred_content_settings.mdwn
 create mode 100644 doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_1_ea347ea6ebdfe5ccfb0ed8786638f279._comment
 create mode 100644 doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_2_5fac7c41c9841cea4234afa0a98b1636._comment
 create mode 100644 doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_3_e2ea1843bbc9580ca7b4ec494f53b552._comment
 create mode 100644 doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_4_59ede467a902f27b81f14e4706a7503a._comment
 create mode 100644 doc/forum/git-annex_doesn__39__t_build_with_feed-1.0.0.0.mdwn
 create mode 100644 doc/forum/git-annex_doesn__39__t_build_with_feed-1.0.0.0/comment_1_0be4545b1d93232a721c5ae65030334c._comment
 create mode 100644 doc/forum/git-annex_fails_on_Windows.mdwn
 create mode 100644 doc/forum/git-annex_fails_on_Windows/comment_1_451a2cdfa6f26e2bd319ebf4ce09da68._comment
 create mode 100644 doc/forum/git-annex_fails_on_Windows/comment_2_57b4fd347f74b3536ab0f0a5d7709af8._comment
 create mode 100644 doc/forum/git-annex_for_multiple_repositories___40__ssh_server__41__.mdwn
 create mode 100644 doc/forum/git-annex_for_multiple_repositories___40__ssh_server__41__/comment_1_cb691410d2a9ef4393af5362000a768c._comment
 create mode 100644 doc/forum/git-annex_help_import_outdated__63__.mdwn
 create mode 100644 doc/forum/git-annex_help_import_outdated__63__/comment_1_ada30e2fead4b5b8f5e53388f941eb07._comment
 create mode 100644 doc/forum/git-annex_help_import_outdated__63__/comment_2_ca898237f42af1205acab509e4d67d38._comment
 create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn
 create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment
 create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment
 create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment
 create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment
 create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment
 create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_6_25ce5eddeb1b65aacd5d86e09c3719b8._comment
 create mode 100644 doc/forum/git-annex_memory_usage.mdwn
 create mode 100644 doc/forum/git-annex_memory_usage/comment_1_50753a133c200cdf6d855c65e6d4422b._comment
 create mode 100644 doc/forum/git-annex_move_does_not_appear_to_respect_numcopies.mdwn
 create mode 100644 doc/forum/git-annex_move_does_not_appear_to_respect_numcopies/comment_1_5dba0ff04c86c7b2697a0750fd1e4b5d._comment
 create mode 100644 doc/forum/git-annex_move_does_not_appear_to_respect_numcopies/comment_2_114cc3c9236ba930117cc14a0dddc3dd._comment
 create mode 100644 doc/forum/git-annex_on_OSX.mdwn
 create mode 100644 doc/forum/git-annex_on_Samba_share.mdwn
 create mode 100644 doc/forum/git-annex_on_Samba_share/comment_1_3e9cfdf2c088e48c967ad08f79966742._comment
 create mode 100644 doc/forum/git-annex_on_Samba_share/comment_2_9d3df393b7b727653598453d94dd33db._comment
 create mode 100644 doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working.mdwn
 create mode 100644 doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_1_209956f3812450a43986d4ca5e647da6._comment
 create mode 100644 doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_3_12a58b8efe545e09b64760c87849839b._comment
 create mode 100644 doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_3_e0f7328603256f25c3be3706ecc9c76c._comment
 create mode 100644 doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_4_6bb8e4522241556fb82784d9b834cbfe._comment
 create mode 100644 doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_5_89a5296b461d400b51006074a13a4560._comment
 create mode 100644 doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_6_62daef4b4392c951b914a01b3effac11._comment
 create mode 100644 doc/forum/git-annex_on_archlinuxarm__44___armv6.mdwn
 create mode 100644 doc/forum/git-annex_on_archlinuxarm__44___armv6/comment_1_88fa644df8614c2db0d092b3eb1d3156._comment
 create mode 100644 doc/forum/git-annex_on_archlinuxarm__44___armv6/comment_2_b25ca7520ff7e339ec887a379d5100ee._comment
 create mode 100644 doc/forum/git-annex_on_archlinuxarm__44___armv6/comment_3_eda0e90c1285396b1ab20ecc04ea6e29._comment
 create mode 100644 doc/forum/git-annex_on_openSUSE.mdwn
 create mode 100644 doc/forum/git-annex_on_openSUSE/comment_1_97313a8a7fc7f558b5956989442a0f0b._comment
 create mode 100644 doc/forum/git-annex_on_openSUSE/comment_2_bbe6925ca465d13b050639c18abcd890._comment
 create mode 100644 doc/forum/git-annex_on_osx_10.9.1_just_crashes__47__closes__47__doesn__39__t_run_on_launch.mdwn
 create mode 100644 doc/forum/git-annex_on_osx_10.9.1_just_crashes__47__closes__47__doesn__39__t_run_on_launch/comment_1_a47174f8438bfaa42fb8067bca77bf4c._comment
 create mode 100644 doc/forum/git-annex_on_osx_10.9.1_just_crashes__47__closes__47__doesn__39__t_run_on_launch/comment_2_567bb460cec7cd2135386acf4e7dceb4._comment
 create mode 100644 doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch.mdwn
 create mode 100644 doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_1_3ece379be6645e75eff0d0acdc0a832f._comment
 create mode 100644 doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_2_5aa79212878820270d9148275829727b._comment
 create mode 100644 doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_2_8a46c0146f81d6d6147d8cfdc1277595._comment
 create mode 100644 doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_4_aec9399cdf7b11011c9b577a6800b490._comment
 create mode 100644 doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_5_aa4091341c7a067b46b57dea9dd02c22._comment
 create mode 100644 doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_6_7d6d0da2243967b9660d8222c546112d._comment
 create mode 100644 doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_7_ae5fb82005702e9b5ed14fa37f80a91a._comment
 create mode 100644 doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_8_b0bc7c10d97a03497354aef2b011e1f1._comment
 create mode 100644 doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_9_deb88db3c97645b1aa180813401fa436._comment
 create mode 100644 doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram.mdwn
 create mode 100644 doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_1_ff16c7932b60b85c744bafc48bb040e4._comment
 create mode 100644 doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_2_5599cddf579d18f70cab6e48d04ae99d._comment
 create mode 100644 doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_3_412941e9385f63153b23695641e71deb._comment
 create mode 100644 doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_4_112ad140d9006c530db2121bec24de30._comment
 create mode 100644 doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_5_9178023b95683a649355f291165a1467._comment
 create mode 100644 doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_6_9251203421c1c3c3aed7828c4b97ecb8._comment
 create mode 100644 doc/forum/git-annex_s3_failure.mdwn
 create mode 100644 doc/forum/git-annex_s3_failure/comment_1_099023ae32a6a3417cc9c8bdcce9a89d._comment
 create mode 100644 doc/forum/git-annex_s3_failure/comment_2_c869b85bb2bea4a7a99e107f4a3cfb0f._comment
 create mode 100644 doc/forum/git-annex_s3_failure/comment_3_b9e52fe4d14104398d57a6bcc7f2deaf._comment
 create mode 100644 doc/forum/git-annex_sync_content_available_from_which_version__63__.mdwn
 create mode 100644 doc/forum/git-annex_sync_content_available_from_which_version__63__/comment_1_104e1b7e7643844f221f85dcbe9c9c4b._comment
 create mode 100644 doc/forum/git-annex_sync_fails_in_repo1_but_not_in_repo2.mdwn
 create mode 100644 doc/forum/git-annex_sync_fails_in_repo1_but_not_in_repo2/comment_1_5cca2fbce3db1c691f43e43f9343f9bd._comment
 create mode 100644 doc/forum/git-annex_sync_fails_in_repo1_but_not_in_repo2/comment_2_1dfeb722edd54c68b4220d00c0a175e5._comment
 create mode 100644 doc/forum/git-annex_sync_here.mdwn
 create mode 100644 doc/forum/git-annex_sync_here/comment_1_3ebef27614bd72b38404c1940007e68c._comment
 create mode 100644 doc/forum/git-annex_sync_here/comment_2_1b0543443759202ec6a85a26088ddb43._comment
 create mode 100644 doc/forum/git-annex_teams___47___groups.mdwn
 create mode 100644 doc/forum/git-annex_teams___47___groups/comment_1_0450673ab74f184a47ac7bab568d26dc._comment
 create mode 100644 doc/forum/git-annex_tor_remote_not_working.mdwn
 create mode 100644 doc/forum/git-annex_tor_remote_not_working/comment_1_15cce70b24769832ccf9782d1215d605._comment
 create mode 100644 doc/forum/git-annex_tor_remote_not_working/comment_2_e17a7f8a98f4614f46f05228f604a562._comment
 create mode 100644 doc/forum/git-annex_tor_remote_not_working/comment_3_8ca1bc7358ad96ffb711d7ab1e4fd22a._comment
 create mode 100644 doc/forum/git-annex_unused_not_dropping_deleted_files.mdwn
 create mode 100644 doc/forum/git-annex_unused_not_dropping_deleted_files/comment_1_2152cfb09675e46e7492e198dd3ea094._comment
 create mode 100644 doc/forum/git-annex_unused_not_dropping_deleted_files/comment_2_97e666dbac9de2a5e688921cba8a42e9._comment
 create mode 100644 doc/forum/git-annex_unused_not_dropping_deleted_files/comment_3_d7b0e9515bface28f3650b8aa20ec2f4._comment
 create mode 100644 doc/forum/git-annex_unused_not_dropping_deleted_files/comment_4_5816f6cab42e27e724e735368f693b09._comment
 create mode 100644 doc/forum/git-annex_unused_not_dropping_deleted_files/comment_5_8e97f39225515f0bf8b168dfd6a0efab._comment
 create mode 100644 doc/forum/git-annex_unused_not_dropping_deleted_files/comment_6_bef37f8ec9c337387b79ffd6d56fe425._comment
 create mode 100644 doc/forum/git-annex_unused_not_dropping_deleted_files/comment_7_bff3bcf9f1b7c458afa98cdb18883153._comment
 create mode 100644 doc/forum/git-annex_unused_not_dropping_deleted_files/comment_8_7259b8e9616009472ad3a10426f3d8ea._comment
 create mode 100644 doc/forum/git-annex_unused_on_directory_special_remote__63__.mdwn
 create mode 100644 doc/forum/git-annex_unused_on_directory_special_remote__63__/comment_1_5fb31042ed7c5c52969451b6fc0f4ddc._comment
 create mode 100644 doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved.mdwn
 create mode 100644 doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_1_81111f59caea9f70cb9d597381e42c96._comment
 create mode 100644 doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_2_8ca9156d21d9f3db0d83d6aa9b69caa0._comment
 create mode 100644 doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_3_9da6ca0250ab0dcfc9a012df75e2e711._comment
 create mode 100644 doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_4_55c52c45f3aaddfb63a1f53efe2ee582._comment
 create mode 100644 doc/forum/git-annex_webapp_launch_behavior_is_confusing.mdwn
 create mode 100644 doc/forum/git-assistant_clarification.mdwn
 create mode 100644 doc/forum/git-assistant_clarification/comment_1_8f553e59da12f798b854a457b96b5778._comment
 create mode 100644 doc/forum/git-assistant_clarification/comment_2_06cf62b599edea6ad8396776f0081494._comment
 create mode 100644 doc/forum/git-assistant_clarification/comment_3_36f0bd6e7a824e6ef40a309850bb087b._comment
 create mode 100644 doc/forum/git-like_git-annex_diff.mdwn
 create mode 100644 doc/forum/git-remote-gcrypt.mdwn
 create mode 100644 doc/forum/git-remote-gcrypt/comment_1_175c8c35d9bbb470fcc17697eb8cc6b8._comment
 create mode 100644 doc/forum/git-remote-gcrypt/comment_2_fdcaf507e14c995636dd93a41e488df3._comment
 create mode 100644 doc/forum/git-remote-gcrypt/comment_3_f4e830f961dbe1c60ddd277b9d888133._comment
 create mode 100644 doc/forum/git-remote-gcrypt_and_rsyncd.mdwn
 create mode 100644 doc/forum/git-remote-gcrypt_and_rsyncd/comment_1_34dd343ed75918f5969f6a23dfae3317._comment
 create mode 100644 doc/forum/git-remote-gcrypt_and_rsyncd/comment_2_78b89867bd1af78a91826022651a57ad._comment
 create mode 100644 doc/forum/git-repair_doesn__39__t_build_with_GHC_8.0.2.mdwn
 create mode 100644 doc/forum/git-repair_doesn__39__t_build_with_GHC_8.0.2/comment_1_0a6ea834f6515b888e5c40fef08f4e2d._comment
 create mode 100644 doc/forum/git-repair_doesn__39__t_build_with_GHC_8.0.2/comment_2_bb490f71aed0cfe119beac66cecae99c._comment
 create mode 100644 doc/forum/git-status_typechange_in_direct_mode.mdwn
 create mode 100644 doc/forum/git-status_typechange_in_direct_mode/comment_1_12c8b67aadbfa2b073e12997a55d49a7._comment
 create mode 100644 doc/forum/git-status_typechange_in_direct_mode/comment_2_005d1b17f3c2ae192aa30c6e5163989e._comment
 create mode 100644 doc/forum/git-subtree_support__63__.mdwn
 create mode 100644 doc/forum/git-subtree_support__63__/comment_1_4f333cb71ed1ff259bbfd86704806aa6._comment
 create mode 100644 doc/forum/git-subtree_support__63__/comment_2_73d2a015b1ac79ec99e071a8b1e29034._comment
 create mode 100644 doc/forum/git-subtree_support__63__/comment_3_c533400e22c306c033fcd56e64761b0b._comment
 create mode 100644 doc/forum/git-subtree_support__63__/comment_4_75b0e072e668aa46ff0a8d62a6620306._comment
 create mode 100644 doc/forum/git-subtree_support__63__/comment_5_f5ec9649d9f1dc122e715de5533bc674._comment
 create mode 100644 doc/forum/git-subtree_support__63__/comment_6_85df530f7b6d76b74ac8017c6034f95e._comment
 create mode 100644 doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_.mdwn
 create mode 100644 doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_/comment_1_e3c37fc6e45de48a4d5c1eb36e8d44df._comment
 create mode 100644 doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_/comment_2_c77b9790da099a94ee368de6a557d4b2._comment
 create mode 100644 doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_/comment_3_f0c6869f31a31803adec0fdc0befa178._comment
 create mode 100644 doc/forum/git__58_____39__annex__39___is_not_a_git_command_error_after_installing.mdwn
 create mode 100644 doc/forum/git__58_____39__annex__39___is_not_a_git_command_error_after_installing/comment_1_8a2e3be32800b7b8a6fa78bbdcba7608._comment
 create mode 100644 doc/forum/git__58_____39__annex__39___is_not_a_git_command_error_after_installing/comment_2_451b3c89d1b98212d5c21efa4e535424._comment
 create mode 100644 doc/forum/git_annex_add_crash_and_subsequent_recovery.mdwn
 create mode 100644 doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_1_062d0153a379c1ba1df8585b90220d3d._comment
 create mode 100644 doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_2_6fc6be43c488c468a4811cd0a1360225._comment
 create mode 100644 doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_3_45efaaf27d9b580c4c75cbcdc4f65b64._comment
 create mode 100644 doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_4_c560eae40867512b0af2cbef161fc8ac._comment
 create mode 100644 doc/forum/git_annex_add_freezes_on_direct_repo.mdwn
 create mode 100644 doc/forum/git_annex_add_freezes_on_direct_repo/comment_1_290df6fdd3c9042308638f1e8b66b805._comment
 create mode 100644 doc/forum/git_annex_add_freezes_on_direct_repo/comment_2_3aa5d0ef823592baab79382851385979._comment
 create mode 100644 doc/forum/git_annex_add_freezes_on_direct_repo/comment_3_cba1ba0c8b0f2e0f4186e7695d9df569._comment
 create mode 100644 doc/forum/git_annex_alternative.mdwn
 create mode 100644 doc/forum/git_annex_assistant_-_Changing_repository_information.mdwn
 create mode 100644 doc/forum/git_annex_assistant_-_Changing_repository_information/comment_1_cde71a410200a7478180748fdcde0352._comment
 create mode 100644 doc/forum/git_annex_assistant__44___share_with_other_devices.mdwn
 create mode 100644 doc/forum/git_annex_assistant_repository_history__63__.mdwn
 create mode 100644 doc/forum/git_annex_assistant_repository_history__63__/comment_1_6f87f31e18cefedcc6bce95dbeb85a0b._comment
 create mode 100644 doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah.mdwn
 create mode 100644 doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_1_5b6e0b749b01a97a6b52a2c1cca6e35a._comment
 create mode 100644 doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_2_8f2567f4c4f6db2078211a87689757d3._comment
 create mode 100644 doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_3_ab98121076b88f351fc8cd9197e6bf64._comment
 create mode 100644 doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_4_cb13328add1b7a812efd817ad3dd1a4f._comment
 create mode 100644 doc/forum/git_annex_copy_more_informative_about_why_some_files_are_not_copied.mdwn
 create mode 100644 doc/forum/git_annex_copy_more_informative_about_why_some_files_are_not_copied/comment_1_75445fc0e01ee99bae1c1f5a60e314bc._comment
 create mode 100644 doc/forum/git_annex_copy_to_google_drive_is_very_slow.mdwn
 create mode 100644 doc/forum/git_annex_copy_to_google_drive_is_very_slow/comment_1_f3085ef9ddff51ee4110cc1000d26da2._comment
 create mode 100644 doc/forum/git_annex_copy_to_google_drive_is_very_slow/comment_2_539dbce8852a9b6ae20ff0e55e74fc2a._comment
 create mode 100644 doc/forum/git_annex_drop_not_freeing_space_on_filesystem.mdwn
 create mode 100644 doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_1_ce1b32c2765edb695e5d9dc8f0ac86e3._comment
 create mode 100644 doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_3_248cb012c87605479fb17fa4aadc1185._comment
 create mode 100644 doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_3_de4aa12c84a6025497f8c743a397ef63._comment
 create mode 100644 doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_4_368b2c07dc7d98534a77c6153e8486ae._comment
 create mode 100644 doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__.mdwn
 create mode 100644 doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_1_292ee7c8b37cbd13f03eb67d0359b99e._comment
 create mode 100644 doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_2_f6341119fcfde5d8160c8f603b1a6fea._comment
 create mode 100644 doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_3_8ad3a1d1fe5995d61e5e137280bc76c3._comment
 create mode 100644 doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_4_86b61b0484f3f4ecff657e46333b3d4f._comment
 create mode 100644 doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_5_5ffac00d08d26acaba8c3513b24c4d65._comment
 create mode 100644 doc/forum/git_annex_file_content_replaced_with_symlink_content.mdwn
 create mode 100644 doc/forum/git_annex_file_content_replaced_with_symlink_content/comment_1_f6f4be7161d4c35c7de1d9751ddbd3c3._comment
 create mode 100644 doc/forum/git_annex_file_content_replaced_with_symlink_content/comment_2_da848024c40eb65e6214bd95b73e078e._comment
 create mode 100644 doc/forum/git_annex_file_content_replaced_with_symlink_content/comment_3_cc703ef5015527425572002295568923._comment
 create mode 100644 doc/forum/git_annex_get_--want-get_another__95__repo.mdwn
 create mode 100644 doc/forum/git_annex_get_--want-get_another__95__repo/comment_1_0be0b3981ddd0743ff26cf6d396e521d._comment
 create mode 100644 doc/forum/git_annex_get_--want-get_another__95__repo/comment_2_b1ead1085a87818625579bf1ef151b5d._comment
 create mode 100644 doc/forum/git_annex_get_--want-get_another__95__repo/comment_3_cf2018852c84b0bf1ac061def6f0ac5d._comment
 create mode 100644 doc/forum/git_annex_get_--want-get_another__95__repo/comment_4_22562e8f1f2f91b9f9a5939ec9006cb5._comment
 create mode 100644 doc/forum/git_annex_get___60__file__62___fails___40__Action_blocked_by_GIT__41__.mdwn
 create mode 100644 doc/forum/git_annex_get___60__file__62___fails___40__Action_blocked_by_GIT__41__/comment_1_476b96f4ffd57bfe6e66c5388a19e9a5._comment
 create mode 100644 doc/forum/git_annex_get___60__file__62___fails___40__Action_blocked_by_GIT__41__/comment_2_6da3b78489ea140b321d780ef669bcd3._comment
 create mode 100644 doc/forum/git_annex_get_creates_a_new_uuid.mdwn
 create mode 100644 doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment
 create mode 100644 doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi.mdwn
 create mode 100644 doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi/comment_1_06b5d0c9c6037ffdafab6c01763061de._comment
 create mode 100644 doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi/comment_2_471a44594af15057dd4781e759013627._comment
 create mode 100644 doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi/comment_3_66f89cded0da36e96099d29542f2455b._comment
 create mode 100644 doc/forum/git_annex_info__58___local_annex_keys__63__.mdwn
 create mode 100644 doc/forum/git_annex_init_timeout.mdwn
 create mode 100644 doc/forum/git_annex_init_timeout/comment_1_e456f5367af5a5a3a31fc982952079e3._comment
 create mode 100644 doc/forum/git_annex_init_timeout/comment_2_bf15b686b07c5e6e95796affa497a541._comment
 create mode 100644 doc/forum/git_annex_init_timeout/comment_3_1e733fad01e6b420c7fd9f7832e9b3f7._comment
 create mode 100644 doc/forum/git_annex_lock__47__unlock__47__fix_on_non-committed_files.mdwn
 create mode 100644 doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis.mdwn
 create mode 100644 doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_1_7fba10b85f4d9289c7782eccef46949e._comment
 create mode 100644 doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_2_7dcec124ea7d0291ed40d80e2ffd5c7e._comment
 create mode 100644 doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_3_24c54ed70220974b98700bf717d1e770._comment
 create mode 100644 doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__.mdwn
 create mode 100644 doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_1_6889c4452e636474b4e70798b404fed2._comment
 create mode 100644 doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_2_978fc11c463a457382fddd668cd1d0dd._comment
 create mode 100644 doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_3_4420bd3afaecd7536b02fc08cee82dbe._comment
 create mode 100644 doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_4_99286f17a87049c303f2aa34c0a90286._comment
 create mode 100644 doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_5_39bad7441dcea4da4b389700301233de._comment
 create mode 100644 doc/forum/git_annex_repair_--force_fails_without_explanation.mdwn
 create mode 100644 doc/forum/git_annex_repair_--force_fails_without_explanation/comment_1_716cbfe900552a453965ac4abd44e7a4._comment
 create mode 100644 doc/forum/git_annex_repair_--force_fails_without_explanation/comment_2_f8ff4c8663d8b7bb30f7b7763be33501._comment
 create mode 100644 doc/forum/git_annex_repair_--force_fails_without_explanation/comment_3_682cb114d133713f80bdda97a4435a5e._comment
 create mode 100644 doc/forum/git_annex_repair_--force_fails_without_explanation/comment_4_cbc49405ab99e8722216739732ce394d._comment
 create mode 100644 doc/forum/git_annex_repairs_since_thursday.mdwn
 create mode 100644 doc/forum/git_annex_repairs_since_thursday/comment_1_38b4563db47ce9bdc52eab5506de20f8._comment
 create mode 100644 doc/forum/git_annex_repairs_since_thursday/comment_2_b072ad2864e1caa7459d17d3426c8eee._comment
 create mode 100644 doc/forum/git_annex_sync__58___only_git-annex.mdwn
 create mode 100644 doc/forum/git_annex_sync__58___only_git-annex/comment_1_2be68ed36a1e6bfc896d5aea9463d3c7._comment
 create mode 100644 doc/forum/git_annex_sync__58___only_git-annex/comment_2_50e137e4d278dfd0103a41aff0cfa3a9._comment
 create mode 100644 doc/forum/git_annex_sync__58___only_git-annex/comment_3_7753f8276478e0e05c10dba2b84bbc49._comment
 create mode 100644 doc/forum/git_annex_sync__58___only_git-annex/comment_5_52010f21a15d76d68986aa1fba29aaf1._comment
 create mode 100644 doc/forum/git_annex_sync__58___only_git-annex/comment_6_df94154fbbc4edbf7ff658f61bde48b5._comment
 create mode 100644 doc/forum/git_annex_sync_destroys_data_on_shallow_clones.mdwn
 create mode 100644 doc/forum/git_annex_sync_destroys_data_on_shallow_clones/comment_1_431fef51e00f19cdf206a5ab97570be5._comment
 create mode 100644 doc/forum/git_annex_sync_dies___40__sometimes__41__.mdwn
 create mode 100644 doc/forum/git_annex_sync_dies___40__sometimes__41__/comment_1_48bbac0545bf13bbf04da723e418d037._comment
 create mode 100644 doc/forum/git_annex_sync_remove_all_recently_added_files.mdwn
 create mode 100644 doc/forum/git_annex_sync_remove_all_recently_added_files/comment_1_6c059f7b2eb9d213bc0865739832b5d2._comment
 create mode 100644 doc/forum/git_annex_sync_remove_all_recently_added_files/comment_2_27a56e101f7c3fcba90b4c69fa39f4c4._comment
 create mode 100644 doc/forum/git_annex_sync_update_remote.mdwn
 create mode 100644 doc/forum/git_annex_sync_update_remote/comment_1_d6410587c442bd6323991f7839c1b5b2._comment
 create mode 100644 doc/forum/git_annex_sync_update_remote/comment_2_704cf62eb4add2459e509cc5fdbfeb68._comment
 create mode 100644 doc/forum/git_annex_sync_update_remote/comment_3_9b6ecb7342aab7f0320ed7567ee5fa0b._comment
 create mode 100644 doc/forum/git_annex_sync_update_remote/comment_4_221e01e024595f444e629db510eb60be._comment
 create mode 100644 doc/forum/git_annex_test_on_windows.mdwn
 create mode 100644 doc/forum/git_annex_test_on_windows/comment_1_258ac5cfa2f5d24e737d94dc48f06899._comment
 create mode 100644 doc/forum/git_annex_uninit_creates_broken_symlinks.mdwn
 create mode 100644 doc/forum/git_annex_uninit_creates_broken_symlinks/comment_1_b7fb7fac51f59b23aafbc8dcce0aef07._comment
 create mode 100644 doc/forum/git_annex_vicfg___40__preferred_content__41___examples.mdwn
 create mode 100644 doc/forum/git_annex_vicfg___40__preferred_content__41___examples/comment_1_1e59c9476b206613285e4f39b2c9efa8._comment
 create mode 100644 doc/forum/git_annex_vicfg___40__preferred_content__41___examples/comment_2_9d0cfb1d221e3ac6ed15db9cefab60fa._comment
 create mode 100644 doc/forum/git_annex_vicfg___40__preferred_content__41___examples/comment_3_78bc3e56502e425f4f77bc35ed2199b8._comment
 create mode 100644 doc/forum/git_annex_view__58___viewindex.lock__44___file_exists___40__it_doesn__39__t__41__.mdwn
 create mode 100644 doc/forum/git_annex_view__58___viewindex.lock__44___file_exists___40__it_doesn__39__t__41__/comment_1_08e3d99b682e640b72d0094d593f9d53._comment
 create mode 100644 doc/forum/git_annex_view_tags_failing.mdwn
 create mode 100644 doc/forum/git_annex_wants_to_repair_every_time_it__39__s_running.mdwn
 create mode 100644 doc/forum/git_annex_wants_to_repair_every_time_it__39__s_running/comment_1_c182b03bae6e691eb68465fedf5c77d5._comment
 create mode 100644 doc/forum/git_annex_wants_to_repair_every_time_it__39__s_running/comment_2_6b3427b2d3e1c5f4c0582be1020c89f8._comment
 create mode 100644 doc/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name.mdwn
 create mode 100644 doc/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name/comment_1_3bfde59729b904aa1ef815427dd35ae6._comment
 create mode 100644 doc/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name/comment_2_d08a955a11953cc783f09bfba180dbd6._comment
 create mode 100644 doc/forum/git_annex_windows_and_rsync.mdwn
 create mode 100644 doc/forum/git_annex_windows_and_rsync/comment_1_33249bf910446fcf98ffb2e7e35017bf._comment
 create mode 100644 doc/forum/git_annex_with_local_apache_webdav_server.mdwn
 create mode 100644 doc/forum/git_annex_with_local_apache_webdav_server/comment_1_a3b89f90f9ac70e0a9b0711ede1cb810._comment
 create mode 100644 doc/forum/git_annex_with_local_apache_webdav_server/comment_2_d8e9237cf6e7f7558f836ba1352f5517._comment
 create mode 100644 doc/forum/git_clone_over_ssh_hangs.mdwn
 create mode 100644 doc/forum/git_clone_over_ssh_hangs/comment_1_07ffe356ef5c441118cc9329060812f2._comment
 create mode 100644 doc/forum/git_lfs_special_remote_implementation.mdwn
 create mode 100644 doc/forum/git_lfs_special_remote_implementation/comment_1_a61494b02c831e84903f28d9900850ac._comment
 create mode 100644 doc/forum/git_pull_remote_git-annex.mdwn
 create mode 100644 doc/forum/git_pull_remote_git-annex/comment_1_9c245db3518d8b889ecdf5115ad9e053._comment
 create mode 100644 doc/forum/git_pull_remote_git-annex/comment_2_0f7f4a311b0ec1d89613e80847e69b42._comment
 create mode 100644 doc/forum/git_pull_remote_git-annex/comment_3_1aa89725b5196e40a16edeeb5ccfa371._comment
 create mode 100644 doc/forum/git_pull_remote_git-annex/comment_4_646f2077edcabc000a7d9cb75a93cf55._comment
 create mode 100644 doc/forum/git_pull_remote_git-annex/comment_5_4f2a05ef6551806dd0ec65372f183ca4._comment
 create mode 100644 doc/forum/git_pull_remote_git-annex/comment_6_3925d1aa56bce9380f712e238d63080f._comment
 create mode 100644 doc/forum/git_pull_remote_git-annex/comment_7_24c45ee981b18bc78325c768242e635d._comment
 create mode 100644 doc/forum/git_pull_remote_git-annex/comment_8_7e76ee9b6520cbffaf484c9299a63ad3._comment
 create mode 100644 doc/forum/git_status_is_slow_twice__44___then_fast.mdwn
 create mode 100644 doc/forum/git_status_is_slow_twice__44___then_fast/comment_1_a32e4d4255a1afcfd05c374d0fffccab._comment
 create mode 100644 doc/forum/git_status_is_slow_twice__44___then_fast/comment_2_1aba5ad6deb4634fca187ecc69a6adf9._comment
 create mode 100644 doc/forum/git_status_typechange_in_v5_direct_false.mdwn
 create mode 100644 doc/forum/git_status_typechange_in_v5_direct_false/comment_1_eb4e2b1fd7615e2b6936b5df01d68d1f._comment
 create mode 100644 doc/forum/git_status_typechange_in_v5_direct_false/comment_2_19df04820aa80549cfabac0141c372c0._comment
 create mode 100644 doc/forum/git_status_typechange_in_v5_direct_false/comment_3_20e04806a59e05a453431cb90086ccac._comment
 create mode 100644 doc/forum/git_tag_missing_for_3.20111011.mdwn
 create mode 100644 doc/forum/git_tag_missing_for_3.20111011/comment_1_7a53bf273f3078ab3351369ef2b5f2a6._comment
 create mode 100644 doc/forum/git_unannex_speed.mdwn
 create mode 100644 doc/forum/git_unannex_speed/comment_1_10cf326248f4e89e1f75bf97d7574763._comment
 create mode 100644 doc/forum/git_unlock_failed.mdwn
 create mode 100644 doc/forum/git_unlock_failed/comment_1_483dbd405b41b7bce343d7c08be8d92f._comment
 create mode 100644 doc/forum/git_unlock_failed/comment_2_76903b206b8cf6dced44a2da29f57201._comment
 create mode 100644 doc/forum/git_unlock_failed/comment_3_3331c627e0a48f8d2698b2bda1e0748f._comment
 create mode 100644 doc/forum/git_unlock_failed/comment_4_a24ddc8effd6983d6ed1d3a5e1c62b45._comment
 create mode 100644 doc/forum/git_unlock_failed/comment_5_e88de8c0fdd998236ba18a60d9308df8._comment
 create mode 100644 doc/forum/git_update-index_message_after_git-annex_get.mdwn
 create mode 100644 doc/forum/git_update-index_message_after_git-annex_get/comment_1_606b627b91a6e9864653ed86252b4bd7._comment
 create mode 100644 doc/forum/glacier_-_range_retrievals_and_daily_free_retrieval_allowance.mdwn
 create mode 100644 doc/forum/got_confused_by_fsck.mdwn
 create mode 100644 doc/forum/got_confused_by_fsck/comment_1_ab35fea4d46ee93e62ab67e5af3dfcbf._comment
 create mode 100644 doc/forum/got_confused_by_fsck/comment_2_19c730cb1337dc8794721cf5679c930b._comment
 create mode 100644 doc/forum/handling_MP3_metadata_changes.mdwn
 create mode 100644 doc/forum/handling_MP3_metadata_changes/comment_1_aa4955fd64ea5aa836f1a591e185c4a2._comment
 create mode 100644 doc/forum/hashing_objects_directories.mdwn
 create mode 100644 doc/forum/hashing_objects_directories/comment_1_c55c56076be4f54251b0b7f79f28a607._comment
 create mode 100644 doc/forum/hashing_objects_directories/comment_2_504c96959c779176f991f4125ea22009._comment
 create mode 100644 doc/forum/hashing_objects_directories/comment_3_9134bde0a13aac0b6a4e5ebabd7f22e8._comment
 create mode 100644 doc/forum/hashing_objects_directories/comment_4_0de9170e429cbfea66f5afa8980d45ac._comment
 create mode 100644 doc/forum/hashing_objects_directories/comment_5_ef6cfd49d24c180c2d0a062e5bd3a0be._comment
 create mode 100644 doc/forum/help__44___a_bunch_of_files_disappeared.mdwn
 create mode 100644 doc/forum/help__44___a_bunch_of_files_disappeared/comment_1_56cffd43ad7056a34c23b139f95ea58e._comment
 create mode 100644 doc/forum/help__44___a_bunch_of_files_disappeared/comment_2_7675ff78cf1b5f58618c5c57da8591b5._comment
 create mode 100644 doc/forum/help__44___a_bunch_of_files_disappeared/comment_3_4b700ccba2b40fdc1d172a3dcbc441e5._comment
 create mode 100644 doc/forum/help_running_git-annex_on_top_of_existing_repo.mdwn
 create mode 100644 doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_1_4cb38d71c943657c5ba0896cd70d2e64._comment
 create mode 100644 doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_2_b5e94c10ebbed9125c7e2332f75709ca._comment
 create mode 100644 doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_3_2b3b93bbc60fbc24d436231954d6822a._comment
 create mode 100644 doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_4_2dfda33ffa39b92b16c8bd9005e1cefe._comment
 create mode 100644 doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_5_96b1eb1e8e9f315c646f4686870f9b52._comment
 create mode 100644 doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_6_e85c3fa1d17f1d6ec625b9c4f9b698c3._comment
 create mode 100644 doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_7_15d918ededb5b8375b0ca13d0b3523ff._comment
 create mode 100644 doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_8_dcc3f2c6d55006776610e8d770b61d12._comment
 create mode 100644 doc/forum/help_with_building_git-annex_on_conda-forge.mdwn
 create mode 100644 doc/forum/help_with_building_git-annex_on_conda-forge/comment_1_369460f5de3219b80a7b2da5bda9aced._comment
 create mode 100644 doc/forum/help_with_building_git-annex_on_conda-forge/comment_2_e72eaf736e2a534fa5970183a2f671af._comment
 create mode 100644 doc/forum/how_do_automated_upgrades_work__63__.mdwn
 create mode 100644 doc/forum/how_do_automated_upgrades_work__63__/comment_1_cfd00ac3a3eaa3c2a1d430f6544c32f0._comment
 create mode 100644 doc/forum/how_do_automated_upgrades_work__63__/comment_2_5ef98e46c514e9b794ee719e4cc8fda4._comment
 create mode 100644 doc/forum/how_do_i_manually_sync_my_external_drive__63__.mdwn
 create mode 100644 doc/forum/how_do_i_manually_sync_my_external_drive__63__/comment_1_4fd8722cafd55b0503c802289206645a._comment
 create mode 100644 doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__.mdwn
 create mode 100644 doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__/comment_1_26d959bb3cfdc690b1eab41c9b0b5dc4._comment
 create mode 100644 doc/forum/how_to___34__move__34___URL_between_remotes__63__.mdwn
 create mode 100644 doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_1_d4fb3eff1b61c60224fec112df9f1136._comment
 create mode 100644 doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_2_c122906fd03bd723aa027fe32fd4fab6._comment
 create mode 100644 doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_3_adebe3ba65ba9fc0a4a7f4b664afc069._comment
 create mode 100644 doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_4_46ad0779ff71cfbadd663fe413d32ffb._comment
 create mode 100644 doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_5_712f40f27b27dfaf58c416ca7dc19045._comment
 create mode 100644 doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_6_260c238435f8f5e53511de7e574dd53f._comment
 create mode 100644 doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_7_742fde3d8f7aa0caa39dadc961c1b3d3._comment
 create mode 100644 doc/forum/how_to_commit_removed_files_as_repo-droped_entries.mdwn
 create mode 100644 doc/forum/how_to_commit_removed_files_as_repo-droped_entries/comment_1_a9a4baebfb647898a76ee3d5ab6febfd._comment
 create mode 100644 doc/forum/how_to_commit_removed_files_as_repo-droped_entries/comment_2_68392de15bae234de1332b8bc80cc2ff._comment
 create mode 100644 doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__.mdwn
 create mode 100644 doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_1_d4dc451892e7a6e230bf32adb7f3f9fa._comment
 create mode 100644 doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_2_79340bf3c0691073a9808c5ac2da0a3d._comment
 create mode 100644 doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_3_6302fb6e5bb7cbddf2cfe74d98d32897._comment
 create mode 100644 doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_4_e3d95bc09c9fb21e8e9bbacc642aa60f._comment
 create mode 100644 doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_5_f2f0a1c2fb0c6323707b11e2b06aa2db._comment
 create mode 100644 doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_6_66fe80e634a8f13cce18fe68974ec67a._comment
 create mode 100644 doc/forum/how_to_disaster_recovery.mdwn
 create mode 100644 doc/forum/how_to_disaster_recovery/comment_10_be3cf3736166855012e10c2d251043e9._comment
 create mode 100644 doc/forum/how_to_disaster_recovery/comment_11_7fa36912ae21a66d3174fec35356d7ba._comment
 create mode 100644 doc/forum/how_to_disaster_recovery/comment_12_f2e570dc60a6f16e8f696d94e253775f._comment
 create mode 100644 doc/forum/how_to_disaster_recovery/comment_1_c8db90fd7af13b9605e152ea884b5241._comment
 create mode 100644 doc/forum/how_to_disaster_recovery/comment_2_31cce673114eb9733e0f1c732c8f08e6._comment
 create mode 100644 doc/forum/how_to_disaster_recovery/comment_3_52ad88121efa92d2c64bb2816884d66b._comment
 create mode 100644 doc/forum/how_to_disaster_recovery/comment_4_444579d0dac2ca14e6b1cbadcca5fcf3._comment
 create mode 100644 doc/forum/how_to_disaster_recovery/comment_5_9b9403a80c5b0a1a441dfb94feece37d._comment
 create mode 100644 doc/forum/how_to_disaster_recovery/comment_6_e8ec7b1fbbb81d61d06a7def61b06354._comment
 create mode 100644 doc/forum/how_to_disaster_recovery/comment_7_7e08eb18e965f47782a39d0426b75b93._comment
 create mode 100644 doc/forum/how_to_disaster_recovery/comment_8_78720819bea58f30146451dd953f10a5._comment
 create mode 100644 doc/forum/how_to_disaster_recovery/comment_9_b16c74c0add6d15b75163859a752d207._comment
 create mode 100644 doc/forum/how_to_edit_the_git-annex_branch__63__.mdwn
 create mode 100644 doc/forum/how_to_edit_the_git-annex_branch__63__/comment_1_fa1936401d1abe1a28dc88968528e186._comment
 create mode 100644 doc/forum/how_to_force_read-only_in_enableremote__63__.mdwn
 create mode 100644 doc/forum/how_to_force_read-only_in_enableremote__63__/comment_1_a1206c8517f467d9a584ba89ef0e101a._comment
 create mode 100644 doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__.mdwn
 create mode 100644 doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_1_440dcd19ea2512f968858b780c2a2913._comment
 create mode 100644 doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_2_e9b70386774996a3d0446faaa3219120._comment
 create mode 100644 doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_3_3dbd76accad2df2fff14b55452c828ef._comment
 create mode 100644 doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_4_bfb4758fdb2a4afafd9c4d45de5c5c6b._comment
 create mode 100644 doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents.mdwn
 create mode 100644 doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents/comment_1_cba76311e146dabb8ffc789bf4c8b714._comment
 create mode 100644 doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents/comment_2_8d99c50fc1347367ccc0714e8d1af385._comment
 create mode 100644 doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents/comment_3_a7a9c55c2ad448179dff5d5b69976c7d._comment
 create mode 100644 doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit.mdwn
 create mode 100644 doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_1_a0551431a57ccab2463f2a6d43553337._comment
 create mode 100644 doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_2_e96e8cf6e08e3a21bfcefbc202e78fe2._comment
 create mode 100644 doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_3_2ad4c1a4bfe00c22444ab878c84a8830._comment
 create mode 100644 doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_4_44639388349a9ea5eabda9ebf79817b3._comment
 create mode 100644 doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_5_339123ab87b69b11d6e999ad6eaf6df5._comment
 create mode 100644 doc/forum/how_to_speed_up_metadata_view_genration.mdwn
 create mode 100644 doc/forum/how_to_speed_up_metadata_view_genration/comment_1_56044eef4cee8940a9bd5f66d2b1cd8f._comment
 create mode 100644 doc/forum/howto_to_link_to_existing_direct_mode_git-annexes.mdwn
 create mode 100644 doc/forum/howto_to_link_to_existing_direct_mode_git-annexes/comment_1_7bd0edaf2352293678f0942aaa885d13._comment
 create mode 100644 doc/forum/howto_update_feed.mdwn
 create mode 100644 doc/forum/howto_update_feed/comment_1_bec356619f370a618f19a187d09d2e35._comment
 create mode 100644 doc/forum/howto_update_feed/comment_2_84dfb80ba3db8d41164eb97022becae3._comment
 create mode 100644 doc/forum/howto_update_feed/comment_3_20166db298c10074e062aecad59ffd71._comment
 create mode 100644 doc/forum/howto_update_feed/comment_4_f040e31b763fc9a7aa092442b4d6b8e8._comment
 create mode 100644 doc/forum/huge_text_files___40__not_binary__41___-_compress.mdwn
 create mode 100644 doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_1_bd0925e056c275c52b59f947e23afe86._comment
 create mode 100644 doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_2_44eb5f14dbf3c5061afeb847958f27fe._comment
 create mode 100644 doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_3_4788a41425d4cc65e9f529dbcdb2bf73._comment
 create mode 100644 doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_4_4dbb0b18905d30ae6b187745859e75c2._comment
 create mode 100644 doc/forum/ignore_changes_made_by_a_remote.mdwn
 create mode 100644 doc/forum/ignore_changes_made_by_a_remote/comment_1_825676069d2e1554499b76fd8c306c30._comment
 create mode 100644 doc/forum/ignore_changes_made_by_a_remote/comment_2_dff49b72f7e072fddaf68584beb97f3c._comment
 create mode 100644 doc/forum/import_and_export_treeish_for_rsync_and_webdav.mdwn
 create mode 100644 doc/forum/import_and_export_treeish_for_rsync_and_webdav/comment_1_6a8ee189ff2fee0697b67a405f22c5a4._comment
 create mode 100644 doc/forum/importfeed__58___comments_in_file_with_feed_urls.mdwn
 create mode 100644 doc/forum/importfeed__58___comments_in_file_with_feed_urls/comment_1_370f5165fdda5c01a5335c864321a348._comment
 create mode 100644 doc/forum/importfeed_does_not_work_with_youtube_anymore.mdwn
 create mode 100644 doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_1_2fcbc85d7aa51dfdb2025a00c37fa8ac._comment
 create mode 100644 doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_2_58733a5065493dbac5cb8d12a029dace._comment
 create mode 100644 doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_3_aef7c172d485f8f6570ada5756446480._comment
 create mode 100644 doc/forum/importfeed_loads_files_a_second_time_prepending_a_2__95__.mdwn
 create mode 100644 doc/forum/importfeed_loads_files_a_second_time_prepending_a_2__95__/comment_1_1623344457fbe10c464506e41fbac3d8._comment
 create mode 100644 doc/forum/importfeed_on_multiple___34__overlapping__34___playlists.mdwn
 create mode 100644 doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_1_ecd0764e7f15469217fd5e04a563f34c._comment
 create mode 100644 doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_2_b9885808ebe447c26283f910f4fc37c3._comment
 create mode 100644 doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_3_aa1077117a83ecffccb8d2095818fa02._comment
 create mode 100644 doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_4_0bf6d5b03032c0b9fd35c8410aea832c._comment
 create mode 100644 doc/forum/include__61__subdir__47____42___in_prefererred_content_expression_not_working.mdwn
 create mode 100644 doc/forum/incompatible_versions__63__.mdwn
 create mode 100644 doc/forum/incompatible_versions__63__/comment_1_629f28258746d413e452cbd42a1a43f4._comment
 create mode 100644 doc/forum/initremote_type__61__web.mdwn
 create mode 100644 doc/forum/initremote_type__61__web/comment_1_9ad92da9525cd89e515d1c5745a59c13._comment
 create mode 100644 doc/forum/initremote_type__61__web/comment_2_acc1dce80c3ed3b13fdfba55ab362581._comment
 create mode 100644 doc/forum/initremote_type__61__web/comment_3_b222de7b3d4397fe8bcafd20c661bc64._comment
 create mode 100644 doc/forum/initremote_type__61__web/comment_4_d128b2abef6cfdcac679aeff7a52d493._comment
 create mode 100644 doc/forum/initremote_type__61__web/comment_5_8de26c367ccb68b917b0b5f91eec8d1a._comment
 create mode 100644 doc/forum/is_it_possible_to_use_github_with_git-lfs_special_remote_within_the_assistant___40__android__41____63__.mdwn
 create mode 100644 doc/forum/is_it_possible_to_use_github_with_git-lfs_special_remote_within_the_assistant___40__android__41____63__/comment_1_d9e0c9471c14178a1b3d07d3c6d76897._comment
 create mode 100644 doc/forum/is_it_possible_to_use_github_with_git-lfs_special_remote_within_the_assistant___40__android__41____63__/comment_2_a73cbde4297d1be734c768d7b8f9d597._comment
 create mode 100644 doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__.mdwn
 create mode 100644 doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/comment_1_82820ce711b87b092a21e31fd381ffce._comment
 create mode 100644 doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/comment_2_160e80583b647eae53aa120ca734e34a._comment
 create mode 100644 doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/comment_3_6d81a41edf052e310e1f80cc6add3c09._comment
 create mode 100644 doc/forum/is_there_a_way_to_only_commit_some_files_in_direct-mode___63__.mdwn
 create mode 100644 doc/forum/is_there_a_way_to_only_commit_some_files_in_direct-mode___63__/comment_1_804e43111ee97dff15e49e50b6c29d91._comment
 create mode 100644 doc/forum/is_there_a_way_to_only_commit_some_files_in_direct-mode___63__/comment_2_299ad6cd0225daa166d36af3726a9ef2._comment
 create mode 100644 doc/forum/is_windows_really_slow__63__.mdwn
 create mode 100644 doc/forum/journal.lck_became_readonly_after_really_long_fsck.mdwn
 create mode 100644 doc/forum/journal.lck_became_readonly_after_really_long_fsck/comment_1_6c094472d7f6f5f0257a445805200a82._comment
 create mode 100644 doc/forum/keys__44___URLs_and_URIs.mdwn
 create mode 100644 doc/forum/keys__44___URLs_and_URIs/comment_1_d285566ca97e720a7bb497c0db8cc0c2._comment
 create mode 100644 doc/forum/known_and_local_annex_keys.mdwn
 create mode 100644 doc/forum/known_and_local_annex_keys/comment_1_3cb4828dc7116e4cf49e119f055ae9a3._comment
 create mode 100644 doc/forum/known_and_local_annex_keys/comment_2_68f20c881eafe986694bde10571cf1c0._comment
 create mode 100644 doc/forum/known_and_local_annex_keys/comment_3_e195a7091a06ce0427bb28aca9a17d04._comment
 create mode 100644 doc/forum/known_and_local_annex_keys/comment_4_d81f0bf7465832cb676fd89f5d53ec18._comment
 create mode 100644 doc/forum/largefiles__58___fail-on-unspecified_mode__63__.mdwn
 create mode 100644 doc/forum/largefiles__58___fail-on-unspecified_mode__63__/comment_1_0bddf22d95cccf68a2852d7ef3a6dc19._comment
 create mode 100644 doc/forum/library__44___backup_and_music_player.mdwn
 create mode 100644 doc/forum/library__44___backup_and_music_player/comment_1_a6e38a1678c433e5a5d96afae4ae4332._comment
 create mode 100644 doc/forum/linux_standalone_tarballs.mdwn
 create mode 100644 doc/forum/linux_standalone_tarballs/comment_1_5c3ceb845a45e50784f7098bfbf94df1._comment
 create mode 100644 doc/forum/local_pairing_with_2_mac.mdwn
 create mode 100644 doc/forum/local_pairing_with_2_mac/comment_10_508585e72c81d197a9a1e193c25a702a._comment
 create mode 100644 doc/forum/local_pairing_with_2_mac/comment_1_6ca4fed183340a2902d1d4d91284b772._comment
 create mode 100644 doc/forum/local_pairing_with_2_mac/comment_2_7c2b3d0a8a69c7056508f8ec73ebefcd._comment
 create mode 100644 doc/forum/local_pairing_with_2_mac/comment_3_07fa468aac1288e770487973052bccea._comment
 create mode 100644 doc/forum/local_pairing_with_2_mac/comment_4_dc0494213d2b57b5b9a489b096a5b8d0._comment
 create mode 100644 doc/forum/local_pairing_with_2_mac/comment_5_bcac18e137c00d4279774dec51963289._comment
 create mode 100644 doc/forum/local_pairing_with_2_mac/comment_6_76b62eafda1ecbf88abe288cbe778e17._comment
 create mode 100644 doc/forum/local_pairing_with_2_mac/comment_7_13fe788f2e9a823ad2e4844f114675a7._comment
 create mode 100644 doc/forum/local_pairing_with_2_mac/comment_8_f81b454e9cfc14dcb33148798be55de3._comment
 create mode 100644 doc/forum/local_pairing_with_2_mac/comment_9_f7a1ce9627ebfc854dfde2f6c924db80._comment
 create mode 100644 doc/forum/local_subtree_and_broken_symlinks.mdwn
 create mode 100644 doc/forum/local_subtree_and_broken_symlinks/comment_1_779cc4e49cb4da8aea7f5743e6257f21._comment
 create mode 100644 doc/forum/location_tracking_cleanup.mdwn
 create mode 100644 doc/forum/location_tracking_cleanup/comment_1_7d6319e8c94dfe998af9cfcbf170efb2._comment
 create mode 100644 doc/forum/location_tracking_cleanup/comment_2_e7395cb6e01f42da72adf71ea3ebcde4._comment
 create mode 100644 doc/forum/location_tracking_cleanup/comment_3_c15428cec90e969284a5e690fb4b2fde._comment
 create mode 100644 doc/forum/locks_during_--batch_operations.mdwn
 create mode 100644 doc/forum/locks_during_--batch_operations/comment_1_190f6a52d9e49b2a092ad4c848e9d0b4._comment
 create mode 100644 doc/forum/locks_during_--batch_operations/comment_2_b19ed6657064c11bf54673f1b2ff4860._comment
 create mode 100644 doc/forum/long_paths_on_windows_10_-_workaround.mdwn
 create mode 100644 doc/forum/lost_in_walkthrough.mdwn
 create mode 100644 doc/forum/lost_in_walkthrough/comment_1_51b703b961ca762f0359e1c169f1ee75._comment
 create mode 100644 doc/forum/lost_in_walkthrough/comment_2_a9de0401a103bdd4401ba2d5983dc54a._comment
 create mode 100644 doc/forum/lsof_resource_use_problems.mdwn
 create mode 100644 doc/forum/lsof_resource_use_problems/comment_1_a5e5d410545fa7f93f08936ec6aeee42._comment
 create mode 100644 doc/forum/lsof_resource_use_problems/comment_2_7b0d4109c04c47e65420105f0de3b7a2._comment
 create mode 100644 doc/forum/luks_encrypted_disk_support.mdwn
 create mode 100644 doc/forum/luks_encrypted_disk_support/comment_1_0ea476c778888f34196d9031f72b1844._comment
 create mode 100644 doc/forum/luks_encrypted_disk_support/comment_2_0af149bfe1868dde0a132c5d835c50df._comment
 create mode 100644 doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move.mdwn
 create mode 100644 doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_1_018cb2fd618a448088d9e91e4872333d._comment
 create mode 100644 doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_2_fdfd1d1ded3fb98a83f2593605250a87._comment
 create mode 100644 doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_3_369daddf95ab43f2c3d6b81c35810c19._comment
 create mode 100644 doc/forum/make_a_snapshot_backup_into_a___34__remote__34__.mdwn
 create mode 100644 doc/forum/make_a_snapshot_backup_into_a___34__remote__34__/comment_1_4974480f1c75152a05c2305d21ed1842._comment
 create mode 100644 doc/forum/make_a_snapshot_backup_into_a___34__remote__34__/comment_2_e18fba58bcd5259125e6e36194234136._comment
 create mode 100644 doc/forum/making_good_use_of_my_shiny_new_rsync.net_account.mdwn
 create mode 100644 doc/forum/making_good_use_of_my_shiny_new_rsync.net_account/comment_1_0ebe509b768d46081db2100f5b712ef7._comment
 create mode 100644 doc/forum/making_good_use_of_my_shiny_new_rsync.net_account/comment_2_ef63d893531d93d2eb09f48f8baff4dd._comment
 create mode 100644 doc/forum/man_pages_in_the_prebuilt_linux_tarball.mdwn
 create mode 100644 doc/forum/man_pages_in_the_prebuilt_linux_tarball/comment_1_a7bc2e84e6d7c0e2de5900685207af78._comment
 create mode 100644 doc/forum/manage_repository_connection_between_external_HDD_and_server.mdwn
 create mode 100644 doc/forum/manage_repository_connection_between_external_HDD_and_server/comment_1_ba8ed548bf228a7d1c82b68283f99a5b._comment
 create mode 100644 doc/forum/managing_git-annex_with_java.mdwn
 create mode 100644 doc/forum/managing_git-annex_with_java/comment_1_fd12f0d0727b5bdddef1d7ef6236fe57._comment
 create mode 100644 doc/forum/managing_multiple_repositories.mdwn
 create mode 100644 doc/forum/manual_update_of_.git__47__annex__47__objects.mdwn
 create mode 100644 doc/forum/manual_update_of_.git__47__annex__47__objects/comment_1_ea6ec91150c8962e2711631f2422bf3a._comment
 create mode 100644 doc/forum/manual_update_of_.git__47__annex__47__objects/comment_2_a7bbf304b26650a786e358bdc01e3069._comment
 create mode 100644 doc/forum/manual_update_of_.git__47__annex__47__objects/comment_3_a855096b683c4c4f84e72c797e065d59._comment
 create mode 100644 doc/forum/many_remotes.mdwn
 create mode 100644 doc/forum/mesh_configurations.mdwn
 create mode 100644 doc/forum/mesh_configurations/comment_10_dc99216ee2fc0bd3d43234915a0305ab._comment
 create mode 100644 doc/forum/mesh_configurations/comment_1_0712fa3d50ca6092bd7d98c945b5cc31._comment
 create mode 100644 doc/forum/mesh_configurations/comment_2_0d9ba4017343475a96975145c9db29c5._comment
 create mode 100644 doc/forum/mesh_configurations/comment_3_d228158cf00cd04dc9ef5602acebdaac._comment
 create mode 100644 doc/forum/mesh_configurations/comment_4_d5c8e99cadf976434460d6d0f410136e._comment
 create mode 100644 doc/forum/mesh_configurations/comment_5_a181fde7b7f6d0559331e1afa395ba0a._comment
 create mode 100644 doc/forum/mesh_configurations/comment_6_7cb33d2416289f744828d8d9d24e9ef6._comment
 create mode 100644 doc/forum/mesh_configurations/comment_7_6c9d499f64067ee9d3721dc763f3c425._comment
 create mode 100644 doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment
 create mode 100644 doc/forum/mesh_configurations/comment_9_ac3e1faaefaed222f725345ab4b5f01a._comment
 create mode 100644 doc/forum/messed_up_annex_by_using_git_checkout.mdwn
 create mode 100644 doc/forum/messed_up_annex_by_using_git_checkout/comment_1_04f33895f6451690372595c576be2811._comment
 create mode 100644 doc/forum/metadata_limits.mdwn
 create mode 100644 doc/forum/metadata_limits/comment_1_a20bbe49f2f23d23131221ec79c8b973._comment
 create mode 100644 doc/forum/metadata_limits/comment_2_4e8995ccd5fc2e5ee5d89a0780e5df9d._comment
 create mode 100644 doc/forum/migrate_existing_git_repository_to_git-annex.mdwn
 create mode 100644 doc/forum/migrate_existing_git_repository_to_git-annex/comment_1_4181bf34c71e2e8845e6e5fb55d53381._comment
 create mode 100644 doc/forum/migrate_existing_git_repository_to_git-annex/comment_2_5f08da5e21c0b3b5a8d1e4408c0d6405._comment
 create mode 100644 doc/forum/migrate_existing_git_repository_to_git-annex/comment_3_f483038c006cf7dcccf1014fa771744f._comment
 create mode 100644 doc/forum/migrate_existing_git_repository_to_git-annex/comment_4_057f0079fbee3451ccda08026bab21d4._comment
 create mode 100644 doc/forum/migration_to_git-annex_and_rsync.mdwn
 create mode 100644 doc/forum/misctmp_filling_up.mdwn
 create mode 100644 doc/forum/misctmp_filling_up/comment_1_2739dec72fe0950dd070c8fab9fbd751._comment
 create mode 100644 doc/forum/misctmp_filling_up/comment_2_440081b5e2b9b5b19e8cd5db3649a976._comment
 create mode 100644 doc/forum/misctmp_filling_up/comment_3_b6ab64f02f204fc7e8741b9c04c5349d._comment
 create mode 100644 doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer.mdwn
 create mode 100644 doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_1_752db25abb647804a1cc12c5b247378a._comment
 create mode 100644 doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_2_db6f4959c35732f72e7a90bd9f4c665c._comment
 create mode 100644 doc/forum/monitoring_disk_usage_by_different_repos_on_same_drive.mdwn
 create mode 100644 doc/forum/monitoring_disk_usage_by_different_repos_on_same_drive/comment_1_04718e5f87a7e0521a3165bc9fc951a8._comment
 create mode 100644 doc/forum/more_intelligent_copy_.mdwn
 create mode 100644 doc/forum/more_intelligent_copy_/comment_1_526f6a007f44f389ef7c904024752541._comment
 create mode 100644 doc/forum/more_intelligent_copy_/comment_2_7b3f5d2e9de4b13de821177db2f57bcd._comment
 create mode 100644 doc/forum/move_files_under_git-annex_and_graft_history__63__.mdwn
 create mode 100644 doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_1_345f9a32f5fc1ea21af9fe18f902d1b0._comment
 create mode 100644 doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_2_aab850db06cbd3c33067cff567d2699e._comment
 create mode 100644 doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_3_4cff971451dd7038ffe8f7f2fa3b28c9._comment
 create mode 100644 doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_4_73e37a27ae3ff6673f34d8b1a6bed4a0._comment
 create mode 100644 doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_5_d536cb5c2622d18802e6a32b03102f14._comment
 create mode 100644 doc/forum/moving_annex_across_filesystems.mdwn
 create mode 100644 doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository.mdwn
 create mode 100644 doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_1_419b27cb1c71bce021ef9f2e471aa92e._comment
 create mode 100644 doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_2_dae4c7a42080dd89150159b2946839b1._comment
 create mode 100644 doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_3_9d9fa65559ba4bb0e4676289b5a65684._comment
 create mode 100644 doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_4_4e89b3590cc33b2565cd173ef7c85013._comment
 create mode 100644 doc/forum/multiple_repositories_single_backup.mdwn
 create mode 100644 doc/forum/multiple_repositories_single_backup/comment_1_4a479fa78e0b366fcff1a27bc37081de._comment
 create mode 100644 doc/forum/multiple_repositories_single_backup/comment_2_bbe19eec0969385a0d4682bf9e9de21a._comment
 create mode 100644 doc/forum/multiple_repositories_single_backup/comment_3_1b18ea058e3eb34852055cffe51de176._comment
 create mode 100644 doc/forum/multiple_routes_to_same_repository.mdwn
 create mode 100644 doc/forum/multiple_routes_to_same_repository/comment_1_26c1734d41d5374f18fc688d862d6b8e._comment
 create mode 100644 doc/forum/multiple_routes_to_same_repository/comment_2_d119ab485fb2d5512c15372efdb2327d._comment
 create mode 100644 doc/forum/multiple_sym_links___40__for_tagging_photos__41____63__.mdwn
 create mode 100644 doc/forum/multiple_sym_links___40__for_tagging_photos__41____63__/comment_1_96beb9ea895c80285748adb940b4f57d._comment
 create mode 100644 doc/forum/multiple_sym_links___40__for_tagging_photos__41____63__/comment_2_985065c1feed9300631dac7a2701f669._comment
 create mode 100644 doc/forum/multiple_urls_for_the_same_UUID.mdwn
 create mode 100644 doc/forum/multiple_urls_for_the_same_UUID/comment_1_de7410d8824a864c4d106c9f1afaec3f._comment
 create mode 100644 doc/forum/multiple_urls_for_the_same_UUID/comment_2_309a86cf7e08448be64357a30d8b56ae._comment
 create mode 100644 doc/forum/multiple_urls_for_the_same_UUID/comment_3_fa97a45fc1392935fd5e0714db999bc2._comment
 create mode 100644 doc/forum/multiple_urls_for_the_same_UUID/comment_4_139178b1ba45b62eec0c89a660c0c81e._comment
 create mode 100644 doc/forum/multiple_urls_for_the_same_UUID/comment_5_7237986a34228282c6b764309afc1d57._comment
 create mode 100644 doc/forum/multiple_urls_for_the_same_UUID/comment_6_392819ba657569a1b997b58aa921a0ad._comment
 create mode 100644 doc/forum/multiple_urls_for_the_same_UUID/comment_7_276cb5d94cbd10e9fc7d1cf4ac607273._comment
 create mode 100644 doc/forum/multiple_urls_for_the_same_UUID/comment_8_c44144c677d54aaea6e900d0d7e000a3._comment
 create mode 100644 doc/forum/multiple_urls_for_the_same_UUID/comment_9_38f3007635b0a7b7d30bad0af8a2d0a9._comment
 create mode 100644 doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__.mdwn
 create mode 100644 doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_1_ac45ad341f026289ce56183b9ff463af._comment
 create mode 100644 doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_53e0ffe901a1a1c22361bfd7cf71affd._comment
 create mode 100644 doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_f7416c26daca543ad08c11e187e1589e._comment
 create mode 100644 doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_4_9c6386710387f7334ea44c1de7cc8729._comment
 create mode 100644 doc/forum/name_resolution_of_dne.mdwn
 create mode 100644 doc/forum/name_resolution_of_dne/comment_1_7309e109d1f6eba8fc92659372d64b19._comment
 create mode 100644 doc/forum/name_resolution_of_dne/comment_2_54ed13db673cff7177cd371143a295b4._comment
 create mode 100644 doc/forum/named_pipes_as_arguments.mdwn
 create mode 100644 doc/forum/named_pipes_as_arguments/comment_1_0fff7a842609af3531d151425a94df0a._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build.mdwn
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_10_5f9735ec62478c99b8c814055206cff0._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_11_859c44046b00fe885f6878cfe0e46360._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_12_35ade68d62e95036344ad33db3279c21._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_13_36f48c30894b9b225b812ba5e5b2f504._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_14_67021b6d239690c9d18e8630aa2254ff._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_15_646a19555f982fb7ab302289400adc3d._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_16_442015225a14f60064aa3ba3cfbdf2ae._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_17_653448e38c3bb71a97023cb5d6b21af6._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_18_0a76ce3895ba9598bd79625268d95ef4._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_1_7211ddc626bae97d4140c723c3cf028f._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_2_fcbe3f7fa9d012b21c7a771553fa9142._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_3_2702cdbae4179a7a103d2a7098a8ed5e._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_4_e1d802fbcc9d699ece5267e80990255a._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_5_257b91ecbf5a6040a8e4c9a360c775ba._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_6_bd8cca86a63be7e330111618c1959a74._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_7_6814bdeca94328fe6c3f407795ff923a._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_8_6db99d998ca990494c8f2826ff1ca273._comment
 create mode 100644 doc/forum/new_linux_arm_tarball_build/comment_9_2802b24ccb24f1615c9d61904f916d05._comment
 create mode 100644 doc/forum/new_microfeatures.mdwn
 create mode 100644 doc/forum/new_microfeatures/comment_1_058bd517c6fffaf3446b1f5d5be63623._comment
 create mode 100644 doc/forum/new_microfeatures/comment_2_41ad904c68e89c85e1fc49c9e9106969._comment
 create mode 100644 doc/forum/new_microfeatures/comment_3_a1a9347b5bc517f2a89a8b292c3f8517._comment
 create mode 100644 doc/forum/new_microfeatures/comment_4_5a6786dc52382fff5cc42fdb05770196._comment
 create mode 100644 doc/forum/new_microfeatures/comment_5_3c627d275586ff499d928a8f8136babf._comment
 create mode 100644 doc/forum/new_microfeatures/comment_6_31ea08c008500560c0b96c6601bc6362._comment
 create mode 100644 doc/forum/new_microfeatures/comment_7_94045b9078b1fff877933b012d1b49e2._comment
 create mode 100644 doc/forum/nntp__47__usenet_special_remote.mdwn
 create mode 100644 doc/forum/nntp__47__usenet_special_remote/comment_1_171a0b95b1f95cfd82073e88bdefaab9._comment
 create mode 100644 doc/forum/nntp__47__usenet_special_remote/comment_2_48736ed17c98ffcfb13ec00b901b2dd6._comment
 create mode 100644 doc/forum/non-bare_repo_on_cloud_remote.mdwn
 create mode 100644 doc/forum/non-bare_repo_on_cloud_remote/comment_1_da0c023af7c78f1ef1cfe1143a900a9f._comment
 create mode 100644 doc/forum/non-bare_repo_on_cloud_remote/comment_2_71baea93f6caaf7b81a9ac00bee91e5e._comment
 create mode 100644 doc/forum/non_fast_forward_error_with_git_annex_sync.mdwn
 create mode 100644 doc/forum/non_fast_forward_error_with_git_annex_sync/comment_1_48d66e5314de5b6a26f78622a4e93ba6._comment
 create mode 100644 doc/forum/non_fast_forward_error_with_git_annex_sync/comment_2_f7101a8e84bbbfb2fbea6c65ca62fdb9._comment
 create mode 100644 doc/forum/non_fast_forward_error_with_git_annex_sync/comment_3_bbb3a5572fa2427d9bf859ae1ba68764._comment
 create mode 100644 doc/forum/noob_question._VPS_web_assistant.mdwn
 create mode 100644 doc/forum/noob_question._VPS_web_assistant/comment_1_49f349192d64048753bedcf10ee22355._comment
 create mode 100644 doc/forum/not_finding_git-annex-shell_on_remote.mdwn
 create mode 100644 doc/forum/not_finding_git-annex-shell_on_remote/comment_1_84881cad02c251a2515cec50fc22bf16._comment
 create mode 100644 doc/forum/not_finding_git-annex-shell_on_remote/comment_2_f32412f8d3b84cd5cb3c4d5d6bb60f32._comment
 create mode 100644 doc/forum/not_finding_git-annex-shell_on_remote/comment_3_dfbf7f41dd4d17f2ce8b67daa9dcd11d._comment
 create mode 100644 doc/forum/not_finding_git-annex-shell_on_remote/comment_4_71ae60efcacdba5e11548923b2c85b95._comment
 create mode 100644 doc/forum/not_getting_file_contents.mdwn
 create mode 100644 doc/forum/not_getting_file_contents/comment_1_4a0f7f4de9c9bc4d13db033cb75d20af._comment
 create mode 100644 doc/forum/not_getting_file_contents/comment_2_dc7403e1b551552f9fd00da6a1453570._comment
 create mode 100644 doc/forum/notify-start_and_notify-finish_for_the_assistant.mdwn
 create mode 100644 doc/forum/notify-start_and_notify-finish_for_the_assistant/comment_1_d3da4ce5cfea6c0a3277e83e0181102d._comment
 create mode 100644 doc/forum/notify-start_and_notify-finish_for_the_assistant/comment_2_01dfd865c469a5bc465f73347a65ce44._comment
 create mode 100644 doc/forum/offsite_repo.mdwn
 create mode 100644 doc/forum/offsite_repo/comment_1_1f3ab9a39baa16e3e307b23fd1aabeb8._comment
 create mode 100644 doc/forum/offsite_repo/comment_2_d4ecd0dc29597e3e0988e06ee9c4d245._comment
 create mode 100644 doc/forum/offsite_repo/comment_3_4b233762116c52bd2a754f49152201b7._comment
 create mode 100644 doc/forum/offsite_repo/comment_4_2e3dfd605df004330396040737a7c5ee._comment
 create mode 100644 doc/forum/offsite_repo/comment_5_59a7718fde634c96dd781ed5fca1f61a._comment
 create mode 100644 doc/forum/one-off_unlocked_annex_files_that_go_against_large.mdwn
 create mode 100644 doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_1_9e4604f3c7ca9be1fe6a7020fee2fd96._comment
 create mode 100644 doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_2_9bd32b89d0521fd1bec94683dffb4ecd._comment
 create mode 100644 doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_3_3c3c4b9ee0a99f0638717922785de675._comment
 create mode 100644 doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_4_8d1ba01f4e25606b960023eab38ec483._comment
 create mode 100644 doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_5_789e8ada06063f6a1c6d6358180dc202._comment
 create mode 100644 doc/forum/one_annex_versus_many_annexes__63__.mdwn
 create mode 100644 doc/forum/one_or_many_annexes__63__.mdwn
 create mode 100644 doc/forum/one_or_many_annexes__63__/comment_1_656d96011801d67a45b0b3bb3d70fa63._comment
 create mode 100644 doc/forum/only_keep_current_version_of_files_in_repo.mdwn
 create mode 100644 doc/forum/only_keep_current_version_of_files_in_repo/comment_1_dd03f7cd46a8c12a34e2b1cf78e7a057._comment
 create mode 100644 doc/forum/only_keep_current_version_of_files_in_repo/comment_2_b45120f0a11428b75c099ca3d85d9016._comment
 create mode 100644 doc/forum/optimising_lookupkey.mdwn
 create mode 100644 doc/forum/optimising_lookupkey/comment_1_e06db4754805c1e0ee298ecc676427d2._comment
 create mode 100644 doc/forum/optimising_lookupkey/comment_2_7dbfa3da6ae72a1f0669396664dd0c1a._comment
 create mode 100644 doc/forum/optimising_lookupkey/comment_3_2c895e4494cddab70ba761c6c48e7cf8._comment
 create mode 100644 doc/forum/original_filename_on_s3.mdwn
 create mode 100644 doc/forum/original_filename_on_s3/comment_1_870f3f01f95b5878d483ffedd2ae2698._comment
 create mode 100644 doc/forum/original_filename_on_s3/comment_2_2a0d5d77219ae2410090eb1811ee1fec._comment
 create mode 100644 doc/forum/original_filename_on_s3/comment_3_0aea0eef336dd648013a9cf7789fc445._comment
 create mode 100644 doc/forum/othertmp__58___createDirectory__58___already_exists.mdwn
 create mode 100644 doc/forum/othertmp__58___createDirectory__58___already_exists/comment_1_6fb34a361417e4cac08edc20fd2bc3e7._comment
 create mode 100644 doc/forum/othertmp__58___createDirectory__58___already_exists/comment_2_0a9372f3dba83b6cee3a33933bf2b006._comment
 create mode 100644 doc/forum/overmounting_repository_at_home.mdwn
 create mode 100644 doc/forum/overmounting_repository_at_home/comment_1_399ac5014c489698e1e45deec4db7311._comment
 create mode 100644 doc/forum/overmounting_repository_at_home/comment_2_d006d89ba204568cdee0731b6251ec1a._comment
 create mode 100644 doc/forum/overmounting_repository_at_home/comment_3_3734b50c37cbec675813cbeca7bf4ce9._comment
 create mode 100644 doc/forum/overwrite_files_with_export_to_special_remote.mdwn
 create mode 100644 doc/forum/overwrite_files_with_export_to_special_remote/comment_1_8091fc1d63ad0a96e086c91a26e2af70._comment
 create mode 100644 doc/forum/partial_annex_repository.mdwn
 create mode 100644 doc/forum/partial_annex_repository/comment_1_5e594914724a04e21087e1e4e57c2d30._comment
 create mode 100644 doc/forum/partial_annex_repository/comment_2_e6a9584bacc3ec98c4757c82a195b414._comment
 create mode 100644 doc/forum/partial_synchronisation._android_phone.mdwn
 create mode 100644 doc/forum/partial_synchronisation._android_phone/comment_1_2a48569277945a9c334bdfc51f8fd01f._comment
 create mode 100644 doc/forum/partial_synchronisation._android_phone/comment_2_550ae91c8a1fe060368c4682d37514b6._comment
 create mode 100644 doc/forum/people__39__s_experience_with_parallel_git-annex_operations.mdwn
 create mode 100644 doc/forum/people__39__s_experience_with_parallel_git-annex_operations/comment_1_5f3b51692797f56656f313e8455c1b5f._comment
 create mode 100644 doc/forum/performance_and_multiple_replication_problems.mdwn
 create mode 100644 doc/forum/performance_and_multiple_replication_problems/comment_1_a2cdf1a4840f099f6bc941fd8de966c7._comment
 create mode 100644 doc/forum/performance_and_multiple_replication_problems/comment_2_e65b360706c66ede6e0e841b2ebbbfbc._comment
 create mode 100644 doc/forum/performance_and_multiple_replication_problems/comment_3_ad7cb4c510e2ab26959ea7cb40a43fef._comment
 create mode 100644 doc/forum/performance_and_multiple_replication_problems/comment_4_23a6dc7ea569944ca55bd21851dd770d._comment
 create mode 100644 doc/forum/performance_and_multiple_replication_problems/comment_5_8df6cc8b72e0e78c7380f7d471124498._comment
 create mode 100644 doc/forum/performance_for_FTP_site_mirroring.mdwn
 create mode 100644 doc/forum/performance_for_FTP_site_mirroring/comment_1_7648fced001ce1c34726e913e06273e9._comment
 create mode 100644 doc/forum/performance_for_FTP_site_mirroring/comment_2_fa2b7400c85356d4de6da8459a5c3b50._comment
 create mode 100644 doc/forum/performance_for_FTP_site_mirroring/comment_3_cb4d7b283f20b43283036f20ebc648ec._comment
 create mode 100644 doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk.mdwn
 create mode 100644 doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_1_b3f22f9be02bc4f2d5a121db3d753ff5._comment
 create mode 100644 doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_2_f94abce32ef818176b42a3cc860691ae._comment
 create mode 100644 doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_3_0c8e77fe248e00bd990d568623e5a5c9._comment
 create mode 100644 doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_4_4b7e8f9521d61900d9ad418e74808ffb._comment
 create mode 100644 doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_5_7abbbe7db3988a2d239d11b0a4c597e7._comment
 create mode 100644 doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_6_46bd45fdc25d9c583f4ebe3a9730ab9f._comment
 create mode 100644 doc/forum/pgp_issue_in_log_file_after_upgrade_to_5.20140517.mdwn
 create mode 100644 doc/forum/pgp_issue_in_log_file_after_upgrade_to_5.20140517/comment_1_807d7da99f732f2fa5f9d3cb1ba9f1a1._comment
 create mode 100644 doc/forum/pgp_issue_in_log_file_after_upgrade_to_5.20140517/comment_2_92a7509fc42ab2347d57f080081d14b5._comment
 create mode 100644 doc/forum/possible_gpg_issue.mdwn
 create mode 100644 doc/forum/possible_gpg_issue/comment_1_c5a33ff375cddd001e6cb7be8d0ce940._comment
 create mode 100644 doc/forum/possible_gpg_issue/comment_2_e5ea7fc9be496f71516a238522193744._comment
 create mode 100644 doc/forum/possible_gpg_issue/comment_3_d505b6e5050d2afa7c8543e21918193d._comment
 create mode 100644 doc/forum/possible_gpg_issue/comment_4_e52099d461d0df99040f664a3af23caf._comment
 create mode 100644 doc/forum/possible_gpg_issue/comment_5_a0c8afc2d8583d30073b62396b254a6e._comment
 create mode 100644 doc/forum/possible_gpg_issue/comment_6_2a0120d6b586594cfd9baabbd6605373._comment
 create mode 100644 doc/forum/possible_gpg_issue/comment_7_f095eadcd9f6947f64e6830acea8228e._comment
 create mode 100644 doc/forum/post-copy__47__sync_hook.mdwn
 create mode 100644 doc/forum/post-copy__47__sync_hook/comment_1_c8322d4b9bbf5eac80b48c312a42fbcf._comment
 create mode 100644 doc/forum/pre-commit_hook_to_use_git_annex_for_only_large_files.mdwn
 create mode 100644 doc/forum/pre-commit_hook_to_use_git_annex_for_only_large_files/comment_1_01db183b1f1d081066d88332e2b6166a._comment
 create mode 100644 doc/forum/pre-commit_hook_to_use_git_annex_for_only_large_files/comment_2_2b76809869e0289f78f137afbdcf36c8._comment
 create mode 100644 doc/forum/preferred_content.mdwn
 create mode 100644 doc/forum/preferred_content/comment_1_9c9e5f2ee5ae4d8459358ad16f879ef1._comment
 create mode 100644 doc/forum/preferred_content_globs_question.mdwn
 create mode 100644 doc/forum/preferred_content_globs_question/comment_1_de4212f2e70fde49063b45b33498ade7._comment
 create mode 100644 doc/forum/preferred_content_settings_for_multiple_symlinks.mdwn
 create mode 100644 doc/forum/preferred_content_settings_for_multiple_symlinks/comment_1_70da012d96ab576151fe3e081ef905d1._comment
 create mode 100644 doc/forum/preferred_content_settings_for_multiple_symlinks/comment_2_ccea74d8b5a4de1f3cd1f6da6694ae0e._comment
 create mode 100644 doc/forum/preferred_content_settings_for_multiple_symlinks/comment_3_fab70c642d5aaf26de05270860281030._comment
 create mode 100644 doc/forum/preferred_content_settings_for_multiple_symlinks/comment_4_3cbd06de53b6a13e2741124a8e7b5b5b._comment
 create mode 100644 doc/forum/preferred_content_settings_for_multiple_symlinks/comment_5_963558ab261d8a6315402d371e8348f9._comment
 create mode 100644 doc/forum/preferred_content_settings_for_multiple_symlinks/comment_6_23279af1d49d22e880d078c59f58c492._comment
 create mode 100644 doc/forum/preferred_content_settings_for_multiple_symlinks/comment_7_73bf2c6dfa71cdb10b36c5cda2d2dc11._comment
 create mode 100644 doc/forum/problem_with_non-ascii_filenames.mdwn
 create mode 100644 doc/forum/problem_with_non-ascii_filenames/comment_1_ad7e7d7ef4b25ef59f93246dab0e3048._comment
 create mode 100644 doc/forum/public-web-frontend.mdwn
 create mode 100644 doc/forum/public-web-frontend/comment_1_c73bd2dfe020c25eaad1c0707dd2db01._comment
 create mode 100644 doc/forum/public-web-frontend/comment_2_0026d7be6b17e50d86b3b54985882f80._comment
 create mode 100644 doc/forum/public__44___read_only_annex_without_location_tracking.mdwn
 create mode 100644 doc/forum/public__44___read_only_annex_without_location_tracking/comment_1_47262f048a87fd6b781090f880a9bf99._comment
 create mode 100644 doc/forum/public__44___read_only_annex_without_location_tracking/comment_2_ec3ff6487c9e5c89c7e508d72518bd50._comment
 create mode 100644 doc/forum/pulling_from_encrypted_remote.mdwn
 create mode 100644 doc/forum/pulling_from_encrypted_remote/comment_1_e9d6a9a6e01d01edb41a11b0da11d74d._comment
 create mode 100644 doc/forum/pulling_from_encrypted_remote/comment_2_8d0db2ff65ce935c6e68044a3e0721a8._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow.mdwn
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_10_683768c9826b0bf0f267e8734b9eb872._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_11_6b541ed834ef45606f3b98779a25a148._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_12_ca8ca35d6cd4a9f94568536736c12adc._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_13_00c82d320c7b4bb51078beba17e14dc8._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_14_b63568b327215ef8f646a39d760fdfc0._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_15_cb7c856d8141b2de3cc95874753f1ee5._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_1_a32f7efd18d174845099a4ed59e6feae._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_2_66dc9b65523a9912411db03c039ba848._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_3_9b7d89da52f7ebb7801f9ec8545c3aba._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_4_dc8a3f75533906ad3756fcc47f7e96bb._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_5_afe5035a6b35ed2c7e193fb69cc182e2._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_6_3660d45c5656f68924acbd23790024ee._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_7_33db51096f568c65b22b4be0b5538c0d._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_8_6e5b42fdb7801daadc0b3046cbc3d51e._comment
 create mode 100644 doc/forum/pure_git-annex_only_workflow/comment_9_ace319652f9c7546883b5152ddc82591._comment
 create mode 100644 doc/forum/purge_files_with_no_copies.mdwn
 create mode 100644 doc/forum/purge_files_with_no_copies/comment_1_12b578689eb8d5d38c06261ec65e2109._comment
 create mode 100644 doc/forum/pushing_to_android.mdwn
 create mode 100644 doc/forum/pushing_to_android/comment_1_1a7f6d21a3eef88d20d6f2bbad4c39d5._comment
 create mode 100644 doc/forum/question_about_assistant_and___47__archive__47__.mdwn
 create mode 100644 doc/forum/question_about_assistant_and___47__archive__47__/comment_1_97890e26072af9277144651e3fdcada0._comment
 create mode 100644 doc/forum/question_about_assistant_and___47__archive__47__/comment_2_542bf265e35a976ac76767762d67d617._comment
 create mode 100644 doc/forum/question_about_assistant_and___47__archive__47__/comment_3_bafe99159df2adcd5fecc0d67bbf05a5._comment
 create mode 100644 doc/forum/question_about_assistant_and___47__archive__47__/comment_4_e77fa2992d9302a49a05f514c81612ca._comment
 create mode 100644 doc/forum/race_condition_with_drop_-J__63__.mdwn
 create mode 100644 doc/forum/race_condition_with_drop_-J__63__/comment_1_0607c11410d99a6933e02c28b54c1f65._comment
 create mode 100644 doc/forum/read_directly_from_annex.mdwn
 create mode 100644 doc/forum/read_directly_from_annex/comment_1_d8c4a60a672e60f89d6e57e515ef86cd._comment
 create mode 100644 doc/forum/rebuild_location_log_from_encrypted_remote.mdwn
 create mode 100644 doc/forum/rebuild_location_log_from_encrypted_remote/comment_1_f84f955fed7b96ae6208b6ff2ec650cd._comment
 create mode 100644 doc/forum/rebuild_location_log_from_encrypted_remote/comment_2_c0b2ce3bc7cd55a0c77ddc31493068c2._comment
 create mode 100644 doc/forum/rebuild_location_log_from_encrypted_remote/comment_3_06a73ca3dc73399ff000b642cca72de7._comment
 create mode 100644 doc/forum/receiving_indirect_renames_on_direct_repo___63__.mdwn
 create mode 100644 doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_1_f4b0a14373c75cb752597c832e296bcc._comment
 create mode 100644 doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_2_8c86dfc99f0b9040402c9d746decda53._comment
 create mode 100644 doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_3_0246fff6c7c75f6be45bd257ec3872a5._comment
 create mode 100644 doc/forum/recover_deleted_files___63__.mdwn
 create mode 100644 doc/forum/recover_deleted_files___63__/comment_1_d7abb7c45c6ec2723a04f153ed215453._comment
 create mode 100644 doc/forum/recover_deleted_files___63__/comment_2_8ea2acaa30d3ee7e9f75310f4ec859b2._comment
 create mode 100644 doc/forum/recover_deleted_files___63__/comment_3_376de81c70799bf409be189a48234815._comment
 create mode 100644 doc/forum/recover_deleted_files___63__/comment_4_2e73ac530d65a01768a57058b7220a29._comment
 create mode 100644 doc/forum/recovering_from_repo_corruption.mdwn
 create mode 100644 doc/forum/recovering_from_repo_corruption/comment_1_01fc85037e24fc70e5c5329898cf6781._comment
 create mode 100644 doc/forum/recovering_from_repo_corruption/comment_2_3bd1c0bf25a0e892e711a60f53cd5298._comment
 create mode 100644 doc/forum/recovering_from_repo_corruption/comment_3_679dde8ca0081fc6854d6d2e8a42abdb._comment
 create mode 100644 doc/forum/recovery_from_failed_merge.mdwn
 create mode 100644 doc/forum/recovery_from_failed_merge/comment_1_84e5b55d473d16bc9bdba5d88dc29bc3._comment
 create mode 100644 doc/forum/reflog_of_pruned_commits.mdwn
 create mode 100644 doc/forum/reflog_of_pruned_commits/comment_1_edb31e8722edc58be7e2593556dc3ddf._comment
 create mode 100644 doc/forum/reflog_of_pruned_commits/comment_2_cd0f057a730389509bd12dcaf21e3150._comment
 create mode 100644 doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src.mdwn
 create mode 100644 doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src/comment_1_c805561fa714ff3930742bb330b340c9._comment
 create mode 100644 doc/forum/reinstalled_os__44___cloned_annex__44___does_not_recognize_remote.mdwn
 create mode 100644 doc/forum/reinstalled_os__44___cloned_annex__44___does_not_recognize_remote/comment_1_c1962d757dd22f49e774afa13a9862ca._comment
 create mode 100644 doc/forum/reinstalled_os__44___cloned_annex__44___does_not_recognize_remote/comment_2_1f0f4a1dc89643cee81ff7199b55e747._comment
 create mode 100644 doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle.mdwn
 create mode 100644 doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_1_58f236c940ca20bfbae53324a530da0d._comment
 create mode 100644 doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_2_54ba7672150ee32df4d2d92390a960c1._comment
 create mode 100644 doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_3_107d0a3c9de6880d0ee164a651d2c20e._comment
 create mode 100644 doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_4_ddb6d671ddd28ba79efce74e41eab7e1._comment
 create mode 100644 doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_5_d496549c4f8bf3500e8ac5c2f2ae0d6e._comment
 create mode 100644 doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_6_8b3555fe33da55c01b199efd492951b0._comment
 create mode 100644 doc/forum/reliability__47__completeness_of_XMPP_updates.mdwn
 create mode 100644 doc/forum/reliability__47__completeness_of_XMPP_updates/comment_1_e0f7aa48d54fc0564f41c3a569c723b7._comment
 create mode 100644 doc/forum/reliability__47__completeness_of_XMPP_updates/comment_2_4e74039a673c16c0163f2cfb406dc4c3._comment
 create mode 100644 doc/forum/reliability__47__completeness_of_XMPP_updates/comment_3_41ade4fe72804b2f06cd4dbf405c1746._comment
 create mode 100644 doc/forum/relying_on_git_for_numcopies.mdwn
 create mode 100644 doc/forum/relying_on_git_for_numcopies/comment_1_8ad3cccd7f66f6423341d71241ba89fc._comment
 create mode 100644 doc/forum/relying_on_git_for_numcopies/comment_2_be6acbc26008a9cb54e7b8f498f2c2a2._comment
 create mode 100644 doc/forum/relying_on_git_for_numcopies/comment_3_43d8e1513eb9947f8a503f094c03f307._comment
 create mode 100644 doc/forum/remembering_state.mdwn
 create mode 100644 doc/forum/remembering_state/comment_1_4a6ac5f50dfa5a17a0f0ccd0c2e7a466._comment
 create mode 100644 doc/forum/remembering_state/comment_2_1b02d3713a2986bc027d166589a11c3f._comment
 create mode 100644 doc/forum/remembering_state/comment_3_b48775ea1e90b061b084f61a4a9baca5._comment
 create mode 100644 doc/forum/remembering_state/comment_4_cbebcc6ed4bdae6815c0576475e96f6a._comment
 create mode 100644 doc/forum/remote-specific_meta-data.mdwn
 create mode 100644 doc/forum/remote-specific_meta-data/comment_1_179ec4787d93ca4710c5bd448754d404._comment
 create mode 100644 doc/forum/remote-specific_meta-data/comment_2_51347629414ac42a6709d00d38ebef9c._comment
 create mode 100644 doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git.mdwn
 create mode 100644 doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_1_8333d1f8d773cd114aee8899d51b8fa1._comment
 create mode 100644 doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_2_174f467144d1977c6bc313f6461fc5c6._comment
 create mode 100644 doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_3_cea5b2a55fd82e4e42ad045d1bdda0a0._comment
 create mode 100644 doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_4_5bd942d53cf0a4978883eed1b61cfe91._comment
 create mode 100644 doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_5_6863faa0a64ff72abcf82435bfabf7b0._comment
 create mode 100644 doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_6_df69e9d176b14c687098d52dbe3cacd3._comment
 create mode 100644 doc/forum/remote_server_client_repositories_are_bare__33____63__.mdwn
 create mode 100644 doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_1_234241460f6c75a8376b303b8dd4e882._comment
 create mode 100644 doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_2_42dfc382d07af2a4f29c76016084f87c._comment
 create mode 100644 doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_3_32bf10cf837db16566dcc99d0b9aaf67._comment
 create mode 100644 doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_4_cd04cfaf97f200d5e581b83bb8d018b2._comment
 create mode 100644 doc/forum/removing_information_from_special_remote_file.mdwn
 create mode 100644 doc/forum/removing_information_from_special_remote_file/comment_1_a3c41731dbbcd53715c205e29ab99e4e._comment
 create mode 100644 doc/forum/removing_remote.log_information_completely.mdwn
 create mode 100644 doc/forum/removing_remote.log_information_completely/comment_1_033f5b8f2b306c756b3f12e0a9bc6637._comment
 create mode 100644 doc/forum/renaming_directories_not_supported__63__.mdwn
 create mode 100644 doc/forum/renaming_directories_not_supported__63__/comment_1_94bb80e70fe619c6f1913b4a233e47ec._comment
 create mode 100644 doc/forum/renaming_directories_not_supported__63__/comment_2_4bd6386dbd5cb907a9c85fb240265ee5._comment
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command.mdwn
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command/comment_10_791c50f8a2284b704e34cacf15637341._comment
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command/comment_11_1d951126a9633b206dffbc77bfc65f6a._comment
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command/comment_12_1a844376915c6a40ad03c2b9b599367b._comment
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command/comment_1_9555c925516ce3be83b4dd17d587100f._comment
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command/comment_2_17327b90d09f8dd0bf7f359c16cf69dd._comment
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command/comment_2_2ae0c755f5a0bf5c93afe5e081fcb915._comment
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command/comment_4_875f9e36a94264a92eb097e9f4bda444._comment
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command/comment_5_d5c29dc4ea49542f7053bf2e83e0f07f._comment
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command/comment_6_061770159851c0f06a962937dff035b9._comment
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command/comment_7_5d9e5fd148d5f9e918ad818e07009d69._comment
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command/comment_8_726c9a887b7df1833d7aef3bdce50517._comment
 create mode 100644 doc/forum/repair_stuck_on_ls-tree_command/comment_9_163cdd18380a13aaa13d68d516af1e30._comment
 create mode 100644 doc/forum/replacing_a_locked_file_without_unlocking_first.mdwn
 create mode 100644 doc/forum/replacing_a_locked_file_without_unlocking_first/comment_1_637598d027bc6194dad89d63aea511d4._comment
 create mode 100644 doc/forum/replacing_a_locked_file_without_unlocking_first/comment_2_b3ee1b086bf0add1e5f286635c02959a._comment
 create mode 100644 doc/forum/replacing_a_locked_file_without_unlocking_first/comment_3_ed4137413812467d67dd84aa5fde6263._comment
 create mode 100644 doc/forum/replacing_a_locked_file_without_unlocking_first/comment_4_8aa708a1bf76e452ef12c35999774791._comment
 create mode 100644 doc/forum/replacing_a_union_mount_with_git-annex.mdwn
 create mode 100644 doc/forum/replacing_a_union_mount_with_git-annex/comment_1_b627a4028d98f1a137c4af85918f49c0._comment
 create mode 100644 doc/forum/repo_corruption_in_usb_external_drive.mdwn
 create mode 100644 doc/forum/repo_corruption_in_usb_external_drive/comment_1_d9122bb0cc3551d92877c299a25b9c9e._comment
 create mode 100644 doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction.mdwn
 create mode 100644 doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction/comment_1_412c319a1610b447fcf372584c2bb15c._comment
 create mode 100644 doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction/comment_2_c10d614039b82c5be289e8e34bc70f86._comment
 create mode 100644 doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction/comment_3_4fec14b132bea863b58aa07e03fc31cc._comment
 create mode 100644 doc/forum/reserving_space_with_directory_special_remotes.mdwn
 create mode 100644 doc/forum/reserving_space_with_directory_special_remotes/comment_1_cd17b624704d93b51931023f69573323._comment
 create mode 100644 doc/forum/reserving_space_with_directory_special_remotes/comment_2_877ca1be23d1484a8a30cdaeb6630053._comment
 create mode 100644 doc/forum/reserving_space_with_directory_special_remotes/comment_3_65910eeaf3c6fcfd03f22c2957293232._comment
 create mode 100644 doc/forum/retrieving_previous_versions.mdwn
 create mode 100644 doc/forum/retrieving_previous_versions/comment_1_a4e83f688d4ec9177e7bf520f12ed26d._comment
 create mode 100644 doc/forum/retrieving_previous_versions/comment_2_e9251f66154e49a77be661c4b4918e18._comment
 create mode 100644 doc/forum/retrieving_previous_versions/comment_3_5b0ca6fbc000727bf78f5fc4ba34b91a._comment
 create mode 100644 doc/forum/root_assistant__63__.mdwn
 create mode 100644 doc/forum/root_assistant__63__/comment_1_fccab2e36d393f420d0fa23958e6a9d2._comment
 create mode 100644 doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__.mdwn
 create mode 100644 doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_1_7754e2cfb72b034effe8642c1b3e593e._comment
 create mode 100644 doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_2_04e1da4352ef9f9be90253ea726e5f24._comment
 create mode 100644 doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_3_84aceb9a9d3e5bd14c044861f47e3b9d._comment
 create mode 100644 doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_4_2cd17d01edeb230197865e6ea0884de0._comment
 create mode 100644 doc/forum/rsync_asking_for_an_unknown_password.mdwn
 create mode 100644 doc/forum/rsync_asking_for_an_unknown_password/comment_1_f23d1c04a27625089eaef5b4bb7f8456._comment
 create mode 100644 doc/forum/rsync_asking_for_an_unknown_password/comment_2_ce4b399fdb2f04e30bd8a951994f1c80._comment
 create mode 100644 doc/forum/rsync_into_annex_without_overwriting_links__63__.mdwn
 create mode 100644 doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_1_baa5351a0653838cfbf5f194f6252bcc._comment
 create mode 100644 doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_2_598cc6e65f57e941be1319255e66a55f._comment
 create mode 100644 doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_3_d765f93511e0ba446f54f3ad30e91e6f._comment
 create mode 100644 doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_4_62cf96d62228b52bf7dd52eab0b94f67._comment
 create mode 100644 doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_5_40e4e9fe7d301b5e75140136d0132860._comment
 create mode 100644 doc/forum/rsync_over_ssh__63__.mdwn
 create mode 100644 doc/forum/rsync_over_ssh__63__/comment_1_ee21f32e90303e20339e0a568321bbbe._comment
 create mode 100644 doc/forum/rsync_over_ssh__63__/comment_2_aa690da6ecfb2b30fc5080ad76dc77b1._comment
 create mode 100644 doc/forum/rsync_protocol_mismatch_due_to_encfs_folder.mdwn
 create mode 100644 doc/forum/rsync_regression_on_Windows.mdwn
 create mode 100644 doc/forum/rsync_regression_on_Windows/comment_1_0e713f8949a3e5a949489fc89c0b9078._comment
 create mode 100644 doc/forum/rsync_remote_is_not_available_from_a_cloned_repo/comment_1_2e340c5a6473f165dc06cc35db38e5c0._comment
 create mode 100644 doc/forum/rsync_test_remote_fail.mdwn
 create mode 100644 doc/forum/rsync_test_remote_fail/comment_1_deffffd5112a60ad7837479da045d39f._comment
 create mode 100644 doc/forum/rsync_test_remote_fail/comment_2_824e45450cc01b30144ac5f8265b930e._comment
 create mode 100644 doc/forum/rsync_test_remote_fail/comment_3_0b910e98485832dd7f305decdc39fa7f._comment
 create mode 100644 doc/forum/rsyncing_.git__47__annex__47__objects.mdwn
 create mode 100644 doc/forum/rsyncing_.git__47__annex__47__objects/comment_1_25eb9f7be5730337b9efd96dce9efd2e._comment
 create mode 100644 doc/forum/rsyncing_.git__47__annex__47__objects/comment_2_d7ceae666c8a1951021d3c6e6ac39a11._comment
 create mode 100644 doc/forum/s3_bandwidth_limitations_and_next_release.mdwn
 create mode 100644 doc/forum/s3_bandwidth_limitations_and_next_release/comment_1_6fba752ada4ca86c96a026a4d09ef16b._comment
 create mode 100644 doc/forum/s3_server_side_encryption.mdwn
 create mode 100644 doc/forum/s3_server_side_encryption/comment_1_68345d01b016abf96c226d2bfa17c641._comment
 create mode 100644 doc/forum/s3_server_side_encryption/comment_2_b2ccef6dc00d58e103ac0fda48ee94d3._comment
 create mode 100644 doc/forum/s3_server_side_encryption/comment_3_3eb57b98e4136b8550ea5d19393fe967._comment
 create mode 100644 doc/forum/s3_server_side_encryption/comment_4_71d6c2356af8974cb848c3574cf3eb6d._comment
 create mode 100644 doc/forum/s3_vs_ssh_Performance_Problems.mdwn
 create mode 100644 doc/forum/s3_vs_ssh_Performance_Problems/comment_1_65f064f09d7850abecab97007b0d30f0._comment
 create mode 100644 doc/forum/s3_vs_ssh_Performance_Problems/comment_2_baaf2384d9196077268e9ca9bbe3b871._comment
 create mode 100644 doc/forum/s3_vs_ssh_Performance_Problems/comment_3_dc44be42070c073d150c476406e9b425._comment
 create mode 100644 doc/forum/s3_vs_ssh_Performance_Problems/comment_4_f9c3ef3b1b44bfb29125acb6ec621f38._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history.mdwn
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_10_a4b93a3fbc98d9b86e942f95e0039862._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_11_383882fafd32f25ed22b5eb2fb3691b9._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_12_47794a2abf29bf4ea2763ff89d872ab4._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_13_b7b920862fc82eaa5d7deae34b4aebc4._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_14_979bbccf31dbee1707d403957bde3493._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_1_4fd76d10a93fe01588fce7a621f9254d._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_2_10ecf3220ffcbbe94ba09da225458f18._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_3_e3beb8acb075faaeef6c052aecbf0a41._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_4_61a5fe2e7e47c60a8b237ea69404a37f._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_5_426d02e2f2a2ae4ec7eae02dfe4519b3._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_6_410a7296c2cee16d3d5bb618a5a41c1d._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_7_42cf492fc98a9eba8176387749ef12e0._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_8_c0327ada073d8b69535f71b4dc6aa57e._comment
 create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_9_f83d6090aea2b7d5d54c876df940cbad._comment
 create mode 100644 doc/forum/scalability_with_lots_of_files.mdwn
 create mode 100644 doc/forum/scalability_with_lots_of_files/comment_1_b9bb0a71d81b8cbc2a751bb7bab84812._comment
 create mode 100644 doc/forum/schedule_repository___91__expression__93__.mdwn
 create mode 100644 doc/forum/schedule_repository___91__expression__93__/comment_1_b123b657a92897017973927e3e47673b._comment
 create mode 100644 doc/forum/script_to_generate___34__.hidden__34___files_for_files_not_in_local_remote.mdwn
 create mode 100644 doc/forum/script_to_generate___34__.hidden__34___files_for_files_not_in_local_remote/comment_1_76453756be78f06ef3a3d7d1bf011b9f._comment
 create mode 100644 doc/forum/security_risk_presented_by_remote.log__63__.mdwn
 create mode 100644 doc/forum/security_risk_presented_by_remote.log__63__/comment_1_9715488033f2a8939a32ed12259377ba._comment
 create mode 100644 doc/forum/security_risk_presented_by_remote.log__63__/comment_2_40383346237de0bae4760dc85fefc348._comment
 create mode 100644 doc/forum/security_risk_presented_by_remote.log__63__/comment_3_b1ddf06b34f750e9bbd88e6d5348e765._comment
 create mode 100644 doc/forum/security_risk_presented_by_remote.log__63__/comment_4_428bbced6406a35eb093a27e35831f38._comment
 create mode 100644 doc/forum/security_risk_presented_by_remote.log__63__/comment_5_df1eab397c8e08698064391438bbff1b._comment
 create mode 100644 doc/forum/security_risk_presented_by_remote.log__63__/comment_6_6a3911dc346d506d4350b5aec7619462._comment
 create mode 100644 doc/forum/seems_to_build_fine_on_haskell_platform_2011.mdwn
 create mode 100644 doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine.mdwn
 create mode 100644 doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/comment_1_1606849eb13b6069394455297395dc30._comment
 create mode 100644 doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/comment_2_f60c43ec9d493db03e2a5a5595501e55._comment
 create mode 100644 doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/comment_3_b041da6694d9d9d21a67f7bbdda0f62e._comment
 create mode 100644 doc/forum/shared_cipher_tries_to_use_gpg.mdwn
 create mode 100644 doc/forum/shared_cipher_tries_to_use_gpg/comment_1_760961eaaa7d5c254dd71c5792437c9e._comment
 create mode 100644 doc/forum/shared_cipher_tries_to_use_gpg/comment_2_f3260aea3a5bb9b95a9bdf1d0dfce090._comment
 create mode 100644 doc/forum/short_exlusive_refspec_notation_for_git_annex_unused_.mdwn
 create mode 100644 doc/forum/short_exlusive_refspec_notation_for_git_annex_unused_/comment_1_0aeb5702e74fcf158f1e9aca16ca9e6b._comment
 create mode 100644 doc/forum/slow_ikiwiki_server__63__.mdwn
 create mode 100644 doc/forum/slow_ikiwiki_server__63__/comment_1_f734812a94c0f6c7612257f82e0c4b36._comment
 create mode 100644 doc/forum/slow_ikiwiki_server__63__/comment_2_1eb8334b06b784211eb93405dbf93a77._comment
 create mode 100644 doc/forum/slow_ikiwiki_server__63__/comment_3_d73e4ff5f273160a3df5590ebafd440c._comment
 create mode 100644 doc/forum/slow_s3_transfer.mdwn
 create mode 100644 doc/forum/slow_s3_transfer/comment_1_a6e3f8579447d85c22f3bb99c4e6cf0d._comment
 create mode 100644 doc/forum/slow_s3_transfer/comment_2_f66a8d597de5065049a9a9b245166540._comment
 create mode 100644 doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat.mdwn
 create mode 100644 doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat/comment_1_a6f0ae755b9e24fd0de5868b57c6a497._comment
 create mode 100644 doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat/comment_2_9fe4a596aea6bd1a898b4c235126dce2._comment
 create mode 100644 doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat/comment_3_02eae41ba9ad2f2fb15cbd20069bf1da._comment
 create mode 100644 doc/forum/some_symlinks_left_in_direct_mode.mdwn
 create mode 100644 doc/forum/some_symlinks_left_in_direct_mode/comment_1_fd8d8107861453f0aa6b2c390e369307._comment
 create mode 100644 doc/forum/some_symlinks_left_in_direct_mode/comment_2_63f61caf28e834d48e12467bf09b2e3d._comment
 create mode 100644 doc/forum/something_really_good_happened_with_3.20130124.mdwn
 create mode 100644 doc/forum/something_really_good_happened_with_3.20130124/comment_1_1712bddd2f483a353f6313aa626445f1._comment
 create mode 100644 doc/forum/sparse_git_checkouts_with_annex.mdwn
 create mode 100644 doc/forum/sparse_git_checkouts_with_annex/comment_1_c7dc199c5740a0e7ba606dfb5e3e579a._comment
 create mode 100644 doc/forum/sparse_git_checkouts_with_annex/comment_2_e357db3ccc4079f07a291843975535eb._comment
 create mode 100644 doc/forum/sparse_git_checkouts_with_annex/comment_3_fcfafca994194d57dccf5319c7c9e646._comment
 create mode 100644 doc/forum/sparse_git_checkouts_with_annex/comment_4_04dc14880f31eee2b6d767d4d4258c5a._comment
 create mode 100644 doc/forum/special_remote_for_IMAP.mdwn
 create mode 100644 doc/forum/special_remote_for_IMAP/comment_1_7c7d4b57a1b6508fff1a6b0508c861f8._comment
 create mode 100644 doc/forum/special_remote_for_IMAP/comment_2_9c46fe8a857aa7a5ce797288144386bd._comment
 create mode 100644 doc/forum/special_remote_for_IMAP/comment_3_27e3b644df6942ce4c103236d0d5cb1b._comment
 create mode 100644 doc/forum/special_remote_for_IMAP/comment_4_0f8e01c453afb02aebf44b3fb2c9a7c1._comment
 create mode 100644 doc/forum/special_remote_for_iPods.mdwn
 create mode 100644 doc/forum/special_remote_for_iPods/comment_1_37cc3dc740341cc663074fd3bfb85947._comment
 create mode 100644 doc/forum/special_remote_which_applies_a_lossless_operation_in__47__out.mdwn
 create mode 100644 doc/forum/special_remote_which_applies_a_lossless_operation_in__47__out/comment_1_195f52aaaa36ce20955f2eb40af3c79a._comment
 create mode 100644 doc/forum/speed_up_assistant_startup_on_large_repositories.mdwn
 create mode 100644 doc/forum/speed_up_assistant_startup_on_large_repositories/comment_1_5ba637a0f6d01ba24fe25e6265134e0a._comment
 create mode 100644 doc/forum/speed_up_assistant_startup_on_large_repositories/comment_2_d65746697977f8971a4b59f5b413f926._comment
 create mode 100644 doc/forum/speed_up_assistant_startup_on_large_repositories/comment_3_be6c4fe5a0c745688438b716973791cc._comment
 create mode 100644 doc/forum/speed_up_assistant_startup_on_large_repositories/comment_4_a07472338a08c068a9b88b2176fc2bee._comment
 create mode 100644 doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer.mdwn
 create mode 100644 doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer/comment_1_87b9540e37abb16c0ec7605f5ab204a5._comment
 create mode 100644 doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer/comment_2_bd3383c142bf93d9cd496cb668d7782c._comment
 create mode 100644 doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer/comment_3_9b1911ae6468d09dae74ab1a60d2757b._comment
 create mode 100644 doc/forum/ssh_key_setup_woes_in_Android.mdwn
 create mode 100644 doc/forum/ssh_key_setup_woes_in_Android/comment_1_f16fbff27a449409699f3dbcf9590622._comment
 create mode 100644 doc/forum/ssh_password.mdwn
 create mode 100644 doc/forum/ssh_password/comment_1_a3e5a41e1d4da683d577976b134b11ee._comment
 create mode 100644 doc/forum/ssh_password/comment_2_fa261676a99d49d4b237b0d43048d76d._comment
 create mode 100644 doc/forum/ssh_remote_-_no___34__use_a_git_repository__34___option_during_setup__63__.mdwn
 create mode 100644 doc/forum/ssh_remote_-_no___34__use_a_git_repository__34___option_during_setup__63__/comment_1_7244794579a191a677190c60758f32e7._comment
 create mode 100644 doc/forum/ssh_remote_-_no___34__use_a_git_repository__34___option_during_setup__63__/comment_2_277cf12907bd7c5930eb4f137b115e29._comment
 create mode 100644 doc/forum/ssh_vs_cifs__47__webdav.mdwn
 create mode 100644 doc/forum/ssl_errors_with_special_remote.mdwn
 create mode 100644 doc/forum/ssl_errors_with_special_remote/comment_1_a3d68cc1af06c54d29818644a9943cc4._comment
 create mode 100644 doc/forum/ssl_errors_with_special_remote/comment_2_6ef51ec4daa0c4d3abae22dafe6f068b._comment
 create mode 100644 doc/forum/ssl_errors_with_special_remote/comment_3_d0e4921bd6d71c7b43418722008d2c22._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions.mdwn
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_10_3c41c48d40ae44129a80f2d2bef284ae._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_11_543bb94e6a6c1313a09328402a191995._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_12_b187721c1480debba3d391c965d17800._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_13_121ae7a2803975e3bdcb5f9df0c4af3f._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_14_5183f3d940ef116b07f88bac25cb97a8._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_15_b822c789e2736caa2c7bce27e619c463._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_16_33af5c294ccdff942f078ff366470342._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_17_a8d92991f13993d0beb72c7dd51e23a6._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_18_28f604900388b087eed76e7c03b8945b._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_19_00592c4cdcd7c3f63d5eacd16abdc88b._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_1_945d08e40897ee964be5e6945ad9914a._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_20_59066dc14b5b45a3a15ee65cf6746bab._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_21_c4fcf4abe2550b677ee312c597556e66._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_22_fe5049bba125e20d766595cb30bf7ce2._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_23_23bf8b9ab7e7850d801dcaec60ccf22d._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_24_3dd596dc5f09564932dacd90fbb5be2b._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_25_dd482d39c746dd6845382e9503731b6f._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_26_7fb08748b8610ad33f800c1bd173b120._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_2_211e260fbc60dc83a8986fac4e9700b7._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_3_9002aa86c44c19f28ab74724daad5422._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_4_ea42a5cb83e9cc8e24673bb805cfd4e1._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_5_c6d2c756b51247c784786e3a02d3840a._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_6_f7de3190366e81fc898393c1ed168c56._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_7_6ac3fa868ab0dfa6cc26928098abc334._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_8_74875c799f20d051739227e2b79de18f._comment
 create mode 100644 doc/forum/standalone_tarballs_for_specific_versions/comment_9_febd89250e37af938c723e4a204c5cef._comment
 create mode 100644 doc/forum/start_assistant_from_command_line.mdwn
 create mode 100644 doc/forum/start_assistant_from_command_line/comment_1_f8dfce1fca9f1212ccaf84e431db71a9._comment
 create mode 100644 doc/forum/start_assistant_from_command_line/comment_2_e769c5d09afbff85961363ddc5eb4019._comment
 create mode 100644 doc/forum/status_of_v7.mdwn
 create mode 100644 doc/forum/status_of_v7/comment_1_88d3bcb329bce6dfe33707f39b843b39._comment
 create mode 100644 doc/forum/store_annex_in_different_place_on_hard_drive.mdwn
 create mode 100644 doc/forum/store_annex_in_different_place_on_hard_drive/comment_1_a95add69028ad71f3c66b544c1a28db6._comment
 create mode 100644 doc/forum/support_for_git_sparse_checkout.mdwn
 create mode 100644 doc/forum/switching_backends.mdwn
 create mode 100644 doc/forum/switching_backends/comment_1_ecf4109c1148dafde3519243ae3c5a03._comment
 create mode 100644 doc/forum/switching_backends/comment_2_21f465a18f40b95dafd307fce0de659a._comment
 create mode 100644 doc/forum/switching_backends/comment_4_4c13d22c1695195e6b101bd20ef6bb42._comment
 create mode 100644 doc/forum/switching_backends/comment_4_e1d4a48baac23fd3f67b20eba4eee8af._comment
 create mode 100644 doc/forum/switching_to__47__from_direct_mode_while_assistant_is_running.mdwn
 create mode 100644 doc/forum/switching_to__47__from_direct_mode_while_assistant_is_running/comment_1_7832243a36613c48d0077b438dbf8b4a._comment
 create mode 100644 doc/forum/symlinks_corrupt__58___link_in_textfile__44___100_bytes_of_size.mdwn
 create mode 100644 doc/forum/symlinks_corrupt__58___link_in_textfile__44___100_bytes_of_size/comment_1_ee6ec862a391c54c8e1254891d4d477e._comment
 create mode 100644 doc/forum/symlinks_corrupt__58___link_in_textfile__44___100_bytes_of_size/comment_2_0748b20c8a0d7d4704003c0ecfc27716._comment
 create mode 100644 doc/forum/sync_--content__44___fatal_is_outside_repository_errors.mdwn
 create mode 100644 doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_10_d4a649874ee9c9e6a4c0252700607713._comment
 create mode 100644 doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_1_668dae37dd46047b46c9e1c23f7bcec4._comment
 create mode 100644 doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_09c62e4abf4ccc0d2e030ef5e1bcdf71._comment
 create mode 100644 doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_8f694afa77f5a835c826d29d46d44615._comment
 create mode 100644 doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_4_a7f476aeacf88679f25badc78fad886a._comment
 create mode 100644 doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_5_e96503f38cba755b2e6bd89b1ffab6ff._comment
 create mode 100644 doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_6_7443fe5f7384431914c714c2b462cf5c._comment
 create mode 100644 doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_7_63225cc9557886ae12b3450f68812815._comment
 create mode 100644 doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_8_baefe35266021184ee78440226fe2a8d._comment
 create mode 100644 doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_9_a9ed50cd4a1f436822ae97bfcd1ced48._comment
 create mode 100644 doc/forum/sync_--content_sometimes_iterates_over_all_files.mdwn
 create mode 100644 doc/forum/sync_--content_sometimes_iterates_over_all_files/comment_1_a276f0f6aa87a491c2fba3d58217b75a._comment
 create mode 100644 doc/forum/sync_--content_sometimes_iterates_over_all_files/comment_2_1f8ae9a0099d456e25f387798f99eec9._comment
 create mode 100644 doc/forum/sync_between_indirect_and_direct_mode.mdwn
 create mode 100644 doc/forum/sync_between_indirect_and_direct_mode/comment_1_7efc0d79196675582571c05fdd133b53._comment
 create mode 100644 doc/forum/sync_between_indirect_and_direct_mode/comment_2_8ac84dbaf7a4d503497487cbdb1749d8._comment
 create mode 100644 doc/forum/sync_between_indirect_and_direct_mode/comment_3_9acb237711669ec6046a8d07f9ed3b2c._comment
 create mode 100644 doc/forum/sync_content_through_repo_that_wants_nothing.mdwn
 create mode 100644 doc/forum/sync_content_through_repo_that_wants_nothing/comment_1_6c014bc88fc8a685ef79a044c8938c7d._comment
 create mode 100644 doc/forum/sync_content_through_repo_that_wants_nothing/comment_2_ef89154903395025bb0a0408e1c23bdf._comment
 create mode 100644 doc/forum/sync_content_through_repo_that_wants_nothing/comment_3_e05a3e3d991617bb2b323b5572cd771e._comment
 create mode 100644 doc/forum/sync_quits_after_first_non-successfull_remote.mdwn
 create mode 100644 doc/forum/sync_quits_after_first_non-successfull_remote/comment_1_dbca6ea763702a82ae7563722cdc7fab._comment
 create mode 100644 doc/forum/sync_remote_repo_on_local_sync_upstream.mdwn
 create mode 100644 doc/forum/sync_remote_repo_on_local_sync_upstream/comment_1_db650b4b5764e33219cb28eba2987ea5._comment
 create mode 100644 doc/forum/sync_stages_deletions_on_remote.mdwn
 create mode 100644 doc/forum/sync_stages_deletions_on_remote/comment_1_2b639066095e450c2d9be3b2775d24b3._comment
 create mode 100644 doc/forum/sync_stages_deletions_on_remote/comment_2_da5775526a2a476b6ead1cd1a735b8bd._comment
 create mode 100644 doc/forum/sync_stages_deletions_on_remote/comment_3_9e07593228915936fadcf90373be9f4e._comment
 create mode 100644 doc/forum/sync_stages_deletions_on_remote/comment_4_e5a3dc34c6229ec40bc999c3cab28041._comment
 create mode 100644 doc/forum/sync_stages_deletions_on_remote/comment_5_f3350d336c6c66c3aacc7caade2ef12c._comment
 create mode 100644 doc/forum/syncing_home_directories.mdwn
 create mode 100644 doc/forum/syncing_home_directories/comment_1_220a6e0ffe0ea610921a63c0a6e3beab._comment
 create mode 100644 doc/forum/syncing_music_to_my_android_device.mdwn
 create mode 100644 doc/forum/syncing_music_to_my_android_device/comment_1_81653a23424ac04675651fb7632c57ae._comment
 create mode 100644 doc/forum/syncing_music_to_my_android_device/comment_2_e49c9e5da5c5d1db228b9b753bed53ff._comment
 create mode 100644 doc/forum/syncing_non-git_trees_with_git-annex.mdwn
 create mode 100644 doc/forum/syncing_non-git_trees_with_git-annex/comment_1_7f9593bdfd95e4a8814e6cc5c44619e6._comment
 create mode 100644 doc/forum/syncing_non-git_trees_with_git-annex/comment_2_49f15478781a0ad5e46e75319070335c._comment
 create mode 100644 doc/forum/syncing_non-git_trees_with_git-annex/comment_3_6d8f399f0549eddd1d1f5c9c9a10c654._comment
 create mode 100644 doc/forum/syncing_to_an_encrypted_remove_won__39__t_prompt_with_pinentry-gtk2.mdwn
 create mode 100644 doc/forum/syncing_to_an_encrypted_remove_won__39__t_prompt_with_pinentry-gtk2/comment_1_daf41d0e59d384dfe5c86a53600ea3f7._comment
 create mode 100644 doc/forum/taskwarrior.mdwn
 create mode 100644 doc/forum/taskwarrior/comment_1_1c3a29e7d292cb602d9d349f8009b51e._comment
 create mode 100644 doc/forum/taskwarrior/comment_2_4b3d70501763f6d36c927ae37bbd33c2._comment
 create mode 100644 doc/forum/telehash_syncing.mdwn
 create mode 100644 doc/forum/tell_us_how_you__39__re_using_git-annex.mdwn
 create mode 100644 doc/forum/tell_us_how_you__39__re_using_git-annex/comment_1_4884803ddee7f642a3ac995a19967a6a._comment
 create mode 100644 doc/forum/tell_us_how_you__39__re_using_git-annex/comment_2_61f5054918e7b36c191454365bc7f3b7._comment
 create mode 100644 doc/forum/tell_us_how_you__39__re_using_git-annex/comment_3_db07e8703be606c998c831e91d300d69._comment
 create mode 100644 doc/forum/tell_us_how_you__39__re_using_git-annex/comment_4_a58595969cdd42ed20210e9615b42e42._comment
 create mode 100644 doc/forum/tell_us_how_you__39__re_using_git-annex/comment_5_4de0a5431431e80f4a81d87e649d4598._comment
 create mode 100644 doc/forum/temporary_AWS_credentials.mdwn
 create mode 100644 doc/forum/temporary_AWS_credentials/comment_1_655825b3aa981e97969e226c98034c4b._comment
 create mode 100644 doc/forum/temporary_AWS_credentials/comment_2_d4b66fd587c3a0ce74436ec09b398f10._comment
 create mode 100644 doc/forum/test_whether_a_file_is_already_annexed.mdwn
 create mode 100644 doc/forum/test_whether_a_file_is_already_annexed/comment_1_55bcb41abae2b70c046e3da1c4d8c761._comment
 create mode 100644 doc/forum/test_whether_a_file_is_already_annexed/comment_2_e2531c7e77bbc75f24af7ce5f789826e._comment
 create mode 100644 doc/forum/test_whether_a_file_is_already_annexed/comment_3_21f51c99b1aac8b3292f60bd83493e94._comment
 create mode 100644 doc/forum/test_whether_a_file_is_already_annexed/comment_4_2c61629777f47ce3e697298d5736f997._comment
 create mode 100644 doc/forum/the___39__here__39___remote.mdwn
 create mode 100644 doc/forum/the___39__here__39___remote/comment_1_8100ed97a671afea207efe3f70230707._comment
 create mode 100644 doc/forum/time_profiling_the_assistant.mdwn
 create mode 100644 doc/forum/time_profiling_the_assistant/comment_1_0227d9c0db24c6abadfe091f92848ec6._comment
 create mode 100644 doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs.mdwn
 create mode 100644 doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_1_76bb33ce45ce6a91b86454147463193b._comment
 create mode 100644 doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_2_4d9b9d47d01d606a475678f630797bf9._comment
 create mode 100644 doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_3_8a812b11fcc2dc3b6fcf01cdbbb8459d._comment
 create mode 100644 doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_4_fc98c819bc5eb4d7c9e74d87fb4f6f3b._comment
 create mode 100644 doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_5_c459fb479fe7b13eaea2377cfc1923a6._comment
 create mode 100644 doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_6_2e9da5a919bbbc27b32de3b243867d4f._comment
 create mode 100644 doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_7_d636c868524b2055ee85832527437f90._comment
 create mode 100644 doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_8_39dc449cc60a787c3bfbfaaac6f9be0c._comment
 create mode 100644 doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_9_2592749c2f02b3e151896e31acba359b._comment
 create mode 100644 doc/forum/transfer_bare_repo_setup_problem.mdwn
 create mode 100644 doc/forum/transfer_bare_repo_setup_problem/comment_1_3b6c15b81c5df09587bc75c5e358b39c._comment
 create mode 100644 doc/forum/transfer_bare_repo_setup_problem/comment_2_c011e8fcda61b6ee0067020abbddf61a._comment
 create mode 100644 doc/forum/treat_directory_with_multiple_files_as_a_single_item.mdwn
 create mode 100644 doc/forum/treat_directory_with_multiple_files_as_a_single_item/comment_1_89d2819893ae954041d65a5758993be8._comment
 create mode 100644 doc/forum/treat_directory_with_multiple_files_as_a_single_item/comment_2_6889f4695bca77c18efe0000fc491b57._comment
 create mode 100644 doc/forum/treat_directory_with_multiple_files_as_a_single_item/comment_3_61924cf10643a6d2d011899d95b4ae56._comment
 create mode 100644 doc/forum/trouble_with_multiple_remotes_syncing_to_gcrypt_based_ssh_repo_.mdwn
 create mode 100644 doc/forum/trouble_with_multiple_remotes_syncing_to_gcrypt_based_ssh_repo_/comment_1_4ad9a6a7cf5678ac0bc6d46a54f64cd3._comment
 create mode 100644 doc/forum/trouble_with_multiple_remotes_syncing_to_gcrypt_based_ssh_repo_/comment_2_82dc18ed14879936d04133f248879fb9._comment
 create mode 100644 doc/forum/trusted_repositories__58___fatal__58___not_a_git_repo.mdwn
 create mode 100644 doc/forum/trusted_repositories__58___fatal__58___not_a_git_repo/comment_1_0a755a4a281c3bd130722093c8ddd080._comment
 create mode 100644 doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn
 create mode 100644 doc/forum/two-way_assistant_sync_with_ssh_special_remote/comment_1_d42def5dfc1cf814fdb07f7cf808bb12._comment
 create mode 100644 doc/forum/two_lines_back_to_remote__63__.mdwn
 create mode 100644 doc/forum/two_lines_back_to_remote__63__/comment_1_064d786c5550e4470440717994e62051._comment
 create mode 100644 doc/forum/two_lines_back_to_remote__63__/comment_2_b1debe6f63e811c79ad97b9e38dd2935._comment
 create mode 100644 doc/forum/two_lines_back_to_remote__63__/comment_3_70ee40b99e06c4f64d3e2e4433c8b4ba._comment
 create mode 100644 doc/forum/ui.mdwn
 create mode 100644 doc/forum/ui/comment_1_f3e3446b05d6b573e29e6cad300fb635._comment
 create mode 100644 doc/forum/ui/comment_2_b493ee97eb2378e72c12f3d137109580._comment
 create mode 100644 doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote.mdwn
 create mode 100644 doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote/comment_1_cbcc4be05aa6d8f030d5ab0dc46858f4._comment
 create mode 100644 doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote/comment_2_3623a37d918d08e8681276206137f5af._comment
 create mode 100644 doc/forum/unable_to_clone_annex_repo_in_windows.mdwn
 create mode 100644 doc/forum/unable_to_clone_annex_repo_in_windows/comment_1_588af0e0b655966c2d344f3f4b4d2e5f._comment
 create mode 100644 doc/forum/unable_to_clone_annex_repo_in_windows/comment_2_e4fcc8329b2deb058b7368ce1c226a3e._comment
 create mode 100644 doc/forum/unable_to_clone_annex_repo_in_windows/comment_3_20aa8de2513fdb6b19a4b24f20983f0a._comment
 create mode 100644 doc/forum/unannex_--fast_+_uninit_leaves_files_in_.git__47__annex__47__objects__63__.mdwn
 create mode 100644 doc/forum/unannex_--fast_+_uninit_leaves_files_in_.git__47__annex__47__objects__63__/comment_1_4aaf93801119b36a01e452c7bb0fc7e9._comment
 create mode 100644 doc/forum/unannex_alternatives.mdwn
 create mode 100644 doc/forum/unannex_alternatives/comment_1_dcd4cd41280b41512bbdffafaf307993._comment
 create mode 100644 doc/forum/unannex_alternatives/comment_2_58a72a9fe0f58c7af0b4d7927a2dd21d._comment
 create mode 100644 doc/forum/unannex_alternatives/comment_3_b1687fc8f9e7744327bbeb6f0635d1cd._comment
 create mode 100644 doc/forum/unknown_response_from_git_cat-file.mdwn
 create mode 100644 doc/forum/unknown_response_from_git_cat-file/comment_1_f26ba569e715fe69b6de3093930362ee._comment
 create mode 100644 doc/forum/unknown_response_from_git_cat-file/comment_2_bba450e83609225c161b4fec1e006f8a._comment
 create mode 100644 doc/forum/unknown_response_from_git_cat-file/comment_3_8e0458e86764242e9e35940b4db302b7._comment
 create mode 100644 doc/forum/unknown_response_from_git_cat-file/comment_4_275fcf1e6643cb247f8ed5afc4c69e56._comment
 create mode 100644 doc/forum/unlock__47__lock_always_gets_me.mdwn
 create mode 100644 doc/forum/unlock__47__lock_always_gets_me/comment_1_dee73a7ea3e1a5154601adb59782831f._comment
 create mode 100644 doc/forum/unlock__47__lock_always_gets_me/comment_2_f89b4349dde840c355a3bc28908decdf._comment
 create mode 100644 doc/forum/unlock__47__lock_always_gets_me/comment_3_acbab7b75726d34dccb5c9dab7b3e728._comment
 create mode 100644 doc/forum/unrelated_repositories_sync.mdwn
 create mode 100644 doc/forum/unrelated_repositories_sync/comment_1_c899b7b05a96d14e25c2efadff3b4e52._comment
 create mode 100644 doc/forum/unsynced_folder.mdwn
 create mode 100644 doc/forum/unsynced_folder/comment_1_7d7a262f067c7b02d76e82637223934c._comment
 create mode 100644 doc/forum/untitled.mdwn
 create mode 100644 doc/forum/untitled/comment_1_0176d1d50bd62b113ff690346ba4161b._comment
 create mode 100644 doc/forum/update_via_cabal_fails.mdwn
 create mode 100644 doc/forum/update_via_cabal_fails/comment_1_e1235dc2acd3bac3dd51b7614dabbb88._comment
 create mode 100644 doc/forum/updating_the___34__number_of_copies__34__.mdwn
 create mode 100644 doc/forum/updating_the___34__number_of_copies__34__/comment_1_327bdb0d9c190c60c7147b3acf07af09._comment
 create mode 100644 doc/forum/updating_the___34__number_of_copies__34__/comment_2_7e11c839637e0894332e413cde02cee9._comment
 create mode 100644 doc/forum/updating_the___34__number_of_copies__34__/comment_3_8b7a70fb3bb41e4eda412302834730bb._comment
 create mode 100644 doc/forum/usability__58___creating_an_archive_on_a_new_external_drive.mdwn
 create mode 100644 doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_1_27b5283c65c402f330263426e4ca6ac1._comment
 create mode 100644 doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_2_b3a6b5ff0aaddd78903fc7bc7fbd6ee2._comment
 create mode 100644 doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_3_aab934c0e37771d7f834d2567a9e76a1._comment
 create mode 100644 doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_4_42beace277e009ddff449cb220775d44._comment
 create mode 100644 doc/forum/usability__58___what_are_those_arrow_things__63__.mdwn
 create mode 100644 doc/forum/usability__58___what_are_those_arrow_things__63__/comment_1_bf34c169c725f9504e0f2114ba53be4b._comment
 create mode 100644 doc/forum/usability__58___what_are_those_arrow_things__63__/comment_2_364ce8b369fd0ba7ddaec3127840ff39._comment
 create mode 100644 doc/forum/use_case__58___unique_indentifier_of_objets___40__doi_like__41__.mdwn
 create mode 100644 doc/forum/use_case__58___unique_indentifier_of_objets___40__doi_like__41__/comment_1_955f3aac12c1ddb41267c5a23ccb79e3._comment
 create mode 100644 doc/forum/use_case__58___unique_indentifier_of_objets___40__doi_like__41__/comment_2_0aff36755f49afddd5482a602a1ccd2b._comment
 create mode 100644 doc/forum/use_case_question__58___developer_repo_with_s3.mdwn
 create mode 100644 doc/forum/use_case_question__58___developer_repo_with_s3/comment_1_3e48d0a6c74e1bd67b1128d6b52f5fc4._comment
 create mode 100644 doc/forum/use_case_question__58___developer_repo_with_s3/comment_2_751d3f5855729d493ee2042b19117a70._comment
 create mode 100644 doc/forum/use_case_question__58___developer_repo_with_s3/comment_3_69ec3fedc166d68c10103b97c231e3d4._comment
 create mode 100644 doc/forum/use_case_question__58___developer_repo_with_s3/comment_4_4afea3a65b6b5c57a4dac5cdbbf89432._comment
 create mode 100644 doc/forum/use_case_question__58___developer_repo_with_s3/comment_5_743d7435c4e94efb293f4d6b1e83483d._comment
 create mode 100644 doc/forum/use_existing_ssh_keys__63__.mdwn
 create mode 100644 doc/forum/use_existing_ssh_keys__63__/comment_1_c420c53f022bbd1b28494bc44d076feb._comment
 create mode 100644 doc/forum/use_existing_ssh_keys__63__/comment_2_e4cae848e5701852073ced307832872b._comment
 create mode 100644 doc/forum/use_existing_ssh_keys__63__/comment_3_a97c20b6df74c49e5f57c7caf962f1e2._comment
 create mode 100644 doc/forum/use_existing_ssh_keys__63__/comment_4_8977bb8ee662c30dfcecae73cede9dfa._comment
 create mode 100644 doc/forum/using_--quiet_with_sync.mdwn
 create mode 100644 doc/forum/using_--quiet_with_sync/comment_1_69c2034761a8b92b001b142e49f0449e._comment
 create mode 100644 doc/forum/using_git-annex_with_lightroom.mdwn
 create mode 100644 doc/forum/using_git-annex_with_lightroom/comment_1_ec977efd277f0644767a4fc7064e4baf._comment
 create mode 100644 doc/forum/using_git-annex_with_lightroom/comment_2_4dc4f1ea91c72418843a682fab1854d2._comment
 create mode 100644 doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__.mdwn
 create mode 100644 doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__/comment_1_5c3ee8a8aaa6d0918c0cc9683ce177ae._comment
 create mode 100644 doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__/comment_2_648946353c6d90c57351cce4010f1301._comment
 create mode 100644 doc/forum/using_rsync.net_as_backup_and_glacier_as_archive.mdwn
 create mode 100644 doc/forum/uuid_mismatch.mdwn
 create mode 100644 doc/forum/uuid_mismatch/comment_1_ed29dcf70b916bdd094015c1c9616550._comment
 create mode 100644 doc/forum/uuid_mismatch/comment_2_de4beb1eb76ae7084387e8efc28e55d3._comment
 create mode 100644 doc/forum/uuid_mismatch/comment_3_a681a4847acbe890c4e486288b3c81d3._comment
 create mode 100644 doc/forum/v5_to_v6_upgrade_strategy.mdwn
 create mode 100644 doc/forum/v5_to_v6_upgrade_strategy/comment_1_1505166c806ab3d1a3148a245faa713a._comment
 create mode 100644 doc/forum/v5_to_v6_upgrade_strategy/comment_2_ef2648a58037b867e2d745eb4b3a15a2._comment
 create mode 100644 doc/forum/v5_to_v6_upgrade_strategy/comment_3_46fb3f5b0a7fa13b6f16ccb9832dac7e._comment
 create mode 100644 doc/forum/v6_thinning_seems_to_be_not_working_for_me.mdwn
 create mode 100644 doc/forum/v6_thinning_seems_to_be_not_working_for_me/comment_1_751e603141513faaa43abc38f3329a3e._comment
 create mode 100644 doc/forum/vanilla_git_repo_as_special_remote__63__.mdwn
 create mode 100644 doc/forum/vanilla_git_repo_as_special_remote__63__/comment_1_67e186265ae21f2cd8451750152f2a6d._comment
 create mode 100644 doc/forum/vanilla_git_repo_as_special_remote__63__/comment_2_6314256da98966f4c7d02aa0d6bf94ff._comment
 create mode 100644 doc/forum/version_3_upgrade.mdwn
 create mode 100644 doc/forum/version_3_upgrade/comment_1_05fc9c9cad26c520bebb98c852c71e35._comment
 create mode 100644 doc/forum/version_5_repo_with_version_6_repo.mdwn
 create mode 100644 doc/forum/version_5_repo_with_version_6_repo/comment_1_95037082d15758d7b2c23ad041d7f6f0._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives.mdwn
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_10_5f67c870fc7e43ae75d8e1f8ced975c2._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_11_65460ed123404478ae59fed1b5cff627._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_12_77cd7b20abd0cd1eadee0ebeb186b3cf._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_13_1d6588477082dd6de6eaad02fdc53463._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_14_6487a9a170f7caa7c9db06ac3bee8c0e._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_15_1d7c3ff1eaeffe03fe7e3e25af822e4e._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_1_0f16c72ed7bcba01398b36cb8b3cee08._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_2_769b971263b9124ec08079336d03869d._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_3_b6ee8c6384c73b44ae9ccc0ba32c3135._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_4_b1dbbf57a46c79e8e32885c2ee8f45d2._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_5_ec5d339021f2a26942248962ea818a80._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_6_a6c5e8dc86ed6b4b5ff45f66f5bad50a._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_7_3e66ef8493d2839cb26418788c510463._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_8_ae7380ff84e4200985c22deb647853e3._comment
 create mode 100644 doc/forum/very_slow_on_exfat_drives/comment_9_5b69d3cb7d3a51ce8a9cbdb608be676c._comment
 create mode 100644 doc/forum/view_from_numeric_values.mdwn
 create mode 100644 doc/forum/view_from_numeric_values/comment_1_f3c440f3f0104002a0020ba96ddcf87b._comment
 create mode 100644 doc/forum/view_from_numeric_values/comment_2_2414e1a8cfd154c339d8fc0e4a630ae9._comment
 create mode 100644 doc/forum/view_from_numeric_values/comment_3_7879a11cc9767cdaac14f9993182dc25._comment
 create mode 100644 doc/forum/view_from_numeric_values/comment_4_517c7659654a6fc608eb3332053df8a4._comment
 create mode 100644 doc/forum/view_including_files_with_no_tags.mdwn
 create mode 100644 doc/forum/view_including_files_with_no_tags/comment_1_b0aafc023fbec33af268576c4c199af3._comment
 create mode 100644 doc/forum/view_including_files_with_no_tags/comment_2_5ae9d5308371bdb1f94342c9f9b01aff._comment
 create mode 100644 doc/forum/views___40__branches__41___never_get_deleted.mdwn
 create mode 100644 doc/forum/views___40__branches__41___never_get_deleted/comment_1_ff53fa0b5f0c4a6554a37e3309e26925._comment
 create mode 100644 doc/forum/views___40__branches__41___never_get_deleted/comment_3_1d4a3f4e83b288262e291262a6636602._comment
 create mode 100644 doc/forum/views___40__branches__41___never_get_deleted/comment_3_4e96e5325fd12e48f190fe551a6ac07e._comment
 create mode 100644 doc/forum/views___40__branches__41___never_get_deleted/comment_4_a4764b5bfb08ebe90430ea14fcb6e8e0._comment
 create mode 100644 doc/forum/views___40__branches__41___never_get_deleted/comment_5_02e08dffb01246010b390aeef8f32234._comment
 create mode 100644 doc/forum/vlc_and_git-annex.mdwn
 create mode 100644 doc/forum/vlc_and_git-annex/comment_1_9c9ab8ce463cf74418aa2f385955f165._comment
 create mode 100644 doc/forum/vlc_and_git-annex/comment_2_037f94c1deeac873dbdb36cd4c927e45._comment
 create mode 100644 doc/forum/walkthrough_report_setting_up_tor_p2p_remote.mdwn
 create mode 100644 doc/forum/warning__58___remote_HEAD_refers_to_nonexistent_ref__44___unable_to_checkout.mdwn
 create mode 100644 doc/forum/warning__58___remote_HEAD_refers_to_nonexistent_ref__44___unable_to_checkout/comment_1_c0d9758be80d1a349ffe82c80075bebd._comment
 create mode 100644 doc/forum/warning__58___remote_HEAD_refers_to_nonexistent_ref__44___unable_to_checkout/comment_2_c28dae2eb0ab825ee6d43735e04a18a3._comment
 create mode 100644 doc/forum/web-browser_for_the_repository.mdwn
 create mode 100644 doc/forum/web-browser_for_the_repository/comment_1_1f8e7e54e9f377417cd672d66ae9bd9d._comment
 create mode 100644 doc/forum/web-browser_for_the_repository/comment_2_551d5bb2d24212de65720d796365177f._comment
 create mode 100644 doc/forum/web-browser_for_the_repository/comment_3_d410df4b7160f17e3846674c3e0e9368._comment
 create mode 100644 doc/forum/web-browser_for_the_repository/comment_4_d06217403bf53a713b845bbc9ca8b962._comment
 create mode 100644 doc/forum/webapp__58___disabling_a_paired_repository.mdwn
 create mode 100644 doc/forum/webapp__58___disabling_a_paired_repository/comment_1_9dd316fedf55afecbc77f3b99e66d837._comment
 create mode 100644 doc/forum/webapp__58___disabling_a_paired_repository/comment_2_28cf58629b9774426c084d80964151d7._comment
 create mode 100644 doc/forum/webapp__58___disabling_a_paired_repository/comment_3_799d66b116e8ddf42e624bb4a082337c._comment
 create mode 100644 doc/forum/webapp___47___assistant_without_watch.mdwn
 create mode 100644 doc/forum/webapp___47___assistant_without_watch/comment_1_1bcd99aa81f937ded683e19a69d33dd9._comment
 create mode 100644 doc/forum/webapp___47___assistant_without_watch/comment_2_9f5b3f5bf7fedcd5baec519d97d3aa8c._comment
 create mode 100644 doc/forum/webapp_and_manual_mode.mdwn
 create mode 100644 doc/forum/webapp_and_manual_mode/comment_1_5b5df5ffeb6ee15779972f13fdc11729._comment
 create mode 100644 doc/forum/webapp_and_manual_mode/comment_2_a1f06b50d1317c78a301b47eb05d2617._comment
 create mode 100644 doc/forum/webapp_and_manual_mode/comment_3_f0739bf4304a91a5d4ec33ac2421c966._comment
 create mode 100644 doc/forum/webapp_does_not_start.mdwn
 create mode 100644 doc/forum/webapp_does_not_start/comment_1_dd27d30ce305562a1552f46c87b1cd27._comment
 create mode 100644 doc/forum/webapp_does_not_start/comment_2_ef37f40288a1181ca619ae13b0f7a994._comment
 create mode 100644 doc/forum/webapp_does_not_start/comment_3_6e625dba9f7fa36bf9c7e9d77fbadeff._comment
 create mode 100644 doc/forum/webapp_listen_port_with_autostart.mdwn
 create mode 100644 doc/forum/webapp_listen_port_with_autostart/comment_1_65dbcf3d8f6c16568f5a326242eab9c5._comment
 create mode 100644 doc/forum/webapp_listen_port_with_autostart/comment_2_39664f833dedc1a4fe083eec9bc4a7cd._comment
 create mode 100644 doc/forum/weird_view_file_naming.mdwn
 create mode 100644 doc/forum/weird_view_file_naming/comment_1_24a44f94194231bb8efe9b20ee311d4c._comment
 create mode 100644 doc/forum/weird_view_file_naming/comment_2_2ff3002e45a7443f0502243b3690df9d._comment
 create mode 100644 doc/forum/what_are___95__exactly__95___limitations_of_git-annex_when_using_it_like_dropbox.mdwn
 create mode 100644 doc/forum/what_are___95__exactly__95___limitations_of_git-annex_when_using_it_like_dropbox/comment_1_b76e6d3c4d530fd6735460aa5ab03ad5._comment
 create mode 100644 doc/forum/what_happens_to_deleted_files__63__.mdwn
 create mode 100644 doc/forum/what_happens_to_deleted_files__63__/comment_1_a476174646ad3adfbbe0cafdd7d42d08._comment
 create mode 100644 doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out.mdwn
 create mode 100644 doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_1_86428fc8286266d01cc51af8ae4aa335._comment
 create mode 100644 doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_2_50c1a19a7278e8748c2e6e789f6b418a._comment
 create mode 100644 doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_3_368403625451415c66b9e62005d9ddea._comment
 create mode 100644 doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_4_53ccb5c7c8f15f44fb2f113742fe77f3._comment
 create mode 100644 doc/forum/when_repo_offline_list_whereis_slow.mdwn
 create mode 100644 doc/forum/when_repo_offline_list_whereis_slow/comment_1_79052583012da5097ca7bdc52dcdfb7d._comment
 create mode 100644 doc/forum/when_repo_offline_list_whereis_slow/comment_2_caa2b4ca2826444bdfb47616a549f4e6._comment
 create mode 100644 doc/forum/where_to_submit_pull_requests_for_git-annex__63__.mdwn
 create mode 100644 doc/forum/where_to_submit_pull_requests_for_git-annex__63__/comment_1_f5e6022798ba63b55bff197b5937f9fe._comment
 create mode 100644 doc/forum/whereis__58___Why_not_here__63__.mdwn
 create mode 100644 doc/forum/whereis__58___Why_not_here__63__/comment_1_02a423918efcc760bb89dfb78586dc2a._comment
 create mode 100644 doc/forum/whereis__58___Why_not_here__63__/comment_2_e55ce8cbb6bbabc654ba743d755a6eee._comment
 create mode 100644 doc/forum/whereis__58___Why_not_here__63__/comment_3_7de87ad1fd8a0f53562d3083af1410d6._comment
 create mode 100644 doc/forum/whereis_command_with_file_names_instead_of_hashes.mdwn
 create mode 100644 doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_1_4eaca07152916adc18032fb404e4dd92._comment
 create mode 100644 doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_2_94b43ac23ff8332b35723422eede8997._comment
 create mode 100644 doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_3_45ffa6dd17667ecd6685f85f34046eff._comment
 create mode 100644 doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_4_d459fbcf0db59b821ae67f4949e48103._comment
 create mode 100644 doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_5_e52a8c9cb418fbc2e2cba71f37bd44ad._comment
 create mode 100644 doc/forum/which_version_should_I_install__63__.mdwn
 create mode 100644 doc/forum/which_version_should_I_install__63__/comment_1_147f12392f6f546ab50dc346052ad4b7._comment
 create mode 100644 doc/forum/which_version_should_I_install__63__/comment_3_c85c107a60b4b642ed9a8de7d233f95e._comment
 create mode 100644 doc/forum/which_version_should_I_install__63__/comment_4_f627212a612f5d746bb8bcc5e1ea48df._comment
 create mode 100644 doc/forum/which_version_should_I_install__63__/comment_5_1c8201cf1de60fde73a2370a6e6c3ad3._comment
 create mode 100644 doc/forum/which_version_should_I_install__63__/comment_6_c0f850927683d45dbe4d6d1d61788b4a._comment
 create mode 100644 doc/forum/which_version_should_I_install__63__/comment_7_b563b2be227a1a128d8ac0679108f5b5._comment
 create mode 100644 doc/forum/which_version_should_I_install__63__/comment_8_e24a8a8edd7d0b314f26406d17775fdc._comment
 create mode 100644 doc/forum/which_version_should_I_install__63__/comment_8_ef725153df7a9b65f7ade4d7e6cecffb._comment
 create mode 100644 doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__.mdwn
 create mode 100644 doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_1_865245182d765fed7bbeb42a35dd605e._comment
 create mode 100644 doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_2_c1f5a285b7cfb92d218b9b0d31caeed6._comment
 create mode 100644 doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_3_be2816c47091842b829cd626e18c5fda._comment
 create mode 100644 doc/forum/windows_port__63__.mdwn
 create mode 100644 doc/forum/windows_port__63__/comment_1_23fa9aa3b00940a1c1b3876c35eef019._comment
 create mode 100644 doc/forum/wishlist__58___get__47__drop_via_webapp_file_explorer.mdwn
 create mode 100644 doc/forum/wishlist__58___get__47__drop_via_webapp_file_explorer/comment_1_c818a6d44dc13a56460b1865f70eb97c._comment
 create mode 100644 doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space.mdwn
 create mode 100644 doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space/comment_1_467e5e3db3e836030bc4b4f15846951f._comment
 create mode 100644 doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space/comment_2_e3ca3db9bea11d3e085ee9c3c56b33fe._comment
 create mode 100644 doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space/comment_3_0ef8c37350fc192d9b784fbab1d9f318._comment
 create mode 100644 doc/forum/working_without_git-annex_commits.mdwn
 create mode 100644 doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up.mdwn
 create mode 100644 doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_1_00b084f9786de6516f46065c0cb00e79._comment
 create mode 100644 doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_2_138499b36d28c5e267b4aad8792dc87e._comment
 create mode 100644 doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_3_6c59c494b563e56d061417eb2216bb19._comment
 create mode 100644 doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_4_ccbba61cdd6fce3e5de82417bcc0cbfb._comment
 create mode 100644 doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_5_50526283b35997cece2f087507cdd4ee._comment
 create mode 100644 doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__.mdwn
 create mode 100644 doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_1_b011442de2f67f3ad340031a0767e990._comment
 create mode 100644 doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_2_c69865c08c3eb49d64310fc76e80c65d._comment
 create mode 100644 doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_3_7651fb48fc71b2c7b4e7b6830a0f9865._comment
 create mode 100644 doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_4_7d88f1aa163185c801b7697846086c7f._comment
 create mode 100644 doc/future_proofing.mdwn
 create mode 100644 doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment
 create mode 100644 doc/git-annex-add.mdwn
 create mode 100644 doc/git-annex-add/comment_1_0e6b855afb4fba540ea5560df26839c5._comment
 create mode 100644 doc/git-annex-add/comment_2_43cf725964c63a2d2545d9f204316a57._comment
 create mode 100644 doc/git-annex-add/comment_3_8517f9634d217f731efd704405d3f2ca._comment
 create mode 100644 doc/git-annex-add/comment_4_3bbbe94633b6cb4ef93b7942eb36cc6c._comment
 create mode 100644 doc/git-annex-add/comment_5_f67bd5fdbe9deeeea1d48175a6b5c536._comment
 create mode 100644 doc/git-annex-add/comment_6_be9e67994aacebedb478f68a8ae542a5._comment
 create mode 100644 doc/git-annex-add/comment_7_bb9d72f90f4d3c93d71de1a1bbc244b6._comment
 create mode 100644 doc/git-annex-addunused.mdwn
 create mode 100644 doc/git-annex-addurl.mdwn
 create mode 100644 doc/git-annex-addurl/comment_10_66051cf22495e661828f2ef3291f8578._comment
 create mode 100644 doc/git-annex-addurl/comment_11_a09a85bbabc112369ab661b7ac5f277d._comment
 create mode 100644 doc/git-annex-addurl/comment_12_f75e35ae6f739e98aeb15c3f8708be8a._comment
 create mode 100644 doc/git-annex-addurl/comment_13_f413cc1febfa70e3ad885c6fa031a209._comment
 create mode 100644 doc/git-annex-addurl/comment_14_5719924fbda2daabe83ef2fde447d620._comment
 create mode 100644 doc/git-annex-addurl/comment_15_460d474cb8ef32d41eae71ee070de0b3._comment
 create mode 100644 doc/git-annex-addurl/comment_16_c6e1743647bb4d45b5a1b237f53d77a6._comment
 create mode 100644 doc/git-annex-addurl/comment_1_ce9c660be160a22c28aeb6de8b3b5818._comment
 create mode 100644 doc/git-annex-addurl/comment_2_9bc984fb80d77309b62a4e915e65a31a._comment
 create mode 100644 doc/git-annex-addurl/comment_3_46e1b62d37619521a60eb2339b8d094f._comment
 create mode 100644 doc/git-annex-addurl/comment_4_0951800d761d18614eb6c5f08cdbb885._comment
 create mode 100644 doc/git-annex-addurl/comment_5_47dfa82fc6426fb9ad050dd00290dc03._comment
 create mode 100644 doc/git-annex-addurl/comment_7_8d8ac07a0f0fe599ea5ed1e4089b13fa._comment
 create mode 100644 doc/git-annex-addurl/comment_8_88aea3014245634d42f23a22ccf2fcc9._comment
 create mode 100644 doc/git-annex-addurl/comment_8_b261e7bfeeffb2c5264aaadae1d78817._comment
 create mode 100644 doc/git-annex-addurl/comment_9_48741c1c625dc1ecba2db4f7be2f644c._comment
 create mode 100644 doc/git-annex-adjust.mdwn
 create mode 100644 doc/git-annex-adjust/comment_1_364d1d5546c0f448a4b27cfe69a59a07._comment
 create mode 100644 doc/git-annex-adjust/comment_2_383af8e1e26e4119671437aace0a58f5._comment
 create mode 100644 doc/git-annex-adjust/comment_3_c5af3a73af8925839413467a7d1e0e14._comment
 create mode 100644 doc/git-annex-adjust/comment_4_597c5e0254012e3a4ecafa49cfa23cb6._comment
 create mode 100644 doc/git-annex-adjust/comment_6_f00c27078cce5ad75fcf0cec1033751b._comment
 create mode 100644 doc/git-annex-adjust/comment_7_a9c88b1d83d5e874f8f8063fcdd9e624._comment
 create mode 100644 doc/git-annex-assist.mdwn
 create mode 100644 doc/git-annex-assistant.mdwn
 create mode 100644 doc/git-annex-backends.mdwn
 create mode 100644 doc/git-annex-benchmark.mdwn
 create mode 100644 doc/git-annex-benchmark/comment_1_fe0e8d2e2e875521e715ee2e68818570._comment
 create mode 100644 doc/git-annex-benchmark/comment_2_3d8dcde00f8df7961490ef81f5400824._comment
 create mode 100644 doc/git-annex-calckey.mdwn
 create mode 100644 doc/git-annex-checkpresentkey.mdwn
 create mode 100644 doc/git-annex-checkpresentkey/comment_1_756f276929a0b0ff73baea141d3ef07d._comment
 create mode 100644 doc/git-annex-checkpresentkey/comment_2_e277962791b64e67b08ccff47dd22447._comment
 create mode 100644 doc/git-annex-common-options.mdwn
 create mode 100644 doc/git-annex-config.mdwn
 create mode 100644 doc/git-annex-config/comment_1_26bd743439e87e71b1eea2c620e6fc12._comment
 create mode 100644 doc/git-annex-config/comment_2_0cf3e61f86b217b89dcace22bdfaaa44._comment
 create mode 100644 doc/git-annex-config/comment_3_cd443c49f9d1122f078872259e342683._comment
 create mode 100644 doc/git-annex-config/comment_4_e1c484811ea276532ed1b5c965d4de1b._comment
 create mode 100644 doc/git-annex-configremote.mdwn
 create mode 100644 doc/git-annex-contentlocation.mdwn
 create mode 100644 doc/git-annex-copy.mdwn
 create mode 100644 doc/git-annex-copy/comment_1_9be279110a112335bc72ee8c8a347da2._comment
 create mode 100644 doc/git-annex-copy/comment_2_599958b0a57d2f8f4383733d28ad9c8d._comment
 create mode 100644 doc/git-annex-copy/comment_3_a9408822e314c32bebf8230f9d40216b._comment
 create mode 100644 doc/git-annex-copy/comment_4_44dcb42a011cc203655bccca06de2e10._comment
 create mode 100644 doc/git-annex-copy/comment_5_fe7c2c6617b3a5ca153af2225fc66498._comment
 create mode 100644 doc/git-annex-dead.mdwn
 create mode 100644 doc/git-annex-describe.mdwn
 create mode 100644 doc/git-annex-diffdriver.mdwn
 create mode 100644 doc/git-annex-diffdriver/comment_1_b45fd606668e2eee0a37bf1db3391f37._comment
 create mode 100644 doc/git-annex-diffdriver/comment_2_05c3a29d7827dd6fc5babe0ac1ff2a94._comment
 create mode 100644 doc/git-annex-direct.mdwn
 create mode 100644 doc/git-annex-direct/comment_1_5d6f9e9393e534e027ddcd555861196b._comment
 create mode 100644 doc/git-annex-direct/comment_2_ef8ac748470549776c1ee299b062add2._comment
 create mode 100644 doc/git-annex-drop.mdwn
 create mode 100644 doc/git-annex-drop/comment_10_9ed8d998831414436e5d0e100ed96fb7._comment
 create mode 100644 doc/git-annex-drop/comment_11_95c5be6e2be84dc0903e3d7384f67313._comment
 create mode 100644 doc/git-annex-drop/comment_1_ecb863aea64eadbaeb7759c5cb0bf5a5._comment
 create mode 100644 doc/git-annex-drop/comment_2_c9017041b01d803b346b1b14b8d1e066._comment
 create mode 100644 doc/git-annex-drop/comment_3_16095aad685d142672911e799450634a._comment
 create mode 100644 doc/git-annex-drop/comment_4_156873ca9820b316a2099b6646562891._comment
 create mode 100644 doc/git-annex-drop/comment_5_655f0bcaafdf03eb637af715e7642e27._comment
 create mode 100644 doc/git-annex-drop/comment_6_ed46bc0407457fc5db0d5241ba69d9ed._comment
 create mode 100644 doc/git-annex-drop/comment_7_f9b255923bdb20c92b878d86998b7ae2._comment
 create mode 100644 doc/git-annex-drop/comment_8_cf6fbdc5355aebe33188825d578690c1._comment
 create mode 100644 doc/git-annex-drop/comment_9_55d96bb12b325954bb7e7817f1a8ff3f._comment
 create mode 100644 doc/git-annex-dropkey.mdwn
 create mode 100644 doc/git-annex-dropunused.mdwn
 create mode 100644 doc/git-annex-edit.mdwn
 create mode 100644 doc/git-annex-enable-tor.mdwn
 create mode 100644 doc/git-annex-enableremote.mdwn
 create mode 100644 doc/git-annex-enableremote/comment_2_43876327581d6bcfb69c318c02d6389a._comment
 create mode 100644 doc/git-annex-enableremote/comment_2_78223f5c6ad120d5e0b98583543425db._comment
 create mode 100644 doc/git-annex-enableremote/comment_3_4bc11d1df0ff6962b12f5b8a1bb6188e._comment
 create mode 100644 doc/git-annex-examinekey.mdwn
 create mode 100644 doc/git-annex-expire.mdwn
 create mode 100644 doc/git-annex-export.mdwn
 create mode 100644 doc/git-annex-filter-branch.mdwn
 create mode 100644 doc/git-annex-filter-process.mdwn
 create mode 100644 doc/git-annex-find.mdwn
 create mode 100644 doc/git-annex-find/comment_6_8d931c135df8f9eba201a3dbb94af87e._comment
 create mode 100644 doc/git-annex-find/comment_7_b9d4cc7438ce5dbe22b62e9decc6cbee._comment
 create mode 100644 doc/git-annex-find/comment_8_d5846a41e2e227569d7d90dbb8edf7d8._comment
 create mode 100644 doc/git-annex-findkeys.mdwn
 create mode 100644 doc/git-annex-findref.mdwn
 create mode 100644 doc/git-annex-fix.mdwn
 create mode 100644 doc/git-annex-forget.mdwn
 create mode 100644 doc/git-annex-fromkey.mdwn
 create mode 100644 doc/git-annex-fsck.mdwn
 create mode 100644 doc/git-annex-fuzztest.mdwn
 create mode 100644 doc/git-annex-get.mdwn
 create mode 100644 doc/git-annex-get/comment_1_9914f6f6c99757927eed9b5d0217908e._comment
 create mode 100644 doc/git-annex-get/comment_2_ce5c85afa01019afe58c79df151c65ff._comment
 create mode 100644 doc/git-annex-group.mdwn
 create mode 100644 doc/git-annex-groupwanted.mdwn
 create mode 100644 doc/git-annex-import.mdwn
 create mode 100644 doc/git-annex-import/comment_1_8961635a772b4ddb5ba1e04a50034e6a._comment
 create mode 100644 doc/git-annex-import/comment_2_e62b59d5c9cee04a77c51799624a3357._comment
 create mode 100644 doc/git-annex-import/comment_3_3891ccc35010e1e5c328a9aa6b9e596b._comment
 create mode 100644 doc/git-annex-importfeed.mdwn
 create mode 100644 doc/git-annex-importfeed/comment_1_d0197108d07873040e46577df1faadbd._comment
 create mode 100644 doc/git-annex-importfeed/comment_2_25d4ed016e98609066597a8d2b956f87._comment
 create mode 100644 doc/git-annex-importfeed/comment_3_bce2b233e4d42fc87a2e17d51e2c2606._comment
 create mode 100644 doc/git-annex-indirect.mdwn
 create mode 100644 doc/git-annex-info.mdwn
 create mode 100644 doc/git-annex-init.mdwn
 create mode 100644 doc/git-annex-initremote.mdwn
 create mode 100644 doc/git-annex-inprogress.mdwn
 create mode 100644 doc/git-annex-list.mdwn
 create mode 100644 doc/git-annex-lock.mdwn
 create mode 100644 doc/git-annex-log.mdwn
 create mode 100644 doc/git-annex-lookupkey.mdwn
 create mode 100644 doc/git-annex-lookupkey/comment_1_100fcc1559449ae99a2dc6eade61662c._comment
 create mode 100644 doc/git-annex-lookupkey/comment_2_897eaca8174d5f568a19805f90d9e1c3._comment
 create mode 100644 doc/git-annex-map.mdwn
 create mode 100644 doc/git-annex-matchexpression.mdwn
 create mode 100644 doc/git-annex-matching-expression.mdwn
 create mode 100644 doc/git-annex-matching-options.mdwn
 create mode 100644 doc/git-annex-matching-options/comment_1_09d1a7961a79dff47bef8797b3775766._comment
 create mode 100644 doc/git-annex-matching-options/comment_2_78a5e7090e5ac3e6710813bac600fde0._comment
 create mode 100644 doc/git-annex-merge.mdwn
 create mode 100644 doc/git-annex-metadata.mdwn
 create mode 100644 doc/git-annex-metadata/comment_10_278fca1c579d0acdcce819449aec8eee._comment
 create mode 100644 doc/git-annex-metadata/comment_11_deee9a4c3a812c9c8097d89f2f6c7d76._comment
 create mode 100644 doc/git-annex-metadata/comment_1_45492400069021adbe048978be6957ef._comment
 create mode 100644 doc/git-annex-metadata/comment_2_12e615b99bf9999df0678cb6dc09d398._comment
 create mode 100644 doc/git-annex-metadata/comment_3_6537bd785997501a9708682acd91f9f6._comment
 create mode 100644 doc/git-annex-metadata/comment_4_49c885bd5840aba9f9e011a1618931a1._comment
 create mode 100644 doc/git-annex-metadata/comment_5_b4f928a4e8a81165e3845219483a9b25._comment
 create mode 100644 doc/git-annex-metadata/comment_6_11b1fa357953736925cfbbc1079590dd._comment
 create mode 100644 doc/git-annex-metadata/comment_7_fe7d15a1a4cd729b6ffec26f49d8b47a._comment
 create mode 100644 doc/git-annex-metadata/comment_8_54cff011e3e13882cfbd7a30fb43d078._comment
 create mode 100644 doc/git-annex-metadata/comment_9_a14b21109aa12eaf13e8c215e108cc29._comment
 create mode 100644 doc/git-annex-migrate.mdwn
 create mode 100644 doc/git-annex-mincopies.mdwn
 create mode 100644 doc/git-annex-mirror.mdwn
 create mode 100644 doc/git-annex-move.mdwn
 create mode 100644 doc/git-annex-move/comment_1_b69fbe2f3892deddb269dd3eb1fdcd84._comment
 create mode 100644 doc/git-annex-move/comment_2_f2908113a633034aa73b8564d22abba6._comment
 create mode 100644 doc/git-annex-move/comment_3_82cfbc0f3600c7c4c9dffc1d35e81123._comment
 create mode 100644 doc/git-annex-move/comment_4_013e20add9a007d3f9a9c2a2ceb6cb06._comment
 create mode 100644 doc/git-annex-move/comment_5_e7608b7fac4ec80781cb4281dc2bf596._comment
 create mode 100644 doc/git-annex-move/comment_6_eb62a9020575d89799815f6e4b98b28c._comment
 create mode 100644 doc/git-annex-move/comment_7_e23e2a133db02112ca99aeda0499e841._comment
 create mode 100644 doc/git-annex-multicast.mdwn
 create mode 100644 doc/git-annex-numcopies.mdwn
 create mode 100644 doc/git-annex-oldkeys.mdwn
 create mode 100644 doc/git-annex-p2p.mdwn
 create mode 100644 doc/git-annex-p2p/comment_1_d5a6a2eab5d32a9c2f4ed194e01d95e8._comment
 create mode 100644 doc/git-annex-post-receive.mdwn
 create mode 100644 doc/git-annex-pre-commit.mdwn
 create mode 100644 doc/git-annex-preferred-content.mdwn
 create mode 100644 doc/git-annex-preferred-content/comment_1_4c24f4513af72214bd5feb69f1ab86bc._comment
 create mode 100644 doc/git-annex-preferred-content/comment_2_e4e0f34466db1fecd21db0e929530ad0._comment
 create mode 100644 doc/git-annex-preferred-content/comment_3_73c14351e041ac5ba86f6ab21487fd12._comment
 create mode 100644 doc/git-annex-preferred-content/comment_4_4f30e99af93a2eb571f5b084cfa72d0d._comment
 create mode 100644 doc/git-annex-preferred-content/comment_5_b05949f87e0073e93a7e09658bd21f05._comment
 create mode 100644 doc/git-annex-preferred-content/comment_6_f10a0c185fa2f2b4b8ec9fceaed6e8e1._comment
 create mode 100644 doc/git-annex-proxy.mdwn
 create mode 100644 doc/git-annex-pull.mdwn
 create mode 100644 doc/git-annex-push.mdwn
 create mode 100644 doc/git-annex-readpresentkey.mdwn
 create mode 100644 doc/git-annex-registerurl.mdwn
 create mode 100644 doc/git-annex-reinit.mdwn
 create mode 100644 doc/git-annex-reinject.mdwn
 create mode 100644 doc/git-annex-reinject/comment_1_070a87e0cb1bbc49088989293334e1fb._comment
 create mode 100644 doc/git-annex-reinject/comment_2_d1a04e31fea877ae5fe873fbd01fdcaa._comment
 create mode 100644 doc/git-annex-reinject/comment_3_2dcdd82efbd6dcac0f3b729d55a09386._comment
 create mode 100644 doc/git-annex-rekey.mdwn
 create mode 100644 doc/git-annex-remotedaemon.mdwn
 create mode 100644 doc/git-annex-renameremote.mdwn
 create mode 100644 doc/git-annex-repair.mdwn
 create mode 100644 doc/git-annex-repair/comment_1_088ce57c74a653478e03968e1d6bba23._comment
 create mode 100644 doc/git-annex-required.mdwn
 create mode 100644 doc/git-annex-reregisterurl.mdwn
 create mode 100644 doc/git-annex-resolvemerge.mdwn
 create mode 100644 doc/git-annex-restage.mdwn
 create mode 100644 doc/git-annex-rmurl.mdwn
 create mode 100644 doc/git-annex-rmurl/comment_1_fc99b7e905c81183f78320af266ae1a5._comment
 create mode 100644 doc/git-annex-rmurl/comment_2_181581caac6ee439ba1003ebca79ed09._comment
 create mode 100644 doc/git-annex-satisfy.mdwn
 create mode 100644 doc/git-annex-schedule.mdwn
 create mode 100644 doc/git-annex-semitrust.mdwn
 create mode 100644 doc/git-annex-setkey.mdwn
 create mode 100644 doc/git-annex-setpresentkey.mdwn
 create mode 100644 doc/git-annex-setpresentkey/comment_1_58c98aafb5f6c20c6b71126cd17d3a40._comment
 create mode 100644 doc/git-annex-setpresentkey/comment_2_57b0ae8a49df6c8809aa3050610191b2._comment
 create mode 100644 doc/git-annex-setpresentkey/comment_3_30a5d3fbd8e02726989ab80ed98b4a54._comment
 create mode 100644 doc/git-annex-setpresentkey/comment_4_df3018b9b3491963311063e8ff202df4._comment
 create mode 100644 doc/git-annex-shell.mdwn
 create mode 100644 doc/git-annex-smudge.mdwn
 create mode 100644 doc/git-annex-status.mdwn
 create mode 100644 doc/git-annex-sync.mdwn
 create mode 100644 doc/git-annex-sync/comment_1_2e12ed1c1a594dfbd06a3f25f5e25e57._comment
 create mode 100644 doc/git-annex-sync/comment_2_cc11f83a06352e5049dcbc588d216f27._comment
 create mode 100644 doc/git-annex-sync/comment_3_cf05eba2bcc10f48092334f9ce889863._comment
 create mode 100644 doc/git-annex-sync/comment_4_bd5e45a7e668063df9159033a0857075._comment
 create mode 100644 doc/git-annex-sync/comment_5_5bf6c2b9750dbe5cff87d630f59f511a._comment
 create mode 100644 doc/git-annex-sync/comment_6_2c989d6d9f2ad2821db970cb3aed83c7._comment
 create mode 100644 doc/git-annex-sync/comment_7_8f9a5457020bed293e9a93ccc9461a65._comment
 create mode 100644 doc/git-annex-test.mdwn
 create mode 100644 doc/git-annex-test/comment_1_5fbd7f75fef7a9f504baab1fae05d72c._comment
 create mode 100644 doc/git-annex-test/comment_2_752ca0ba483203cc4f5ccf36752e656d._comment
 create mode 100644 doc/git-annex-test/comment_3_cac436ddf4dec95006d1ebb4171a3289._comment
 create mode 100644 doc/git-annex-testremote.mdwn
 create mode 100644 doc/git-annex-transferkey.mdwn
 create mode 100644 doc/git-annex-transferkeys.mdwn
 create mode 100644 doc/git-annex-transferrer.mdwn
 create mode 100644 doc/git-annex-trust.mdwn
 create mode 100644 doc/git-annex-unannex.mdwn
 create mode 100644 doc/git-annex-unannex/comment_1_281aea2f018ea0fc98452c0d180c3bcb._comment
 create mode 100644 doc/git-annex-unannex/comment_2_d325e4201ec2964c5633e00c473df755._comment
 create mode 100644 doc/git-annex-unannex/comment_3_034db8e67e4bf5321e022918902f38e8._comment
 create mode 100644 doc/git-annex-unannex/comment_4_2a5334f59a4bdf242d53d2d5c120283c._comment
 create mode 100644 doc/git-annex-unannex/comment_5_d549796a3b1bdd3e980cb2c05f30fe2e._comment
 create mode 100644 doc/git-annex-unannex/comment_6_d5a8450349b0383ec29d150420189937._comment
 create mode 100644 doc/git-annex-unannex/comment_7_a6b64c4d90f4d228b8facce5e2399eca._comment
 create mode 100644 doc/git-annex-unannex/comment_8_54a6008e1db73d16d72587830912d772._comment
 create mode 100644 doc/git-annex-undo.mdwn
 create mode 100644 doc/git-annex-undo/comment_1_3466520304aa164ec44ed4e9d67590e7._comment
 create mode 100644 doc/git-annex-undo/comment_2_3dba1a993cbd357bdaa453366c0185cd._comment
 create mode 100644 doc/git-annex-undo/comment_3_ac1369c0417c1dc5f1b41b5cc88fe2fd._comment
 create mode 100644 doc/git-annex-undo/comment_4_18ed23e07ffed1cbf63e71fb115b0654._comment
 create mode 100644 doc/git-annex-ungroup.mdwn
 create mode 100644 doc/git-annex-uninit.mdwn
 create mode 100644 doc/git-annex-uninit/comment_1_075670e8e153e1d9f420b7d53c6ec06d._comment
 create mode 100644 doc/git-annex-uninit/comment_2_c695775bdb2c7491314a33dd6bcb447d._comment
 create mode 100644 doc/git-annex-uninit/comment_4_3386d8419830354b4422d38448467e95._comment
 create mode 100644 doc/git-annex-uninit/comment_5_53358bdd6093e2fb787df8de7190c5fd._comment
 create mode 100644 doc/git-annex-unlock.mdwn
 create mode 100644 doc/git-annex-unlock/comment_10_1f5ca7ccd35e9b102bf24b3f14deeee1._comment
 create mode 100644 doc/git-annex-unlock/comment_11_26ad80a6ad142e7dac6c8af955a4413f._comment
 create mode 100644 doc/git-annex-unlock/comment_1_d7f38f681be51db1244988847840d735._comment
 create mode 100644 doc/git-annex-unlock/comment_2_51158d4484ecb39633ec828beb8d9ce3._comment
 create mode 100644 doc/git-annex-unlock/comment_3_516a1522db3d1c14cc5131a24d672a8f._comment
 create mode 100644 doc/git-annex-unlock/comment_4_d04a1d4159306939b91a34fd17ab0325._comment
 create mode 100644 doc/git-annex-unlock/comment_5_40abc819288a97753747562f16b8febe._comment
 create mode 100644 doc/git-annex-unlock/comment_6_047355b1ba5e90b71fc85b42f52d1aeb._comment
 create mode 100644 doc/git-annex-unlock/comment_6_7ab5b674d0fc18da262e6c0264953e21._comment
 create mode 100644 doc/git-annex-unlock/comment_8_d10c8b6e2dd8800cbfc11a7fa8536065._comment
 create mode 100644 doc/git-annex-unlock/comment_9_31c72f60ddf029f09c1850223d5a8a55._comment
 create mode 100644 doc/git-annex-unregisterurl.mdwn
 create mode 100644 doc/git-annex-untrust.mdwn
 create mode 100644 doc/git-annex-unused.mdwn
 create mode 100644 doc/git-annex-unused/comment_11_5c1ea2e8ac475d8c0ddca2c38f968b95._comment
 create mode 100644 doc/git-annex-unused/comment_12_573e68def90ffd899271c6a9f80eae3c._comment
 create mode 100644 doc/git-annex-unused/comment_13_4a935c0c8862b24202c877031c35e238._comment
 create mode 100644 doc/git-annex-unused/comment_1_029c4bee59e48806c9f3d83579fdbb90._comment
 create mode 100644 doc/git-annex-unused/comment_2_c4d994706f69024788e6653d02a09517._comment
 create mode 100644 doc/git-annex-unused/comment_2_ca010846ef8eed4a302b6755f1f521f4._comment
 create mode 100644 doc/git-annex-unused/comment_3_5eb913bb96a04a174c04fe5d119977f4._comment
 create mode 100644 doc/git-annex-unused/comment_4_5b208cb45335f0d383a456865068e659._comment
 create mode 100644 doc/git-annex-unused/comment_5_65ab9f687f2817199eda7455d9b82677._comment
 create mode 100644 doc/git-annex-unused/comment_6_962097729f8b4a657bb7b9863fdffb68._comment
 create mode 100644 doc/git-annex-unused/comment_7_e21b036767651c5cfdd34bbd24a31fb5._comment
 create mode 100644 doc/git-annex-unused/comment_8_10ee2770ffe1cde367f3d310b2670539._comment
 create mode 100644 doc/git-annex-unused/comment_9_cfcc0bab810d58b7db66c2fa4e92f769._comment
 create mode 100644 doc/git-annex-upgrade.mdwn
 create mode 100644 doc/git-annex-vadd.mdwn
 create mode 100644 doc/git-annex-vcycle.mdwn
 create mode 100644 doc/git-annex-version.mdwn
 create mode 100644 doc/git-annex-vfilter.mdwn
 create mode 100644 doc/git-annex-vicfg.mdwn
 create mode 100644 doc/git-annex-view.mdwn
 create mode 100644 doc/git-annex-vpop.mdwn
 create mode 100644 doc/git-annex-wanted.mdwn
 create mode 100644 doc/git-annex-watch.mdwn
 create mode 100644 doc/git-annex-webapp.mdwn
 create mode 100644 doc/git-annex-webapp/comment_1_443c5595412a19ef9c6948c4224297a3._comment
 create mode 100644 doc/git-annex-webapp/comment_2_7b1c4c4356e801006081588b32075fb4._comment
 create mode 100644 doc/git-annex-webapp/comment_3_aee70625f7cff6e7312f9bc2cbbb02d0._comment
 create mode 100644 doc/git-annex-webapp/comment_4_c1754cdb4087ad278867ed8fddd99409._comment
 create mode 100644 doc/git-annex-webapp/comment_5_31301895752f0dd81db72c463f0dc732._comment
 create mode 100644 doc/git-annex-whereis.mdwn
 create mode 100644 doc/git-annex-whereis/comment_1_6a1f97de22983127bfc351d14838fb0e._comment
 create mode 100644 doc/git-annex-whereis/comment_2_69a861de80c7d2b939aae7103b1b7359._comment
 create mode 100644 doc/git-annex-whereis/comment_3_d06a33bfaeb2a9274d12639fdedcfa8a._comment
 create mode 100644 doc/git-annex-whereis/comment_4_3f06096e582178b4c69d63e84735d911._comment
 create mode 100644 doc/git-annex-whereused.mdwn
 create mode 100644 doc/git-annex-whereused/comment_1_bebd4ad86c6a64cc48e6f0dd5861f3de._comment
 create mode 100644 doc/git-annex-whereused/comment_2_f926fbe7c558a242a2af949daed415f7._comment
 create mode 100644 doc/git-annex-whereused/comment_3_bc04457bf320e81437c2eb858793c5ca._comment
 create mode 100644 doc/git-annex.mdwn
 create mode 100644 doc/git-remote-tor-annex.mdwn
 create mode 100644 doc/git-union-merge.mdwn
 create mode 100644 doc/how_it_works.mdwn
 create mode 100644 doc/how_it_works/comment_1_b3bdd6a06d5764db521ae54878131f5f._comment
 create mode 100644 doc/how_it_works/comment_2_2a8ce5859040d815e6234fc18f5f1961._comment
 create mode 100644 doc/how_it_works/comment_3_806c0fe325942a425e43afb9b78327ec._comment
 create mode 100644 doc/how_it_works/comment_4_0ef6b8c9dbd5a7f9b9f274dc6f9988f0._comment
 create mode 100644 doc/how_it_works/comment_5_11e5141c9ffb37db4fa0c1bfb32c51a9._comment
 create mode 100644 doc/how_it_works/comment_6_2ad3441a02f1bcc2cca0c10ecf7b216f._comment
 create mode 100644 doc/index.mdwn
 create mode 100644 doc/install.mdwn
 create mode 100644 doc/install/AlpineLinux.mdwn
 create mode 100644 doc/install/Android.mdwn
 create mode 100755 doc/install/Android/git-annex-install
 create mode 100644 doc/install/Android/oldapp.mdwn
 create mode 100644 doc/install/Android/oldapp/comment_10_225f2c6fe255be93702cfbd4dc172f3b._comment
 create mode 100644 doc/install/Android/oldapp/comment_10_4b565e73f02f0e84bdf7e686b0d7bf5f._comment
 create mode 100644 doc/install/Android/oldapp/comment_11_3e7980603749665fafbdeb1b7ab068a5._comment
 create mode 100644 doc/install/Android/oldapp/comment_11_4e970633d9073fcf4bc33f3fff2525b2._comment
 create mode 100644 doc/install/Android/oldapp/comment_12_57867e2b13b83cc9815df56b027d388a._comment
 create mode 100644 doc/install/Android/oldapp/comment_12_87da4f379a0276b662583e7e22061218._comment
 create mode 100644 doc/install/Android/oldapp/comment_13_169025cf0b415d5a45dd89856e53cca9._comment
 create mode 100644 doc/install/Android/oldapp/comment_14_19909ddf4e7e6da0e814e165c5c9b44a._comment
 create mode 100644 doc/install/Android/oldapp/comment_1_f9ced494a530e6ae3e76cfbaddb89f5d._comment
 create mode 100644 doc/install/Android/oldapp/comment_2_74cccae04ea23a8600069c7e658143aa._comment
 create mode 100644 doc/install/Android/oldapp/comment_3_82c7cb31d19d4e18ca5548da5ca19a79._comment
 create mode 100644 doc/install/Android/oldapp/comment_4_cebaa8ee5bbed27d9b2d032ca7bdec6e._comment
 create mode 100644 doc/install/Android/oldapp/comment_8_34f7c42050fa48769a6bfae60d72e477._comment
 create mode 100644 doc/install/Android/oldapp/comment_9_f3d289b78d6bdb3cc65689495a8439a5._comment
 create mode 100644 doc/install/ArchLinux.mdwn
 create mode 100644 doc/install/ArchLinux/comment_10_b68c42b3804481808dfe83ae557edec3._comment
 create mode 100644 doc/install/ArchLinux/comment_11_0d51aaebe5929b03cba38156a97bf3cc._comment
 create mode 100644 doc/install/ArchLinux/comment_2_e5f923e6d81cfb3fba7a72f60baaf4ab._comment
 create mode 100644 doc/install/ArchLinux/comment_3_8e607cd883ec174571e9dfe3b25bfd05._comment
 create mode 100644 doc/install/ArchLinux/comment_4_a378391dd218859f381c479259dd8fe3._comment
 create mode 100644 doc/install/ArchLinux/comment_6_1d597d6a95f9c2df7dae6e98813e4865._comment
 create mode 100644 doc/install/ArchLinux/comment_7_2d708977e2fad6b68803494576382df5._comment
 create mode 100644 doc/install/ArchLinux/comment_7_97d611f1ae6d4fbe91f84f9fe739f368._comment
 create mode 100644 doc/install/ArchLinux/comment_8_5b5f5e0b64e5bfb1ea12e8b251c6fb5f._comment
 create mode 100644 doc/install/ArchLinux/comment_8_ddc13b45286933e7dd06f5bd6ea8fac9._comment
 create mode 100644 doc/install/ArchLinux/comment_9_b5f1bd5d92cf35002e2ea75e07040bea._comment
 create mode 100644 doc/install/Debian.mdwn
 create mode 100644 doc/install/Debian/comment_11_b44ed53973ac26eedd3838df28f74a7e._comment
 create mode 100644 doc/install/Debian/comment_12_a0105d7f045511b9c80ea9bb0eac3708._comment
 create mode 100644 doc/install/Debian/comment_13_435fb1359ea7f481ae23a973216085d8._comment
 create mode 100644 doc/install/Debian/comment_14_a34e23d9aa3027012ab1236aa4f7d5cb._comment
 create mode 100644 doc/install/Debian/comment_15_20d8271ba3f6cfe3c8849c3d41607630._comment
 create mode 100644 doc/install/Debian/comment_16_89f67da4a4a6a626a7db9c6674b244b6._comment
 create mode 100644 doc/install/Debian/comment_17_ef7f3e88d61833e51f0302e938343818._comment
 create mode 100644 doc/install/Debian/comment_1_029486088d098c2d4f1099f2f0e701a9._comment
 create mode 100644 doc/install/Debian/comment_2_648e3467e260cdf233acdb0b53313ce0._comment
 create mode 100644 doc/install/Debian/comment_3_4d922e11249627634ecc35bba4044d9e._comment
 create mode 100644 doc/install/Debian/comment_4_2a93ab18b05ccb90e7acc5885866fca2._comment
 create mode 100644 doc/install/Debian/comment_7_1bccc7bf7a4ef61a9b30024b9b22ba7d._comment
 create mode 100644 doc/install/Debian/comment_8_5b5a3b0e8abe8831a6a15a4e258d14fd._comment
 create mode 100644 doc/install/Docker.mdwn
 create mode 100644 doc/install/Docker/comment_1_909e3b2da0050ce1102c289cc5aac522._comment
 create mode 100644 doc/install/Fedora.mdwn
 create mode 100644 doc/install/Fedora/comment_1_c4db84e672ad4b45b522db735706b00f._comment
 create mode 100644 doc/install/Fedora/comment_2_f98c488c09bef86e2b0414589ce9e141._comment
 create mode 100644 doc/install/Fedora/comment_3_d872acf8865fe7c99a9b712db5b38ea4._comment
 create mode 100644 doc/install/Fedora/comment_4_93b3402e4c51e1a5c96f907bb528164b._comment
 create mode 100644 doc/install/Fedora/comment_5_0427e0503764b29e57abf9e97155136b._comment
 create mode 100644 doc/install/Fedora/comment_6_1b1b38a79251fe2e8c1e4debbe3bc3c5._comment
 create mode 100644 doc/install/Fedora/comment_7_4832d271dcc63a6cd1c40fe38ad5e367._comment
 create mode 100644 doc/install/Fedora/comment_8_80e167cde1a6511683a8f6e8029c0da6._comment
 create mode 100644 doc/install/FreeBSD.mdwn
 create mode 100644 doc/install/Gentoo.mdwn
 create mode 100644 doc/install/Guix.mdwn
 create mode 100644 doc/install/Linux_standalone.mdwn
 create mode 100644 doc/install/Linux_standalone/comment_1_1adc00aecc51f1e74701bd67cd74155d._comment
 create mode 100644 doc/install/Linux_standalone/comment_2_7983285b56fd10359a7cc3615fd1e2fe._comment
 create mode 100644 doc/install/Linux_standalone/comment_3_eaa9b0532d4629b61f3a684886b1d4f9._comment
 create mode 100644 doc/install/Linux_standalone/comment_4_070689ea45739d06260da07d1369dff9._comment
 create mode 100644 doc/install/Linux_standalone/comment_5_9046b80114fc03179c971bfb3e4d666d._comment
 create mode 100644 doc/install/NixOS.mdwn
 create mode 100644 doc/install/NixOS/comment_1_4e487ddd2654a8a992c1538b9c3bf003._comment
 create mode 100644 doc/install/OSX.mdwn
 create mode 100644 doc/install/OSX/Homebrew.mdwn
 create mode 100644 doc/install/OSX/Homebrew/comment_1_61cad5a309c3c4e3f278dec1890c9f40._comment
 create mode 100644 doc/install/OSX/Homebrew/comment_2_2f89cfbc42590885fb7e92a89d0f7895._comment
 create mode 100644 doc/install/OSX/MacPorts.mdwn
 create mode 100644 doc/install/OSX/MacPorts/comment_21_987f1302f56107c926b6daf83e124654._comment
 create mode 100644 doc/install/OSX/MacPorts/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment
 create mode 100644 doc/install/OSX/comment_10_e5172de344908f85ce6cf976e3c3806b._comment
 create mode 100644 doc/install/OSX/comment_11_8d53c477b441ab0984257b21003c7cc7._comment
 create mode 100644 doc/install/OSX/comment_12_17b84f51de6bed88e373350b194c8a8d._comment
 create mode 100644 doc/install/OSX/comment_13_f4b39e2009274539d60b29711a4a2c8d._comment
 create mode 100644 doc/install/OSX/comment_14_5581b7d1c09e6a78419d626bb25261b6._comment
 create mode 100644 doc/install/OSX/comment_15_dda16b58686b0e5d061521f8e1831f89._comment
 create mode 100644 doc/install/OSX/comment_16_277249620801bd4305776a3d598bd074._comment
 create mode 100644 doc/install/OSX/comment_17_06e8fc7a4670a42c249f90a3602c3523._comment
 create mode 100644 doc/install/OSX/comment_18_5eca3153048d2b3b4fa707d6b8a5ebeb._comment
 create mode 100644 doc/install/OSX/comment_19_040d388c94ee0e537990f0cd782d8554._comment
 create mode 100644 doc/install/OSX/comment_20_3e6a3c00444badf2cf7a9ee3d54af11e._comment
 create mode 100644 doc/install/OSX/comment_21_951e6bb1f70d8f02374e9e3fb91dc182._comment
 create mode 100644 doc/install/OSX/comment_22_6ae394921280d3cd4907f210b9845a2f._comment
 create mode 100644 doc/install/OSX/comment_23_895d4e837d05a318512730d66f14db22._comment
 create mode 100644 doc/install/OSX/comment_23_af10ed56c037499d002fcf0114b9426a._comment
 create mode 100644 doc/install/OSX/comment_25_db90984062a07576a4777b2d743161f1._comment
 create mode 100644 doc/install/OSX/comment_2_25552ff2942048fafe97d653757f1ad6._comment
 create mode 100644 doc/install/OSX/comment_4_25cac8bcd84a5210fc0a5243260b8cc7._comment
 create mode 100644 doc/install/OSX/comment_5_39b4b748b4586bf32b37edfefef84bba._comment
 create mode 100644 doc/install/OSX/comment_6_1a9c91ef43edc4148947f202ff604114._comment
 create mode 100644 doc/install/OSX/comment_7_892f7e65f95f43697164267c4b71c0d5._comment
 create mode 100644 doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment
 create mode 100644 doc/install/OSX/comment_9_f11f726d1fee3c4c91f3c984e792037d._comment
 create mode 100644 doc/install/OSX/old_comments.mdwn
 create mode 100644 doc/install/OSX/old_comments/comment_10_4d15bfc4fc26e7249953bebfbb09e0aa._comment
 create mode 100644 doc/install/OSX/old_comments/comment_10_798000aab19af2944b6e44dbc550c6fe._comment
 create mode 100644 doc/install/OSX/old_comments/comment_11_707a1a27a15b2de8dfc8d1a30420ab4c._comment
 create mode 100644 doc/install/OSX/old_comments/comment_12_60d13f2c8e008af1041bea565a392c83._comment
 create mode 100644 doc/install/OSX/old_comments/comment_13_a6f48c87c2d6eabe379d6e10a6cac453._comment
 create mode 100644 doc/install/OSX/old_comments/comment_14_6ef2ddb7b11ce6ad54578ae118ed346e._comment
 create mode 100644 doc/install/OSX/old_comments/comment_15_6fd1fad5b6d9f36620e5a0e99edd2f89._comment
 create mode 100644 doc/install/OSX/old_comments/comment_16_af6fe3540032cdf4400478de87771058._comment
 create mode 100644 doc/install/OSX/old_comments/comment_17_8d3a0596db67108041728b20f2790f31._comment
 create mode 100644 doc/install/OSX/old_comments/comment_1_0a1760bf0db1f1ba89bdb4c62032f631._comment
 create mode 100644 doc/install/OSX/old_comments/comment_2_0327c64b15249596add635d26f4ce67f._comment
 create mode 100644 doc/install/OSX/old_comments/comment_2_7683740a98182de06cb329792e0c0a25._comment
 create mode 100644 doc/install/OSX/old_comments/comment_34_c9362141d15a2f68a75df9f8bfe29da0._comment
 create mode 100644 doc/install/OSX/old_comments/comment_35_8106196c3fef70652cb2106e2d5857db._comment
 create mode 100644 doc/install/OSX/old_comments/comment_3_47c682a779812dda77601c24a619923c._comment
 create mode 100644 doc/install/OSX/old_comments/comment_3_733147cebe501c60f2141b711f1d7f24._comment
 create mode 100644 doc/install/OSX/old_comments/comment_3_b090f40fe5a32e00b472a5ab2b850b4a._comment
 create mode 100644 doc/install/OSX/old_comments/comment_3_fc092412e99cf4c5f095b0ef710bc4de._comment
 create mode 100644 doc/install/OSX/old_comments/comment_4_d513e21512a9b207983d38abf348d00f._comment
 create mode 100644 doc/install/OSX/old_comments/comment_4_d68c36432c7be3f4a76f4f0d7300bac9._comment
 create mode 100644 doc/install/OSX/old_comments/comment_4_e6109a964064a2a799768a370e57801d._comment
 create mode 100644 doc/install/OSX/old_comments/comment_5_50777853f808d57b957f8ce9a0f84b3d._comment
 create mode 100644 doc/install/OSX/old_comments/comment_5_626a4b4bf302d4ae750174f860402f70._comment
 create mode 100644 doc/install/OSX/old_comments/comment_6_18a8df794aa0ddd294dbf17d3d4c7fe2._comment
 create mode 100644 doc/install/OSX/old_comments/comment_7_2ce7acab15403d3f993cec94ec7f3bc6._comment
 create mode 100644 doc/install/OSX/old_comments/comment_8_a93ad4b67c5df4243268bcf32562f6be._comment
 create mode 100644 doc/install/OSX/old_comments/comment_9_ae3ed5345bc84f57e44251d2e6c39342._comment
 create mode 100644 doc/install/OSX/old_comments/comment_9_c6b1b31d16f2144ad08abd8c767b6ab9._comment
 create mode 100644 doc/install/OSX/porting.mdwn
 create mode 100644 doc/install/OSX/porting/comment_10_cd2120552ef894a37933b328136fa4cc._comment
 create mode 100644 doc/install/OSX/porting/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment
 create mode 100644 doc/install/OSX/porting/comment_12_a84028080578a8b60115b6c4ef823627._comment
 create mode 100644 doc/install/OSX/porting/comment_13_d6f1db401858ffea23c123db49f5b296._comment
 create mode 100644 doc/install/OSX/porting/comment_14_035f856923276b0edad879e196e94097._comment
 create mode 100644 doc/install/OSX/porting/comment_15_336e0acb00e84943715e69917643a69e._comment
 create mode 100644 doc/install/OSX/porting/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment
 create mode 100644 doc/install/OSX/porting/comment_17_19c08b2c6c2c5cd88bf96d2bcbbd9055._comment
 create mode 100644 doc/install/OSX/porting/comment_18_537fad5d8854e765499d47602d1ab398._comment
 create mode 100644 doc/install/OSX/porting/comment_19_18d4377f4ded5604d395d73783ba82c9._comment
 create mode 100644 doc/install/OSX/porting/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment
 create mode 100644 doc/install/OSX/porting/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment
 create mode 100644 doc/install/OSX/porting/comment_24_b9d3563a2cc3d769f27876e028dc344d._comment
 create mode 100644 doc/install/OSX/porting/comment_27_2a60108a440231ba83f5a54b6bcc5488._comment
 create mode 100644 doc/install/OSX/porting/comment_27_d453510b9bb62072a4c663206c12c8a4._comment
 create mode 100644 doc/install/OSX/porting/comment_28_0970bfd63137ea48701dff6aea1b4bcb._comment
 create mode 100644 doc/install/OSX/porting/comment_29_8622ed56c6a8034c20fb311418d94003._comment
 create mode 100644 doc/install/OSX/porting/comment_30_ce58633ef5b2f8f4caa7e626358f33be._comment
 create mode 100644 doc/install/OSX/porting/comment_31_09084a7b3cf06bfa3add0f4991476ffe._comment
 create mode 100644 doc/install/OSX/porting/comment_32_a46d8e3e7795b9afb1e1c2be943d12af._comment
 create mode 100644 doc/install/OSX/porting/comment_33_203a36322b3c453c05c8906c64e62e06._comment
 create mode 100644 doc/install/OSX/porting/comment_34_874ff01f27911baf6ef0f559d5d5f5a0._comment
 create mode 100644 doc/install/OSX/porting/comment_8_38d9c2eea1090674de2361274eab5b0e._comment
 create mode 100644 doc/install/OSX/porting/comment_9_35bf3812db6f3ef25da9b3bc84f147c5._comment
 create mode 100644 doc/install/OpenBSD.mdwn
 create mode 100644 doc/install/RHEL.mdwn
 create mode 100644 doc/install/ScientificLinux.mdwn
 create mode 100644 doc/install/Ubuntu.mdwn
 create mode 100644 doc/install/Ubuntu/Phone.mdwn
 create mode 100644 doc/install/Ubuntu/comment_10_490e065314693423ab6969d8ae6978fe._comment
 create mode 100644 doc/install/Ubuntu/comment_11_4ebac3fb43de854ed1a3b1d2ea94011a._comment
 create mode 100644 doc/install/Ubuntu/comment_12_38f69dffe2db0d15e4c4e5cb47f40ef8._comment
 create mode 100644 doc/install/Ubuntu/comment_13_7964374bb2332940677eea570bdb0b69._comment
 create mode 100644 doc/install/Ubuntu/comment_14_b511063001af2e2170bef657cf016ff2._comment
 create mode 100644 doc/install/Ubuntu/comment_15_4ea052431b49a0505b4a58a760054bed._comment
 create mode 100644 doc/install/Ubuntu/comment_16_b5dd1d73309e427d6e817a3a69beea74._comment
 create mode 100644 doc/install/Ubuntu/comment_1_d1c511153fe94bf33e19a1281f1c92f2._comment
 create mode 100644 doc/install/Ubuntu/comment_2_ad13886c1c1f76d1cd995ea7b7d8471c._comment
 create mode 100644 doc/install/Ubuntu/comment_3_a08817322739b03cf0fec97283b16f1a._comment
 create mode 100644 doc/install/Ubuntu/comment_4_fe0997e56136bd30749f0995cbf19b56._comment
 create mode 100644 doc/install/Ubuntu/comment_5_fbb5306a162db1a1ee9efa3523aac952._comment
 create mode 100644 doc/install/Ubuntu/comment_6_a97e7f0e62ac685c3ded423bddeaa67f._comment
 create mode 100644 doc/install/Ubuntu/comment_7_921a223fd7e679b9ced3d8ba5ce688e0._comment
 create mode 100644 doc/install/Ubuntu/comment_8_1f943cb084fa8e21bc6ee5fc3118f02f._comment
 create mode 100644 doc/install/Ubuntu/comment_9_c2f8b35ada873acb1ce593b04e2899fe._comment
 create mode 100644 doc/install/Void.mdwn
 create mode 100644 doc/install/Windows.mdwn
 create mode 100644 doc/install/Windows/comment_10_39edee046193c7d36daaf245fa87007c._comment
 create mode 100644 doc/install/Windows/comment_11_6310a850074cf65b1c0b5b49e2e5b582._comment
 create mode 100644 doc/install/Windows/comment_12_3a7080a31d30ccb32fede56a98bb635a._comment
 create mode 100644 doc/install/Windows/comment_13_6a998c400070059477de18a81a3ba0b5._comment
 create mode 100644 doc/install/Windows/comment_14_7b5f0c6b31d9c409ea0989123788bacf._comment
 create mode 100644 doc/install/Windows/comment_15_19226be8cae0c29b0e9a54cebcf1f17b._comment
 create mode 100644 doc/install/Windows/comment_16_b4b60bed666355ace286775afe87860d._comment
 create mode 100644 doc/install/Windows/comment_17_165ac8b0e1cd4f250e681eb88c0624d3._comment
 create mode 100644 doc/install/Windows/comment_18_e0adfbf74754f847dc4705685cf00640._comment
 create mode 100644 doc/install/Windows/comment_1_e5e5c7b75859493a7d94cbf7df746fb9._comment
 create mode 100644 doc/install/Windows/comment_2_ef329ea100b36a1180e232a1f97369d6._comment
 create mode 100644 doc/install/Windows/comment_3_10fb90bc434b4da189ed7235818ef30f._comment
 create mode 100644 doc/install/Windows/comment_4_c81a36e387ca11050cf8cb977fff98ff._comment
 create mode 100644 doc/install/Windows/comment_5_88ad2f657bf92e8c6144608612b9be49._comment
 create mode 100644 doc/install/Windows/comment_6_90ef5d5a4f66ac3e440aadf302a625a9._comment
 create mode 100644 doc/install/Windows/comment_7_0589dd8c33572dd1d0ef5cb7b29ebba7._comment
 create mode 100644 doc/install/Windows/comment_8_35c66016c971a623ec86318adf7923b4._comment
 create mode 100644 doc/install/Windows/comment_9_2687128ff7aa4b6f29e8b880b5d4d13d._comment
 create mode 100644 doc/install/comment_1_0aa16754fb08d8f2a54c8c3f78b6c187._comment
 create mode 100644 doc/install/comment_2_ba3985a5cbd9f5682807d2bdbb9874e2._comment
 create mode 100644 doc/install/comment_3_9a2118d6f967585cb21f9d9b372f4017._comment
 create mode 100644 doc/install/comment_5_a2532a0fea59d15a2efa11748ff0d70a._comment
 create mode 100644 doc/install/comment_6_4ae37152bc9765cea921b436fb2785d8._comment
 create mode 100644 doc/install/comment_7_bc273d60cb74241231183186aefbc147._comment
 create mode 100644 doc/install/comment_8_1330a5413b720eca0103a0880d24eb2d._comment
 create mode 100644 doc/install/comment_8_768498659909c37044f2b4dd08bacda3._comment
 create mode 100644 doc/install/conda.mdwn
 create mode 100644 doc/install/conda/comment_1_d9fbae3aca8853a13919350d405d686b._comment
 create mode 100644 doc/install/conda/comment_2_8968f1e04a08fb95644910089438b02d._comment
 create mode 100644 doc/install/fromsource.mdwn
 create mode 100644 doc/install/fromsource/comment_10_7ebe353b05d4df29897dc9a4f45c8a91._comment
 create mode 100644 doc/install/fromsource/comment_11_0d06702e6e0ae3cd331cf748a9f6f273._comment
 create mode 100644 doc/install/fromsource/comment_12_b93ca271dffca3f948645d3e1326c1d9._comment
 create mode 100644 doc/install/fromsource/comment_13_3dac019cda71bf99878c0a1d9382323b._comment
 create mode 100644 doc/install/fromsource/comment_14_14b46470593f84f8c3768a91cb77bdab._comment
 create mode 100644 doc/install/fromsource/comment_15_c3a5b0aad28a90e0bb8da31a430578eb._comment
 create mode 100644 doc/install/fromsource/comment_16_4faf214f97f9516898d7c17d743ef825._comment
 create mode 100644 doc/install/fromsource/comment_17_2a9d6807a3a13815c824985521757167._comment
 create mode 100644 doc/install/fromsource/comment_18_1efa0c7a963ec452fc6336fbe4964f6e._comment
 create mode 100644 doc/install/fromsource/comment_19_6f42f9234f9ff6a2ca6bbb4d2643843e._comment
 create mode 100644 doc/install/fromsource/comment_1_9d085e460553fa045999ab7cb945cdec._comment
 create mode 100644 doc/install/fromsource/comment_1_f04df6bcd50d1d01eb34868bb00ac35c._comment
 create mode 100644 doc/install/fromsource/comment_20_0f553be2a4c666e3bed58b2bce549406._comment
 create mode 100644 doc/install/fromsource/comment_21_f91a6ec21e96eced73ea9579fd8cbd15._comment
 create mode 100644 doc/install/fromsource/comment_22_2f27b78215f97ade1986ca806c634cb3._comment
 create mode 100644 doc/install/fromsource/comment_23_c34d2b1d95830a3e58671a5b566a1758._comment
 create mode 100644 doc/install/fromsource/comment_24_40cbde8ec067b3a860e6df1a9bea5f76._comment
 create mode 100644 doc/install/fromsource/comment_25_8a7664e6f9271718dc607a0782366c5b._comment
 create mode 100644 doc/install/fromsource/comment_26_bd455c732639728bce2bfc39e32871d2._comment
 create mode 100644 doc/install/fromsource/comment_27_c080e9239b6eec88d329c28da7bb4141._comment
 create mode 100644 doc/install/fromsource/comment_28_15951dd070a675300420eea137a28ef9._comment
 create mode 100644 doc/install/fromsource/comment_29_ac082dca67f4a29b06070c0283130f52._comment
 create mode 100644 doc/install/fromsource/comment_2_a69d17c55e56a707ec6606d5cdddee25._comment
 create mode 100644 doc/install/fromsource/comment_2_b7954521d9ab40622b665f278dd72e17._comment
 create mode 100644 doc/install/fromsource/comment_30_ad639c07cb79e89406e95c1dafce3a01._comment
 create mode 100644 doc/install/fromsource/comment_31_4763b24a29627d55f465b9ea260ea7ec._comment
 create mode 100644 doc/install/fromsource/comment_32_1d34c294486c85b1149675fa5861ae35._comment
 create mode 100644 doc/install/fromsource/comment_33_8d4dfc33cada6091c30d3a43ce404b8b._comment
 create mode 100644 doc/install/fromsource/comment_34_38451e751add6daf479b559c4b6a7c61._comment
 create mode 100644 doc/install/fromsource/comment_35_4d44e4531e6686bd340f26836ad40026._comment
 create mode 100644 doc/install/fromsource/comment_36_2a095a5af53a356bd29abd22a9cb1bea._comment
 create mode 100644 doc/install/fromsource/comment_37_f33e1a4575dccc20b0d3d7c00e6db709._comment
 create mode 100644 doc/install/fromsource/comment_38_5c1e96221154a4ae4ebd636232044ced._comment
 create mode 100644 doc/install/fromsource/comment_39_a86057d7e6d47113330f79e1812c3a5d._comment
 create mode 100644 doc/install/fromsource/comment_3_55bed050bdb768543dbe1b86edec057d._comment
 create mode 100644 doc/install/fromsource/comment_3_a3bf3ce57ea73515a059267f25b816eb._comment
 create mode 100644 doc/install/fromsource/comment_45_d9cccbb9620cc8218e72b5380fd89a05._comment
 create mode 100644 doc/install/fromsource/comment_46_954de34275d33bc4590927f911761563._comment
 create mode 100644 doc/install/fromsource/comment_47_6de25c1e450e1e3b1d18d2c76235ccb8._comment
 create mode 100644 doc/install/fromsource/comment_48_9c08300c5d172ba9223042a00c8acb2b._comment
 create mode 100644 doc/install/fromsource/comment_49_c8370525547b435d963a2c1192a21124._comment
 create mode 100644 doc/install/fromsource/comment_4_2ff7f8a3b03bea7e860248829d595bd1._comment
 create mode 100644 doc/install/fromsource/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment
 create mode 100644 doc/install/fromsource/comment_50_c1ce6084ba1e96afa30e18f0f6433aa4._comment
 create mode 100644 doc/install/fromsource/comment_51_514bac1020c4227a23380d1675184fc7._comment
 create mode 100644 doc/install/fromsource/comment_52_df7d36e4d169fbc4199026d7af1aa581._comment
 create mode 100644 doc/install/fromsource/comment_53_e4bb31024aa4a317be2f45667b6d6f9f._comment
 create mode 100644 doc/install/fromsource/comment_54_d7fabada8101596954ed7e401a8c460b._comment
 create mode 100644 doc/install/fromsource/comment_55_0592c3d36ab569cd777009a491e25ba2._comment
 create mode 100644 doc/install/fromsource/comment_57_13a198daa871e001b02b9df2e8d7c446._comment
 create mode 100644 doc/install/fromsource/comment_57_efac370d382fc79e1f207e8090e0f06b._comment
 create mode 100644 doc/install/fromsource/comment_58_64b44da5ec93fe4f50ad8b856823558d._comment
 create mode 100644 doc/install/fromsource/comment_59_4ef618a5de9b86ffa54ae849cbb329bb._comment
 create mode 100644 doc/install/fromsource/comment_5_4aea55dc5b24d84e0953382ccfea1a01._comment
 create mode 100644 doc/install/fromsource/comment_5_8789fc27466714faa5a3a7a6b8ec6e5d._comment
 create mode 100644 doc/install/fromsource/comment_60_55ec2dcb5e1b5e272fdd53aa063bc162._comment
 create mode 100644 doc/install/fromsource/comment_61_7fb2a70b6d39ad95ee701a99b9e19961._comment
 create mode 100644 doc/install/fromsource/comment_62_4cf71016c3b42ec972760a938031cbf9._comment
 create mode 100644 doc/install/fromsource/comment_63_dddfc7e7d2fa09008f538abde3213b45._comment
 create mode 100644 doc/install/fromsource/comment_64_c3195cbc42058593ea6ca9d2eaaf9722._comment
 create mode 100644 doc/install/fromsource/comment_65_663426a5014e5a38d477fb6fed411c17._comment
 create mode 100644 doc/install/fromsource/comment_66_849c4c2cfc34991c13d55495e391cce3._comment
 create mode 100644 doc/install/fromsource/comment_67_5655a80d206bd1f7cf1f326c645df7ed._comment
 create mode 100644 doc/install/fromsource/comment_68_059f1cd929228e131bf88d80aca0b573._comment
 create mode 100644 doc/install/fromsource/comment_69_444e529f8838ef127ff115eb6c2ef8ca._comment
 create mode 100644 doc/install/fromsource/comment_6_5afb2d081e8b603bc338cd460ad9317d._comment
 create mode 100644 doc/install/fromsource/comment_70_ab27934713fa6032ec9992f7e04fa9c5._comment
 create mode 100644 doc/install/fromsource/comment_71_3075af9a88b717c8ff1a489177e689f4._comment
 create mode 100644 doc/install/fromsource/comment_72_fb9581f4949efe1e8c90851fce9d61bf._comment
 create mode 100644 doc/install/fromsource/comment_73_bc163a82180b00a8b757edf269cebc06._comment
 create mode 100644 doc/install/fromsource/comment_74_473d320a05f08ce3cbe24789dcb01200._comment
 create mode 100644 doc/install/fromsource/comment_75_58dfd18135aa187d8b3977521ecff2d2._comment
 create mode 100644 doc/install/fromsource/comment_7_129c4f2e404c874e5adfa52902a81104._comment
 create mode 100644 doc/install/fromsource/comment_8_738c108f131e3aab0d720bc4fd6a81fd._comment
 create mode 100644 doc/install/fromsource/comment_9_5ddbba419d96a7411f7edddaa4d7b739._comment
 create mode 100644 doc/install/openSUSE.mdwn
 create mode 100644 doc/install/openSUSE/comment_1_a5aea1ef644d0402d3caf593fef2456f._comment
 create mode 100644 doc/install/openSUSE/comment_2_095d48e7dffe57421b2d3384a83d7183._comment
 create mode 100644 doc/install/rpm_standalone.mdwn
 create mode 100644 doc/install/rpm_standalone/comment_1_7d234e64f3b6e97cd6d91c339ebb0025._comment
 create mode 100644 doc/install/rpm_standalone/comment_2_11f0fdc5be4fd6620732867070c53477._comment
 create mode 100644 doc/install/rpm_standalone/comment_3_3a38ab16ca034025476b4df0a566b4a9._comment
 create mode 100644 doc/install/verifying_downloads.mdwn
 create mode 100644 doc/internals.mdwn
 create mode 100644 doc/internals/comment_10_c4298babd96b2596bd4f6ad828212c92._comment
 create mode 100644 doc/internals/comment_11_9758bb3a17f63b4dcf51742ea482dbe9._comment
 create mode 100644 doc/internals/comment_12_f0325cefa5cd53a5a897046606137cef._comment
 create mode 100644 doc/internals/comment_13_e45b6fa035a30703618448a0f764f935._comment
 create mode 100644 doc/internals/comment_14_3f62751c2dd041f4ead1c6580ea5eec1._comment
 create mode 100644 doc/internals/comment_15_c3d12d14e4d044f39829c5d92f523655._comment
 create mode 100644 doc/internals/comment_16_2455c898d6c77a5437a2c1532144bb8a._comment
 create mode 100644 doc/internals/comment_17_df13b7e66963a6d2673e49f52afb978a._comment
 create mode 100644 doc/internals/comment_18_1adce7945940b9c384c2383261388dd9._comment
 create mode 100644 doc/internals/comment_1_4b8ed353dca4f484b3b6eb463fa02fd8._comment
 create mode 100644 doc/internals/comment_2_c19232d5cc4976c2e5b014aef6e8d9ec._comment
 create mode 100644 doc/internals/comment_3_5a26ee5aab274f321a4ea6f8527f53bd._comment
 create mode 100644 doc/internals/comment_4_81293b180fb09105ec158fdfef73d249._comment
 create mode 100644 doc/internals/comment_5_354012b6a9ac11160eb926234d38051f._comment
 create mode 100644 doc/internals/comment_7_7e40f744f9ac7f0403df9d1a2162a516._comment
 create mode 100644 doc/internals/comment_7_9c82a2878f3feb1b2a95662ed25b234b._comment
 create mode 100644 doc/internals/comment_8_9dccdd3a9556ceef54e318cd5c8a50ad._comment
 create mode 100644 doc/internals/comment_9_40442b012886ad698f448c262f0d7f4c._comment
 create mode 100644 doc/internals/hashing.mdwn
 create mode 100644 doc/internals/hashing/comment_1_9153e4f4f9335e524cf1b96a51bef41f._comment
 create mode 100644 doc/internals/hashing/comment_2_086ea37acf15e2a8694b8386222b73f6._comment
 create mode 100644 doc/internals/hashing/comment_3_19b7d20ca392078f14f9f10992f288ec._comment
 create mode 100644 doc/internals/hashing/comment_4_7642d6ce5fd4d37d464b05d0b4f869c6._comment
 create mode 100644 doc/internals/hashing/comment_5_b0cb207a85cda5a0ff2ea71caca22c0d._comment
 create mode 100644 doc/internals/hashing/comment_6_edb5c3388b5ac3481403c7accf9bb3f2._comment
 create mode 100644 doc/internals/hashing/comment_7_843592cf125be06fb316be43b85b0524._comment
 create mode 100644 doc/internals/key_format.mdwn
 create mode 100644 doc/internals/key_format/comment_1_4ec126bffafc81fae04e183874ffce39._comment
 create mode 100644 doc/internals/key_format/comment_2_1e46521ab48805c36233dbb69b11e389._comment
 create mode 100644 doc/internals/lockdown.mdwn
 create mode 100644 doc/internals/lockdown/comment_1_caa8b378e8c35177083e6cc2f6937180._comment
 create mode 100644 doc/internals/lockdown/comment_2_7bf74adb5556b7fc74a94e751c5fd3d6._comment
 create mode 100644 doc/internals/lockdown/comment_3_caf6d5318703d188a2135737093d8323._comment
 create mode 100644 doc/internals/lockdown/comment_4_0253bf642148ea853f6d1c8580e09db2._comment
 create mode 100644 doc/internals/lockdown/comment_5_3d7ab5c8e813b21812b5132c708aad68._comment
 create mode 100644 doc/internals/pointer_file.mdwn
 create mode 100644 doc/license.mdwn
 create mode 100644 doc/license/AGPL
 create mode 100644 doc/license/GPL
 create mode 100644 doc/links/key_concepts.mdwn
 create mode 100644 doc/links/other_stuff.mdwn
 create mode 100644 doc/links/the_details.mdwn
 create mode 100644 doc/location_tracking.mdwn
 create mode 100644 doc/logo-old-bw.svg
 create mode 100644 doc/logo-old.png
 create mode 100644 doc/logo-old.svg
 create mode 100644 doc/logo-old_small.png
 create mode 100644 doc/logo-with-cli.png
 create mode 100644 doc/logo-with-cli.svg
 create mode 100644 doc/logo.mdwn
 create mode 100644 doc/logo.svg
 create mode 100644 doc/logo_16x16.png
 create mode 100644 doc/logo_32x32.png
 create mode 100644 doc/logo_small.png
 create mode 100644 doc/meta.mdwn
 create mode 100644 doc/metadata.mdwn
 create mode 100644 doc/metadata/comment_1_d367fdaf0425b59d694bf16059d47192._comment
 create mode 100644 doc/metadata/comment_2_e15d2b5a405db4ccdb91d6aad4a22983._comment
 create mode 100644 doc/metadata/comment_3_50b17af1cf75ce88c4aef59dcd971b82._comment
 create mode 100644 doc/metadata/comment_4_237721c5e8f66f303a1828810573a23d._comment
 create mode 100644 doc/metadata/comment_5_fd30444aecfc4792eb4dbfdebc230786._comment
 create mode 100644 doc/news.mdwn
 create mode 100644 doc/news/2013_git-annex_user_survey.mdwn
 create mode 100644 doc/news/2015_git-annex_user_survey.mdwn
 create mode 100644 doc/news/2018_git-annex_user_survey.mdwn
 create mode 100644 doc/news/Distribits_meeting.mdwn
 create mode 100644 doc/news/Distribits_meeting/comment_1_774494da38afecc425aceca21d047b5e._comment
 create mode 100644 doc/news/Distribits_meeting/comment_2_bbdde32c4bd9c7a1a62450d59a1e879b._comment
 create mode 100644 doc/news/LWN_article.mdwn
 create mode 100644 doc/news/Presentation_at_FOSDEM.mdwn
 create mode 100644 doc/news/git-annex_shirts_now_available_at_hellotux.com.mdwn
 create mode 100644 doc/news/git_annex_fall_of_code.mdwn
 create mode 100644 doc/news/security_fix_release.mdwn
 create mode 100644 doc/news/sharebox_a_FUSE_filesystem_for_git-annex.mdwn
 create mode 100644 doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_1_e238d1734238e37bb55ff952b32e06b8._comment
 create mode 100644 doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_2_341b567722797eb02bd96ffada431b0c._comment
 create mode 100644 doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_3_d6f6e7181f30094339a49ab420bee380._comment
 create mode 100644 doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_4_ab0d45c5058595a71656035c962c1143._comment
 create mode 100644 doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_5_b92045c91d92da7db794aed2c67dde0d._comment
 create mode 100644 doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_6_6f3b5d5a5781b3a570f46481dc2ebca2._comment
 create mode 100644 doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_7_6202ae898f24b3e02bc343d0fd2ac35a._comment
 create mode 100644 doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_8_884a0b9571544a95fad55cb5fc5963d8._comment
 create mode 100644 doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_9_32b5d0fb9c328fbcd8105dfa31f032d3._comment
 create mode 100644 doc/news/version_10.20230926.mdwn
 create mode 100644 doc/news/version_10.20230926/comment_1_6edf64272975935ac4874d7e8dd44390._comment
 create mode 100644 doc/news/version_10.20230926/comment_2_b1bb446c48a4abc4df73354980f9f7cf._comment
 create mode 100644 doc/news/version_10.20231129.mdwn
 create mode 100644 doc/news/version_10.20231227.mdwn
 create mode 100644 doc/news/version_10.20240129.mdwn
 create mode 100644 doc/news/version_10.20240227.mdwn
 create mode 100644 doc/not.mdwn
 create mode 100644 doc/not/comment_10_d8fb9add7e98dadea2a39f8827f75447._comment
 create mode 100644 doc/not/comment_11_6c23aba5a9c341f2d5e2007e4b43f2ea._comment
 create mode 100644 doc/not/comment_12_a0ef1a045257659f0f8722e4987e0ccc._comment
 create mode 100644 doc/not/comment_13_c5c20576388f18daba3af913b44fb001._comment
 create mode 100644 doc/not/comment_14_837e3699014b73e8f2bd2a668eea9eef._comment
 create mode 100644 doc/not/comment_15_ac7396ca125abb80a42f9aaaf61a6ab4._comment
 create mode 100644 doc/not/comment_16_d2ae9613ad81508dbda6ed425d441ccb._comment
 create mode 100644 doc/not/comment_1_ab41bec1ccc884e71780cb9458439170._comment
 create mode 100644 doc/not/comment_2_0e19ff7deb5ed65f2bc685d4c516d816._comment
 create mode 100644 doc/not/comment_3_bab9584c41a25dda934ad230e3eb732d._comment
 create mode 100644 doc/not/comment_4_b2a0d5a45ab8ddd66c29dde9412d7a12._comment
 create mode 100644 doc/not/comment_5_f2829ecbe80a61aa9a8411d2403de69e._comment
 create mode 100644 doc/not/comment_6_547fc59b19ad66d7280c53a7f923ea08._comment
 create mode 100644 doc/not/comment_7_581e23cca0219711f8a4500a8d5d20fc._comment
 create mode 100644 doc/not/comment_8_5c61457f117de38ef487e5cc2780d554._comment
 create mode 100644 doc/not/comment_9_69aa47398a3c13ce64f146de985b727d._comment
 create mode 100644 doc/polls.mdwn
 create mode 100644 doc/polls/2013.mdwn
 create mode 100644 doc/preferred_content.mdwn
 create mode 100644 doc/preferred_content/comment_10_d9eb7d8efe731cbcdb456fc56935d886._comment
 create mode 100644 doc/preferred_content/comment_10_f0bce3c67f293eaba97b92f0942876b6._comment
 create mode 100644 doc/preferred_content/comment_11_fa7249ebbd7d5b499b486311c0a8f96d._comment
 create mode 100644 doc/preferred_content/comment_1_7d45e21dfb016e9ffa4715346dd0c1a6._comment
 create mode 100644 doc/preferred_content/comment_2_1ccd90b009245667ad59f4d29d2a3a37._comment
 create mode 100644 doc/preferred_content/comment_4_384025b5fa23a3f175985a081438149f._comment
 create mode 100644 doc/preferred_content/comment_4_6a9bc657bc7415f0e118357d8c6664c6._comment
 create mode 100644 doc/preferred_content/comment_5_f0a957e67297c4bb5a8778c11b3c9fd4._comment
 create mode 100644 doc/preferred_content/comment_6_b434c0e2aaa132020fd4a01551285376._comment
 create mode 100644 doc/preferred_content/comment_7_c4acaa237bf1a8512c5e8ea4cdbd11b9._comment
 create mode 100644 doc/preferred_content/comment_9_f82538be42428691d7cab60a7add2e74._comment
 create mode 100644 doc/preferred_content/standard_groups.mdwn
 create mode 100644 doc/preferred_content/standard_groups/comment_1_026e47e425d06c4b2580238b3187a379._comment
 create mode 100644 doc/preferred_content/standard_groups/comment_2_460bae34ba7c05357318a202b2932d25._comment
 create mode 100644 doc/preferred_content/standard_groups/comment_4_f5cd38886b58917fa3c417861fd10a10._comment
 create mode 100644 doc/preferred_content/standard_groups/comment_5_22434bd01b2b9ce62ddc9fb64b18f8b8._comment
 create mode 100644 doc/preferred_content/standard_groups/comment_5_9288dfe6b89885fe287db27cf941be64._comment
 create mode 100644 doc/preferred_content/standard_groups/comment_6_31fa43557e7585dec5dd105531b0fc10._comment
 create mode 100644 doc/preferred_content/standard_groups/comment_7_258ce07e607fa8eba80d142651393a95._comment
 create mode 100644 doc/preferred_content/standard_groups/comment_8_2d4737488451f1376500098919652808._comment
 create mode 100644 doc/privacy.mdwn
 create mode 100644 doc/profiling.mdwn
 create mode 100644 doc/profiling/comment_1_c1f99493f5e5c362d5c39f048280b11b._comment
 create mode 100644 doc/profiling/comment_2_f4d802a28b79905da0cb24af6cb65b0a._comment
 create mode 100644 doc/profiling/comment_3_1af4ac0d37c876912678522895c1656b._comment
 create mode 100644 doc/profiling/comment_4_1ca8d9765e6e3a18ae09df74bc390a00._comment
 create mode 100644 doc/profiling/comment_5_1ca8d9765e6e3a18ae09df74bc390a00._comment
 create mode 100644 doc/profiling/comment_6_ca4ac016a0fb0132fc5c746dfb6fefb3._comment
 create mode 100644 doc/profiling/comment_7_95f5afb616c7eba60473cdeb85a070b0._comment
 create mode 100644 doc/profiling/comment_8_951c1c047ef414268295626218474677._comment
 create mode 100644 doc/projects.mdwn
 create mode 100644 doc/projects/annextimelog.mdwn
 create mode 100644 doc/projects/dandi.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_1_6450f220a0d4252ceafdd82f0cc24486._comment
 create mode 100644 doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_2_f787daed9b02af18b81f033cc2f84d0b._comment
 create mode 100644 doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_3_a1aeed36b8317144bc5df6fe7bcfd488._comment
 create mode 100644 doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_4_a32f922bb12d6cfd96c5116b20cff828._comment
 create mode 100644 doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_5_fad1fe49c2c545aeeb388176d2f5a893._comment
 create mode 100644 doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_1_86b9cb50635c8ef8cf5918ab9a76d013._comment
 create mode 100644 doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_2_2a151ccc0d9ef464df1452adc6ca449a._comment
 create mode 100644 doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_3_1732be4c1d48acefcf3174cf8a7c8434._comment
 create mode 100644 doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_4_74e37e96d01bfb8b9521000d5faa7e53._comment
 create mode 100644 doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_5_1b87390e69204b42878930cc1614437e._comment
 create mode 100644 doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_1_aa0be7b60156b1b8a036081b36d120e0._comment
 create mode 100644 doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_2_0bbf38af3012493cee0ada5248f32525._comment
 create mode 100644 doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_3_d36533f093ced2a0fa5aa74de492b69f._comment
 create mode 100644 doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_4_7f8537172df5da79bdedd66bdc5cd231._comment
 create mode 100644 doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_5_1993718701b7ad180ec683f80c87003f._comment
 create mode 100644 doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_6_a84145c6537ac1a81db59cdc03bc625d._comment
 create mode 100644 doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_7_3fd3445beec2a6cc6e8c71bd8e90cc83._comment
 create mode 100644 doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_1_0c17cba36b1feddc956e0075f73536ed._comment
 create mode 100644 doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_2_33143a5f2467c58201496c8f59532b53._comment
 create mode 100644 doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_3_1241df23fa4861554cf9a5d65235c8a1._comment
 create mode 100644 doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_4_8c64d10dbfcd8189465affbf5329c63e._comment
 create mode 100644 doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks/comment_1_5d11bb90105b4d0cf14f85e6d8795023._comment
 create mode 100644 doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks/comment_2_f48e4d3571a8fc2b45fbaad7a9f8fb60._comment
 create mode 100644 doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks/comment_3_ff3bcc2cce6e0cbbeef10a187541f5d3._comment
 create mode 100644 doc/projects/dandi/bugs-done/git-lfs_remote_URL_is_not_recorded__63__.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/git-lfs_remote_URL_is_not_recorded__63__/comment_1_e2bcd52490fc04850738b72255692e32._comment
 create mode 100644 doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place/comment_1_d385d0fffdd6ac18f38828f805e4daff._comment
 create mode 100644 doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place/comment_2_0c6006b53f97515c1ed31d8d4ab464cc._comment
 create mode 100644 doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place/comment_3_300f74178ef17e2e549fd7a04a262428._comment
 create mode 100644 doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_1_182b9cc42f7287c8b022422404fc74b7._comment
 create mode 100644 doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_2_0baadee49b21451a99a38306a98e3e56._comment
 create mode 100644 doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_2_d51bb87dc5ed0f4ede808c5a9594240d._comment
 create mode 100644 doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_4_ea413a9dec0243688cbfcaf8a5998ac5._comment
 create mode 100644 doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_1_08af564539efb1b0d85905c0aa862c43._comment
 create mode 100644 doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_2_9a63b2918f5621efbfe8cdb33b23ff21._comment
 create mode 100644 doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_3_3df07b6c8ef25ad96ff4f198931347ad._comment
 create mode 100644 doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_4_051d22f0bd0eb601476cd3b74a9b98b8._comment
 create mode 100644 doc/projects/dandi/bugs-done/many___40__2x_jobs__63____41___sleeping__hash-object__processes__63__.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/many___40__2x_jobs__63____41___sleeping__hash-object__processes__63__/comment_1_c01d8d2e4aa2cb0d064ab223e615a75c._comment
 create mode 100644 doc/projects/dandi/bugs-done/metadata_cmd._vs._--json-error-messages.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/metadata_cmd._vs._--json-error-messages/comment_1_198df45c72d0c9b4997d1342ffb666ca._comment
 create mode 100644 doc/projects/dandi/bugs-done/move.log__58___openFile__58___resource_busy___40__file_is_locked__41__.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/move.log__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_1_14d5ba72397406620ac0a9fb05f2862d._comment
 create mode 100644 doc/projects/dandi/bugs-done/move.log__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_2_6216c1eb6991cec787333284463fcc9d._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_10_43f1eec4aa317ff3b1a4fc18def96c6f._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_11_f8a54670d8eaf00624e9b8f85e803864._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_12_5cdddca4ca03216b68d443eeb49af581._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_12_68a79183b04b99d4b00b363e3cbe3f3c._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_13_5c03731700b2a025755fb06c9a96f331._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_15_df08c2530b890544d5eb2df792c8fd4b._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_16_4b8a360c38dfa4c8d22e3a96fbace0e5._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_1_5dead4bf9fe9a9c7627843c91613caf5._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_2_49e075aaa89e60fe1d35513dd4d4d755._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_3_2a08321045a8ede5c3b5a690232020b3._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_4_ac9c166c2b0c3aad8391abb56654ecf2._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_5_7d339e9a04a7c303949523b235a046ec._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_6_48819ddcb8713087c78db8941e4c1151._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_7_3186ec45f20c4d768c7682e1d42fa24c._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_8_927028d040b0e24d772b667324b1a5e1._comment
 create mode 100644 doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_9_64ba2901154b629a9697b427f3ad92e2._comment
 create mode 100644 doc/projects/dandi/bugs-done/standalone_needs_more_depends_-_libgcc-s1__63__.mdwn
 create mode 100644 doc/projects/dandi/bugs-done/standalone_needs_more_depends_-_libgcc-s1__63__/comment_1_93f4c8f86c58da7988bf1550867f8945._comment
 create mode 100644 doc/projects/dandi/done.mdwn
 create mode 100644 doc/projects/dandi/potential.mdwn
 create mode 100644 doc/projects/datalad.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/--debug_is_not_in_effect_if_precedes_-c.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/--debug_is_not_in_effect_if_precedes_-c/comment_1_0f66414e629e31c2de868f8b7eeb7af5._comment
 create mode 100644 doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_1_3a2be0a1cd74c7dba3b07e1300ce2a30._comment
 create mode 100644 doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_2_1945040bcdf209b9a0faecd4a77e0f35._comment
 create mode 100644 doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_3_06dd9606225cf881f7681fc27fb4833d._comment
 create mode 100644 doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_4_0c6b8a3b0a6fbd700b3c8934bfec199f._comment
 create mode 100644 doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_4_c2f248745388b508337c5097baaa1979._comment
 create mode 100644 doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_1_22a1f4b025a6046e4d11f90590a6e4bd._comment
 create mode 100644 doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_2_71e985981c14780cc172a07beb0e9854._comment
 create mode 100644 doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_3_ac3fe75560c020015ecca615cf0e7abe._comment
 create mode 100644 doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_4_3bdf724f5e9203424b7cb5630fb49a46._comment
 create mode 100644 doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_5_46acb87752c0f0574d8f3b91fdfb1697._comment
 create mode 100644 doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_1_f78784304b46b77d334f74c827d0889b._comment
 create mode 100644 doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_2_62a5cc7cd6b8b06850fb32b76121ad82._comment
 create mode 100644 doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_3_f621e615a745910b4e28f91b27132c0e._comment
 create mode 100644 doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_4_43e5a90d6215b414f4e3357ea91af663._comment
 create mode 100644 doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_5_27b5669cecba4863ce296049804e82af._comment
 create mode 100644 doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_1_ea82bf47752807531870651653160f1c._comment
 create mode 100644 doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_2_27faf0663265bd3855e98f7f1f382bdd._comment
 create mode 100644 doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_3_37fb6d6361068f57c2068270ceb72ac0._comment
 create mode 100644 doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_4_4c3b233aa1c6b0b6c0b0d7519b5877a1._comment
 create mode 100644 doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_5_d1d23d3884fcbef3c8715ebdf8791f01._comment
 create mode 100644 doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_6_b713bf610c4f4d9c2463b61721bce406._comment
 create mode 100644 doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_1_c0a98d1391d4426182d3d43651ad67e5._comment
 create mode 100644 doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_2_952d0856b79cdf1637a84c74f396d9e8._comment
 create mode 100644 doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_3_ed02f45c96f7eedf2c15add673ca84f2._comment
 create mode 100644 doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_4_639337906e441523a610c7080f215aa8._comment
 create mode 100644 doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_4_746ffcf575f91bc3d156b279bcdf8ae2._comment
 create mode 100644 doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_4_e4f249bc78e870c91b3fcbf34596a9ed._comment
 create mode 100644 doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_7_a9b594ecd43c0d2f35029c934ba7e143._comment
 create mode 100644 doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_8_9fdcef0d78d04ce05765693fe296bb3d._comment
 create mode 100644 doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_1_138124e29ad5a27751fcd133e9dbf6df._comment
 create mode 100644 doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_2_4f68ed79045c93831cb8b41888057f29._comment
 create mode 100644 doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_3_72d271ac0612e13b3ceaf736e9e50fd9._comment
 create mode 100644 doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_4_69ae4b847873d039d790cd2b1cfa97c0._comment
 create mode 100644 doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_5_ca662cade7153349ce644cd93c379815._comment
 create mode 100644 doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_6_c75c9bcbcc8e68c60323dfde9c0248a7._comment
 create mode 100644 doc/projects/datalad/bugs-done/Build_failing_because_MonadFail_is_not_in_scope.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Build_failing_because_MonadFail_is_not_in_scope/comment_1_3ebe2e53fd8e8ce673267ac2715d964c._comment
 create mode 100644 doc/projects/datalad/bugs-done/Build_failing_on_Windows_since_ef3ab0769.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_0a9a9c44e.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_4b1b9d7a8.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_a706708d1.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_ddd7d1d11.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Change_to_annex.largefiles_leaves_repo_modified.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Change_to_annex.largefiles_leaves_repo_modified/comment_1_7cd205f8f5560420d117d5a2bde48532._comment
 create mode 100644 doc/projects/datalad/bugs-done/Change_to_annex.largefiles_leaves_repo_modified/comment_2_725d46358366ea79e375fd47beac6acd._comment
 create mode 100644 doc/projects/datalad/bugs-done/Deleted_files_not_considered_with_wanted__61____34__anything__34__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Deleted_files_not_considered_with_wanted__61____34__anything__34__/comment_1_03eebb6527c364552b8f81c12616e926._comment
 create mode 100644 doc/projects/datalad/bugs-done/Deleted_files_not_considered_with_wanted__61____34__anything__34__/comment_2_fded8e94841cb23a9d2715b00f63ae98._comment
 create mode 100644 doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_1_43cde828704e54cad344c066ba1e2821._comment
 create mode 100644 doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_2_f1d89a826b5a2847328f6eec36b9f452._comment
 create mode 100644 doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_3_38d687454c618c3321ad6d9b3c4e7a38._comment
 create mode 100644 doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_4_8f31a065f5f97285adeb3f9614c1f3c9._comment
 create mode 100644 doc/projects/datalad/bugs-done/FTBFS__58___Couldn__39__t_match_type___96__Annex.AnnexState__39___..._.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working/comment_1_e821d8666ace3a760a2a335220844b29._comment
 create mode 100644 doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working/comment_2_3cdbe5b9b7150f9ad9fd5d7af01b247b._comment
 create mode 100644 doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working/comment_3_1dcf8d6a37bec46a7e7c2d9a65becf28._comment
 create mode 100644 doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__/comment_1_e9f5fdf1078c87718fb6ca2559323b1e._comment
 create mode 100644 doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__/comment_2_5d0e1468f7ab2e8cd42452812d9ce49b._comment
 create mode 100644 doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__/comment_3_a9837edeacdf55c74d8fed2b8d7bf1f9._comment
 create mode 100644 doc/projects/datalad/bugs-done/JSON_results_for___96__export__96___have_file__58__null_property.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/JSON_results_for___96__export__96___have_file__58__null_property/comment_1_bf743f047b8063b8ecbd8c87d12fa475._comment
 create mode 100644 doc/projects/datalad/bugs-done/JSON_results_for___96__export__96___have_file__58__null_property/comment_2_d6e28d84238cb79c1df927da491f50db._comment
 create mode 100644 doc/projects/datalad/bugs-done/OSX__58___addurl_--batch_--json_spits_out_shortened_output_string__dies_off_with_4.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Patch_for_compilation_errors_on_Windows.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Patch_for_compilation_errors_on_Windows/comment_1_eb8d464da14af1fead372b4b61b20f17._comment
 create mode 100644 doc/projects/datalad/bugs-done/R__47__O_permissions_are_stalking_me_somehow.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/R__47__O_permissions_are_stalking_me_somehow/comment_1_9e4ba1e03a89c219c5e62280757311ba._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_10_d9dc3550012a618ba674119dd1163642._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_11_5dc1d7c54fc4768849d39affac51fcae._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_12_7cb4c4e1bc100e8f3241ece74ce463e3._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_13_a1bce716987b0d8d00a4a9aa07e9ac65._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_13_dd51471ec6a8f380663c62d6f9edb176._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_15_93e2dd2b30cdeddd5e273eae78a422e0._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_16_b2d1550e20e8c4cc07dbd0ebba64c603._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_1_5274e7f715ef060383046e8f5da08164._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_2_8976d014def1910f5140b1e5cdd37fb0._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_3_efccd6c930ea37f782cbd3b029f4fa71._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_4_282d1a5a2942820785b9cdacc1126545._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_5_34d7c2fb1b46f61e348a92f86a3d732c._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_6_279dfc4d611e2dbcb2523b9756f13a9d._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_7_815bf1b8985a49a0fafbcddc7c96f9d6._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_8_6f5e18dec962aba505ed15bed328f11f._comment
 create mode 100644 doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_9_bcc64259541b35eed34a63f4955884e5._comment
 create mode 100644 doc/projects/datalad/bugs-done/Repo_contains_invalid_Windows_paths_again.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_1_ce71734986fe4c86a43a5805628dd3de._comment
 create mode 100644 doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_2_8e7487f2f093e79dcce0be34274d7fa2._comment
 create mode 100644 doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_3_4ddca3bdc573ed3c7f6d846c4309ac2e._comment
 create mode 100644 doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_4_c480f7fad76759742bbdc4837d8c0c36._comment
 create mode 100644 doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_5_8a5b1e1cb4482fb787bde97a6066de59._comment
 create mode 100644 doc/projects/datalad/bugs-done/Some_calls_to_git_repeat_--config_values.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Submodule_deletion_not_synced_from_adjusted_branch.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Submodule_deletion_not_synced_from_adjusted_branch/comment_1_6473d7eceae5141e36c87156044b9d06._comment
 create mode 100644 doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_1_5b56b989145a8ef6a6203e4df38e2288._comment
 create mode 100644 doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_2_e37aaf6d440b6c2a7567b3df1c344ff7._comment
 create mode 100644 doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_3_9e1cc48bb2125cc8fd375e3ff2f3310f._comment
 create mode 100644 doc/projects/datalad/bugs-done/Syntax_error_in_comit_f29d49d47.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Tests_failing_on_Windows.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Tests_failing_on_Windows/comment_1_69e29a9c9b6690684ce1f4f8df3f3a2a._comment
 create mode 100644 doc/projects/datalad/bugs-done/Tests_failing_on_Windows/comment_2_e95cf7f151ba51fd4324dc212afd5467._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_10_5eb0622b326a8094b06f5f0de627e288._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_11_a3b5e2047185bbd3972ada07ddb79172._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_12_db64ae67b8aa974bd6d00aad005058ac._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_13_5f11262639d60ef63a44de09b191e0b6._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_14_cfab68df294195498fe71daa376e9f68._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_15_e42f03c3e880dcd71d57bc2f6292d95d._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_1_045f90b5693de55958c6ad1b825cbc9e._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_2_ead7e348547da0598a82be8d064c0c08._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_3_ff0746f08600fb9729b8e1773317a52d._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_4_598622df322c56da71320d1b15e0348f._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_5_9707d9dda7ebb2c94c71f1ea2f99064d._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_6_56c8ddb604b54b8a5cfd077225971582._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_7_6b2a763f3d07f0cdc035008638e08194._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_8_5aa63bf0d8e4145974702a86b36bd435._comment
 create mode 100644 doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_9_5a22839b8dc11965a879dd2654bd5d60._comment
 create mode 100644 doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_10_0598b1ccc9d7002d6b7fa08f29f8edc9._comment
 create mode 100644 doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_11_03ea7014854be4fa9f40a8815616b81d._comment
 create mode 100644 doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_1_e4b3597a6be74b10f03af3cdbc9ab4b2._comment
 create mode 100644 doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_2_aa11bebaa9ca341434fbc1382bbbbee4._comment
 create mode 100644 doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_3_22290ea94d5e547a199411d696657708._comment
 create mode 100644 doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_4_b6c36a9f466cbd0a09ae83ada7bc728c._comment
 create mode 100644 doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_5_201fb2f59e3143145f9f0b07a5f3ac30._comment
 create mode 100644 doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_6_e1051429a09bf5d7e5887d0eb378d72f._comment
 create mode 100644 doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_7_e50ed095c335c616b8e27fe20dae00d9._comment
 create mode 100644 doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_8_c1f5a71c217b965ece29fe8d9a01e6b2._comment
 create mode 100644 doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_9_b25f2c71675f4d8f6a6e22bb5cd98b23._comment
 create mode 100644 doc/projects/datalad/bugs-done/W__58__prop__95__relPathDirToFileAbs__95__basics_started_to_fail.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_1_ddf822288da76a16eaaade2da51c5b43._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_2_00fa93b8a064bd1e6ca6c35b1a10d5aa._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_3_26e80ddbcb3f0c149e6565552558f6c7._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_4_5f9a1e4468a4531a7676d1b749ba0b9e._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_10_4e3cec5a4ce33dadfd0ce7a8d17bfaa0._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_12_f1a92680ab7874aa0c102cbf4b8a445a._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_13_e38a372b6d9f498160369a9c3071939a._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_14_26472db382e75e03cf10c6e5770ef42b._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_15_94d2048dcd33712e08f2206a5182b23f._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_16_0a170534b266ca55afbfcfe191ff18fc._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_17_7db34973cb362bee271545c3c58690b4._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_18_2e8e840cabbc547ef758568bb2779f9a._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_19_c89853eca5c16e9dfa4a4acc982ab526._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_1_8623b98bf21427ae5734d74e2576af5b._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_20_281ded4caa0dd407431b205ce6746c05._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_21_cc08c222cc36e3a0462f370df12eb129._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_22_1c001d885bd4d7f60b3260d494406e5c._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_23_cedee281d3f6f97499e70dacd0560f70._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_2_80c5ec6993e8a720fbd1841fdd21e311._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_3_85f07d906b836ac968ab877258180c0c._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_4_0d2ab75208877136534040b726c7f97b._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_5_891b532bd662b1198351803b82ed634e._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_6_3947b44c88820da49d8a2d1afd3595ff._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_7_1c867ba26de03f921dd347c14b8ec402._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_8_4ee757b45706816c3296dd4b29f05fbf._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_8_b46545c78628379dd50d306c87550b9d._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_9_409a95cb01a4b26d46d7aaff042026a0._comment
 create mode 100644 doc/projects/datalad/bugs-done/Windows_build_failing_as_of_commit_cb7bb3e.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_10_61c1fe6f14a30082a325c0efea9632f6._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_11_541e257ea04d6a7647a337998d79232c._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_12_80b15bc4e0c8c9ed4680da9408c1d559._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_13_8f305fa196210899d2215324849a8fab._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_14_66d72d1d214124eaa57681df21b9b121._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_15_6354d1e144830bea5a0d7872f698ccc0._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_1_945d45b37b0548deacddab19568dd5b3._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_2_4e89c558748c370e8bbb1ef50f4cdcf7._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_3_1c0abfb39eafb73527c99dd56b41c0bd._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_4_ff06b532b0ec6edc17ae26a7a80233af._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_5_86eed28bf04fd293851afcbea5312271._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_6_71f5f1704b97cf4e809a55a71e9da3eb._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_7_78258166fed7a555e59ed2b78143fad1._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_8_1219295230f196c00744058ed3441a98._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_9_640a2685ca0efb7367da6bc502354735._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_10_755703a901687283f1a9b3bfcdf1ea68._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_11_539c272450ceb56badde88702afb4e4d._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_12_67567cf57d9b7d57fb5e10ff7a54a99f._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_13_a4643d9f91947714b6105ca81164cb26._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_14_41f1271bdc7a4d62b30f6254a0f6ffd6._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_15_0d6bfbc5539ef2083e0bc2e32762a9c0._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_16_6ef33d110d709e46768549c59b02841a._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_17_7c7b953b2366fbfc1b95cc6048473ddb._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_18_eb8b597167a6708a27ac03ef4fbf3632._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_19_9a1c92462a5393155298d70ef90d3019._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_1_c36b1968c69e9794c723ff29d1738759._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_20_e6ed93310ad694f6c52b52530c63f8f5._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_21_79ccde86a33f486b77857720d97185f3._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_22_4b6cf4221ff9d4f106d595f2897ea85f._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_23_503d0507c55412ca8c625b32feb7f80e._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_24_4345e2d7f30318dc7565e90ac8578086._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_2_5b1148d1d771b71f6af654f974dbf427._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_3_ac650ab647f5fda2623a958b30b40c18._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_4_af8d80956d3ccedfe9aeb0fe22b2592a._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_5_93cb28a06189d349a59d8d79c44d3b51._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_6_d76a32758b58695dcef7d4ec83abb1ea._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_7_40094333a89de09f7e64ca715ba20f16._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_7_4da389b802a114dc18e0264a4df36dee._comment
 create mode 100644 doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_9_c43d7b153cc8b68f31ea007922326ee8._comment
 create mode 100644 doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_1_a2d1112b0a9338b7c093546a985a5f90._comment
 create mode 100644 doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_2_c6e30af134a73bc8b3faee83c7c3b378._comment
 create mode 100644 doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_3_9ac6e3436ab4866993ebf4e469b13636._comment
 create mode 100644 doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_3_efe4490c33e874bd78fd567c70874088._comment
 create mode 100644 doc/projects/datalad/bugs-done/__39__git_annex_test__39___failures_introduced_by_75aab72d2.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/__39__init_--version__61__N__39___can_land_on_unsupported_N+1.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/__39__init_--version__61__N__39___can_land_on_unsupported_N+1/comment_1_c67521dc54f12efbbf7e13c828775e30._comment
 create mode 100644 doc/projects/datalad/bugs-done/__39__init_--version__61__N__39___can_land_on_unsupported_N+1/comment_2_d65fc129524c92fa1c783d8dbc516f5f._comment
 create mode 100644 doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_1_0bc5a3d36900d9bd8c978a08383d409d._comment
 create mode 100644 doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_2_ecc658185b485a5ccaf592ab8a255241._comment
 create mode 100644 doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_3_38baec012d7ebc95f92df59c85c6d525._comment
 create mode 100644 doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_4_ee9f695290b1bcaf2c9320d8042047cc._comment
 create mode 100644 doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_5_3fb410419608d725ea15a4849266396e._comment
 create mode 100644 doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_6_2455f440750a285768746e764fbfb9cd._comment
 create mode 100644 doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_7_c8f6ee2cb993b22b2531d1a4b7c3da8e._comment
 create mode 100644 doc/projects/datalad/bugs-done/add_--force-small_fails_on_modified_submodules.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/add_--force-small_fails_on_modified_submodules/comment_1_95e4a43684338e28a74b6df8d2e5281a._comment
 create mode 100644 doc/projects/datalad/bugs-done/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/addurl_--file__causes_file_redownload_even_if_it_already_present.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/annex-ssh-options_dropped_since_8.20200330.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/annex-ssh-options_dropped_since_8.20200330/comment_1_2ba303f406a0be7c3bb4a8466ce4b9c3._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex-ssh-options_dropped_since_8.20200330/comment_2_d3fdcfe9e75f2fa6a7c4d12e318455db._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_1_cc1417bb8173e3b2636d465967a704d9._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_2_60ab40449991dbb3f64d08f01c5458c4._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_3_86e8f44191a004da20db8e97577744a9._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_4_d6039a6d2df740600e98b50fe90fbdfb._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_add_ignores_.-prefixed_directories.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/annex_doesn__39__t_fixup_symlinks_when___34__git_commit_path__95__to__95__repo__34___is_used.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/annex_doesn__39__t_fixup_symlinks_when___34__git_commit_path__95__to__95__repo__34___is_used/comment_1_b90f22ce0ab931658856e949ac227985._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_drop_fails_to_determine_availability_on_a_http_url_redirecting_to_ftp.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_10_4b053c393627e2efb746a2b81838e518._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_11_e8ff5342533744617248104b04aa227f._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_12_7b5857e8415f386813b1b174e39e899f._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_13_552c0283748b64d84e84f5117f697d3b._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_14_7e3f849312d824cfbd10cce1f024c80b._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_15_666dcda30f5a34588c4357c3fa43e8d8._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_16_39227b7dc49d141556680980aa558318._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_17_c39c3b0978777987dcd8c86906aa6532._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_18_bffd59a35ae162f4141b6de7efcc7422._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_19_b3fc7c5f6acfa23b6bfd0f709d2f6b96._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_1_4916bb94a700e72d42302d2938693daa._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_20_3070880ace124795e07c4f8d1f47e81b._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_20_797c40af56ddb435db3d4affa86d49a2._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_22_35fbdb89eb658439e4125c22a04173a7._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_23_301141057296da0e01fcc622b4f14dcc._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_24_1c96a68c27ba09cd1f8c035dd026582b._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_25_d107200df348bc2b97e2fefc4342e49a._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_26_a3d803f25795365c9651d2ec023d9145._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_27_0f2e6c7dbfbb3007d4e3f7faa63d16b4._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_28_0812ef7942034a4ece952dd8069813a3._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_29_c18ec0797bd55780a0851c3b0c71b184._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_2_8d391bacf291492846d9253057653082._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_30_2bee4762be30b9864083ed1d32fe942e._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_3_6f228fa6770aad308d0f99647ac21347._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_4_3eaebe28f2925cac21a49f30aed3fa3c._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_5_c31884e8d52324c0e04cdbbee42d4d35._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_6_0707380cc043d9bbb84f0232eb1c1322._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_7_f7fd86a45b6d5440cdd0588ebb8753c8._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_8_7eee5a23aa67cb156aa31fe9fd92dd50._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_9_ee7333607930d8e3fbd4cca2b974c55b._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_10_1cbef11391d23210230872a75f8e5414._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_1_4de90238d57de0d49b75418411135dbc._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_2_5da78a05b781029fa7f0f9d8ead7e093._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_3_b279da2a2db1ba5a24a76a9112e691aa._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_4_089f1d2d7de435a98dc1098ebf1cf3df._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_5_3b840d50a1ecc9cb6e161e3c039fe332._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_6_2c83482ead69a902c99fca3ae63dfc34._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_7_51f6745c4abce7b3cdfcf1c5998f8329._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_7_d8ccfe3fe0d5123c1065ace73b623b44._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_9_df98c47016e79f15218880a009e671ea._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch/comment_1_4169fceac6ef95400ddc79652558dc13._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch/comment_2_c479f19eb55dce35364eea30d0b727b7._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch/comment_3_f694e35efa09aa60daf17d63270968af._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_sync___40__in_direct_mode_only__41___does_not_actually_update_local_branch__47__tree.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/annex_sync___40__in_direct_mode_only__41___does_not_actually_update_local_branch__47__tree/comment_1_6fb5a4fec435eccc0528744c55b7468c._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_1_9c91eef41c51737f85d4df3c737fc6c7._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_2_f6759af83ddd62293593a276e089188d._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_3_798629780fa04dc1a8bf1c21ca813d40._comment
 create mode 100644 doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_4_b7c2abf63c9f350402b3176e028bda03._comment
 create mode 100644 doc/projects/datalad/bugs-done/autoenable__61__true_seems_to_not_work_any_longer.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/autoenable__61__true_seems_to_not_work_any_longer/comment_1_457027471d09aa4ae8718c1508cfae1d._comment
 create mode 100644 doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_1_020c0c7a51638cf28efc518da4ccdb9d._comment
 create mode 100644 doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_2_0378843b9c7281d587304ac9c42d46f5._comment
 create mode 100644 doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_3_935f2fe1f7ff1a46b1038cd4458317a4._comment
 create mode 100644 doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_4_5bb365e15cd27002b0104d9eb9b5f28d._comment
 create mode 100644 doc/projects/datalad/bugs-done/awkward_error_from_annex_whenever_operating_on_a_clone_with_submodules.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/awkward_error_from_annex_whenever_operating_on_a_clone_with_submodules/comment_1_86b409dc4b7824f601deeed0a14cc8e4._comment
 create mode 100644 doc/projects/datalad/bugs-done/awkward_error_from_annex_whenever_operating_on_a_clone_with_submodules/comment_2_f5bf66e8494b4ee2c6da7f3a6de8da18._comment
 create mode 100644 doc/projects/datalad/bugs-done/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__/comment_1_a18cfae149effed2375b3b0be021ac3a._comment
 create mode 100644 doc/projects/datalad/bugs-done/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__/comment_2_08448687578634b6281ea285f18d87e7._comment
 create mode 100644 doc/projects/datalad/bugs-done/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test/comment_1_e9db58f71eedc99ccfd7a7a446843316._comment
 create mode 100644 doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_1_07ee2e1b3e0bf8959001c22273a71afe._comment
 create mode 100644 doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_2_ad34ddcf5bd0466b66eb1b93f65297fe._comment
 create mode 100644 doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_3_223df2a9cebd99a312537137863b1781._comment
 create mode 100644 doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_4_c78b91393ca917f9d231c39702c70e14._comment
 create mode 100644 doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_5_1bf2ff8d5ddbc8121ea69a5f4042f190._comment
 create mode 100644 doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_6_e12bd42ef9690d3bb74236d55da66bff._comment
 create mode 100644 doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_7_f0a3a944479e52a7789ff9a346001a6d._comment
 create mode 100644 doc/projects/datalad/bugs-done/cannot___34__install__34___standalone_git_annex_within_afs_mount.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_1_ad19d064dd9c175debe647a6928e4f35._comment
 create mode 100644 doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_2_19de1d89dd0a266ce43e0f25cd2b74cd._comment
 create mode 100644 doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_3_92b71940fe9d00bf58ee08b327f4a991._comment
 create mode 100644 doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_4_010b0b10ce6f9cd2b9a3f9847ff2a91a._comment
 create mode 100644 doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_4_8ab0f0852a1dc6c51a502f07faba61eb._comment
 create mode 100644 doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_6_7081b1386ca8807dff79e8613088b619._comment
 create mode 100644 doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_7_d987bcd1f589cd9f19a4df92461f9e1a._comment
 create mode 100644 doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_8_a9100e161d004729db9e3157fcb78343._comment
 create mode 100644 doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_9_220be99862a8a24263bd5f5f27988a1c._comment
 create mode 100644 doc/projects/datalad/bugs-done/case_where_using_pathspec_with_git-commit_leaves_s.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/case_where_using_pathspec_with_git-commit_leaves_s/comment_1_a71ce38ec25075ac7037550094da2bf7._comment
 create mode 100644 doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621/comment_1_ba8a5b590d2f690bcabeb63c0ef6f46c._comment
 create mode 100644 doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621/comment_2_28ea6b8a7addc23f2eaf5626705fc789._comment
 create mode 100644 doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621/comment_3_bd3faa20f746fcf4fd99a011b7453b38._comment
 create mode 100644 doc/projects/datalad/bugs-done/clash_of_-j__in_copy_for_--json_--json-progress.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_1_793ab4d52a3a4a3a30b0e72b72ac18eb._comment
 create mode 100644 doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_2_1c0e6f07f1da2872455401ac97c4ccc8._comment
 create mode 100644 doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_3_d064cceaaded97ce52169ca176959187._comment
 create mode 100644 doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_4_8209bed5e7c10f74b3ac17c368c92023._comment
 create mode 100644 doc/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output/comment_1_4ed0e29f0b599135b1b1c9197d58873b._comment
 create mode 100644 doc/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output/comment_2_cae2883d41b495a6722a7039f0ec2726._comment
 create mode 100644 doc/projects/datalad/bugs-done/could_standalone_copy_of_git_ship__47__deploy_hooks_samples_as_well_as_stock_git__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_10_b96755e44bedf262cbb32403f8edaf0b._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_11_9356da08c06aeae254fc84e44b0b3d14._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_12_918ed48f23dfdc1fc95e3df9526b489c._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_13_baafac7f80ff4b7cc4cf078e4ab969c3._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_1_ac112e35d792bdaeff268aae7ef0dc6a._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e1c7bd12aba40c6d9e9c039fa0de8631._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e524de262247edc4c541ce3af92c48e0._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_4_1e0f10f694f7d07c0ab75136daec669c._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_5_bc9b8c1b80a3308c997fdccbf8465f08._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_6_21e8b47c5f100196f3d2062001a484d8._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_7_36f796f2ed8cd91716ee5a083e5a5ace._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_8_0d34bfeab48421e35c6880bca639cbb2._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_9_d0d441c94af2fe63ed1b20fb031181a3._comment
 create mode 100644 doc/projects/datalad/bugs-done/crippledfs__58___annex-init_crash_when_remote_name_is.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/diffdriver_does_not_workout_on_unlocked_file__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/diffdriver_does_not_workout_on_unlocked_file__63__/comment_1_f5f0bb494672fb6b959c2a72a042467d._comment
 create mode 100644 doc/projects/datalad/bugs-done/does_not_complain__47__fail_if_by_mistake_option_value_passed_within_arg_for__-c.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_1_ef17dd348b2404000c29e7b41f1e5253._comment
 create mode 100644 doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_2_51a060d64f2dead1aa030596b0b34bc8._comment
 create mode 100644 doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_3_6c79c41676318bd976eff9988463d167._comment
 create mode 100644 doc/projects/datalad/bugs-done/dropkey_--batch_--json_--force_is_always_succesfull.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/duplicate_progress_reports_in_parallel___39__get__39__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_10_1a3d3ade491f97e68a7bfcd853062875._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_11_d53e63d817a71ae88580c5b08ce28956._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_12_435c4cad7d3837aa09292642b983f041._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_13_afc2af08abebba808886464fbcd0b9d7._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_14_a532adc63a5ad97ab37a0a775cda0d0e._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_15_ba2420e2d8f41dbdafc839246b8362aa._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_16_8768afda308d5afeee2002f53f5cbf2c._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_17_06103ccf5423718b35d35d6b2e4f04d2._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_1_e47d2cae9fa224bef2433eba4d21ec7e._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_2_de71be6bdc853567ad52a05c591b3bb5._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_3_36b91cb600c0a14dedd58e91e97132d5._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_4_2a15295f0a6f907d684ca5a7134619ac._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_5_e7a571699a2e564bb8364e353d9a1245._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_6_362351708d543f1d219dfcf8d71b5a14._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_7_1fbf8751d378f4e838e7f5ba6b43a6ca._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_8_03d750b6461b965b33e1e4bed1242658._comment
 create mode 100644 doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_8_3f8ca763326523a79184192332107879._comment
 create mode 100644 doc/projects/datalad/bugs-done/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__/comment_1_a3111068628efcfe8c5dbbe653805481._comment
 create mode 100644 doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata/comment_1_d027727bb0063e82ef9f92c8558e191d._comment
 create mode 100644 doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata/comment_2_e7d11326148bf27a0233d36e26e08e6a._comment
 create mode 100644 doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata/comment_3_3ef1310132adf09cd426e49c93503a88._comment
 create mode 100644 doc/projects/datalad/bugs-done/error_message_in_addurl_is_not_channeled_into_json_record_with_--json-error-messages.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/export_-J_6__to_S3__58___transfer_already_in_progress.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/export_-J_6__to_S3__58___transfer_already_in_progress/comment_1_f81e00b5293f2df894dc3cd1678530c1._comment
 create mode 100644 doc/projects/datalad/bugs-done/export_-J_6__to_S3__58___transfer_already_in_progress/comment_2_0efd2da2e467c0607d1903ada98a3f20._comment
 create mode 100644 doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_1_fcf8372714c74e5001b5a18c7100c7a1._comment
 create mode 100644 doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_2_1fb916ff03e0b8c96c554caf1558ecab._comment
 create mode 100644 doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_3_18d4577c331bceceaffed7518902975a._comment
 create mode 100644 doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_3_d949841feb6a035e20a3d0f31634d388._comment
 create mode 100644 doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_1_917b46d9ca69c4e8181d041d5414d373._comment
 create mode 100644 doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_2_363c4a87018de7be3286d88d0d5f8ebf._comment
 create mode 100644 doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_3_1fd43cf6dd14f50ef8087f0b22ad640f._comment
 create mode 100644 doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_4_4a4d5b62af4a42ab9072ccaa6d8bed7d._comment
 create mode 100644 doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_5_6c1e74df4c7e566c4c1ba43fbbbd3beb._comment
 create mode 100644 doc/projects/datalad/bugs-done/fails_to_verify_presence_via_http_while_wget_fetches_it_just_fine.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/fails_to_verify_presence_via_http_while_wget_fetches_it_just_fine/comment_1_fa6649208f1882a6bb412ba40cf57fec._comment
 create mode 100644 doc/projects/datalad/bugs-done/find_--batch_reports_files_that_have_no_content.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_1_d0dcd56a0af59bb53092c518a4e3eefd._comment
 create mode 100644 doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_2_3f1980c96f795c30886b3decba69819d._comment
 create mode 100644 doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_3_5299bafc9ae75788d2e7e9aa7f48d00e._comment
 create mode 100644 doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_3_b68abf3a46bf0137c02e439c58ce0014._comment
 create mode 100644 doc/projects/datalad/bugs-done/fresh_test_fails_for___34__trust__58____34___-_trust_failed_.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/fromkey__58___create_directories_for_pointer_files__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_1_1d627cb46d9ecdf0b526a9c8e9764011._comment
 create mode 100644 doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_2_eb7c6445b1ca53d5552506d8ae93b5d4._comment
 create mode 100644 doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_3_c7d43b06f88d2000fcf574ebab971ae1._comment
 create mode 100644 doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_4_9d7c83cfb6154bdfc51caae00da4c4b7._comment
 create mode 100644 doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_5_09bb754f4e7e19cd52d68f91368f57fc._comment
 create mode 100644 doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_6_3cba6bde1e5c1e978519672bf4c2d33f._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_--json_fails_whenever_plain_get_works___40__with_https_urls__41__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/get_--json_fails_whenever_plain_get_works___40__with_https_urls__41__/comment_1_a9aee679a5069dc8ee8960e975bf020b._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_--json_fails_whenever_plain_get_works___40__with_https_urls__41__/comment_2_f1e97aa8b9927c01e3365b940061d3c2._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist/comment_1_83448258af56b5872a9530cf60c72eb0._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist/comment_2_92dec3e0c31ffbef1a70ea3038ba6ca1._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist/comment_3_ab590b41983d84c8fe7d5dc7276689b8._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J8_resource_exhausted.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_10_61622483d4f1962f191fb6a791c6817d._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_11_ccc6f5f1ac5743b0857f68cf21eaa6ea._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_1_5f9e9600d65c1270b479cc8910d507d0._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_2_54cf519a09cfaa0c85d60734daf58d72._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_3_132ea480f90af577e3cad67f2f01c73d._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_4_06e99c29eaa770ab96ea5fd832ee04b8._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_5_0e7b492da14e067c34693b7be02e6864._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_5_db1ae584fc803c0dbb48c7e31a540c4e._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_7_f584dc15789b371569e1925c4ee5ae36._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_8_83eccac19016c971f1b799d935a4c0bb._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_9_5db907d77c5f5490c1bdc8e51387a9e9._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_1_57844bc289adacc6a53162cd224e6df3._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_2_ea5d3efc56b70de03a5b0b5e908bf11f._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_3_ed5fa01a2263ebb4a24bfe0e46ee820f._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_4_5964e40963325975e5de37506a2852ca._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_5_64705f2eddbb6fcb55edc797bbd3b22c._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_6_e51841ae57dd9d2f48cd21fbdb90ac29._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_7_2f7f87db7ca4d379d439ab88bdeee5b5._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_8_36bcdc23439c4f19c5aaedff85213db0._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_9_7ce83c16509bd42b2460ce59470f70c0._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_1_5b3879d1bb992ddf2aafa3fcb41b968f._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_2_af7078b291d99569070f6a76579787aa._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_3_86e1be495262a7f57428e92eb27a559f._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_4_3428942e9b52091b2297cd9823f17219._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_5_525ac8695b6253fc435112f336238c41._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_6_5f2ed95bcad2e3d1c4260d1fb0440052._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_1_236d2b897a550e7db4b266814d4e778d._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_2_c877de08f959dee4ace34e66f42c8615._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_3_daac1d424bc9e5b56772fa49707bc5a5._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_4_05bf20db275b911e2d89311182f289f6._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_5_b094509fe0194313666b5b1db0a68156._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_6_f5fe8d4cecfceec5cb4a03dd054d2e0a._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_7_0118a107147f6b94a7da907e599e58db._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_8_5da63cf5fa93120c85b98077fba51488._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J_from_ssh_remote_tries_to_lock_in_home_directory__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/get_-J_from_ssh_remote_tries_to_lock_in_home_directory__63__/comment_1_362a858ce78fa0b8d7949fb39fb247d9._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_-J_from_ssh_remote_tries_to_lock_in_home_directory__63__/comment_2_3f985fc652c9a15b5989cc82cb5da1ad._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_fails___40__only_in_--debug__41___with_rsync_error.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/get_fails___40__only_in_--debug__41___with_rsync_error/comment_1_d30e7f8eecfb73f2f97ec87285966f21._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_fails___40__only_in_--debug__41___with_rsync_error/comment_2_6ec6e02bfb94b27b8da1ed68e4f9f121._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_from_the_web_remote_fails___40__redirect__63____41___-_lack_of_further_debug_info.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_1_dee4b1e8c5cc15a5d362df3b97a886a8._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_2_16bf63e639626f5dfedd6f3809216747._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_3_3b3dc5b946e405955b68b0c4c3d7df3d._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_4_91cdb022987aa3a8852a82ace092a929._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_4_b2c7517a7482071111514a68c70ce8dc._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_6_76433ca072233f8cd24600d3e45f97c5._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_7_21dbdbf7e4e889dc7c2475a0b9d4c5d7._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_10_dd7883772bb37fa85aa1332633184071._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_11_375e6d23c43a2cc0ef8bb81b06c3bcc9._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_1_032dfcb0dc7e5c54a0cbc6634ad77268._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_2_1c079d165831b790676dc6bec0549773._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_3_d83330ad40f4f2c2c55f29acf6680620._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_4_129a1946d7c76b89ae2f45b8a804959f._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_4_1713d56b81db533db4532f2a79250c87._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_5_a14f999b63905c1f29999bd68ded42f2._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_7_31ecf1c31511e6454a274e3c9a9bef75._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_8_3aecc3467427b4ebecbd53012e111004._comment
 create mode 100644 doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_9_dfb1b7ee4e674cf18d6f41e4f4b6c879._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_10_d44de6a250694b25ce9c3169d62db8d1._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_11_56ae0f15bbdea2331df3b261b74d0b0b._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_12_d499a2f44e8ee2f39ee959f4d6373570._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_13_05687dca2462eb79872879bd7695d665._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_14_cb1df663b03f3ce9cb27e311e5a70198._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_1_a98a54c04fa4e81f35fe958e746d61cb._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_2_18169e7bbd2caba5ee4bb0286961ac95._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_3_e3b623ff6714a9fe5fa0d332c72fe32f._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_4_58eebd8cfd664b32ef6fd0ddc34c5e86._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_5_e5e24428ac02b78d38cd4f197ae3807b._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_6_01dc7a1ff67783ce672d72cefe7b4bb5._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_7_458518805b8d6613930b38b9ccc3c1bc._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_8_853bc273b19bd6d84ca8f5da6c3dfb56._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_9_86656a409ab25c7fa24de8ac3e68b254._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_1_88439da4b9df6e07aa0300700b66d910._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_2_020d7c6292c2a8238a5ec891fba9eddd._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_3_f533ffdb2b37f98094fc7633cd686e5c._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_4_301ac4a37a0f2da6b9c394509a369484._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_5_f2a25cca5d72ce1dcecf36c2780abec2._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_6_b8f96a403990a125bf181f0ce8bea44e._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_7_2899ef72aa2a5488eb945d14f7a2d76e._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex_looses_itself_on_Windows__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/git-annex_looses_itself_on_Windows__63__/comment_1_e809445ff0109d8aa98093b024b3b35c._comment
 create mode 100644 doc/projects/datalad/bugs-done/git-annex_no_longer_provides_remote_name_with_GETCONFIG_name.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/git-annex_no_longer_provides_remote_name_with_GETCONFIG_name/comment_1_005fd5bb4e8a025f1b15c7bf5f22d2c5._comment
 create mode 100644 doc/projects/datalad/bugs-done/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__/comment_1_6c595bec40f6bf470e9170c8ae4bb573._comment
 create mode 100644 doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__/comment_2_4c2e143b8b3283734963e0a6e68755ac._comment
 create mode 100644 doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__/comment_3_dac1401bd3661397a9388a5b6ce673a5._comment
 create mode 100644 doc/projects/datalad/bugs-done/graft__47__graft_cleanup_commits_--_really_needed__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/graft__47__graft_cleanup_commits_--_really_needed__63__/comment_1_7bc271ddeafc92d36d2b90fcb1481891._comment
 create mode 100644 doc/projects/datalad/bugs-done/graft__47__graft_cleanup_commits_--_really_needed__63__/comment_2_d0a7283aac4f3c231e20ab284a1f2253._comment
 create mode 100644 doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_1_447c9cf5e9e137238fb2c662a54ee2d7._comment
 create mode 100644 doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_2_8432a49e6af69efbfcb4d615e147f873._comment
 create mode 100644 doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_3_f66844b716e48c5befbe99346e940962._comment
 create mode 100644 doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_4_e90ba33f7506745582d18841ae9a9531._comment
 create mode 100644 doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_5_098b2e2c51f70d495fe1587220173f55._comment
 create mode 100644 doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_6_306afca0827aabc092fd99e56a5b658c._comment
 create mode 100644 doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_7_987b2c1de4638e01c4f4feb028d47b88._comment
 create mode 100644 doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_8_d0d8a729badb551bb8d0f77e7104c159._comment
 create mode 100644 doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_9_7159b17d64ee147822969d79d5a1c48c._comment
 create mode 100644 doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/comment_1_833cf2db9881a401a3d5db6d4f3c450a._comment
 create mode 100644 doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/comment_2_ae3d42be1a15dda2cfe97c99248ceacb._comment
 create mode 100644 doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/comment_3_bea29c2596ddcc7f8cd7f02ff7bfd9ef._comment
 create mode 100644 doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_1_a5824d9099dc4035e09086166b13f133._comment
 create mode 100644 doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_2_fceb64e98fb7566f7cb999e9b37914f5._comment
 create mode 100644 doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_3_49b8cf8de638190b3b29ffdca3fe0bdd._comment
 create mode 100644 doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_4_dc940fed174b32dfdb4b4ff8c10529f0._comment
 create mode 100644 doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_5_c76fddc3aab4d3580c79f105c97d6998._comment
 create mode 100644 doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_1_8b60c52d8fe41718377d6d15a25cae97._comment
 create mode 100644 doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_2_066d2f95ffab1b36b69aa84643d67765._comment
 create mode 100644 doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_3_05f7eec04634e5b4e200cf3dca1bb1b1._comment
 create mode 100644 doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_4_705616c61fe7a0779df3794fa8a1d6dc._comment
 create mode 100644 doc/projects/datalad/bugs-done/inconsistent_output_upon_addurl_--batch_complicates_if_not_forbids_reliable_parsing_of_output.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/info_--json_lists_backend_usage_stats_as_a_list_of_lists.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/init__58___syntax_warnings_in_diff_driver_on_Windows.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/init__58___syntax_warnings_in_diff_driver_on_Windows/comment_1_65fda26959f82d1f3d110e72d7aaec9a._comment
 create mode 100644 doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_1_54456b2ce0964933db23257149b5a651._comment
 create mode 100644 doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_2_23398e5403c3a9f40d3b544139ee9915._comment
 create mode 100644 doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_3_7fd5d3decc2d6b40d6d2f2d7e6dcabdd._comment
 create mode 100644 doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_4_307e7328ca24ff386e0dd734b9ff103e._comment
 create mode 100644 doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_5_e9800d53c4f88d1555aad2e0e945b40b._comment
 create mode 100644 doc/projects/datalad/bugs-done/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout/comment_1_fc8fa8020a9e542d90dd459799d6ec6e._comment
 create mode 100644 doc/projects/datalad/bugs-done/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout/comment_2_dac0fc9914eff0e187d4cfe3c21348bc._comment
 create mode 100644 doc/projects/datalad/bugs-done/man_page_for_command_misses_actual_command_in_the_synopsis_for_git-annex-checkpresentkey.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_10_d2242b526c7cce1084bbb63ef2bfe06a._comment
 create mode 100644 doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_1_c3fbb6eb15a510ae9b1af13cd7df028a._comment
 create mode 100644 doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_2_c33bf0bdf6bf85e4ee9e1286208c0b73._comment
 create mode 100644 doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_3_4c957c33a1c8dc179e0e6cd67a5a29d9._comment
 create mode 100644 doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_4_497bbe4e351a66731c920ca5a2048c92._comment
 create mode 100644 doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_5_53c317adf0ef48d9ba4af0571f9ded3f._comment
 create mode 100644 doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_6_7fac2098e6d7cce997a540592e20c97a._comment
 create mode 100644 doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_7_05e4e6936d7b87cb21e312a7aa1731eb._comment
 create mode 100644 doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_8_ccb6c9756a2fcf75be8049d89731a5bf._comment
 create mode 100644 doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_9_49cda6f52fa4fb527b392f6ee6bae078._comment
 create mode 100644 doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb/comment_1_5a7d8371910b27a82e479bdf3bb63d8f._comment
 create mode 100644 doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb/comment_2_bdc4f86afd827beb20b3d888d96aefe9._comment
 create mode 100644 doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb/comment_2_d3c6aa8c91630d4bb40b3267bfdebfbf._comment
 create mode 100644 doc/projects/datalad/bugs-done/mysterious_dependency_of_git_annex_status_output_of_the_added_file.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/mysterious_dependency_of_git_annex_status_output_of_the_added_file/comment_1_4d7eb95c73eceb079a176db1957df25e._comment
 create mode 100644 doc/projects/datalad/bugs-done/mysterious_dependency_of_git_annex_status_output_of_the_added_file/comment_2_ef55541955a6a8840a63309aa403ecae._comment
 create mode 100644 doc/projects/datalad/bugs-done/new_whereis_--json_lost_information_about_web_urls_if_other_special_remotes_provide_them.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__/comment_1_ac192db19137f8b65a13a2c3f7f454a9._comment
 create mode 100644 doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__/comment_2_88d08c4b269c075e0724fa1bce70f671._comment
 create mode 100644 doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__/comment_3_28060f4bb31730e3334cf3db56fc032b._comment
 create mode 100644 doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_10_53714ec51d6ae4769f6c4dd9ee46ebae._comment
 create mode 100644 doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_1_44965e93c65148f06bf4fe4cad95993c._comment
 create mode 100644 doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_2_4a704f47a709a9de35358d6d2fb9fe20._comment
 create mode 100644 doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_3_fea65a7f0218ccf27446ee7ce6fc017e._comment
 create mode 100644 doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_4_c2d4485b2a49ada5ab5266e30df91b0b._comment
 create mode 100644 doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_5_94d4cc9baf46fbc09c21abd08b441b0c._comment
 create mode 100644 doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_6_db5de257e8cfb468bf31d46065b7d251._comment
 create mode 100644 doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_7_644826ed86849eb4babf37bea3937a7c._comment
 create mode 100644 doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_8_dd50ae03bc9a71e04528ac793e79a8b2._comment
 create mode 100644 doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_9_552e36f88bc39bc68b65ccba06002082._comment
 create mode 100644 doc/projects/datalad/bugs-done/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_1_a7ad806ceb76f13ff8fdcce62bc0ed8a._comment
 create mode 100644 doc/projects/datalad/bugs-done/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_2_495820d777c889f88466d725c11895f9._comment
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_1_1173126bd91dcb7fd13c57f06fd16c2b._comment
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_2_2ba8101ed0e91df7079744d1b37779fd._comment
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_3_6674e4dbc7437ce941bcef6272c3433b._comment
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_4_480df575c68bfb37b8bb4fb43737726f._comment
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_5_03e474b00b1cb2a5b8244d9161857b9b._comment
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_1_46420a92dbd8655af9b16349da24d0fc._comment
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_2_b1f4dc12ad00a4aa73e5bdc7c0a8f489._comment
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_3_d8ba7cc5a860e9ccaab32c637cc2a7cd._comment
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_4_eecaa7f7b0279c56902c90ed58d1444f._comment
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_5_052acf169f9c2b8b0233adddabb02559._comment
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_6_880c962d5ca77c494c984e7f74725265._comment
 create mode 100644 doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_6_e33df0ec76069deb069b94c944d62c76._comment
 create mode 100644 doc/projects/datalad/bugs-done/prematurely___40__can__39__t_check_offline__41___marks_remote_as_annex-ignore.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_1_9222f76d21e8260327b4f127cc90782d._comment
 create mode 100644 doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_2_9e694fdee4a40581a86d21b962f99f25._comment
 create mode 100644 doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_3_79626c62d4ce8be2524f9ef3a1351363._comment
 create mode 100644 doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_4_40d710dd89b305a64ff8df5d238778e8._comment
 create mode 100644 doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_1_9b101babc7cb9e697a6195366d4a0a67._comment
 create mode 100644 doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_2_9bfcb8386d5589623423f4d3f040df3c._comment
 create mode 100644 doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_3_704ecfd2888a8153eaa5e4a8e6e3d011._comment
 create mode 100644 doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_4_3291fcd5100fda8d41fb8714cec15b30._comment
 create mode 100644 doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_5_adb69305a31cf55ff62497b6de8e2f6a._comment
 create mode 100644 doc/projects/datalad/bugs-done/prop__95__isomorphic__95__key__95__encode_fails_with_external_backend_changes.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/prop__95__isomorphic__95__key__95__encode_fails_with_external_backend_changes/comment_1_7f23940cfa4451e4cd7137e2d7a46d86._comment
 create mode 100644 doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__/comment_1_23bf4756af808d1b2cf89f7da119031f._comment
 create mode 100644 doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__/comment_2_63d3ff9c10ef530d318653bfadccab22._comment
 create mode 100644 doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__/comment_3_e8432845460fd0598f8fea5d00c70993._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression_-_fails_to_drop_._Exit_code_11_wo_--debug__44___and_1_with_--debug.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/regression_-_fails_to_drop_._Exit_code_11_wo_--debug__44___and_1_with_--debug/comment_1_3c2578d17ce519f80aa278a546df29cf._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_1_56cd6e167c86f4419ac0971922f2e5d1._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_2_1cebe1385d2b8a244afc259a78f72ada._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_2_ca0bf1079acc89a4a79e55f8f58403c0._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_4_f05e1047c5d22dddba21a9faa3397f0d._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_5_811ba6ec07f6f30c701201178cdb00ac._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_6_2cd156baab77dc3b3c248a2368b59040._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_7_9f3f7c04524063960f1451c90948a41f._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_8_55b111079ecb9732a42d3486160e77b5._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___annex_add_of_moved_file_errors_out.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___fails_to___39__add_.__39___if_file_was_renamed.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___fails_to___39__add_.__39___if_file_was_renamed/comment_1_bd132d7cfa21b2ea3236b76dffaff156._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___fails_to___39__add_.__39___if_file_was_renamed/comment_2_bceb84ed261a160c4041c146372fc551._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_1_7f25fd487c60f8b6fcaddd1444d898af._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_2_92c7a561537e0c6628f30be233b9d7f6._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_3_621beade26a1dbbdea000ca43d93a325._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_4_3b19a1d3e0e13e407af476b54b725bd1._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_5_0655ad5ece1ccd1892ea217aac493594._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_6_9dce3bf28e416dbcc08b314dbc08c8a4._comment
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___standalone_build_is_deficient_on_linux_after_7.20190819+git2-g908476a9b-1__126__ndall+1_some_time.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/regression__58___standalone_build_is_deficient_on_linux_after_7.20190819+git2-g908476a9b-1__126__ndall+1_some_time/comment_1_1735409e62ce82f7ba7258b0167fda06._comment
 create mode 100644 doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi/comment_1_10590563da0f80fa8326a90977966509._comment
 create mode 100644 doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi/comment_2_1b9b2ebc78949c7b39a255c291d11891._comment
 create mode 100644 doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi/comment_3_0ec752dbe8ef55a9884c1c5e83887505._comment
 create mode 100644 doc/projects/datalad/bugs-done/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/reports_success_when_addurl_--batch__a_file_which_is_.gitignore__39__d.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/return_--backend_for_addurl___63___.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/running_tests_on_NFS_HOME_does_not_exit_cleanly__58___gpgtmp.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/running_tests_on_NFS_HOME_does_not_exit_cleanly__58___gpgtmp/comment_1_84a2d253843903f9811652b78d0fa7ba._comment
 create mode 100644 doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_1_cd7043b66977b2a668bbd52f4d8e31ff._comment
 create mode 100644 doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_2_e5b43f5733181fba9f79ae0035b354ef._comment
 create mode 100644 doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_3_10d6135ad4b0c9706ff7b932323118d3._comment
 create mode 100644 doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_4_fda77062452ac619a23298007bc0148a._comment
 create mode 100644 doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_5_fa6d5d0afdc00824da0e04d9bf23d6f4._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_10_2e61ccc41839b8da70ad26d31e40ad74._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_11_e9af4784ffb84b49b6faaa21aa7c8efc._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_12_fc10e403f35f47a6c4464f3f68d01eca._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_13_43a09de767ed9060dd91d6eca5e0b3a3._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_1_df04a6bd62a60789d8a59cce4b62728e._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_2_0619eec44cddf3d3b1aae27c7bd1389a._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_3_aae8dd8b3b0ce4647ec2d30e1d682339._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_4_c72e6646e39cc487ea52cd17925a548f._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_5_d8c8b725ee91a899a131bf505bd9a2e3._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_6_d0d8065b78c22e62ef780c27e4d5952c._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_7_a82064795fdbdb0187763aeee4a308ff._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_8_c3d447a8f4e63f6a28a02ccb4eed1ad4._comment
 create mode 100644 doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_9_f74642e1dfc4e533b9582e5a13a16898._comment
 create mode 100644 doc/projects/datalad/bugs-done/should_not_assume_entire_name_to_be_an_extension__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/shouldn__39__t_keep_permissions_of_the_ssh_remote__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/shouldn__39__t_keep_permissions_of_the_ssh_remote__63__/comment_1_35eeb15c0031c18ba6d0922bb7ae8ed3._comment
 create mode 100644 doc/projects/datalad/bugs-done/shouldn__39__t_keep_permissions_of_the_ssh_remote__63__/comment_2_65232a9c2bbba075d325ce00b7c5e13f._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_10_37d5186dfa2da31526c4eafbbbfdbc33._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_11_51a3a86a290b0e3994507f3f64e7c72a._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_12_c841c9db2000c65c56ce8e26e58a3f62._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_13_f6bec279f43603719694e44d99309fc7._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_14_4d2998ea843dd8adee8b7b066d97d942._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_15_c9488d6180e741dfec0793f546c9eb29._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_16_65aaf8e15cd15187cd63863634f25091._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_17_045fd8ebe1f9441e42c9c6fbf5c06563._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_17_8df0e346ed85e52ec94763d11c174ab3._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_18_3e57d7d4640de95a059b2ab3d1e9d54e._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_19_80372cd15a6a8812072a446c41fed4e7._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_1_3eb1b092f41dc5c04d74f7a03249aa0f._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_21_0119751108d8d9fe6848269594bec273._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_22_192f2055345f1156a06d93b4c25e6722._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_23_8693e7e9c800f25cbd274b6781d834d6._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_24_6d11f6aa4b1a435bdf6d165eb8e6db8a._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_25_5525b58ec94084a926c71f749d1f4233._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_26_cb64b1798af6ad507ce4a4196e9c5b1d._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_27_db91e10d0bea246686ba2241b348e67d._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_28_0d6a37f823cd9cb3ed1e6e90066ebd2c._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_29_0f3c8949ae362b43ac7db02eb4e11890._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_2_521f784d686fcaeb5e081599fbdf9903._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_30_386c0cfe688effb1543ffd01a54717e0._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_31_97fa9b7729805704a6a22cf18082e203._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_32_0ab5e774dad1e6e74a5c72b95e40d659._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_33_6e5121e066998a303cf68ebc53e9fc15._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_34_86d07025980e0b50d1a52f73c049944a._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_35_d3437076c759eedc0c8d5d15db035455._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_36_25fa8b726e06dc69e3a0d9ed675da1d1._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_3_d30a515103d04fd966aadee7f141aeee._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_4_4011786784a140442dd7ecd1cefe559b._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_4_85d1031d2b51c0fc1271c283d8ee7888._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_5_b0f1e94e96cf8fe992425cf81f8d1105._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_7_35217e61ccf6936e105df8de7e1775d0._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_8_29bde900ef625702b49cf020118f940f._comment
 create mode 100644 doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_9_431582f1c218f27e50849df1444dc845._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_1_4123b5b93a220c1ba46126a5d97b6ff9._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_2_7d37b8d79fcb6a0edd99e0bd6f2b0515._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_3_7ec51c8996c7cc4b555313e84634e406._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_4_7bd5a28d5ba1eefd5a96483b5f00a89e._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_5_3c407c1924e21aa1ec300875680dc3b3._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_6_58997665e5aa0a237a3ec90efca92891._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_test__40__s__63____41___regularly_fail_starting_recently.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/some_test__40__s__63____41___regularly_fail_starting_recently/comment_1_d4c417df9a8e6c13c06ccfc21853de02._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_test__40__s__63____41___regularly_fail_starting_recently/comment_2_16a96277aecccfa32cd918ac662ce6f8._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_tests_fail_while_running_under_NFS.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/some_tests_fail_while_running_under_NFS/comment_1_8e0f72f633ec79bd373b009046ab66b7._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_tests_fail_while_running_under_NFS/comment_2_ee9cc13cf34432be00a906bf65cebafd._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_1_b762aa4a31f2153c00988d185ce5efbe._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_2_7d5c57bf17659769d9cf4d56774ba67e._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_3_8a5ceb261338ab55b5c8c2daa56d04ce._comment
 create mode 100644 doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_4_bedf66f7257511d1d245ff0c6bcfe5f6._comment
 create mode 100644 doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__/comment_1_9909507b034e25db04e5407717fab315._comment
 create mode 100644 doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__/comment_2_a254c4de61a74bf314eb33e301c199f0._comment
 create mode 100644 doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__/comment_3_89e9d65073a58188024290a2b32fda2e._comment
 create mode 100644 doc/projects/datalad/bugs-done/standalone_build_is_slightly_out_of_date.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/standalone_build_is_slightly_out_of_date/comment_1_349f2d8f6ef0fddcfe576fc08b3cccb6._comment
 create mode 100644 doc/projects/datalad/bugs-done/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_1_343ac13424b0b65db2094c595bcabd7f._comment
 create mode 100644 doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_2_c43bb7ffa7b900f5824b4495a6a82d0e._comment
 create mode 100644 doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_3_57681d5959095d9a3e6ea9e4d0679c85._comment
 create mode 100644 doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_4_5c2c6003b45d78b9e0bee95f5a12c48c._comment
 create mode 100644 doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_5_57834ef04f206e1b351b36ba32ce447f._comment
 create mode 100644 doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_6_9ee31c8d92178b38bbc920df395ee284._comment
 create mode 100644 doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_7_2abc6e368033bc636debbcd83dd2b4ed._comment
 create mode 100644 doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_1_ab8017246c0075b731c7d31235672c01._comment
 create mode 100644 doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_2_2b7afff24ba025fe3e272ff6f607eadf._comment
 create mode 100644 doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_3_ba1b34111d47d58517ea64f537214e98._comment
 create mode 100644 doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_4_297b462c0344b8c7e5e113fdda3642f4._comment
 create mode 100644 doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_1_7e089c436af03ffd8ad00dba45156a14._comment
 create mode 100644 doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_2_07f7881be6b0d29cdf64a7839b669b3e._comment
 create mode 100644 doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_3_c570246b0484ed3694efff62feff968c._comment
 create mode 100644 doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_4_2f701f39286c3a75a88407dcc6947081._comment
 create mode 100644 doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_5_096b3af691987ef20281c87519a31935._comment
 create mode 100644 doc/projects/datalad/bugs-done/strips___95___from_extensions_in_E_backends__63__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/test_fail_on_windows__58___permission_denied_.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/test_fail_on_windows__58___permission_denied_/comment_1_9f46a99e5f570de2313a5521b58640b3._comment
 create mode 100644 doc/projects/datalad/bugs-done/testremote_breeds_way_too_many_instances_of_the_externals_remote.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/testremote_breeds_way_too_many_instances_of_the_externals_remote/comment_1_6c4afa18ad31f46ff8c0b827415373e4._comment
 create mode 100644 doc/projects/datalad/bugs-done/testremote_breeds_way_too_many_instances_of_the_externals_remote/comment_2_daa09ac406dea6cd3ab74fe19d89d956._comment
 create mode 100644 doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_1_d779827a6cc3d3d7bb6edfa410170e09._comment
 create mode 100644 doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_2_4cfb0979773618a0bc18d52bf0f274e4._comment
 create mode 100644 doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_2_d53b98bca623d4d25bab58563e7577b3._comment
 create mode 100644 doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_4_a80f9277eb6f6c49710d5008bc2c2c42._comment
 create mode 100644 doc/projects/datalad/bugs-done/testremote_with_external_remote_hangs_after_asyncexternal_merge.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/testremote_with_external_remote_hangs_after_asyncexternal_merge/comment_1_854aecbc440dc3a5aa15f9de5f36c9e8._comment
 create mode 100644 doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_1_d36c27dca4d266d1e6639e3435198016._comment
 create mode 100644 doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_2_c61b14b76cf06c0b10257c1a84d9478a._comment
 create mode 100644 doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_3_ea210a22073919be434884f006212e6a._comment
 create mode 100644 doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_4_0cfd7d0d93d0747d42d20f13b788fe43._comment
 create mode 100644 doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_5_944a4474401b2fa0b4f3631bac63a07d._comment
 create mode 100644 doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_5_fa8c65c2223d2be21aa95e5889c1f352._comment
 create mode 100644 doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_6_d358bf55d89f5d0609d792a26757d0f4._comment
 create mode 100644 doc/projects/datalad/bugs-done/tests_fail_on_Linux_build.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/tests_fail_on_Linux_build/comment_1_9932a7c60bb369fbffba52092e03bce3._comment
 create mode 100644 doc/projects/datalad/bugs-done/tests_fail_on_Linux_build/comment_2_c042d95b58500933e5932176037ead8f._comment
 create mode 100644 doc/projects/datalad/bugs-done/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_10_2562d33a1cafb01b2cddb9a42a635616._comment
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_1_8b4fd2331ff62c984f91a9536a3a7e2b._comment
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_2_3889b10d60b007de72b3af87e920e74e._comment
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_3_a4f9bb23f0682a66e951b96aed6ae214._comment
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_4_1b01ff1b092976af137bdfc2c9e28fba._comment
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_5_9e4b82d27ddbb42d74f10a85635590e7._comment
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_6_11cb8251521014ef81b53090f5c78376._comment
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_7_ba7e53135285dbf198f5aa12d7edc1cd._comment
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_8_95ff27c621afe43abfd7403f343b612c._comment
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_9_b70343f8cb81807a7da0da5637d8c750._comment
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why/comment_1_87983a598cacaa8800db4a01ec23ba1b._comment
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why/comment_2_b9e5b868dd5379de18ed77907d1b42a3._comment
 create mode 100644 doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why/comment_3_667c5b94580e2ca0305d4ed97c2e199f._comment
 create mode 100644 doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_1_08514c489b916b2ae8e4e0122051856f._comment
 create mode 100644 doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_2_1ae05c24612f50cfe03e2569b332a522._comment
 create mode 100644 doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_3_ae81a2ac4b2167d48c8a447811a492a2._comment
 create mode 100644 doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_4_c49e48ea12ed0a0edb675b532279a5a8._comment
 create mode 100644 doc/projects/datalad/bugs-done/upgrade___40__from_v5__41___fails_without_stating_any_reason__47__hints.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/using_regular_magic_file__warning_pollutes_stderr.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_1_1c86937cee067b5980852fcb066b0bfb._comment
 create mode 100644 doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_2_bd552525b7bb2ceaad72c8fa3bf41c6b._comment
 create mode 100644 doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_3_8cfa8fe790ff2586374f46ed10cc8fbe._comment
 create mode 100644 doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_4_40e9a5b641200c92725df31a654b6a05._comment
 create mode 100644 doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_5_eaafc970cce2c71ce29f136c90e04504._comment
 create mode 100644 doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_1_d530fb679b76e995c466fe17c3aab830._comment
 create mode 100644 doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_2_dcc764525370338fbf9b6f2728e3e5ac._comment
 create mode 100644 doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_3_7c9fc177fcb76b76765cece36b4f939e._comment
 create mode 100644 doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_4_981d6d42f411476d1a5e38d987af6035._comment
 create mode 100644 doc/projects/datalad/bugs-done/wanted_on_read-only_repo_crashes_.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/wanted_started_to_dump_debug_output_to_stdout_.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/whereis_shouldn__39__t_just_crash_if_one_of_the_special_remotes___34__drivers__34___is_not_available.mdwn
 create mode 100644 doc/projects/datalad/bugs-done/whereis_shouldn__39__t_just_crash_if_one_of_the_special_remotes___34__drivers__34___is_not_available/comment_1_3f8100a4d9e6ab4302c89eeafd0f843e._comment
 create mode 100644 doc/projects/datalad/done.mdwn
 create mode 100644 doc/projects/datalad/potential.mdwn
 create mode 100644 doc/projects/neurohub.mdwn
 create mode 100644 doc/projects/openneuro.mdwn
 create mode 100644 doc/projects/repronim.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d/comment_1_244e138f7621c901dd7763159db84677._comment
 create mode 100644 doc/projects/repronim/bugs-done/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d/comment_2_cbdfb3dea5c125b52d53811b96b3e01e._comment
 create mode 100644 doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_1_ddd60096d409a820358d5a57a3a449c9._comment
 create mode 100644 doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_2_b496a4967b6bcc0a4e1cc55e06ba90c8._comment
 create mode 100644 doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_3_bdadf679a2f82c2a1cae747d437add85._comment
 create mode 100644 doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_4_90bc2857c83afae250834135a5884898._comment
 create mode 100644 doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_5_d29518fef1b3b0b8937e078f9303d41c._comment
 create mode 100644 doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_6_24eca56dc972ecff0b553e93b7c649c4._comment
 create mode 100644 doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_7_3adce9695e4e3786f0c68b092d8f6400._comment
 create mode 100644 doc/projects/repronim/bugs-done/Please_include_version_of_used_to_build_ghc_within___34__git_annex_version__34__.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/Regression_in___96__find_--json__96___output.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/Regression_in___96__find_--json__96___output/comment_1_034f772098dfb9d3622c6f84976e69a2._comment
 create mode 100644 doc/projects/repronim/bugs-done/Unable_to_get__47__addurl_to_http_link__58___download_failed__58___InvalidHeader___34__preload__34__.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/Unable_to_get__47__addurl_to_http_link__58___download_failed__58___InvalidHeader___34__preload__34__/comment_1_247f3c1dfea3cdb0b398c015f4c4d44b._comment
 create mode 100644 doc/projects/repronim/bugs-done/add_--json_should_provide_a___34__note__34___with_an_error_message_in_case_of_an_error.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/add_--json_should_provide_a___34__note__34___with_an_error_message_in_case_of_an_error/comment_1_636a375fbd8cf8573b3806d7a815b59f._comment
 create mode 100644 doc/projects/repronim/bugs-done/add_--json_should_provide_a___34__note__34___with_an_error_message_in_case_of_an_error/comment_2_50d096934badd3e59756939b5c418bcb._comment
 create mode 100644 doc/projects/repronim/bugs-done/addurl_fails_with_non-youtube_url_with___34__This_url_is_supported_by_youtube-dl__44___but_youtube-dl_could_potentially_access_any_address__34__.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_1_eb415152db43c02e4d474dade4a1faca._comment
 create mode 100644 doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_2_c51d386f294529d6ebe7058438577ffe._comment
 create mode 100644 doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_3_6edae77c6ee7e4c4f94f9c0daff375ad._comment
 create mode 100644 doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_4_d92a7f2bc72b27c74cd86811c9bbf098._comment
 create mode 100644 doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_5_0dd1d4e6cd16da2865c3153b61b9e282._comment
 create mode 100644 doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_6_539039e237d9b0db0c97f64d877de7f7._comment
 create mode 100644 doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_1_130f2600057aa5b648f7798c49b4ea60._comment
 create mode 100644 doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_2_802f85441c42ac079b6ecaea39a63c81._comment
 create mode 100644 doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_3_4d03d12bfba811e0a67551e10201200b._comment
 create mode 100644 doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_4_1ea0f89c3c9e8bf1142b2c234cdf90c3._comment
 create mode 100644 doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_5_72c67ef575c90071040cf5347d81ce01._comment
 create mode 100644 doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_6_dcfb1dfb33a690a73547a5855e0ee55d._comment
 create mode 100644 doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_1_10045d7efa652ded4c41fd8c3e089bf4._comment
 create mode 100644 doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_2_6d57bda8ddc603f24e16018969ac780a._comment
 create mode 100644 doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_3_1a982c19fc7360a2a231b5a23142bbba._comment
 create mode 100644 doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_4_397686077b5a63196204327c178a7064._comment
 create mode 100644 doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_5_b95c1da49c3a4eecca8038c03a46c709._comment
 create mode 100644 doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_6_d2f9a37824dd2bb49892430f9f271f1c._comment
 create mode 100644 doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_1_ec7aa500a826beb813bc5313af9aa983._comment
 create mode 100644 doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_2_a61ed5b8f438caf0b8c7a53e08e1986a._comment
 create mode 100644 doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_3_09343b67a0c6e82203b76ef591233869._comment
 create mode 100644 doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_4_8be6e27e081d4bc8c0fa178088a10a91._comment
 create mode 100644 doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_5_b08d8859f873fcbdc78f938042fe0fbd._comment
 create mode 100644 doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_6_357f297d1afab22a59b2bafe4b85facd._comment
 create mode 100644 doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_7_2181d91c9b5b374c6102fdcc227349fc._comment
 create mode 100644 doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD/comment_1_a377e26b2eb75956c9de9beed0534cc2._comment
 create mode 100644 doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD/comment_2_d1ae8ccbfc3a9dd90cc03e68d5a78071._comment
 create mode 100644 doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD/comment_3_cd7cc008c3d37caa76416bd2452da90d._comment
 create mode 100644 doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_1_25dd2f0ba99913f26cbcbf55352bb1ab._comment
 create mode 100644 doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_2_f5e21a674c54c5dc4c8474ce1b4ffaf1._comment
 create mode 100644 doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_3_028eca36967a89e5f479802499232a90._comment
 create mode 100644 doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_4_6657ceac22df80251b74c6e4b47f8ba0._comment
 create mode 100644 doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_5_96f485e38778448804ae253f9032babc._comment
 create mode 100644 doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_6_0e3ae1862408b6d0c5e0acd9e9fa20b5._comment
 create mode 100644 doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_7_7fcb97b7d7f26fb6964a574ba1c8cd20._comment
 create mode 100644 doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_8_ba2dd3b91147e2979bc90a022f6e0252._comment
 create mode 100644 doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_9_fe629ccb023c2564dbf78402d92bef66._comment
 create mode 100644 doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_10_d258114e6e8f8db28b65a39cb13f2a04._comment
 create mode 100644 doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_11_adc040aad7d339e22fef76a2cbc4a312._comment
 create mode 100644 doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_1_e07a5dd0abb2049b4bb0bf26fa2ebab5._comment
 create mode 100644 doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_2_419de3fe25c490b251b8a6a7a9b24ed6._comment
 create mode 100644 doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_3_2bb944b19503dcf90fdf55e5098a2c02._comment
 create mode 100644 doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_4_a8847e219a57f3cf41330745e6a67b10._comment
 create mode 100644 doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_5_4e7be0dd1eb70af4790e2bcba7bb6ea1._comment
 create mode 100644 doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_6_d12ddfb48706454eba1bd552a681e5ba._comment
 create mode 100644 doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_7_d897d97bfe8f13431f8c5d92e61bbd3d._comment
 create mode 100644 doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_8_b3f282a0a0d4c5f174cf6831dbf3014c._comment
 create mode 100644 doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_9_230038504d75704baacd4d3ac750ee95._comment
 create mode 100644 doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_1_0351276d5eeb5d8af0cf0e72c3a213fd._comment
 create mode 100644 doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_2_a8565fb1657318092a22e8ed18ae6cbc._comment
 create mode 100644 doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_3_d3a478e3f7da91ab14c9b1e24d3e07d6._comment
 create mode 100644 doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_4_9add6c8e1d5b722eaeb2e5a0fe67cd32._comment
 create mode 100644 doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_5_b411b96c73bba30557c2f3aa9d6077e7._comment
 create mode 100644 doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_5_e3a79f9480a7123feb924f3c1e72ce62._comment
 create mode 100644 doc/projects/repronim/bugs-done/initial_get_-J_on_exported_S3_bucket_fails.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/initial_get_-J_on_exported_S3_bucket_fails/comment_1_005874771ab14efb94c4a739da31b523._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_10_d2a5b1eb72cf0abbd0143339ff81a92a._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_11_5ee016343b74fac9d6235db88744734a._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_12_c640da31be6bcd50dec6eabb2e792e07._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_13_4bb69f0bc73b5d368cc9278b88223a5e._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_14_2d8cf0d8b020941d143abd424729c6bc._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_14_7cc13b150c19a3c08f2b9cdeb880cfe9._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_16_9d1f902cc0e029b483115c3c0de5d113._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_17_0e4efb1686564f4d8e834b1e0843d397._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_18_01371e8b9d56d4470af5277456763d12._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_19_a171911a9bb7a278e673e4b6905c971d._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_1_ffcede72f600ecc98b906f0d9b6d6d0a._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_20_2b76e74756e684a09387396fa2177d57._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_21_8f7fd9bc58d8c2eff32f5fa200b57119._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_22_0827ffb4beb55f6553a40c722bc2ec12._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_23_c9102fdb9d99d2c19585e74b0dc0dff7._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_23_d69e0931e520391551eb4c37eb2f809d._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_25_115c584098501e16292dc6c776141074._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_25_1adec4fa4c8af5409d2f5dc7adcaecf4._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_27_e8b00ab555e94cf8826493ca6ce2d082._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_28_2fb1c54c41b31698909594106cb08cd4._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_29_750dbe3e118b1b6b8d0cca7d26ea1366._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_2_50c0db38a664adbb0c5a2290326195a6._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_30_cd1362901ff08323ca134fc8de914318._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_31_e2cc841198c91709980cc2b2a8297925._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_32_eff60d2ee47af65f18dede31cc283adb._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_33_3338f896a983292bef576dcd369bba5a._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_33_fe7e5c3340282f89c3393d8c5a2bc17c._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_35_296739c184ac8d0cc453aeeeff5b6f74._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_36_75f52900d12931b4c6172e10401f28d3._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_3_eea08486fa9669bd197eb9e957b65ef8._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_4_817a9d27a0b15798671f4dc5cd661164._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_4_c2df4fa0420c0db31b38e65a8d7dbf92._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_5_288741ae44f2dddbe53ab1dc294e2fb7._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_7_44d25c37e26e71b2aff759a0d39c5803._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_8_24ab22004dd25169bb9191a92f1e0ac4._comment
 create mode 100644 doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_9_c8a52578b5d7482683443bd5d95a5265._comment
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_1_82a71d4e9656c83e2d50143cb8a31602._comment
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_2_9bd5f0acb9761dcf59ecd38092e3e14d._comment
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_3_6d2fceb790e675cb73b193bf67f7a6f4._comment
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_4_bf6487c1740f163745b7dcc41468ec4d._comment
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_1_5184c1b87e249f203541f610278ed08e._comment
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_2_860458173cb4d745e8c9833b804398d8._comment
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_3_921d2493f51ecb61b711773238c9f7e7._comment
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_4_b15837921956ad166cf53a5dd23cb7dd._comment
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_5_2a66b890e3c60d1102acb7cef0b86308._comment
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_6_c42192a94651f34d32f6d5b91b1c09e8._comment
 create mode 100644 doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_7_11f4424d3b9fb6c54fa510320affac73._comment
 create mode 100644 doc/projects/repronim/bugs-done/rmurl_marks_url_not_available_in_wrong_remote.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/rmurl_marks_url_not_available_in_wrong_remote/comment_1_2aa17a7067a183f5837b5a41d74fcde9._comment
 create mode 100644 doc/projects/repronim/bugs-done/windows__58___autostart_for_annex_64bit_looks_under_x86.mdwn
 create mode 100644 doc/projects/repronim/bugs-done/windows__58___autostart_for_annex_64bit_looks_under_x86/comment_1_b8a4128b08ef8dd25a8141b27531b9ae._comment
 create mode 100644 doc/projects/repronim/bugs-done/windows__58___autostart_for_annex_64bit_looks_under_x86/comment_2_0f23c377b22788d9c540bd480398f47b._comment
 create mode 100644 doc/projects/repronim/done.mdwn
 create mode 100644 doc/publicrepos.mdwn
 create mode 100644 doc/related_software.mdwn
 create mode 100644 doc/repomap.png
 create mode 100644 doc/required_content.mdwn
 create mode 100644 doc/required_content/comment_1_b9576aaa31258e9bdf18a4eac8d61bfb._comment
 create mode 100644 doc/required_content/comment_2_d475f4afc84a58afe7af6d492de3ebe5._comment
 create mode 100644 doc/scalability.mdwn
 create mode 100644 doc/scalability/comment_1_a6656ae397277719d67d0953a28fe1d8._comment
 create mode 100644 doc/scalability/comment_2_71c7c3aa97284602d0f64c11a98d1782._comment
 create mode 100644 doc/security.mdwn
 create mode 100644 doc/security/CVE-2014-6274.mdwn
 create mode 100644 doc/security/CVE-2017-12976.mdwn
 create mode 100644 doc/security/CVE-2018-10857_and_CVE-2018-10859.mdwn
 create mode 100644 doc/security/checksum_exposure_to_encrypted_special_remotes.mdwn
 create mode 100644 doc/security/comment_1_285da453a385bd4bd225e26377a47cd5._comment
 create mode 100644 doc/security/comment_2_261b1904e41f4566490b977010ce8734._comment
 create mode 100644 doc/security/comment_3_0cc44e032fc94f4d374fb297ca9a8f2d._comment
 create mode 100644 doc/security/comment_4_3822244fb9becc32385d57233fa036a4._comment
 create mode 100644 doc/security/comment_5_616b08553430a64beab196571c5b9cdc._comment
 create mode 100644 doc/shortcuts.mdwn
 create mode 100644 doc/sidebar.mdwn
 create mode 100644 doc/sitemap.mdwn
 create mode 100644 doc/special_remotes.mdwn
 create mode 100644 doc/special_remotes/S3.mdwn
 create mode 100644 doc/special_remotes/S3/comment_10_c366f020c9b97a365e21878a33360079._comment
 create mode 100644 doc/special_remotes/S3/comment_11_c1da387e082d91feec13dde91ccb111a._comment
 create mode 100644 doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment
 create mode 100644 doc/special_remotes/S3/comment_13_0789a21d980825188bb09f7fc8bba8be._comment
 create mode 100644 doc/special_remotes/S3/comment_14_29574a51d5831c51e2e765eb2c06e567._comment
 create mode 100644 doc/special_remotes/S3/comment_15_ceb9048c743135f6beca57a23505f0a3._comment
 create mode 100644 doc/special_remotes/S3/comment_16_7b79f8b5ef88a2775d61b5ac5774d3e0._comment
 create mode 100644 doc/special_remotes/S3/comment_17_52d3510016c099d083553f9b3fa40db9._comment
 create mode 100644 doc/special_remotes/S3/comment_18_0dcb84048563fc9e45b66ca8f365f320._comment
 create mode 100644 doc/special_remotes/S3/comment_19_9d0d622b6202698f09eb06c097579fbb._comment
 create mode 100644 doc/special_remotes/S3/comment_1_4a1f7a230dad6caa84831685b236fd73._comment
 create mode 100644 doc/special_remotes/S3/comment_20_ce4ce50d51675ee4746a2528d4bea750._comment
 create mode 100644 doc/special_remotes/S3/comment_21_26cbfd805dd45a80121f5e2079afba37._comment
 create mode 100644 doc/special_remotes/S3/comment_22_55a7e513713285b8ced84c8cfd525364._comment
 create mode 100644 doc/special_remotes/S3/comment_23_b503ce70a4f008be580a069420361686._comment
 create mode 100644 doc/special_remotes/S3/comment_24_b209474b90befc79a7139d6c5703e2d8._comment
 create mode 100644 doc/special_remotes/S3/comment_25_29f2760e433a0e6229e46e728c380275._comment
 create mode 100644 doc/special_remotes/S3/comment_26_6b99242a6a681a1848041a8b8875743d._comment
 create mode 100644 doc/special_remotes/S3/comment_28_163d81443ca5a05138e6f570b068ac6e._comment
 create mode 100644 doc/special_remotes/S3/comment_28_c4dafad82a898eafd6d9e3703fad2c48._comment
 create mode 100644 doc/special_remotes/S3/comment_29_37430a66a9f39a635b32f04ff82db194._comment
 create mode 100644 doc/special_remotes/S3/comment_2_5b22d67de946f4d34a4a3c7449d32988._comment
 create mode 100644 doc/special_remotes/S3/comment_30_db7e1e3506cf7a912cf88ffe4caea20b._comment
 create mode 100644 doc/special_remotes/S3/comment_31_e46934941fca2de536f3705185098b6e._comment
 create mode 100644 doc/special_remotes/S3/comment_32_197d0c6d632c201a4ea9680653895c07._comment
 create mode 100644 doc/special_remotes/S3/comment_33_36788d742259b3b078e02d7b2a251ce5._comment
 create mode 100644 doc/special_remotes/S3/comment_34_cf57e8dbd9fdc7c487565b61808b6bb2._comment
 create mode 100644 doc/special_remotes/S3/comment_35_a141196a77d77cc6e130185dbf01e48b._comment
 create mode 100644 doc/special_remotes/S3/comment_36_9c900d777c9add9c277d40bd5b32bdf6._comment
 create mode 100644 doc/special_remotes/S3/comment_37_fef35384191078ed9ac6ee819eea4aa7._comment
 create mode 100644 doc/special_remotes/S3/comment_38_03ba1dcf23e04b8c54b53b10a93e1c45._comment
 create mode 100644 doc/special_remotes/S3/comment_3_bcab2bd0f168954243aa9bcc9671bd94._comment
 create mode 100644 doc/special_remotes/S3/comment_4_38c0b062997fde1ad28facc05d973e83._comment
 create mode 100644 doc/special_remotes/S3/comment_5_409bc2b56382417cf26bb222fb783ba7._comment
 create mode 100644 doc/special_remotes/S3/comment_6_78da9e233882ec0908962882ea8c4056._comment
 create mode 100644 doc/special_remotes/S3/comment_7_6af9781004d982d8e6b20a83ad29eead._comment
 create mode 100644 doc/special_remotes/S3/comment_8_0fa68d584ee7f6b5c9058fba7e911a11._comment
 create mode 100644 doc/special_remotes/S3/comment_9_7ad757b3865b04967c79af0a263bb3b0._comment
 create mode 100644 doc/special_remotes/adb.mdwn
 create mode 100644 doc/special_remotes/adb/comment_1_df47283c499cddd1d92a262679514531._comment
 create mode 100644 doc/special_remotes/adb/comment_2_f1f6c0a6f8c34c3d205988d2f69693ea._comment
 create mode 100644 doc/special_remotes/adb/comment_3_1d08d2ded354328461e9a7288287779e._comment
 create mode 100644 doc/special_remotes/adb/comment_4_9f5edeb544f6a26e9278410ef67e99ba._comment
 create mode 100644 doc/special_remotes/adb/comment_5_c9a3427bc8e924cd1f50246b3ec7c081._comment
 create mode 100644 doc/special_remotes/adb/comment_7_73ea2ada02df871b0c9795a5b769f7db._comment
 create mode 100644 doc/special_remotes/bittorrent.mdwn
 create mode 100644 doc/special_remotes/bittorrent/comment_1_4ef590d88bacd763abd5ce209e6b9640._comment
 create mode 100644 doc/special_remotes/bittorrent/comment_2_bccc7409111e4df4f4aab3b21fa4d321._comment
 create mode 100644 doc/special_remotes/bittorrent/comment_3_1e2372988e37c07b47a407f2eb979190._comment
 create mode 100644 doc/special_remotes/bittorrent/comment_4_aedac7a8482f710637493464b9e76fa7._comment
 create mode 100644 doc/special_remotes/borg.mdwn
 create mode 100644 doc/special_remotes/borg/comment_1_2a650af185a4eee5fd7fc350ed395e2c._comment
 create mode 100644 doc/special_remotes/borg/comment_2_6e6baf5467efcae70729e18975d8eb1a._comment
 create mode 100644 doc/special_remotes/bup.mdwn
 create mode 100644 doc/special_remotes/bup/comment_10_f78c1ed97d2e4c6ebffaa7482cfe0c9b._comment
 create mode 100644 doc/special_remotes/bup/comment_11_b53bceb0058acf4d1ab12ea4853ee443._comment
 create mode 100644 doc/special_remotes/bup/comment_12_65d923226cf6120349d807c5c60f640c._comment
 create mode 100644 doc/special_remotes/bup/comment_12_fca579678edde073716f099c767767e1._comment
 create mode 100644 doc/special_remotes/bup/comment_13_ce960bc69b27dfc2a233c9baa5b2cd2b._comment
 create mode 100644 doc/special_remotes/bup/comment_14_940b778f97377e83dc16439c0c7e5b38._comment
 create mode 100644 doc/special_remotes/bup/comment_15_c4665d089f2ceb2ed798cf264d490a8c._comment
 create mode 100644 doc/special_remotes/bup/comment_16_4787e0373eeec3c7d1d562e47217566c._comment
 create mode 100644 doc/special_remotes/bup/comment_17_360caa8972c2daa94044cc95188306e9._comment
 create mode 100644 doc/special_remotes/bup/comment_1_96179a003da4444f6fc08867872cda0a._comment
 create mode 100644 doc/special_remotes/bup/comment_2_612b038c15206f9f3c2e23c7104ca627._comment
 create mode 100644 doc/special_remotes/bup/comment_3_1186def82741ddab1ade256fb2e59e6f._comment
 create mode 100644 doc/special_remotes/bup/comment_4_7d22a805dd2914971e7ca628ceea69be._comment
 create mode 100644 doc/special_remotes/bup/comment_6_5942333cde09fd98e26c4f1d389cb76f._comment
 create mode 100644 doc/special_remotes/bup/comment_7_cb1a0d3076e9d06e7a24204478f6fa98._comment
 create mode 100644 doc/special_remotes/bup/comment_8_4cbc67e5911748d13cee3c483d7ece8a._comment
 create mode 100644 doc/special_remotes/bup/comment_9_ca7096a759961af375e6bd49663b45b3._comment
 create mode 100644 doc/special_remotes/comment_10_e9881290486a1770bd260f8650ada9c6._comment
 create mode 100644 doc/special_remotes/comment_11_e01b5cc5a0d81b071e93e27e7b91fe2a._comment
 create mode 100644 doc/special_remotes/comment_12_13237170ef5b6646e0e25d3421af3fe5._comment
 create mode 100644 doc/special_remotes/comment_13_1a36a0483a9db04d36e0234a192ebad8._comment
 create mode 100644 doc/special_remotes/comment_14_a8419963dc024b1d9eb73807596012dc._comment
 create mode 100644 doc/special_remotes/comment_15_95ccfdd22a2391daa99e0beb04adedd6._comment
 create mode 100644 doc/special_remotes/comment_16_b9d238fb15ad7628e33c90b071e07bb0._comment
 create mode 100644 doc/special_remotes/comment_17_cc21b81a8f809f6efa5f5b6332513fc3._comment
 create mode 100644 doc/special_remotes/comment_18_3fe750118ff1edbe91a110b86fb5b662._comment
 create mode 100644 doc/special_remotes/comment_19_6794eb52bd87c28ef1df3172aa7d5780._comment
 create mode 100644 doc/special_remotes/comment_1_961276c18e9353ca8e25cad53e7ec51f._comment
 create mode 100644 doc/special_remotes/comment_20_6b7242721f2f2c77b634568cb737e3e3._comment
 create mode 100644 doc/special_remotes/comment_22_308afc586b86c66bbb3437d63864d9cb._comment
 create mode 100644 doc/special_remotes/comment_23_0f5440e0e54cf7ac2a68b1ba115b0930._comment
 create mode 100644 doc/special_remotes/comment_23_96ef232e13bc2dc102a667a06c856ee7._comment
 create mode 100644 doc/special_remotes/comment_24_2c9eda62766c9d5000346a092fe5d0d8._comment
 create mode 100644 doc/special_remotes/comment_25_d9f298f284d66fb0aff029eb01f1ce23._comment
 create mode 100644 doc/special_remotes/comment_26_606c1bee71a265f9df3a8cf50fce9a21._comment
 create mode 100644 doc/special_remotes/comment_27_b37c6ed2444bd7e8b4d7937abdfcbd1c._comment
 create mode 100644 doc/special_remotes/comment_28_c7ab32e1e63fc114b3b2f56bab62eafa._comment
 create mode 100644 doc/special_remotes/comment_29_8393a14f084d022986c8245ee01f4198._comment
 create mode 100644 doc/special_remotes/comment_2_97543acfa7434e332ebea5672e446317._comment
 create mode 100644 doc/special_remotes/comment_30_8e5b17431507ee2115b992e5156b749b._comment
 create mode 100644 doc/special_remotes/comment_31_20ac13d009a4f451eb895ca16446ba88._comment
 create mode 100644 doc/special_remotes/comment_32_8dea734fed26e5d9336a2da5bd81eabc._comment
 create mode 100644 doc/special_remotes/comment_33_317c4d5edc9de8159c3b03a3e161e257._comment
 create mode 100644 doc/special_remotes/comment_34_31256dd4b74d344aa49902adec4bcf02._comment
 create mode 100644 doc/special_remotes/comment_35_5801755d10149f0d3971fef0b6e1b62f._comment
 create mode 100644 doc/special_remotes/comment_36_48859c5ea8f63e37b7531ed0e07f4a54._comment
 create mode 100644 doc/special_remotes/comment_37_9fa2adc324ba25428a681158e58a5300._comment
 create mode 100644 doc/special_remotes/comment_38_04366bcb840b7628d13546daf65650dc._comment
 create mode 100644 doc/special_remotes/comment_39_990a0e67fdd30680631a90231d07c611._comment
 create mode 100644 doc/special_remotes/comment_3_9229776623c234204c8b164edff95da0._comment
 create mode 100644 doc/special_remotes/comment_40_2a36f9c874b00fd5de94836e3dcde782._comment
 create mode 100644 doc/special_remotes/comment_41_26a29fe6169eee1c62dd10672040851c._comment
 create mode 100644 doc/special_remotes/comment_42_85e354eb058aea02be7b847bceb02313._comment
 create mode 100644 doc/special_remotes/comment_43_75a7c567db2b5256182b2cf06091dc12._comment
 create mode 100644 doc/special_remotes/comment_44_bc5871052d29f25eddcc0e02bb2e5a25._comment
 create mode 100644 doc/special_remotes/comment_45_7553ddfb96499b52ddc300a457972645._comment
 create mode 100644 doc/special_remotes/comment_46_f3f5348ceeffb458bcd7bfaa5c420751._comment
 create mode 100644 doc/special_remotes/comment_47_780e9ba56a2a83d64583521b8d987e33._comment
 create mode 100644 doc/special_remotes/comment_48_ee5aa6762ca9403c1a2afe1819984fef._comment
 create mode 100644 doc/special_remotes/comment_49_044a3d6c35fa1b522f7aeea2cec4199a._comment
 create mode 100644 doc/special_remotes/comment_4_3bbda479d13f6bf393dcd59ed94ddeaa._comment
 create mode 100644 doc/special_remotes/comment_50_4485e72f90f46beef3f216ffab82386e._comment
 create mode 100644 doc/special_remotes/comment_51_1a8a217dc31b0a36dfa9975f72d40b3a._comment
 create mode 100644 doc/special_remotes/comment_52_02172d2b81de8c5e212e5ed093a01aa1._comment
 create mode 100644 doc/special_remotes/comment_5_f7000975d38077828ab11a99095b39eb._comment
 create mode 100644 doc/special_remotes/comment_6_5d2bd7c1e1493d3c3784708a9b0bc001._comment
 create mode 100644 doc/special_remotes/comment_7_af01ee5ce31b1490af565cb087d65277._comment
 create mode 100644 doc/special_remotes/comment_8_3d4ffec566d68d601eafe8758a616756._comment
 create mode 100644 doc/special_remotes/comment_9_26af468952f0403171370b56e127830a._comment
 create mode 100644 doc/special_remotes/ddar.mdwn
 create mode 100644 doc/special_remotes/directory.mdwn
 create mode 100644 doc/special_remotes/directory/comment_11_86f8c1b09cbd82bcd76378dfa1b3ca07._comment
 create mode 100644 doc/special_remotes/directory/comment_12._comment
 create mode 100644 doc/special_remotes/directory/comment_12_311cd013fd8db47856d84161119e059d._comment
 create mode 100644 doc/special_remotes/directory/comment_13_019660abe79fb1a3e6dbeb9a87a4c546._comment
 create mode 100644 doc/special_remotes/directory/comment_14_80d962f856de7510a437437fc0ca75e1._comment
 create mode 100644 doc/special_remotes/directory/comment_15_3d091c87c1e4d1c086fb88ae21137a57._comment
 create mode 100644 doc/special_remotes/directory/comment_16_32f6695042fe1f6e40a64a785fab59b9._comment
 create mode 100644 doc/special_remotes/directory/comment_17_01559b914ed43c4468e0980f3f794ea7._comment
 create mode 100644 doc/special_remotes/directory/comment_18_1b24ac6abc99e2e4bc8c9f4687c81395._comment
 create mode 100644 doc/special_remotes/directory/comment_19_0a6ae6ba0d2835da21fa62b2b376bf3f._comment
 create mode 100644 doc/special_remotes/directory/comment_1_e8a53592adb13f7d7f212a2eb5a18a31._comment
 create mode 100644 doc/special_remotes/directory/comment_20_981eeeaee76f89a59e2dcbb368c14387._comment
 create mode 100644 doc/special_remotes/directory/comment_21_4df82f23228dd2f95353f774d9bd8173._comment
 create mode 100644 doc/special_remotes/directory/comment_22_2be4b4e74a41723b72ef92a28f81a4dd._comment
 create mode 100644 doc/special_remotes/directory/comment_2_d949edad6a330079f9e15f703f9091e3._comment
 create mode 100644 doc/special_remotes/directory/comment_3_49009f4e9e335c9a9d0422aa59c9a432._comment
 create mode 100644 doc/special_remotes/directory/comment_4_f5e9b0b477c4e521f8633fd274757fa3._comment
 create mode 100644 doc/special_remotes/directory/comment_5_e790718423c41f5ea8047ea5225bfacd._comment
 create mode 100644 doc/special_remotes/directory/comment_6_325aac80b86588912c4fd61339ccbd0b._comment
 create mode 100644 doc/special_remotes/directory/comment_7_4206db69d68d9917623ce02500387021._comment
 create mode 100644 doc/special_remotes/directory/comment_8_acd9023511fe43817718bc89430f96c3._comment
 create mode 100644 doc/special_remotes/directory/comment_9_d330eb808a990bb71034613c297a265e._comment
 create mode 100644 doc/special_remotes/external.mdwn
 create mode 100755 doc/special_remotes/external/example.sh
 create mode 100755 doc/special_remotes/external/git-annex-remote-ipfs
 create mode 100755 doc/special_remotes/external/git-annex-remote-torrent
 create mode 100644 doc/special_remotes/gcrypt.mdwn
 create mode 100644 doc/special_remotes/gcrypt/comment_1_16a7b4978a58284b5ab3c58f2102e9d0._comment
 create mode 100644 doc/special_remotes/gcrypt/comment_2_08245fd6716ee3ed5ac98fe95e7d5ca1._comment
 create mode 100644 doc/special_remotes/gcrypt/comment_3_2b22c692fb98be1a964430b5b1a329a9._comment
 create mode 100644 doc/special_remotes/git-lfs.mdwn
 create mode 100644 doc/special_remotes/git.mdwn
 create mode 100644 doc/special_remotes/git/comment_1_4c76e1f29065cfb2f8bc05c187c1cc31._comment
 create mode 100644 doc/special_remotes/git/comment_2_12c53dbbdb77f98f337ad60c67171337._comment
 create mode 100644 doc/special_remotes/glacier.mdwn
 create mode 100644 doc/special_remotes/glacier/comment_10_c0e841c3e305712d960e43a10e674215._comment
 create mode 100644 doc/special_remotes/glacier/comment_11_e062b823b4d0b365698a6488d756b85c._comment
 create mode 100644 doc/special_remotes/glacier/comment_12_a097d78d15e103c10f67e237c852b222._comment
 create mode 100644 doc/special_remotes/glacier/comment_13_6ef8735fbd357a09dafe254c8da3b1a8._comment
 create mode 100644 doc/special_remotes/glacier/comment_14_53c965ab49c75fe2220a04f014ba577f._comment
 create mode 100644 doc/special_remotes/glacier/comment_15_e9df327e60ad0e69ace7102deef1efd8._comment
 create mode 100644 doc/special_remotes/glacier/comment_16_ceb6a0cc74eea65fa60b58d1d000acf0._comment
 create mode 100644 doc/special_remotes/glacier/comment_1_fcd856b99dc6b3f9141b65fe639ef76b._comment
 create mode 100644 doc/special_remotes/glacier/comment_2_38fcca87074f6ea31a12569a822aa8c9._comment
 create mode 100644 doc/special_remotes/glacier/comment_3_cea5bcb162e4288847ba5f25464a0406._comment
 create mode 100644 doc/special_remotes/glacier/comment_4_0c92cc82c7ac513130f862391a02d329._comment
 create mode 100644 doc/special_remotes/glacier/comment_5_8d1dcb4bf48386314bfb248ea6eeeb68._comment
 create mode 100644 doc/special_remotes/glacier/comment_6_adb1db354dc4941e4b004e4ba34660d7._comment
 create mode 100644 doc/special_remotes/glacier/comment_7_747e403aac5acaba00e220931e926951._comment
 create mode 100644 doc/special_remotes/glacier/comment_8_a04bb5f27c1a7cfffe881903f973dbec._comment
 create mode 100644 doc/special_remotes/glacier/comment_9_89c4506e079c299fd098d0fe746d032a._comment
 create mode 100644 doc/special_remotes/hook.mdwn
 create mode 100644 doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment
 create mode 100644 doc/special_remotes/hook/comment_2_ee7c43b93c5b787216334f019643f6a0._comment
 create mode 100644 doc/special_remotes/hook/comment_3_2593291795e732994862d08bf2ed467b._comment
 create mode 100644 doc/special_remotes/hook/comment_4_35d79b5ffa5a19056efcdc805070bc4b._comment
 create mode 100644 doc/special_remotes/hook/comment_5_6fbf1e963fa3ea4b2eb8ca5a3819762d._comment
 create mode 100644 doc/special_remotes/hook/comment_6_e0ab48d5333e5de85f016b097e6fdac1._comment
 create mode 100644 doc/special_remotes/hook/comment_7_cc2b1243c2c36e63241513bcaddfea67._comment
 create mode 100644 doc/special_remotes/hook/comment_8_bbae315233bda48eb04662dfd48cf1ae._comment
 create mode 100644 doc/special_remotes/hook/comment_9_037523d1994c702239ca96791156fe65._comment
 create mode 100644 doc/special_remotes/httpalso.mdwn
 create mode 100644 doc/special_remotes/httpalso/comment_1_128e53b20a2f01bf55c83d52c4d42e93._comment
 create mode 100644 doc/special_remotes/httpalso/comment_2_aeeb2122814552f9cf83d950995b16ba._comment
 create mode 100644 doc/special_remotes/httpalso/comment_3_1c9384afe2779ab6c6ae689deea37b31._comment
 create mode 100644 doc/special_remotes/httpalso/comment_4_0bf4d78dec7ec997f781c5a46460b27b._comment
 create mode 100644 doc/special_remotes/httpalso/comment_5_500374b5826e87293dbd4e3aae570185._comment
 create mode 100644 doc/special_remotes/httpalso/comment_6_ee2c2a34e11bbbac835be7660830e298._comment
 create mode 100644 doc/special_remotes/httpalso/comment_7_cea7241b64264f3485e6759b9dc0dfaf._comment
 create mode 100644 doc/special_remotes/httpalso/comment_8_a5198f57b7eb6c458d5e88f8fc9776fa._comment
 create mode 100644 doc/special_remotes/ipfs.mdwn
 create mode 100644 doc/special_remotes/ipfs/comment_10_9fe1bef94c60fb47cad8b80b0cf0d722._comment
 create mode 100644 doc/special_remotes/ipfs/comment_12_1e38459dccd1ef3e23335e9bebca3241._comment
 create mode 100644 doc/special_remotes/ipfs/comment_12_5f8f72a832c8439e3769a1199dc46c4e._comment
 create mode 100644 doc/special_remotes/ipfs/comment_13_551c4dc55b73d6f07c4ddee546b5e938._comment
 create mode 100644 doc/special_remotes/ipfs/comment_14_8cfb0f54444e78089837e62502ef9f61._comment
 create mode 100644 doc/special_remotes/ipfs/comment_15_82b398be82a0b4ec7765606352ec0942._comment
 create mode 100644 doc/special_remotes/ipfs/comment_16_331655ed1b7ebb02444aa693b551e728._comment
 create mode 100644 doc/special_remotes/ipfs/comment_1_d1b2da148715476015716a2f866558b9._comment
 create mode 100644 doc/special_remotes/ipfs/comment_2_564271a8660d7bbade6e4ed396fcfb57._comment
 create mode 100644 doc/special_remotes/ipfs/comment_3_b8c7e402e0ee63d659ae33e3e2504ca2._comment
 create mode 100644 doc/special_remotes/ipfs/comment_4_06611859079239659ba7d73d655f517e._comment
 create mode 100644 doc/special_remotes/ipfs/comment_5_ba7d08b2bcb6614102c48b4cb3de5b1a._comment
 create mode 100644 doc/special_remotes/ipfs/comment_6_8621bbd87982f73cf401cfa09d95d1e4._comment
 create mode 100644 doc/special_remotes/ipfs/comment_7_062f266f26b5788b418de6955bff442d._comment
 create mode 100644 doc/special_remotes/ipfs/comment_8_eedf260df630192b49557bfc84c9ce82._comment
 create mode 100644 doc/special_remotes/ipfs/comment_9_630964c11465751773d1082e35737e70._comment
 create mode 100644 doc/special_remotes/rclone.mdwn
 create mode 100644 doc/special_remotes/rclone/comment_1_3fa761ad2e7a87e160b6d0e86814801c._comment
 create mode 100644 doc/special_remotes/rclone/comment_2_e5babe3bc4535946ee04e8339403fda4._comment
 create mode 100644 doc/special_remotes/rclone/comment_3_d946b28311da5e3632c651f52357a2c1._comment
 create mode 100644 doc/special_remotes/rsync.mdwn
 create mode 100644 doc/special_remotes/rsync/comment_10_43e8fa3517c1f5935f02ad06fbed63dc._comment
 create mode 100644 doc/special_remotes/rsync/comment_11_8cafc1a8b37e6fb056185ec058c0c3e8._comment
 create mode 100644 doc/special_remotes/rsync/comment_12_fa21b66a1722d226f1819646b9c45308._comment
 create mode 100644 doc/special_remotes/rsync/comment_13_368f90773db9522c373168e127a39ae6._comment
 create mode 100644 doc/special_remotes/rsync/comment_14_2261b1b7441eff9e28ec8e1f98d77980._comment
 create mode 100644 doc/special_remotes/rsync/comment_15_a4a0491a7dcee2e7b7786127518866af._comment
 create mode 100644 doc/special_remotes/rsync/comment_16_509514d6e3d790a80a2125068f499a72._comment
 create mode 100644 doc/special_remotes/rsync/comment_1_9e180c397486989beab21699b8e8f103._comment
 create mode 100644 doc/special_remotes/rsync/comment_2_25545dc0b53f09ae73b29899c8884b02._comment
 create mode 100644 doc/special_remotes/rsync/comment_3_960a89b1ae7e3888ffba06baa963dc21._comment
 create mode 100644 doc/special_remotes/rsync/comment_4_db84816c31239953dd21f23a8c557b43._comment
 create mode 100644 doc/special_remotes/rsync/comment_5_ccaffa4aded9dab88c76a856b96ea5b9._comment
 create mode 100644 doc/special_remotes/rsync/comment_6_e687b9482b177e1351c8c65ea617d3fa._comment
 create mode 100644 doc/special_remotes/rsync/comment_7_e122979ea811d9ef835ba05bb936190f._comment
 create mode 100644 doc/special_remotes/rsync/comment_8_d566113318d0aa7500d76ffe1bd46069._comment
 create mode 100644 doc/special_remotes/rsync/comment_9_5dcf10a502b2d4feac46b620d43e9d00._comment
 create mode 100644 doc/special_remotes/tahoe.mdwn
 create mode 100644 doc/special_remotes/tahoe/comment_10_90d6937e95301f83268e0c9190f0f8c5._comment
 create mode 100644 doc/special_remotes/tahoe/comment_1_d30f5958cca5dbcb93e4ea56a25586da._comment
 create mode 100644 doc/special_remotes/tahoe/comment_2_84d59f41949987381369ab75efc1b65e._comment
 create mode 100644 doc/special_remotes/tahoe/comment_3_8a425ab612c3b46efb9658ab79038661._comment
 create mode 100644 doc/special_remotes/tahoe/comment_4_11513056ee7de3dc8bf54c7e0948538d._comment
 create mode 100644 doc/special_remotes/tahoe/comment_5_588d129cc2eaf0a8df9fc2fc6de014a9._comment
 create mode 100644 doc/special_remotes/tahoe/comment_6_9b23112d568a7edfce05e95478c30e4f._comment
 create mode 100644 doc/special_remotes/tahoe/comment_7_5aa703bb3d3f7de9e78a6d831bd515dc._comment
 create mode 100644 doc/special_remotes/tahoe/comment_9_75eccd07ea57f44d5a198533a907225a._comment
 create mode 100644 doc/special_remotes/tahoe/comment_9_f5e45af55cd18af73e2d3d5911039418._comment
 create mode 100644 doc/special_remotes/tor.mdwn
 create mode 100644 doc/special_remotes/web.mdwn
 create mode 100644 doc/special_remotes/web/comment_1_0bd570025f6cd551349ea88a4729ac8e._comment
 create mode 100644 doc/special_remotes/web/comment_2_333141cc9ec6c26ffd19aa95303a91e3._comment
 create mode 100644 doc/special_remotes/web/comment_3_e6ce9bb92c973350852c9498b7ffb50f._comment
 create mode 100644 doc/special_remotes/web/comment_4_8a8369e0398a7ec6c65e493e4d836db9._comment
 create mode 100644 doc/special_remotes/web/comment_5_1ad36ff51dfe69256fb0c8803da4efd6._comment
 create mode 100644 doc/special_remotes/webdav.mdwn
 create mode 100644 doc/special_remotes/webdav/comment_10_2c087a132c2203ac20636800bf73dfa7._comment
 create mode 100644 doc/special_remotes/webdav/comment_11_cde4fccaf551ba1eab8235ebf6654316._comment
 create mode 100644 doc/special_remotes/webdav/comment_12_76423262fceeced32ab18fa38ed53bdb._comment
 create mode 100644 doc/special_remotes/webdav/comment_14_2390020fa7daac8a6d3e8b713bd3b8e7._comment
 create mode 100644 doc/special_remotes/webdav/comment_14_45e3b7094d0611b2e082be352f74151a._comment
 create mode 100644 doc/special_remotes/webdav/comment_15_d43673b8c8ed3534f31d026098ab673c._comment
 create mode 100644 doc/special_remotes/webdav/comment_16_2a11dfc1fd159a6b9a25cde71ffec80b._comment
 create mode 100644 doc/special_remotes/webdav/comment_17_cfd2786a998af5034dc707f23aa81678._comment
 create mode 100644 doc/special_remotes/webdav/comment_18_c0aff1c36b500ae67c6cb4b34292a54b._comment
 create mode 100644 doc/special_remotes/webdav/comment_19_8bf8d365c0a13f684ed9f9cb013396e7._comment
 create mode 100644 doc/special_remotes/webdav/comment_1_6b523eea78eae1d19fe2a9950ee33e3a._comment
 create mode 100644 doc/special_remotes/webdav/comment_20_a85a41709bbc0c7c138838ac94ba499f._comment
 create mode 100644 doc/special_remotes/webdav/comment_21_e86cfc56014df46412f08b36bc019fb6._comment
 create mode 100644 doc/special_remotes/webdav/comment_22_556386f26497f4075ab533e21e2077ce._comment
 create mode 100644 doc/special_remotes/webdav/comment_23_b57fdd5322088e9b08dca7512c7e7793._comment
 create mode 100644 doc/special_remotes/webdav/comment_24_6c16a7c9abb257be4d046e27e11bacdf._comment
 create mode 100644 doc/special_remotes/webdav/comment_2_83fc4e7d9ba7a05c8500da659f561b8f._comment
 create mode 100644 doc/special_remotes/webdav/comment_3_239367ad639c61ecdf87a89f7ac53efe._comment
 create mode 100644 doc/special_remotes/webdav/comment_4_ffa52f7776cdc8caa28667b5eadae123._comment
 create mode 100644 doc/special_remotes/webdav/comment_5_5b8cbdb5e9a1b90d748a5074997e1cd5._comment
 create mode 100644 doc/special_remotes/webdav/comment_6_d3be3e588c3a2abb2025ceb82c18b0ef._comment
 create mode 100644 doc/special_remotes/webdav/comment_7_6fa7e11331db5a943015bd5367eb3d73._comment
 create mode 100644 doc/special_remotes/webdav/comment_8_2627b41f80c7511b27464e2040b128a8._comment
 create mode 100644 doc/special_remotes/webdav/comment_9_b8f17efe524bb45a3e16705996df1265._comment
 create mode 100644 doc/special_remotes/xmpp.mdwn
 create mode 100644 doc/special_remotes/xmpp/comment_10_c7c2e2e81cb5b2b9a5272430c835dd39._comment
 create mode 100644 doc/special_remotes/xmpp/comment_11_05d9a67b9331656b4035399641cedb1b._comment
 create mode 100644 doc/special_remotes/xmpp/comment_1_568247938929a2934e8198fca80b7184._comment
 create mode 100644 doc/special_remotes/xmpp/comment_2_9fc3f512020b7eb2591d6b7b2e8de2d7._comment
 create mode 100644 doc/special_remotes/xmpp/comment_3_48ddbba1402d89acaea07cff747c48e0._comment
 create mode 100644 doc/special_remotes/xmpp/comment_4_59857879abaae22bde444a215e00bf18._comment
 create mode 100644 doc/special_remotes/xmpp/comment_5_583ee374bd34fcc9ae26c2fd690e8c47._comment
 create mode 100644 doc/special_remotes/xmpp/comment_6_8f0b5bba1271d031a67e7f0c175d67d5._comment
 create mode 100644 doc/special_remotes/xmpp/comment_7_ac7acbded03325b015959d82ae77faf1._comment
 create mode 100644 doc/special_remotes/xmpp/comment_8_81a9636a1e8a36a58185468a26f8633d._comment
 create mode 100644 doc/special_remotes/xmpp/comment_9_eda76b826491c96b1ce072aacf9d3adf._comment
 create mode 100644 doc/stickers.mdwn
 create mode 100644 doc/stickers/comment_1_96f9b35048793c1cc0902cced82b65c5._comment
 create mode 100644 doc/stickers/comment_2_39cfee29eae5e69d88d84b2c65eb83fe._comment
 create mode 100644 doc/stickers/hex.svg
 create mode 100644 doc/stickers/hexdemos.svg
 create mode 100644 doc/submodules.mdwn
 create mode 100644 doc/submodules/comment_10_936e145bbe3b6bd928571c17d3416937._comment
 create mode 100644 doc/submodules/comment_11_78fffae9facce1600915bc19429d81e2._comment
 create mode 100644 doc/submodules/comment_12_d59882712e0547c748d3b354e8607d62._comment
 create mode 100644 doc/submodules/comment_1_15a2633524fc376b6a6c4f76187e435b._comment
 create mode 100644 doc/submodules/comment_2_fb006a18240230aefb80ee8aeebdccb7._comment
 create mode 100644 doc/submodules/comment_3_92cdc81ccc4831f5ad493736ca87e87d._comment
 create mode 100644 doc/submodules/comment_4_9da0d19529dfb8a997ad469169e55895._comment
 create mode 100644 doc/submodules/comment_5_9ccb133a957498724188a8749359a422._comment
 create mode 100644 doc/submodules/comment_6_d1877da19346bbd6067ff95252974a9b._comment
 create mode 100644 doc/submodules/comment_7_899cf2aa74cbb8160b1e249b314e7d60._comment
 create mode 100644 doc/submodules/comment_8_8755b0d18c1b013ed0dc121ecfb83360._comment
 create mode 100644 doc/submodules/comment_9_5e3a7d5c81fb37efbfe22cbbe8b8a247._comment
 create mode 100644 doc/summary.mdwn
 create mode 100644 doc/sync.mdwn
 create mode 100644 doc/sync/comment_10_2cd8ab86f498d6f676f859b552f831eb._comment
 create mode 100644 doc/sync/comment_11_7683879f6982c0eb0aa39b66ff5a5ea9._comment
 create mode 100644 doc/sync/comment_12_2fea14fa314ddb7ab645a5cca5a95fd9._comment
 create mode 100644 doc/sync/comment_13_690f66be9cefe28844d8df653b7a0331._comment
 create mode 100644 doc/sync/comment_14_db342785a4dade30b5b75cb95031bed1._comment
 create mode 100644 doc/sync/comment_15_168e0ab10b4084e13df1a3058fa7e8a9._comment
 create mode 100644 doc/sync/comment_16_96096f994fc55f921f2b24b274f998f7._comment
 create mode 100644 doc/sync/comment_17_44a4ae4685c4bf2b4e7c61897eb3ff80._comment
 create mode 100644 doc/sync/comment_18_838fb249cd5be83962770d5cc394389a._comment
 create mode 100644 doc/sync/comment_19_d409ad20c5a6671f0d0b834232368030._comment
 create mode 100644 doc/sync/comment_1_59681be5568f568f5c54eb0445163dd2._comment
 create mode 100644 doc/sync/comment_20_537b27219871a565ae7bb7f357cd3793._comment
 create mode 100644 doc/sync/comment_21_9c0368eb796f1191c22c186cbb06c642._comment
 create mode 100644 doc/sync/comment_22_e83ed5c0034c48baed7943c596f708ae._comment
 create mode 100644 doc/sync/comment_23_e5e7ec9fbafe5e0429161b977e483752._comment
 create mode 100644 doc/sync/comment_24_1d1eb1bddc835644c7f9d6e83e09b752._comment
 create mode 100644 doc/sync/comment_25_7e69a963102ceaa5b691ad9ed15c5a42._comment
 create mode 100644 doc/sync/comment_25_ea6f4e1f5ab31cd74d67fe95e83084cb._comment
 create mode 100644 doc/sync/comment_27_8925805ff8902d7b2d1f47c1395aadc7._comment
 create mode 100644 doc/sync/comment_28_e5c5da7fc0d0d034bfae33481f1ae067._comment
 create mode 100644 doc/sync/comment_29_161c5d3f693de45070e037d27ee7e8aa._comment
 create mode 100644 doc/sync/comment_2_9301ff5e81d37475f594e74fbe32f24e._comment
 create mode 100644 doc/sync/comment_30_f75f5957dbd0f6fd7b2d7291f06e7489._comment
 create mode 100644 doc/sync/comment_31_c85edac65571caff70e87dff2317a4e5._comment
 create mode 100644 doc/sync/comment_3_49560003da47490e4fabd4ab0089f2d7._comment
 create mode 100644 doc/sync/comment_4_cf29326408e62575085d1f980087c923._comment
 create mode 100644 doc/sync/comment_5_18c396c59907147bb2bf713e55392b6b._comment
 create mode 100644 doc/sync/comment_6_012e9d4468d0b88ee3c5dad3911c3606._comment
 create mode 100644 doc/sync/comment_7_6276e100d1341f1a0be368f54de0ae7b._comment
 create mode 100644 doc/sync/comment_8_b89161c82c05634d35f6b65bf8360a96._comment
 create mode 100644 doc/sync/comment_9_849883b7cc05bfcb01914d8737098010._comment
 create mode 100644 doc/templates/bare.tmpl
 create mode 100644 doc/templates/blogpost.tmpl
 create mode 100644 doc/templates/buglist.tmpl
 create mode 100644 doc/templates/bugtemplate.mdwn
 create mode 100644 doc/templates/note.mdwn
 create mode 100644 doc/templates/walkthrough.tmpl
 create mode 100644 doc/testimonials.mdwn
 create mode 100644 doc/testimonials/comment_1_2bf439f7a3bc3d6fab91849017946182._comment
 create mode 100644 doc/thanks.mdwn
 create mode 100644 doc/thanks/list
 create mode 100644 doc/thanks/list.2018
 create mode 100644 doc/thanks/list.2023
 create mode 100644 doc/tips.mdwn
 create mode 100644 doc/tips/Accessing_files_in_bare_remotes_without_git-annex.mdwn
 create mode 100644 doc/tips/Accessing_files_in_bare_remotes_without_git-annex/comment_1_9243af1c87fdaf33e336ec34e99c0f74._comment
 create mode 100644 doc/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex.mdwn
 create mode 100644 doc/tips/Building_git-annex_on_Debian_OR___37____164____35____34____164____37____38____34____35___Haskell__33__.mdwn
 create mode 100644 doc/tips/Building_git-annex_on_Debian_OR___37____164____35____34____164____37____38____34____35___Haskell__33__/comment_1_835a3608df3e9d044cabe822d0f3e7e4._comment
 create mode 100644 doc/tips/Building_git-annex_on_Debian_OR___37____164____35____34____164____37____38____34____35___Haskell__33__/comment_2_080b30cba72a718e73ea715e259e1cfb._comment
 create mode 100644 doc/tips/Bup_repositories_in_git-annex.mdwn
 create mode 100644 doc/tips/Bup_repositories_in_git-annex/comment_1_738959a699755704baab6df778ecd120._comment
 create mode 100644 doc/tips/Crude_Windows_Sync.mdwn
 create mode 100644 doc/tips/Decentralized_repository_behind_a_Firewall.mdwn
 create mode 100644 doc/tips/Decentralized_repository_behind_a_Firewall/comment_1_78b9035234a690ca5a7c9f3cc78fa092._comment
 create mode 100644 doc/tips/Decrypting_files_in_special_remotes_without_git-annex.mdwn
 create mode 100644 doc/tips/Decrypting_files_in_special_remotes_without_git-annex/comment_1_9288805fae0710b19da6c82f9dc32f2a._comment
 create mode 100644 doc/tips/Delay_Assistant_Startup_on_Login.mdwn
 create mode 100644 doc/tips/Delay_Assistant_Startup_on_Login/comment_1_c63917150527efab4b1106183b3aa7ef._comment
 create mode 100644 doc/tips/Faster_bash_autocompletion_with_big_annex_repos.mdwn
 create mode 100644 doc/tips/Faster_bash_autocompletion_with_big_annex_repos/comment_1_a41fb1037186319bbb44f7a67df6120f._comment
 create mode 100644 doc/tips/Git_annex_and_Calibre.mdwn
 create mode 100644 doc/tips/Git_annex_and_Calibre/comment_1_b0ef346eaab9ff616aa1ba6b5f4530bc._comment
 create mode 100644 doc/tips/Git_annex_and_Calibre/comment_2_9e8122ea81bbd0a86bd6c5173db801f8._comment
 create mode 100644 doc/tips/Git_annex_and_Calibre/comment_3_ee1372977919229d17d216cfc3fb0f61._comment
 create mode 100644 doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo.mdwn
 create mode 100644 doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_1_7eaf73fb3355bd706ab18a43790b3c10._comment
 create mode 100644 doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_2_dac1a171204f30d7c906e878eb6bd461._comment
 create mode 100644 doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_3_b62ec0b848d2487d68d7032682622193._comment
 create mode 100644 doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_4_2423904e41a86cd1c6bc155d7b733642._comment
 create mode 100644 doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_5_3062c0794ecd7c6237efae66f4d9b62f._comment
 create mode 100644 doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_6_1eceb980814f95b28caac9d4d9894f01._comment
 create mode 100644 doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_7_603db6818d33663b70b917c04fd8485b._comment
 create mode 100644 doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_8_834410421ccede5194bd8fbaccea8d1a._comment
 create mode 100644 doc/tips/Internet_Archive_via_S3.mdwn
 create mode 100644 doc/tips/Internet_Archive_via_S3/comment_1_d53a3848c20dce61867283fc03c2adaa._comment
 create mode 100644 doc/tips/Internet_Archive_via_S3/comment_2_91c1472da27b00e5d682d22bc1ef04e0._comment
 create mode 100644 doc/tips/Internet_Archive_via_S3/comment_3_e23cf781c532f80d47d52265f2b2c87e._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files.mdwn
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_10_3fac08b817ca3dbfcac3a03ce521464e._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_11_49585db4fbf9f22bf806ee08d73b7db1._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_12_e1f3b19d1dd62b1c9314e1e826fec54f._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_13_6b4cd0667d700c0c5ec6e0054b43f2e7._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_14_f8af84e301d271e9822556f23395dde7._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_15_71def7a311980e89a3b877175ea5bbe2._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_1_fac49a6d3f6a18c9925c34521221307d._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_2_f8417d9ebcfdcba34dfbbf76070ad95c._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_3_992f2a85ce0cdcef2f97ff978560fdb8._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_4_8ff3aa032fb778ff69276984152578b0._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_5_8540bf807eaf1b4e927eafc03deef304._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_6_9169a33c06cf8aea231cdd8f51ce17b6._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_7_f56f1ffeb5e1f382d3227b4ace7f84a1._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_8_25a26f5210986655808992533aa48d3d._comment
 create mode 100644 doc/tips/Repositories_with_large_number_of_files/comment_9_c2b44076201d8152f16e12cb23c50397._comment
 create mode 100644 doc/tips/Shamir_secret_sharing_and_git-annex.mdwn
 create mode 100644 doc/tips/Synology_NAS_and_git_annex.mdwn
 create mode 100644 doc/tips/Synology_NAS_and_git_annex/comment_10_ee03a12ac5ba760b038ac5b93eea4be3._comment
 create mode 100644 doc/tips/Synology_NAS_and_git_annex/comment_11_ab2487da061a23e14198875a00ae801e._comment
 create mode 100644 doc/tips/Synology_NAS_and_git_annex/comment_13_44b28cff77db57a83d9448f768695d2b._comment
 create mode 100644 doc/tips/Synology_NAS_and_git_annex/comment_1_ef7e19f1fd2005eb7cc74509ffb92766._comment
 create mode 100644 doc/tips/Synology_NAS_and_git_annex/comment_2_5e723ccf026fe970ad31207f9f036b69._comment
 create mode 100644 doc/tips/Synology_NAS_and_git_annex/comment_3_8beb2b4b79c7787a92689aaad3bfc452._comment
 create mode 100644 doc/tips/Synology_NAS_and_git_annex/comment_4_b04a1245378d3580432e85dff8eefdec._comment
 create mode 100644 doc/tips/Synology_NAS_and_git_annex/comment_5_7e4ec2b22fb15e653d3b2274493e460c._comment
 create mode 100644 doc/tips/Synology_NAS_and_git_annex/comment_6_954fc1b423208928fafdeb8cdac47c50._comment
 create mode 100644 doc/tips/Synology_NAS_and_git_annex/comment_7_b862cb6ad0f912cc2ffede21df10c2fe._comment
 create mode 100644 doc/tips/Synology_NAS_and_git_annex/comment_8_38775efe367033a9a96cf98a49f8cdde._comment
 create mode 100644 doc/tips/Synology_NAS_and_git_annex/comment_9_52e1684fc40d1ab487a06cf13530871b._comment
 create mode 100644 doc/tips/Systemd_unit.mdwn
 create mode 100644 doc/tips/Systemd_unit/comment_1_06399a293f08401032bef1b94f05547c._comment
 create mode 100644 doc/tips/Systemd_unit/comment_2_389a2b36c3115eb3342429b0b68ddef2._comment
 create mode 100644 doc/tips/The_perfect_preferred_content_settings_for_my_android_phone.mdwn
 create mode 100644 doc/tips/The_perfect_preferred_content_settings_for_my_android_phone/comment_1_393d1636bb313530be383a075bd3440a._comment
 create mode 100644 doc/tips/The_perfect_preferred_content_settings_for_my_android_phone/comment_2_51a013213118660bdc06ff4d6c8110ba._comment
 create mode 100644 doc/tips/Using_Git-annex_as_a_web_browsing_assistant.mdwn
 create mode 100644 doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
 create mode 100644 doc/tips/Using_git-annex_on_NTFS_with_WSL1/comment_1_426bcb5c31f6ddf078b5f7c9bba00672._comment
 create mode 100644 doc/tips/Using_git-annex_on_NTFS_with_WSL1/comment_2_df6e152f1291c3dc1ba2b1b03b18083e._comment
 create mode 100644 doc/tips/Using_git-worktree_with_annex.mdwn
 create mode 100644 doc/tips/Using_git-worktree_with_annex/comment_1_8e1493eae66a483ece338649c763115a._comment
 create mode 100644 doc/tips/ZSH_completion.mdwn
 create mode 100644 doc/tips/ZSH_completion/comment_1_a810be47633dc83d737a9ef6e8870431._comment
 create mode 100644 doc/tips/ZSH_completion/comment_4_0e6f7035350ec0c9c61eeafb02ab7af7._comment
 create mode 100644 doc/tips/ZSH_completion/comment_4_2bdaf6a00723b975808a52863e417321._comment
 create mode 100644 doc/tips/ZSH_completion/comment_5_182c13292016baf46d8f53a306cb4b05._comment
 create mode 100644 doc/tips/a_gui_for_metadata_operations.mdwn
 create mode 100644 doc/tips/a_gui_for_metadata_operations/comment_1_1ce311d8328ea370a6a3494adea0f5db._comment
 create mode 100644 doc/tips/android_sync_with_adb.mdwn
 create mode 100644 doc/tips/android_sync_with_adb/comment_1_18e0b24a2907ba8df033454315e50212._comment
 create mode 100644 doc/tips/android_sync_with_adb/comment_1_ae0ae08f76cce010999ec8d366f52400._comment
 create mode 100644 doc/tips/android_sync_with_adb/comment_2_68affd1a753abdeca0f161698cc63413._comment
 create mode 100644 doc/tips/android_sync_with_adb/comment_4_d3e6d777a26c6719df4fd2b4cf89763b._comment
 create mode 100644 doc/tips/android_sync_with_adb/comment_5_1ac315bee17c7f4cdc5de1427852d609._comment
 create mode 100644 doc/tips/android_sync_with_adb/comment_6_4aefa716b1d37b89c3dc002f85ab6607._comment
 create mode 100644 doc/tips/android_sync_with_adb/comment_7_44a985a0cbd0adfe3a2ca4ef20443083._comment
 create mode 100644 doc/tips/android_sync_with_adb/comment_8_036ff21f5eee0c165a41e472ffdfa341._comment
 create mode 100644 doc/tips/android_sync_with_adb/comment_9_af84d2eaeba2d5a8df087e097095eba5._comment
 create mode 100644 doc/tips/antipatterns.mdwn
 create mode 100644 doc/tips/assume-unstaged.mdwn
 create mode 100644 doc/tips/assume-unstaged/comment_1_44abd811ef79a85e557418e17a3927be._comment
 create mode 100644 doc/tips/assume-unstaged/comment_2_5b589f37cfc03bf7be33a51826cc4dba._comment
 create mode 100644 doc/tips/automatically_adding_metadata.mdwn
 create mode 100644 doc/tips/automatically_adding_metadata/comment_10_cf770ba8eed7963f08517877bd460d3f._comment
 create mode 100644 doc/tips/automatically_adding_metadata/comment_11_6eeb21b66aa3541491ddc0dd3058ddc7._comment
 create mode 100644 doc/tips/automatically_adding_metadata/comment_12_92c28dee004562d7085191f3b9e29fec._comment
 create mode 100644 doc/tips/automatically_adding_metadata/comment_13_065b018dc290549b5ef00b50c3b09fcc._comment
 create mode 100644 doc/tips/automatically_adding_metadata/comment_1_ffc308cc6aedabbc55820db4f401e0fb._comment
 create mode 100644 doc/tips/automatically_adding_metadata/comment_2_bd64a53914107bc000c887b4d4bdf6af._comment
 create mode 100644 doc/tips/automatically_adding_metadata/comment_3_02e5314f827d17d482343e8f22c42fd9._comment
 create mode 100644 doc/tips/automatically_adding_metadata/comment_4_cd3c8e2f45db93576d1b82cfbfbe601b._comment
 create mode 100644 doc/tips/automatically_adding_metadata/comment_5_888f0a77405d616a0d51a6176b44f605._comment
 create mode 100644 doc/tips/automatically_adding_metadata/comment_6_34f0c55d09ddee3de642f6b25a9f6269._comment
 create mode 100644 doc/tips/automatically_adding_metadata/comment_7_94877b21bf80374c2874b971f26f0e55._comment
 create mode 100644 doc/tips/automatically_adding_metadata/comment_8_3880fb7f13e74d33d9c4e86772cc6b0e._comment
 create mode 100644 doc/tips/automatically_adding_metadata/comment_9_db9c2fa8545188520d4bdda5ba545624._comment
 create mode 100755 doc/tips/automatically_adding_metadata/pre-commit-annex
 create mode 100644 doc/tips/automatically_getting_files_on_checkout.mdwn
 create mode 100644 doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes.mdwn
 create mode 100644 doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_1_e7c5c46112a2406b873d08bbf53c40d8._comment
 create mode 100644 doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_2_daf45ce29fed986fa9aa8b173760d0b7._comment
 create mode 100644 doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_3_72d222020af4a9c6c753eb1ee7e1f1cf._comment
 create mode 100644 doc/tips/centralised_repository__58___starting_from_nothing.mdwn
 create mode 100644 doc/tips/centralised_repository__58___starting_from_nothing/comment_1_b0d22822017646775869ce1292e676f4._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial.mdwn
 create mode 100644 doc/tips/centralized_git_repository_tutorial/comment_1_9072ebc0c61446d7b151fcfab616fea9._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/comment_2_528e92b21f0551fde4adb956654953ae._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/comment_3_8894229043935e70089caf67f0cc4ddb._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/comment_4_b496622537d2491854b02884acf1672c._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/comment_5_c6e3468c95bc875e17724ee4a3a283a3._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_GitHub.mdwn
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_GitHub/comment_1_98a1986ff2047de981d77755c462b690._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_GitLab.mdwn
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_1_9d0694204984ec96379a62f0f70ba696._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_2_1c33d3f62ec7119c116ad02b75c91f8a._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_3_7d3ea328a42c3a1df01f87e5233eca62._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_4_3c40b855e9914d8987b2f89d9abc29ae._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_your_own_server.mdwn
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_1_ae5af47faf95f008f1b07dbed5181286._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_2_b6a70e698eb4c46e753a620716c5956c._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_3_371f22ec58cf953c2b8abe3af71d3f91._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_4_6610f58b031d587f07f05b31754e4d97._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_5_b18e841b77cbec354d7641f37d030f49._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_6_a75d657dc322e1ccb02871492bef6f12._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_7_e818be55d40623167ce2d0381e7168e3._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_8_0778c23a67f7474753fb143ced6227a5._comment
 create mode 100644 doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_9_915965b46b03186eec466c51131c734c._comment
 create mode 100644 doc/tips/cloning_a_repository_privately.mdwn
 create mode 100644 doc/tips/cloning_a_repository_privately/comment_1_f5490d034074ca80a712bdd41c307139._comment
 create mode 100644 doc/tips/cloning_a_repository_privately/comment_2_0fb78b2183932da08809d60dfc5a7374._comment
 create mode 100644 doc/tips/deleting_unwanted_files.mdwn
 create mode 100644 doc/tips/deleting_unwanted_files/comment_1_2d3cf347c754047875a26d7f73c6fbb2._comment
 create mode 100644 doc/tips/deleting_unwanted_files/comment_2_8471758f2e02ebcfd9c015691ba9f15f._comment
 create mode 100644 doc/tips/disabling_a_special_remote.mdwn
 create mode 100644 doc/tips/disabling_a_special_remote/comment_1_8762ffef0024a9396979fc2586965c5d._comment
 create mode 100644 doc/tips/disabling_a_special_remote/comment_2_325dc29b8e82595806741b0ff8dd6215._comment
 create mode 100644 doc/tips/disabling_a_special_remote/comment_3_6c7c92a9c5ce9cee1450117f0bab1354._comment
 create mode 100644 doc/tips/downloading_podcasts.mdwn
 create mode 100644 doc/tips/downloading_podcasts/comment_10_4d4f6c22070b58918ee8d34c5e7290ad._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_11_d8d77048c7e2524968c188e1ad517873._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_12_0859317471b43c88744dd3df95c879f7._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_13_e8c3c97282d17e2a1d47fb9d5e2b2f7b._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_14_05a3694052de36848fbbad6eeeada895._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_15_21028bed8858c2dae1ac9c2d014fd2a1._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_16_4869fb5c9f896acc477c44de06c36ca7._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_17_2e278ff200c1c15efd27c46a3e0aed40._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_18_382f2b970738d9b1af577955c3083e90._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_19_f76fc6835e5787b0156380bf09fd81ca._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_1_f04bc32a34baeeffcd691e9f7cce0230._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_20_65ebf3a3bbf0a2aebd2b69640b757e16._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_21_98a1dacc8d264ff31801e6c5c5f2612d._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_22_00cc7a2fb936d7ea3d5d3764a1637663._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_23_62603cda8e581a2eb2cc799dffe8a740._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_24_e75af243654d15bc7b917fcd888bcf2f._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_25_2ee88c3375eca23fe34cab65df1e7aeb._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_26_a69b4c033d85406675bb70e6996590ce._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_27_e343aeda7c16c834599fb3caab2a51a2._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_28_f57a89a32a55dfae0dfa237a8981a667._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_2_a9a98cad7358d16792853a2ee413fe6c._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_3_5a8068a5cb0fd864581157a3aa5d1113._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_4_e7072a9da30b4c4b4c526013144238d4._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_5_79b3f8d678ac9f67df4c0cd649657283._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_6_35106fee5458bdd5c21868fbc49d3616._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_7_ceb16498b7aadbf04a27acd5d6561d46._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_8_147397603f0b3fdb42ca387d1da7c5ef._comment
 create mode 100644 doc/tips/downloading_podcasts/comment_9_6a26a6cc7683d38fae0f23c5a52d1e23._comment
 create mode 100644 doc/tips/dropboxannex.mdwn
 create mode 100644 doc/tips/dumb_metadata_extraction_from_xbmc.mdwn
 create mode 100644 doc/tips/dumb_metadata_extraction_from_xbmc/git-annex-xbmc-playcount.pl
 create mode 100644 doc/tips/emacs_integration.mdwn
 create mode 100644 doc/tips/enable_tor_on_nixos.mdwn
 create mode 100644 doc/tips/file_manager_integration.mdwn
 create mode 100644 doc/tips/file_manager_integration/comment_1_0f82520f415b4715946358658e1799a8._comment
 create mode 100644 doc/tips/file_manager_integration/comment_2_9cb6b7fcb8e33a75efd2f92d7e40a9c5._comment
 create mode 100644 doc/tips/file_manager_integration/comment_3_e7096737268cf66fce2709e9e4937f51._comment
 create mode 100644 doc/tips/finding_duplicate_files.mdwn
 create mode 100644 doc/tips/finding_duplicate_files/comment_11_5efc6b6ee1dfec88512183e9679ca616._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_12_630b065f41019716a5f6848e0adcd0f0._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_14_21f6ff2f7c51ca148fb8836a5e325e23._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_15_cd191275a277aee5de80507d5b5da69b._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_16_05827cf95647c56c344d150564cdf01d._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_17_9ea2c23d6099281f55122e39655d7353._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_1_ddb477ca242ffeb21e0df394d8fdf5d2._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_2_900eafe0a781018ff44b35ac232e3ad3._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_3._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_4_1494143a74cc1e9fbe4720c14b73d42b._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_5_1a35ca360468bcb84a67ad8d62a2ef7d._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_6_a6e88c93b31f67c933523725ff61b287._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_7_347b0186755a809594bd42feda6363e2._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_8_3af51722da0980b724facb184f0f66e9._comment
 create mode 100644 doc/tips/finding_duplicate_files/comment_9_7b4b78a5cd253abfe4f6001049bf64f3._comment
 create mode 100644 doc/tips/finding_which_file_matches_a_key.mdwn
 create mode 100644 doc/tips/finding_which_file_matches_a_key/comment_1_0379aaad5d1dc13e90c13ddd82719ce5._comment
 create mode 100644 doc/tips/finding_which_file_matches_a_key/comment_2_8feecf0ed92b958c902ea2032b5d9576._comment
 create mode 100644 doc/tips/finding_which_file_matches_a_key/comment_3_1775ca681b8471938a0173b21019f743._comment
 create mode 100644 doc/tips/flickrannex.mdwn
 create mode 100644 doc/tips/flickrannex/comment_10_50707f259abe5829ce075dfbecd5a4ba._comment
 create mode 100644 doc/tips/flickrannex/comment_11_ab5bcb025381b3da4d7c6dfd0c7310dd._comment
 create mode 100644 doc/tips/flickrannex/comment_12_90a331275d888221bc695003c8acbe46._comment
 create mode 100644 doc/tips/flickrannex/comment_13_1596e70dca71c853fd1d6fc9bde02b18._comment
 create mode 100644 doc/tips/flickrannex/comment_14_c728f10074d194efa8b2c60e97d275e7._comment
 create mode 100644 doc/tips/flickrannex/comment_15_2dd75800e4db58761fcbbd1954a36f1f._comment
 create mode 100644 doc/tips/flickrannex/comment_16_2f65093ec9f6d67d2cfe5b5fae201123._comment
 create mode 100644 doc/tips/flickrannex/comment_17_5bfe0988260b7825eeec204cd8f79b98._comment
 create mode 100644 doc/tips/flickrannex/comment_18_ef71e2f8c48b0399d9fbc419e850dc5d._comment
 create mode 100644 doc/tips/flickrannex/comment_2_d74c4fc7edf8e47f7482564ce0ef4d12._comment
 create mode 100644 doc/tips/flickrannex/comment_2_f53d0d5520e2835e9705bea4e75556f0._comment
 create mode 100644 doc/tips/flickrannex/comment_4_9ebba4d61140f6c2071e988c9328cf7e._comment
 create mode 100644 doc/tips/flickrannex/comment_5_4470dae270613dd8712623474bc80ab0._comment
 create mode 100644 doc/tips/flickrannex/comment_5_d395cdcf815cb430e374ff05c1a63ff4._comment
 create mode 100644 doc/tips/flickrannex/comment_6_8cf730097001ffe106f2c743edce9d0a._comment
 create mode 100644 doc/tips/flickrannex/comment_7_a80c8087c4e1562a4c98a24edc182e5a._comment
 create mode 100644 doc/tips/flickrannex/comment_8_94f84254c32cf0f7dd1441b7da5d2bc6._comment
 create mode 100644 doc/tips/flickrannex/comment_9_5299b4cab4a4cb8e8fd4d2b39f0ea59c._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt.mdwn
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_10_4440a80d64c60c7312d5c405d54e607a._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_11_28eb9d4ebf28ca310f9b357b1dad244a._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_12_b697b2ab10705b090a78e7717ec59b18._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_13_4e37146a870576f09f56d2e5ee784ed7._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_14_2044e821d841fcd37a51ae768fa88df2._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_15_de4838d82987685896d4c76dac7cdb6c._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_16_c1194234e9f4fd469fa4b9fea72219e1._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_17_098998132fb0bcf130b5bf8a16ac8b8a._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_18_bdcb4bace530ac8b2018916893ae7e93._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_1_5c54690586f2a781905ea4b25aa1147f._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_2_07feedb4348f8c31176cc744c19368a1._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_3_c2f873dffa015f1d72ad0c3921909316._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_4_f8a6e4415f4fe6da14f6a3b7334bc952._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_5_11b8e82d2a234f65b58b823e71c6d6a2._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_6_3e41948e1beffcf279bb05ef8e61cc07._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_7_4ce0b26b25b336f07b2e27246cdfba3e._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_8_49aa34d75d24a2066baa8a585bc9c2e9._comment
 create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_9_3784e0c828cd60b6a9075c2d32d070cc._comment
 create mode 100644 doc/tips/get_git-annex-shell_into_PATH.mdwn
 create mode 100644 doc/tips/git-annex_extensions_for_ranger__44___the_file_manager.mdwn
 create mode 100644 doc/tips/git-annex_extensions_for_ranger__44___the_file_manager/comment_1_358d4041c0158c247340cd4588286df4._comment
 create mode 100644 doc/tips/git-annex_on_NFS.mdwn
 create mode 100644 doc/tips/git-annex_on_NFS/comment_1_e2e99f2c484597c0d314ae597be078c3._comment
 create mode 100644 doc/tips/git-annex_on_NFS/comment_2_06f2ee5095cd35063a434560375e172e._comment
 create mode 100644 doc/tips/hashdeep_integration.mdwn
 create mode 100644 doc/tips/hiding_missing_files.mdwn
 create mode 100644 doc/tips/hiding_missing_files/comment_1_eba2b140f9d5a9f7ee23cb3ba7da7612._comment
 create mode 100644 doc/tips/hiding_missing_files/comment_2_9bff461eb281f67d169d4be30129bc13._comment
 create mode 100644 doc/tips/imapannex.mdwn
 create mode 100644 doc/tips/install_on_Android_in_Termux.mdwn
 create mode 100644 doc/tips/install_on_Android_in_Termux/comment_1_dc277facdcfba4e175831467b0e450d5._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments.mdwn
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_10_8c24553afc5352c8a4c9cd0555423325._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_11_8f5f8f47305b45dca53222ac0e3bde29._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_12_a7bbf9e61e2e993eca9a9222de899920._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_13_b46679eac8d4d86b2abe9baff1f0a609._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_14_20a995c941f9a3582a8913d412e3d090._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_15_387e69f3ed94a00c01b0a097132f989c._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_16_2d7181f765cdbf545f161825c4cfeca9._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_17_37ba50a8378b2ac3d920fc8155eea42a._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_18_c1b5fefdc9a654579d0ada3db7a40ad8._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_19_5e0aa7c4341867374a67f5fe0a242e00._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_1_320b1fa3328cf8b8e584e72a9cd7735a._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_20_9651ab0e1e43d193cca16963f5fde858._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_21_3d1c6a1dc4ff8f04dffa4a02ad56fef2._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_22_39e2f2100a49f986760db389cf10240b._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_2_3a8c8facaa8b2989c88ebaabb984c7de._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_2_663de2e553ea050dd5a00fc88aeb6412._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_4_338e7f1b0fdf273d5fa453fe8ed2578b._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_5_82c4de6ad0ff016e72133d2552b5158d._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_6_66bfd7ca3dd81bb7632cb91fd8637dae._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_7_b475d3c36cf6d52d6b4720d00a5ae245._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_8_35329178895fc03395f08a37044e7c94._comment
 create mode 100644 doc/tips/install_on_Android_in_Termux/old_comments/comment_9_7ae18460ca6201cc313215a8a03e0d57._comment
 create mode 100644 doc/tips/largefiles.mdwn
 create mode 100644 doc/tips/largefiles/comment_10_18f17926c44ea4b0c17a61a91c6bb5b5._comment
 create mode 100644 doc/tips/largefiles/comment_11_e7c83e38c92b8fc91bae140c1d7c007d._comment
 create mode 100644 doc/tips/largefiles/comment_13_16176199c4c98c66dd40b5eae95122ed._comment
 create mode 100644 doc/tips/largefiles/comment_13_b541d011d4c7f23227426c783a4bdc20._comment
 create mode 100644 doc/tips/largefiles/comment_14_2f8d8e73e4218b1e36e358770016cabe._comment
 create mode 100644 doc/tips/largefiles/comment_14_cd71d1c6e69a9fc7feadf9aa6a39c406._comment
 create mode 100644 doc/tips/largefiles/comment_15_d1f24df21ac577b89a8ae385532de6f2._comment
 create mode 100644 doc/tips/largefiles/comment_16_4c6f52958246757dfbedd0b410d43ffe._comment
 create mode 100644 doc/tips/largefiles/comment_17_066fdebc2655dd11077fda1ef6e102e4._comment
 create mode 100644 doc/tips/largefiles/comment_1_b84e5cb8316c30fc7b355234384a5899._comment
 create mode 100644 doc/tips/largefiles/comment_2_825b72391117f88062a585684cf62eeb._comment
 create mode 100644 doc/tips/largefiles/comment_3_f4df42fe943011cc8feb2921a59616e9._comment
 create mode 100644 doc/tips/largefiles/comment_4_b6380286f60c1cd46a82a2e90c7aa05f._comment
 create mode 100644 doc/tips/largefiles/comment_5_20c6702f83dbade1ac4d6eee30c40b4b._comment
 create mode 100644 doc/tips/largefiles/comment_6_639b1492271643566846b48fe13f7b8d._comment
 create mode 100644 doc/tips/largefiles/comment_7_35a634c5e6d780972b9e938065837988._comment
 create mode 100644 doc/tips/largefiles/comment_8_f036356b23a4690705a2b4df604e82ba._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files.mdwn
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_10_c93895a509ab4e458043450bccf930dc._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_11_5bf79eae24dd6b69daa1cd10e0b4d296._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_12_cbc8fbd8a98574683008ca363d3ac6b7._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_13_18514bbfab0ff0d8a70ce5b08436cd44._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_14_7afa02db922ef1ad9d4031a87e4b688c._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_15_a1ce74ef47a0512bc56ff323c2c03c75._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_16_3f4950f7dc51472b5f0405baeac187a0._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_17_d1f0d7ac76f704ea71c4971ee7ed0cde._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_18_6b21f1ed5a2cbbba7c7042dcfec080a8._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_19_490c15d7673c535e83c7f1df3082e7ed._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_1_ad1ab9d78cc0c45fcda54bf9f03b4f8f._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_20_af084d315d82c1bae85122939042305b._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_21_3776a0371faccc673c868323278f3b0d._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_22_b047ea1c6b9247a42b560a111d4fdeae._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_23_994f408b01fa09e80599538a4ff28485._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_2_d3ac760cfee0decfbcb4f81ddbc39a3f._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_3_2a80533f259cde64662db7e6a1c1742c._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_4_42906e52528907a0960ab8b08c2eedd4._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_5_dc1e5e3d256a2618f6c2a7864b01c08e._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_6_c0d79b07a4c83c9d081d7c8f702fa4dc._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_7_ffdf07bac38a6c29b799281441fd32c9._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_8_0e4571cc81ade6510b7a1ddfff9cb055._comment
 create mode 100644 doc/tips/local_caching_of_annexed_files/comment_9_7db7787a306c70ba3c1687c1d103608d._comment
 create mode 100644 doc/tips/making_a_remote_repo_update_when_changes_are_pushed_to_it.mdwn
 create mode 100644 doc/tips/mc_menu_integration.mdwn
 create mode 100644 doc/tips/megaannex.mdwn
 create mode 100644 doc/tips/megaannex/comment_1_eec701662debd2a78c48243dbcebf59a._comment
 create mode 100644 doc/tips/megaannex/comment_2_c1158b7ec15646d64cae8215ce845642._comment
 create mode 100644 doc/tips/metadata_driven_views.mdwn
 create mode 100644 doc/tips/metadata_driven_views/comment_1_1d6793701fd8a1a66bae04662cf853ce._comment
 create mode 100644 doc/tips/metadata_driven_views/comment_2_13ae4e3668b693c0eefaca23b88515cf._comment
 create mode 100644 doc/tips/metadata_driven_views/comment_3_196f55e52a5d8a8f061603ab87ad04ad._comment
 create mode 100644 doc/tips/migrating_data_to_a_new_backend.mdwn
 create mode 100644 doc/tips/migrating_two_seperate_disconnected_directories_to_git_annex.mdwn
 create mode 100644 doc/tips/migrating_two_seperate_disconnected_directories_to_git_annex/comment_1_d94ae69945416e57faa6e6dd5536f66e._comment
 create mode 100644 doc/tips/migrating_two_seperate_disconnected_directories_to_git_annex/comment_2_c6c11a9d5f9f136fa541404cdc49f45c._comment
 create mode 100644 doc/tips/multiple_remotes_accessing_the_same_data_store.mdwn
 create mode 100644 doc/tips/offline_archive_drives.mdwn
 create mode 100644 doc/tips/offline_archive_drives/comment_1_3d4fdf42191a9d81434d00f51c3609ff._comment
 create mode 100644 doc/tips/offline_archive_drives/comment_2_864c752aa8d064791a4b14dbbe2e6882._comment
 create mode 100644 doc/tips/offline_archive_drives/comment_3_7be2ccaf70c9ecfc9a34384e0e31f490._comment
 create mode 100644 doc/tips/offline_archive_drives/comment_4_f9f2f8c59818d3d48475fa3cbf339ba3._comment
 create mode 100644 doc/tips/offline_archive_drives/comment_5_25c92a3602a1365d68e6bab080e4a41d._comment
 create mode 100644 doc/tips/offline_archive_drives/comment_6_f64f48f2bb5325bf9e14e2aa96a94429._comment
 create mode 100644 doc/tips/offline_archive_drives/comment_7_c8b506c4b2da98be430016e219680e34._comment
 create mode 100644 doc/tips/owncloudannex.mdwn
 create mode 100644 doc/tips/owncloudannex/comment_1_129652308c3c499462828dcaf8e747a4._comment
 create mode 100644 doc/tips/owncloudannex/comment_2_38604990368666f654d41891ba99ac61._comment
 create mode 100644 doc/tips/owncloudannex/comment_3_1bfd290d00d6536da7d31818db46f8ec._comment
 create mode 100644 doc/tips/owncloudannex/comment_4_492b6922a7c5bb5464fedb46b0c5303b._comment
 create mode 100644 doc/tips/owncloudannex/comment_5_1d48ac08714fadcb06d874570d745bd8._comment
 create mode 100644 doc/tips/owncloudannex/comment_6_65959f49a2f56bffd6fe48670c0c8d5a._comment
 create mode 100644 doc/tips/owncloudannex/comment_7_7482002991672ef67836bae43b8d0be8._comment
 create mode 100644 doc/tips/owncloudannex/comment_8_6579203d726f4a39db02fcdda156e12c._comment
 create mode 100644 doc/tips/owncloudannex/comment_9_e52582d76e9b57cc11791f2730389605._comment
 create mode 100644 doc/tips/peer_to_peer_network_with_tor.mdwn
 create mode 100644 doc/tips/peer_to_peer_network_with_tor/comment_1_72d4ea5ffa23f5048c453c2e7510e2f0._comment
 create mode 100644 doc/tips/peer_to_peer_network_with_tor/comment_2_8180e202fc493ad07999a3367ccd9425._comment
 create mode 100644 doc/tips/peer_to_peer_network_with_tor/comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment
 create mode 100644 doc/tips/peer_to_peer_network_with_tor/comment_4_917eee70600e13470f70555abe06597d._comment
 create mode 100644 doc/tips/peer_to_peer_network_with_tor/comment_5_6db70bb9266a92e249587bc4d095c472._comment
 create mode 100644 doc/tips/playlist_fetch.mdwn
 create mode 100644 doc/tips/playlist_fetch/comment_1_5310fd53406d35f36deff68e8c2cb599._comment
 create mode 100644 doc/tips/powerful_file_matching.mdwn
 create mode 100644 doc/tips/public_Amazon_S3_remote.mdwn
 create mode 100644 doc/tips/public_Amazon_S3_remote/comment_1_a2684b49dbc2de45b644523f47b3c891._comment
 create mode 100644 doc/tips/public_Amazon_S3_remote/comment_2_f155c3aa054a23df1ab057baaa300a62._comment
 create mode 100644 doc/tips/publishing_your_files_to_the_public.mdwn
 create mode 100644 doc/tips/publishing_your_files_to_the_public/comment_1_40f690c59de96159da96855c61bb5963._comment
 create mode 100644 doc/tips/publishing_your_files_to_the_public/comment_2_0287fd56eea34fcd5831768252335a7b._comment
 create mode 100644 doc/tips/publishing_your_files_to_the_public/comment_3_4ae6d6c5137e5f9b667417c2c77fca85._comment
 create mode 100644 doc/tips/publishing_your_files_to_the_public/comment_4_33b50a2de3f1268c875fc388a85c0296._comment
 create mode 100644 doc/tips/publishing_your_files_to_the_public/comment_5_3216edeefa99f484194d6de061283170._comment
 create mode 100644 doc/tips/publishing_your_files_to_the_public/comment_6_06cba66922cc382c112fdac52b98bb4d._comment
 create mode 100644 doc/tips/publishing_your_files_to_the_public/comment_7_caf9ad71e3805347df98f4d6df352cec._comment
 create mode 100644 doc/tips/publishing_your_files_to_the_public/old_method.mdwn
 create mode 100644 doc/tips/publishing_your_files_to_the_public/old_method/comment_1_48f545ce26dbec944f96796ed3b9204d._comment
 create mode 100644 doc/tips/publishing_your_files_to_the_public/old_method/comment_2_27a40806d009d617b3ad56873197bf87._comment
 create mode 100644 doc/tips/publishing_your_files_to_the_public/old_method/comment_3_2f5045629e40e8d881725876190c7846._comment
 create mode 100644 doc/tips/publishing_your_files_to_the_public/old_method/comment_4_37405f20da790141187e9f780c999448._comment
 create mode 100644 doc/tips/publishing_your_files_to_the_public/old_method/comment_5_29c3ee4aed6a5b53b6767a96a7b85ad9._comment
 create mode 100644 doc/tips/recover_data_from_lost+found.mdwn
 create mode 100644 doc/tips/recover_data_from_lost+found/comment_1_f0901527a4f0faf0b1fd916d5b809314._comment
 create mode 100644 doc/tips/recover_data_from_lost+found/comment_2_ac405575058beeac992d07c55f7c53a8._comment
 create mode 100644 doc/tips/recover_data_from_lost+found/comment_3_02cb9efd54d8447d0bd11e5981e7dca7._comment
 create mode 100644 doc/tips/recover_data_from_lost+found/comment_4_960fcfe8c5c7bcb7350f61ecfb84f36c._comment
 create mode 100644 doc/tips/recover_data_from_lost+found/comment_5_e887b2d2ecbce3de22c517afd500e783._comment
 create mode 100644 doc/tips/recovering_from_a_corrupt_git_repository.mdwn
 create mode 100644 doc/tips/recovering_from_a_corrupt_git_repository/comment_1_f5827be97f78dbae113a5ba0c9ced896._comment
 create mode 100644 doc/tips/recovering_from_a_corrupt_git_repository/comment_2_e98df7275bb032308bb87e3607bdde32._comment
 create mode 100644 doc/tips/recovering_from_a_corrupt_git_repository/comment_3_11bece6dfac090edbcd783b266c482a3._comment
 create mode 100644 doc/tips/recovering_from_a_corrupt_git_repository/comment_4_86e99017f7585ac2f76753051214637e._comment
 create mode 100644 doc/tips/recovering_from_a_corrupt_git_repository/comment_6_c8953732ce353cdf0c4fb81ddc98c04a._comment
 create mode 100644 doc/tips/recovering_from_a_corrupt_git_repository/comment_6_d0da84df0241dc6ccf0aa0c7598917df._comment
 create mode 100644 doc/tips/recovering_from_a_corrupt_git_repository/comment_7_addf49556e4c33d55a41c393f519d0a4._comment
 create mode 100644 doc/tips/recovering_from_a_corrupt_git_repository/comment_8_505a2fc2b841fe8eb419801f923ef35f._comment
 create mode 100644 doc/tips/redacting_history_by_converting_git_files_to_annexed.mdwn
 create mode 100644 doc/tips/redacting_history_by_converting_git_files_to_annexed/comment_1_aece062800c6ed78988161d40e36bba4._comment
 create mode 100644 doc/tips/redacting_history_by_converting_git_files_to_annexed/comment_2_6b682415956756b969767f7de267f1f0._comment
 create mode 100644 doc/tips/redacting_history_by_converting_git_files_to_annexed/comment_3_7e92db3d8a392e43b305fa8ecc0e39d3._comment
 create mode 100644 doc/tips/remote_webapp_setup.mdwn
 create mode 100644 doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant.mdwn
 create mode 100644 doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_10_d1bd5d6b33951f6d11185bb4a8228269._comment
 create mode 100644 doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_11_54692ebf854ecbcc5314bb29c33ecc66._comment
 create mode 100644 doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_1_907e4032ca4a39adb846cf16dbf447dc._comment
 create mode 100644 doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_2_902d001ba86657ef0f8cca5b175f99ca._comment
 create mode 100644 doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_3_a1cf93f9b29658f0f26e9e0ae6057ee3._comment
 create mode 100644 doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_4_e10671908b58c554375787d0f76e2366._comment
 create mode 100644 doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_5_4114380f66b6376c851e93f6876d590b._comment
 create mode 100644 doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_6_6a5d6af107b297afd008b021f73d787b._comment
 create mode 100644 doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_7_74d57cf503a86d8f7ace2d769dbb58be._comment
 create mode 100644 doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_8_85765c0cfeb5b326c06cf60c98147cbf._comment
 create mode 100644 doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_9_082b5d90ffc836e7c86e40b63a75780d._comment
 create mode 100644 doc/tips/semi-synchronized_remotes.mdwn
 create mode 100644 doc/tips/semi-synchronized_remotes/comment_1_d0459d72b7e0441fe833a5c8e1588a4f._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site.mdwn
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_10_5554d52c568fdd5235c498ba999545cb._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_11_5fc7b153f1822c8ae2d415963fcb9ce2._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_12_eb732e9c1c44942bc313aa1ab3ff56fc._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_13_4332e21dcbe4fdcbab58f01aca295fc9._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_1_1d0fa6da33e401df1d7ff31979247fec._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_2_b98b761dee9d923153e3c288c1d987ee._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_3_a6698218f15c598c9b32e0af850133bf._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_4_e20ea0dc04d4d62b699271483f81a136._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_5_0bb7c62b71d2c9da6fbfe8f889baff38._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_6_89eac454cfbdffabb916355b355e1b94._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_7_6015b7ad6a19f412d0b50bfb3a661fe2._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_8_ceb528ff60b9c7544eae28292ef74ddb._comment
 create mode 100644 doc/tips/setup_a_public_repository_on_a_web_site/comment_9_2dfb5b225ed62c0310ddadb0d83ceb79._comment
 create mode 100644 doc/tips/shared_git_annex_directory_between_multiple_users.mdwn
 create mode 100644 doc/tips/shared_git_annex_directory_between_multiple_users/comment_1_01db8cf9dff016bd8e0498d36f325418._comment
 create mode 100644 doc/tips/shared_git_annex_directory_between_multiple_users/comment_2_07ad0b2f6fd2644241a605a10d8fb8d0._comment
 create mode 100644 doc/tips/shared_git_annex_directory_between_multiple_users/comment_3_3bfb9e0e028f71c8a47e5363dcfdbd36._comment
 create mode 100644 doc/tips/skydriveannex.mdwn
 create mode 100644 doc/tips/skydriveannex/comment_10_c3465b5587548dea56b80b32cd66d653._comment
 create mode 100644 doc/tips/skydriveannex/comment_11_13692d8cb9ccf10ced26d90739385a6a._comment
 create mode 100644 doc/tips/skydriveannex/comment_1_bf383481b2bbb962fbfe783b9f2f213a._comment
 create mode 100644 doc/tips/skydriveannex/comment_2_1f747018b35ab8accd2bf0905e6ad926._comment
 create mode 100644 doc/tips/skydriveannex/comment_3_8b9444006734262693f71e50a40eae1d._comment
 create mode 100644 doc/tips/skydriveannex/comment_4_8b01dc6ca1082a8c24ff65fec9d759d8._comment
 create mode 100644 doc/tips/skydriveannex/comment_5_1d220d96945d497f3a93b5d848eb3995._comment
 create mode 100644 doc/tips/skydriveannex/comment_6_a7a3afdc7eed9a0eda48dcb57f1e87c6._comment
 create mode 100644 doc/tips/skydriveannex/comment_7_7fcd9c6b5e2a3fc7b753eeac06164036._comment
 create mode 100644 doc/tips/skydriveannex/comment_8_856eaa1b167033aede91a937099c7833._comment
 create mode 100644 doc/tips/skydriveannex/comment_9_cfcf767a1bf07957b76d7f44ef8a9500._comment
 create mode 100644 doc/tips/splitting_a_repository.mdwn
 create mode 100644 doc/tips/splitting_a_repository/comment_1_654527ef2350fe871e2d7ff6addc6713._comment
 create mode 100644 doc/tips/splitting_a_repository/comment_2_2437e95397e1b06ade5360405e399591._comment
 create mode 100644 doc/tips/splitting_a_repository/comment_3_c0ccbf6758eabf645075d3b84188825e._comment
 create mode 100644 doc/tips/splitting_a_repository/comment_4_fbf9d86fd3aee4542a7cabacce9578cd._comment
 create mode 100644 doc/tips/splitting_a_repository/comment_5_baf4871cb78b337c627a352333c4e39d._comment
 create mode 100644 doc/tips/splitting_a_repository/comment_6_ce243a141a286e5e1a55af8321238b5c._comment
 create mode 100644 doc/tips/splitting_a_repository/comment_7_0d11c72712da0cf36b8cc91ba7501d52._comment
 create mode 100644 doc/tips/splitting_a_repository/comment_8_72ebd848d406190e12e3291cff824f7e._comment
 create mode 100644 doc/tips/storing_data_in_git-lfs.mdwn
 create mode 100644 doc/tips/storing_data_in_git-lfs/comment_1_e4eb406a4bf146c1f442047a4c1b1e1a._comment
 create mode 100644 doc/tips/transmission_integration.mdwn
 create mode 100644 doc/tips/transmission_integration/transmission_integration.sh
 create mode 100644 doc/tips/unlocked_files.mdwn
 create mode 100644 doc/tips/unlocked_files/comment_10_add35d419c7735571208aa5e47437f99._comment
 create mode 100644 doc/tips/unlocked_files/comment_11_08102655fbb13e4977e82f3f097f28db._comment
 create mode 100644 doc/tips/unlocked_files/comment_12_8cd7855dc6419297174a32e847e5f49a._comment
 create mode 100644 doc/tips/unlocked_files/comment_13_99f82c84aa9d886062aa3e3956e1acf8._comment
 create mode 100644 doc/tips/unlocked_files/comment_14_e3425d219001fc34470f0cd55fc7241e._comment
 create mode 100644 doc/tips/unlocked_files/comment_15_4be14df022612d6301442b3210a17d0a._comment
 create mode 100644 doc/tips/unlocked_files/comment_16_61121c6b95e1310df8132aca13924b88._comment
 create mode 100644 doc/tips/unlocked_files/comment_17_15c6f8db289812e76859b21d158b1b2e._comment
 create mode 100644 doc/tips/unlocked_files/comment_1_29cef6b8e48e722fafed3fe9b7cefe08._comment
 create mode 100644 doc/tips/unlocked_files/comment_2_54a1811ef2f57f0843e48572ab6713b8._comment
 create mode 100644 doc/tips/unlocked_files/comment_3_f5f29661bd04a6bba6158307465981d9._comment
 create mode 100644 doc/tips/unlocked_files/comment_4_a8139747da8cbb2510b3647ba448d72d._comment
 create mode 100644 doc/tips/unlocked_files/comment_5_8225cb96640697d4955badfee5b75e39._comment
 create mode 100644 doc/tips/unlocked_files/comment_6_666d88b862a7f6f5cd719e454a8a6469._comment
 create mode 100644 doc/tips/unlocked_files/comment_7_46ff6b142c4cc9ad07b0c8dc07ba9c09._comment
 create mode 100644 doc/tips/unlocked_files/comment_8_9e5d1a9523239cb601612951af5eb9f1._comment
 create mode 100644 doc/tips/unlocked_files/comment_9_1cfd5f680f2d19ea1039ff0e7324083f._comment
 create mode 100644 doc/tips/untrusted_repositories.mdwn
 create mode 100644 doc/tips/using_Amazon_Glacier.mdwn
 create mode 100644 doc/tips/using_Amazon_Glacier/comment_1_ccee7f4f5a483a3650270b6e09ab7293._comment
 create mode 100644 doc/tips/using_Amazon_Glacier/comment_2_d34e05f9244d3a4fcec87b3c360adb4e._comment
 create mode 100644 doc/tips/using_Amazon_Glacier/comment_3_4c504fd22775afe36296cf54d3e04a8e._comment
 create mode 100644 doc/tips/using_Amazon_Glacier/comment_4_e6ac76b0c20285f4f96b3d0975e8ac66._comment
 create mode 100644 doc/tips/using_Amazon_Glacier/comment_5_7788890f58f714b0cdf1462c718ea536._comment
 create mode 100644 doc/tips/using_Amazon_Glacier/comment_6_0fbe528a57552622e8128196ad80c863._comment
 create mode 100644 doc/tips/using_Amazon_Glacier/comment_7_a83cfe55f4c70bd8801e0c05c5be8323._comment
 create mode 100644 doc/tips/using_Amazon_Glacier/comment_8_ddef6cc5d1a5fd3d69cfe8cccfa58a53._comment
 create mode 100644 doc/tips/using_Amazon_S3.mdwn
 create mode 100644 doc/tips/using_Amazon_S3/comment_10_43f3f12a83e3ace1674eae395b865409._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_11_70b4e62aabb93d078811cbdcd3cced20._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_12_d00472bf4ac5f7b2212073c081ba04c2._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_13_30bdbd217fd2b603984cf7d3a3dce266._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_14_5bb12e6fa51da00ecf48f2dee1bfb050._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_15_d8cc20706debc17f4f738d2019577dea._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_16_bb2cb128d9c6a8e9176604cef1f6fc91._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_1_666a26f95024760c99c627eed37b1966._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_2_f5a0883be7dbb421b584c6dc0165f1ef._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_3_32acba030c2ad252e2f7027075e4303e._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_4_92df5a9f923beafba55a1c455728112e._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_5_6b288e06010bedbb71e0afed6b427704._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_6_3b6c74b40ea666389ac04b52ab0819a0._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_7_cf6755d88463878f2ea6e4c300899027._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_8_4f9c2f6627f8ed3423bcc8b7bf2f76cb._comment
 create mode 100644 doc/tips/using_Amazon_S3/comment_9_47e4ea77d0262d332d86a06d7aaeddd8._comment
 create mode 100644 doc/tips/using_Backblaze_B2.mdwn
 create mode 100644 doc/tips/using_Backblaze_B2/comment_1_b8b045d5f3d2bed1905c05b4fa00c5ca._comment
 create mode 100644 doc/tips/using_Backblaze_B2/comment_2_d7fd727cb38a0290de10f06539a23d27._comment
 create mode 100644 doc/tips/using_Google_Cloud_Storage.mdwn
 create mode 100644 doc/tips/using_Google_Cloud_Storage/comment_1_c576182f39563ae68767391c4227a177._comment
 create mode 100644 doc/tips/using_Google_Cloud_Storage/comment_2_0843bfb776b8b6d5de4de7fda4489f34._comment
 create mode 100644 doc/tips/using_Google_Cloud_Storage/comment_3_9738f145014d8eae1f1aae7c39e71d31._comment
 create mode 100644 doc/tips/using_Google_Cloud_Storage/comment_4_63f29692ef270cd4a196ec94ff97185a._comment
 create mode 100644 doc/tips/using_Google_Cloud_Storage/comment_5_865f27a393f24fd5723c895d4d70dde3._comment
 create mode 100644 doc/tips/using_Google_Cloud_Storage/comment_6_d1462d9d1d425e609bf8ad8fb8f0a9d5._comment
 create mode 100644 doc/tips/using_Google_Cloud_Storage/comment_7_6896ea720bb29db35db4c5e2463fa818._comment
 create mode 100644 doc/tips/using_Google_Cloud_Storage/comment_8_1b4eb7e0f44865cd5ff0f8ef507d99c1._comment
 create mode 100644 doc/tips/using_Google_Drive.mdwn
 create mode 100644 doc/tips/using_Hubic.mdwn
 create mode 100644 doc/tips/using_borg_for_efficient_storage_of_old_annexed_files.mdwn
 create mode 100644 doc/tips/using_box.com_as_a_special_remote.mdwn
 create mode 100644 doc/tips/using_box.com_as_a_special_remote/comment_1_be39f063e8a6155cc2eb71829e884a63._comment
 create mode 100644 doc/tips/using_git-annex_from_your_program.mdwn
 create mode 100644 doc/tips/using_git_annex_with_no_fixed_hostname_and_optimising_ssh.mdwn
 create mode 100644 doc/tips/using_git_annex_with_no_fixed_hostname_and_optimising_ssh/comment_1_c0b7682a2b6f3078457b85683c825baf._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex.mdwn
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_10_8767bc8014b459a3cd76f275fd4fa8d6._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_11_00715e0b47f09130e0e536e29f7b9258._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_12_7027ce60265b8f24c8ab54553e544068._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_13_75218b7409c0e281cb01c9b2791e8cdf._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_14_7d4d4515218d1259d32be3baeb5ee56e._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_15_dc6f21b5a3d5931c8d949a9753411b9e._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_16_8e5039e6655fc80dc863b6cdf44ef02a._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_17_9c40e1da8bb44f7207e802377f5cf923._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_18_f1a180d5cf65b7a870a13ddb4f76d00d._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_19_33c19097b6f2b48dfe09ec4c8d952d06._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_1_9a2a2a8eac9af97e0c984ad105763a73._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_20_c82af00db3dd74ee9bfe12668e76e57b._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_21_d2feaaf22d41413048dabf706d1b267e._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_22_90ead0e1fe8615fe11f6f1bd7dcd7e84._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_23_70dcb7e7ffdd14351adaf4c40ee7fdd0._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_24_a62f59295b3912dc38def5e493bdb55a._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_25_08b3b257b3dbd32cb807e29f512ea9c9._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_2_d8efea4ab9576555fadbb47666ecefa9._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_3_807035f38509ccb9f93f1929ecd37417._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_4_eb81f824aadc97f098379c5f7e4fba4c._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_5_f688309532d2993630e9e72e87fb9c46._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_6_3e203e010a4df5bf03899f867718adc5._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_7_f8fd08b6ab47378ad88c87348057220d._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_8_8249772c142117f88e37975d058aa936._comment
 create mode 100644 doc/tips/using_gitolite_with_git-annex/comment_9_28418635a6ed7231b89e02211cd3c236._comment
 create mode 100644 doc/tips/using_nested_git_repositories.mdwn
 create mode 100644 doc/tips/using_nested_git_repositories/comment_1_cd7f673de1c39d2f37d9958357d5e72d._comment
 create mode 100644 doc/tips/using_nested_git_repositories/comment_2_63f30b652c0cbdb0acf6745891f9f09e._comment
 create mode 100644 doc/tips/using_nested_git_repositories/comment_3_029571d8331ba2dcf0b149d071fef75c._comment
 create mode 100644 doc/tips/using_nested_git_repositories/comment_4_3c701a4c6789fc6c73f71217e7ed8c65._comment
 create mode 100644 doc/tips/using_signed_git_commits.mdwn
 create mode 100644 doc/tips/using_signed_git_commits/comment_1_82241dc5666e1b573a24b3e84f3991ae._comment
 create mode 100644 doc/tips/using_signed_git_commits/comment_2_5fb568fcd3aa376d2ee36c660a4a02a2._comment
 create mode 100644 doc/tips/using_signed_git_commits/comment_3_3edce6f128e96e1156601c6136118427._comment
 create mode 100644 doc/tips/using_signed_git_commits/comment_4_5ad0596373cc363ec9bc0b69efbac03c._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote.mdwn
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_11_9889828caa47aad88267d0ec35f2240d._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_12_1704dcd7fc94432af5aa18459495c9ab._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_12_2ce018f181e039b5dd52e2b712f63eea._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_13_39122e2587f84633fda262bfc9d076eb._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_14_3a923511cf20d816b468044c03eb171f._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_15_8981dfd222cbf349bac3d74f53675fde._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_1_321a41d611c6fe45e047af9c96c5176c._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_2_dfe9c8c49aadff80d2020288584e0390._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_3_ed8dd3bbd9b9ae7f2309b72b94f61eb1._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_4_c1133a524989a940f1b5db588707157a._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_5_5ee9717e74ca2afed98e81fc0ea98a95._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_6_dceb15bd656e69eefa3ca975d9d642de._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_7_0bde977c62a53c90cb20491936bc399d._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_8_3f32d536f51d5e9908953caf5736b0a0._comment
 create mode 100644 doc/tips/using_the_web_as_a_special_remote/comment_9_b420b1f320d620a9909cce5086c549bf._comment
 create mode 100644 doc/tips/visualizing_repositories_with_gource.mdwn
 create mode 100644 doc/tips/visualizing_repositories_with_gource/comment_1_01c5cd21375990c612b8f291904ddb3e._comment
 create mode 100644 doc/tips/visualizing_repositories_with_gource/screenshot.jpg
 create mode 100644 doc/tips/what_to_do_when_a_repository_is_corrupted.mdwn
 create mode 100644 doc/tips/what_to_do_when_a_repository_is_corrupted/comment_1_c3543190eae2af594f3e050057e80db6._comment
 create mode 100644 doc/tips/what_to_do_when_a_repository_is_corrupted/comment_2_025178c2b11affe2d42a87544b897dc8._comment
 create mode 100644 doc/tips/what_to_do_when_a_repository_is_corrupted/comment_3_9a6bae9c0326ecc7610f5415db20f49e._comment
 create mode 100644 doc/tips/what_to_do_when_a_repository_is_corrupted/comment_4_d4178d99179e8761162c74673042e28a._comment
 create mode 100644 doc/tips/what_to_do_when_a_repository_is_corrupted/comment_5_9b3738aa678015a58f30a22baa2012df._comment
 create mode 100644 doc/tips/what_to_do_when_a_repository_is_corrupted/comment_6_0e3224af10362a10aa1c8786423960a9._comment
 create mode 100644 doc/tips/what_to_do_when_you_lose_a_repository.mdwn
 create mode 100644 doc/tips/what_to_do_when_you_lose_a_repository/comment_1_cf19b8dc304dc37c26717174c4a98aa4._comment
 create mode 100644 doc/tips/what_to_do_when_you_lose_a_repository/comment_3_fa9ca81668f5faebf2f61b10f82c97d2._comment
 create mode 100644 doc/tips/what_to_do_when_you_lose_a_repository/comment_3_fdcfca8707e310ca7bb94d359adf8607._comment
 create mode 100644 doc/tips/what_to_do_when_you_lose_a_repository/comment_4_679eb9be0bfb9d48a2b96383c4816f62._comment
 create mode 100644 doc/tips/what_to_do_when_you_lose_a_repository/comment_5_4fb04b70d88ec93ff9ed4f884747d5d4._comment
 create mode 100644 doc/tips/what_to_do_when_you_lose_a_repository/comment_6_05db504cbff2ec2a6346bf43e57a3c25._comment
 create mode 100644 doc/tips/what_to_do_when_you_lose_a_repository/comment_7_4e6baa41bfee6edf2b17d4ade2909c7b._comment
 create mode 100644 doc/tips/what_to_do_when_you_lose_a_repository/comment_8_596bcfa25a4fa6e81bb6a0940c55a2f2._comment
 create mode 100644 doc/tips/what_to_do_when_you_lose_a_repository/comment_9_525e58e5941220b23b0ed73fa7611db1._comment
 create mode 100644 doc/tips/yet_another_simple_disk_usage_like_utility.mdwn
 create mode 100644 doc/tips/yet_another_simple_disk_usage_like_utility/comment_1_41b212bde8bc88d2a5dea93bd0dc75f1._comment
 create mode 100644 doc/tips/yet_another_simple_disk_usage_like_utility/comment_2_73698913837bfd5a58cf15721211e43e._comment
 create mode 100644 doc/todo.mdwn
 create mode 100644 doc/todo/--batch_for_add.mdwn
 create mode 100644 doc/todo/--batch_for_add/comment_1_b1362c86e162a49717d7e3b0816025ba._comment
 create mode 100644 doc/todo/--batch_for_find.mdwn
 create mode 100644 doc/todo/--batch_for_find/comment_1_d164ad661617d29cb1ceb3d6fc3bb37f._comment
 create mode 100644 doc/todo/--batch_for_find/comment_2_9873396186f4d24088fd746f42373678._comment
 create mode 100644 doc/todo/--batch_for_find/comment_3_598a0500a3a4573c50a559d1931f1918._comment
 create mode 100644 doc/todo/--batch_for_find/comment_4_830cf616968e25cee8e7d35f9709f79b._comment
 create mode 100644 doc/todo/--batch_for_info.mdwn
 create mode 100644 doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex.mdwn
 create mode 100644 doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_1_58e729e2fa58b28d247eeda579bb9329._comment
 create mode 100644 doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_2_66a32cef4ff6bc93ad04346612f543ec._comment
 create mode 100644 doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_3_ea60112be683188e43b27942667ddd77._comment
 create mode 100644 doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_4_03cd162638a9b4f2b7981cee141693f6._comment
 create mode 100644 doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_5_f27efaef3d9cb8db3de9dd42df252059._comment
 create mode 100644 doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_6_d9014e7e964f47a4fdc680ffc53e17b8._comment
 create mode 100644 doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_7_5ae9913b8b9a9fe443c211976adce002._comment
 create mode 100644 doc/todo/--get_option_for_diffdriver.mdwn
 create mode 100644 doc/todo/--get_option_for_diffdriver/comment_1_6b2501b2dc0318242e444e8d4b8b314f._comment
 create mode 100644 doc/todo/--get_option_for_diffdriver/comment_2_cb4eb05f447a214353a5bd5c29d207d0._comment
 create mode 100644 doc/todo/--json_for_registerurl.mdwn
 create mode 100644 doc/todo/--json_for_registerurl/comment_1_68fd330b6f20ef2d56234a639a5323c4._comment
 create mode 100644 doc/todo/--json_for_unannex__and_ideally_any_other_command_.mdwn
 create mode 100644 doc/todo/--json_for_unannex__and_ideally_any_other_command_/comment_1_9cc7829b4742f21077a27caad7ae638e._comment
 create mode 100644 doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison.mdwn
 create mode 100644 doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_1_e2da4d1fceb5f7c37e3c19d42256c8d5._comment
 create mode 100644 doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_2_38c46dee95ef2f246cd403717faaaa09._comment
 create mode 100644 doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_3_9c298fbda8d395fe9b8395105708c3bd._comment
 create mode 100644 doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_4_b8f2602e633dae4c85f89c97c8f03d81._comment
 create mode 100644 doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_5_afba02fb24eddc6569dce63ffe606dcf._comment
 create mode 100644 doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__.mdwn
 create mode 100644 doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_1_7815551c0ec6d933ae5537e28fb183ad._comment
 create mode 100644 doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_2_2debe0cb11763f0673255cfd7f764815._comment
 create mode 100644 doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_3_b559ac06e7fc622b8bbb5e73d4cc0930._comment
 create mode 100644 doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_4_8cb8cdef0cc563714d7bc7d91743762b._comment
 create mode 100644 doc/todo/Adding_a_matcher_for___39__recently_touched_files__39__.mdwn
 create mode 100644 doc/todo/Adding_a_matcher_for___39__recently_touched_files__39__/comment_1_bcb54e40904b04006dd7f8962add6994._comment
 create mode 100644 doc/todo/Adding_unmatched_files_to_a_view.mdwn
 create mode 100644 doc/todo/Adding_unmatched_files_to_a_view/comment_1_dee34c34b2df1d430a4f6c2792d35e28._comment
 create mode 100644 doc/todo/Adding_unmatched_files_to_a_view/comment_2_271f37d6c3e0f61324f9f50cb9cf24c7._comment
 create mode 100644 doc/todo/Adding_unmatched_files_to_a_view/comment_3_2e2a15ffc429db4b09215e7a7118e502._comment
 create mode 100644 doc/todo/Adressing_.gitattributes_inefficiency.mdwn
 create mode 100644 doc/todo/Adressing_.gitattributes_inefficiency/comment_1_335b8d3c5a903c1e83a7f84b7bfc2998._comment
 create mode 100644 doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from.mdwn
 create mode 100644 doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_1_9f4245bd016f9283464a25698563786c._comment
 create mode 100644 doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_2_34d1eab194b7913dd453131d9187287a._comment
 create mode 100644 doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_3_f667aa26dadadede318d31176292102d._comment
 create mode 100644 doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_4_16d30e86132d6a3cefaa8e2fecbda7ca._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote.mdwn
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_10_ff4c23b4ccaf649a9914f4aa4435968d._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_11_a7087acb84b3139418c597496e18f4a1._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_12_69e39ee8140ef0cafd1b0f21be6a8d37._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_13_afb7fb3750e3b16bf144c52ffc68c153._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_1_f2172080e8e3e324a739d8769dca2ed0._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_2_1ab2634c8a7058c5aa09f1ba72be3471._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_3_6970e60b7d826beb025fda452cc1bc13._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_4_8fe7f4c03784f519fd184e6d59fb0b2a._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_5_4d8e8abe8b31174ccc536387a96b0228._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_6_b6261ff8e442ee6df79834844f6b3565._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_7_50516fc4b3c315a9e5d771777fb27e9f._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_8_87ad54a694bde70713e71acd4e074894._comment
 create mode 100644 doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_9_4029b264ea2b0d47e6949f832af69282._comment
 create mode 100644 doc/todo/Allow_globally_limiting_filename_length.mdwn
 create mode 100644 doc/todo/Allow_remote_sync__42___and_ignore__42___in_git_annex_config.mdwn
 create mode 100644 doc/todo/Allow_remote_sync__42___and_ignore__42___in_git_annex_config/comment_1_7a55c03691a6b6738d1a0e2555cb4cea._comment
 create mode 100644 doc/todo/Android__58___add_a___34__Share_via__34___shortcut___34__Add_to_Annex__34__.mdwn
 create mode 100644 doc/todo/Android__58___add_a___34__Share_via__34___shortcut___34__Add_to_Annex__34__/comment_1_286279b96fc7940c9e7eeb0eb57cc279._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__.mdwn
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_10_41cf16d6d14d1551c43736f854da3d05._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_11_2ad0467b36d7e7be3b346dd54ba4f46b._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_12_70c4c9f6c35acd7ca1134ac74356e5be._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_13_440624874dd3697dd538655765f2b6a2._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_14_cf70ca1f6dac58c44ee3ece2199d25a9._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_15_06641815750038a0ed908d929868c1c3._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_16_adf57675c5fa1047ee48b16dd356f4fe._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_17_c41b669837be95b731bd68f1b3269fef._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_18_4e1e8fd89ea9be43d89e72562236c979._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_19_b34a9cf4114ed943fe4ba2de78eb0bbc._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_1_94395a48d99e4737dd0ee28a597bfe70._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_20_e9a36e9600561201969c4d21499833af._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_21_8f5dd9ba761e636ce5413da4e596296d._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_2_bd7c278922a52004540db79099e35763._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_3_c3f029b865bcd489d03bcf722dfa4e44._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_4_2cb31617bb7003c5bf0e5def358da0e4._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_5_2aab5c685ad934486e60065b3c8da1bf._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_6_a5089531b5d9bdcc90a07cb9d3f1da7d._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_6_e2718b6492d5da64a8bd6b13ad1cfa45._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_7_71d3936dc37349392e6f7b0bd8292b7b._comment
 create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_9_7ada8d7e9438f2740b700e2e54b045da._comment
 create mode 100644 doc/todo/Bidirectional_metadata.mdwn
 create mode 100644 doc/todo/Bidirectional_metadata/comment_1_9974d17e407fab14b12399016d3d66c2._comment
 create mode 100644 doc/todo/Bidirectional_metadata/comment_2_c791aca6da2bb1be70991bc1a76982a4._comment
 create mode 100644 doc/todo/Bittorrent-like_features.mdwn
 create mode 100644 doc/todo/Bittorrent-like_features/comment_1_f4c110ef35ebf4fd89f06edf2c4f0c48._comment
 create mode 100644 doc/todo/Bittorrent-like_features/comment_2_83148bd5c5c5e6c2eff3ad6e1d4fb82c._comment
 create mode 100644 doc/todo/Bittorrent-like_features/comment_3_84f149b30de1562593623aa23dc0396c._comment
 create mode 100644 doc/todo/Bittorrent-like_features/comment_4_7c54c83e582c0d4848aaf3d70e312707._comment
 create mode 100644 doc/todo/Bittorrent-like_features/comment_5_194dd0e8404ea72af9fb6ff34b994998._comment
 create mode 100644 doc/todo/Bittorrent-like_features/comment_6_489505da4143fb1c2bf21e7af695cdef._comment
 create mode 100644 doc/todo/CHECKPRESENT-MULTI.mdwn
 create mode 100644 doc/todo/CHECKPRESENT-MULTI/comment_1_181a908a9f77a4c51d1d09f1aff526b7._comment
 create mode 100644 doc/todo/CHECKPRESENT-MULTI/comment_2_87857aeaf45927846cde8cea70f9e6f4._comment
 create mode 100644 doc/todo/CHECKPRESENT-MULTI/comment_4_5228016c35ca0b13545b82bbd3b9455e._comment
 create mode 100644 doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client.mdwn
 create mode 100644 doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_10_e33dddf4d1f104107c86800a0a9a89b2._comment
 create mode 100644 doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_1_25eb2d7d0a9cdd1c55df0cec68472723._comment
 create mode 100644 doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_2_9e9b96e5113a50533251e946c2560d81._comment
 create mode 100644 doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_3_6b091198ddd6ed709b076df1296aeb77._comment
 create mode 100644 doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_4_118b588685b535cca4c02eb6ef297c67._comment
 create mode 100644 doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_5_5cead277493e1c020e16be6f9245fe33._comment
 create mode 100644 doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_6_0f135f97c2808dce094628dc6608e617._comment
 create mode 100644 doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_7_1d6f47f9e6cf935f19d68af6d5aa92fa._comment
 create mode 100644 doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_8_c5758fdb32348b9cd804ff17d27864e1._comment
 create mode 100644 doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_9_3f0bfc5a79aa59ac76a6968aacda6655._comment
 create mode 100644 doc/todo/Configuring_metadata_view_filenames.mdwn
 create mode 100644 doc/todo/Configuring_metadata_view_filenames/comment_1_08f8f27e5a8dbd80a91ffd9fd6f64e6c._comment
 create mode 100644 doc/todo/Configuring_metadata_view_filenames/comment_2_34efe1424a9b02dca706565517900bd6._comment
 create mode 100644 doc/todo/Configuring_metadata_view_filenames/comment_3_dd7aa7560412d4589d2fc28eb978a71e._comment
 create mode 100644 doc/todo/Configuring_metadata_view_filenames/comment_4_1873c7cdd142dffc210ec0172bf29997._comment
 create mode 100644 doc/todo/Configuring_metadata_view_filenames/comment_5_b222634d9f97e2ef604b476df357d54b._comment
 create mode 100644 doc/todo/Configuring_metadata_view_filenames/comment_6_1eb8c2d70ff9e3e5b3dbebf88270eb93._comment
 create mode 100644 doc/todo/Configuring_metadata_view_filenames/comment_7_ae259f68ab5b366b6fd29e5df1a05469._comment
 create mode 100644 doc/todo/Configuring_metadata_view_filenames/comment_8_2bcfc677da72637f34904b84fdd95c10._comment
 create mode 100644 doc/todo/Copy-on-Write__47__reflink__47__clonefile_support_on_macOS.mdwn
 create mode 100644 doc/todo/Copy-on-Write__47__reflink__47__clonefile_support_on_macOS/comment_1_81bf4ac2fe810cc4e7a21c8bb4d0f15a._comment
 create mode 100644 doc/todo/Copy-on-Write__47__reflink_support_for_unlocked_files.mdwn
 create mode 100644 doc/todo/Copy-on-Write__47__reflink_support_for_unlocked_files/comment_1_52db92711e28abb0eb7a346646b91573._comment
 create mode 100644 doc/todo/Describe_a_file_in_function_of_another_file.mdwn
 create mode 100644 doc/todo/Describe_a_file_in_function_of_another_file/comment_1_b0132288c67054485e9681f3f5138768._comment
 create mode 100644 doc/todo/Describe_a_file_in_function_of_another_file/comment_2_4efe2044282c8ccd6d570e84bb2ab68a._comment
 create mode 100644 doc/todo/Describe_a_file_in_function_of_another_file/comment_3_a9e02d7a27fd4448c1afd19e3f171a5c._comment
 create mode 100644 doc/todo/Display_fingerprint_to_WebApps_GPG___34__create_encrypted_new_repo__34__.mdwn
 create mode 100644 doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp.mdwn
 create mode 100644 doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_1_0650918c86fca0554755aede19a12fd3._comment
 create mode 100644 doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_2_aa6bf987de3dfc9f78eba30b4b2c8c16._comment
 create mode 100644 doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_3_3419d2603af199fd311f6898adef5ed3._comment
 create mode 100644 doc/todo/Extend_merge_conflict_resolution_to_git_conflicts.mdwn
 create mode 100644 doc/todo/Extend_merge_conflict_resolution_to_git_conflicts/comment_1_c08e7f51503f103c447064a01b085783._comment
 create mode 100644 doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running.mdwn
 create mode 100644 doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running/comment_1_e5f2630591ffa7758ca4250a061a8589._comment
 create mode 100644 doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running/comment_2_f8a5cc905d5b06bdbb1a778ab866a28c._comment
 create mode 100644 doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running/comment_3_626c629654508d0d948ece849d43ed86._comment
 create mode 100644 doc/todo/File_deletion_workflow.mdwn
 create mode 100644 doc/todo/File_deletion_workflow/comment_1_7b80d9a202ede51730cbd443731e1fa7._comment
 create mode 100644 doc/todo/File_deletion_workflow/comment_2_60b54e6bbb37464697b4f5c4ebe561da._comment
 create mode 100644 doc/todo/Filter_a_tree_with_pattern.mdwn
 create mode 100644 doc/todo/Filter_a_tree_with_pattern/comment_1_17dac31227b8f95c5ca50f4a4cf5a425._comment
 create mode 100644 doc/todo/Filter_a_tree_with_pattern/comment_2_e2b0b3eafdfdab1e315066ac57c8b838._comment
 create mode 100644 doc/todo/Filter_a_tree_with_pattern/comment_3_ca3058fe82eff771f3664ab2f8aa78ae._comment
 create mode 100644 doc/todo/Fsck_remote_files_in-flight.mdwn
 create mode 100644 doc/todo/Fsck_remote_files_in-flight/comment_1_1a70ae7c9821d664ddf72fd4c431be29._comment
 create mode 100644 doc/todo/Fsck_remote_files_in-flight/comment_2_3baff888fbc3068571cdc9fee73fbe36._comment
 create mode 100644 doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext.mdwn
 create mode 100644 doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_1_5af33851bdac4f34d83e8ef2e1d45355._comment
 create mode 100644 doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_2_ad76bcde941d6f1719260179a7bd27ba._comment
 create mode 100644 doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_3_51945c553d70ae76297ed4aaf3c8b624._comment
 create mode 100644 doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_4_2f496cb303c90eaefef955082e2bfb00._comment
 create mode 100644 doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_5_272be474bd9ee8d087821bd8a6e88175._comment
 create mode 100644 doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_6_be9a58f2028fb3c155ff2020dee2b46b._comment
 create mode 100644 doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_7_fed82ecac17e6ed86eb18232d4b5ae6a._comment
 create mode 100644 doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_8_82c04709fe3b69d6a75e44d71b500681._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add.mdwn
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_10_6d9ef10f9534c7b95ca58913cfe3b5fd._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_11_25be855ca688e37644fa86357b96b3d2._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_12_8327e0a3f3d4bf35c52b1f2f4089dcbc._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_13_8b150a2a4b9b0de8039ee8995c01bf8c._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_14_0156a70246f19beeee6ce5cfb510de86._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_15_b0f6d52ef7a94badd572c6cfa759efb3._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_16_6c4c1541a146c66c11ebe6abaf7f1810._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_1_2160800299fff5dc920847bec1ab0220._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_2_eeb1bb0b1a02a74291daa41e9a8eb725._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_3_a49dcb3963a986c530571f69fa9326b4._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_4_cf4ed68e05fd7d553a314746b444b7c0._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_5_3a2fe8d0c0dd6f5066370086c0f03300._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_6_2e0ad0cdb9d813d0fbc514c1642669ca._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_7_bb6b5503ec5f699749fa8e3ffce59aab._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_7_e6e6b344d533de57ce7661b5f1ada027._comment
 create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_9_e128886c09b9ca2127ff540c2af0beda._comment
 create mode 100644 doc/todo/INFO_message_for_custom_special_remotes.mdwn
 create mode 100644 doc/todo/INFO_message_for_custom_special_remotes/comment_1_ea99a5099f78767859c05aeb5217a12d._comment
 create mode 100644 doc/todo/INFO_message_for_custom_special_remotes/comment_2_69535d7d9b7266eaac6f9bb70d2660dc._comment
 create mode 100644 doc/todo/Idea_for_emulating_a_versioned_tree_export.mdwn
 create mode 100644 doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_1_d944fd707130be6ebe35302794a0b73f._comment
 create mode 100644 doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_2_e0f6d78620a89f60010607b37328f754._comment
 create mode 100644 doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_3_19e77a51911d3c2d39a558162223e78e._comment
 create mode 100644 doc/todo/Improving_diffdriver_--text.mdwn
 create mode 100644 doc/todo/Improving_diffdriver_--text/comment_1_a38b0f30f9b4011d703e70c093f139ab._comment
 create mode 100644 doc/todo/Improving_diffdriver_--text/comment_2_2a59862281c1be5ee92912912c2045e9._comment
 create mode 100644 doc/todo/Incremental_git_annex_sync_--content_--all.mdwn
 create mode 100644 doc/todo/Incremental_git_annex_sync_--content_--all/comment_1_9d812c6dd2fd7b4c255ea88580da4396._comment
 create mode 100644 doc/todo/Incremental_git_annex_sync_--content_--all/comment_2_9fff9eb8a7a897c5aabe9878f4d0b23b._comment
 create mode 100644 doc/todo/Incremental_git_annex_sync_--content_--all/comment_3_638f40462d4bb2a447350ce0a5dc7a92._comment
 create mode 100644 doc/todo/Incremental_git_annex_sync_--content_--all/comment_4_c232e1e1cfcc47f70079f2d32c2b4633._comment
 create mode 100644 doc/todo/Incremental_git_annex_sync_--content_--all/comment_5_e81719f23565579674249db5d0a883da._comment
 create mode 100644 doc/todo/Invert_remote_selection.mdwn
 create mode 100644 doc/todo/Invert_remote_selection/comment_1_5aa12a96f54a40adbfe18267a6bde87b._comment
 create mode 100644 doc/todo/Invert_remote_selection/comment_2_9ad4c9b2217f739e67198d16d14d32e7._comment
 create mode 100644 doc/todo/Invert_remote_selection/comment_3_2aec5f535c84c37d59802e4759a1c242._comment
 create mode 100644 doc/todo/Invert_remote_selection/comment_4_f5ab9eec7ed0f080c57dbb594deafd13._comment
 create mode 100644 doc/todo/Keeping_a_repo__39__s_description_up_to_date.mdwn
 create mode 100644 doc/todo/Keeping_a_repo__39__s_description_up_to_date/comment_1_2fcce6a8fcfec28a6edeab40291deaba._comment
 create mode 100644 doc/todo/Keeping_a_repo__39__s_description_up_to_date/comment_2_1c73d94cc84bbfdeb65a71995265491f._comment
 create mode 100644 doc/todo/Keeping_a_repo__39__s_description_up_to_date/comment_3_394c87782dd3318a6fa3705322fea4fb._comment
 create mode 100644 doc/todo/LIst_of_Available_Remotes_in_Webapp.mdwn
 create mode 100644 doc/todo/LIst_of_Available_Remotes_in_Webapp/comment_1_23fe2f3cd44c4357a385452dcd5eedef._comment
 create mode 100644 doc/todo/Long_Running_Filter_Process.mdwn
 create mode 100644 doc/todo/Long_Running_Filter_Process/comment_1_f155ffc7dbd074964dd53165274ec8a0._comment
 create mode 100644 doc/todo/Long_Running_Filter_Process/comment_3_24d89d0e8eb2da6e43d107caa71e042b._comment
 create mode 100644 doc/todo/Long_Running_Filter_Process/comment_4_96c20518a6bd2806fed3646331b3ca1c._comment
 create mode 100644 doc/todo/Lower-case_extension_for_SHA256E_and_similar.mdwn
 create mode 100644 doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_1_71a32962c081e42be0bfc468f74230e8._comment
 create mode 100644 doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_2_db432973421d3974e027cef13caa3033._comment
 create mode 100644 doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_3_15ec3c411b0a92b073eb8c65e192c8b8._comment
 create mode 100644 doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_4_2ef3cc0ff00cc735e3400120ae49d14a._comment
 create mode 100644 doc/todo/Make_addunlocked_configurable_like_largefiles.mdwn
 create mode 100644 doc/todo/Make_addunlocked_configurable_like_largefiles/comment_1_823bddc3b3824419f1123748f163e0ff._comment
 create mode 100644 doc/todo/Make_addunlocked_configurable_like_largefiles/comment_2_89ea6c764e18ed4335733f979fb31140._comment
 create mode 100644 doc/todo/Make_addunlocked_configurable_like_largefiles/comment_3_8f32ef554635d852383eeaf3f0629d45._comment
 create mode 100644 doc/todo/Make_addunlocked_configurable_like_largefiles/comment_4_17d12c5d9f5aa40aa8c20ae478b324b2._comment
 create mode 100644 doc/todo/Make_git_annex_sync_--content_trust_location_logs.mdwn
 create mode 100644 doc/todo/Make_git_annex_sync_--content_trust_location_logs/comment_1_006e3e3ab0c08852239c0f8fec851201._comment
 create mode 100644 doc/todo/Make_webapp_port_configurable.mdwn
 create mode 100644 doc/todo/Mbps.mdwn
 create mode 100644 doc/todo/Metadata_changes_are_not_reflected_in_a_view.mdwn
 create mode 100644 doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment
 create mode 100644 doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_2_74597dc57b426adccfa5aab456e499d2._comment
 create mode 100644 doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_3_39d7b5588595067332909c53b232c413._comment
 create mode 100644 doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_4_6ab0e38d8be8a70d501108f207d41d82._comment
 create mode 100644 doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_5_b1b381c560fd81f372fc393ec5d63d8d._comment
 create mode 100644 doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_6_9d3d9877e8581f986257dd3d495a8eab._comment
 create mode 100644 doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_7_f97d171fdd715d984e43c1a8139bb8ae._comment
 create mode 100644 doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_8_e10e8e6daf155fc493454f1d0d8595a8._comment
 create mode 100644 doc/todo/Metadata_on_regular_git_objects___40__blob__44___trees__41____63__.mdwn
 create mode 100644 doc/todo/Metadata_on_regular_git_objects___40__blob__44___trees__41____63__/comment_1_30c513b68101442dbcdec0eb109203fe._comment
 create mode 100644 doc/todo/More_precise_jobs_count_config.mdwn
 create mode 100644 doc/todo/More_precise_jobs_count_config/comment_1_8b7dbf6025c99172925f037e9096ead1._comment
 create mode 100644 doc/todo/More_space_savings_for_annex.thin.mdwn
 create mode 100644 doc/todo/More_space_savings_for_annex.thin/comment_1_cd571b1b3b6e73041ee629d031481d09._comment
 create mode 100644 doc/todo/More_space_savings_for_annex.thin/comment_2_95d195f2bad7e6a912e5d201928a94b9._comment
 create mode 100644 doc/todo/More_space_savings_for_annex.thin/comment_3_15cc8f9e428df04199d139e2677afd8a._comment
 create mode 100644 doc/todo/More_space_savings_for_annex.thin/comment_4_a87baf5ad6b7688bb40a6c463cb1b8db._comment
 create mode 100644 doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config.mdwn
 create mode 100644 doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_1_284c806e83a32af81b02aea7c7bc285a._comment
 create mode 100644 doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_2_1f55ad6b39906458779b2d604b003ffe._comment
 create mode 100644 doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_3_b00dce2374aac6968317d05d23bcfaf7._comment
 create mode 100644 doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_4_743d0b077110c5cac1e2f47187b75333._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__.mdwn
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_10_ed3a47b10ce2303041d9b9271bb9a2c8._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_11_2afa6133bfa8932ea1fb02b2052e2939._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_12_6c9336be070b04d5736b943889370c13._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_13_20184de38c2adeed7e20fa323d9a3ba4._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_14_58965ac55e2e9aebdd0e38f8eef097a3._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_1_312f32bd35f06837463e541773986b4f._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_2_7ea1c35ce23a57fea52a593c41a8fb69._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_3_337217fc0ae8cfd432c7df45942b86ef._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_4_8778b93dbc123c484727bb55e39608c9._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_5_9c7bdcb483b371f421bcdca3d8c2073c._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_6_c94fdab4db1d5f94929ae068c546b533._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_7_e3c50b7ab1c5cd49a3e5376e20b7d4c0._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_8_72eb9bc8d12bc8719f49f6528a086234._comment
 create mode 100644 doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_9_6d1a630fbf036144c9559c9c01fca845._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation.mdwn
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_10_695d1269ab20c66630ddfa2d8cbabbef._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_12_f85f81450c5d59e6722b46299f2ae29c._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_13_a19823409648828b8b9f7a0f2fa7d935._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_14_14f46277adb38d5cb802cd23eb2cde04._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_15_85e2368381e15cd86b5340fcec1a083b._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_16_fbbcf1d8b35078274cfe322cea6de21c._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_17_39db598e93d0d858984052e3894cd96e._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_1_29e601ea3ea4f22301c6cf6eed403ba4._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_2_fa9e2c0a83bad2e0c2da3016b9bf2100._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_3_529c38fc63540b32c51ae75529e9005e._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_4_82707d36ed580d62c73e441f959ccd9e._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_5_aad1896b58e58cbc870c4526ebb824ec._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_6_3d2f62f0946528c9986135f8db86a237._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_7_48842fb1e006a05573ab34048db45c8b._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_8_593b8710c25bec1182409b36d6c44b4a._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_9_4f4f4a42adafe52207ed32a5d20e94be._comment
 create mode 100644 doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_9_b92774b0feec3049bf6aef89614543df._comment
 create mode 100644 doc/todo/PATCH__58___drop_url_parameters_from_extension.hs
 create mode 100644 doc/todo/Package_for_Lacie_NasOS__63__.mdwn
 create mode 100644 doc/todo/Package_for_Lacie_NasOS__63__/comment_1_1b1b23b95b1fa29a8d71848a5cec9008._comment
 create mode 100644 doc/todo/Package_for_Lacie_NasOS__63__/comment_2_81b181781da615c56aa30eab131cec53._comment
 create mode 100644 doc/todo/Package_for_Lacie_NasOS__63__/comment_3_fd7eeee6a86101867f0ab17f883f0c6a._comment
 create mode 100644 doc/todo/Pause_all_transfers_in_all_annexes_watched_by_the_assistant.mdwn
 create mode 100644 doc/todo/Prevent_simultaneous_pushing_to_idential_remotes.mdwn
 create mode 100644 doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__.mdwn
 create mode 100644 doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_1_26d81cbc8732b65c2f0a86a33ef0f8fd._comment
 create mode 100644 doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_2_64ffa9a560bf11ba22c715da0b4b1cfe._comment
 create mode 100644 doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_3_da5363a268008a88014972987de10323._comment
 create mode 100644 doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_4_620fd718bd2c97a6fa4ce775e311a2d6._comment
 create mode 100644 doc/todo/RawFilePath_conversion.mdwn
 create mode 100644 doc/todo/Request__58___Date_limit_with_importfeed.mdwn
 create mode 100644 doc/todo/Request__58___Date_limit_with_importfeed/comment_1_5d3d762eaf755410f5ee70a22fc95ab6._comment
 create mode 100644 doc/todo/S3_export_redirecting_to_key-value_store.mdwn
 create mode 100644 doc/todo/S3_multipart_interruption_cleanup.mdwn
 create mode 100644 doc/todo/Set_total_storage_limit_for_special_remotes.mdwn
 create mode 100644 doc/todo/Set_total_storage_limit_for_special_remotes/comment_1_8945025ad54e28f48474f8931746a775._comment
 create mode 100644 doc/todo/Set_total_storage_limit_for_special_remotes/comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment
 create mode 100644 doc/todo/Setting_default_preferred_content_expressions.mdwn
 create mode 100644 doc/todo/Setting_default_preferred_content_expressions/comment_1_45d57933a45ddc1e31ba46519b944239._comment
 create mode 100644 doc/todo/Setting_default_preferred_content_expressions/comment_2_575320e07f005d46d26cc6db9ad3ebd3._comment
 create mode 100644 doc/todo/Setting_default_preferred_content_expressions/comment_3_971b3efe8a6ebdeede0184f13774e86b._comment
 create mode 100644 doc/todo/Should_git_annex_diffdriver_fetch_non-present_file.mdwn
 create mode 100644 doc/todo/Show_repo_type_in_repo_list.mdwn
 create mode 100644 doc/todo/Show_repo_type_in_repo_list/comment_1_ac6eb1072ef902a094b79dd8e0917c4d._comment
 create mode 100644 doc/todo/Show_repo_type_in_repo_list/comment_2_6979c487f707a724a048d20e2e5744e6._comment
 create mode 100644 doc/todo/Show_repo_type_in_repo_list/comment_3_529254a6cc20de7259d60a3cbc5ccaf7._comment
 create mode 100644 doc/todo/Sorting_remotes_by_description_in___96__git_annex_info__96__.mdwn
 create mode 100644 doc/todo/Special_remotes__58___support_for_MULTIREMOVE.mdwn
 create mode 100644 doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_1_cc95104ae0803db35fee504152db046a._comment
 create mode 100644 doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_2_f58cc7b04948a8c758f97778631b0f02._comment
 create mode 100644 doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_3_4f18712f974f85c3cef810714d304d85._comment
 create mode 100644 doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_4_2dbf3558c7c969281f1cc5e1738d2c0b._comment
 create mode 100644 doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_5_4a9f2e1e3f30b472d4c5aa9c07684cc0._comment
 create mode 100644 doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_6_f756a8ea12af1a01406f1bf05d9dba11._comment
 create mode 100644 doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_7_993ed66935c0d95488751a0e0e2c57b8._comment
 create mode 100644 doc/todo/Specify_maximum_usable_space_per_remote.mdwn
 create mode 100644 doc/todo/Specify_maximum_usable_space_per_remote/comment_1_fdc0c518b6cbc5dc7e5b64748c2d7b01._comment
 create mode 100644 doc/todo/Specify_maximum_usable_space_per_remote/comment_2_b81af6dac4042c0d4dab58c91a46b09d._comment
 create mode 100644 doc/todo/Specify_maximum_usable_space_per_remote/comment_3_afc7f278c02d7bf9f92a90e51cb5a2a9._comment
 create mode 100644 doc/todo/Specify_maximum_usable_space_per_remote/comment_4_a760351ed7a6d3d232af7c22b2063871._comment
 create mode 100644 doc/todo/Specify_maximum_usable_space_per_remote/comment_5_c5069ffed5e8c4e1d001aedb971aca75._comment
 create mode 100644 doc/todo/Specify_maximum_usable_space_per_remote/comment_6_bef44c8f571f2be177d6ee949c721a6a._comment
 create mode 100644 doc/todo/Speed_up___39__import_--clean-duplicates__39__.mdwn
 create mode 100644 doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_1_9268c639d3d21cce4ca7b60d08e9cb65._comment
 create mode 100644 doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_2_9c6688901ef20badd834419202627d5c._comment
 create mode 100644 doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_3_b53f2e881af1426adb0f45e2b11e4be6._comment
 create mode 100644 doc/todo/Split_autocommit_option.mdwn
 create mode 100644 doc/todo/Split_autocommit_option/comment_1_fc127bc73c650404df4f21c9a04b3dd4._comment
 create mode 100644 doc/todo/Store_git_pack_files_on_special_remotes.mdwn
 create mode 100644 doc/todo/Straight-forward_diffing_with___39__git_annex_diff__39__.mdwn
 create mode 100644 doc/todo/Straight-forward_diffing_with___39__git_annex_diff__39__/comment_1_2f5ea091b7f6defa397d15055d04a67d._comment
 create mode 100644 doc/todo/Straight-forward_diffing_with___39__git_annex_diff__39__/comment_2_cae9e0be287bd42498caf1f61c518f0e._comment
 create mode 100644 doc/todo/Usability_improvements_for_new_users.mdwn
 create mode 100644 doc/todo/Usability_improvements_for_new_users/comment_1_70ecef547308f9b049bd67f3d2f14117._comment
 create mode 100644 doc/todo/Usability_improvements_for_new_users/comment_2_ea77f0894802a17854aeedeceababf8a._comment
 create mode 100644 doc/todo/Use_MediaScannerConnection_on_Android.mdwn
 create mode 100644 doc/todo/Use_a_remote_as_a_sharing_site_for_files_with_obfuscated_URLs.mdwn
 create mode 100644 doc/todo/Use_a_remote_as_a_sharing_site_for_files_with_obfuscated_URLs/comment_1_1a1f34f4f389267d67e79409c0ca8b1d._comment
 create mode 100644 doc/todo/Use_a_remote_as_a_sharing_site_for_files_with_obfuscated_URLs/comment_2_735afa6f87a93cdf333c17da32010620._comment
 create mode 100644 doc/todo/Use_editorconfig_for_formatting_rules.mdwn
 create mode 100644 doc/todo/Use_editorconfig_for_formatting_rules/comment_1_20e6d6467dcc9e4814c657355a7f2e74._comment
 create mode 100644 doc/todo/View_for_old_versions_of_a_file.mdwn
 create mode 100644 doc/todo/View_for_old_versions_of_a_file/comment_1_8e233fd006bd8f16533df63579f02fb1._comment
 create mode 100644 doc/todo/View_for_old_versions_of_a_file/comment_2_9b1c6f41f77ec6ba9c90a5e9ec088647._comment
 create mode 100644 doc/todo/When_autostarting_the_assistant_on_boot_delay_the_execution_2min.mdwn
 create mode 100644 doc/todo/When_autostarting_the_assistant_on_boot_delay_the_execution_2min/comment_1_49990eaf4a3d6ee89f668dfc159f5eae._comment
 create mode 100644 doc/todo/Wishlist__58___Parity_files_on_all_files.mdwn
 create mode 100644 doc/todo/Wishlist__58___Parity_files_on_all_files/comment_1_3900fa7c3ed1455fe07d097c3dc0c9f2._comment
 create mode 100644 doc/todo/Wishlist__58___Parity_files_on_all_files/comment_2_60dc7823a1814af18861b459a9b3cd0e._comment
 create mode 100644 doc/todo/Wishlist__58___Parity_files_on_all_files/comment_3_d69eba0afc48c49bdcd7f1f6a7716bbb._comment
 create mode 100644 doc/todo/Wishlist__58___Parity_files_on_all_files/comment_4_01c382342237e4713ab32a3e95497926._comment
 create mode 100644 doc/todo/Wishlist__58___additional_environment_variables_for_hooks.mdwn
 create mode 100644 doc/todo/Wishlist__58___additional_environment_variables_for_hooks/comment_1_d82cbbb478a81a651fbe6cb8b71c1192._comment
 create mode 100644 doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant.mdwn
 create mode 100644 doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant/comment_1_3274820a0d1f10c505f15cd29a37b95a._comment
 create mode 100644 doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant/comment_2_2cf5aef3f1d340c4ed6249ef94c1b607._comment
 create mode 100644 doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant/comment_3_6c53d82e62b2d269a941ba967d05adf5._comment
 create mode 100644 doc/todo/Wishlist__58___sanitychecker_fix_wrong_UUID__47__duplicate_remote.mdwn
 create mode 100644 doc/todo/Wishlist__58___sanitychecker_fix_wrong_UUID__47__duplicate_remote/comment_1_a9e54e4bc540cbab7cdbbfdeaa973f4a._comment
 create mode 100644 doc/todo/Workflow_guide.mdwn
 create mode 100644 doc/todo/Workflow_guide/comment_1_f4242a3bdeffb90336f562f9ec182e5d._comment
 create mode 100644 doc/todo/Workflow_guide/comment_2_ee6da4cc639bca0b17156d51ebfc05c2._comment
 create mode 100644 doc/todo/Workflow_guide/comment_3_8cf0f9913dc307cd18001656ba390159._comment
 create mode 100644 doc/todo/Workflow_guide/comment_4_b6f5ce361529356a77b0e6141a62c06d._comment
 create mode 100644 doc/todo/Workflow_guide/comment_5_6ec6fb45021ba82ed6a4bb9a6f3cfceb._comment
 create mode 100644 doc/todo/Workflow_guide/comment_6_640e5c6cdea8a6fae63c3fab6970f1f2._comment
 create mode 100644 doc/todo/Workflow_guide/comment_7_805e877b23adcf562feeb7d927fca08d._comment
 create mode 100644 doc/todo/__39__info_filename__39___to_provide_information_either_content_is_locally_present.mdwn
 create mode 100644 doc/todo/__91__FR__93___No_consistency_check_while_on_battery-only.mdwn
 create mode 100644 doc/todo/__91__FR__93___No_consistency_check_while_on_battery-only/comment_1_b557db02c3719152d392fa454c9c5ce5._comment
 create mode 100644 doc/todo/__91__FR__93___No_consistency_check_while_on_battery-only/comment_2_374567f37635613a5d671c877d601367._comment
 create mode 100644 doc/todo/__91__PATCH__93___Change_--copies__39___meta_parameter_to_NUMBER.mdwn
 create mode 100644 doc/todo/__91__PATCH__93___Fix_annex.adviceNoSshCaching_no_effect.mdwn
 create mode 100644 doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs.mdwn
 create mode 100644 doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs/comment_1_b943081483e4f1f9897b214004d48493._comment
 create mode 100644 doc/todo/a_way_to_figure_out_the_origin_of_largefiles.mdwn
 create mode 100644 doc/todo/a_way_to_figure_out_the_origin_of_largefiles/comment_1_9b0826c1d5b063a3e63d4d2cc030a55b._comment
 create mode 100644 doc/todo/a_way_to_figure_out_the_origin_of_largefiles/comment_2_6bfe8e1b6b2c3334803d8a6676862e8a._comment
 create mode 100644 doc/todo/a_way_to_figure_out_the_origin_of_largefiles/comment_3_def75a3ad8907cb62eb5d96c85aabd5e._comment
 create mode 100644 doc/todo/absolute_symlinks.mdwn
 create mode 100644 doc/todo/add_--all___40__or_alike__41___to_find_and_findref.mdwn
 create mode 100644 doc/todo/add_--all___40__or_alike__41___to_find_and_findref/comment_1_8407146882e97ee8510f28df2ba5129c._comment
 create mode 100644 doc/todo/add_--dry-run.mdwn
 create mode 100644 doc/todo/add_--dry-run/comment_1_4daf51eec7db67a89bec8f81b742a094._comment
 create mode 100644 doc/todo/add_--dry-run/comment_2_312127fc2780fd894332d7d8b7f7a209._comment
 create mode 100644 doc/todo/add_--jobs_for_dropunused_command.mdwn
 create mode 100644 doc/todo/add_--jobs_for_dropunused_command/comment_1_bcd06faab6b5f6394333e74a17249d08._comment
 create mode 100644 doc/todo/add_--json-progress_support_in_push_and_pull.mdwn
 create mode 100644 doc/todo/add_--json-progress_support_in_push_and_pull/comment_1_403acf073a2a8d53eaa880cc2564347d._comment
 create mode 100644 doc/todo/add_--json-progress_support_in_push_and_pull/comment_2_ff0b1ca16b03d2e6c8331645adad84a6._comment
 create mode 100644 doc/todo/add_--json-progress_support_in_push_and_pull/comment_3_a11ee71f4ee907b011aebcfe270b7ee3._comment
 create mode 100644 doc/todo/add_--json-progress_support_in_push_and_pull/comment_4_0f3c22853b50550237f9659ed2120ab2._comment
 create mode 100644 doc/todo/add_--json-progress_to___96__git_annex_add__96__.mdwn
 create mode 100644 doc/todo/add_--json-progress_to___96__git_annex_add__96__/comment_1_9acc343305dd5a2aaf569a6396d09896._comment
 create mode 100644 doc/todo/add_--json-progress_to_fsck_--json.mdwn
 create mode 100644 doc/todo/add_--json-progress_to_fsck_--json/comment_1_170acd9fc5b5a40ae22de0bf418b424c._comment
 create mode 100644 doc/todo/add_--json-progress_to_fsck_--json/comment_2_2ce9c3c35ea5c4033bfa42e2f3365a64._comment
 create mode 100644 doc/todo/add_--json-progress_to_fsck_--json/comment_3_5c0c3bdf1e5cf68f2dcebdd85a8253ac._comment
 create mode 100644 doc/todo/add_ancient_armel_build.mdwn
 create mode 100644 doc/todo/add_ancient_armel_build/comment_1_704f1a854e5ef62edbca60ab209d2123._comment
 create mode 100644 doc/todo/add_ancient_armel_build/comment_2_0b02f96699e9ec9447e336b74b255801._comment
 create mode 100644 doc/todo/add_ancient_armel_build/comment_3_eaeb9aec42fde6b8a25199b1e1e6a78c._comment
 create mode 100644 doc/todo/add_ancient_armel_build/comment_4_da51390e7b67cd1dc075c793e99d4367._comment
 create mode 100644 doc/todo/add_import_--to_command.mdwn
 create mode 100644 doc/todo/add_import_--to_command/comment_1_b70d10190722c0d21c2343fe51e38414._comment
 create mode 100644 doc/todo/add_import_--to_command/comment_2_c7a95793a46ed948301b01a1f29bfac1._comment
 create mode 100644 doc/todo/add_import_--to_command/comment_3_f393450ae2daa14e1e7008db2b3c7dc8._comment
 create mode 100644 doc/todo/add_import_--to_command/comment_4_4a30627ac78b32911604c3377b958cd0._comment
 create mode 100644 doc/todo/add_import_--to_command/comment_5_549edb19b222bf4bd1b87aceba007005._comment
 create mode 100644 doc/todo/add_import_tree_to_external_special_remote_protocol.mdwn
 create mode 100644 doc/todo/add_limit_to_matching_options.mdwn
 create mode 100644 doc/todo/add_limit_to_matching_options/comment_1_2358e0503ca6c65644ca68c0ebd89723._comment
 create mode 100644 doc/todo/add_limit_to_matching_options/comment_2_187a47171265eeaf2aa144beed53bfc3._comment
 create mode 100644 doc/todo/add_limit_to_matching_options/comment_3_cfff69317903879bba2a9a9de1e73a8e._comment
 create mode 100644 doc/todo/add_maxextensionlength_to_git-annex-config.mdwn
 create mode 100644 doc/todo/add_maxextensionlength_to_git-annex-config/comment_1_df1113eb2b0b9cf6c13b1e8ea0995f1d._comment
 create mode 100644 doc/todo/add_maxextensionlength_to_git-annex-config/comment_2_580ed143221abbcced40f020b849cc27._comment
 create mode 100644 doc/todo/add_maxextensionlength_to_git-annex-config/comment_3_6bcf92e8cc78b47ed42f58a610e27d76._comment
 create mode 100644 doc/todo/add_maxextensionlength_to_git-annex-config/comment_4_f0894e2797e1188bdf4bdc09bd10553e._comment
 create mode 100644 doc/todo/add_maxextensionlength_to_git-annex-config/comment_5_9499ecd6136102803f1d6691c03e6b20._comment
 create mode 100644 doc/todo/add_maxextensionlength_to_git-annex-config/comment_6_9ff852c12549985f6e88bd2316a69def._comment
 create mode 100644 doc/todo/add_maxextensionlength_to_git-annex-config/comment_7_2b02c97fc9cfdb30d89676ec82760538._comment
 create mode 100644 doc/todo/add_maxextensionlength_to_git-annex-config/comment_8_6302aa8c3ff1f1096bc9978dd6407744._comment
 create mode 100644 doc/todo/add_maxextensionlength_to_git-annex-config/comment_9_5027255cc1b0dec41e315df8472fe60e._comment
 create mode 100644 doc/todo/add_option_to_disable_fsck_upgradable_key_warnings.mdwn
 create mode 100644 doc/todo/add_option_to_disable_fsck_upgradable_key_warnings/comment_1_f91174aef6f7a5a41fb9b9b54249be1c._comment
 create mode 100644 doc/todo/add_option_to_disable_fsck_upgradable_key_warnings/comment_2_eb2a5ee55df954b243bf0ea87801fbce._comment
 create mode 100644 doc/todo/add_option_to_disable_fsck_upgradable_key_warnings/comment_3_3b9f1387cc5de5d0bce5fee5fff91002._comment
 create mode 100644 doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn
 create mode 100644 doc/todo/add_sftp_special_remote.mdwn
 create mode 100644 doc/todo/add_sftp_special_remote/comment_1_28c98e879c16f56da2a89ed9d50e4398._comment
 create mode 100644 doc/todo/add_sftp_special_remote/comment_2_1fcefc50041b363a86f596f8d4121611._comment
 create mode 100644 doc/todo/add_testremote_cleanup.mdwn
 create mode 100644 doc/todo/add_testremote_cleanup/comment_1_9dc28d46dfcd693def4cbb3837de55e0._comment
 create mode 100644 doc/todo/add_testremote_cleanup/comment_2_a87de50ab7c39d955d5c1f6a1c51f761._comment
 create mode 100644 doc/todo/add_testremote_cleanup/comment_3_976fd7b1db867bf5fe785e0d32acddcb._comment
 create mode 100644 doc/todo/add_testremote_cleanup/comment_4_ef144de6384eb89a2d4caa13e6895872._comment
 create mode 100644 doc/todo/add_testremote_cleanup/comment_5_0a3c3cc6c9b4efd7a6c4cf7333f2b120._comment
 create mode 100644 doc/todo/add_tests_under_concurrency.mdwn
 create mode 100644 doc/todo/add_tests_under_concurrency/comment_1_9879c63f9de342b6831d5794d8f6212e._comment
 create mode 100644 doc/todo/add_tests_under_concurrency/comment_2_3713c706c8a0689f527c4558176a7b48._comment
 create mode 100644 doc/todo/add_xxHash_backend.mdwn
 create mode 100644 doc/todo/add_xxHash_backend/comment_1_8993f493a8b43ffda9f8e0b6d5e186ac._comment
 create mode 100644 doc/todo/add_xxHash_backend/comment_2_945217badfaeba8672329d4f6ac4b8e2._comment
 create mode 100644 doc/todo/add_xxHash_backend/comment_3_93892ef71d40f0b10e5fdcb703faf3ad._comment
 create mode 100644 doc/todo/additional_git-annex-config_settings__63__.mdwn
 create mode 100644 doc/todo/additional_git-annex-config_settings__63__/comment_1_74d61d6a4412223092f468628d3f2f45._comment
 create mode 100644 doc/todo/additional_git-annex-config_settings__63__/comment_2_2973d438e8f3fda50cfb151534a8ec73._comment
 create mode 100644 doc/todo/additional_git-annex-config_settings__63__/comment_3_3abeddccdf5c742962b25b7dbe8fb69e._comment
 create mode 100644 doc/todo/additional_git-annex-config_settings__63__/comment_4_1d777383fda7c50d630e19ec1d1ade52._comment
 create mode 100644 doc/todo/additional_git-annex-config_settings__63__/comment_5_ba2cbf8dcf14a1d0b20621b48b8e8600._comment
 create mode 100644 doc/todo/additional_git-annex-config_settings__63__/comment_6_4ec0261f3b8bc6d2492fa3dabb0121e5._comment
 create mode 100644 doc/todo/additional_git-annex-config_settings__63__/comment_7_c1768ab8568c8e58525ed40e76cc13f2._comment
 create mode 100644 doc/todo/additional_git-annex-config_settings__63__/comment_8_845a504ea9f038a19a21d8a985585b2b._comment
 create mode 100644 doc/todo/addurl_--raw-except_REMOTEs__63__.mdwn
 create mode 100644 doc/todo/addurl_--raw-except_REMOTEs__63__/comment_1_d9b88a0f157ce8143d52a35256beaaab._comment
 create mode 100644 doc/todo/addurl_--raw-except_REMOTEs__63__/comment_2_2cd05802f25c9868b1b975dd359b66b4._comment
 create mode 100644 doc/todo/addurl___8211__force-torrent_option.mdwn
 create mode 100644 doc/todo/addurl___8211__force-torrent_option/comment_1_15be1914c8d05cd1ad8220bcfea9d0bf._comment
 create mode 100644 doc/todo/addurl___8211__force-torrent_option/comment_2_52c04c388b807993cecacc7f98b73cd3._comment
 create mode 100644 doc/todo/adjusted_branch_with_hashdirlower_links.mdwn
 create mode 100644 doc/todo/aeson_2.0.mdwn
 create mode 100644 doc/todo/allow_configuring_assistant_to_add_files_locked.mdwn
 create mode 100644 doc/todo/allow_disk_space_quota_independent_of_free_disk_space.mdwn
 create mode 100644 doc/todo/allow_for_annonymous_AWS_S3_access.mdwn
 create mode 100644 doc/todo/allow_for_annonymous_AWS_S3_access/comment_1_0723643146ba36131218be090e6d5c73._comment
 create mode 100644 doc/todo/allow_for_annonymous_AWS_S3_access/comment_2_2626e1d0b2aa5a2af19d7fef1d13beaa._comment
 create mode 100644 doc/todo/allow_for_annonymous_AWS_S3_access/comment_3_6f79f3ecab275d594182fff5e2fd81f9._comment
 create mode 100644 doc/todo/allow_for_annonymous_AWS_S3_access/comment_4_9cf7360f849964689133af60b8e1175b._comment
 create mode 100644 doc/todo/allow_for_annonymous_AWS_S3_access/comment_5_b680494cd2fb1cf117b110e08e0ff476._comment
 create mode 100644 doc/todo/allow_for_annonymous_AWS_S3_access/comment_6_b1e14d6baef8d03aaa6ace717aebc0f9._comment
 create mode 100644 doc/todo/allow_for_annonymous_AWS_S3_access/comment_7_d44dea0d8c0d46dd8c75ae40f66072e1._comment
 create mode 100644 doc/todo/allow_for_annonymous_AWS_S3_access/comment_8_b0d9dbe81f01e80809381a9e5f6a883d._comment
 create mode 100644 doc/todo/allow_for_annonymous_AWS_S3_access/comment_9_7fa3b2aafcad92c20f8a3467aa3ae6b9._comment
 create mode 100644 doc/todo/alternate_keys_for_same_content.mdwn
 create mode 100644 doc/todo/alternate_keys_for_same_content/comment_10_22ff867952875856b20339a8829c5944._comment
 create mode 100644 doc/todo/alternate_keys_for_same_content/comment_11_3323eff3d94d366595bf2b7e78c01dce._comment
 create mode 100644 doc/todo/alternate_keys_for_same_content/comment_1_7a7f287bcde5353072100294dd8edce6._comment
 create mode 100644 doc/todo/alternate_keys_for_same_content/comment_2_0f464f4970e499371fcb65e0d06202cf._comment
 create mode 100644 doc/todo/alternate_keys_for_same_content/comment_3_c99b23e878e37e205a3182d3b6d3f2b2._comment
 create mode 100644 doc/todo/alternate_keys_for_same_content/comment_4_a5fb6045595da0c490098e46f76db9b8._comment
 create mode 100644 doc/todo/alternate_keys_for_same_content/comment_5_230d35bd623189818002901455964ca4._comment
 create mode 100644 doc/todo/alternate_keys_for_same_content/comment_6_ae8355ec917e7a7a240cdb88714c55d0._comment
 create mode 100644 doc/todo/alternate_keys_for_same_content/comment_7_1c0a975893c63c14b3f6e17712b5191c._comment
 create mode 100644 doc/todo/alternate_keys_for_same_content/comment_8_4b16c48a2d9f4926d63f6ab54fe801d3._comment
 create mode 100644 doc/todo/alternate_keys_for_same_content/comment_9_42d240bbfc6ab858219ffa0f873c3eb4._comment
 create mode 100644 doc/todo/annex.addunlocked_in_gitattributes.mdwn
 create mode 100644 doc/todo/annex.addunlocked_in_gitattributes/comment_1_1d21cde3d21a9b5bb129b17b9e0fc95d._comment
 create mode 100644 doc/todo/annex.addunlocked_in_gitattributes/comment_2_38f248f7596646dfc11248f0149c0beb._comment
 create mode 100644 doc/todo/annex.addunlocked_in_gitattributes/comment_3_270c5156c8adce0aff86eda5f2746703._comment
 create mode 100644 doc/todo/annex.addunlocked_in_gitattributes/comment_4_d87e08ccdec98867dd52b629e6fad330._comment
 create mode 100644 doc/todo/annex.addunlocked_in_gitattributes/comment_5_be25f3b3c2279eb3fd3ef69c4d1cb52d._comment
 create mode 100644 doc/todo/annex.addunlocked_in_gitattributes/comment_6_f672dee4c1712e0d20dd820999598d87._comment
 create mode 100644 doc/todo/annex.addunlocked_in_gitattributes/comment_7_d06e3412f07d98c784b420d82d2d8d49._comment
 create mode 100644 doc/todo/annex.addunlocked_in_gitattributes/comment_8_73a402df13f30b279dfd2914adec5f35._comment
 create mode 100644 doc/todo/annex.addunlocked_in_gitattributes/comment_9_02866c504617c2914eff01d3529d5cc7._comment
 create mode 100644 doc/todo/annex_add___40__-u__124__--update__41___mode.mdwn
 create mode 100644 doc/todo/annex_add___40__-u__124__--update__41___mode/comment_1_bde2b1e2c45e110d56ce98b43dd77743._comment
 create mode 100644 doc/todo/annex_merge_--remotes.mdwn
 create mode 100644 doc/todo/annex_merge_--remotes/comment_1_d4d1c3dae7cff4119b7c111ac6e6f947._comment
 create mode 100644 doc/todo/annex_merge_--remotes/comment_2_be8596676823e916a56d774e0a161945._comment
 create mode 100644 doc/todo/annex_merge_--remotes/comment_3_35614da544e315529b236a36e1b28e2d._comment
 create mode 100644 doc/todo/annex_merge_--remotes/comment_4_8cb7787fbfae63c45a155ee6ef270922._comment
 create mode 100644 doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed.mdwn
 create mode 100644 doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_10_32ebb1ea1278b891b58dd3c4a8546453._comment
 create mode 100644 doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_1_672457817d5dca898f5aefbe97da9b23._comment
 create mode 100644 doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_2_b6a76bfc063dcba439b2ead004caabc9._comment
 create mode 100644 doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_3_3f0872f13160a77a82bd5a95fc3f397d._comment
 create mode 100644 doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_4_0217c8acd2a9eb3bba1fc497856cd96a._comment
 create mode 100644 doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_5_7501eed2e6cb732966277ef2f1ff28e9._comment
 create mode 100644 doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_6_7a5b3d2694a48e4e44436f6bf7ed6642._comment
 create mode 100644 doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_8_2550e1760dcfb90c9c2ca1ee145adcf1._comment
 create mode 100644 doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_8_f34293aa30b8b9abc71fac4e713aded3._comment
 create mode 100644 doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_9_d7e879ae1e7ae5e27e15dab9d5b99f16._comment
 create mode 100644 doc/todo/arm64_autobuild_broken_since_2022.mdwn
 create mode 100644 doc/todo/arm64_autobuild_broken_since_2022/comment_1_0642002d8ad1eb318de5fdb63956a2fc._comment
 create mode 100644 doc/todo/arm64_autobuild_broken_since_2022/comment_2_48e40f76e0480adc965505543a4f25e5._comment
 create mode 100644 doc/todo/assign_costs_per_URL_or_better_repo-wide___40__regexes__41__.mdwn
 create mode 100644 doc/todo/assign_costs_per_URL_or_better_repo-wide___40__regexes__41__/comment_1_55652562111e83129eb19a61da14ee4a._comment
 create mode 100644 doc/todo/assign_costs_per_URL_or_better_repo-wide___40__regexes__41__/comment_2_0d1e17e92d6022552406fef144e8c104._comment
 create mode 100644 doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn
 create mode 100644 doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address/comment_1_6b71a390fd16f593216793aec590d9a8._comment
 create mode 100644 doc/todo/assistant_importtree.mdwn
 create mode 100644 doc/todo/assistant_parallel_file_transfers.mdwn
 create mode 100644 doc/todo/assistant_should_detect_added_remotes.mdwn
 create mode 100644 doc/todo/assistant_should_detect_added_remotes/comment_1_1cadcd0d5c61a04bd1118d94e3fc7f45._comment
 create mode 100644 doc/todo/assistant_should_detect_added_remotes/comment_2_2a282fcacad94b9590f5bc440ff6ea64._comment
 create mode 100644 doc/todo/assistant_should_detect_added_remotes/comment_3_35435a0b4d98483fa5c67759ae5baa35._comment
 create mode 100644 doc/todo/assistant_support_hide-missing.mdwn
 create mode 100644 doc/todo/assistant_web_switch_repo_Internal_Server_Error.mdwn
 create mode 100644 doc/todo/assistant_web_switch_repo_Internal_Server_Error/comment_1_b4add1998a9a81fb2c95539408bbeb64._comment
 create mode 100644 doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters.mdwn
 create mode 100644 doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_1_63d48db769863cdfe411404e8c26a399._comment
 create mode 100644 doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_2_afa8c10bd3b1df649c1f643430b300e9._comment
 create mode 100644 doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_3_f19ff768a3903f80dbaa378b74d2a7e3._comment
 create mode 100644 doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_4_b031ee12622b1ed28b6ffc8c037f7d30._comment
 create mode 100644 doc/todo/auto-lock_files_after_one_edit.mdwn
 create mode 100644 doc/todo/auto-lock_files_after_one_edit/comment_1_afc78ecd06f0ee9a70ea6c89a8b63e46._comment
 create mode 100644 doc/todo/auto-lock_files_after_one_edit/comment_2_4a6274dd1da7746a5be673ffb0c5d520._comment
 create mode 100644 doc/todo/avoid_storing_contentidentifier_log_for_borg.mdwn
 create mode 100644 doc/todo/batch_async.mdwn
 create mode 100644 doc/todo/batch_async/comment_1_b68dcc98856f7b757e539c499db7ebd1._comment
 create mode 100644 doc/todo/batch_operations_for_remotes.mdwn
 create mode 100644 doc/todo/batch_operations_for_remotes/comment_1_9a2f21febec8f49c782e464973dbc4fc._comment
 create mode 100644 doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit.mdwn
 create mode 100644 doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_1_c8836a164c8c1efedd5467233237bfd0._comment
 create mode 100644 doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_2_41a25215d9a1f635573d5e5f5c30fd62._comment
 create mode 100644 doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_3_5241eace21e873678a0fbb353f4ece69._comment
 create mode 100644 doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_4_caf913b53a54ac010dba253fca1ef76e._comment
 create mode 100644 doc/todo/better_error_messages_for_local_remote.mdwn
 create mode 100644 doc/todo/better_error_messages_for_local_remote/comment_1_094e6a7b62c8b81185cda06a62104f1f._comment
 create mode 100644 doc/todo/better_error_messages_for_local_remote/comment_2_4c8115fa0a41bd1cbecdcf7a4d9608ed._comment
 create mode 100644 doc/todo/better_error_messages_for_local_remote/comment_3_2dd5e994a8ce6352eac78cfd69934316._comment
 create mode 100644 doc/todo/better_mangling_of_filenames_in_views_via_unicode.mdwn
 create mode 100644 doc/todo/better_mangling_of_filenames_in_views_via_unicode/comment_1_85eb622f3e651ad3cd42def62e2a83fd._comment
 create mode 100644 doc/todo/better_mangling_of_filenames_in_views_via_unicode/comment_2_b6d583625aa8821bde31464e8f19a34f._comment
 create mode 100644 doc/todo/better_message_for_external_special_remote_protocol_mismatch.mdwn
 create mode 100644 doc/todo/better_way_to_get_missing_files.mdwn
 create mode 100644 doc/todo/bittorrent__58___support_offline_operation_and_verification.mdwn
 create mode 100644 doc/todo/bittorrent__58___support_offline_operation_and_verification/comment_1_ab16dfb6c3fe2a70ddfb0cee287c6127._comment
 create mode 100644 doc/todo/bittorrent__58___support_offline_operation_and_verification/comment_2_262f9d68a865300d894c4077e0e8a70c._comment
 create mode 100644 doc/todo/build_a_user_guide.mdwn
 create mode 100644 doc/todo/cache_key_info.mdwn
 create mode 100644 doc/todo/cache_key_info/comment_1_578df1b3b2cbfdc4aa1805378f35dc48._comment
 create mode 100644 doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__.mdwn
 create mode 100644 doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_1_c81e5d438b06e28392e4ae789a84a2e8._comment
 create mode 100644 doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_2_2cdaffbc72d5ef197a3ef7ffb306312e._comment
 create mode 100644 doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_3_4520660c0f66bd73158887f22586886e._comment
 create mode 100644 doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_4_ee750e205acefe400d13c3a5e967ca3b._comment
 create mode 100644 doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_5_ec644589ec44a442dc2f3bd2244c9800._comment
 create mode 100644 doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_6_aa8c191593789900e966a37f9117dd97._comment
 create mode 100644 doc/todo/calckey_cannot_be_used_outside_of_git_repo.mdwn
 create mode 100644 doc/todo/calckey_cannot_be_used_outside_of_git_repo/comment_1_c54b53c5f81132bedf75eb6b439a202d._comment
 create mode 100644 doc/todo/change_git-annex-import_not_to_delete_original_files_by_default.mdwn
 create mode 100644 doc/todo/change_git-annex-import_not_to_delete_original_files_by_default/comment_1_4eb794daaeef843b104bd480e11f7b42._comment
 create mode 100644 doc/todo/change_git-annex-import_not_to_delete_original_files_by_default/comment_2_f2d436822490e74544bf58a4f1c9ee79._comment
 create mode 100644 doc/todo/change_git-annex-import_not_to_delete_original_files_by_default/comment_3_6a7c2cbd85b5ac8e90933aaa9147e004._comment
 create mode 100644 doc/todo/checkpresentkey_without_explicit_remote.mdwn
 create mode 100644 doc/todo/cleaner_hack_for_man_pages.mdwn
 create mode 100644 doc/todo/cleaner_hack_for_man_pages/comment_1_d51be0df42cba6f3eba2b5157dc9d427._comment
 create mode 100644 doc/todo/cleaner_hack_for_man_pages/comment_2_3dd91f4c788c81a4f7368f673778c106._comment
 create mode 100644 doc/todo/command_to___34__migrate__34___from_adjusted_mode.mdwn
 create mode 100644 doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_10_551012fe6261269363719d83113d4e3c._comment
 create mode 100644 doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_1_8e9ecd2a3f9fc5cb80785b100aeb6e36._comment
 create mode 100644 doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_2_845206fa688ed4786262fe6d82464d97._comment
 create mode 100644 doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_3_4375a63a864306c39323fa4b159425d6._comment
 create mode 100644 doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_4_a0d4ffdf3edadb5381f242f65fa38932._comment
 create mode 100644 doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_5_55b5beaeba0de7bb1efcc2626570d3b5._comment
 create mode 100644 doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_6_a383c7303f1e942a830d9f730f1c0f00._comment
 create mode 100644 doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_6_e8ab74bb4951fe7f0c71630bb278ad6f._comment
 create mode 100644 doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_7_0ccaf798086a8c9511d3733b12b24c8b._comment
 create mode 100644 doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_7_e2d45ac485456ed9cb86f8e6bd23617c._comment
 create mode 100644 doc/todo/command_to_list_keys_for_old_versions_of_files.mdwn
 create mode 100644 doc/todo/command_to_list_keys_for_old_versions_of_files/comment_1_43c11d9467b4d4460aa97bfb88b4896f._comment
 create mode 100644 doc/todo/command_to_list_keys_for_old_versions_of_files/comment_2_5062a0f8b57fdebf74fef8a65ac0a0b2._comment
 create mode 100644 doc/todo/command_to_list_keys_for_old_versions_of_files/comment_3_3c605fbd4c20522e265ef080675c3669._comment
 create mode 100644 doc/todo/comment_1_98d09316dc39619203e507f862716bab._comment
 create mode 100644 doc/todo/complete_annex.skipunknown_transition_in_2022.mdwn
 create mode 100644 doc/todo/compute_special_remote.mdwn
 create mode 100644 doc/todo/compute_special_remote/comment_1_9f4835cd08d9d02009b685f4a366a245._comment
 create mode 100644 doc/todo/compute_special_remote/comment_2_bdb9c77b3ac97cef8d1b8eeaaf300d8b._comment
 create mode 100644 doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls.mdwn
 create mode 100644 doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_1_06d6dd17b7bd45b96276770b09bedca9._comment
 create mode 100644 doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_2_d9135802f29b78749833b7fd9967cc0b._comment
 create mode 100644 doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_3_8a6027fb58c4b7aaa3f82b5fd1c2812a._comment
 create mode 100644 doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_4_ceb543ebac42bf7a5f1571ff3f4ef977._comment
 create mode 100644 doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_5_ec99ba117fac299fc361a32de4ff29a5._comment
 create mode 100644 doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems.mdwn
 create mode 100644 doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_1_e3cd8d86869d8a63337f7eff0b91ddbc._comment
 create mode 100644 doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_2_3580025d828b27072530eb8ccda9bdf4._comment
 create mode 100644 doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_3_d300407d70f799958734df1722fe923b._comment
 create mode 100644 doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_4_9367cfc5e12e43db6b53f43dc468757f._comment
 create mode 100644 doc/todo/confirmed.mdwn
 create mode 100644 doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info.mdwn
 create mode 100644 doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_1_68c86b06b3b0c8cc9c3faac97e3f6c3f._comment
 create mode 100644 doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_2_8993cf9badc8348604c662e35ba6f199._comment
 create mode 100644 doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_3_53a7a0d5ba6be411bdae10a6f8ba16fc._comment
 create mode 100644 doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_4_d82ee205451cf55eb283952c4774d32a._comment
 create mode 100644 doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_5_3565680846a8d547d0912d1ef31430b2._comment
 create mode 100644 doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_6_e479e9b65a512727f2816d4abd72b900._comment
 create mode 100644 doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_7_d64e8d82f139146338ce2fd4af1b7ad7._comment
 create mode 100644 doc/todo/copy__47__move_support_for_pushinsteadOf_.mdwn
 create mode 100644 doc/todo/copy__47__move_support_for_pushinsteadOf_/comment_1_c5eec865ac5493f8bedf4fcba6759d6e._comment
 create mode 100644 doc/todo/copy__47__move_support_for_pushinsteadOf_/comment_2_b6d694d34e6d5a684249b11f53a8532f._comment
 create mode 100644 doc/todo/copy__47__move_support_for_pushinsteadOf_/comment_3_e53e69ae3adc42bb2bf36af1f07a4c83._comment
 create mode 100644 doc/todo/copy_instead_of_rename_on_reinject.mdwn
 create mode 100644 doc/todo/copy_instead_of_rename_on_reinject/comment_1_8e1fefa8231cc93f0f1958e44d869c47._comment
 create mode 100644 doc/todo/copy_with_both_--to_and_--from_.mdwn
 create mode 100644 doc/todo/copy_with_both_--to_and_--from_/comment_10_81fb304a2cdd50aa58f839a89d25f2ae._comment
 create mode 100644 doc/todo/copy_with_both_--to_and_--from_/comment_1_0c42c2269e2fe2888254cc14a4967535._comment
 create mode 100644 doc/todo/copy_with_both_--to_and_--from_/comment_2_7db9f62f5aa3640d1f4aeeb599e02e7c._comment
 create mode 100644 doc/todo/copy_with_both_--to_and_--from_/comment_3_05a8fbcf2b069c561b6e24286565af5f._comment
 create mode 100644 doc/todo/copy_with_both_--to_and_--from_/comment_4_b4d6b876c8f36a61268e2144d3bcf082._comment
 create mode 100644 doc/todo/copy_with_both_--to_and_--from_/comment_5_8fbf7e5ef86892f05b63e73373a97f0f._comment
 create mode 100644 doc/todo/copy_with_both_--to_and_--from_/comment_6_4397649b4a2115891cb0f597999cca66._comment
 create mode 100644 doc/todo/copy_with_both_--to_and_--from_/comment_6_959f6081cb3cb777ea4fad70bad07da3._comment
 create mode 100644 doc/todo/copy_with_both_--to_and_--from_/comment_8_a230b52cd5985437827bb432a85349ce._comment
 create mode 100644 doc/todo/copy_with_both_--to_and_--from_/comment_9_3152d196f56561d31a00514c343669ad._comment
 create mode 100644 doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__.mdwn
 create mode 100644 doc/todo/create_debug_logs_but_erase_them_on_success.mdwn
 create mode 100644 doc/todo/create_debug_logs_but_erase_them_on_success/comment_1_72b1e3b25a221f42ea7919aaecd6012d._comment
 create mode 100644 doc/todo/create_debug_logs_but_erase_them_on_success/comment_2_8809f216aac308962917053ea24b9022._comment
 create mode 100644 doc/todo/debug_for___34__content_changed_while_it_was_being_sent.mdwn
 create mode 100644 doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_1_bce631c26907d03314cfc2e94933cce9._comment
 create mode 100644 doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_2_8093d410c2b359967ee7ee8886d7e4c4._comment
 create mode 100644 doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_3_78551b601b04b8336a858adfcff29507._comment
 create mode 100644 doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_4_d9faaaf2dd44e609fcf361189b247bed._comment
 create mode 100644 doc/todo/deferred_update_mode.mdwn
 create mode 100644 doc/todo/deleting_a_repository_from_history.mdwn
 create mode 100644 doc/todo/deleting_a_repository_from_history/comment_1_bcaa591f37f3496c2f7a2e1f06450002._comment
 create mode 100644 doc/todo/deleting_a_repository_from_history/comment_2_69de586c7c030f75fd540d05a6ca4ddb._comment
 create mode 100644 doc/todo/detect_and_handle_submodules_after_path_changed_by_mv.mdwn
 create mode 100644 doc/todo/detect_and_handle_submodules_after_path_changed_by_mv/comment_1_9f9da126a031d2a4c98555b381dbcbdc._comment
 create mode 100644 doc/todo/distributed_migration.mdwn
 create mode 100644 doc/todo/distributed_migration/comment_1_8734d30aa0c1cb27dce81a0277d24948._comment
 create mode 100644 doc/todo/distributed_migration/comment_2_fdaef5d870221d44c57fc3bd1501e7ee._comment
 create mode 100644 doc/todo/distributed_migration_for_special_remotes.mdwn
 create mode 100644 doc/todo/ditch_yesod.mdwn
 create mode 100644 doc/todo/ditch_yesod/comment_1_976dcb99ebe30c02c9b223f19a67c875._comment
 create mode 100644 doc/todo/do_not_bug_me_about_intermediate_files.mdwn
 create mode 100644 doc/todo/do_not_count_trusted_repos_toward_mincopies.mdwn
 create mode 100644 doc/todo/do_not_count_trusted_repos_toward_mincopies/comment_1_66a71fdd9bdc2387870f4216841b9900._comment
 create mode 100644 doc/todo/do_not_count_trusted_repos_toward_mincopies/comment_2_058f521451ff38d2072af6c944143ab1._comment
 create mode 100644 doc/todo/dockerized_external_special_remotes.mdwn
 create mode 100644 doc/todo/dockerized_external_special_remotes/comment_10_82d0eba3b5658990aa1e909758d75291._comment
 create mode 100644 doc/todo/dockerized_external_special_remotes/comment_1_d1a0106951c070b56bc30a67c8804374._comment
 create mode 100644 doc/todo/dockerized_external_special_remotes/comment_2_61a23adb5b871b178d3fb5a51602cf46._comment
 create mode 100644 doc/todo/dockerized_external_special_remotes/comment_3_a044848ea54aebc2196376f9a59ccc70._comment
 create mode 100644 doc/todo/dockerized_external_special_remotes/comment_4_3ace886382ff165db6f36df8743ca7c1._comment
 create mode 100644 doc/todo/dockerized_external_special_remotes/comment_5_4e09e2a08f07924ef791d63da56df066._comment
 create mode 100644 doc/todo/dockerized_external_special_remotes/comment_6_c43d5137b595edc3db130158293431ff._comment
 create mode 100644 doc/todo/dockerized_external_special_remotes/comment_7_dc3e46508758b1df241ba0af78fbc692._comment
 create mode 100644 doc/todo/dockerized_external_special_remotes/comment_8_a32b4ec09da1bee3c960fa8fcfa0d797._comment
 create mode 100644 doc/todo/dockerized_external_special_remotes/comment_9_f5c0b77e06b7a65f2582c56011217d5c._comment
 create mode 100644 doc/todo/document_git-annex_dependencies.mdwn
 create mode 100644 doc/todo/document_git-annex_dependencies/comment_1_bb9cbd703e57adb9ca45e2cea94308a0._comment
 create mode 100644 doc/todo/document_git-annex_dependencies/comment_2_bcd0fa1ace9a22b0cc09cea2e7cad84c._comment
 create mode 100644 doc/todo/document_git-annex_dependencies/comment_3_ac0b1db3d447240b49686920a71ff91b._comment
 create mode 100644 doc/todo/document_standard_groups_more_extensively_in_the_UI.mdwn
 create mode 100644 doc/todo/documentation__58___improve_on_special_remotes.mdwn
 create mode 100644 doc/todo/documentation__58___improve_on_special_remotes/comment_1_edd0a4e9894d07e7bae9fef1fe4acf6d._comment
 create mode 100644 doc/todo/documenting_sqlite_database_schemas.mdwn
 create mode 100644 doc/todo/documenting_sqlite_database_schemas/comment_1_cc94cb2467c2b261c0b79c64853103a5._comment
 create mode 100644 doc/todo/documenting_sqlite_database_schemas/comment_2_06bc5d625d9a3e7522c7f6df53a7ac3d._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps.mdwn
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_10_8cce043ff86fefc3dcd97cf5c4428786._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_11_eea115becce4ac79932d8cfa2903f20c._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_12_a8b69299c9278c16c6c5061d88bc7eca._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_13_e37ea5188bd48817ccac82141906ee83._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_14_9a3f50f1b8cfd1cc0da83937a36e1369._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_1_caf5e5cb17f4d05fff8c2fab661cd93f._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_2_c337fca1474b5b78f61ad6f421138ae4._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_3_9a3eeddc46e5a420575f00cb47caf703._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_4_99b064259fc2e3c6eb83c3da3b2d3bac._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_5_c95c8b9bd617830604500213c962fc7a._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_6_b99e00d0bc4258c4cb28b544b19ea3b8._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_7_eefa6afce824f1069bb5216b392405b7._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_8_f2a32e39356f7b772ab9cf3136436700._comment
 create mode 100644 doc/todo/does_not_preserve_timestamps/comment_9_62736ee2f299d62f685800353fc36ccf._comment
 create mode 100644 doc/todo/done.mdwn
 create mode 100644 doc/todo/drop_--batch.mdwn
 create mode 100644 doc/todo/drop_from_export_remote.mdwn
 create mode 100644 doc/todo/dynamic_stall_detection.mdwn
 create mode 100644 doc/todo/enable_a_discussion_forum_or_support_system.mdwn
 create mode 100644 doc/todo/enable_a_discussion_forum_or_support_system/comment_1_578c0ab40d53dd56bb3f2d98491c5e85._comment
 create mode 100644 doc/todo/enable_a_discussion_forum_or_support_system/comment_2_b1129b4cdfe39e740c4f7cf0d6ff2b91._comment
 create mode 100644 doc/todo/enable_a_discussion_forum_or_support_system/comment_3_52598af3d7b050981e32ad1569f69db9._comment
 create mode 100644 doc/todo/encrypt_only_the_credentials.mdwn
 create mode 100644 doc/todo/encrypt_only_the_credentials/comment_1_7c3911e8fbc981c7e1f32b1464ce4122._comment
 create mode 100644 doc/todo/encrypt_only_the_credentials/comment_2_76fdfa927562d33dfea9630b3b729220._comment
 create mode 100644 doc/todo/encrypt_only_the_credentials/comment_3_6f0ba120ef655d5250fdf3db53464fe6._comment
 create mode 100644 doc/todo/encrypted_keys_in_git_repository.mdwn
 create mode 100644 doc/todo/encrypted_keys_in_git_repository/comment_1_4d17c427756127f22dc472984259f8d7._comment
 create mode 100644 doc/todo/encrypted_keys_in_git_repository/comment_2_6679caba100bee0a0fe32c8eef50758e._comment
 create mode 100644 doc/todo/encrypted_keys_in_git_repository/comment_3_a79ea55e2f8a1095f0110f2f0853dee1._comment
 create mode 100644 doc/todo/encrypted_keys_in_git_repository/comment_4_e88664a0939b7bca730a61efb47d34ab._comment
 create mode 100644 doc/todo/encrypted_keys_in_git_repository/comment_5_05b0e2e88b233691b403d4c908b50c52._comment
 create mode 100644 doc/todo/encrypted_keys_in_git_repository/comment_6_9e25b4d05d61fc3a3cca4f7111681a5f._comment
 create mode 100644 doc/todo/encrypting_URLs.mdwn
 create mode 100644 doc/todo/encrypting_URLs/comment_1_9d0dda82d1f3907e6478a95608388836._comment
 create mode 100644 doc/todo/explicit_metadata_needed_for_view_inclusion_or_not.mdwn
 create mode 100644 doc/todo/explicit_metadata_needed_for_view_inclusion_or_not/comment_1_17f8adc8555ea0a2716308e3f5188a25._comment
 create mode 100644 doc/todo/export_--json_--json-progress_--json-error-messages.mdwn
 create mode 100644 doc/todo/export_paired_rename_innefficenctcy.mdwn
 create mode 100644 doc/todo/expose_fsck_last_run_information.mdwn
 create mode 100644 doc/todo/expose_fsck_last_run_information/comment_1_44f5eb2e601ba1a6cb22f5de7a6d3ff6._comment
 create mode 100644 doc/todo/expose_fsck_last_run_information/comment_2_9a1729dfbec291159000d3412dd147d7._comment
 create mode 100644 doc/todo/external_backends.mdwn
 create mode 100644 doc/todo/external_backends/comment_10_4c0f8a338a58cef8e239613292d5aa38._comment
 create mode 100644 doc/todo/external_backends/comment_11_56224638fde7b46ee6f52211474cd047._comment
 create mode 100644 doc/todo/external_backends/comment_12_268cd038b7beb9d42cf0bd8803efce94._comment
 create mode 100644 doc/todo/external_backends/comment_13_6e8452f06da80458bb2cccde05cc9813._comment
 create mode 100644 doc/todo/external_backends/comment_14_6edc4008ce8eec17e283dd7db8dbcbf0._comment
 create mode 100644 doc/todo/external_backends/comment_15_7880557cb94706d82a6d2bfc785288ea._comment
 create mode 100644 doc/todo/external_backends/comment_1_9d73d6dbfabe3d58a41b661825bf3dcb._comment
 create mode 100644 doc/todo/external_backends/comment_2_a2528865e48f85feab5569951f13caa9._comment
 create mode 100644 doc/todo/external_backends/comment_3_9451d002f6768dd5975d5816c12b1350._comment
 create mode 100644 doc/todo/external_backends/comment_4_2983bbf5e1cc485da3e8e9628a4bea89._comment
 create mode 100644 doc/todo/external_backends/comment_5_37fd824cf9f2dcc59616b9d49e38c262._comment
 create mode 100644 doc/todo/external_backends/comment_6_d871bdf09932035acc6260c839f45757._comment
 create mode 100644 doc/todo/external_backends/comment_7_090e62b5d37beb5d62d56cfb3b1e2134._comment
 create mode 100644 doc/todo/external_backends/comment_8_e3c66820da36fe255d07059226690ca4._comment
 create mode 100644 doc/todo/external_backends/comment_9_bf2de8fdc134684f0af2b53bc9b78f08._comment
 create mode 100644 doc/todo/external_remote_querying_transition.mdwn
 create mode 100644 doc/todo/external_remote_querying_transition/comment_1_838311ffa7f00d65c9ab23717dd117aa._comment
 create mode 100644 doc/todo/external_remotes__58___Add_support_for_ErrorMsg_to_-FAILURE_messages_lacking_it.mdwn
 create mode 100644 doc/todo/external_remotes__58___Add_support_for_ErrorMsg_to_-FAILURE_messages_lacking_it/comment_1_a096df37d5bc5543b574b32554311af9._comment
 create mode 100644 doc/todo/external_special_remotes_not_using_git-annex-remote_in_name.mdwn
 create mode 100644 doc/todo/external_special_remotes_not_using_git-annex-remote_in_name/comment_1_8bb17f1a8297b500dcc5bdf9412a5d6c._comment
 create mode 100644 doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__.mdwn
 create mode 100644 doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_1_9c77d8cf628025308c2561a8a46d2365._comment
 create mode 100644 doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_2_0d7eb254ec9ff7ba8b1831898008747f._comment
 create mode 100644 doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_3_26f82b5ef0ce9dc0a5a8fc64f4a3b335._comment
 create mode 100644 doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_4_3e2b49710772340238358041ba91bc25._comment
 create mode 100644 doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_5_009ffc560a14061feb8d748e1d2d9b71._comment
 create mode 100644 doc/todo/faster_incremental_update_of_view_branch_by_git-annex_sync.mdwn
 create mode 100644 doc/todo/filter-branch_for_objects.mdwn
 create mode 100644 doc/todo/find__47__prefer_keys_by_file_extension_in_key.mdwn
 create mode 100644 doc/todo/find__47__prefer_keys_by_file_extension_in_key/comment_1_fcf6f2c6ecf49930f4ddbf9b35301bf3._comment
 create mode 100644 doc/todo/find__47__prefer_keys_by_file_extension_in_key/comment_2_751137f0fd1815adfef69bec6a2cbe22._comment
 create mode 100644 doc/todo/findkeys.mdwn
 create mode 100644 doc/todo/findkeys/comment_1_da758b20bca40e0580526e52ea3e9a61._comment
 create mode 100644 doc/todo/finish_sync_content_transition.mdwn
 create mode 100644 doc/todo/force_star_topology_on_a_repository.mdwn
 create mode 100644 doc/todo/force_star_topology_on_a_repository/comment_1_cffe5ae2b85022ac9f58ce668ec9bf97._comment
 create mode 100644 doc/todo/force_star_topology_on_a_repository/comment_2_6e735205024588497a116ce9e7e621a9._comment
 create mode 100644 doc/todo/force_star_topology_on_a_repository/comment_3_154614345d2b8f4260c88e9061bf4255._comment
 create mode 100644 doc/todo/force_star_topology_on_a_repository/comment_4_a722bce9ea8c94864657415395eadb43._comment
 create mode 100644 doc/todo/force_star_topology_on_a_repository/comment_5_60d832d97923d3aac047dd525dc8df12._comment
 create mode 100644 doc/todo/force_star_topology_on_a_repository/comment_6_8bb1f37233055c53d98c73fed4224b50._comment
 create mode 100644 doc/todo/force_star_topology_on_a_repository/comment_7_6b08f09f690f7791f59cb90db01c4cf0._comment
 create mode 100644 doc/todo/force_star_topology_on_a_repository/comment_8_f840a405028df2630a7c8eac5091833f._comment
 create mode 100644 doc/todo/forget_dead_keys.mdwn
 create mode 100644 doc/todo/forget_dead_keys/comment_1_e4c7db734087dc4c2f6b86bb774136fd._comment
 create mode 100644 doc/todo/free_space_checking_for_local_special_remotes.mdwn
 create mode 100644 doc/todo/free_space_checking_for_local_special_remotes/comment_1_47c254cec58cbbb3ea84c93ef8282f01._comment
 create mode 100644 doc/todo/fsck_scrub.mdwn
 create mode 100644 doc/todo/fsverify.mdwn
 create mode 100644 doc/todo/generic_readonly_http_remote/comment_1_5fcd23950ed5409e52d7954abf71afa9._comment
 create mode 100644 doc/todo/generic_readonly_http_remote/comment_2_c81b458a8ee0f15950adbd32dd168972._comment
 create mode 100644 doc/todo/generic_readonly_http_remote/comment_3_6d95fc858ca780f087c48e4a6a4ab25b._comment
 create mode 100644 doc/todo/generic_readonly_http_remote/comment_4_551bbaf8f22add6ad1e2774e76a1d078._comment
 create mode 100644 doc/todo/generic_readonly_http_remote/comment_5_bfbec043d803ff1aa649f2661f6918f4._comment
 create mode 100644 doc/todo/get_--batch.mdwn
 create mode 100644 doc/todo/git-annex-addunused-historical.mdwn
 create mode 100644 doc/todo/git-annex-cat.mdwn
 create mode 100644 doc/todo/git-annex-cat/comment_1_a5da8264c2d662e96802535820cb2249._comment
 create mode 100644 doc/todo/git-annex-cat/comment_2_a43a3568e48e6b5e93998bc473178d5c._comment
 create mode 100644 doc/todo/git-annex-cat/comment_3_347a33a4a77fd385ab8f3551138b75e1._comment
 create mode 100644 doc/todo/git-annex-cat/comment_4_8708bf0aef0025e2ed1a8b9d2a7f0112._comment
 create mode 100644 doc/todo/git-annex-cat/comment_5_f78a6a136610f3fca7a02a3af9c19e25._comment
 create mode 100644 doc/todo/git-annex-export_--from_option.mdwn
 create mode 100644 doc/todo/git-annex-export_--from_option/comment_1_10f107aa0094d5ee4886878f5b1aaf06._comment
 create mode 100644 doc/todo/git-annex-export_--from_option/comment_2_72e7dc2a6b3cec21c941a5f7a2914050._comment
 create mode 100644 doc/todo/git-annex-migrate_using_git-replace.mdwn
 create mode 100644 doc/todo/git-annex-migrate_using_git-replace/comment_1_6a317be851dfb72c4aaaf5786dd1a1ff._comment
 create mode 100644 doc/todo/git-annex-migrate_using_git-replace/comment_2_e760213fc51f6a2cfc68dec711622f25._comment
 create mode 100644 doc/todo/git-annex-sync_handling_of_linked_worktrees.mdwn
 create mode 100644 doc/todo/git-annex-sync_handling_of_linked_worktrees/comment_1_3e542583247177f9cdf44122ec483a0c._comment
 create mode 100644 doc/todo/git-annex-test___58___skip_tests_if_external_utils_have_problems.mdwn
 create mode 100644 doc/todo/git-annex-test___58___skip_tests_if_external_utils_have_problems/comment_1_240c9c45a629124dc35f4ed0dddd7355._comment
 create mode 100644 doc/todo/git-annex-unused_--history.mdwn
 create mode 100644 doc/todo/git-annex-unused_--history/comment_1_9b9518a88e5f90d68b4131c430e66881._comment
 create mode 100644 doc/todo/git-annex-unused_--history/comment_2_d0aa8cc29e38510b2bb1c4ce356aa2ac._comment
 create mode 100644 doc/todo/git-annex-unused_--history/comment_3_21797e55d27356411430b3ec07af5264._comment
 create mode 100644 doc/todo/git-hook_to_sanity-check_git-annex_branch_pushes.mdwn
 create mode 100644 doc/todo/git-lfs_special_remote_simpler_setup.mdwn
 create mode 100644 doc/todo/git-lfs_special_remote_simpler_setup/comment_1_4e9f8b60dd1b705d4755200dada8801c._comment
 create mode 100644 doc/todo/git-remote-annex.mdwn
 create mode 100644 doc/todo/git_annex_info___60__remote__62___does_not_list_all_the_parameters_for_the_remote.mdwn
 create mode 100644 doc/todo/git_annex_info___60__remote__62___does_not_list_all_the_parameters_for_the_remote/comment_1_875fdf1aacff3cc2c3732450f052d711._comment
 create mode 100644 doc/todo/git_annex_info_to_include_information_about_repo_version__63__.mdwn
 create mode 100644 doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_1_783c53fd99747bc65bd832f918c50a59._comment
 create mode 100644 doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_2_60d3b088de83c86243b19c3d0d050080._comment
 create mode 100644 doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_3_d6e84551319439ba50bc10edbd25335c._comment
 create mode 100644 doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_4_5b3e45c746e6cfa7f511790bbd9f6c9f._comment
 create mode 100644 doc/todo/git_annex_repair__58___performance_can_be_abysmal__44___huge_improvements_possible.mdwn
 create mode 100644 doc/todo/git_annex_repair__58___performance_can_be_abysmal__44___huge_improvements_possible/comment_1_4828098be3e7cd6109bd1934bf029f1f._comment
 create mode 100644 doc/todo/git_annex_upgrade_to_not_care_about_submod_status__63__.mdwn
 create mode 100644 doc/todo/git_annex_upgrade_to_not_care_about_submod_status__63__/comment_1_607ec43498187636312693932f66cc6d._comment
 create mode 100644 doc/todo/git_fetch_and_push_to_import_export_remote.mdwn
 create mode 100644 doc/todo/git_repo_tracking___40__not_storage__41__.mdwn
 create mode 100644 doc/todo/git_repo_tracking___40__not_storage__41__/comment_1_e47bc088880a9e839f5c437117c58b68._comment
 create mode 100644 doc/todo/git_repo_tracking___40__not_storage__41__/comment_2_4af24f7207f63eb4cc127a64c1fc5fc3._comment
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal.mdwn
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_10_2247cea7e7ca09389073fb32e98394e7._comment
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_11_39e671908522b79b8054ed9ddcaf918c._comment
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_12_bb2bf0e82985bf2045741205c4682813._comment
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_1_b41830b59c47ce5041c6005d41baf550._comment
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_2_8ad0fa4f67af60313d3195bc8c0acfb8._comment
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_3_778d21703afc5c08bfbc387b442cc193._comment
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_4_ef42e80aac54e02000c1a61b1f42aed0._comment
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_5_8da190f9f0cece7215df28b0bc47b151._comment
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_6_69b4455c0e54834503794f6f65de1fc8._comment
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_7_d52b1ab7d6a186919b3edfd51347e161._comment
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_8_e99ecb0ac561dd670f3ea7b2915de872._comment
 create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_9_ccea12d55706ab2fc1b0ba46818354a3._comment
 create mode 100644 doc/todo/git_status_smudges_unncessarily_after_unlock.mdwn
 create mode 100644 doc/todo/globus_special_remote_as_a___34__transport__34___layer.mdwn
 create mode 100644 doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_1_f2c68afc949f54939fc760bd0d916b89._comment
 create mode 100644 doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_2_89be9eea4304897c639fa80db92cfe2c._comment
 create mode 100644 doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_3_43107f1bec1ad141af2e97f715a70fe9._comment
 create mode 100644 doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_3_9c557a788841bd34e5fa902e171d2b52._comment
 create mode 100644 doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_4_3bea0473d4805b1ef56b955ba30166e8._comment
 create mode 100644 doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_5_28aabb525a1a487eaecdfe591cc7108b._comment
 create mode 100644 doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_6_51b2078904c6a7c0fff2dd7d38791e6b._comment
 create mode 100644 doc/todo/hidden_files.mdwn
 create mode 100644 doc/todo/hiding_a_repository.mdwn
 create mode 100644 doc/todo/hiding_a_repository/comment_1_68636f0a35a1cd62e0390d1a752eba47._comment
 create mode 100644 doc/todo/hiding_a_repository/comment_2_5d8224fdb6c77834b3bf55b2148d9f97._comment
 create mode 100644 doc/todo/hiding_a_repository/comment_3_64ba3f1d5099e066d554566ca818bdd6._comment
 create mode 100644 doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers.mdwn
 create mode 100644 doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_1_64397d2700c9ab13885024b65d4d5adc._comment
 create mode 100644 doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_2_f2f2986f643c654c3d87be832687fc68._comment
 create mode 100644 doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_3_7e07ab418734d22ab032bb655b4b3645._comment
 create mode 100644 doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_4_0c4110101bf810816d4568b37018211e._comment
 create mode 100644 doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_5_ab2c969b5b561b75fec1d95c52598cb4._comment
 create mode 100644 doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_6_877ae38938a279fa100e58c03990e81a._comment
 create mode 100644 doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_7_59aa5bd5ac6cfe5976666853b5ce9fdc._comment
 create mode 100644 doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_7_c0f5b5098252df0f86528078f3c96ec7._comment
 create mode 100644 doc/todo/immediate_stream-to-sync.mdwn
 create mode 100644 doc/todo/immediate_stream-to-sync/comment_1_457523845c5e63bae90ea5a84d57bf96._comment
 create mode 100644 doc/todo/import_from_directory_does_not_use_cp_--reflink__63___.mdwn
 create mode 100644 doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_1_7a297f170720daf25f7ecf133aafc6a4._comment
 create mode 100644 doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_2_04b63e4e2092ed455d23657e2b396d3b._comment
 create mode 100644 doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_3_20e31ffc7c490215db7a3f1a0a3b813c._comment
 create mode 100644 doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_3_50ae4126d701dbd3a0c9ed8770404228._comment
 create mode 100644 doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_4_fca845bb9869e8ce9a279952813ce481._comment
 create mode 100644 doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_5_f1475420fd16e664b907c4f24910a8d1._comment
 create mode 100644 doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_7_b57afb61d622d9f5b2555e7d80d0ff4e._comment
 create mode 100644 doc/todo/import_only_remotes_need_a_way_to_resolve_conflicts.mdwn
 create mode 100644 doc/todo/import_symlinks_when_importing_from_directory.mdwn
 create mode 100644 doc/todo/import_symlinks_when_importing_from_directory/comment_1_60b1a3ab291bc7eec2ba2ad6ee044bfe._comment
 create mode 100644 doc/todo/import_tree_from_rsync_special_remote.mdwn
 create mode 100644 doc/todo/import_tree_from_rsync_special_remote/comment_1_b1f97f8d62c4e2f9bbe02955c7a4dec4._comment
 create mode 100644 doc/todo/import_tree_from_rsync_special_remote/comment_2_7e62dbfc5540a8737d77f25ad2acc4af._comment
 create mode 100644 doc/todo/import_tree_from_rsync_special_remote/comment_3_1d3acf47e3eff3680c1639de12823940._comment
 create mode 100644 doc/todo/import_tree_preferred_content_expansions.mdwn
 create mode 100644 doc/todo/import_tree_preferred_content_expansions/comment_1_df8ca8665e1dfc530a832b6d24d60ea4._comment
 create mode 100644 doc/todo/importfeed_needs_more_memory_the_more_urls_there_are.mdwn
 create mode 100644 doc/todo/importfeed_parallell.mdwn
 create mode 100644 doc/todo/importtree_only_remotes.mdwn
 create mode 100644 doc/todo/improve_memory_usage_of_--all.mdwn
 create mode 100644 doc/todo/improve_unused_for_special_remotes.mdwn
 create mode 100644 doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output.mdwn
 create mode 100644 doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_1_f02e43b68c219b2d7d65ea868fac125f._comment
 create mode 100644 doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_2_3a7043652c692796b1a438a2c4c26828._comment
 create mode 100644 doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_3_2d41d67dcb6e700b1ecda3106e444a5e._comment
 create mode 100644 doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_4_c2e5041a07787ae84f85b898b1aae6b7._comment
 create mode 100644 doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_5_429e42b9c1989dade01300f08fc3c13c._comment
 create mode 100644 doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_6_3d5a33476a3fa773fda1e5f7a2d8c453._comment
 create mode 100644 doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_7_246e35f32f77af3b2924577b1bf45001._comment
 create mode 100644 doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_8_2e0ec2bb51a2a06184b94710616f211c._comment
 create mode 100644 doc/todo/incremental_hashing_for_add.mdwn
 create mode 100644 doc/todo/incremental_hashing_for_add/comment_1_d00827f5edd7b270aa6dfc011e7c9f22._comment
 create mode 100644 doc/todo/incremental_hashing_for_add/comment_2_30b4c0f3b1c13e9a1a2ddba5f88eb6ee._comment
 create mode 100644 doc/todo/info_--size-history.mdwn
 create mode 100644 doc/todo/info__58___allow_file_matching_options_for_all_keys.mdwn
 create mode 100644 doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_1_3b96becda1db6ae23adb5077b6332718._comment
 create mode 100644 doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_2_2d0a6abd5be8afce677eeea575aae548._comment
 create mode 100644 doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_3_aae866dc71811074d69b91c2390ccb01._comment
 create mode 100644 doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_4_371d53b4539bee6e3d595154033a2471._comment
 create mode 100644 doc/todo/info_show_total_annex_sizes_of_repositories.mdwn
 create mode 100644 doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch.mdwn
 create mode 100644 doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch/comment_1_2ff094dd4ff1fb05db90782d381441d3._comment
 create mode 100644 doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch/comment_2_2cbfb22e8f1d89d4f78ade565554cb1c._comment
 create mode 100644 doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch/comment_3_fe771be800a6b26157c3075e632ee1b7._comment
 create mode 100644 doc/todo/interface_to_the___34__progress__34___of_annex_operations.mdwn
 create mode 100644 doc/todo/keep_git-annex_branch_checked_out__63__.mdwn
 create mode 100644 doc/todo/keep_git-annex_branch_checked_out__63__/comment_1_cd967b89dbebd431a14b0dcd08ebc67c._comment
 create mode 100644 doc/todo/keep_git-annex_branch_checked_out__63__/comment_2_620cfbb2e2507d340dfb25d1fcd2cdfa._comment
 create mode 100644 doc/todo/key_checksum_from_chunk_checksums.mdwn
 create mode 100644 doc/todo/key_checksum_from_chunk_checksums/comment_1_946e2679cafd2c74a3b0b408e39f2d8d._comment
 create mode 100644 doc/todo/key_checksum_from_chunk_checksums/comment_2_aaff896ff99366d3b96c523284c1248e._comment
 create mode 100644 doc/todo/key_checksum_from_chunk_checksums/comment_3_352bc3eb419184a4ec70ddaffd78968e._comment
 create mode 100644 doc/todo/key_checksum_from_chunk_checksums/comment_4_e766f725e22ea0a38ac2277e08fd3839._comment
 create mode 100644 doc/todo/key_checksum_from_chunk_checksums/comment_5_561b9bb28c5d375334ce915da75d5ce6._comment
 create mode 100644 doc/todo/learn_about_remotes_that_are_currently_unavailable.mdwn
 create mode 100644 doc/todo/let_external_remotes_declare_support_for_named_pipes.mdwn
 create mode 100644 doc/todo/let_git-annex-matching-options_query_gitattributes.mdwn
 create mode 100644 doc/todo/let_git-annex-matching-options_query_gitattributes/comment_1_3e7c731037b8ce7148a6a597783d2ba3._comment
 create mode 100644 doc/todo/lockContent_for_special_remotes.mdwn
 create mode 100644 doc/todo/lockContent_for_special_remotes/comment_1_835d075d22fd1544fc27b912ad3326d8._comment
 create mode 100644 doc/todo/lockContent_for_special_remotes/comment_2_948993c967f7908adaea068e352e0607._comment
 create mode 100644 doc/todo/lockContent_for_special_remotes/comment_3_432fc28c4e09fd514fd780ec16b9423e._comment
 create mode 100644 doc/todo/lockContent_for_special_remotes/comment_4_13f4b8e180c727b775807e8e2aa5a11f._comment
 create mode 100644 doc/todo/lockContent_for_special_remotes/comment_5_b006d6bca93a50e1f23a2b6d20584c91._comment
 create mode 100644 doc/todo/lockContent_for_special_remotes/comment_6_01cc0fba0368fcda594d2835247dd884._comment
 create mode 100644 doc/todo/lockContent_for_special_remotes/comment_7_463e336fd7f2cb21eff2d87d25851c39._comment
 create mode 100644 doc/todo/lockdown_hooks.mdwn
 create mode 100644 doc/todo/lockdown_hooks/comment_1_649dbc3c951bbabc550e12e87e45b319._comment
 create mode 100644 doc/todo/lockdown_hooks/comment_2_575c33970014662c664d71e573e718e7._comment
 create mode 100644 doc/todo/lockdown_hooks/comment_3_f57299385578914f5bca05f06b76cd46._comment
 create mode 100644 doc/todo/lockdown_hooks/comment_4_614d2c8c758f9920cd84748f8f0d384e._comment
 create mode 100644 doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote.mdwn
 create mode 100644 doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote/comment_1_dbe339cb1860d27ebc7116ab4d6e50fb._comment
 create mode 100644 doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote/comment_2_06e98b0e0704dce8ced214600d0d6347._comment
 create mode 100644 doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote/comment_3_1c1aaecf15ee220ed5c39def48ccd734._comment
 create mode 100644 doc/todo/make_add_--batch_add_directories_content.mdwn
 create mode 100644 doc/todo/make_add_--batch_add_directories_content/comment_1_e5707f72bb086c342c89fc3b5ccf00e5._comment
 create mode 100644 doc/todo/make_add_--batch_add_directories_content/comment_2_5083e5a729f56dab76bdc97fb247b902._comment
 create mode 100644 doc/todo/make_add_--batch_add_directories_content/comment_3_e320d2c3b625f24e2b93c5dab21a1e0f._comment
 create mode 100644 doc/todo/make_add_--batch_add_directories_content/comment_4_98c678aefbc62aed7ceec8c7519d343a._comment
 create mode 100644 doc/todo/make_add_--batch_add_directories_content/comment_5_4cfd430f9e9196ec293fb118e5118160._comment
 create mode 100644 doc/todo/make_add_--batch_add_directories_content/comment_6_93cb877bf71acddcf15a6c1ed48d2768._comment
 create mode 100644 doc/todo/make_add_--batch_add_directories_content/comment_7_2155ce0ab07a84a4f36bcf92c29ec792._comment
 create mode 100644 doc/todo/make_add_--batch_add_directories_content/comment_8_5d63312c2efe3f1a25f9254ed230c66b._comment
 create mode 100644 doc/todo/make_add_--batch_add_directories_content/comment_9_0bbdcf13e0ea7869c1633a34457d9a86._comment
 create mode 100644 doc/todo/make_addurl_respect_annex.largefiles_option.mdwn
 create mode 100644 doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg.mdwn
 create mode 100644 doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_1_e7f759dccbfa134a772f15bc5f9c4b29._comment
 create mode 100644 doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_2_acd656bf30f7e0b5def7ad7a564cf914._comment
 create mode 100644 doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_3_0f49414f9b4a68a16a8d47a336242f13._comment
 create mode 100644 doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_4_203a356c1edfaf8c0c9cf01bedc2ec5d._comment
 create mode 100644 doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_5_c7a888605dd063fe7df7c569f1193f8c._comment
 create mode 100644 doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_6_b8bb9e5c7156e4defd7a2e8b7777e1ba._comment
 create mode 100644 doc/todo/make_annex_info_more_efficient.mdwn
 create mode 100644 doc/todo/make_annex_info_more_efficient/comment_1_afd5c806f7285442401b027f82a8c629._comment
 create mode 100644 doc/todo/make_annex_info_more_efficient/comment_2_0770ef5c4c261949a565723073480dcb._comment
 create mode 100644 doc/todo/make_annex_info_more_efficient/comment_3_c022caab61061b1f77b78485089a9052._comment
 create mode 100644 doc/todo/make_annex_info_more_efficient/comment_4_923dd7c22920b389488ca2625225164c._comment
 create mode 100644 doc/todo/make_annex_info_more_efficient/comment_5_c6c8850aefe3ab81f1f113daa734695b._comment
 create mode 100644 doc/todo/make_annex_info_more_efficient/comment_6_804dbb72757b09e3abad3e249f704da0._comment
 create mode 100644 doc/todo/make_annex_info_more_efficient/comment_7_44efc2bfcdde576aaca002595476a2a2._comment
 create mode 100644 doc/todo/make_annex_info_more_efficient/comment_8_90a22c51b19707ee0cecbe652c6ffa98._comment
 create mode 100644 doc/todo/make_annex_info_more_efficient/comment_9_3bec13ce0c9f0932715d73106d576e86._comment
 create mode 100644 doc/todo/make_copy_--fast__faster.mdwn
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_10_1af4ac0d37c876912678522895c1656b._comment
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_11_1ca8d9765e6e3a18ae09df74bc390a00._comment
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_12_14856a2886cf73d1bee57ef9fad01661._comment
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_13_0f8e2127cea96c4f9609fa7599b1eec9._comment
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_1_24a9ca652007a18f18b368232cf549da._comment
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_2_0c67f467d730a0966b43171de0382c42._comment
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_3_5cd9e6b5d6d015120b5852bd212314aa._comment
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_4_3ac10a07c74e5debafc9ae574d26c955._comment
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_5_eb7008151a59e35c7850df3a86cf3587._comment
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_6_3a08de49e9661f9df5bab272e170461a._comment
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_7_3f52b6e19035d3c891356c6d98035987._comment
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_8_c1f99493f5e5c362d5c39f048280b11b._comment
 create mode 100644 doc/todo/make_copy_--fast__faster/comment_9_f4d802a28b79905da0cb24af6cb65b0a._comment
 create mode 100644 doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__.mdwn
 create mode 100644 doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_1_f8ea668cd8a405226113ef2edeb9e678._comment
 create mode 100644 doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_2_50d04e85c0504f920ed7d2ccb9cdb6dd._comment
 create mode 100644 doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_3_2ebd0de2fe55230f4e589bd295c828a2._comment
 create mode 100644 doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_4_7d1154d80feca270f6226374a51a0609._comment
 create mode 100644 doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_5_8e931e54738640cecf0bbaf80a3e8660._comment
 create mode 100644 doc/todo/make_status_show_staged_files/comment_1_3874f5da5a300b7d443e1ad6373b4099._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__.mdwn
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_10_20db4ecf9debcc2662ec69a6ad9b37c6._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_11_b3c5851c3603976d59927b591ba1d126._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_12_2363dac7701b9c36eb1896a09e68c17d._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_13_5d65192366f7690c22d1a209fb1e8f78._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_14_16aae09d0e1d80240fc3ae81e5b06972._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_15_013afa9d45970397bfcd60e57a519d67._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_16_c43788c8730619c3590d1a0a2bb87148._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_17_77a2f7d18cbcf780d8e2bb4a3e40b4fa._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_18_7650d349ba50972b64cd6d81673bf1c9._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_19_13b21a0523b8837f4e27bb78e35ad5e0._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_1_c67d403cb5bb67c3486ff9ade9607b2f._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_2_c67fe4be932b8e7e365ed336e612b526._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_3_6ae9e999b6af6b6bfe078dd187f7ff22._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_4_bfb9b94048fc239f29351a9d38c8d4e3._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_5_7a57b6713788778f6a6e8144cf3931b2._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_6_3a849428b335964f80a8503d44d51c5a._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_7_5f5d9af7ed807b8ef203426f717822b2._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_8_b45863d81e3790ea44714a18c1721abd._comment
 create mode 100644 doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_9_ce5fb75f944816b134fd2dc7a389b913._comment
 create mode 100644 doc/todo/metadata_--batch.mdwn
 create mode 100644 doc/todo/migration_to_VURL_by_default.mdwn
 create mode 100644 doc/todo/more___34__filesystem_efficient__34___journalling__63___.mdwn
 create mode 100644 doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_1_5bbc2d651e4ce0ea5b20f199be5cb717._comment
 create mode 100644 doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_2_5a29f3bc596b463b6710a6654b2e271e._comment
 create mode 100644 doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_3_6486a0cf500f6ba3a9306cdc137f7b4d._comment
 create mode 100644 doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_4_3d1a1ede9d1b5048723a542996121dd4._comment
 create mode 100644 doc/todo/more_efficient_resolution_of_trivial_export_conflicts.mdwn
 create mode 100644 doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_1_5a2d7ea060f5e1be11c39521c0a5631d._comment
 create mode 100644 doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_2_70c3cfa9b95f3aa6c2e2e2f6dbbc50d0._comment
 create mode 100644 doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_3_d0549f8a07032ce61e88b4ccb2c6ef3b._comment
 create mode 100644 doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism.mdwn
 create mode 100644 doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism/comment_1_7078d380be9e78fea9fd5bec4ef9594b._comment
 create mode 100644 doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism/comment_2_9e2c1d58f0d91dc55524d2e164b89b97._comment
 create mode 100644 doc/todo/moreinfo.mdwn
 create mode 100644 doc/todo/move_readonly_values_to_AnnexRead.mdwn
 create mode 100644 doc/todo/multiple_-m.mdwn
 create mode 100644 doc/todo/need_a_clear_criteria_for_adding_git-annex-config_settings.mdwn
 create mode 100644 doc/todo/need_a_clear_criteria_for_adding_git-annex-config_settings/comment_1_bcc5d69426fc6af6affdaf251dd9dd5d._comment
 create mode 100644 doc/todo/needsthought.mdwn
 create mode 100644 doc/todo/network_test_suite.mdwn
 create mode 100644 doc/todo/new_command_for_syncing_content_only.mdwn
 create mode 100644 doc/todo/new_command_for_syncing_content_only/comment_1_7f983de645430d970c75f25fee27b2ed._comment
 create mode 100644 doc/todo/new_command_for_syncing_content_only/comment_2_311cd71d61bea5782c71ee33282d152e._comment
 create mode 100644 doc/todo/new_command_for_syncing_content_only/comment_3_19398beb81c56b3b7cc3aff7081a2886._comment
 create mode 100644 doc/todo/new_command_for_syncing_content_only/comment_4_c72cbc566af9585b4701f833883f878e._comment
 create mode 100644 doc/todo/new_command_for_syncing_content_only/comment_5_857157a775711330df39b57828cf9bd4._comment
 create mode 100644 doc/todo/new_command_for_syncing_content_only/comment_6_3ca0ef151b73781d2fe168c56d54faad._comment
 create mode 100644 doc/todo/new_command_for_syncing_content_only/comment_7_084e139c8325bb8607f6c0a9f3873afe._comment
 create mode 100644 doc/todo/new_command_for_syncing_content_only/comment_8_c666e3ef20e823230392a70d6b588e7d._comment
 create mode 100644 doc/todo/nitpick__58___show_one_column_per_UUID_in_git_annex_lis.mdwn
 create mode 100644 doc/todo/nitpick__58___show_one_column_per_UUID_in_git_annex_lis/comment_1_e6d9efa01ddeb129469b3b8a4205cb3f._comment
 create mode 100644 doc/todo/nitpick__58___show_one_column_per_UUID_in_git_annex_lis/comment_2_049625685f6147f38392e2df1dadac33._comment
 create mode 100644 doc/todo/not_ask_git_credentials_for_password_per_each_file.mdwn
 create mode 100644 doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_1_ae15355f54b5137e696aaf5d2111806b._comment
 create mode 100644 doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_2_0c60c791513acff3910a29513f7f2f78._comment
 create mode 100644 doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_2_2d8902e343e65a39b5a23278793ec921._comment
 create mode 100644 doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_3_39ccd0fe773200166d0727dc903c34e3._comment
 create mode 100644 doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_4_4dca41df7506fa7aedf88d7618bbcf39._comment
 create mode 100644 doc/todo/onlyingroup_preferred_content_expression.mdwn
 create mode 100644 doc/todo/onlyingroup_preferred_content_expression/comment_1_eddf28997789400398fbdd58ec64861d._comment
 create mode 100644 doc/todo/onlyingroup_preferred_content_expression/comment_2_b1a22e4fbc594c3085e7fbc6fbaab69a._comment
 create mode 100644 doc/todo/onlyingroup_preferred_content_expression/comment_3_8f205160e62aa1312b8e2ef4cafe8c50._comment
 create mode 100644 doc/todo/openwrt_package.mdwn
 create mode 100644 doc/todo/openwrt_package/comment_1_100d76109e04bc43979775d71b4152ac._comment
 create mode 100644 doc/todo/openwrt_package/comment_2_2cb7dd4c0cc4413a4588b13cf7700de2._comment
 create mode 100644 doc/todo/openwrt_package/comment_3_5ba8a325a683ff543d81a366c873070d._comment
 create mode 100644 doc/todo/openwrt_package/comment_4_132e67b34f9c616217e037e4ecac70a4._comment
 create mode 100644 doc/todo/optimise_by_converting_Map_to_HashMap.mdwn
 create mode 100644 doc/todo/optimise_use_of_keys_db_on_local_remote.mdwn
 create mode 100644 doc/todo/optimization_needed__58___slow_uninit.mdwn
 create mode 100644 doc/todo/optimization_needed__58___slow_uninit/comment_1_3d01d125ffea8dd247e68f716a9c636a._comment
 create mode 100644 doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__.mdwn
 create mode 100644 doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_1_8620167702725aa8fb0e42dfe3820520._comment
 create mode 100644 doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_2_f964bb1a14f099e69f1e780ee7c7ef68._comment
 create mode 100644 doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_3_d4672f72a00509186cfc5dd85e1da140._comment
 create mode 100644 doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_4_4560eff896578ac2779b03ec3484d0b2._comment
 create mode 100644 doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_5_a154a025d441db4e0140fee821d1791c._comment
 create mode 100644 doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__.mdwn
 create mode 100644 doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_1_8f40b2663c9f48ddb07969af1b6632a8._comment
 create mode 100644 doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_2_32383ff5db43f0f4dc9e7470613f04fd._comment
 create mode 100644 doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_3_2665f3fc268dff1de24d6ee9648c5d8c._comment
 create mode 100644 doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_4_5fb82eb18c6d935ac07ec9220d9037c0._comment
 create mode 100644 doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_5_c7b9cbdbc4be36ea4d56a1eec13c6f34._comment
 create mode 100644 doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_6_aa58624e8d0de174a06c6c2c0e33dc14._comment
 create mode 100644 doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_7_150a87dea1bd24e3d4e18cf3bcfb937f._comment
 create mode 100644 doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_8_1e87a33fe71ec2d5f4df887b94dae7c6._comment
 create mode 100644 doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents.mdwn
 create mode 100644 doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents/comment_1_4e813660a7743ecc3378b87adb0cd0f8._comment
 create mode 100644 doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents/comment_2_8aec191966e5633ae6b1b008f8990d3e._comment
 create mode 100644 doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents/comment_3_7337c487d7118e0bfdf931a741f3d5a4._comment
 create mode 100644 doc/todo/option_to_explain.mdwn
 create mode 100644 doc/todo/option_to_explain/comment_1_81644886e14851a276dc3c89965df62e._comment
 create mode 100644 doc/todo/option_to_explain/comment_2_71616074104ab70eb76ad5edb9207b5c._comment
 create mode 100644 doc/todo/option_to_explain/comment_3_2179a7fec079045d82a58993d3f09995._comment
 create mode 100644 doc/todo/option_to_explain/comment_4_28919c6f816f11811b1e8c73b07403f7._comment
 create mode 100644 doc/todo/option_to_individually_hash_chunks.mdwn
 create mode 100644 doc/todo/option_to_individually_hash_chunks/comment_1_c6d5133efb3ddc9ac632530600257bdf._comment
 create mode 100644 doc/todo/option_to_individually_hash_chunks/comment_2_29821c673e5e8ce88c62086a67346357._comment
 create mode 100644 doc/todo/option_to_individually_hash_chunks/comment_3_3cd814797e837fae3dba8d6d99f41ec1._comment
 create mode 100644 doc/todo/option_to_individually_hash_chunks/comment_4_b2a78d90e7e2ee8a98f12663c9e1041a._comment
 create mode 100644 doc/todo/option_to_limit_to_files_that_are_expected_to_be_present.mdwn
 create mode 100644 doc/todo/option_to_put_temp_files_on_a_RAM_disk.mdwn
 create mode 100644 doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_1_28a5627604d2d4b25c51779a7216931d._comment
 create mode 100644 doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_2_1df752ac3b9cb2cc0e4a7dd4af71897f._comment
 create mode 100644 doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_3_12a1b6f9fd616f5c498d5aff1cf1bcb6._comment
 create mode 100644 doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment
 create mode 100644 doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages.mdwn
 create mode 100644 doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages/comment_1_bfbf428da46eaea52cc54878f119512a._comment
 create mode 100644 doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages/comment_2_c43e838b750448fe4d1519e72c43242f._comment
 create mode 100644 doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages/comment_3_e006b8efab713d4965316c9846ec437c._comment
 create mode 100644 doc/todo/parallel_get.mdwn
 create mode 100644 doc/todo/patch_generation_with_annexed_files.mdwn
 create mode 100644 doc/todo/preserve_file_extensions_in_WORM_and_URL_keys.mdwn
 create mode 100644 doc/todo/preserve_file_extensions_in_WORM_and_URL_keys/comment_1_3cf91bca8e01f98644b0d25a45ecf092._comment
 create mode 100644 doc/todo/prevent_directly_printing_to_stderr_error_from_an_attempt_to_download_remote___47__config_file.mdwn
 create mode 100644 doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn
 create mode 100644 doc/todo/provide___39__file__39___in_--json-progress_record_for_addurl.mdwn
 create mode 100644 doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse.mdwn
 create mode 100644 doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse/comment_1_5ed9864ef616d9e9b77a3d62561363fd._comment
 create mode 100644 doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse/comment_2_e9647b34aa79c414faf0f57ba17e6af4._comment
 create mode 100644 doc/todo/provide_windows_build_with_MagicMime.mdwn
 create mode 100644 doc/todo/provide_windows_build_with_MagicMime/comment_1_11adb1623314e8a43c50704c5e6e62d4._comment
 create mode 100644 doc/todo/provide_windows_build_with_MagicMime/comment_2_8f2d350c853f8827e1d5f95897dc2bd8._comment
 create mode 100644 doc/todo/provide_windows_build_with_MagicMime/comment_3_15509110c5900aee2cc977372da16f0b._comment
 create mode 100644 doc/todo/provide_windows_build_with_MagicMime/comment_4_4727291eefa07a40da13dace75a2e255._comment
 create mode 100644 doc/todo/provide_windows_build_with_MagicMime/comment_5_4633d2a40bca1ba8fa93f7038569715f._comment
 create mode 100644 doc/todo/provide_windows_build_with_MagicMime/comment_6_5542a421c6c7c878394d7dd7a3bce9c1._comment
 create mode 100644 doc/todo/provide_windows_build_with_MagicMime/comment_7_d16e4fb3d0be2acd23d158272171b842._comment
 create mode 100644 doc/todo/proving_preferred_content_behavior.mdwn
 create mode 100644 doc/todo/publicurl_config_for_all_special_remotes.mdwn
 create mode 100644 doc/todo/publicurl_config_for_all_special_remotes/comment_1_58b2ec259bd3d9e368240e459330a738._comment
 create mode 100644 doc/todo/publicurl_config_for_all_special_remotes/comment_2_d9933855e8521ebed00406a6350837b7._comment
 create mode 100644 doc/todo/publicurl_config_for_all_special_remotes/comment_3_42ac954b120205650a2a5f03872085c2._comment
 create mode 100644 doc/todo/publicurl_config_for_all_special_remotes/comment_4_3c144c0323d49f7ca2d6b9971ad3160a._comment
 create mode 100644 doc/todo/publicurl_config_for_all_special_remotes/comment_5_1d9186506f8f44415706f3b4394c9008._comment
 create mode 100644 doc/todo/publicurl_config_for_all_special_remotes/comment_6_7f027aa4b5b495a93aee3cd3417862a8._comment
 create mode 100644 doc/todo/publicurl_config_for_all_special_remotes/comment_7_c35df3621c7b6a1b518787fdc8967ee7._comment
 create mode 100644 doc/todo/read-only_removable_drives.mdwn
 create mode 100644 doc/todo/read-only_removable_drives/comment_1_979455e3694ae2403134ed6fa2add2fa._comment
 create mode 100644 doc/todo/read-only_removable_drives/comment_2_08fced29b86b21f63bb0868747227e08._comment
 create mode 100644 doc/todo/read-only_removable_drives/comment_3_2675e211c7bd248b7f7c1bbc6fd46679._comment
 create mode 100644 doc/todo/read-only_removable_drives/comment_4_9e9bc6dd5fa8c4cf7f2511b771bd1bc7._comment
 create mode 100644 doc/todo/read-only_removable_drives/comment_5_a693c5744bfc6c33f5605aa9d9c0bfe0._comment
 create mode 100644 doc/todo/read-only_removable_drives/comment_6_737e3d315f29a4fc61597ce4f9ec6206._comment
 create mode 100644 doc/todo/read-only_removable_drives/comment_7_16c8652d38ae57db4ed1860a4733a18b._comment
 create mode 100644 doc/todo/read-only_removable_drives/comment_8_a802e0617c9ef72eb8d3842de99e44ae._comment
 create mode 100644 doc/todo/record_ETag_when_using_addurl_--fast.mdwn
 create mode 100644 doc/todo/record_ETag_when_using_addurl_--fast/comment_1_cf15e943ba9405240aecc3dc83b4ef08._comment
 create mode 100644 doc/todo/registerurl_--remote_REMOTE.mdwn
 create mode 100644 doc/todo/registerurl_--remote_REMOTE/comment_1_9d99569edd7ee8331626ec9fffeaa1b7._comment
 create mode 100644 doc/todo/registerurl_--remote_REMOTE/comment_2_59f6ff108c40b4597a7a870fafdaabc2._comment
 create mode 100644 doc/todo/registerurl_--remote_REMOTE/comment_3_70244d4f7f81b6799cd541ad14b38ee0._comment
 create mode 100644 doc/todo/registerurl_--remote_REMOTE/comment_4_334ce2eb815d6d8489f9cb00c09b0bd7._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__.mdwn
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_10_0de07ff7054e7d71a6cf1d08051664f9._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_11_b41f6266e341ec05586e6ec32b6cf68a._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_12_3994a27f274ef2025300291ff1bce8bb._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_13_0154b05e0b0edccd8e69657501938d92._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_14_aafc89e24d5640dad3b8f6134c1ac26b._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_15_41ba5600367f6893e8ed0bf01be3d539._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_15_b120af2367cc3667934c088b496331f6._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_17_fe41f306edfb0ae608dfb3a8f153bcbf._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_18_6b4df9d81c523e090b83c56bfdce373a._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_19_b23a39f88879b3c770e112f9e82c4607._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_1_98cd9e5dd449cbd834f53d97fd5dfc13._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_20_532690bc7b9707aa053814c3e84b1dca._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_20_fc54794546e8e14b31aa063d93c328de._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_21_953eaa6ca651597897a6c6ad7a259d1d._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_23_4b576c9c33ff2a322cd832027484606b._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_24_fb760c2566b6f37ed7378bbcca5875c5._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_25_148392f465864f19593de0b1aa56f7f8._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_2_a4fce84f5777ed582fa599778835455f._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_3_56c313fdcb88e95abaa10647678bc108._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_4_13c0eecd57ea56bb1e21e130d7343778._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_4_52a1fe104856968488b386b701c4a4bd._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_6_29a487203bf620e44c3e9db2d22f5ee3._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_7_6bf718a1c6185b6aed0b6d0d5c4c9cf8._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_8_e041fcd11c50d47eada124368a5bb7b5._comment
 create mode 100644 doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_9_dd5a1bdc1cc3ecd6ac68cc83fb2195ed._comment
 create mode 100644 doc/todo/reinit_current_repo_to_new_uuid.mdwn
 create mode 100644 doc/todo/reinit_current_repo_to_new_uuid/comment_1_2274082a0d130127eb2fcc12e3404d08._comment
 create mode 100644 doc/todo/reinit_current_repo_to_new_uuid/comment_2_d7f2a6de08a3559a1d76ae8aba5a6702._comment
 create mode 100644 doc/todo/reinit_current_repo_to_new_uuid/comment_3_94434f7e76df4a25d922eed28ca6b559._comment
 create mode 100644 doc/todo/reinit_current_repo_to_new_uuid/comment_4_9d2b98c15d78781f943f0f2ddf775706._comment
 create mode 100644 doc/todo/remote-ready-command.mdwn
 create mode 100644 doc/todo/remote-ready-command/comment_1_55cbea73adb94e85fc2e2252d6f2f03c._comment
 create mode 100644 doc/todo/remote-ready-command/comment_2_0e79b93a9c614a259b9a7d7c1f6cb6dc._comment
 create mode 100644 doc/todo/remove_legacy_import_directory_interface.mdwn
 create mode 100644 doc/todo/remove_legacy_import_directory_interface/comment_1_335ab41b3539f605ace1830577794913._comment
 create mode 100644 doc/todo/report_PID___40__and_may_be_failure_details__63____41___in___34__process_done__34___debug_messages.mdwn
 create mode 100644 doc/todo/report_PID___40__and_may_be_failure_details__63____41___in___34__process_done__34___debug_messages/comment_1_3b069234f20378fc231802c594eb213d._comment
 create mode 100644 doc/todo/repositories_that_count_as_more_than_one_copy.mdwn
 create mode 100644 doc/todo/repositories_that_count_as_more_than_one_copy/comment_1_cc1ea7d1c6aac3749b4ecd789594e3f9._comment
 create mode 100644 doc/todo/required_content.mdwn
 create mode 100644 doc/todo/required_content/comment_1_42620a3c958666be2a0d5f5b8eadf7b4._comment
 create mode 100644 doc/todo/required_content/comment_2_132ec6378db63af6281569cf5748b9d3._comment
 create mode 100644 doc/todo/required_content/comment_3_b16a8e8b45ceee887c8c0167b7859654._comment
 create mode 100644 doc/todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__.mdwn
 create mode 100644 doc/todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__/comment_1_8a59da3012b9d177b4baa72610b72fc9._comment
 create mode 100644 doc/todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__/comment_2_96f1138462fecac628751d872e2ceb9e._comment
 create mode 100644 doc/todo/return___34__key__34___entry_in_--json_output_for_addurl___40__and_future_add__41___--batch.mdwn
 create mode 100644 doc/todo/reuse_desktop_notifications.mdwn
 create mode 100644 doc/todo/reuse_desktop_notifications/comment_1_6193ed5a4ad0a908af82da33d14bd654._comment
 create mode 100644 doc/todo/reuse_desktop_notifications/comment_2_3fb10a432a57ce14cb7bc2946467ab22._comment
 create mode 100644 doc/todo/reuse_desktop_notifications/comment_3_ac0e5f437b5d2677e916224d6dfaf666._comment
 create mode 100644 doc/todo/setpresentkey_option_to_record_chunked_state.mdwn
 create mode 100644 doc/todo/setpresentkey_option_to_record_chunked_state/comment_1_99bf00b8f78d75888dc7bc69d36cd112._comment
 create mode 100644 doc/todo/setpresentkey_option_to_record_chunked_state/comment_2_42e9309fff6a71c1a0a625dd2bc6aae2._comment
 create mode 100644 doc/todo/setpresentkey_option_to_record_chunked_state/comment_3_97ed902a268ebad53f534dd48a6f5fc9._comment
 create mode 100644 doc/todo/sharedRepository_mode_not_supported_by_git-annex.mdwn
 create mode 100644 doc/todo/sharedRepository_mode_not_supported_by_git-annex/comment_1_b219d62cd7d21002ae73d0dbd4b792be._comment
 create mode 100644 doc/todo/sharedRepository_mode_not_supported_by_git-annex/comment_2_7140ad0abbb54f5a4e20b165a08793e2._comment
 create mode 100644 doc/todo/sharedRepository_mode_not_supported_by_git-annex/comment_3_c3dff87829e3f055881829eb4598f903._comment
 create mode 100644 doc/todo/shorten_git-annex_manpage.mdwn
 create mode 100644 doc/todo/shorten_git-annex_manpage/comment_1_4b82eb4af9b923b23c6ecd8d355c0651._comment
 create mode 100644 doc/todo/shorten_git-annex_manpage/comment_2_859444d7e2826ac4448b0ba0f716328f._comment
 create mode 100644 doc/todo/shorten_git-annex_manpage/comment_3_3543a2edda668c3f0a90c46aeee94812._comment
 create mode 100644 doc/todo/shorten_git-annex_manpage/comment_4_fa6c2870f4a83d0f5680b76b05009e4b._comment
 create mode 100644 doc/todo/shorter_keys_through_better_encoding.mdwn
 create mode 100644 doc/todo/shorter_keys_through_better_encoding/comment_1_4bd588a3cdca5cb94132549b7d78e6af._comment
 create mode 100644 doc/todo/shorter_keys_through_better_encoding/comment_2_454cb3b2b1102ce4da18f245bc583e7c._comment
 create mode 100644 doc/todo/shorter_keys_through_better_encoding/comment_3_9f5f16a7ab5d3e28cdddc333d97b87ea._comment
 create mode 100644 doc/todo/shorter_keys_through_better_encoding/comment_4_720012572e1d748bc628fdb17a55a3bd._comment
 create mode 100644 doc/todo/shorter_keys_through_better_encoding/comment_5_41857b7f25f8a922640378a41574b84d._comment
 create mode 100644 doc/todo/shorter_keys_through_better_encoding/comment_6_de3f0be0f6b560ca7bb66f7b5c8f0592._comment
 create mode 100644 doc/todo/shorter_keys_through_better_encoding/comment_7_d499c66c9a1981bb14d0ce63f4983ea5._comment
 create mode 100644 doc/todo/shorter_keys_through_better_encoding/comment_8_5592ac9d1887183daf3173a0c27b672f._comment
 create mode 100644 doc/todo/shorter_keys_through_better_encoding/comment_9_75f611c63bf1e9c8b4885fea8e9d467f._comment
 create mode 100644 doc/todo/show_dead_in_info___40__behind_option__63____41__.mdwn
 create mode 100644 doc/todo/show_dead_in_info___40__behind_option__63____41__/comment_1_74c3bbb7819368a894ff1189988e4cd3._comment
 create mode 100644 doc/todo/show_dead_in_info___40__behind_option__63____41__/comment_2_0cc7a3c53ffbabcb13807956541d83ec._comment
 create mode 100644 doc/todo/show_me_where_unused_file_was__44___i_can_wait.mdwn
 create mode 100644 doc/todo/show_me_where_unused_file_was__44___i_can_wait/comment_1_732f726f72f2540372d434974fda60f2._comment
 create mode 100644 doc/todo/show_readonly_removable_drives_in_the_webapp.mdwn
 create mode 100644 doc/todo/show_readonly_removable_drives_in_the_webapp/comment_1_c41140289f9b062e96cfd5d9d5382155._comment
 create mode 100644 doc/todo/show_readonly_removable_drives_in_the_webapp/comment_2_b9236ea884a2934dd0c8e511a80f4fda._comment
 create mode 100644 doc/todo/show_time_of_last_interaction_with_a_repo.mdwn
 create mode 100644 doc/todo/show_time_of_last_interaction_with_a_repo/comment_1_4ec9597df62dc4a2f7320f13f6a0ee8e._comment
 create mode 100644 doc/todo/show_time_of_last_interaction_with_a_repo/comment_1_997d9968782f7fd96d9edd9c380a3ee9._comment
 create mode 100644 doc/todo/simpler__44___trusted_export_remotes.mdwn
 create mode 100644 doc/todo/simpler__44___trusted_export_remotes/comment_1_cc6a862519677ea18f78d24f40a48be1._comment
 create mode 100644 doc/todo/simpler__44___trusted_export_remotes/comment_2_5528a5dd5f8d7746b175552a077ba313._comment
 create mode 100644 doc/todo/simpler__44___trusted_export_remotes/comment_3_3e7be2ba92559a767ea09b764daef2db._comment
 create mode 100644 doc/todo/simpler__44___trusted_export_remotes/comment_4_be525962211e8c4da681279aba132c71._comment
 create mode 100644 doc/todo/simpler__44___trusted_export_remotes/comment_5_aeefb4803340ff993a1d6673c8e5e97b._comment
 create mode 100644 doc/todo/simpler__44___trusted_export_remotes/comment_6_0d27b08792112cbee7a368bc94044bb4._comment
 create mode 100644 doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type.mdwn
 create mode 100644 doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_1_8ea993d1acc92f3aa9594ed8e2d3ec7d._comment
 create mode 100644 doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_2_96fae68472f7f9ef720c27149556f7a0._comment
 create mode 100644 doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_3_b75ffc63f0e9a85c3d1f01bdce21c97c._comment
 create mode 100644 doc/todo/specify_gitconfig_for_test_suite.mdwn
 create mode 100644 doc/todo/speculate-can-get___58___extension_of_speculate-present.mdwn
 create mode 100644 doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_1_264538d1cbf07254a2857ca4cf40e9ac._comment
 create mode 100644 doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_2_93450de83c4843f6828e971a948d12e3._comment
 create mode 100644 doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_3_272d66c3549892687879ef20e0cd9cf1._comment
 create mode 100644 doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_4_8627a8073fe0b4c144f26d32626e0c1b._comment
 create mode 100644 doc/todo/speed_up_VURL_by_avoiding_redundant_hashing.mdwn
 create mode 100644 doc/todo/speed_up___34__standalone_build__34___and__47__or_tests.mdwn
 create mode 100644 doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_10_0e070bc39eb0b8d9cf307af8a06504dc._comment
 create mode 100644 doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_1_41749c4c9b317a58e02df99f748844a1._comment
 create mode 100644 doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_2_f462ee4719b4c459c12e36ce29ab82b5._comment
 create mode 100644 doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_3_dfd20b6c6a49c99243945a267e041d58._comment
 create mode 100644 doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_4_650e5dd2471cdfd0223d712771067d55._comment
 create mode 100644 doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_5_0ee51fffee1f591173418212919bcd30._comment
 create mode 100644 doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_6_b4aecfd9f1b7f0e16d5f1dcb3c16af3e._comment
 create mode 100644 doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_7_e11ae8ba6dd6e6c53891db954d28bfff._comment
 create mode 100644 doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_8_b06360071e05df18b895322382357b61._comment
 create mode 100644 doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_9_2253c6916a1c6e4f1393b8656617aa10._comment
 create mode 100644 doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn
 create mode 100644 doc/todo/speed_up_drop_on___34__heavy__34___repo.mdwn
 create mode 100644 doc/todo/speed_up_drop_on___34__heavy__34___repo/comment_1_5c92b3e7c2fc0e8a8e943690c1806322._comment
 create mode 100644 doc/todo/speed_up_drop_on___34__heavy__34___repo/comment_2_a5587ebc2a406d52855868cdeb39b83e._comment
 create mode 100644 doc/todo/speed_up_import_tree.mdwn
 create mode 100644 doc/todo/speed_up_import_tree_with_many_excluded_files.mdwn
 create mode 100644 doc/todo/ssh_special_remote.mdwn
 create mode 100644 doc/todo/stalldetection_for_import_and_export.mdwn
 create mode 100644 doc/todo/standlone__58___growing_number_of_libpcre.so_lookups.mdwn
 create mode 100644 doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_1_ef6645a9b6d69a652cd042185c864677._comment
 create mode 100644 doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_2_181175a281f3a4298341d109064eeff8._comment
 create mode 100644 doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_3_0358f9e216271ba0be8684eea4a3e1d1._comment
 create mode 100644 doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_3_5e3c73faeaefee8f0ec1227c672f2be5._comment
 create mode 100644 doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_4_91ab4b860a074c90e5cbeb03e3515ad4._comment
 create mode 100644 doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_6_2e435cc8fe61c7ca7c59f2a63fbbee20._comment
 create mode 100644 doc/todo/stop_after_these_files.mdwn
 create mode 100644 doc/todo/support___126____47__.netrc_for_http_access_authentication_specs_as_was_done_when_wget_was_used.mdwn
 create mode 100644 doc/todo/support___126____47__.netrc_for_http_access_authentication_specs_as_was_done_when_wget_was_used/comment_1_0f2f5b58020879252d716930f2396b81._comment
 create mode 100644 doc/todo/support_for_storing_xattrs.mdwn
 create mode 100644 doc/todo/support_for_storing_xattrs/comment_1_55c839d1b8af5150a5df29f0314e4b79._comment
 create mode 100644 doc/todo/support_for_storing_xattrs/comment_2_c10f87259aef110510014ba16d0792ad._comment
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__.mdwn
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_10_d94d813bdd6bea17347c87597788aec7._comment
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_11_e5b9898f69fa9143519e58378ac668f8._comment
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_12_9fd59c3ec54d54790050eb8860964783._comment
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_1_1b23963d04c5bd53d3de09970816fad8._comment
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_2_e506d7b173bd04ad7f32db52dcc1ea03._comment
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_3_d812c6dbd672e3dcdeb5c87806dcef91._comment
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_4_8fbd3cdc5a077cbd51d41db30c19a005._comment
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_5_4580926755ee2802c80baa9f9bcc0661._comment
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_6_bd610770eff9ef1eb68085e28c1175fa._comment
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_7_f09b99a17d52a55e609bb3ca02db781a._comment
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_8_f1c3cf11cddb9e5c7747e5824cd4b608._comment
 create mode 100644 doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_9_5097e4ac096d1b0b9c06c544b9217e22._comment
 create mode 100644 doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support.mdwn
 create mode 100644 doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support/comment_1_7932fd28b14898a0b4846856a27405b8._comment
 create mode 100644 doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support/comment_2_048a8f7b52a0baf4c0abbae37de00257._comment
 create mode 100644 doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support/comment_3_04be2f010aeb792e070f1ff93435fabc._comment
 create mode 100644 doc/todo/support_using_Stateless_OpenPGP_instead_of_gpg.mdwn
 create mode 100644 doc/todo/symlinks_to_symlinks_to_the_annex.mdwn
 create mode 100644 doc/todo/symlinks_to_symlinks_to_the_annex/comment_1_54bae401b8de13c9973ef5e6d2cf7e88._comment
 create mode 100644 doc/todo/symlinks_to_symlinks_to_the_annex/comment_2_f5c08ecd3b0b4099186d78c85b7f1e6f._comment
 create mode 100644 doc/todo/symlinks_to_symlinks_to_the_annex/comment_3_409de39da33b7ecfe5b8c7b2e866225e._comment
 create mode 100644 doc/todo/symlinks_to_symlinks_to_the_annex/comment_4_818c85d1a199d40daca7371fefb18bc3._comment
 create mode 100644 doc/todo/symlinks_to_symlinks_to_the_annex/comment_5_94b84cd27c36d14dc16837484d232d72._comment
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__.mdwn
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_10_06fd59c8bdd451b5608e1e0191f4d5cb._comment
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_11_436fd00970867a8bb0806a753ac24963._comment
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_12_2e768899c332cacffcb1fa6edb195325._comment
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_1_741720c1b65fff2f8ecb87abbcf16223._comment
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_2_73bd5d343286f61c9ac753ed3b00c149._comment
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_3_bab52f2fd4f66cac6a178cdd9ef71c6d._comment
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_4_a765e998ffaecc2af681947263cd80d7._comment
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_5_8f19d38c815dd3051004301a15657cf6._comment
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_6_15e336ea35f0233e22f7c5b656b616d2._comment
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_7_757f97ac10035ec6b28720c0570b19f0._comment
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_8_6c683fcba5d69a4c0051eb42b8c558a0._comment
 create mode 100644 doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_9_5bef9faa4df40b84c991b9ea5e1ab7a3._comment
 create mode 100644 doc/todo/syncthing_special_remote.mdwn
 create mode 100644 doc/todo/tahoe_lfs_for_reals.mdwn
 create mode 100644 doc/todo/tahoe_lfs_for_reals/comment_1_0a4793ce6a867638f6e510e71dd4bb44._comment
 create mode 100644 doc/todo/tahoe_lfs_for_reals/comment_2_80b9e848edfdc7be21baab7d0cef0e3a._comment
 create mode 100644 doc/todo/terminal_escapes_in_filenames.mdwn
 create mode 100644 doc/todo/test_suite_unsafe_use_of_setEnv.mdwn
 create mode 100644 doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so.mdwn
 create mode 100644 doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so/comment_1_35e85e3088c4453751ebffb7357a9f9b._comment
 create mode 100644 doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so/comment_2_61d70f4a06edaa593a17d47019be53de._comment
 create mode 100644 doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so/comment_3_89701d7011c3c9085afaab33aa16c39f._comment
 create mode 100644 doc/todo/timeout_support_for_importfeed.mdwn
 create mode 100644 doc/todo/to_and_from_multiple_remotes.mdwn
 create mode 100644 doc/todo/to_and_from_multiple_remotes/comment_1_2c055c3f55e0796b6842df8c2733726b._comment
 create mode 100644 doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3.mdwn
 create mode 100644 doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3/comment_1_42256576a4b5e8312b12e785fbc8fb1f._comment
 create mode 100644 doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3/comment_2_6b655d30bf07518f33ec42cdeabef4ef._comment
 create mode 100644 doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3/comment_3_fb3e0585f6700050db7a06e27d8e1099._comment
 create mode 100644 doc/todo/tor.mdwn
 create mode 100644 doc/todo/track_free_space_in_repos_via_git-annex_branch.mdwn
 create mode 100644 doc/todo/tracking_changes_to_metadata.mdwn
 create mode 100644 doc/todo/tracking_changes_to_metadata/comment_1_825c15ba36324aad58faf643057b256a._comment
 create mode 100644 doc/todo/tracking_changes_to_metadata/comment_2_03a631beaa20a479f5016def7585d363._comment
 create mode 100644 doc/todo/tracking_changes_to_metadata/comment_3_a05652472c37c463eca22f11cf6596a4._comment
 create mode 100644 doc/todo/transitive_transfers.mdwn
 create mode 100644 doc/todo/transitive_transfers/comment_1_d244295696be5a8164db45f7fad1701a._comment
 create mode 100644 doc/todo/transitive_transfers/comment_2_7255f5083283b0ae7e7fc41e127bd829._comment
 create mode 100644 doc/todo/transitive_transfers/comment_3_e5c2ede203e7bdb5af8432df6c09268f._comment
 create mode 100644 doc/todo/transitive_transfers/comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment
 create mode 100644 doc/todo/transitive_transfers/comment_5_50670cb52b29dc9c0c6c981e6f6d198b._comment
 create mode 100644 doc/todo/transitive_transfers/comment_6_ddef2f127a49c2eb8a15b5848756d888._comment
 create mode 100644 doc/todo/transitive_transfers/comment_7_6417ec94a5723776b6688ccbb0453ffc._comment
 create mode 100644 doc/todo/transitive_transfers/comment_8_7ffe073c582fc9392213ce52ba6ba398._comment
 create mode 100644 doc/todo/transitive_transfers/comment_9_6d5c2697bc985627199e425962f23189._comment
 create mode 100644 doc/todo/trust_based_on_time_since_last_fsck.mdwn
 create mode 100644 doc/todo/trust_based_on_time_since_last_fsck/comment_1_3805e8dd9e6dd986c097c6f1b78ab244._comment
 create mode 100644 doc/todo/trust_based_on_time_since_last_fsck/comment_2_ec1b87b389dc06440df04c9a719e0cbc._comment
 create mode 100644 doc/todo/trust_based_on_time_since_last_fsck/comment_3_23f37b9d8b877b829e34e6c8ea6b40c4._comment
 create mode 100644 doc/todo/trust_based_on_time_since_last_fsck/comment_4_29729772f7600dfb459e3be9cf2c43ea._comment
 create mode 100644 doc/todo/trust_presence_info_for_specific_remotes_for_specified_time.mdwn
 create mode 100644 doc/todo/trust_presence_info_for_specific_remotes_for_specified_time/comment_1_96e12b8ecba4bacfbfa5c58025bedaab._comment
 create mode 100644 doc/todo/unify_adjust_with_view.mdwn
 create mode 100644 doc/todo/union_mounting.mdwn
 create mode 100644 doc/todo/union_mounting/comment_1_cb08435812dd7766de26199c73f38e8b._comment
 create mode 100644 doc/todo/union_mounting/comment_2_240b1736f6bd4fbf87c372d3a46e661b._comment
 create mode 100644 doc/todo/union_mounting/comment_3_cf0a0d4fbd929f24f7056115b2acb7de._comment
 create mode 100644 doc/todo/union_mounting/comment_4_2f02fe00a84bf94b7c8e437d8b80293f._comment
 create mode 100644 doc/todo/union_mounting/comment_5_58c38383a7ac2df843772960fa10204f._comment
 create mode 100644 doc/todo/union_mounting/comment_6_65055977d7c8db3c9c29d90e033e5bb4._comment
 create mode 100644 doc/todo/universal_batch_mode.mdwn
 create mode 100644 doc/todo/universal_batch_mode/comment_1_83264867c7f58d92148d1585e4361ee5._comment
 create mode 100644 doc/todo/universal_batch_mode/comment_2_c662c1e2410285e9bf6d01135851fdc8._comment
 create mode 100644 doc/todo/universal_batch_mode/comment_3_c8232195fa3db718dc2b246d528e6c00._comment
 create mode 100644 doc/todo/unlikely.mdwn
 create mode 100644 doc/todo/unlock_--json.mdwn
 create mode 100644 doc/todo/unlock_--json/comment_1_4cd41dca533de8147027eeb9a8ad89db._comment
 create mode 100644 doc/todo/unlock_--json/comment_2_f00fda45d300ce14a5ea6fd32a20defe._comment
 create mode 100644 doc/todo/unlock_--read-only.mdwn
 create mode 100644 doc/todo/unlock_--read-only/comment_10_c2a1f402a28c44f842d88747fa3741cc._comment
 create mode 100644 doc/todo/unlock_--read-only/comment_11_e8f1576e67d6368eb28aa89c30aaa34c._comment
 create mode 100644 doc/todo/unlock_--read-only/comment_1_19da9b33836df34b7d747039e6863586._comment
 create mode 100644 doc/todo/unlock_--read-only/comment_2_1658f775ef9340e65711512049085dd7._comment
 create mode 100644 doc/todo/unlock_--read-only/comment_3_305c1b867c38edf74cdff1638e5b1cfa._comment
 create mode 100644 doc/todo/unlock_--read-only/comment_4_515e21cf5c2dfbf9fd780af9cef2e726._comment
 create mode 100644 doc/todo/unlock_--read-only/comment_5_645bccbcd3499eb552a24563cb613af2._comment
 create mode 100644 doc/todo/unlock_--read-only/comment_6_eda5475b89536726ec29a831e2748f43._comment
 create mode 100644 doc/todo/unlock_--read-only/comment_7_3ea1a354bb631539df1ac941e76988e1._comment
 create mode 100644 doc/todo/unlock_--read-only/comment_8_c39e204047bd9a1999b69a433b22b16d._comment
 create mode 100644 doc/todo/unlock_--read-only/comment_9_82a8bfe07d78fc29d306fa5545e866a7._comment
 create mode 100644 doc/todo/unregisterurl_KEY_URL.mdwn
 create mode 100644 doc/todo/unregisterurl_KEY_URL/comment_1_9562b4583203b49ec68162f3a4816ad7._comment
 create mode 100644 doc/todo/unregisterurl_KEY_URL/comment_2_87ec9a2037eaa84011f7e7ecf43d31aa._comment
 create mode 100644 doc/todo/unregisterurl_KEY_URL/comment_3_22edc4e69a686511c76c7c7608da5793._comment
 create mode 100644 doc/todo/upload_large_chunks_without_buffering_in_memory.mdwn
 create mode 100644 doc/todo/use_git-mktree_rather_than_index_file.mdwn
 create mode 100644 doc/todo/use_systemd_credential_system_for_git-annex_credentials.mdwn
 create mode 100644 doc/todo/using_file_metadata_for_preferred___40__wanted__41___content.mdwn
 create mode 100644 doc/todo/using_file_metadata_for_preferred___40__wanted__41___content/comment_1_8c377382b772e4c2d0c1f981010b8d91._comment
 create mode 100644 doc/todo/v11_changes.mdwn
 create mode 100644 doc/todo/v9_changes.mdwn
 create mode 100644 doc/todo/verified_relaxed_urls.mdwn
 create mode 100644 doc/todo/warn_of_breaking_changes_same_way_git_does.mdwn
 create mode 100644 doc/todo/way_to_instruct_on_how_to_decide_on_extension__63__.mdwn
 create mode 100644 doc/todo/way_to_instruct_on_how_to_decide_on_extension__63__/comment_1_b3e9fcb09b6455301a5f7a9bf50a8a49._comment
 create mode 100644 doc/todo/way_to_untrust_without_unncessary_branch_update.mdwn
 create mode 100644 doc/todo/webapp__58___show_times_of_events.mdwn
 create mode 100644 doc/todo/webapp_export_remote_configuration_interface.mdwn
 create mode 100644 doc/todo/webapp_nudge_when_less_than_numcopies_clones.mdwn
 create mode 100644 doc/todo/webapp_ssh_setup_should_work_with_locked_down_git-annex-shell_account.mdwn
 create mode 100644 doc/todo/wherewas.mdwn
 create mode 100644 doc/todo/whishlist__58___GPG_alternatives_like_AGE.mdwn
 create mode 100644 doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_1_92a7d08946a3ed95d0f0413e6c6208ae._comment
 create mode 100644 doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_2_18ae790f59a9dbeda745e6f6f45384cb._comment
 create mode 100644 doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_3_09b89df28a3a3dab2f0fbf2f56feafe1._comment
 create mode 100644 doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_4_b9de19ba8382225ac8c65ee1ad8110a8._comment
 create mode 100644 doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_5_c81d61a221fd93eb25765998b67bbde7._comment
 create mode 100644 doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_6_991bf6846513818c00b75b7962b0fb2e._comment
 create mode 100644 doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_7_d86cf1376fbbd85e9ea63d7b7afbd1fc._comment
 create mode 100644 doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_8_d784886328bc00b2adaba2391776d2c8._comment
 create mode 100644 doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_9_18861f94b677a40c2d1c0014338231c6._comment
 create mode 100644 doc/todo/whishlist__58___kde-connect_as_a_transport.mdwn
 create mode 100644 doc/todo/whishlist__58___kde-connect_as_a_transport/comment_1_14426ad1fa5dfc32d290da484c1e4c7b._comment
 create mode 100644 doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities.mdwn
 create mode 100644 doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_1_40985c5919f20fd47fa57caec09bfa3c._comment
 create mode 100644 doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_2_1d9c331e774138ceb89b1f7920bb76d4._comment
 create mode 100644 doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_3_88b58dd27cbff3f046b6f8d1c612f87f._comment
 create mode 100644 doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_4_28e5593e0a58fb7d7a2a297fa63e8208._comment
 create mode 100644 doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_5_43603d84801cfe0ecfcdc408db97ae22._comment
 create mode 100644 doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_6_a623b2e131dd85f50e04483d262abc9a._comment
 create mode 100644 doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_7_91c17601eed0936bab17cdf9ec5f3ecb._comment
 create mode 100644 doc/todo/windows_support.mdwn
 create mode 100644 doc/todo/windows_support/comment_10_394127e34e07ab3dc0e7b94ee6898866._comment
 create mode 100644 doc/todo/windows_support/comment_11_c91eb7da8ee05064a5bc4a6e2203314b._comment
 create mode 100644 doc/todo/windows_support/comment_12_0775dc22516cfa8c5e7deea954084947._comment
 create mode 100644 doc/todo/windows_support/comment_13_4dfb65242280c2e28796f1ab8f022dea._comment
 create mode 100644 doc/todo/windows_support/comment_14_a8519b722cb94f9363d4a8a8bd40e942._comment
 create mode 100644 doc/todo/windows_support/comment_15_61d1281072de2bb418cf96fd8b563d45._comment
 create mode 100644 doc/todo/windows_support/comment_16_6bbcf900874e950b08cdf0410f7a75d2._comment
 create mode 100644 doc/todo/windows_support/comment_17_653b36e0838308dd85d38b05d3df5077._comment
 create mode 100644 doc/todo/windows_support/comment_18_fbd19cd8365808daa007f44ff167c635._comment
 create mode 100644 doc/todo/windows_support/comment_19_87e06eb2968856ce97b6162bc14203c1._comment
 create mode 100644 doc/todo/windows_support/comment_1_3cc26ad8101a22e95a8c60cf0c4dedcc._comment
 create mode 100644 doc/todo/windows_support/comment_20_7d83963db52d5dedd65f8cf7937dff4f._comment
 create mode 100644 doc/todo/windows_support/comment_21_49ef5997d36ade4797ef77b1b62f5405._comment
 create mode 100644 doc/todo/windows_support/comment_22_8e5b8ec9e6a63bcde7390511c92d2940._comment
 create mode 100644 doc/todo/windows_support/comment_23_616a7d579730e5a4f5cc314d6328bfd0._comment
 create mode 100644 doc/todo/windows_support/comment_24_f50de72a082476e0a2e7587368191788._comment
 create mode 100644 doc/todo/windows_support/comment_25_5eb1a4693db88a9e05500ad66edce61d._comment
 create mode 100644 doc/todo/windows_support/comment_26_99d0541d1c7f7c82a67d481c61209670._comment
 create mode 100644 doc/todo/windows_support/comment_2_8acae818ce468967499050bbe3c532ea._comment
 create mode 100644 doc/todo/windows_support/comment_3_bd0a12f4c9b884ab8a06082842381a01._comment
 create mode 100644 doc/todo/windows_support/comment_4_ad06b98b2ddac866ffee334e41fee6a8._comment
 create mode 100644 doc/todo/windows_support/comment_5_444fc7251f57db241b6e80abae41851c._comment
 create mode 100644 doc/todo/windows_support/comment_6_34f1f60b570c389bb1e741b990064a7e._comment
 create mode 100644 doc/todo/windows_support/comment_7_a5ca56c487257434650420acfa60e39f._comment
 create mode 100644 doc/todo/windows_support/comment_8_61214de7d967740d42905f3823ce2f65._comment
 create mode 100644 doc/todo/windows_support/comment_9_259a0b1a6f4d8d1944173380adc5e7c8._comment
 create mode 100644 doc/todo/wishlist__58___--dry-run_option_for_all_commands.mdwn
 create mode 100644 doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_1_03bf493d5a7f957339f9aa388ba85ef8._comment
 create mode 100644 doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_2_8ac7ae6937d219854bc60b56b8646d8b._comment
 create mode 100644 doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_3_411cabdfebe353d35f8dc78364f4a507._comment
 create mode 100644 doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_4_2824eb6fd3fe9a44d48639c38d478351._comment
 create mode 100644 doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_5_e139434d88638d05c84b721abdbb406c._comment
 create mode 100644 doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_6_cd430ea90286759eb5311ef376f63929._comment
 create mode 100644 doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find.mdwn
 create mode 100644 doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_1_c355878ac49bbb23a4cf82fe685da9ee._comment
 create mode 100644 doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_2_da30a066c4de465fe172ad01057e2380._comment
 create mode 100644 doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_3_f3eadd6241f5cc2886515b2826dc5cf9._comment
 create mode 100644 doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_4_c766c1465407324fc933db78be325b33._comment
 create mode 100644 doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_5_dcda795ff29de150ced0c839c85f7837._comment
 create mode 100644 doc/todo/wishlist__58___Add_--byte-limit_option.mdwn
 create mode 100644 doc/todo/wishlist__58___Freeing_X_space_on_remote_Y.mdwn
 create mode 100644 doc/todo/wishlist__58___Option_to_specify_max_transfer_rate.mdwn
 create mode 100644 doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_1_4fd870e14b5b70c8a6ade41406294387._comment
 create mode 100644 doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_2_dd854f297ad6a94b54be9f3edfd0f766._comment
 create mode 100644 doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_3_a8b7e90a473d5937807cc7eb456efe33._comment
 create mode 100644 doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_4_53c43e480a37b20bc8fed9d38527651b._comment
 create mode 100644 doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_5_428d638e1f41d84df7e6c51675fe65da._comment
 create mode 100644 doc/todo/wishlist__58___Parity_files_for_encrypted_remotes.mdwn
 create mode 100644 doc/todo/wishlist__58___Parity_files_for_encrypted_remotes/comment_1_5fbffd74f9d89857b807093cd7a5941e._comment
 create mode 100644 doc/todo/wishlist__58___Restore_s3_files_moved_to_Glacier.mdwn
 create mode 100644 doc/todo/wishlist__58___Restore_s3_files_moved_to_Glacier/comment_1_eb934756cb2af7fa13ad3b5fad7f85b2._comment
 create mode 100644 doc/todo/wishlist__58_____39__get__39___queue_and_schedule.mdwn
 create mode 100644 doc/todo/wishlist__58_____39__get__39___queue_and_schedule/comment_1_d6ab311beee2ce5f73ae325a4ae463d4._comment
 create mode 100644 doc/todo/wishlist__58_____39__get__39___queue_and_schedule/comment_2_c2e9ab3ff49c22f27dd800512e7b7961._comment
 create mode 100644 doc/todo/wishlist__58_____39__whereis__39___support_in_the_webapp.mdwn
 create mode 100644 doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__.mdwn
 create mode 100644 doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_1_c83a6cddd0ce222205a149cfa41ca395._comment
 create mode 100644 doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_2_353fbc2bcc40cb8c9af42907a34c6e5a._comment
 create mode 100644 doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_3_3e830035df580601f038ce3a7003c39d._comment
 create mode 100644 doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_4_e5516689bc128c061dcd66649dc69584._comment
 create mode 100644 doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_5_be740e4b06d9130ae6afc5783da3c0e0._comment
 create mode 100644 doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_6_79d115f95cec46bb51e7fba078524db1._comment
 create mode 100644 doc/todo/wishlist__58_____96__git_annex_optimize__96__.mdwn
 create mode 100644 doc/todo/wishlist__58___allow_custom_S3_url_in_webapp.mdwn
 create mode 100644 doc/todo/wishlist__58___allow_custom_S3_url_in_webapp/comment_1_3d1ea5579a6ad0c0efde58dca11c10aa._comment
 create mode 100644 doc/todo/wishlist__58___allow_custom_S3_url_in_webapp/comment_2_f96bb81fde4185368dc6ea5a5aed87da._comment
 create mode 100644 doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads.mdwn
 create mode 100644 doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_1_36ae3c75053d5ec278b5e6eb2084d57a._comment
 create mode 100644 doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_3_be8eb800523db8cf7a2c68a28fbf5ea5._comment
 create mode 100644 doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_3_d9f725de41a8572c85e4c6d9b4bcc927._comment
 create mode 100644 doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_4_f52492e4cc6f965515800bd1c0e05c90._comment
 create mode 100644 doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_5_5b36656fc5fa124e763f06711d9da32b._comment
 create mode 100644 doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_6_285215a4466806baf85b8606f680494a._comment
 create mode 100644 doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_7_15bf62e46db4b84ed3156f550f03de42._comment
 create mode 100644 doc/todo/wishlist__58___annex.largefiles_configuration_in_webapp_and_sync.mdwn
 create mode 100644 doc/todo/wishlist__58___annex.largefiles_configuration_in_webapp_and_sync/comment_1_db632de391ce9fce42af51a770ed3aeb._comment
 create mode 100644 doc/todo/wishlist__58___annex.largefiles_configuration_in_webapp_and_sync/comment_2_4a0931d9884054d764fde315d4fe4851._comment
 create mode 100644 doc/todo/wishlist__58___archive_from_remote_with_the_least_free_space.mdwn
 create mode 100644 doc/todo/wishlist__58___archive_from_remote_with_the_least_free_space/comment_1_6813fdc7ecc98765a5d35d34163a1712._comment
 create mode 100644 doc/todo/wishlist__58___archive_from_remote_with_the_least_free_space/comment_2_21a249cedca1ceb80d10784004735524._comment
 create mode 100644 doc/todo/wishlist__58___assistant_logging_improvements.mdwn
 create mode 100644 doc/todo/wishlist__58___assistant_logging_improvements/comment_1_683e2e3c94345cb6f35028cd130a4dcc._comment
 create mode 100644 doc/todo/wishlist__58___derived_content_support.mdwn
 create mode 100644 doc/todo/wishlist__58___disable_automatic_commits.mdwn
 create mode 100644 doc/todo/wishlist__58___disable_automatic_commits/comment_1_3f76bc558b59f90d0276be8cd24c6797._comment
 create mode 100644 doc/todo/wishlist__58___disable_automatic_commits/comment_2_a031373f7251b5395100bcfc57519049._comment
 create mode 100644 doc/todo/wishlist__58___disable_automatic_commits/comment_3_53b1321d5bcaf4139f9fbbd17f26fe75._comment
 create mode 100644 doc/todo/wishlist__58___disable_automatic_commits/comment_4_e021de3647a00aa0259a247441de50eb._comment
 create mode 100644 doc/todo/wishlist__58___disable_automatic_commits/comment_5_701ef8d7bca858150bc0ae070d21755d._comment
 create mode 100644 doc/todo/wishlist__58___disable_automatic_commits/comment_6_195815446f3ec78901c1ddd245b86c4c._comment
 create mode 100644 doc/todo/wishlist__58___display_status_of_remotes_in_the_webapp.mdwn
 create mode 100644 doc/todo/wishlist__58___encrypted_git_remote_on_hosting_site_from_webapp.mdwn
 create mode 100644 doc/todo/wishlist__58___generic_annex.cost-command.mdwn
 create mode 100644 doc/todo/wishlist__58___generic_annex.cost-command/comment_1_b2060ec194e3ae53bd286f2bae799984._comment
 create mode 100644 doc/todo/wishlist__58___global_progress_status.mdwn
 create mode 100644 doc/todo/wishlist__58___global_progress_status/comment_1_d915dce144071f768ee9bcdead07a0e5._comment
 create mode 100644 doc/todo/wishlist__58___global_progress_status/comment_2_816f41f5436543fc09e7d7df82a8c8d5._comment
 create mode 100644 doc/todo/wishlist__58___global_progress_status/comment_3_587e8befa0e52d8880362a32799df492._comment
 create mode 100644 doc/todo/wishlist__58___global_progress_status/comment_4_60b7597af2b86ce6bcb31731f6d8c54e._comment
 create mode 100644 doc/todo/wishlist__58___history_of_operations.mdwn
 create mode 100644 doc/todo/wishlist__58___history_of_operations/comment_1_f9a77ce83c6f39b6272d5c577ffbb9f9._comment
 create mode 100644 doc/todo/wishlist__58___matching_options_for_branches.mdwn
 create mode 100644 doc/todo/wishlist__58___matching_options_for_branches/comment_1_c0d442b646dc40d870b10098a0ee5408._comment
 create mode 100644 doc/todo/wishlist__58___move_pending_transfers_for_a_host_to_the_end_of_the_queue_when_one_fails.mdwn
 create mode 100644 doc/todo/wishlist__58___move_pending_transfers_for_a_host_to_the_end_of_the_queue_when_one_fails/comment_1_82ee9de610a0ac55cd1c27c211079e5b._comment
 create mode 100644 doc/todo/wishlist__58___move_pending_transfers_for_a_host_to_the_end_of_the_queue_when_one_fails/comment_2_bea55156bd32cf9e6dd9b946ba1bb8c1._comment
 create mode 100644 doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode.mdwn
 create mode 100644 doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_1_f95f2c92a46c1bd00c627aa19b08c875._comment
 create mode 100644 doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_2_bb756ddf06c52ca52d73af319f0265b0._comment
 create mode 100644 doc/todo/wishlist__58___perform_fsck_remotely.mdwn
 create mode 100644 doc/todo/wishlist__58___perform_fsck_remotely/comment_1_db92311dcdb1ef0ab0413f83e191c70c._comment
 create mode 100644 doc/todo/wishlist__58___perform_fsck_remotely/comment_2_2f0dbaf143d94290bfbebb6869eb7241._comment
 create mode 100644 doc/todo/wishlist__58___perform_fsck_remotely/comment_3_5ec2e0e248dfd4ca46aef89cc5658d18._comment
 create mode 100644 doc/todo/wishlist__58___provide_a_config_option_for_using_new_hashing_scheme_in_non-bare_remotes.mdwn
 create mode 100644 doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl.mdwn
 create mode 100644 doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl/comment_1_b79976afc2242791523e63831f30af71._comment
 create mode 100644 doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl/comment_2_1741d2392006a9af9cfd1f3b847600b9._comment
 create mode 100644 doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl/comment_3_b6fb39030f98bbc9915712e3d35d1838._comment
 create mode 100644 doc/todo/wishlist__58___traffic_accounting_for_git-annex.mdwn
 create mode 100644 doc/todo/wishlist__58___unify_directory_scheme_for_the_store.mdwn
 create mode 100644 doc/todo/wishlist__58___unify_directory_scheme_for_the_store/comment_1_44da58beaaab359ecaba7fb905ca4ae1._comment
 create mode 100644 doc/todo/wishlist__58___unify_directory_scheme_for_the_store/comment_2_bc698c501ecdb56df57171f4f3bb831a._comment
 create mode 100644 doc/todo/wishlist__58___unify_directory_scheme_for_the_store/comment_3_e555d0dbbaa05528806905c6a940724b._comment
 create mode 100644 doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__.mdwn
 create mode 100644 doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_1_bbbb9c4c71b8c56eaf134b794d2345c3._comment
 create mode 100644 doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_2_1eb09a234616cb0df7fed9016827dd0c._comment
 create mode 100644 doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_3_942c2decd6dda0730e2efe4ed6e6cd16._comment
 create mode 100644 doc/todo/wishlist__91__minor__93____58___add_time_stamps_to_annex_log_popups_in_webapp.mdwn
 create mode 100644 doc/todo/wishlist__91__minor__93____58___add_time_stamps_to_annex_log_popups_in_webapp/comment_1_ec90432a7d46383071401b05243d621f._comment
 create mode 100644 doc/todo/wishlist_degraded_files.mdwn
 create mode 100644 doc/todo/withExclusiveLock_blocking_issue.mdwn
 create mode 100644 doc/todo/worktree_overwrite_races.mdwn
 create mode 100644 doc/todo/yt-dlp__58___parse__47__handle___40__error__41_____34__Video_unavailable__34__.mdwn
 create mode 100644 doc/todo/yt-dlp__58___parse__47__handle___40__error__41_____34__Video_unavailable__34__/comment_1_8b761cfc9b2ca784efc15b39689c31f5._comment
 create mode 100644 doc/transferring_data.mdwn
 create mode 100644 doc/trust.mdwn
 create mode 100644 doc/trust/comment_1_305e4e7c6b75db29212b758e8504d8c9._comment
 create mode 100644 doc/trust/comment_2_2262eaa830306d3dc75999bc0433b6a8._comment
 create mode 100644 doc/tuning.mdwn
 create mode 100644 doc/tuning/comment_1_f8af8e9b696d32d238ebd56a3b8058c4._comment
 create mode 100644 doc/tuning/comment_2_a0091dbb39b79dfe101d05f9a5db216f._comment
 create mode 100644 doc/tuning/comment_4_1c576f9a5e0a0b5d7d8edf9d40462874._comment
 create mode 100644 doc/tuning/comment_4_5b782975263480a405c5e8dcfe058007._comment
 create mode 100644 doc/tuning/comment_5_0143b798e75ad25c5917794a49a879fb._comment
 create mode 100644 doc/upgrades.mdwn
 create mode 100644 doc/upgrades/SHA_size.mdwn
 create mode 100644 doc/upgrades/SHA_size/comment_1_20f9b7b75786075de666b2146dc13a60._comment
 create mode 100644 doc/upgrades/gcrypt.mdwn
 create mode 100644 doc/upgrades/gcrypt/comment_1_606c1527735996ae671f78948e4ad84b._comment
 create mode 100644 doc/upgrades/insecure_embedded_creds.mdwn
 create mode 100644 doc/use_case/Alice.mdwn
 create mode 100644 doc/use_case/Bob.mdwn
 create mode 100644 doc/users.mdwn
 create mode 100644 doc/users/Ilya__95__Shlyakhter.mdwn
 create mode 100644 doc/users/anarcat.mdwn
 create mode 100644 doc/users/andrew.mdwn
 create mode 100644 doc/users/ben.mdwn
 create mode 100644 doc/users/chris.mdwn
 create mode 100644 doc/users/chrysn.mdwn
 create mode 100644 doc/users/clacke.mdwn
 create mode 100644 doc/users/claes.wallin.mdwn
 create mode 100644 doc/users/dandi.mdwn
 create mode 100644 doc/users/datalad.mdwn
 create mode 100644 doc/users/dave.mdwn
 create mode 100644 doc/users/dckc.mdwn
 create mode 100644 doc/users/falsifian.mdwn
 create mode 100644 doc/users/fmarier.mdwn
 create mode 100644 doc/users/frederik.mdwn
 create mode 100644 doc/users/gebi.mdwn
 create mode 100644 doc/users/greg.mdwn
 create mode 100644 doc/users/james.mdwn
 create mode 100644 doc/users/jgoerzen.mdwn
 create mode 100644 doc/users/jkniiv.mdwn
 create mode 100644 doc/users/joey.mdwn
 create mode 100644 doc/users/joey/comment_1_0ccf207fd817f9b5555aad030bd4957f._comment
 create mode 100644 doc/users/joey/comment_2_7e0b8d499d2bededf01591a7c5686f8f._comment
 create mode 100644 doc/users/kolam.mdwn
 create mode 100644 doc/users/mih.mdwn
 create mode 100644 doc/users/nobodyinperson.mdwn
 create mode 100644 doc/users/parhuzamos.mdwn
 create mode 100644 doc/users/petersjt014.mdwn
 create mode 100644 doc/users/ptilopteri.mdwn
 create mode 100644 doc/users/sameerds.mdwn
 create mode 100644 doc/users/thk.mdwn
 create mode 100644 doc/users/timothe.mdwn
 create mode 100644 doc/users/tobiastheviking.mdwn
 create mode 100644 doc/users/unqueued.mdwn
 create mode 100644 doc/users/wzhd.mdwn
 create mode 100644 doc/users/yarikoptic.mdwn
 create mode 100644 doc/users/yoh.mdwn
 create mode 100644 doc/videos.mdwn
 create mode 100644 doc/videos/FOSDEM2012.mdwn
 create mode 100644 doc/videos/LCA2013.mdwn
 create mode 100644 doc/videos/git-annex_assistant_archiving.mdwn
 create mode 100644 doc/videos/git-annex_assistant_introduction.mdwn
 create mode 100644 doc/videos/git-annex_assistant_introduction/comment_1_f42ad4183c2c28319d3705a82fceb82f._comment
 create mode 100644 doc/videos/git-annex_assistant_introduction/comment_2_b62f4eeeac1138570f7cb8c98d41c2cb._comment
 create mode 100644 doc/videos/git-annex_assistant_lan.mdwn
 create mode 100644 doc/videos/git-annex_assistant_lan/comment_1_df8c8b6d9d63fbf5462b225edbb23c82._comment
 create mode 100644 doc/videos/git-annex_assistant_lan/comment_2_d4e3122da9c9e27fbe872e09fcde762b._comment
 create mode 100644 doc/videos/git-annex_assistant_lan/comment_3_d43ee0a335c2f010b437cf28437455c2._comment
 create mode 100644 doc/videos/git-annex_assistant_lan/comment_4_c710e27db41311b157d8caaafc32dc7e._comment
 create mode 100644 doc/videos/git-annex_assistant_sync_demo.mdwn
 create mode 100644 doc/videos/git-annex_views_demo.mdwn
 create mode 100644 doc/videos/git-annex_watch_demo.mdwn
 create mode 100644 doc/videos/git-annex_weppapp_demo.mdwn
 create mode 100644 doc/videos/tuebix.mdwn
 create mode 100644 doc/walkthrough.mdwn
 create mode 100644 doc/walkthrough/adding_a_remote.mdwn
 create mode 100644 doc/walkthrough/adding_a_remote/comment_1_0a59355bd33a796aec97173607e6adc9._comment
 create mode 100644 doc/walkthrough/adding_a_remote/comment_2_f8cd79ef1593a8181a7f1086a87713e8._comment
 create mode 100644 doc/walkthrough/adding_a_remote/comment_3_60691af4400521b5a8c8d75efe3b44cb._comment
 create mode 100644 doc/walkthrough/adding_a_remote/comment_4_6f7cf5c330272c96b3abeb6612075c9d._comment
 create mode 100644 doc/walkthrough/adding_a_remote/comment_5_bcbe480aa710ce693ee03d86884f1820._comment
 create mode 100644 doc/walkthrough/adding_a_remote/comment_6_15ea28114e69dddac82fddaf009079ca._comment
 create mode 100644 doc/walkthrough/adding_a_remote/comment_7_caea7e4e9ec904617c6ec1a33368090f._comment
 create mode 100644 doc/walkthrough/adding_files.mdwn
 create mode 100644 doc/walkthrough/automatically_managing_content.mdwn
 create mode 100644 doc/walkthrough/backups.mdwn
 create mode 100644 doc/walkthrough/backups/comment_1_d0244791d2abbf29553546a6a6568a0f._comment
 create mode 100644 doc/walkthrough/creating_a_repository.mdwn
 create mode 100644 doc/walkthrough/fsck__58___verifying_your_data.mdwn
 create mode 100644 doc/walkthrough/fsck__58___when_things_go_wrong.mdwn
 create mode 100644 doc/walkthrough/getting_file_content.mdwn
 create mode 100644 doc/walkthrough/modifying_annexed_files.mdwn
 create mode 100644 doc/walkthrough/modifying_annexed_files/comment_1_624b4a0b521b553d68ab6049f7dbaf8c._comment
 create mode 100644 doc/walkthrough/modifying_annexed_files/comment_2_b000622304535d32b69db17d51156b21._comment
 create mode 100644 doc/walkthrough/more.mdwn
 create mode 100644 doc/walkthrough/moving_file_content_between_repositories.mdwn
 create mode 100644 doc/walkthrough/moving_file_content_between_repositories/comment_1_4c30ade91fc7113a95960aa3bd1d5427._comment
 create mode 100644 doc/walkthrough/moving_file_content_between_repositories/comment_2_7d90e1e150e7524ba31687108fcc38d6._comment
 create mode 100644 doc/walkthrough/moving_file_content_between_repositories/comment_3_558d80384434207b9cfc033763863de3._comment
 create mode 100644 doc/walkthrough/moving_file_content_between_repositories/comment_4_a2f343eceed9e9fba1670f21e0fc6af4._comment
 create mode 100644 doc/walkthrough/quiet_please__58___When_git-annex_seems_to_skip_files.mdwn
 create mode 100644 doc/walkthrough/removing_files.mdwn
 create mode 100644 doc/walkthrough/removing_files/comment_1_cb65e7c510b75be1c51f655b058667c6._comment
 create mode 100644 doc/walkthrough/removing_files/comment_2_64709ea4558915edd5c8ca4486965b07._comment
 create mode 100644 doc/walkthrough/removing_files/comment_3_91e995867a731325dfdf3331f69a238c._comment
 create mode 100644 doc/walkthrough/removing_files/comment_4_9b575f7f2b67b36599890dd5455dcf47._comment
 create mode 100644 doc/walkthrough/removing_files__58___When_things_go_wrong.mdwn
 create mode 100644 doc/walkthrough/renaming_files.mdwn
 create mode 100644 doc/walkthrough/renaming_files/comment_1_c05f70079c265d23e882f92aaa4d28f8._comment
 create mode 100644 doc/walkthrough/renaming_files/comment_2_fe83c600e080131b3109fe616940a25e._comment
 create mode 100644 doc/walkthrough/renaming_files/comment_3_6b579a4f2990a28b33a8170ebd39da5c._comment
 create mode 100644 doc/walkthrough/renaming_files/comment_4_1cf4cb6be73223755cb611ec097d1498._comment
 create mode 100644 doc/walkthrough/renaming_files/comment_5_bc3e37868b276c52a51586641cdb92ae._comment
 create mode 100644 doc/walkthrough/renaming_files/comment_6_2ae2cc3dba5db4d4354a5b49c490272e._comment
 create mode 100644 doc/walkthrough/syncing.mdwn
 create mode 100644 doc/walkthrough/transferring_files__58___When_things_go_wrong.mdwn
 create mode 100644 doc/walkthrough/unused_data.mdwn
 create mode 100644 doc/walkthrough/unused_data/comment_1_684b7b652d3a8ec04f32129c5528f1ab._comment
 create mode 100644 doc/walkthrough/unused_data/comment_2_e2ccd9a209c7a104004e998135d4b675._comment
 create mode 100644 doc/walkthrough/unused_data/comment_3_5f973eb7c265015fcd400b6b0bbdf235._comment
 create mode 100644 doc/walkthrough/unused_data/comment_4_2110ed6316b6a0df4ef3e1c8bc97ab99._comment
 create mode 100644 doc/walkthrough/unused_data/comment_5_46acb9fbbd5ef19f65115723888f3eb6._comment
 create mode 100644 doc/walkthrough/using_bup.mdwn
 create mode 100644 doc/walkthrough/using_ddar.mdwn
 create mode 100644 doc/walkthrough/using_special_remotes.mdwn
 create mode 100644 doc/walkthrough/using_ssh_remotes.mdwn
 create mode 100644 doc/walkthrough/using_ssh_remotes/comment_10_98e97c4d7fbbcd449eddf683967a71d6._comment
 create mode 100644 doc/walkthrough/using_ssh_remotes/comment_11_f2775a151ed50caba27057bd9c38bae2._comment
 create mode 100644 doc/walkthrough/using_ssh_remotes/comment_12_a8bc6110128431ca2a8624ddc75ea364._comment
 create mode 100644 doc/walkthrough/using_ssh_remotes/comment_2_365db5820d96d5daa62c19fd76fcdf1e._comment
 create mode 100644 doc/walkthrough/using_ssh_remotes/comment_2_451fd0c6a25ee61ef137e8e5be0c286b._comment
 create mode 100644 doc/walkthrough/using_ssh_remotes/comment_3_b2f15a46620385da26d5fe8f11ebfc1a._comment
 create mode 100644 doc/walkthrough/using_ssh_remotes/comment_4_433ccc87fbb0a13e32d59d77f0b4e56c._comment
 create mode 100644 doc/walkthrough/using_ssh_remotes/comment_5_a9805c7965da0b88a1c9f7f207c450a1._comment
 create mode 100644 doc/walkthrough/using_ssh_remotes/comment_6_9d5c12c056892b706cf100ea01866685._comment
 create mode 100644 doc/walkthrough/using_ssh_remotes/comment_7_725e7dbb2d0a74a035127cb01ee0442c._comment
 create mode 100644 doc/walkthrough/using_ssh_remotes/comment_8_8448e55026d2c2b50d8da41707686bea._comment
 create mode 100644 doc/walkthrough/using_ssh_remotes/comment_9_61833299a9878f23ac57598fa6da8839._comment
 create mode 100644 doc/walkthrough/using_tags_and_branches.mdwn
 create mode 100644 doc/workflow.mdwn
 create mode 100644 doc/workflow/comment_1_e4b2199944c3a248562bddf3cf9e2829._comment
 create mode 100644 doc/workflow/comment_2_67edac29c0e7b5a768511a0fd0878947._comment
 create mode 100644 git-annex.cabal
 create mode 100644 git-annex.hs
 create mode 100644 git-union-merge.hs
 create mode 100644 stack-lts-18.13.yaml
 create mode 100644 stack.yaml
 create mode 100644 standalone/licences.gz
 create mode 100644 standalone/linux/skel/README
 create mode 100755 standalone/linux/skel/git
 create mode 100755 standalone/linux/skel/git-annex
 create mode 100755 standalone/linux/skel/git-annex-shell
 create mode 100755 standalone/linux/skel/git-annex-webapp
 create mode 100755 standalone/linux/skel/git-receive-pack
 create mode 100755 standalone/linux/skel/git-shell
 create mode 100755 standalone/linux/skel/git-upload-pack
 create mode 100755 standalone/linux/skel/runshell
 create mode 100644 standalone/linux/stack-i386ancient.yaml
 create mode 100644 standalone/osx/Info.plist.template
 create mode 100644 standalone/osx/git-annex.app/Contents/MacOS/README
 create mode 100755 standalone/osx/git-annex.app/Contents/MacOS/git
 create mode 100755 standalone/osx/git-annex.app/Contents/MacOS/git-annex
 create mode 100755 standalone/osx/git-annex.app/Contents/MacOS/git-annex-shell
 create mode 100755 standalone/osx/git-annex.app/Contents/MacOS/git-annex-webapp
 create mode 100755 standalone/osx/git-annex.app/Contents/MacOS/git-receive-pack
 create mode 100755 standalone/osx/git-annex.app/Contents/MacOS/git-shell
 create mode 100755 standalone/osx/git-annex.app/Contents/MacOS/git-upload-pack
 create mode 100755 standalone/osx/git-annex.app/Contents/MacOS/runshell
 create mode 100644 standalone/osx/git-annex.app/Contents/Resources/git-annex.icns
 create mode 100644 standalone/rpm/git-annex-standalone.spec
 create mode 100755 standalone/rpm/rpmbuild-from-standalone-tarball
 create mode 100644 standalone/trustedkeys.gpg
 create mode 100644 static/activityicon.gif
 create mode 100644 static/css/bootstrap-theme.css
 create mode 100644 static/css/bootstrap.css
 create mode 100644 static/favicon.ico
 create mode 100644 static/fonts/glyphicons-halflings-regular.eot
 create mode 100644 static/fonts/glyphicons-halflings-regular.svg
 create mode 100644 static/fonts/glyphicons-halflings-regular.ttf
 create mode 100644 static/fonts/glyphicons-halflings-regular.woff
 create mode 100644 static/js/bootstrap.js
 create mode 100644 static/js/jquery.full.js
 create mode 100644 static/js/jquery.ui.core.js
 create mode 100644 static/js/jquery.ui.mouse.js
 create mode 100644 static/js/jquery.ui.sortable.js
 create mode 100644 static/js/jquery.ui.widget.js
 create mode 100644 static/js/longpolling.js
 create mode 100644 static/syncicon.gif
 create mode 100644 templates/README
 create mode 100644 templates/actionbutton.hamlet
 create mode 100644 templates/bootstrap.hamlet
 create mode 100644 templates/configurators/adddrive.hamlet
 create mode 100644 templates/configurators/adddrive/combine.hamlet
 create mode 100644 templates/configurators/adddrive/encrypt.hamlet
 create mode 100644 templates/configurators/adddrive/setupmodal.hamlet
 create mode 100644 templates/configurators/addglacier.hamlet
 create mode 100644 templates/configurators/addia.hamlet
 create mode 100644 templates/configurators/addrepository.hamlet
 create mode 100644 templates/configurators/addrepository/archive.hamlet
 create mode 100644 templates/configurators/addrepository/cloud.hamlet
 create mode 100644 templates/configurators/addrepository/connection.hamlet
 create mode 100644 templates/configurators/addrepository/misc.hamlet
 create mode 100644 templates/configurators/addrepository/ssh.hamlet
 create mode 100644 templates/configurators/addrepository/wormholepairing.hamlet
 create mode 100644 templates/configurators/adds3.hamlet
 create mode 100644 templates/configurators/delete/currentrepository.hamlet
 create mode 100644 templates/configurators/delete/finished.hamlet
 create mode 100644 templates/configurators/delete/start.hamlet
 create mode 100644 templates/configurators/edit/nonannexremote.hamlet
 create mode 100644 templates/configurators/edit/repository.hamlet
 create mode 100644 templates/configurators/edit/webrepository.hamlet
 create mode 100644 templates/configurators/enableaws.hamlet
 create mode 100644 templates/configurators/enabledirectory.hamlet
 create mode 100644 templates/configurators/enableia.hamlet
 create mode 100644 templates/configurators/enablewebdav.hamlet
 create mode 100644 templates/configurators/fsck.cassius
 create mode 100644 templates/configurators/fsck.hamlet
 create mode 100644 templates/configurators/fsck/form.hamlet
 create mode 100644 templates/configurators/fsck/formcontent.hamlet
 create mode 100644 templates/configurators/fsck/preferencesform.hamlet
 create mode 100644 templates/configurators/fsck/status.hamlet
 create mode 100644 templates/configurators/genkeymodal.hamlet
 create mode 100644 templates/configurators/main.hamlet
 create mode 100644 templates/configurators/needconnection.hamlet
 create mode 100644 templates/configurators/needgcrypt.hamlet
 create mode 100644 templates/configurators/needglaciercli.hamlet
 create mode 100644 templates/configurators/needmagicwormhole.hamlet
 create mode 100644 templates/configurators/needtor.hamlet
 create mode 100644 templates/configurators/newrepository.hamlet
 create mode 100644 templates/configurators/newrepository/combine.hamlet
 create mode 100644 templates/configurators/newrepository/first.hamlet
 create mode 100644 templates/configurators/newrepository/form.hamlet
 create mode 100644 templates/configurators/pairing/disabled.hamlet
 create mode 100644 templates/configurators/pairing/local/inprogress.hamlet
 create mode 100644 templates/configurators/pairing/local/prompt.hamlet
 create mode 100644 templates/configurators/pairing/wormhole/prompt.hamlet
 create mode 100644 templates/configurators/pairing/wormhole/start.hamlet
 create mode 100644 templates/configurators/preferences.hamlet
 create mode 100644 templates/configurators/rsync.net/add.hamlet
 create mode 100644 templates/configurators/rsync.net/encrypt.hamlet
 create mode 100644 templates/configurators/ssh/add.hamlet
 create mode 100644 templates/configurators/ssh/combine.hamlet
 create mode 100644 templates/configurators/ssh/confirm.hamlet
 create mode 100644 templates/configurators/ssh/enable.hamlet
 create mode 100644 templates/configurators/ssh/error.hamlet
 create mode 100644 templates/configurators/ssh/expiredpassword.hamlet
 create mode 100644 templates/configurators/ssh/setupmodal.hamlet
 create mode 100644 templates/configurators/ssh/testmodal.hamlet
 create mode 100644 templates/configurators/unused.hamlet
 create mode 100644 templates/configurators/unused/form.hamlet
 create mode 100644 templates/control/log.hamlet
 create mode 100644 templates/control/notrunning.hamlet
 create mode 100644 templates/control/notrunning.julius
 create mode 100644 templates/control/repairrepository.hamlet
 create mode 100644 templates/control/repairrepository/done.hamlet
 create mode 100644 templates/control/repositoryswitcher.hamlet
 create mode 100644 templates/control/shutdown.hamlet
 create mode 100644 templates/controlmenu.hamlet
 create mode 100644 templates/dashboard/main.hamlet
 create mode 100644 templates/dashboard/metarefresh.hamlet
 create mode 100644 templates/dashboard/transfers.cassius
 create mode 100644 templates/dashboard/transfers.hamlet
 create mode 100644 templates/documentation/about.hamlet
 create mode 100644 templates/documentation/license.hamlet
 create mode 100644 templates/documentation/repogroup.hamlet
 create mode 100644 templates/error.cassius
 create mode 100644 templates/error.hamlet
 create mode 100644 templates/notifications/longpolling.julius
 create mode 100644 templates/page.cassius
 create mode 100644 templates/page.hamlet
 create mode 100644 templates/page.julius
 create mode 100644 templates/repolist.hamlet
 create mode 100644 templates/repolist.julius
 create mode 100644 templates/sidebar/alert.hamlet
 create mode 100644 templates/sidebar/main.hamlet

diff --git a/.appveyor.yml b/.appveyor.yml
new file mode 100644
index 0000000000..82e3bfe3f6
--- /dev/null
+++ b/.appveyor.yml
@@ -0,0 +1,141 @@
+# This CI setup provides a largely homogeneous configuration across all
+# major platforms (Windows, MacOS, and Linux). The aim of this test setup is
+# to create a "native" platform experience, using as few cross-platform
+# helper tools as possible.
+#
+# All workers support remote login. Login details are shown at the top of each
+# CI run log.
+#
+# - Linux/Mac workers (via SSH):
+#
+#   - A permitted SSH key must be defined in an APPVEYOR_SSH_KEY environment
+#     variable (via the appveyor project settings)
+#
+#   - SSH login info is given in the form of: 'appveyor@67.225.164.xx -p 22xxx'
+#
+#   - Login with:
+#
+#     ssh -o StrictHostKeyChecking=no <LOGIN>
+#
+#   - to prevent the CI run from exiting, `touch` a file named `BLOCK` in the
+#     user HOME directory (current directory directly after login). The session
+#     will run until the file is removed (or 60 min have passed)
+#
+# - Windows workers (via RDP):
+#
+#   - An RDP password should be defined in an APPVEYOR_RDP_PASSWORD environment
+#     variable (via the appveyor project settings), or a random password is used
+#     every time
+#
+#   - RDP login info is given in the form of IP:PORT
+#
+#   - Login with:
+#
+#     xfreerdp /cert:ignore /dynamic-resolution /u:appveyor /p:<PASSWORD> /v:<LOGIN>
+#
+#   - to prevent the CI run from exiting, create a textfile named
+#     `BLOCK.txt` in the currently directory after login. The session
+#     will run until the file is removed (or 60 min have passed)
+
+# Do a shallow clone with enough commits that queued builds will still
+# find the commit they want to build.
+clone_depth: 100
+
+environment:
+  # Do not use `image` as a matrix dimension, to have fine-grained control over
+  # what tests run on which platform
+  # The ID variable had no impact, but sorts first in the CI run overview
+  # an intelligible name can help to locate a specific test run
+  matrix:
+    # List a CI run for each platform first, to have immediate access when there
+    # is a need for debugging
+
+    # Windows core tests
+    - ID: WinP39core
+      APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2019
+      STACK_ROOT: "c:\\sr"
+    # MacOS core tests
+    - ID: MacP38core
+      APPVEYOR_BUILD_WORKER_IMAGE: macos-monterey
+    # Ubuntu core tests
+    # (disabled because it's not needed)
+    #- ID: Ubu20
+    #  APPVEYOR_BUILD_WORKER_IMAGE: Ubuntu2004
+
+# do not run the CI if only documentation changes were made
+# documentation builds are tested elsewhere and cheaper
+skip_commits:
+  files:
+    - doc/
+    - CHANGELOG
+
+# it is OK to specify paths that may not exist for a particular test run
+cache:
+   - C:\sr -> stack.yaml
+   - C:\Users\appveyor\AppData\Local\Programs\stack -> stack.yaml
+   - /Users/appveyor/.stack -> stack.yaml
+
+# turn of support for MS project build support (not needed)
+build: off
+
+# init cannot use any components from the repo, because it runs prior to
+# cloning it
+init:
+  # remove windows 260-char limit on path names
+  - cmd: powershell Set-Itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name LongPathsEnabled -value 1
+  # enable developer mode on windows
+  # this should enable mklink without admin privileges, but it doesn't seem to work
+  #- cmd: powershell tools\ci\appveyor_enable_windevmode.ps1
+  # enable RDP access on windows (RDP password is in appveyor project config)
+  # this is relatively expensive (1-2min), but very convenient to jump into any build at any time
+  - cmd: powershell.exe iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))
+
+install:
+  # enable external SSH access to CI worker on all other systems
+  # needs APPVEYOR_SSH_KEY defined in project settings (or environment)
+  - sh: curl -sflL 'https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-ssh.sh' | bash -e -
+  # install stack (works on linux, OSX, and windows)
+  - curl -sSL https://get.haskellstack.org/ | sh
+
+# Building dependencies takes almost too long on windows, so build without
+# optimisation (including when building the dependencies) 
+before_build:
+  - sh: cp stack.yaml stack.yaml.build
+  - ps: cp stack-lts-18.13.yaml stack.yaml.build
+  - sh: 'echo "apply-ghc-options: everything" >> stack.yaml.build'
+  - ps: '"apply-ghc-options: everything" |Add-Content -Path .\stack.yaml.build'
+  - stack --stack-yaml stack.yaml.build build --only-dependencies --ghc-options=-O0
+
+build_script:
+  - stack --stack-yaml stack.yaml.build build --copy-bins --ghc-options=-O0
+
+#after_build:
+#
+
+#before_test:
+#
+
+# Cannot use stack run git-annex because it does not support --ghc-options
+# and would rebuild all deps. Instead, use the binary --copy-bins installed.
+test_script:
+  - cmd: C:\Users\appveyor\AppData\Roaming\local\bin\git-annex.exe test
+  - sh: ln -s $(stack path --local-bin)/git-annex git-annex
+  - sh: ln -s $(stack path --local-bin)/git-annex git-annex-shell
+  - sh: PATH=`pwd`:$PATH; export PATH; git-annex test
+
+#after_test:
+#
+
+#on_success:
+#
+
+#on_failure:
+#
+
+on_finish:
+  # conditionally block the exit of a CI run for direct debugging
+  - sh: while [ -f ~/BLOCK ]; do sleep 5; done
+  - cmd: powershell.exe while ((Test-Path "C:\Users\\appveyor\\BLOCK.txt")) { Start-Sleep 5 }
+  # block exit until 60 minute timeout, for direct debugging
+  #- sh: while true; do sleep 5; done
+  #- cmd: powershell.exe while ($true) { Start-Sleep 5 }
diff --git a/.codespellrc b/.codespellrc
new file mode 100644
index 0000000000..cb1d82e9c8
--- /dev/null
+++ b/.codespellrc
@@ -0,0 +1,7 @@
+[codespell]
+skip = .git,*.pdf,*.svg,*._comment,jquery.*.js,*.mdwn,changelog,CHANGELOG,list.2018,html,dist,dist-newstyle,.stack-work,man,tags,tmp
+# some common variables etc (case insensitive)
+# keypair - constructs
+## May be TODO later, touches too much
+# sentinal -> sentinel
+ignore-words-list = dne,inout,fo,ot,bu,te,allright,inh,mor,myu,keypair,pasttime,sentinal,startd,ifset
diff --git a/.ghci b/.ghci
new file mode 100644
index 0000000000..931298e050
--- /dev/null
+++ b/.ghci
@@ -0,0 +1,3 @@
+:load Common
+:set -XLambdaCase
+:set -fno-warn-tabs
diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000000..a81b30b931
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+CHANGELOG merge=dpkg-mergechangelogs
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000000..2d0859233f
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,40 @@
+tags
+TAGS
+Setup
+*.hi
+*.o
+tmp
+test
+Build/SysConfig
+Build/Version
+Build/InstallDesktopFile
+Build/Standalone
+Build/BuildVersion
+Build/MakeMans
+git-annex
+git-annex-shell
+man
+git-union-merge
+git-union-merge.1
+doc/.ikiwiki
+html
+*.tix
+.hpc
+dist
+dist-newstyle
+cabal.project.local
+cabal.project.local~*
+result
+git-annex-build-deps*
+# Sandboxed builds
+cabal-dev
+.cabal-sandbox
+cabal.sandbox.config
+.stack-work
+stack.yaml.lock
+# Project-local emacs configuration
+.dir-locals.el
+# OSX related
+.DS_Store
+.virthualenv
+.tasty-rerun-log
diff --git a/.mailmap b/.mailmap
new file mode 100644
index 0000000000..2ea582b7c9
--- /dev/null
+++ b/.mailmap
@@ -0,0 +1,29 @@
+Antoine Beaupré <anarcat@koumbit.org> anarcat <anarcat@web>
+Antoine Beaupré <anarcat@koumbit.org> https://id.koumbit.net/anarcat <https://id.koumbit.net/anarcat@web>
+Greg Grossmeier <greg@grossmeier.net> http://grossmeier.net/ <greg@web>
+Jimmy Tang <jtang@tchpc.tcd.ie> jtang <jtang@web>
+Joachim Breitner <mail@joachim-breitner.de> http://www.joachim-breitner.de/ <nomeata@web>
+Joey Hess <id@joeyh.name> Joey Hess <joey@gnu.kitenet.net>
+Joey Hess <id@joeyh.name> Joey Hess <joey@kitenet.net>
+Joey Hess <id@joeyh.name> Joey Hess <joeyh@debian.org>
+Joey Hess <id@joeyh.name> Joey Hess <joeyh@fischer.debian.org>
+Joey Hess <id@joeyh.name> Joey Hess <joeyh@joeyh.name>
+Joey Hess <id@joeyh.name> Joey Hess <joeyh@oberon.tam-lin.net>
+Joey Hess <id@joeyh.name> Joey Hess <joeyh@oberon.underhill.private>
+Joey Hess <id@joeyh.name> http://joey.kitenet.net/ <joey@web>
+Joey Hess <id@joeyh.name> http://joeyh.name/ <http://joeyh.name/@web>
+Joey Hess <id@joeyh.name> http://joeyh.name/ <joey@web>
+Joey Hess <id@joeyh.name> https://www.google.com/accounts/o8/id?id=AItOawmJfIszzreLNvCqzqzvTayA9_9L6gb9RtY <Joey@web>
+Johan Kiviniemi <devel@johan.kiviniemi.name> http://johan.kiviniemi.name/ <Johan@web>
+Johan Kiviniemi <devel@johan.kiviniemi.name> http://johan.kiviniemi.name/ <http://johan.kiviniemi.name/@web>
+Nicolas Pouillard <nicolas.pouillard@gmail.com> http://ertai.myopenid.com/ <npouillard@web>
+Peter Simons <simons@cryp.to> Peter Simons <simons@ubuntu-12.04>
+Peter Simons <simons@cryp.to> http://peter-simons.myopenid.com/ <http://peter-simons.myopenid.com/@web>
+Philipp Kern <pkern@debian.org> http://phil.0x539.de/ <Philipp_Kern@web>
+Richard Hartmann <richih@debian.org> https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U <Richard@web>
+Yaroslav Halchenko <debian@onerussian.com>
+Yaroslav Halchenko <debian@onerussian.com> http://yarikoptic.myopenid.com/ <site-myopenid@web>
+Yaroslav Halchenko <debian@onerussian.com> https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY <Yaroslav@web>
+Yaroslav Halchenko <debian@onerussian.com> https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4 <https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4@web>
+Øyvind A. Holm <sunny@sunbase.org> http://sunny256.sunbase.org/ <sunny256@web>
+Øyvind A. Holm <sunny@sunbase.org> https://sunny256.wordpress.com/ <sunny256@web>
diff --git a/Annex.hs b/Annex.hs
new file mode 100644
index 0000000000..376f8a9879
--- /dev/null
+++ b/Annex.hs
@@ -0,0 +1,471 @@
+{- git-annex monad
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE GeneralizedNewtypeDeriving, BangPatterns, PackageImports #-}
+
+module Annex (
+	Annex,
+	AnnexState(..),
+	AnnexRead(..),
+	new,
+	run,
+	eval,
+	makeRunner,
+	getRead,
+	getState,
+	changeState,
+	withState,
+	setField,
+	setOutput,
+	getField,
+	addCleanupAction,
+	gitRepo,
+	inRepo,
+	fromRepo,
+	calcRepo,
+	calcRepo',
+	getGitConfig,
+	overrideGitConfig,
+	changeGitRepo,
+	adjustGitRepo,
+	addGitConfigOverride,
+	getGitConfigOverrides,
+	getRemoteGitConfig,
+	withCurrentState,
+	changeDirectory,
+	getGitRemotes,
+	incError,
+) where
+
+import Common
+import qualified Git
+import qualified Git.Config
+import qualified Git.Construct
+import Annex.Fixup
+import Git.HashObject
+import Git.CheckAttr
+import Git.CheckIgnore
+import qualified Git.Hook
+import qualified Git.Queue
+import Types.Key
+import Types.Backend
+import Types.GitConfig
+import qualified Types.Remote
+import Types.Crypto
+import Types.BranchState
+import Types.TrustLevel
+import Types.Group
+import Types.Messages
+import Types.Concurrency
+import Types.UUID
+import Types.FileMatcher
+import Types.NumCopies
+import Types.LockCache
+import Types.DesktopNotify
+import Types.CleanupActions
+import Types.AdjustedBranch
+import Types.WorkerPool
+import Types.IndexFiles
+import Types.CatFileHandles
+import Types.RemoteConfig
+import Types.TransferrerPool
+import Types.VectorClock
+import Annex.VectorClock.Utility
+import Annex.Debug.Utility
+import qualified Database.Keys.Handle as Keys
+import Utility.InodeCache
+import Utility.Url
+import Utility.ResourcePool
+import Utility.HumanTime
+import Git.Credential (CredentialCache(..))
+
+import "mtl" Control.Monad.Reader
+import Control.Concurrent
+import Control.Concurrent.STM
+import qualified Control.Monad.Fail as Fail
+import qualified Data.Map.Strict as M
+import qualified Data.Set as S
+import Data.Time.Clock.POSIX
+
+{- git-annex's monad is a ReaderT around an AnnexState stored in a MVar,
+ - and an AnnexRead. The MVar is not exposed outside this module.
+ -
+ - Note that when an Annex action fails and the exception is caught,
+ - any changes the action has made to the AnnexState are retained,
+ - due to the use of the MVar to store the state.
+ -}
+newtype Annex a = Annex { runAnnex :: ReaderT (MVar AnnexState, AnnexRead) IO a }
+	deriving (
+		Monad,
+		MonadIO,
+		MonadReader (MVar AnnexState, AnnexRead),
+		MonadCatch,
+		MonadThrow,
+		MonadMask,
+		Fail.MonadFail,
+		Functor,
+		Applicative,
+		Alternative
+	)
+
+-- Values that can be read, but not modified by an Annex action.
+data AnnexRead = AnnexRead
+	{ activekeys :: TVar (M.Map Key ThreadId)
+	, activeremotes :: MVar (M.Map (Types.Remote.RemoteA Annex) Integer)
+	, keysdbhandle :: Keys.DbHandle
+	, sshstalecleaned :: TMVar Bool
+	, signalactions :: TVar (M.Map SignalAction (Int -> IO ()))
+	, transferrerpool :: TransferrerPool
+	, debugenabled :: Bool
+	, debugselector :: DebugSelector
+	, explainenabled :: Bool
+	, ciphers :: TMVar (M.Map StorableCipher Cipher)
+	, fast :: Bool
+	, force :: Bool
+	, forcenumcopies :: Maybe NumCopies
+	, forcemincopies :: Maybe MinCopies
+	, forcebackend :: Maybe String
+	, useragent :: Maybe String
+	, desktopnotify :: DesktopNotify
+	, gitcredentialcache :: TMVar CredentialCache
+	}
+
+newAnnexRead :: GitConfig -> IO AnnexRead
+newAnnexRead c = do
+	emptyactivekeys <- newTVarIO M.empty
+	emptyactiveremotes <- newMVar M.empty
+	kh <- Keys.newDbHandle
+	sc <- newTMVarIO False
+	si <- newTVarIO M.empty
+	tp <- newTransferrerPool
+	cm <- newTMVarIO M.empty
+	cc <- newTMVarIO (CredentialCache M.empty)
+	return $ AnnexRead
+		{ activekeys = emptyactivekeys
+		, activeremotes = emptyactiveremotes
+		, keysdbhandle = kh
+		, sshstalecleaned = sc
+		, signalactions = si
+		, transferrerpool = tp
+		, debugenabled = annexDebug c
+		, debugselector = debugSelectorFromGitConfig c
+		, explainenabled = False
+		, ciphers = cm
+		, fast = False
+		, force = False
+		, forcebackend = Nothing
+		, forcenumcopies = Nothing
+		, forcemincopies = Nothing
+		, useragent = Nothing
+		, desktopnotify = mempty
+		, gitcredentialcache = cc
+		}
+
+-- Values that can change while running an Annex action.
+data AnnexState = AnnexState
+	{ repo :: Git.Repo
+	, repoadjustment :: (Git.Repo -> IO Git.Repo)
+	, gitconfig :: GitConfig
+	, gitconfigadjustment :: (GitConfig -> GitConfig)
+	, gitconfigoverride :: [String]
+	, gitremotes :: Maybe [Git.Repo]
+	, gitconfiginodecache :: Maybe InodeCache
+	, backend :: Maybe (BackendA Annex)
+	, remotes :: [Types.Remote.RemoteA Annex]
+	, output :: MessageState
+	, concurrency :: ConcurrencySetting
+	, daemon :: Bool
+	, branchstate :: BranchState
+	, repoqueue :: Maybe (Git.Queue.Queue Annex)
+	, catfilehandles :: CatFileHandles
+	, hashobjecthandle :: Maybe (ResourcePool HashObjectHandle)
+	, checkattrhandle :: Maybe (ResourcePool CheckAttrHandle)
+	, checkignorehandle :: Maybe (ResourcePool CheckIgnoreHandle)
+	, globalnumcopies :: Maybe (Maybe NumCopies)
+	, globalmincopies :: Maybe (Maybe MinCopies)
+	, limit :: ExpandableMatcher Annex
+	, timelimit :: Maybe (Duration, POSIXTime)
+	, sizelimit :: Maybe (TVar Integer)
+	, uuiddescmap :: Maybe UUIDDescMap
+	, preferredcontentmap :: Maybe (FileMatcherMap Annex)
+	, requiredcontentmap :: Maybe (FileMatcherMap Annex)
+	, remoteconfigmap :: Maybe (M.Map UUID RemoteConfig)
+	, forcetrust :: TrustMap
+	, trustmap :: Maybe TrustMap
+	, groupmap :: Maybe GroupMap
+	, lockcache :: LockCache
+	, fields :: M.Map String String
+	, cleanupactions :: M.Map CleanupAction (Annex ())
+	, sentinalstatus :: Maybe SentinalStatus
+	, errcounter :: Integer
+	, reachedlimit :: Bool
+	, adjustedbranchrefreshcounter :: Integer
+	, unusedkeys :: Maybe (S.Set Key)
+	, tempurls :: M.Map Key URLString
+	, existinghooks :: M.Map Git.Hook.Hook Bool
+	, workers :: Maybe (TMVar (WorkerPool (AnnexState, AnnexRead)))
+	, cachedcurrentbranch :: (Maybe (Maybe Git.Branch, Maybe Adjustment))
+	, cachedgitenv :: Maybe (AltIndexFile, FilePath, [(String, String)])
+	, urloptions :: Maybe UrlOptions
+	, insmudgecleanfilter :: Bool
+	, getvectorclock :: IO CandidateVectorClock
+	}
+
+newAnnexState :: GitConfig -> Git.Repo -> IO AnnexState
+newAnnexState c r = do
+	o <- newMessageState
+	vc <- startVectorClock
+	return $ AnnexState
+		{ repo = r
+		, repoadjustment = return
+		, gitconfig = c
+		, gitconfigadjustment = id
+		, gitconfigoverride = []
+		, gitremotes = Nothing
+		, gitconfiginodecache = Nothing
+		, backend = Nothing
+		, remotes = []
+		, output = o
+		, concurrency = ConcurrencyCmdLine NonConcurrent
+		, daemon = False
+		, branchstate = startBranchState
+		, repoqueue = Nothing
+		, catfilehandles = catFileHandlesNonConcurrent
+		, hashobjecthandle = Nothing
+		, checkattrhandle = Nothing
+		, checkignorehandle = Nothing
+		, globalnumcopies = Nothing
+		, globalmincopies = Nothing
+		, limit = BuildingMatcher []
+		, timelimit = Nothing
+		, sizelimit = Nothing
+		, uuiddescmap = Nothing
+		, preferredcontentmap = Nothing
+		, requiredcontentmap = Nothing
+		, remoteconfigmap = Nothing
+		, forcetrust = M.empty
+		, trustmap = Nothing
+		, groupmap = Nothing
+		, lockcache = M.empty
+		, fields = M.empty
+		, cleanupactions = M.empty
+		, sentinalstatus = Nothing
+		, errcounter = 0
+		, reachedlimit = False
+		, adjustedbranchrefreshcounter = 0
+		, unusedkeys = Nothing
+		, tempurls = M.empty
+		, existinghooks = M.empty
+		, workers = Nothing
+		, cachedcurrentbranch = Nothing
+		, cachedgitenv = Nothing
+		, urloptions = Nothing
+		, insmudgecleanfilter = False
+		, getvectorclock = vc
+		}
+
+{- Makes an Annex state object for the specified git repo.
+ - Ensures the config is read, if it was not already, and performs
+ - any necessary git repo fixups. -}
+new :: Git.Repo -> IO (AnnexState, AnnexRead)
+new r = do
+	r' <- Git.Config.read r
+	let c = extractGitConfig FromGitConfig r'
+	st <- newAnnexState c =<< fixupRepo r' c
+	rd <- newAnnexRead c
+	return (st, rd)
+
+{- Performs an action in the Annex monad from a starting state,
+ - returning a new state. -}
+run :: (AnnexState, AnnexRead) -> Annex a -> IO (a, (AnnexState, AnnexRead))
+run (st, rd) a = do
+	mv <- newMVar st
+	run' mv rd a 
+
+run' :: MVar AnnexState -> AnnexRead -> Annex a -> IO (a, (AnnexState, AnnexRead))
+run' mvar rd a = do
+	r <- runReaderT (runAnnex a) (mvar, rd)
+	st <- takeMVar mvar
+	return (r, (st, rd))
+
+{- Performs an action in the Annex monad from a starting state, 
+ - and throws away the changed state. -}
+eval :: (AnnexState, AnnexRead) -> Annex a -> IO a
+eval v a = fst <$> run v a
+
+{- Makes a runner action, that allows diving into IO and from inside
+ - the IO action, running an Annex action. -}
+makeRunner :: Annex (Annex a -> IO a)
+makeRunner = do
+	(mvar, rd) <- ask
+	return $ \a -> do
+		(r, (s, _rd)) <- run' mvar rd a
+		putMVar mvar s
+		return r
+
+getRead :: (AnnexRead -> v) -> Annex v
+getRead selector = selector . snd <$> ask
+
+getState :: (AnnexState -> v) -> Annex v
+getState selector = do
+	mvar <- fst <$> ask
+	st <- liftIO $ readMVar mvar
+	return $ selector st
+
+changeState :: (AnnexState -> AnnexState) -> Annex ()
+changeState modifier = do
+	mvar <- fst <$> ask
+	liftIO $ modifyMVar_ mvar $ return . modifier
+
+withState :: (AnnexState -> IO (AnnexState, b)) -> Annex b
+withState modifier = do
+	mvar <- fst <$> ask
+	liftIO $ modifyMVar mvar modifier
+
+{- Sets a field to a value -}
+setField :: String -> String -> Annex ()
+setField field value = changeState $ \st ->
+	st { fields = M.insert field value $ fields st }
+
+{- Adds a cleanup action to perform. -}
+addCleanupAction :: CleanupAction -> Annex () -> Annex ()
+addCleanupAction k a = changeState $ \st ->
+	st { cleanupactions = M.insert k a $ cleanupactions st }
+
+{- Sets the type of output to emit. -}
+setOutput :: OutputType -> Annex ()
+setOutput o = changeState $ \st ->
+	let m = output st
+	in st { output = m { outputType = adjustOutputType (outputType m) o } }
+
+{- Gets the value of a field. -}
+getField :: String -> Annex (Maybe String)
+getField field = M.lookup field <$> getState fields
+
+{- Returns the annex's git repository. -}
+gitRepo :: Annex Git.Repo
+gitRepo = getState repo
+
+{- Runs an IO action in the annex's git repository. -}
+inRepo :: (Git.Repo -> IO a) -> Annex a
+inRepo a = liftIO . a =<< gitRepo
+
+{- Extracts a value from the annex's git repisitory. -}
+fromRepo :: (Git.Repo -> a) -> Annex a
+fromRepo a = a <$> gitRepo
+
+{- Calculates a value from an annex's git repository and its GitConfig. -}
+calcRepo :: (Git.Repo -> GitConfig -> IO a) -> Annex a
+calcRepo a = do
+	s <- getState id
+	liftIO $ a (repo s) (gitconfig s)
+
+calcRepo' :: (Git.Repo -> GitConfig -> a) -> Annex a
+calcRepo' f = do
+	s <- getState id
+	pure $ f (repo s) (gitconfig s)
+
+{- Gets the GitConfig settings. -}
+getGitConfig :: Annex GitConfig
+getGitConfig = getState gitconfig
+
+{- Overrides a GitConfig setting. The modification persists across
+ - reloads of the repo's config. -}
+overrideGitConfig :: (GitConfig -> GitConfig) -> Annex ()
+overrideGitConfig f = changeState $ \st -> st
+	{ gitconfigadjustment = gitconfigadjustment st . f
+	, gitconfig = f (gitconfig st)
+	}
+
+{- Adds an adjustment to the Repo data. Adjustments persist across reloads
+ - of the repo's config.
+ -
+ - Note that the action may run more than once, and should avoid eg,
+ - appending the same value to a repo's config when run repeatedly.
+ -}
+adjustGitRepo :: (Git.Repo -> IO Git.Repo) -> Annex ()
+adjustGitRepo a = do
+	changeState $ \st -> st { repoadjustment = \r -> repoadjustment st r >>= a }
+	changeGitRepo =<< gitRepo
+
+{- Adds git config setting, like "foo=bar". It will be passed with -c
+ - to git processes. The config setting is also recorded in the Repo,
+ - and the GitConfig is updated. -}
+addGitConfigOverride :: String -> Annex ()
+addGitConfigOverride v = do
+	adjustGitRepo $ \r ->
+		Git.Config.store (encodeBS v) Git.Config.ConfigList $
+			r { Git.gitGlobalOpts = go (Git.gitGlobalOpts r) }
+	changeState $ \st -> st { gitconfigoverride = v : gitconfigoverride st }
+  where
+	-- Remove any prior occurrence of the setting to avoid
+	-- building up many of them when the adjustment is run repeatedly,
+	-- and add the setting to the end.
+	go [] = [Param "-c", Param v]
+	go (Param "-c": Param v':rest) | v' == v = go rest
+	go (c:rest) = c : go rest
+
+{- Values that were passed to addGitConfigOverride. -}
+getGitConfigOverrides :: Annex [String]
+getGitConfigOverrides = reverse <$> getState gitconfigoverride
+
+{- Changing the git Repo data also involves re-extracting its GitConfig. -}
+changeGitRepo :: Git.Repo -> Annex ()
+changeGitRepo r = do
+	repoadjuster <- getState repoadjustment
+	gitconfigadjuster <- getState gitconfigadjustment
+	r' <- liftIO $ repoadjuster r
+	changeState $ \st -> st
+		{ repo = r'
+		, gitconfig = gitconfigadjuster $
+			extractGitConfig FromGitConfig r'
+		}
+
+{- Gets the RemoteGitConfig from a remote, given the Git.Repo for that
+ - remote. -}
+getRemoteGitConfig :: Git.Repo -> Annex RemoteGitConfig
+getRemoteGitConfig r = do
+	g <- gitRepo
+	liftIO $ atomically $ extractRemoteGitConfig g (Git.repoDescribe r)
+
+{- Converts an Annex action into an IO action, that runs with a copy
+ - of the current Annex state. 
+ -
+ - Use with caution; the action should not rely on changing the
+ - state, as it will be thrown away. -}
+withCurrentState :: Annex a -> Annex (IO a)
+withCurrentState a = do
+	(mvar, rd) <- ask
+	st <- liftIO $ readMVar mvar
+	return $ eval (st, rd) a
+
+{- It's not safe to use setCurrentDirectory in the Annex monad,
+ - because the git repo paths are stored relative.
+ - Instead, use this.
+ -}
+changeDirectory :: FilePath -> Annex ()
+changeDirectory d = do
+	r <- liftIO . Git.adjustPath absPath =<< gitRepo
+	liftIO $ setCurrentDirectory d
+	r' <- liftIO $ Git.relPath r
+	changeState $ \st -> st { repo = r' }
+
+incError :: Annex ()
+incError = changeState $ \st -> 
+	let !c = errcounter st + 1 
+	    !st' = st { errcounter = c }
+	in st'
+
+getGitRemotes :: Annex [Git.Repo]
+getGitRemotes = do
+	st <- getState id
+	case gitremotes st of
+		Just rs -> return rs
+		Nothing -> do
+			rs <- liftIO $ Git.Construct.fromRemotes (repo st)
+			changeState $ \st' -> st' { gitremotes = Just rs }
+			return rs
diff --git a/Annex/Action.hs b/Annex/Action.hs
new file mode 100644
index 0000000000..9eaf169851
--- /dev/null
+++ b/Annex/Action.hs
@@ -0,0 +1,105 @@
+{- git-annex actions
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Annex.Action (
+	action,
+	verifiedAction,
+	startup,
+	quiesce,
+	stopCoProcesses,
+) where
+
+import qualified Data.Map as M
+
+import Annex.Common
+import qualified Annex
+import Annex.Content
+import Annex.CatFile
+import Annex.CheckAttr
+import Annex.HashObject
+import Annex.CheckIgnore
+import Annex.TransferrerPool
+import qualified Database.Keys
+
+#ifndef mingw32_HOST_OS
+import Control.Concurrent.STM
+import System.Posix.Signals
+#endif
+
+{- Runs an action that may throw exceptions, catching and displaying them. -}
+action :: Annex () -> Annex Bool
+action a = tryNonAsync a >>= \case
+	Right () -> return True
+	Left e -> do
+		warning (UnquotedString (show e))
+		return False
+
+verifiedAction :: Annex Verification -> Annex (Bool, Verification)
+verifiedAction a = tryNonAsync a >>= \case
+	Right v -> return (True, v)
+	Left e -> do
+		warning (UnquotedString (show e))
+		return (False, UnVerified)
+
+
+{- Actions to perform each time ran. -}
+startup :: Annex ()
+startup = do
+#ifndef mingw32_HOST_OS
+	av <- Annex.getRead Annex.signalactions
+	let propagate sig = liftIO $ installhandleronce sig av
+	propagate sigINT
+	propagate sigQUIT
+	propagate sigTERM
+	propagate sigTSTP
+	propagate sigCONT
+	propagate sigHUP
+	-- sigWINCH is not propagated; it should not be needed,
+	-- and the concurrent-output library installs its own signal
+	-- handler for it.
+	-- sigSTOP and sigKILL cannot be caught, so will not be propagated.
+  where
+	installhandleronce sig av = void $
+		installHandler sig (CatchOnce (gotsignal sig av)) Nothing
+	gotsignal sig av = do
+		mapM_ (\a -> a (fromIntegral sig)) =<< atomically (readTVar av)
+		raiseSignal sig
+		installhandleronce sig av
+#else
+       return ()
+#endif
+
+{- Rn all cleanup actions, save all state, stop all long-running child
+ - processes.
+ -
+ - This can be run repeatedly with other Annex actions run in between,
+ - but usually it is run only once at the end.
+ -
+ - When passed True, avoids making any commits to the git-annex branch,
+ - leaving changes in the journal for later commit.
+ -}
+quiesce :: Bool -> Annex ()
+quiesce nocommit = do
+	cas <- Annex.withState $ \st -> return 
+		( st { Annex.cleanupactions = mempty }
+		, Annex.cleanupactions st
+		)
+	sequence_ (M.elems cas)
+	saveState nocommit
+	stopCoProcesses
+	Database.Keys.closeDb
+
+{- Stops all long-running child processes, including git query processes. -}
+stopCoProcesses :: Annex ()
+stopCoProcesses = do
+	catFileStop
+	checkAttrStop
+	hashObjectStop
+	checkIgnoreStop
+	emptyTransferrerPool
diff --git a/Annex/AdjustedBranch.hs b/Annex/AdjustedBranch.hs
new file mode 100644
index 0000000000..94fdeea2ea
--- /dev/null
+++ b/Annex/AdjustedBranch.hs
@@ -0,0 +1,680 @@
+{- adjusted branch
+ -
+ - Copyright 2016-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns, OverloadedStrings #-}
+
+module Annex.AdjustedBranch (
+	Adjustment(..),
+	LinkAdjustment(..),
+	PresenceAdjustment(..),
+	LinkPresentAdjustment(..),
+	adjustmentHidesFiles,
+	adjustmentIsStable,
+	OrigBranch,
+	AdjBranch(..),
+	originalToAdjusted,
+	adjustedToOriginal,
+	fromAdjustedBranch,
+	getAdjustment,
+	enterAdjustedBranch,
+	adjustedBranchRefresh,
+	adjustedBranchRefreshFull,
+	adjustBranch,
+	adjustTree,
+	adjustToCrippledFileSystem,
+	commitForAdjustedBranch,
+	propigateAdjustedCommits,
+	propigateAdjustedCommits',
+	commitAdjustedTree,
+	commitAdjustedTree',
+	BasisBranch(..),
+	basisBranch,
+	setBasisBranch,
+	preventCommits,
+	AdjustedClone(..),
+	checkAdjustedClone,
+	checkVersionSupported,
+	isGitVersionSupported,
+) where
+
+import Annex.Common
+import Types.AdjustedBranch
+import Annex.AdjustedBranch.Name
+import qualified Annex
+import Git
+import Git.Types
+import qualified Git.Branch
+import qualified Git.Ref
+import qualified Git.Command
+import qualified Git.Tree
+import qualified Git.DiffTree
+import Git.Tree (TreeItem(..))
+import Git.Sha
+import Git.Env
+import Git.Index
+import Git.FilePath
+import qualified Git.LockFile
+import qualified Git.Version
+import Annex.CatFile
+import Annex.Link
+import Annex.Content.Presence
+import Annex.CurrentBranch
+import Types.CleanupActions
+import qualified Database.Keys
+import Config
+import Logs.View (is_branchView)
+import Logs.AdjustedBranchUpdate
+
+import Data.Time.Clock.POSIX
+import qualified Data.Map as M
+
+class AdjustTreeItem t where
+	-- How to perform various adjustments to a TreeItem.
+	adjustTreeItem :: t -> TreeItem -> Annex (Maybe TreeItem)
+	-- Will adjusting a given tree always yield the same adjusted tree?
+	adjustmentIsStable :: t -> Bool
+
+instance AdjustTreeItem Adjustment where
+	adjustTreeItem (LinkAdjustment l) t = adjustTreeItem l t
+	adjustTreeItem (PresenceAdjustment p Nothing) t = adjustTreeItem p t
+	adjustTreeItem (PresenceAdjustment p (Just l)) t =
+		adjustTreeItem p t >>= \case
+			Nothing -> return Nothing
+			Just t' -> adjustTreeItem l t'
+	adjustTreeItem (LinkPresentAdjustment l) t = adjustTreeItem l t
+
+	adjustmentIsStable (LinkAdjustment l) = adjustmentIsStable l
+	adjustmentIsStable (PresenceAdjustment p _) = adjustmentIsStable p
+	adjustmentIsStable (LinkPresentAdjustment l) = adjustmentIsStable l
+
+instance AdjustTreeItem LinkAdjustment where
+	adjustTreeItem UnlockAdjustment =
+		ifSymlink adjustToPointer noAdjust
+	adjustTreeItem LockAdjustment =
+		ifSymlink noAdjust adjustToSymlink
+	adjustTreeItem FixAdjustment =
+		ifSymlink adjustToSymlink noAdjust
+	adjustTreeItem UnFixAdjustment =
+		ifSymlink (adjustToSymlink' gitAnnexLinkCanonical) noAdjust
+	
+	adjustmentIsStable _ = True
+
+instance AdjustTreeItem PresenceAdjustment where
+	adjustTreeItem HideMissingAdjustment = 
+		ifPresent noAdjust hideAdjust
+	adjustTreeItem ShowMissingAdjustment =
+		noAdjust
+
+	adjustmentIsStable HideMissingAdjustment = False
+	adjustmentIsStable ShowMissingAdjustment = True
+
+instance AdjustTreeItem LinkPresentAdjustment where
+	adjustTreeItem UnlockPresentAdjustment = 
+		ifPresent adjustToPointer adjustToSymlink
+	adjustTreeItem LockPresentAdjustment =
+		-- Turn all pointers back to symlinks, whether the content
+		-- is present or not. This is done because the content
+		-- availability may have changed and the branch not been
+		-- re-adjusted to keep up, so there may be pointers whose
+		-- content is not present.
+		ifSymlink noAdjust adjustToSymlink
+
+	adjustmentIsStable UnlockPresentAdjustment = False
+	adjustmentIsStable LockPresentAdjustment = True
+
+ifSymlink
+	:: (TreeItem -> Annex a)
+	-> (TreeItem -> Annex a)
+	-> TreeItem
+	-> Annex a
+ifSymlink issymlink notsymlink ti@(TreeItem _f m _s)
+	| toTreeItemType m == Just TreeSymlink = issymlink ti
+	| otherwise = notsymlink ti
+
+ifPresent
+	:: (TreeItem -> Annex (Maybe TreeItem))
+	-> (TreeItem -> Annex (Maybe TreeItem))
+	-> TreeItem
+	-> Annex (Maybe TreeItem)
+ifPresent ispresent notpresent ti@(TreeItem _ _ s) =
+	catKey s >>= \case
+		Just k -> ifM (inAnnex k) (ispresent ti, notpresent ti)
+		Nothing -> return (Just ti)
+
+noAdjust :: TreeItem -> Annex (Maybe TreeItem)
+noAdjust = return . Just
+
+hideAdjust :: TreeItem -> Annex (Maybe TreeItem)
+hideAdjust _ = return Nothing
+
+adjustToPointer :: TreeItem -> Annex (Maybe TreeItem)
+adjustToPointer ti@(TreeItem f _m s) = catKey s >>= \case
+	Just k -> do
+		Database.Keys.addAssociatedFile k f
+		Just . TreeItem f (fromTreeItemType TreeFile)
+			<$> hashPointerFile k
+	Nothing -> return (Just ti)
+
+adjustToSymlink :: TreeItem -> Annex (Maybe TreeItem)
+adjustToSymlink = adjustToSymlink' gitAnnexLink
+
+adjustToSymlink' :: (RawFilePath -> Key -> Git.Repo -> GitConfig -> IO RawFilePath) -> TreeItem -> Annex (Maybe TreeItem)
+adjustToSymlink' gitannexlink ti@(TreeItem f _m s) = catKey s >>= \case
+	Just k -> do
+		absf <- inRepo $ \r -> absPath $ fromTopFilePath f r
+		linktarget <- calcRepo $ gitannexlink absf k
+		Just . TreeItem f (fromTreeItemType TreeSymlink)
+			<$> hashSymlink linktarget
+	Nothing -> return (Just ti)
+
+-- This is a hidden branch ref, that's used as the basis for the AdjBranch,
+-- since pushes can overwrite the OrigBranch at any time. So, changes
+-- are propigated from the AdjBranch to the head of the BasisBranch.
+newtype BasisBranch = BasisBranch Ref
+
+-- The basis for refs/heads/adjusted/master(unlocked) is
+-- refs/basis/adjusted/master(unlocked).
+basisBranch :: AdjBranch -> BasisBranch
+basisBranch (AdjBranch adjbranch) = BasisBranch $
+	Ref ("refs/basis/" <> fromRef' (Git.Ref.base adjbranch))
+
+getAdjustment :: Branch -> Maybe Adjustment
+getAdjustment = fmap fst . adjustedToOriginal
+
+fromAdjustedBranch :: Branch -> OrigBranch
+fromAdjustedBranch b = maybe b snd (adjustedToOriginal b)
+
+{- Enter an adjusted version of current branch (or, if already in an
+ - adjusted version of a branch, changes the adjustment of the original
+ - branch).
+ -
+ - Can fail, if no branch is checked out, or if the adjusted branch already
+ - exists, or if staged changes prevent a checkout.
+ -}
+enterAdjustedBranch :: Adjustment -> Annex Bool
+enterAdjustedBranch adj = inRepo Git.Branch.current >>= \case
+	Just currbranch -> case getAdjustment currbranch of
+		Just curradj | curradj == adj ->
+			updateAdjustedBranch adj (AdjBranch currbranch)
+				(fromAdjustedBranch currbranch)
+		_ -> go currbranch
+	Nothing -> do
+		warning "not on any branch!"
+		return False
+  where
+	go currbranch = do
+		let origbranch = fromAdjustedBranch currbranch
+		let adjbranch = adjBranch $ originalToAdjusted origbranch adj
+		ifM (inRepo (Git.Ref.exists adjbranch) <&&> (not <$> Annex.getRead Annex.force) <&&> pure (not (is_branchView origbranch)))
+			( do
+				mapM_ (warning . UnquotedString . unwords)
+					[ [ "adjusted branch"
+					  , Git.Ref.describe adjbranch
+					  , "already exists."
+					  ]
+					, [ "Aborting because that branch may have changes that have not yet reached"
+					  , Git.Ref.describe origbranch
+					  ]
+					, [ "You can check out the adjusted branch manually to enter it,"
+					  , "or add the --force option to overwrite the old branch."
+					  ]
+					]
+				return False
+			, do
+				starttime <- liftIO getPOSIXTime
+				b <- preventCommits $ const $ 
+					adjustBranch adj origbranch
+				ok <- checkoutAdjustedBranch b False
+				when ok $
+					recordAdjustedBranchUpdateFinished starttime
+				return ok
+			)
+
+checkoutAdjustedBranch :: AdjBranch -> Bool -> Annex Bool
+checkoutAdjustedBranch (AdjBranch b) quietcheckout = do
+	-- checkout can have output in large repos
+	unless quietcheckout
+		showOutput
+	inRepo $ Git.Command.runBool $
+		[ Param "checkout"
+		, Param $ fromRef $ Git.Ref.base b
+		, if quietcheckout then Param "--quiet" else Param "--progress"
+		]
+
+{- Already in a branch with this adjustment, but the user asked to enter it
+ - again. This should have the same result as propagating any commits
+ - back to the original branch, checking out the original branch, deleting
+ - and rebuilding the adjusted branch, and then checking it out.
+ - But, it can be implemented more efficiently than that.
+ -}
+updateAdjustedBranch :: Adjustment -> AdjBranch -> OrigBranch -> Annex Bool
+updateAdjustedBranch adj (AdjBranch currbranch) origbranch
+	| not (adjustmentIsStable adj) = do
+		(b, origheadfile, newheadfile) <- preventCommits $ \commitlck -> do
+			-- Avoid losing any commits that the adjusted branch
+			-- has that have not yet been propigated back to the
+			-- origbranch.
+			_ <- propigateAdjustedCommits' True origbranch adj commitlck
+			
+			origheadfile <- inRepo $ readFileStrict . Git.Ref.headFile
+			origheadsha <- inRepo (Git.Ref.sha currbranch)
+			
+			b <- adjustBranch adj origbranch
+
+			-- Git normally won't do anything when asked to check
+			-- out the currently checked out branch, even when its
+			-- ref has changed. Work around this by writing a raw
+			-- sha to .git/HEAD.
+			newheadfile <- case origheadsha of
+				Just s -> do
+					inRepo $ \r -> do
+						let newheadfile = fromRef s
+						writeFile (Git.Ref.headFile r) newheadfile
+						return (Just newheadfile)
+				_ -> return Nothing
+	
+			return (b, origheadfile, newheadfile)
+	
+		-- Make git checkout quiet to avoid warnings about
+		-- disconnected branch tips being lost.
+		ok <- checkoutAdjustedBranch b True
+
+		-- Avoid leaving repo with detached head.
+		unless ok $ case newheadfile of
+			Nothing -> noop
+			Just v -> preventCommits $ \_commitlck -> inRepo $ \r -> do
+				v' <- readFileStrict (Git.Ref.headFile r)
+				when (v == v') $
+					writeFile (Git.Ref.headFile r) origheadfile
+
+		return ok
+	| otherwise = preventCommits $ \commitlck -> do
+		-- Done for consistency.
+		_ <- propigateAdjustedCommits' True origbranch adj commitlck
+		-- No need to actually update the branch because the
+		-- adjustment is stable.
+		return True
+
+{- Passed an action that, if it succeeds may get or drop the Key associated
+ - with the file. When the adjusted branch needs to be refreshed to reflect
+ - those changes, it's handled here.
+ -
+ - Note that the AssociatedFile must be verified by this to point to the
+ - Key. In some cases, the value was provided by the user and might not
+ - really be an associated file.
+ -}
+adjustedBranchRefresh :: AssociatedFile -> Annex a -> Annex a
+adjustedBranchRefresh _af a = do
+	r <- a
+	go
+	return r
+  where
+	go = getCurrentBranch >>= \case
+		(Just origbranch, Just adj) ->
+			unless (adjustmentIsStable adj) $ do
+				recordAdjustedBranchUpdateNeeded
+				n <- annexAdjustedBranchRefresh <$> Annex.getGitConfig
+				unless (n == 0) $ ifM (checkcounter n)
+					-- This is slow, it would be better to incrementally
+					-- adjust the AssociatedFile, and only call this once
+					-- at shutdown to handle cases where not all
+					-- AssociatedFiles are known.
+					( adjustedBranchRefreshFull' adj origbranch
+					, Annex.addCleanupAction AdjustedBranchUpdate $
+						adjustedBranchRefreshFull' adj origbranch
+					)
+		_ -> return ()
+	
+	checkcounter n
+		-- Special case, 1 (or true) refreshes only at shutdown.
+		| n == 1 = pure False
+		| otherwise = Annex.withState $ \s -> 
+			let !c = Annex.adjustedbranchrefreshcounter s + 1
+			    !enough = c >= pred n
+			    !c' = if enough then 0 else c
+			    !s' = s { Annex.adjustedbranchrefreshcounter = c' }
+			    in pure (s', enough)
+
+{- Slow, but more dependable version of adjustedBranchRefresh that
+ - does not rely on all AssociatedFiles being known. -}
+adjustedBranchRefreshFull :: Adjustment -> OrigBranch -> Annex ()
+adjustedBranchRefreshFull adj origbranch =
+	whenM isAdjustedBranchUpdateNeeded $ do
+		adjustedBranchRefreshFull' adj origbranch
+
+adjustedBranchRefreshFull' :: Adjustment -> OrigBranch -> Annex ()
+adjustedBranchRefreshFull' adj origbranch = do
+	-- Restage pointer files so modifications to them due to get/drop
+	-- do not prevent checking out the updated adjusted branch.
+	restagePointerFiles =<< Annex.gitRepo
+	starttime <- liftIO getPOSIXTime
+	let adjbranch = originalToAdjusted origbranch adj
+	ifM (updateAdjustedBranch adj adjbranch origbranch)
+		( recordAdjustedBranchUpdateFinished starttime
+		, warning "Updating adjusted branch failed."
+		)
+
+adjustToCrippledFileSystem :: Annex ()
+adjustToCrippledFileSystem = do
+	warning "Entering an adjusted branch where files are unlocked as this filesystem does not support locked files."
+	checkVersionSupported
+	whenM (isNothing <$> inRepo Git.Branch.current) $
+		commitForAdjustedBranch []
+	inRepo Git.Branch.current >>= \case
+		Just currbranch -> case getAdjustment currbranch of
+			Just curradj | curradj == adj -> return ()
+			_ -> do
+				let adjbranch = originalToAdjusted currbranch adj
+				ifM (inRepo (Git.Ref.exists $ adjBranch adjbranch))
+					( unlessM (checkoutAdjustedBranch adjbranch False) $
+						failedenter
+					, unlessM (enterAdjustedBranch adj) $
+						failedenter
+					)
+		Nothing -> failedenter
+  where
+	adj = LinkAdjustment UnlockAdjustment
+	failedenter = warning "Failed to enter adjusted branch!"
+
+{- Commit before entering adjusted branch. Only needs to be done
+ - when the current branch does not have any commits yet.
+ -
+ - If something is already staged, it will be committed, but otherwise
+ - an empty commit will be made.
+ -}
+commitForAdjustedBranch :: [CommandParam] -> Annex ()
+commitForAdjustedBranch ps = do
+	cmode <- annexCommitMode <$> Annex.getGitConfig
+	let cquiet = Git.Branch.CommitQuiet True
+	void $ inRepo $ Git.Branch.commitCommand cmode cquiet $
+		[ Param "--allow-empty"
+		, Param "-m"
+		, Param "commit before entering adjusted branch"
+		] ++ ps
+
+setBasisBranch :: BasisBranch -> Ref -> Annex ()
+setBasisBranch (BasisBranch basis) new = 
+	inRepo $ Git.Branch.update' basis new
+
+setAdjustedBranch :: String -> AdjBranch -> Ref -> Annex ()
+setAdjustedBranch msg (AdjBranch b) r = inRepo $ Git.Branch.update msg b r
+
+adjustBranch :: Adjustment -> OrigBranch -> Annex AdjBranch
+adjustBranch adj origbranch = do
+	-- Start basis off with the current value of the origbranch.
+	setBasisBranch basis origbranch
+	sha <- adjustCommit adj basis
+	setAdjustedBranch "entering adjusted branch" adjbranch sha
+	return adjbranch
+  where
+	adjbranch = originalToAdjusted origbranch adj
+	basis = basisBranch adjbranch
+
+adjustCommit :: Adjustment -> BasisBranch -> Annex Sha
+adjustCommit adj basis = do
+	treesha <- adjustTree adj basis
+	commitAdjustedTree treesha basis
+
+adjustTree :: Adjustment -> BasisBranch -> Annex Sha
+adjustTree adj (BasisBranch basis) = do
+	let toadj = adjustTreeItem adj
+	treesha <- Git.Tree.adjustTree
+		toadj 
+		[] 
+		(\_old new -> new)
+		[]
+		basis =<< Annex.gitRepo
+	return treesha
+
+type CommitsPrevented = Git.LockFile.LockHandle
+
+{- Locks git's index file, preventing git from making a commit, merge, 
+ - or otherwise changing the HEAD ref while the action is run.
+ -
+ - Throws an IO exception if the index file is already locked.
+ -}
+preventCommits :: (CommitsPrevented -> Annex a) -> Annex a
+preventCommits = bracket setup cleanup
+  where
+	setup = do
+		lck <- fromRepo $ indexFileLock . indexFile
+		liftIO $ Git.LockFile.openLock (fromRawFilePath lck)
+	cleanup = liftIO . Git.LockFile.closeLock
+
+{- Commits a given adjusted tree, with the provided parent ref.
+ -
+ - This should always yield the same value, even if performed in different 
+ - clones of a repo, at different times. The commit message and other
+ - metadata is based on the parent.
+ -}
+commitAdjustedTree :: Sha -> BasisBranch -> Annex Sha
+commitAdjustedTree treesha parent@(BasisBranch b) =
+	commitAdjustedTree' treesha parent [b]
+
+commitAdjustedTree' :: Sha -> BasisBranch -> [Ref] -> Annex Sha
+commitAdjustedTree' treesha (BasisBranch basis) parents =
+	go =<< catCommit basis
+  where
+	go Nothing = do
+		cmode <- annexCommitMode <$> Annex.getGitConfig
+		inRepo $ mkcommit cmode
+	go (Just basiscommit) = do
+		cmode <- annexCommitMode <$> Annex.getGitConfig
+		inRepo $ commitWithMetaData
+			(commitAuthorMetaData basiscommit)
+			(commitCommitterMetaData basiscommit)
+			(mkcommit cmode)
+	-- Make sure that the exact message is used in the commit,
+	-- since that message is looked for later.
+	-- After git-annex 10.20240227, it's possible to use
+	-- commitTree instead of this, but this is being kept
+	-- for some time, for compatability with older versions.
+	mkcommit cmode = Git.Branch.commitTreeExactMessage cmode
+		adjustedBranchCommitMessage parents treesha
+
+{- This message should never be changed. -}
+adjustedBranchCommitMessage :: String
+adjustedBranchCommitMessage = "git-annex adjusted branch"
+
+{- Allow for a trailing newline after the message. -}
+hasAdjustedBranchCommitMessage :: Commit -> Bool
+hasAdjustedBranchCommitMessage c = 
+	dropWhileEnd (\x -> x == '\n' || x == '\r') (commitMessage c) 
+		== adjustedBranchCommitMessage
+
+findAdjustingCommit :: AdjBranch -> Annex (Maybe Commit)
+findAdjustingCommit (AdjBranch b) = go =<< catCommit b
+  where
+	go Nothing = return Nothing
+	go (Just c)
+		| hasAdjustedBranchCommitMessage c = return (Just c)
+		| otherwise = case commitParent c of
+			[p] -> go =<< catCommit p
+			_ -> return Nothing
+
+{- Check for any commits present on the adjusted branch that have not yet
+ - been propigated to the basis branch, and propagate them to the basis
+ - branch and from there on to the orig branch.
+ -
+ - After propigating the commits back to the basis branch,
+ - rebase the adjusted branch on top of the updated basis branch.
+ -}
+propigateAdjustedCommits :: OrigBranch -> Adjustment -> Annex ()
+propigateAdjustedCommits origbranch adj = 
+	preventCommits $ \commitsprevented ->
+		join $ snd <$> propigateAdjustedCommits' True origbranch adj commitsprevented
+		
+{- Returns sha of updated basis branch, and action which will rebase
+ - the adjusted branch on top of the updated basis branch. -}
+propigateAdjustedCommits'
+	:: Bool
+	-> OrigBranch
+	-> Adjustment
+	-> CommitsPrevented
+	-> Annex (Maybe Sha, Annex ())
+propigateAdjustedCommits' warnwhendiverged origbranch adj _commitsprevented =
+	inRepo (Git.Ref.sha basis) >>= \case
+		Just origsha -> catCommit currbranch >>= \case
+			Just currcommit ->
+				newcommits >>= go origsha origsha False >>= \case
+					Left e -> do
+						warning (UnquotedString e)
+						return (Nothing, return ())
+					Right newparent -> return
+						( Just newparent
+						, rebase currcommit newparent
+						)
+			Nothing -> return (Nothing, return ())
+		Nothing -> do
+			warning $ UnquotedString $ 
+				"Cannot find basis ref " ++ fromRef basis ++ "; not propagating adjusted commits to original branch " ++ fromRef origbranch
+			return (Nothing, return ())
+  where
+	(BasisBranch basis) = basisBranch adjbranch
+	adjbranch@(AdjBranch currbranch) = originalToAdjusted origbranch adj
+	newcommits = inRepo $ Git.Branch.changedCommits basis currbranch
+		-- Get commits oldest first, so they can be processed
+		-- in order made.
+		[Param "--reverse"]
+	go origsha parent _ [] = do
+		setBasisBranch (BasisBranch basis) parent
+		inRepo (Git.Ref.sha origbranch) >>= \case
+			Just origbranchsha | origbranchsha /= origsha ->
+				when warnwhendiverged $
+					warning $ UnquotedString $ 
+						"Original branch " ++ fromRef origbranch ++ " has diverged from current adjusted branch " ++ fromRef currbranch
+			_ -> inRepo $ Git.Branch.update' origbranch parent
+		return (Right parent)
+	go origsha parent pastadjcommit (sha:l) = catCommit sha >>= \case
+		Just c
+			| hasAdjustedBranchCommitMessage c ->
+				go origsha parent True l
+			| pastadjcommit ->
+				reverseAdjustedCommit parent adj (sha, c) origbranch
+					>>= \case
+						Left e -> return (Left e)
+						Right commit -> go origsha commit pastadjcommit l
+		_ -> go origsha parent pastadjcommit l
+	rebase currcommit newparent = do
+		-- Reuse the current adjusted tree, and reparent it
+		-- on top of the newparent.
+		commitAdjustedTree (commitTree currcommit) (BasisBranch newparent)
+			>>= inRepo . Git.Branch.update rebaseOnTopMsg currbranch
+
+rebaseOnTopMsg :: String
+rebaseOnTopMsg = "rebasing adjusted branch on top of updated original branch"
+
+{- Reverses an adjusted commit, and commit with provided commitparent,
+ - yielding a commit sha.
+ -
+ - Adjusts the tree of the commitparent, changing only the files that the
+ - commit changed, and reverse adjusting those changes.
+ -
+ - The commit message, and the author and committer metadata are
+ - copied over from the basiscommit. However, any gpg signature
+ - will be lost, and any other headers are not copied either. -}
+reverseAdjustedCommit :: Sha -> Adjustment -> (Sha, Commit) -> OrigBranch -> Annex (Either String Sha)
+reverseAdjustedCommit commitparent adj (csha, basiscommit) origbranch
+	| length (commitParent basiscommit) > 1 = return $
+		Left $ "unable to propagate merge commit " ++ show csha ++ " back to " ++ show origbranch
+	| otherwise = do
+		cmode <- annexCommitMode <$> Annex.getGitConfig
+		treesha <- reverseAdjustedTree commitparent adj csha
+		revadjcommit <- inRepo $ commitWithMetaData
+			(commitAuthorMetaData basiscommit)
+			(commitCommitterMetaData basiscommit) $
+				Git.Branch.commitTree cmode
+					[commitMessage basiscommit]
+					[commitparent] treesha
+		return (Right revadjcommit)
+
+{- Adjusts the tree of the basis, changing only the files that the
+ - commit changed, and reverse adjusting those changes.
+ -
+ - commitDiff does not support merge commits, so the csha must not be a
+ - merge commit. -}
+reverseAdjustedTree :: Sha -> Adjustment -> Sha -> Annex Sha
+reverseAdjustedTree basis adj csha = do
+	(diff, cleanup) <- inRepo (Git.DiffTree.commitDiff csha)
+	let (adds, others) = partition (\dti -> Git.DiffTree.srcsha dti `elem` nullShas) diff
+	let (removes, changes) = partition (\dti -> Git.DiffTree.dstsha dti `elem` nullShas) others
+	adds' <- catMaybes <$>
+		mapM (adjustTreeItem reverseadj) (map diffTreeToTreeItem adds)
+	treesha <- Git.Tree.adjustTree
+		(propchanges changes)
+		adds'
+		(\_old new -> new)
+		(map Git.DiffTree.file removes)
+		basis
+		=<< Annex.gitRepo
+	void $ liftIO cleanup
+	return treesha
+  where
+	reverseadj = reverseAdjustment adj
+	propchanges changes ti@(TreeItem f _ _) =
+		case M.lookup (norm f) m of
+			Nothing -> return (Just ti) -- not changed
+			Just change -> adjustTreeItem reverseadj change
+	  where
+		m = M.fromList $ map (\i@(TreeItem f' _ _) -> (norm f', i)) $
+			map diffTreeToTreeItem changes
+		norm = normalise . fromRawFilePath . getTopFilePath
+
+diffTreeToTreeItem :: Git.DiffTree.DiffTreeItem -> TreeItem
+diffTreeToTreeItem dti = TreeItem
+	(Git.DiffTree.file dti)
+	(Git.DiffTree.dstmode dti)
+	(Git.DiffTree.dstsha dti)
+
+data AdjustedClone = InAdjustedClone | NotInAdjustedClone
+
+{- Cloning a repository that has an adjusted branch checked out will
+ - result in the clone having the same adjusted branch checked out -- but
+ - the origbranch won't exist in the clone, nor will the basis. So
+ - to properly set up the adjusted branch, the origbranch and basis need
+ - to be set.
+ - 
+ - We can't trust that the origin's origbranch matches up with the currently
+ - checked out adjusted branch; the origin could have the two branches
+ - out of sync (eg, due to another branch having been pushed to the origin's
+ - origbranch), or due to a commit on its adjusted branch not having been
+ - propigated back to origbranch.
+ -
+ - So, find the adjusting commit on the currently checked out adjusted
+ - branch, and use the parent of that commit as the basis, and set the
+ - origbranch to it.
+ -}
+checkAdjustedClone :: Annex AdjustedClone
+checkAdjustedClone = ifM isBareRepo
+	( return NotInAdjustedClone
+	, go =<< inRepo Git.Branch.current
+	)
+  where
+	go Nothing = return NotInAdjustedClone
+	go (Just currbranch) = case adjustedToOriginal currbranch of
+		Nothing -> return NotInAdjustedClone
+		Just (adj, origbranch) -> do
+			let basis@(BasisBranch bb) = basisBranch (originalToAdjusted origbranch adj)
+			unlessM (inRepo $ Git.Ref.exists bb) $ do
+				aps <- fmap commitParent <$> findAdjustingCommit (AdjBranch currbranch)
+				case aps of
+					Just [p] -> do
+						unlessM (inRepo $ Git.Ref.exists origbranch) $
+							inRepo $ Git.Branch.update' origbranch p
+						setBasisBranch basis p
+					_ -> giveup $ "Unable to clean up from clone of adjusted branch; perhaps you should check out " ++ Git.Ref.describe origbranch
+			return InAdjustedClone
+
+checkVersionSupported :: Annex ()
+checkVersionSupported =
+	unlessM (liftIO isGitVersionSupported) $
+		giveup "Your version of git is too old; upgrade it to 2.2.0 or newer to use adjusted branches."
+
+-- git 2.2.0 needed for GIT_COMMON_DIR which is needed
+-- by updateAdjustedBranch to use withWorkTreeRelated.
+isGitVersionSupported :: IO Bool
+isGitVersionSupported = not <$> Git.Version.older "2.2.0"
diff --git a/Annex/AdjustedBranch/Merge.hs b/Annex/AdjustedBranch/Merge.hs
new file mode 100644
index 0000000000..904f4ee412
--- /dev/null
+++ b/Annex/AdjustedBranch/Merge.hs
@@ -0,0 +1,167 @@
+{- adjusted branch merging
+ -
+ - Copyright 2016-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns, OverloadedStrings #-}
+
+module Annex.AdjustedBranch.Merge (
+	canMergeToAdjustedBranch,
+	mergeToAdjustedBranch,
+) where
+
+import Annex.Common
+import Annex.AdjustedBranch
+import qualified Annex
+import Git
+import Git.Types
+import qualified Git.Branch
+import qualified Git.Ref
+import qualified Git.Command
+import qualified Git.Merge
+import Git.Sha
+import Annex.CatFile
+import Annex.AutoMerge
+import Annex.Tmp
+import Annex.GitOverlay
+import Utility.Tmp.Dir
+import Utility.CopyFile
+import Utility.Directory.Create
+
+import qualified Data.ByteString as S
+import qualified System.FilePath.ByteString as P
+
+canMergeToAdjustedBranch :: Branch -> (OrigBranch, Adjustment) -> Annex Bool
+canMergeToAdjustedBranch tomerge (origbranch, adj) =
+	inRepo $ Git.Branch.changed currbranch tomerge
+  where
+	AdjBranch currbranch = originalToAdjusted origbranch adj
+
+{- Update the currently checked out adjusted branch, merging the provided
+ - branch into it. Note that the provided branch should be a non-adjusted
+ - branch. -}
+mergeToAdjustedBranch :: Branch -> (OrigBranch, Adjustment) -> [Git.Merge.MergeConfig] -> Bool -> Git.Branch.CommitMode -> Annex Bool
+mergeToAdjustedBranch tomerge (origbranch, adj) mergeconfig canresolvemerge commitmode = catchBoolIO $
+	join $ preventCommits go
+  where
+	adjbranch@(AdjBranch currbranch) = originalToAdjusted origbranch adj
+	basis = basisBranch adjbranch
+
+	go commitsprevented = do
+		(updatedorig, _) <- propigateAdjustedCommits'
+			False origbranch adj commitsprevented
+		changestomerge updatedorig
+
+	{- Since the adjusted branch changes files, merging tomerge
+	 - directly into it would likely result in unnecessary merge
+	 - conflicts. To avoid those conflicts, instead merge tomerge into
+	 - updatedorig. The result of the merge can the be
+	 - adjusted to yield the final adjusted branch.
+	 -
+	 - In order to do a merge into a ref that is not checked out,
+	 - set the work tree to a temp directory, and set GIT_DIR
+	 - to another temp directory, in which HEAD contains the
+	 - updatedorig sha. GIT_COMMON_DIR is set to point to the real
+	 - git directory, and so git can read and write objects from there,
+	 - but will use GIT_DIR for HEAD and index.
+	 -
+	 - (Doing the merge this way also lets it run even though the main
+	 - index file is currently locked.)
+	 -}
+	changestomerge (Just updatedorig) = withOtherTmp $ \othertmpdir -> do
+		git_dir <- fromRepo Git.localGitDir
+		let git_dir' = fromRawFilePath git_dir
+		tmpwt <- fromRepo gitAnnexMergeDir
+		withTmpDirIn (fromRawFilePath othertmpdir) "git" $ \tmpgit -> withWorkTreeRelated tmpgit $
+			withemptydir git_dir tmpwt $ withWorkTree tmpwt $ do
+				liftIO $ writeFile (tmpgit </> "HEAD") (fromRef updatedorig)
+				-- Copy in refs and packed-refs, to work
+				-- around bug in git 2.13.0, which
+				-- causes it not to look in GIT_DIR for refs.
+				refs <- liftIO $ emptyWhenDoesNotExist $ 
+					dirContentsRecursive $
+						git_dir' </> "refs"
+				let refs' = (git_dir' </> "packed-refs") : refs
+				liftIO $ forM_ refs' $ \src -> do
+					let src' = toRawFilePath src
+					whenM (doesFileExist src) $ do
+						dest <- relPathDirToFile git_dir src'
+						let dest' = toRawFilePath tmpgit P.</> dest
+						createDirectoryUnder [git_dir]
+							(P.takeDirectory dest')
+						void $ createLinkOrCopy src' dest'
+				-- This reset makes git merge not care
+				-- that the work tree is empty; otherwise
+				-- it will think that all the files have
+				-- been staged for deletion, and sometimes
+				-- the merge includes these deletions
+				-- (for an unknown reason).
+				-- http://thread.gmane.org/gmane.comp.version-control.git/297237
+				inRepo $ Git.Command.run [Param "reset", Param "HEAD", Param "--quiet"]
+				when (tomerge /= origbranch) $
+					showAction $ UnquotedString $ "Merging into " ++ fromRef (Git.Ref.base origbranch)
+				merged <- autoMergeFrom' tomerge Nothing mergeconfig commitmode True
+					(const $ resolveMerge (Just updatedorig) tomerge True)
+				if merged
+					then do
+						!mergecommit <- liftIO $ extractSha
+							<$> S.readFile (tmpgit </> "HEAD")
+						-- This is run after the commit lock is dropped.
+						return $ postmerge mergecommit
+					else return $ return False
+	changestomerge Nothing = return $ return False
+	
+	withemptydir git_dir d a = bracketIO setup cleanup (const a)
+	  where
+		setup = do
+			whenM (doesDirectoryExist d) $
+				removeDirectoryRecursive d
+			createDirectoryUnder [git_dir] (toRawFilePath d)
+		cleanup _ = removeDirectoryRecursive d
+
+	{- A merge commit has been made between the basisbranch and 
+	 - tomerge. Update the basisbranch and origbranch to point
+	 - to that commit, adjust it to get the new adjusted branch,
+	 - and check it out.
+	 -
+	 - But, there may be unstaged work tree changes that conflict, 
+	 - so the check out is done by making a normal merge of
+	 - the new adjusted branch.
+	 -}
+	postmerge (Just mergecommit) = do
+		setBasisBranch basis mergecommit
+		inRepo $ Git.Branch.update' origbranch mergecommit
+		adjtree <- adjustTree adj (BasisBranch mergecommit)
+		adjmergecommit <- commitAdjustedTree adjtree (BasisBranch mergecommit)
+		-- Make currbranch be the parent, so that merging
+		-- this commit will be a fast-forward.
+		adjmergecommitff <- commitAdjustedTree' adjtree (BasisBranch mergecommit) [currbranch]
+		showAction "Merging into adjusted branch"
+		ifM (autoMergeFrom adjmergecommitff (Just currbranch) mergeconfig commitmode canresolvemerge)
+			( reparent adjtree adjmergecommit =<< getcurrentcommit
+			, return False
+			)
+	postmerge Nothing = return False
+
+	-- Now that the merge into the adjusted branch is complete,
+	-- take the tree from that merge, and attach it on top of the
+	-- adjmergecommit, if it's different.
+	reparent adjtree adjmergecommit (Just currentcommit) = do
+		if (commitTree currentcommit /= adjtree)
+			then do
+				cmode <- annexCommitMode <$> Annex.getGitConfig
+				c <- inRepo $ Git.Branch.commitTree cmode
+					["Merged " ++ fromRef tomerge]
+					[adjmergecommit]
+					(commitTree currentcommit)
+				inRepo $ Git.Branch.update "updating adjusted branch" currbranch c
+				propigateAdjustedCommits origbranch adj
+			else inRepo $ Git.Branch.update "updating adjusted branch" currbranch adjmergecommit
+		return True
+	reparent _ _ Nothing = return False
+
+	getcurrentcommit = inRepo Git.Branch.currentUnsafe >>= \case
+		Nothing -> return Nothing
+		Just c -> catCommit c
diff --git a/Annex/AdjustedBranch/Name.hs b/Annex/AdjustedBranch/Name.hs
new file mode 100644
index 0000000000..7a1b44d54e
--- /dev/null
+++ b/Annex/AdjustedBranch/Name.hs
@@ -0,0 +1,99 @@
+{- adjusted branch names
+ -
+ - Copyright 2016-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.AdjustedBranch.Name (
+	originalToAdjusted,
+	adjustedToOriginal,
+	AdjBranch(..),
+	OrigBranch,
+) where
+
+import Types.AdjustedBranch
+import Git
+import qualified Git.Ref
+import Utility.Misc
+
+import Control.Applicative
+import Data.Char
+import qualified Data.ByteString as S
+
+adjustedBranchPrefix :: S.ByteString
+adjustedBranchPrefix = "refs/heads/adjusted/"
+
+class SerializeAdjustment t where
+	serializeAdjustment :: t -> S.ByteString
+	deserializeAdjustment :: S.ByteString -> Maybe t
+
+instance SerializeAdjustment Adjustment where
+	serializeAdjustment (LinkAdjustment l) =
+		serializeAdjustment l
+	serializeAdjustment (PresenceAdjustment p Nothing) =
+		serializeAdjustment p
+	serializeAdjustment (PresenceAdjustment p (Just l)) = 
+		serializeAdjustment p <> "-" <> serializeAdjustment l
+	serializeAdjustment (LinkPresentAdjustment l) =
+		serializeAdjustment l
+	deserializeAdjustment s = 
+		(LinkAdjustment <$> deserializeAdjustment s)
+			<|>
+		(PresenceAdjustment <$> deserializeAdjustment s1 <*> pure (deserializeAdjustment s2))
+			<|>
+		(PresenceAdjustment <$> deserializeAdjustment s <*> pure Nothing)
+			<|>
+		(LinkPresentAdjustment <$> deserializeAdjustment s)
+	  where
+		(s1, s2) = separate' (== (fromIntegral (ord '-'))) s
+
+instance SerializeAdjustment LinkAdjustment where
+	serializeAdjustment UnlockAdjustment = "unlocked"
+	serializeAdjustment LockAdjustment = "locked"
+	serializeAdjustment FixAdjustment = "fixed"
+	serializeAdjustment UnFixAdjustment = "unfixed"
+	deserializeAdjustment "unlocked" = Just UnlockAdjustment
+	deserializeAdjustment "locked" = Just LockAdjustment
+	deserializeAdjustment "fixed" = Just FixAdjustment
+	deserializeAdjustment "unfixed" = Just UnFixAdjustment
+	deserializeAdjustment _ = Nothing
+
+instance SerializeAdjustment PresenceAdjustment where
+	serializeAdjustment HideMissingAdjustment = "hidemissing"
+	serializeAdjustment ShowMissingAdjustment = "showmissing"
+	deserializeAdjustment "hidemissing" = Just HideMissingAdjustment
+	deserializeAdjustment "showmissing" = Just ShowMissingAdjustment
+	deserializeAdjustment _ = Nothing
+
+instance SerializeAdjustment LinkPresentAdjustment where
+	serializeAdjustment UnlockPresentAdjustment = "unlockpresent"
+	serializeAdjustment LockPresentAdjustment = "lockpresent"
+	deserializeAdjustment "unlockpresent" = Just UnlockPresentAdjustment
+	deserializeAdjustment "lockpresent" = Just LockPresentAdjustment
+	deserializeAdjustment _ = Nothing
+
+newtype AdjBranch = AdjBranch { adjBranch :: Branch }
+
+originalToAdjusted :: OrigBranch -> Adjustment -> AdjBranch
+originalToAdjusted orig adj = AdjBranch $ Ref $
+	adjustedBranchPrefix <> base <> "(" <> serializeAdjustment adj <> ")"
+  where
+	base = fromRef' (Git.Ref.base orig)
+
+type OrigBranch = Branch
+
+adjustedToOriginal :: Branch -> Maybe (Adjustment, OrigBranch)
+adjustedToOriginal b
+	| adjustedBranchPrefix `S.isPrefixOf` bs = do
+		let (base, as) = separateEnd' (== openparen) (S.drop prefixlen bs)
+		adj <- deserializeAdjustment (S.takeWhile (/= closeparen) as)
+		Just (adj, Git.Ref.branchRef (Ref base))
+	| otherwise = Nothing
+  where
+	bs = fromRef' b
+	prefixlen = S.length adjustedBranchPrefix
+	openparen = fromIntegral (ord '(')
+	closeparen = fromIntegral (ord ')')
diff --git a/Annex/AutoMerge.hs b/Annex/AutoMerge.hs
new file mode 100644
index 0000000000..bb43d0593b
--- /dev/null
+++ b/Annex/AutoMerge.hs
@@ -0,0 +1,391 @@
+{- git-annex automatic merge conflict resolution
+ -
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.AutoMerge
+	( autoMergeFrom
+	, autoMergeFrom'
+	, resolveMerge
+	, commitResolvedMerge
+	) where
+
+import Annex.Common
+import qualified Annex
+import qualified Annex.Queue
+import Annex.CatFile
+import Annex.Link
+import Annex.Content
+import qualified Git.LsFiles as LsFiles
+import qualified Git.UpdateIndex as UpdateIndex
+import qualified Git.Merge
+import qualified Git.Ref
+import qualified Git
+import qualified Git.Branch
+import Git.Types (TreeItemType(..), fromTreeItemType)
+import Git.FilePath
+import Annex.ReplaceFile
+import Annex.VariantFile
+import qualified Database.Keys
+import Annex.InodeSentinal
+import Utility.InodeCache
+import Utility.FileMode
+import qualified Utility.RawFilePath as R
+
+import qualified Data.Set as S
+import qualified Data.Map as M
+import qualified Data.ByteString.Lazy as L
+import System.PosixCompat.Files (isSymbolicLink)
+
+{- Merges from a branch into the current branch (which may not exist yet),
+ - with automatic merge conflict resolution.
+ -
+ - Callers should use Git.Branch.changed first, to make sure that
+ - there are changes from the current branch to the branch being merged in.
+ -}
+autoMergeFrom :: Git.Ref -> Maybe Git.Ref -> [Git.Merge.MergeConfig] -> Git.Branch.CommitMode -> Bool -> Annex Bool
+autoMergeFrom branch currbranch mergeconfig commitmode canresolvemerge =
+	autoMergeFrom' branch currbranch mergeconfig commitmode canresolvemerge resolvemerge
+  where
+	resolvemerge old
+		| canresolvemerge = resolveMerge old branch False
+		| otherwise = return False 
+
+autoMergeFrom' :: Git.Ref -> Maybe Git.Ref -> [Git.Merge.MergeConfig] -> Git.Branch.CommitMode -> Bool -> (Maybe Git.Ref -> Annex Bool) -> Annex Bool
+autoMergeFrom' branch currbranch mergeconfig commitmode willresolvemerge toresolvemerge = do
+	showOutput
+	case currbranch of
+		Nothing -> go Nothing
+		Just b -> go =<< inRepo (Git.Ref.sha b)
+  where
+	go old = do
+			-- merge.directoryRenames=conflict plus automatic
+			-- merge conflict resolution results in files in a
+			-- "renamed" directory getting variant names,
+			-- so is not a great combination. If the user has
+			-- explicitly set it, use it, but otherwise when
+			-- merge conflicts will be resolved, override
+			-- to merge.directoryRenames=false.
+			overridedirectoryrenames <- if willresolvemerge
+				then isNothing . mergeDirectoryRenames
+					<$> Annex.getGitConfig
+				else pure False
+			let f r 
+				| overridedirectoryrenames = r
+					{ Git.gitGlobalOpts = 
+						Param "-c"
+						: Param "merge.directoryRenames=false" 
+						: Git.gitGlobalOpts r
+					}
+				| otherwise = r
+			r <- inRepo (Git.Merge.merge branch mergeconfig commitmode . f)
+				<||> (toresolvemerge old <&&> commitResolvedMerge commitmode)
+			-- Merging can cause new associated files to appear
+			-- and the smudge filter will add them to the database.
+			-- To ensure that this process sees those changes,
+			-- close the database if it was open.
+			Database.Keys.closeDb
+			return r
+
+{- Resolves a conflicted merge. It's important that any conflicts be
+ - resolved in a way that itself avoids later merge conflicts, since
+ - multiple repositories may be doing this concurrently.
+ -
+ - Only merge conflicts where at least one side is an annexed file
+ - is resolved.
+ -
+ - This uses the Keys pointed to by the files to construct new
+ - filenames. So when both sides modified annexed file foo, 
+ - it will be deleted, and replaced with files foo.variant-A and
+ - foo.variant-B.
+ -
+ - On the other hand, when one side deleted foo, and the other modified it,
+ - it will be deleted, and the modified version stored as file
+ - foo.variant-A (or B).
+ -
+ - It's also possible that one side has foo as an annexed file, and
+ - the other as a directory or non-annexed file. The annexed file
+ - is renamed to resolve the merge, and the other object is preserved as-is.
+ -
+ - The merge is resolved in the work tree and files
+ - staged, to clean up from a conflicted merge that was run in the work
+ - tree. 
+ - 
+ - This is complicated by needing to support merges run in an overlay
+ - work tree, in which case the CWD won't be within the work tree.
+ - In this mode, there is no need to update the work tree at all,
+ - as the overlay work tree will get deleted.
+ -
+ - Unlocked files remain unlocked after merging, and locked files
+ - remain locked. When the merge conflict is between a locked and unlocked
+ - file, that otherwise point to the same content, the unlocked mode wins.
+ - This is done because only unlocked files work in filesystems that don't
+ - support symlinks.
+ -
+ - Returns false when there are no merge conflicts to resolve.
+ - A git merge can fail for other reasons, and this allows detecting
+ - such failures.
+ -}
+resolveMerge :: Maybe Git.Ref -> Git.Ref -> Bool -> Annex Bool
+resolveMerge us them inoverlay = do
+	top <- if inoverlay
+		then pure "."
+		else fromRepo Git.repoPath
+	(fs, cleanup) <- inRepo (LsFiles.unmerged [top])
+	srcmap <- if inoverlay
+		then pure M.empty
+		else inodeMap $ pure (concatMap getunmergedfiles fs, return True)
+	(mergedks, mergedfs) <- unzip <$> mapM (resolveMerge' srcmap us them inoverlay) fs
+	let mergedks' = concat mergedks
+	let mergedfs' = catMaybes mergedfs
+	let merged = not (null mergedfs')
+	void $ liftIO cleanup
+
+	unless inoverlay $ do
+		(deleted, cleanup2) <- inRepo (LsFiles.deleted [] [top])
+		unless (null deleted) $
+			Annex.Queue.addCommand [] "rm"
+				[Param "--quiet", Param "-f", Param "--"]
+				(map fromRawFilePath deleted)
+		void $ liftIO cleanup2
+
+	when merged $ do
+		Annex.Queue.flush
+		unless inoverlay $ do
+			unstagedmap <- inodeMap $ inRepo $
+				LsFiles.notInRepo [] False [top]
+			cleanConflictCruft mergedks' mergedfs' unstagedmap
+		showLongNote "Merge conflict was automatically resolved; you may want to examine the result."
+	return merged
+  where
+	getunmergedfiles u = catMaybes
+		[ Just (LsFiles.unmergedFile u)
+		, LsFiles.unmergedSiblingFile u
+		]
+
+resolveMerge' :: InodeMap -> Maybe Git.Ref -> Git.Ref -> Bool -> LsFiles.Unmerged -> Annex ([Key], Maybe FilePath)
+resolveMerge' _ Nothing _ _ _ = return ([], Nothing)
+resolveMerge' unstagedmap (Just us) them inoverlay u = do
+	kus <- getkey LsFiles.valUs
+	kthem <- getkey LsFiles.valThem
+	case (kus, kthem) of
+		-- Both sides of conflict are annexed files
+		(Just keyUs, Just keyThem)
+			| keyUs /= keyThem -> resolveby [keyUs, keyThem] $ do
+				makevariantannexlink keyUs LsFiles.valUs
+				makevariantannexlink keyThem LsFiles.valThem
+				-- cleanConflictCruft can't handle unlocked
+				-- files, so delete here.
+				unless inoverlay $
+					unless (islocked LsFiles.valUs) $
+						liftIO $ removeWhenExistsWith R.removeLink (toRawFilePath file)
+			| otherwise -> resolveby [keyUs, keyThem] $
+				-- Only resolve using symlink when both
+				-- were locked, otherwise use unlocked
+				-- pointer.
+				-- In either case, keep original filename.
+				if islocked LsFiles.valUs && islocked LsFiles.valThem
+					then makesymlink keyUs file
+					else makepointer keyUs file (combinedmodes)
+		-- Our side is annexed file, other side is not.
+		-- Make the annexed file into a variant file and graft in the
+		-- other file/directory as it was.
+		(Just keyUs, Nothing) -> resolveby [keyUs] $ do
+			graftin them file LsFiles.valThem LsFiles.valThem LsFiles.valUs
+			makevariantannexlink keyUs LsFiles.valUs
+		-- Our side is not annexed file, other side is.
+		(Nothing, Just keyThem) -> resolveby [keyThem] $ do
+			graftin us file LsFiles.valUs LsFiles.valUs LsFiles.valThem
+			makevariantannexlink keyThem LsFiles.valThem
+		-- Neither side is annexed file; cannot resolve.
+		(Nothing, Nothing) -> return ([], Nothing)
+  where
+	file = fromRawFilePath $ LsFiles.unmergedFile u
+	sibfile = fromRawFilePath <$> LsFiles.unmergedSiblingFile u
+
+	getkey select = 
+		case select (LsFiles.unmergedSha u) of
+			Just sha -> catKey sha
+			Nothing -> pure Nothing
+	
+	islocked select = select (LsFiles.unmergedTreeItemType u) == Just TreeSymlink
+
+	combinedmodes = case catMaybes [ourmode, theirmode] of
+		[] -> Nothing
+		l -> Just (combineModes l)
+	  where
+		ourmode = fromTreeItemType
+			<$> LsFiles.valUs (LsFiles.unmergedTreeItemType u)
+		theirmode = fromTreeItemType
+			<$> LsFiles.valThem (LsFiles.unmergedTreeItemType u)
+
+	makevariantannexlink key select
+		| islocked select = makesymlink key dest
+		| otherwise = makepointer key dest destmode
+	  where
+		dest = variantFile file key
+		destmode = fromTreeItemType <$> select (LsFiles.unmergedTreeItemType u)
+
+	stagefile :: FilePath -> Annex FilePath
+	stagefile f
+		| inoverlay = (</> f) . fromRawFilePath <$> fromRepo Git.repoPath
+		| otherwise = pure f
+
+	makesymlink key dest = do
+		l <- calcRepo $ gitAnnexLink (toRawFilePath dest) key
+		unless inoverlay $ replacewithsymlink dest l
+		dest' <- toRawFilePath <$> stagefile dest
+		stageSymlink dest' =<< hashSymlink l
+
+	replacewithsymlink dest link = replaceWorkTreeFile dest $
+		makeGitLink link
+
+	makepointer key dest destmode = do
+		unless inoverlay $ 
+			unlessM (reuseOldFile unstagedmap key file dest) $
+				linkFromAnnex key (toRawFilePath dest) destmode >>= \case
+					LinkAnnexFailed -> liftIO $
+						writePointerFile (toRawFilePath dest) key destmode
+					_ -> noop
+		dest' <- toRawFilePath <$> stagefile dest
+		stagePointerFile dest' destmode =<< hashPointerFile key
+		unless inoverlay $
+			Database.Keys.addAssociatedFile key
+				=<< inRepo (toTopFilePath (toRawFilePath dest))
+
+	{- Stage a graft of a directory or file from a branch
+	 - and update the work tree. -}
+	graftin b item selectwant selectwant' selectunwant = do
+		Annex.Queue.addUpdateIndex
+			=<< fromRepo (UpdateIndex.lsSubTree b item)
+				
+		let replacefile isexecutable = case selectwant' (LsFiles.unmergedSha u) of
+			Nothing -> noop
+			Just sha -> replaceWorkTreeFile item $ \tmp -> do
+				c <- catObject sha
+				liftIO $ L.writeFile (decodeBS tmp) c
+				when isexecutable $
+					liftIO $ void $ tryIO $ 
+						modifyFileMode tmp $
+							addModes executeModes
+
+		-- Update the work tree to reflect the graft.
+		unless inoverlay $ case (selectwant (LsFiles.unmergedTreeItemType u), selectunwant (LsFiles.unmergedTreeItemType u)) of
+			(Just TreeSymlink, _) -> do
+				case selectwant' (LsFiles.unmergedSha u) of
+					Nothing -> noop
+					Just sha -> do
+						link <- catSymLinkTarget sha
+						replacewithsymlink item link
+			(Just TreeFile, Just TreeSymlink) -> replacefile False
+			(Just TreeExecutable, Just TreeSymlink) -> replacefile True
+			_ -> ifM (liftIO $ doesDirectoryExist item)
+				-- a conflict between a file and a directory
+				-- leaves the directory, so since a directory
+				-- is there, it must be what was wanted
+				( noop
+				-- probably a file with conflict markers is
+				-- in the work tree; replace with grafted
+				-- file content (this is needed when
+				-- the annexed file is unlocked)
+				, replacefile False
+				)
+	
+	resolveby ks a = do
+		{- Remove conflicted file from index so merge can be resolved.
+		 - If there's a sibling conflicted file, remove it too. -}
+		Annex.Queue.addCommand [] "rm"
+			[ Param "--quiet"
+			, Param "-f"
+			, Param "--cached"
+			, Param "--"
+			]
+			(catMaybes [Just file, sibfile])
+		liftIO $ maybe noop
+			(removeWhenExistsWith R.removeLink . toRawFilePath)
+			sibfile
+		void a
+		return (ks, Just file)
+
+{- git-merge moves conflicting files away to files
+ - named something like f~HEAD or f~branch or just f, but the
+ - exact name chosen can vary. Once the conflict is resolved,
+ - this cruft can be deleted. To avoid deleting legitimate
+ - files that look like this, only delete files that are
+ - A) not staged in git and
+ - B) have a name related to the merged files and
+ - C) are pointers to or have the content of keys that were involved
+ - in the merge.
+ -}
+cleanConflictCruft :: [Key] -> [FilePath] -> InodeMap -> Annex ()
+cleanConflictCruft resolvedks resolvedfs unstagedmap = do
+	is <- S.fromList . map (inodeCacheToKey Strongly) . concat 
+		<$> mapM Database.Keys.getInodeCaches resolvedks
+	forM_ (M.toList unstagedmap) $ \(i, f) ->
+		whenM (matchesresolved is i f) $
+			liftIO $ removeWhenExistsWith R.removeLink (toRawFilePath f)
+  where
+	fs = S.fromList resolvedfs
+	ks = S.fromList resolvedks
+	inks = maybe False (flip S.member ks)
+	matchesresolved is i f
+		| S.member f fs || S.member (conflictCruftBase f) fs = anyM id
+			[ pure $ either (const False) (`S.member` is) i
+			, inks <$> isAnnexLink (toRawFilePath f)
+			, inks <$> liftIO (isPointerFile (toRawFilePath f))
+			]
+		| otherwise = return False
+
+conflictCruftBase :: FilePath -> FilePath
+conflictCruftBase f = reverse $ drop 1 $ dropWhile (/= '~') $ reverse f
+
+{- When possible, reuse an existing file from the srcmap as the
+ - content of a worktree file in the resolved merge. It must have the
+ - same name as the origfile, or a name that git would use for conflict
+ - cruft. And, its inode cache must be a known one for the key. -}
+reuseOldFile :: InodeMap -> Key -> FilePath -> FilePath -> Annex Bool
+reuseOldFile srcmap key origfile destfile = do
+	is <- map (inodeCacheToKey Strongly)
+		<$> Database.Keys.getInodeCaches key
+	liftIO $ go $ mapMaybe (\i -> M.lookup (Right i) srcmap) is
+  where
+	go [] = return False
+	go (f:fs)
+		| f == origfile || conflictCruftBase f == origfile = 
+			ifM (doesFileExist f)
+				( do
+					renameFile f destfile
+					return True
+				, go fs
+				)
+		| otherwise = go fs
+	
+commitResolvedMerge :: Git.Branch.CommitMode -> Annex Bool
+commitResolvedMerge commitmode = do
+	commitquiet <- Git.Branch.CommitQuiet <$> commandProgressDisabled
+	inRepo $ Git.Branch.commitCommand commitmode commitquiet
+		[ Param "--no-verify"
+		, Param "-m"
+		, Param "git-annex automatic merge conflict fix"
+		]
+
+type InodeMap = M.Map (Either FilePath InodeCacheKey) FilePath
+
+inodeMap :: Annex ([RawFilePath], IO Bool) -> Annex InodeMap
+inodeMap getfiles = do
+	(fs, cleanup) <- getfiles
+	fsis <- forM fs $ \f -> do
+		s <- liftIO $ R.getSymbolicLinkStatus f
+		let f' = fromRawFilePath f
+		if isSymbolicLink s
+			then pure $ Just (Left f', f')
+			else withTSDelta (\d -> liftIO $ toInodeCache d f s)
+				>>= return . \case
+					Just i -> Just (Right (inodeCacheToKey Strongly i), f')
+					Nothing -> Nothing
+	void $ liftIO cleanup
+	return $ M.fromList $ catMaybes fsis
diff --git a/Annex/BloomFilter.hs b/Annex/BloomFilter.hs
new file mode 100644
index 0000000000..571f1c6c17
--- /dev/null
+++ b/Annex/BloomFilter.hs
@@ -0,0 +1,54 @@
+{- git-annex bloom filter
+ -
+ - Copyright 2010-2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.BloomFilter where
+
+import Annex.Common
+import qualified Annex
+import Utility.Bloom
+
+import Control.Monad.ST
+
+{- A bloom filter capable of holding half a million keys with a
+ - false positive rate of 1 in 10000000 uses around 16 mb of memory,
+ - so will easily fit on even my lowest memory systems.
+ -}
+bloomCapacity :: Annex Int
+bloomCapacity = fromMaybe 500000 . annexBloomCapacity <$> Annex.getGitConfig
+bloomAccuracy :: Annex Int
+bloomAccuracy = fromMaybe 10000000 . annexBloomAccuracy <$> Annex.getGitConfig
+bloomBitsHashes :: Annex (Int, Int)
+bloomBitsHashes = do
+	capacity <- bloomCapacity
+	accuracy <- bloomAccuracy
+	case safeSuggestSizing capacity (1 / fromIntegral accuracy) of
+		Left e -> do
+			warning $ UnquotedString $
+				"bloomfilter " ++ e ++ "; falling back to sane value"
+			-- precaulculated value for 500000 (1/10000000)
+			return (16777216,23)
+		Right v -> return v
+
+{- Creates a bloom filter, and runs an action to populate it.
+ -
+ - The action is passed a callback that it can use to feed values into the
+ - bloom filter. 
+ -
+ - Once the action completes, the mutable filter is frozen
+ - for later use.
+ -}
+genBloomFilter :: Hashable v => ((v -> Annex ()) -> Annex ()) -> Annex (Bloom v)
+genBloomFilter populate = do
+	(numbits, numhashes) <- bloomBitsHashes
+	bloom <- lift $ newMB (cheapHashes numhashes) numbits
+	populate $ \v -> lift $ insertMB bloom v
+	lift $ unsafeFreezeMB bloom
+  where
+	lift = liftIO . stToIO
+
+bloomFilter :: [v] -> Bloom v -> [v]
+bloomFilter l bloom = filter (\v -> v `notElemB` bloom) l
diff --git a/Annex/Branch.hs b/Annex/Branch.hs
new file mode 100644
index 0000000000..bcc9ae114d
--- /dev/null
+++ b/Annex/Branch.hs
@@ -0,0 +1,1062 @@
+{- management of the git-annex branch
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Branch (
+	fullname,
+	name,
+	hasOrigin,
+	hasSibling,
+	siblingBranches,
+	create,
+	getBranch,
+	UpdateMade(..),
+	update,
+	forceUpdate,
+	updateTo,
+	get,
+	getHistorical,
+	getUnmergedRefs,
+	RegardingUUID(..),
+	change,
+	ChangeOrAppend(..),
+	changeOrAppend,
+	maybeChange,
+	commitMessage,
+	createMessage,
+	commit,
+	forceCommit,
+	files,
+	rememberTreeish,
+	performTransitions,
+	withIndex,
+	precache,
+	overBranchFileContents,
+	updatedFromTree,
+) where
+
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Set as S
+import qualified Data.Map as M
+import Data.Function
+import Data.Char
+import Data.ByteString.Builder
+import Control.Concurrent (threadDelay)
+import Control.Concurrent.MVar
+import qualified System.FilePath.ByteString as P
+import System.PosixCompat.Files (isRegularFile)
+
+import Annex.Common
+import Types.BranchState
+import Annex.BranchState
+import Annex.Journal
+import Annex.GitOverlay
+import Annex.Tmp
+import qualified Git
+import qualified Git.Command
+import qualified Git.Ref
+import qualified Git.RefLog
+import qualified Git.Sha
+import qualified Git.Branch
+import qualified Git.UnionMerge
+import qualified Git.UpdateIndex
+import qualified Git.Tree
+import qualified Git.LsTree
+import Git.LsTree (lsTreeParams)
+import qualified Git.HashObject
+import Annex.HashObject
+import Git.Types (Ref(..), fromRef, fromRef', RefDate, TreeItemType(..))
+import Git.FilePath
+import Annex.CatFile
+import Git.CatFile (catObjectStreamLsTree)
+import Annex.Perms
+import Logs
+import Logs.Transitions
+import Logs.File
+import Logs.Trust.Pure
+import Logs.Remote.Pure
+import Logs.Export.Pure
+import Logs.Difference.Pure
+import qualified Annex.Queue
+import Types.Transitions
+import Annex.Branch.Transitions
+import qualified Annex
+import Annex.Hook
+import Utility.Directory.Stream
+import Utility.Tmp
+import qualified Utility.RawFilePath as R
+
+{- Name of the branch that is used to store git-annex's information. -}
+name :: Git.Ref
+name = Git.Ref "git-annex"
+
+{- Fully qualified name of the branch. -}
+fullname :: Git.Ref
+fullname = Git.Ref $ "refs/heads/" <> fromRef' name
+
+{- Branch's name in origin. -}
+originname :: Git.Ref
+originname = Git.Ref $ "refs/remotes/origin/" <> fromRef' name
+
+{- Does origin/git-annex exist? -}
+hasOrigin :: Annex Bool
+hasOrigin = inRepo $ Git.Ref.exists originname
+
+{- Does the git-annex branch or a sibling foo/git-annex branch exist? -}
+hasSibling :: Annex Bool
+hasSibling = not . null <$> siblingBranches
+
+{- List of git-annex (shas, branches), including the main one and any
+ - from remotes. Duplicates are filtered out. -}
+siblingBranches :: Annex [(Git.Sha, Git.Branch)]
+siblingBranches = inRepo $ Git.Ref.matchingUniq [name]
+
+{- Creates the branch, if it does not already exist. -}
+create :: Annex ()
+create = void getBranch
+
+{- Returns the sha of the branch, creating it first if necessary. -}
+getBranch :: Annex Git.Ref
+getBranch = maybe (hasOrigin >>= go >>= use) return =<< branchsha
+  where
+	go True = do
+		inRepo $ Git.Command.run
+			[ Param "branch"
+			, Param "--no-track"
+			, Param $ fromRef name
+			, Param $ fromRef originname
+			]
+		fromMaybe (giveup $ "failed to create " ++ fromRef name)
+			<$> branchsha
+	go False = withIndex' True $ do
+		-- Create the index file. This is not necessary,
+		-- except to avoid a bug in git 2.37 that causes
+		-- git write-tree to segfault when the index file does not
+		-- exist.
+		inRepo $ flip Git.UpdateIndex.streamUpdateIndex []
+		cmode <- annexCommitMode <$> Annex.getGitConfig
+		cmessage <- createMessage
+		inRepo $ Git.Branch.commitAlways cmode cmessage fullname []
+	use sha = do
+		setIndexSha sha
+		return sha
+	branchsha = inRepo $ Git.Ref.sha fullname
+
+{- Ensures that the branch and index are up-to-date; should be
+ - called before data is read from it. Runs only once per git-annex run. -}
+update :: Annex BranchState
+update = runUpdateOnce $ updateTo =<< siblingBranches
+
+{- Forces an update even if one has already been run. -}
+forceUpdate :: Annex UpdateMade
+forceUpdate = updateTo =<< siblingBranches
+
+{- Merges the specified Refs into the index, if they have any changes not
+ - already in it. The Branch names are only used in the commit message;
+ - it's even possible that the provided Branches have not been updated to
+ - point to the Refs yet.
+ - 
+ - The branch is fast-forwarded if possible, otherwise a merge commit is
+ - made.
+ -
+ - Before Refs are merged into the index, it's important to first stage the
+ - journal into the index. Otherwise, any changes in the journal would
+ - later get staged, and might overwrite changes made during the merge.
+ - This is only done if some of the Refs do need to be merged.
+ -
+ - Also handles performing any Transitions that have not yet been
+ - performed, in either the local branch, or the Refs.
+ -}
+updateTo :: [(Git.Sha, Git.Branch)] -> Annex UpdateMade
+updateTo pairs = ifM (annexMergeAnnexBranches <$> Annex.getGitConfig)
+	( updateTo' pairs
+	, return (UpdateMade False False)
+	)
+
+updateTo' :: [(Git.Sha, Git.Branch)] -> Annex UpdateMade
+updateTo' pairs = do
+	-- ensure branch exists, and get its current ref
+	branchref <- getBranch
+	ignoredrefs <- getIgnoredRefs
+	let unignoredrefs = excludeset ignoredrefs pairs
+	(tomerge, notnewer) <- if null unignoredrefs
+		then return ([], [])
+		else do
+			mergedrefs <- getMergedRefs
+			partitionM isnewer $
+				excludeset mergedrefs unignoredrefs
+	{- In a read-only repository, catching permission denied lets
+	 - query operations still work, although they will need to do
+	 - additional work since the refs are not merged. -}
+	catchPermissionDenied
+		(const (updatefailedperms tomerge))
+		(go branchref tomerge notnewer)
+  where
+	excludeset s = filter (\(r, _) -> S.notMember r s)
+
+	isnewer (r, _) = inRepo $ Git.Branch.changed fullname r
+
+	go branchref tomerge notnewer = do
+		dirty <- journalDirty gitAnnexJournalDir
+		journalcleaned <- if null tomerge
+			{- Even when no refs need to be merged, the index
+			 - may still be updated if the branch has gotten ahead 
+			 - of the index, or just if the journal is dirty. -}
+			then ifM (needUpdateIndex branchref)
+				( lockJournal $ \jl -> do
+					forceUpdateIndex jl branchref
+					{- When there are journalled changes
+					 - as well as the branch being updated,
+					 - a commit needs to be done. -}
+					when dirty $
+						go' branchref dirty [] jl
+					return True
+				, if dirty
+					then ifM (annexAlwaysCommit <$> Annex.getGitConfig)
+						( lockJournal $ \jl -> do
+							go' branchref dirty [] jl
+							return True
+						, return False
+						)
+					else return True
+				)
+			else lockJournal $ \jl -> do
+				go' branchref dirty tomerge jl
+				return True
+		journalclean <- if journalcleaned
+			then not <$> privateUUIDsKnown
+			else pure False
+		addMergedRefs notnewer
+		return $ UpdateMade
+			{ refsWereMerged = not (null tomerge)
+			, journalClean = journalclean 
+			}
+	
+	go' branchref dirty tomerge jl = stagejournalwhen dirty jl $ do
+		let (refs, branches) = unzip tomerge
+		merge_desc <- if null tomerge
+			then commitMessage
+			else return $ "merging " ++
+				unwords (map Git.Ref.describe branches) ++ 
+				" into " ++ fromRef name
+		localtransitions <- getLocalTransitions
+		unless (null tomerge) $ do
+			showSideAction (UnquotedString merge_desc)
+			mapM_ checkBranchDifferences refs
+			mergeIndex jl refs
+		let commitrefs = nub $ fullname:refs
+		ifM (handleTransitions jl localtransitions commitrefs)
+			( runAnnexHook postUpdateAnnexHook
+			, do
+				ff <- if dirty
+					then return False
+					else inRepo $ Git.Branch.fastForward fullname refs
+				if ff
+					then updateIndex jl branchref
+					else commitIndex jl branchref merge_desc commitrefs
+			)
+		addMergedRefs tomerge
+		invalidateCache
+	
+	stagejournalwhen dirty jl a
+		| dirty = stageJournal jl a
+		| otherwise = withIndex a
+	
+	-- Preparing for read-only branch access with unmerged remote refs.
+	updatefailedperms tomerge = do
+		let refs = map fst tomerge
+		-- Gather any transitions that are new to either the
+		-- local branch or a remote ref, which will need to be
+		-- applied on the fly.
+		localts <- getLocalTransitions
+		remotets <- mapM getRefTransitions refs
+		ts <- if all (localts ==) remotets
+			then return []
+			else 
+				let tcs = mapMaybe getTransitionCalculator $
+					knownTransitionList $
+						combineTransitions (localts:remotets)
+				in if null tcs
+					then return []
+					else do
+						config <- Annex.getGitConfig
+						trustmap <- calcTrustMap <$> getStaged trustLog
+						remoteconfigmap <- calcRemoteConfigMap <$> getStaged remoteLog
+						return $ map (\c -> c trustmap remoteconfigmap config) tcs
+		return $ UpdateFailedPermissions 
+			{ refsUnmerged = refs
+			, newTransitions = ts
+			}
+
+{- Gets the content of a file, which may be in the journal, or in the index
+ - (and committed to the branch). 
+ -
+ - Returns an empty string if the file doesn't exist yet.
+ - 
+ - Updates the branch if necessary, to ensure the most up-to-date available
+ - content is returned. 
+ -
+ - When permissions prevented updating the branch, reads the content from the
+ - journal, plus the branch, plus all unmerged refs. In this case, any
+ - transitions that have not been applied to all refs will be applied on
+ - the fly.
+ -}
+get :: RawFilePath -> Annex L.ByteString
+get file = do
+	st <- update
+	case getCache file st of
+		Just content -> return content
+		Nothing -> do
+			content <- if journalIgnorable st
+				then getRef fullname file
+				else if null (unmergedRefs st) 
+					then getLocal file
+					else unmergedbranchfallback st
+			setCache file content
+			return content
+  where
+	unmergedbranchfallback st = do
+		l <- getLocal file
+		bs <- forM (unmergedRefs st) $ \ref -> getRef ref file
+		let content = l <> mconcat bs
+		return $ applytransitions (unhandledTransitions st) content
+	applytransitions [] content = content
+	applytransitions (changer:rest) content = case changer file content of
+		PreserveFile -> applytransitions rest content
+		ChangeFile builder -> do
+			let content' = toLazyByteString builder
+			if L.null content'
+				-- File is deleted, can't run any other
+				-- transitions on it.
+				then content'
+				else applytransitions rest content'
+
+{- When the git-annex branch is unable to be updated due to permissions,
+ - and there are other git-annex branches that have not been merged into
+ - it, this gets the refs of those branches. -}
+getUnmergedRefs :: Annex [Git.Ref]
+getUnmergedRefs = unmergedRefs <$> update
+
+{- Used to cache the value of a file, which has been read from the branch
+ - using some optimised method. The journal has to be checked, in case
+ - it has a newer version of the file that has not reached the branch yet.
+ -}
+precache :: RawFilePath -> L.ByteString -> Annex ()
+precache file branchcontent = do
+	st <- getState
+	content <- if journalIgnorable st
+		then pure branchcontent
+		else getJournalFileStale (GetPrivate True) file >>= return . \case
+			NoJournalledContent -> branchcontent
+			JournalledContent journalcontent -> journalcontent
+			PossiblyStaleJournalledContent journalcontent ->
+				branchcontent <> journalcontent
+	setCache file content
+
+{- Like get, but does not merge the branch, so the info returned may not
+ - reflect changes in remotes.
+ - (Changing the value this returns, and then merging is always the
+ - same as using get, and then changing its value.) -}
+getLocal :: RawFilePath -> Annex L.ByteString
+getLocal = getLocal' (GetPrivate True)
+
+getLocal' :: GetPrivate -> RawFilePath -> Annex L.ByteString
+getLocal' getprivate file = do
+	fastDebug "Annex.Branch" ("read " ++ fromRawFilePath file)
+	go =<< getJournalFileStale getprivate file
+  where
+	go NoJournalledContent = getRef fullname file
+	go (JournalledContent journalcontent) = return journalcontent
+	go (PossiblyStaleJournalledContent journalcontent) = do
+		v <- getRef fullname file
+		return (v <> journalcontent)
+
+{- Gets the content of a file as staged in the branch's index. -}
+getStaged :: RawFilePath -> Annex L.ByteString
+getStaged = getRef indexref
+  where
+	-- This makes git cat-file be run with ":file",
+	-- so it looks at the index.
+	indexref = Ref ""
+
+getHistorical :: RefDate -> RawFilePath -> Annex L.ByteString
+getHistorical date file =
+	-- This check avoids some ugly error messages when the reflog
+	-- is empty.
+	ifM (null <$> inRepo (Git.RefLog.get' [Param (fromRef fullname), Param "-n1"]))
+		( giveup ("No reflog for " ++ fromRef fullname)
+		, getRef (Git.Ref.dateRef fullname date) file
+		)
+
+getRef :: Ref -> RawFilePath -> Annex L.ByteString
+getRef ref file = withIndex $ catFile ref file
+
+{- Applies a function to modify the content of a file.
+ -
+ - Note that this does not cause the branch to be merged, it only
+ - modifies the current content of the file on the branch.
+ -}
+change :: Journalable content => RegardingUUID -> RawFilePath -> (L.ByteString -> content) -> Annex ()
+change ru file f = lockJournal $ \jl -> f <$> getToChange ru file >>= set jl ru file
+
+{- Applies a function which can modify the content of a file, or not. -}
+maybeChange :: Journalable content => RegardingUUID -> RawFilePath -> (L.ByteString -> Maybe content) -> Annex ()
+maybeChange ru file f = lockJournal $ \jl -> do
+	v <- getToChange ru file
+	case f v of
+		Just jv ->
+			let b = journalableByteString jv
+			in when (v /= b) $ set jl ru file b
+		_ -> noop
+
+data ChangeOrAppend t = Change t | Append t
+
+{- Applies a function that can either modify the content of the file,
+ - or append to the file. Appending can be more efficient when several
+ - lines are written to a file in succession.
+ -
+ - When annex.alwayscompact=false, the function is not passed the content
+ - of the journal file when the journal file already exists, and whatever
+ - value it provides is always appended to the journal file. That avoids
+ - reading the journal file, and so can be faster when many lines are being
+ - written to it. The information that is recorded will be effectively the
+ - same, only obsolete log lines will not get compacted.
+ -
+ - Currently, only appends when annex.alwayscompact=false. That is to
+ - avoid appending when an older version of git-annex is also in use in the
+ - same repository. An interrupted append could leave the journal file in a
+ - state that would confuse the older version. This is planned to be
+ - changed in a future repository version.
+ -}
+changeOrAppend :: Journalable content => RegardingUUID -> RawFilePath -> (L.ByteString -> ChangeOrAppend content) -> Annex ()
+changeOrAppend ru file f = lockJournal $ \jl ->
+	checkCanAppendJournalFile jl ru file >>= \case
+		Just appendable -> ifM (annexAlwaysCompact <$> Annex.getGitConfig)
+			( do
+				oldc <- getToChange ru file
+				case f oldc of
+					Change newc -> set jl ru file newc
+					Append toappend -> 
+						set jl ru file $
+							oldc <> journalableByteString toappend
+						-- Use this instead in v11
+						-- or whatever.
+						-- append jl file appendable toappend
+			, case f mempty of
+				-- Append even though a change was
+				-- requested; since mempty was passed in,
+				-- the lines requested to change are
+				-- minimized.
+				Change newc -> append jl file appendable newc
+				Append toappend -> append jl file appendable toappend
+			)
+		Nothing -> do
+			oldc <- getToChange ru file
+			case f oldc of
+				Change newc -> set jl ru file newc
+				-- Journal file does not exist yet, so
+				-- cannot append and have to write it all.
+				Append toappend -> set jl ru file $
+					oldc <> journalableByteString toappend
+
+{- Only get private information when the RegardingUUID is itself private. -}
+getToChange :: RegardingUUID -> RawFilePath -> Annex L.ByteString
+getToChange ru f = flip getLocal' f . GetPrivate =<< regardingPrivateUUID ru
+
+{- Records new content of a file into the journal.
+ -
+ - This is not exported; all changes have to be made via change. This
+ - ensures that information that was written to the branch is not
+ - overwritten. Also, it avoids a get followed by a set without taking into
+ - account whether private information was gotten from the private
+ - git-annex index, and should not be written to the public git-annex
+ - branch.
+ -}
+set :: Journalable content => JournalLocked -> RegardingUUID -> RawFilePath -> content -> Annex ()
+set jl ru f c = do
+	journalChanged
+	setJournalFile jl ru f c
+	fastDebug "Annex.Branch" ("set " ++ fromRawFilePath f)
+	-- Could cache the new content, but it would involve
+	-- evaluating a Journalable Builder twice, which is not very
+	-- efficient. Instead, assume that it's not common to need to read
+	-- a log file immediately after writing it.
+	invalidateCache
+
+{- Appends content to the journal file. -}
+append :: Journalable content => JournalLocked -> RawFilePath -> AppendableJournalFile -> content -> Annex ()
+append jl f appendable toappend = do
+	journalChanged
+	appendJournalFile jl appendable toappend
+	fastDebug "Annex.Branch" ("append " ++ fromRawFilePath f)
+	invalidateCache
+
+{- Commit message used when making a commit of whatever data has changed
+ - to the git-annex branch. -}
+commitMessage :: Annex String
+commitMessage = fromMaybe "update" <$> getCommitMessage
+
+{- Commit message used when creating the branch. -}
+createMessage :: Annex String
+createMessage = fromMaybe "branch created" <$> getCommitMessage
+
+getCommitMessage :: Annex (Maybe String)
+getCommitMessage = do
+	config <- Annex.getGitConfig
+	case annexCommitMessageCommand config of
+		Nothing -> return (annexCommitMessage config)
+		Just cmd -> catchDefaultIO (annexCommitMessage config) $
+			Just <$> liftIO (readProcess "sh" ["-c", cmd])
+
+{- Stages the journal, and commits staged changes to the branch. -}
+commit :: String -> Annex ()
+commit = whenM (journalDirty gitAnnexJournalDir) . forceCommit
+
+{- Commits the current index to the branch even without any journalled
+ - changes. -}
+forceCommit :: String -> Annex ()
+forceCommit message = lockJournal $ \jl ->
+	stageJournal jl $ do
+		ref <- getBranch
+		commitIndex jl ref message [fullname]
+
+{- Commits the staged changes in the index to the branch.
+ - 
+ - Ensures that the branch's index file is first updated to merge the state
+ - of the branch at branchref, before running the commit action. This
+ - is needed because the branch may have had changes pushed to it, that
+ - are not yet reflected in the index.
+ - 
+ - The branchref value can have been obtained using getBranch at any
+ - previous point, though getting it a long time ago makes the race
+ - more likely to occur.
+ -
+ - Note that changes may be pushed to the branch at any point in time!
+ - So, there's a race. If the commit is made using the newly pushed tip of
+ - the branch as its parent, and that ref has not yet been merged into the
+ - index, then the result is that the commit will revert the pushed
+ - changes, since they have not been merged into the index. This race
+ - is detected and another commit made to fix it.
+ -
+ - (It's also possible for the branch to be overwritten,
+ - losing the commit made here. But that's ok; the data is still in the
+ - index and will get committed again later.)
+ -}
+commitIndex :: JournalLocked -> Git.Ref -> String -> [Git.Ref] -> Annex ()
+commitIndex jl branchref message parents = do
+	showStoringStateAction
+	commitIndex' jl branchref message message 0 parents
+commitIndex' :: JournalLocked -> Git.Ref -> String -> String -> Integer -> [Git.Ref] -> Annex ()
+commitIndex' jl branchref message basemessage retrynum parents = do
+	updateIndex jl branchref
+	cmode <- annexCommitMode <$> Annex.getGitConfig
+	committedref <- inRepo $ Git.Branch.commitAlways cmode message fullname parents
+	setIndexSha committedref
+	parentrefs <- commitparents <$> catObject committedref
+	when (racedetected branchref parentrefs) $
+		fixrace committedref parentrefs
+  where
+	-- look for "parent ref" lines and return the refs
+	commitparents = map (Git.Ref . snd) . filter isparent .
+		map (toassoc . L.toStrict) . L.split newline
+	newline = fromIntegral (ord '\n')
+	toassoc = separate' (== (fromIntegral (ord ' ')))
+	isparent (k,_) = k == "parent"
+		
+	{- The race can be detected by checking the commit's
+	 - parent, which will be the newly pushed branch,
+	 - instead of the expected ref that the index was updated to. -}
+	racedetected expectedref parentrefs
+		| expectedref `elem` parentrefs = False -- good parent
+		| otherwise = True -- race!
+		
+	{- To recover from the race, union merge the lost refs
+	 - into the index. -}
+	fixrace committedref lostrefs = do
+		showSideAction "recovering from race"
+		let retrynum' = retrynum+1
+		-- small sleep to let any activity that caused
+		-- the race settle down
+		liftIO $ threadDelay (100000 + fromInteger retrynum')
+		mergeIndex jl lostrefs
+		let racemessage = basemessage ++ " (recovery from race #" ++ show retrynum' ++ "; expected commit parent " ++ show branchref ++ " but found " ++ show lostrefs ++ " )"
+		commitIndex' jl committedref racemessage basemessage retrynum' [committedref]
+
+{- Lists all files on the branch. including ones in the journal
+ - that have not been committed yet. 
+ -
+ - There may be duplicates in the list, when the journal has files that
+ - have not been written to the branch yet.
+ - 
+ - In a read-only repository that has other git-annex branches that have
+ - not been merged in, returns Nothing, because it's not possible to
+ - efficiently handle that.
+ -}
+files :: Annex (Maybe ([RawFilePath], IO Bool))
+files = do
+	st <- update
+        if not (null (unmergedRefs st))
+		then return Nothing
+		else do
+			(bfs, cleanup) <- branchFiles
+			jfs <- journalledFiles
+			pjfs <- journalledFilesPrivate
+			-- ++ forces the content of the first list to be
+			-- buffered in memory, so use journalledFiles,
+			-- which should be much smaller most of the time.
+			-- branchFiles will stream as the list is consumed.
+			let l = jfs ++ pjfs ++ bfs
+			return (Just (l, cleanup))
+
+{- Lists all files currently in the journal, but not files in the private
+ - journal. -}
+journalledFiles :: Annex [RawFilePath]
+journalledFiles = getJournalledFilesStale gitAnnexJournalDir
+
+journalledFilesPrivate :: Annex [RawFilePath]
+journalledFilesPrivate = ifM privateUUIDsKnown
+	( getJournalledFilesStale gitAnnexPrivateJournalDir
+	, return []
+	)
+
+{- Files in the branch, not including any from journalled changes,
+ - and without updating the branch. -}
+branchFiles :: Annex ([RawFilePath], IO Bool)
+branchFiles = withIndex $ inRepo branchFiles'
+
+branchFiles' :: Git.Repo -> IO ([RawFilePath], IO Bool)
+branchFiles' = Git.Command.pipeNullSplit' $
+	lsTreeParams Git.LsTree.LsTreeRecursive (Git.LsTree.LsTreeLong False)
+		fullname
+		[Param "--name-only"]
+
+{- Populates the branch's index file with the current branch contents.
+ - 
+ - This is only done when the index doesn't yet exist, and the index 
+ - is used to build up changes to be committed to the branch, and merge
+ - in changes from other branches.
+ -}
+genIndex :: Git.Repo -> IO ()
+genIndex g = Git.UpdateIndex.streamUpdateIndex g
+	[Git.UpdateIndex.lsTree fullname g]
+
+{- Merges the specified refs into the index.
+ - Any changes staged in the index will be preserved. -}
+mergeIndex :: JournalLocked -> [Git.Ref] -> Annex ()
+mergeIndex jl branches = do
+	prepareModifyIndex jl
+	withHashObjectHandle $ \hashhandle ->
+		withCatFileHandle $ \ch ->
+			inRepo $ \g -> Git.UnionMerge.mergeIndex hashhandle ch g branches
+
+{- Removes any stale git lock file, to avoid git falling over when
+ - updating the index.
+ -
+ - Since all modifications of the index are performed inside this module,
+ - and only when the journal is locked, the fact that the journal has to be
+ - locked when this is called ensures that no other process is currently
+ - modifying the index. So any index.lock file must be stale, caused
+ - by git running when the system crashed, or the repository's disk was
+ - removed, etc.
+ -}
+prepareModifyIndex :: JournalLocked -> Annex ()
+prepareModifyIndex _jl = do
+	index <- fromRepo gitAnnexIndex
+	void $ liftIO $ tryIO $ R.removeLink (index <> ".lock")
+
+{- Runs an action using the branch's index file. -}
+withIndex :: Annex a -> Annex a
+withIndex = withIndex' False
+withIndex' :: Bool -> Annex a -> Annex a
+withIndex' bootstrapping a = withIndexFile AnnexIndexFile $ \f -> do
+	checkIndexOnce $ unlessM (liftIO $ doesFileExist f) $ do
+		unless bootstrapping create
+		createAnnexDirectory $ toRawFilePath $ takeDirectory f
+		unless bootstrapping $ inRepo genIndex
+	a
+
+{- Updates the branch's index to reflect the current contents of the branch.
+ - Any changes staged in the index will be preserved.
+ -
+ - Compares the ref stored in the lock file with the current
+ - ref of the branch to see if an update is needed.
+ -}
+updateIndex :: JournalLocked -> Git.Ref -> Annex ()
+updateIndex jl branchref = whenM (needUpdateIndex branchref) $
+	forceUpdateIndex jl branchref
+
+forceUpdateIndex :: JournalLocked -> Git.Ref -> Annex ()
+forceUpdateIndex jl branchref = do
+	withIndex $ mergeIndex jl [fullname]
+	setIndexSha branchref
+
+{- Checks if the index needs to be updated. -}
+needUpdateIndex :: Git.Ref -> Annex Bool
+needUpdateIndex branchref = do
+	f <- fromRawFilePath <$> fromRepo gitAnnexIndexStatus
+	committedref <- Git.Ref . firstLine' <$>
+		liftIO (catchDefaultIO mempty $ B.readFile f)
+	return (committedref /= branchref)
+
+{- Record that the branch's index has been updated to correspond to a
+ - given ref of the branch. -}
+setIndexSha :: Git.Ref -> Annex ()
+setIndexSha ref = do
+	f <- fromRepo gitAnnexIndexStatus
+	writeLogFile f $ fromRef ref ++ "\n"
+	runAnnexHook postUpdateAnnexHook
+
+{- Stages the journal into the index, and runs an action that
+ - commits the index to the branch. Note that the action is run
+ - inside withIndex so will automatically use the branch's index.
+ -
+ - Before staging, this removes any existing git index file lock.
+ - This is safe to do because stageJournal is the only thing that
+ - modifies this index file, and only one can run at a time, because
+ - the journal is locked. So any existing git index file lock must be
+ - stale, and the journal must contain any data that was in the process
+ - of being written to the index file when it crashed.
+ -}
+stageJournal :: JournalLocked -> Annex () -> Annex ()
+stageJournal jl commitindex = withIndex $ withOtherTmp $ \tmpdir -> do
+	prepareModifyIndex jl
+	g <- gitRepo
+	let dir = gitAnnexJournalDir g
+	(jlogf, jlogh) <- openjlog (fromRawFilePath tmpdir)
+	withHashObjectHandle $ \h ->
+		withJournalHandle gitAnnexJournalDir $ \jh ->
+			Git.UpdateIndex.streamUpdateIndex g
+				[genstream dir h jh jlogh]
+	commitindex
+	liftIO $ cleanup (fromRawFilePath dir) jlogh jlogf
+  where
+	genstream dir h jh jlogh streamer = readDirectory jh >>= \case
+		Nothing -> return ()
+		Just file -> do
+			let path = dir P.</> toRawFilePath file
+			unless (dirCruft file) $ whenM (isfile path) $ do
+				sha <- Git.HashObject.hashFile h path
+				hPutStrLn jlogh file
+				streamer $ Git.UpdateIndex.updateIndexLine
+					sha TreeFile (asTopFilePath $ fileJournal $ toRawFilePath file)
+			genstream dir h jh jlogh streamer
+	isfile file = isRegularFile <$> R.getFileStatus file
+	-- Clean up the staged files, as listed in the temp log file.
+	-- The temp file is used to avoid needing to buffer all the
+	-- filenames in memory.
+	cleanup dir jlogh jlogf = do
+		hFlush jlogh
+		hSeek jlogh AbsoluteSeek 0
+		stagedfs <- lines <$> hGetContents jlogh
+		mapM_ (removeFile . (dir </>)) stagedfs
+		hClose jlogh
+		removeWhenExistsWith (R.removeLink) (toRawFilePath jlogf)
+	openjlog tmpdir = liftIO $ openTmpFileIn tmpdir "jlog"
+
+getLocalTransitions :: Annex Transitions
+getLocalTransitions = 
+	parseTransitionsStrictly "local"
+		<$> getLocal transitionsLog
+
+{- This is run after the refs have been merged into the index,
+ - but before the result is committed to the branch.
+ - (Which is why it's passed the contents of the local branches's
+ - transition log before that merge took place.)
+ -
+ - When the refs contain transitions that have not yet been done locally,
+ - the transitions are performed on the index, and a new branch
+ - is created from the result.
+ -
+ - When there are transitions recorded locally that have not been done
+ - to the remote refs, the transitions are performed in the index,
+ - and committed to the existing branch. In this case, the untransitioned
+ - remote refs cannot be merged into the branch (since transitions
+ - throw away history), so they are added to the list of refs to ignore,
+ - to avoid re-merging content from them again.
+ -}
+handleTransitions :: JournalLocked -> Transitions -> [Git.Ref] -> Annex Bool
+handleTransitions jl localts refs = do
+	remotets <- mapM getRefTransitions refs
+	if all (localts ==) remotets
+		then return False
+		else do
+			let m = M.fromList (zip refs remotets)
+			let allts = combineTransitions (localts:remotets)
+			let (transitionedrefs, untransitionedrefs) =
+				partition (\r -> M.lookup r m == Just allts) refs
+			performTransitionsLocked jl allts (localts /= allts) transitionedrefs
+			ignoreRefs untransitionedrefs
+			return True
+
+{- Performs the specified transitions on the contents of the index file,
+ - commits it to the branch, or creates a new branch.
+ -}
+performTransitions :: Transitions -> Bool -> [Ref] -> Annex ()
+performTransitions ts neednewlocalbranch transitionedrefs = lockJournal $ \jl ->
+	performTransitionsLocked jl ts neednewlocalbranch transitionedrefs
+performTransitionsLocked :: JournalLocked -> Transitions -> Bool -> [Ref] -> Annex ()
+performTransitionsLocked jl ts neednewlocalbranch transitionedrefs = do
+	-- For simplicity & speed, we're going to use the Annex.Queue to
+	-- update the git-annex branch, while it usually holds changes
+	-- for the head branch. Flush any such changes.
+	Annex.Queue.flush
+	-- Stop any running git cat-files, to ensure that the
+	-- getStaged calls below use the current index, and not some older
+	-- one.
+	catFileStop
+	withIndex $ do
+		prepareModifyIndex jl
+		run $ mapMaybe getTransitionCalculator tlist
+		Annex.Queue.flush
+		if neednewlocalbranch
+			then do
+				cmode <- annexCommitMode <$> Annex.getGitConfig
+				committedref <- inRepo $ Git.Branch.commitAlways cmode message fullname transitionedrefs
+				setIndexSha committedref
+			else do
+				ref <- getBranch
+				commitIndex jl ref message (nub $ fullname:transitionedrefs)
+	regraftexports
+  where
+	message
+		| neednewlocalbranch && null transitionedrefs = "new branch for transition " ++ tdesc
+		| otherwise = "continuing transition " ++ tdesc
+	tdesc = show $ map describeTransition tlist
+	tlist = knownTransitionList ts
+
+	{- The changes to make to the branch are calculated and applied to
+	 - the branch directly, rather than going through the journal,
+	 - which would be innefficient. (And the journal is not designed
+	 - to hold changes to every file in the branch at once.)
+	 -
+	 - When a file in the branch is changed by transition code,
+	 - its new content is remembered and fed into the code for subsequent
+	 - transitions.
+	 -}
+	run [] = noop
+	run changers = do
+		config <- Annex.getGitConfig
+		trustmap <- calcTrustMap <$> getStaged trustLog
+		remoteconfigmap <- calcRemoteConfigMap <$> getStaged remoteLog
+		-- partially apply, improves performance
+		let changers' = map (\c -> c trustmap remoteconfigmap config) changers
+		(fs, cleanup) <- branchFiles
+		forM_ fs $ \f -> do
+			content <- getStaged f
+			apply changers' f content
+		liftIO $ void cleanup
+	
+	apply [] _ _ = return ()
+	apply (changer:rest) file content = case changer file content of
+		PreserveFile -> apply rest file content
+		ChangeFile builder -> do
+			let content' = toLazyByteString builder
+			if L.null content'
+				then do
+					Annex.Queue.addUpdateIndex
+						=<< inRepo (Git.UpdateIndex.unstageFile file)
+					-- File is deleted; can't run any other
+					-- transitions on it.
+					return ()
+				else do
+					sha <- hashBlob content'
+					Annex.Queue.addUpdateIndex $ Git.UpdateIndex.pureStreamer $
+						Git.UpdateIndex.updateIndexLine sha TreeFile (asTopFilePath file)
+					apply rest file content'
+
+	-- Trees mentioned in export.log were grafted into the old
+	-- git-annex branch to make sure they remain available. Re-graft
+	-- the trees into the new branch.
+	regraftexports = do
+		l <- exportedTreeishes . M.elems . parseExportLogMap
+			<$> getStaged exportLog
+		forM_ l $ \t ->
+			rememberTreeishLocked t (asTopFilePath exportTreeGraftPoint) jl
+
+checkBranchDifferences :: Git.Ref -> Annex ()
+checkBranchDifferences ref = do
+	theirdiffs <- allDifferences . parseDifferencesLog
+		<$> catFile ref differenceLog
+	mydiffs <- annexDifferences <$> Annex.getGitConfig
+	when (theirdiffs /= mydiffs) $
+		giveup "Remote repository is tuned in incompatible way; cannot be merged with local repository."
+
+ignoreRefs :: [Git.Sha] -> Annex ()
+ignoreRefs rs = do
+	old <- getIgnoredRefs
+	let s = S.unions [old, S.fromList rs]
+	f <- fromRepo gitAnnexIgnoredRefs
+	writeLogFile f $
+		unlines $ map fromRef $ S.elems s
+
+getIgnoredRefs :: Annex (S.Set Git.Sha)
+getIgnoredRefs = 
+	S.fromList . mapMaybe Git.Sha.extractSha . fileLines' <$> content
+  where
+	content = do
+		f <- fromRawFilePath <$> fromRepo gitAnnexIgnoredRefs
+		liftIO $ catchDefaultIO mempty $ B.readFile f
+
+addMergedRefs :: [(Git.Sha, Git.Branch)] -> Annex ()
+addMergedRefs [] = return ()
+addMergedRefs new = do
+	old <- getMergedRefs'
+	-- Keep only the newest sha for each branch.
+	let l = nubBy ((==) `on` snd) (new ++ old)
+	f <- fromRepo gitAnnexMergedRefs
+	writeLogFile f $
+		unlines $ map (\(s, b) -> fromRef s ++ '\t' : fromRef b) l
+
+getMergedRefs :: Annex (S.Set Git.Sha)
+getMergedRefs = S.fromList . map fst <$> getMergedRefs'
+
+getMergedRefs' :: Annex [(Git.Sha, Git.Branch)]
+getMergedRefs' = do
+	f <- fromRawFilePath <$> fromRepo gitAnnexMergedRefs
+	s <- liftIO $ catchDefaultIO mempty $ B.readFile f
+	return $ map parse $ fileLines' s
+  where
+	parse l = 
+		let (s, b) = separate' (== (fromIntegral (ord '\t'))) l
+		in (Ref s, Ref b)
+
+{- Grafts a treeish into the branch at the specified location,
+ - and then removes it. This ensures that the treeish won't get garbage
+ - collected, and will always be available as long as the git-annex branch
+ - is available.
+ -
+ - Returns the sha of the git commit made to the git-annex branch.
+ -}
+rememberTreeish :: Git.Ref -> TopFilePath -> Annex Git.Sha
+rememberTreeish treeish graftpoint = lockJournal $
+	rememberTreeishLocked treeish graftpoint
+rememberTreeishLocked :: Git.Ref -> TopFilePath -> JournalLocked -> Annex Git.Sha
+rememberTreeishLocked treeish graftpoint jl = do
+	branchref <- getBranch
+	updateIndex jl branchref
+	origtree <- fromMaybe (giveup "unable to determine git-annex branch tree") <$>
+		inRepo (Git.Ref.tree branchref)
+	addedt <- inRepo $ Git.Tree.graftTree treeish graftpoint origtree
+	cmode <- annexCommitMode <$> Annex.getGitConfig
+	c <- inRepo $ Git.Branch.commitTree cmode
+		["graft"] [branchref] addedt
+	c' <- inRepo $ Git.Branch.commitTree cmode
+		["graft cleanup"] [c] origtree
+	inRepo $ Git.Branch.update' fullname c'
+	-- The tree in c' is the same as the tree in branchref,
+	-- and the index was updated to that above, so it's safe to
+	-- say that the index contains c'.
+	setIndexSha c'
+	return c'
+
+{- Runs an action on the content of selected files from the branch.
+ - This is much faster than reading the content of each file in turn,
+ - because it lets git cat-file stream content without blocking.
+ -
+ - The action is passed a callback that it can repeatedly call to read
+ - the next file and its contents. When there are no more files, the
+ - callback will return Nothing.
+ -
+ - In some cases the callback may return the same file more than once,
+ - with different content. This happens rarely, only when the journal
+ - contains additional information, and the last version of the
+ - file it returns is the most current one.
+ -
+ - In a read-only repository that has other git-annex branches that have
+ - not been merged in, returns Nothing, because it's not possible to
+ - efficiently handle that.
+ -}
+overBranchFileContents
+	:: (RawFilePath -> Maybe v)
+	-> (Annex (Maybe (v, RawFilePath, Maybe L.ByteString)) -> Annex a)
+	-> Annex (Maybe a)
+overBranchFileContents select go = do
+	st <- update
+	if not (null (unmergedRefs st))
+		then return Nothing
+		else Just <$> overBranchFileContents' select go st
+
+overBranchFileContents'
+	:: (RawFilePath -> Maybe v)
+	-> (Annex (Maybe (v, RawFilePath, Maybe L.ByteString)) -> Annex a)
+	-> BranchState
+	-> Annex a
+overBranchFileContents' select go st = do
+	g <- Annex.gitRepo
+	(l, cleanup) <- inRepo $ Git.LsTree.lsTree
+		Git.LsTree.LsTreeRecursive
+		(Git.LsTree.LsTreeLong False)
+		fullname
+	let select' f = fmap (\v -> (v, f)) (select f)
+	buf <- liftIO newEmptyMVar
+	let go' reader = go $ liftIO reader >>= \case
+		Just ((v, f), content) -> do
+			content' <- checkjournal f content
+			return (Just (v, f, content'))
+		Nothing
+			| journalIgnorable st -> return Nothing
+			-- The journal did not get committed to the
+			-- branch, and may contain files that
+			-- are not present in the branch, which 
+			-- need to be provided to the action still.
+			-- This can cause the action to be run a
+			-- second time with a file it already ran on.
+			| otherwise -> liftIO (tryTakeMVar buf) >>= \case
+				Nothing -> do
+					jfs <- journalledFiles
+					pjfs <- journalledFilesPrivate
+					drain buf jfs pjfs
+				Just (jfs, pjfs) -> drain buf jfs pjfs
+	catObjectStreamLsTree l (select' . getTopFilePath . Git.LsTree.file) g go'
+		`finally` liftIO (void cleanup)
+  where
+	-- Check the journal, in case it did not get committed to the branch
+	checkjournal f branchcontent
+		| journalIgnorable st = return branchcontent
+		| otherwise = getJournalFileStale (GetPrivate True) f >>= return . \case
+			NoJournalledContent -> branchcontent
+			JournalledContent journalledcontent ->
+				Just journalledcontent
+			PossiblyStaleJournalledContent journalledcontent ->
+				Just (fromMaybe mempty branchcontent <> journalledcontent)
+				
+	drain buf fs pfs = case getnext fs pfs of
+		Just (v, f, fs', pfs') -> do
+			liftIO $ putMVar buf (fs', pfs')
+			content <- getJournalFileStale (GetPrivate True) f >>= \case
+				NoJournalledContent -> return Nothing
+				JournalledContent journalledcontent ->
+					return (Just journalledcontent)
+				PossiblyStaleJournalledContent journalledcontent -> do
+					-- This is expensive, but happens
+					-- only when there is a private
+					-- journal file.
+					content <- getRef fullname f
+					return (Just (content <> journalledcontent))
+			return (Just (v, f, content))
+		Nothing -> do
+			liftIO $ putMVar buf ([], [])
+			return Nothing
+	
+	getnext [] [] = Nothing
+	getnext (f:fs) pfs = case select f of
+		Nothing -> getnext fs pfs
+		Just v -> Just (v, f, fs, pfs)
+	getnext [] (pf:pfs) = case select pf of
+		Nothing -> getnext [] pfs
+		Just v -> Just (v, pf, [], pfs)
+
+{- Check if the git-annex branch has been updated from the oldtree.
+ - If so, returns the tuple of the old and new trees. -}
+updatedFromTree :: Git.Sha -> Annex (Maybe (Git.Sha, Git.Sha))
+updatedFromTree oldtree =
+	inRepo (Git.Ref.tree fullname) >>= \case
+		Just currtree | currtree /= oldtree ->
+			return $ Just (oldtree, currtree)
+		_ -> return Nothing
diff --git a/Annex/Branch/Transitions.hs b/Annex/Branch/Transitions.hs
new file mode 100644
index 0000000000..d7f45cb067
--- /dev/null
+++ b/Annex/Branch/Transitions.hs
@@ -0,0 +1,108 @@
+{- git-annex branch transitions
+ -
+ - Copyright 2013-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.Branch.Transitions (
+	getTransitionCalculator,
+	filterBranch,
+) where
+
+import Common
+import Logs
+import Logs.Transitions
+import qualified Logs.UUIDBased as UUIDBased
+import qualified Logs.Presence.Pure as Presence
+import qualified Logs.Chunk.Pure as Chunk
+import qualified Logs.MetaData.Pure as MetaData
+import qualified Logs.Remote.Pure as Remote
+import Logs.MapLog
+import Types.TrustLevel
+import Types.UUID
+import Types.MetaData
+import Types.Remote
+import Types.Transitions
+import Types.GitConfig (GitConfig)
+import Types.ProposedAccepted
+import Annex.SpecialRemote.Config
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import Data.ByteString.Builder
+
+getTransitionCalculator :: Transition -> Maybe (TrustMap -> M.Map UUID RemoteConfig -> GitConfig -> TransitionCalculator)
+getTransitionCalculator ForgetGitHistory = Nothing
+getTransitionCalculator ForgetDeadRemotes = Just dropDead
+
+-- Removes data about all dead repos.
+--
+-- The trust log is not changed, because other, unmerged clones
+-- may contain other data about the dead repos. So we need to remember
+-- which are dead to later remove that.
+--
+-- When the remote log contains a sameas-uuid pointing to a dead uuid,
+-- the uuid of that remote configuration is also effectively dead,
+-- though not in the trust log. There may be per-remote state stored using
+-- the latter uuid, that also needs to be removed. The sameas-uuid
+-- is not removed from the remote log, for the same reason the trust log
+-- is not changed.
+dropDead :: TrustMap -> M.Map UUID RemoteConfig -> GitConfig -> TransitionCalculator
+dropDead trustmap remoteconfigmap gc f content
+	| f == trustLog = PreserveFile
+	| f == remoteLog = ChangeFile $
+		Remote.buildRemoteConfigLog $
+			mapLogWithKey minimizesameasdead $
+				filterMapLog (notdead trustmap) id $
+					Remote.parseRemoteConfigLog content
+	| otherwise = filterBranch (notdead trustmap') gc f content
+  where
+	notdead m u = M.findWithDefault def u m /= DeadTrusted
+	trustmap' = trustmap `M.union`
+		M.map (const DeadTrusted) (M.filter sameasdead remoteconfigmap)
+	sameasdead cm =
+		case toUUID . fromProposedAccepted <$> M.lookup sameasUUIDField cm of
+			Nothing -> False
+			Just u' -> M.lookup u' trustmap == Just DeadTrusted
+	minimizesameasdead u l
+		| M.lookup u trustmap' == Just DeadTrusted =
+			l { UUIDBased.value = minimizesameasdead' (UUIDBased.value l) }
+		| otherwise = l
+	minimizesameasdead' c = M.restrictKeys c (S.singleton sameasUUIDField)
+
+filterBranch :: (UUID -> Bool) -> GitConfig -> TransitionCalculator
+filterBranch wantuuid gc f content = case getLogVariety gc f of
+	Just OldUUIDBasedLog -> ChangeFile $
+		UUIDBased.buildLogOld byteString $
+			filterMapLog wantuuid id $
+				UUIDBased.parseLogOld A.takeByteString content
+	Just NewUUIDBasedLog -> ChangeFile $
+		UUIDBased.buildLogNew byteString $
+			filterMapLog wantuuid id $
+				UUIDBased.parseLogNew A.takeByteString content
+	Just (ChunkLog _) -> ChangeFile $
+		Chunk.buildLog $ filterMapLog wantuuid fst $
+			Chunk.parseLog content
+	Just (LocationLog _) -> ChangeFile $ Presence.buildLog $
+		Presence.compactLog $
+			filterLocationLog wantuuid $
+				Presence.parseLog content
+	Just (UrlLog _) -> PreserveFile
+	Just RemoteMetaDataLog -> ChangeFile $ MetaData.buildLog $
+		filterRemoteMetaDataLog wantuuid $
+			MetaData.simplifyLog $ MetaData.parseLog content
+	Just OtherLog -> PreserveFile
+	Nothing -> PreserveFile
+
+filterMapLog :: (UUID -> Bool) -> (k -> UUID) -> MapLog k v -> MapLog k v
+filterMapLog wantuuid getuuid = filterMapLogWith (\k _v -> wantuuid (getuuid k))
+
+filterLocationLog :: (UUID -> Bool) -> [Presence.LogLine] -> [Presence.LogLine]
+filterLocationLog wantuuid = filter $
+	wantuuid . toUUID . Presence.fromLogInfo . Presence.info
+
+filterRemoteMetaDataLog :: (UUID -> Bool) -> MetaData.Log MetaData -> MetaData.Log MetaData
+filterRemoteMetaDataLog wantuuid = 
+	MetaData.filterOutEmpty . MetaData.filterRemoteMetaData wantuuid
diff --git a/Annex/BranchState.hs b/Annex/BranchState.hs
new file mode 100644
index 0000000000..95d860e467
--- /dev/null
+++ b/Annex/BranchState.hs
@@ -0,0 +1,134 @@
+{- git-annex branch state management
+ -
+ - Runtime state about the git-annex branch, and a small cache.
+ -
+ - Copyright 2011-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.BranchState where
+
+import Annex.Common
+import Types.BranchState
+import Types.Transitions
+import qualified Annex
+import Logs
+import qualified Git
+
+import qualified Data.ByteString.Lazy as L
+
+getState :: Annex BranchState
+getState = Annex.getState Annex.branchstate
+
+changeState :: (BranchState -> BranchState) -> Annex ()
+changeState changer = Annex.changeState $ \s -> 
+	s { Annex.branchstate = changer (Annex.branchstate s) }
+
+{- Runs an action to check that the index file exists, if it's not been
+ - checked before in this run of git-annex. -}
+checkIndexOnce :: Annex () -> Annex ()
+checkIndexOnce a = unlessM (indexChecked <$> getState) $ do
+	a
+	changeState $ \s -> s { indexChecked = True }
+
+data UpdateMade 
+	= UpdateMade
+		{ refsWereMerged :: Bool
+		, journalClean :: Bool
+		}
+	| UpdateFailedPermissions
+		{ refsUnmerged :: [Git.Sha]
+		, newTransitions :: [TransitionCalculator]
+		}
+
+{- Runs an action to update the branch, if it's not been updated before
+ - in this run of git-annex. 
+ -
+ - When interactive access is enabled, the journal is always checked when
+ - reading values from the branch, and so this does not need to update
+ - the branch.
+ -
+ - When the action leaves the journal clean, by staging anything that
+ - was in it, an optimisation is enabled: The journal does not need to
+ - be checked going forward, until new information gets written to it.
+ -
+ - When the action is unable to update the branch due to a permissions
+ - problem, the journal is still read every time.
+ -}
+runUpdateOnce :: Annex UpdateMade -> Annex BranchState
+runUpdateOnce update = do
+	st <- getState
+	if branchUpdated st || needInteractiveAccess st
+		then return st
+		else do
+			um <- update
+			let stf = case um of
+				UpdateMade {} -> \st' -> st'
+					{ branchUpdated = True
+					, journalIgnorable = journalClean um
+					}
+				UpdateFailedPermissions {} -> \st' -> st'
+					{ branchUpdated = True
+					, journalIgnorable = False
+					, unmergedRefs = refsUnmerged um
+					, unhandledTransitions = newTransitions um
+					, cachedFileContents = []
+					}
+			changeState stf
+			return (stf st)
+
+{- Avoids updating the branch. A useful optimisation when the branch
+ - is known to have not changed, or git-annex won't be relying on info
+ - queried from it being as up-to-date as possible. -}
+disableUpdate :: Annex ()
+disableUpdate = changeState $ \s -> s { branchUpdated = True }
+
+{- Called when a change is made to the journal. -}
+journalChanged :: Annex ()
+journalChanged = do
+	-- Optimisation: Typically journalIgnorable will already be True
+	-- (when one thing gets journalled, often other things do to),
+	-- so avoid an unnecessary write to the MVar that changeState
+	-- would do.
+	--
+	-- This assumes that another thread is not setting journalIgnorable
+	-- at the same time, but since runUpdateOnce is the only
+	-- thing that sets it, and it only runs once, that
+	-- should not happen.
+	st <- getState 
+	when (journalIgnorable st) $
+		changeState $ \st' -> st' { journalIgnorable = False }
+
+{- When git-annex is somehow interactive, eg in --batch mode,
+ - and needs to always notice changes made to the journal by other
+ - processes, this disables optimisations that avoid normally reading the
+ - journal.
+ -
+ - It also avoids using the cache, so changes committed by other processes
+ - will be seen.
+ -}
+enableInteractiveBranchAccess :: Annex ()
+enableInteractiveBranchAccess = changeState $ \s -> s 
+	{ needInteractiveAccess = True
+	, journalIgnorable = False
+	}
+
+setCache :: RawFilePath -> L.ByteString -> Annex ()
+setCache file content = changeState $ \s -> s
+	{ cachedFileContents = add (cachedFileContents s) }
+  where
+	add l
+		| length l < logFilesToCache = (file, content) : l
+		| otherwise = (file, content) : Prelude.init l
+
+getCache :: RawFilePath -> BranchState -> Maybe L.ByteString
+getCache file state = go (cachedFileContents state)
+  where
+	go [] = Nothing
+	go ((f,c):rest)
+		| f == file && not (needInteractiveAccess state) = Just c
+		| otherwise = go rest
+
+invalidateCache :: Annex ()
+invalidateCache = changeState $ \s -> s { cachedFileContents = [] }
diff --git a/Annex/CatFile.hs b/Annex/CatFile.hs
new file mode 100644
index 0000000000..35162b91a1
--- /dev/null
+++ b/Annex/CatFile.hs
@@ -0,0 +1,221 @@
+{- git cat-file interface, with handle automatically stored in the Annex monad
+ -
+ - Copyright 2011-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Annex.CatFile (
+	catFile,
+	catFileDetails,
+	catObject,
+	catTree,
+	catCommit,
+	catObjectDetails,
+	withCatFileHandle,
+	catObjectMetaData,
+	catFileStop,
+	catKey,
+	catKey',
+	catSymLinkTarget,
+	catKeyFile,
+	catKeyFileHEAD,
+	catKeyFileHidden,
+	catObjectMetaDataHidden,
+) where
+
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Map as M
+import System.PosixCompat.Types
+import Control.Concurrent.STM
+
+import Annex.Common
+import qualified Git
+import qualified Git.CatFile
+import qualified Annex
+import Git.Types
+import Git.FilePath
+import Git.Index
+import qualified Git.Ref
+import Annex.Link
+import Annex.CurrentBranch
+import Types.AdjustedBranch
+import Types.CatFileHandles
+import Utility.ResourcePool
+
+catFile :: Git.Branch -> RawFilePath -> Annex L.ByteString
+catFile branch file = withCatFileHandle $ \h -> 
+	liftIO $ Git.CatFile.catFile h branch file
+
+catFileDetails :: Git.Branch -> RawFilePath -> Annex (Maybe (L.ByteString, Sha, ObjectType))
+catFileDetails branch file = withCatFileHandle $ \h -> 
+	liftIO $ Git.CatFile.catFileDetails h branch file
+
+catObject :: Git.Ref -> Annex L.ByteString
+catObject ref = withCatFileHandle $ \h ->
+	liftIO $ Git.CatFile.catObject h ref
+
+catObjectMetaData :: Git.Ref -> Annex (Maybe (Sha, Integer, ObjectType))
+catObjectMetaData ref = withCatFileMetaDataHandle $ \h ->
+	liftIO $ Git.CatFile.catObjectMetaData h ref
+
+catTree :: Git.Ref -> Annex [(FilePath, FileMode)]
+catTree ref = withCatFileHandle $ \h -> 
+	liftIO $ Git.CatFile.catTree h ref
+
+catCommit :: Git.Ref -> Annex (Maybe Commit)
+catCommit ref = withCatFileHandle $ \h -> 
+	liftIO $ Git.CatFile.catCommit h ref
+
+catObjectDetails :: Git.Ref -> Annex (Maybe (L.ByteString, Sha, ObjectType))
+catObjectDetails ref = withCatFileHandle $ \h ->
+	liftIO $ Git.CatFile.catObjectDetails h ref
+
+{- There can be multiple index files, and a different cat-file is needed
+ - for each. That is selected by setting GIT_INDEX_FILE in the gitEnv
+ - before running this. -}
+withCatFileHandle :: (Git.CatFile.CatFileHandle -> Annex a) -> Annex a
+withCatFileHandle = withCatFileHandle'
+	Git.CatFile.catFileStart
+	catFileMap
+	(\v m -> v { catFileMap = m })
+
+withCatFileMetaDataHandle :: (Git.CatFile.CatFileMetaDataHandle -> Annex a) -> Annex a
+withCatFileMetaDataHandle = withCatFileHandle'
+	Git.CatFile.catFileMetaDataStart
+	catFileMetaDataMap
+	(\v m -> v { catFileMetaDataMap = m })
+
+withCatFileHandle'
+	:: (Repo -> IO hdl)
+	-> (CatMap -> M.Map FilePath (ResourcePool hdl))
+	-> (CatMap -> M.Map FilePath (ResourcePool hdl) -> CatMap)
+	-> (hdl -> Annex a)
+	-> Annex a
+withCatFileHandle' startcat get set a = do
+	cfh <- Annex.getState Annex.catfilehandles
+	indexfile <- fromMaybe "" . maybe Nothing (lookup indexEnv)
+		<$> fromRepo gitEnv
+	p <- case cfh of
+		CatFileHandlesNonConcurrent m -> case M.lookup indexfile (get m) of
+			Just p -> return p
+			Nothing -> do
+				p <- mkResourcePoolNonConcurrent startcatfile
+				let !m' = set m (M.insert indexfile p (get m))
+				Annex.changeState $ \s -> s
+					{ Annex.catfilehandles = CatFileHandlesNonConcurrent m' }
+				return p
+		CatFileHandlesPool tm -> do
+			m <- liftIO $ atomically $ takeTMVar tm
+			case M.lookup indexfile (get m) of
+				Just p -> do
+					liftIO $ atomically $ putTMVar tm m
+					return p
+				Nothing -> do
+					p  <- mkResourcePool maxCatFiles
+					let !m' = set m (M.insert indexfile p (get m))
+					liftIO $ atomically $ putTMVar tm m'
+					return p
+	withResourcePool p startcatfile a
+  where
+	startcatfile = inRepo startcat
+
+{- A lot of git cat-file processes are unlikely to improve concurrency,
+ - because a query to them takes only a little bit of CPU, and tends to be
+ - bottlenecked on disk. Also, they each open a number of files, so
+ - using too many might run out of file handles. So, only start a maximum
+ - of 2.
+ -
+ - Note that each different index file gets its own pool of cat-files;
+ - this is the size of each pool. In all, 4 times this many cat-files
+ - may end up running.
+ -}
+maxCatFiles :: Int
+maxCatFiles = 2
+
+{- Stops all running cat-files. Should only be run when it's known that
+ - nothing is using the handles, eg at shutdown. -}
+catFileStop :: Annex ()
+catFileStop = do
+	cfh <- Annex.getState Annex.catfilehandles
+	m <- case cfh of
+		CatFileHandlesNonConcurrent m -> do
+			Annex.changeState $ \s -> s { Annex.catfilehandles = CatFileHandlesNonConcurrent emptyCatMap }
+			return m
+		CatFileHandlesPool tm ->
+			liftIO $ atomically $ swapTMVar tm emptyCatMap
+	liftIO $ forM_ (M.elems (catFileMap m)) $ \p ->
+		freeResourcePool p Git.CatFile.catFileStop
+	liftIO $ forM_ (M.elems (catFileMetaDataMap m)) $ \p ->
+		freeResourcePool p Git.CatFile.catFileMetaDataStop
+
+{- From ref to a symlink or a pointer file, get the key. -}
+catKey :: Ref -> Annex (Maybe Key)
+catKey ref = catObjectMetaData ref >>= \case
+	Just (_, sz, _) -> catKey' ref sz
+	Nothing -> return Nothing
+
+catKey' :: Ref -> FileSize -> Annex (Maybe Key)
+catKey' ref sz
+	-- Avoid catting large files, that cannot be symlinks or
+	-- pointer files, which would require buffering their
+	-- content in memory, as well as a lot of IO.
+	| sz <= fromIntegral maxPointerSz =
+		parseLinkTargetOrPointer . L.toStrict <$> catObject ref
+catKey' _ _ = return Nothing
+
+{- Gets a symlink target. -}
+catSymLinkTarget :: Sha -> Annex RawFilePath
+catSymLinkTarget sha = fromInternalGitPath . L.toStrict <$> get
+  where
+	-- Avoid buffering the whole file content, which might be large.
+	-- 8192 is enough if it really is a symlink.
+	get = L.take 8192 <$> catObject sha
+
+{- From a file in the repository back to the key.
+ -
+ - Ideally, this should reflect the key that's staged in the index,
+ - not the key that's committed to HEAD. Unfortunately, git cat-file
+ - does not refresh the index file after it's started up, so things
+ - newly staged in the index won't show up. It does, however, notice
+ - when branches change.
+ -
+ - For command-line git-annex use, that doesn't matter. It's perfectly
+ - reasonable for things staged in the index after the currently running
+ - git-annex process to not be noticed by it. However, we do want to see
+ - what's in the index, since it may have uncommitted changes not in HEAD
+ -
+ - For the assistant, this is much more of a problem, since it commits
+ - files and then needs to be able to immediately look up their keys.
+ - OTOH, the assistant doesn't keep changes staged in the index for very
+ - long at all before committing them -- and it won't look at the keys
+ - of files until after committing them.
+ -
+ - So, this gets info from the index, unless running as a daemon.
+ -}
+catKeyFile :: RawFilePath -> Annex (Maybe Key)
+catKeyFile f = ifM (Annex.getState Annex.daemon)
+	( catKeyFileHEAD f
+	, maybe (pure Nothing) catKey =<< inRepo (Git.Ref.fileRef f)
+	)
+
+catKeyFileHEAD :: RawFilePath -> Annex (Maybe Key)
+catKeyFileHEAD f = maybe (pure Nothing) catKey
+	=<< inRepo (Git.Ref.fileFromRef Git.Ref.headRef f)
+
+{- Look in the original branch from whence an adjusted branch is based
+ - to find the file. But only when the adjustment hides some files. -}
+catKeyFileHidden :: RawFilePath -> CurrBranch -> Annex (Maybe Key) 
+catKeyFileHidden = hiddenCat catKey
+
+catObjectMetaDataHidden :: RawFilePath -> CurrBranch -> Annex (Maybe (Sha, Integer, ObjectType))
+catObjectMetaDataHidden = hiddenCat catObjectMetaData
+
+hiddenCat :: (Ref -> Annex (Maybe a)) -> RawFilePath -> CurrBranch -> Annex (Maybe a)
+hiddenCat a f (Just origbranch, Just adj)
+	| adjustmentHidesFiles adj = 
+		maybe (pure Nothing) a
+			=<< inRepo (Git.Ref.fileFromRef origbranch f)
+hiddenCat _ _ _ = return Nothing
diff --git a/Annex/ChangedRefs.hs b/Annex/ChangedRefs.hs
new file mode 100644
index 0000000000..7a9ce8a34f
--- /dev/null
+++ b/Annex/ChangedRefs.hs
@@ -0,0 +1,111 @@
+{- Waiting for changed git refs
+ -
+ - Copyright 2014-2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.ChangedRefs
+	( ChangedRefs(..)
+	, ChangedRefsHandle
+	, waitChangedRefs
+	, drainChangedRefs
+	, stopWatchingChangedRefs
+	, watchChangedRefs
+	) where
+
+import Annex.Common
+import Utility.DirWatcher
+import Utility.DirWatcher.Types
+import Utility.Directory.Create
+import qualified Git
+import Git.Sha
+import qualified Utility.SimpleProtocol as Proto
+
+import Control.Concurrent
+import Control.Concurrent.STM
+import Control.Concurrent.STM.TBMChan
+import qualified Data.ByteString as S
+import qualified System.FilePath.ByteString as P
+
+newtype ChangedRefs = ChangedRefs [Git.Ref]
+	deriving (Show)
+
+instance Proto.Serializable ChangedRefs where
+	serialize (ChangedRefs l) = unwords $ map Git.fromRef l
+	deserialize = Just . ChangedRefs . map (Git.Ref . encodeBS) . words
+
+data ChangedRefsHandle = ChangedRefsHandle DirWatcherHandle (TBMChan Git.Sha)
+
+-- | Wait for one or more git refs to change.
+--
+-- When possible, coalesce ref writes that occur closely together
+-- in time. Delay up to 0.05 seconds to get more ref writes.
+waitChangedRefs :: ChangedRefsHandle -> IO ChangedRefs
+waitChangedRefs (ChangedRefsHandle _ chan) =
+	atomically (readTBMChan chan) >>= \case
+		Nothing -> return $ ChangedRefs []
+		Just r -> do
+			threadDelay 50000
+			rs <- atomically $ loop []
+			return $ ChangedRefs (r:rs)
+  where
+	loop rs = tryReadTBMChan chan >>= \case
+		Just (Just r) -> loop (r:rs)
+		_ -> return rs
+
+-- | Remove any changes that might be buffered in the channel,
+-- without waiting for any new changes.
+drainChangedRefs :: ChangedRefsHandle -> IO ()
+drainChangedRefs (ChangedRefsHandle _ chan) = atomically go
+  where
+	go = tryReadTBMChan chan >>= \case
+		Just (Just _) -> go
+		_ -> return ()
+
+stopWatchingChangedRefs :: ChangedRefsHandle -> IO ()
+stopWatchingChangedRefs h@(ChangedRefsHandle wh chan) = do
+	stopWatchDir wh
+	atomically $ closeTBMChan chan
+	drainChangedRefs h
+
+watchChangedRefs :: Annex (Maybe ChangedRefsHandle)
+watchChangedRefs = do
+	-- This channel is used to accumulate notifications,
+	-- because the DirWatcher might have multiple threads that find
+	-- changes at the same time. It is bounded to allow a watcher
+	-- to be started once and reused, without too many changes being
+	-- buffered in memory.
+	chan <- liftIO $ newTBMChanIO 100
+	
+	g <- gitRepo
+	let gittop = Git.localGitDir g
+	let refdir = gittop P.</> "refs"
+	liftIO $ createDirectoryUnder [gittop] refdir
+
+	let notifyhook = Just $ notifyHook chan
+	let hooks = mkWatchHooks
+		{ addHook = notifyhook
+		, modifyHook = notifyhook
+		}
+
+	if canWatch
+		then do
+			h <- liftIO $ watchDir
+				(fromRawFilePath refdir)
+				(const False) True hooks id
+			return $ Just $ ChangedRefsHandle h chan
+		else return Nothing
+
+notifyHook :: TBMChan Git.Sha -> FilePath -> Maybe FileStatus -> IO ()
+notifyHook chan reffile _
+	| ".lock" `isSuffixOf` reffile = noop
+	| otherwise = void $ do
+		sha <- catchDefaultIO Nothing $
+			extractSha <$> S.readFile reffile
+		-- When the channel is full, there is probably no reader
+		-- running, or ref changes have been occurring very fast,
+		-- so it's ok to not write the change to it.
+		maybe noop (void . atomically . tryWriteTBMChan chan) sha
diff --git a/Annex/CheckAttr.hs b/Annex/CheckAttr.hs
new file mode 100644
index 0000000000..6ad8fafce6
--- /dev/null
+++ b/Annex/CheckAttr.hs
@@ -0,0 +1,74 @@
+{- git check-attr interface
+ -
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.CheckAttr (
+	annexAttrs,
+	checkAttr,
+	checkAttrs,
+	checkAttrStop,
+	mkConcurrentCheckAttrHandle,
+) where
+
+import Annex.Common
+import qualified Git.CheckAttr as Git
+import qualified Annex
+import Utility.ResourcePool
+import Types.Concurrency
+import Annex.Concurrent.Utility
+
+{- All gitattributes used by git-annex. -}
+annexAttrs :: [Git.Attr]
+annexAttrs =
+	[ "annex.backend"
+	, "annex.largefiles"
+	, "annex.numcopies"
+	, "annex.mincopies"
+	]
+
+checkAttr :: Git.Attr -> RawFilePath -> Annex String
+checkAttr attr file = withCheckAttrHandle $ \h -> do
+	r <- liftIO $ Git.checkAttr h attr file
+	if r == Git.unspecifiedAttr
+		then return ""
+		else return r
+
+checkAttrs :: [Git.Attr] -> RawFilePath -> Annex [String]
+checkAttrs attrs file = withCheckAttrHandle $ \h -> 
+	liftIO $ Git.checkAttrs h attrs file
+
+withCheckAttrHandle :: (Git.CheckAttrHandle -> Annex a) -> Annex a
+withCheckAttrHandle a = 
+	maybe mkpool go =<< Annex.getState Annex.checkattrhandle
+  where
+	go p = withResourcePool p start a
+	start = inRepo $ Git.checkAttrStart annexAttrs
+	mkpool = do
+		-- This only runs in non-concurrent code paths;
+		-- a concurrent pool is set up earlier when needed.
+		p <- mkResourcePoolNonConcurrent start
+		Annex.changeState $ \s -> s { Annex.checkattrhandle = Just p }
+		go p
+
+mkConcurrentCheckAttrHandle :: Concurrency -> Annex (ResourcePool Git.CheckAttrHandle)
+mkConcurrentCheckAttrHandle c =
+	Annex.getState Annex.checkattrhandle >>= \case
+		Just p@(ResourcePool {}) -> return p
+		_ -> mkResourcePool =<< liftIO (maxCheckAttrs c)
+
+{- git check-attr is typically CPU bound, and is not likely to be the main
+ - bottleneck for any command. So limit to the number of CPU cores, maximum,
+ - while respecting the -Jn value.
+ -}
+maxCheckAttrs :: Concurrency -> IO Int
+maxCheckAttrs = concurrencyUpToCpus
+
+checkAttrStop :: Annex ()
+checkAttrStop = maybe noop stop =<< Annex.getState Annex.checkattrhandle
+  where
+	stop p = do
+		liftIO $ freeResourcePool p Git.checkAttrStop
+		Annex.changeState $ \s -> s { Annex.checkattrhandle = Nothing }
diff --git a/Annex/CheckIgnore.hs b/Annex/CheckIgnore.hs
new file mode 100644
index 0000000000..d3c03f210a
--- /dev/null
+++ b/Annex/CheckIgnore.hs
@@ -0,0 +1,64 @@
+{- git check-ignore interface, with handle automatically stored in
+ - the Annex monad
+ -
+ - Copyright 2013-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.CheckIgnore (
+	CheckGitIgnore(..),
+	checkIgnored,
+	checkIgnoreStop,
+	mkConcurrentCheckIgnoreHandle,
+) where
+
+import Annex.Common
+import qualified Git.CheckIgnore as Git
+import qualified Annex
+import Utility.ResourcePool
+import Types.Concurrency
+import Annex.Concurrent.Utility
+
+newtype CheckGitIgnore = CheckGitIgnore Bool
+
+checkIgnored :: CheckGitIgnore -> RawFilePath -> Annex Bool
+checkIgnored (CheckGitIgnore False) _ = pure False
+checkIgnored (CheckGitIgnore True) file =
+	ifM (Annex.getRead Annex.force)
+		( pure False
+		, withCheckIgnoreHandle $ \h -> liftIO $ Git.checkIgnored h file
+		)
+
+withCheckIgnoreHandle :: (Git.CheckIgnoreHandle -> Annex a) -> Annex a
+withCheckIgnoreHandle a =
+	maybe mkpool go =<< Annex.getState Annex.checkignorehandle
+  where
+	go p = withResourcePool p start a
+	start = inRepo Git.checkIgnoreStart
+	mkpool = do
+		-- This only runs in non-concurrent code paths;
+		-- a concurrent pool is set up earlier when needed.
+		p <- mkResourcePoolNonConcurrent start
+		Annex.changeState $ \s -> s { Annex.checkignorehandle = Just p }
+		go p
+
+mkConcurrentCheckIgnoreHandle :: Concurrency -> Annex (ResourcePool Git.CheckIgnoreHandle)
+mkConcurrentCheckIgnoreHandle c =
+	Annex.getState Annex.checkignorehandle >>= \case
+		Just p@(ResourcePool {}) -> return p
+		_ -> mkResourcePool =<< liftIO (maxCheckIgnores c)
+
+{- git check-ignore is typically CPU bound, and is not likely to be the main
+ - bottleneck for any command. So limit to the number of CPU cores, maximum,
+ - while respecting the -Jn value.
+ -}
+maxCheckIgnores :: Concurrency -> IO Int
+maxCheckIgnores = concurrencyUpToCpus
+
+checkIgnoreStop :: Annex ()
+checkIgnoreStop = maybe noop stop =<< Annex.getState Annex.checkignorehandle
+  where
+	stop p = do
+		liftIO $ freeResourcePool p Git.checkIgnoreStop
+		Annex.changeState $ \s -> s { Annex.checkignorehandle = Nothing }
diff --git a/Annex/Common.hs b/Annex/Common.hs
new file mode 100644
index 0000000000..0fc602205a
--- /dev/null
+++ b/Annex/Common.hs
@@ -0,0 +1,16 @@
+{-# LANGUAGE CPP #-}
+
+module Annex.Common (module X) where
+
+import Common as X
+import Types as X
+import Key as X
+import Types.UUID as X
+import Annex as X (gitRepo, inRepo, fromRepo, calcRepo, calcRepo')
+import Annex.Locations as X
+import Annex.Debug as X (fastDebug, debug)
+import Messages as X
+import Git.Quote as X
+#ifndef mingw32_HOST_OS
+import System.Posix.IO as X hiding (createPipe, append)
+#endif
diff --git a/Annex/Concurrent.hs b/Annex/Concurrent.hs
new file mode 100644
index 0000000000..72ea40318f
--- /dev/null
+++ b/Annex/Concurrent.hs
@@ -0,0 +1,113 @@
+{- git-annex concurrent state
+ -
+ - Copyright 2015-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.Concurrent (
+	module Annex.Concurrent,
+	module Annex.Concurrent.Utility
+) where
+
+import Annex
+import Annex.Common
+import Annex.Concurrent.Utility
+import qualified Annex.Queue
+import Types.Concurrency
+import Types.CatFileHandles
+import Annex.CatFile
+import Annex.CheckAttr
+import Annex.HashObject
+import Annex.CheckIgnore
+
+import qualified Data.Map as M
+
+setConcurrency :: ConcurrencySetting -> Annex ()
+setConcurrency (ConcurrencyCmdLine s) = setConcurrency' s ConcurrencyCmdLine
+setConcurrency (ConcurrencyGitConfig s) = setConcurrency' s ConcurrencyGitConfig
+
+setConcurrency' :: Concurrency -> (Concurrency -> ConcurrencySetting) -> Annex ()
+setConcurrency' NonConcurrent f = 
+	Annex.changeState $ \s -> s 
+		{ Annex.concurrency = f NonConcurrent
+		}
+setConcurrency' c f = do
+	oldc <- Annex.getState Annex.concurrency
+	case oldc of
+		ConcurrencyCmdLine NonConcurrent -> fromnonconcurrent
+		ConcurrencyGitConfig NonConcurrent -> fromnonconcurrent
+		_
+			| oldc == newc -> return ()
+			| otherwise ->
+				Annex.changeState $ \s -> s
+					{ Annex.concurrency = newc
+					}
+  where
+	newc = f c
+	fromnonconcurrent = do
+		catFileStop
+		checkAttrStop
+		hashObjectStop
+		checkIgnoreStop
+		cfh <- liftIO catFileHandlesPool
+		cah <- mkConcurrentCheckAttrHandle c
+		hoh <- mkConcurrentHashObjectHandle c
+		cih <- mkConcurrentCheckIgnoreHandle c
+		Annex.changeState $ \s -> s
+			{ Annex.concurrency = newc
+			, Annex.catfilehandles = cfh
+			, Annex.checkattrhandle = Just cah
+			, Annex.hashobjecthandle = Just hoh
+			, Annex.checkignorehandle = Just cih
+			}
+
+{- Allows forking off a thread that uses a copy of the current AnnexState
+ - to run an Annex action.
+ -
+ - The returned IO action can be used to start the thread.
+ - It returns an Annex action that must be run in the original 
+ - calling context to merge the forked AnnexState back into the
+ - current AnnexState.
+ -}
+forkState :: Annex a -> Annex (IO (Annex a))
+forkState a = do
+	rd <- Annex.getRead id
+	st <- dupState
+	return $ do
+		(ret, (newst, _rd)) <- run (st, rd) a
+		return $ do
+			mergeState newst
+			return ret
+
+{- Returns a copy of the current AnnexState that is safe to be
+ - used when forking off a thread. 
+ -
+ - After an Annex action is run using this AnnexState, it
+ - should be merged back into the current Annex's state,
+ - by calling mergeState.
+ -}
+dupState :: Annex AnnexState
+dupState = do
+	st <- Annex.getState id
+	-- Make sure that concurrency is enabled, if it was not already,
+	-- so the concurrency-safe resource pools are set up.
+	st' <- case getConcurrency' (Annex.concurrency st) of
+		NonConcurrent -> do
+			setConcurrency (ConcurrencyCmdLine (Concurrent 1))
+			Annex.getState id
+		_ -> return st
+	return $ st'
+		-- each thread has its own repoqueue
+		{ Annex.repoqueue = Nothing
+		-- no errors from this thread yet
+		, Annex.errcounter = 0
+		}
+
+{- Merges the passed AnnexState into the current Annex state. -}
+mergeState :: AnnexState -> Annex ()
+mergeState st = do
+	forM_ (M.toList $ Annex.cleanupactions st) $
+		uncurry addCleanupAction
+	Annex.Queue.mergeFrom st
+	changeState $ \s -> s { errcounter = errcounter s + errcounter st }
diff --git a/Annex/Concurrent/Utility.hs b/Annex/Concurrent/Utility.hs
new file mode 100644
index 0000000000..2810f6da6b
--- /dev/null
+++ b/Annex/Concurrent/Utility.hs
@@ -0,0 +1,31 @@
+{- git-annex concurrency utilities
+ -
+ - Copyright 2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.Concurrent.Utility where
+
+import Annex
+import Types.Concurrency
+
+import GHC.Conc
+
+getConcurrency :: Annex Concurrency
+getConcurrency = getConcurrency' <$> getState concurrency
+
+getConcurrency' :: ConcurrencySetting -> Concurrency
+getConcurrency' (ConcurrencyCmdLine c) = c
+getConcurrency' (ConcurrencyGitConfig c) = c
+
+{- Honor the requested level of concurrency, but only up to the number of
+ - CPU cores. Useful for things that are known to be CPU bound. -}
+concurrencyUpToCpus :: Concurrency -> IO Int
+concurrencyUpToCpus c = do
+	let cn = case c of
+		Concurrent n -> n
+		NonConcurrent -> 1
+		ConcurrentPerCpu -> 1
+	pn <- getNumProcessors
+	return (min cn pn)
diff --git a/Annex/Content.hs b/Annex/Content.hs
new file mode 100644
index 0000000000..693c1de2da
--- /dev/null
+++ b/Annex/Content.hs
@@ -0,0 +1,949 @@
+{- git-annex file content managing
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Content (
+	inAnnex,
+	inAnnex',
+	inAnnexSafe,
+	inAnnexCheck,
+	objectFileExists,
+	lockContentShared,
+	lockContentForRemoval,
+	ContentRemovalLock,
+	RetrievalSecurityPolicy(..),
+	getViaTmp,
+	getViaTmpFromDisk,
+	verificationOfContentFailed,
+	checkDiskSpaceToGet,
+	checkSecureHashes,
+	prepTmp,
+	withTmp,
+	checkDiskSpace,
+	needMoreDiskSpace,
+	moveAnnex,
+	populatePointerFile,
+	linkToAnnex,
+	linkFromAnnex,
+	linkFromAnnex',
+	LinkAnnexResult(..),
+	unlinkAnnex,
+	checkedCopyFile,
+	linkOrCopy,
+	linkOrCopy',
+	sendAnnex,
+	prepSendAnnex,
+	prepSendAnnex',
+	removeAnnex,
+	moveBad,
+	KeyLocation(..),
+	listKeys,
+	listKeys',
+	saveState,
+	downloadUrl,
+	preseedTmp,
+	dirKeys,
+	withObjectLoc,
+	staleKeysPrune,
+	pruneTmpWorkDirBefore,
+	isUnmodified,
+	isUnmodifiedCheap,
+	verifyKeyContentPostRetrieval,
+	verifyKeyContent,
+	VerifyConfig,
+	VerifyConfigA(..),
+	Verification(..),
+	unVerified,
+	withTmpWorkDir,
+	KeyStatus(..),
+	isKeyUnlockedThin,
+	getKeyStatus,
+	getKeyFileStatus,
+	cleanObjectDirs,
+	contentSize,
+) where
+
+import System.IO.Unsafe (unsafeInterleaveIO)
+import qualified Data.Set as S
+
+import Annex.Common
+import Annex.Content.Presence
+import Annex.Content.LowLevel
+import Annex.Content.PointerFile
+import Annex.Verify
+import qualified Git
+import qualified Annex
+import qualified Annex.Queue
+import qualified Annex.Branch
+import qualified Annex.Url as Url
+import qualified Backend
+import qualified Database.Keys
+import Git.FilePath
+import Annex.Perms
+import Annex.Link
+import Annex.LockPool
+import Annex.UUID
+import Annex.InodeSentinal
+import Annex.ReplaceFile
+import Annex.AdjustedBranch (adjustedBranchRefresh)
+import Annex.DirHashes
+import Messages.Progress
+import Types.Remote (RetrievalSecurityPolicy(..), VerifyConfigA(..))
+import Types.NumCopies
+import Types.Key
+import Types.Transfer
+import Logs.Transfer
+import Logs.Location
+import Utility.InodeCache
+import Utility.CopyFile
+import Utility.Metered
+#ifndef mingw32_HOST_OS
+import Utility.FileMode
+#endif
+import qualified Utility.RawFilePath as R
+
+import qualified System.FilePath.ByteString as P
+import System.PosixCompat.Files (isSymbolicLink, linkCount)
+
+{- Prevents the content from being removed while the action is running.
+ - Uses a shared lock.
+ -
+ - If locking fails, or the content is not present, throws an exception
+ - rather than running the action.
+ -}
+lockContentShared :: Key -> (VerifiedCopy -> Annex a) -> Annex a
+lockContentShared key a = lockContentUsing lock key notpresent $
+	ifM (inAnnex key)
+		( do
+			u <- getUUID
+			withVerifiedCopy LockedCopy u (return True) a
+		, notpresent
+		)
+  where
+	notpresent = giveup $ "failed to lock content: not present"
+#ifndef mingw32_HOST_OS
+	lock _ (Just lockfile) = 
+		( posixLocker tryLockShared lockfile
+		, Just (posixLocker tryLockExclusive lockfile)
+		)
+	lock contentfile Nothing =
+		( tryLockShared Nothing contentfile
+		, Nothing
+		)
+#else
+	lock = winLocker lockShared
+#endif
+
+{- Exclusively locks content, while performing an action that
+ - might remove it.
+ -
+ - If locking fails, throws an exception rather than running the action.
+ -
+ - When the content file itself is used as the lock file, 
+ - and locking fails because the the content is not present, runs the
+ - fallback action instead. However, the content is not guaranteed to be
+ - present when this succeeds.
+ -}
+lockContentForRemoval :: Key -> Annex a -> (ContentRemovalLock -> Annex a) -> Annex a
+lockContentForRemoval key fallback a = lockContentUsing lock key fallback $ 
+	a (ContentRemovalLock key)
+  where
+#ifndef mingw32_HOST_OS
+	lock _ (Just lockfile) = (posixLocker tryLockExclusive lockfile, Nothing)
+	{- No lock file, so the content file itself is locked. 
+	 - Since content files are stored with the write bit
+	 - disabled, have to fiddle with permissions to open
+	 - for an exclusive lock. -}
+	lock contentfile Nothing =
+		let lck = bracket_
+			(thawContent contentfile)
+			(freezeContent contentfile)
+			(tryLockExclusive Nothing contentfile)
+		in (lck, Nothing)
+#else
+	lock = winLocker lockExclusive
+#endif
+
+{- Passed the object content file, and maybe a separate lock file to use,
+ - when the content file itself should not be locked. -}
+type ContentLocker = RawFilePath -> Maybe LockFile -> (Annex (Maybe LockHandle), Maybe (Annex (Maybe LockHandle)))
+
+#ifndef mingw32_HOST_OS
+posixLocker :: (Maybe ModeSetter -> LockFile -> Annex (Maybe LockHandle)) -> LockFile -> Annex (Maybe LockHandle)
+posixLocker takelock lockfile = do
+	mode <- annexFileMode
+	modifyContentDirWhenExists lockfile $
+		takelock (Just mode) lockfile
+#else
+winLocker :: (LockFile -> IO (Maybe LockHandle)) -> ContentLocker
+winLocker takelock _ (Just lockfile) = 
+	let lck = do
+		modifyContentDir lockfile $
+			void $ liftIO $ tryIO $
+				writeFile (fromRawFilePath lockfile) ""
+		liftIO $ takelock lockfile
+	in (lck, Nothing)
+-- never reached; windows always uses a separate lock file
+winLocker _ _ Nothing = (return Nothing, Nothing)
+#endif
+
+{- The fallback action is run if the ContentLocker throws an IO exception
+ - and the content is not present. It's not guaranteed to always run when
+ - the content is not present, because the content file is not always
+ - the file that is locked. -}
+lockContentUsing :: ContentLocker -> Key -> Annex a -> Annex a -> Annex a
+lockContentUsing contentlocker key fallback a = withContentLockFile key $ \mlockfile -> do
+	contentfile <- calcRepo (gitAnnexLocation key)
+	let (locker, sharedtoexclusive) = contentlocker contentfile mlockfile
+	bracket
+		(lock locker mlockfile)
+		(either (const noop) (unlock sharedtoexclusive mlockfile))
+		go
+  where
+	alreadylocked = giveup "content is locked"
+	failedtolock e = giveup $ "failed to lock content: " ++ show e
+
+#ifndef mingw32_HOST_OS
+	lock locker mlockfile =
+#else
+	lock locker _mlockfile =
+#endif
+		tryIO $ locker >>= \case
+			Nothing -> alreadylocked
+			Just h ->
+#ifndef mingw32_HOST_OS
+				case mlockfile of
+					Nothing -> return h
+					Just lockfile ->
+						ifM (checkSaneLock lockfile h)
+							( return h
+							, alreadylocked
+							)
+#else
+				return h
+#endif
+	
+	go (Right _) = a
+	go (Left e) = ifM (inAnnex key)
+		( failedtolock e
+		, fallback 
+		)
+
+#ifndef mingw32_HOST_OS
+	unlock sharedtoexclusive mlockfile lck = case (sharedtoexclusive, mlockfile) of
+		-- We have a shared lock, so other processes may also
+		-- have shared locks of the same lock file. To avoid
+		-- deleting the lock file when there are other shared
+		-- locks, try to convert to an exclusive lock, and only
+		-- delete it when that succeeds.
+		--
+		-- Since other processes might be doing the same,
+		-- a race is possible where we open the lock file
+		-- and then another process takes the exclusive lock and
+		-- deletes it, leaving us with an invalid lock. To avoid 
+		-- that race, checkSaneLock is used after taking the lock
+		-- here, and above.
+		(Just exclusivelocker, Just lockfile) -> do
+			liftIO $ dropLock lck
+			exclusivelocker >>= \case
+				Nothing -> return ()
+				Just h -> do
+					whenM (checkSaneLock lockfile h) $ do
+						cleanuplockfile lockfile
+					liftIO $ dropLock h
+		-- We have an exclusive lock, so no other process can have
+		-- the lock file locked, and so it's safe to remove it, as 
+		-- long as all lock attempts use checkSaneLock.
+		_ -> do
+			maybe noop cleanuplockfile mlockfile
+			liftIO $ dropLock lck
+#else
+	unlock _ mlockfile lck = do
+		-- Can't delete a locked file on Windows,
+		-- so close our lock first. If there are other shared
+		-- locks, they will prevent the file deletion from
+		-- happening.
+		liftIO $ dropLock lck
+		maybe noop cleanuplockfile mlockfile
+#endif
+
+	cleanuplockfile lockfile = void $ tryNonAsync $ do
+		thawContentDir lockfile
+		liftIO $ removeWhenExistsWith R.removeLink lockfile
+		cleanObjectDirs lockfile
+
+{- Runs an action, passing it the temp file to get,
+ - and if the action succeeds, verifies the file matches
+ - the key and moves the file into the annex as a key's content. -}
+getViaTmp :: RetrievalSecurityPolicy -> VerifyConfig -> Key -> AssociatedFile -> Maybe FileSize -> (RawFilePath -> Annex (Bool, Verification)) -> Annex Bool
+getViaTmp rsp v key af sz action =
+	checkDiskSpaceToGet key sz False $
+		getViaTmpFromDisk rsp v key af action
+
+{- Like getViaTmp, but does not check that there is enough disk space
+ - for the incoming key. For use when the key content is already on disk
+ - and not being copied into place. -}
+getViaTmpFromDisk :: RetrievalSecurityPolicy -> VerifyConfig -> Key -> AssociatedFile -> (RawFilePath -> Annex (Bool, Verification)) -> Annex Bool
+getViaTmpFromDisk rsp v key af action = checkallowed $ do
+	tmpfile <- prepTmp key
+	resuming <- liftIO $ R.doesPathExist tmpfile
+	(ok, verification) <- action tmpfile
+	-- When the temp file already had content, we don't know if
+	-- that content is good or not, so only trust if it the action
+	-- Verified it in passing. Otherwise, force verification even
+	-- if the VerifyConfig normally disables it.
+	let verification' = if resuming
+		then case verification of
+			Verified -> Verified
+			_ -> MustVerify
+		else verification
+	if ok
+		then ifM (verifyKeyContentPostRetrieval rsp v verification' key tmpfile)
+			( pruneTmpWorkDirBefore tmpfile (moveAnnex key af)
+			, do
+				verificationOfContentFailed tmpfile
+				return False
+			)
+		-- On transfer failure, the tmp file is left behind, in case
+		-- caller wants to resume its transfer
+		else return False
+  where
+	-- Avoid running the action to get the content when the
+	-- RetrievalSecurityPolicy would cause verification to always fail.
+	checkallowed a = case rsp of
+		RetrievalAllKeysSecure -> a
+		RetrievalVerifiableKeysSecure -> ifM (isVerifiable key)
+			( a
+			, ifM (annexAllowUnverifiedDownloads <$> Annex.getGitConfig)
+				( a
+				, warnUnverifiableInsecure key >> return False
+				)
+			)
+
+{- When the content of a file that was successfully transferred from a remote
+ - fails to verify, use this to display a message so the user knows why it
+ - failed, and to clean up the corrupted content.
+ -
+ - The bad content is not retained, because the transfer of it succeeded.
+ - So it's not incomplete and a resume using it will not work. While
+ - some protocols like rsync could recover such a bad content file,
+ - they are assumed to not write out bad data to a file in the first place.
+ - Most protocols, including the P2P protocol, pick up downloads where they
+ - left off, and so if the bad content were not deleted, repeated downloads
+ - would continue to fail.
+ -}
+verificationOfContentFailed :: RawFilePath -> Annex ()
+verificationOfContentFailed tmpfile = do
+	warning "Verification of content failed"
+	pruneTmpWorkDirBefore tmpfile
+		(liftIO . removeWhenExistsWith R.removeLink)
+
+{- Checks if there is enough free disk space to download a key
+ - to its temp file.
+ -
+ - When the temp file already exists, count the space it is using as
+ - free, since the download will overwrite it or resume.
+ -
+ - Wen there's enough free space, runs the download action.
+ -}
+checkDiskSpaceToGet :: Key -> Maybe FileSize -> a -> Annex a -> Annex a
+checkDiskSpaceToGet key sz unabletoget getkey = do
+	tmp <- fromRepo (gitAnnexTmpObjectLocation key)
+	e <- liftIO $ doesFileExist (fromRawFilePath tmp)
+	alreadythere <- liftIO $ if e
+		then getFileSize tmp
+		else return 0
+	ifM (checkDiskSpace sz Nothing key alreadythere True)
+		( do
+			-- The tmp file may not have been left writable
+			when e $ thawContent tmp
+			getkey
+		, return unabletoget
+		)
+
+prepTmp :: Key -> Annex RawFilePath
+prepTmp key = do
+	tmp <- fromRepo $ gitAnnexTmpObjectLocation key
+	createAnnexDirectory (parentDir tmp)
+	return tmp
+
+{- Prepares a temp file for a key, runs an action on it, and cleans up
+ - the temp file. If the action throws an exception, the temp file is
+ - left behind, which allows for resuming.
+ -}
+withTmp :: Key -> (RawFilePath -> Annex a) -> Annex a
+withTmp key action = do
+	tmp <- prepTmp key
+	res <- action tmp
+	pruneTmpWorkDirBefore tmp (liftIO . removeWhenExistsWith R.removeLink)
+	return res
+
+{- Moves a key's content into .git/annex/objects/
+ -
+ - When a key has associated pointer files, the object is hard
+ - linked (or copied) to the files, and the object file is left thawed.
+ -
+ - What if the key there already has content? This could happen for
+ - various reasons; perhaps the same content is being annexed again.
+ - Perhaps there has been a hash collision generating the keys.
+ -
+ - The current strategy is to assume that in this case it's safe to delete
+ - one of the two copies of the content; and the one already in the annex
+ - is left there, assuming it's the original, canonical copy.
+ -
+ - I considered being more paranoid, and checking that both files had
+ - the same content. Decided against it because A) users explicitly choose
+ - a backend based on its hashing properties and so if they're dealing
+ - with colliding files it's their own fault and B) adding such a check
+ - would not catch all cases of colliding keys. For example, perhaps 
+ - a remote has a key; if it's then added again with different content then
+ - the overall system now has two different pieces of content for that
+ - key, and one of them will probably get deleted later. So, adding the
+ - check here would only raise expectations that git-annex cannot truly
+ - meet.
+ -
+ - May return false, when a particular variety of key is not being
+ - accepted into the repository. Will display a warning message in this
+ - case. May also throw exceptions in some cases.
+ -}
+moveAnnex :: Key -> AssociatedFile -> RawFilePath -> Annex Bool
+moveAnnex key af src = ifM (checkSecureHashes' key)
+	( do
+		withObjectLoc key storeobject
+		return True
+	, return False
+	)
+  where
+	storeobject dest = ifM (liftIO $ R.doesPathExist dest)
+		( alreadyhave
+		, adjustedBranchRefresh af $ modifyContentDir dest $ do
+			liftIO $ moveFile src dest
+			-- Freeze the object file now that it is in place.
+			-- Waiting until now to freeze it allows for freeze
+			-- hooks that prevent moving the file.
+			freezeContent dest
+			g <- Annex.gitRepo 
+			fs <- map (`fromTopFilePath` g)
+				<$> Database.Keys.getAssociatedFiles key
+			unless (null fs) $ do
+				destic <- withTSDelta $
+					liftIO . genInodeCache dest
+				ics <- mapM (populatePointerFile (Restage True) key dest) fs
+				Database.Keys.addInodeCaches key
+					(catMaybes (destic:ics))
+		)
+	alreadyhave = liftIO $ R.removeLink src
+
+checkSecureHashes :: Key -> Annex (Maybe String)
+checkSecureHashes key = ifM (Backend.isCryptographicallySecureKey key)
+	( return Nothing
+	, ifM (annexSecureHashesOnly <$> Annex.getGitConfig)
+		( return $ Just $ "annex.securehashesonly blocked adding " ++ decodeBS (formatKeyVariety (fromKey keyVariety key)) ++ " key"
+		, return Nothing
+		)
+	)
+
+checkSecureHashes' :: Key -> Annex Bool
+checkSecureHashes' key = checkSecureHashes key >>= \case
+	Nothing -> return True
+	Just msg -> do
+		warning $ UnquotedString $ msg ++ " to annex objects"
+		return False
+
+data LinkAnnexResult = LinkAnnexOk | LinkAnnexFailed | LinkAnnexNoop
+	deriving (Eq)
+
+{- Populates the annex object file by hard linking or copying a source
+ - file to it. -}
+linkToAnnex :: Key -> RawFilePath -> Maybe InodeCache -> Annex LinkAnnexResult
+linkToAnnex key src srcic = ifM (checkSecureHashes' key)
+	( do
+		dest <- calcRepo (gitAnnexLocation key)
+		modifyContentDir dest $ linkAnnex To key src srcic dest Nothing
+	, return LinkAnnexFailed
+	)
+
+{- Makes a destination file be a link or copy from the annex object.
+ -
+ - linkAnnex stats the file after copying it to add to the inode
+ - cache. But dest may be a file in the working tree, which could
+ - get modified immediately after being populated. To avoid such a
+ - race, call linkAnnex on a temporary file and move it into place
+ - afterwards. Note that a consequence of this is that, if the file
+ - already exists, it will be overwritten.
+ -}
+linkFromAnnex :: Key -> RawFilePath -> Maybe FileMode -> Annex LinkAnnexResult
+linkFromAnnex key dest destmode =
+	replaceFile' (const noop) (fromRawFilePath dest) (== LinkAnnexOk) $ \tmp ->
+		linkFromAnnex' key tmp destmode
+
+{- This is only safe to use when dest is not a worktree file. -}
+linkFromAnnex' :: Key -> RawFilePath -> Maybe FileMode -> Annex LinkAnnexResult
+linkFromAnnex' key dest destmode = do
+	src <- calcRepo (gitAnnexLocation key)
+	srcic <- withTSDelta (liftIO . genInodeCache src)
+	linkAnnex From key src srcic dest destmode
+
+data FromTo = From | To
+
+{- Hard links or copies from or to the annex object location. 
+ - Updates inode cache.
+ -
+ - Freezes or thaws the destination appropriately.
+ -
+ - When a hard link is made, the annex object necessarily has to be thawed
+ - too. So, adding an object to the annex with a hard link can prevent
+ - losing the content if the source file is deleted, but does not
+ - guard against modifications.
+ -
+ - Nothing is done if the destination file already exists.
+ -}
+linkAnnex :: FromTo -> Key -> RawFilePath -> Maybe InodeCache -> RawFilePath -> Maybe FileMode -> Annex LinkAnnexResult
+linkAnnex _ _ _ Nothing _ _ = return LinkAnnexFailed
+linkAnnex fromto key src (Just srcic) dest destmode =
+	withTSDelta (liftIO . genInodeCache dest) >>= \case
+		Just destic -> do
+			cs <- Database.Keys.getInodeCaches key
+			if null cs
+				then Database.Keys.addInodeCaches key [srcic, destic]
+				else Database.Keys.addInodeCaches key [srcic]
+			return LinkAnnexNoop
+		Nothing -> linkOrCopy key src dest destmode >>= \case
+			Nothing -> failed
+			Just r -> do
+				case fromto of
+					From -> thawContent dest
+					To -> case r of
+						Copied -> freezeContent dest
+						Linked -> noop
+				checksrcunchanged
+  where
+	failed = do
+		Database.Keys.addInodeCaches key [srcic]
+		return LinkAnnexFailed
+	checksrcunchanged = withTSDelta (liftIO . genInodeCache src) >>= \case
+		Just srcic' | compareStrong srcic srcic' -> do
+			destic <- withTSDelta (liftIO . genInodeCache dest)
+			Database.Keys.addInodeCaches key $
+				catMaybes [destic, Just srcic]
+			return LinkAnnexOk
+		_ -> do
+			liftIO $ removeWhenExistsWith R.removeLink dest
+			failed
+
+{- Removes the annex object file for a key. Lowlevel. -}
+unlinkAnnex :: Key -> Annex ()
+unlinkAnnex key = do
+	obj <- calcRepo (gitAnnexLocation key)
+	modifyContentDir obj $ do
+		secureErase obj
+		liftIO $ removeWhenExistsWith R.removeLink obj
+
+{- Runs an action to transfer an object's content. The action is also
+ - passed the size of the object.
+ -
+ - In some cases, it's possible for the file to change as it's being sent.
+ - If this happens, runs the rollback action and throws an exception.
+ - The rollback action should remove the data that was transferred.
+ -}
+sendAnnex :: Key -> Annex () -> (FilePath -> FileSize -> Annex a) -> Annex a
+sendAnnex key rollback sendobject = go =<< prepSendAnnex' key
+  where
+	go (Just (f, sz, check)) = do
+		r <- sendobject f sz
+		check >>= \case
+			Nothing -> return r
+			Just err -> do
+				rollback
+				giveup err
+	go Nothing = giveup "content not available to send"
+
+{- Returns a file that contains an object's content,
+ - and a check to run after the transfer is complete.
+ -
+ - When a file is unlocked, it's possible for its content to
+ - change as it's being sent. The check detects this case
+ - and returns False.
+ -
+ - Note that the returned check action is, in some cases, run in the
+ - Annex monad of the remote that is receiving the object, rather than
+ - the sender. So it cannot rely on Annex state.
+ -}
+prepSendAnnex :: Key -> Annex (Maybe (FilePath, FileSize, Annex Bool))
+prepSendAnnex key = withObjectLoc key $ \f -> do
+	let retval c cs = return $ Just 
+		(fromRawFilePath f
+		, inodeCacheFileSize c
+		, sameInodeCache f cs
+		)
+	cache <- Database.Keys.getInodeCaches key
+	if null cache
+		-- Since no inode cache is in the database, this
+		-- object is not currently unlocked. But that could
+		-- change while the transfer is in progress, so
+		-- generate an inode cache for the starting
+		-- content.
+		then maybe (return Nothing) (\fc -> retval fc [fc])
+			=<< withTSDelta (liftIO . genInodeCache f)
+		-- Verify that the object is not modified. Usually this
+		-- only has to check the inode cache, but if the cache
+		-- is somehow stale, it will fall back to verifying its
+		-- content.
+		else withTSDelta (liftIO . genInodeCache f) >>= \case
+			Just fc -> ifM (isUnmodified' key f fc cache)
+				( retval fc (fc:cache)
+				, return Nothing
+				)
+			Nothing -> return Nothing
+
+prepSendAnnex' :: Key -> Annex (Maybe (FilePath, FileSize, Annex (Maybe String)))
+prepSendAnnex' key = prepSendAnnex key >>= \case
+	Just (f, sz, checksuccess) -> 
+		let checksuccess' = ifM checksuccess
+			( return Nothing
+			, return (Just "content changed while it was being sent")
+			)
+		in return (Just (f, sz, checksuccess'))
+	Nothing -> return Nothing
+
+cleanObjectLoc :: Key -> Annex () -> Annex ()
+cleanObjectLoc key cleaner = do
+	file <- calcRepo (gitAnnexLocation key)
+	void $ tryIO $ thawContentDir file
+	{- Thawing is not necessary when the file was frozen only
+	 - by removing write perms. But if there is a thaw hook, it may do
+	 - something else that is necessary to allow the file to be
+	 - deleted. 
+	 -}
+	whenM hasThawHook $
+		void $ tryIO $ thawContent file
+		
+	cleaner
+	cleanObjectDirs file
+
+{- Given a filename inside the object directory, tries to remove the object
+ - directory, as well as the object hash directories.
+ - 
+ - Does nothing if the object directory is not empty, and does not
+ - throw an exception if it's unable to remove a directory. -}
+cleanObjectDirs :: RawFilePath -> Annex ()
+cleanObjectDirs f = do
+	HashLevels n <- objectHashLevels <$> Annex.getGitConfig
+	liftIO $ go f (succ n)
+  where
+	go _ 0 = noop
+	go file n = do
+		let dir = parentDir file
+		maybe noop (const $ go dir (n-1))
+			<=< catchMaybeIO $ tryWhenExists $
+				removeDirectory (fromRawFilePath dir)
+
+{- Removes a key's file from .git/annex/objects/ -}
+removeAnnex :: ContentRemovalLock -> Annex ()
+removeAnnex (ContentRemovalLock key) = withObjectLoc key $ \file ->
+	cleanObjectLoc key $ do
+		secureErase file
+		liftIO $ removeWhenExistsWith R.removeLink file
+		g <- Annex.gitRepo 
+		mapM_ (\f -> void $ tryIO $ resetpointer $ fromTopFilePath f g)
+			=<< Database.Keys.getAssociatedFiles key
+		Database.Keys.removeInodeCaches key
+  where
+	-- Check associated pointer file for modifications, and reset if
+	-- it's unmodified.
+	resetpointer file = unlessM (liftIO $ isSymbolicLink <$> R.getSymbolicLinkStatus file) $
+		ifM (isUnmodified key file)
+			( adjustedBranchRefresh (AssociatedFile (Just file)) $
+				depopulatePointerFile key file
+			-- Modified file, so leave it alone.
+			-- If it was a hard link to the annex object,
+			-- that object might have been frozen as part of the
+			-- removal process, so thaw it.
+			, void $ tryIO $ thawContent file
+			)
+
+{- Moves a key out of .git/annex/objects/ into .git/annex/bad, and
+ - returns the file it was moved to. -}
+moveBad :: Key -> Annex RawFilePath
+moveBad key = do
+	src <- calcRepo (gitAnnexLocation key)
+	bad <- fromRepo gitAnnexBadDir
+	let dest = bad P.</> P.takeFileName src
+	createAnnexDirectory (parentDir dest)
+	cleanObjectLoc key $
+		liftIO $ moveFile src dest
+	logStatus key InfoMissing
+	return dest
+
+data KeyLocation = InAnnex | InAnywhere
+
+{- InAnnex only lists keys with content in .git/annex/objects.
+ - InAnywhere lists all keys that have directories in
+ - .git/annex/objects, whether or not the content is present.
+ -}
+listKeys :: KeyLocation -> Annex [Key]
+listKeys keyloc = listKeys' keyloc (const (pure True))
+
+{- Due to use of unsafeInterleaveIO, the passed filter action
+ - will be run in a copy of the Annex state, so any changes it
+ - makes to the state will not be preserved. -}
+listKeys' :: KeyLocation -> (Key -> Annex Bool) -> Annex [Key]
+listKeys' keyloc want = do
+	dir <- fromRepo gitAnnexObjectDir
+	s <- Annex.getState id
+	r <- Annex.getRead id
+	depth <- gitAnnexLocationDepth <$> Annex.getGitConfig
+	liftIO $ walk (s, r) depth (fromRawFilePath dir)
+  where
+	walk s depth dir = do
+		contents <- catchDefaultIO [] (dirContents dir)
+		if depth < 2
+			then do
+				contents' <- filterM present contents
+				keys <- filterM (Annex.eval s . want) $
+					mapMaybe (fileKey . P.takeFileName . toRawFilePath) contents'
+				continue keys []
+			else do
+				let deeper = walk s (depth - 1)
+				continue [] (map deeper contents)
+	continue keys [] = return keys
+	continue keys (a:as) = do
+		{- Force lazy traversal with unsafeInterleaveIO. -}
+		morekeys <- unsafeInterleaveIO a
+		continue (morekeys++keys) as
+
+	inanywhere = case keyloc of
+		InAnywhere -> True
+		_ -> False
+
+	present _ | inanywhere = pure True
+	present d = presentInAnnex d
+
+	presentInAnnex = doesFileExist . contentfile
+	contentfile d = d </> takeFileName d
+
+{- Things to do to record changes to content when shutting down.
+ -
+ - It's acceptable to avoid committing changes to the branch,
+ - especially if performing a short-lived action.
+ -}
+saveState :: Bool -> Annex ()
+saveState nocommit = doSideAction $ do
+	Annex.Queue.flush
+	Database.Keys.flushDb
+	unless nocommit $
+		whenM (annexAlwaysCommit <$> Annex.getGitConfig) $
+			Annex.Branch.commit =<< Annex.Branch.commitMessage
+
+{- Downloads content from any of a list of urls, displaying a progress
+ - meter.
+ -
+ - Only displays error message if all the urls fail to download.
+ - When listfailedurls is set, lists each url and why it failed.
+ - Otherwise, only displays one error message, from one of the urls
+ - that failed.
+ -}
+downloadUrl :: Bool -> Key -> MeterUpdate -> Maybe IncrementalVerifier -> [Url.URLString] -> FilePath -> Url.UrlOptions -> Annex Bool
+downloadUrl listfailedurls k p iv urls file uo = 
+	-- Poll the file to handle configurations where an external
+	-- download command is used.
+	meteredFile (toRawFilePath file) (Just p) k (go urls [])
+  where
+	go (u:us) errs p' = Url.download' p' iv u file uo >>= \case
+		Right () -> return True
+		Left err -> do
+			-- If the incremental verifier was fed anything
+			-- while the download that failed ran, it's unable
+			-- to be used for the other urls.
+			case iv of
+				Just iv' -> 
+					liftIO $ positionIncrementalVerifier iv' >>= \case
+					Just n | n > 0 -> unableIncrementalVerifier iv'
+					_ -> noop
+				Nothing -> noop
+			go us ((u, err) : errs) p'
+	go [] [] _ = return False
+	go [] errs@((_, err):_) _ = do
+		if listfailedurls
+			then warning $ UnquotedString $
+				unlines $ flip map errs $ \(u, err') ->
+					u ++ " " ++ err'
+			else warning $ UnquotedString err
+		return False
+
+{- Copies a key's content, when present, to a temp file.
+ - This is used to speed up some rsyncs. -}
+preseedTmp :: Key -> FilePath -> Annex Bool
+preseedTmp key file = go =<< inAnnex key
+  where
+	go False = return False
+	go True = do
+		ok <- copy
+		when ok $ thawContent (toRawFilePath file)
+		return ok
+	copy = ifM (liftIO $ doesFileExist file)
+		( return True
+		, do
+			s <- fromRawFilePath <$> (calcRepo $ gitAnnexLocation key)
+			liftIO $ ifM (doesFileExist s)
+				( copyFileExternal CopyTimeStamps s file
+				, return False
+				)
+		)
+
+{- Finds files directly inside a directory like gitAnnexBadDir 
+ - (not in subdirectories) and returns the corresponding keys. -}
+dirKeys :: (Git.Repo -> RawFilePath) -> Annex [Key]
+dirKeys dirspec = do
+	dir <- fromRawFilePath <$> fromRepo dirspec
+	ifM (liftIO $ doesDirectoryExist dir)
+		( do
+			contents <- liftIO $ getDirectoryContents dir
+			files <- liftIO $ filterM doesFileExist $
+				map (dir </>) contents
+			return $ mapMaybe (fileKey . P.takeFileName . toRawFilePath) files
+		, return []
+		)
+
+{- Looks in the specified directory for bad/tmp keys, and returns a list
+ - of those that might still have value, or might be stale and removable.
+ - 
+ - Also, stale keys that can be proven to have no value
+ - (ie, their content is already present) are deleted.
+ -}
+staleKeysPrune :: (Git.Repo -> RawFilePath) -> Bool -> Annex [Key]
+staleKeysPrune dirspec nottransferred = do
+	contents <- dirKeys dirspec
+	
+	dups <- filterM inAnnex contents
+	let stale = contents `exclude` dups
+
+	dir <- fromRepo dirspec
+	forM_ dups $ \k ->
+		pruneTmpWorkDirBefore (dir P.</> keyFile k)
+			(liftIO . R.removeLink)
+
+	if nottransferred
+		then do
+			inprogress <- S.fromList . map (transferKey . fst)
+				<$> getTransfers
+			return $ filter (`S.notMember` inprogress) stale
+		else return stale
+
+{- Prune the work dir associated with the specified content file,
+ - before performing an action that deletes the file, or moves it away.
+ -
+ - This preserves the invariant that the workdir never exists without
+ - the content file.
+ -}
+pruneTmpWorkDirBefore :: RawFilePath -> (RawFilePath -> Annex a) -> Annex a
+pruneTmpWorkDirBefore f action = do
+	let workdir = fromRawFilePath $ gitAnnexTmpWorkDir f
+	liftIO $ whenM (doesDirectoryExist workdir) $
+		removeDirectoryRecursive workdir
+	action f
+
+{- Runs an action, passing it a temporary work directory where
+ - it can write files while receiving the content of a key.
+ -
+ - Preserves the invariant that the workdir never exists without the
+ - content file, by creating an empty content file first.
+ -
+ - On exception, or when the action returns Nothing,
+ - the temporary work directory is retained (unless
+ - empty), so anything in it can be used on resume.
+ -}
+withTmpWorkDir :: Key -> (RawFilePath -> Annex (Maybe a)) -> Annex (Maybe a)
+withTmpWorkDir key action = do
+	-- Create the object file if it does not exist. This way,
+	-- staleKeysPrune only has to look for object files, and can
+	-- clean up gitAnnexTmpWorkDir for those it finds.
+	obj <- prepTmp key
+	let obj' = fromRawFilePath obj
+	unlessM (liftIO $ doesFileExist obj') $ do
+		liftIO $ writeFile obj' ""
+		setAnnexFilePerm obj
+	let tmpdir = gitAnnexTmpWorkDir obj
+	createAnnexDirectory tmpdir
+	res <- action tmpdir
+	case res of
+		Just _ -> liftIO $ removeDirectoryRecursive (fromRawFilePath tmpdir)
+		Nothing -> liftIO $ void $ tryIO $ removeDirectory (fromRawFilePath tmpdir)
+	return res
+
+{- Finds items in the first, smaller list, that are not
+ - present in the second, larger list.
+ - 
+ - Constructing a single set, of the list that tends to be
+ - smaller, appears more efficient in both memory and CPU
+ - than constructing and taking the S.difference of two sets. -}
+exclude :: Ord a => [a] -> [a] -> [a]
+exclude [] _ = [] -- optimisation
+exclude smaller larger = S.toList $ remove larger $ S.fromList smaller
+  where
+	remove a b = foldl (flip S.delete) b a
+
+data KeyStatus
+	= KeyMissing
+	| KeyPresent
+	| KeyUnlockedThin
+	-- ^ An annex.thin worktree file is hard linked to the object.
+	| KeyLockedThin
+	-- ^ The object has hard links, but the file being fscked
+	-- is not the one that hard links to it.
+	deriving (Show)
+
+isKeyUnlockedThin :: KeyStatus -> Bool
+isKeyUnlockedThin KeyUnlockedThin = True
+isKeyUnlockedThin KeyLockedThin = False
+isKeyUnlockedThin KeyPresent = False
+isKeyUnlockedThin KeyMissing = False
+
+getKeyStatus :: Key -> Annex KeyStatus
+getKeyStatus key = catchDefaultIO KeyMissing $ do
+	afs <- not . null <$> Database.Keys.getAssociatedFiles key
+	obj <- calcRepo (gitAnnexLocation key)
+	multilink <- ((> 1) . linkCount <$> liftIO (R.getFileStatus obj))
+	return $ if multilink && afs
+		then KeyUnlockedThin
+		else KeyPresent
+
+getKeyFileStatus :: Key -> RawFilePath -> Annex KeyStatus
+getKeyFileStatus key file = do
+	s <- getKeyStatus key
+	case s of
+		KeyUnlockedThin -> catchDefaultIO KeyUnlockedThin $
+			ifM (isJust <$> isAnnexLink file)
+				( return KeyLockedThin
+				, return KeyUnlockedThin
+				)
+		_ -> return s
+
+{- Gets the size of the content of a key when it is present.
+ - Useful when the key does not have keySize set. 
+ -
+ - When the object file appears possibly modified with annex.thin set, does
+ - not do an expensive verification that the content is good, just returns
+ - Nothing.
+ -}
+contentSize :: Key -> Annex (Maybe FileSize)
+contentSize key = catchDefaultIO Nothing $
+	withObjectLoc key $ \loc ->
+		withTSDelta (liftIO . genInodeCache loc) >>= \case
+			Just ic -> ifM (unmodified ic)
+				( return (Just (inodeCacheFileSize ic))
+				, return Nothing
+				)
+			Nothing -> return Nothing
+  where
+	unmodified ic =
+		ifM (annexThin <$> Annex.getGitConfig)
+			( isUnmodifiedCheap' key ic
+			, return True
+			)
diff --git a/Annex/Content/LowLevel.hs b/Annex/Content/LowLevel.hs
new file mode 100644
index 0000000000..9d732f6a6e
--- /dev/null
+++ b/Annex/Content/LowLevel.hs
@@ -0,0 +1,141 @@
+{- git-annex low-level content functions
+ -
+ - Copyright 2010-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Annex.Content.LowLevel where
+
+import Annex.Common
+import Logs.Transfer
+import qualified Annex
+import Utility.DiskFree
+import Utility.FileMode
+import Utility.DataUnits
+import Utility.CopyFile
+import qualified Utility.RawFilePath as R
+
+import qualified System.FilePath.ByteString as P
+import System.PosixCompat.Files (linkCount)
+
+{- Runs the secure erase command if set, otherwise does nothing.
+ - File may or may not be deleted at the end; caller is responsible for
+ - making sure it's deleted. -}
+secureErase :: RawFilePath -> Annex ()
+secureErase file = maybe noop go =<< annexSecureEraseCommand <$> Annex.getGitConfig
+  where
+	go basecmd = void $ liftIO $
+		boolSystem "sh" [Param "-c", Param $ gencmd basecmd]
+	gencmd = massReplace [ ("%file", shellEscape (fromRawFilePath file)) ]
+
+data LinkedOrCopied = Linked | Copied
+
+{- Hard links or copies src to dest, which must not already exist.
+ -
+ - Only uses a hard link when annex.thin is enabled and when src is
+ - not already hardlinked to elsewhere.
+ -
+ - Checks disk reserve before copying against the size of the key,
+ - and will fail if not enough space, or if the dest file already exists.
+ -
+ - The FileMode, if provided, influences the mode of the dest file.
+ - In particular, if it has an execute bit set, the dest file's
+ - execute bit will be set. The mode is not fully copied over because
+ - git doesn't support file modes beyond execute.
+ -}
+linkOrCopy :: Key -> RawFilePath -> RawFilePath -> Maybe FileMode -> Annex (Maybe LinkedOrCopied)
+linkOrCopy = linkOrCopy' (annexThin <$> Annex.getGitConfig)
+
+linkOrCopy' :: Annex Bool -> Key -> RawFilePath -> RawFilePath -> Maybe FileMode -> Annex (Maybe LinkedOrCopied)
+linkOrCopy' canhardlink key src dest destmode = catchDefaultIO Nothing $
+	ifM canhardlink
+		( hardlink
+		, copy =<< getstat
+		)
+  where
+	hardlink = do
+		s <- getstat
+		if linkCount s > 1
+			then copy s
+			else liftIO (R.createLink src dest >> preserveGitMode dest destmode >> return (Just Linked))
+				`catchIO` const (copy s)
+	copy s = ifM (checkedCopyFile' key src dest destmode s)
+		( return (Just Copied)
+		, return Nothing
+		)
+	getstat = liftIO $ R.getFileStatus src
+
+{- Checks disk space before copying. -}
+checkedCopyFile :: Key -> RawFilePath -> RawFilePath -> Maybe FileMode -> Annex Bool
+checkedCopyFile key src dest destmode = catchBoolIO $
+	checkedCopyFile' key src dest destmode
+		=<< liftIO (R.getFileStatus src)
+
+checkedCopyFile' :: Key -> RawFilePath -> RawFilePath -> Maybe FileMode -> FileStatus -> Annex Bool
+checkedCopyFile' key src dest destmode s = catchBoolIO $ do
+	sz <- liftIO $ getFileSize' src s
+	ifM (checkDiskSpace' sz (Just $ P.takeDirectory dest) key 0 True)
+		( liftIO $
+			copyFileExternal CopyAllMetaData (fromRawFilePath src) (fromRawFilePath dest)
+				<&&> preserveGitMode dest destmode
+		, return False
+		)
+
+preserveGitMode :: RawFilePath -> Maybe FileMode -> IO Bool
+preserveGitMode f (Just mode)
+	| isExecutable mode = catchBoolIO $ do
+		modifyFileMode f $ addModes executeModes
+		return True
+	| otherwise = catchBoolIO $ do
+		modifyFileMode f $ removeModes executeModes
+		return True
+preserveGitMode _ _ = return True
+
+{- Checks that there is disk space available to store a given key,
+ - in a destination directory (or the annex) printing a warning if not. 
+ -
+ - If the destination is on the same filesystem as the annex,
+ - checks for any other running downloads, removing the amount of data still
+ - to be downloaded from the free space. This way, we avoid overcommitting
+ - when doing concurrent downloads.
+ -}
+checkDiskSpace :: Maybe FileSize -> Maybe RawFilePath -> Key -> Integer -> Bool -> Annex Bool
+checkDiskSpace msz destdir key = checkDiskSpace' sz destdir key
+  where
+	sz = fromMaybe 1 (fromKey keySize key <|> msz)
+
+checkDiskSpace' :: FileSize -> Maybe RawFilePath -> Key -> Integer -> Bool -> Annex Bool
+checkDiskSpace' sz destdir key alreadythere samefilesystem = ifM (Annex.getRead Annex.force)
+	( return True
+	, do
+		-- We can't get inprogress and free at the same
+		-- time, and both can be changing, so there's a
+		-- small race here. Err on the side of caution
+		-- by getting inprogress first, so if it takes
+		-- a while, we'll see any decrease in the free
+		-- disk space.
+		inprogress <- if samefilesystem
+			then sizeOfDownloadsInProgress (/= key)
+			else pure 0
+		dir >>= liftIO . getDiskFree . fromRawFilePath >>= \case
+			Just have -> do
+				reserve <- annexDiskReserve <$> Annex.getGitConfig
+				let delta = sz + reserve - have - alreadythere + inprogress
+				let ok = delta <= 0
+				unless ok $
+					warning $ UnquotedString $ 
+						needMoreDiskSpace delta
+				return ok
+			_ -> return True
+	)
+  where
+	dir = maybe (fromRepo gitAnnexDir) return destdir
+
+needMoreDiskSpace :: Integer -> String
+needMoreDiskSpace n = "not enough free space, need " ++ 
+	roughSize storageUnits True n ++ " more" ++ forcemsg
+  where
+	forcemsg = " (use --force to override this check or adjust annex.diskreserve)"
diff --git a/Annex/Content/PointerFile.hs b/Annex/Content/PointerFile.hs
new file mode 100644
index 0000000000..c2acc9ab93
--- /dev/null
+++ b/Annex/Content/PointerFile.hs
@@ -0,0 +1,71 @@
+{- git-annex pointer files
+ -
+ - Copyright 2010-2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Annex.Content.PointerFile where
+
+import Annex.Common
+import Annex.Perms
+import Annex.Link
+import Annex.ReplaceFile
+import Annex.InodeSentinal
+import Annex.Content.LowLevel
+import Utility.InodeCache
+import qualified Utility.RawFilePath as R
+#if ! defined(mingw32_HOST_OS)
+import Utility.Touch
+import qualified System.Posix.Files as Posix
+#endif
+
+import System.PosixCompat.Files (fileMode)
+
+{- Populates a pointer file with the content of a key. 
+ -
+ - If the file already has some other content, it is not modified.
+ -
+ - Returns an InodeCache if it populated the pointer file.
+ -}
+populatePointerFile :: Restage -> Key -> RawFilePath -> RawFilePath -> Annex (Maybe InodeCache)
+populatePointerFile restage k obj f = go =<< liftIO (isPointerFile f)
+  where
+	go (Just k') | k == k' = do
+		let f' = fromRawFilePath f
+		destmode <- liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus f
+		liftIO $ removeWhenExistsWith R.removeLink f
+		(ic, populated) <- replaceWorkTreeFile f' $ \tmp -> do
+			ok <- linkOrCopy k obj tmp destmode >>= \case
+				Just _ -> thawContent tmp >> return True
+				Nothing -> liftIO (writePointerFile tmp k destmode) >> return False
+			ic <- withTSDelta (liftIO . genInodeCache tmp)
+			return (ic, ok)
+		maybe noop (restagePointerFile restage f) ic
+		if populated
+			then return ic
+			else return Nothing
+	go _ = return Nothing
+	
+{- Removes the content from a pointer file, replacing it with a pointer.
+ -
+ - Does not check if the pointer file is modified. -}
+depopulatePointerFile :: Key -> RawFilePath -> Annex ()
+depopulatePointerFile key file = do
+	st <- liftIO $ catchMaybeIO $ R.getFileStatus file
+	let mode = fmap fileMode st
+	secureErase file
+	liftIO $ removeWhenExistsWith R.removeLink file
+	ic <- replaceWorkTreeFile (fromRawFilePath file) $ \tmp -> do
+		liftIO $ writePointerFile tmp key mode
+#if ! defined(mingw32_HOST_OS)
+		-- Don't advance mtime; this avoids unnecessary re-smudging
+		-- by git in some cases.
+		liftIO $ maybe noop
+			(\t -> touch tmp t False)
+			(fmap Posix.modificationTimeHiRes st)
+#endif
+		withTSDelta (liftIO . genInodeCache tmp)
+	maybe noop (restagePointerFile (Restage True) file) ic
diff --git a/Annex/Content/Presence.hs b/Annex/Content/Presence.hs
new file mode 100644
index 0000000000..2eb0016ddd
--- /dev/null
+++ b/Annex/Content/Presence.hs
@@ -0,0 +1,215 @@
+{- git-annex object content presence
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Content.Presence (
+	inAnnex,
+	inAnnex',
+	inAnnexSafe,
+	inAnnexCheck,
+	objectFileExists,
+	withObjectLoc,
+	isUnmodified,
+	isUnmodified',
+	isUnmodifiedCheap,
+	isUnmodifiedCheap',
+	withContentLockFile,
+	contentLockFile,
+) where
+
+import Annex.Content.Presence.LowLevel
+import Annex.Common
+import qualified Annex
+import Annex.LockPool
+import Annex.LockFile
+import Annex.Version
+import Types.RepoVersion
+import qualified Database.Keys
+import Annex.InodeSentinal
+import Utility.InodeCache
+import qualified Utility.RawFilePath as R
+import qualified Git
+import Config
+
+#ifdef mingw32_HOST_OS
+import Annex.Perms
+#endif
+
+import qualified System.FilePath.ByteString as P
+
+{- Checks if a given key's content is currently present. -}
+inAnnex :: Key -> Annex Bool
+inAnnex key = inAnnexCheck key $ liftIO . R.doesPathExist
+
+{- Runs an arbitrary check on a key's content. -}
+inAnnexCheck :: Key -> (RawFilePath -> Annex Bool) -> Annex Bool
+inAnnexCheck key check = inAnnex' id False check key
+
+{- inAnnex that performs an arbitrary check of the key's content. -}
+inAnnex' :: (a -> Bool) -> a -> (RawFilePath -> Annex a) -> Key -> Annex a
+inAnnex' isgood bad check key = withObjectLoc key $ \loc -> do
+	r <- check loc
+	if isgood r
+		then ifM (annexThin <$> Annex.getGitConfig)
+			-- When annex.thin is set, the object file
+			-- could be modified; make sure it's not.
+			-- (Suppress any messages about
+			-- checksumming, to avoid them cluttering
+			-- the display.)
+			( ifM (doQuietAction $ isUnmodified key loc)
+				( return r
+				, return bad
+				)
+			, return r
+			)
+		else return bad
+
+{- Like inAnnex, checks if the object file for a key exists,
+ - but there are no guarantees it has the right content. -}
+objectFileExists :: Key -> Annex Bool
+objectFileExists key =
+	calcRepo (gitAnnexLocation key)
+		>>= liftIO . R.doesPathExist
+
+{- A safer check; the key's content must not only be present, but
+ - is not in the process of being removed. -}
+inAnnexSafe :: Key -> Annex (Maybe Bool)
+inAnnexSafe key = inAnnex' (fromMaybe True) (Just False) go key
+  where
+	is_locked = Nothing
+	is_unlocked = Just True
+	is_missing = Just False
+
+	go contentfile = withContentLockFile key $ flip checklock contentfile
+
+#ifndef mingw32_HOST_OS
+	checklock Nothing contentfile = checkOr is_missing contentfile
+	{- The content file must exist, but the lock file generally
+	 - won't exist unless a removal is in process. -}
+	checklock (Just lockfile) contentfile =
+		ifM (liftIO $ doesFileExist (fromRawFilePath contentfile))
+			( checkOr is_unlocked lockfile
+			, return is_missing
+			)
+	checkOr d lockfile = checkLocked lockfile >>= return . \case
+		Nothing -> d
+		Just True -> is_locked
+		Just False -> is_unlocked
+#else
+	checklock Nothing contentfile = liftIO $ ifM (doesFileExist (fromRawFilePath contentfile))
+		( lockShared contentfile >>= \case
+			Nothing -> return is_locked
+			Just lockhandle -> do
+				dropLock lockhandle
+				return is_unlocked
+		, return is_missing
+		)
+	{- In Windows, see if we can take a shared lock. If so, 
+	 - remove the lock file to clean up after ourselves. -}
+	checklock (Just lockfile) contentfile =
+		ifM (liftIO $ doesFileExist (fromRawFilePath contentfile))
+			( modifyContentDir lockfile $ liftIO $
+				lockShared lockfile >>= \case
+					Nothing -> return is_locked
+					Just lockhandle -> do
+						dropLock lockhandle
+						void $ tryIO $ removeWhenExistsWith R.removeLink lockfile
+						return is_unlocked
+			, return is_missing
+			)
+#endif
+
+{- Runs an action with the lock file to use to lock a key's content.
+ - When the content file itself should be locked, runs the action with
+ - Nothing.
+ -
+ - In v9 and below, while the action is running, a shared lock is held of the
+ - gitAnnexContentLockLock. That prevents the v10 upgrade, which changes how
+ - content locking works, from running at the same time as content is locked
+ - using the old method.
+ -}
+withContentLockFile :: Key -> (Maybe RawFilePath -> Annex a) -> Annex a
+withContentLockFile k a = do
+	v <- getVersion
+	if versionNeedsWritableContentFiles v
+		then fromRepo gitAnnexContentLockLock >>= \lck -> withSharedLock lck $ do
+			{- While the lock is held, check to see if the git
+			 - config has changed, and reload it if so. This
+			 - updates the annex.version after the v10 upgrade,
+			 - so that a process that started in a v9 repository
+			 - will switch over to v10 content lock files at the
+			 - right time. -}
+			gitdir <- fromRepo Git.localGitDir
+			let gitconfig = gitdir P.</> "config"
+			ic <- withTSDelta (liftIO . genInodeCache gitconfig)
+			oldic <- Annex.getState Annex.gitconfiginodecache
+			v' <- if fromMaybe False (compareStrong <$> ic <*> oldic)
+				then pure v
+				else do
+					Annex.changeState $ \s -> 
+						s { Annex.gitconfiginodecache = ic }
+					reloadConfig
+					getVersion
+			go (v')
+		else go v
+  where
+	go v = contentLockFile k v >>= a
+
+contentLockFile :: Key -> Maybe RepoVersion -> Annex (Maybe RawFilePath)
+#ifndef mingw32_HOST_OS
+{- Older versions of git-annex locked content files themselves, but newer
+ - versions use a separate lock file, to better support repos shared
+ - among users in eg a group. -}
+contentLockFile key v
+	| versionNeedsWritableContentFiles v = pure Nothing
+	| otherwise = Just <$> calcRepo (gitAnnexContentLock key)
+#else
+{- Windows always has to use a separate lock file from the content, since
+ - locking the actual content file would interfere with the user's
+ - use of it. -}
+contentLockFile key _ = Just <$> calcRepo (gitAnnexContentLock key)
+#endif
+
+{- Performs an action, passing it the location to use for a key's content. -}
+withObjectLoc :: Key -> (RawFilePath -> Annex a) -> Annex a
+withObjectLoc key a = a =<< calcRepo (gitAnnexLocation key)
+
+{- Check if a file contains the unmodified content of the key.
+ -
+ - The expensive way to tell is to do a verification of its content.
+ - The cheaper way is to see if the InodeCache for the key matches the
+ - file. -}
+isUnmodified :: Key -> RawFilePath -> Annex Bool
+isUnmodified key f = 
+	withTSDelta (liftIO . genInodeCache f) >>= \case
+		Just fc -> do
+			ic <- Database.Keys.getInodeCaches key
+			isUnmodified' key f fc ic
+		Nothing -> return False
+
+isUnmodified' :: Key -> RawFilePath -> InodeCache -> [InodeCache] -> Annex Bool
+isUnmodified' = isUnmodifiedLowLevel Database.Keys.addInodeCaches
+
+{- Cheap check if a file contains the unmodified content of the key,
+ - only checking the InodeCache of the key.
+ -
+ - When the InodeCache is stale, this may incorrectly report that a file is
+ - modified.
+ -
+ - Note that, on systems not supporting high-resolution mtimes,
+ - this may report a false positive when repeated edits are made to a file
+ - within a small time window (eg 1 second).
+ -}
+isUnmodifiedCheap :: Key -> RawFilePath -> Annex Bool
+isUnmodifiedCheap key f = maybe (pure False) (isUnmodifiedCheap' key) 
+	=<< withTSDelta (liftIO . genInodeCache f)
+
+isUnmodifiedCheap' :: Key -> InodeCache -> Annex Bool
+isUnmodifiedCheap' key fc = isUnmodifiedCheapLowLevel fc
+	=<< Database.Keys.getInodeCaches key
diff --git a/Annex/Content/Presence/LowLevel.hs b/Annex/Content/Presence/LowLevel.hs
new file mode 100644
index 0000000000..6f50c187b2
--- /dev/null
+++ b/Annex/Content/Presence/LowLevel.hs
@@ -0,0 +1,36 @@
+{- git-annex object content presence, low-level functions
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.Content.Presence.LowLevel where
+
+import Annex.Common
+import Annex.Verify
+import Annex.InodeSentinal
+import Utility.InodeCache
+
+isUnmodifiedLowLevel :: (Key -> [InodeCache] -> Annex ()) -> Key -> RawFilePath -> InodeCache -> [InodeCache] -> Annex Bool
+isUnmodifiedLowLevel addinodecaches key f fc ic =
+	isUnmodifiedCheapLowLevel fc ic <||> expensivecheck
+  where
+	expensivecheck = ifM (verifyKeyContent key f)
+		( do
+			-- The file could have been modified while it was
+			-- being verified. Detect that.
+			ifM (geti >>= maybe (return False) (compareInodeCaches fc))
+				( do
+					-- Update the InodeCache to avoid
+					-- performing this expensive check again.
+					addinodecaches key [fc]
+					return True
+				, return False
+				)
+		, return False
+		)
+	geti = withTSDelta (liftIO . genInodeCache f)
+
+isUnmodifiedCheapLowLevel :: InodeCache -> [InodeCache] -> Annex Bool
+isUnmodifiedCheapLowLevel fc ic = anyM (compareInodeCaches fc) ic
diff --git a/Annex/CopyFile.hs b/Annex/CopyFile.hs
new file mode 100644
index 0000000000..55c7d908e2
--- /dev/null
+++ b/Annex/CopyFile.hs
@@ -0,0 +1,179 @@
+{- Copying files.
+ -
+ - Copyright 2011-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Annex.CopyFile where
+
+import Annex.Common
+import Utility.Metered
+import Utility.CopyFile
+import Utility.FileMode
+import Utility.Touch
+import Utility.Hash (IncrementalVerifier(..))
+import qualified Utility.RawFilePath as R
+
+import Control.Concurrent
+import qualified Data.ByteString as S
+import Data.Time.Clock.POSIX
+import System.PosixCompat.Files (fileMode)
+
+-- To avoid the overhead of trying copy-on-write every time, it's tried
+-- once and if it fails, is not tried again.
+newtype CopyCoWTried = CopyCoWTried (MVar Bool)
+
+newCopyCoWTried :: IO CopyCoWTried
+newCopyCoWTried = CopyCoWTried <$> newEmptyMVar
+
+{- Copies a file is copy-on-write is supported. Otherwise, returns False.
+ -
+ - The destination file must not exist yet (or may exist but be empty), 
+ - or it will fail to make a CoW copy, and will return false.
+ -}
+tryCopyCoW :: CopyCoWTried -> FilePath -> FilePath -> MeterUpdate -> IO Bool
+tryCopyCoW (CopyCoWTried copycowtried) src dest meterupdate =
+	-- If multiple threads reach this at the same time, they
+	-- will both try CoW, which is acceptable.
+	ifM (isEmptyMVar copycowtried)
+		( ifM destfilealreadypopulated
+			( return False
+			, do
+				ok <- docopycow
+				void $ tryPutMVar copycowtried ok
+				return ok
+			)
+		, ifM (readMVar copycowtried)
+			( do
+				-- CoW is known to work, so delete
+				-- dest if it exists in order to do a fast
+				-- CoW copy.
+				void $ tryIO $ removeFile dest
+				docopycow
+			, return False
+			)
+		)
+  where
+	docopycow = watchFileSize dest' meterupdate $ const $
+		copyCoW CopyTimeStamps src dest
+	
+	dest' = toRawFilePath dest
+
+	-- Check if the dest file already exists, which would prevent
+	-- probing CoW. If the file exists but is empty, there's no benefit
+	-- to resuming from it when CoW does not work, so remove it.
+	destfilealreadypopulated = 
+		tryIO (R.getFileStatus dest') >>= \case
+			Left _ -> return False
+			Right st -> do
+				sz <- getFileSize' dest' st
+				if sz == 0
+					then tryIO (removeFile dest) >>= \case
+						Right () -> return False
+						Left _ -> return True
+					else return True
+
+data CopyMethod = CopiedCoW | Copied
+
+{- Copies from src to dest, updating a meter. Preserves mode and mtime.
+ - Uses copy-on-write if it is supported. If the the destination already
+ - exists, an interrupted copy will resume where it left off.
+ -
+ - The IncrementalVerifier is updated with the content of the file as it's
+ - being copied. But it is not finalized at the end.
+ -
+ - When copy-on-write is used, the IncrementalVerifier is not fed
+ - the content of the file, and verification using it will fail.
+ -
+ - Note that, when the destination file already exists, it's read both
+ - to start calculating the hash, and also to verify that its content is
+ - the same as the start of the source file. It's possible that the
+ - destination file was created from some other source file,
+ - (eg when isStableKey is false), and doing this avoids getting a
+ - corrupted file in such cases.
+ -}
+fileCopier :: CopyCoWTried -> FilePath -> FilePath -> MeterUpdate -> Maybe IncrementalVerifier -> IO CopyMethod
+#ifdef mingw32_HOST_OS
+fileCopier _ src dest meterupdate iv = docopy
+#else
+fileCopier copycowtried src dest meterupdate iv =
+	ifM (tryCopyCoW copycowtried src dest meterupdate)
+		( do
+			maybe noop unableIncrementalVerifier iv
+			return CopiedCoW
+		, docopy
+		)
+#endif
+  where
+	docopy = do
+		-- The file might have had the write bit removed,
+		-- so make sure we can write to it.
+		void $ tryIO $ allowWrite dest'
+
+		withBinaryFile src ReadMode $ \hsrc ->
+			fileContentCopier hsrc dest meterupdate iv
+		
+		-- Copy src mode and mtime.
+		mode <- fileMode <$> R.getFileStatus (toRawFilePath src)
+		mtime <- utcTimeToPOSIXSeconds <$> getModificationTime src
+		R.setFileMode dest' mode
+		touch dest' mtime False
+
+		return Copied
+	
+	dest' = toRawFilePath dest
+
+{- Copies content from a handle to a destination file. Does not
+ - use copy-on-write, and does not copy file mode and mtime.
+ -}
+fileContentCopier :: Handle -> FilePath -> MeterUpdate -> Maybe IncrementalVerifier -> IO ()
+fileContentCopier hsrc dest meterupdate iv =
+	withBinaryFile dest ReadWriteMode $ \hdest -> do
+		sofar <- compareexisting hdest zeroBytesProcessed
+		docopy hdest sofar
+  where
+	docopy hdest sofar = do
+		s <- S.hGet hsrc defaultChunkSize
+		if s == S.empty
+			then return ()
+			else do
+				let sofar' = addBytesProcessed sofar (S.length s)
+				S.hPut hdest s
+				maybe noop (flip updateIncrementalVerifier s) iv
+				meterupdate sofar'
+				docopy hdest sofar'
+
+	-- Leaves hdest and hsrc seeked to wherever the two diverge,
+	-- so typically hdest will be seeked to end, and hsrc to the same
+	-- position.
+	compareexisting hdest sofar = do
+		s <- S.hGet hdest defaultChunkSize
+		if s == S.empty
+			then return sofar
+			else do
+				s' <- getnoshort (S.length s) hsrc
+				if s == s'
+					then do
+						maybe noop (flip updateIncrementalVerifier s) iv
+						let sofar' = addBytesProcessed sofar (S.length s)
+						meterupdate sofar'
+						compareexisting hdest sofar'
+					else do
+						seekbefore hdest s
+						seekbefore hsrc s'
+						return sofar
+	
+	seekbefore h s = hSeek h RelativeSeek (fromIntegral (-1*S.length s))
+	
+	-- Like hGet, but never returns less than the requested number of
+	-- bytes, unless it reaches EOF.
+	getnoshort n h = do
+		s <- S.hGet h n
+		if S.length s == n || S.empty == s
+			then return s
+			else do
+				s' <- getnoshort (n - S.length s) h
+				return (s <> s')
diff --git a/Annex/CurrentBranch.hs b/Annex/CurrentBranch.hs
new file mode 100644
index 0000000000..f6ae28442f
--- /dev/null
+++ b/Annex/CurrentBranch.hs
@@ -0,0 +1,41 @@
+{- currently checked out branch
+ -
+ - Copyright 2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.CurrentBranch where
+
+import Annex.Common
+import Types.AdjustedBranch
+import Annex.AdjustedBranch.Name
+import qualified Annex
+import qualified Git
+import qualified Git.Branch
+
+type CurrBranch = (Maybe Git.Branch, Maybe Adjustment)
+
+{- Gets the currently checked out branch.
+ - When on an adjusted branch, gets the original branch, and the adjustment.
+ -
+ - Cached for speed.
+ -
+ - Until a commit is made in a new repository, no branch is checked out.
+ - Since git-annex may make the first commit, this does not cache
+ - the absence of a branch.
+ -}
+getCurrentBranch :: Annex CurrBranch
+getCurrentBranch = maybe cache return
+	=<< Annex.getState Annex.cachedcurrentbranch
+  where
+	cache = inRepo Git.Branch.current >>= \case
+		Just b -> do
+			let v = case adjustedToOriginal b of 
+                        	Nothing -> (Just b, Nothing) 
+                                Just (adj, origbranch) -> 
+                                	(Just origbranch, Just adj)
+			Annex.changeState $ \s ->
+				s { Annex.cachedcurrentbranch = Just v }
+			return v
+		Nothing -> return (Nothing, Nothing)
diff --git a/Annex/Debug.hs b/Annex/Debug.hs
new file mode 100644
index 0000000000..fb7d7eef77
--- /dev/null
+++ b/Annex/Debug.hs
@@ -0,0 +1,35 @@
+{- git-annex debugging
+ -
+ - Copyright 2021-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.Debug (
+	DebugSelector(..),
+	DebugSource(..),
+	debug,
+	fastDebug,
+	fastDebug',
+	configureDebug,
+	debugSelectorFromGitConfig,
+	parseDebugSelector,
+) where
+
+import Common
+import qualified Annex
+import Utility.Debug hiding (fastDebug)
+import qualified Utility.Debug
+import Annex.Debug.Utility
+
+-- | This is faster than using debug, because the DebugSelector
+-- is read from the Annex monad, which avoids any IORef access overhead
+-- when debugging is not enabled.
+fastDebug :: DebugSource -> String -> Annex.Annex ()
+fastDebug src msg = do
+	rd <- Annex.getRead id
+	fastDebug' rd src msg
+
+fastDebug' :: Annex.AnnexRead -> DebugSource -> String -> Annex.Annex ()
+fastDebug' rd src msg = when (Annex.debugenabled rd) $
+	liftIO $ Utility.Debug.fastDebug (Annex.debugselector rd) src msg
diff --git a/Annex/Debug/Utility.hs b/Annex/Debug/Utility.hs
new file mode 100644
index 0000000000..79186d840d
--- /dev/null
+++ b/Annex/Debug/Utility.hs
@@ -0,0 +1,32 @@
+{- git-annex debugging, utility functions
+ -
+ - Copyright 2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.Debug.Utility (
+	debugSelectorFromGitConfig,
+	parseDebugSelector,
+	DebugSelector,
+) where
+
+import Types.GitConfig
+import Utility.Debug
+import Utility.Split
+import Utility.FileSystemEncoding
+
+import qualified Data.ByteString as S
+
+debugSelectorFromGitConfig :: GitConfig -> DebugSelector
+debugSelectorFromGitConfig = 
+	maybe NoDebugSelector parseDebugSelector . annexDebugFilter
+
+parseDebugSelector :: String -> DebugSelector
+parseDebugSelector = DebugSelector . matchDebugSource . splitSelectorNames
+
+splitSelectorNames :: String -> [S.ByteString]
+splitSelectorNames = map encodeBS . splitc ','
+
+matchDebugSource :: [S.ByteString] -> DebugSource -> Bool
+matchDebugSource names (DebugSource s) = any (`S.isInfixOf` s) names
diff --git a/Annex/Difference.hs b/Annex/Difference.hs
new file mode 100644
index 0000000000..fa874476fd
--- /dev/null
+++ b/Annex/Difference.hs
@@ -0,0 +1,60 @@
+{- git-annex repository differences
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Difference (
+	module Types.Difference,
+	setDifferences,
+) where
+
+import Annex.Common
+import Types.Difference
+import Logs.Difference
+import Config
+import Annex.UUID
+import Logs.UUID
+import Annex.Version
+import qualified Annex
+
+import qualified Data.Map as M
+
+-- Differences are only allowed to be tweaked when initializing a
+-- repository for the first time, and then only if there is not another
+-- known uuid. If the repository was cloned from elsewhere, it inherits
+-- the existing settings.
+--
+-- Must be called before setVersion, so it can check if this is the first
+-- time the repository is being initialized.
+setDifferences :: Annex ()
+setDifferences = do
+	u <- getUUID
+	otherds <- allDifferences <$> recordedDifferences
+	ds <- mappend otherds . annexDifferences <$> Annex.getGitConfig
+	when (ds /= mempty) $ do
+		ds' <- ifM (isJust <$> getVersion)
+			( do
+				oldds <- recordedDifferencesFor u
+				when (ds /= oldds) $
+					warning "Cannot change tunable parameters in already initialized repository."
+				return oldds
+			, if otherds == mempty
+				then ifM (any (/= u) . M.keys <$> uuidDescMap)
+					( do
+						warning "Cannot change tunable parameters in a clone of an existing repository."
+						return mempty
+					, return ds
+					)
+				else if otherds /= ds
+					then do
+						warning "The specified tunable parameters differ from values being used in other clones of this repository."
+						return otherds
+					else return ds
+			)
+		forM_ (listDifferences ds') $ \d ->
+			setConfig (differenceConfigKey d) (differenceConfigVal d)
+		recordDifferences ds' u
diff --git a/Annex/DirHashes.hs b/Annex/DirHashes.hs
new file mode 100644
index 0000000000..7311acf3e6
--- /dev/null
+++ b/Annex/DirHashes.hs
@@ -0,0 +1,90 @@
+{- git-annex file locations
+ -
+ - Copyright 2010-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.DirHashes (
+	Hasher,
+	HashLevels(..),
+	objectHashLevels,
+	branchHashLevels,
+	branchHashDir,
+	dirHashes,
+	hashDirMixed,
+	hashDirLower,
+	display_32bits_as_dir
+) where
+
+import Data.Default
+import Data.Bits
+import qualified Data.ByteArray as BA
+import qualified Data.ByteArray.Encoding as BA
+import qualified Data.ByteString as S
+import qualified System.FilePath.ByteString as P
+
+import Common
+import Key
+import Types.GitConfig
+import Types.Difference
+import Utility.Hash
+import Utility.MD5
+
+type Hasher = Key -> RawFilePath
+
+-- Number of hash levels to use. 2 is the default.
+newtype HashLevels = HashLevels Int
+
+instance Default HashLevels where
+	def = HashLevels 2
+
+objectHashLevels :: GitConfig -> HashLevels
+objectHashLevels = configHashLevels OneLevelObjectHash
+
+branchHashLevels :: GitConfig -> HashLevels
+branchHashLevels = configHashLevels OneLevelBranchHash
+
+configHashLevels :: Difference -> GitConfig -> HashLevels
+configHashLevels d config
+	| hasDifference d (annexDifferences config) = HashLevels 1
+	| otherwise = def
+
+branchHashDir :: GitConfig -> Key -> S.ByteString
+branchHashDir = hashDirLower . branchHashLevels
+
+{- Two different directory hashes may be used. The mixed case hash
+ - came first, and is fine, except for the problem of case-strict
+ - filesystems such as Linux VFAT (mounted with shortname=mixed),
+ - which do not allow using a directory "XX" when "xx" already exists.
+ - To support that, some git-annex repositories use the lower case-hash.
+ - All special remotes use the lower-case hash for new data, but old data
+ - may still use the mixed case hash. -}
+dirHashes :: [HashLevels -> Hasher]
+dirHashes = [hashDirLower, hashDirMixed]
+
+hashDirs :: HashLevels -> Int -> S.ByteString -> RawFilePath
+hashDirs (HashLevels 1) sz s = P.addTrailingPathSeparator $ S.take sz s
+hashDirs _ sz s = P.addTrailingPathSeparator $ h P.</> t
+  where
+	(h, t) = S.splitAt sz s
+
+hashDirLower :: HashLevels -> Hasher
+hashDirLower n k = hashDirs n 3 $ S.pack $ take 6 $ conv $
+	md5s $ serializeKey' $ nonChunkKey k
+  where
+	conv v = BA.unpack $
+		(BA.convertToBase BA.Base16 v :: BA.Bytes)
+
+{- This was originally using Data.Hash.MD5 from MissingH. This new version
+- is faster, but ugly as it has to replicate the 4 Word32's that produced. -}
+hashDirMixed :: HashLevels -> Hasher
+hashDirMixed n k = hashDirs n 2 $ S.pack $ take 4 $
+	concatMap display_32bits_as_dir $
+		encodeWord32 $ map fromIntegral $ BA.unpack $
+			Utility.Hash.md5s $ serializeKey' $ nonChunkKey k
+  where
+	encodeWord32 (b1:b2:b3:b4:rest) =
+		(shiftL b4 24 .|. shiftL b3 16 .|. shiftL b2 8 .|. b1)
+		: encodeWord32 rest
+	encodeWord32 _ = []
diff --git a/Annex/Drop.hs b/Annex/Drop.hs
new file mode 100644
index 0000000000..f59d6f17d6
--- /dev/null
+++ b/Annex/Drop.hs
@@ -0,0 +1,131 @@
+{- dropping of unwanted content
+ -
+ - Copyright 2012-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Drop where
+
+import Annex.Common
+import Logs.Trust
+import Annex.NumCopies
+import Types.Remote (uuid, appendonly, config, remotetype, thirdPartyPopulated)
+import qualified Remote
+import qualified Command.Drop
+import Command
+import Annex.Wanted
+import Annex.Content
+import Annex.SpecialRemote.Config
+import qualified Database.Keys
+
+import qualified Data.Set as S
+
+type Reason = String
+
+{- Drop a key from local and/or remote when allowed by the preferred content,
+ - required content, and numcopies settings.
+ -
+ - Skips trying to drop from remotes that are appendonly, since those drops
+ - would presumably fail. Also skips dropping from exporttree/importtree remotes,
+ - which don't allow dropping individual keys, and from thirdPartyPopulated
+ - remotes.
+ -
+ - The UUIDs are ones where the content is believed to be present.
+ - The Remote list can include other remotes that do not have the content;
+ - only ones that match the UUIDs will be dropped from.
+ -
+ - If allowed to drop fromhere, that drop will be done last. This is done
+ - because local drops do not need any LockedCopy evidence, and so dropping
+ - from local last allows the content to be removed from more remotes.
+ -
+ - A VerifiedCopy can be provided as an optimisation when eg, a key
+ - has just been uploaded to a remote.
+ -
+ - The runner is used to run CommandStart sequentially, it's typically 
+ - callCommandAction.
+ -}
+handleDropsFrom :: [UUID] -> [Remote] -> Reason -> Bool -> Key -> AssociatedFile -> SeekInput -> [VerifiedCopy] -> (CommandStart -> CommandCleanup) -> Annex ()
+handleDropsFrom locs rs reason fromhere key afile si preverified runner = do
+	fs <- Database.Keys.getAssociatedFilesIncluding afile key
+	n <- getcopies fs
+	void $ if fromhere && checkcopies n Nothing
+		then go fs rs n >>= dropl fs
+		else go fs rs n
+  where
+	getcopies fs = do
+		(untrusted, have) <- trustPartition UnTrusted locs
+		(numcopies, mincopies) <- getSafestNumMinCopies' afile key fs
+		return (length have, numcopies, mincopies, S.fromList untrusted)
+
+	{- Check that we have enough copies still to drop the content.
+	 - When the remote being dropped from is untrusted, it was not
+	 - counted as a copy, so having only numcopies suffices. Otherwise,
+	 - we need more than numcopies to safely drop.
+	 -
+	 - This is not the final check that it's safe to drop, but it
+	 - avoids doing extra work to do that check later in cases where it
+	 - will surely fail.
+	 -}
+	checkcopies (have, numcopies, mincopies, _untrusted) Nothing =
+		have > fromNumCopies numcopies && have > fromMinCopies mincopies
+	checkcopies (have, numcopies, mincopies, untrusted) (Just u)
+		| S.member u untrusted = have >= fromNumCopies numcopies && have >= fromMinCopies mincopies
+		| otherwise = have > fromNumCopies numcopies && have > fromMinCopies mincopies
+	
+	decrcopies (have, numcopies, mincopies, untrusted) Nothing =
+		(have - 1, numcopies, mincopies, untrusted)
+	decrcopies v@(_have, _numcopies, _mincopies, untrusted) (Just u)
+		| S.member u untrusted = v
+		| otherwise = decrcopies v Nothing
+
+	go _ [] n = pure n
+	go fs (r:rest) n
+		| uuid r `S.notMember` slocs = go fs rest n
+		| appendonly r = go fs rest n
+		| exportTree (config r) = go fs rest n
+		| importTree (config r) = go fs rest n
+		| thirdPartyPopulated (remotetype r) = go fs rest n
+		| checkcopies n (Just $ Remote.uuid r) =
+			dropr fs r n >>= go fs rest
+		| otherwise = pure n
+
+	checkdrop fs n u a =
+		let afs = map (AssociatedFile . Just) fs
+		    pcc = Command.Drop.PreferredContentChecked True
+		in ifM (wantDrop True u (Just key) afile (Just afs))
+			( dodrop n u (a pcc)
+			, return n
+			)
+
+	dodrop n@(have, numcopies, mincopies, _untrusted) u a = 
+		ifM (safely $ runner $ a numcopies mincopies)
+			( do
+				fastDebug "Annex.Drop" $ unwords
+					[ "dropped"
+					, case afile of
+						AssociatedFile Nothing -> serializeKey key
+						AssociatedFile (Just af) -> fromRawFilePath af
+					, "(from " ++ maybe "here" show u ++ ")"
+					, "(copies now " ++ show (have - 1) ++ ")"
+					, ": " ++ reason
+					]
+				return $ decrcopies n u
+			, return n
+			)
+
+	dropl fs n = checkdrop fs n Nothing $ \pcc numcopies mincopies ->
+		stopUnless (inAnnex key) $
+			Command.Drop.startLocal pcc afile ai si numcopies mincopies key preverified (Command.Drop.DroppingUnused False)
+
+	dropr fs r n  = checkdrop fs n (Just $ Remote.uuid r) $ \pcc numcopies mincopies ->
+		Command.Drop.startRemote pcc afile ai si numcopies mincopies key (Command.Drop.DroppingUnused False) r
+
+	ai = mkActionItem (key, afile)
+
+	slocs = S.fromList locs
+	
+	safely a = either (const False) id <$> tryNonAsync a
+
diff --git a/Annex/Environment.hs b/Annex/Environment.hs
new file mode 100644
index 0000000000..2b917f4fa2
--- /dev/null
+++ b/Annex/Environment.hs
@@ -0,0 +1,73 @@
+{- git-annex environment
+ -
+ - Copyright 2012-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Environment (
+	checkEnvironment,
+	checkEnvironmentIO,
+	ensureCommit,
+) where
+
+import Annex.Common
+import Utility.UserInfo
+import qualified Git.Config
+import Config
+import Utility.Env.Set
+
+import Control.Exception
+
+{- Checks that the system's environment allows git to function.
+ - Git requires a GECOS username, or suitable git configuration, or
+ - environment variables. When none of those are set, this will set the
+ - environment variables.
+ -
+ - Git also requires the system have a hostname containing a dot.
+ - Otherwise, it tries various methods to find a FQDN, and will fail if it
+ - does not. To avoid replicating that code here, which would break if its
+ - methods change, this function does not check the hostname is valid.
+ - Instead, git-annex init calls ensureCommit, which makes sure that git
+ - gets set up to allow committing.
+ -}
+checkEnvironment :: Annex ()
+checkEnvironment = do
+	gitusername <- fromRepo $ Git.Config.getMaybe "user.name"
+	when (isNothing gitusername || gitusername == Just "") $
+		unlessM userConfigOnly $
+			liftIO checkEnvironmentIO
+
+checkEnvironmentIO :: IO ()
+checkEnvironmentIO = whenM (isNothing <$> myUserGecos) $ do
+	username <- either (const "unknown") id <$> myUserName
+	ensureEnv "GIT_AUTHOR_NAME" username
+	ensureEnv "GIT_COMMITTER_NAME" username
+  where
+	-- existing environment is not overwritten
+	ensureEnv var val = setEnv var val False
+
+{- Runs an action that commits to the repository, and if it fails, 
+ - sets user.email and user.name to a dummy value and tries the action again.
+ -
+ - Note that user.email and user.name are left set afterwards, so this only
+ - needs to be used once to make sure that future commits will succeed.
+ -}
+ensureCommit :: Annex a -> Annex a
+ensureCommit a = either retry return =<< tryNonAsync a 
+  where
+	retry e = ifM userConfigOnly
+		( liftIO (throwIO e)
+		, do
+			name <- liftIO $ either (const "unknown") id <$> myUserName
+			setConfig "user.name" name
+			setConfig "user.email" name
+			a
+		)
+
+userConfigOnly :: Annex Bool
+userConfigOnly = do
+	v <- fromRepo $ Git.Config.getMaybe "user.useconfigonly"
+	return (fromMaybe False (Git.Config.isTrueFalse' =<< v))
diff --git a/Annex/Export.hs b/Annex/Export.hs
new file mode 100644
index 0000000000..60039ef3b9
--- /dev/null
+++ b/Annex/Export.hs
@@ -0,0 +1,72 @@
+{- git-annex exports
+ -
+ - Copyright 2017-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Export where
+
+import Annex
+import Annex.CatFile
+import Types
+import Types.Key
+import qualified Git
+import qualified Types.Remote as Remote
+import Git.Quote
+import Messages
+
+import Data.Maybe
+import qualified Data.ByteString.Short as S (fromShort, toShort)
+
+-- From a sha pointing to the content of a file to the key
+-- to use to export it. When the file is annexed, it's the annexed key.
+-- When the file is stored in git, it's a special type of key to indicate
+-- that.
+exportKey :: Git.Sha -> Annex Key
+exportKey sha = mk <$> catKey sha
+  where
+	mk (Just k) = k
+	mk Nothing = gitShaKey sha
+
+-- Encodes a git sha as a key. This is used to represent a non-annexed
+-- file that is stored on a special remote, which necessarily needs a
+-- key.
+--
+-- This is not the same as a SHA1 key, because the mapping needs to be
+-- bijective, also because git may not always use SHA1, and because git
+-- takes a SHA1 of the file size + content, while git-annex SHA1 keys
+-- only checksum the content.
+gitShaKey :: Git.Sha -> Key
+gitShaKey (Git.Ref s) = mkKey $ \kd -> kd
+	{ keyName = S.toShort s
+	, keyVariety = OtherKey "GIT"
+	}
+
+-- Reverse of gitShaKey
+keyGitSha :: Key -> Maybe Git.Sha
+keyGitSha k
+	| fromKey keyVariety k == OtherKey "GIT" =
+		Just (Git.Ref (S.fromShort (fromKey keyName k)))
+	| otherwise = Nothing
+
+-- Is a key storing a git sha, and not used for an annexed file?
+isGitShaKey :: Key -> Bool
+isGitShaKey = isJust . keyGitSha
+
+warnExportImportConflict :: Remote -> Annex ()
+warnExportImportConflict r = do
+	isimport <- Remote.isImportSupported r
+	isexport <- Remote.isExportSupported r
+	let (ops, resolvcmd) = case (isexport, isimport) of
+		(False, True) -> ("imported from", "git-annex import")
+		(True, False) -> ("exported to", "git-annex export")
+		_ -> ("exported to and/or imported from", "git-annex export")
+	toplevelWarning True $ UnquotedString $ unwords
+		[ "Conflict detected. Different trees have been"
+		, ops, Remote.name r ++ ". Use"
+		, resolvcmd
+		, "to resolve this conflict."
+		]
diff --git a/Annex/ExternalAddonProcess.hs b/Annex/ExternalAddonProcess.hs
new file mode 100644
index 0000000000..e573d2261d
--- /dev/null
+++ b/Annex/ExternalAddonProcess.hs
@@ -0,0 +1,100 @@
+{- External addon processes for special remotes and backends.
+ -
+ - Copyright 2013-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.ExternalAddonProcess where
+
+import qualified Annex
+import Annex.Common
+import Git.Env
+import Utility.Shell
+import Messages.Progress
+
+import Control.Concurrent.Async
+
+data ExternalAddonProcess = ExternalAddonProcess
+	{ externalSend :: Handle
+	, externalReceive :: Handle
+	-- Shut down the process. With True, it's forced to stop
+	-- immediately.
+	, externalShutdown :: Bool -> IO ()
+	, externalPid :: ExternalAddonPID
+	, externalProgram :: String
+	}
+
+type ExternalAddonPID = Int
+
+data ExternalAddonStartError
+	= ProgramNotInstalled String
+	| ProgramFailure String
+
+startExternalAddonProcess :: String -> [CommandParam] -> ExternalAddonPID -> Annex (Either ExternalAddonStartError ExternalAddonProcess)
+startExternalAddonProcess basecmd ps pid = do
+	errrelayer <- mkStderrRelayer
+	g <- Annex.gitRepo
+	cmdpath <- liftIO $ searchPath basecmd
+	liftIO $ start errrelayer g cmdpath
+  where
+	start errrelayer g cmdpath = do
+		(cmd, cmdps) <- maybe (pure (basecmd, [])) findShellCommand cmdpath
+		let basep = (proc cmd (toCommand (cmdps ++ ps)))
+			{ std_in = CreatePipe
+			, std_out = CreatePipe
+			, std_err = CreatePipe
+			}
+		p <- propgit g basep
+		tryNonAsync (createProcess p) >>= \case
+			Right v -> (Right <$> started cmd errrelayer v)
+				`catchNonAsync` const (runerr cmdpath)
+			Left _ -> runerr cmdpath
+	
+	started cmd errrelayer pall@(Just hin, Just hout, Just herr, ph) = do
+		stderrelay <- async $ errrelayer ph herr
+		let shutdown forcestop = do
+			-- Close the process's stdin, to let it know there
+			-- are no more requests, so it will exit.
+			hClose hout
+			-- Close the procces's stdout as we're not going to
+			-- process any more output from it.
+			hClose hin
+			if forcestop
+				then cleanupProcess pall
+				else void (waitForProcess ph)
+					`onException` cleanupProcess pall
+			-- This thread will exit after consuming any
+			-- remaining stderr from the process.
+			() <- wait stderrelay
+			hClose herr
+		return $ ExternalAddonProcess
+			{ externalSend = hin
+			, externalReceive = hout
+			, externalPid = pid
+			, externalShutdown = shutdown
+			, externalProgram = cmd
+			}
+	started _ _ _ = giveup "internal"
+
+	propgit g p = do
+		environ <- propGitEnv g
+		return $ p { env = Just environ }
+
+	runerr (Just cmd) =
+		return $ Left $ ProgramFailure $
+			"Cannot run " ++ cmd ++ " -- Make sure it's executable and that its dependencies are installed."
+	runerr Nothing = do
+		path <- intercalate ":" <$> getSearchPath
+		return $ Left $ ProgramNotInstalled $
+			"Cannot run " ++ basecmd ++ " -- It is not installed in PATH (" ++ path ++ ")"
+
+protocolDebug :: ExternalAddonProcess -> Bool -> String -> IO ()
+protocolDebug external sendto line = debug "Annex.ExternalAddonProcess" $ unwords
+	[ externalProgram external ++ 
+		"[" ++ show (externalPid external) ++ "]"
+	, if sendto then "<--" else "-->"
+	, line
+	]
diff --git a/Annex/FileMatcher.hs b/Annex/FileMatcher.hs
new file mode 100644
index 0000000000..e48931f360
--- /dev/null
+++ b/Annex/FileMatcher.hs
@@ -0,0 +1,278 @@
+{- git-annex file matching
+ -
+ - Copyright 2012-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Annex.FileMatcher (
+	GetFileMatcher,
+	checkFileMatcher,
+	checkFileMatcher',
+	checkMatcher,
+	checkMatcher',
+	matchAll,
+	PreferredContentData(..),
+	preferredContentTokens,
+	preferredContentParser,
+	ParseToken,
+	parsedToMatcher,
+	mkMatchExpressionParser,
+	largeFilesMatcher,
+	AddUnlockedMatcher,
+	addUnlockedMatcher,
+	checkAddUnlockedMatcher,
+	LimitBy(..),
+	module Types.FileMatcher
+) where
+
+import qualified Data.Map as M
+
+import Annex.Common
+import Limit
+import Utility.Matcher
+import Types.Group
+import Types.FileMatcher
+import Types.GitConfig
+import Config.GitConfig
+import Annex.SpecialRemote.Config (preferreddirField)
+import Git.FilePath
+import Types.Remote (RemoteConfig)
+import Types.ProposedAccepted
+import Annex.CheckAttr
+import qualified Git.Config
+#ifdef WITH_MAGICMIME
+import Annex.Magic
+#endif
+
+import Data.Either
+import qualified Data.Set as S
+import Control.Monad.Writer
+
+type GetFileMatcher = RawFilePath -> Annex (FileMatcher Annex)
+
+checkFileMatcher :: GetFileMatcher -> RawFilePath -> Annex Bool
+checkFileMatcher getmatcher file =
+	checkFileMatcher' getmatcher file (return True)
+
+-- | Allows running an action when no matcher is configured for the file.
+checkFileMatcher' :: GetFileMatcher -> RawFilePath -> Annex Bool -> Annex Bool
+checkFileMatcher' getmatcher file notconfigured = do
+	matcher <- getmatcher file
+	checkMatcher matcher Nothing afile S.empty notconfigured d
+  where
+	afile = AssociatedFile (Just file)
+	-- checkMatcher will never use this, because afile is provided.
+	d = return True
+
+checkMatcher :: FileMatcher Annex -> Maybe Key -> AssociatedFile -> AssumeNotPresent -> Annex Bool -> Annex Bool -> Annex Bool
+checkMatcher matcher mkey afile notpresent notconfigured d
+	| isEmpty (fst matcher) = notconfigured
+	| otherwise = case (mkey, afile) of
+		(_, AssociatedFile (Just file)) ->
+			go =<< fileMatchInfo file mkey
+		(Just key, AssociatedFile Nothing) ->
+			let i = ProvidedInfo
+				{ providedFilePath = Nothing
+				, providedKey = Just key
+				, providedFileSize = Nothing
+				, providedMimeType = Nothing
+				, providedMimeEncoding = Nothing
+				, providedLinkType = Nothing
+				}
+			in go (MatchingInfo i)
+		(Nothing, _) -> d
+  where
+	go mi = checkMatcher' matcher mi notpresent
+
+checkMatcher' :: FileMatcher Annex -> MatchInfo -> AssumeNotPresent -> Annex Bool
+checkMatcher' (matcher, (MatcherDesc matcherdesc)) mi notpresent = do
+	(matches, desc) <- runWriterT $ matchMrun' matcher $ \op ->
+		matchAction op notpresent mi
+	explain (mkActionItem mi) $ UnquotedString <$>
+		describeMatchResult matchDesc desc
+			((if matches then "matches " else "does not match ") ++ matcherdesc ++ ": ")
+	return matches
+
+fileMatchInfo :: RawFilePath -> Maybe Key -> Annex MatchInfo
+fileMatchInfo file mkey = do
+	matchfile <- getTopFilePath <$> inRepo (toTopFilePath file)
+	return $ MatchingFile FileInfo
+		{ matchFile = matchfile
+		, contentFile = file
+		, matchKey = mkey
+		}
+
+matchAll :: Matcher (MatchFiles Annex)
+matchAll = generate []
+
+parsedToMatcher :: MatcherDesc -> [ParseResult (MatchFiles Annex)] -> Either String (FileMatcher Annex)
+parsedToMatcher matcherdesc parsed = case partitionEithers parsed of
+	([], vs) -> Right (generate vs, matcherdesc)
+	(es, _) -> Left $ unwords $ map ("Parse failure: " ++) es
+
+data ParseToken t
+	= SimpleToken String (ParseResult t)
+	| ValueToken String (String -> ParseResult t)
+
+type ParseResult t = Either String (Token t)
+
+parseToken :: [ParseToken t] -> String -> ParseResult t
+parseToken l t = case syntaxToken t of
+	Right st -> Right st
+	Left _ -> go l
+  where
+	go [] = Left $ "near " ++ show t
+	go (SimpleToken s r : _) | s == t = r
+	go (ValueToken s mkr : _) | s == k = mkr v
+	go (_ : ps) = go ps
+	(k, v) = separate (== '=') t
+
+{- This is really dumb tokenization; there's no support for quoted values.
+ - Open and close parens are always treated as standalone tokens;
+ - otherwise tokens must be separated by whitespace. -}
+tokenizeMatcher :: String -> [String]
+tokenizeMatcher = filter (not . null) . concatMap splitparens . words
+  where
+	splitparens = segmentDelim (`elem` "()")
+
+commonTokens :: LimitBy -> [ParseToken (MatchFiles Annex)]
+commonTokens lb =
+	[ SimpleToken "anything" (simply limitAnything)
+	, SimpleToken "nothing" (simply limitNothing)
+	, ValueToken "include" (usev limitInclude)
+	, ValueToken "exclude" (usev limitExclude)
+	, ValueToken "largerthan" (usev $ limitSize lb "largerthan" (>))
+	, ValueToken "smallerthan" (usev $ limitSize lb "smallerthan" (<))
+	, SimpleToken "unused" (simply limitUnused)
+	]
+
+data PreferredContentData = PCD
+	{ matchStandard :: Either String (Matcher (MatchFiles Annex))
+	, matchGroupWanted :: Either String (Matcher (MatchFiles Annex))
+	, getGroupMap :: Annex GroupMap
+	, configMap :: M.Map UUID RemoteConfig
+	, repoUUID :: Maybe UUID
+	}
+
+preferredContentTokens :: PreferredContentData -> [ParseToken (MatchFiles Annex)]
+preferredContentTokens pcd =
+	[ SimpleToken "standard" (call "standard" $ matchStandard pcd)
+	, SimpleToken "groupwanted" (call "groupwanted" $ matchGroupWanted pcd)
+	, SimpleToken "inpreferreddir" (simply $ limitInDir preferreddir "inpreferreddir")
+	, SimpleToken "present" (simply $ limitPresent $ repoUUID pcd)
+	, SimpleToken "securehash" (simply limitSecureHash)
+	, ValueToken "copies" (usev limitCopies)
+	, ValueToken "lackingcopies" (usev $ limitLackingCopies "lackingcopies" False)
+	, ValueToken "approxlackingcopies" (usev $ limitLackingCopies "approxlackingcopies" True)
+	, ValueToken "inbackend" (usev limitInBackend)
+	, ValueToken "metadata" (usev limitMetaData)
+	, ValueToken "inallgroup" (usev $ limitInAllGroup $ getGroupMap pcd)
+	, ValueToken "onlyingroup" (usev $ limitOnlyInGroup $ getGroupMap pcd)
+	] ++ commonTokens LimitAnnexFiles
+  where
+	preferreddir = maybe "public" fromProposedAccepted $
+		M.lookup preferreddirField =<< (`M.lookup` configMap pcd) =<< repoUUID pcd
+
+preferredContentParser :: [ParseToken (MatchFiles Annex)] -> String -> [ParseResult (MatchFiles Annex)]
+preferredContentParser tokens = map (parseToken tokens) . tokenizeMatcher
+
+mkMatchExpressionParser :: Annex (String -> [ParseResult (MatchFiles Annex)])
+mkMatchExpressionParser = do
+#ifdef WITH_MAGICMIME
+	magicmime <- liftIO initMagicMime
+	let mimer n f = ValueToken n (usev $ f magicmime)
+#else
+	let mimer n = ValueToken n $ 
+		const $ Left $ "\""++n++"\" not supported; not built with MagicMime support"
+#endif
+	let parse = parseToken $
+		commonTokens LimitDiskFiles ++
+#ifdef WITH_MAGICMIME
+		[ mimer "mimetype" $
+			matchMagic "mimetype" getMagicMimeType providedMimeType userProvidedMimeType
+		, mimer "mimeencoding" $
+			matchMagic "mimeencoding" getMagicMimeEncoding providedMimeEncoding userProvidedMimeEncoding
+		]
+#else
+		[ mimer "mimetype"
+		, mimer "mimeencoding"
+		]
+#endif
+	return $ map parse . tokenizeMatcher
+
+{- Generates a matcher for files large enough (or meeting other criteria)
+ - to be added to the annex, rather than directly to git.
+ -
+ - annex.largefiles is configured in git config, or git attributes,
+ - or global git-annex config, in that order.
+ -}
+largeFilesMatcher :: Annex GetFileMatcher
+largeFilesMatcher = go =<< getGitConfigVal' annexLargeFiles
+  where
+	matcherdesc = MatcherDesc "annex.largefiles"
+	go (HasGitConfig (Just expr)) = do
+		matcher <- mkmatcher expr "git config"
+		return $ const $ return matcher
+	go v = return $ \file -> do
+		expr <- checkAttr "annex.largefiles" file
+		if null expr
+			then case v of
+				HasGlobalConfig (Just expr') ->
+					mkmatcher expr' "git-annex config"
+				_ -> return (matchAll, matcherdesc)
+			else mkmatcher expr "gitattributes"
+
+	mkmatcher expr cfgfrom = do
+		parser <- mkMatchExpressionParser
+		either (badexpr cfgfrom) return $ parsedToMatcher matcherdesc $ parser expr
+
+	badexpr cfgfrom e = giveup $ "bad annex.largefiles configuration in " ++ cfgfrom ++ ": " ++ e
+
+newtype AddUnlockedMatcher = AddUnlockedMatcher (FileMatcher Annex)
+
+addUnlockedMatcher :: Annex AddUnlockedMatcher
+addUnlockedMatcher = AddUnlockedMatcher <$>
+	(go =<< getGitConfigVal' annexAddUnlocked)
+  where
+	go (HasGitConfig (Just expr)) = mkmatcher expr "git config"
+	go (HasGlobalConfig (Just expr)) = mkmatcher expr "git annex config"
+	go _ = matchalways False
+
+	matcherdesc = MatcherDesc "annex.addunlocked"
+
+	mkmatcher :: String -> String -> Annex (FileMatcher Annex)
+	mkmatcher expr cfgfrom = case Git.Config.isTrueFalse expr of
+		Just b -> matchalways b
+		Nothing -> do
+			parser <- mkMatchExpressionParser
+			either (badexpr cfgfrom) return $ parsedToMatcher matcherdesc $ parser expr
+
+	badexpr cfgfrom e = giveup $ "bad annex.addunlocked configuration in " ++ cfgfrom ++ ": " ++ e
+
+	matchalways True = return (MOp limitAnything, matcherdesc)
+	matchalways False = return (MOp limitNothing, matcherdesc)
+
+checkAddUnlockedMatcher :: AddUnlockedMatcher -> MatchInfo -> Annex Bool
+checkAddUnlockedMatcher (AddUnlockedMatcher matcher) mi = 
+	checkMatcher' matcher mi S.empty
+
+simply :: MatchFiles Annex -> ParseResult (MatchFiles Annex)
+simply = Right . Operation
+
+usev :: MkLimit Annex -> String -> ParseResult (MatchFiles Annex)
+usev a v = Operation <$> a v
+
+call :: String -> Either String (Matcher (MatchFiles Annex)) -> ParseResult (MatchFiles Annex)
+call desc (Right sub) = Right $ Operation $ MatchFiles
+	{ matchAction = \notpresent mi ->
+		matchMrun sub $ \o -> matchAction o notpresent mi
+	, matchNeedsFileName = any matchNeedsFileName sub
+	, matchNeedsFileContent = any matchNeedsFileContent sub
+	, matchNeedsKey = any matchNeedsKey sub
+	, matchNeedsLocationLog = any matchNeedsLocationLog sub
+	, matchDesc = matchDescSimple desc
+	}
+call _ (Left err) = Left err
diff --git a/Annex/Fixup.hs b/Annex/Fixup.hs
new file mode 100644
index 0000000000..a60e4baa0b
--- /dev/null
+++ b/Annex/Fixup.hs
@@ -0,0 +1,155 @@
+{- git-annex repository fixups
+ -
+ - Copyright 2013-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Fixup where
+
+import Git.Types
+import Git.Config
+import Types.GitConfig
+import Utility.Path
+import Utility.Path.AbsRel
+import Utility.SafeCommand
+import Utility.Directory
+import Utility.Exception
+import Utility.Monad
+import Utility.FileSystemEncoding
+import qualified Utility.RawFilePath as R
+import Utility.PartialPrelude
+
+import System.IO
+import Data.List
+import Data.Maybe
+import Control.Monad
+import Control.Monad.IfElse
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import System.FilePath.ByteString
+import Control.Applicative
+import Prelude
+
+fixupRepo :: Repo -> GitConfig -> IO Repo
+fixupRepo r c = do
+	let r' = disableWildcardExpansion r
+	r'' <- fixupUnusualRepos r' c
+	if annexDirect c
+		then return (fixupDirect r'')
+		else return r''
+
+{- Disable git's built-in wildcard expansion, which is not wanted
+ - when using it as plumbing by git-annex. -}
+disableWildcardExpansion :: Repo -> Repo
+disableWildcardExpansion r = r
+	{ gitGlobalOpts = gitGlobalOpts r ++ [Param "--literal-pathspecs"] }
+
+{- Direct mode repos have core.bare=true, but are not really bare.
+ - Fix up the Repo to be a non-bare repo, and arrange for git commands
+ - run by git-annex to be passed parameters that override this setting. -}
+fixupDirect :: Repo -> Repo
+fixupDirect r@(Repo { location = l@(Local { gitdir = d, worktree = Nothing }) }) = do
+	r
+		{ location = l { worktree = Just (parentDir d) }
+		, gitGlobalOpts = gitGlobalOpts r ++
+			[ Param "-c"
+			, Param $ fromConfigKey coreBare ++ "=" ++ boolConfig False
+			]
+		}
+fixupDirect r = r
+
+{- Submodules have their gitdir containing ".git/modules/", and
+ - have core.worktree set, and also have a .git file in the top
+ - of the repo. We need to unset core.worktree, and change the .git
+ - file into a symlink to the git directory. This way, annex symlinks will be
+ - of the usual .git/annex/object form, and will consistently work
+ - whether a repo is used as a submodule or not, and wheverever the
+ - submodule is mounted.
+ -
+ - git-worktree directories have a .git file.
+ - That needs to be converted to a symlink, and .git/annex made a symlink
+ - to the main repository's git-annex directory.
+ - The worktree shares git config with the main repository, so the same
+ - annex uuid and other configuration will be used in the worktree as in
+ - the main repository.
+ -
+ - git clone or init with --separate-git-dir similarly makes a .git file,
+ - which in that case points to a different git directory. It's
+ - also converted to a symlink so links to .git/annex will work. 
+ - 
+ - When the filesystem doesn't support symlinks, we cannot make .git
+ - into a symlink. But we don't need too, since the repo will use adjusted
+ - unlocked branches.
+ -
+ - Don't do any of this if the repo has not been initialized for git-annex
+ - use yet.
+ -}
+fixupUnusualRepos :: Repo -> GitConfig -> IO Repo
+fixupUnusualRepos r@(Repo { location = l@(Local { worktree = Just w, gitdir = d }) }) c
+	| isNothing (annexVersion c) = return r
+	| needsSubmoduleFixup r = do
+		when (coreSymlinks c) $
+			(replacedotgit >> unsetcoreworktree)
+				`catchNonAsync` \e -> hPutStrLn stderr $
+					"warning: unable to convert submodule to form that will work with git-annex: " ++ show e
+		return $ r'
+			{ config = M.delete "core.worktree" (config r)
+			}
+	| otherwise = ifM (needsGitLinkFixup r)
+		( do
+			when (coreSymlinks c) $
+				(replacedotgit >> worktreefixup)
+					`catchNonAsync` \e -> hPutStrLn stderr $
+						"warning: unable to convert .git file to symlink that will work with git-annex: " ++ show e
+			return r'
+		, return r
+		)
+  where
+	dotgit = w </> ".git"
+
+	replacedotgit = whenM (doesFileExist (fromRawFilePath dotgit)) $ do
+		linktarget <- relPathDirToFile w d
+		removeWhenExistsWith R.removeLink dotgit
+		R.createSymbolicLink linktarget dotgit
+	
+	-- Unsetting a config fails if it's not set, so ignore failure.
+	unsetcoreworktree = void $ Git.Config.unset "core.worktree" r
+	
+	worktreefixup =
+		-- git-worktree sets up a "commondir" file that contains
+		-- the path to the main git directory.
+		-- Using --separate-git-dir does not.
+		catchDefaultIO Nothing (headMaybe . lines <$> readFile (fromRawFilePath (d </> "commondir"))) >>= \case
+			Just gd -> do
+				-- Make the worktree's git directory
+				-- contain an annex symlink to the main
+				-- repository's annex directory.
+				let linktarget = toRawFilePath gd </> "annex"
+				R.createSymbolicLink linktarget
+					(dotgit </> "annex")
+			Nothing -> return ()
+
+	-- Repo adjusted, so that symlinks to objects that get checked
+	-- in will have the usual path, rather than pointing off to the
+	-- real .git directory.
+	r'
+		| coreSymlinks c = r { location = l { gitdir = dotgit } }
+		| otherwise = r
+fixupUnusualRepos r _ = return r
+
+needsSubmoduleFixup :: Repo -> Bool
+needsSubmoduleFixup (Repo { location = (Local { worktree = Just _, gitdir = d }) }) =
+	(".git" </> "modules") `S.isInfixOf` d
+needsSubmoduleFixup _ = False
+
+needsGitLinkFixup :: Repo -> IO Bool
+needsGitLinkFixup (Repo { location = (Local { worktree = Just wt, gitdir = d }) })
+	-- Optimization: Avoid statting .git in the common case; only
+	-- when the gitdir is not in the usual place inside the worktree
+	-- might .git be a file.
+	| wt </> ".git" == d = return False
+	| otherwise = doesFileExist (fromRawFilePath (wt </> ".git"))
+needsGitLinkFixup _ = return False
diff --git a/Annex/GitOverlay.hs b/Annex/GitOverlay.hs
new file mode 100644
index 0000000000..5388c1bfc6
--- /dev/null
+++ b/Annex/GitOverlay.hs
@@ -0,0 +1,124 @@
+{- Temporarily changing how git-annex runs git commands.
+ -
+ - Copyright 2014-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.GitOverlay (
+	module Annex.GitOverlay,
+	AltIndexFile(..),
+) where
+
+import qualified Control.Exception as E
+
+import Annex.Common
+import Types.IndexFiles
+import Git
+import Git.Types
+import Git.Index
+import Git.Env
+import qualified Annex
+import qualified Annex.Queue
+import Config.Smudge
+
+{- Runs an action using a different git index file. -}
+withIndexFile :: AltIndexFile -> (FilePath -> Annex a) -> Annex a
+withIndexFile i = withAltRepo usecachedgitenv restoregitenv
+  where
+	-- This is an optimisation. Since withIndexFile is run repeatedly,
+	-- typically with the same file, and addGitEnv uses the slow
+	-- getEnvironment when gitEnv is Nothing, and has to do a
+	-- nontrivial amount of work, we cache the modified environment
+	-- the first time, and reuse it in subsequent calls for the same
+	-- index file.
+	--
+	-- (This could be done at another level; eg when creating the
+	-- Git object in the first place, but it's more efficient to let
+	-- the environment be inherited in all calls to git where it
+	-- does not need to be modified.)
+	--
+	-- Also, the use of AltIndexFile avoids needing to construct
+	-- the FilePath each time, which saves enough time to be worth the
+	-- added complication.
+	usecachedgitenv g = case gitEnv g of
+		Nothing -> Annex.withState $ \s -> case Annex.cachedgitenv s of
+			Just (cachedi, cachedf, cachede) | i == cachedi ->
+				return (s, (g { gitEnv = Just cachede }, cachedf))
+			_ -> do
+				r@(g', f) <- addindex g
+				let cache = (,,)
+					<$> Just i
+					<*> Just f
+					<*> gitEnv g'
+				return (s { Annex.cachedgitenv = cache }, r)
+		Just _ -> liftIO $ addindex g
+	
+	addindex g = do
+		f <- indexEnvVal $ case i of
+			AnnexIndexFile -> gitAnnexIndex g
+			ViewIndexFile -> gitAnnexViewIndex g
+		g' <- addGitEnv g indexEnv f
+		return (g', f)
+	
+	restoregitenv g g' = g' { gitEnv = gitEnv g }
+
+{- Runs an action using a different git work tree.
+ -
+ - Smudge and clean filters are disabled in this work tree. -}
+withWorkTree :: FilePath -> Annex a -> Annex a
+withWorkTree d a = withAltRepo
+	(\g -> return $ (g { location = modlocation (location g), gitGlobalOpts = gitGlobalOpts g ++ bypassSmudgeConfig }, ()))
+	(\g g' -> g' { location = location g, gitGlobalOpts = gitGlobalOpts g })
+	(const a)
+  where
+	modlocation l@(Local {}) = l { worktree = Just (toRawFilePath d) }
+	modlocation _ = giveup "withWorkTree of non-local git repo"
+
+{- Runs an action with the git index file and HEAD, and a few other
+ - files that are related to the work tree coming from an overlay
+ - directory other than the usual. This is done by pointing
+ - GIT_COMMON_DIR at the regular git directory, and GIT_DIR at the
+ - overlay directory.
+ -
+ - Needs git 2.2.0 or newer.
+ -}
+withWorkTreeRelated :: FilePath -> Annex a -> Annex a
+withWorkTreeRelated d a = withAltRepo modrepo unmodrepo (const a)
+  where
+	modrepo g = liftIO $ do
+		g' <- addGitEnv g "GIT_COMMON_DIR" . fromRawFilePath
+			=<< absPath (localGitDir g)
+		g'' <- addGitEnv g' "GIT_DIR" d
+		return (g'' { gitEnvOverridesGitDir = True }, ())
+	unmodrepo g g' = g'
+		{ gitEnv = gitEnv g
+		, gitEnvOverridesGitDir = gitEnvOverridesGitDir g
+		}
+
+withAltRepo 
+	:: (Repo -> Annex (Repo, t))
+	-- ^ modify Repo
+	-> (Repo -> Repo -> Repo)
+	-- ^ undo modifications; first Repo is the original and second
+	-- is the one after running the action.
+	-> (t -> Annex a)
+	-> Annex a
+withAltRepo modrepo unmodrepo a = do
+	g <- gitRepo
+	(g', t) <- modrepo g
+	q <- Annex.Queue.get
+	v <- tryNonAsync $ do
+		Annex.changeState $ \s -> s
+			{ Annex.repo = g'
+			-- Start a separate queue for any changes made
+			-- with the modified repo.
+			, Annex.repoqueue = Nothing
+			}
+		a t
+	void $ tryNonAsync Annex.Queue.flush
+	Annex.changeState $ \s -> s
+		{ Annex.repo = unmodrepo g (Annex.repo s)
+		, Annex.repoqueue = Just q
+		}
+	either E.throw return v
diff --git a/Annex/HashObject.hs b/Annex/HashObject.hs
new file mode 100644
index 0000000000..4a0ea187ed
--- /dev/null
+++ b/Annex/HashObject.hs
@@ -0,0 +1,66 @@
+{- git hash-object interface
+ -
+ - Copyright 2016-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.HashObject (
+	hashFile,
+	hashBlob,
+	hashObjectStop,
+	mkConcurrentHashObjectHandle,
+	withHashObjectHandle,
+) where
+
+import Annex.Common
+import qualified Git.HashObject
+import qualified Annex
+import Git.Types
+import Utility.ResourcePool
+import Types.Concurrency
+import Annex.Concurrent.Utility
+
+hashObjectStop :: Annex ()
+hashObjectStop = maybe noop stop =<< Annex.getState Annex.hashobjecthandle
+  where
+	stop p = do
+		liftIO $ freeResourcePool p Git.HashObject.hashObjectStop
+		Annex.changeState $ \s -> s { Annex.hashobjecthandle = Nothing }
+
+hashFile :: RawFilePath -> Annex Sha
+hashFile f = withHashObjectHandle $ \h -> 
+	liftIO $ Git.HashObject.hashFile h f
+
+{- Note that the content will be written to a temp file.
+ - So it may be faster to use Git.HashObject.hashObject for large
+ - blob contents. -}
+hashBlob :: Git.HashObject.HashableBlob b => b -> Annex Sha
+hashBlob content = withHashObjectHandle $ \h ->
+	liftIO $ Git.HashObject.hashBlob h content
+
+withHashObjectHandle :: (Git.HashObject.HashObjectHandle -> Annex a) -> Annex a
+withHashObjectHandle a =
+	maybe mkpool go =<< Annex.getState Annex.hashobjecthandle
+  where
+	go p = withResourcePool p start a
+	start = inRepo $ Git.HashObject.hashObjectStart True
+	mkpool = do
+		-- This only runs in non-concurrent code paths;
+		-- a concurrent pool is set up earlier when needed.
+		p <- mkResourcePoolNonConcurrent start
+		Annex.changeState $ \s -> s { Annex.hashobjecthandle = Just p }
+		go p
+
+mkConcurrentHashObjectHandle :: Concurrency -> Annex (ResourcePool Git.HashObject.HashObjectHandle)
+mkConcurrentHashObjectHandle c =
+        Annex.getState Annex.hashobjecthandle >>= \case
+                Just p@(ResourcePool {}) -> return p
+                _ -> mkResourcePool =<< liftIO (maxHashObjects c)
+
+{- git hash-object is typically CPU bound, and is not likely to be the main
+ - bottleneck for any command. So limit to the number of CPU cores, maximum,
+ - while respecting the -Jn value.
+ -}
+maxHashObjects :: Concurrency -> IO Int
+maxHashObjects = concurrencyUpToCpus
diff --git a/Annex/Hook.hs b/Annex/Hook.hs
new file mode 100644
index 0000000000..8c6d648fb0
--- /dev/null
+++ b/Annex/Hook.hs
@@ -0,0 +1,88 @@
+{- git-annex git hooks
+ -
+ - Note that it's important that the content of scripts installed by
+ - git-annex not change, otherwise removing old hooks using an old
+ - version of the script would fail.
+ -
+ - Copyright 2013-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.Hook where
+
+import Annex.Common
+import qualified Git.Hook as Git
+import qualified Annex
+import Utility.Shell
+
+import qualified Data.Map as M
+
+preCommitHook :: Git.Hook
+preCommitHook = Git.Hook "pre-commit" (mkHookScript "git annex pre-commit .") []
+
+postReceiveHook :: Git.Hook
+postReceiveHook = Git.Hook "post-receive"
+	-- Only run git-annex post-receive when git-annex supports it,
+	-- to avoid failing if the repository with this hook is used
+	-- with an older version of git-annex.
+	(mkHookScript "if git annex post-receive --help >/dev/null 2>&1; then git annex post-receive; fi")
+	-- This is an old version of the hook script.
+	[ mkHookScript "git annex post-receive"
+	]
+
+postCheckoutHook :: Git.Hook
+postCheckoutHook = Git.Hook "post-checkout" smudgeHook []
+
+postMergeHook :: Git.Hook
+postMergeHook = Git.Hook "post-merge" smudgeHook []
+
+-- Older versions of git-annex didn't support this command, but neither did
+-- they support v7 repositories.
+smudgeHook :: String
+smudgeHook = mkHookScript "git annex smudge --update"
+
+preCommitAnnexHook :: Git.Hook
+preCommitAnnexHook = Git.Hook "pre-commit-annex" "" []
+
+postUpdateAnnexHook :: Git.Hook
+postUpdateAnnexHook = Git.Hook "post-update-annex" "" []
+
+mkHookScript :: String -> String
+mkHookScript s = unlines
+	[ shebang
+	, "# automatically configured by git-annex"
+	, s
+	]
+
+hookWrite :: Git.Hook -> Annex ()
+hookWrite h = unlessM (inRepo $ Git.hookWrite h) $
+	hookWarning h "already exists, not configuring"
+
+hookUnWrite :: Git.Hook -> Annex ()
+hookUnWrite h = unlessM (inRepo $ Git.hookUnWrite h) $
+	hookWarning h "contents modified; not deleting. Edit it to remove call to git annex."
+
+hookWarning :: Git.Hook -> String -> Annex ()
+hookWarning h msg = do
+	r <- gitRepo
+	warning $ UnquotedString $
+		Git.hookName h ++ " hook (" ++ Git.hookFile h r ++ ") " ++ msg
+
+{- Runs a hook. To avoid checking if the hook exists every time,
+ - the existing hooks are cached. -}
+runAnnexHook :: Git.Hook -> Annex ()
+runAnnexHook hook = do
+	m <- Annex.getState Annex.existinghooks
+	case M.lookup hook m of
+		Just True -> run
+		Just False -> noop
+		Nothing -> do
+			exists <- inRepo $ Git.hookExists hook
+			Annex.changeState $ \s -> s
+				{ Annex.existinghooks = M.insert hook exists m }
+			when exists run
+  where
+	run = unlessM (inRepo $ Git.runHook hook) $ do
+		h <- fromRepo $ Git.hookFile hook
+		warning $ UnquotedString $ h ++ " failed"
diff --git a/Annex/Import.hs b/Annex/Import.hs
new file mode 100644
index 0000000000..2778740382
--- /dev/null
+++ b/Annex/Import.hs
@@ -0,0 +1,1105 @@
+{- git-annex import from remotes
+ -
+ - Copyright 2019-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Import (
+	ImportTreeConfig(..),
+	ImportCommitConfig(..),
+	buildImportCommit,
+	buildImportTrees,
+	recordImportTree,
+	canImportKeys,
+	ImportResult(..),
+	Imported,
+	importChanges,
+	importKeys,
+	makeImportMatcher,
+	getImportableContents,
+) where
+
+import Annex.Common
+import Types.Import
+import qualified Types.Remote as Remote
+import Git.Types
+import Git.Tree
+import Git.Sha
+import Git.FilePath
+import Git.History
+import qualified Git.DiffTree
+import qualified Git.Ref
+import qualified Git.Branch
+import qualified Annex
+import Annex.Link
+import Annex.LockFile
+import Annex.Content
+import Annex.Export
+import Annex.RemoteTrackingBranch
+import Annex.HashObject
+import Annex.Transfer
+import Annex.CheckIgnore
+import Annex.CatFile
+import Annex.VectorClock
+import Command
+import Backend
+import Types.Key
+import Types.KeySource
+import Messages.Progress
+import Utility.DataUnits
+import Utility.Metered
+import Utility.Hash (sha1s)
+import Logs.Import
+import Logs.Export
+import Logs.Location
+import Logs.PreferredContent
+import Types.FileMatcher
+import Annex.FileMatcher
+import qualified Utility.Matcher
+import qualified Database.Export as Export
+import qualified Database.ContentIdentifier as CIDDb
+import qualified Logs.ContentIdentifier as CIDLog
+import Backend.Utilities
+
+import Control.Concurrent.STM
+import qualified Data.Map.Strict as M
+import qualified Data.Set as S
+import qualified System.FilePath.Posix.ByteString as Posix
+import qualified System.FilePath.ByteString as P
+import qualified Data.ByteArray.Encoding as BA
+
+{- Configures how to build an import tree. -}
+data ImportTreeConfig
+	= ImportTree
+	-- ^ Import the tree as-is from the remote.
+	| ImportSubTree TopFilePath Sha
+	-- ^ Import a tree from the remote and graft it into a subdirectory
+	-- of the existing tree whose Sha is provided, replacing anything
+	-- that was there before.
+	deriving (Show)
+
+{- Configures how to build an import commit. -}
+data ImportCommitConfig = ImportCommitConfig
+	{ importCommitTracking :: Maybe Sha
+	-- ^ Current commit on the remote tracking branch.
+	, importCommitMode :: Git.Branch.CommitMode
+	, importCommitMessages :: [String]
+	}
+
+{- Buils a commit for an import from a special remote.
+ -
+ - When there are no changes to make (importCommitTracking
+ - already matches what was imported), returns Nothing.
+ -
+ - After importing from a remote, exporting the same thing back to the
+ - remote should be a no-op. So, the export log and database are
+ - updated to reflect the imported tree.
+ -
+ - This does not download any content from a remote. But since it needs the
+ - Key of imported files to be known, its caller will have to first download
+ - new files in order to generate keys for them.
+ -}
+buildImportCommit
+	:: Remote
+	-> ImportTreeConfig
+	-> ImportCommitConfig
+	-> Imported
+	-> Annex (Maybe Ref)
+buildImportCommit remote importtreeconfig importcommitconfig imported =
+	case importCommitTracking importcommitconfig of
+		Nothing -> go Nothing
+		Just trackingcommit -> inRepo (Git.Ref.tree trackingcommit) >>= \case
+			Nothing -> go Nothing
+			Just _ -> go (Just trackingcommit)
+  where
+	go trackingcommit = do
+		(importedtree, updatestate) <- recordImportTree remote importtreeconfig imported
+		buildImportCommit' remote importcommitconfig trackingcommit importedtree >>= \case
+			Just finalcommit -> do
+				updatestate
+				return (Just finalcommit)
+			Nothing -> return Nothing
+
+{- Builds a tree for an import from a special remote.
+ -
+ - Also returns an action that can be used to update 
+ - all the other state to record the import.
+ -}
+recordImportTree
+	:: Remote
+	-> ImportTreeConfig
+	-> Imported
+	-> Annex (History Sha, Annex ())
+recordImportTree remote importtreeconfig imported = do
+	importedtree@(History finaltree _) <- buildImportTrees basetree subdir imported
+	return (importedtree, updatestate finaltree)
+  where
+	basetree = case importtreeconfig of
+		ImportTree -> emptyTree
+		ImportSubTree _ sha -> sha
+	subdir = case importtreeconfig of
+		ImportTree -> Nothing
+		ImportSubTree dir _ -> Just dir
+	
+	updatestate finaltree = do
+		importedtree <- case subdir of
+			Nothing -> pure finaltree
+			Just dir -> 
+				let subtreeref = Ref $
+					fromRef' finaltree
+						<> ":"
+						<> getTopFilePath dir
+				in fromMaybe emptyTree
+					<$> inRepo (Git.Ref.tree subtreeref)
+		updateexportdb importedtree
+		oldexport <- updateexportlog importedtree
+		updatelocationlog oldexport importedtree
+	
+	updateexportdb importedtree = do
+		db <- Export.openDb (Remote.uuid remote)
+		Export.writeLockDbWhile db $ do
+			prevtree <- liftIO $ fromMaybe emptyTree
+				<$> Export.getExportTreeCurrent db
+			when (importedtree /= prevtree) $ do
+				Export.updateExportDb db prevtree importedtree
+				liftIO $ Export.recordExportTreeCurrent db importedtree
+		Export.closeDb db
+	
+	updateexportlog importedtree = do
+		oldexport <- getExport (Remote.uuid remote)
+		recordExport (Remote.uuid remote) importedtree $ ExportChange
+			{ oldTreeish = exportedTreeishes oldexport
+			, newTreeish = importedtree
+			}
+		return oldexport
+
+	-- downloadImport takes care of updating the location log
+	-- for the local repo when keys are downloaded, and also updates
+	-- the location log for the remote for keys that are present in it.
+	-- That leaves updating the location log for the remote for keys
+	-- that have had the last copy of their content removed from it.
+	--
+	-- This must run after the export database has been updated
+	-- and flushed to disk, so it can query it.
+	updatelocationlog oldexport finaltree = do
+		let stillpresent db k = liftIO $ not . null
+			<$> Export.getExportedLocation db k
+		let updater db moldkey _newkey _ = case moldkey of
+			Just oldkey | not (isGitShaKey oldkey) ->
+				unlessM (stillpresent db oldkey) $
+					logChange oldkey (Remote.uuid remote) InfoMissing
+			_ -> noop
+		-- When the remote is versioned, it still contains keys
+		-- that are not present in the new tree.
+		unless (Remote.versionedExport (Remote.exportActions remote)) $ do
+			db <- Export.openDb (Remote.uuid remote)
+			forM_ (exportedTreeishes oldexport) $ \oldtree ->
+				Export.runExportDiffUpdater updater db oldtree finaltree
+			Export.closeDb db
+
+buildImportCommit' :: Remote -> ImportCommitConfig -> Maybe Sha -> History Sha -> Annex (Maybe Sha)
+buildImportCommit' remote importcommitconfig mtrackingcommit imported@(History ti _) =
+	case mtrackingcommit of
+		Nothing -> Just <$> mkcommitsunconnected imported
+		Just trackingcommit -> do
+			-- Get history of tracking branch to at most
+			-- one more level deep than what was imported,
+			-- so we'll have enough history to compare,
+			-- but not spend too much time getting it.
+			let maxdepth = succ importeddepth
+			inRepo (getHistoryToDepth maxdepth trackingcommit)
+				>>= go trackingcommit
+  where
+	go _ Nothing = Just <$> mkcommitsunconnected imported
+	go trackingcommit (Just h)
+		-- If the tracking branch head is a merge commit
+		-- and one side of the merge matches the history,
+		-- nothing new needs to be committed.
+		| t == ti && any sametodepth (S.toList s) = return Nothing
+		-- If the tracking branch matches the history,
+		-- nothing new needs to be committed.
+		-- (This is unlikely to happen.)
+		| sametodepth h' = return Nothing
+		-- If the imported tree is unchanged,
+		-- nothing new needs to be committed.
+		| otherwise = getLastImportedTree remote >>= \case
+			Just (LastImportedTree lasttree)
+				| lasttree == ti -> return Nothing
+			_ -> gencommit trackingcommit h
+	  where
+		h'@(History t s) = mapHistory historyCommitTree h
+	
+	gencommit trackingcommit h = do
+		importedcommit <- case getRemoteTrackingBranchImportHistory h of
+			Nothing -> mkcommitsunconnected imported
+			Just oldimported@(History oldhc _)
+				| importeddepth == 1 ->
+					mkcommitconnected imported oldimported
+				| otherwise -> do
+					let oldimportedtrees = mapHistory historyCommitTree oldimported
+					mknewcommits oldhc oldimportedtrees imported
+		ti' <- addBackExportExcluded remote ti
+		Just <$> makeRemoteTrackingBranchMergeCommit'
+			trackingcommit importedcommit ti'
+
+	importeddepth = historyDepth imported
+
+	sametodepth b = imported == truncateHistoryToDepth importeddepth b
+
+	mkcommit parents tree = inRepo $ Git.Branch.commitTree
+		(importCommitMode importcommitconfig)
+		(importCommitMessages importcommitconfig)
+		parents
+		tree
+
+	-- Start a new history of import commits, not connected to any
+	-- prior import commits.
+	mkcommitsunconnected (History importedtree hs) = do
+		parents <- mapM mkcommitsunconnected (S.toList hs)
+		mkcommit parents importedtree
+
+	-- Commit the new history connected with the old history.
+	-- Used when the import is not versioned, so the history depth is 1.
+	mkcommitconnected (History importedtree _) (History oldhc _) = do
+		let parents = [historyCommit oldhc]
+		mkcommit parents importedtree
+
+	-- Reuse the commits from the old imported History when possible.
+	mknewcommits oldhc old new@(History importedtree hs)
+		| old == new = return $ historyCommit oldhc
+		| otherwise = do
+			parents <- mapM (mknewcommits oldhc old) (S.toList hs)
+			mkcommit parents importedtree
+
+{- Builds a history of git trees for an import.
+ -
+ - When a subdir is provided, the imported tree is grafted into 
+ - the basetree at that location, replacing any object that was there.
+ -}
+buildImportTrees
+	:: Ref
+	-> Maybe TopFilePath
+	-> Imported
+	-> Annex (History Sha)
+buildImportTrees basetree msubdir (ImportedFull imported) = 
+	buildImportTreesGeneric convertImportTree basetree msubdir imported
+buildImportTrees basetree msubdir (ImportedDiff (LastImportedTree oldtree) imported) = do
+	importtree <- if null (importableContents imported)
+		then pure oldtree
+		else applydiff
+	repo <- Annex.gitRepo
+	t <- withMkTreeHandle repo $
+		graftImportTree basetree msubdir importtree
+	-- Diffing is not currently implemented when the history is not empty.
+	return (History t mempty)
+  where
+	applydiff = do
+		let (removed, new) = partition isremoved
+			(importableContents imported)
+		newtreeitems <- catMaybes <$> mapM mktreeitem new
+		let removedfiles = map (mkloc . fst) removed
+		inRepo $ adjustTree
+			(pure . Just) 
+			-- ^ keep files that are not added/removed the same
+			newtreeitems
+			(\_oldti newti -> newti)
+			-- ^ prefer newly added version of file
+			removedfiles
+			oldtree
+	
+	mktreeitem (loc, DiffChanged v) = 
+		Just <$> mkImportTreeItem msubdir loc v
+	mktreeitem (_, DiffRemoved) = 
+		pure Nothing
+
+	mkloc = asTopFilePath . fromImportLocation
+		
+	isremoved (_, v) = v == DiffRemoved
+
+convertImportTree :: Maybe TopFilePath -> [(ImportLocation, Either Sha Key)] -> Annex Tree
+convertImportTree msubdir ls = 
+	treeItemsToTree <$> mapM (uncurry $ mkImportTreeItem msubdir) ls
+
+mkImportTreeItem :: Maybe TopFilePath -> ImportLocation -> Either Sha Key -> Annex TreeItem
+mkImportTreeItem msubdir loc v = case v of
+	Right k -> do
+		relf <- fromRepo $ fromTopFilePath topf
+		symlink <- calcRepo $ gitAnnexLink relf k
+		linksha <- hashSymlink symlink
+		return $ TreeItem treepath (fromTreeItemType TreeSymlink) linksha
+	Left sha -> 
+		return $ TreeItem treepath (fromTreeItemType TreeFile) sha
+  where
+	lf = fromImportLocation loc
+	treepath = asTopFilePath lf
+	topf = asTopFilePath $
+		maybe lf (\sd -> getTopFilePath sd P.</> lf) msubdir
+
+{- Builds a history of git trees using ContentIdentifiers.
+ -
+ - These are not the final trees that are generated by the import, which
+ - use Keys. The purpose of these trees is to allow quickly determining
+ - which files in the import have changed, and which are unchanged, to
+ - avoid needing to look up the Keys for unchanged ContentIdentifiers.
+ - When the import has a large number of files, that can be slow.
+ -}
+buildContentIdentifierTree
+	:: ImportableContentsChunkable Annex (ContentIdentifier, ByteSize)
+	-> Annex (History Sha, M.Map Sha (ContentIdentifier, ByteSize))
+buildContentIdentifierTree importable = do
+	mv <- liftIO $ newTVarIO M.empty
+	r <- buildImportTreesGeneric (convertContentIdentifierTree mv) emptyTree Nothing importable
+	m <- liftIO $ atomically $ readTVar mv
+	return (r, m)
+
+{- For speed, and to avoid bloating the repository, the ContentIdentifiers
+ - are not actually checked into git, instead a sha1 hash is calculated
+ - internally.
+ -}
+convertContentIdentifierTree
+	:: TVar (M.Map Sha (ContentIdentifier, ByteSize))
+	-> Maybe TopFilePath
+	-> [(ImportLocation, (ContentIdentifier, ByteSize))]
+	-> Annex Tree
+convertContentIdentifierTree mv _ ls = do
+	let (tis, ml) = unzip (map mktreeitem ls)
+	liftIO $ atomically $ modifyTVar' mv $
+		M.union (M.fromList ml)
+	return (treeItemsToTree tis)
+  where
+	mktreeitem (loc, v@((ContentIdentifier cid), _sz)) =
+		(TreeItem p mode sha1, (sha1, v))
+	  where
+		p = asTopFilePath (fromImportLocation loc)
+		mode = fromTreeItemType TreeFile
+		-- Note that this hardcodes sha1, even if git has started
+		-- defaulting to some other checksum method. That should be
+		-- ok, hopefully. This checksum never needs to be verified
+		-- by git, which is why this does not bother to prefix the
+		-- cid with its length, like git would.
+		sha1 = Ref $ BA.convertToBase BA.Base16 $ sha1s cid
+
+buildImportTreesGeneric
+	:: (Maybe TopFilePath -> [(ImportLocation, v)] -> Annex Tree)
+	-> Ref
+	-> Maybe TopFilePath
+	-> ImportableContentsChunkable Annex v
+	-> Annex (History Sha)
+buildImportTreesGeneric converttree basetree msubdir (ImportableContentsComplete importable) = do
+	repo <- Annex.gitRepo
+	withMkTreeHandle repo $ buildImportTreesGeneric' converttree basetree msubdir importable
+buildImportTreesGeneric converttree basetree msubdir importable@(ImportableContentsChunked {}) = do
+	repo <- Annex.gitRepo
+	withMkTreeHandle repo $ \hdl ->
+		History
+			<$> go hdl
+			<*> buildImportTreesHistory converttree basetree msubdir
+				(importableHistoryComplete importable) hdl
+  where
+	go hdl = do
+		tree <- gochunks [] (importableContentsChunk importable) hdl
+		importtree <- liftIO $ recordTree' hdl tree
+		graftImportTree basetree msubdir importtree hdl
+
+	gochunks l c hdl = do
+		let subdir = importChunkSubDir $ importableContentsSubDir c
+		-- Full directory prefix where the sub tree is located.
+		let fullprefix = asTopFilePath $ case msubdir of
+			Nothing -> subdir
+			Just d -> getTopFilePath d Posix.</> subdir
+		Tree ts <- converttree (Just fullprefix) $
+			map (\(p, i) -> (mkImportLocation p, i))
+				(importableContentsSubTree c)
+		-- Record this subtree before getting next chunk, this
+		-- avoids buffering all the chunks into memory.
+		tc <- liftIO $ recordSubTree hdl $
+			NewSubTree (asTopFilePath subdir) ts
+		importableContentsNextChunk c >>= \case
+			Nothing -> return (Tree (tc:l))
+			Just c' -> gochunks (tc:l) c' hdl
+
+buildImportTreesGeneric'
+	:: (Maybe TopFilePath -> [(ImportLocation, v)] -> Annex Tree)
+	-> Ref
+	-> Maybe TopFilePath
+	-> ImportableContents v
+	-> MkTreeHandle
+	-> Annex (History Sha)
+buildImportTreesGeneric' converttree basetree msubdir importable hdl = History
+	<$> buildImportTree converttree basetree msubdir (importableContents importable) hdl
+	<*> buildImportTreesHistory converttree basetree msubdir (importableHistory importable) hdl
+
+buildImportTree
+	:: (Maybe TopFilePath -> [(ImportLocation, v)] -> Annex Tree)
+	-> Ref
+	-> Maybe TopFilePath
+	-> [(ImportLocation, v)]
+	-> MkTreeHandle
+	-> Annex Sha
+buildImportTree converttree basetree msubdir ls hdl = do
+	importtree <- liftIO . recordTree' hdl =<< converttree msubdir ls
+	graftImportTree basetree msubdir importtree hdl
+
+graftImportTree
+	:: Ref
+	-> Maybe TopFilePath
+	-> Sha
+	-> MkTreeHandle
+	-> Annex Sha
+graftImportTree basetree msubdir tree hdl = case msubdir of
+	Nothing -> return tree
+	Just subdir -> inRepo $ \repo ->
+		graftTree' tree subdir basetree repo hdl
+
+buildImportTreesHistory
+	:: (Maybe TopFilePath -> [(ImportLocation, v)] -> Annex Tree)
+	-> Ref
+	-> Maybe TopFilePath
+	-> [ImportableContents v]
+	-> MkTreeHandle
+	-> Annex (S.Set (History Sha))
+buildImportTreesHistory converttree basetree msubdir history hdl = S.fromList
+	<$> mapM (\ic -> buildImportTreesGeneric' converttree basetree msubdir ic hdl) history
+
+canImportKeys :: Remote -> Bool -> Bool
+canImportKeys remote importcontent =
+	importcontent || isJust (Remote.importKey ia)
+  where
+	ia = Remote.importActions remote
+
+-- Result of an import. ImportUnfinished indicates that some file failed to
+-- be imported. Running again should resume where it left off.
+data ImportResult t
+	= ImportFinished t
+	| ImportUnfinished
+
+data Diffed t
+	= DiffChanged t
+	| DiffRemoved
+	deriving (Eq)
+
+data Imported
+	= ImportedFull (ImportableContentsChunkable Annex (Either Sha Key))
+	| ImportedDiff LastImportedTree (ImportableContents (Diffed (Either Sha Key)))
+
+newtype LastImportedTree = LastImportedTree Sha
+
+{- Diffs between the previous and current ContentIdentifier trees, and 
+ - runs importKeys on only the changed files.
+ -
+ - This will download the same content as if importKeys were run on all
+ - files, but this speeds it up significantly when there are a lot of files
+ - and only a few have changed. importKeys has to look up each
+ - ContentIdentifier to see if a Key is known for it. This avoids doing
+ - that lookup on files that have not changed.
+ -
+ - Diffing is not currently implemented when there is a History.
+ -}
+importChanges
+	:: Remote
+	-> ImportTreeConfig
+	-> Bool
+	-> Bool
+	-> ImportableContentsChunkable Annex (ContentIdentifier, ByteSize)
+	-> Annex (ImportResult Imported)
+importChanges remote importtreeconfig importcontent thirdpartypopulated importablecontents = do
+	((History currcidtree currhistory), cidtreemap) <- buildContentIdentifierTree importablecontents
+	-- diffimport below does not handle history, so when there is
+	-- history, do a full import.
+	if not (S.null currhistory)
+		then fullimport currcidtree
+		else do
+			getContentIdentifierTree (Remote.uuid remote) >>= \case
+				Nothing -> fullimport currcidtree
+				Just prevcidtree -> candiffimport prevcidtree >>= \case
+					Nothing -> fullimport currcidtree
+					Just lastimportedtree -> diffimport cidtreemap prevcidtree currcidtree lastimportedtree
+  where
+	remember = recordContentIdentifierTree (Remote.uuid remote)
+
+	-- In order to use a diff, the previous ContentIdentifier tree must
+	-- not have been garbage collected. Which can happen since there
+	-- are no git refs to it.
+	--
+	-- Also, a tree must have been imported before, and that tree must
+	-- also have not been garbage collected (which is less likely to
+	-- happen due to the remote tracking branch).
+	candiffimport prevcidtree =
+		catObjectMetaData prevcidtree >>= \case
+			Nothing -> return Nothing
+			Just _ -> getLastImportedTree remote >>= \case
+				Nothing -> return Nothing
+				Just lastimported@(LastImportedTree t) -> 
+					ifM (isJust <$> catObjectMetaData t)
+						( return (Just lastimported)
+						, return Nothing
+						)
+
+	fullimport currcidtree = 
+		importKeys remote importtreeconfig importcontent thirdpartypopulated importablecontents >>= \case
+			ImportUnfinished -> return ImportUnfinished
+			ImportFinished r -> do
+				remember currcidtree
+	 			return $ ImportFinished $ ImportedFull r
+		
+	diffimport cidtreemap prevcidtree currcidtree lastimportedtree = do
+		(diff, cleanup) <- inRepo $ Git.DiffTree.diffTreeRecursive
+			prevcidtree
+			currcidtree
+		let (removed, changed) = partition isremoval diff
+		let mkicchanged ti = do
+			v <- M.lookup (Git.DiffTree.dstsha ti) cidtreemap
+			return (mkloc ti, v)
+		let ic = ImportableContentsComplete $ ImportableContents
+			{ importableContents = mapMaybe mkicchanged changed
+			, importableHistory = []
+			}
+		importKeys remote importtreeconfig importcontent thirdpartypopulated ic >>= \case
+			ImportUnfinished -> do
+				void $ liftIO cleanup
+				return ImportUnfinished
+			ImportFinished (ImportableContentsComplete ic') -> 
+				liftIO cleanup >>= \case
+					False -> return ImportUnfinished
+					True -> do
+						remember currcidtree
+						return $ ImportFinished $ 
+							ImportedDiff lastimportedtree
+								(mkdiff ic' removed)
+			-- importKeys is not passed ImportableContentsChunked
+			-- above, so it cannot return it
+			ImportFinished (ImportableContentsChunked {}) -> error "internal"
+		
+	isremoval ti = Git.DiffTree.dstsha ti `elem` nullShas
+	
+	mkloc = mkImportLocation . getTopFilePath . Git.DiffTree.file
+
+	mkdiff ic removed = ImportableContents
+		{ importableContents = diffremoved ++ diffchanged
+		, importableHistory = []
+		}
+	  where
+		diffchanged = map
+			(\(loc, v) -> (loc, DiffChanged v))
+			(importableContents ic)
+		diffremoved = map
+			(\ti -> (mkloc ti, DiffRemoved))
+			removed
+
+{- Gets the tree that was last imported from the remote
+ - (or exported to it if an export happened after the last import).
+ -}
+getLastImportedTree :: Remote -> Annex (Maybe LastImportedTree)
+getLastImportedTree remote = do
+	db <- Export.openDb (Remote.uuid remote)
+	mtree <- liftIO $ Export.getExportTreeCurrent db
+	Export.closeDb db
+	return (LastImportedTree <$> mtree)
+
+{- Downloads all new ContentIdentifiers, or when importcontent is False,
+ - generates Keys without downloading.
+ -
+ - Generates either a Key or a git Sha, depending on annex.largefiles.
+ - But when importcontent is False, it cannot match on annex.largefiles
+ - (or generate a git Sha), so always generates Keys.
+ -
+ - Supports concurrency when enabled.
+ -
+ - Note that, when a ContentIdentifier has been imported before,
+ - generates the same thing that was imported before, so annex.largefiles
+ - is not reapplied.
+ -}
+importKeys
+	:: Remote
+	-> ImportTreeConfig
+	-> Bool
+	-> Bool
+	-> ImportableContentsChunkable Annex (ContentIdentifier, ByteSize)
+	-> Annex (ImportResult (ImportableContentsChunkable Annex (Either Sha Key)))
+importKeys remote importtreeconfig importcontent thirdpartypopulated importablecontents = do
+	unless (canImportKeys remote importcontent) $
+		giveup "This remote does not support importing without downloading content."
+	-- This map is used to remember content identifiers that
+	-- were just imported, before they have necessarily been
+	-- stored in the database. This way, if the same content
+	-- identifier appears multiple times in the
+	-- importablecontents (eg when it has a history), 
+	-- they will only be imported once.
+	cidmap <- liftIO $ newTVarIO M.empty
+	-- When concurrency is enabled, this set is needed to
+	-- avoid two threads both importing the same content identifier.
+	importing <- liftIO $ newTVarIO S.empty
+	withciddb $ \db -> do
+		db' <- CIDDb.needsUpdateFromLog db
+			>>= maybe (pure db) (CIDDb.updateFromLog db)
+		(prepclock (run cidmap importing db'))
+  where
+	-- When not importing content, reuse the same vector
+	-- clock for all state that's recorded. This can save
+	-- a little bit of disk space. Individual file downloads
+	-- while downloading take too long for this optimisation
+	-- to be safe to do.
+	prepclock a
+		| importcontent = a
+		| otherwise = reuseVectorClockWhile a
+
+	withciddb a = do
+		cidlck <- calcRepo' gitAnnexContentIdentifierLock
+		withExclusiveLock cidlck $
+			bracket CIDDb.openDb CIDDb.closeDb a
+
+	run cidmap importing db = do
+		largematcher <- largeFilesMatcher
+		case importablecontents of
+			ImportableContentsComplete ic ->
+				go False largematcher cidmap importing db ic >>= return . \case
+					Nothing -> ImportUnfinished
+					Just v -> ImportFinished $ ImportableContentsComplete v
+			ImportableContentsChunked {} -> do
+				c <- gochunked db (importableContentsChunk importablecontents)
+				gohistory largematcher cidmap importing db (importableHistoryComplete importablecontents) >>= return . \case
+					Nothing -> ImportUnfinished
+					Just h -> ImportFinished $ ImportableContentsChunked
+						{ importableContentsChunk = c
+						, importableHistoryComplete = h
+						}
+
+	go oldversion largematcher cidmap importing db (ImportableContents l h) = do
+		jobs <- forM l $ \i ->
+			if thirdpartypopulated
+				then Left <$> thirdpartypopulatedimport db i
+				else startimport cidmap importing db i oldversion largematcher
+		l' <- liftIO $ forM jobs $
+			either pure (atomically . takeTMVar)
+		if any isNothing l'
+			then return Nothing
+			else gohistory largematcher cidmap importing db h >>= return . \case
+				Nothing -> Nothing
+				Just h' -> Just $ ImportableContents (catMaybes l') h'
+	
+	gohistory largematcher cidmap importing db h = do
+		h' <- mapM (go True largematcher cidmap importing db) h
+		if any isNothing h'
+			then return Nothing
+			else return $ Just $ catMaybes h'
+	
+	gochunked db c
+		-- Downloading cannot be done when chunked, since only
+		-- the first chunk is processed before returning.
+		| importcontent = giveup "importKeys does not support downloading chunked import"
+		-- Chunked import is currently only used by thirdpartypopulated
+		-- remotes.
+		| not thirdpartypopulated = giveup "importKeys does not support chunked import when not thirdpartypopulated"
+		| otherwise = do
+			l <- forM (importableContentsSubTree c) $ \(loc, i) -> do
+				let loc' = importableContentsChunkFullLocation (importableContentsSubDir c) loc
+				thirdpartypopulatedimport db (loc', i) >>= return . \case
+					Just (_loc, k) -> Just (loc, k)
+					Nothing -> Nothing
+			return $ ImportableContentsChunk
+				{ importableContentsSubDir = importableContentsSubDir c
+				, importableContentsSubTree = catMaybes l
+				, importableContentsNextChunk =
+					importableContentsNextChunk c >>= \case
+						Nothing -> return Nothing
+						Just c' -> withciddb $ \db' -> 
+							prepclock $
+								Just <$> gochunked db' c'
+				}
+
+	waitstart importing cid = liftIO $ atomically $ do
+		s <- readTVar importing
+		if S.member cid s
+			then retry
+			else writeTVar importing $ S.insert cid s
+	
+	signaldone importing cid = liftIO $ atomically $ do
+		s <- readTVar importing
+		writeTVar importing $ S.delete cid s
+	
+	startimport cidmap importing db i@(loc, (cid, _sz)) oldversion largematcher = getcidkey cidmap db cid >>= \case
+		(k:ks) ->
+			-- If the same content was imported before
+			-- yielding multiple different keys, it's not clear
+			-- which is best to use this time, so pick the
+			-- first in the list. But, if any of them is a
+			-- git sha, use it, because the content must
+			-- be included in the git repo then.
+			let v = case mapMaybe keyGitSha (k:ks) of
+				(sha:_) -> Left sha
+				[] -> Right k
+			in return $ Left $ Just (loc, v)
+		[] -> do
+			job <- liftIO $ newEmptyTMVarIO
+			let ai = ActionItemOther (Just (QuotedPath (fromImportLocation loc)))
+			let si = SeekInput []
+			let importaction = starting ("import " ++ Remote.name remote) ai si $ do
+				when oldversion $
+					showNote "old version"
+				tryNonAsync (importordownload cidmap i largematcher) >>= \case
+					Left e -> next $ do
+						warning (UnquotedString (show e))
+						liftIO $ atomically $
+							putTMVar job Nothing
+						return False
+					Right r -> next $ do
+						liftIO $ atomically $
+							putTMVar job r
+						return True
+			commandAction $ bracket_
+				(waitstart importing cid)
+				(signaldone importing cid)
+				importaction
+			return (Right job)
+	
+	thirdpartypopulatedimport db (loc, (cid, sz)) = 
+		case Remote.importKey ia of
+			Nothing -> return Nothing
+			Just importkey ->
+				tryNonAsync (importkey loc cid sz nullMeterUpdate) >>= \case
+					Right (Just k) -> do
+						recordcidkeyindb db cid k
+						logChange k (Remote.uuid remote) InfoPresent
+						return $ Just (loc, Right k)
+					Right Nothing -> return Nothing
+					Left e -> do
+						warning (UnquotedString (show e))
+						return Nothing
+	
+	importordownload cidmap (loc, (cid, sz)) largematcher = do
+		f <- locworktreefile loc
+		matcher <- largematcher f
+		-- When importing a key is supported, always use it rather
+		-- than downloading and retrieving a key, to avoid
+		-- generating trees with different keys for the same content.
+		let act = if importcontent
+			then case Remote.importKey ia of
+				Nothing -> dodownload
+				Just _ -> if Utility.Matcher.introspect matchNeedsFileContent (fst matcher)
+					then dodownload
+					else doimport
+			else doimport
+		act cidmap (loc, (cid, sz)) f matcher
+
+	doimport cidmap (loc, (cid, sz)) f matcher =
+		case Remote.importKey ia of
+			Nothing -> error "internal" -- checked earlier
+			Just importkey -> do
+				when (Utility.Matcher.introspect matchNeedsFileContent (fst matcher)) $
+					giveup "annex.largefiles configuration examines file contents, so cannot import without content."
+ 				let mi = MatchingInfo ProvidedInfo
+					{ providedFilePath = Just f
+					, providedKey = Nothing
+					, providedFileSize = Just sz
+					, providedMimeType = Nothing
+					, providedMimeEncoding = Nothing
+					, providedLinkType = Nothing
+					}
+				islargefile <- checkMatcher' matcher mi mempty
+				metered Nothing sz bwlimit $ const $ if islargefile
+					then doimportlarge importkey cidmap loc cid sz f
+					else doimportsmall cidmap loc cid sz
+	
+	doimportlarge importkey cidmap loc cid sz f p =
+		tryNonAsync importer >>= \case
+			Right (Just (k, True)) -> return $ Just (loc, Right k)
+			Right _ -> return Nothing
+			Left e -> do
+				warning (UnquotedString (show e))
+				return Nothing
+	  where
+		importer = do
+			-- Don't display progress when generating
+			-- key, if the content will later be
+			-- downloaded, which is a more expensive
+			-- operation generally.
+			let p' = if importcontent then nullMeterUpdate else p
+			importkey loc cid sz p' >>= \case
+				Nothing -> return Nothing
+				Just k -> checkSecureHashes k >>= \case
+					Nothing -> do
+						recordcidkey cidmap cid k
+						logChange k (Remote.uuid remote) InfoPresent
+						if importcontent
+							then getcontent k
+							else return (Just (k, True))
+					Just msg -> giveup (msg ++ " to import")
+
+		getcontent :: Key -> Annex (Maybe (Key, Bool))
+		getcontent k = do
+			let af = AssociatedFile (Just f)
+			let downloader p' tmpfile = do
+				_ <- Remote.retrieveExportWithContentIdentifier
+					ia loc [cid] (fromRawFilePath tmpfile)
+					(Left k)
+					(combineMeterUpdate p' p)
+				ok <- moveAnnex k af tmpfile
+				when ok $
+					logStatus k InfoPresent
+				return (Just (k, ok))
+			checkDiskSpaceToGet k Nothing Nothing $
+				notifyTransfer Download af $
+					download' (Remote.uuid remote) k af Nothing stdRetry $ \p' ->
+						withTmp k $ downloader p'
+			
+	-- The file is small, so is added to git, so while importing
+	-- without content does not retrieve annexed files, it does
+	-- need to retrieve this file.
+	doimportsmall cidmap loc cid sz p = do
+		let downloader tmpfile = do
+			(k, _) <- Remote.retrieveExportWithContentIdentifier
+				ia loc [cid] (fromRawFilePath tmpfile)
+				(Right (mkkey tmpfile))
+				p
+			case keyGitSha k of
+				Just sha -> do
+					recordcidkey cidmap cid k
+					return sha
+				Nothing -> error "internal"
+		checkDiskSpaceToGet tmpkey Nothing Nothing $
+			withTmp tmpkey $ \tmpfile ->
+				tryNonAsync (downloader tmpfile) >>= \case
+					Right sha -> return $ Just (loc, Left sha)
+					Left e -> do
+						warning (UnquotedString (show e))
+						return Nothing
+	  where
+		tmpkey = importKey cid sz
+		mkkey tmpfile = gitShaKey <$> hashFile tmpfile
+	
+	dodownload cidmap (loc, (cid, sz)) f matcher = do
+		let af = AssociatedFile (Just f)
+		let downloader tmpfile p = do
+			(k, _) <- Remote.retrieveExportWithContentIdentifier
+				ia loc [cid] (fromRawFilePath tmpfile)
+				(Right (mkkey tmpfile))
+				p
+			case keyGitSha k of
+				Nothing -> do
+					ok <- moveAnnex k af tmpfile
+					when ok $ do
+						recordcidkey cidmap cid k
+						logStatus k InfoPresent
+						logChange k (Remote.uuid remote) InfoPresent
+					return (Right k, ok)
+				Just sha -> do
+					recordcidkey cidmap cid k
+					return (Left sha, True)
+		let rundownload tmpfile p = tryNonAsync (downloader tmpfile p) >>= \case
+			Right (v, True) -> return $ Just (loc, v)
+			Right (_, False) -> return Nothing
+			Left e -> do
+				warning (UnquotedString (show e))
+				return Nothing
+		checkDiskSpaceToGet tmpkey Nothing Nothing $
+			notifyTransfer Download af $
+				download' (Remote.uuid remote) tmpkey af Nothing stdRetry $ \p ->
+					withTmp tmpkey $ \tmpfile ->
+						metered (Just p) tmpkey bwlimit $
+							const (rundownload tmpfile)
+	  where
+		tmpkey = importKey cid sz
+	
+		mkkey tmpfile = do
+			let mi = MatchingFile FileInfo
+				{ matchFile = f
+				, contentFile = tmpfile
+				, matchKey = Nothing
+				}
+			islargefile <- checkMatcher' matcher mi mempty
+			if islargefile
+				then do
+					backend <- chooseBackend f
+					let ks = KeySource
+						{ keyFilename = f
+						, contentLocation = tmpfile
+						, inodeCache = Nothing
+						}
+					fst <$> genKey ks nullMeterUpdate backend
+				else gitShaKey <$> hashFile tmpfile
+	
+	ia = Remote.importActions remote
+				
+	bwlimit = remoteAnnexBwLimitDownload (Remote.gitconfig remote)
+			<|> remoteAnnexBwLimit (Remote.gitconfig remote)
+
+	locworktreefile loc = fromRepo $ fromTopFilePath $ asTopFilePath $
+		case importtreeconfig of
+			ImportTree -> fromImportLocation loc
+			ImportSubTree subdir _ ->
+				getTopFilePath subdir P.</> fromImportLocation loc
+
+	getcidkey cidmap db cid = liftIO $
+		-- Avoiding querying the database when it's empty speeds up
+		-- the initial import.
+		if CIDDb.databaseIsEmpty db
+			then getcidkeymap cidmap cid
+			else CIDDb.getContentIdentifierKeys db rs cid >>= \case
+				[] -> getcidkeymap cidmap cid
+				l -> return l
+
+	getcidkeymap cidmap cid =
+		atomically $ maybeToList . M.lookup cid <$> readTVar cidmap
+
+	recordcidkey cidmap cid k = do
+		liftIO $ atomically $ modifyTVar' cidmap $
+			M.insert cid k
+		-- Only record in log now; the database will be updated
+		-- later from the log, and the cidmap will be used for now.
+		recordcidkeyinlog cid k
+	
+	recordcidkeyindb db cid k = do
+		liftIO $ CIDDb.recordContentIdentifier db rs cid k
+		recordcidkeyinlog cid k
+	
+	recordcidkeyinlog cid k =
+		CIDLog.recordContentIdentifier rs cid k
+
+	rs = Remote.remoteStateHandle remote
+
+{- Temporary key used for import of a ContentIdentifier while downloading
+ - content, before generating its real key. -}
+importKey :: ContentIdentifier -> Integer -> Key
+importKey (ContentIdentifier cid) size = mkKey $ \k -> k
+	{ keyName = genKeyName (decodeBS cid)
+	, keyVariety = OtherKey "CID"
+	, keySize = Just size
+	}
+
+{-- Export omits non-preferred content from the tree stored on the
+ -- remote. So the import will normally have that content
+ -- omitted (unless something else added files with the same names to the
+ -- special remote).
+ --
+ -- That presents a problem: Merging the imported tree would result
+ -- in deletion of the files that were excluded from export.
+ -- To avoid that happening, this adds them back to the imported tree.
+ --}
+addBackExportExcluded :: Remote -> Sha -> Annex Sha
+addBackExportExcluded remote importtree =
+	getExportExcluded (Remote.uuid remote) >>= \case
+		[] -> return importtree
+		excludedlist -> inRepo $
+			adjustTree
+				-- don't remove any
+				(pure . Just)
+				excludedlist
+				-- if something was imported with the same
+				-- name as a file that was previously
+				-- excluded from import, use what was imported
+				(\imported _excluded -> imported)
+				[]
+				importtree
+
+{- Match the preferred content of the remote at import time.
+ -
+ - Only keyless tokens are supported, because the keys are not known
+ - until an imported file is downloaded, which is too late to bother
+ - excluding it from an import. So prunes any tokens in the preferred
+ - content expression that need keys.
+ -}
+makeImportMatcher :: Remote -> Annex (Either String (FileMatcher Annex))
+makeImportMatcher r = load preferredContentTokens >>= \case
+	Nothing -> return $ Right (matchAll, matcherdesc)
+	Just (Right v) -> return $ Right (v, matcherdesc)
+	Just (Left err) -> return $ Left err
+  where
+	load t = M.lookup (Remote.uuid r) . fst
+		<$> preferredRequiredMapsLoad' pruneImportMatcher t
+	matcherdesc = MatcherDesc "preferred content"
+
+pruneImportMatcher :: Utility.Matcher.Matcher (MatchFiles a) -> Utility.Matcher.Matcher (MatchFiles a)
+pruneImportMatcher = Utility.Matcher.pruneMatcher matchNeedsKey
+
+{- Gets the ImportableContents from the remote.
+ -
+ - Filters out any paths that include a ".git" component, because git does
+ - not allow storing ".git" in a git repository. While it is possible to
+ - write a git tree that contains that, git will complain and refuse to
+ - check it out.
+ -
+ - Filters out new things not matching the FileMatcher or that are
+ - gitignored. However, files that are already in git get imported
+ - regardless. (Similar to how git add behaves on gitignored files.)
+ - This avoids creating a remote tracking branch that, when merged,
+ - would delete the files.
+ -
+ - Throws exception if unable to contact the remote.
+ - Returns Nothing when there is no change since last time.
+ -}
+getImportableContents :: Remote -> ImportTreeConfig -> CheckGitIgnore -> FileMatcher Annex -> Annex (Maybe (ImportableContentsChunkable Annex (ContentIdentifier, ByteSize)))
+getImportableContents r importtreeconfig ci matcher = do
+	Remote.listImportableContents (Remote.importActions r) >>= \case
+		Just (ImportableContentsComplete ic) -> do
+			dbhandle <- opendbhandle
+			Just . ImportableContentsComplete
+				<$> filterunwanted dbhandle ic
+		Just (c@(ImportableContentsChunked {})) -> do
+			dbhandle <- opendbhandle
+			Just <$> filterunwantedchunked dbhandle c
+		Nothing -> return Nothing
+  where
+	filterunwanted dbhandle ic = ImportableContents
+		<$> filterM (wanted dbhandle) (importableContents ic)
+		<*> mapM (filterunwanted dbhandle) (importableHistory ic)
+	
+	filterunwantedchunked dbhandle c = ImportableContentsChunked
+		<$> filterunwantedchunk dbhandle (importableContentsChunk c)
+		<*> mapM (filterunwanted dbhandle) (importableHistoryComplete c)
+
+	filterunwantedchunk dbhandle c = ImportableContentsChunk
+		<$> pure (importableContentsSubDir c)
+		<*> filterM (wantedunder dbhandle (importableContentsSubDir c))
+			(importableContentsSubTree c)
+		<*> pure (
+			importableContentsNextChunk c >>= \case
+				Nothing -> return Nothing
+				Just c' -> Just <$> filterunwantedchunk dbhandle c'
+			)
+
+	opendbhandle = do
+		h <- Export.openDb (Remote.uuid r)
+		void $ Export.updateExportTreeFromLog h
+		return h
+
+	wanted dbhandle (loc, (_cid, sz))
+		| ingitdir = pure False
+		| otherwise =
+			isknown <||> (matches <&&> notignored)
+	  where
+		-- Checks, from least to most expensive.
+		ingitdir = ".git" `elem` Posix.splitDirectories (fromImportLocation loc)
+		matches = matchesImportLocation matcher loc sz
+		isknown = isKnownImportLocation dbhandle loc
+		notignored = notIgnoredImportLocation importtreeconfig ci loc
+	
+	wantedunder dbhandle root (loc, v) = 
+		wanted dbhandle (importableContentsChunkFullLocation root loc, v)
+
+isKnownImportLocation :: Export.ExportHandle -> ImportLocation -> Annex Bool
+isKnownImportLocation dbhandle loc = liftIO $
+	not . null <$> Export.getExportTreeKey dbhandle loc
+
+matchesImportLocation :: FileMatcher Annex -> ImportLocation -> Integer -> Annex Bool
+matchesImportLocation matcher loc sz = checkMatcher' matcher mi mempty
+  where
+	mi = MatchingInfo $ ProvidedInfo
+		{ providedFilePath = Just (fromImportLocation loc)
+		, providedKey = Nothing
+		, providedFileSize = Just sz
+		, providedMimeType = Nothing
+		, providedMimeEncoding = Nothing
+		, providedLinkType = Nothing
+		}
+
+notIgnoredImportLocation :: ImportTreeConfig -> CheckGitIgnore -> ImportLocation -> Annex Bool
+notIgnoredImportLocation importtreeconfig ci loc = not <$> checkIgnored ci f
+  where
+	f = case importtreeconfig of
+		ImportSubTree dir _ ->
+			getTopFilePath dir P.</> fromImportLocation loc
+		ImportTree ->
+			fromImportLocation loc
diff --git a/Annex/Ingest.hs b/Annex/Ingest.hs
new file mode 100644
index 0000000000..1ef4d346b9
--- /dev/null
+++ b/Annex/Ingest.hs
@@ -0,0 +1,425 @@
+{- git-annex content ingestion
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Ingest (
+	LockedDown(..),
+	LockDownConfig(..),
+	lockDown,
+	checkLockedDownWritePerms,
+	ingestAdd,
+	ingestAdd',
+	ingest,
+	ingest',
+	finishIngestUnlocked,
+	cleanOldKeys,
+	addSymlink,
+	genSymlink,
+	makeLink,
+	addUnlocked,
+	CheckGitIgnore(..),
+	gitAddParams,
+	addAnnexedFile,
+	addingExistingLink,
+) where
+
+import Annex.Common
+import Types.KeySource
+import Types.FileMatcher
+import Backend
+import Annex.Content
+import Annex.Perms
+import Annex.Link
+import Annex.MetaData
+import Annex.CurrentBranch
+import Annex.CheckIgnore
+import Logs.Location
+import qualified Git
+import qualified Annex
+import qualified Database.Keys
+import Config
+import Utility.InodeCache
+import Annex.ReplaceFile
+import Utility.Tmp
+import Utility.CopyFile
+import Utility.Touch
+import Utility.Metered
+import Git.FilePath
+import Annex.InodeSentinal
+import Annex.AdjustedBranch
+import Annex.FileMatcher
+import qualified Utility.RawFilePath as R
+
+import System.PosixCompat.Files (fileMode)
+
+data LockedDown = LockedDown
+	{ lockDownConfig :: LockDownConfig
+	, keySource :: KeySource
+	}
+	deriving (Show)
+
+data LockDownConfig = LockDownConfig
+	{ lockingFile :: Bool
+	-- ^ write bit removed during lock down
+	, hardlinkFileTmpDir :: Maybe RawFilePath
+	-- ^ hard link to temp directory
+	, checkWritePerms :: Bool
+	-- ^ check that write perms are successfully removed
+	}
+	deriving (Show)
+
+{- The file that's being ingested is locked down before a key is generated,
+ - to prevent it from being modified in between. This lock down is not
+ - perfect at best (and pretty weak at worst). For example, it does not
+ - guard against files that are already opened for write by another process.
+ - So, the InodeCache can be used to detect any changes that might be made
+ - to the file after it was locked down.
+ -
+ - When possible, the file is hard linked to a temp directory. This guards
+ - against some changes, like deletion or overwrite of the file, and
+ - allows lsof checks to be done more efficiently when adding a lot of files.
+ -
+ - Lockdown can fail if a file gets deleted, or if it's unable to remove
+ - write permissions, and Nothing will be returned.
+ -}
+lockDown :: LockDownConfig-> FilePath -> Annex (Maybe LockedDown)
+lockDown cfg file = either 
+		(\e -> warning (UnquotedString (show e)) >> return Nothing)
+		(return . Just)
+	=<< lockDown' cfg file
+
+lockDown' :: LockDownConfig -> FilePath -> Annex (Either SomeException LockedDown)
+lockDown' cfg file = tryNonAsync $ ifM crippledFileSystem
+	( nohardlink
+	, case hardlinkFileTmpDir cfg of
+		Nothing -> nohardlink
+		Just tmpdir -> withhardlink tmpdir
+	)
+  where
+	file' = toRawFilePath file
+
+	nohardlink = do
+		setperms
+		withTSDelta $ liftIO . nohardlink'
+
+	nohardlink' delta = do
+		cache <- genInodeCache file' delta
+		return $ LockedDown cfg $ KeySource
+			{ keyFilename = file'
+			, contentLocation = file'
+			, inodeCache = cache
+			}
+	
+	withhardlink tmpdir = do
+		setperms
+		withTSDelta $ \delta -> liftIO $ do
+			(tmpfile, h) <- openTmpFileIn (fromRawFilePath tmpdir) $
+				relatedTemplate $ "ingest-" ++ takeFileName file
+			hClose h
+			removeWhenExistsWith R.removeLink (toRawFilePath tmpfile)
+			withhardlink' delta tmpfile
+				`catchIO` const (nohardlink' delta)
+
+	withhardlink' delta tmpfile = do
+		let tmpfile' = toRawFilePath tmpfile
+		R.createLink file' tmpfile'
+		cache <- genInodeCache tmpfile' delta
+		return $ LockedDown cfg $ KeySource
+			{ keyFilename = file'
+			, contentLocation = tmpfile'
+			, inodeCache = cache
+			}
+		
+	setperms = when (lockingFile cfg) $ do
+		freezeContent file'
+		when (checkWritePerms cfg) $ do
+			qp <- coreQuotePath <$> Annex.getGitConfig
+			maybe noop (giveup . decodeBS . quote qp)
+				=<< checkLockedDownWritePerms file' file'
+
+checkLockedDownWritePerms :: RawFilePath -> RawFilePath -> Annex (Maybe StringContainingQuotedPath)
+checkLockedDownWritePerms file displayfile = checkContentWritePerm file >>= return . \case
+	Just False -> Just $ "Unable to remove all write permissions from "
+		<> QuotedPath displayfile
+		<> " -- perhaps it has an xattr or ACL set."
+	_ -> Nothing
+
+{- Ingests a locked down file into the annex. Updates the work tree and
+ - index. -}
+ingestAdd :: MeterUpdate -> Maybe LockedDown -> Annex (Maybe Key)
+ingestAdd meterupdate ld = ingestAdd' meterupdate ld Nothing
+
+ingestAdd' :: MeterUpdate -> Maybe LockedDown -> Maybe Key -> Annex (Maybe Key)
+ingestAdd' _ Nothing _ = return Nothing
+ingestAdd' meterupdate ld@(Just (LockedDown cfg source)) mk = do
+	(mk', mic) <- ingest meterupdate ld mk
+	case mk' of
+		Nothing -> return Nothing
+		Just k -> do
+			let f = keyFilename source
+			if lockingFile cfg
+				then addSymlink f k mic
+				else do
+					mode <- liftIO $ catchMaybeIO $
+						fileMode <$> R.getFileStatus (contentLocation source)
+					stagePointerFile f mode =<< hashPointerFile k
+			return (Just k)
+
+{- Ingests a locked down file into the annex. Does not update the working
+ - tree or the index. -}
+ingest :: MeterUpdate -> Maybe LockedDown -> Maybe Key -> Annex (Maybe Key, Maybe InodeCache)
+ingest meterupdate ld mk = ingest' Nothing meterupdate ld mk (Restage True)
+
+ingest' :: Maybe Backend -> MeterUpdate -> Maybe LockedDown -> Maybe Key -> Restage -> Annex (Maybe Key, Maybe InodeCache)
+ingest' _ _ Nothing _ _ = return (Nothing, Nothing)
+ingest' preferredbackend meterupdate (Just (LockedDown cfg source)) mk restage = withTSDelta $ \delta -> do
+	k <- case mk of
+		Nothing -> do
+			backend <- maybe
+				(chooseBackend $ keyFilename source)
+				return
+				preferredbackend
+			fst <$> genKey source meterupdate backend
+		Just k -> return k
+	let src = contentLocation source
+	ms <- liftIO $ catchMaybeIO $ R.getFileStatus src
+	mcache <- maybe (pure Nothing) (liftIO . toInodeCache delta src) ms
+	case (mcache, inodeCache source) of
+		(_, Nothing) -> go k mcache
+		(Just newc, Just c) | compareStrong c newc -> go k mcache
+		_ -> failure "changed while it was being added"
+  where
+	go key mcache
+		| lockingFile cfg = golocked key mcache
+		| otherwise = gounlocked key mcache
+
+	golocked key mcache =
+		tryNonAsync (moveAnnex key naf (contentLocation source)) >>= \case
+			Right True -> success key mcache
+			Right False -> giveup "failed to add content to annex"
+			Left e -> restoreFile (keyFilename source) key e
+
+	-- moveAnnex uses the AssociatedFile provided to it to unlock
+	-- locked files when getting a file in an adjusted branch.
+	-- That case does not apply here, where we're adding an unlocked
+	-- file, so provide it nothing.
+	naf = AssociatedFile Nothing
+
+	gounlocked key (Just cache) = do
+		-- Remove temp directory hard link first because
+		-- linkToAnnex falls back to copying if a file
+		-- already has a hard link.
+		cleanCruft source
+		cleanOldKeys (keyFilename source) key
+		linkToAnnex key (keyFilename source) (Just cache) >>= \case
+			LinkAnnexFailed -> failure "failed to link to annex"
+			lar -> do
+				finishIngestUnlocked' key source restage (Just lar)
+				success key (Just cache)
+	gounlocked _ _ = failure "failed statting file"
+
+	success k mcache = do
+		genMetaData k (keyFilename source) (fmap inodeCacheToMtime mcache)
+		return (Just k, mcache)
+
+	failure msg = do
+		warning $ QuotedPath (keyFilename source) <> " " <> UnquotedString msg
+		cleanCruft source
+		return (Nothing, Nothing)
+
+finishIngestUnlocked :: Key -> KeySource -> Annex ()
+finishIngestUnlocked key source = do
+	cleanCruft source
+	finishIngestUnlocked' key source (Restage True) Nothing
+
+finishIngestUnlocked' :: Key -> KeySource -> Restage -> Maybe LinkAnnexResult -> Annex ()
+finishIngestUnlocked' key source restage lar = do
+	Database.Keys.addAssociatedFile key
+		=<< inRepo (toTopFilePath (keyFilename source))
+	populateUnlockedFiles key source restage lar
+
+{- Copy to any other unlocked files using the same key.
+ -
+ - When linkToAnnex did not have to do anything, the object file
+ - was already present, and so other unlocked files are already populated,
+ - and nothing needs to be done here.
+ -}
+populateUnlockedFiles :: Key -> KeySource -> Restage -> Maybe LinkAnnexResult -> Annex ()
+populateUnlockedFiles _ _ _ (Just LinkAnnexNoop) = return ()
+populateUnlockedFiles key source restage _ = do
+	obj <- calcRepo (gitAnnexLocation key)
+	g <- Annex.gitRepo
+	ingestedf <- flip fromTopFilePath g
+		<$> inRepo (toTopFilePath (keyFilename source))
+	afs <- map (`fromTopFilePath` g) <$> Database.Keys.getAssociatedFiles key
+	forM_ (filter (/= ingestedf) afs) $
+		populatePointerFile restage key obj
+
+cleanCruft :: KeySource -> Annex ()
+cleanCruft source = when (contentLocation source /= keyFilename source) $
+	liftIO $ removeWhenExistsWith R.removeLink $ contentLocation source
+
+-- If a worktree file was was hard linked to an annex object before,
+-- modifying the file would have caused the object to have the wrong
+-- content. Clean up from that.
+cleanOldKeys :: RawFilePath -> Key -> Annex ()
+cleanOldKeys file newkey = do
+	g <- Annex.gitRepo
+	topf <- inRepo (toTopFilePath file)
+	ingestedf <- fromRepo $ fromTopFilePath topf
+	oldkeys <- filter (/= newkey)
+		<$> Database.Keys.getAssociatedKey topf
+	forM_ oldkeys $ \key ->
+		unlessM (isUnmodified key =<< calcRepo (gitAnnexLocation key)) $ do
+			caches <- Database.Keys.getInodeCaches key
+			unlinkAnnex key
+			fs <- filter (/= ingestedf)
+				. map (`fromTopFilePath` g)
+				<$> Database.Keys.getAssociatedFiles key
+			filterM (`sameInodeCache` caches) fs >>= \case
+				-- If linkToAnnex fails, the associated 
+				-- file with the content is still present,
+				-- so no need for any recovery.
+				(f:_) -> do
+					ic <- withTSDelta (liftIO . genInodeCache f)
+					void $ linkToAnnex key f ic
+				_ -> logStatus key InfoMissing
+
+{- On error, put the file back so it doesn't seem to have vanished.
+ - This can be called before or after the symlink is in place. -}
+restoreFile :: RawFilePath -> Key -> SomeException -> Annex a
+restoreFile file key e = do
+	whenM (inAnnex key) $ do
+		liftIO $ removeWhenExistsWith R.removeLink file
+		-- The key could be used by other files too, so leave the
+		-- content in the annex, and make a copy back to the file.
+		obj <- fromRawFilePath <$> calcRepo (gitAnnexLocation key)
+		unlessM (liftIO $ copyFileExternal CopyTimeStamps obj (fromRawFilePath file)) $
+			warning $ "Unable to restore content of " <> QuotedPath file <> "; it should be located in " <> QuotedPath (toRawFilePath obj)
+		thawContent file
+	throwM e
+
+{- Creates the symlink to the annexed content, returns the link target. -}
+makeLink :: RawFilePath -> Key -> Maybe InodeCache -> Annex LinkTarget
+makeLink file key mcache = flip catchNonAsync (restoreFile file key) $ do
+	l <- calcRepo $ gitAnnexLink file key
+	replaceWorkTreeFile file' $ makeAnnexLink l
+
+	-- touch symlink to have same time as the original file,
+	-- as provided in the InodeCache
+	case mcache of
+		Just c -> liftIO $ touch file (inodeCacheToMtime c) False
+		Nothing -> noop
+
+	return l
+  where
+	file' = fromRawFilePath file
+
+{- Creates the symlink to the annexed content, and stages it in git. -}
+addSymlink :: RawFilePath -> Key -> Maybe InodeCache -> Annex ()
+addSymlink file key mcache = stageSymlink file =<< genSymlink file key mcache
+
+genSymlink :: RawFilePath -> Key -> Maybe InodeCache -> Annex Git.Sha
+genSymlink file key mcache = do
+	linktarget <- makeLink file key mcache
+	hashSymlink linktarget
+
+{- Parameters to pass to git add, forcing addition of ignored files.
+ -
+ - Note that, when git add is being run on an ignored file that is already
+ - checked in, CheckGitIgnore True has no effect.
+ -}
+gitAddParams :: CheckGitIgnore -> Annex [CommandParam]
+gitAddParams (CheckGitIgnore True) = ifM (Annex.getRead Annex.force)
+	( return [Param "-f"]
+	, return []
+	)
+gitAddParams (CheckGitIgnore False) = return [Param "-f"]
+
+{- Whether a file should be added unlocked or not. Default is to not,
+ - unless symlinks are not supported. annex.addunlocked can override that.
+ - Also, when in an adjusted branch that unlocked files, always add files
+ - unlocked.
+ -}
+addUnlocked :: AddUnlockedMatcher -> MatchInfo -> Bool -> Annex Bool
+addUnlocked matcher mi contentpresent =
+	((not . coreSymlinks <$> Annex.getGitConfig) <||>
+	 (checkAddUnlockedMatcher matcher mi) <||>
+	 (maybe False go . snd <$> getCurrentBranch)
+	)
+  where
+	go (LinkAdjustment UnlockAdjustment) = True
+	go (LinkAdjustment LockAdjustment) = False
+	go (LinkAdjustment FixAdjustment) = False
+	go (LinkAdjustment UnFixAdjustment) = False
+	go (PresenceAdjustment _ (Just la)) = go (LinkAdjustment la)
+	go (PresenceAdjustment _ Nothing) = False
+	go (LinkPresentAdjustment UnlockPresentAdjustment) = contentpresent
+	go (LinkPresentAdjustment LockPresentAdjustment) = False
+
+{- Adds a file to the work tree for the key, and stages it in the index.
+ - The content of the key may be provided in a temp file, which will be
+ - moved into place. If no content is provided, adds an annex link but does
+ - not ingest the content.
+ -
+ - When the content of the key is not accepted into the annex, returns False.
+ -}
+addAnnexedFile :: AddUnlockedMatcher -> RawFilePath -> Key -> Maybe RawFilePath -> Annex Bool
+addAnnexedFile matcher file key mtmp = ifM (addUnlocked matcher mi (isJust mtmp))
+	( do
+		mode <- maybe
+			(pure Nothing)
+			(\tmp -> liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus tmp)
+			mtmp
+		stagePointerFile file mode =<< hashPointerFile key
+		Database.Keys.addAssociatedFile key =<< inRepo (toTopFilePath file)
+		case mtmp of
+			Just tmp -> ifM (moveAnnex key af tmp)
+				( linkunlocked mode >> return True
+				, writepointer mode >> return False
+				)
+			Nothing -> ifM (inAnnex key)
+				( linkunlocked mode >> return True
+				, writepointer mode >> return True
+				)
+	, do
+		addSymlink file key Nothing
+		case mtmp of
+			Just tmp -> moveAnnex key af tmp
+			Nothing -> return True
+	)
+  where
+	af = AssociatedFile (Just file)
+	mi = case mtmp of
+		Just tmp -> MatchingFile $ FileInfo
+			{ contentFile = tmp
+			, matchFile = file
+			, matchKey = Just key
+			}
+		Nothing -> keyMatchInfoWithoutContent key file
+	
+	linkunlocked mode = linkFromAnnex key file mode >>= \case
+		LinkAnnexFailed -> writepointer mode
+		_ -> return ()
+	
+	writepointer mode = liftIO $ writePointerFile file key mode
+
+{- Use with actions that add an already existing annex symlink or pointer
+ - file. The warning avoids a confusing situation where the file got copied
+ - from another git-annex repo, probably by accident. -}
+addingExistingLink :: RawFilePath -> Key -> Annex a -> Annex a
+addingExistingLink f k a = do
+	unlessM (isKnownKey k <||> inAnnex k) $ do
+		islink <- isJust <$> isAnnexLink f
+		warning $
+			QuotedPath f
+			<> " is a git-annex "
+			<> if islink then "symlink." else "pointer file."
+			<> " Its content is not available in this repository."
+			<> " (Maybe " <> QuotedPath f <> " was copied from another repository?)"
+	a
diff --git a/Annex/Init.hs b/Annex/Init.hs
new file mode 100644
index 0000000000..6a499e4771
--- /dev/null
+++ b/Annex/Init.hs
@@ -0,0 +1,466 @@
+{- git-annex repository initialization
+ -
+ - Copyright 2011-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Init (
+	checkInitializeAllowed,
+	ensureInitialized,
+	autoInitialize,
+	isInitialized,
+	initialize,
+	initialize',
+	uninitialize,
+	probeCrippledFileSystem,
+	probeCrippledFileSystem',
+) where
+
+import Annex.Common
+import qualified Annex
+import qualified Git
+import qualified Git.Config
+import qualified Git.Objects
+import Git.Types (fromConfigValue)
+import Git.ConfigTypes (SharedRepository(..))
+import qualified Annex.Branch
+import qualified Database.Fsck
+import Logs.UUID
+import Logs.Trust.Basic
+import Logs.Config
+import Types.TrustLevel
+import Types.RepoVersion
+import Annex.Version
+import Annex.Difference
+import Annex.UUID
+import Annex.Fixup
+import Annex.Path
+import Config
+import Config.Files
+import Config.Smudge
+import qualified Upgrade.V5.Direct as Direct
+import qualified Annex.AdjustedBranch as AdjustedBranch
+import Remote.List.Util (remotesChanged)
+import Annex.Environment
+import Annex.Hook
+import Annex.InodeSentinal
+import Upgrade
+import Annex.Tmp
+import Utility.UserInfo
+import Annex.Perms
+#ifndef mingw32_HOST_OS
+import Utility.ThreadScheduler
+import qualified Utility.RawFilePath as R
+import Utility.FileMode
+import System.Posix.User
+import qualified Utility.LockFile.Posix as Posix
+#endif
+
+import qualified Data.Map as M
+import Control.Monad.IO.Class (MonadIO)
+#ifndef mingw32_HOST_OS
+import System.PosixCompat.Files (ownerReadMode, isNamedPipe)
+import Data.Either
+import qualified System.FilePath.ByteString as P
+import Control.Concurrent.Async
+#endif
+
+data InitializeAllowed = InitializeAllowed
+
+checkInitializeAllowed :: (InitializeAllowed -> Annex a) -> Annex a
+checkInitializeAllowed a = guardSafeToUseRepo $ noAnnexFileContent' >>= \case
+	Nothing -> do
+		checkSqliteWorks
+		a InitializeAllowed
+	Just noannexmsg -> do
+		warning "Initialization prevented by .noannex file (remove the file to override)"
+		unless (null noannexmsg) $
+			warning (UnquotedString noannexmsg)
+		giveup "Not initialized."
+
+initializeAllowed :: Annex Bool
+initializeAllowed = isNothing <$> noAnnexFileContent'
+
+noAnnexFileContent' :: Annex (Maybe String)
+noAnnexFileContent' = inRepo $
+	noAnnexFileContent . fmap fromRawFilePath . Git.repoWorkTree
+
+genDescription :: Maybe String -> Annex UUIDDesc
+genDescription (Just d) = return $ UUIDDesc $ encodeBS d
+genDescription Nothing = do
+	reldir <- liftIO . relHome . fromRawFilePath
+		=<< liftIO . absPath
+		=<< fromRepo Git.repoPath
+	hostname <- fromMaybe "" <$> liftIO getHostname
+	let at = if null hostname then "" else "@"
+	v <- liftIO myUserName
+	return $ UUIDDesc $ encodeBS $ concat $ case v of
+		Right username -> [username, at, hostname, ":", reldir]
+		Left _ -> [hostname, ":", reldir]
+
+initialize :: Maybe String -> Maybe RepoVersion -> Annex ()
+initialize mdescription mversion = checkInitializeAllowed $ \initallowed -> do
+	{- Has to come before any commits are made as the shared
+	 - clone heuristic expects no local objects. -}
+	sharedclone <- checkSharedClone
+
+	{- This will make the first commit to git, so ensure git is set up
+	 - properly to allow commits when running it. -}
+	ensureCommit $ Annex.Branch.create
+
+	prepUUID
+	initialize' mversion initallowed
+	
+	initSharedClone sharedclone
+	
+	u <- getUUID
+	when (u == NoUUID) $
+		giveup "Failed to read annex.uuid from git config after setting it. This should never happen. Please file a bug report."
+	
+	{- Avoid overwriting existing description with a default
+	 - description. -}
+	whenM (pure (isJust mdescription) <||> not . M.member u <$> uuidDescMapRaw) $
+		describeUUID u =<< genDescription mdescription
+
+-- Everything except for uuid setup, shared clone setup, and initial
+-- description.
+initialize' :: Maybe RepoVersion -> InitializeAllowed -> Annex ()
+initialize' mversion _initallowed = do
+	checkLockSupport
+	checkFifoSupport
+	checkCrippledFileSystem
+	unlessM isBareRepo $ do
+		hookWrite preCommitHook
+		hookWrite postReceiveHook
+	setDifferences
+	unlessM (isJust <$> getVersion) $
+		setVersion (fromMaybe defaultVersion mversion)
+	supportunlocked <- annexSupportUnlocked <$> Annex.getGitConfig
+	if supportunlocked
+		then configureSmudgeFilter
+		else deconfigureSmudgeFilter
+	unlessM isBareRepo $ do
+		hookWrite postCheckoutHook
+		hookWrite postMergeHook
+
+	AdjustedBranch.checkAdjustedClone >>= \case
+		AdjustedBranch.InAdjustedClone -> return ()
+		AdjustedBranch.NotInAdjustedClone ->
+			ifM (crippledFileSystem <&&> (not <$> isBareRepo))
+				( AdjustedBranch.adjustToCrippledFileSystem
+				-- Handle case where this repo was cloned from a
+				-- direct mode repo
+				, unlessM isBareRepo
+					Direct.switchHEADBack
+				)
+	propigateSecureHashesOnly
+	createInodeSentinalFile False
+	fixupUnusualReposAfterInit
+
+uninitialize :: Annex ()
+uninitialize = do
+	-- Remove hooks that are written when initializing.
+	hookUnWrite preCommitHook
+	hookUnWrite postReceiveHook
+	hookUnWrite postCheckoutHook
+	hookUnWrite postMergeHook
+	deconfigureSmudgeFilter
+	removeRepoUUID
+	removeVersion
+
+{- Gets the version that the repo is initialized with.
+ -
+ - To make sure the repo is fully initialized, also checks that it has a
+ - uuid configured. In the unusual case where one is set and the other is
+ - not, errors out to avoid running in an inconsistent state.
+ -}
+getInitializedVersion :: Annex (Maybe RepoVersion)
+getInitializedVersion = do
+	um <- (\u -> if u == NoUUID then Nothing else Just u) <$> getUUID
+	vm <- getVersion
+	case (um, vm) of
+		(Just _, Just v) -> return (Just v)
+		(Nothing, Nothing) -> return Nothing
+		(Just _, Nothing) -> onemissing "annex.version" "annex.uuid"
+		(Nothing, Just _) -> onemissing "annex.uuid" "annex.version"
+  where
+	onemissing missing have = giveup $ unwords
+		[ "This repository has " ++ have ++ " set,"
+		, "but " ++ missing ++ " is not set. Perhaps that"
+		, "git config was lost. Cannot use the repository"
+		, "in this state; set back " ++ missing ++ " to fix this."
+		]
+
+{- Will automatically initialize if there is already a git-annex
+ - branch from somewhere. Otherwise, require a manual init
+ - to avoid git-annex accidentally being run in git
+ - repos that did not intend to use it.
+ -
+ - Checks repository version and handles upgrades too.
+ -}
+ensureInitialized :: Annex [Remote] -> Annex ()
+ensureInitialized remotelist = getInitializedVersion >>= maybe needsinit checkUpgrade
+  where
+	needsinit = ifM autoInitializeAllowed
+		( do
+			tryNonAsync (initialize Nothing Nothing) >>= \case
+				Right () -> noop
+				Left e -> giveup $ show e ++ "\n" ++
+					"git-annex: automatic initialization failed due to above problems"
+			autoEnableSpecialRemotes remotelist
+		, giveup "First run: git-annex init"
+		)
+
+{- Check if auto-initialize is allowed. -}
+autoInitializeAllowed :: Annex Bool
+autoInitializeAllowed = Annex.Branch.hasSibling <&&> objectDirNotPresent
+
+objectDirNotPresent :: Annex Bool
+objectDirNotPresent = do
+	d <- fromRawFilePath <$> fromRepo gitAnnexObjectDir
+	exists <- liftIO $ doesDirectoryExist d
+	when exists $ guardSafeToUseRepo $
+		giveup $ unwords $ 
+			[ "This repository is not initialized for use"
+			, "by git-annex, but " ++ d ++ " exists,"
+			, "which indicates this repository was used by"
+			, "git-annex before, and may have lost its"
+			, "annex.uuid and annex.version configs. Either"
+			, "set back missing configs, or run git-annex init"
+			, "to initialize with a new uuid."
+			]
+	return (not exists)
+
+guardSafeToUseRepo :: Annex a -> Annex a
+guardSafeToUseRepo a = ifM (inRepo Git.Config.checkRepoConfigInaccessible)
+	( do
+		repopath <- fromRepo Git.repoPath
+		p <- liftIO $ absPath repopath
+		giveup $ unlines $
+			[ "Git refuses to operate in this repository,"
+			, "probably because it is owned by someone else."
+			, ""
+			-- This mirrors git's wording.
+			, "To add an exception for this directory, call:"
+			, "\tgit config --global --add safe.directory " ++ fromRawFilePath p
+			]
+	, a
+	)
+
+{- Initialize if it can do so automatically. Avoids failing if it cannot.
+ -
+ - Checks repository version and handles upgrades too.
+ -}
+autoInitialize :: Annex [Remote] -> Annex ()
+autoInitialize remotelist = getInitializedVersion >>= maybe needsinit checkUpgrade
+  where
+	needsinit =
+		whenM (initializeAllowed <&&> autoInitializeAllowed) $ do
+			initialize Nothing Nothing
+			autoEnableSpecialRemotes remotelist
+
+{- Checks if a repository is initialized. Does not check version for ugrade. -}
+isInitialized :: Annex Bool
+isInitialized = maybe Annex.Branch.hasSibling (const $ return True) =<< getVersion
+
+{- A crippled filesystem is one that does not allow making symlinks,
+ - or removing write access from files. -}
+probeCrippledFileSystem :: Annex Bool
+probeCrippledFileSystem = withEventuallyCleanedOtherTmp $ \tmp -> do
+	(r, warnings) <- probeCrippledFileSystem' tmp
+		(Just (freezeContent' UnShared))
+		(Just (thawContent' UnShared))
+		=<< hasFreezeHook
+	mapM_ (warning . UnquotedString) warnings
+	return r
+
+probeCrippledFileSystem'
+	:: (MonadIO m, MonadCatch m)
+	=> RawFilePath
+	-> Maybe (RawFilePath -> m ())
+	-> Maybe (RawFilePath -> m ())
+	-> Bool
+	-> m (Bool, [String])
+#ifdef mingw32_HOST_OS
+probeCrippledFileSystem' _ _ _ _ = return (True, [])
+#else
+probeCrippledFileSystem' tmp freezecontent thawcontent hasfreezehook = do
+	let f = tmp P.</> "gaprobe"
+	let f' = fromRawFilePath f
+	liftIO $ writeFile f' ""
+	r <- probe f'
+	void $ tryNonAsync $ (fromMaybe (liftIO . allowWrite) thawcontent) f
+	liftIO $ removeFile f'
+	return r
+  where
+	probe f = catchDefaultIO (True, []) $ do
+		let f2 = f ++ "2"
+		liftIO $ removeWhenExistsWith R.removeLink (toRawFilePath f2)
+		liftIO $ R.createSymbolicLink (toRawFilePath f) (toRawFilePath f2)
+		liftIO $ removeWhenExistsWith R.removeLink (toRawFilePath f2)
+		(fromMaybe (liftIO . preventWrite) freezecontent) (toRawFilePath f)
+		-- Should be unable to write to the file (unless
+		-- running as root). But some crippled
+		-- filesystems ignore write bit removals or ignore
+		-- permissions entirely.
+		ifM ((== Just False) <$> liftIO (checkContentWritePerm' UnShared (toRawFilePath f) Nothing hasfreezehook))
+			( return (True, ["Filesystem does not allow removing write bit from files."])
+			, liftIO $ ifM ((== 0) <$> getRealUserID)
+				( return (False, [])
+				, do
+					r <- catchBoolIO $ do
+						writeFile f "2"
+						return True
+					if r
+						then return (True, ["Filesystem allows writing to files whose write bit is not set."])
+						else return (False, [])
+				)
+			)
+#endif
+
+checkCrippledFileSystem :: Annex ()
+checkCrippledFileSystem = whenM probeCrippledFileSystem $ do
+	warning "Detected a crippled filesystem."
+	setCrippledFileSystem True
+
+	{- Normally git disables core.symlinks itself when the:w
+	 -
+	 - filesystem does not support them. But, even if symlinks are
+	 - supported, we don't use them by default in a crippled
+	 - filesystem. -}
+	whenM (coreSymlinks <$> Annex.getGitConfig) $ do
+		warning "Disabling core.symlinks."
+		setConfig "core.symlinks"
+			(Git.Config.boolConfig False)
+
+probeLockSupport :: Annex Bool
+#ifdef mingw32_HOST_OS
+probeLockSupport = return True
+#else
+probeLockSupport = withEventuallyCleanedOtherTmp $ \tmp -> do
+	let f = tmp P.</> "lockprobe"
+	mode <- annexFileMode
+	annexrunner <- Annex.makeRunner
+	liftIO $ withAsync (warnstall annexrunner) (const (go f mode))
+  where
+	go f mode = do
+		removeWhenExistsWith R.removeLink f
+		let locktest = bracket
+			(Posix.lockExclusive (Just mode) f)
+			Posix.dropLock
+			(const noop)
+		ok <- isRight <$> tryNonAsync locktest
+		removeWhenExistsWith R.removeLink f
+		return ok
+	
+	warnstall annexrunner = do
+		threadDelaySeconds (Seconds 10)
+		annexrunner $ do
+			warning "Probing the filesystem for POSIX fcntl lock support is taking a long time."
+			warning "(Setting annex.pidlock will avoid this probe.)"
+#endif
+
+probeFifoSupport :: Annex Bool
+probeFifoSupport = do
+#ifdef mingw32_HOST_OS
+	return False
+#else
+	withEventuallyCleanedOtherTmp $ \tmp -> do
+		let f = tmp P.</> "gaprobe"
+		let f2 = tmp P.</> "gaprobe2"
+		liftIO $ do
+			removeWhenExistsWith R.removeLink f
+			removeWhenExistsWith R.removeLink f2
+			ms <- tryIO $ do
+				R.createNamedPipe f ownerReadMode
+				R.createLink f f2
+				R.getFileStatus f
+			removeWhenExistsWith R.removeLink f
+			removeWhenExistsWith R.removeLink f2
+			return $ either (const False) isNamedPipe ms
+#endif
+
+checkLockSupport :: Annex ()
+checkLockSupport =
+	unlessM (annexPidLock <$> Annex.getGitConfig) $
+		unlessM probeLockSupport $ do
+			warning "Detected a filesystem without POSIX fcntl lock support."
+			warning "Enabling annex.pidlock."
+			setConfig (annexConfig "pidlock") (Git.Config.boolConfig True)
+
+checkFifoSupport :: Annex ()
+checkFifoSupport = unlessM probeFifoSupport $ do
+	warning "Detected a filesystem without fifo support."
+	warning "Disabling ssh connection caching."
+	setConfig (annexConfig "sshcaching") (Git.Config.boolConfig False)
+
+{- Sqlite needs the filesystem to support range locking. Some like CIFS
+ - do not, which will cause sqlite to fail with ErrorBusy. -}
+checkSqliteWorks :: Annex ()
+checkSqliteWorks = do
+	u <- getUUID
+	tryNonAsync (Database.Fsck.openDb u >>= Database.Fsck.closeDb) >>= \case
+		Right () -> return ()
+		Left e -> do
+			showLongNote $ "Detected a filesystem where Sqlite does not work."
+			showLongNote $ UnquotedString $ "(" ++ show e ++ ")"
+			showLongNote $ "To work around this problem, you can set annex.dbdir " <>
+				"to a directory on another filesystem."
+			showLongNote $ "For example: git config annex.dbdir $HOME/cache/git-annex"
+			giveup "Not initialized."
+
+checkSharedClone :: Annex Bool
+checkSharedClone = inRepo Git.Objects.isSharedClone
+
+initSharedClone :: Bool -> Annex ()
+initSharedClone False = return ()
+initSharedClone True = do
+	showLongNote "Repository was cloned with --shared; setting annex.hardlink=true and making repository untrusted."
+	u <- getUUID
+	trustSet u UnTrusted
+	setConfig (annexConfig "hardlink") (Git.Config.boolConfig True)
+
+{- Propagate annex.securehashesonly from then global config to local
+ - config. This makes a clone inherit a parent's setting, but once
+ - a repository has a local setting, changes to the global config won't
+ - affect it. -}
+propigateSecureHashesOnly :: Annex ()
+propigateSecureHashesOnly =
+	maybe noop (setConfig "annex.securehashesonly" . fromConfigValue)
+		=<< getGlobalConfig "annex.securehashesonly"
+
+fixupUnusualReposAfterInit :: Annex ()
+fixupUnusualReposAfterInit = do
+	gc <- Annex.getGitConfig
+	void $ inRepo $ \r -> fixupUnusualRepos r gc
+
+{- Try to enable any special remotes that are configured to do so.
+ - 
+ - The enabling is done in a child process to avoid it using stdio.
+ -
+ - The remotelist should be Remote.List.remoteList, which cannot
+ - be imported here due to a dependency loop.
+ -}
+autoEnableSpecialRemotes :: Annex [Remote] -> Annex ()
+autoEnableSpecialRemotes remotelist = do
+	-- Get all existing git remotes to probe for their uuid here,
+	-- so it is not done inside the child process. Doing it in there
+	-- could result in password prompts for http credentials,
+	-- which would then not end up cached in this process's state.
+	_ <- remotelist
+	rp <- fromRawFilePath <$> fromRepo Git.repoPath
+	withNullHandle $ \nullh -> gitAnnexChildProcess "init"
+		[ Param "--autoenable" ]
+		(\p -> p
+			{ std_out = UseHandle nullh
+			, std_err = UseHandle nullh
+			, std_in = UseHandle nullh
+			, cwd = Just rp
+			}
+		)
+		(\_ _ _ pid -> void $ waitForProcess pid)
+	remotesChanged
diff --git a/Annex/InodeSentinal.hs b/Annex/InodeSentinal.hs
new file mode 100644
index 0000000000..129dd08b71
--- /dev/null
+++ b/Annex/InodeSentinal.hs
@@ -0,0 +1,112 @@
+{- git-annex inode sentinal file
+ -
+ - Copyright 2012-2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.InodeSentinal where
+
+import Annex.Common
+import qualified Annex
+import Utility.InodeCache
+import Annex.Perms
+
+{- If the sendinal shows the inodes have changed, only the size and mtime
+ - are compared. -}
+compareInodeCaches :: InodeCache -> InodeCache -> Annex Bool
+compareInodeCaches x y
+	| compareStrong x y = return True
+	| otherwise = ifM inodesChanged
+		( return $ compareWeak x y
+		, return False
+		)
+
+compareInodeCachesWith :: Annex InodeComparisonType
+compareInodeCachesWith = ifM inodesChanged ( return Weakly, return Strongly )
+
+{- Checks if one of the provided old InodeCache matches the current
+ - version of a file. -}
+sameInodeCache :: RawFilePath -> [InodeCache] -> Annex Bool
+sameInodeCache file [] = do
+	fastDebug "Annex.InodeSentinal" $
+		fromRawFilePath file ++ " inode cache empty"
+	return False
+sameInodeCache file old = go =<< withTSDelta (liftIO . genInodeCache file)
+  where
+	go Nothing = do
+		fastDebug "Annex.InodeSentinal" $
+			fromRawFilePath file ++ " not present, cannot compare with inode cache"
+		return False
+	go (Just curr) = ifM (elemInodeCaches curr old)
+		( return True
+		, do
+			fastDebug "Annex.InodeSentinal" $
+				fromRawFilePath file ++ " (" ++ show curr ++ ") does not match inode cache (" ++ show old ++ ")"
+			return False
+		)
+
+elemInodeCaches :: InodeCache -> [InodeCache] -> Annex Bool
+elemInodeCaches _ [] = return False
+elemInodeCaches c (l:ls) = ifM (compareInodeCaches c l)
+	( return True
+	, elemInodeCaches c ls
+	)
+
+{- Some filesystems get new inodes each time they are mounted.
+ - In order to work on such a filesystem, a sentinal file is used to detect
+ - when the inodes have changed.
+ -
+ - If the sentinal file does not exist, we have to assume that the
+ - inodes have changed.
+ -}
+inodesChanged :: Annex Bool
+inodesChanged = sentinalInodesChanged <$> sentinalStatus
+
+withTSDelta :: (TSDelta -> Annex a) -> Annex a
+withTSDelta a = a =<< getTSDelta
+
+getTSDelta :: Annex TSDelta
+#ifdef mingw32_HOST_OS
+getTSDelta = sentinalTSDelta <$> sentinalStatus
+#else
+getTSDelta = pure noTSDelta -- optimisation
+#endif
+
+sentinalStatus :: Annex SentinalStatus
+sentinalStatus = maybe check return =<< Annex.getState Annex.sentinalstatus
+  where
+	check = do
+		sc <- liftIO . checkSentinalFile =<< annexSentinalFile
+		Annex.changeState $ \s -> s { Annex.sentinalstatus = Just sc }
+		return sc
+
+{- The sentinal file is only created when first initializing a repository.
+ - If there are any annexed objects in the repository already, creating
+ - the file would invalidate their inode caches. -}
+createInodeSentinalFile :: Bool -> Annex ()
+createInodeSentinalFile evenwithobjects = 
+	unlessM (alreadyexists <||> hasobjects) $ do
+		s <- annexSentinalFile
+		createAnnexDirectory (parentDir (sentinalFile s))
+		liftIO $ writeSentinalFile s
+		setAnnexFilePerm (sentinalFile s)
+		setAnnexFilePerm (sentinalCacheFile s)
+  where
+	alreadyexists = liftIO. sentinalFileExists =<< annexSentinalFile
+	hasobjects
+		| evenwithobjects = pure False
+		| otherwise = liftIO . doesDirectoryExist . fromRawFilePath
+			=<< fromRepo gitAnnexObjectDir
+
+annexSentinalFile :: Annex SentinalFile
+annexSentinalFile = do
+	sentinalfile <- fromRepo gitAnnexInodeSentinal
+	sentinalcachefile <- fromRepo gitAnnexInodeSentinalCache
+	return SentinalFile
+		{ sentinalFile = sentinalfile
+		, sentinalCacheFile = sentinalcachefile
+		}
diff --git a/Annex/Journal.hs b/Annex/Journal.hs
new file mode 100644
index 0000000000..ea6327606d
--- /dev/null
+++ b/Annex/Journal.hs
@@ -0,0 +1,294 @@
+{- management of the git-annex journal
+ -
+ - The journal is used to queue up changes before they are committed to the
+ - git-annex branch. Among other things, it ensures that if git-annex is
+ - interrupted, its recorded data is not lost.
+ -
+ - All files in the journal must be a series of lines separated by
+ - newlines.
+ -
+ - Copyright 2011-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE CPP #-}
+
+module Annex.Journal where
+
+import Annex.Common
+import qualified Annex
+import qualified Git
+import Annex.Perms
+import Annex.Tmp
+import Annex.LockFile
+import Utility.Directory.Stream
+import qualified Utility.RawFilePath as R
+
+import qualified Data.Set as S
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString as B
+import qualified System.FilePath.ByteString as P
+import Data.ByteString.Builder
+import Data.Char
+
+class Journalable t where
+	writeJournalHandle :: Handle -> t -> IO ()
+	journalableByteString :: t -> L.ByteString
+
+instance Journalable L.ByteString where
+	writeJournalHandle = L.hPut
+	journalableByteString = id
+
+-- This is more efficient than the ByteString instance.
+instance Journalable Builder where
+	writeJournalHandle = hPutBuilder
+	journalableByteString = toLazyByteString
+
+{- When a file in the git-annex branch is changed, this indicates what
+ - repository UUID (or in some cases, UUIDs) a change is regarding.
+ -
+ - Using this lets changes regarding private UUIDs be stored separately
+ - from the git-annex branch, so its information does not get exposed
+ - outside the repo.
+ -}
+data RegardingUUID = RegardingUUID [UUID]
+
+regardingPrivateUUID :: RegardingUUID -> Annex Bool
+regardingPrivateUUID (RegardingUUID []) = pure False
+regardingPrivateUUID (RegardingUUID us) = do
+	s <- annexPrivateRepos <$> Annex.getGitConfig
+	return (any (flip S.member s) us)
+
+{- Are any private UUIDs known to exist? If so, extra work has to be done,
+ - to check for information separately recorded for them, outside the usual
+ - locations.
+ -}
+privateUUIDsKnown :: Annex Bool
+privateUUIDsKnown = privateUUIDsKnown' <$> Annex.getState id
+
+privateUUIDsKnown' :: Annex.AnnexState -> Bool
+privateUUIDsKnown' = not . S.null . annexPrivateRepos . Annex.gitconfig
+
+{- Records content for a file in the branch to the journal.
+ -
+ - Using the journal, rather than immediately staging content to the index
+ - avoids git needing to rewrite the index after every change.
+ - 
+ - The file in the journal is updated atomically. This avoids an
+ - interrupted write truncating information that was earlier read from the
+ - file, and so losing data.
+ -}
+setJournalFile :: Journalable content => JournalLocked -> RegardingUUID -> RawFilePath -> content -> Annex ()
+setJournalFile _jl ru file content = withOtherTmp $ \tmp -> do
+	jd <- fromRepo =<< ifM (regardingPrivateUUID ru)
+		( return gitAnnexPrivateJournalDir
+		, return gitAnnexJournalDir
+		)
+	-- journal file is written atomically
+	let jfile = journalFile file
+	let tmpfile = tmp P.</> jfile
+	liftIO $ withFile (fromRawFilePath tmpfile) WriteMode $ \h ->
+		writeJournalHandle h content
+	let dest = jd P.</> jfile
+	let mv = do
+		liftIO $ moveFile tmpfile dest
+		setAnnexFilePerm dest
+	-- avoid overhead of creating the journal directory when it already
+	-- exists
+	mv `catchIO` (const (createAnnexDirectory jd >> mv))
+
+newtype AppendableJournalFile = AppendableJournalFile (RawFilePath, RawFilePath)
+
+{- If the journal file does not exist, it cannot be appended to, because
+ - that would overwrite whatever content the file has in the git-annex
+ - branch. -}
+checkCanAppendJournalFile :: JournalLocked -> RegardingUUID -> RawFilePath -> Annex (Maybe AppendableJournalFile)
+checkCanAppendJournalFile _jl ru file = do
+	jd <- fromRepo =<< ifM (regardingPrivateUUID ru)
+		( return gitAnnexPrivateJournalDir
+		, return gitAnnexJournalDir
+		)
+	let jfile = jd P.</> journalFile file
+	ifM (liftIO $ R.doesPathExist jfile)
+		( return (Just (AppendableJournalFile (jd, jfile)))
+		, return Nothing
+		)
+
+{- Appends content to an existing journal file.
+ -
+ - Appends are not necessarily atomic, though short appends often are.
+ - So, when this is interrupted, it can leave only part of the content
+ - written to the file. To deal with that situation, both this and
+ - getJournalFileStale check if the file ends with a newline, and if
+ - not discard the incomplete line.
+ -
+ - Due to the lack of atomicity, this should not be used when multiple
+ - lines need to be written to the file as an atomic unit.
+ -}
+appendJournalFile :: Journalable content => JournalLocked -> AppendableJournalFile -> content -> Annex ()
+appendJournalFile _jl (AppendableJournalFile (jd, jfile)) content = do
+	let write = liftIO $ withFile (fromRawFilePath jfile) ReadWriteMode $ \h -> do
+		sz <- hFileSize h
+		when (sz /= 0) $ do
+			hSeek h SeekFromEnd (-1)
+			lastchar <- B.hGet h 1
+			unless (lastchar == "\n") $ do
+				hSeek h AbsoluteSeek 0
+				goodpart <- L.length . discardIncompleteAppend
+					<$> L.hGet h (fromIntegral sz)
+				hSetFileSize h (fromIntegral goodpart)
+				hSeek h SeekFromEnd 0
+		writeJournalHandle h content
+	write `catchIO` (const (createAnnexDirectory jd >> write))
+
+data JournalledContent
+	= NoJournalledContent
+	| JournalledContent L.ByteString
+	| PossiblyStaleJournalledContent L.ByteString
+	-- ^ This is used when the journalled content may have been 
+	-- supersceded by content in the git-annex branch. The returned
+	-- content should be combined with content from the git-annex branch.
+	-- This is particularly the case when a file is in the private
+	-- journal, which does not get written to the git-annex branch,
+	-- and so the git-annex branch can contain changes to non-private
+	-- information that were made after that journal file was written.
+
+{- Gets any journalled content for a file in the branch. -}
+getJournalFile :: JournalLocked -> GetPrivate -> RawFilePath -> Annex JournalledContent
+getJournalFile _jl = getJournalFileStale
+
+data GetPrivate = GetPrivate Bool
+
+{- Without locking, this is not guaranteed to be the most recent
+ - content of the file in the journal, so should not be used as a basis for
+ - making changes to the file.
+ -
+ - The file is read strictly so that its content can safely be fed into
+ - an operation that modifies the file (when getJournalFile calls this). 
+ - The minor loss of laziness doesn't matter much, as the files are not
+ - very large.
+ -
+ - To recover from an append of a line that is interrupted part way through
+ - (or is in progress when this is called), if the file content does not end
+ - with a newline, it is truncated back to the previous newline.
+ -}
+getJournalFileStale :: GetPrivate -> RawFilePath -> Annex JournalledContent
+getJournalFileStale (GetPrivate getprivate) file = do
+	-- Optimisation to avoid a second MVar access.
+	st <- Annex.getState id
+	let g = Annex.repo st
+	liftIO $
+		if getprivate && privateUUIDsKnown' st
+		then do
+			x <- getfrom (gitAnnexJournalDir g)
+			getfrom (gitAnnexPrivateJournalDir g) >>= \case
+				Nothing -> return $ case x of
+					Nothing -> NoJournalledContent
+					Just b -> JournalledContent b
+				Just y -> return $ PossiblyStaleJournalledContent $ case x of
+					Nothing -> y
+					-- This concacenation is the same as
+					-- happens in a merge of two
+					-- git-annex branches.
+					Just x' -> x' <> y
+		else getfrom (gitAnnexJournalDir g) >>= return . \case
+			Nothing -> NoJournalledContent
+			Just b -> JournalledContent b
+  where
+	jfile = journalFile file
+	getfrom d = catchMaybeIO $
+		discardIncompleteAppend . L.fromStrict
+			<$> B.readFile (fromRawFilePath (d P.</> jfile))
+
+-- Note that this forces read of the whole lazy bytestring.
+discardIncompleteAppend :: L.ByteString -> L.ByteString
+discardIncompleteAppend v
+	| L.null v = v
+	| L.last v == nl = v
+	| otherwise = dropwhileend (/= nl) v
+  where
+	nl = fromIntegral (ord '\n')
+#if MIN_VERSION_bytestring(0,11,2)
+	dropwhileend = L.dropWhileEnd
+#else
+	dropwhileend p = L.reverse . L.dropWhile p . L.reverse
+#endif
+
+{- List of existing journal files in a journal directory, but without locking,
+ - may miss new ones just being added, or may have false positives if the
+ - journal is staged as it is run. -}
+getJournalledFilesStale :: (Git.Repo -> RawFilePath) -> Annex [RawFilePath]
+getJournalledFilesStale getjournaldir = do
+	g <- gitRepo
+	fs <- liftIO $ catchDefaultIO [] $
+		getDirectoryContents $ fromRawFilePath (getjournaldir g)
+	return $ filter (`notElem` [".", ".."]) $
+		map (fileJournal . toRawFilePath) fs
+
+{- Directory handle open on a journal directory. -}
+withJournalHandle :: (Git.Repo -> RawFilePath) -> (DirectoryHandle -> IO a) -> Annex a
+withJournalHandle getjournaldir a = do
+	d <- fromRepo getjournaldir
+	bracket (opendir d) (liftIO . closeDirectory) (liftIO . a)
+  where
+	-- avoid overhead of creating the journal directory when it already
+	-- exists
+	opendir d = liftIO (openDirectory (fromRawFilePath d))
+		`catchIO` (const (createAnnexDirectory d >> opendir d))
+
+{- Checks if there are changes in the journal. -}
+journalDirty :: (Git.Repo -> RawFilePath) -> Annex Bool
+journalDirty getjournaldir = do
+	d <- fromRawFilePath <$> fromRepo getjournaldir
+	liftIO $ 
+		(not <$> isDirectoryEmpty d)
+			`catchIO` (const $ doesDirectoryExist d)
+
+{- Produces a filename to use in the journal for a file on the branch.
+ - The filename does not include the journal directory.
+ -
+ - The journal typically won't have a lot of files in it, so the hashing
+ - used in the branch is not necessary, and all the files are put directly
+ - in the journal directory.
+ -}
+journalFile :: RawFilePath -> RawFilePath
+journalFile file = B.concatMap mangle file
+  where
+	mangle c
+		| P.isPathSeparator c = B.singleton underscore
+		| c == underscore = B.pack [underscore, underscore]
+		| otherwise = B.singleton c
+	underscore = fromIntegral (ord '_')
+
+{- Converts a journal file (relative to the journal dir) back to the
+ - filename on the branch. -}
+fileJournal :: RawFilePath -> RawFilePath
+fileJournal = go
+  where
+	go b = 
+		let (h, t) = B.break (== underscore) b
+		in h <> case B.uncons t of
+			Nothing -> t
+			Just (_u, t') -> case B.uncons t' of
+				Nothing -> t'			
+				Just (w, t'')
+					| w == underscore ->
+						B.cons underscore (go t'')
+					| otherwise -> 
+						B.cons P.pathSeparator (go t')
+	
+	underscore = fromIntegral (ord '_')
+
+{- Sentinal value, only produced by lockJournal; required
+ - as a parameter by things that need to ensure the journal is
+ - locked. -}
+data JournalLocked = ProduceJournalLocked
+
+{- Runs an action that modifies the journal, using locking to avoid
+ - contention with other git-annex processes. -}
+lockJournal :: (JournalLocked -> Annex a) -> Annex a
+lockJournal a = do
+	lck <- fromRepo gitAnnexJournalLock
+	withExclusiveLock lck $ a ProduceJournalLocked
diff --git a/Annex/Link.hs b/Annex/Link.hs
new file mode 100644
index 0000000000..4961499f62
--- /dev/null
+++ b/Annex/Link.hs
@@ -0,0 +1,476 @@
+{- git-annex links to content
+ -
+ - On file systems that support them, symlinks are used.
+ -
+ - On other filesystems, git instead stores the symlink target in a regular
+ - file.
+ -
+ - Pointer files are used instead of symlinks for unlocked files.
+ -
+ - Copyright 2013-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP, BangPatterns, OverloadedStrings #-}
+
+module Annex.Link where
+
+import Annex.Common
+import qualified Annex
+import qualified Annex.Queue
+import qualified Git.Queue
+import qualified Git.UpdateIndex
+import qualified Git.Index
+import qualified Git.LockFile
+import qualified Git.Env
+import qualified Git
+import Logs.Restage
+import Git.Types
+import Git.FilePath
+import Git.Config
+import Annex.HashObject
+import Annex.InodeSentinal
+import Annex.PidLock
+import Utility.FileMode
+import Utility.InodeCache
+import Utility.Tmp.Dir
+import Utility.CopyFile
+import qualified Database.Keys.Handle
+import qualified Utility.RawFilePath as R
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.ByteString.Lazy as L
+import qualified System.FilePath.ByteString as P
+#ifndef mingw32_HOST_OS
+#if MIN_VERSION_unix(2,8,0)
+#else
+import System.PosixCompat.Files (isSymbolicLink)
+#endif
+#endif
+
+type LinkTarget = S.ByteString
+
+{- Checks if a file is a link to a key. -}
+isAnnexLink :: RawFilePath -> Annex (Maybe Key)
+isAnnexLink file = maybe Nothing parseLinkTargetOrPointer <$> getAnnexLinkTarget file
+
+{- Gets the link target of a symlink.
+ -
+ - On a filesystem that does not support symlinks, fall back to getting the
+ - link target by looking inside the file.
+ -
+ - Returns Nothing if the file is not a symlink, or not a link to annex
+ - content.
+ -}
+getAnnexLinkTarget :: RawFilePath -> Annex (Maybe LinkTarget)
+getAnnexLinkTarget f = getAnnexLinkTarget' f
+	=<< (coreSymlinks <$> Annex.getGitConfig)
+
+{- Pass False to force looking inside file, for when git checks out
+ - symlinks as plain files. -}
+getAnnexLinkTarget' :: RawFilePath -> Bool -> Annex (Maybe S.ByteString)
+getAnnexLinkTarget' file coresymlinks = if coresymlinks
+	then check probesymlink $
+		return Nothing
+	else check probesymlink $
+		check probefilecontent $
+			return Nothing
+  where
+	check getlinktarget fallback = 
+		liftIO (catchMaybeIO getlinktarget) >>= \case
+			Just l
+				| isLinkToAnnex l -> return (Just l)
+				| otherwise -> return Nothing
+			Nothing -> fallback
+
+	probesymlink = R.readSymbolicLink file
+
+	probefilecontent = withFile (fromRawFilePath file) ReadMode $ \h -> do
+		s <- S.hGet h maxSymlinkSz
+		-- If we got the full amount, the file is too large
+		-- to be a symlink target.
+		return $ if S.length s == maxSymlinkSz
+			then mempty
+			else 
+				-- If there are any NUL or newline
+				-- characters, or whitespace, we
+				-- certainly don't have a symlink to a
+				-- git-annex key.
+				if any (`S8.elem` s) ("\0\n\r \t" :: [Char])
+					then mempty
+					else s
+
+makeAnnexLink :: LinkTarget -> RawFilePath -> Annex ()
+makeAnnexLink = makeGitLink
+
+{- Creates a link on disk.
+ -
+ - On a filesystem that does not support symlinks, writes the link target
+ - to a file. Note that git will only treat the file as a symlink if
+ - it's staged as such, so use addAnnexLink when adding a new file or
+ - modified link to git.
+ -}
+makeGitLink :: LinkTarget -> RawFilePath -> Annex ()
+makeGitLink linktarget file = ifM (coreSymlinks <$> Annex.getGitConfig)
+	( liftIO $ do
+		void $ tryIO $ R.removeLink file
+		R.createSymbolicLink linktarget file
+	, liftIO $ S.writeFile (fromRawFilePath file) linktarget
+	)
+
+{- Creates a link on disk, and additionally stages it in git. -}
+addAnnexLink :: LinkTarget -> RawFilePath -> Annex ()
+addAnnexLink linktarget file = do
+	makeAnnexLink linktarget file
+	stageSymlink file =<< hashSymlink linktarget
+
+{- Injects a symlink target into git, returning its Sha. -}
+hashSymlink :: LinkTarget -> Annex Sha
+hashSymlink = hashBlob . toInternalGitPath
+
+{- Stages a symlink to an annexed object, using a Sha of its target. -}
+stageSymlink :: RawFilePath -> Sha -> Annex ()
+stageSymlink file sha =
+	Annex.Queue.addUpdateIndex =<<
+		inRepo (Git.UpdateIndex.stageSymlink file sha)
+
+{- Injects a pointer file content into git, returning its Sha. -}
+hashPointerFile :: Key -> Annex Sha
+hashPointerFile key = hashBlob $ formatPointer key
+
+{- Stages a pointer file, using a Sha of its content -}
+stagePointerFile :: RawFilePath -> Maybe FileMode -> Sha -> Annex ()
+stagePointerFile file mode sha =
+	Annex.Queue.addUpdateIndex =<<
+		inRepo (Git.UpdateIndex.stageFile sha treeitemtype file)
+  where
+	treeitemtype
+		| maybe False isExecutable mode = TreeExecutable
+		| otherwise = TreeFile
+
+writePointerFile :: RawFilePath -> Key -> Maybe FileMode -> IO ()
+writePointerFile file k mode = do
+	S.writeFile (fromRawFilePath file) (formatPointer k)
+	maybe noop (R.setFileMode file) mode
+
+newtype Restage = Restage Bool
+
+{- Restage pointer file. This is used after updating a worktree file
+ - when content is added/removed, to prevent git status from showing
+ - it as modified.
+ -
+ - The InodeCache is for the worktree file. It is used to detect when
+ - the worktree file is changed by something else before git update-index
+ - gets to look at it.
+ -
+ - Asks git to refresh its index information for the file.
+ - That in turn runs the clean filter on the file; when the clean
+ - filter produces the same pointer that was in the index before, git
+ - realizes that the file has not actually been modified.
+ -
+ - Note that, if the pointer file is staged for deletion, or has different
+ - content than the current worktree content staged, this won't change
+ - that. So it's safe to call at any time and any situation.
+ -
+ - If the index is known to be locked (eg, git add has run git-annex),
+ - that would fail. Restage False will prevent the index being updated,
+ - and will store it in the restage log. Displays a message to help the
+ - user understand why the file will appear to be modified.
+ -
+ - This uses the git queue, so the update is not performed immediately,
+ - and this can be run multiple times cheaply. Using the git queue also
+ - prevents building up too large a number of updates when many files
+ - are being processed. It's also recorded in the restage log so that,
+ - if the process is interrupted before the git queue is fulushed, the
+ - restage will be taken care of later.
+ -}
+restagePointerFile :: Restage -> RawFilePath -> InodeCache -> Annex ()
+restagePointerFile (Restage False) f orig = do
+	flip writeRestageLog orig =<< inRepo (toTopFilePath f)
+	toplevelWarning True $ unableToRestage $ Just f
+restagePointerFile (Restage True) f orig = do
+	flip writeRestageLog orig =<< inRepo (toTopFilePath f)
+	-- Avoid refreshing the index if run by the
+	-- smudge clean filter, because git uses that when
+	-- it's already refreshing the index, probably because
+	-- this very action is running. Running it again would likely
+	-- deadlock.
+	unlessM (Annex.getState Annex.insmudgecleanfilter) $
+		Annex.Queue.addFlushAction restagePointerFileRunner [f]
+
+restagePointerFileRunner :: Git.Queue.FlushActionRunner Annex
+restagePointerFileRunner = 
+	Git.Queue.FlushActionRunner "restagePointerFiles" $ \r _fs ->
+		restagePointerFiles r
+
+-- Restage all files in the restage log that have not been modified.
+--
+-- Other changes to the files may have been staged before this
+-- gets a chance to run. To avoid a race with any staging of
+-- changes, first lock the index file. Then run git update-index
+-- on all still-unmodified files, using a copy of the index file,
+-- to bypass the lock. Then replace the old index file with the new
+-- updated index file.
+restagePointerFiles :: Git.Repo -> Annex ()
+restagePointerFiles r = unlessM (Annex.getState Annex.insmudgecleanfilter) $ do
+	-- Flush any queued changes to the keys database, so they
+	-- are visible to child processes.
+	-- The database is closed because that may improve behavior
+	-- when run in Windows's WSL1, which has issues with
+	-- multiple writers to SQL databases.
+	liftIO . Database.Keys.Handle.closeDbHandle
+		=<< Annex.getRead Annex.keysdbhandle
+	realindex <- liftIO $ Git.Index.currentIndexFile r
+	numsz@(numfiles, _) <- calcnumsz
+	let lock = fromRawFilePath (Git.Index.indexFileLock realindex)
+	    lockindex = liftIO $ catchMaybeIO $ Git.LockFile.openLock' lock
+	    unlockindex = liftIO . maybe noop Git.LockFile.closeLock
+	    showwarning = warning $ unableToRestage Nothing
+	    go Nothing = showwarning
+	    go (Just _) = withtmpdir $ \tmpdir -> do
+		tsd <- getTSDelta 
+		let tmpindex = toRawFilePath (tmpdir </> "index")
+		let replaceindex = liftIO $ moveFile tmpindex realindex
+		let updatetmpindex = do
+			r' <- liftIO $ Git.Env.addGitEnv r Git.Index.indexEnv
+				=<< Git.Index.indexEnvVal tmpindex
+			configfilterprocess numsz $
+				runupdateindex tsd r' replaceindex
+			return True
+		ok <- liftIO (createLinkOrCopy realindex tmpindex)
+			<&&> catchBoolIO updatetmpindex
+		unless ok showwarning
+	when (numfiles > 0) $
+		bracket lockindex unlockindex go
+  where
+	withtmpdir = withTmpDirIn (fromRawFilePath $ Git.localGitDir r) "annexindex"
+
+	isunmodified tsd f orig = 
+		genInodeCache f tsd >>= return . \case
+			Nothing -> False
+			Just new -> compareStrong orig new
+			
+	{- Avoid git warning about CRLF munging -}
+	avoidcrlfwarning r' = r' { gitGlobalOpts = gitGlobalOpts r' ++
+		[ Param "-c"
+		, Param $ "core.safecrlf=" ++ boolConfig False
+		] }
+			
+	runupdateindex tsd r' replaceindex = 
+		runsGitAnnexChildProcessViaGit' (avoidcrlfwarning r') $ \r'' ->
+			Git.UpdateIndex.refreshIndex r'' $ \feeder -> do
+				let atend = do
+					-- wait for index write
+					liftIO $ feeder Nothing
+					replaceindex
+				streamRestageLog atend $ \topf ic -> do
+					let f = fromTopFilePath topf r''
+					liftIO $ whenM (isunmodified tsd f ic) $
+						feedupdateindex f feeder
+	
+	{- update-index is documented as picky about "./file" and it
+	 - fails on "../../repo/path/file" when cwd is not in the repo 
+	 - being acted on. Avoid these problems with an absolute path.
+	 -}
+	feedupdateindex f feeder = do
+		absf <- absPath f
+		feeder (Just absf)
+	
+	calcnumsz = calcRestageLog (0, 0) $ \(_f, ic) (numfiles, sizefiles) ->
+		(numfiles+1, sizefiles + inodeCacheFileSize ic)
+
+	{- filter.annex.process configured to use git-annex filter-process
+	 - is sometimes faster and sometimes slower than using
+	 - git-annex smudge. The latter is run once per file, while
+	 - the former has the content of files piped to it.
+	 -}
+	filterprocessfaster :: (Integer, FileSize) -> Bool
+	filterprocessfaster (numfiles, sizefiles) = 
+		let estimate_enabled = sizefiles `div` 191739611
+		    estimate_disabled = numfiles `div` 7
+		in estimate_enabled <= estimate_disabled
+	 
+	 {- This disables filter.annex.process if it's set when it would
+	  - probably not be faster to use it. Unfortunately, simply
+	  - passing -c filter.annex.process= also prevents git from
+	  - running the smudge filter, so .git/config has to be modified
+	  - to disable it. The modification is reversed at the end. In
+	  - case this process is terminated early, the next time this
+	  - runs it will take care of reversing the modification.
+	  -}
+	configfilterprocess numsz = bracket setup cleanup . const
+	  where
+		setup
+			| filterprocessfaster numsz = return Nothing
+			| otherwise = fromRepo (Git.Config.getMaybe ck) >>= \case
+				Nothing -> return Nothing
+				Just v -> do
+					void $ inRepo (Git.Config.change ckd (fromConfigValue v))
+					void $ inRepo (Git.Config.unset ck)
+					return (Just v)
+		cleanup (Just v) = do
+			void $ inRepo $ Git.Config.change ck (fromConfigValue v)
+			void $ inRepo (Git.Config.unset ckd)
+		cleanup Nothing = fromRepo (Git.Config.getMaybe ckd) >>= \case
+			Nothing -> return ()
+			Just v -> do
+				whenM (isNothing <$> fromRepo (Git.Config.getMaybe ck)) $
+					void $ inRepo (Git.Config.change ck (fromConfigValue v))
+				void $ inRepo (Git.Config.unset ckd)
+		ck = ConfigKey "filter.annex.process"
+		ckd = ConfigKey "filter.annex.process-temp-disabled"
+
+unableToRestage :: Maybe RawFilePath -> StringContainingQuotedPath
+unableToRestage mf =
+	"git status will show " <> maybe "some files" QuotedPath mf
+	<> " to be modified, since content availability has changed"
+	<> " and git-annex was unable to update the index."
+	<> " This is only a cosmetic problem affecting git status; git add,"
+	<> " git commit, etc won't be affected."
+	<> " To fix the git status display, you can run:"
+	<> " git-annex restage"
+
+{- Parses a symlink target or a pointer file to a Key.
+ -
+ - Makes sure that the pointer file is valid, including not being longer
+ - than the maximum allowed size of a valid pointer file, and that any
+ - subsequent lines after the first contain the validPointerLineTag.
+ - If a valid pointer file gets some other data appended to it, it should
+ - never be considered valid, unless that data happened to itself be a
+ - valid pointer file.
+ -}
+parseLinkTargetOrPointer :: S.ByteString -> Maybe Key
+parseLinkTargetOrPointer = either (const Nothing) id
+	. parseLinkTargetOrPointer'
+
+data InvalidAppendedPointerFile = InvalidAppendedPointerFile
+
+parseLinkTargetOrPointer' :: S.ByteString -> Either InvalidAppendedPointerFile (Maybe Key)
+parseLinkTargetOrPointer' b = 
+	let (firstline, rest) = S8.span (/= '\n') b
+	in case parsekey $ droptrailing '\r' firstline of
+		Just k
+			| S.length b > maxValidPointerSz -> Left InvalidAppendedPointerFile
+			| restvalid (dropleading '\n' rest) -> Right (Just k)
+			| otherwise -> Left InvalidAppendedPointerFile
+		Nothing -> Right Nothing
+  where
+	parsekey l
+		| isLinkToAnnex l = fileKey $ snd $ S8.breakEnd pathsep l
+		| otherwise = Nothing
+
+	restvalid r
+		| S.null r = True
+		| otherwise = 
+			let (l, r') = S8.span (/= '\n') r
+			in validPointerLineTag `S.isInfixOf` l
+				&& (not (S8.null r') && S8.head r' == '\n')
+				&& restvalid (S8.tail r')
+
+	dropleading c l
+		| S.null l = l
+		| S8.head l == c = S8.tail l
+		| otherwise = l
+	
+	droptrailing c l
+		| S.null l = l
+		| S8.last l == c = S8.init l
+		| otherwise = l
+	
+	pathsep '/' = True
+#ifdef mingw32_HOST_OS
+	pathsep '\\' = True
+#endif
+	pathsep _ = False
+
+{- Avoid looking at more of the lazy ByteString than necessary since it
+ - could be reading from a large file that is not a pointer file. -}
+parseLinkTargetOrPointerLazy :: L.ByteString -> Maybe Key
+parseLinkTargetOrPointerLazy = either (const Nothing) id
+	. parseLinkTargetOrPointerLazy'
+
+parseLinkTargetOrPointerLazy' :: L.ByteString -> Either InvalidAppendedPointerFile (Maybe Key)
+parseLinkTargetOrPointerLazy' b = 
+	let b' = L.take (fromIntegral maxPointerSz) b
+	in parseLinkTargetOrPointer' (L.toStrict b')
+
+formatPointer :: Key -> S.ByteString
+formatPointer k = prefix <> keyFile k <> nl
+  where
+	prefix = toInternalGitPath $ P.pathSeparator `S.cons` objectDir
+	nl = S8.singleton '\n'
+
+{- Maximum size of a file that could be a pointer to a key.
+ - Check to avoid buffering really big files in git into
+ - memory when reading files that may be pointers.
+ -
+ - 8192 bytes is plenty for a pointer to a key. This adds some additional
+ - padding to allow for pointer files that have lines of additional data
+ - after the key.
+ -
+ - One additional byte is used to detect when a valid pointer file
+ - got something else appended to it.
+ -}
+maxPointerSz :: Int
+maxPointerSz = maxValidPointerSz + 1
+
+{- Maximum size of a valid pointer files is 32kb. -}
+maxValidPointerSz :: Int
+maxValidPointerSz = 32768
+
+maxSymlinkSz :: Int
+maxSymlinkSz = 8192
+
+{- Checks if a worktree file is a pointer to a key.
+ -
+ - Unlocked files whose content is present are not detected by this.
+ -
+ - It's possible, though unlikely, that an annex symlink points to
+ - an object that looks like a pointer file. Or that a non-annex
+ - symlink does. Avoids a false positive in those cases.
+ - -}
+isPointerFile :: RawFilePath -> IO (Maybe Key)
+isPointerFile f = catchDefaultIO Nothing $
+#if defined(mingw32_HOST_OS)
+	withFile (fromRawFilePath f) ReadMode readhandle
+#else
+#if MIN_VERSION_unix(2,8,0)
+	let open = do
+		fd <- openFd (fromRawFilePath f) ReadOnly 
+			(defaultFileFlags { nofollow = True })
+		fdToHandle fd
+	in bracket open hClose readhandle
+#else
+	ifM (isSymbolicLink <$> R.getSymbolicLinkStatus f)
+		( return Nothing
+		, withFile (fromRawFilePath f) ReadMode readhandle
+		)
+#endif
+#endif
+  where
+	readhandle h = parseLinkTargetOrPointer <$> S.hGet h maxPointerSz
+
+{- Checks a symlink target or pointer file first line to see if it
+ - appears to point to annexed content.
+ -
+ - We only look for paths inside the .git directory, and not at the .git
+ - directory itself, because GIT_DIR may cause a directory name other
+ - than .git to be used.
+ -}
+isLinkToAnnex :: S.ByteString -> Bool
+isLinkToAnnex s = p `S.isInfixOf` s
+#ifdef mingw32_HOST_OS
+	-- '/' is used inside pointer files on Windows, not the native '\'
+	|| p' `S.isInfixOf` s
+#endif
+  where
+	p = P.pathSeparator `S.cons` objectDir
+#ifdef mingw32_HOST_OS
+	p' = toInternalGitPath p
+#endif
+
+{- String that must appear on every line of a valid pointer file. -}
+validPointerLineTag :: S.ByteString
+validPointerLineTag = "/annex/"
diff --git a/Annex/Locations.hs b/Annex/Locations.hs
new file mode 100644
index 0000000000..28494bed16
--- /dev/null
+++ b/Annex/Locations.hs
@@ -0,0 +1,727 @@
+{- git-annex file locations
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Locations (
+	keyFile,
+	fileKey,
+	keyPaths,
+	keyPath,
+	annexDir,
+	objectDir,
+	gitAnnexLocation,
+	gitAnnexLocation',
+	gitAnnexLocationDepth,
+	gitAnnexLink,
+	gitAnnexLinkCanonical,
+	gitAnnexContentLock,
+	gitAnnexContentLockLock,
+	gitAnnexInodeSentinal,
+	gitAnnexInodeSentinalCache,
+	annexLocationsBare,
+	annexLocationsNonBare,
+	gitAnnexDir,
+	gitAnnexObjectDir,
+	gitAnnexTmpOtherDir,
+	gitAnnexTmpOtherLock,
+	gitAnnexTmpOtherDirOld,
+	gitAnnexTmpWatcherDir,
+	gitAnnexTmpObjectDir,
+	gitAnnexTmpObjectLocation,
+	gitAnnexTmpWorkDir,
+	gitAnnexBadDir,
+	gitAnnexBadLocation,
+	gitAnnexUnusedLog,
+	gitAnnexKeysDbDir,
+	gitAnnexKeysDbLock,
+	gitAnnexKeysDbIndexCache,
+	gitAnnexFsckState,
+	gitAnnexFsckDbDir,
+	gitAnnexFsckDbDirOld,
+	gitAnnexFsckDbLock,
+	gitAnnexFsckResultsLog,
+	gitAnnexUpgradeLog,
+	gitAnnexUpgradeLock,
+	gitAnnexSmudgeLog,
+	gitAnnexSmudgeLock,
+	gitAnnexRestageLog,
+	gitAnnexRestageLogOld,
+	gitAnnexRestageLock,
+	gitAnnexAdjustedBranchUpdateLog,
+	gitAnnexAdjustedBranchUpdateLock,
+	gitAnnexMigrateLog,
+	gitAnnexMigrateLock,
+	gitAnnexMigrationsLog,
+	gitAnnexMigrationsLock,
+	gitAnnexMoveLog,
+	gitAnnexMoveLock,
+	gitAnnexExportDir,
+	gitAnnexExportDbDir,
+	gitAnnexExportLock,
+	gitAnnexExportUpdateLock,
+	gitAnnexExportExcludeLog,
+	gitAnnexImportDir,
+	gitAnnexImportLog,
+	gitAnnexContentIdentifierDbDir,
+	gitAnnexContentIdentifierLock,
+	gitAnnexImportFeedDbDir,
+	gitAnnexImportFeedDbLock,
+	gitAnnexScheduleState,
+	gitAnnexTransferDir,
+	gitAnnexCredsDir,
+	gitAnnexWebCertificate,
+	gitAnnexWebPrivKey,
+	gitAnnexFeedStateDir,
+	gitAnnexFeedState,
+	gitAnnexMergeDir,
+	gitAnnexJournalDir,
+	gitAnnexPrivateJournalDir,
+	gitAnnexJournalLock,
+	gitAnnexGitQueueLock,
+	gitAnnexIndex,
+	gitAnnexPrivateIndex,
+	gitAnnexIndexStatus,
+	gitAnnexViewIndex,
+	gitAnnexViewLog,
+	gitAnnexMergedRefs,
+	gitAnnexIgnoredRefs,
+	gitAnnexPidFile,
+	gitAnnexPidLockFile,
+	gitAnnexDaemonStatusFile,
+	gitAnnexDaemonLogFile,
+	gitAnnexFuzzTestLogFile,
+	gitAnnexHtmlShim,
+	gitAnnexUrlFile,
+	gitAnnexTmpCfgFile,
+	gitAnnexSshDir,
+	gitAnnexRemotesDir,
+	gitAnnexAssistantDefaultDir,
+	HashLevels(..),
+	hashDirMixed,
+	hashDirLower,
+	preSanitizeKeyName,
+	reSanitizeKeyName,
+) where
+
+import Data.Char
+import Data.Default
+import qualified Data.ByteString.Char8 as S8
+import qualified System.FilePath.ByteString as P
+
+import Common
+import Key
+import Types.UUID
+import Types.GitConfig
+import Types.Difference
+import qualified Git
+import qualified Git.Types as Git
+import Git.FilePath
+import Annex.DirHashes
+import Annex.Fixup
+import qualified Utility.RawFilePath as R
+
+{- Conventions:
+ -
+ - Functions ending in "Dir" should always return values ending with a
+ - trailing path separator. Most code does not rely on that, but a few
+ - things do. 
+ -
+ - Everything else should not end in a trailing path sepatator. 
+ -
+ - Only functions (with names starting with "git") that build a path
+ - based on a git repository should return full path relative to the git
+ - repository. Everything else returns path segments.
+ -}
+
+{- The directory git annex uses for local state, relative to the .git
+ - directory -}
+annexDir :: RawFilePath
+annexDir = P.addTrailingPathSeparator "annex"
+
+{- The directory git annex uses for locally available object content,
+ - relative to the .git directory -}
+objectDir :: RawFilePath
+objectDir = P.addTrailingPathSeparator $ annexDir P.</> "objects"
+
+{- Annexed file's possible locations relative to the .git directory
+ - in a non-bare repository.
+ -
+ - Normally it is hashDirMixed. However, it's always possible that a
+ - bare repository was converted to non-bare, or that the cripped
+ - filesystem setting changed, so still need to check both. -}
+annexLocationsNonBare :: GitConfig -> Key -> [RawFilePath]
+annexLocationsNonBare config key = 
+	map (annexLocation config key) [hashDirMixed, hashDirLower]
+
+{- Annexed file's possible locations relative to a bare repository. -}
+annexLocationsBare :: GitConfig -> Key -> [RawFilePath]
+annexLocationsBare config key = 
+	map (annexLocation config key) [hashDirLower, hashDirMixed]
+
+annexLocation :: GitConfig -> Key -> (HashLevels -> Hasher) -> RawFilePath
+annexLocation config key hasher = objectDir P.</> keyPath key (hasher $ objectHashLevels config)
+
+{- Number of subdirectories from the gitAnnexObjectDir
+ - to the gitAnnexLocation. -}
+gitAnnexLocationDepth :: GitConfig -> Int
+gitAnnexLocationDepth config = hashlevels + 1
+  where
+	HashLevels hashlevels = objectHashLevels config
+
+{- Annexed object's location in a repository.
+ -
+ - When there are multiple possible locations, returns the one where the
+ - file is actually present.
+ -
+ - When the file is not present, returns the location where the file should
+ - be stored.
+ -}
+gitAnnexLocation :: Key -> Git.Repo -> GitConfig -> IO RawFilePath
+gitAnnexLocation = gitAnnexLocation' R.doesPathExist
+
+gitAnnexLocation' :: (RawFilePath -> IO Bool) -> Key -> Git.Repo -> GitConfig -> IO RawFilePath
+gitAnnexLocation' checker key r config = gitAnnexLocation'' key r config
+	(annexCrippledFileSystem config)
+	(coreSymlinks config)
+	checker
+	(Git.localGitDir r)
+
+gitAnnexLocation'' :: Key -> Git.Repo -> GitConfig -> Bool -> Bool -> (RawFilePath -> IO Bool) -> RawFilePath -> IO RawFilePath
+gitAnnexLocation'' key r config crippled symlinkssupported checker gitdir
+	{- Bare repositories default to hashDirLower for new
+	 - content, as it's more portable. But check all locations. -}
+	| Git.repoIsLocalBare r = checkall annexLocationsBare
+	{- If the repository is configured to only use lower, no need
+	 - to check both. -}
+	| hasDifference ObjectHashLower (annexDifferences config) = 
+		only hashDirLower
+	{- Repositories on crippled filesystems use same layout as bare
+	 - repos for new content, unless symlinks are supported too. -}
+	| crippled = if symlinkssupported
+		then checkall annexLocationsNonBare
+		else checkall annexLocationsBare
+	| otherwise = checkall annexLocationsNonBare
+  where
+	only = return . inrepo . annexLocation config key
+	checkall f = check $ map inrepo $ f config key
+
+	inrepo d = gitdir P.</> d
+	check locs@(l:_) = fromMaybe l <$> firstM checker locs
+	check [] = error "internal"
+
+{- Calculates a symlink target to link a file to an annexed object. -}
+gitAnnexLink :: RawFilePath -> Key -> Git.Repo -> GitConfig -> IO RawFilePath
+gitAnnexLink file key r config = do
+	currdir <- R.getCurrentDirectory
+	let absfile = absNormPathUnix currdir file
+	let gitdir = getgitdir currdir
+	loc <- gitAnnexLocation'' key r config False False (\_ -> return True) gitdir
+	toInternalGitPath <$> relPathDirToFile (parentDir absfile) loc
+  where
+	getgitdir currdir
+		{- This special case is for git submodules on filesystems not
+		 - supporting symlinks; generate link target that will
+		 - work portably. -}
+		| not (coreSymlinks config) && needsSubmoduleFixup r =
+			absNormPathUnix currdir (Git.repoPath r P.</> ".git")
+		| otherwise = Git.localGitDir r
+	absNormPathUnix d p = toInternalGitPath $
+		absPathFrom (toInternalGitPath d) (toInternalGitPath p)
+
+{- Calculates a symlink target as would be used in a typical git
+ - repository, with .git in the top of the work tree. -}
+gitAnnexLinkCanonical :: RawFilePath -> Key -> Git.Repo -> GitConfig -> IO RawFilePath
+gitAnnexLinkCanonical file key r config = gitAnnexLink file key r' config'
+  where
+	r' = case r of
+		Git.Repo { Git.location = l@Git.Local { Git.worktree = Just wt } } ->
+			r { Git.location = l { Git.gitdir = wt P.</> ".git" } }
+		_ -> r
+	config' = config
+		{ annexCrippledFileSystem = False
+		, coreSymlinks = True
+		}
+
+{- File used to lock a key's content. -}
+gitAnnexContentLock :: Key -> Git.Repo -> GitConfig -> IO RawFilePath
+gitAnnexContentLock key r config = do
+	loc <- gitAnnexLocation key r config
+	return $ loc <> ".lck"
+
+{- Lock that is held when taking the gitAnnexContentLock to support the v10
+ - upgrade.
+ -
+ - This uses the gitAnnexInodeSentinal file, because it needs to be a file
+ - that exists in the repository, even when it's an old v8 repository that
+ - is mounted read-only. The gitAnnexInodeSentinal is created by git-annex
+ - init, so should already exist.
+ -}
+gitAnnexContentLockLock :: Git.Repo -> RawFilePath
+gitAnnexContentLockLock = gitAnnexInodeSentinal
+
+gitAnnexInodeSentinal :: Git.Repo -> RawFilePath
+gitAnnexInodeSentinal r = gitAnnexDir r P.</> "sentinal"
+
+gitAnnexInodeSentinalCache :: Git.Repo -> RawFilePath
+gitAnnexInodeSentinalCache r = gitAnnexInodeSentinal r <> ".cache"
+
+{- The annex directory of a repository. -}
+gitAnnexDir :: Git.Repo -> RawFilePath
+gitAnnexDir r = P.addTrailingPathSeparator $ Git.localGitDir r P.</> annexDir
+
+{- The part of the annex directory where file contents are stored. -}
+gitAnnexObjectDir :: Git.Repo -> RawFilePath
+gitAnnexObjectDir r = P.addTrailingPathSeparator $
+	Git.localGitDir r P.</> objectDir
+
+{- .git/annex/tmp/ is used for temp files for key's contents -}
+gitAnnexTmpObjectDir :: Git.Repo -> RawFilePath
+gitAnnexTmpObjectDir r = P.addTrailingPathSeparator $
+	gitAnnexDir r P.</> "tmp"
+
+{- .git/annex/othertmp/ is used for other temp files -}
+gitAnnexTmpOtherDir :: Git.Repo -> RawFilePath
+gitAnnexTmpOtherDir r = P.addTrailingPathSeparator $
+	gitAnnexDir r P.</> "othertmp"
+
+{- Lock file for gitAnnexTmpOtherDir. -}
+gitAnnexTmpOtherLock :: Git.Repo -> RawFilePath
+gitAnnexTmpOtherLock r = gitAnnexDir r P.</> "othertmp.lck"
+
+{- .git/annex/misctmp/ was used by old versions of git-annex and is still
+ - used during initialization -}
+gitAnnexTmpOtherDirOld :: Git.Repo -> RawFilePath
+gitAnnexTmpOtherDirOld r = P.addTrailingPathSeparator $ 
+	gitAnnexDir r P.</> "misctmp"
+
+{- .git/annex/watchtmp/ is used by the watcher and assistant -}
+gitAnnexTmpWatcherDir :: Git.Repo -> RawFilePath
+gitAnnexTmpWatcherDir r = P.addTrailingPathSeparator $
+	gitAnnexDir r P.</> "watchtmp"
+
+{- The temp file to use for a given key's content. -}
+gitAnnexTmpObjectLocation :: Key -> Git.Repo -> RawFilePath
+gitAnnexTmpObjectLocation key r = gitAnnexTmpObjectDir r P.</> keyFile key
+
+{- Given a temp file such as gitAnnexTmpObjectLocation, makes a name for a
+ - subdirectory in the same location, that can be used as a work area
+ - when receiving the key's content.
+ -
+ - There are ordering requirements for creating these directories;
+ - use Annex.Content.withTmpWorkDir to set them up.
+ -}
+gitAnnexTmpWorkDir :: RawFilePath -> RawFilePath
+gitAnnexTmpWorkDir p =
+	let (dir, f) = P.splitFileName p
+	-- Using a prefix avoids name conflict with any other keys.
+	in dir P.</> "work." <> f
+
+{- .git/annex/bad/ is used for bad files found during fsck -}
+gitAnnexBadDir :: Git.Repo -> RawFilePath
+gitAnnexBadDir r = P.addTrailingPathSeparator $ gitAnnexDir r P.</> "bad"
+
+{- The bad file to use for a given key. -}
+gitAnnexBadLocation :: Key -> Git.Repo -> RawFilePath
+gitAnnexBadLocation key r = gitAnnexBadDir r P.</> keyFile key
+
+{- .git/annex/foounused is used to number possibly unused keys -}
+gitAnnexUnusedLog :: RawFilePath -> Git.Repo -> RawFilePath
+gitAnnexUnusedLog prefix r = gitAnnexDir r P.</> (prefix <> "unused")
+
+{- .git/annex/keysdb/ contains a database of information about keys. -}
+gitAnnexKeysDbDir :: Git.Repo -> GitConfig -> RawFilePath
+gitAnnexKeysDbDir r c = fromMaybe (gitAnnexDir r) (annexDbDir c) P.</> "keysdb"
+
+{- Lock file for the keys database. -}
+gitAnnexKeysDbLock :: Git.Repo -> GitConfig -> RawFilePath
+gitAnnexKeysDbLock r c = gitAnnexKeysDbDir r c <> ".lck"
+
+{- Contains the stat of the last index file that was
+ - reconciled with the keys database. -}
+gitAnnexKeysDbIndexCache :: Git.Repo -> GitConfig -> RawFilePath
+gitAnnexKeysDbIndexCache r c = gitAnnexKeysDbDir r c <> ".cache"
+
+{- .git/annex/fsck/uuid/ is used to store information about incremental
+ - fscks. -}
+gitAnnexFsckDir :: UUID -> Git.Repo -> Maybe GitConfig -> RawFilePath
+gitAnnexFsckDir u r mc = case annexDbDir =<< mc of
+	Nothing -> go (gitAnnexDir r)
+	Just d -> go d
+  where
+	go d = d P.</> "fsck" P.</> fromUUID u
+
+{- used to store information about incremental fscks. -}
+gitAnnexFsckState :: UUID -> Git.Repo -> RawFilePath
+gitAnnexFsckState u r = gitAnnexFsckDir u r Nothing P.</> "state"
+
+{- Directory containing database used to record fsck info. -}
+gitAnnexFsckDbDir :: UUID -> Git.Repo -> GitConfig -> RawFilePath
+gitAnnexFsckDbDir u r c = gitAnnexFsckDir u r (Just c) P.</> "fsckdb"
+
+{- Directory containing old database used to record fsck info. -}
+gitAnnexFsckDbDirOld :: UUID -> Git.Repo -> GitConfig -> RawFilePath
+gitAnnexFsckDbDirOld u r c = gitAnnexFsckDir u r (Just c) P.</> "db"
+
+{- Lock file for the fsck database. -}
+gitAnnexFsckDbLock :: UUID -> Git.Repo -> GitConfig -> RawFilePath
+gitAnnexFsckDbLock u r c = gitAnnexFsckDir u r (Just c) P.</> "fsck.lck"
+
+{- .git/annex/fsckresults/uuid is used to store results of git fscks -}
+gitAnnexFsckResultsLog :: UUID -> Git.Repo -> RawFilePath
+gitAnnexFsckResultsLog u r = 
+	gitAnnexDir r P.</> "fsckresults" P.</> fromUUID u
+
+{- .git/annex/upgrade.log is used to record repository version upgrades. -}
+gitAnnexUpgradeLog :: Git.Repo -> RawFilePath
+gitAnnexUpgradeLog r = gitAnnexDir r P.</> "upgrade.log"
+
+gitAnnexUpgradeLock :: Git.Repo -> RawFilePath
+gitAnnexUpgradeLock r = gitAnnexDir r P.</> "upgrade.lck"
+
+{- .git/annex/smudge.log is used to log smudged worktree files that need to
+ - be updated. -}
+gitAnnexSmudgeLog :: Git.Repo -> RawFilePath
+gitAnnexSmudgeLog r = gitAnnexDir r P.</> "smudge.log"
+
+gitAnnexSmudgeLock :: Git.Repo -> RawFilePath
+gitAnnexSmudgeLock r = gitAnnexDir r P.</> "smudge.lck"
+
+{- .git/annex/restage.log is used to log worktree files that need to be
+ - restaged in git -}
+gitAnnexRestageLog :: Git.Repo -> RawFilePath
+gitAnnexRestageLog r = gitAnnexDir r P.</> "restage.log"
+
+{- .git/annex/restage.old is used while restaging files in git -}
+gitAnnexRestageLogOld :: Git.Repo -> RawFilePath
+gitAnnexRestageLogOld r = gitAnnexDir r P.</> "restage.old"
+
+gitAnnexRestageLock :: Git.Repo -> RawFilePath
+gitAnnexRestageLock r = gitAnnexDir r P.</> "restage.lck"
+
+{- .git/annex/adjust.log is used to log when the adjusted branch needs to
+ - be updated. -}
+gitAnnexAdjustedBranchUpdateLog :: Git.Repo -> RawFilePath
+gitAnnexAdjustedBranchUpdateLog r = gitAnnexDir r P.</> "adjust.log"
+
+gitAnnexAdjustedBranchUpdateLock :: Git.Repo -> RawFilePath
+gitAnnexAdjustedBranchUpdateLock r = gitAnnexDir r P.</> "adjust.lck"
+
+{- .git/annex/migrate.log is used to log migrations before committing them. -}
+gitAnnexMigrateLog :: Git.Repo -> RawFilePath
+gitAnnexMigrateLog r = gitAnnexDir r P.</> "migrate.log"
+
+gitAnnexMigrateLock :: Git.Repo -> RawFilePath
+gitAnnexMigrateLock r = gitAnnexDir r P.</> "migrate.lck"
+
+{- .git/annex/migrations.log is used to log committed migrations. -}
+gitAnnexMigrationsLog :: Git.Repo -> RawFilePath
+gitAnnexMigrationsLog r = gitAnnexDir r P.</> "migrations.log"
+
+gitAnnexMigrationsLock :: Git.Repo -> RawFilePath
+gitAnnexMigrationsLock r = gitAnnexDir r P.</> "migrations.lck"
+
+{- .git/annex/move.log is used to log moves that are in progress,
+ - to better support resuming an interrupted move. -}
+gitAnnexMoveLog :: Git.Repo -> RawFilePath
+gitAnnexMoveLog r = gitAnnexDir r P.</> "move.log"
+
+gitAnnexMoveLock :: Git.Repo -> RawFilePath
+gitAnnexMoveLock r = gitAnnexDir r P.</> "move.lck"
+
+{- .git/annex/export/ is used to store information about
+ - exports to special remotes. -}
+gitAnnexExportDir :: Git.Repo -> GitConfig -> RawFilePath
+gitAnnexExportDir r c = fromMaybe (gitAnnexDir r) (annexDbDir c) P.</> "export"
+
+{- Directory containing database used to record export info. -}
+gitAnnexExportDbDir :: UUID -> Git.Repo -> GitConfig -> RawFilePath
+gitAnnexExportDbDir u r c = 
+	gitAnnexExportDir r c P.</> fromUUID u P.</> "exportdb"
+
+{- Lock file for export database. -}
+gitAnnexExportLock :: UUID -> Git.Repo -> GitConfig -> RawFilePath
+gitAnnexExportLock u r c = gitAnnexExportDbDir u r c <> ".lck"
+
+{- Lock file for updating the export database with information from the
+ - repository. -}
+gitAnnexExportUpdateLock :: UUID -> Git.Repo -> GitConfig -> RawFilePath
+gitAnnexExportUpdateLock u r c = gitAnnexExportDbDir u r c <> ".upl"
+
+{- Log file used to keep track of files that were in the tree exported to a
+ - remote, but were excluded by its preferred content settings. -}
+gitAnnexExportExcludeLog :: UUID -> Git.Repo -> RawFilePath
+gitAnnexExportExcludeLog u r = gitAnnexDir r P.</> "export.ex" P.</> fromUUID u
+
+{- Directory containing database used to record remote content ids.
+ -
+ - (This used to be "cid", but a problem with the database caused it to
+ - need to be rebuilt with a new name.)
+ -}
+gitAnnexContentIdentifierDbDir :: Git.Repo -> GitConfig -> RawFilePath
+gitAnnexContentIdentifierDbDir r c =
+	fromMaybe (gitAnnexDir r) (annexDbDir c) P.</> "cidsdb"
+
+{- Lock file for writing to the content id database. -}
+gitAnnexContentIdentifierLock :: Git.Repo -> GitConfig -> RawFilePath
+gitAnnexContentIdentifierLock r c = gitAnnexContentIdentifierDbDir r c <> ".lck"
+
+{- .git/annex/import/ is used to store information about
+ - imports from special remotes. -}
+gitAnnexImportDir :: Git.Repo -> GitConfig -> RawFilePath
+gitAnnexImportDir r c = fromMaybe (gitAnnexDir r) (annexDbDir c) P.</> "import"
+
+{- File containing state about the last import done from a remote. -}
+gitAnnexImportLog :: UUID -> Git.Repo -> GitConfig -> RawFilePath
+gitAnnexImportLog u r c = 
+	gitAnnexImportDir r c P.</> fromUUID u P.</> "log"
+
+{- Directory containing database used by importfeed. -}
+gitAnnexImportFeedDbDir :: Git.Repo -> GitConfig -> RawFilePath
+gitAnnexImportFeedDbDir r c =
+	fromMaybe (gitAnnexDir r) (annexDbDir c) P.</> "importfeed"
+
+{- Lock file for writing to the importfeed database. -}
+gitAnnexImportFeedDbLock :: Git.Repo -> GitConfig -> RawFilePath
+gitAnnexImportFeedDbLock r c = gitAnnexImportFeedDbDir r c <> ".lck"
+
+{- .git/annex/schedulestate is used to store information about when
+ - scheduled jobs were last run. -}
+gitAnnexScheduleState :: Git.Repo -> RawFilePath
+gitAnnexScheduleState r = gitAnnexDir r P.</> "schedulestate"
+
+{- .git/annex/creds/ is used to store credentials to access some special
+ - remotes. -}
+gitAnnexCredsDir :: Git.Repo -> RawFilePath
+gitAnnexCredsDir r = P.addTrailingPathSeparator $ gitAnnexDir r P.</> "creds"
+
+{- .git/annex/certificate.pem and .git/annex/key.pem are used by the webapp
+ - when HTTPS is enabled -}
+gitAnnexWebCertificate :: Git.Repo -> FilePath
+gitAnnexWebCertificate r = fromRawFilePath $ gitAnnexDir r P.</> "certificate.pem"
+gitAnnexWebPrivKey :: Git.Repo -> FilePath
+gitAnnexWebPrivKey r = fromRawFilePath $ gitAnnexDir r P.</> "privkey.pem"
+
+{- .git/annex/feeds/ is used to record per-key (url) state by importfeed -}
+gitAnnexFeedStateDir :: Git.Repo -> RawFilePath
+gitAnnexFeedStateDir r = P.addTrailingPathSeparator $
+	gitAnnexDir r P.</> "feedstate"
+
+gitAnnexFeedState :: Key -> Git.Repo -> RawFilePath
+gitAnnexFeedState k r = gitAnnexFeedStateDir r P.</> keyFile k
+
+{- .git/annex/merge/ is used as a empty work tree for merges in 
+ - adjusted branches. -}
+gitAnnexMergeDir :: Git.Repo -> FilePath
+gitAnnexMergeDir r = fromRawFilePath $
+	P.addTrailingPathSeparator $ gitAnnexDir r P.</> "merge"
+
+{- .git/annex/transfer/ is used to record keys currently
+ - being transferred, and other transfer bookkeeping info. -}
+gitAnnexTransferDir :: Git.Repo -> RawFilePath
+gitAnnexTransferDir r =
+	P.addTrailingPathSeparator $ gitAnnexDir r P.</> "transfer"
+
+{- .git/annex/journal/ is used to journal changes made to the git-annex
+ - branch -}
+gitAnnexJournalDir :: Git.Repo -> RawFilePath
+gitAnnexJournalDir r = 
+	P.addTrailingPathSeparator $ gitAnnexDir r P.</> "journal"
+
+{- .git/annex/journal.private/ is used to journal changes regarding private
+ - repositories. -}
+gitAnnexPrivateJournalDir :: Git.Repo -> RawFilePath
+gitAnnexPrivateJournalDir r = 
+	P.addTrailingPathSeparator $ gitAnnexDir r P.</> "journal-private"
+
+{- Lock file for the journal. -}
+gitAnnexJournalLock :: Git.Repo -> RawFilePath
+gitAnnexJournalLock r = gitAnnexDir r P.</> "journal.lck"
+
+{- Lock file for flushing a git queue that writes to the git index or
+ - other git state that should only have one writer at a time. -}
+gitAnnexGitQueueLock :: Git.Repo -> RawFilePath
+gitAnnexGitQueueLock r = gitAnnexDir r P.</> "gitqueue.lck"
+
+{- .git/annex/index is used to stage changes to the git-annex branch -}
+gitAnnexIndex :: Git.Repo -> RawFilePath
+gitAnnexIndex r = gitAnnexDir r P.</> "index"
+
+{- .git/annex/index-private is used to store information that is not to
+ - be exposed to the git-annex branch. -}
+gitAnnexPrivateIndex :: Git.Repo -> RawFilePath
+gitAnnexPrivateIndex r = gitAnnexDir r P.</> "index-private"
+
+{- Holds the ref of the git-annex branch that the index was last updated to.
+ -
+ - The .lck in the name is a historical accident; this is not used as a
+ - lock. -}
+gitAnnexIndexStatus :: Git.Repo -> RawFilePath
+gitAnnexIndexStatus r = gitAnnexDir r P.</> "index.lck"
+
+{- The index file used to generate a filtered branch view._-}
+gitAnnexViewIndex :: Git.Repo -> RawFilePath
+gitAnnexViewIndex r = gitAnnexDir r P.</> "viewindex"
+
+{- File containing a log of recently accessed views. -}
+gitAnnexViewLog :: Git.Repo -> RawFilePath
+gitAnnexViewLog r = gitAnnexDir r P.</> "viewlog"
+
+{- List of refs that have already been merged into the git-annex branch. -}
+gitAnnexMergedRefs :: Git.Repo -> RawFilePath
+gitAnnexMergedRefs r = gitAnnexDir r P.</> "mergedrefs"
+
+{- List of refs that should not be merged into the git-annex branch. -}
+gitAnnexIgnoredRefs :: Git.Repo -> RawFilePath
+gitAnnexIgnoredRefs r = gitAnnexDir r P.</> "ignoredrefs"
+
+{- Pid file for daemon mode. -}
+gitAnnexPidFile :: Git.Repo -> RawFilePath
+gitAnnexPidFile r = gitAnnexDir r P.</> "daemon.pid"
+
+{- Pid lock file for pidlock mode -}
+gitAnnexPidLockFile :: Git.Repo -> RawFilePath
+gitAnnexPidLockFile r = gitAnnexDir r P.</> "pidlock"
+
+{- Status file for daemon mode. -}
+gitAnnexDaemonStatusFile :: Git.Repo -> FilePath
+gitAnnexDaemonStatusFile r = fromRawFilePath $
+	gitAnnexDir r P.</> "daemon.status"
+
+{- Log file for daemon mode. -}
+gitAnnexDaemonLogFile :: Git.Repo -> RawFilePath
+gitAnnexDaemonLogFile r = gitAnnexDir r P.</> "daemon.log"
+
+{- Log file for fuzz test. -}
+gitAnnexFuzzTestLogFile :: Git.Repo -> FilePath
+gitAnnexFuzzTestLogFile r = fromRawFilePath $
+	gitAnnexDir r P.</> "fuzztest.log"
+
+{- Html shim file used to launch the webapp. -}
+gitAnnexHtmlShim :: Git.Repo -> RawFilePath
+gitAnnexHtmlShim r = gitAnnexDir r P.</> "webapp.html"
+
+{- File containing the url to the webapp. -}
+gitAnnexUrlFile :: Git.Repo -> RawFilePath
+gitAnnexUrlFile r = gitAnnexDir r P.</> "url"
+
+{- Temporary file used to edit configuriation from the git-annex branch. -}
+gitAnnexTmpCfgFile :: Git.Repo -> RawFilePath
+gitAnnexTmpCfgFile r = gitAnnexDir r P.</> "config.tmp"
+
+{- .git/annex/ssh/ is used for ssh connection caching -}
+gitAnnexSshDir :: Git.Repo -> RawFilePath
+gitAnnexSshDir r = P.addTrailingPathSeparator $ gitAnnexDir r P.</> "ssh"
+
+{- .git/annex/remotes/ is used for remote-specific state. -}
+gitAnnexRemotesDir :: Git.Repo -> RawFilePath
+gitAnnexRemotesDir r =
+	P.addTrailingPathSeparator $ gitAnnexDir r P.</> "remotes"
+
+{- This is the base directory name used by the assistant when making
+ - repositories, by default. -}
+gitAnnexAssistantDefaultDir :: FilePath
+gitAnnexAssistantDefaultDir = "annex"
+
+{- Sanitizes a String that will be used as part of a Key's keyName,
+ - dealing with characters that cause problems.
+ -
+ - This is used when a new Key is initially being generated, eg by genKey.
+ - Unlike keyFile and fileKey, it does not need to be a reversible
+ - escaping. Also, it's ok to change this to add more problematic
+ - characters later. Unlike changing keyFile, which could result in the
+ - filenames used for existing keys changing and contents getting lost.
+ -
+ - It is, however, important that the input and output of this function
+ - have a 1:1 mapping, to avoid two different inputs from mapping to the
+ - same key.
+ -}
+preSanitizeKeyName :: String -> String
+preSanitizeKeyName = preSanitizeKeyName' False
+
+preSanitizeKeyName' :: Bool -> String -> String
+preSanitizeKeyName' resanitize = concatMap escape
+  where
+	escape c
+		| isAsciiUpper c || isAsciiLower c || isDigit c = [c]
+		| c `elem` ['.', '-', '_'] = [c] -- common, assumed safe
+		| c `elem` ['/', '%', ':'] = [c] -- handled by keyFile
+		-- , is safe and uncommon, so will be used to escape
+		-- other characters. By itself, it is escaped to 
+		-- doubled form.
+		| c == ',' = if not resanitize
+			then ",,"
+			else ","
+		| otherwise = ',' : show (ord c)
+
+{- Converts a keyName that has been santizied with an old version of
+ - preSanitizeKeyName to be sanitized with the new version. -}
+reSanitizeKeyName :: String -> String
+reSanitizeKeyName = preSanitizeKeyName' True
+
+{- Converts a key into a filename fragment without any directory.
+ -
+ - Escape "/" in the key name, to keep a flat tree of files and avoid
+ - issues with keys containing "/../" or ending with "/" etc. 
+ -
+ - "/" is escaped to "%" because it's short and rarely used, and resembles
+ -     a slash
+ - "%" is escaped to "&s", and "&" to "&a"; this ensures that the mapping
+ -     is one to one.
+ - ":" is escaped to "&c", because it seemed like a good idea at the time.
+ -
+ - Changing what this function escapes and how is not a good idea, as it
+ - can cause existing objects to get lost.
+ -}
+keyFile :: Key -> RawFilePath
+keyFile k = 
+	let b = serializeKey' k
+	in if S8.any (`elem` ['&', '%', ':', '/']) b
+		then S8.concatMap esc b
+		else b
+  where
+	esc '&' = "&a"
+	esc '%' = "&s"
+	esc ':' = "&c"
+	esc '/' = "%"
+	esc c = S8.singleton c
+
+{- Reverses keyFile, converting a filename fragment (ie, the basename of
+ - the symlink target) into a key. -}
+fileKey :: RawFilePath -> Maybe Key
+fileKey = deserializeKey' . S8.intercalate "/" . map go . S8.split '%'
+  where
+	go = S8.concat . unescafterfirst . S8.split '&'
+	unescafterfirst [] = []
+	unescafterfirst (b:bs) = b : map (unesc . S8.uncons) bs
+	unesc :: Maybe (Char, S8.ByteString) -> S8.ByteString
+	unesc Nothing = mempty
+	unesc (Just ('c', b)) = S8.cons ':' b
+	unesc (Just ('s', b)) = S8.cons '%' b
+	unesc (Just ('a', b)) = S8.cons '&' b
+	unesc (Just (c, b)) = S8.cons c b
+
+{- A location to store a key on a special remote that uses a filesystem.
+ - A directory hash is used, to protect against filesystems that dislike
+ - having many items in a single directory.
+ -
+ - The file is put in a directory with the same name, this allows
+ - write-protecting the directory to avoid accidental deletion of the file.
+ -}
+keyPath :: Key -> Hasher -> RawFilePath
+keyPath key hasher = hasher key P.</> f P.</> f
+  where
+	f = keyFile key
+
+{- All possible locations to store a key in a special remote
+ - using different directory hashes.
+ -
+ - This is compatible with the annexLocationsNonBare and annexLocationsBare,
+ - for interoperability between special remotes and git-annex repos.
+ -}
+keyPaths :: Key -> [RawFilePath]
+keyPaths key = map (\h -> keyPath key (h def)) dirHashes
diff --git a/Annex/LockFile.hs b/Annex/LockFile.hs
new file mode 100644
index 0000000000..71a07e677c
--- /dev/null
+++ b/Annex/LockFile.hs
@@ -0,0 +1,113 @@
+{- git-annex lock files.
+ -
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Annex.LockFile (
+	lockFileCached,
+	unlockFile,
+	getLockCache,
+	fromLockCache,
+	withSharedLock,
+	withExclusiveLock,
+	takeExclusiveLock,
+	tryExclusiveLock,
+) where
+
+import Annex.Common
+import Annex
+import Types.LockCache
+import Annex.Perms
+import Annex.LockPool
+
+import qualified Data.Map as M
+import qualified System.FilePath.ByteString as P
+
+{- Create a specified lock file, and takes a shared lock, which is retained
+ - in the cache. -}
+lockFileCached :: RawFilePath -> Annex ()
+lockFileCached file = go =<< fromLockCache file
+  where
+	go (Just _) = noop -- already locked
+	go Nothing = do
+#ifndef mingw32_HOST_OS
+		mode <- annexFileMode
+		lockhandle <- lockShared (Just mode) file
+#else
+		lockhandle <- liftIO $ waitToLock $ lockShared file
+#endif
+		changeLockCache $ M.insert file lockhandle
+
+unlockFile :: RawFilePath -> Annex ()
+unlockFile file = maybe noop go =<< fromLockCache file
+  where
+	go lockhandle = do
+		liftIO $ dropLock lockhandle
+		changeLockCache $ M.delete file
+
+getLockCache :: Annex LockCache
+getLockCache = getState lockcache
+
+fromLockCache :: RawFilePath -> Annex (Maybe LockHandle)
+fromLockCache file = M.lookup file <$> getLockCache
+
+changeLockCache :: (LockCache -> LockCache) -> Annex ()
+changeLockCache a = do
+	m <- getLockCache
+	changeState $ \s -> s { lockcache = a m }
+
+{- Runs an action with a shared lock held. If an exclusive lock is held,
+ - blocks until it becomes free. -}
+withSharedLock :: RawFilePath -> Annex a -> Annex a
+withSharedLock lockfile a = debugLocks $ do
+	createAnnexDirectory $ P.takeDirectory lockfile
+	mode <- annexFileMode
+	bracket (lock mode lockfile) (liftIO . dropLock) (const a)
+  where
+#ifndef mingw32_HOST_OS
+	lock mode = lockShared (Just mode)
+#else
+	lock _mode = liftIO . waitToLock . lockShared
+#endif
+
+{- Runs an action with an exclusive lock held. If the lock is already
+ - held, blocks until it becomes free. -}
+withExclusiveLock :: RawFilePath -> Annex a -> Annex a
+withExclusiveLock lockfile a = bracket
+	(takeExclusiveLock lockfile)
+	(liftIO . dropLock)
+	(const a)
+
+{- Takes an exclusive lock, blocking until it's free. -}
+takeExclusiveLock :: RawFilePath -> Annex LockHandle
+takeExclusiveLock lockfile = debugLocks $ do
+	createAnnexDirectory $ P.takeDirectory lockfile
+	mode <- annexFileMode
+	lock mode lockfile
+  where
+#ifndef mingw32_HOST_OS
+	lock mode = lockExclusive (Just mode)
+#else
+	lock _mode = liftIO . waitToLock . lockExclusive
+#endif
+
+{- Tries to take an exclusive lock and run an action. If the lock is
+ - already held, returns Nothing. -}
+tryExclusiveLock :: RawFilePath -> Annex a -> Annex (Maybe a)
+tryExclusiveLock lockfile a = debugLocks $ do
+	createAnnexDirectory $ P.takeDirectory lockfile
+	mode <- annexFileMode
+	bracket (lock mode lockfile) (liftIO . unlock) go
+  where
+#ifndef mingw32_HOST_OS
+	lock mode = tryLockExclusive (Just mode)
+#else
+	lock _mode = liftIO . lockExclusive
+#endif
+	unlock = maybe noop dropLock
+	go Nothing = return Nothing
+	go (Just _) = Just <$> a
diff --git a/Annex/LockPool.hs b/Annex/LockPool.hs
new file mode 100644
index 0000000000..33df3b611e
--- /dev/null
+++ b/Annex/LockPool.hs
@@ -0,0 +1,17 @@
+{- Wraps Utility.LockPool, making pid locks be used when git-annex is so
+ - configured.
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Annex.LockPool (module X) where
+
+#ifndef mingw32_HOST_OS
+import Annex.LockPool.PosixOrPid as X
+#else
+import Utility.LockPool.Windows as X
+#endif
diff --git a/Annex/LockPool/PosixOrPid.hs b/Annex/LockPool/PosixOrPid.hs
new file mode 100644
index 0000000000..36426fdaf8
--- /dev/null
+++ b/Annex/LockPool/PosixOrPid.hs
@@ -0,0 +1,93 @@
+{- Wraps Utility.LockPool, making pid locks be used when git-annex is so
+ - configured.
+ -
+ - Copyright 2015-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.LockPool.PosixOrPid (
+	LockFile,
+	LockHandle,
+	lockShared,
+	lockExclusive,
+	tryLockShared,
+	tryLockExclusive,
+	dropLock,
+	checkLocked,
+	LockStatus(..),
+	getLockStatus,
+	checkSaneLock,
+) where
+
+import Common
+import Types
+import qualified Annex
+import qualified Utility.LockPool.Posix as Posix
+import qualified Utility.LockPool.PidLock as Pid
+import qualified Utility.LockPool.LockHandle as H
+import Utility.FileMode
+import Utility.LockPool.LockHandle (LockHandle, dropLock)
+import Utility.LockFile.Posix (openLockFile)
+import Utility.LockPool.STM (LockFile, LockMode(..))
+import Utility.LockFile.LockStatus
+import Config (pidLockFile)
+import Messages (warning)
+import Git.Quote
+
+import System.Posix
+
+lockShared :: Maybe ModeSetter -> LockFile -> Annex LockHandle
+lockShared m f = pidLock m f LockShared $ Posix.lockShared m f
+
+lockExclusive :: Maybe ModeSetter -> LockFile -> Annex LockHandle
+lockExclusive m f = pidLock m f LockExclusive $ Posix.lockExclusive m f
+
+tryLockShared :: Maybe ModeSetter -> LockFile -> Annex (Maybe LockHandle)
+tryLockShared m f = tryPidLock m f LockShared $ Posix.tryLockShared m f
+
+tryLockExclusive :: Maybe ModeSetter -> LockFile -> Annex (Maybe LockHandle)
+tryLockExclusive m f = tryPidLock m f LockExclusive $ Posix.tryLockExclusive m f
+
+checkLocked :: LockFile -> Annex (Maybe Bool)
+checkLocked f = Posix.checkLocked f `pidLockCheck` checkpid
+  where
+	checkpid pidlock = Pid.checkLocked pidlock >>= \case
+		-- Only return true when the posix lock file exists.
+		Just _ -> Posix.checkLocked f
+		Nothing -> return Nothing
+
+getLockStatus :: LockFile -> Annex LockStatus
+getLockStatus f = Posix.getLockStatus f
+	`pidLockCheck` Pid.getLockStatus
+
+checkSaneLock :: LockFile -> LockHandle -> Annex Bool
+checkSaneLock f h = H.checkSaneLock f h
+	`pidLockCheck` flip Pid.checkSaneLock h
+
+pidLockCheck :: IO a -> (LockFile -> IO a) -> Annex a
+pidLockCheck posixcheck pidcheck = debugLocks $
+	liftIO . maybe posixcheck pidcheck =<< pidLockFile
+
+pidLock :: Maybe ModeSetter -> LockFile -> LockMode -> IO LockHandle -> Annex LockHandle
+pidLock m f lockmode posixlock = debugLocks $ go =<< pidLockFile
+  where
+	go Nothing = liftIO posixlock
+	go (Just pidlock) = do
+		timeout <- annexPidLockTimeout <$> Annex.getGitConfig
+		liftIO $ dummyPosixLock m f
+		Pid.waitLock f lockmode timeout pidlock (warning . UnquotedString)
+
+tryPidLock :: Maybe ModeSetter -> LockFile -> LockMode -> IO (Maybe LockHandle) -> Annex (Maybe LockHandle)
+tryPidLock m f lockmode posixlock = debugLocks $ liftIO . go =<< pidLockFile
+  where
+	go Nothing = posixlock
+	go (Just pidlock) = do
+		dummyPosixLock m f
+		Pid.tryLock f lockmode pidlock
+
+-- The posix lock file is created even when using pid locks, in order to
+-- avoid complicating any code that might expect to be able to see that
+-- lock file. But, it's not locked.
+dummyPosixLock :: Maybe ModeSetter -> LockFile -> IO ()
+dummyPosixLock m f = bracket (openLockFile ReadLock m f) closeFd (const noop)
diff --git a/Annex/Magic.hs b/Annex/Magic.hs
new file mode 100644
index 0000000000..c408cd50d0
--- /dev/null
+++ b/Annex/Magic.hs
@@ -0,0 +1,74 @@
+{- Interface to libmagic
+ -
+ - Copyright 2019-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Annex.Magic (
+	Magic,
+	MimeType,
+	MimeEncoding,
+	initMagicMime,
+	getMagicMimeType,
+	getMagicMimeEncoding,
+) where
+
+import Types.Mime
+import Control.Monad.IO.Class
+#ifdef WITH_MAGICMIME
+import Magic
+import Utility.Env
+import Control.Concurrent
+import System.IO.Unsafe (unsafePerformIO)
+import Common
+#else
+type Magic = ()
+#endif
+
+initMagicMime :: IO (Maybe Magic)
+#ifdef WITH_MAGICMIME
+initMagicMime = catchMaybeIO $ do
+	m <- magicOpen [MagicMime]
+	liftIO $ getEnv "GIT_ANNEX_DIR" >>= \case
+		Nothing -> magicLoadDefault m
+		Just d -> magicLoad m
+			(d </> "magic" </> "magic.mgc")
+	return m
+#else
+initMagicMime = return Nothing
+#endif
+
+getMagicMime :: Magic -> FilePath -> IO (Maybe (MimeType, MimeEncoding))
+#ifdef WITH_MAGICMIME
+getMagicMime m f = Just . parse <$> magicConcurrentSafe (magicFile m f)
+  where
+	parse s = 
+		let (mimetype, rest) = separate (== ';') s
+		in case rest of
+			(' ':'c':'h':'a':'r':'s':'e':'t':'=':mimeencoding) -> 
+				(mimetype, mimeencoding)
+			_ -> (mimetype, "")
+#else
+getMagicMime _ _ = return Nothing
+#endif
+
+getMagicMimeType :: MonadIO m => Magic -> FilePath -> m (Maybe MimeType)
+getMagicMimeType m f = liftIO $ fmap fst <$> getMagicMime m f
+
+getMagicMimeEncoding :: MonadIO m => Magic -> FilePath -> m(Maybe MimeEncoding)
+getMagicMimeEncoding m f = liftIO $ fmap snd <$> getMagicMime m f
+
+#ifdef WITH_MAGICMIME
+{-# NOINLINE mutex #-}
+mutex :: MVar ()
+mutex = unsafePerformIO $ newMVar ()
+
+-- Work around a bug, the library is not concurrency safe and will
+-- sometimes access the wrong memory if multiple ones are called at the
+-- same time.
+magicConcurrentSafe :: IO a -> IO a
+magicConcurrentSafe = bracket_ (takeMVar mutex) (putMVar mutex ())
+#endif
diff --git a/Annex/MetaData.hs b/Annex/MetaData.hs
new file mode 100644
index 0000000000..1eba836455
--- /dev/null
+++ b/Annex/MetaData.hs
@@ -0,0 +1,121 @@
+{- git-annex metadata
+ -
+ - Copyright 2014-2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.MetaData (
+	genMetaData,
+	dateMetaData,
+	parseModMeta,
+	parseMetaDataMatcher,
+	module X
+) where
+
+import Annex.Common
+import qualified Annex
+import Types.MetaData as X
+import Annex.MetaData.StandardFields as X
+import Logs.MetaData
+import Annex.CatFile
+import Utility.Glob
+
+import qualified Data.Set as S
+import qualified Data.Text as T
+import Data.Time.Calendar
+import Data.Time.Clock
+import Data.Time.Clock.POSIX
+import Text.Read
+
+{- Adds metadata for a file that has just been ingested into the
+ - annex, but has not yet been committed to git.
+ -
+ - When the file has been modified, the metadata is copied over
+ - from the old key to the new key. Note that it looks at the old key as
+ - committed to HEAD -- the new key may or may not have already been staged
+ - in the index.
+ -
+ - Also, can generate new metadata, if configured to do so.
+ -}
+genMetaData :: Key -> RawFilePath -> Maybe POSIXTime -> Annex ()
+genMetaData key file mmtime = do
+	catKeyFileHEAD file >>= \case
+		Nothing -> noop
+		Just oldkey ->
+			-- Have to copy first, before adding any
+			-- more metadata, because copyMetaData does not
+			-- preserve any metadata already on key.
+			whenM (copyMetaData oldkey key <&&> (not <$> onlydatemeta oldkey)) $
+				warncopied
+	whenM (annexGenMetaData <$> Annex.getGitConfig) $
+		case mmtime of
+			Just mtime -> do
+				old <- getCurrentMetaData key
+				addMetaData key $
+					dateMetaData (posixSecondsToUTCTime mtime) old
+			Nothing -> noop
+  where
+	warncopied = warning $ UnquotedString $
+		"Copied metadata from old version of " ++ fromRawFilePath file ++ " to new version. " ++ 
+		"If you don't want this copied metadata, run: git annex metadata --remove-all " ++ fromRawFilePath file
+	-- If the only fields copied were date metadata, and they'll
+	-- be overwritten with the current mtime, no need to warn about
+	-- copying.
+	onlydatemeta oldkey = ifM (annexGenMetaData <$> Annex.getGitConfig)
+		( null . filter (not . isDateMetaField . fst) . fromMetaData 
+			<$> getCurrentMetaData oldkey
+		, return False
+		)
+
+{- Generates metadata for a file's date stamp.
+ -
+ - Any date fields in the old metadata will be overwritten.
+ - 
+ - Note that the returned MetaData does not contain all the input MetaData,
+ - only changes to add the date fields. -}
+dateMetaData :: UTCTime -> MetaData -> MetaData
+dateMetaData mtime old = modMeta old $
+	(SetMeta yearMetaField $ S.singleton $ toMetaValue $ encodeBS $ show y)
+		`ComposeModMeta`
+	(SetMeta monthMetaField $ S.singleton $ toMetaValue $ encodeBS $ show m)
+		`ComposeModMeta`
+	(SetMeta dayMetaField $ S.singleton $ toMetaValue $ encodeBS $ show d)
+  where
+	(y, m, d) = toGregorian $ utctDay mtime
+
+{- Parses field=value, field+=value, field-=value, field?=value -}
+parseModMeta :: String -> Either String ModMeta
+parseModMeta p = case lastMaybe f of
+	Just '+' -> AddMeta <$> mkMetaField (T.pack f') <*> v
+	Just '-' -> DelMeta <$> mkMetaField (T.pack f') <*> (Just <$> v)
+	Just '?' -> MaybeSetMeta <$> mkMetaField (T.pack f') <*> v
+	_ -> SetMeta <$> mkMetaField (T.pack f) <*> (S.singleton <$> v)
+  where
+	(f, sv) = separate (== '=') p
+	f' = beginning f
+	v = pure (toMetaValue (encodeBS sv))
+
+{- Parses field=value, field<value, field<=value, field>value, field>=value -}
+parseMetaDataMatcher :: String -> Either String (MetaField, MetaValue -> Bool)
+parseMetaDataMatcher p = (,)
+	<$> mkMetaField (T.pack f)
+	<*> pure matcher
+  where
+	(f, op_v) = break (`elem` "=<>") p
+	matcher = case op_v of
+		('=':v) -> checkglob v
+		('<':'=':v) -> checkcmp (<=) (<=) v
+		('<':v) -> checkcmp (<) (<) v
+		('>':'=':v) -> checkcmp (>=) (>=) v
+		('>':v) -> checkcmp (>) (>) v
+		_ -> checkglob ""
+	checkglob v =
+		let cglob = compileGlob v CaseInsensitive (GlobFilePath False)
+		in matchGlob cglob . decodeBS . fromMetaValue
+	checkcmp cmp cmp' v mv' = 
+		let v' = decodeBS (fromMetaValue mv')
+		in case (doubleval v, doubleval v') of
+			(Just d, Just d') -> d' `cmp` d
+			_ -> v' `cmp'` v
+	doubleval v = readMaybe v :: Maybe Double
diff --git a/Annex/MetaData/StandardFields.hs b/Annex/MetaData/StandardFields.hs
new file mode 100644
index 0000000000..061133b41c
--- /dev/null
+++ b/Annex/MetaData/StandardFields.hs
@@ -0,0 +1,67 @@
+{- git-annex metadata, standard fields
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.MetaData.StandardFields (
+	tagMetaField,
+	yearMetaField,
+	monthMetaField,
+	dayMetaField,
+	isDateMetaField,
+	lastChangedField,
+	mkLastChangedField,
+	isLastChangedField,
+	itemIdField
+) where
+
+import Types.MetaData
+
+import qualified Data.Text as T
+import Data.Monoid
+import Prelude
+
+tagMetaField :: MetaField
+tagMetaField = mkMetaFieldUnchecked "tag"
+
+yearMetaField :: MetaField
+yearMetaField = mkMetaFieldUnchecked "year"
+
+monthMetaField :: MetaField
+monthMetaField = mkMetaFieldUnchecked "month"
+
+dayMetaField :: MetaField
+dayMetaField = mkMetaFieldUnchecked "day"
+
+isDateMetaField :: MetaField -> Bool
+isDateMetaField f
+	| f == yearMetaField = True
+	| f == monthMetaField = True
+	| f == dayMetaField = True
+	| otherwise = False
+
+lastChangedField :: MetaField
+lastChangedField = mkMetaFieldUnchecked lastchanged
+
+mkLastChangedField :: MetaField -> MetaField
+mkLastChangedField f = mkMetaFieldUnchecked (fromMetaField f <> lastchangedSuffix)
+
+isLastChangedField :: MetaField -> Bool
+isLastChangedField f
+	| f == lastChangedField = True
+	| otherwise = lastchanged `T.isSuffixOf` s && s /= lastchangedSuffix
+  where
+	s = fromMetaField f
+
+lastchanged :: T.Text
+lastchanged = "lastchanged"
+
+lastchangedSuffix :: T.Text
+lastchangedSuffix = "-lastchanged"
+
+itemIdField :: MetaField
+itemIdField = mkMetaFieldUnchecked "itemid"
diff --git a/Annex/Multicast.hs b/Annex/Multicast.hs
new file mode 100644
index 0000000000..1443de776c
--- /dev/null
+++ b/Annex/Multicast.hs
@@ -0,0 +1,44 @@
+{- git-annex multicast receive callback
+ -
+ - Copyright 2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.Multicast where
+
+import Annex.Path
+import Utility.Env
+import Utility.PartialPrelude
+
+import System.Process
+import System.IO
+import GHC.IO.Handle.FD
+import Control.Applicative
+import Prelude
+
+multicastReceiveEnv :: String
+multicastReceiveEnv = "GIT_ANNEX_MULTICAST_RECEIVE"
+
+multicastCallbackEnv :: IO (FilePath, [(String, String)], Handle)
+multicastCallbackEnv = do
+	gitannex <- programPath
+	-- This will even work on Windows
+	(rfd, wfd) <- createPipeFd
+	rh <- fdToHandle rfd
+	environ <- addEntry multicastReceiveEnv (show wfd) <$> getEnvironment
+	return (gitannex, environ, rh)
+
+-- This is run when uftpd has received a file. Rather than move
+-- the file into the annex here, which would require starting up the
+-- Annex monad, parsing git config, and verifying the content, simply
+-- output to the specified FD the filename. This keeps the time
+-- that uftpd is not receiving the next file as short as possible.
+runMulticastReceive :: [String] -> String -> IO ()
+runMulticastReceive ("-I":_sessionid:fs) hs = case readish hs of
+	Just fd -> do
+		h <- fdToHandle fd
+		mapM_ (hPutStrLn h) fs
+		hClose h
+	Nothing -> return ()
+runMulticastReceive _ _ = return ()
diff --git a/Annex/Notification.hs b/Annex/Notification.hs
new file mode 100644
index 0000000000..f205797359
--- /dev/null
+++ b/Annex/Notification.hs
@@ -0,0 +1,108 @@
+{- git-annex desktop notifications
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-}
+{-# LANGUAGE CPP #-}
+
+module Annex.Notification (NotifyWitness, noNotification, notifyTransfer, notifyDrop) where
+
+import Annex.Common
+import Types.Transfer
+#ifdef WITH_DBUS_NOTIFICATIONS
+import qualified Annex
+import Types.DesktopNotify
+import qualified DBus.Notify as Notify
+import qualified DBus.Client
+#endif
+
+-- Witness that notification has happened.
+data NotifyWitness = NotifyWitness
+
+-- Only use when no notification should be done.
+noNotification :: NotifyWitness
+noNotification = NotifyWitness
+
+{- Wrap around an action that performs a transfer, which may run multiple
+ - attempts. Displays notification when supported and when the user asked
+ - for it. -}
+notifyTransfer :: Transferrable t => Observable v => Direction -> t -> (NotifyWitness -> Annex v) -> Annex v
+#ifdef WITH_DBUS_NOTIFICATIONS
+notifyTransfer direction t a = case descTransfrerrable t of
+	Nothing -> a NotifyWitness
+	Just desc -> do
+		wanted <- Annex.getRead Annex.desktopnotify
+		if (notifyStart wanted || notifyFinish wanted)
+			then do
+				client <- liftIO DBus.Client.connectSession
+				startnotification <- liftIO $ if notifyStart wanted
+					then Just <$> Notify.notify client (startedTransferNote direction desc)
+					else pure Nothing
+				res <- a NotifyWitness
+				let ok = observeBool res
+				when (notifyFinish wanted) $ liftIO $ void $ maybe 
+					(Notify.notify client $ finishedTransferNote ok direction desc)
+					(\n -> Notify.replace client n $ finishedTransferNote ok direction desc)
+					startnotification
+				return res
+			else a NotifyWitness
+#else
+notifyTransfer _ _ a = a NotifyWitness
+#endif
+
+notifyDrop :: AssociatedFile -> Bool -> Annex ()
+notifyDrop (AssociatedFile Nothing) _ = noop
+#ifdef WITH_DBUS_NOTIFICATIONS
+notifyDrop (AssociatedFile (Just f)) ok = do
+	wanted <- Annex.getRead Annex.desktopnotify
+	when (notifyFinish wanted) $ liftIO $ do
+		client <- DBus.Client.connectSession
+		void $ Notify.notify client (droppedNote ok (fromRawFilePath f))
+#else
+notifyDrop (AssociatedFile (Just _)) _ = noop
+#endif
+
+#ifdef WITH_DBUS_NOTIFICATIONS
+startedTransferNote :: Direction -> String -> Notify.Note
+startedTransferNote Upload   = mkNote Notify.Transfer Notify.Low iconUpload
+	"Uploading"
+startedTransferNote Download = mkNote Notify.Transfer Notify.Low iconDownload
+	"Downloading"
+
+finishedTransferNote :: Bool -> Direction -> String -> Notify.Note
+finishedTransferNote False Upload   = mkNote Notify.TransferError Notify.Normal iconFailure
+	"Failed to upload"
+finishedTransferNote False Download = mkNote Notify.TransferError Notify.Normal iconFailure
+	"Failed to download"
+finishedTransferNote True  Upload   = mkNote Notify.TransferComplete Notify.Low iconSuccess
+	"Finished uploading"
+finishedTransferNote True  Download = mkNote Notify.TransferComplete Notify.Low iconSuccess
+	"Finished downloading"
+
+droppedNote :: Bool -> String -> Notify.Note
+droppedNote False = mkNote Notify.TransferError Notify.Normal iconFailure
+	"Failed to drop"
+droppedNote True  = mkNote Notify.TransferComplete Notify.Low iconSuccess
+	"Dropped"
+
+iconUpload, iconDownload, iconFailure, iconSuccess :: String
+iconUpload   = "network-transmit"
+iconDownload = "network-receive"
+iconFailure  = "dialog-error"
+iconSuccess  = "git-annex"  -- Is there a standard icon for success/completion?
+
+mkNote :: Notify.Category -> Notify.UrgencyLevel -> String -> String -> FilePath -> Notify.Note
+mkNote category urgency icon desc path = Notify.blankNote
+	{ Notify.appName = "git-annex"
+	, Notify.appImage = Just (Notify.Icon icon)
+	, Notify.summary = desc ++ " " ++ path
+	, Notify.hints =
+		[ Notify.Category category
+		, Notify.Urgency urgency
+		, Notify.SuppressSound True
+		]
+	}
+#endif
diff --git a/Annex/NumCopies.hs b/Annex/NumCopies.hs
new file mode 100644
index 0000000000..69b1943d87
--- /dev/null
+++ b/Annex/NumCopies.hs
@@ -0,0 +1,333 @@
+{- git-annex numcopies configuration and checking
+ -
+ - Copyright 2014-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE ScopedTypeVariables, DeriveDataTypeable, OverloadedStrings #-}
+
+module Annex.NumCopies (
+	module Types.NumCopies,
+	module Logs.NumCopies,
+	getFileNumMinCopies,
+	getSafestNumMinCopies,
+	getSafestNumMinCopies',
+	getGlobalFileNumCopies,
+	getNumCopies,
+	getMinCopies,
+	deprecatedNumCopies,
+	defaultNumCopies,
+	numCopiesCheck,
+	numCopiesCheck',
+	verifyEnoughCopiesToDrop,
+	verifiableCopies,
+	UnVerifiedCopy(..),
+) where
+
+import Annex.Common
+import qualified Annex
+import Types.NumCopies
+import Logs.NumCopies
+import Logs.Trust
+import Annex.CheckAttr
+import qualified Remote
+import qualified Types.Remote as Remote
+import Annex.Content
+import Annex.UUID
+import Annex.CatFile
+import qualified Database.Keys
+
+import Control.Exception
+import qualified Control.Monad.Catch as M
+import Data.Typeable
+
+defaultNumCopies :: NumCopies
+defaultNumCopies = configuredNumCopies 1
+
+defaultMinCopies :: MinCopies
+defaultMinCopies = configuredMinCopies 1
+
+fromSourcesOr :: v -> [Annex (Maybe v)] -> Annex v
+fromSourcesOr v = fromMaybe v <$$> getM id
+
+{- The git config annex.numcopies is deprecated. -}
+deprecatedNumCopies :: Annex (Maybe NumCopies)
+deprecatedNumCopies = annexNumCopies <$> Annex.getGitConfig
+
+{- Value forced on the command line by --numcopies. -}
+getForcedNumCopies :: Annex (Maybe NumCopies)
+getForcedNumCopies = Annex.getRead Annex.forcenumcopies
+
+{- Value forced on the command line by --mincopies. -}
+getForcedMinCopies :: Annex (Maybe MinCopies)
+getForcedMinCopies = Annex.getRead Annex.forcemincopies
+
+{- NumCopies value from any of the non-.gitattributes configuration
+ - sources. -}
+getNumCopies :: Annex NumCopies
+getNumCopies = fromSourcesOr defaultNumCopies
+	[ getForcedNumCopies
+	, getGlobalNumCopies
+	, deprecatedNumCopies
+	]
+
+{- MinCopies value from any of the non-.gitattributes configuration
+ - sources. -}
+getMinCopies :: Annex MinCopies
+getMinCopies = fromSourcesOr defaultMinCopies
+	[ getForcedMinCopies
+	, getGlobalMinCopies
+	]
+
+{- NumCopies and MinCopies value for a file, from any configuration source,
+ - including .gitattributes. -}
+getFileNumMinCopies :: RawFilePath -> Annex (NumCopies, MinCopies)
+getFileNumMinCopies f = do
+	fnumc <- getForcedNumCopies
+	fminc <- getForcedMinCopies
+	case (fnumc, fminc) of
+		(Just numc, Just minc) -> return (numc, minc)
+		(Just numc, Nothing) -> do
+			minc <- fromSourcesOr defaultMinCopies
+				[ snd <$> getNumMinCopiesAttr f
+				, getGlobalMinCopies
+				]
+			return (numc, minc)
+		(Nothing, Just minc) -> do
+			numc <- fromSourcesOr defaultNumCopies
+				[ fst <$> getNumMinCopiesAttr f
+				, getGlobalNumCopies
+				, deprecatedNumCopies
+				]
+			return (numc, minc)
+		(Nothing, Nothing) -> do
+			let fallbacknum = fromSourcesOr defaultNumCopies
+				[ getGlobalNumCopies
+				, deprecatedNumCopies
+				]
+			let fallbackmin = fromSourcesOr defaultMinCopies
+				[ getGlobalMinCopies
+				]
+			getNumMinCopiesAttr f >>= \case
+				(Just numc, Just minc) -> 
+					return (numc, minc)
+				(Just numc, Nothing) -> (,)
+					<$> pure numc
+					<*> fallbackmin
+				(Nothing, Just minc) -> (,)
+					<$> fallbacknum
+					<*> pure minc
+				(Nothing, Nothing) -> (,)
+					<$> fallbacknum
+					<*> fallbackmin
+
+{- Gets the highest NumCopies and MinCopies value for all files
+ - associated with a key. Provide any known associated file;
+ - the rest are looked up from the database.
+ -
+ - Using this when dropping, rather than getFileNumMinCopies
+ - avoids dropping one file that has a smaller value violating
+ - the value set for another file that uses the same content.
+ -}
+getSafestNumMinCopies :: AssociatedFile -> Key -> Annex (NumCopies, MinCopies)
+getSafestNumMinCopies afile k =
+	Database.Keys.getAssociatedFilesIncluding afile k
+		>>= getSafestNumMinCopies' afile k
+
+getSafestNumMinCopies' :: AssociatedFile -> Key -> [RawFilePath] -> Annex (NumCopies, MinCopies)
+getSafestNumMinCopies' afile k fs = do
+	l <- mapM getFileNumMinCopies fs
+	let l' = zip l fs
+	(,)
+		<$> findmax fst l' getNumCopies
+		<*> findmax snd l' getMinCopies
+  where
+	-- Some associated files in the keys database may no longer
+	-- correspond to files in the repository.
+	-- (But the AssociatedFile passed to this is known to be
+	-- an associated file, which may not be in the keys database
+	-- yet, so checking it is skipped.)
+	stillassociated f
+		| AssociatedFile (Just f) == afile = return True
+		| otherwise = catKeyFile f >>= \case
+			Just k' | k' == k -> return True
+			_ -> return False
+	
+	-- Avoid calling stillassociated on every file; just make sure
+	-- that the one with the highest value is still associated.
+	findmax _ [] fallback = fallback
+	findmax getv l fallback = do
+		let n = maximum (map (getv . fst) l)
+		let (maxls, l') = partition (\(x, _) -> getv x == n) l
+		ifM (anyM stillassociated (map snd maxls))
+			( return n
+			, findmax getv l' fallback
+			)
+
+{- This is the globally visible numcopies value for a file. So it does
+ - not include local configuration in the git config or command line
+ - options. -}
+getGlobalFileNumCopies :: RawFilePath  -> Annex NumCopies
+getGlobalFileNumCopies f = fromSourcesOr defaultNumCopies
+	[ fst <$> getNumMinCopiesAttr f
+	, getGlobalNumCopies
+	]
+
+getNumMinCopiesAttr :: RawFilePath  -> Annex (Maybe NumCopies, Maybe MinCopies)
+getNumMinCopiesAttr file =
+	checkAttrs ["annex.numcopies", "annex.mincopies"] file >>= \case
+		(n:m:[]) -> return
+			( configuredNumCopies <$> readish n
+			, configuredMinCopies <$> readish m
+			)
+		_ -> error "internal"
+
+{- Checks if numcopies are satisfied for a file by running a comparison
+ - between the number of (not untrusted) copies that are
+ - believed to exist, and the configured value.
+ -
+ - This is good enough for everything except dropping the file, which
+ - requires active verification of the copies.
+ -}
+numCopiesCheck :: RawFilePath -> Key -> (Int -> Int -> v) -> Annex v
+numCopiesCheck file key vs = do
+	have <- trustExclude UnTrusted =<< Remote.keyLocations key
+	numCopiesCheck' file vs have
+
+numCopiesCheck' :: RawFilePath -> (Int -> Int -> v) -> [UUID] -> Annex v
+numCopiesCheck' file vs have = do
+	needed <- fromNumCopies . fst <$> getFileNumMinCopies file
+	let nhave = length have
+	explain (ActionItemTreeFile file) $ Just $ UnquotedString $
+		"has " ++ show nhave ++ " " ++ pluralCopies nhave ++ 
+		", and the configured annex.numcopies is " ++ show needed
+	return $ nhave `vs` needed
+
+data UnVerifiedCopy = UnVerifiedRemote Remote | UnVerifiedHere
+	deriving (Ord, Eq)
+
+{- Verifies that enough copies of a key exist among the listed remotes,
+ - to safely drop it, running an action with a proof if so, and
+ - printing an informative message if not.
+ -}
+verifyEnoughCopiesToDrop
+	:: String -- message to print when there are no known locations
+	-> Key
+	-> Maybe ContentRemovalLock
+	-> NumCopies
+	-> MinCopies
+	-> [UUID] -- repos to skip considering (generally untrusted remotes)
+	-> [VerifiedCopy] -- copies already verified to exist
+	-> [UnVerifiedCopy] -- places to check to see if they have copies
+	-> (SafeDropProof -> Annex a) -- action to perform the drop
+	-> Annex a -- action to perform when unable to drop
+	-> Annex a
+verifyEnoughCopiesToDrop nolocmsg key removallock neednum needmin skip preverified tocheck dropaction nodropaction = 
+	helper [] [] preverified (nub tocheck) []
+  where
+	helper bad missing have [] lockunsupported =
+		liftIO (mkSafeDropProof neednum needmin have removallock) >>= \case
+			Right proof -> dropaction proof
+			Left stillhave -> do
+				notEnoughCopies key neednum needmin stillhave (skip++missing) bad nolocmsg lockunsupported
+				nodropaction
+	helper bad missing have (c:cs) lockunsupported
+		| isSafeDrop neednum needmin have removallock =
+			liftIO (mkSafeDropProof neednum needmin have removallock) >>= \case
+				Right proof -> dropaction proof
+				Left stillhave -> helper bad missing stillhave (c:cs) lockunsupported
+		| otherwise = case c of
+			UnVerifiedHere -> lockContentShared key contverified
+			UnVerifiedRemote r -> checkremote r contverified $
+				let lockunsupported' = r : lockunsupported
+				in Remote.hasKey r key >>= \case
+					Right True  -> helper bad missing (mkVerifiedCopy RecentlyVerifiedCopy r : have) cs lockunsupported'
+					Left _      -> helper (r:bad) missing have cs lockunsupported'
+					Right False -> helper bad (Remote.uuid r:missing) have cs lockunsupported'
+		  where
+			contverified vc = helper bad missing (vc : have) cs lockunsupported
+
+	checkremote r cont fallback = case Remote.lockContent r of
+		Just lockcontent -> do
+			-- The remote's lockContent will throw an exception
+			-- when it is unable to lock, in which case the
+			-- fallback should be run. 
+			--
+			-- On the other hand, the continuation could itself
+			-- throw an exception (ie, the eventual drop action
+			-- fails), and in this case we don't want to run the
+			-- fallback since part of the drop action may have
+			-- already been performed.
+			--
+			-- Differentiate between these two sorts
+			-- of exceptions by using DropException.
+			let a = lockcontent key $ \v -> 
+				cont v `catchNonAsync` (throw . DropException)
+			a `M.catches`
+				[ M.Handler (\ (e :: AsyncException) -> throwM e)
+				, M.Handler (\ (e :: SomeAsyncException) -> throwM e)
+				, M.Handler (\ (DropException e') -> throwM e')
+				, M.Handler (\ (_e :: SomeException) -> fallback)
+				]
+		Nothing -> fallback
+
+data DropException = DropException SomeException
+	deriving (Typeable, Show)
+
+instance Exception DropException
+
+notEnoughCopies :: Key -> NumCopies -> MinCopies -> [VerifiedCopy] -> [UUID] -> [Remote] -> String -> [Remote] -> Annex ()
+notEnoughCopies key neednum needmin have skip bad nolocmsg lockunsupported = do
+	showNote "unsafe"
+	if length have < fromNumCopies neednum
+		then showLongNote $ UnquotedString $
+			if fromNumCopies neednum == 1
+				then "Could not verify the existence of the 1 necessary copy."
+				else "Could only verify the existence of " ++
+					show (length have) ++ " out of " ++ show (fromNumCopies neednum) ++ 
+					" necessary " ++ pluralCopies (fromNumCopies neednum) ++ "."
+		else do
+			showLongNote $ UnquotedString $ "Unable to lock down " ++ show (fromMinCopies needmin) ++ 
+				" " ++ pluralCopies (fromMinCopies needmin) ++ 
+				" of file necessary to safely drop it."
+			if null lockunsupported
+				then showLongNote "(This could have happened because of a concurrent drop, or because a remote has too old a version of git-annex-shell installed.)"
+				else showLongNote $ UnquotedString $ "These remotes do not support locking: "
+					++ Remote.listRemoteNames lockunsupported
+
+	Remote.showTriedRemotes bad
+	Remote.showLocations True key (map toUUID have++skip) nolocmsg
+
+pluralCopies :: Int -> String
+pluralCopies 1 = "copy"
+pluralCopies _ = "copies"
+
+{- Finds locations of a key that can be used to get VerifiedCopies,
+ - in order to allow dropping the key.
+ -
+ - Provide a list of UUIDs that the key is being dropped from.
+ - The returned lists will exclude any of those UUIDs.
+ -
+ - The return lists also exclude any repositories that are untrusted,
+ - since those should not be used for verification.
+ -
+ - The UnVerifiedCopy list is cost ordered.
+ - The VerifiedCopy list contains repositories that are trusted to
+ - contain the key.
+ -}
+verifiableCopies :: Key -> [UUID] -> Annex ([UnVerifiedCopy], [VerifiedCopy])
+verifiableCopies key exclude = do
+	locs <- Remote.keyLocations key
+	(remotes, trusteduuids) <- Remote.remoteLocations (Remote.IncludeIgnored False) locs
+		=<< trustGet Trusted
+	untrusteduuids <- trustGet UnTrusted
+	let exclude' = exclude ++ untrusteduuids
+	let remotes' = Remote.remotesWithoutUUID remotes (exclude' ++ trusteduuids)
+	let verified = map (mkVerifiedCopy TrustedCopy) $
+		filter (`notElem` exclude') trusteduuids
+	u <- getUUID
+	let herec = if u `elem` locs && u `notElem` exclude'
+		then [UnVerifiedHere]
+		else []
+	return (herec ++ map UnVerifiedRemote remotes', verified)
diff --git a/Annex/Path.hs b/Annex/Path.hs
new file mode 100644
index 0000000000..aa51da1b58
--- /dev/null
+++ b/Annex/Path.hs
@@ -0,0 +1,125 @@
+{- git-annex program path
+ -
+ - Copyright 2013-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.Path (
+	programPath,
+	readProgramFile,
+	gitAnnexChildProcess,
+	gitAnnexChildProcessParams,
+	gitAnnexDaemonizeParams,
+	cleanStandaloneEnvironment,
+) where
+
+import Annex.Common
+import Config.Files
+import Utility.Env
+import Annex.PidLock
+import qualified Annex
+
+import System.Environment (getExecutablePath, getArgs, getProgName)
+
+{- A fully qualified path to the currently running git-annex program.
+ - 
+ - getExecutablePath is used when possible. On OSs it supports
+ - well, it returns the complete path to the program. But, on other OSs,
+ - it might return just the basename. Fall back to reading the programFile,
+ - or searching for the command name in PATH.
+ -
+ - The standalone build runs git-annex via ld.so, and defeats
+ - getExecutablePath. It sets GIT_ANNEX_DIR to the location of the
+ - standalone build directory, and there are wrapper scripts for git-annex
+ - and git-annex-shell in that directory.
+ -}
+programPath :: IO FilePath
+programPath = go =<< getEnv "GIT_ANNEX_DIR"
+  where
+	go (Just dir) = do
+		name <- getProgName
+		return (dir </> name)
+	go Nothing = do
+		exe <- getExecutablePath
+		p <- if isAbsolute exe
+			then return exe
+			else fromMaybe exe <$> readProgramFile
+		maybe cannotFindProgram return =<< searchPath p
+
+{- Returns the path for git-annex that is recorded in the programFile. -}
+readProgramFile :: IO (Maybe FilePath)
+readProgramFile = do
+	programfile <- programFile
+	headMaybe . lines <$> readFile programfile
+
+cannotFindProgram :: IO a
+cannotFindProgram = do
+	f <- programFile
+	giveup $ "cannot find git-annex program in PATH or in " ++ f
+
+{- Runs a git-annex child process.
+ -
+ - Like runsGitAnnexChildProcessViaGit, when pid locking is in use,
+ - this takes the pid lock, while running it, and sets an env var
+ - that prevents the child process trying to take the pid lock,
+ - to avoid it deadlocking.
+ -}
+gitAnnexChildProcess
+	:: String
+	-> [CommandParam]
+	-> (CreateProcess -> CreateProcess)
+	-> (Maybe Handle -> Maybe Handle -> Maybe Handle -> ProcessHandle -> IO a)
+	-> Annex a
+gitAnnexChildProcess subcmd ps f a = do
+	cmd <- liftIO programPath
+	ps' <- gitAnnexChildProcessParams subcmd ps
+	pidLockChildProcess cmd ps' f a
+
+{- Parameters to pass to a git-annex child process to run a subcommand
+ - with some parameters.
+ -
+ - Includes -c values that were passed on the git-annex command line
+ - or due to options like --debug being enabled.
+ -}
+gitAnnexChildProcessParams :: String -> [CommandParam] -> Annex [CommandParam]
+gitAnnexChildProcessParams subcmd ps = do
+	cps <- gitAnnexGitConfigOverrides
+	return (Param subcmd : cps ++ ps)
+
+gitAnnexGitConfigOverrides :: Annex [CommandParam]
+gitAnnexGitConfigOverrides = concatMap (\c -> [Param "-c", Param c])
+	<$> Annex.getGitConfigOverrides
+
+{- Parameters to pass to git-annex when re-running the current command
+ - to daemonize it. Used with Utility.Daemon.daemonize. -}
+gitAnnexDaemonizeParams :: Annex [CommandParam]
+gitAnnexDaemonizeParams = do
+	-- This includes -c parameters passed to git, as well as ones
+	-- passed to git-annex.
+	cps <- gitAnnexGitConfigOverrides
+	-- Get every parameter git-annex was run with.
+	ps <- liftIO getArgs
+	return (map Param ps ++ cps)
+
+{- Returns a cleaned up environment that lacks path and other settings
+ - used to make the standalone builds use their bundled libraries and programs.
+ - Useful when calling programs not included in the standalone builds.
+ -
+ - For a non-standalone build, returns Nothing.
+ -}
+cleanStandaloneEnvironment :: IO (Maybe [(String, String)])
+cleanStandaloneEnvironment = clean <$> getEnvironment
+  where
+	clean environ
+		| null vars = Nothing
+		| otherwise = Just $ catMaybes $ map (restoreorig environ) environ
+	  where
+		vars = words $ fromMaybe "" $
+			lookup "GIT_ANNEX_STANDLONE_ENV" environ
+		restoreorig oldenviron p@(k, _v)
+			| k `elem` vars = case lookup ("ORIG_" ++ k) oldenviron of
+				(Just v')
+					| not (null v') -> Just (k, v')
+				_ -> Nothing
+			| otherwise = Just p
diff --git a/Annex/Perms.hs b/Annex/Perms.hs
new file mode 100644
index 0000000000..83b4f73130
--- /dev/null
+++ b/Annex/Perms.hs
@@ -0,0 +1,374 @@
+{- git-annex file permissions
+ -
+ - Copyright 2012-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Perms (
+	FileMode,
+	setAnnexFilePerm,
+	setAnnexDirPerm,
+	resetAnnexFilePerm,
+	annexFileMode,
+	createAnnexDirectory,
+	createWorkTreeDirectory,
+	freezeContent,
+	freezeContent',
+	freezeContent'',
+	checkContentWritePerm,
+	checkContentWritePerm',
+	thawContent,
+	thawContent',
+	createContentDir,
+	freezeContentDir,
+	thawContentDir,
+	modifyContentDir,
+	modifyContentDirWhenExists,
+	withShared,
+	hasFreezeHook,
+	hasThawHook,
+) where
+
+import Annex.Common
+import Utility.FileMode
+import Git
+import Git.ConfigTypes
+import qualified Annex
+import Annex.Version
+import Types.RepoVersion
+import Config
+import Utility.Directory.Create
+import qualified Utility.RawFilePath as R
+
+import System.PosixCompat.Files (fileMode, intersectFileModes, nullFileMode, groupWriteMode, ownerWriteMode, ownerReadMode, groupReadMode, otherReadMode, stdFileMode, ownerExecuteMode, groupExecuteMode, otherExecuteMode, setGroupIDMode)
+
+withShared :: (SharedRepository -> Annex a) -> Annex a
+withShared a = a =<< coreSharedRepository <$> Annex.getGitConfig
+
+setAnnexFilePerm :: RawFilePath -> Annex ()
+setAnnexFilePerm = setAnnexPerm False
+
+setAnnexDirPerm :: RawFilePath -> Annex ()
+setAnnexDirPerm = setAnnexPerm True
+
+{- Sets appropriate file mode for a file or directory in the annex,
+ - other than the content files and content directory. Normally,
+ - don't change the mode, but with core.sharedRepository set,
+ - allow the group to write, etc. -}
+setAnnexPerm :: Bool -> RawFilePath -> Annex ()
+setAnnexPerm isdir file = setAnnexPerm' Nothing isdir >>= \go -> liftIO (go file)
+
+setAnnexPerm' :: Maybe ([FileMode] -> FileMode -> FileMode) -> Bool -> Annex (RawFilePath -> IO ())
+setAnnexPerm' modef isdir = ifM crippledFileSystem
+	( return (const noop)
+	, withShared $ \s -> return $ \file -> go s file
+	)
+  where
+	go GroupShared file = void $ tryIO $ modifyFileMode file $ modef' $
+		groupSharedModes ++
+		if isdir then [ ownerExecuteMode, groupExecuteMode ] else []
+	go AllShared file = void $ tryIO $ modifyFileMode file $ modef' $
+		readModes ++
+		[ ownerWriteMode, groupWriteMode ] ++
+		if isdir then executeModes else []
+	go UnShared file = case modef of
+		Nothing -> noop
+		Just f -> void $ tryIO $
+			modifyFileMode file $ f []
+	go (UmaskShared n) file = void $ tryIO $ R.setFileMode file $
+		if isdir then umaskSharedDirectory n else n
+	modef' = fromMaybe addModes modef
+
+resetAnnexFilePerm :: RawFilePath -> Annex ()
+resetAnnexFilePerm = resetAnnexPerm False
+
+{- Like setAnnexPerm, but ignores the current mode of the file entirely,
+ - and sets the same mode that the umask would result in when creating a
+ - new file.
+ -
+ - Useful eg, after creating a temporary file with locked down modes,
+ - which is going to be moved to a non-temporary location and needs
+ - usual modes.
+ -}
+resetAnnexPerm :: Bool -> RawFilePath -> Annex ()
+resetAnnexPerm isdir file = unlessM crippledFileSystem $ do
+	defmode <- liftIO defaultFileMode
+	let modef moremodes _oldmode = addModes moremodes defmode
+	setAnnexPerm' (Just modef) isdir >>= \go -> liftIO (go file)
+
+{- Creates a ModeSetter which can be used for creating a file in the annex
+ - (other than content files, which are locked down more). -}
+annexFileMode :: Annex ModeSetter
+annexFileMode = do
+	modesetter <- setAnnexPerm' Nothing False
+	withShared (\s -> pure $ mk s modesetter)
+  where
+	mk GroupShared = ModeSetter stdFileMode
+	mk AllShared = ModeSetter stdFileMode
+	mk UnShared = ModeSetter stdFileMode
+	mk (UmaskShared mode) = ModeSetter mode
+
+{- Creates a directory inside the gitAnnexDir (or possibly the dbdir), 
+ - creating any parent directories up to and including the gitAnnexDir.
+ - Makes directories with appropriate permissions. -}
+createAnnexDirectory :: RawFilePath -> Annex ()
+createAnnexDirectory dir = do
+	top <- parentDir <$> fromRepo gitAnnexDir
+	tops <- annexDbDir <$> Annex.getGitConfig >>= return . \case
+		Nothing -> [top]
+		Just dbdir -> [top, parentDir (parentDir dbdir)]
+	createDirectoryUnder' tops dir createdir
+  where
+	createdir p = do
+		liftIO $ R.createDirectory p
+		setAnnexDirPerm p
+
+{- Create a directory in the git work tree, creating any parent
+ - directories up to the top of the work tree.
+ -
+ - Uses default permissions.
+ -}
+createWorkTreeDirectory :: RawFilePath -> Annex ()
+createWorkTreeDirectory dir = do
+	fromRepo repoWorkTree >>= liftIO . \case
+		Just wt -> createDirectoryUnder [wt] dir
+		-- Should never happen, but let whatever tries to write
+		-- to the directory be what throws an exception, as that
+		-- will be clearer than an exception from here.
+		Nothing -> noop
+
+{- Normally, blocks writing to an annexed file, and modifies file
+ - permissions to allow reading it.
+ -
+ - Before v9, when core.sharedRepository is set, the write bits are not
+ - removed from the file, but instead the appropriate group write bits
+ - are set. This is necessary to let other users in the group lock the file.
+ - v9 improved this by using separate lock files, so the content file does
+ - not need to be writable when using it.
+ -
+ - In a shared repository, the current user may not be able to change
+ - a file owned by another user, so failure to change modes is ignored.
+ -
+ - Note that, on Linux, xattrs can sometimes prevent removing
+ - certain permissions from a file with chmod. (Maybe some ACLs too?) 
+ - In such a case, this will return with the file still having some mode
+ - it should not normally have. checkContentWritePerm can detect when
+ - that happens with write permissions.
+ -}
+freezeContent :: RawFilePath -> Annex ()
+freezeContent file =
+	withShared $ \sr -> freezeContent' sr file
+
+freezeContent' :: SharedRepository -> RawFilePath -> Annex ()
+freezeContent' sr file = freezeContent'' sr file =<< getVersion
+
+freezeContent'' :: SharedRepository -> RawFilePath -> Maybe RepoVersion -> Annex ()
+freezeContent'' sr file rv = do
+	fastDebug "Annex.Perms" ("freezing content " ++ fromRawFilePath file)
+	unlessM crippledFileSystem $ go sr
+	freezeHook file
+  where
+	go UnShared = liftIO $ nowriteadd [ownerReadMode]
+	go GroupShared = if versionNeedsWritableContentFiles rv
+		then liftIO $ ignoresharederr $ modmode $ addModes
+			[ownerReadMode, groupReadMode, ownerWriteMode, groupWriteMode]
+		else liftIO $ ignoresharederr $
+			nowriteadd [ownerReadMode, groupReadMode]
+	go AllShared = if versionNeedsWritableContentFiles rv
+		then liftIO $ ignoresharederr $ modmode $ addModes
+			(readModes ++ writeModes)
+		else liftIO $ ignoresharederr $ 
+			nowriteadd readModes
+	go (UmaskShared n) = if versionNeedsWritableContentFiles rv
+		-- Assume that the configured mode includes write bits
+		-- for all users who should be able to lock the file, so
+		-- don't need to add any write modes.
+		then liftIO $ ignoresharederr $ modmode $ const n
+		else liftIO $ ignoresharederr $ modmode $ const $
+			removeModes writeModes n
+
+	ignoresharederr = void . tryIO
+
+	modmode = modifyFileMode file
+
+	nowriteadd readmodes = modmode $ 
+		removeModes writeModes .
+		addModes readmodes
+
+{- Checks if the write permissions are as freezeContent should set them.
+ -
+ - When the repository is shared, the user may not be able to change
+ - permissions of a file owned by another user. So if the permissions seem
+ - wrong, but the repository is shared, returns Nothing. If the permissions
+ - are wrong otherwise, returns Just False.
+ -
+ - When there is a freeze hook, it may prevent write in some way other than
+ - permissions. One use of a freeze hook is when the filesystem does not
+ - support removing write permissions, so when there is such a hook
+ - write permissions are ignored.
+ -}
+checkContentWritePerm :: RawFilePath -> Annex (Maybe Bool)
+checkContentWritePerm file = ifM crippledFileSystem
+	( return (Just True)
+	, do
+		rv <- getVersion
+		hasfreezehook <- hasFreezeHook
+		withShared $ \sr ->
+			liftIO $ checkContentWritePerm' sr file rv hasfreezehook
+	)
+
+checkContentWritePerm' :: SharedRepository -> RawFilePath -> Maybe RepoVersion -> Bool -> IO (Maybe Bool)
+checkContentWritePerm' sr file rv hasfreezehook
+	| hasfreezehook = return (Just True)
+	| otherwise = case sr of
+		UnShared -> want Just (excludemodes writeModes)
+		GroupShared
+			| versionNeedsWritableContentFiles rv -> want sharedret
+				(includemodes [ownerWriteMode, groupWriteMode])
+			| otherwise -> want sharedret (excludemodes writeModes)
+		AllShared
+			| versionNeedsWritableContentFiles rv -> 
+				want sharedret (includemodes writeModes)
+			| otherwise -> want sharedret (excludemodes writeModes)
+		UmaskShared n
+			| versionNeedsWritableContentFiles rv -> want sharedret
+				(\havemode -> havemode == n)
+			| otherwise -> want sharedret
+				(\havemode -> havemode == removeModes writeModes n)
+  where
+	want mk f = catchMaybeIO (fileMode <$> R.getFileStatus file)
+		>>= return . \case
+			Just havemode -> mk (f havemode)
+			Nothing -> mk True
+	
+	includemodes l havemode = havemode == combineModes (havemode:l)
+	excludemodes l havemode = all (\m -> intersectFileModes m havemode == nullFileMode) l
+
+	sharedret True = Just True
+	sharedret False = Nothing
+
+{- Allows writing to an annexed file that freezeContent was called on
+ - before. -}
+thawContent :: RawFilePath -> Annex ()
+thawContent file = withShared $ \sr -> thawContent' sr file
+
+thawContent' :: SharedRepository -> RawFilePath -> Annex ()
+thawContent' sr file = do
+	fastDebug "Annex.Perms" ("thawing content " ++ fromRawFilePath file)
+	thawPerms (go sr) (thawHook file)
+  where
+	go GroupShared = liftIO $ void $ tryIO $ groupWriteRead file
+	go AllShared = liftIO $ void $ tryIO $ groupWriteRead file
+	go UnShared = liftIO $ allowWrite file
+	go (UmaskShared n) = liftIO $ void $ tryIO $ R.setFileMode file n
+
+{- Runs an action that thaws a file's permissions. This will probably
+ - fail on a crippled filesystem. But, if file modes are supported on a
+ - crippled filesystem, the file may be frozen, so try to thaw its
+ - permissions. -}
+thawPerms :: Annex () -> Annex () -> Annex ()
+thawPerms a hook = ifM crippledFileSystem
+	( hook >> void (tryNonAsync a)
+	, hook >> a
+	)
+
+{- Blocks writing to the directory an annexed file is in, to prevent the
+ - file accidentally being deleted. However, if core.sharedRepository
+ - is set, this is not done, since the group must be allowed to delete the
+ - file without eing able to thaw the directory.
+ -}
+freezeContentDir :: RawFilePath -> Annex ()
+freezeContentDir file = do
+	fastDebug "Annex.Perms" ("freezing content directory " ++ fromRawFilePath dir)
+	unlessM crippledFileSystem $ withShared go
+	freezeHook dir
+  where
+	dir = parentDir file
+	go UnShared = liftIO $ preventWrite dir
+	go GroupShared = liftIO $ void $ tryIO $ groupWriteRead dir
+	go AllShared = liftIO $ void $ tryIO $ groupWriteRead dir
+	go (UmaskShared n) = liftIO $ void $ tryIO $ R.setFileMode dir $
+		umaskSharedDirectory $ 
+			-- If n includes group or other write mode, leave them set
+			-- to allow them to delete the file without being able to
+			-- thaw the directory.
+			removeModes [ownerWriteMode] n
+
+thawContentDir :: RawFilePath -> Annex ()
+thawContentDir file = do
+	fastDebug "Annex.Perms" ("thawing content directory " ++ fromRawFilePath dir)
+	thawPerms (withShared (liftIO . go)) (thawHook dir)
+  where
+	dir = parentDir file
+	go UnShared = allowWrite dir
+	go GroupShared = allowWrite dir
+	go AllShared = allowWrite dir
+	go (UmaskShared n) = R.setFileMode dir n
+
+{- Makes the directory tree to store an annexed file's content,
+ - with appropriate permissions on each level. -}
+createContentDir :: RawFilePath -> Annex ()
+createContentDir dest = do
+	unlessM (liftIO $ R.doesPathExist dir) $
+		createAnnexDirectory dir 
+	-- might have already existed with restricted perms
+	thawHook dir
+	unlessM crippledFileSystem $ liftIO $ allowWrite dir
+  where
+	dir = parentDir dest
+
+{- Creates the content directory for a file if it doesn't already exist,
+ - or thaws it if it does, then runs an action to modify a file in the
+ - directory, and finally, freezes the content directory. -}
+modifyContentDir :: RawFilePath -> Annex a -> Annex a
+modifyContentDir f a = do
+	createContentDir f -- also thaws it
+	v <- tryNonAsync a
+	freezeContentDir f
+	either throwM return v
+
+{- Like modifyContentDir, but avoids creating the content directory if it
+ - does not already exist. In that case, the action will probably fail. -}
+modifyContentDirWhenExists :: RawFilePath -> Annex a -> Annex a
+modifyContentDirWhenExists f a = do
+	thawContentDir f
+	v <- tryNonAsync a
+	freezeContentDir f
+	either throwM return v
+
+hasFreezeHook :: Annex Bool
+hasFreezeHook = isJust . annexFreezeContentCommand <$> Annex.getGitConfig
+
+hasThawHook :: Annex Bool
+hasThawHook = isJust . annexThawContentCommand <$> Annex.getGitConfig
+
+freezeHook :: RawFilePath -> Annex ()
+freezeHook p = maybe noop go =<< annexFreezeContentCommand <$> Annex.getGitConfig
+  where
+	go basecmd = void $ liftIO $
+		boolSystem "sh" [Param "-c", Param $ gencmd basecmd]
+	gencmd = massReplace [ ("%path", shellEscape (fromRawFilePath p)) ]
+
+thawHook :: RawFilePath -> Annex ()
+thawHook p = maybe noop go =<< annexThawContentCommand <$> Annex.getGitConfig
+  where
+	go basecmd = void $ liftIO $
+		boolSystem "sh" [Param "-c", Param $ gencmd basecmd]
+	gencmd = massReplace [ ("%path", shellEscape (fromRawFilePath p)) ]
+
+{- Calculate mode to use for a directory from the mode to use for a file.
+ -
+ - This corresponds to git's handling of core.sharedRepository=0xxx
+ -}
+umaskSharedDirectory :: FileMode -> FileMode
+umaskSharedDirectory n = flip addModes n $ map snd $ filter fst
+	[ (isset ownerReadMode, ownerExecuteMode)
+	, (isset groupReadMode, groupExecuteMode)
+	, (isset otherReadMode, otherExecuteMode)
+	, (isset groupReadMode || isset groupWriteMode, setGroupIDMode)
+	]
+  where
+	isset v = checkMode v n
diff --git a/Annex/PidLock.hs b/Annex/PidLock.hs
new file mode 100644
index 0000000000..9b2adea4e8
--- /dev/null
+++ b/Annex/PidLock.hs
@@ -0,0 +1,131 @@
+{- Pid locking support.
+ -
+ - Copyright 2014-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Annex.PidLock where
+
+import Annex.Common
+import Git
+#ifndef mingw32_HOST_OS
+import Git.Env
+import Annex.GitOverlay
+import qualified Utility.LockFile.PidLock as PidF
+import qualified Utility.LockPool.PidLock as PidP
+import Utility.LockPool (dropLock)
+import Utility.Env
+import Config
+#endif
+
+{- When pid locking is in use, this tries to take the pid lock (unless
+ - the process already has it), and if successful, holds it while
+ - running the child process. The child process is run with an env var
+ - set, which prevents it from trying to take the pid lock itself.
+ -
+ - This way, any locking the parent does will not get in the way of
+ - the child. The child is assumed to not do any locking that conflicts
+ - with the parent, but if it did happen to do that, it would be noticed
+ - when git-annex is used without pid locking.
+ -
+ - If another process is already holding the pid lock, the child process
+ - is still run, but without setting the env var, so it can try to take the
+ - pid lock itself, and fail however is appropriate for it in that
+ - situation.
+ -}
+pidLockChildProcess
+	:: FilePath
+	-> [CommandParam]
+	-> (CreateProcess -> CreateProcess)
+	-> (Maybe Handle -> Maybe Handle -> Maybe Handle -> ProcessHandle -> IO a)
+	-> Annex a
+pidLockChildProcess cmd ps f a = do
+	let p = f (proc cmd (toCommand ps))
+	let gonopidlock = withCreateProcess p a
+#ifndef mingw32_HOST_OS
+	pidLockFile >>= liftIO . \case
+		Nothing -> gonopidlock
+		Just pidlock -> bracket
+			(setup pidlock)
+			cleanup
+			(go gonopidlock p pidlock)
+  where
+  	setup pidlock = fmap fst <$> PidP.tryLock' pidlock
+
+	cleanup (Just h) = dropLock h
+	cleanup Nothing = return ()
+
+	go gonopidlock _ _ Nothing = gonopidlock
+	go _ p pidlock (Just _h) = do
+		v <- PidF.pidLockEnv pidlock
+		baseenv <- case env p of
+			Nothing -> getEnvironment
+			Just baseenv -> pure baseenv
+		let p' = p { env = Just ((v, PidF.pidLockEnvValue) : baseenv) }
+		withCreateProcess p' a
+#else
+	liftIO gonopidlock
+#endif
+
+{- Wrap around actions that may run a git-annex child process via a git
+ - command.
+ -
+ - This is like pidLockChildProcess, but rather than running a process
+ - itself, it runs the action with a modified Annex state that passes the
+ - necessary env var when running git.
+ -}
+runsGitAnnexChildProcessViaGit :: Annex a -> Annex a
+#ifndef mingw32_HOST_OS
+runsGitAnnexChildProcessViaGit a = pidLockFile >>= \case
+	Nothing -> a
+	Just pidlock -> bracket (setup pidlock) cleanup (go pidlock)
+  where
+	setup pidlock = liftIO $ fmap fst <$> PidP.tryLock' pidlock
+	
+	cleanup (Just h) = liftIO $ dropLock h
+	cleanup Nothing = return ()
+	
+	go _ Nothing = a
+	go pidlock (Just _h) = do
+		v <- liftIO $ PidF.pidLockEnv pidlock
+		let addenv g = do
+			g' <- liftIO $ addGitEnv g v PidF.pidLockEnvValue
+			return (g', ())
+		let rmenv oldg g
+			| any (\(k, _) -> k == v) (fromMaybe [] (Git.gitEnv oldg)) = g
+			| otherwise = 
+				let e' = case Git.gitEnv g of
+					Just e -> Just (delEntry v e)
+					Nothing -> Nothing
+				in g { Git.gitEnv = e' }
+		withAltRepo addenv rmenv (const a)
+#else
+runsGitAnnexChildProcessViaGit a = a
+#endif
+
+{- Like runsGitAnnexChildProcessViaGit, but the Annex state is not
+ - modified. Instead the input Repo's state is modified to set the 
+ - necessary env var when git is run in that Repo.
+ -}
+runsGitAnnexChildProcessViaGit' :: Git.Repo -> (Git.Repo -> Annex a) -> Annex a
+#ifndef mingw32_HOST_OS
+runsGitAnnexChildProcessViaGit' r a = pidLockFile >>= \case
+	Nothing -> a r
+	Just pidlock -> bracketIO (setup pidlock) cleanup (go pidlock)
+  where
+	setup pidlock = fmap fst <$> PidP.tryLock' pidlock
+	
+	cleanup (Just h) = dropLock h
+	cleanup Nothing = return ()
+	
+	go _ Nothing = a r
+	go pidlock (Just _h) = do
+		v <- liftIO $ PidF.pidLockEnv pidlock
+		r' <- liftIO $ addGitEnv r v PidF.pidLockEnvValue
+		a r'
+#else
+runsGitAnnexChildProcessViaGit' r a = a r
+#endif
diff --git a/Annex/Queue.hs b/Annex/Queue.hs
new file mode 100644
index 0000000000..b2b28bccb5
--- /dev/null
+++ b/Annex/Queue.hs
@@ -0,0 +1,97 @@
+{- git-annex command queue
+ -
+ - Copyright 2011-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Annex.Queue (
+	addCommand,
+	addFlushAction,
+	addUpdateIndex,
+	flush,
+	flushWhenFull,
+	size,
+	get,
+	mergeFrom,
+) where
+
+import Annex.Common
+import Annex hiding (new)
+import Annex.LockFile
+import qualified Git.Queue
+import qualified Git.UpdateIndex
+
+{- Adds a git command to the queue. -}
+addCommand :: [CommandParam] -> String -> [CommandParam] -> [FilePath] -> Annex ()
+addCommand commonparams command params files = do
+	q <- get
+	store =<< flushWhenFull =<<
+		(Git.Queue.addCommand commonparams command params files q =<< gitRepo)
+
+addFlushAction :: Git.Queue.FlushActionRunner Annex -> [RawFilePath] -> Annex ()
+addFlushAction runner files = do
+	q <- get
+	store =<< flushWhenFull =<<
+		(Git.Queue.addFlushAction runner files q =<< gitRepo)
+
+{- Adds an update-index stream to the queue. -}
+addUpdateIndex :: Git.UpdateIndex.Streamer -> Annex ()
+addUpdateIndex streamer = do
+	q <- get
+	store =<< flushWhenFull =<<
+		(Git.Queue.addUpdateIndex streamer q =<< gitRepo)
+
+{- Runs the queue if it is full. -}
+flushWhenFull :: Git.Queue.Queue Annex -> Annex (Git.Queue.Queue Annex)
+flushWhenFull q
+	| Git.Queue.full q = flush' q
+	| otherwise = return q
+
+{- Runs (and empties) the queue. -}
+flush :: Annex ()
+flush = do
+	q <- get
+	unless (0 == Git.Queue.size q) $ do
+		store =<< flush' q
+
+{- When there are multiple worker threads, each has its own queue.
+ - And of course multiple git-annex processes may be running each with its
+ - own queue.
+ -
+ - But, flushing two queues at the same time could lead to failures due to
+ - git locking files. So, only one queue is allowed to flush at a time.
+ -}
+flush' :: Git.Queue.Queue Annex -> Annex (Git.Queue.Queue Annex)
+flush' q = do
+	lck <- fromRepo gitAnnexGitQueueLock
+	withExclusiveLock lck $ do
+		showStoringStateAction
+		Git.Queue.flush q =<< gitRepo
+
+{- Gets the size of the queue. -}
+size :: Annex Int
+size = Git.Queue.size <$> get
+
+get :: Annex (Git.Queue.Queue Annex)
+get = maybe new return =<< getState repoqueue
+
+new :: Annex (Git.Queue.Queue Annex)
+new = do
+	sz <- annexQueueSize <$> getGitConfig
+	q <- liftIO $ Git.Queue.new sz Nothing
+	store q
+	return q
+
+store :: Git.Queue.Queue Annex -> Annex ()
+store q = changeState $ \s -> s { repoqueue = Just q }
+
+mergeFrom :: AnnexState -> Annex ()
+mergeFrom st = case repoqueue st of
+	Nothing -> noop
+	Just newq -> do
+		q <- get
+		let !q' = Git.Queue.merge q newq
+		store =<< flushWhenFull q'
diff --git a/Annex/RemoteTrackingBranch.hs b/Annex/RemoteTrackingBranch.hs
new file mode 100644
index 0000000000..06591d0918
--- /dev/null
+++ b/Annex/RemoteTrackingBranch.hs
@@ -0,0 +1,96 @@
+{- git-annex remote tracking branches
+ -
+ - Copyright 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.RemoteTrackingBranch
+	( RemoteTrackingBranch
+	, mkRemoteTrackingBranch
+	, fromRemoteTrackingBranch
+	, setRemoteTrackingBranch
+	, makeRemoteTrackingBranchMergeCommit
+	, makeRemoteTrackingBranchMergeCommit'
+	, getRemoteTrackingBranchImportHistory
+	) where
+
+import Annex.Common
+import Annex.CatFile
+import qualified Annex
+import Git.Types
+import qualified Git.Ref
+import qualified Git.Branch
+import Git.History
+import qualified Types.Remote as Remote
+
+import qualified Data.Set as S
+
+newtype RemoteTrackingBranch = RemoteTrackingBranch
+	{ fromRemoteTrackingBranch :: Ref }
+	deriving (Show, Eq)
+
+{- Makes a remote tracking branch corresponding to a local branch. 
+ - Note that the local branch does not need to exist yet. -}
+mkRemoteTrackingBranch :: Remote -> Branch -> RemoteTrackingBranch
+mkRemoteTrackingBranch remote ref = RemoteTrackingBranch $
+	Git.Ref.underBase ("refs/remotes/" ++ Remote.name remote) ref
+
+{- Set remote tracking branch to point to a commit. -}
+setRemoteTrackingBranch :: RemoteTrackingBranch -> Sha -> Annex ()
+setRemoteTrackingBranch tb commit = 
+	inRepo $ Git.Branch.update' (fromRemoteTrackingBranch tb) commit
+
+{- Makes a merge commit that preserves the import history of the
+ - RemoteTrackingBranch, while grafting new git history into it.
+ -
+ - The second parent of the merge commit is the past history of the
+ - RemoteTrackingBranch as imported from a remote. When importing a
+ - history of trees from a remote, commits can be sythesized from
+ - them, but such commits won't have the same sha due to eg date differing.
+ - But since we know that the second parent consists entirely of such
+ - import commits, they can be reused when updating the
+ - RemoteTrackingBranch.
+ -}
+makeRemoteTrackingBranchMergeCommit :: RemoteTrackingBranch -> Sha -> Annex Sha
+makeRemoteTrackingBranchMergeCommit tb commitsha =
+	-- Check if the tracking branch exists.
+	inRepo (Git.Ref.sha (fromRemoteTrackingBranch tb)) >>= \case
+		Nothing -> return commitsha
+		Just _ -> inRepo (getHistoryToDepth 1 (fromRemoteTrackingBranch tb)) >>= \case
+			Nothing -> return commitsha
+			Just (History hc _) -> case historyCommitParents hc of
+				[_, importhistory] -> do
+					treesha <- maybe
+						(giveup $ "Unable to cat commit " ++ fromRef commitsha)
+						commitTree
+						<$> catCommit commitsha
+					makeRemoteTrackingBranchMergeCommit' commitsha importhistory treesha
+				-- Earlier versions of git-annex did not
+				-- make the merge commit, or perhaps
+				-- something else changed where the
+				-- tracking branch pointed.
+				_ -> return commitsha
+
+makeRemoteTrackingBranchMergeCommit' :: Sha -> Sha -> Sha -> Annex Sha
+makeRemoteTrackingBranchMergeCommit' commitsha importedhistory treesha = do
+	cmode <- annexCommitMode <$> Annex.getGitConfig
+	inRepo $ Git.Branch.commitTree
+			cmode
+			["remote tracking branch"]
+			[commitsha, importedhistory]
+			treesha
+
+{- When makeRemoteTrackingBranchMergeCommit was used, this finds the
+ - import history, starting from the second parent of the merge commit.
+ -}
+getRemoteTrackingBranchImportHistory :: History HistoryCommit -> Maybe (History HistoryCommit)
+getRemoteTrackingBranchImportHistory (History hc s) = 
+	case historyCommitParents hc of
+		[_, importhistory] -> go importhistory (S.toList s)
+		_ -> Nothing
+  where
+	go _ [] = Nothing
+	go i (h@(History hc' _):hs)
+		| historyCommit hc' == i = Just h
+		| otherwise = go i hs
diff --git a/Annex/ReplaceFile.hs b/Annex/ReplaceFile.hs
new file mode 100644
index 0000000000..21735eba14
--- /dev/null
+++ b/Annex/ReplaceFile.hs
@@ -0,0 +1,87 @@
+{- git-annex file replacing
+ -
+ - Copyright 2013-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Annex.ReplaceFile (
+	replaceGitAnnexDirFile,
+	replaceGitDirFile,
+	replaceWorkTreeFile,
+	replaceFile,
+	replaceFile',
+) where
+
+import Annex.Common
+import Annex.Tmp
+import Annex.Perms
+import Git
+import Utility.Tmp.Dir
+import Utility.Directory.Create
+#ifndef mingw32_HOST_OS
+import Utility.Path.Max
+#endif
+
+{- replaceFile on a file located inside the gitAnnexDir. -}
+replaceGitAnnexDirFile :: FilePath -> (RawFilePath -> Annex a) -> Annex a
+replaceGitAnnexDirFile = replaceFile createAnnexDirectory
+
+{- replaceFile on a file located inside the .git directory. -}
+replaceGitDirFile :: FilePath -> (RawFilePath -> Annex a) -> Annex a
+replaceGitDirFile = replaceFile $ \dir -> do
+	top <- fromRepo localGitDir
+	liftIO $ createDirectoryUnder [top] dir
+
+{- replaceFile on a worktree file. -}
+replaceWorkTreeFile :: FilePath -> (RawFilePath -> Annex a) -> Annex a
+replaceWorkTreeFile = replaceFile createWorkTreeDirectory
+
+{- Replaces a possibly already existing file with a new version, 
+ - atomically, by running an action.
+ - 
+ - The action is passed the name of temp file, in a temp directory, 
+ - which it can write to, and once done the temp file is moved into place
+ - and anything else in the temp directory is deleted.
+ -
+ - The action can throw an exception, in which case the temp directory
+ - will be deleted, and the existing file will be preserved.
+ -
+ - Throws an IO exception when it was unable to replace the file.
+ -
+ - The createdirectory action is only run when moving the file into place
+ - fails, and can create any parent directory structure needed.
+ -}
+replaceFile :: (RawFilePath -> Annex ()) -> FilePath -> (RawFilePath -> Annex a) -> Annex a
+replaceFile createdirectory file action = replaceFile' createdirectory file (const True) action
+
+replaceFile' :: (RawFilePath -> Annex ()) -> FilePath -> (a -> Bool) -> (RawFilePath -> Annex a) -> Annex a
+replaceFile' createdirectory file checkres action = withOtherTmp $ \othertmpdir -> do
+	let othertmpdir' = fromRawFilePath othertmpdir
+#ifndef mingw32_HOST_OS
+	-- Use part of the filename as the template for the temp
+	-- directory. This does not need to be unique, but it
+	-- makes it more clear what this temp directory is for.
+	filemax <- liftIO $ fileNameLengthLimit othertmpdir'
+	let basetmp = take (filemax `div` 2) (takeFileName file)
+#else
+	-- Windows has limits on the whole path length, so keep
+	-- it short.
+	let basetmp = "t"
+#endif
+	withTmpDirIn othertmpdir' basetmp $ \tmpdir -> do
+		let tmpfile = toRawFilePath (tmpdir </> basetmp)
+		r <- action tmpfile
+		when (checkres r) $
+			replaceFileFrom tmpfile (toRawFilePath file) createdirectory
+		return r
+
+replaceFileFrom :: RawFilePath -> RawFilePath -> (RawFilePath -> Annex ()) -> Annex ()
+replaceFileFrom src dest createdirectory = go `catchIO` fallback
+  where
+	go = liftIO $ moveFile src dest
+	fallback _ = do
+		createdirectory (parentDir dest)
+		go
diff --git a/Annex/SpecialRemote.hs b/Annex/SpecialRemote.hs
new file mode 100644
index 0000000000..2b23b06b5d
--- /dev/null
+++ b/Annex/SpecialRemote.hs
@@ -0,0 +1,135 @@
+{- git-annex special remote configuration
+ -
+ - Copyright 2011-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.SpecialRemote (
+	module Annex.SpecialRemote,
+	module Annex.SpecialRemote.Config
+) where
+
+import Annex.Common
+import Annex.SpecialRemote.Config
+import Types.Remote (RemoteConfig, SetupStage(..), typename, setup)
+import Types.GitConfig
+import Types.ProposedAccepted
+import Config
+import Remote.List
+import Logs.Remote
+import Logs.Trust
+import qualified Types.Remote as Remote
+import Git.Types (RemoteName)
+import Utility.SafeOutput
+
+import qualified Data.Map as M
+
+{- See if there's an existing special remote with this name.
+ -
+ - Remotes that are not dead come first in the list
+ - when a name appears multiple times. -}
+findExisting :: RemoteName -> Annex [(UUID, RemoteConfig, Maybe (ConfigFrom UUID))]
+findExisting name = do
+	(a, b) <- findExisting' name
+	return (a++b)
+
+{- Dead remotes with the name are in the second list, all others in the
+ - first list. -}
+findExisting' :: RemoteName -> Annex ([(UUID, RemoteConfig, Maybe (ConfigFrom UUID))], [(UUID, RemoteConfig, Maybe (ConfigFrom UUID))])
+findExisting' name = do
+	t <- trustMap
+	partition (\(u, _, _) -> M.lookup u t /= Just DeadTrusted)
+		. findByRemoteConfig (\c -> lookupName c == Just name)
+		<$> Logs.Remote.remoteConfigMap
+
+newConfig
+	:: RemoteName
+	-> Maybe (Sameas UUID)
+	-> RemoteConfig
+	-- ^ configuration provided by the user
+	-> M.Map UUID RemoteConfig
+	-- ^ configuration of other special remotes, to inherit from
+	-- when sameas is used
+	-> RemoteConfig
+newConfig name sameas fromuser m = case sameas of
+	Nothing -> M.insert nameField (Proposed name) fromuser
+	Just (Sameas u) -> addSameasInherited m $ M.fromList
+		[ (sameasNameField, Proposed name)
+		, (sameasUUIDField, Proposed (fromUUID u))
+		] `M.union` fromuser
+
+specialRemoteMap :: Annex (M.Map UUID RemoteName)
+specialRemoteMap = do
+	m <- Logs.Remote.remoteConfigMap
+	return $ specialRemoteNameMap m
+
+specialRemoteNameMap :: M.Map UUID RemoteConfig -> M.Map UUID RemoteName
+specialRemoteNameMap = M.fromList . mapMaybe go . M.toList
+  where
+	go (u, c) = case lookupName c of
+		Nothing -> Nothing
+		Just n -> Just (u, n)
+
+{- find the remote type -}
+findType :: RemoteConfig -> Either String RemoteType
+findType config = maybe unspecified (specified . fromProposedAccepted) $
+	M.lookup typeField config
+  where
+	unspecified = Left "Specify the type of remote with type="
+	specified s = case filter (findtype s) remoteTypes of
+		[] -> Left $ "Unknown remote type " ++ s 
+			++ " (pick from: "
+			++ intercalate " " (map typename remoteTypes)
+			++ ")"
+		(t:_) -> Right t
+	findtype s i = typename i == s
+
+autoEnable :: Annex ()
+autoEnable = do
+	m <- autoEnableable
+	enabled <- getenabledremotes
+	forM_ (M.toList m) $ \(cu, c) -> unless (cu `M.member` enabled) $ do
+		let u = case findSameasUUID c of
+			Just (Sameas u') -> u'
+			Nothing -> cu
+		case (lookupName c, findType c) of
+			-- Avoid auto-enabling when the name contains a
+			-- control character, because git does not avoid
+			-- displaying control characters in the name of a
+			-- remote, and an attacker could leverage
+			-- autoenabling it as part of an attack.
+			(Just name, Right t) | safeOutput name == name -> do
+				showSideAction $ UnquotedString $ "Auto enabling special remote " ++ name
+				dummycfg <- liftIO dummyRemoteGitConfig
+				tryNonAsync (setup t (AutoEnable c) (Just u) Nothing c dummycfg) >>= \case
+					Left e -> warning (UnquotedString (show e))
+					Right (_c, _u) ->
+						when (cu /= u) $
+							setConfig (remoteAnnexConfig c "config-uuid") (fromUUID cu)
+			_ -> return ()
+  where
+	getenabledremotes = M.fromList
+		. map (\r -> (getcu r, r))
+		<$> remoteList
+	getcu r = fromMaybe
+		(Remote.uuid r)
+		(remoteAnnexConfigUUID (Remote.gitconfig r))
+
+autoEnableable :: Annex (M.Map UUID RemoteConfig)
+autoEnableable = do
+	tm <- trustMap
+	(M.filterWithKey (notdead tm) . M.filter configured)
+		<$> remoteConfigMap
+  where
+	configured c = fromMaybe False $
+		trueFalseParser' . fromProposedAccepted
+			=<< M.lookup autoEnableField c
+	notdead tm cu c = 
+		let u = case findSameasUUID c of
+			Just (Sameas u') -> u'
+			Nothing -> cu
+		in lookupTrust' u tm /= DeadTrusted
+
diff --git a/Annex/SpecialRemote/Config.hs b/Annex/SpecialRemote/Config.hs
new file mode 100644
index 0000000000..fff2c88c1d
--- /dev/null
+++ b/Annex/SpecialRemote/Config.hs
@@ -0,0 +1,301 @@
+{- git-annex special remote configuration
+ -
+ - Copyright 2019-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-}
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module Annex.SpecialRemote.Config where
+
+import Common
+import Types.Remote (configParser)
+import Types
+import Types.UUID
+import Types.ProposedAccepted
+import Types.RemoteConfig
+import Types.GitConfig
+import Config.Cost
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import Text.Read
+import Data.Typeable
+import GHC.Stack
+
+newtype Sameas t = Sameas t
+	deriving (Show)
+
+newtype ConfigFrom t = ConfigFrom t
+	deriving (Show)
+
+{- The name of a configured remote is stored in its config using this key. -}
+nameField :: RemoteConfigField
+nameField = Accepted "name"
+
+{- The name of a sameas remote is stored using this key instead. 
+ - This prevents old versions of git-annex getting confused. -}
+sameasNameField :: RemoteConfigField
+sameasNameField = Accepted "sameas-name"
+
+lookupName :: RemoteConfig -> Maybe String
+lookupName c = fmap fromProposedAccepted $
+	M.lookup nameField c <|> M.lookup sameasNameField c
+
+instance RemoteNameable RemoteConfig where
+	getRemoteName c = fromMaybe "" (lookupName c)
+
+{- The uuid that a sameas remote is the same as is stored in this key. -}
+sameasUUIDField :: RemoteConfigField
+sameasUUIDField = Accepted "sameas-uuid"
+
+{- The type of a remote is stored in its config using this key. -}
+typeField :: RemoteConfigField
+typeField = Accepted "type"
+
+autoEnableField :: RemoteConfigField
+autoEnableField = Accepted "autoenable"
+
+costField :: RemoteConfigField
+costField = Accepted "cost"
+
+encryptionField :: RemoteConfigField
+encryptionField = Accepted "encryption"
+
+macField :: RemoteConfigField
+macField = Accepted "mac"
+
+cipherField :: RemoteConfigField
+cipherField = Accepted "cipher"
+
+cipherkeysField :: RemoteConfigField
+cipherkeysField = Accepted "cipherkeys"
+
+pubkeysField :: RemoteConfigField
+pubkeysField = Accepted "pubkeys"
+
+chunkField :: RemoteConfigField
+chunkField = Accepted "chunk"
+
+chunksizeField :: RemoteConfigField
+chunksizeField = Accepted "chunksize"
+
+embedCredsField :: RemoteConfigField
+embedCredsField = Accepted "embedcreds"
+
+preferreddirField :: RemoteConfigField
+preferreddirField = Accepted "preferreddir"
+
+exportTreeField :: RemoteConfigField
+exportTreeField = Accepted "exporttree"
+
+importTreeField :: RemoteConfigField
+importTreeField = Accepted "importtree"
+
+exportTree :: ParsedRemoteConfig -> Bool
+exportTree = fromMaybe False . getRemoteConfigValue exportTreeField
+
+importTree :: ParsedRemoteConfig -> Bool
+importTree = fromMaybe False . getRemoteConfigValue importTreeField
+
+{- Parsers for fields that are common to all special remotes. -}
+commonFieldParsers :: [RemoteConfigFieldParser]
+commonFieldParsers =
+	[ optionalStringParser nameField
+		(FieldDesc "name for the special remote")
+	, optionalStringParser sameasNameField HiddenField
+	, optionalStringParser sameasUUIDField HiddenField
+	, optionalStringParser typeField
+		(FieldDesc "type of special remote")
+	, autoEnableFieldParser
+	, costParser costField
+		(FieldDesc "default cost of this special remote")
+	, yesNoParser exportTreeField (Just False)
+		(FieldDesc "export trees of files to this remote")
+	, yesNoParser importTreeField (Just False)
+		(FieldDesc "import trees of files from this remote")
+	, optionalStringParser preferreddirField
+		(FieldDesc "directory whose content is preferred")
+	]
+
+autoEnableFieldParser :: RemoteConfigFieldParser
+autoEnableFieldParser = trueFalseParser autoEnableField (Just False)
+	(FieldDesc "automatically enable special remote")
+
+{- A remote with sameas-uuid set will inherit these values from the config
+ - of that uuid. These values cannot be overridden in the remote's config. -}
+sameasInherits :: S.Set RemoteConfigField
+sameasInherits = S.fromList
+	-- encryption configuration is necessarily the same for two
+	-- remotes that access the same data store
+	[ encryptionField
+	, macField
+	, cipherField
+	, cipherkeysField
+	, pubkeysField
+	-- legacy chunking was either enabled or not, so has to be the same
+	-- across configs for remotes that access the same data
+	, chunksizeField
+	-- (new-style chunking does not have that limitation)
+	-- but there is no benefit to picking a different chunk size
+	-- for the sameas remote, since it's reading whatever chunks were
+	-- stored
+	, chunkField
+	]
+
+{- Each RemoteConfig that has a sameas-uuid inherits some fields
+ - from it. Such fields can only be set by inheritance; the RemoteConfig
+ - cannot provide values from them. -}
+addSameasInherited :: M.Map UUID RemoteConfig -> RemoteConfig -> RemoteConfig
+addSameasInherited m c = case findSameasUUID c of
+	Nothing -> c
+	Just (Sameas sameasuuid) -> case M.lookup sameasuuid m of
+		Nothing -> c
+		Just parentc -> 
+			M.withoutKeys c sameasInherits			
+				`M.union`
+			M.restrictKeys parentc sameasInherits
+
+findSameasUUID :: RemoteConfig -> Maybe (Sameas UUID)
+findSameasUUID c = Sameas . toUUID . fromProposedAccepted
+	<$> M.lookup sameasUUIDField c
+
+{- Remove any fields inherited from a sameas-uuid. When storing a
+ - RemoteConfig, those fields don't get stored, since they were already
+ - inherited. -}
+removeSameasInherited :: RemoteConfig -> RemoteConfig
+removeSameasInherited c = case M.lookup sameasUUIDField c of
+	Nothing -> c
+	Just _ -> M.withoutKeys c sameasInherits
+
+{- Finds remote uuids with matching RemoteConfig. -}
+findByRemoteConfig :: (RemoteConfig -> Bool) -> M.Map UUID RemoteConfig -> [(UUID, RemoteConfig, Maybe (ConfigFrom UUID))]
+findByRemoteConfig matching = map sameasuuid . filter (matching . snd) . M.toList
+  where
+	sameasuuid (u, c) = case M.lookup sameasUUIDField c of
+		Nothing -> (u, c, Nothing)
+		Just u' -> (toUUID (fromProposedAccepted u'), c, Just (ConfigFrom u))
+
+{- Extracts a value from ParsedRemoteConfig. -}
+getRemoteConfigValue :: HasCallStack => Typeable v => RemoteConfigField -> ParsedRemoteConfig -> Maybe v
+getRemoteConfigValue f (ParsedRemoteConfig m _) = case M.lookup f m of
+	Just (RemoteConfigValue v) -> case cast v of
+		Just v' -> Just v'
+		Nothing -> error $ unwords
+			[ "getRemoteConfigValue"
+			, fromProposedAccepted f
+			, "found value of unexpected type"
+			, show (typeOf v) ++ "."
+			, "This is a bug in git-annex!"
+			]
+	Nothing -> Nothing
+
+{- Gets all fields that remoteConfigRestPassthrough matched. -}
+getRemoteConfigPassedThrough :: ParsedRemoteConfig -> M.Map RemoteConfigField String
+getRemoteConfigPassedThrough (ParsedRemoteConfig m _) = 
+	flip M.mapMaybe m $ \(RemoteConfigValue v) ->
+		case cast v of
+			Just (PassedThrough s) -> Just s
+			Nothing -> Nothing
+
+newtype PassedThrough = PassedThrough String
+
+parsedRemoteConfig :: RemoteType -> RemoteConfig -> Annex ParsedRemoteConfig
+parsedRemoteConfig t c = either (const emptycfg) id . parseRemoteConfig c 
+	<$> configParser t c
+  where
+	emptycfg = ParsedRemoteConfig mempty c
+
+parseRemoteConfig :: RemoteConfig -> RemoteConfigParser -> Either String ParsedRemoteConfig
+parseRemoteConfig c rpc =
+	go [] c (remoteConfigFieldParsers rpc ++ commonFieldParsers)
+  where
+	go l c' [] =
+		let (passover, leftovers) = partition
+			(maybe (const False) fst (remoteConfigRestPassthrough rpc) . fst)
+			(M.toList c')
+		    leftovers' = filter (notaccepted . fst) leftovers
+		in if not (null leftovers')
+			then Left $ "Unexpected parameters: " ++
+				unwords (map (fromProposedAccepted . fst) leftovers')
+			else
+				let m = M.fromList $
+					l ++ map (uncurry passthrough) passover
+				in Right (ParsedRemoteConfig m c)
+	go l c' (p:rest) = do
+		let f = parserForField p
+		(valueParser p) (M.lookup f c) c >>= \case
+			Just v -> go ((f,v):l) (M.delete f c') rest
+			Nothing -> go l (M.delete f c') rest
+	
+	passthrough f v = (f, RemoteConfigValue (PassedThrough (fromProposedAccepted v)))
+	
+	notaccepted (Proposed _) = True
+	notaccepted (Accepted _) = False
+
+optionalStringParser :: RemoteConfigField -> FieldDesc -> RemoteConfigFieldParser
+optionalStringParser f fielddesc = RemoteConfigFieldParser
+	{ parserForField = f 
+	, valueParser = p
+	, fieldDesc = fielddesc
+	, valueDesc = Nothing
+	}
+  where
+	p (Just v) _c = Right (Just (RemoteConfigValue (fromProposedAccepted v)))
+	p Nothing _c = Right Nothing
+
+yesNoParser :: RemoteConfigField -> Maybe Bool -> FieldDesc -> RemoteConfigFieldParser
+yesNoParser f mdef fd = genParser yesno f mdef fd
+	(Just (ValueDesc "yes or no"))
+  where
+	yesno "yes" = Just True
+	yesno "no" = Just False
+	yesno _ = Nothing
+
+trueFalseParser :: RemoteConfigField -> Maybe Bool -> FieldDesc -> RemoteConfigFieldParser
+trueFalseParser f mdef fd = genParser trueFalseParser' f mdef fd
+	(Just (ValueDesc "true or false"))
+
+-- Not using Git.Config.isTrueFalse because git supports
+-- a lot of other values for true and false in its configs,
+-- and this is not a git config and we want to avoid that mess.
+trueFalseParser' :: String -> Maybe Bool
+trueFalseParser' "true" = Just True
+trueFalseParser' "false" = Just False
+trueFalseParser' _ = Nothing
+
+costParser :: RemoteConfigField -> FieldDesc -> RemoteConfigFieldParser
+costParser f fd = genParser readcost f Nothing fd
+	(Just (ValueDesc "a number"))
+  where
+	readcost :: String -> Maybe Cost
+	readcost = readMaybe
+
+genParser
+	:: Typeable t
+	=> (String -> Maybe t)
+	-> RemoteConfigField
+	-> Maybe t -- ^ default if not configured
+	-> FieldDesc
+	-> Maybe ValueDesc
+	-> RemoteConfigFieldParser
+genParser parse f mdef fielddesc valuedesc = RemoteConfigFieldParser	
+	{ parserForField = f
+	, valueParser = p
+	, fieldDesc = fielddesc
+	, valueDesc = valuedesc
+	}
+  where
+	p Nothing _c = Right (fmap RemoteConfigValue mdef)
+	p (Just v) _c = case parse (fromProposedAccepted v) of
+		Just b -> Right (Just (RemoteConfigValue b))
+		Nothing -> case v of
+			Accepted _ -> Right (fmap RemoteConfigValue mdef)
+			Proposed _ -> Left $
+				"Bad value for " ++ fromProposedAccepted f ++
+				case valuedesc of
+					Just (ValueDesc vd) ->
+						" (expected " ++ vd ++ ")"
+					Nothing -> ""
diff --git a/Annex/Ssh.hs b/Annex/Ssh.hs
new file mode 100644
index 0000000000..e233e48b5a
--- /dev/null
+++ b/Annex/Ssh.hs
@@ -0,0 +1,480 @@
+{- git-annex ssh interface, with connection caching
+ -
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Annex.Ssh (
+	ConsumeStdin(..),
+	SshCommand,
+	sshCommand,
+	sshOptions,
+	sshCacheDir,
+	sshReadPort,
+	forceSshCleanup,
+	sshOptionsEnv,
+	sshOptionsTo,
+	inRepoWithSshOptionsTo,
+	runSshOptions,
+	sshAskPassEnv,
+	runSshAskPass
+) where
+
+import Annex.Common
+import Annex.LockFile
+import qualified BuildInfo
+import qualified Annex
+import qualified Git
+import qualified Git.Url
+import Config
+import Annex.Path
+import Utility.Env
+import Utility.Hash
+import Types.CleanupActions
+import Annex.Concurrent.Utility
+import Types.Concurrency
+import Git.Env
+import Git.Ssh
+import qualified Utility.RawFilePath as R
+import Annex.Perms
+#ifndef mingw32_HOST_OS
+import Annex.LockPool
+#endif
+
+import Control.Concurrent.STM
+import qualified Data.ByteString as S
+import qualified System.FilePath.ByteString as P
+
+{- Some ssh commands are fed stdin on a pipe and so should be allowed to
+ - consume it. But ssh commands that are not piped stdin should generally
+ - not be allowed to consume the process's stdin. -}
+data ConsumeStdin = ConsumeStdin | NoConsumeStdin
+
+{- Generates a command to ssh to a given host (or user@host) on a given
+ - port. This includes connection caching parameters, and any ssh-options.
+ - If GIT_SSH or GIT_SSH_COMMAND is enabled, they are used instead. -}
+sshCommand :: ConsumeStdin -> (SshHost, Maybe SshPort) -> RemoteGitConfig -> SshCommand -> Annex (FilePath, [CommandParam])
+sshCommand cs (host, port) gc remotecmd = ifM (liftIO safe_GIT_SSH)
+	( maybe go return
+		=<< liftIO (gitSsh' host port remotecmd (consumeStdinParams cs))
+	, go
+	)
+  where
+	go = do
+		ps <- sshOptions cs (host, port) gc []
+		return ("ssh", Param (fromSshHost host):ps++[Param remotecmd])
+
+{- Generates parameters to ssh to a given host (or user@host) on a given
+ - port. This includes connection caching parameters, and any
+ - ssh-options. Note that the host to ssh to and the command to run
+ - are not included in the returned options. -}
+sshOptions :: ConsumeStdin -> (SshHost, Maybe Integer) -> RemoteGitConfig -> [CommandParam] -> Annex [CommandParam]
+sshOptions cs (host, port) gc opts = go =<< sshCachingInfo (host, port)
+  where
+	go (Nothing, params) = return $ mkparams cs params
+	go (Just socketfile, params) = do
+		prepSocket socketfile host (mkparams NoConsumeStdin params)
+			
+		return $ mkparams cs params
+	mkparams cs' ps = concat
+		[ ps
+		, map Param (remoteAnnexSshOptions gc)
+		, opts
+		, portParams port
+		, consumeStdinParams cs'
+		, [Param "-T"]
+		]
+
+{- Due to passing -n to GIT_SSH and GIT_SSH_COMMAND, some settings
+ - of those that expect exactly git's parameters will break. So only
+ - use those if the user set GIT_ANNEX_USE_GIT_SSH to say it's ok. -}
+safe_GIT_SSH :: IO Bool
+safe_GIT_SSH = (== Just "1") <$> getEnv "GIT_ANNEX_USE_GIT_SSH"
+
+consumeStdinParams :: ConsumeStdin -> [CommandParam]
+consumeStdinParams ConsumeStdin = []
+consumeStdinParams NoConsumeStdin = [Param "-n"]
+
+{- Returns a filename to use for a ssh connection caching socket, and
+ - parameters to enable ssh connection caching. -}
+sshCachingInfo :: (SshHost, Maybe Integer) -> Annex (Maybe FilePath, [CommandParam])
+sshCachingInfo (host, port) = go =<< sshCacheDir'
+  where
+	go (Right dir) =
+		liftIO (bestSocketPath $ dir P.</> hostport2socket host port) >>= return . \case
+			Nothing -> (Nothing, [])
+			Just socketfile -> 
+				let socketfile' = fromRawFilePath socketfile
+				in (Just socketfile', sshConnectionCachingParams socketfile')
+	-- No connection caching with concurrency is not a good
+	-- combination, so warn the user.
+	go (Left whynocaching) = do
+		getConcurrency >>= \case
+                	NonConcurrent -> return ()
+			Concurrent {} -> warnnocaching whynocaching
+			ConcurrentPerCpu -> warnnocaching whynocaching
+		return (Nothing, [])
+	
+	warnnocaching whynocaching =
+		whenM (annexAdviceNoSshCaching <$> Annex.getGitConfig) $ do
+			warning $ UnquotedString nocachingwarning
+			warning $ UnquotedString whynocaching
+	
+	nocachingwarning = unwords
+		[ "You have enabled concurrency, but git-annex is not able"
+		, "to use ssh connection caching. This may result in"
+		, "multiple ssh processes prompting for passwords at the"
+		, "same time."
+		]
+
+{- Given an absolute path to use for a socket file,
+ - returns whichever is shorter of that or the relative path to the same
+ - file.
+ -
+ - If no path can be constructed that is a valid socket, returns Nothing. -}
+bestSocketPath :: RawFilePath -> IO (Maybe RawFilePath)
+bestSocketPath abssocketfile = do
+	relsocketfile <- liftIO $ relPathCwdToFile abssocketfile
+	let socketfile = if S.length abssocketfile <= S.length relsocketfile
+		then abssocketfile
+		else relsocketfile
+	return $ if valid_unix_socket_path socketfile sshgarbagelen
+			then Just socketfile
+			else Nothing
+  where
+	-- ssh appends a 16 char extension to the socket when setting it
+	-- up, which needs to be taken into account when checking
+	-- that a valid socket was constructed.
+	sshgarbagelen = 1+16
+
+sshConnectionCachingParams :: FilePath -> [CommandParam]
+sshConnectionCachingParams socketfile = 
+	[ Param "-S", Param socketfile
+	, Param "-o", Param "ControlMaster=auto"
+	, Param "-o", Param "ControlPersist=yes"
+	]
+
+sshSocketDirEnv :: String
+sshSocketDirEnv = "GIT_ANNEX_SSH_SOCKET_DIR"
+
+{- Returns the directory where ssh connection caching sockets can be
+ - stored.
+ - 
+ - The directory will be created if it does not exist.
+ -}
+sshCacheDir :: Annex (Maybe RawFilePath)
+sshCacheDir = eitherToMaybe <$> sshCacheDir'
+
+sshCacheDir' :: Annex (Either String RawFilePath)
+sshCacheDir' = 
+	ifM (fromMaybe BuildInfo.sshconnectioncaching . annexSshCaching <$> Annex.getGitConfig)
+		( ifM crippledFileSystem
+			( gettmpdir >>= \case
+				Nothing ->
+					return (Left crippledfswarning)
+				Just tmpdir -> 
+					liftIO $ catchMsgIO $
+						usetmpdir tmpdir
+			, do
+				d <- fromRepo gitAnnexSshDir
+				createAnnexDirectory d
+				return (Right d)
+			)
+		, return (Left "annex.sshcaching is not set to true")
+		)
+  where
+	gettmpdir = liftIO $ getEnv sshSocketDirEnv
+
+	usetmpdir tmpdir = do
+		let socktmp = tmpdir </> "ssh"
+		createDirectoryIfMissing True socktmp
+		return (toRawFilePath socktmp)
+	
+	crippledfswarning = unwords
+		[ "This repository is on a crippled filesystem, so unix named"
+		, "pipes probably don't work, and ssh connection caching"
+		, "relies on those. One workaround is to set"
+		, sshSocketDirEnv
+		, "to point to a directory on a non-crippled filesystem."
+		]
+
+portParams :: Maybe Integer -> [CommandParam]
+portParams Nothing = []
+portParams (Just port) = [Param "-p", Param $ show port]
+
+{- Prepare to use a socket file for ssh connection caching.
+ -
+ - When concurrency is enabled, this blocks until a ssh connection
+ - has been made to the host. So, any password prompting by ssh will
+ - happen in this call, and only one ssh process will prompt at a time.
+ -
+ - Locks the socket lock file to prevent other git-annex processes from
+ - stopping the ssh multiplexer on this socket.
+ -}
+prepSocket :: FilePath -> SshHost -> [CommandParam] -> Annex ()
+prepSocket socketfile sshhost sshparams = do
+	-- There could be stale ssh connections hanging around
+	-- from a previous git-annex run that was interrupted.
+	-- This must run only once, before we have made any ssh connection,
+	-- and any other prepSocket calls must block while it's run.
+	tv <- Annex.getRead Annex.sshstalecleaned
+	join $ liftIO $ atomically $ do
+		cleaned <- takeTMVar tv
+		if cleaned
+			then do
+				putTMVar tv cleaned
+				return noop
+			else return $ do
+				sshCleanup
+				liftIO $ atomically $ putTMVar tv True
+	-- Cleanup at shutdown.
+	Annex.addCleanupAction SshCachingCleanup sshCleanup
+	
+	let socketlock = socket2lock socketfile
+
+	getConcurrency >>= \case
+		NonConcurrent -> return ()
+		Concurrent {} -> makeconnection socketlock
+		ConcurrentPerCpu -> makeconnection socketlock
+	
+	lockFileCached socketlock
+  where
+	-- When the LockCache already has the socketlock in it,
+	-- the connection has already been started. Otherwise,
+	-- get the connection started now.
+	makeconnection socketlock = debugLocks $
+		whenM (isNothing <$> fromLockCache socketlock) $
+			-- See if ssh can connect in batch mode,
+			-- if so there's no need to block for a password
+			-- prompt.
+			unlessM (tryssh ["-o", "BatchMode=true"]) $
+				-- ssh needs to prompt (probably)
+				-- If the user enters the wrong password,
+				-- ssh will tell them, so we can ignore
+				-- failure.
+				void $ prompt $ tryssh []
+	-- Try to ssh to the host quietly. Returns True if ssh apparently
+	-- connected to the host successfully. If ssh failed to connect,
+	-- returns False.
+	-- Even if ssh is forced to run some specific command, this will
+	-- return True.
+	-- (Except there's an unlikely false positive where a forced
+	-- ssh command exits 255.)
+	tryssh extraps = liftIO $ withNullHandle $ \nullh -> do
+		let p = (proc "ssh" $ concat
+			[ extraps
+			, toCommand sshparams
+			, [fromSshHost sshhost, "true"]
+			])
+			{ std_out = UseHandle nullh
+			, std_err = UseHandle nullh
+			}
+		withCreateProcess p $ \_ _ _ pid -> do
+			exitcode <- waitForProcess pid
+			return $ case exitcode of
+				ExitFailure 255 -> False
+				_ -> True
+
+{- Find ssh socket files.
+ -
+ - The check that the lock file exists makes only socket files
+ - that were set up by prepSocket be found. On some NFS systems,
+ - a deleted socket file may linger for a while under another filename;
+ - and this check makes such files be skipped since the corresponding lock
+ - file won't exist.
+ -}
+enumSocketFiles :: Annex [FilePath]
+enumSocketFiles = liftIO . go =<< sshCacheDir
+  where
+	go Nothing = return []
+	go (Just dir) = filterM (R.doesPathExist . socket2lock)
+		=<< filter (not . isLock)
+		<$> catchDefaultIO [] (dirContents (fromRawFilePath dir))
+
+{- Stop any unused ssh connection caching processes. -}
+sshCleanup :: Annex ()
+sshCleanup = mapM_ cleanup =<< enumSocketFiles
+  where
+	cleanup socketfile = do
+#ifndef mingw32_HOST_OS
+		-- Drop any shared lock we have, and take an
+		-- exclusive lock, without blocking. If the lock
+		-- succeeds, nothing is using this ssh, and it can
+		-- be stopped.
+		--
+		-- After ssh is stopped cannot remove the lock file;
+		-- other processes may be waiting on our exclusive
+		-- lock to use it.
+		let lockfile = socket2lock socketfile
+		unlockFile lockfile
+		mode <- annexFileMode
+		tryLockExclusive (Just mode) lockfile >>= \case
+			Nothing -> noop
+			Just lck -> do
+				forceStopSsh socketfile
+				liftIO $ dropLock lck
+#else
+		forceStopSsh socketfile
+#endif
+
+{- Stop all ssh connection caching processes, even when they're in use. -}
+forceSshCleanup :: Annex ()
+forceSshCleanup = mapM_ forceStopSsh =<< enumSocketFiles
+
+forceStopSsh :: FilePath -> Annex ()
+forceStopSsh socketfile = withNullHandle $ \nullh -> do
+	let (dir, base) = splitFileName socketfile
+	let p = (proc "ssh" $ toCommand $
+		[ Param "-O", Param "stop" ] ++ 
+		sshConnectionCachingParams base ++ 
+		[Param "localhost"])
+		{ cwd = Just dir
+		-- "ssh -O stop" is noisy on stderr even with -q
+		, std_out = UseHandle nullh
+		, std_err = UseHandle nullh
+		}
+	void $ liftIO $ catchMaybeIO $ withCreateProcess p $ \_ _ _ pid ->
+		forceSuccessProcess p pid
+	liftIO $ removeWhenExistsWith R.removeLink (toRawFilePath socketfile)
+
+{- This needs to be as short as possible, due to limitations on the length
+ - of the path to a socket file. At the same time, it needs to be unique
+ - for each host.
+ -}
+hostport2socket :: SshHost -> Maybe Integer -> RawFilePath
+hostport2socket host Nothing = hostport2socket' $ fromSshHost host
+hostport2socket host (Just port) = hostport2socket' $
+	fromSshHost host ++ "!" ++ show port
+hostport2socket' :: String -> RawFilePath
+hostport2socket' s
+	| length s > lengthofmd5s = toRawFilePath $ show $ md5 $ encodeBL s
+	| otherwise = toRawFilePath s
+  where
+	lengthofmd5s = 32
+
+socket2lock :: FilePath -> RawFilePath
+socket2lock socket = toRawFilePath (socket ++ lockExt)
+
+isLock :: FilePath -> Bool
+isLock f = lockExt `isSuffixOf` f
+
+lockExt :: String
+lockExt = ".lock"
+
+{- This is the size of the sun_path component of sockaddr_un, which
+ - is the limit to the total length of the filename of a unix socket.
+ -
+ - On Linux, this is 108. On OSX, 104. TODO: Probe
+ -}
+sizeof_sockaddr_un_sun_path :: Int
+sizeof_sockaddr_un_sun_path = 100
+
+{- Note that this looks at the true length of the path in bytes, as it will
+ - appear on disk. -}
+valid_unix_socket_path :: RawFilePath -> Int -> Bool
+valid_unix_socket_path f n = S.length f + n < sizeof_sockaddr_un_sun_path
+
+{- Parses the SSH port, and returns the other OpenSSH options. If
+ - several ports are found, the last one takes precedence. -}
+sshReadPort :: [String] -> (Maybe Integer, [String])
+sshReadPort params = (port, reverse args)
+  where
+	(port,args) = aux (Nothing, []) params
+	aux (p,ps) [] = (p,ps)
+	aux (_,ps) ("-p":p:rest) = aux (readPort p, ps) rest
+	aux (p,ps) (q:rest) | "-p" `isPrefixOf` q = aux (readPort $ drop 2 q, ps) rest
+			    | otherwise = aux (p,q:ps) rest
+	readPort p = fmap fst $ listToMaybe $ reads p
+
+{- When this env var is set, git-annex runs ssh with the specified
+ - options. (The options are separated by newlines.)
+ -
+ - This is a workaround for GIT_SSH not being able to contain
+ - additional parameters to pass to ssh. (GIT_SSH_COMMAND can,
+ - but is not supported by older versions of git.) -}
+sshOptionsEnv :: String
+sshOptionsEnv = "GIT_ANNEX_SSHOPTION"
+
+toSshOptionsEnv :: [CommandParam] -> String
+toSshOptionsEnv = unlines . toCommand
+
+fromSshOptionsEnv :: String -> [CommandParam]
+fromSshOptionsEnv = map Param . lines
+
+{- Enables ssh caching for git push/pull to a particular
+ - remote git repo. (Can safely be used on non-ssh remotes.)
+ -
+ - Also propigates any configured ssh-options.
+ -
+ - Like inRepo, the action is run with the local git repo.
+ - But here it's a modified version, with gitEnv to set GIT_SSH=git-annex,
+ - and sshOptionsEnv set so that git-annex will know what socket
+ - file to use. -}
+inRepoWithSshOptionsTo :: Git.Repo -> RemoteGitConfig -> (Git.Repo -> IO a) -> Annex a
+inRepoWithSshOptionsTo remote gc a =
+	liftIO . a =<< sshOptionsTo remote gc =<< gitRepo
+
+{- To make any git commands be run with ssh caching enabled,
+ - and configured ssh-options alters the local Git.Repo's gitEnv
+ - to set GIT_SSH=git-annex, and set sshOptionsEnv when running git
+ - commands.
+ -
+ - If GIT_SSH or GIT_SSH_COMMAND are enabled, this has no effect. -}
+sshOptionsTo :: Git.Repo -> RemoteGitConfig -> Git.Repo -> Annex Git.Repo
+sshOptionsTo remote gc localr
+	| not (Git.repoIsUrl remote) || Git.repoIsHttp remote = unchanged
+	| otherwise = case Git.Url.hostuser remote of
+		Nothing -> unchanged
+		Just host -> ifM (liftIO $ safe_GIT_SSH <&&> gitSshEnvSet)
+			( unchanged
+			, do
+				let port = Git.Url.port remote
+				let sshhost = either giveup id (mkSshHost host)
+				(msockfile, cacheparams) <- sshCachingInfo (sshhost, port)
+				case msockfile of
+					Nothing -> use []
+					Just sockfile -> do
+						prepSocket sockfile sshhost $ concat
+							[ cacheparams
+							, map Param (remoteAnnexSshOptions gc)
+							, portParams port
+							, consumeStdinParams NoConsumeStdin
+							, [Param "-T"]
+							]
+						use cacheparams
+			)
+  where
+	unchanged = return localr
+
+	use opts = do
+		let sshopts = concat
+			[ opts
+			, map Param (remoteAnnexSshOptions gc)
+			]
+		if null sshopts
+			then unchanged
+			else do
+				command <- liftIO programPath
+				liftIO $ do
+					localr' <- addGitEnv localr sshOptionsEnv
+						(toSshOptionsEnv sshopts)
+					addGitEnv localr' gitSshEnv command
+
+runSshOptions :: [String] -> String -> IO ()
+runSshOptions args s = do
+	let args' = toCommand (fromSshOptionsEnv s) ++ args
+	let p = proc "ssh" args'
+	exitcode <- withCreateProcess p $ \_ _ _ pid -> waitForProcess pid
+	exitWith exitcode
+
+{- When this env var is set, git-annex is being used as a ssh-askpass
+ - program, and should read the password from the specified location,
+ - and output it for ssh to read. -}
+sshAskPassEnv :: String
+sshAskPassEnv = "GIT_ANNEX_SSHASKPASS"
+
+runSshAskPass :: FilePath -> IO ()
+runSshAskPass passfile = putStrLn =<< readFile passfile
diff --git a/Annex/StallDetection.hs b/Annex/StallDetection.hs
new file mode 100644
index 0000000000..9b885c2ecf
--- /dev/null
+++ b/Annex/StallDetection.hs
@@ -0,0 +1,154 @@
+{- Stall detection for transfers.
+ -
+ - Copyright 2020-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.StallDetection (
+	getStallDetection,
+	detectStalls,
+	StallDetection,
+) where
+
+import Annex.Common
+import Types.StallDetection
+import Types.Direction
+import Types.Remote (gitconfig)
+import Utility.Metered
+import Utility.HumanTime
+import Utility.DataUnits
+import Utility.ThreadScheduler
+
+import Control.Concurrent.STM
+import Control.Monad.IO.Class (MonadIO)
+import Data.Time.Clock
+
+getStallDetection :: Direction -> Remote -> Maybe StallDetection
+getStallDetection Download r = 
+	remoteAnnexStallDetectionDownload (gitconfig r)
+		<|> remoteAnnexStallDetection (gitconfig r)
+getStallDetection Upload r =
+	remoteAnnexStallDetectionUpload (gitconfig r)
+		<|> remoteAnnexStallDetection (gitconfig r)
+
+{- This may be safely canceled (with eg uninterruptibleCancel),
+ - as long as the passed action can be safely canceled. -}
+detectStalls :: (Monad m, MonadIO m) => Maybe StallDetection -> TVar (Maybe BytesProcessed) -> m () -> m ()
+detectStalls Nothing _ _ = noop
+detectStalls (Just StallDetectionDisabled) _ _ = noop
+detectStalls (Just (StallDetection bwrate@(BwRate _minsz duration))) metervar onstall = do
+	-- If the progress is being updated, but less frequently than
+	-- the specified duration, a stall would be incorrectly detected.
+	--
+	-- For example, consider the case of a remote that does
+	-- not support progress updates, but is chunked with a large chunk
+	-- size. In that case, progress is only updated after each chunk.
+	--
+	-- So, wait for the first update, and see how long it takes.
+	-- When it's longer than the duration (or close to it), 
+	-- upscale the duration and minsz accordingly.
+	starttime <- liftIO getCurrentTime
+	v <- waitforfirstupdate =<< readMeterVar metervar
+	endtime <- liftIO getCurrentTime
+	let timepassed = floor (endtime `diffUTCTime` starttime)
+	let BwRate scaledminsz scaledduration = upscale bwrate timepassed
+	detectStalls' scaledminsz scaledduration metervar onstall v
+  where
+	minwaitsecs = Seconds $
+		min 60 (fromIntegral (durationSeconds duration))
+	waitforfirstupdate startval = do
+		liftIO $ threadDelaySeconds minwaitsecs
+		v <- readMeterVar metervar
+		if v > startval
+			then return v
+			else waitforfirstupdate startval
+detectStalls (Just ProbeStallDetection) metervar onstall = do
+	-- Only do stall detection once the progress is confirmed to be
+	-- consistently updating. After the first update, it needs to
+	-- advance twice within 30 seconds. With that established,
+	-- if no data at all is sent for a 60 second period, it's
+	-- assumed to be a stall.
+	v <- readMeterVar metervar >>= waitforfirstupdate
+	ontimelyadvance v $ \v' -> ontimelyadvance v' $
+		detectStalls' 1 duration metervar onstall
+  where
+	duration = Duration 60
+
+	delay = Seconds (fromIntegral (durationSeconds duration) `div` 2)
+	
+	waitforfirstupdate startval = do
+		liftIO $ threadDelaySeconds delay
+		v <- readMeterVar metervar
+		if v > startval
+			then return v
+			else waitforfirstupdate startval
+
+	ontimelyadvance v cont = do
+		liftIO $ threadDelaySeconds delay
+		v' <- readMeterVar metervar
+		when (v' > v) $
+			cont v'
+
+detectStalls'
+	:: (Monad m, MonadIO m)
+	=> ByteSize
+	-> Duration
+	-> TVar (Maybe BytesProcessed)
+	-> m ()
+	-> Maybe ByteSize
+	-> m ()
+detectStalls' minsz duration metervar onstall st = do
+	liftIO $ threadDelaySeconds delay
+	-- Get whatever progress value was reported most recently, if any.
+	v <- readMeterVar metervar
+	let cont = detectStalls' minsz duration metervar onstall v
+	case (st, v) of
+		(Nothing, _) -> cont
+		(_, Nothing) -> cont
+		(Just prev, Just sofar)
+			-- Just in case a progress meter somehow runs
+			-- backwards, or a second progress meter was
+			-- started and is at a smaller value than
+			-- the previous one.
+			| prev > sofar -> cont
+			| sofar - prev < minsz -> onstall
+			| otherwise -> cont
+  where
+	delay = Seconds (fromIntegral (durationSeconds duration))
+
+readMeterVar
+	:: MonadIO m
+	=> TVar (Maybe BytesProcessed)
+	-> m (Maybe ByteSize)
+readMeterVar metervar = liftIO $ atomically $ 
+	fmap fromBytesProcessed <$> readTVar metervar
+
+-- Scale up the minsz and duration to match the observed time that passed
+-- between progress updates. This allows for some variation in the transfer
+-- rate causing later progress updates to happen less frequently.
+upscale :: BwRate -> Integer -> BwRate
+upscale input@(BwRate minsz duration) timepassedsecs
+	| timepassedsecs > dsecs `div` allowedvariation = BwRate 
+		(ceiling (fromIntegral minsz * scale))
+		(Duration (ceiling (fromIntegral dsecs * scale)))
+	| otherwise = input
+  where
+	scale = max (1 :: Double) $
+		(fromIntegral timepassedsecs / fromIntegral (max dsecs 1))
+		* fromIntegral allowedvariation
+	
+	dsecs = durationSeconds duration
+
+	-- Setting this too low will make normal bandwidth variations be
+	-- considered to be stalls, while setting it too high will make
+	-- stalls not be detected for much longer than the expected
+	-- duration.
+	--
+	-- For example, a BwRate of 20MB/1m, when the first progress
+	-- update takes 10m to arrive, is scaled to 600MB/30m. That 30m
+	-- is a reasonable since only 3 chunks get sent in that amount of
+	-- time at that rate. If allowedvariation = 10, that would
+	-- be 2000MB/100m, which seems much too long to wait to detect a
+	-- stall.
+	allowedvariation = 3
diff --git a/Annex/TaggedPush.hs b/Annex/TaggedPush.hs
new file mode 100644
index 0000000000..d728678e9a
--- /dev/null
+++ b/Annex/TaggedPush.hs
@@ -0,0 +1,68 @@
+{- git-annex tagged pushes
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.TaggedPush where
+
+import Annex.Common
+import qualified Remote
+import qualified Annex.Branch
+import qualified Git
+import qualified Git.Ref
+import qualified Git.Command
+import qualified Git.Branch
+import Utility.Base64
+
+import qualified Data.ByteString as S
+
+{- Converts a git branch into a branch that is tagged with a UUID, typically
+ - the UUID of the repo that will be pushing it, and possibly with other
+ - information.
+ -
+ - Pushing to branches on the remote that have our uuid in them is ugly,
+ - but it reserves those branches for pushing by us, and so our pushes will
+ - never conflict with other pushes.
+ -
+ - To avoid cluttering up the branch display, the branch is put under
+ - refs/synced/, rather than the usual refs/remotes/
+ -
+ - Both UUIDs and Base64 encoded data are always legal to be used in git
+ - refs, per git-check-ref-format.
+ -}
+toTaggedBranch :: UUID -> Maybe String -> Git.Branch -> Git.Ref
+toTaggedBranch u info b = Git.Ref $ S.intercalate "/" $ catMaybes
+	[ Just "refs/synced"
+	, Just $ fromUUID u
+	, toB64 . encodeBS <$> info
+	, Just $ Git.fromRef' $ Git.Ref.base b
+	]
+
+fromTaggedBranch :: Git.Ref -> Maybe (UUID, Maybe S.ByteString)
+fromTaggedBranch b = case splitc '/' $ Git.fromRef b of
+	("refs":"synced":u:info:_base) ->
+		Just (toUUID u, fromB64Maybe (encodeBS info))
+	("refs":"synced":u:_base) ->
+		Just (toUUID u, Nothing)
+	_ -> Nothing
+
+listTaggedBranches :: Annex [(Git.Sha, Git.Ref)]
+listTaggedBranches = filter (isJust . fromTaggedBranch . snd)
+	<$> inRepo Git.Ref.list
+
+taggedPush :: UUID -> Maybe String -> Git.Ref -> Remote -> Git.Repo -> IO Bool
+taggedPush u info branch remote = Git.Command.runBool
+	[ Param "push"
+	, Param $ Remote.name remote
+	{- Using forcePush here is safe because we "own" the tagged branch
+	 - we're pushing; it has no other writers. Ensures it is pushed
+	 - even if it has been rewritten by a transition. -}
+	, Param $ Git.Branch.forcePush $ refspec Annex.Branch.name
+	, Param $ refspec branch
+	]
+  where
+	refspec b = Git.fromRef b ++ ":" ++ Git.fromRef (toTaggedBranch u info b)
diff --git a/Annex/Tmp.hs b/Annex/Tmp.hs
new file mode 100644
index 0000000000..2bbebd6388
--- /dev/null
+++ b/Annex/Tmp.hs
@@ -0,0 +1,74 @@
+{- git-annex tmp files
+ -
+ - Copyright 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.Tmp where
+
+import Annex.Common
+import qualified Annex
+import Annex.LockFile
+import Annex.Perms
+import Types.CleanupActions
+import qualified Utility.RawFilePath as R
+
+import Data.Time.Clock.POSIX
+import System.PosixCompat.Files (modificationTime)
+
+-- | For creation of tmp files, other than for key's contents.
+--
+-- The action should normally clean up whatever files it writes to the temp
+-- directory that is passed to it. However, once the action is done,
+-- any files left in that directory may be cleaned up by another process at
+-- any time.
+withOtherTmp :: (RawFilePath -> Annex a) -> Annex a
+withOtherTmp a = do
+	Annex.addCleanupAction OtherTmpCleanup cleanupOtherTmp
+	tmpdir <- fromRepo gitAnnexTmpOtherDir
+	tmplck <- fromRepo gitAnnexTmpOtherLock
+	withSharedLock tmplck $ do
+		void $ createAnnexDirectory tmpdir
+		a tmpdir
+
+-- | This uses an alternate temp directory. The action should normally
+-- clean up whatever files it writes there, but if it leaves files
+-- there (perhaps due to being interrupted), the files will be eventually
+-- cleaned up by another git-annex process (after they're a week old).
+--
+-- Unlike withOtherTmp, this does not rely on locking working.
+-- Its main use is in situations where the state of lockfile is not
+-- determined yet, eg during initialization.
+withEventuallyCleanedOtherTmp :: (RawFilePath -> Annex a) -> Annex a
+withEventuallyCleanedOtherTmp = bracket setup cleanup
+  where
+	setup = do
+		tmpdir <- fromRepo gitAnnexTmpOtherDirOld
+		void $ createAnnexDirectory tmpdir
+		return tmpdir
+	cleanup = liftIO . void . tryIO . removeDirectory . fromRawFilePath
+
+-- | Cleans up any tmp files that were left by a previous
+-- git-annex process that got interrupted or failed to clean up after
+-- itself for some other reason.
+--
+-- Does not do anything if withOtherTmp is running.
+cleanupOtherTmp :: Annex ()
+cleanupOtherTmp = do
+	tmplck <- fromRepo gitAnnexTmpOtherLock
+	void $ tryIO $ tryExclusiveLock tmplck $ do
+		tmpdir <- fromRawFilePath <$> fromRepo gitAnnexTmpOtherDir
+		void $ liftIO $ tryIO $ removeDirectoryRecursive tmpdir
+		oldtmp <- fromRawFilePath <$> fromRepo gitAnnexTmpOtherDirOld
+		liftIO $ mapM_ cleanold
+			=<< emptyWhenDoesNotExist (dirContentsRecursive oldtmp)
+		liftIO $ void $ tryIO $ removeDirectory oldtmp -- when empty
+  where
+	cleanold f = do
+		now <- liftIO getPOSIXTime
+		let oldenough = now - (60 * 60 * 24 * 7)
+		catchMaybeIO (modificationTime <$> R.getSymbolicLinkStatus (toRawFilePath f)) >>= \case
+			Just mtime | realToFrac mtime <= oldenough -> 
+				void $ tryIO $ removeWhenExistsWith R.removeLink (toRawFilePath f)
+			_ -> return ()
diff --git a/Annex/Transfer.hs b/Annex/Transfer.hs
new file mode 100644
index 0000000000..4235dfcd8d
--- /dev/null
+++ b/Annex/Transfer.hs
@@ -0,0 +1,443 @@
+{- git-annex transfers
+ -
+ - Copyright 2012-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP, BangPatterns, OverloadedStrings #-}
+
+module Annex.Transfer (
+	module X,
+	upload,
+	upload',
+	alwaysUpload,
+	download,
+	download',
+	runTransfer,
+	alwaysRunTransfer,
+	noRetry,
+	stdRetry,
+	pickRemote,
+) where
+
+import Annex.Common
+import qualified Annex
+import Logs.Transfer as X
+import Types.Transfer as X
+import Annex.Notification as X
+import Annex.Content
+import Annex.Perms
+import Annex.Action
+import Utility.Metered
+import Utility.ThreadScheduler
+import Utility.FileMode
+import Annex.LockPool
+import Types.Key
+import qualified Types.Remote as Remote
+import qualified Types.Backend
+import Types.Concurrency
+import Annex.Concurrent
+import Types.WorkerPool
+import Annex.WorkerPool
+import Annex.TransferrerPool
+import Annex.StallDetection
+import Backend (isCryptographicallySecureKey)
+import Types.StallDetection
+import qualified Utility.RawFilePath as R
+
+import Control.Concurrent
+import Control.Concurrent.Async
+import Control.Concurrent.STM hiding (retry)
+import qualified Data.Map.Strict as M
+import qualified System.FilePath.ByteString as P
+import Data.Ord
+
+-- Upload, supporting canceling detected stalls.
+upload :: Remote -> Key -> AssociatedFile -> RetryDecider -> NotifyWitness -> Annex Bool
+upload r key f d witness = 
+	case getStallDetection Upload r of
+		Nothing -> go (Just ProbeStallDetection)
+		Just StallDetectionDisabled -> go Nothing
+		Just sd -> runTransferrer sd r key f d Upload witness
+  where
+ 	go sd = upload' (Remote.uuid r) key f sd d (action . Remote.storeKey r key f) witness
+
+-- Upload, not supporting canceling detected stalls
+upload' :: Observable v => UUID -> Key -> AssociatedFile -> Maybe StallDetection -> RetryDecider -> (MeterUpdate -> Annex v) -> NotifyWitness -> Annex v
+upload' u key f sd d a _witness = guardHaveUUID u $ 
+	runTransfer (Transfer Upload u (fromKey id key)) Nothing f sd d a
+
+alwaysUpload :: Observable v => UUID -> Key -> AssociatedFile -> Maybe StallDetection -> RetryDecider -> (MeterUpdate -> Annex v) -> NotifyWitness -> Annex v
+alwaysUpload u key f sd d a _witness = guardHaveUUID u $ 
+	alwaysRunTransfer (Transfer Upload u (fromKey id key)) Nothing f sd d a
+
+-- Download, supporting canceling detected stalls.
+download :: Remote -> Key -> AssociatedFile -> RetryDecider -> NotifyWitness -> Annex Bool
+download r key f d witness = 
+	case getStallDetection Download r of
+		Nothing -> go (Just ProbeStallDetection)
+		Just StallDetectionDisabled -> go Nothing
+		Just sd -> runTransferrer sd r key f d Download witness
+  where
+	go sd = getViaTmp (Remote.retrievalSecurityPolicy r) vc key f Nothing $ \dest ->
+		download' (Remote.uuid r) key f sd d (go' dest) witness
+	go' dest p = verifiedAction $
+		Remote.retrieveKeyFile r key f (fromRawFilePath dest) p vc
+	vc = Remote.RemoteVerify r
+
+-- Download, not supporting canceling detected stalls.
+download' :: Observable v => UUID -> Key -> AssociatedFile -> Maybe StallDetection -> RetryDecider -> (MeterUpdate -> Annex v) -> NotifyWitness -> Annex v
+download' u key f sd d a _witness = guardHaveUUID u $
+	runTransfer (Transfer Download u (fromKey id key)) Nothing f sd d a
+
+guardHaveUUID :: Observable v => UUID -> Annex v -> Annex v
+guardHaveUUID u a
+	| u == NoUUID = return observeFailure
+	| otherwise = a
+
+{- Runs a transfer action. Creates and locks the lock file while the
+ - action is running, and stores info in the transfer information
+ - file.
+ -
+ - If the transfer action returns False, the transfer info is 
+ - left in the failedTransferDir.
+ -
+ - If the transfer is already in progress, returns False.
+ -
+ - An upload can be run from a read-only filesystem, and in this case
+ - no transfer information or lock file is used.
+ -
+ - Cannot cancel stalls, but when a likely stall is detected, 
+ - suggests to the user that they enable stall detection handling.
+ -}
+runTransfer :: Observable v => Transfer -> Maybe Backend -> AssociatedFile -> Maybe StallDetection -> RetryDecider -> (MeterUpdate -> Annex v) -> Annex v
+runTransfer = runTransfer' False
+
+{- Like runTransfer, but ignores any existing transfer lock file for the
+ - transfer, allowing re-running a transfer that is already in progress.
+ -}
+alwaysRunTransfer :: Observable v => Transfer -> Maybe Backend -> AssociatedFile -> Maybe StallDetection -> RetryDecider -> (MeterUpdate -> Annex v) -> Annex v
+alwaysRunTransfer = runTransfer' True
+
+runTransfer' :: Observable v => Bool -> Transfer -> Maybe Backend -> AssociatedFile -> Maybe StallDetection -> RetryDecider -> (MeterUpdate -> Annex v) -> Annex v
+runTransfer' ignorelock t eventualbackend afile stalldetection retrydecider transferaction =
+	enteringStage (TransferStage (transferDirection t)) $
+		debugLocks $
+			preCheckSecureHashes (transferKey t) eventualbackend go
+  where
+	go = do
+		info <- liftIO $ startTransferInfo afile
+		(tfile, lckfile, moldlckfile) <- fromRepo $ transferFileAndLockFile t
+		(meter, createtfile, metervar) <- mkProgressUpdater t info tfile
+		mode <- annexFileMode
+		(lck, inprogress) <- prep lckfile moldlckfile createtfile mode
+		if inprogress && not ignorelock
+			then do
+				warning "transfer already in progress, or unable to take transfer lock"
+				return observeFailure
+			else do
+				v <- retry 0 info metervar $
+					detectStallsAndSuggestConfig stalldetection metervar $
+						transferaction meter
+				liftIO $ cleanup tfile lckfile moldlckfile lck
+				if observeBool v
+					then removeFailedTransfer t
+					else recordFailedTransfer t info
+				return v
+	
+	prep :: RawFilePath -> Maybe RawFilePath -> Annex () -> ModeSetter -> Annex (Maybe (LockHandle, Maybe LockHandle), Bool)
+#ifndef mingw32_HOST_OS
+	prep lckfile moldlckfile createtfile mode = catchPermissionDenied (const prepfailed) $ do
+		createAnnexDirectory $ P.takeDirectory lckfile
+		tryLockExclusive (Just mode) lckfile >>= \case
+			Nothing -> return (Nothing, True)
+			-- Since the lock file is removed in cleanup,
+			-- there's a race where different processes
+			-- may have a deleted and a new version of the same
+			-- lock file open. checkSaneLock guards against
+			-- that.
+			Just lockhandle -> ifM (checkSaneLock lckfile lockhandle)
+				( case moldlckfile of
+					Nothing -> do
+						createtfile
+						return (Just (lockhandle, Nothing), False)
+					Just oldlckfile -> do
+						createAnnexDirectory $ P.takeDirectory oldlckfile
+						tryLockExclusive (Just mode) oldlckfile >>= \case
+							Nothing -> do
+								liftIO $ dropLock lockhandle
+								return (Nothing, True)
+							Just oldlockhandle -> ifM (checkSaneLock oldlckfile oldlockhandle)
+								( do
+									createtfile
+									return (Just (lockhandle, Just oldlockhandle), False)
+								, do
+									liftIO $ dropLock oldlockhandle
+									liftIO $ dropLock lockhandle
+									return (Nothing, True)
+								)
+				, do
+					liftIO $ dropLock lockhandle
+					return (Nothing, True)
+				)
+#else
+	prep lckfile moldlckfile createtfile _mode = catchPermissionDenied (const prepfailed) $ do
+		createAnnexDirectory $ P.takeDirectory lckfile
+		catchMaybeIO (liftIO $ lockExclusive lckfile) >>= \case
+			Just (Just lockhandle) -> case moldlckfile of
+				Nothing -> do
+					createtfile
+					return (Just (lockhandle, Nothing), False)
+				Just oldlckfile -> do
+					createAnnexDirectory $ P.takeDirectory oldlckfile
+					catchMaybeIO (liftIO $ lockExclusive oldlckfile) >>= \case
+						Just (Just oldlockhandle) -> do
+							createtfile
+							return (Just (lockhandle, Just oldlockhandle), False)
+						_ -> do
+							liftIO $ dropLock lockhandle
+							return (Nothing, False)
+			_ -> return (Nothing, False)
+#endif
+	prepfailed = return (Nothing, False)
+
+	cleanup _ _ _ Nothing = noop
+	cleanup tfile lckfile moldlckfile (Just (lockhandle, moldlockhandle)) = do
+		void $ tryIO $ R.removeLink tfile
+#ifndef mingw32_HOST_OS
+		void $ tryIO $ R.removeLink lckfile
+		maybe noop (void . tryIO . R.removeLink) moldlckfile
+		maybe noop dropLock moldlockhandle
+		dropLock lockhandle
+#else
+		{- Windows cannot delete the lockfile until the lock
+		 - is closed. So it's possible to race with another
+		 - process that takes the lock before it's removed,
+		 - so ignore failure to remove.
+		 -}
+		maybe noop dropLock moldlockhandle
+		dropLock lockhandle
+		void $ tryIO $ R.removeLink lckfile
+		maybe noop (void . tryIO . R.removeLink) moldlckfile
+#endif
+
+	retry numretries oldinfo metervar run =
+		tryNonAsync run >>= \case
+			Right v
+				| observeBool v -> return v
+				| otherwise -> checkretry
+			Left e -> do
+				warning (UnquotedString (show e))
+				checkretry
+	  where
+		checkretry = do
+			b <- getbytescomplete metervar
+			let newinfo = oldinfo { bytesComplete = Just b }
+			let !numretries' = succ numretries
+			ifM (retrydecider numretries' oldinfo newinfo)
+				( retry numretries' newinfo metervar run
+				, return observeFailure
+				)
+
+	getbytescomplete metervar = liftIO $
+		maybe 0 fromBytesProcessed <$> readTVarIO metervar
+
+detectStallsAndSuggestConfig :: Maybe StallDetection -> TVar (Maybe BytesProcessed) -> Annex a -> Annex a
+detectStallsAndSuggestConfig Nothing _ a = a
+detectStallsAndSuggestConfig sd@(Just _) metervar a = 
+	bracket setup cleanup (const a)
+  where
+	setup = do
+		v <- liftIO newEmptyTMVarIO
+		sdt <- liftIO $ async $ detectStalls sd metervar $
+			void $ atomically $ tryPutTMVar v True
+		wt <- liftIO . async =<< forkState (warnonstall v)
+		return (v, sdt, wt)
+	cleanup (v, sdt, wt) = do
+		liftIO $ uninterruptibleCancel sdt
+		void $ liftIO $ atomically $ tryPutTMVar v False
+		join (liftIO (wait wt))
+	warnonstall v = whenM (liftIO (atomically (takeTMVar v))) $
+		warning "Transfer seems to have stalled. To restart stalled transfers, configure annex.stalldetection"
+
+{- Runs a transfer using a separate process, which lets detected stalls be
+ - canceled. -}
+runTransferrer
+	:: StallDetection
+	-> Remote
+	-> Key
+	-> AssociatedFile
+	-> RetryDecider
+	-> Direction
+	-> NotifyWitness
+	-> Annex Bool
+runTransferrer sd r k afile retrydecider direction _witness =
+	enteringStage (TransferStage direction) $ preCheckSecureHashes k Nothing $ do
+		info <- liftIO $ startTransferInfo afile
+		go 0 info
+  where
+	go numretries info = 
+		withTransferrer (performTransfer (Just sd) AnnexLevel id (Just r) t info) >>= \case
+			Right () -> return True
+			Left newinfo -> do
+				let !numretries' = succ numretries
+				ifM (retrydecider numretries' info newinfo)
+					( go numretries' newinfo
+					, return False
+					)
+	t = Transfer direction (Remote.uuid r) (fromKey id k)
+
+{- Avoid download and upload of keys with insecure content when
+ - annex.securehashesonly is configured.
+ -
+ - This is not a security check. Even if this let the content be
+ - downloaded, the actual security checks would prevent the content from
+ - being added to the repository. The only reason this is done here is to
+ - avoid transferring content that's going to be rejected anyway.
+ -
+ - We assume that, if annex.securehashesonly is set and the local repo
+ - still contains content using an insecure hash, remotes will likewise
+ - tend to be configured to reject it, so Upload is also prevented.
+ -}
+preCheckSecureHashes :: Observable v => Key -> Maybe Backend -> Annex v -> Annex v
+preCheckSecureHashes k meventualbackend a = case meventualbackend of
+	Just eventualbackend -> go
+		(pure (Types.Backend.isCryptographicallySecure eventualbackend))
+		(Types.Backend.backendVariety eventualbackend)
+	Nothing -> go
+		(isCryptographicallySecureKey k)
+		(fromKey keyVariety k)
+  where
+	go checksecure variety = ifM checksecure
+		( a
+		, ifM (annexSecureHashesOnly <$> Annex.getGitConfig)
+			( blocked variety
+			, a
+			)
+		)
+	blocked variety = do
+		warning $ UnquotedString $ "annex.securehashesonly blocked transfer of " ++ decodeBS (formatKeyVariety variety) ++ " key"
+		return observeFailure
+
+type NumRetries = Integer
+
+type RetryDecider = NumRetries -> TransferInfo -> TransferInfo -> Annex Bool
+
+{- Both retry deciders are checked together, so if one chooses to delay,
+ - it will always take effect. -}
+combineRetryDeciders :: RetryDecider -> RetryDecider -> RetryDecider
+combineRetryDeciders a b = \n old new -> do
+	ar <- a n old new
+	br <- b n old new
+	return (ar || br)
+
+noRetry :: RetryDecider
+noRetry _ _ _ = pure False
+
+stdRetry :: RetryDecider
+stdRetry = combineRetryDeciders forwardRetry configuredRetry
+
+{- Keep retrying failed transfers, as long as forward progress is being
+ - made.
+ -
+ - Up to a point -- while some remotes can resume where the previous
+ - transfer left off, and so it would make sense to keep retrying forever,
+ - other remotes restart each transfer from the beginning, and so even if
+ - forward progress is being made, it's not real progress. So, retry a
+ - maximum of 5 times by default.
+ -}
+forwardRetry :: RetryDecider
+forwardRetry numretries old new
+	| fromMaybe 0 (bytesComplete old) < fromMaybe 0 (bytesComplete new) =
+		(numretries <=) <$> maybe globalretrycfg pure remoteretrycfg
+	| otherwise = return False
+  where
+	globalretrycfg = fromMaybe 5 . annexForwardRetry
+		<$> Annex.getGitConfig
+	remoteretrycfg = remoteAnnexRetry =<<
+		(Remote.gitconfig <$> transferRemote new)
+
+{- Retries a number of times with growing delays in between when enabled
+ - by git configuration. -}
+configuredRetry :: RetryDecider
+configuredRetry numretries _old new = do
+	(maxretries, Seconds initretrydelay) <- getcfg $ 
+		Remote.gitconfig <$> transferRemote new
+	if numretries < maxretries
+		then do
+			let retrydelay = Seconds (initretrydelay * 2^(numretries-1))
+			showSideAction $ UnquotedString $ "Delaying " ++ show (fromSeconds retrydelay) ++ "s before retrying."
+			liftIO $ threadDelaySeconds retrydelay
+			return True
+		else return False
+  where
+	globalretrycfg = fromMaybe 0 . annexRetry
+		<$> Annex.getGitConfig
+	globalretrydelaycfg = fromMaybe (Seconds 1) . annexRetryDelay
+		<$> Annex.getGitConfig
+	getcfg Nothing = (,) <$> globalretrycfg <*> globalretrydelaycfg
+	getcfg (Just gc) = (,)
+		<$> maybe globalretrycfg return (remoteAnnexRetry gc)
+		<*> maybe globalretrydelaycfg return (remoteAnnexRetryDelay gc)
+
+{- Picks a remote from the list and tries a transfer to it. If the transfer
+ - does not succeed, goes on to try other remotes from the list.
+ -
+ - The list should already be ordered by remote cost, and is normally
+ - tried in order. However, when concurrent jobs are running, they will
+ - be assigned different remotes of the same cost when possible. This can
+ - increase total transfer speed.
+ -}
+pickRemote :: Observable v => [Remote] -> (Remote -> Annex v) -> Annex v
+pickRemote l a = debugLocks $ go l =<< getConcurrency
+  where
+	go [] _ = return observeFailure
+	go (r:[]) _ = a r
+	go rs NonConcurrent = gononconcurrent rs
+	go rs (Concurrent n)
+		| n <= 1 = gononconcurrent rs
+		| otherwise = goconcurrent rs
+	go rs ConcurrentPerCpu = goconcurrent rs
+	
+	gononconcurrent [] = return observeFailure
+	gononconcurrent (r:rs) = do
+		ok <- a r
+		if observeBool ok
+			then return ok
+			else gononconcurrent rs
+	
+	goconcurrent rs = do
+		mv <- Annex.getRead Annex.activeremotes
+		active <- liftIO $ takeMVar mv
+		let rs' = sortBy (lessActiveFirst active) rs
+		goconcurrent' mv active rs'
+
+	goconcurrent' mv active [] = do
+		liftIO $ putMVar mv active
+		return observeFailure
+	goconcurrent' mv active (r:rs) = do
+		let !active' = M.insertWith (+) r 1 active
+		liftIO $ putMVar mv active'
+		let getnewactive = do
+			active'' <- liftIO $ takeMVar mv
+			let !active''' = M.update (\n -> if n > 1 then Just (n-1) else Nothing) r active''
+			return active'''
+		let removeactive = liftIO . putMVar mv =<< getnewactive
+		ok <- a r `onException` removeactive
+		if observeBool ok
+			then do
+				removeactive
+				return ok 
+			else do
+				active'' <- getnewactive
+				-- Re-sort the remaining rs 
+				-- because other threads could have
+				-- been assigned them in the meantime.
+				let rs' = sortBy (lessActiveFirst active'') rs
+				goconcurrent' mv active'' rs'
+
+lessActiveFirst :: M.Map Remote Integer -> Remote -> Remote -> Ordering
+lessActiveFirst active a b
+	| Remote.cost a == Remote.cost b = comparing (`M.lookup` active) a b
+	| otherwise = comparing Remote.cost a b
diff --git a/Annex/TransferrerPool.hs b/Annex/TransferrerPool.hs
new file mode 100644
index 0000000000..481e08e9f7
--- /dev/null
+++ b/Annex/TransferrerPool.hs
@@ -0,0 +1,300 @@
+{- A pool of "git-annex transferrer" processes
+ -
+ - Copyright 2013-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE CPP #-}
+
+module Annex.TransferrerPool where
+
+import Annex.Common
+import qualified Annex
+import Types.TransferrerPool
+import Types.Transferrer
+import Types.Transfer
+import qualified Types.Remote as Remote
+import Types.Messages
+import Types.CleanupActions
+import Messages.Serialized
+import Annex.Path
+import Annex.StallDetection
+import Annex.Link
+import Utility.Batch
+import Utility.Metered
+import qualified Utility.SimpleProtocol as Proto
+
+import Control.Concurrent
+import Control.Concurrent.Async
+import Control.Concurrent.STM hiding (check)
+import Control.Monad.IO.Class (MonadIO)
+import qualified Data.Map as M
+#ifndef mingw32_HOST_OS
+import System.Posix.Signals
+import System.Posix.Process (getProcessGroupIDOf)
+#endif
+
+type SignalActionsVar = TVar (M.Map SignalAction (Int -> IO ()))
+
+data RunTransferrer = RunTransferrer String [CommandParam] BatchCommandMaker
+
+mkRunTransferrer :: BatchCommandMaker -> Annex RunTransferrer
+mkRunTransferrer batchmaker = RunTransferrer
+	<$> liftIO programPath
+	<*> gitAnnexChildProcessParams "transferrer" []
+	<*> pure batchmaker
+
+{- Runs an action with a Transferrer from the pool. -}
+withTransferrer :: (Transferrer -> Annex a) -> Annex a
+withTransferrer a = do
+	rt <- mkRunTransferrer nonBatchCommandMaker
+	pool <- Annex.getRead Annex.transferrerpool
+	let nocheck = pure (pure True)
+	signalactonsvar <- Annex.getRead Annex.signalactions
+	withTransferrer' False signalactonsvar nocheck rt pool a
+
+withTransferrer'
+	:: (MonadIO m, MonadMask m)
+	=> Bool
+	-- ^ When minimizeprocesses is True, only one Transferrer is left
+	-- running in the pool at a time. So if this needed to start a
+	-- new Transferrer, it's stopped when done. Otherwise, idle
+	-- processes are left in the pool for use later.
+	-> SignalActionsVar
+	-> MkCheckTransferrer
+	-> RunTransferrer
+	-> TransferrerPool
+	-> (Transferrer -> m a)
+	-> m a
+withTransferrer' minimizeprocesses signalactonsvar mkcheck rt pool a = do
+	(mi, leftinpool) <- liftIO $ atomically (popTransferrerPool pool)
+	(i@(TransferrerPoolItem _ check), t) <- liftIO $ case mi of
+		Nothing -> do
+			t <- mkTransferrer signalactonsvar rt
+			i <- mkTransferrerPoolItem mkcheck t
+			return (i, t)
+		Just i -> checkTransferrerPoolItem signalactonsvar rt i
+	a t `finally` returntopool leftinpool check t i
+  where
+	returntopool leftinpool check t i
+		| not minimizeprocesses || leftinpool == 0 =
+			-- If the transferrer got killed, the handles will
+			-- be closed, so it should not be returned to the
+			-- pool.
+			liftIO $ whenM (hIsOpen (transferrerWrite t)) $
+				liftIO $ atomically $ pushTransferrerPool pool i
+		| otherwise = liftIO $ do
+			void $ forkIO $ transferrerShutdown t
+			atomically $ pushTransferrerPool pool $ TransferrerPoolItem Nothing check
+
+{- Check if a Transferrer from the pool is still ok to be used.
+ - If not, stop it and start a new one. -}
+checkTransferrerPoolItem :: SignalActionsVar -> RunTransferrer -> TransferrerPoolItem -> IO (TransferrerPoolItem, Transferrer)
+checkTransferrerPoolItem signalactonsvar rt i = case i of
+	TransferrerPoolItem (Just t) check -> ifM check
+		( return (i, t)
+		, do
+			transferrerShutdown t
+			new check
+		)
+	TransferrerPoolItem Nothing check -> new check
+  where
+	new check = do
+		t <- mkTransferrer signalactonsvar rt
+		return (TransferrerPoolItem (Just t) check, t)
+
+data TransferRequestLevel = AnnexLevel | AssistantLevel
+	deriving (Show)
+
+{- Requests that a Transferrer perform a Transfer, and waits for it to
+ - finish.
+ -
+ - When a stall is detected, kills the Transferrer.
+ -
+ - If the transfer failed or stalled, returns TransferInfo with an
+ - updated bytesComplete reflecting how much data has been transferred.
+ -}
+performTransfer
+	:: (Monad m, MonadIO m, MonadMask m)
+	=> Maybe StallDetection
+	-> TransferRequestLevel
+	-> (forall a. Annex a -> m a)
+	-- ^ Run an annex action in the monad. Will not be used with
+	-- actions that block for a long time.
+	-> Maybe Remote
+	-> Transfer
+	-> TransferInfo
+	-> Transferrer
+	-> m (Either TransferInfo ())
+performTransfer stalldetection level runannex r t info transferrer = do
+	bpv <- liftIO $ newTVarIO zeroBytesProcessed
+	ifM (catchBoolIO $ bracket setup cleanup (go bpv))
+		( return (Right ())
+		, do
+			n <- liftIO $ atomically $
+				fromBytesProcessed <$> readTVar bpv
+			return $ Left $ info { bytesComplete = Just n }
+		)
+  where
+	setup = do
+		liftIO $ sendRequest level t r
+			(associatedFile info)
+			(transferrerWrite transferrer)
+		metervar <- liftIO $ newTVarIO Nothing
+		stalledvar <- liftIO $ newTVarIO False
+		tid <- liftIO $ async $ 
+			detectStalls stalldetection metervar $ do
+				atomically $ writeTVar stalledvar True
+				killTransferrer transferrer
+		return (metervar, tid, stalledvar)
+	
+	cleanup (_, tid, stalledvar) = do
+		liftIO $ uninterruptibleCancel tid
+		whenM (liftIO $ atomically $ readTVar stalledvar) $ do
+			runannex $ showLongNote "Transfer stalled"
+			-- Close handles, to prevent the transferrer being
+			-- reused since the process was killed.
+			liftIO $ hClose $ transferrerRead transferrer
+			liftIO $ hClose $ transferrerWrite transferrer
+
+	go bpv (metervar, _, _) = relaySerializedOutput
+		(liftIO $ readResponse (transferrerRead transferrer))
+		(liftIO . sendSerializedOutputResponse (transferrerWrite transferrer))
+		(updatemeter bpv metervar)
+		runannex
+	
+	updatemeter bpv metervar (Just n) = liftIO $ do
+		atomically $ writeTVar metervar (Just n)
+		atomically $ writeTVar bpv n
+	updatemeter _bpv metervar Nothing = liftIO $
+		atomically $ writeTVar metervar Nothing
+
+{- Starts a new git-annex transfer process, setting up handles
+ - that will be used to communicate with it. -}
+mkTransferrer :: SignalActionsVar -> RunTransferrer -> IO Transferrer
+#ifndef mingw32_HOST_OS
+mkTransferrer signalactonsvar (RunTransferrer program params batchmaker) = do
+#else
+mkTransferrer _ (RunTransferrer program params batchmaker) = do
+#endif
+	{- It runs as a batch job. -}
+	let (program', params') = batchmaker (program, params)
+	{- It's put into its own group so that the whole group can be
+	 - killed to stop a transfer. -}
+	(Just writeh, Just readh, _, ph) <- createProcess
+		(proc program' $ toCommand params')
+		{ create_group = True
+		, std_in = CreatePipe
+		, std_out = CreatePipe
+		}
+
+	{- Set up signal propagation, so eg ctrl-c will also interrupt
+	 - the processes in the transferrer's process group. 
+	 -
+	 - There is a race between the process being created and this point.
+	 - If a signal is received before this can run, it is not sent to
+	 - the transferrer. This leaves the transferrer waiting for the
+	 - first message on stdin to tell what to do. If the signal kills
+	 - this parent process, the transferrer will then get a sigpipe
+	 - and die too. If the signal suspends this parent process,
+	 - it's ok to leave the transferrer running, as it's waiting on
+	 - the pipe until this process wakes back up.
+	 -}
+#ifndef mingw32_HOST_OS
+	pid <- getPid ph
+	unregistersignalprop <- case pid of
+		Just p -> getProcessGroupIDOf p >>= \pgrp -> do
+			atomically $ modifyTVar' signalactonsvar $ 
+				M.insert (PropagateSignalProcessGroup p) $ \sig ->
+					signalProcessGroup (fromIntegral sig) pgrp
+			return $ atomically $ modifyTVar' signalactonsvar $
+				M.delete (PropagateSignalProcessGroup p)
+		Nothing -> return noop
+#else
+	let unregistersignalprop = noop
+#endif
+
+	return $ Transferrer
+		{ transferrerRead = readh
+		, transferrerWrite = writeh
+		, transferrerHandle = ph
+		, transferrerShutdown = do
+			-- The transferrer may write to stdout
+			-- as it's shutting down, so don't close
+			-- the readh right away. Instead, drain
+			-- anything sent to it.
+			drainer <- async $ void $ hGetContents readh
+			hClose writeh
+			void $ waitForProcess ph
+			wait drainer
+			hClose readh
+			unregistersignalprop
+		}
+
+-- | Send a request to perform a transfer.
+sendRequest :: TransferRequestLevel -> Transfer -> Maybe Remote -> AssociatedFile -> Handle -> IO ()
+sendRequest level t mremote afile h = do
+	let tr = maybe
+		(TransferRemoteUUID (transferUUID t))
+		(TransferRemoteName . Remote.name)
+		mremote
+	let f = case (level, transferDirection t) of
+		(AnnexLevel, Upload) -> UploadRequest
+		(AnnexLevel, Download) -> DownloadRequest
+		(AssistantLevel, Upload) -> AssistantUploadRequest
+		(AssistantLevel, Download) -> AssistantDownloadRequest
+	let r = f tr (transferKey t) (TransferAssociatedFile afile)
+	let l = unwords $ Proto.formatMessage r
+	debug "Annex.TransferrerPool" ("> " ++ l)
+	hPutStrLn h l
+	hFlush h
+
+sendSerializedOutputResponse :: Handle -> SerializedOutputResponse -> IO ()
+sendSerializedOutputResponse h sor = do
+	let l = unwords $ Proto.formatMessage $
+		TransferSerializedOutputResponse sor
+	debug "Annex.TransferrerPool" ("> " ++ show l)
+	hPutStrLn h l
+	hFlush h
+
+-- | Read a response to a transfer request.
+--
+-- Before the final response, this will return whatever SerializedOutput
+-- should be displayed as the transfer is performed.
+readResponse :: Handle -> IO (Either SerializedOutput Bool)
+readResponse h = do
+	l <- liftIO $ hGetLine h
+	debug "Annex.TransferrerPool" ("< " ++ l)
+	case Proto.parseMessage l of
+		Just (TransferOutput so) -> return (Left so)
+		Just (TransferResult r) -> return (Right r)
+		Nothing -> transferrerProtocolError l
+
+transferrerProtocolError :: String -> a
+transferrerProtocolError l = giveup $ "transferrer protocol error: " ++ show l
+
+{- Kill the transferrer, and all its child processes. -}
+killTransferrer :: Transferrer -> IO ()
+killTransferrer t = do
+	interruptProcessGroupOf $ transferrerHandle t
+	threadDelay 50000 -- 0.05 second grace period
+	terminateProcess $ transferrerHandle t
+
+{- Stop all transferrers in the pool. -}
+emptyTransferrerPool :: Annex ()
+emptyTransferrerPool = do
+	poolvar <- Annex.getRead Annex.transferrerpool
+	pool <- liftIO $ atomically $ swapTVar poolvar []
+	liftIO $ forM_ pool $ \case
+		TransferrerPoolItem (Just t) _ -> transferrerShutdown t
+		TransferrerPoolItem Nothing _ -> noop
+	-- Transferrers usually restage pointer files themselves,
+	-- but when killTransferrer is used, a transferrer may have
+	-- pointer files it has not gotten around to restaging yet.
+	-- So, restage pointer files here in clean up from such killed
+	-- transferrers.
+	unless (null pool) $
+		restagePointerFiles =<< Annex.gitRepo
diff --git a/Annex/UUID.hs b/Annex/UUID.hs
new file mode 100644
index 0000000000..8986f2d7a0
--- /dev/null
+++ b/Annex/UUID.hs
@@ -0,0 +1,123 @@
+{- git-annex uuids
+ -
+ - Each git repository used by git-annex has an annex.uuid setting that
+ - uniquely identifies that repository.
+ -
+ - UUIDs of remotes are cached in git config, using keys named
+ - remote.<name>.annex-uuid
+ -
+ - Copyright 2010-2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.UUID (
+	configkeyUUID,
+	getUUID,
+	getRepoUUID,
+	getUncachedUUID,
+	isUUIDConfigured,
+	prepUUID,
+	genUUID,
+	genUUIDInNameSpace,
+	gCryptNameSpace,
+	removeRepoUUID,
+	storeUUID,
+	storeUUIDIn,
+	setUUID,
+	webUUID,
+	bitTorrentUUID,
+) where
+
+import Annex.Common
+import qualified Annex
+import qualified Git
+import qualified Git.Config
+import Git.Types
+import Config
+
+import qualified Data.UUID as U
+import qualified Data.UUID.V4 as U4
+import qualified Data.UUID.V5 as U5
+import qualified Data.ByteString as S
+import Data.String
+
+configkeyUUID :: ConfigKey
+configkeyUUID = annexConfig "uuid"
+
+{- Generates a random UUID, that does not include the MAC address. -}
+genUUID :: IO UUID
+genUUID = toUUID <$> U4.nextRandom
+
+{- Generates a UUID from a given string, using a namespace.
+ - Given the same namespace, the same string will always result
+ - in the same UUID. -}
+genUUIDInNameSpace :: U.UUID -> S.ByteString -> UUID
+genUUIDInNameSpace namespace = toUUID . U5.generateNamed namespace . S.unpack
+
+{- Namespace used for UUIDs derived from git-remote-gcrypt ids. -}
+gCryptNameSpace :: U.UUID
+gCryptNameSpace = U5.generateNamed U5.namespaceURL $
+	S.unpack "http://git-annex.branchable.com/design/gcrypt/" 
+
+{- Get current repository's UUID. -}
+getUUID :: Annex UUID
+getUUID = annexUUID <$> Annex.getGitConfig 
+
+{- Looks up a remote repo's UUID, caching it in .git/config if
+ - it's not already. -}
+getRepoUUID :: Git.Repo -> Annex UUID
+getRepoUUID r = do
+	c <- toUUID <$> getConfig cachekey ""
+	let u = getUncachedUUID r
+	
+	if c /= u && u /= NoUUID
+		then do
+			updatecache u
+			return u
+		else return c
+  where
+	updatecache u = do
+		g <- gitRepo
+		when (g /= r) $ storeUUIDIn cachekey u
+	cachekey = remoteAnnexConfig r "uuid"
+
+removeRepoUUID :: Annex ()
+removeRepoUUID = do
+	unsetConfig configkeyUUID
+	storeUUID NoUUID
+
+getUncachedUUID :: Git.Repo -> UUID
+getUncachedUUID = toUUID . Git.Config.get configkeyUUID ""
+
+-- Does the repo's config have a key for the UUID?
+-- True even when the key has no value.
+isUUIDConfigured :: Git.Repo -> Bool
+isUUIDConfigured = isJust . Git.Config.getMaybe configkeyUUID
+
+{- Make sure that the repo has an annex.uuid setting. -}
+prepUUID :: Annex ()
+prepUUID = whenM ((==) NoUUID <$> getUUID) $
+	storeUUID =<< liftIO genUUID
+
+storeUUID :: UUID -> Annex ()
+storeUUID = storeUUIDIn configkeyUUID
+
+storeUUIDIn :: ConfigKey -> UUID -> Annex ()
+storeUUIDIn configfield = setConfig configfield . fromUUID
+
+{- Only sets the configkey in the Repo; does not change .git/config -}
+setUUID :: Git.Repo -> UUID -> IO Git.Repo
+setUUID r u = do
+	let s = encodeBS $ show configkeyUUID ++ "=" ++ fromUUID u
+	Git.Config.store s Git.Config.ConfigList r
+
+-- Dummy uuid for the whole web. Do not alter.
+webUUID :: UUID
+webUUID = UUID (fromString "00000000-0000-0000-0000-000000000001")
+
+-- Dummy uuid for bittorrent. Do not alter.
+bitTorrentUUID :: UUID
+bitTorrentUUID = UUID (fromString "00000000-0000-0000-0000-000000000002")
diff --git a/Annex/UntrustedFilePath.hs b/Annex/UntrustedFilePath.hs
new file mode 100644
index 0000000000..df7ac3bd35
--- /dev/null
+++ b/Annex/UntrustedFilePath.hs
@@ -0,0 +1,77 @@
+{- handling untrusted filepaths
+ -
+ - Copyright 2010-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.UntrustedFilePath where
+
+import Data.Char
+import System.FilePath
+
+import Utility.SafeOutput
+
+{- Given a string that we'd like to use as the basis for FilePath, but that
+ - was provided by a third party and is not to be trusted, returns the closest
+ - sane FilePath.
+ -
+ - All spaces and punctuation and other wacky stuff are replaced
+ - with '_', except for '.' and '-'
+ -
+ - "../" becomes ".._", which is safe.
+ - "/foo" becomes "_foo", which is safe.
+ - "c:foo" becomes "c_foo", which is safe even on windows.
+ - 
+ - Leading '.' and '-' are also replaced with '_', so
+ - so no dotfiles that might control a program are inadvertently created,
+ - and to avoid filenames being treated as options to commands the user
+ - might run.
+ -
+ - Also there's an off chance the string might be empty, so to avoid
+ - needing to handle such an invalid filepath, return a dummy "file" in
+ - that case.
+ -}
+sanitizeFilePath :: String -> FilePath
+sanitizeFilePath = sanitizeLeadingFilePathCharacter . sanitizeFilePathComponent
+
+{- For when the filepath is being built up out of components that should be
+ - individually sanitized, this can be used for each component, followed by
+ - sanitizeLeadingFilePathCharacter for the whole thing.
+ -}
+sanitizeFilePathComponent :: String -> String
+sanitizeFilePathComponent = map sanitize
+  where
+	sanitize c
+		| c == '.' || c == '-' = c
+		| isSpace c || isPunctuation c || isSymbol c || isControl c || c == '/' = '_'
+		| otherwise = c
+
+sanitizeLeadingFilePathCharacter :: String -> FilePath
+sanitizeLeadingFilePathCharacter [] = "file"
+sanitizeLeadingFilePathCharacter ('.':s) = '_':s
+sanitizeLeadingFilePathCharacter ('-':s) = '_':s
+sanitizeLeadingFilePathCharacter ('/':s) = '_':s
+sanitizeLeadingFilePathCharacter s = s
+
+controlCharacterInFilePath :: FilePath -> Bool
+controlCharacterInFilePath = any (not . safechar)
+  where
+	safechar c = safeOutputChar c && c /= '\n'
+
+{- ../ is a path traversal, no matter where it appears.
+ -
+ - An absolute path is, of course.
+ -}
+pathTraversalInFilePath :: FilePath -> Bool
+pathTraversalInFilePath f
+	| isAbsolute f = True
+	| any (== "..") (splitPath f) = True
+	-- On windows, C:foo with no directory is not considered absolute
+	| hasDrive f = True 
+	| otherwise = False
+
+gitDirectoryInFilePath :: FilePath -> Bool
+gitDirectoryInFilePath = any (== ".git")
+	. map dropTrailingPathSeparator
+	. splitPath 
diff --git a/Annex/UpdateInstead.hs b/Annex/UpdateInstead.hs
new file mode 100644
index 0000000000..3f197cb580
--- /dev/null
+++ b/Annex/UpdateInstead.hs
@@ -0,0 +1,23 @@
+{- git-annex UpdateIntead emulation
+ -
+ - Copyright 2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.UpdateInstead where
+
+import qualified Annex
+import Annex.Common
+import Annex.AdjustedBranch
+import Git.Branch
+import Git.ConfigTypes
+
+{- receive.denyCurrentBranch=updateInstead does not work
+ - when an adjusted branch is checked out, so must be emulated. -}
+needUpdateInsteadEmulation :: Annex Bool
+needUpdateInsteadEmulation = updateinsteadset <&&> isadjusted
+  where
+	updateinsteadset = (== UpdateInstead) . receiveDenyCurrentBranch
+		<$> Annex.getGitConfig
+	isadjusted = (maybe False (isJust . getAdjustment) <$> inRepo Git.Branch.current)
diff --git a/Annex/Url.hs b/Annex/Url.hs
new file mode 100644
index 0000000000..2f12a10768
--- /dev/null
+++ b/Annex/Url.hs
@@ -0,0 +1,190 @@
+{- Url downloading, with git-annex user agent and configured http
+ - headers, security restrictions, etc.
+ -
+ - Copyright 2013-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Url (
+	withUrlOptions,
+	withUrlOptionsPromptingCreds,
+	getUrlOptions,
+	getUserAgent,
+	ipAddressesUnlimited,
+	checkBoth,
+	download,
+	download',
+	exists,
+	getUrlInfo,
+	U.URLString,
+	U.UrlOptions(..),
+	U.UrlInfo(..),
+	U.sinkResponseFile,
+	U.matchStatusCodeException,
+	U.downloadConduit,
+	U.downloadPartial,
+	U.parseURIRelaxed,
+	U.allowedScheme,
+	U.assumeUrlExists,
+) where
+
+import Annex.Common
+import qualified Annex
+import qualified Utility.Url as U
+import qualified Utility.Url.Parse as U
+import Utility.Hash (IncrementalVerifier)
+import Utility.IPAddress
+import Network.HTTP.Client.Restricted
+import Utility.Metered
+import Git.Credential
+import qualified BuildInfo
+
+import Network.Socket
+import Network.HTTP.Client
+import Network.HTTP.Client.TLS
+import Text.Read
+import qualified Data.Set as S
+
+defaultUserAgent :: U.UserAgent
+defaultUserAgent = "git-annex/" ++ BuildInfo.packageversion
+
+getUserAgent :: Annex U.UserAgent
+getUserAgent = Annex.getRead $ 
+	fromMaybe defaultUserAgent . Annex.useragent
+
+getUrlOptions :: Annex U.UrlOptions
+getUrlOptions = Annex.getState Annex.urloptions >>= \case
+	Just uo -> return uo
+	Nothing -> do
+		uo <- mk
+		Annex.changeState $ \s -> s
+			{ Annex.urloptions = Just uo }
+		return uo
+  where
+	mk = do
+		(urldownloader, manager) <- checkallowedaddr
+		U.mkUrlOptions
+			<$> (Just <$> getUserAgent)
+			<*> headers
+			<*> pure urldownloader
+			<*> pure manager
+			<*> (annexAllowedUrlSchemes <$> Annex.getGitConfig)
+			<*> pure (Just (\u -> "Configuration of annex.security.allowed-url-schemes does not allow accessing " ++ show u))
+			<*> pure U.noBasicAuth
+	
+	headers = annexHttpHeadersCommand <$> Annex.getGitConfig >>= \case
+		Just cmd -> lines <$> liftIO (readProcess "sh" ["-c", cmd])
+		Nothing -> annexHttpHeaders <$> Annex.getGitConfig
+	
+	checkallowedaddr = words . annexAllowedIPAddresses <$> Annex.getGitConfig >>= \case
+		["all"] -> do
+			curlopts <- map Param . annexWebOptions <$> Annex.getGitConfig
+			allowedurlschemes <- annexAllowedUrlSchemes <$> Annex.getGitConfig
+			let urldownloader = if null curlopts && not (any (`S.notMember` U.conduitUrlSchemes) allowedurlschemes)
+				then U.DownloadWithConduit $
+					U.DownloadWithCurlRestricted mempty
+				else U.DownloadWithCurl curlopts
+			manager <- liftIO $ U.newManager $ 
+				avoidtimeout $ tlsManagerSettings
+			return (urldownloader, manager)
+		allowedaddrsports -> do
+			addrmatcher <- liftIO $ 
+				(\l v -> any (\f -> f v) l) . catMaybes
+					<$> mapM (uncurry makeAddressMatcher) 
+						(mapMaybe splitAddrPort allowedaddrsports)
+			-- Default to not allowing access to loopback
+			-- and private IP addresses to avoid data
+			-- leakage.
+			let isallowed addr
+				| addrmatcher addr = True
+				| isLoopbackAddress addr = False
+				| isPrivateAddress addr = False
+				| otherwise = True
+			let connectionrestricted = connectionRestricted 
+				("Configuration of annex.security.allowed-ip-addresses does not allow accessing address " ++)
+			let r = addressRestriction $ \addr ->
+				if isallowed (addrAddress addr)
+					then Nothing
+					else Just (connectionrestricted addr)
+			(settings, pr) <- liftIO $ 
+				mkRestrictedManagerSettings r Nothing Nothing
+			case pr of
+				Nothing -> return ()
+				Just ProxyRestricted -> toplevelWarning True
+					"http proxy settings not used due to annex.security.allowed-ip-addresses configuration"
+			manager <- liftIO $ U.newManager $ 
+				avoidtimeout settings
+			-- Curl is not used, as its interface does not allow
+			-- preventing it from accessing specific IP addresses.
+			let urldownloader = U.DownloadWithConduit $
+				U.DownloadWithCurlRestricted r
+			return (urldownloader, manager)
+	
+	-- http-client defailts to timing out a request after 30 seconds
+	-- or so, but some web servers are slower and git-annex has its own
+	-- separate timeout controls, so disable that.
+	avoidtimeout s = s { managerResponseTimeout = responseTimeoutNone }
+
+splitAddrPort :: String -> Maybe (String, Maybe PortNumber)
+splitAddrPort s
+	-- "[addr]:port" (also allow "[addr]")
+	| "[" `isPrefixOf` s = case splitc ']' (drop 1 s) of
+		[a,cp] -> case splitc ':' cp of
+			["",p] -> do
+				pn <- readMaybe p
+				return (a, Just pn)
+			[""] -> Just (a, Nothing)
+			_ -> Nothing
+		_ -> Nothing
+	| otherwise = Just (s, Nothing)
+
+ipAddressesUnlimited :: Annex Bool
+ipAddressesUnlimited = 
+	("all" == ) . annexAllowedIPAddresses <$> Annex.getGitConfig
+
+withUrlOptions :: (U.UrlOptions -> Annex a) -> Annex a
+withUrlOptions a = a =<< getUrlOptions
+
+-- When downloading an url, if authentication is needed, uses
+-- git-credential to prompt for username and password.
+--
+-- Note that, when the downloader is curl, it will not use git-credential.
+-- If the user wants to, they can configure curl to use a netrc file that
+-- handles authentication.
+withUrlOptionsPromptingCreds :: (U.UrlOptions -> Annex a) -> Annex a
+withUrlOptionsPromptingCreds a = do
+	g <- Annex.gitRepo
+	uo <- getUrlOptions
+	prompter <- mkPrompter
+	cc <- Annex.getRead Annex.gitcredentialcache
+	a $ uo
+		{ U.getBasicAuth = \u -> prompter $
+			getBasicAuthFromCredential g cc u
+		}
+
+checkBoth :: U.URLString -> Maybe Integer -> U.UrlOptions -> Annex Bool
+checkBoth url expected_size uo =
+	liftIO (U.checkBoth url expected_size uo) >>= \case
+		Right r -> return r
+		Left err -> warning (UnquotedString err) >> return False
+
+download :: MeterUpdate -> Maybe IncrementalVerifier -> U.URLString -> FilePath -> U.UrlOptions -> Annex Bool
+download meterupdate iv url file uo =
+	liftIO (U.download meterupdate iv url file uo) >>= \case
+		Right () -> return True
+		Left err -> warning (UnquotedString err) >> return False
+
+download' :: MeterUpdate -> Maybe IncrementalVerifier -> U.URLString -> FilePath -> U.UrlOptions -> Annex (Either String ())
+download' meterupdate iv url file uo =
+	liftIO (U.download meterupdate iv url file uo)
+
+exists :: U.URLString -> U.UrlOptions -> Annex Bool
+exists url uo = liftIO (U.exists url uo) >>= \case
+	Right b -> return b
+	Left err -> warning (UnquotedString err) >> return False
+
+getUrlInfo :: U.URLString -> U.UrlOptions -> Annex (Either String U.UrlInfo)
+getUrlInfo url uo = liftIO (U.getUrlInfo url uo)
diff --git a/Annex/VariantFile.hs b/Annex/VariantFile.hs
new file mode 100644
index 0000000000..781732368d
--- /dev/null
+++ b/Annex/VariantFile.hs
@@ -0,0 +1,45 @@
+{- git-annex .variant files for automatic merge conflict resolution
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.VariantFile where
+
+import Annex.Common
+import Utility.Hash
+
+import qualified Data.ByteString as S
+
+variantMarker :: String
+variantMarker = ".variant-"
+
+mkVariant :: FilePath -> String -> FilePath
+mkVariant file variant = takeDirectory file
+	</> dropExtension (takeFileName file)
+	++ variantMarker ++ variant
+	++ takeExtension file
+
+{- The filename to use when resolving a conflicted merge of a file,
+ - that points to a key.
+ -
+ - Something derived from the key needs to be included in the filename,
+ - but rather than exposing the whole key to the user, a very weak hash
+ - is used. There is a very real, although still unlikely, chance of
+ - conflicts using this hash.
+ -
+ - In the event that there is a conflict with the filename generated
+ - for some other key, that conflict will itself be handled by the
+ - conflicted merge resolution code. That case is detected, and the full
+ - key is used in the filename.
+ -}
+variantFile :: FilePath -> Key -> FilePath
+variantFile file key
+	| doubleconflict = mkVariant file (fromRawFilePath (keyFile key))
+	| otherwise = mkVariant file (shortHash $ serializeKey' key)
+  where
+	doubleconflict = variantMarker `isInfixOf` file
+
+shortHash :: S.ByteString -> String
+shortHash = take 4 . show . md5s
diff --git a/Annex/VectorClock.hs b/Annex/VectorClock.hs
new file mode 100644
index 0000000000..db2c63c0bd
--- /dev/null
+++ b/Annex/VectorClock.hs
@@ -0,0 +1,83 @@
+{- git-annex vector clocks
+ -
+ - These are basically a timestamp. However, when logging a new
+ - value, if the old value has a vector clock that is the same or greater
+ - than the current vector clock, the old vector clock is incremented.
+ - This way, clock skew does not cause confusion.
+ -
+ - Copyright 2017-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.VectorClock (
+	module Annex.VectorClock,
+	module Types.VectorClock,
+) where
+
+import Types.VectorClock
+import Annex.Common
+import qualified Annex
+import Utility.TimeStamp
+
+import Data.ByteString.Builder
+import qualified Data.Attoparsec.ByteString.Lazy as A
+
+currentVectorClock :: Annex CandidateVectorClock
+currentVectorClock = liftIO =<< Annex.getState Annex.getvectorclock
+
+-- Runs the action and uses the same vector clock throughout,
+-- except when it's necessary to use a newer one due to a past value having
+-- a newer vector clock.
+--
+-- When the action modifies several files in the git-annex branch,
+-- this can cause less space to be used, since the same vector clock
+-- value is used, which can compress better.
+--
+-- However, this should not be used when running a long-duration action,
+-- because the vector clock is based on the start of the action, and not on 
+-- the later points where it writes changes. For example, if this were
+-- used across downloads of several files, the location log information
+-- would have an earlier vector clock than necessary, which might cause it
+-- to be disregarded in favor of other information that was collected
+-- at an earlier point in time than when the transfers completted and the
+-- log was written.
+reuseVectorClockWhile :: Annex a -> Annex a
+reuseVectorClockWhile = bracket setup cleanup . const
+  where
+	setup = do
+		origget <- Annex.getState Annex.getvectorclock
+		vc <- liftIO origget
+		use (pure vc)
+		return origget
+
+	cleanup origget = use origget
+
+	use vc = Annex.changeState $ \s ->
+		s { Annex.getvectorclock = vc }
+
+-- Convert a candidate vector clock in to the final one to use,
+-- advancing it if necessary when necessary to get ahead of a previously
+-- used vector clock.
+advanceVectorClock :: CandidateVectorClock -> [VectorClock] -> VectorClock
+advanceVectorClock (CandidateVectorClock c) [] = VectorClock c
+advanceVectorClock (CandidateVectorClock c) prevs
+	| prev >= VectorClock c = case prev of
+		VectorClock v -> VectorClock (v + 1)
+		Unknown -> VectorClock c
+	| otherwise = VectorClock c
+  where
+	prev = maximum prevs
+
+formatVectorClock :: VectorClock -> String
+formatVectorClock Unknown = "0"
+formatVectorClock (VectorClock t) = show t
+
+buildVectorClock :: VectorClock -> Builder
+buildVectorClock = string7 . formatVectorClock
+
+parseVectorClock :: String -> Maybe VectorClock
+parseVectorClock t = VectorClock <$> parsePOSIXTime t
+
+vectorClockParser :: A.Parser VectorClock
+vectorClockParser = VectorClock <$> parserPOSIXTime
diff --git a/Annex/VectorClock/Utility.hs b/Annex/VectorClock/Utility.hs
new file mode 100644
index 0000000000..76b74d9cd5
--- /dev/null
+++ b/Annex/VectorClock/Utility.hs
@@ -0,0 +1,33 @@
+{- git-annex vector clock utilities
+ -
+ - Copyright 2017-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.VectorClock.Utility where
+
+import Data.Time.Clock.POSIX
+
+import Types.VectorClock
+import Utility.Env
+import Utility.TimeStamp
+
+startVectorClock :: IO (IO CandidateVectorClock)
+startVectorClock = go =<< getEnv "GIT_ANNEX_VECTOR_CLOCK"
+  where
+	go Nothing = timebased
+	go (Just s) = case parsePOSIXTime s of
+		Just t -> return (pure (CandidateVectorClock t))
+		Nothing -> timebased
+	-- Avoid using fractional seconds in the CandidateVectorClock.
+	-- This reduces the size of the packed git-annex branch by up
+	-- to 8%. 
+	--
+	-- Due to the use of vector clocks, high resolution timestamps are
+	-- not necessary to make clear which information is most recent when
+	-- eg, a value is changed repeatedly in the same second. In such a
+	-- case, the vector clock will be advanced to the next second after
+	-- the last modification.
+	timebased = return $
+		CandidateVectorClock . truncateResolution 0 <$> getPOSIXTime
diff --git a/Annex/Verify.hs b/Annex/Verify.hs
new file mode 100644
index 0000000000..bfd1435803
--- /dev/null
+++ b/Annex/Verify.hs
@@ -0,0 +1,352 @@
+{- verification
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Verify (
+	shouldVerify,
+	verifyKeyContentPostRetrieval,
+	verifyKeyContent,
+	verifyKeyContent',
+	Verification(..),
+	unVerified,
+	warnUnverifiableInsecure,
+	isVerifiable,
+	startVerifyKeyContentIncrementally,
+	finishVerifyKeyContentIncrementally,
+	verifyKeyContentIncrementally,
+	IncrementalVerifier(..),
+	tailVerify,
+) where
+
+import Annex.Common
+import qualified Annex
+import qualified Types.Remote
+import Types.Remote (VerifyConfigA(..))
+import qualified Types.Backend
+import qualified Backend
+import Types.Remote (unVerified, Verification(..), RetrievalSecurityPolicy(..))
+import Utility.Hash (IncrementalVerifier(..))
+import Annex.WorkerPool
+import Types.WorkerPool
+import Types.Key
+
+import Control.Concurrent.STM
+import Control.Concurrent.Async
+import qualified Data.ByteString as S
+#if WITH_INOTIFY
+import qualified System.INotify as INotify
+import qualified System.FilePath.ByteString as P
+#endif
+
+shouldVerify :: VerifyConfig -> Annex Bool
+shouldVerify AlwaysVerify = return True
+shouldVerify NoVerify = return False
+shouldVerify DefaultVerify = annexVerify <$> Annex.getGitConfig
+shouldVerify (RemoteVerify r) = 
+	(shouldVerify DefaultVerify
+			<&&> pure (remoteAnnexVerify (Types.Remote.gitconfig r)))
+	-- Export remotes are not key/value stores, so always verify
+	-- content from them even when verification is disabled.
+	<||> Types.Remote.isExportSupported r
+
+{- Verifies that a file is the expected content of a key.
+ -
+ - Configuration can prevent verification, for either a
+ - particular remote or always, unless the RetrievalSecurityPolicy
+ - requires verification.
+ -
+ - Most keys have a known size, and if so, the file size is checked.
+ -
+ - When the key's backend allows verifying the content (via checksum),
+ - it is checked. 
+ -
+ - If the RetrievalSecurityPolicy requires verification and the key's
+ - backend doesn't support it, the verification will fail.
+ -}
+verifyKeyContentPostRetrieval :: RetrievalSecurityPolicy -> VerifyConfig -> Verification -> Key -> RawFilePath -> Annex Bool
+verifyKeyContentPostRetrieval rsp v verification k f = case (rsp, verification) of
+	(_, Verified) -> return True
+	(RetrievalVerifiableKeysSecure, _) -> ifM (isVerifiable k)
+		( verify
+		, ifM (annexAllowUnverifiedDownloads <$> Annex.getGitConfig)
+			( verify
+			, warnUnverifiableInsecure k >> return False
+			)
+		)
+	(_, UnVerified) -> ifM (shouldVerify v)
+		( verify
+		, return True
+		)
+	(_, IncompleteVerify _) -> ifM (shouldVerify v)
+		( verify
+		, return True
+		)
+	(_, MustVerify) -> verify
+	(_, MustFinishIncompleteVerify _) -> verify
+  where
+	verify = enteringStage VerifyStage $
+		case verification of
+			IncompleteVerify iv -> 
+				resumeVerifyKeyContent k f iv
+			MustFinishIncompleteVerify iv -> 
+				resumeVerifyKeyContent k f iv
+			_ -> verifyKeyContent k f
+
+-- When possible, does an incremental verification, because that can be
+-- faster. Eg, the VURL backend can need to try multiple checksums and only
+-- with an incremental verification does it avoid reading files twice.
+verifyKeyContent :: Key -> RawFilePath -> Annex Bool
+verifyKeyContent k f = verifyKeySize k f <&&> verifyKeyContent' k f
+
+-- Does not verify size.
+verifyKeyContent' :: Key -> RawFilePath -> Annex Bool
+verifyKeyContent' k f = 
+	Backend.maybeLookupBackendVariety (fromKey keyVariety k) >>= \case
+		Nothing -> return True
+		Just b -> case (Types.Backend.verifyKeyContentIncrementally b, Types.Backend.verifyKeyContent b) of
+			(Nothing, Nothing) -> return True
+			(Just mkiv, mverifier) -> do
+				iv <- mkiv k
+				showAction (UnquotedString (descIncrementalVerifier iv))
+				res <- liftIO $ catchDefaultIO Nothing $
+					withBinaryFile (fromRawFilePath f) ReadMode $ \h -> do
+						feedIncrementalVerifier h iv
+						finalizeIncrementalVerifier iv
+				case res of
+					Just res' -> return res'
+					Nothing -> case mverifier of
+						Nothing -> return True
+						Just verifier -> verifier k f
+			(Nothing, Just verifier) -> verifier k f
+
+resumeVerifyKeyContent :: Key -> RawFilePath -> IncrementalVerifier -> Annex Bool
+resumeVerifyKeyContent k f iv = liftIO (positionIncrementalVerifier iv) >>= \case
+	Nothing -> fallback
+	Just endpos -> do
+		fsz <- liftIO $ catchDefaultIO 0 $ getFileSize f
+		if fsz < endpos
+			then fallback
+			else case fromKey keySize k of
+				Just size | fsz /= size -> return False
+				_ -> go fsz endpos >>= \case
+					Just v -> return v
+					Nothing -> fallback
+  where
+	fallback = verifyKeyContent k f
+
+	go fsz endpos
+		| fsz == endpos =
+			liftIO $ catchDefaultIO (Just False) $
+				finalizeIncrementalVerifier iv
+		| otherwise = do
+			showAction (UnquotedString (descIncrementalVerifier iv))
+			liftIO $ catchDefaultIO (Just False) $
+				withBinaryFile (fromRawFilePath f) ReadMode $ \h -> do
+					hSeek h AbsoluteSeek endpos
+					feedIncrementalVerifier h iv
+					finalizeIncrementalVerifier iv
+	
+feedIncrementalVerifier :: Handle -> IncrementalVerifier -> IO ()
+feedIncrementalVerifier h iv = do
+	b <- S.hGetSome h chunk
+	if S.null b
+		then return ()
+		else do
+			updateIncrementalVerifier iv b
+			feedIncrementalVerifier h iv
+  where
+	chunk = 65536
+
+verifyKeySize :: Key -> RawFilePath -> Annex Bool
+verifyKeySize k f = case fromKey keySize k of
+	Just size -> do
+		size' <- liftIO $ catchDefaultIO 0 $ getFileSize f
+		return (size' == size)
+	Nothing -> return True
+
+warnUnverifiableInsecure :: Key -> Annex ()
+warnUnverifiableInsecure k = warning $ UnquotedString $ unwords
+	[ "Getting " ++ kv ++ " keys with this remote is not secure;"
+	, "the content cannot be verified to be correct."
+	, "(Use annex.security.allow-unverified-downloads to bypass"
+	, "this safety check.)"
+	]
+  where
+	kv = decodeBS (formatKeyVariety (fromKey keyVariety k))
+
+isVerifiable :: Key -> Annex Bool
+isVerifiable k = maybe False (isJust . Types.Backend.verifyKeyContent) 
+	<$> Backend.maybeLookupBackendVariety (fromKey keyVariety k)
+
+startVerifyKeyContentIncrementally :: VerifyConfig -> Key -> Annex (Maybe IncrementalVerifier)
+startVerifyKeyContentIncrementally verifyconfig k = 
+	ifM (shouldVerify verifyconfig)
+		( Backend.maybeLookupBackendVariety (fromKey keyVariety k) >>= \case
+			Just b -> case Types.Backend.verifyKeyContentIncrementally b of
+				Just v -> Just <$> v k
+				Nothing -> return Nothing
+			Nothing -> return Nothing
+		, return Nothing
+		)
+
+finishVerifyKeyContentIncrementally :: Maybe IncrementalVerifier -> Annex (Bool, Verification)
+finishVerifyKeyContentIncrementally Nothing = 
+	return (True, UnVerified)
+finishVerifyKeyContentIncrementally (Just iv) =
+	liftIO (finalizeIncrementalVerifier iv) >>= \case
+		Just True -> return (True, Verified)
+		Just False -> do
+			warning "verification of content failed"
+			return (False, UnVerified)
+		-- Incremental verification was not able to be done.
+		Nothing -> return (True, UnVerified)
+
+verifyKeyContentIncrementally :: VerifyConfig -> Key -> (Maybe IncrementalVerifier -> Annex ()) -> Annex Verification
+verifyKeyContentIncrementally verifyconfig k a = do
+	miv <- startVerifyKeyContentIncrementally verifyconfig k
+	a miv
+	snd <$> finishVerifyKeyContentIncrementally miv
+
+-- | Runs a writer action that retrieves to a file. In another thread,
+-- reads the file as it grows, and feeds it to the incremental verifier.
+-- 
+-- Once the writer finishes, this returns quickly. It may not feed
+-- the entire content of the file to the incremental verifier.
+--
+-- The file does not need to exist yet when this is called. It will wait
+-- for the file to appear before opening it and starting verification.
+--
+-- This is not supported for all OSs, and on OS's where it is not
+-- supported, verification will not happen.
+--
+-- The writer probably needs to be another process. If the file is being
+-- written directly by git-annex, the haskell RTS will prevent opening it
+-- for read at the same time, and verification will not happen.
+--
+-- Note that there are situations where the file may fail to verify despite
+-- having the correct content. For example, when the file is written out
+-- of order, or gets replaced part way through. To deal with such cases,
+-- when verification fails, it should not be treated as if the file's
+-- content is known to be incorrect, but instead as an indication that the
+-- file should be verified again, once it's done being written to.
+--
+-- (It is also possible, in theory, for a file to verify despite having
+-- incorrect content. For that to happen, the file would need to have
+-- the right content when this checks it, but then the content gets
+-- changed later by whatever is writing to the file.)
+--
+-- This should be fairly efficient, reading from the disk cache,
+-- as long as the writer does not get very far ahead of it. However,
+-- there are situations where it would be much less expensive to verify
+-- chunks as they are being written. For example, when resuming with
+-- a lot of content in the file, all that content needs to be read,
+-- and if the disk is slow, the reader may never catch up to the writer,
+-- and the disk cache may never speed up reads. So this should only be
+-- used when there's not a better way to incrementally verify.
+tailVerify :: Maybe IncrementalVerifier -> RawFilePath -> Annex a -> Annex a
+tailVerify (Just iv) f writer = do
+	finished <- liftIO newEmptyTMVarIO
+	t <- liftIO $ async $ tailVerify' iv f finished
+	let finishtail = do
+		liftIO $ atomically $ putTMVar finished ()
+		liftIO (wait t)
+	writer `finally` finishtail
+tailVerify Nothing _ writer = writer
+
+tailVerify' :: IncrementalVerifier -> RawFilePath -> TMVar () -> IO ()
+#if WITH_INOTIFY
+tailVerify' iv f finished = 
+	tryNonAsync go >>= \case
+		Right r -> return r
+		Left _ -> unableIncrementalVerifier iv
+  where
+	-- Watch the directory containing the file, and wait for
+	-- the file to be modified. It's possible that the file already
+	-- exists before the downloader starts, but it replaces it instead
+	-- of resuming, and waiting for modification deals with such
+	-- situations.
+	inotifydirchange i cont =
+		INotify.addWatch i [INotify.Modify] dir $ \case
+			-- Ignore changes to other files in the directory.
+			INotify.Modified { INotify.maybeFilePath = fn }
+				| fn == Just basef -> cont
+			_ -> noop
+	  where
+		(dir, basef) = P.splitFileName f
+	
+	inotifyfilechange i = INotify.addWatch i [INotify.Modify] f . const
+
+	go = INotify.withINotify $ \i -> do
+		modified <- newEmptyTMVarIO
+		let signalmodified = atomically $ void $ tryPutTMVar modified ()
+		wd <- inotifydirchange i signalmodified
+		let cleanup = void . tryNonAsync . INotify.removeWatch
+		let stop w = do
+			cleanup w
+			unableIncrementalVerifier iv
+		waitopen modified >>= \case
+			Nothing -> stop wd
+			Just h -> do
+				cleanup wd
+				wf <- inotifyfilechange i signalmodified
+				tryNonAsync (follow h modified) >>= \case
+					Left _ -> stop wf
+					Right () -> cleanup wf
+				hClose h
+
+	waitopen modified = do
+		v <- atomically $
+			(Just <$> takeTMVar modified)
+				`orElse` 
+			((const Nothing) <$> takeTMVar finished)
+		case v of
+			Just () -> do
+				r <- tryNonAsync $
+					tryWhenExists (openBinaryFile (fromRawFilePath f) ReadMode) >>= \case
+						Just h -> return (Just h)
+						-- File does not exist, must have been
+						-- deleted. Wait for next modification
+						-- and try again.
+						Nothing -> waitopen modified
+				case r of
+					Right r' -> return r'
+					-- Permission error prevents
+					-- reading, or this same process
+					-- is writing to the file,
+					-- and it cannot be read at the
+					-- same time.
+					Left _ -> return Nothing
+			-- finished without the file being modified
+			Nothing -> return Nothing
+	
+	follow h modified = do
+		b <- S.hGetNonBlocking h chunk
+		if S.null b
+			then do
+				-- We've caught up to the writer.
+				-- Wait for the file to get modified again,
+				-- or until we're told it is done being
+				-- written.
+				cont <- atomically $
+					(const (follow h modified)
+						<$> takeTMVar modified)
+							`orElse`
+					(const (return ())
+						<$> takeTMVar finished)
+				cont
+			else do
+				updateIncrementalVerifier iv b
+				atomically (tryTakeTMVar finished) >>= \case
+					Nothing -> follow h modified
+					Just () -> return ()
+
+	chunk = 65536
+#else
+tailVerify' iv _ _ = unableIncrementalVerifier iv
+#endif
diff --git a/Annex/Version.hs b/Annex/Version.hs
new file mode 100644
index 0000000000..c3504cfd93
--- /dev/null
+++ b/Annex/Version.hs
@@ -0,0 +1,68 @@
+{- git-annex repository versioning
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Annex.Version where
+
+import Annex.Common
+import Config
+import Git.Types
+import Types.RepoVersion
+import qualified Annex
+
+import qualified Data.Map as M
+
+defaultVersion :: RepoVersion
+defaultVersion = RepoVersion 10
+
+latestVersion :: RepoVersion
+latestVersion = RepoVersion 10
+
+supportedVersions :: [RepoVersion]
+supportedVersions = map RepoVersion [8, 9, 10]
+
+upgradeableVersions :: [RepoVersion]
+#ifndef mingw32_HOST_OS
+upgradeableVersions = map RepoVersion [0..10]
+#else
+upgradeableVersions = map RepoVersion [2..10]
+#endif
+
+autoUpgradeableVersions :: M.Map RepoVersion RepoVersion
+autoUpgradeableVersions = M.fromList
+	[ (RepoVersion 3, defaultVersion)
+	, (RepoVersion 4, defaultVersion)
+	, (RepoVersion 5, defaultVersion)
+	, (RepoVersion 6, defaultVersion)
+	, (RepoVersion 7, defaultVersion)
+	, (RepoVersion 8, defaultVersion)
+	, (RepoVersion 9, defaultVersion)
+	]
+
+versionField :: ConfigKey
+versionField = annexConfig "version"
+
+getVersion :: Annex (Maybe RepoVersion)
+getVersion = annexVersion <$> Annex.getGitConfig
+
+setVersion :: RepoVersion -> Annex ()
+setVersion (RepoVersion v) = setConfig versionField (show v)
+
+removeVersion :: Annex ()
+removeVersion = unsetConfig versionField
+
+versionSupportsFilterProcess :: Maybe RepoVersion -> Bool
+versionSupportsFilterProcess (Just v) 
+	| v >= RepoVersion 9 = True
+versionSupportsFilterProcess _ = False
+
+versionNeedsWritableContentFiles :: Maybe RepoVersion -> Bool
+versionNeedsWritableContentFiles (Just v) 
+	| v >= RepoVersion 10 = False
+versionNeedsWritableContentFiles _ = True
diff --git a/Annex/View.hs b/Annex/View.hs
new file mode 100644
index 0000000000..482ce17c3a
--- /dev/null
+++ b/Annex/View.hs
@@ -0,0 +1,636 @@
+{- metadata based branch views
+ -
+ - Copyright 2014-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, PackageImports #-}
+
+module Annex.View where
+
+import Annex.Common
+import Annex.View.ViewedFile
+import Types.View
+import Types.AdjustedBranch
+import Types.MetaData
+import Annex.MetaData
+import qualified Annex
+import qualified Annex.Branch
+import qualified Git
+import qualified Git.DiffTree as DiffTree
+import qualified Git.Branch
+import qualified Git.LsFiles
+import qualified Git.LsTree
+import qualified Git.Ref
+import Git.CatFile
+import Git.UpdateIndex
+import Git.Sha
+import Git.Types
+import Git.FilePath
+import Annex.WorkTree
+import Annex.GitOverlay
+import Annex.Link
+import Annex.CatFile
+import Annex.Concurrent
+import Annex.Content.Presence
+import Logs
+import Logs.MetaData
+import Logs.View
+import Utility.Glob
+import Types.Command
+import CmdLine.Action
+import qualified Utility.RawFilePath as R
+
+import qualified Data.Text as T
+import qualified Data.ByteString as B
+import qualified Data.Set as S
+import qualified Data.Map as M
+import qualified System.FilePath.ByteString as P
+import Control.Concurrent.Async
+import "mtl" Control.Monad.Writer
+
+{- Each visible ViewFilter in a view results in another level of
+ - subdirectory nesting. When a file matches multiple ways, it will appear
+ - in multiple subdirectories. This means there is a bit of an exponential
+ - blowup with a single file appearing in a crazy number of places!
+ -
+ - Capping the view size to 5 is reasonable; why wants to dig
+ - through 5+ levels of subdirectories to find anything?
+ -}
+viewTooLarge :: View -> Bool
+viewTooLarge view = visibleViewSize view > 5
+
+visibleViewSize :: View -> Int
+visibleViewSize = length . filter viewVisible . viewComponents
+
+{- Parses field=value, field!=value, field?=value, tag, !tag, and ?tag
+ -
+ - Note that the field may not be a legal metadata field name,
+ - but it's let through anyway.
+ - This is useful when matching on directory names with spaces,
+ - which are not legal MetaFields.
+ -}
+parseViewParam :: ViewUnset -> String -> (MetaField, ViewFilter)
+parseViewParam vu s = case separate (== '=') s of
+	('!':tag, []) | not (null tag) ->
+		( tagMetaField
+		, mkExcludeValues tag
+		)
+	('?':tag, []) | not (null tag) ->
+		( tagMetaField
+		, mkFilterOrUnsetValues tag
+		)
+	(tag, []) ->
+		( tagMetaField
+		, mkFilterValues tag
+		)
+	(field, wanted)
+		| end field == "!" ->
+			( mkMetaFieldUnchecked (T.pack (beginning field))
+			, mkExcludeValues wanted
+			)
+		| end field == "?" ->
+			( mkMetaFieldUnchecked (T.pack (beginning field))
+			, mkFilterOrUnsetValues wanted
+			)
+		| otherwise ->
+			( mkMetaFieldUnchecked (T.pack field)
+			, mkFilterValues wanted
+			)
+  where
+	mkExcludeValues = ExcludeValues . S.singleton . toMetaValue . encodeBS
+	mkFilterValues v
+		| any (`elem` v) ['*', '?'] = FilterGlob v
+		| otherwise = FilterValues $ S.singleton $ toMetaValue $ encodeBS v
+	mkFilterOrUnsetValues v
+		| any (`elem` v) ['*', '?'] = FilterGlobOrUnset v vu
+		| otherwise = FilterValuesOrUnset (S.singleton $ toMetaValue $ encodeBS v) vu
+
+data ViewChange = Unchanged | Narrowing | Widening
+	deriving (Ord, Eq, Show)
+
+{- Updates a view, adding new fields to filter on (Narrowing), 
+ - or allowing new values in an existing field (Widening). -}
+refineView :: View -> [(MetaField, ViewFilter)] -> (View, ViewChange)
+refineView origview = checksize . calc Unchanged origview
+  where
+	calc c v [] = (v, c)
+	calc c v ((f, vf):rest) =
+		let (v', c') = refine v f vf
+		in calc (max c c') v' rest
+
+	refine view field vf
+		| field `elem` map viewField (viewComponents view) =
+			let (components', viewchanges) = runWriter $
+				mapM (\c -> updateViewComponent c field vf) (viewComponents view)
+			    viewchange = if field `elem` map viewField (viewComponents origview)
+				then maximum viewchanges
+				else Narrowing
+			in (view { viewComponents = components' }, viewchange)
+		| otherwise = 
+			let component = mkViewComponent field vf
+			    view' = view { viewComponents = component : viewComponents view }
+			in (view', Narrowing)
+	
+	checksize r@(v, _)
+		| viewTooLarge v = giveup $ "View is too large (" ++ show (visibleViewSize v) ++ " levels of subdirectories)"
+		| otherwise = r
+
+updateViewComponent :: ViewComponent -> MetaField -> ViewFilter -> Writer [ViewChange] ViewComponent
+updateViewComponent c field vf
+	| viewField c == field = do
+		let (newvf, viewchange) = combineViewFilter (viewFilter c) vf
+		tell [viewchange]
+		return $ mkViewComponent field newvf
+	| otherwise = return c
+
+{- Adds an additional filter to a view. This can only result in narrowing
+ - the view. Multivalued filters are added in non-visible form. -}
+filterView :: View -> [(MetaField, ViewFilter)] -> View
+filterView v vs = v { viewComponents = viewComponents f' ++ viewComponents v}
+  where
+	f = fst $ refineView (v {viewComponents = []}) vs
+	f' = f { viewComponents = map toinvisible (viewComponents f) }
+	toinvisible c = c { viewVisible = False }
+
+{- Combine old and new ViewFilters, yielding a result that matches
+ - either old+new, or only new. Which depends on the types of things
+ - being combined.
+ -}
+combineViewFilter :: ViewFilter -> ViewFilter -> (ViewFilter, ViewChange)
+combineViewFilter old@(FilterValues olds) (FilterValues news)
+	| combined == old = (combined, Unchanged)
+	| otherwise = (combined, Widening)
+  where
+	combined = FilterValues (S.union olds news)
+combineViewFilter old@(ExcludeValues olds) (ExcludeValues news)
+	| combined == old = (combined, Unchanged)
+	| otherwise = (combined, Narrowing)
+  where
+	combined = ExcludeValues (S.union olds news)
+{- If we have FilterValues and change to a FilterGlob,
+ - it's always a widening change, because the glob could match other
+ - values. OTOH, going the other way, it's a Narrowing change if the old
+ - glob matches all the new FilterValues. -}
+combineViewFilter (FilterValues _) newglob@(FilterGlob _) =
+	(newglob, Widening)
+combineViewFilter (FilterGlob oldglob) new@(FilterValues s)
+	| all (matchGlob (compileGlob oldglob CaseInsensitive (GlobFilePath False)) . decodeBS . fromMetaValue) (S.toList s) = (new, Narrowing)
+	| otherwise = (new, Widening)
+{- With two globs, the old one is discarded, and the new one is used.
+ - We can tell if that's a narrowing change by checking if the old
+ - glob matches the new glob. For example, "*" matches "foo*",
+ - so that's narrowing. While "f?o" does not match "f??", so that's
+ - widening. -}
+combineViewFilter (FilterGlob old) newglob@(FilterGlob new)
+	| old == new = (newglob, Unchanged)
+	| matchGlob (compileGlob old CaseInsensitive (GlobFilePath False)) new = (newglob, Narrowing)
+	| otherwise = (newglob, Widening)
+{- Combining FilterValuesOrUnset and FilterGlobOrUnset with FilterValues
+ - and FilterGlob maintains the OrUnset if the second parameter has it,
+ - and is otherwise the same as combining without OrUnset, except that
+ - eliminating the OrUnset can be narrowing, and adding it can be widening. -}
+combineViewFilter old@(FilterValuesOrUnset olds _) (FilterValuesOrUnset news newvu)
+	| combined == old = (combined, Unchanged)
+	| otherwise = (combined, Widening)
+  where
+	combined = FilterValuesOrUnset (S.union olds news) newvu
+combineViewFilter (FilterValues olds) (FilterValuesOrUnset news vu) =
+	(combined, Widening)
+  where
+	combined = FilterValuesOrUnset (S.union olds news) vu
+combineViewFilter old@(FilterValuesOrUnset olds _) (FilterValues news)
+	| combined == old = (combined, Narrowing)
+	| otherwise = (combined, Widening)
+  where
+	combined = FilterValues (S.union olds news)
+combineViewFilter (FilterValuesOrUnset _ _) newglob@(FilterGlob _) =
+	(newglob, Widening)
+combineViewFilter (FilterGlob _) new@(FilterValuesOrUnset _ _) =
+	(new, Widening)
+combineViewFilter (FilterValues _) newglob@(FilterGlobOrUnset _ _) =
+	(newglob, Widening)
+combineViewFilter (FilterValuesOrUnset _ _) newglob@(FilterGlobOrUnset _ _) =
+	(newglob, Widening)
+combineViewFilter (FilterGlobOrUnset oldglob _) new@(FilterValues _) =
+	combineViewFilter (FilterGlob oldglob) new
+combineViewFilter (FilterGlobOrUnset oldglob _) new@(FilterValuesOrUnset _ _) =
+	let (_, viewchange) = combineViewFilter (FilterGlob oldglob) new
+	in (new, viewchange)
+combineViewFilter (FilterGlobOrUnset old _) newglob@(FilterGlobOrUnset new _)
+	| old == new = (newglob, Unchanged)
+	| matchGlob (compileGlob old CaseInsensitive (GlobFilePath False)) new = (newglob, Narrowing)
+	| otherwise = (newglob, Widening)
+combineViewFilter (FilterGlob _) newglob@(FilterGlobOrUnset _ _) =
+	(newglob, Widening)
+combineViewFilter (FilterGlobOrUnset _ _) newglob@(FilterGlob _) =
+	(newglob, Narrowing)
+{- There is not a way to filter a value and also apply an exclude. So:
+ - When adding an exclude to a filter, use only the exclude.
+ - When adding a filter to an exclude, use only the filter. -}
+combineViewFilter (FilterGlob _) new@(ExcludeValues _) = (new, Narrowing)
+combineViewFilter (ExcludeValues _) new@(FilterGlob _) = (new, Widening)
+combineViewFilter (FilterValues _) new@(ExcludeValues _) = (new, Narrowing)
+combineViewFilter (ExcludeValues _) new@(FilterValues _) = (new, Widening)
+combineViewFilter (FilterValuesOrUnset _ _) new@(ExcludeValues _) = (new, Narrowing)
+combineViewFilter (ExcludeValues _) new@(FilterValuesOrUnset _ _) = (new, Widening)
+combineViewFilter (FilterGlobOrUnset _ _) new@(ExcludeValues _) = (new, Narrowing)
+combineViewFilter (ExcludeValues _) new@(FilterGlobOrUnset _ _) = (new, Widening)
+
+{- Generates views for a file from a branch, based on its metadata
+ - and the filename used in the branch.
+ -
+ - Note that a file may appear multiple times in a view, when it
+ - has multiple matching values for a MetaField used in the View.
+ -
+ - Of course if its MetaData does not match the View, it won't appear at
+ - all.
+ -
+ - Note that for efficiency, it's useful to partially
+ - evaluate this function with the view parameter and reuse
+ - the result. The globs in the view will then be compiled and memoized.
+ -}
+viewedFiles :: View -> MkViewedFile -> FilePath -> MetaData -> [ViewedFile]
+viewedFiles view = 
+	let matchers = map viewComponentMatcher (viewComponents view)
+	in \mkviewedfile file metadata ->
+		let matches = map (\m -> m metadata) matchers
+		in if any isNothing matches
+			then []
+			else 
+				let paths = pathProduct $
+					map (map toviewpath) (visible matches)
+				in if null paths
+					then [mkviewedfile file]
+					else map (</> mkviewedfile file) paths
+  where
+	visible = map (fromJust . snd) .
+		filter (viewVisible . fst) .
+		zip (viewComponents view)
+	
+	toviewpath (MatchingMetaValue v) = toViewPath v
+	toviewpath (MatchingUnset v) = toViewPath (toMetaValue (encodeBS v))
+
+data MatchingValue = MatchingMetaValue MetaValue | MatchingUnset String
+
+{- Checks if metadata matches a ViewComponent filter, and if so
+ - returns the value, or values that match. Self-memoizing on ViewComponent. -}
+viewComponentMatcher :: ViewComponent -> (MetaData -> Maybe [MatchingValue])
+viewComponentMatcher viewcomponent = \metadata -> 
+	matcher Nothing (viewFilter viewcomponent)
+		(currentMetaDataValues metafield metadata)
+  where
+	metafield = viewField viewcomponent
+	matcher matchunset (FilterValues s) = 
+		\values -> setmatches matchunset $ S.intersection s values
+	matcher matchunset (FilterGlob glob) =
+		let cglob = compileGlob glob CaseInsensitive (GlobFilePath False)
+		in \values -> setmatches matchunset $
+			S.filter (matchGlob cglob . decodeBS . fromMetaValue) values
+	matcher _ (ExcludeValues excludes) = 
+		\values -> 
+			if S.null (S.intersection values excludes)
+				then Just []
+				else Nothing
+	matcher _ (FilterValuesOrUnset s (ViewUnset u)) =
+		matcher (Just [MatchingUnset u]) (FilterValues s)
+	matcher _ (FilterGlobOrUnset glob (ViewUnset u)) =
+		matcher (Just [MatchingUnset u]) (FilterGlob glob)
+
+	setmatches matchunset s
+		| S.null s = matchunset 
+		| otherwise = Just $
+			map MatchingMetaValue (S.toList s)
+
+-- This is '∕', a unicode character that displays the same as '/' but is
+-- not it. It is encoded using the filesystem encoding, which allows it
+-- to be used even when not in a unicode capable locale.
+pseudoSlash :: String
+pseudoSlash = "\56546\56456\56469"
+
+-- And this is '╲' similarly.
+pseudoBackslash :: String
+pseudoBackslash = "\56546\56469\56498"
+
+-- And this is '﹕' similarly.
+pseudoColon :: String
+pseudoColon = "\56559\56505\56469"
+
+toViewPath :: MetaValue -> FilePath
+toViewPath = escapepseudo [] . decodeBS . fromMetaValue
+  where
+	escapepseudo s ('/':cs) = escapepseudo (pseudoSlash:s) cs
+	escapepseudo s ('\\':cs) = escapepseudo (pseudoBackslash:s) cs
+	escapepseudo s (':':cs) = escapepseudo (pseudoColon:s) cs
+	escapepseudo s ('%':cs) = escapepseudo ("%%":s) cs
+	escapepseudo s (c1:c2:c3:cs)
+		| [c1,c2,c3] == pseudoSlash = escapepseudo ("%":pseudoSlash:s) cs
+		| [c1,c2,c3] == pseudoBackslash = escapepseudo ("%":pseudoBackslash:s) cs
+		| [c1,c2,c3] == pseudoColon = escapepseudo ("%":pseudoColon:s) cs
+		| otherwise = escapepseudo ([c1]:s) (c2:c3:cs)
+	escapepseudo s (c:cs) = escapepseudo ([c]:s) cs
+	escapepseudo s [] = concat (reverse s)
+
+fromViewPath :: FilePath -> MetaValue
+fromViewPath = toMetaValue . encodeBS . deescapepseudo []
+  where
+	deescapepseudo s ('%':escapedc:cs) = deescapepseudo ([escapedc]:s) cs
+	deescapepseudo s (c1:c2:c3:cs)
+		| [c1,c2,c3] == pseudoSlash = deescapepseudo ("/":s) cs
+		| [c1,c2,c3] == pseudoBackslash = deescapepseudo ("\\":s) cs
+		| [c1,c2,c3] == pseudoColon = deescapepseudo (":":s) cs
+		| otherwise = deescapepseudo ([c1]:s) (c2:c3:cs)
+	deescapepseudo s cs = concat (reverse (cs:s))
+
+prop_viewPath_roundtrips :: MetaValue -> Bool
+prop_viewPath_roundtrips v = fromViewPath (toViewPath v) == v
+
+pathProduct :: [[FilePath]] -> [FilePath]
+pathProduct [] = []
+pathProduct (l:ls) = foldl combinel l ls
+  where
+	combinel xs ys = [combine x y | x <- xs, y <- ys]
+
+{- Extracts the metadata from a ViewedFile, based on the view that was used
+ - to construct it.
+ -
+ - Derived metadata is excluded.
+ -}
+fromView :: View -> ViewedFile -> MetaData
+fromView view f = MetaData $ m `M.difference` derived
+  where
+	m = M.fromList $ map convfield $
+		filter (not . isviewunset) (zip visible values)
+	visible = filter viewVisible (viewComponents view)
+	paths = splitDirectories (dropFileName f)
+	values = map (S.singleton . fromViewPath) paths
+	MetaData derived = getViewedFileMetaData f
+	convfield (vc, v) = (viewField vc, v)
+
+	-- When a directory is the one used to hold files that don't
+	-- have the metadata set, don't include it in the MetaData.
+	isviewunset (vc, v) = case viewFilter vc of
+		FilterValues {} -> False
+		FilterGlob {} -> False
+		ExcludeValues {} -> False
+		FilterValuesOrUnset _ (ViewUnset vu) -> isviewunset' vu v
+		FilterGlobOrUnset _ (ViewUnset vu) -> isviewunset' vu v
+	isviewunset' vu v = S.member (fromViewPath vu) v
+
+{- Constructing a view that will match arbitrary metadata, and applying
+ - it to a file yields a set of ViewedFile which all contain the same
+ - MetaFields that were present in the input metadata
+ - (excluding fields that are not visible). -}
+prop_view_roundtrips :: AssociatedFile -> MetaData -> Bool -> Bool
+prop_view_roundtrips (AssociatedFile Nothing) _ _ = True
+prop_view_roundtrips (AssociatedFile (Just f)) metadata visible = or
+	[ B.null (P.takeFileName f) && B.null (P.takeDirectory f)
+	, viewTooLarge view
+	, all hasfields (viewedFiles view (viewedFileFromReference' Nothing Nothing) (fromRawFilePath f) metadata)
+	]
+  where
+	view = View (Git.Ref "foo") $
+		map (\(mf, mv) -> ViewComponent mf (FilterValues $ S.filter (not . B.null . fromMetaValue) mv) visible)
+			(fromMetaData metadata)
+	visiblefields = sort (map viewField $ filter viewVisible (viewComponents view))
+	hasfields fv = sort (map fst (fromMetaData (fromView view fv))) == visiblefields
+
+{- A directory foo/bar/baz/ is turned into metadata fields
+ - /=foo, foo/=bar, foo/bar/=baz.
+ -
+ - Note that this may generate MetaFields that legalField rejects.
+ - This is necessary to have a 1:1 mapping between directory names and
+ - fields. So this MetaData cannot safely be serialized. -}
+getDirMetaData :: FilePath -> MetaData
+getDirMetaData d = MetaData $ M.fromList $ zip fields values
+  where
+	dirs = splitDirectories d
+	fields = map (mkMetaFieldUnchecked . T.pack . addTrailingPathSeparator . joinPath)
+		(inits dirs)
+	values = map (S.singleton . toMetaValue . encodeBS . fromMaybe "" . headMaybe)
+		(tails dirs)
+
+getWorkTreeMetaData :: FilePath -> MetaData
+getWorkTreeMetaData = getDirMetaData . dropFileName
+
+getViewedFileMetaData :: FilePath -> MetaData
+getViewedFileMetaData = getDirMetaData . dirFromViewedFile . takeFileName
+
+{- Applies a view to the currently checked out branch, generating a new
+ - branch for the view.
+ -}
+applyView :: View -> Maybe Adjustment -> Annex Git.Branch
+applyView v ma = do
+	gc <- Annex.getGitConfig
+	applyView' (viewedFileFromReference gc) getWorkTreeMetaData v ma
+
+{- Generates a new branch for a View, which must be a more narrow
+ - version of the View originally used to generate the currently
+ - checked out branch. That is, it must match a subset of the files
+ - in view, not any others.
+ -}
+narrowView :: View -> Maybe Adjustment -> Annex Git.Branch
+narrowView = applyView' viewedFileReuse getViewedFileMetaData
+
+{- Go through each staged file.
+ - If the file is not annexed, skip it, unless it's a dotfile in the top,
+ - or a file in a dotdir in the top. 
+ - Look up the metadata of annexed files, and generate any ViewedFiles,
+ - and stage them.
+ -}
+applyView' :: MkViewedFile -> (FilePath -> MetaData) -> View -> Maybe Adjustment -> Annex Git.Branch
+applyView' mkviewedfile getfilemetadata view madj = do
+	top <- fromRepo Git.repoPath
+	(l, clean) <- inRepo $ Git.LsFiles.inRepoDetails [] [top]
+	applyView'' mkviewedfile getfilemetadata view madj l clean $ 
+		\(f, sha, mode) -> do
+			topf <- inRepo (toTopFilePath f)
+			k <- lookupKey f
+			return (topf, sha, toTreeItemType mode, k)
+	genViewBranch view madj
+
+applyView''
+	:: MkViewedFile
+	-> (FilePath -> MetaData)
+	-> View
+	-> Maybe Adjustment
+	-> [t]
+	-> IO Bool
+	-> (t -> Annex (TopFilePath, Sha, Maybe TreeItemType, Maybe Key))
+	-> Annex ()
+applyView'' mkviewedfile getfilemetadata view madj l clean conv = do
+	viewg <- withNewViewIndex gitRepo
+	withUpdateIndex viewg $ \uh -> do
+		g <- Annex.gitRepo
+		gc <- Annex.getGitConfig
+		-- Streaming the metadata like this is an optimisation.
+		catObjectStream g $ \mdfeeder mdcloser mdreader -> do
+			tid <- liftIO . async =<< forkState
+				(getmetadata gc mdfeeder mdcloser l)
+			process uh mdreader
+			join (liftIO (wait tid))
+			liftIO $ void clean
+  where
+	genviewedfiles = viewedFiles view mkviewedfile -- enables memoization
+
+	getmetadata _ _ mdcloser [] = liftIO mdcloser
+	getmetadata gc mdfeeder mdcloser (t:ts) = do
+		v@(topf, _sha, _treeitemtype, mkey) <- conv t
+		let feed mdlogf = liftIO $ mdfeeder
+			(v, Git.Ref.branchFileRef Annex.Branch.fullname mdlogf)
+		case mkey of
+			Just key -> feed (metaDataLogFile gc key)
+			Nothing
+				-- Handle toplevel dotfiles that are not
+				-- annexed files by feeding through a query
+				-- for dummy metadata. Calling
+				-- Git.UpdateIndex.streamUpdateIndex'
+				-- here would race with process's calls
+				-- to it.
+				| "." `B.isPrefixOf` getTopFilePath topf ->
+					feed "dummy"
+				| otherwise -> noop
+		getmetadata gc mdfeeder mdcloser ts
+
+	process uh mdreader = liftIO mdreader >>= \case
+		Just ((topf, _, mtreeitemtype, Just k), mdlog) -> do
+			let metadata = maybe emptyMetaData parseCurrentMetaData mdlog
+			let f = fromRawFilePath $ getTopFilePath topf
+			let metadata' = getfilemetadata f `unionMetaData` metadata
+			forM_ (genviewedfiles f metadata') $ \fv -> do
+				f' <- fromRepo (fromTopFilePath $ asTopFilePath $ toRawFilePath fv)
+				stagefile uh f' k mtreeitemtype
+			process uh mdreader
+		Just ((topf, sha, Just treeitemtype, Nothing), _) -> do
+			liftIO $ Git.UpdateIndex.streamUpdateIndex' uh $
+				pureStreamer $ updateIndexLine sha treeitemtype topf
+			process uh mdreader
+		Just _ -> process uh mdreader
+		Nothing -> return ()
+	
+	stagefile uh f k mtreeitemtype = case madj of
+		Nothing -> stagesymlink uh f k
+		Just (LinkAdjustment UnlockAdjustment) ->
+			stagepointerfile uh f k mtreeitemtype
+		Just (LinkPresentAdjustment UnlockPresentAdjustment) ->
+			ifM (inAnnex k)
+				( stagepointerfile uh f k mtreeitemtype
+				, stagesymlink uh f k
+				)
+		Just (PresenceAdjustment HideMissingAdjustment (Just UnlockAdjustment)) ->
+			whenM (inAnnex k) $
+				stagepointerfile uh f k mtreeitemtype
+		Just (PresenceAdjustment HideMissingAdjustment _) ->
+			whenM (inAnnex k) $
+				stagesymlink uh f k
+		_ -> stagesymlink uh f k
+
+	stagesymlink uh f k = do
+		linktarget <- calcRepo (gitAnnexLink f k)
+		sha <- hashSymlink linktarget
+		liftIO . Git.UpdateIndex.streamUpdateIndex' uh
+			=<< inRepo (Git.UpdateIndex.stageSymlink f sha)
+	
+	stagepointerfile uh f k mtreeitemtype = do
+		let treeitemtype = if mtreeitemtype == Just TreeExecutable
+			then TreeExecutable
+			else TreeFile
+		sha <- hashPointerFile k
+		liftIO . Git.UpdateIndex.streamUpdateIndex' uh
+			=<< inRepo (Git.UpdateIndex.stageFile sha treeitemtype f)
+
+{- Updates the current view with any changes that have been made to its
+ - parent branch or the metadata since the view was created or last updated.
+ -
+ - When there were changes, returns a ref to a commit for the updated view.
+ - Does not update the view branch with it.
+ -
+ - This is not very optimised. An incremental update would be possible to
+ - implement and would be faster, but more complicated.
+ -}
+updateView :: View -> Maybe Adjustment -> Annex (Maybe Git.Ref)
+updateView view madj = do
+	(l, clean) <- inRepo $ Git.LsTree.lsTree
+		Git.LsTree.LsTreeRecursive
+		(Git.LsTree.LsTreeLong True)
+		(viewParentBranch view)
+	gc <- Annex.getGitConfig
+	applyView'' (viewedFileFromReference gc) getWorkTreeMetaData view madj l clean $
+		\ti -> do
+			let ref = Git.Ref.branchFileRef (viewParentBranch view)
+				(getTopFilePath (Git.LsTree.file ti))
+			k <- case Git.LsTree.size ti of
+				Nothing -> catKey ref
+				Just sz -> catKey' ref sz
+			return
+				( (Git.LsTree.file ti)
+				, (Git.LsTree.sha ti)
+				, (toTreeItemType (Git.LsTree.mode ti))
+				, k
+				)
+	oldcommit <- inRepo $ Git.Ref.sha (branchView view madj)
+	oldtree <- maybe (pure Nothing) (inRepo . Git.Ref.tree) oldcommit
+	newtree <- withViewIndex $ inRepo Git.Branch.writeTree
+	if oldtree /= Just newtree
+		then Just <$> do
+			cmode <- annexCommitMode <$> Annex.getGitConfig
+			let msg = "updated " ++ fromRef (branchView view madj)
+			let parent = catMaybes [oldcommit]
+			inRepo (Git.Branch.commitTree cmode [msg] parent newtree)
+		else return Nothing
+
+{- Diff between currently checked out branch and staged changes, and
+ - update metadata to reflect the changes that are being committed to the
+ - view.
+ -
+ - Adding a file to a directory adds the metadata represented by
+ - that directory to the file, and removing a file from a directory
+ - removes the metadata.
+ -
+ - Note that removes must be handled before adds. This is so
+ - that moving a file from x/foo/ to x/bar/ adds back the metadata for x.
+ -}
+withViewChanges :: (ViewedFile -> Key -> CommandStart) -> (ViewedFile -> Key -> CommandStart) -> Annex ()
+withViewChanges addmeta removemeta = do
+	(diffs, cleanup) <- inRepo $ DiffTree.diffIndex Git.Ref.headRef
+	forM_ diffs handleremovals
+	forM_ diffs handleadds
+	void $ liftIO cleanup
+  where
+	handleremovals item
+		| DiffTree.srcsha item `notElem` nullShas =
+			handlechange item removemeta
+				=<< catKey (DiffTree.srcsha item)
+		| otherwise = noop
+	handleadds item
+		| DiffTree.dstsha item `notElem` nullShas = 
+			handlechange item addmeta
+				=<< catKey (DiffTree.dstsha item)
+		| otherwise = noop
+	handlechange item a = maybe noop
+		(void . commandAction . a (fromRawFilePath $ getTopFilePath $ DiffTree.file item))
+
+{- Runs an action using the view index file.
+ - Note that the file does not necessarily exist, or can contain
+ - info staged for an old view. -}
+withViewIndex :: Annex a -> Annex a
+withViewIndex = withIndexFile ViewIndexFile . const
+
+withNewViewIndex :: Annex a -> Annex a
+withNewViewIndex a = do
+	liftIO . removeWhenExistsWith R.removeLink =<< fromRepo gitAnnexViewIndex
+	withViewIndex a
+
+{- Generates a branch for a view, using the view index file
+ - to make a commit to the view branch. The view branch is not
+ - checked out, but entering it will display the view. -}
+genViewBranch :: View -> Maybe Adjustment -> Annex Git.Branch
+genViewBranch view madj = withViewIndex $ do
+	let branch = branchView view madj
+	cmode <- annexCommitMode <$> Annex.getGitConfig
+	void $ inRepo $ Git.Branch.commit cmode True (fromRef branch) branch []
+	return branch
+
+withCurrentView :: (View -> Maybe Adjustment -> Annex a) -> Annex a
+withCurrentView a = maybe (giveup "Not in a view.") (uncurry a) =<< currentView
diff --git a/Annex/View/ViewedFile.hs b/Annex/View/ViewedFile.hs
new file mode 100644
index 0000000000..84dcbc897a
--- /dev/null
+++ b/Annex/View/ViewedFile.hs
@@ -0,0 +1,112 @@
+{- filenames (not paths) used in views
+ -
+ - Copyright 2014-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Annex.View.ViewedFile (
+	ViewedFile,
+	MkViewedFile,
+	viewedFileFromReference,
+	viewedFileFromReference',
+	viewedFileReuse,
+	dirFromViewedFile,
+	prop_viewedFile_roundtrips,
+) where
+
+import Annex.Common
+import Utility.QuickCheck
+import Backend.Utilities (maxExtensions)
+
+import qualified Data.ByteString as S
+
+type FileName = String
+type ViewedFile = FileName
+
+type MkViewedFile = FilePath -> ViewedFile
+
+{- Converts a filepath used in a reference branch to the
+ - filename that will be used in the view.
+ -
+ - No two filepaths from the same branch should yield the same result,
+ - so all directory structure needs to be included in the output filename
+ - in some way.
+ -
+ - So, from dir/subdir/file.foo, generate file_%dir%subdir%.foo
+ -}
+viewedFileFromReference :: GitConfig -> MkViewedFile
+viewedFileFromReference g = viewedFileFromReference'
+	(annexMaxExtensionLength g)
+	(annexMaxExtensions g)
+
+viewedFileFromReference' :: Maybe Int -> Maybe Int -> MkViewedFile
+viewedFileFromReference' maxextlen maxextensions f = concat $
+	[ escape (fromRawFilePath base')
+	, if null dirs then "" else "_%" ++ intercalate "%" (map escape dirs) ++ "%"
+	, escape $ fromRawFilePath $ S.concat extensions'
+	]
+  where
+	(path, basefile) = splitFileName f
+	dirs = filter (/= ".") $ map dropTrailingPathSeparator (splitPath path)
+	(base, extensions) = case maxextlen of
+		Nothing -> splitShortExtensions (toRawFilePath basefile')
+		Just n -> splitShortExtensions' (n+1) (toRawFilePath basefile')
+	{- Limit number of extensions. -}
+	maxextensions' = fromMaybe maxExtensions maxextensions
+	(base', extensions')
+		| length extensions <= maxextensions' = (base, extensions)
+		| otherwise = 
+			let (es,more) = splitAt maxextensions' (reverse extensions)
+			in (base <> mconcat (reverse more), reverse es)
+	{- On Windows, if the filename looked like "dir/c:foo" then
+	 - basefile would look like it contains a drive letter, which will
+	 - not work. There cannot really be a filename like that, probably,
+	 - but it prevents the test suite failing. -}
+	(_basedrive, basefile') = splitDrive basefile
+
+	{- To avoid collisions with filenames or directories that contain
+	 - '%', and to allow the original directories to be extracted
+	 - from the ViewedFile, '%' is escaped. )
+	 -}
+	escape :: String -> String
+	escape = replace "%" (escchar:'%':[]) . replace [escchar] [escchar, escchar]
+
+escchar :: Char
+#ifndef mingw32_HOST_OS
+escchar = '\\'
+#else
+-- \ is path separator on Windows, so instead use !
+escchar = '!'
+#endif
+
+{- For use when operating already within a view, so whatever filepath
+ - is present in the work tree is already a ViewedFile. -}
+viewedFileReuse :: MkViewedFile
+viewedFileReuse = takeFileName
+
+{- Extracts from a ViewedFile the directory where the file is located on
+ - in the reference branch. -}
+dirFromViewedFile :: ViewedFile -> FilePath
+dirFromViewedFile = joinPath . drop 1 . sep [] ""
+  where
+	sep l _ [] = reverse l
+	sep l curr (c:cs)
+		| c == '%' = sep (reverse curr:l) "" cs
+		| c == escchar = case cs of
+			(c':cs') -> sep l (c':curr) cs'
+			[] -> sep l curr cs
+		| otherwise = sep l (c:curr) cs
+
+prop_viewedFile_roundtrips :: TestableFilePath -> Bool
+prop_viewedFile_roundtrips tf
+	-- Relative filenames wanted, not directories.
+	| any (isPathSeparator) (end f ++ beginning f) = True
+	| isAbsolute f || isDrive f = True
+	| otherwise = dir == dirFromViewedFile 
+		(viewedFileFromReference' Nothing Nothing f)
+  where
+	f = fromTestableFilePath tf
+	dir = joinPath $ beginning $ splitDirectories f
diff --git a/Annex/Wanted.hs b/Annex/Wanted.hs
new file mode 100644
index 0000000000..87fdbdae49
--- /dev/null
+++ b/Annex/Wanted.hs
@@ -0,0 +1,75 @@
+{- git-annex checking whether content is wanted
+ -
+ - Copyright 2012-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.Wanted where
+
+import Annex.Common
+import Logs.PreferredContent
+import Annex.UUID
+import Annex.CatFile
+import Git.FilePath
+import qualified Database.Keys
+import Types.FileMatcher
+
+import qualified Data.Set as S
+
+{- Check if a file is preferred content for the local repository. -}
+wantGet :: Bool -> Maybe Key -> AssociatedFile -> Annex Bool
+wantGet d key file = isPreferredContent Nothing S.empty key file d
+
+{- Check if a file is preferred content for a repository. -}
+wantGetBy :: Bool -> Maybe Key -> AssociatedFile -> UUID -> Annex Bool
+wantGetBy d key file to = isPreferredContent (Just to) S.empty key file d
+
+{- Check if a file is not preferred or required content, and can be
+ - dropped. When a UUID is provided, checks for that repository.
+ -
+ - The AssociatedFile is the one that the user requested to drop.
+ - There may be other files that use the same key, and preferred content
+ - may match some of those and not others. If any are preferred content,
+ - that will prevent dropping. When the other associated files are known,
+ - they can be provided, otherwise this looks them up.
+ -}
+wantDrop :: Bool -> Maybe UUID -> Maybe Key -> AssociatedFile -> (Maybe [AssociatedFile]) -> Annex Bool
+wantDrop d from key file others =
+	isNothing <$> checkDrop isPreferredContent d from key file others
+
+{- Generalization of wantDrop that can also be used with isRequiredContent.
+ -
+ - When the content should not be dropped, returns Just the file that
+ - the checker matches.
+ -}
+checkDrop :: (Maybe UUID -> AssumeNotPresent -> Maybe Key -> AssociatedFile -> Bool -> Annex Bool) -> Bool -> Maybe UUID -> Maybe Key -> AssociatedFile -> (Maybe [AssociatedFile]) -> Annex (Maybe AssociatedFile)
+checkDrop checker d from key file others = do
+	u <- maybe getUUID (pure . id) from
+	let s = S.singleton u
+	let checker' f = checker (Just u) s key f d
+	ifM (checker' file)
+		( return (Just file)
+		, do
+			others' <- case others of
+				Just afs -> pure (filter (/= file) afs)
+				Nothing -> case key of
+					Just k ->
+						mapM (\f -> AssociatedFile . Just <$> fromRepo (fromTopFilePath f))
+							=<< Database.Keys.getAssociatedFiles k
+					Nothing -> pure []
+			l <- filterM checker' others'
+			if null l
+				then return Nothing
+				else checkassociated l
+		)
+  where
+	-- Some associated files that are in the keys database may no
+	-- longer correspond to files in the repository, and should
+	-- not prevent dropping.
+	checkassociated [] = return Nothing
+	checkassociated (af@(AssociatedFile (Just f)):fs) =
+		catKeyFile f >>= \case
+			Just k | Just k == key -> return (Just af)
+			_ -> checkassociated fs
+	checkassociated (AssociatedFile Nothing:fs) = checkassociated fs
diff --git a/Annex/WorkTree.hs b/Annex/WorkTree.hs
new file mode 100644
index 0000000000..41abc2471e
--- /dev/null
+++ b/Annex/WorkTree.hs
@@ -0,0 +1,60 @@
+{- git-annex worktree files
+ -
+ - Copyright 2013-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.WorkTree where
+
+import Annex.Common
+import Annex.Link
+import Annex.CatFile
+import Annex.CurrentBranch
+import qualified Database.Keys
+
+{- Looks up the key corresponding to an annexed file in the work tree,
+ - by examining what the symlink points to.
+ -
+ - An unlocked file will not have a link on disk, so fall back to
+ - looking for a pointer to a key in git.
+ -
+ - When in an adjusted branch that may have hidden the file, looks for a
+ - pointer to a key in the original branch.
+ -}
+lookupKey :: RawFilePath -> Annex (Maybe Key)
+lookupKey = lookupKey' catkeyfile
+  where
+	catkeyfile file =
+		ifM (liftIO $ doesFileExist $ fromRawFilePath file)
+			( catKeyFile file
+			, catKeyFileHidden file =<< getCurrentBranch
+			)
+
+{- Like lookupKey, but only looks at files staged in git, not at unstaged
+ - changes in the work tree. This means it's slower, but it also has
+ - consistently the same behavior for locked files as for unlocked files.
+ -}
+lookupKeyStaged :: RawFilePath -> Annex (Maybe Key)
+lookupKeyStaged file = catKeyFile file >>= \case
+	Just k -> return (Just k)
+	Nothing -> catKeyFileHidden file =<< getCurrentBranch
+
+{- Like lookupKey, but does not find keys for hidden files. -}
+lookupKeyNotHidden :: RawFilePath -> Annex (Maybe Key)
+lookupKeyNotHidden = lookupKey' catkeyfile
+  where
+	catkeyfile file =
+		ifM (liftIO $ doesFileExist $ fromRawFilePath file)
+			( catKeyFile file
+			, return Nothing
+			)
+
+lookupKey' :: (RawFilePath -> Annex (Maybe Key)) -> RawFilePath -> Annex (Maybe Key)
+lookupKey' catkeyfile file = isAnnexLink file >>= \case
+	Just key -> return (Just key)
+	Nothing -> catkeyfile file
+
+{- Find all annexed files and update the keys database for them. -}
+scanAnnexedFiles :: Annex ()
+scanAnnexedFiles = Database.Keys.updateDatabase
diff --git a/Annex/WorkerPool.hs b/Annex/WorkerPool.hs
new file mode 100644
index 0000000000..9f2b7f872f
--- /dev/null
+++ b/Annex/WorkerPool.hs
@@ -0,0 +1,126 @@
+{- git-annex worker thread pool
+ -
+ - Copyright 2015-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Annex.WorkerPool where
+
+import Annex
+import Annex.Common
+import Types.WorkerPool
+
+import Control.Concurrent
+import Control.Concurrent.STM
+
+{- Runs an action and makes the current thread have the specified stage
+ - while doing so. If too many other threads are running in the specified
+ - stage, waits for one of them to become idle.
+ -
+ - Noop if the current thread already has the requested stage, or if the
+ - current thread is not in the worker pool, or if concurrency is not
+ - enabled.
+ -
+ - Also a noop if the stage is not one of the stages that the worker pool
+ - uses.
+ -}
+enteringStage :: WorkerStage -> Annex a -> Annex a
+enteringStage newstage a = Annex.getState Annex.workers >>= \case
+	Nothing -> a
+	Just tv -> do
+		mytid <- liftIO myThreadId
+		let set = changeStageTo mytid tv (const newstage)
+		let restore = maybe noop (void . changeStageTo mytid tv . const)
+		bracket set restore (const a)
+
+{- Transition the current thread to the initial stage.
+ - This is done once the thread is ready to begin work.
+ -}
+enteringInitialStage :: Annex ()
+enteringInitialStage = Annex.getState Annex.workers >>= \case
+	Nothing -> noop
+	Just tv -> do
+		mytid <- liftIO myThreadId
+		void $ changeStageTo mytid tv initialStage
+
+{- This needs to leave the WorkerPool with the same number of
+ - idle and active threads, and with the same number of threads for each
+ - WorkerStage. So, all it can do is swap the WorkerStage of our thread's
+ - ActiveWorker with an IdleWorker.
+ -
+ - Must avoid a deadlock if all worker threads end up here at the same
+ - time, or if there are no suitable IdleWorkers left. So if necessary
+ - we first replace our ActiveWorker with an IdleWorker in the pool, to allow
+ - some other thread to use it, before waiting for a suitable IdleWorker
+ - for us to use.
+ -
+ - Note that the spareVals in the WorkerPool does not get anything added to
+ - it when adding the IdleWorker, so there will for a while be more IdleWorkers
+ - in the pool than spareVals. That does not prevent other threads that call
+ - this from using them though, so it's fine.
+ -}
+changeStageTo :: ThreadId -> TMVar (WorkerPool t) -> (UsedStages -> WorkerStage) -> Annex (Maybe WorkerStage)
+changeStageTo mytid tv getnewstage = liftIO $
+	replaceidle >>= maybe
+		(return Nothing)
+		(either waitidle (return . Just))
+  where
+	replaceidle = atomically $ do
+		pool <- takeTMVar tv
+		let newstage = getnewstage (usedStages pool)
+		let notchanging = do
+			putTMVar tv pool
+			return Nothing
+		if memberStage newstage (usedStages pool)
+			then case removeThreadIdWorkerPool mytid pool of
+				Just ((myaid, oldstage), pool')
+					| oldstage /= newstage -> case getIdleWorkerSlot newstage pool' of
+						Nothing -> do
+							putTMVar tv $
+								addWorkerPool (IdleWorker oldstage) pool'
+							return $ Just $ Left (myaid, newstage, oldstage)
+						Just pool'' -> do
+							-- optimisation
+							putTMVar tv $
+								addWorkerPool (IdleWorker oldstage) $
+									addWorkerPool (ActiveWorker myaid newstage) pool''
+							return $ Just $ Right oldstage
+					| otherwise -> notchanging
+				_ -> notchanging
+			else notchanging
+	
+	waitidle (myaid, newstage, oldstage) = atomically $ do
+		pool <- waitIdleWorkerSlot newstage =<< takeTMVar tv
+		putTMVar tv $ addWorkerPool (ActiveWorker myaid newstage) pool
+		return (Just oldstage)
+
+-- | Waits until there's an idle StartStage worker in the worker pool,
+-- removes it from the pool, and returns its state.
+--
+-- If the worker pool is not already allocated, returns Nothing.
+waitStartWorkerSlot :: TMVar (WorkerPool t) -> STM (Maybe (t, WorkerStage))
+waitStartWorkerSlot tv = do
+	pool <- takeTMVar tv
+	v <- go pool
+	return $ Just (v, StartStage)
+  where
+	go pool = case spareVals pool of
+		[] -> retry
+		(v:vs) -> do
+			let pool' = pool { spareVals = vs }
+			putTMVar tv =<< waitIdleWorkerSlot StartStage pool'
+			return v
+
+waitIdleWorkerSlot :: WorkerStage -> WorkerPool t -> STM (WorkerPool t)
+waitIdleWorkerSlot wantstage = maybe retry return . getIdleWorkerSlot wantstage
+
+getIdleWorkerSlot :: WorkerStage -> WorkerPool t -> Maybe (WorkerPool t)
+getIdleWorkerSlot wantstage pool = do
+	l <- findidle [] (workerList pool)
+	return $ pool { workerList = l }
+  where
+	findidle _ [] = Nothing
+	findidle c ((IdleWorker stage):rest)
+		| stage == wantstage = Just (c ++ rest)
+	findidle c (w:rest) = findidle (w:c) rest
diff --git a/Annex/YoutubeDl.hs b/Annex/YoutubeDl.hs
new file mode 100644
index 0000000000..0ed67e9aec
--- /dev/null
+++ b/Annex/YoutubeDl.hs
@@ -0,0 +1,410 @@
+{- yt-dlp (and deprecated youtube-dl) integration for git-annex
+ -
+ - Copyright 2017-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE DeriveGeneric #-}
+
+module Annex.YoutubeDl (
+	youtubeDl,
+	youtubeDlTo,
+	youtubeDlSupported,
+	youtubeDlCheck,
+	youtubeDlFileName,
+	youtubeDlFileNameHtmlOnly,
+	youtubeDlCommand,
+	youtubePlaylist,
+	YoutubePlaylistItem(..),
+) where
+
+import Annex.Common
+import qualified Annex
+import Annex.Content
+import Annex.Url
+import Utility.DiskFree
+import Utility.HtmlDetect
+import Utility.Process.Transcript
+import Utility.Metered
+import Utility.Tmp
+import Messages.Progress
+import Logs.Transfer
+
+import Network.URI
+import Control.Concurrent.Async
+import Text.Read
+import Data.Either
+import qualified Data.Aeson as Aeson
+import GHC.Generics
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Char8 as B8
+
+-- youtube-dl can follow redirects to anywhere, including potentially
+-- localhost or a private address. So, it's only allowed to download
+-- content if the user has allowed access to all addresses.
+youtubeDlAllowed :: Annex Bool
+youtubeDlAllowed = ipAddressesUnlimited
+
+youtubeDlNotAllowedMessage :: String
+youtubeDlNotAllowedMessage = unwords
+	[ "This url is supported by yt-dlp, but"
+	, "yt-dlp could potentially access any address, and the"
+	, "configuration of annex.security.allowed-ip-addresses"
+	, "does not allow that. Not using yt-dlp (or youtube-dl)."
+	]
+
+-- Runs youtube-dl in a work directory, to download a single media file
+-- from the url. Returns the path to the media file in the work directory.
+--
+-- Displays a progress meter as youtube-dl downloads.
+--
+-- If no file is downloaded, or the program is not installed,
+-- returns Right Nothing.
+--
+-- youtube-dl can write to multiple files, either temporary files, or
+-- multiple videos found at the url, and git-annex needs only one file.
+-- So we need to find the destination file, and make sure there is not
+-- more than one. With yt-dlp use --print-to-file to make it record the 
+-- file(s) it downloads. With youtube-dl, the best that can be done is
+-- to require that the work directory end up with only 1 file in it.
+-- (This can fail, but youtube-dl is deprecated, and they closed my
+-- issue requesting something like --print-to-file; 
+-- <https://github.com/rg3/youtube-dl/issues/14864>)
+youtubeDl :: URLString -> FilePath -> MeterUpdate -> Annex (Either String (Maybe FilePath))
+youtubeDl url workdir p = ifM ipAddressesUnlimited
+	( withUrlOptions $ youtubeDl' url workdir p
+	, return $ Left youtubeDlNotAllowedMessage
+	)
+
+youtubeDl' :: URLString -> FilePath -> MeterUpdate -> UrlOptions -> Annex (Either String (Maybe FilePath))
+youtubeDl' url workdir p uo
+	| supportedScheme uo url = do
+		cmd <- youtubeDlCommand
+		ifM (liftIO $ inSearchPath cmd)
+			( runcmd cmd >>= \case
+				Right True -> downloadedfiles cmd >>= \case
+					(f:[]) -> return (Right (Just f))
+					[] -> return (nofiles cmd)
+					fs -> return (toomanyfiles cmd fs)
+				Right False -> workdirfiles >>= \case
+					[] -> return (Right Nothing)
+					_ -> return (Left $ cmd ++ " download is incomplete. Run the command again to resume.")
+				Left msg -> return (Left msg)
+			, return (Right Nothing)
+			)
+	| otherwise = return (Right Nothing)
+  where
+	nofiles cmd = Left $ cmd ++ " did not put any media in its work directory, perhaps it's been configured to store files somewhere else?"
+	toomanyfiles cmd fs = Left $ cmd ++ " downloaded multiple media files; git-annex is only able to deal with one per url: " ++ show fs
+	downloadedfiles cmd
+		| isytdlp cmd = liftIO $ 
+			(nub . lines <$> readFile filelistfile)
+				`catchIO` (pure . const [])
+		| otherwise = workdirfiles
+	workdirfiles = liftIO $ filter (/= filelistfile) 
+		<$> (filterM (doesFileExist) =<< dirContents workdir)
+	filelistfile = workdir </> filelistfilebase
+	filelistfilebase = "git-annex-file-list-file"
+	isytdlp cmd = cmd == "yt-dlp"
+	runcmd cmd = youtubeDlMaxSize workdir >>= \case
+		Left msg -> return (Left msg)
+		Right maxsize -> do
+			opts <- youtubeDlOpts (dlopts cmd ++ maxsize)
+			oh <- mkOutputHandlerQuiet
+			-- The size is unknown to start. Once youtube-dl
+			-- outputs some progress, the meter will be updated
+			-- with the size, which is why it's important the
+			-- meter is passed into commandMeter'
+			let unknownsize = Nothing :: Maybe FileSize
+			ok <- metered (Just p) unknownsize Nothing $ \meter meterupdate ->
+				liftIO $ commandMeter'
+					(if isytdlp cmd then parseYtdlpProgress else parseYoutubeDlProgress)
+					oh (Just meter) meterupdate cmd opts
+					(\pr -> pr { cwd = Just workdir })
+			return (Right ok)
+	dlopts cmd = 
+		[ Param url
+		-- To make it only download one file when given a
+		-- page with a video and a playlist, download only the video.
+		, Param "--no-playlist"
+		-- And when given a page with only a playlist, download only
+		-- the first video on the playlist. (Assumes the video is
+		-- somewhat stable, but this is the only way to prevent
+		-- it from downloading the whole playlist.)
+		, Param "--playlist-items", Param "0"
+		] ++
+			if isytdlp cmd
+				then
+					-- Avoid warnings, which go to
+					-- stderr and may mess up
+					-- git-annex's display.
+					[ Param "--no-warnings"
+					, Param "--progress-template"
+					, Param progressTemplate
+					, Param "--print-to-file"
+					, Param "after_move:filepath"
+					, Param filelistfilebase
+					]
+				else []
+
+-- To honor annex.diskreserve, ask youtube-dl to not download too
+-- large a media file. Factors in other downloads that are in progress,
+-- and any files in the workdir that it may have partially downloaded
+-- before.
+youtubeDlMaxSize :: FilePath -> Annex (Either String [CommandParam])
+youtubeDlMaxSize workdir = ifM (Annex.getRead Annex.force)
+	( return $ Right []
+	, liftIO (getDiskFree workdir) >>= \case
+		Just have -> do
+			inprogress <- sizeOfDownloadsInProgress (const True)
+			partial <- liftIO $ sum 
+				<$> (mapM (getFileSize . toRawFilePath) =<< dirContents workdir)
+			reserve <- annexDiskReserve <$> Annex.getGitConfig
+			let maxsize = have - reserve - inprogress + partial
+			if maxsize > 0
+				then return $ Right
+					[ Param "--max-filesize"
+					, Param (show maxsize)
+					]
+				else return $ Left $
+					needMoreDiskSpace $
+						negate maxsize + 1024
+		Nothing -> return $ Right []
+	)
+
+-- Download a media file to a destination, 
+youtubeDlTo :: Key -> URLString -> FilePath -> MeterUpdate -> Annex Bool
+youtubeDlTo key url dest p = do
+	res <- withTmpWorkDir key $ \workdir ->
+		youtubeDl url (fromRawFilePath workdir) p >>= \case
+			Right (Just mediafile) -> do
+				liftIO $ moveFile (toRawFilePath mediafile) (toRawFilePath dest)
+				return (Just True)
+			Right Nothing -> return (Just False)
+			Left msg -> do
+				warning (UnquotedString msg)
+				return Nothing
+	return (fromMaybe False res)
+
+-- youtube-dl supports downloading urls that are not html pages,
+-- but we don't want to use it for such urls, since they can be downloaded
+-- without it. So, this first downloads part of the content and checks 
+-- if it's a html page; only then is youtube-dl used.
+htmlOnly :: URLString -> a -> Annex a -> Annex a
+htmlOnly url fallback a = withUrlOptions $ \uo -> 
+	liftIO (downloadPartial url uo htmlPrefixLength) >>= \case
+		Just bs | isHtmlBs bs -> a
+		_ -> return fallback
+
+-- Check if youtube-dl supports downloading content from an url.
+youtubeDlSupported :: URLString -> Annex Bool
+youtubeDlSupported url = either (const False) id
+	<$> withUrlOptions (youtubeDlCheck' url)
+
+-- Check if youtube-dl can find media in an url.
+--
+-- While this does not download anything, it checks youtubeDlAllowed
+-- for symmetry with youtubeDl; the check should not succeed if the
+-- download won't succeed.
+youtubeDlCheck :: URLString -> Annex (Either String Bool)
+youtubeDlCheck url = ifM youtubeDlAllowed
+	( withUrlOptions $ youtubeDlCheck' url
+	, return $ Left youtubeDlNotAllowedMessage
+	)
+
+youtubeDlCheck' :: URLString -> UrlOptions -> Annex (Either String Bool)
+youtubeDlCheck' url uo
+	| supportedScheme uo url = catchMsgIO $ htmlOnly url False $ do
+		opts <- youtubeDlOpts [ Param url, Param "--simulate" ]
+		cmd <- youtubeDlCommand
+		liftIO $ snd <$> processTranscript cmd (toCommand opts) Nothing
+	| otherwise = return (Right False)
+
+-- Ask youtube-dl for the filename of media in an url.
+--
+-- (This is not always identical to the filename it uses when downloading.)
+youtubeDlFileName :: URLString -> Annex (Either String FilePath)
+youtubeDlFileName url = withUrlOptions go
+  where
+	go uo
+		| supportedScheme uo url = flip catchIO (pure . Left . show) $
+			htmlOnly url nomedia (youtubeDlFileNameHtmlOnly' url uo)
+		| otherwise = return nomedia
+	nomedia = Left "no media in url"
+
+-- Does not check if the url contains htmlOnly; use when that's already
+-- been verified.
+youtubeDlFileNameHtmlOnly :: URLString -> Annex (Either String FilePath)
+youtubeDlFileNameHtmlOnly = withUrlOptions . youtubeDlFileNameHtmlOnly'
+
+youtubeDlFileNameHtmlOnly' :: URLString -> UrlOptions -> Annex (Either String FilePath)
+youtubeDlFileNameHtmlOnly' url uo
+	| supportedScheme uo url = flip catchIO (pure . Left . show) go
+	| otherwise = return nomedia
+  where
+	go = do
+		-- Sometimes youtube-dl will fail with an ugly backtrace
+		-- (eg, http://bugs.debian.org/874321)
+		-- so catch stderr as well as stdout to avoid the user
+		-- seeing it. --no-warnings avoids warning messages that
+		-- are output to stdout.
+		opts <- youtubeDlOpts
+			[ Param url
+			, Param "--get-filename"
+			, Param "--no-warnings"
+			, Param "--no-playlist"
+			]
+		cmd <- youtubeDlCommand
+		let p = (proc cmd (toCommand opts))
+			{ std_out = CreatePipe
+			, std_err = CreatePipe
+			}
+		liftIO $ withCreateProcess p waitproc
+	
+	waitproc Nothing (Just o) (Just e) pid = do
+		errt <- async $ discardstderr pid e
+		output <- hGetContentsStrict o
+		ok <- liftIO $ checkSuccessProcess pid
+		wait errt
+		return $ case (ok, lines output) of
+			(True, (f:_)) | not (null f) -> Right f
+			_ -> nomedia
+	waitproc _ _ _ _ = error "internal"
+
+	discardstderr pid e = hGetLineUntilExitOrEOF pid e >>= \case
+		Nothing -> return ()
+		Just _ -> discardstderr pid e
+
+	nomedia = Left "no media in url"
+
+youtubeDlOpts :: [CommandParam] -> Annex [CommandParam]
+youtubeDlOpts addopts = do
+	opts <- map Param . annexYoutubeDlOptions <$> Annex.getGitConfig
+	return (opts ++ addopts)
+
+youtubeDlCommand :: Annex String
+youtubeDlCommand = annexYoutubeDlCommand <$> Annex.getGitConfig >>= \case
+	Just c -> pure c
+	Nothing -> ifM (liftIO $ inSearchPath "yt-dlp")
+		( return "yt-dlp"
+		, return "youtube-dl"
+		)
+
+supportedScheme :: UrlOptions -> URLString -> Bool
+supportedScheme uo url = case parseURIRelaxed url of
+	Nothing -> False
+	Just u -> case uriScheme u of
+		-- avoid ugly message from youtube-dl about not supporting file:
+		"file:" -> False
+		-- ftp indexes may look like html pages, and there's no point
+		-- involving youtube-dl in a ftp download
+		"ftp:" -> False
+		_ -> allowedScheme uo u
+
+progressTemplate :: String
+progressTemplate = "ANNEX %(progress.downloaded_bytes)i %(progress.total_bytes_estimate)i %(progress.total_bytes)i ANNEX"
+
+{- The progressTemplate makes output look like "ANNEX 10 100 NA ANNEX" or
+ - "ANNEX 10 NA 100 ANNEX" depending on whether the total bytes are estimated
+ - or known. That makes parsing much easier (and less fragile) than parsing
+ - the usual progress output.
+ -}
+parseYtdlpProgress :: ProgressParser
+parseYtdlpProgress = go [] . reverse . progresschunks
+  where
+	delim = '\r'
+
+	progresschunks = splitc delim
+
+	go remainder [] = (Nothing, Nothing, remainder)
+	go remainder (x:xs) = case splitc ' ' x of
+			("ANNEX":downloaded_bytes_s:total_bytes_estimate_s:total_bytes_s:"ANNEX":[]) ->
+				case (readMaybe downloaded_bytes_s, readMaybe total_bytes_estimate_s, readMaybe total_bytes_s) of
+					(Just downloaded_bytes, Nothing, Just total_bytes) ->
+						( Just (BytesProcessed downloaded_bytes)
+						, Just (TotalSize total_bytes)
+						, remainder
+						)
+					(Just downloaded_bytes, Just total_bytes_estimate, _) ->
+						( Just (BytesProcessed downloaded_bytes)
+						, Just (TotalSize total_bytes_estimate)
+						, remainder
+						)
+					_ -> go (remainder++x) xs
+			_ -> go (remainder++x) xs
+
+{- youtube-dl is deprecated, parsing its progress was attempted before but
+ - was buggy and is no longer done. -}
+parseYoutubeDlProgress :: ProgressParser
+parseYoutubeDlProgress _ = (Nothing, Nothing, "")
+
+{- List the items that yt-dlp can download from an url.
+ - 
+ - Note that this does not check youtubeDlAllowed because it does not
+ - download content.
+ -}
+youtubePlaylist :: URLString -> Annex (Either String [YoutubePlaylistItem])
+youtubePlaylist url = do
+	cmd <- youtubeDlCommand
+	if cmd == "yt-dlp"
+		then liftIO $ youtubePlaylist' url cmd
+		else return $ Left $ "Scraping needs yt-dlp, but git-annex has been configured to use " ++ cmd
+
+youtubePlaylist' :: URLString -> String -> IO (Either String [YoutubePlaylistItem])
+youtubePlaylist' url cmd = withTmpFile "yt-dlp" $ \tmpfile h -> do
+	hClose h
+	(outerr, ok) <- processTranscript cmd
+		[ "--simulate"
+		, "--flat-playlist"
+		-- Skip live videos in progress
+		, "--match-filter", "!is_live"
+		, "--print-to-file"
+		-- Write json with selected fields.
+		, "%(.{" ++ intercalate "," youtubePlaylistItemFields ++ "})j"
+		, tmpfile
+		, url
+		]
+		Nothing
+	if ok
+		then flip catchIO (pure . Left . show) $ do
+			v <- map Aeson.eitherDecodeStrict . B8.lines
+				<$> B.readFile tmpfile
+			return $ case partitionEithers v of
+				((parserr:_), _) -> 
+					Left $ "yt-dlp json parse errror: " ++ parserr
+				([], r) -> Right r
+		else return $ Left $ if null outerr
+			then "yt-dlp failed"
+			else "yt-dlp failed: " ++ outerr
+
+-- There are other fields that yt-dlp can extract, but these are similar to
+-- the information from an RSS feed.
+youtubePlaylistItemFields :: [String]
+youtubePlaylistItemFields =
+	[ "playlist_title"
+	, "playlist_uploader"
+	, "title"
+	, "description"
+	, "license"
+	, "url"
+	, "timestamp"
+	]
+
+-- Parse JSON generated by yt-dlp for playlist. Note that any field
+-- may be omitted when that information is not supported for a given website.
+data YoutubePlaylistItem = YoutubePlaylistItem
+	{ youtube_playlist_title :: Maybe String
+	, youtube_playlist_uploader :: Maybe String
+	, youtube_title :: Maybe String
+	, youtube_description :: Maybe String
+	, youtube_license :: Maybe String
+	, youtube_url :: Maybe String
+	, youtube_timestamp :: Maybe Integer -- ^ unix timestamp
+	} deriving (Generic, Show)
+
+instance Aeson.FromJSON YoutubePlaylistItem
+  where
+	parseJSON = Aeson.genericParseJSON Aeson.defaultOptions
+		{ Aeson.fieldLabelModifier = drop (length "youtube_") }
+
diff --git a/Assistant.hs b/Assistant.hs
new file mode 100644
index 0000000000..2e50a79ff1
--- /dev/null
+++ b/Assistant.hs
@@ -0,0 +1,194 @@
+{- git-annex assistant daemon
+ -
+ - Copyright 2012-2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Assistant where
+
+import qualified Annex
+import Assistant.Common
+import Assistant.DaemonStatus
+import Assistant.NamedThread
+import Assistant.Types.ThreadedMonad
+import Assistant.Threads.DaemonStatus
+import Assistant.Threads.Watcher
+import Assistant.Threads.Committer
+import Assistant.Threads.Pusher
+import Assistant.Threads.Exporter
+import Assistant.Threads.Merger
+import Assistant.Threads.TransferWatcher
+import Assistant.Threads.Transferrer
+import Assistant.Threads.RemoteControl
+import Assistant.Threads.SanityChecker
+import Assistant.Threads.Cronner
+import Assistant.Threads.ProblemFixer
+#ifndef mingw32_HOST_OS
+import Assistant.Threads.MountWatcher
+#endif
+import Assistant.Threads.NetWatcher
+import Assistant.Threads.Upgrader
+import Assistant.Threads.UpgradeWatcher
+import Assistant.Threads.TransferScanner
+import Assistant.Threads.TransferPoller
+import Assistant.Threads.ConfigMonitor
+import Assistant.Threads.Glacier
+#ifdef WITH_WEBAPP
+import Assistant.WebApp
+import Assistant.Threads.WebApp
+#ifdef WITH_PAIRING
+import Assistant.Threads.PairListener
+#endif
+#else
+import Assistant.Types.UrlRenderer
+#endif
+import qualified Utility.Daemon
+import Utility.ThreadScheduler
+import Utility.HumanTime
+import Annex.Perms
+import Annex.BranchState
+import Utility.LogFile
+import Annex.Path
+#ifdef mingw32_HOST_OS
+import Utility.Env
+import System.Environment (getArgs)
+#endif
+import qualified Utility.Debug as Debug
+
+import Network.Socket (HostName, PortNumber)
+
+stopDaemon :: Annex ()
+stopDaemon = liftIO . Utility.Daemon.stopDaemon . fromRawFilePath
+	=<< fromRepo gitAnnexPidFile
+
+{- Starts the daemon. If the daemon is run in the foreground, once it's
+ - running, can start the browser.
+ -
+ - startbrowser is passed the url and html shim file, as well as the original
+ - stdout and stderr descriptors. -}
+startDaemon :: Bool -> Bool -> Maybe Duration -> Maybe String -> Maybe HostName -> Maybe PortNumber ->  Maybe (Maybe Handle -> Maybe Handle -> String -> FilePath -> IO ()) -> Annex ()
+startDaemon assistant foreground startdelay cannotrun listenhost listenport startbrowser = do
+	Annex.changeState $ \s -> s { Annex.daemon = True }
+	enableInteractiveBranchAccess
+	pidfile <- fromRepo gitAnnexPidFile
+	logfile <- fromRepo gitAnnexDaemonLogFile
+	liftIO $ Debug.debug "Assistant" $ "logging to " ++ fromRawFilePath logfile
+	createAnnexDirectory (parentDir pidfile)
+#ifndef mingw32_HOST_OS
+	createAnnexDirectory (parentDir logfile)
+	let logfd = handleToFd =<< openLog (fromRawFilePath logfile)
+	if foreground
+		then do
+			origout <- liftIO $ catchMaybeIO $ 
+				fdToHandle =<< dup stdOutput
+			origerr <- liftIO $ catchMaybeIO $ 
+				fdToHandle =<< dup stdError
+			let undaemonize = Utility.Daemon.foreground logfd (Just (fromRawFilePath pidfile))
+			start undaemonize $ 
+				case startbrowser of
+					Nothing -> Nothing
+					Just a -> Just $ a origout origerr
+		else do
+			git_annex <- liftIO programPath
+			ps <- gitAnnexDaemonizeParams
+			start (Utility.Daemon.daemonize git_annex ps logfd (Just (fromRawFilePath pidfile)) False) Nothing
+#else
+	-- Windows doesn't daemonize, but does redirect output to the
+	-- log file. The only way to do so is to restart the program.
+	when (foreground || not foreground) $ do
+		let flag = "GIT_ANNEX_OUTPUT_REDIR"
+		createAnnexDirectory (parentDir logfile)
+		ifM (liftIO $ isNothing <$> getEnv flag)
+			( liftIO $ withNullHandle $ \nullh -> do
+				loghandle <- openLog (fromRawFilePath logfile)
+				e <- getEnvironment
+				cmd <- programPath
+				ps <- getArgs
+				let p = (proc cmd ps)
+					{ env = Just (addEntry flag "1" e)
+					, std_in = UseHandle nullh
+					, std_out = UseHandle loghandle
+					, std_err = UseHandle loghandle
+					}
+				exitcode <- withCreateProcess p $ \_ _ _ pid ->
+					waitForProcess pid
+				exitWith exitcode
+			, start (Utility.Daemon.foreground (Just (fromRawFilePath pidfile))) $
+				case startbrowser of
+					Nothing -> Nothing
+					Just a -> Just $ a Nothing Nothing
+			)
+#endif
+  where
+	start daemonize webappwaiter = withThreadState $ \st -> do
+		checkCanWatch
+		dstatus <- startDaemonStatus
+		logfile <- fromRepo gitAnnexDaemonLogFile
+		liftIO $ Debug.debug "Assistant" $ "logging to " ++ fromRawFilePath logfile
+		liftIO $ daemonize $
+			flip runAssistant (go webappwaiter) 
+				=<< newAssistantData st dstatus
+
+#ifdef WITH_WEBAPP
+	go webappwaiter = do
+		d <- getAssistant id
+#else
+	go _webappwaiter = do
+#endif
+		urlrenderer <- liftIO newUrlRenderer
+#ifdef WITH_WEBAPP
+		let webappthread = [ assist $ webAppThread d urlrenderer False cannotrun Nothing listenhost listenport webappwaiter ]
+#else
+		let webappthread = []
+#endif
+		let threads = if isJust cannotrun
+			then webappthread
+			else webappthread ++
+				[ watch commitThread
+#ifdef WITH_WEBAPP
+#ifdef WITH_PAIRING
+				, assist $ pairListenerThread urlrenderer
+#endif
+#endif
+				, assist pushThread
+				, assist pushRetryThread
+				, assist exportThread
+				, assist exportRetryThread
+				, assist mergeThread
+				, assist transferWatcherThread
+				, assist transferPollerThread
+				, assist transfererThread
+				, assist remoteControlThread
+				, assist daemonStatusThread
+				, assist $ sanityCheckerDailyThread urlrenderer
+				, assist sanityCheckerHourlyThread
+				, assist $ problemFixerThread urlrenderer
+#ifndef mingw32_HOST_OS
+				, assist $ mountWatcherThread urlrenderer
+#endif
+				, assist netWatcherThread
+				, assist $ upgraderThread urlrenderer
+				, assist $ upgradeWatcherThread urlrenderer
+				, assist netWatcherFallbackThread
+				, assist $ transferScannerThread urlrenderer
+				, assist $ cronnerThread urlrenderer
+				, assist configMonitorThread
+				, assist glacierThread
+				, watch watchThread
+				-- must come last so that all threads that wait
+				-- on it have already started waiting
+				, watch $ sanityCheckerStartupThread startdelay
+				]
+	
+		mapM_ (startthread urlrenderer) threads
+		liftIO waitForTermination
+
+	watch a = (True, a)
+	assist a = (False, a)
+	startthread urlrenderer (watcher, t)
+		| watcher || assistant = startNamedThread urlrenderer t
+		| otherwise = noop
diff --git a/Assistant/Alert.hs b/Assistant/Alert.hs
new file mode 100644
index 0000000000..ead791dcc9
--- /dev/null
+++ b/Assistant/Alert.hs
@@ -0,0 +1,460 @@
+{- git-annex assistant alerts
+ -
+ - Copyright 2012-2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, CPP, BangPatterns #-}
+
+module Assistant.Alert where
+
+import Annex.Common
+import Assistant.Types.Alert
+import Assistant.Alert.Utility
+import qualified Remote
+import Utility.Tense
+import Types.Transfer
+import Types.Distribution
+import Git.Types (RemoteName)
+
+import Data.String
+import qualified Data.Text as T
+import qualified Control.Exception as E
+
+#ifdef WITH_WEBAPP
+import Assistant.DaemonStatus
+import Assistant.WebApp.Types
+import Assistant.WebApp (renderUrl)
+#endif
+import Assistant.Monad
+import Assistant.Types.UrlRenderer
+
+{- Makes a button for an alert that opens a Route. 
+ -
+ - If autoclose is set, the button will close the alert it's
+ - attached to when clicked. -}
+#ifdef WITH_WEBAPP
+mkAlertButton :: Bool -> T.Text -> UrlRenderer -> Route WebApp -> Assistant AlertButton
+mkAlertButton autoclose label urlrenderer route = do
+	close <- asIO1 removeAlert
+	url <- liftIO $ renderUrl urlrenderer route []
+	return $ AlertButton
+		{ buttonLabel = label
+		, buttonUrl = url
+		, buttonAction = if autoclose then Just close else Nothing
+		, buttonPrimary = True
+		}
+#endif
+
+renderData :: Alert -> TenseText
+renderData = tenseWords . alertData
+
+baseActivityAlert :: Alert
+baseActivityAlert = Alert
+	{ alertClass = Activity
+	, alertHeader = Nothing
+	, alertMessageRender = renderData
+	, alertData = []
+	, alertCounter = 0
+	, alertBlockDisplay = False
+	, alertClosable = False
+	, alertPriority = Medium
+	, alertIcon = Just ActivityIcon
+	, alertCombiner = Nothing
+	, alertName = Nothing
+	, alertButtons = []
+	}
+
+warningAlert :: String -> String -> Alert
+warningAlert name msg = Alert
+	{ alertClass = Warning
+	, alertHeader = Just $ tenseWords ["warning"]
+	, alertMessageRender = renderData
+	, alertData = [UnTensed $ T.pack msg]
+	, alertCounter = 0
+	, alertBlockDisplay = True
+	, alertClosable = True
+	, alertPriority = High
+	, alertIcon = Just ErrorIcon
+	, alertCombiner = Just $ dataCombiner $ \_old new -> new
+	, alertName = Just $ WarningAlert name
+	, alertButtons = []
+	}
+
+errorAlert :: String -> [AlertButton] -> Alert
+errorAlert msg buttons = Alert
+	{ alertClass = Error
+	, alertHeader = Nothing
+	, alertMessageRender = renderData
+	, alertData = [UnTensed $ T.pack msg]
+	, alertCounter = 0
+	, alertBlockDisplay = True
+	, alertClosable = True
+	, alertPriority = Pinned
+	, alertIcon = Just ErrorIcon
+	, alertCombiner = Nothing
+	, alertName = Nothing
+	, alertButtons = buttons
+	}
+
+activityAlert :: Maybe TenseText -> [TenseChunk] -> Alert
+activityAlert header dat = baseActivityAlert
+	{ alertHeader = header
+	, alertData = dat
+	}
+
+startupScanAlert :: Alert
+startupScanAlert = activityAlert Nothing
+	[Tensed "Performing" "Performed", "startup scan"]
+
+{- Displayed when a shutdown is occurring, so will be seen after shutdown
+ - has happened. -}
+shutdownAlert :: Alert
+shutdownAlert = warningAlert "shutdown" "git-annex has been shut down"
+
+commitAlert :: Alert
+commitAlert = activityAlert Nothing
+	[Tensed "Committing" "Committed", "changes to git"]
+
+showRemotes :: [RemoteName] -> TenseChunk
+showRemotes = UnTensed . T.intercalate ", " . map T.pack
+
+syncAlert :: [Remote] -> Alert
+syncAlert = syncAlert' . map Remote.name
+
+syncAlert' :: [RemoteName] -> Alert
+syncAlert' rs = baseActivityAlert
+	{ alertName = Just SyncAlert
+	, alertHeader = Just $ tenseWords
+		[Tensed "Syncing" "Synced", "with", showRemotes rs]
+	, alertPriority = Low
+	, alertIcon = Just SyncIcon
+	}
+
+syncResultAlert :: [Remote] -> [Remote] -> Alert
+syncResultAlert succeeded failed = syncResultAlert'
+	(map Remote.name succeeded)
+	(map Remote.name failed)
+
+syncResultAlert' :: [RemoteName] -> [RemoteName] -> Alert
+syncResultAlert' succeeded failed = makeAlertFiller (not $ null succeeded) $
+	baseActivityAlert
+		{ alertName = Just SyncAlert
+		, alertHeader = Just $ tenseWords msg
+		}
+  where
+	msg
+		| null succeeded = ["Failed to sync with", showRemotes failed]
+		| null failed = ["Synced with", showRemotes succeeded]
+		| otherwise =
+			[ "Synced with", showRemotes succeeded
+			, "but not with", showRemotes failed
+			]
+
+sanityCheckAlert :: Alert
+sanityCheckAlert = activityAlert
+	(Just $ tenseWords [Tensed "Running" "Ran", "daily sanity check"])
+	["to make sure everything is ok."]
+
+sanityCheckFixAlert :: String -> Alert
+sanityCheckFixAlert msg = Alert
+	{ alertClass = Warning
+	, alertHeader = Just $ tenseWords ["Fixed a problem"]
+	, alertMessageRender = render
+	, alertData = [UnTensed $ T.pack msg]
+	, alertCounter = 0
+	, alertBlockDisplay = True
+	, alertPriority = High
+	, alertClosable = True
+	, alertIcon = Just ErrorIcon
+	, alertName = Just SanityCheckFixAlert
+	, alertCombiner = Just $ dataCombiner (++)
+	, alertButtons = []
+	}
+  where
+	render alert = tenseWords $ alerthead : alertData alert ++ [alertfoot]
+	alerthead = "The daily sanity check found and fixed a problem:"
+	alertfoot = "If these problems persist, consider filing a bug report."
+
+fsckingAlert :: AlertButton -> Maybe Remote -> Alert
+fsckingAlert button mr = baseActivityAlert
+	{ alertData = case mr of
+		Nothing -> [ UnTensed $ T.pack $ "Consistency check in progress" ]
+		Just r -> [ UnTensed $ T.pack $ "Consistency check of " ++ Remote.name r ++ " in progress"]
+	, alertButtons = [button]
+	}
+
+showFscking :: UrlRenderer -> Maybe Remote -> IO (Either E.SomeException a) -> Assistant a
+showFscking urlrenderer mr a = do
+#ifdef WITH_WEBAPP
+	button <- mkAlertButton False (T.pack "Configure") urlrenderer ConfigFsckR
+	r <- alertDuring (fsckingAlert button mr) $
+		liftIO a
+#else
+	r <- liftIO a
+#endif
+	either (liftIO . E.throwIO) return r
+
+notFsckedNudge :: UrlRenderer -> Maybe Remote -> Assistant ()
+#ifdef WITH_WEBAPP
+notFsckedNudge urlrenderer mr = do
+	button <- mkAlertButton True (T.pack "Configure") urlrenderer ConfigFsckR
+	void $ addAlert (notFsckedAlert mr button)
+#else
+notFsckedNudge _ _ = noop
+#endif
+
+notFsckedAlert :: Maybe Remote -> AlertButton -> Alert
+notFsckedAlert mr button = Alert
+	{ alertHeader = Just $ fromString $ concat
+		[ "You should enable consistency checking to protect your data"
+		, maybe "" (\r -> " in " ++ Remote.name r) mr
+		, "."
+		]
+	, alertIcon = Just InfoIcon
+	, alertPriority = High
+	, alertButtons = [button]
+	, alertClosable = True
+	, alertClass = Message
+	, alertMessageRender = renderData
+	, alertCounter = 0
+	, alertBlockDisplay = True
+	, alertName = Just NotFsckedAlert
+	, alertCombiner = Just $ dataCombiner $ \_old new -> new
+	, alertData = []
+	}
+
+baseUpgradeAlert :: [AlertButton] -> TenseText -> Alert
+baseUpgradeAlert buttons message = Alert
+	{ alertHeader = Just message
+	, alertIcon = Just UpgradeIcon
+	, alertPriority = High
+	, alertButtons = buttons
+	, alertClosable = True
+	, alertClass = Message
+	, alertMessageRender = renderData
+	, alertCounter = 0
+	, alertBlockDisplay = True
+	, alertName = Just UpgradeAlert
+	, alertCombiner = Just $ fullCombiner $ \new _old -> new
+	, alertData = []
+	}
+
+canUpgradeAlert :: AlertPriority -> GitAnnexVersion -> AlertButton -> Alert
+canUpgradeAlert priority version button = 
+	(baseUpgradeAlert [button] $ fromString msg)
+		{ alertPriority = priority
+		, alertData = [fromString $ " (version " ++ version ++ ")"]
+		}
+  where
+	msg = if priority >= High
+		then "An important upgrade of git-annex is available!"
+		else "An upgrade of git-annex is available."
+
+upgradeReadyAlert :: AlertButton -> Alert
+upgradeReadyAlert button = baseUpgradeAlert [button] $
+	fromString "A new version of git-annex has been installed."
+
+upgradingAlert :: Alert
+upgradingAlert = activityAlert Nothing [ fromString "Upgrading git-annex" ]
+
+upgradeFinishedAlert :: Maybe AlertButton -> GitAnnexVersion -> Alert
+upgradeFinishedAlert button version =
+	baseUpgradeAlert (maybeToList button) $ fromString $ 
+		"Finished upgrading git-annex to version " ++ version
+
+upgradeFailedAlert :: String -> Alert
+upgradeFailedAlert msg = (errorAlert msg [])
+	{ alertHeader = Just $ fromString "Upgrade failed." }
+
+unusedFilesAlert :: [AlertButton] -> String -> Alert
+unusedFilesAlert buttons message = Alert
+	{ alertHeader = Just $ fromString $ unwords
+		[ "Old and deleted files are piling up --"
+		, message
+		]
+	, alertIcon = Just InfoIcon
+	, alertPriority = High
+	, alertButtons = buttons
+	, alertClosable = True
+	, alertClass = Message
+	, alertMessageRender = renderData
+	, alertCounter = 0
+	, alertBlockDisplay = True
+	, alertName = Just UnusedFilesAlert
+	, alertCombiner = Just $ fullCombiner $ \new _old -> new
+	, alertData = []
+	}
+
+brokenRepositoryAlert :: [AlertButton] -> Alert
+brokenRepositoryAlert = errorAlert "Serious problems have been detected with your repository. This needs your immediate attention!"
+
+repairingAlert :: String -> Alert
+repairingAlert repodesc = activityAlert Nothing
+	[ Tensed "Attempting to repair" "Repaired"
+	, UnTensed $ T.pack repodesc
+	]
+
+pairingAlert :: AlertButton -> Alert
+pairingAlert button = baseActivityAlert
+	{ alertData = [ UnTensed "Pairing in progress" ]
+	, alertPriority = High
+	, alertButtons = [button]
+	}
+
+pairRequestReceivedAlert :: String -> AlertButton -> Alert
+pairRequestReceivedAlert who button = Alert
+	{ alertClass = Message
+	, alertHeader = Nothing
+	, alertMessageRender = renderData
+	, alertData = [UnTensed $ T.pack $ who ++ " is sending a pair request."]
+	, alertCounter = 0
+	, alertBlockDisplay = False
+	, alertPriority = High
+	, alertClosable = True
+	, alertIcon = Just InfoIcon
+	, alertName = Just $ PairAlert who
+	, alertCombiner = Just $ dataCombiner $ \_old new -> new
+	, alertButtons = [button]
+	}
+
+pairRequestAcknowledgedAlert :: String -> Maybe AlertButton -> Alert
+pairRequestAcknowledgedAlert who button = baseActivityAlert
+	{ alertData = ["Pairing with", UnTensed (T.pack who), Tensed "in progress" "complete"]
+	, alertPriority = High
+	, alertName = Just $ PairAlert who
+	, alertCombiner = Just $ dataCombiner $ \_old new -> new
+	, alertButtons = maybeToList button
+	}
+
+connectionNeededAlert :: AlertButton -> Alert
+connectionNeededAlert button = Alert
+	{ alertHeader = Just "Share with friends, and keep your devices in sync across the cloud."
+	, alertIcon = Just ConnectionIcon
+	, alertPriority = High
+	, alertButtons = [button]
+	, alertClosable = True
+	, alertClass = Message
+	, alertMessageRender = renderData
+	, alertCounter = 0
+	, alertBlockDisplay = True
+	, alertName = Just ConnectionNeededAlert
+	, alertCombiner = Just $ dataCombiner $ \_old new -> new
+	, alertData = []
+	}
+
+cloudRepoNeededAlert :: Maybe String -> AlertButton -> Alert
+cloudRepoNeededAlert friendname button = Alert
+	{ alertHeader = Just $ fromString $ unwords
+		[ "Unable to download files from"
+		, (fromMaybe "your other devices" friendname) ++ "."
+		]
+	, alertIcon = Just ErrorIcon
+	, alertPriority = High
+	, alertButtons = [button]
+	, alertClosable = True
+	, alertClass = Message
+	, alertMessageRender = renderData
+	, alertCounter = 0
+	, alertBlockDisplay = True
+	, alertName = Just $ CloudRepoNeededAlert
+	, alertCombiner = Just $ dataCombiner $ \_old new -> new
+	, alertData = []
+	}
+
+remoteRemovalAlert :: String -> AlertButton -> Alert
+remoteRemovalAlert desc button = Alert
+	{ alertHeader = Just $ fromString $
+		"The repository \"" ++ desc ++ 
+		"\" has been emptied, and can now be removed."
+	, alertIcon = Just InfoIcon
+	, alertPriority = High
+	, alertButtons = [button]
+	, alertClosable = True
+	, alertClass = Message
+	, alertMessageRender = renderData
+	, alertCounter = 0
+	, alertBlockDisplay = True
+	, alertName = Just $ RemoteRemovalAlert desc
+	, alertCombiner = Just $ dataCombiner $ \_old new -> new
+	, alertData = []
+	}
+
+{- Show a message that relates to a list of files.
+ -
+ - The most recent several files are shown, and a count of any others. -}
+fileAlert :: TenseChunk -> [FilePath] -> Alert
+fileAlert msg files = (activityAlert Nothing shortfiles)
+	{ alertName = Just $ FileAlert msg
+	, alertMessageRender = renderer
+	, alertCounter = counter
+	, alertCombiner = Just $ fullCombiner combiner
+	}
+  where
+	maxfilesshown = 10
+
+	(!somefiles, !counter) = splitcounter (dedupadjacent files)
+	!shortfiles = map (fromString . shortFile . takeFileName) somefiles
+
+	renderer alert = tenseWords $ msg : alertData alert ++ showcounter
+	  where
+		showcounter = case alertCounter alert of
+			0 -> []
+			_ -> [fromString $ "and " ++ show (alertCounter alert) ++ " other files"]
+
+	dedupadjacent (x:y:rest)
+		| x == y = dedupadjacent (y:rest)
+		| otherwise = x : dedupadjacent (y:rest)
+	dedupadjacent (x:[]) = [x]
+	dedupadjacent [] = []
+
+	{- Note that this ensures the counter is never 1; no need to say 
+	 - "1 file" when the filename could be shown. -}
+	splitcounter l
+		| length l <= maxfilesshown = (l, 0)
+		| otherwise =
+			let (keep, rest) = splitAt (maxfilesshown - 1) l
+			in (keep, length rest)
+	
+	combiner new old =
+		let (!fs, n) = splitcounter $
+			dedupadjacent $ alertData new ++ alertData old
+		    !cnt = n + alertCounter new + alertCounter old
+		in old
+			{ alertData = fs
+			, alertCounter = cnt
+			}
+
+addFileAlert :: [FilePath] -> Alert
+addFileAlert = fileAlert (Tensed "Adding" "Added")
+
+{- This is only used as a success alert after a transfer, not during it. -}
+transferFileAlert :: Direction -> Bool -> FilePath -> Alert
+transferFileAlert direction True file
+	| direction == Upload = fileAlert "Uploaded" [file]
+	| otherwise = fileAlert "Downloaded" [file]
+transferFileAlert direction False file
+	| direction == Upload = fileAlert "Upload failed" [file]
+	| otherwise = fileAlert "Download failed" [file]
+
+dataCombiner :: ([TenseChunk] -> [TenseChunk] -> [TenseChunk]) -> AlertCombiner
+dataCombiner combiner = fullCombiner $
+	\new old -> old { alertData = alertData new `combiner` alertData old }
+
+fullCombiner :: (Alert -> Alert -> Alert) -> AlertCombiner
+fullCombiner combiner new old
+	| alertClass new /= alertClass old = Nothing
+	| alertName new == alertName old = 
+		Just $! new `combiner` old
+	| otherwise = Nothing
+
+shortFile :: FilePath -> String
+shortFile f
+	| len < maxlen = f
+	| otherwise = take half f ++ ".." ++ drop (len - half) f
+  where
+	len = length f
+	maxlen = 20
+	half = (maxlen - 2) `div` 2 
+
diff --git a/Assistant/Alert/Utility.hs b/Assistant/Alert/Utility.hs
new file mode 100644
index 0000000000..8016d620a4
--- /dev/null
+++ b/Assistant/Alert/Utility.hs
@@ -0,0 +1,129 @@
+{- git-annex assistant alert utilities
+ -
+ - Copyright 2012, 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Alert.Utility where
+
+import Annex.Common
+import Assistant.Types.Alert
+import Utility.Tense
+
+import qualified Data.Text as T
+import Data.Text (Text)
+import qualified Data.Map.Strict as M
+
+{- This is as many alerts as it makes sense to display at a time.
+ - A display might be smaller, or larger, the point is to not overwhelm the
+ - user with a ton of alerts. -}
+displayAlerts :: Int
+displayAlerts = 6
+
+{- This is not a hard maximum, but there's no point in keeping a great
+ - many filler alerts in an AlertMap, so when there's more than this many,
+ - they start being pruned, down toward displayAlerts. -}
+maxAlerts :: Int
+maxAlerts = displayAlerts * 2
+
+type AlertPair = (AlertId, Alert)
+
+{- The desired order is the reverse of:
+ -
+ - - Pinned alerts
+ - - High priority alerts, newest first
+ - - Medium priority Activity, newest first (mostly used for Activity)
+ - - Low priority alerts, newest first
+ - - Filler priority alerts, newest first
+ - - Ties are broken by the AlertClass, with Errors etc coming first.
+ -}
+compareAlertPairs :: AlertPair -> AlertPair -> Ordering
+compareAlertPairs
+	(aid, Alert { alertClass = aclass, alertPriority = aprio })
+	(bid, Alert { alertClass = bclass, alertPriority = bprio })
+	 = compare aprio bprio
+		`mappend` compare aid bid
+			`mappend` compare aclass bclass
+
+sortAlertPairs :: [AlertPair] -> [AlertPair]
+sortAlertPairs = sortBy compareAlertPairs
+
+{- Renders an alert's header for display, if it has one. -}
+renderAlertHeader :: Alert -> Maybe Text
+renderAlertHeader alert = renderTense (alertTense alert) <$> alertHeader alert
+
+{- Renders an alert's message for display. -}
+renderAlertMessage :: Alert -> Text
+renderAlertMessage alert = renderTense (alertTense alert) $
+	(alertMessageRender alert) alert
+
+showAlert :: Alert -> String
+showAlert alert = T.unpack $ T.unwords $ catMaybes
+	[ renderAlertHeader alert
+	, Just $ renderAlertMessage alert
+	]
+
+alertTense :: Alert -> Tense
+alertTense alert
+	| alertClass alert == Activity = Present
+	| otherwise = Past
+
+{- Checks if two alerts display the same. -}
+effectivelySameAlert :: Alert -> Alert -> Bool
+effectivelySameAlert x y = all id 
+	[ alertClass x == alertClass y
+	, alertHeader x == alertHeader y
+	, alertData x == alertData y
+	, alertBlockDisplay x == alertBlockDisplay y
+	, alertClosable x == alertClosable y
+	, alertPriority x == alertPriority y
+	]
+
+makeAlertFiller :: Bool -> Alert -> Alert
+makeAlertFiller success alert
+	| isFiller alert = alert
+	| otherwise = alert
+		{ alertClass = if c == Activity then c' else c
+		, alertPriority = Filler
+		, alertClosable = True
+		, alertButtons = []
+		, alertIcon = Just $ if success then SuccessIcon else ErrorIcon
+		}
+  where
+	c = alertClass alert
+	c'
+		| success = Success
+		| otherwise = Error
+
+isFiller :: Alert -> Bool
+isFiller alert = alertPriority alert == Filler
+
+{- Updates the Alertmap, adding or updating an alert.
+ -
+ - Any old filler that looks the same as the alert is removed.
+ -
+ - Or, if the alert has an alertCombiner that combines it with
+ - an old alert, the old alert is replaced with the result, and the
+ - alert is removed.
+ -
+ - Old filler alerts are pruned once maxAlerts is reached.
+ -}
+mergeAlert :: AlertId -> Alert -> AlertMap -> AlertMap
+mergeAlert i al m = maybe updatePrune updateCombine (alertCombiner al)
+  where
+	pruneSame k al' = k == i || not (effectivelySameAlert al al')
+	pruneBloat m'
+		| bloat > 0 = M.fromList $ pruneold $ M.toList m'
+		| otherwise = m'
+	  where
+		bloat = M.size m' - maxAlerts
+		pruneold l =
+			let (f, rest) = partition (\(_, a) -> isFiller a) l
+			in drop bloat f ++ rest
+	updatePrune = pruneBloat $ M.filterWithKey pruneSame $ M.insert i al m
+	updateCombine combiner = 
+		let combined = M.mapMaybe (combiner al) m
+		in if M.null combined
+			then updatePrune
+			else M.delete i $ M.union combined m
diff --git a/Assistant/BranchChange.hs b/Assistant/BranchChange.hs
new file mode 100644
index 0000000000..b78e13a015
--- /dev/null
+++ b/Assistant/BranchChange.hs
@@ -0,0 +1,19 @@
+{- git-annex assistant git-annex branch change tracking
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.BranchChange where
+
+import Assistant.Common
+import Assistant.Types.BranchChange
+
+import Control.Concurrent.MSampleVar
+
+branchChanged :: Assistant ()
+branchChanged = flip writeSV () <<~ (fromBranchChangeHandle . branchChangeHandle)
+
+waitBranchChange :: Assistant ()
+waitBranchChange = readSV <<~ (fromBranchChangeHandle . branchChangeHandle)
diff --git a/Assistant/Changes.hs b/Assistant/Changes.hs
new file mode 100644
index 0000000000..4a20850fa0
--- /dev/null
+++ b/Assistant/Changes.hs
@@ -0,0 +1,47 @@
+{- git-annex assistant change tracking
+ -
+ - Copyright 2012-2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Changes where
+
+import Assistant.Common
+import Assistant.Types.Changes
+import Utility.TList
+
+import Data.Time.Clock
+import Control.Concurrent.STM
+
+{- Handlers call this when they made a change that needs to get committed. -}
+madeChange :: FilePath -> ChangeInfo -> Assistant (Maybe Change)
+madeChange f t = Just <$> (Change <$> liftIO getCurrentTime <*> pure f <*> pure t)
+
+noChange :: Assistant (Maybe Change)
+noChange = return Nothing
+
+{- Indicates an add needs to be done, but has not started yet. -}
+pendingAddChange :: FilePath -> Assistant (Maybe Change)
+pendingAddChange f = Just <$> (PendingAddChange <$> liftIO getCurrentTime <*> pure f)
+
+{- Gets all unhandled changes.
+ - Blocks until at least one change is made. -}
+getChanges :: Assistant [Change]
+getChanges = (atomically . getTList) <<~ changePool
+
+{- Gets all unhandled changes, without blocking. -}
+getAnyChanges :: Assistant [Change]
+getAnyChanges = (atomically . takeTList) <<~ changePool
+
+{- Puts unhandled changes back into the pool.
+ - Note: Original order is not preserved. -}
+refillChanges :: [Change] -> Assistant ()
+refillChanges cs = (atomically . flip appendTList cs) <<~ changePool
+
+{- Records a change to the pool. -}
+recordChange :: Change -> Assistant ()
+recordChange c = (atomically . flip snocTList c) <<~ changePool
+
+recordChanges :: [Change] -> Assistant ()
+recordChanges = refillChanges
diff --git a/Assistant/Commits.hs b/Assistant/Commits.hs
new file mode 100644
index 0000000000..09c3172ad4
--- /dev/null
+++ b/Assistant/Commits.hs
@@ -0,0 +1,32 @@
+{- git-annex assistant commit tracking
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Commits where
+
+import Assistant.Common
+import Assistant.Types.Commits
+import Utility.TList
+
+import Control.Concurrent.STM
+
+{- Gets all unhandled commits.
+ - Blocks until at least one commit is made. -}
+getCommits :: Assistant [Commit]
+getCommits = (atomically . getTList) <<~ commitChan
+
+{- Records a commit in the channel. -}
+recordCommit :: Assistant ()
+recordCommit = (atomically . flip consTList Commit) <<~ commitChan
+
+{- Gets all unhandled export commits.
+ - Blocks until at least one export commit is made. -}
+getExportCommits :: Assistant [Commit]
+getExportCommits = (atomically . getTList) <<~ exportCommitChan
+
+{- Records an export commit in the channel. -}
+recordExportCommit :: Assistant ()
+recordExportCommit = (atomically . flip consTList Commit) <<~ exportCommitChan
diff --git a/Assistant/Common.hs b/Assistant/Common.hs
new file mode 100644
index 0000000000..33532ec216
--- /dev/null
+++ b/Assistant/Common.hs
@@ -0,0 +1,14 @@
+{- Common infrastructure for the git-annex assistant.
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Common (module X) where
+
+import Annex.Common as X hiding (debug)
+import Assistant.Monad as X
+import Assistant.Types.DaemonStatus as X
+import Assistant.Types.NamedThread as X
+import Assistant.Types.Alert as X
diff --git a/Assistant/CredPairCache.hs b/Assistant/CredPairCache.hs
new file mode 100644
index 0000000000..eba3d2b779
--- /dev/null
+++ b/Assistant/CredPairCache.hs
@@ -0,0 +1,53 @@
+{- git-annex assistant CredPair cache.
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Assistant.CredPairCache (
+	cacheCred,
+	getCachedCred,
+	expireCachedCred,
+) where
+
+import Assistant.Types.CredPairCache
+import Types.Creds
+import Assistant.Common
+import Utility.ThreadScheduler
+
+import qualified Data.Map as M
+import Control.Concurrent
+
+{- Caches a CredPair, but only for a limited time, after which it
+ - will expire.
+ -
+ - Note that repeatedly caching the same CredPair
+ - does not reset its expiry time.
+ -}
+cacheCred :: CredPair -> Seconds -> Assistant ()
+cacheCred (login, password) expireafter = do
+	cache <- getAssistant credPairCache
+	liftIO $ do
+		changeStrict cache $ M.insert login password
+		void $ forkIO $ do
+			threadDelaySeconds expireafter
+			changeStrict cache $ M.delete login
+
+getCachedCred :: Login -> Assistant (Maybe Password)
+getCachedCred login = do
+	cache <- getAssistant credPairCache
+	liftIO $ M.lookup login <$> readMVar cache
+
+expireCachedCred :: Login -> Assistant ()
+expireCachedCred login = do
+	cache <- getAssistant credPairCache
+	liftIO $ changeStrict cache $ M.delete login
+
+{- Update map strictly to avoid keeping references to old creds in memory. -}
+changeStrict :: CredPairCache -> (M.Map Login Password -> M.Map Login Password) -> IO ()
+changeStrict cache a = modifyMVar_ cache $ \m -> do
+	let !m' = a m
+	return m'
diff --git a/Assistant/DaemonStatus.hs b/Assistant/DaemonStatus.hs
new file mode 100644
index 0000000000..9be4558761
--- /dev/null
+++ b/Assistant/DaemonStatus.hs
@@ -0,0 +1,273 @@
+{- git-annex assistant daemon status
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Assistant.DaemonStatus where
+
+import Assistant.Common
+import Assistant.Alert.Utility
+import Utility.Tmp
+import Utility.NotificationBroadcaster
+import Types.Availability
+import Types.Transfer
+import Logs.Transfer
+import Logs.Trust
+import Utility.TimeStamp
+import qualified Remote
+import qualified Types.Remote as Remote
+import Config.DynamicConfig
+import Annex.SpecialRemote.Config
+
+import Control.Concurrent.STM
+import System.Posix.Types
+import Data.Time.Clock.POSIX
+import qualified Data.Map.Strict as M
+import qualified Data.Set as S
+
+getDaemonStatus :: Assistant DaemonStatus
+getDaemonStatus = (atomically . readTVar) <<~ daemonStatusHandle
+
+modifyDaemonStatus_ :: (DaemonStatus -> DaemonStatus) -> Assistant ()
+modifyDaemonStatus_ a = modifyDaemonStatus $ \s -> (a s, ())
+
+modifyDaemonStatus :: (DaemonStatus -> (DaemonStatus, b)) -> Assistant b
+modifyDaemonStatus a = do
+	dstatus <- getAssistant daemonStatusHandle
+	liftIO $ do
+		(s, b) <- atomically $ do
+			r@(!s, _) <- a <$> readTVar dstatus
+			writeTVar dstatus s
+			return r
+		sendNotification $ changeNotifier s
+		return b
+
+{- Returns a function that updates the lists of syncable remotes
+ - and other associated information. -}
+calcSyncRemotes :: Annex (DaemonStatus -> DaemonStatus)
+calcSyncRemotes = do
+	rs <- filterM (liftIO . getDynamicConfig . remoteAnnexSync . Remote.gitconfig)
+		=<< (concat . Remote.byCost <$> Remote.remoteList)
+	alive <- trustExclude DeadTrusted (map Remote.uuid rs)
+	let good r = Remote.uuid r `elem` alive
+	let syncable = filter good rs
+	contentremotes <- filterM (not <$$> liftIO . getDynamicConfig . remoteAnnexIgnore . Remote.gitconfig) $
+		filter (\r -> Remote.uuid r /= NoUUID) syncable
+	let (exportremotes, nonexportremotes) = partition (exportTree . Remote.config) contentremotes
+	let isimport r = importTree (Remote.config r) || Remote.thirdPartyPopulated (Remote.remotetype r)
+	let dataremotes = filter (not . isimport) nonexportremotes
+	tocloud <- anyM iscloud contentremotes
+
+	return $ \dstatus -> dstatus
+		{ syncRemotes = syncable
+		, syncGitRemotes = filter (Remote.gitSyncableRemoteType . Remote.remotetype) syncable
+		, syncDataRemotes = dataremotes
+		, exportRemotes = exportremotes
+		, downloadRemotes = contentremotes
+		, syncingToCloudRemote = tocloud
+		}
+  where
+	iscloud r
+		| Remote.readonly r = pure False
+		| otherwise = tryNonAsync (Remote.availability r) >>= return . \case
+			Right GloballyAvailable -> True
+			_ -> False
+
+{- Updates the syncRemotes list from the list of all remotes in Annex state. -}
+updateSyncRemotes :: Assistant ()
+updateSyncRemotes = do
+	modifyDaemonStatus_ =<< liftAnnex calcSyncRemotes
+	status <- getDaemonStatus
+	liftIO $ sendNotification $ syncRemotesNotifier status
+
+	when (syncingToCloudRemote status) $
+		updateAlertMap $
+			M.filter $ \alert ->
+				alertName alert /= Just CloudRepoNeededAlert
+
+changeCurrentlyConnected :: (S.Set UUID -> S.Set UUID) -> Assistant ()
+changeCurrentlyConnected sm = do
+	modifyDaemonStatus_ $ \ds -> ds
+		{ currentlyConnectedRemotes = sm (currentlyConnectedRemotes ds)
+		}
+	v <- currentlyConnectedRemotes <$> getDaemonStatus
+	debug [show v]
+	liftIO . sendNotification =<< syncRemotesNotifier <$> getDaemonStatus
+
+updateScheduleLog :: Assistant ()
+updateScheduleLog =
+	liftIO . sendNotification =<< scheduleLogNotifier <$> getDaemonStatus
+
+{- Load any previous daemon status file, and store it in a MVar for this
+ - process to use as its DaemonStatus. Also gets current transfer status. -}
+startDaemonStatus :: Annex DaemonStatusHandle
+startDaemonStatus = do
+	file <- fromRepo gitAnnexDaemonStatusFile
+	status <- liftIO $
+		flip catchDefaultIO (readDaemonStatusFile file) =<< newDaemonStatus
+	transfers <- M.fromList <$> getTransfers
+	addsync <- calcSyncRemotes
+	liftIO $ atomically $ newTVar $ addsync $ status
+		{ scanComplete = False
+		, sanityCheckRunning = False
+		, currentTransfers = transfers
+		}
+
+{- Don't just dump out the structure, because it will change over time,
+ - and parts of it are not relevant. -}
+writeDaemonStatusFile :: FilePath -> DaemonStatus -> IO ()
+writeDaemonStatusFile file status = 
+	viaTmp writeFile file =<< serialized <$> getPOSIXTime
+  where
+	serialized now = unlines
+		[ "lastRunning:" ++ show now
+		, "scanComplete:" ++ show (scanComplete status)
+		, "sanityCheckRunning:" ++ show (sanityCheckRunning status)
+		, "lastSanityCheck:" ++ maybe "" show (lastSanityCheck status)
+		]
+
+readDaemonStatusFile :: FilePath -> IO DaemonStatus
+readDaemonStatusFile file = parse <$> newDaemonStatus <*> readFile file
+  where
+	parse status = foldr parseline status . lines
+	parseline line status
+		| key == "lastRunning" = parseval parsePOSIXTime $ \v ->
+			status { lastRunning = Just v }
+		| key == "scanComplete" = parseval readish $ \v ->
+			status { scanComplete = v }
+		| key == "sanityCheckRunning" = parseval readish $ \v ->
+			status { sanityCheckRunning = v }
+		| key == "lastSanityCheck" = parseval parsePOSIXTime $ \v ->
+			status { lastSanityCheck = Just v }
+		| otherwise = status -- unparsable line
+	  where
+		(key, value) = separate (== ':') line
+		parseval parser a = maybe status a (parser value)
+
+{- Checks if a time stamp was made after the daemon was lastRunning.
+ -
+ - Some slop is built in; this really checks if the time stamp was made
+ - at least ten minutes after the daemon was lastRunning. This is to
+ - ensure the daemon shut down cleanly, and deal with minor clock skew.
+ -
+ - If the daemon has never ran before, this always returns False.
+ -}
+afterLastDaemonRun :: EpochTime -> DaemonStatus -> Bool
+afterLastDaemonRun timestamp status = maybe False (< t) (lastRunning status)
+  where
+	t = realToFrac (timestamp + slop) :: POSIXTime
+	slop = fromIntegral tenMinutes
+
+tenMinutes :: Int
+tenMinutes = 10 * 60
+
+{- Mutates the transfer map. Runs in STM so that the transfer map can
+ - be modified in the same transaction that modifies the transfer queue.
+ - Note that this does not send a notification of the change; that's left
+ - to the caller. -}
+adjustTransfersSTM :: DaemonStatusHandle -> (TransferMap -> TransferMap) -> STM ()
+adjustTransfersSTM dstatus a = do
+	s <- readTVar dstatus
+	let !v = a (currentTransfers s)
+	writeTVar dstatus $ s { currentTransfers = v }
+
+{- Checks if a transfer is currently running. -}
+checkRunningTransferSTM :: DaemonStatusHandle -> Transfer -> STM Bool
+checkRunningTransferSTM dstatus t = M.member t . currentTransfers
+	<$> readTVar dstatus
+
+{- Alters a transfer's info, if the transfer is in the map. -}
+alterTransferInfo :: Transfer -> (TransferInfo -> TransferInfo) -> Assistant ()
+alterTransferInfo t a = updateTransferInfo' $ M.adjust a t
+
+{- Updates a transfer's info. Adds the transfer to the map if necessary,
+ - or if already present, updates it while preserving the old transferTid,
+ - transferPaused, and bytesComplete values, which are not written to disk. -}
+updateTransferInfo :: Transfer -> TransferInfo -> Assistant ()
+updateTransferInfo t info = updateTransferInfo' $ M.insertWith merge t info
+  where
+	merge new old = new
+		{ transferTid = maybe (transferTid new) Just (transferTid old)
+		, transferPaused = transferPaused new || transferPaused old
+		, bytesComplete = maybe (bytesComplete new) Just (bytesComplete old)
+		}
+
+updateTransferInfo' :: (TransferMap -> TransferMap) -> Assistant ()
+updateTransferInfo' a = notifyTransfer `after` modifyDaemonStatus_ update
+  where
+	update s = s { currentTransfers = a (currentTransfers s) }
+
+{- Removes a transfer from the map, and returns its info. -}
+removeTransfer :: Transfer -> Assistant (Maybe TransferInfo)
+removeTransfer t = notifyTransfer `after` modifyDaemonStatus remove
+  where
+	remove s =
+		let (info, ts) = M.updateLookupWithKey
+			(\_k _v -> Nothing)
+			t (currentTransfers s)
+		in (s { currentTransfers = ts }, info)
+
+{- Send a notification when a transfer is changed. -}
+notifyTransfer :: Assistant ()
+notifyTransfer = do
+	dstatus <- getAssistant daemonStatusHandle
+	liftIO $ sendNotification
+		=<< transferNotifier <$> atomically (readTVar dstatus)
+
+{- Send a notification when alerts are changed. -}
+notifyAlert :: Assistant ()
+notifyAlert = do
+	dstatus <- getAssistant daemonStatusHandle
+	liftIO $ sendNotification
+		=<< alertNotifier <$> atomically (readTVar dstatus)
+
+{- Returns the alert's identifier, which can be used to remove it. -}
+addAlert :: Alert -> Assistant AlertId
+addAlert alert = notifyAlert `after` modifyDaemonStatus add
+  where
+	add s = (s { lastAlertId = i, alertMap = m }, i)
+	  where
+		!i = nextAlertId $ lastAlertId s
+		!m = mergeAlert i alert (alertMap s)
+
+removeAlert :: AlertId -> Assistant ()
+removeAlert i = updateAlert i (const Nothing)
+
+updateAlert :: AlertId -> (Alert -> Maybe Alert) -> Assistant ()
+updateAlert i a = updateAlertMap $ \m -> M.update a i m
+
+updateAlertMap :: (AlertMap -> AlertMap) -> Assistant ()
+updateAlertMap a = notifyAlert `after` modifyDaemonStatus_ update
+  where
+	update s = 
+		let !m = a (alertMap s)
+		in s { alertMap = m }
+
+{- Displays an alert while performing an activity that returns True on
+ - success.
+ -
+ - The alert is left visible afterwards, as filler.
+ - Old filler is pruned, to prevent the map growing too large. -}
+alertWhile :: Alert -> Assistant Bool -> Assistant Bool
+alertWhile alert a = alertWhile' alert $ do
+	r <- a
+	return (r, r)
+
+{- Like alertWhile, but allows the activity to return a value too. -}
+alertWhile' :: Alert -> Assistant (Bool, a) -> Assistant a
+alertWhile' alert a = do
+	let alert' = alert { alertClass = Activity }
+	i <- addAlert alert'
+	(ok, r) <- a
+	updateAlertMap $ mergeAlert i $ makeAlertFiller ok alert'
+	return r
+
+{- Displays an alert while performing an activity, then removes it. -}
+alertDuring :: Alert -> Assistant a -> Assistant a
+alertDuring alert a = do
+	i <- addAlert $ alert { alertClass = Activity }
+	removeAlert  i `after` a
diff --git a/Assistant/DeleteRemote.hs b/Assistant/DeleteRemote.hs
new file mode 100644
index 0000000000..fa788f086f
--- /dev/null
+++ b/Assistant/DeleteRemote.hs
@@ -0,0 +1,89 @@
+{- git-annex assistant remote deletion utilities
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Assistant.DeleteRemote where
+
+import Assistant.Common
+import Assistant.Types.UrlRenderer
+import Assistant.TransferQueue
+import Types.Transfer
+import Logs.Location
+import Assistant.DaemonStatus
+import qualified Remote
+import Remote.List.Util
+import qualified Git.Remote.Remove
+import Logs.Trust
+import qualified Annex
+
+#ifdef WITH_WEBAPP
+import Assistant.WebApp.Types
+import Assistant.Alert
+import qualified Data.Text as T
+#endif
+
+{- Removes a remote (but leave the repository as-is), and returns the old
+ - Remote data. -}
+disableRemote :: UUID -> Assistant Remote
+disableRemote uuid = do
+	remote <- fromMaybe (giveup "unknown remote")
+		<$> liftAnnex (Remote.remoteFromUUID uuid)
+	liftAnnex $ do
+		inRepo $ Git.Remote.Remove.remove (Remote.name remote)
+		remotesChanged
+	updateSyncRemotes
+	return remote
+
+{- Removes a remote, marking it dead .-}
+removeRemote :: UUID -> Assistant Remote
+removeRemote uuid = do
+	liftAnnex $ trustSet uuid DeadTrusted
+	disableRemote uuid
+
+{- Called when a Remote is probably empty, to remove it.
+ -
+ - This does one last check for any objects remaining in the Remote,
+ - and if there are any, queues Downloads of them, and defers removing
+ - the remote for later. This is to catch any objects not referred to
+ - in keys in the current branch.
+ -}
+removableRemote :: UrlRenderer -> UUID -> Assistant ()
+removableRemote urlrenderer uuid = getkeys >>= \case
+	Just keys
+		| null keys -> finishRemovingRemote urlrenderer uuid
+		| otherwise -> do
+			r <- fromMaybe (giveup "unknown remote")
+				<$> liftAnnex (Remote.remoteFromUUID uuid)
+			mapM_ (queueremaining r) keys
+	Nothing -> noop
+  where
+	queueremaining r k = 
+		queueTransferWhenSmall "remaining object in unwanted remote"
+			(AssociatedFile Nothing) (Transfer Download uuid (fromKey id k)) r
+	{- Scanning for keys can take a long time; do not tie up
+	 - the Annex monad while doing it, so other threads continue to
+	 - run. -}
+	getkeys = do
+		a <- liftAnnex $ Annex.withCurrentState $ loggedKeysFor uuid
+		liftIO a
+
+{- With the webapp, this asks the user to click on a button to finish
+ - removing the remote.
+ -
+ - Without the webapp, just do the removal now.
+ -}
+finishRemovingRemote :: UrlRenderer -> UUID -> Assistant ()
+#ifdef WITH_WEBAPP
+finishRemovingRemote urlrenderer uuid = do
+	desc <- liftAnnex $ Remote.prettyUUID uuid
+	button <- mkAlertButton True (T.pack "Finish deletion process") urlrenderer $
+		FinishDeleteRepositoryR uuid
+	void $ addAlert $ remoteRemovalAlert desc button
+#else
+finishRemovingRemote _ uuid = void $ removeRemote uuid
+#endif
diff --git a/Assistant/Drop.hs b/Assistant/Drop.hs
new file mode 100644
index 0000000000..06b09951ac
--- /dev/null
+++ b/Assistant/Drop.hs
@@ -0,0 +1,30 @@
+{- git-annex assistant dropping of unwanted content
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Drop (
+	handleDrops,
+	handleDropsFrom,
+) where
+
+import Assistant.Common
+import Assistant.DaemonStatus
+import Annex.Drop (handleDropsFrom, Reason)
+import Logs.Location
+import CmdLine.Action
+import Types.NumCopies
+import Types.Command
+
+{- Drop from local and/or remote when allowed by the preferred content and
+ - numcopies settings. -}
+handleDrops :: Reason -> Bool -> Key -> AssociatedFile -> [VerifiedCopy] -> Assistant ()
+handleDrops reason fromhere key f preverified = do
+	syncrs <- syncDataRemotes <$> getDaemonStatus
+	locs <- liftAnnex $ loggedLocations key
+	liftAnnex $ handleDropsFrom
+		locs syncrs reason fromhere key f
+		(SeekInput [])
+		preverified callCommandAction
diff --git a/Assistant/Fsck.hs b/Assistant/Fsck.hs
new file mode 100644
index 0000000000..067c7d1a10
--- /dev/null
+++ b/Assistant/Fsck.hs
@@ -0,0 +1,50 @@
+{- git-annex assistant fscking
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Fsck where
+
+import Assistant.Common
+import Types.ScheduledActivity
+import qualified Types.Remote as Remote
+import Annex.UUID
+import Assistant.Alert
+import Assistant.Types.UrlRenderer
+import Logs.Schedule
+import qualified Annex
+
+import qualified Data.Set as S
+
+{- Displays a nudge in the webapp if a fsck is not configured for
+ - the specified remote, or for the local repository. -}
+fsckNudge :: UrlRenderer -> Maybe Remote -> Assistant ()
+fsckNudge urlrenderer mr
+	| maybe True fsckableRemote mr =
+		whenM (liftAnnex $ annexFsckNudge <$> Annex.getGitConfig) $
+			unlessM (liftAnnex $ checkFscked mr) $
+				notFsckedNudge urlrenderer mr
+	| otherwise = noop
+
+fsckableRemote :: Remote -> Bool
+fsckableRemote = isJust . Remote.remoteFsck
+
+{- Checks if the remote, or the local repository, has a fsck scheduled.
+ - Only looks at fscks configured to run via the local repository, not
+ - other repositories. -}
+checkFscked :: Maybe Remote -> Annex Bool
+checkFscked mr = any wanted . S.toList <$> (scheduleGet =<< getUUID)
+  where
+	wanted = case mr of
+		Nothing -> isSelfFsck
+		Just r -> flip isFsckOf (Remote.uuid r)
+
+isSelfFsck :: ScheduledActivity -> Bool
+isSelfFsck (ScheduledSelfFsck _ _) = True
+isSelfFsck _ = False
+
+isFsckOf :: ScheduledActivity -> UUID -> Bool
+isFsckOf (ScheduledRemoteFsck u _ _) u' = u == u'
+isFsckOf _ _ = False
diff --git a/Assistant/Gpg.hs b/Assistant/Gpg.hs
new file mode 100644
index 0000000000..01226e0640
--- /dev/null
+++ b/Assistant/Gpg.hs
@@ -0,0 +1,38 @@
+{- git-annex assistant gpg stuff
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Gpg where
+
+import Utility.Gpg
+import Utility.UserInfo
+import Types.Remote (RemoteConfigField)
+import Annex.SpecialRemote.Config
+import Types.ProposedAccepted
+
+import qualified Data.Map as M
+import Control.Applicative
+import Prelude
+
+{- Generates a gpg user id that is not used by any existing secret key -}
+newUserId :: GpgCmd -> IO UserId
+newUserId cmd = do
+	oldkeys <- secretKeys cmd
+	username <- either (const "unknown") id <$> myUserName
+	let basekeyname = username ++ "'s git-annex encryption key"
+	return $ Prelude.head $ filter (\n -> M.null $ M.filter (== n) oldkeys)
+		( basekeyname
+		: map (\n -> basekeyname ++ show n) ([2..] :: [Int])
+		)
+
+data EnableEncryption = HybridEncryption | SharedEncryption | NoEncryption
+	deriving (Eq)
+
+{- Generates Remote configuration for encryption. -}
+configureEncryption :: EnableEncryption -> (RemoteConfigField, ProposedAccepted String)
+configureEncryption SharedEncryption = (encryptionField, Proposed "shared")
+configureEncryption NoEncryption = (encryptionField, Proposed "none")
+configureEncryption HybridEncryption = (encryptionField, Proposed "hybrid")
diff --git a/Assistant/Install.hs b/Assistant/Install.hs
new file mode 100644
index 0000000000..c11b6d5585
--- /dev/null
+++ b/Assistant/Install.hs
@@ -0,0 +1,175 @@
+{- Assistant installation
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Assistant.Install where
+
+import Assistant.Common
+import Assistant.Install.AutoStart
+import Config.Files
+import Utility.FileMode
+import Utility.Shell
+import Utility.Tmp
+import Utility.Env
+import Utility.SshConfig
+
+#ifdef darwin_HOST_OS
+import Utility.OSX
+#else
+import Utility.FreeDesktop
+import Assistant.Install.Menu
+import Utility.UserInfo
+import Utility.Android
+#endif
+
+import System.PosixCompat.Files (ownerExecuteMode)
+
+standaloneAppBase :: IO (Maybe FilePath)
+standaloneAppBase = getEnv "GIT_ANNEX_APP_BASE"
+
+{- The standalone app does not have an installation process.
+ - So when it's run, it needs to set up autostarting of the assistant
+ - daemon, as well as writing the programFile, and putting the
+ - git-annex-shell and git-annex-wrapper wrapper scripts into ~/.ssh
+ -
+ - Note that this is done every time it's started, so if the user moves
+ - it around, the paths this sets up won't break.
+ -
+ - File manager hook script installation is done even for
+ - packaged apps, since it has to go into the user's home directory.
+ -}
+ensureInstalled :: IO ()
+ensureInstalled = ifM (isJust <$> getEnv "GIT_ANNEX_PACKAGE_INSTALL")
+	( go Nothing
+	, go =<< standaloneAppBase
+	)
+  where
+	go Nothing = installFileManagerHooks "git-annex"
+	go (Just base) = do
+		let program = base </> "git-annex"
+		programfile <- programFile
+		createDirectoryIfMissing True $
+			fromRawFilePath (parentDir (toRawFilePath programfile))
+		writeFile programfile program
+
+#ifdef darwin_HOST_OS
+		autostartfile <- userAutoStart osxAutoStartLabel
+		installAutoStart program autostartfile
+#else
+		ifM osAndroid
+			( do
+				-- Integration with the Termux:Boot app.
+				home <- myHomeDir
+				let bootfile = home </> ".termux" </> "boot" </> "git-annex"
+				unlessM (doesFileExist bootfile) $ do
+					createDirectoryIfMissing True (takeDirectory bootfile)
+					writeFile bootfile "git-annex assistant --autostart"
+			, do
+				menufile <- desktopMenuFilePath "git-annex" <$> userDataDir
+				icondir <- iconDir <$> userDataDir
+				installMenu program menufile base icondir
+				autostartfile <- autoStartPath "git-annex" <$> userConfigDir
+				installAutoStart program autostartfile
+			)
+#endif
+
+		sshdir <- sshDir
+		let runshell var = "exec " ++ base </> "runshell " ++ var
+		let rungitannexshell var = runshell $ "git-annex-shell -c \"" ++ var ++ "\""
+
+		installWrapper (sshdir </> "git-annex-shell") $ unlines
+			[ shebang
+			, "set -e"
+			, "if [ \"x$SSH_ORIGINAL_COMMAND\" != \"x\" ]; then"
+			,   rungitannexshell "$SSH_ORIGINAL_COMMAND"
+			, "else"
+			,   rungitannexshell "$@"
+			, "fi"
+			]
+		installWrapper (sshdir </> "git-annex-wrapper") $ unlines
+			[ shebang
+			, "set -e"
+			, runshell "\"$@\""
+			]
+
+		installFileManagerHooks program
+
+installWrapper :: FilePath -> String -> IO ()
+installWrapper file content = do
+	curr <- catchDefaultIO "" $ readFileStrict file
+	when (curr /= content) $ do
+		createDirectoryIfMissing True (fromRawFilePath (parentDir (toRawFilePath file)))
+		viaTmp writeFile file content
+		modifyFileMode (toRawFilePath file) $ 
+			addModes [ownerExecuteMode]
+
+installFileManagerHooks :: FilePath -> IO ()
+#ifdef linux_HOST_OS
+installFileManagerHooks program = unlessM osAndroid $ do
+	let actions = ["get", "drop", "undo"]
+
+	-- Gnome
+	nautilusScriptdir <- (\d -> d </> "nautilus" </> "scripts") <$> userDataDir
+	createDirectoryIfMissing True nautilusScriptdir
+	forM_ actions $
+		genNautilusScript nautilusScriptdir
+
+	-- KDE
+	userdata <- userDataDir
+	let kdeServiceMenusdir = userdata </> "kservices5" </> "ServiceMenus"
+	createDirectoryIfMissing True kdeServiceMenusdir
+	writeFile (kdeServiceMenusdir </> "git-annex.desktop")
+		(kdeDesktopFile actions)
+  where
+	genNautilusScript scriptdir action =
+		installscript (scriptdir </> scriptname action) $ unlines
+			[ shebang
+			, autoaddedcomment
+			, "exec " ++ program ++ " " ++ action ++ " --notify-start --notify-finish -- \"$@\""
+			]
+	scriptname action = "git-annex " ++ action
+	installscript f c = whenM (safetoinstallscript f) $ do
+		writeFile f c
+		modifyFileMode (toRawFilePath f) $ addModes [ownerExecuteMode]
+	safetoinstallscript f = catchDefaultIO True $
+		elem autoaddedcomment . lines <$> readFileStrict f
+	autoaddedcomment = "# " ++ autoaddedmsg ++ " (To disable, chmod 600 this file.)"
+	autoaddedmsg = "Automatically added by git-annex, do not edit."
+
+	kdeDesktopFile actions = unlines $ concat $
+		kdeDesktopHeader actions : map kdeDesktopAction actions
+	kdeDesktopHeader actions =
+		[ "# " ++ autoaddedmsg
+		, "[Desktop Entry]"
+		, "Type=Service"
+		, "ServiceTypes=all/allfiles"
+		, "MimeType=all/all;"
+		, "Actions=" ++ intercalate ";" (map kdeDesktopSection actions)
+		, "X-KDE-Priority=TopLevel"
+		, "X-KDE-Submenu=Git-Annex"
+		, "X-KDE-Icon=git-annex"
+		, "X-KDE-ServiceTypes=KonqPopupMenu/Plugin"
+		]
+	kdeDesktopSection command = "GitAnnex" ++ command
+	kdeDesktopAction command = 
+		[ ""
+		, "[Desktop Action " ++ kdeDesktopSection command ++ "]"
+		, "Name=" ++ command
+		, "Icon=git-annex"
+		, unwords
+			[ "Exec=sh -c 'cd \"$(dirname \"$1\")\" &&"
+			, program
+			, command
+			, "--notify-start --notify-finish -- \"$1\"'"
+			, "false" -- this becomes $0 in sh, so unused
+			, "%f"
+			]
+		]
+#else
+installFileManagerHooks _ = noop
+#endif
diff --git a/Assistant/Install/AutoStart.hs b/Assistant/Install/AutoStart.hs
new file mode 100644
index 0000000000..59fb7b674d
--- /dev/null
+++ b/Assistant/Install/AutoStart.hs
@@ -0,0 +1,41 @@
+{- Assistant autostart file installation
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Assistant.Install.AutoStart where
+
+import Utility.FreeDesktop
+#ifdef darwin_HOST_OS
+import Utility.OSX
+import Utility.Path
+import Utility.SystemDirectory
+import Utility.FileSystemEncoding
+#endif
+
+installAutoStart :: FilePath -> FilePath -> IO ()
+installAutoStart command file = do
+#ifdef darwin_HOST_OS
+	createDirectoryIfMissing True (fromRawFilePath (parentDir (toRawFilePath file)))
+	writeFile file $ genOSXAutoStartFile osxAutoStartLabel command
+		["assistant", "--autostart"]
+#else
+	writeDesktopMenuFile (fdoAutostart command) file
+#endif
+
+osxAutoStartLabel :: String
+osxAutoStartLabel = "com.branchable.git-annex.assistant"
+
+fdoAutostart :: FilePath -> DesktopEntry
+fdoAutostart command = genDesktopEntry
+	"Git Annex Assistant"
+	"Autostart"
+	False
+	(command ++ " assistant --autostart")
+	Nothing
+	[]
diff --git a/Assistant/Install/Menu.hs b/Assistant/Install/Menu.hs
new file mode 100644
index 0000000000..91fcd3baf5
--- /dev/null
+++ b/Assistant/Install/Menu.hs
@@ -0,0 +1,54 @@
+{- Assistant menu installation.
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Assistant.Install.Menu where
+
+import Utility.FreeDesktop
+import Utility.FileSystemEncoding
+import Utility.Path
+
+import System.IO
+import Utility.SystemDirectory
+#ifndef darwin_HOST_OS
+import System.FilePath
+#endif
+
+installMenu :: FilePath -> FilePath -> FilePath -> FilePath -> IO ()
+#ifdef darwin_HOST_OS
+installMenu _command _menufile _iconsrcdir _icondir = return ()
+#else
+installMenu command menufile iconsrcdir icondir = do
+	writeDesktopMenuFile (fdoDesktopMenu command) menufile
+	installIcon (iconsrcdir </> "logo.svg") $
+		iconFilePath (iconBaseName ++ ".svg") "scalable" icondir
+	installIcon (iconsrcdir </> "logo_16x16.png") $
+		iconFilePath (iconBaseName ++ ".png") "16x16" icondir
+#endif
+
+{- The command can be either just "git-annex", or the full path to use
+ - to run it. -}
+fdoDesktopMenu :: FilePath -> DesktopEntry
+fdoDesktopMenu command = genDesktopEntry
+	"Git Annex"
+	"Track and sync the files in your Git Annex"
+	False
+	(command ++ " webapp")
+	(Just iconBaseName)
+	["Network", "FileTransfer"]
+
+installIcon :: FilePath -> FilePath -> IO ()
+installIcon src dest = do
+	createDirectoryIfMissing True (fromRawFilePath (parentDir (toRawFilePath dest)))
+	withBinaryFile src ReadMode $ \hin ->
+		withBinaryFile dest WriteMode $ \hout ->
+			hGetContents hin >>= hPutStr hout
+
+iconBaseName :: String
+iconBaseName = "git-annex"
diff --git a/Assistant/MakeRemote.hs b/Assistant/MakeRemote.hs
new file mode 100644
index 0000000000..3d3c178f65
--- /dev/null
+++ b/Assistant/MakeRemote.hs
@@ -0,0 +1,184 @@
+{- git-annex assistant remote creation utilities
+ -
+ - Copyright 2012, 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Assistant.MakeRemote where
+
+import Assistant.Common
+import Assistant.Ssh
+import qualified Types.Remote as R
+import qualified Remote
+import Remote.List.Util
+import qualified Remote.Rsync as Rsync
+import qualified Remote.GCrypt as GCrypt
+import qualified Git
+import qualified Git.Command
+import qualified Annex
+import qualified Annex.SpecialRemote
+import Annex.SpecialRemote.Config
+import Logs.UUID
+import Logs.Remote
+import Git.Remote
+import Git.Types (RemoteName)
+import Creds
+import Assistant.Gpg
+import Utility.Gpg (KeyId)
+import Types.GitConfig
+import Config
+import Types.ProposedAccepted
+
+import qualified Data.Map as M
+
+{- Sets up a new git or rsync remote, accessed over ssh. -}
+makeSshRemote :: SshData -> Annex RemoteName
+makeSshRemote sshdata = maker (sshRepoName sshdata) (genSshUrl sshdata)
+  where
+	maker
+		| onlyCapability sshdata RsyncCapable = makeRsyncRemote
+		| otherwise = makeGitRemote
+
+{- Runs an action that returns a name of the remote, and finishes adding it. -}
+addRemote :: Annex RemoteName -> Annex Remote
+addRemote a = do
+	name <- a
+	remotesChanged
+	maybe (giveup "failed to add remote") return
+		=<< Remote.byName (Just name)
+
+{- Inits a rsync special remote, and returns its name. -}
+makeRsyncRemote :: RemoteName -> String -> Annex String
+makeRsyncRemote name location = makeRemote name location $ const $ void $
+	go =<< Annex.SpecialRemote.findExisting name
+  where
+	go [] = setupSpecialRemote name Rsync.remote config Nothing
+		(Nothing, R.Init, Annex.SpecialRemote.newConfig name Nothing mempty mempty) Nothing
+	go ((u, c, mcu):_) = setupSpecialRemote name Rsync.remote config Nothing
+		(Just u, R.Enable c, c) mcu
+	config = M.fromList
+		[ (encryptionField, Proposed "shared")
+		, (Proposed "rsyncurl", Proposed location)
+		, (typeField, Proposed "rsync")
+		]
+
+{- Inits a gcrypt special remote, and returns its name. -}
+makeGCryptRemote :: RemoteName -> String -> KeyId -> Annex RemoteName
+makeGCryptRemote remotename location keyid = 
+	initSpecialRemote remotename GCrypt.remote Nothing $ M.fromList
+		[ (typeField, Proposed "gcrypt")
+		, (Proposed "gitrepo", Proposed location)
+		, configureEncryption HybridEncryption
+		, (Proposed "keyid", Proposed keyid)
+		]
+
+type SpecialRemoteMaker = RemoteName -> RemoteType -> Maybe CredPair -> R.RemoteConfig -> Annex RemoteName
+
+{- Inits a new special remote. The name is used as a suggestion, but
+ - will be changed if there is already a special remote with that name. -}
+initSpecialRemote :: SpecialRemoteMaker
+initSpecialRemote name remotetype mcreds config = go 0
+  where
+	go :: Int -> Annex RemoteName
+	go n = do
+		let fullname = if n == 0  then name else name ++ show n
+		Annex.SpecialRemote.findExisting fullname >>= \case
+			[] -> setupSpecialRemote fullname remotetype config mcreds
+				(Nothing, R.Init, Annex.SpecialRemote.newConfig fullname Nothing mempty mempty) Nothing
+			_ -> go (n + 1)
+
+{- Enables an existing special remote. -}
+enableSpecialRemote :: SpecialRemoteMaker
+enableSpecialRemote name remotetype mcreds config =
+	Annex.SpecialRemote.findExisting name >>= \case
+		[] -> giveup $ "Cannot find a special remote named " ++ name
+		((u, c, mcu):_) -> setupSpecialRemote' False name remotetype config mcreds (Just u, R.Enable c, c) mcu
+
+setupSpecialRemote :: RemoteName -> RemoteType -> R.RemoteConfig -> Maybe CredPair -> (Maybe UUID, R.SetupStage, R.RemoteConfig) -> Maybe (Annex.SpecialRemote.ConfigFrom UUID) -> Annex RemoteName
+setupSpecialRemote = setupSpecialRemote' True
+
+setupSpecialRemote' :: Bool -> RemoteName -> RemoteType -> R.RemoteConfig -> Maybe CredPair -> (Maybe UUID, R.SetupStage, R.RemoteConfig) -> Maybe (Annex.SpecialRemote.ConfigFrom UUID) -> Annex RemoteName
+setupSpecialRemote' setdesc name remotetype config mcreds (mu, ss, c) mcu = do
+	{- Currently, only 'weak' ciphers can be generated from the
+	 - assistant, because otherwise GnuPG may block once the entropy
+	 - pool is drained, and as of now there's no way to tell the user
+	 - to perform IO actions to refill the pool. -}
+	let weakc = M.insert (Proposed "highRandomQuality") (Proposed "false") (M.union config c)
+	dummycfg <- liftIO dummyRemoteGitConfig
+	(c', u) <- R.setup remotetype ss mu mcreds weakc dummycfg
+	case mcu of
+		Nothing ->
+			configSet u c'
+		Just (Annex.SpecialRemote.ConfigFrom cu) -> do
+			setConfig (remoteAnnexConfig c' "config-uuid") (fromUUID cu)
+			configSet cu c'
+	when setdesc $
+		whenM (isNothing . M.lookup u <$> uuidDescMap) $
+			describeUUID u (toUUIDDesc name)
+	return name
+
+{- Returns the name of the git remote it created. If there's already a
+ - remote at the location, returns its name. -}
+makeGitRemote :: String -> String -> Annex RemoteName
+makeGitRemote basename location = makeRemote basename location $ \name ->
+	void $ inRepo $ Git.Command.runBool
+		[Param "remote", Param "add", Param name, Param location]
+
+{- If there's not already a remote at the location, adds it using the
+ - action, which is passed the name of the remote to make.
+ -
+ - Returns the name of the remote. -}
+makeRemote :: String -> String -> (RemoteName -> Annex ()) -> Annex RemoteName
+makeRemote basename location a = do
+	rs <- Annex.getGitRemotes
+	if not (any samelocation rs)
+		then do
+			let name = uniqueRemoteName basename 0 rs
+			a name
+			return name
+		else return basename
+  where
+	samelocation x = Git.repoLocation x == location
+
+{- Given a list of all remotes, generate an unused name for a new
+ - remote, adding a number if necessary.
+ -
+ - Ensures that the returned name is a legal git remote name. -}
+uniqueRemoteName :: String -> Int -> [Git.Repo] -> RemoteName
+uniqueRemoteName basename n rs
+	| null namecollision = name
+	| otherwise = uniqueRemoteName legalbasename (succ n) rs
+  where
+	namecollision = filter samename rs
+	samename x = Git.remoteName x == Just name
+	name
+		| n == 0 = legalbasename
+		| otherwise = legalbasename ++ show n
+	legalbasename = makeLegalName basename
+
+{- Finds a CredPair belonging to any Remote that is of a given type
+ - and matches some other criteria.
+ -
+ - This can be used as a default when another repository is being set up
+ - using the same service.
+ -
+ - A function must be provided that returns the CredPairStorage
+ - to use for a particular Remote's uuid.
+ -}
+previouslyUsedCredPair
+	:: (UUID -> CredPairStorage)
+	-> RemoteType
+	-> (Remote -> Bool)
+	-> Annex (Maybe CredPair)
+previouslyUsedCredPair getstorage remotetype criteria =
+	getM fromstorage
+		=<< filter criteria . filter sametype 
+		<$> Remote.remoteList
+  where
+	sametype r = R.typename (R.remotetype r) == R.typename remotetype
+	fromstorage r = do
+		let storage = getstorage (R.uuid r)
+		getRemoteCredPair (R.config r) (R.gitconfig r) storage
diff --git a/Assistant/MakeRepo.hs b/Assistant/MakeRepo.hs
new file mode 100644
index 0000000000..d85eb45775
--- /dev/null
+++ b/Assistant/MakeRepo.hs
@@ -0,0 +1,98 @@
+{- making local repositories
+ -
+ - Copyright 2012-2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Assistant.MakeRepo where
+
+import Assistant.WebApp.Common
+import Annex.Init
+import qualified Git.Construct
+import qualified Git.Config
+import qualified Git.Command
+import qualified Git.Branch
+import qualified Annex
+import Annex.UUID
+import Annex.AdjustedBranch
+import Annex.Action
+import Types.StandardGroups
+import Logs.PreferredContent
+import qualified Annex.Branch
+import Utility.Process.Transcript
+import Config
+
+{- Makes a new git repository. Or, if a git repository already
+ - exists, returns False. -}
+makeRepo :: FilePath -> Bool -> IO Bool
+makeRepo path bare = ifM (probeRepoExists path)
+	( return False
+	, do
+		(transcript, ok) <-
+			processTranscript "git" (toCommand params) Nothing
+		unless ok $
+			giveup $ "git init failed!\nOutput:\n" ++ transcript
+		return True
+	)
+  where
+	baseparams = [Param "init", Param "--quiet"]
+	params
+		| bare = baseparams ++ [Param "--bare", File path]
+		| otherwise = baseparams ++ [File path]
+
+{- Runs an action in the git repository in the specified directory. -}
+inDir :: FilePath -> Annex a -> IO a
+inDir dir a = do
+	state <- Annex.new
+		=<< Git.Config.read
+		=<< Git.Construct.fromPath (toRawFilePath dir)
+	Annex.eval state $ a `finally` quiesce True
+
+{- Creates a new repository, and returns its UUID. -}
+initRepo :: Bool -> Bool -> FilePath -> Maybe String -> Maybe StandardGroup -> IO UUID
+initRepo True primary_assistant_repo dir desc mgroup = inDir dir $ do
+	initRepo' desc mgroup
+	{- Initialize the master branch, so things that expect
+	 - to have it will work, before any files are added. -}
+	unlessM (fromMaybe False . Git.Config.isBare <$> gitRepo) $ do
+		cmode <- annexCommitMode <$> Annex.getGitConfig
+		void $ inRepo $ Git.Branch.commitCommand cmode
+			(Git.Branch.CommitQuiet True)
+			[ Param "--allow-empty"
+			, Param "-m"
+			, Param "created repository"
+			]
+	{- Repositories directly managed by the assistant use 
+	 - an adjusted unlocked branch with annex.thin set.
+	 - 
+	 - Automatic gc is disabled, as it can be slow. Instead, gc is done
+	 - once a day.
+	 -}
+	when primary_assistant_repo $ do
+		void $ enterAdjustedBranch (LinkAdjustment UnlockAdjustment)
+		setConfig (annexConfig "thin") (Git.Config.boolConfig True)
+		inRepo $ Git.Command.run
+			[Param "config", Param "gc.auto", Param "0"]
+	getUUID
+{- Repo already exists, could be a non-git-annex repo though so
+ - still initialize it. -}
+initRepo False _ dir desc mgroup = inDir dir $ do
+	initRepo' desc mgroup
+	getUUID
+
+initRepo' :: Maybe String -> Maybe StandardGroup -> Annex ()
+initRepo' desc mgroup = unlessM isInitialized $ do
+	initialize desc Nothing
+	u <- getUUID
+	maybe noop (defaultStandardGroup u) mgroup
+	{- Ensure branch gets committed right away so it is
+	 - available for merging immediately. -}
+	Annex.Branch.commit =<< Annex.Branch.commitMessage
+
+{- Checks if a git repo exists at a location. -}
+probeRepoExists :: FilePath -> IO Bool
+probeRepoExists dir = isJust <$>
+	catchDefaultIO Nothing (Git.Construct.checkForRepo (encodeBS dir))
diff --git a/Assistant/Monad.hs b/Assistant/Monad.hs
new file mode 100644
index 0000000000..dcdbeaf4dd
--- /dev/null
+++ b/Assistant/Monad.hs
@@ -0,0 +1,144 @@
+{- git-annex assistant monad
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE GeneralizedNewtypeDeriving, MultiParamTypeClasses #-}
+{-# LANGUAGE PackageImports #-}
+
+module Assistant.Monad (
+	Assistant,
+	AssistantData(..),
+	newAssistantData,
+	runAssistant,
+	getAssistant,
+	LiftAnnex,
+	liftAnnex,
+	(<~>),
+	(<<~),
+	asIO,
+	asIO1,
+	asIO2,
+	ThreadName,
+	debug,
+) where
+
+import "mtl" Control.Monad.Reader
+import qualified Control.Monad.Fail as Fail
+
+import Annex.Common hiding (debug)
+import Assistant.Types.ThreadedMonad
+import Assistant.Types.DaemonStatus
+import Assistant.Types.ScanRemotes
+import Assistant.Types.TransferQueue
+import Assistant.Types.TransferSlots
+import Assistant.Types.Pushes
+import Assistant.Types.BranchChange
+import Assistant.Types.Commits
+import Assistant.Types.Changes
+import Assistant.Types.RepoProblem
+import Assistant.Types.ThreadName
+import Assistant.Types.RemoteControl
+import Assistant.Types.CredPairCache
+import qualified Utility.Debug as Debug
+
+newtype Assistant a = Assistant { mkAssistant :: ReaderT AssistantData IO a }
+	deriving (
+		Monad,
+		MonadIO,
+		MonadReader AssistantData,
+		MonadCatch,
+		MonadThrow,
+		MonadMask,
+		Fail.MonadFail,
+		Functor,
+		Applicative
+	)
+
+data AssistantData = AssistantData
+	{ threadName :: ThreadName
+	, threadState :: ThreadState
+	, daemonStatusHandle :: DaemonStatusHandle
+	, scanRemoteMap :: ScanRemoteMap
+	, transferQueue :: TransferQueue
+	, transferSlots :: TransferSlots
+	, failedPushMap :: FailedPushMap
+	, failedExportMap :: FailedPushMap
+	, commitChan :: CommitChan
+	, exportCommitChan :: CommitChan
+	, changePool :: ChangePool
+	, repoProblemChan :: RepoProblemChan
+	, branchChangeHandle :: BranchChangeHandle
+	, remoteControl :: RemoteControl
+	, credPairCache :: CredPairCache
+	}
+
+newAssistantData :: ThreadState -> DaemonStatusHandle -> IO AssistantData
+newAssistantData st dstatus = AssistantData
+	<$> pure (ThreadName "main")
+	<*> pure st
+	<*> pure dstatus
+	<*> newScanRemoteMap
+	<*> newTransferQueue
+	<*> newTransferSlots
+	<*> newFailedPushMap
+	<*> newFailedPushMap
+	<*> newCommitChan
+	<*> newCommitChan
+	<*> newChangePool
+	<*> newRepoProblemChan
+	<*> newBranchChangeHandle
+	<*> newRemoteControl
+	<*> newCredPairCache
+
+runAssistant :: AssistantData -> Assistant a -> IO a
+runAssistant d a = runReaderT (mkAssistant a) d
+
+getAssistant :: (AssistantData -> a) -> Assistant a
+getAssistant = reader
+
+{- Using a type class for lifting into the annex monad allows
+ - easily lifting to it from multiple different monads. -}
+class LiftAnnex m where
+	liftAnnex :: Annex a -> m a
+
+{- Runs an action in the git-annex monad. Note that the same monad state
+ - is shared among all assistant threads, so only one of these can run at
+ - a time. Therefore, long-duration actions should be avoided. -}
+instance LiftAnnex Assistant where
+	liftAnnex a = do
+		st <- reader threadState
+		liftIO $ runThreadState st a
+
+{- Runs an IO action, passing it an IO action that runs an Assistant action. -}
+(<~>) :: (IO a -> IO b) -> Assistant a -> Assistant b
+io <~> a = do
+	d <- reader id
+	liftIO $ io $ runAssistant d a
+
+{- Creates an IO action that will run an Assistant action when run. -}
+asIO :: Assistant a -> Assistant (IO a)
+asIO a = do
+	d <- reader id
+	return $ runAssistant d a
+
+asIO1 :: (a -> Assistant b) -> Assistant (a -> IO b)
+asIO1 a = do
+	d <- reader id
+	return $ \v -> runAssistant d $ a v
+
+asIO2 :: (a -> b -> Assistant c) -> Assistant (a -> b -> IO c)
+asIO2 a = do
+	d <- reader id
+	return $ \v1 v2 -> runAssistant d (a v1 v2)
+
+{- Runs an IO action on a selected field of the AssistantData. -}
+(<<~) :: (a -> IO b) -> (AssistantData -> a) -> Assistant b
+io <<~ v = reader v >>= liftIO . io
+
+debug :: [String] -> Assistant ()
+debug ws = do
+	ThreadName name <- getAssistant threadName
+	liftIO $ Debug.debug (Debug.DebugSource (encodeBS name)) (unwords ws)
diff --git a/Assistant/NamedThread.hs b/Assistant/NamedThread.hs
new file mode 100644
index 0000000000..7abe274d58
--- /dev/null
+++ b/Assistant/NamedThread.hs
@@ -0,0 +1,99 @@
+{- git-annex assistant named threads.
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Assistant.NamedThread where
+
+import Annex.Common
+import Assistant.Types.NamedThread
+import Assistant.Types.ThreadName
+import Assistant.Types.DaemonStatus
+import Assistant.Types.UrlRenderer
+import Assistant.DaemonStatus
+import Assistant.Monad
+import Utility.NotificationBroadcaster
+
+import Control.Concurrent
+import Control.Concurrent.Async
+import qualified Data.Map.Strict as M
+import qualified Control.Exception as E
+
+#ifdef WITH_WEBAPP
+import Assistant.WebApp.Types
+import Assistant.Types.Alert
+import Assistant.Alert
+import qualified Data.Text as T
+#endif
+
+{- Starts a named thread, if it's not already running.
+ -
+ - Named threads are run by a management thread, so if they crash
+ - an alert is displayed, allowing the thread to be restarted. -}
+startNamedThread :: UrlRenderer -> NamedThread -> Assistant ()
+startNamedThread urlrenderer (NamedThread afterstartupsanitycheck name a) =
+	M.lookup name . startedThreads <$> getDaemonStatus >>= \case
+		Nothing -> start
+		Just (aid, _) -> do
+			r <- liftIO (E.try (poll aid) :: IO (Either E.SomeException (Maybe (Either E.SomeException ()))))
+			case r of
+				Right Nothing -> noop
+				_ -> start
+  where
+	start
+		| afterstartupsanitycheck = do
+			status <- getDaemonStatus
+			h <- liftIO $ newNotificationHandle False $
+				startupSanityCheckNotifier status
+			startwith $ runmanaged $
+				liftIO $ waitNotification h
+		| otherwise = startwith $ runmanaged noop
+	startwith runner = do
+		d <- getAssistant id
+		aid <- liftIO $ runner $ d { threadName = name }
+		restart <- asIO $ startNamedThread urlrenderer (NamedThread False name a)
+		modifyDaemonStatus_ $ \s -> s
+			{ startedThreads = M.insert name (aid, restart) (startedThreads s) }
+	runmanaged first d = do
+		aid <- async $ runAssistant d $ do
+			void first
+			a
+		void $ forkIO $ manager d aid
+		return aid
+	manager d aid = (E.try (wait aid) :: IO (Either E.SomeException ())) >>= \case
+		Right _ -> noop
+		Left e -> do
+			let msg = unwords
+				[ fromThreadName $ threadName d
+				, "crashed:", show e
+				]
+			hPutStrLn stderr msg
+#ifdef WITH_WEBAPP
+			button <- runAssistant d $ mkAlertButton True
+				(T.pack "Restart Thread")
+				urlrenderer 
+				(RestartThreadR name)
+			runAssistant d $ void $ addAlert $
+				(warningAlert (fromThreadName name) msg)
+					{ alertButtons = [button] }
+#endif
+
+namedThreadId :: NamedThread -> Assistant (Maybe ThreadId)
+namedThreadId (NamedThread _ name _) = do
+	m <- startedThreads <$> getDaemonStatus
+	return $ asyncThreadId . fst <$> M.lookup name m
+
+{- Waits for all named threads that have been started to finish.
+ -
+ - Note that if a named thread crashes, it will probably
+ - cause this to crash as well. Also, named threads that are started
+ - after this is called will not be waited on. -}
+waitNamedThreads :: Assistant ()
+waitNamedThreads = do
+	m <- startedThreads <$> getDaemonStatus
+	liftIO $ mapM_ (wait . fst) $ M.elems m
+
diff --git a/Assistant/Pairing.hs b/Assistant/Pairing.hs
new file mode 100644
index 0000000000..aa700f5998
--- /dev/null
+++ b/Assistant/Pairing.hs
@@ -0,0 +1,97 @@
+{- git-annex assistant repo pairing, core data types
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Pairing where
+
+import Annex.Common
+import Utility.Verifiable
+import Assistant.Ssh
+
+import Control.Concurrent
+import Network.Socket
+import Data.Char
+import qualified Data.Text as T
+
+data PairStage
+	{- "I'll pair with anybody who shares the secret that can be used
+	 - to verify this request." -}
+	 = PairReq
+	{- "I've verified your request, and you can verify this to see
+	 - that I know the secret. I set up your ssh key already.
+	 - Here's mine for you to set up." -}
+	| PairAck
+	{- "I saw your PairAck; you can stop sending them." -}
+	| PairDone
+	deriving (Eq, Read, Show, Ord, Enum)
+
+newtype PairMsg = PairMsg (Verifiable (PairStage, PairData, SomeAddr))
+	deriving (Eq, Read, Show)
+
+verifiedPairMsg :: PairMsg -> PairingInProgress -> Bool
+verifiedPairMsg (PairMsg m) pip = verify m $ inProgressSecret pip
+
+fromPairMsg :: PairMsg -> Verifiable (PairStage, PairData, SomeAddr)
+fromPairMsg (PairMsg m) = m
+
+pairMsgStage :: PairMsg -> PairStage
+pairMsgStage (PairMsg (Verifiable (s, _, _) _)) = s
+
+pairMsgData :: PairMsg -> PairData
+pairMsgData (PairMsg (Verifiable (_, d, _) _)) = d
+
+pairMsgAddr :: PairMsg -> SomeAddr
+pairMsgAddr (PairMsg (Verifiable (_, _, a) _)) = a
+
+data PairData = PairData
+	-- uname -n output, not a full domain name
+	{ remoteHostName :: Maybe HostName
+	, remoteUserName :: UserName
+	, remoteDirectory :: FilePath
+	, remoteSshPubKey :: SshPubKey
+	, pairUUID :: UUID
+	}
+	deriving (Eq, Read, Show)
+
+checkSane :: PairData -> Bool
+checkSane p = all (not . any isControl)
+	[ fromMaybe "" (remoteHostName p)
+	, remoteUserName p
+	, remoteDirectory p
+	, remoteSshPubKey p
+	, fromUUID (pairUUID p)
+	]
+
+type UserName = String
+
+{- A pairing that is in progress has a secret, a thread that is
+ - broadcasting pairing messages, and a SshKeyPair that has not yet been
+ - set up on disk. -}
+data PairingInProgress = PairingInProgress
+	{ inProgressSecret :: Secret
+	, inProgressThreadId :: Maybe ThreadId
+	, inProgressSshKeyPair :: SshKeyPair
+	, inProgressPairData :: PairData
+	, inProgressPairStage :: PairStage
+	}
+	deriving (Show)
+
+data AddrClass = IPv4AddrClass | IPv6AddrClass
+
+data SomeAddr = IPv4Addr HostAddress
+	| IPv6Addr HostAddress6
+	deriving (Ord, Eq, Read, Show)
+
+{- This contains the whole secret, just lightly obfuscated to make it not
+ - too obvious. It's only displayed in the user's web browser. -}
+newtype SecretReminder = SecretReminder [Int]
+	deriving (Show, Eq, Ord, Read)
+
+toSecretReminder :: T.Text -> SecretReminder
+toSecretReminder = SecretReminder . map ord . T.unpack
+
+fromSecretReminder :: SecretReminder -> T.Text
+fromSecretReminder (SecretReminder s) = T.pack $ map chr s
diff --git a/Assistant/Pairing/MakeRemote.hs b/Assistant/Pairing/MakeRemote.hs
new file mode 100644
index 0000000000..69402e2e3d
--- /dev/null
+++ b/Assistant/Pairing/MakeRemote.hs
@@ -0,0 +1,98 @@
+{- git-annex assistant pairing remote creation
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Pairing.MakeRemote where
+
+import Assistant.Common
+import Assistant.Ssh
+import Assistant.Pairing
+import Assistant.Pairing.Network
+import Assistant.MakeRemote
+import Assistant.Sync
+import Config.Cost
+import Config
+import qualified Types.Remote as Remote
+
+import Network.Socket
+import qualified Data.Text as T
+
+{- Authorized keys are set up before pairing is complete, so that the other
+ - side can immediately begin syncing. -}
+setupAuthorizedKeys :: PairMsg -> FilePath -> IO ()
+setupAuthorizedKeys msg repodir = case validateSshPubKey $ remoteSshPubKey $ pairMsgData msg of
+	Left err -> giveup err
+	Right pubkey -> do
+		absdir <- fromRawFilePath <$> absPath (toRawFilePath repodir)
+		unlessM (liftIO $ addAuthorizedKeys True absdir pubkey) $
+			giveup "failed setting up ssh authorized keys"
+
+{- When local pairing is complete, this is used to set up the remote for
+ - the host we paired with. -}
+finishedLocalPairing :: PairMsg -> SshKeyPair -> Assistant ()
+finishedLocalPairing msg keypair = do
+	sshdata <- liftIO $ installSshKeyPair keypair =<< pairMsgToSshData msg
+	{- Ensure that we know the ssh host key for the host we paired with.
+	 - If we don't, ssh over to get it. -}
+	liftIO $ unlessM (knownHost $ sshHostName sshdata) $
+		void $ sshTranscript
+			[ sshOpt "StrictHostKeyChecking" "no"
+			, sshOpt "NumberOfPasswordPrompts" "0"
+			, "-n"
+			]
+			(genSshHost (sshHostName sshdata) (sshUserName sshdata))
+			("git-annex-shell -c configlist " ++ T.unpack (sshDirectory sshdata))
+			Nothing
+	r <- liftAnnex $ addRemote $ makeSshRemote sshdata
+	repo <- liftAnnex $ Remote.getRepo r
+	liftAnnex $ setRemoteCost repo semiExpensiveRemoteCost
+	syncRemote r
+
+{- Mostly a straightforward conversion.  Except:
+ -  * Determine the best hostname to use to contact the host.
+ -  * Strip leading ~/ from the directory name.
+ -}
+pairMsgToSshData :: PairMsg -> IO SshData
+pairMsgToSshData msg = do
+	let d = pairMsgData msg
+	hostname <- liftIO $ bestHostName msg
+	let dir = case remoteDirectory d of
+		('~':'/':v) -> v
+		v -> v
+	return SshData
+		{ sshHostName = T.pack hostname
+		, sshUserName = Just (T.pack $ remoteUserName d)
+		, sshDirectory = T.pack dir
+		, sshRepoName = genSshRepoName hostname dir
+		, sshPort = 22
+		, needsPubKey = True
+		, sshCapabilities = [GitAnnexShellCapable, GitCapable, RsyncCapable]
+		, sshRepoUrl = Nothing
+		}
+
+{- Finds the best hostname to use for the host that sent the PairMsg.
+ -
+ - If remoteHostName is set, tries to use a .local address based on it.
+ - That's the most robust, if this system supports .local.
+ - Otherwise, looks up the hostname in the DNS for the remoteAddress,
+ - if any. May fall back to remoteAddress if there's no DNS. Ugh. -}
+bestHostName :: PairMsg -> IO HostName
+bestHostName msg = case remoteHostName $ pairMsgData msg of
+	Just h -> do
+		let localname = h ++ ".local"
+		addrs <- catchDefaultIO [] $
+			getAddrInfo Nothing (Just localname) Nothing
+		maybe fallback (const $ return localname) (headMaybe addrs)
+	Nothing -> fallback
+  where
+	fallback = do
+		let a = pairMsgAddr msg
+		let sockaddr = case a of
+			IPv4Addr addr -> SockAddrInet (fromInteger 0) addr
+			IPv6Addr addr -> SockAddrInet6 (fromInteger 0) 0 addr 0
+		fromMaybe (showAddr a)
+			<$> catchDefaultIO Nothing
+				(fst <$> getNameInfo [] True False sockaddr)
diff --git a/Assistant/Pairing/Network.hs b/Assistant/Pairing/Network.hs
new file mode 100644
index 0000000000..62a4ea02e8
--- /dev/null
+++ b/Assistant/Pairing/Network.hs
@@ -0,0 +1,132 @@
+{- git-annex assistant pairing network code
+ -
+ - All network traffic is sent over multicast UDP. For reliability,
+ - each message is repeated until acknowledged. This is done using a
+ - thread, that gets stopped before the next message is sent.
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Pairing.Network where
+
+import Assistant.Common
+import Assistant.Pairing
+import Assistant.DaemonStatus
+import Utility.ThreadScheduler
+import Utility.Verifiable
+
+import Network.Multicast
+import Network.Info
+import Network.Socket
+import qualified Network.Socket.ByteString as B
+import qualified Data.ByteString.UTF8 as BU8
+import qualified Data.Map as M
+import Control.Concurrent
+
+{- This is an arbitrary port in the dynamic port range, that could
+ - conceivably be used for some other broadcast messages.
+ - If so, hope they ignore the garbage from us; we'll certainly
+ - ignore garbage from them. Wild wild west. -}
+pairingPort :: PortNumber
+pairingPort = 55556
+
+{- Goal: Reach all hosts on the same network segment.
+ - Method: Use same address that avahi uses. Other broadcast addresses seem
+ - to not be let through some routers. -}
+multicastAddress :: AddrClass -> HostName
+multicastAddress IPv4AddrClass = "224.0.0.251"
+multicastAddress IPv6AddrClass = "ff02::fb"
+
+{- Multicasts a message repeatedly on all interfaces, with a 2 second
+ - delay between each transmission. The message is repeated forever
+ - unless a number of repeats is specified.
+ -
+ - The remoteHostAddress is set to the interface's IP address.
+ -
+ - Note that new sockets are opened each time. This is hardly efficient,
+ - but it allows new network interfaces to be used as they come up.
+ - On the other hand, the expensive DNS lookups are cached.
+ -}
+multicastPairMsg :: Maybe Int -> Secret -> PairData -> PairStage -> IO ()
+multicastPairMsg repeats secret pairdata stage = go M.empty repeats
+  where
+	go _ (Just 0) = noop
+	go cache n = do
+		addrs <- activeNetworkAddresses
+		let cache' = updatecache cache addrs
+		mapM_ (sendinterface cache') addrs
+		threadDelaySeconds (Seconds 2)
+		go cache' $ pred <$> n
+	{- The multicast library currently chokes on ipv6 addresses. -}
+	sendinterface _ (IPv6Addr _) = noop
+	sendinterface cache i = void $ tryIO $
+		withSocketsDo $ bracket setup cleanup use
+	  where
+		setup = multicastSender (multicastAddress IPv4AddrClass) pairingPort
+		cleanup (sock, _) = close sock -- FIXME does not work
+		use (sock, addr) = do
+			setInterface sock (showAddr i)
+			maybe noop
+				(\s -> void $ B.sendTo sock (BU8.fromString s) addr)
+				(M.lookup i cache)
+	updatecache cache [] = cache
+	updatecache cache (i:is)
+		| M.member i cache = updatecache cache is
+		| otherwise = updatecache (M.insert i (show $ mkmsg i) cache) is
+	mkmsg addr = PairMsg $
+		mkVerifiable (stage, pairdata, addr) secret
+
+startSending :: PairingInProgress -> PairStage -> (PairStage -> IO ()) -> Assistant ()
+startSending pip stage sender = do
+	a <- asIO start
+	void $ liftIO $ forkIO a
+  where
+	start = do
+		tid <- liftIO myThreadId
+		let pip' = pip { inProgressPairStage = stage, inProgressThreadId = Just tid }
+		oldpip <- modifyDaemonStatus $
+			\s -> (s { pairingInProgress = Just pip' }, pairingInProgress s)
+		maybe noop stopold oldpip
+		liftIO $ sender stage
+	stopold = maybe noop (liftIO . killThread) . inProgressThreadId
+
+stopSending :: PairingInProgress -> Assistant ()
+stopSending pip = do
+	maybe noop (liftIO . killThread) $ inProgressThreadId pip
+	modifyDaemonStatus_ $ \s -> s { pairingInProgress = Nothing }
+
+class ToSomeAddr a where
+	toSomeAddr :: a -> SomeAddr
+
+instance ToSomeAddr IPv4 where
+	toSomeAddr (IPv4 a) = IPv4Addr a
+
+instance ToSomeAddr IPv6 where
+	toSomeAddr (IPv6 o1 o2 o3 o4) = IPv6Addr (o1, o2, o3, o4)
+
+showAddr :: SomeAddr -> HostName
+showAddr (IPv4Addr a) = show $ IPv4 a
+showAddr (IPv6Addr (o1, o2, o3, o4)) = show $ IPv6 o1 o2 o3 o4
+
+activeNetworkAddresses :: IO [SomeAddr]
+activeNetworkAddresses = filter (not . all (`elem` "0.:") . showAddr)
+	. concatMap (\ni -> [toSomeAddr $ ipv4 ni, toSomeAddr $ ipv6 ni])
+	<$> getNetworkInterfaces
+
+{- A human-visible description of the repository being paired with.
+ - Note that the repository's description is not shown to the user, because
+ - it could be something like "my repo", which is confusing when pairing
+ - with someone else's repo. However, this has the same format as the
+ - default description of a repo. -}
+pairRepo :: PairMsg -> String
+pairRepo msg = concat
+	[ remoteUserName d
+	, "@"
+	, fromMaybe (showAddr $ pairMsgAddr msg) (remoteHostName d)
+	, ":"
+	, remoteDirectory d
+	]
+  where
+	d = pairMsgData msg
diff --git a/Assistant/Pushes.hs b/Assistant/Pushes.hs
new file mode 100644
index 0000000000..f1fccb5d66
--- /dev/null
+++ b/Assistant/Pushes.hs
@@ -0,0 +1,37 @@
+{- git-annex assistant push tracking
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Pushes where
+
+import Assistant.Common
+import Assistant.Types.Pushes
+
+import Control.Concurrent.STM
+import Data.Time.Clock
+import qualified Data.Map as M
+
+{- Blocks until there are failed pushes.
+ - Returns Remotes whose pushes failed a given time duration or more ago.
+ - (This may be an empty list.) -}
+getFailedPushesBefore :: NominalDiffTime -> FailedPushMap -> Assistant [Remote]
+getFailedPushesBefore duration v = liftIO $ do
+	m <- atomically $ readTMVar v
+	now <- getCurrentTime
+	return $ M.keys $ M.filter (not . toorecent now) m
+  where
+	toorecent now time = now `diffUTCTime` time < duration
+
+{- Modifies the map. -}
+changeFailedPushMap :: FailedPushMap -> (PushMap -> PushMap) -> Assistant ()
+changeFailedPushMap v f = liftIO $ atomically $
+	store . f . fromMaybe M.empty =<< tryTakeTMVar v
+  where
+	{- tryTakeTMVar empties the TMVar; refill it only if
+	 - the modified map is not itself empty -}
+	store m
+		| m == M.empty = noop
+		| otherwise = putTMVar v $! m
diff --git a/Assistant/RemoteControl.hs b/Assistant/RemoteControl.hs
new file mode 100644
index 0000000000..d61b3e16d3
--- /dev/null
+++ b/Assistant/RemoteControl.hs
@@ -0,0 +1,21 @@
+{- git-annex assistant RemoteDaemon control
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.RemoteControl (
+	sendRemoteControl,
+	RemoteDaemon.Consumed(..)
+) where
+
+import Assistant.Common
+import qualified RemoteDaemon.Types as RemoteDaemon
+
+import Control.Concurrent
+
+sendRemoteControl :: RemoteDaemon.Consumed -> Assistant ()
+sendRemoteControl msg = do
+	clicker <- getAssistant remoteControl
+	liftIO $ writeChan clicker msg
diff --git a/Assistant/Repair.hs b/Assistant/Repair.hs
new file mode 100644
index 0000000000..02ebab3cae
--- /dev/null
+++ b/Assistant/Repair.hs
@@ -0,0 +1,162 @@
+{- git-annex assistant repository repair
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Assistant.Repair where
+
+import Assistant.Common
+import Command.Repair (repairAnnexBranch, trackingOrSyncBranch)
+import Git.Fsck (FsckResults, foundBroken)
+import Git.Repair (runRepairOf)
+import qualified Git
+import qualified Remote
+import qualified Types.Remote as Remote
+import Logs.FsckResults
+import Annex.UUID
+import Utility.Batch
+import Annex.Path
+import Assistant.Sync
+import Assistant.Alert
+import Assistant.DaemonStatus
+import Assistant.Types.UrlRenderer
+#ifdef WITH_WEBAPP
+import Assistant.WebApp.Types
+import qualified Data.Text as T
+#endif
+import qualified Utility.Lsof as Lsof
+import Utility.ThreadScheduler
+import qualified Utility.RawFilePath as R
+
+import Control.Concurrent.Async
+
+{- When the FsckResults require a repair, tries to do a non-destructive
+ - repair. If that fails, pops up an alert. -}
+repairWhenNecessary :: UrlRenderer -> UUID -> Maybe Remote -> FsckResults -> Assistant Bool
+repairWhenNecessary urlrenderer u mrmt fsckresults
+	| foundBroken fsckresults = do
+		liftAnnex $ writeFsckResults u fsckresults
+		repodesc <- liftAnnex $ Remote.prettyUUID u
+		ok <- alertWhile (repairingAlert repodesc)
+			(runRepair u mrmt False)
+#ifdef WITH_WEBAPP
+		unless ok $ do
+			button <- mkAlertButton True (T.pack "Click Here") urlrenderer $
+				RepairRepositoryR u
+			void $ addAlert $ brokenRepositoryAlert [button]
+#endif
+		return ok
+	| otherwise = return False
+
+runRepair :: UUID -> Maybe Remote -> Bool -> Assistant Bool
+runRepair u mrmt destructiverepair = do
+	fsckresults <- liftAnnex $ readFsckResults u
+	myu <- liftAnnex getUUID
+	ok <- if u == myu
+		then localrepair fsckresults
+		else remoterepair fsckresults
+	liftAnnex $ clearFsckResults u
+	debug [ "Repaired", show u, show ok ]
+
+	return ok
+  where
+	localrepair fsckresults = do
+		-- Stop the watcher from running while running repairs.
+		changeSyncable Nothing False
+
+		-- This intentionally runs the repair inside the Annex
+		-- monad, which is not strictly necessary, but keeps
+		-- other threads that might be trying to use the Annex
+		-- from running until it completes.
+		ok <- liftAnnex $ repair fsckresults Nothing
+
+		-- Run a background fast fsck if a destructive repair had
+		-- to be done, to ensure that the git-annex branch
+		-- reflects the current state of the repo.
+		when destructiverepair $
+			backgroundfsck [ Param "--fast" ]
+
+		-- Start the watcher running again. This also triggers it to
+		-- do a startup scan, which is especially important if the
+		-- git repo repair removed files from the index file. Those
+		-- files will be seen as new, and re-added to the repository.
+		when (ok || destructiverepair) $
+			changeSyncable Nothing True
+
+		return ok
+
+	remoterepair fsckresults = case Remote.repairRepo =<< mrmt of
+		Nothing -> return False
+		Just mkrepair -> do
+			thisrepopath <- liftIO . absPath
+				=<< liftAnnex (fromRepo Git.repoPath)
+			a <- liftAnnex $ mkrepair $
+				repair fsckresults (Just (fromRawFilePath thisrepopath))
+			liftIO $ catchBoolIO a
+
+	repair fsckresults referencerepo = do
+		(ok, modifiedbranches) <- inRepo $
+			runRepairOf fsckresults trackingOrSyncBranch destructiverepair referencerepo
+		when destructiverepair $
+			repairAnnexBranch modifiedbranches
+		return ok
+	
+	backgroundfsck params = liftIO $ void $ async $ do
+		program <- programPath
+		batchCommand program (Param "fsck" : params)
+
+{- Detect when a git lock file exists and has no git process currently
+ - writing to it. This strongly suggests it is a stale lock file.
+ -
+ - However, this could be on a network filesystem. Which is not very safe
+ - anyway (the assistant relies on being able to check when files have
+ - no writers to know when to commit them). Also, a few lock-file-ish
+ - things used by git are not kept open, particularly MERGE_HEAD.
+ -
+ - So, just in case, when the lock file appears stale, we delay for one
+ - minute, and check its size. If the size changed, delay for another
+ - minute, and so on. This will at work to detect when another machine
+ - is writing out a new index file, since git does so by writing the
+ - new content to index.lock.
+ -
+ - Returns true if locks were cleaned up.
+ -}
+repairStaleGitLocks :: Git.Repo -> Assistant Bool
+repairStaleGitLocks r = do
+	lockfiles <- liftIO $ filter islock
+		<$> emptyWhenDoesNotExist (findgitfiles r)
+	repairStaleLocks lockfiles
+	return $ not $ null lockfiles
+  where
+	findgitfiles = dirContentsRecursiveSkipping (== dropTrailingPathSeparator (fromRawFilePath annexDir)) True . fromRawFilePath . Git.localGitDir
+	islock f
+		| "gc.pid" `isInfixOf` f = False
+		| ".lock" `isSuffixOf` f = True
+		| takeFileName f == "MERGE_HEAD" = True
+		| otherwise = False
+
+repairStaleLocks :: [FilePath] -> Assistant ()
+repairStaleLocks lockfiles = go =<< getsizes
+  where
+	getsize lf = catchMaybeIO $ (\s -> (lf, s))
+		<$> getFileSize (toRawFilePath lf)
+	getsizes = liftIO $ catMaybes <$> mapM getsize lockfiles
+	go [] = return ()
+	go l = ifM (liftIO $ null <$> Lsof.query ("--" : map fst l))
+		( do
+			waitforit "to check stale git lock file"
+			l' <- getsizes
+			if l' == l
+				then liftIO $ mapM_ (removeWhenExistsWith R.removeLink . toRawFilePath . fst) l
+				else go l'
+		, do
+			waitforit "for git lock file writer"
+			go =<< getsizes
+		)
+	waitforit why = do
+		debug ["Waiting for 60 seconds", why]
+		liftIO $ threadDelaySeconds $ Seconds 60
diff --git a/Assistant/RepoProblem.hs b/Assistant/RepoProblem.hs
new file mode 100644
index 0000000000..cf7318b7e6
--- /dev/null
+++ b/Assistant/RepoProblem.hs
@@ -0,0 +1,34 @@
+{- git-annex assistant remote problem handling
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.RepoProblem where
+
+import Assistant.Common
+import Assistant.Types.RepoProblem
+import Utility.TList
+
+import Control.Concurrent.STM
+
+{- Gets all repositories that have problems. Blocks until there is at
+ - least one. -}
+getRepoProblems :: Assistant [RepoProblem]
+getRepoProblems = nubBy sameRepoProblem
+	<$> (atomically . getTList) <<~ repoProblemChan
+
+{- Indicates that there was a problem with a repository, and the problem
+ - appears to not be a transient (eg network connection) problem.
+ -
+ - If the problem is able to be repaired, the passed action will be run.
+ - (However, if multiple problems are reported with a single repository,
+ - only a single action will be run.)
+ -}
+repoHasProblem :: UUID -> Assistant () -> Assistant ()
+repoHasProblem u afterrepair = do
+	rp <- RepoProblem
+		<$> pure u
+		<*> asIO afterrepair
+	(atomically . flip consTList rp) <<~ repoProblemChan
diff --git a/Assistant/Restart.hs b/Assistant/Restart.hs
new file mode 100644
index 0000000000..65b6fe64aa
--- /dev/null
+++ b/Assistant/Restart.hs
@@ -0,0 +1,119 @@
+{- git-annex assistant restarting
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Assistant.Restart where
+
+import Assistant.Common
+import Assistant.Threads.Watcher
+import Assistant.DaemonStatus
+import Assistant.NamedThread
+import Utility.ThreadScheduler
+import Utility.NotificationBroadcaster
+import Utility.Url
+import Utility.Url.Parse
+import Utility.PID
+import qualified Utility.RawFilePath as R
+import qualified Git.Construct
+import qualified Git.Config
+import qualified Annex
+import qualified Git
+import Annex.Path
+
+import Control.Concurrent
+#ifndef mingw32_HOST_OS
+import System.Posix (signalProcess, sigTERM)
+#else
+import System.Win32.Process (terminateProcessById)
+#endif
+import Network.URI
+
+{- Before the assistant can be restarted, have to remove our 
+ - gitAnnexUrlFile and our gitAnnexPidFile. Pausing the watcher is also
+ - a good idea, to avoid fighting when two assistants are running in the
+ - same repo.
+ -}
+prepRestart :: Assistant ()
+prepRestart = do
+	liftIO . maybe noop (`throwTo` PauseWatcher) =<< namedThreadId watchThread
+	liftIO . removeWhenExistsWith R.removeLink =<< liftAnnex (fromRepo gitAnnexUrlFile)
+	liftIO . removeWhenExistsWith R.removeLink =<< liftAnnex (fromRepo gitAnnexPidFile)
+
+{- To finish a restart, send a global redirect to the new url
+ - to any web browsers that are displaying the webapp.
+ -
+ - Wait for browser to update before terminating this process. -}
+postRestart :: URLString -> Assistant ()
+postRestart url = do
+	modifyDaemonStatus_ $ \status -> status { globalRedirUrl = Just url }
+	liftIO . sendNotification . globalRedirNotifier =<< getDaemonStatus
+	void $ liftIO $ forkIO $ do
+		threadDelaySeconds (Seconds 120)
+		terminateSelf
+
+terminateSelf :: IO ()
+terminateSelf =
+#ifndef mingw32_HOST_OS
+		signalProcess sigTERM =<< getPID
+#else
+		terminateProcessById =<< getPID
+#endif
+
+runRestart :: Assistant URLString
+runRestart = liftIO . newAssistantUrl
+	=<< liftAnnex (Git.repoLocation <$> Annex.gitRepo)
+
+{- Starts up the assistant in the repository, and waits for it to create
+ - a gitAnnexUrlFile. Waits for the assistant to be up and listening for
+ - connections by testing the url. -}
+newAssistantUrl :: FilePath -> IO URLString
+newAssistantUrl repo = do
+	startAssistant repo
+	geturl
+  where
+	geturl = do
+		r <- Git.Config.read =<< Git.Construct.fromPath (toRawFilePath repo)
+		waiturl $ fromRawFilePath $ gitAnnexUrlFile r
+	waiturl urlfile = do
+		v <- tryIO $ readFile urlfile
+		case v of
+			Left _ -> delayed $ waiturl urlfile
+			Right url -> ifM (assistantListening url)
+				( return url
+				, delayed $ waiturl urlfile
+				)
+	delayed a = do
+		threadDelay 100000 -- 1/10th of a second
+		a
+
+{- Checks if the assistant is listening on an url.
+ -
+ - Always checks http, because https with self-signed cert is problematic.
+ - warp-tls listens to http, in order to show an error page, so this works.
+ -}
+assistantListening :: URLString -> IO Bool
+assistantListening url = catchBoolIO $ do
+	uo <- defUrlOptions
+	(== Right True) <$> exists url' uo
+  where
+	url' = case parseURIPortable url of
+		Nothing -> url
+		Just uri -> show $ uri
+			{ uriScheme = "http:"
+			}
+
+{- Does not wait for assistant to be listening for web connections. 
+ -
+ - On windows, the assistant does not daemonize, which is why the forkIO is
+ - done.
+ -}
+startAssistant :: FilePath -> IO ()
+startAssistant repo = void $ forkIO $ do
+	program <- programPath
+	let p = (proc program ["assistant"]) { cwd = Just repo }
+	withCreateProcess p $ \_ _ _ pid -> void $ checkSuccessProcess pid
diff --git a/Assistant/ScanRemotes.hs b/Assistant/ScanRemotes.hs
new file mode 100644
index 0000000000..7cecc62cd6
--- /dev/null
+++ b/Assistant/ScanRemotes.hs
@@ -0,0 +1,41 @@
+{- git-annex assistant remotes needing scanning
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.ScanRemotes where
+
+import Assistant.Common
+import Assistant.Types.ScanRemotes
+import qualified Types.Remote as Remote
+
+import Data.Function
+import Control.Concurrent.STM
+import qualified Data.Map as M
+
+{- Blocks until there is a remote or remotes that need to be scanned.
+ -
+ - The list has higher priority remotes listed first. -}
+getScanRemote :: Assistant [(Remote, ScanInfo)]
+getScanRemote = do
+	v <- getAssistant scanRemoteMap
+	liftIO $ atomically $
+		reverse . sortBy (compare `on` scanPriority . snd) . M.toList
+			<$> takeTMVar v
+
+{- Adds new remotes that need scanning. -}
+addScanRemotes :: Bool -> [Remote] -> Assistant ()
+addScanRemotes _ [] = noop
+addScanRemotes full rs = do
+	v <- getAssistant scanRemoteMap
+	liftIO $ atomically $ do
+		m <- fromMaybe M.empty <$> tryTakeTMVar v
+		putTMVar v $ M.unionWith merge (M.fromList $ zip rs (map info rs)) m
+  where
+	info r = ScanInfo (-1 * Remote.cost r) full
+	merge x y = ScanInfo
+		{ scanPriority = max (scanPriority x) (scanPriority y)
+		, fullScan = fullScan x || fullScan y 
+		}
diff --git a/Assistant/Ssh.hs b/Assistant/Ssh.hs
new file mode 100644
index 0000000000..3f472a5332
--- /dev/null
+++ b/Assistant/Ssh.hs
@@ -0,0 +1,412 @@
+{- git-annex assistant ssh utilities
+ -
+ - Copyright 2012-2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Ssh where
+
+import Annex.Common
+import Utility.Tmp
+import Utility.Tmp.Dir
+import Utility.Shell
+import Utility.Rsync
+import Utility.FileMode
+import Utility.SshConfig
+import Git.Remote
+import Utility.SshHost
+import Utility.Process.Transcript
+
+import Data.Text (Text)
+import qualified Data.Text as T
+import Data.Char
+import Network.URI
+
+data SshData = SshData
+	{ sshHostName :: Text
+	, sshUserName :: Maybe Text
+	, sshDirectory :: Text
+	, sshRepoName :: String
+	, sshPort :: Int
+	, needsPubKey :: Bool
+	, sshCapabilities :: [SshServerCapability]
+	, sshRepoUrl :: Maybe String
+	}
+	deriving (Read, Show, Eq)
+
+data SshServerCapability
+	= GitAnnexShellCapable -- server has git-annex-shell installed
+	| GitCapable -- server has git installed
+	| RsyncCapable -- server supports raw rsync access (not only via git-annex-shell)
+	| PushCapable -- repo on server is set up already, and ready to accept pushes
+	deriving (Read, Show, Eq)
+
+hasCapability :: SshData -> SshServerCapability -> Bool
+hasCapability d c = c `elem` sshCapabilities d
+
+addCapability :: SshData -> SshServerCapability -> SshData
+addCapability d c = d { sshCapabilities = c : sshCapabilities d }
+
+onlyCapability :: SshData -> SshServerCapability -> Bool
+onlyCapability d c = all (== c) (sshCapabilities d)
+
+type SshPubKey = String
+type SshPrivKey = String
+
+data SshKeyPair = SshKeyPair
+	{ sshPubKey :: SshPubKey
+	, sshPrivKey :: SshPrivKey
+	}
+
+instance Show SshKeyPair where
+	show = sshPubKey
+
+{- ssh -ofoo=bar command-line option -}
+sshOpt :: String -> String -> String
+sshOpt k v = concat ["-o", k, "=", v]
+
+{- user@host or host -}
+genSshHost :: Text -> Maybe Text -> SshHost
+genSshHost host user = either giveup id $ mkSshHost $
+	maybe "" (\v -> T.unpack v ++ "@") user ++ T.unpack host
+
+{- Generates a ssh or rsync url from a SshData. -}
+genSshUrl :: SshData -> String
+genSshUrl sshdata = case sshRepoUrl sshdata of
+	Just repourl -> repourl
+	Nothing -> addtrailingslash $ T.unpack $ T.concat $
+		if (onlyCapability sshdata RsyncCapable)
+			then [u, h, T.pack ":", sshDirectory sshdata]
+			else [T.pack "ssh://", u, h, d]
+  where
+	u = maybe (T.pack "") (\v -> T.concat [v, T.pack "@"]) $ sshUserName sshdata
+	h = sshHostName sshdata
+	d
+		| T.pack "/" `T.isPrefixOf` sshDirectory sshdata = sshDirectory sshdata
+		| T.pack "~/" `T.isPrefixOf` sshDirectory sshdata = T.concat [T.pack "/", sshDirectory sshdata]
+		| otherwise = T.concat [T.pack "/~/", sshDirectory sshdata]
+	addtrailingslash s
+		| "/" `isSuffixOf` s = s
+		| otherwise = s ++ "/"
+
+{- Reverses genSshUrl -}
+parseSshUrl :: String -> Maybe SshData
+parseSshUrl u
+	| "ssh://" `isPrefixOf` u = fromssh (drop (length "ssh://") u)
+	| otherwise = fromrsync u
+  where
+	mkdata (userhost, dir) = Just $ SshData
+		{ sshHostName = T.pack host
+		, sshUserName = if null user then Nothing else Just $ T.pack user
+		, sshDirectory = T.pack dir
+		, sshRepoName = genSshRepoName host dir
+		-- dummy values, cannot determine from url
+		, sshPort = 22
+		, needsPubKey = True
+		, sshCapabilities = []
+		, sshRepoUrl = Nothing
+		}
+	  where
+		(user, host) = if '@' `elem` userhost
+			then separate (== '@') userhost
+			else ("", userhost)
+	fromrsync s
+		| not (rsyncUrlIsShell u) = Nothing
+		| otherwise = mkdata $ separate (== ':') s
+	fromssh = mkdata . break (== '/')
+
+{- Generates a git remote name, like host_dir or host -}
+genSshRepoName :: String -> FilePath -> String
+genSshRepoName host dir
+	| null dir = makeLegalName host
+	| otherwise = makeLegalName $ host ++ "_" ++ dir
+
+{- The output of ssh, including both stdout and stderr. -}
+sshTranscript :: [String] -> SshHost -> String -> (Maybe String) -> IO (String, Bool)
+sshTranscript opts sshhost cmd input = processTranscript "ssh"
+	(opts ++ [fromSshHost sshhost, cmd]) input
+
+{- Ensure that the ssh public key doesn't include any ssh options, like
+ - command=foo, or other weirdness.
+ -
+ - The returned version of the key has its comment removed.
+ -}
+validateSshPubKey :: SshPubKey -> Either String SshPubKey
+validateSshPubKey pubkey
+	| length (lines pubkey) == 1 = check $ words pubkey
+	| otherwise = Left "too many lines in ssh public key"
+  where
+	check (prefix:key:_) = checkprefix prefix (unwords [prefix, key])
+	check _ = err "wrong number of words in ssh public key"
+
+	err msg = Left $ unwords [msg, pubkey]
+
+	checkprefix prefix validpubkey
+		| ssh == "ssh" && all isAlphaNum keytype = Right validpubkey
+		| otherwise = err "bad ssh public key prefix"
+	  where
+		(ssh, keytype) = separate (== '-') prefix
+
+addAuthorizedKeys :: Bool -> FilePath -> SshPubKey -> IO Bool
+addAuthorizedKeys gitannexshellonly dir pubkey = boolSystem "sh"
+	[ Param "-c" , Param $ addAuthorizedKeysCommand gitannexshellonly dir pubkey ]
+
+{- Should only be used within the same process that added the line;
+ - the layout of the line is not kepy stable across versions. -}
+removeAuthorizedKeys :: Bool -> FilePath -> SshPubKey -> IO ()
+removeAuthorizedKeys gitannexshellonly dir pubkey = do
+	let keyline = authorizedKeysLine gitannexshellonly dir pubkey
+	sshdir <- sshDir
+	let keyfile = sshdir </> "authorized_keys"
+	tryWhenExists (lines <$> readFileStrict keyfile) >>= \case
+		Just ls -> viaTmp writeSshConfig keyfile $
+			unlines $ filter (/= keyline) ls
+		Nothing -> noop
+
+{- Implemented as a shell command, so it can be run on remote servers over
+ - ssh.
+ -
+ - The ~/.ssh/git-annex-shell wrapper script is created if not already
+ - present.
+ -}
+addAuthorizedKeysCommand :: Bool -> FilePath -> SshPubKey -> String
+addAuthorizedKeysCommand gitannexshellonly dir pubkey = intercalate "&&"
+	[ "mkdir -p ~/.ssh"
+	, intercalate "; "
+		[ "if [ ! -e " ++ wrapper ++ " ]"
+		, "then (" ++ intercalate ";" (map echoval script) ++ ") > " ++ wrapper
+		, "fi"
+		]
+	, "chmod 700 " ++ wrapper
+	, "touch ~/.ssh/authorized_keys"
+	, "chmod 600 ~/.ssh/authorized_keys"
+	, unwords
+		[ "echo"
+		, shellEscape $ authorizedKeysLine gitannexshellonly dir pubkey
+		, ">>~/.ssh/authorized_keys"
+		]
+	]
+  where
+	echoval v = "echo " ++ shellEscape v
+	wrapper = "~/.ssh/git-annex-shell"
+	script =
+		[ shebang
+		, "set -e"
+		, "if [ \"x$SSH_ORIGINAL_COMMAND\" != \"x\" ]; then"
+		,   runshell "$SSH_ORIGINAL_COMMAND"
+		, "else"
+		,   runshell "$@"
+		, "fi"
+		]
+	runshell var = "exec git-annex-shell -c \"" ++ var ++ "\""
+
+authorizedKeysLine :: Bool -> FilePath -> SshPubKey -> String
+authorizedKeysLine gitannexshellonly dir pubkey
+	| gitannexshellonly = limitcommand ++ pubkey
+	{- TODO: Locking down rsync is difficult, requiring a rather
+	 - long perl script. -}
+	| otherwise = pubkey
+  where
+	limitcommand = "command=\"env GIT_ANNEX_SHELL_DIRECTORY="++shellEscape dir++" ~/.ssh/git-annex-shell\",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty "
+
+{- Generates a ssh key pair. -}
+genSshKeyPair :: IO SshKeyPair
+genSshKeyPair = withTmpDir "git-annex-keygen" $ \dir -> do
+	ok <- boolSystem "ssh-keygen"
+		[ Param "-P", Param "" -- no password
+		, Param "-f", File $ dir </> "key"
+		]
+	unless ok $
+		giveup "ssh-keygen failed"
+	SshKeyPair
+		<$> readFile (dir </> "key.pub")
+		<*> readFile (dir </> "key")
+
+{- Installs a ssh key pair, and sets up ssh config with a mangled hostname
+ - that will enable use of the key. This way we avoid changing the user's
+ - regular ssh experience at all. Returns a modified SshData containing the
+ - mangled hostname.
+ -
+ - Note that the key files are put in ~/.ssh/git-annex/, rather than directly
+ - in ssh because of an **INSANE** behavior of gnome-keyring: It loads
+ - ~/.ssh/ANYTHING.pub, and uses them indiscriminately. But using this key
+ - for a normal login to the server will force git-annex-shell to run,
+ - and locks the user out. Luckily, it does not recurse into subdirectories.
+ -
+ - Similarly, IdentitiesOnly is set in the ssh config to prevent the
+ - ssh-agent from forcing use of a different key.
+ -
+ - Force strict host key checking to avoid repeated prompts
+ - when git-annex and git try to access the remote, if its
+ - host key has changed.
+ -}
+installSshKeyPair :: SshKeyPair -> SshData -> IO SshData
+installSshKeyPair sshkeypair sshdata = do
+	sshdir <- sshDir
+	createDirectoryIfMissing True $ fromRawFilePath $
+		parentDir $ toRawFilePath $ sshdir </> sshPrivKeyFile sshdata
+
+	unlessM (doesFileExist $ sshdir </> sshPrivKeyFile sshdata) $
+		writeFileProtected (toRawFilePath (sshdir </> sshPrivKeyFile sshdata)) (sshPrivKey sshkeypair)
+	unlessM (doesFileExist $ sshdir </> sshPubKeyFile sshdata) $
+		writeFile (sshdir </> sshPubKeyFile sshdata) (sshPubKey sshkeypair)
+
+	setSshConfig sshdata
+		[ ("IdentityFile", "~/.ssh/" ++ sshPrivKeyFile sshdata)
+		, ("IdentitiesOnly", "yes")
+		, ("StrictHostKeyChecking", "yes")
+		]
+
+sshPrivKeyFile :: SshData -> FilePath
+sshPrivKeyFile sshdata = "git-annex" </> "key." ++ mangleSshHostName sshdata
+
+sshPubKeyFile :: SshData -> FilePath
+sshPubKeyFile sshdata = sshPrivKeyFile sshdata ++ ".pub"
+
+{- Generates an installs a new ssh key pair if one is not already
+ - installed. Returns the modified SshData that will use the key pair,
+ - and the key pair. -}
+setupSshKeyPair :: SshData -> IO (SshData, SshKeyPair)
+setupSshKeyPair sshdata = do
+	sshdir <- sshDir
+	mprivkey <- catchMaybeIO $ readFile (sshdir </> sshPrivKeyFile sshdata)
+	mpubkey <- catchMaybeIO $ readFile (sshdir </> sshPubKeyFile sshdata)
+	keypair <- case (mprivkey, mpubkey) of
+		(Just privkey, Just pubkey) -> return $ SshKeyPair
+			{ sshPubKey = pubkey
+			, sshPrivKey = privkey
+			}
+		_ -> genSshKeyPair
+	sshdata' <- installSshKeyPair keypair sshdata
+	return (sshdata', keypair)
+
+{- Fixes git-annex ssh key pairs configured in .ssh/config 
+ - by old versions to set IdentitiesOnly.
+ -
+ - Strategy: Search for IdentityFile lines with key.git-annex
+ - in their names. These are for git-annex ssh key pairs.
+ - Add the IdentitiesOnly line immediately after them, if not already
+ - present.
+ -}
+fixSshKeyPairIdentitiesOnly :: IO ()
+fixSshKeyPairIdentitiesOnly = changeUserSshConfig $ unlines . go [] . lines
+  where
+	go c [] = reverse c
+	go c (l:[])
+		| all (`isInfixOf` l) indicators = go (fixedline l:l:c) []
+		| otherwise = go (l:c) []
+	go c (l:next:rest)
+		| all (`isInfixOf` l) indicators && not ("IdentitiesOnly" `isInfixOf` next) = 
+			go (fixedline l:l:c) (next:rest)
+		| otherwise = go (l:c) (next:rest)
+	indicators = ["IdentityFile", "key.git-annex"]
+	fixedline tmpl = takeWhile isSpace tmpl ++ "IdentitiesOnly yes"
+
+{- Add StrictHostKeyChecking to any ssh config stanzas that were written
+ - by git-annex. -}
+fixUpSshRemotes :: IO ()
+fixUpSshRemotes = modifyUserSshConfig (map go)
+  where
+	go c@(HostConfig h _)
+		| "git-annex-" `isPrefixOf` h = fixupconfig c
+		| otherwise = c
+	go other = other
+
+	fixupconfig c = case findHostConfigKey c "StrictHostKeyChecking" of
+		Nothing -> addToHostConfig c "StrictHostKeyChecking" "yes"
+		Just _ -> c
+
+{- Setups up a ssh config with a mangled hostname.
+ - Returns a modified SshData containing the mangled hostname. -}
+setSshConfig :: SshData -> [(String, String)] -> IO SshData
+setSshConfig sshdata config = do
+	sshdir <- sshDir
+	createDirectoryIfMissing True sshdir
+	let configfile = sshdir </> "config"
+	unlessM (catchBoolIO $ isInfixOf mangledhost <$> readFile configfile) $ do
+		appendFile configfile $ unlines $
+			[ ""
+			, "# Added automatically by git-annex"
+			, "Host " ++ mangledhost
+			] ++ map (\(k, v) -> "\t" ++ k ++ " " ++ v)
+				(settings ++ config)
+		setSshConfigMode (toRawFilePath configfile)
+
+	return $ sshdata
+		{ sshHostName = T.pack mangledhost
+		, sshRepoUrl = replace orighost mangledhost
+			<$> sshRepoUrl sshdata
+		}
+  where
+	orighost = T.unpack $ sshHostName sshdata
+	mangledhost = mangleSshHostName sshdata
+	settings =
+		[ ("Hostname", orighost)
+		, ("Port", show $ sshPort sshdata)
+		]
+
+{- This hostname is specific to a given repository on the ssh host,
+ - so it is based on the real hostname, the username, and the directory.
+ -
+ - The mangled hostname has the form:
+ - "git-annex-realhostname-username_port_dir"
+ - Note that "-" is only used in the realhostname and as a separator;
+ - this is necessary to allow unMangleSshHostName to work.
+ -
+ - Unusual characters are url encoded, but using "." rather than "%"
+ - (the latter has special meaning to ssh).
+ -
+ - In the username and directory, unusual characters are any
+ - non-alphanumerics, other than "_"
+ -
+ - The real hostname is not normally encoded at all. This is done for
+ - backwards compatibility and to avoid unnecessary ugliness in the
+ - filename. However, when it contains special characters
+ - (notably ":" which cannot be used on some filesystems), it is url
+ - encoded. To indicate it was encoded, the mangled hostname
+ - has the form
+ - "git-annex-.encodedhostname-username_port_dir"
+ -}
+mangleSshHostName :: SshData -> String
+mangleSshHostName sshdata = intercalate "-" 
+	[ "git-annex"
+	, escapehostname (T.unpack (sshHostName sshdata))
+	, escape extra
+	]
+  where
+	extra = intercalate "_" $ map T.unpack $ catMaybes
+		[ sshUserName sshdata
+		, Just $ T.pack $ show $ sshPort sshdata
+		, Just $ sshDirectory sshdata
+		]
+	safe c
+		| isAlphaNum c = True
+		| c == '_' = True
+		| otherwise = False
+	escape s = replace "%" "." $ escapeURIString safe s
+	escapehostname s
+		| all (\c -> c == '.' || safe c) s = s
+		| otherwise = '.' : escape s
+
+{- Extracts the real hostname from a mangled ssh hostname. -}
+unMangleSshHostName :: String -> String
+unMangleSshHostName h = case splitc '-' h of
+	("git":"annex":rest) -> unescape (intercalate "-" (beginning rest))
+	_ -> h
+  where
+	unescape ('.':s) = unEscapeString (replace "." "%" s)
+	unescape s = s
+
+{- Does ssh have known_hosts data for a hostname? -}
+knownHost :: Text -> IO Bool
+knownHost hostname = do
+	sshdir <- sshDir
+	ifM (doesFileExist $ sshdir </> "known_hosts")
+		( not . null <$> checkhost
+		, return False
+		)
+  where
+	{- ssh-keygen -F can crash on some old known_hosts file -}
+	checkhost = catchDefaultIO "" $
+		readProcess "ssh-keygen" ["-F", T.unpack hostname]
diff --git a/Assistant/Sync.hs b/Assistant/Sync.hs
new file mode 100644
index 0000000000..48f805655d
--- /dev/null
+++ b/Assistant/Sync.hs
@@ -0,0 +1,287 @@
+{- git-annex assistant repo syncing
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Assistant.Sync where
+
+import Assistant.Common
+import Assistant.Pushes
+import Assistant.Alert
+import Assistant.Alert.Utility
+import Assistant.DaemonStatus
+import Assistant.ScanRemotes
+import Assistant.RemoteControl
+import qualified Command.Sync
+import qualified Git
+import qualified Git.Command
+import qualified Remote
+import qualified Types.Remote as Remote
+import qualified Annex
+import qualified Annex.Branch
+import Remote.List.Util
+import Annex.UUID
+import Annex.TaggedPush
+import Annex.Ssh
+import Annex.CurrentBranch
+import qualified Config
+import Git.Config
+import Config.DynamicConfig
+import Assistant.NamedThread
+import Assistant.Threads.Watcher (watchThread, WatcherControl(..))
+import Assistant.TransferSlots
+import Assistant.TransferQueue
+import Assistant.RepoProblem
+import Assistant.Commits
+import Types.Transfer
+import Database.Export
+
+import Data.Time.Clock
+import qualified Data.Map as M
+import Control.Concurrent
+import Control.Concurrent.Async
+
+{- Syncs with remotes that may have been disconnected for a while.
+ - 
+ - First gets git in sync, and then prepares any necessary file transfers.
+ -
+ - An expensive full scan is queued when the git-annex branches of some of
+ - the remotes have diverged from the local git-annex branch. Otherwise,
+ - it's sufficient to requeue failed transfers.
+ -
+ - Also handles signaling any connectRemoteNotifiers, after the syncing is
+ - done, and records an export commit to make any exports be updated.
+ -}
+reconnectRemotes :: [Remote] -> Assistant ()
+reconnectRemotes [] = recordExportCommit
+reconnectRemotes rs = void $ do
+	rs' <- liftAnnex $ filterM (Remote.checkAvailable True) rs
+	unless (null rs') $ do
+		failedrs <- syncAction rs' (const go)
+		forM_ failedrs $ \r ->
+			whenM (liftAnnex $ Remote.checkAvailable False r) $
+				repoHasProblem (Remote.uuid r) (syncRemote r)
+		mapM_ signal $ filter (`notElem` failedrs) rs'
+	recordExportCommit
+  where
+	gitremotes = liftAnnex $ 
+		filterM (notspecialremote <$$> Remote.getRepo) rs
+	notspecialremote r
+		| Git.repoIsUrl r = True
+		| Git.repoIsLocal r = True
+		| Git.repoIsLocalUnknown r = True
+		| otherwise = False
+	syncbranch currentbranch@(Just _, _) = do
+		(failedpull, diverged) <- manualPull currentbranch =<< gitremotes
+		now <- liftIO getCurrentTime
+		failedpush <- pushToRemotes' now =<< gitremotes
+		return (nub $ failedpull ++ failedpush, diverged)
+	{- No local branch exists yet, but we can try pulling. -}
+	syncbranch (Nothing, _) = manualPull (Nothing, Nothing) =<< gitremotes
+	go = do
+		(failed, diverged) <- syncbranch =<< liftAnnex getCurrentBranch
+		addScanRemotes diverged =<<
+			filterM (not <$$> liftIO . getDynamicConfig . remoteAnnexIgnore . Remote.gitconfig) rs
+		return failed
+	signal r = liftIO . mapM_ (flip tryPutMVar ())
+		=<< fromMaybe [] . M.lookup (Remote.uuid r) . connectRemoteNotifiers
+			<$> getDaemonStatus
+
+{- Pushes the local sync branch to all remotes, in
+ - parallel, along with the git-annex branch. This is the same
+ - as "git annex sync", except in parallel, and will co-exist with use of
+ - "git annex sync".
+ -
+ - Avoids running possibly long-duration commands in the Annex monad, so
+ - as not to block other threads.
+ -
+ - This can fail, when the remote's sync branch (or git-annex branch) has
+ - been updated by some other remote pushing into it, or by the remote
+ - itself. To handle failure, a manual pull and merge is done, and the push
+ - is retried.
+ -
+ - When there's a lot of activity, we may fail more than once.
+ - On the other hand, we may fail because the remote is not available.
+ - Rather than retrying indefinitely, after the first retry we enter a
+ - fallback mode, where our push is guaranteed to succeed if the remote is
+ - reachable. If the fallback fails, the push is queued to be retried
+ - later.
+ -
+ - Returns any remotes that it failed to push to.
+ -}
+pushToRemotes :: [Remote] -> Assistant [Remote]
+pushToRemotes remotes = do
+	now <- liftIO getCurrentTime
+	let remotes' = filter (wantpush . Remote.gitconfig) remotes
+	syncAction remotes' (pushToRemotes' now)
+  where
+	wantpush gc
+		| remoteAnnexReadOnly gc = False
+		| not (remoteAnnexPush gc) = False
+		| otherwise = True
+
+pushToRemotes' :: UTCTime -> [Remote] -> Assistant [Remote]
+pushToRemotes' now remotes = do
+	(g, branch, u, ms) <- liftAnnex $ do
+		Annex.Branch.commit =<< Annex.Branch.commitMessage
+		(,,,)
+			<$> gitRepo
+			<*> getCurrentBranch
+			<*> getUUID
+			<*> Annex.getState Annex.output
+	ret <- go ms True branch g u remotes
+	return ret
+  where
+	go _ _ (Nothing, _) _ _ _ = return [] -- no branch, so nothing to do
+	go _ _ _ _ _ [] = return [] -- no remotes, so nothing to do
+	go ms shouldretry currbranch@(Just branch, _) g u rs =  do
+		debug ["pushing to", show rs]
+		(succeeded, failed) <- parallelPush g rs (push ms branch)
+		updatemap succeeded []
+		if null failed
+			then return []
+			else if shouldretry
+				then retry ms currbranch g u failed
+				else fallback branch g u failed
+
+	updatemap succeeded failed = do
+		v <- getAssistant failedPushMap 
+		changeFailedPushMap v $ \m ->
+			M.union (makemap failed) $
+				M.difference m (makemap succeeded)
+	makemap l = M.fromList $ zip l (repeat now)
+
+	retry ms currbranch g u rs = do
+		debug ["trying manual pull to resolve failed pushes"]
+		void $ manualPull currbranch rs
+		go ms False currbranch g u rs
+
+	fallback branch g u rs = do
+		debug ["fallback pushing to", show rs]
+		(succeeded, failed) <- parallelPush g rs (taggedPush u Nothing branch)
+		updatemap succeeded failed
+		return failed
+		
+	push ms branch remote = Command.Sync.pushBranch remote (Just branch) ms
+
+parallelPush :: Git.Repo -> [Remote] -> (Remote -> Git.Repo -> IO Bool)-> Assistant ([Remote], [Remote])
+parallelPush g rs a = do
+	rgs <- liftAnnex $ mapM topush rs
+	(succeededrgs, failedrgs) <- liftIO $ inParallel (uncurry a) rgs
+	return (map fst succeededrgs, map fst failedrgs)
+  where
+	topush r = (,)
+		<$> pure r
+		<*> (Remote.getRepo r >>= \repo ->
+			sshOptionsTo repo (Remote.gitconfig r) g)
+
+inParallel :: (v -> IO Bool) -> [v] -> IO ([v], [v])
+inParallel a l = (\(t,f) -> (map fst t, map fst f)) 
+	. partition snd 
+	. zip l <$> mapConcurrently a l
+
+{- Displays an alert while running an action that syncs with some remotes,
+ - and returns any remotes that it failed to sync with.
+ -
+ - Readonly remotes are also hidden (to hide the web special remote).
+ -}
+syncAction :: [Remote] -> ([Remote] -> Assistant [Remote]) -> Assistant [Remote]
+syncAction rs a
+	| null visibleremotes = a rs
+	| otherwise = do
+		i <- addAlert $ syncAlert visibleremotes
+		failed <- a rs
+		failed' <- filterM (not . Git.repoIsLocalUnknown <$$> liftAnnex . Remote.getRepo) failed
+		let succeeded = filter (`notElem` failed) visibleremotes
+		if null succeeded && null failed'
+			then removeAlert i
+			else updateAlertMap $ mergeAlert i $
+				syncResultAlert succeeded failed'
+		return failed
+  where
+	visibleremotes = filter (not . Remote.readonly) rs
+
+{- Manually pull from remotes and merge their branches. Returns any
+ - remotes that it failed to pull from, and a Bool indicating
+ - whether the git-annex branches of the remotes and local had
+ - diverged before the pull.
+ -}
+manualPull :: Command.Sync.CurrBranch -> [Remote] -> Assistant ([Remote], Bool)
+manualPull currentbranch remotes = do
+	g <- liftAnnex gitRepo
+	-- Allow merging unrelated histories.
+	mc <- liftAnnex $ Command.Sync.mergeConfig True
+	failed <- forM remotes $ \r -> if wantpull $ Remote.gitconfig r
+		then do
+			g' <- liftAnnex $ do
+				repo <- Remote.getRepo r
+				sshOptionsTo repo (Remote.gitconfig r) g
+			ifM (liftIO $ Git.Command.runBool [Param "fetch", Param $ Remote.name r] g')
+				( return Nothing
+				, return $ Just r
+				)
+		else return Nothing
+	haddiverged <- liftAnnex Annex.Branch.forceUpdate >>= return . \case
+		u@(Annex.Branch.UpdateMade {}) -> Annex.Branch.refsWereMerged u
+		(Annex.Branch.UpdateFailedPermissions {}) -> True
+	forM_ remotes $ \r ->
+		liftAnnex $ Command.Sync.mergeRemote r
+			currentbranch mc def
+	when haddiverged $
+		updateExportTreeFromLogAll
+	return (catMaybes failed, haddiverged)
+  where
+	wantpull gc = remoteAnnexPull gc
+
+{- Start syncing a remote, using a background thread. -}
+syncRemote :: Remote -> Assistant ()
+syncRemote remote = do
+	updateSyncRemotes
+	thread <- asIO $ do
+		reconnectRemotes [remote]
+		addScanRemotes True [remote]
+	void $ liftIO $ forkIO $ thread
+
+{- Use Nothing to change autocommit setting; or a remote to change
+ - its sync setting. -}
+changeSyncable :: Maybe Remote -> Bool -> Assistant ()
+changeSyncable Nothing enable = do
+	liftAnnex $ Config.setConfig key (boolConfig enable)
+	liftIO . maybe noop (`throwTo` signal)
+		=<< namedThreadId watchThread
+  where
+	key = Config.annexConfig "autocommit"
+	signal
+		| enable = ResumeWatcher
+		| otherwise = PauseWatcher
+changeSyncable (Just r) True = do
+	liftAnnex $ changeSyncFlag r True
+	syncRemote r
+	sendRemoteControl RELOAD
+changeSyncable (Just r) False = do
+	liftAnnex $ changeSyncFlag r False
+	updateSyncRemotes
+	{- Stop all transfers to or from this remote.
+	 - XXX Can't stop any ongoing scan, or git syncs. -}
+	void $ dequeueTransfers tofrom
+	mapM_ (cancelTransfer False) =<<
+		filter tofrom . M.keys . currentTransfers <$> getDaemonStatus
+  where
+	tofrom t = transferUUID t == Remote.uuid r
+
+changeSyncFlag :: Remote -> Bool -> Annex ()
+changeSyncFlag r enabled = do
+	repo <- Remote.getRepo r
+	let key = Config.remoteAnnexConfig repo "sync"
+	Config.setConfig key (boolConfig enabled)
+	remotesChanged
+
+updateExportTreeFromLogAll :: Assistant ()
+updateExportTreeFromLogAll = do
+	rs <- exportRemotes <$> getDaemonStatus
+	forM_ rs $ \r -> liftAnnex $
+		openDb (Remote.uuid r) >>= updateExportTreeFromLog
diff --git a/Assistant/Threads/Committer.hs b/Assistant/Threads/Committer.hs
new file mode 100644
index 0000000000..07013c0486
--- /dev/null
+++ b/Assistant/Threads/Committer.hs
@@ -0,0 +1,505 @@
+{- git-annex assistant commit thread
+ -
+ - Copyright 2012-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP, OverloadedStrings #-}
+
+module Assistant.Threads.Committer where
+
+import Assistant.Common
+import Assistant.Changes
+import Assistant.Types.Changes
+import Assistant.Commits
+import Assistant.Alert
+import Assistant.DaemonStatus
+import Assistant.TransferQueue
+import Assistant.Drop
+import Types.Transfer
+import Logs.Location
+import Utility.ThreadScheduler
+import qualified Utility.Lsof as Lsof
+import qualified Utility.DirWatcher as DirWatcher
+import Types.KeySource
+import Types.Command
+import Config
+import Annex.Content
+import Annex.Ingest
+import Annex.Link
+import Annex.Perms
+import Annex.CatFile
+import Annex.InodeSentinal
+import Annex.CurrentBranch
+import Annex.FileMatcher
+import qualified Annex
+import qualified Annex.Queue
+import qualified Annex.Branch
+import Utility.InodeCache
+import qualified Database.Keys
+import qualified Command.Sync
+import qualified Command.Add
+import Config.GitConfig
+import qualified Git.Branch
+import Utility.Tuple
+import Utility.Metered
+import qualified Utility.RawFilePath as R
+
+import Data.Time.Clock
+import qualified Data.Set as S
+import qualified Data.Map as M
+import Data.Either
+import Control.Concurrent
+import System.PosixCompat.Files (fileID, deviceID, fileMode)
+
+{- This thread makes git commits at appropriate times. -}
+commitThread :: NamedThread
+commitThread = namedThread "Committer" $ do
+	havelsof <- liftIO $ inSearchPath "lsof"
+	delayadd <- liftAnnex $
+		fmap Seconds . annexDelayAdd <$> Annex.getGitConfig
+	largefilematcher <- liftAnnex largeFilesMatcher
+	annexdotfiles <- liftAnnex $ getGitConfigVal annexDotFiles
+	msg <- liftAnnex Command.Sync.commitMsg
+	lockdowndir <- liftAnnex $ fromRepo gitAnnexTmpWatcherDir
+	liftAnnex $ do
+		-- Clean up anything left behind by a previous process
+		-- on unclean shutdown.
+		void $ liftIO $ tryIO $ removeDirectoryRecursive
+			(fromRawFilePath lockdowndir)
+		void $ createAnnexDirectory lockdowndir
+	waitChangeTime $ \(changes, time) -> do
+		readychanges <- handleAdds (fromRawFilePath lockdowndir) havelsof largefilematcher annexdotfiles delayadd $
+			simplifyChanges changes
+		if shouldCommit False time (length readychanges) readychanges
+			then do
+				debug
+					[ "committing"
+					, show (length readychanges)
+					, "changes"
+					]
+				void $ alertWhile commitAlert $
+					liftAnnex $ commitStaged msg
+				recordCommit
+				recordExportCommit
+				let numchanges = length readychanges
+				mapM_ checkChangeContent readychanges
+				return numchanges
+			else do
+				refill readychanges
+				return 0
+
+refill :: [Change] -> Assistant ()	
+refill [] = noop
+refill cs = do
+	debug ["delaying commit of", show (length cs), "changes"]
+	refillChanges cs
+
+{- Wait for one or more changes to arrive to be committed, and then
+ - runs an action to commit them. If more changes arrive while this is
+ - going on, they're handled intelligently, batching up changes into
+ - large commits where possible, doing rename detection, and
+ - committing immediately otherwise. -}
+waitChangeTime :: (([Change], UTCTime) -> Assistant Int) -> Assistant ()
+waitChangeTime a = waitchanges 0
+  where
+	waitchanges lastcommitsize = do
+		-- Wait one one second as a simple rate limiter.
+		liftIO $ threadDelaySeconds (Seconds 1)
+		-- Now, wait until at least one change is available for
+		-- processing.
+		cs <- getChanges
+		handlechanges cs lastcommitsize
+	handlechanges changes lastcommitsize = do
+		let len = length changes
+		-- See if now's a good time to commit.
+		now <- liftIO getCurrentTime
+		scanning <- not . scanComplete <$> getDaemonStatus
+		case (lastcommitsize >= maxCommitSize, shouldCommit scanning now len changes, possiblyrename changes) of
+			(True, True, _)
+				| len > maxCommitSize -> 
+					a (changes, now) >>= waitchanges
+				| otherwise -> aftermaxcommit changes
+			(_, True, False) ->
+				a (changes, now) >>= waitchanges
+			(_, True, True) -> do
+				morechanges <- getrelatedchanges changes
+				a (changes ++ morechanges, now) >>= waitchanges
+			_ -> do
+				refill changes
+				waitchanges lastcommitsize
+	
+	{- Did we perhaps only get one of the AddChange and RmChange pair
+	 - that make up a file rename? Or some of the pairs that make up 
+	 - a directory rename?
+	 -}
+	possiblyrename = all renamepart
+
+	renamepart (PendingAddChange _ _) = True
+	renamepart c = isRmChange c
+
+	{- Gets changes related to the passed changes, without blocking
+	 - very long.
+	 -
+	 - If there are multiple RmChanges, this is probably a directory
+	 - rename, in which case it may be necessary to wait longer to get
+	 - all the Changes involved.
+	 -}
+	getrelatedchanges oldchanges
+		| length (filter isRmChange oldchanges) > 1 =
+			concat <$> getbatchchanges []
+		| otherwise = do
+			liftIO humanImperceptibleDelay
+			getAnyChanges
+	getbatchchanges cs = do
+		liftIO $ threadDelay $ fromIntegral $ oneSecond `div` 10
+		cs' <- getAnyChanges
+		if null cs'
+			then return cs
+			else getbatchchanges (cs':cs)
+
+	{- The last commit was maximum size, so it's very likely there
+	 - are more changes and we'd like to ensure we make another commit
+	 - of maximum size if possible.
+	 -
+	 - But, it can take a while for the Watcher to wake back up
+	 - after a commit. It can get blocked by another thread
+	 - that is using the Annex state, such as a git-annex branch
+	 - commit. Especially after such a large commit, this can
+	 - take several seconds. When this happens, it defeats the
+	 - normal commit batching, which sees some old changes the
+	 - Watcher found while the commit was being prepared, and sees
+	 - no recent ones, and wants to commit immediately.
+	 -
+	 - All that we need to do, then, is wait for the Watcher to
+	 - wake up, and queue up one more change.
+	 -
+	 - However, it's also possible that we're at the end of changes for
+	 - now. So to avoid waiting a really long time before committing
+	 - those changes we have, poll for up to 30 seconds, and then
+	 - commit them.
+	 -
+	 - Also, try to run something in Annex, to ensure we block
+	 - longer if the Annex state is indeed blocked.
+	 -}
+	aftermaxcommit oldchanges = loop (30 :: Int)
+	  where
+		loop 0 = continue oldchanges
+		loop n = do
+			liftAnnex noop -- ensure Annex state is free
+			liftIO $ threadDelaySeconds (Seconds 1)
+			changes <- getAnyChanges
+			if null changes
+				then loop (n - 1)
+				else continue (oldchanges ++ changes)
+		continue cs
+			| null cs = waitchanges 0
+			| otherwise = handlechanges cs 0
+
+isRmChange :: Change -> Bool
+isRmChange (Change { changeInfo = i }) | i == RmChange = True
+isRmChange _ = False
+
+{- An amount of time that is hopefully imperceptably short for humans,
+ - while long enough for a computer to get some work done. 
+ - Note that 0.001 is a little too short for rename change batching to
+ - work. -}
+humanImperceptibleInterval :: NominalDiffTime
+humanImperceptibleInterval = 0.01
+
+humanImperceptibleDelay :: IO ()
+humanImperceptibleDelay = threadDelay $
+	truncate $ humanImperceptibleInterval * fromIntegral oneSecond
+
+maxCommitSize :: Int
+maxCommitSize = 5000
+
+{- Decide if now is a good time to make a commit.
+ - Note that the list of changes has a random order.
+ -
+ - Current strategy: If there have been 10 changes within the past second,
+ - a batch activity is taking place, so wait for later.
+ -}
+shouldCommit :: Bool -> UTCTime -> Int -> [Change] -> Bool
+shouldCommit scanning now len changes
+	| scanning = len >= maxCommitSize
+	| len == 0 = False
+	| len >= maxCommitSize = True
+	| length recentchanges < 10 = True
+	| otherwise = False -- batch activity
+  where
+	thissecond c = timeDelta c <= 1
+	recentchanges = filter thissecond changes
+	timeDelta c = now `diffUTCTime` changeTime c
+
+commitStaged :: String -> Annex Bool
+commitStaged msg = do
+	{- This could fail if there's another commit being made by
+	 - something else. -}
+	v <- tryNonAsync Annex.Queue.flush
+	case v of
+		Left _ -> return False
+		Right _ -> do
+			cmode <- annexCommitMode <$> Annex.getGitConfig
+			ok <- inRepo $ Git.Branch.commitCommand cmode
+				(Git.Branch.CommitQuiet True)
+				[ Param "-m"
+				, Param msg
+				]
+			when ok $
+				Command.Sync.updateBranches =<< getCurrentBranch
+			{- Commit the git-annex branch. This comes after
+			 - the commit of the staged changes, so that
+			 - annex.commitmessage-command can examine that
+			 - commit. -}
+			Annex.Branch.commit =<< Annex.Branch.commitMessage
+			return ok
+
+{- If there are PendingAddChanges, or InProcessAddChanges, the files
+ - have not yet actually been added, and that has to be done
+ - now, before committing.
+ -
+ - Deferring the adds to this point causes batches to be bundled together,
+ - which allows faster checking with lsof that the files are not still open
+ - for write by some other process, and faster checking with git-ls-files
+ - that the files are not already checked into git.
+ -
+ - When a file is added in locked mode, Inotify will notice the new symlink.
+ - So this waits for additional Changes to arrive, so that the symlink has
+ - hopefully been staged before returning, and will be committed immediately.
+ - (OTOH, for kqueue, eventsCoalesce, so instead the symlink is directly
+ - created and staged.)
+ -
+ - Returns a list of all changes that are ready to be committed.
+ - Any pending adds that are not ready yet are put back into the ChangeChan,
+ - where they will be retried later.
+ -}
+handleAdds :: FilePath -> Bool -> GetFileMatcher -> Bool -> Maybe Seconds -> [Change] -> Assistant [Change]
+handleAdds lockdowndir havelsof largefilematcher annexdotfiles delayadd cs = returnWhen (null incomplete) $ do
+	let (pending, inprocess) = partition isPendingAddChange incomplete
+	let lockdownconfig = LockDownConfig
+		{ lockingFile = False
+		, hardlinkFileTmpDir = Just (toRawFilePath lockdowndir)
+		, checkWritePerms = True
+		}
+	(postponed, toadd) <- partitionEithers
+		<$> safeToAdd lockdowndir lockdownconfig havelsof delayadd pending inprocess
+
+	unless (null postponed) $
+		refillChanges postponed
+
+	returnWhen (null toadd) $ do
+		(toaddannexed, toaddsmall) <- partitionEithers
+			<$> mapM checksmall toadd
+		addsmall toaddsmall
+		addedannexed <- addaction toadd $
+			catMaybes <$> addannexed toaddannexed
+		return $ addedannexed ++ toaddsmall ++ otherchanges
+  where
+	(incomplete, otherchanges) = partition (\c -> isPendingAddChange c || isInProcessAddChange c) cs
+
+	returnWhen c a
+		| c = return otherchanges
+		| otherwise = a
+
+	checksmall change
+		| not annexdotfiles && dotfile f =
+			return (Right change)
+		| otherwise =
+			ifM (liftAnnex $ checkFileMatcher largefilematcher f)
+				( return (Left change)
+				, return (Right change)
+				)
+	  where
+		f = toRawFilePath (changeFile change)
+
+	addsmall [] = noop
+	addsmall toadd = liftAnnex $ void $ tryIO $
+		forM (map (toRawFilePath . changeFile) toadd) $ \f ->
+			Command.Add.addFile Command.Add.Small f
+				=<< liftIO (R.getSymbolicLinkStatus f)
+
+	{- Avoid overhead of re-injesting a renamed unlocked file, by
+	 - examining the other Changes to see if a removed file has the
+	 - same InodeCache as the new file. If so, we can just update
+	 - bookkeeping, and stage the file in git.
+	 -}
+	addannexed :: [Change] -> Assistant [Maybe Change]
+	addannexed [] = return []
+	addannexed toadd = do
+		ct <- liftAnnex compareInodeCachesWith
+		m <- liftAnnex $ removedKeysMap ct cs
+		delta <- liftAnnex getTSDelta
+		let cfg = LockDownConfig
+			{ lockingFile = False
+			, hardlinkFileTmpDir = Just (toRawFilePath lockdowndir)
+			, checkWritePerms = True
+			}
+		if M.null m
+			then forM toadd (addannexed' cfg)
+			else forM toadd $ \c -> do
+				mcache <- liftIO $ genInodeCache (toRawFilePath (changeFile c)) delta
+				case mcache of
+					Nothing -> addannexed' cfg c
+					Just cache ->
+						case M.lookup (inodeCacheToKey ct cache) m of
+							Nothing -> addannexed' cfg c
+							Just k -> fastadd c k
+
+	addannexed' :: LockDownConfig -> Change -> Assistant (Maybe Change)
+	addannexed' lockdownconfig change@(InProcessAddChange { lockedDown = ld }) = 
+		catchDefaultIO Nothing <~> doadd
+	  where
+	  	ks = keySource ld
+		doadd = sanitycheck ks $ do
+			(mkey, _mcache) <- liftAnnex $ do
+				showStartMessage (StartMessage "add" (ActionItemOther (Just (QuotedPath (keyFilename ks)))) (SeekInput []))
+				ingest nullMeterUpdate (Just $ LockedDown lockdownconfig ks) Nothing
+			maybe (failedingest change) (done change $ fromRawFilePath $ keyFilename ks) mkey
+	addannexed' _ _ = return Nothing
+
+	fastadd :: Change -> Key -> Assistant (Maybe Change)
+	fastadd change key = do
+		let source = keySource $ lockedDown change
+		liftAnnex $ finishIngestUnlocked key source
+		done change (fromRawFilePath $ keyFilename source) key
+
+	removedKeysMap :: InodeComparisonType -> [Change] -> Annex (M.Map InodeCacheKey Key)
+	removedKeysMap ct l = do
+		mks <- forM (filter isRmChange l) $ \c ->
+			catKeyFile $ toRawFilePath $ changeFile c
+		M.fromList . concat <$> mapM mkpairs (catMaybes mks)
+	  where
+		mkpairs k = map (\c -> (inodeCacheToKey ct c, k)) <$>
+			Database.Keys.getInodeCaches k
+
+	failedingest change = do
+		refill [retryChange change]
+		liftAnnex showEndFail
+		return Nothing
+
+	done change file key = liftAnnex $ do
+		logStatus key InfoPresent
+		mode <- liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus (toRawFilePath file)
+		stagePointerFile (toRawFilePath file) mode =<< hashPointerFile key
+		showEndOk
+		return $ Just $ finishedChange change key
+
+	{- Check that the keysource's keyFilename still exists,
+	 - and is still a hard link to its contentLocation,
+	 - before ingesting it. -}
+	sanitycheck keysource a = do
+		fs <- liftIO $ R.getSymbolicLinkStatus $ keyFilename keysource
+		ks <- liftIO $ R.getSymbolicLinkStatus $ contentLocation keysource
+		if deviceID ks == deviceID fs && fileID ks == fileID fs
+			then a
+			else do
+				-- remove the hard link
+				when (contentLocation keysource /= keyFilename keysource) $
+					void $ liftIO $ tryIO $ removeFile $ fromRawFilePath $ contentLocation keysource
+				return Nothing
+
+	{- Shown an alert while performing an action to add a file or
+	 - files. When only a few files are added, their names are shown
+	 - in the alert. When it's a batch add, the number of files added
+	 - is shown.
+	 -
+	 - Add errors tend to be transient and will be
+	 - automatically dealt with, so the alert is always told
+	 - the add succeeded.
+	 -}
+	addaction [] a = a
+	addaction toadd a = alertWhile' (addFileAlert $ map changeFile toadd) $
+		(,) 
+			<$> pure True
+			<*> a
+
+{- Files can Either be Right to be added now,
+ - or are unsafe, and must be Left for later.
+ -
+ - Check by running lsof on the repository.
+ -}
+safeToAdd :: FilePath -> LockDownConfig -> Bool -> Maybe Seconds -> [Change] -> [Change] -> Assistant [Either Change Change]
+safeToAdd _ _ _ _ [] [] = return []
+safeToAdd lockdowndir lockdownconfig havelsof delayadd pending inprocess = do
+	maybe noop (liftIO . threadDelaySeconds) delayadd
+	liftAnnex $ do
+		lockeddown <- forM pending $ lockDown lockdownconfig . changeFile
+		let inprocess' = inprocess ++ mapMaybe mkinprocess (zip pending lockeddown)
+		openfiles <- if havelsof
+			then S.fromList . map fst3 . filter openwrite <$>
+				findopenfiles (map (keySource . lockedDown) inprocess')
+			else pure S.empty
+		let checked = map (check openfiles) inprocess'
+
+		{- If new events are received when files are closed,
+		 - there's no need to retry any changes that cannot
+		 - be done now. -}
+		if DirWatcher.closingTracked
+			then do
+				mapM_ canceladd $ lefts checked
+				allRight $ rights checked
+			else return checked
+  where
+	check openfiles change@(InProcessAddChange { lockedDown = ld })
+		| S.member (fromRawFilePath (contentLocation (keySource ld))) openfiles = Left change
+	check _ change = Right change
+
+	mkinprocess (c, Just ld) = Just InProcessAddChange
+		{ changeTime = changeTime c
+		, lockedDown = ld
+		}
+	mkinprocess (_, Nothing) = Nothing
+
+	canceladd (InProcessAddChange { lockedDown = ld }) = do
+		let ks = keySource ld
+		warning $ QuotedPath (keyFilename ks)
+			<> " still has writers, not adding"
+		-- remove the hard link
+		when (contentLocation ks /= keyFilename ks) $
+			void $ liftIO $ tryIO $ removeFile $ fromRawFilePath $ contentLocation ks
+	canceladd _ = noop
+
+	openwrite (_file, mode, _pid)
+		| mode == Lsof.OpenWriteOnly = True
+		| mode == Lsof.OpenReadWrite = True
+		| mode == Lsof.OpenUnknown = True
+		| otherwise = False
+
+	allRight = return . map Right
+
+	{- Normally the KeySources are locked down inside the lockdowndir,
+	 - so can just lsof that, which is quite efficient.
+	 -
+	 - In crippled filesystem mode, there is no lock down, so must run lsof
+	 - on each individual file.
+	 -}
+	findopenfiles keysources = ifM crippledFileSystem
+		( liftIO $ do
+			let segments = segmentXargsUnordered $
+				map (fromRawFilePath . keyFilename) keysources
+			concat <$> forM segments (\fs -> Lsof.query $ "--" : fs)
+		, liftIO $ Lsof.queryDir lockdowndir
+		)
+
+{- After a Change is committed, queue any necessary transfers or drops
+ - of the content of the key.
+ -
+ - This is not done during the startup scan, because the expensive
+ - transfer scan does the same thing then.
+ -}
+checkChangeContent :: Change -> Assistant ()
+checkChangeContent change@(Change { changeInfo = i }) =
+	case changeInfoKey i of
+		Nothing -> noop
+		Just k -> whenM (scanComplete <$> getDaemonStatus) $ do
+			present <- liftAnnex $ inAnnex k
+			void $ if present
+				then queueTransfers "new file created" Next k af Upload
+				else queueTransfers "new or renamed file wanted" Next k af Download
+			handleDrops "file renamed" present k af []
+  where
+	f = changeFile change
+	af = AssociatedFile (Just (toRawFilePath f))
+checkChangeContent _ = noop
diff --git a/Assistant/Threads/ConfigMonitor.hs b/Assistant/Threads/ConfigMonitor.hs
new file mode 100644
index 0000000000..9f1e03f8d1
--- /dev/null
+++ b/Assistant/Threads/ConfigMonitor.hs
@@ -0,0 +1,95 @@
+{- git-annex assistant config monitor thread
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Threads.ConfigMonitor where
+
+import Assistant.Common
+import Assistant.BranchChange
+import Assistant.DaemonStatus
+import Assistant.Commits
+import Utility.ThreadScheduler
+import Logs
+import Logs.UUID
+import Logs.Trust
+import Logs.PreferredContent
+import Logs.Group
+import Logs.NumCopies
+import Remote.List.Util
+import qualified Git.LsTree as LsTree
+import Git.Types
+import Git.FilePath
+import qualified Annex.Branch
+import Annex.FileMatcher
+
+import qualified Data.Set as S
+
+{- This thread detects when configuration changes have been made to the
+ - git-annex branch and reloads cached configuration.
+ -
+ - If the branch is frequently changing, it's checked for configuration
+ - changes no more often than once every 60 seconds. On the other hand,
+ - if the branch has not changed in a while, configuration changes will
+ - be detected immediately.
+ -}
+configMonitorThread :: NamedThread
+configMonitorThread = namedThread "ConfigMonitor" $ loop =<< getConfigs
+  where
+	loop old = do
+		waitBranchChange
+		new <- getConfigs
+		when (old /= new) $ do
+			let changedconfigs = new `S.difference` old
+			debug $ "reloading config" : 
+				map (fromRawFilePath . fst)
+				(S.toList changedconfigs)
+			reloadConfigs new
+			{- Record a commit to get this config
+			 - change pushed out to remotes. -}
+			recordCommit
+		liftIO $ threadDelaySeconds (Seconds 60)
+		loop new
+
+{- Config files, and their checksums. -}
+type Configs = S.Set (RawFilePath, Sha)
+
+{- All git-annex's config files, and actions to run when they change. -}
+configFilesActions :: [(RawFilePath, Assistant ())]
+configFilesActions =
+	[ (uuidLog, void $ liftAnnex uuidDescMapLoad)
+	, (remoteLog, void $ liftAnnex remotesChanged)
+	, (trustLog, void $ liftAnnex trustMapLoad)
+	, (groupLog, void $ liftAnnex groupMapLoad)
+	, (numcopiesLog, void $ liftAnnex globalNumCopiesLoad)
+	, (mincopiesLog, void $ liftAnnex globalMinCopiesLoad)
+	, (scheduleLog, void updateScheduleLog)
+	-- Preferred and required content settings depend on most of the
+	-- other configs, so will be reloaded whenever any configs change.
+	, (preferredContentLog, noop)
+	, (requiredContentLog, noop)
+	, (groupPreferredContentLog, noop)
+	]
+
+reloadConfigs :: Configs -> Assistant ()
+reloadConfigs changedconfigs = do
+	sequence_ as
+	void $ liftAnnex $ preferredRequiredMapsLoad preferredContentTokens
+	{- Changes to the remote log, or the trust log, can affect the
+	 - syncRemotes list. Changes to the uuid log may affect its
+	 - display so are also included. -}
+	when (any (`elem` fs) [remoteLog, trustLog, uuidLog])
+		updateSyncRemotes
+  where
+	(fs, as) = unzip $ filter (flip S.member changedfiles . fst)
+		configFilesActions
+	changedfiles = S.map fst changedconfigs
+
+getConfigs :: Assistant Configs
+getConfigs = S.fromList . map extract
+	<$> liftAnnex (inRepo $ LsTree.lsTreeFiles (LsTree.LsTreeLong False) Annex.Branch.fullname files)
+  where
+	files = map (fromRawFilePath . fst) configFilesActions
+	extract treeitem = (getTopFilePath $ LsTree.file treeitem, LsTree.sha treeitem)
diff --git a/Assistant/Threads/Cronner.hs b/Assistant/Threads/Cronner.hs
new file mode 100644
index 0000000000..9bd173869d
--- /dev/null
+++ b/Assistant/Threads/Cronner.hs
@@ -0,0 +1,225 @@
+{- git-annex assistant sceduled jobs runner
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE DeriveDataTypeable #-}
+
+module Assistant.Threads.Cronner (
+	cronnerThread
+) where
+
+import Assistant.Common
+import Assistant.DaemonStatus
+import Utility.NotificationBroadcaster
+import Annex.UUID
+import Annex.Path
+import Logs.Schedule
+import Utility.Scheduled
+import Types.ScheduledActivity
+import Utility.ThreadScheduler
+import Utility.HumanTime
+import Utility.Batch
+import Assistant.TransferQueue
+import Annex.Content
+import Types.Transfer
+import Assistant.Types.UrlRenderer
+import Assistant.Alert
+import Remote
+import qualified Types.Remote as Remote
+import qualified Git
+import qualified Git.Fsck
+import Assistant.Fsck
+import Assistant.Repair
+
+import Control.Concurrent.Async
+import Control.Concurrent.MVar
+import Data.Time.LocalTime
+import Data.Time.Clock
+import qualified Data.Map as M
+import qualified Data.Set as S
+
+{- Loads schedules for this repository, and fires off one thread for each 
+ - scheduled event that runs on this repository. Each thread sleeps until
+ - its event is scheduled to run.
+ -
+ - To handle events that run on remotes, which need to only run when
+ - their remote gets connected, threads are also started, and are passed
+ - a MVar to wait on, which is stored in the DaemonStatus's
+ - connectRemoteNotifiers.
+ -
+ - In the meantime the main thread waits for any changes to the
+ - schedules. When there's a change, compare the old and new list of
+ - schedules to find deleted and added ones. Start new threads for added
+ - ones, and kill the threads for deleted ones. -}
+cronnerThread :: UrlRenderer -> NamedThread
+cronnerThread urlrenderer = namedThreadUnchecked "Cronner" $ do
+	fsckNudge urlrenderer Nothing
+	dstatus <- getDaemonStatus
+	h <- liftIO $ newNotificationHandle False (scheduleLogNotifier dstatus)
+	go h M.empty M.empty
+  where
+	go h amap nmap = do
+		activities <- liftAnnex $ scheduleGet =<< getUUID
+
+		let addedactivities = activities `S.difference` M.keysSet amap
+		let removedactivities = M.keysSet amap `S.difference` activities
+
+		forM_ (S.toList removedactivities) $ \activity ->
+			case M.lookup activity amap of
+				Just a -> do
+					debug ["stopping removed job for", fromScheduledActivity activity, show (asyncThreadId a)]
+					liftIO $ cancel a
+				Nothing -> noop
+
+		lastruntimes <- liftAnnex getLastRunTimes
+		started <- startactivities (S.toList addedactivities) lastruntimes
+		let addedamap = M.fromList $ map fst started
+		let addednmap = M.fromList $ catMaybes $ map snd started
+
+		let removefiltered = M.filterWithKey (\k _ -> S.member k removedactivities)
+		let amap' = M.difference (M.union addedamap amap) (removefiltered amap)
+		let nmap' = M.difference (M.union addednmap nmap) (removefiltered nmap)
+		modifyDaemonStatus_ $ \s -> s { connectRemoteNotifiers = M.fromListWith (++) (M.elems nmap') }
+
+		liftIO $ waitNotification h
+		debug ["reloading changed activities"]
+		go h amap' nmap'
+	startactivities as lastruntimes = forM as $ \activity ->
+		case connectActivityUUID activity of
+			Nothing -> do
+				runner <- asIO2 (sleepingActivityThread urlrenderer)
+				a <- liftIO $ async $
+					runner activity (M.lookup activity lastruntimes)
+				return ((activity, a), Nothing)
+			Just u -> do
+				mvar <- liftIO newEmptyMVar
+				runner <- asIO2 (remoteActivityThread urlrenderer mvar)
+				a <- liftIO $ async $
+					runner activity (M.lookup activity lastruntimes)
+				return ((activity, a), Just (activity, (u, [mvar])))
+
+{- Calculate the next time the activity is scheduled to run, then
+ - sleep until that time, and run it. Then call setLastRunTime, and
+ - loop.
+ -}
+sleepingActivityThread :: UrlRenderer -> ScheduledActivity -> Maybe LocalTime -> Assistant ()
+sleepingActivityThread urlrenderer activity lasttime = go lasttime =<< getnexttime lasttime
+  where
+	getnexttime = liftIO . nextTime schedule
+	go _ Nothing = debug ["no scheduled events left for", desc]
+	go l (Just (NextTimeExactly t)) = waitrun l t Nothing
+	go l (Just (NextTimeWindow windowstart windowend)) =
+		waitrun l windowstart (Just windowend)
+	desc = fromScheduledActivity activity
+	schedule = getSchedule activity
+	waitrun l t mmaxt = do
+		seconds <- liftIO $ secondsUntilLocalTime t
+		when (seconds > Seconds 0) $ do
+			debug ["waiting", show seconds, "for next scheduled", desc]
+			liftIO $ threadDelaySeconds seconds
+		now <- liftIO getCurrentTime
+		tz <- liftIO $ getTimeZone now
+		let nowt = utcToLocalTime tz now
+		if tolate nowt tz
+			then do
+				debug ["too late to run scheduled", desc]
+				go l =<< getnexttime l
+			else run nowt
+	  where
+		tolate nowt tz = case mmaxt of
+			Just maxt -> nowt > maxt
+			-- allow the job to start 10 minutes late
+			Nothing -> diffUTCTime 
+				(localTimeToUTC tz nowt)
+				(localTimeToUTC tz t) > 600
+	run nowt = do
+		runActivity urlrenderer activity nowt
+		go (Just nowt) =<< getnexttime (Just nowt)
+
+{- Wait for the remote to become available by waiting on the MVar.
+ - Then check if the time is within a time window when activity
+ - is scheduled to run, and if so run it.
+ - Otherwise, just wait again on the MVar.
+ -}
+remoteActivityThread :: UrlRenderer -> MVar () -> ScheduledActivity -> Maybe LocalTime -> Assistant ()
+remoteActivityThread urlrenderer mvar activity lasttime = do
+	liftIO $ takeMVar mvar
+	go =<< liftIO (nextTime (getSchedule activity) lasttime)
+  where
+	go (Just (NextTimeWindow windowstart windowend)) = do
+		now <- liftIO getCurrentTime
+		tz <- liftIO $ getTimeZone now
+		if now >= localTimeToUTC tz windowstart && now <= localTimeToUTC tz windowend
+			then do
+				let nowt = utcToLocalTime tz now
+				runActivity urlrenderer activity nowt
+				loop (Just nowt)
+			else loop lasttime
+	go _ = noop -- running at exact time not handled here
+	loop = remoteActivityThread urlrenderer mvar activity
+
+secondsUntilLocalTime :: LocalTime -> IO Seconds
+secondsUntilLocalTime t = do
+	now <- getCurrentTime
+	tz <- getTimeZone now
+	let secs = truncate $ diffUTCTime (localTimeToUTC tz t) now
+	return $ if secs > 0
+		then Seconds secs
+		else Seconds 0
+
+runActivity :: UrlRenderer -> ScheduledActivity -> LocalTime -> Assistant ()
+runActivity urlrenderer activity nowt = do
+	debug ["starting", desc]
+	runActivity' urlrenderer activity
+	debug ["finished", desc]
+	liftAnnex $ setLastRunTime activity nowt
+  where
+	desc = fromScheduledActivity activity
+
+runActivity' :: UrlRenderer -> ScheduledActivity -> Assistant ()
+runActivity' urlrenderer (ScheduledSelfFsck _ d) = do
+	program <- liftIO programPath
+	g <- liftAnnex gitRepo
+	fsckresults <- showFscking urlrenderer Nothing $ tryNonAsync $ do
+		void $ batchCommand program (Param "fsck" : annexFsckParams d)
+		Git.Fsck.findBroken True False g
+	u <- liftAnnex getUUID
+	void $ repairWhenNecessary urlrenderer u Nothing fsckresults
+	mapM_ reget =<< liftAnnex (dirKeys gitAnnexBadDir)
+  where
+	reget k = queueTransfers "fsck found bad file; redownloading" Next k (AssociatedFile Nothing) Download
+runActivity' urlrenderer (ScheduledRemoteFsck u s d) = dispatch =<< liftAnnex (remoteFromUUID u)
+  where
+	dispatch Nothing = debug ["skipping remote fsck of uuid without a configured remote", fromUUID u, fromSchedule s]
+	dispatch (Just rmt) = void $ case Remote.remoteFsck rmt of
+		Nothing -> go rmt $ do
+			program <- programPath
+			void $ batchCommand program $ 
+				[ Param "fsck"
+				-- avoid downloading files
+				, Param "--fast"
+				, Param "--from"
+				, Param $ Remote.name rmt
+				] ++ annexFsckParams d
+		Just mkfscker -> do
+			{- Note that having mkfsker return an IO action
+			 - avoids running a long duration fsck in the
+			 - Annex monad. -}
+			go rmt =<< liftAnnex (mkfscker (annexFsckParams d))
+	go rmt annexfscker = do
+		repo <- liftAnnex $ Remote.getRepo rmt
+		fsckresults <- showFscking urlrenderer (Just rmt) $ tryNonAsync $ do
+			void annexfscker
+			if Git.repoIsLocal repo && not (Git.repoIsLocalUnknown repo)
+				then Just <$> Git.Fsck.findBroken True True repo
+				else pure Nothing
+		maybe noop (void . repairWhenNecessary urlrenderer u (Just rmt)) fsckresults
+
+annexFsckParams :: Duration -> [CommandParam]
+annexFsckParams d =
+	[ Param "--incremental-schedule=1d"
+	, Param $ "--time-limit=" ++ fromDuration d
+	]
diff --git a/Assistant/Threads/DaemonStatus.hs b/Assistant/Threads/DaemonStatus.hs
new file mode 100644
index 0000000000..0b14ca737f
--- /dev/null
+++ b/Assistant/Threads/DaemonStatus.hs
@@ -0,0 +1,29 @@
+{- git-annex assistant daemon status thread
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Threads.DaemonStatus where
+
+import Assistant.Common
+import Assistant.DaemonStatus
+import Utility.ThreadScheduler
+import Utility.NotificationBroadcaster
+
+{- This writes the daemon status to disk, when it changes, but no more
+ - frequently than once every ten minutes.
+ -}
+daemonStatusThread :: NamedThread
+daemonStatusThread = namedThread "DaemonStatus" $ do
+	notifier <- liftIO . newNotificationHandle False
+		=<< changeNotifier <$> getDaemonStatus
+	checkpoint
+	runEvery (Seconds tenMinutes) <~> do
+		liftIO $ waitNotification notifier
+		checkpoint
+  where
+	checkpoint = do
+		file <- liftAnnex $ fromRepo gitAnnexDaemonStatusFile
+		liftIO . writeDaemonStatusFile file =<< getDaemonStatus
diff --git a/Assistant/Threads/Exporter.hs b/Assistant/Threads/Exporter.hs
new file mode 100644
index 0000000000..20a252baff
--- /dev/null
+++ b/Assistant/Threads/Exporter.hs
@@ -0,0 +1,80 @@
+{- git-annex assistant export updating thread
+ -
+ - Copyright 2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Threads.Exporter where
+
+import Assistant.Common
+import Assistant.Commits
+import Assistant.Pushes
+import Assistant.DaemonStatus
+import Annex.Concurrent
+import Annex.CurrentBranch
+import Utility.ThreadScheduler
+import qualified Annex
+import qualified Remote
+import qualified Types.Remote as Remote
+import qualified Command.Sync
+
+import Control.Concurrent.Async
+import Data.Time.Clock
+import qualified Data.Map as M
+
+{- This thread retries exports that failed before. -}
+exportRetryThread :: NamedThread
+exportRetryThread = namedThread "ExportRetrier" $ runEvery (Seconds halfhour) <~> do
+	-- We already waited half an hour, now wait until there are failed
+	-- exports to retry.
+	toexport <- getFailedPushesBefore (fromIntegral halfhour) 
+		=<< getAssistant failedExportMap
+	unless (null toexport) $ do
+		debug ["retrying", show (length toexport), "failed exports"]
+		void $ exportToRemotes toexport
+  where
+	halfhour = 1800
+
+{- This thread updates exports soon after git commits are made. -}
+exportThread :: NamedThread
+exportThread = namedThread "Exporter" $ runEvery (Seconds 30) <~> do
+	-- We already waited two seconds as a simple rate limiter.
+	-- Next, wait until at least one commit has been made
+	void getExportCommits
+	-- Now see if now's a good time to push.
+	void $ exportToRemotes =<< exportTargets
+
+{- We want to avoid exporting to remotes that are marked readonly.
+ -
+ - Also, avoid exporting to local remotes we can easily tell are not available,
+ - to avoid ugly messages when a removable drive is not attached.
+ -}
+exportTargets :: Assistant [Remote]
+exportTargets = liftAnnex . filterM (Remote.checkAvailable True)
+	=<< candidates <$> getDaemonStatus
+  where
+	candidates = filter (not . Remote.readonly) . exportRemotes
+
+exportToRemotes :: [Remote] -> Assistant ()
+exportToRemotes rs = do
+	-- This is a long-duration action which runs in the Annex monad,
+	-- so don't just liftAnnex to run it; fork the Annex state.
+	runner <- liftAnnex $ forkState $
+		forM rs $ \r -> do
+			Annex.changeState $ \st -> st { Annex.errcounter = 0 }
+			start <- liftIO getCurrentTime
+			void $ Command.Sync.seekExportContent Nothing rs
+				=<< getCurrentBranch
+			-- Look at command error counter to see if the export
+			-- didn't work.
+			failed <- (> 0) <$> Annex.getState Annex.errcounter
+			Annex.changeState $ \st -> st { Annex.errcounter = 0 }
+			return $ if failed
+				then Just (r, start)
+				else Nothing
+	failed <- catMaybes
+		<$> (liftAnnex =<< liftIO . wait =<< liftIO (async runner))
+	unless (null failed) $ do
+		v <- getAssistant failedExportMap
+		changeFailedPushMap v $ M.union $ M.fromList failed
diff --git a/Assistant/Threads/Glacier.hs b/Assistant/Threads/Glacier.hs
new file mode 100644
index 0000000000..d5a20e908f
--- /dev/null
+++ b/Assistant/Threads/Glacier.hs
@@ -0,0 +1,44 @@
+{- git-annex assistant Amazon Glacier retrieval
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Assistant.Threads.Glacier where
+
+import Assistant.Common
+import Utility.ThreadScheduler
+import qualified Types.Remote as Remote
+import qualified Remote.Glacier as Glacier
+import Types.Transfer
+import Logs.Transfer
+import Assistant.DaemonStatus
+import Assistant.TransferQueue
+
+import qualified Data.Set as S
+
+{- Wakes up every half hour and checks if any glacier remotes have failed
+ - downloads. If so, runs glacier-cli to check if the files are now
+ - available, and queues the downloads. -}
+glacierThread :: NamedThread
+glacierThread = namedThread "Glacier" $ runEvery (Seconds 3600) <~> go
+  where
+	isglacier r = Remote.remotetype r == Glacier.remote
+	go = do
+		rs <- filter isglacier . downloadRemotes <$> getDaemonStatus
+		forM_ rs $ \r -> 
+			check r =<< liftAnnex (getFailedTransfers $ Remote.uuid r)
+	check _ [] = noop
+	check r l = do
+		let keys = map getkey l
+		(availkeys, failedkeys) <- liftAnnex $ Glacier.jobList r keys
+		let s = S.fromList (failedkeys ++ availkeys)
+		let l' = filter (\p -> S.member (getkey p) s) l
+		forM_ l' $ \(t, info) -> do
+			liftAnnex $ removeFailedTransfer t
+			queueTransferWhenSmall "object available from glacier" (associatedFile info) t r
+	getkey = transferKey . fst
diff --git a/Assistant/Threads/Merger.hs b/Assistant/Threads/Merger.hs
new file mode 100644
index 0000000000..7b9db70abf
--- /dev/null
+++ b/Assistant/Threads/Merger.hs
@@ -0,0 +1,131 @@
+{- git-annex assistant git merge thread
+ -
+ - Copyright 2012-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Assistant.Threads.Merger where
+
+import Assistant.Common
+import Assistant.TransferQueue
+import Assistant.BranchChange
+import Assistant.Sync
+import Utility.DirWatcher
+import Utility.DirWatcher.Types
+import Utility.Directory.Create
+import Annex.CurrentBranch
+import Assistant.Commits
+import qualified Annex
+import qualified Annex.Branch
+import qualified Git
+import qualified Git.Branch
+import qualified Git.Ref
+import qualified Command.Sync
+
+import qualified System.FilePath.ByteString as P
+
+{- This thread watches for changes to .git/refs/, and handles incoming
+ - pushes. -}
+mergeThread :: NamedThread
+mergeThread = namedThread "Merger" $ do
+	g <- liftAnnex gitRepo
+	let gitd = Git.localGitDir g
+	let dir = gitd P.</> "refs"
+	liftIO $ createDirectoryUnder [gitd] dir
+	let hook a = Just <$> asIO2 (runHandler a)
+	changehook <- hook onChange
+	errhook <- hook onErr
+	let hooks = mkWatchHooks
+		{ addHook = changehook
+		, modifyHook = changehook
+		, errHook = errhook
+		}
+	void $ liftIO $ watchDir (fromRawFilePath dir) (const False) True hooks id
+	debug ["watching", fromRawFilePath dir]
+
+type Handler = FilePath -> Assistant ()
+
+{- Runs an action handler.
+ -
+ - Exceptions are ignored, otherwise a whole thread could be crashed.
+ -}
+runHandler :: Handler -> FilePath -> Maybe FileStatus -> Assistant ()
+runHandler handler file _filestatus =
+	either (liftIO . print) (const noop) =<< tryIO <~> handler file
+
+{- Called when there's an error with inotify. -}
+onErr :: Handler
+onErr = giveup
+
+{- Called when a new branch ref is written, or a branch ref is modified.
+ -
+ - At startup, synthetic add events fire, causing this to run, but that's
+ - ok; it ensures that any changes pushed since the last time the assistant
+ - ran are merged in.
+ -}
+onChange :: Handler
+onChange file
+	| ".lock" `isSuffixOf` file = noop
+	| isAnnexBranch file = do
+		branchChanged
+		diverged <- liftAnnex Annex.Branch.forceUpdate >>= return . \case
+			u@(Annex.Branch.UpdateMade {}) -> Annex.Branch.refsWereMerged u
+			(Annex.Branch.UpdateFailedPermissions {}) -> True
+		when diverged $ do
+			updateExportTreeFromLogAll
+			queueDeferredDownloads "retrying deferred download" Later
+	| otherwise = mergecurrent
+  where
+	changedbranch = fileToBranch file
+
+	mergecurrent =
+		mergecurrent' =<< liftAnnex getCurrentBranch
+	mergecurrent' currbranch@(Just b, _)
+		| changedbranch `isRelatedTo` b = do
+			whenM (liftAnnex $ inRepo $ Git.Branch.changed b changedbranch) $ do
+				debug
+					[ "merging", Git.fromRef changedbranch
+					, "into", Git.fromRef b
+					]
+				void $ liftAnnex $ do
+					cmode <- annexCommitMode <$> Annex.getGitConfig
+					-- Allow merging unrelated histories.
+					mc <- Command.Sync.mergeConfig True
+					Command.Sync.merge
+						currbranch
+						mc
+						def
+						cmode
+						[changedbranch]
+			recordCommit
+		| changedbranch == b =
+			-- Record commit so the pusher pushes it out.
+			-- This makes sure pushes happen when
+			-- annex.autocommit=false
+			recordCommit
+	mergecurrent' _ = noop
+
+{- Is the first branch a synced branch or remote tracking branch related
+ - to the second branch, which should be merged into it? -}
+isRelatedTo :: Git.Ref -> Git.Ref -> Bool
+isRelatedTo x y
+	| basex /= takeDirectory basex ++ "/" ++ basey = False
+	| "/synced/" `isInfixOf` Git.fromRef x = True
+	| "refs/remotes/" `isPrefixOf` Git.fromRef x = True
+	| otherwise = False
+  where
+	basex = Git.fromRef $ Git.Ref.base x
+	basey = Git.fromRef $ Git.Ref.base y
+
+isAnnexBranch :: FilePath -> Bool
+isAnnexBranch f = n `isSuffixOf` f
+  where
+	n = '/' : Git.fromRef Annex.Branch.name
+
+fileToBranch :: FilePath -> Git.Ref
+fileToBranch f = Git.Ref $ encodeBS $ "refs" </> base
+  where
+	base = Prelude.last $ split "/refs/" f
diff --git a/Assistant/Threads/MountWatcher.hs b/Assistant/Threads/MountWatcher.hs
new file mode 100644
index 0000000000..11997fbd71
--- /dev/null
+++ b/Assistant/Threads/MountWatcher.hs
@@ -0,0 +1,182 @@
+{- git-annex assistant mount watcher, using either dbus or mtab polling
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Assistant.Threads.MountWatcher where
+
+import Assistant.Common
+import Assistant.DaemonStatus
+import Assistant.Sync
+import qualified Annex
+import qualified Git
+import Utility.ThreadScheduler
+import Utility.Mounts
+import Remote.List
+import qualified Types.Remote as Remote
+import Assistant.Types.UrlRenderer
+import Assistant.Fsck
+
+import qualified Data.Set as S
+
+#if WITH_DBUS
+import Utility.DBus
+import DBus.Client
+import DBus
+import Data.Word (Word32)
+import Control.Concurrent
+import qualified Control.Exception as E
+#else
+#ifdef linux_HOST_OS
+#warning Building without dbus support; will use mtab polling
+#endif
+#endif
+
+mountWatcherThread :: UrlRenderer -> NamedThread
+mountWatcherThread urlrenderer = namedThread "MountWatcher" $
+#if WITH_DBUS
+	dbusThread urlrenderer
+#else
+	pollingThread urlrenderer
+#endif
+
+#if WITH_DBUS
+
+dbusThread :: UrlRenderer -> Assistant ()
+dbusThread urlrenderer = do
+	runclient <- asIO1 go
+	r <- liftIO $ E.try $ runClient getSystemAddress runclient
+	either onerr (const noop) r
+  where
+	go client = ifM (checkMountMonitor client)
+		( do
+			{- Store the current mount points in an MVar, to be
+			 - compared later. We could in theory work out the
+			 - mount point from the dbus message, but this is
+			 - easier. -}
+			mvar <- liftIO $ newMVar =<< currentMountPoints
+			handleevent <- asIO1 $ \_event -> do
+				nowmounted <- liftIO $ currentMountPoints
+				wasmounted <- liftIO $ swapMVar mvar nowmounted
+				handleMounts urlrenderer wasmounted nowmounted
+			liftIO $ forM_ mountChanged $ \matcher ->
+				void $ addMatch client matcher handleevent
+		, do
+			liftAnnex $
+				warning "No known volume monitor available through dbus; falling back to mtab polling"
+			pollingThread urlrenderer
+		)
+	onerr :: E.SomeException -> Assistant ()
+	onerr e = do
+		liftAnnex $
+			warning $ UnquotedString $ "dbus failed; falling back to mtab polling (" ++ show e ++ ")"
+		pollingThread urlrenderer
+
+{- Examine the list of services connected to dbus, to see if there
+ - are any we can use to monitor mounts. If not, will attempt to start one. -}
+checkMountMonitor :: Client -> Assistant Bool
+checkMountMonitor client = do
+	running <- filter (`elem` usableservices)
+		<$> liftIO (listServiceNames client)
+	case running of
+		[] -> startOneService client startableservices
+		(service:_) -> do
+			debug [ "Using running DBUS service"
+				, service
+				, "to monitor mount events."
+				]
+			return True
+  where
+	startableservices = [udisks2]
+	usableservices = startableservices
+	udisks2 = "org.freedesktop.UDisks2"
+
+startOneService :: Client -> [ServiceName] -> Assistant Bool
+startOneService _ [] = return False
+startOneService client (x:xs) = do
+	_ <- liftIO $ tryNonAsync $ callDBus client "StartServiceByName"
+		[toVariant x, toVariant (0 :: Word32)]
+	ifM (liftIO $ elem x <$> listServiceNames client)
+		( do
+			debug
+				[ "Started DBUS service", x
+				, "to monitor mount events."
+				]
+			return True
+		, startOneService client xs
+		)
+
+{- Filter matching events received when drives are mounted and unmounted. -}	
+mountChanged :: [MatchRule]
+mountChanged = [udisks2mount, udisks2umount]
+  where
+	udisks2mount = matchAny
+		{ matchPath = Just "/org/freedesktop/UDisks2"
+		, matchInterface = Just "org.freedesktop.DBus.ObjectManager"
+		, matchMember = Just "InterfacesAdded"
+		}
+	udisks2umount = matchAny
+		{ matchPath = Just "/org/freedesktop/UDisks2"
+		, matchInterface = Just "org.freedesktop.DBus.ObjectManager"
+		, matchMember = Just "InterfacesRemoved"
+		}
+#endif
+
+pollingThread :: UrlRenderer -> Assistant ()
+pollingThread urlrenderer = go =<< liftIO currentMountPoints
+  where
+	go wasmounted = do
+		liftIO $ threadDelaySeconds (Seconds 10)
+		nowmounted <- liftIO currentMountPoints
+		handleMounts urlrenderer wasmounted nowmounted
+		go nowmounted
+
+handleMounts :: UrlRenderer -> MountPoints -> MountPoints -> Assistant ()
+handleMounts urlrenderer wasmounted nowmounted =
+	mapM_ (handleMount urlrenderer . mnt_dir) $
+		S.toList $ newMountPoints wasmounted nowmounted
+
+handleMount :: UrlRenderer -> FilePath -> Assistant ()
+handleMount urlrenderer dir = do
+	debug ["detected mount of", dir]
+	rs <- filterM (Git.repoIsLocal <$$> liftAnnex . Remote.getRepo)
+		=<< remotesUnder dir
+	mapM_ (fsckNudge urlrenderer . Just) rs
+	reconnectRemotes rs
+
+{- Finds remotes located underneath the mount point.
+ -
+ - Updates state to include the remotes.
+ -
+ - The config of git remotes is re-read, as it may not have been available
+ - at startup time, or may have changed (it could even be a different
+ - repository at the same remote location..)
+ -}
+remotesUnder :: FilePath -> Assistant [Remote]
+remotesUnder dir = do
+	repotop <- liftAnnex $ fromRepo Git.repoPath
+	rs <- liftAnnex remoteList
+	pairs <- liftAnnex $ mapM (checkremote repotop) rs
+	let (waschanged, rs') = unzip pairs
+	when (or waschanged) $ do
+		liftAnnex $ Annex.changeState $ \s -> s { Annex.remotes = catMaybes rs' }
+		updateSyncRemotes
+	return $ mapMaybe snd $ filter fst pairs
+  where
+	checkremote repotop r = case Remote.localpath r of
+		Just p | dirContains (toRawFilePath dir) (absPathFrom repotop (toRawFilePath p)) ->
+			(,) <$> pure True <*> updateRemote r
+		_ -> return (False, Just r)
+
+type MountPoints = S.Set Mntent
+
+currentMountPoints :: IO MountPoints
+currentMountPoints = S.fromList <$> getMounts
+
+newMountPoints :: MountPoints -> MountPoints -> MountPoints
+newMountPoints old new = S.difference new old
diff --git a/Assistant/Threads/NetWatcher.hs b/Assistant/Threads/NetWatcher.hs
new file mode 100644
index 0000000000..f86872d74c
--- /dev/null
+++ b/Assistant/Threads/NetWatcher.hs
@@ -0,0 +1,202 @@
+{- git-annex assistant network connection watcher, using dbus
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Assistant.Threads.NetWatcher where
+
+import Assistant.Common
+import Assistant.Sync
+import Utility.ThreadScheduler
+import qualified Types.Remote as Remote
+import Assistant.DaemonStatus
+import Utility.NotificationBroadcaster
+
+#if WITH_DBUS
+import Assistant.RemoteControl
+import Utility.DBus
+import DBus.Client
+import DBus
+#else
+#ifdef linux_HOST_OS
+#warning Building without dbus support; will poll for network connection changes
+#endif
+#endif
+
+netWatcherThread :: NamedThread
+#if WITH_DBUS
+netWatcherThread = thread dbusThread
+#else
+netWatcherThread = thread noop
+#endif
+  where
+	thread = namedThread "NetWatcher"
+
+{- This is a fallback for when dbus cannot be used to detect
+ - network connection changes, but it also ensures that
+ - any networked remotes that may have not been routable for a
+ - while (despite the local network staying up), are synced with
+ - periodically.
+ -
+ - Note that it does not signal the RemoteControl, because it doesn't 
+ - know that the network has changed.
+ -}
+netWatcherFallbackThread :: NamedThread
+netWatcherFallbackThread = namedThread "NetWatcherFallback" $
+	runEvery (Seconds 3600) <~> handleConnection
+
+#if WITH_DBUS
+
+dbusThread :: Assistant ()
+dbusThread = do
+	handleerr <- asIO2 onerr
+	runclient <- asIO1 go
+	liftIO $ persistentClient getSystemAddress () handleerr runclient
+  where
+	go client = ifM (checkNetMonitor client)
+		( do
+			callback <- asIO1 connchange
+			liftIO $ do
+				listenNMConnections client callback
+				listenNDConnections client callback
+				listenWicdConnections client callback
+		, do
+			liftAnnex $
+				warning "No known network monitor available through dbus; falling back to polling"
+		)
+	connchange False = do
+		debug ["detected network disconnection"]
+		sendRemoteControl LOSTNET
+	connchange True = do
+		debug ["detected network connection"]
+		handleConnection
+		sendRemoteControl RESUME
+	onerr e _ = do
+		liftAnnex $
+			warning $ UnquotedString $ "lost dbus connection; falling back to polling (" ++ show e ++ ")"
+		{- Wait, in hope that dbus will come back -}
+		liftIO $ threadDelaySeconds (Seconds 60)
+
+{- Examine the list of services connected to dbus, to see if there
+ - are any we can use to monitor network connections. -}
+checkNetMonitor :: Client -> Assistant Bool
+checkNetMonitor client = do
+	running <- liftIO $ filter (`elem` manager_addresses)
+		<$> listServiceNames client
+	case running of
+		[] -> return False
+		(service:_) -> do
+			debug [ "Using running DBUS service"
+				, service
+				, "to monitor network connection events."
+				]
+			return True
+  where
+	manager_addresses = [networkmanager, networkd, wicd]
+	networkmanager = "org.freedesktop.NetworkManager"
+	networkd = "org.freedesktop.network1"
+	wicd = "org.wicd.daemon"
+
+{- Listens for systemd-networkd connections and diconnections.
+ -
+ - Connection example (once fully connected):
+ - [Variant {"OperationalState": Variant "routable"}]
+ -
+ - Disconnection example:
+ - [Variant {"OperationalState": Variant _}]
+ -}
+listenNDConnections :: Client -> (Bool -> IO ()) -> IO ()
+listenNDConnections client setconnected =
+	void $ addMatch client matcher
+		$ \event -> mapM_ handleevent
+			(map dictionaryItems $ mapMaybe fromVariant $ signalBody event)
+  where
+	matcher = matchAny
+		{ matchInterface = Just "org.freedesktop.DBus.Properties"
+		, matchMember = Just "PropertiesChanged"
+		}
+	operational_state_key = toVariant ("OperationalState" :: String)
+	routable = toVariant $ toVariant ("routable" :: String)
+	handleevent m = case lookup operational_state_key m of
+				Just state -> if state == routable
+					then setconnected True
+					else setconnected False
+				Nothing -> noop
+
+{- Listens for NetworkManager connections and diconnections.
+ -
+ - Connection example (once fully connected):
+ - [Variant {"ActivatingConnection": Variant (ObjectPath "/"), "PrimaryConnection": Variant (ObjectPath "/org/freedesktop/NetworkManager/ActiveConnection/34"), "State": Variant 70}]
+ -
+ - Disconnection example:
+ - [Variant {"ActiveConnections": Variant []}]
+ -}
+listenNMConnections :: Client -> (Bool -> IO ()) -> IO ()
+listenNMConnections client setconnected =
+	void $ addMatch client matcher
+		$ \event -> mapM_ handleevent
+			(map dictionaryItems $ mapMaybe fromVariant $ signalBody event)
+  where
+	matcher = matchAny
+		{ matchInterface = Just "org.freedesktop.NetworkManager"
+		, matchMember = Just "PropertiesChanged"
+		}
+	nm_active_connections_key = toVariant ("ActiveConnections" :: String)
+	nm_activatingconnection_key = toVariant ("ActivatingConnection" :: String)
+	noconnections = Just $ toVariant $ toVariant ([] :: [ObjectPath])
+	rootconnection = Just $ toVariant $ toVariant $ objectPath_ "/"
+	handleevent m
+		| lookup nm_active_connections_key m == noconnections =
+			setconnected False
+		| lookup nm_activatingconnection_key m == rootconnection =
+			setconnected True
+		| otherwise = noop
+
+{- Listens for Wicd connections and disconnections.
+ -
+ - Connection example:
+ -   ConnectResultsSent:
+ -     Variant "success"
+ -
+ - Disconnection example:
+ -   StatusChanged
+ -     [Variant 0, Variant [Variant ""]]
+ -}
+listenWicdConnections :: Client -> (Bool -> IO ()) -> IO ()
+listenWicdConnections client setconnected = do
+	match connmatcher $ \event ->
+		when (any (== wicd_success) (signalBody event)) $
+			setconnected True
+	match statusmatcher $ \event -> handleevent (signalBody event)
+  where
+	connmatcher = matchAny
+		{ matchInterface = Just "org.wicd.daemon"
+		, matchMember = Just "ConnectResultsSent"
+		}
+	statusmatcher = matchAny
+		{ matchInterface = Just "org.wicd.daemon"
+		, matchMember = Just "StatusChanged"
+		}
+	wicd_success = toVariant ("success" :: String)
+	wicd_disconnected = toVariant [toVariant ("" :: String)]
+	handleevent status
+		| any (== wicd_disconnected) status = setconnected False
+		| otherwise = noop
+	match matcher a = 
+		void $ addMatch client matcher a
+#endif
+
+handleConnection :: Assistant ()
+handleConnection = do
+	liftIO . sendNotification . networkConnectedNotifier =<< getDaemonStatus
+	reconnectRemotes =<< networkRemotes
+
+{- Network remotes to sync with. -}
+networkRemotes :: Assistant [Remote]
+networkRemotes = filter (isNothing . Remote.localpath) . syncRemotes
+	<$> getDaemonStatus
diff --git a/Assistant/Threads/PairListener.hs b/Assistant/Threads/PairListener.hs
new file mode 100644
index 0000000000..0199b79f84
--- /dev/null
+++ b/Assistant/Threads/PairListener.hs
@@ -0,0 +1,156 @@
+{- git-annex assistant thread to listen for incoming pairing traffic
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Assistant.Threads.PairListener where
+
+import Assistant.Common
+import Assistant.Pairing
+import Assistant.Pairing.Network
+import Assistant.Pairing.MakeRemote
+import Assistant.WebApp (UrlRenderer)
+import Assistant.WebApp.Types
+import Assistant.Alert
+import Assistant.DaemonStatus
+import Utility.ThreadScheduler
+import Git
+
+import Network.Multicast
+import Network.Socket
+import qualified Data.ByteString as B
+import qualified Data.ByteString.UTF8 as BU8
+import qualified Network.Socket.ByteString as B
+import qualified Data.Text as T
+
+pairListenerThread :: UrlRenderer -> NamedThread
+pairListenerThread urlrenderer = namedThread "PairListener" $ do
+	listener <- asIO1 $ go [] []
+	liftIO $ withSocketsDo $
+		runEvery (Seconds 60) $ void $ tryIO $ 
+			listener =<< getsock
+  where
+	{- Note this can crash if there's no network interface,
+	 - or only one like lo that doesn't support multicast. -}
+	getsock = multicastReceiver (multicastAddress IPv4AddrClass) pairingPort
+		
+	go reqs cache sock = liftIO (getmsg sock B.empty) >>= \msg -> case readish (BU8.toString msg) of
+		Nothing -> go reqs cache sock
+		Just m -> do
+			debug ["received", show msg]
+			(pip, verified) <- verificationCheck m
+				=<< (pairingInProgress <$> getDaemonStatus)
+			let wrongstage = maybe False (\p -> pairMsgStage m <= inProgressPairStage p) pip
+			let fromus = maybe False (\p -> remoteSshPubKey (pairMsgData m) == remoteSshPubKey (inProgressPairData p)) pip
+			case (wrongstage, fromus, checkSane (pairMsgData m), pairMsgStage m) of
+				(_, True, _, _) -> do
+					debug ["ignoring message that looped back"]
+					go reqs cache sock
+				(_, _, False, _) -> do
+					liftAnnex $ warning $ UnquotedString $
+						"illegal control characters in pairing message; ignoring (" ++ show (pairMsgData m) ++ ")"
+					go reqs cache sock
+				-- PairReq starts a pairing process, so a
+				-- new one is always heeded, even if
+				-- some other pairing is in process.
+				(_, _, _, PairReq) -> if m `elem` reqs
+					then go reqs (invalidateCache m cache) sock
+					else do
+						pairReqReceived verified urlrenderer m
+						go (m:take 10 reqs) (invalidateCache m cache) sock
+				(True, _, _, _) -> do
+					debug
+						["ignoring out of order message"
+						, show (pairMsgStage m)
+						, "expected"
+						, show (succ . inProgressPairStage <$> pip)
+						]
+					go reqs cache sock
+				(_, _, _, PairAck) -> do
+					cache' <- pairAckReceived verified pip m cache
+					go reqs cache' sock
+				(_,_ , _, PairDone) -> do
+					pairDoneReceived verified pip m
+					go reqs cache sock
+
+	{- As well as verifying the message using the shared secret,
+	 - check its UUID against the UUID we have stored. If
+	 - they're the same, someone is sending bogus messages,
+	 - which could be an attempt to brute force the shared secret. -}
+	verificationCheck _ Nothing = return (Nothing, False)
+	verificationCheck m (Just pip)
+		| not verified && sameuuid = do
+			liftAnnex $ warning
+				"detected possible pairing brute force attempt; disabled pairing"
+			stopSending pip
+			return (Nothing, False)
+		| otherwise = return (Just pip, verified && sameuuid)
+	  where
+		verified = verifiedPairMsg m pip
+		sameuuid = pairUUID (inProgressPairData pip) == pairUUID (pairMsgData m)
+
+	{- PairReqs invalidate the cache of recently finished pairings.
+	 - This is so that, if a new pairing is started with the
+	 - same secret used before, a bogus PairDone is not sent. -}
+	invalidateCache msg = filter (not . verifiedPairMsg msg)
+
+	getmsg sock c = do
+		(msg, _) <- B.recvFrom sock chunksz
+		if B.length msg < chunksz
+			then return $ c <> msg
+			else getmsg sock $ c <> msg
+	  where
+		chunksz = 1024
+
+{- Show an alert when a PairReq is seen. -}
+pairReqReceived :: Bool -> UrlRenderer -> PairMsg -> Assistant ()
+pairReqReceived True _ _ = noop -- ignore our own PairReq
+pairReqReceived False urlrenderer msg = do
+	button <- mkAlertButton True (T.pack "Respond") urlrenderer (FinishLocalPairR msg)
+	void $ addAlert $ pairRequestReceivedAlert repo button
+  where
+	repo = pairRepo msg
+
+{- When a verified PairAck is seen, a host is ready to pair with us, and has
+ - already configured our ssh key. Stop sending PairReqs, finish the pairing,
+ - and send a single PairDone. -}
+pairAckReceived :: Bool -> Maybe PairingInProgress -> PairMsg -> [PairingInProgress] -> Assistant [PairingInProgress]
+pairAckReceived True (Just pip) msg cache = do
+	stopSending pip
+	repodir <- fromRawFilePath . repoPath <$> liftAnnex gitRepo
+	liftIO $ setupAuthorizedKeys msg repodir
+	finishedLocalPairing msg (inProgressSshKeyPair pip)
+	startSending pip PairDone $ multicastPairMsg
+		(Just 1) (inProgressSecret pip) (inProgressPairData pip)
+	return $ pip : take 10 cache
+{- A stale PairAck might also be seen, after we've finished pairing.
+ - Perhaps our PairDone was not received. To handle this, we keep
+ - a cache of recently finished pairings, and re-send PairDone in
+ - response to stale PairAcks for them. -}
+pairAckReceived _ _ msg cache = do
+	let pips = filter (verifiedPairMsg msg) cache
+	unless (null pips) $
+		forM_ pips $ \pip ->
+			startSending pip PairDone $ multicastPairMsg
+				(Just 1) (inProgressSecret pip) (inProgressPairData pip)
+	return cache
+
+{- If we get a verified PairDone, the host has accepted our PairAck, and
+ - has paired with us. Stop sending PairAcks, and finish pairing with them.
+ -
+ - TODO: Should third-party hosts remove their pair request alert when they
+ - see a PairDone?
+ - Complication: The user could have already clicked on the alert and be
+ - entering the secret. Would be better to start a fresh pair request in this
+ - situation.
+ -}
+pairDoneReceived :: Bool -> Maybe PairingInProgress -> PairMsg -> Assistant ()
+pairDoneReceived False _ _ = noop -- not verified
+pairDoneReceived True Nothing _ = noop -- not in progress
+pairDoneReceived True (Just pip) msg = do
+	stopSending pip
+	finishedLocalPairing msg (inProgressSshKeyPair pip)
diff --git a/Assistant/Threads/ProblemFixer.hs b/Assistant/Threads/ProblemFixer.hs
new file mode 100644
index 0000000000..2b5829037f
--- /dev/null
+++ b/Assistant/Threads/ProblemFixer.hs
@@ -0,0 +1,73 @@
+{- git-annex assistant thread to handle fixing problems with repositories
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Threads.ProblemFixer (
+	problemFixerThread
+) where
+
+import Assistant.Common
+import Assistant.Types.RepoProblem
+import Assistant.RepoProblem
+import Assistant.Types.UrlRenderer
+import Assistant.Alert
+import Remote
+import qualified Types.Remote as Remote
+import qualified Git.Fsck
+import Assistant.Repair
+import qualified Git
+import Annex.UUID
+import Utility.ThreadScheduler
+
+{- Waits for problems with a repo, and tries to fsck the repo and repair
+ - the problem. -}
+problemFixerThread :: UrlRenderer -> NamedThread
+problemFixerThread urlrenderer = namedThread "ProblemFixer" $
+	go =<< getRepoProblems
+  where
+	go problems = do
+		mapM_ (handleProblem urlrenderer) problems
+		liftIO $ threadDelaySeconds (Seconds 60)
+		-- Problems may have been re-reported while they were being
+		-- fixed, so ignore those. If a new unique problem happened
+		-- 60 seconds after the last was fixed, we're unlikely
+		-- to do much good anyway.
+		go =<< filter (\p -> not (any (sameRepoProblem p) problems))
+			<$> getRepoProblems
+
+handleProblem :: UrlRenderer -> RepoProblem -> Assistant ()
+handleProblem urlrenderer repoproblem = do
+	fixed <- ifM ((==) (problemUUID repoproblem) <$> liftAnnex getUUID)
+		( handleLocalRepoProblem urlrenderer
+		, maybe (return False) (handleRemoteProblem urlrenderer)
+			=<< liftAnnex (remoteFromUUID $ problemUUID repoproblem)
+		)
+	when fixed $
+		liftIO $ afterFix repoproblem
+
+handleRemoteProblem :: UrlRenderer -> Remote -> Assistant Bool
+handleRemoteProblem urlrenderer rmt = do
+	repo <- liftAnnex $ Remote.getRepo rmt
+	handleRemoteProblem' repo urlrenderer rmt
+
+handleRemoteProblem' :: Git.Repo -> UrlRenderer -> Remote -> Assistant Bool
+handleRemoteProblem' repo urlrenderer rmt
+	| Git.repoIsLocal repo && not (Git.repoIsLocalUnknown repo) =
+		ifM (liftAnnex $ checkAvailable True rmt)
+			( do
+				fixedlocks <- repairStaleGitLocks repo
+				fsckresults <- showFscking urlrenderer (Just rmt) $ tryNonAsync $
+					Git.Fsck.findBroken True True repo
+				repaired <- repairWhenNecessary urlrenderer (Remote.uuid rmt) (Just rmt) fsckresults
+				return $ fixedlocks || repaired
+			, return False
+			)
+	| otherwise = return False
+
+{- This is not yet used, and should probably do a fsck. -}
+handleLocalRepoProblem :: UrlRenderer -> Assistant Bool
+handleLocalRepoProblem _urlrenderer = do
+	repairStaleGitLocks =<< liftAnnex gitRepo
diff --git a/Assistant/Threads/Pusher.hs b/Assistant/Threads/Pusher.hs
new file mode 100644
index 0000000000..3d7b6345c0
--- /dev/null
+++ b/Assistant/Threads/Pusher.hs
@@ -0,0 +1,50 @@
+{- git-annex assistant git pushing thread
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Threads.Pusher where
+
+import Assistant.Common
+import Assistant.Commits
+import Assistant.Pushes
+import Assistant.DaemonStatus
+import Assistant.Sync
+import Utility.ThreadScheduler
+import qualified Remote
+import qualified Types.Remote as Remote
+
+{- This thread retries pushes that failed before. -}
+pushRetryThread :: NamedThread
+pushRetryThread = namedThread "PushRetrier" $ runEvery (Seconds halfhour) <~> do
+	-- We already waited half an hour, now wait until there are failed
+	-- pushes to retry.
+	topush <- getFailedPushesBefore (fromIntegral halfhour)
+		=<< getAssistant failedPushMap
+	unless (null topush) $ do
+		debug ["retrying", show (length topush), "failed pushes"]
+		void $ pushToRemotes topush
+  where
+	halfhour = 1800
+
+{- This thread pushes git commits out to remotes soon after they are made. -}
+pushThread :: NamedThread
+pushThread = namedThread "Pusher" $ runEvery (Seconds 2) <~> do
+	-- We already waited two seconds as a simple rate limiter.
+	-- Next, wait until at least one commit has been made
+	void getCommits
+	-- Now see if now's a good time to push.
+	void $ pushToRemotes =<< pushTargets
+
+{- We want to avoid pushing to remotes that are marked readonly.
+ -
+ - Also, avoid pushing to local remotes we can easily tell are not available,
+ - to avoid ugly messages when a removable drive is not attached.
+ -}
+pushTargets :: Assistant [Remote]
+pushTargets = liftAnnex . filterM (Remote.checkAvailable True)
+	=<< candidates <$> getDaemonStatus
+  where
+	candidates = filter (not . Remote.readonly) . syncGitRemotes
diff --git a/Assistant/Threads/RemoteControl.hs b/Assistant/Threads/RemoteControl.hs
new file mode 100644
index 0000000000..51f5e4b9b4
--- /dev/null
+++ b/Assistant/Threads/RemoteControl.hs
@@ -0,0 +1,128 @@
+{- git-annex assistant communication with remotedaemon
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Threads.RemoteControl where
+
+import Assistant.Common
+import RemoteDaemon.Types
+import Annex.Path
+import Utility.Batch
+import Utility.SimpleProtocol
+import Assistant.Alert
+import Assistant.Alert.Utility
+import Assistant.DaemonStatus
+import qualified Git
+import qualified Git.Types as Git
+import qualified Remote
+import qualified Types.Remote as Remote
+
+import Control.Concurrent
+import Control.Concurrent.Async
+import Network.URI
+import qualified Data.Map as M
+import qualified Data.Set as S
+
+remoteControlThread :: NamedThread
+remoteControlThread = namedThread "RemoteControl" $ do
+	program <- liftIO programPath
+	(cmd, params) <- liftIO $ toBatchCommand
+		(program, [Param "remotedaemon", Param "--foreground"])
+	let p = proc cmd (toCommand params)
+	bracket (setup p) cleanup (go p)
+  where
+	setup p = liftIO $ createProcess $ p
+		{ std_in = CreatePipe
+		, std_out = CreatePipe
+		}
+	cleanup = liftIO . cleanupProcess
+
+	go p (Just toh, Just fromh, _, pid) = do
+		urimap <- liftIO . newMVar =<< liftAnnex getURIMap
+
+		controller <- asIO $ remoteControllerThread toh
+		responder <- asIO $ remoteResponderThread fromh urimap
+
+		-- run controller and responder until the remotedaemon dies
+		liftIO $ void $ tryNonAsync $
+			controller `concurrently` responder
+		debug ["remotedaemon exited"]
+		liftIO $ forceSuccessProcess p pid	
+	go _ _ = error "internal"
+		
+
+-- feed from the remoteControl channel into the remotedaemon
+remoteControllerThread :: Handle -> Assistant ()
+remoteControllerThread toh = do
+	clicker <- getAssistant remoteControl
+	forever $ do
+		msg <- liftIO $ readChan clicker
+		debug [show msg]
+		liftIO $ do
+			hPutStrLn toh $ unwords $ formatMessage msg
+			hFlush toh
+
+-- read status messages emitted by the remotedaemon and handle them
+remoteResponderThread :: Handle -> MVar (M.Map URI Remote) -> Assistant ()
+remoteResponderThread fromh urimap = go M.empty
+  where
+	go syncalerts = do
+		l <- liftIO $ hGetLine fromh
+		debug [l]
+		case parseMessage l of
+			Just (CONNECTED uri) -> changeconnected S.insert uri
+			Just (DISCONNECTED uri) -> changeconnected S.delete uri
+			Just (SYNCING uri) -> withr uri $ \r ->
+				if M.member (Remote.uuid r) syncalerts
+					then go syncalerts
+					else do
+						i <- addAlert $ syncAlert [r]
+						go (M.insert (Remote.uuid r) i syncalerts)
+			Just (DONESYNCING uri status) -> withr uri $ \r ->
+				case M.lookup (Remote.uuid r) syncalerts of
+					Nothing -> cont
+					Just i -> do
+						let (succeeded, failed) = if status
+							then ([r], [])
+							else ([], [r])
+						updateAlertMap $ mergeAlert i $
+							syncResultAlert succeeded failed
+						go (M.delete (Remote.uuid r) syncalerts)
+			Just (WARNING (RemoteURI uri) msg) -> do
+				void $ addAlert $
+					warningAlert ("RemoteControl "++ show uri) msg
+				cont
+			Nothing -> do
+				debug ["protocol error from remotedaemon: ", l]
+				cont
+	  where
+		cont = go syncalerts
+		withr uri = withRemote uri urimap cont
+		changeconnected sm uri = withr uri $ \r -> do
+			changeCurrentlyConnected $ sm $ Remote.uuid r
+			cont
+
+getURIMap :: Annex (M.Map URI Remote)
+getURIMap = Remote.remoteMap' id (\r -> mkk . Git.location <$> Remote.getRepo r)
+  where
+	mkk (Git.Url u) = Just u
+	mkk _ = Nothing
+
+withRemote
+	:: RemoteURI
+	-> MVar (M.Map URI Remote)
+	-> Assistant a
+	-> (Remote -> Assistant a)
+	-> Assistant a
+withRemote (RemoteURI uri) remotemap noremote a = do
+	m <- liftIO $ readMVar remotemap
+	case M.lookup uri m of
+		Just r -> a r
+		Nothing -> do
+			{- Reload map, in case a new remote has been added. -}
+			m' <- liftAnnex getURIMap
+			void $ liftIO $ swapMVar remotemap $ m'
+			maybe noremote a (M.lookup uri m')
diff --git a/Assistant/Threads/SanityChecker.hs b/Assistant/Threads/SanityChecker.hs
new file mode 100644
index 0000000000..563e038e78
--- /dev/null
+++ b/Assistant/Threads/SanityChecker.hs
@@ -0,0 +1,274 @@
+{- git-annex assistant sanity checker
+ -
+ - Copyright 2012, 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Assistant.Threads.SanityChecker (
+	sanityCheckerStartupThread,
+	sanityCheckerDailyThread,
+	sanityCheckerHourlyThread
+) where
+
+import Assistant.Common
+import Assistant.DaemonStatus
+import Assistant.Alert
+import Assistant.Repair
+import Assistant.Drop
+import Assistant.Ssh
+import Assistant.TransferQueue
+import Assistant.Types.UrlRenderer
+import Assistant.Restart
+import qualified Annex.Branch
+import qualified Git
+import qualified Git.LsFiles
+import qualified Git.Command.Batch
+import qualified Git.Config
+import Utility.ThreadScheduler
+import qualified Assistant.Threads.Watcher as Watcher
+import Utility.Batch
+import Utility.NotificationBroadcaster
+import Utility.HumanTime
+import Utility.Tense
+import Git.Repair
+import Git.Index
+import Assistant.Unused
+import Logs.Unused
+import Types.Transfer
+import Annex.Path
+import Annex.Tmp
+import qualified Annex
+import qualified Utility.RawFilePath as R
+#ifdef WITH_WEBAPP
+import Assistant.WebApp.Types
+#endif
+#ifndef mingw32_HOST_OS
+import Utility.LogFile
+import Utility.DiskFree
+#endif
+
+import Data.Time.Clock.POSIX
+import qualified Data.Text as T
+import System.PosixCompat.Files (statusChangeTime, isSymbolicLink)
+
+{- This thread runs once at startup, and most other threads wait for it
+ - to finish. (However, the webapp thread does not, to prevent the UI
+ - being nonresponsive.) -}
+sanityCheckerStartupThread :: Maybe Duration -> NamedThread
+sanityCheckerStartupThread startupdelay = namedThreadUnchecked "SanityCheckerStartup" $ do
+	{- Stale git locks can prevent commits from happening, etc. -}
+	void $ repairStaleGitLocks =<< liftAnnex gitRepo
+
+	{- A corrupt index file can prevent the assistant from working at
+	 - all, so detect and repair. -}
+	ifM (not <$> liftAnnex (inRepo checkIndexFast))
+		( do
+			debug ["corrupt index file found at startup; removing and restaging"]
+			liftAnnex $ inRepo $ removeWhenExistsWith R.removeLink . indexFile
+			{- Normally the startup scan avoids re-staging files,
+			 - but with the index deleted, everything needs to be
+			 - restaged. -}
+			modifyDaemonStatus_ $ \s -> s { forceRestage = True }
+		, whenM (liftAnnex $ inRepo missingIndex) $ do
+			debug ["no index file; restaging"]
+			modifyDaemonStatus_ $ \s -> s { forceRestage = True }
+		)
+	{- If the git-annex index file is corrupt, it's ok to remove it;
+	 - the data from the git-annex branch will be used, and the index
+	 - will be automatically regenerated. -}
+	unlessM (liftAnnex $ Annex.Branch.withIndex $ inRepo $ Git.Repair.checkIndexFast) $ do
+		debug ["corrupt annex/index file found at startup; removing"]
+		liftAnnex $ liftIO . removeWhenExistsWith R.removeLink =<< fromRepo gitAnnexIndex
+
+	{- Fix up ssh remotes set up by past versions of the assistant. -}
+	liftIO $ fixUpSshRemotes
+
+	{- Clean up old temp files. -}
+	void $ liftAnnex $ tryNonAsync $ cleanupOtherTmp
+
+	{- If there's a startup delay, it's done here. -}
+	liftIO $ maybe noop (threadDelaySeconds . Seconds . fromIntegral . durationSeconds) startupdelay
+
+	{- Notify other threads that the startup sanity check is done. -}
+	status <- getDaemonStatus
+	liftIO $ sendNotification $ startupSanityCheckNotifier status
+
+{- This thread wakes up hourly for inxepensive frequent sanity checks. -}
+sanityCheckerHourlyThread :: NamedThread
+sanityCheckerHourlyThread = namedThread "SanityCheckerHourly" $ forever $ do
+	liftIO $ threadDelaySeconds $ Seconds oneHour
+	hourlyCheck
+
+{- This thread wakes up daily to make sure the tree is in good shape. -}
+sanityCheckerDailyThread :: UrlRenderer -> NamedThread
+sanityCheckerDailyThread urlrenderer = namedThread "SanityCheckerDaily" $ forever $ do
+	waitForNextCheck
+
+	debug ["starting sanity check"]
+	void $ alertWhile sanityCheckAlert go
+	debug ["sanity check complete"]
+  where
+	go = do
+		modifyDaemonStatus_ $ \s -> s { sanityCheckRunning = True }
+
+		now <- liftIO getPOSIXTime -- before check started
+		r <- either showerr return 
+			=<< (tryIO . batch) <~> dailyCheck urlrenderer
+
+		modifyDaemonStatus_ $ \s -> s
+			{ sanityCheckRunning = False
+			, lastSanityCheck = Just now
+			}
+
+		return r
+
+	showerr e = do
+		liftAnnex $ warning $ UnquotedString $ show e
+		return False
+
+{- Only run one check per day, from the time of the last check. -}
+waitForNextCheck :: Assistant ()
+waitForNextCheck = do
+	v <- lastSanityCheck <$> getDaemonStatus
+	now <- liftIO getPOSIXTime
+	liftIO $ threadDelaySeconds $ Seconds $ calcdelay now v
+  where
+	calcdelay _ Nothing = oneDay
+	calcdelay now (Just lastcheck)
+		| lastcheck < now = max oneDay $
+			oneDay - truncate (now - lastcheck)
+		| otherwise = oneDay
+
+{- It's important to stay out of the Annex monad as much as possible while
+ - running potentially expensive parts of this check, since remaining in it
+ - will block the watcher. -}
+dailyCheck :: UrlRenderer -> Assistant Bool
+dailyCheck urlrenderer = do
+	checkRepoExists
+
+	g <- liftAnnex gitRepo
+	batchmaker <- liftIO getBatchCommandMaker
+
+	-- Find old unstaged symlinks, and add them to git.
+	(unstaged, cleanup) <- liftIO $ Git.LsFiles.notInRepo [] False ["."] g
+	now <- liftIO getPOSIXTime
+	forM_ unstaged $ \file -> do
+		ms <- liftIO $ catchMaybeIO $ R.getSymbolicLinkStatus file
+		case ms of
+			Just s	| toonew (statusChangeTime s) now -> noop
+				| isSymbolicLink s -> addsymlink (fromRawFilePath file) ms
+			_ -> noop
+	liftIO $ void cleanup
+
+	{- Allow git-gc to run once per day. More frequent gc is avoided
+	 - by default to avoid slowing things down. Only run repacks when 100x
+	 - the usual number of loose objects are present; we tend
+	 - to have a lot of small objects and they should not be a
+	 - significant size. -}
+	when (Git.Config.getMaybe "gc.auto" g == Just "0") $
+		liftIO $ void $ Git.Command.Batch.run batchmaker
+			[ Param "-c", Param "gc.auto=670000"
+			, Param "gc"
+			, Param "--auto"
+			] g
+
+	{- Check if the unused files found last time have been dealt with. -}
+	checkOldUnused urlrenderer
+
+	{- Run git-annex unused once per day. This is run as a separate
+	 - process to stay out of the annex monad and so it can run as a
+	 - batch job. -}
+	program <- liftIO programPath
+	let (program', params') = batchmaker (program, [Param "unused"])
+	void $ liftIO $ boolSystem program' params'
+	{- Invalidate unused keys cache, and queue transfers of all unused
+	 - keys, or if no transfers are called for, drop them. -}
+	unused <- liftAnnex unusedKeys'
+	void $ liftAnnex $ setUnusedKeys unused
+	forM_ unused $ \k -> do
+		unlessM (queueTransfers "unused" Later k (AssociatedFile Nothing) Upload) $
+			handleDrops "unused" True k (AssociatedFile Nothing) []
+
+	return True
+  where
+	toonew timestamp now = now < (realToFrac (timestamp + slop) :: POSIXTime)
+	slop = fromIntegral tenMinutes
+	insanity msg = do
+		liftAnnex $ warning (UnquotedString msg)
+		void $ addAlert $ sanityCheckFixAlert msg
+	addsymlink file s = do
+		Watcher.runHandler Watcher.onAddSymlink file s
+		insanity $ "found unstaged symlink: " ++ file
+
+hourlyCheck :: Assistant ()
+hourlyCheck = do
+	checkRepoExists
+#ifndef mingw32_HOST_OS
+	checkLogSize 0
+#else
+	noop
+#endif
+
+#ifndef mingw32_HOST_OS
+{- Rotate logs once when total log file size is > 2 mb.
+ -
+ - If total log size is larger than the amount of free disk space,
+ - continue rotating logs until size is < 2 mb, even if this
+ - results in immediately losing the just logged data.
+ -}
+checkLogSize :: Int -> Assistant ()
+checkLogSize n = do
+	f <- liftAnnex $ fromRawFilePath <$> fromRepo gitAnnexDaemonLogFile
+	logs <- liftIO $ listLogs f
+	totalsize <- liftIO $ sum <$> mapM (getFileSize . toRawFilePath) logs
+	when (totalsize > 2 * oneMegabyte) $ do
+		debug ["Rotated logs due to size:", show totalsize]
+		liftIO $ openLog f >>= handleToFd >>= redirLog
+		when (n < maxLogs + 1) $ do
+			df <- liftIO $ getDiskFree $ takeDirectory f
+			case df of
+				Just free
+					| free < fromIntegral totalsize ->
+						checkLogSize (n + 1)
+				_ -> noop
+  where
+	oneMegabyte :: Integer
+	oneMegabyte = 1000000
+#endif
+
+oneHour :: Int
+oneHour = 60 * 60
+
+oneDay :: Int
+oneDay = 24 * oneHour
+
+{- If annex.expireunused is set, find any keys that have lingered unused
+ - for the specified duration, and remove them.
+ -
+ - Otherwise, check to see if unused keys are piling up, and let the user
+ - know. -}
+checkOldUnused :: UrlRenderer -> Assistant ()
+checkOldUnused urlrenderer = go =<< annexExpireUnused <$> liftAnnex Annex.getGitConfig
+  where
+	go (Just Nothing) = noop
+	go (Just (Just expireunused)) = expireUnused (Just expireunused)
+	go Nothing = maybe noop promptconfig =<< describeUnusedWhenBig
+
+	promptconfig msg = 
+#ifdef WITH_WEBAPP
+		do
+			button <- mkAlertButton True (T.pack "Configure") urlrenderer ConfigUnusedR
+			void $ addAlert $ unusedFilesAlert [button] $ T.unpack $ renderTense Present msg
+#else
+		debug [show $ renderTense Past msg]
+#endif
+
+checkRepoExists :: Assistant ()
+checkRepoExists = do
+	g <- liftAnnex gitRepo
+	liftIO $ unlessM (doesDirectoryExist $ fromRawFilePath $ Git.repoPath g) $
+		terminateSelf
diff --git a/Assistant/Threads/TransferPoller.hs b/Assistant/Threads/TransferPoller.hs
new file mode 100644
index 0000000000..067bd0b022
--- /dev/null
+++ b/Assistant/Threads/TransferPoller.hs
@@ -0,0 +1,56 @@
+{- git-annex assistant transfer polling thread
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Threads.TransferPoller where
+
+import Assistant.Common
+import Assistant.DaemonStatus
+import Types.Transfer
+import Logs.Transfer
+import Utility.NotificationBroadcaster
+import qualified Assistant.Threads.TransferWatcher as TransferWatcher
+
+import Control.Concurrent
+import qualified Data.Map as M
+
+{- This thread polls the status of ongoing transfers, determining how much
+ - of each transfer is complete. -}
+transferPollerThread :: NamedThread
+transferPollerThread = namedThread "TransferPoller" $ do
+	g <- liftAnnex gitRepo
+	tn <- liftIO . newNotificationHandle True =<<
+		transferNotifier <$> getDaemonStatus
+	forever $ do
+		liftIO $ threadDelay 500000 -- 0.5 seconds
+		ts <- currentTransfers <$> getDaemonStatus
+		if M.null ts
+			-- block until transfers running
+			then liftIO $ waitNotification tn
+			else mapM_ (poll g) $ M.toList ts
+  where
+	poll g (t, info)
+		{- Downloads are polled by checking the size of the
+		 - temp file being used for the transfer. -}
+		| transferDirection t == Download = do
+			let f = gitAnnexTmpObjectLocation (transferKey t) g
+			sz <- liftIO $ catchMaybeIO $ getFileSize f
+			newsize t info sz
+		{- Uploads don't need to be polled for when the TransferWatcher
+		 - thread can track file modifications. -}
+		| TransferWatcher.watchesTransferSize = noop
+		{- Otherwise, this code polls the upload progress
+		 - by reading the transfer info file. -}
+		| otherwise = do
+			let (f, _, _) = transferFileAndLockFile t g
+			mi <- liftIO $ catchDefaultIO Nothing $
+				readTransferInfoFile Nothing (fromRawFilePath f)
+			maybe noop (newsize t info . bytesComplete) mi
+
+	newsize t info sz
+		| bytesComplete info /= sz && isJust sz =
+			alterTransferInfo t $ \i -> i { bytesComplete = sz }
+		| otherwise = noop
diff --git a/Assistant/Threads/TransferScanner.hs b/Assistant/Threads/TransferScanner.hs
new file mode 100644
index 0000000000..970516a380
--- /dev/null
+++ b/Assistant/Threads/TransferScanner.hs
@@ -0,0 +1,196 @@
+{- git-annex assistant thread to scan remotes to find needed transfers
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Threads.TransferScanner where
+
+import Assistant.Common
+import Assistant.Types.ScanRemotes
+import Assistant.ScanRemotes
+import Assistant.TransferQueue
+import Assistant.DaemonStatus
+import Assistant.Drop
+import Assistant.Sync
+import Assistant.DeleteRemote
+import Assistant.Types.UrlRenderer
+import Types.Transfer
+import Logs.Transfer
+import Logs.Location
+import Logs.Group
+import qualified Remote
+import qualified Types.Remote as Remote
+import Utility.ThreadScheduler
+import Utility.NotificationBroadcaster
+import Utility.Batch
+import qualified Git.LsFiles as LsFiles
+import Annex.WorkTree
+import Annex.Content
+import Annex.Wanted
+import CmdLine.Action
+import Types.Command
+
+import qualified Data.Set as S
+import Control.Concurrent
+
+{- This thread waits until a remote needs to be scanned, to find transfers
+ - that need to be made, to keep data in sync.
+ -}
+transferScannerThread :: UrlRenderer -> NamedThread
+transferScannerThread urlrenderer = namedThread "TransferScanner" $ do
+	startupScan
+	go S.empty
+  where
+	go scanned = do
+		scanrunning False
+		liftIO $ threadDelaySeconds (Seconds 2)
+		(rs, infos) <- unzip <$> getScanRemote
+		scanrunning True
+		if any fullScan infos || any (`S.notMember` scanned) rs
+			then do
+				expensiveScan urlrenderer rs
+				go $ scanned `S.union` S.fromList rs
+			else do
+				mapM_ failedTransferScan rs
+				go scanned
+	scanrunning b = do
+		ds <- modifyDaemonStatus $ \s -> 
+			(s { transferScanRunning = b }, s)
+		liftIO $ sendNotification $ transferNotifier ds
+		
+	{- All git remotes are synced, all exports are updated,
+	 - and all available remotes are scanned in full on startup,
+	 - for multiple reasons, including:
+	 -
+	 - * This may be the first run, and there may be remotes
+	 -   already in place, that need to be synced.
+	 - * Changes may have been made last time we run, but remotes were
+	 -   not available to be synced with.
+	 - * Changes may have been made to remotes while we were down.
+	 - * We may have run before, and scanned a remote, but
+	 -   only been in a subdirectory of the git remote, and so
+	 -   not synced it all.
+	 - * We may have run before, and had transfers queued,
+	 -   and then the system (or us) crashed, and that info was
+	 -   lost.
+	 - * A remote may be in the unwanted group, and this is a chance
+	 -   to determine if the remote has been emptied.
+	 -}
+	startupScan = do
+		reconnectRemotes =<< syncGitRemotes <$> getDaemonStatus
+		addScanRemotes True =<< scannableRemotes
+
+{- This is a cheap scan for failed transfers involving a remote. -}
+failedTransferScan :: Remote -> Assistant ()
+failedTransferScan r = do
+	failed <- liftAnnex $ clearFailedTransfers (Remote.uuid r)
+	mapM_ retry failed
+  where
+	retry (t, info)
+		| transferDirection t == Download =
+			{- Check if the remote still has the key.
+			 - If not, relies on the expensiveScan to
+			 - get it queued from some other remote. -}
+			whenM (liftAnnex $ remoteHas r $ transferKey t) $
+				requeue t info
+		| otherwise =
+			{- The Transferrer checks when uploading
+			 - that the remote doesn't already have the
+			 - key, so it's not redundantly checked here. -}
+			requeue t info
+	requeue t info = queueTransferWhenSmall "retrying failed transfer" (associatedFile info) t r
+	
+{- This is a expensive scan through the full git work tree, finding
+ - files to transfer. The scan is blocked when the transfer queue gets
+ - too large. 
+ -
+ - This also finds files that are present either here or on a remote
+ - but that are not preferred content, and drops them. Searching for files
+ - to drop is done concurrently with the scan for transfers.
+ -
+ - TODO: It would be better to first drop as much as we can, before
+ - transferring much, to minimise disk use.
+ - 
+ - During the scan, we'll also check if any unwanted repositories are empty,
+ - and can be removed. While unrelated, this is a cheap place to do it,
+ - since we need to look at the locations of all keys anyway.
+ -}
+expensiveScan :: UrlRenderer -> [Remote] -> Assistant ()
+expensiveScan urlrenderer rs = batch <~> do
+	debug ["starting scan of", show visiblers]
+
+	let us = map Remote.uuid rs
+
+	mapM_ (liftAnnex . clearFailedTransfers) us
+
+	unwantedrs <- liftAnnex $ S.fromList
+		<$> filterM inUnwantedGroup us
+
+	g <- liftAnnex gitRepo
+	(files, cleanup) <- liftIO $ LsFiles.inRepo [] [] g
+	removablers <- scan unwantedrs files
+	void $ liftIO cleanup
+
+	debug ["finished scan of", show visiblers]
+
+	remove <- asIO1 $ removableRemote urlrenderer
+	liftIO $ mapM_ (void . tryNonAsync . remove) $ S.toList removablers
+  where
+	visiblers = let rs' = filter (not . Remote.readonly) rs
+		in if null rs' then rs else rs'
+
+	scan unwanted [] = return unwanted
+	scan unwanted (f:fs) = do
+		(unwanted', ts) <- maybe
+			(return (unwanted, []))
+			(findtransfers f unwanted)
+				=<< liftAnnex (lookupKey f)
+		mapM_ (enqueue f) ts
+
+		{- Delay for a short time to avoid using too much CPU. -}
+		liftIO $ threadDelay $ fromIntegral $ oneSecond `div` 200
+
+		scan unwanted' fs
+
+	enqueue f (r, t) =
+		queueTransferWhenSmall "expensive scan found missing object"
+			(AssociatedFile (Just f)) t r
+	findtransfers f unwanted key = do
+		let af = AssociatedFile (Just f)
+		locs <- liftAnnex $ loggedLocations key
+		present <- liftAnnex $ inAnnex key
+		let slocs = S.fromList locs
+		
+		{- The remotes may have changed since this scan began. -}
+		syncrs <- syncDataRemotes <$> getDaemonStatus
+		let use l a = mapMaybe (a key slocs) . l <$> getDaemonStatus
+
+		liftAnnex $ handleDropsFrom locs syncrs
+			"expensive scan found too many copies of object"
+			present key af (SeekInput []) [] callCommandAction
+		ts <- if present
+			then liftAnnex . filterM (wantGetBy True (Just key) af . Remote.uuid . fst)
+				=<< use syncDataRemotes (genTransfer Upload False)
+			else ifM (liftAnnex $ wantGet True (Just key) af)
+				( use downloadRemotes (genTransfer Download True) , return [] )
+		let unwanted' = S.difference unwanted slocs
+		return (unwanted', ts)
+
+-- Both syncDataRemotes and exportRemotes can be scanned.
+-- The downloadRemotes list contains both.
+scannableRemotes :: Assistant [Remote]
+scannableRemotes = downloadRemotes <$> getDaemonStatus
+
+genTransfer :: Direction -> Bool -> Key -> S.Set UUID -> Remote -> Maybe (Remote, Transfer)
+genTransfer direction want key slocs r
+	| direction == Upload && Remote.readonly r = Nothing
+	| S.member (Remote.uuid r) slocs == want = Just
+		(r, Transfer direction (Remote.uuid r) (fromKey id key))
+	| otherwise = Nothing
+
+remoteHas :: Remote -> Key -> Annex Bool
+remoteHas r key = elem
+	<$> pure (Remote.uuid r)
+	<*> loggedLocations key
diff --git a/Assistant/Threads/TransferWatcher.hs b/Assistant/Threads/TransferWatcher.hs
new file mode 100644
index 0000000000..d692a3ffd0
--- /dev/null
+++ b/Assistant/Threads/TransferWatcher.hs
@@ -0,0 +1,108 @@
+{- git-annex assistant transfer watching thread
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Threads.TransferWatcher where
+
+import Assistant.Common
+import Assistant.DaemonStatus
+import Assistant.TransferSlots
+import Types.Transfer
+import Logs.Transfer
+import Utility.DirWatcher
+import Utility.DirWatcher.Types
+import qualified Remote
+import qualified Annex
+import Annex.Perms
+
+import Control.Concurrent
+import qualified Data.Map as M
+
+{- This thread watches for changes to the gitAnnexTransferDir,
+ - and updates the DaemonStatus's map of ongoing transfers. -}
+transferWatcherThread :: NamedThread
+transferWatcherThread = namedThread "TransferWatcher" $ do
+	dir <- liftAnnex $ gitAnnexTransferDir <$> gitRepo
+	liftAnnex $ createAnnexDirectory dir
+	let hook a = Just <$> asIO2 (runHandler a)
+	addhook <- hook onAdd
+	delhook <- hook onDel
+	modifyhook <- hook onModify
+	errhook <- hook onErr
+	let hooks = mkWatchHooks
+		{ addHook = addhook
+		, delHook = delhook
+		, modifyHook = modifyhook
+		, errHook = errhook
+		}
+	void $ liftIO $ watchDir (fromRawFilePath dir) (const False) True hooks id
+	debug ["watching for transfers"]
+
+type Handler = FilePath -> Assistant ()
+
+{- Runs an action handler.
+ -
+ - Exceptions are ignored, otherwise a whole thread could be crashed.
+ -}
+runHandler :: Handler -> FilePath -> Maybe FileStatus -> Assistant ()
+runHandler handler file _filestatus =
+	either (liftIO . print) (const noop) =<< tryIO <~> handler file
+
+{- Called when there's an error with inotify. -}
+onErr :: Handler
+onErr = giveup
+
+{- Called when a new transfer information file is written. -}
+onAdd :: Handler
+onAdd file = case parseTransferFile file of
+	Nothing -> noop
+	Just t -> go t =<< liftAnnex (checkTransfer t)
+  where
+	go _ Nothing = noop -- transfer already finished
+	go t (Just info) = do
+		qp <- liftAnnex $ coreQuotePath <$> Annex.getGitConfig
+		debug [ "transfer starting:", describeTransfer qp t info ]
+		r <- liftAnnex $ Remote.remoteFromUUID $ transferUUID t
+		updateTransferInfo t info { transferRemote = r }
+
+{- Called when a transfer information file is updated.
+ -
+ - The only thing that should change in the transfer info is the
+ - bytesComplete, so that's the only thing updated in the DaemonStatus. -}
+onModify :: Handler
+onModify file = case parseTransferFile file of
+	Nothing -> noop
+	Just t -> go t =<< liftIO (readTransferInfoFile Nothing file)
+  where
+	go _ Nothing = noop
+	go t (Just newinfo) = alterTransferInfo t $
+		\i -> i { bytesComplete = bytesComplete newinfo }
+
+{- This thread can only watch transfer sizes when the DirWatcher supports
+ - tracking modifications to files. -}
+watchesTransferSize :: Bool
+watchesTransferSize = modifyTracked
+
+{- Called when a transfer information file is removed. -}
+onDel :: Handler
+onDel file = case parseTransferFile file of
+	Nothing -> noop
+	Just t -> do
+		debug [ "transfer finishing:", show t]
+		minfo <- removeTransfer t
+
+		-- Run transfer hook.
+		m <- transferHook <$> getDaemonStatus
+		maybe noop (\hook -> void $ liftIO $ forkIO $ hook t)
+			(M.lookup (transferKey t) m)
+
+		finished <- asIO2 finishedTransfer
+		void $ liftIO $ forkIO $ do
+			{- XXX race workaround delay. The location
+			 - log needs to be updated before finishedTransfer
+			 - runs. -}
+			threadDelay 10000000 -- 10 seconds
+			finished t minfo
diff --git a/Assistant/Threads/Transferrer.hs b/Assistant/Threads/Transferrer.hs
new file mode 100644
index 0000000000..923479e7a1
--- /dev/null
+++ b/Assistant/Threads/Transferrer.hs
@@ -0,0 +1,27 @@
+{- git-annex assistant data transferrer thread
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Threads.Transferrer where
+
+import Assistant.Common
+import Assistant.TransferQueue
+import Assistant.TransferSlots
+import Types.Transfer
+import Annex.TransferrerPool
+import Utility.Batch
+
+{- Dispatches transfers from the queue. -}
+transfererThread :: NamedThread
+transfererThread = namedThread "Transferrer" $ do
+	rt <- liftAnnex . mkRunTransferrer
+		=<< liftIO getBatchCommandMaker
+	forever $ inTransferSlot rt $
+		maybe (return Nothing) (uncurry genTransfer)
+			=<< getNextTransfer notrunning
+  where
+	{- Skip transfers that are already running. -}
+	notrunning = isNothing . startedTime
diff --git a/Assistant/Threads/UpgradeWatcher.hs b/Assistant/Threads/UpgradeWatcher.hs
new file mode 100644
index 0000000000..5960a70c32
--- /dev/null
+++ b/Assistant/Threads/UpgradeWatcher.hs
@@ -0,0 +1,109 @@
+{- git-annex assistant thread to detect when git-annex is upgraded
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Assistant.Threads.UpgradeWatcher (
+	upgradeWatcherThread
+) where
+
+import Assistant.Common
+import Assistant.Upgrade
+import Utility.DirWatcher
+import Utility.DirWatcher.Types
+import Utility.ThreadScheduler
+import Assistant.Types.UrlRenderer
+import Assistant.Alert
+import Assistant.DaemonStatus
+#ifdef WITH_WEBAPP
+import Assistant.WebApp.Types
+import qualified BuildInfo
+#endif
+
+import Control.Concurrent.MVar
+import qualified Data.Text as T
+
+data WatcherState = InStartupScan | Started | Upgrading
+	deriving (Eq)
+
+upgradeWatcherThread :: UrlRenderer -> NamedThread
+upgradeWatcherThread urlrenderer = namedThread "UpgradeWatcher" $ do
+	whenM (liftIO checkSuccessfulUpgrade) $
+		showSuccessfulUpgrade urlrenderer
+	go =<< liftIO upgradeFlagFile
+  where
+	go flagfile = do
+		mvar <- liftIO $ newMVar InStartupScan
+		changed <- Just <$> asIO2 (changedFile urlrenderer mvar flagfile)
+		let hooks = mkWatchHooks
+			{ addHook = changed
+			, delHook = changed
+			, addSymlinkHook = changed
+			, modifyHook = changed
+			, delDirHook = changed
+			}
+		let dir = fromRawFilePath (parentDir (toRawFilePath flagfile))
+		let depth = length (splitPath dir) + 1
+		let nosubdirs f = length (splitPath f) == depth
+		void $ liftIO $ watchDir dir nosubdirs False hooks (startup mvar)
+	-- Ignore bogus events generated during the startup scan.
+	-- We ask the watcher to not generate them, but just to be safe..
+	startup mvar scanner = do
+		r <- scanner
+		void $ swapMVar mvar Started
+		return r
+
+changedFile :: UrlRenderer -> MVar WatcherState -> FilePath -> FilePath -> Maybe FileStatus -> Assistant ()
+changedFile urlrenderer mvar flagfile file _status
+	| flagfile /= file = noop
+	| otherwise = do
+		state <- liftIO $ readMVar mvar
+		when (state == Started) $ do
+			setstate Upgrading
+			ifM (liftIO upgradeSanityCheck)
+				( handleUpgrade urlrenderer
+				, do
+					debug ["new version failed sanity check; not using"]
+					setstate Started
+				)
+  where
+	setstate = void . liftIO . swapMVar mvar
+
+handleUpgrade :: UrlRenderer -> Assistant ()
+handleUpgrade urlrenderer = do
+	-- Wait 2 minutes for any final upgrade changes to settle.
+	-- (For example, other associated files may be being put into
+	-- place.) Not needed when using a distribution bundle, because
+	-- in that case git-annex handles the upgrade in a non-racy way.
+	liftIO $ unlessM usingDistribution $
+		threadDelaySeconds (Seconds 120)
+	ifM autoUpgradeEnabled
+		( do
+			debug ["starting automatic upgrade"]
+			unattendedUpgrade
+#ifdef WITH_WEBAPP
+		, do
+			button <- mkAlertButton True (T.pack "Finish Upgrade") urlrenderer ConfigFinishUpgradeR
+			void $ addAlert $ upgradeReadyAlert button
+#else
+		, noop
+#endif
+		)
+
+showSuccessfulUpgrade :: UrlRenderer -> Assistant ()
+showSuccessfulUpgrade urlrenderer = do
+#ifdef WITH_WEBAPP
+	button <- ifM autoUpgradeEnabled 
+		( pure Nothing
+		, Just <$> mkAlertButton True
+			(T.pack "Enable Automatic Upgrades")
+			urlrenderer ConfigEnableAutomaticUpgradeR
+		)
+	void $ addAlert $ upgradeFinishedAlert button BuildInfo.packageversion
+#else
+	noop
+#endif
diff --git a/Assistant/Threads/Upgrader.hs b/Assistant/Threads/Upgrader.hs
new file mode 100644
index 0000000000..a0e39e4174
--- /dev/null
+++ b/Assistant/Threads/Upgrader.hs
@@ -0,0 +1,85 @@
+{- git-annex assistant thread to detect when upgrade is available
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Assistant.Threads.Upgrader (
+	upgraderThread
+) where
+
+import Assistant.Common
+import Assistant.Upgrade
+
+import Assistant.Types.UrlRenderer
+import Assistant.DaemonStatus
+import Assistant.Alert
+import Utility.NotificationBroadcaster
+import qualified Annex
+import qualified BuildInfo
+import qualified Utility.DottedVersion as DottedVersion
+import Types.Distribution
+#ifdef WITH_WEBAPP
+import Assistant.WebApp.Types
+#endif
+
+import Data.Time.Clock
+import qualified Data.Text as T
+
+upgraderThread :: UrlRenderer -> NamedThread
+upgraderThread urlrenderer = namedThread "Upgrader" $
+	when upgradeSupported $ do
+		{- Check for upgrade on startup, unless it was just
+		 - upgraded. -}
+		unlessM (liftIO checkSuccessfulUpgrade) $
+			checkUpgrade urlrenderer
+		h <- liftIO . newNotificationHandle False . networkConnectedNotifier =<< getDaemonStatus
+		go h =<< liftIO getCurrentTime
+  where
+	{- Wait for a network connection event. Then see if it's been
+	 - half a day since the last upgrade check. If so, proceed with
+	 - check. -}
+	go h lastchecked = do
+		liftIO $ waitNotification h
+		autoupgrade <- liftAnnex $ annexAutoUpgrade <$> Annex.getGitConfig
+		if autoupgrade == NoAutoUpgrade
+			then go h lastchecked
+			else do
+				now <- liftIO getCurrentTime
+				if diffUTCTime now lastchecked > halfday
+					then do
+						checkUpgrade urlrenderer
+						go h =<< liftIO getCurrentTime
+					else go h lastchecked
+	halfday = 12 * 60 * 60
+
+checkUpgrade :: UrlRenderer -> Assistant ()
+checkUpgrade urlrenderer = do
+	debug [ "Checking if an upgrade is available." ]
+	go =<< downloadDistributionInfo
+  where
+	go Nothing = debug [ "Failed to check if upgrade is available." ]
+	go (Just d) = do
+		let installed = DottedVersion.normalize BuildInfo.packageversion
+		let avail = DottedVersion.normalize $ distributionVersion d
+		let old = DottedVersion.normalize <$> distributionUrgentUpgrade d
+		if Just installed <= old
+			then canUpgrade High urlrenderer d
+			else if installed < avail
+				then canUpgrade Low urlrenderer d
+				else debug [ "No new version found." ]
+
+canUpgrade :: AlertPriority -> UrlRenderer -> GitAnnexDistribution -> Assistant ()
+canUpgrade urgency urlrenderer d = ifM autoUpgradeEnabled
+	( startDistributionDownload d
+	, do
+#ifdef WITH_WEBAPP
+		button <- mkAlertButton True (T.pack "Upgrade") urlrenderer (ConfigStartUpgradeR d)
+		void $ addAlert (canUpgradeAlert urgency (distributionVersion d) button)
+#else
+		noop
+#endif
+	)
diff --git a/Assistant/Threads/Watcher.hs b/Assistant/Threads/Watcher.hs
new file mode 100644
index 0000000000..2df29ce76c
--- /dev/null
+++ b/Assistant/Threads/Watcher.hs
@@ -0,0 +1,376 @@
+{- git-annex assistant tree watcher
+ -
+ - Copyright 2012-2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE DeriveDataTypeable, OverloadedStrings, CPP #-}
+
+module Assistant.Threads.Watcher (
+	watchThread,
+	WatcherControl(..),
+	checkCanWatch,
+	needLsof,
+	onAddSymlink,
+	runHandler,
+) where
+
+import Assistant.Common
+import Assistant.DaemonStatus
+import Assistant.Changes
+import Assistant.Types.Changes
+import Assistant.Alert
+import Utility.DirWatcher
+import Utility.DirWatcher.Types
+import Utility.InodeCache
+import qualified Utility.RawFilePath as R
+import qualified Annex
+import qualified Annex.Queue
+import qualified Git
+import qualified Git.UpdateIndex
+import qualified Git.LsFiles as LsFiles
+import Annex.WorkTree
+import Annex.CatFile
+import Annex.CheckIgnore
+import Annex.Link
+import Annex.Content
+import Annex.ReplaceFile
+import Annex.InodeSentinal
+import Git.Types
+import Git.FilePath
+import Config.GitConfig
+import Utility.ThreadScheduler
+import Logs.Location
+import qualified Database.Keys
+#ifndef mingw32_HOST_OS
+import qualified Utility.Lsof as Lsof
+#endif
+
+import Data.Typeable
+import qualified Data.ByteString.Lazy as L
+import qualified Control.Exception as E
+import Data.Time.Clock
+import System.PosixCompat.Files (fileMode, statusChangeTime)
+
+checkCanWatch :: Annex ()
+checkCanWatch
+	| canWatch = do
+#ifndef mingw32_HOST_OS
+		liftIO Lsof.setup
+		unlessM (liftIO (inSearchPath "lsof") <||> Annex.getRead Annex.force)
+			needLsof
+#else
+		noop
+#endif
+	| otherwise = giveup "watch mode is not available on this system"
+
+needLsof :: Annex ()
+needLsof = giveup $ unlines
+	[ "The lsof command is needed for watch mode to be safe, and is not in PATH."
+	, "To override lsof checks to ensure that files are not open for writing"
+	, "when added to the annex, you can use --force"
+	, "Be warned: This can corrupt data in the annex, and make fsck complain."
+	]
+
+{- A special exception that can be thrown to pause or resume the watcher. -}
+data WatcherControl = PauseWatcher | ResumeWatcher
+	deriving (Show, Eq, Typeable)
+
+instance E.Exception WatcherControl
+
+watchThread :: NamedThread
+watchThread = namedThread "Watcher" $
+	ifM (liftAnnex $ getGitConfigVal annexAutoCommit)
+		( runWatcher
+		, waitFor ResumeWatcher runWatcher
+		)
+
+runWatcher :: Assistant ()
+runWatcher = do
+	startup <- asIO1 startupScan
+	symlinkssupported <- liftAnnex $ coreSymlinks <$> Annex.getGitConfig
+	addhook <- hook $ onAddFile symlinkssupported
+	delhook <- hook onDel
+	addsymlinkhook <- hook onAddSymlink
+	deldirhook <- hook onDelDir
+	errhook <- hook onErr
+	let hooks = mkWatchHooks
+		{ addHook = addhook
+		, delHook = delhook
+		, addSymlinkHook = addsymlinkhook
+		, delDirHook = deldirhook
+		, errHook = errhook
+		}
+	scanevents <- liftAnnex $ annexStartupScan <$> Annex.getGitConfig
+	h <- liftIO $ watchDir "." ignored scanevents hooks startup
+	debug [ "watching", "."]
+	
+	{- Let the DirWatcher thread run until signalled to pause it,
+	 - then wait for a resume signal, and restart. -}
+	waitFor PauseWatcher $ do
+		liftIO $ stopWatchDir h
+		waitFor ResumeWatcher runWatcher
+  where
+	hook a = Just <$> asIO2 (runHandler a)
+
+waitFor :: WatcherControl -> Assistant () -> Assistant ()
+waitFor sig next = do
+	r <- liftIO (E.try pause :: IO (Either E.SomeException ()))
+	case r of
+		Left e -> case E.fromException e of
+			Just s
+				| s == sig -> next
+			_ -> noop
+		_ -> noop
+  where
+	pause = runEvery (Seconds 86400) noop
+
+{- Initial scartup scan. The action should return once the scan is complete. -}
+startupScan :: IO a -> Assistant a
+startupScan scanner = do
+	liftAnnex $ showAction "scanning"
+	alertWhile' startupScanAlert $ do
+		r <- liftIO scanner
+
+		-- Notice any files that were deleted before
+		-- watching was started.
+		top <- liftAnnex $ fromRepo Git.repoPath
+		(fs, cleanup) <- liftAnnex $ inRepo $ LsFiles.deleted [] [top]
+		forM_ fs $ \f -> do
+			let f' = fromRawFilePath f
+			liftAnnex $ onDel' f'
+			maybe noop recordChange =<< madeChange f' RmChange
+		void $ liftIO cleanup
+		
+		liftAnnex $ showAction "started"
+		liftIO $ putStrLn ""
+		
+		modifyDaemonStatus_ $ \s -> s { scanComplete = True }
+
+		-- Ensure that the Committer sees any changes
+		-- that it did not process, and acts on them now that
+		-- the scan is complete.
+		refillChanges =<< getAnyChanges
+
+		return (True, r)
+
+{- Hardcoded ignores, passed to the DirWatcher so it can avoid looking
+ - at the entire .git directory. Does not include .gitignores. -}
+ignored :: FilePath -> Bool
+ignored = ig . takeFileName
+  where
+	ig ".git" = True
+	ig ".gitignore" = True
+	ig ".gitattributes" = True
+#ifdef darwin_HOST_OS
+	ig ".DS_Store" = True
+#endif
+	ig _ = False
+
+unlessIgnored :: FilePath -> Assistant (Maybe Change) -> Assistant (Maybe Change)
+unlessIgnored file a = ifM (liftAnnex $ checkIgnored (CheckGitIgnore True) (toRawFilePath file))
+	( noChange
+	, a
+	)
+
+type Handler = FilePath -> Maybe FileStatus -> Assistant (Maybe Change)
+
+{- Runs an action handler, and if there was a change, adds it to the ChangeChan.
+ -
+ - Exceptions are ignored, otherwise a whole watcher thread could be crashed.
+ -}
+runHandler :: Handler -> FilePath -> Maybe FileStatus -> Assistant ()
+runHandler handler file filestatus = void $ do
+	r <- tryIO <~> handler (normalize file) filestatus
+	case r of
+		Left e -> liftAnnex $ warning $ UnquotedString $ show e
+		Right Nothing -> noop
+		Right (Just change) -> recordChange change
+  where
+	normalize f
+		| "./" `isPrefixOf` file = drop 2 f
+		| otherwise = f
+
+shouldRestage :: DaemonStatus -> Bool
+shouldRestage ds = scanComplete ds || forceRestage ds
+
+onAddFile :: Bool -> Handler
+onAddFile symlinkssupported f fs = do
+	mk <- liftIO $ isPointerFile $ toRawFilePath f
+	case mk of
+		Nothing -> onAddFile' contentchanged addassociatedfile addlink samefilestatus symlinkssupported f fs
+		Just k -> addlink f k
+  where
+	addassociatedfile key file = 
+		Database.Keys.addAssociatedFile key
+			=<< inRepo (toTopFilePath (toRawFilePath file))
+	samefilestatus key file status = do
+		cache <- Database.Keys.getInodeCaches key
+		curr <- withTSDelta $ \delta ->
+			liftIO $ toInodeCache delta (toRawFilePath file) status
+		case (cache, curr) of
+			(_, Just c) -> elemInodeCaches c cache
+			([], Nothing) -> return True
+			_ -> return False
+	contentchanged oldkey file = do
+		Database.Keys.removeAssociatedFile oldkey
+			=<< inRepo (toTopFilePath (toRawFilePath file))
+		unlessM (inAnnex oldkey) $
+			logStatus oldkey InfoMissing
+	addlink file key = do
+		mode <- liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus (toRawFilePath file)
+		liftAnnex $ stagePointerFile (toRawFilePath file) mode =<< hashPointerFile key
+		madeChange file $ LinkChange (Just key)
+
+onAddFile'
+	:: (Key -> FilePath -> Annex ())
+	-> (Key -> FilePath -> Annex ())
+	-> (FilePath -> Key -> Assistant (Maybe Change))
+	-> (Key -> FilePath -> FileStatus -> Annex Bool)
+	-> Bool
+	-> Handler
+onAddFile' contentchanged addassociatedfile addlink samefilestatus symlinkssupported file fs = do
+	v <- liftAnnex $ catKeyFile (toRawFilePath file)
+	case (v, fs) of
+		(Just key, Just filestatus) ->
+			ifM (liftAnnex $ samefilestatus key file filestatus)
+				{- It's possible to get an add event for
+				 - an existing file that is not
+				 - really modified, but it might have
+				 - just been deleted and been put back,
+				 - so its annex link is restaged to make sure. -}
+				( ifM (shouldRestage <$> getDaemonStatus)
+					( addlink file key
+					, noChange
+					)
+				, guardSymlinkStandin (Just key) $ do
+					debug ["changed", file]
+					liftAnnex $ contentchanged key file
+					pendingAddChange file
+				)
+		_ -> unlessIgnored file $
+			guardSymlinkStandin Nothing $ do
+				debug ["add", file]
+				pendingAddChange file
+  where
+	{- On a filesystem without symlinks, we'll get changes for regular
+	 - files that git uses to stand-in for symlinks. Detect when
+	 - this happens, and stage the symlink, rather than annexing the
+	 - file. -}
+	guardSymlinkStandin mk a
+		| symlinkssupported = a
+		| otherwise = do
+			linktarget <- liftAnnex $ getAnnexLinkTarget $
+				toRawFilePath file
+			case linktarget of
+				Nothing -> a
+				Just lt -> do
+					case parseLinkTargetOrPointer lt of
+						Nothing -> noop
+						Just key -> liftAnnex $
+							addassociatedfile key file
+					onAddSymlink' (Just lt) mk file fs
+
+{- A symlink might be an arbitrary symlink, which is just added.
+ - Or, if it is a git-annex symlink, ensure it points to the content
+ - before adding it.
+ -}
+onAddSymlink :: Handler
+onAddSymlink file filestatus = unlessIgnored file $ do
+	linktarget <- liftIO (catchMaybeIO $ R.readSymbolicLink file')
+	kv <- liftAnnex (lookupKey file')
+	onAddSymlink' linktarget kv file filestatus
+  where
+	file' = toRawFilePath file
+
+onAddSymlink' :: Maybe LinkTarget -> Maybe Key -> Handler
+onAddSymlink' linktarget mk file filestatus = go mk
+  where
+	go (Just key) = do
+		link <- liftAnnex $ calcRepo $ gitAnnexLink (toRawFilePath file) key
+		if linktarget == Just link
+			then ensurestaged (Just link) =<< getDaemonStatus
+			else do
+				liftAnnex $ replaceWorkTreeFile file $
+					makeAnnexLink link
+				addLink file link (Just key)
+	-- other symlink, not git-annex
+	go Nothing = ensurestaged linktarget =<< getDaemonStatus
+
+	{- This is often called on symlinks that are already
+	 - staged correctly. A symlink may have been deleted
+	 - and being re-added, or added when the watcher was
+	 - not running. So they're normally restaged to make sure.
+	 -
+	 - As an optimisation, during the startup scan, avoid
+	 - restaging everything. Only links that were created since
+	 - the last time the daemon was running are staged.
+	 - (If the daemon has never ran before, avoid staging
+	 - links too.)
+	 -}
+	ensurestaged (Just link) daemonstatus
+		| shouldRestage daemonstatus = addLink file link mk
+		| otherwise = case filestatus of
+			Just s
+				| not (afterLastDaemonRun (statusChangeTime s) daemonstatus) -> noChange
+			_ -> addLink file link mk
+	ensurestaged Nothing _ = noChange
+
+{- For speed, tries to reuse the existing blob for symlink target. -}
+addLink :: FilePath -> LinkTarget -> Maybe Key -> Assistant (Maybe Change)
+addLink file link mk = do
+	debug ["add symlink", file]
+	liftAnnex $ do
+		v <- catObjectDetails $ Ref $ encodeBS $ ':':file
+		case v of
+			Just (currlink, sha, _type)
+				| L.fromStrict link == currlink ->
+					stageSymlink (toRawFilePath file) sha
+			_ -> stageSymlink (toRawFilePath file)
+				=<< hashSymlink link
+	madeChange file $ LinkChange mk
+
+onDel :: Handler
+onDel file _ = do
+	debug ["file deleted", file]
+	liftAnnex $ onDel' file
+	madeChange file RmChange
+
+onDel' :: FilePath -> Annex ()
+onDel' file = do
+	topfile <- inRepo (toTopFilePath (toRawFilePath file))
+	withkey $ flip Database.Keys.removeAssociatedFile topfile
+	Annex.Queue.addUpdateIndex =<<
+		inRepo (Git.UpdateIndex.unstageFile (toRawFilePath file))
+  where
+	withkey a = maybe noop a =<< catKeyFile (toRawFilePath file)
+
+{- A directory has been deleted, or moved, so tell git to remove anything
+ - that was inside it from its cache. Since it could reappear at any time,
+ - use --cached to only delete it from the index.
+ -
+ - This queues up a lot of RmChanges, which assists the Committer in
+ - pairing up renamed files when the directory was renamed. -}
+onDelDir :: Handler
+onDelDir dir _ = do
+	debug ["directory deleted", dir]
+	(fs, clean) <- liftAnnex $ inRepo $ LsFiles.deleted [] [toRawFilePath dir]
+	let fs' = map fromRawFilePath fs
+
+	liftAnnex $ mapM_ onDel' fs'
+
+	-- Get the events queued up as fast as possible, so the
+	-- committer sees them all in one block.
+	now <- liftIO getCurrentTime
+	recordChanges $ map (\f -> Change now f RmChange) fs'
+
+	void $ liftIO clean
+	noChange
+
+{- Called when there's an error with inotify or kqueue. -}
+onErr :: Handler
+onErr msg _ = do
+	liftAnnex $ warning (UnquotedString msg)
+	void $ addAlert $ warningAlert "watcher" msg
+	noChange
diff --git a/Assistant/Threads/WebApp.hs b/Assistant/Threads/WebApp.hs
new file mode 100644
index 0000000000..3fdd12d05f
--- /dev/null
+++ b/Assistant/Threads/WebApp.hs
@@ -0,0 +1,136 @@
+{- git-annex assistant webapp thread
+ -
+ - Copyright 2012-2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TemplateHaskell, MultiParamTypeClasses #-}
+{-# LANGUAGE ViewPatterns, OverloadedStrings #-}
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module Assistant.Threads.WebApp where
+
+import Assistant.Common
+import Assistant.WebApp
+import Assistant.WebApp.Types
+import Assistant.WebApp.DashBoard
+import Assistant.WebApp.SideBar
+import Assistant.WebApp.Notifications
+import Assistant.WebApp.RepoList
+import Assistant.WebApp.Configurators
+import Assistant.WebApp.Configurators.Local
+import Assistant.WebApp.Configurators.Ssh
+import Assistant.WebApp.Configurators.Pairing
+import Assistant.WebApp.Configurators.AWS
+import Assistant.WebApp.Configurators.IA
+import Assistant.WebApp.Configurators.WebDAV
+import Assistant.WebApp.Configurators.Preferences
+import Assistant.WebApp.Configurators.Unused
+import Assistant.WebApp.Configurators.Edit
+import Assistant.WebApp.Configurators.Delete
+import Assistant.WebApp.Configurators.Fsck
+import Assistant.WebApp.Configurators.Upgrade
+import Assistant.WebApp.Documentation
+import Assistant.WebApp.Control
+import Assistant.WebApp.OtherRepos
+import Assistant.WebApp.Repair
+import Assistant.WebApp.Pairing
+import Assistant.Types.ThreadedMonad
+import Utility.WebApp
+import Utility.AuthToken
+import Utility.Tmp
+import Utility.FileMode
+import Git
+import qualified Annex
+
+import Yesod
+import Network.Socket (SockAddr, HostName, PortNumber)
+import Data.Text (pack, unpack)
+import qualified Network.Wai.Handler.WarpTLS as TLS
+import Network.Wai.Middleware.RequestLogger
+
+mkYesodDispatch "WebApp" $(parseRoutesFile "Assistant/WebApp/routes")
+
+type Url = String
+
+webAppThread
+	:: AssistantData
+	-> UrlRenderer
+	-> Bool
+	-> Maybe String
+	-> Maybe (IO Url)
+	-> Maybe HostName
+	-> Maybe PortNumber
+	-> Maybe (Url -> FilePath -> IO ())
+	-> NamedThread
+webAppThread assistantdata urlrenderer noannex cannotrun postfirstrun listenhost listenport onstartup = thread $ liftIO $ do
+	listenhost' <- if isJust listenhost
+		then pure listenhost
+		else getAnnex $ annexListen <$> Annex.getGitConfig
+	listenport' <- if isJust listenport
+		then pure listenport
+		else getAnnex $ annexPort <$> Annex.getGitConfig
+	tlssettings <- getAnnex getTlsSettings
+	webapp <- WebApp
+		<$> pure assistantdata
+		<*> genAuthToken 128
+		<*> getreldir
+		<*> pure staticRoutes
+		<*> pure postfirstrun
+		<*> pure cannotrun
+		<*> pure noannex
+		<*> pure listenhost'
+		<*> newWormholePairingState
+	setUrlRenderer urlrenderer $ yesodRender webapp (pack "")
+	app <- toWaiAppPlain webapp
+	app' <- ifM (fromMaybe False <$> (getAnnex $ Just . annexDebug <$> Annex.getGitConfig))
+		( return $ logStdout app
+		, return app
+		)
+	runWebApp tlssettings listenhost' listenport' app' $ \addr -> if noannex
+		then withTmpFile "webapp.html" $ \tmpfile h -> do
+			hClose h
+			go tlssettings addr webapp tmpfile Nothing
+		else do
+			htmlshim <- getAnnex' $ fromRepo gitAnnexHtmlShim
+			urlfile <- getAnnex' $ fromRepo gitAnnexUrlFile
+			go tlssettings addr webapp
+				(fromRawFilePath htmlshim)
+				(Just urlfile)
+  where
+	-- The webapp thread does not wait for the startupSanityCheckThread
+	-- to finish, so that the user interface remains responsive while
+	-- that's going on.
+	thread = namedThreadUnchecked "WebApp"
+	getreldir
+		| noannex = return Nothing
+		| otherwise = Just <$>
+			(relHome . fromRawFilePath =<< absPath =<< getAnnex' (fromRepo repoPath))
+	go tlssettings addr webapp htmlshim urlfile = do
+		let url = myUrl tlssettings webapp addr
+		maybe noop (`writeFileProtected` url) urlfile
+		writeHtmlShim "Starting webapp..." url htmlshim
+		maybe noop (\a -> a url htmlshim) onstartup
+
+	getAnnex a
+		| noannex = pure Nothing
+		| otherwise = getAnnex' a
+	getAnnex' = runThreadState (threadState assistantdata)
+
+myUrl :: Maybe TLS.TLSSettings -> WebApp -> SockAddr -> Url
+myUrl tlssettings webapp addr = unpack $ yesodRender webapp urlbase DashboardR []
+  where
+	urlbase = pack $ proto ++ "://" ++ show addr
+	proto
+		| isJust tlssettings = "https"
+		| otherwise = "http"
+
+getTlsSettings :: Annex (Maybe TLS.TLSSettings)
+getTlsSettings = do
+	cert <- fromRepo gitAnnexWebCertificate
+	privkey <- fromRepo gitAnnexWebPrivKey
+	ifM (liftIO $ allM doesFileExist [cert, privkey])
+		( return $ Just $ TLS.tlsSettings cert privkey
+		, return Nothing
+		)
diff --git a/Assistant/TransferQueue.hs b/Assistant/TransferQueue.hs
new file mode 100644
index 0000000000..571899bb6d
--- /dev/null
+++ b/Assistant/TransferQueue.hs
@@ -0,0 +1,236 @@
+{- git-annex assistant pending transfer queue
+ -
+ - Copyright 2012-2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Assistant.TransferQueue (
+	TransferQueue,
+	Schedule(..),
+	newTransferQueue,
+	getTransferQueue,
+	queueTransfers,
+	queueTransfersMatching,
+	queueDeferredDownloads,
+	queueTransfer,
+	queueTransferAt,
+	queueTransferWhenSmall,
+	getNextTransfer,
+	getMatchingTransfers,
+	dequeueTransfers,
+) where
+
+import Assistant.Common
+import Assistant.DaemonStatus
+import Assistant.Types.TransferQueue
+import Types.Transfer
+import Logs.Transfer
+import Types.Remote
+import qualified Remote
+import qualified Types.Remote as Remote
+import qualified Annex
+import Annex.Wanted
+import Utility.TList
+
+import Control.Concurrent.STM
+import qualified Data.Map.Strict as M
+import qualified Data.Set as S
+
+type Reason = String
+
+{- Reads the queue's content without blocking or changing it. -}
+getTransferQueue :: Assistant [(Transfer, TransferInfo)]
+getTransferQueue = (atomically . readTList . queuelist) <<~ transferQueue
+
+stubInfo :: AssociatedFile -> Remote -> TransferInfo
+stubInfo f r = stubTransferInfo
+	{ transferRemote = Just r
+	, associatedFile = f
+	}
+
+{- Adds transfers to queue for some of the known remotes.
+ - Honors preferred content settings, only transferring wanted files. -}
+queueTransfers :: Reason -> Schedule -> Key -> AssociatedFile -> Direction -> Assistant Bool
+queueTransfers = queueTransfersMatching (const True)
+
+{- Adds transfers to queue for some of the known remotes, that match a
+ - condition. Honors preferred content settings. -}
+queueTransfersMatching :: (UUID -> Bool) -> Reason -> Schedule -> Key -> AssociatedFile -> Direction -> Assistant Bool
+queueTransfersMatching matching reason schedule k f direction
+	| direction == Download = ifM (liftAnnex $ wantGet True (Just k) f)
+		( go
+		, return False
+		)
+	| otherwise = go
+  where
+	go = do
+		rs <- liftAnnex . selectremotes =<< getDaemonStatus
+		let matchingrs = filter (matching . Remote.uuid) rs
+		if null matchingrs
+			then do
+				defer
+				return False
+			else do
+				forM_ matchingrs $ \r ->
+					enqueue reason schedule (gentransfer r) (stubInfo f r)
+				return True
+	selectremotes st
+		{- Queue downloads from all remotes that
+		 - have the key. The list of remotes is ordered with
+		 - cheapest first. More expensive ones will only be tried
+		 - if downloading from a cheap one fails. -}
+		| direction == Download = do
+			s <- locs
+			return $ filter (inset s) (downloadRemotes st)
+		{- Upload to all remotes that want the content and don't
+		 - already have it. -}
+		| otherwise = do
+			s <- locs
+			filterM (wantGetBy True (Just k) f . Remote.uuid) $
+				filter (\r -> not (inset s r || Remote.readonly r))
+					(syncDataRemotes st)
+	  where
+		locs = S.fromList . map Remote.uuid <$> Remote.keyPossibilities (Remote.IncludeIgnored False) k
+		inset s r = S.member (Remote.uuid r) s
+	gentransfer r = Transfer
+		{ transferDirection = direction
+		, transferKeyData = fromKey id k
+		, transferUUID = Remote.uuid r
+		}
+	defer
+		{- Defer this download, as no known remote has the key. -}
+		| direction == Download = do
+			q <- getAssistant transferQueue
+			void $ liftIO $ atomically $
+				consTList (deferreddownloads q) (k, f)
+		| otherwise = noop
+
+{- Queues any deferred downloads that can now be accomplished, leaving
+ - any others in the list to try again later. -}
+queueDeferredDownloads :: Reason -> Schedule -> Assistant ()
+queueDeferredDownloads reason schedule = do
+	q <- getAssistant transferQueue
+	l <- liftIO $ atomically $ readTList (deferreddownloads q)
+	rs <- downloadRemotes <$> getDaemonStatus
+	left <- filterM (queue rs) l
+	unless (null left) $
+		liftIO $ atomically $ appendTList (deferreddownloads q) left
+  where
+	queue rs (k, f) = do
+		uuids <- liftAnnex $ Remote.keyLocations k
+		let sources = filter (\r -> uuid r `elem` uuids) rs
+		unless (null sources) $
+			forM_ sources $ \r ->
+				enqueue reason schedule 
+					(gentransfer r) (stubInfo f r)
+		return $ null sources
+	  where
+		gentransfer r = Transfer
+			{ transferDirection = Download
+			, transferKeyData = fromKey id k
+			, transferUUID = Remote.uuid r
+			}
+
+enqueue :: Reason -> Schedule -> Transfer -> TransferInfo -> Assistant ()
+enqueue reason schedule t info
+	| schedule == Next = go consTList
+	| otherwise = go snocTList
+  where
+	go modlist = whenM (add modlist) $ do
+		qp <- liftAnnex $ coreQuotePath <$> Annex.getGitConfig
+		debug [ "queued", describeTransfer qp t info, ": " ++ reason ]
+		notifyTransfer
+	add modlist = do
+		q <- getAssistant transferQueue
+		dstatus <- getAssistant daemonStatusHandle
+		liftIO $ atomically $ ifM (checkRunningTransferSTM dstatus t)
+			( return False
+			, do
+				l <- readTList (queuelist q)
+				if (t `notElem` map fst l)
+					then do	
+						void $ modifyTVar' (queuesize q) succ
+						void $ modlist (queuelist q) (t, info)
+						return True
+					else return False
+			)
+
+{- Adds a transfer to the queue. -}
+queueTransfer :: Reason -> Schedule -> AssociatedFile -> Transfer -> Remote -> Assistant ()
+queueTransfer reason schedule f t remote =
+	enqueue reason schedule t (stubInfo f remote)
+
+{- Blocks until the queue is no larger than a given size, and then adds a
+ - transfer to the queue. -}
+queueTransferAt :: Int -> Reason -> Schedule -> AssociatedFile -> Transfer -> Remote -> Assistant ()
+queueTransferAt wantsz reason schedule f t remote = do
+	q <- getAssistant transferQueue
+	liftIO $ atomically $ do
+		sz <- readTVar (queuesize q)
+		unless (sz <= wantsz) $
+			retry -- blocks until queuesize changes
+	enqueue reason schedule t (stubInfo f remote)
+
+queueTransferWhenSmall :: Reason -> AssociatedFile -> Transfer -> Remote -> Assistant ()
+queueTransferWhenSmall reason = queueTransferAt 10 reason Later
+
+{- Blocks until a pending transfer is available in the queue,
+ - and removes it.
+ -
+ - Checks that it's acceptable, before adding it to the
+ - currentTransfers map. If it's not acceptable, it's discarded.
+ -
+ - This is done in a single STM transaction, so there is no window
+ - where an observer sees an inconsistent status. -}
+getNextTransfer :: (TransferInfo -> Bool) -> Assistant (Maybe (Transfer, TransferInfo))
+getNextTransfer acceptable = do
+	q <- getAssistant transferQueue
+	dstatus <- getAssistant daemonStatusHandle
+	liftIO $ atomically $ do
+		sz <- readTVar (queuesize q)
+		if sz < 1
+			then retry -- blocks until queuesize changes
+			else readTList (queuelist q) >>= \case
+				[] -> retry -- blocks until something is queued
+				(r@(t,info):rest) -> do
+					void $ modifyTVar' (queuesize q) pred
+					setTList (queuelist q) rest
+					if acceptable info
+						then do
+							adjustTransfersSTM dstatus $
+								M.insert t info
+							return $ Just r
+						else return Nothing
+
+{- Moves transfers matching a condition from the queue, to the
+ - currentTransfers map. -}
+getMatchingTransfers :: (Transfer -> Bool) -> Assistant [(Transfer, TransferInfo)]
+getMatchingTransfers c = do
+	q <- getAssistant transferQueue
+	dstatus <- getAssistant daemonStatusHandle
+	liftIO $ atomically $ do
+		ts <- dequeueTransfersSTM q c
+		unless (null ts) $
+			adjustTransfersSTM dstatus $ \m -> M.union m $ M.fromList ts
+		return ts
+
+{- Removes transfers matching a condition from the queue, and returns the
+ - removed transfers. -}
+dequeueTransfers :: (Transfer -> Bool) -> Assistant [(Transfer, TransferInfo)]
+dequeueTransfers c = do
+	q <- getAssistant transferQueue
+	removed <- liftIO $ atomically $ dequeueTransfersSTM q c
+	unless (null removed) $
+		notifyTransfer
+	return removed
+
+dequeueTransfersSTM :: TransferQueue -> (Transfer -> Bool) -> STM [(Transfer, TransferInfo)]
+dequeueTransfersSTM q c = do
+	!(removed, ts) <- partition (c . fst) <$> readTList (queuelist q)
+	let !len = length ts
+	void $ writeTVar (queuesize q) len
+	setTList (queuelist q) ts
+	return removed
diff --git a/Assistant/TransferSlots.hs b/Assistant/TransferSlots.hs
new file mode 100644
index 0000000000..c16871f468
--- /dev/null
+++ b/Assistant/TransferSlots.hs
@@ -0,0 +1,321 @@
+{- git-annex assistant transfer slots
+ -
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Assistant.TransferSlots where
+
+import Control.Concurrent.STM
+
+import Assistant.Common
+import Utility.ThreadScheduler
+import Utility.NotificationBroadcaster
+import Assistant.Types.TransferSlots
+import Assistant.DaemonStatus
+import Annex.TransferrerPool
+import Types.TransferrerPool
+import Assistant.Types.TransferQueue
+import Assistant.TransferQueue
+import Assistant.Alert
+import Assistant.Alert.Utility
+import Assistant.Commits
+import Assistant.Drop
+import Types.Transfer
+import Logs.Transfer
+import Logs.Location
+import qualified Git
+import qualified Annex
+import qualified Remote
+import qualified Types.Remote as Remote
+import Annex.Content
+import Annex.Wanted
+import Annex.StallDetection
+import Utility.Batch
+import Types.NumCopies
+
+import Data.Either
+import qualified Data.Map as M 
+import qualified Control.Exception as E
+import Control.Concurrent
+import qualified Control.Concurrent.MSemN as MSemN
+#ifndef mingw32_HOST_OS
+import System.Posix.Process (getProcessGroupIDOf)
+import System.Posix.Signals (signalProcessGroup, sigTERM, sigKILL)
+#else
+import System.Win32.Process (terminateProcessById)
+#endif
+
+type TransferGenerator = Assistant (Maybe (Transfer, TransferInfo, Transferrer -> Assistant ()))
+
+{- Waits until a transfer slot becomes available, then runs a
+ - TransferGenerator, and then runs the transfer action in its own thread. 
+ -}
+inTransferSlot :: RunTransferrer -> TransferGenerator -> Assistant ()
+inTransferSlot rt gen = do
+	flip MSemN.wait 1 <<~ transferSlots
+	runTransferThread rt =<< gen
+
+{- Runs a TransferGenerator, and its transfer action,
+ - without waiting for a slot to become available. -}
+inImmediateTransferSlot :: RunTransferrer -> TransferGenerator -> Assistant ()
+inImmediateTransferSlot rt gen = do
+	flip MSemN.signal (-1) <<~ transferSlots
+	runTransferThread rt =<< gen
+
+{- Runs a transfer action, in an already allocated transfer slot.
+ - Once it finishes, frees the transfer slot.
+ -
+ - Note that the action is subject to being killed when the transfer
+ - is canceled or paused.
+ -
+ - A PauseTransfer exception is handled by letting the action be killed,
+ - then pausing the thread until a ResumeTransfer exception is raised,
+ - then rerunning the action.
+ -}
+runTransferThread :: RunTransferrer -> Maybe (Transfer, TransferInfo, Transferrer -> Assistant ()) -> Assistant ()
+runTransferThread _ Nothing = flip MSemN.signal 1 <<~ transferSlots
+runTransferThread rt (Just (t, info, a)) = do
+	d <- getAssistant id
+	mkcheck <- checkNetworkConnections 
+		<$> getAssistant daemonStatusHandle
+	aio <- asIO1 a
+	tid <- liftIO $ forkIO $ runTransferThread' mkcheck rt d aio
+	updateTransferInfo t $ info { transferTid = Just tid }
+
+runTransferThread' :: MkCheckTransferrer -> RunTransferrer -> AssistantData -> (Transferrer -> IO ()) -> IO ()
+runTransferThread' mkcheck rt d run = go
+  where
+	go = catchPauseResume $ do
+		p <- runAssistant d $ liftAnnex $ 
+			Annex.getRead Annex.transferrerpool
+		signalactonsvar <- runAssistant d $ liftAnnex $
+			Annex.getRead Annex.signalactions
+		withTransferrer' True signalactonsvar mkcheck rt p run
+	pause = catchPauseResume $
+		runEvery (Seconds 86400) noop
+	{- Note: This must use E.try, rather than E.catch.
+	 - When E.catch is used, and has called go in its exception
+	 - handler, Control.Concurrent.throwTo will block sometimes
+	 - when signaling. Using E.try avoids the problem. -}
+	catchPauseResume a' = do
+		r <- E.try a' :: IO (Either E.SomeException ())
+		case r of
+			Left e -> case E.fromException e of
+				Just PauseTransfer -> pause
+				Just ResumeTransfer -> go
+				_ -> done
+			_ -> done
+	done = runAssistant d $ 
+		flip MSemN.signal 1 <<~ transferSlots
+
+{- By the time this is called, the daemonstatus's currentTransfers map should
+ - already have been updated to include the transfer. -}
+genTransfer :: Transfer -> TransferInfo -> TransferGenerator
+genTransfer t info = case transferRemote info of
+	Just remote -> ifM (unpluggedremovabledrive remote)
+		( do
+			-- optimisation, since the transfer would fail
+			liftAnnex $ recordFailedTransfer t info
+			void $ removeTransfer t
+			return Nothing
+		, ifM (liftAnnex $ shouldTransfer t info)
+			( do
+				qp <- liftAnnex $ coreQuotePath <$> Annex.getGitConfig
+				debug [ "Transferring:" , describeTransfer qp t info ]
+				notifyTransfer
+				let sd = getStallDetection (transferDirection t) remote
+				return $ Just (t, info, go remote sd)
+			, do
+				qp <- liftAnnex $ coreQuotePath <$> Annex.getGitConfig
+				debug [ "Skipping unnecessary transfer:",
+					describeTransfer qp t info ]
+				void $ removeTransfer t
+				finishedTransfer t (Just info)
+				return Nothing
+			)
+		)
+	_ -> return Nothing
+  where
+	direction = transferDirection t
+	isdownload = direction == Download
+
+	unpluggedremovabledrive remote = Git.repoIsLocalUnknown
+		<$> liftAnnex (Remote.getRepo remote)
+
+	{- Alerts are only shown for successful transfers.
+	 - Transfers can temporarily fail for many reasons,
+	 - so there's no point in bothering the user about
+	 - those. The assistant should recover.
+	 -
+	 - After a successful upload, handle dropping it from
+	 - here, if desired. In this case, the remote it was
+	 - uploaded to is known to have it.
+	 -
+	 - Also, after a successful transfer, the location
+	 - log has changed. Indicate that a commit has been
+	 - made, in order to queue a push of the git-annex
+	 - branch out to remotes that did not participate
+	 - in the transfer.
+	 -
+	 - If the process failed, it could have crashed,
+	 - so remove the transfer from the list of current
+	 - transfers, just in case it didn't stop
+	 - in a way that lets the TransferWatcher do its
+	 - usual cleanup. However, first check if something else is
+	 - running the transfer, to avoid removing active transfers.
+	 -}
+	go remote sd transferrer = ifM (isRight <$> performTransfer sd AssistantLevel liftAnnex (transferRemote info) t info transferrer)
+		( do
+			case associatedFile info of
+				AssociatedFile Nothing -> noop
+				AssociatedFile (Just af) -> void $ 
+					addAlert $ makeAlertFiller True $
+						transferFileAlert direction True (fromRawFilePath af)
+			unless isdownload $
+				handleDrops
+					("object uploaded to " ++ show remote)
+					True (transferKey t)
+					(associatedFile info)
+					[mkVerifiedCopy RecentlyVerifiedCopy remote]
+			void recordCommit
+		, whenM (liftAnnex $ isNothing <$> checkTransfer t) $
+			void $ removeTransfer t
+		)
+
+{- Called right before a transfer begins, this is a last chance to avoid
+ - unnecessary transfers.
+ -
+ - For downloads, we obviously don't need to download if the already
+ - have the object.
+ -
+ - Smilarly, for uploads, check if the remote is known to already have
+ - the object.
+ -
+ - Also, uploads get queued to all remotes, in order of cost.
+ - This may mean, for example, that an object is uploaded over the LAN
+ - to a locally paired client, and once that upload is done, a more
+ - expensive transfer remote no longer wants the object. (Since
+ - all the clients have it already.) So do one last check if this is still
+ - preferred content.
+ -
+ - We'll also do one last preferred content check for downloads. An
+ - example of a case where this could be needed is if a download is queued
+ - for a file that gets moved out of an archive directory -- but before
+ - that download can happen, the file is put back in the archive.
+ -}
+shouldTransfer :: Transfer -> TransferInfo -> Annex Bool
+shouldTransfer t info
+	| transferDirection t == Download =
+		(not <$> inAnnex key) <&&> wantGet True (Just key) file
+	| transferDirection t == Upload = case transferRemote info of
+		Nothing -> return False
+		Just r -> notinremote r
+			<&&> wantGetBy True (Just key) file (Remote.uuid r)
+	| otherwise = return False
+  where
+	key = transferKey t
+	file = associatedFile info
+
+	{- Trust the location log to check if the remote already has
+	 - the key. This avoids a roundtrip to the remote. -}
+	notinremote r = notElem (Remote.uuid r) <$> loggedLocations key
+
+{- Queue uploads of files downloaded to us, spreading them
+ - out to other reachable remotes.
+ -
+ - Downloading a file may have caused a remote to not want it;
+ - so check for drops from remotes.
+ -
+ - Uploading a file may cause the local repo, or some other remote to not
+ - want it; handle that too.
+ -}
+finishedTransfer :: Transfer -> Maybe TransferInfo -> Assistant ()
+finishedTransfer t (Just info)
+	| transferDirection t == Download =
+		whenM (liftAnnex $ inAnnex $ transferKey t) $ do
+			dodrops False
+			void $ queueTransfersMatching (/= transferUUID t)
+				"newly received object"
+				Later (transferKey t) (associatedFile info) Upload
+	| otherwise = dodrops True
+  where
+	dodrops fromhere = do
+		qp <- liftAnnex $ coreQuotePath <$> Annex.getGitConfig
+		handleDrops
+			("drop wanted after " ++ describeTransfer qp t info)
+			fromhere (transferKey t) (associatedFile info) []
+finishedTransfer _ _ = noop
+
+{- Pause a running transfer. -}
+pauseTransfer :: Transfer -> Assistant ()
+pauseTransfer = cancelTransfer True
+
+{- Cancel a running transfer. -}
+cancelTransfer :: Bool -> Transfer -> Assistant ()
+cancelTransfer pause t = do
+	m <- getCurrentTransfers
+	unless pause $
+		{- remove queued transfer -}
+		void $ dequeueTransfers $ equivilantTransfer t
+	{- stop running transfer -}
+	maybe noop stop (M.lookup t m)
+  where
+	stop info = do
+		{- When there's a thread associated with the
+		 - transfer, it's signaled first, to avoid it
+		 - displaying any alert about the transfer having
+		 - failed when the transfer process is killed. -}
+		liftIO $ maybe noop signalthread $ transferTid info
+		liftIO $ maybe noop killproc $ transferPid info
+		if pause
+			then void $ alterTransferInfo t $
+				\i -> i { transferPaused = True }
+			else void $ removeTransfer t
+	signalthread tid
+		| pause = throwTo tid PauseTransfer
+		| otherwise = killThread tid
+	killproc pid = void $ tryIO $ do
+#ifndef mingw32_HOST_OS
+		{- In order to stop helper processes like rsync,
+		 - kill the whole process group of the process
+		 - running the transfer. -}
+		g <- getProcessGroupIDOf pid
+		let signal sig = void $ tryIO $ signalProcessGroup sig g
+		signal sigTERM
+		threadDelay 50000 -- 0.05 second grace period
+		signal sigKILL
+#else
+		terminateProcessById pid
+#endif
+
+{- Start or resume a transfer. -}
+startTransfer :: Transfer -> Assistant ()
+startTransfer t = do
+	m <- getCurrentTransfers
+	maybe startqueued go (M.lookup t m)
+  where
+	go info = maybe (start info) resume $ transferTid info
+	startqueued = do
+		is <- map snd <$> getMatchingTransfers (== t)
+		maybe noop start $ headMaybe is
+	resume tid = do
+		alterTransferInfo t $ \i -> i { transferPaused = False }
+		liftIO $ throwTo tid ResumeTransfer
+	start info = do
+		rt <- liftAnnex . mkRunTransferrer
+			=<< liftIO getBatchCommandMaker
+		inImmediateTransferSlot rt $
+			genTransfer t info
+
+getCurrentTransfers :: Assistant TransferMap
+getCurrentTransfers = currentTransfers <$> getDaemonStatus
+
+checkNetworkConnections :: DaemonStatusHandle -> MkCheckTransferrer
+checkNetworkConnections dstatushandle = do
+	dstatus <- atomically $ readTVar dstatushandle
+	h <- newNotificationHandle False (networkConnectedNotifier dstatus)
+	return $ not <$> checkNotification h
diff --git a/Assistant/Types/Alert.hs b/Assistant/Types/Alert.hs
new file mode 100644
index 0000000000..e6dcdc9ce2
--- /dev/null
+++ b/Assistant/Types/Alert.hs
@@ -0,0 +1,79 @@
+{- git-annex assistant alert types
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.Alert where
+
+import Utility.Tense
+
+import Data.Text (Text)
+import qualified Data.Map as M
+
+{- Different classes of alerts are displayed differently. -}
+data AlertClass = Success | Message | Activity | Warning | Error
+	deriving (Eq, Ord)
+
+data AlertPriority = Filler | Low | Medium | High | Pinned
+	deriving (Eq, Ord)
+
+{- An alert can have an name, which is used to combine it with other similar
+ - alerts. -}
+data AlertName 
+	= FileAlert TenseChunk
+	| SanityCheckFixAlert
+	| WarningAlert String
+	| PairAlert String
+	| ConnectionNeededAlert
+	| RemoteRemovalAlert String
+	| CloudRepoNeededAlert
+	| SyncAlert
+	| NotFsckedAlert
+	| UpgradeAlert
+	| UnusedFilesAlert
+	deriving (Eq)
+
+{- The first alert is the new alert, the second is an old alert.
+ - Should return a modified version of the old alert. -}
+type AlertCombiner = Alert -> Alert -> Maybe Alert
+
+data Alert = Alert
+	{ alertClass :: AlertClass
+	, alertHeader :: Maybe TenseText
+	, alertMessageRender :: Alert -> TenseText
+	, alertData :: [TenseChunk]
+	, alertCounter :: Int
+	, alertBlockDisplay :: Bool
+	, alertClosable :: Bool
+	, alertPriority :: AlertPriority
+	, alertIcon :: Maybe AlertIcon
+	, alertCombiner :: Maybe AlertCombiner
+	, alertName :: Maybe AlertName
+	, alertButtons :: [AlertButton]
+	}
+
+data AlertIcon = ActivityIcon | SyncIcon | SuccessIcon | ErrorIcon | InfoIcon | UpgradeIcon | ConnectionIcon
+
+type AlertMap = M.Map AlertId Alert
+
+{- Higher AlertId indicates a more recent alert. -}
+newtype AlertId = AlertId Integer
+	deriving (Read, Show, Eq, Ord)
+
+firstAlertId :: AlertId
+firstAlertId = AlertId 0
+
+nextAlertId :: AlertId -> AlertId
+nextAlertId (AlertId i) = AlertId $ succ i
+
+{- When clicked, a button always redirects to a URL
+ - It may also run an IO action in the background, which is useful
+ - to make the button close or otherwise change the alert. -}
+data AlertButton = AlertButton
+	{ buttonLabel :: Text
+	, buttonUrl :: Text
+	, buttonAction :: Maybe (AlertId -> IO ())
+	, buttonPrimary :: Bool
+	}
diff --git a/Assistant/Types/BranchChange.hs b/Assistant/Types/BranchChange.hs
new file mode 100644
index 0000000000..1f4128b754
--- /dev/null
+++ b/Assistant/Types/BranchChange.hs
@@ -0,0 +1,20 @@
+{- git-annex assistant git-annex branch change tracking
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.BranchChange where
+
+import Control.Concurrent.MSampleVar
+import Control.Applicative
+import Prelude
+
+newtype BranchChangeHandle = BranchChangeHandle (MSampleVar ())
+
+newBranchChangeHandle :: IO BranchChangeHandle
+newBranchChangeHandle = BranchChangeHandle <$> newEmptySV
+
+fromBranchChangeHandle :: BranchChangeHandle -> MSampleVar ()
+fromBranchChangeHandle (BranchChangeHandle v) = v
diff --git a/Assistant/Types/Changes.hs b/Assistant/Types/Changes.hs
new file mode 100644
index 0000000000..a08810ba54
--- /dev/null
+++ b/Assistant/Types/Changes.hs
@@ -0,0 +1,101 @@
+{- git-annex assistant change tracking
+ -
+ - Copyright 2012-2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Assistant.Types.Changes where
+
+import Types.KeySource
+import Types.Key
+import Utility.TList
+import Utility.FileSystemEncoding
+import Annex.Ingest
+
+import Control.Concurrent.STM
+import Data.Time.Clock
+import qualified Data.Set as S
+
+{- An un-ordered pool of Changes that have been noticed and should be
+ - staged and committed. Changes will typically be in order, but ordering
+ - may be lost. In any case, order should not matter, as any given Change
+ - may later be reverted by a later Change (ie, a file is added and then
+ - deleted). Code that processes the changes needs to deal with such
+ - scenarios.
+ -}
+type ChangePool = TList Change
+
+newChangePool :: IO ChangePool
+newChangePool = atomically newTList
+
+data Change
+	= Change 
+		{ changeTime :: UTCTime
+		, _changeFile :: FilePath
+		, changeInfo :: ChangeInfo
+		}
+	| PendingAddChange
+		{ changeTime ::UTCTime
+		, _changeFile :: FilePath
+		}
+	| InProcessAddChange
+		{ changeTime ::UTCTime
+		, lockedDown :: LockedDown
+		}
+	deriving (Show)
+
+data ChangeInfo = AddKeyChange Key | AddFileChange | LinkChange (Maybe Key) | RmChange
+	deriving (Show, Eq, Ord)
+
+changeInfoKey :: ChangeInfo -> Maybe Key
+changeInfoKey (AddKeyChange k) = Just k
+changeInfoKey (LinkChange (Just k)) = Just k
+changeInfoKey _ = Nothing
+
+changeFile :: Change -> FilePath
+changeFile (Change _ f _) = f
+changeFile (PendingAddChange _ f) = f
+changeFile (InProcessAddChange _ ld) = fromRawFilePath $ keyFilename $ keySource ld
+
+isPendingAddChange :: Change -> Bool
+isPendingAddChange (PendingAddChange {}) = True
+isPendingAddChange _ = False
+
+isInProcessAddChange :: Change -> Bool
+isInProcessAddChange (InProcessAddChange {}) = True
+isInProcessAddChange _ = False
+
+retryChange :: Change -> Change
+retryChange c@(InProcessAddChange time _) =
+	PendingAddChange time $ changeFile c
+retryChange c = c
+
+finishedChange :: Change -> Key -> Change
+finishedChange c@(InProcessAddChange {}) k = Change
+	{ changeTime = changeTime c
+	, _changeFile = changeFile c
+	, changeInfo = AddKeyChange k
+	}
+finishedChange c _ = c
+
+{- Combine PendingAddChanges that are for the same file.
+ - Multiple such often get noticed when eg, a file is opened and then
+ - closed in quick succession. -}
+simplifyChanges :: [Change] -> [Change]
+simplifyChanges [c] = [c]
+simplifyChanges cl = go cl S.empty []
+  where
+ 	go [] _ l = reverse l
+	go (c:cs) seen l
+		| isPendingAddChange c =
+			if S.member f seen 
+				then go cs seen l
+				else 
+					let !seen' = S.insert f seen
+					in go cs seen' (c:l)
+		| otherwise = go cs seen (c:l)
+	  where
+		f = changeFile c
diff --git a/Assistant/Types/Commits.hs b/Assistant/Types/Commits.hs
new file mode 100644
index 0000000000..d7c13b027e
--- /dev/null
+++ b/Assistant/Types/Commits.hs
@@ -0,0 +1,19 @@
+{- git-annex assistant commit tracking
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.Commits where
+
+import Utility.TList
+
+import Control.Concurrent.STM
+
+type CommitChan = TList Commit
+
+data Commit = Commit
+
+newCommitChan :: IO CommitChan
+newCommitChan = atomically newTList
diff --git a/Assistant/Types/CredPairCache.hs b/Assistant/Types/CredPairCache.hs
new file mode 100644
index 0000000000..d70c47b943
--- /dev/null
+++ b/Assistant/Types/CredPairCache.hs
@@ -0,0 +1,18 @@
+{- git-annex assistant CredPair cache.
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.CredPairCache where
+
+import Types.Creds
+
+import Control.Concurrent
+import qualified Data.Map as M
+
+type CredPairCache = MVar (M.Map Login Password)
+
+newCredPairCache :: IO CredPairCache
+newCredPairCache = newMVar M.empty
diff --git a/Assistant/Types/DaemonStatus.hs b/Assistant/Types/DaemonStatus.hs
new file mode 100644
index 0000000000..9c547aa10a
--- /dev/null
+++ b/Assistant/Types/DaemonStatus.hs
@@ -0,0 +1,119 @@
+{- git-annex assistant daemon status
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.DaemonStatus where
+
+import Annex.Common
+import Assistant.Pairing
+import Utility.NotificationBroadcaster
+import Types.Transfer
+import Assistant.Types.ThreadName
+import Assistant.Types.Alert
+import Utility.Url
+
+import Control.Concurrent.STM
+import Control.Concurrent.MVar
+import Control.Concurrent.Async
+import Data.Time.Clock.POSIX
+import qualified Data.Map as M
+import qualified Data.Set as S
+
+data DaemonStatus = DaemonStatus
+	-- All the named threads that comprise the daemon,
+	-- and actions to run to restart them.
+	{ startedThreads :: M.Map ThreadName (Async (), IO ())
+	-- False when the daemon is performing its startup scan
+	, scanComplete :: Bool
+	-- True when all files should be restaged.
+	, forceRestage :: Bool
+	-- Time when a previous process of the daemon was running ok
+	, lastRunning :: Maybe POSIXTime
+	-- True when the daily sanity checker is running
+	, sanityCheckRunning :: Bool
+	-- Last time the daily sanity checker ran
+	, lastSanityCheck :: Maybe POSIXTime
+	-- True when a scan for file transfers is running
+	, transferScanRunning :: Bool
+	-- Currently running file content transfers
+	, currentTransfers :: TransferMap
+	-- Messages to display to the user.
+	, alertMap :: AlertMap
+	, lastAlertId :: AlertId
+	-- Ordered list of all remotes that can be synced with
+	, syncRemotes :: [Remote]
+	-- Ordered list of remotes to sync git with
+	, syncGitRemotes :: [Remote]
+	-- Ordered list of remotes to sync data with
+	, syncDataRemotes :: [Remote]
+	-- Ordered list of remotes to export to
+	, exportRemotes :: [Remote]
+	-- Ordered list of remotes that data can be downloaded from
+	, downloadRemotes :: [Remote]
+	-- Are we syncing to any cloud remotes?
+	, syncingToCloudRemote :: Bool
+	-- Set of uuids of remotes that are currently connected.
+	, currentlyConnectedRemotes :: S.Set UUID
+	-- Pairing request that is in progress.
+	, pairingInProgress :: Maybe PairingInProgress
+	-- Broadcasts notifications about all changes to the DaemonStatus.
+	, changeNotifier :: NotificationBroadcaster
+	-- Broadcasts notifications when queued or current transfers change.
+	, transferNotifier :: NotificationBroadcaster
+	-- Broadcasts notifications when there's a change to the alerts.
+	, alertNotifier :: NotificationBroadcaster
+	-- Broadcasts notifications when the syncRemotes change.
+	, syncRemotesNotifier :: NotificationBroadcaster
+	-- Broadcasts notifications when the scheduleLog changes.
+	, scheduleLogNotifier :: NotificationBroadcaster
+	-- Broadcasts a notification once the startup sanity check has run.
+	, startupSanityCheckNotifier :: NotificationBroadcaster
+	-- Broadcasts notifications when the network is connected.
+	, networkConnectedNotifier :: NotificationBroadcaster
+	-- Broadcasts notifications when a global redirect is needed.
+	, globalRedirNotifier :: NotificationBroadcaster
+	, globalRedirUrl :: Maybe URLString
+	-- Actions to run after a Key is transferred.
+	, transferHook :: M.Map Key (Transfer -> IO ())
+	-- MVars to signal when a remote gets connected.
+	, connectRemoteNotifiers :: M.Map UUID [MVar ()]
+	}
+
+type TransferMap = M.Map Transfer TransferInfo
+
+type DaemonStatusHandle = TVar DaemonStatus
+
+newDaemonStatus :: IO DaemonStatus
+newDaemonStatus = DaemonStatus
+	<$> pure M.empty
+	<*> pure False
+	<*> pure False
+	<*> pure Nothing
+	<*> pure False
+	<*> pure Nothing
+	<*> pure False
+	<*> pure M.empty
+	<*> pure M.empty
+	<*> pure firstAlertId
+	<*> pure []
+	<*> pure []
+	<*> pure []
+	<*> pure []
+	<*> pure []
+	<*> pure False
+	<*> pure S.empty
+	<*> pure Nothing
+	<*> newNotificationBroadcaster
+	<*> newNotificationBroadcaster
+	<*> newNotificationBroadcaster
+	<*> newNotificationBroadcaster
+	<*> newNotificationBroadcaster
+	<*> newNotificationBroadcaster
+	<*> newNotificationBroadcaster
+	<*> newNotificationBroadcaster
+	<*> pure Nothing
+	<*> pure M.empty
+	<*> pure M.empty
diff --git a/Assistant/Types/NamedThread.hs b/Assistant/Types/NamedThread.hs
new file mode 100644
index 0000000000..866affc90c
--- /dev/null
+++ b/Assistant/Types/NamedThread.hs
@@ -0,0 +1,21 @@
+{- named threads
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.NamedThread where
+
+import Assistant.Monad
+import Assistant.Types.ThreadName
+
+{- Information about a named thread that can be run. -}
+data NamedThread = NamedThread Bool ThreadName (Assistant ())
+
+namedThread :: String -> Assistant () -> NamedThread
+namedThread = NamedThread True . ThreadName
+
+{- A named thread that can start running before the startup sanity check. -}
+namedThreadUnchecked :: String -> Assistant () -> NamedThread
+namedThreadUnchecked = NamedThread False . ThreadName
diff --git a/Assistant/Types/Pushes.hs b/Assistant/Types/Pushes.hs
new file mode 100644
index 0000000000..57cafb4fae
--- /dev/null
+++ b/Assistant/Types/Pushes.hs
@@ -0,0 +1,24 @@
+{- git-annex assistant push tracking
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.Pushes where
+
+import Annex.Common
+
+import Control.Concurrent.STM
+import Data.Time.Clock
+import qualified Data.Map as M
+
+{- Track the most recent push failure for each remote. -}
+type PushMap = M.Map Remote UTCTime
+type FailedPushMap = TMVar PushMap
+
+{- The TMVar starts empty, and is left empty when there are no
+ - failed pushes. This way we can block until there are some failed pushes.
+ -}
+newFailedPushMap :: IO FailedPushMap
+newFailedPushMap = atomically newEmptyTMVar
diff --git a/Assistant/Types/RemoteControl.hs b/Assistant/Types/RemoteControl.hs
new file mode 100644
index 0000000000..433a37bd9b
--- /dev/null
+++ b/Assistant/Types/RemoteControl.hs
@@ -0,0 +1,16 @@
+{- git-annex assistant RemoteDaemon control
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.RemoteControl where
+
+import qualified RemoteDaemon.Types as RemoteDaemon
+import Control.Concurrent
+
+type RemoteControl = Chan RemoteDaemon.Consumed
+
+newRemoteControl :: IO RemoteControl
+newRemoteControl = newChan
diff --git a/Assistant/Types/RepoProblem.hs b/Assistant/Types/RepoProblem.hs
new file mode 100644
index 0000000000..afc7e4b2f3
--- /dev/null
+++ b/Assistant/Types/RepoProblem.hs
@@ -0,0 +1,28 @@
+{- git-annex assistant repository problem tracking
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.RepoProblem where
+
+import Types
+import Utility.TList
+
+import Control.Concurrent.STM
+import Data.Function
+
+data RepoProblem = RepoProblem
+	{ problemUUID :: UUID
+	, afterFix :: IO ()
+	}
+
+{- The afterFix actions are assumed to all be equivalent. -}
+sameRepoProblem :: RepoProblem -> RepoProblem -> Bool
+sameRepoProblem = (==) `on` problemUUID
+
+type RepoProblemChan = TList RepoProblem
+
+newRepoProblemChan :: IO RepoProblemChan
+newRepoProblemChan = atomically newTList
diff --git a/Assistant/Types/ScanRemotes.hs b/Assistant/Types/ScanRemotes.hs
new file mode 100644
index 0000000000..09fa75a877
--- /dev/null
+++ b/Assistant/Types/ScanRemotes.hs
@@ -0,0 +1,25 @@
+{- git-annex assistant remotes needing scanning
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.ScanRemotes where
+
+import Annex.Common
+
+import Control.Concurrent.STM
+import qualified Data.Map as M
+
+data ScanInfo = ScanInfo
+	{ scanPriority :: Float
+	, fullScan :: Bool
+	}
+
+type ScanRemoteMap = TMVar (M.Map Remote ScanInfo)
+
+{- The TMVar starts empty, and is left empty when there are no remotes
+ - to scan. -}
+newScanRemoteMap :: IO ScanRemoteMap
+newScanRemoteMap = atomically newEmptyTMVar
diff --git a/Assistant/Types/ThreadName.hs b/Assistant/Types/ThreadName.hs
new file mode 100644
index 0000000000..06435f474f
--- /dev/null
+++ b/Assistant/Types/ThreadName.hs
@@ -0,0 +1,14 @@
+{- name of a thread
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.ThreadName where
+
+newtype ThreadName = ThreadName String
+	deriving (Eq, Read, Show, Ord)
+
+fromThreadName :: ThreadName -> String
+fromThreadName (ThreadName n) = n
diff --git a/Assistant/Types/ThreadedMonad.hs b/Assistant/Types/ThreadedMonad.hs
new file mode 100644
index 0000000000..4c07317807
--- /dev/null
+++ b/Assistant/Types/ThreadedMonad.hs
@@ -0,0 +1,40 @@
+{- making the Annex monad available across threads
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.ThreadedMonad where
+
+import Annex.Common
+import qualified Annex
+
+import Control.Concurrent
+import Data.Tuple
+
+{- The Annex state is stored in a MVar, so that threaded actions can access
+ - it. -}
+type ThreadState = MVar (Annex.AnnexState, Annex.AnnexRead)
+
+{- Stores the Annex state in a MVar.
+ -
+ - Once the action is finished, retrieves the state from the MVar.
+ -}
+withThreadState :: (ThreadState -> Annex a) -> Annex a
+withThreadState a = do
+	state <- Annex.getState id
+	rd <- Annex.getRead id
+	mvar <- liftIO $ newMVar (state, rd)
+	r <- a mvar
+	newstate <- liftIO $ fst <$> takeMVar mvar
+	Annex.changeState (const newstate)
+	return r
+
+{- Runs an Annex action, using the state from the MVar. 
+ -
+ - This serializes calls by threads; only one thread can run in Annex at a
+ - time. -}
+runThreadState :: ThreadState -> Annex a -> IO a
+runThreadState mvar a = modifyMVar mvar $ \v -> swap <$> Annex.run v a
+
diff --git a/Assistant/Types/TransferQueue.hs b/Assistant/Types/TransferQueue.hs
new file mode 100644
index 0000000000..f15a43200c
--- /dev/null
+++ b/Assistant/Types/TransferQueue.hs
@@ -0,0 +1,29 @@
+{- git-annex assistant pending transfer queue
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.Types.TransferQueue where
+
+import Annex.Common
+import Types.Transfer
+
+import Control.Concurrent.STM
+import Utility.TList
+
+data TransferQueue = TransferQueue
+	{ queuesize :: TVar Int
+	, queuelist :: TList (Transfer, TransferInfo)
+	, deferreddownloads :: TList (Key, AssociatedFile)
+	}
+
+data Schedule = Next | Later
+	deriving (Eq)
+
+newTransferQueue :: IO TransferQueue
+newTransferQueue = atomically $ TransferQueue
+	<$> newTVar 0
+	<*> newTList
+	<*> newTList
diff --git a/Assistant/Types/TransferSlots.hs b/Assistant/Types/TransferSlots.hs
new file mode 100644
index 0000000000..bbcc84fb4b
--- /dev/null
+++ b/Assistant/Types/TransferSlots.hs
@@ -0,0 +1,34 @@
+{- git-annex assistant transfer slots
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE DeriveDataTypeable #-}
+
+module Assistant.Types.TransferSlots where
+
+import qualified Control.Exception as E
+import qualified Control.Concurrent.MSemN as MSemN
+import Data.Typeable
+
+type TransferSlots = MSemN.MSemN Int
+
+{- A special exception that can be thrown to pause or resume a transfer, while
+ - keeping its slot in use. -}
+data TransferException = PauseTransfer | ResumeTransfer
+	deriving (Show, Eq, Typeable)
+
+instance E.Exception TransferException
+
+{- Number of concurrent transfers allowed to be run from the assistant.
+ -
+ - Transfers launched by other means, including by remote assistants,
+ - do not currently take up slots.
+ -}
+numSlots :: Int
+numSlots = 1
+
+newTransferSlots :: IO TransferSlots
+newTransferSlots = MSemN.new numSlots
diff --git a/Assistant/Types/UrlRenderer.hs b/Assistant/Types/UrlRenderer.hs
new file mode 100644
index 0000000000..f0ffb10acd
--- /dev/null
+++ b/Assistant/Types/UrlRenderer.hs
@@ -0,0 +1,26 @@
+{- webapp url renderer access from the assistant
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Assistant.Types.UrlRenderer (
+	UrlRenderer,
+	newUrlRenderer
+) where
+
+#ifdef WITH_WEBAPP
+
+import Assistant.WebApp (UrlRenderer, newUrlRenderer)
+
+#else
+
+data UrlRenderer = UrlRenderer -- dummy type
+
+newUrlRenderer :: IO UrlRenderer
+newUrlRenderer = return UrlRenderer
+
+#endif
diff --git a/Assistant/Unused.hs b/Assistant/Unused.hs
new file mode 100644
index 0000000000..8af61527d2
--- /dev/null
+++ b/Assistant/Unused.hs
@@ -0,0 +1,85 @@
+{- git-annex assistant unused files
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Assistant.Unused where
+
+import qualified Data.Map as M
+
+import Assistant.Common
+import qualified Git
+import Logs.Unused
+import Logs.Location
+import Annex.Content
+import Utility.DataUnits
+import Utility.DiskFree
+import Utility.HumanTime
+import Utility.Tense
+
+import Data.Time.Clock.POSIX
+import qualified Data.Text as T
+
+describeUnused :: Assistant (Maybe TenseText)
+describeUnused = describeUnused' False
+
+describeUnusedWhenBig :: Assistant (Maybe TenseText)
+describeUnusedWhenBig = describeUnused' True
+
+{- This uses heuristics: 1000 unused keys, or more unused keys 
+ - than the remaining free disk space, or more than 1/10th the total
+ - disk space being unused keys all suggest a problem. -}
+describeUnused' :: Bool -> Assistant (Maybe TenseText)
+describeUnused' whenbig = liftAnnex $ go =<< readUnusedLog ""
+  where
+	go m = do
+		let num = M.size m
+		let diskused = foldl' sumkeysize 0 (M.keys m)
+		df <- forpath getDiskFree
+		disksize <- forpath getDiskSize
+		return $ if num == 0
+			then Nothing
+			else if not whenbig || moreused df diskused || tenthused disksize diskused
+				then Just $ tenseWords
+					[ UnTensed $ T.pack $ roughSize storageUnits False diskused
+					, Tensed "are" "were"
+					, "taken up by unused files"
+					]
+				else if num > 1000
+					then Just $ tenseWords
+						[ UnTensed $ T.pack $ show num ++ " unused files"
+						, Tensed "exist" "existed"
+						]
+					else Nothing
+
+	moreused Nothing _ = False
+	moreused (Just df) used = df <= used
+
+	tenthused Nothing _ = False
+	tenthused (Just disksize) used = used >= disksize `div` 10
+
+	sumkeysize s k = s + fromMaybe 0 (fromKey keySize k)
+
+	forpath a = inRepo $ liftIO . a . fromRawFilePath . Git.repoPath
+
+{- With a duration, expires all unused files that are older.
+ - With Nothing, expires *all* unused files. -}
+expireUnused :: Maybe Duration -> Assistant ()
+expireUnused duration = do
+	m <- liftAnnex $ readUnusedLog ""
+	now <- liftIO getPOSIXTime
+	let oldkeys = M.keys $ M.filter (tooold now) m
+	forM_ oldkeys $ \k -> do
+		debug ["removing old unused key", serializeKey k]
+		liftAnnex $ tryNonAsync $ do
+			lockContentForRemoval k noop removeAnnex
+			logStatus k InfoMissing
+  where
+	boundary = durationToPOSIXTime <$> duration
+	tooold now (_, mt) = case boundary of
+		Nothing -> True
+		Just b -> maybe False (\t -> now - t >= b) mt
diff --git a/Assistant/Upgrade.hs b/Assistant/Upgrade.hs
new file mode 100644
index 0000000000..419c133a62
--- /dev/null
+++ b/Assistant/Upgrade.hs
@@ -0,0 +1,377 @@
+{- git-annex assistant upgrading
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Assistant.Upgrade where
+
+import Assistant.Common
+import Assistant.Restart
+import qualified Annex
+import Assistant.Alert
+import Assistant.DaemonStatus
+import Utility.Env
+import Utility.Env.Set
+import Types.Distribution
+import Types.Transfer
+import Logs.Web
+import Logs.Presence
+import Logs.Location
+import Annex.Content
+import Annex.UUID
+import qualified Backend
+import qualified Types.Backend
+import Assistant.TransferQueue
+import Assistant.TransferSlots
+import Remote (remoteFromUUID)
+import Annex.Path
+import Config.Files
+import Utility.ThreadScheduler
+import Utility.Tmp.Dir
+import Utility.UserInfo
+import Utility.Gpg
+import Utility.FileMode
+import Utility.Metered
+import qualified Utility.Lsof as Lsof
+import qualified BuildInfo
+import qualified Utility.Url as Url
+import qualified Annex.Url as Url hiding (download)
+import Utility.Tuple
+import qualified Utility.RawFilePath as R
+
+import Data.Either
+import qualified Data.Map as M
+
+{- Upgrade without interaction in the webapp. -}
+unattendedUpgrade :: Assistant ()
+unattendedUpgrade = do
+	prepUpgrade
+	url <- runRestart
+	postUpgrade url
+
+prepUpgrade :: Assistant ()
+prepUpgrade = do
+	void $ addAlert upgradingAlert
+	liftIO $ setEnv upgradedEnv "1" True
+	prepRestart
+
+postUpgrade :: URLString -> Assistant ()
+postUpgrade = postRestart
+
+autoUpgradeEnabled :: Assistant Bool
+autoUpgradeEnabled = liftAnnex $ (==) AutoUpgrade . annexAutoUpgrade <$> Annex.getGitConfig
+
+checkSuccessfulUpgrade :: IO Bool
+checkSuccessfulUpgrade = isJust <$> getEnv upgradedEnv
+
+upgradedEnv :: String
+upgradedEnv = "GIT_ANNEX_UPGRADED"
+
+{- Start downloading the distribution key from the web.
+ - Install a hook that will be run once the download is complete,
+ - and finishes the upgrade.
+ -
+ - Creates the destination directory where the upgrade will be installed
+ - early, in order to check if another upgrade has happened (or is
+ - happending). On failure, the directory is removed.
+ -}
+startDistributionDownload :: GitAnnexDistribution -> Assistant ()
+startDistributionDownload d = go =<< liftIO . newVersionLocation d =<< liftIO oldVersionLocation
+  where
+	go Nothing = debug ["Skipping redundant upgrade"]
+	go (Just dest) = do
+		liftAnnex $ setUrlPresent k u
+		hook <- asIO1 $ distributionDownloadComplete d dest cleanup
+		modifyDaemonStatus_ $ \s -> s
+			{ transferHook = M.insert k hook (transferHook s) }
+		maybe noop (queueTransfer "upgrade" Next (AssociatedFile (Just (toRawFilePath f))) t)
+			=<< liftAnnex (remoteFromUUID webUUID)
+		startTransfer t
+	k = mkKey $ const $ distributionKey d
+	u = distributionUrl d
+	f = takeFileName u ++ " (for upgrade)"
+	t = Transfer
+		{ transferDirection = Download
+		, transferUUID = webUUID
+		, transferKeyData = fromKey id k
+		}
+	cleanup = liftAnnex $ do
+		lockContentForRemoval k noop removeAnnex
+		setUrlMissing k u
+		logStatus k InfoMissing
+
+{- Called once the download is done.
+ - Passed an action that can be used to clean up the downloaded file.
+ -
+ - Verifies the content of the downloaded key.
+ -}
+distributionDownloadComplete :: GitAnnexDistribution -> FilePath -> Assistant () -> Transfer -> Assistant ()
+distributionDownloadComplete d dest cleanup t 
+	| transferDirection t == Download = do
+		debug ["finished downloading git-annex distribution"]
+		maybe (failedupgrade "bad download") go
+			=<< liftAnnex (withObjectLoc k fsckit)
+	| otherwise = cleanup
+  where
+	k = mkKey $ const $ distributionKey d
+	fsckit f = Backend.maybeLookupBackendVariety (fromKey keyVariety k) >>= \case
+		Nothing -> return $ Just (fromRawFilePath f)
+		Just b -> case Types.Backend.verifyKeyContent b of
+			Nothing -> return $ Just (fromRawFilePath f)
+			Just verifier -> ifM (verifier k f)
+				( return $ Just (fromRawFilePath f)
+				, return Nothing
+				)
+	go f = do
+		ua <- asIO $ upgradeToDistribution dest cleanup f
+		fa <- asIO1 failedupgrade
+		liftIO $ ua `catchNonAsync` (fa . show)
+	failedupgrade msg = do
+		void $ addAlert $ upgradeFailedAlert msg
+		cleanup
+		liftIO $ void $ tryIO $ removeDirectoryRecursive dest
+
+{- The upgrade method varies by OS.
+ -
+ - In general, find where the distribution was installed before,
+ - and unpack the new distribution next to it (in a versioned directory).
+ - Then update the programFile to point to the new version.
+ -}
+upgradeToDistribution :: FilePath -> Assistant () -> FilePath -> Assistant ()
+upgradeToDistribution newdir cleanup distributionfile = do
+	liftIO $ createDirectoryIfMissing True newdir
+	(program, deleteold) <- unpack
+	changeprogram program
+	cleanup
+	prepUpgrade
+	url <- runRestart
+	{- At this point, the new assistant is fully running, so
+	 - it's safe to delete the old version. -}
+	liftIO $ void $ tryIO deleteold
+	postUpgrade url
+  where
+	changeprogram program = liftIO $ do
+		unlessM (boolSystem program [Param "version"]) $
+			giveup "New git-annex program failed to run! Not using."
+		pf <- programFile
+		liftIO $ writeFile pf program
+	
+#ifdef darwin_HOST_OS
+	{- OS X uses a dmg, so mount it, and copy the contents into place. -}
+	unpack = liftIO $ do
+		olddir <- oldVersionLocation
+		withTmpDirIn (fromRawFilePath (parentDir (toRawFilePath newdir))) "git-annex.upgrade" $ \tmpdir -> do
+			void $ boolSystem "hdiutil"
+				[ Param "attach", File distributionfile
+				, Param "-mountpoint", File tmpdir
+				]
+			void $ boolSystem "cp"
+				[ Param "-R"
+				, File $ tmpdir </> installBase </> "Contents"
+				, File $ newdir
+				]
+			void $ boolSystem "hdiutil"
+				[ Param "eject"
+				, File tmpdir
+				]
+			sanitycheck newdir
+		let deleteold = do
+			deleteFromManifest $ olddir </> "Contents" </> "MacOS"
+			makeorigsymlink olddir
+		return (newdir </> "Contents" </> "MacOS" </> "git-annex", deleteold)
+#else
+	{- Linux uses a tarball (so could other POSIX systems), so
+	 - untar it (into a temp directory) and move the directory
+	 - into place. -}
+	unpack = liftIO $ do
+		olddir <- oldVersionLocation
+		withTmpDirIn (fromRawFilePath $ parentDir $ toRawFilePath newdir) "git-annex.upgrade" $ \tmpdir -> do
+			let tarball = tmpdir </> "tar"
+			-- Cannot rely on filename extension, and this also
+			-- avoids problems if tar doesn't support transparent
+			-- decompression.
+			void $ boolSystem "sh"
+				[ Param "-c"
+				, Param $ "zcat < " ++ shellEscape distributionfile ++
+					" > " ++ shellEscape tarball
+				]
+			tarok <- boolSystem "tar"
+				[ Param "xf"
+				, Param tarball
+				, Param "--directory", File tmpdir
+				]
+			unless tarok $
+				giveup $ "failed to untar " ++ distributionfile
+			sanitycheck $ tmpdir </> installBase
+			installby R.rename newdir (tmpdir </> installBase)
+		let deleteold = do
+			deleteFromManifest olddir
+			makeorigsymlink olddir
+		return (newdir </> "git-annex", deleteold)
+	installby a dstdir srcdir =
+		mapM_ (\x -> a (toRawFilePath x) (toRawFilePath (dstdir </> takeFileName x)))
+			=<< dirContents srcdir
+#endif
+	sanitycheck dir = 
+		unlessM (doesDirectoryExist dir) $
+			giveup $ "did not find " ++ dir ++ " in " ++ distributionfile
+	makeorigsymlink olddir = do
+		let origdir = fromRawFilePath (parentDir (toRawFilePath olddir)) </> installBase
+		removeWhenExistsWith R.removeLink (toRawFilePath origdir)
+		R.createSymbolicLink (toRawFilePath newdir) (toRawFilePath origdir)
+
+{- Finds where the old version was installed. -}
+oldVersionLocation :: IO FilePath
+oldVersionLocation = readProgramFile >>= \case
+	Nothing -> giveup "Cannot find old distribution bundle; not upgrading."
+	Just pf -> do
+		let pdir = fromRawFilePath $ parentDir $ toRawFilePath pf
+#ifdef darwin_HOST_OS
+		let dirs = splitDirectories pdir
+		{- It will probably be deep inside a git-annex.app directory. -}
+		let olddir = case findIndex ("git-annex.app" `isPrefixOf`) dirs of
+			Nothing -> pdir
+			Just i -> joinPath (take (i + 1) dirs)
+#else
+		let olddir = pdir
+#endif
+		when (null olddir) $
+			giveup $ "Cannot find old distribution bundle; not upgrading. (Looked in " ++ pdir ++ ")"
+		return olddir
+
+{- Finds a place to install the new version.
+ - Generally, put it in the parent directory of where the old version was
+ - installed, and use a version number in the directory name.
+ - If unable to write to there, instead put it in the home directory.
+ -
+ - The directory is created. If it already exists, returns Nothing.
+ -}
+newVersionLocation :: GitAnnexDistribution -> FilePath -> IO (Maybe FilePath)
+newVersionLocation d olddir = 
+	trymkdir newloc $ do
+		home <- myHomeDir
+		trymkdir (home </> s) $
+			return Nothing
+  where
+	s = installBase ++ "." ++ distributionVersion d
+	topdir = fromRawFilePath $ parentDir $ toRawFilePath olddir
+	newloc = topdir </> s
+	trymkdir dir fallback =
+		(createDirectory dir >> return (Just dir))
+			`catchIO` const fallback
+
+installBase :: String
+installBase = "git-annex." ++
+#ifdef linux_HOST_OS
+	"linux"
+#else
+#ifdef darwin_HOST_OS
+	"app"
+#else
+	"dir"
+#endif
+#endif
+
+deleteFromManifest :: FilePath -> IO ()
+deleteFromManifest dir = do
+	fs <- map (dir </>) . lines <$> catchDefaultIO "" (readFile manifest)
+	mapM_ (removeWhenExistsWith R.removeLink . toRawFilePath) fs
+	removeWhenExistsWith R.removeLink (toRawFilePath manifest)
+	removeEmptyRecursive dir
+  where
+	manifest = dir </> "git-annex.MANIFEST"
+
+removeEmptyRecursive :: FilePath -> IO ()
+removeEmptyRecursive dir = do
+	mapM_ removeEmptyRecursive =<< dirContents dir
+	void $ tryIO $ removeDirectory dir
+
+{- This is a file that the UpgradeWatcher can watch for modifications to
+ - detect when git-annex has been upgraded.
+ -}
+upgradeFlagFile :: IO FilePath
+upgradeFlagFile = programPath
+
+{- Sanity check to see if an upgrade is complete and the program is ready
+ - to be run. -}
+upgradeSanityCheck :: IO Bool
+upgradeSanityCheck = ifM usingDistribution
+	( doesFileExist =<< programFile
+	, do
+		-- Ensure that the program is present, and has no writers,
+		-- and can be run. This should handle distribution
+		-- upgrades, manual upgrades, etc.
+		program <- programPath
+		untilM (doesFileExist program <&&> nowriter program) $
+			threadDelaySeconds (Seconds 60)
+		boolSystem program [Param "version"]
+	)
+  where
+	nowriter f = null
+		. filter (`elem` [Lsof.OpenReadWrite, Lsof.OpenWriteOnly])
+		. map snd3
+		<$> Lsof.query [f]
+
+usingDistribution :: IO Bool
+usingDistribution = isJust <$> getEnv "GIT_ANNEX_STANDLONE_ENV"
+
+downloadDistributionInfo :: Assistant (Maybe GitAnnexDistribution)
+downloadDistributionInfo = do
+	uo <- liftAnnex Url.getUrlOptions
+	gpgcmd <- liftAnnex $ gpgCmd <$> Annex.getGitConfig
+	liftIO $ withTmpDir "git-annex.tmp" $ \tmpdir -> do
+		let infof = tmpdir </> "info"
+		let sigf = infof ++ ".sig"
+		ifM (isRight <$> Url.download nullMeterUpdate Nothing distributionInfoUrl infof uo
+			<&&> (isRight <$> Url.download nullMeterUpdate Nothing distributionInfoSigUrl sigf uo)
+			<&&> verifyDistributionSig gpgcmd sigf)
+			( parseInfoFile <$> readFileStrict infof
+			, return Nothing
+			)
+
+distributionInfoUrl :: String
+distributionInfoUrl = fromJust BuildInfo.upgradelocation ++ ".info"
+
+distributionInfoSigUrl :: String
+distributionInfoSigUrl = distributionInfoUrl ++ ".sig"
+
+{- Upgrade only supported on linux and OSX. -}
+upgradeSupported :: Bool
+#ifdef linux_HOST_OS
+upgradeSupported = isJust BuildInfo.upgradelocation
+#else
+#ifdef darwin_HOST_OS
+upgradeSupported = isJust BuildInfo.upgradelocation
+#else
+upgradeSupported = False
+#endif
+#endif
+
+{- Verifies that a file from the git-annex distribution has a valid
+ - signature. Pass the detached .sig file; the file to be verified should
+ - be located next to it.
+ -
+ - The gpg keyring used to verify the signature is located in
+ - trustedkeys.gpg, next to the git-annex program.
+ -}
+verifyDistributionSig :: GpgCmd -> FilePath -> IO Bool
+verifyDistributionSig gpgcmd sig = readProgramFile >>= \case
+	Just p | isAbsolute p ->
+		withUmask 0o0077 $ withTmpDir "git-annex-gpg.tmp" $ \gpgtmp -> do
+			let trustedkeys = takeDirectory p </> "trustedkeys.gpg"
+			boolGpgCmd gpgcmd
+				[ Param "--no-default-keyring"
+				, Param "--no-auto-check-trustdb"
+				, Param "--no-options"
+				, Param "--homedir"
+				, File gpgtmp
+				, Param "--keyring"
+				, File trustedkeys
+				, Param "--verify"
+				, File sig
+				]
+	_ -> return False
diff --git a/Assistant/WebApp.hs b/Assistant/WebApp.hs
new file mode 100644
index 0000000000..3d0b632717
--- /dev/null
+++ b/Assistant/WebApp.hs
@@ -0,0 +1,74 @@
+{- git-annex assistant webapp core
+ -
+ - Copyright 2012, 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeFamilies, QuasiQuotes, MultiParamTypeClasses #-}
+{-# LANGUAGE TemplateHaskell, OverloadedStrings, RankNTypes #-}
+
+module Assistant.WebApp where
+
+import Assistant.WebApp.Types
+import Assistant.Common
+import Utility.NotificationBroadcaster
+import Utility.Yesod
+import Utility.AuthToken
+
+import Data.Text (Text)
+import Control.Concurrent
+import qualified Network.Wai as W
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.Text as T
+
+waitNotifier :: Assistant NotificationBroadcaster -> NotificationId -> Handler ()
+waitNotifier getbroadcaster nid = liftAssistant $ do
+	b <- getbroadcaster
+	liftIO $ waitNotification $ notificationHandleFromId b nid
+
+newNotifier :: Assistant NotificationBroadcaster -> Handler NotificationId
+newNotifier getbroadcaster = liftAssistant $ do
+	b <- getbroadcaster
+	liftIO $ notificationHandleToId <$> newNotificationHandle True b
+
+{- Adds the auth parameter as a hidden field on a form. Must be put into
+ - every form. -}
+webAppFormAuthToken :: Widget
+webAppFormAuthToken = do
+	webapp <- liftH getYesod
+	[whamlet|<input type="hidden" name="auth" value="#{fromAuthToken (authToken webapp)}">|]
+
+{- A button with an icon, and maybe label or tooltip, that can be
+ - clicked to perform some action.
+ - With javascript, clicking it POSTs the Route, and remains on the same
+ - page.
+ - With noscript, clicking it GETs the Route. -}
+actionButton :: Route WebApp -> (Maybe String) -> (Maybe String) -> String -> String -> Widget
+actionButton route label tooltip buttonclass iconclass = $(widgetFile "actionbutton")
+
+type UrlRenderFunc = Route WebApp -> [(Text, Text)] -> Text
+type UrlRenderer = MVar (UrlRenderFunc)
+
+newUrlRenderer :: IO UrlRenderer
+newUrlRenderer = newEmptyMVar
+
+setUrlRenderer :: UrlRenderer -> (UrlRenderFunc) -> IO ()
+setUrlRenderer = putMVar
+
+inFirstRun :: Handler Bool
+inFirstRun = isNothing . relDir <$> getYesod
+
+{- Blocks until the webapp is running and has called setUrlRenderer. -}
+renderUrl :: UrlRenderer -> Route WebApp -> [(Text, Text)] -> IO Text
+renderUrl urlrenderer route params = do
+	r <- readMVar urlrenderer
+	return $ r route params
+
+{- Redirects back to the referring page, or if there's none, DashboardR -}
+redirectBack :: Handler ()
+redirectBack = do
+	mr <- lookup "referer" . W.requestHeaders <$> waiRequest
+	case mr of
+		Nothing -> redirect DashboardR
+		Just r -> redirect $ T.pack $ S8.unpack r
diff --git a/Assistant/WebApp/Common.hs b/Assistant/WebApp/Common.hs
new file mode 100644
index 0000000000..a148dcabdb
--- /dev/null
+++ b/Assistant/WebApp/Common.hs
@@ -0,0 +1,17 @@
+{- git-annex assistant webapp, common imports
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.WebApp.Common (module X) where
+
+import Assistant.Common as X
+import Assistant.WebApp as X
+import Assistant.WebApp.Page as X
+import Assistant.WebApp.Form as X
+import Assistant.WebApp.Types as X
+import Assistant.WebApp.RepoId as X
+import Utility.Yesod as X hiding (textField, passwordField, insertBy, replace, joinPath, deleteBy, delete, insert, Key, Option, PermissionDenied)
+import Data.Text as X (Text)
diff --git a/Assistant/WebApp/Configurators.hs b/Assistant/WebApp/Configurators.hs
new file mode 100644
index 0000000000..0042638b15
--- /dev/null
+++ b/Assistant/WebApp/Configurators.hs
@@ -0,0 +1,44 @@
+{- git-annex assistant webapp configurators
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Configurators where
+
+import Assistant.WebApp.Common
+import Assistant.WebApp.RepoList
+
+{- The main configuration screen. -}
+getConfigurationR :: Handler Html
+getConfigurationR = ifM inFirstRun
+	( redirect FirstRepositoryR
+	, page "Configuration" (Just Configuration) $ do
+		$(widgetFile "configurators/main")
+	)
+
+getAddRepositoryR :: Handler Html
+getAddRepositoryR = page "Add Repository" (Just Configuration) $ do
+	let repolist = repoListDisplay mainRepoSelector
+	$(widgetFile "configurators/addrepository")
+
+makeMiscRepositories :: Widget
+makeMiscRepositories = $(widgetFile "configurators/addrepository/misc")
+
+makeCloudRepositories :: Widget
+makeCloudRepositories = $(widgetFile "configurators/addrepository/cloud")
+
+makeWormholePairing :: Widget
+makeWormholePairing = $(widgetFile "configurators/addrepository/wormholepairing")
+
+makeSshRepository :: Widget
+makeSshRepository = $(widgetFile "configurators/addrepository/ssh")
+
+makeConnectionRepositories :: Widget
+makeConnectionRepositories = $(widgetFile "configurators/addrepository/connection")
+
+makeArchiveRepositories :: Widget
+makeArchiveRepositories = $(widgetFile "configurators/addrepository/archive")
diff --git a/Assistant/WebApp/Configurators/AWS.hs b/Assistant/WebApp/Configurators/AWS.hs
new file mode 100644
index 0000000000..fb9f92b0dd
--- /dev/null
+++ b/Assistant/WebApp/Configurators/AWS.hs
@@ -0,0 +1,213 @@
+{- git-annex assistant webapp configurators for Amazon AWS services
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Configurators.AWS where
+
+import Assistant.WebApp.Common
+import Assistant.WebApp.MakeRemote
+import qualified Remote.S3 as S3
+import Logs.Remote
+import qualified Remote
+import qualified Types.Remote as Remote
+import qualified Remote.Glacier as Glacier
+import qualified Remote.Helper.AWS as AWS
+import Types.Remote (RemoteConfig)
+import Types.StandardGroups
+import Creds
+import Assistant.Gpg
+import Git.Types (RemoteName)
+import Annex.SpecialRemote.Config
+import Types.ProposedAccepted
+
+import qualified Data.Text as T
+import qualified Data.Map as M
+import Data.Char
+
+awsConfigurator :: Widget -> Handler Html
+awsConfigurator = page "Add an Amazon repository" (Just Configuration)
+
+glacierConfigurator :: Widget -> Handler Html
+glacierConfigurator a = do
+	ifM (liftIO $ inSearchPath "glacier")
+		( awsConfigurator a
+		, awsConfigurator needglaciercli
+		)
+  where
+	needglaciercli = $(widgetFile "configurators/needglaciercli")
+
+data StorageClass
+	= StandardRedundancy
+	| StandardInfrequentAccess
+	deriving (Eq, Enum, Bounded)
+
+instance Show StorageClass where
+	show StandardRedundancy = "STANDARD" 
+	show StandardInfrequentAccess = "STANDARD_IA"
+
+data AWSInput = AWSInput
+	{ accessKeyID :: Text
+	, secretAccessKey :: Text
+	, datacenter :: Text
+	-- Only used for S3, not Glacier.
+	, storageClass :: StorageClass
+	, repoName :: Text
+	, enableEncryption :: EnableEncryption
+	}
+
+data AWSCreds = AWSCreds Text Text
+
+extractCreds :: AWSInput -> AWSCreds
+extractCreds i = AWSCreds (accessKeyID i) (secretAccessKey i)
+
+s3InputAForm :: Maybe CredPair -> MkAForm AWSInput
+s3InputAForm defcreds = AWSInput
+	<$> accessKeyIDFieldWithHelp (T.pack . fst <$> defcreds)
+	<*> secretAccessKeyField (T.pack . snd <$> defcreds)
+	<*> datacenterField AWS.S3
+	<*> areq (selectFieldList storageclasses) (bfs "Storage class") (Just StandardRedundancy)
+	<*> areq textField (bfs "Repository name") (Just "S3")
+	<*> enableEncryptionField
+  where
+	storageclasses :: [(Text, StorageClass)]
+	storageclasses =
+		[ ("Standard redundancy", StandardRedundancy)
+		, ("Infrequent access (cheaper for backups and archives)", StandardInfrequentAccess)
+		]
+
+glacierInputAForm :: Maybe CredPair -> MkAForm AWSInput
+glacierInputAForm defcreds = AWSInput
+	<$> accessKeyIDFieldWithHelp (T.pack . fst <$> defcreds)
+	<*> secretAccessKeyField (T.pack . snd <$> defcreds)
+	<*> datacenterField AWS.Glacier
+	<*> pure StandardRedundancy
+	<*> areq textField (bfs "Repository name") (Just "glacier")
+	<*> enableEncryptionField
+
+awsCredsAForm :: Maybe CredPair -> MkAForm AWSCreds
+awsCredsAForm defcreds = AWSCreds
+	<$> accessKeyIDFieldWithHelp (T.pack . fst <$> defcreds)
+	<*> secretAccessKeyField (T.pack . snd <$> defcreds)
+
+accessKeyIDField :: Widget -> Maybe Text -> MkAForm Text
+accessKeyIDField help = areq (textField `withNote` help) (bfs "Access Key ID")
+
+accessKeyIDFieldWithHelp :: Maybe Text -> MkAForm Text
+accessKeyIDFieldWithHelp = accessKeyIDField help
+  where
+	help = [whamlet|
+<a href="https://portal.aws.amazon.com/gp/aws/securityCredentials#id_block">
+  Get Amazon access keys
+|]
+
+secretAccessKeyField :: Maybe Text -> MkAForm Text
+secretAccessKeyField = areq passwordField (bfs "Secret Access Key")
+
+datacenterField :: AWS.Service -> MkAForm Text
+datacenterField service = areq (selectFieldList list) (bfs "Datacenter") defregion
+  where
+	list = M.toList $ AWS.regionMap service
+	defregion = Just $ AWS.defaultRegion service
+
+getAddS3R :: Handler Html
+getAddS3R = postAddS3R
+
+postAddS3R :: Handler Html
+postAddS3R = awsConfigurator $ do
+	defcreds <- liftAnnex previouslyUsedAWSCreds
+	((result, form), enctype) <- liftH $
+		runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $ s3InputAForm defcreds
+	case result of
+		FormSuccess input -> liftH $ do
+			let name = T.unpack $ repoName input
+			makeAWSRemote initSpecialRemote S3.remote TransferGroup (extractCreds input) name $ M.fromList
+				[ configureEncryption $ enableEncryption input
+				, (typeField, Proposed "S3")
+				, (Proposed "datacenter", Proposed $ T.unpack $ datacenter input)
+				, (Proposed "storageclass", Proposed $ show $ storageClass input)
+				, (Proposed "chunk", Proposed "1MiB")
+				]
+		_ -> $(widgetFile "configurators/adds3")
+
+getAddGlacierR :: Handler Html
+getAddGlacierR = postAddGlacierR
+
+postAddGlacierR :: Handler Html
+postAddGlacierR = glacierConfigurator $ do
+	defcreds <- liftAnnex previouslyUsedAWSCreds
+	((result, form), enctype) <- liftH $
+		runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $ glacierInputAForm defcreds
+	case result of
+		FormSuccess input -> liftH $ do
+			let name = T.unpack $ repoName input
+			makeAWSRemote initSpecialRemote Glacier.remote SmallArchiveGroup (extractCreds input) name $ M.fromList
+				[ configureEncryption $ enableEncryption input
+				, (typeField, Proposed "glacier")
+				, (Proposed "datacenter", Proposed $ T.unpack $ datacenter input)
+				]
+		_ -> $(widgetFile "configurators/addglacier")
+
+getEnableS3R :: UUID -> Handler Html
+getEnableS3R uuid = do
+	m <- liftAnnex remoteConfigMap
+	isia <- case M.lookup uuid m of
+		Just c -> liftAnnex $ do
+			pc <- parsedRemoteConfig S3.remote c
+			return $ S3.configIA pc
+		Nothing -> return False
+	if isia
+		then redirect $ EnableIAR uuid
+		else postEnableS3R uuid
+
+postEnableS3R :: UUID -> Handler Html
+postEnableS3R uuid = awsConfigurator $ enableAWSRemote S3.remote uuid
+
+getEnableGlacierR :: UUID -> Handler Html
+getEnableGlacierR = postEnableGlacierR
+
+postEnableGlacierR :: UUID -> Handler Html
+postEnableGlacierR = glacierConfigurator . enableAWSRemote Glacier.remote
+
+enableAWSRemote :: RemoteType -> UUID -> Widget
+enableAWSRemote remotetype uuid = do
+	defcreds <- liftAnnex previouslyUsedAWSCreds
+	((result, form), enctype) <- liftH $
+		runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $ awsCredsAForm defcreds
+	case result of
+		FormSuccess creds -> liftH $ do
+			m <- liftAnnex remoteConfigMap
+			let name = fromJust $ lookupName $
+				fromJust $ M.lookup uuid m
+			makeAWSRemote enableSpecialRemote remotetype SmallArchiveGroup creds name M.empty
+		_ -> do
+			description <- liftAnnex $
+				T.pack <$> Remote.prettyUUID uuid
+			$(widgetFile "configurators/enableaws")
+
+makeAWSRemote :: SpecialRemoteMaker -> RemoteType -> StandardGroup -> AWSCreds -> RemoteName -> RemoteConfig -> Handler ()
+makeAWSRemote maker remotetype defaultgroup (AWSCreds ak sk) name config = 
+	setupCloudRemote defaultgroup Nothing $
+		maker hostname remotetype (Just creds) config
+  where
+	creds = (T.unpack ak, T.unpack sk)
+	{- AWS services use the remote name as the basis for a host
+	 - name, so filter it to contain valid characters. -}
+	hostname = case filter isAlphaNum name of
+		[] -> "aws"
+		n -> n
+
+getRepoInfo :: RemoteConfig -> Widget
+getRepoInfo c = [whamlet|S3 remote using bucket: #{bucket}|]
+  where
+	bucket = maybe "" fromProposedAccepted $ M.lookup (Accepted "bucket") c
+
+previouslyUsedAWSCreds :: Annex (Maybe CredPair)
+previouslyUsedAWSCreds = getM gettype [S3.remote, Glacier.remote]
+  where
+	gettype t = previouslyUsedCredPair AWS.creds t $
+		not . S3.configIA . Remote.config
diff --git a/Assistant/WebApp/Configurators/Delete.hs b/Assistant/WebApp/Configurators/Delete.hs
new file mode 100644
index 0000000000..333e13656a
--- /dev/null
+++ b/Assistant/WebApp/Configurators/Delete.hs
@@ -0,0 +1,121 @@
+{- git-annex assistant webapp repository deletion
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Configurators.Delete where
+
+import Assistant.WebApp.Common
+import Assistant.DeleteRemote
+import Assistant.DaemonStatus
+import Assistant.ScanRemotes
+import Assistant.Sync
+import qualified Remote
+import qualified Git
+import Config.Files.AutoStart
+import Logs.Trust
+import Logs.Remote
+import Logs.PreferredContent
+import Types.StandardGroups
+import Annex.UUID
+import Command.Uninit (prepareRemoveAnnexDir)
+
+import qualified Data.Text as T
+import qualified Data.Map as M
+
+notCurrentRepo :: UUID -> Handler Html -> Handler Html
+notCurrentRepo uuid a = do
+	u <- liftAnnex getUUID
+	if u == uuid
+		then redirect DeleteCurrentRepositoryR
+		else go =<< liftAnnex (Remote.remoteFromUUID uuid)
+  where
+	go Nothing = giveup "Unknown UUID"
+	go (Just _) = a
+
+getDeleteRepositoryR :: UUID -> Handler Html
+getDeleteRepositoryR uuid = notCurrentRepo uuid $ do
+	deletionPage $ do
+		reponame <- liftAnnex $ Remote.prettyUUID uuid
+		$(widgetFile "configurators/delete/start")
+
+getStartDeleteRepositoryR :: UUID -> Handler Html
+getStartDeleteRepositoryR uuid = do
+	remote <- fromMaybe (giveup "unknown remote")
+		<$> liftAnnex (Remote.remoteFromUUID uuid)
+	liftAnnex $ do
+		trustSet uuid UnTrusted
+		setStandardGroup uuid UnwantedGroup
+	liftAssistant $ addScanRemotes True [remote]
+	redirect DashboardR
+
+getFinishDeleteRepositoryR :: UUID -> Handler Html
+getFinishDeleteRepositoryR uuid = deletionPage $ do
+	void $ liftAssistant $ removeRemote uuid
+
+	reponame <- liftAnnex $ Remote.prettyUUID uuid
+	{- If it's not listed in the remote log, it must be a git repo. -}
+	gitrepo <- liftAnnex $ M.notMember uuid <$> remoteConfigMap
+	$(widgetFile "configurators/delete/finished")	
+
+getDeleteCurrentRepositoryR :: Handler Html
+getDeleteCurrentRepositoryR = deleteCurrentRepository
+
+postDeleteCurrentRepositoryR :: Handler Html
+postDeleteCurrentRepositoryR = deleteCurrentRepository
+
+deleteCurrentRepository :: Handler Html
+deleteCurrentRepository = dangerPage $ do
+	reldir <- fromJust . relDir <$> liftH getYesod
+	havegitremotes <- haveremotes syncGitRemotes
+	havedataremotes <- haveremotes downloadRemotes
+	((result, form), enctype) <- liftH $
+		runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $
+			sanityVerifierAForm $ SanityVerifier magicphrase
+	case result of
+		FormSuccess _ -> liftH $ do
+			dir <- liftAnnex $ fromRawFilePath <$> fromRepo Git.repoPath
+			liftIO $ removeAutoStartFile dir
+
+			{- Disable syncing to this repository, and all
+			 - remotes. This stops all transfers, and all
+			 - file watching. -}
+			liftAssistant $ do
+				changeSyncable Nothing False
+				rs <- syncRemotes <$> getDaemonStatus
+				mapM_ (\r -> changeSyncable (Just r) False) rs
+
+			liftAnnex $ prepareRemoveAnnexDir dir
+			liftIO $ removeDirectoryRecursive . fromRawFilePath
+				=<< absPath (toRawFilePath dir)
+			
+			redirect ShutdownConfirmedR
+		_ -> $(widgetFile "configurators/delete/currentrepository")
+  where
+	haveremotes selector = not . null . selector
+		<$> liftAssistant getDaemonStatus
+
+data SanityVerifier = SanityVerifier T.Text
+	deriving (Eq)
+
+sanityVerifierAForm :: SanityVerifier -> MkAForm SanityVerifier
+sanityVerifierAForm template = SanityVerifier
+	<$> areq checksanity (bfs "Confirm deletion?") Nothing
+  where
+	checksanity = checkBool (\input -> SanityVerifier input == template)
+		insane textField
+	
+	insane = "Maybe this is not a good idea..." :: Text
+
+deletionPage :: Widget -> Handler Html
+deletionPage = page "Delete repository" (Just Configuration)
+
+dangerPage :: Widget -> Handler Html
+dangerPage = page "Danger danger danger" (Just Configuration)
+
+magicphrase :: Text
+magicphrase = "Yes, please do as I say!"
diff --git a/Assistant/WebApp/Configurators/Edit.hs b/Assistant/WebApp/Configurators/Edit.hs
new file mode 100644
index 0000000000..65da2d588e
--- /dev/null
+++ b/Assistant/WebApp/Configurators/Edit.hs
@@ -0,0 +1,329 @@
+{- git-annex assistant webapp configurator for editing existing repos
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+{-# LANGUAGE FlexibleContexts #-}
+
+module Assistant.WebApp.Configurators.Edit where
+
+import Assistant.WebApp.Common
+import Assistant.WebApp.Gpg
+import Assistant.WebApp.Configurators
+import Assistant.DaemonStatus
+import Assistant.WebApp.MakeRemote (uniqueRemoteName)
+import Assistant.ScanRemotes
+import Assistant.Sync
+import Assistant.Alert
+import qualified Assistant.WebApp.Configurators.AWS as AWS
+import qualified Assistant.WebApp.Configurators.IA as IA
+import qualified Remote.S3 as S3
+import qualified Remote
+import qualified Types.Remote as Remote
+import Remote.List.Util
+import Logs.UUID
+import Logs.Group
+import Logs.PreferredContent
+import Logs.Remote
+import Types.StandardGroups
+import qualified Git
+import qualified Git.Types as Git
+import qualified Git.Command
+import qualified Git.Config
+import qualified Annex
+import Git.Remote
+import Remote.Helper.Encryptable (extractCipher, parseEncryptionConfig)
+import Types.Crypto
+import Utility.Gpg
+import Annex.UUID
+import Annex.Perms
+import Assistant.Ssh
+import Config
+import Config.GitConfig
+import Config.DynamicConfig
+import Types.Group
+import Types.ProposedAccepted
+import Annex.SpecialRemote.Config
+
+import qualified Data.Text as T
+import qualified Data.Map as M
+import qualified Data.Set as S
+
+data RepoGroup = RepoGroupCustom String | RepoGroupStandard StandardGroup
+	deriving (Show, Eq)
+
+data RepoConfig = RepoConfig
+	{ repoName :: Text
+	, repoDescription :: Maybe Text
+	, repoGroup :: RepoGroup
+	, repoAssociatedDirectory :: Maybe Text
+	, repoSyncable :: Bool
+	}
+	deriving (Show)
+
+getRepoConfig :: UUID -> Maybe Remote -> Annex RepoConfig
+getRepoConfig uuid mremote = do
+	-- Ensure we're editing current data by discarding caches.
+	void groupMapLoad
+	void uuidDescMapLoad
+
+	groups <- lookupGroups uuid
+	remoteconfig <- M.lookup uuid <$> remoteConfigMap
+	let (repogroup, associateddirectory) = case getStandardGroup groups of
+		Nothing -> (RepoGroupCustom $ unwords $ map fromGroup $ S.toList groups, Nothing)
+		Just g -> (RepoGroupStandard g, associatedDirectory remoteconfig g)
+	
+	description <- fmap (T.pack . fromUUIDDesc) . M.lookup uuid <$> uuidDescMap
+
+	syncable <- case mremote of
+		Just r -> liftIO $ getDynamicConfig $ remoteAnnexSync $ Remote.gitconfig r
+		Nothing -> getGitConfigVal annexAutoCommit
+
+	return $ RepoConfig
+		(T.pack $ maybe "here" Remote.name mremote)
+		description
+		repogroup
+		(T.pack <$> associateddirectory)
+		syncable
+		
+setRepoConfig :: UUID -> Maybe Remote -> RepoConfig -> RepoConfig -> Handler ()
+setRepoConfig uuid mremote oldc newc = do
+	when descriptionChanged $ liftAnnex $ do
+		maybe noop (describeUUID uuid . toUUIDDesc . T.unpack) (repoDescription newc)
+		void uuidDescMapLoad
+	when nameChanged $ do
+		liftAnnex $ do
+			name <- uniqueRemoteName (legalName newc) 0 <$> Annex.getGitRemotes
+			{- git remote rename expects there to be a
+			 - remote.<name>.fetch, and exits nonzero if
+			 - there's not. Special remotes don't normally
+			 - have that, and don't use it. Temporarily add
+			 - it if it's missing. -}
+			let remotefetch = Git.ConfigKey $ encodeBS $
+				"remote." ++ T.unpack (repoName oldc) ++ ".fetch"
+			needfetch <- isNothing <$> fromRepo (Git.Config.getMaybe remotefetch)
+			when needfetch $
+				inRepo $ Git.Command.run
+					[Param "config", Param (Git.fromConfigKey remotefetch), Param ""]
+			inRepo $ Git.Command.run
+				[ Param "remote"
+				, Param "rename"
+				, Param $ T.unpack $ repoName oldc
+				, Param name
+				]
+			remotesChanged
+		liftAssistant updateSyncRemotes
+	when associatedDirectoryChanged $ case repoAssociatedDirectory newc of
+		Nothing -> noop
+		Just t
+			| T.null t -> noop
+			| otherwise -> liftAnnex $ do
+				let dir = takeBaseName $ T.unpack t
+				m <- remoteConfigMap
+				case M.lookup uuid m of
+					Nothing -> noop
+					Just remoteconfig -> configSet uuid $
+						M.insert (Proposed "preferreddir") (Proposed dir) remoteconfig
+	when groupChanged $ do
+		liftAnnex $ case repoGroup newc of
+			RepoGroupStandard g -> setStandardGroup uuid g
+			RepoGroupCustom s -> groupSet uuid $ S.fromList $ map toGroup $ words s
+		{- Enabling syncing will cause a scan,
+		 - so avoid queueing a duplicate scan. -}
+		when (repoSyncable newc && not syncableChanged) $ liftAssistant $
+			case mremote of
+				Just remote -> addScanRemotes True [remote]
+				Nothing -> addScanRemotes True
+					=<< syncDataRemotes <$> getDaemonStatus
+	when syncableChanged $
+		liftAssistant $ changeSyncable mremote (repoSyncable newc)
+  where
+	syncableChanged = repoSyncable oldc /= repoSyncable newc
+	associatedDirectoryChanged = repoAssociatedDirectory oldc /= repoAssociatedDirectory newc
+	groupChanged = repoGroup oldc /= repoGroup newc
+	nameChanged = isJust mremote && legalName oldc /= legalName newc
+	descriptionChanged = repoDescription oldc /= repoDescription newc
+
+	legalName = makeLegalName . T.unpack . repoName
+
+editRepositoryAForm :: Maybe Git.Repo -> Maybe Remote -> RepoConfig -> MkAForm RepoConfig
+editRepositoryAForm mrepo mremote d = RepoConfig
+	<$> areq (if ishere then readonlyTextField else textField)
+		(bfs "Name") (Just $ repoName d)
+	<*> aopt textField (bfs "Description") (Just $ repoDescription d)
+	<*> areq (selectFieldList groups `withNote` help) (bfs "Repository group") (Just $ repoGroup d)
+	<*> associateddirectory
+	<*> areq checkBoxField "Syncing enabled" (Just $ repoSyncable d)
+  where
+	ishere = isNothing mremote
+	isspecial = maybe False ((== Git.Unknown) . Git.location) mrepo
+	groups = customgroups ++ standardgroups
+	standardgroups :: [(Text, RepoGroup)]
+	standardgroups = map (\g -> (T.pack $ descStandardGroup g , RepoGroupStandard g)) $
+		filter sanegroup [minBound..maxBound]
+	sanegroup
+		| isspecial = const True
+		| otherwise = not . specialRemoteOnly
+	customgroups :: [(Text, RepoGroup)]
+	customgroups = case repoGroup d of
+		RepoGroupCustom s -> [(T.pack s, RepoGroupCustom s)]
+		_ -> []
+	help = [whamlet|<a href="@{RepoGroupR}">What's this?</a>|]
+
+	associateddirectory = case repoAssociatedDirectory d of
+		Nothing -> aopt hiddenField "" Nothing
+		Just dir -> aopt textField (bfs "Associated directory") (Just $ Just dir)
+
+getEditRepositoryR :: RepoId -> Handler Html
+getEditRepositoryR = postEditRepositoryR
+
+postEditRepositoryR :: RepoId -> Handler Html
+postEditRepositoryR = editForm False
+
+getEditNewRepositoryR :: UUID -> Handler Html
+getEditNewRepositoryR = postEditNewRepositoryR
+
+postEditNewRepositoryR :: UUID -> Handler Html
+postEditNewRepositoryR = editForm True . RepoUUID
+
+getEditNewCloudRepositoryR :: UUID -> Handler Html
+getEditNewCloudRepositoryR = postEditNewCloudRepositoryR
+
+postEditNewCloudRepositoryR :: UUID -> Handler Html
+postEditNewCloudRepositoryR uuid = connectionNeeded >> editForm True (RepoUUID uuid)
+
+editForm :: Bool -> RepoId -> Handler Html
+editForm new (RepoUUID uuid)
+	| uuid == webUUID || uuid == bitTorrentUUID = page "The web" (Just Configuration) $ do
+		$(widgetFile "configurators/edit/webrepository")
+	| otherwise = page "Edit repository" (Just Configuration) $ do
+		mremote <- liftAnnex $ Remote.remoteFromUUID uuid
+		when (mremote == Nothing) $
+			whenM ((/=) uuid <$> liftAnnex getUUID) $
+				giveup "unknown remote"
+		curr <- liftAnnex $ getRepoConfig uuid mremote
+		liftAnnex $ checkAssociatedDirectory curr mremote
+		mrepo <- liftAnnex $
+			maybe (pure Nothing) (Just <$$> Remote.getRepo) mremote
+		((result, form), enctype) <- liftH $
+			runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $
+				editRepositoryAForm mrepo mremote curr
+		case result of
+			FormSuccess input -> liftH $ do
+				setRepoConfig uuid mremote curr input
+				liftAnnex $ checkAssociatedDirectory input mremote
+				redirect DashboardR
+			_ -> do
+				let istransfer = repoGroup curr == RepoGroupStandard TransferGroup
+				config <- liftAnnex $ fromMaybe mempty 
+					. M.lookup uuid
+					<$> remoteConfigMap
+				let repoInfo = getRepoInfo mremote config
+				let repoEncryption = getRepoEncryption mremote (Just config)
+				$(widgetFile "configurators/edit/repository")
+editForm _new r@(RepoName _) = page "Edit repository" (Just Configuration) $ do
+	mr <- liftAnnex (repoIdRemote r)
+	let repoInfo = case mr of
+		Just rmt -> do
+			config <- liftAnnex $ fromMaybe mempty
+				. M.lookup (Remote.uuid rmt)
+				<$> remoteConfigMap
+			getRepoInfo mr config
+		Nothing -> getRepoInfo Nothing mempty
+	g <- liftAnnex gitRepo
+	mrepo <- liftAnnex $ maybe (pure Nothing) (Just <$$> Remote.getRepo) mr
+	let sshrepo = maybe False (\repo -> remoteLocationIsSshUrl (parseRemoteLocation (Git.repoLocation repo) False g)) mrepo
+	$(widgetFile "configurators/edit/nonannexremote")
+
+{- Makes any directory associated with the repository. -}
+checkAssociatedDirectory :: RepoConfig -> Maybe Remote -> Annex ()
+checkAssociatedDirectory _ Nothing = noop
+checkAssociatedDirectory cfg (Just r) = do
+	repoconfig <- M.lookup (Remote.uuid r) <$> remoteConfigMap
+	case repoGroup cfg of
+		RepoGroupStandard gr -> case associatedDirectory repoconfig gr of
+			Just d -> do
+				top <- fromRawFilePath <$> fromRepo Git.repoPath
+				createWorkTreeDirectory (toRawFilePath (top </> d))
+			Nothing -> noop
+		_ -> noop
+
+getRepoInfo :: Maybe Remote.Remote -> Remote.RemoteConfig -> Widget
+getRepoInfo (Just r) c = case fromProposedAccepted <$> M.lookup typeField c of
+	Just "S3" -> do
+		pc <- liftAnnex $ parsedRemoteConfig S3.remote c
+		if S3.configIA pc
+			then IA.getRepoInfo c
+			else AWS.getRepoInfo c
+	Just t
+		| t /= "git" -> [whamlet|#{t} remote|]
+	_ -> getGitRepoInfo =<< liftAnnex (Remote.getRepo r)
+getRepoInfo _ _ = [whamlet|git repository|]
+
+getGitRepoInfo :: Git.Repo -> Widget
+getGitRepoInfo r = do
+	let loc = Git.repoLocation r
+	[whamlet|git repository located at <tt>#{loc}</tt>|]
+
+getRepoEncryption :: Maybe Remote.Remote -> Maybe Remote.RemoteConfig -> Widget
+getRepoEncryption (Just _) (Just c) = case extractCipher pc of
+	Nothing ->
+		[whamlet|not encrypted|]
+	(Just (SharedCipher _)) ->
+		[whamlet|encrypted: encryption key stored in git repository|]
+	(Just (EncryptedCipher _ _ ks)) -> desckeys ks
+	(Just (SharedPubKeyCipher _ ks)) -> desckeys ks
+  where
+	pc = either (const (Remote.ParsedRemoteConfig mempty mempty)) id $
+		parseEncryptionConfig c
+	desckeys (KeyIds { keyIds = ks }) = do
+		cmd <- liftAnnex $ gpgCmd <$> Annex.getGitConfig
+		knownkeys <- liftIO (secretKeys cmd)
+		[whamlet|
+encrypted using gpg key:
+<ul style="list-style: none">
+  $forall k <- ks
+    <li>
+      ^{gpgKeyDisplay k (M.lookup k knownkeys)}
+|]
+getRepoEncryption _ _ = return () -- local repo
+
+getUpgradeRepositoryR  :: RepoId -> Handler ()
+getUpgradeRepositoryR (RepoUUID _) = redirect DashboardR
+getUpgradeRepositoryR r = go =<< liftAnnex (repoIdRemote r)
+  where
+	go Nothing = redirect DashboardR
+	go (Just rmt) = do
+		liftIO fixSshKeyPairIdentitiesOnly
+		liftAnnex $ do
+			repo <- Remote.getRepo rmt
+			setConfig
+				(remoteAnnexConfig repo "ignore")
+				(Git.Config.boolConfig False)
+		liftAnnex remotesChanged
+		liftAssistant updateSyncRemotes
+		liftAssistant $ syncRemote rmt
+		redirect DashboardR
+
+{- If there is no currently connected remote, display an alert suggesting
+ - to set up one. -}
+connectionNeeded :: Handler ()
+connectionNeeded = whenM noconnection $ do
+	urlrender <- getUrlRender
+	void $ liftAssistant $ do
+		close <- asIO1 removeAlert
+		addAlert $ connectionNeededAlert $ AlertButton
+			{ buttonLabel = "Connect"
+			, buttonUrl = urlrender ConnectionNeededR
+			, buttonAction = Just close
+			, buttonPrimary = True
+			}
+  where
+	noconnection = S.null . currentlyConnectedRemotes <$> liftAssistant getDaemonStatus
+
+getConnectionNeededR :: Handler Html
+getConnectionNeededR = page "Connection needed" (Just Configuration) $ do
+	$(widgetFile "configurators/needconnection")
diff --git a/Assistant/WebApp/Configurators/Fsck.hs b/Assistant/WebApp/Configurators/Fsck.hs
new file mode 100644
index 0000000000..e220d34b44
--- /dev/null
+++ b/Assistant/WebApp/Configurators/Fsck.hs
@@ -0,0 +1,196 @@
+{- git-annex assistant fsck configuration
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Configurators.Fsck where
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import qualified Data.Text as T
+
+import Assistant.WebApp.Common
+import Types.ScheduledActivity
+import Utility.HumanTime
+import Utility.Scheduled
+import Logs.Schedule
+import Annex.UUID
+import qualified Remote
+import Assistant.DaemonStatus
+import qualified Annex.Branch
+import Assistant.Fsck
+import Config
+import Git.Config
+import qualified Annex
+
+{- This adds a form to the page. It does not handle posting of the form,
+ - because unlike a typical yesod form that posts using the same url
+ - that generated it, this form posts using one of two other routes. -}
+showFsckForm :: Bool -> ScheduledActivity -> Widget
+showFsckForm new activity = do
+	u <- liftAnnex getUUID
+	let action = if new
+		then AddActivityR u
+		else ChangeActivityR u activity
+	((res, form), enctype) <- liftH $ runFsckForm new activity
+	case res of
+		FormSuccess _ -> noop
+		_ -> $(widgetFile "configurators/fsck/form")
+
+{- This does not display a form, but it does get it from a post, and run
+ - some Annex action on it. -}
+withFsckForm :: (ScheduledActivity -> Annex ()) -> Handler ()
+withFsckForm a = do
+	((res, _form), _enctype) <- runFsckForm False $ defaultFsck Nothing
+	case res of
+		FormSuccess activity -> liftAnnex $ a activity
+		_ -> noop
+
+mkFsck :: UUID -> UUID -> Schedule -> Duration -> ScheduledActivity
+mkFsck hereu u s d
+	| u == hereu = ScheduledSelfFsck s d 
+	| otherwise = ScheduledRemoteFsck u s d
+
+runFsckForm :: Bool -> ScheduledActivity -> Handler ((FormResult ScheduledActivity, Widget), Enctype)
+runFsckForm new activity = case activity of
+	ScheduledSelfFsck s d -> go s d =<< liftAnnex getUUID
+	ScheduledRemoteFsck ru s d -> go s d ru
+  where
+	go (Schedule r t) d ru = do
+		u <- liftAnnex getUUID
+		repolist <- liftAssistant (getrepolist ru)
+		runFormPostNoToken $ \msg -> do
+			(reposRes, reposView) <- mreq (selectFieldList repolist) (bfs "") (Just ru)
+			(durationRes, durationView) <- mreq intField (bfs "") (Just $ durationSeconds d `quot` 60 )
+			(timeRes, timeView) <- mreq (selectFieldList times) (bfs "") (Just t)
+			(recurrenceRes, recurrenceView) <- mreq (selectFieldList recurrences) (bfs "") (Just r)
+			let form = do
+				webAppFormAuthToken
+				$(widgetFile "configurators/fsck/formcontent")
+			let formresult = mkFsck
+				<$> pure u
+				<*> reposRes
+				<*> (Schedule <$> recurrenceRes <*> timeRes)
+				<*> (Duration <$> ((60 *) <$> durationRes))
+			return (formresult, form)
+	  where
+		times :: [(Text, ScheduledTime)]
+		times = ensurevalue t (T.pack $ fromScheduledTime t) $
+			map (\x -> (T.pack $ fromScheduledTime x, x)) $
+				AnyTime : map (\h -> SpecificTime h 0) [0..23]
+		recurrences :: [(Text, Recurrence)]
+		recurrences = ensurevalue r (T.pack $ fromRecurrence r) $
+			[ ("every day", Daily)
+			, ("every Sunday", Weekly $ Just 1)
+			, ("every Monday", Weekly $ Just 2)
+			, ("every Tuesday", Weekly $ Just 3)
+			, ("every Wednesday", Weekly $ Just 4)
+			, ("every Thursday", Weekly $ Just 5)
+			, ("every Friday", Weekly $ Just 6)
+			, ("every Saturday", Weekly $ Just 7)
+			, ("monthly", Monthly Nothing)
+			, ("twice a month", Divisible 2 (Weekly Nothing))
+			, ("yearly", Yearly Nothing)
+			, ("twice a year", Divisible 6 (Monthly Nothing))
+			, ("quarterly", Divisible 4 (Monthly Nothing))
+			]
+	ensurevalue v desc l = case M.lookup v (M.fromList $ map (\(x,y) -> (y,x)) l) of
+		Just _ -> l
+		Nothing -> (desc, v) : l
+	getrepolist :: UUID -> Assistant [(Text, UUID)]
+	getrepolist ensureu = do
+		-- It is possible to have fsck jobs for remotes that
+		-- do not implement remoteFsck, but it's not too useful,
+		-- so omit them from the UI normally.
+		remotes <- filter (\r -> Remote.uuid r == ensureu || isJust (Remote.remoteFsck r)) . syncRemotes
+			<$> getDaemonStatus
+		u <- liftAnnex getUUID
+		let us = u : (map Remote.uuid remotes)
+		liftAnnex $ 
+			zip <$> (map T.pack <$> Remote.prettyListUUIDs us) <*> pure us
+
+defaultFsck :: Maybe Remote -> ScheduledActivity
+defaultFsck Nothing = ScheduledSelfFsck (Schedule Daily AnyTime) (Duration $ 60*60)
+defaultFsck (Just r) = ScheduledRemoteFsck (Remote.uuid r) (Schedule Daily AnyTime) (Duration $ 60*60)
+
+showFsckStatus :: ScheduledActivity -> Widget
+showFsckStatus activity = do
+	m <- liftAnnex getLastRunTimes
+	let lastrun = M.lookup activity m
+	$(widgetFile "configurators/fsck/status")
+
+getConfigFsckR :: Handler Html
+getConfigFsckR = postConfigFsckR
+postConfigFsckR :: Handler Html
+postConfigFsckR = page "Consistency checks" (Just Configuration) $ do
+	scheduledchecks <- liftAnnex $
+		S.toList <$> (scheduleGet =<< getUUID)
+	rs <- liftAssistant $
+		filter fsckableRemote . syncRemotes <$> getDaemonStatus
+	recommendedchecks <- liftAnnex $ map defaultFsck
+		<$> filterM (not <$$> checkFscked) (Nothing : map Just rs)
+	$(widgetFile "configurators/fsck")
+
+changeSchedule :: Handler () -> Handler Html
+changeSchedule a = do
+	a
+	liftAnnex $ Annex.Branch.commit =<< Annex.Branch.commitMessage
+	redirect ConfigFsckR
+
+getRemoveActivityR :: UUID -> ScheduledActivity -> Handler Html
+getRemoveActivityR u activity = changeSchedule $
+	liftAnnex $ scheduleRemove u activity
+
+getAddActivityR :: UUID -> Handler Html
+getAddActivityR = postAddActivityR
+postAddActivityR :: UUID -> Handler Html
+postAddActivityR u = changeSchedule $
+	withFsckForm $ scheduleAdd u
+
+getChangeActivityR :: UUID -> ScheduledActivity -> Handler Html
+getChangeActivityR = postChangeActivityR
+postChangeActivityR :: UUID -> ScheduledActivity -> Handler Html
+postChangeActivityR u oldactivity = changeSchedule $
+	withFsckForm $ \newactivity -> scheduleChange u $
+			S.insert newactivity . S.delete oldactivity
+
+data FsckPreferences = FsckPreferences
+	{ enableFsckNudge :: Bool
+	}
+
+getFsckPreferences :: Annex FsckPreferences
+getFsckPreferences = FsckPreferences
+	<$> (annexFsckNudge <$> Annex.getGitConfig)
+
+fsckPreferencesAForm :: FsckPreferences -> MkAForm FsckPreferences
+fsckPreferencesAForm d = FsckPreferences
+	<$> areq (checkBoxField `withNote` nudgenote) "Reminders" (Just $ enableFsckNudge d)
+  where
+	nudgenote = [whamlet|Remind me when using repositories that lack consistency checks.|]
+
+runFsckPreferencesForm :: Handler ((FormResult FsckPreferences, Widget), Enctype)
+runFsckPreferencesForm = do
+	prefs <- liftAnnex getFsckPreferences
+	runFormPostNoToken $ renderBootstrap3 formLayout $ fsckPreferencesAForm prefs
+  where formLayout = BootstrapHorizontalForm (ColSm 0) (ColSm 2) (ColSm 0) (ColSm 10)
+
+showFsckPreferencesForm :: Widget
+showFsckPreferencesForm = do
+	((res, form), enctype) <- liftH $ runFsckPreferencesForm
+	case res of
+		FormSuccess _ -> noop
+		_ -> $(widgetFile "configurators/fsck/preferencesform")
+
+postConfigFsckPreferencesR :: Handler Html
+postConfigFsckPreferencesR = do
+	((res, _form), _enctype) <- runFsckPreferencesForm
+	case res of
+		FormSuccess prefs ->
+			liftAnnex $ setConfig (annexConfig "fscknudge")
+				(boolConfig $ enableFsckNudge prefs)
+		_ -> noop
+	redirect ConfigFsckR
diff --git a/Assistant/WebApp/Configurators/IA.hs b/Assistant/WebApp/Configurators/IA.hs
new file mode 100644
index 0000000000..1b2d05e6e2
--- /dev/null
+++ b/Assistant/WebApp/Configurators/IA.hs
@@ -0,0 +1,194 @@
+{- git-annex assistant webapp configurators for Internet Archive
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Configurators.IA where
+
+import Assistant.WebApp.Common
+import qualified Assistant.WebApp.Configurators.AWS as AWS
+import qualified Remote.S3 as S3
+import qualified Remote.Helper.AWS as AWS
+import Assistant.WebApp.MakeRemote
+import qualified Remote
+import qualified Types.Remote as Remote
+import Types.StandardGroups
+import Logs.Remote
+import Assistant.Gpg
+import Types.Remote (RemoteConfig)
+import qualified Annex.Url as Url
+import Creds
+import Annex.SpecialRemote.Config
+import Types.ProposedAccepted
+
+import qualified Data.Text as T
+import qualified Data.Map as M
+import Data.Char
+import Network.URI
+
+iaConfigurator :: Widget -> Handler Html
+iaConfigurator = page "Add an Internet Archive repository" (Just Configuration)
+
+data IAInput = IAInput
+	{ accessKeyID :: Text
+	, secretAccessKey :: Text
+	, mediaType :: MediaType
+	, itemName :: Text
+	}
+
+extractCreds :: IAInput -> AWS.AWSCreds
+extractCreds i = AWS.AWSCreds (accessKeyID i) (secretAccessKey i)
+
+{- IA defines only a few media types currently, or the media type
+ - may be omitted
+ -
+ - We add a few other common types, mapped to what we've been told
+ - is the closest match.
+ -}
+data MediaType = MediaImages | MediaAudio | MediaVideo | MediaText | MediaSoftware | MediaOmitted
+	deriving (Eq, Ord, Enum, Bounded)
+
+{- Format a MediaType for entry into the IA metadata -}
+formatMediaType :: MediaType -> String
+formatMediaType MediaText = "texts"
+formatMediaType MediaImages = "image"
+formatMediaType MediaSoftware = "software"
+formatMediaType MediaVideo = "movies"
+formatMediaType MediaAudio = "audio"
+formatMediaType MediaOmitted = ""
+
+{- A default collection to use for each Mediatype. -}
+collectionMediaType :: MediaType -> Maybe String
+collectionMediaType MediaText = Just "opensource"
+collectionMediaType MediaImages = Just "opensource" -- not ideal
+collectionMediaType MediaSoftware = Just "opensource" -- not ideal
+collectionMediaType MediaVideo = Just "opensource_movies"
+collectionMediaType MediaAudio = Just "opensource_audio"
+collectionMediaType MediaOmitted = Just "opensource"
+
+{- Format a MediaType for user display. -}
+showMediaType :: MediaType -> String
+showMediaType MediaText = "texts"
+showMediaType MediaImages = "photos & images"
+showMediaType MediaSoftware = "software"
+showMediaType MediaVideo = "videos & movies"
+showMediaType MediaAudio = "audio & music"
+showMediaType MediaOmitted = "other"
+
+iaInputAForm :: Maybe CredPair -> MkAForm IAInput
+iaInputAForm defcreds = IAInput
+	<$> accessKeyIDFieldWithHelp (T.pack . fst <$> defcreds)
+	<*> AWS.secretAccessKeyField (T.pack . snd <$> defcreds)
+	<*> areq (selectFieldList mediatypes) (bfs "Media Type") (Just MediaOmitted)
+	<*> areq (textField `withExpandableNote` ("Help", itemNameHelp)) (bfs "Item Name") Nothing
+  where
+	mediatypes :: [(Text, MediaType)]
+	mediatypes = map (\t -> (T.pack $ showMediaType t, t)) [minBound..]
+
+itemNameHelp :: Widget
+itemNameHelp = [whamlet|
+<div>
+  Each item stored in the Internet Archive must have a unique name.
+<div>
+  Once you create the item, a special directory will appear #
+  with a name matching the item name. Files you put in that directory #
+  will be uploaded to your Internet Archive item.
+|]
+
+iaCredsAForm :: Maybe CredPair -> MkAForm AWS.AWSCreds
+iaCredsAForm defcreds = AWS.AWSCreds
+	<$> accessKeyIDFieldWithHelp (T.pack . fst <$> defcreds)
+	<*> AWS.secretAccessKeyField (T.pack . snd <$> defcreds)
+
+previouslyUsedIACreds :: Annex (Maybe CredPair)
+previouslyUsedIACreds = previouslyUsedCredPair AWS.creds S3.remote $
+	S3.configIA . Remote.config
+
+accessKeyIDFieldWithHelp :: Maybe Text -> MkAForm Text
+accessKeyIDFieldWithHelp = AWS.accessKeyIDField help
+  where
+	help = [whamlet|
+<a href="http://archive.org/account/s3.php">
+  Get Internet Archive access keys
+|]
+
+getAddIAR :: Handler Html
+getAddIAR = postAddIAR
+
+postAddIAR :: Handler Html
+postAddIAR = iaConfigurator $ do
+	defcreds <- liftAnnex previouslyUsedIACreds
+	((result, form), enctype) <- liftH $
+		runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $ iaInputAForm defcreds
+	case result of
+		FormSuccess input -> liftH $ do
+			let name = escapeBucket $ T.unpack $ itemName input
+			let wrap (k, v) = (Proposed k, Proposed v)
+			let c = map wrap $ catMaybes
+				[ Just ("type", "S3")
+				, Just ("host", S3.iaHost)
+				, Just ("bucket", escapeHeader name)
+				, Just ("x-archive-meta-title", escapeHeader $ T.unpack $ itemName input)
+				, if mediaType input == MediaOmitted
+					then Nothing
+					else Just ("x-archive-mediatype", formatMediaType $ mediaType input)
+				, (,) <$> pure "x-archive-meta-collection" <*> collectionMediaType (mediaType input)
+				-- Make item show up ASAP.
+				, Just ("x-archive-interactive-priority", "1")
+				, Just ("preferreddir", name)
+				]
+			AWS.makeAWSRemote initSpecialRemote S3.remote PublicGroup (extractCreds input) name $
+				M.fromList $ configureEncryption NoEncryption : c
+		_ -> $(widgetFile "configurators/addia")
+
+getEnableIAR :: UUID -> Handler Html
+getEnableIAR = postEnableIAR
+
+postEnableIAR :: UUID -> Handler Html
+postEnableIAR = iaConfigurator . enableIARemote
+
+enableIARemote :: UUID -> Widget
+enableIARemote uuid = do
+	defcreds <- liftAnnex previouslyUsedIACreds
+	((result, form), enctype) <- liftH $
+		runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $ iaCredsAForm defcreds
+	case result of
+		FormSuccess creds -> liftH $ do
+			m <- liftAnnex remoteConfigMap
+			let name = fromJust $ lookupName $
+				fromJust $ M.lookup uuid m
+			AWS.makeAWSRemote enableSpecialRemote S3.remote PublicGroup creds name M.empty
+		_ -> do
+			description <- liftAnnex $
+				T.pack <$> Remote.prettyUUID uuid
+			$(widgetFile "configurators/enableia")
+
+{- Convert a description into a bucket item name, which will also be
+ - used as the repository name, and the preferreddir.
+ - IA seems to need only lower case, and no spaces. -}
+escapeBucket :: String -> String
+escapeBucket = map toLower . replace " " "-"
+
+{- IA S3 API likes headers to be URI escaped, escaping spaces looks ugly. -}
+escapeHeader :: String -> String
+escapeHeader = escapeURIString (\c -> isUnescapedInURI c && c /= ' ')
+
+getRepoInfo :: RemoteConfig -> Widget
+getRepoInfo c = do
+	uo <- liftAnnex Url.getUrlOptions
+	urlexists <- liftAnnex $ catchDefaultIO False $ Url.exists url uo
+	[whamlet|
+<a href="#{url}">
+  Internet Archive item
+$if (not urlexists)
+  <p>
+    The page will only be available once some files #
+    have been uploaded, and the Internet Archive has processed them.
+|]
+  where
+	bucket = maybe "" fromProposedAccepted $ M.lookup (Accepted "bucket") c
+	url = S3.iaItemUrl bucket
diff --git a/Assistant/WebApp/Configurators/Local.hs b/Assistant/WebApp/Configurators/Local.hs
new file mode 100644
index 0000000000..0b7c60a092
--- /dev/null
+++ b/Assistant/WebApp/Configurators/Local.hs
@@ -0,0 +1,433 @@
+{- git-annex assistant webapp configurators for making local repositories
+ -
+ - Copyright 2012-2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP, QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+{-# LANGUAGE RankNTypes, KindSignatures, TypeFamilies, TypeOperators #-}
+{-# LANGUAGE FlexibleContexts #-}
+
+module Assistant.WebApp.Configurators.Local where
+
+import Assistant.WebApp.Common
+import Assistant.WebApp.Gpg
+import Assistant.WebApp.MakeRemote
+import Assistant.Sync
+import Assistant.Restart
+import Assistant.MakeRepo
+import qualified Annex
+import qualified Git
+import qualified Git.Config
+import qualified Git.Command
+import Config.Files.AutoStart
+import Utility.FreeDesktop
+import Utility.DiskFree
+#ifndef mingw32_HOST_OS
+import Utility.Mounts
+#endif
+import Utility.DataUnits
+import Remote (prettyUUID)
+import Annex.UUID
+import Annex.CurrentBranch
+import Types.StandardGroups
+import Logs.PreferredContent
+import Logs.UUID
+import Utility.UserInfo
+import Config
+import Utility.Gpg
+import qualified Remote.GCrypt as GCrypt
+import qualified Types.Remote
+import Utility.Android
+import Types.ProposedAccepted
+import qualified Utility.RawFilePath as R
+
+import qualified Data.Text as T
+import qualified Data.Map as M
+import Data.Char
+import Data.Ord
+import Data.Kind
+import qualified Text.Hamlet as Hamlet
+
+data RepositoryPath = RepositoryPath Text
+	deriving Show
+
+{- Custom field display for a RepositoryPath, with an icon etc.
+ -
+ - Validates that the path entered is not empty, and is a safe value
+ - to use as a repository. -}
+repositoryPathField :: forall (m :: Type -> Type). (MonadIO m, HandlerSite m ~ WebApp) => Bool -> Field m Text
+repositoryPathField autofocus = Field
+	{ fieldParse = \l _ -> parse l
+	, fieldEnctype = UrlEncoded
+	, fieldView = view
+	}
+  where
+	view idAttr nameAttr attrs val isReq =
+		[whamlet|<input type="text" *{attrs} id="#{idAttr}" name="#{nameAttr}" :isReq:required :autofocus:autofocus value="#{either id id val}">|]
+
+	parse [path]
+		| T.null path = nopath
+		| otherwise = liftIO $ checkRepositoryPath path
+	parse [] = return $ Right Nothing
+	parse _ = nopath
+
+	nopath = return $ Left "Enter a location for the repository"
+
+{- As well as checking the path for a lot of silly things, tilde is
+ - expanded in the returned path. -}
+checkRepositoryPath :: Text -> IO (Either (SomeMessage WebApp) (Maybe Text))
+checkRepositoryPath p = do
+	home <- myHomeDir
+	let basepath = expandTilde home $ T.unpack p
+	path <- fromRawFilePath <$> absPath (toRawFilePath basepath)
+	let parent = fromRawFilePath $ parentDir (toRawFilePath path)
+	problems <- catMaybes <$> mapM runcheck
+		[ (return $ path == "/", "Enter the full path to use for the repository.")
+		, (return $ all isSpace basepath, "A blank path? Seems unlikely.")
+		, (doesFileExist path, "A file already exists with that name.")
+		, (return $ path == home, "Sorry, using git-annex for your whole home directory is not currently supported.")
+		, (not <$> doesDirectoryExist parent, "Parent directory does not exist.")
+		, (not <$> canWrite path, "Cannot write a repository there.")
+		]
+	return $ 
+		case headMaybe problems of
+			Nothing -> Right $ Just $ T.pack basepath
+			Just prob -> Left prob
+  where
+	runcheck (chk, msg) = ifM chk ( return $ Just msg, return Nothing )
+	expandTilde home ('~':'/':path) = home </> path
+	expandTilde _ path = path
+
+{- On first run, if run in the home directory, default to putting it in
+ - ~/Desktop/annex, when a Desktop directory exists, and ~/annex otherwise.
+ -
+ - When on Android, default to ~/storage/shared/annex, which termux sets up
+ - as a link to the sdcard.
+ -
+ - If run in another directory, that the user can write to,
+ - the user probably wants to put it there. Unless that directory
+ - contains a git-annex file, in which case the user has probably
+ - browsed to a directory with git-annex and run it from there. -}
+defaultRepositoryPath :: Bool -> IO FilePath
+defaultRepositoryPath firstrun = do
+#ifndef mingw32_HOST_OS
+	home <- myHomeDir
+	currdir <- liftIO getCurrentDirectory
+	if home == currdir && firstrun
+		then inhome
+		else ifM (legit currdir <&&> canWrite currdir)
+			( return currdir
+			, inhome
+			)
+#else
+	-- On Windows, always default to ~/Desktop/annex or ~/annex,
+	-- no cwd handling because the user might be able to write
+	-- to the entire drive.
+	if firstrun then inhome else inhome
+#endif
+  where
+	inhome = ifM osAndroid
+		( do
+			home <- myHomeDir
+			let storageshared = home </> "storage" </> "shared"
+			ifM (doesDirectoryExist storageshared)
+				( relHome $ storageshared </> gitAnnexAssistantDefaultDir
+				, return $ "~" </> gitAnnexAssistantDefaultDir
+				)
+		, do
+			desktop <- userDesktopDir
+			ifM (doesDirectoryExist desktop <&&> canWrite desktop)
+				( relHome $ desktop </> gitAnnexAssistantDefaultDir
+				, return $ "~" </> gitAnnexAssistantDefaultDir
+				)
+		)
+#ifndef mingw32_HOST_OS
+	-- Avoid using eg, standalone build's git-annex.linux/ directory
+	-- when run from there.
+	legit d = not <$> doesFileExist (d </> "git-annex")
+#endif
+
+newRepositoryForm :: FilePath -> Hamlet.Html -> MkMForm RepositoryPath
+newRepositoryForm defpath msg = do
+	(pathRes, pathView) <- mreq (repositoryPathField True) (bfs "")
+		(Just $ T.pack $ addTrailingPathSeparator defpath)
+	let (err, errmsg) = case pathRes of
+		FormMissing -> (False, "")
+		FormFailure l -> (True, concatMap T.unpack l)
+		FormSuccess _ -> (False, "")
+	let form = do
+		webAppFormAuthToken
+		$(widgetFile "configurators/newrepository/form")
+	return (RepositoryPath <$> pathRes, form)
+
+{- Making the first repository, when starting the webapp for the first time. -}
+getFirstRepositoryR :: Handler Html
+getFirstRepositoryR = postFirstRepositoryR
+postFirstRepositoryR :: Handler Html
+postFirstRepositoryR = page "Getting started" (Just Configuration) $ do
+	unlessM (liftIO $ inSearchPath "git") $
+		giveup "You need to install git in order to use git-annex!"
+	androidspecial <- liftIO osAndroid
+	path <- liftIO . defaultRepositoryPath =<< liftH inFirstRun
+	((res, form), enctype) <- liftH $ runFormPostNoToken $ newRepositoryForm path
+	case res of
+		FormSuccess (RepositoryPath p) -> liftH $
+			startFullAssistant (T.unpack p) ClientGroup Nothing
+		_ -> $(widgetFile "configurators/newrepository/first")
+
+getAndroidCameraRepositoryR :: Handler ()
+getAndroidCameraRepositoryR = do
+	home <- liftIO myHomeDir
+	let dcim = home </> "storage" </> "dcim"
+	startFullAssistant dcim SourceGroup $ Just addignore	
+  where
+	addignore = do
+		liftIO $ unlessM (doesFileExist ".gitignore") $
+			writeFile ".gitignore" ".thumbnails"
+		void $ inRepo $
+			Git.Command.runBool [Param "add", File ".gitignore"]
+
+{- Adding a new local repository, which may be entirely separate, or may
+ - be connected to the current repository. -}
+getNewRepositoryR :: Handler Html
+getNewRepositoryR = postNewRepositoryR
+postNewRepositoryR :: Handler Html
+postNewRepositoryR = page "Add another repository" (Just Configuration) $ do
+	home <- liftIO myHomeDir
+	((res, form), enctype) <- liftH $ runFormPostNoToken $ newRepositoryForm home
+	case res of
+		FormSuccess (RepositoryPath p) -> do
+			let path = T.unpack p
+			isnew <- liftIO $ makeRepo path False
+			u <- liftIO $ initRepo isnew True path Nothing (Just ClientGroup)
+			liftIO $ addAutoStartFile path
+			liftIO $ startAssistant path
+			askcombine u path
+		_ -> $(widgetFile "configurators/newrepository")
+  where
+	askcombine newrepouuid newrepopath = do
+		newrepo <- liftIO $ relHome newrepopath
+		mainrepo <- fromJust . relDir <$> liftH getYesod
+		$(widgetFile "configurators/newrepository/combine")
+
+{- Ensure that a remote's description, group, etc are available by
+ - immediately pulling from it. Also spawns a sync to push to it as well. -}
+immediateSyncRemote :: Remote -> Assistant ()
+immediateSyncRemote r = do
+	currentbranch <- liftAnnex $ getCurrentBranch
+	void $ manualPull currentbranch [r]
+	syncRemote r
+
+getCombineRepositoryR :: FilePath -> UUID -> Handler Html
+getCombineRepositoryR newrepopath newrepouuid = do
+	liftAssistant . immediateSyncRemote =<< combineRepos newrepopath remotename
+	redirect $ EditRepositoryR $ RepoUUID newrepouuid
+  where
+	remotename = takeFileName newrepopath
+
+selectDriveForm :: [RemovableDrive] -> Hamlet.Html -> MkMForm RemovableDrive
+selectDriveForm drives = renderBootstrap3 bootstrapFormLayout $ RemovableDrive
+	<$> pure Nothing
+	<*> areq (selectFieldList pairs `withNote` onlywritable) (bfs "Select drive:") Nothing
+	<*> areq textField (bfs "Use this directory on the drive:")
+		(Just $ T.pack gitAnnexAssistantDefaultDir)
+  where
+	pairs = zip (map describe drives) (map mountPoint drives)
+	describe drive = case diskFree drive of
+		Nothing -> mountPoint drive
+		Just free -> 
+			let sz = roughSize storageUnits True free
+			in T.unwords
+				[ mountPoint drive
+				, T.concat ["(", T.pack sz]
+				, "free)"
+				]
+	onlywritable = [whamlet|This list only includes drives you can write to.|]
+
+removableDriveRepository :: RemovableDrive -> FilePath
+removableDriveRepository drive =
+	T.unpack (mountPoint drive) </> T.unpack (driveRepoPath drive)
+
+{- Adding a removable drive. -}
+getAddDriveR :: Handler Html
+getAddDriveR = postAddDriveR
+postAddDriveR :: Handler Html
+postAddDriveR = page "Add a removable drive" (Just Configuration) $ do
+	removabledrives <- liftIO driveList
+	writabledrives <- liftIO $
+		filterM (canWrite . T.unpack . mountPoint) removabledrives
+	((res, form), enctype) <- liftH $ runFormPostNoToken $
+		selectDriveForm (sort writabledrives)
+	case res of
+		FormSuccess drive -> liftH $ redirect $ ConfirmAddDriveR drive
+		_ -> $(widgetFile "configurators/adddrive")
+
+{- The repo may already exist, when adding removable media
+ - that has already been used elsewhere. If so, check
+ - the UUID of the repo and see if it's one we know. If not,
+ - the user must confirm the repository merge.
+ -
+ - If the repo does not already exist on the drive, prompt about
+ - encryption. -}
+getConfirmAddDriveR :: RemovableDrive -> Handler Html
+getConfirmAddDriveR drive = ifM (liftIO $ probeRepoExists dir)
+	( do
+		mu <- liftIO $ probeUUID dir
+		case mu of
+			Nothing -> maybe askcombine isknownuuid
+				=<< liftAnnex (probeGCryptRemoteUUID dir)
+			Just driveuuid -> isknownuuid driveuuid
+	, newrepo
+	)
+  where
+	dir = removableDriveRepository drive
+	newrepo = do
+		cmd <- liftAnnex $ gpgCmd <$> Annex.getGitConfig
+		secretkeys <- sortBy (comparing snd) . M.toList
+			<$> liftIO (secretKeys cmd)
+		page "Encrypt repository?" (Just Configuration) $
+			$(widgetFile "configurators/adddrive/encrypt")
+	knownrepo = getFinishAddDriveR drive NoRepoKey
+	askcombine = page "Combine repositories?" (Just Configuration) $
+		$(widgetFile "configurators/adddrive/combine")
+	isknownuuid driveuuid =
+		ifM (M.member driveuuid <$> liftAnnex uuidDescMap)
+			( knownrepo
+			, askcombine
+			)
+
+setupDriveModal :: Widget
+setupDriveModal = $(widgetFile "configurators/adddrive/setupmodal")
+
+getGenKeyForDriveR :: RemovableDrive -> Handler Html
+getGenKeyForDriveR drive = withNewSecretKey $ \keyid ->
+	{- Generating a key takes a long time, and 
+	 - the removable drive may have been disconnected
+	 - in the meantime. Check that it is still mounted
+	 - before finishing. -}
+	ifM (liftIO $ any (\d -> mountPoint d == mountPoint drive) <$> driveList)
+		( getFinishAddDriveR drive (RepoKey keyid)
+		, getAddDriveR
+		)
+
+getFinishAddDriveR :: RemovableDrive -> RepoKey -> Handler Html
+getFinishAddDriveR drive = go
+  where
+	go (RepoKey keyid) = whenGcryptInstalled $ makewith $ const $ do
+		r <- liftAnnex $ addRemote $
+			makeGCryptRemote remotename dir keyid
+		return (Types.Remote.uuid r, r)
+	go NoRepoKey = checkGCryptRepoEncryption dir makeunencrypted makeunencrypted $ do
+		mu <- liftAnnex $ probeGCryptRemoteUUID dir
+		case mu of
+			Just u -> enableexistinggcryptremote u
+			Nothing -> giveup "The drive contains a gcrypt repository that is not a git-annex special remote. This is not supported."
+	enableexistinggcryptremote u = do
+		remotename' <- liftAnnex $ getGCryptRemoteName u dir
+		makewith $ const $ do
+			r <- liftAnnex $ addRemote $
+				enableSpecialRemote remotename' GCrypt.remote Nothing $ M.fromList
+					[(Proposed "gitrepo", Proposed dir)]
+			return (u, r)
+	{- Making a new unencrypted repo, or combining with an existing one. -}
+	makeunencrypted = makewith $ \isnew -> (,)
+		<$> liftIO (initRepo isnew False dir (Just remotename) Nothing)
+		<*> combineRepos dir remotename
+	makewith a = do
+		liftIO $ createDirectoryIfMissing True dir
+		isnew <- liftIO $ makeRepo dir True
+		{- Removable drives are not reliable media, so enable fsync. -}
+		liftIO $ inDir dir $
+			setConfig "core.fsyncobjectfiles"
+				(Git.Config.boolConfig True)
+		(u, r) <- a isnew
+		when isnew $
+			liftAnnex $ defaultStandardGroup u TransferGroup
+		liftAssistant $ immediateSyncRemote r
+		redirect $ EditNewRepositoryR u
+	mountpoint = T.unpack (mountPoint drive)
+	dir = removableDriveRepository drive
+	remotename = takeFileName mountpoint
+
+{- Each repository is made a remote of the other.
+ - Next call syncRemote to get them in sync. -}
+combineRepos :: FilePath -> String -> Handler Remote
+combineRepos dir name = liftAnnex $ do
+	hostname <- fromMaybe "host" <$> liftIO getHostname
+	mylocation <- fromRepo Git.repoLocation
+	mypath <- liftIO $ fromRawFilePath <$> relPathDirToFile
+		(toRawFilePath dir)
+		(toRawFilePath mylocation)
+	liftIO $ inDir dir $ void $ makeGitRemote hostname mypath
+	addRemote $ makeGitRemote name dir
+
+getEnableDirectoryR :: UUID -> Handler Html
+getEnableDirectoryR uuid = page "Enable a repository" (Just Configuration) $ do
+	description <- liftAnnex $ T.pack <$> prettyUUID uuid
+	$(widgetFile "configurators/enabledirectory")
+
+{- List of removable drives. -}
+driveList :: IO [RemovableDrive]
+#ifdef mingw32_HOST_OS
+-- Just enumerate all likely drive letters for Windows.
+-- Could use wmic, but it only works for administrators.
+driveList = mapM (\d -> genRemovableDrive $ d:":\\") ['A'..'Z']
+#else
+driveList = mapM (genRemovableDrive . mnt_dir) =<< filter sane <$> getMounts
+  where
+	-- filter out some things that are surely not removable drives
+	sane Mntent { mnt_dir = dir, mnt_fsname = dev }
+		{- We want real disks like /dev/foo, not
+		 - dummy mount points like proc or tmpfs or
+		 - gvfs-fuse-daemon. -}
+		| not ('/' `elem` dev) = False
+		{- Just in case: These mount points are surely not
+		 - removable disks. -}
+		| dir == "/" = False
+		| dir == "/tmp" = False
+		| dir == "/run/shm" = False
+		| dir == "/run/lock" = False
+		| otherwise = True
+#endif
+
+genRemovableDrive :: FilePath -> IO RemovableDrive
+genRemovableDrive dir = RemovableDrive
+	<$> getDiskFree dir
+	<*> pure (T.pack dir)
+	<*> pure (T.pack gitAnnexAssistantDefaultDir)
+
+{- Bootstraps from first run mode to a fully running assistant in a
+ - repository, by running the postFirstRun callback, which returns the
+ - url to the new webapp. -}
+startFullAssistant :: FilePath -> StandardGroup -> Maybe (Annex ())-> Handler ()
+startFullAssistant path repogroup setup = do
+	webapp <- getYesod
+	url <- liftIO $ do
+		isnew <- makeRepo path False
+		void $ initRepo isnew True path Nothing (Just repogroup)
+		inDir path $ fromMaybe noop setup
+		addAutoStartFile path
+		setCurrentDirectory path
+		fromJust $ postFirstRun webapp
+	redirect $ T.pack url
+
+{- Checks if the user can write to a directory.
+ -
+ - The directory may be in the process of being created; if so
+ - the parent directory is checked instead. -}
+canWrite :: FilePath -> IO Bool		
+canWrite dir = do
+	tocheck <- ifM (doesDirectoryExist dir)
+		( return dir
+		, return $ fromRawFilePath $ parentDir $ toRawFilePath dir
+		)
+	catchBoolIO $ R.fileAccess (toRawFilePath tocheck) False True False
+
+{- Gets the UUID of the git repo at a location, which may not exist, or
+ - not be a git-annex repo. -}
+probeUUID :: FilePath -> IO (Maybe UUID)
+probeUUID dir = catchDefaultIO Nothing $ inDir dir $ do
+	u <- getUUID
+	return $ if u == NoUUID then Nothing else Just u
diff --git a/Assistant/WebApp/Configurators/Pairing.hs b/Assistant/WebApp/Configurators/Pairing.hs
new file mode 100644
index 0000000000..ceff21a3bf
--- /dev/null
+++ b/Assistant/WebApp/Configurators/Pairing.hs
@@ -0,0 +1,321 @@
+{- git-annex assistant webapp configurator for pairing
+ -
+ - Copyright 2012,2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeFamilies, QuasiQuotes, TemplateHaskell, OverloadedStrings, FlexibleContexts #-}
+{-# LANGUAGE CPP #-}
+
+module Assistant.WebApp.Configurators.Pairing where
+
+import Assistant.Pairing
+import Assistant.WebApp.Common
+import Annex.UUID
+#ifdef WITH_PAIRING
+import Assistant.DaemonStatus
+import Assistant.Pairing.MakeRemote
+import Assistant.Pairing.Network
+import Assistant.Ssh
+import Utility.Verifiable
+#endif
+import Utility.UserInfo
+import Utility.Tor
+import Utility.Su
+import Assistant.WebApp.Pairing
+import Assistant.Alert
+import qualified Utility.MagicWormhole as Wormhole
+import Assistant.MakeRemote
+import Assistant.RemoteControl
+import Assistant.Sync
+import Assistant.WebApp.SideBar
+import Command.P2P (unusedPeerRemoteName, PairingResult(..))
+import P2P.Address
+import Git
+import Annex.Path
+import Utility.Process.Transcript
+
+import qualified Data.Map as M
+import qualified Data.Text as T
+#ifdef WITH_PAIRING
+import qualified Data.Text.Encoding as T
+import qualified Data.ByteString as B
+import Data.Char
+import qualified Control.Exception as E
+import Control.Concurrent
+#endif
+import Control.Concurrent.STM hiding (check)
+
+getStartWormholePairFriendR :: Handler Html
+getStartWormholePairFriendR = startWormholePairR PairingWithFriend
+
+getStartWormholePairSelfR :: Handler Html
+getStartWormholePairSelfR = startWormholePairR PairingWithSelf
+
+startWormholePairR :: PairingWith -> Handler Html
+startWormholePairR pairingwith = whenTorInstalled $ whenWormholeInstalled $
+	pairPage $ do
+		sucommand <- liftIO $ mkSuCommand "git-annex" [Param "enable-tor"]
+		$(widgetFile "configurators/pairing/wormhole/start")
+
+getPrepareWormholePairR :: PairingWith -> Handler Html
+getPrepareWormholePairR pairingwith = do
+	enableTor
+	myaddrs <- liftAnnex loadP2PAddresses
+	remotename <- liftAnnex unusedPeerRemoteName
+	h <- liftAssistant $
+		startWormholePairing pairingwith remotename myaddrs
+	i <- liftIO . addWormholePairingState h
+		=<< wormholePairingState <$> getYesod
+	redirect $ RunningWormholePairR i
+
+enableTor :: Handler ()
+enableTor = do
+	gitannex <- liftIO programPath
+	(transcript, ok) <- liftIO $ processTranscript gitannex ["enable-tor"] Nothing
+	if ok
+		-- Reload remotedameon so it's serving the tor hidden
+		-- service.
+		then liftAssistant $ sendRemoteControl RELOAD
+		else giveup $ "Failed to enable tor\n\n" ++ transcript
+
+getRunningWormholePairR :: WormholePairingId -> Handler Html
+getRunningWormholePairR = runningWormholePairR
+
+postRunningWormholePairR :: WormholePairingId -> Handler Html
+postRunningWormholePairR = runningWormholePairR
+
+runningWormholePairR :: WormholePairingId -> Handler Html
+runningWormholePairR i = go =<< getWormholePairingHandle i
+  where
+	go Nothing = redirect StartWormholePairFriendR
+	go (Just h) = pairPage $  withPairingWith h $ \pairingwith -> do
+		ourcode <- liftIO $ getOurWormholeCode h
+		let codeprompt = case pairingwith of
+			PairingWithFriend -> "Your friend's pairing code"
+			PairingWithSelf -> "The other device's pairing code"
+		((result, form), enctype) <- liftH $
+			runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $
+				areq (checkwormholecode ourcode pairingwith textField) (bfs codeprompt) Nothing
+		case result of
+			FormSuccess t -> case Wormhole.toCode (T.unpack t) of
+				Nothing -> giveup invalidcode
+				Just theircode -> finish h theircode
+			_ -> showform form enctype ourcode pairingwith
+	
+	showform form enctype ourcode pairingwith =
+		$(widgetFile "configurators/pairing/wormhole/prompt")
+	
+	checkwormholecode ourcode pairingwith = check $ \t ->
+		case Wormhole.toCode (T.unpack t) of
+			Nothing -> Left (T.pack invalidcode)
+			Just theircode
+				| theircode == ourcode -> Left $
+					case pairingwith of
+						PairingWithSelf -> "Oops -- You entered this repository's pairing code. Enter the pairing code of the *other* repository."
+						PairingWithFriend -> "Oops -- You entered your pairing code. Enter your friend's pairing code."
+				| otherwise -> Right t
+
+	invalidcode = "That does not look like a valid pairing code. Try again..."
+
+	finish h theircode = do
+		void $ liftIO $ sendTheirWormholeCode h theircode
+		res <- liftAssistant $ finishWormholePairing h
+		case res of
+			SendFailed -> giveup "Failed sending data to pair."
+			ReceiveFailed -> giveup "Failed receiving data from pair."
+			LinkFailed e -> giveup $ "Failed linking to pair: " ++ e
+			PairSuccess -> withRemoteName h $ \remotename -> do
+				r <- liftAnnex $ addRemote (return remotename)
+				liftAssistant $ syncRemote r
+				liftAssistant $ sendRemoteControl RELOAD
+				redirect DashboardR
+
+getWormholePairingHandle :: WormholePairingId -> Handler (Maybe WormholePairingHandle)
+getWormholePairingHandle i = do
+	s <- wormholePairingState <$> getYesod
+	liftIO $ atomically $ M.lookup i <$> readTVar s
+
+whenTorInstalled :: Handler Html -> Handler Html
+whenTorInstalled a = ifM (liftIO torIsInstalled)
+	( a
+	, page "Need Tor" (Just Configuration) $
+		$(widgetFile "configurators/needtor")
+	)
+
+whenWormholeInstalled :: Handler Html -> Handler Html
+whenWormholeInstalled a = ifM (liftIO Wormhole.isInstalled)
+	( a
+	, page "Need Magic Wormhole" (Just Configuration) $
+		$(widgetFile "configurators/needmagicwormhole")
+	)
+
+{- Starts local pairing. -}
+getStartLocalPairR :: Handler Html
+getStartLocalPairR = postStartLocalPairR
+postStartLocalPairR :: Handler Html
+#ifdef WITH_PAIRING
+postStartLocalPairR = promptSecret Nothing $
+	startLocalPairing PairReq noop pairingAlert Nothing
+#else
+postStartLocalPairR = noLocalPairing
+
+noLocalPairing :: Handler Html
+noLocalPairing = noPairing "local"
+#endif
+
+{- Runs on the system that responds to a local pair request; sets up the ssh
+ - authorized key first so that the originating host can immediately sync
+ - with us. -}
+getFinishLocalPairR :: PairMsg -> Handler Html
+getFinishLocalPairR = postFinishLocalPairR
+postFinishLocalPairR :: PairMsg -> Handler Html
+#ifdef WITH_PAIRING
+postFinishLocalPairR msg = promptSecret (Just msg) $ \_ secret -> do
+	repodir <- liftH $ fromRawFilePath . repoPath <$> liftAnnex gitRepo
+	liftIO $ setup repodir
+	startLocalPairing PairAck (cleanup repodir) alert uuid "" secret
+  where
+	alert = pairRequestAcknowledgedAlert (pairRepo msg) . Just
+	setup repodir = setupAuthorizedKeys msg repodir
+	cleanup repodir = removeAuthorizedKeys True repodir $
+		remoteSshPubKey $ pairMsgData msg
+	uuid = Just $ pairUUID $ pairMsgData msg
+#else
+postFinishLocalPairR _ = noLocalPairing
+#endif
+
+getRunningLocalPairR :: SecretReminder -> Handler Html
+#ifdef WITH_PAIRING
+getRunningLocalPairR s = pairPage $ do
+	let secret = fromSecretReminder s
+	$(widgetFile "configurators/pairing/local/inprogress")
+#else
+getRunningLocalPairR _ = noLocalPairing
+#endif
+
+#ifdef WITH_PAIRING
+
+{- Starts local pairing, at either the PairReq (initiating host) or 
+ - PairAck (responding host) stage.
+ -
+ - Displays an alert, and starts a thread sending the pairing message,
+ - which will continue running until the other host responds, or until
+ - canceled by the user. If canceled by the user, runs the oncancel action.
+ -
+ - Redirects to the pairing in progress page.
+ -}
+startLocalPairing :: PairStage -> IO () -> (AlertButton -> Alert) -> Maybe UUID -> Text -> Secret -> Widget
+startLocalPairing stage oncancel alert muuid displaysecret secret = do
+	urlrender <- liftH getUrlRender
+	reldir <- fromJust . relDir <$> liftH getYesod
+
+	sendrequests <- liftAssistant $ asIO2 $ mksendrequests urlrender
+	{- Generating a ssh key pair can take a while, so do it in the
+	 - background. -}
+	thread <- liftAssistant $ asIO $ do
+		keypair <- liftIO $ genSshKeyPair
+		let pubkey = either giveup id $ validateSshPubKey $ sshPubKey keypair
+		pairdata <- liftIO $ PairData
+			<$> getHostname
+			<*> (either giveup id <$> myUserName)
+			<*> pure reldir
+			<*> pure pubkey
+			<*> (maybe genUUID return muuid)
+		let sender = multicastPairMsg Nothing secret pairdata
+		let pip = PairingInProgress secret Nothing keypair pairdata stage
+		startSending pip stage $ sendrequests sender
+	void $ liftIO $ forkIO thread
+
+	liftH $ redirect $ RunningLocalPairR $ toSecretReminder displaysecret
+  where
+	{- Sends pairing messages until the thread is killed,
+	 - and shows an activity alert while doing it.
+	 -
+	 - The cancel button returns the user to the DashboardR. This is
+	 - not ideal, but they have to be sent somewhere, and could
+	 - have been on a page specific to the in-process pairing
+	 - that just stopped, so can't go back there.
+	 -}
+	mksendrequests urlrender sender _stage = do
+		tid <- liftIO myThreadId
+		let selfdestruct = AlertButton
+			{ buttonLabel = "Cancel"
+			, buttonPrimary = True
+			, buttonUrl = urlrender DashboardR
+			, buttonAction = Just $ const $ do
+				oncancel
+				killThread tid
+			}
+		alertDuring (alert selfdestruct) $ liftIO $ do
+			_ <- E.try (sender stage) :: IO (Either E.SomeException ())
+			return ()
+
+data InputSecret = InputSecret { secretText :: Maybe Text }
+
+{- If a PairMsg is passed in, ensures that the user enters a secret
+ - that can validate it. -}
+promptSecret :: Maybe PairMsg -> (Text -> Secret -> Widget) -> Handler Html
+promptSecret msg cont = pairPage $ do
+	((result, form), enctype) <- liftH $
+		runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $
+			InputSecret <$> aopt textField (bfs "Secret phrase") Nothing
+	case result of
+		FormSuccess v -> do
+			let rawsecret = fromMaybe "" $ secretText v
+			let secret = toSecret rawsecret
+			case msg of
+				Nothing -> case secretProblem secret of
+					Nothing -> cont rawsecret secret
+					Just problem ->
+						showform form enctype $ Just problem
+				Just m ->
+					if verify (fromPairMsg m) secret
+						then cont rawsecret secret
+						else showform form enctype $ Just
+							"That's not the right secret phrase."
+		_ -> showform form enctype Nothing
+  where
+	showform form enctype mproblem = do
+		let start = isNothing msg
+		let badphrase = isJust mproblem
+		let problem = fromMaybe "" mproblem
+		let (username, hostname) = maybe ("", "")
+			(\(_, v, a) -> (T.pack $ remoteUserName v, T.pack $ fromMaybe (showAddr a) (remoteHostName v)))
+			(verifiableVal . fromPairMsg <$> msg)
+		u <- liftIO myUserName
+		let sameusername = Right username == (T.pack <$> u)
+		$(widgetFile "configurators/pairing/local/prompt")
+
+{- This counts unicode characters as more than one character,
+ - but that's ok; they *do* provide additional entropy. -}
+secretProblem :: Secret -> Maybe Text
+secretProblem s
+	| B.null s = Just "The secret phrase cannot be left empty. (Remember that punctuation and white space is ignored.)"
+	| B.length s < 6 = Just "Enter a longer secret phrase, at least 6 characters, but really, a phrase is best! This is not a password you'll need to enter every day."
+	| s == toSecret sampleQuote = Just "Speaking of foolishness, don't paste in the example I gave. Enter a different phrase, please!"
+	| otherwise = Nothing
+
+toSecret :: Text -> Secret
+toSecret s = T.encodeUtf8 $ T.toLower $ T.filter isAlphaNum s
+
+{- From Dickens -}
+sampleQuote :: Text
+sampleQuote = T.unwords
+	[ "It was the best of times,"
+	, "it was the worst of times,"
+	, "it was the age of wisdom,"
+	, "it was the age of foolishness."
+	]
+
+#else
+
+#endif
+
+pairPage :: Widget -> Handler Html
+pairPage = page "Pairing" (Just Configuration)
+
+noPairing :: Text -> Handler Html
+noPairing pairingtype = pairPage $
+	$(widgetFile "configurators/pairing/disabled")
diff --git a/Assistant/WebApp/Configurators/Preferences.hs b/Assistant/WebApp/Configurators/Preferences.hs
new file mode 100644
index 0000000000..14b3267b1c
--- /dev/null
+++ b/Assistant/WebApp/Configurators/Preferences.hs
@@ -0,0 +1,114 @@
+{- git-annex assistant general preferences
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Configurators.Preferences (
+	getPreferencesR,
+	postPreferencesR
+) where
+
+import Assistant.WebApp.Common
+import qualified Annex
+import qualified Git
+import Config
+import Config.Files.AutoStart
+import Annex.NumCopies
+import Utility.DataUnits
+import Types.Distribution
+import Assistant.Upgrade
+
+import qualified Data.Text as T
+import qualified System.FilePath.ByteString as P
+
+data PrefsForm = PrefsForm
+	{ diskReserve :: Text
+	, numCopies :: Int
+	, autoStart :: Bool
+	, autoUpgrade :: AutoUpgrade
+	}
+
+prefsAForm :: PrefsForm -> MkAForm PrefsForm
+prefsAForm d = PrefsForm
+	<$> areq (storageField `withNote` diskreservenote)
+		(bfs "Disk reserve") (Just $ diskReserve d)
+	<*> areq (positiveIntField `withNote` numcopiesnote)
+		(bfs "Number of copies") (Just $ numCopies d)
+	<*> areq (checkBoxField `withNote` autostartnote)
+		"Auto start" (Just $ autoStart d)
+	<*> areq (selectFieldList autoUpgradeChoices)
+		(bfs autoUpgradeLabel) (Just $ autoUpgrade d)
+  where
+	diskreservenote = [whamlet|<br>Avoid downloading files from other repositories when there is too little free disk space.|]
+	numcopiesnote = [whamlet|<br>Only drop a file after verifying that other repositories contain this many copies.|]
+	autostartnote = [whamlet|Start the git-annex assistant at boot or on login.|]
+
+	autoUpgradeChoices :: [(Text, AutoUpgrade)]
+	autoUpgradeChoices =
+		[ ("ask me", AskUpgrade)
+		, ("enabled", AutoUpgrade)
+		, ("disabled", NoAutoUpgrade)
+		]
+	autoUpgradeLabel
+		| upgradeSupported = "Auto upgrade"
+		| otherwise = "Auto restart on upgrade"
+
+	positiveIntField = check isPositive intField
+	  where
+		isPositive i
+			| i > 0 = Right i
+			| otherwise = Left notPositive
+		notPositive :: Text
+		notPositive = "This should be 1 or more!"
+
+	storageField = check validStorage textField
+	  where
+		validStorage t
+			| T.null t = Right t
+			| otherwise =  case readSize dataUnits $ T.unpack t of
+				Nothing -> Left badParse
+				Just _ -> Right t
+		badParse :: Text
+		badParse = "Parse error. Expected something like \"100 megabytes\" or \"2 gb\""
+
+getPrefs :: Annex PrefsForm
+getPrefs = PrefsForm
+	<$> (T.pack . roughSize storageUnits False . annexDiskReserve <$> Annex.getGitConfig)
+	<*> (fromNumCopies <$> getNumCopies)
+	<*> inAutoStartFile
+	<*> (annexAutoUpgrade <$> Annex.getGitConfig)
+
+storePrefs :: PrefsForm -> Annex ()
+storePrefs p = do
+	setConfig (annexConfig "diskreserve") (T.unpack $ diskReserve p)
+	setGlobalNumCopies (configuredNumCopies $ numCopies p)
+	unsetConfig (annexConfig "numcopies") -- deprecated
+	setConfig (annexConfig "autoupgrade") (fromAutoUpgrade $ autoUpgrade p)
+	unlessM ((==) <$> pure (autoStart p) <*> inAutoStartFile) $ do
+		here <- fromRawFilePath <$> fromRepo Git.repoPath
+		liftIO $ if autoStart p
+			then addAutoStartFile here
+			else removeAutoStartFile here
+
+getPreferencesR :: Handler Html
+getPreferencesR = postPreferencesR
+postPreferencesR :: Handler Html
+postPreferencesR = page "Preferences" (Just Configuration) $ do
+	((result, form), enctype) <- liftH $ do
+		current <- liftAnnex getPrefs
+		runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $ prefsAForm current
+	case result of
+		FormSuccess new -> liftH $ do
+			liftAnnex $ storePrefs new
+			redirect ConfigurationR
+		_ -> $(widgetFile "configurators/preferences")
+
+inAutoStartFile :: Annex Bool
+inAutoStartFile = do
+	here <- liftIO . absPath =<< fromRepo Git.repoPath
+	any (`P.equalFilePath` here) . map toRawFilePath
+		<$> liftIO readAutoStartFile
diff --git a/Assistant/WebApp/Configurators/Ssh.hs b/Assistant/WebApp/Configurators/Ssh.hs
new file mode 100644
index 0000000000..04ac8ceb1d
--- /dev/null
+++ b/Assistant/WebApp/Configurators/Ssh.hs
@@ -0,0 +1,674 @@
+{- git-annex assistant webapp configurator for ssh-based remotes
+ -
+ - Copyright 2012-2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings, FlexibleContexts #-}
+
+module Assistant.WebApp.Configurators.Ssh where
+
+import Assistant.WebApp.Common
+import Assistant.WebApp.Gpg
+import Assistant.Ssh
+import Annex.Ssh
+import Assistant.WebApp.MakeRemote
+import Logs.Remote
+import Remote
+import Types.StandardGroups
+import Utility.UserInfo
+import Utility.Gpg
+import Types.Remote (RemoteConfig)
+import Types.ProposedAccepted
+import Git.Types (RemoteName, fromRef, fromConfigKey)
+import qualified Remote.GCrypt as GCrypt
+import qualified Annex
+import qualified Git.Command
+import qualified Annex.Branch
+import Annex.UUID
+import Logs.UUID
+import Annex.SpecialRemote.Config
+import Assistant.RemoteControl
+import Types.Creds
+import Assistant.CredPairCache
+import Annex.Path
+import Utility.Tmp
+import Utility.FileMode
+import Utility.ThreadScheduler
+import Utility.Env
+import Utility.SshHost
+import Utility.Process.Transcript
+
+import qualified Data.Text as T
+import qualified Data.Map as M
+import Network.Socket
+import Data.Ord
+
+sshConfigurator :: Widget -> Handler Html
+sshConfigurator = page "Add a remote server" (Just Configuration)
+
+data SshInput = SshInput
+	{ inputHostname :: Maybe Text
+	, inputUsername :: Maybe Text
+	, inputAuthMethod :: AuthMethod
+	, inputPassword :: Maybe Text
+	, inputDirectory :: Maybe Text
+	, inputPort :: Int
+	}
+
+data AuthMethod
+	= Password
+	| CachedPassword
+	| ExistingSshKey
+	deriving (Eq, Show)
+
+-- Is a repository a new one that's being created, or did it already exist
+-- and is just being added.
+data RepoStatus = NewRepo | ExistingRepo
+
+{- SshInput is only used for applicative form prompting, this converts
+ - the result of such a form into a SshData. -}
+mkSshData :: SshInput -> SshData
+mkSshData s = SshData 
+	{ sshHostName = fromMaybe "" $ inputHostname s
+	, sshUserName = inputUsername s
+	, sshDirectory = fromMaybe "" $ inputDirectory s
+	, sshRepoName = genSshRepoName
+		(T.unpack $ fromJust $ inputHostname s)
+		(maybe "" T.unpack $ inputDirectory s)
+	, sshPort = inputPort s
+	, needsPubKey = False
+	, sshCapabilities = [] -- untested
+	, sshRepoUrl = Nothing
+	}
+
+mkSshInput :: SshData -> SshInput
+mkSshInput s = SshInput
+	{ inputHostname = Just $ sshHostName s
+	, inputUsername = sshUserName s
+	, inputAuthMethod = if needsPubKey s then CachedPassword else ExistingSshKey
+	, inputPassword = Nothing
+	, inputDirectory = Just $ sshDirectory s
+	, inputPort = sshPort s
+	}
+
+sshInputAForm :: Field Handler Text -> SshInput -> AForm Handler SshInput
+sshInputAForm hostnamefield d = normalize <$> gen
+  where
+	gen = SshInput
+		<$> aopt check_hostname (bfs "Host name") (Just $ inputHostname d)
+		<*> aopt check_username (bfs "User name") (Just $ inputUsername d)
+		<*> areq (selectFieldList authmethods) (bfs "Authenticate with") (Just $ inputAuthMethod d)
+		<*> aopt passwordField (bfs "Password") Nothing
+		<*> aopt textField (bfs "Directory") (Just $ Just $ fromMaybe (T.pack gitAnnexAssistantDefaultDir) $ inputDirectory d)
+		<*> areq intField (bfs "Port") (Just $ inputPort d)
+	
+	authmethods :: [(Text, AuthMethod)]
+	authmethods =
+		[ ("password", Password)
+		, ("existing ssh key", ExistingSshKey)
+		]
+
+	check_username = checkBool (all (`notElem` ("/:@ \t" :: String)) . T.unpack)
+		bad_username textField
+
+	bad_username = "bad user name" :: Text
+	bad_hostname = "cannot resolve host name" :: Text
+
+	check_hostname = checkM (liftIO . checkdns) hostnamefield
+	checkdns t = do
+		let h = T.unpack t
+		let canonname = Just $ defaultHints { addrFlags = [AI_CANONNAME] }
+		r <- catchMaybeIO $ getAddrInfo canonname (Just h) Nothing
+		return $ case mapMaybe addrCanonName <$> r of
+			-- canonicalize input hostname if it had no dot
+			Just (fullname:_)
+				| '.' `elem` h -> Right t
+				| otherwise -> Right $ T.pack fullname
+			Just [] -> Right t
+			Nothing -> Left bad_hostname
+
+	-- The directory is implicitly in home, so remove any leading ~/
+	normalize i = i { inputDirectory = normalizedir <$> inputDirectory i }
+	normalizedir dir
+		| "~/" `T.isPrefixOf` dir = T.drop 2 dir
+		| "/~/" `T.isPrefixOf` dir = T.drop 3 dir
+		| otherwise = dir
+
+data ServerStatus
+	= UntestedServer
+	| UnusableServer Text -- reason why it's not usable
+	| ServerNeedsPubKey SshPubKey
+	| UsableServer [SshServerCapability]
+	deriving (Eq)
+
+capabilities :: ServerStatus -> [SshServerCapability]
+capabilities (UsableServer cs) = cs
+capabilities _ = []
+
+getAddSshR :: Handler Html
+getAddSshR = postAddSshR
+postAddSshR :: Handler Html
+postAddSshR = sshConfigurator $ do
+	username <- liftIO $ either (const Nothing) (Just . T.pack) <$> myUserName
+	((result, form), enctype) <- liftH $
+		runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $ sshInputAForm textField $
+			SshInput Nothing username Password Nothing Nothing 22
+	case result of
+		FormSuccess sshinput -> do
+			s <- liftAssistant $ testServer sshinput
+			case s of
+				Left status -> showform form enctype status
+				Right (sshdata, u) -> liftH $ redirect $ ConfirmSshR sshdata u
+		_ -> showform form enctype UntestedServer
+  where
+	showform form enctype status = $(widgetFile "configurators/ssh/add")
+
+sshTestModal :: Widget
+sshTestModal = $(widgetFile "configurators/ssh/testmodal")
+
+sshSetupModal :: SshData -> Widget
+sshSetupModal sshdata = $(widgetFile "configurators/ssh/setupmodal")
+
+getEnableRsyncR :: UUID -> Handler Html
+getEnableRsyncR = postEnableRsyncR
+postEnableRsyncR :: UUID -> Handler Html
+postEnableRsyncR = enableSshRemote getsshinput enableRsyncNet enablersync
+  where
+	enablersync sshdata u = redirect $ ConfirmSshR
+		(sshdata { sshCapabilities = [RsyncCapable] }) u
+	getsshinput = parseSshUrl . fromProposedAccepted <=< M.lookup (Accepted "rsyncurl")
+
+{- This only handles gcrypt repositories that are located on ssh servers;
+ - ones on local drives are handled via another part of the UI. -}
+getEnableSshGCryptR :: UUID -> Handler Html
+getEnableSshGCryptR = postEnableSshGCryptR
+postEnableSshGCryptR :: UUID -> Handler Html
+postEnableSshGCryptR u = whenGcryptInstalled $
+	enableSshRemote getsshinput enableRsyncNetGCrypt enablegcrypt u
+  where
+	enablegcrypt sshdata _ = prepSsh False sshdata $ \sshdata' ->
+		sshConfigurator $
+			checkExistingGCrypt sshdata' $
+				giveup "Expected to find an encrypted git repository, but did not."
+	getsshinput = parseSshUrl . fromProposedAccepted <=< M.lookup (Accepted "gitrepo")
+
+getEnableSshGitRemoteR :: UUID -> Handler Html
+getEnableSshGitRemoteR = postEnableSshGitRemoteR
+postEnableSshGitRemoteR :: UUID -> Handler Html
+postEnableSshGitRemoteR = enableSshRemote getsshinput enableRsyncNet enablesshgitremote
+  where
+	enablesshgitremote sshdata u = redirect $ ConfirmSshR sshdata u
+
+	getsshinput = parseSshUrl . fromProposedAccepted <=< M.lookup (Accepted "location")
+
+{- To enable a remote that uses ssh as its transport, 
+ - parse a config key to get its url, and display a form
+ - to prompt for its password.
+ -}
+enableSshRemote :: (RemoteConfig -> Maybe SshData) -> (SshInput -> RemoteName -> Handler Html) -> (SshData -> UUID -> Handler Html) -> UUID -> Handler Html
+enableSshRemote getsshdata rsyncnetsetup genericsetup u = do
+	m <- fromMaybe M.empty . M.lookup u <$> liftAnnex remoteConfigMap
+	case (unmangle <$> getsshdata m, lookupName m) of
+		(Just sshdata, Just reponame) -> sshConfigurator $ do
+			((result, form), enctype) <- liftH $
+				runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $
+					sshInputAForm textField $ mkSshInput sshdata
+			case result of
+				FormSuccess sshinput
+					| isRsyncNet (inputHostname sshinput) ->
+						void $ liftH $ rsyncnetsetup sshinput reponame
+					| otherwise -> do
+						s <- liftAssistant $ testServer sshinput
+						case s of
+							Left status -> showform form enctype status
+							Right (sshdata', _u) -> void $ liftH $ genericsetup
+								( sshdata' { sshRepoName = reponame } ) u
+				_ -> showform form enctype UntestedServer
+		_ -> redirect AddSshR
+  where
+	unmangle sshdata = sshdata
+		{ sshHostName = T.pack $ unMangleSshHostName $
+			T.unpack $ sshHostName sshdata
+		}
+	showform form enctype status = do
+		description <- liftAnnex $ T.pack <$> prettyUUID u
+		$(widgetFile "configurators/ssh/enable")
+
+{- To deal with git-annex and possibly even git and rsync not being
+ - available in the remote server's PATH, when git-annex was installed
+ - from the standalone tarball etc, look for a ~/.ssh/git-annex-wrapper
+ - and if it's there, use it to run a command. -}
+wrapCommand :: String -> String
+wrapCommand cmd = "if [ -x " ++ commandWrapper ++ " ]; then " ++ commandWrapper ++ " " ++ cmd ++ "; else " ++ cmd ++ "; fi"
+
+commandWrapper :: String
+commandWrapper = "~/.ssh/git-annex-wrapper"
+
+{- Test if we can ssh into the server, using the specified AuthMethod.
+ -
+ - Once logged into the server, probe to see if git-annex-shell,
+ - git, and rsync are available. 
+ -
+ - Note that ~/.ssh/git-annex-shell may be present, while
+ - git-annex-shell is not in PATH.
+ - Also, git and rsync may not be in PATH; as long as the commandWrapper
+ - is present, assume it is able to be used to run them.
+ -
+ - Also probe to see if there is already a git repository at the location
+ - with either an annex-uuid or a gcrypt-id set. (If not, returns NoUUID.)
+ -}
+testServer :: SshInput -> Assistant (Either ServerStatus (SshData, UUID))
+testServer (SshInput { inputHostname = Nothing }) = return $
+	Left $ UnusableServer "Please enter a host name."
+testServer sshinput@(SshInput { inputHostname = Just hn }) = do
+	(status, u) <- probe
+	case capabilities status of
+		[] -> return $ Left status
+		cs -> do
+			let sshdata = (mkSshData sshinput)
+				{ needsPubKey = inputAuthMethod sshinput /= ExistingSshKey
+				, sshCapabilities = cs
+				}
+			return $ Right (sshdata, u)
+  where
+	probe = do
+		let remotecommand = shellWrap $ intercalate ";"
+			[ report "loggedin"
+			, checkcommand "git-annex-shell"
+			, checkcommand "git"
+			, checkcommand "rsync"
+			, checkcommand shim
+			, checkcommand commandWrapper
+			, getgitconfig (T.unpack <$> inputDirectory sshinput)
+			]
+		knownhost <- liftIO $ knownHost hn
+		let sshopts =
+			{- If this is an already known host, let
+			 - ssh check it as usual.
+			 - Otherwise, trust the host key. -}
+			[ sshOpt "StrictHostKeyChecking" $
+				if knownhost then "yes" else "no"
+			, "-n" -- don't read from stdin
+			, "-p", show (inputPort sshinput)
+			]
+		let sshhost = genSshHost
+			(fromJust $ inputHostname sshinput)
+			(inputUsername sshinput)
+		parsetranscript . fst <$> sshAuthTranscript sshinput sshopts sshhost remotecommand Nothing
+	parsetranscript s =
+		let cs = map snd $ filter (reported . fst)
+			[ ("git-annex-shell", GitAnnexShellCapable)
+			, (shim, GitAnnexShellCapable)
+			, ("git", GitCapable)
+			, ("rsync", RsyncCapable)
+			, (commandWrapper, GitCapable)
+			, (commandWrapper, RsyncCapable)
+			]
+		    u = fromMaybe NoUUID $ headMaybe $ mapMaybe finduuid $
+			map (separate (== '=')) $ lines s
+		in if null cs
+			then (UnusableServer unusablereason, u)
+			else (UsableServer cs, u)
+	  where
+		reported r = token r `isInfixOf` s
+		unusablereason = if reported "loggedin"
+				then "Neither rsync nor git-annex are installed on the server. Perhaps you should go install them?"
+				else T.pack $ "Failed to ssh to the server. Transcript: " ++ s
+		finduuid (k, v)
+			| k == "annex.uuid" = Just $ toUUID v
+			| k == fromConfigKey GCrypt.coreGCryptId =
+				Just $ genUUIDInNameSpace gCryptNameSpace (encodeBS v)
+			| otherwise = Nothing
+	
+	checkcommand c = "if which " ++ c ++ "; then " ++ report c ++ "; fi"
+	token r = "git-annex-probe " ++ r
+	report r = "echo " ++ shellEscape (token r)
+	shim = "~/.ssh/git-annex-shell"
+	getgitconfig (Just d)
+		| not (null d) = "cd " ++ shellEscape d ++ " && git config --list"
+	getgitconfig _ = "echo"
+
+{- Runs a ssh command to set up the repository; if it fails shows
+ - the user the transcript, and if it succeeds, runs an action. -}
+sshSetup :: SshInput -> [String] -> SshHost -> String -> Maybe String -> Handler Html -> Handler Html
+sshSetup sshinput opts sshhost cmd input a = do
+	(transcript, ok) <- liftAssistant $ sshAuthTranscript sshinput opts sshhost cmd input
+	if ok
+		then do
+			liftAssistant $ expireCachedCred $ getLogin sshinput
+			a
+		else sshErr sshinput transcript
+
+sshErr :: SshInput -> String -> Handler Html
+sshErr sshinput msg
+	| inputAuthMethod sshinput == CachedPassword =
+		ifM (liftAssistant $ isNothing <$> getCachedCred (getLogin sshinput))
+			( sshConfigurator $
+				$(widgetFile "configurators/ssh/expiredpassword")
+			, showerr
+			)
+	| otherwise = showerr
+  where
+	showerr = sshConfigurator $
+		$(widgetFile "configurators/ssh/error")
+
+{- Runs a ssh command, returning a transcript of its output.
+ -
+ - Depending on the SshInput, avoids using a password, or uses a
+ - cached password. ssh is coaxed to use git-annex as SSH_ASKPASS
+ - to get the password.
+ -}
+sshAuthTranscript :: SshInput -> [String] -> SshHost -> String -> (Maybe String) -> Assistant (String, Bool)
+sshAuthTranscript sshinput opts sshhost cmd input = case inputAuthMethod sshinput of
+	ExistingSshKey -> liftIO $ go [passwordprompts 0] Nothing
+	CachedPassword -> setupAskPass
+	Password -> do
+		cacheCred (login, geti inputPassword) (Seconds $ 60 * 10)
+		setupAskPass
+  where
+	login = getLogin sshinput
+	geti f = maybe "" T.unpack (f sshinput)
+
+	go extraopts environ = processTranscript' 
+		(askPass environ (proc "ssh" (extraopts ++ opts ++ [fromSshHost sshhost, cmd])))
+		-- Always provide stdin, even when empty.
+		(Just (fromMaybe "" input))
+
+ 	{- ssh will only use SSH_ASKPASS when DISPLAY is set and there
+	 - is no controlling terminal. -}
+	askPass environ p = p
+		{ env = environ
+		, detach_console = True
+		, new_session = True
+		}
+
+	setupAskPass = do
+		program <- liftIO programPath
+		v <- getCachedCred login
+		liftIO $ case v of
+			Nothing -> go [passwordprompts 0] Nothing
+			Just pass -> withTmpFile "ssh" $ \passfile h -> do
+				hClose h
+				writeFileProtected (toRawFilePath passfile) pass
+				environ <- getEnvironment
+				let environ' = addEntries
+					[ ("SSH_ASKPASS", program)
+					, (sshAskPassEnv, passfile)
+					, ("DISPLAY", ":0")
+					] environ
+				go [passwordprompts 1] (Just environ')
+	
+	passwordprompts :: Int -> String
+	passwordprompts = sshOpt "NumberOfPasswordPrompts" . show
+
+getLogin :: SshInput -> Login
+getLogin sshinput = geti inputUsername ++ "@" ++ geti inputHostname
+  where
+	geti f = maybe "" T.unpack (f sshinput)
+
+{- The UUID will be NoUUID when the repository does not already exist,
+ - or was not a git-annex repository before. -}
+getConfirmSshR :: SshData -> UUID -> Handler Html
+getConfirmSshR sshdata u
+	| u == NoUUID = handlenew
+	| otherwise = handleexisting =<< (M.lookup u <$> liftAnnex uuidDescMap)
+  where
+	handlenew = sshConfigurator $ do
+		cmd <- liftAnnex $ gpgCmd <$> Annex.getGitConfig
+		secretkeys <- sortBy (comparing snd) . M.toList
+			<$> liftIO (secretKeys cmd)
+		$(widgetFile "configurators/ssh/confirm")
+	handleexisting Nothing = sshConfigurator $
+		-- Not a UUID we know, so prompt about combining.
+		$(widgetFile "configurators/ssh/combine")
+	handleexisting (Just _) = prepSsh False sshdata $ \sshdata' -> do
+		m <- liftAnnex remoteConfigMap
+		case fromProposedAccepted <$> (M.lookup typeField =<< M.lookup u m) of
+			Just "gcrypt" -> combineExistingGCrypt sshdata' u
+			_ -> makeSshRepo ExistingRepo sshdata'
+
+{- The user has confirmed they want to combine with a ssh repository,
+ - which is not known to us. So it might be using gcrypt. -}
+getCombineSshR :: SshData -> Handler Html
+getCombineSshR sshdata = prepSsh False sshdata $ \sshdata' ->
+	sshConfigurator $
+		checkExistingGCrypt sshdata' $
+			void $ liftH $ makeSshRepo ExistingRepo sshdata'
+
+getRetrySshR :: SshData -> Handler ()
+getRetrySshR sshdata = do
+	s <- liftAssistant $ testServer $ mkSshInput sshdata
+	redirect $ either (const $ ConfirmSshR sshdata NoUUID) (uncurry ConfirmSshR) s
+
+{- Making a new git repository. -}
+getMakeSshGitR :: SshData -> Handler Html
+getMakeSshGitR sshdata = prepSsh True sshdata (makeSshRepo NewRepo)
+
+getMakeSshRsyncR :: SshData -> Handler Html
+getMakeSshRsyncR sshdata = prepSsh False (rsyncOnly sshdata) (makeSshRepo NewRepo)
+
+rsyncOnly :: SshData -> SshData
+rsyncOnly sshdata = sshdata { sshCapabilities = [RsyncCapable] }
+
+getMakeSshGCryptR :: SshData -> RepoKey -> Handler Html
+getMakeSshGCryptR sshdata NoRepoKey = whenGcryptInstalled $
+	withNewSecretKey $ getMakeSshGCryptR sshdata . RepoKey
+getMakeSshGCryptR sshdata (RepoKey keyid) = whenGcryptInstalled $
+	prepSsh False sshdata $ makeGCryptRepo NewRepo keyid
+	
+{- Detect if the user entered a location with an existing, known
+ - gcrypt repository, and enable it. Otherwise, runs the action. -}
+checkExistingGCrypt :: SshData -> Widget -> Widget
+checkExistingGCrypt sshdata nope = checkGCryptRepoEncryption repourl nope nope $ do
+	mu <- liftAnnex $ probeGCryptRemoteUUID repourl
+	case mu of
+		Just u -> void $ liftH $
+			combineExistingGCrypt sshdata u
+		Nothing -> giveup "The location contains a gcrypt repository that is not a git-annex special remote. This is not supported."
+  where
+	repourl = genSshUrl sshdata
+
+{- Enables an existing gcrypt special remote. -}
+enableGCrypt :: SshData -> RemoteName -> Handler Html
+enableGCrypt sshdata reponame = setupRemote postsetup Nothing Nothing mk
+  where
+	mk = enableSpecialRemote reponame GCrypt.remote Nothing $
+		M.fromList [(Proposed "gitrepo", Proposed (genSshUrl sshdata))]
+	postsetup _ = redirect DashboardR
+
+{- Combining with a gcrypt repository that may not be
+ - known in remote.log, so probe the gcrypt repo. -}
+combineExistingGCrypt :: SshData -> UUID -> Handler Html
+combineExistingGCrypt sshdata u = do
+	reponame <- liftAnnex $ getGCryptRemoteName u repourl
+	enableGCrypt sshdata reponame
+  where
+	repourl = genSshUrl sshdata
+
+{- Sets up remote repository for ssh, or directory for rsync. -}
+prepSsh :: Bool -> SshData -> (SshData -> Handler Html) -> Handler Html
+prepSsh needsinit sshdata a
+	| needsPubKey sshdata = do
+		(sshdata', keypair) <- liftIO $ setupSshKeyPair sshdata
+		prepSsh' needsinit sshdata sshdata' (Just keypair) a
+	| sshPort sshdata /= 22 = do
+		sshdata' <- liftIO $ setSshConfig sshdata []
+		prepSsh' needsinit sshdata sshdata' Nothing a
+	| otherwise = prepSsh' needsinit sshdata sshdata Nothing a
+
+prepSsh' :: Bool -> SshData -> SshData -> Maybe SshKeyPair -> (SshData -> Handler Html) -> Handler Html
+prepSsh' needsinit origsshdata sshdata keypair a
+	| hasCapability sshdata PushCapable = do
+		{- To ensure the repository is initialized, try to push the
+		 - git-annex branch to it. Then git-annex-shell will see
+		 - the branch and auto-initialize. -}
+		when needsinit $ do
+			void $ liftAnnex $ inRepo $ Git.Command.runBool
+				[ Param "push"
+				, Param (genSshUrl sshdata)
+				, Param (fromRef Annex.Branch.name)
+				]
+		a sshdata
+	| otherwise = sshSetup (mkSshInput origsshdata)
+		[ "-p", show (sshPort origsshdata)
+		]
+		(genSshHost (sshHostName origsshdata) (sshUserName origsshdata))
+		remoteCommand
+		Nothing (a sshdata)
+  where
+	remotedir = T.unpack $ sshDirectory sshdata
+	remoteCommand = shellWrap $ intercalate "&&" $ catMaybes
+		[ Just $ "mkdir -p " ++ shellEscape remotedir
+		, Just $ "cd " ++ shellEscape remotedir
+		, if rsynconly then Nothing else Just $ unwords
+			[ "if [ ! -d .git ]; then"
+			, wrapCommand "git init --bare --shared"
+		, "&&"
+			, wrapCommand "git config receive.denyNonFastforwards"
+			, ";fi"
+			]
+		, if needsinit then Just (wrapCommand "git annex init") else Nothing
+		, if needsPubKey origsshdata
+			then addAuthorizedKeysCommand (hasCapability origsshdata GitAnnexShellCapable) remotedir . sshPubKey <$> keypair
+			else Nothing
+		]
+	rsynconly = onlyCapability origsshdata RsyncCapable
+
+makeSshRepo :: RepoStatus -> SshData -> Handler Html
+makeSshRepo rs sshdata
+	| onlyCapability sshdata RsyncCapable = setupCloudRemote TransferGroup Nothing mk
+	| otherwise = makeSshRepoConnection rs mk setup
+  where
+	mk = makeSshRemote sshdata
+	-- Record the location of the ssh remote in the remote log, so it
+	-- can easily be enabled elsewhere using the webapp.
+	setup r = do
+		m <- remoteConfigMap
+		let c = fromMaybe M.empty (M.lookup (Remote.uuid r) m)
+		let c' = M.insert (Proposed "location") (Proposed (genSshUrl sshdata)) $
+			M.insert typeField (Proposed "git") $
+			case fromProposedAccepted <$> M.lookup nameField c of
+				Just _ -> c
+				Nothing -> M.insert nameField (Proposed (Remote.name r)) c
+		configSet (Remote.uuid r) c'
+
+makeSshRepoConnection :: RepoStatus -> Annex RemoteName -> (Remote -> Annex ()) -> Handler Html
+makeSshRepoConnection rs mk setup = setupRemote postsetup mgroup Nothing mk
+  where
+	mgroup = case rs of
+		NewRepo -> Just TransferGroup
+		ExistingRepo -> Nothing
+	postsetup r = do
+		liftAssistant $ sendRemoteControl RELOAD
+		liftAnnex $ setup r
+		case rs of
+			NewRepo -> redirect $ EditNewRepositoryR (Remote.uuid r)
+			ExistingRepo -> redirect DashboardR
+
+makeGCryptRepo :: RepoStatus -> KeyId -> SshData -> Handler Html
+makeGCryptRepo rs keyid sshdata = makeSshRepoConnection rs mk (const noop)
+  where
+	mk = makeGCryptRemote (sshRepoName sshdata) (genSshUrl sshdata) keyid
+
+getAddRsyncNetR :: Handler Html
+getAddRsyncNetR = postAddRsyncNetR
+postAddRsyncNetR :: Handler Html
+postAddRsyncNetR = do
+	((result, form), enctype) <- runFormPostNoToken $
+		renderBootstrap3 bootstrapFormLayout $ sshInputAForm hostnamefield $
+			SshInput Nothing Nothing Password Nothing Nothing 22
+	let showform status = inpage $
+		$(widgetFile "configurators/rsync.net/add")
+	case result of
+		FormSuccess sshinput
+			| isRsyncNet (inputHostname sshinput) ->
+				go sshinput
+			| otherwise ->
+				showform $ UnusableServer
+					"That is not a rsync.net host name."
+		_ -> showform UntestedServer
+  where
+	inpage = page "Add a Rsync.net repository" (Just Configuration)
+	hostnamefield = textField `withExpandableNote` ("Help", help)
+	help = [whamlet|
+<div>
+  When you sign up for a Rsync.net account, you should receive an #
+  email from them with the host name and user name to put here.
+<div>
+  The host name will be something like "usw-s001.rsync.net", and the #
+  user name something like "7491"
+|]
+	go sshinput = do
+		let reponame = genSshRepoName "rsync.net" 
+			(maybe "" T.unpack $ inputDirectory sshinput)
+		
+		prepRsyncNet sshinput reponame $ \sshdata -> inpage $ 
+			checkExistingGCrypt sshdata $ do
+				cmd <- liftAnnex $ gpgCmd <$> Annex.getGitConfig
+				secretkeys <- sortBy (comparing snd) . M.toList
+					<$> liftIO (secretKeys cmd)
+				$(widgetFile "configurators/rsync.net/encrypt")
+
+getMakeRsyncNetSharedR :: SshData -> Handler Html
+getMakeRsyncNetSharedR = makeSshRepo NewRepo . rsyncOnly
+
+{- Make a new gcrypt special remote on rsync.net. -}
+getMakeRsyncNetGCryptR :: SshData -> RepoKey -> Handler Html
+getMakeRsyncNetGCryptR sshdata NoRepoKey = whenGcryptInstalled $
+	withNewSecretKey $ getMakeRsyncNetGCryptR sshdata . RepoKey
+getMakeRsyncNetGCryptR sshdata (RepoKey keyid) = whenGcryptInstalled $
+	sshSetup (mkSshInput sshdata) [] sshhost gitinit Nothing $
+		makeGCryptRepo NewRepo keyid sshdata
+  where
+	sshhost = genSshHost (sshHostName sshdata) (sshUserName sshdata)
+	gitinit = "git init --bare " ++ T.unpack (sshDirectory sshdata)
+
+enableRsyncNet :: SshInput -> String -> Handler Html
+enableRsyncNet sshinput reponame = 
+	prepRsyncNet sshinput reponame $ makeSshRepo ExistingRepo . rsyncOnly
+
+enableRsyncNetGCrypt :: SshInput -> RemoteName -> Handler Html
+enableRsyncNetGCrypt sshinput reponame = 
+	prepRsyncNet sshinput reponame $ \sshdata -> whenGcryptInstalled $
+		checkGCryptRepoEncryption (genSshUrl sshdata) notencrypted notinstalled $
+			enableGCrypt sshdata reponame
+  where
+	notencrypted = giveup "Unexpectedly found a non-encrypted git repository, instead of the expected encrypted git repository."
+	notinstalled = error "internal"
+
+{- Prepares rsync.net ssh key and creates the directory that will be 
+ - used on rsync.net. If successful, runs an action with its SshData.
+ -
+ - To append the ssh key to rsync.net's authorized_keys, their
+ - documentation recommends a dd method, where the line is fed
+ - in to ssh over stdin.
+ -}
+prepRsyncNet :: SshInput -> String -> (SshData -> Handler Html) -> Handler Html
+prepRsyncNet sshinput reponame a = do
+	knownhost <- liftIO $ maybe (return False) knownHost (inputHostname sshinput)
+	(sshdata, keypair) <- liftIO $ setupSshKeyPair $
+		(mkSshData sshinput)
+			{ sshRepoName = reponame 
+			, needsPubKey = True
+			, sshCapabilities = [RsyncCapable]
+			}
+	let sshhost = genSshHost (sshHostName sshdata) (sshUserName sshdata)
+	let torsyncnet
+		| knownhost = []
+		| otherwise = [sshOpt "StrictHostKeyChecking" "no"]
+	{- I'd prefer to separate commands with && , but
+	 - rsync.net's shell does not support that. -}
+	let remotecommand = intercalate ";"
+		[ "mkdir -p .ssh"
+		, "touch .ssh/authorized_keys"
+		, "dd of=.ssh/authorized_keys oflag=append conv=notrunc"
+		, "mkdir -p " ++ T.unpack (sshDirectory sshdata)
+		]
+	sshSetup sshinput torsyncnet sshhost remotecommand
+		(Just $ sshPubKey keypair) (a sshdata)
+
+isRsyncNet :: Maybe Text -> Bool
+isRsyncNet Nothing = False
+isRsyncNet (Just host) = ".rsync.net" `T.isSuffixOf` T.toLower host
diff --git a/Assistant/WebApp/Configurators/Unused.hs b/Assistant/WebApp/Configurators/Unused.hs
new file mode 100644
index 0000000000..11f60e3127
--- /dev/null
+++ b/Assistant/WebApp/Configurators/Unused.hs
@@ -0,0 +1,80 @@
+{- git-annex assistant unused file preferences
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Configurators.Unused where
+
+import Assistant.WebApp.Common
+import qualified Annex
+import Utility.HumanTime
+import Assistant.Unused
+import Config
+import Git.Config
+import Logs.Unused
+import Utility.Tense
+
+import qualified Text.Hamlet as Hamlet
+
+data UnusedForm = UnusedForm
+	{ enableExpire :: Bool
+	, expireWhen :: Integer
+	}
+
+unusedForm :: UnusedForm -> Hamlet.Html -> MkMForm UnusedForm
+unusedForm d msg = do
+	(enableRes, enableView) <- mreq (selectFieldList enabledisable) (bfs "")
+		(Just $ enableExpire d)
+	(whenRes, whenView) <- mreq intField (bfs "")
+		(Just $ expireWhen d)
+	let form = do
+		webAppFormAuthToken
+		$(widgetFile "configurators/unused/form")
+	return (UnusedForm <$> enableRes <*> whenRes, form)
+  where
+	enabledisable :: [(Text, Bool)]
+	enabledisable = [("Disable expiry", False), ("Enable expiry", True)]
+
+getConfigUnusedR :: Handler Html
+getConfigUnusedR = postConfigUnusedR
+postConfigUnusedR :: Handler Html
+postConfigUnusedR = page "Unused files" (Just Configuration) $ do
+	current <- liftAnnex getUnused
+	((res, form), enctype) <- liftH $ runFormPostNoToken $ unusedForm current
+	case res of
+		FormSuccess new -> liftH $ do
+			liftAnnex $ storeUnused new
+			redirect ConfigurationR
+		_ -> do
+			munuseddesc <- liftAssistant describeUnused
+			ts <- liftAnnex $ dateUnusedLog ""
+			mlastchecked <- case ts of
+				Nothing -> pure Nothing
+				Just t -> Just <$> liftIO (durationSince t)
+			$(widgetFile "configurators/unused")
+
+getUnused :: Annex UnusedForm
+getUnused = convert . annexExpireUnused <$> Annex.getGitConfig
+  where
+	convert Nothing = noexpire
+	convert (Just Nothing) = noexpire
+	convert (Just (Just n)) = UnusedForm True $ durationToDays n
+
+	-- The 7 is so that, if they enable expiry, they have to change
+	-- it to get faster than  a week.
+	noexpire = UnusedForm False 7
+
+storeUnused :: UnusedForm -> Annex ()
+storeUnused f = setConfig (annexConfig "expireunused") $
+	if not (enableExpire f) || expireWhen f < 0
+		then boolConfig False
+		else fromDuration $ daysToDuration $ expireWhen f
+
+getCleanupUnusedR :: Handler Html
+getCleanupUnusedR = do
+	liftAssistant $ expireUnused Nothing
+	redirect ConfigUnusedR
diff --git a/Assistant/WebApp/Configurators/Upgrade.hs b/Assistant/WebApp/Configurators/Upgrade.hs
new file mode 100644
index 0000000000..1fa0087129
--- /dev/null
+++ b/Assistant/WebApp/Configurators/Upgrade.hs
@@ -0,0 +1,37 @@
+{- git-annex assistant webapp upgrade UI
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Configurators.Upgrade where
+
+import Assistant.WebApp.Common
+import Types.Distribution
+import Assistant.Upgrade
+import Assistant.Restart
+import Config
+
+{- Start the upgrade process. -}
+getConfigStartUpgradeR :: GitAnnexDistribution -> Handler Html
+getConfigStartUpgradeR d = do
+	liftAssistant $ startDistributionDownload d
+	redirect DashboardR
+
+{- Finish upgrade by starting the new assistant in the same repository this
+ - one is running in, and redirecting to it. -}
+getConfigFinishUpgradeR :: Handler Html
+getConfigFinishUpgradeR = do
+	liftAssistant prepUpgrade
+	url <- liftAssistant runRestart
+	liftAssistant $ postUpgrade url
+	redirect url
+
+getConfigEnableAutomaticUpgradeR :: Handler Html
+getConfigEnableAutomaticUpgradeR = do
+	liftAnnex $ setConfig (annexConfig "autoupgrade")
+		(fromAutoUpgrade AutoUpgrade)
+	redirect DashboardR
diff --git a/Assistant/WebApp/Configurators/WebDAV.hs b/Assistant/WebApp/Configurators/WebDAV.hs
new file mode 100644
index 0000000000..473740fa74
--- /dev/null
+++ b/Assistant/WebApp/Configurators/WebDAV.hs
@@ -0,0 +1,100 @@
+{- git-annex assistant webapp configurators for WebDAV remotes
+ -
+ - Copyright 2012, 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Configurators.WebDAV where
+
+import Assistant.WebApp.Common
+import Creds
+import qualified Remote.WebDAV as WebDAV
+import Assistant.WebApp.MakeRemote
+import qualified Remote
+import Types.Remote (RemoteConfig, config)
+import Types.StandardGroups
+import Logs.Remote
+import Git.Types (RemoteName)
+import Assistant.Gpg
+import Types.GitConfig
+import Annex.SpecialRemote.Config
+import Types.ProposedAccepted
+import Utility.Url.Parse
+
+import qualified Data.Map as M
+import qualified Data.Text as T
+import Network.URI
+
+webDAVConfigurator :: Widget -> Handler Html
+webDAVConfigurator = page "Add a WebDAV repository" (Just Configuration)
+
+data WebDAVInput = WebDAVInput
+	{ user :: Text
+	, password :: Text
+	, embedCreds :: Bool
+	, directory :: Text
+	, enableEncryption :: EnableEncryption
+	}
+
+toCredPair :: WebDAVInput -> CredPair
+toCredPair input = (T.unpack $ user input, T.unpack $ password input)
+
+webDAVCredsAForm :: Maybe CredPair -> MkAForm WebDAVInput
+webDAVCredsAForm defcreds = WebDAVInput
+	<$> areq textField (bfs "Username or Email") (T.pack . fst <$> defcreds)
+	<*> areq passwordField (bfs "Password") (T.pack . snd <$> defcreds)
+	<*> pure False
+	<*> pure T.empty
+	<*> pure NoEncryption -- not used!
+
+getEnableWebDAVR :: UUID -> Handler Html
+getEnableWebDAVR = postEnableWebDAVR
+postEnableWebDAVR :: UUID -> Handler Html
+postEnableWebDAVR uuid = do
+	m <- liftAnnex remoteConfigMap
+	let c = fromJust $ M.lookup uuid m
+	let name = fromJust $ lookupName c
+	let url = fromProposedAccepted $ fromJust $ M.lookup (Accepted "url") c
+	mcreds <- liftAnnex $ do
+		dummycfg <- liftIO dummyRemoteGitConfig
+		pc <- parsedRemoteConfig WebDAV.remote c
+		getRemoteCredPairFor "webdav" pc dummycfg (WebDAV.davCreds uuid)
+	case mcreds of
+		Just creds -> webDAVConfigurator $ liftH $
+			makeWebDavRemote enableSpecialRemote name creds M.empty
+		Nothing -> webDAVConfigurator $ showform name url
+  where
+	showform name url = do
+		defcreds <- liftAnnex $ 
+			maybe (pure Nothing) previouslyUsedWebDAVCreds $
+				urlHost url
+		((result, form), enctype) <- liftH $
+			runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $
+				webDAVCredsAForm defcreds
+		case result of
+			FormSuccess input -> liftH $
+				makeWebDavRemote enableSpecialRemote name (toCredPair input) M.empty
+			_ -> do
+				description <- liftAnnex $
+					T.pack <$> Remote.prettyUUID uuid
+				$(widgetFile "configurators/enablewebdav")
+
+makeWebDavRemote :: SpecialRemoteMaker -> RemoteName -> CredPair -> RemoteConfig -> Handler ()
+makeWebDavRemote maker name creds c = 
+	setupCloudRemote TransferGroup Nothing $
+		maker name WebDAV.remote (Just creds) c
+
+{- Only returns creds previously used for the same hostname. -}
+previouslyUsedWebDAVCreds :: String -> Annex (Maybe CredPair)
+previouslyUsedWebDAVCreds hostname =
+	previouslyUsedCredPair WebDAV.davCreds WebDAV.remote samehost
+  where
+	samehost r = case urlHost =<< WebDAV.configUrl (config r) of
+		Nothing -> False
+		Just h -> h == hostname
+
+urlHost :: String -> Maybe String
+urlHost url = uriRegName <$> (uriAuthority =<< parseURIPortable url)
diff --git a/Assistant/WebApp/Control.hs b/Assistant/WebApp/Control.hs
new file mode 100644
index 0000000000..5d60731bfe
--- /dev/null
+++ b/Assistant/WebApp/Control.hs
@@ -0,0 +1,78 @@
+{- git-annex assistant webapp control
+ -
+ - Copyright 2012, 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeFamilies, QuasiQuotes, MultiParamTypeClasses, TemplateHaskell, OverloadedStrings, RankNTypes #-}
+
+module Assistant.WebApp.Control where
+
+import Assistant.WebApp.Common
+import Assistant.DaemonStatus
+import Assistant.Alert
+import Assistant.TransferSlots
+import Assistant.Restart
+import Utility.LogFile
+import Utility.NotificationBroadcaster
+
+import Control.Concurrent
+import qualified Data.Map as M
+import qualified Data.Text as T
+
+getShutdownR :: Handler Html
+getShutdownR = page "Shutdown" Nothing $
+	$(widgetFile "control/shutdown")
+
+getShutdownConfirmedR :: Handler Html
+getShutdownConfirmedR = do
+	liftAssistant $ do
+		{- Remove all alerts for currently running activities. -}
+		updateAlertMap $ M.filter $ \a -> alertClass a /= Activity
+		void $ addAlert shutdownAlert
+		{- Stop transfers the assistant is running,
+		 - otherwise they would continue past shutdown.
+		 - Pausing transfers prevents more being started up (and stops
+		 - the transfer processes). -}
+		ts <- M.keys . currentTransfers <$> getDaemonStatus
+		mapM_ pauseTransfer ts
+	webapp <- getYesod
+	let url = T.unpack $ yesodRender webapp (T.pack "") NotRunningR []
+	{- Signal any other web browsers. -}
+	liftAssistant $ do
+		modifyDaemonStatus_ $ \status -> status { globalRedirUrl = Just url }
+		liftIO . sendNotification . globalRedirNotifier =<< getDaemonStatus
+	{- Wait 2 seconds before shutting down, to give the web
+	 - page time to load in the browser. -}
+	void $ liftIO $ forkIO $ do
+		threadDelay 2000000
+		terminateSelf
+	redirect NotRunningR
+
+{- Use a custom page to avoid putting long polling elements on it that will 
+ - fail and cause thet web browser to show an error once the webapp is
+ - truly stopped. -}
+getNotRunningR :: Handler Html
+getNotRunningR = customPage' False Nothing $
+	$(widgetFile "control/notrunning")
+
+getRestartR :: Handler Html
+getRestartR = do
+	liftAssistant prepRestart
+	url <- liftAssistant runRestart
+	liftAssistant $ postRestart url
+	redirect url
+
+getRestartThreadR :: ThreadName -> Handler ()
+getRestartThreadR name = do
+	m <- liftAssistant $ startedThreads <$> getDaemonStatus
+	liftIO $ maybe noop snd $ M.lookup name m
+	redirectBack
+
+getLogR :: Handler Html
+getLogR = page "Logs" Nothing $ do
+	logfile <- liftAnnex $ fromRepo gitAnnexDaemonLogFile
+	logs <- liftIO $ listLogs (fromRawFilePath logfile)
+	logcontent <- liftIO $ concat <$> mapM readFile logs
+	$(widgetFile "control/log")
diff --git a/Assistant/WebApp/DashBoard.hs b/Assistant/WebApp/DashBoard.hs
new file mode 100644
index 0000000000..5bbcee3c92
--- /dev/null
+++ b/Assistant/WebApp/DashBoard.hs
@@ -0,0 +1,179 @@
+{- git-annex assistant webapp dashboard
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP, TypeFamilies, QuasiQuotes, MultiParamTypeClasses, TemplateHaskell, OverloadedStrings, RankNTypes #-}
+
+module Assistant.WebApp.DashBoard where
+
+import Assistant.WebApp.Common
+import Assistant.WebApp.RepoList
+import Assistant.WebApp.Notifications
+import Assistant.TransferQueue
+import Assistant.TransferSlots
+import Assistant.DaemonStatus
+import Utility.NotificationBroadcaster
+import Types.Transfer
+import Logs.Transfer
+import Utility.Percentage
+import Utility.DataUnits
+import qualified Remote
+import qualified Git
+
+import qualified Text.Hamlet as Hamlet
+import qualified Data.Map as M
+import Control.Concurrent
+
+{- A display of currently running and queued transfers. -}
+transfersDisplay :: Widget
+transfersDisplay = do
+	current <- liftAssistant $ M.toList <$> getCurrentTransfers
+	queued <- take 10 <$> liftAssistant getTransferQueue
+	autoUpdate ident NotifierTransfersR (10 :: Int) (10 :: Int)
+	let transfers = simplifyTransfers $ current ++ queued
+	let transfersrunning = not $ null transfers
+	scanrunning <- if transfersrunning
+		then return False
+		else liftAssistant $ transferScanRunning <$> getDaemonStatus
+	$(widgetFile "dashboard/transfers")
+  where
+	ident = "transfers"
+	isrunning info = not $
+		transferPaused info || isNothing (startedTime info)
+	desc transfer info = case associatedFile info of
+		AssociatedFile Nothing -> serializeKey $ transferKey transfer
+		AssociatedFile (Just af) -> fromRawFilePath af
+
+{- Simplifies a list of transfers, avoiding display of redundant
+ - equivalent transfers. -}
+simplifyTransfers :: [(Transfer, TransferInfo)] -> [(Transfer, TransferInfo)]
+simplifyTransfers [] = []
+simplifyTransfers (x:[]) = [x]
+simplifyTransfers (v@(t1, _):r@((t2, _):l))
+	| equivilantTransfer t1 t2 = simplifyTransfers (v:l)
+	| otherwise = v : simplifyTransfers r
+
+{- Called by client to get a display of currently in process transfers.
+ -
+ - Returns a div, which will be inserted into the calling page.
+ -
+ - Note that the head of the widget is not included, only its
+ - body is. To get the widget head content, the widget is also 
+ - inserted onto the getDashboardR page.
+ -}
+getTransfersR :: NotificationId -> Handler Html
+getTransfersR nid = do
+	waitNotifier getTransferBroadcaster nid
+
+	p <- widgetToPageContent transfersDisplay
+	withUrlRenderer $ [hamlet|^{pageBody p}|]
+
+{- The main dashboard. -}
+dashboard :: Bool -> Widget
+dashboard warnNoScript = do
+	let repolist = repoListDisplay $
+		mainRepoSelector { nudgeAddMore = True }
+	let transferlist = transfersDisplay
+	$(widgetFile "dashboard/main")
+
+getDashboardR :: Handler Html
+getDashboardR = ifM inFirstRun
+	( redirect ConfigurationR
+	, page "" (Just DashBoard) $ dashboard True
+	)
+
+{- Used to test if the webapp is running. -}
+headDashboardR :: Handler ()
+headDashboardR = noop
+
+{- Same as DashboardR, except no autorefresh at all (and no noscript warning). -}
+getNoScriptR :: Handler Html
+getNoScriptR = page "" (Just DashBoard) $ dashboard False
+
+{- Same as DashboardR, except with autorefreshing via meta refresh. -}
+getNoScriptAutoR :: Handler Html
+getNoScriptAutoR = page "" (Just DashBoard) $ do
+	let delayseconds = 3 :: Int
+	let this = NoScriptAutoR
+	toWidgetHead $(Hamlet.hamletFile $ hamletTemplate "dashboard/metarefresh")
+	dashboard False
+
+{- The javascript code does a post. -}
+postFileBrowserR :: Handler ()
+postFileBrowserR = void openFileBrowser
+
+{- Used by non-javascript browsers, where clicking on the link actually
+ - opens this page, so we redirect back to the referrer. -}
+getFileBrowserR :: Handler ()
+getFileBrowserR = whenM openFileBrowser redirectBack
+
+{- Opens the system file browser on the repo, or, as a fallback,
+ - goes to a file:// url. Returns True if it's ok to redirect away
+ - from the page (ie, the system file browser was opened). 
+ -
+ - Note that the command is opened using a different thread, to avoid
+ - blocking the response to the browser on it. -}
+openFileBrowser :: Handler Bool
+openFileBrowser = do
+	path <- fromRawFilePath 
+		<$> (liftIO . absPath =<< liftAnnex (fromRepo Git.repoPath))
+#ifdef darwin_HOST_OS
+	let cmd = "open"
+	let p = proc cmd [path]
+#else
+#ifdef mingw32_HOST_OS
+	{- Changing to the directory and then opening . works around
+	 - spaces in directory name, etc. -}
+	let cmd = "cmd"
+	let p = (proc cmd ["/c start ."]) { cwd = Just path }
+#else
+	let cmd = "xdg-open"
+	let p = proc cmd [path]
+#endif
+#endif
+	ifM (liftIO $ inSearchPath cmd)
+		( do
+			let run = void $ liftIO $ forkIO $ do
+				withCreateProcess p $ \_ _ _ pid -> void $
+					waitForProcess pid
+			run
+#ifdef mingw32_HOST_OS
+			{- On windows, if the file browser is not
+			 - already open, it comes up below the
+			 - web browser when started. 
+			 -
+			 - Running it a second time brings it
+			 - to the foreground.
+			 -
+			 - Seems to need a delay long enough for the file
+			 - browser to be open in order to work. Here 1
+			 - second. -}
+			liftIO $ threadDelay 1000000
+			run
+#endif
+			return True
+		, do
+			void $ redirect $ "file://" ++ path
+			return False
+		)
+
+{- Transfer controls. The GET is done in noscript mode and redirects back
+ - to the referring page. The POST is called by javascript. -}
+getPauseTransferR :: Transfer -> Handler ()
+getPauseTransferR = noscript postPauseTransferR
+postPauseTransferR :: Transfer -> Handler ()
+postPauseTransferR = liftAssistant . pauseTransfer
+getStartTransferR :: Transfer -> Handler ()
+getStartTransferR = noscript postStartTransferR
+postStartTransferR :: Transfer -> Handler ()
+postStartTransferR = liftAssistant . startTransfer
+getCancelTransferR :: Transfer -> Handler ()
+getCancelTransferR = noscript postCancelTransferR
+postCancelTransferR :: Transfer -> Handler ()
+postCancelTransferR = liftAssistant . cancelTransfer False
+
+noscript :: (Transfer -> Handler ()) -> Transfer -> Handler ()
+noscript a t = a t >> redirectBack
diff --git a/Assistant/WebApp/Documentation.hs b/Assistant/WebApp/Documentation.hs
new file mode 100644
index 0000000000..63c4f7cb98
--- /dev/null
+++ b/Assistant/WebApp/Documentation.hs
@@ -0,0 +1,42 @@
+{- git-annex assistant webapp documentation
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Documentation where
+
+import Assistant.WebApp.Common
+import Assistant.Install (standaloneAppBase)
+import BuildInfo (packageversion)
+import BuildFlags
+
+{- The full license info may be included in a file on disk that can
+ - be read in and displayed. -}
+licenseFile :: IO (Maybe FilePath)
+licenseFile = do
+	base <- standaloneAppBase
+	return $ (</> "LICENSE") <$> base
+
+getAboutR :: Handler Html
+getAboutR = page "About git-annex" (Just About) $ do
+	builtinlicense <- isJust <$> liftIO licenseFile
+	$(widgetFile "documentation/about")
+
+getLicenseR :: Handler Html
+getLicenseR = do
+	v <- liftIO licenseFile
+	case v of
+		Nothing -> redirect AboutR
+		Just f -> customPage (Just About) $ do
+			-- no sidebar, just pages of legalese..
+			setTitle "License"
+			license <- liftIO $ readFile f
+			$(widgetFile "documentation/license")
+
+getRepoGroupR :: Handler Html
+getRepoGroupR = page "About repository groups" (Just About) $
+	$(widgetFile "documentation/repogroup")
diff --git a/Assistant/WebApp/Form.hs b/Assistant/WebApp/Form.hs
new file mode 100644
index 0000000000..bf33ff7dee
--- /dev/null
+++ b/Assistant/WebApp/Form.hs
@@ -0,0 +1,94 @@
+{- git-annex assistant webapp form utilities
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE FlexibleContexts, TypeFamilies, QuasiQuotes #-}
+{-# LANGUAGE MultiParamTypeClasses, TemplateHaskell #-}
+{-# LANGUAGE OverloadedStrings, RankNTypes #-}
+
+module Assistant.WebApp.Form where
+
+import Assistant.WebApp.Types
+import Assistant.Gpg
+
+import Yesod hiding (textField, passwordField)
+import Yesod.Form.Fields as F
+import Yesod.Form.Bootstrap3 as Y hiding (bfs)
+import Data.Text (Text)
+
+{- Yesod's textField sets the required attribute for required fields.
+ - We don't want this, because many of the forms used in this webapp 
+ - display a modal dialog when submitted, which interacts badly with
+ - required field handling by the browser.
+ -
+ - Required fields are still checked by Yesod.
+ -}
+textField :: MkField Text
+textField = F.textField
+	{ fieldView = \theId name attrs val _isReq -> [whamlet|
+<input id="#{theId}" name="#{name}" *{attrs} type="text" value="#{either id id val}">
+|]
+	}
+
+readonlyTextField :: MkField Text
+readonlyTextField = F.textField
+	{ fieldView = \theId name attrs val _isReq -> [whamlet|
+<input id="#{theId}" name="#{name}" *{attrs} type="text" value="#{either id id val}" readonly="true">
+|]
+	}
+
+{- Also without required attribute. -}
+passwordField :: MkField Text
+passwordField = F.passwordField
+	{ fieldView = \theId name attrs val _isReq -> toWidget [hamlet|
+<input id="#{theId}" name="#{name}" *{attrs} type="password" value="#{either id id val}">
+|]
+	}
+
+{- Makes a note widget be displayed after a field. -}
+withNote :: (ToWidget (HandlerSite m) a) => Field m v -> a -> Field m v
+withNote field note = field { fieldView = newview }
+  where
+	newview theId name attrs val isReq = 
+		let fieldwidget = (fieldView field) theId name attrs val isReq
+		in [whamlet|^{fieldwidget}&nbsp;&nbsp;<span>^{note}</span>|]
+
+{- Note that the toggle string must be unique on the form. -}
+withExpandableNote :: (ToWidget (HandlerSite m) w) => Field m v -> (String, w) -> Field m v
+withExpandableNote field (toggle, note) = withNote field $ [whamlet|
+<a .btn .btn-default data-toggle="collapse" data-target="##{ident}">#{toggle}</a>
+<div ##{ident} .collapse>
+  ^{note}
+|]
+  where
+	ident = "toggle_" ++ toggle
+
+{- Adds a check box to an AForm to control encryption. -}
+enableEncryptionField :: (RenderMessage site FormMessage) => AForm (HandlerFor site) EnableEncryption
+enableEncryptionField = areq (selectFieldList choices) (bfs "Encryption") (Just SharedEncryption)
+  where
+	choices :: [(Text, EnableEncryption)]
+	choices =
+		[ ("Encrypt all data", SharedEncryption)
+		, ("Disable encryption", NoEncryption)
+		]
+
+{- Defines the layout used by the Bootstrap3 form helper -}
+bootstrapFormLayout :: BootstrapFormLayout
+bootstrapFormLayout = BootstrapHorizontalForm (ColSm 0) (ColSm 2) (ColSm 0) (ColSm 10)
+
+{- Adds the form-control class used by Bootstrap3 for layout to a field
+ - This is the same as Yesod.Form.Bootstrap3.bfs except it takes just a Text
+ - parameter as I couldn't get the original bfs to compile due to type ambiguities.
+ -}
+bfs :: Text -> FieldSettings master
+bfs msg = FieldSettings
+	{ fsLabel = SomeMessage msg
+	, fsName  = Nothing
+	, fsId    = Nothing
+	, fsAttrs = [("class", "form-control")]
+	, fsTooltip = Nothing
+	}
diff --git a/Assistant/WebApp/Gpg.hs b/Assistant/WebApp/Gpg.hs
new file mode 100644
index 0000000000..79c36a2e0e
--- /dev/null
+++ b/Assistant/WebApp/Gpg.hs
@@ -0,0 +1,114 @@
+{- git-annex webapp gpg stuff
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Gpg where
+
+import Assistant.WebApp.Common
+import Assistant.Gpg
+import Utility.Gpg
+import qualified Annex
+import qualified Git.Command
+import qualified Git.Remote.Remove
+import qualified Git.Construct
+import qualified Annex.Branch
+import qualified Git.GCrypt
+import qualified Remote.GCrypt as GCrypt
+import Git.Types (RemoteName)
+import Assistant.WebApp.MakeRemote
+import Annex.SpecialRemote.Config
+import Logs.Remote
+
+import qualified Data.Map as M
+
+gpgKeyDisplay :: KeyId -> Maybe UserId -> Widget
+gpgKeyDisplay keyid userid = [whamlet|
+  <span title="key id #{keyid}">
+    <span .glyphicon .glyphicon-user>
+    \ 
+    $maybe name <- userid
+      #{name}
+    $nothing
+      key id #{keyid}
+|]
+
+genKeyModal :: Widget
+genKeyModal = $(widgetFile "configurators/genkeymodal")
+
+isGcryptInstalled :: IO Bool
+isGcryptInstalled = inSearchPath "git-remote-gcrypt"
+
+whenGcryptInstalled :: Handler Html -> Handler Html
+whenGcryptInstalled a = ifM (liftIO isGcryptInstalled)
+	( a
+	, page "Need git-remote-gcrypt" (Just Configuration) $
+		$(widgetFile "configurators/needgcrypt")
+	)
+
+withNewSecretKey :: (KeyId -> Handler Html) -> Handler Html
+withNewSecretKey use = do
+	cmd <- liftAnnex $ gpgCmd <$> Annex.getGitConfig
+	userid <- liftIO $ newUserId cmd
+	liftIO $ genSecretKey cmd "" userid
+	results <- M.keys . M.filter (== userid) <$> liftIO (secretKeys cmd)
+	case results of
+		[] -> giveup "Failed to generate gpg key!"
+		(key:_) -> use key
+
+{- Tries to find the name used in remote.log for a gcrypt repository
+ - with a given uuid.
+ -
+ - The gcrypt remote may not be on that is listed in the local remote.log
+ - (or the info may be out of date), so this actually fetches the git-annex
+ - branch from the gcrypt remote and merges it in, and then looks up
+ - the name.
+ -}
+getGCryptRemoteName :: UUID -> String -> Annex RemoteName
+getGCryptRemoteName u repoloc = do
+	tmpremote <- uniqueRemoteName "tmpgcryptremote" 0 <$> Annex.getGitRemotes
+	void $ inRepo $ Git.Command.runBool
+		[ Param "remote"
+		, Param "add"
+		, Param tmpremote
+		, Param $ Git.GCrypt.urlPrefix ++ repoloc
+		]
+	mname <- ifM (inRepo $ Git.Command.runBool [Param "fetch", Param tmpremote])
+		( do
+			void Annex.Branch.forceUpdate
+			(lookupName <=< M.lookup u) <$> remoteConfigMap
+		, return Nothing
+		)
+	void $ inRepo $ Git.Remote.Remove.remove tmpremote
+	maybe missing return mname
+  where
+	missing = giveup $ "Cannot find configuration for the gcrypt remote at " ++ repoloc
+
+{- Checks to see if a repo is encrypted with gcrypt, and runs one action if
+ - it's not an another if it is.
+ -
+ - Since the probing requires gcrypt to be installed, a third action must
+ - be provided to run if it's not installed.
+ -}
+checkGCryptRepoEncryption :: (Monad m, LiftAnnex m) => String -> m a -> m a -> m a -> m a
+checkGCryptRepoEncryption location notencrypted notinstalled encrypted = 
+	ifM (liftAnnex $ liftIO isGcryptInstalled)
+		( dispatch =<< liftAnnex (inRepo $ Git.GCrypt.probeRepo location)
+		, notinstalled
+		)
+  where
+	dispatch Git.GCrypt.Decryptable = encrypted
+	dispatch Git.GCrypt.NotEncrypted = notencrypted
+	dispatch Git.GCrypt.NotDecryptable =
+		giveup "This git repository is encrypted with a GnuPG key that you do not have."
+
+{- Gets the UUID of the gcrypt repo at a location, which may not exist.
+ - Only works if the gcrypt repo was created as a git-annex remote. -}
+probeGCryptRemoteUUID :: String -> Annex (Maybe UUID)
+probeGCryptRemoteUUID repolocation = do
+	r <- inRepo $ Git.Construct.fromRemoteLocation repolocation False
+	GCrypt.getGCryptUUID False r
diff --git a/Assistant/WebApp/MakeRemote.hs b/Assistant/WebApp/MakeRemote.hs
new file mode 100644
index 0000000000..2575febeac
--- /dev/null
+++ b/Assistant/WebApp/MakeRemote.hs
@@ -0,0 +1,46 @@
+{- git-annex assistant webapp making remotes
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.WebApp.MakeRemote (
+	module Assistant.MakeRemote,
+	module Assistant.WebApp.MakeRemote
+) where
+
+import Assistant.Common
+import Assistant.WebApp.Types
+import Assistant.Sync
+import qualified Remote
+import qualified Types.Remote as Remote
+import qualified Config
+import Config.Cost
+import Types.StandardGroups
+import Git.Types (RemoteName)
+import Logs.PreferredContent
+import Assistant.MakeRemote
+
+import Utility.Yesod
+
+{- Runs an action that creates or enables a cloud remote,
+ - and finishes setting it up, then starts syncing with it,
+ - and finishes by displaying the page to edit it.
+ -
+ - This includes displaying the connectionNeeded nudge if appropariate.
+ -}
+setupCloudRemote :: StandardGroup -> Maybe Cost -> Annex RemoteName -> Handler a
+setupCloudRemote = setupRemote postsetup . Just
+  where
+	postsetup = redirect . EditNewCloudRepositoryR . Remote.uuid
+
+setupRemote :: (Remote -> Handler a) -> Maybe StandardGroup -> Maybe Cost -> Annex RemoteName -> Handler a
+setupRemote postsetup mgroup mcost getname = do
+	r <- liftAnnex $ addRemote getname
+	repo <- liftAnnex $ Remote.getRepo r
+	liftAnnex $ do
+		maybe noop (defaultStandardGroup (Remote.uuid r)) mgroup
+		maybe noop (Config.setRemoteCost repo) mcost
+	liftAssistant $ syncRemote r
+	postsetup r
diff --git a/Assistant/WebApp/Notifications.hs b/Assistant/WebApp/Notifications.hs
new file mode 100644
index 0000000000..5fb66a2240
--- /dev/null
+++ b/Assistant/WebApp/Notifications.hs
@@ -0,0 +1,86 @@
+{- git-annex assistant webapp notifications
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Notifications where
+
+import Assistant.Common
+import Assistant.WebApp
+import Assistant.WebApp.Types
+import Assistant.DaemonStatus
+import Utility.NotificationBroadcaster
+import Utility.Yesod
+import Utility.AuthToken
+
+import Data.Text (Text)
+import qualified Data.Text as T
+import qualified Data.Aeson.Types as Aeson
+
+{- Add to any widget to make it auto-update using long polling.
+ -
+ - The widget should have a html element with an id=ident, which will be
+ - replaced when it's updated.
+ -
+ - The geturl route should return the notifier url to use for polling.
+ -
+ - ms_delay is how long to delay between AJAX updates
+ - ms_startdelay is how long to delay before updating with AJAX at the start
+ -}
+autoUpdate :: Text -> Route WebApp -> Int -> Int -> Widget
+autoUpdate tident geturl ms_delay ms_startdelay = do
+	let delay = Aeson.String (T.pack (show ms_delay))
+	let startdelay = Aeson.String (T.pack (show ms_startdelay))
+	let ident = Aeson.String tident
+	$(widgetFile "notifications/longpolling")
+
+{- Notifier urls are requested by the javascript, to avoid allocation
+ - of NotificationIds when noscript pages are loaded. This constructs a
+ - notifier url for a given Route and NotificationBroadcaster.
+ -}
+notifierUrl :: (NotificationId -> Route WebApp) -> Assistant NotificationBroadcaster -> Handler RepPlain
+notifierUrl route broadcaster = do
+	(urlbits, _params) <- renderRoute . route <$> newNotifier broadcaster
+	webapp <- getYesod
+	return $ RepPlain $ toContent $ T.concat
+		[ "/"
+		, T.intercalate "/" urlbits
+		, "?auth="
+		, fromAuthToken (authToken webapp)
+		]
+
+getNotifierTransfersR :: Handler RepPlain
+getNotifierTransfersR = notifierUrl TransfersR getTransferBroadcaster
+
+getNotifierSideBarR :: Handler RepPlain
+getNotifierSideBarR = notifierUrl SideBarR getAlertBroadcaster
+
+getNotifierRepoListR :: RepoSelector -> Handler RepPlain
+getNotifierRepoListR reposelector = notifierUrl route getRepoListBroadcaster
+  where
+	route nid = RepoListR nid reposelector
+
+getNotifierGlobalRedirR :: Handler RepPlain
+getNotifierGlobalRedirR = notifierUrl GlobalRedirR getGlobalRedirBroadcaster
+
+getTransferBroadcaster :: Assistant NotificationBroadcaster
+getTransferBroadcaster = transferNotifier <$> getDaemonStatus
+
+getAlertBroadcaster :: Assistant NotificationBroadcaster
+getAlertBroadcaster = alertNotifier <$> getDaemonStatus
+
+getRepoListBroadcaster :: Assistant NotificationBroadcaster
+getRepoListBroadcaster =  syncRemotesNotifier <$> getDaemonStatus
+
+getGlobalRedirBroadcaster :: Assistant NotificationBroadcaster
+getGlobalRedirBroadcaster =  globalRedirNotifier <$> getDaemonStatus
+
+getGlobalRedirR :: NotificationId -> Handler RepPlain
+getGlobalRedirR nid = do
+	waitNotifier getGlobalRedirBroadcaster nid
+	maybe (getGlobalRedirR nid) (return . RepPlain . toContent . T.pack)
+		=<< globalRedirUrl <$> liftAssistant getDaemonStatus
diff --git a/Assistant/WebApp/OtherRepos.hs b/Assistant/WebApp/OtherRepos.hs
new file mode 100644
index 0000000000..c13d93ffdc
--- /dev/null
+++ b/Assistant/WebApp/OtherRepos.hs
@@ -0,0 +1,39 @@
+{- git-annex assistant webapp switching to other repos
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.OtherRepos where
+
+import Assistant.Common
+import Assistant.WebApp.Types
+import Assistant.WebApp.Page
+import Config.Files.AutoStart
+import Utility.Yesod
+import Assistant.Restart
+import qualified Utility.RawFilePath as R
+
+getRepositorySwitcherR :: Handler Html
+getRepositorySwitcherR = page "Switch repository" Nothing $ do
+	repolist <- liftIO listOtherRepos
+	$(widgetFile "control/repositoryswitcher")
+
+listOtherRepos :: IO [(String, String)]
+listOtherRepos = do
+	dirs <- readAutoStartFile
+	pwd <- R.getCurrentDirectory
+	gooddirs <- filterM isrepo $
+		filter (\d -> not $ toRawFilePath d `dirContains` pwd) dirs
+	names <- mapM relHome gooddirs
+	return $ sort $ zip names gooddirs
+  where
+	isrepo d = doesDirectoryExist (d </> ".git")
+
+getSwitchToRepositoryR :: FilePath -> Handler Html
+getSwitchToRepositoryR repo = do
+	liftIO $ addAutoStartFile repo -- make this the new default repo
+	redirect =<< liftIO (newAssistantUrl repo)
diff --git a/Assistant/WebApp/Page.hs b/Assistant/WebApp/Page.hs
new file mode 100644
index 0000000000..ee7491a688
--- /dev/null
+++ b/Assistant/WebApp/Page.hs
@@ -0,0 +1,75 @@
+{- git-annex assistant webapp page display
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeFamilies, QuasiQuotes, MultiParamTypeClasses, TemplateHaskell, OverloadedStrings, RankNTypes #-}
+
+module Assistant.WebApp.Page where
+
+import Assistant.Common
+import Assistant.WebApp
+import Assistant.WebApp.Types
+import Assistant.WebApp.SideBar
+import Utility.Yesod
+
+import qualified Text.Hamlet as Hamlet
+import Data.Text (Text)
+
+data NavBarItem = DashBoard | Configuration | About
+	deriving (Eq, Ord, Enum, Bounded)
+
+navBarName :: NavBarItem -> Text
+navBarName DashBoard = "Dashboard"
+navBarName Configuration = "Configuration"
+navBarName About = "About"
+
+navBarRoute :: NavBarItem -> Route WebApp
+navBarRoute DashBoard = DashboardR
+navBarRoute Configuration = ConfigurationR
+navBarRoute About = AboutR
+
+defaultNavBar :: [NavBarItem]
+defaultNavBar = [minBound .. maxBound]
+
+firstRunNavBar :: [NavBarItem]
+firstRunNavBar = [Configuration, About]
+
+selectNavBar :: Handler [NavBarItem]
+selectNavBar = ifM inFirstRun (return firstRunNavBar, return defaultNavBar)
+
+{- A standard page of the webapp, with a title, a sidebar, and that may
+ - be highlighted on the navbar. -}
+page :: Hamlet.Html -> Maybe NavBarItem -> Widget -> Handler Html
+page title navbaritem content = customPage navbaritem $ do
+	setTitle title
+	content
+	sideBarDisplay
+
+{- A custom page, with no title or sidebar set. -}
+customPage :: Maybe NavBarItem -> Widget -> Handler Html
+customPage = customPage' True
+
+customPage' :: Bool -> Maybe NavBarItem -> Widget -> Handler Html
+customPage' with_longpolling navbaritem content = do
+	webapp <- getYesod
+	case cannotRun webapp of
+		Nothing -> do
+			navbar <- map navdetails <$> selectNavBar
+			pageinfo <- widgetToPageContent $ do
+				addStylesheet $ StaticR css_bootstrap_css
+				addStylesheet $ StaticR css_bootstrap_theme_css
+				addScript $ StaticR js_jquery_full_js
+				addScript $ StaticR js_bootstrap_js
+				when with_longpolling $
+					addScript $ StaticR js_longpolling_js
+				$(widgetFile "page")
+			withUrlRenderer $(Hamlet.hamletFile $ hamletTemplate "bootstrap")
+		Just msg -> giveup msg
+  where
+	navdetails i = (navBarName i, navBarRoute i, Just i == navbaritem)
+
+controlMenu :: Widget
+controlMenu = $(widgetFile "controlmenu")
diff --git a/Assistant/WebApp/Pairing.hs b/Assistant/WebApp/Pairing.hs
new file mode 100644
index 0000000000..2c4086a5cf
--- /dev/null
+++ b/Assistant/WebApp/Pairing.hs
@@ -0,0 +1,79 @@
+{- git-annex assistant pairing
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.WebApp.Pairing where
+
+import Assistant.Common
+import qualified Utility.MagicWormhole as Wormhole
+import Command.P2P (wormholePairing, PairingResult(..))
+import P2P.Address
+import Annex.Concurrent
+import Git.Types
+
+import Control.Concurrent
+import Control.Concurrent.Async
+import Control.Concurrent.STM
+import qualified Data.Map.Strict as M
+
+data PairingWith = PairingWithSelf | PairingWithFriend
+	deriving (Eq, Show, Read)
+
+type WormholePairingState = TVar (M.Map WormholePairingId WormholePairingHandle)
+
+type WormholePairingHandle = (PairingWith, RemoteName, MVar Wormhole.CodeObserver, MVar Wormhole.Code, Async (Annex PairingResult))
+
+newtype WormholePairingId = WormholePairingId Int
+	deriving (Ord, Eq, Show, Read)
+
+newWormholePairingState :: IO WormholePairingState
+newWormholePairingState = newTVarIO M.empty
+
+addWormholePairingState :: WormholePairingHandle -> WormholePairingState -> IO WormholePairingId
+addWormholePairingState h tv = atomically $ do
+	m <- readTVar tv
+	-- use of head is safe because allids is infinite
+	let i = Prelude.head $ filter (`notElem` M.keys m) allids
+	writeTVar tv (M.insert i h m)
+	return i
+  where
+	allids = map WormholePairingId [1..]
+
+-- | Starts the wormhole pairing processes.
+startWormholePairing :: PairingWith -> RemoteName -> [P2PAddress] -> Assistant WormholePairingHandle
+startWormholePairing pairingwith remotename ouraddrs = do
+	observerrelay <- liftIO newEmptyMVar
+	producerrelay <- liftIO newEmptyMVar
+	-- wormholePairing needs to run in the Annex monad, and is a
+	-- long-duration action. So, don't just liftAnnex to run it;
+	-- fork the Annex state.
+	runner <- liftAnnex $ forkState $ 
+		wormholePairing remotename ouraddrs $ \observer producer -> do
+			putMVar observerrelay observer
+			theircode <- takeMVar producerrelay
+			Wormhole.sendCode producer theircode
+	tid <- liftIO $ async runner
+	return (pairingwith, remotename, observerrelay, producerrelay, tid)
+
+-- | Call after sendTheirWormholeCode. This can take some time to return.
+finishWormholePairing :: WormholePairingHandle -> Assistant PairingResult
+finishWormholePairing (_, _, _, _, tid) = liftAnnex =<< liftIO (wait tid)
+
+-- | Waits for wormhole to produce our code. Can be called repeatedly, safely.
+getOurWormholeCode :: WormholePairingHandle -> IO Wormhole.Code
+getOurWormholeCode (_, _, observerrelay, _, _) =
+	readMVar observerrelay >>= Wormhole.waitCode
+
+-- | Sends their code to wormhole. If their code has already been sent,
+-- avoids blocking and returns False.
+sendTheirWormholeCode :: WormholePairingHandle -> Wormhole.Code -> IO Bool
+sendTheirWormholeCode (_, _, _, producerrelay, _) = tryPutMVar producerrelay
+
+withPairingWith :: WormholePairingHandle -> (PairingWith -> a) -> a
+withPairingWith (pairingwith, _, _, _, _) a = a pairingwith
+
+withRemoteName :: WormholePairingHandle -> (RemoteName -> a) -> a
+withRemoteName (_, remotename, _, _, _) a = a remotename
diff --git a/Assistant/WebApp/Repair.hs b/Assistant/WebApp/Repair.hs
new file mode 100644
index 0000000000..ded075cedc
--- /dev/null
+++ b/Assistant/WebApp/Repair.hs
@@ -0,0 +1,35 @@
+{- git-annex assistant repository repair
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.Repair where
+
+import Assistant.WebApp.Common
+import Assistant.WebApp.RepoList
+import Remote (prettyUUID, remoteFromUUID)
+import Annex.UUID (getUUID)
+import Assistant.Repair
+
+getRepairRepositoryR :: UUID -> Handler Html
+getRepairRepositoryR = postRepairRepositoryR
+postRepairRepositoryR :: UUID -> Handler Html
+postRepairRepositoryR u = page "Repair repository" Nothing $ do
+	repodesc <- liftAnnex $ prettyUUID u
+	repairingmainrepo <- (==) u <$> liftAnnex getUUID
+	$(widgetFile "control/repairrepository")
+
+getRepairRepositoryRunR :: UUID -> Handler Html
+getRepairRepositoryRunR = postRepairRepositoryRunR
+postRepairRepositoryRunR :: UUID -> Handler Html
+postRepairRepositoryRunR u = do
+	r <- liftAnnex $ remoteFromUUID u
+	void $ liftAssistant $ runRepair u r True
+	page "Repair repository" Nothing $ do
+		let repolist = repoListDisplay $
+			mainRepoSelector { nudgeAddMore = True }
+		$(widgetFile "control/repairrepository/done")
diff --git a/Assistant/WebApp/RepoId.hs b/Assistant/WebApp/RepoId.hs
new file mode 100644
index 0000000000..99cdb85113
--- /dev/null
+++ b/Assistant/WebApp/RepoId.hs
@@ -0,0 +1,40 @@
+{- git-annex assistant webapp RepoId type
+ -
+ - Copyright 2012,2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Assistant.WebApp.RepoId where
+
+import Annex.Common
+import Git.Types (RemoteName)
+import qualified Remote
+
+{- Parts of the webapp need to be able to act on repositories that may or
+ - may not have a UUID. -}
+data RepoId
+	= RepoUUID UUID
+	| RepoName RemoteName
+	deriving (Eq, Ord, Show, Read)
+
+mkRepoId :: Remote -> RepoId
+mkRepoId r = case Remote.uuid r of
+	NoUUID -> RepoName (Remote.name r)
+	u -> RepoUUID u
+
+
+describeRepoId :: RepoId -> Annex String
+describeRepoId (RepoUUID u) = Remote.prettyUUID u
+describeRepoId (RepoName n) = return n
+
+repoIdRemote :: RepoId -> Annex (Maybe Remote)
+repoIdRemote (RepoUUID u) = Remote.remoteFromUUID u
+repoIdRemote (RepoName n) = Remote.byNameOnly n
+
+lacksUUID :: RepoId -> Bool
+lacksUUID r = asUUID r == NoUUID
+
+asUUID :: RepoId -> UUID
+asUUID (RepoUUID u) = u
+asUUID _ = NoUUID
diff --git a/Assistant/WebApp/RepoList.hs b/Assistant/WebApp/RepoList.hs
new file mode 100644
index 0000000000..980bd67ff2
--- /dev/null
+++ b/Assistant/WebApp/RepoList.hs
@@ -0,0 +1,266 @@
+{- git-annex assistant webapp repository list
+ -
+ - Copyright 2012,2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings #-}
+
+module Assistant.WebApp.RepoList where
+
+import Assistant.WebApp.Common
+import Assistant.DaemonStatus
+import Assistant.WebApp.Notifications
+import qualified Remote
+import qualified Types.Remote as Remote
+import Remote.List.Util
+import Annex.UUID (getUUID)
+import Logs.Remote
+import Logs.Trust
+import Logs.Group
+import Config
+import Config.GitConfig
+import Git.Remote
+import Assistant.Sync
+import Config.Cost
+import Utility.NotificationBroadcaster
+import qualified Git
+import Types.ProposedAccepted
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import qualified Data.Text as T
+import Data.Function
+import Control.Concurrent
+
+type RepoList = [(RepoDesc, RepoId, CurrentlyConnected, Actions)]
+
+type RepoDesc = String
+type CurrentlyConnected = Bool
+
+{- Actions that can be performed on a repo in the list. -}
+data Actions
+	= DisabledRepoActions
+		{ setupRepoLink :: Route WebApp }
+	| SyncingRepoActions
+		{ setupRepoLink :: Route WebApp
+		, syncToggleLink :: Route WebApp
+		}
+	| NotSyncingRepoActions
+		{ setupRepoLink :: Route WebApp
+		, syncToggleLink :: Route WebApp
+		}
+	| UnwantedRepoActions
+		{ setupRepoLink :: Route WebApp }
+
+mkSyncingRepoActions :: RepoId -> Actions
+mkSyncingRepoActions repoid = SyncingRepoActions
+	{ setupRepoLink = EditRepositoryR repoid
+	, syncToggleLink = DisableSyncR repoid
+	}
+
+mkNotSyncingRepoActions :: RepoId -> Actions
+mkNotSyncingRepoActions repoid = NotSyncingRepoActions
+	{ setupRepoLink = EditRepositoryR repoid
+	, syncToggleLink = EnableSyncR repoid
+	}
+
+mkUnwantedRepoActions :: RepoId -> Actions
+mkUnwantedRepoActions repoid = UnwantedRepoActions
+	{ setupRepoLink = EditRepositoryR repoid
+	}
+
+needsEnabled :: Actions -> Bool
+needsEnabled (DisabledRepoActions _) = True
+needsEnabled _ = False
+
+notSyncing :: Actions -> Bool
+notSyncing (SyncingRepoActions _ _) = False
+notSyncing _ = True
+
+notWanted :: Actions -> Bool
+notWanted (UnwantedRepoActions _) = True
+notWanted _ = False
+
+{- Called by client to get a list of repos, that refreshes
+ - when new repos are added.
+ -
+ - Returns a div, which will be inserted into the calling page.
+ -}
+getRepoListR :: NotificationId -> RepoSelector -> Handler Html
+getRepoListR nid reposelector = do
+	waitNotifier getRepoListBroadcaster nid
+	p <- widgetToPageContent $ repoListDisplay reposelector
+	withUrlRenderer $ [hamlet|^{pageBody p}|]
+
+mainRepoSelector :: RepoSelector
+mainRepoSelector = RepoSelector
+	{ onlyCloud = False
+	, onlyConfigured = False
+	, includeHere = True
+	, nudgeAddMore = False
+	}
+
+{- List of cloud repositories, configured and not. -}
+cloudRepoList :: Widget
+cloudRepoList = repoListDisplay RepoSelector
+	{ onlyCloud = True
+	, onlyConfigured = False
+	, includeHere = False
+	, nudgeAddMore = False
+	}
+
+repoListDisplay :: RepoSelector -> Widget
+repoListDisplay reposelector = do
+	autoUpdate ident (NotifierRepoListR reposelector) (10 :: Int) (10 :: Int)
+	addScript $ StaticR js_jquery_ui_core_js
+	addScript $ StaticR js_jquery_ui_widget_js
+	addScript $ StaticR js_jquery_ui_mouse_js
+	addScript $ StaticR js_jquery_ui_sortable_js
+
+	repolist <- liftH $ repoList reposelector
+	let addmore = nudgeAddMore reposelector
+	let nootherrepos = length repolist < 2
+
+	$(widgetFile "repolist")
+  where
+	ident = "repolist"
+
+{- A list of known repositories, with actions that can be taken on them. -}
+repoList :: RepoSelector -> Handler RepoList
+repoList reposelector
+	| onlyConfigured reposelector = list =<< configured
+	| otherwise = list =<< (++) <$> configured <*> unconfigured
+  where
+	configured = do
+		syncremotes <- syncRemotes <$> liftAssistant getDaemonStatus
+		let syncing = S.fromList $ map mkRepoId syncremotes
+		liftAnnex $ do
+			unwanted <- S.fromList
+				<$> filterM inUnwantedGroup (map Remote.uuid syncremotes)
+			trustmap <- trustMap
+			allrs <- concat . Remote.byCost <$> Remote.remoteList
+			rs <- filter (\r -> M.lookup (Remote.uuid r) trustmap /= Just DeadTrusted)
+				. map fst
+				. filter selectedrepo
+				<$> forM allrs (\r -> (,) <$> pure r <*> Remote.getRepo r)
+			let l = flip map (map mkRepoId rs) $ \r -> case r of
+				(RepoUUID u)
+					| u `S.member` unwanted -> (r, mkUnwantedRepoActions r)
+				_
+					| r `S.member` syncing -> (r, mkSyncingRepoActions r)
+					| otherwise -> (r, mkNotSyncingRepoActions r)
+			if includeHere reposelector
+				then do
+					r <- RepoUUID <$> getUUID
+					autocommit <- getGitConfigVal annexAutoCommit
+					let hereactions = if autocommit
+						then mkSyncingRepoActions r
+						else mkNotSyncingRepoActions r
+					let here = (r, hereactions)
+					return $ here : l
+				else return l
+	unconfigured = liftAnnex $ do
+		m <- remoteConfigMap
+		g <- gitRepo
+		map snd . catMaybes . filter selectedremote 
+			. map (findinfo m g)
+			<$> trustExclude DeadTrusted (M.keys m)
+	selectedrepo (r, repo)
+		| Remote.readonly r = False
+		| onlyCloud reposelector = Git.repoIsUrl repo
+			&& Remote.uuid r /= NoUUID 
+		| otherwise = True
+	selectedremote Nothing = False
+	selectedremote (Just (iscloud, _))
+		| onlyCloud reposelector = iscloud
+		| otherwise = True
+	findinfo m g u = case fromProposedAccepted <$> getconfig (Accepted "type") of
+		Just "rsync" -> val True EnableRsyncR
+		Just "directory" -> val False EnableDirectoryR
+		Just "S3" -> val True EnableS3R
+		Just "glacier" -> val True EnableGlacierR
+		Just "webdav" -> val True EnableWebDAVR
+		Just "gcrypt" ->
+			-- Skip gcrypt repos on removable drives;
+			-- handled separately.
+			case fromProposedAccepted <$> getconfig (Accepted "gitrepo") of
+				Just rr	| remoteLocationIsUrl (parseRemoteLocation rr False g) ->
+					val True EnableSshGCryptR
+				_ -> Nothing
+		Just "git" -> 
+			case fromProposedAccepted <$> getconfig (Accepted "location") of
+				Just loc | remoteLocationIsSshUrl (parseRemoteLocation loc False g) ->
+					val True EnableSshGitRemoteR
+				_ -> Nothing
+		_ -> Nothing
+	  where
+		getconfig k = M.lookup k =<< M.lookup u m
+		val iscloud r = Just (iscloud, (RepoUUID u, DisabledRepoActions $ r u))
+	list l = do
+		cc <- currentlyConnectedRemotes <$> liftAssistant getDaemonStatus
+		forM (nubBy ((==) `on` fst) l) $ \(repoid, actions) ->
+			(,,,)
+				<$> liftAnnex (describeRepoId repoid)
+				<*> pure repoid
+				<*> pure (getCurrentlyConnected repoid cc)
+				<*> pure actions
+
+getCurrentlyConnected :: RepoId -> S.Set UUID -> CurrentlyConnected
+getCurrentlyConnected (RepoUUID u) cc = S.member u cc
+getCurrentlyConnected _ _ = False
+
+getEnableSyncR :: RepoId -> Handler ()
+getEnableSyncR = flipSync True
+
+getDisableSyncR :: RepoId -> Handler ()
+getDisableSyncR = flipSync False
+
+flipSync :: Bool -> RepoId -> Handler ()
+flipSync enable repoid = do
+	mremote <- liftAnnex $ repoIdRemote repoid
+	liftAssistant $ changeSyncable mremote enable
+	redirectBack
+
+getRepositoriesReorderR :: Handler ()
+getRepositoriesReorderR = do
+	{- Get uuid of the moved item, and the list it was moved within. -}
+	moved <- fromjs <$> runInputGet (ireq textField "moved")
+	list <- map fromjs <$> lookupGetParams "list[]"
+	liftAnnex $ go list =<< repoIdRemote moved
+	liftAssistant updateSyncRemotes
+  where
+	go _ Nothing = noop
+	go list (Just remote) = do
+		rs <- catMaybes <$> mapM repoIdRemote list
+		forM_ (reorderCosts remote rs) $ \(r, newcost) ->
+			when (Remote.cost r /= newcost) $ do
+				repo <- Remote.getRepo r
+				setRemoteCost repo newcost
+		remotesChanged
+	fromjs = fromMaybe (RepoUUID NoUUID) . readish . T.unpack
+
+reorderCosts :: Remote -> [Remote] -> [(Remote, Cost)]
+reorderCosts remote rs = zip rs'' (insertCostAfter costs i)
+  where
+	{- Find the index of the remote in the list that the remote
+	 - was moved to be after.
+	 - If it was moved to the start of the list, -1 -}
+	i = fromMaybe 0 (elemIndex remote rs) - 1
+	rs' = filter (\r -> Remote.uuid r /= Remote.uuid remote) rs
+	costs = map Remote.cost rs'
+	rs'' = (\(x, y) -> x ++ [remote] ++ y) $ splitAt (i + 1) rs'
+
+getSyncNowRepositoryR :: UUID -> Handler ()
+getSyncNowRepositoryR uuid = do
+	u <- liftAnnex getUUID
+	if u == uuid
+		then do
+			thread <- liftAssistant $ asIO $
+				reconnectRemotes
+					=<< (syncRemotes <$> getDaemonStatus)
+			void $ liftIO $ forkIO thread
+		else maybe noop (liftAssistant . syncRemote)
+			=<< liftAnnex (Remote.remoteFromUUID uuid)
+	redirectBack
diff --git a/Assistant/WebApp/SideBar.hs b/Assistant/WebApp/SideBar.hs
new file mode 100644
index 0000000000..aae063d7c4
--- /dev/null
+++ b/Assistant/WebApp/SideBar.hs
@@ -0,0 +1,109 @@
+{- git-annex assistant webapp sidebar
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE QuasiQuotes, TemplateHaskell, OverloadedStrings, FlexibleContexts #-}
+
+module Assistant.WebApp.SideBar where
+
+import Assistant.Common
+import Assistant.WebApp
+import Assistant.WebApp.Types
+import Assistant.WebApp.Notifications
+import Assistant.Alert.Utility
+import Assistant.DaemonStatus
+import Utility.NotificationBroadcaster
+import Utility.Yesod
+
+import Data.Text (Text)
+import qualified Data.Text as T
+import qualified Data.Map as M
+import Control.Concurrent
+
+sideBarDisplay :: Widget
+sideBarDisplay = do
+	let content = do
+		{- Add newest alerts to the sidebar. -}
+		alertpairs <- liftH $ M.toList . alertMap
+			<$> liftAssistant getDaemonStatus
+		mapM_ renderalert $
+			take displayAlerts $ reverse $ sortAlertPairs alertpairs
+	let ident = "sidebar"
+	$(widgetFile "sidebar/main")
+	autoUpdate ident NotifierSideBarR (10 :: Int) (10 :: Int)
+  where
+	bootstrapclass :: AlertClass -> Text
+	bootstrapclass Activity = "alert-info"
+	bootstrapclass Warning = "alert"
+	bootstrapclass Error = "alert-danger"
+	bootstrapclass Success = "alert-success"
+	bootstrapclass Message = "alert-info"
+
+	renderalert (aid, alert) = do
+		let alertid = show aid
+		let closable = alertClosable alert
+		let block = alertBlockDisplay alert
+		let divclass = bootstrapclass $ alertClass alert
+		let message = renderAlertMessage alert
+		let messagelines = T.lines message
+		let multiline = length messagelines > 1
+		let buttons = zip (alertButtons alert) [1..]
+		$(widgetFile "sidebar/alert")
+
+{- Called by client to get a sidebar display.
+ -
+ - Returns a div, which will be inserted into the calling page.
+ -
+ - Note that the head of the widget is not included, only its
+ - body is. To get the widget head content, the widget is also 
+ - inserted onto all pages.
+ -}
+getSideBarR :: NotificationId -> Handler Html
+getSideBarR nid = do
+	waitNotifier getAlertBroadcaster nid
+
+	{- This 0.1 second delay avoids very transient notifications from
+	 - being displayed and churning the sidebar unnecessarily. 
+	 -
+	 - This needs to be below the level perceptable by the user,
+	 - to avoid slowing down user actions like closing alerts. -}
+	liftIO $ threadDelay 100000
+
+	page <- widgetToPageContent sideBarDisplay
+	withUrlRenderer $ [hamlet|^{pageBody page}|]
+
+{- Called by the client to close an alert. -}
+getCloseAlert :: AlertId -> Handler ()
+getCloseAlert = liftAssistant . removeAlert
+
+{- When an alert with a button is clicked on, the button takes us here. -}
+getClickAlert :: AlertId -> Int -> Handler ()
+getClickAlert i bnum = do
+	m <- alertMap <$> liftAssistant getDaemonStatus
+	case M.lookup i m of
+		Just (Alert { alertButtons = bs })
+			| length bs >= bnum -> do
+				let b = bs !! (bnum - 1)
+				{- Spawn a thread to run the action
+				 - while redirecting. -}
+				case buttonAction b of
+					Nothing -> noop
+					Just a -> liftIO $ void $ forkIO $ a i
+				redirect $ buttonUrl b
+			| otherwise -> redirectBack
+		_ -> redirectBack
+
+htmlIcon :: AlertIcon -> Widget
+htmlIcon ActivityIcon = [whamlet|<img src="@{StaticR activityicon_gif}" alt="">|]
+htmlIcon SyncIcon = [whamlet|<img src="@{StaticR syncicon_gif}" alt="">|]
+htmlIcon InfoIcon = bootstrapIcon "info-sign"
+htmlIcon SuccessIcon = bootstrapIcon "ok"
+htmlIcon ErrorIcon = bootstrapIcon "exclamation-sign"
+htmlIcon UpgradeIcon = bootstrapIcon "arrow-up"
+htmlIcon ConnectionIcon = bootstrapIcon "signal"
+
+bootstrapIcon :: Text -> Widget
+bootstrapIcon name = [whamlet|<span .glyphicon .glyphicon-#{name}>|]
diff --git a/Assistant/WebApp/Types.hs b/Assistant/WebApp/Types.hs
new file mode 100644
index 0000000000..ef8934092a
--- /dev/null
+++ b/Assistant/WebApp/Types.hs
@@ -0,0 +1,197 @@
+{- git-annex assistant webapp types
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeFamilies, QuasiQuotes, MultiParamTypeClasses #-}
+{-# LANGUAGE TemplateHaskell, OverloadedStrings, RankNTypes #-}
+{-# LANGUAGE FlexibleInstances, FlexibleContexts, ViewPatterns #-}
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module Assistant.WebApp.Types (
+	module Assistant.WebApp.Types,
+	Route
+) where
+
+import Assistant.Common
+import Assistant.Ssh
+import Assistant.Pairing
+import Utility.NotificationBroadcaster
+import Utility.AuthToken
+import Utility.WebApp
+import Utility.Yesod
+import Types.Transfer
+import Utility.Gpg (KeyId)
+import BuildInfo (packageversion)
+import Types.ScheduledActivity
+import Assistant.WebApp.RepoId
+import Assistant.WebApp.Pairing
+import Types.Distribution
+
+import Yesod.Static
+import Text.Hamlet
+import Data.Text (Text, pack, unpack)
+import Network.Socket (HostName)
+
+publicFiles "static"
+
+staticRoutes :: Static
+staticRoutes = $(embed "static")
+
+data WebApp = WebApp
+	{ assistantData :: AssistantData
+	, authToken :: AuthToken
+	, relDir :: Maybe FilePath
+	, getStatic :: Static
+	, postFirstRun :: Maybe (IO String)
+	, cannotRun :: Maybe String
+	, noAnnex :: Bool
+	, listenHost ::Maybe HostName
+	, wormholePairingState :: WormholePairingState
+	}
+
+mkYesodData "WebApp" $(parseRoutesFile "Assistant/WebApp/routes")
+
+excludeStatic :: [Text] -> Bool
+excludeStatic [] = True
+excludeStatic (p:_) = p /= "static"
+
+instance Yesod WebApp where
+	{- Require an auth token be set when accessing any (non-static) route -}
+	isAuthorized r _ = checkAuthToken authToken r excludeStatic
+
+	{- Add the auth token to every url generated, except static subsite
+	 - urls (which can show up in Permission Denied pages). -}
+	joinPath = insertAuthToken authToken excludeStatic
+
+	makeSessionBackend = webAppSessionBackend
+	jsLoader _ = BottomOfHeadBlocking
+
+	{- The webapp does not use defaultLayout, so this is only used
+	 - for error pages or any other built-in yesod page.
+	 - 
+	 - This can use static routes, but should use no other routes,
+	 - as that would expose the auth token.
+	 -}
+	defaultLayout content = do
+		webapp <- getYesod
+		pageinfo <- widgetToPageContent $ do
+			addStylesheet $ StaticR css_bootstrap_css
+			addStylesheet $ StaticR css_bootstrap_theme_css
+			addScript $ StaticR js_jquery_full_js
+			addScript $ StaticR js_bootstrap_js
+			$(widgetFile "error")
+		withUrlRenderer $(hamletFile $ hamletTemplate "bootstrap")
+
+instance RenderMessage WebApp FormMessage where
+	renderMessage _ _ = defaultFormMessage
+
+instance LiftAnnex Handler where
+	liftAnnex a = ifM (noAnnex <$> getYesod)
+		( error "internal liftAnnex"
+		, liftAssistant $ liftAnnex a
+		)
+
+instance LiftAnnex (WidgetFor WebApp) where
+	liftAnnex = liftH . liftAnnex
+
+class LiftAssistant m where
+	liftAssistant :: Assistant a -> m a
+
+instance LiftAssistant Handler where
+	liftAssistant a = liftIO . flip runAssistant a
+		=<< assistantData <$> getYesod
+
+instance LiftAssistant (WidgetFor WebApp) where
+	liftAssistant = liftH . liftAssistant
+
+type MkMForm x = MForm Handler (FormResult x, Widget)
+
+type MkAForm x = AForm Handler x
+
+type MkField x = forall m. Monad m => RenderMessage (HandlerSite m) FormMessage => Field m x
+
+data RepoSelector = RepoSelector
+	{ onlyCloud :: Bool
+	, onlyConfigured :: Bool
+	, includeHere :: Bool
+	, nudgeAddMore :: Bool
+	}
+	deriving (Read, Show, Eq)
+
+data RemovableDrive = RemovableDrive 
+	{ diskFree :: Maybe Integer
+	, mountPoint :: Text
+	, driveRepoPath :: Text
+	}
+	deriving (Read, Show, Eq, Ord)
+
+data RepoKey = RepoKey KeyId | NoRepoKey
+	deriving (Read, Show, Eq, Ord)
+
+instance PathPiece RemovableDrive where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece RepoKey where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece SshData where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece NotificationId where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece AlertId where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece Transfer where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece PairMsg where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece SecretReminder where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece UUID where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece RepoSelector where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece ThreadName where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece ScheduledActivity where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece RepoId where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece GitAnnexDistribution where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece PairingWith where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
+
+instance PathPiece WormholePairingId where
+	toPathPiece = pack . show
+	fromPathPiece = readish . unpack
diff --git a/Assistant/WebApp/routes b/Assistant/WebApp/routes
new file mode 100644
index 0000000000..8774228081
--- /dev/null
+++ b/Assistant/WebApp/routes
@@ -0,0 +1,115 @@
+/ DashboardR GET HEAD
+
+/noscript NoScriptR GET
+/noscript/auto NoScriptAutoR GET
+
+/about AboutR GET
+/about/license LicenseR GET
+/about/repogroups RepoGroupR GET
+
+/shutdown ShutdownR GET
+/shutdown/confirm ShutdownConfirmedR GET
+/shutdown/complete NotRunningR GET
+/restart RestartR GET
+/restart/thread/#ThreadName RestartThreadR GET
+/log LogR GET
+
+/config ConfigurationR GET
+/config/preferences PreferencesR GET POST
+/config/needconnection ConnectionNeededR GET
+/config/fsck ConfigFsckR GET POST
+/config/fsck/preferences ConfigFsckPreferencesR POST
+/config/upgrade/start/#GitAnnexDistribution ConfigStartUpgradeR GET
+/config/upgrade/finish ConfigFinishUpgradeR GET
+/config/upgrade/automatically ConfigEnableAutomaticUpgradeR GET
+/config/unused ConfigUnusedR GET POST
+
+/config/addrepository AddRepositoryR GET
+/config/repository/new NewRepositoryR GET POST
+/config/repository/new/first FirstRepositoryR GET POST
+/config/repository/new/androidcamera AndroidCameraRepositoryR GET
+/config/repository/switcher RepositorySwitcherR GET
+/config/repository/switchto/#FilePath SwitchToRepositoryR GET
+/config/repository/combine/#FilePath/#UUID CombineRepositoryR GET
+/config/repository/edit/#RepoId EditRepositoryR GET POST
+/config/repository/edit/new/#UUID EditNewRepositoryR GET POST
+/config/repository/edit/new/cloud/#UUID EditNewCloudRepositoryR GET POST
+/config/repository/sync/disable/#RepoId DisableSyncR GET
+/config/repository/sync/enable/#RepoId EnableSyncR GET
+/config/repository/upgrade/#RepoId UpgradeRepositoryR GET
+
+/config/repository/add/drive AddDriveR GET POST
+/config/repository/add/drive/confirm/#RemovableDrive ConfirmAddDriveR GET
+/config/repository/add/drive/genkey/#RemovableDrive GenKeyForDriveR GET
+/config/repository/add/drive/finish/#RemovableDrive/#RepoKey FinishAddDriveR GET
+/config/repository/add/ssh AddSshR GET POST
+/config/repository/add/ssh/confirm/#SshData/#UUID ConfirmSshR GET
+/config/repository/add/ssh/retry/#SshData RetrySshR GET
+/config/repository/add/ssh/make/git/#SshData MakeSshGitR GET
+/config/repository/add/ssh/make/rsync/#SshData MakeSshRsyncR GET
+/config/repository/add/ssh/make/gcrypt/#SshData/#RepoKey MakeSshGCryptR GET
+/config/repository/add/ssh/combine/#SshData CombineSshR GET
+/config/repository/add/cloud/rsync.net AddRsyncNetR GET POST
+/config/repository/add/cloud/rsync.net/shared/#SshData MakeRsyncNetSharedR GET
+/config/repository/add/cloud/rsync.net/gcrypt/#SshData/#RepoKey MakeRsyncNetGCryptR GET
+/config/repository/add/cloud/S3 AddS3R GET POST
+/config/repository/add/cloud/IA AddIAR GET POST
+/config/repository/add/cloud/glacier AddGlacierR GET POST
+
+/config/repository/pair/local/start StartLocalPairR GET POST
+/config/repository/pair/local/running/#SecretReminder RunningLocalPairR GET
+/config/repository/pair/local/finish/#PairMsg FinishLocalPairR GET POST
+
+/config/repository/pair/wormhole/start/self StartWormholePairSelfR GET
+/config/repository/pair/wormhole/start/friend StartWormholePairFriendR GET
+/config/repository/pair/wormhole/prepare/#PairingWith PrepareWormholePairR GET
+/config/repository/pair/wormhole/running/#WormholePairingId RunningWormholePairR GET POST
+
+/config/repository/enable/rsync/#UUID EnableRsyncR GET POST
+/config/repository/enable/gcrypt/#UUID EnableSshGCryptR GET POST
+/config/repository/enable/directory/#UUID EnableDirectoryR GET
+/config/repository/enable/S3/#UUID EnableS3R GET POST
+/config/repository/enable/IA/#UUID EnableIAR GET POST
+/config/repository/enable/glacier/#UUID EnableGlacierR GET POST
+/config/repository/enable/webdav/#UUID EnableWebDAVR GET POST
+/config/repository/enable/sshgitremote/#UUID EnableSshGitRemoteR GET POST
+
+/config/repository/reorder RepositoriesReorderR GET
+
+/config/repository/syncnow/#UUID SyncNowRepositoryR GET
+
+/config/repository/delete/confirm/#UUID DeleteRepositoryR GET
+/config/repository/delete/start/#UUID StartDeleteRepositoryR GET
+/config/repository/delete/finish/#UUID FinishDeleteRepositoryR GET
+/config/repository/delete/here DeleteCurrentRepositoryR GET POST
+
+/config/activity/add/#UUID AddActivityR GET POST
+/config/activity/change/#UUID/#ScheduledActivity ChangeActivityR GET POST
+/config/activity/remove/#UUID/#ScheduledActivity RemoveActivityR GET
+
+/transfers/#NotificationId TransfersR GET
+/notifier/transfers NotifierTransfersR GET
+
+/sidebar/#NotificationId SideBarR GET
+/notifier/sidebar NotifierSideBarR GET
+
+/repolist/#NotificationId/#RepoSelector RepoListR GET
+/notifier/repolist/#RepoSelector NotifierRepoListR GET
+
+/globalredir/#NotificationId GlobalRedirR GET
+/notifier/globalredir NotifierGlobalRedirR GET
+
+/alert/close/#AlertId CloseAlert GET
+/alert/click/#AlertId/#Int ClickAlert GET
+/filebrowser FileBrowserR GET POST
+
+/transfer/pause/#Transfer PauseTransferR GET POST
+/transfer/start/#Transfer StartTransferR GET POST
+/transfer/cancel/#Transfer CancelTransferR GET POST
+
+/repair/#UUID RepairRepositoryR GET POST
+/repair/run/#UUID RepairRepositoryRunR GET POST
+
+/unused/cleanup CleanupUnusedR GET
+
+/static StaticR Static getStatic
diff --git a/Author.hs b/Author.hs
new file mode 100644
index 0000000000..281e8def9f
--- /dev/null
+++ b/Author.hs
@@ -0,0 +1,35 @@
+{- authorship made explicit in the code
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE FlexibleInstances, RankNTypes #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Author where
+
+data Author = JoeyHess
+
+-- This allows writing eg:
+--
+-- copyright = author JoeyHess 1999 :: Copyright
+type Copyright = forall t. Authored t => t
+
+class Authored t where
+	author:: Author -> Int -> t
+
+instance Authored Bool where
+	author _ year = year >= 2010
+	{-# INLINE author #-}
+
+instance Authored (a -> a) where
+	author by year f
+		| author by year = f
+		| otherwise = author by (pred year) f
+	{-# INLINE author #-}
+
+instance Monad m => Authored (a -> m a) where
+	author by year = pure . author by year
+	{-# INLINE author #-}
diff --git a/Backend.hs b/Backend.hs
new file mode 100644
index 0000000000..216b59fb4a
--- /dev/null
+++ b/Backend.hs
@@ -0,0 +1,121 @@
+{- git-annex key/value backends
+ -
+ - Copyright 2010-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Backend (
+	builtinList,
+	defaultBackend,
+	defaultHashBackend,
+	genKey,
+	getBackend,
+	chooseBackend,
+	lookupBackendVariety,
+	lookupBuiltinBackendVariety,
+	maybeLookupBackendVariety,
+	isStableKey,
+	isCryptographicallySecureKey,
+	isCryptographicallySecure,
+) where
+
+import qualified Data.Map as M
+
+import Annex.Common
+import qualified Annex
+import Annex.CheckAttr
+import Types.Key
+import Types.KeySource
+import qualified Types.Backend as B
+import Utility.Metered
+import Backend.Variety
+import qualified Backend.VURL
+
+{- Built-in backends. Does not include externals. -}
+builtinList :: [Backend]
+builtinList = regularBackendList ++ Backend.VURL.backends
+
+{- Backend to use by default when generating a new key. Takes git config
+ - and --backend option into account. -}
+defaultBackend :: Annex Backend
+defaultBackend = maybe cache return =<< Annex.getState Annex.backend
+  where
+	cache = do
+		n <- maybe (annexBackend <$> Annex.getGitConfig) (return . Just)
+			=<< Annex.getRead Annex.forcebackend
+		b <- case n of
+			Just name | valid name -> lookupname name
+			_ -> pure defaultHashBackend
+		Annex.changeState $ \s -> s { Annex.backend = Just b }
+		return b
+	valid name = not (null name)
+	lookupname = lookupBackendVariety . parseKeyVariety . encodeBS
+
+{- Generates a key for a file. -}
+genKey :: KeySource -> MeterUpdate -> Backend -> Annex (Key, Backend)
+genKey source meterupdate b = case B.genKey b of
+	Just a -> do
+		k <- a source meterupdate
+		return (k, b)
+	Nothing -> giveup $ "Cannot generate a key for backend " ++
+		decodeBS (formatKeyVariety (B.backendVariety b))
+
+getBackend :: FilePath -> Key -> Annex (Maybe Backend)
+getBackend file k = maybeLookupBackendVariety (fromKey keyVariety k) >>= \case
+	Just backend -> return $ Just backend
+	Nothing -> do
+		warning $ "skipping " <> QuotedPath (toRawFilePath file) <> " (" <>
+			UnquotedString (unknownBackendVarietyMessage (fromKey keyVariety k)) <> ")"
+		return Nothing
+
+unknownBackendVarietyMessage :: KeyVariety -> String
+unknownBackendVarietyMessage v =
+	"unknown backend " ++ decodeBS (formatKeyVariety v)
+
+{- Looks up the backend that should be used for a file.
+ - That can be configured on a per-file basis in the gitattributes file,
+ - or forced with --backend. -}
+chooseBackend :: RawFilePath -> Annex Backend
+chooseBackend f = Annex.getRead Annex.forcebackend >>= go
+  where
+	go Nothing = do
+		mb <- maybeLookupBackendVariety . parseKeyVariety . encodeBS
+			=<< checkAttr "annex.backend" f
+		case mb of
+			Just b -> return b
+			Nothing -> defaultBackend
+	go (Just _) = defaultBackend
+
+{- Looks up a backend by variety. May fail if unsupported or disabled. -}
+lookupBackendVariety :: KeyVariety -> Annex Backend
+lookupBackendVariety v = fromMaybe (giveup (unknownBackendVarietyMessage v))
+	<$> maybeLookupBackendVariety v
+
+lookupBuiltinBackendVariety :: KeyVariety -> Backend
+lookupBuiltinBackendVariety v = fromMaybe (giveup (unknownBackendVarietyMessage v)) $
+	maybeLookupBuiltinBackendVariety v
+
+maybeLookupBuiltinBackendVariety :: KeyVariety -> Maybe Backend
+maybeLookupBuiltinBackendVariety v = M.lookup v varietyMap
+
+maybeLookupBackendVariety :: KeyVariety -> Annex (Maybe Backend)
+maybeLookupBackendVariety v = maybeLookupBackendVarietyMap v varietyMap
+
+varietyMap :: M.Map KeyVariety Backend
+varietyMap = makeVarietyMap builtinList
+
+isStableKey :: Key -> Annex Bool
+isStableKey k = maybe False (`B.isStableKey` k) 
+	<$> maybeLookupBackendVariety (fromKey keyVariety k)
+
+isCryptographicallySecureKey :: Key -> Annex Bool
+isCryptographicallySecureKey k = maybe 
+	(pure False)
+	(\b -> B.isCryptographicallySecureKey b k)
+	=<< maybeLookupBackendVariety (fromKey keyVariety k)
+
+isCryptographicallySecure :: Backend -> Bool
+isCryptographicallySecure = B.isCryptographicallySecure
diff --git a/Backend/External.hs b/Backend/External.hs
new file mode 100644
index 0000000000..53416c7e4b
--- /dev/null
+++ b/Backend/External.hs
@@ -0,0 +1,378 @@
+{- git-annex external backend
+ -
+ - Copyright 2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeSynonymInstances #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Backend.External (makeBackend) where
+
+import Annex.Common
+import Annex.ExternalAddonProcess
+import Backend.Utilities
+import Types.Key
+import Types.Backend
+import Types.KeySource
+import Utility.Metered
+import qualified Utility.SimpleProtocol as Proto
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Short as S (toShort, fromShort)
+import qualified Data.Map.Strict as M
+import Data.Char
+import Control.Concurrent
+import System.IO.Unsafe (unsafePerformIO)
+
+newtype ExternalBackendName = ExternalBackendName S.ByteString
+	deriving (Show, Eq, Ord)
+
+-- Makes Backend representing an external backend of any type.
+-- If the program is not available or doesn't work, makes a Backend
+-- that cannot generate or verify keys, but that still lets the keys be
+-- basically used.
+makeBackend :: S.ByteString -> HasExt -> Annex Backend
+makeBackend bname hasext =
+	withExternalState ebname hasext (return . externalBackend)
+  where
+	ebname = ExternalBackendName bname
+
+makeBackend' :: ExternalBackendName -> HasExt -> Either ExternalAddonStartError ExternalAddonProcess -> Annex Backend
+makeBackend' ebname@(ExternalBackendName bname) hasext (Right p) = do
+	let st = ExternalState
+		{ externalAddonProcess = Right p
+		, externalBackend = unavailBackend ebname hasext
+		}
+	canverify <- handleRequest st CANVERIFY (pure False) $ \case
+		CANVERIFY_YES -> result True
+		CANVERIFY_NO -> result False
+		_ -> Nothing
+	isstable <- handleRequest st ISSTABLE (pure False) $ \case
+		ISSTABLE_YES -> result True
+		ISSTABLE_NO -> result False
+		_ -> Nothing
+	iscryptographicallysecure <- handleRequest st ISCRYPTOGRAPHICALLYSECURE (pure False) $ \case
+		ISCRYPTOGRAPHICALLYSECURE_YES -> result True
+		ISCRYPTOGRAPHICALLYSECURE_NO -> result False
+		_ -> Nothing
+	return $ Backend
+		{ backendVariety = ExternalKey bname hasext
+		, genKey = Just $ genKeyExternal ebname hasext
+		, verifyKeyContent = if canverify
+			then Just $ verifyKeyContentExternal ebname hasext
+				-- The protocol supports PROGRESS here,
+				-- but it's not actually used. It was put
+				-- in to avoid needing a protocol version
+				-- bump if progress handling is later added.
+				nullMeterUpdate
+			else Nothing
+		, verifyKeyContentIncrementally = Nothing
+		, canUpgradeKey = Nothing
+		, fastMigrate = Nothing
+		, isStableKey = const isstable
+		, isCryptographicallySecure = iscryptographicallysecure
+		, isCryptographicallySecureKey = const (pure iscryptographicallysecure)
+		}
+makeBackend' ebname hasext (Left _) = return $ unavailBackend ebname hasext
+
+unavailBackend :: ExternalBackendName -> HasExt -> Backend
+unavailBackend (ExternalBackendName bname) hasext = 
+	Backend
+		{ backendVariety = ExternalKey bname hasext
+		, genKey = Nothing
+		, verifyKeyContent = Nothing
+		, verifyKeyContentIncrementally = Nothing
+		, canUpgradeKey = Nothing
+		, fastMigrate = Nothing
+		, isStableKey = const False
+		, isCryptographicallySecure = False
+		, isCryptographicallySecureKey = const (pure False)
+		}
+
+genKeyExternal :: ExternalBackendName -> HasExt -> KeySource -> MeterUpdate -> Annex Key
+genKeyExternal ebname hasext ks meterupdate = 
+	withExternalState ebname hasext $ \st ->
+		handleRequest st req notavail go
+  where
+	req = GENKEY (fromRawFilePath (contentLocation ks))
+	notavail = giveup $ "Cannot generate a key, since " ++ externalBackendProgram ebname ++ " is not available."
+	
+	go (GENKEY_SUCCESS pk) = Just $ Result <$> fromProtoKey pk hasext ks
+	go (GENKEY_FAILURE msg) = Just $ giveup $
+		"External backend program failed to generate a key: " ++ msg
+	go (PROGRESS bytesprocessed) = Just $ do
+		liftIO $ meterupdate bytesprocessed
+		return $ GetNextMessage go
+	go _ = Nothing
+
+verifyKeyContentExternal :: ExternalBackendName -> HasExt -> MeterUpdate -> Key -> RawFilePath -> Annex Bool
+verifyKeyContentExternal ebname hasext meterupdate k f = 
+	withExternalState ebname hasext $ \st ->
+		handleRequest st req notavail go
+  where
+	req = VERIFYKEYCONTENT (toProtoKey k) (fromRawFilePath f)
+
+	-- This should not be able to happen, because CANVERIFY is checked
+	-- before this function is enable, and so the external program 
+	-- is available. But if it does, fail the verification.
+	notavail = return False
+
+	go VERIFYKEYCONTENT_SUCCESS = result True
+	go VERIFYKEYCONTENT_FAILURE = result False
+	go (PROGRESS bytesprocessed) = Just $ do
+		liftIO $ meterupdate bytesprocessed
+		return $ GetNextMessage go
+	go _ = Nothing
+
+-- State about a running external backend program.
+data ExternalState = ExternalState
+	{ externalAddonProcess :: Either ExternalAddonStartError ExternalAddonProcess
+	, externalBackend :: Backend
+	}
+
+handleRequest :: ExternalState -> Request -> Annex a -> ResponseHandler a -> Annex a
+handleRequest st req whenunavail responsehandler =
+	withExternalAddon st whenunavail $ \p -> do
+		sendMessage p req
+		let loop = receiveResponse p responsehandler
+			(Just . handleExceptionalMessage loop)
+		loop
+  where
+	handleExceptionalMessage _ (ERROR err) = do
+		warning $ UnquotedString $
+			"external special remote error: " ++ err
+		whenunavail
+	handleExceptionalMessage loop (DEBUG msg) = do
+		fastDebug "Backend.External" msg
+		loop
+
+withExternalAddon :: ExternalState -> a -> (ExternalAddonProcess -> a) -> a
+withExternalAddon st whenunavail a = case externalAddonProcess st of
+	Right addon -> a addon
+	Left _ -> whenunavail
+
+sendMessage :: Proto.Sendable m => ExternalAddonProcess -> m -> Annex ()
+sendMessage p m = liftIO $ do
+	protocolDebug p True line
+	hPutStrLn (externalSend p) line
+	hFlush (externalSend p)
+  where
+	line = unwords $ Proto.formatMessage m
+
+{- A response handler can yield a result, or it can request that another
+ - message be consumed from the external. -}
+data ResponseHandlerResult a
+	= Result a
+	| GetNextMessage (ResponseHandler a)
+
+type ResponseHandler a = Response -> Maybe (Annex (ResponseHandlerResult a))
+
+result :: a -> Maybe (Annex (ResponseHandlerResult a))
+result = Just . return . Result
+
+{- Waits for a message from the external backend, and passes it to the
+ - appropriate handler. 
+ -
+ - If the handler returns Nothing, this is a protocol error.
+ -}
+receiveResponse
+	:: ExternalAddonProcess
+	-> ResponseHandler a
+	-> (ExceptionalMessage -> Maybe (Annex a))
+	-> Annex a
+receiveResponse p handleresponse handleexceptional =
+	go =<< liftIO (catchMaybeIO $ hGetLine $ externalReceive p)
+  where
+	go Nothing = protocolError False ""
+	go (Just s) = do
+		liftIO $ protocolDebug p False s
+		case Proto.parseMessage s :: Maybe Response of
+			Just resp -> case handleresponse resp of
+				Nothing -> protocolError True s
+				Just callback -> callback >>= \case
+					Result a -> return a
+					GetNextMessage handleresponse' ->
+						receiveResponse p handleresponse' handleexceptional
+			Nothing -> case Proto.parseMessage s :: Maybe ExceptionalMessage of
+				Just msg -> maybe (protocolError True s) id (handleexceptional msg)
+				Nothing -> protocolError False s
+
+	protocolError parsed s = giveup $ "external backend protocol error, unexpectedly received \"" ++ s ++ "\" " ++
+		if parsed
+			then "(message not allowed at this time)"
+			else "(unable to parse message)"
+
+-- Information about pools of of running external backends that are
+-- available to use is stored in this global.
+{-# NOINLINE poolVar #-}
+poolVar :: MVar (M.Map ExternalBackendName (ExternalAddonPID, [ExternalState]))
+poolVar = unsafePerformIO $ newMVar M.empty
+
+-- Starts a new instance of an external backend.
+-- Does not add it to the poolVar; caller should add it once it's done
+-- using it.
+newExternalState :: ExternalBackendName -> HasExt -> ExternalAddonPID -> Annex ExternalState
+newExternalState ebname hasext pid = do
+	st <- startExternalAddonProcess basecmd [] pid
+	st' <- case st of
+		Left (ProgramNotInstalled msg) -> warnonce msg >> return st
+		Left (ProgramFailure msg) -> warnonce msg >> return st
+		Right p -> do
+			sendMessage p GETVERSION
+			v <- receiveResponse p
+				(\resp -> case resp of
+					VERSION v -> result v
+					_ -> Nothing
+				)
+				(const Nothing)
+			if v `notElem` supportedProtocolVersions
+				then do
+					warnonce (basecmd ++ " uses an unsupported version of the external backend protocol")
+					return $ Left (ProgramFailure "bad protocol version")
+				else return (Right p)
+	backend <- makeBackend' ebname hasext st'
+	return $ ExternalState
+		{ externalAddonProcess = st'
+		, externalBackend = backend
+		}
+  where
+	basecmd = externalBackendProgram ebname
+	warnonce msg = when (pid == 1) $
+		warning (UnquotedString msg)
+
+externalBackendProgram :: ExternalBackendName -> String
+externalBackendProgram (ExternalBackendName bname) = "git-annex-backend-X" ++ decodeBS bname
+
+-- Runs an action with an ExternalState, starting a new external backend
+-- process if necessary. It is returned to the pool once the action
+-- finishes successfully. On exception, it's shut down.
+withExternalState :: ExternalBackendName -> HasExt -> (ExternalState -> Annex a) -> Annex a
+withExternalState bname hasext a = do
+	st <- get
+	r <- a st `onException` shutdown st
+	put st -- only when no exception is thrown
+	return r
+  where
+	get = do
+		m <- liftIO $ takeMVar poolVar
+		case fromMaybe (1, []) (M.lookup bname m) of
+			(pid, []) -> do
+				let m' = M.insert bname (succ pid, []) m
+				liftIO $ putMVar poolVar m'
+				newExternalState bname hasext pid
+			(pid, (st:rest)) -> do
+				let m' = M.insert bname (pid, rest) m
+				liftIO $ putMVar poolVar m'
+				return st
+	put st = liftIO $ modifyMVar_ poolVar $
+		pure . M.adjust (\(pid, l) -> (pid, st:l)) bname
+	shutdown st = liftIO $
+		withExternalAddon st noop (flip externalShutdown False)
+
+-- This is a key as seen by the protocol consumer. When the "E" variant
+-- of the external backend is in use, it does not include an extension.
+-- And it's assumed not to contain spaces or newlines, or anything besides
+-- ascii alphanumerics, because the protocol does not allow keys containing
+-- such things.
+newtype ProtoKey = ProtoKey Key
+	deriving (Show)
+
+fromProtoKey :: ProtoKey -> HasExt -> KeySource -> Annex Key
+fromProtoKey (ProtoKey k) (HasExt False) _ = pure k
+fromProtoKey (ProtoKey k) hasext@(HasExt True) source =
+	addE source (setHasExt hasext) k
+
+toProtoKey :: Key -> ProtoKey
+toProtoKey k = ProtoKey $ alterKey k $ \d -> d
+	-- The extension can be easily removed, because the protocol
+	-- documentation does not allow '.' to be used in the keyName,
+	-- so the first one is the extension.
+	{ keyName = S.toShort (S.takeWhile (/= dot) (S.fromShort (keyName d)))
+	, keyVariety = setHasExt (HasExt False) (keyVariety d)
+	}
+  where
+	dot = fromIntegral (ord '.')
+
+setHasExt :: HasExt -> KeyVariety -> KeyVariety
+setHasExt hasext (ExternalKey name _) = ExternalKey name hasext
+setHasExt _ v = v
+
+instance Proto.Serializable ProtoKey where
+	serialize (ProtoKey k) = Proto.serialize k
+	deserialize = fmap ProtoKey . Proto.deserialize
+
+data Request
+	= GETVERSION
+	| CANVERIFY
+	| ISSTABLE
+	| ISCRYPTOGRAPHICALLYSECURE
+	| GENKEY FilePath
+	| VERIFYKEYCONTENT ProtoKey FilePath
+	deriving (Show)
+
+data Response
+	= VERSION ProtocolVersion
+	| CANVERIFY_YES
+	| CANVERIFY_NO
+	| ISSTABLE_YES
+	| ISSTABLE_NO
+	| ISCRYPTOGRAPHICALLYSECURE_YES
+	| ISCRYPTOGRAPHICALLYSECURE_NO
+	| GENKEY_SUCCESS ProtoKey
+	| GENKEY_FAILURE ErrorMsg
+	| VERIFYKEYCONTENT_SUCCESS
+	| VERIFYKEYCONTENT_FAILURE
+	| PROGRESS BytesProcessed
+	deriving (Show)
+
+data ExceptionalMessage
+	= ERROR ErrorMsg
+	| DEBUG String
+	deriving (Show)
+
+type ErrorMsg = String
+
+newtype ProtocolVersion = ProtocolVersion Int
+	deriving (Show, Eq)
+
+supportedProtocolVersions :: [ProtocolVersion]
+supportedProtocolVersions = [ProtocolVersion 1]
+
+instance Proto.Serializable ProtocolVersion where
+	serialize (ProtocolVersion n) = show n
+	deserialize = ProtocolVersion <$$> readish
+
+instance Proto.Sendable ExceptionalMessage where
+	formatMessage (ERROR err) = ["ERROR", Proto.serialize err]
+	formatMessage (DEBUG msg) = ["DEBUG", Proto.serialize msg]
+
+instance Proto.Receivable ExceptionalMessage where
+	parseCommand "ERROR" = Proto.parse1 ERROR
+	parseCommand "DEBUG" = Proto.parse1 DEBUG
+	parseCommand _ = Proto.parseFail
+
+instance Proto.Sendable Request where
+	formatMessage GETVERSION = ["GETVERSION"]
+	formatMessage CANVERIFY = ["CANVERIFY"]
+	formatMessage ISSTABLE = ["ISSTABLE"]
+	formatMessage ISCRYPTOGRAPHICALLYSECURE = ["ISCRYPTOGRAPHICALLYSECURE"]
+	formatMessage (GENKEY file) = ["GENKEY", Proto.serialize file]
+	formatMessage (VERIFYKEYCONTENT key file) =
+		["VERIFYKEYCONTENT", Proto.serialize key, Proto.serialize file]
+
+instance Proto.Receivable Response where
+	parseCommand "VERSION" = Proto.parse1 VERSION
+	parseCommand "CANVERIFY-YES" = Proto.parse0 CANVERIFY_YES
+	parseCommand "CANVERIFY-NO" = Proto.parse0 CANVERIFY_NO
+	parseCommand "ISSTABLE-YES" = Proto.parse0 ISSTABLE_YES
+	parseCommand "ISSTABLE-NO" = Proto.parse0 ISSTABLE_NO
+	parseCommand "ISCRYPTOGRAPHICALLYSECURE-YES" = Proto.parse0 ISCRYPTOGRAPHICALLYSECURE_YES
+	parseCommand "ISCRYPTOGRAPHICALLYSECURE-NO" = Proto.parse0 ISCRYPTOGRAPHICALLYSECURE_NO
+	parseCommand "GENKEY-SUCCESS" = Proto.parse1 GENKEY_SUCCESS
+	parseCommand "GENKEY-FAILURE" = Proto.parse1 GENKEY_FAILURE
+	parseCommand "VERIFYKEYCONTENT-SUCCESS" = Proto.parse0 VERIFYKEYCONTENT_SUCCESS
+	parseCommand "VERIFYKEYCONTENT-FAILURE" = Proto.parse0 VERIFYKEYCONTENT_FAILURE
+	parseCommand "PROGRESS" = Proto.parse1 PROGRESS
+	parseCommand _ = Proto.parseFail
diff --git a/Backend/Hash.hs b/Backend/Hash.hs
new file mode 100644
index 0000000000..fc0a8b8591
--- /dev/null
+++ b/Backend/Hash.hs
@@ -0,0 +1,310 @@
+{- git-annex hashing backends
+ -
+ - Copyright 2011-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Backend.Hash (
+	backends,
+	testKeyBackend,
+	keyHash,
+	descChecksum,
+) where
+
+import Annex.Common
+import qualified Annex
+import Backend.Utilities
+import Types.Key
+import Types.Backend
+import Types.KeySource
+import Utility.Hash
+import Utility.Metered
+import qualified Utility.RawFilePath as R
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Short as S (toShort, fromShort)
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.ByteString.Lazy as L
+import Control.DeepSeq
+import Control.Exception (evaluate)
+
+data Hash
+	= MD5Hash
+	| SHA1Hash
+	| SHA2Hash HashSize
+	| SHA3Hash HashSize
+	| SkeinHash HashSize
+	| Blake2bHash HashSize
+	| Blake2bpHash HashSize
+	| Blake2sHash HashSize
+	| Blake2spHash HashSize
+
+cryptographicallySecure :: Hash -> Bool
+cryptographicallySecure (SHA2Hash _) = True
+cryptographicallySecure (SHA3Hash _) = True
+cryptographicallySecure (SkeinHash _) = True
+cryptographicallySecure (Blake2bHash _) = True
+cryptographicallySecure (Blake2bpHash _) = True
+cryptographicallySecure (Blake2sHash _) = True
+cryptographicallySecure (Blake2spHash _) = True
+cryptographicallySecure SHA1Hash = False
+cryptographicallySecure MD5Hash = False
+
+{- Order is significant. The first hash is the default one that git-annex
+ - uses, and must be cryptographically secure. 
+ -
+ - Also, want more common sizes earlier than uncommon sizes. -}
+hashes :: [Hash]
+hashes = concat 
+	[ map (SHA2Hash . HashSize) [256, 512, 224, 384]
+	, map (SHA3Hash . HashSize) [256, 512, 224, 384]
+	, map (SkeinHash . HashSize) [256, 512]
+	, map (Blake2bHash . HashSize) [256, 512, 160, 224, 384]
+	, map (Blake2bpHash . HashSize) [512]
+	, map (Blake2sHash . HashSize) [256, 160, 224]
+	, map (Blake2spHash . HashSize) [256, 224]
+	, [SHA1Hash]
+	, [MD5Hash]
+	]
+
+{- The SHA256E backend is the default, so genBackendE comes first. -}
+backends :: [Backend]
+backends = concatMap (\h -> [genBackendE h, genBackend h]) hashes
+
+genBackend :: Hash -> Backend
+genBackend hash = Backend
+	{ backendVariety = hashKeyVariety hash (HasExt False)
+	, genKey = Just (keyValue hash)
+	, verifyKeyContent = Just $ checkKeyChecksum hash
+	, verifyKeyContentIncrementally = Just $ checkKeyChecksumIncremental hash
+	, canUpgradeKey = Just needsUpgrade
+	, fastMigrate = Just trivialMigrate
+	, isStableKey = const True
+	, isCryptographicallySecure = cryptographicallySecure hash
+	, isCryptographicallySecureKey = const $ pure $
+		cryptographicallySecure hash
+	}
+
+genBackendE :: Hash -> Backend
+genBackendE hash = (genBackend hash)
+	{ backendVariety = hashKeyVariety hash (HasExt True)
+	, genKey = Just (keyValueE hash)
+	}
+
+hashKeyVariety :: Hash -> HasExt -> KeyVariety
+hashKeyVariety MD5Hash he = MD5Key he
+hashKeyVariety SHA1Hash he = SHA1Key he
+hashKeyVariety (SHA2Hash size) he = SHA2Key size he
+hashKeyVariety (SHA3Hash size) he = SHA3Key size he
+hashKeyVariety (SkeinHash size) he = SKEINKey size he
+hashKeyVariety (Blake2bHash size) he = Blake2bKey size he
+hashKeyVariety (Blake2bpHash size) he = Blake2bpKey size he
+hashKeyVariety (Blake2sHash size) he = Blake2sKey size he
+hashKeyVariety (Blake2spHash size) he = Blake2spKey size he
+
+{- A key is a hash of its contents. -}
+keyValue :: Hash -> KeySource -> MeterUpdate -> Annex Key
+keyValue hash source meterupdate = do
+	let file = contentLocation source
+	filesize <- liftIO $ getFileSize file
+	s <- hashFile hash file meterupdate
+	return $ mkKey $ \k -> k
+		{ keyName = S.toShort (encodeBS s)
+		, keyVariety = hashKeyVariety hash (HasExt False)
+		, keySize = Just filesize
+		}
+
+{- Extension preserving keys. -}
+keyValueE :: Hash -> KeySource -> MeterUpdate -> Annex Key
+keyValueE hash source meterupdate =
+	keyValue hash source meterupdate
+		>>= addE source (const $ hashKeyVariety hash (HasExt True))
+
+checkKeyChecksum :: Hash -> Key -> RawFilePath -> Annex Bool
+checkKeyChecksum hash key file = catchIOErrorType HardwareFault hwfault $ do
+	fast <- Annex.getRead Annex.fast
+	exists <- liftIO $ R.doesPathExist file
+	case (exists, fast) of
+		(True, False) -> do
+			showAction (UnquotedString descChecksum)
+			sameCheckSum key 
+				<$> hashFile hash file nullMeterUpdate
+		_ -> return True
+  where
+	hwfault e = do
+		warning $ UnquotedString $ "hardware fault: " ++ show e
+		return False
+
+sameCheckSum :: Key -> String -> Bool
+sameCheckSum key s
+	| s == expected = True
+	{- A bug caused checksums to be prefixed with \ in some
+	 - cases; still accept these as legal now that the bug
+	 - has been fixed. -}
+	| '\\' : s == expected = True
+	| otherwise = False
+  where
+	expected = decodeBS (keyHash key)
+
+checkKeyChecksumIncremental :: Hash -> Key -> Annex IncrementalVerifier
+checkKeyChecksumIncremental hash key = liftIO $ (snd $ hasher hash) key
+
+keyHash :: Key -> S.ByteString
+keyHash = fst . splitKeyNameExtension
+
+{- Upgrade keys that have the \ prefix on their hash due to a bug, or
+ - that contain non-alphanumeric characters in their extension.
+ -
+ - Also, for a while migrate from eg SHA256E to SHA256 resulted in a SHA256
+ - key that contained an extension inside its keyName. Upgrade those
+ - keys, removing the extension.
+ -}
+needsUpgrade :: Key -> Bool
+needsUpgrade key = or
+	[ "\\" `S8.isPrefixOf` keyHash key
+	, S.any (not . validInExtension) (snd $ splitKeyNameExtension key)
+	, not (hasExt (fromKey keyVariety key)) && keyHash key /= S.fromShort (fromKey keyName key)
+	]
+
+trivialMigrate :: Key -> Backend -> AssociatedFile -> Bool -> Annex (Maybe Key)
+trivialMigrate oldkey newbackend afile _inannex = do
+	c <- Annex.getGitConfig
+	return $ trivialMigrate' oldkey newbackend afile
+		(annexMaxExtensionLength c)
+		(annexMaxExtensions c)
+
+trivialMigrate' :: Key -> Backend -> AssociatedFile -> Maybe Int -> Maybe Int -> Maybe Key
+trivialMigrate' oldkey newbackend afile maxextlen maxexts
+	{- Fast migration from hashE to hash backend. -}
+	| migratable && hasExt oldvariety = Just $ alterKey oldkey $ \d -> d
+		{ keyName = S.toShort (keyHash oldkey)
+		, keyVariety = newvariety
+		}
+	{- Fast migration from hash to hashE backend. -}
+	| migratable && hasExt newvariety = case afile of
+		AssociatedFile Nothing -> Nothing
+		AssociatedFile (Just file) -> Just $ alterKey oldkey $ \d -> d
+			{ keyName = S.toShort $ keyHash oldkey 
+				<> selectExtension maxextlen maxexts file
+			, keyVariety = newvariety
+			}
+	{- Upgrade to fix bad previous migration that created a
+	 - non-extension preserving key, with an extension
+	 - in its keyName. -}
+	| newvariety == oldvariety && not (hasExt oldvariety) &&
+		keyHash oldkey /= S.fromShort (fromKey keyName oldkey) = 
+			Just $ alterKey oldkey $ \d -> d
+				{ keyName = S.toShort (keyHash oldkey)
+				}
+	| otherwise = Nothing
+  where
+	migratable = oldvariety /= newvariety 
+		&& sameExceptExt oldvariety newvariety
+	oldvariety = fromKey keyVariety oldkey
+	newvariety = backendVariety newbackend
+
+hashFile :: Hash -> RawFilePath -> MeterUpdate -> Annex String
+hashFile hash file meterupdate = 
+	liftIO $ withMeteredFile (fromRawFilePath file) meterupdate $ \b -> do
+		let h = (fst $ hasher hash) b
+		-- Force full evaluation of hash so whole file is read
+		-- before returning.
+		evaluate (rnf h)
+		return h
+
+type Hasher = (L.ByteString -> String, Key -> IO IncrementalVerifier)
+
+hasher :: Hash -> Hasher
+hasher MD5Hash = md5Hasher
+hasher SHA1Hash = sha1Hasher
+hasher (SHA2Hash hashsize) = sha2Hasher hashsize
+hasher (SHA3Hash hashsize) = sha3Hasher hashsize
+hasher (SkeinHash hashsize) = skeinHasher hashsize
+hasher (Blake2bHash hashsize) = blake2bHasher hashsize
+hasher (Blake2bpHash hashsize) = blake2bpHasher hashsize
+hasher (Blake2sHash hashsize) = blake2sHasher hashsize
+hasher (Blake2spHash hashsize) = blake2spHasher hashsize
+
+mkHasher :: HashAlgorithm h => (L.ByteString -> Digest h) -> Context h -> Hasher
+mkHasher h c = (show . h, mkIncrementalVerifier c descChecksum . sameCheckSum)
+
+sha2Hasher :: HashSize -> Hasher
+sha2Hasher (HashSize hashsize)
+	| hashsize == 256 = mkHasher sha2_256 sha2_256_context
+	| hashsize == 224 = mkHasher sha2_224 sha2_224_context
+	| hashsize == 384 = mkHasher sha2_384 sha2_384_context
+	| hashsize == 512 = mkHasher sha2_512 sha2_512_context
+	| otherwise = giveup $ "unsupported SHA2 size " ++ show hashsize
+
+sha3Hasher :: HashSize -> Hasher
+sha3Hasher (HashSize hashsize)
+	| hashsize == 256 = mkHasher sha3_256 sha3_256_context
+	| hashsize == 224 = mkHasher sha3_224 sha3_224_context
+	| hashsize == 384 = mkHasher sha3_384 sha3_384_context
+	| hashsize == 512 = mkHasher sha3_512 sha3_512_context
+	| otherwise = giveup $ "unsupported SHA3 size " ++ show hashsize
+
+skeinHasher :: HashSize -> Hasher
+skeinHasher (HashSize hashsize)
+	| hashsize == 256 = mkHasher skein256 skein256_context
+	| hashsize == 512 = mkHasher skein512 skein512_context
+	| otherwise = giveup $ "unsupported SKEIN size " ++ show hashsize
+
+blake2bHasher :: HashSize -> Hasher
+blake2bHasher (HashSize hashsize)
+	| hashsize == 256 = mkHasher blake2b_256 blake2b_256_context
+	| hashsize == 512 = mkHasher blake2b_512 blake2b_512_context
+	| hashsize == 160 = mkHasher blake2b_160 blake2b_160_context
+	| hashsize == 224 = mkHasher blake2b_224 blake2b_224_context
+	| hashsize == 384 = mkHasher blake2b_384 blake2b_384_context
+	| otherwise = giveup $ "unsupported BLAKE2B size " ++ show hashsize
+
+blake2bpHasher :: HashSize -> Hasher
+blake2bpHasher (HashSize hashsize)
+	| hashsize == 512 = mkHasher blake2bp_512 blake2bp_512_context
+	| otherwise = giveup $ "unsupported BLAKE2BP size " ++ show hashsize
+
+blake2sHasher :: HashSize -> Hasher
+blake2sHasher (HashSize hashsize)
+	| hashsize == 256 = mkHasher blake2s_256 blake2s_256_context
+	| hashsize == 160 = mkHasher blake2s_160 blake2s_160_context
+	| hashsize == 224 = mkHasher blake2s_224 blake2s_224_context
+	| otherwise = giveup $ "unsupported BLAKE2S size " ++ show hashsize
+
+blake2spHasher :: HashSize -> Hasher
+blake2spHasher (HashSize hashsize)
+	| hashsize == 256 = mkHasher blake2sp_256 blake2sp_256_context
+	| hashsize == 224 = mkHasher blake2sp_224 blake2sp_224_context
+	| otherwise = giveup $ "unsupported BLAKE2SP size " ++ show hashsize
+
+sha1Hasher :: Hasher
+sha1Hasher = mkHasher sha1 sha1_context
+
+md5Hasher :: Hasher
+md5Hasher = mkHasher md5 md5_context
+
+descChecksum :: String
+descChecksum = "checksum"
+
+{- A variant of the SHA256E backend, for testing that needs special keys
+ - that cannot collide with legitimate keys in the repository.
+ -
+ - This is accomplished by appending a special extension to the key,
+ - that is not one that selectExtension would select (due to being too
+ - long).
+ -}
+testKeyBackend :: Backend
+testKeyBackend = 
+	let b = genBackendE (SHA2Hash (HashSize 256))
+	    gk = case genKey b of
+		Nothing -> Nothing
+		Just f -> Just (\ks p -> addTestE <$> f ks p)
+	in b { genKey = gk }
+  where
+	addTestE k = alterKey k $ \d -> d
+		{ keyName = keyName d <> longext
+		}
+	longext = ".this-is-a-test-key"
diff --git a/Backend/URL.hs b/Backend/URL.hs
new file mode 100644
index 0000000000..d68b2196e3
--- /dev/null
+++ b/Backend/URL.hs
@@ -0,0 +1,43 @@
+{- git-annex URL backend -- keys whose content is available from urls.
+ -
+ - Copyright 2011-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Backend.URL (
+	backends,
+	fromUrl
+) where
+
+import Annex.Common
+import Types.Key
+import Types.Backend
+import Backend.Utilities
+import Backend.VURL.Utilities (migrateFromURLToVURL)
+
+backends :: [Backend]
+backends = [backendURL]
+
+backendURL :: Backend
+backendURL = Backend
+	{ backendVariety = URLKey
+	, genKey = Nothing
+	, verifyKeyContent = Nothing
+	, verifyKeyContentIncrementally = Nothing
+	, canUpgradeKey = Nothing
+	, fastMigrate = Just migrateFromURLToVURL
+	-- The content of an url can change at any time, so URL keys are
+	-- not stable.
+	, isStableKey = const False
+	, isCryptographicallySecure = False
+	, isCryptographicallySecureKey = const (pure False)
+	}
+
+{- Every unique url has a corresponding key. -}
+fromUrl :: String -> Maybe Integer -> Bool -> Key
+fromUrl url size verifiable = mkKey $ \k -> k
+	{ keyName = genKeyName url
+	, keyVariety = if verifiable then VURLKey else URLKey
+	, keySize = size
+	}
diff --git a/Backend/Utilities.hs b/Backend/Utilities.hs
new file mode 100644
index 0000000000..304cfaac16
--- /dev/null
+++ b/Backend/Utilities.hs
@@ -0,0 +1,84 @@
+{- git-annex backend utilities
+ -
+ - Copyright 2012-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Backend.Utilities where
+
+import Annex.Common
+import qualified Annex
+import Utility.Hash
+import Types.Key
+import Types.KeySource
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Short as S (ShortByteString, toShort)
+import qualified Data.ByteString.Lazy as L
+import qualified System.FilePath.ByteString as P
+import Data.Char
+import Data.Word
+
+{- Generates a keyName from an input string. Takes care of sanitizing it.
+ - If it's not too long, the full string is used as the keyName.
+ - Otherwise, it's truncated, and its md5 is prepended to ensure a unique
+ - key. -}
+genKeyName :: String -> S.ShortByteString
+genKeyName s
+	-- Avoid making keys longer than the length of a SHA256 checksum.
+	| bytelen > sha256len = S.toShort $ encodeBS $
+		truncateFilePath (sha256len - md5len - 1) s' ++ "-" ++ 
+			show (md5 bl)
+	| otherwise = S.toShort $ encodeBS s'
+  where
+	s' = preSanitizeKeyName s
+	bl = encodeBL s
+	bytelen = fromIntegral $ L.length bl
+
+	sha256len = 64
+	md5len = 32
+
+{- Converts a key to a version that includes an extension from the
+ - file that the key was generated from.  -}
+addE :: KeySource -> (KeyVariety -> KeyVariety) -> Key -> Annex Key
+addE source sethasext k = do
+	c <- Annex.getGitConfig
+	let ext = selectExtension
+		(annexMaxExtensionLength c)
+		(annexMaxExtensions c)
+		(keyFilename source)
+	return $ alterKey k $ \d -> d
+		{ keyName = keyName d <> S.toShort ext
+		, keyVariety = sethasext (keyVariety d)
+		}
+
+selectExtension :: Maybe Int -> Maybe Int -> RawFilePath -> S.ByteString
+selectExtension maxlen maxextensions f
+	| null es = ""
+	| otherwise = S.intercalate "." ("":es)
+  where
+	es = filter (not . S.null) $ reverse $
+		take (fromMaybe maxExtensions maxextensions) $
+		filter (S.all validInExtension) $
+		takeWhile shortenough $
+		reverse $ S.split (fromIntegral (ord '.')) (P.takeExtensions f')
+	shortenough e = S.length e <= fromMaybe maxExtensionLen maxlen
+	-- Avoid treating a file ".foo" as having its whole name as an
+	-- extension.
+	f' = S.dropWhile (== fromIntegral (ord '.')) (P.takeFileName f)
+
+validInExtension :: Word8 -> Bool
+validInExtension c
+	| isAlphaNum (chr (fromIntegral c)) = True
+	| fromIntegral c == ord '.' = True
+	| c <= 127 = False -- other ascii: spaces, punctuation, control chars
+	| otherwise = True -- utf8 is allowed, also other encodings
+
+maxExtensionLen :: Int
+maxExtensionLen = 4 -- long enough for "jpeg"
+
+maxExtensions :: Int
+maxExtensions = 2 -- include both extensions of "tar.gz"
diff --git a/Backend/VURL.hs b/Backend/VURL.hs
new file mode 100644
index 0000000000..532b46de39
--- /dev/null
+++ b/Backend/VURL.hs
@@ -0,0 +1,102 @@
+{- git-annex VURL backend -- like URL, but with hash-based verification
+ - of transfers between git-annex repositories.
+ -
+ - Copyright 2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Backend.VURL (
+	backends,
+) where
+
+import Annex.Common
+import Types.Key
+import Types.Backend
+import Logs.EquivilantKeys
+import Backend.Variety
+import Backend.Hash (descChecksum)
+import Utility.Hash
+import Backend.VURL.Utilities
+
+backends :: [Backend]
+backends = [backendVURL]
+
+backendVURL :: Backend
+backendVURL = Backend
+	{ backendVariety = VURLKey
+	, genKey = Nothing
+	, verifyKeyContent = Just $ \k f -> do
+		equivkeys k >>= \case
+			-- Normally there will always be an key
+			-- recorded when a VURL's content is available,
+			-- because downloading the content from the web in
+			-- the first place records one.
+			[] -> return False
+			eks -> do
+				let check ek = getbackend ek >>= \case
+					Nothing -> pure False
+					Just b -> case verifyKeyContent b of
+						Just verify -> verify ek f
+						Nothing -> pure False
+				anyM check eks
+	, verifyKeyContentIncrementally = Just $ \k -> do
+		-- Run incremental verifiers for each equivilant key together,
+		-- and see if any of them succeed.
+		eks <- equivkeys k
+		let get = \ek -> getbackend ek >>= \case
+			Nothing -> pure Nothing
+			Just b -> case verifyKeyContentIncrementally b of
+				Nothing -> pure Nothing
+				Just va -> Just <$> va ek
+		l <- catMaybes <$> forM eks get
+		return $ IncrementalVerifier
+			{ updateIncrementalVerifier = \s ->
+				forM_ l $ flip updateIncrementalVerifier s
+			-- If there are no equivilant keys recorded somehow,
+			-- or if none of them support incremental verification,
+			-- this will return Nothing, which indicates that
+			-- incremental verification was not able to be
+			-- performed.
+			, finalizeIncrementalVerifier = do
+				r <- forM l finalizeIncrementalVerifier
+				return $ case catMaybes r of
+					[] -> Nothing
+					r' -> Just (or r')
+			, unableIncrementalVerifier = 
+				forM_ l unableIncrementalVerifier
+			, positionIncrementalVerifier =
+				getM positionIncrementalVerifier l
+			, descIncrementalVerifier = descChecksum
+			} 
+	, canUpgradeKey = Nothing
+	, fastMigrate = Just migrateFromVURLToURL
+	-- Even if a hash is recorded on initial download from the web and
+	-- is used to verify every subsequent transfer including other
+	-- downloads from the web, in a split-brain situation there
+	-- can be more than one hash and different versions of the content.
+	-- So the content is not stable.
+	, isStableKey = const False
+	-- Not all keys using this backend are necessarily 
+	-- cryptographically secure.
+	, isCryptographicallySecure = False
+	-- A key is secure when all recorded equivilant keys are.
+	-- If there are none recorded yet, it's secure because when
+	-- downloaded, an equivilant key that is cryptographically secure
+	-- will be constructed then.
+	, isCryptographicallySecureKey = \k ->
+		equivkeys k >>= \case
+			[] -> return True
+			l -> do
+				let check ek = getbackend ek >>= \case
+					Nothing -> pure False
+					Just b -> isCryptographicallySecureKey b ek
+				allM check l
+	}
+  where
+	equivkeys k = filter allowedequiv <$> getEquivilantKeys k
+	-- Don't allow using VURL keys as equivilant keys, because that
+	-- could let a crafted git-annex branch cause an infinite loop.
+	allowedequiv ek = fromKey keyVariety ek /= VURLKey
+	varietymap = makeVarietyMap regularBackendList
+	getbackend ek = maybeLookupBackendVarietyMap (fromKey keyVariety ek) varietymap
diff --git a/Backend/VURL/Utilities.hs b/Backend/VURL/Utilities.hs
new file mode 100644
index 0000000000..a3197febb2
--- /dev/null
+++ b/Backend/VURL/Utilities.hs
@@ -0,0 +1,57 @@
+{- git-annex VURL backend utilities
+ -
+ - Copyright 2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Backend.VURL.Utilities where
+
+import Annex.Common
+import Types.Key
+import Types.Backend
+import Types.KeySource
+import Logs.EquivilantKeys
+import qualified Backend.Hash
+import Utility.Metered
+
+migrateFromURLToVURL :: Key -> Backend -> AssociatedFile -> Bool -> Annex (Maybe Key)
+migrateFromURLToVURL oldkey newbackend _af inannex
+	| inannex && fromKey keyVariety oldkey == URLKey && backendVariety newbackend == VURLKey = do
+		let newkey = mkKey $ const $
+			(keyData oldkey)
+				{ keyVariety = VURLKey }
+		contentfile <- calcRepo (gitAnnexLocation oldkey)
+		generateEquivilantKey hashbackend contentfile >>= \case
+			Nothing -> return Nothing
+			Just ek -> do
+				setEquivilantKey newkey ek
+				return (Just newkey)
+	| otherwise = return Nothing
+  where
+	-- Relies on the first hash being cryptographically secure, and the
+	-- default hash used by git-annex.
+	hashbackend = Prelude.head Backend.Hash.backends
+
+migrateFromVURLToURL :: Key -> Backend -> AssociatedFile -> Bool -> Annex (Maybe Key)
+migrateFromVURLToURL oldkey newbackend _af _
+	| fromKey keyVariety oldkey == VURLKey && backendVariety newbackend == URLKey =
+		return $ Just $ mkKey $ const $
+			(keyData oldkey)
+				{ keyVariety = URLKey }
+	| otherwise = return Nothing
+
+-- The Backend must use a cryptographically secure hash.
+generateEquivilantKey :: Backend -> RawFilePath -> Annex (Maybe Key)
+generateEquivilantKey b f =
+	case genKey b of
+		Just genkey -> do
+			showSideAction (UnquotedString Backend.Hash.descChecksum)
+			Just <$> genkey source nullMeterUpdate
+		Nothing -> return Nothing
+  where
+	source = KeySource
+		{ keyFilename = mempty -- avoid adding any extension
+		, contentLocation = f
+		, inodeCache = Nothing
+		}
diff --git a/Backend/Variety.hs b/Backend/Variety.hs
new file mode 100644
index 0000000000..b4da6f2a96
--- /dev/null
+++ b/Backend/Variety.hs
@@ -0,0 +1,39 @@
+{- git-annex backend varieties
+ -
+ - Copyright 2012-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Backend.Variety where
+
+import qualified Data.Map as M
+
+import Annex.Common
+import Types.Key
+import Types.Backend
+import qualified Backend.External
+
+-- When adding a new backend, import it here and add it to the builtinList.
+import qualified Backend.Hash
+import qualified Backend.WORM
+import qualified Backend.URL
+
+{- Regular backends. Does not include externals or VURL. -}
+regularBackendList :: [Backend]
+regularBackendList = Backend.Hash.backends 
+	++ Backend.WORM.backends 
+	++ Backend.URL.backends
+
+{- The default hashing backend. -}
+defaultHashBackend :: Backend
+defaultHashBackend = Prelude.head regularBackendList
+
+makeVarietyMap :: [Backend] -> M.Map KeyVariety Backend
+makeVarietyMap l = M.fromList $ zip (map backendVariety l) l
+
+maybeLookupBackendVarietyMap :: KeyVariety -> M.Map KeyVariety Backend -> Annex (Maybe Backend)
+maybeLookupBackendVarietyMap (ExternalKey s hasext) _varitymap =
+	Just <$> Backend.External.makeBackend s hasext
+maybeLookupBackendVarietyMap v varietymap = 
+	pure $ M.lookup v varietymap
diff --git a/Backend/WORM.hs b/Backend/WORM.hs
new file mode 100644
index 0000000000..2e2df45004
--- /dev/null
+++ b/Backend/WORM.hs
@@ -0,0 +1,70 @@
+{- git-annex "WORM" backend -- Write Once, Read Many
+ -
+ - Copyright 2010 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Backend.WORM (backends) where
+
+import Annex.Common
+import Types.Key
+import Types.Backend
+import Types.KeySource
+import Backend.Utilities
+import Git.FilePath
+import Utility.Metered
+import qualified Utility.RawFilePath as R
+
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.ByteString.Short as S (toShort, fromShort)
+import System.PosixCompat.Files (modificationTime)
+
+backends :: [Backend]
+backends = [backend]
+
+backend :: Backend
+backend = Backend
+	{ backendVariety = WORMKey
+	, genKey = Just keyValue
+	, verifyKeyContent = Nothing
+	, verifyKeyContentIncrementally = Nothing
+	, canUpgradeKey = Just needsUpgrade
+	, fastMigrate = Just removeProblemChars
+	, isStableKey = const True
+	, isCryptographicallySecure = False
+	, isCryptographicallySecureKey = const (pure False)
+	}
+
+{- The key includes the file size, modification time, and the
+ - original filename relative to the top of the git repository.
+ -}
+keyValue :: KeySource -> MeterUpdate -> Annex Key
+keyValue source _ = do
+	let f = contentLocation source
+	stat <- liftIO $ R.getFileStatus f
+	sz <- liftIO $ getFileSize' f stat
+	relf <- fromRawFilePath . getTopFilePath
+		<$> inRepo (toTopFilePath $ keyFilename source)
+	return $ mkKey $ \k -> k
+		{ keyName = genKeyName relf
+		, keyVariety = WORMKey
+		, keySize = Just sz
+		, keyMtime = Just $ modificationTime stat
+		}
+
+{- Old WORM keys could contain spaces and carriage returns, 
+ - and can be upgraded to remove them. -}
+needsUpgrade :: Key -> Bool
+needsUpgrade key =
+	any (`S8.elem` S.fromShort (fromKey keyName key)) [' ', '\r']
+
+removeProblemChars :: Key -> Backend -> AssociatedFile -> Bool -> Annex (Maybe Key)
+removeProblemChars oldkey newbackend _ _
+	| migratable = return $ Just $ alterKey oldkey $ \d -> d
+		{ keyName = S.toShort $ encodeBS $ reSanitizeKeyName $ decodeBS $ S.fromShort $ keyName d }
+	| otherwise = return Nothing
+  where
+	migratable = oldvariety == newvariety
+	oldvariety = fromKey keyVariety oldkey
+	newvariety = backendVariety newbackend
diff --git a/Benchmark.hs b/Benchmark.hs
new file mode 100644
index 0000000000..434d9764d8
--- /dev/null
+++ b/Benchmark.hs
@@ -0,0 +1,47 @@
+{- git-annex benchmark infrastructure
+ -
+ - Copyright 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Benchmark where
+
+import Common
+import Types.Benchmark
+import Types.Command
+import CmdLine.Action
+import CmdLine
+import qualified Annex
+import qualified Annex.Branch
+
+import qualified Options.Applicative as O
+
+{- Given a list of all git-annex Commands, and the user's input,
+ - generates an IO action to benchmark that runs the specified
+ - commands. -}
+mkGenerator :: MkBenchmarkGenerator
+mkGenerator cmds userinput = do
+	-- Get the git-annex branch updated, to avoid the overhead of doing
+	-- so skewing the runtime of the first action that will be
+	-- benchmarked.
+	Annex.Branch.commit "benchmarking"
+	_ <- Annex.Branch.update
+	l <- mapM parsesubcommand $ split [";"] userinput
+	return $ do
+		forM_ l $ \(cmd, seek, st) ->
+			-- The cmd is run for benchmarking without startup or
+			-- shutdown actions.
+			Annex.eval st $ performCommandAction False cmd seek noop
+  where
+	-- Simplified version of CmdLine.dispatch, without support for fuzzy
+	-- matching or out-of-repo commands.
+	parsesubcommand ps = do
+		(cmd, seek, globalconfig) <- liftIO $ O.handleParseResult $
+			parseCmd "git-annex" "benchmarking" ps cmds cmdparser
+		-- Make an entirely separate Annex state for each subcommand,
+		-- and prepare it to run the cmd.
+		st <- liftIO . Annex.new =<< Annex.getState Annex.repo
+		((), st') <- liftIO $ Annex.run st $
+			prepRunCommand cmd globalconfig
+		return (cmd, seek, st')
diff --git a/Build/BuildVersion.hs b/Build/BuildVersion.hs
new file mode 100644
index 0000000000..dbd819fff7
--- /dev/null
+++ b/Build/BuildVersion.hs
@@ -0,0 +1,13 @@
+{- For use by autobuilders, this outputs the version of git-annex that
+ - is being built, and also updates the Build/Version file so the build
+ - will report the right version, including the current git rev. -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+import Build.Version
+
+main :: IO ()
+main = do
+	ver <- getVersion
+	writeVersion ver
+	putStr ver
diff --git a/Build/BundledPrograms.hs b/Build/BundledPrograms.hs
new file mode 100644
index 0000000000..d35cae0e15
--- /dev/null
+++ b/Build/BundledPrograms.hs
@@ -0,0 +1,95 @@
+{- Bundled programs
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Build.BundledPrograms where
+
+import Data.Maybe
+
+import BuildInfo
+
+{- Programs that git-annex uses, to include in the bundle.
+ -
+ - These may be just the command name, or the full path to it. -}
+bundledPrograms :: [FilePath]
+bundledPrograms = preferredBundledPrograms ++ extraBundledPrograms
+
+{- Programs that are only included in the bundle in case the system
+ - doesn't have them. These come after the system PATH.
+ -}
+extraBundledPrograms :: [FilePath]
+extraBundledPrograms = catMaybes
+	[ Nothing
+#ifndef darwin_HOST_OS
+#ifndef mingw32_HOST_OS
+	-- OS X has ssh installed by default.
+	-- On Windows, git provides ssh.
+	-- Linux probably has ssh installed system wide,
+	-- and if so the user probably wants to use that one.
+	, Just "ssh"
+	, Just "ssh-keygen"
+#endif
+#endif
+	]
+
+{- Programs that should be preferred for use from the bundle, over
+ - any that might be installed on the system otherwise. These come before
+ - the system PATH.
+ -
+ - For example, git-annex is built for a specific version of git.
+ -}
+preferredBundledPrograms :: [FilePath]
+preferredBundledPrograms = catMaybes
+	[ Nothing
+#ifndef mingw32_HOST_OS
+	-- git is not included in the windows bundle; git for windows is used
+	, Just "git"
+	-- Not strictly needed in PATH by git-annex, but called
+	-- by git when it sshes to a remote.
+	, Just "git-upload-pack"
+	, Just "git-receive-pack"
+	, Just "git-shell"
+	-- using xargs on windows led to problems, so it's not used there
+	, Just "xargs"
+	-- rsync is not a core dependency, but good to have.
+	-- On windows, bundling rsync required the build be used with a
+	-- particular version of git for windows, so not included there.
+	, Just "rsync"
+	, Just "sh"
+	-- used by git-annex when available
+	, Just "uname"
+	-- Included in git for Windows
+	, Just "cp"
+#endif
+	, BuildInfo.lsof
+	, BuildInfo.gcrypt
+#ifdef linux_HOST_OS
+	-- used to unpack the tarball when upgrading
+	, Just "gunzip"
+	, Just "tar"
+	-- used by runshell to generate locales
+	, Just "localedef"
+#endif
+	-- nice, ionice, and nocache are not included in the bundle;
+	-- we rely on the system's own version, which may better match
+	-- its kernel, and avoid using them if not available.
+	]
+
+magicDLLs :: [FilePath]
+#ifdef mingw32_HOST_OS
+magicDLLs = ["libmagic-1.dll", "libgnurx-0.dll"]
+#else
+magicDLLs = []
+#endif
+
+magicShare :: [FilePath]
+#ifdef mingw32_HOST_OS
+magicShare = ["magic.mgc"]
+#else
+magicShare = []
+#endif
diff --git a/Build/Configure.hs b/Build/Configure.hs
new file mode 100644
index 0000000000..cce9488bae
--- /dev/null
+++ b/Build/Configure.hs
@@ -0,0 +1,106 @@
+{- Checks system configuration and generates Build/SysConfig and Build/Version. -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+{-# LANGUAGE CPP #-}
+
+module Build.Configure where
+
+import Build.TestConfig
+import Build.Version
+import Utility.SafeCommand
+import Utility.Env.Basic
+import qualified Git.Version
+import Utility.SystemDirectory
+
+import Control.Monad
+import Control.Applicative
+import Prelude
+
+tests :: [TestCase]
+tests =
+	[ TestCase "UPGRADE_LOCATION" getUpgradeLocation
+	, TestCase "git" $ testCmd "git" "git --version >/dev/null"
+	, TestCase "git version" getGitVersion
+	, testCp "cp_a" "-a"
+	, testCp "cp_p" "-p"
+	, testCp "cp_preserve_timestamps" "--preserve=timestamps"
+	, testCpReflinkAuto
+	, testCpNoPreserveXattr
+	, TestCase "xargs -0" $ testCmd "xargs_0" "xargs -0 </dev/null"
+	, TestCase "rsync" $ testCmd "rsync" "rsync --version >/dev/null"
+	, TestCase "curl" $ testCmd "curl" "curl --version >/dev/null"
+	, TestCase "bup" $ testCmd "bup" "bup --version >/dev/null"
+	, TestCase "borg" $ testCmd "borg" "borg --version >/dev/null"
+	, TestCase "nice" $ testCmd "nice" "nice true >/dev/null"
+	, TestCase "ionice" $ testCmd "ionice" "ionice -c3 true >/dev/null"
+	, TestCase "nocache" $ testCmd "nocache" "nocache true >/dev/null"
+	, TestCase "gpg" $ maybeSelectCmd "gpg"
+		[ ("gpg", "--version >/dev/null")
+		, ("gpg2", "--version >/dev/null") ]
+	, TestCase "lsof" $ findCmdPath "lsof" "lsof"
+	, TestCase "git-remote-gcrypt" $ findCmdPath "gcrypt" "git-remote-gcrypt"
+	, TestCase "ssh connection caching" getSshConnectionCaching
+	]
+
+tmpDir :: String
+tmpDir = "tmp"
+
+testFile :: String
+testFile = tmpDir ++ "/testfile"
+
+testCp :: ConfigKey -> String -> TestCase
+testCp k option = TestCase cmd $ testCmd k cmdline
+  where
+	cmd = "cp " ++ option
+	cmdline = cmd ++ " " ++ testFile ++ " " ++ testFile ++ ".new"
+
+testCpReflinkAuto :: TestCase
+#ifdef mingw32_HOST_OS
+-- Windows does not support reflink so don't even try to use the option.
+testCpReflinkAuto = TestCase k (return $ Config k (BoolConfig False))
+#else
+testCpReflinkAuto = testCp k "--reflink=auto"
+#endif
+  where
+	k = "cp_reflink_supported"
+
+testCpNoPreserveXattr :: TestCase
+testCpNoPreserveXattr = testCp 
+	"cp_no_preserve_xattr_supported" 
+	"--no-preserve=xattr"
+
+getUpgradeLocation :: Test
+getUpgradeLocation = do
+	e <- getEnv "UPGRADE_LOCATION"
+	return $ Config "upgradelocation" $ MaybeStringConfig e
+
+getGitVersion :: Test
+getGitVersion = go =<< getEnv "FORCE_GIT_VERSION"
+  where
+	go (Just s) = return $ Config "gitversion" $ StringConfig s
+	go Nothing = do
+		v <- Git.Version.installed
+		let oldestallowed = Git.Version.normalize "2.1"
+		when (v < oldestallowed) $
+			error $ "installed git version " ++ show v ++ " is too old! (Need " ++ show oldestallowed ++ " or newer)"
+		return $ Config "gitversion" $ StringConfig $ show v
+
+getSshConnectionCaching :: Test
+getSshConnectionCaching = Config "sshconnectioncaching" . BoolConfig <$>
+	boolSystem "sh" [Param "-c", Param "ssh -o ControlPersist=yes -V >/dev/null 2>/dev/null"]
+
+setup :: IO ()
+setup = do
+	createDirectoryIfMissing True tmpDir
+	writeFile testFile "test file contents"
+
+cleanup :: IO ()
+cleanup = removeDirectoryRecursive tmpDir
+
+run :: [TestCase] -> IO ()
+run ts = do
+	setup
+	config <- runTests ts
+	writeSysConfig config
+	writeVersion =<< getVersion
+	cleanup
diff --git a/Build/DesktopFile.hs b/Build/DesktopFile.hs
new file mode 100644
index 0000000000..8d13294c05
--- /dev/null
+++ b/Build/DesktopFile.hs
@@ -0,0 +1,89 @@
+{- Generating and installing a desktop menu entry file and icon,
+ - and a desktop autostart file. (And OSX equivilants.)
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Build.DesktopFile where
+
+import Utility.Exception
+import Utility.FreeDesktop
+import Utility.Path
+import Utility.Monad
+import Utility.SystemDirectory
+import Utility.FileSystemEncoding
+import Config.Files
+import Utility.OSX
+import Assistant.Install.AutoStart
+import Assistant.Install.Menu
+
+import System.Environment
+#ifndef mingw32_HOST_OS 
+import System.Posix.User
+import Data.Maybe
+import Control.Applicative
+import Prelude
+#endif
+
+systemwideInstall :: IO Bool
+#ifndef mingw32_HOST_OS 
+systemwideInstall = isroot <||> (not <$> userdirset)
+  where
+	isroot = do
+		uid <- fromIntegral <$> getRealUserID
+		return $ uid == (0 :: Int)
+	userdirset = isJust <$> catchMaybeIO (getEnv "USERDIR")
+#else
+systemwideInstall = return False
+#endif
+
+inDestDir :: FilePath -> IO FilePath
+inDestDir f = do
+	destdir <- catchDefaultIO "" (getEnv "DESTDIR")
+	return $ destdir ++ "/" ++ f
+
+writeFDODesktop :: FilePath -> IO ()
+writeFDODesktop command = do
+	systemwide <- systemwideInstall
+
+	datadir <- if systemwide then return systemDataDir else userDataDir
+	menufile <- inDestDir (desktopMenuFilePath "git-annex" datadir)
+	icondir <- inDestDir (iconDir datadir)
+	installMenu command menufile "doc" icondir
+
+	configdir <- if systemwide then return systemConfigDir else userConfigDir
+	installAutoStart command 
+		=<< inDestDir (autoStartPath "git-annex" configdir)
+
+writeOSXDesktop :: FilePath -> IO ()
+writeOSXDesktop command = do
+	installAutoStart command =<< inDestDir =<< ifM systemwideInstall
+		( return $ systemAutoStart osxAutoStartLabel
+		, userAutoStart osxAutoStartLabel
+		)
+
+install :: FilePath -> IO ()
+install command = do
+#ifdef darwin_HOST_OS
+	writeOSXDesktop command
+#else
+	writeFDODesktop command
+#endif
+	ifM systemwideInstall
+		( return ()
+		, do
+			programfile <- inDestDir =<< programFile
+			createDirectoryIfMissing True (fromRawFilePath (parentDir (toRawFilePath programfile)))
+			writeFile programfile command
+		)
+
+installUser :: FilePath -> IO ()
+installUser command = ifM systemwideInstall
+	( return ()
+	, install command
+	)
diff --git a/Build/DistributionUpdate.hs b/Build/DistributionUpdate.hs
new file mode 100644
index 0000000000..dfd85c3222
--- /dev/null
+++ b/Build/DistributionUpdate.hs
@@ -0,0 +1,261 @@
+{- Downloads git-annex autobuilds and installs them into the git-annex
+ - repository in ~/lib/downloads that is used to distribute git-annex
+ - releases.
+ -
+ - Generates info files, containing the version (of the corresponding file
+ - from the autobuild).
+ -
+ - Builds standalone rpms from the standalone tarballs, and populates
+ - a rpm package repository with them using the createrepo_c program.
+ -
+ - Also gpg signs the files.
+ -}
+
+import Annex.Common
+import Types.Distribution
+import Build.Version (getChangelogVersion, Version)
+import Utility.UserInfo
+import Utility.Url
+import Utility.Tmp.Dir
+import Utility.Metered
+import qualified Git.Construct
+import qualified Annex
+import Annex.Content
+import Annex.WorkTree
+import Git.Command
+import qualified Utility.RawFilePath as R
+import Annex.Action
+
+import Data.Time.Clock
+import Data.Char
+import Data.Either
+import System.Posix.Directory
+
+-- git-annex distribution signing key (for Joey Hess)
+signingKey :: String
+signingKey = "89C809CB"
+
+-- URL to an autobuilt git-annex file, and the place to install
+-- it in the repository.
+autobuilds :: [(URLString, FilePath)]
+autobuilds = 
+	(map linuxarch ["i386", "amd64", "armel", "arm64", "i386-ancient", "arm64-ancient"]) ++
+	[ (autobuild "x86_64-apple-catalina/git-annex.dmg", "git-annex/OSX/current/10.15_Catalina/git-annex.dmg")
+	, (autobuild "windows/git-annex-installer.exe", "git-annex/windows/current/git-annex-installer.exe")
+	]
+  where
+	linuxarch a =
+		( autobuild (a ++ "/git-annex-standalone-" ++ a ++ ".tar.gz")
+		, "git-annex/linux/current/git-annex-standalone-" ++ a ++ ".tar.gz"
+		)
+	autobuild f = "https://downloads.kitenet.net/git-annex/autobuild/" ++ f
+
+-- Names of architectures in standalone tarballs and the corresponding
+-- rpm architecture.
+tarrpmarches :: [(String, String)]
+tarrpmarches =
+	[ ("i386", "i386")
+	, ("amd64", "x86_64")
+	, ("arm64", "aarch64")
+	]
+
+main :: IO ()
+main = do
+	useFileSystemEncoding
+	version <- getChangelogVersion
+	repodir <- getRepoDir
+	topdir <- getCurrentDirectory
+	changeWorkingDirectory repodir
+	updated <- catMaybes <$> mapM (getbuild repodir) autobuilds
+	state <- Annex.new =<< Git.Construct.fromPath (toRawFilePath ".")
+	ood <- Annex.eval state $ do
+		buildrpms topdir updated
+		is <- makeinfos updated version
+		quiesce False
+		return is
+	syncToArchiveOrg
+	unless (null ood) $
+		error $ "Some info files are out of date: " ++ show (map fst ood)
+
+-- Download a build from the autobuilder, virus check it, and return its
+-- version.
+-- It's very important that the version matches the build, otherwise
+-- auto-upgrades can loop reatedly. So, check build-version before
+-- and after downloading the file.
+getbuild :: FilePath -> (URLString, FilePath) -> IO (Maybe (FilePath, Version))
+getbuild repodir (url, f) = do
+	bv1 <- getbv
+	let dest = repodir </> f
+	let tmp = dest ++ ".tmp"
+	removeWhenExistsWith removeFile tmp
+	createDirectoryIfMissing True (fromRawFilePath (parentDir (toRawFilePath dest)))
+	let oops s = do
+		removeWhenExistsWith removeFile tmp
+		putStrLn $ "*** " ++ s
+		return Nothing
+	uo <- defUrlOptions
+	ifM (isRight <$> download nullMeterUpdate Nothing url tmp uo)
+		( ifM (liftIO $ virusFree tmp)
+			( do
+				bv2 <- getbv
+				case bv2 of
+					Nothing -> oops $ "no build-version file for " ++ url
+					(Just v)
+						| bv2 == bv1 -> do
+							removeWhenExistsWith removeFile dest
+							renameFile tmp dest
+							-- remove git rev part of version
+							let v' = takeWhile (/= '-') v
+							return $ Just (f, v')
+						| otherwise -> oops $ "build version changed while downloading " ++ url ++ " " ++ show (bv1, bv2)
+			, oops $ "VIRUS detected in " ++ url
+			)
+		, oops $ "failed to download " ++ url
+		)
+  where
+	bvurl = takeDirectory url ++ "/build-version"
+	getbv = do
+		bv <- catchDefaultIO "" $ readProcess "curl" ["--silent", bvurl]
+		return $ if null bv || any (not . versionchar) bv then Nothing else Just bv
+	versionchar c = isAlphaNum c || c == '.' || c == '-'
+
+makeinfos :: [(FilePath, Version)] -> Version -> Annex [([Char], Maybe GitAnnexDistribution)]
+makeinfos updated changelogversion = do
+	mapM_ (\f -> inRepo $ runBool [Param "annex", Param "add", File f]) (map fst updated)
+	void $ inRepo $ runBool 
+		[ Param "commit"
+		, Param "-a"
+		, Param ("-S" ++ signingKey)
+		, Param "-m"
+		, Param $ "publishing git-annex " ++ descversion
+		]
+	now <- liftIO getCurrentTime
+	liftIO $ putStrLn $ "building info files"
+	forM_ updated $ \(f, bv) -> do
+		v <- lookupKey (toRawFilePath f)
+		case v of
+			Nothing -> noop
+			Just k -> whenM (inAnnex k) $ do
+				liftIO $ putStrLn f
+				let infofile = f ++ ".info"
+				let d = GitAnnexDistribution
+					{ distributionUrl = mkUrl f
+					, distributionKey = fromKey id k
+					, distributionVersion = bv
+					, distributionReleasedate = now
+					, distributionUrgentUpgrade = Just "6.20180626"
+					}
+				liftIO $ writeFile infofile $ formatInfoFile d
+				void $ inRepo $ runBool [Param "add", File infofile]
+				signFile infofile
+				signFile f
+	void $ inRepo $ runBool 
+		[ Param "commit"
+		, Param ("-S" ++ signingKey)
+		, Param "-m"
+		, Param $ "updated info files for git-annex " ++ descversion
+		]
+	void $ inRepo $ runBool
+		[ Param "annex"
+		, Param "move"
+		, Param "--to"
+		, Param "website"
+		, Param "--force"
+		]
+	void $ inRepo $ runBool
+		[ Param "annex"
+		, Param "sync"
+		]
+	
+	-- Check for out of date info files.
+	infos <- liftIO $ filter (".info" `isSuffixOf`)
+		<$> emptyWhenDoesNotExist (dirContentsRecursive "git-annex")
+	ds <- liftIO $ forM infos (readish <$$> readFile)
+	let dis = zip infos ds
+	let ood = filter outofdate dis
+	return ood
+  where
+	outofdate (_, md) = case md of
+		Nothing -> True
+		Just d -> distributionVersion d /= changelogversion
+	descversion = unwords (nub (map snd updated))
+
+getRepoDir :: IO FilePath
+getRepoDir = do
+	home <- liftIO myHomeDir
+	return $ home </> "lib" </> "downloads"
+
+mkUrl :: FilePath -> String
+mkUrl f = "https://downloads.kitenet.net/" ++ f
+				
+signFile :: FilePath -> Annex ()
+signFile f = do
+	void $ liftIO $ boolSystem "gpg"
+		[ Param "-a"
+		, Param $ "--default-key=" ++ signingKey
+		, Param "--detach-sign"
+		, File f
+		]
+	liftIO $ R.rename (toRawFilePath (f ++ ".asc")) (toRawFilePath (f ++ ".sig"))
+	void $ inRepo $ runBool [Param "add", File (f ++ ".sig")]
+
+-- clamscan should handle unpacking archives, but did not in my
+-- testing, so do it manually.
+virusFree :: FilePath -> IO Bool
+virusFree f 
+	| ".tar.gz" `isSuffixOf` f = unpack $ \tmpdir ->
+		boolSystem "tar" [ Param "xf", File f, Param "-C", File tmpdir ]
+	| ".dmg" `isSuffixOf` f = unpack $ \tmpdir -> do
+		-- 7z can extract partitions from a dmg, and then
+		-- run on partitions can extract their files
+		unhfs tmpdir f
+		parts <- filter (".hfs" `isSuffixOf`) <$> getDirectoryContents tmpdir
+		forM_ parts $ unhfs tmpdir
+		return True
+	| otherwise = clamscan f
+  where
+	clamscan f' = boolSystem "clamscan"
+		[ Param "--no-summary"
+		, Param "-r"
+		, Param f'
+		]
+	unpack unpacker = withTmpDir "clamscan" $ \tmpdir -> do
+		unlessM (unpacker tmpdir) $
+			error $ "Failed to unpack " ++ f ++ " for virus scan"
+		clamscan tmpdir
+	unhfs dest f' = unlessM (boolSystem "7z" [ Param "x", Param ("-o" ++ dest), File f' ]) $
+		error $ "Failed extracting hfs " ++ f'
+
+buildrpms :: FilePath -> [(FilePath, Version)] -> Annex ()
+buildrpms topdir l = do
+	liftIO $ createDirectoryIfMissing True rpmrepo
+	oldrpms <- map (rpmrepo </>) . filter (".rpm" `isSuffixOf`)
+		<$> liftIO (getDirectoryContents rpmrepo)
+	forM_ tarrpmarches $ \(tararch, rpmarch) ->
+		forM_ (filter (isstandalonetarball tararch . fst) l) $ \(tarball, v) -> do
+			liftIO $ mapM_ (removeWhenExistsWith (R.removeLink . toRawFilePath))
+				(filter ((rpmarch ++ ".rpm") `isSuffixOf`) oldrpms)
+			void $ liftIO $ boolSystem script 
+				[ Param rpmarch
+				, File tarball
+				, Param v
+				, File rpmrepo
+				]
+	void $ inRepo $ runBool [Param "annex", Param "get", File rpmrepo]
+	void $ liftIO $ boolSystem "createrepo_c" [File rpmrepo]
+	void $ inRepo $ runBool [Param "annex", Param "add", File rpmrepo]
+  where
+	isstandalonetarball tararch f =
+		("git-annex-standalone-" ++ tararch ++ ".tar.gz") `isSuffixOf` f
+	script = topdir </> "standalone" </> "rpm" </> "rpmbuild-from-standalone-tarball"
+	rpmrepo = "git-annex/linux/current/rpms"
+
+-- My .mrconfig is configured to copy new files to archive.org,
+-- and moves old versions of content to archive.org to free up space on my
+-- server.
+syncToArchiveOrg :: IO ()
+syncToArchiveOrg = void $ boolSystem "mr" 
+	[ Param "-d"
+	, File "/srv/web/downloads.kitenet.net"
+	, Param "update"
+	]
diff --git a/Build/InstallDesktopFile.hs b/Build/InstallDesktopFile.hs
new file mode 100644
index 0000000000..be261f32cd
--- /dev/null
+++ b/Build/InstallDesktopFile.hs
@@ -0,0 +1,19 @@
+{- Generating and installing a desktop menu entry file and icon,
+ - and a desktop autostart file. (And OSX equivilants.)
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Main where
+
+import Build.DesktopFile
+
+import System.Environment
+
+main :: IO ()
+main = getArgs >>= go
+  where
+	go [] = error "specify git-annex command"
+	go (command:_) = install command
diff --git a/Build/LinuxMkLibs.hs b/Build/LinuxMkLibs.hs
new file mode 100644
index 0000000000..6a5f8dea01
--- /dev/null
+++ b/Build/LinuxMkLibs.hs
@@ -0,0 +1,200 @@
+{- Linux library copier and binary shimmer
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Build.LinuxMkLibs (mklibs) where
+
+import Data.Maybe
+import System.FilePath
+import Control.Monad
+import Data.List
+import System.Posix.Files
+import Control.Monad.IfElse
+import Control.Applicative
+import qualified System.Info
+import Prelude
+
+import Utility.LinuxMkLibs
+import Utility.Directory
+import Utility.Process
+import Utility.Monad
+import Utility.Path
+import Utility.Path.AbsRel
+import Utility.FileMode
+import Utility.CopyFile
+import Utility.FileSystemEncoding
+
+mklibs :: FilePath -> a -> IO Bool
+mklibs top _installedbins = do
+	fs <- dirContentsRecursive top
+	exes <- filterM checkExe fs
+	libs <- runLdd exes
+	
+	glibclibs <- glibcLibs
+	let libs' = nub $ libs ++ glibclibs
+	let (linkers, otherlibs) = partition ("ld-linux" `isInfixOf`) libs'
+	libdirs <- nub . catMaybes <$> mapM (installLib installFile top) otherlibs
+	libdirs' <- consolidateUsrLib top libdirs
+
+	gconvlibs <- gconvLibs
+	mapM_ (installLib installFile top) gconvlibs
+
+	-- Various files used by runshell to set up env vars used by the
+	-- linker shims.
+	writeFile (top </> "libdirs") (unlines libdirs')
+	writeFile (top </> "gconvdir") (fromRawFilePath $ parentDir $ toRawFilePath $ Prelude.head gconvlibs)
+	
+	mapM_ (installLib installFile top) linkers
+	let linker = Prelude.head linkers
+	mapM_ (installLinkerShim top linker) exes
+	
+	return (any hwcaplibdir libdirs)
+  where
+	-- hwcap lib dirs are things like foo/tls and foo/x86.
+	-- Hard to know if a directory is, so this is a heuristic
+	-- looking for things that are certainly not. If this heuristic
+	-- fails, a minor optimisation will not happen, but there will be
+	-- no bad results.
+	hwcaplibdir d = not $ or
+		[ "lib" == takeFileName d
+		-- eg, "lib/x86_64-linux-gnu"
+		, "-linux-" `isInfixOf` takeFileName d
+		]
+
+{- If there are two libdirs that are the same except one is in
+ - usr/lib and the other is in lib/, move the contents of the usr/lib one
+ - into the lib/ one. This reduces the number of directories the linker
+ - needs to look in, and so reduces the number of failed stats
+ - and improves startup time.
+ -}
+consolidateUsrLib :: FilePath -> [FilePath] -> IO [FilePath]
+consolidateUsrLib top libdirs = go [] libdirs
+  where
+	go c [] = return c
+	go c (x:rest) = case filter (\d -> ("/usr" ++ d) == x) libdirs of
+		(d:_) -> do
+			fs <- getDirectoryContents (inTop top x)
+			forM_ fs $ \f -> do
+				let src = inTop top (x </> f)
+				let dst = inTop top (d </> f)
+				unless (dirCruft f) $
+					unlessM (doesDirectoryExist src) $
+						renameFile src dst
+			symlinkHwCapDirs top d
+			go c rest
+		_ -> do
+			symlinkHwCapDirs top x
+			go (x:c) rest
+
+{- The linker looks for optimised versions of libraries depending on the
+ - hardware capabilities. That causes a lot of extra work searching for
+ - libraries, so to avoid it, make symlinks from the hwcap directories
+ - to the libdir. This way, the linker will find a library the first place
+ - it happens to look for it.
+ -}
+symlinkHwCapDirs :: FilePath -> FilePath -> IO ()
+symlinkHwCapDirs top libdir = forM_ hwcapdirs $ \d ->
+	unlessM (doesDirectoryExist (top ++ libdir </> d)) $ do
+		createDirectoryIfMissing True (top ++ libdir </> takeDirectory d)
+		link <- relPathDirToFile
+			(toRawFilePath (top ++ takeDirectory (libdir </> d)))
+			(toRawFilePath (top ++ libdir))
+		let link' = case fromRawFilePath link of
+			"" -> "."
+			l -> l
+		createSymbolicLink link' (top ++ libdir </> d)
+  where
+	hwcapdirs = case System.Info.arch of
+		"x86_64" -> 
+			-- See glibc's sysdeps/x86_64/dl-hwcaps-subdirs.c 
+			-- for list of subarchitecture directories.
+			[ "glibc-hwcaps/x86-64-v2"
+			, "glibc-hwcaps/x86-64-v3"
+			, "glibc-hwcaps/x86-64-v4"
+			-- The linker later checks these, and will check
+			-- them when none of the above subarchitectures
+			-- are supported by the processor, so make them
+			-- just in case.
+			, "tls/x86_64"
+			, "x86_64"
+			]
+		"i386" ->
+			[ "tls/i686"
+			, "tls/i586"
+			, "i686"
+			, "i586"
+			]
+		"arm" ->
+			-- Probably not complete, only what I have
+			-- observed.
+			[ "tls/v7l"
+			, "v7l"
+			]
+		_ -> []
+
+{- Installs a linker shim script around a binary.
+ -
+ - Note that each binary is put into its own separate directory,
+ - to avoid eg git looking for binaries in its directory rather
+ - than in PATH.
+ -
+ - The linker is symlinked to a file with the same basename as the binary,
+ - since that looks better in ps than "ld-linux.so".
+ -}
+installLinkerShim :: FilePath -> FilePath -> FilePath -> IO ()
+installLinkerShim top linker exe = do
+	createDirectoryIfMissing True (top </> shimdir)
+	createDirectoryIfMissing True (top </> exedir)
+	ifM (isSymbolicLink <$> getSymbolicLinkStatus exe)
+		( do
+			sl <- readSymbolicLink exe
+			removeWhenExistsWith removeLink exe
+			removeWhenExistsWith removeLink exedest
+			-- Assume that for a symlink, the destination
+			-- will also be shimmed.
+			let sl' = ".." </> takeFileName sl </> takeFileName sl
+			createSymbolicLink sl' exedest
+		, renameFile exe exedest
+		)
+	link <- relPathDirToFile
+		(toRawFilePath (top </> exedir))
+		(toRawFilePath (top ++ linker))
+	unlessM (doesFileExist (top </> exelink)) $
+		createSymbolicLink (fromRawFilePath link) (top </> exelink)
+	writeFile exe $ unlines
+		[ "#!/bin/sh"
+		, "exec \"$GIT_ANNEX_DIR/" ++ exelink ++ "\" --library-path \"$GIT_ANNEX_LD_LIBRARY_PATH\" \"$GIT_ANNEX_DIR/shimmed/" ++ base ++ "/" ++ base ++ "\" \"$@\""
+		]
+	modifyFileMode (toRawFilePath exe) $ addModes executeModes
+  where
+	base = takeFileName exe
+	shimdir = "shimmed" </> base
+	exedir = "exe"
+	exedest = top </> shimdir </> base
+	exelink = exedir </> base
+
+installFile :: FilePath -> FilePath -> IO ()
+installFile top f = do
+	createDirectoryIfMissing True destdir
+	void $ copyFileExternal CopyTimeStamps f destdir
+  where
+	destdir = inTop top $ fromRawFilePath $ parentDir $ toRawFilePath f
+
+checkExe :: FilePath -> IO Bool
+checkExe f
+	| ".so" `isSuffixOf` f = return False
+	| otherwise = ifM (isExecutable . fileMode <$> getFileStatus f)
+		( checkFileExe <$> readProcess "file" ["-L", f]
+		, return False
+		)
+
+{- Check that file(1) thinks it's a Linux ELF executable, or possibly
+ - a shared library (a few executables like ssh appear as shared libraries). -}
+checkFileExe :: String -> Bool
+checkFileExe s = and
+	[ "ELF" `isInfixOf` s
+	, "executable" `isInfixOf` s || "shared object" `isInfixOf` s
+	]
diff --git a/Build/MakeMans.hs b/Build/MakeMans.hs
new file mode 100644
index 0000000000..359fdd48b2
--- /dev/null
+++ b/Build/MakeMans.hs
@@ -0,0 +1,15 @@
+{- Build man pages, for use by Makefile
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Main where
+
+import Build.Mans
+
+main :: IO ()
+main = buildMansOrWarn
diff --git a/Build/Mans.hs b/Build/Mans.hs
new file mode 100644
index 0000000000..56183e30d6
--- /dev/null
+++ b/Build/Mans.hs
@@ -0,0 +1,65 @@
+{- Build man pages.
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Build.Mans where
+
+import System.Directory
+import System.FilePath
+import Data.List
+import Control.Monad
+import System.Process
+import System.Exit
+import Data.Maybe
+import Utility.Exception
+import Control.Applicative
+import Prelude
+
+buildMansOrWarn :: IO ()
+buildMansOrWarn = do
+	mans <- buildMans
+	when (any isNothing mans) $
+		error "mdwn2man failed"
+
+buildMans :: IO [Maybe FilePath]
+buildMans = do
+	mansrc <- filter isManSrc <$> getDirectoryContents "doc"
+	createDirectoryIfMissing False "man"
+	forM mansrc $ \f -> do
+		let src = "doc" </> f
+		let dest = srcToDest src
+		srcm <- getModificationTime src
+		destm <- catchMaybeIO $ getModificationTime dest
+		if (Just srcm > destm)
+			then do
+				r <- system $ unwords
+					-- Run with per because in some
+					-- cases it may not be executable.
+					[ "perl", "./Build/mdwn2man"
+					, progName src
+					, "1"
+					, src
+					, "> " ++ dest
+					]
+				if r == ExitSuccess
+					then return (Just dest)
+					else return Nothing
+			else return (Just dest)
+
+isManSrc :: FilePath -> Bool
+isManSrc s
+	| not (takeExtension s == ".mdwn") = False
+	| otherwise = "git-annex" `isPrefixOf` f || "git-remote-" `isPrefixOf` f
+  where
+	f = takeFileName s
+
+srcToDest :: FilePath -> FilePath
+srcToDest s = "man" </> progName s ++ ".1"
+
+progName :: FilePath -> FilePath
+progName = dropExtension . takeFileName
diff --git a/Build/NullSoftInstaller.hs b/Build/NullSoftInstaller.hs
new file mode 100644
index 0000000000..ca209076d3
--- /dev/null
+++ b/Build/NullSoftInstaller.hs
@@ -0,0 +1,224 @@
+{- Generates a NullSoft installer program for git-annex on Windows.
+ -
+ - This uses the Haskell nsis package to generate a .nsi file,
+ - which is then used to produce git-annex-installer.exe
+ - 
+ - The installer includes git-annex, and utilities it uses, with the
+ - exception of git and some utilities that are bundled with git.
+ - The user needs to install git separately, and the installer checks
+ - for that.
+ - 
+ - To build the installer, git-annex should already be built to
+ - ./git-annex.exe, then run this program, using eg:
+ -
+ - stack ghc --no-haddock --package nsis Build/NullSoftInstaller.hs
+ -
+ - A build of libmagic will also be included in the installer, if its files
+ - are found in the current directory: 
+ -   ./magic.mgc ./libmagic-1.dll ./libgnurx-0.dll
+ - To build git-annex to usse libmagic, it has to be built with the
+ - magicmime build flag turned on.
+ -
+ - Copyright 2013-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, FlexibleContexts #-}
+
+import Development.NSIS
+import System.FilePath
+import Control.Monad
+import Control.Applicative
+import Data.String
+import Data.Maybe
+import Data.Char
+import Data.List (nub, isPrefixOf)
+
+import Utility.Tmp.Dir
+import Utility.Path
+import Utility.CopyFile
+import Utility.SafeCommand
+import Utility.Process
+import Utility.Exception
+import Utility.Directory
+import Build.BundledPrograms
+
+main = do
+	withTmpDir "nsis-build" $ \tmpdir -> do
+		let gitannex = tmpdir </> gitannexprogram
+		mustSucceed "ln" [File "git-annex.exe", File gitannex]
+		magicDLLs' <- installwhenpresent magicDLLs tmpdir
+		magicShare' <- installwhenpresent magicShare tmpdir
+		let license = tmpdir </> licensefile
+		mustSucceed "sh" [Param "-c", Param $ "zcat standalone/licences.gz > '" ++ license ++ "'"]
+		webappscript <- vbsLauncher tmpdir "git-annex-webapp" "git annex webapp"
+		autostartscript <- vbsLauncher tmpdir "git-annex-autostart" "git annex assistant --autostart"
+		let htmlhelp = tmpdir </> "git-annex.html"
+		writeFile htmlhelp htmlHelpText
+		let gitannexcmd = tmpdir </> "git-annex.cmd"
+		writeFile gitannexcmd "git annex %*"
+		writeFile nsifile $ makeInstaller
+			gitannex gitannexcmd license htmlhelp (winPrograms ++ magicDLLs') magicShare'
+			[ webappscript, autostartscript ]
+		mustSucceed "makensis" [File nsifile]
+	removeFile nsifile -- left behind if makensis fails
+  where
+	nsifile = "git-annex.nsi"
+	mustSucceed cmd params = do
+		r <- boolSystem cmd params
+		case r of
+			True -> return ()
+			False -> error $ cmd ++ " failed"
+	installwhenpresent fs tmpdir = do
+		fs' <- forM fs $ \f -> do
+			present <- doesFileExist f
+			if present
+				then do
+					mustSucceed "ln" [File f, File (tmpdir </> f)]
+					return (Just f)
+				else return Nothing
+		return (catMaybes fs')
+
+{- Generates a .vbs launcher which runs a command without any visible DOS
+ - box. It expects to be passed the directory where git-annex is installed. -}
+vbsLauncher :: FilePath -> String -> String -> IO String
+vbsLauncher tmpdir basename cmd = do
+	let f = tmpdir </> basename ++ ".vbs"
+	writeFile f $ unlines
+		[ "Set objshell=CreateObject(\"Wscript.Shell\")"
+		, "objShell.CurrentDirectory = Wscript.Arguments.item(0)"
+		, "objShell.Run(\"" ++ cmd ++ "\"), 0, False"
+		]
+	return f
+
+gitannexprogram :: FilePath
+gitannexprogram = "git-annex.exe"
+
+licensefile :: FilePath
+licensefile = "git-annex-licenses.txt"
+
+installer :: FilePath
+installer = "git-annex-installer.exe"
+
+uninstaller :: FilePath
+uninstaller = "git-annex-uninstall.exe"
+
+gitInstallDir32 :: Exp FilePath
+gitInstallDir32 = fromString "$PROGRAMFILES\\Git"
+
+gitInstallDir64 :: Exp FilePath
+gitInstallDir64 = fromString "$PROGRAMFILES64\\Git"
+
+gitInstallDir :: Exp FilePath
+gitInstallDir = gitInstallDir64
+
+-- This intentionally has a different name than git-annex or
+-- git-annex-webapp, since it is itself treated as an executable file.
+-- Also, on XP, the filename is displayed, not the description.
+startMenuItem :: Exp FilePath
+startMenuItem = "$SMPROGRAMS/Git Annex (Webapp).lnk"
+
+oldStartMenuItem :: Exp FilePath
+oldStartMenuItem = "$SMPROGRAMS/git-annex.lnk"
+
+autoStartItem :: Exp FilePath
+autoStartItem = "$SMSTARTUP/git-annex-autostart.lnk"
+
+needGit :: Exp String
+needGit = strConcat
+	[ fromString "You need git installed to use git-annex. Looking at "
+	, gitInstallDir
+	, fromString " , it seems to not be installed, "
+	, fromString "or may be installed in another location. "
+	, fromString "You can install git from http:////git-scm.com//"
+	]
+
+makeInstaller :: FilePath -> FilePath -> FilePath -> FilePath -> [FilePath] -> [FilePath] -> [FilePath] -> String
+makeInstaller gitannex gitannexcmd license htmlhelp extrabins sharefiles launchers = nsis $ do
+	name "git-annex"
+	outFile $ str installer
+	{- Installing into the same directory as git avoids needing to modify
+	 - path myself, since the git installer already does it. -}
+	installDir gitInstallDir
+	requestExecutionLevel Admin
+
+	iff (fileExists gitInstallDir)
+		(return ())
+		(alert needGit)
+	
+	-- Pages to display
+	page Directory                   -- Pick where to install
+	page (License license)
+	page InstFiles                   -- Give a progress bar while installing
+	-- Start menu shortcut
+	Development.NSIS.createDirectory "$SMPROGRAMS"
+	createShortcut startMenuItem
+		[ Target "wscript.exe"
+		, Parameters "\"$INSTDIR/cmd/git-annex-webapp.vbs\" \"$INSTDIR/cmd\""
+		, StartOptions "SW_SHOWNORMAL"
+		, IconFile "$INSTDIR/usr/bin/git-annex.exe"
+		, IconIndex 2
+		, Description "Git Annex (Webapp)"
+		]
+	delete [RebootOK] $ oldStartMenuItem
+	createShortcut autoStartItem
+		[ Target "wscript.exe"
+		, Parameters "\"$INSTDIR/cmd/git-annex-autostart.vbs\" \"$INSTDIR/cmd\""
+		, StartOptions "SW_SHOWNORMAL"
+		, IconFile "$INSTDIR/usr/bin/git-annex.exe"
+		, IconIndex 2
+		, Description "git-annex autostart"
+		]
+	section "cmd" [] $ do
+		-- Remove old files no longer installed in the cmd
+		-- directory.
+		removefilesFrom "$INSTDIR/cmd" (gitannex:extrabins)
+		-- Install everything to the same location git puts its
+		-- bins. This makes "git annex" work in the git bash
+		-- shell, since git expects to find the git-annex binary
+		-- there.
+		setOutPath "$INSTDIR\\usr\\bin"
+		mapM_ addfile (gitannex:extrabins)
+		setOutPath "$INSTDIR\\usr\\share\\misc"
+		mapM_ addfile sharefiles
+		-- This little wrapper is installed in the cmd directory,
+		-- so that "git-annex" works (as well as "git annex"),
+		-- when only that directory is in PATH (ie, in a ms-dos
+		-- prompt window).
+		setOutPath "$INSTDIR\\cmd"
+		addfile gitannexcmd
+	section "meta" [] $ do
+		-- git opens this file when git annex --help is run.
+		-- (Program Files/Git/mingw64/share/doc/git-doc/git-annex.html)
+		setOutPath "$INSTDIR\\mingw64\\share\\doc\\git-doc"
+		addfile htmlhelp
+		setOutPath "$INSTDIR"
+		addfile license
+		setOutPath "$INSTDIR\\cmd"
+		mapM_ addfile launchers
+		writeUninstaller $ str uninstaller
+	uninstall $ do
+		delete [RebootOK] $ startMenuItem
+		delete [RebootOK] $ autoStartItem
+		removefilesFrom "$INSTDIR/usr/bin" (gitannex:extrabins)
+		removefilesFrom "$INSTDIR/cmd" (gitannexcmd:launchers)
+		removefilesFrom "$INSTDIR\\mingw64\\share\\doc\\git-doc" [htmlhelp]
+		removefilesFrom "$INSTDIR" [license, uninstaller]
+  where
+	addfile f = file [] (str f)
+	removefilesFrom d = mapM_ (\f -> delete [RebootOK] $ fromString $ d ++ "/" ++ takeFileName f)
+
+winPrograms :: [FilePath]
+winPrograms = map (\p -> p ++ ".exe") bundledPrograms
+
+htmlHelpText :: String
+htmlHelpText = unlines
+	[ "<html>"
+	, "<title>git-annex help</title>"
+	, "<body>"
+	, "For help on git-annex, run \"git annex help\", or"
+	, "<a href=\"https://git-annex.branchable.com/git-annex/\">read the man page</a>."
+	, "</body>"
+	, "</html"
+	]
diff --git a/Build/OSXMkLibs.hs b/Build/OSXMkLibs.hs
new file mode 100644
index 0000000000..c680612d8e
--- /dev/null
+++ b/Build/OSXMkLibs.hs
@@ -0,0 +1,206 @@
+{- OSX library copier
+ -
+ - Copyright 2012-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Build.OSXMkLibs (mklibs) where
+
+import Data.Maybe
+import System.FilePath
+import System.IO
+import Control.Monad
+import Control.Monad.IfElse
+import Data.List
+import Control.Applicative
+import System.Posix.Files
+import Prelude
+
+import Utility.PartialPrelude
+import Utility.Directory
+import Utility.Process
+import Utility.Monad
+import Utility.SafeCommand
+import Utility.Path
+import Utility.Exception
+import Utility.Env
+import Utility.Split
+import Utility.FileSystemEncoding
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+
+type LibMap = M.Map FilePath String
+
+mklibs :: FilePath -> M.Map FilePath FilePath -> IO Bool
+mklibs appbase installedbins = do
+	mklibs' appbase installedbins [] [] M.empty
+	return True
+
+{- Recursively find and install libs, until nothing new to install is found. -}
+mklibs' :: FilePath -> M.Map FilePath FilePath -> [FilePath] -> [(FilePath, FilePath)] -> LibMap -> IO ()
+mklibs' appbase installedbins libdirs replacement_libs libmap = do
+	(new, replacement_libs', libmap') <- installLibs appbase installedbins replacement_libs libmap
+	unless (null new) $
+		mklibs' appbase installedbins (libdirs++new) replacement_libs' libmap'
+
+{- Returns directories into which new libs were installed. -}
+installLibs :: FilePath -> M.Map FilePath FilePath -> [(FilePath, FilePath)] -> LibMap -> IO ([FilePath], [(FilePath, FilePath)], LibMap)
+installLibs appbase installedbins replacement_libs libmap = do
+	(needlibs, replacement_libs', libmap') <- otool appbase installedbins replacement_libs libmap
+	libs <- forM needlibs $ \lib -> do
+		pathlib <- findLibPath lib
+		let shortlib = fromMaybe (error "internal") (M.lookup lib libmap')
+		let fulllib = dropWhile (== '/') lib
+		let dest = appbase </> fulllib
+		let symdest = appbase </> shortlib
+		-- This is a hack; libraries need to be in the same
+		-- directory as the program, so also link them into the
+		-- extra and git-core directories so programs in those will
+		-- find them.
+		let symdestextra = 
+			[ appbase </> "extra" </> shortlib
+			, appbase </> "git-core" </> shortlib
+			]
+		ifM (doesFileExist dest)
+			( return Nothing
+			, do
+				createDirectoryIfMissing True (fromRawFilePath (parentDir (toRawFilePath dest)))
+				putStrLn $ "installing " ++ pathlib ++ " as " ++ shortlib
+				unlessM (boolSystem "cp" [File pathlib, File dest]
+					<&&> boolSystem "chmod" [Param "644", File dest]
+					<&&> boolSystem "ln" [Param "-s", File fulllib, File symdest]) $
+					error "library install failed"
+				forM_ symdestextra $ \d ->
+					unlessM (boolSystem "ln" [Param "-s", File (".." </> fulllib), File d]) $
+						error "library linking failed"
+				return $ Just appbase
+			)
+	return (catMaybes libs, replacement_libs', libmap')
+
+{- Returns libraries to install.
+ -
+ - Note that otool -L ignores DYLD_LIBRARY_PATH, so the
+ - library files returned may need to be run through findLibPath
+ - to find the actual libraries to install.
+ -}
+otool :: FilePath -> M.Map FilePath FilePath -> [(FilePath, FilePath)] -> LibMap -> IO ([FilePath], [(FilePath, FilePath)], LibMap)
+otool appbase installedbins replacement_libs libmap = do
+	files <- filterM doesFileExist =<< dirContentsRecursive appbase
+	process [] files replacement_libs libmap
+  where
+	want s = 
+		-- This seems to be about finding libraries next
+		-- to executables or something. May need further resolving
+		-- to find real path to library, but for now, skip it.
+		not ("@executable_path" `isInfixOf` s)
+		&& not ("@loader_path" `isInfixOf` s)
+		-- OSX frameworks such as Cocoa are too tightly tied to
+		-- a specific OSX version, so don't bundle.
+		&& not (".framework" `isInfixOf` s)
+		-- libSystem.B is tightly tied to frameworks.
+		&& not ("libSystem.B" `isInfixOf` s)
+		-- ImageIO.framework uses libPng which is built against a
+		-- specific version of libz; other versions lack the
+		-- _inflateValidate symbol. So, avoid bundling libz unless
+		-- this incompatibility is resolved.
+		&& not ("libz." `isInfixOf` s)
+	lib_present s
+		| "@rpath" `isInfixOf` s = return True
+		| otherwise = ifM (isJust <$> catchMaybeIO (getSymbolicLinkStatus s))
+			( return True
+			, do
+				hPutStrLn stderr $ "note: skipping library that is not present on disk: " ++ s
+				return False
+			)
+	process c [] rls m = return (nub $ concat c, rls, m)
+	process c (file:rest) rls m = do
+		_ <- boolSystem "chmod" [Param "755", File file]
+		libs <- filterM lib_present
+			=<< filter want . parseOtool
+			<$> readProcess "otool" ["-L", file]
+		expanded_libs <- expand_rpath installedbins libs replacement_libs file
+		let rls' = nub $ rls ++ (zip libs expanded_libs)
+		m' <- install_name_tool file libs expanded_libs m
+		process (expanded_libs:c) rest rls' m'
+
+findLibPath :: FilePath -> IO FilePath
+findLibPath l = go =<< getEnv "DYLD_LIBRARY_PATH"
+  where
+	go Nothing = return l
+	go (Just p) = fromMaybe l
+		<$> firstM doesFileExist (map (</> f) (splitc ':' p))
+	f = takeFileName l
+
+{- Expands any @rpath in the list of libraries.
+ -
+ - This is done by the nasty method of running the command with a dummy
+ - option (so it doesn't do anything.. hopefully!) and asking the dynamic
+ - linker to print expanded rpaths.
+ -}
+expand_rpath :: M.Map FilePath FilePath -> [String] -> [(FilePath, FilePath)] -> FilePath -> IO [String]
+expand_rpath installedbins libs replacement_libs cmd
+	| any ("@rpath" `isInfixOf`) libs = do
+		let origcmd = case M.lookup cmd installedbins of
+			Nothing -> cmd
+			Just cmd' -> cmd'
+		s <- catchDefaultIO "" $ readProcess "sh" ["-c", probe origcmd]
+		let m = if (null s)
+			then M.fromList replacement_libs
+			else M.fromList $ mapMaybe parse $ lines s
+		return $ map (replacem m) libs
+	| otherwise = return libs
+  where
+	probe c = "DYLD_PRINT_RPATHS=1 " ++ c ++ " --getting-rpath-dummy-option 2>&1 | grep RPATH"
+	parse s = case words s of
+		("RPATH":"successful":"expansion":"of":old:"to:":new:[]) -> 
+			Just (old, new)
+		_ -> Nothing
+	replacem m l = fromMaybe l $ M.lookup l m
+
+parseOtool :: String -> [FilePath]
+parseOtool = catMaybes . map parse . lines
+  where
+	parse l
+		| "\t" `isPrefixOf` l = headMaybe $ words l
+		| otherwise = Nothing
+
+{- Adjusts binaries to use libraries bundled with it, rather than the
+ - system libraries. -}
+install_name_tool :: FilePath -> [FilePath] -> [FilePath] -> LibMap -> IO LibMap
+install_name_tool _ [] _ libmap = return libmap
+install_name_tool binary libs expanded_libs libmap = do
+	let (libnames, libmap') = getLibNames expanded_libs libmap
+	let params = concatMap change $ zip libs libnames
+	ok <- boolSystem "install_name_tool" $ params ++ [File binary]
+	unless ok $
+		error $ "install_name_tool failed for " ++ binary
+	return libmap'
+  where
+	change (lib, libname) =
+		[ Param "-change"
+		, File lib
+		, Param $ "@executable_path/" ++ libname
+		]
+
+getLibNames :: [FilePath] -> LibMap -> ([FilePath], LibMap)
+getLibNames libs libmap = go [] libs libmap
+  where
+	go c [] m = (reverse c, m)
+	go c (l:rest) m =
+		let (f, m') = getLibName l m
+		in go (f:c) rest m'
+
+{- Uses really short names for the library files it installs, because
+ - binaries have arbitrarily short RPATH field limits. -}
+getLibName :: FilePath -> LibMap -> (FilePath, LibMap)
+getLibName lib libmap = case M.lookup lib libmap of
+	Just n -> (n, libmap)
+	Nothing -> (nextfreename, M.insert lib nextfreename libmap)
+  where
+	names = map pure ['A' .. 'Z'] ++
+		[[n, l] | n <- ['0' .. '9'], l <- ['A' .. 'Z']]
+	used = S.fromList $ M.elems libmap
+	nextfreename = fromMaybe (error "ran out of short library names!") $ 
+		headMaybe $ dropWhile (`S.member` used) names
diff --git a/Build/Standalone.hs b/Build/Standalone.hs
new file mode 100644
index 0000000000..98c3b2cc89
--- /dev/null
+++ b/Build/Standalone.hs
@@ -0,0 +1,240 @@
+{- Makes standalone bundle.
+ -
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE LambdaCase #-}
+
+module Main where
+
+import System.Environment (getArgs)
+import Control.Monad.IfElse
+import System.FilePath
+import System.Posix.Files
+import Control.Monad
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Map as M
+
+import Utility.SafeCommand
+import Utility.Process
+import Utility.Path
+import Utility.Path.AbsRel
+import Utility.Directory
+import Utility.Env
+import Utility.FileSystemEncoding
+import Build.BundledPrograms
+#ifdef darwin_HOST_OS
+import System.IO
+import Build.OSXMkLibs (mklibs)
+import Build.Version
+import Utility.Split
+#else
+import Build.LinuxMkLibs (mklibs)
+import Utility.FileMode
+#endif
+
+progDir :: FilePath -> FilePath
+#ifdef darwin_HOST_OS
+progDir topdir = topdir
+#else
+progDir topdir = topdir </> "bin"
+#endif
+
+extraProgDir :: FilePath -> FilePath
+extraProgDir topdir = topdir </> "extra"
+
+installProg :: FilePath -> FilePath -> IO (FilePath, FilePath)
+installProg dir prog = searchPath prog >>= go
+  where
+	go Nothing = error $ "cannot find " ++ prog ++ " in PATH"
+	go (Just f) = do
+		let dest = dir </> takeFileName f
+		unlessM (boolSystem "install" [File f, File dest]) $
+			error $ "install failed for " ++ prog
+		return (dest, f)
+
+installBundledPrograms :: FilePath -> IO (M.Map FilePath FilePath)
+installBundledPrograms topdir = M.fromList . concat <$> mapM go
+	[ (progDir topdir, preferredBundledPrograms)
+	, (extraProgDir topdir, extraBundledPrograms)
+	]
+  where
+	go (dir, progs) = do
+		createDirectoryIfMissing True dir
+		forM progs $ installProg dir
+
+installGitLibs :: FilePath -> IO ()
+installGitLibs topdir = do
+	-- install git-core programs; these are run by the git command
+	createDirectoryIfMissing True gitcoredestdir
+	execpath <- getgitpath "exec-path"
+	cfs <- dirContents execpath
+	forM_ cfs $ \f -> do
+		destf <- ((gitcoredestdir </>) . fromRawFilePath)
+			<$> relPathDirToFile
+				(toRawFilePath execpath)
+				(toRawFilePath f)
+		createDirectoryIfMissing True (takeDirectory destf)
+		issymlink <- isSymbolicLink <$> getSymbolicLinkStatus f
+		if issymlink
+			then do
+				-- many git-core files may symlink to eg
+				-- ../../bin/git, which is located outside
+				-- the git-core directory. The target of
+				-- such links is installed into the progDir
+				-- (if not already there), and the links
+				-- repointed to it.
+				--
+				-- Other git-core files symlink to a file
+				-- beside them in the directory. Those
+				-- links can be copied as-is.
+				linktarget <- readSymbolicLink f
+				if takeFileName linktarget == linktarget
+					then cp f destf
+					else do
+						let linktarget' = progDir topdir </> takeFileName linktarget
+						unlessM (doesFileExist linktarget') $ do
+							createDirectoryIfMissing True (takeDirectory linktarget')
+							L.readFile f >>= L.writeFile linktarget'
+						removeWhenExistsWith removeLink destf
+						rellinktarget <- relPathDirToFile
+							(toRawFilePath (takeDirectory destf))
+							(toRawFilePath linktarget')
+						createSymbolicLink (fromRawFilePath rellinktarget) destf
+			else cp f destf
+	
+	-- install git's template files
+	-- git does not have an option to get the path of these,
+	-- but they're architecture independent files, so are located
+	-- next to the --man-path, in eg /usr/share/git-core
+	manpath <- getgitpath "man-path"
+	let templatepath = manpath </> ".." </> "git-core" </> "templates"
+	tfs <- dirContents templatepath
+	forM_ tfs $ \f -> do
+		destf <- ((templatedestdir </>) . fromRawFilePath)
+			<$> relPathDirToFile
+				(toRawFilePath templatepath)
+				(toRawFilePath f)
+		createDirectoryIfMissing True (takeDirectory destf)
+		cp f destf
+  where
+	gitcoredestdir = topdir </> "git-core"
+	templatedestdir = topdir </> "templates"
+
+	getgitpath v = do
+		let opt = "--" ++ v
+		ls <- lines <$> readProcess "git" [opt]
+		case ls of
+			[] -> error $ "git " ++ opt ++ "did not output a location"
+			(p:_) -> return p
+
+cp :: FilePath -> FilePath -> IO ()
+cp src dest = do
+	removeWhenExistsWith removeLink dest
+	unlessM (boolSystem "cp" [Param "-a", File src, File dest]) $
+		error "cp failed"
+
+installMagic :: FilePath -> IO ()
+#ifdef darwin_HOST_OS
+installMagic topdir = getEnv "OSX_MAGIC_FILE" >>= \case
+	Nothing -> hPutStrLn stderr "OSX_MAGIC_FILE not set; not including it"
+	Just f -> do
+		let mdir = topdir </> "magic"
+		createDirectoryIfMissing True mdir
+		unlessM (boolSystem "cp" [File f, File (mdir </> "magic.mgc")]) $
+			error "cp failed"
+#else
+installMagic topdir = do
+	let mdir = topdir </> "magic"
+	createDirectoryIfMissing True mdir
+	unlessM (boolSystem "cp" [File "/usr/share/file/magic.mgc", File (mdir </> "magic.mgc")]) $
+		error "cp failed"
+#endif
+
+installLocales :: FilePath -> IO ()
+#ifdef darwin_HOST_OS
+installLocales _ = return ()
+#else
+installLocales topdir = cp "/usr/share/i18n" (topdir </> "i18n")
+#endif
+
+installSkel :: FilePath -> FilePath -> IO ()
+#ifdef darwin_HOST_OS
+installSkel _topdir basedir = do
+	whenM (doesDirectoryExist basedir) $
+		removeDirectoryRecursive basedir
+	createDirectoryIfMissing True (takeDirectory basedir)
+	unlessM (boolSystem "cp" [Param "-R", File "standalone/osx/git-annex.app", File basedir]) $
+		error "cp failed"
+#else
+installSkel topdir _basedir = do
+	whenM (doesDirectoryExist topdir) $
+		removeDirectoryRecursive topdir
+	createDirectoryIfMissing True (takeDirectory topdir)
+	unlessM (boolSystem "cp" [Param "-R", File "standalone/linux/skel", File topdir]) $
+		error "cp failed"
+#endif
+
+installSkelRest :: FilePath -> FilePath -> Bool -> IO ()
+#ifdef darwin_HOST_OS
+installSkelRest _topdir basedir _hwcaplibs = do
+	plist <- lines <$> readFile "standalone/osx/Info.plist.template"
+	version <- getVersion
+	writeFile (basedir </> "Contents" </> "Info.plist")
+		(unlines (map (expandversion version) plist))
+  where
+	expandversion v l = replace "GIT_ANNEX_VERSION" v l
+#else
+installSkelRest topdir _basedir hwcaplibs = do
+	runshell <- lines <$> readFile "standalone/linux/skel/runshell"
+	-- GIT_ANNEX_PACKAGE_INSTALL can be set by a distributor and
+	-- runshell will be modified
+	gapi <- getEnv "GIT_ANNEX_PACKAGE_INSTALL"
+	writeFile (topdir </> "runshell")
+		(unlines (map (expandrunshell gapi) runshell))
+	modifyFileMode
+		(toRawFilePath (topdir </> "runshell"))
+		(addModes executeModes)
+  where
+	expandrunshell (Just gapi) l@"GIT_ANNEX_PACKAGE_INSTALL=" = l ++ gapi
+	-- This is an optimisation, that avoids the linker looking in
+	-- several directories for hwcap optimised libs, when there are
+	-- none.
+	expandrunshell _ l@"LD_HWCAP_MASK=" = l ++ if not hwcaplibs
+		then "0"
+		else ""
+	expandrunshell _ l = l
+#endif
+
+installGitAnnex :: FilePath -> IO ()
+#ifdef darwin_HOST_OS
+installGitAnnex topdir = go topdir
+#else
+installGitAnnex topdir = go (topdir </> "bin")
+#endif
+  where
+	go bindir = do
+		createDirectoryIfMissing True bindir
+		unlessM (boolSystem "cp" [File "git-annex", File bindir]) $
+			error "cp failed"
+		unlessM (boolSystem "strip" [File (bindir </> "git-annex")]) $
+			error "strip failed"
+		createSymbolicLink "git-annex" (bindir </> "git-annex-shell")
+		createSymbolicLink "git-annex" (bindir </> "git-remote-tor-annex")
+
+main :: IO ()
+main = getArgs >>= go
+  where
+	go (topdir:basedir:[]) = do
+		installSkel topdir basedir
+		installGitAnnex topdir
+		installedbins <- installBundledPrograms topdir
+		installGitLibs topdir
+		installMagic topdir
+		installLocales topdir
+		hwcaplibs <- mklibs topdir installedbins
+		installSkelRest topdir basedir hwcaplibs
+	go _ = error "specify topdir and basedir"
diff --git a/Build/TestConfig.hs b/Build/TestConfig.hs
new file mode 100644
index 0000000000..5458612d4c
--- /dev/null
+++ b/Build/TestConfig.hs
@@ -0,0 +1,130 @@
+{- Tests the system and generates SysConfig. -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Build.TestConfig where
+
+import Utility.Path
+import Utility.Monad
+import Utility.SafeCommand
+import Utility.SystemDirectory
+
+import System.IO
+import System.FilePath
+
+type ConfigKey = String
+data ConfigValue =
+	BoolConfig Bool |
+	StringConfig String |
+	MaybeStringConfig (Maybe String) |
+	MaybeBoolConfig (Maybe Bool)
+data Config = Config ConfigKey ConfigValue
+
+type Test = IO Config
+type TestName = String
+data TestCase = TestCase TestName Test
+
+instance Show ConfigValue where
+	show (BoolConfig b) = show b
+	show (StringConfig s) = show s
+	show (MaybeStringConfig s) = show s
+	show (MaybeBoolConfig s) = show s
+
+instance Show Config where
+	show (Config key value) = unlines
+		[ key ++ " :: " ++ valuetype value
+		, key ++ " = " ++ show value
+		]
+	  where
+		valuetype (BoolConfig _) = "Bool"
+		valuetype (StringConfig _) = "String"
+		valuetype (MaybeStringConfig _) = "Maybe String"
+		valuetype (MaybeBoolConfig _) = "Maybe Bool"
+
+writeSysConfig :: [Config] -> IO ()
+writeSysConfig config = writeFile "Build/SysConfig" body
+  where
+	body = unlines $ header ++ map show config ++ footer
+	header = [
+		  "{- Automatically generated. -}"
+		, ""
+		]
+	footer = []
+
+runTests :: [TestCase] -> IO [Config]
+runTests [] = return []
+runTests (TestCase tname t : ts) = do
+	testStart tname
+	c <- t
+	testEnd c
+	rest <- runTests ts
+	return $ c:rest
+
+{- Checks if a command is available by running a command line. -}
+testCmd :: ConfigKey -> String -> Test
+testCmd k cmdline = do
+	ok <- boolSystem "sh" [ Param "-c", Param $ quiet cmdline ]
+	return $ Config k (BoolConfig ok)
+
+{- Ensures that one of a set of commands is available by running each in
+ - turn. The Config is set to the first one found. -}
+selectCmd :: ConfigKey -> [(String, String)] -> Test
+selectCmd k = searchCmd
+		(return . Config k . StringConfig)
+		(\cmds -> do
+			testEnd $ Config k $ BoolConfig False
+			error $ "* need one of these commands, but none are available: " ++ show cmds
+		)
+
+maybeSelectCmd :: ConfigKey -> [(String, String)] -> Test
+maybeSelectCmd k = searchCmd
+		(return . Config k . MaybeStringConfig . Just)
+		(\_ -> return $ Config k $ MaybeStringConfig Nothing)
+
+searchCmd :: (String -> Test) -> ([String] -> Test) -> [(String, String)] -> Test
+searchCmd success failure cmdsparams = search cmdsparams
+  where
+	search [] = failure $ fst $ unzip cmdsparams
+	search ((c, params):cs) = do
+		ok <- boolSystem "sh" [ Param "-c", Param $ quiet $ c ++ " " ++ params ]
+		if ok
+			then success c
+			else search cs
+
+{- Finds a command, either in PATH or perhaps in a sbin directory not in
+ - PATH. If it's in PATH the config is set to just the command name,
+ - but if it's found outside PATH, the config is set to the full path to
+ - the command. -}
+findCmdPath :: ConfigKey -> String -> Test
+findCmdPath k command = do
+	ifM (inSearchPath command)
+		( return $ Config k $ MaybeStringConfig $ Just command
+		, do
+			r <- getM find ["/usr/sbin", "/sbin", "/usr/local/sbin"]
+			return $ Config k $ MaybeStringConfig r
+		)
+  where
+	find d =
+		let f = d </> command
+		in ifM (doesFileExist f) ( return (Just f), return Nothing )
+
+quiet :: String -> String
+quiet s = s ++ " >/dev/null 2>&1"
+
+testStart :: TestName -> IO ()
+testStart s = do
+	putStr $ "  checking " ++ s ++ "..."
+	hFlush stdout
+
+testEnd :: Config -> IO ()
+testEnd (Config _ (BoolConfig True)) = status "yes"
+testEnd (Config _ (BoolConfig False)) = status "no"
+testEnd (Config _ (StringConfig s)) = status s
+testEnd (Config _ (MaybeStringConfig (Just s))) = status s
+testEnd (Config _ (MaybeStringConfig Nothing)) = status "not available"
+testEnd (Config _ (MaybeBoolConfig (Just True))) = status "yes"
+testEnd (Config _ (MaybeBoolConfig (Just False))) = status "no"
+testEnd (Config _ (MaybeBoolConfig Nothing)) = status "unknown"
+
+status :: String -> IO ()
+status s = putStrLn $ ' ':s
diff --git a/Build/Version.hs b/Build/Version.hs
new file mode 100644
index 0000000000..0d95dc7b26
--- /dev/null
+++ b/Build/Version.hs
@@ -0,0 +1,74 @@
+{- Package version determination. -}
+
+{-# LANGUAGE LambdaCase #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Build.Version where
+
+import Data.List
+import System.Environment
+import Data.Char
+import System.Process
+import Control.Applicative
+import Prelude
+
+import Utility.Monad
+import Utility.Exception
+import Utility.Misc
+
+type Version = String
+
+{- Set when making an official release. (Distribution vendors should set
+ - this too.) -}
+isReleaseBuild :: IO Bool
+isReleaseBuild = (== Just "1") <$> catchMaybeIO (getEnv "RELEASE_BUILD")
+
+{- Version comes from the CHANGELOG, plus the git rev of the last commit.
+ - This works for autobuilds, ad-hoc builds, etc.
+ -
+ - If git or a git repo is not available, or something goes wrong,
+ - or this is a release build, just use the version from the CHANGELOG. -}
+getVersion :: IO Version
+getVersion = do
+	changelogversion <- getChangelogVersion
+	ifM (isReleaseBuild)
+		( return changelogversion
+		, catchDefaultIO changelogversion $ do
+			gitversion <- takeWhile (\c -> isAlphaNum c) <$> readProcess "sh"
+				[ "-c"
+				, "git log -n 1 --format=format:'%H'"
+				] ""
+			return $ if null gitversion
+				then changelogversion
+				else concat
+					[ changelogversion
+					, "-g"
+					, gitversion
+					]
+		)
+	
+getChangelogVersion :: IO Version
+getChangelogVersion = do
+	changelog <- readFile "CHANGELOG"
+	let verline = takeWhile (/= '\n') changelog
+	return $ middle (words verline !! 1)
+  where
+	middle = drop 1 . init
+
+writeVersion :: Version -> IO ()
+writeVersion ver = catchMaybeIO (readFileStrict f) >>= \case
+	Just s | s == body -> return ()
+	_ -> writeFile f body
+  where
+	body = unlines $ concat
+		[ header
+		, ["packageversion :: String"]
+		, ["packageversion = \"" ++ ver ++ "\""]
+		, footer
+		]
+	header = [
+		  "{- Automatically generated. -}"
+		, ""
+		]
+	footer = []
+	f = "Build/Version"
diff --git a/Build/collect-ghc-options.sh b/Build/collect-ghc-options.sh
new file mode 100755
index 0000000000..4f75a7202e
--- /dev/null
+++ b/Build/collect-ghc-options.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+# Generate --ghc-options to pass LDFLAGS, CFLAGS, and CPPFLAGS through ghc
+# and on to ld, cc, and cpp.
+for w in $LDFLAGS; do
+	printf -- "-optl%s\n" "$w"
+done
+for w in $CFLAGS; do
+	printf -- "-optc%s\n" "$w"
+done
+for w in $CPPFLAGS; do
+	printf -- "-optc-Wp,%s\n" "$w"
+done
diff --git a/Build/mdwn2man b/Build/mdwn2man
new file mode 100755
index 0000000000..1eb0246a7d
--- /dev/null
+++ b/Build/mdwn2man
@@ -0,0 +1,58 @@
+#!/usr/bin/env perl
+# Warning: hack
+
+my $prog=shift;
+my $section=shift;
+
+print ".TH $prog $section\n";
+
+while (<>) {
+	s{(\\?)\[\[([^:\s\|\]]+)(\|[^\s\]]+)?\]\]}{$1 ? "[[$2]]" : $2}eg;
+	s/\`([^\`]*)\`/\\fB$1\\fP/g;
+	s/\`//g;
+	s/^ *\./\\&./g;
+	if (/^#\s/) {
+		s/^#\s/.SH /;
+		<>; # blank;
+	}
+	s/^[ \n]+//;
+	s/^\t/ /;
+	s/-/\\-/g;
+	s/git\\-annex/git-annex/g;
+	s/^Warning:.*mdwn2man.*//g;
+	s/^$/.PP\n/;
+	s/^\*\s+(.*)/.IP "$1"/;
+	s/\\$/\\\\/;
+	next if $_ eq ".PP\n" && $skippara;
+	if (/^.IP /) {
+		$inlist=1;
+		$spippara=0;
+	}
+	elsif (/^.SH/) {
+		$skippara=0;
+		$inlist=0;
+	}
+	elsif (/^\./) {
+		$skippara=1;
+	}
+	else {
+		$skippara=0;
+	}
+	if ($inlist && $_ eq ".PP\n") {
+		$_=".IP\n";
+	}
+
+	if ($inNAME) {
+		# make lexgrog happy
+		s/^git-annex (\w)/git-annex-$1/;
+	}
+	if ($_ eq ".SH NAME\n") {
+		$inNAME=1;
+	}
+	else {
+		$inNAME=0;
+	}
+	s/\\"/\\\\"/g; # hack for git-annex-shell's quotes around SSH_ORIGINAL_COMMAND
+
+	print $_;
+}
diff --git a/BuildFlags.hs b/BuildFlags.hs
new file mode 100644
index 0000000000..c02814f179
--- /dev/null
+++ b/BuildFlags.hs
@@ -0,0 +1,96 @@
+{- git-annex build flags
+ -
+ - Copyright 2013-2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module BuildFlags where
+
+import Data.List
+import Data.Ord
+import qualified Data.CaseInsensitive as CI
+
+buildFlags :: [String]
+buildFlags = filter (not . null)
+	[ ""
+#ifdef WITH_ASSISTANT
+	, "Assistant"
+#else
+#warning Building without the assistant.
+#endif
+#ifdef WITH_WEBAPP
+	, "Webapp"
+#else
+#warning Building without the webapp.
+#endif
+#ifdef WITH_PAIRING
+	, "Pairing"
+#else
+#warning Building without local pairing.
+#endif
+#ifdef WITH_INOTIFY
+	, "Inotify"
+#endif
+#ifdef WITH_FSEVENTS
+	, "FsEvents"
+#endif
+#ifdef WITH_KQUEUE
+	, "Kqueue"
+#endif
+#ifdef WITH_DBUS
+	, "DBus"
+#endif
+#ifdef WITH_DESKTOP_NOTIFY
+	, "DesktopNotify"
+#endif
+#ifdef WITH_TORRENTPARSER
+	, "TorrentParser"
+#endif
+#ifdef WITH_MAGICMIME
+	, "MagicMime"
+#endif
+#ifdef WITH_BENCHMARK
+	, "Benchmark"
+#endif
+#ifdef DEBUGLOCKS
+	, "DebugLocks"
+#endif
+	-- Always enabled now, but users may be used to seeing these flags
+	-- listed.
+	, "Feeds"
+	, "Testsuite"
+	, "S3"
+	, "WebDAV"
+	]
+
+-- Not a complete list, let alone a listing transitive deps, but only
+-- the ones that are often interesting to know.
+dependencyVersions :: [String]
+dependencyVersions = map fmt $ sortBy (comparing (CI.mk . fst))
+	[ ("feed", VERSION_feed)
+	, ("uuid", VERSION_uuid)
+	, ("bloomfilter", VERSION_bloomfilter)
+	, ("http-client", VERSION_http_client)
+	, ("persistent-sqlite", VERSION_persistent_sqlite)
+#ifdef WITH_CRYPTON
+	, ("crypton", VERSION_crypton)
+#else
+	, ("cryptonite", VERSION_cryptonite)
+#endif
+	, ("aws", VERSION_aws)
+	, ("DAV", VERSION_DAV)
+#ifdef WITH_TORRENTPARSER
+	, ("torrent", VERSION_torrent)
+#endif
+#ifdef WITH_WEBAPP
+	, ("yesod", VERSION_yesod)
+#endif
+#ifdef TOOL_VERSION_ghc
+	, ("ghc", TOOL_VERSION_ghc)
+#endif
+	]
+  where
+	fmt (p, v) = p ++ "-" ++ v
diff --git a/BuildInfo.hs b/BuildInfo.hs
new file mode 100644
index 0000000000..f0a61cb242
--- /dev/null
+++ b/BuildInfo.hs
@@ -0,0 +1,16 @@
+{- git-annex build info
+ -
+ - Copyright 2013-2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module BuildInfo where
+
+-- This file is generated by the configure program with the results of its
+-- probing.
+#include "Build/SysConfig"
+-- This file is automatically generated from the CHANGELOG version
+#include "Build/Version"
diff --git a/CHANGELOG b/CHANGELOG
new file mode 100644
index 0000000000..859c006268
--- /dev/null
+++ b/CHANGELOG
@@ -0,0 +1,8332 @@
+git-annex (10.20240430) upstream; urgency=medium
+
+  * Bug fix: While redundant concurrent transfers were already
+    prevented in most cases, it failed to prevent the case where
+    two different repositories were sending the same content to
+    the same repository.
+  * addurl, importfeed: Added --verifiable option, which improves
+    the safety of --fast or --relaxed by letting the content of
+    annexed files be verified with a checksum that is calculated
+    on a later download from the web. This will become the default later.
+  * Added rclone special remote, which can be used without needing
+    to install the git-annex-remote-rclone program. This needs
+    a forthcoming version of rclone (1.67.0), which supports 
+    "rclone gitannex".
+  * sync, assist, import: Allow -m option to be specified multiple
+    times, to provide additional paragraphs for the commit message.
+  * reregisterurl: New command that can change an url from being
+    used by a special remote to being used by the web remote.
+  * annex.maxextensions configuration controls how many filename
+    extensions to preserve.
+  * find: Fix --help for --copies.
+    Thanks, Gergely Risko
+  * Windows: Fix escaping output to terminal when using old
+    versions of MinTTY.
+  * Added dependency on unbounded-delays.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 30 Apr 2024 15:26:32 -0400
+
+git-annex (10.20240227) upstream; urgency=medium
+
+  * importfeed: Added --scrape option, which uses yt-dlp to screen scrape
+    the equivilant of an RSS feed.
+  * importfeed --force: Don't treat it as a failure when an already
+    downloaded file exists. (Fixes a behavior change introduced in
+    10.20230626.)
+  * importfeed --force: Avoid creating duplicates of existing
+    already downloaded files when yt-dlp or a special remote was used.
+  * addurl, importfeed: Added --raw-except option.
+  * stack.yaml: Update to lts-22.9 and use crypton.
+  * assistant, undo: When committing, let the usual git commit
+    hooks run.
+  * Added annex.commitmessage-command config.
+  * pre-commit: Avoid committing the git-annex branch
+    (except when a commit is made in a view, which changes metadata).
+  * Pass --no-warnings to yt-dlp.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 27 Feb 2024 12:58:30 -0400
+
+git-annex (10.20240129) upstream; urgency=medium
+
+  * info: Added "annex sizes of repositories" table to the overall display.
+  * import: Sped up import from special remotes.
+  * import: Added --message/-m option.
+  * Support using commands that implement the Stateless OpenPGP command line
+    interface, as an alternative to gpg.
+    Currently only supported for encryption=shared special remotes,
+    when annex.shared-sop-command is configured.
+  * test: Test a specified Stateless OpenPGP command when
+    run with eg --test-git-config annex.shared-sop-command=sqop
+  * Improve disk free space checking when transferring unsized keys to
+    local git remotes.
+  * Added configs annex.stalldetection-download, annex.stalldetection-upload,
+    annex.bwlimit-download, annex.bwlimit-upload,
+    and similar per-remote configs.
+  * Improve annex.stalldetection to handle remotes that update progress
+    less frequently than the configured time period.
+  * external: Monitor file size when getting content from external
+    special remotes and use that to update the progress meter,
+    in case the external special remote program does not report progress.
+  * Added --expected-present file matching option.
+  * webapp: Added --port option, and annex.port config.
+  * assistant: When generating a gpg secret key, avoid hardcoding the
+    key algorithm and size.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 29 Jan 2024 13:12:00 -0400
+
+git-annex (10.20231227) upstream; urgency=medium
+
+  * migrate: Support distributed migrations by recording each migration,
+    and adding a --update option that updates the local repository
+    incrementally, hard linking annex objects to their new keys.
+  * pull, sync: When operating on content, automatically handle
+    distributed migrations.
+  * Added annex.syncmigrations config that can be set to false to prevent
+    pull and sync from migrating object content.
+  * migrate: Added --apply option that (re)applies all recorded 
+    distributed migrations to the objects in repository.
+  * migrate: Support adding size to URL keys that were added with
+    --relaxed, by running eg: git-annex migrate --backend=URL foo
+  * When importing from a special remote, support preferred content
+    expressions that use terms that match on keys (eg "present", "copies=1").
+    Such terms are ignored when importing, since the key is not known yet.
+    Before, such expressions caused the import to fail.
+  * Support git-annex copy/move --from-anywhere --to remote.
+  * Make git-annex get/copy/move --from foo override configuration of 
+    remote.foo.annex-ignore, as documented.
+  * Lower precision of timestamps in git-annex branch, which can reduce the
+    size of the branch by up to 8%.
+  * sync: Fix locking problems during merge when annex.pidlock is set.
+  * Avoid a problem with temp file names ending in "." on certian
+    filesystems that have problems with such filenames.
+  * sync, push: Avoid trying to send individual files to special remotes
+    configured with importtree=yes exporttree=no, which would always fail.
+  * Fix a crash opening sqlite databases when run in a non-unicode locale.
+    (Needs persistent-sqlite 2.13.3.)
+
+ -- Joey Hess <id@joeyh.name>  Wed, 27 Dec 2023 19:27:37 -0400
+
+git-annex (10.20231129) upstream; urgency=medium
+
+  * Fix bug in git-annex copy --from --to that skipped files that were
+    locally present.
+  * Make git-annex copy --from --to --fast actually fast.
+  * Fix crash of enableremote when the special remote has embedcreds=yes.
+  * Ignore directories and other unusual files in .git/annex/journal/
+  * info: Added calculation of combined annex size of all repositories.
+  * log: Added options --sizesof, --sizes and --totalsizes that
+    display how the size of repositories changed over time.
+  * log: Added options --interval, --bytes, --received, and --gnuplot
+    to tune the output of the above added options.
+  * findkeys: Support --largerthan and --smallerthan.
+  * importfeed: Use caching database to avoid needing to list urls
+    on every run, and avoid using too much memory.
+  * Improve memory use of --all when using annex.private.
+  * lookupkey: Sped up --batch.
+  * Windows: Consistently avoid ending standard output lines with CR.
+    This matches the behavior of git on Windows.
+  * Windows: Fix CRLF handling in some log files.
+  * Windows: When git-annex init is installing hook scripts, it will
+    avoid ending lines with CR for portability. Existing hook scripts
+    that do have CR line endings will not be changed.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 29 Nov 2023 15:59:20 -0400
+
+git-annex (10.20230926) upstream; urgency=medium
+
+  * Fix more breakage caused by git's fix for CVE-2022-24765, this time
+    involving a remote (either local or ssh) that is a repository not owned
+    by the current user.
+  * Fix using git remotes that are bare when git is configured with 
+    safe.bareRepository = explicit.
+  * Fix linker optimisation in linux standalone tarballs.
+  * adb: Avoid some problems with unusual characters in exporttree 
+    filenames that confuse adb shell commands.
+  * push: When on an adjusted branch, propagate changes to parent branch
+    before updating export remotes.
+  * lookupkey: Added --ref option.
+  * enableremote: Avoid overwriting existing git remote when passed the uuid
+    of a specialremote that was earlier initialized with the same name.
+  * Support being built with crypton rather than the no-longer maintained 
+    cryptonite.
+  * Removed the vendored git-lfs and the GitLfs build flag.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 26 Sep 2023 13:23:37 -0400
+
+git-annex (10.20230828) upstream; urgency=medium
+
+  * oldkeys: New command that lists the keys used by old versions of a file.
+  * Fix behavior of onlyingroup.
+  * info: Added --dead-repositories option. 
+  * Significant startup speed increase by avoiding repeatedly checking
+    if some remote git-annex branch refs need to be merged.
+  * Fix behavior when importing a tree from a directory remote when the
+    directory does not exist. An empty tree was imported, rather than the
+    import failing.
+  * sync, assist, push, pull: Skip more types of remotes when they
+    are not available due to eg being on a drive that is offline.
+    (directory, borg, bup, ddar, gcrypt, rsync)
+  * info: Added available to the info displayed for a remote.
+  * Added AVAILABILITY UNAVAILABLE and the UNAVAILABLERESPONSE extension
+    to the external special remote protocol.
+  * The remote.name.annex-availability git config is no longer used.
+  * Avoid using curl when annex.security.allowed-ip-addresses is set
+    but neither annex.web-options nor annex.security.allowed-url-schemes
+    is set to a value that needs curl.
+  * Stop bundling curl in the OSX dmg and linux standalone image.
+  * diffdriver: Added --get option.
+  * diffdriver: Refuse to run when not in a git-annex repository.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 28 Aug 2023 12:40:37 -0400
+
+git-annex (10.20230802) upstream; urgency=medium
+
+  * satisfy: New command that gets/sends/drops content to satisfy
+    preferred content settings. This is like to the --content
+    part of git-annex sync.
+  * --explain: New option to display explanations of what git-annex
+    takes into account when deciding what to do. Including explaining
+    matching of preferred content expressions, annex.largefiles, and 
+    annex.addunlocked.
+  * reinject: Added --guesskeys option.
+  * diffdriver: Added --text option for easy diffing of the contents of
+    annexed text files.
+  * assist: With --jobs, parallelize transferring content to/from remotes.
+  * Bug fix: Re-running git-annex adjust or sync when in an adjusted branch
+    would overwrite the original branch, losing any commits that had been
+    made to it since the adjusted branch was created.
+  * Bug fix: Fix behavior when git is configured with 
+    safe.bareRepository = explicit.
+  * importfeed bug fix: When -J was used with multiple feeds, some feeds
+    did not get their items downloaded.
+  * importfeed: Add feedurl to the metadata (and allow it to be used in the
+    --template)
+  * Improve resuming interrupted download when using yt-dlp.
+  * S3: Amazon S3 buckets created after April 2023 do not support ACLs,
+    so public=yes cannot be used with them. Existing buckets configured
+    with public=yes will keep working.
+  * S3: Allow setting publicurl=yes without public=yes, to support
+    buckets that are configured with a Bucket Policy that allows public
+    access.
+  * directory, gcrypt: Remove empty hash directories when dropping content.
+  * dropunused: Support --jobs
+  * Support "onlyingroup=" in preferred content expressions.
+  * Support --onlyingroup= matching option.
+  * Setup.hs: Stop installing man pages, desktop files, and the
+    git-annex-shell and git-remote-tor-annex symlinks.
+    Anything still relying on that, eg via cabal v1-install will need to
+    change to using make install-home.
+  * Support building with unix-compat 0.7
+  * Support building with unix-2.8.0.
+  * stack.yaml: Update to build with ghc-9.6.2 and aws-0.24.
+    (For windows, stack-lts-18.13.yaml has to be used instead for now.)
+
+ -- Joey Hess <id@joeyh.name>  Wed, 02 Aug 2023 13:55:30 -0400
+
+git-annex (10.20230626) upstream; urgency=medium
+
+  * Split out two new commands, git-annex pull and git-annex push.
+    Those plus a git commit are equivalent to git-annex sync.
+    (Note that the new commands default to syncing content, unless
+    annex.synccontent is explicitly set to false.)
+  * assist: New command, which is the same as git-annex sync but with
+    new files added and content transferred by default.
+  * sync: Started a transition to --content being enabled by default.
+    When used without --content or --no-content, warn about the upcoming
+    transition, and suggest using one of the options, or setting
+    annex.synccontent.
+  * sync: Added -g as a short option for --no-content.
+  * Many commands now quote filenames that contain unusual characters the
+    same way that git does, to avoid exposing control characters to the
+    terminal.
+  * Support core.quotePath, which can be set to false to display utf8
+    characters as-is in filenames.
+  * Control characters in non-filename data coming from the repository or
+    other possible untrusted sources are filtered out of the display of many
+    commands. When the command output is intended for use in scripting,
+    control characters are only filtered out when displaying to the
+    terminal.
+  * find, findkeys, examinekey: When outputting to a terminal and --format
+    is not used, quote control characters. Output to a pipe is unchanged.
+    (Similar to the behavior of GNU find.)
+  * addurl --preserve-filename now rejects filenames that contain other
+    control characters, besides the escape sequences it already rejected.
+  * init: Avoid autoenabling special remotes that have control characters
+    in their names.
+  * Support core.sharedRepository=0xxx at long last.
+  * Support --json and --json-error-messages in many more commands
+    (addunused, configremote, dead, describe, dropunused, enableremote,
+    expire, fix, importfeed, init, initremote, log, merge, migrate, reinit,
+    reinject, rekey, renameremote, rmurl, semitrust, setpresentkey, trust,
+    unannex, undo, uninit, untrust, unused, upgrade)
+  * importfeed: Support -J
+  * importfeed: Support --json-progress
+  * httpalso: Support being used with special remotes that use chunking.
+  * Several significant speedups to importing large trees from special
+    remotes. Imports that took over an hour now take only a few minutes.
+  * Cache negative lookups of global numcopies and mincopies. 
+    Speeds up eg git-annex sync --content by up to 50%.
+  * Speed up sync in an adjusted branch by avoiding re-adjusting the branch
+    unnecessarily, particularly when it is adjusted with --hide-missing
+    or --unlock-present.
+  * config: Added the --show-origin and --for-file options.
+  * config: Support annex.numcopies and annex.mincopies.
+  * whereused: Fix display of branch:file when run in a subdirectory.
+  * enableremote: Support enableremote of a git remote (that was previously
+    set up with initremote) when additional parameters such as autoenable=
+    are passed.
+  * configremote: New command, currently limited to changing autoenable=
+    setting of a special remote.
+  * Honor --force option when operating on a local git remote.
+  * When a nonexistant file is passed to a command and 
+    --json-error-messages is enabled, output a JSON object indicating the
+    problem. (But git ls-files --error-unmatch still displays errors about
+    such files in some situations.)
+  * Bug fix: Create .git/annex/, .git/annex/fsckdb,
+    .git/annex/sentinal, .git/annex/sentinal.cache, and
+    .git/annex/journal/* with permissions configured by core.sharedRepository.
+  * Bug fix: Lock files were created with wrong modes for some combinations
+    of core.sharedRepository and umask.
+  * initremote: Avoid creating a remote that is not encrypted when gpg is
+    broken.
+  * log: When --raw-date is used, display only seconds from the epoch, as
+    documented, omitting a trailing "s" that was included in the output
+    before.
+  * addunused: Displays the names of the files that it adds.
+  * reinject: Fix support for operating on multiple pairs of files and keys.
+  * sync: Fix buggy handling of --no-pull and --no-push when syncing
+    --content. With --no-pull, avoid downloading content, and with
+    --no-push avoid uploading content. This was done before, but
+    inconsistently.
+  * uninit: Avoid buffering the names of all annexed files in memory.
+  * Fix bug in -z handling of trailing NUL in input.
+  * version: Avoid error message when entire output is not read.
+  * Fix excessive CPU usage when parsing yt-dlp (or youtube-dl) progress
+    output fails.
+  * Use --progress-template with yt-dlp to fix a failure to parse
+    progress output when only an estimated total size is known.
+  * When yt-dlp is available, default to using it in preference to
+    youtube-dl. Using youtube-dl is now deprecated, and git-annex no longer
+    tries to parse its output to display download progress
+  * Improve resuming interrupted download when using yt-dlp or youtube-dl.
+  * assistant: Add dotfiles to git by default, unless annex.dotfiles
+    is configured, the same as git-annex add does.
+  * assistant --autostop: Avoid crashing when ~/.config/git-annex/autostart
+    lists a directory that it cannot chdir to.
+  * Fix display when run with -J1.
+  * assistant: Fix a crash when a small file is deleted immediately after
+    being created.
+  * repair: Fix handling of git ref names on Windows.
+  * repair: Fix a crash when .git/annex/journal/ does not exist.
+  * Support building with optparse-applicative 0.18.1
+    (Thanks, Peter Simons)
+
+ -- Joey Hess <id@joeyh.name>  Mon, 26 Jun 2023 10:37:36 -0400
+
+git-annex (10.20230407) upstream; urgency=medium
+
+  * Fix laziness bug introduced in last release that breaks use
+    of --unlock-present and --hide-missing adjusted branches.
+  * Support user.useConfigOnly git config.
+  * registerurl, unregisterurl: Added --remote option.
+  * registerurl: When an url is claimed by a special remote other than the
+    web, update location tracking for that special remote.
+    (This was the behavior before version 6.20181011)
+  * Sped up sqlite inserts 2x when built with persistent 2.14.5.0
+  * git-annex.cabal: Prevent building with unix-compat 0.7 which
+    removed System.PosixCompat.User.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 07 Apr 2023 13:36:23 -0400
+
+git-annex (10.20230329) upstream; urgency=medium
+
+  * sync: Fix parsing of gcrypt::rsync:// urls that use a relative path.
+  * Avoid failure to update adjusted branch --unlock-present after git-annex
+    drop when annex.adjustedbranchrefresh=1
+  * Avoid leaving repo with a detached head when there is a failure
+    checking out an updated adjusted branch.
+  * view: Support annex.maxextensionlength when generating filenames for
+    the view branch.
+  * Windows: Support urls like "file:///c:/path"
+  * addurl, importfeed: Fix failure when annex.securehashesonly is set.
+  * Copy with a reflink when exporting a tree to a directory special remote.
+  * Fix bug that caused broken protocol to be used with external remotes
+    that use exporttree=yes. In some cases this could result in the wrong
+    content being exported to, or retrieved from the remote.
+  * Support VERSION 2 in the external special remote protocol, which is
+    identical to VERSION 1, but avoids external remote programs needing
+    to work around the above bug. External remote program that support
+    exporttree=yes are recommended to be updated to send VERSION 2.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 29 Mar 2023 13:29:07 -0400
+
+git-annex (10.20230321) upstream; urgency=medium
+
+  * Using git-annex view in an adjusted branch, or git-annex adjust in a
+    view branch, will enter an adjusted view branch.
+  * sync: Fix a reversion that prevented sending files to exporttree=yes
+    remotes when annex-tracking-branch was configured to branch:subdir
+    (Introduced in version 10.20230214)
+  * status: This command is deprecated because it was only needed in direct
+    mode; git status --short is very similar.
+  * Windows: Support long filenames in more (possibly all) of the code.
+  * Added arm64 build for ancient kernels, needed to support Android phones
+    whose kernels are too old to support kernels used by the current arm64
+    build.
+  * importfeed: Display feed title.
+  * init: Support being ran in a repository that has a newline in its path.
+  * copy: When --from and --to are combined and the content is already
+    present on the destination remote, update location tracking as
+    necessary.
+  * Fixed spelling of some messages and added a .codespellrc
+    Thanks, Yaroslav Halchenko
+
+ -- Joey Hess <id@joeyh.name>  Tue, 21 Mar 2023 16:13:46 -0400
+
+git-annex (10.20230227) upstream; urgency=medium
+
+  * Fix more breakage caused by git's fix for CVE-2022-24765, this time
+    involving a remote that is a local bare repository not owned by the
+    current user.
+  * info: Fix reversion in last release involving handling of unsupported
+    input by continuing to handle any other inputs, before exiting nonzero
+    at the end.
+  * git-annex.cabal: Move webapp build deps under the Assistant build flag
+    so git-annex can be built again without yesod etc installed.
+  * Improve error message when unable to read a sqlite database due to
+    permissions problem.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 27 Feb 2023 12:23:12 -0400
+
+git-annex (10.20230214) upstream; urgency=medium
+
+  * sync: Fix a bug that caused files to be removed from an 
+    importtree=yes exporttree=yes special remote when the remote's
+    annex-tracking-branch was not the currently checked out branch.
+  * S3: Support a region= configuration useful for some non-Amazon S3
+    implementations. This feature needs git-annex to be built with aws-0.24.
+  * view: New field?=glob and ?tag syntax that includes a directory "_"
+    in the view for files that do not have the specified metadata set.
+  * Added annex.viewunsetdirectory git config to change the name of the
+    "_" directory in a view.
+  * Changed the name of view branches to include the parent branch.
+    Existing view branches checked out using an old name will still work.
+  * sync: Avoid pushing view branches to remotes.
+  * sync: When run in a view branch, refresh the view branch to reflect any
+    changes that have been made to the parent branch or metadata.
+  * sync: When run in a view branch, avoid updating synced/ branches,
+    or trying to merge anything from remotes.
+  * Support http urls that contain ":" that is not followed by a port
+    number, the same as git does.
+  * sync: Warn when the adjusted basis ref cannot be found, as happens eg when
+    the user has renamed branches.
+  * Sped up view branch construction by 50%.
+  * info, enableremotemote, renameremote: Avoid a confusing message when more
+    than one repository matches the user provided name.
+  * info: Exit nonzero when the input is not supported.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 14 Feb 2023 14:07:11 -0400
+
+git-annex (10.20230126) upstream; urgency=medium
+
+  * Change --metadata comparisons < > <= and >= to fall back to
+    lexicographical comparisons when one or both values being compared
+    are not numbers.
+  * Improve handling of some .git/annex/ subdirectories being on other
+    filesystems, in the bittorrent special remote, and youtube-dl
+    integration, and git-annex addurl.
+  * Added --anything (and --nothing). Eg, git-annex find --anything
+    will list all annexed files whether or not the content is present.
+    This is slightly faster and clearer than --include=* or --exclude=*
+  * Speed up git-annex upgrade (from v5) and init in a repository that has
+    submodules.
+  * Added libgcc_s.so.1 to the linux standalone build so pthread_cancel
+    will work.
+  * Speed up initial scanning for annexed files when built
+    with persistent-2.14.4.1
+  * Allow initremote of additional special remotes with type=web,
+    in addition to the default web special remote. When --sameas=web is used,
+    these provide additional names for the web special remote, and may
+    also have their own additional configuration and cost.
+  * web: Add urlinclude and urlexclude configuration settings.
+  * Added an optional cost= configuration to all special remotes.
+  * adb: Support the remote.name.cost and remote.name.cost-command configs.
+  * findkeys: New command, very similar to git-annex find but operating on
+    keys.
+  * move, copy: Support combining --from and --to, which will send content
+    from one remote across to another remote.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 26 Jan 2023 15:26:22 -0400
+
+git-annex (10.20221212) upstream; urgency=medium
+
+  * Fix a hang that occasionally occurred during commands such as move,
+    when operating on unlocked files. (A bug introduced in 10.20220927)
+  * When youtube-dl is not available in PATH, use yt-dlp instead.
+  * Support parsing yt-dpl output to display download progress.
+  * init: Avoid scanning for annexed files, which can be lengthy in a
+    large repository. Instead that scan is done on demand.
+  * Sped up the initial scan for annexed files by 21%.
+  * test: Add --test-debug option.
+  * Support quettabyte and yottabyte.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 12 Dec 2022 12:20:06 -0400
+
+git-annex (10.20221104) upstream; urgency=medium
+
+  * export: Fix a bug that left a file on a special remote when
+    two files with the same content were both deleted in the exported tree.
+  * S3: Support signature=anonymous to access a S3 bucket anonymously.
+    This can be used, for example, with importtree=yes to import from
+    a public bucket.
+    This feature needs git-annex to be built with aws-0.23.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 03 Nov 2022 14:07:31 -0400
+
+git-annex (10.20221103) upstream; urgency=medium
+
+  * Doubled the speed of git-annex drop when operating on many files,
+    and of git-annex get when operating on many tiny files.
+  * trust, untrust, semitrust, dead: Fix behavior when provided with
+    multiple repositories to operate on.
+  * trust, untrust, semitrust, dead: When provided with no parameters,
+    do not operate on a repository that has an empty name.
+  * move: Fix openFile crash with -J
+    (Fixes a reversion in 8.20201103)
+  * S3: Speed up importing from a large bucket when fileprefix= is set,
+    by only asking for files under the prefix.
+  * When importing from versioned remotes, fix tracking of the content
+    of deleted files.
+  * More robust handling of ErrorBusy when writing to sqlite databases.
+  * Avoid hanging when a suspended git-annex process is keeping a sqlite
+    database locked.
+  * Make --batch mode handle unstaged annexed files consistently
+    whether the file is unlocked or not. Note that this changes the
+    behavior of --batch when it is provided with locked files that are
+    in the process of being added to the repository, but have not yet been
+    staged in git.
+  * Make git-annex enable-tor work when using the linux standalone build.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 03 Nov 2022 14:07:31 -0400
+
+git-annex (10.20221003) upstream; urgency=medium
+
+  * Avoid displaying warning about git-annex restage needing to be run
+    in situations where it does not.
+  * Fix the annex.adviceNoSshCaching config, which has never worked.
+    Thanks, Reiko Asakura
+
+ -- Joey Hess <id@joeyh.name>  Mon, 03 Oct 2022 12:38:48 -0400
+
+git-annex (10.20220927) upstream; urgency=medium
+
+  * Fix a bug in the last release that caused v8 repositories to upgrade
+    immediately to v10, rather than taking the scheduled 1 year to do so.
+  * annex.diskreserve default increased from 1 mb to 100 mb.
+  * Include the assistant and webapp when building with cabal 3.4.1.0.
+  * Merged the webapp build flag into the assistant build flag.
+  * Optimise linker in linux standalone tarballs.
+  * Fix crash importing from a directory special remote that contains
+    a broken symlink.
+  * When accessing a git remote over http needs a git credential
+    prompt for a password, cache it for the lifetime of the git-annex
+    process, rather than repeatedly prompting.
+  * Use curl for downloads from git remotes when annex.url-options is set.
+  * Fix a reversion that made dead keys not be skipped when operating on
+    all keys via --all or in a bare repo.
+    (Introduced in version 8.20200720)
+  * vicfg: Include mincopies configuration.
+  * Improve handling of directory special remotes with importtree=yes whose
+    ignoreinode setting has been changed. When getting a file from such a
+    remote, accept the content that would have been accepted with the
+    previous ignoreinode setting.
+  * directory, adb: Fixed a bug with importtree=yes and multiple files
+    in the special remote have the same content, that caused it to
+    refuse to get a file from the special remote, incorrectly complaining
+    that it had changed, due to only accepting the inode+mtime of one file
+    (that was since modified or deleted) and not accepting the inode+mtime
+    of other duplicate files.
+  * Fix a reversion that prevented git-annex from working in a
+    repository when --git-dir or GIT_DIR is specified to relocate the git
+    directory to somewhere else.
+    (Introduced in version 10.20220525)
+  * Improved handling of --time-limit when combined with -J
+  * Fix updating git index file after getting an unlocked file 
+    when annex.stalldetection is set.
+  * restage: New git-annex command, handles restaging unlocked files.
+  * test: Added --test-git-config option.
+  * Run annex.freezecontent-command and annex.thawcontent-command
+    when on a crippled filesystem.
+    Thanks, Reiko Asakura
+  * enable-tor: Fix breakage caused by git's fix for CVE-2022-24765.
+  * Let GIT_DIR and --git-dir override git's protection against operating
+    in a repository owned by another user.
+  * p2p: Pass wormhole the --appid option before the receive/send command,
+    as it does not accept that option after the command
+  * Support "inbackend" in preferred content expressions.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 27 Sep 2022 13:31:18 -0400
+
+git-annex (10.20220822) upstream; urgency=medium
+
+  * v8 repositories now automatically upgrade to v9, which will in turn
+    automatically upgrade to v10 in a year's time.
+    To avoid this upgrade, you can set annex.autoupgraderepository to false.
+  * Now uses v10 by default for new repositories.
+  * Fix a regression in 10.20220624 that caused git-annex add to crash
+    when there was an unstaged deletion.
+  * Added new matching options --want-get-by and --want-drop-by.
+  * Allow find --branch to be used in a bare repository, the same as
+    the deprecated findref can be.
+  * add --dry-run: New option. 
+  * import: Avoid following symbolic links inside directories being
+    imported.
+  * Work around bug in git 2.37 that causes a segfault
+    when core.untrackedCache is set, which broke git-annex init.
+  * Added annex.dbdir config which can be used to move sqlite databases
+    to a different filesystem than the git-annex repo, when the repo is on
+    a filesystem that sqlite does not work well in.
+  * Use curl when annex.security.allowed-url-schemes includes an url
+    scheme not supported by git-annex internally, as long as
+    annex.security.allowed-ip-addresses is configured to allow using curl.
+  * Improve output when storing to bup.
+  * When bup split fails, display its stderr.
+  * Avoid running multiple bup split processes concurrently, since
+    bup is not concurrency safe.
+  * Avoid starting an unnecessary number of git hash-object processes when 
+    concurrency is enabled.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 22 Aug 2022 11:56:06 -0400
+
+git-annex (10.20220724) upstream; urgency=medium
+
+  * filter-process: Fix a bug involving handling of empty files,
+    that caused git to kill git-annex filter-process.
+  * add: Fix reversion when adding an annex link that has been moved to
+    another directory. (Introduced in version 10.20220624)
+  * Added annex.alwayscompact setting which can be unset to speed up
+    writes to the git-annex branch in some cases. See its documentation
+    for important notes on when it's appropariate to use.
+  * adb: Added configuration setting oldandroid=true to avoid using
+    find -printf, which was first supported in Android around 2019-2020.
+    This may need to be enabled for old android devices that used to work
+    without it being set, since version 10.20220222 started using 
+    find -printf.
+  * --backend is no longer a global option, and is only accepted by
+    commands that actually need it.
+  * Improve handling of parallelization with -J when copying content
+    from/to a git remote that is a local path.
+  * S3: Avoid writing or checking the uuid file in the S3 bucket when
+    importtree=yes or exporttree=yes.
+  * Fix a reversion that prevented --batch commands (and the assistant)
+    from noticing data written to the journal by other commands.
+  * Fix building with the Assistant build flag disabled but the Webapp
+    build flag enabled.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 25 Jul 2022 12:55:38 -0400
+
+git-annex (10.20220624) upstream; urgency=medium
+
+  * init: Added --no-autoenable option.
+  * info: Added --autoenable option.
+  * initremote: Improve handling of type=git special remotes.
+    The location value no longer needs to match the url of an existing
+    git remote, and locations not using ssh:// will work now, including
+    both paths and host:/path
+  * Fix retrival of an empty file that is stored in a special remote with 
+    chunking enabled.
+    (Fixes a reversion in 8.20201103)
+  * move: Improve resuming a move that succeeded in transferring the
+    content, but where dropping failed due to eg a network problem, 
+    in cases where numcopies checks prevented the resumed
+    move from dropping the object from the source repository.
+  * add, fix, lock, rekey: When several files were being processed, 
+    replacing an annex symlink of a file that was already processed
+    with a new large file could sometimes cause that large file to be
+    added to git. These races have been fixed.
+  * add: Also fix a similar race that could cause a large file be added
+    to git when a small file was modified or overwritten while it was
+    being added.
+  * add --batch: Fix handling of a file that is skipped due to being
+    gitignored.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 23 Jun 2022 13:31:22 -0400
+
+git-annex (10.20220525) upstream; urgency=medium
+
+  * Special remotes with importtree=yes or exporttree=yes are once again
+    treated as untrusted, since files stored in them can be deleted or
+    modified at any time.
+    (Fixes a reversion in 8.20201129)
+  * Added support for "megabit" and related bandwidth units
+    in annex.stalldetection and everywhere else that git-annex parses
+    data units. Note that the short form is "Mbit" not "Mb" because
+    that differs from "MB" only in case, and git-annex parses units
+    case-insensitively.
+  * Special remotes using exporttree=yes and/or importtree=yes now
+    checksum content while it is being retrieved, instead of in a separate
+    pass at the end.
+  * fsck: Fix situations where the annex object file is stored in a
+    directory structure other than where annex symlinks point to.
+  * Deal with git's recent changes to fix CVE-2022-24765, which prevent
+    using git in a repository owned by someone else.
+  * Improve an error message displayed in that situation.
+  * Prevent git-annex init incorrectly reinitializing the repository in
+    that situation.
+  * test: When limiting tests to run with -p, work around tasty limitation
+    by automatically including dependent tests.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 25 May 2022 13:44:46 -0400
+
+git-annex (10.20220504) upstream; urgency=medium
+
+  * Ignore annex.numcopies set to 0 in gitattributes or git config,
+    or by git-annex numcopies or by --numcopies, since that
+    configuration would make git-annex easily lose data. 
+    Same for mincopies.
+  * assistant: When annex.autocommit is set, notice commits that
+    the user makes manually, and push them out to remotes promptly.
+  * multicast: Support uftp 5.0 by switching from aes256-cbc to
+    aes256-gcm.
+  * Fix test failure on NFS when cleaning up gpg temp directory.
+  * Fix a build failure with ghc 9.2.2.
+    Thanks, gnezdo for the patch.
+  * rsync 3.2.4 broke backwards-compatability by preventing exposing
+    filenames to the shell. Made the rsync and gcrypt special remotes
+    detect this and disable shellescape. Closes: #1010397
+  * repair: Avoid treating refs/annex/last-index or other refs that
+    are not commit objects as evidence of repository corruption.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 04 May 2022 11:45:27 -0400
+
+git-annex (10.20220322) upstream; urgency=medium
+
+  * Directory special remotes with importtree=yes have changed to once more 
+    take inodes into account. This will cause extra work when importing
+    from a directory on a FAT filesystem that changes inodes on every
+    mount. To avoid that extra work, set ignoreinodes=yes when initializing
+    a new directory special remote, or change the configuration of your
+    existing remote:
+      git-annex enableremote foo ignoreinodes=yes
+  * add: Avoid unncessarily converting a newly unlocked file to be stored
+    in git when it is not modified, even when annex.largefiles does not
+    match it.
+  * The above change to add fixes a reversion in version 10.20220222,
+    where git-annex unlock followed by git-annex add, followed by git
+    commit file could result in git thinking the file was modified
+    after the commit.
+  * Detect when an unlocked file whose content is not present has gotten
+    some other content appended to it, and avoid treating it as a pointer
+    file, so that appended content will not be checked into git, but will
+    be annexed like any other file.
+  * smudge: Warn when encountering a pointer file that has other content
+    appended to it.
+  * When annex.freezecontent-command is set, and the filesystem does not
+    support removing write bits, avoid treating it as a crippled
+    filesystem.
+  * Run annex.thawcontent-command before deleting an object file,
+    in case annex.freezecontent-command did something that would prevent
+    deletion.
+  * Fix propagation of nonzero exit status from git ls-files when a specified
+    file does not exist, or a specified directory does not contain
+    any files checked into git.
+  * Fix build with aeson 2.0.
+    Thanks, sternenseemann for the patch.
+  * Avoid git-annex test being very slow when run from within the
+    standalone linux tarball or OSX app.
+  * test: Runs tests in parallel to speed up the test suite.
+  * test: Added --jobs option.
+  * Removed vendored copy of http-client-restricted, and removed the
+    HttpClientRestricted build flag that avoided that dependency.
+  * Removed the NetworkBSD build flag.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 22 Mar 2022 13:56:12 -0400
+
+git-annex (10.20220222) upstream; urgency=medium
+
+  * annex.skipunknown now defaults to false, so commands like
+    `git annex get foo*` will not silently skip over files/dirs that are
+    not checked into git.
+  * info: Allow using matching options in more situations. File matching
+    options like --include will be rejected in situations where there is
+    no filename to match against.
+  * adb: Avoid find failing with "Argument list too long"
+  * Fix git-annex forget propagation between repositories.
+    (reversion introduced in version 7.20190122)
+  * registerurl, unregisterurl: Improved output when reading from stdin
+    to be more like other batch commands.
+  * registerurl, unregisterurl: Added --json and --json-error-messages options.
+  * Avoid git status taking a long time after git-annex unlock of many files.
+  * Pass --no-textconv when running git diff internally.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 22 Feb 2022 13:01:20 -0400
+
+git-annex (10.20220127) upstream; urgency=medium
+
+  * New v10 repository version (with v9 as a stepping-stone to it).
+    v8 remains the default version for now.
+  * In v10, object files are locked using separate lock files. This allows
+    the object files to be kept non-writable even in repositories where
+    core.sharedRepository is set.
+  * The v10 upgrade will happen automatically, one year after the v9
+    upgrade, in order to allow time for any old git-annex processes that
+    are not aware of the locking change to finish. Or git-annex upgrade
+    can be used to upgrade to v10 immediately.
+  * In v9 upgrade, set filter.annex.process. This makes git add/checkout faster
+    when there are a lot of unlocked annexed files or non-annexed files, but can
+    also make git add of large files to the annex somewhat slower.
+    If this tradeoff does not work for your use case, you can still unset
+    filter.annex.process.
+  * export: When a non-annexed symlink is in the tree to be exported, skip it.
+  * import: When the previously exported tree contained a non-annexed symlink,
+    preserve it in the imported tree so it does not get deleted.
+  * enableremote, renameremote: Better handling of the unusual case where
+    multiple special remotes have been initialized with the same name.
+  * Recover from corrupted content being received from a git remote,
+    by deleting the temporary file when it fails to verify. This prevents
+    a retry from failing again. 
+    (reversion introduced in version 8.20210903)
+  * adb: Added ignorefinderror configuration parameter.
+  * Avoid crashing when run in a bare git repo that somehow contains an
+    index file.
+  * Reject combinations of --batch (or --batch-keys) with options like
+    --all or --key or with filenames.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 27 Jan 2022 13:25:19 -0400
+
+git-annex (8.20211231) upstream; urgency=medium
+
+  * Improved support for using git-annex in a read-only repository,
+    git-annex branch information from remotes that cannot be merged into
+    the git-annex branch will now not crash it, but will be merged in
+    memory.
+  * addurl, youtube-dl: When --check-raw prevents downloading an url,
+    still continue with any downloads that come after it, rather than
+    erroring out.
+  * Fix locking problems when annex.pidlock is set and concurrency is
+    enabled eg with -J.
+  * Improve error message display when autoinit fails due to eg, a
+    permissions problem.
+  * export: Avoid unncessarily re-exporting non-annexed files that were
+    already exported.
+  * Improve git command queue flushing so that eg, addurl of several
+    large files that take time to download will update the index for each
+    file, rather than deferring the index updates to the end.
+  * sync: Better error message when unable to export to a remote because
+    remote.name.annex-tracking-branch is configured to a ref that does not
+    exist.
+  * Fix build with ghc 9.0.1
+  * Fix build with old versions of feed library.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 31 Dec 2021 15:03:36 -0400
+
+git-annex (8.20211123) upstream; urgency=medium
+
+  * Bugfix: When -J was enabled, getting files could leak an
+    ever-growing number of git cat-file processes.
+  * Support git's new "ort" resolver, which became the default in git 2.34.0,
+    and broke the test suite and automatic merge resolution of a conflict
+    between an annexed file and a non-annexed file.
+  * importfeed: Display url before starting youtube-dl download.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 23 Nov 2021 15:19:16 -0400
+
+git-annex (8.20211117) upstream; urgency=medium
+
+  * filter-process: New command that can make git add/checkout faster when
+    there are a lot of unlocked annexed files or non-annexed files, but that
+    also makes git add of large annexed files slower. Use it by running:
+    git config filter.annex.process 'git-annex filter-process'
+  * Fix a typo in the name of youtube-dl
+    (reversion introduced in version 8.20210903)
+  * git-lfs: Fix interoperability with gitlab's implementation of the
+    git-lfs protocol, which requests Content-Encoding chunked.
+  * importfeed: Fix a crash when used in a non-unicode locale.
+  * migrate: New --remove-size option.
+  * uninit: Avoid error message when no commits have been made to the
+    repository yet.
+  * uninit: Avoid error message when there is no git-annex branch.
+  * metadata --batch: Avoid crashing when a non-annexed file is input,
+    instead output a blank line like other batch commands do.
+  * metadata --batch --json: Reject input whose "fields" does not consist
+    of arrays of strings. Such invalid input used to be silently ignored.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 17 Nov 2021 12:18:49 -0400
+
+git-annex (8.20211028) upstream; urgency=medium
+
+  * Removed support for accessing git remotes that use versions of
+    git-annex older than 6.20180312.
+  * git-annex-shell: Removed several commands that were only needed to
+    support git-annex versions older than 6.20180312.
+  * Negotiate P2P protocol version with tor remotes, allowing
+    use of protocol version 1. This negotiation is not supported
+    by versions of git-annex older than 6.20180312.
+  * Fix bug that caused stale git-annex branch information to read
+    when annex.private or remote.name.annex-private is set.
+  * git-annex get when run as the first git-annex command in a new repo
+    did not populate all unlocked files.
+    (Reversion in version 8.20210621)
+  * Fix using lookupkey and info inside a subdirectory of the git repository.
+    (Reversion in version 8.20211011)
+  * Avoid some sqlite crashes on Windows SubSystem for Linux (WSL).
+  * Call annex.freezecontent-command on the annex object file
+    after it has been moved into place in annex/objects/. This allows
+    the hook to freeze the file in ways that prevent moving it, such as
+    removing the Windows delete permission.
+    Thanks, Reiko Asakura.
+  * addurl: Support adding the same url to multiple files at the same
+    time when using -J with --batch --with-files.
+  * When retrieval from a chunked remote fails, display the error that
+    occurred when downloading the chunk, rather than the error that
+    occurred when trying to download the unchunked content, which is less
+    likely to actually be stored in the remote.
+  * Avoid crashing tilde expansion on user who does not exist.
+  * test: Put gpg temp home directory in system temp directory,
+    not filesystem being tested.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 28 Oct 2021 11:58:29 -0400
+
+git-annex (8.20211011) upstream; urgency=medium
+
+  * Added annex.bwlimit and remote.name.annex-bwlimit config to limit
+    the bandwidth of transfers. It works for git remotes and many
+    but not all special remotes.
+  * Bug fix: Git configs such as annex.verify were incorrectly overriding
+    per-remote git configs such as remote.name.annex-verify.
+    (Reversion in version 4.20130323)
+  * borg: Significantly improved memory use when a borg repository
+    contains many archives.
+  * borg: Avoid trying to extract xattrs, ACLS, and bsdflags when
+    retrieving from a borg repository.
+  * Sped up git-annex smudge --clean by 25%.
+  * Resume where it left off when copying a file to/from a local git remote
+    was interrupted.
+  * sync --content: Avoid a redundant checksum of a file that was
+    incrementally verified, when used on NTFS and perhaps other filesystems.
+  * reinject: Fix crash when reinjecting a file from outside the repository.
+    (Reversion in version 8.20210621)
+  * Avoid cursor jitter when updating progress display.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 11 Oct 2021 12:52:14 -0400
+
+git-annex (8.20210903) upstream; urgency=medium
+
+  * Deal with clock skew, both forwards and backwards, when logging
+    information to the git-annex branch.
+  * GIT_ANNEX_VECTOR_CLOCK can now be set to a fixed value (eg 1)
+    rather than needing to be advanced each time a new change is made.
+  * Misuse of GIT_ANNEX_VECTOR_CLOCK will no longer confuse git-annex.
+  * add: When adding a dotfile, avoid treating its name as an extension.
+  * rsync special remote: Stop displaying rsync progress, and use
+    git-annex's own progress display.
+  * Many special remotes now checksum content while it is being retrieved,
+    instead of in a separate pass at the end. This is supported for all
+    special remotes on Linux (except for bittorrent), and for many
+    on other OS's (except for adb, external, gcrypt, hook, and rsync).
+  * unused: Skip the refs/annex/last-index ref that git-annex recently
+    started creating.
+  * Fix test suite failure on Windows.
+  * New --batch-keys option added to these commands: 
+    get, drop, move, copy, whereis
+  * Added annex.youtube-dl-command config. This can be used to run some
+    forks of youtube-dl.
+  * Run cp -a with --no-preserve=xattr, to avoid problems with copied
+    xattrs, including them breaking permissions setting on some NFS
+    servers.
+  * add, import: Detect when xattrs or perhaps ACLs prevent removing
+    write permissions from an annexed file, and fail with an informative
+    message.
+  * Fix support for readonly git remotes.
+    (Reversion in version 8.20210621)
+  * When downloading urls fail, explain which urls failed for which
+    reasons.
+  * web: Avoid displaying a warning when downloading one url failed
+    but another url later succeeded.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 03 Sep 2021 12:00:46 -0400
+
+git-annex (8.20210803) upstream; urgency=medium
+
+  * whereused: New command, finds what files use a key, or where a key
+    was used historically.
+  * Fix a bug that prevented getting content from a repository that
+    started out as a bare repository, or had annex.crippledfilesystem
+    set, and was converted to a non-bare repository.
+  * Fix retrieval of content from borg repos accessed over ssh.
+  * sync: When --quiet is used, run git commit, push, and pull without
+    their ususual output.
+  * merge: When --quiet is used, run git merge without its usual output.
+  * sync, merge, post-receive: Avoid merging unrelated histories,
+    which used to be allowed only to support direct mode repositories.
+    (However, sync does still merge unrelated histories when importing
+    trees from special remotes, and the assistant still merges unrelated
+    histories.)
+  * sync, merge: Added --allow-unrelated-histories option, which
+    is the same as the git merge option.
+  * Fix bug that caused some transfers to incorrectly fail with
+    "content changed while it was being sent", when the content was not
+    changed.
+  * Fix bug that could prevent pointer files from being populated,
+    in a repository that was upgraded from v7.
+  * fsck: Detect and correct stale or missing inode caches.
+  * Fix a rounding bug in display of data sizes.
+  * git-annex get when run as the first git-annex command in a new repo
+    did not populate unlocked files.
+    (Reversion in version 8.20210621)
+
+ -- Joey Hess <id@joeyh.name>  Tue, 03 Aug 2021 12:20:09 -0400
+
+git-annex (8.20210714) upstream; urgency=medium
+
+  * assistant: Avoid unnecessary git repository repair in a situation where
+    git fsck gets confused about a commit that is made while it's running.
+  * addurl: Avoid crashing when used on beegfs.
+  * --debug output goes to stderr again, not stdout.
+    (Reversion in version 8.20210428)
+  * init: Fix misbehavior when core.sharedRepository = group that
+    caused it to enter an adjusted branch and set annex.crippledfilesystem
+    (Reversion in version 8.20210630)
+  * assistant: When adding non-large files to git, honor annex.delayadd
+    configuration. Also, don't add non-large files to git when they
+    are still being written to.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 14 Jul 2021 12:22:55 -0400
+
+git-annex (8.20210630) upstream; urgency=medium
+
+  * Fixed bug that interrupting git-annex repair (or assistant) while
+    it was fixing repository corruption would lose objects that were
+    contained in pack files. Also the assistant might sometimes have
+    crashed with the same result.
+  * repair: Fix reversion in version 8.20200522 that prevented fetching
+    missing objects from remotes.
+  * sync: Partly work around github behavior that first branch to be pushed
+    to a new repository is assumed to be the head branch, by not pushing
+    synced/git-annex first.
+  * Added annex.freezecontent-command and annex.thawcontent-command
+    configs.
+  * Improve display of errors when transfers fail.
+  * Dropping an unused object with drop --unused or dropunused will
+    mark it as dead, preventing fsck --all from complaining about it
+    after it's been dropped from all repositories.
+  * addurl, importfeed: Added --no-raw option that forces download
+    with youtube-dl or a special remote. In particular this can avoid
+    falling back to raw download when youtube-dl is blocked for some
+    reason.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 30 Jun 2021 11:48:16 -0400
+
+git-annex (8.20210621) upstream; urgency=medium
+
+  * New matching options --excludesamecontent and --includesamecontent
+  * When two files have the same content, and a required content expression
+    matches one but not the other, dropping the latter file will fail as it
+    would also remove the content of the required file.
+  * drop, move, mirror: When two files have the same content, and
+    different numcopies or requiredcopies values, use the higher value.
+  * drop --auto: When two files have the same content, and a preferred content
+    expression matches one but not the other, do not drop the content.
+  * sync --content, assistant: When two unlocked files have the same
+    content, and a preferred content expression matches one but not the
+    other, do not drop the content. (This was already the case for locked
+    files.)
+  * sync --content, assistant: Fix an edge case where a file that is not
+    preferred content did not get dropped.
+  * filter-branch: New command, useful to produce a filtered version of the
+    git-annex branch, eg when splitting a repository.
+  * fromkey: Create an unlocked file when used in an adjusted branch
+    where the file should be unlocked, or when configured by annex.addunlocked.
+  * Fix behavior of several commands, including reinject, addurl, and rmurl
+    when given an absolute path to an unlocked file, or a relative path
+    that leaves and re-enters the repository.
+  * smudge: Fix a case where an unlocked annexed file that annex.largefiles
+    does not match could get its unchanged content checked into git,
+    due to git running the smudge filter unecessarily.
+  * reinject: Error out when run on a file that is not annexed, rather
+    than silently skipping it.
+  * assistant: Fix a crash on startup by avoiding using forkProcess.
+  * init: When annex.commitmessage is set, use that message for the commit
+    that creates the git-annex branch.
+  * Added annex.adviceNoSshCaching config.
+  * Added --size-limit option.
+  * Future proof activity log parsing.
+  * Fix an exponential slowdown when large numbers of duplicate files are
+    being added in unlocked form.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 21 Jun 2021 12:17:24 -0400
+
+git-annex (8.20210428) upstream; urgency=medium
+
+  * New annex.private and remote.name.annex-private configs that can
+    prevent storing information about a repository and remotes in the
+    git-annex branch.
+  * initremote: Added --private option to set up a private special remote.
+  * importfeed: Made "checking known urls" phase run 12 times faster.
+  * Added --debugfilter (and annex.debugfilter)
+  * diffdriver: Support unlocked files.
+  * forget: Preserve currently exported trees, avoiding problems with
+    exporttree remotes in some unusual circumstances.
+  * fsck: When downloading content from a remote, if the content is able
+    to be verified during the transfer, skip checksumming it a second time.
+  * directory: When cp supports reflinks, use it.
+  * Avoid excess commits to the git-annex branch when stall detection is
+    enabled.
+  * git-annex-config: Allow setting annex.securehashesonly, which has
+    otherwise been supported since 2019, but was missing from the list of
+    allowed repo-global configs.
+  * init: Fix a crash when the repo's was cloned from a repo that had an
+    adjusted branch checked out, and the origin remote is not named "origin".    
+  * Fix some bugs that made git-annex not see recently recorded status
+    information when configured with annex.alwayscommit=false.
+  * When mincopies is set to a larger value than numcopies, make sure that
+    mincopies is satisfied. Before, it assumed a sane configuration would
+    have numcopies larger or equal to mincopies. It's still a good idea
+    not to configure git-annex this way.
+  * Avoid more than 1 gpg password prompt at the same time, which
+    could happen occasionally before when concurrency is enabled.
+  * Fix build with persistent-2.12.0.1
+
+ -- Joey Hess <id@joeyh.name>  Wed, 28 Apr 2021 12:13:24 -0400
+
+git-annex (8.20210330) upstream; urgency=medium
+
+  * Behavior change: When autoenabling special remotes of type S3, weddav,
+    or glacier, do not take login credentials from environment variables,
+    as the user may not be expecting the autoenable to happen, or may
+    have those set for other purposes and not intend git-annex to use them.
+  * New annex.supportunlocked config that can be set to false to avoid
+    some expensive things needed to support unlocked files, if you do not
+    use them.
+  * Fix bug importing from a special remote into a subdirectory more than
+    one level deep, which generated unusual git trees that could confuse
+    git merge.
+  * borg: Fix a bug that prevented importing keys of type URL and WORM.
+  * borg: Support importing files that are hard linked in the borg backup.
+  * export: When a submodule is in the tree to be exported, skip it.
+  * import: When the previously exported tree contained a submodule,
+    preserve it in the imported tree so it does not get deleted.
+  * export --json: Fill in the file field.
+  * rmurl: When youtube-dl was used for an url, it no longer needs to be
+    prefixed with "yt:" in order to be removed.
+  * rmurl: If an url is both used by the web and also claimed by another
+    special remote, fix a bug that caused the url to to not be removed.
+  * unregisterurl: Fix a bug that caused an url to not be unregistered
+    when it is claimed by a special remote other than the web.
+  * whereis: Don't include yt: prefix when showing url to content
+    retrieved with youtube-dl.
+  * webdav: Work around some buggy webdav server behavior involving
+    renaming files.
+  * Make --debug also enable debugging in child git-annex processes.
+  * fsck: When --from is used in combination with --all or similar options,
+    do not verify required content, which can't be checked properly when
+    operating on keys.
+  * Sped up git-annex init in a clone of an existing repository.
+  * Improved display of errors when accessing a git http remote fails.
+  * Fix build with attoparsec-0.14.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 30 Mar 2021 13:01:17 -0400
+
+git-annex (8.20210310) upstream; urgency=medium
+
+  * When non-annexed files in a tree are exported to a special remote,
+    importing from the special remote keeps the files non-annexed,
+    as long as their content has not changed, rather than converting
+    them to annexed files. 
+    (Such a conversion will still happen when importing from a remote
+    an old git-annex exported such a tree to before; export the tree
+    with the new git-annex before importing to avoid that.)
+  * Added support for git-remote-gcrypt's rsync URIs, which access a remote
+    using rsync over ssh, and which git pushes to much more efficiently
+    than ssh urls.
+  * unregisterurl: New command.
+  * registerurl: Allow it to be used in a bare repository.
+  * Prevent combinations of options such as --all with --include.
+  * Fixed handling of --mimetype or --mimeencoding combined with
+    options like --all or --unused.
+  * Fix handling of --branch combined with --unlocked or --locked.
+  * Fix support for local gcrypt repositories with a space in their URI.
+  * uninit: Fix a small bug that left a lock file in .git/annex
+  * Windows: Correct the path to the html help file for 64 bit build.
+  * OSX dmg: Updated bundled git to 2.30.2 which fixes CVE-2021-21300.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 10 Mar 2021 13:58:15 -0400
+
+git-annex (8.20210223) upstream; urgency=medium
+
+  * annex.stalldetection can now be set to "true" to make git-annex
+    do automatic stall detection when it detects a remote is updating its
+    transfer progress consistently enough for stall detection to work.
+  * When annex.stalldetection is not enabled and a likely stall is
+    detected, display a suggestion to enable it.
+  * Commands can be added to git-annex, by installing a program in PATH
+    with a name starting with "git-annex-"
+  * Fix a reversion that made import of a tree from a special remote
+    result in a merge that deleted files that were not preferred content
+    of that special remote.
+  * Bugfix: fsck --from a ssh remote did not actually check that the
+    content on the remote is not corrupted.
+  * unannex, uninit: When an annexed file is modified, don't overwrite
+    the modified version with an older version from the annex.
+  * When adding files to an adjusted branch set up by --unlock-present,
+    add them unlocked, not locked.
+  * Fix an oddity in matching options and preferred content expressions
+    such as "foo (bar or baz)", which was incorrectly handled as if
+    it were "(foo or bar) and baz)" rather than the intended
+    "foo and (bar or baz)"
+  * Checksum as content is received from a remote git-annex repository,
+    rather than doing it in a second pass.
+  * Tahoe: Avoid verifying hash after download, since tahoe does sufficient
+    verification itself.
+  * unannex, uninit: Don't run git rm once per annexed file, 
+    for a large speedup.
+  * When a git remote is configured with an absolute path, use that
+    path, rather than making it relative.
+  * get: Improve output when failing to get a file fails.
+  * Fix build on openbsd.
+    Thanks, James Cook for the patch.
+  * Include libkqueue.h file needed to build the assistant on BSDs.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 23 Feb 2021 14:40:14 -0400
+
+git-annex (8.20210127) upstream; urgency=medium
+
+  * Added mincopies configuration. This is like numcopies, but is
+    enforced even more strictly. While numcopies can be violated in
+    concurrent drop situations involving special remotes that do not
+    support locking, mincopies cannot be. The default value has always
+    been 1, but now it can be set to higher values if desired.
+  * Behavior change: When numcopies is set to 0, git-annex used to drop
+    content without requiring any copies. Now to get that (highly unsafe)
+    behavior, mincopies also needs to be set to 0.
+  * Behavior change: git-annex trust now needs --force, since unconsidered
+    use of trusted repositories can lead to data loss.
+  * Behavior change: --trust and --trust-glacier options no longer overrides
+    trust, since that can lead to data loss, which should never be enabled
+    by an option other than --force.
+  * add: Significantly speed up adding lots of non-large files to git,
+    by disabling the annex smudge filter when running git add.
+  * add --force-small: Run git add rather than updating the index itself,
+    so any other smudge filters than the annex one that may be enabled will
+    be used.
+  * Fix --time-limit, which got broken in several ways by some optimisations
+    in version 8.20201007.
+  * When syncing changes back from an adjusted branch to the basis branch,
+    include deletions of submodules.
+    Thanks, Kyle Meyer for the patch.
+  * Bug fix: export with -J could fail when two files had the same content.
+  * Bug fix: Fix tilde expansion in ssh urls when the tilde is the last
+    character in the url.
+    Thanks, Grond for the patch.
+  * Avoid crashing when there are remotes using unparseable urls.
+    Including the non-standard URI form that git-remote-gcrypt uses for rsync.
+  * Directory special remotes with importtree=yes now avoid unnecessary
+    hashing when inodes of files have changed, as happens whenever a FAT
+    filesystem gets remounted.
+  * Fix a bug that prevented git-annex init from working in a submodule.
+  * Fix a bug in view filename generation when a metadata value ended with
+    "/" (or ":" or "\" on Windows)
+  * adjust: Fix some bad behavior when unlocked files use URL keys.
+  * smudge: Fix some bad behavior when git add is run on an unlocked
+    file that used an URL key.
+  * Added GETGITREMOTENAME to external special remote protocol.
+  * Windows: Work around win32 length limits when dealing with lock files.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 27 Jan 2021 11:09:25 -0400
+
+git-annex (8.20201129) upstream; urgency=medium
+
+  * New borg special remote. This is a new kind of remote, that examines
+    borg backups of git-annex repositories, learns what files have been
+    backed up, and can restore files from the backup and so on. As well
+    as backups, it can be useful for archival storage, since borg can
+    efficiently store many related versions of files.
+  * New config annex.stalldetection, remote.name.annex-stalldetection,
+    which can be used to deal with remotes that stall during transfers,
+    or are sometimes too slow to want to use.
+  * Support special remotes that are configured with importtree=yes but
+    without exporttree=yes.
+  * Fix bug that made the next download after an empty file from a ssh
+    or tor remote fail.
+  * Avoid spurious "verification of content failed" message when downloading
+    content from a ssh or tor remote fails due to the remote no longer
+    having a copy of the content.
+  * Fix bug that matched include= and exclude= in preferred/required content
+    expressions relative to the current directory, rather than the path
+    from the top of the repository.
+    (Reversion introduced in version 8.20201116.)
+  * Fix hang on shutdown of external special remote using ASYNC protocol
+    extension. 
+    (Reversion introduced in version 8.20201007.)
+  * Guard against running in a repo where annex.uuid is set but
+    annex.version is not set, or vice-versa.
+  * Avoid autoinit when a repo does not have annex.version or annex.uuid
+    set, but has a git-annex objects directory, suggesting it was used
+    by git-annex before, and the git config may have been lost.
+  * importfeed: Avoid using youtube-dl when a feed does not contain an
+    enclosure, but only a link to an url which youtube-dl does not support.
+  * initremote: Prevent enabling encryption with exporttree=yes or 
+    importtree=yes.
+  * Windows: include= and exclude= containing '/' will also match filenames
+    that are written using '\'. (And vice-versa, but it's better to use '/'
+    for portability.)
+  * Fix a bug that could prevent getting files from an importtree=yes
+    remote, because the imported tree was allowed to be garbage collected.
+  * stack.yaml: Updated to lts-16.27.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 29 Dec 2020 12:52:58 -0400
+
+git-annex (8.20201127) upstream; urgency=medium
+
+  * adjust: New --unlock-present mode which locks files whose content is not
+    present (so the broken symlink is visible), while unlocking files whose
+    content is present.
+  * Added annex.adjustedbranchrefresh git config to update adjusted
+    branches set up by git-annex adjust --unlock-present/--hide-missing.
+  * Fix hang when an external special remote program exited but
+    the stderr pipe to it was left open, due to a daemon having inherited
+    the file descriptor.
+  * Fix a bug that could make resuming a download from the web fail
+    when the entire content of the file is actually already present
+    locally.
+  * examinekey: Added a "file" format variable for consistency with find,
+    and for easier scripting.
+  * init: When writing hook scripts, set all execute bits, not only
+    the user execute bit.
+  * upgrade: Support an edge case upgrading a v5 direct mode repo
+    where nothing had ever been committed to the head branch.
+  * Made the test suite significantly less noisy, only displaying command
+    output when something failed.
+  * Fix building without the torrent library.
+    Thanks, Kyle Meyer.
+  * Fix build on Windows.
+  * Prevent windows assistant from trying (and failing) to upgrade
+    itself, which has never been supported on windows.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 27 Nov 2020 12:54:11 -0400
+
+git-annex (8.20201116) upstream; urgency=medium
+
+  * move: Fix a regression in the last release that made move --to not
+    honor numcopies settings.
+  * sync --content: Fix a bug where a file that was not preferred content
+    could be transferred to a remote. This happened when the file got deleted
+    after the sync started running.
+  * Warn when adding a annex symlink or pointer file that uses a key that
+    is not known to the repository, to prevent confusion if the user has
+    copied it from some other repository.
+  * examinekey: Added two new format variables: objectpath and objectpointer
+  * examinekey: Added --migrate-to-backend
+
+ -- Joey Hess <id@joeyh.name>  Mon, 16 Nov 2020 09:36:35 -0400
+
+git-annex (8.20201103) upstream; urgency=medium
+
+  * move: Improve resuming a move that was interrupted after the object
+    was transferred, in cases where numcopies checks prevented the resumed
+    move from dropping the object from the source repository.
+  * When a special remote has chunking enabled, but no chunk sizes are
+    recorded (or the recorded ones are not found), speculatively try
+    chunks using the configured chunk size.
+  * Fixed some problems that prevented this command from working:
+    git submodule foreach git annex init
+  * Improve shutdown process for external special remotes and external
+    backends. Make sure to relay any remaining stderr from the process,
+    and potentially avoid the process getting a SIGPIPE if it writes to
+    stderr too late.
+  * Fix a bug that prevented linux standalone bundle from working on a fresh
+    install.
+  * Windows build changed to one done by the datalad-extensions project
+    using Github actions.
+  * Windows build now includes libmagic, so mimetype and mimeencoding
+    will work.
+    Thanks to John Thorvald Wodder II and Yaroslav Halchenko for their work
+    on this.
+  * view: Avoid using ':' from metadata when generating a view, because
+    it's a special character on Windows ("c:")
+  * Fix a memory leak introduced in the last release.
+  * add, import: Fix a reversion in 7.20191009 that broke handling
+    of --largerthan and --smallerthan.
+  * view: Fix a reversion in 8.20200522 that broke entering or changing views.
+  * Fix build on Windows with network-3.
+  * testremote: Display exceptions when tests fail, to aid debugging.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 03 Nov 2020 11:40:56 -0400
+
+git-annex (8.20201007) upstream; urgency=medium
+
+  * --json output now includes a new field "input" which is the input
+    value (filename, url, etc) that caused a json object to be output.
+  * --batch combined with -J now runs batch requests concurrently for many
+    commands. Before, the combination was accepted, but did not enable
+    concurrency. Since the output of batch requests can be in any order,
+    --json with the new "input" field is recommended to be used,
+    to determine which batch request each response corresponds to.
+  * aws-0.22 improved its support for setting etags, which improves
+    support for versioned S3 buckets.
+  * Serialize use of C magic library, which is not thread safe.
+    This fixes failures uploading to S3 when using -J.
+  * add, addurl, importfeed, import: Added --no-check-gitignore option
+    for finer grained control than using --force.
+  * import: Check gitignores when importing trees from special remotes.
+  * addunused: Don't check .gitignores when adding files.
+  * Improve the "Try making some of these repositories available"
+    message, with some hints for the user for what to do.
+  * Improve --debug output to show pid of processes that are started and
+    stopped.
+  * sync --all: Sped up seeking to around twice as fast, by avoiding a
+    pass over the worktree files when preferred content expressions of the
+    local repo and remotes don't use include=/exclude=.
+  * Sped up seeking for files to operate on, when using options like
+    --copies or --in, by around 20%
+  * import --no-content: Check annex.largefiles, and import small
+    files into git, the same as is done when importing with content.
+    If the largefiles expression needs the file content available
+    (due to mimetype or mimeencoding being used), the import will fail.
+  * sync: When run without --content, import without copying from
+    importtree=yes directory special remotes.
+    (Other special remotes may support this later as well.)
+  * addurl: Avoid a redundant git ignores check for speed.
+  * upgrade: Avoid an upgrade failure of a bare repo in unusual circumstances.
+  * httpalso: Support being used with special remotes that do not have
+    encryption= in their config.
+  * Parse youtube-dl progress output, which lets progress be displayed
+    when doing concurrent downloads.
+  * Fix build with Benchmark build flag.
+  * Enable building with git-annex benchmark by default, only turning it
+    off when the criterion library is not installed.
+  * runshell: Fix a edge case where rm errors were sent to stdout, which
+    could confuse things parsing git-annex output.
+  * runshell: Update files atomically when preparing to run git-annex.
+  * Fix a build failure on Windows.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 07 Oct 2020 12:19:05 -0400
+
+git-annex (8.20200908) upstream; urgency=medium
+
+  * Added httpalso special remote, which is useful for accessing 
+    content stored on other remotes that is published by http.
+  * The external special remote protocol got an ASYNC extension.
+    This can be used by an external special remote to let a single process
+    perform concurrent actions, rather than multiple processes being
+    started, when that is more efficient.
+  * Retry transfers to exporttree=yes remotes same as for other remotes.
+  * import: Retry downloads that fail, same as is done for downloads generally.
+  * Limit retrying of failed transfers when forward progress is being made
+    to 5, to avoid some unusual edge cases where too much retrying could
+    result in far more data transfer than makes sense.
+  * Exposed annex.forward-retry git config, to configure the forward retry
+    behavior that git-annex has had for a long time.
+  * sync, assistant, merge: When merge.directoryRenames is not set,
+    default it it to "false", which works better with automatic merge
+    conflict resolution than git's ususual default of "conflict".
+    (This is not done when automatic merge conflict resolution is disabled.)
+  * resolvemerge: Improve cleanup of cruft left in the working tree 
+    by a conflicted merge.
+  * Support git remotes where .git is a file, not a directory,
+    eg when --separate-git-dir was used.
+  * Fixed several cases where files were created without file mode bits
+    that the umask would usually set. This included exports to the
+    directory special remote, torrent files used by the bittorrent special
+    remote, hooks written by git-annex init, and some log files in .git/annex/
+  * Fix reversion in 7.20190322 that made addurl --file not be honored
+    when youtube-dl was used to download media.
+  * Fix reversion in 8.20200617 that made annex.pidlock being enabled
+    result in some commands stalling, particularly those needing to
+    autoinit.
+  * Display warning when external special remote does not start up
+    properly, or is not usable.
+  * Display a message when git-annex has to wait for a pid lock file
+    held by another process.
+  * test: Stop gpg-agent daemons that are started for the test framework's
+    gpg key.
+  * Removed the S3 and WebDAV build flags so these special remotes are
+    always supported.
+  * stack.yaml: Updated to lts-16.10.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 08 Sep 2020 14:20:11 -0400
+
+git-annex (8.20200814) upstream; urgency=medium
+
+  * Added support for external backend programs. So if you want a hash
+    that git-annex doesn't support, or something stranger, you can write a
+    small program to implement it.
+  * Fix a bug in find --branch in the previous version.
+  * importfeed: Fix reversion that caused some '.' in filenames to be
+    replaced with '_'
+  * Fix a lock file descriptor leak that could occur when running commands
+    like git-annex add with -J. Bug was introduced as part of a different FD
+    leak fix in version 6.20160318.
+  * Fix a hang when using git-annex with an old openssh 7.2p2, which had
+    some weird inheriting of ssh FDs by sshd. Bug was introduced in
+    git-annex version 7.20200202.7.
+  * move, copy --to: Sped up seeking files by 2x.
+  * drop: Sped up seeking files to drop by 2x, and also some performance
+    improvements to checking numcopies.
+  * Deal with unusual IFS settings in the shell scripts for linux
+    standalone and OSX app.
+    Thanks, Yaroslav Halchenko
+  * Avoid complaining that a file with "is beyond a symbolic link"
+    when the filepath is absolute and the symlink in question is not
+    actually inside the git repository.
+  * Slightly sped up the linux standalone bundle.
+  * Support building with dlist-1.0
+
+ -- Joey Hess <id@joeyh.name>  Mon, 10 Aug 2020 13:04:04 -0400
+
+git-annex (8.20200720.1) upstream; urgency=medium
+
+  * Fix a bug in find --batch in the previous version.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 20 Jul 2020 19:39:11 -0400
+
+git-annex (8.20200720) upstream; urgency=medium
+
+  * import: Added --no-content option, which avoids downloading files
+    from a special remote. Currently only supported by the directory
+    special remote.
+  * Honor annex.largefiles when importing a tree from a special remote.
+    (Except for when --no-content is used.)
+  * Fix a deadlock that could occur after git-annex got an unlocked
+    file, causing the command to hang indefinitely. Known to happen on 
+    vfat filesystems, possibly others.
+  * Build with the http-client-restricted and git-lfs libraries when 
+    available, otherwise use the vendored copy as before.
+  * testremote: Fix over-allocation of resources and bad caching,
+    including starting up a large number of external special remote processes.
+    (Regression introduced in version 8.20200501)
+  * test: Fix some test cases that assumed git's default branch name.
+  * importfeed: Added some additional --template variables:
+    itempubyear, itempubmonth, itempubday, itempubhour,
+    itempubminute, itempubsecond.
+  * Made several special remotes support locking content on them,
+    which allows dropping from other special remotes in some situations
+    where it was not possible before. Supported special remotes:
+    S3 (with versioning=yes), git-lfs, tahoe
+  * Fix reversion that broke passing annex.* and remote.*.annex-*
+    git configs with -c. (Since version 8.20200330.)
+  * Bring back git-annex branch read cache. This speeds up some operations,
+    eg git-annex sync --content --all gets 20% faster.
+  * Fix a recently introduced bug that could cause a "fork: resource exhausted"
+    after getting several thousand files.
+  * Sped up the --all option by 2x to 16x by using git cat-file --buffer.
+    Thanks to Lukey for finding this optimisation.
+  * Sped up seeking for annexed files to operate on by a factor of nearly 2x.
+  * Sped up sync --content by 2x and other commands like fsck --fast and
+    whereis by around 50%, by using git cat-file --buffer.
+  * importfeed: Made checking known urls step around 15% faster.
+  * fsck: Detect if WORM keys contain a carriage return, and recommend
+    upgrading the key. (git-annex could have maybe created such keys back
+    in 2013).
+  * When on an adjust --hide-missing branch, fix handling of files that
+    have been deleted but the deletion is not yet staged.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 20 Jul 2020 14:40:51 -0400
+
+git-annex (8.20200617) upstream; urgency=medium
+
+  * Added annex.skipunknown git config, that can be set to false to change
+    the behavior of commands like `git annex get foo*`, to not skip
+    over files/dirs that are not checked into git and are explicitly listed in
+    the command line.
+  * annex.skipunknown is planned to change to default to false in a
+    git-annex release in early 2022. If you prefer the current behavior,
+    you can explicitly set it to true.
+  * Try to enable special remotes configured with autoenable=yes
+    when git-annex auto-initialization happens in a new clone of an
+    existing repo. Previously, git-annex init had to be explicitly run to
+    enable them. Special remotes cannot display anything when autoenabled
+    this way, to avoid interfering with the output of git-annex query
+    commands.
+  * export: Added options for json output.
+  * import: Added --json-progress.
+  * addurl: Make --preserve-filename also apply when eg a torrent contains
+    multiple files.
+  * Fix a crash or potentially not all files being exported when 
+    sync -J --content is used with an export remote.
+  * export: Let concurrent transfers be done with -J or annex.jobs.
+  * move --to, copy --to, mirror --to: When concurrency is enabled, run
+    cleanup actions in separate job pool from uploads. 
+  * init: If lock probing stalls for a long time (eg a broken NFS server),
+    display a message to let the user know what's taking so long.
+  * init: When annex.pidlock is set, skip lock probing.
+  * Fix file descriptor leak when importing from a directory special remote
+    that is configured with exporttree=yes.
+  * Note that external special remote programs should not block SIGINT or
+    SIGTERM.
+  * Avoid creating the keys database during init when there are no unlocked
+    files, to prevent init failing when sqlite does not work in the
+    filesystem.
+  * import: Avoid using some strange names for temporary keys,
+    which broke importing from a directory special remote onto a vfat
+    filesystem.
+  * S3: The REDUCED_REDUNDANCY storage class is no longer cheaper so
+    stop documenting it, and stop offering it as a choice in the assistant.
+  * Improve display of problems auto-initializing or upgrading local git
+    remotes.
+  * When a local git remote cannot be initialized because it has no
+    git-annex branch or a .noannex file, avoid displaying a message about it.
+  * checkpresentkey: When no remote is specified, try all remotes, not
+    only ones that the location log says contain the key. This is what
+    the documentation has always said it did.
+  * Fix regression in external special remote handling: GETCONFIG did not
+    return a value that was set with SETCONFIG immediately before.
+    (Regression introduced in version 7.20200202.7)
+  * Fix bug that made initremote of extrnal special remotes with
+    embedcreds=yes or gpg encryption not store the creds in the git-annex
+    branch. git-annex-remote-googledrive one was special remote affected by
+    this bug.
+    (Regression introduced in version 7.20200202.7)
+  * Fix bug that made creds not be stored in git when a special remote
+    was initialized with gpg encryption, but without an explicit
+    embedcreds=yes.
+    (Regression introduced in version 7.20200202.7)
+  * Fix a annex.pidlock issue that made eg git-annex get of an unlocked
+    file hang until the annex.pidlocktimeout and then fail.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 17 Jun 2020 15:58:59 -0400
+
+git-annex (8.20200522) upstream; urgency=medium
+
+  * Fix bug that made enableremote of S3 and webdav remotes, that
+    have embedcreds=yes, fail to set up the embedded creds, so accessing
+    the remotes failed. (Regression introduced in version 7.20200202.7)
+  * addurl, importfeed: Avoid adding filenames with leading '.', instead
+    it will be replaced with '_'.
+  * addurl, importfeed: Allow '-' in filenames, as long as it's not the
+    first character.
+  * addurl --preserve-filename: New option, uses server-provided filename
+    without any sanitization, but will fail if the filename has an obvious
+    security problem like using an escape sequence or trying to escape
+    the current directory.
+  * whereis: Added --format option.
+  * S3: Support signature=v4, to use S3 Signature Version 4.
+    Some S3 services seem to require v4, while others may only
+    support v2, which remains the default.
+  * upgrade: When upgrade fails due to an exception, display it.
+  * repair: Improve fetching from a remote with an url in host:path format.
+  * git-lfs repos that encrypt the annexed content but not the git repo
+    only need --force passed to initremote, allow enableremote and
+    autoenable of such remotes without forcing again.
+  * When accessing a remote fails, always display a reason why.
+  * Display a warning message when a remote uses a protocol, such as
+    git://, that git-annex does not support. Silently skipping such a
+    remote was confusing behavior.
+  * Also display a warning message when a remote, without a known uuid,
+    is located in a directory that does not currently exist, to avoid
+    silently skipping such a remote.
+  * sync: Avoid an ugly error message when nothing has been committed to
+    master yet and there is a synced master branch to merge from.
+  * Display a warning message when asked to operate on a file inside a
+    directory that's a symbolic link to elsewhere.
+  * Support building with tasty-1.3.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 22 May 2020 12:05:01 -0400
+
+git-annex (8.20200501) upstream; urgency=medium
+
+  * Improve git-annex's ability to find the path to its program,
+    especially when it needs to run itself in another repo to upgrade it.
+  * adb: Better messages when the adb command is not installed.
+  * Sped up query commands that read the git-annex branch by around 9%.
+  * Various speed improvements gained by using ByteStrings for git refs and
+    shas.
+  * Fix a potential failure to parse git config.
+  * Support boolean git configs that are represented by the name of the
+    setting with no value, eg "core.bare" is the same as "core.bare = true".
+  * When parsing git configs, support all the documented ways to write
+    true and false, including "yes", "on", "1", etc.
+  * Fix --batch commands (and git-annex info) to accept absolute filenames 
+    for unlocked files, which already worked for locked files.
+  * Avoid repeatedly opening keys db when accessing a local git remote
+    and -J is used.
+  * Avoid running a large number of git cat-file child processes when run
+    with a large -J value.
+  * Avoid running with more git check-attr and check-ignore processes than
+    there are CPU cores when run with a large -J value.
+  * get --from, move --from: When used with a local git remote, these used
+    to silently skip files that the location log thought were present on the
+    remote, when the remote actually no longer contained them. Since that
+    behavior could be surprising, now instead display a warning.
+  * external special remotes: remote.name.annex-readonly=true no longer
+    disables running the external special remote program. Instead, it just
+    makes the remote operate in a readonly mode, same as any remote.
+    To disable running the external special remote program, now need to set
+    remote.name.annex-externaltype=readonly. That is done when
+    git-annex enableremote is passed readonly=true.
+  * Stop storing readonly=true in remote.log of external special remotes;
+    it is a local setting only.
+  * sync: When some remotes to sync with are specified, and --fast is too,
+    pick the lowest cost of the specified remotes, do not sync with a
+    faster remote that was not specified.
+  * addurl: When run with --fast on an url that 
+    annex.security.allowed-ip-addresses prevents accessing, display
+    a more useful message.
+  * When the required content is set to "groupwanted", use whatever
+    expression has been set in groupwanted as the required content of the
+    repo, similar to how setting required content to "standard" already
+    worked.
+  * Avoid a test suite failure when the environment does not let gpg be
+    tested due to eg, too long a path to the agent socket.
+  * test: Include testremote tests, run on a directory special remote.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 01 May 2020 13:09:24 -0400
+
+git-annex (8.20200330) upstream; urgency=medium
+
+  * fsck: Fix reversion in 8.20200226 that made it incorrectly warn
+    that hashed keys with an extension should be upgraded.
+  * add --force-small: Fix a bug that, when adding a symbolic link,
+    checked in the content of the file the symlink pointed to.
+    Thanks, Kyle Meyer for the patch.
+  * add --force-small: Fix failure when passed a modified submodule.
+    Thanks, Kyle Meyer for the patch.
+  * When syncing changes back from an adjusted branch to the basis branch,
+    include changes to submodules.
+    Thanks, Kyle Meyer for the patch.
+  * webdav: Made exporttree remotes faster by caching connection to the
+    server.
+  * Fix a minor bug that caused options provided with -c to be passed
+    multiple times to git.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 30 Mar 2020 12:14:50 -0400
+
+git-annex (8.20200309) upstream; urgency=medium
+
+  * Fix bug that caused unlocked annexed dotfiles to be added to git by the
+    smudge filter when annex.dotfiles was not set.
+  * Upgrade other repos than the current one by running git-annex upgrade
+    inside them, which avoids problems with upgrade code making assumptions
+    that the cwd will be inside the repo being upgraded. In particular,
+    this fixes a problem where upgrading a v7 repo to v8 caused an ugly
+    git error message.
+  * Fix upgrade failure when a file has been deleted from the working tree.
+  * Fix regression 1 month ago that prevented external special remotes from
+    using GETCONFIG to query values like "name".
+  * Improve behavior when a directory git-annex is writing to gets
+    unmounted. Previously it could in some cases re-create the mount point
+    and directory tree, and even write object contents to the wrong disk.
+  * Don't ignore --debug when it is followed by -c.
+  * whereis: If a remote fails to report on urls where a key
+    is located, display a warning, rather than giving up and not displaying
+    any information.
+  * When external special remotes fail but neglect to provide an error
+    message, say what request failed, which is better than displaying an
+    empty error message to the user.
+  * git-annex config: Only allow configs be set that are ones git-annex
+    actually supports reading from repo-global config, to avoid confusion.
+  * Avoid converting .git file in a worktree or submodule to a symlink
+    when the repository is not a git-annex repository.
+  * Linux standalone: Use md5sum to shorten paths in .cache/git-annex/locales
+  * Fix build with ghc 8.8 (MonadFail)
+    Thanks, Peter Simons
+  * stack.yaml: Updated to lts-14.27.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 09 Mar 2020 17:04:08 -0400
+
+git-annex (8.20200226) upstream; urgency=medium
+
+  * New v8 repository version.
+  * v7 upgrades automatically to v8. The upgrade deletes old sqlite
+    databases, which may cause git-annex to need to do extra work to
+    regenerate the databases or due to not having the information from the
+    old databases available. Two notable cases are interrupted incremental
+    fscks and interrupted exports, both of which will restart from the
+    beginning.
+  * Improved serialization of filenames and keys to the sqlite databases,
+    avoiding encoding problems and speeding up operations on them.
+  * Add some missing indexes to sqlite databases. This will speed up
+    some things involving export and import remotes, and git-annex smudge.
+    Microbenchmarks show around 10-25% speedup of sqlite database operations.
+  * add: When adding a whole directory, any dotfiles found in it will
+    not be skipped, but will be added to git by default. This behavior
+    can be configured with annex.dotfiles.
+  * add: Removed special case for explicitly passing dotfiles,
+    that no longer adds them to the annex, but to git. This behavior
+    can be configured with annex.dotfiles.
+  * add: Removed the --include-dotfiles option.
+  * initremote, enableremote: Set remote.name.skipFetchAll when
+    the remote cannot be fetched from by git, so git fetch --all
+    will not try to use it.
+  * Fix some cases where handling of keys with extensions varied depending
+    on the locale.
+  * annex.maxextensionlength used to be the number of characters, not
+    bytes, when in a utf-8 locale. It's now always the number of bytes.
+  * Extended annex.security.allowed-ip-addresses to let specific ports
+    of an IP address to be used, while denying use of other ports.
+  * init --version: When the version given is one that automatically
+    upgrades to a newer version, use the newer version instead.
+  * Auto upgrades from older repo versions, like v5, now jump right to v8.
+  * Makefile: Support newer versions of cabal that use the new-build system.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 26 Feb 2020 18:49:58 -0400
+
+git-annex (7.20200226) upstream; urgency=high
+
+  * Fix serious regression in gcrypt and encrypted git-lfs remotes.
+    Since version 7.20200202.7, git-annex incorrectly stored content
+    on those remotes without encrypting it.
+    If your remotes are affected, you will want to make sure to delete
+    any content that git-annex has stored on them that is not encrypted!
+  * initremote: Fix regression in parsing the exporttree= parameter.
+  * info: Fix display of the encryption value.
+    (Some debugging junk had crept in.)
+  * Bugfix to getting content from an export remote with -J, when the
+    export database was not yet populated.
+  * Bugfix: export --tracking (a deprecated option) set 
+    annex-annex-tracking-branch, instead of annex-tracking-branch.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 26 Feb 2020 17:18:16 -0400
+
+git-annex (7.20200219) upstream; urgency=medium
+
+  * Added sync --only-annex, which syncs the git-annex branch and annexed
+    content but leaves managing the other git branches up to you.
+  * Added annex.synconlyannex git config setting, which can also be set with
+    git-annex config to configure sync in all clones of the repo.
+  * fsck --from remote: Fix a concurrency bug that could make it incorrectly
+    detect that content in the remote is corrupt, and remove it, resulting in
+    data loss.
+  * When git-annex is built with a ssh that does not support ssh connection
+    caching, default annex.sshcaching to false, but let the user override it.
+  * Improve warning messages further when ssh connection caching cannot
+    be used, to clearly state why.
+  * Avoid throwing fatal errors when asked to write to a readonly
+    git remote on http.
+  * Fix support for repositories tuned with annex.tune.branchhash1=true,
+    including --all not working and git-annex log not displaying anything
+    for annexed files.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 19 Feb 2020 12:44:43 -0400
+
+git-annex (7.20200204) upstream; urgency=medium
+
+  * Fix build with persistent-template 2.8.0.
+  * Makefile: Really move the fish completion to the
+    vendor_completions.d directory.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 04 Feb 2020 14:30:55 -0400
+
+git-annex (7.20200202.7) upstream; urgency=medium
+
+  * add: --force-large/--force-small options make it easier to override
+    annex.largefiles configuration (and potentially safer as it avoids
+    bugs like the smudge bug fixed in the last release).
+  * reinject --known: Fix bug that prevented it from working in a bare repo.
+  * Support being used in a git repository that uses sha256 rather than sha1.
+  * initremote, enableremote: Be stricter about rejecting invalid
+    configuration parameters for remotes, particularly things like foo=true
+    when foo=yes is expected.
+  * initremote, enableremote: Reject unknown configuration parameters
+    provided to these commands.
+  * initremote: Added --whatelse option, to show additional
+    configuration parameters you might want to set. Eg:
+    git annex initremote type=directory encryption=none --whatelse
+  * Added LISTCONFIGS to external special remote protocol. Special remote
+    programs that use GETCONFIG/SETCONFIG are recommended to implement it.
+  * init: Avoid an ugly error message when http remote has no git-annex
+    uuid configured.
+  * Support git remotes that need http basic auth to be accessed,
+    using git credential to get the password.
+  * Display a warning when concurrency is enabled but ssh connection caching
+    is not enabled or won't work due to a crippled filesystem.
+  * Makefile: Move the fish completion to the vendor_completions.d directory.
+  * Fixed a test suite failure when run in the C locale.
+
+ -- Joey Hess <id@joeyh.name>  Sun, 02 Feb 2020 00:00:00 -0400
+
+git-annex (7.20191230) upstream; urgency=medium
+
+  * Optimised processing of many files, especially by commands like find
+    and whereis that only report on the state of the repository. Commands
+    like get also sped up in cases where they have to check a lot of
+    files but only transfer a few files. Speedups range from 30-100%.
+  * Added build dependency on the filepath-bytestring library.
+  * Fixed an oversight that had always prevented annex.resolvemerge
+    from being honored, when it was configured by git-annex config.
+  * annex.largefiles can be configured by git-annex config,
+    to more easily set a default that will also be used by clones,
+    without needing to shoehorn the expression into the gitattributes file.
+    The git config and gitattributes override that.
+  * annex.addunlocked can be set to an expression with the same format used by
+    annex.largefiles, when you want to default to unlocking some files but
+    not others.
+  * annex.addunlocked can be configured by git-annex config.
+  * git-annex-config --set/--unset: No longer change the local git config
+    setting, except for in the special case of annex.securehashesonly.
+  * Improve file ordering behavior when one parameter is "." and other
+    parameters are other directories.
+  * smudge bugfix: When annex.largefiles=anything, files that were already
+    stored in git, and have not been modified could sometimes be converted
+    to being stored in the annex. Changes in 7.20191024 made this more
+    of a problem. This case is now detected and prevented.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 30 Dec 2019 12:43:30 -0400
+
+git-annex (7.20191218) upstream; urgency=medium
+
+  * git-lfs: The url provided to initremote/enableremote will now be
+    stored in the git-annex branch, allowing enableremote to be used without
+    an url. initremote --sameas can be used to add additional urls.
+  * git-lfs: When there's a git remote with an url that's known to be
+    used for git-lfs, automatically enable the special remote.
+  * sync, assistant: Pull and push from git-lfs remotes.
+  * Fix bug that made bare repos be treated as non-bare when --git-dir
+    was used.
+  * inprogress: Support --key.
+  * Sped up many git-annex commands that operate on many files, by 
+    avoiding reserialization of keys.
+    find is 7% faster; whereis is 3% faster; and git-annex get when
+    all files are already present is 5% faster
+  * Stop displaying rsync progress, and use git-annex's own progress display
+    for local-to-local repo transfers.
+  * benchmark: Changed --databases to take a parameter specifiying the size
+    of the database to benchmark.
+  * benchmark --databases: Display size of the populated database.
+  * benchmark --databases: Improve the "addAssociatedFile (new)"
+    benchmark to really add new values, not overwriting old values.
+  * Windows: Fix handling of changes to time zone. (Used to work but was
+    broken in version 7.20181031.)
+
+ -- Joey Hess <id@joeyh.name>  Wed, 18 Dec 2019 13:53:51 -0400
+
+git-annex (7.20191114) upstream; urgency=medium
+
+  * Added annex.allowsign option.
+  * Make --json-error-messages capture more errors,
+    particularly url download errors.
+  * Fix a crash (STM deadlock) when -J is used with multiple files
+    that point to the same key.
+  * linuxstandalone: Fix a regression that broke git-remote-https.
+  * OSX git-annex.app: Fix a problem that prevented using the bundled
+    git-remote-https, git-remote-http, and git-shell.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 14 Nov 2019 21:57:59 -0400
+
+git-annex (7.20191106) upstream; urgency=medium
+
+  * init: Fix bug that lost modifications to unlocked files when init is
+    re-ran in an already initialized repo.
+  * benchmark: Add --databases to benchmark sqlite databases.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 06 Nov 2019 12:14:50 -0400
+
+git-annex (7.20191024) upstream; urgency=medium
+
+  * Changed git add/git commit -a default behavior back to what it was
+    before v7; they add file contents to git, not to the annex. 
+    (However, if a file was annexed before, they will still add it to
+    the annex, to avoid footgun.)
+  * Configuring annex.largefiles overrides that; once git-annex has
+    been told which files are large git add/git commit -a will annex them.
+  * Added annex.gitaddtoannex configuration. Setting it to false prevents
+    git add from adding files to the annex even when annex.largefiles
+    is configured. (Unless the file was annexed before.)
+  * smudge: Made git add smarter about renamed annexed files. It can tell
+    when an annexed file was renamed, and will add it to the annex, 
+    and not to git, unless annex.largefiles tells it to do otherwise.
+  * init: Fix a failure when used in a submodule on a crippled filesystem.
+  * sync: Fix crash when there are submodules and an adjusted branch is
+    checked out.
+  * enable-tor: Deal with pkexec changing to root's home directory
+    when running a command.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 25 Oct 2019 13:04:59 -0400
+
+git-annex (7.20191017) upstream; urgency=medium
+
+  * initremote: Added --sameas option, allows for two special remotes that
+    access the same data store.
+  * Note that due to complications of the sameas feature, any external
+    special remotes that try to send SETSTATE or GETSTATE during INITREMOTE
+    or EXPORTSUPPORTED will now get back an ERROR. That would be a very
+    hackish thing for an external special remote to do, needing some kind
+    of hard-coded key value to be used, so probably nothing will be affected.
+  * forget --drop-dead: Remove several classes of git-annex log files
+    when they become empty, further reducing the size of the git-annex branch.
+  * OSX: Deal with symbolic link problem that caused git to not be included in
+    the git-annex.dmg.
+  * Fix build with persistent-2.10.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 17 Oct 2019 18:19:12 -0400
+
+git-annex (7.20191009) upstream; urgency=medium
+
+  * Fix bug in handling of annex.largefiles that use largerthan/smallerthan.
+    When adding a modified file, it incorrectly used the file size of the
+    old version of the file, not the current size.
+  * Added --mimetype and --mimeencoding file matching options.
+  * Added --unlocked and --locked file matching options.
+  * Added adjust --lock, to enter an adjusted branch where files are locked.
+  * git-lfs: Added support for http basic auth.
+  * git-lfs: Only do endpoint discovery once when concurrency is enabled.
+  * fsck --incremental/--more: Fix bug that prevented the incremental fsck
+    information from being updated every 5 minutes as it was supposed to be;
+    it was only updated after 1000 files were checked, which may be more
+    files that are possible to fsck in a given fsck time window.
+    Thanks to Peter Simons for help with analysis of this bug.
+  * Test: Use more robust directory removal when built with directory-1.2.7.
+  * Close sqlite databases more robustly.
+  * remotedaemon: Don't list --stop in help since it's not supported.
+  * enable-tor: Run kdesu with -c option.
+  * enable-tor: Use pkexec to run command as root when gksu and kdesu are not
+    available.
+  * When dropping an unlocked file, preserve its mtime, which avoids
+    git status unncessarily running the clean filter on the file.
+  * uninit: Remove several git hooks that git-annex init sets up.
+  * uninit: Remove the smudge and clean filters that git-annex init sets up.
+  * Work around git cat-file --batch's odd stripping of carriage return
+    from the end of the line (some windows infection), avoiding crashing
+    when the repo contains a filename ending in a carriage return.
+  * git-annex-standalone.rpm: Fix the git-annex-shell symlink.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 09 Oct 2019 12:31:31 -0400
+
+git-annex (7.20190912) upstream; urgency=medium
+
+  * Default to v7 for new repositories.
+  * Automatically upgrade v5 repositories to v7.
+  * Automatically convert direct mode repositories to v7 with adjusted
+    unlocked branches and set annex.thin.
+  * Added annex.autoupgraderepository configuration that can be set to false
+    to prevent any automatic repository upgrades.
+  * Refuse to upgrade direct mode repositories when git is older than 2.22,
+    which fixed a memory leak that could cause an OOM during the upgrade.
+  * Removed support for git versions older than 2.1.
+  * assistant: When creating a new repository, no longer use direct
+    mode, instead use v7 adjusted branches with annex.thin.
+  * init: When run on a crippled filesystem with --version=5,
+    will error out, since version 7 is needed for adjusted unlocked branch.
+  * direct: This command always errors out as direct mode is no longer
+    supported.
+  * indirect: This command has become a deprecated noop.
+  * proxy: This command is deprecated because it was only needed in direct
+    mode. (But it continues to work.)
+  * info: Removed the "repository mode" from its output (including the
+    --json output) since with the removal of direct mode, there is no
+    repository mode.
+  * info: When file matching options are specified when getting
+    info of something other than a directory, they won't have any effect,
+    so error out to avoid confusion.
+  * info: Display trust level when getting info on a uuid, same as a remote.
+  * When upgrading a direct mode repo to v7 with adjusted unlocked branches,
+    fix a bug that prevented annex.thin from taking effect for the files
+    in working tree.
+  * Avoid making a commit when upgrading from direct mode to v7.
+  * init: Catch more exceptions when testing locking.
+  * init: Fix a reversion that broke initialization on systems that
+    need to use pid locking.
+  * A git-annex-standalone rpm is now distributed along with the standalone
+    tarball.
+  * Added standalone/rpm/rpmbuild-from-standalone-tarball script.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 13 Sep 2019 12:53:06 -0400
+
+git-annex (7.20190819) upstream; urgency=medium
+
+  * New git-lfs special remote, which can be used to store data on any git-lfs
+    server, including github, gitlab, and gogs.
+  * Support fully encrypting all data sent to a git-lfs special remote,
+    using a combination of gcrypt to encrypt the git data, and git-annex's
+    encryption of its data.
+  * Use the same optimisation for --in=here as has always been
+    used for --in=. rather than the slow code path that unncessarily
+    queries the git-annex branch.
+  * Allow setting up a gcrypt special remote with encryption=shared.
+  * Fix querying git for object type when operating on a file containing
+    newlines.
+  * merge: When run with a branch parameter, merges from that branch.
+    This is especially useful when using an adjusted branch, because
+    it applies the same adjustment to the branch before merging it.
+  * init: Install working hook scripts when run on a crippled filesystem
+    and on Windows. If your repository was set up by an old version
+    of git-annex that omitted the hooks, you can simply re-run git-annex init
+    to install them.
+  * init: When the repo is already initialized, and --version requests a
+    different version, error out rather than silently not changing the
+    version.
+  * S3: Fix encoding when generating public urls of S3 objects.
+  * Make git-annex-standalone.deb include the shell completions again.
+  * Makefile: Changed default zsh completion location to zsh default fpath.
+    Systems such as Debian that have overridden the default fpath will
+    need to set ZSH_COMPLETIONS_PATH.
+  * test: Add pass using adjusted unlocked branch.
+  * Fix intermittent failure of the test suite, where its repeated opening
+    and writing to the sqlite database somehow caused inode cache information
+    to occasionally be lost.
+  * Fix several test suite failures on Windows.
+  * Windows installer: Always install to 64 bit program files directory,
+    since it needs 64 bit git now.
+  * Build with silently-1.2.5.1 on Windows; the old one used "NUL" device
+    which is not supported with recent versions of ghc.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 19 Aug 2019 12:23:16 -0400
+
+git-annex (7.20190730) upstream; urgency=medium
+
+  * Improved probing when CoW copies can be made between files on the same
+    drive. Now supports CoW between BTRFS subvolumes. And, falls back to rsync
+    instead of using cp when CoW won't work, eg copies between repos on the
+    same EXT4 filesystem.
+  * Add BLAKE2BP512 and BLAKE2BP512E backends, using a blake2 variant
+    optimised for 4-way CPUs.
+  * Support running v7 upgrade in a repo where there is no branch checked
+    out, but HEAD is set directly to some other ref.
+  * Windows build no longer ships with a copy of rsync, since that is only
+    used any more to access rsync special remotes or remotes with a very
+    old version of git-annex-shell.
+  * Windows build is now 64 bit, and using it with the 64 bit git for
+    Windows is fully supported.
+  * Windows problems with long filenames should be fixed now,
+    since the Windows build is made with a newer ghc version that works
+    around the problems.
+  * stack.yaml: Build with http-client-0.5.14 to get a bug fix to http header
+    parsing.
+  * Drop support for building with ghc older than 8.4.4,
+    and with older versions of serveral haskell libraries.
+  * Support building with socks-0.6 and persistant-template-2.7.
+  * Corrected some license statements.
+    Thanks, Sean Whitton.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 30 Jul 2019 12:22:25 -0400
+
+git-annex (7.20190708) upstream; urgency=medium
+
+  * Fix find --json to output json once more.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 08 Jul 2019 08:58:16 -0400
+
+git-annex (7.20190626) upstream; urgency=medium
+
+  * get, move, copy, sync: When -J or annex.jobs has enabled concurrency,
+    checksum verification uses a separate job pool than is used for
+    downloads, to keep bandwidth saturated.
+  * Other commands also run their cleanup phase using a separate job pool
+    than their perform phase, which may make some of them somewhat faster
+    when running concurrently as well.
+  * When downloading an url and the destination file exists but is empty,
+    avoid using http range to resume, since a range "bytes=0-" is an unusual
+    edge case that it's best to avoid relying on working. This is known to
+    fix a case where importfeed downloaded a partial feed from such a server.
+  * importfeed: When there's a problem parsing the feed, --debug will
+    output the feed content that was downloaded.
+  * init: Fix a reversion in the last release that prevented automatically
+    generating and setting a description for the repository.
+  * add: Display progress meter when hashing files.
+  * add: Support --json-progress option.
+  * The Linux standalone arm build now works again on CPU versions below
+    arm6. Thanks to Emanuele Olivetti, Ilias Tsitsimpis, Bernhard
+    Übelacker, and Adrian Bunk for fixing ghc in Debian (bug #928882).
+  * OSX dmg: Put git-annex's version in the Info.plist file.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 26 Jun 2019 12:29:46 -0400
+
+git-annex (7.20190615) upstream; urgency=medium
+
+  * Fixed bug that caused git-annex to fail to add a file when another
+    git-annex process cleaned up the temp directory it was using.
+  * Makefile: Added install-completions to install target.
+  * Added the ability to run one job per CPU (core), by setting
+    annex.jobs=cpus, or using option --jobs=cpus or -Jcpus.
+  * Honor preferred content of a special remote when exporting trees to it;
+    unwanted files are filtered out of the tree that is exported.
+  * Importing from a special remote honors its preferred content too;
+    unwanted files are not imported. But, some preferred content
+    expressions can't be checked before files are imported, and trying to
+    import with such an expression will fail.
+  * Don't try to import .git directories from special remotes, because
+    git does not support storing git repositories inside a git repository.
+  * Improve shape of commit tree when importing from unversioned special
+    remotes.
+  * init: When the repository already has a description, don't change it.
+  * describe: When run with no description parameter it used to set
+    the description to "", now it will error out.
+  * Android: Improve installation process when the user's login shell is not
+    bash.
+  * When a remote is configured to be readonly, don't allow changing
+    what's exported to it.
+  * Renamed annex.security.allowed-http-addresses to
+    annex.security.allowed-ip-addresses because it is not really specific
+    to the http protocol, also limiting eg, git-annex's use of ftp.
+    The old name for the config will still work.
+  * Add back support for ftp urls, which was disabled as part of the fix for
+    security hole CVE-2018-10857 (except for configurations which enabled curl
+    and bypassed public IP address restrictions). Now it will work
+    if allowed by annex.security.allowed-ip-addresses.
+  * Avoid a delay at startup when concurrency is enabled and there are
+    rsync or gcrypt special remotes, which was caused by git-annex
+    opening a ssh connection to the remote too early.
+
+ -- Joey Hess <id@joeyh.name>  Sat, 15 Jun 2019 12:38:25 -0400
+
+git-annex (7.20190507) upstream; urgency=medium
+
+  * Fix reversion in last release that caused wrong tree to be written
+    to remote tracking branch after an export of a subtree.
+  * Improved locking when multiple git-annex processes are writing to 
+    the .git/index file
+
+ -- Joey Hess <id@joeyh.name>  Tue, 07 May 2019 13:05:33 -0400
+
+git-annex (7.20190503) upstream; urgency=medium
+
+  * adb special remote supports being configured with importtree=yes,
+    to allow git-annex import of files from an Android device. This can be
+    combined with exporttree=yes and git-annex export used to send changes
+    back to the Android device.
+  * S3 special remote supports being configured with importtree=yes,
+    to allow git-annex import of files from a S3 bucket. This can be
+    combined with exporttree=yes and git-annex export used to send changes
+    back to the S3 bucket.
+  * S3: When versioning is enabled on a bucket, importing from it will
+    import old versions of files that were written to the bucket as well
+    as the current versions. A git history is synthesized to reflect the way
+    the bucket changed over time.
+  * Fix bug that caused importing from a special remote to repeatedly
+    download unchanged files when multiple files in the remote have the same
+    content.
+  * Made git-annex sync --content much faster when all the remotes it's
+    syncing with are export/import remotes.
+  * sync: When listing contents on an import remote fails, proceed with
+    other syncing instead of aborting.
+  * renameremote: New command, changes the name that is used to enable 
+    a special remote. Especially useful when you want to reuse the name
+    of an old remote for something new.
+  * Drop support for building with aws older than 0.14.
+  * info: Show when a remote is configured with importtree.
+  * Added mimeencoding= term to annex.largefiles expressions.
+    This is probably mostly useful to match non-text files with eg
+    "mimeencoding=binary"
+  * git-annex matchexpression: Added --mimeencoding option.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 03 May 2019 12:47:41 -0400
+
+git-annex (7.20190322) upstream; urgency=medium
+
+  * New feature allows importing from special remotes, using
+    git annex import branch:subdir --from remote
+  * Directory special remote supports being configured with importree=yes,
+    to allow git-annex import of files from the directory. This can be
+    combined with exporttree=yes and git-annex export used to send changes
+    back to the same directory.
+  * Remote tracking branches are updated when importing and exporting to
+    special remotes, in ways analagous to how git fetch and git push do.
+  * export: Deprecated the --tracking option.
+    Instead, users can configure remote.<name>.annex-tracking-branch
+    themselves.
+  * sync --content: When remote.<name>.annex-tracking-branch is configured,
+    import from special remotes.
+  * sync, assistant: --no-push and remote.<name>.annex-push prevent exporting
+    trees to special remotes.
+  * Fix storage of metadata values containing newlines.
+    (Reversion introduced in version 7.20190122.)
+  * Sped up git-annex export in repositories with lots of keys.
+  * S3: Support enabling bucket versioning when built with aws-0.21.1.
+  * stack.yaml: Build with aws-0.21.1
+  * Fix cleanup of git-annex:export.log after git-annex forget --drop-dead.
+  * Makefile: Added install-home target which installs git-annex into
+    the HOME directory.
+  * addurl --file: Fix a bug that made youtube-dl be used unneccessarily
+    when adding an html url that does not contain any media.
+  * Add -- before %f in the smudge/clean filter configuration,
+    to support filenames starting with dashes.
+    (To update the config of existing repositories, you can
+    re-run git-annex init.)
+  * fsck: Detect situations where annex.thin has caused data loss
+    to the content of locked files.
+  * Removed bundled gpg from the Linux standalone build and OSX dmg,
+    because gpg now always wants to use gpg-agent, and shipping such a daemon
+    in those is not a good idea.
+  * import: Let --force overwrite symlinks, not only regular files.
+  * Android: Fix typo of name of armv7l in installation script.
+    Thanks, 4omecha.
+  * S3: Added protocol= initremote setting, to allow https to be used
+    on a non-standard port.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 22 Mar 2019 13:56:51 -0400
+
+git-annex (7.20190219) upstream; urgency=medium
+
+  * init: Fix bug when direct mode needs to be enabled on a crippled
+    filesystem, that left the repository in indirect mode.
+  * Fix false positive in export conflict detection, that occurred
+    when the same tree was exported by multiple clones. Previous fix was
+    incomplete.
+  * When key-based retrieval from a S3 remote with exporttree=yes appendonly=yes
+    fails, fall back to trying to retrieve from the exported tree.
+    This allows downloads of files that were exported to such a remote
+    before versioning was enabled on it.
+  * Fix path separator bug on Windows that completely broke git-annex
+    since version 7.20190122.
+  * Improved speed of S3 remote by only loading S3 creds once.
+  * Display progress bar when getting files from export remotes.
+  * Fix race in cleanup of othertmp directory that could result in a failure
+    attempting to access it.
+  * fromkey: Made idempotent.
+  * fromkey: Added --json.
+  * fromkey --batch output changed to support using it with --json.
+    The old output was not parseable for any useful information, so
+    this is not expected to break anything.
+  * Avoid performing repository fixups for submodules and git-worktrees
+    when there's a .noannex file that will prevent git-annex from being
+    used in the repository.
+  * init: Don't let --force be used to override a .noannex file,
+    instead the user can just delete the file.
+  * webdav: Exporting files with '#' or '?' in their name won't work because
+    urls get truncated on those. Fail in a better way in this case,
+    and avoid failing when removing such files from the export, so
+    after the user has renamed the problem files the export will succeed.
+  * On Windows, avoid using rsync for local copies, since rsync is not
+    always available there.
+  * Added NetworkBSD build flag to deal with Network.BSD moving to a new
+    package.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 19 Feb 2019 11:12:45 -0400
+
+git-annex (7.20190129) upstream; urgency=medium
+
+  * initremote S3: When configured with versioning=yes, either ask the user
+    to enable bucket versioning, or auto-enable it when built with aws-0.22.
+  * enableremote S3: Do not let versioning=yes be set on existing remote,
+    because when git-annex lacks S3 version IDs for files stored in
+    the bucket, deleting them would cause data loss.
+  * S3: Detect when version=yes but an exported file lacks a S3 version ID,
+    and refuse to delete it, to avoid data loss.
+  * S3: Send a Content-Type header when storing objects in S3,
+    so exports to public buckets can be linked to from web pages.
+    (When git-annex is built with MagicMime support.)
+
+ -- Joey Hess <id@joeyh.name>  Tue, 29 Jan 2019 15:09:20 -0400
+
+git-annex (7.20190122) upstream; urgency=medium
+
+  * sync --content: Fix dropping unwanted content from the local repository.
+  * sync --content: Support dropping local content that has reached an
+    exporttree remote that is not untrusted (currently only S3 remotes
+    with versioning).
+  * init: When --version=5 is passed on a crippled filesystem,
+    use a v5 direct mode repo as requested, rather than upgrading to v7
+    adjusted unlocked. (Fixes test suite on crippled filesystems.)
+  * Some optimisations, including a 10x faster timestamp parser,
+    a 7x faster key parser, and improved parsing and serialization of
+    git-annex branch data. Many commands will run 5-15% faster.
+  * Stricter parser for keys doesn't allow doubled fields or out of order fields.
+  * The benchmark command, which only had some old benchmarking of the sqlite
+    databases before, now allows benchmarking any other git-annex commands.
+  * Support being built with ghc 8.6.3 (MonadFail).
+  * Removed old code that cleaned up after a bug in git-annex versions
+    3.20111105-3.20111110. In the unlikely event that a repo was
+    last touched by that ancient git-annex version, the descriptions
+    of remotes would appear missing when used with this version of
+    git-annex.
+  * Improve uuid.log parser to preserve whitespace in repo descriptions.
+  * Improve activity.log parser to not remove unknown values,
+    allowing for future expansion.
+  * addunused, merge, assistant: Avoid creating work tree files in
+    subdirectories in an edge case where the key contains "/".
+  * testremote: Support testing readonly remotes with the --test-readonly option.
+  * Switch to using .git/annex/othertmp for tmp files other than partial
+    downloads, and make stale files left in that directory when git-annex
+    is interrupted be cleaned up promptly by subsequent git-annex processes.
+  * The .git/annex/misctmp directory is no longer used and git-annex will
+    delete anything lingering in there after it's 1 week old.
+  * Estimated time to completion display shortened from eg "1h1m1s" to "1h1m".
+  * Fix doubled progress display when downloading an url when -J is used.
+  * unused: Update suggested git log message to see where data was previously
+    used so it will also work with v7 unlocked pointer files.
+  * importfeed: Better error message when downloading the feed fails.
+  * Make test suite work better when the temp directory is on NFS.
+  * webapp: Remove configurator for box.com repository, since their
+    webdav support is going away at the end of this January.
+  * webapp: Remove configurator for gitlab, which stopped supporting git-annex
+    some time ago.
+  * Android: For armv71 architecture, use the armel build.
+  * Windows: If 64 bit git is installed, use it when installing git-annex.
+    (However, rsync still won't work and this is still not the documented way
+    to install it.)
+
+ -- Joey Hess <id@joeyh.name>  Tue, 22 Jan 2019 12:25:26 -0400
+
+git-annex (7.20181211) upstream; urgency=medium
+
+  * S3: Improve diagnostics when a remote is configured with exporttree and
+    versioning, but no S3 version id has been recorded for a key.
+  * findref: Support file matching options: --include, --exclude,
+    --want-get, --want-drop, --largerthan, --smallerthan, --accessedwithin
+  * Commands supporting --branch now apply file matching options --include,
+    --exclude, --want-get, --want-drop to filenames from the branch.
+    Previously, combining --branch with those would fail to match anything.
+  * add, import, findref: Support --time-limit.
+  * Add --branch option to git-annex find and mildly deprecate findref in
+    favor of it.
+  * webdav: When initializing, avoid trying to make a directory at the top of
+    the webdav server, which could never accomplish anything and failed on
+    nextcloud servers. (Reversion introduced in version 6.20170925.)
+  * Fix a case where upgrade to v7 caused git to think that unlocked files
+    were modified.
+  * Fix bug upgrading from direct mode to v7: when files in the repository
+    were already committed as v7 unlocked files elsewhere, and the
+    content was present in the direct mode repository, the annexed files
+    got their full content checked into git.
+  * Fix bug that caused v7 unlocked files in a direct mode repository
+    to get locked when committing.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 11 Dec 2018 16:33:10 -0400
+
+git-annex (7.20181205) upstream; urgency=medium
+
+  * Make bittorrent special remote work w/o btshowmetainfo installed
+    when it was build with torrentparser.
+    Thanks, Robert Schütz
+  * When running youtube-dl to get a filename, pass --no-playlist.
+  * Fix build without concurrent-output.
+  * init: When a crippled filesystem causes an adjusted unlocked branch to
+    be used, set repo version to 7, which it neglected to do before.
+  * init: When on a crippled filesystem, and the git version is too old
+    to use an adjusted unlocked branch, fall back to using direct mode.
+  * info: When used with an exporttree remote, includes an "exportedtree"
+    info, which is the tree last exported to the remote. During an export
+    conflict, multiple values will be listed.
+  * dropunused: When an unused object file has gotten modified, eg due to
+    annex.thin being set, don't silently skip it, but display a warning
+    and let --force drop it.
+  * annex.cachecreds: New config to allow disabling of credentials caching
+    for special remotes.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 05 Dec 2018 14:02:27 -0400
+
+git-annex (7.20181121) upstream; urgency=medium
+
+  * git-annex-shell: Fix hang when transferring the same objects to two
+    different clients at the same time. (Or when annex.pidlock is used,
+    two different objects.)
+  * Fixed some other potential hangs in the P2P protocol.
+  * Fix bash completion of "git annex" to propertly handle files with
+    spaces and other problem characters. (Completion of "git-annex"
+    already did.)
+  * Fix resume of download of url when the whole file content is
+    already actually downloaded.
+  * When an export conflict prevents accessing a special remote,
+    be clearer about what the problem is and how to resolve it.
+  * export, sync --content: Avoid unnecessarily trying to upload files
+    to an exporttree remote that already contains the files.
+  * smudge: When passed a file located outside the working tree, eg by git
+    diff, avoid erroring out.
+  * drop -J: Avoid processing the same key twice at the same time when
+    multiple annexed files use it.
+  * When a command is operating on multiple files and there's an error
+    with one, try harder to continue to the rest. (As was already done
+    for many types of errors including IO errors.)
+  * Fixed a crash when using -J with ssh password prompts in
+    --quiet/--json mode.
+    Thanks to Yaroslav Halchenko and the DataLad&ReproNim team for
+    helping to track down this bug.
+  * Remove esqueleto dependency to allow upgrading other dependencies to
+    newer versions.
+    Thanks Sean Parsons.
+  * Fix build with persistent-sqlite older than 2.6.3.
+  * Updated stack.yaml to lts-12.19; added stack-lts-9.9.yaml
+    to support old versions of stack.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 21 Nov 2018 14:22:47 -0400
+
+git-annex (7.20181105) upstream; urgency=medium
+
+  * Fix test suite failure when git-annex test is not run inside a git
+    repository.
+  * Fix a P2P protocol hang.
+  * importfeed: Avoid erroring out when a feed has been repeatedly broken,
+    as that can leave other imported files not checked into git.
+  * Increase minimum QuickCheck version.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 05 Nov 2018 13:31:09 -0400
+
+git-annex (7.20181031) upstream; urgency=medium
+
+  * Added v7 repository mode. v6 upgrades automatically to v7, but
+    v5 is still the default for now. While v6 was always experimental
+    to some degree, its successor v7 is ready for production use!
+    http://git-annex.branchable.com/tips/unlocked_files/
+  * Direct mode repositories are deprecated; they have many problems
+    that v7 fixes, so upgrading them now is recommended (but not yet
+    required): git annex upgrade --version=7
+  * init: When in a crippled filesystem, initialize a v7 repository
+    using an adjusted unlocked branch, instead of a direct mode repository.
+  * At long last there's a way to hide annexed files whose content
+    is missing from the working tree: git-annex adjust --hide-missing
+    See https://git-annex.branchable.com/tips/hiding_missing_files/
+  * When already in an adjusted branch, running git-annex adjust
+    again will update the branch as needed. This is mostly
+    useful with --hide-missing to hide/unhide files after their content
+    has been dropped or received.
+  * git-annex sync --content supports --hide-missing; it can
+    be used to get the content of hidden files, and it updates the
+    adjusted branch to hide/unhide files as necessary.
+  * smudge: The smudge filter no longer provides git with annexed
+    file content, to avoid a git memory leak, and because that did not
+    honor annex.thin. Now git annex smudge --update has to be run
+    after a checkout to update unlocked files in the working tree 
+    with annexed file contents.
+  * v7 init, upgrade: Install git post-checkout and post-merge hooks that run 
+    git annex smudge --update.
+  * precommit: Run git annex smudge --update, because the post-merge
+    hook is not run when there is a merge conflict. So the work tree will
+    be updated when a commit is made to resolve the merge conflict.
+  * Note that git has no hooks run after git stash or git cherry-pick,
+    so the user will have to manually run git annex smudge --update
+    after such commands.
+  * Removed the old Android app.
+  * Removed support for building with very old ghc < 8.0.1,
+    and with yesod < 1.4.3, and without concurrent-output,
+    which were only being used for the Android cross build.
+  * Webapp: Fix termux detection.
+  * runshell: Use system locales when built with 
+    GIT_ANNEX_PACKAGE_INSTALL set. (For Neurodebian packages.)
+  * Fix database inconsistency that could cause git-annex to
+    get confused about whether a locked file's content was present.
+  * Fix concurrency bug that occurred on the first download from an
+    exporttree remote.
+  * init --version=6 will still work, but the repository is auto-upgraded
+    immediately to v7.
+  * When annex.thin is set, allow hard links to be made between executable
+    work tree files and annex objects.
+  * addurl: Removed undocumented special case in handling of a CHECKURL-MULTI
+    response with only a single file listed. Rather than ignoring the url that
+    was in the response, use it.
+  * webapp: Fixed a crash when adding a git remote.
+    (Reversion introduced in version 6.20180112)
+  * migrate: Fix failure to migrate from URL keys.
+    (Reversion introduced in version 6.20180926)
+  * Cache high-resolution mtimes for improved detection of modified files
+    in v7 (and direct mode).
+
+ -- Joey Hess <id@joeyh.name>  Wed, 31 Oct 2018 09:21:50 -0400
+
+git-annex (6.20181011) upstream; urgency=medium
+
+  * sync: Warn when a remote's export is not updated to the current
+    tree because export tracking is not configured.
+  * Improve display when git config download from a http remote fails.
+  * Added annex.jobs setting, which is like using the -J option.
+  * Fix reversion in support of annex.web-options.
+  * rmurl: Fix a case where removing the last url left git-annex thinking
+    content was still present in the web special remote.
+  * SETURLPRESENT, SETURIPRESENT, SETURLMISSING, and SETURIMISSING
+    used to update the presence information of the external special remote
+    that called them; this was not documented behavior and is no longer done.
+  * export: Fix false positive in export conflict detection, that occurred
+    when the same tree was exported by multiple clones.
+  * Fix potential crash in exporttree database due to failure to honor
+    uniqueness constraint.
+  * Fix crash when exporttree is set to a bad value.
+  * Linux standalone: Avoid using bundled cp before envionment is fully set up.
+  * Added arm64 Linux standalone build.
+  * Improved termux installation process.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 11 Oct 2018 13:41:10 -0400
+
+git-annex (6.20180926) upstream; urgency=medium
+
+  [ Joey Hess ]
+  * Fixes a reversion in the last release that broke interoperation with
+    older versions of git-annex-shell.
+  * init: Improve generated post-receive hook, so it won't fail when
+    run on a system whose git-annex is too old to support git-annex post-receive
+  * init: Update the post-receive hook when re-run in an existing repository.
+  * S3: Fix url construction bug when the publicurl has been set to an url
+    that does not end with a slash.
+  * --debug shows urls accessed by git-annex, like it used to do when 
+    git-annex used wget and curl.
+  * Fix support for filenames containing newlines when querying git
+    cat-file, though less efficiently than other filenames.
+    This should make git-annex fully support filenames containing newlines
+    as the rest of git's interface is used in newline-safe ways.
+  * Added -z option to git-annex commands that use --batch, useful for
+    supporting filenames containing newlines.
+  * Added annex.maxextensionlength for use cases where extensions longer
+    than 4 characters are needed.
+  * Added remote.name.annex-security-allow-unverified-downloads, a
+    per-remote setting for annex.security.allow-unverified-downloads.
+  * More FreeBSD build fixes.
+
+  [ Yaroslav Halchenko ]
+  * debian/control
+    + add netbase to Depends: since required for basic tcp interactions
+      (see e.g. https://github.com/nipy/heudiconv/issues/260)
+
+ -- Joey Hess <id@joeyh.name>  Wed, 26 Sep 2018 12:56:49 -0400
+
+git-annex (6.20180913) upstream; urgency=medium
+
+  * When --batch is used with matching options like --in, --metadata,
+    etc, only operate on the provided files when they match those options.
+    Otherwise, a blank line is output in the batch protocol.
+    Affected commands: find, add, whereis, drop, copy, move, get
+  * Make metadata --batch combined with matching options refuse to run,
+    since it does not seem worth supporting that combination.
+  * v6 add: Take advantage of improved SIGPIPE handler in git 2.5 to
+    speed up the clean filter by not reading the file content from the
+    pipe. This also avoids git buffering the whole file content in memory.
+  * v6: After updating the worktree for an add/drop, update git's index,
+    so git status will not show the files as modified.
+  * v6: When annex.largefiles is not configured for a file, running git
+    add or git commit, or otherwise using git to stage a file
+    will add it to the annex if the file was in the annex before,
+    and to git otherwise. This is to avoid accidental conversion.
+    Note that git-annex add's behavior has not changed.
+  * v6: Update associated files database when git has staged changes
+    to pointer files.
+  * v6: Fix some race conditions.
+  * v6: Fix annex object file permissions when git-annex add is run
+    on a modified unlocked file, and in some related cases.
+  * v6: When a file is unlocked but has not been modified,
+    and the unlocking is only staged, git-annex add did not lock it.
+    Now it will, for consistency with how modified files are handled and
+    with v5.
+  * Fix git command queue to be concurrency safe.
+  * linux standalone: When LOCPATH is already set, use it instead of the
+    bundled locales. It can be set to an empty string to use the system
+    locales too.
+  * Stop using external hash programs, since cryptonite is faster.
+  * Fix build on FreeBSD.
+  * S3: Support buckets with versioning enabled. When a remote
+    is configured with exporttree=yes versioning=yes, git-annex can
+    download past versions of exported files from it.
+  * S3: Multipart uploads are now only supported when git-annex is built
+    with aws-0.16.0 or later, as earlier versions of the library don't
+    support versioning with multipart uploads.
+  * S3: Support AWS_SESSION_TOKEN.
+  * Don't use GIT_PREFIX when GIT_WORK_TREE=. because it seems git
+    does not intend GIT_WORK_TREE to be relative to GIT_PREFIX in that
+    case, despite GIT_WORK_TREE=.. being relative to GIT_PREFIX.
+  * Don't use GIT_PREFIX to fix up a relative GIT_DIR, because
+    git 2.11 sets GIT_PREFIX to a path it's not relative to.
+    and apparently GIT_DIR is never relative to GIT_PREFIX.
+  * git-annex.cabal: Fix build without assistant, and some other refinements.
+    Thanks fftehnik.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 13 Sep 2018 15:50:38 -0400
+
+git-annex (6.20180807) upstream; urgency=medium
+
+  * S3: Support credential-less download from remotes configured
+    with public=yes exporttree=yes.
+  * Fix reversion in display of http 404 errors.
+  * Added remote.name.annex-speculate-present config that can be used to
+    make cache remotes.
+  * Added --accessedwithin matching option.
+  * Added annex.commitmessage config that can specify a commit message
+    for the git-annex branch instead of the usual "update".
+  * Fix wrong sorting of remotes when using -J, it was sorting by uuid,
+    rather than cost.
+  * addurl: Include filename in --json-progress output.
+  * Fix git-annex branch data loss that could occur after
+    git-annex forget --drop-dead.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 07 Aug 2018 16:22:05 -0400
+
+git-annex (6.20180719) upstream; urgency=medium
+
+  * Support working trees set up by git-worktree.
+  * Improve support for repositories created with --separate-git-dir.
+  * Support configuring remote.web.annex-cost and remote.bittorrent.annex-cost
+  * addurl: When security configuration prevents downloads with youtube-dl,
+    still check if the url is one that it supports, and fail downloading
+    it, instead of downloading the raw web page.
+  * Send User-Agent and any configured annex.http-headers when downloading
+    with http, fixes reversion introduced when switching to http-client.
+  * Fix reversion introduced in version 6.20180316 that caused git-annex to
+    stop processing files when unable to contact a ssh remote.
+  * v6: Work around git bug that runs smudge/clean filters at the top of the
+    repository while passing them a relative GIT_WORK_TREE that may point
+    outside of the repository, by using GIT_PREFIX to get back to the
+    subdirectory where a relative GIT_WORK_TREE is valid.
+  * p2p --pair: Fix interception of the magic-wormhole pairing code,
+    which since 0.8.2 it has sent to stderr rather than stdout.
+  * info: Display uuid and description when a repository is identified by
+    uuid, and for "here".
+  * unused --from: Allow specifiying a repository by uuid or description.
+  * linux standalone: Generate locale files in ~/.cache/git-annex/locales/
+    so they're available even when the standalone tarball is installed
+    in a directory owned by root. Note that this prevents using the
+    standalone bundle in environments where HOME is not writable.
+  * Include uname command in standalone builds since git-annex uses it.
+  * git-annex.cabal: Fix network version.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 19 Jul 2018 13:53:45 -0400
+
+git-annex (6.20180626) upstream; urgency=high
+
+  Security fix release for CVE-2018-10857 and CVE-2018-10859
+  https://git-annex.branchable.com/security/CVE-2018-10857_and_CVE-2018-10859/
+
+  * Refuse to download content, that cannot be verified with a hash, 
+    from encrypted special remotes (for CVE-2018-10859),
+    and from all external special remotes and glacier (for CVE-2018-10857).
+    In particular, URL and WORM keys stored on such remotes won't
+    be downloaded. If this affects your files, you can run
+    `git-annex migrate` on the affected files, to convert them
+    to use a hash.
+  * Added annex.security.allow-unverified-downloads, which can override
+    the above.
+  * Added annex.security.allowed-url-schemes setting, which defaults
+    to only allowing http, https, and ftp URLs. Note especially that file:/
+    is no longer enabled by default.
+  * Removed annex.web-download-command, since its interface does not allow
+    supporting annex.security.allowed-url-schemes across redirects.
+    If you used this setting, you may want to instead use annex.web-options
+    to pass options to curl.
+  * git-annex will refuse to download content from http servers on
+    localhost, or any private IP addresses, to prevent accidental
+    exposure of internal data. This can be overridden with the
+    annex.security.allowed-http-addresses setting.
+  * Local http proxies will not be used unless allowed by the
+    annex.security.allowed-http-addresses setting.
+  * Since the interfaces to curl and youtube-dl do not have a way to
+    prevent them from accessing localhost or private IP addresses,
+    they default to not being used for url downloads.
+    Only when annex.security.allowed-http-addresses=all will curl and
+    youtube-dl be used.
+ 
+  Non-security fix changes:
+
+  * Fix build with ghc 8.4+, which broke due to the Semigroup Monoid change. 
+  * version: Show operating system and repository version list 
+    when run outside a git repo too.
+  * Fix annex-checkuuid implementation, so that remotes configured that
+    way can be used.
+  * Fix problems accessing repositories over http when annex.tune.*
+    is configured.
+  * External special remotes can now add info to `git annex info $remote`,
+    by replying to the GETINFO message.
+  * adb: Android serial numbers are not all 16 characters long, so accept
+    other lengths.
+  * Display error messages that come from git-annex-shell when the p2p
+    protocol is used, so that diskreserve messages, IO errors, etc from
+    the remote side are visible again.
+  * When content has been lost from an export remote and 
+    git-annex fsck --from remote has noticed it's gone, re-running
+    git-annex export or git-annex sync --content will re-upload it.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 22 Jun 2018 10:36:22 -0400
+
+git-annex (6.20180529) upstream; urgency=medium
+
+  * Prevent haskell http-client from decompressing gzip files, so downloads
+    of such files works the same as it used to with wget and curl.
+  * Workaround for bug in an old version of cryptonite that broke https
+    downloads, by using curl for downloads when git-annex is built with it.
+  * view, vadd: Fix crash when a git submodule has a name starting with a dot.
+  * Don't allow entering a view with staged or unstaged changes.
+  * move: --force was accidentially enabling two unrelated behaviors
+    since 6.20180427. The older behavior, which has never been well
+    documented and seems almost entirely useless, has been removed.
+  * copy: --force no longer does anything.
+  * migrate: Fix bug in migration between eg SHA256 and SHA256E, 
+    that caused the extension to be included in SHA256 keys,
+    and omitted from SHA256E keys.
+    (Bug introduced in version 6.20170214)
+  * migrate: Check for above bug when migrating from SHA256 to SHA256
+    (and same for SHA1 to SHA1 etc), and remove the extension that should
+    not be in the SHA256 key.
+  * fsck: Detect and warn when keys need an upgrade, either to fix up
+    from the above migrate bug, or to add missing size information
+    (a long ago transition), or because of a few other past key related
+    bugs.
+  * git-annex-shell: GIT_ANNEX_SHELL_APPENDONLY makes it allow writes,
+    but not deletion of annexed content. Note that securing pushes to
+    the git repository is left up to the user.
+  * setpresentkey: Added --batch support.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 29 May 2018 13:05:26 -0400
+
+git-annex (6.20180509) upstream; urgency=medium
+
+  * The old git-annex Android app is now deprecated in favor of running
+    git-annex in termux.
+  * runshell: Use proot when running on Android, to work around
+    Android 8's ill-advised seccomp filtering of system calls,
+    including ones crucial for reliable thread locking.
+    (This will only work with termux's version of proot.)
+  * Fix bug in last release that crashes when using
+    --all or running git-annex in a bare repository. May have also
+    affected git-annex unused and git-annex info.
+  * Fix bug in last release that prevented the webapp opening on
+    non-Linux systems.
+  * Support building with hinotify-0.3.10.
+  * Display error message when http download fails.
+  * Avoid forward retry when 0 bytes were received.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 09 May 2018 16:20:26 -0400
+
+git-annex (6.20180427) upstream; urgency=medium
+
+  * move: Now takes numcopies configuration, and required content
+    configuration into account, and refuses to reduce the current
+    number of copies of a file, or remove content that a repository
+    requires. --force can override these checks.
+    Note that it's still allowed to move the content of a file
+    from one repository to another when numcopies is not satisfied, as long
+    as the move does not result in there being fewer copies.
+  * Fix mangling of --json output of utf-8 characters when not
+    running in a utf-8 locale.
+  * Fix build with yesod 1.6.
+  * Clean up some build warnings with newer versions of ghc and haskell
+    libraries.
+  * runshell: Unset LD_PRELOAD since preloaded libraries from the host
+    system may not get along with the bundled linker.
+  * runshell: Added some tweaks to make git-annex work in termux on
+    Android. The regular arm standalone tarball now works in termux.
+  * Webapp: Support being run inside termux on Android, and offer to set up
+    a repository on the sdcard.
+  * Assistant: Integrate with Termux:Boot, so when it's installed, the
+    assistant is autostarted on boot.
+  * Assistant: Fix installation of menus, icons, etc when run
+    from within runshell.
+  * import: Avoid buffering all filenames to be imported in memory.
+  * Improve memory use and speed of --all and git-annex info remote,
+    by not buffering list of all keys.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 27 Apr 2018 12:36:20 -0400
+
+git-annex (6.20180409) upstream; urgency=medium
+
+  * Added adb special remote which allows exporting files to Android devices.
+  * For url downloads, git-annex now defaults to using a http library,
+    rather than wget or curl. But, if annex.web-options is set, it will
+    use curl. To use the .netrc file, run: 
+      git config annex.web-options --netrc
+  * git-annex no longer uses wget (and wget is no longer shipped with
+    git-annex builds).
+  * Enable HTTP connection reuse across multiple files for improved speed.
+  * Fix calculation of estimated completion for progress meter.
+  * OSX app: Work around libz/libPng/ImageIO.framework version skew
+    by not bundling libz, assuming OSX includes a suitable libz.1.dylib.
+  * Added annex.retry, annex.retry-delay, and per-remote versions
+    to configure transfer retries.
+  * Also do forward retrying in cases where no exception is thrown,
+    but the transfer failed.
+  * When adding a new version of a file, and annex.genmetadata is enabled,
+    don't copy the data metadata from the old version of the file,
+    instead use the mtime of the file.
+  * Avoid running annex.http-headers-command more than once.
+  * info: Added "combined size of repositories containing these files"
+    stat when run on a directory.
+  * info: Changed sorting of numcopies stats table, so it's ordered
+    by the variance from the desired number of copies.
+  * Fix resuming a download when using curl.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 09 Apr 2018 13:03:15 -0400
+
+git-annex (6.20180316) upstream; urgency=medium
+
+  * New protocol for communicating with git-annex-shell increases speed
+    of operations involving ssh remotes. When not transferring large files,
+    git-annex is between 200% and 400% faster using the new protocol,
+    and it's just as fast as before when transferring large files.
+    (When the remote has an old git-annex-shell, git-annex falls back
+    to the old slower code. This fallback is planned to be removed 
+    after 5 years or so.)
+  * Note that, due to not using rsync to transfer files over ssh
+    any longer, permissions and other file metadata of annexed files
+    will no longer be preserved when copying them to and from ssh remotes.
+    Other remotes never supported preserving that information, so
+    this is not considered a regression.
+  * Fix data loss bug in content locking over tor, when the remote
+    repository is in direct mode, it neglected to check that the content
+    was actually present when locking it. This could cause git annex drop
+    to remove the only copy of a file when it thought the tor remote had
+    a copy.
+  * Fix data loss bug when the local repository uses direct mode, and a
+    locally modified file is dropped from a remote repsitory. The bug
+    caused the modified file to be counted as a copy of the original file.
+    (This is not a severe bug because in such a situation, dropping
+    from the remote and then modifying the file is allowed and has the same
+    end result.)
+  * Some downloads will be verified, even when annex.verify=false.
+    This is done in some edge cases where there's a likelyhood than an
+    object was downloaded incorrectly.
+  * Support exporttree=yes for rsync special remotes.
+  * Added backends for the BLAKE2 family of hashes, when built with
+    a new enough version of cryptonite.
+  * Improve SHA*E extension extraction code to not treat parts of the
+    filename that contain punctuation or other non-alphanumeric characters
+    as extensions. Before, such characters were filtered out.
+  * Better ssh connection warmup when using -J for concurrency.
+    Avoids ugly messages when forced ssh command is not git-annex-shell.
+  * Fix race condition in ssh warmup that caused git-annex to get
+    stuck and never process some files when run with high levels of
+    concurrency.
+  * Fix reversion introduced in 6.20171214 that caused concurrent
+    transfers to incorrectly fail with "transfer already in progress".
+  * Note that Remote/Git.hs now contains AGPL licensed code,
+    thus the license of git-annex as a whole is AGPL. This was already
+    the case when git-annex was built with the webapp enabled.
+  * Include amount of data transferred in progress display.
+  * Dial back optimisation when building on arm, which prevents
+    ghc and llc from running out of memory when optimising some files.
+    (Unfortunately this fix is incomplete due to a ghc bug.)
+
+ -- Joey Hess <id@joeyh.name>  Fri, 16 Mar 2018 12:10:40 -0400
+
+git-annex (6.20180227) upstream; urgency=medium
+
+  * inprogress: Avoid showing failures for files not in progress. 
+  * Added INFO to external special remote protocol.
+  * Added EXTENSIONS to external special remote protocol.
+  * datalad < 0.9.1 had a problem in its special remote protocol handling
+    which is broken by EXTENSIONS. Make the debian git-annex package
+    conflict with the problem version of datalad.
+  * fsck: Warn when required content is not present in the repository that
+    requires it.
+  * Add gpg-agent to Build-Depends.
+    Needed to run the test suite.
+  * --json: When there are multiple lines of notes about a file, make the note
+    field multiline, rather than the old behavior of only including the
+    last line.
+  * git-annex.cabal: Once more try to not build the assistant on the hurd,
+    hopefully hackage finally recognises that OS.
+  * Split Test.hs and avoid optimising it much, to need less memory to
+    compile.
+  * Fix behavior of --json-progress followed by --json, the latter option
+    used to disable the former.
+  * Added --json-error-messages option, which makes messages
+    that would normally be output to standard error be included in
+    the json output.
+  * Remove temporary code added in 6.20160619 to prime the mergedrefs
+    log.
+  * importfeed: Fix a failure when downloading with youtube-dl
+    and the destination subdirectory does not exist yet.
+  * Added annex.merge-annex-branches config setting which
+    can be used to disable automatic merge of git-annex branches.
+  * tips/automatically_adding_metadata/pre-commit-annex: Fix to not
+    silently skip filenames containing non-ascii characters.
+  * sync: Fix bug that prevented pulling changes into direct mode
+    repositories that were committed to remotes using git commit
+    rather than git-annex sync.
+  * Makefile: Remove chrpath workaround for bug in cabal, 
+    which is no longer needed.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 27 Feb 2018 12:04:52 -0400
+
+git-annex (6.20180112) upstream; urgency=medium
+
+  * Added inprogress command for accessing files as they are being
+    downloaded.
+  * Fix bug introduced in version 6.20171018 that caused some commands
+    to print out "ok" twice after processing a file.
+  * addurl: When the file youtube-dl will download is already an annexed
+    file, don't download it again and fail to overwrite it, instead just do
+    nothing, like it used to when quvi was used.
+  * addurl: Fix encoding of filename queried from youtube-dl when in
+    --fast mode.
+  * Fix several places where files in .git/annex/ were written with modes
+    that did not take the core.sharedRepository config into account.
+  * Improve startup time for commands that do not operate on remotes,
+    and for tab completion, by not unnessessarily statting paths to
+    remotes, which used to cause eg, spin-up of removable drives.
+  * Added remote.<name>.annex-checkuuid config, which can be set to false
+    to disable the default checking of the uuid of remotes that point to
+    directories. This can be useful to avoid unnecessary drive spin-ups and
+    automounting.
+  * git-annex.cabal: Add back custom-setup stanza, so cabal new-build works.
+  * git-annex.cabal: Removed the testsuite build flag; test suite is always
+    included.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 12 Jan 2018 15:45:48 -0400
+
+git-annex (6.20171214) upstream; urgency=medium
+
+  * Use youtube-dl rather than quvi to download media from web pages,
+    since quvi is not being actively developed and youtube-dl supports
+    many more sites.
+  * addurl --relaxed got slower, since youtube-dl has to hit the network
+    to check for embedded media. If you relied on --relaxed not hitting the
+    network for speed reasons, using --relaxed --raw will get the old level
+    of speed, but can't be used for urls with embedded videos.
+  * importfeed now downloads things linked to by feeds, even when they are
+    not media files.
+  * Removed no longer needed dependency on yesod-default.
+  * Allow exporttree remotes to be marked as dead.
+  * initremote, enableremote: Really support gpg subkeys suffixed with an
+    exclamation mark, which forces gpg to use a specific subkey.
+    (Previous try had a bug.)
+  * lookupkey: Support being given an absolute filename to a file
+    within the current git repository.
+  * A top-level .noannex file will prevent git-annex init from being used
+    in a repository. This is useful for repositories that have a policy
+    reason not to use git-annex. The content of the file will be displayed
+    to the user who tries to run git-annex init.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 14 Dec 2017 11:50:48 -0400
+
+git-annex (6.20171124) unstable; urgency=medium
+
+  * Display progress meter when uploading a key without size information,
+    getting the size by statting the content file.
+  * Fix build with dns-3.0.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 24 Nov 2017 10:49:36 -0400
+
+git-annex (6.20171109) unstable; urgency=medium
+
+  * Fix export of subdir of a branch.
+  * Fix exporting of non-annexed files to external special remotes.
+  * unlock, lock: Support --json.
+  * When there are multiple urls for a file, still treat it as being present
+    in the web when some urls don't work, as long as at least one url does
+    work.
+  * Makefile improvement for sudo make install.
+    Thanks, Eric Siegerman 
+  * Makefile improvement for BUILDER=stack, use stack to run ghc.
+  * testremote: Test exporttree.
+  * Fix directory special remote's cleanup of empty export directories.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 09 Nov 2017 12:21:49 -0400
+
+git-annex (6.20171026) unstable; urgency=medium
+
+  * Windows: Fix reversion that caused the path used to link
+    to annexed content to include the drive letter and full path, rather
+    than being relative. (`git annex fix` will fix up after this problem).
+  * Windows build fixed, and changed to use stack for more reliable build
+    environment.
+  * Windows: Remove wget from bundle; it needs libraries that are not
+    included, and git for windows includes curl which git-annex will use
+    instead.
+  * Add day to metadata when annex.genmetadata is enabled.
+    Thanks, Sean T Parsons
+  * stack.yaml: Added nix packages section.
+    Thanks, Sean T Parsons 
+
+ -- Joey Hess <id@joeyh.name>  Thu, 26 Oct 2017 13:56:18 -0400
+
+git-annex (6.20171018) unstable; urgency=medium
+
+  * add: Replace work tree file atomically on systems supporting hard
+    links. Avoids a window where interrupting an add could result in
+    the file being moved into the annex, with no symlink yet created.
+  * webdav: Avoid unncessisarily creating the collection at the top
+    of the repository when storing files there, since that collection
+    is created by initremote.
+    (This seems to work around some brokenness of the box.com webdav
+    server, which caused uploads to be very slow or sometimes fail.)
+  * webdav: Make --debug show all webdav operations.
+  * get -J/move -J/copy -J/mirror -J/sync -J: Avoid "transfer already in
+    progress" errors when two files use the same key.
+  * Konqueror desktop file location changed to one used by plasma 5.
+    Thanks, Félix Sipma.
+  * Avoid repeated checking that files passed on the command line exist.
+  * Fix build with aws-0.17.
+  * stack.yaml: Update to lts-9.9.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 18 Oct 2017 15:40:06 -0400
+
+git-annex (6.20171003) unstable; urgency=medium
+
+  * webdav: Improve error message for failed request to include the request
+    method and path.
+  * metadata: Added --remove-all.
+  * Warn when metadata is inherited from a previous version of a file,
+    to avoid the user being surprised in cases where that behavior is not
+    desired or expected.
+  * sync: Added --cleanup, which removes local and remote synced/ branches.
+  * external: When the external special remote program crashed, a newline
+    could be output, which messed up the expected output for --batch mode.
+  * external: Avoid checking EXPORTSUPPORTED for special remotes that are
+    not configured to use exports.
+  * test: Fix reversion that made it only run inside a git repository.
+  * copy, move: Behave same with --fast when sending to remotes located
+    on a local disk as when sending to other remotes.
+  * Fix process and file descriptor leak that was exposed when
+    git-annex was built with ghc 8.2.1. Broke git-annex test on OSX
+    due to running out of FDs, and may have also leaked in other situations.
+  * info: Improve cleanup of stale transfer info files.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 03 Oct 2017 13:18:15 -0400
+
+git-annex (6.20170925) unstable; urgency=medium
+
+  * git-annex export: New command, can create and efficiently update
+    exports of trees to special remotes.
+  * Use git-annex initremote with exporttree=yes to set up a special remote
+    for use by git-annex export.
+  * Implemented export to directory, S3, and webdav special remotes.
+  * External special remote protocol extended to support export.
+    Developers of external special remotes should consider if export makes
+    sense for them and add support.
+  * sync, assistant: Update tracking exports.
+  * Support building with feed-1.0, while still supporting older versions.
+  * init: Display an additional message when it detects a filesystem that
+    allows writing to files whose write bit is not set.
+  * S3: Allow removing files from IA.
+  * webdav: Checking if a non-existent file is present on Box.com
+    triggered a bug in its webdav support that generates an infinite series
+    of redirects. Deal with such problems by assuming such behavior means
+    the file is not present.
+  * webdav: Fix lack of url-escaping of filenames. Mostly impacted exports
+    of filenames containing eg spaces.
+  * webdav: Changed path used on webdav server for temporary files.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 25 Sep 2017 11:13:58 -0400
+
+git-annex (6.20170818) unstable; urgency=high
+
+  * Security fix: Disallow hostname starting with a dash, which
+    would get passed to ssh and be treated an option. This could
+    be used by an attacker who provides a crafted repository url
+    to cause the victim to execute arbitrary code via -oProxyCommand.
+    CVE-2017-12976
+    (The same class of security hole recently affected git itself.)
+  * git-annex.cabal: Deal with breaking changes in Cabal 2.0.
+  * Fix build with QuickCheck 2.10.
+  * fsck: Support --json.
+  * move, copy: Support --batch.
+  * Added GIT_ANNEX_VECTOR_CLOCK environment variable, which can be used to
+    override the default timestamps used in log files in the git-annex
+    branch. This is a dangerous environment variable; use with caution.
+  * Fix a git-annex test failure when run on NFS due to NFS lock files
+    preventing directory removal.
+  * test: Avoid most situations involving failure to delete test
+    directories, by forking a worker process and only deleting the test
+    directory once it exits.
+  * Disable http-client's default 30 second response timeout when HEADing
+    an url to check if it exists. Some web servers take quite a long time
+    to answer a HEAD request.
+  * Added remote configuration settings annex-ignore-command and
+    annex-sync-command, which are dynamic equivilants of the annex-ignore
+    and annex-sync configurations.
+  * Prevent spaces from being embedded in the name of new WORM keys,
+    as that handing spaces in keys would complicate things like the
+    external special remote protocol.
+  * migrate: WORM keys containing spaces will be migrated to not contain
+    spaces anymore.
+  * External special remotes will refuse to operate on keys with spaces in
+    their names. That has never worked correctly due to the design of the
+    external special remote protocol. Display an error message suggesting
+    migration.
+  * Fix incorrect external special remote documentation, which said that
+    the filename parameter to the TRANSFER command could not contain
+    spaces. It can in fact contain spaces. Special remotes implementors
+    that relied on that may need to fix bugs in their special remotes.
+  * Fix the external special remotes git-annex-remote-ipfs, 
+    git-annex-remote-torrent and the example.sh template to correctly
+    support filenames with spaces.
+  * Windows: Win32 package has subsumed Win32-extras; update dependency.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 18 Aug 2017 11:19:06 -0400
+
+git-annex (6.20170520) unstable; urgency=medium
+
+  * move --to=here moves from all reachable remotes to the local repository.
+  * initremote, enableremote: Support gpg subkeys suffixed with an
+    exclamation mark, which forces gpg to use a specific subkey.
+  * Improve progress display when watching file size, in cases where
+    a transfer does not resume.
+  * Fix transfer log file locking problem when running concurrent
+    transfers.
+  * Avoid concurrent git-config setting problem when running concurrent
+    threads.
+  * metadata: When setting metadata of a file that did not exist,
+    no error message was displayed, unlike getting metadata and most other
+    git-annex commands. Fixed this oversight.
+  * Added annex.resolvemerge configuration, which can be set to false to 
+    disable the usual automatic merge conflict resolution done by git-annex
+    sync and the assistant.
+  * sync: Added --no-resolvemerge option.
+  * Avoid error about git-annex-shell not being found when
+    syncing with -J with a git remote where git-annex-shell is not
+    installed.
+  * Fix bug that prevented transfer locks from working when
+    run on SMB or other filesystem that does not support fcntl locks
+    and hard links.
+  * assistant: Merge changes from refs/remotes/foo/master into master.
+    Previously, only sync branches were merged. This makes regular git push
+    into a repository watched by the assistant auto-merge.
+  * Makefile: Install completions for the fish and zsh shells
+    when git-annex is built with optparse-applicative-0.14.
+  * assistant: Don't trust OSX FSEvents's eventFlagItemModified to be called
+    when the last writer of a file closes it; apparently that sometimes
+    does not happen, which prevented files from being quickly added.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 12 Jun 2017 13:37:16 -0400
+
+git-annex (6.20170519) unstable; urgency=medium
+
+  * Ssh password prompting improved when using -J for concurrency.
+    When ssh connection caching is enabled (and when GIT_ANNEX_USE_GIT_SSH
+    is not set), only one ssh password prompt will be made per host, and
+    only one ssh password prompt will be made at a time.
+  * When built with concurrent-output 1.9, ssh password prompts will no
+    longer interfere with the -J display.
+  * Removed dependency on MissingH, instead depending on the split library.
+  * Progress is displayed for transfers of files of unknown size.
+  * Work around bug in git 2.13.0 involving GIT_COMMON_DIR that broke
+    merging changes into adjusted branches.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 19 May 2017 10:37:57 -0400
+
+git-annex (6.20170510) unstable; urgency=medium
+
+  * When a http remote does not expose an annex.uuid config, only warn
+    about it once, not every time git-annex is run.
+  * multicast: New command, uses uftp to multicast annexed files, for eg
+    a classroom setting.
+  * Added remote.<name>.annex-push and remote.<name>.annex-pull
+    which can be useful to make remotes that don't get fully synced with
+    local changes.
+  * Disable git-annex's support for GIT_SSH and GIT_SSH_COMMAND, unless
+    GIT_ANNEX_USE_GIT_SSH=1 is also set in the environment. This is
+    necessary because as feared, the extra -n parameter that git-annex
+    passes breaks uses of these environment variables that expect exactly
+    the parameters that git passes.
+  * enableremote: When enabling a non-special remote, param=value
+    parameters can't be used, so error out if any are provided.
+  * enableremote: Fix re-enabling of special remotes that have a git
+    url, so that eg, encryption key changes take effect. They were silently
+    ignored, a reversion introduced in 6.20160527.
+  * gcrypt: Support re-enabling to change eg, encryption parameters.
+    This was never supported before.
+  * git annex add -u now supported, analagous to git add -u
+  * version: Added "dependency versions" line.
+  * Keys marked as dead are now skipped by --all.
+  * annex.backend is the new name for what was annex.backends, and takes
+    a single key-value backend, rather than the unnecessary and confusing
+    list. The old option still works if set.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 10 May 2017 15:05:22 -0400
+
+git-annex (6.20170321) unstable; urgency=medium
+
+  * Bugfix: Passing a command a filename that does not exist sometimes
+    did not display an error, when a path to a directory was also passed.
+  * status: Propigate nonzero exit code from git status.
+  * Linux standalone builds put the bundled ssh last in PATH,
+    so any system ssh will be preferred over it.
+  * assistant: Add 1/200th second delay between checking each file
+    in the full transfer scan, to avoid using too much CPU.
+  * get -J: Improve distribution of jobs amoung remotes when there are more
+    jobs than remotes.
+  * fsck -q: When a file has bad content, include the name of the file
+    in the warning message.
+  * Windows: Improve handling of shebang in external special remote
+    program, searching for the program in the PATH.
+  * Drop support for building with old versions of dns, http-conduit,
+    directory, feed, and http-types.
+  * Windows: Fix bug in shell script shebang lookup code that
+    caused a "delayed read on closed handle" error.
+  * git-annex-shell: Fix bug when used with a recently cloned repository,
+    where "merging" messages were included in the output of configlist
+    (and perhaps other commands) and caused a "Failed to get annex.uuid
+    configuration" error.
+  * Support GIT_SSH and GIT_SSH_COMMAND, which are handled close the same
+    as they are by git. However, unlike git, git-annex sometimes needs to
+    pass the -n parameter when using these.
+  * sync --content-of=path (-C path) added for when you want to sync
+    only some files' contents, not the whole working tree.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 21 Mar 2017 11:27:38 -0400
+
+git-annex (6.20170301.1) unstable; urgency=medium
+
+  * Fix reversion in yesterday's release that made SHA1E and MD5E backends
+    not work.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 01 Mar 2017 12:46:03 -0400
+
+git-annex (6.20170301) unstable; urgency=medium
+
+  * No changes from 6.20170228; a new version number was needed due
+    to a problem with Hackage.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 01 Mar 2017 12:06:02 -0400
+
+git-annex (6.20170228) unstable; urgency=medium
+
+  * Cryptographically secure hashes can be forced to be used in a
+    repository, by setting annex.securehashesonly.
+    This does not prevent the git repository from containing links
+    to insecure hashes, but it does prevent the content of such files
+    from being added to .git/annex/objects by any method.
+  * Tighten key parser to prevent SHA1 collision attacks generating
+    two keys that have the same SHA1. (Only done for keys that contain
+    a hash). This ensures that signed git commits of annexed files
+    will remain secure, as long as git-annex is using a secure hashing
+    backend.
+  * fsck: Warn about any files whose content is present, that don't
+    use secure hashes, when annex.securehashesonly is set.
+  * init: When annex.securehashesonly has been set with git-annex config,
+    copy that value to the annex.securehashesonly git config.
+  * Added --securehash option to match files using a secure hash function,
+    and corresponding securehash preferred content expression.
+  * sync, merge: Fail when the current branch has no commits yet, instead
+    of not merging in anything from remotes and appearing to succeed.
+  * Run ssh with -n whenever input is not being piped into it,
+    to avoid it consuming stdin that it shouldn't.
+    This fixes git-annex-checkpresentkey --batch remote,
+    which didn't output results for all keys passed into it. Other
+    git-annex commands that communicate with a remote over ssh may also
+    have been consuming stdin that they shouldn't have, which could have
+    impacted using them in eg, shell scripts.
+  * sync: Improve integration with receive.denyCurrentBranch=updateInstead,
+    displaying error messages from the remote then it fails to update
+    its checked out branch.
+  * Added post-recieve hook, which makes updateInstead work with direct
+    mode and adjusted branches.
+  * init: Set up the post-receive hook.
+  * sync: When syncing with a local repository located on a crippled
+    filesystem, run the post-receive hook there, since it wouldn't get run
+    otherwise. This makes pushing to repos on FAT-formatted removable
+    drives update them when receive.denyCurrentBranch=updateInstead.
+  * config group groupwanted numcopies schedule wanted required: 
+    Avoid displaying extraneous messages about repository auto-init,
+    git-annex branch merging, etc, when being used to get information.
+  * adjust: Fix behavior when used in a repository that contains
+    submodules.
+  * Run wget with -nv instead of -q, so it will display HTTP errors.
+  * Run curl with -S, so HTTP errors are displayed, even when
+    it's otherwise silent.
+  * When downloading in --json or --quiet mode, use curl in preference
+    to wget, since curl is able to display only errors to stderr, unlike
+    wget.
+  * status: Pass --ignore-submodules=when option on to git status.
+  * config --set: As well as setting value in git-annex branch,
+    set local gitconfig. This is needed especially for
+    annex.securehashesonly, which is read only from local gitconfig and not
+    the git-annex branch.
+  * Removed support for building with the old cryptohash library.
+    Building with that library made git-annex not support SHA3; it's time
+    for that to always be supported in case SHA2 dominoes.
+  * git-annex.cabal: Make crypto-api a dependency even when built w/o
+    webapp and test suite.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 28 Feb 2017 14:39:47 -0400
+
+git-annex (6.20170214) unstable; urgency=medium
+
+  * Increase default cost for p2p remotes from 200 to 1000.
+    This makes git-annex prefer transferring data from special
+    remotes when possible.
+  * Remove -j short option for --json-progress; that option was already
+    taken for --json.
+  * vicfg: Include the numcopies configuation.
+  * config: New command for storing configuration in the git-annex branch.
+  * annex.autocommit can be configured via git-annex config, to control
+    the default behavior in all clones of a repository.
+  * New annex.synccontent config setting, which can be set to true to make
+    git annex sync default to --content. This may become the default at
+    some point in the future. As well as being configuable by git config,
+    it can be configured by git-annex config to control the default
+    behavior in all clones of a repository.
+  * stack.yaml: Update to lts-7.18.
+  * Some optimisations to string splitting code.
+  * unused: When large files are checked right into git, avoid buffering
+    their contents in memory.
+  * unused: Improved memory use significantly when there are a lot
+    of differences between branches.
+  * Wormhole pairing will start to provide an appid to wormhole on
+    2021-12-31. An appid can't be provided now because Debian stable is going
+    to ship a older version of git-annex that does not provide an appid.
+    Assumption is that by 2021-12-31, this version of git-annex will be
+    shipped in a Debian stable release. If that turns out to not be the
+    case, this change will need to be cherry-picked into the git-annex in
+    Debian stable, or its wormhole pairing will break.
+  * Fix build with aws 0.16. Thanks, aristidb.
+  * assistant: Make --autostart --foreground wait for the children it
+    starts. Before, the --foreground was ignored when autostarting.
+  * initremote: When a uuid= parameter is passed, use the specified
+    UUID for the new special remote, instead of generating a UUID.
+    This can be useful in some situations, eg when the same data can be
+    accessed via two different special remote backends.
+  * import: Changed how --deduplicate, --skip-duplicates, and
+    --clean-duplicates determine if a file is a duplicate.
+    Before, only content known to be present somewhere was considered
+    a duplicate. Now, any content that has been annexed before will be
+    considered a duplicate, even if all annexed copies of the data have
+    been lost.
+    Note that --clean-duplicates and --deduplicate still check
+    numcopies, so won't delete duplicate files unless there's an annexed
+    copy.
+  * import: --deduplicate and --skip-duplicates were implemented
+    inneficiently; they unncessarily hashed each file twice. They have
+    been improved to only hash once.
+  * import: Added --reinject-duplicates.
+  * Added git template directory to Linux standalone tarball and OSX
+    app bundle.
+  * Improve pid locking code to work on filesystems that don't support hard
+    links.
+  * S3: Fix check of uuid file stored in bucket, which was not working.
+  * Work around sqlite's incorrect handling of umask when creating
+    databases.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 14 Feb 2017 14:22:00 -0400
+
+git-annex (6.20170101) unstable; urgency=medium
+
+  * XMPP support has been removed from the assistant in this release.
+    If your repositories used XMPP to keep in sync, that will no longer
+    work, and you should enable some other remote to keep them in sync.
+    A ssh server is one way, or use the new Tor pairing feature.
+  * p2p --pair makes it easy to pair repositories, over Tor, using
+    Magic Wormhole codes to find the other repository.
+    See http://git-annex.branchable.com/tips/peer_to_peer_network_with_tor/
+  * webapp: The "Share with a friend" and "Share with your other devices"
+    pages have been changed to pair repositories using Tor and Magic Wormhole.
+  * metadata --batch: Fix bug when conflicting metadata changes were
+    made in the same batch run.
+  * Pass annex.web-options to wget and curl after other options, so that
+    eg --no-show-progress can be set by the user to disable the default
+    --show-progress.
+  * Revert ServerAliveInterval change in 6.20161111, which caused problems
+    with too many old versions of ssh and unusual ssh configurations.
+    It should have not been needed anyway since ssh is supposted to
+    have TCPKeepAlive enabled by default.
+  * Make all --batch input, as well as fromkey and registerurl stdin
+    be processed without requiring it to be in the current encoding.
+  * p2p: --link no longer takes a remote name, instead the --name
+    option can be used.
+  * Linux standalone: Improve generation of locale definition files,
+    supporting locales such as en_GB.UTF-8.
+  * rekey --force: Incorrectly marked the new key's content as being
+    present in the local repo even when it was not.
+  * enable-tor: Put tor sockets in /var/lib/tor-annex/, rather
+    than in /etc/tor/hidden_service/.
+  * enable-tor: No longer needs to be run as root.
+  * enable-tor: When run as a regular user, also tests a connection back to 
+    the hidden service over tor.
+  * Support all common locations of the torrc file.
+  * Always use filesystem encoding for all file and handle reads and
+    writes.
+  * Fix build with directory-1.3.
+  * Debian: Suggest tor and magic-wormhole.
+  * Debian: Build webapp on armel.
+
+ -- Joey Hess <id@joeyh.name>  Sat, 31 Dec 2016 15:11:04 -0400
+
+git-annex (6.20161210) unstable; urgency=medium
+
+  * Linux standalone: Updated ghc to fix its "unable to decommit memory"
+    bug, which may have resulted in data loss when these builds were used
+    with Linux kernels older than 4.5.
+  * enable-tor: New command, enables tor hidden service for P2P syncing.
+  * p2p: New command, allows linking repositories using a P2P network.
+  * remotedaemon: Serve tor hidden service.
+  * Added git-remote-tor-annex, which allows git pull and push to the tor
+    hidden service.
+  * remotedaemon: Fork to background by default. Added --foreground switch
+    to enable old behavior.
+  * addurl: Fix bug in checking annex.largefiles expressions using
+    largerthan, mimetype, and smallerthan; the first two always failed
+    to match, and the latter always matched.
+  * Relicense 5 source files that are not part of the webapp from AGPL to GPL.
+  * map: Run xdot if it's available in PATH. On OSX, the dot command
+    does not support graphical display, while xdot does.
+  * Debian: xdot is a better interactive viewer than dot, so Suggest
+    xdot, rather than graphviz.
+  * rmurl: Multiple pairs of files and urls can be provided on the
+    command line.
+  * rmurl: Added --batch mode.
+  * fromkey: Accept multiple pairs of files and keys.
+    Thanks, Daniel Brooks.
+  * rekey: Added --batch mode.
+  * add: Stage modified non-large files when running in indirect mode. 
+    (This was already done in v6 mode and direct mode.)
+  * git-annex-shell, remotedaemon, git remote: Fix some memory DOS attacks.
+  * Fix build with http-client 0.5.
+    Thanks, Alper Nebi Yasak.
+
+ -- Joey Hess <id@joeyh.name>  Sat, 10 Dec 2016 11:56:25 -0400
+
+git-annex (6.20161118) unstable; urgency=medium
+
+  * git-annex.cabal: Loosen bounds on persistent to allow 2.5, which
+    on Debian has been patched to work with esqueleto.
+    This may break cabal's resolver on non-Debian systems;
+    if so, either use stack to build, or run cabal with 
+    --constraint='persistent ==2.2.4.1'
+    Hopefully this mess with esqueleto will be resolved soon.
+  * sync: Pass --allow-unrelated-histories to git merge when used with git
+    git 2.9.0 or newer. This makes merging a remote into a freshly created
+    direct mode repository work the same as it works in indirect mode.
+  * Avoid backtraces on expected failures when built with ghc 8;
+    only use backtraces for unexpected errors.
+  * fsck --all --from was checking the existence and content of files
+    in the local repository, rather than on the special remote. Oops.
+  * Linux arm standalone: Build with a 32kb page size, which is needed
+    on several ARM NAS devices, including Drobo 5N, and WD NAS.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 18 Nov 2016 11:43:14 -0400
+
+git-annex (6.20161111) unstable; urgency=medium
+
+  * Restarting a crashing git process could result in filename encoding
+    issues when not in a unicode locale, as the restarted processes's
+    handles were not read in raw mode.
+  * Make .git/annex/ssh.config file work with versions of ssh older than
+    7.3, which don't support Include. When used with an older version
+    of ssh, any ServerAliveInterval in ~/.ssh/config will be overridden
+    by .git/annex/ssh.config.
+  * S3: Support the special case endpoint needed for the cn-north-1 region.
+  * Webapp: Don't list the Frankfurt S3 region, as this (and some other new
+    regions) need V4 authorization which the aws library does not yet use.
+  * reinject --known: Avoid second, unnecessary checksum of file.
+  * OSX: Remove RPATHs from git-annex binary, which are not needed,
+    slow down startup, and break the OSX Sierra linker.
+  * webapp: Explicitly avoid checking for auth in static subsite
+    requests. Yesod didn't used to do auth checks for that, but this may
+    have changed.
+  * Linux standalone: Avoid using hard links in the tarball so it can be
+    untarred on eg, afs which does not support them.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 11 Nov 2016 14:46:39 -0400
+
+git-annex (6.20161031) unstable; urgency=medium
+
+  * Assistant, repair: Fix ignoring of git fsck errors due to
+    duplicate file entries in tree objects.
+  * Linux standalone: Fix location of locale files in the bundle.
+  * Fix reversion in 6.20161012 that prevented adding files with a space
+    in their name.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 31 Oct 2016 18:55:59 -0400
+
+git-annex (6.20161027) unstable; urgency=medium
+
+  * lock, smudge: Fix edge cases where data loss could occur in v6 mode
+    when the keys database was not populated.
+  * upgrade: Handle upgrade to v6 when the repository already contains
+    v6 unlocked files whose content is already present.
+  * Improve style of offline html build of website.
+  * importfeed: Drop URL parameters from file extension.
+    Thanks, James MacMahon.
+  * Assistant, repair: Improved filtering out of git fsck lines about
+    duplicate file entries in tree objects.
+  * test: Deal with gpg-agent behavior change that broke the test suite.
+  * Improve ssh socket cleanup code to skip over the cruft that
+    NFS sometimes puts in a directory when a file is being deleted.
+  * If a transfer fails for some reason, but some data managed to be sent,
+    the transfer will be retried. (The assistant already did this.)
+  * Run ssh with ServerAliveInterval 60, so that stalled transfers will
+    be noticed within about 3 minutes.
+    (Any setting in your ~/.ssh/config or /etc/ssh/ssh_config 
+    overrides this.)
+
+ -- Joey Hess <id@joeyh.name>  Thu, 27 Oct 2016 15:21:58 -0400
+
+git-annex (6.20161012) unstable; urgency=medium
+
+  * Optimisations to time it takes git-annex to walk working tree and find
+    files to work on. Sped up by around 18%.
+  * Optimisations to git-annex branch query and setting, avoiding repeated
+    copies of the environment. Speeds up commands like 
+    "git-annex find --in remote" by over 50%.
+  * Optimised git-annex branch log file timestamp parsing.
+  * Add "total-size" field to --json-progress output.
+  * Make --json-progress output be shown even when the size of a object
+    is not known.
+  * Multiple external special remote processes for the same remote will be
+    started as needed when using -J. This should not beak any existing
+    external special remotes, because running multiple git-annex commands
+    at the same time could already start multiple processes for the same
+    external special remotes.
+  * Linux standalone: Include locale files in the bundle, and generate
+    locale definition files for the locales in use when starting runshell.
+    (Currently only done for utf-8 locales.)
+  * Avoid using a lot of memory when large objects are present in the git
+    repository and have to be checked to see if they are a pointed to an
+    annexed file. Cases where such memory use could occur included, but
+    were not limited to:
+    - git commit -a of a large unlocked file (in v5 mode)
+    - git-annex adjust when a large file was checked into git directly
+  * When auto-upgrading a v3 remote, avoid upgrading to version 6,
+    instead keep it at version 5.
+  * Support using v3 repositories without upgrading them to v5.
+  * sync: Fix bug in adjusted branch merging that could cause recently
+    added files to be lost when updating the adjusted branch.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 12 Oct 2016 09:37:41 -0400
+
+git-annex (6.20160923) unstable; urgency=medium
+
+  * Rate limit console progress display updates to 10 per second.
+    Was updating as frequently as changes were reported, up to hundreds of
+    times per second, which used unnecessary bandwidth when running git-annex
+    over ssh etc.
+  * Make --json and --quiet work when used with -J.
+    Previously, -J override the other options.
+  * addurl, get: Added --json-progress option, which adds progress
+    objects to the json output.
+  * Remove key:null from git-annex add --json output.
+  * copy, move, mirror: Support --json and --json-progress.
+  * Improve gpg secret key list parser to deal with changes in gpg 2.1.15.
+    Fixes key name display in webapp.
+  * info: Support being passed a treeish, and show info about the annexed
+    files in it similar to how a directory is handled.
+  * sync: Previously, when run in a branch with a slash in its name,
+    such as "foo/bar", the sync branch was "synced/bar". That conflicted
+    with the sync branch used for branch "bar", so has been changed to
+    "synced/foo/bar".
+  * Note that if you're using an old version of git-annex to sync with
+    a branch with a slash in its name, it won't see some changes synced by
+    this version, and this version won't see some changes synced by the older
+    version. This is not a problem if there's a central bare repository,
+    but may impact other configurations until git-annex is upgraded to this
+    version.
+  * adjust: Previously, when adjusting a branch with a slash in its name,
+    such as "foo/bar", the adjusted branch was "adjusted/bar(unlocked)".
+    That conflicted with the adjusted branch used for branch "bar",
+    so has been changed to "adjusted/foo/bar(unlocked)"
+  * Also, running sync in an adjusted branch did not correctly sync
+    changes back to the parent branch when it had a slash in its name.
+    This bug has been fixed.
+  * addurl, importfeed: Improve behavior when file being added is gitignored.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 23 Sep 2016 09:43:26 -0400
+
+git-annex (6.20160907) unstable; urgency=medium
+
+  * Windows: Handle shebang in external special remote program.
+  * Fix formatting of git-annex-smudge man page, and improve mdwn2man.
+    Thanks, Jim Paris.
+  * examimekey: Allow being run in a git repo that is not initialized by
+    git-annex yet.
+  * Android: Fix disabling use of cp --reflink=auto, curl, sha224, and sha384.
+  * Make --json and --quiet suppress automatic init messages, and any
+    other messages that might be output before a command starts.
+    Fixes a reversion introduced in version 5.20150727.
+  * Assistant, repair: Filter out git fsck lines about duplicate file
+    entries in tree objects.
+  * get -J, sync --content -J: Download different files from different
+    remotes when the remotes have the same costs.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 07 Sep 2016 11:12:11 -0400
+
+git-annex (6.20160808) unstable; urgency=medium
+
+  * metadata --json output format has changed, adding a inner json object
+    named "fields" which contains only the fields and their values.
+    This should be easier to parse than the old format, which mixed up
+    metadata fields with other keys in the json object.
+    Any consumers of the old format will need to be updated.
+  * Added metadata --batch option, which allows getting, setting, deleting,
+    and modifying metadata for multiple files/keys.
+  * Added --branch option to copy, drop, fsck, get, metadata, mirror, move,
+    and whereis commands. This option makes git-annex operate on files that
+    are included in a specified branch (or other treeish).
+  * git-annex.cabal: Temporarily limit to http-conduit <2.2.0
+    since aws 0.14.0 is not compatible with the newer version.
+  * git-annex.cabal: Temporarily limit to persistent <2.5
+    since esqueleto 2.4.3 is not compatible with the newer version.
+  * Removed dependency on json library; all JSON is now handled by aeson.
+  * When built with uuid-1.3.12, generate more random UUIDs than before.
+    (However, this did not impact git-annex much, so a hard depedency has
+    not been added on uuid-1.3.12.)
+  * info: When run on a file now includes an indication of whether
+    the content is present locally.
+  * get, move, copy, mirror: Added --failed switch which retries
+    failed copies/moves.
+  * Re-enable accumulating transfer failure log files for command-line
+    actions (disabled in 5.20150522), and remove the log files after
+    successful transfers.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 08 Aug 2016 11:42:17 -0400
+
+git-annex (6.20160619) unstable; urgency=medium
+
+  * get, drop: Add --batch and --json options.
+  * testremote: Fix crash when testing a freshly made external special remote.
+  * Remove unnecessary rpaths in the git-annex binary, but only when
+    it's built using make, not cabal. 
+    This speeds up git-annex startup time by around 50%.
+  * Speed up startup time by caching the refs that have been merged into
+    the git-annex branch.
+    This can speed up git-annex commands by as much as a second,
+    depending on the number of remotes.
+  * fsck: Fix a reversion in direct mode fsck of a file that is
+    present when the location log thinks it is not. Reversion introduced
+    in version 5.20151208.
+  * uninit: Fix crash due to trying to write to deleted keys db.
+    Reversion introduced by v6 mode support, affects v5 too.
+  * Fix a similar crash when the webapp is used to delete a repository.
+  * Support checking presence of content at a http url that redirects to
+    a ftp url.
+  * log: Added --all option.
+  * New url for git-remote-gcrypt, now maintained by spwhitton.
+  * webapp: Don't allow deleting a remote that has syncing disabled,
+    as such a deletion will never finish.
+    Thanks, Farhan Kathawala.
+  * webapp: Escape unusual characters in ssh hostnames when generating
+    mangled hostnames. This allows IPv6 addresses to be used on filesystems
+    not supporting : in filenames.
+  * Avoid any access to keys database in v5 mode repositories, which 
+    are not supposed to use that database.
+  * Remove the EKG build flag, since Gentoo for some reason decided to
+    enable this flag, depsite it not being intended for production use and
+    so disabled by default.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 19 Jul 2016 14:17:54 -0400
+
+git-annex (6.20160613) unstable; urgency=medium
+
+  * Improve SHA*E extension extraction code.
+  * Windows: Avoid terminating git-annex branch lines with \r\n when
+    union merging and performing transitions.
+  * Remove Makefile from cabal tarball; man page building is now handled by
+    a small haskell program.
+  * sync --content: Fix bug that caused transfers of files to be made 
+    to a git remote that does not have a UUID. This particularly impacted
+    clones from gcrypt repositories.
+  * Pass -S to git commit-tree when commit.gpgsign is set and when
+    making a non-automatic commit, in order to preserve current behavior
+    when used with git 2.9, which has stopped doing this itself.
+  * remotedaemon: Fixed support for notifications of changes to gcrypt
+    remotes, which was never tested and didn't quite work before.
+  * list: Do not include dead repositories.
+  * move --to: Better behavior when system is completely out of disk space;
+    drop content from disk before writing location log.
+  * Avoid a crash if getpwuid does not work, when querying the user's full
+    name.
+  * Automatically enable v6 mode when initializing in a clone from a repo
+    that has an adjusted branch checked out.
+  * v6: Fix initialization of a bare clone of a repo that has an adjusted
+    branch checked out.
+  * v6: Fix bad automatic merge conflict resolution between an annexed file
+    and a directory with the same name when in an adjusted branch.
+  * v6: Fix bad merge in an adjusted branch that resulted in an empty tree.
+  * v6: Fix bug in initialization of clone from a repo with an adjusted branch
+    that had not been synced back to master. 
+    (This bug caused broken tree objects to get built by a later git annex
+    sync.)
+  * v6: Make lock and unlock work on files whose content is not present.
+  * v6: Fix update of associated files db when unlocking a file.
+  * v6: Make git clean filter preserve the backend that was used for a file.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 13 Jun 2016 14:57:38 -0400
+
+git-annex (6.20160527) unstable; urgency=medium
+
+  * Split lines in the git-annex branch on \r as well as \n, to deal
+    with \r\n terminated lines written by some versions of git-annex on
+    Windows. This fixes strange displays in some cases.
+  * assistant: Fix bug that caused v6 pointer files to be annexed by the
+    assistant.
+  * assistant: Fix race in v6 mode that caused downloaded file content to
+    sometimes not replace pointer files.
+  * add: Adding a v6 pointer file used to annex it; now the pointer file is
+    added to git as-is. (git add of a pointer file already did the right
+    thing)
+  * enableremote: Can now be used to explicitly enable git-annex to use
+    git remotes. Using the command this way prevents other git-annex
+    commands from probing new git remotes to auto-enable them.
+  * enableremote: Remove annex-ignore configuration from a remote.
+  * Change git annex info remote encryption description to use wording
+    closer to what's used in initremote.
+  * Pass the various gnupg-options configs to gpg in several cases where
+    they were not before. Most notably, gnupg-decrypt-options is now
+    passed when decrypting an encrypted cipher.
+  * adjust: Add --fix adjustment, which is useful when the git directory
+    is in a nonstandard place.
+  * adjust: If the adjusted branch already exists, avoid overwriting it,
+    since it might contain changes that have not yet been propigated to the
+    original branch.
+  * Work around git weirdness in handling of relative path to GIT_INDEX_FILE
+    when in a subdirectory of the repository. This affected git annex view.
+  * Fix crash when entering/changing view in a subdirectory of a repo that
+    has a dotfile in its root.
+  * webapp: Avoid confusing display of dead remotes.
+  * Support building with ghc 8.0.1.
+  * Updated cabal file explicitly lists source files. The tarball
+    on hackage will include only the files needed for cabal install;
+    it is NOT the full git-annex source tree.
+  * debian/changelog, debian/NEWS, debian/copyright: Converted to symlinks
+    to CHANGELOG, NEWS, and COPYRIGHT, which used to symlink to these instead.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 27 May 2016 11:48:36 -0400
+
+git-annex (6.20160511) unstable; urgency=medium
+
+  * Fix bug that sometimes prevented git-annex smudge --clean from consuming
+    all its input, which resulted in git add bypassing git-annex.
+  * Fix build with directory-1.2.6.2.
+  * Improve behavior when a just added http remote is not available
+    during uuid probe. Do not mark it as annex-ignore, so it will be tried
+    again later.
+  * Android: Icon refresh.
+    Thanks, freewheelinfranks.
+  * Added DIRHASH-LOWER to external special remote protocol.
+  * git-annex.cabal: Add Setup-Depends.
+  * stack.yaml: Enable explicit-setup-deps.
+  * Windows: Fix several bugs in propigation of changes from the adjusted
+    branch back to the master branch.
+  * Windows: Fix an over-long temp directory name.
+  * map: Hide dead repositories that are not connected to the graph.
+  * map: Changed colors; red is used for untrusted repositories and grey
+    for dead.
+  * version: Display OS version and architecture too.
+  * Propigate GIT_DIR and GIT_WORK_TREE environment to external special
+    remotes.
+  * Added annex.gnupg-decrypt-options and
+    remote.<name>.annex-gnupg-decrypt-options, which are passed to gpg
+    when it's decrypting data.
+  * fsck: When a key is not previously known in the location log,
+    record something so that reinject --known will work.
+  * In the unusual configuration where annex.crippledfilesystem=true but
+    core.symlinks=true, store object contents in mixed case hash
+    directories so that symlinks will point to them.
+  * Added new encryption=sharedpubkey mode for special remotes.
+    This is useful for makking a special remote that anyone with a clone
+    of the repo and your public keys can upload files to, but only you can
+    decrypt the files stored in it.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 11 May 2016 12:41:42 -0400
+
+git-annex (6.20160419) unstable; urgency=medium
+
+  * Fix bug that prevented resuming of uploads to encrypted special remotes
+    that used chunking.
+  * That bug could also expose the names of keys to such remotes, so it is a
+    minor security issue.
+  * Fix duplicate progress meter display when downloading from a git remote
+    over http with -J.
+  * reinject: When src file's content cannot be verified, leave it alone,
+    instead of deleting it.
+  * reinject: Added new mode which can reinject known files into the annex.
+    For example: git-annex reinject --known /mnt/backup/*
+  * calckey: New plumbing command, calculates the key that would be used
+    to refer to a file.
+  * Fix bug that prevented annex.sshcaching=false configuration from taking
+    effect when on a crippled filesystem. Thanks, divergentdave.
+  * git 2.9.0 is going to prevent git merge from merging in unrelated
+    branches. Since the webapp's pairing etc features often combine
+    together repositories with unrelated histories, work around
+    this behavior change when the assistant merges, by passing
+    --allow-unrelated-histories. Note though that this is not done
+    for git annex sync's merges, so it will follow git's default or
+    configured behavior.
+  * When git-annex is used with a git version older than 2.2.0, disable
+    support for adjusted branches, since GIT_COMMON_DIR is needed to update
+    them and was first added in that version of git.
+  * Avoid setting LOCPATH in linux standalone builds that are built with
+    a ghc that has been fixed to not hang when it cannot find locale files.
+  * Isolate test suite from global git config settings.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 28 Apr 2016 09:31:14 -0400
+
+git-annex (6.20160418) unstable; urgency=medium
+
+  * smudge: Print a warning when annex.thin is set, as git's smudge
+    interface does not allow honoring that configuration.
+  * webapp: When $HOME is a git repository, and has been initialized for
+    use by git-annex, opening the webapp went ahead and ran the assistant
+    there, annexing all files. Since this is almost certianly not
+    desirable, especially when the user is just opening the webapp from
+    a dekstop menu which happens to run it in $HOME, the webapp will now not
+    treat such a $HOME git repository as a git-annex repository.
+  * webapp: Update url to add gitlab.com ssh key.
+  * Fix bug in v6 mode that prevented treating unlocked executable files
+    as annexed. If you have such files, run git annex init --version=6
+    to update the cache after upgrading to this version of git-annex.
+  * Preserve execute bits of unlocked files in v6 mode.
+  * fsck: Warn when core.sharedRepository is set and an annex object file's
+    write bit is not set and cannot be set due to the file being owned
+    by a different user.
+  * Fix hang when dropping content needs to lock the content on a
+    ssh remote, which occurred when the remote has git-annex version
+    5.20151019 or newer. (The bug was in the client side; the remote
+    git-annex-shell does not need to be upgraded.)
+
+ -- Joey Hess <id@joeyh.name>  Mon, 18 Apr 2016 18:33:52 -0400
+
+git-annex (6.20160412) unstable; urgency=medium
+
+  * adjust --unlock: Enters an adjusted branch in which all annexed files
+    are unlocked. The v6 equivilant of direct mode, but much cleaner!
+  * Upgrading a direct mode repository to v6 has changed to enter
+    an adjusted unlocked branch. This makes the direct mode to v6 upgrade
+    able to be performed in one clone of a repository without affecting
+    other clones, which can continue using v5 and direct mode.
+  * init --version=6: Automatically enter the adjusted unlocked branch
+    when filesystem doesn't support symlinks.
+  * ddar remote: fix ssh calls
+    Thanks, Robie Basak
+  * log: Display time with time zone.
+  * log --raw-date: Use to display seconds from unix epoch.
+  * v6: Close pointer file handles more quickly, to avoid problems on Windows.
+  * sync: Show output of git commit.
+  * annex.thin and annex.hardlink are now supported on Windows.
+  * unannex --fast now makes hard links on Windows.
+  * Fix bug in annex.largefiles mimetype= matching when git-annex
+    is run in a subdirectory of the repository.
+  * Fix build with ghc v7.11. Thanks, Gabor Greif.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 12 Apr 2016 14:53:22 -0400
+
+git-annex (6.20160318) unstable; urgency=medium
+
+  * metadata: Added -r to remove all current values of a field.
+  * Fix data loss that can occur when annex.pidlock is set in a repository.
+  * Fix bug preventing moving files to/from a repository with annex.pidlock set.
+  * Fix shared lock file FD leak.
+  * Fix metadata hook behavior when multiple files are added at once.
+    Thanks, Klaus Ethgen.
+  * Added dependencies on haskell mountpoints and disk-free-space
+    libraries, removing FFI code from git-annex.
+  * dropkey: Add --batch and --json.
+  * Fix OSX dmg to include libraries needed by bundled gpg,
+    lost in last release.
+  * Always try to thaw content, even when annex.crippledfilesystem is set.
+  * Correct git-annex info to include unlocked files in v6 repository.
+  * Sped up git-annex add in direct mode and v6 by using
+    git hash-object --stdin-paths.
+  * Sped up git-annex merge by using git hash-object --stdin-paths.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 18 Mar 2016 11:30:36 -0400
+
+git-annex (6.20160229) unstable; urgency=medium
+
+  * Update perlmagick build dependency. Closes: #789225
+  * Fix memory leak in last release, which affected commands like
+    git-annex status when a large non-annexed file is present in the work
+    tree.
+  * fsck: When the only copy of a file is in a dead repository, mention
+    the repository.
+  * info: Mention when run in a dead repository.
+  * Linux and OSX standalone builds put the bundled gpg last in PATH,
+    so any system gpg will be preferred over it.
+  * Avoid crashing when built with MagicMime support, but when the magic
+    database cannot be loaded.
+  * Include magic database in the linux and OSX standalone builds.
+  * Fix memory leak when hashing files, which triggered during fsck
+    when an external hash program was not used.
+    (This leak was introduced in version 6.20160114.)
+  * Support --metadata field<number, --metadata field>number etc
+    to match ranges of numeric values.
+  * Similarly, support preferred content expressions like
+    metadata=field<number and metadata=field>number
+  * The pre-commit-annex hook script that automatically extracts
+    metadata has been updated to also use exiftool.
+    Thanks, Klaus Ethgen.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 29 Feb 2016 12:41:49 -0400
+
+git-annex (6.20160217) unstable; urgency=medium
+
+  * Support getting files from read-only repositories.
+  * checkpresentkey: Allow to be run without an explicit remote.
+  * checkpresentkey: Added --batch.
+  * Work around problem with concurrent-output when in a non-unicode locale
+    by avoiding use of it in such a locale. Instead -J will behave as if
+    it was built without concurrent-output support in this situation.
+  * Fix storing of filenames of v6 unlocked files when the filename is not
+    representable in the current locale.
+  * fsck: Detect and fix missing associated file mappings in v6 repositories.
+  * fsck: Populate unlocked files in v6 repositories whose content is
+    present in annex/objects but didn't reach the work tree.
+  * When initializing a v6 repo on a crippled filesystem, don't force it
+    into direct mode.
+  * Windows: Fix v6 unlocked files to actually work.
+  * add, addurl, import, importfeed: When in a v6 repository on a crippled
+    filesystem, add files unlocked.
+  * annex.addunlocked: New configuration setting, makes files always be
+    added unlocked. (v6 only)
+  * Improve format of v6 unlocked pointer files to support keys containing
+    slashes.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 17 Feb 2016 14:48:51 -0400
+
+git-annex (6.20160211) unstable; urgency=medium
+
+  * annex.addsmallfiles: New option controlling what is done when
+    adding files not matching annex.largefiles.
+  * Fix reversion in lookupkey, contentlocation, and examinekey which
+    caused them to sometimes output side messages.
+  * webapp: Fix deletion of current repository directory.
+  * Added "nothing" to preferred content expression syntax.
+  * annex.largefiles can be configured in .gitattributes too;
+    this is particulary useful for v6 repositories, since the
+    .gitattributes configuration will apply in all clones of the
+    repository.
+  * Limit annex.largefiles parsing to the subset of preferred content
+    expressions that make sense in its context. So, not "standard"
+    or "lackingcopies", etc.
+  * annex.largefiles: Add support for mimetype=text/* etc, when git-annex
+    is linked with libmagic.
+  * matchexpression: Added --largefiles option to parse an annex.largefiles
+    expression.
+  * Brought back the dbus and xmpp build flags, so build from source can be
+    done without C libraries that may be hard to install.
+  * init: Fix bugs in submodule .git symlink fixup, that occurred when
+    initializing in a subdirectory of a submodule and a submodule of a
+    submodule.
+  * WebDAV: Set depth 1 in PROPFIND request, for better compatibility with
+    some servers. Thanks, wzhd.
+  * WebDAV: Remove a bogus trailing slash from the end of the url to the
+    temporary store location for a key. Thanks, wzhd.
+  * S3: Allow configuring with requeststyle=path to use path-style bucket
+    access instead of the default DNS-style access.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 11 Feb 2016 11:42:19 -0400
+
+git-annex (6.20160126) unstable; urgency=medium
+
+  * Fix nasty reversion in the last release that broke sync --content's
+    handling of many preferred content expressions.
+  * whereis --json: Urls are now listed inside the remote that claims them,
+    rather than all together at the end.
+  * info, add, whereis, find: Support --batch mode.
+  * Force output to be line-buffered, even when it's not connected to the
+    terminal. This is particuarly important for commands with --batch
+    output, which was not always being flushed at an appropriate time.
+  * add, import: Support --json output.
+  * addurl --json: Include field for added key (unless the file was
+    added directly to git due to annex.largefiles configuration.)
+    (Also done by add --json and import --json)
+  * registerurl: Check if a remote claims the url, same as addurl does.
+  * Bug fix: Git config settings passed to git-annex -c did not always take
+    effect.
+  * assistant: Use udisks2 dbus events to detect when disks are mounted,
+    instead of relying on gnome/kde stuff that is not stable.
+  * Fix build with QuickCheck 2.8.2
+  * matchexpression: New plumbing command to check if a preferred content
+    expression matches some data.
+  * Removed the webapp-secure build flag, rolling it into the webapp build
+    flag.
+  * Removed the quvi, tahoe, feed, and tfds build flags, adding
+    aeson feed and regex-tdfa to the core dependencies.
+  * Roll the dns build flag into the assistant build flag.
+  * Debian: Avoid building debug package, since gdb is not often useful
+    to debug haskell programs.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 26 Jan 2016 14:57:42 -0400
+
+git-annex (6.20160114) unstable; urgency=medium
+
+  "hexapodia as the key insight"
+
+  * Added v6 repository mode, but v5 is still the default for now.
+  * unlock, lock: In v6 mode, unlocking a file changes it from a symlink to a
+    pointer file, and this change can be committed to the git repository.
+    For details, see http://git-annex.branchable.com/tips/unlocked_files/
+  * The upgrade to version 6 is not done fully automatically yet, because
+    upgrading a direct mode repository to version 6 will prevent old
+    versions of git-annex from working in other clones of that repository.
+    For details, see http://git-annex.branchable.com/upgrades/
+  * init: --version parameter added to control which supported repository
+    version to use.
+  * init, upgrade: Configure .git/info/attributes to use git-annex
+    as a smudge filter. In v6 repository mode, this makes git add
+    add files to the annex in unlocked mode, unless overridden by
+    annex.largefiles configuration.
+  * assistant: In v6 mode, adds files in unlocked mode, so they can
+    continue to be modified.
+  * Added annex.thin setting, which makes unlocked files in v6 repositories
+    be hard linked to their content, instead of a copy. This saves disk
+    space but means any modification of an unlocked file will lose the local
+    (and possibly only) copy of the old version.
+  * Enable annex.thin by default on upgrade from direct mode to v6, since
+    direct mode made the same tradeoff.
+  * fix: Adjusts unlocked files as configured by annex.thin.
+  * persistent-sqlite is now a hard build dependency, since v6 repository
+    mode needs it.
+
+
+  * status: On crippled filesystems, was displaying M for all annexed files
+    that were present. Probably caused by a change to what git status
+    displays in this situation. Fixed by treating files git thinks are
+    modified the same as typechanged files.
+  * addurl: Added --batch and --with-files options.
+  * addurl: Support --json, particularly useful in --batch mode.
+  * addurl: Refuse to overwrite any existing, non-annexed file.
+  * Debian: Adjust build dependencies for webapp, DAV. Now available on
+    mips, mipsel, but temporarily removed armel since build is failing
+    there.
+  * info: Fix "backend usage" numbers, which were counting present keys
+    twice.
+  * info --json: Improve json for "backend usage", using a nested object
+    with fields for each backend instead of the previous weird nested lists.
+    This may break existing parsers of this json output, if there were any.
+  * whereis --json: Make url list be included in machine-parseable form.
+  * test: Added --keep-failures option.
+  * unused: Bug fix when a new file was added to the annex, and then
+    removed (but not git rmed). git still has the add staged in this case,
+    so the content should not be unused and was wrongly treated as such.
+  * migrate: Copy over metadata to new key.
+  * rekey: No longer copies over urls from the old to the new key.
+    It makes sense for migrate to do that, but not for this low-level
+    (and little used) plumbing command to.
+  * view: Fix crash in non-unicode capable locale when entering a view
+    of metadata containing a slash or backslash.
+  * When annex.http-headers is used to set the User-Agent header, avoid
+    sending User-Agent: git-annex
+  * Windows: Fix rsync cross-drive hack to work with msys2 rsync.
+    Thanks, Pieter Kitslaar.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 14 Jan 2016 10:14:19 -0400
+
+git-annex (5.20151218) unstable; urgency=medium
+
+  * Add S3 features to git-annex version output.
+  * webdav: When testing the WebDAV server, send a file with content.
+    The empty file it was sending tickled bugs in some php WebDAV server.
+  * fsck: Failed to honor annex.diskreserve when checking a remote.
+  * Debian: Build depend on concurrent-output.
+  * Fix insecure temporary permissions when git-annex repair is used in
+    in a corrupted git repository.
+  * Fix potential denial of service attack when creating temp dirs.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 18 Dec 2015 12:09:33 -0400
+
+git-annex (5.20151208) unstable; urgency=medium
+
+  * Build with -j1 again to get reproducible build.
+  * Display progress meter in -J mode when copying from a local git repo,
+    to a local git repo, and from a remote git repo.
+  * Display progress meter in -J mode when downloading from the web.
+  * map: Improve display of git remotes with non-ssh urls, including http
+    and gcrypt. 
+  * When core.sharedRepository is set, annex object files are not made mode
+    444, since that prevents a user other than the file owner from locking
+    them. Instead, a mode such as 664 is used in this case.
+  * tahoe: Include tahoe capabilities in whereis display.
+  * import: Changed to honor annex.largefiles settings.
+  * addurl, importfeed: Changed to honor annex.largefiles settings,
+    when the content of the url is downloaded. (Not when using --fast or
+    --relaxed.)
+  * webapp: Fix bugs that could result in a relative path such as "."
+    being written to ~/.config/git-annex/autostart, and ignore any such 
+    relative paths in the file.
+    This was a reversion caused by the relative path changes in 5.20150113.
+  * dropunused: Make more robust when trying to drop an object that has
+    already been dropped.
+  * Fix reversion in handling of long filenames, particularly when using
+    addurl/importfeed, which was introduced in the previous release.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 08 Dec 2015 11:14:03 -0400
+
+git-annex (5.20151116) unstable; urgency=medium
+
+  * Use concurrent-output library when configured with -fConcurrentOutput.
+    This allows nicely displayed messages when using the -J flag.
+  * Additional commands now support the -J flag: 
+    fsck, drop, add, addurl, import
+  * import: Avoid very ugly error messages when the directory files
+    are imported to is not a directort, but perhaps an annexed file.
+  * Concurrent progress bars are now displayed when using -J with a command
+    that moves file contents around.
+  * Fix race that could result in an annexed file's symlink not being
+    created, when eg, running concurrent git-annex adds.
+  * add: Fix error recovery rollback to not move the injested file content
+    out of the annex back to the file, because other files may point to
+    that same content. Instead, copy the injected file content out to
+    recover.
+  * quvi may output utf-8 encoded data when the conifigured locale doesn't
+    support that; avoid crashing on such invalid encoding.
+  * runshell: Avoid failing when $HOME/.ssh does not exist and cannot be
+    created.
+  * Make the git-annex-standalone.deb prevent runshell from installing
+    wrappers into $HOME/.ssh
+  * Make git-annex-standalone.deb include the git-annex html documentation,
+    desktop file, and base completion file, same as the regular git-annex.deb.
+  * fsck: When fscking a dead repo, avoid incorrect "fixing location log"
+    message, and display a warning about it being dead, since it's unusual
+    to have access to a dead repo.
+  * assistant: Pass ssh-options through 3 more git pull/push calls
+    that were missed before.
+  * Added annex.pidlock and annex.pidlocktimeout configuration to support
+    filesystems where POSIX fcntl locks cannot be used.
+  * init: Automatically enable annex.pidlock when necessary.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 16 Nov 2015 14:17:40 -0400
+
+git-annex (5.20151102.1) unstable; urgency=medium
+
+  * Avoid installing desktop file and program file if cabal install
+    git-annex is run as root, since that is not a systemwide install,
+    but to /root, and so generating a systemwide desktop file is not right.
+  * When cabal install is run with the desktop file location not writable,
+    display a warning, but continue successfully.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 03 Nov 2015 12:08:38 -0400
+
+git-annex (5.20151102) unstable; urgency=medium
+
+  * Use statvfs on OSX.
+  * Symlink timestamp preservation code uses functions
+    from unix-2.7.0 when available, which should be more portable.
+  * enableremote: List uuids and descriptions of remotes that can be
+    enabled, and accept either the uuid or the description in leu if the
+    name.
+  * Catch up with current git behavior when both repo and repo.git exist;
+    it seems it now prefers repo in this case, although historically it may
+    have preferred repo.git.
+  * Fix failure to build with aws-0.13.0.
+  * When built with aws-0.13.0, the S3 special remote can be used to create
+    google nearline buckets, by setting storageclass=NEARLINE.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 02 Nov 2015 12:41:20 -0400
+
+git-annex (5.20151019) unstable; urgency=medium
+
+  * Fix a longstanding, but unlikely to occur bug, where dropping
+    a file from a remote could race with other drops of the same file,
+    and result in all copies of its content being lost.
+  * git-annex-shell: Added lockcontent command, to prevent dropping of
+    a key's content. This is necessary due to the above bugfix.
+  * In some cases, the above bugfix changes what git-annex allows you to
+    drop:
+    - When a file is present in several special remotes,
+      but not in any accessible git repositories, dropping it from one of
+      the special remotes will now fail. Instead, the file has to be
+      moved from one of the special remotes to the git repository, and can
+      then safely be dropped from the git repository.
+    - If a git remote has too old a version of git-annex-shell installed,
+      git-annex won't trust it to hold onto a copy of a file when dropping
+      that file from the local git repository.
+  * Changed drop ordering when using git annex sync --content or the
+    assistant, to drop from remotes first and from the local repo last.
+    This works better with the behavior changes to drop in many cases.
+  * Do verification of checksums of annex objects downloaded from remotes.
+  * When annex objects are received into git repositories from other git
+    repos, their checksums are verified then too.
+  * To get the old, faster, behavior of not verifying checksums, set
+    annex.verify=false, or remote.<name>.annex-verify=false.
+  * setkey, rekey: These commands also now verify that the provided file
+    matches the expected checksum of the key, unless annex.verify=false.
+  * reinject: Already verified content; this can now be disabled by
+    setting annex.verify=false.
+  * sync, merge, assistant: When git merge failed for a reason other
+    than a conflicted merge, such as a crippled filesystem not allowing
+    particular characters in filenames, git-annex would make a merge commit
+    that could omit such files or otherwise be bad. Fixed by aborting the
+    whole merge process when git merge fails for any reason other than a
+    merge conflict.
+  * Allow building with S3 disabled again.
+  * Ported disk free space checking code to work on Solaris.
+  * Windows webapp: Fix support for entering password when setting
+    up a ssh remote.
+  * copy --auto was checking the wrong repo's preferred content.
+    (--from was checking what --to should, and vice-versa.)
+    Fixed this bug, which was introduced in version 5.20150727.
+  * Avoid unnecessary write to the location log when a file is unlocked
+    and then added back with unchanged content.
+  * S3: Fix support for using https.
+  * Avoid displaying network transport warning when a ssh remote
+    does not yet have an annex.uuid set.
+  * Debian: Add torrent library to build-depends as it's packaged now,
+    and stop recommending bittornado | bittorrent.
+  * Debian: Remove build dependency on transformers library, as it is now
+    included in ghc.
+  * Debian: Remove menu file, since a desktop file is provided and
+    lintian says there can be only one.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 19 Oct 2015 13:59:01 -0400
+
+git-annex (5.20150930) unstable; urgency=medium
+
+  * Added new linux standalone "ancient" build to support kernels
+    like 2.6.32.
+  * info: Don't allow use in a non-git-annex repository, since it
+    uses the git-annex branch and would create it if it were missing.
+  * assistant: When updating ~/.ssh/config, preserve any symlinks.
+  * webapp: Remove the "disable remote" feature from the UI.
+  * S3: When built with aws-0.13.0, supports using more storage classes.
+    In particular, storageclass=STANDARD_IA to use Amazon's
+    new Infrequently Accessed storage, and storageclass=NEARLINE
+    to use Google's NearLine storage.
+  * Improve ~/.ssh/config modification code to not add trailing spaces
+    to lines it cannot parse.
+  * Fix a crash at direct mode merge time when .git/index doesn't exist
+    yet. Triggered by eg, git-annex sync --no-commit in a fresh clone of
+    a repository.
+  * status: Show added but not yet committed files.
+  * Added stack.yaml to support easy builds from source with stack.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 30 Sep 2015 14:31:52 -0400
+
+git-annex (5.20150916) unstable; urgency=medium
+
+  * Fix Windows build to work with ghc 7.10.
+  * init: Fix reversion in detection of repo made with git clone --shared
+  * info: Support querying info of individual files in direct mode.
+  * unused: Fix reversion in 5.20150727 that broke parsing of the
+    --unused-refspec option. Thanks, Øyvind A. Holm.
+  * Make full option parsing be done when not in a git repo, so --help
+    can be displayed for commands that require a git repo, etc.
+  * fsck: Work around bug in persistent that broke display of
+    problematically encoded filenames on stderr when using --incremental.
+  * When gpg.program is configured, it's used to get the command to run
+    for gpg. Useful on systems that have only a gpg2 command or want to
+    use it instead of the gpg command.
+  * Windows: Switched to using git for Windows, rather than msysgit.
+    Using msysgit with git-annex is no longer supported.
+  * Windows: Even when the user neglects to tell the git installer to
+    add git to PATH, git-annex will still work from within the git bash
+    shell, and the webapp can be used too.
+  * sync: Add --no-commit, --no-pull, --no-push options to turn off parts of
+    the sync process, as well as supporting --commit, --pull, --push, and
+    --no-content options to specify the (current) default behavior.
+  * annex.hardlink extended to also try to use hard links when copying from
+    the repository to a remote.
+  * Improve bash completion, so it completes names of remotes and backends
+    in appropriate places.
+  * Special remotes configured with autoenable=true will be automatically
+    enabled when git-annex init is run.
+  * Fix bug in combination of preferred and required content settings.
+    When one was set to the empty string and the other set to some expression,
+    this bug caused all files to be wanted, instead of only files matching
+    the expression.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 16 Sep 2015 10:31:24 -0400
+
+git-annex (5.20150824) unstable; urgency=medium
+
+  * Sped up downloads of files from ssh remotes, reducing the
+    non-data-transfer overhead 6x.
+  * sync: Support --jobs
+  * sync --content: Avoid unnecessary second pull from remotes when 
+    no file transfers are made.
+  * External special remotes can now be built that can be used in readonly
+    mode, where git-annex downloads content from the remote using regular
+    http.
+  * Added WHEREIS to external special remote protocol.
+  * importfeed --relaxed: Avoid hitting the urls of items in the feed.
+  * Fix reversion in init when ran as root, introduced in version 5.20150731.
+  * Reorder declaration to fix build with yesod-core > 1.4.13.
+    Thanks, Michael Alan Dorman.
+  * Fix building without quvi and without database.
+    Thanks, Ben Boeckel.
+  * Avoid building the assistant on the hurd, since an inotify equivalent
+    is not yet implemented in git-annex for the hurd.
+  * --debug log messages are now timestamped with fractional seconds.
+  * --debug is passed along to git-annex-shell when git-annex is in debug mode.
+  * Makefile: Pass LDFLAGS, CFLAGS, and CPPFLAGS through ghc and on to
+    ld, cc, and cpp.
+  * As a result of the Makefile changes, the Debian package is built
+    with various hardening options. Although their benefit to a largely
+    haskell program is unknown.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 24 Aug 2015 14:11:05 -0700
+
+git-annex (5.20150812) unstable; urgency=medium
+
+  * Added support for SHA3 hashed keys (in 8 varieties), when git-annex is
+    built using the cryptonite library.
+  * metadata: Fix reversion introduced in 5.20150727 that caused recursive
+    display of metadata to not work.
+  * Windows: Fix bug that caused git-annex sync to fail due to missing
+    environment variable.
+  * Fix setting/setting/viewing metadata that contains unicode or other
+    special characters, when in a non-unicode locale.
+  * Simplify setup process for a ssh remote. Now it suffices to run git
+    remote add, followed by git-annex sync. Now the remote is automatically
+    initialized for use by git-annex, where before the git-annex branch had
+    to manually be pushed before using git-annex sync. Note that this
+    involved changes to git-annex-shell, so if the remote is using an old
+    version, the manual push is still needed.
+  * git-annex-shell: Don't let configlist auto-init repository when in
+    readonly mode.
+  * Perform a clean shutdown when --time-limit is reached.
+    This includes running queued git commands, and cleanup actions normally
+    run when a command is finished.
+  * fsck: Commit incremental fsck database when --time-limit is reached.
+    Previously, some of the last files fscked did not make it into the
+    database when using --time-limit.
+  * fsck: Commit incremental fsck database after every 1000 files
+    fscked, or every 5 minutes, whichever comes first. Previously,
+    commits were made every 1000 files fscked.
+  * Linux standalone: Work around problem that prevented it from working
+    properly if unpacked into a directory that contains ":" or ";" in its
+    name.
+  * proxy: Fix proxy git commit of non-annexed files in direct mode. 
+  * proxy: If a non-proxied git command, such as git revert
+    would normally fail because of unstaged files in the work tree,
+    make the proxied command fail the same way.
+  * proxy: Fix removal of files deleted by the proxied command.
+  * proxy: Fix behavior when run in subdirectory of git repo.
+  * Improve Setup.hs file so that cabal copy --destdir works.
+    Thanks, Magnus Therning.
+  * Tighten dependency on optparse-applicative to 0.11.0.
+  * Added back debian/cabal-wrapper, since it still seems needed after all.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 12 Aug 2015 11:14:58 -0400
+
+git-annex (5.20150731) unstable; urgency=medium
+
+  * webapp: Support enabling known gitlab.com remotes.
+  * Fix rsync special remote to work when -Jn is used for concurrent
+    uploads.
+  * The last release accidentally removed a number of options from the
+    copy command. (-J, file matching options, etc). These have been added
+    back.
+  * init: Detect when the filesystem is crippled such that it ignores
+    attempts to remove the write bit from a file, and enable direct mode.
+    Seen with eg, NTFS fuse on linux.
+  * Fix man page installation by cabal install; all the new man pages are
+    now installed.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 31 Jul 2015 11:34:36 -0400
+
+git-annex (5.20150727) unstable; urgency=medium
+
+  * Fix bug that prevented uploads to remotes using new-style chunking
+    from resuming after the last successfully uploaded chunk.
+  * Switched option parsing to use optparse-applicative. This was a very large
+    and invasive change, and may have caused some minor behavior changes to
+    edge cases of option parsing. (For example, the metadata command no
+    longer accepts the combination of --get and --set, which never actually
+    worked.)
+  * Bash completion file is now included in the git-annex source tree, 
+    and installed into Debian package (and any other packages built using make
+    install). This bash completion is generated by the option parser, so it
+    covers all commands, all options, and will never go out of date!
+  * As well as tab completing "git-annex" commands, "git annex" will also tab
+    complete. However, git's bash completion script needs a patch,
+    which I've submitted, for this to work prefectly.
+  * version --raw now works when run outside a git repository.
+  * assistant --startdelay now works when run outside a git repository.
+  * dead now accepts multiple --key options.
+  * addurl now accepts --prefix and --suffix options to adjust the
+    filenames used.
+  * sync --content: Fix bug that caused files to be uploaded to eg,
+    more archive remotes than wanted copies, only to later be dropped
+    to satisfy the preferred content settings.
+  * importfeed: Improve detection of known items whose url has changed,
+    and avoid adding redundant files. Where before this only looked at
+    permalinks in rss feeds, it now also looks at guids.
+  * importfeed: Look at not only permalinks, but now also guids
+    to identify previously downloaded files.
+  * Webapp: Now features easy setup of git-annex repositories on gitlab.com.
+  * Adjust debian build deps: The webapp can now build on arm64, s390x
+    and hurd-i386. WebDAV support is also available on those architectures.
+  * Debian package now maintained by Richard Hartmann.
+  * Support building without persistent database on for systems that
+    lack TH. This removes support for incremental fsck.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 27 Jul 2015 12:24:49 -0400
+
+git-annex (5.20150710) unstable; urgency=medium
+
+  * add: Stage symlinks the same as git add would, even if they are not a
+    link to annexed content.
+  * sync: When annex.autocommit=false, avoid making any commit of local
+    changes, while still merging with remote to the extent possible.
+  * unused: --used-refspec can now be configured to look at refs in the
+    reflog. This provides a way to not consider old versions of files to be
+    unused after they have reached a specified age, when the old refs in
+    the reflog expire.
+  * log: Fix reversion introduced in version 5.20150528 that broke this command.
+  * assistant --autostart: First stop any daemons that are already running,
+    which might be left over from a previous login session and so unable to
+    use the ssh agent of a new login session.
+  * assistant: Fix local pairing to not include newline in ssh pubkey,
+    which is rejected on the other end for security reasons.
+  * assistant: Fix ANNEX_SHELL_DIR written to ~/.ssh/authorized_keys 
+    in local pairing to be the absolute path to the repository, not "."
+    This was a reversion caused by the relative path changes in 5.20150113.
+  * Brought back the setkey plumbing command that was removed in 2011, since
+    we found a use case for it. Note that the command's syntax was changed
+    for consistency.
+  * bugfix: Pass --full-tree when using git ls-files to get a list of files
+    on the git-annex branch, so it works when run in a subdirectory.
+    This bug affected git-annex unused, and potentially also transitions
+    running code and other things.
+  * Support git's undocumented core.sharedRepository=2 value, which
+    is equivalent to "world", and is set when a repo was created using
+    git init --shared=world.
+  * When building on linux, pass --as-needed to linker to avoid linking
+    with unused shared libraries including libyaml.
+  * import: Fix failure of cross-device import on Windows.
+  * merge: Avoid creating the synced/master branch.
+  * Removed support for optparse-applicative versions older than 0.10.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 10 Jul 2015 16:36:42 -0400
+
+git-annex (5.20150617) unstable; urgency=medium
+
+  * Now supports git annex sync --all --content to sync all versions of all
+    files with all repos that want them.
+  * Added new "anything" preferred content expression, which matches all
+    versions of all files.
+  * Standard preferred content for client, backup, incremental backup,
+    and unwanted groups have been adjusted to work better when used
+    with git annex sync --all --content.
+  * fromkey, registerurl: Improve handling of urls that happen to also
+    be parsable as strange keys.
+  * sync, remotedaemon: Pass configured ssh-options even when
+    annex.sshcaching is disabled.
+  * assistant: Consume systemd-networkd dbus events to learn about
+    changes to network connections, as was already done with
+    network-manager and wicd.
+    Thanks to Sebastian Reuße for the patches.
+  * get --incomplete: New option to resume any interrupted downloads.
+  * dead --key: Can be used to mark a key as dead.
+  * fsck: Ignore keys that are known to be dead when running in
+    --all/--unused/--key mode or a in a bare repo. Closes: #753888
+    Otherwise, still reports files with lost contents, even if the content
+    is dead.
+  * S3: Special remotes can be configured with public=yes to allow
+    the public to access the bucket's content.
+  * S3: Publically accessible buckets can be used without creds.
+  * import --clean-duplicates: Fix bug that didn't count local or trusted
+    repo's copy of a file as one of the necessary copies to allow removing
+    it from the import location.
+  * tahoe: Use ~/.tahoe-git-annex/ rather than ~/.tahoe/git-annex/
+    when setting up a tahoe special remote to avoid old versions of
+    tahoe create-client choking.
+  * Fix bug that prevented enumerating locally present objects in repos
+    tuned with annex.tune.objecthash1=true.
+    Fixes: unused, object count in info, unannex.
+  * Improve url parsing to handle some urls containing illegal []
+    characters in their paths.
+  * info: Added json output for "backend usage", "numcopies stats",
+    "repositories containing these files", and "transfers in progress".
+  * Fix incremental backup standard preferred content expression to match
+    its documentation, which says it does not want files that have reached
+    a backup repository.
+  * Increased the default annex.bloomaccuracy from 1000 to 10000000.
+    This makes git annex unused use up to 16 mb more memory than it did
+    before, but the massive increase in accuracy makes this worthwhile
+    for all but the smallest systems.
+  * Build documentation with deterministic=1 for reproducible builds.
+    (A new ikiwiki feature.) Closes: #785736
+  * Re-remove dependency on obsolete hamlet package. Closes: #786659
+  * debian/cabal-wrapper: Removed this hack which should not be needed anymore.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 17 Jun 2015 13:50:35 -0400
+
+git-annex (5.20150528) unstable; urgency=medium
+
+  * fromkey, registerurl: Allow urls to be specified instead of keys,
+    and generate URL keys.
+  * Linux standalone, OSX app: Improve runshell script to always quote
+    shell vars, so that it will work when eg, untarred into a directory
+    path with spaces in its name.
+  * Revert removal dependency on obsolete hamlet package, since the
+    autobuilders are not ready for this change yet and it prevented them
+    from building the webapp. Reopens: #786659
+  * fsck: When checksumming a file fails due to a hardware fault,
+    the file is now moved to the bad directory, and the fsck proceeds.
+    Before, the fsck immediately failed.
+  * Linux standalone: The webapp was not built in the previous release,
+    this release fixes that oversight.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 28 May 2015 10:48:03 -0400
+
+git-annex (5.20150522) unstable; urgency=medium
+
+  * import: Refuse to import files that are within the work tree, as that
+    does not make sense and could cause data loss.
+  * drop: Now supports --all, --unused, and --key.
+  * drop: Now defaults to --all when run in a bare repository.
+    (Previously, did nothing when run in a bare repository.)
+  * get, move, copy, mirror: Concurrent transfers are now supported!
+    For example: git-annex get -J10
+    However, progress bars are not yet displayed for concurrent transfers,
+    pending an updated version of the ascii-progress library.
+  * --quiet now makes progress output by rsync, wget, etc be quiet too.
+  * Take space that will be used by other running downloads into account when
+    checking annex.diskreserve.
+  * Avoid accumulating transfer failure log files unless the assistant is
+    being used.
+  * Fix an unlikely race that could result in two transfers of the same key
+    running at once.
+  * Stale transfer lock and info files will be cleaned up automatically
+    when get/unused/info commands are run.
+  * unused: Add --used-refspec option and annex.used-refspec, which can
+    specify a set of refs to consider used, rather than the default of
+    considering all refs used.
+  * webapp: Fix zombie xdg-open process left when opening file browser.
+    Closes: #785498
+  * Safer posix fctnl locking implementation, using lock pools and STM.
+  * Build documentation with TZ=UTC for reproducible builds. See #785736.
+  * OSX: Corrected the location of trustedkeys.gpg, so the built-in
+    upgrade code will find it. Fixes OSX upgrade going forward, but
+    older versions won't upgrade themselves due to this problem.
+  * Remove dependency on obsolete hamlet package. Closes: #786659
+
+ -- Joey Hess <id@joeyh.name>  Fri, 22 May 2015 14:20:18 -0400
+
+git-annex (5.20150508.1) unstable; urgency=medium
+
+  * Now builds cleanly using ghc 7.10 (as well as ghc back to 7.6).
+  * Imrovements to the git-annex-standalone.deb build process.
+    (Thanks, Yaroslav Halchenko)
+
+ -- Joey Hess <id@joeyh.name>  Mon, 11 May 2015 12:08:58 -0400
+
+git-annex (5.20150508) unstable; urgency=medium
+
+  * Improve behavior when a git-annex command is told to operate
+    on a file that doesn't exist. It will now continue to other
+    files specified after that on the command line, and only error out at
+    the end.
+  * S3: Enable debug logging when annex.debug or --debug is set.
+  * S3: git annex info will show additional information about a S3 remote
+    (endpoint, port, storage class)
+  * S3: Let git annex enableremote be used, without trying to recreate
+    a bucket that should already exist.
+  * S3: Fix incompatibility with bucket names used by hS3; the aws library
+    cannot handle upper-case bucket names. git-annex now converts them to
+    lower case automatically.
+  * import: Check for gitignored files before moving them into the tree.
+    (Needs git 1.8.4 or newer.)
+  * import: Don't stop entire import when one file fails due to being
+    gitignored or conflicting with something in the work tree.
+  * import: Before removing a duplicate file in --deduplicate or
+    --clean-duplicates mode, verify that enough copies of its content still
+    exist.
+  * Improve integration with KDE's file manager to work with dolphin
+    version 14.12.3 while still being compatable with 4.14.2.
+    Thanks, silvio.
+  * assistant: Added --autostop to complement --autostart.
+  * Work around wget bug #784348 which could cause it to clobber git-annex
+    symlinks when downloading from ftp.
+  * Support checking ftp urls for file presence.
+  * Fix bogus failure of fsck --fast.
+  * fsck: Ignore error recording the fsck in the activity log,
+    which can happen when running fsck in a read-only repository.
+    Closes: #698559
+    (fsck can still need to write to the repository if it find problems,
+    but a successful fsck can be done read-only)
+  * Improve quvi 0.4 output parsing to handle cases wher there is no known
+    filename extension. This is currently the case when using quvi with
+    youtube. In this case, the extension ".m" will be used.
+  * Dropped support for older versions of yesod, warp, and dbus than the ones
+    in Debian Jessie.
+  * Switch from the obsolete dataenc library for base64 encoding to sandi.
+    (Thanks, Magnus Therning)
+  * Debian's ghc now supports TH on arm! Adjust build dependencies
+    to build the webapp on arm, and enable DAV support on arm. \o/
+  * Adjust some other arch specific build dependencies that are now
+    available on more architectures in Devian unstable.
+  * Windows: Remove cygwin ssh, the newer version of which has stopped
+    honoring the setting of HOME. Instead, copy msysgit's ssh into PATH.
+    Note that setting up a remote ssh server using password authentication
+    is known to be broken in this release on Windows.
+  * Windows: Roll back to an older version of rsync from cygwin.
+    The newer version has some dependency on a newer ssh from cygwin.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 08 May 2015 13:42:30 -0400
+
+git-annex (5.20150420) unstable; urgency=medium
+
+  * Fix activity log parsing, which caused the log to not retain
+    activity from other uuids.
+  * Union merge could fall over if there was a file in the repository
+    with the same name as a git ref. Now fixed.
+  * info dir: Added information about repositories that
+    contain files in the specified directory.
+  * info: Added --bytes option.
+  * bittorrent: Fix handling of magnet links.
+  * When a key's size is unknown, still check the annex.diskreserve,
+    and avoid getting content if the disk is too full.
+  * Fix fsck --from a git remote in a local directory, and from
+    a directory special remote.
+    This was a reversion caused by the relative path changes in 5.20150113.
+  * fsck --from remote: When bad content is found in the remote,
+    and the local repo does not have a copy of the content, preserve
+    the bad content in .git/annex/bad/ to avoid further data loss.
+  * fsck --from remote: Avoid downloading a key if it would go over
+    the annex.diskreserve limit.
+  * required: New command, like wanted, but for required content.
+  * Removed dependency on haskell SHA library,
+    instead using cryptohash >= 0.11.0.
+  * Make repo init more robust.
+  * New debian/rules build-standalone target, which generates a
+    git-annex-standalone.deb that should work on many old Debian etc
+    systems. Thanks, Yaroslav Halchenko.
+  * Windows: Renamed start menu file to avoid loop in some versions
+    of Windows where the menu file is treated as a git-annex program.
+  * Windows: Fixed support of remotes on other drives.
+    (A reversion introduced in version 5.20150113.)
+  * Windows: Bundled versions of rsync, wget, ssh, and gpg from
+    cygwin all updated. Thanks, Yury V. Zaytsev.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 20 Apr 2015 14:44:04 -0400
+
+git-annex (5.20150409) unstable; urgency=medium
+
+  * This fixes a bug in the assistant introduced by the literal pathspec
+    changes in version 5.20150406.
+  * --quiet now suppresses progress displays from eg, rsync.
+    (Second time's the charm..)
+  * fromkey, registerurl: When reading from stdin, allow the
+    filename and url, respectively, to contain whitespace.
+  * add: If annex.largefiles is set and does not match a file that's being
+    added, the file will be checked into git rather than being added to the
+    annex. Previously, git annex add skipped over such files; this new
+    behavior is more useful in direct mode.
+  * proxy: Made it work when run in a new repository before initial
+    commit.
+  * info: Display repository mode: bare when in a bare (non-direct mode)
+    repo.
+  * importfeed: Fix feed download when curl is used.
+  * importfeed: Error out when passed a non-url.
+  * webapp: When adding another local repository, and combining it
+    with the current repository, the new repository's remote path
+    was set to "." rather than the path to the current repository.
+    This was a reversion caused by the relative path changes in 5.20150113.
+  * contentlocationn: New plumbing command.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 09 Apr 2015 15:06:38 -0400
+
+git-annex (5.20150406.1) unstable; urgency=medium
+
+  * Fixes a bug in the last release that caused rsync and possibly
+    other commands to hang at the end of a file transfer.
+    (--quiet is back to not blocking progress displays until
+    that code can be fixed properly.)
+
+ -- Joey Hess <id@joeyh.name>  Mon, 06 Apr 2015 17:13:13 -0400
+
+git-annex (5.20150406) unstable; urgency=medium
+
+  * Prevent git-ls-files from double-expanding wildcards when an
+    unexpanded wildcard is passed to a git-annex command like add or find.
+  * Fix make build target. Thanks, Justin Geibel.
+  * Fix GETURLS in external special remote protocol to strip
+    downloader prefix from logged url info before checking for the
+    specified prefix.
+  * importfeed: Avoid downloading a redundant item from a feed whose
+    permalink has been seen before, even when the url has changed.
+  * importfeed: Always store itemid in metadata; before this was only
+    done when annex.genmetadata was set.
+  * Relax debian package dependencies to git >= 1:1.8.1 rather
+    than needing >= 1:2.0.
+  * test: Fix --list-tests
+  * addurl --file: When used with a special remote that claims
+    urls and checks their contents, don't override the user's provided
+    filename with filenames that the special remote suggests. Also,
+    don't allow adding the url if the special remote says it contains
+    multiple files.
+  * import: --deduplicate and --cleanduplicates now output the keys
+    corresponding to duplicated files they process.
+  * expire: New command, for expiring inactive repositories.
+  * fsck: Record fsck activity for use by expire command.
+  * Fix truncation of parameters that could occur when using xargs git-annex.
+  * Significantly sped up processing of large numbers of directories
+    passed to a single git-annex command.
+  * version: Add --raw
+  * init: Improve fifo test to detect NFS systems that support fifos
+    but not well enough for sshcaching.
+  * --quiet now suppresses progress displays from eg, rsync.
+    (The option already suppressed git-annex's own built-in progress
+    displays.)
+
+ -- Joey Hess <id@joeyh.name>  Mon, 06 Apr 2015 12:48:48 -0400
+
+git-annex (5.20150327) unstable; urgency=medium
+
+  * readpresentkey: New plumbing command for checking location log.
+  * checkpresentkey: New plumbing command to check if a key can be verified
+    to be present on a remote.
+  * Added a post-update-annex hook, which is run after the git-annex branch
+    is updated. Needed for git update-server-info.
+  * migrate: --force will force migration of keys already using the
+    destination backend. Useful in rare cases.
+  * Man pages for individual commands now available, and can be
+    opened using "git annex help <command>"
+  * --auto is no longer a global option; only get, drop, and copy
+    accept it. (Not a behavior change unless you were passing it to a
+    command that ignored it.)
+  * Improve error message when --in @date is used and there is no
+    reflog for the git-annex branch.
+  * assistant: Committing a whole lot of files at once could overflow
+    command-line length limits and cause the commit to fail. This
+    only happened when using the assistant in an indirect mode repository.
+  * Work around curl bug when asked to download an empty url to a file.
+  * Fix bug introduced in the last release that broke git-annex sync
+    when git-annex was installed from the standalone tarball.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 27 Mar 2015 13:10:59 -0400
+
+git-annex (5.20150317) unstable; urgency=medium
+
+  * fsck: Incremental fsck uses sqlite to store its records, instead
+    of abusing the sticky bit. Existing sticky bits are ignored;
+    incremental fscks started by old versions won't be resumed by
+    this version.
+  * fsck: Multiple incremental fscks of different repos (including remotes)
+    can now be running at the same time in the same repo without it
+    getting confused about which files have been checked for which remotes.
+  * unannex: Refuse to unannex when repo is too new to have a HEAD,
+    since in this case there must be staged changes in the index
+    (if there is anything to unannex), and the unannex code path
+    needs to run with a clean index.
+  * Linux standalone: Set LOCPATH=/dev/null to work around
+    https://ghc.haskell.org/trac/ghc/ticket/7695
+    This prevents localization from working, but git-annex
+    is not localized anyway.
+  * sync: As well as the synced/git-annex push, attempt a
+    git-annex:git-annex push, as long as the remote branch
+    is an ancestor of the local branch, to better support bare git repos.
+    (This used to be done, but it forgot to do it since version 4.20130909.)
+  * When re-execing git-annex, use current program location, rather than
+    ~/.config/git-annex/program, when possible.
+  * Submodules are now supported by git-annex!
+  * metadata: Fix encoding problem that led to mojibake when storing
+    metadata strings that contained both unicode characters and a space
+    (or '!') character.
+  * Also potentially fixes encoding problem when embedding credentials
+    that contain unicode characters.
+  * sync: Fix committing when in a direct mode repo that has no HEAD ref.
+    (For example, a newly checked out git submodule.)
+  * Added SETURIPRESENT and SETURIMISSING to external special remote protocol,
+    useful for things like ipfs that don't use regular urls.
+  * addurl: Added --raw option, which bypasses special handling of quvi,
+    bittorrent etc urls.
+  * git-annex-shell: Improve error message when the specified repository
+    doesn't exist or git config fails for some reason.
+  * fromkey --force: Skip test that the key has its content in the annex.
+  * fromkey: Add stdin mode.
+  * registerurl: New plumbing command for mass-adding urls to keys.
+  * remotedaemon: Fixed support for notifications of changes to gcrypt
+    remotes, which was never tested and didn't quite work before.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 17 Mar 2015 13:02:36 -0400
+
+git-annex (5.20150219) unstable; urgency=medium
+
+  * glacier: Detect when the glacier command in PATH is the wrong one,
+    from boto, rather than from glacier-cli, and refuse to use it,
+    since the boto program fails to fail when passed
+    parameters it does not understand.
+  * groupwanted: New command to set the groupwanted preferred content
+    expression.
+  * import: Support file matching options such as --exclude, --include, 
+    --smallerthan, --largerthan
+  * The file matching options are now only accepted by commands that
+    can actually use them, instead of by all commands.
+  * import: Avoid checksumming file twice when run in the default
+    or --duplicate mode.
+  * Windows: Fix bug in dropping an annexed file, which
+    caused a symlink to be staged that contained backslashes.
+  * webapp: Fix reversion in opening webapp when starting it manually
+    inside a repository.
+  * assistant: Improve sanity check for control characters when pairing.
+  * Improve race recovery code when committing to git-annex branch.
+  * addurl: Avoid crash if quvi is not installed, when git-annex was
+    built with process-1.2
+  * bittorrent: Fix mojibake introduced in parsing arai2c progress output.
+  * fsck --from: If a download from a remote fails, propagate the failure.
+  * metadata: When setting metadata, do not recurse into directories by
+    default, since that can be surprising behavior and difficult to recover
+    from. The old behavior is available by using --force.
+  * sync, assistant: Include repository name in head branch commit message.
+  * The ssh-options git config is now used by gcrypt, rsync, and ddar
+    special remotes that use ssh as a transport.
+  * sync, assistant: Use the ssh-options git config when doing git pull
+    and push.
+  * remotedaemon: Use the ssh-options git config.
+  * Linux standalone: Improved process names of linker shimmed programs.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 19 Feb 2015 14:16:03 -0400
+
+git-annex (5.20150205) unstable; urgency=medium
+
+  * info: Can now display info about a given uuid.
+  * Added to remote/uuid info: Count of the number of keys present
+    on the remote, and their size. This is rather expensive to calculate,
+    so comes last and --fast will disable it.
+  * info remote: Include the date of the last sync with the remote.
+  * sync: Added --message/-m option like git commit.
+  * remotedaemon: Fix problem that could prevent ssh connections being
+    made after two LOSTNET messages were received in a row (perhaps due to
+    two different network interfaces being brought down).
+  * Fix build failure when wget is not installed.
+  * Fix wording of message displayed when unable to get a file that
+    is available in untrusted repositories.
+  * addurl: When a Content-Disposition header suggests a filename to use,
+    addurl will consider using it, if it's reasonable and doesn't conflict
+    with an existing file. (--file overrides this)
+  * Fix default repository description created by git annex init,
+    which got broken by the relative path changes in the last release.
+  * init: Repository tuning parameters can now be passed when initializing a
+    repository for the first time. For details, see
+    http://git-annex.branchable.com/tuning/
+  * merge: Refuse to merge changes from a git-annex branch of a repo
+    that has been tuned in incompatible ways.
+  * Support annex.tune.objecthash1, annex.tune.objecthashlower, and
+    annex.tune.branchhash1.
+  * Remove support for building without cryptohash.
+  * Added MD5 and MD5E backends.
+  * assistant: Fix local pairing when ssh pubkey comment contains spaces.
+  * Avoid using fileSize which maxes out at just 2 gb on Windows.
+    Instead, use hFileSize, which doesn't have a bounded size.
+    Fixes support for files > 2 gb on Windows.
+  * Windows: Fix running of the pre-commit-annex hook.
+  * Windows: Fix S3 special remote; need to call withSocketsDo. Thanks, Trent.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 05 Feb 2015 14:08:33 -0400
+
+git-annex (5.20150113) unstable; urgency=medium
+
+  * unlock: Don't allow unlocking files that have never been committed to git
+    before, to avoid an intractable problem that prevents the pre-commit
+    hook from telling if such a file is intended to be an annexed file or not.
+  * Avoid re-checksumming when migrating from hash to hashE backend.
+    Closes: #774494
+  * Fix build with process 1.2.1.0.
+  * Android: Provide a version built with -fPIE -pie to support Android 5.0.
+  * sync: Fix an edge case where syncing in a bare repository would try to
+    merge and so fail.
+  * Check git version at runtime, rather than assuming it will be the same
+    as the git version used at build time when running git-checkattr and
+    git-branch remove.
+  * Switch to using relative paths to the git repository.
+    - This allows the git repository to be moved while git-annex is running in
+      it, with fewer problems.
+    - On Windows, this avoids some of the problems with the absurdly small
+      MAX_PATH of 260 bytes. In particular, git-annex repositories should
+      work in deeper/longer directory structures than before.
+  * Generate shorter keys for WORM and URL, avoiding keys that are longer
+    than used for SHA256, so as to not break on systems like Windows that
+    have very small maximum path length limits.
+  * Bugfix: A file named HEAD in the work tree could confuse some git commands
+    run by git-annex.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 13 Jan 2015 12:10:08 -0400
+
+git-annex (5.20141231) unstable; urgency=medium
+
+  * vicfg: Avoid crashing on badly encoded config data.
+  * Work around statfs() overflow on some XFS systems.
+  * sync: Now supports remote groups, the same way git remote update does.
+  * setpresentkey: A new plumbing-level command.
+  * Run shutdown cleanup actions even if there were failures processing
+    the command. Among other fixes, this means that addurl will stage
+    added files even if adding one of the urls fails.
+  * bittorrent: Fix locking problem when using addurl file://
+  * Windows: Fix local rsync filepath munging (fixes 26 test suite failures).
+  * Windows: Got the rsync special remote working.
+  * Windows: Fix handling of views of filenames containing '%'
+  * OSX: Switched away from deprecated statfs64 interface.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 31 Dec 2014 15:15:46 -0400
+
+git-annex (5.20141219) unstable; urgency=medium
+
+  * Webapp: When adding a new box.com remote, use the new style chunking.
+    Thanks, Jon Ander Peñalba.
+  * External special remote protocol now includes commands for setting
+    and getting the urls associated with a key.
+  * Urls can now be claimed by remotes. This will allow creating,
+    for example, a external special remote that handles magnet: and
+    *.torrent urls.
+  * Use wget -q --show-progress for less verbose wget output,
+    when built with wget 1.16.
+  * Added bittorrent special remote.
+  * addurl behavior change: When downloading an url ending in .torrent,
+    it will download files from bittorrent, instead of the old behavior
+    of adding the torrent file to the repository.
+  * Added Recommends on aria2.
+  * When possible, build with the haskell torrent library for parsing
+    torrent files. As a fallback, can instead use btshowmetainfo from
+    bittornado | bittorrent.
+  * Fix build with -f-S3.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 19 Dec 2014 16:53:26 -0400
+
+git-annex (5.20141203) unstable; urgency=medium
+
+  * proxy: New command for direct mode repositories, allows bypassing
+    the direct mode guard in a safe way to do all sorts of things
+    including git revert, git mv, git checkout ...
+  * undo: New command to undo the most recent change to a file
+    or to the contents of a directory.
+  * Add undo action to nautilus and konqueror integration.
+  * diffdriver: New git-annex command, to make git external diff drivers
+    work with annexed files.
+  * pre-commit: Block partial commit of unlocked annexed file, since
+    that left a typechange staged in index due to some infelicity of git's
+    handling of partial commits.
+  * Work around behavior change in lsof 4.88's -F output format.
+  * S3: Switched to using the haskell aws library.
+  * S3: No longer buffers entire files in memory when uploading without
+    chunking.
+  * S3: When built with a new enough version of the haskell aws library,
+    supports doing multipart uploads, in order to store extremely large
+    files in S3 when not using chunking.
+  * Don't show "(gpg)" when decrypting the remote encryption cipher,
+    since this could be taken to read that's the only time git-annex
+    runs gpg, which is not the case.
+  * Debian package is now maintained by Gergely Nagy.
+  * Windows: Remove Alt+A keyboard shortcut, which turns out to have scope
+    outside the menus.
+  * Windows: Install ssh and other bundled programs to Git/cmd,
+    instead of Git/bin, since the latter is not in the default msysgit PATH.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 03 Dec 2014 15:16:52 -0400
+
+git-annex (5.20141125) unstable; urgency=medium
+
+  * Remove fixup code for bad bare repositories created by
+    versions 5.20131118 through 5.20131127. That fixup code would
+    accidentally fire when --git-dir was incorrectly
+    pointed at the working tree of a git-annex repository,
+    possibly resulting in data loss. Closes: #768093
+  * Windows: Fix crash when user.name is not set in git config.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 05 Nov 2014 11:41:51 -0400
+
+git-annex (5.20141024) unstable; urgency=medium
+
+  * vicfg: Deleting configurations now resets to the default, where
+    before it has no effect.
+  * Remove hurd stuff from cabal file, since hackage currently rejects
+    it, and the test suite fails on hurd.
+  * initremote: Don't allow creating a special remote that has the same
+    name as an existing git remote.
+  * Windows: Use haskell setenv library to clean up several ugly workarounds
+    for inability to manipulate the environment on windows. This includes
+    making git-annex not re-exec itself on start on windows, and making the
+    test suite on Windows run tests without forking.
+  * glacier: Fix pipe setup when calling glacier-cli to retrieve an object.
+  * info: When run on a single annexed file, displays some info about the 
+    file, including its key and size.
+  * info: When passed the name or uuid of a remote, displays info about that
+    remote. Remotes that support encryption, chunking, or embedded
+    creds will include that in their info.
+  * enableremote: When the remote has creds, update the local creds cache
+    file. Before, the old version of the creds could be left there, and
+    would continue to be used.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 24 Oct 2014 13:03:29 -0400
+
+git-annex (5.20141013) unstable; urgency=medium
+
+  * Adjust cabal file to support building w/o assistant on the hurd.
+  * Support building with yesod 1.4.
+  * S3: Fix embedcreds=yes handling for the Internet Archive.
+  * map: Handle .git prefixed remote repos. Closes: #614759
+  * repair: Prevent auto gc from happening when fetching from a remote.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 13 Oct 2014 10:13:06 -0400
+
+git-annex (5.20140927) unstable; urgency=medium
+
+  * Really depend (not just build-depend) on new enough git for --no-gpg-sign
+    to work. Closes: #763057
+  * Add temporary workaround for bug #763078 which broke building on armel
+    and armhf.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 27 Sep 2014 14:25:09 -0400
+
+git-annex (5.20140926) unstable; urgency=high
+
+  * Depend on new enough git for --no-gpg-sign to work. Closes: #762446
+  * Work around failure to build on mips by using cabal, not Setup,
+    to build in debian/rules.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 26 Sep 2014 15:09:02 -0400
+
+git-annex (5.20140919) unstable; urgency=high
+
+  * Security fix for S3 and glacier when using embedcreds=yes with
+    encryption=pubkey or encryption=hybrid. CVE-2014-6274
+    The creds embedded in the git repo were *not* encrypted.
+    git-annex enableremote will warn when used on a remote that has
+    this problem. For details, see:
+    https://git-annex.branchable.com/upgrades/insecure_embedded_creds/
+  * assistant: Detect when repository has been deleted or moved, and
+    automatically shut down the assistant. Closes: #761261
+  * Windows: Avoid crashing trying to list gpg secret keys, for gcrypt
+    which is not yet supported on Windows.
+  * WebDav: Fix enableremote crash when the remote already exists.
+    (Bug introduced in version 5.20140817.)
+  * add: In direct mode, adding an annex symlink will check it into git,
+    as was already done in indirect mode.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 19 Sep 2014 12:53:42 -0400
+
+git-annex (5.20140915) unstable; urgency=medium
+
+  * New annex.hardlink setting. Closes: #758593
+  * init: Automatically detect when a repository was cloned with --shared,
+    and set annex.hardlink=true, as well as marking the repository as
+    untrusted.
+  * Fix parsing of ipv6 address in git remote address when it was not
+    formatted as an url.
+  * The annex-rsync-transport configuration is now also used when checking
+    if a key is present on a rsync remote, and when dropping a key from
+    the remote.
+  * Promote file not found warning message to an error.
+  * Fix transfer lock file FD leak that could occur when two separate
+    git-annex processes were both working to perform the same set of
+    transfers.
+  * sync: Ensure that pending changes to git-annex branch are committed
+    before push when in direct mode. (Fixing a very minor reversion.)
+  * WORM backend: Switched to include the relative path to the file inside
+    the repository, rather than just the file's base name. Note that if you're
+    relying on such things to keep files separate with WORM, you should really
+    be using a better backend.
+  * Rather than crashing when there's a problem with the requested bloomfilter
+    capacity/accuracy, fall back to a reasonable default bloom filter size.
+  * Fix build with optparse-applicative 0.10. Closes: #761484
+  * webapp: Fixed visual glitch in xmpp pairing that was reported live by a
+    user who tracked me down in front of a coffee cart in Portland. 
+    (New bug reporting method of choice?)
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 15 Sep 2014 10:45:00 -0400
+
+git-annex (5.20140831) unstable; urgency=medium
+
+  * Make --help work when not in a git repository. Closes: #758592
+  * Ensure that all lock fds are close-on-exec, fixing various problems with
+    them being inherited by child processes such as git commands.
+  * When accessing a local remote, shut down git-cat-file processes
+    afterwards, to ensure that remotes on removable media can be unmounted.
+    Closes: #758630
+  * Fix handing of autocorrection when running outside a git repository.
+  * Fix stub git-annex test support when built without tasty.
+  * Do not preserve permissions and acls when copying files from
+    one local git repository to another. Timestamps are still preserved
+    as long as cp --preserve=timestamps is supported. Closes: #729757
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 31 Aug 2014 12:30:08 -0700
+
+git-annex (5.20140817) unstable; urgency=medium
+
+  * New chunk= option to chunk files stored in special remotes.
+    Supported by: directory, S3, webdav, gcrypt, rsync, and all external
+    and hook special remotes.
+  * Partially transferred files are automatically resumed when using
+    chunked remotes!
+  * The old chunksize= option is deprecated. Do not use for new remotes.
+  * Legacy code for directory remotes using the old chunksize= option
+    will keep them working, but more slowly than before.
+  * webapp: Automatically install Konqueror integration scripts
+    to get and drop files.
+  * repair: Removing bad objects could leave fsck finding no more
+    unreachable objects, but some branches no longer accessible.
+    Fix this, including support for fixing up repositories that
+    were incompletely repaired before.
+  * Fix cost calculation for non-encrypted remotes.
+  * Display exception message when a transfer fails due to an exception.
+  * WebDAV: Sped up by avoiding making multiple http connections
+    when storing a file.
+  * WebDAV: Avoid buffering whole file in memory when uploading and
+    downloading.
+  * WebDAV: Dropped support for DAV before 1.0.
+  * testremote: New command to test uploads/downloads to a remote.
+  * Dropping an object from a bup special remote now deletes the git branch
+    for the object, although of course the object's content cannot be deleted
+    due to the nature of bup.
+  * unlock: Better error handling; continue past files that are not available
+    or cannot be unlocked due to disk space, and try all specified files.
+  * Windows: Now uses actual inode equivilants in new direct mode
+    repositories, for safer detection of eg, renaming of files with the same
+    size and mtime.
+  * direct: Fix ugly warning messages.
+  * WORM backend: When adding a file in a subdirectory, avoid including the
+    subdirectory in the key name.
+  * S3, Glacier, WebDAV: Fix bug that prevented accessing the creds
+    when the repository was configured with encryption=shared embedcreds=yes.
+  * direct: Avoid leaving file content in misctemp if interrupted.
+  * git-annex-shell sendkey: Don't fail if a remote asks for a key to be sent
+    that already has a transfer lock file indicating it's being sent to that
+    remote. The remote may have moved between networks, or reconnected.
+  * Switched from the old haskell HTTP library to http-conduit.
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 17 Aug 2014 10:30:58 -0400
+
+git-annex (5.20140717) unstable; urgency=high
+
+  * Fix minor FD leak in journal code. Closes: #754608
+  * direct: Fix handling of case where a work tree subdirectory cannot
+    be written to due to permissions.
+  * migrate: Avoid re-checksumming when migrating from hashE to hash backend.
+  * uninit: Avoid failing final removal in some direct mode repositories
+    due to file modes.
+  * S3: Deal with AWS ACL configurations that do not allow creating or
+    checking the location of a bucket, but only reading and writing content to
+    it.
+  * resolvemerge: New plumbing command that runs the automatic merge conflict
+    resolver.
+  * Deal with change in git 2.0 that made indirect mode merge conflict
+    resolution leave behind old files.
+  * sync: Fix git sync with local git remotes even when they don't have an
+    annex.uuid set. (The assistant already did so.)
+  * Set gcrypt-publish-participants when setting up a gcrypt repository,
+    to avoid unnecessary passphrase prompts.
+    This is a security/usability tradeoff. To avoid exposing the gpg key
+    ids who can decrypt the repository, users can unset
+    gcrypt-publish-participants.
+  * Install nautilus hooks even when ~/.local/share/nautilus/ does not yet
+    exist, since it is not automatically created for Gnome 3 users.
+  * Windows: Move .vbs files out of git\bin, to avoid that being in the
+    PATH, which caused some weird breakage. (Thanks, divB)
+  * Windows: Fix locking issue that prevented the webapp starting
+    (since 5.20140707).
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 17 Jul 2014 11:27:25 -0400
+
+git-annex (5.20140709) unstable; urgency=medium
+
+  * Fix race in direct mode merge code that could cause all files in the
+    repository to be removed. It should be able to recover repositories
+    experiencing this bug without data loss. See:
+    http://git-annex.branchable.com/bugs/bad_merge_commit_deleting_all_files/
+  * Fix git version that supported --no-gpg-sign.
+  * Fix bug in automatic merge conflict resolution, when one side is an
+    annexed symlink, and the other side is a non-annexed symlink.
+  * Really fix bug that caused the assistant to make many unnecessary
+    empty merge commits.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 09 Jul 2014 15:28:03 -0400
+
+git-annex (5.20140707) unstable; urgency=medium
+
+  * assistant: Fix bug, introduced in last release, that caused the assistant
+    to make many unnecessary empty merge commits.
+  * assistant: Fix one-way assistant->assistant sync in direct mode.
+  * Fix bug in annex.queuesize calculation that caused much more
+    queue flushing than necessary.
+  * importfeed: When annex.genmetadata is set, metadata from the feed
+    is added to files that are imported from it.
+  * Support users who have set commit.gpgsign, by disabling gpg signatures
+    for git-annex branch commits and commits made by the assistant.
+  * Fix memory leak when committing millions of changes to the git-annex
+    branch, eg after git-annex add has run on 2 million files in one go.
+  * Support building with bloomfilter 2.0.0.
+  * Run standalone install process when the assistant is started
+    (was only being run when the webapp was opened).
+  * Android: patch git to avoid fchmod, which fails on /sdcard.
+  * Windows: Got rid of that pesky DOS box when starting the webapp.
+  * Windows: Added Startup menu item so assistant starts automatically
+    on login.
+  * Windows: Fix opening file browser from webapp when repo is in a
+    directory with spaces.
+  * Windows: Assistant now logs to daemon.log.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 07 Jul 2014 12:24:13 -0400
+
+git-annex (5.20140613) unstable; urgency=medium
+
+  * Ignore setsid failures.
+  * Avoid leaving behind .tmp files when failing in some cases, including
+    importing files to a disk that is full.
+  * Avoid bad commits after interrupted direct mode sync (or merge).
+  * Fix build with wai 0.3.0.
+  * Deal with FAT's low resolution timestamps, which in combination with
+    Linux's caching of higher res timestamps while a FAT is mounted, caused
+    direct mode repositories on FAT to seem to have modified files after
+    they were unmounted and remounted.
+  * Windows: Fix opening webapp when repository is in a directory with
+    spaces in the path.
+  * Detect when Windows has lost its mind in a timezone change, and
+    automatically apply a delta to the timestamps it returns, to get back to
+    sane values.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 13 Jun 2014 09:58:07 -0400
+
+git-annex (5.20140606) unstable; urgency=medium
+
+  * webapp: When adding a new local repository, fix bug that caused its
+    group and preferred content to be set in the current repository,
+    even when not combining.
+  * webapp: Avoid stomping on existing description, group and
+    preferred content settings when enabling or combining with
+    an already existing remote.
+  * assistant: Make sanity checker tmp dir cleanup code more robust.
+  * unused: Avoid checking view branches for unused files.
+  * webapp: Include ssh port in mangled hostname.
+  * Windows: Fix bug introduced in last release that caused files
+    in the git-annex branch to have lines teminated with \r.
+  * Windows: Fix retrieving of files from local bare git repositories.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 06 Jun 2014 12:54:06 -0400
+
+git-annex (5.20140529) unstable; urgency=medium
+
+  * Fix encoding of data written to git-annex branch. Avoid truncating
+    unicode characters to 8 bits. Allow any encoding to be used, as with
+    filenames (but utf8 is the sane choice). Affects metadata and repository
+    descriptions, and preferred content expressions.
+  * assistant: When there are multiple remotes giving different ways
+    to access the same repository, honor remote cost settings and use
+    the cheapest available.
+  * webapp: More robust startup when annex directory is not a git repo.
+  * initremote/enableremote: Basic support for using with regular git remotes;
+    initremote stores the location of an already existing git remote,
+    and enableremote setups up a remote using its stored location.
+  * webapp: Support for enabling known git repositories on ssh servers.
+    The repository must have been added using initremote.
+  * webapp: When setting up a ssh remote, record it using initremote,
+    so that it can be easily enabled elsewhere.
+  * webapp: When setting up a ssh remote, if the user inputs ~/foo,
+    normalize that to foo, since it's in the home directory by default.
+  * Use exceptions in place of deprecated MonadCatchIO-transformers
+    Thanks, Ben Gamari.
+  * android: Run busybox install with -s, since some versions of Android
+    prohibit making hard links.
+  * Android webapp: Fix EvilSplicer bugs that mangled the css files,
+    preventing icons from displaying, and also slightly broke the js files.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 29 May 2014 14:41:56 -0400
+
+git-annex (5.20140517) unstable; urgency=medium
+
+  * webapp: Switched to bootstrap 3.
+    Thanks, Sören Brunk.
+  * Standalone builds now check gpg signatures before upgrading.
+  * Simplified repository description line format. The remote name,
+    if any, is always in square brackets after the description.
+  * assistant: Clean up stale tmp files on startup.
+  * webapp: Better ssh password prompting.
+  * Depend on git-remote-gcrypt 0.20130908-6. Older versions
+    fail when the assistant is run with no controlling tty.
+  * Added ddar special remote.
+    Thanks, Robie Basak.
+  * webapp: Fixed drag and drop to reorder the list of remotes.
+  * group: When no groups are specified to set, lists the current groups
+    of a repository.
+  * Add remote.$name.annex-shell configuration.
+    Thanks, Fraser Tweedale 
+  * Support symlinking git-annex and git-annex-shell
+    from the Linux standalone bundle into PATH.
+    Thanks, jlebar.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 17 May 2014 13:30:39 -0400
+
+git-annex (5.20140421) unstable; urgency=medium
+
+  * assistant: Now detects immediately when other repositories push
+    changes to a ssh remote, and pulls.
+    ** XMPP is no longer needed in this configuration! **
+    This requires the remote server have git-annex-shell with
+    notifychanges support (>= 5.20140405)
+  * webapp: Show a network signal icon next to ssh and xmpp remotes that
+    it's currently connected with.
+  * webapp: Rework xmpp nudge to prompt for either xmpp or a ssh remote 
+    to be set up.
+  * sync, assistant, remotedaemon: Use ssh connection caching for git pushes
+    and pulls.
+  * remotedaemon: When network connection is lost, close all cached ssh
+    connections.
+  * Improve handling of monthly/yearly scheduling.
+  * Avoid depending on shakespeare except for when building the webapp.
+  * uninit: Avoid making unnecessary copies of files.
+  * info: Allow use in a repository where annex.uuid is not set.
+  * reinit: New command that can initialize a new repository using
+    the configuration of a previously known repository.
+    Useful if a repository got deleted and you want
+    to clone it back the way it was.
+  * drop --from: When local repository is untrusted, its copy of a file does
+    not count.
+  * Bring back rsync -p, but only when git-annex is running on a non-crippled
+    file system. This is a better approach to fix #700282 while not
+    unncessarily losing file permissions on non-crippled systems.
+  * webapp: Start even if the current directory is listed in
+    ~/.config/git-annex/autostart but no longer has a git repository in it.
+  * findref: New command, like find but shows files in a specified git ref.
+  * webapp: Fix UI for removing XMPP connection.
+  * When init detects that git is not configured to commit, and sets
+    user.email to work around the problem, also make it set user.name.
+  * webapp: Support using git-annex on a remote server, which was installed
+    from the standalone tarball or OSX app, and so does not have
+    git-annex in PATH (and may also not have git or rsync in PATH).
+  * standalone tarball, OSX app: Install a ~/.ssh/git-annex-wrapper, which
+    can be used to run git-annex, git, rsync, etc.
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 20 Apr 2014 19:43:14 -0400
+
+git-annex (5.20140412) unstable; urgency=high
+
+  * Last release didn't quite fix the high cpu issue in all cases, this should.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 11 Apr 2014 17:14:38 -0400
+
+git-annex (5.20140411) unstable; urgency=high
+
+  * importfeed: Filename template can now contain an itempubdate variable.
+    Needs feed 0.3.9.2.
+  * Fix rsync progress parsing in locales that use comma in number display.
+    Closes: #744148
+  * assistant: Fix high CPU usage triggered when a monthly fsck is scheduled,
+    and the last time the job ran was a day of the month > 12. This caused a
+    runaway loop. Thanks to Anarcat for his assistance, and to Maximiliano
+    Curia for identifying the cause of this bug.
+  * Remove wget from OSX dmg, due to issues with cert paths that broke
+    git-annex automatic upgrading. Instead, curl is used, unless the
+    OSX system has wget installed, which will then be used.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 11 Apr 2014 14:59:49 -0400
+
+git-annex (5.20140405) unstable; urgency=medium
+
+  * git-annex-shell: Added notifychanges command.
+  * Improve display of dbus notifications. Thanks, Johan Kiviniemi.
+  * Fix nautilus script installation to not crash when the nautilus script dir
+    does not exist. Instead, only install scripts when the directory already
+    exists.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 05 Apr 2014 16:54:33 -0400
+
+git-annex (5.20140402) unstable; urgency=medium
+
+  * unannex, uninit: Avoid committing after every file is unannexed,
+    for massive speedup.
+  * --notify-finish switch will cause desktop notifications after each 
+    file upload/download/drop completes
+    (using the dbus Desktop Notifications Specification)
+  * --notify-start switch will show desktop notifications when each
+    file upload/download starts.
+  * webapp: Automatically install Nautilus integration scripts
+    to get and drop files.
+  * tahoe: Pass -d parameter before subcommand; putting it after
+    the subcommand no longer works with tahoe-lafs version 1.10.
+    (Thanks, Alberto Berti)
+  * forget --drop-dead: Avoid removing the dead remote from the trust.log,
+    so that if git remotes for it still exist anywhere, git annex info
+    will still know it's dead and not show it.
+  * git-annex-shell: Make configlist automatically initialize
+    a remote git repository, as long as a git-annex branch has
+    been pushed to it, to simplify setup of remote git repositories,
+    including via gitolite.
+  * add --include-dotfiles: New option, perhaps useful for backups.
+  * Version 5.20140227 broke creation of glacier repositories,
+    not including the datacenter and vault in their configuration.
+    This bug is fixed, but glacier repositories set up with the broken
+    version of git-annex need to have the datacenter and vault set
+    in order to be usable. This can be done using git annex enableremote
+    to add the missing settings. For details, see
+    http://git-annex.branchable.com/bugs/problems_with_glacier/
+  * Added required content configuration.
+  * assistant: Improve ssh authorized keys line generated in local pairing
+    or for a remote ssh server to set environment variables in an 
+    alternative way that works with the non-POSIX fish shell, as well
+    as POSIX shells.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 02 Apr 2014 16:42:53 -0400
+
+git-annex (5.20140320) unstable; urgency=medium
+
+  * Fix zombie leak and general inneficiency when copying files to a
+    local git repo.
+  * Fix ssh connection caching stop method to work with openssh 6.5p1,
+    which broke the old method.
+  * webapp: Added a "Sync now" item to each repository's menu.
+  * webapp: Use securemem for constant time auth token comparisons.
+  * copy --fast --to remote: Avoid printing anything for files that
+    are already believed to be present on the remote.
+  * Commands that allow specifying which repository to act on using
+    the repository's description will now fail when multiple repositories
+    match, rather than picking a repository at random.
+    (So will --in=)
+  * Better workaround for problem umasks when eg, setting up ssh keys.
+  * "standard" can now be used as a first-class keyword in preferred content
+    expressions. For example "standard or (include=otherdir/*)"
+  * groupwanted can be used in preferred content expressions.
+  * vicfg: Allows editing preferred content expressions for groups.
+  * Improve behavior when unable to parse a preferred content expression
+    (thanks, ion).
+  * metadata: Add --get
+  * metadata: Support --key option (and some other ones like --all)
+  * For each metadata field, there's now an automatically maintained
+    "$field-lastchanged" that gives the date of the last change to that
+    field. Also the "lastchanged" field for the date of the last change
+    to any of a file's metadata.
+  * unused: In direct mode, files that are deleted from the work tree
+    and so have no content present are no longer incorrectly detected as
+    unused.
+  * Avoid encoding errors when using the unused log file.
+  * map: Fix crash when one of the remotes of a repo is a local directory
+    that does not exist, or is not a git repo.
+  * repair: Improve memory usage when git fsck finds a great many broken
+    objects.
+  * Windows: Fix some filename encoding bugs.
+  * rsync special remote: Fix slashes when used on Windows.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 20 Mar 2014 13:21:12 -0400
+
+git-annex (5.20140306) unstable; urgency=high
+
+  * sync: Fix bug in direct mode that caused a file that was not
+    checked into git to be deleted when there was a conflicting
+    merge with a remote.
+  * webapp: Now supports HTTPS.
+  * webapp: No longer supports a port specified after --listen, since
+    it was buggy, and that use case is better supported by setting up HTTPS.
+  * annex.listen can be configured, instead of using --listen
+  * annex.startupscan can be set to false to disable the assistant's startup
+    scan.
+  * Probe for quvi version at run time.
+  * webapp: Filter out from Switch Repository list any
+    repositories listed in autostart file that don't have a
+    git directory anymore. (Or are bare)
+  * webapp: Refuse to start in a bare git repository.
+  * assistant --autostart: Refuse to start in a bare git repository.
+  * webapp: Don't list the public repository group when editing a
+    git repository; it only makes sense for special remotes.
+  * view, vfilter: Add support for filtering tags and values out of a view,
+    using !tag and field!=value.
+  * vadd: Allow listing multiple desired values for a field.
+  * view: Refuse to enter a view when no branch is currently checked out.
+  * metadata: To only set a field when it's not already got a value, use
+    -s field?=value
+  * Run .git/hooks/pre-commit-annex whenever a commit is made.
+  * sync: Automatically resolve merge conflict between and annexed file
+    and a regular git file.
+  * glacier: Pass --region to glacier checkpresent.
+  * webdav: When built with a new enough haskell DAV (0.6), disable
+    the http response timeout, which was only 5 seconds.
+  * webapp: Include no-pty in ssh authorized_keys lines.
+  * assistant: Smarter log file rotation, which takes free disk space
+    into account.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 06 Mar 2014 12:28:04 -0400
+
+git-annex (5.20140227) unstable; urgency=medium
+
+  * metadata: Field names limited to alphanumerics and a few whitelisted
+    punctuation characters to avoid issues with views, etc.
+  * metadata: Field names are now case insensitive.
+  * When constructing views, metadata is available about the location of the
+    file in the view's reference branch. Allows incorporating parts of the
+    directory hierarchy in a view.
+    For example `git annex view tag=* podcasts/=*` makes a view in the form
+    tag/showname.
+  * --metadata field=value can now use globs to match, and matches
+    case insensitively, the same as git annex view field=value does.
+  * annex.genmetadata can be set to make git-annex automatically set
+    metadata (year and month) when adding files.
+  * Make annex.web-options be used in several places that call curl.
+  * Fix handling of rsync remote urls containing a username,
+    including rsync.net.
+  * Preserve metadata when staging a new version of an annexed file.
+  * metadata: Support --json
+  * webapp: Fix creation of box.com and Amazon S3 and Glacier
+    repositories, broken in 5.20140221.
+  * webdav: When built with DAV 0.6.0, use the new DAV monad to avoid
+    locking files, which is not needed by git-annex's use of webdav, and
+    does not work on Box.com.
+  * webdav: Fix path separator bug when used on Windows.
+  * repair: Optimise unpacking of pack files, and avoid repeated error
+    messages about corrupt pack files.
+  * Add build dep on regex-compat to fix build on mipsel, which lacks
+    regex-tdfa.
+  * Disable test suite on sparc, which is missing optparse-applicative.
+  * Put non-object tmp files in .git/annex/misctmp, leaving .git/annex/tmp
+    for only partially transferred objects.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 27 Feb 2014 11:34:19 -0400
+
+git-annex (5.20140221) unstable; urgency=medium
+
+  * metadata: New command that can attach metadata to files.
+  * --metadata can be used to limit commands to acting on files
+    that have particular metadata.
+  * Preferred content expressions can use metadata=field=value
+    to limit them to acting on files that have particular metadata.
+  * view: New command that creates and checks out a branch that provides
+    a structured view of selected metadata.
+  * vfilter, vadd, vpop, vcycle: New commands for operating within views.
+  * pre-commit: Update metadata when committing changes to locations
+    of annexed files within a view.
+  * Add progress display for transfers to/from external special remotes.
+  * unused: Fix to actually detect unused keys when in direct mode.
+  * fsck: When run with --all or --unused, while .gitattributes
+    annex.numcopies cannot be honored since it's operating on keys
+    instead of files, make it honor the global numcopies setting,
+    and the annex.numcopies git config setting.
+  * trust, untrust, semitrust, dead: Warn when the trust level is
+    overridden in .git/config.
+  * glacier: Do not try to run glacier value create when an existing glacier
+    remote is enabled.
+  * fsck: Refuse to do anything if more than one of --incremental, --more,
+    and --incremental-schedule are given, since it's not clear which option
+    should win.
+  * Windows webapp: Can set up box.com, Amazon S3, and rsync.net remotes
+  * Windows webapp: Can create repos on removable drives.
+  * Windows: Ensure HOME is set, as needed by bundled cygwin utilities.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 21 Feb 2014 11:23:59 -0400
+
+git-annex (5.20140210) unstable; urgency=medium
+
+  * --in can now refer to files that were located in a repository at
+    some past date. For example, --in="here@{yesterday}"
+  * Fixed direct mode annexed content locking code, which is used to
+    guard against recursive file drops.
+  * This is the first beta-level release of the Windows port with important
+    fixes (see below).
+    (The webapp and assistant are still alpha-level on Windows.)
+  * sync --content: Honor annex-ignore configuration.
+  * sync: Don't try to sync with xmpp remotes, which are only currently
+    supported when using the assistant.
+  * sync --content: Re-pull from remotes after downloading content,
+    since that can take a while and other changes may be pushed in the
+    meantime.
+  * sync --content: Reuse smart copy code from copy command, including
+    handling and repairing out of date location tracking info.
+    Closes: #737480
+  * sync --content: Drop files from remotes that don't want them after
+    getting them.
+  * sync: Fix bug in automatic merge conflict resolution code when used
+    on a filesystem not supporting symlinks, which resulted in it losing
+    track of the symlink bit of annexed files.
+  * Added ways to configure rsync options to be used only when uploading
+    or downloading from a remote. Useful to eg limit upload bandwidth.
+  * Fix initremote with encryption=pubkey to work with S3, glacier, webdav,
+    and external special remotes.
+  * Avoid building with DAV 0.6 which is badly broken (see #737902).
+  * Fix dropping of unused keys with spaces in their name.
+  * Fix build on platforms not supporting the webapp.
+  * Document in man page that sshcaching uses ssh ControlMaster.
+    Closes: #737476
+  * Windows: It's now safe to run multiple git-annex processes concurrently
+    on Windows; the lock files have been sorted out.
+  * Windows: Avoid using unix-compat's rename, which refuses to rename
+    directories.
+  * Windows: Fix deletion of repositories by test suite and webapp.
+  * Windows: Test suite 100% passes again.
+  * Windows: Fix bug in symlink calculation code.
+  * Windows: Fix handling of absolute unix-style git repository paths.
+  * Android: Avoid crashing when unable to set file mode for ssh config file
+    due to Android filesystem horribleness.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 10 Feb 2014 12:54:57 -0400
+
+git-annex (5.20140127) unstable; urgency=medium
+
+  * sync --content: New option that makes the content of annexed files be
+    transferred. Similar to the assistant, this honors any configured
+    preferred content expressions.
+  * Remove --json option from commands not supporting it.
+  * status: Support --json.
+  * list: Fix specifying of files to list.
+  * Allow --all to be mixed with matching options like --copies and --in
+    (but not --include and --exclude).
+  * numcopies: New command, sets global numcopies value that is seen by all
+    clones of a repository.
+  * The annex.numcopies git config setting is deprecated. Once the numcopies
+    command is used to set the global number of copies, any annex.numcopies
+    git configs will be ignored.
+  * assistant: Make the prefs page set the global numcopies.
+  * Add lackingcopies, approxlackingcopies, and unused to
+    preferred content expressions.
+  * Client, transfer, incremental backup, and archive repositories
+    now want to get content that does not yet have enough copies.
+  * Client, transfer, and source repositories now do not want to retain
+    unused file contents.
+  * assistant: Checks daily for unused file contents, and when possible
+    moves them to a repository (such as a backup repository) that
+    wants to retain them.
+  * assistant: annex.expireunused can be configured to cause unused
+    file contents to be deleted after some period of time.
+  * webapp: Nudge user to see if they want to expire old unused file
+    contents when a lot of them seem to be piling up in the repository.
+  * repair: Check git version at run time.
+  * assistant: Run the periodic git gc in batch mode.
+  * added annex.secure-erase-command config option.
+  * test suite: Use tasty-rerun, and expose tasty command-line options.
+  * Optimise non-bare http remotes; no longer does a 404 to the wrong
+    url every time before trying the right url. Needs annex-bare to be
+    set to false, which is done when initially probing the uuid of a
+    http remote.
+  * webapp: After upgrading a git repository to git-annex, fix
+    bug that made it temporarily not be synced with.
+  * whereis: Support --all.
+  * All commands that support --all also support a --key option,
+    which limits them to acting on a single key.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 27 Jan 2014 13:43:28 -0400
+
+git-annex (5.20140117) unstable; urgency=medium
+
+  * Really fix FTBFS on mipsel and sparc due to test suite not being available
+    on those architectures.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 17 Jan 2014 14:46:27 -0400
+
+git-annex (5.20140116) unstable; urgency=medium
+
+  * Added tahoe special remote.
+  * external special remote protocol: Added GETGITDIR, and GETAVAILABILITY.
+  * Refuse to build with git older than 1.7.1.1, which is needed for
+    git checkout -B
+  * map: Fix display of v5 direct mode repos.
+  * repair: Support old git versions from before git fsck --no-dangling was
+    implemented.
+  * Fix a long-standing bug that could cause the wrong index file to be used
+    when committing to the git-annex branch, if GIT_INDEX_FILE is set in the
+    environment. This typically resulted in git-annex branch log files being
+    committed to the master branch and later showing up in the work tree.
+    (These log files can be safely removed.)
+  * assistant: Detect if .git/annex/index is corrupt at startup, and
+    recover.
+  * repair: Fix bug in packed refs file exploding code that caused a .gitrefs
+    directory to be created instead of .git/refs
+  * Fix FTBFS on mipsel and sparc due to test suite not being available
+    on those architectures.
+  * Android: Avoid passing --clobber to busybox wget.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 16 Jan 2014 11:34:54 -0400
+
+git-annex (5.20140107) unstable; urgency=medium
+
+  * mirror: Support --all (and --unused).
+  * external special remote protocol: Added GETUUID, GETWANTED, SETWANTED,
+    SETSTATE, GETSTATE, DEBUG.
+  * Windows: Fix bug in direct mode merge code that could cause files
+    in subdirectories to go missing.
+  * Windows: Avoid eating stdin when running ssh to add a authorized key,
+    since this is used for password prompting.
+  * Avoid looping if long-running git cat-file or git hash-object crashes
+    and keeps crashing when restarted.
+  * Assistant: Remove stale MERGE_HEAD files in lockfile cleanup.
+  * Remotes can now be made read-only, by setting remote.<name>.annex-readonly
+  * wanted, schedule: Avoid printing "ok" after requested value.
+  * assistant: Ensure that .ssh/config and .ssh/authorized_keys are not
+    group or world writable when writing to those files, as that can make
+    ssh refuse to use them, if it allows another user to write to them.
+  * addurl, importfeed: Honor annex.diskreserve as long as the size of the
+    url can be checked.
+  * add: Fix rollback when disk is completely full.
+  * assistant: Fixed several minor memory leaks that manifested when
+    adding a large number of files.
+  * assistant: Start a new git-annex transferkeys process
+    after a network connection change, so that remotes that use a persistent
+    network connection are restarted.
+  * Adjust Debian build deps to match current state of sparc, mipsel.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 07 Jan 2014 12:22:18 -0400
+
+git-annex (5.20131230) unstable; urgency=medium
+
+  * Added new external special remote interface.
+  * importfeed: Support youtube playlists.
+  * Add tasty to build-depends, so that test suite builds again.
+    (tasty was stuck in incoming.)
+  * Fix typo in test suite.
+  * Fix bug in Linux standalone build's shimming that broke git-annex-shell.
+  * Include git-receive-pack, git-upload-pack, git, and git-shell wrappers
+    in the Linux standalone build, and OSX app, so they will be available
+    when it's added to PATH.
+  * addurl, importfeed: Sanitize | and some other symbols and special
+    characters.
+  * Auto-upgrade v3 indirect repos to v5 with no changes.
+    This also fixes a problem when a direct mode repo was somehow set to v3
+    rather than v4, and so the automatic direct mode upgrade to v5 was not
+    done.
+  * Android: Avoid trying to use Android's own ionice, which does not
+    allow specifying a command to run. Fixes transferring files to/from
+    android and probably a few other things.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 30 Dec 2013 14:13:40 -0400
+
+git-annex (5.20131221) unstable; urgency=low
+
+  * assistant: Fix OSX-specific bug that caused the startup scan to try to
+    follow symlinks to other directories, and add their contents to the annex.
+  * assistant: Set StrictHostKeyChecking yes when creating ssh remotes,
+    and add it to the configuration for any ssh remotes previously created
+    by the assistant. This avoids repeated prompts by ssh if the host key
+    changes, instead syncing with such a remote will fail. Closes: #732602
+  * Fix test suite to cover lock --force change.
+  * Add plumbing-level lookupkey and examinekey commands.
+  * find --format: Added hashdirlower, hashdirmixed, keyname, and mtime
+    format variables.
+  * assistant: Always batch changes found in startup scan.
+  * An armel Linux standalone build is now available, which includes the
+    webapp.
+  * Programs from Linux and OSX standalone builds can now be symlinked
+    into a directory in PATH as an alternative installation method, and will
+    use readlink to find where the build was unpacked.
+  * Include man pages in Linux and OSX standalone builds.
+  * Linux standalone build now includes its own glibc and forces the linker to
+    use it, to remove dependence on the host glibc.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 21 Dec 2013 12:00:17 -0400
+
+git-annex (5.20131213) unstable; urgency=low
+
+  * Avoid using git commit in direct mode, since in some situations
+    it will read the full contents of files in the tree.
+  * assistant: Batch jobs are now run with ionice and nocache, when
+    those commands are available.
+  * assistant: Run transferkeys as batch jobs.
+  * Automatically fix up bad bare repositories created by
+    versions 5.20131118 through 5.20131127.
+  * rsync special remote: Fix fallback mode for rsync remotes that
+    use hashDirMixed. Closes: #731142
+  * copy --from, get --from: When --force is used, ignore the
+    location log and always try to get the file from the remote.
+  * Deal with box.com changing the url of their webdav endpoint.
+  * Android: Fix SRV record lookups for XMPP to use android getprop
+    command to find DNS server, since there is no resolv.conf.
+  * import: Add --skip-duplicates option.
+  * lock: Require --force. Closes: #731606
+  * import: better handling of overwriting an existing file/directory/broken
+    link when importing
+  * Windows: assistant and webapp work! (very experimental)
+  * Windows: Support annex.diskreserve.
+  * Fix bad behavior in Firefox, which was caused by an earlier fix to
+    bad behavior in Chromium.
+  * repair: Improve repair of git-annex index file.
+  * repair: Remove damaged git-annex sync branches.
+  * status: Ignore new files that are gitignored.
+  * Fix direct mode's handling when modifications to non-annexed files
+    are pulled from a remote. A bug prevented the files from being updated
+    in the work tree, and this caused the modification to be reverted.
+  * OSX: Remove ssh and ssh-keygen from dmg as they're included in OSX by
+    default.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 13 Dec 2013 14:20:32 -0400
+
+git-annex (5.20131130) unstable; urgency=low
+
+  * init: Fix a bug that caused git annex init, when run in a bare
+    repository, to set core.bare=false.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 30 Nov 2013 16:32:35 -0400
+
+git-annex (5.20131127.1) unstable; urgency=low
+
+  * Rebuild that does not try to use quvi 0.9 from experimental.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 28 Nov 2013 07:57:36 -0400
+
+git-annex (5.20131127) unstable; urgency=low
+
+  * webapp: Detect when upgrades are available, and upgrade if the user
+    desires.
+    (Only when git-annex is installed using the prebuilt binaries
+    from git-annex upstream, not from eg Debian.)
+  * assistant: Detect when the git-annex binary is modified or replaced,
+    and either prompt the user to restart the program, or automatically
+    restart it.
+  * annex.autoupgrade configures both the above upgrade behaviors.
+  * Added support for quvi 0.9. Slightly suboptimal due to limitations in its
+    interface compared with the old version.
+  * Bug fix: annex.version did not get set on automatic upgrade to v5 direct
+    mode repo, so the upgrade was performed repeatedly, slowing commands down.
+  * webapp: Fix bug that broke switching between local repositories
+    that use the new guarded direct mode.
+  * Android: Fix stripping of the git-annex binary.
+  * Android: Make terminal app show git-annex version number.
+  * Android: Re-enable XMPP support.
+  * reinject: Allow to be used in direct mode.
+  * Futher improvements to git repo repair. Has now been tested in tens
+    of thousands of intentionally damaged repos, and successfully
+    repaired them all.
+  * Allow use of --unused in bare repository.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 27 Nov 2013 18:41:44 -0400
+
+git-annex (5.20131120) unstable; urgency=low
+
+  * Fix Debian package to not try to run test suite, since haskell-tasty
+    is not out of new or in Build-Depends yet.
+  * dropunused, addunused: Allow "all" instead of a range to
+    act on all unused data.
+  * Ensure execute bit is set on directories when core.sharedrepository is set.
+  * Ensure that core.sharedrepository is honored when creating the .git/annex
+    directory.
+  * Improve repair code in the case where the index file is corrupt,
+    and this hides other problems from git fsck.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 20 Nov 2013 12:54:18 -0400
+
+git-annex (5.20131118) unstable; urgency=low
+
+  * Direct mode repositories now have core.bare=true set, to prevent
+    accidentally running git commands that try to operate on the work tree,
+    and so do the wrong thing in direct mode.
+  * annex.version is now set to 5 for direct mode repositories.
+    This upgrade is handled fully automatically, no need to run
+    git annex upgrade
+  * The "status" command has been renamed to "info", to allow
+    "git annex status" to be used in direct mode repositories, now that
+    "git status" won't work in them.
+  * The -c option now not only modifies the git configuration seen by
+    git-annex, but it is passed along to every git command git-annex runs.
+  * watcher: Avoid loop when adding a file owned by someone else fails
+    in indirect mode because its permissions cannot be modified.
+  * webapp: Avoid encoding problems when displaying the daemon log file.
+  * webapp: Improve UI around remote that have no annex.uuid set,
+    either because setup of them is incomplete, or because the remote
+    git repository is not a git-annex repository.
+  * Include ssh-keygen in standalone bundle.
+  * Allow optionally configuring git-annex with -fEKG to enable awesome
+    remote monitoring interfaceat http://localhost:4242/
+  * Fix bug that caused bad information to be written to the git-annex branch
+    when running describe or other commands with a remote that has no uuid.
+  * Work around Android linker problem that had prevented git-annex from
+    running on Android 4.3 and 4.4.
+  * repair: Handle case where index file is corrupt, but all objects are ok.
+  * assistant: Notice on startup when the index file is corrupt, and
+    auto-repair.
+  * Fix direct mode merge bug when a direct mode file was deleted and replaced
+    with a directory. An ordering problem caused the directory to not get
+    created in this case.
+    Thanks to Tim for the test case.
+  * Direct mode .git/annex/objects directories are no longer left writable,
+    because that allowed writing to symlinks of files that are not present,
+    which followed the link and put bad content in an object location.
+    Thanks to Tim for the test case.
+  * fsck: Fix up .git/annex/object directory permissions.
+  * Switched to the tasty test framework.
+  * Android: Adjust default .gitignore to ignore .thumbnails at any location
+    in the tree, not just at its top.
+  * webapp: Check annex.version.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 18 Nov 2013 10:45:43 -0400
+
+git-annex (4.20131106) unstable; urgency=low
+
+  * Improve local pairing behavior when two computers both try to start
+    the pairing process separately.
+  * sync: Work even when the local git repository is new and empty,
+    with no master branch.
+  * gcrypt, bup: Fix bug that prevented using these special remotes
+    with encryption=pubkey.
+  * Fix enabling of gcrypt repository accessed over ssh;
+    git-annex-shell gcryptsetup had a bug that caused it to fail
+    with permission denied.
+  * Fix zombie process that occurred when switching between repository
+    views in the webapp.
+  * map: Work when there are gcrypt remotes.
+  * Fix build w/o webapp.
+  * Fix exception handling bug that could cause .git/annex/index to be used
+    for git commits outside the git-annex branch. Known to affect git-annex
+    when used with the git shipped with Ubuntu 13.10.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 06 Nov 2013 11:17:47 -0400
+
+git-annex (4.20131101) unstable; urgency=low
+
+  * The "git annex content" command is renamed to "git annex wanted".
+  * New --want-get and --want-drop options which can be used to
+    test preferred content settings.
+    For example, "git annex find --in . --want-drop"
+  * assistant: When autostarted, wait 5 seconds before running the startup
+    scan, to avoid contending with the user's desktop login process.
+  * webapp: When setting up a bare shared repository, enable non-fast-forward
+    pushes.
+  * sync: Show a hint about receive.denyNonFastForwards when a push fails.
+  * directory, webdav: Fix bug introduced in version 4.20131002 that
+    caused the chunkcount file to not be written. Work around repositories
+    without such a file, so files can still be retreived from them.
+  * assistant: Automatically repair damanged git repository, if it can
+    be done without losing data.
+  * assistant: Support repairing git remotes that are locally accessible
+    (eg, on removable drives).
+  * add: Fix reversion in 4.20130827 when adding unlocked files that have
+    not yet been committed.
+  * unannex: New, much slower, but more safe behavior: Copies files out of
+    the annex. This avoids an unannex of one file breaking other files that
+    link to the same content. Also, it means that the content
+    remains in the annex using up space until cleaned up with 
+    "git annex unused".
+    (The behavior of unannex --fast has not changed; it still hard links
+    to content in the annex. --fast was not made the default because it is
+    potentially unsafe; editing such a hard linked file can unexpectedly
+    change content stored in the annex.)
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 01 Nov 2013 11:34:27 -0400
+
+git-annex (4.20131024) unstable; urgency=low
+
+  * webapp: Fix bug when adding a remote and git-remote-gcrypt
+    is not installed.
+  * The assitant can now run scheduled incremental fsck jobs on the local
+    repository and remotes. These can be configured using vicfg or with the
+    webapp.
+  * repair: New command, which can repair damaged git repositories
+    (even ones not using git-annex).
+  * webapp: When git repository damange is detected, repairs can be
+    done using the webapp UI.
+  * Automatically and safely detect and recover from dangling
+    .git/annex/index.lock files, which would prevent git from
+    committing to the git-annex branch, eg after a crash.
+  * assistant: Detect stale git lock files at startup time, and remove them.
+  * addurl: Better sanitization of generated filenames.
+  * Better sanitization of problem characters when generating URL and WORM
+    keys.
+  * The control socket path passed to ssh needs to be 17 characters
+    shorter than the maximum unix domain socket length, because ssh
+    appends stuff to it to make a temporary filename. Closes: #725512
+  * status: Fix space leak in local mode, introduced in version 4.20130920.
+  * import: Skip .git directories.
+  * Remove bogus runshell loop check.
+  * addurl: Improve message when adding url with wrong size to existing file.
+  * Fixed handling of URL keys that have no recorded size.
+  * status: Fix a crash if a temp file went away while its size was
+    being checked for status.
+  * Deal with git check-attr -z output format change in git 1.8.5.
+  * Work around sed output difference that led to version containing a newline
+    on OSX.
+  * sync: Fix automatic resolution of merge conflicts where one side is an
+    annexed file, and the other side is a non-annexed file, or a directory.
+  * S3: Try to ensure bucket name is valid for archive.org.
+  * assistant: Bug fix: When run in a subdirectory, files from incoming merges
+    were wrongly added to that subdirectory, and removed from their original
+    locations.
+  * Windows: Deal with strange msysgit 1.8.4 behavior of not understanding
+    DOS formatted paths for --git-dir and --work-tree.
+  * Removed workaround for bug in git 1.8.4r0.
+  * Added git-recover-repository command to git-annex source
+    (not built by default; this needs to move to someplace else).
+  * webapp: Move sidebar to the right hand side of the screen.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 24 Oct 2013 12:59:55 -0400
+
+git-annex (4.20131002) unstable; urgency=low
+
+  * Note that the layout of gcrypt repositories has changed, and
+    if you created one you must manually upgrade it.
+    See http://git-annex.branchable.com/upgrades/gcrypt/
+  * webapp: Support setting up and using encrypted git repositories on
+    any ssh server, as well as on rsync.net.
+  * git-annex-shell: Added support for operating inside gcrypt repositories.
+  * Disable receive.denyNonFastForwards when setting up a gcrypt special
+    remote, since gcrypt needs to be able to fast-forward the master branch.
+  * import: Preserve top-level directory structure.
+  * Use cryptohash rather than SHA for hashing when no external hash program
+    is available. This is a significant speedup for SHA256 on OSX, for
+    example.
+  * Added SKEIN256 and SKEIN512 backends.
+  * Android build redone from scratch, many dependencies updated,
+    and entire build can now be done using provided scripts.
+  * assistant: Clear the list of failed transfers when doing a full transfer
+    scan. This prevents repeated retries to download files that are not
+    available, or are not referenced by the current git tree.
+  * indirect, direct: Better behavior when a file is not owned by
+    the user running the conversion.
+  * add, import, assistant: Better preserve the mtime of symlinks,
+    when when adding content that gets deduplicated.
+  * Send a git-annex user-agent when downloading urls.
+    Overridable with --user-agent option.
+    (Not yet done for S3 or WebDAV due to limitations of libraries used.)
+  * webapp: Fixed a bug where when a new remote is added, one file
+    may fail to sync to or from it due to the transferrer process not
+    yet knowing about the new remote.
+  * OSX: Bundled gpg upgraded, now compatible with config files
+    written by MacGPG.
+  * assistant: More robust inotify handling; avoid crashing if a directory
+    cannot be read.
+  * Moved list of backends and remote types from status to version
+    command.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 02 Oct 2013 16:00:39 -0400
+
+git-annex (4.20130920) unstable; urgency=low
+
+  * webapp: Initial support for setting up encrypted removable drives.
+  * Recommend using my patched gcrypt, which fixes some bugs:
+    https://github.com/joeyh/git-remote-gcrypt
+  * Support hot-swapping of removable drives containing gcrypt repositories.
+  * list: New command, displays a compact table of remotes that
+    contain files.
+    (Thanks, anarcat for display code and mastensg for inspiration.)
+  * fsck: Fix detection and fixing of present direct mode files that are
+    wrongly represented as standin symlinks on crippled filesystems.
+  * sync: Fix bug that caused direct mode mappings to not be updated
+    when merging files into the tree on Windows.
+  * sync: Don't fail if the directory it is run in gets removed by the
+    sync.
+  * addurl: Fix quvi audodetection, broken in last release.
+  * status: In local mode, displays information about variance from configured
+    numcopies levels. (--fast avoids calculating these)
+  * gcrypt: Ensure that signing key is set to one of the participants keys.
+  * webapp: Show encryption information when editing a remote.
+  * Avoid unnecessarily catting non-symlink files from git, which can be
+    so large it runs out of memory.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 20 Sep 2013 10:34:51 -0400
+
+git-annex (4.20130911) unstable; urgency=low
+
+  * Fix problem with test suite in non-unicode locale.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 11 Sep 2013 12:14:16 -0400
+
+git-annex (4.20130909) unstable; urgency=low
+
+  * initremote: Syntax change when setting up an encrypted special remote.
+    Now use keyid=$KEYID rather than the old encryption=$KEYID
+  * forget: New command, causes git-annex branch history to be forgotten
+    in a way that will spread to other clones of the repository.
+    (As long as they're running this version or newer of git-annex.)
+  * forget --drop-dead: Completely removes mentions of repositories that
+    have been marked as dead from the git-annex branch.
+  * sync, assistant: Force push of the git-annex branch. Necessary
+    to ensure it gets pushed to remotes after being rewritten by forget.
+  * Added gcrypt support. This combines a fully encrypted git
+    repository (using git-remote-gcrypt) with an encrypted git-annex special
+    remote.
+  * sync: Support syncing with gcrypt remotes.
+  * importfeed: Also ignore transient problems with downloading content
+    from feeds.
+  * Honor core.sharedrepository when receiving and adding files in direct
+    mode.
+  * enableremote: gpg keys can be removed from those a remote encrypts
+    to by passing "keyid-=$KEYID". keyid+= is also provided.
+    (Thanks, guilhem for the patch.)
+  * Added encryption=pubkey scheme, which encrypts to public keys directly
+    rather than the hybrid approach. See documentation for advantages
+    and disadvantages, but encryption=hybrid is the recommended scheme still.
+    (Thanks, guilhem for the patch.)
+  * Fix Feeds display in build flags.
+  * Remind user when annex-ignore is set for some remotes, if unable to
+    get or drop a file, possibly because it's on an ignored remote.
+  * gpg: Force --no-textmode in case the user has it turned on in config.
+  * webapp: Improve javascript's handling of longpolling connection
+    failures, by reloading the current page in this case.
+    Works around chromium behavior where ajax connections to urls
+    that were already accessed are denied after navigating back to
+    a previous page.
+  * Allow building without quvi support.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 09 Sep 2013 09:47:02 -0400
+
+git-annex (4.20130827) unstable; urgency=low
+
+  * Youtube support! (And 53 other video hosts). When quvi is installed,
+    git-annex addurl automatically uses it to detect when an page is
+    a video, and downloads the video file.
+  * web special remote: Also support using quvi, for getting files,
+    or checking if files exist in the web.
+  * unused: Is now a minimum of 30 times faster, and typically many
+    more times than that (when a repository has several branches).
+    (Thanks, guilhem for the patch.)
+  * unused: Fix bugs in two edge cases involving manually staged changes.
+    (Thanks, guilhem for the patch.)
+  * Android: Fix bug in terminal app that caused it to spin using much 
+    CPU and battery. This problem was introduced in version 4.20130601.
+  * sync, merge: Bug fix: Don't try to merge into master when in a bare repo.
+  * import: Add options to control handling of duplicate files:
+    --duplicate, --deduplicate, and --clean-duplicates
+  * mirror: New command, makes two repositories contain the same set of files.
+  * Set --clobber when running wget to ensure resuming works properly.
+  * Unescape characters in 'file://...' URIs. (Thanks, guilhem for the patch.)
+  * Better error message when trying to use a git remote that has annex.ignore
+    set.
+  * Fix bug that caused typechanged symlinks to be assumed to be unlocked
+    files, so they were added to the annex by the pre-commit hook.
+  * Debian: Run the builtin test suite as an autopkgtest.
+  * Debian: Recommend ssh-askpass, which ssh will use when the assistant
+    is run w/o a tty. Closes: #719832
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 27 Aug 2013 11:03:00 -0400
+
+git-annex (4.20130815) unstable; urgency=low
+
+  * assistant, watcher: .gitignore files and other git ignores are now
+    honored, when git 1.8.4 or newer is installed.
+    (Thanks, Adam Spiers, for getting the necessary support into git for this.)
+  * importfeed: Ignores transient problems with feeds. Only exits nonzero
+    when a feed has repeatedly had a problems for at least 1 day.
+  * importfeed: Fix handling of dots in extensions.
+  * Windows: Added support for encrypted special remotes.
+  * Windows: Fixed permissions problem that prevented removing files
+    from directory special remote. Directory special remotes now fully usable.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 15 Aug 2013 10:14:33 +0200
+
+git-annex (4.20130802) unstable; urgency=low
+
+  * dropunused behavior change: Now refuses to drop the last copy of a
+    file, unless you use the --force.
+    This was the last place in git-annex that could remove data referred
+    to by the git history, without being forced.
+    Like drop, dropunused checks remotes, and honors the global
+    annex.numcopies setting. (However, .gitattributes settings cannot
+    apply to unused files.) 
+  * Fix inverted logic in last release's fix for data loss bug,
+    that caused git-annex sync on FAT or other crippled filesystems to add
+    symlink standin files to the annex.
+  * importfeed can be used to import files from podcast feeds.
+  * webapp: When setting up a dedicated ssh key to access the annex
+    on a host, set IdentitiesOnly to prevent the ssh-agent from forcing
+    use of a different ssh key. That could result in unnecessary password
+    prompts, or prevent git-annex-shell from being run on the remote host.
+  * webapp: Improve handling of remotes whose setup has stalled.
+  * Add status message to XMPP presence tag, to identify to others that
+    the client is a git-annex client. Closes: #717652
+  * webapp: When creating a repository on a removable drive, set
+    core.fsyncobjectfiles, to help prevent data loss when the drive is yanked.
+  * Always build with -threaded, to avoid a deadlock when communicating with
+    gpg.
+  * unused: No longer shows as unused tmp files that are actively being
+    transferred.
+  * assistant: Fix NetWatcher to not sync with remotes that have
+    remote.<name>.annex-sync set to false.
+  * assistant: Fix deadlock that could occur when adding a lot of files
+    at once in indirect mode.
+  * assistant: Fix bug that caused it to stall when adding a very large
+    number of files at once (around 5 thousand).
+  * OSX: Make git-annex-webapp run in the background, so that the app icon
+    can be clicked on the open a new webapp when the assistant is already
+    running.
+  * Improve test suite on Windows; now tests git annex sync.
+  * Fix a few bugs involving filenames that are at or near the filesystem's
+    maximum filename length limit.
+  * find: Avoid polluting stdout with progress messages. Closes: #718186
+  * Escape ':' in file/directory names to avoid it being treated
+    as a pathspec by some git commands. Closes: #718185
+  * Slow and ugly work around for bug #718517 in git 1.8.4~rc0, which broke
+    git-cat-file --batch for filenames containing spaces.
+    (Will be reverted after next git pre-release fixes the problem.)
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 02 Aug 2013 11:35:16 -0400
+
+git-annex (4.20130723) unstable; urgency=low
+
+  * Fix data loss bug when adding an (uncompressed) tarball of a
+    git-annex repository, or other file that begins with something
+    that can be mistaken for a git-annex link. Closes: #717456
+  * New improved version of the git-annex logo, contributed by
+    John Lawrence.
+  * Rsync.net have committed to support git-annex and offer a special
+    discounted rate for git-annex users. Updated the webapp to reflect this.
+    http://www.rsync.net/products/git-annex-pricing.html
+  * Install XDG desktop icon files.
+  * Support unannex and uninit in direct mode.
+  * Support import in direct mode.
+  * webapp: Better display of added files.
+  * fix: Preserve the original mtime of fixed symlinks.
+  * uninit: Preserve .git/annex/objects at the end, if it still
+    has content, so that old versions of files and deleted files
+    are not deleted. Print a message with some suggested actions.
+  * When a transfer is already being run by another process,
+    proceed on to the next file, rather than dying.
+  * Fix checking when content is present in a non-bare repository
+    accessed via http.
+  * Display byte sizes with more precision.
+  * watcher: Fixed a crash that could occur when a directory was renamed
+    or deleted before it could be scanned.
+  * watcher: Partially worked around a bug in hinotify, no longer crashes
+    if hinotify cannot process a directory (but can't detect changes in it)
+  * directory special remote: Fix checking that there is enough disk space
+    to hold an object, was broken when using encryption.
+  * webapp: Differentiate between creating a new S3/Glacier/WebDav remote,
+    and initializing an existing remote. When creating a new remote, avoid
+    conflicts with other existing (or deleted) remotes with the same name.
+  * When an XMPP server has SRV records, try them, but don't then fall
+    back to the regular host if they all fail.
+  * For long hostnames, use a hash of the hostname to generate the socket
+    file for ssh connection caching.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 23 Jul 2013 10:46:05 -0400
+
+git-annex (4.20130709) unstable; urgency=low
+
+  * --all: New switch that makes git-annex operate on all data stored
+    in the git annex, including old versions of files. Supported by
+    fsck, get, move, copy.
+  * --unused: New switch that makes git-annex operate on all data found
+    by the last run of git annex unused. Supported by fsck, move, copy.
+  * get, move, copy: Can now be run in a bare repository,
+    like fsck already could. --all is enabled automatically in this case.
+  * merge: Now also merges synced/master or similar branches, which 
+    makes it useful to put in a post-receive hook to make a repository
+    automatically update its working copy when git annex sync or the assistant
+    sync with it.
+  * webapp: Fix ssh setup with nonstandard port, broken in last release.
+  * init: Detect systems on which git commit fails due to not being able to
+    determine the FQDN, and put in a workaround so committing to the git-annex
+    branch works.
+  * addurl --pathdepth: Fix failure when the pathdepth specified is deeper
+    than the urls's path.
+  * Windows: Look for .exe extension when searching for a command in path.
+  * Pass -f to curl when downloading a file with it, so it propigates failure. 
+  * Windows: Fix url to object when using a http remote.
+  * webapp: Fix authorized_keys line added when setting up a rsync remote
+    on a server that also supports git-annex, to not force running
+    git-annex-shell.
+  * OSX Mountain Lion: Fixed gpg bundled in dmg to not fail due to a missing
+    gpg-agent.
+  * Android: gpg is built without --enable-minimal, so it interoperates
+    better with other gpg builds that may default to using other algorithms
+    for encryption.
+  * dropunused, addunused: Complain when asked to operate on a number that
+    does not correspond to any unused key.
+  * fsck: Don't claim to fix direct mode when run on a symlink whose content
+    is not present.
+  * Make --numcopies override annex.numcopies set in .gitattributes.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 09 Jul 2013 13:55:39 -0400
+
+git-annex (4.20130627) unstable; urgency=low
+
+  * assistant --autostart: Automatically ionices the daemons it starts.
+  * assistant: Daily sanity check thread is run niced.
+  * bup: Handle /~/ in bup remote paths.
+    Thanks, Oliver Matthews
+  * fsck: Ensures that direct mode is used for files when it's enabled.
+  * webapp: Fix bug when setting up a remote ssh repo repeatedly on the same
+    server.
+  * webapp: Ensure that ssh keys generated for different directories
+    on a server are always different.
+  * webapp: Fix bug setting up ssh repo if the user enters "~/" at the start 
+    of the path.
+  * assistant: Fix bug that prevented adding files written by gnucash, 
+    and more generally support adding hard links to files. However,
+    other operations on hard links are still unsupported.
+  * webapp: Fix bug that caused the webapp to hang when built with yesod 1.2.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 27 Jun 2013 14:21:55 -0400
+
+git-annex (4.20130621) unstable; urgency=low
+
+  * Supports indirect mode on encfs in paranoia mode, and other
+    filesystems that do not support hard links, but do support
+    symlinks and other POSIX filesystem features.
+  * Android: Add .thumbnails to .gitignore when setting up a camera
+    repository.
+  * Android: Make the "Open webapp" menu item open the just created
+    repository when a new repo is made.
+  * webapp: When the user switches to display a different repository,
+    that repository becomes the default repository to be displayed next time
+    the webapp gets started.
+  * glacier: Better handling of the glacier inventory, which avoids
+    duplicate uploads to the same glacier repository by `git annex copy`.
+  * Direct mode: No longer temporarily remove write permission bit of files
+    when adding them.
+  * sync: Better support for bare git remotes. Now pushes directly to the
+    master branch on such a remote, instead of to synced/master. This
+    makes it easier to clone from a bare git remote that has been populated
+    with git annex sync or by the assistant.
+  * Android: Fix use of cp command to not try to use features present
+    only on build system.
+  * Windows: Fix hang when adding several files at once.
+  * assistant: In direct mode, objects are now only dropped when all
+    associated files are unwanted. This avoids a repreated drop/get loop
+    of a file that has a copy in an archive directory, and a copy not in an
+    archive directory. (Indirect mode still has some buggy behavior in this
+    area, since it does not keep track of associated files.)
+    Closes: #712060
+  * status: No longer shows dead repositories.
+  * annex.debug can now be set to enable debug logging by default.
+    The webapp's debugging check box does this.
+  * fsck: Avoid getting confused by Windows path separators
+  * Windows: Multiple bug fixes, including fixing the data written to the
+    git-annex branch.
+  * Windows: The test suite now passes on Windows (a few broken parts are
+    disabled).
+  * assistant: On Linux, the expensive transfer scan is run niced.
+  * Enable assistant and WebDAV support on powerpc and sparc architectures,
+    which now have the necessary dependencies built.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 21 Jun 2013 10:18:41 -0400
+
+git-annex (4.20130601) unstable; urgency=medium
+
+  * XMPP: Git push over xmpp made much more robust.
+  * XMPP: Avoid redundant and unnecessary pushes. Note that this breaks
+    compatibility with previous versions of git-annex, which will refuse
+    to accept any XMPP pushes from this version.
+  * XMPP: Send pings and use them to detect when contact with the server
+    is lost.
+  * hook special remote: Added combined hook program support.
+  * Android app: Avoid using hard links to app's lib directory, which
+    is sometimes on a different filesystem than the data directory.
+  * Fix bug in parsing of parens in some preferred content expressions.
+    This fixes the behavior of the manual mode group.
+  * assistant: Work around git-cat-file's not reloading the index after files
+    are staged.
+  * Improve error handling when getting uuid of http remotes to auto-ignore,
+    like with ssh remotes.
+  * content: New command line way to view and configure a repository's
+    preferred content settings.
+  * sync: Fix double merge conflict resolution handling.
+  * XMPP: Fix a file descriptor leak.
+  * Android: Added an "Open WebApp" item to the terminal's menu.
+  * Android: Work around Android devices where the `am` command doesn't work.
+  * Can now restart certain long-running git processes if they crash, and
+    continue working.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 01 Jun 2013 19:16:04 -0400
+
+git-annex (4.20130521) unstable; urgency=low
+
+  * Sanitize debian changelog version before putting it into cabal file.
+    Closes: #708619
+  * Switch to MonadCatchIO-transformers for better handling of state while
+    catching exceptions.
+  * Fix a zombie that could result when running a process like gpg to
+    read and write to it.
+  * Allow building with gpg2.
+  * Disable building with the haskell threaded runtime when the webapp
+    is not built. This may fix builds on mips, s390x and sparc, which are
+    failing to link -lHSrts_thr
+  * Temporarily build without webapp on kfreebsd-i386, until yesod is
+    installable there again.
+  * Direct mode bug fix: After a conflicted merge was automatically resolved,
+    the content of a file that was already present could incorrectly
+    be replaced with a symlink.
+  * Fix a bug in the git-annex branch handling code that could
+    cause info from a remote to not be merged and take effect immediately.
+  * Direct mode is now fully tested by the test suite.
+  * Detect bad content in ~/.config/git-annex/program and look in PATH instead.
+  * OSX: Fixed gpg included in dmg.
+  * Linux standalone: Back to being built with glibc 2.13 for maximum
+    portability.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 21 May 2013 13:10:26 -0400
+
+git-annex (4.20130516) unstable; urgency=low
+
+  * Android: The webapp is ported and working.
+  * Windows: There is a very rough Windows port. Do not trust it with
+    important data.
+  * git-annex-shell: Ensure that received files can be read. Files
+    transferred from some Android devices may have very broken permissions
+    as received.
+  * direct mode: Direct mode commands now work on files staged in the index,
+    they do not need to be committed to git.
+  * Temporarily add an upper bound to the version of yesod that can be built
+    with, since yesod 1.2 has a great many changes that will require extensive
+    work on the webapp.
+  * Disable building with the haskell threaded runtime when the assistant
+    is not built. This may fix builds on s390x and sparc, which are failing
+    to link -lHSrts_thr
+  * Avoid depending on regex-tdfa on mips, mipsel, and s390, where it fails
+    to build.
+  * direct: Fix a bug that could cause some files to be left in indirect mode.
+  * When initializing a directory special remote with a relative path,
+    the path is made absolute.
+  * SHA: Add a runtime sanity check that sha commands output something
+    that appears to be a real sha.
+  * configure: Better checking that sha commands output in the desired format.
+  * rsync special remotes: When sending from a crippled filesystem, use
+    the destination's default file permissions, as the local ones can
+    be arbitrarily broken. (Ie, ----rwxr-x for files on Android)
+  * migrate: Detect if a file gets corrupted while it's being migrated.
+  * Debian: Add a menu file.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 16 May 2013 11:03:35 -0400
+
+git-annex (4.20130501) unstable; urgency=low
+
+  * sync, assistant: Behavior changes: Sync with remotes that have
+    annex-ignore set, so that git remotes on servers without git-annex
+    installed can be used to keep clients' git repos in sync.
+  * assistant: Work around misfeature in git 1.8.2 that makes
+    `git commit --alow-empty -m ""` run an editor.
+  * sync: Bug fix, avoid adding to the annex the 
+    dummy symlinks used on crippled filesystems.
+  * Add public repository group.
+    (And inpreferreddir to preferred content expressions.)
+  * webapp: Can now set up Internet Archive repositories.
+  * S3: Dropping content from the Internet Archive doesn't work, but
+    their API indicates it does. Always refuse to drop from there.
+  * Automatically register public urls for files uploaded to the
+    Internet Archive.
+  * To enable an existing special remote, the new enableremote command
+    must be used. The initremote command now is used only to create
+    new special remotes.
+  * initremote: If two existing remotes have the same name,
+    prefer the one with a higher trust level.
+  * assistant: Improved XMPP protocol to better support multiple repositories
+    using the same XMPP account. Fixes bad behavior when sharing with a friend
+    when you or the friend have multiple reposotories on an XMPP account.
+    Note that XMPP pairing with your own devices still pairs with all
+    repositories using your XMPP account.
+  * assistant: Fix bug that could cause incoming pushes to not get
+    merged into the local tree. Particularly affected XMPP pushes.
+  * webapp: Display some additional information about a repository on
+    its edit page.
+  * webapp: Install FDO desktop menu file when started in standalone mode.
+  * webapp: Don't default to making repository in cwd when started
+    from within a directory containing a git-annex file (eg, standalone
+    tarball directory).
+  * Detect systems that have no user name set in GECOS, and also
+    don't have user.name set in git config, and put in a workaround
+    so that commits to the git-annex branch (and the assistant)
+    will still succeed despite git not liking the system configuration.
+  * webapp: When told to add a git repository on a remote server, and
+    the repository already exists as a non-bare repository, use it,
+    rather than initializing a bare repository in the same directory.
+  * direct, indirect: Refuse to do anything when the assistant
+    or git-annex watch daemon is running.
+  * assistant: When built with git before 1.8.0, use `git remote rm`
+    to delete a remote. Newer git uses `git remote remove`.
+  * rmurl: New command, removes one of the recorded urls for a file.
+  * Detect when the remote is broken like bitbucket is, and exits 0 when
+    it fails to run git-annex-shell.
+  * assistant: Several improvements to performance and behavior when
+    performing bulk adds of a large number of files (tens to hundreds
+    of thousands).
+  * assistant: Sanitize XMPP presence information logged for debugging.
+  * webapp: Now automatically fills in any creds used by an existing remote
+    when creating a new remote of the same type. Done for Internet Archive,
+    S3, Glacier, and Box.com remotes.
+  * Store an annex-uuid file in the bucket when setting up a new S3 remote.
+  * Support building with DAV 0.4.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 01 May 2013 01:42:46 -0400
+
+git-annex (4.20130417) unstable; urgency=low
+
+  * initremote: Generates encryption keys with high quality entropy.
+    This can be disabled using --fast to get the old behavior.
+    The assistant still uses low-quality entropy when creating encrypted
+    remotes, to avoid delays. (Thanks, guilhem for the patch.)
+  * Bugfix: Direct mode no longer repeatedly checksums duplicated files.
+  * assistant: Work around horrible, terrible, very bad behavior of
+    gnome-keyring, by not storing special-purpose ssh keys in ~/.ssh/*.pub.
+    Apparently gnome-keyring apparently will load and indiscriminately use
+    such keys in some cases, even if they are not using any of the standard
+    ssh key names. Instead store the keys in ~/.ssh/annex/,
+    which gnome-keyring will not check.
+  * addurl: Bugfix: Did not properly add file in direct mode.
+  * assistant: Bug fix to avoid annexing the files that git uses
+    to stand in for symlinks on FAT and other filesystem not supporting
+    symlinks.
+  * Adjust preferred content expressions so that content in archive
+    directories is preferred until it has reached an archive or smallarchive
+    repository.
+  * webapp: New --listen= option allows running the webapp on one computer
+    and connecting to it from another. (Note: Does not yet use HTTPS.)
+  * Added annex.web-download-command setting.
+  * Added per-remote annex-rsync-transport option. (guilhem again)
+  * Ssh connection caching is now also used by rsync special remotes.
+    (guilhem yet again)
+  * The version number is now derived from git, unless built with
+    VERSION_FROM_CHANGELOG.
+  * assistant: Stop any transfers the assistant initiated on shutdown.
+  * assistant: Added sequence numbers to XMPP git push packets. (Not yet used.)
+  * addurl: Register transfer so the webapp can see it.
+  * addurl: Automatically retry downloads that fail, as long as some
+    additional content was downloaded.
+  * webapp: Much improved progress bar display for downloads from encrypted
+    remotes.
+  * Avoid using runghc, as that needs ghci.
+  * webapp: When a repository's group is changed, rescan for transfers.
+  * webapp: Added animations.
+  * webapp: Include the repository directory in the mangled hostname and
+    ssh key name, so that a locked down ssh key for one repository is not
+    re-used when setting up additional repositories on the same server.
+  * Fall back to internal url downloader when built without curl.
+  * fsck: Check content of direct mode files (only when the inode cache
+    thinks they are unmodified).
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 17 Apr 2013 09:07:38 -0400
+
+git-annex (4.20130405) unstable; urgency=low
+
+  * Group subcommands into sections in usage. Closes: #703797
+  * Per-command usage messages.
+  * webapp: Fix a race that sometimes caused alerts or other notifications
+    to be missed if they occurred while a page was loading.
+  * webapp: Progess bar fixes for many types of special remotes.
+  * Build debian package without using cabal, which writes to HOME.
+    Closes: #704205
+  * webapp: Run ssh server probes in a way that will work when the
+    login shell is a monstrosity that should have died 25 years ago,
+    such as csh.
+  * New annex.largefiles setting, which configures which files
+    `git annex add` and the assistant add to the annex.
+  * assistant: Check small files into git directly.
+  * Remotes can be configured to use other MAC algorithms than HMACSHA1
+    to encrypt filenames.
+    Thanks, guilhem for the patch.
+  * git-annex-shell: Passes rsync --bwlimit options on rsync.
+    Thanks, guilhem for the patch.
+  * webapp: Added UI to delete repositories. Closes: #689847
+  * Adjust built-in preferred content expressions to make most types
+    of repositories want content that is only located on untrusted, dead,
+    and unwanted repositories.
+  * drop --auto: Fix bug that prevented dropping files from untrusted
+    repositories.
+  * assistant: Fix bug that could cause direct mode files to be unstaged
+    from git.
+  * Update working tree files fully atomically.
+  * webapp: Improved transfer queue management.
+  * init: Probe whether the filesystem supports fifos, and if not,
+    disable ssh connection caching.
+  * Use lower case hash directories for storing files on crippled filesystems,
+    same as is already done for bare repositories.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 05 Apr 2013 10:42:18 -0400
+
+git-annex (4.20130323) unstable; urgency=low
+
+  * webapp: Repository list is now included in the dashboard, and other
+    UI tweaks.
+  * webapp: Improved UI for pairing your own devices together using XMPP.
+  * webapp: Display an alert when there are XMPP remotes, and a cloud
+    transfer repository needs to be configured.
+  * Add incrementalbackup repository group.
+  * webapp: Encourage user to install git-annex on a server when adding
+    a ssh server, rather than just funneling them through to rsync.
+  * xmpp: --debug now enables a sanitized dump of the XMPP protocol
+  * xmpp: Try harder to detect presence of clients when there's a git push
+    to send.
+  * xmpp: Re-enable XA flag, since disabling it did not turn out to help
+    with the problems Google Talk has with not always sending presence
+    messages to clients.
+  * map: Combine duplicate repositories, for a nicer looking map.
+  * Fix several bugs caused by a bad Ord instance for Remote.
+  * webapp: Switch all forms to POST.
+  * assistant: Avoid syncing with annex-ignored remotes when reconnecting
+    to the network, or connecting a drive.
+  * assistant: Fix OSX bug that prevented committing changed files to a
+    repository when in indirect mode.
+  * webapp: Improved alerts displayed when syncing with remotes, and 
+    when syncing with a remote fails.
+  * webapp: Force wrap long filenames in transfer display.
+  * assistant: The ConfigMonitor left one zombie behind each time
+    it checked for changes, now fixed.
+  * get, copy, move: Display an error message when an identical transfer
+    is already in progress, rather than failing with no indication why.
+  * assistant: Several optimisations to file transfers.
+  * OSX app and standalone Linux tarball now both support being added to
+    PATH; no need to use runshell to start git-annex.
+  * webapp: When adding a removable drive, you can now specify the
+    directory inside it to use.
+  * webapp: Confirm whether user wants to combine repositories when
+    adding a removable drive that already has a repository on it.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 22 Mar 2013 18:54:05 -0400
+
+git-annex (4.20130314) unstable; urgency=low
+
+  * Bugfix: git annex add, when ran without any file or directory specified,
+    should add files in the current directory, but not act on unlocked files
+    elsewhere in the tree.
+  * Bugfix: drop --from an unavailable remote no longer updates the location
+    log, incorrectly, to say the remote does not have the key.
+  * Bugfix: If the UUID of a remote is not known, prevent --from, --to,
+    and other ways of specifying remotes by name from selecting it,
+    since it is not possible to sanely use it.
+  * Bugfix: Fix bug in inode cache sentinal check, which broke
+    copying to local repos if the repo being copied from had moved
+    to a different filesystem or otherwise changed all its inodes
+
+  * Switch from using regex-compat to regex-tdfa, as the C regex library
+    is rather buggy.
+  * status: Can now be run with a directory path to show only the
+    status of that directory, rather than the whole annex.
+  * Added remote.<name>.annex-gnupg-options setting.
+    Thanks, guilhem for the patch.
+  * addurl: Add --relaxed option.
+  * addurl: Escape invalid characters in urls, rather than failing to
+    use an invalid url.
+  * addurl: Properly handle url-escaped characters in file:// urls.
+
+  * assistant: Fix dropping content when a file is moved to an archive
+    directory, and getting contennt when a file is moved back out.
+  * assistant: Fix bug in direct mode that could occur when a symlink is
+    moved out of an archive directory, and resulted in the file not being
+    set to direct mode when it was transferred.
+  * assistant: Generate better commits for renames.
+  * assistant: Logs are rotated to avoid them using too much disk space.
+  * assistant: Avoid noise in logs from git commit about typechanged
+    files in direct mode repositories.
+  * assistant: Set gc.auto=0 when creating repositories to prevent
+    automatic commits from causing git-gc runs.
+  * assistant: If gc.auto=0, run git-gc once a day, packing loose objects
+    very non-aggressively.
+  * assistant: XMPP git pull and push requests are cached and sent when
+    presence of a new client is detected.
+  * assistant: Sync with all git remotes on startup.
+  * assistant: Get back in sync with XMPP remotes after network reconnection,
+    and on startup.
+  * assistant: Fix syncing after XMPP pairing.
+  * assistant: Optimised handling of renamed files in direct mode,
+    avoiding re-checksumming.
+  * assistant: Detects most renames, including directory renames, and
+    combines all their changes into a single commit.
+  * assistant: Fix ~/.ssh/git-annex-shell wrapper to work when the
+    ssh key does not force a command.
+  * assistant: Be smarter about avoiding unnecessary transfers.
+
+  * webapp: Work around bug in Warp's slowloris attack prevention code,
+    that caused regular browsers to stall when they reuse a connection
+    after leaving it idle for 30 seconds.
+    (See https://github.com/yesodweb/wai/issues/146)
+  * webapp: New preferences page allows enabling/disabling debug logging
+    at runtime, as well as configuring numcopies and diskreserve.
+  * webapp: Repository costs can be configured by dragging repositories around
+    in the repository list.
+  * webapp: Proceed automatically on from "Configure jabber account"
+    to pairing.
+  * webapp: Only show up to 10 queued transfers.
+  * webapp: DTRT when told to create a git repo that already exists.
+  * webapp: Set locally paired repositories to a lower cost than other
+    network remotes.
+
+  * Run ssh with -T to avoid tty allocation and any login scripts that
+    may do undesired things with it.
+  * Several improvements to Makefile and cabal file. Thanks, Peter Simmons
+  * Stop depending on testpack.
+  * Android: Enable test suite. 
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 14 Mar 2013 15:29:20 -0400
+
+git-annex (4.20130227) unstable; urgency=low
+
+  * annex.version is now set to 4 for direct mode repositories.
+  * Should now fully support git repositories with core.symlinks=false;
+    always using git's pseudosymlink files in such repositories.
+  * webapp: Allow creating repositories on filesystems that lack support for
+    symlinks.
+  * webapp: Can now add a new local repository, and make it sync with
+    the main local repository.
+  * Android: Bundle now includes openssh.
+  * Android: Support ssh connection caching.
+  * Android: Assistant is fully working. (But no webapp yet.)
+  * Direct mode: Support filesystems like FAT which can change their inodes
+    each time they are mounted.
+  * Direct mode: Fix support for adding a modified file.
+  * Avoid passing -p to rsync, to interoperate with crippled filesystems.
+    Closes: #700282
+  * Additional GIT_DIR support bugfixes. May actually work now.
+  * webapp: Display any error message from git init if it fails to create
+    a repository.
+  * Fix a reversion in matching globs introduced in the last release,
+    where "*" did not match files inside subdirectories. No longer uses
+    the Glob library.
+  * copy: Update location log when no copy was performed, if the location
+    log was out of date.
+  * Makefile now builds using cabal, taking advantage of cabal's automatic
+    detection of appropriate build flags.
+  * test: The test suite is now built into the git-annex binary, and can
+    be run at any time.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 27 Feb 2013 14:07:24 -0400
+
+git-annex (3.20130216) unstable; urgency=low
+
+  * Now uses the Haskell uuid library, rather than needing a uuid program.
+  * Now uses the Haskell Glob library, rather than pcre-light, avoiding
+    the need to install libpcre. Currently done only for Cabal or when
+    the Makefile is made to use -DWITH_GLOB
+  * Android port now available (command-line only).
+  * New annex.crippledfilesystem setting, allows use of git-annex
+    repositories on FAT and even worse filesystems; avoiding use of
+    hard links and locked down permissions settings. (Support is incomplete.)
+  * init: Detect when the repository is on a filesystem that does not
+    support hard links, or symlinks, or unix permissions, and set
+    annex.crippledfilesystem, as well as annex.direct.
+  * add: Improved detection of files that are modified while being added.
+  * Fix a bug in direct mode, introduced in the previous release, where
+    if a file was dropped and then got back, it would be stored in indirect
+    mode.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 16 Feb 2013 10:03:26 -0400
+
+git-annex (3.20130207) unstable; urgency=low
+
+  * webapp: Now allows restarting any threads that crash.
+  * Adjust debian package to only build-depend on DAV on architectures
+    where it is available.
+  * addurl --fast: Use curl, rather than haskell HTTP library, to support https.
+  * annex.autocommit: New setting, can be used to disable autocommit
+    of changed files by the assistant, while it still does data syncing
+    and other tasks.
+  * assistant: Ignore .DS_Store on OSX.
+  * assistant: Fix location log when adding new file in direct mode.
+  * Deal with stale mappings for deleted file in direct mode.
+  * pre-commit: Update direct mode mappings. 
+  * uninit, unannex --fast: If hard link creation fails, fall back to slow
+    mode.
+  * Clean up direct mode cache and mapping info when dropping keys.
+  * dropunused: Clean up stale direct mode cache and mapping info not
+    removed before.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 07 Feb 2013 12:45:25 -0400
+
+git-annex (3.20130124) unstable; urgency=low
+
+  * Added source repository group, that only retains files until they've
+    been transferred to another repository. Useful for things like
+    repositories on cameras.
+  * Added manual repository group. Use to prevent the assistant from
+    downloading any file contents to keep things in sync. Instead
+    `git annex get`, `git annex drop` etc can be used manually as desired.
+  * webapp: More adjustments to longpoll code to deal with changes in
+    variable quoting in different versions of shakespeare-js.
+  * webapp: Avoid an error if a transfer is stopped just as it finishes.
+    Closes: #698184 
+  * webapp: Now always logs to .git/annex/daemon.log
+  * webapp: Has a page to view the log, accessed from the control menu.
+  * webapp: Fix crash adding removable drive that has an annex directory
+    in it that is not a git repository.
+  * Deal with incompatibility in gpg2, which caused prompts for encryption
+    passphrases rather than using the supplied --passphrase-fd.
+  * bugfix: Union merges involving two or more repositories could sometimes
+    result in data from one repository getting lost. This could result
+    in the location log data becoming wrong, and fsck being needed to fix it.
+  * sync: Automatic merge conflict resolution now stages deleted files.
+  * Depend on git 1.7.7.6 for --no-edit. Closes: #698399
+  * Fix direct mode mapping code to always store direct mode filenames
+    relative to the top of the repository, even when operating inside a
+    subdirectory.
+  * fsck: Detect and fix consistency errors in direct mode mapping files.
+  * Avoid filename encoding errors when writing direct mode mappings.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 22 Jan 2013 07:11:59 +1100
+
+git-annex (3.20130114) unstable; urgency=low
+
+  * Now handles the case where a file that's being transferred to a remote
+    is modified in place, which direct mode allows. When this
+    happens, the transfer now fails, rather than allow possibly corrupt
+    data into the remote.
+  * fsck: Better checking of file content in direct mode.
+  * drop: Suggest using git annex move when numcopies prevents dropping a file.
+  * webapp: Repo switcher filters out repos that do not exist any more
+    (or are on a drive that's not mounted).
+  * webapp: Use IP address, rather than localhost, since some systems may
+    have configuration problems or other issues that prevent web browsers
+    from connecting to the right localhost IP for the webapp.
+  * webapp: Adjust longpoll code to work with recent versions of
+    shakespeare-js.
+  * assistant: Support new gvfs dbus names used in Gnome 3.6.
+  * In direct mode, files with the same key are no longer hardlinked, as
+    that would cause a surprising behavior if modifying one, where the other
+    would also change.
+  * webapp: Avoid illegal characters in hostname when creating S3 or
+    Glacier remote.
+  * assistant: Avoid committer crashing if a file is deleted at the wrong
+    instant.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 14 Jan 2013 15:25:18 -0400
+
+git-annex (3.20130107) unstable; urgency=low
+
+  * webapp: Add UI to stop and restart assistant.
+  * committer: Fix a file handle leak.
+  * assistant: Make expensive transfer scan work fully in direct mode.
+  * More commands work in direct mode repositories: find, whereis, move, copy,
+    drop, log, fsck, add, addurl.
+  * sync: No longer automatically adds files in direct mode.
+  * assistant: Detect when system is not configured with a user name,
+    and set environment to prevent git from failing.
+  * direct: Avoid hardlinking symlinks that point to the same content
+    when the content is not present.
+  * Fix transferring files to special remotes in direct mode.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 07 Jan 2013 01:01:41 -0400
+
+git-annex (3.20130102) unstable; urgency=low
+
+  * direct, indirect: New commands, that switch a repository to and from
+    direct mode. In direct mode, files are accessed directly, rather than
+    via symlinks. Note that direct mode is currently experimental. Many
+    git-annex commands do not work in direct mode. Some git commands can
+    cause data loss when used in direct mode repositories.
+  * assistant: Now uses direct mode by default when setting up a new
+    local repository.
+  * OSX assistant: Uses the FSEvents API to detect file changes.
+    This avoids issues with running out of file descriptors on large trees,
+    as well as allowing detection of modification of files in direct mode.
+    Other BSD systems still use kqueue.
+  * kqueue: Fix bug that made broken symlinks not be noticed.
+  * vicfg: Quote filename. Closes: #696193
+  * Bugfix: Fixed bug parsing transfer info files, where the newline after
+    the filename was included in it. This was generally benign, but in
+    the assistant, it caused unexpected dropping of preferred content.
+  * Bugfix: Remove leading \ from checksums output by sha*sum commands,
+    when the filename contains \ or a newline. Closes: #696384
+  * fsck: Still accept checksums with a leading \ as valid, now that
+    above bug is fixed.
+  * SHA*E backends: Exclude non-alphanumeric characters from extensions.
+  * migrate: Remove leading \ in SHA* checksums, and non-alphanumerics
+    from extensions of SHA*E keys.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 02 Jan 2013 13:21:34 -0400
+
+git-annex (3.20121211) unstable; urgency=low
+
+  * webapp: Defaults to sharing box.com account info with friends, allowing
+    one-click enabling of the repository.
+  * Fix broken .config/git-annex/program installed by standalone tarball.
+  * assistant: Retrival from glacier now handled.
+  * Include ssh in standalone tarball and OSX app.
+  * watch: Avoid leaving hard links to files behind in .git/annex/tmp
+    if a file is deleted or moved while it's being quarantined in preparation
+    to being added to the annex.
+  * Allow `git annex drop --from web`; of course this does not remove
+    any file from the web, but it does make git-annex remove all urls
+    associated with a file.
+  * webapp: S3 and Glacier forms now have a select list of all
+    currently-supported AWS regions.
+  * webdav: Avoid trying to set props, avoiding incompatibility with
+    livedrive.com. Needs DAV version 0.3.
+  * webapp: Prettify error display.
+  * webapp: Fix bad interaction between required fields and modals.
+  * webapp: Added help buttons and links next to fields that require
+    explanations.
+  * webapp: Encryption can be disabled when setting up remotes.
+  * assistant: Avoid trying to drop content from remotes that don't have it.
+  * assistant: Allow periods in ssh key comments.
+  * get/copy --auto: Transfer data even if it would exceed numcopies,
+    when preferred content settings want it.
+  * drop --auto: Fix dropping content when there are no preferred content
+    settings.
+  * webapp: Allow user to specify the port when setting up a ssh or rsync
+    remote.
+  * assistant: Fix syncing to just created ssh remotes.
+  * Enable WebDAV support in Debian package. Closes: #695532
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 11 Dec 2012 11:25:03 -0400
+
+git-annex (3.20121127) unstable; urgency=low
+
+  * Fix dirContentsRecursive, which had missed some files in deeply nested
+    subdirectories. Could affect various parts of git-annex.
+  * rsync: Fix bug introduced in last release that broke encrypted rsync
+    special remotes.
+  * The standalone builds now unset their special path and library path
+    variables before running the system web browser.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 27 Nov 2012 17:07:32 -0400
+
+git-annex (3.20121126) unstable; urgency=low
+
+  * New webdav and Amazon glacier special remotes.
+  * Display a warning when a non-existing file or directory is specified.
+  * webapp: Added configurator for Box.com.
+  * webapp: Show error messages to user when testing XMPP creds.
+  * Fix build of assistant without yesod.
+  * webapp: The list of repositiories refreshes when new repositories are
+    added, including when new repository configurations are pushed in from
+    remotes.
+  * OSX: Fix RunAtLoad value in plist file.
+  * Getting a file from chunked directory special remotes no longer buffers
+    it all in memory.
+  * S3: Added progress display for uploading and downloading.
+  * directory special remote: Made more efficient and robust.
+  * Bugfix: directory special remote could loop forever storing a key 
+    when a too small chunksize was configured.
+  * Allow controlling whether login credentials for S3 and webdav are
+    committed to the repository, by setting embedcreds=yes|no when running
+    initremote.
+  * Added smallarchive repository group, that only archives files that are
+    in archive directories. Used by default for glacier when set up in the
+    webapp.
+  * assistant: Fixed handling of toplevel archive directory and
+    client repository group.
+  * assistant: Apply preferred content settings when a new symlink
+    is created, or a symlink gets renamed. Made archive directories work.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 26 Nov 2012 11:37:49 -0400
+
+git-annex (3.20121112) unstable; urgency=low
+
+  * assistant: Can use XMPP to notify other nodes about pushes made to other
+    repositories, as well as pushing to them directly over XMPP.
+  * wepapp: Added an XMPP configuration interface.
+  * webapp: Supports pairing over XMPP, with both friends, and other repos
+    using the same account.
+  * assistant: Drops non-preferred content when possible.
+  * assistant: Notices, and applies config changes as they are made to
+    the git-annex branch, including config changes pushed in from remotes.
+  * git-annex-shell: GIT_ANNEX_SHELL_DIRECTORY can be set to limit it
+    to operating on a specified directory.
+  * webapp: When setting up authorized_keys, use GIT_ANNEX_SHELL_DIRECTORY.
+  * Preferred content path matching bugfix.
+  * Preferred content expressions cannot use "in=".
+  * Preferred content expressions can use "present".
+  * Fix handling of GIT_DIR when it refers to a git submodule.
+  * Depend on and use the Haskell SafeSemaphore library, which provides
+    exception-safe versions of SampleVar and QSemN.
+    Thanks, Ben Gamari for an excellent patch set.
+  * file:/// URLs can now be used with the web special remote.
+  * webapp: Allow dashes in ssh key comments when pairing.
+  * uninit: Check and abort if there are symlinks to annexed content that
+    are not checked into git.
+  * webapp: Switched to using the same multicast IP address that avahi uses.
+  * bup: Don't pass - to bup-split to make it read stdin; bup 0.25
+    does not accept that.
+  * bugfix: Don't fail transferring content from read-only repos.
+    Closes: #691341
+  * configure: Check that checksum programs produce correct checksums.
+  * Re-enable dbus, using a new version of the library that fixes the memory
+    leak.
+  * NetWatcher: When dbus connection is lost, try to reconnect.
+  * Use USER and HOME environment when set, and only fall back to getpwent,
+    which doesn't work with LDAP or NIS.
+  * rsync special remote: Include annex-rsync-options when running rsync
+    to test a key's presence.
+  * The standalone tarball's runshell now takes care of installing a
+    ~/.ssh/git-annex-shell wrapper the first time it's run.
+  * webapp: Make an initial, empty commit so there is a master branch 
+  * assistant: Fix syncing local drives.
+  * webapp: Fix creation of rsync.net repositories.
+  * webapp: Fix renaming of special remotes.
+  * webapp: Generate better git remote names.
+  * webapp: Ensure that rsync special remotes are enabled using the same
+    name they were originally created using.
+  * Bugfix: Fix hang in webapp when setting up a ssh remote with an absolute
+    path.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 12 Nov 2012 10:39:47 -0400
+
+git-annex (3.20121017) unstable; urgency=low
+
+  * Fix zombie cleanup reversion introduced in 3.20121009.
+  * Additional fix to support git submodules.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 16 Oct 2012 21:10:14 -0400
+
+git-annex (3.20121016) unstable; urgency=low
+
+  * vicfg: New file format, avoids ambiguity with repos that have the same
+    description, or no description.
+  * Bug fix: A recent change caused git-annex-shell to crash.
+  * Better preferred content expression for transfer repos.
+  * webapp: Repository edit form can now edit the name of a repository.
+  * webapp: Make bare repositories on removable drives, as there is nothing
+    to ensure non-bare repos get updated when syncing.
+  * webapp: Better behavior when pausing syncing to a remote when a transfer
+    scan is running and queueing new transfers for that remote.
+  * The standalone binaries are now built to not use ssh connection caching,
+    in order to work with old versions of ssh.
+  * A relative core.worktree is relative to the gitdir. Now that this is
+    handled correctly, git-annex can be used in git submodules.
+  * Temporarily disable use of dbus, as the haskell dbus library blows up
+    when losing connection, which will need to be fixed upstream. 
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 16 Oct 2012 15:25:22 -0400
+
+git-annex (3.20121010) unstable; urgency=low
+
+  * Renamed --ingroup to --inallgroup.
+  * Standard groups changed to client, transfer, archive, and backup.
+    Each of these has its own standard preferred content setting.
+  * dead: Remove dead repository from all groups.
+  * Avoid unsetting HOME when running certian git commands. Closes: #690193
+  * test: Fix threaded runtime hang.
+  * Makefile: Avoid building with -threaded if the ghc threaded runtime does
+    not exist.
+  * webapp: Improve wording of intro display. Closes: #689848
+  * webapp: Repositories can now be configured, to change their description,
+    their group, or even to disable syncing to them.
+  * git config remote.name.annex-sync can be used to control whether
+    a remote gets synced.
+  * Fix a crash when merging files in the git-annex branch that contain
+    invalid utf8.
+  * Automatically detect when a ssh remote does not have git-annex-shell
+    installed, and set annex-ignore.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 12 Oct 2012 13:45:21 -0400
+
+git-annex (3.20121009) unstable; urgency=low
+
+  * watch, assistant: It's now safe to git annex unlock files while
+    the watcher is running, as well as modify files checked into git
+    as normal files. Additionally, .gitignore settings are now honored.
+    Closes: #689979
+  * group, ungroup: New commands to indicate groups of repositories.
+  * webapp: Adds newly created repositories to one of these groups:
+    clients, drives, servers
+  * vicfg: New command, allows editing (or simply viewing) most
+    of the repository configuration settings stored in the git-annex branch.
+  * Added preferred content expressions, configurable using vicfg.
+  * get --auto: If the local repository has preferred content
+    configured, only get that content.
+  * drop --auto: If the repository the content is dropped from has
+    preferred content configured, drop only content that is not preferred.
+  * copy --auto: Only transfer content that the destination repository prefers.
+  * assistant: Now honors preferred content settings when deciding what to
+    transfer.
+  * --copies=group:number can now be used to match files that are present
+    in a specified number of repositories in a group.
+  * Added --smallerthan, --largerthan, and --inall limits.
+  * Only build-depend on libghc-clientsession-dev on arches that will have
+    the webapp.
+  * uninit: Unset annex.version. Closes: #689852
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 09 Oct 2012 15:13:23 -0400
+
+git-annex (3.20121001) unstable; urgency=low
+
+  * fsck: Now has an incremental mode. Start a new incremental fsck pass
+    with git annex fsck --incremental. Now the fsck can be interrupted
+    as desired, and resumed with git annex fsck --more.
+    Thanks, Justin Azoff
+  * New --time-limit option, makes long git-annex commands stop after
+    a specified amount of time.
+  * fsck: New --incremental-schedule option which is nice for scheduling
+    eg, monthly incremental fsck runs in cron jobs.
+  * Fix fallback to ~/Desktop when xdg-user-dir is not available.
+    Closes: #688833
+  * S3: When using a shared cipher, S3 credentials are not stored encrypted
+    in the git repository, as that would allow anyone with access to
+    the repository access to the S3 account. Instead, they're stored
+    in a 600 mode file in the local git repo.
+  * webapp: Avoid crashing when ssh-keygen -F chokes on an invalid known_hosts
+    file.
+  * Always do a system wide installation when DESTDIR is set. Closes: #689052
+  * The Makefile now builds with the new yesod by default.
+    Systems like Debian that have the old yesod 1.0.1 should set
+    GIT_ANNEX_LOCAL_FEATURES=-DWITH_OLD_YESOD
+  * copy: Avoid updating the location log when no copy is performed.
+  * configure: Test that uuid -m works, falling back to plain uuid if not.
+  * Avoid building the webapp on Debian architectures that do not yet
+    have template haskell and thus yesod. (Should be available for arm soonish
+    I hope).
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 01 Oct 2012 13:56:55 -0400
+
+git-annex (3.20120924) unstable; urgency=low
+
+  * assistant: New command, a daemon which does everything watch does,
+    as well as automatically syncing file contents between repositories.
+  * webapp: An interface for managing and configuring the assistant.
+  * The default backend used when adding files to the annex is changed
+    from SHA256 to SHA256E, to simplify interoperability with OSX, media
+    players, and various programs that needlessly look at symlink targets.
+    To get old behavior, add a .gitattributes containing: * annex.backend=SHA256
+  * init: If no description is provided for a new repository, one will
+    automatically be generated, like "joey@gnu:~/foo"
+  * test: Set a lot of git environment variables so testing works in strange
+    environments that normally need git config to set names, etc.
+    Closes: #682351 Thanks, gregor herrmann
+  * Disable ssh connection caching if the path to the control socket would be
+    too long (and use relative path to minimise path to the control socket).
+  * migrate: Check content before generating the new key, to avoid generating
+    a key for corrupt data.
+  * Support repositories created with --separate-git-dir. Closes: #684405
+  * reinject: When the provided file doesn't match, leave it where it is,
+    rather than moving to .git/annex/bad/
+  * Avoid crashing on encoding errors in filenames when writing transfer info
+    files and reading from checksum commands.
+  * sync: Pushes the git-annex branch to remote/synced/git-annex, rather
+    than directly to remote/git-annex.
+  * Now supports matching files that are present on a number of remotes
+    with a specified trust level. Example: --copies=trusted:2
+    Thanks, Nicolas Pouillard
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 24 Sep 2012 13:47:48 -0400
+
+git-annex (3.20120825) unstable; urgency=low
+
+  * S3: Add fileprefix setting.
+  * Pass --use-agent to gpg when in no tty mode. Thanks, Eskild Hustvedt.
+  * Bugfix: Fix fsck in SHA*E backends, when the key contains composite
+    extensions, as added in 3.20120721.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 25 Aug 2012 10:00:10 -0400
+
+git-annex (3.20120807) unstable; urgency=low
+
+  * initremote: Avoid recording remote's description before checking
+    that its config is valid.
+  * unused, status: Avoid crashing when ran in bare repo.
+  * Avoid crashing when "git annex get" fails to download from one
+    location, and falls back to downloading from a second location.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 07 Aug 2012 13:35:07 -0400
+
+git-annex (3.20120721) unstable; urgency=low
+
+  * get, move, copy: Now refuse to do anything when the requested file
+    transfer is already in progress by another process.
+  * status: Lists transfers that are currently in progress.
+  * Fix passing --uuid to git-annex-shell.
+  * When shaNsum commands cannot be found, use the Haskell SHA library
+    (already a dependency) to do the checksumming. This may be slower,
+    but avoids portability problems.
+  * Use SHA library for files less than 50 kb in size, at which point it's
+    faster than forking the more optimised external program.
+  * SHAnE backends are now smarter about composite extensions, such as
+    .tar.gz Closes: #680450
+  * map: Write map.dot to .git/annex, which avoids watch trying to annex it.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 21 Jul 2012 16:52:48 -0400
+
+git-annex (3.20120629) unstable; urgency=low
+
+  * cabal: Only try to use inotify on Linux.
+  * Version build dependency on STM, and allow building without it,
+    which disables the watch command.
+  * Avoid ugly failure mode when moving content from a local repository
+    that is not available.
+  * Got rid of the last place that did utf8 decoding.
+  * Accept arbitrarily encoded repository filepaths etc when reading
+    git config output. This fixes support for remotes with unusual characters
+    in their names.
+  * sync: Automatically resolves merge conflicts.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 29 Jun 2012 10:17:49 -0400
+
+git-annex (3.20120624) unstable; urgency=low
+
+  * watch: New subcommand, a daemon which notices changes to
+    files and automatically annexes new files, etc, so you don't
+    need to manually run git commands when manipulating files.
+    Available on Linux, BSDs, and OSX!
+  * Enable diskfree on kfreebsd, using kqueue.
+  * unused: Fix crash when key names contain invalid utf8.
+  * sync: Avoid recent git's interactive merge.
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 24 Jun 2012 12:36:50 -0400
+
+git-annex (3.20120614) unstable; urgency=medium
+
+  * addurl: Was broken by a typo introduced 2 released ago, now fixed.
+    Closes: #677576
+  * Install man page when run by cabal, in a location where man will
+    find it, even when installing under $HOME. Thanks, Nathan Collins
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 14 Jun 2012 20:21:29 -0400
+
+git-annex (3.20120611) unstable; urgency=medium
+
+  * add: Prevent (most) modifications from being made to a file while it
+    is being added to the annex.
+  * initremote: Automatically describe a remote when creating it.
+  * uninit: Refuse to run in a subdirectory. Closes: #677076
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 11 Jun 2012 10:32:01 -0400
+
+git-annex (3.20120605) unstable; urgency=low
+
+  * sync: Show a nicer message if a user tries to sync to a special remote.
+  * lock: Reset unlocked file to index, rather than to branch head.
+  * import: New subcommand, pulls files from a directory outside the annex
+    and adds them.
+  * Fix display of warning message when encountering a file that uses an
+    unsupported backend.
+  * Require that the SHA256 backend can be used when building, since it's the
+    default.
+  * Preserve parent environment when running hooks of the hook special remote.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 05 Jun 2012 14:03:39 -0400
+
+git-annex (3.20120522) unstable; urgency=low
+
+  * Pass -a to cp even when it supports --reflink=auto, to preserve
+    permissions.
+  * Clean up handling of git directory and git worktree.
+  * Add support for core.worktree, and fix support for GIT_WORK_TREE and
+    GIT_DIR.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 22 May 2012 11:16:13 -0400
+
+git-annex (3.20120511) unstable; urgency=low
+
+  * Rsync special remotes can be configured with shellescape=no
+    to avoid shell quoting that is normally done when using rsync over ssh.
+    This is known to be needed for certian rsync hosting providers
+    (specificially hidrive.strato.com) that use rsync over ssh but do not
+    pass it through the shell.
+  * dropunused: Allow specifying ranges to drop.
+  * addunused: New command, the opposite of dropunused, it relinks unused
+    content into the git repository.
+  * Fix use of several config settings: annex.ssh-options,
+    annex.rsync-options, annex.bup-split-options. (And adjust types to avoid
+    the bugs that broke several config settings.)
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 11 May 2012 12:29:30 -0400
+
+git-annex (3.20120430) unstable; urgency=low
+
+  * Fix use of annex.diskreserve config setting.
+  * Directory special remotes now check annex.diskreserve.
+  * Support git's core.sharedRepository configuration.
+  * Add annex.http-headers and annex.http-headers-command config
+    settings, to allow custom headers to be sent with all HTTP requests.
+    (Requested by the Internet Archive)
+  * uninit: Clear annex.uuid from .git/config. Closes: #670639
+  * Added shared cipher mode to encryptable special remotes. This option
+    avoids gpg key distribution, at the expense of flexibility, and with
+    the requirement that all clones of the git repository be equally trusted.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 30 Apr 2012 13:16:10 -0400
+
+git-annex (3.20120418) unstable; urgency=low
+
+  * bugfix: Adding a dotfile also caused all non-dotfiles to be added.
+  * bup: Properly handle key names with spaces or other things that are
+    not legal git refs.
+  * git-annex (but not git-annex-shell) supports the git help.autocorrect
+    configuration setting, doing fuzzy matching using the restricted
+    Damerau-Levenshtein edit distance, just as git does. This adds a build
+    dependency on the haskell edit-distance library.
+  * Renamed diskfree.c to avoid OSX case insensativity bug.
+  * cabal now installs git-annex-shell as a symlink to git-annex.
+  * cabal file now autodetects whether S3 support is available.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 18 Apr 2012 12:11:32 -0400
+
+git-annex (3.20120406) unstable; urgency=low
+
+  * Disable diskfree on kfreebsd, as I have a build failure on kfreebsd-i386
+    that is quite likely caused by it.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 07 Apr 2012 15:50:36 -0400
+
+git-annex (3.20120405) unstable; urgency=low
+
+  * Rewrote free disk space checking code, moving the portability
+    handling into a small C library.
+  * status: Display amount of free disk space.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 05 Apr 2012 16:19:10 -0400
+
+git-annex (3.20120315) unstable; urgency=low
+
+  * fsck: Fix up any broken links and misplaced content caused by the
+    directory hash calculation bug fixed in the last release.
+  * sync: Sync to lower cost remotes first.
+  * status: Fixed to run in constant space.
+  * status: More accurate display of sizes of tmp and bad keys.
+  * unused: Now uses a bloom filter, and runs in constant space.
+    Use of a bloom filter does mean it will not notice a small
+    number of unused keys. For repos with up to half a million keys,
+    it will miss one key in 1000.
+  * Added annex.bloomcapacity and annex.bloomaccuracy, which can be
+    adjusted as desired to tune the bloom filter.
+  * status: Display amount of memory used by bloom filter, and
+    detect when it's too small for the number of keys in a repository.
+  * git-annex-shell: Runs hooks/annex-content after content is received
+    or dropped.
+  * Work around a bug in rsync (IMHO) introduced by openSUSE's SIP patch.
+  * git-annex now behaves as git-annex-shell if symlinked to and run by that
+    name. The Makefile sets this up, saving some 8 mb of installed size.
+  * git-union-merge is a demo program, so it is no longer built by default.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 15 Mar 2012 11:05:28 -0400
+
+git-annex (3.20120309) unstable; urgency=low
+
+  * Fix key directory hash calculation code to behave as it did before 
+    version 3.20120227 when a key contains non-ascii characters (only
+    WORM backend is likely to have been affected).
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 09 Mar 2012 20:05:09 -0400
+
+git-annex (3.20120230) unstable; urgency=low
+
+  * "here" can be used to refer to the current repository,
+    which can read better than the old "." (which still works too).
+  * Directory special remotes now support chunking files written to them,
+    avoiding writing files larger than a specified size.
+  * Add progress bar display to the directory special remote.
+  * Add configurable hooks that are run when git-annex starts and stops
+    using a remote: remote.name.annex-start-command and
+    remote.name.annex-stop-command
+  * Fix a bug in symlink calculation code, that triggered in rare
+    cases where an annexed file is in a subdirectory that nearly
+    matched to the .git/annex/object/xx/yy subdirectories.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 05 Mar 2012 13:38:13 -0400
+
+git-annex (3.20120229) unstable; urgency=low
+
+  * Fix test suite to not require a unicode locale.
+  * Fix cabal build failure. Thanks, Sergei Trofimovich
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 29 Feb 2012 02:31:31 -0400
+
+git-annex (3.20120227) unstable; urgency=low
+
+  * Modifications to support ghc 7.4's handling of filenames.
+    This version can only be built with ghc 7.4 or newer. See the ghc7.0
+    branch for older ghcs.
+  * S3: Fix irrefutable pattern failure when accessing encrypted S3
+    credentials.
+  * Use the haskell IfElse library.
+  * Fix teardown of stale cached ssh connections.
+  * Fixed to use the strict state monad, to avoid leaking all kinds of memory
+    due to lazy state update thunks when adding/fixing many files.
+  * Fixed some memory leaks that occurred when committing journal files.
+  * Added a annex.queuesize setting, useful when adding hundreds of thousands
+    of files on a system with plenty of memory.
+  * whereis: Prints the urls of files that the web special remote knows about.
+  * addurl --fast: Verifies that the url can be downloaded (only getting
+    its head), and records the size in the key.
+  * When checking that an url has a key, verify that the Content-Length,
+    if available, matches the size of the key.
+  * addurl: Added a --file option, which can be used to specify what
+    file the url is added to. This can be used to override the default
+    filename that is used when adding an url, which is based on the url.
+    Or, when the file already exists, the url is recorded as another
+    location of the file.
+  * addurl: Normalize badly encoded urls.
+  * addurl: Add --pathdepth option.
+  * rekey: New plumbing level command, can be used to change the keys used
+    for files en masse.
+  * Store web special remote url info in a more efficient location.
+    (Urls stored with this version will not be visible to older versions.)
+  * Deal with NFS problem that caused a failure to remove a directory
+    when removing content from the annex.
+  * Make a single location log commit after a remote has received or
+    dropped files. Uses a new "git-annex-shell commit" command when available.
+  * To avoid commits of data to the git-annex branch after each command
+    is run, set annex.alwayscommit=false. Its data will then be committed
+    less frequently, when a merge or sync is done.
+  * configure: Check if ssh connection caching is supported by the installed
+    version of ssh and default annex.sshcaching accordingly.
+  * move --from, copy --from: Now 10 times faster when scanning to find
+    files in a remote on a local disk; rather than go through the location log
+    to see which files are present on the remote, it simply looks at the 
+    disk contents directly.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 27 Feb 2012 12:58:21 -0400
+
+git-annex (3.20120123) unstable; urgency=low
+
+  * fsck --from: Fscking a remote is now supported. It's done by retrieving
+    the contents of the specified files from the remote, and checking them,
+    so can be an expensive operation. Still, if the remote is a special
+    remote, or a git repository that you cannot run fsck in locally, it's
+    nice to have the ability to fsck it.
+  * If you have any directory special remotes, now would be a good time to
+    fsck them, in case you were hit by the data loss bug fixed in the
+    previous release!
+  * fsck --from remote --fast: Avoids expensive file transfers, at the
+    expense of not checking file size and/or contents.
+  * Ssh connection caching is now enabled automatically by git-annex.
+    Only one ssh connection is made to each host per git-annex run, which
+    can speed some things up a lot, as well as avoiding repeated password
+    prompts. Concurrent git-annex processes also share ssh connections.
+    Cached ssh connections are shut down when git-annex exits.
+  * To disable the ssh caching (if for example you have your own broader
+    ssh caching configuration), set annex.sshcaching=false.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 23 Jan 2012 13:48:48 -0400
+
+git-annex (3.20120116) unstable; urgency=medium
+
+  * Fix data loss bug in directory special remote, when moving a file
+    to the remote failed, and partially transferred content was left
+    behind in the directory, re-running the same move would think it
+    succeeded and delete the local copy.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 16 Jan 2012 16:43:45 -0400
+
+git-annex (3.20120115) unstable; urgency=low
+
+  * Add a sanity check for bad StatFS results. On architectures
+    where StatFS does not currently work (s390, mips, powerpc, sparc),
+    this disables the diskreserve checking code, and attempting to
+    configure an annex.diskreserve will result in an error.
+  * Fix QuickCheck dependency in cabal file.
+  * Minor optimisations.
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 15 Jan 2012 13:54:20 -0400
+
+git-annex (3.20120113) unstable; urgency=low
+
+  * log: Add --gource mode, which generates output usable by gource.
+  * map: Fix display of remote repos
+  * Add annex-trustlevel configuration settings, which can be used to 
+    override the trust level of a remote.
+  * git-annex, git-union-merge: Support GIT_DIR and GIT_WORK_TREE.
+  * Add libghc-testpack-dev to build depends on all arches.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 13 Jan 2012 15:35:17 -0400
+
+git-annex (3.20120106) unstable; urgency=low
+
+  * Support unescaped repository urls, like git does.
+  * log: New command that displays the location log for files,
+    showing each repository they were added to and removed from.
+  * Fix overbroad gpg --no-tty fix from last release.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 07 Jan 2012 13:16:23 -0400
+
+git-annex (3.20120105) unstable; urgency=low
+
+  * Added annex-web-options configuration settings, which can be
+    used to provide parameters to whichever of wget or curl git-annex uses
+    (depends on which is available, but most of their important options
+    suitable for use here are the same).
+  * Dotfiles, and files inside dotdirs are not added by "git annex add"
+    unless the dotfile or directory is explicitly listed. So "git annex add ."
+    will add all untracked files in the current directory except for those in
+    dotdirs.
+  * Added quickcheck to build dependencies, and fail if test suite cannot be
+    built.
+  * fsck: Do backend-specific check before checking numcopies is satisfied.
+  * Run gpg with --no-tty. Closes: #654721
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 05 Jan 2012 13:44:12 -0400
+
+git-annex (3.20111231) unstable; urgency=low
+
+  * sync: Improved to work well without a central bare repository.
+    Thanks to Joachim Breitner.
+  * Rather than manually committing, pushing, pulling, merging, and git annex
+    merging, we encourage you to give "git annex sync" a try.
+  * sync --fast: Selects some of the remotes with the lowest annex.cost
+    and syncs those, in addition to any specified at the command line.
+  * Union merge now finds the least expensive way to represent the merge.
+  * reinject: Add a sanity check for using an annexed file as the source file.
+  * Properly handle multiline git config values.
+  * Fix the hook special remote, which bitrotted a while ago.
+  * map: --fast disables use of dot to display map
+  * Test suite improvements. Current top-level test coverage: 75%
+  * Improve deletion of files from rsync special remotes. Closes: #652849
+  * Add --include, which is the same as --not --exclude.
+  * Format strings can be specified using the new --format option, to control
+    what is output by git annex find.
+  * Support git annex find --json
+  * Fixed behavior when multiple insteadOf configs are provided for the
+    same url base.
+  * Can now be built with older git versions (before 1.7.7); the resulting
+    binary should only be used with old git.
+  * Updated to build with monad-control 0.3.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 31 Dec 2011 14:55:29 -0400
+
+git-annex (3.20111211) unstable; urgency=medium
+
+  * Fix bug in last version in getting contents from bare repositories.
+  * Ensure that git-annex branch changes are merged into git-annex's index,
+    which fixes a bug that could cause changes that were pushed to the
+    git-annex branch to get reverted. As a side effect, it's now safe
+    for users to check out and commit changes directly to the git-annex
+    branch.
+  * map: Fix a failure to detect a loop when both repositories are local
+    and refer to each other with relative paths.
+  * Prevent key names from containing newlines.
+  * add: If interrupted, add can leave files converted to symlinks but not
+    yet added to git. Running the add again will now clean up this situtation.
+  * Fix caching of decrypted ciphers, which failed when drop had to check
+    multiple different encrypted special remotes.
+  * unannex: Can be run on files that have been added to the annex, but not
+    yet committed.
+  * sync: New command that synchronises the local repository and default
+    remote, by running git commit, pull, and push for you.
+  * Version monad-control dependency in cabal file.
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 11 Dec 2011 21:24:39 -0400
+
+git-annex (3.20111203) unstable; urgency=low
+
+  * The VFAT filesystem on recent versions of Linux, when mounted with
+    shortname=mixed, does not get along well with git-annex's mixed case
+    .git/annex/objects hash directories. To avoid this problem, new content
+    is now stored in all-lowercase hash directories. Except for non-bare
+    repositories which would be a pain to transition and cannot be put on FAT.
+    (Old mixed-case hash directories are still tried for backwards
+    compatibility.)
+  * Flush json output, avoiding a buffering problem that could result in
+    doubled output.
+  * Avoid needing haskell98 and other fixes for new ghc. Thanks, Mark Wright.
+  * Bugfix: dropunused did not drop keys with two spaces in their name.
+  * Support for storing .git/annex on a different device than the rest of the
+    git repository.
+  * --inbackend can be used to make git-annex only operate on files
+    whose content is stored using a specified key-value backend.
+  * dead: A command which says that a repository is gone for good
+    and you don't want git-annex to mention it again.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 03 Dec 2011 21:01:45 -0400
+
+git-annex (3.20111122) unstable; urgency=low
+
+  * merge: Improve commit messages to mention what was merged.
+  * Avoid doing auto-merging in commands that don't need fully current
+    information from the git-annex branch. In particular, git annex add
+    no longer needs to auto-merge.
+  * init: When run in an already initalized repository, and without
+    a description specified, don't delete the old description. 
+  * Optimised union merging; now only runs git cat-file once, and runs
+    in constant space.
+  * status: Now displays trusted, untrusted, and semitrusted repositories
+    separately.
+  * status: Include all special remotes in the list of repositories.
+  * status: Fix --json mode.
+  * status: --fast is back
+  * Fix support for insteadOf url remapping. Closes: #644278
+  * When not run in a git repository, git-annex can still display a usage
+    message, and "git annex version" even works.
+  * migrate: Don't fall over a stale temp file.
+  * Avoid excessive escaping for rsync special remotes that are not accessed
+    over ssh.
+  * find: Support --print0
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 22 Nov 2011 14:31:45 -0400
+
+git-annex (3.20111111) unstable; urgency=low
+
+  * Handle a case where an annexed file is moved into a gitignored directory,
+    by having fix --force add its change.
+  * Avoid cyclic drop problems.
+  * Optimized copy --from and get --from to avoid checking the location log
+    for files that are already present.
+  * Automatically fix up badly formatted uuid.log entries produced by
+    3.20111105, whenever the uuid.log is changed (ie, by init or describe).
+  * map: Support remotes with /~/ and /~user/
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 11 Nov 2011 13:44:18 -0400
+
+git-annex (3.20111107) unstable; urgency=low
+
+  * merge: Use fast-forward merges when possible.
+    Thanks Valentin Haenel for a test case showing how non-fast-forward
+    merges could result in an ongoing pull/merge/push cycle.
+  * Don't try to read config from repos with annex-ignore set.
+  * Bugfix: In the past two releases, git-annex init has written the uuid.log
+    in the wrong format, with the UUID and description flipped.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 07 Nov 2011 12:47:44 -0400
+
+git-annex (3.20111105) unstable; urgency=low
+
+  * The default backend used when adding files to the annex is changed
+    from WORM to SHA256.
+    To get old behavior, add a .gitattributes containing: * annex.backend=WORM
+  * Sped up some operations on remotes that are on the same host.
+  * copy --to: Fixed leak when copying many files to a remote on the same
+    host.
+  * uninit: Add guard against being run with the git-annex branch checked out.
+  * Fail if --from or --to is passed to commands that do not support them.
+  * drop --from is now supported to remove file content from a remote.
+  * status: Now always shows the current repository, even when it does not
+    appear in uuid.log.
+  * fsck: Now works in bare repositories. Checks location log information,
+    and file contents. Does not check that numcopies is satisfied, as
+    .gitattributes information about numcopies is not available in a bare
+    repository.
+  * unused, dropunused: Now work in bare repositories.
+  * Removed the setkey command, and added a reinject command with a more
+    useful interface.
+  * The fromkey command now takes the key as its first parameter. The --key
+    option is no longer used.
+  * Built without any filename containing .git being excluded. Closes: #647215
+  * Record uuid when auto-initializing a remote so it shows in status.
+  * Bugfix: Fixed git-annex init crash in a bare repository when there was
+    already an existing git-annex branch.
+  * Pass -t to rsync to preserve timestamps.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 05 Nov 2011 15:47:52 -0400
+
+git-annex (3.20111025) unstable; urgency=low
+
+  * A remote can have a annexUrl configured, that is used by git-annex
+    instead of its usual url. (Similar to pushUrl.)
+  * migrate: Copy url logs for keys when migrating.
+  * git-annex-shell: GIT_ANNEX_SHELL_READONLY and GIT_ANNEX_SHELL_LIMITED
+    environment variables can be set to limit what commands can be run.
+    This is used by gitolite's new git-annex support!
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 25 Oct 2011 13:03:08 -0700
+
+git-annex (3.20111011) unstable; urgency=low
+
+  * This version of git-annex only works with git 1.7.7 and newer.
+    The breakage with old versions is subtle, and affects the
+    annex.numcopies settings in .gitattributes, so be sure to upgrade git
+    to 1.7.7. (Debian package now depends on that version.)
+  * Don't pass absolute paths to git show-attr, as it started following
+    symlinks when that's done in 1.7.7. Instead, use relative paths,
+    which show-attr only handles 100% correctly in 1.7.7. Closes: #645046
+  * Fix referring to remotes by uuid.
+  * New or changed repository descriptions in uuid.log now have a timestamp,
+    which is used to ensure the newest description is used when the uuid.log
+    has been merged.
+  * Note that older versions of git-annex will display the timestamp as part
+    of the repository description, which is ugly but otherwise harmless.
+  * Add timestamps to trust.log and remote.log too.
+  * git-annex-shell: Added the --uuid option.
+  * git-annex now asks git-annex-shell to verify that it's operating in 
+    the expected repository.
+  * Note that this git-annex will not interoperate with remotes using 
+    older versions of git-annex-shell.
+  * Now supports git's insteadOf configuration, to modify the url
+    used to access a remote. Note that pushInsteadOf is not used;
+    that and pushurl are reserved for actual git pushes. Closes: #644278
+  * status: List all known repositories.
+  * When displaying a list of repositories, show git remote names
+    in addition to their descriptions.
+  * Add locking to avoid races when changing the git-annex branch.
+  * Various speed improvements gained by using ByteStrings.
+  * Contain the zombie hordes.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 11 Oct 2011 23:00:02 -0400
+
+git-annex (3.20110928) unstable; urgency=low
+
+  * --in can be used to make git-annex only operate on files
+    believed to be present in a given repository.
+  * Arbitrarily complex expressions can be built to limit the files git-annex
+    operates on, by combining the options --not --and --or -( and -)
+    Example: git annex get --exclude '*.mp3' --and --not -( --in usbdrive --or --in archive -)
+  * --copies=N can be used to make git-annex only operate on files with
+    the specified number of copies. (And --not --copies=N for the inverse.)
+  * find: Rather than only showing files whose contents are present,
+    when used with --exclude --copies or --in, displays all files that
+    match the specified conditions.
+  * Note that this is a behavior change for git-annex find! Old behavior
+    can be gotten by using: git-annex find --in .
+  * status: Massively sped up; remove --fast mode.
+  * unused: File contents used by branches and tags are no longer
+    considered unused, even when not used by the current branch. This is
+    the final piece of the puzzle needed for git-annex to to play nicely
+    with branches.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 28 Sep 2011 18:14:02 -0400
+
+git-annex (3.20110915) unstable; urgency=low
+
+  * whereis: Show untrusted locations separately and do not include in
+    location count.
+  * Fix build without S3.
+  * addurl: Always use whole url as destination filename, rather than
+    only its file component.
+  * get, drop, copy: Added --auto option, which decides whether
+    to get/drop content as needed to work toward the configured numcopies.
+  * bugfix: drop and fsck did not honor --exclude
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 15 Sep 2011 22:25:46 -0400
+
+git-annex (3.20110906) unstable; urgency=low
+
+  * Improve display of newlines around error and warning messages.
+  * Fix Makefile to work with cabal again.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 06 Sep 2011 13:45:16 -0400
+
+git-annex (3.20110902) unstable; urgency=low
+
+  * Set EMAIL when running test suite so that git does not need to be
+    configured first. Closes: #638998
+  * The wget command will now be used in preference to curl, if available.
+  * init: Make description an optional parameter.
+  * unused, status: Sped up by avoiding unnecessary stats of annexed files.
+  * unused --remote: Reduced memory use to 1/4th what was used before.
+  * Add --json switch, to produce machine-consumable output.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 02 Sep 2011 21:20:37 -0400
+
+git-annex (3.20110819) unstable; urgency=low
+
+  * Now "git annex init" only has to be run once, when a git repository
+    is first being created. Clones will automatically notice that git-annex
+    is in use and automatically perform a basic initalization. It's
+    still recommended to run "git annex init" in any clones, to describe them.
+  * Added annex-cost-command configuration, which can be used to vary the
+    cost of a remote based on the output of a shell command.
+  * Fix broken upgrade from V1 repository. Closes: #638584
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 19 Aug 2011 20:34:09 -0400
+
+git-annex (3.20110817) unstable; urgency=low
+
+  * Fix shell escaping in rsync special remote.
+  * addurl: --fast can be used to avoid immediately downloading the url.
+  * Added support for getting content from git remotes using http (and https).
+  * Added curl to Debian package dependencies.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 17 Aug 2011 01:29:02 -0400
+
+git-annex (3.20110719) unstable; urgency=low
+
+  * add: Be even more robust to avoid ever leaving the file seemingly deleted.
+    Closes: #634233
+  * Bugfix: Make add ../ work.
+  * Support the standard git -c name=value
+  * unannex: Clean up use of git commit -a.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 19 Jul 2011 23:39:53 -0400
+
+git-annex (3.20110707) unstable; urgency=low
+
+  * Fix sign bug in disk free space checking.
+  * Bugfix: Forgot to de-escape keys when upgrading. Could result in
+    bad location log data for keys that contain [&:%] in their names.
+    (A workaround for this problem is to run git annex fsck.)
+  * add: Avoid a failure mode that resulted in the file seemingly being
+    deleted (content put in the annex but no symlink present).
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 07 Jul 2011 19:29:39 -0400
+
+git-annex (3.20110705) unstable; urgency=low
+
+  * uninit: Delete the git-annex branch and .git/annex/
+  * unannex: In --fast mode, file content is left in the annex, and a
+    hard link made to it.
+  * uninit: Use unannex in --fast mode, to support unannexing multiple
+    files that link to the same content.
+  * Drop the dependency on the haskell curl bindings, use regular haskell HTTP.
+  * Fix a pipeline stall when upgrading (caused by #624389).
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 05 Jul 2011 14:37:39 -0400
+
+git-annex (3.20110702) unstable; urgency=low
+
+  * Now the web can be used as a special remote. 
+    This feature replaces the old URL backend.
+  * addurl: New command to download an url and store it in the annex.
+  * Sped back up fsck, copy --from, and other commands that often
+    have to read a lot of information from the git-annex branch. Such
+    commands are now faster than they were before introduction of the
+    git-annex branch.
+  * Always ensure git-annex branch exists.
+  * Modify location log parser to allow future expansion.
+  * --force will cause add, etc, to operate on ignored files.
+  * Avoid mangling encoding when storing the description of repository
+    and other content.
+  * cabal can now be used to build git-annex. This is substantially
+    slower than using make, does not build or install documentation,
+    does not run the test suite, and is not particularly recommended,
+    but could be useful to some.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 02 Jul 2011 15:00:18 -0400
+
+git-annex (3.20110624) experimental; urgency=low
+
+  * New repository format, annex.version=3. Use `git annex upgrade` to migrate.
+  * git-annex now stores its logs in a git-annex branch.
+  * merge: New subcommand. Auto-merges the new git-annex branch.
+  * Improved handling of bare git repos with annexes. Many more commands will
+    work in them.
+  * git-annex is now more robust; it will never leave state files
+    uncommitted when some other git process comes along and locks the index
+    at an inconvenient time.
+  * rsync is now used when copying files from repos on other filesystems.
+    cp is still used when copying file from repos on the same filesystem,
+    since --reflink=auto can make it significantly faster on filesystems
+    such as btrfs.
+  * Allow --trust etc to specify a repository by name, for temporarily 
+    trusting repositories that are not configured remotes.
+  * unlock: Made atomic.
+  * git-union-merge: New git subcommand, that does a generic union merge
+    operation, and operates efficiently without touching the working tree.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 24 Jun 2011 14:32:18 -0400
+
+git-annex (0.20110610) unstable; urgency=low
+
+  * Add --numcopies option.
+  * Add --trust, --untrust, and --semitrust options.
+  * get --from is the same as copy --from
+  * Bugfix: Fix fsck to not think all SHAnE keys are bad.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 10 Jun 2011 11:48:40 -0400
+
+git-annex (0.20110601) unstable; urgency=low
+
+  * Minor bugfixes and error message improvements.
+  * Massively sped up `git annex lock` by avoiding use of the uber-slow
+    `git reset`, and only running `git checkout` once, even when many files
+    are being locked.
+  * Fix locking of files with staged changes.
+  * Somewhat sped up `git commit` of modifications to unlocked files.
+  * Build fix for older ghc.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 01 Jun 2011 11:50:47 -0400
+
+git-annex (0.20110522) unstable; urgency=low
+
+  * Closer emulation of git's behavior when told to use "foo/.git" as a
+    git repository instead of just "foo". Closes: #627563
+  * Fix bug in --exclude introduced in 0.20110516.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 27 May 2011 20:20:41 -0400
+
+git-annex (0.20110521) unstable; urgency=low
+
+  * status: New subcommand to show info about an annex, including its size.
+  * --backend now overrides any backend configured in .gitattributes files.
+  * Add --debug option. Closes: #627499
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 21 May 2011 11:52:53 -0400
+
+git-annex (0.20110516) unstable; urgency=low
+
+  * Add a few tweaks to make it easy to use the Internet Archive's variant
+    of S3. In particular, munge key filenames to comply with the IA's filename
+    limits, disable encryption, support their nonstandard way of creating
+    buckets, and allow x-archive-* headers to be specified in initremote to
+    set item metadata.
+  * Added filename extension preserving variant backends SHA1E, SHA256E, etc.
+  * migrate: Use current filename when generating new key, for backends
+    where the filename affects the key name.
+  * Work around a bug in Network.URI's handling of bracketed ipv6 addresses.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 16 May 2011 14:16:52 -0400
+
+git-annex (0.20110503) unstable; urgency=low
+
+  * Fix hasKeyCheap setting for bup and rsync special remotes.
+  * Add hook special remotes.
+  * Avoid crashing when an existing key is readded to the annex.
+  * unused: Now also lists files fsck places in .git/annex/bad/
+  * S3: When encryption is enabled, the Amazon S3 login credentials
+    are stored, encrypted, in .git-annex/remotes.log, so environment
+    variables need not be set after the remote is initialized.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 03 May 2011 20:56:01 -0400
+
+git-annex (0.20110427) unstable; urgency=low
+
+  * Switch back to haskell SHA library, so git-annex remains buildable on
+    Debian stable.
+  * Added rsync special remotes. This could be used, for example, to 
+    store annexed content on rsync.net (encrypted naturally). Or anywhere else.
+  * Bugfix: Avoid pipeline stall when running git annex drop or fsck on a
+    lot of files. Possibly only occured with ghc 7.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 27 Apr 2011 22:50:26 -0400
+
+git-annex (0.20110425) unstable; urgency=low
+
+  * Use haskell Crypto library instead of haskell SHA library.
+  * Remove testpack from build depends for non x86 architectures where it
+    is not available. The test suite will not be run if it cannot be compiled.
+  * Avoid using absolute paths when staging location log, as that can
+    confuse git when a remote's path contains a symlink. Closes: #621386
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 25 Apr 2011 15:47:00 -0400
+
+git-annex (0.20110420) unstable; urgency=low
+
+  * Update Debian build dependencies for ghc 7.
+  * Debian package is now built with S3 support.
+    Thanks Joachim Breitner for making this possible.
+  * Somewhat improved memory usage of S3, still work to do.
+    Thanks Greg Heartsfield for ongoing work to improve the hS3 library
+    for git-annex.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 21 Apr 2011 15:00:48 -0400
+
+git-annex (0.20110419) unstable; urgency=low
+
+  * Don't run gpg in batch mode, so it can prompt for passphrase when
+    there is no agent.
+  * Add missing build dep on dataenc.
+  * S3: Fix stalls when transferring encrypted data.
+  * bup: Avoid memory leak when transferring encrypted data.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 19 Apr 2011 21:26:51 -0400
+
+git-annex (0.20110417) unstable; urgency=low
+
+  * bup is now supported as a special type of remote.
+  * The data sent to special remotes (Amazon S3, bup, etc) can be encrypted
+    using GPG for privacy.
+  * Use lowercase hash directories for locationlog files, to avoid
+    some issues with git on OSX with the mixed-case directories.
+    No migration is needed; the old mixed case hash directories are still
+    read; new information is written to the new directories.
+  * Unused files on remotes, particulary special remotes, can now be
+    identified and dropped, by using "--from remote" with git annex unused
+    and git annex dropunused.
+  * Clear up short option confusion between --from and --force (-f is now
+    --from, and there is no short option for --force).
+  * Add build depend on perlmagick so docs are consistently built.
+    Closes: #621410
+  * Add doc-base file. Closes: #621408
+  * Periodically flush git command queue, to avoid boating memory usage
+    too much.
+  * Support "sha1" and "sha512" commands on FreeBSD, and allow building
+    if any/all SHA commands are not available. Thanks, Fraser Tweedale
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 17 Apr 2011 12:00:24 -0400
+
+git-annex (0.20110401) experimental; urgency=low
+
+  * Amazon S3 is now supported as a special type of remote.
+    Warning: Encrypting data before sending it to S3 is not yet supported.
+  * Note that Amazon S3 support is not built in by default on Debian yet,
+    as hS3 is not packaged.
+  * fsck: Ensure that files and directories in .git/annex/objects
+    have proper permissions.
+  * Added a special type of remote called a directory remote, which
+    simply stores files in an arbitrary local directory.
+  * Bugfix: copy --to --fast never really copied, fixed.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 01 Apr 2011 21:27:22 -0400
+
+git-annex (0.20110328) experimental; urgency=low
+
+  * annex.diskreserve can be given in arbitrary units (ie "0.5 gigabytes")
+  * Generalized remotes handling, laying groundwork for remotes that are
+    not regular git remotes. (Think Amazon S3.)
+  * Provide a less expensive version of `git annex copy --to`, enabled
+    via --fast. This assumes that location tracking information is correct,
+    rather than contacting the remote for every file.
+  * Bugfix: Keys could be received into v1 annexes from v2 annexes, via
+    v1 git-annex-shell. This results in some oddly named keys in the v1
+    annex. Recognise and fix those keys when upgrading, instead of crashing.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 28 Mar 2011 10:47:29 -0400
+
+git-annex (0.20110325) experimental; urgency=low
+
+  * Free space checking is now done, for transfers of data for keys
+    that have free space metadata. (Notably, not for SHA* keys generated
+    with git-annex 0.2x or earlier.) The code is believed to work on
+    Linux, FreeBSD, and OSX; check compile-time messages to see if it
+    is not enabled for your OS.
+  * Add annex.diskreserve config setting, to control how much free space
+    to reserve for other purposes and avoid using (defaults to 1 mb).
+  * Add --fast flag, that can enable less expensive, but also less thorough
+    versions of some commands.
+  * fsck: In fast mode, avoid checking checksums.
+  * unused: In fast mode, just show all existing temp files as unused,
+    and avoid expensive scan for other unused content.
+  * migrate: Support migrating v1 SHA keys to v2 SHA keys with
+    size information that can be used for free space checking.
+  * Fix space leak in fsck and drop commands.
+  * migrate: Bugfix for case when migrating a file results in a key that
+    is already present in .git/annex/objects.
+  * dropunused: Significantly sped up; only read unused log file once.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 25 Mar 2011 00:47:37 -0400
+
+git-annex (0.20110320) experimental; urgency=low
+
+  * Fix dropping of files using the URL backend.
+  * Fix support for remotes with '.' in their names.
+  * Add version command to show git-annex version as well as repository
+    version information.
+  * No longer auto-upgrade to repository format 2, to avoid accidental
+    upgrades, etc. Use git-annex upgrade when you're ready to run this
+    version.
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 20 Mar 2011 16:36:33 -0400
+
+git-annex (0.20110316) experimental; urgency=low
+
+  * New repository format, annex.version=2.
+  * The first time git-annex is run in an old format repository, it
+    will automatically upgrade it to the new format, staging all
+    necessary changes to git. Also added a "git annex upgrade" command.
+  * Colons are now avoided in filenames, so bare clones of git repos
+    can be put on USB thumb drives formatted with vFAT or similar
+    filesystems.
+  * Added two levels of hashing to object directory and .git-annex logs,
+    to improve scalability with enormous numbers of annexed
+    objects. (With one hundred million annexed objects, each
+    directory would contain fewer than 1024 files.)
+  * The setkey, fromkey, and dropkey subcommands have changed how
+    the key is specified. --backend is no longer used with these.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 16 Mar 2011 16:20:23 -0400
+
+git-annex (0.24) unstable; urgency=low
+
+  Branched the 0.24 series, which will be maintained for a while to
+  support v1 git-annex repos, while main development moves to the 0.2011
+  series, with v2 git-annex repos.
+
+  * Add Suggests on graphviz. Closes: #618039
+  * When adding files to the annex, the symlinks pointing at the annexed
+    content are made to have the same mtime as the original file.
+    While git does not preserve that information, this allows a tool
+    like metastore to be used with annexed files.
+    (Currently this is only done on systems supporting POSIX 200809.)
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 16 Mar 2011 18:35:13 -0400
+
+git-annex (0.23) unstable; urgency=low
+
+  * Support ssh remotes with a port specified.
+  * whereis: New subcommand to show where a file's content has gotten to.
+  * Rethink filename encoding handling for display. Since filename encoding
+    may or may not match locale settings, any attempt to decode filenames 
+    will fail for some files. So instead, do all output in binary mode.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 12 Mar 2011 15:02:49 -0400
+
+git-annex (0.22) unstable; urgency=low
+
+  * Git annexes can now be attached to bare git repositories.
+    (Both the local and remote host must have this version of git-annex
+    installed for it to work.)
+  * Support filenames that start with a dash; when such a file is passed
+    to a utility it will be escaped to avoid it being interpreted as an
+    option. (I went a little overboard and got the type checker involved
+    in this, so such files are rather comprehensively supported now.)
+  * New backends: SHA512 SHA384 SHA256 SHA224
+    (Supported on systems where corresponding shaNsum commands are available.)
+  * describe: New subcommand that can set or change the description of
+    a repository.
+  * Fix test suite to reap zombies.
+    (Zombies can be particularly annoying on OSX; thanks to Jimmy Tang
+    for his help eliminating the infestation... for now.)
+  * Make test suite not rely on a working cp -pr.
+    (The Unix wars are still ON!)
+  * Look for dir.git directories the same as git does.
+  * Support remote urls specified as relative paths.
+  * Support non-ssh remote paths that contain tilde expansions.
+  * fsck: Check for and repair location log damage.
+  * Bugfix: When fsck detected and moved away corrupt file content, it did
+    not update the location log.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 04 Mar 2011 15:10:57 -0400
+
+git-annex (0.21) unstable; urgency=low
+
+  * test: Don't rely on chmod -R working.
+  * unannex: Fix recently introduced bug when attempting to unannex more
+    than one file at a time.
+  * test: Set git user name and email in case git can't guess values.
+  * Fix display of unicode filenames.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 11 Feb 2011 23:21:08 -0400
+
+git-annex (0.20) unstable; urgency=low
+
+  * Preserve specified file ordering when instructed to act on multiple
+    files or directories. For example, "git annex get a b" will now always
+    get "a" before "b". Previously it could operate in either order.
+  * unannex: Commit staged changes at end, to avoid some confusing behavior
+    with the pre-commit hook, which would see some types of commits after
+    an unannex as checking in of an unlocked file.
+  * map: New subcommand that uses graphviz to display a nice map of
+    the git repository network.
+  * Deal with the mtl/monads-fd conflict.
+  * configure: Check for sha1sum.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 08 Feb 2011 18:57:24 -0400
+
+git-annex (0.19) unstable; urgency=low
+
+  * configure: Support using the uuidgen command if the uuid command is
+    not available.
+  * Allow --exclude to be specified more than once.
+  * There are now three levels of repository trust.
+  * untrust: Now marks the current repository as untrusted.
+  * semitrust: Now restores the default trust level. (What untrust used to do.)
+  * fsck, drop: Take untrusted repositories into account.
+  * Bugfix: Files were copied from trusted remotes first even if their
+    annex.cost was higher than other remotes.
+  * Improved temp file handling. Transfers of content can now be resumed
+    from temp files later; the resume does not have to be the immediate
+    next git-annex run.
+  * unused: Include partially transferred content in the list.
+  * Bugfix: Running a second git-annex while a first has a transfer in
+    progress no longer deletes the first processes's temp file.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 28 Jan 2011 14:31:37 -0400
+
+git-annex (0.18) unstable; urgency=low
+
+  * Bugfix: `copy --to` and `move --to` forgot to stage location log changes
+    after transferring the file to the remote repository.
+    (Did not affect ssh remotes.)
+  * fsck: Fix bug in moving of corrupted files to .git/annex/bad/
+  * migrate: Fix support for --backend option.
+  * unlock: Fix behavior when file content is not present.
+  * Test suite improvements. Current top-level test coverage: 80%
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 14 Jan 2011 14:17:44 -0400
+
+git-annex (0.17) unstable; urgency=low
+
+  * unannex: Now skips files whose content is not present, rather than
+    it being an error.
+  * New migrate subcommand can be used to switch files to using a different
+    backend, safely and with no duplication of content.
+  * bugfix: Fix crash caused by empty key name. (Thanks Henrik for reporting.)
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 09 Jan 2011 10:04:11 -0400
+
+git-annex (0.16) unstable; urgency=low
+
+  * git-annex-shell: Avoid exposing any git repo config except for the
+    annex.uuid when doing configlist.
+  * bugfix: Running `move --to` with a remote whose UUID was not yet known
+    could result in git-annex not recording on the local side where the
+    file was moved to. This could not result in data loss, or even a
+    significant problem, since the remote *did* record that it had the file.
+  * Also, add a general guard to detect attempts to record information
+    about repositories with missing UUIDs.
+  * bugfix: Running `move --to` with a non-ssh remote failed.
+  * bugfix: Running `copy --to` with a non-ssh remote actually did a move.
+  * Many test suite improvements. Current top-level test coverage: 65%
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 07 Jan 2011 14:33:13 -0400
+
+git-annex (0.15) unstable; urgency=low
+
+  * Support scp-style urls for remotes (host:path).
+  * Support ssh urls containing "~".
+  * Add trust and untrust subcommands, to allow configuring repositories
+    that are trusted to retain files without explicit checking.
+  * Fix bug in numcopies handling when multiple remotes pointed to the
+    same repository.
+  * Introduce the git-annex-shell command. It's now possible to make
+    a user have it as a restricted login shell, similar to git-shell.
+  * Note that git-annex will always use git-annex-shell when accessing
+    a ssh remote, so all of your remotes need to be upgraded to this
+    version of git-annex at the same time.
+  * Now rsync is exclusively used for copying files to and from remotes.
+    scp is not longer supported.
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 31 Dec 2010 22:00:52 -0400
+
+git-annex (0.14) unstable; urgency=low
+
+  * Bugfix to git annex unused in a repository with nothing yet annexed.
+  * Support upgrading from a v0 annex with nothing in it.
+  * Avoid multiple calls to git ls-files when passed eg, "*".
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 24 Dec 2010 17:38:48 -0400
+
+git-annex (0.13) unstable; urgency=low
+
+  * Makefile: Install man page and html (when built).
+  * Makefile: Add GHCFLAGS variable.
+  * Fix upgrade from 0.03.
+  * Support remotes using git+ssh and ssh+git as protocol.
+    Closes: #607056
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 14 Dec 2010 13:05:10 -0400
+
+git-annex (0.12) unstable; urgency=low
+
+  * Add --exclude option to exclude files from processing.
+  * mwdn2man: Fix a bug in newline supression. Closes: #606578
+  * Bugfix to git annex add of an unlocked file in a subdir. Closes: #606579
+  * Makefile: Add PREFIX variable.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 11 Dec 2010 17:32:00 -0400
+
+git-annex (0.11) unstable; urgency=low
+
+  * If available, rsync will be used for file transfers from remote
+    repositories. This allows resuming interrupted transfers.
+  * Added remote.annex-rsync-options.
+  * Avoid deleting temp files when rsync fails.
+  * Improve detection of version 0 repos.
+  * Add uninit subcommand. Closes: #605749
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 04 Dec 2010 17:27:42 -0400
+
+git-annex (0.10) unstable; urgency=low
+
+  * In .gitattributes, the annex.numcopies attribute can be used
+    to control the number of copies to retain of different types of files.
+  * Bugfix: Always correctly handle gitattributes when in a subdirectory of
+    the repository. (Had worked ok for ones like "*.mp3", but failed for
+    ones like "dir/*".)
+  * fsck: Fix warning about not enough copies of a file, when locations
+    are known, but are not available in currently configured remotes.
+  * precommit: Optimise to avoid calling git-check-attr more than once.
+  * The git-annex-backend attribute has been renamed to annex.backend.
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 28 Nov 2010 19:28:05 -0400
+
+git-annex (0.09) unstable; urgency=low
+
+  * Add copy subcommand.
+  * Fix bug in setkey subcommand triggered by move --to.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 27 Nov 2010 17:14:59 -0400
+
+git-annex (0.08) unstable; urgency=low
+
+  * Fix `git annex add ../foo` (when ran in a subdir of the repo).
+  * Add configure step to build process.
+  * Only use cp -a if it is supported, falling back to cp -p or plain cp
+    as needed for portability.
+  * cp --reflink=auto is used if supported, and will make git annex unlock
+    much faster on filesystems like btrfs that support copy on write.
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 21 Nov 2010 13:45:44 -0400
+
+git-annex (0.07) unstable; urgency=low
+
+  * find: New subcommand.
+  * unused: New subcommand, finds unused data. (Split out from fsck.)
+  * dropunused: New subcommand, provides for easy dropping of unused keys
+    by number, as listed by the unused subcommand.
+  * fsck: Print warnings to stderr; --quiet can now be used to only see
+    problems.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 15 Nov 2010 18:41:50 -0400
+
+git-annex (0.06) unstable; urgency=low
+
+  * fsck: Check if annex.numcopies is satisfied.
+  * fsck: Verify the sha1 of files when the SHA1 backend is used.
+  * fsck: Verify the size of files when the WORM backend is used.
+  * fsck: Allow specifying individual files if fscking everything
+    is not desired.
+  * fsck: Fix bug, introduced in 0.04, in detection of unused data.
+
+ -- Joey Hess <joeyh@debian.org>  Sat, 13 Nov 2010 16:24:29 -0400
+
+git-annex (0.05) unstable; urgency=low
+
+  * Optimize both pre-commit and lock subcommands to not call git diff
+    on every file being committed/locked.
+    (This actually also works around a bug in ghc, that caused
+    git-annex 0.04 pre-commit to sometimes corrupt filename being read
+    from git ls-files and fail. 
+    See <http://hackage.haskell.org/trac/ghc/ticket/4493>
+    The excessive number of calls made by pre-commit exposed the ghc bug.
+    Thanks Josh Triplett for the debugging.)
+  * Build with -O2.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 11 Nov 2010 18:31:09 -0400
+
+git-annex (0.04) unstable; urgency=low
+
+  * Add unlock subcommand, which replaces the symlink with a copy of
+    the file's content in preparation of changing it. The "edit" subcommand
+    is an alias for unlock.
+  * Add lock subcommand.
+  * Unlocked files will now automatically be added back into the annex when
+    committed (and the updated symlink committed), by some magic in the
+    pre-commit hook.
+  * The SHA1 backend is now fully usable.
+  * Add annex.version, which will be used to automate upgrades
+    between incompatible versions.
+  * Reorganised the layout of .git/annex/
+  * The new layout will be automatically upgraded to the first time
+    git-annex is used in a repository with the old layout.
+  * Note that git-annex 0.04 cannot transfer content from old repositories
+    that have not yet been upgraded.
+  * Annexed file contents are now made unwritable and put in unwriteable
+    directories, to avoid them accidentally being removed or modified.
+    (Thanks Josh Triplett for the idea.)
+  * Add build dep on libghc6-testpack-dev. Closes: #603016
+  * Avoid using runghc to run test suite as it is not available on all
+    architectures. Closes: #603006
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 10 Nov 2010 14:23:23 -0400
+
+git-annex (0.03) unstable; urgency=low
+
+  * Fix support for file:// remotes.
+  * Add --verbose
+  * Fix SIGINT handling.
+  * Fix handling of files with unusual characters in their name.
+  * Fixed memory leak; git-annex no longer reads the whole file list
+    from git before starting, and will be much faster with large repos.
+  * Fix crash on unknown symlinks.
+  * Added remote.annex-scp-options and remote.annex-ssh-options.
+  * The backends to use when adding different sets of files can be configured
+    via gitattributes.
+  * In .gitattributes, the git-annex-backend attribute can be set to the
+    names of backends to use when adding different types of files.
+  * Add fsck subcommand. (For now it only finds unused key contents in the
+    annex.)
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 07 Nov 2010 18:26:04 -0400
+
+git-annex (0.02) unstable; urgency=low
+
+  * Can scp annexed files from remote hosts, and check remote hosts for
+    file content when dropping files.
+  * New move subcommand, that makes it easy to move file contents from
+    or to a remote.
+  * New fromkey subcommand, for registering urls, etc.
+  * git-annex init will now set up a pre-commit hook that fixes up symlinks
+    before they are committed, to ensure that moving symlinks around does not
+    break them.
+  * More intelligent and fast staging of modified files; git add coalescing.
+  * Add remote.annex-ignore git config setting to allow completly disabling
+    a given remote.
+  * --from/--to can be used to control the remote repository that git-annex
+    uses.
+  * --quiet can be used to avoid verbose output
+  * New plumbing-level dropkey and addkey subcommands.
+  * Lots of bug fixes.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 27 Oct 2010 16:39:29 -0400
+
+git-annex (0.01) unstable; urgency=low
+
+  * First prerelease.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 20 Oct 2010 12:54:24 -0400
diff --git a/COPYRIGHT b/COPYRIGHT
new file mode 100644
index 0000000000..a41e2d603a
--- /dev/null
+++ b/COPYRIGHT
@@ -0,0 +1,840 @@
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Source: native package
+
+Files: *
+Copyright: © 2010-2024 Joey Hess <id@joeyh.name>
+License: AGPL-3+
+
+Files: Assistant/WebApp.hs Assistant/WebApp/* templates/* static/*
+Copyright: © 2012-2017 Joey Hess <id@joeyh.name>
+           © 2014 Sören Brunk
+License: AGPL-3+
+
+Files: doc/special_remotes/external/* 
+Copyright: © 2013 Joey Hess <id@joeyh.name>
+License: GPL-3+
+
+Files: doc/design/external_backend_protocol/git-annex-backend-XFOO
+Copyright: © 2020 Joey Hess <id@joeyh.name>
+License: GPL-3+
+
+Files: Command/Sync.hs
+Copyright: © Joachim Breitner <mail@joachim-breitner.de>
+           © 2011-2020 Joey Hess <id@joeyh.name>
+License: AGPL-3+
+
+Files: Command/List.hs
+Copyright: © 2013 Joey Hess <id@joeyh.name>
+           © 2013 Antoine Beaupré
+License: AGPL-3+
+
+Files: Remote/Ddar.hs
+Copyright: © 2011-2020 Joey Hess <id@joeyh.name>
+           © 2014 Robie Basak <robie@justgohome.co.uk>
+License: GPL-3+
+
+Files: Utility/Attoparsec.hs
+Copyright: 2019 Joey Hess <id@joeyh.name>
+           2007-2015 Bryan O'Sullivan
+License: BSD-3-clause
+
+Files: Utility/Matcher.hs Utility/Tor.hs Utility/Yesod.hs
+Copyright: © 2010-2023 Joey Hess <id@joeyh.name>
+License: AGPL-3+
+
+Files: Utility/*
+Copyright: 2012-2022 Joey Hess <id@joeyh.name>
+License: BSD-2-clause
+
+Files: doc/logo* */favicon.ico standalone/osx/git-annex.app/Contents/Resources/git-annex.icns
+Copyright: 2007 Henrik Nyh <http://henrik.nyh.se/>
+           2010 Joey Hess <id@joeyh.name>
+	   2013 John Lawrence
+License: icon-license
+  Free to modify and redistribute with due credit, and obviously free to use.
+
+Files: Utility/MD5.hs
+Copyright: 2001 Ian Lynagh
+License: GPL-2
+ The full text of version 2 of the GPL is distributed in
+ /usr/share/common-licenses/GPL-2 on Debian systems.
+
+Files: Database/RawFilePath.hs
+Copyright: © 2012 Michael Snoyman, http://www.yesodweb.com/
+           © 2023 Joey Hess <id@joeyh.name>
+License: Expat
+ The text of the Expat license is in the Expat section below.
+
+Files: doc/tips/automatically_adding_metadata/pre-commit-annex 
+Copyright: 2014 Joey Hess <id@joeyh.name>
+           2016 Klaus Ethgen <Klaus@Ethgen.ch>
+License: GPL-3+
+
+Files: static/jquery*
+Copyright: © 2005-2011 by John Resig, Branden Aaron & Jörn Zaefferer
+           © 2011 The Dojo Foundation
+License: Expat or GPL-2
+ The full text of version 2 of the GPL is distributed in
+ /usr/share/common-licenses/GPL-2 on Debian systems. The text of the Expat
+ license is in the Expat section below.
+
+Files: static/*/bootstrap* static/*/glyphicons-halflings*
+Copyright: 2012-2014 Twitter, Inc.
+License: MIT-twitter
+  Copyright (c) 2011-2014 Twitter, Inc
+  .
+  Permission is hereby granted, free of charge, to any person obtaining a copy
+  of this software and associated documentation files (the "Software"), to deal
+  in the Software without restriction, including without limitation the rights
+  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+  copies of the Software, and to permit persons to whom the Software is
+  furnished to do so, subject to the following conditions:
+  .
+  The above copyright notice and this permission notice shall be included in
+  all copies or substantial portions of the Software.
+  .
+  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+  THE SOFTWARE.
+
+License: GPL-3+
+ The full text of version 3 of the GPL is distributed as doc/license/GPL in
+ this package's source, or in /usr/share/common-licenses/GPL-3 on
+ Debian systems.
+
+License: BSD-2-clause
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+ 1. Redistributions of source code must retain the above copyright
+    notice, this list of conditions and the following disclaimer.
+ 2. Redistributions in binary form must reproduce the above copyright
+    notice, this list of conditions and the following disclaimer in the
+    documentation and/or other materials provided with the distribution.
+ .
+ THIS SOFTWARE IS PROVIDED BY AUTHORS AND CONTRIBUTORS ``AS IS'' AND
+ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE
+ FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ SUCH DAMAGE.
+
+License: BSD-3-clause
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+ .
+ 1. Redistributions of source code must retain the above copyright
+     notice, this list of conditions and the following disclaimer.
+ .
+ 2. Redistributions in binary form must reproduce the above copyright
+    notice, this list of conditions and the following disclaimer in the
+    documentation and/or other materials provided with the distribution.
+ .
+ 3. Neither the name of the author nor the names of his contributors
+    may be used to endorse or promote products derived from this software
+    without specific prior written permission.
+ .
+ THIS SOFTWARE IS PROVIDED BY THE CONTRIBUTORS ``AS IS'' AND ANY EXPRESS
+ OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ DISCLAIMED.  IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR
+ ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+ ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+
+License: Expat
+ Permission is hereby granted, free of charge, to any person obtaining
+ a copy of this software and associated documentation files (the
+ "Software"), to deal in the Software without restriction, including
+ without limitation the rights to use, copy, modify, merge, publish,
+ distribute, sublicense, and/or sell copies of the Software, and to
+ permit persons to whom the Software is furnished to do so, subject to
+ the following conditions:
+ .
+ The above copyright notice and this permission notice shall be
+ included in all copies or substantial portions of the Software.
+ .
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+ LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+ OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+License: AGPL-3+
+                      GNU AFFERO GENERAL PUBLIC LICENSE
+                         Version 3, 19 November 2007
+ .
+   Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
+   Everyone is permitted to copy and distribute verbatim copies
+   of this license document, but changing it is not allowed.
+ .
+                              Preamble
+ .
+    The GNU Affero General Public License is a free, copyleft license for
+  software and other kinds of works, specifically designed to ensure
+  cooperation with the community in the case of network server software.
+ .
+    The licenses for most software and other practical works are designed
+  to take away your freedom to share and change the works.  By contrast,
+  our General Public Licenses are intended to guarantee your freedom to
+  share and change all versions of a program--to make sure it remains free
+  software for all its users.
+ .
+    When we speak of free software, we are referring to freedom, not
+  price.  Our General Public Licenses are designed to make sure that you
+  have the freedom to distribute copies of free software (and charge for
+  them if you wish), that you receive source code or can get it if you
+  want it, that you can change the software or use pieces of it in new
+  free programs, and that you know you can do these things.
+ .
+    Developers that use our General Public Licenses protect your rights
+  with two steps: (1) assert copyright on the software, and (2) offer
+  you this License which gives you legal permission to copy, distribute
+  and/or modify the software.
+ .
+    A secondary benefit of defending all users' freedom is that
+  improvements made in alternate versions of the program, if they
+  receive widespread use, become available for other developers to
+  incorporate.  Many developers of free software are heartened and
+  encouraged by the resulting cooperation.  However, in the case of
+  software used on network servers, this result may fail to come about.
+  The GNU General Public License permits making a modified version and
+  letting the public access it on a server without ever releasing its
+  source code to the public.
+ .
+    The GNU Affero General Public License is designed specifically to
+  ensure that, in such cases, the modified source code becomes available
+  to the community.  It requires the operator of a network server to
+  provide the source code of the modified version running there to the
+  users of that server.  Therefore, public use of a modified version, on
+  a publicly accessible server, gives the public access to the source
+  code of the modified version.
+ .
+    An older license, called the Affero General Public License and
+  published by Affero, was designed to accomplish similar goals.  This is
+  a different license, not a version of the Affero GPL, but Affero has
+  released a new version of the Affero GPL which permits relicensing under
+  this license.
+ .
+    The precise terms and conditions for copying, distribution and
+  modification follow.
+ .
+                         TERMS AND CONDITIONS
+ .
+    0. Definitions.
+ .
+    "This License" refers to version 3 of the GNU Affero General Public License.
+ .
+    "Copyright" also means copyright-like laws that apply to other kinds of
+  works, such as semiconductor masks.
+ .
+    "The Program" refers to any copyrightable work licensed under this
+  License.  Each licensee is addressed as "you".  "Licensees" and
+  "recipients" may be individuals or organizations.
+ .
+    To "modify" a work means to copy from or adapt all or part of the work
+  in a fashion requiring copyright permission, other than the making of an
+  exact copy.  The resulting work is called a "modified version" of the
+  earlier work or a work "based on" the earlier work.
+ .
+    A "covered work" means either the unmodified Program or a work based
+  on the Program.
+ .
+    To "propagate" a work means to do anything with it that, without
+  permission, would make you directly or secondarily liable for
+  infringement under applicable copyright law, except executing it on a
+  computer or modifying a private copy.  Propagation includes copying,
+  distribution (with or without modification), making available to the
+  public, and in some countries other activities as well.
+ .
+    To "convey" a work means any kind of propagation that enables other
+  parties to make or receive copies.  Mere interaction with a user through
+  a computer network, with no transfer of a copy, is not conveying.
+ .
+    An interactive user interface displays "Appropriate Legal Notices"
+  to the extent that it includes a convenient and prominently visible
+  feature that (1) displays an appropriate copyright notice, and (2)
+  tells the user that there is no warranty for the work (except to the
+  extent that warranties are provided), that licensees may convey the
+  work under this License, and how to view a copy of this License.  If
+  the interface presents a list of user commands or options, such as a
+  menu, a prominent item in the list meets this criterion.
+ .
+    1. Source Code.
+ .
+    The "source code" for a work means the preferred form of the work
+  for making modifications to it.  "Object code" means any non-source
+  form of a work.
+ .
+    A "Standard Interface" means an interface that either is an official
+  standard defined by a recognized standards body, or, in the case of
+  interfaces specified for a particular programming language, one that
+  is widely used among developers working in that language.
+ .
+    The "System Libraries" of an executable work include anything, other
+  than the work as a whole, that (a) is included in the normal form of
+  packaging a Major Component, but which is not part of that Major
+  Component, and (b) serves only to enable use of the work with that
+  Major Component, or to implement a Standard Interface for which an
+  implementation is available to the public in source code form.  A
+  "Major Component", in this context, means a major essential component
+  (kernel, window system, and so on) of the specific operating system
+  (if any) on which the executable work runs, or a compiler used to
+  produce the work, or an object code interpreter used to run it.
+ .
+    The "Corresponding Source" for a work in object code form means all
+  the source code needed to generate, install, and (for an executable
+  work) run the object code and to modify the work, including scripts to
+  control those activities.  However, it does not include the work's
+  System Libraries, or general-purpose tools or generally available free
+  programs which are used unmodified in performing those activities but
+  which are not part of the work.  For example, Corresponding Source
+  includes interface definition files associated with source files for
+  the work, and the source code for shared libraries and dynamically
+  linked subprograms that the work is specifically designed to require,
+  such as by intimate data communication or control flow between those
+  subprograms and other parts of the work.
+ .
+    The Corresponding Source need not include anything that users
+  can regenerate automatically from other parts of the Corresponding
+  Source.
+ .
+    The Corresponding Source for a work in source code form is that
+  same work.
+ .
+    2. Basic Permissions.
+ .
+    All rights granted under this License are granted for the term of
+  copyright on the Program, and are irrevocable provided the stated
+  conditions are met.  This License explicitly affirms your unlimited
+  permission to run the unmodified Program.  The output from running a
+  covered work is covered by this License only if the output, given its
+  content, constitutes a covered work.  This License acknowledges your
+  rights of fair use or other equivalent, as provided by copyright law.
+ .
+    You may make, run and propagate covered works that you do not
+  convey, without conditions so long as your license otherwise remains
+  in force.  You may convey covered works to others for the sole purpose
+  of having them make modifications exclusively for you, or provide you
+  with facilities for running those works, provided that you comply with
+  the terms of this License in conveying all material for which you do
+  not control copyright.  Those thus making or running the covered works
+  for you must do so exclusively on your behalf, under your direction
+  and control, on terms that prohibit them from making any copies of
+  your copyrighted material outside their relationship with you.
+ .
+    Conveying under any other circumstances is permitted solely under
+  the conditions stated below.  Sublicensing is not allowed; section 10
+  makes it unnecessary.
+ .
+    3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+ .
+    No covered work shall be deemed part of an effective technological
+  measure under any applicable law fulfilling obligations under article
+  11 of the WIPO copyright treaty adopted on 20 December 1996, or
+  similar laws prohibiting or restricting circumvention of such
+  measures.
+ .
+    When you convey a covered work, you waive any legal power to forbid
+  circumvention of technological measures to the extent such circumvention
+  is effected by exercising rights under this License with respect to
+  the covered work, and you disclaim any intention to limit operation or
+  modification of the work as a means of enforcing, against the work's
+  users, your or third parties' legal rights to forbid circumvention of
+  technological measures.
+ .
+    4. Conveying Verbatim Copies.
+ .
+    You may convey verbatim copies of the Program's source code as you
+  receive it, in any medium, provided that you conspicuously and
+  appropriately publish on each copy an appropriate copyright notice;
+  keep intact all notices stating that this License and any
+  non-permissive terms added in accord with section 7 apply to the code;
+  keep intact all notices of the absence of any warranty; and give all
+  recipients a copy of this License along with the Program.
+ .
+    You may charge any price or no price for each copy that you convey,
+  and you may offer support or warranty protection for a fee.
+ .
+    5. Conveying Modified Source Versions.
+ .
+    You may convey a work based on the Program, or the modifications to
+  produce it from the Program, in the form of source code under the
+  terms of section 4, provided that you also meet all of these conditions:
+ .
+      a) The work must carry prominent notices stating that you modified
+      it, and giving a relevant date.
+ .
+      b) The work must carry prominent notices stating that it is
+      released under this License and any conditions added under section
+      7.  This requirement modifies the requirement in section 4 to
+      "keep intact all notices".
+ .
+      c) You must license the entire work, as a whole, under this
+      License to anyone who comes into possession of a copy.  This
+      License will therefore apply, along with any applicable section 7
+      additional terms, to the whole of the work, and all its parts,
+      regardless of how they are packaged.  This License gives no
+      permission to license the work in any other way, but it does not
+      invalidate such permission if you have separately received it.
+ .
+      d) If the work has interactive user interfaces, each must display
+      Appropriate Legal Notices; however, if the Program has interactive
+      interfaces that do not display Appropriate Legal Notices, your
+      work need not make them do so.
+ .
+    A compilation of a covered work with other separate and independent
+  works, which are not by their nature extensions of the covered work,
+  and which are not combined with it such as to form a larger program,
+  in or on a volume of a storage or distribution medium, is called an
+  "aggregate" if the compilation and its resulting copyright are not
+  used to limit the access or legal rights of the compilation's users
+  beyond what the individual works permit.  Inclusion of a covered work
+  in an aggregate does not cause this License to apply to the other
+  parts of the aggregate.
+ .
+    6. Conveying Non-Source Forms.
+ .
+    You may convey a covered work in object code form under the terms
+  of sections 4 and 5, provided that you also convey the
+  machine-readable Corresponding Source under the terms of this License,
+  in one of these ways:
+ .
+      a) Convey the object code in, or embodied in, a physical product
+      (including a physical distribution medium), accompanied by the
+      Corresponding Source fixed on a durable physical medium
+      customarily used for software interchange.
+ .
+      b) Convey the object code in, or embodied in, a physical product
+      (including a physical distribution medium), accompanied by a
+      written offer, valid for at least three years and valid for as
+      long as you offer spare parts or customer support for that product
+      model, to give anyone who possesses the object code either (1) a
+      copy of the Corresponding Source for all the software in the
+      product that is covered by this License, on a durable physical
+      medium customarily used for software interchange, for a price no
+      more than your reasonable cost of physically performing this
+      conveying of source, or (2) access to copy the
+      Corresponding Source from a network server at no charge.
+ .
+      c) Convey individual copies of the object code with a copy of the
+      written offer to provide the Corresponding Source.  This
+      alternative is allowed only occasionally and noncommercially, and
+      only if you received the object code with such an offer, in accord
+      with subsection 6b.
+ .
+      d) Convey the object code by offering access from a designated
+      place (gratis or for a charge), and offer equivalent access to the
+      Corresponding Source in the same way through the same place at no
+      further charge.  You need not require recipients to copy the
+      Corresponding Source along with the object code.  If the place to
+      copy the object code is a network server, the Corresponding Source
+      may be on a different server (operated by you or a third party)
+      that supports equivalent copying facilities, provided you maintain
+      clear directions next to the object code saying where to find the
+      Corresponding Source.  Regardless of what server hosts the
+      Corresponding Source, you remain obligated to ensure that it is
+      available for as long as needed to satisfy these requirements.
+ .
+      e) Convey the object code using peer-to-peer transmission, provided
+      you inform other peers where the object code and Corresponding
+      Source of the work are being offered to the general public at no
+      charge under subsection 6d.
+ .
+    A separable portion of the object code, whose source code is excluded
+  from the Corresponding Source as a System Library, need not be
+  included in conveying the object code work.
+ .
+    A "User Product" is either (1) a "consumer product", which means any
+  tangible personal property which is normally used for personal, family,
+  or household purposes, or (2) anything designed or sold for incorporation
+  into a dwelling.  In determining whether a product is a consumer product,
+  doubtful cases shall be resolved in favor of coverage.  For a particular
+  product received by a particular user, "normally used" refers to a
+  typical or common use of that class of product, regardless of the status
+  of the particular user or of the way in which the particular user
+  actually uses, or expects or is expected to use, the product.  A product
+  is a consumer product regardless of whether the product has substantial
+  commercial, industrial or non-consumer uses, unless such uses represent
+  the only significant mode of use of the product.
+ .
+    "Installation Information" for a User Product means any methods,
+  procedures, authorization keys, or other information required to install
+  and execute modified versions of a covered work in that User Product from
+  a modified version of its Corresponding Source.  The information must
+  suffice to ensure that the continued functioning of the modified object
+  code is in no case prevented or interfered with solely because
+  modification has been made.
+ .
+    If you convey an object code work under this section in, or with, or
+  specifically for use in, a User Product, and the conveying occurs as
+  part of a transaction in which the right of possession and use of the
+  User Product is transferred to the recipient in perpetuity or for a
+  fixed term (regardless of how the transaction is characterized), the
+  Corresponding Source conveyed under this section must be accompanied
+  by the Installation Information.  But this requirement does not apply
+  if neither you nor any third party retains the ability to install
+  modified object code on the User Product (for example, the work has
+  been installed in ROM).
+ .
+    The requirement to provide Installation Information does not include a
+  requirement to continue to provide support service, warranty, or updates
+  for a work that has been modified or installed by the recipient, or for
+  the User Product in which it has been modified or installed.  Access to a
+  network may be denied when the modification itself materially and
+  adversely affects the operation of the network or violates the rules and
+  protocols for communication across the network.
+ .
+    Corresponding Source conveyed, and Installation Information provided,
+  in accord with this section must be in a format that is publicly
+  documented (and with an implementation available to the public in
+  source code form), and must require no special password or key for
+  unpacking, reading or copying.
+ .
+    7. Additional Terms.
+ .
+    "Additional permissions" are terms that supplement the terms of this
+  License by making exceptions from one or more of its conditions.
+  Additional permissions that are applicable to the entire Program shall
+  be treated as though they were included in this License, to the extent
+  that they are valid under applicable law.  If additional permissions
+  apply only to part of the Program, that part may be used separately
+  under those permissions, but the entire Program remains governed by
+  this License without regard to the additional permissions.
+ .
+    When you convey a copy of a covered work, you may at your option
+  remove any additional permissions from that copy, or from any part of
+  it.  (Additional permissions may be written to require their own
+  removal in certain cases when you modify the work.)  You may place
+  additional permissions on material, added by you to a covered work,
+  for which you have or can give appropriate copyright permission.
+ .
+    Notwithstanding any other provision of this License, for material you
+  add to a covered work, you may (if authorized by the copyright holders of
+  that material) supplement the terms of this License with terms:
+ .
+      a) Disclaiming warranty or limiting liability differently from the
+      terms of sections 15 and 16 of this License; or
+ .
+      b) Requiring preservation of specified reasonable legal notices or
+      author attributions in that material or in the Appropriate Legal
+      Notices displayed by works containing it; or
+ .
+      c) Prohibiting misrepresentation of the origin of that material, or
+      requiring that modified versions of such material be marked in
+      reasonable ways as different from the original version; or
+ .
+      d) Limiting the use for publicity purposes of names of licensors or
+      authors of the material; or
+ .
+      e) Declining to grant rights under trademark law for use of some
+      trade names, trademarks, or service marks; or
+ .
+      f) Requiring indemnification of licensors and authors of that
+      material by anyone who conveys the material (or modified versions of
+      it) with contractual assumptions of liability to the recipient, for
+      any liability that these contractual assumptions directly impose on
+      those licensors and authors.
+ .
+    All other non-permissive additional terms are considered "further
+  restrictions" within the meaning of section 10.  If the Program as you
+  received it, or any part of it, contains a notice stating that it is
+  governed by this License along with a term that is a further
+  restriction, you may remove that term.  If a license document contains
+  a further restriction but permits relicensing or conveying under this
+  License, you may add to a covered work material governed by the terms
+  of that license document, provided that the further restriction does
+  not survive such relicensing or conveying.
+ .
+    If you add terms to a covered work in accord with this section, you
+  must place, in the relevant source files, a statement of the
+  additional terms that apply to those files, or a notice indicating
+  where to find the applicable terms.
+ .
+    Additional terms, permissive or non-permissive, may be stated in the
+  form of a separately written license, or stated as exceptions;
+  the above requirements apply either way.
+ .
+    8. Termination.
+ .
+    You may not propagate or modify a covered work except as expressly
+  provided under this License.  Any attempt otherwise to propagate or
+  modify it is void, and will automatically terminate your rights under
+  this License (including any patent licenses granted under the third
+  paragraph of section 11).
+ .
+    However, if you cease all violation of this License, then your
+  license from a particular copyright holder is reinstated (a)
+  provisionally, unless and until the copyright holder explicitly and
+  finally terminates your license, and (b) permanently, if the copyright
+  holder fails to notify you of the violation by some reasonable means
+  prior to 60 days after the cessation.
+ .
+    Moreover, your license from a particular copyright holder is
+  reinstated permanently if the copyright holder notifies you of the
+  violation by some reasonable means, this is the first time you have
+  received notice of violation of this License (for any work) from that
+  copyright holder, and you cure the violation prior to 30 days after
+  your receipt of the notice.
+ .
+    Termination of your rights under this section does not terminate the
+  licenses of parties who have received copies or rights from you under
+  this License.  If your rights have been terminated and not permanently
+  reinstated, you do not qualify to receive new licenses for the same
+  material under section 10.
+ .
+    9. Acceptance Not Required for Having Copies.
+ .
+    You are not required to accept this License in order to receive or
+  run a copy of the Program.  Ancillary propagation of a covered work
+  occurring solely as a consequence of using peer-to-peer transmission
+  to receive a copy likewise does not require acceptance.  However,
+  nothing other than this License grants you permission to propagate or
+  modify any covered work.  These actions infringe copyright if you do
+  not accept this License.  Therefore, by modifying or propagating a
+  covered work, you indicate your acceptance of this License to do so.
+ .
+    10. Automatic Licensing of Downstream Recipients.
+ .
+    Each time you convey a covered work, the recipient automatically
+  receives a license from the original licensors, to run, modify and
+  propagate that work, subject to this License.  You are not responsible
+  for enforcing compliance by third parties with this License.
+ .
+    An "entity transaction" is a transaction transferring control of an
+  organization, or substantially all assets of one, or subdividing an
+  organization, or merging organizations.  If propagation of a covered
+  work results from an entity transaction, each party to that
+  transaction who receives a copy of the work also receives whatever
+  licenses to the work the party's predecessor in interest had or could
+  give under the previous paragraph, plus a right to possession of the
+  Corresponding Source of the work from the predecessor in interest, if
+  the predecessor has it or can get it with reasonable efforts.
+ .
+    You may not impose any further restrictions on the exercise of the
+  rights granted or affirmed under this License.  For example, you may
+  not impose a license fee, royalty, or other charge for exercise of
+  rights granted under this License, and you may not initiate litigation
+  (including a cross-claim or counterclaim in a lawsuit) alleging that
+  any patent claim is infringed by making, using, selling, offering for
+  sale, or importing the Program or any portion of it.
+ .
+    11. Patents.
+ .
+    A "contributor" is a copyright holder who authorizes use under this
+  License of the Program or a work on which the Program is based.  The
+  work thus licensed is called the contributor's "contributor version".
+ .
+    A contributor's "essential patent claims" are all patent claims
+  owned or controlled by the contributor, whether already acquired or
+  hereafter acquired, that would be infringed by some manner, permitted
+  by this License, of making, using, or selling its contributor version,
+  but do not include claims that would be infringed only as a
+  consequence of further modification of the contributor version.  For
+  purposes of this definition, "control" includes the right to grant
+  patent sublicenses in a manner consistent with the requirements of
+  this License.
+ .
+    Each contributor grants you a non-exclusive, worldwide, royalty-free
+  patent license under the contributor's essential patent claims, to
+  make, use, sell, offer for sale, import and otherwise run, modify and
+  propagate the contents of its contributor version.
+ .
+    In the following three paragraphs, a "patent license" is any express
+  agreement or commitment, however denominated, not to enforce a patent
+  (such as an express permission to practice a patent or covenant not to
+  sue for patent infringement).  To "grant" such a patent license to a
+  party means to make such an agreement or commitment not to enforce a
+  patent against the party.
+ .
+    If you convey a covered work, knowingly relying on a patent license,
+  and the Corresponding Source of the work is not available for anyone
+  to copy, free of charge and under the terms of this License, through a
+  publicly available network server or other readily accessible means,
+  then you must either (1) cause the Corresponding Source to be so
+  available, or (2) arrange to deprive yourself of the benefit of the
+  patent license for this particular work, or (3) arrange, in a manner
+  consistent with the requirements of this License, to extend the patent
+  license to downstream recipients.  "Knowingly relying" means you have
+  actual knowledge that, but for the patent license, your conveying the
+  covered work in a country, or your recipient's use of the covered work
+  in a country, would infringe one or more identifiable patents in that
+  country that you have reason to believe are valid.
+ .
+    If, pursuant to or in connection with a single transaction or
+  arrangement, you convey, or propagate by procuring conveyance of, a
+  covered work, and grant a patent license to some of the parties
+  receiving the covered work authorizing them to use, propagate, modify
+  or convey a specific copy of the covered work, then the patent license
+  you grant is automatically extended to all recipients of the covered
+  work and works based on it.
+ .
+    A patent license is "discriminatory" if it does not include within
+  the scope of its coverage, prohibits the exercise of, or is
+  conditioned on the non-exercise of one or more of the rights that are
+  specifically granted under this License.  You may not convey a covered
+  work if you are a party to an arrangement with a third party that is
+  in the business of distributing software, under which you make payment
+  to the third party based on the extent of your activity of conveying
+  the work, and under which the third party grants, to any of the
+  parties who would receive the covered work from you, a discriminatory
+  patent license (a) in connection with copies of the covered work
+  conveyed by you (or copies made from those copies), or (b) primarily
+  for and in connection with specific products or compilations that
+  contain the covered work, unless you entered into that arrangement,
+  or that patent license was granted, prior to 28 March 2007.
+ .
+    Nothing in this License shall be construed as excluding or limiting
+  any implied license or other defenses to infringement that may
+  otherwise be available to you under applicable patent law.
+ .
+    12. No Surrender of Others' Freedom.
+ .
+    If conditions are imposed on you (whether by court order, agreement or
+  otherwise) that contradict the conditions of this License, they do not
+  excuse you from the conditions of this License.  If you cannot convey a
+  covered work so as to satisfy simultaneously your obligations under this
+  License and any other pertinent obligations, then as a consequence you may
+  not convey it at all.  For example, if you agree to terms that obligate you
+  to collect a royalty for further conveying from those to whom you convey
+  the Program, the only way you could satisfy both those terms and this
+  License would be to refrain entirely from conveying the Program.
+ .
+    13. Remote Network Interaction; Use with the GNU General Public License.
+ .
+    Notwithstanding any other provision of this License, if you modify the
+  Program, your modified version must prominently offer all users
+  interacting with it remotely through a computer network (if your version
+  supports such interaction) an opportunity to receive the Corresponding
+  Source of your version by providing access to the Corresponding Source
+  from a network server at no charge, through some standard or customary
+  means of facilitating copying of software.  This Corresponding Source
+  shall include the Corresponding Source for any work covered by version 3
+  of the GNU General Public License that is incorporated pursuant to the
+  following paragraph.
+ .
+    Notwithstanding any other provision of this License, you have
+  permission to link or combine any covered work with a work licensed
+  under version 3 of the GNU General Public License into a single
+  combined work, and to convey the resulting work.  The terms of this
+  License will continue to apply to the part which is the covered work,
+  but the work with which it is combined will remain governed by version
+  3 of the GNU General Public License.
+ .
+    14. Revised Versions of this License.
+ .
+    The Free Software Foundation may publish revised and/or new versions of
+  the GNU Affero General Public License from time to time.  Such new versions
+  will be similar in spirit to the present version, but may differ in detail to
+  address new problems or concerns.
+ .
+    Each version is given a distinguishing version number.  If the
+  Program specifies that a certain numbered version of the GNU Affero General
+  Public License "or any later version" applies to it, you have the
+  option of following the terms and conditions either of that numbered
+  version or of any later version published by the Free Software
+  Foundation.  If the Program does not specify a version number of the
+  GNU Affero General Public License, you may choose any version ever published
+  by the Free Software Foundation.
+ .
+    If the Program specifies that a proxy can decide which future
+  versions of the GNU Affero General Public License can be used, that proxy's
+  public statement of acceptance of a version permanently authorizes you
+  to choose that version for the Program.
+ .
+    Later license versions may give you additional or different
+  permissions.  However, no additional obligations are imposed on any
+  author or copyright holder as a result of your choosing to follow a
+  later version.
+ .
+    15. Disclaimer of Warranty.
+ .
+    THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+  APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+  HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+  OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+  THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+  PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+  IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+  ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+ .
+    16. Limitation of Liability.
+ .
+    IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+  WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+  THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+  GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+  USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+  DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+  PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+  EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+  SUCH DAMAGES.
+ .
+    17. Interpretation of Sections 15 and 16.
+ .
+    If the disclaimer of warranty and limitation of liability provided
+  above cannot be given local legal effect according to their terms,
+  reviewing courts shall apply local law that most closely approximates
+  an absolute waiver of all civil liability in connection with the
+  Program, unless a warranty or assumption of liability accompanies a
+  copy of the Program in return for a fee.
+ .
+                       END OF TERMS AND CONDITIONS
+ .
+              How to Apply These Terms to Your New Programs
+ .
+    If you develop a new program, and you want it to be of the greatest
+  possible use to the public, the best way to achieve this is to make it
+  free software which everyone can redistribute and change under these terms.
+ .
+    To do so, attach the following notices to the program.  It is safest
+  to attach them to the start of each source file to most effectively
+  state the exclusion of warranty; and each file should have at least
+  the "copyright" line and a pointer to where the full notice is found.
+ .
+      <one line to give the program's name and a brief idea of what it does.>
+      Copyright (C) <year>  <name of author>
+ .
+      This program is free software: you can redistribute it and/or modify
+      it under the terms of the GNU Affero General Public License as published by
+      the Free Software Foundation, either version 3 of the License, or
+      (at your option) any later version.
+ .
+      This program is distributed in the hope that it will be useful,
+      but WITHOUT ANY WARRANTY; without even the implied warranty of
+      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+      GNU Affero General Public License for more details.
+ .
+      You should have received a copy of the GNU Affero General Public License
+      along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ .
+  Also add information on how to contact you by electronic and paper mail.
+ .
+    If your software can interact with users remotely through a computer
+  network, you should also make sure that it provides a way for users to
+  get its source.  For example, if your program is a web application, its
+  interface could display a "Source" link that leads users to an archive
+  of the code.  There are many ways you could offer source, and different
+  solutions will be better for different programs; see section 13 for the
+  specific requirements.
+ .
+    You should also get your employer (if you work as a programmer) or school,
+  if any, to sign a "copyright disclaimer" for the program, if necessary.
+  For more information on this, and how to apply and follow the GNU AGPL, see
+  <http://www.gnu.org/licenses/>.
diff --git a/CmdLine.hs b/CmdLine.hs
new file mode 100644
index 0000000000..004198c40a
--- /dev/null
+++ b/CmdLine.hs
@@ -0,0 +1,199 @@
+{- git-annex command line parsing and dispatch
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module CmdLine (
+	dispatch,
+	usage,
+	parseCmd,
+	prepRunCommand,
+) where
+
+import qualified Options.Applicative as O
+import qualified Options.Applicative.Help as H
+import Control.Exception (throw)
+import Control.Monad.IO.Class (MonadIO)
+import System.Exit
+
+import Annex.Common
+import qualified Annex
+import qualified Git
+import qualified Git.AutoCorrect
+import qualified Git.Config
+import Annex.Action
+import Annex.Environment
+import Command
+import Types.Messages
+
+{- Parses input arguments, finds a matching Command, and runs it. -}
+dispatch :: Bool -> Bool -> CmdParams -> [Command] -> [(String, String)] -> IO Git.Repo -> String -> String -> IO ()
+dispatch addonok fuzzyok allargs allcmds fields getgitrepo progname progdesc =
+	go addonok allcmds $
+		findAddonCommand subcommandname >>= \case
+			Just c -> go addonok (c:allcmds) noop
+			Nothing -> go addonok allcmds $
+				findAllAddonCommands >>= \cs ->
+					go False (cs++allcmds) noop
+  where
+	go p allcmds' cont =
+		let (fuzzy, cmds) = selectCmd fuzzyok allcmds' subcommandname
+		in if not p || (not fuzzy && not (null cmds))
+			then dispatch' subcommandname args fuzzy cmds allargs allcmds' fields getgitrepo progname progdesc
+			else cont
+	
+	(subcommandname, args) = subCmdName allargs
+
+dispatch' :: (Maybe String) -> CmdParams -> Bool -> [Command] -> CmdParams -> [Command] -> [(String, String)] -> IO Git.Repo -> String -> String -> IO ()
+dispatch' subcommandname args fuzzy cmds allargs allcmds fields getgitrepo progname progdesc = do
+	setupConsole
+	go =<< tryNonAsync getgitrepo
+  where
+	go (Right g) = do
+		g' <- Git.Config.read g
+		(cmd, seek, annexsetter) <- parsewith False cmdparser
+			(\a -> a (Just g'))
+			O.handleParseResult
+		state <- applyAnnexReadSetter annexsetter <$> Annex.new g'
+		Annex.eval state $ do
+			checkEnvironment
+			forM_ fields $ uncurry Annex.setField
+			prepRunCommand cmd annexsetter
+			startup
+			performCommandAction True cmd seek $
+				quiesce $ cmdnocommit cmd
+	go (Left norepo) = do
+		let ingitrepo = \a -> a =<< Git.Config.global
+		-- Parse command line with full cmdparser first,
+		-- so that help can be displayed for bad parses
+		-- even when not run in a repo.
+		res <- parsewith False cmdparser ingitrepo return
+		case res of
+			Failure _ -> void (O.handleParseResult res)
+			_ -> do
+				-- Parse command line in norepo mode.
+				(_, a, _globalconfig) <- parsewith True
+					(fromMaybe (throw norepo) . cmdnorepo)
+					ingitrepo
+					O.handleParseResult
+				a
+
+	parsewith secondrun getparser ingitrepo handleresult =
+		case parseCmd progname progdesc allargs allcmds getparser of
+			O.Failure _ -> do
+				-- parse failed, so fall back to
+				-- fuzzy matching, or to showing usage
+				when (fuzzy && not secondrun) $
+					ingitrepo autocorrect
+				handleresult (parseCmd progname progdesc correctedargs allcmds getparser)
+			res -> handleresult res
+	  where
+		autocorrect = Git.AutoCorrect.prepare (fromJust subcommandname) cmdname cmds
+		name
+			| fuzzy = case cmds of
+				(c:_) -> Just (cmdname c)
+				_ -> subcommandname
+			| otherwise = subcommandname
+		correctedargs = case name of
+			Nothing -> allargs
+			Just n -> n:args
+
+{- Parses command line, selecting one of the commands from the list. -}
+parseCmd :: String -> String -> CmdParams -> [Command] -> (Command -> O.Parser v) -> O.ParserResult (Command, v, AnnexSetter)
+parseCmd progname progdesc allargs allcmds getparser = 
+	O.execParserPure (O.prefs O.idm) pinfo allargs
+  where
+	pinfo = O.info (O.helper <*> subcmds) (O.progDescDoc (Just intro))
+	subcmds = O.hsubparser $ mconcat $ map mkcommand allcmds
+	mkcommand c = O.command (cmdname c) $ O.info (mkparser c) $ O.fullDesc 
+		<> O.header (synopsis (progname ++ " " ++ cmdname c) (cmddesc c))
+		<> O.footer ("For details, run: " ++ progname ++ " help " ++ cmdname c)
+		<> cmdinfomod c
+	mkparser c = (,,) 
+		<$> pure c
+		<*> getparser c
+		<*> parserAnnexOptions (cmdannexoptions c)
+	synopsis n d = n ++ " - " ++ d
+	intro = mconcat $ concatMap (\l -> [H.pretty l, H.line])
+		(synopsis progname progdesc : commandList allcmds)
+
+{- Selects the Command that matches the subcommand name.
+ - Does fuzzy matching if necessary, which may result in multiple Commands. -}
+selectCmd :: Bool -> [Command] -> Maybe String -> (Bool, [Command])
+selectCmd fuzzyok cmds (Just n)
+	| not (null exactcmds) = (False, exactcmds)
+	| fuzzyok && not (null inexactcmds) = (True, inexactcmds)
+	| otherwise = (False, [])
+  where
+	exactcmds = filter (\c -> cmdname c == n) cmds
+	inexactcmds = Git.AutoCorrect.fuzzymatches n cmdname cmds
+selectCmd _ _ Nothing = (False, [])
+
+{- Parses command line params far enough to find the subcommand name. -}
+subCmdName :: CmdParams -> (Maybe String, CmdParams)
+subCmdName argv = (name, args)
+  where
+	(name, args) = findname argv []
+	findname [] c = (Nothing, reverse c)
+	findname (a:as) c
+		| "-" `isPrefixOf` a = findname as (a:c)
+		| otherwise = (Just a, reverse c ++ as)
+
+-- | Note that the AnnexSetter must have already had its annexReadSetter
+-- applied before entering the Annex monad to run this; that cannot be
+-- changed while running in the Annex monad.
+prepRunCommand :: Command -> AnnexSetter -> Annex ()
+prepRunCommand cmd annexsetter = do
+	when (cmdnomessages cmd) $
+		Annex.setOutput QuietOutput
+	annexStateSetter annexsetter
+	whenM (Annex.getRead Annex.debugenabled) $
+		enableDebugOutput
+
+findAddonCommand :: Maybe String -> IO (Maybe Command)
+findAddonCommand Nothing = return Nothing
+findAddonCommand (Just subcommandname) =
+	searchPath c >>= \case
+		Nothing -> return Nothing
+		Just p -> return (Just (mkAddonCommand p subcommandname))
+  where
+	c = "git-annex-" ++ subcommandname
+
+findAllAddonCommands :: IO [Command]
+findAllAddonCommands = 
+	filter isaddoncommand
+		. map (\p -> mkAddonCommand p (deprefix p))
+		<$> searchPathContents ("git-annex-" `isPrefixOf`)
+  where
+	deprefix = replace "git-annex-" "" . takeFileName
+	isaddoncommand c
+		-- git-annex-shell
+		| cmdname c == "shell" = False
+		-- external special remotes
+		| "remote-" `isPrefixOf` cmdname c = False
+		-- external backends
+		| "backend-" `isPrefixOf` cmdname c = False
+		| otherwise = True
+
+mkAddonCommand :: FilePath -> String -> Command
+mkAddonCommand p subcommandname = Command
+	{ cmdcheck = []
+	, cmdnocommit = True
+	, cmdnomessages = True
+	, cmdname = subcommandname
+	, cmdparamdesc = "[PARAMS]"
+	, cmdsection = SectionAddOn
+	, cmddesc = "addon command"
+	, cmdannexoptions = []
+	, cmdinfomod = O.forwardOptions
+	, cmdparser = parse
+	, cmdnorepo = Just parse
+	}
+  where
+	parse :: (Monad m, MonadIO m) => Parser (m ())
+	parse = (liftIO . run) <$> cmdParams "PARAMS"
+
+	run ps = withCreateProcess (proc p ps) $ \_ _ _ pid ->
+		exitWith =<< waitForProcess pid
diff --git a/CmdLine/Action.hs b/CmdLine/Action.hs
new file mode 100644
index 0000000000..b274065682
--- /dev/null
+++ b/CmdLine/Action.hs
@@ -0,0 +1,348 @@
+{- git-annex command-line actions and concurrency
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP, BangPatterns #-}
+
+module CmdLine.Action where
+
+import Annex.Common
+import qualified Annex
+import Annex.Concurrent
+import Annex.WorkerPool
+import Types.Command
+import Types.Concurrency
+import Annex.Content
+import Messages.Concurrent
+import Types.Messages
+import Types.WorkerPool
+import Types.ActionItem
+import Remote.List
+
+import Control.Concurrent
+import Control.Concurrent.Async
+import Control.Concurrent.STM
+import GHC.Conc
+import qualified Data.Map.Strict as M
+import qualified System.Console.Regions as Regions
+
+{- Runs a command, starting with the check stage, and then
+ - the seek stage. Finishes by running the continuation.
+ -
+ - Can exit when there was a problem or when a time or size limit was
+ - reached. Also shows a count of any failures when that is enabled.
+ -}
+performCommandAction :: Bool -> Command -> CommandSeek -> Annex () -> Annex ()
+performCommandAction canexit (Command { cmdcheck = c, cmdname = name }) seek cont = do
+	mapM_ runCheck c
+	Annex.changeState $ \s -> s { Annex.errcounter = 0 }
+	seek
+	finishCommandActions
+	cont
+	st <- Annex.getState id
+	when canexit $ liftIO $ case (Annex.errcounter st, Annex.reachedlimit st) of
+		(0, False) -> noop
+		(errcnt, False) -> do
+			showerrcount errcnt
+			exitWith $ ExitFailure 1
+		(0, True) -> exitreachedlimit
+		(errcnt, True) -> do
+			showerrcount errcnt
+			exitreachedlimit
+  where
+	showerrcount cnt = hPutStrLn stderr $
+		name ++ ": " ++ show cnt ++ " failed"
+	exitreachedlimit = exitWith $ ExitFailure 101
+
+commandActions :: [CommandStart] -> Annex ()
+commandActions = mapM_ commandAction
+
+{- Runs one of the actions needed to perform a command.
+ - Individual actions can fail without stopping the whole command,
+ - including by throwing non-async exceptions.
+ - 
+ - When concurrency is enabled, a thread is forked off to run the action
+ - in the background, as soon as a free worker slot is available.
+ 
+ - This should only be run in the seek stage.
+ -}
+commandAction :: CommandStart -> Annex ()
+commandAction start = do
+	st <- Annex.getState id
+	case getConcurrency' (Annex.concurrency st) of
+		NonConcurrent -> runnonconcurrent (Annex.sizelimit st)
+		Concurrent _ -> runconcurrent (Annex.sizelimit st) (Annex.workers st)
+		ConcurrentPerCpu -> runconcurrent (Annex.sizelimit st) (Annex.workers st)
+  where
+	runnonconcurrent sizelimit = start >>= \case
+		Nothing -> noop
+		Just (startmsg, perform) -> 
+			checkSizeLimit sizelimit startmsg $ do
+				showStartMessage startmsg
+				void $ accountCommandAction startmsg $
+					performCommandAction' startmsg perform
+
+	runconcurrent sizelimit Nothing = runnonconcurrent sizelimit
+	runconcurrent sizelimit (Just tv) = 
+		liftIO (atomically (waitStartWorkerSlot tv)) >>= maybe
+			(runnonconcurrent sizelimit)
+			(runconcurrent' sizelimit tv)
+	runconcurrent' sizelimit tv (workerstrd, workerstage) = do
+		aid <- liftIO $ async $ snd 
+			<$> Annex.run workerstrd
+				(concurrentjob sizelimit (fst workerstrd))
+		liftIO $ atomically $ do
+			pool <- takeTMVar tv
+			let !pool' = addWorkerPool (ActiveWorker aid workerstage) pool
+			putTMVar tv pool'
+		void $ liftIO $ forkIO $ debugLocks $ do
+			-- accountCommandAction will usually catch
+			-- exceptions. Just in case, fall back to the
+			-- original workerstrd.
+			workerstrd' <- either (const workerstrd) id
+				<$> waitCatch aid
+			atomically $ do
+				pool <- takeTMVar tv
+				let !pool' = deactivateWorker pool aid workerstrd'
+				putTMVar tv pool'
+	
+	concurrentjob sizelimit workerst = start >>= \case
+		Nothing -> noop
+		Just (startmsg, perform) ->
+			checkSizeLimit sizelimit startmsg $
+				concurrentjob' workerst startmsg perform
+	
+	concurrentjob' workerst startmsg perform = case mkActionItem startmsg of
+		OnlyActionOn k _ -> ensureOnlyActionOn k $
+			-- If another job performed the same action while we
+			-- waited, there may be nothing left to do, so re-run
+			-- the start stage to see if it still wants to do
+			-- something.
+			start >>= \case
+				Just (startmsg', perform') ->
+					case mkActionItem startmsg' of
+						OnlyActionOn k' _ | k' /= k ->
+							concurrentjob' workerst startmsg' perform'
+						_ -> beginjob workerst startmsg' perform'
+				Nothing -> noop
+		_ -> beginjob workerst startmsg perform
+	
+	beginjob workerst startmsg perform =
+		inOwnConsoleRegion (Annex.output workerst) $ do
+			enteringInitialStage
+			void $ accountCommandAction startmsg $
+				performconcurrent startmsg perform
+
+	-- Like performCommandAction' but the worker thread's stage
+	-- is changed before starting the cleanup action.
+	performconcurrent startmsg perform = do
+		showStartMessage startmsg
+		perform >>= \case
+			Just cleanup -> enteringStage CleanupStage $ do
+				r <- cleanup
+				showEndMessage startmsg r
+				return r
+			Nothing -> do
+				showEndMessage startmsg False
+				return False
+	
+{- Waits for all worker threads to finish and merges their AnnexStates
+ - back into the current Annex's state.
+ -}
+finishCommandActions :: Annex ()
+finishCommandActions = Annex.getState Annex.workers >>= \case
+	Nothing -> noop
+	Just tv -> do
+		Annex.changeState $ \s -> s { Annex.workers = Nothing }
+		vs <- liftIO $ atomically $ do
+			pool <- readTMVar tv
+			if allIdle pool
+				then return (spareVals pool)
+				else retry
+		mapM_ (mergeState . fst) vs
+
+{- Waits for all worker threads that have been started so far to finish. -}
+waitForAllRunningCommandActions :: Annex ()
+waitForAllRunningCommandActions = Annex.getState Annex.workers >>= \case
+	Nothing -> noop
+	Just tv -> liftIO $ atomically $ do
+		pool <- readTMVar tv
+		unless (allIdle pool)
+			retry
+
+{- Like commandAction, but without the concurrency. -}
+includeCommandAction :: CommandStart -> CommandCleanup
+includeCommandAction start =
+	start >>= \case
+		Nothing -> return True
+		Just (startmsg, perform) -> do
+			showStartMessage startmsg
+			accountCommandAction startmsg $
+				performCommandAction' startmsg perform
+
+accountCommandAction :: StartMessage -> CommandCleanup -> CommandCleanup
+accountCommandAction startmsg cleanup = tryNonAsync cleanup >>= \case
+	Right True -> return True
+	Right False -> incerr
+	Left err -> case fromException err of
+		Just exitcode -> liftIO $ exitWith exitcode
+		Nothing -> do
+			toplevelWarning True (UnquotedString (show err))
+			showEndMessage startmsg False
+			incerr
+  where
+	incerr = do
+		Annex.incError
+		return False
+
+{- Runs a single command action through the start, perform and cleanup
+ - stages, without catching errors and without incrementing error counter.
+ - Useful if one command wants to run part of another command. -}
+callCommandAction :: CommandStart -> CommandCleanup
+callCommandAction start = start >>= \case
+	Just (startmsg, perform) -> do
+		showStartMessage startmsg
+		performCommandAction' startmsg perform
+	Nothing -> return True
+
+performCommandAction' :: StartMessage -> CommandPerform -> CommandCleanup
+performCommandAction' startmsg perform = 
+	perform >>= \case
+		Nothing -> do
+			showEndMessage startmsg False
+			return False
+		Just cleanup -> do
+			r <- cleanup
+			showEndMessage startmsg r
+			return r
+
+{- Start concurrency when that has been requested.
+ - Should be run wrapping the seek stage of a command.
+ -
+ - Note that a duplicate of the Annex state is made here, and worker
+ - threads use that state. While the worker threads are not actually
+ - started here, that has the same effect.
+ -}
+startConcurrency :: UsedStages -> Annex a -> Annex a
+startConcurrency usedstages a = do
+	fromcmdline <- getConcurrency
+	fromgitcfg <- annexJobs <$> Annex.getGitConfig
+	let usegitcfg = setConcurrency (ConcurrencyGitConfig fromgitcfg)
+	case (fromcmdline, fromgitcfg) of
+		(NonConcurrent, NonConcurrent) -> a
+		(Concurrent n, _) 
+			| n > 1 -> goconcurrent n
+			| otherwise -> do
+				setConcurrency' NonConcurrent ConcurrencyCmdLine
+				a
+		(ConcurrentPerCpu, _) ->
+			goconcurrentpercpu
+		(NonConcurrent, Concurrent n) -> do
+			usegitcfg
+			goconcurrent n
+		(NonConcurrent, ConcurrentPerCpu) -> do
+			usegitcfg
+			goconcurrentpercpu
+  where
+	goconcurrent n = do
+		raisecapabilitiesto n
+		withMessageState $ \s -> case outputType s of
+			NormalOutput -> ifM (liftIO concurrentOutputSupported)
+				( Regions.displayConsoleRegions $
+					goconcurrent' n True
+				, goconcurrent' n False
+				)
+			_ -> goconcurrent' n False
+	goconcurrent' n b = bracket_ (setup n b) cleanup a
+
+	goconcurrentpercpu = goconcurrent =<< liftIO getNumProcessors
+
+	setup n b = do
+		setconcurrentoutputenabled b
+		initworkerpool n
+
+	cleanup = do
+		finishCommandActions
+		setconcurrentoutputenabled False
+
+	setconcurrentoutputenabled b = Annex.changeState $ \s ->
+		s { Annex.output = (Annex.output s) { concurrentOutputEnabled = b } }
+
+	raisecapabilitiesto n = do
+		c <- liftIO getNumCapabilities
+		when (n > c) $
+			liftIO $ setNumCapabilities n
+	
+	initworkerpool n = do
+		tv <- liftIO newEmptyTMVarIO
+		Annex.changeState $ \s -> s { Annex.workers = Just tv }
+		prepDupState
+		st <- dupState
+		rd <- Annex.getRead id
+		liftIO $ atomically $ putTMVar tv $
+			allocateWorkerPool (st, rd) (max n 1) usedstages
+
+-- Make sure that some expensive actions have been done before
+-- starting threads. This way the state has them already run,
+-- and each thread won't try to do them.
+prepDupState :: Annex ()
+prepDupState = do
+	_ <- remoteList
+	return ()
+
+{- Ensures that only one thread processes a key at a time.
+ - Other threads will block until it's done.
+ -
+ - May be called repeatedly by the same thread without blocking. -}
+ensureOnlyActionOn :: Key -> Annex a -> Annex a
+ensureOnlyActionOn k a = debugLocks $
+	go =<< getConcurrency
+  where
+	go NonConcurrent = a
+	go (Concurrent _) = goconcurrent
+	go ConcurrentPerCpu = goconcurrent
+	goconcurrent = do
+		tv <- Annex.getRead Annex.activekeys
+		bracket (setup tv) id (const a)
+	setup tv = liftIO $ do
+		mytid <- myThreadId
+		atomically $ do
+			m <- readTVar tv
+			case M.lookup k m of
+				Just tid
+					| tid /= mytid -> retry
+					| otherwise -> return $ return ()
+				Nothing -> do
+					writeTVar tv $! M.insert k mytid m
+					return $ liftIO $ atomically $
+						modifyTVar tv $ M.delete k
+
+checkSizeLimit :: Maybe (TVar Integer) -> StartMessage -> Annex () -> Annex ()
+checkSizeLimit Nothing _ a = a
+checkSizeLimit (Just sizelimitvar) startmsg a =
+	case actionItemKey (mkActionItem startmsg) of
+		Just k -> case fromKey keySize k of
+			Just sz -> go sz
+			Nothing -> do
+				fsz <- catchMaybeIO $ withObjectLoc k $
+					liftIO . getFileSize
+				maybe reachedlimit go fsz
+		Nothing -> a
+  where
+	go sz = do
+		fits <- liftIO $ atomically $ do
+			n <- readTVar sizelimitvar
+			let !n' = n - sz
+			if n' >= 0
+				then do
+					writeTVar sizelimitvar n'
+					return True
+				else return False
+		if fits 
+			then a
+			else reachedlimit
+	
+	reachedlimit = Annex.changeState $ \s -> s { Annex.reachedlimit = True }
diff --git a/CmdLine/AnnexSetter.hs b/CmdLine/AnnexSetter.hs
new file mode 100644
index 0000000000..234faf3abe
--- /dev/null
+++ b/CmdLine/AnnexSetter.hs
@@ -0,0 +1,36 @@
+{- git-annex options that are stored in Annex
+ -
+ - Copyright 2015-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+  -}
+  
+module CmdLine.AnnexSetter where
+
+import Common
+import Annex
+import Types.DeferredParse
+
+import Options.Applicative
+
+setAnnexState :: Annex () -> AnnexSetter
+setAnnexState a = AnnexSetter a id
+
+setAnnexRead :: (AnnexRead -> AnnexRead) -> AnnexSetter
+setAnnexRead f = AnnexSetter (return ()) f
+
+annexFlag :: AnnexSetter -> Mod FlagFields AnnexSetter -> AnnexOption
+annexFlag = flag'
+
+annexOption :: (v -> AnnexSetter) -> Parser v -> AnnexOption
+annexOption mk parser = mk <$> parser
+
+-- | Combines a bunch of AnnexOptions together into a Parser
+-- that returns a AnnexSetter that can be used to set all the options that
+-- are enabled.
+parserAnnexOptions :: [AnnexOption] -> Parser AnnexSetter
+parserAnnexOptions [] = pure mempty
+parserAnnexOptions l = mconcat <$> many (foldl1 (<|>) l)
+
+applyAnnexReadSetter :: AnnexSetter -> (AnnexState, AnnexRead) -> (AnnexState, AnnexRead)
+applyAnnexReadSetter gs (st, rd) = (st, annexReadSetter gs rd)
diff --git a/CmdLine/Batch.hs b/CmdLine/Batch.hs
new file mode 100644
index 0000000000..2a7924ab2b
--- /dev/null
+++ b/CmdLine/Batch.hs
@@ -0,0 +1,227 @@
+{- git-annex batch commands
+ -
+ - Copyright 2015-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module CmdLine.Batch where
+
+import Annex.Common
+import qualified Annex
+import Types.Command
+import CmdLine.Action
+import CmdLine.GitAnnex.Options
+import CmdLine.Seek
+import Options.Applicative
+import Limit
+import Types.FileMatcher
+import Annex.BranchState
+import Annex.WorkTree
+import Annex.Content
+import Annex.Concurrent
+import Types.Concurrency
+
+data BatchMode = Batch BatchFormat | NoBatch
+
+data BatchFormat = BatchFormat BatchSeparator BatchKeys
+
+data BatchSeparator = BatchLine | BatchNull
+
+newtype BatchKeys = BatchKeys Bool
+
+parseBatchOption :: Bool -> Parser BatchMode
+parseBatchOption supportbatchkeysoption = go 
+	<$> switch
+		( long "batch"
+		<> help batchhelp
+		)
+	<*> batchkeysswitch
+	<*> flag BatchLine BatchNull
+		( short 'z'
+		<> help "null delimited batch input"
+		)
+  where
+	go True False batchseparator = 
+		Batch (BatchFormat batchseparator (BatchKeys False))
+	go _ True batchseparator = 
+		Batch (BatchFormat batchseparator (BatchKeys True))
+	go _ _ _ = NoBatch
+
+	batchhelp = "enable batch mode" ++
+		if supportbatchkeysoption
+			then ", with files input"
+			else ""
+	batchkeyshelp = "enable batch mode, with keys input"
+
+	batchkeysswitch
+		| supportbatchkeysoption = switch
+			( long "batch-keys"
+			<> help batchkeyshelp
+			)
+		| otherwise = pure False
+
+-- A batchable command can run in batch mode, or not.
+-- In batch mode, one line at a time is read, parsed, and a reply output to
+-- stdout. In non batch mode, the command's parameters are parsed and
+-- a reply output for each.
+--
+-- Note that the actions are not run concurrently.
+batchable :: (opts -> SeekInput -> String -> Annex Bool) -> Parser opts -> CmdParamsDesc -> CommandParser
+batchable handler parser paramdesc = batchseeker <$> batchparser
+  where
+	batchparser = (,,)
+		<$> parser
+		<*> parseBatchOption False
+		<*> cmdParams paramdesc
+	
+	batchseeker (opts, NoBatch, params) =
+		mapM_ (\p -> go NoBatch opts (SeekInput [p], p)) params
+	batchseeker (opts, batchmode@(Batch fmt), params) = 
+		batchOnly Nothing params $
+			batchInput fmt (pure . Right) (go batchmode opts)
+
+	go batchmode opts (si, p) =
+		unlessM (handler opts si p) $
+			batchBadInput batchmode
+
+-- bad input is indicated by an empty line in batch mode. In non batch
+-- mode, exit on bad input.
+batchBadInput :: BatchMode -> Annex ()
+batchBadInput NoBatch = liftIO exitFailure
+batchBadInput _ = liftIO $ putStrLn ""
+
+-- Reads lines of batch mode input, runs a parser, and passes the result
+-- to the action.
+--
+-- Note that if the batch input includes a worktree filename, it should
+-- be converted to relative. Normally, filename parameters are passed
+-- through git ls-files, which makes them relative, but batch mode does
+-- not use that, and absolute worktree files are likely to cause breakage.
+batchInput :: BatchFormat -> (String -> Annex (Either String v)) -> ((SeekInput, v) -> Annex ()) -> Annex ()
+batchInput fmt parser a = go =<< batchLines fmt
+  where
+	go [] = return ()
+	go (l:rest) = do
+		either parseerr (\v -> a (SeekInput [l], v)) =<< parser l
+		go rest
+	parseerr s = giveup $ "Batch input parse failure: " ++ s
+
+batchLines :: BatchFormat -> Annex [String]
+batchLines (BatchFormat sep _) = do
+	checkBatchConcurrency
+	enableInteractiveBranchAccess
+	liftIO $ splitter <$> getContents
+  where
+	splitter = case sep of
+		BatchLine -> lines
+		BatchNull -> elimemptyend . splitc '\0'
+
+	-- When there is a trailing null on the input, eliminate the empty
+	-- string that splitc generates. Other empty strings elsewhere in
+	-- the list are preserved. This is the same effect as how `lines`
+	-- handles a trailing newline.
+	elimemptyend [] = []
+	elimemptyend (x:[])
+		| null x = []
+		| otherwise = [x]
+	elimemptyend (x:rest) = x : elimemptyend rest
+
+-- When concurrency is enabled at the command line, it is used in batch
+-- mode. But, if it's only set in git config, don't use it, because the
+-- program using batch mode may not expect interleaved output.
+checkBatchConcurrency :: Annex ()
+checkBatchConcurrency = Annex.getState Annex.concurrency >>= \case
+	ConcurrencyCmdLine _ -> noop
+	ConcurrencyGitConfig _ -> 
+		setConcurrency (ConcurrencyGitConfig (Concurrent 1))
+
+batchCommandAction :: CommandStart -> Annex ()
+batchCommandAction = commandAction . batchCommandStart
+
+-- The batch mode user expects to read a line of output, and it's up to the
+-- CommandStart to generate that output as it succeeds or fails to do its
+-- job. However, if it stops without doing anything, it won't generate
+-- any output. This modifies it so in that case, an empty line is printed.
+batchCommandStart :: CommandStart -> CommandStart
+batchCommandStart a = a >>= \case
+	Just v -> return (Just v)
+	Nothing -> do
+		batchBadInput (Batch (BatchFormat BatchLine (BatchKeys False)))
+		return Nothing
+
+-- Reads lines of batch input and passes the filepaths to a CommandStart
+-- to handle them.
+--
+-- File matching options are checked, and non-matching files skipped.
+batchFiles :: BatchFormat -> ((SeekInput, RawFilePath) -> CommandStart) -> Annex ()
+batchFiles fmt a = batchFilesKeys fmt $ \(si, v) -> case v of
+	Right f -> a (si, f)
+	Left _k -> return Nothing
+
+batchFilesKeys :: BatchFormat -> ((SeekInput, Either Key RawFilePath) -> CommandStart) -> Annex ()
+batchFilesKeys fmt a = do
+	matcher <- getMatcher
+	go $ \si v -> case v of
+		Right f -> 
+			ifM (matcher $ MatchingFile $ FileInfo f f Nothing)
+				( a (si, Right f)
+				, return Nothing
+				)
+		Left k -> a (si, Left k)
+  where
+	go a' = batchInput fmt parser (batchCommandAction . uncurry a')
+	parser = case fmt of
+		-- Absolute filepaths are converted to relative,
+		-- because in non-batch mode, that is done when
+		-- CmdLine.Seek uses git ls-files.
+		BatchFormat _ (BatchKeys False) -> 
+			Right . Right
+				<$$> liftIO . relPathCwdToFile . toRawFilePath
+		BatchFormat _ (BatchKeys True) -> \i ->
+			pure $ case deserializeKey i of
+				Just k -> Right (Left k)
+				Nothing -> Left "not a valid key"
+
+batchAnnexedFiles :: BatchFormat -> AnnexedFileSeeker -> Annex ()
+batchAnnexedFiles fmt seeker = batchAnnexed fmt seeker (const (return Nothing))
+
+-- Reads lines of batch input and passes filepaths to the AnnexedFileSeeker
+-- to handle them. Or, with --batch-keys, passes keys to the keyaction.
+--
+-- Matching options are checked, and non-matching items skipped.
+batchAnnexed :: BatchFormat -> AnnexedFileSeeker -> ((SeekInput, Key, ActionItem) -> CommandStart) -> Annex ()
+batchAnnexed fmt seeker keyaction = do
+	matcher <- getMatcher
+	batchFilesKeys fmt $ \(si, v) ->
+		case v of
+			Right f -> lookupKeyStaged f >>= \case
+				Nothing -> return Nothing
+				Just k -> checkpresent k $
+					startAction seeker Nothing si f k
+			Left k -> ifM (matcher (MatchingInfo (mkinfo k)))
+				( checkpresent k $
+					keyaction (si, k, mkActionItem k)
+				, return Nothing)
+  where
+	checkpresent k cont = case checkContentPresent seeker of
+		Just v -> do
+			present <- inAnnex k
+			if present == v
+				then cont
+				else return Nothing
+		Nothing -> cont
+	
+	mkinfo k = ProvidedInfo
+		{ providedFilePath = Nothing
+		, providedKey = Just k
+		, providedFileSize = Nothing
+		, providedMimeType = Nothing
+		, providedMimeEncoding = Nothing
+		, providedLinkType = Nothing
+		}
+
+batchOnly :: Maybe KeyOptions -> CmdParams -> Annex () -> Annex ()
+batchOnly Nothing [] a = a
+batchOnly _ _ _ = giveup "Cannot combine batch option with file or key options"
+
diff --git a/CmdLine/GitAnnex.hs b/CmdLine/GitAnnex.hs
new file mode 100644
index 0000000000..debf30fffd
--- /dev/null
+++ b/CmdLine/GitAnnex.hs
@@ -0,0 +1,282 @@
+{- git-annex main program
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP, OverloadedStrings #-}
+
+module CmdLine.GitAnnex where
+
+import qualified Git.CurrentRepo
+import CmdLine
+import Command
+import Utility.Env
+import Annex.Ssh
+import Annex.Multicast
+import Types.Test
+import Types.Benchmark
+
+import qualified Command.Help
+import qualified Command.Add
+import qualified Command.Unannex
+import qualified Command.Drop
+import qualified Command.Move
+import qualified Command.Copy
+import qualified Command.Get
+import qualified Command.Fsck
+import qualified Command.LookupKey
+import qualified Command.CalcKey
+import qualified Command.ContentLocation
+import qualified Command.ExamineKey
+import qualified Command.MatchExpression
+import qualified Command.FromKey
+import qualified Command.RegisterUrl
+import qualified Command.UnregisterUrl
+import qualified Command.ReregisterUrl
+import qualified Command.SetKey
+import qualified Command.DropKey
+import qualified Command.Transferrer
+import qualified Command.TransferKey
+import qualified Command.TransferKeys
+import qualified Command.SetPresentKey
+import qualified Command.ReadPresentKey
+import qualified Command.CheckPresentKey
+import qualified Command.ReKey
+import qualified Command.Adjust
+import qualified Command.MetaData
+import qualified Command.View
+import qualified Command.VAdd
+import qualified Command.VFilter
+import qualified Command.VPop
+import qualified Command.VCycle
+import qualified Command.Reinject
+import qualified Command.Fix
+import qualified Command.Init
+import qualified Command.Describe
+import qualified Command.InitRemote
+import qualified Command.EnableRemote
+import qualified Command.ConfigRemote
+import qualified Command.RenameRemote
+import qualified Command.EnableTor
+import qualified Command.Multicast
+import qualified Command.Expire
+import qualified Command.Repair
+import qualified Command.Unused
+import qualified Command.DropUnused
+import qualified Command.AddUnused
+import qualified Command.Unlock
+import qualified Command.Lock
+import qualified Command.PreCommit
+import qualified Command.PostReceive
+import qualified Command.FilterBranch
+import qualified Command.Find
+import qualified Command.FindKeys
+import qualified Command.FindRef
+import qualified Command.Whereis
+import qualified Command.WhereUsed
+import qualified Command.List
+import qualified Command.Log
+import qualified Command.Merge
+import qualified Command.ResolveMerge
+import qualified Command.Info
+import qualified Command.Status
+import qualified Command.Inprogress
+import qualified Command.Migrate
+import qualified Command.Uninit
+import qualified Command.Reinit
+import qualified Command.NumCopies
+import qualified Command.MinCopies
+import qualified Command.Trust
+import qualified Command.Untrust
+import qualified Command.Semitrust
+import qualified Command.Dead
+import qualified Command.Group
+import qualified Command.Wanted
+import qualified Command.GroupWanted
+import qualified Command.Required
+import qualified Command.Schedule
+import qualified Command.Ungroup
+import qualified Command.Config
+import qualified Command.Vicfg
+import qualified Command.Sync
+import qualified Command.Assist
+import qualified Command.Pull
+import qualified Command.Push
+import qualified Command.Satisfy
+import qualified Command.Mirror
+import qualified Command.AddUrl
+import qualified Command.ImportFeed
+import qualified Command.RmUrl
+import qualified Command.Import
+import qualified Command.Export
+import qualified Command.Map
+import qualified Command.Direct
+import qualified Command.Indirect
+import qualified Command.Upgrade
+import qualified Command.Forget
+import qualified Command.OldKeys
+import qualified Command.P2P
+import qualified Command.Proxy
+import qualified Command.DiffDriver
+import qualified Command.Smudge
+import qualified Command.FilterProcess
+import qualified Command.Restage
+import qualified Command.Undo
+import qualified Command.Version
+import qualified Command.RemoteDaemon
+#ifdef WITH_ASSISTANT
+import qualified Command.Watch
+import qualified Command.Assistant
+#ifdef WITH_WEBAPP
+import qualified Command.WebApp
+#endif
+#endif
+import qualified Command.Test
+import qualified Command.FuzzTest
+import qualified Command.TestRemote
+import qualified Command.Benchmark
+
+cmds :: Parser TestOptions -> TestRunner -> MkBenchmarkGenerator -> [Command]
+cmds testoptparser testrunner mkbenchmarkgenerator = map addGitAnnexCommonOptions $
+	[ Command.Help.cmd
+	, Command.Add.cmd
+	, Command.Get.cmd
+	, Command.Drop.cmd
+	, Command.Move.cmd
+	, Command.Copy.cmd
+	, Command.Fsck.cmd
+	, Command.Unlock.cmd
+	, Command.Unlock.editcmd
+	, Command.Lock.cmd
+	, Command.Sync.cmd
+	, Command.Assist.cmd
+	, Command.Pull.cmd
+	, Command.Push.cmd
+	, Command.Satisfy.cmd
+	, Command.Mirror.cmd
+	, Command.AddUrl.cmd
+	, Command.ImportFeed.cmd
+	, Command.RmUrl.cmd
+	, Command.Import.cmd
+	, Command.Export.cmd
+	, Command.Init.cmd
+	, Command.Describe.cmd
+	, Command.InitRemote.cmd
+	, Command.EnableRemote.cmd
+	, Command.ConfigRemote.cmd
+	, Command.RenameRemote.cmd
+	, Command.EnableTor.cmd
+	, Command.Multicast.cmd
+	, Command.Reinject.cmd
+	, Command.Unannex.cmd
+	, Command.Uninit.cmd
+	, Command.Reinit.cmd
+	, Command.PreCommit.cmd
+	, Command.PostReceive.cmd
+	, Command.NumCopies.cmd
+	, Command.MinCopies.cmd
+	, Command.Trust.cmd
+	, Command.Untrust.cmd
+	, Command.Semitrust.cmd
+	, Command.Dead.cmd
+	, Command.Group.cmd
+	, Command.Wanted.cmd
+	, Command.GroupWanted.cmd
+	, Command.Required.cmd
+	, Command.Schedule.cmd
+	, Command.Ungroup.cmd
+	, Command.Config.cmd
+	, Command.Vicfg.cmd
+	, Command.LookupKey.cmd
+	, Command.CalcKey.cmd
+	, Command.ContentLocation.cmd
+	, Command.ExamineKey.cmd
+	, Command.MatchExpression.cmd
+	, Command.FromKey.cmd
+	, Command.RegisterUrl.cmd
+	, Command.UnregisterUrl.cmd
+	, Command.ReregisterUrl.cmd
+	, Command.SetKey.cmd
+	, Command.DropKey.cmd
+	, Command.Transferrer.cmd
+	, Command.TransferKey.cmd
+	, Command.TransferKeys.cmd
+	, Command.SetPresentKey.cmd
+	, Command.ReadPresentKey.cmd
+	, Command.CheckPresentKey.cmd
+	, Command.ReKey.cmd
+	, Command.Adjust.cmd
+	, Command.MetaData.cmd
+	, Command.View.cmd
+	, Command.VAdd.cmd
+	, Command.VFilter.cmd
+	, Command.VPop.cmd
+	, Command.VCycle.cmd
+	, Command.Fix.cmd
+	, Command.Expire.cmd
+	, Command.Repair.cmd
+	, Command.Unused.cmd
+	, Command.DropUnused.cmd
+	, Command.AddUnused.cmd
+	, Command.FilterBranch.cmd
+	, Command.Find.cmd
+	, Command.FindKeys.cmd
+	, Command.FindRef.cmd
+	, Command.Whereis.cmd
+	, Command.WhereUsed.cmd
+	, Command.List.cmd
+	, Command.Log.cmd
+	, Command.Merge.cmd
+	, Command.ResolveMerge.cmd
+	, Command.Info.cmd
+	, Command.Status.cmd
+	, Command.Inprogress.cmd
+	, Command.Migrate.cmd
+	, Command.Map.cmd
+	, Command.Direct.cmd
+	, Command.Indirect.cmd
+	, Command.Upgrade.cmd
+	, Command.Forget.cmd
+	, Command.OldKeys.cmd
+	, Command.P2P.cmd
+	, Command.Proxy.cmd
+	, Command.DiffDriver.cmd
+	, Command.Smudge.cmd
+	, Command.FilterProcess.cmd
+	, Command.Restage.cmd
+	, Command.Undo.cmd
+	, Command.Version.cmd
+	, Command.RemoteDaemon.cmd
+#ifdef WITH_ASSISTANT
+	, Command.Watch.cmd
+	, Command.Assistant.cmd
+#ifdef WITH_WEBAPP
+	, Command.WebApp.cmd
+#endif
+#endif
+	, Command.Test.cmd testoptparser testrunner
+	, Command.FuzzTest.cmd
+	, Command.TestRemote.cmd
+	, Command.Benchmark.cmd $
+		mkbenchmarkgenerator $ cmds testoptparser testrunner (\_ _ -> return noop)
+	]
+
+addGitAnnexCommonOptions :: Command -> Command
+addGitAnnexCommonOptions c = c { cmdannexoptions = gitAnnexCommonOptions ++ cmdannexoptions c }
+
+run :: Parser TestOptions -> TestRunner -> MkBenchmarkGenerator -> [String] -> IO ()
+run testoptparser testrunner mkbenchmarkgenerator args = go envmodes
+  where
+	go [] = dispatch True True args 
+		(cmds testoptparser testrunner mkbenchmarkgenerator)
+		[] Git.CurrentRepo.get
+		"git-annex"
+		"manage files with git, without checking their contents in"
+	go ((v, a):rest) = maybe (go rest) a =<< getEnv v
+	envmodes =
+		[ (sshOptionsEnv, runSshOptions args)
+		, (sshAskPassEnv, runSshAskPass)
+		, (multicastReceiveEnv, runMulticastReceive args)
+		]
diff --git a/CmdLine/GitAnnex/Options.hs b/CmdLine/GitAnnex/Options.hs
new file mode 100644
index 0000000000..ed6bca99c7
--- /dev/null
+++ b/CmdLine/GitAnnex/Options.hs
@@ -0,0 +1,582 @@
+{- git-annex command-line option parsing
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeSynonymInstances, FlexibleInstances, OverloadedStrings #-}
+
+module CmdLine.GitAnnex.Options where
+
+import Control.Monad.Fail as Fail (MonadFail(..))
+import Options.Applicative
+import Data.Time.Clock.POSIX
+import Control.Concurrent.STM
+import qualified Data.Map as M
+
+import Annex.Common
+import qualified Git.Config
+import qualified Git.Construct
+import Git.Remote
+import Git.Types
+import Types.Key
+import Types.TrustLevel
+import Types.NumCopies
+import Types.Messages
+import Types.Command
+import Types.DeferredParse
+import Types.DesktopNotify
+import Types.Concurrency
+import qualified Annex
+import qualified Remote
+import qualified Limit
+import qualified Limit.Wanted
+import CmdLine.Option
+import CmdLine.Usage
+import CmdLine.AnnexSetter
+import qualified Backend
+import qualified Types.Backend as Backend
+import Utility.HumanTime
+import Utility.DataUnits
+import Annex.Concurrent
+
+-- Options that are accepted by all git-annex sub-commands,
+-- although not always used.
+gitAnnexCommonOptions :: [AnnexOption]
+gitAnnexCommonOptions = commonOptions ++
+	[ annexOption setnumcopies $ option auto
+		( long "numcopies" <> short 'N' <> metavar paramNumber
+		<> help "override desired number of copies"
+		<> hidden
+		)
+	, annexOption setmincopies $ option auto
+		( long "mincopies" <> short 'N' <> metavar paramNumber
+		<> help "override minimum number of copies"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Remote.forceTrust Trusted) $ strOption
+		( long "trust" <> metavar paramRemote
+		<> help "deprecated, does not override trust setting"
+		<> hidden
+		<> completeRemotes
+		)
+	, annexOption (setAnnexState . Remote.forceTrust SemiTrusted) $ strOption
+		( long "semitrust" <> metavar paramRemote
+		<> help "override trust setting back to default"
+		<> hidden
+		<> completeRemotes
+		)
+	, annexOption (setAnnexState . Remote.forceTrust UnTrusted) $ strOption
+		( long "untrust" <> metavar paramRemote
+		<> help "override trust setting to untrusted"
+		<> hidden
+		<> completeRemotes
+		)
+	, annexOption (setAnnexState . setgitconfig) $ strOption
+		( long "config" <> short 'c' <> metavar "NAME=VALUE"
+		<> help "override git configuration setting"
+		<> hidden
+		)
+	, annexOption setuseragent $ strOption
+		( long "user-agent" <> metavar paramName
+		<> help "override default User-Agent"
+		<> hidden
+		)
+	, annexFlag (setAnnexState $ toplevelWarning False "--trust-glacier no longer has any effect")
+		( long "trust-glacier"
+		<> help "deprecated, does not trust Amazon Glacier inventory"
+		<> hidden
+		)
+	, annexFlag (setdesktopnotify mkNotifyFinish)
+		( long "notify-finish"
+		<> help "show desktop notification after transfer finishes"
+		<> hidden
+		)
+	, annexFlag (setdesktopnotify mkNotifyStart)
+		( long "notify-start"
+		<> help "show desktop notification after transfer starts"
+		<> hidden
+		)
+	]
+  where
+	setnumcopies n = setAnnexRead $ \rd -> rd { Annex.forcenumcopies = Just $ configuredNumCopies n }
+	setmincopies n = setAnnexRead $ \rd -> rd { Annex.forcemincopies = Just $ configuredMinCopies n }
+	setuseragent v = setAnnexRead $ \rd -> rd { Annex.useragent = Just v }
+	setdesktopnotify v = setAnnexRead $ \rd -> rd { Annex.desktopnotify = Annex.desktopnotify rd <> v }
+	setgitconfig v = Annex.addGitConfigOverride v
+
+{- Parser that accepts all non-option params. -}
+cmdParams :: CmdParamsDesc -> Parser CmdParams
+cmdParams paramdesc = many $ argument str
+	( metavar paramdesc
+	<> action "file"
+	)
+
+parseAutoOption :: Parser Bool
+parseAutoOption = switch
+	( long "auto" <> short 'a'
+	<> help "automatic mode"
+	)
+
+mkParseRemoteOption :: RemoteName -> DeferredParse Remote
+mkParseRemoteOption = DeferredParse 
+	. (fromJust <$$> Remote.byNameWithUUID)
+	. Just
+
+parseUUIDOption :: String -> DeferredParse UUID
+parseUUIDOption = DeferredParse
+	. (Remote.nameToUUID)
+
+parseDryRunOption :: Parser DryRun
+parseDryRunOption = DryRun <$> switch
+	( long "dry-run"
+	<> help "don't make changes, but show what would be done"
+	)
+
+-- | From or To a remote but not both.
+data FromToOptions
+	= FromRemote (DeferredParse Remote)
+	| ToRemote (DeferredParse Remote)
+
+instance DeferredParseClass FromToOptions where
+	finishParse (FromRemote v) = FromRemote <$> finishParse v
+	finishParse (ToRemote v) = ToRemote <$> finishParse v
+
+parseFromToOptions :: Parser FromToOptions
+parseFromToOptions = 
+	(FromRemote . mkParseRemoteOption <$> parseFromOption) 
+	<|> (ToRemote . mkParseRemoteOption <$> parseToOption)
+
+parseFromOption :: Parser RemoteName
+parseFromOption = strOption
+	( long "from" <> short 'f' <> metavar paramRemote
+	<> help "source remote"
+	<> completeRemotes
+	)
+
+parseToOption :: Parser RemoteName
+parseToOption = strOption
+	( long "to" <> short 't' <> metavar paramRemote
+	<> help "destination remote"
+	<> completeRemotes
+	)
+
+parseFromAnywhereOption :: Parser Bool
+parseFromAnywhereOption = switch
+	( long "from-anywhere"
+	<> help "from any remote"
+	)
+
+parseRemoteOption :: Parser RemoteName
+parseRemoteOption = strOption
+	( long "remote" <> metavar paramRemote
+	<> completeRemotes
+	)
+
+-- | --from or --to a remote, or both, or a special --to=here,
+-- or --from-anywhere --to remote.
+data FromToHereOptions 
+	= FromOrToRemote FromToOptions
+	| ToHere
+	| FromRemoteToRemote (DeferredParse Remote) (DeferredParse Remote)
+	| FromAnywhereToRemote (DeferredParse Remote)
+
+parseFromToHereOptions :: Parser (Maybe FromToHereOptions)
+parseFromToHereOptions = go
+	<$> optional parseFromOption
+	<*> optional parseToOption
+	<*> parseFromAnywhereOption
+  where
+	go _ (Just to) True = Just $ FromAnywhereToRemote
+		(mkParseRemoteOption to)
+	go (Just from) (Just to) _ = Just $ FromRemoteToRemote
+		(mkParseRemoteOption from)
+		(mkParseRemoteOption to)
+	go (Just from) Nothing _ = Just $ FromOrToRemote
+		(FromRemote $ mkParseRemoteOption from)
+	go Nothing (Just to) _ = Just $ case to of
+		"here" -> ToHere
+		"." -> ToHere
+		_ -> FromOrToRemote $ ToRemote $ mkParseRemoteOption to
+	go Nothing Nothing _ = Nothing
+
+instance DeferredParseClass FromToHereOptions where
+	finishParse (FromOrToRemote v) = 
+		FromOrToRemote <$> finishParse v
+	finishParse ToHere = pure ToHere
+	finishParse (FromRemoteToRemote v1 v2) = 
+		FromRemoteToRemote
+			<$> finishParse v1
+			<*> finishParse v2
+	finishParse (FromAnywhereToRemote v) = 
+		FromAnywhereToRemote <$> finishParse v
+
+-- Options for acting on keys, rather than work tree files.
+data KeyOptions
+	= WantAllKeys
+	| WantUnusedKeys
+	| WantFailedTransfers
+	| WantSpecificKey Key
+	| WantIncompleteKeys
+	| WantBranchKeys [Branch]
+
+parseKeyOptions :: Parser KeyOptions
+parseKeyOptions = parseAllOption
+	<|> parseBranchKeysOption
+	<|> parseUnusedKeysOption
+	<|> parseSpecificKeyOption
+
+parseUnusedKeysOption :: Parser KeyOptions
+parseUnusedKeysOption = flag' WantUnusedKeys
+	( long "unused" <> short 'U'
+	<> help "operate on files found by last run of git-annex unused"
+	)
+
+parseSpecificKeyOption :: Parser KeyOptions
+parseSpecificKeyOption = WantSpecificKey <$> option (str >>= parseKey)
+	( long "key" <> metavar paramKey
+	<> help "operate on specified key"
+	)
+
+parseBranchKeysOption :: Parser KeyOptions
+parseBranchKeysOption = WantBranchKeys <$> some (option (str >>= pure . Ref)
+	( long "branch" <> metavar paramRef
+	<> help "operate on files in the specified branch or treeish"
+	))
+
+parseFailedTransfersOption :: Parser KeyOptions
+parseFailedTransfersOption = flag' WantFailedTransfers
+	( long "failed"
+	<> help "operate on files that recently failed to be transferred"
+	)
+
+parseIncompleteOption :: Parser KeyOptions
+parseIncompleteOption = flag' WantIncompleteKeys
+	( long "incomplete"
+	<> help "resume previous downloads"
+	)
+
+parseAllOption :: Parser KeyOptions
+parseAllOption = flag' WantAllKeys
+	( long "all" <> short 'A'
+	<> help "operate on all versions of all files"
+	)
+
+parseKey :: MonadFail m => String -> m Key
+parseKey = maybe (Fail.fail "invalid key") return . deserializeKey
+
+-- Options to match properties of annexed files.
+annexedMatchingOptions :: [AnnexOption]
+annexedMatchingOptions = concat
+	[ keyMatchingOptions'
+	, fileMatchingOptions' Limit.LimitAnnexFiles
+	, anythingNothingOptions
+	, combiningOptions
+	, timeLimitOption
+	, sizeLimitOption
+	]
+
+-- Options to match properties of keys.
+keyMatchingOptions :: [AnnexOption]
+keyMatchingOptions = concat
+	[ keyMatchingOptions'
+	, sizeMatchingOptions Limit.LimitAnnexFiles
+	, anythingNothingOptions
+	, combiningOptions 
+	, timeLimitOption 
+	, sizeLimitOption
+	]
+
+-- Matching options that can operate on keys as well as files.
+keyMatchingOptions' :: [AnnexOption]
+keyMatchingOptions' = 
+	[ annexOption (setAnnexState . Limit.addIn) $ strOption
+		( long "in" <> short 'i' <> metavar paramRemote
+		<> help "match files present in a repository"
+		<> hidden
+		<> completeRemotes
+		)
+	, annexOption (setAnnexState . Limit.addCopies) $ strOption
+		( long "copies" <> short 'C' <> metavar paramNumber
+		<> help "skip files with fewer copies"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.addLackingCopies "lackingcopies" False) $ strOption
+		( long "lackingcopies" <> metavar paramNumber
+		<> help "match files that need more copies"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.addLackingCopies "approxlackingcopies" True) $ strOption
+		( long "approxlackingcopies" <> metavar paramNumber
+		<> help "match files that need more copies (faster)"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.addInBackend) $ strOption
+		( long "inbackend" <> short 'B' <> metavar paramName
+		<> help "match files using a key-value backend"
+		<> hidden
+		<> completeBackends
+		)
+	, annexFlag (setAnnexState Limit.addSecureHash)
+		( long "securehash"
+		<> help "match files using a cryptographically secure hash"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.addInAllGroup) $ strOption
+		( long "inallgroup" <> metavar paramGroup
+		<> help "match files present in all repositories in a group"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.addOnlyInGroup) $ strOption
+		( long "onlyingroup" <> metavar paramGroup
+		<> help "match files that are only present in repositories in the group"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.addMetaData) $ strOption
+		( long "metadata" <> metavar "FIELD=VALUE"
+		<> help "match files with attached metadata"
+		<> hidden
+		)
+	, annexFlag (setAnnexState Limit.Wanted.addWantGet)
+		( long "want-get"
+		<> help "match files the local repository wants to get"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.Wanted.addWantGetBy) $ strOption
+		( long "want-get-by" <> metavar paramRemote
+		<> help "match files the specified repository wants to get"
+		<> hidden
+		<> completeRemotes
+		)
+	, annexFlag (setAnnexState Limit.Wanted.addWantDrop)
+		( long "want-drop"
+		<> help "match files the local repository wants to drop"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.Wanted.addWantDropBy) $ strOption
+		( long "want-drop-by" <> metavar paramRemote
+		<> help "match files the specified repository wants to drop"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.addAccessedWithin) $
+		option (eitherReader parseDuration)
+			( long "accessedwithin"
+			<> metavar paramTime
+			<> help "match files accessed within a time interval"
+			<> hidden
+			)
+	, annexOption (setAnnexState . Limit.addMimeType) $ strOption
+		( long "mimetype" <> metavar paramGlob
+		<> help "match files by mime type"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.addMimeEncoding) $ strOption
+		( long "mimeencoding" <> metavar paramGlob
+		<> help "match files by mime encoding"
+		<> hidden
+		)
+	, annexFlag (setAnnexState Limit.addUnlocked)
+		( long "unlocked"
+		<> help "match files that are unlocked"
+		<> hidden
+		)
+	, annexFlag (setAnnexState Limit.addLocked)
+		( long "locked"
+		<> help "match files that are locked"
+		<> hidden
+		)
+	, annexFlag (setAnnexState Limit.addExpectedPresent)
+		( long "expected-present"
+		<> help "match files expected to be present"
+		<> hidden
+		)
+	]
+
+-- Options to match files which may not yet be annexed.
+fileMatchingOptions :: Limit.LimitBy -> [AnnexOption]
+fileMatchingOptions lb = fileMatchingOptions' lb ++ combiningOptions ++ timeLimitOption
+
+fileMatchingOptions' :: Limit.LimitBy -> [AnnexOption]
+fileMatchingOptions' lb =
+	[ annexOption (setAnnexState . Limit.addExclude) $ strOption
+		( long "exclude" <> short 'x' <> metavar paramGlob
+		<> help "skip files matching the glob pattern"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.addInclude) $ strOption
+		( long "include" <> short 'I' <> metavar paramGlob
+		<> help "limit to files matching the glob pattern"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.addExcludeSameContent) $ strOption
+		( long "excludesamecontent" <> short 'x' <> metavar paramGlob
+		<> help "skip files whose content is the same as another file matching the glob pattern"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.addIncludeSameContent) $ strOption
+		( long "includesamecontent" <> short 'I' <> metavar paramGlob
+		<> help "limit to files whose content is the same as another file matching the glob pattern"
+		<> hidden
+		)
+	] ++ sizeMatchingOptions lb
+
+sizeMatchingOptions :: Limit.LimitBy -> [AnnexOption]
+sizeMatchingOptions lb =
+	[ annexOption (setAnnexState . Limit.addLargerThan lb) $ strOption
+		( long "largerthan" <> metavar paramSize
+		<> help "match files larger than a size"
+		<> hidden
+		)
+	, annexOption (setAnnexState . Limit.addSmallerThan lb) $ strOption
+		( long "smallerthan" <> metavar paramSize
+		<> help "match files smaller than a size"
+		<> hidden
+		)
+	]
+
+anythingNothingOptions :: [AnnexOption]
+anythingNothingOptions =
+	[ annexFlag (setAnnexState Limit.addAnything)
+		( long "anything"
+		<> help "match all files"
+		<> hidden
+		)
+	, annexFlag (setAnnexState Limit.addNothing)
+		( long "nothing"
+		<> help "don't match any files"
+		<> hidden
+		)
+	]
+
+combiningOptions :: [AnnexOption]
+combiningOptions = 
+	[ longopt "not" "negate next option"
+	, longopt "and" "both previous and next option must match"
+	, longopt "or" "either previous or next option must match"
+	, shortopt '(' "open group of options"
+	, shortopt ')' "close group of options"
+	]
+  where
+	longopt o h = annexFlag (setAnnexState $ Limit.addSyntaxToken o)
+		( long o <> help h <> hidden )
+	shortopt o h = annexFlag (setAnnexState $ Limit.addSyntaxToken [o])
+		( short o <> help h <> hidden )
+
+jsonOptions :: [AnnexOption]
+jsonOptions = 
+	[ annexFlag (setAnnexState $ Annex.setOutput (JSONOutput stdjsonoptions))
+		( long "json" <> short 'j'
+		<> help "enable JSON output"
+		<> hidden
+		)
+	, annexFlag (setAnnexState $ Annex.setOutput (JSONOutput jsonerrormessagesoptions))
+		( long "json-error-messages"
+		<> help "include error messages in JSON"
+		<> hidden
+		)
+	]
+  where
+	stdjsonoptions = JSONOptions
+		{ jsonProgress = False
+		, jsonErrorMessages = False
+		}
+	jsonerrormessagesoptions = stdjsonoptions { jsonErrorMessages = True }
+
+jsonProgressOption :: [AnnexOption]
+jsonProgressOption = 
+	[ annexFlag (setAnnexState $ Annex.setOutput (JSONOutput jsonoptions))
+		( long "json-progress"
+		<> help "include progress in JSON output"
+		<> hidden
+		)
+	]
+  where
+	jsonoptions = JSONOptions
+		{ jsonProgress = True
+		, jsonErrorMessages = False
+		}
+
+-- Note that a command that adds this option should wrap its seek
+-- action in `allowConcurrentOutput`.
+jobsOption :: [AnnexOption]
+jobsOption = 
+	[ annexOption (setAnnexState . setConcurrency . ConcurrencyCmdLine) $ 
+		option (maybeReader parseConcurrency)
+			( long "jobs" <> short 'J' 
+			<> metavar (paramNumber `paramOr` "cpus")
+			<> help "enable concurrent jobs"
+			<> hidden
+			)
+	]
+
+timeLimitOption :: [AnnexOption]
+timeLimitOption = 
+	[ annexOption settimelimit $ option (eitherReader parseDuration)
+		( long "time-limit" <> short 'T' <> metavar paramTime
+		<> help "stop after the specified amount of time"
+		<> hidden
+		)
+	]
+  where
+	settimelimit duration = setAnnexState $ do
+		start <- liftIO getPOSIXTime
+		let cutoff = start + durationToPOSIXTime duration
+		Annex.changeState $ \s -> s { Annex.timelimit = Just (duration, cutoff) }
+
+sizeLimitOption :: [AnnexOption]
+sizeLimitOption =
+	[ annexOption setsizelimit $ option (maybeReader (readSize dataUnits))
+		( long "size-limit" <> metavar paramSize
+		<> help "total size of annexed files to process"
+		<> hidden
+		)
+	]
+  where
+	setsizelimit n = setAnnexState $ do
+		v <- liftIO $ newTVarIO n
+		Annex.changeState $ \s -> s { Annex.sizelimit = Just v }
+	
+backendOption :: [AnnexOption]
+backendOption = 
+	[ annexOption setforcebackend $ strOption
+		( long "backend" <> short 'b' <> metavar paramName
+		<> help "specify key-value backend to use"
+		<> hidden
+		)
+	]
+  where
+	setforcebackend v = setAnnexRead $ 
+		\rd -> rd { Annex.forcebackend = Just v }
+
+data DaemonOptions = DaemonOptions
+	{ foregroundDaemonOption :: Bool
+	, stopDaemonOption :: Bool
+	}
+
+parseDaemonOptions :: Bool -> Parser DaemonOptions
+parseDaemonOptions canstop
+	| canstop = DaemonOptions <$> foreground <*> stop
+	| otherwise = DaemonOptions <$> foreground <*> pure False
+  where
+	foreground = switch
+		( long "foreground"
+		<> help "do not daemonize"
+		)
+	stop = switch
+		( long "stop"
+		<> help "stop daemon"
+		)
+
+completeRemotes :: HasCompleter f => Mod f a
+completeRemotes = completer $ mkCompleter $ \input -> do
+	r <- maybe (pure Nothing) (Just <$$> Git.Config.read)
+		=<< Git.Construct.fromCwd
+	return $ filter (input `isPrefixOf`) $
+		mapMaybe remoteKeyToRemoteName $
+			filter isRemoteUrlKey $
+				maybe [] (M.keys . config) r
+		
+completeBackends :: HasCompleter f => Mod f a
+completeBackends = completeWith $
+	map (decodeBS . formatKeyVariety . Backend.backendVariety) Backend.builtinList
diff --git a/CmdLine/GitAnnexShell.hs b/CmdLine/GitAnnexShell.hs
new file mode 100644
index 0000000000..84339de2c9
--- /dev/null
+++ b/CmdLine/GitAnnexShell.hs
@@ -0,0 +1,171 @@
+{- git-annex-shell main program
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module CmdLine.GitAnnexShell where
+
+import Annex.Common
+import qualified Git.Construct
+import qualified Git.Config
+import CmdLine
+import CmdLine.AnnexSetter
+import Command
+import Annex.UUID
+import CmdLine.GitAnnexShell.Checks
+import CmdLine.GitAnnexShell.Fields
+import Remote.GCrypt (getGCryptUUID)
+import P2P.Protocol (ServerMode(..))
+import Git.Types
+
+import qualified Command.ConfigList
+import qualified Command.NotifyChanges
+import qualified Command.GCryptSetup
+import qualified Command.P2PStdIO
+import qualified Command.InAnnex
+import qualified Command.RecvKey
+import qualified Command.SendKey
+import qualified Command.DropKey
+
+import qualified Data.Map as M
+
+cmdsMap :: M.Map ServerMode [Command]
+cmdsMap = M.fromList $ map mk
+	[ (ServeReadOnly, readonlycmds)
+	, (ServeAppendOnly, appendcmds)
+	, (ServeReadWrite, allcmds)
+	]
+  where
+	readonlycmds = map addAnnexOptions
+		[ Command.ConfigList.cmd
+		, gitAnnexShellCheck Command.NotifyChanges.cmd
+		-- p2pstdio checks the environment variables to
+		-- determine the security policy to use
+		, gitAnnexShellCheck Command.P2PStdIO.cmd
+		, gitAnnexShellCheck Command.InAnnex.cmd
+		, gitAnnexShellCheck Command.SendKey.cmd
+		]
+	appendcmds = readonlycmds ++ map addAnnexOptions
+		[ gitAnnexShellCheck Command.RecvKey.cmd
+		]
+	allcmds = appendcmds ++ map addAnnexOptions
+		[ gitAnnexShellCheck Command.DropKey.cmd
+		, Command.GCryptSetup.cmd
+		]
+
+	mk (s, l) = (s, map (adddirparam . noMessages) l)
+	adddirparam c = c { cmdparamdesc = "DIRECTORY " ++ cmdparamdesc c }
+
+cmdsFor :: ServerMode -> [Command]
+cmdsFor = fromMaybe [] . flip M.lookup cmdsMap
+
+cmdsList :: [Command]
+cmdsList = nub $ concat $ M.elems cmdsMap
+
+addAnnexOptions :: Command -> Command
+addAnnexOptions c = c { cmdannexoptions = commonShellOptions ++ cmdannexoptions c }
+
+commonShellOptions :: [AnnexOption]
+commonShellOptions = 
+	annexOption (setAnnexState . checkUUID) (strOption
+		( long "uuid" <> metavar paramUUID
+		<> help "local repository uuid"
+		))
+	: commonOptions
+  where
+	checkUUID expected = getUUID >>= check
+	  where
+		check u | u == toUUID expected = noop
+		check NoUUID = checkGCryptUUID expected
+		check u = unexpectedUUID expected u
+	checkGCryptUUID expected = check =<< getGCryptUUID True =<< gitRepo
+	  where
+		check (Just u) | u == toUUID expected = noop
+		check Nothing = unexpected expected "uninitialized repository"
+		check (Just u) = unexpectedUUID expected u
+	unexpectedUUID expected u = unexpected expected $ "UUID " ++ fromUUID u
+	unexpected expected s = giveup $
+		"expected repository UUID " ++ expected ++ " but found " ++ s
+
+run :: [String] -> IO ()
+run [] = failure
+-- skip leading -c options, passed by eg, ssh
+run ("-c":p) = run p
+-- a command can be either a builtin or something to pass to git-shell
+run c@(cmd:dir:params)
+	| cmd `elem` builtins = builtin cmd dir params
+	| otherwise = external c
+run c@(cmd:_)
+	-- Handle the case of being the user's login shell. It will be passed
+	-- a single string containing all the real parameters.
+	| "git-annex-shell " `isPrefixOf` cmd = run $ drop 1 $ shellUnEscape cmd
+	| cmd `elem` builtins = failure
+	| otherwise = external c
+
+builtins :: [String]
+builtins = map cmdname cmdsList
+
+builtin :: String -> String -> [String] -> IO ()
+builtin cmd dir params = do
+	unless (cmd `elem` map cmdname (cmdsFor ServeReadOnly))
+		checkNotReadOnly
+	unless (cmd `elem` map cmdname (cmdsFor ServeAppendOnly))
+		checkNotAppendOnly
+	checkDirectory $ Just dir
+	let (params', fieldparams, opts) = partitionParams params
+	    rsyncopts = ("RsyncOptions", unwords opts)
+	    fields = rsyncopts : filter checkField (parseFields fieldparams)
+	dispatch False False (cmd : params') cmdsList fields mkrepo
+		"git-annex-shell"
+		"Restricted login shell for git-annex only SSH access"
+  where
+	mkrepo = do
+		r <- Git.Construct.repoAbsPath (toRawFilePath dir)
+			>>= Git.Construct.fromAbsPath
+		let r' = r { repoPathSpecifiedExplicitly = True }
+		Git.Config.read r'
+			`catchIO` \_ -> do
+				hn <- fromMaybe "unknown" <$> getHostname
+				giveup $ "failed to read git config of git repository in " ++ hn ++ " on " ++ dir ++ "; perhaps this repository is not set up correctly or has moved"
+
+external :: [String] -> IO ()
+external params = do
+	{- Normal git-shell commands all have the directory as their last
+	 - parameter. -}
+	let lastparam = lastMaybe =<< shellUnEscape <$> lastMaybe params
+	    (params', _, _) = partitionParams params
+	checkDirectory lastparam
+	checkNotLimited
+	unlessM (boolSystem "git-shell" $ map Param $ "-c":params') $
+		giveup "git-shell failed"
+
+{- Split the input list into 3 groups separated with a double dash --.
+ - Parameters between two -- markers are field settings, in the form:
+ - field=value field=value
+ -
+ - Parameters after the last -- are the command itself and its arguments e.g.,
+ - rsync --bandwidth=100.
+ -}
+partitionParams :: [String] -> ([String], [String], [String])
+partitionParams ps = case segment (== "--") ps of
+	params:fieldparams:rest -> ( params, fieldparams, intercalate ["--"] rest )
+	[params] -> (params, [], [])
+	_ -> ([], [], [])
+
+parseFields :: [String] -> [(String, String)]
+parseFields = map (separate (== '='))
+
+{- Only allow known fields to be set, ignore others.
+ - Make sure that field values make sense. -}
+checkField :: (String, String) -> Bool
+checkField (field, val)
+	| field == fieldName remoteUUID = fieldCheck remoteUUID val
+	| field == fieldName autoInit = fieldCheck autoInit val
+	| otherwise = False
+
+failure :: IO ()
+failure = giveup $ "bad parameters\n\n" ++ usage h cmdsList
+  where
+	h = "git-annex-shell [-c] command [parameters ...] [option ...]"
diff --git a/CmdLine/GitAnnexShell/Checks.hs b/CmdLine/GitAnnexShell/Checks.hs
new file mode 100644
index 0000000000..9de66eec6f
--- /dev/null
+++ b/CmdLine/GitAnnexShell/Checks.hs
@@ -0,0 +1,84 @@
+{- git-annex-shell checks
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module CmdLine.GitAnnexShell.Checks where
+
+import Annex.Common
+import Command
+import qualified Annex
+import Annex.Init
+import Utility.UserInfo
+import Utility.Env
+
+limitedEnv :: String
+limitedEnv = "GIT_ANNEX_SHELL_LIMITED"
+
+checkNotLimited :: IO ()
+checkNotLimited = checkEnv limitedEnv
+
+readOnlyEnv :: String
+readOnlyEnv = "GIT_ANNEX_SHELL_READONLY"
+
+checkNotReadOnly :: IO ()
+checkNotReadOnly = checkEnv readOnlyEnv
+
+appendOnlyEnv :: String
+appendOnlyEnv = "GIT_ANNEX_SHELL_APPENDONLY"
+
+checkNotAppendOnly :: IO ()
+checkNotAppendOnly = checkEnv appendOnlyEnv
+
+checkEnv :: String -> IO ()
+checkEnv var = checkEnvSet var >>= \case
+	False -> noop
+	True -> giveup $ "Action blocked by " ++ var
+
+checkEnvSet :: String -> IO Bool
+checkEnvSet var = getEnv var >>= return . \case
+	Nothing -> False
+	Just "" -> False
+	Just _ -> True
+
+checkDirectory :: Maybe FilePath -> IO ()
+checkDirectory mdir = do
+	v <- getEnv "GIT_ANNEX_SHELL_DIRECTORY"
+	case (v, mdir) of
+		(Nothing, _) -> noop
+		(Just d, Nothing) -> req d Nothing
+		(Just d, Just dir)
+			|  d `equalFilePath` dir -> noop
+			| otherwise -> do
+				home <- myHomeDir
+				d' <- canondir home d
+				dir' <- canondir home dir
+				if d' `equalFilePath` dir'
+					then noop
+					else req d' (Just dir')
+  where
+	req d mdir' = giveup $ unwords 
+		[ "Only allowed to access"
+		, d
+		, maybe "and could not determine directory from command line" ("not " ++) mdir'
+		]
+
+	{- A directory may start with ~/ or in some cases, even /~/,
+	 - or could just be relative to home, or of course could
+	 - be absolute. -}
+	canondir home d
+		| "~/" `isPrefixOf` d = return d
+		| "/~/" `isPrefixOf` d = return $ drop 1 d
+		| otherwise = relHome $ fromRawFilePath $ absPathFrom 
+			(toRawFilePath home)
+			(toRawFilePath d)
+
+{- Modifies a Command to check that it is run in either a git-annex
+ - repository, or a repository with a gcrypt-id set. -}
+gitAnnexShellCheck :: Command -> Command
+gitAnnexShellCheck = addCheck GitAnnexShellOk okforshell . dontCheck repoExists
+  where
+	okforshell = unlessM (isInitialized <||> isJust . gcryptId <$> Annex.getGitConfig) $
+		giveup "Not a git-annex or gcrypt repository."
diff --git a/CmdLine/GitAnnexShell/Fields.hs b/CmdLine/GitAnnexShell/Fields.hs
new file mode 100644
index 0000000000..1e416cdb32
--- /dev/null
+++ b/CmdLine/GitAnnexShell/Fields.hs
@@ -0,0 +1,33 @@
+{- git-annex-shell fields
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module CmdLine.GitAnnexShell.Fields where
+
+import Annex.Common
+import qualified Annex
+
+import Data.Char
+
+{- A field, stored in Annex state, with a value sanity checker. -}
+data Field = Field
+	{ fieldName :: String
+	, fieldCheck :: String -> Bool
+	}
+
+getField :: Field -> Annex (Maybe String)
+getField = Annex.getField . fieldName
+
+remoteUUID :: Field
+remoteUUID = Field "remoteuuid" $
+	-- does it look like a UUID?
+	all (\c -> isAlphaNum c || c == '-')
+
+unlocked :: Field
+unlocked = Field "unlocked" $ \f -> f == "1"
+
+autoInit :: Field
+autoInit = Field "autoinit" $ \f -> f == "1"
diff --git a/CmdLine/GitRemoteTorAnnex.hs b/CmdLine/GitRemoteTorAnnex.hs
new file mode 100644
index 0000000000..3349304fb2
--- /dev/null
+++ b/CmdLine/GitRemoteTorAnnex.hs
@@ -0,0 +1,67 @@
+{- git-remote-tor-annex program
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module CmdLine.GitRemoteTorAnnex where
+
+import Common
+import qualified Annex
+import qualified Git.CurrentRepo
+import P2P.Protocol
+import P2P.IO
+import Utility.Tor
+import Utility.AuthToken
+import Annex.UUID
+import P2P.Address
+import P2P.Auth
+import Annex.Action
+
+run :: [String] -> IO ()
+run (_remotename:address:[]) = forever $
+	getLine >>= \case
+		"capabilities" -> putStrLn "connect" >> ready
+		"connect git-upload-pack" -> go UploadPack
+		"connect git-receive-pack" -> go ReceivePack
+		l -> giveup $ "git-remote-helpers protocol error at " ++ show l
+  where
+	(onionaddress, onionport)
+		| '/' `elem` address = parseAddressPort $
+			reverse $ takeWhile (/= '/') $ reverse address
+		| otherwise = parseAddressPort address
+	go service = do
+		ready
+		connectService onionaddress onionport service >>= \case
+			Right exitcode -> exitWith exitcode
+			Left e -> giveup $ describeProtoFailure e
+	ready = do
+		putStrLn ""
+		hFlush stdout
+		
+run (_remotename:[]) = giveup "remote address not configured"
+run _ = giveup "expected remote name and address parameters"
+
+parseAddressPort :: String -> (OnionAddress, OnionPort)
+parseAddressPort s = 
+	let (a, sp) = separate (== ':') s
+	in case readish sp of
+		Nothing -> giveup "onion address must include port number"
+		Just p -> (OnionAddress a, p)
+
+connectService :: OnionAddress -> OnionPort -> Service -> IO (Either ProtoFailure ExitCode)
+connectService address port service = do
+	state <- Annex.new =<< Git.CurrentRepo.get
+	Annex.eval state $ do
+		authtoken <- fromMaybe nullAuthToken
+			<$> loadP2PRemoteAuthToken (TorAnnex address port)
+		myuuid <- getUUID
+		g <- Annex.gitRepo
+		conn <- liftIO $ connectPeer g (TorAnnex address port)
+		runst <- liftIO $ mkRunState Client
+		r <- liftIO $ runNetProto runst conn $ auth myuuid authtoken noop >>= \case
+			Just _theiruuid -> connect service stdin stdout
+			Nothing -> giveup $ "authentication failed, perhaps you need to set " ++ p2pAuthTokenEnv
+		quiesce False
+		return r
diff --git a/CmdLine/Option.hs b/CmdLine/Option.hs
new file mode 100644
index 0000000000..dec78d1898
--- /dev/null
+++ b/CmdLine/Option.hs
@@ -0,0 +1,95 @@
+{- common command-line options
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module CmdLine.Option where
+
+import Options.Applicative
+
+import CmdLine.AnnexSetter
+import qualified Annex
+import Types.Messages
+import Types.DeferredParse
+import Types.GitConfig
+import Git.Types (ConfigKey(..))
+import Git.Config
+import Utility.FileSystemEncoding
+import Annex.Debug
+
+-- Options accepted by both git-annex and git-annex-shell sub-commands.
+commonOptions :: [AnnexOption]
+commonOptions =
+	[ annexFlag (setforce True)
+		( long "force" 
+		<> help "allow actions that may lose annexed data"
+		<> hidden
+		)
+	, annexFlag (setfast True)
+		( long "fast" <> short 'F'
+		<> help "avoid slow operations"
+		<> hidden
+		)
+	, annexFlag (setAnnexState $ Annex.setOutput QuietOutput)
+		( long "quiet" <> short 'q'
+		<> help "avoid verbose output"
+		<> hidden
+		)
+	, annexFlag (setAnnexState $ Annex.setOutput NormalOutput)
+		( long "verbose" <> short 'v'
+		<> help "allow verbose output (default)"
+		<> hidden
+		)
+	, annexFlag (setdebug True)
+		( long "debug" <> short 'd'
+		<> help "show debug messages"
+		<> hidden
+		)
+	, annexFlag (setdebug False)
+		( long "no-debug"
+		<> help "don't show debug messages"
+		<> hidden
+		)
+	, annexOption setdebugfilter $ strOption
+		( long "debugfilter" <> metavar "NAME[,NAME..]"
+		<> help "show debug messages coming from the specified module"
+		<> hidden
+		)
+	, annexFlag (setexplain True)
+		( long "explain" <> short 'd'
+		<> help "explain why git-annex does what it does"
+		<> hidden
+		)
+	]
+  where
+	setforce v = setAnnexRead $ \rd -> rd { Annex.force = v }
+
+	setfast v = setAnnexRead $ \rd -> rd { Annex.fast = v }
+
+	setdebug v = mconcat
+		[ setAnnexRead $ \rd -> rd { Annex.debugenabled = v }
+		-- Also set in git config so it will be passed on to any
+		-- git-annex child processes.
+		, setAnnexState $ Annex.addGitConfigOverride $
+			decodeBS $ debugconfig <> "=" <> boolConfig' v
+		]
+	
+	setdebugfilter v = mconcat
+		[ setAnnexRead $ \rd -> rd
+			{ Annex.debugselector = parseDebugSelector v }
+		-- Also set in git config so it will be passed on to any
+		-- git-annex child processes.
+		, setAnnexState $ Annex.addGitConfigOverride $ 
+			decodeBS (debugfilterconfig <> "=") ++ v
+		]
+	
+	setexplain v = mconcat
+		[ setAnnexRead $ \rd -> rd { Annex.explainenabled = v }
+		]
+	
+	(ConfigKey debugconfig) = annexConfig "debug"
+	(ConfigKey debugfilterconfig) = annexConfig "debugfilter"
diff --git a/CmdLine/Seek.hs b/CmdLine/Seek.hs
new file mode 100644
index 0000000000..620ff81da3
--- /dev/null
+++ b/CmdLine/Seek.hs
@@ -0,0 +1,633 @@
+{- git-annex command seeking
+ - 
+ - These functions find appropriate files or other things based on
+ - the values a user passes to a command, and prepare actions operating
+ - on them.
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module CmdLine.Seek where
+
+import Annex.Common
+import Types.Command
+import Types.FileMatcher
+import qualified Annex
+import qualified Git
+import qualified Git.LsFiles as LsFiles
+import qualified Git.LsTree as LsTree
+import qualified Git.Types as Git
+import qualified Git.Ref
+import Git.Types (toTreeItemType, TreeItemType(..))
+import Git.FilePath
+import qualified Limit
+import CmdLine.GitAnnex.Options
+import CmdLine.Action
+import Logs
+import Logs.Unused
+import Logs.Location
+import Types.Transfer
+import Logs.Transfer
+import Types.Link
+import Remote.List
+import qualified Remote
+import Annex.CatFile
+import Git.CatFile
+import Annex.CurrentBranch
+import Annex.Content
+import Annex.Link
+import Annex.InodeSentinal
+import Annex.Concurrent
+import Annex.CheckIgnore
+import qualified Annex.Branch
+import qualified Database.Keys
+import qualified Utility.RawFilePath as R
+import Utility.Tuple
+import Utility.HumanTime
+
+import Control.Concurrent.Async
+import Control.Concurrent.STM
+import System.Posix.Types
+import Data.IORef
+import Data.Time.Clock.POSIX
+import System.PosixCompat.Files (isDirectory, isSymbolicLink, deviceID, fileID)
+import qualified System.FilePath.ByteString as P
+
+data AnnexedFileSeeker = AnnexedFileSeeker
+	{ startAction :: Maybe KeySha -> SeekInput -> RawFilePath -> Key -> CommandStart
+	, checkContentPresent :: Maybe Bool
+	, usesLocationLog :: Bool
+	}
+
+-- The Sha that was read to get the Key.
+newtype KeySha = KeySha Git.Sha
+
+withFilesInGitAnnex :: WarnUnmatchWhen -> AnnexedFileSeeker -> WorkTreeItems -> CommandSeek
+withFilesInGitAnnex ww a l = seekFilteredKeys a $
+	seekHelper fst3 ww LsFiles.inRepoDetails l
+
+withFilesInGitAnnexNonRecursive :: WarnUnmatchWhen -> String -> AnnexedFileSeeker -> WorkTreeItems -> CommandSeek
+withFilesInGitAnnexNonRecursive ww needforce a (WorkTreeItems l) = ifM (Annex.getRead Annex.force)
+	( withFilesInGitAnnex ww a (WorkTreeItems l)
+	, if null l
+		then giveup needforce
+		else seekFilteredKeys a (getfiles [] l)
+	)
+  where
+	getfiles c [] = return (reverse c, pure True)
+	getfiles c (p:ps) = do
+		os <- seekOptions ww
+		(fs, cleanup) <- inRepo $ LsFiles.inRepoDetails os [toRawFilePath p]
+		r <- case fs of
+			[f] -> do
+				propagateLsFilesError cleanup
+				fst <$> getfiles ((SeekInput [p], f):c) ps
+			[] -> do
+				propagateLsFilesError cleanup
+				fst <$> getfiles c ps
+			_ -> do
+				propagateLsFilesError cleanup
+				giveup needforce
+		return (r, pure True)
+withFilesInGitAnnexNonRecursive _ _ _ NoWorkTreeItems = noop
+
+withFilesNotInGit :: CheckGitIgnore -> WarnUnmatchWhen -> ((SeekInput, RawFilePath) -> CommandSeek) -> WorkTreeItems -> CommandSeek
+withFilesNotInGit (CheckGitIgnore ci) ww a l = do
+	force <- Annex.getRead Annex.force
+	let include_ignored = force || not ci
+	seekFiltered (const (pure True)) a $
+		seekHelper id ww (const $ LsFiles.notInRepo [] include_ignored) l
+
+withPathContents :: ((RawFilePath, RawFilePath) -> CommandSeek) -> CmdParams -> CommandSeek
+withPathContents a params = do
+	matcher <- Limit.getMatcher
+	checktimelimit <- mkCheckTimeLimit
+	go matcher checktimelimit params []
+  where
+	go _ _ [] [] = return ()
+	go matcher checktimelimit (p:ps) [] =
+		go matcher checktimelimit ps =<< liftIO (get p)
+	go matcher checktimelimit ps (f:fs) = checktimelimit noop $ do
+		whenM (checkmatch matcher f) $
+			a f
+		go matcher checktimelimit ps fs		
+	
+	-- Using getFileStatus not getSymbolicLinkStatus because it should
+	-- fail if the path that the user provided is a broken symlink,
+	-- the same as it fails if the path that the user provided does not
+	-- exist.
+	get p = ifM (isDirectory <$> R.getFileStatus p')
+		( map (\f -> 
+			let f' = toRawFilePath f
+			in (f', P.makeRelative (P.takeDirectory (P.dropTrailingPathSeparator p')) f'))
+			<$> dirContentsRecursiveSkipping (".git" `isSuffixOf`) False p
+		, return [(p', P.takeFileName p')]
+		)
+	  where
+		p' = toRawFilePath p
+
+	checkmatch matcher (f, relf) = matcher $ MatchingFile $ FileInfo
+		{ contentFile = f
+		, matchFile = relf
+		, matchKey = Nothing
+		}
+
+withWords :: ([String] -> CommandSeek) -> CmdParams -> CommandSeek
+withWords a params = a params
+
+withStrings :: (String -> CommandSeek) -> CmdParams -> CommandSeek
+withStrings a params = sequence_ $ map a params
+
+withPairs :: ((SeekInput, (String, String)) -> CommandSeek) -> CmdParams -> CommandSeek
+withPairs a params = sequence_ $ 
+	map (\p@(x,y) -> a (SeekInput [x,y], p)) (pairs [] params)
+  where
+	pairs c [] = reverse c
+	pairs c (x:y:xs) = pairs ((x,y):c) xs
+	pairs _ _ = giveup "expected pairs"
+
+withFilesToBeCommitted :: WarnUnmatchWhen -> ((SeekInput, RawFilePath) -> CommandSeek) -> WorkTreeItems -> CommandSeek
+withFilesToBeCommitted ww a l = seekFiltered (const (pure True)) a $
+	seekHelper id ww (const LsFiles.stagedNotDeleted) l
+
+{- unlocked pointer files that are staged, and whose content has not been
+ - modified-}
+withUnmodifiedUnlockedPointers :: WarnUnmatchWhen -> ((SeekInput, RawFilePath) -> CommandSeek) -> WorkTreeItems -> CommandSeek
+withUnmodifiedUnlockedPointers ww a l =
+	seekFiltered (isUnmodifiedUnlocked . snd) a $
+		seekHelper id ww (const LsFiles.typeChangedStaged) l
+
+isUnmodifiedUnlocked :: RawFilePath -> Annex Bool
+isUnmodifiedUnlocked f = catKeyFile f >>= \case
+	Nothing -> return False
+	Just k -> sameInodeCache f =<< Database.Keys.getInodeCaches k
+
+{- Finds files that may be modified. -}
+withFilesMaybeModified :: WarnUnmatchWhen -> ((SeekInput, RawFilePath) -> CommandSeek) -> WorkTreeItems -> CommandSeek
+withFilesMaybeModified ww a params = seekFiltered (const (pure True)) a $
+	seekHelper id ww LsFiles.modified params
+
+withKeys :: ((SeekInput, Key) -> CommandSeek) -> CmdParams -> CommandSeek
+withKeys a ls = sequence_ $ map (\l -> a (SeekInput [l], parse l)) ls
+  where
+	parse p = fromMaybe (giveup "bad key") $ deserializeKey p
+
+withNothing :: CommandSeek -> CmdParams -> CommandSeek
+withNothing a [] = a
+withNothing _ _ = giveup "This command takes no parameters."
+
+{- Handles the --all, --branch, --unused, --failed, --key, and
+ - --incomplete options, which specify particular keys to run an
+ - action on.
+ -
+ - In a bare repo, --all is the default.
+ -
+ - Otherwise falls back to a regular CommandSeek action on
+ - whatever params were passed.
+ -}
+withKeyOptions 
+	:: Maybe KeyOptions
+	-> Bool
+	-> AnnexedFileSeeker
+	-> ((SeekInput, Key, ActionItem) -> CommandSeek)
+	-> (WorkTreeItems -> CommandSeek)
+	-> WorkTreeItems
+	-> CommandSeek
+withKeyOptions ko auto seeker keyaction = withKeyOptions' ko auto mkkeyaction
+  where
+	mkkeyaction = do
+		matcher <- Limit.getMatcher
+		return $ \lt v@(_si, k, ai) -> checkseeker k $
+			let i = case ai of
+				ActionItemBranchFilePath (BranchFilePath _ topf) _ ->
+					ProvidedInfo
+						{ providedFilePath = Just $
+							getTopFilePath topf
+						, providedKey = Just k
+						, providedFileSize = Nothing
+						, providedMimeType = Nothing
+						, providedMimeEncoding = Nothing
+						, providedLinkType = lt
+						}
+				_ -> ProvidedInfo
+					{ providedFilePath = Nothing
+					, providedKey = Just k
+					, providedFileSize = Nothing
+					, providedMimeType = Nothing
+					, providedMimeEncoding = Nothing
+					, providedLinkType = lt
+					}
+			in whenM (matcher (MatchingInfo i)) $
+				keyaction v
+	checkseeker k a = case checkContentPresent seeker of
+		Nothing -> a
+		Just v -> do
+			present <- inAnnex k
+			when (present == v) a
+
+withKeyOptions' 
+	:: Maybe KeyOptions
+	-> Bool
+	-> Annex (Maybe LinkType -> (SeekInput, Key, ActionItem) -> Annex ())
+	-> (WorkTreeItems -> CommandSeek)
+	-> WorkTreeItems
+	-> CommandSeek
+withKeyOptions' ko auto mkkeyaction fallbackaction worktreeitems = do
+	bare <- fromRepo Git.repoIsLocalBare
+	when (auto && bare) $
+		giveup "Cannot use --auto in a bare repository"
+	case (nospecifiedworktreeitems, ko) of
+		(True, Nothing)
+			| bare -> nofilename $ noauto runallkeys
+			| otherwise -> fallbackaction worktreeitems
+		(False, Nothing) -> fallbackaction worktreeitems
+		(True, Just WantAllKeys) -> nofilename $ noauto runallkeys
+		(True, Just WantUnusedKeys) -> nofilename $ noauto $ runkeyaction unusedKeys'
+		(True, Just WantFailedTransfers) -> nofilename $ noauto runfailedtransfers
+		(True, Just (WantSpecificKey k)) -> nofilename $ noauto $ runkeyaction (return [k])
+		(True, Just WantIncompleteKeys) -> nofilename $ noauto $ runkeyaction incompletekeys
+		(True, Just (WantBranchKeys bs)) -> noauto $ runbranchkeys bs
+		(False, Just _) -> giveup "Can only specify one of file names, --all, --branch, --unused, --failed, --key, or --incomplete"
+  where
+	noauto a
+		| auto = giveup "Cannot use --auto with --all or --branch or --unused or --key or --incomplete"
+		| otherwise = a
+			
+	nofilename a = ifM (Limit.introspect matchNeedsFileName)
+		( do
+			bare <- fromRepo Git.repoIsLocalBare
+			if bare
+				then giveup "Cannot use options that match on file names in a bare repository."
+				else giveup "Cannot use --all or --unused or --key or --incomplete with options that match on file names."
+		, a
+		)
+
+	nospecifiedworktreeitems = case worktreeitems of
+		WorkTreeItems [] -> True
+		WorkTreeItems _ -> False
+		NoWorkTreeItems -> False
+
+	incompletekeys = staleKeysPrune gitAnnexTmpObjectDir True
+
+	-- List all location log files on the git-annex branch,
+	-- and use those to get keys. Pass through cat-file
+	-- to get the contents of the location logs, and pre-cache
+	-- those. This significantly speeds up typical operations
+	-- that need to look at the location log for each key.
+	runallkeys = do
+		keyaction <- mkkeyaction
+		checktimelimit <- mkCheckTimeLimit
+		let discard reader = reader >>= \case
+			Nothing -> noop
+			Just _ -> discard reader
+		overLocationLogs' () 
+			(\reader cont -> checktimelimit (discard reader) cont) 
+			(\k _ () -> keyaction Nothing (SeekInput [], k, mkActionItem k))
+
+	runkeyaction getks = do
+		keyaction <- mkkeyaction
+		ks <- getks
+		forM_ ks $ \k -> keyaction Nothing (SeekInput [], k, mkActionItem k)
+	
+	runbranchkeys bs = do
+		keyaction <- mkkeyaction
+		forM_ bs $ \b -> do
+			(l, cleanup) <- inRepo $ LsTree.lsTree LsTree.LsTreeRecursive (LsTree.LsTreeLong False) b
+			forM_ l $ \i -> catKey (LsTree.sha i) >>= \case
+				Just k -> 
+					let bfp = mkActionItem (BranchFilePath b (LsTree.file i), k)
+					    lt = case toTreeItemType (LsTree.mode i) of
+						Just TreeSymlink -> Just LockedLink
+						Just TreeFile -> Just UnlockedLink
+						Just TreeExecutable -> Just UnlockedLink
+						_ -> Nothing
+					in keyaction lt (SeekInput [], k, bfp)
+				Nothing -> noop
+			unlessM (liftIO cleanup) $
+				giveup ("git ls-tree " ++ Git.fromRef b ++ " failed")
+	
+	runfailedtransfers = do
+		keyaction <- mkkeyaction
+		rs <- remoteList
+		ts <- concat <$> mapM (getFailedTransfers . Remote.uuid) rs
+		forM_ ts $ \(t, i) ->
+			keyaction Nothing (SeekInput [], transferKey t, mkActionItem (t, i))
+
+seekFiltered :: ((SeekInput, RawFilePath) -> Annex Bool) -> ((SeekInput, RawFilePath) -> CommandSeek) -> Annex ([(SeekInput, RawFilePath)], IO Bool) -> Annex ()
+seekFiltered prefilter a listfs = do
+	matcher <- Limit.getMatcher
+	checktimelimit <- mkCheckTimeLimit
+	(fs, cleanup) <- listfs
+	go matcher checktimelimit fs
+	propagateLsFilesError cleanup
+  where
+	go _ _ [] = return ()
+	go matcher checktimelimit (v@(_si, f):rest) = checktimelimit noop $ do
+		whenM (prefilter v) $
+			whenM (matcher $ MatchingFile $ FileInfo f f Nothing) $
+				a v
+		go matcher checktimelimit rest
+
+data MatcherInfo = MatcherInfo
+	{ matcherAction :: MatchInfo -> Annex Bool
+	, matcherNeedsFileName :: Bool
+	, matcherNeedsKey :: Bool
+	, matcherNeedsLocationLog :: Bool
+	}
+
+checkMatcherWhen :: MatcherInfo -> Bool -> MatchInfo -> Annex () -> Annex ()
+checkMatcherWhen mi c i a
+	| c = whenM (matcherAction mi i) a
+	| otherwise = a
+
+-- This is significantly faster than using lookupKey after seekFiltered,
+-- because of the way data is streamed through git cat-file.
+--
+-- It can also precache location logs using the same efficient streaming.
+seekFilteredKeys :: AnnexedFileSeeker -> Annex ([(SeekInput, (RawFilePath, Git.Sha, FileMode))], IO Bool) -> Annex ()
+seekFilteredKeys seeker listfs = do
+	g <- Annex.gitRepo
+	mi <- MatcherInfo
+		<$> Limit.getMatcher
+		<*> Limit.introspect matchNeedsFileName
+		<*> Limit.introspect matchNeedsKey
+		<*> Limit.introspect matchNeedsLocationLog
+	config <- Annex.getGitConfig
+	(l, cleanup) <- listfs
+	checktimelimit <- mkCheckTimeLimit
+	catObjectMetaDataStream g $ \mdfeeder mdcloser mdreader ->
+		catObjectStream g $ \ofeeder ocloser oreader -> do
+			processertid <- liftIO . async =<< forkState
+				(process mi ofeeder mdfeeder mdcloser False l)
+			mdprocessertid <- liftIO . async =<< forkState
+				(mdprocess mi mdreader ofeeder ocloser)
+			ifM (precachell mi)
+				( catObjectStream g $ \lfeeder lcloser lreader -> do
+					precachertid <- liftIO . async =<< forkState
+						(precacher mi config oreader lfeeder lcloser)
+					precachefinisher mi lreader checktimelimit
+					join (liftIO (wait precachertid))
+				, finisher mi oreader checktimelimit
+				)
+			join (liftIO (wait mdprocessertid))
+			join (liftIO (wait processertid))
+	propagateLsFilesError cleanup
+  where
+	finisher mi oreader checktimelimit = liftIO oreader >>= \case
+		Just ((si, f, keysha), content) -> checktimelimit (liftIO discard) $ do
+			keyaction f mi content $
+				commandAction . startAction seeker keysha si f
+			finisher mi oreader checktimelimit
+		Nothing -> return ()
+	  where
+		discard = oreader >>= \case
+			Nothing -> return ()
+			Just _ -> discard
+
+	precachefinisher mi lreader checktimelimit = liftIO lreader >>= \case
+		Just ((logf, (si, f, keysha), k), logcontent) -> checktimelimit (liftIO discard) $ do
+			maybe noop (Annex.Branch.precache logf) logcontent
+			checkMatcherWhen mi
+				(matcherNeedsLocationLog mi && not (matcherNeedsFileName mi))
+				(MatchingFile $ FileInfo f f (Just k))
+				(commandAction $ startAction seeker keysha si f k)
+			precachefinisher mi lreader checktimelimit
+		Nothing -> return ()
+	  where
+		discard = lreader >>= \case
+			Nothing -> return ()
+			Just _ -> discard
+	
+	precacher mi config oreader lfeeder lcloser = liftIO oreader >>= \case
+		Just ((si, f, keysha), content) -> do
+			keyaction f mi content $ \k -> 
+				let logf = locationLogFile config k
+				    ref = Git.Ref.branchFileRef Annex.Branch.fullname logf
+				in liftIO $ lfeeder ((logf, (si, f, keysha), k), ref)
+			precacher mi config oreader lfeeder lcloser
+		Nothing -> liftIO $ void lcloser
+	
+	feedmatches mi ofeeder si f sha = checkMatcherWhen mi
+		-- When the matcher needs a key or location log 
+		-- (and does not need a worktree filename), it will be
+		-- checked later, to avoid a slow lookup here.
+		(not ((matcherNeedsKey mi || matcherNeedsLocationLog mi) 
+			&& not (matcherNeedsFileName mi)))
+		(MatchingFile $ FileInfo f f Nothing)
+		(liftIO $ ofeeder ((si, f, Just (KeySha sha)), sha))
+
+	keyaction f mi content a = 
+		case parseLinkTargetOrPointerLazy =<< content of
+			Just k -> checkMatcherWhen mi
+				(matcherNeedsKey mi && not (matcherNeedsFileName mi || matcherNeedsLocationLog mi))
+				(MatchingFile $ FileInfo f f (Just k))
+				(checkpresence k (a k))
+			Nothing -> noop
+	
+	checkpresence k cont = case checkContentPresent seeker of
+		Just v -> do
+			present <- inAnnex k
+			when (present == v) cont
+		Nothing -> cont
+
+	process mi ofeeder mdfeeder mdcloser seenpointer ((si, (f, sha, mode)):rest) =
+		case Git.toTreeItemType mode of
+			Just Git.TreeSymlink -> do
+				whenM (exists f) $
+					-- Once a pointer file has been seen,
+					-- symlinks have to be sent via the 
+					-- metadata processor too. That is
+					-- slightly slower, but preserves the
+					-- requested file order.
+					if seenpointer
+						then liftIO $ mdfeeder ((si, f), sha)
+						else feedmatches mi ofeeder si f sha
+				process mi ofeeder mdfeeder mdcloser seenpointer rest
+			Just Git.TreeSubmodule ->
+				process mi ofeeder mdfeeder mdcloser seenpointer rest
+			-- Might be a pointer file, might be other
+			-- file in git, possibly large. Avoid catting
+			-- large files by first looking up the size.
+			Just _ -> do
+				whenM (exists f) $
+					liftIO $ mdfeeder ((si, f), sha)
+				process mi ofeeder mdfeeder mdcloser True rest
+			Nothing ->
+				process mi ofeeder mdfeeder mdcloser seenpointer rest
+	process _ _ _ mdcloser _ [] = liftIO $ void mdcloser
+	
+	-- Check if files exist, because a deleted file will still be
+	-- listed by ls-tree, but should not be processed.
+	exists p = isJust <$> liftIO (catchMaybeIO $ R.getSymbolicLinkStatus p)
+
+	mdprocess mi mdreader ofeeder ocloser = liftIO mdreader >>= \case
+		Just ((si, f), Just (sha, size, _type))
+			| size < fromIntegral maxPointerSz -> do
+				feedmatches mi ofeeder si f sha
+				mdprocess mi mdreader ofeeder ocloser
+		Just _ -> mdprocess mi mdreader ofeeder ocloser
+		Nothing -> liftIO $ void ocloser
+
+	-- Precache location logs if it will speed things up.
+	--
+	-- When there are git-annex branches that are not able to be
+	-- merged, the precaching is disabled, since it only looks at the
+	-- git-annex branch and not at those.
+	precachell mi
+		| usesLocationLog seeker || matcherNeedsLocationLog mi =
+			null <$> Annex.Branch.getUnmergedRefs
+		| otherwise = pure False
+
+seekHelper :: (a -> RawFilePath) -> WarnUnmatchWhen -> ([LsFiles.Options] -> [RawFilePath] -> Git.Repo -> IO ([a], IO Bool)) -> WorkTreeItems -> Annex ([(SeekInput, a)], IO Bool)
+seekHelper c ww a (WorkTreeItems l) = do
+	os <- seekOptions ww
+	v <- liftIO $ newIORef []
+	r <- inRepo $ \g -> concat . concat <$> forM (segmentXargsOrdered l)
+		(runSegmentPaths' mk c (\fs -> go v os fs g) . map toRawFilePath)
+	return (r, cleanupall v)
+  where
+	mk (Just i) f = (SeekInput [fromRawFilePath i], f) 
+	-- This is not accurate, but it only happens when there are a
+	-- great many input WorkTreeItems.
+	mk Nothing f = (SeekInput [fromRawFilePath (c f)], f)
+
+	go v os fs g = do
+		(ls, cleanup) <- a os fs g
+		liftIO $ modifyIORef' v (cleanup:)
+		return ls
+
+	cleanupall v = do
+		cleanups <- readIORef v
+		and <$> sequence cleanups
+seekHelper _ _ _ NoWorkTreeItems = return ([], pure True)
+
+data WarnUnmatchWhen = WarnUnmatchLsFiles String | WarnUnmatchWorkTreeItems String
+
+seekOptions :: WarnUnmatchWhen -> Annex [LsFiles.Options]
+seekOptions (WarnUnmatchLsFiles _) =
+	ifM (annexSkipUnknown <$> Annex.getGitConfig)
+		( return [] 
+		, return [LsFiles.ErrorUnmatch]
+		)
+seekOptions (WarnUnmatchWorkTreeItems _) = return []
+
+-- Items in the work tree, which may be files or directories.
+data WorkTreeItems
+	= WorkTreeItems [FilePath]
+	-- ^ An empty list often means all files.
+	| NoWorkTreeItems
+	-- ^ Used when no work tree items should be operated on.
+	deriving (Show)
+
+-- When in an adjusted branch that hides some files, it may not exist
+-- in the current work tree, but in the original branch. This allows
+-- seeking for such files.
+newtype AllowHidden = AllowHidden Bool
+
+-- git ls-files without --error-unmatch seeks work tree items matching
+-- some criteria, and silently skips over anything that does not exist.
+
+-- Also, when two directories are symlinked, referring to a file
+-- inside the symlinked directory will be silently skipped by
+-- git ls-files without --error-unmatch. 
+--
+-- Sometimes a command needs to use git-lsfiles that way, perhaps repeatedly.
+-- But users expect an error message when one of the files they provided
+-- as a command-line parameter doesn't exist, so this checks that each
+-- exists when run with WarnUnmatchWorkTreeItems.
+--
+-- Note that, unlike --error-unmatch, using this does not warn
+-- about command-line parameters that exist, but are not checked into git.
+workTreeItems :: WarnUnmatchWhen -> CmdParams -> Annex WorkTreeItems
+workTreeItems = workTreeItems' (AllowHidden False)
+
+workTreeItems' :: AllowHidden -> WarnUnmatchWhen -> CmdParams -> Annex WorkTreeItems
+workTreeItems' (AllowHidden allowhidden) ww ps = case ww of
+	(WarnUnmatchWorkTreeItems action) -> runcheck action
+	(WarnUnmatchLsFiles action) -> 
+		ifM (annexSkipUnknown <$> Annex.getGitConfig)
+			( runcheck action
+			, return $ WorkTreeItems ps
+			)
+  where
+	runcheck action = do
+		currbranch <- getCurrentBranch
+		stopattop <- prepviasymlink
+		ps' <- flip filterM ps $ \p -> do
+			let p' = toRawFilePath p
+			relf <- liftIO $ relPathCwdToFile p'
+			ifM (not <$> (exists p' <||> hidden currbranch relf))
+				( prob action FileNotFound p' "not found"
+				, ifM (viasymlink stopattop (upFrom relf))
+					( prob action FileBeyondSymbolicLink p' "is beyond a symbolic link"
+					, return True
+					)
+				)
+		if null ps' && not (null ps)
+			then return NoWorkTreeItems
+			else return (WorkTreeItems ps')
+	
+	exists p = isJust <$> liftIO (catchMaybeIO $ R.getSymbolicLinkStatus p)
+
+	prepviasymlink = do
+		repotopst <- inRepo $ 
+			maybe
+				(pure Nothing)
+				(catchMaybeIO . R.getSymbolicLinkStatus) 
+			. Git.repoWorkTree
+		return $ \st -> case repotopst of
+			Nothing -> False
+			Just tst -> fileID st == fileID tst
+				&& deviceID st == deviceID tst
+
+	viasymlink _ Nothing = return False
+	viasymlink stopattop (Just p) = do
+		st <- liftIO $ R.getSymbolicLinkStatus p
+		if stopattop st
+			then return False
+			else if isSymbolicLink st
+				then return True
+				else viasymlink stopattop (upFrom p)
+
+	hidden currbranch f
+		| allowhidden = isJust
+			<$> catObjectMetaDataHidden f currbranch
+		| otherwise = return False
+
+	prob action errorid p msg = do
+		toplevelFileProblem False errorid msg action p Nothing (SeekInput [fromRawFilePath p])
+		Annex.incError
+		return False
+	
+notSymlink :: RawFilePath -> IO Bool
+notSymlink f = liftIO $ not . isSymbolicLink <$> R.getSymbolicLinkStatus f
+
+{- Returns an action that, when there's a time limit, can be used
+ - to check it before processing a file. The first action is run when
+ - over the time limit, otherwise the second action is run one time to
+ - clean up. -}
+mkCheckTimeLimit :: Annex (Annex () -> Annex () -> Annex ())
+mkCheckTimeLimit = Annex.getState Annex.timelimit >>= \case
+	Nothing -> return $ \_ a -> a
+	Just (duration, cutoff) -> do
+		warningshownv <- liftIO $ newTVarIO False
+		return $ \cleanup a -> do
+			now <- liftIO getPOSIXTime
+			if now > cutoff
+				then do
+					warningshown <- liftIO $ atomically $
+						swapTVar warningshownv True
+					unless warningshown $ do
+						Annex.changeState $ \s -> s { Annex.reachedlimit = True }
+						warning $ UnquotedString $ "Time limit (" ++ fromDuration duration ++ ") reached! Shutting down..."
+						cleanup
+				else a
+
+propagateLsFilesError :: IO Bool -> Annex ()
+propagateLsFilesError cleanup =
+	unlessM (liftIO cleanup) $
+		Annex.incError
diff --git a/CmdLine/Usage.hs b/CmdLine/Usage.hs
new file mode 100644
index 0000000000..4943eaeb16
--- /dev/null
+++ b/CmdLine/Usage.hs
@@ -0,0 +1,108 @@
+{- git-annex usage messages
+ -
+ - Copyright 2010-2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module CmdLine.Usage where
+
+import Annex.Common
+import Types.Command
+
+usageMessage :: String -> String
+usageMessage s = "Usage: " ++ s
+
+usage :: String -> [Command] -> String
+usage header cmds = unlines $ usageMessage header : commandList cmds
+
+{- Commands listed by section, with brief usage and description. -}
+commandList :: [Command] -> [String]
+commandList cmds = concatMap go [minBound..]
+  where
+	go section
+		| null cs = []
+		| otherwise =
+			[ ""
+			, descSection section ++ ":"
+			, ""
+			] ++ map cmdline cs
+	  where
+		cs = filter (\c -> cmdsection c == section) scmds
+	cmdline c = concat
+		[ cmdname c
+		, namepad (cmdname c)
+		, cmddesc c
+		]
+	pad n s = replicate (n - length s) ' '
+	namepad = pad $ longest cmdname + 1
+	longest f = foldl max 0 $ map (length . f) cmds
+	scmds = sort cmds
+
+{- Descriptions of params used in usage messages. -}
+paramPaths :: String
+paramPaths = paramRepeating paramPath -- most often used
+paramPath :: String
+paramPath = "PATH"
+paramKey :: String
+paramKey = "KEY"
+paramDesc :: String
+paramDesc = "DESC"
+paramUrl :: String
+paramUrl = "URL"
+paramNumber :: String
+paramNumber = "NUMBER"
+paramNumRange :: String
+paramNumRange = "NUM|RANGE"
+paramRemote :: String
+paramRemote = "REMOTE"
+paramRepository :: String
+paramRepository = "REPOSITORY"
+paramField :: String
+paramField = "FIELD"
+paramGlob :: String
+paramGlob = "GLOB"
+paramName :: String
+paramName = "NAME"
+paramValue :: String
+paramValue = "VALUE"
+paramUUID :: String
+paramUUID = "UUID"
+paramType :: String
+paramType = "TYPE"
+paramDate :: String
+paramDate = "DATE"
+paramTime :: String
+paramTime = "TIME"
+paramFormat :: String
+paramFormat = "FORMAT"
+paramFile :: String
+paramFile = "FILE"
+paramRef :: String
+paramRef = "REF"
+paramRefSpec :: String
+paramRefSpec = "REFSPEC"
+paramGroup :: String
+paramGroup = "GROUP"
+paramExpression :: String
+paramExpression = "EXPR"
+paramSize :: String
+paramSize = "SIZE"
+paramAddress :: String
+paramAddress = "ADDRESS"
+paramItem :: String
+paramItem = "ITEM"
+paramTreeish :: String
+paramTreeish = "TREEISH"
+paramParamValue :: String
+paramParamValue = "PARAM=VALUE"
+paramNothing :: String
+paramNothing = ""
+paramRepeating :: String -> String
+paramRepeating s = s ++ " ..."
+paramOptional :: String -> String
+paramOptional s = s
+paramPair :: String -> String -> String
+paramPair a b = a ++ " " ++ b
+paramOr :: String -> String -> String
+paramOr a b = a ++ " | " ++ b
diff --git a/Command.hs b/Command.hs
new file mode 100644
index 0000000000..7c4caeffa7
--- /dev/null
+++ b/Command.hs
@@ -0,0 +1,152 @@
+{- git-annex command infrastructure
+ -
+ - Copyright 2010-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command (
+	module Command,
+	module ReExported
+) where
+
+import Annex.Common as ReExported
+import Types.Command as ReExported
+import Types.DeferredParse as ReExported
+import CmdLine.Seek as ReExported
+import CmdLine.Usage as ReExported
+import CmdLine.Action as ReExported
+import CmdLine.Option as ReExported
+import CmdLine.AnnexSetter as ReExported
+import CmdLine.GitAnnex.Options as ReExported
+import CmdLine.Batch as ReExported
+import Options.Applicative as ReExported hiding (command)
+import qualified Git
+import Annex.Init
+import Utility.Daemon
+import Types.Transfer
+import Types.ActionItem as ReExported
+import Types.WorkerPool as ReExported
+import Remote.List
+
+{- Generates a normal Command -}
+command :: String -> CommandSection -> String -> CmdParamsDesc -> (CmdParamsDesc -> CommandParser) -> Command
+command name section desc paramdesc mkparser =
+	Command commonChecks False False name paramdesc 
+		section desc (mkparser paramdesc) mempty [] Nothing
+
+{- Simple option parser that takes all non-option params as-is. -}
+withParams :: (CmdParams -> v) -> CmdParamsDesc -> Parser v
+withParams mkseek paramdesc = mkseek <$> cmdParams paramdesc
+
+{- Uses the supplied option parser, which yields a deferred parse,
+ - and calls finishParse on the result before passing it to the
+ - CommandSeek constructor. -}
+(<--<) :: DeferredParseClass a
+	=> (a -> CommandSeek) 
+	-> (CmdParamsDesc -> Parser a)
+	-> CmdParamsDesc
+	-> Parser CommandSeek
+(<--<) mkseek optparser paramsdesc = 
+	(mkseek <=< finishParse) <$> optparser paramsdesc
+
+{- Indicates that a command doesn't need to commit any changes to
+ - the git-annex branch. -}
+noCommit :: Command -> Command
+noCommit c = c { cmdnocommit = True }
+
+{- Indicates that a command should not output the usual messages when
+ - starting or stopping processing a file or other item. Unless --json mode
+ - is enabled, this also enables quiet output mode, so only things
+ - explicitly output by the command are shown and not progress messages
+ - etc.
+ -}
+noMessages :: Command -> Command
+noMessages c = c { cmdnomessages = True }
+
+{- Adds a fallback action to a command, that will be run if it's used
+ - outside a git repository. -}
+noRepo :: (CmdParamsDesc -> Parser (IO ())) -> Command -> Command
+noRepo a c = c { cmdnorepo = Just (a (cmdparamdesc c)) }
+
+{- Adds Annex options to a command. -}
+withAnnexOptions :: [[AnnexOption]] -> Command -> Command
+withAnnexOptions os c = c { cmdannexoptions = cmdannexoptions c ++ concat os }
+
+{- For start stage to indicate what will be done. -}
+starting:: MkActionItem actionitem => String -> actionitem -> SeekInput -> CommandPerform -> CommandStart
+starting msg ai si a = next
+	(StartMessage msg (mkActionItem ai) si, a)
+
+{- Use when noMessages was used but the command is going to output
+ - usual messages after all. -}
+startingUsualMessages :: MkActionItem t => String -> t -> SeekInput -> CommandPerform -> CommandStart
+startingUsualMessages msg t si a = next 
+	(StartUsualMessages msg (mkActionItem t) si, a)
+
+{- When no message should be displayed at start/end, but messages can still 
+ - be displayed when using eg includeCommandAction. -}
+startingNoMessage :: MkActionItem t => t -> CommandPerform -> CommandStart
+startingNoMessage t a = next (StartNoMessage (mkActionItem t), a)
+
+{- For commands that do not display usual start or end messages, 
+ - but have some other custom output. -}
+startingCustomOutput :: MkActionItem t => t -> CommandPerform -> CommandStart
+startingCustomOutput t a = next (CustomOutput (mkActionItem t), a)
+
+{- For perform stage to indicate what step to run next. -}
+next :: a -> Annex (Maybe a)
+next a = return $ Just a
+
+{- For start and perform stage to indicate nothing needs to be done. -}
+stop :: Annex (Maybe a)
+stop = return Nothing
+
+{- Stops unless a condition is met. -}
+stopUnless :: Annex Bool -> Annex (Maybe a) -> Annex (Maybe a)
+stopUnless c a = ifM c ( a , stop )
+
+{- When doing a dry run, avoid actually performing the action, but pretend
+ - that it succeeded. -}
+skipWhenDryRun :: DryRun -> CommandPerform -> CommandPerform
+skipWhenDryRun (DryRun False) a = a
+skipWhenDryRun (DryRun True) _ = next $ return True
+
+{- When acting on a failed transfer, stops unless it was in the specified
+ - direction. -}
+checkFailedTransferDirection :: ActionItem -> Direction -> Annex (Maybe a) -> Annex (Maybe a)
+checkFailedTransferDirection ai d = stopUnless (pure check)
+  where
+	check = case actionItemTransferDirection ai of
+		Nothing -> True
+		Just d' -> d' == d
+
+commonChecks :: [CommandCheck]
+commonChecks = [repoExists]
+
+repoExists :: CommandCheck
+repoExists = CommandCheck RepoExists (ensureInitialized remoteList)
+
+notBareRepo :: Command -> Command
+notBareRepo = addCheck CheckNotBareRepo checkNotBareRepo
+
+checkNotBareRepo :: Annex ()
+checkNotBareRepo = whenM (fromRepo Git.repoIsLocalBare) $
+	giveup "You cannot run this command in a bare repository."
+
+noDaemonRunning :: Command -> Command
+noDaemonRunning = addCheck NoDaemonRunning $ whenM (isJust <$> daemonpid) $
+	giveup "You cannot run this command while git-annex watch or git-annex assistant is running."
+  where
+	daemonpid = liftIO . checkDaemon . fromRawFilePath
+		=<< fromRepo gitAnnexPidFile
+
+dontCheck :: CommandCheck -> Command -> Command
+dontCheck check cmd = mutateCheck cmd $ \c -> filter (/= check) c
+
+addCheck :: CommandCheckId -> Annex () -> Command -> Command
+addCheck cid check cmd = mutateCheck cmd $ \c ->
+	CommandCheck cid check : c
+
+mutateCheck :: Command -> ([CommandCheck] -> [CommandCheck]) -> Command
+mutateCheck cmd@(Command { cmdcheck = c }) a = cmd { cmdcheck = a c }
diff --git a/Command/Add.hs b/Command/Add.hs
new file mode 100644
index 0000000000..5f0daaab08
--- /dev/null
+++ b/Command/Add.hs
@@ -0,0 +1,271 @@
+{- git-annex command
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Add where
+
+import Command
+import Annex.Ingest
+import Logs.Location
+import Annex.Content
+import qualified Annex
+import qualified Annex.Queue
+import qualified Database.Keys
+import Annex.FileMatcher
+import Annex.Link
+import Annex.Tmp
+import Annex.HashObject
+import Annex.WorkTree
+import Messages.Progress
+import Git.FilePath
+import Git.Types
+import Git.UpdateIndex
+import Config.GitConfig
+import Utility.OptParse
+import Utility.InodeCache
+import Annex.InodeSentinal
+import Annex.CheckIgnore
+import qualified Utility.RawFilePath as R
+import qualified System.FilePath.ByteString as P
+
+import System.PosixCompat.Files (fileSize, isSymbolicLink, isRegularFile, modificationTime, fileID, deviceID, fileMode, ownerExecuteMode, intersectFileModes)
+
+cmd :: Command
+cmd = notBareRepo $ 
+	withAnnexOptions opts $
+		command "add" SectionCommon "add files to annex"
+			paramPaths (seek <$$> optParser)
+  where
+	opts =
+		[ backendOption
+		, jobsOption
+		, jsonOptions
+		, jsonProgressOption
+		, fileMatchingOptions LimitDiskFiles
+		]
+
+data AddOptions = AddOptions
+	{ addThese :: CmdParams
+	, batchOption :: BatchMode
+	, updateOnly :: Bool
+	, largeFilesOverride :: Maybe Bool
+	, checkGitIgnoreOption :: CheckGitIgnore
+	, dryRunOption :: DryRun
+	}
+
+optParser :: CmdParamsDesc -> Parser AddOptions
+optParser desc = AddOptions
+	<$> cmdParams desc
+	<*> parseBatchOption False
+	<*> switch
+		( long "update"
+		<> short 'u'
+		<> help "only update tracked files"
+		)
+	<*> (parseforcelarge <|> parseforcesmall)
+	<*> checkGitIgnoreSwitch
+	<*> parseDryRunOption
+  where
+	parseforcelarge = flag Nothing (Just True)
+		( long "force-large"
+		<> help "add all files to annex, ignoring other configuration"
+		)
+	parseforcesmall = flag Nothing (Just False)
+		( long "force-small"
+		<> help "add all files to git, ignoring other configuration"
+		)
+
+checkGitIgnoreSwitch :: Parser CheckGitIgnore
+checkGitIgnoreSwitch = CheckGitIgnore <$>
+	invertableSwitch "check-gitignore" True
+		(help "Do not check .gitignore when adding files")
+
+seek :: AddOptions -> CommandSeek
+seek o = startConcurrency commandStages (seek' o)
+
+seek' :: AddOptions -> CommandSeek
+seek' o = do
+	largematcher <- largeFilesMatcher
+	addunlockedmatcher <- addUnlockedMatcher
+	annexdotfiles <- getGitConfigVal annexDotFiles 
+	let gofile includingsmall (si, file) = case largeFilesOverride o of
+		Nothing -> ifM (pure (annexdotfiles || not (dotfile file))
+			<&&> (checkFileMatcher largematcher file 
+			<||> Annex.getRead Annex.force))
+			( start dr si file addunlockedmatcher
+			, if includingsmall
+				then ifM (annexAddSmallFiles <$> Annex.getGitConfig)
+					( startSmall dr si file
+					, stop
+					)
+				else stop
+			)
+		Just True -> start dr si file addunlockedmatcher
+		Just False -> startSmallOverridden dr si file
+	case batchOption o of
+		Batch fmt
+			| updateOnly o ->
+				giveup "--update --batch is not supported"
+			| otherwise -> batchOnly Nothing (addThese o) $
+				batchFiles fmt $ \v@(_si, file) -> 
+					ifM (checkIgnored (checkGitIgnoreOption o) file)
+						( stop
+						, gofile True v
+						)
+		NoBatch -> do
+			-- Avoid git ls-files complaining about files that
+			-- are not known to git yet, since this will add
+			-- them. Instead, have workTreeItems warn about other
+			-- problems, like files that don't exist.
+			let ww = WarnUnmatchWorkTreeItems "add"
+			l <- workTreeItems ww (addThese o)
+			let go b a = a ww (commandAction . gofile b) l
+			unless (updateOnly o) $
+				go True (withFilesNotInGit (checkGitIgnoreOption o))
+			go True withFilesMaybeModified
+			-- Convert newly unlocked files back to locked files,
+			-- same as a modified unlocked file would get
+			-- locked when added.
+			go False withUnmodifiedUnlockedPointers
+  where
+	dr = dryRunOption o
+
+{- Pass file off to git-add. -}
+startSmall :: DryRun -> SeekInput -> RawFilePath -> CommandStart
+startSmall dr si file =
+	liftIO (catchMaybeIO $ R.getSymbolicLinkStatus file) >>= \case
+		Just s -> 
+			starting "add" (ActionItemTreeFile file) si $
+				addSmall dr file s
+		Nothing -> stop
+
+addSmall :: DryRun -> RawFilePath -> FileStatus -> CommandPerform
+addSmall dr file s = do
+	showNote "non-large file; adding content to git repository"
+	skipWhenDryRun dr $ next $ addFile Small file s
+
+startSmallOverridden :: DryRun -> SeekInput -> RawFilePath -> CommandStart
+startSmallOverridden dr si file = 
+	liftIO (catchMaybeIO $ R.getSymbolicLinkStatus file) >>= \case
+		Just s -> starting "add" (ActionItemTreeFile file) si $ do
+			showNote "adding content to git repository"
+			skipWhenDryRun dr $ next $ addFile Small file s
+		Nothing -> stop
+
+data SmallOrLarge = Small | Large
+
+addFile :: SmallOrLarge -> RawFilePath -> FileStatus -> Annex Bool
+addFile smallorlarge file s = do
+	sha <- if isSymbolicLink s
+		then hashBlob =<< liftIO (R.readSymbolicLink file)
+		else if isRegularFile s
+			then hashFile file
+			else do
+				qp <- coreQuotePath <$> Annex.getGitConfig
+				giveup $ decodeBS $ quote qp $
+					file <> " is not a regular file"
+	let treetype = if isSymbolicLink s
+		then TreeSymlink
+		else if intersectFileModes ownerExecuteMode (fileMode s) /= 0
+			then TreeExecutable
+			else TreeFile
+	s' <- liftIO $ catchMaybeIO $ R.getSymbolicLinkStatus file
+	if maybe True (changed s) s'
+		then do
+			warning $ QuotedPath file <> " changed while it was being added"
+			return False
+		else do
+			case smallorlarge of
+				-- In case the file is being converted from 
+				-- an annexed file to be stored in git,
+				-- remove the cached inode, so that if the
+				-- smudge clean filter later runs on the file,
+				-- it will not remember it was annexed.
+				Small -> maybe noop Database.Keys.removeInodeCache
+					=<< withTSDelta (liftIO . genInodeCache file)
+				Large -> noop
+			Annex.Queue.addUpdateIndex =<<
+				inRepo (stageFile sha treetype file)
+			return True
+  where
+	changed a b =
+		deviceID a /= deviceID b ||
+		fileID a /= fileID b ||
+		fileSize a /= fileSize b ||
+		modificationTime a /= modificationTime b ||
+		isRegularFile a /= isRegularFile b ||
+		isSymbolicLink a /= isSymbolicLink b
+
+start :: DryRun -> SeekInput -> RawFilePath -> AddUnlockedMatcher -> CommandStart
+start dr si file addunlockedmatcher = 
+	liftIO (catchMaybeIO $ R.getSymbolicLinkStatus file) >>= \case
+		Nothing -> stop
+		Just s
+			| not (isRegularFile s) && not (isSymbolicLink s) -> stop
+			| otherwise -> do
+				mk <- liftIO $ isPointerFile file
+				maybe (go s) (fixuppointer s) mk
+  where
+	go s = lookupKey file >>= \case
+		Just k -> addpresent s k
+		Nothing -> add s
+	add s = starting "add" (ActionItemTreeFile file) si $
+		skipWhenDryRun dr $
+			if isSymbolicLink s
+				then next $ addFile Small file s
+				else perform file addunlockedmatcher
+	addpresent s key
+		| isSymbolicLink s = fixuplink key
+		| otherwise = add s
+	fixuplink key = 
+		starting "add" (ActionItemTreeFile file) si $
+			addingExistingLink file key $
+				skipWhenDryRun dr $ withOtherTmp $ \tmp -> do
+					let tmpf = tmp P.</> P.takeFileName file
+					liftIO $ moveFile file tmpf
+					ifM (isSymbolicLink <$> liftIO (R.getSymbolicLinkStatus tmpf))
+						( do
+							liftIO $ R.removeLink tmpf
+							addSymlink file key Nothing
+							next $ cleanup key =<< inAnnex key
+						, do
+							liftIO $ moveFile tmpf file
+							next $ return True
+						)
+	fixuppointer s key =
+		starting "add" (ActionItemTreeFile file) si $
+			addingExistingLink file key $
+				skipWhenDryRun dr $ do
+					Database.Keys.addAssociatedFile key =<< inRepo (toTopFilePath file)
+					next $ addFile Large file s
+
+perform :: RawFilePath -> AddUnlockedMatcher -> CommandPerform
+perform file addunlockedmatcher = withOtherTmp $ \tmpdir -> do
+	lockingfile <- not <$> addUnlocked addunlockedmatcher
+		(MatchingFile (FileInfo file file Nothing))
+		True
+	let cfg = LockDownConfig
+		{ lockingFile = lockingfile
+		, hardlinkFileTmpDir = Just tmpdir
+		, checkWritePerms = True
+		}
+	ld <- lockDown cfg (fromRawFilePath file)
+	let sizer = keySource <$> ld
+	v <- metered Nothing sizer Nothing $ \_meter meterupdate ->
+		ingestAdd meterupdate ld
+	finish v
+  where
+	finish (Just key) = next $ cleanup key True
+	finish Nothing = stop
+
+cleanup :: Key -> Bool -> CommandCleanup
+cleanup key hascontent = do
+	maybeShowJSON $ JSONChunk [("key", serializeKey key)]
+	when hascontent $
+		logStatus key InfoPresent
+	return True
diff --git a/Command/AddUnused.hs b/Command/AddUnused.hs
new file mode 100644
index 0000000000..9ce2881bba
--- /dev/null
+++ b/Command/AddUnused.hs
@@ -0,0 +1,43 @@
+{- git-annex command
+ -
+ - Copyright 2012-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.AddUnused where
+
+import Logs.Location
+import Command
+import Annex.Ingest
+import Command.Unused (withUnusedMaps, UnusedMaps(..), startUnused)
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "addunused" SectionMaintenance 
+		"add back unused files"
+		(paramRepeating paramNumRange) (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withUnusedMaps start
+
+start :: UnusedMaps -> Int -> CommandStart
+start = startUnused go (other "bad") (other "tmp")
+  where
+	go n key = do
+		let file = "unused." <> keyFile key
+		starting "addunused"
+			(ActionItemTreeFile file)
+			(SeekInput [show n]) $
+			next $ do
+				logStatus key InfoPresent
+				addSymlink file key Nothing
+				return True
+
+	{- The content is not in the annex, but in another directory, and
+	 - it seems better to error out, rather than moving bad/tmp content
+	 - into the annex. -}
+	other n _ _ = giveup $ "cannot addunused " ++ n ++ "content"
+
diff --git a/Command/AddUrl.hs b/Command/AddUrl.hs
new file mode 100644
index 0000000000..970089c02d
--- /dev/null
+++ b/Command/AddUrl.hs
@@ -0,0 +1,610 @@
+{- git-annex command
+ -
+ - Copyright 2011-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.AddUrl where
+
+import Command
+import Backend
+import qualified Annex
+import qualified Annex.Url as Url
+import qualified Backend.URL
+import qualified Remote
+import qualified Types.Remote as Remote
+import qualified Command.Add
+import Annex.Content
+import Annex.Ingest
+import Annex.CheckIgnore
+import Annex.Perms
+import Annex.UUID
+import Annex.WorkTree
+import Annex.YoutubeDl
+import Annex.UntrustedFilePath
+import Logs.Web
+import Types.KeySource
+import Types.UrlContents
+import Annex.FileMatcher
+import Logs.Location
+import Utility.Metered
+import Utility.HtmlDetect
+import Utility.Path.Max
+import Utility.Url.Parse
+import qualified Utility.RawFilePath as R
+import qualified Annex.Transfer as Transfer
+
+import Network.URI
+import qualified System.FilePath.ByteString as P
+
+cmd :: Command
+cmd = notBareRepo $ withAnnexOptions 
+	[ jobsOption
+	, jsonOptions
+	, jsonProgressOption
+	, backendOption
+	] $
+	command "addurl" SectionCommon "add urls to annex"
+		(paramRepeating paramUrl) (seek <$$> optParser)
+
+data AddUrlOptions = AddUrlOptions
+	{ addUrls :: CmdParams
+	, pathdepthOption :: Maybe Int
+	, prefixOption :: Maybe String
+	, suffixOption :: Maybe String
+	, downloadOptions :: DownloadOptions
+	, batchOption :: BatchMode
+	, batchFilesOption :: Bool
+	}
+
+data DownloadOptions = DownloadOptions
+	{ relaxedOption :: Bool
+	, verifiableOption :: Bool
+	, rawOption :: Bool
+	, noRawOption :: Bool
+	, rawExceptOption :: Maybe (DeferredParse Remote)
+	, fileOption :: Maybe FilePath
+	, preserveFilenameOption :: Bool
+	, checkGitIgnoreOption :: CheckGitIgnore
+	}
+
+optParser :: CmdParamsDesc -> Parser AddUrlOptions
+optParser desc = AddUrlOptions
+	<$> cmdParams desc
+	<*> optional (option auto
+		( long "pathdepth" <> metavar paramNumber
+		<> help "number of url path components to use in filename"
+		))
+	<*> optional (strOption
+		( long "prefix" <> metavar paramValue
+		<> help "add a prefix to the filename"
+		))
+	<*> optional (strOption
+		( long "suffix" <> metavar paramValue
+		<> help "add a suffix to the filename"
+		))
+	<*> parseDownloadOptions True
+	<*> parseBatchOption False
+	<*> switch
+		( long "with-files"
+		<> help "parse batch mode lines of the form \"$url $file\""
+		)
+
+parseDownloadOptions :: Bool -> Parser DownloadOptions
+parseDownloadOptions withfileoptions = DownloadOptions
+	<$> switch
+		( long "relaxed"
+		<> help "accept whatever content is downloaded from web even if it changes"
+		)
+	<*> switch
+		( long "verifiable"
+		<> short 'V'
+		<> help "improve later verification of --fast or --relaxed content"
+		)
+	<*> switch
+		( long "raw"
+		<> help "disable special handling for torrents, youtube-dl, etc"
+		)
+	<*> switch
+		( long "no-raw"
+		<> help "prevent downloading raw url content, must use special handling"
+		)
+	<*> optional
+		(mkParseRemoteOption <$> strOption
+		        ( long "raw-except" <> metavar paramRemote
+			<> help "disable special handling except by this remote"
+			<> completeRemotes
+			)
+		)
+	<*> (if withfileoptions
+		then optional (strOption
+			( long "file" <> metavar paramFile
+			<> help "specify what file the url is added to"
+			))
+		else pure Nothing)
+	<*> (if withfileoptions
+		then switch
+			( long "preserve-filename"
+			<> help "use filename provided by server as-is"
+			)
+		else pure False)
+	<*> Command.Add.checkGitIgnoreSwitch
+
+seek :: AddUrlOptions -> CommandSeek
+seek o = startConcurrency commandStages $ do
+	addunlockedmatcher <- addUnlockedMatcher
+	let go (si, (o', u)) = do
+		r <- checkClaimingUrl (downloadOptions o) u
+		if Remote.uuid r == webUUID || rawOption (downloadOptions o')
+			then void $ commandAction $
+				startWeb addunlockedmatcher o' si u
+			else checkUrl addunlockedmatcher r o' si u
+	case batchOption o of
+		Batch fmt -> batchOnly Nothing (addUrls o) $
+			batchInput fmt (pure . parseBatchInput o) go
+		NoBatch -> forM_ (addUrls o) (\u -> go (SeekInput [u], (o, u)))
+
+checkClaimingUrl :: DownloadOptions -> URLString -> Annex Remote
+checkClaimingUrl o u = do
+	allowedremote <- case rawExceptOption o of
+                Nothing -> pure (const True)
+                Just f -> (==) <$> getParsed f
+	Remote.claimingUrl' allowedremote u
+
+parseBatchInput :: AddUrlOptions -> String -> Either String (AddUrlOptions, URLString)
+parseBatchInput o s
+	| batchFilesOption o =
+		let (u, f) = separate (== ' ') s
+		in if null u || null f
+			then Left ("parsed empty url or filename in input: " ++ s)
+			else Right (o { downloadOptions = (downloadOptions o) { fileOption = Just f } }, u)
+	| otherwise = Right (o, s)
+
+checkUrl :: AddUnlockedMatcher -> Remote -> AddUrlOptions -> SeekInput -> URLString -> Annex ()
+checkUrl addunlockedmatcher r o si u = do
+	pathmax <- liftIO $ fileNameLengthLimit "."
+	let deffile = fromMaybe (urlString2file u (pathdepthOption o) pathmax) (fileOption (downloadOptions o))
+	go deffile =<< maybe
+		(giveup $ "unable to checkUrl of " ++ Remote.name r)
+		(tryNonAsync . flip id u)
+		(Remote.checkUrl r)
+  where
+
+	go _ (Left e) = void $ commandAction $ startingAddUrl si u o $ do
+		warning (UnquotedString (show e))
+		next $ return False
+	go deffile (Right (UrlContents sz mf)) = do
+		f <- maybe (pure deffile) (sanitizeOrPreserveFilePath o) mf
+		let f' = adjustFile o (fromMaybe f (fileOption (downloadOptions o)))
+		void $ commandAction $ startRemote addunlockedmatcher r o si f' u sz
+	go deffile (Right (UrlMulti l)) = case fileOption (downloadOptions o) of
+		Nothing ->
+			forM_ l $ \(u', sz, f) -> do
+				f' <- sanitizeOrPreserveFilePath o f
+				let f'' = adjustFile o (deffile </> f')
+				void $ commandAction $ startRemote addunlockedmatcher r o si f'' u' sz
+		Just f -> case l of
+			[] -> noop
+			((u',sz,_):[]) -> do
+				let f' = adjustFile o f
+				void $ commandAction $ startRemote addunlockedmatcher r o si f' u' sz
+			_ -> giveup $ unwords
+				[ "That url contains multiple files according to the"
+				, Remote.name r
+				, " remote; cannot add it to a single file."
+				]
+
+startRemote :: AddUnlockedMatcher -> Remote -> AddUrlOptions -> SeekInput -> FilePath -> URLString -> Maybe Integer -> CommandStart
+startRemote addunlockedmatcher r o si file uri sz = do
+	pathmax <- liftIO $ fileNameLengthLimit "."
+	let file' = joinPath $ map (truncateFilePath pathmax) $
+		splitDirectories file
+	startingAddUrl si uri o $ do
+		showNote $ UnquotedString $ "from " ++ Remote.name r 
+		showDestinationFile (toRawFilePath file')
+		performRemote addunlockedmatcher r o uri (toRawFilePath file') sz
+
+performRemote :: AddUnlockedMatcher -> Remote -> AddUrlOptions -> URLString -> RawFilePath -> Maybe Integer -> CommandPerform
+performRemote addunlockedmatcher r o uri file sz = lookupKey file >>= \case
+	Just k -> adduri k
+	Nothing -> geturi
+  where
+	loguri = setDownloader uri OtherDownloader
+	adduri = addUrlChecked o loguri file (Remote.uuid r) checkexistssize
+	checkexistssize key = return $ Just $ case sz of
+		Nothing -> (True, True, loguri)
+		Just n -> (True, n == fromMaybe n (fromKey keySize key), loguri)
+	geturi = next $ isJust <$> downloadRemoteFile addunlockedmatcher r (downloadOptions o) uri file sz
+
+downloadRemoteFile :: AddUnlockedMatcher -> Remote -> DownloadOptions -> URLString -> RawFilePath -> Maybe Integer -> Annex (Maybe Key)
+downloadRemoteFile addunlockedmatcher r o uri file sz = checkCanAdd o file $ \canadd -> do
+	let urlkey = Backend.URL.fromUrl uri sz (verifiableOption o)
+	createWorkTreeDirectory (parentDir file)
+	ifM (Annex.getRead Annex.fast <||> pure (relaxedOption o))
+		( do
+			addWorkTree canadd addunlockedmatcher (Remote.uuid r) loguri file urlkey Nothing
+			return (Just urlkey)
+		, do
+			-- Set temporary url for the urlkey
+			-- so that the remote knows what url it
+			-- should use to download it.
+			setTempUrl urlkey loguri
+			let downloader = \dest p ->
+				fst <$> Remote.verifiedAction
+					(Remote.retrieveKeyFile r urlkey af dest p (RemoteVerify r))
+			ret <- downloadWith canadd addunlockedmatcher downloader urlkey (Remote.uuid r) loguri file
+			removeTempUrl urlkey
+			return ret
+		)
+  where
+	loguri = setDownloader uri OtherDownloader
+	af = AssociatedFile (Just file)
+
+startWeb :: AddUnlockedMatcher -> AddUrlOptions -> SeekInput -> URLString -> CommandStart
+startWeb addunlockedmatcher o si urlstring = go $ fromMaybe bad $ parseURIPortable urlstring
+  where
+	bad = fromMaybe (giveup $ "bad url " ++ urlstring) $
+		Url.parseURIRelaxed $ urlstring
+	go url = startingAddUrl si urlstring o $
+		if relaxedOption (downloadOptions o)
+			then go' url Url.assumeUrlExists
+			else Url.withUrlOptions (Url.getUrlInfo urlstring) >>= \case
+				Right urlinfo -> go' url urlinfo
+				Left err -> do
+					warning (UnquotedString err)
+					next $ return False
+	go' url urlinfo = do
+		pathmax <- liftIO $ fileNameLengthLimit "."
+		file <- adjustFile o <$> case fileOption (downloadOptions o) of
+			Just f -> pure f
+			Nothing -> case Url.urlSuggestedFile urlinfo of
+				Just sf -> do
+					f <- sanitizeOrPreserveFilePath o sf
+					if preserveFilenameOption (downloadOptions o)
+						then pure f
+						else ifM (liftIO $ doesFileExist f <||> doesDirectoryExist f)
+							( pure $ url2file url (pathdepthOption o) pathmax
+							, pure f
+							)
+				_ -> pure $ url2file url (pathdepthOption o) pathmax
+		performWeb addunlockedmatcher o urlstring (toRawFilePath file) urlinfo
+
+sanitizeOrPreserveFilePath :: AddUrlOptions -> FilePath -> Annex FilePath
+sanitizeOrPreserveFilePath o f
+	| preserveFilenameOption (downloadOptions o) && not (null f) = do
+		checkPreserveFileNameSecurity f
+		return f
+	| otherwise = do
+		pathmax <- liftIO $ fileNameLengthLimit "."
+		return $ truncateFilePath pathmax $ sanitizeFilePath f
+
+-- sanitizeFilePath avoids all these security problems
+-- (and probably others, but at least this catches the most egrarious ones).
+checkPreserveFileNameSecurity :: FilePath -> Annex ()
+checkPreserveFileNameSecurity f = do
+	checksecurity controlCharacterInFilePath "control character"
+	checksecurity pathTraversalInFilePath "path traversal"
+	checksecurity gitDirectoryInFilePath "contains a .git directory"
+  where
+	checksecurity p d = when (p f) $ do
+		qp <- coreQuotePath <$> Annex.getGitConfig
+		giveup $ decodeBS $ quote qp $
+			"--preserve-filename was used, but the filename ("
+				<> QuotedPath (toRawFilePath f)
+				<> ") has a security problem ("
+				<> d
+				<> "), not adding."
+
+performWeb :: AddUnlockedMatcher -> AddUrlOptions -> URLString -> RawFilePath -> Url.UrlInfo -> CommandPerform
+performWeb addunlockedmatcher o url file urlinfo = lookupKey file >>= \case
+	Just k -> addurl k
+	Nothing -> geturl
+  where
+	geturl = next $ isJust <$> addUrlFile addunlockedmatcher (downloadOptions o) url urlinfo file
+	addurl = addUrlChecked o url file webUUID $ \k ->
+		ifM (useYoutubeDl (downloadOptions o) <&&> youtubeDlSupported url)
+			( return (Just (True, True, setDownloader url YoutubeDownloader))
+			, checkRaw Nothing (downloadOptions o) (pure Nothing) $
+				return (Just (Url.urlExists urlinfo, Url.urlSize urlinfo == fromKey keySize k, url))
+			)
+
+{- Check that the url exists, and has the same size as the key,
+ - and add it as an url to the key. -}
+addUrlChecked :: AddUrlOptions -> URLString -> RawFilePath -> UUID -> (Key -> Annex (Maybe (Bool, Bool, URLString))) -> Key -> CommandPerform
+addUrlChecked o url file u checkexistssize key =
+	ifM ((elem url <$> getUrls key) <&&> (elem u <$> loggedLocations key))
+		( do
+			showDestinationFile file
+			next $ return True
+		, checkexistssize key >>= \case
+			Just (exists, samesize, url')
+				| exists && (samesize || relaxedOption (downloadOptions o)) -> do
+					setUrlPresent key url'
+					logChange key u InfoPresent
+					next $ return True
+				| otherwise -> do
+					warning $ UnquotedString $ "while adding a new url to an already annexed file, " ++ if exists
+						then "url does not have expected file size (use --relaxed to bypass this check) " ++ url
+						else "failed to verify url exists: " ++ url
+					stop
+			Nothing -> stop
+		)
+
+{- Downloads an url (except in fast or relaxed mode) and adds it to the
+ - repository, normally at the specified FilePath. 
+ - But, if youtube-dl supports the url, it will be written to a
+ - different file, based on the title of the media. Unless the user
+ - specified fileOption, which then forces using the FilePath.
+ -}
+addUrlFile :: AddUnlockedMatcher -> DownloadOptions -> URLString -> Url.UrlInfo -> RawFilePath -> Annex (Maybe Key)
+addUrlFile addunlockedmatcher o url urlinfo file =
+	ifM (Annex.getRead Annex.fast <||> pure (relaxedOption o))
+		( nodownloadWeb addunlockedmatcher o url urlinfo file
+		, downloadWeb addunlockedmatcher o url urlinfo file
+		)
+
+downloadWeb :: AddUnlockedMatcher -> DownloadOptions -> URLString -> Url.UrlInfo -> RawFilePath -> Annex (Maybe Key)
+downloadWeb addunlockedmatcher o url urlinfo file =
+	go =<< downloadWith' downloader urlkey webUUID url file
+  where
+	urlkey = addSizeUrlKey urlinfo $ Backend.URL.fromUrl url Nothing (verifiableOption o)
+	downloader f p = Url.withUrlOptions $ downloadUrl False urlkey p Nothing [url] f
+	go Nothing = return Nothing
+	go (Just (tmp, backend)) = ifM (useYoutubeDl o <&&> liftIO (isHtmlFile (fromRawFilePath tmp)))
+		( tryyoutubedl tmp backend
+		, normalfinish tmp backend
+		)
+	normalfinish tmp backend = checkCanAdd o file $ \canadd -> do
+		showDestinationFile file
+		createWorkTreeDirectory (parentDir file)
+		Just <$> finishDownloadWith canadd addunlockedmatcher tmp backend webUUID url file
+	-- Ask youtube-dl what filename it will download first, 
+	-- so it's only used when the file contains embedded media.
+	tryyoutubedl tmp backend = youtubeDlFileNameHtmlOnly url >>= \case
+		Right mediafile -> do
+			liftIO $ liftIO $ removeWhenExistsWith R.removeLink tmp
+			let f = youtubeDlDestFile o file (toRawFilePath mediafile)
+			lookupKey f >>= \case
+				Just k -> alreadyannexed f k
+				Nothing -> dl f
+		Left err -> checkRaw (Just err) o (pure Nothing) (normalfinish tmp backend)
+	  where
+		dl dest = withTmpWorkDir mediakey $ \workdir -> do
+			let cleanuptmp = pruneTmpWorkDirBefore tmp (liftIO . removeWhenExistsWith R.removeLink)
+			dlcmd <- youtubeDlCommand
+			showNote ("using " <> UnquotedString dlcmd)
+			Transfer.notifyTransfer Transfer.Download url $
+				Transfer.download' webUUID mediakey (AssociatedFile Nothing) Nothing Transfer.noRetry $ \p -> do
+					showDestinationFile dest
+					youtubeDl url (fromRawFilePath workdir) p >>= \case
+						Right (Just mediafile) -> do
+							cleanuptmp
+							checkCanAdd o dest $ \canadd -> do
+								addWorkTree canadd addunlockedmatcher webUUID mediaurl dest mediakey (Just (toRawFilePath mediafile))
+								return $ Just mediakey
+						Left msg -> do
+							cleanuptmp
+							warning (UnquotedString msg)
+							return Nothing
+						Right Nothing -> do
+							cleanuptmp
+							warning (UnquotedString dlcmd <> " did not download anything")
+							return Nothing
+		mediaurl = setDownloader url YoutubeDownloader
+		mediakey = Backend.URL.fromUrl mediaurl Nothing (verifiableOption o)
+		-- Does the already annexed file have the mediaurl
+		-- as an url? If so nothing to do.
+		alreadyannexed dest k = do
+			us <- getUrls k
+			if mediaurl `elem` us
+				then return (Just k)
+				else do
+					warning $ QuotedPath dest <> " already exists; not overwriting"
+					return Nothing
+	
+checkRaw :: (Maybe String) -> DownloadOptions -> Annex a -> Annex a -> Annex a
+checkRaw failreason o f a
+	| noRawOption o = do
+		warning $ UnquotedString $ "Unable to use youtube-dl or a special remote and --no-raw was specified" ++
+			case failreason of
+				Just msg -> ": " ++ msg
+				Nothing -> ""
+		f
+	| otherwise = a
+
+useYoutubeDl :: DownloadOptions -> Annex Bool
+useYoutubeDl o
+	| rawOption o = pure False
+	| otherwise = case rawExceptOption o of
+                Nothing -> pure True
+                Just f -> do
+			remote <- getParsed f
+			pure (Remote.uuid remote == webUUID)
+
+{- The destination file is not known at start time unless the user provided
+ - a filename. It's not displayed then for output consistency, 
+ - but is added to the json when available. -}
+startingAddUrl :: SeekInput -> URLString -> AddUrlOptions -> CommandPerform -> CommandStart
+startingAddUrl si url o p = starting "addurl" ai si $ do
+	case fileOption (downloadOptions o) of
+		Nothing -> noop
+		Just file -> maybeShowJSON $ JSONChunk [("file", file)]
+	p
+  where
+	-- Avoid failure when the same url is downloaded concurrently
+	-- to two different files, by using OnlyActionOn with a key
+	-- based on the url. Note that this may not be the actual key
+	-- that is used for the download; later size information may be
+	-- available and get added to it. That's ok, this is only
+	-- used to prevent two threads running concurrently when that would
+	-- likely fail.
+	ai = OnlyActionOn urlkey (ActionItemOther (Just (UnquotedString url)))
+	urlkey = Backend.URL.fromUrl url Nothing (verifiableOption (downloadOptions o))
+
+showDestinationFile :: RawFilePath -> Annex ()
+showDestinationFile file = do
+	showNote ("to " <> QuotedPath file)
+	maybeShowJSON $ JSONChunk [("file", fromRawFilePath file)]
+
+{- The Key should be a dummy key, based on the URL, which is used
+ - for this download, before we can examine the file and find its real key.
+ - For resuming downloads to work, the dummy key for a given url should be
+ - stable. For disk space checking to work, the dummy key should have
+ - the size of the url already set.
+ -
+ - Downloads the url, sets up the worktree file, and returns the
+ - real key.
+ -}
+downloadWith :: CanAddFile -> AddUnlockedMatcher -> (FilePath -> MeterUpdate -> Annex Bool) -> Key -> UUID -> URLString -> RawFilePath -> Annex (Maybe Key)
+downloadWith canadd addunlockedmatcher downloader dummykey u url file =
+	go =<< downloadWith' downloader dummykey u url file
+  where
+	go Nothing = return Nothing
+	go (Just (tmp, backend)) = Just <$> finishDownloadWith canadd addunlockedmatcher tmp backend u url file
+
+{- Like downloadWith, but leaves the dummy key content in
+ - the returned location. -}
+downloadWith' :: (FilePath -> MeterUpdate -> Annex Bool) -> Key -> UUID -> URLString -> RawFilePath -> Annex (Maybe (RawFilePath, Backend))
+downloadWith' downloader dummykey u url file =
+	checkDiskSpaceToGet dummykey Nothing Nothing $ do
+		backend <- chooseBackend file
+		tmp <- fromRepo $ gitAnnexTmpObjectLocation dummykey
+		let t = (Transfer.Transfer Transfer.Download u (fromKey id dummykey))
+		ok <- Transfer.notifyTransfer Transfer.Download url $ \_w ->
+			Transfer.runTransfer t (Just backend) afile Nothing Transfer.stdRetry $ \p -> do
+				createAnnexDirectory (parentDir tmp)
+				downloader (fromRawFilePath tmp) p
+		if ok
+			then return (Just (tmp, backend))
+			else return Nothing
+  where
+	afile = AssociatedFile (Just file)
+
+finishDownloadWith :: CanAddFile -> AddUnlockedMatcher -> RawFilePath -> Backend -> UUID -> URLString -> RawFilePath -> Annex Key
+finishDownloadWith canadd addunlockedmatcher tmp backend u url file = do
+	let source = KeySource
+		{ keyFilename = file
+		, contentLocation = tmp
+		, inodeCache = Nothing
+		}
+	key <- fst <$> genKey source nullMeterUpdate backend
+	addWorkTree canadd addunlockedmatcher u url file key (Just tmp)
+	return key
+
+{- Adds the url size to the Key. -}
+addSizeUrlKey :: Url.UrlInfo -> Key -> Key
+addSizeUrlKey urlinfo key = alterKey key $ \d -> d
+	{ keySize = Url.urlSize urlinfo
+	}
+
+{- Adds worktree file to the repository. -}
+addWorkTree :: CanAddFile -> AddUnlockedMatcher -> UUID -> URLString -> RawFilePath -> Key -> Maybe RawFilePath -> Annex ()
+addWorkTree _ addunlockedmatcher u url file key mtmp = case mtmp of
+	Nothing -> go
+	Just tmp -> do
+		s <- liftIO $ R.getSymbolicLinkStatus tmp
+		-- Move to final location for large file check.
+		pruneTmpWorkDirBefore tmp $ \_ -> do
+			createWorkTreeDirectory (P.takeDirectory file)
+			liftIO $ moveFile tmp file
+		largematcher <- largeFilesMatcher
+		large <- checkFileMatcher largematcher file
+		if large
+			then do
+				-- Move back to tmp because addAnnexedFile
+				-- needs the file in a different location
+				-- than the work tree file.
+				liftIO $ moveFile file tmp
+				go
+			else Command.Add.addSmall (DryRun False) file s
+				>>= maybe noop void
+  where
+	go = do
+		maybeShowJSON $ JSONChunk [("key", serializeKey key)]
+		setUrlPresent key url
+		logChange key u InfoPresent
+		ifM (addAnnexedFile addunlockedmatcher file key mtmp)
+			( do
+				when (isJust mtmp) $
+					logStatus key InfoPresent
+			, maybe noop (\tmp -> pruneTmpWorkDirBefore tmp (liftIO . removeWhenExistsWith R.removeLink)) mtmp
+			)
+
+nodownloadWeb :: AddUnlockedMatcher -> DownloadOptions -> URLString -> Url.UrlInfo -> RawFilePath -> Annex (Maybe Key)
+nodownloadWeb addunlockedmatcher o url urlinfo file
+	| Url.urlExists urlinfo = if rawOption o
+		then nomedia
+		else youtubeDlFileName url >>= \case
+			Right mediafile -> usemedia (toRawFilePath mediafile)
+			Left err -> checkRaw (Just err) o (pure Nothing) nomedia
+	| otherwise = do
+		warning $ UnquotedString $ "unable to access url: " ++ url
+		return Nothing
+  where
+	nomedia = do
+		let key = Backend.URL.fromUrl url (Url.urlSize urlinfo) (verifiableOption o)
+		nodownloadWeb' o addunlockedmatcher url key file
+	usemedia mediafile = do
+		let dest = youtubeDlDestFile o file mediafile
+		let mediaurl = setDownloader url YoutubeDownloader
+		let mediakey = Backend.URL.fromUrl mediaurl Nothing (verifiableOption o)
+		nodownloadWeb' o addunlockedmatcher mediaurl mediakey dest
+
+youtubeDlDestFile :: DownloadOptions -> RawFilePath -> RawFilePath -> RawFilePath
+youtubeDlDestFile o destfile mediafile
+	| isJust (fileOption o) = destfile
+	| otherwise = P.takeFileName mediafile
+
+nodownloadWeb' :: DownloadOptions -> AddUnlockedMatcher -> URLString -> Key -> RawFilePath -> Annex (Maybe Key)
+nodownloadWeb' o addunlockedmatcher url key file = checkCanAdd o file $ \canadd -> do
+	showDestinationFile file
+	createWorkTreeDirectory (parentDir file)
+	addWorkTree canadd addunlockedmatcher webUUID url file key Nothing
+	return (Just key)
+
+url2file :: URI -> Maybe Int -> Int -> FilePath
+url2file url pathdepth pathmax = case pathdepth of
+	Nothing -> truncateFilePath pathmax $ sanitizeFilePath fullurl
+	Just depth
+		| depth >= length urlbits -> frombits id
+		| depth > 0 -> frombits $ drop depth
+		| depth < 0 -> frombits $ reverse . take (negate depth) . reverse
+		| otherwise -> giveup "bad --pathdepth"
+  where
+	fullurl = concat
+		[ maybe "" uriRegName (uriAuthority url)
+		, uriPath url
+		, uriQuery url
+		]
+	frombits a = intercalate "/" $ a urlbits
+	urlbits = map (truncateFilePath pathmax . sanitizeFilePath) $
+		filter (not . null) $ splitc '/' fullurl
+
+urlString2file :: URLString -> Maybe Int -> Int -> FilePath
+urlString2file s pathdepth pathmax = case Url.parseURIRelaxed s of
+	Nothing -> giveup $ "bad uri " ++ s
+	Just u -> url2file u pathdepth pathmax
+
+adjustFile :: AddUrlOptions -> FilePath -> FilePath
+adjustFile o = addprefix . addsuffix
+  where
+	addprefix f = maybe f (++ f) (prefixOption o)
+	addsuffix f = maybe f (f ++) (suffixOption o)
+
+data CanAddFile = CanAddFile
+
+checkCanAdd :: DownloadOptions -> RawFilePath -> (CanAddFile -> Annex (Maybe a)) -> Annex (Maybe a)
+checkCanAdd o file a = ifM (isJust <$> (liftIO $ catchMaybeIO $ R.getSymbolicLinkStatus file))
+	( do
+		warning $ QuotedPath file <> " already exists; not overwriting"
+		return Nothing
+	, ifM (checkIgnored (checkGitIgnoreOption o) file)
+		( do
+			warning $ "not adding " <> QuotedPath file <> " which is .gitignored (use --no-check-gitignore to override)"
+			return Nothing
+		, a CanAddFile
+		)
+	)
diff --git a/Command/Adjust.hs b/Command/Adjust.hs
new file mode 100644
index 0000000000..6e15ef8af9
--- /dev/null
+++ b/Command/Adjust.hs
@@ -0,0 +1,63 @@
+{- git-annex command
+ -
+ - Copyright 2016-2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Adjust where
+
+import Command
+import Annex.AdjustedBranch
+
+cmd :: Command
+cmd = notBareRepo $ noDaemonRunning $
+	command "adjust" SectionSetup "enter adjusted branch"
+		paramNothing (seek <$$> optParser)
+
+optParser :: CmdParamsDesc -> Parser Adjustment
+optParser _ =
+	(LinkAdjustment <$> linkAdjustmentParser)
+	<|> (PresenceAdjustment <$> presenceAdjustmentParser <*> maybeLinkAdjustmentParser)
+	<|> (LinkPresentAdjustment <$> linkPresentAdjustmentParser)
+
+linkAdjustmentParser :: Parser LinkAdjustment
+linkAdjustmentParser =
+	flag' UnlockAdjustment
+		( long "unlock"
+		<> help "unlock annexed files"
+		)
+	<|> flag' LockAdjustment
+		( long "lock"
+		<> help "lock annexed files"
+		)
+	<|> flag' FixAdjustment
+		( long "fix"
+		<> help "fix symlinks to annnexed files"
+		)
+
+maybeLinkAdjustmentParser :: Parser (Maybe LinkAdjustment)
+maybeLinkAdjustmentParser = Just <$> linkAdjustmentParser <|> pure Nothing
+
+presenceAdjustmentParser :: Parser PresenceAdjustment
+presenceAdjustmentParser =
+	flag' HideMissingAdjustment
+		( long "hide-missing"
+		<> help "hide annexed files whose content is not present"
+		)
+
+linkPresentAdjustmentParser :: Parser LinkPresentAdjustment
+linkPresentAdjustmentParser =
+	flag' UnlockPresentAdjustment
+		( long "unlock-present"
+		<> help "unlock files whose content is present; lock rest"
+		)
+
+seek :: Adjustment -> CommandSeek
+seek = commandAction . start
+
+start :: Adjustment -> CommandStart
+start adj = do
+	checkVersionSupported
+	starting "adjust" (ActionItemOther Nothing) (SeekInput []) $
+		next $ enterAdjustedBranch adj
diff --git a/Command/Assist.hs b/Command/Assist.hs
new file mode 100644
index 0000000000..bcdac9ae67
--- /dev/null
+++ b/Command/Assist.hs
@@ -0,0 +1,42 @@
+{- git-annex command
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Assist (cmd) where
+
+import Command
+import qualified Command.Sync
+import qualified Command.Add
+import Annex.CheckIgnore
+import qualified Annex.Queue
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, backendOption] $
+	command "assist" SectionCommon 
+		"add files and sync changes with remotes"
+		(paramRepeating paramRemote)
+		(myseek <--< Command.Sync.optParser Command.Sync.AssistMode)
+
+myseek :: Command.Sync.SyncOptions -> CommandSeek
+myseek o = do
+	-- Changes to top of repository, so when this is run in a
+	-- subdirectory, it will still default to adding files anywhere in
+	-- the working tree.
+	Command.Sync.prepMerge
+
+	Command.Add.seek Command.Add.AddOptions
+		{ Command.Add.addThese = Command.Sync.contentOfOption o
+		, Command.Add.batchOption = NoBatch
+		, Command.Add.updateOnly = False
+		, Command.Add.largeFilesOverride = Nothing
+		, Command.Add.checkGitIgnoreOption = CheckGitIgnore True
+		, Command.Add.dryRunOption = DryRun False
+		}
+	finishCommandActions
+	-- Flush added files to index so they will be committed.
+	Annex.Queue.flush
+
+	Command.Sync.seek' o
diff --git a/Command/Assistant.hs b/Command/Assistant.hs
new file mode 100644
index 0000000000..92db99664d
--- /dev/null
+++ b/Command/Assistant.hs
@@ -0,0 +1,140 @@
+{- git-annex assistant
+ -
+ - Copyright 2012-2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Assistant where
+
+import Command
+import qualified Command.Watch
+import Annex.Init
+import Annex.Path
+import Config.Files
+import Config.Files.AutoStart
+import qualified BuildInfo
+import Utility.HumanTime
+import Assistant.Install
+import Remote.List
+
+import Control.Concurrent.Async
+
+cmd :: Command
+cmd = dontCheck repoExists $ notBareRepo $
+	noRepo (startNoRepo <$$> optParser) $
+		command "assistant" SectionCommon
+			"daemon to add files and automatically sync changes"
+			paramNothing (seek <$$> optParser)
+
+data AssistantOptions = AssistantOptions
+	{ daemonOptions :: DaemonOptions
+	, autoStartOption :: Bool
+	, startDelayOption :: Maybe Duration
+	, autoStopOption :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser AssistantOptions
+optParser _ = AssistantOptions
+	<$> parseDaemonOptions True
+	<*> switch
+		( long "autostart"
+		<> help "start in known repositories"
+		)
+	<*> optional (option (eitherReader parseDuration)
+		( long "startdelay" <> metavar paramNumber
+		<> help "delay before running startup scan"
+		))
+	<*> switch
+		( long "autostop"
+		<> help "stop in known repositories"
+		)
+
+seek :: AssistantOptions -> CommandSeek
+seek = commandAction . start
+
+start :: AssistantOptions -> CommandStart
+start o
+	| autoStartOption o = do
+		liftIO $ autoStart o
+		stop
+	| autoStopOption o = do
+		liftIO autoStop
+		stop
+	| otherwise = do
+		liftIO ensureInstalled
+		ensureInitialized remoteList
+		Command.Watch.start True (daemonOptions o) (startDelayOption o)
+
+startNoRepo :: AssistantOptions -> IO ()
+startNoRepo o
+	| autoStartOption o = autoStart o
+	| autoStopOption o = autoStop
+	| otherwise = giveup "Not in a git repository."
+
+-- Does not return
+autoStart :: AssistantOptions -> IO ()
+autoStart o = do
+	dirs <- liftIO readAutoStartFile
+	when (null dirs) $ do
+		f <- autoStartFile
+		giveup $ "Nothing listed in " ++ f
+	program <- programPath
+	haveionice <- pure BuildInfo.ionice <&&> inSearchPath "ionice"
+	pids <- forM dirs $ \d -> do
+		putStrLn $ "git-annex autostart in " ++ d
+		mpid <- catchMaybeIO $ go haveionice program d
+		if foregroundDaemonOption (daemonOptions o)
+			then return mpid
+			else do
+				case mpid of
+					Nothing -> putStrLn "failed"
+					Just pid -> ifM (checkSuccessProcess pid)
+						( putStrLn "ok"
+						, putStrLn "failed"
+						)
+				return Nothing
+	-- Wait for any foreground jobs to finish and propagate exit status.
+	ifM (all (== True) <$> mapConcurrently checkSuccessProcess (catMaybes pids))
+		( exitSuccess
+		, exitFailure
+		)
+  where
+	go haveionice program dir = do
+		setCurrentDirectory dir
+		-- First stop any old daemon running in this directory, which
+		-- might be a leftover from an old login session. Such a
+		-- leftover might be left in an environment where it is
+		-- unable to use the ssh agent or other login session
+		-- resources.
+		void $ boolSystem program [Param "assistant", Param "--stop"]
+		(Nothing, Nothing, Nothing, pid) <- createProcess p
+		return pid
+	  where
+		p
+			| haveionice = proc "ionice"
+				(toCommand $ Param "-c3" : Param program : baseparams)
+			| otherwise = proc program
+				(toCommand baseparams)
+		baseparams = catMaybes
+			[ Just $ Param "assistant"
+			, Just $ Param $ "--startdelay=" ++ fromDuration (fromMaybe (Duration 5) (startDelayOption o))
+			, if foregroundDaemonOption (daemonOptions o)
+				then Just $ Param "--foreground"
+				else Nothing
+			]
+
+autoStop :: IO ()
+autoStop = do
+	dirs <- liftIO readAutoStartFile
+	program <- programPath
+	forM_ dirs $ \d -> do
+		putStrLn $ "git-annex autostop in " ++ d
+		tryIO (setCurrentDirectory d) >>= \case
+			Right () -> ifM (boolSystem program [Param "assistant", Param "--stop"])
+				( putStrLn "ok"
+				, putStrLn "failed"
+				)
+			Left e -> do
+				putStrLn (show e)
+				putStrLn "failed"
diff --git a/Command/Benchmark.hs b/Command/Benchmark.hs
new file mode 100644
index 0000000000..0395383ff4
--- /dev/null
+++ b/Command/Benchmark.hs
@@ -0,0 +1,58 @@
+{- git-annex benchmark
+ -
+ - Copyright 2016-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Command.Benchmark where
+
+import Command
+import Types.Benchmark
+#ifdef WITH_BENCHMARK
+import Database.Benchmark
+
+import Criterion.Main
+import Criterion.Main.Options (parseWith)
+#endif
+
+cmd :: BenchmarkGenerator -> Command
+cmd generator = command "benchmark" SectionTesting
+	"benchmark git-annex commands"
+	paramNothing
+	(seek generator <$$> optParser)
+
+data BenchmarkOptions 
+	= BenchmarkOptions CmdParams CriterionMode
+	| BenchmarkDatabases CriterionMode Integer
+
+optParser :: CmdParamsDesc -> Parser BenchmarkOptions
+optParser desc = benchmarkoptions <|> benchmarkdatabases
+  where
+	benchmarkoptions = BenchmarkOptions
+		<$> cmdParams desc
+		<*> criterionopts
+	benchmarkdatabases = BenchmarkDatabases
+		<$> criterionopts
+		<*> option auto
+	                ( long "databases" 
+			<> metavar paramNumber
+			<> help "benchmark sqlite databases"
+                	)
+#ifdef WITH_BENCHMARK
+	criterionopts = parseWith defaultConfig
+#else
+	criterionopts = pure ()
+#endif
+
+seek :: BenchmarkGenerator -> BenchmarkOptions -> CommandSeek
+#ifdef WITH_BENCHMARK
+seek generator (BenchmarkOptions ps mode) = do
+	runner <- generator ps
+	liftIO $ runMode mode [ bench (unwords ps) $ nfIO runner ]
+seek _ (BenchmarkDatabases mode n) = benchmarkDbs mode n
+#else
+seek _ _ = giveup "git-annex is not built with benchmarking support"
+#endif
diff --git a/Command/CalcKey.hs b/Command/CalcKey.hs
new file mode 100644
index 0000000000..44aa69b59d
--- /dev/null
+++ b/Command/CalcKey.hs
@@ -0,0 +1,35 @@
+{- git-annex command
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.CalcKey where
+
+import Command
+import Backend (genKey, defaultBackend)
+import Types.KeySource
+import Utility.Metered
+import Utility.Terminal
+import Utility.SafeOutput
+
+cmd :: Command
+cmd = noCommit $ noMessages $ dontCheck repoExists $
+	withAnnexOptions [backendOption] $
+		command "calckey" SectionPlumbing 
+			"calculate key for a file"
+			(paramRepeating paramFile)
+			(batchable run (pure ()))
+
+run :: () -> SeekInput -> String -> Annex Bool
+run _ _ file = tryNonAsync (genKey ks nullMeterUpdate =<< defaultBackend) >>= \case
+	Right (k, _) -> do
+		IsTerminal isterminal <- liftIO $ checkIsTerminal stdout
+		let sk = serializeKey k
+		liftIO $ putStrLn $ if isterminal then safeOutput sk else sk
+		return True
+	Left _err -> return False
+  where
+	ks = KeySource file' file' Nothing
+	file' = toRawFilePath file
diff --git a/Command/CheckPresentKey.hs b/Command/CheckPresentKey.hs
new file mode 100644
index 0000000000..efefc71aeb
--- /dev/null
+++ b/Command/CheckPresentKey.hs
@@ -0,0 +1,84 @@
+{- git-annex command
+ -
+ - Copyright 2015-2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.CheckPresentKey where
+
+import Command
+import qualified Remote
+import Remote.List
+import Utility.SafeOutput
+
+cmd :: Command
+cmd = noCommit $ noMessages $
+	command "checkpresentkey" SectionPlumbing
+		"check if key is present in remote"
+		(paramPair paramKey (paramOptional paramRemote))
+		(seek <$$> optParser)
+
+data CheckPresentKeyOptions = CheckPresentKeyOptions
+	{ params :: CmdParams
+	, batchOption :: BatchMode
+	}
+
+optParser :: CmdParamsDesc -> Parser CheckPresentKeyOptions
+optParser desc = CheckPresentKeyOptions
+	<$> cmdParams desc
+	<*> parseBatchOption False
+
+seek :: CheckPresentKeyOptions -> CommandSeek
+seek o = case batchOption o of
+	NoBatch -> case params o of
+		(ks:rn:[]) -> toRemote rn >>= (check ks . Just) >>= exitResult
+		(ks:[]) -> check ks Nothing >>= exitResult
+		_ -> wrongnumparams
+	Batch fmt -> do
+		checker <- case params o of
+			(rn:[]) -> toRemote rn >>= \r -> return (flip check (Just r))
+			[] -> return (flip check Nothing)
+			_ -> wrongnumparams
+		batchInput fmt (pure . Right) $
+			checker . snd >=> batchResult
+  where
+	wrongnumparams = giveup "Wrong number of parameters"
+					
+data Result = Present | NotPresent | CheckFailure String
+
+check :: String -> Maybe Remote -> Annex Result
+check ks mr = case mr of
+	Just r -> go Nothing [r]
+	Nothing -> do
+		mostlikely <- Remote.keyPossibilities (Remote.IncludeIgnored False) k
+		otherremotes <- flip Remote.remotesWithoutUUID 
+			(map Remote.uuid mostlikely)
+			<$> remoteList
+		go Nothing (mostlikely ++ otherremotes)
+  where
+	k = toKey ks
+	go Nothing [] = return NotPresent
+	go (Just e) [] = return $ CheckFailure e
+	go olderr (r:rs) = Remote.hasKey r k >>= \case
+		Right True -> return Present
+		Right False -> go olderr rs
+		Left e -> go (Just e) rs
+
+exitResult :: Result -> Annex a
+exitResult Present = liftIO exitSuccess
+exitResult NotPresent = liftIO exitFailure
+exitResult (CheckFailure msg) = liftIO $ do
+	hPutStrLn stderr (safeOutput msg)
+	exitWith $ ExitFailure 100
+
+batchResult :: Result -> Annex ()
+batchResult Present = liftIO $ putStrLn "1"
+batchResult _ = liftIO $ putStrLn "0"
+
+toKey :: String -> Key
+toKey = fromMaybe (giveup "Bad key") . deserializeKey
+
+toRemote :: String -> Annex Remote
+toRemote rn = maybe (giveup "Unknown remote") return
+	=<< Remote.byNameWithUUID (Just rn)
diff --git a/Command/Config.hs b/Command/Config.hs
new file mode 100644
index 0000000000..c61b443c3e
--- /dev/null
+++ b/Command/Config.hs
@@ -0,0 +1,216 @@
+{- git-annex command
+ -
+ - Copyright 2017-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Config where
+
+import Command
+import Logs.Config
+import Config
+import Types.GitConfig (globalConfigs)
+import Git.Types (fromConfigValue, fromConfigKey)
+import qualified Git.Command
+import Utility.SafeOutput
+import Annex.CheckAttr
+import Types.NumCopies
+import Logs.NumCopies
+
+import qualified Data.ByteString.Char8 as S8
+
+cmd :: Command
+cmd = noMessages $ command "config" SectionSetup
+	"configuration stored in git-annex branch"
+	paramNothing (seek <$$> optParser)
+
+data Action
+	= SetConfig ConfigKey ConfigValue
+	| GetConfig ConfigKey
+	| UnsetConfig ConfigKey
+	| ShowOrigin ConfigKey (Maybe FilePath)
+
+type Name = String
+type Value = String
+
+optParser :: CmdParamsDesc -> Parser Action
+optParser _ = setconfig <|> getconfig <|> unsetconfig <|> showorigin
+  where
+	setconfig = SetConfig
+		<$> strOption
+			( long "set"
+			<> help "set configuration"
+			<> metavar paramName
+			)
+		<*> strArgument
+			( metavar paramValue
+			)
+	getconfig = GetConfig <$> strOption
+		( long "get"
+		<> help "get configuration"
+		<> metavar paramName
+		)
+	unsetconfig = UnsetConfig <$> strOption
+		( long "unset"
+		<> help "unset configuration"
+		<> metavar paramName
+		)
+	showorigin = ShowOrigin
+		<$> strOption
+			( long "show-origin"
+			<> help "explain where a value is configured"
+			<> metavar paramName
+			)
+		<*> optional (strOption
+			( long "for-file"
+			<> help "filename to check for in gitattributes"
+			<> metavar paramFile
+			))
+
+seek :: Action -> CommandSeek
+seek (SetConfig ck@(ConfigKey name) val) = checkIsGlobalConfig ck $ \setter _unsetter _getter ->
+	commandAction $ startingUsualMessages (decodeBS name) ai si $ do
+		setter val
+		when (needLocalUpdate ck) $
+			setConfig ck (fromConfigValue val)
+		next $ return True
+  where
+	ai = ActionItemOther (Just (UnquotedString (fromConfigValue val)))
+	si = SeekInput [decodeBS name]
+seek (UnsetConfig ck@(ConfigKey name)) = checkIsGlobalConfig ck $ \_setter unsetter _getter ->
+	commandAction $ startingUsualMessages (decodeBS name) ai si $ do
+		unsetter
+		when (needLocalUpdate ck) $
+			unsetConfig ck
+		next $ return True
+  where
+	ai = ActionItemOther (Just "unset")
+	si = SeekInput [decodeBS name]
+seek (GetConfig ck) = checkIsGlobalConfig ck $ \_setter _unsetter getter ->
+	commandAction $	startingCustomOutput ai $ do
+		getter >>= \case
+			Just (ConfigValue v) -> liftIO $ S8.putStrLn $ safeOutput v
+			Just NoConfigValue -> return ()
+			Nothing -> return ()
+		next $ return True
+  where
+	ai = ActionItemOther Nothing
+seek (ShowOrigin ck@(ConfigKey name) forfile) = commandAction $
+	startingCustomOutput ai $ next $ checknotconfigured $
+		case checkIsGlobalConfig' ck of
+			Just (_setter, _unsetter, getter) ->
+				ifM gitconfigorigin
+					( return True
+					, checkattrs (checkconfigbranch getter)
+					)
+			Nothing -> ifM gitconfigorigin
+				( return True
+				, checkattrs checkgitconfigunderride
+				)
+  where
+	ai = ActionItemOther Nothing
+
+	gitconfigorigin
+		| name `elem` gitconfigdoesnotoverride = return False
+		| otherwise = gitconfigorigin'
+	gitconfigorigin' = inRepo $ Git.Command.runBool
+			[ Param "config"
+			, Param "--show-origin"
+			, Param (decodeBS name)
+			]
+	
+	-- git configs for these do not override values from git attributes
+	-- or the branch
+	gitconfigdoesnotoverride =
+		[ "annex.numcopies"
+		, "annex.mincopies"
+		]
+
+	-- the git config for annex.numcopies is a special case; it's only
+	-- used if not configured anywhere else
+	checkgitconfigunderride
+		| name == "annex.numcopies" = gitconfigorigin'
+		| otherwise = return False
+
+	-- Display similar to git config --show-origin
+	showval loc v = liftIO $ do
+		putStrLn $ loc ++ "\t" ++ v
+		return True
+	
+	configbranch v
+		| needLocalUpdate ck = checkgitconfigunderride
+		| otherwise = showval "branch:git-annex" (decodeBS v)
+	
+	checkconfigbranch getter = getter >>= \case
+		Just (ConfigValue v) -> configbranch v
+		_ -> checkgitconfigunderride
+	
+	checkattrs cont
+		| decodeBS name `elem` annexAttrs =
+			case forfile of
+				Just file -> do
+					v <- checkAttr (decodeBS name) (toRawFilePath file)
+					if null v
+						then cont
+						else showval "gitattributes" v		
+				Nothing -> do
+					warnforfile
+					cont
+		| otherwise = cont
+	
+	warnforfile = warning $ UnquotedString $ configKeyMessage ck $ unwords
+		[ "may be configured in gitattributes."
+		, "Pass --for-file= with a filename to check"
+		]
+	
+	checknotconfigured a = do
+		ok <- a
+		unless ok $
+			warning $ UnquotedString $ configKeyMessage ck
+				"is not configured"
+		return ok
+
+type Setter = ConfigValue -> Annex ()
+type Unsetter = Annex ()
+type Getter = Annex (Maybe ConfigValue)
+
+checkIsGlobalConfig :: ConfigKey -> (Setter -> Unsetter -> Getter -> Annex a) -> Annex a
+checkIsGlobalConfig ck a = case checkIsGlobalConfig' ck of
+	Just (setter, unsetter, getter) -> a setter unsetter getter
+	Nothing -> giveup $ configKeyMessage ck "is not a configuration setting that can be stored in the git-annex branch"
+
+checkIsGlobalConfig' :: ConfigKey -> Maybe (Setter, Unsetter, Getter)
+checkIsGlobalConfig' ck
+	| elem ck globalConfigs = Just
+		( setGlobalConfig ck
+		, unsetGlobalConfig ck
+		, getGlobalConfig ck
+		)
+	-- These came before this command, but are also global configs,
+	-- so support them here as well.
+	| ck == ConfigKey "annex.numcopies" = Just
+		( mksetter (setGlobalNumCopies . configuredNumCopies)
+		, error "unsetting annex.numcopies is not supported"
+		, mkgetter fromNumCopies getGlobalNumCopies
+		)
+	| ck == ConfigKey "annex.mincopies" = Just
+		( mksetter (setGlobalMinCopies . configuredMinCopies)
+		, error "unsetting annex.mincopies is not supported"
+		, mkgetter fromMinCopies getGlobalMinCopies
+		)
+	| otherwise = Nothing
+  where
+	mksetter f = 
+		maybe (error ("invalid value for " ++ fromConfigKey ck)) f 
+			. readish . decodeBS . fromConfigValue
+	mkgetter f g = fmap (ConfigValue . encodeBS . show . f) <$> g
+
+configKeyMessage :: ConfigKey -> String -> String
+configKeyMessage (ConfigKey name) msg = decodeBS name ++ " " ++ msg
+
+needLocalUpdate :: ConfigKey -> Bool
+needLocalUpdate (ConfigKey "annex.securehashesonly") = True
+needLocalUpdate _ = False
diff --git a/Command/ConfigList.hs b/Command/ConfigList.hs
new file mode 100644
index 0000000000..bb33f7102b
--- /dev/null
+++ b/Command/ConfigList.hs
@@ -0,0 +1,53 @@
+{- git-annex command
+ -
+ - Copyright 2010-2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.ConfigList where
+
+import Command
+import Annex.UUID
+import Annex.Init
+import qualified Annex.Branch
+import qualified Git.Config
+import Git.Types
+import Remote.GCrypt (coreGCryptId)
+import qualified CmdLine.GitAnnexShell.Fields as Fields
+import CmdLine.GitAnnexShell.Checks
+
+cmd :: Command
+cmd = noCommit $ dontCheck repoExists $
+	command "configlist" SectionPlumbing 
+		"outputs relevant git configuration"
+		paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = do
+	u <- findOrGenUUID
+	showConfig configkeyUUID $ fromUUID u
+	showConfig coreGCryptId . fromConfigValue
+		=<< fromRepo (Git.Config.get coreGCryptId mempty)
+	stop
+  where
+	showConfig k v = liftIO $ putStrLn $ fromConfigKey k ++ "=" ++ v
+
+{- The repository may not yet have a UUID; automatically initialize it
+ - when there's a git-annex branch available or if the autoinit field was
+ - set. -}
+findOrGenUUID :: Annex UUID
+findOrGenUUID = do
+	u <- getUUID
+	if u /= NoUUID
+		then return u
+		else ifM (Annex.Branch.hasSibling <||> (isJust <$> Fields.getField Fields.autoInit))
+			( do
+				liftIO checkNotReadOnly
+				initialize Nothing Nothing
+				getUUID
+			, return NoUUID
+			)
diff --git a/Command/ConfigRemote.hs b/Command/ConfigRemote.hs
new file mode 100644
index 0000000000..4bed32998f
--- /dev/null
+++ b/Command/ConfigRemote.hs
@@ -0,0 +1,64 @@
+{- git-annex command
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.ConfigRemote where
+
+import Command
+import qualified Logs.Remote
+import qualified Git.Types as Git
+import qualified Annex.SpecialRemote as SpecialRemote
+import qualified Types.Remote as Remote
+import Types.ProposedAccepted
+import Command.EnableRemote (unknownNameError, startSpecialRemote', PerformSpecialRemote, deadLast)
+
+import qualified Data.Map as M
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "configremote" SectionSetup
+		"changes special remote configuration"
+		(paramPair paramName $ paramOptional $ paramRepeating paramParamValue)
+		(withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start [] = unknownNameError "Specify the remote to configure."
+start (name:inputconfig) = deadLast name $
+	startSpecialRemote (checkSafeConfig inputconfig) name
+		(Logs.Remote.keyValToConfig Proposed inputconfig)
+
+{- Since this command stores config without calling the remote's setup
+ - method to validate it, it can only be used on fields that are known to
+ - be safe to change in all remotes. -}
+checkSafeConfig :: [String] -> Annex ()
+checkSafeConfig cs = do
+	let rc = Logs.Remote.keyValToConfig Proposed cs
+	forM_ (M.keys rc) $ \k ->
+		when (fromProposedAccepted k `notElem` safefields) $
+			giveup $ "Cannot change field \"" ++ fromProposedAccepted k  ++ "\" with this command. Use git-annex enableremote instead."
+	case SpecialRemote.parseRemoteConfig rc (Remote.RemoteConfigParser ps Nothing) of
+		Left err -> giveup err
+		Right _ -> return ()
+  where
+	ps = [ SpecialRemote.autoEnableFieldParser ]
+	safefields = [ fromProposedAccepted SpecialRemote.autoEnableField ]
+
+startSpecialRemote :: Annex () -> Git.RemoteName -> Remote.RemoteConfig -> [(UUID, Remote.RemoteConfig, Maybe (SpecialRemote.ConfigFrom UUID))] -> CommandStart
+startSpecialRemote = startSpecialRemote' "configremote" . performSpecialRemote
+
+performSpecialRemote :: Annex () -> PerformSpecialRemote
+performSpecialRemote precheck _ u _ c _ mcu = do
+	precheck
+	case mcu of
+		Nothing -> Logs.Remote.configSet u c
+		Just (SpecialRemote.ConfigFrom cu) ->
+			Logs.Remote.configSet cu c
+	next $ return True
diff --git a/Command/ContentLocation.hs b/Command/ContentLocation.hs
new file mode 100644
index 0000000000..ea2845899a
--- /dev/null
+++ b/Command/ContentLocation.hs
@@ -0,0 +1,32 @@
+{- git-annex command
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.ContentLocation where
+
+import Command
+import Annex.Content
+import qualified Utility.RawFilePath as R
+
+import qualified Data.ByteString.Char8 as B8
+
+cmd :: Command
+cmd = noCommit $ noMessages $
+	command "contentlocation" SectionPlumbing 
+		"looks up content for a key"
+		(paramRepeating paramKey)
+		(batchable run (pure ()))
+
+run :: () -> SeekInput -> String -> Annex Bool
+run _ _ p = do
+	let k = fromMaybe (giveup "bad key") $ deserializeKey p
+	maybe (return False) (\f -> liftIO (B8.putStrLn f) >> return True)
+		=<< inAnnex' (pure True) Nothing check k
+  where
+	check f = ifM (liftIO (R.doesPathExist f))
+		( return (Just f)
+		, return Nothing
+		)
diff --git a/Command/Copy.hs b/Command/Copy.hs
new file mode 100644
index 0000000000..8fe19e2ff9
--- /dev/null
+++ b/Command/Copy.hs
@@ -0,0 +1,97 @@
+{- git-annex command
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Copy where
+
+import Command
+import qualified Command.Move
+import qualified Remote
+import Annex.Wanted
+import Annex.NumCopies
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, jsonOptions, jsonProgressOption, annexedMatchingOptions] $
+	command "copy" SectionCommon
+		"copy content of files to/from another repository"
+		paramPaths (seek <--< optParser)
+
+data CopyOptions = CopyOptions
+	{ copyFiles :: CmdParams
+	, fromToOptions :: Maybe FromToHereOptions
+	, keyOptions :: Maybe KeyOptions
+	, autoMode :: Bool
+	, batchOption :: BatchMode
+	}
+
+optParser :: CmdParamsDesc -> Parser CopyOptions
+optParser desc = CopyOptions
+	<$> cmdParams desc
+	<*> parseFromToHereOptions
+	<*> optional (parseKeyOptions <|> parseFailedTransfersOption)
+	<*> parseAutoOption
+	<*> parseBatchOption True
+
+instance DeferredParseClass CopyOptions where
+	finishParse v = CopyOptions
+		<$> pure (copyFiles v)
+		<*> maybe (pure Nothing) (Just <$$> finishParse)
+			(fromToOptions v)
+		<*> pure (keyOptions v)
+		<*> pure (autoMode v)
+		<*> pure (batchOption v)
+
+seek :: CopyOptions -> CommandSeek
+seek o = case fromToOptions o of
+	Just fto -> seek' o fto
+	Nothing -> giveup "Specify --from or --to"
+
+seek' :: CopyOptions -> FromToHereOptions -> CommandSeek
+seek' o fto = startConcurrency (Command.Move.stages fto) $ do
+	case batchOption o of
+		NoBatch -> withKeyOptions
+			(keyOptions o) (autoMode o) seeker
+			(commandAction . keyaction)
+			(withFilesInGitAnnex ww seeker)
+			=<< workTreeItems ww (copyFiles o)
+		Batch fmt -> batchOnly (keyOptions o) (copyFiles o) $
+			batchAnnexed fmt seeker keyaction
+  where
+	ww = WarnUnmatchLsFiles "copy"
+	
+	seeker = AnnexedFileSeeker
+		{ startAction = const $ start o fto
+		, checkContentPresent = case fto of
+			FromOrToRemote (FromRemote _) -> Just False
+			FromOrToRemote (ToRemote _) -> Just True
+			ToHere -> Just False
+			FromRemoteToRemote _ _ -> Nothing
+			FromAnywhereToRemote _ -> Nothing
+		, usesLocationLog = True
+		}
+	keyaction = Command.Move.startKey fto Command.Move.RemoveNever
+
+{- A copy is just a move that does not delete the source file.
+ - However, auto mode avoids unnecessary copies, and avoids getting or
+ - sending non-preferred content. -}
+start :: CopyOptions -> FromToHereOptions -> SeekInput -> RawFilePath -> Key -> CommandStart
+start o fto si file key = stopUnless shouldCopy $ 
+	Command.Move.start fto Command.Move.RemoveNever si file key
+  where
+	shouldCopy
+		| autoMode o = want <||> numCopiesCheck file key (<)
+		| otherwise = return True
+	want = case fto of
+		FromOrToRemote (ToRemote dest) -> checkwantsend dest
+		FromOrToRemote (FromRemote _) -> checkwantget
+		ToHere -> checkwantget
+		FromRemoteToRemote _ dest -> checkwantsend dest
+		FromAnywhereToRemote dest -> checkwantsend dest
+
+	checkwantsend dest = 
+		(Remote.uuid <$> getParsed dest) >>=
+			wantGetBy False (Just key) (AssociatedFile (Just file))
+	checkwantget = wantGet False (Just key) (AssociatedFile (Just file))
diff --git a/Command/Dead.hs b/Command/Dead.hs
new file mode 100644
index 0000000000..cc6462fe3d
--- /dev/null
+++ b/Command/Dead.hs
@@ -0,0 +1,44 @@
+{- git-annex command
+ -
+ - Copyright 2011, 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Dead where
+
+import Command
+import Types.TrustLevel
+import Command.Trust (trustCommand)
+import Logs.Location
+import Remote (keyLocations)
+import Git.Types
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "dead" SectionSetup "hide a lost repository or key"
+		(paramRepeating paramRepository) (seek <$$> optParser)
+
+data DeadOptions = DeadRemotes [RemoteName] | DeadKeys [Key]
+
+optParser :: CmdParamsDesc -> Parser DeadOptions
+optParser desc = (DeadRemotes <$> cmdParams desc)
+	<|> (DeadKeys <$> many (option (str >>= parseKey)
+		( long "key" <> metavar paramKey
+		<> help "keys whose content has been irretrievably lost"
+		)))
+
+seek :: DeadOptions -> CommandSeek
+seek (DeadRemotes rs) = trustCommand "dead" DeadTrusted rs
+seek (DeadKeys ks) = commandActions $ map startKey ks
+
+startKey :: Key -> CommandStart
+startKey key = starting "dead" (mkActionItem key) (SeekInput []) $
+	keyLocations key >>= \case
+		[] -> performKey key
+		_ -> giveup "This key is still known to be present in some locations; not marking as dead."
+
+performKey :: Key -> CommandPerform
+performKey key = do
+	setDead key
+	next $ return True
diff --git a/Command/Describe.hs b/Command/Describe.hs
new file mode 100644
index 0000000000..ab76fedd7b
--- /dev/null
+++ b/Command/Describe.hs
@@ -0,0 +1,36 @@
+{- git-annex command
+ -
+ - Copyright 2011 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Describe where
+
+import Command
+import qualified Remote
+import Logs.UUID
+
+cmd :: Command
+cmd = command "describe" SectionSetup
+	"change description of a repository"
+	(paramPair paramRemote paramDesc)
+	(withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start (name:description) | not (null description) = do
+	u <- Remote.nameToUUID name
+	let ai = ActionItemUUID u (UnquotedString name)
+	starting "describe" ai si $
+		perform u $ unwords description
+  where
+	si = SeekInput [name]
+start _ = giveup "Specify a repository and a description."	
+
+perform :: UUID -> String -> CommandPerform
+perform u description = do
+	describeUUID u (toUUIDDesc description)
+	next $ return True
diff --git a/Command/DiffDriver.hs b/Command/DiffDriver.hs
new file mode 100644
index 0000000000..4c0e8b7fbc
--- /dev/null
+++ b/Command/DiffDriver.hs
@@ -0,0 +1,149 @@
+{- git-annex command
+ -
+ - Copyright 2014-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.DiffDriver where
+
+import Command
+import Annex.Content
+import Annex.Link
+import Git.Types
+import qualified Command.Get
+
+cmd :: Command
+cmd = command "diffdriver" SectionPlumbing 
+	"git diff driver"
+	("-- cmd --") (seek <$$> optParser)
+
+data Options = Options
+	{ textDiff :: Bool
+	, getOption :: Bool
+	, restOptions :: CmdParams
+	}
+
+optParser :: CmdParamsDesc -> Parser Options
+optParser desc = Options
+	<$> switch
+		( long "text"
+		<> help "diff text files with diff(1)"
+		)
+	<*> switch
+		( long "get"
+		<> help "get file contents from remotes"
+		)
+	<*> cmdParams desc
+
+seek :: Options -> CommandSeek
+seek opts = do
+	let (req, differ) = parseReq opts
+	void $ liftIO . exitBool =<< liftIO . differ =<< fixupReq req opts
+
+data Req 
+	= Req
+		{ rPath :: FilePath
+		, rOldFile :: FilePath
+		, rOldHex :: String
+		, rOldMode :: String
+		, rNewFile :: FilePath
+		, rNewHex :: String
+		, rNewMode ::String
+		}
+	| UnmergedReq
+		{ rPath :: FilePath
+		}
+
+type Differ = Req -> IO Bool
+
+serializeReq :: Req -> [CommandParam]
+serializeReq req@(UnmergedReq {}) = [Param $ rPath req]
+serializeReq req@(Req {}) = map Param
+	[ rPath req
+	, rOldFile req
+	, rOldHex req
+	, rOldMode req
+	, rNewFile req
+	, rNewHex req
+	, rNewMode req
+	]
+
+parseReq :: Options -> (Req, Differ)
+parseReq opts
+	| textDiff opts = case separate (== "--") (restOptions opts) of
+		(_,[]) -> (mk (restOptions opts), textDiffer [])
+		(ps,rest) -> (mk rest, textDiffer ps)
+	| otherwise = case separate (== "--") (restOptions opts) of
+		(c:ps, l) -> (mk l, externalDiffer c ps)
+		([],_) -> badopts
+  where
+	mk (path:old_file:old_hex:old_mode:new_file:new_hex:new_mode:[]) =
+		Req
+			{ rPath = path
+			, rOldFile = old_file
+			, rOldHex = old_hex
+			, rOldMode = old_mode
+			, rNewFile = new_file
+			, rNewHex = new_hex
+			, rNewMode = new_mode
+			}
+	mk (unmergedpath:[]) = UnmergedReq { rPath = unmergedpath }
+	mk _ = badopts
+
+	badopts = giveup $ "Unexpected input: " ++ unwords (restOptions opts)
+
+{- Check if either file is a symlink to a git-annex object,
+ - which git-diff will leave as a normal file containing the link text.
+ -
+ - Also check if either file is a pointer file, as used for unlocked files.
+ -
+ - In either case, adjust the Req to instead point to the actual
+ - location of the annexed object (which may or may not be present).
+ -
+ - This also gets objects from remotes when the getOption is set.
+ -}
+fixupReq :: Req -> Options -> Annex Req
+fixupReq req@(UnmergedReq {}) _ = return req
+fixupReq req@(Req {}) opts = 
+	check rOldFile rOldMode setoldfile req
+		>>= check rNewFile rNewMode setnewfile
+  where
+	setoldfile r@(Req {}) f = r { rOldFile = f }
+	setoldfile r@(UnmergedReq {}) _ = r
+	setnewfile r@(Req {}) f = r { rNewFile = f }
+	setnewfile r@(UnmergedReq {}) _ = r
+	check getfile getmode setfile r = case readTreeItemType (encodeBS (getmode r)) of
+		Just TreeSymlink -> do
+			v <- getAnnexLinkTarget' f False
+			maybe (return r) go (parseLinkTargetOrPointer =<< v)
+		_ -> maybe (return r) go =<< liftIO (isPointerFile f)
+	  where
+		f = toRawFilePath (getfile r)
+	  	go k = do
+			when (getOption opts) $
+				unlessM (inAnnex k) $
+					commandAction $
+						starting "get" ai si $
+							Command.Get.perform k af
+			repoint k
+		  where
+			ai = OnlyActionOn k (ActionItemKey k)
+			si = SeekInput []
+			af = AssociatedFile (Just f)
+		repoint k = withObjectLoc k $
+			pure . setfile r . fromRawFilePath
+
+externalDiffer :: String -> [String] -> Differ
+externalDiffer c ps = \req -> boolSystem c (map Param ps ++ serializeReq req )
+
+textDiffer :: [String] -> Differ
+textDiffer diffopts req = do
+	putStrLn ("diff a/" ++ rPath req ++ " b/" ++ rPath req)
+	-- diff exits nonzero on difference, so ignore exit status
+	void $ boolSystem "diff" $
+		[ Param "-u"
+		, Param (rOldFile req)
+		, Param (rNewFile req)
+		] ++ map Param diffopts
+	return True
diff --git a/Command/Direct.hs b/Command/Direct.hs
new file mode 100644
index 0000000000..ac295415a8
--- /dev/null
+++ b/Command/Direct.hs
@@ -0,0 +1,21 @@
+{- git-annex command
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Direct where
+
+import Command
+
+cmd :: Command
+cmd = notBareRepo $ noDaemonRunning $
+	command "direct" SectionSetup "switch repository to direct mode (deprecated)"
+		paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = giveup "Direct mode is not supported by this repository version. Use git-annex unlock instead."
diff --git a/Command/Drop.hs b/Command/Drop.hs
new file mode 100644
index 0000000000..2fcb5d6ebb
--- /dev/null
+++ b/Command/Drop.hs
@@ -0,0 +1,259 @@
+{- git-annex command
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Drop where
+
+import Command
+import qualified Remote
+import qualified Annex
+import Annex.UUID
+import Logs.Location
+import Logs.Trust
+import Logs.PreferredContent
+import Annex.NumCopies
+import Annex.Content
+import Annex.Wanted
+import Annex.Notification
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, jsonOptions, annexedMatchingOptions] $
+	command "drop" SectionCommon
+		"remove content of files from repository"
+		paramPaths (seek <$$> optParser)
+
+data DropOptions = DropOptions
+	{ dropFiles :: CmdParams
+	, dropFrom :: Maybe (DeferredParse Remote)
+	, autoMode :: Bool
+	, keyOptions :: Maybe KeyOptions
+	, batchOption :: BatchMode
+	}
+
+optParser :: CmdParamsDesc -> Parser DropOptions
+optParser desc = DropOptions
+	<$> cmdParams desc
+	<*> optional parseDropFromOption
+	<*> parseAutoOption
+	<*> optional parseKeyOptions
+	<*> parseBatchOption True
+
+parseDropFromOption :: Parser (DeferredParse Remote)
+parseDropFromOption = mkParseRemoteOption <$> strOption
+	( long "from" <> short 'f' <> metavar paramRemote
+	<> help "drop content from a remote"
+	<> completeRemotes
+	)
+
+seek :: DropOptions -> CommandSeek
+seek o = startConcurrency commandStages $ do
+	from <- case dropFrom o of
+		Nothing -> pure Nothing
+		Just f -> getParsed f >>= \remote -> do
+			u <- getUUID
+			if Remote.uuid remote == u
+				then pure Nothing
+				else pure (Just remote)				
+	let seeker = AnnexedFileSeeker
+		{ startAction = const $ start o from
+		, checkContentPresent = case from of
+			Nothing -> Just True
+			Just _ -> Nothing
+		, usesLocationLog = True
+		}
+	case batchOption o of
+		NoBatch -> withKeyOptions (keyOptions o) (autoMode o) seeker
+			(commandAction . startKeys o from)
+			(withFilesInGitAnnex ww seeker)
+			=<< workTreeItems ww (dropFiles o)
+		Batch fmt -> batchOnly (keyOptions o) (dropFiles o) $
+			batchAnnexed fmt seeker (startKeys o from)
+  where
+	ww = WarnUnmatchLsFiles "drop"
+
+start :: DropOptions -> Maybe Remote -> SeekInput -> RawFilePath -> Key -> CommandStart
+start o from si file key = start' o from key afile ai si
+  where
+	afile = AssociatedFile (Just file)
+	ai = mkActionItem (key, afile)
+
+start' :: DropOptions -> Maybe Remote -> Key -> AssociatedFile -> ActionItem -> SeekInput -> CommandStart
+start' o from key afile ai si = 
+	checkDropAuto (autoMode o) from afile key $ \numcopies mincopies ->
+		stopUnless wantdrop $
+			case from of
+				Nothing -> startLocal pcc afile ai si numcopies mincopies key [] ud
+				Just remote -> startRemote pcc afile ai si numcopies mincopies key ud remote
+  where
+	wantdrop
+		| autoMode o = wantDrop False (Remote.uuid <$> from) (Just key) afile Nothing
+		| otherwise = return True
+	pcc = PreferredContentChecked (autoMode o)
+	ud = case (batchOption o, keyOptions o) of
+		(NoBatch, Just WantUnusedKeys) -> DroppingUnused True
+		_ -> DroppingUnused False
+
+startKeys :: DropOptions -> Maybe Remote -> (SeekInput, Key, ActionItem) -> CommandStart
+startKeys o from (si, key, ai) = start' o from key (AssociatedFile Nothing) ai si
+
+startLocal :: PreferredContentChecked -> AssociatedFile -> ActionItem -> SeekInput -> NumCopies -> MinCopies -> Key -> [VerifiedCopy] -> DroppingUnused -> CommandStart
+startLocal pcc afile ai si numcopies mincopies key preverified ud =
+	starting "drop" (OnlyActionOn key ai) si $
+		performLocal pcc key afile numcopies mincopies preverified ud
+
+startRemote :: PreferredContentChecked -> AssociatedFile -> ActionItem -> SeekInput -> NumCopies -> MinCopies -> Key -> DroppingUnused -> Remote -> CommandStart
+startRemote pcc afile ai si numcopies mincopies key ud remote = 
+	starting "drop" (OnlyActionOn key ai) si $ do
+		showAction $ UnquotedString $ "from " ++ Remote.name remote
+		performRemote pcc key afile numcopies mincopies remote ud
+
+performLocal :: PreferredContentChecked -> Key -> AssociatedFile -> NumCopies -> MinCopies -> [VerifiedCopy] -> DroppingUnused -> CommandPerform
+performLocal pcc key afile numcopies mincopies preverified ud = lockContentForRemoval key fallback $ \contentlock -> do
+	u <- getUUID
+	(tocheck, verified) <- verifiableCopies key [u]
+	doDrop pcc u (Just contentlock) key afile numcopies mincopies [] (preverified ++ verified) tocheck
+		( \proof -> do
+			fastDebug "Command.Drop" $ unwords
+				[ "Dropping from here"
+				, "proof:"
+				, show proof
+				]
+			removeAnnex contentlock
+			notifyDrop afile True
+			next $ cleanupLocal key ud
+		, do 
+			notifyDrop afile False
+			stop
+		)
+  where
+	-- This occurs when, for example, two files are being dropped
+	-- and have the same content. The seek stage checks if the content
+	-- is present, but due to buffering, may find it present for the
+	-- second file before the first is dropped. If so, nothing remains
+	-- to be done except for cleaning up.
+	fallback = next $ cleanupLocal key ud
+
+performRemote :: PreferredContentChecked -> Key -> AssociatedFile -> NumCopies -> MinCopies -> Remote -> DroppingUnused -> CommandPerform
+performRemote pcc key afile numcopies mincopies remote ud = do
+	-- Filter the uuid it's being dropped from out of the lists of
+	-- places assumed to have the key, and places to check.
+	(tocheck, verified) <- verifiableCopies key [uuid]
+	doDrop pcc uuid Nothing key afile numcopies mincopies [uuid] verified tocheck
+		( \proof -> do 
+			fastDebug "Command.Drop" $ unwords
+				[ "Dropping from remote"
+				, show remote
+				, "proof:"
+				, show proof
+				]
+			ok <- Remote.action (Remote.removeKey remote key)
+			next $ cleanupRemote key remote ud ok
+		, stop
+		)
+  where
+	uuid = Remote.uuid remote
+
+cleanupLocal :: Key -> DroppingUnused -> CommandCleanup
+cleanupLocal key ud = do
+	logStatus key (dropStatus ud)
+	return True
+
+cleanupRemote :: Key -> Remote -> DroppingUnused -> Bool -> CommandCleanup
+cleanupRemote key remote ud ok = do
+	when ok $
+		Remote.logStatus remote key (dropStatus ud)
+	return ok
+
+{- Set when the user explicitly chose to operate on unused content.
+ - Presumably the user still expects the last git-annex unused to be
+ - correct at this point. -}
+newtype DroppingUnused = DroppingUnused Bool
+
+{- When explicitly dropping unused content, mark the key as dead, at least
+ - in the repository it was dropped from. It may still be in other
+ - repositories, and will not be treated as dead until dropped from all of
+ - them. -}
+dropStatus :: DroppingUnused -> LogStatus
+dropStatus (DroppingUnused False) = InfoMissing
+dropStatus (DroppingUnused True) = InfoDead
+
+{- Before running the dropaction, checks specified remotes to
+ - verify that enough copies of a key exist to allow it to be
+ - safely removed (with no data loss).
+ -
+ - --force overrides and always allows dropping.
+ -}
+doDrop
+	:: PreferredContentChecked
+	-> UUID
+	-> Maybe ContentRemovalLock
+	-> Key
+	-> AssociatedFile
+	-> NumCopies
+	-> MinCopies
+	-> [UUID]
+	-> [VerifiedCopy]
+	-> [UnVerifiedCopy]
+	-> (Maybe SafeDropProof -> CommandPerform, CommandPerform)
+	-> CommandPerform
+doDrop pcc dropfrom contentlock key afile numcopies mincopies skip preverified check (dropaction, nodropaction) = 
+	ifM (Annex.getRead Annex.force)
+		( dropaction Nothing
+		, ifM (checkRequiredContent pcc dropfrom key afile)
+			( verifyEnoughCopiesToDrop nolocmsg key 
+				contentlock numcopies mincopies
+				skip preverified check
+					(dropaction . Just)
+					(forcehint nodropaction)
+			, stop
+			)
+		)
+  where
+	nolocmsg = "Rather than dropping this file, try using: git annex move"
+	forcehint a = do
+		showLongNote "(Use --force to override this check, or adjust numcopies.)"
+		a
+
+{- Checking preferred content also checks required content, so when
+ - auto mode causes preferred content to be checked, it's redundant
+ - for checkRequiredContent to separately check required content, and
+ - providing this avoids that extra work. -}
+newtype PreferredContentChecked = PreferredContentChecked Bool
+
+checkRequiredContent :: PreferredContentChecked -> UUID -> Key -> AssociatedFile -> Annex Bool
+checkRequiredContent (PreferredContentChecked True) _ _ _ = return True
+checkRequiredContent (PreferredContentChecked False) u k afile =
+	checkDrop isRequiredContent False (Just u) (Just k) afile Nothing >>= \case
+		Nothing -> return True
+		Just afile' -> do
+			if afile == afile'
+				then showLongNote "That file is required content. It cannot be dropped!"
+				else showLongNote $ "That file has the same content as another file"
+					<> case afile' of
+						AssociatedFile (Just f) -> " (" <> QuotedPath f <> "),"
+						AssociatedFile Nothing -> ""
+					<> " which is required content. It cannot be dropped!"
+			showLongNote "(Use --force to override this check, or adjust required content configuration.)"
+			return False
+
+{- In auto mode, only runs the action if there are enough
+ - copies on other semitrusted repositories. -}
+checkDropAuto :: Bool -> Maybe Remote -> AssociatedFile -> Key -> (NumCopies -> MinCopies -> CommandStart) -> CommandStart
+checkDropAuto automode mremote afile key a =
+	go =<< getSafestNumMinCopies afile key
+  where
+	go (numcopies, mincopies)
+		| automode = do
+			locs <- Remote.keyLocations key
+			uuid <- getUUID
+			let remoteuuid = fromMaybe uuid $ Remote.uuid <$> mremote
+			locs' <- trustExclude UnTrusted $ filter (/= remoteuuid) locs
+			if length locs' >= fromNumCopies numcopies
+				then a numcopies mincopies
+				else stop
+		| otherwise = a numcopies mincopies
diff --git a/Command/DropKey.hs b/Command/DropKey.hs
new file mode 100644
index 0000000000..43de89a970
--- /dev/null
+++ b/Command/DropKey.hs
@@ -0,0 +1,59 @@
+{- git-annex command
+ -
+ - Copyright 2010,2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.DropKey where
+
+import Command
+import qualified Annex
+import Logs.Location
+import Annex.Content
+
+cmd :: Command
+cmd = noCommit $ withAnnexOptions [jsonOptions] $
+	command "dropkey" SectionPlumbing
+		"drops annexed content for specified keys"
+		(paramRepeating paramKey)
+		(seek <$$> optParser)
+
+data DropKeyOptions = DropKeyOptions
+	{ toDrop :: [String]
+	, batchOption :: BatchMode
+	}
+
+optParser :: CmdParamsDesc -> Parser DropKeyOptions
+optParser desc = DropKeyOptions
+	<$> cmdParams desc
+	<*> parseBatchOption False
+
+seek :: DropKeyOptions -> CommandSeek
+seek o = do
+	unlessM (Annex.getRead Annex.force) $
+		giveup "dropkey can cause data loss; use --force if you're sure you want to do this"
+	case batchOption o of
+		NoBatch -> withKeys (commandAction . start) (toDrop o)
+		Batch fmt -> batchOnly Nothing (toDrop o) $
+			batchInput fmt (pure . parsekey) $
+				batchCommandAction . start
+  where
+	parsekey = maybe (Left "bad key") Right . deserializeKey
+
+start :: (SeekInput, Key) -> CommandStart
+start (si, key) = starting "dropkey" (mkActionItem key) si $
+	perform key
+
+perform :: Key -> CommandPerform
+perform key = ifM (inAnnex key)
+	( lockContentForRemoval key (next $ cleanup key) $ \contentlock -> do
+		removeAnnex contentlock
+		next $ cleanup key
+	, next $ return True
+	)
+
+cleanup :: Key -> CommandCleanup
+cleanup key = do
+	logStatus key InfoMissing
+	return True
diff --git a/Command/DropUnused.hs b/Command/DropUnused.hs
new file mode 100644
index 0000000000..2a268f760c
--- /dev/null
+++ b/Command/DropUnused.hs
@@ -0,0 +1,82 @@
+{- git-annex command
+ -
+ - Copyright 2010,2012,2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.DropUnused where
+
+import Command
+import qualified Annex
+import qualified Command.Drop
+import qualified Remote
+import qualified Git
+import Command.Unused (withUnusedMaps, UnusedMaps(..), startUnused)
+import Annex.NumCopies
+import Annex.Content
+import qualified Utility.RawFilePath as R
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, jsonOptions] $
+	command "dropunused" SectionMaintenance
+		"drop unused file content"
+		(paramRepeating paramNumRange) (seek <$$> optParser)
+
+data DropUnusedOptions = DropUnusedOptions
+	{ rangesToDrop :: CmdParams
+	, dropFrom :: Maybe (DeferredParse Remote)
+	}
+
+optParser :: CmdParamsDesc -> Parser DropUnusedOptions
+optParser desc = DropUnusedOptions
+	<$> cmdParams desc
+	<*> optional (Command.Drop.parseDropFromOption)
+
+seek :: DropUnusedOptions -> CommandSeek
+seek o = startConcurrency commandStages $ do
+	numcopies <- getNumCopies
+	mincopies <- getMinCopies
+	from <- maybe (pure Nothing) (Just <$$> getParsed) (dropFrom o)
+	withUnusedMaps (start from numcopies mincopies) (rangesToDrop o)
+
+start :: Maybe Remote -> NumCopies -> MinCopies -> UnusedMaps -> Int -> CommandStart
+start from numcopies mincopies = startUnused
+	(go (perform from numcopies mincopies))
+	(go (performOther gitAnnexBadLocation))
+	(go (performOther gitAnnexTmpObjectLocation))
+  where
+	go a n key = starting "dropunused" 
+		(ActionItemOther $ Just $ UnquotedString $ show n)
+		(SeekInput [show n])
+		(a key)
+
+perform :: Maybe Remote -> NumCopies -> MinCopies -> Key -> CommandPerform
+perform from numcopies mincopies key = case from of
+	Just r -> do
+		showAction $ UnquotedString $ "from " ++ Remote.name r
+		Command.Drop.performRemote pcc key (AssociatedFile Nothing) numcopies mincopies r ud
+	Nothing -> ifM (inAnnex key)
+		( droplocal
+		, ifM (objectFileExists key)
+			( ifM (Annex.getRead Annex.force)
+				( droplocal
+				, do
+					warning "Annexed object has been modified and dropping it would probably lose the only copy. Run this command with --force if you want to drop it anyway."
+					next $ return False
+				)
+			, next $ return True
+			)
+		)
+  where
+	droplocal = Command.Drop.performLocal pcc key (AssociatedFile Nothing) numcopies mincopies [] ud
+	pcc = Command.Drop.PreferredContentChecked False
+	ud = Command.Drop.DroppingUnused True
+
+performOther :: (Key -> Git.Repo -> RawFilePath) -> Key -> CommandPerform
+performOther filespec key = do
+	f <- fromRepo $ filespec key
+	pruneTmpWorkDirBefore f (liftIO . removeWhenExistsWith R.removeLink)
+	next $ return True
diff --git a/Command/EnableRemote.hs b/Command/EnableRemote.hs
new file mode 100644
index 0000000000..4d04610cdd
--- /dev/null
+++ b/Command/EnableRemote.hs
@@ -0,0 +1,159 @@
+{- git-annex command
+ -
+ - Copyright 2013-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.EnableRemote where
+
+import Command
+import qualified Annex
+import qualified Logs.Remote
+import qualified Types.Remote as R
+import qualified Git
+import qualified Git.Types as Git
+import qualified Annex.SpecialRemote as SpecialRemote
+import qualified Remote
+import qualified Types.Remote as Remote
+import qualified Remote.Git
+import Logs.UUID
+import Annex.UUID
+import Config
+import Config.DynamicConfig
+import Types.GitConfig
+import Types.ProposedAccepted
+import Git.Config
+
+import qualified Data.Map as M
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "enableremote" SectionSetup
+		"enables git-annex to use a remote"
+		(paramPair paramName $ paramOptional $ paramRepeating paramParamValue)
+		(withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start [] = unknownNameError "Specify the remote to enable."
+start (name:rest) = go =<< filter matchingname <$> Annex.getGitRemotes
+  where
+	matchingname r = Git.remoteName r == Just name
+	go [] = deadLast name $ 
+		startSpecialRemote name (Logs.Remote.keyValToConfig Proposed rest)
+	go (r:_)
+		| not (null rest) = go []
+		| otherwise = do
+			-- This could be either a normal git remote or a special
+			-- remote that has an url (eg gcrypt).
+			rs <- Remote.remoteList
+			case filter (\rmt -> Remote.name rmt == name) rs of
+				(rmt:_) | Remote.remotetype rmt == Remote.Git.remote ->
+					startNormalRemote name r
+				_  -> go []
+
+-- enableremote of a normal git remote with no added parameters is a special case
+-- that retries probing the remote uuid.
+startNormalRemote :: Git.RemoteName -> Git.Repo -> CommandStart
+startNormalRemote name r = starting "enableremote (normal)" ai si $ do
+	setRemoteIgnore r False
+	r' <- Remote.Git.configRead False r
+	u <- getRepoUUID r'
+	next $ return $ u /= NoUUID
+  where
+	ai = ActionItemOther (Just (UnquotedString name))
+	si = SeekInput [name]
+
+startSpecialRemote :: Git.RemoteName -> Remote.RemoteConfig -> [(UUID, Remote.RemoteConfig, Maybe (SpecialRemote.ConfigFrom UUID))] -> CommandStart
+startSpecialRemote = startSpecialRemote' "enableremote" performSpecialRemote
+
+type PerformSpecialRemote = RemoteType -> UUID -> R.RemoteConfig -> R.RemoteConfig -> RemoteGitConfig -> Maybe (SpecialRemote.ConfigFrom UUID) -> CommandPerform
+
+startSpecialRemote' :: String -> PerformSpecialRemote -> Git.RemoteName -> Remote.RemoteConfig -> [(UUID, Remote.RemoteConfig, Maybe (SpecialRemote.ConfigFrom UUID))] -> CommandStart
+startSpecialRemote' cname perform name config [] = do
+	m <- SpecialRemote.specialRemoteMap
+	confm <- Logs.Remote.remoteConfigMap
+	Remote.nameToUUID' name >>= \case
+		([u], _) | u `M.member` m ->
+			startSpecialRemote' cname perform name config $
+				[(u, fromMaybe M.empty (M.lookup u confm), Nothing)]
+		(_, msg) -> unknownNameError msg
+startSpecialRemote' cname perform name config ((u, c, mcu):[]) =
+	starting cname ai si $ do
+		let fullconfig = config `M.union` c	
+		t <- either giveup return (SpecialRemote.findType fullconfig)
+		gc <- maybe (liftIO dummyRemoteGitConfig) 
+			(return . Remote.gitconfig)
+			=<< Remote.byUUID u
+		perform t u c fullconfig gc mcu
+  where
+	ai = ActionItemOther (Just (UnquotedString name))
+	si = SeekInput [name]
+startSpecialRemote' _ _ _ _ _ =
+	giveup "Multiple remotes have that name. Either use git-annex renameremote to rename them, or specify the uuid of the remote."
+
+performSpecialRemote :: PerformSpecialRemote
+performSpecialRemote t u oldc c gc mcu = do
+	-- Avoid enabling a special remote if there is another remote
+	-- with the same name.
+	case SpecialRemote.lookupName c of
+		Nothing -> noop
+		Just name -> do
+			rs <- Remote.remoteList
+			case filter (\rmt -> Remote.name rmt == name) rs of
+				(rmt:_) | Remote.uuid rmt /= u ->
+					giveup $ "Not overwriting currently configured git remote named \"" ++ name ++ "\""
+				_ -> noop
+	(c', u') <- R.setup t (R.Enable oldc) (Just u) Nothing c gc
+	next $ cleanupSpecialRemote t u' c' mcu
+
+cleanupSpecialRemote :: RemoteType -> UUID -> R.RemoteConfig -> Maybe (SpecialRemote.ConfigFrom UUID) -> CommandCleanup
+cleanupSpecialRemote t u c mcu = do
+	case mcu of
+		Nothing -> Logs.Remote.configSet u c
+		Just (SpecialRemote.ConfigFrom cu) -> do
+			setConfig (remoteAnnexConfig c "config-uuid") (fromUUID cu)
+			Logs.Remote.configSet cu c
+	Remote.byUUID u >>= \case
+		Nothing -> noop
+		Just r -> do
+			repo <- R.getRepo r
+			setRemoteIgnore repo False
+	unless (Remote.gitSyncableRemoteType t) $
+		setConfig (remoteConfig c "skipFetchAll") (boolConfig True)
+	return True
+
+unknownNameError :: String -> Annex a
+unknownNameError prefix = do
+	m <- SpecialRemote.specialRemoteMap
+	descm <- M.unionWith Remote.addName
+		<$> uuidDescMap
+		<*> pure (M.map toUUIDDesc m)
+	specialmsg <- if M.null m
+			then pure "(No special remotes are currently known; perhaps use initremote instead?)"
+			else Remote.prettyPrintUUIDsDescs
+				"known special remotes"
+				descm (M.keys m)
+	disabledremotes <- filterM isdisabled =<< Annex.getGitRemotes
+	let remotesmsg = unlines $ map ("\t" ++) $
+		mapMaybe Git.remoteName disabledremotes
+	giveup $ concat $ filter (not . null) [prefix ++ "\n", remotesmsg, specialmsg]
+  where
+	isdisabled r = anyM id
+		[ (==) NoUUID <$> getRepoUUID r
+		, liftIO . getDynamicConfig . remoteAnnexIgnore
+			=<< Annex.getRemoteGitConfig r
+		]
+
+-- Use dead remote only when there is no other remote
+-- with the same name
+deadLast :: Git.RemoteName -> ([(UUID, Remote.RemoteConfig, Maybe (SpecialRemote.ConfigFrom UUID))] -> Annex a) -> Annex a
+deadLast name use =
+	SpecialRemote.findExisting' name >>= \case
+		([], l) -> use l
+		(l, _) -> use l
diff --git a/Command/EnableTor.hs b/Command/EnableTor.hs
new file mode 100644
index 0000000000..8e837a27c6
--- /dev/null
+++ b/Command/EnableTor.hs
@@ -0,0 +1,152 @@
+{- git-annex command
+ -
+ - Copyright 2016-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, CPP #-}
+
+module Command.EnableTor where
+
+import Command
+import qualified Annex
+import P2P.Address
+import P2P.Annex
+import Utility.Tor
+import Annex.UUID
+#ifndef mingw32_HOST_OS
+import Annex.Path
+#endif
+import P2P.IO
+import qualified P2P.Protocol as P2P
+import Utility.ThreadScheduler
+import RemoteDaemon.Transport.Tor
+import Git.Types
+import Config
+
+import Control.Concurrent.Async
+import qualified Network.Socket as S
+#ifndef mingw32_HOST_OS
+import Utility.Su
+import System.Posix.User
+#endif
+
+cmd :: Command
+cmd = noCommit $ dontCheck repoExists $
+	command "enable-tor" SectionSetup "enable tor hidden service"
+		"uid" (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+-- This runs as root, so avoid making any commits or initializing
+-- git-annex, or doing other things that create root-owned files.
+start :: [String] -> CommandStart
+#ifndef mingw32_HOST_OS
+start os = do
+#else
+start _os = do
+#endif
+#ifndef mingw32_HOST_OS
+	let ai = ActionItemOther Nothing
+	let si = SeekInput []
+	curruserid <- liftIO getEffectiveUserID
+	if curruserid == 0
+		then case readish =<< headMaybe os of
+			Nothing -> giveup "Need user-id parameter."
+			Just userid -> go userid
+		else starting "enable-tor" ai si $ do
+			gitannex <- liftIO programPath
+			let ps = [Param (cmdname cmd), Param (show curruserid)]
+			sucommand <- liftIO $ mkSuCommand gitannex ps
+			cleanenv <- liftIO $ cleanStandaloneEnvironment
+			maybe noop (showLongNote . UnquotedString)
+				(describePasswordPrompt' sucommand)
+			ifM (liftIO $ runSuCommand sucommand cleanenv)
+				( next checkHiddenService
+				, giveup $ unwords $
+					[ "Failed to run as root:" , gitannex ] ++ toCommand ps
+				)
+#else
+	go 0
+#endif
+  where
+	go userid = do
+		-- Usually git will refuse to read local configs of a git
+		-- repo belonging to another user. But in this case, the
+		-- user wants this command, run as root, to operate on
+		-- their repo. Behave as if --git-dir had been used to
+		-- specify that the git directory is intended to be used.
+		Annex.adjustGitRepo $ \r -> return $ r
+			{ gitDirSpecifiedExplicitly = True }
+		reloadConfig
+
+		uuid <- getUUID
+		when (uuid == NoUUID) $
+			giveup "This can only be run in a git-annex repository."
+		(onionaddr, onionport) <- liftIO $
+			addHiddenService torAppName userid (fromUUID uuid)
+		storeP2PAddress $ TorAnnex onionaddr onionport
+		stop
+
+checkHiddenService :: CommandCleanup
+checkHiddenService = bracket setup cleanup go
+  where
+	setup = do
+		showLongNote "Tor hidden service is configured. Checking connection to it. This may take a few minutes."
+		startlistener
+	
+	cleanup = liftIO . cancel
+	
+	go _ = check (150 :: Int) =<< filter istoraddr <$> loadP2PAddresses
+	
+	istoraddr (TorAnnex _ _) = True
+
+	check 0 _ = giveup "Still unable to connect to hidden service. It might not yet be usable by others. Please check Tor's logs for details."
+	check _ [] = giveup "Somehow didn't get an onion address."
+	check n addrs@(addr:_) = do
+		g <- Annex.gitRepo
+		-- Connect but don't bother trying to auth,
+		-- we just want to know if the tor circuit works.
+		liftIO (tryNonAsync $ connectPeer g addr) >>= \case
+			Left e -> do
+				warning $ UnquotedString $ "Unable to connect to hidden service. It may not yet have propigated to the Tor network. (" ++ show e ++ ") Will retry.."
+				liftIO $ threadDelaySeconds (Seconds 2)
+				check (n-1) addrs
+			Right conn -> do
+				liftIO $ closeConnection conn
+				showLongNote "Tor hidden service is working."
+				return True
+	
+	-- Unless the remotedaemon is already listening on the hidden
+	-- service's socket, start a listener. This is only run during the
+	-- check, and it refuses all auth attempts.
+	startlistener = do
+		r <- Annex.gitRepo
+		u <- getUUID
+		msock <- torSocketFile
+		case msock of
+			Just sockfile -> ifM (liftIO $ haslistener sockfile)
+				( liftIO $ async $ return ()
+				, liftIO $ async $ runlistener sockfile u r
+				)
+			Nothing -> giveup "Could not find socket file in Tor configuration!"
+	
+	runlistener sockfile u r = serveUnixSocket sockfile $ \h -> do
+		let conn = P2PConnection
+			{ connRepo = r
+			, connCheckAuth = const False
+			, connIhdl = h
+			, connOhdl = h
+			, connIdent = ConnIdent Nothing
+			}
+		runst <- mkRunState Client
+		void $ runNetProto runst conn $ P2P.serveAuth u
+		hClose h
+
+	haslistener sockfile = catchBoolIO $ do
+		soc <- S.socket S.AF_UNIX S.Stream S.defaultProtocol
+		S.connect soc (S.SockAddrUnix sockfile)
+		S.close soc
+		return True
diff --git a/Command/ExamineKey.hs b/Command/ExamineKey.hs
new file mode 100644
index 0000000000..439472a47e
--- /dev/null
+++ b/Command/ExamineKey.hs
@@ -0,0 +1,83 @@
+{- git-annex command
+ -
+ - Copyright 2013-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.ExamineKey where
+
+import Command
+import qualified Utility.Format
+import Command.Find (parseFormatOption, showFormatted, formatVars)
+import Annex.Link
+import Backend
+import Types.Backend
+import Types.Key
+import Utility.Terminal
+
+import Data.Char
+import qualified Data.ByteString as B
+
+cmd :: Command
+cmd = noCommit $ noMessages $ dontCheck repoExists $ 
+	withAnnexOptions [jsonOptions] $
+		command "examinekey" SectionPlumbing 
+			"prints information from a key"
+			(paramRepeating paramKey)
+			(batchable run optParser)
+
+data ExamineOptions = ExamineOptions
+	{ format :: Maybe Utility.Format.Format
+	, migrateToBackend :: Maybe (DeferredParse Backend)
+	, associatedFile :: AssociatedFile
+	}
+
+optParser :: Parser ExamineOptions
+optParser = ExamineOptions
+	<$> optional parseFormatOption
+	<*> (fmap (DeferredParse . tobackend) <$> migrateopt)
+	<*> (AssociatedFile <$> fileopt)
+  where
+	fileopt = optional $ strOption
+		( long "filename" <> metavar paramFile
+		<> help "file associated with the key"
+		)
+	migrateopt = optional $ strOption
+		( long "migrate-to-backend" <> metavar paramName
+		<> help "migrate key to other backend when possible"
+		)
+	tobackend = lookupBackendVariety . parseKeyVariety . encodeBS
+
+run :: ExamineOptions -> SeekInput -> String -> Annex Bool
+run o _ input = do
+	k <- getkey
+	
+	objectpath <- calcRepo $ gitAnnexLocation k
+	let objectpointer = formatPointer k
+	isterminal <- liftIO $ checkIsTerminal stdout
+	showFormatted isterminal (format o) (serializeKey' k) $
+		[ ("objectpath", fromRawFilePath objectpath)
+		, ("objectpointer", fromRawFilePath objectpointer)
+		] ++ formatVars k af
+	return True
+  where
+	-- Parse the input, which is either a key, or in batch mode 
+	-- can be "key filename"
+	(ikb, ifb) = B.break (== (fromIntegral (ord ' '))) (toRawFilePath input)
+	ifb' = B.drop 1 ifb
+	ik = fromMaybe (giveup "bad key") (deserializeKey' ikb)
+	af = if B.null ifb'
+		then associatedFile o
+		else AssociatedFile (Just ifb')
+
+	getkey = case migrateToBackend o of
+		Nothing -> pure ik
+		Just v -> getParsed v >>= \b ->
+			maybeLookupBackendVariety (fromKey keyVariety ik) >>= \case
+				Just ib -> case fastMigrate ib of
+					Just fm -> fromMaybe ik <$> fm ik b af False
+					Nothing -> pure ik
+				Nothing -> pure ik
diff --git a/Command/Expire.hs b/Command/Expire.hs
new file mode 100644
index 0000000000..7cbf0a8230
--- /dev/null
+++ b/Command/Expire.hs
@@ -0,0 +1,117 @@
+{- git-annex command
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Expire where
+
+import Command
+import Logs.Activity
+import Logs.UUID
+import Logs.MapLog
+import Logs.Trust
+import Annex.UUID
+import Annex.VectorClock
+import qualified Remote
+import Utility.HumanTime
+
+import Control.Monad.Fail as Fail (MonadFail(..))
+import Data.Time.Clock.POSIX
+import qualified Data.Map as M
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "expire" SectionMaintenance
+		"expire inactive repositories"
+		paramExpire (seek <$$> optParser)
+
+paramExpire :: String
+paramExpire = (paramRepeating $ paramOptional paramRemote ++ ":" ++ paramTime)
+
+data ExpireOptions = ExpireOptions
+	{ expireParams :: CmdParams
+	, activityOption :: Maybe Activity
+	, noActOption :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser ExpireOptions
+optParser desc = ExpireOptions
+	<$> cmdParams desc
+	<*> optional (option (str >>= parseActivity)
+		( long "activity" <> metavar paramName
+		<> help "specify activity that prevents expiry"
+		))
+	<*> switch
+		( long "no-act"
+		<> help "don't really do anything"
+		)
+
+seek :: ExpireOptions -> CommandSeek
+seek o = do
+	expire <- parseExpire (expireParams o)
+	actlog <- lastActivities (activityOption o)
+	u <- getUUID
+	us <- filter (/= u) . M.keys <$> uuidDescMap
+	descs <- uuidDescMap
+	commandActions $ map (start expire (noActOption o) actlog descs) us
+
+start :: Expire -> Bool -> Log Activity -> UUIDDescMap -> UUID -> CommandStart
+start (Expire expire) noact actlog descs u =
+	case lastact of
+		Just ent | notexpired ent -> checktrust (== DeadTrusted) $
+			starting "unexpire" ai si $ do
+				showNote . UnquotedString =<< whenactive
+				unless noact $
+					trustSet u SemiTrusted
+				next $ return True
+		_ -> checktrust (/= DeadTrusted) $
+			starting "expire" ai si $ do
+				showNote . UnquotedString =<< whenactive
+				unless noact $
+					trustSet u DeadTrusted
+				next $ return True
+  where
+	lastact = changed <$> M.lookup u (fromMapLog actlog)
+	whenactive = case lastact of
+		Just (VectorClock c) -> do
+			d <- liftIO $ durationSince $ posixSecondsToUTCTime c
+			return $ "last active: " ++ fromDuration d ++ " ago"
+		_  -> return "no activity"
+	desc = fromUUID u ++ " " ++ fromUUIDDesc (fromMaybe mempty (M.lookup u descs))
+	ai = ActionItemUUID u (UnquotedString desc)
+	si = SeekInput []
+	notexpired ent = case ent of
+		Unknown -> False
+		VectorClock c -> case lookupexpire of
+			Just (Just expiretime) -> c >= expiretime
+			_ -> True
+	lookupexpire = headMaybe $ catMaybes $
+		map (`M.lookup` expire) [Just u, Nothing]
+	checktrust want = stopUnless (want <$> lookupTrust u)
+
+data Expire = Expire (M.Map (Maybe UUID) (Maybe POSIXTime))
+
+parseExpire :: [String] -> Annex Expire
+parseExpire [] = giveup "Specify an expire time."
+parseExpire ps = do
+	now <- liftIO getPOSIXTime
+	Expire . M.fromList <$> mapM (parse now) ps
+  where
+	parse now s = case separate (== ':') s of
+		(t, []) -> return (Nothing, parsetime now t)
+		(n, t) -> do
+			r <- Remote.nameToUUID n
+			return (Just r, parsetime now t)
+	parsetime _ "never" = Nothing
+	parsetime now s = case parseDuration s of
+		Right d -> Just (now - durationToPOSIXTime d)
+		Left e -> giveup $ "bad expire time: " ++ e
+
+parseActivity :: MonadFail m => String -> m Activity
+parseActivity s = case readish s of
+	Nothing -> Fail.fail $ "Unknown activity. Choose from: " ++ 
+		unwords (map show allActivities)
+	Just v -> return v
+
diff --git a/Command/Export.hs b/Command/Export.hs
new file mode 100644
index 0000000000..3fd633c43b
--- /dev/null
+++ b/Command/Export.hs
@@ -0,0 +1,554 @@
+{- git-annex command
+ -
+ - Copyright 2017-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TupleSections, BangPatterns #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Export where
+
+import Command
+import qualified Annex
+import qualified Git
+import qualified Git.DiffTree
+import qualified Git.LsTree
+import qualified Git.Tree
+import qualified Git.Ref
+import Git.Types
+import Git.FilePath
+import Git.Sha
+import qualified Remote
+import Types.Remote
+import Types.Export
+import Annex.Export
+import Annex.Content
+import Annex.Transfer
+import Annex.CatFile
+import Annex.FileMatcher
+import Annex.RemoteTrackingBranch
+import Logs.Location
+import Logs.Export
+import Logs.PreferredContent
+import Database.Export
+import Config
+import Utility.Tmp
+import Utility.Metered
+import Utility.Matcher
+
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Map as M
+import Control.Concurrent
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, jsonOptions, jsonProgressOption] $
+	command "export" SectionCommon
+		"export a tree of files to a special remote"
+		paramTreeish (seek <$$> optParser)
+
+data ExportOptions = ExportOptions
+	{ exportTreeish :: Git.Ref
+	-- ^ can be a tree, a branch, a commit, or a tag
+	, exportRemote :: DeferredParse Remote
+	, exportTracking :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser ExportOptions
+optParser _ = ExportOptions
+	<$> (Git.Ref <$> parsetreeish)
+	<*> (mkParseRemoteOption <$> parseToOption)
+	<*> parsetracking
+  where
+	parsetreeish = argument str
+		( metavar paramTreeish
+		)
+	parsetracking = switch
+		( long "tracking"
+		<> help ("track changes to the " ++ paramTreeish ++ " (deprecated)")
+		)
+
+-- To handle renames which swap files, the exported file is first renamed
+-- to a stable temporary name based on the key.
+exportTempName :: Key -> ExportLocation
+exportTempName ek = mkExportLocation $ toRawFilePath $
+	".git-annex-tmp-content-" ++ serializeKey ek
+
+seek :: ExportOptions -> CommandSeek
+seek o = startConcurrency commandStages $ do
+	r <- getParsed (exportRemote o)
+	unlessM (isExportSupported r) $
+		giveup "That remote does not support exports."
+	
+	-- handle deprecated option
+	when (exportTracking o) $
+		setConfig (remoteAnnexConfig r "tracking-branch")
+			(fromRef $ exportTreeish o)
+	
+	tree <- filterExport r =<<
+		fromMaybe (giveup "unknown tree") <$>
+		inRepo (Git.Ref.tree (exportTreeish o))
+	
+	mtbcommitsha <- getExportCommit r (exportTreeish o)
+
+	db <- openDb (uuid r)
+	writeLockDbWhile db $ do
+		changeExport r db tree
+		unlessM (Annex.getRead Annex.fast) $ do
+			void $ fillExport r db tree mtbcommitsha
+	closeDb db
+
+-- | When the treeish is a branch like master or refs/heads/master
+-- (but not refs/remotes/...), find the commit it points to
+-- and the corresponding remote tracking branch.
+--
+-- The treeish may also be a subdir within a branch, like master:subdir,
+-- that results in this returning the same thing it does for the master
+-- branch.
+getExportCommit :: Remote -> Git.Ref -> Annex (Maybe (RemoteTrackingBranch, Sha))
+getExportCommit r treeish
+	| '/' `notElem` fromRef baseref = do
+		let tb = mkRemoteTrackingBranch r baseref
+		commitsha <- inRepo $ Git.Ref.sha $ Git.Ref.underBase refsheads baseref
+		return (fmap (tb, ) commitsha)
+	| otherwise = return Nothing
+  where
+	baseref = Ref $ S8.takeWhile (/= ':') $ fromRef' $ 
+		Git.Ref.removeBase refsheads treeish
+	refsheads = "refs/heads"
+
+-- | Changes what's exported to the remote. Does not upload any new
+-- files, but does delete and rename files already exported to the remote.
+changeExport :: Remote -> ExportHandle -> ExportFiltered Git.Ref -> CommandSeek
+changeExport r db (ExportFiltered new) = do
+	old <- getExport (uuid r)
+	recordExportBeginning (uuid r) new
+	
+	-- Clean up after incomplete export of a tree, in which
+	-- the next block of code below may have renamed some files to
+	-- temp files. Diff from the incomplete tree to the new tree,
+	-- and delete any temp files that the new tree can't use.
+	let recover diff = commandAction $
+		startRecoverIncomplete r db
+			(Git.DiffTree.srcsha diff)
+			(Git.DiffTree.file diff)
+	forM_ (incompleteExportedTreeishes old) $ \incomplete ->
+		mapdiff recover incomplete new
+	waitForAllRunningCommandActions
+
+	-- Diff the old and new trees, and delete or rename to new name all
+	-- changed files in the export. After this, every file that remains
+	-- in the export will have the content from the new treeish.
+	-- 
+	-- When there was an export conflict, this resolves it.
+	--
+	-- The ExportTree is also updated here to reflect the new tree.
+	case exportedTreeishes old of
+		[] -> updateExportTree db emptyTree new
+		[oldtreesha] -> do
+			diffmap <- mkDiffMap oldtreesha new db
+			let seekdiffmap a = mapM_ a (M.toList diffmap)
+			-- Rename old files to temp, or delete.
+			let deleteoldf = \ek oldf -> commandAction $
+				startUnexport' r db oldf ek
+			seekdiffmap $ \case
+				(ek, (oldf:oldfs, _newf:_)) -> do
+					commandAction $
+						startMoveToTempName r db oldf ek
+					forM_ oldfs (deleteoldf ek)
+				(ek, (oldfs, [])) ->
+					forM_ oldfs (deleteoldf ek)
+				(_ek, ([], _)) -> noop
+			waitForAllRunningCommandActions
+			-- Rename from temp to new files.
+			seekdiffmap $ \case
+				(ek, (_oldf:_, newf:_)) -> commandAction $
+					startMoveFromTempName r db ek newf
+				_ -> noop
+			waitForAllRunningCommandActions
+		ts -> do
+			warning "Resolving export conflict.."
+			forM_ ts $ \oldtreesha -> do
+				-- Unexport both the srcsha and the dstsha,
+				-- because the wrong content may have
+				-- been renamed to the dstsha due to the
+				-- export conflict.
+				let unexportboth d = 
+					[ Git.DiffTree.srcsha d 
+					, Git.DiffTree.dstsha d
+					]
+				-- Don't rename to temp, because the
+				-- content is unknown; delete instead.
+				mapdiff
+					(\diff -> commandAction $ startUnexport r db (Git.DiffTree.file diff) (unexportboth diff))
+					oldtreesha new
+			updateExportTree db emptyTree new
+			waitForAllRunningCommandActions
+	liftIO $ recordExportTreeCurrent db new
+
+	-- Waiting until now to record the export guarantees that,
+	-- if this export is interrupted, there are no files left over
+	-- from a previous export, that are not part of this export.
+	c <- Annex.getState Annex.errcounter
+	when (c == 0) $ do
+		recordExportUnderway (uuid r) $ ExportChange
+			{ oldTreeish = exportedTreeishes old
+			, newTreeish = new
+			}
+  where
+	mapdiff a oldtreesha newtreesha = do
+		(diff, cleanup) <- inRepo $
+			Git.DiffTree.diffTreeRecursive oldtreesha newtreesha
+		sequence_ $ map a diff
+		void $ liftIO cleanup
+
+-- Map of old and new filenames for each changed Key in a diff.
+type DiffMap = M.Map Key ([TopFilePath], [TopFilePath])
+
+mkDiffMap :: Git.Ref -> Git.Ref -> ExportHandle -> Annex DiffMap
+mkDiffMap old new db = do
+	(diff, cleanup) <- inRepo $ Git.DiffTree.diffTreeRecursive old new
+	diffmap <- M.fromListWith combinedm . concat <$> forM diff mkdm
+	void $ liftIO cleanup
+	return diffmap
+  where
+	combinedm (srca, dsta) (srcb, dstb) = (srca ++ srcb, dsta ++ dstb)
+	mkdm i = do
+		srcek <- getek (Git.DiffTree.srcsha i)
+		dstek <- getek (Git.DiffTree.dstsha i)
+		updateExportTree' db srcek dstek i
+		return $ catMaybes
+			[ (, ([Git.DiffTree.file i], [])) <$> srcek
+			, (, ([], [Git.DiffTree.file i])) <$> dstek
+			]
+	getek sha
+		| sha `elem` nullShas = return Nothing
+		| otherwise = Just <$> exportKey sha
+
+newtype FileUploaded = FileUploaded { fromFileUploaded :: Bool }
+
+newtype AllFilled = AllFilled { fromAllFilled :: Bool }
+
+-- | Upload all exported files that are not yet in the remote.
+--
+-- Returns True when some files were uploaded (perhaps not all of them).
+--
+-- Once all exported files have reached the remote, updates the
+-- remote tracking branch.
+fillExport :: Remote -> ExportHandle -> ExportFiltered Git.Ref -> Maybe (RemoteTrackingBranch, Sha) -> Annex Bool
+fillExport r db (ExportFiltered newtree) mtbcommitsha = do
+	(l, cleanup) <- inRepo $ Git.LsTree.lsTree
+		Git.LsTree.LsTreeRecursive
+		(Git.LsTree.LsTreeLong False)
+		newtree
+	cvar <- liftIO $ newMVar (FileUploaded False)
+	allfilledvar <- liftIO $ newMVar (AllFilled True)
+	commandActions $
+		map (startExport r db cvar allfilledvar) l
+	void $ liftIO $ cleanup
+	waitForAllRunningCommandActions
+
+	case mtbcommitsha of
+		Nothing -> noop
+		Just (tb, commitsha) ->
+			whenM (liftIO $ fromAllFilled <$> takeMVar allfilledvar) $
+				makeRemoteTrackingBranchMergeCommit tb commitsha
+					>>= setRemoteTrackingBranch tb
+	
+	liftIO $ fromFileUploaded <$> takeMVar cvar
+
+startExport :: Remote -> ExportHandle -> MVar FileUploaded -> MVar AllFilled -> Git.LsTree.TreeItem -> CommandStart
+startExport r db cvar allfilledvar ti = do
+	ek <- exportKey (Git.LsTree.sha ti)
+	stopUnless (notrecordedpresent ek) $
+		starting ("export " ++ name r) ai si $
+			ifM (either (const False) id <$> tryNonAsync (checkPresentExport (exportActions r) ek loc))
+				( next $ cleanupExport r db ek loc False
+				, do
+					liftIO $ modifyMVar_ cvar (pure . const (FileUploaded True))
+					performExport r db ek af (Git.LsTree.sha ti) loc allfilledvar
+				)
+  where
+	loc = mkExportLocation f
+	f = getTopFilePath (Git.LsTree.file ti)
+	af = AssociatedFile (Just f)
+	ai = ActionItemTreeFile f
+	si = SeekInput []
+	notrecordedpresent ek = 
+		ifM  (liftIO $ notElem loc <$> getExportedLocation db ek)
+			( return True
+			-- When content was lost from the remote and
+			-- a fsck noticed that, the export db will still
+			-- list it as present in the remote. So also check 
+			-- location tracking. 
+			-- However, git sha keys do not have their locations
+			-- tracked, and fsck doesn't check them, so not
+			-- for those.
+			, if isGitShaKey ek
+				then return False
+				else notElem (uuid r) <$> loggedLocations ek
+			)
+
+performExport :: Remote -> ExportHandle -> Key -> AssociatedFile -> Sha -> ExportLocation -> MVar AllFilled -> CommandPerform
+performExport r db ek af contentsha loc allfilledvar = do
+	let storer = storeExport (exportActions r)
+	sent <- tryNonAsync $ if not (isGitShaKey ek)
+		then ifM (inAnnex ek)
+			( notifyTransfer Upload af $
+				-- alwaysUpload because the same key
+				-- could be used for more than one export
+				-- location, and concurrently uploading
+				-- of the content should still be allowed.
+				alwaysUpload (uuid r) ek af Nothing stdRetry $ \pm -> do
+					let rollback = void $
+						performUnexport r db [ek] loc
+					sendAnnex ek rollback $ \f _sz ->
+						Remote.action $
+							storer f ek loc pm
+			, do
+				showNote "not available"
+				return False
+			)
+		-- Sending a non-annexed file.
+		else withTmpFile "export" $ \tmp h -> do
+			b <- catObject contentsha
+			liftIO $ L.hPut h b
+			liftIO $ hClose h
+			Remote.action $
+				storer tmp ek loc nullMeterUpdate
+	let failedsend = liftIO $ modifyMVar_ allfilledvar (pure . const (AllFilled False))
+	case sent of
+		Right True -> next $ cleanupExport r db ek loc True
+		Right False -> do
+			failedsend
+			stop
+		Left err -> do
+			failedsend
+			throwM err
+
+cleanupExport :: Remote -> ExportHandle -> Key -> ExportLocation -> Bool -> CommandCleanup
+cleanupExport r db ek loc sent = do
+	liftIO $ addExportedLocation db ek loc
+	when (sent && not (isGitShaKey ek)) $
+		logChange ek (uuid r) InfoPresent
+	return True
+
+startUnexport :: Remote -> ExportHandle -> TopFilePath -> [Git.Sha] -> CommandStart
+startUnexport r db f shas = do
+	eks <- forM (filter (`notElem` nullShas) shas) exportKey
+	if null eks
+		then stop
+		else starting ("unexport " ++ name r) ai si $
+			performUnexport r db eks loc
+  where
+	loc = mkExportLocation f'
+	f' = getTopFilePath f
+	ai = ActionItemTreeFile f'
+	si = SeekInput []
+
+startUnexport' :: Remote -> ExportHandle -> TopFilePath -> Key -> CommandStart
+startUnexport' r db f ek =
+	starting ("unexport " ++ name r) ai si $
+		performUnexport r db [ek] loc
+  where
+	loc = mkExportLocation f'
+	f' = getTopFilePath f
+	ai = ActionItemTreeFile f'
+	si = SeekInput []
+
+-- Unlike a usual drop from a repository, this does not check that
+-- numcopies is satisfied before removing the content. Typically an export
+-- remote is untrusted, so would not count as a copy anyway.
+-- Or, an export may be appendonly, and removing a file from it does
+-- not really remove the content, which must be accessible later on.
+performUnexport :: Remote -> ExportHandle -> [Key] -> ExportLocation -> CommandPerform
+performUnexport r db eks loc = do
+	ifM (allM rm eks)
+		( next $ cleanupUnexport r db eks loc
+		, stop
+		)
+  where
+	rm ek = Remote.action $ removeExport (exportActions r) ek loc
+
+cleanupUnexport :: Remote -> ExportHandle -> [Key] -> ExportLocation -> CommandCleanup
+cleanupUnexport r db eks loc = do
+	liftIO $ do
+		forM_ eks $ \ek ->
+			removeExportedLocation db ek loc
+		flushDbQueue db
+
+	-- A versionedExport remote supports removeExportLocation to remove
+	-- the file from the exported tree, but still retains the content
+	-- and allows retrieving it.
+	unless (versionedExport (exportActions r)) $ do
+		remaininglocs <- liftIO $ 
+			concat <$> forM eks (getExportedLocation db)
+		when (null remaininglocs) $
+			forM_ eks $ \ek ->
+				logChange ek (uuid r) InfoMissing
+	
+	removeEmptyDirectories r db loc eks
+
+startRecoverIncomplete :: Remote -> ExportHandle -> Git.Sha -> TopFilePath -> CommandStart
+startRecoverIncomplete r db sha oldf
+	| sha `elem` nullShas = stop
+	| otherwise = do
+		ek <- exportKey sha
+		let loc = exportTempName ek
+		let ai = ActionItemTreeFile (fromExportLocation loc)
+		let si = SeekInput []
+		starting ("unexport " ++ name r) ai si $ do
+			liftIO $ removeExportedLocation db ek oldloc
+			performUnexport r db [ek] loc
+  where
+	oldloc = mkExportLocation $ getTopFilePath oldf
+
+startMoveToTempName :: Remote -> ExportHandle -> TopFilePath -> Key -> CommandStart
+startMoveToTempName r db f ek = case renameExport (exportActions r) of
+	Just _ -> starting ("rename " ++ name r) ai si $
+		performRename r db ek loc tmploc
+	Nothing -> starting ("unexport " ++ name r) ai' si $
+		performUnexport r db [ek] loc
+  where
+	loc = mkExportLocation f'
+	f' = getTopFilePath f
+	tmploc = exportTempName ek
+	ai = ActionItemOther $ Just $ 
+		QuotedPath f' <> " -> " <> QuotedPath (fromExportLocation tmploc)
+	ai' = ActionItemTreeFile (fromExportLocation loc)
+	si = SeekInput []
+
+startMoveFromTempName :: Remote -> ExportHandle -> Key -> TopFilePath -> CommandStart
+startMoveFromTempName r db ek f = case renameExport (exportActions r) of
+	Just _ -> stopUnless (liftIO $ elem tmploc <$> getExportedLocation db ek) $
+		starting ("rename " ++ name r) ai si $
+			performRename r db ek tmploc loc
+	Nothing -> starting ("unexport " ++ name r) ai' si $
+		performUnexport r db [ek] tmploc
+  where
+	loc = mkExportLocation f'
+	f' = getTopFilePath f
+	tmploc = exportTempName ek
+	ai = ActionItemOther $ Just $
+		QuotedPath (fromExportLocation tmploc) <> " -> " <> QuotedPath f'
+	ai' = ActionItemTreeFile (fromExportLocation tmploc)
+	si = SeekInput []
+
+performRename :: Remote -> ExportHandle -> Key -> ExportLocation -> ExportLocation -> CommandPerform
+performRename r db ek src dest = case renameExport (exportActions r) of
+	Just renameaction -> tryNonAsync (renameaction ek src dest) >>= \case
+		Right (Just ()) -> next $ cleanupRename r db ek src dest
+		Left err -> do
+			warning $ UnquotedString $ "rename failed (" ++ show err ++ "); deleting instead"
+			fallbackdelete
+		Right Nothing -> fallbackdelete
+	-- remote does not support renaming
+	Nothing -> fallbackdelete
+  where
+	fallbackdelete = performUnexport r db [ek] src
+
+cleanupRename :: Remote -> ExportHandle -> Key -> ExportLocation -> ExportLocation -> CommandCleanup
+cleanupRename r db ek src dest = do
+	liftIO $ do
+		removeExportedLocation db ek src
+		addExportedLocation db ek dest
+		flushDbQueue db
+	if exportDirectories src /= exportDirectories dest
+		then removeEmptyDirectories r db src [ek]
+		else return True
+
+-- | Remove empty directories from the export. Call after removing an
+-- exported file, and after calling removeExportLocation and flushing the
+-- database.
+removeEmptyDirectories :: Remote -> ExportHandle -> ExportLocation -> [Key] -> Annex Bool
+removeEmptyDirectories r db loc ks
+	| null (exportDirectories loc) = return True
+	| otherwise = case removeExportDirectory (exportActions r) of
+		Nothing -> return True
+		Just removeexportdirectory -> do
+			ok <- allM (go removeexportdirectory) 
+				(reverse (exportDirectories loc))
+			unless ok $ liftIO $ do
+				-- Add location back to export database, 
+				-- so this is tried again next time.
+				forM_ ks $ \k ->
+					addExportedLocation db k loc
+				flushDbQueue db
+			return ok
+  where
+	go removeexportdirectory d = 
+		ifM (liftIO $ isExportDirectoryEmpty db d)
+			( Remote.action $ removeexportdirectory d
+			, return True
+			)
+
+-- | A value that has been filtered through the remote's preferred content
+-- expression.
+newtype ExportFiltered t = ExportFiltered t
+
+-- | Filters the tree to annexed files that are preferred content of the
+-- remote, and also including non-annexed files, but not submodules or
+-- non-annexed symlinks.
+--
+-- A log is written with tree items that were filtered out, so they can
+-- be added back in when importing from the remote.
+filterExport :: Remote -> Git.Ref -> Annex (ExportFiltered Git.Ref)
+filterExport r tree = logExportExcluded (uuid r) $ \logwriter -> do
+	m <- preferredContentMap
+	case M.lookup (uuid r) m of
+		Just (matcher, matcherdesc) | not (isEmpty matcher) ->
+			ExportFiltered <$> go (Just (matcher, matcherdesc)) logwriter
+		_ -> ExportFiltered <$> go Nothing logwriter
+  where
+	go mmatcher logwriter = do
+		g <- Annex.gitRepo
+		Git.Tree.adjustTree
+			(check mmatcher logwriter)
+			[]
+			(\_old new -> new)
+			[]
+			tree
+			g
+
+	check mmatcher logwriter ti@(Git.Tree.TreeItem topf mode sha) =
+		case toTreeItemType mode of
+			-- Don't export submodule entries.
+			Just TreeSubmodule -> excluded
+			Just TreeSymlink -> checkkey True
+			_ -> checkkey False
+	  where
+		excluded = do
+			() <- liftIO $ logwriter ti
+			return Nothing
+
+		checkkey issymlink =
+			case mmatcher of
+				Nothing
+					| issymlink -> catKey sha >>= \case
+						Just _ -> return (Just ti)
+						Nothing -> excluded
+					| otherwise -> return (Just ti)
+				Just matcher -> catKey sha >>= \case
+					Just k -> checkmatcher matcher k
+					Nothing
+						| issymlink -> excluded
+						| otherwise -> return (Just ti)
+
+		checkmatcher matcher k = do
+			let mi = MatchingInfo $ ProvidedInfo
+				{ providedFilePath = Just $
+					-- Match filename relative
+					-- to the top of the tree.
+					getTopFilePath topf
+				, providedKey = Just k
+				, providedFileSize = Nothing
+				, providedMimeType = Nothing
+				, providedMimeEncoding = Nothing
+				, providedLinkType = Nothing
+				}
+			ifM (checkMatcher' matcher mi mempty)
+				( return (Just ti)
+				, excluded
+				)
diff --git a/Command/FilterBranch.hs b/Command/FilterBranch.hs
new file mode 100644
index 0000000000..6c565c5d29
--- /dev/null
+++ b/Command/FilterBranch.hs
@@ -0,0 +1,195 @@
+{- git-annex command
+ -
+ - Copyright 2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.FilterBranch where
+
+import Command
+import qualified Annex
+import qualified Annex.Branch
+import Annex.Branch.Transitions
+import Types.Transitions
+import Annex.HashObject
+import Annex.Tmp
+import Annex.SpecialRemote.Config
+import Types.ProposedAccepted
+import Logs
+import Logs.Remote
+import Git.Types
+import Git.FilePath
+import Git.Index
+import Git.Env
+import Git.UpdateIndex
+import qualified Git.LsTree as LsTree
+import qualified Git.Branch as Git
+import Utility.RawFilePath
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import qualified Data.ByteString.Lazy as L
+import Data.ByteString.Builder
+import qualified System.FilePath.ByteString as P
+
+cmd :: Command
+cmd = noMessages $ withAnnexOptions [annexedMatchingOptions] $ 
+	command "filter-branch" SectionMaintenance 
+		"filter information from the git-annex branch"
+		paramPaths (seek <$$> optParser)
+
+data FilterBranchOptions = FilterBranchOptions
+	{ includeFiles :: CmdParams
+	, keyOptions :: Maybe KeyOptions
+	, keyInformation :: [IncludeExclude (DeferredParse UUID)]
+	, repoConfig :: [IncludeExclude (DeferredParse UUID)]
+	, includeGlobalConfig :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser FilterBranchOptions
+optParser desc = FilterBranchOptions
+	<$> cmdParams desc
+	<*> optional parseKeyOptions
+	<*> many (parseIncludeExclude "key-information")
+	<*> many (parseIncludeExclude "repo-config")
+	<*> switch
+		( long "include-global-config"
+		<> help "include global configuration"
+		)
+
+data IncludeExclude t
+	= Include t
+	| Exclude t
+	| IncludeAll
+	deriving (Show, Eq, Ord)
+
+isInclude :: IncludeExclude t -> Bool
+isInclude (Include _) = True
+isInclude IncludeAll = True
+isInclude (Exclude _) = False
+
+parseIncludeExclude :: String -> Parser (IncludeExclude (DeferredParse UUID))
+parseIncludeExclude s = 
+	( Include <$> parseRepositoryOption
+		("include-" ++ s ++ "-for")
+		"include information about a repository"
+	) <|>
+	( Exclude <$> parseRepositoryOption
+		("exclude-" ++ s ++ "-for")
+		"exclude information about a repository"
+	) <|>
+	( flag' IncludeAll 
+		( long ("include-all-" ++ s)
+		<> help "include information about all non-excluded repositories"
+		)
+	)
+
+parseRepositoryOption :: String -> String -> Parser (DeferredParse UUID)
+parseRepositoryOption s h = parseUUIDOption <$> strOption
+	( long s
+	<> help h
+	<> metavar (paramRemote `paramOr` paramDesc `paramOr` paramUUID)
+	<> completeRemotes
+	)
+
+mkUUIDMatcher :: [IncludeExclude (DeferredParse UUID)] -> Annex (UUID -> Bool)
+mkUUIDMatcher l = do
+	sameasmap <- M.mapMaybe
+		(toUUID . fromProposedAccepted <$$> M.lookup sameasUUIDField)
+		<$> remoteConfigMap
+	mkUUIDMatcher' sameasmap <$> mapM get l
+  where
+	get (Include v) = Include <$> getParsed v
+	get (Exclude v) = Exclude <$> getParsed v
+	get IncludeAll = pure IncludeAll
+
+mkUUIDMatcher' :: M.Map UUID UUID -> [IncludeExclude UUID] -> (UUID -> Bool)
+mkUUIDMatcher' sameasmap l = \u -> 
+	let sameas = M.lookup u sameasmap
+	in ( S.member (Include u) includes
+		|| S.member IncludeAll includes
+		|| maybe False (\u' -> S.member (Include u') includes) sameas
+		)
+		&& S.notMember (Exclude u) excludes
+		&& maybe True (\u' -> S.notMember (Exclude u') excludes) sameas
+  where
+	(includes, excludes) = (S.partition isInclude (S.fromList l))
+
+seek :: FilterBranchOptions -> CommandSeek
+seek o = withOtherTmp $ \tmpdir -> do
+	let tmpindex = tmpdir P.</> "index"
+	gc <- Annex.getGitConfig
+	tmpindexrepo <- Annex.inRepo $ \r ->
+		addGitEnv r indexEnv (fromRawFilePath tmpindex)
+	withUpdateIndex tmpindexrepo $ \h -> do
+		keyinfomatcher <- mkUUIDMatcher (keyInformation o)
+		repoconfigmatcher <- mkUUIDMatcher (repoConfig o)
+
+		let addtoindex f sha = liftIO $ streamUpdateIndex' h $
+			pureStreamer $ L.fromStrict $ LsTree.formatLsTree $ LsTree.TreeItem
+				{ LsTree.mode = fromTreeItemType TreeFile
+				, LsTree.typeobj = fmtObjectType BlobObject
+				, LsTree.sha = sha
+				, LsTree.size = Nothing
+				, LsTree.file = asTopFilePath f
+				}
+		
+		let filterbanch matcher f c
+			| L.null c = noop
+			| otherwise = case filterBranch matcher gc f c of
+				ChangeFile builder -> do
+					let c' = toLazyByteString builder
+					unless (L.null c') $
+						addtoindex f =<< hashBlob c'
+				-- This could perhaps be optimised by looking
+				-- up the sha of the file in the branch.
+				PreserveFile -> addtoindex f =<< hashBlob c
+
+		-- Add information for all keys that are being included,
+		-- filtering out information for repositories that are not
+		-- being included.
+		let addkeyinfo k = startingCustomOutput k $ do
+			forM_ (keyLogFiles gc k) $ \f ->
+				filterbanch keyinfomatcher f
+					=<< Annex.Branch.get f
+			next (return True)
+		let seeker = AnnexedFileSeeker
+			{ startAction = \_ _ _ k -> addkeyinfo k
+			, checkContentPresent = Nothing
+			, usesLocationLog = True
+			}
+		-- Avoid the usual default of all files in the current
+		-- directory and below, because this command is documented
+		-- as only including the information it has explicitly been
+		-- told to include.
+		when (not (null (includeFiles o)) || isJust (keyOptions o)) $
+			withKeyOptions (keyOptions o) False seeker
+				(commandAction . \(_, k, _) -> addkeyinfo k)
+				(withFilesInGitAnnex ww seeker)
+				=<< workTreeItems ww (includeFiles o)
+	
+		-- Add repository configs for all repositories that are
+		-- being included.
+		forM_ topLevelUUIDBasedLogs $ \f ->
+			filterbanch repoconfigmatcher f
+				=<< Annex.Branch.get f
+
+		-- Add global configs when included.
+		when (includeGlobalConfig o) $
+			forM_ otherTopLevelLogs $ \f -> do
+				c <- Annex.Branch.get f
+				unless (L.null c) $
+					addtoindex f =<< hashBlob c
+
+	-- Commit the temporary index, and output the result.
+	t <- liftIO $ Git.writeTree tmpindexrepo
+	liftIO $ removeWhenExistsWith removeLink tmpindex
+	cmode <- annexCommitMode <$> Annex.getGitConfig
+	cmessage <- Annex.Branch.commitMessage
+	c <- inRepo $ Git.commitTree cmode [cmessage] [] t
+	liftIO $ putStrLn (fromRef c)
+  where
+	ww = WarnUnmatchLsFiles "filter-branch"
diff --git a/Command/FilterProcess.hs b/Command/FilterProcess.hs
new file mode 100644
index 0000000000..ff20dd7268
--- /dev/null
+++ b/Command/FilterProcess.hs
@@ -0,0 +1,89 @@
+{- git-annex command
+ -
+ - Copyright 2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.FilterProcess where
+
+import Command
+import qualified Command.Smudge
+import Git.FilterProcess
+import Git.PktLine
+import Annex.Link
+
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Lazy as L
+
+cmd :: Command
+cmd = noCommit $ noMessages $
+	command "filter-process" SectionPlumbing 
+		"long running git filter process"
+		paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek _ = liftIO longRunningFilterProcessHandshake >>= \case
+	Left err -> giveup err
+	Right () -> go
+  where
+	go = liftIO getFilterRequest >>= \case
+		Just (Smudge f) -> do
+			smudge f
+			go
+		Just (Clean f) -> do
+			clean f
+			go
+		Nothing -> return ()
+
+smudge :: FilePath -> Annex ()
+smudge file = do
+	{- The whole git file content is necessarily buffered in memory,
+	 - because we have to consume everything git is sending before
+	 - we can respond to it. An annexed file will be only a pointer
+	 - though. -}
+	b <- B.concat . map pktLineToByteString <$> liftIO readUntilFlushPkt
+	Command.Smudge.smudge' file (L.fromStrict b)
+	{- Git expects us to output the content of unlocked annexed files,
+	 - but if we got a pointer, we output only the pointer.
+	 - See Command.Smudge.smudge for details of how this works. -}
+	liftIO $ respondFilterRequest b
+
+clean :: FilePath -> Annex ()
+clean file = do
+	{- We have to consume everything git is sending before we can
+	 - respond to it. But it can be an arbitrarily large file,
+	 - which is being added to the annex, and we do not want to buffer
+	 - all that in memory. 
+	 -
+	 - Start by reading enough to determine if the file is an annex
+	 - pointer.
+	 -}
+	let conv b l = (B.concat (map pktLineToByteString l), b)
+	(b, readcomplete) <- 
+		either (conv False) (conv True)
+			<$> liftIO (readUntilFlushPktOrSize maxPointerSz)
+	
+	let passthrough
+		| readcomplete = liftIO $ respondFilterRequest b
+		| otherwise = liftIO $ do
+			-- Have to buffer the file content in memory here,
+			-- but it's not an annexed file, so not typically
+			-- large, and it's all stored in git, which also
+			-- buffers files in memory.
+			b' <- B.concat . (map pktLineToByteString)
+				<$> readUntilFlushPkt
+			respondFilterRequest (b <> b')
+	let discardreststdin
+		| readcomplete = return ()
+		| otherwise = liftIO discardUntilFlushPkt
+	let emitpointer = liftIO . respondFilterRequest . formatPointer
+	-- This does not incrementally hash, so both git and git-annex
+	-- read from the file. It may be less expensive to incrementally
+	-- hash the content provided by git, but Backend does not currently
+	-- have an interface to do so.
+	Command.Smudge.clean' (toRawFilePath file)
+		(parseLinkTargetOrPointer' b)
+		passthrough
+		discardreststdin
+		emitpointer
diff --git a/Command/Find.hs b/Command/Find.hs
new file mode 100644
index 0000000000..3a1fabe5e2
--- /dev/null
+++ b/Command/Find.hs
@@ -0,0 +1,128 @@
+{- git-annex command
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Find where
+
+import Data.Default
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Short as S (fromShort)
+import qualified Data.ByteString.Char8 as S8
+
+import Command
+import Limit
+import Types.Key
+import Git.FilePath
+import qualified Utility.Format
+import Utility.DataUnits
+import Utility.Terminal
+
+cmd :: Command
+cmd = withAnnexOptions [annexedMatchingOptions] $ mkCommand $
+	command "find" SectionQuery "lists available files"
+		paramPaths (seek <$$> optParser)
+
+mkCommand :: Command -> Command
+mkCommand = noCommit . noMessages . withAnnexOptions [jsonOptions]
+
+data FindOptions = FindOptions
+	{ findThese :: CmdParams
+	, formatOption :: Maybe Utility.Format.Format
+	, keyOptions :: Maybe KeyOptions
+	, batchOption :: BatchMode
+	}
+
+optParser :: CmdParamsDesc -> Parser FindOptions
+optParser desc = FindOptions
+	<$> cmdParams desc
+	<*> optional parseFormatOption
+	<*> optional parseBranchKeysOption
+	<*> parseBatchOption False
+
+parseFormatOption :: Parser Utility.Format.Format
+parseFormatOption = parseFormatOption' "${file}\0"
+
+parseFormatOption' :: String -> Parser Utility.Format.Format
+parseFormatOption' print0format = 
+	option (Utility.Format.gen <$> str)
+		( long "format" <> metavar paramFormat
+		<> help "control format of output"
+		)
+	<|> flag' (Utility.Format.gen print0format)
+		( long "print0"
+		<> help "use nulls to separate output rather than lines"
+		)
+
+seek :: FindOptions -> CommandSeek
+seek o = do
+	unless (isJust (keyOptions o)) $
+		checkNotBareRepo
+	isterminal <- liftIO $ checkIsTerminal stdout
+	seeker <- contentPresentUnlessLimited $ AnnexedFileSeeker
+		{ startAction = const (start o isterminal)
+		, checkContentPresent = Nothing
+		, usesLocationLog = False
+		}
+	case batchOption o of
+		NoBatch -> withKeyOptions (keyOptions o) False seeker
+			(commandAction . startKeys o isterminal)
+			(withFilesInGitAnnex ww seeker)
+			=<< workTreeItems ww (findThese o)
+		Batch fmt -> batchOnly (keyOptions o) (findThese o) $
+			batchAnnexedFiles fmt seeker
+  where
+	ww = WarnUnmatchLsFiles "find"
+
+-- Default to needing content to be present, but if the user specified a
+-- limit, content does not need to be present.
+contentPresentUnlessLimited :: AnnexedFileSeeker -> Annex AnnexedFileSeeker
+contentPresentUnlessLimited s = do
+	islimited <- limited
+	return $ s
+		{ checkContentPresent = if islimited
+			then Nothing
+			else Just True
+		}
+
+start :: FindOptions -> IsTerminal -> SeekInput -> RawFilePath -> Key -> CommandStart
+start o isterminal _ file key = startingCustomOutput key $ do
+	showFormatted isterminal (formatOption o) file
+		(formatVars key (AssociatedFile (Just file)))
+	next $ return True
+
+startKeys :: FindOptions -> IsTerminal -> (SeekInput, Key, ActionItem) -> CommandStart
+startKeys o isterminal (si, key, ActionItemBranchFilePath (BranchFilePath _ topf) _) = 
+	start o isterminal si (getTopFilePath topf) key
+startKeys _ _ _ = stop
+
+showFormatted :: IsTerminal -> Maybe Utility.Format.Format -> S.ByteString -> [(String, String)] -> Annex ()
+showFormatted (IsTerminal isterminal) format unformatted vars =
+	unlessM (showFullJSON $ JSONChunk vars) $
+		case format of
+			Nothing -> do
+				liftIO $ S8.putStrLn $ if isterminal
+					then Utility.Format.encode_c (const False) unformatted
+					else unformatted
+			Just formatter -> liftIO $ putStr $
+				Utility.Format.format formatter $
+					M.fromList vars
+
+formatVars :: Key -> AssociatedFile -> [(String, String)]
+formatVars key (AssociatedFile af) =
+	(maybe id (\f l -> (("file", fromRawFilePath f) : l)) af)
+	[ ("key", serializeKey key)
+	, ("backend", decodeBS $ formatKeyVariety $ fromKey keyVariety key)
+	, ("bytesize", size show)
+	, ("humansize", size $ roughSize storageUnits True)
+	, ("keyname", decodeBS $ S.fromShort $ fromKey keyName key)
+	, ("hashdirlower", fromRawFilePath $ hashDirLower def key)
+	, ("hashdirmixed", fromRawFilePath $ hashDirMixed def key)
+	, ("mtime", whenavail show $ fromKey keyMtime key)
+	]
+  where
+	size c = whenavail c $ fromKey keySize key
+	whenavail = maybe "unknown"
diff --git a/Command/FindKeys.hs b/Command/FindKeys.hs
new file mode 100644
index 0000000000..f105d7f8b9
--- /dev/null
+++ b/Command/FindKeys.hs
@@ -0,0 +1,49 @@
+{- git-annex command
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.FindKeys where
+
+import Command
+import qualified Command.Find
+import qualified Utility.Format
+import Utility.Terminal
+
+cmd :: Command
+cmd = withAnnexOptions [keyMatchingOptions] $ Command.Find.mkCommand $
+	command "findkeys" SectionQuery "lists available keys"
+		paramNothing (seek <$$> optParser)
+
+data FindKeysOptions = FindKeysOptions
+	{ formatOption :: Maybe Utility.Format.Format
+	}
+
+optParser :: CmdParamsDesc -> Parser FindKeysOptions
+optParser _ = FindKeysOptions
+	<$> optional (Command.Find.parseFormatOption' "${key}\0")
+
+seek :: FindKeysOptions -> CommandSeek
+seek o = do
+	isterminal <- liftIO $ checkIsTerminal stdout
+	seeker <- Command.Find.contentPresentUnlessLimited $ AnnexedFileSeeker
+		{ checkContentPresent = Nothing
+		, usesLocationLog = False
+		-- startAction is not actually used since this
+		-- is not used to seek files
+		, startAction = \_ _ _ key -> start' o isterminal key
+		}
+	withKeyOptions (Just WantAllKeys) False seeker
+		(commandAction . start o isterminal)
+		(const noop) (WorkTreeItems [])
+
+start :: FindKeysOptions -> IsTerminal -> (SeekInput, Key, ActionItem) -> CommandStart
+start o isterminal (_si, key, _ai) = start' o isterminal key
+
+start' :: FindKeysOptions -> IsTerminal -> Key -> CommandStart
+start' o isterminal key = startingCustomOutput key $ do
+	Command.Find.showFormatted isterminal (formatOption o) (serializeKey' key)
+		(Command.Find.formatVars key (AssociatedFile Nothing))
+	next $ return True
diff --git a/Command/FindRef.hs b/Command/FindRef.hs
new file mode 100644
index 0000000000..0009dc2ce0
--- /dev/null
+++ b/Command/FindRef.hs
@@ -0,0 +1,27 @@
+{- git-annex command
+ -
+ - Copyright 2014-2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.FindRef where
+
+import Command
+import qualified Command.Find as Find
+import qualified Git
+
+cmd :: Command
+cmd = withAnnexOptions [annexedMatchingOptions] $ Find.mkCommand $ 
+	command "findref" SectionPlumbing
+		"lists files in a git ref (deprecated)"
+		paramRef (seek <$$> Find.optParser)
+
+seek :: Find.FindOptions -> CommandSeek
+seek o = Find.seek o'
+  where
+	o' = o 
+		{ Find.keyOptions = Just $ WantBranchKeys $
+			map (Git.Ref . encodeBS) (Find.findThese o)
+		, Find.findThese = []
+		}
diff --git a/Command/Fix.hs b/Command/Fix.hs
new file mode 100644
index 0000000000..862853a861
--- /dev/null
+++ b/Command/Fix.hs
@@ -0,0 +1,106 @@
+{- git-annex command
+ -
+ - Copyright 2010-2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Command.Fix where
+
+import Command
+import Config
+import qualified Annex
+import Annex.ReplaceFile
+import Annex.Content
+import Annex.Perms
+import Annex.Link
+import qualified Database.Keys
+import qualified Utility.RawFilePath as R
+
+import System.PosixCompat.Files (fileMode, linkCount)
+#if ! defined(mingw32_HOST_OS)
+import qualified System.Posix.Files as Posix
+import Utility.Touch
+#endif
+
+cmd :: Command
+cmd = noCommit $ withAnnexOptions [annexedMatchingOptions, jsonOptions] $
+	command "fix" SectionMaintenance
+		"fix up links to annexed content"
+		paramPaths (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek ps = unlessM crippledFileSystem $
+	withFilesInGitAnnex ww seeker =<< workTreeItems ww ps
+  where
+	ww = WarnUnmatchLsFiles "fix"
+	seeker = AnnexedFileSeeker
+		{ startAction = const $ start FixAll
+		, checkContentPresent = Nothing
+		, usesLocationLog = False
+		}
+
+data FixWhat = FixSymlinks | FixAll
+
+start :: FixWhat -> SeekInput -> RawFilePath -> Key -> CommandStart
+start fixwhat si file key = do
+	currlink <- liftIO $ catchMaybeIO $ R.readSymbolicLink file
+	wantlink <- calcRepo $ gitAnnexLink file key
+	case currlink of
+		Just l
+			| l /=  wantlink -> fixby $ fixSymlink file wantlink
+			| otherwise -> stop
+		Nothing -> case fixwhat of
+			FixAll -> fixthin
+			FixSymlinks -> stop
+  where
+	fixby = starting "fix" (mkActionItem (key, file)) si
+	fixthin = do
+		obj <- calcRepo (gitAnnexLocation key)
+		stopUnless (isUnmodified key file <&&> isUnmodified key obj) $ do
+			thin <- annexThin <$> Annex.getGitConfig
+			fs <- liftIO $ catchMaybeIO $ R.getFileStatus file
+			os <- liftIO $ catchMaybeIO $ R.getFileStatus obj
+			case (linkCount <$> fs, linkCount <$> os, thin) of
+				(Just 1, Just 1, True) ->
+					fixby $ makeHardLink file key
+				(Just n, Just n', False) | n > 1 && n == n' ->
+					fixby $ breakHardLink file key obj
+				_ -> stop
+
+breakHardLink :: RawFilePath -> Key -> RawFilePath -> CommandPerform
+breakHardLink file key obj = do
+	replaceWorkTreeFile (fromRawFilePath file) $ \tmp -> do
+		mode <- liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus file
+		unlessM (checkedCopyFile key obj tmp mode) $
+			giveup "unable to break hard link"
+		thawContent tmp
+		Database.Keys.storeInodeCaches key [tmp]
+		modifyContentDir obj $ freezeContent obj
+	next $ return True
+
+makeHardLink :: RawFilePath -> Key -> CommandPerform
+makeHardLink file key = do
+	replaceWorkTreeFile (fromRawFilePath file) $ \tmp -> do
+		mode <- liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus file
+		linkFromAnnex' key tmp mode >>= \case
+			LinkAnnexFailed -> giveup "unable to make hard link"
+			_ -> noop
+	next $ return True
+
+fixSymlink :: RawFilePath -> RawFilePath -> CommandPerform
+fixSymlink file link = do
+#if ! defined(mingw32_HOST_OS)
+	-- preserve mtime of symlink
+	mtime <- liftIO $ catchMaybeIO $ Posix.modificationTimeHiRes
+		<$> R.getSymbolicLinkStatus file
+#endif
+	replaceWorkTreeFile (fromRawFilePath file) $ \tmpfile -> do
+		liftIO $ R.createSymbolicLink link tmpfile
+#if ! defined(mingw32_HOST_OS)
+		liftIO $ maybe noop (\t -> touch tmpfile t False) mtime
+#endif
+	stageSymlink file =<< hashSymlink link
+	next $ return True
diff --git a/Command/Forget.hs b/Command/Forget.hs
new file mode 100644
index 0000000000..fb8de396aa
--- /dev/null
+++ b/Command/Forget.hs
@@ -0,0 +1,59 @@
+{- git-annex command
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Forget where
+
+import Command
+import qualified Annex.Branch as Branch
+import Logs.Transitions
+import qualified Annex
+import Annex.VectorClock
+import Git.Types
+
+cmd :: Command
+cmd = command "forget" SectionMaintenance 
+	"prune git-annex branch history"
+	paramNothing (seek <$$> optParser)
+
+data ForgetOptions = ForgetOptions
+	{ dropDead :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser ForgetOptions
+optParser _ = ForgetOptions
+	<$> switch
+		( long "drop-dead"
+		<> help "drop references to dead repositories"
+		)
+
+seek :: ForgetOptions -> CommandSeek
+seek = commandAction . start
+
+start :: ForgetOptions -> CommandStart
+start o = starting "forget" ai si $ do
+	c <- currentVectorClock
+	let basets = addTransition c ForgetGitHistory noTransitions
+	let ts = if dropDead o
+		then addTransition c ForgetDeadRemotes basets
+		else basets
+	perform ts =<< Annex.getRead Annex.force
+  where
+	ai = ActionItemOther (Just (UnquotedString (fromRef Branch.name)))
+	si = SeekInput []
+
+perform :: Transitions -> Bool -> CommandPerform
+perform ts True = do
+	recordTransitions (Branch.change (Branch.RegardingUUID [])) ts
+	-- get branch committed before continuing with the transition
+	_ <- Branch.update
+	void $ Branch.performTransitions ts True []
+	next $ return True
+perform _ False = do
+	showLongNote "To forget git-annex branch history, you must specify --force. This deletes metadata!"
+	stop
diff --git a/Command/FromKey.hs b/Command/FromKey.hs
new file mode 100644
index 0000000000..292ab179a6
--- /dev/null
+++ b/Command/FromKey.hs
@@ -0,0 +1,142 @@
+{- git-annex command
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.FromKey where
+
+import Command
+import qualified Annex
+import qualified Database.Keys
+import qualified Backend.URL
+import Annex.Content
+import Annex.WorkTree
+import Annex.Perms
+import Annex.Link
+import Annex.FileMatcher
+import Annex.Ingest
+import Git.FilePath
+import Utility.Url.Parse
+
+import Network.URI
+
+cmd :: Command
+cmd = notBareRepo $ withAnnexOptions [jsonOptions] $
+	command "fromkey" SectionPlumbing "adds a file using a specific key"
+		(paramRepeating (paramPair paramKey paramPath))
+		(seek <$$> optParser)
+
+data FromKeyOptions = FromKeyOptions
+	{ keyFilePairs :: CmdParams 
+	, batchOption :: BatchMode
+	}
+
+optParser :: CmdParamsDesc -> Parser FromKeyOptions
+optParser desc = FromKeyOptions
+	<$> cmdParams desc
+	<*> parseBatchOption False
+
+seek :: FromKeyOptions -> CommandSeek
+seek o = do
+	matcher <- addUnlockedMatcher
+	case (batchOption o, keyFilePairs o) of
+		(Batch fmt, _) -> batchOnly Nothing (keyFilePairs o) $
+			seekBatch matcher fmt
+		-- older way of enabling batch input, does not support BatchNull
+		(NoBatch, []) -> seekBatch matcher (BatchFormat BatchLine (BatchKeys False))
+		(NoBatch, ps) -> do
+			force <- Annex.getRead Annex.force
+			withPairs (commandAction . start matcher force) ps
+
+seekBatch :: AddUnlockedMatcher -> BatchFormat -> CommandSeek
+seekBatch matcher fmt = batchInput fmt parse (commandAction . go)
+  where
+	parse s = do
+		let (keyname, file) = separate (== ' ') s
+		if not (null keyname) && not (null file)
+			then do
+				file' <- liftIO $ relPathCwdToFile (toRawFilePath file)
+				return $ Right (file', keyOpt keyname)
+			else return $
+				Left "Expected pairs of key and filename"
+	go (si, (file, key)) = 
+		let ai = mkActionItem (key, file)
+		in starting "fromkey" ai si $
+			perform matcher key file
+
+start :: AddUnlockedMatcher -> Bool -> (SeekInput, (String, FilePath)) -> CommandStart
+start matcher force (si, (keyname, file)) = do
+	let key = keyOpt keyname
+	unless force $ do
+		inbackend <- inAnnex key
+		unless inbackend $ giveup $
+			"key ("++ keyname ++") is not present in backend (use --force to override this sanity check)"
+	let ai = mkActionItem (key, file')
+	starting "fromkey" ai si $
+		perform matcher key file'
+  where
+	file' = toRawFilePath file
+
+-- From user input to a Key.
+-- User can input either a serialized key, or an url.
+--
+-- In some cases, an input can be parsed as both a key and as an uri.
+-- For example, "WORM--a:a" parses as an uri. To disambiguate, check
+-- the uri scheme, to see if it looks like the prefix of a key. This relies
+-- on key backend names never containing a ':'.
+keyOpt :: String -> Key
+keyOpt = either giveup id . keyOpt'
+
+keyOpt' :: String -> Either String Key
+keyOpt' s = case parseURIPortable s of
+	Just u | not (isKeyPrefix (uriScheme u)) ->
+		Right $ Backend.URL.fromUrl s Nothing False
+	_ -> case deserializeKey s of
+		Just k -> Right k
+		Nothing -> Left $ "bad key/url " ++ s
+
+perform :: AddUnlockedMatcher -> Key -> RawFilePath -> CommandPerform
+perform matcher key file = lookupKeyNotHidden file >>= \case
+	Nothing -> ifM (liftIO $ doesFileExist (fromRawFilePath file))
+		( hasothercontent
+		, do
+			contentpresent <- inAnnex key
+			objectloc <- calcRepo (gitAnnexLocation key)
+			let mi = if contentpresent
+				then MatchingFile $ FileInfo
+					{ contentFile = objectloc
+					, matchFile = file
+					, matchKey = Just key
+					}
+				else keyMatchInfoWithoutContent key file
+			createWorkTreeDirectory (parentDir file)
+			ifM (addUnlocked matcher mi contentpresent)
+				( do
+					stagePointerFile file Nothing =<< hashPointerFile key
+					Database.Keys.addAssociatedFile key =<< inRepo (toTopFilePath file)
+					if contentpresent
+						then linkunlocked
+						else writepointer
+				, do
+					link <- calcRepo $ gitAnnexLink file key
+					addAnnexLink link file
+				)
+			next $ return True
+		)
+	Just k
+		| k == key -> next $ return True
+		| otherwise -> hasothercontent
+  where
+	hasothercontent = do
+		warning $ QuotedPath file <> " already exists with different content"
+		next $ return False
+	
+	linkunlocked = linkFromAnnex key file Nothing >>= \case
+		LinkAnnexFailed -> writepointer
+		_ -> return ()
+	
+	writepointer = liftIO $ writePointerFile file key Nothing
diff --git a/Command/Fsck.hs b/Command/Fsck.hs
new file mode 100644
index 0000000000..3e3de1ea86
--- /dev/null
+++ b/Command/Fsck.hs
@@ -0,0 +1,756 @@
+{- git-annex command
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Fsck where
+
+import Command
+import qualified Annex
+import qualified Remote
+import qualified Types.Backend
+import qualified Backend
+import Annex.Content
+import Annex.Verify
+#ifndef mingw32_HOST_OS
+import Annex.Version
+import Annex.Content.Presence
+#endif
+import Annex.Content.Presence.LowLevel
+import Annex.Perms
+import Annex.Link
+import Logs.Location
+import Logs.Trust
+import Logs.Activity
+import Utility.TimeStamp
+import Logs.PreferredContent
+import Annex.NumCopies
+import Annex.UUID
+import Annex.ReplaceFile
+import Utility.DataUnits
+import Utility.HumanTime
+import Utility.CopyFile
+import Git.FilePath
+import Utility.PID
+import Utility.InodeCache
+import Annex.InodeSentinal
+import qualified Database.Keys
+import qualified Database.Fsck as FsckDb
+import Types.CleanupActions
+import Types.Key
+import qualified Utility.RawFilePath as R
+
+import Data.Time.Clock.POSIX
+import System.Posix.Types (EpochTime)
+import qualified Data.Set as S
+import qualified Data.Map as M
+import Data.Either
+import qualified System.FilePath.ByteString as P
+import System.PosixCompat.Files (fileMode, isSymbolicLink, modificationTime)
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, jsonOptions, annexedMatchingOptions] $
+	command "fsck" SectionMaintenance
+		"find and fix problems"
+		paramPaths (seek <$$> optParser)
+
+data FsckOptions = FsckOptions
+	{ fsckFiles :: CmdParams
+	, fsckFromOption :: Maybe (DeferredParse Remote)
+	, incrementalOpt :: Maybe IncrementalOpt
+	, keyOptions :: Maybe KeyOptions
+	}
+
+data IncrementalOpt
+	= StartIncrementalO
+	| MoreIncrementalO
+	| ScheduleIncrementalO Duration
+
+optParser :: CmdParamsDesc -> Parser FsckOptions
+optParser desc = FsckOptions
+	<$> cmdParams desc
+	<*> optional (mkParseRemoteOption <$> strOption 
+		( long "from" <> short 'f' <> metavar paramRemote 
+		<> help "check remote"
+		<> completeRemotes
+		))
+	<*> optional parseincremental
+	<*> optional parseKeyOptions
+  where
+	parseincremental =
+		flag' StartIncrementalO
+			( long "incremental" <> short 'S'
+			<> help "start an incremental fsck"
+			)
+		<|> flag' MoreIncrementalO
+			( long "more" <> short 'm'
+			<> help "continue an incremental fsck"
+			)
+		<|> (ScheduleIncrementalO <$> option (eitherReader parseDuration)
+			( long "incremental-schedule" <> metavar paramTime
+			<> help "schedule incremental fscking"
+			))
+
+seek :: FsckOptions -> CommandSeek
+seek o = startConcurrency commandStages $ do
+	from <- maybe (pure Nothing) (Just <$$> getParsed) (fsckFromOption o)
+	u <- maybe getUUID (pure . Remote.uuid) from
+	checkDeadRepo u
+	i <- prepIncremental u (incrementalOpt o)
+	let seeker = AnnexedFileSeeker
+		{ startAction = const $ start from i
+		, checkContentPresent = Nothing
+		, usesLocationLog = True
+		}
+	withKeyOptions (keyOptions o) False seeker
+		(\kai -> commandAction . startKey from i kai =<< getNumCopies)
+		(withFilesInGitAnnex ww seeker)
+		=<< workTreeItems ww (fsckFiles o)
+	cleanupIncremental i
+	void $ tryIO $ recordActivity Fsck u
+  where
+	ww = WarnUnmatchLsFiles "fsck"
+
+checkDeadRepo :: UUID -> Annex ()
+checkDeadRepo u =
+	whenM ((==) DeadTrusted <$> lookupTrust u) $
+		earlyWarning "Warning: Fscking a repository that is currently marked as dead."
+
+start :: Maybe Remote -> Incremental -> SeekInput -> RawFilePath -> Key -> CommandStart
+start from inc si file key = Backend.getBackend (fromRawFilePath file) key >>= \case
+	Nothing -> stop
+	Just backend -> do
+		(numcopies, _mincopies) <- getFileNumMinCopies file
+		case from of
+			Nothing -> go $ perform key file backend numcopies
+			Just r -> go $ performRemote key afile numcopies r
+  where
+	go = runFsck inc si (mkActionItem (key, afile)) key
+	afile = AssociatedFile (Just file)
+
+perform :: Key -> RawFilePath -> Backend -> NumCopies -> Annex Bool
+perform key file backend numcopies = do
+	keystatus <- getKeyFileStatus key file
+	check
+		-- order matters
+		[ fixLink key file
+		, fixObjectLocation key
+		, verifyLocationLog key keystatus ai
+		, verifyRequiredContent key ai
+		, verifyAssociatedFiles key keystatus file
+		, verifyWorkTree key file
+		, checkKeySize key keystatus ai
+		, checkBackend key keystatus afile
+		, checkKeyUpgrade backend key ai afile
+		, checkKeyNumCopies key afile numcopies
+		]
+  where
+	afile = AssociatedFile (Just file)
+	ai = mkActionItem (key, afile)
+
+{- To fsck a remote, the content is retrieved to a tmp file,
+ - and checked locally. -}
+performRemote :: Key -> AssociatedFile -> NumCopies -> Remote -> Annex Bool
+performRemote key afile numcopies remote =
+	dispatch =<< Remote.hasKey remote key
+  where
+	dispatch (Left err) = do
+		showNote (UnquotedString err)
+		return False
+	dispatch (Right True) = withtmp $ \tmpfile ->
+		getfile tmpfile >>= \case
+			Nothing -> go True Nothing
+			Just (Right verification) -> go True (Just (tmpfile, verification))
+			Just (Left _) -> do
+				warning $ actionItemDesc ai
+					<> ": failed to download file from remote"
+				void $ go True Nothing
+				return False
+	dispatch (Right False) = go False Nothing
+	go present lv = check
+		[ verifyLocationLogRemote key ai remote present
+		, verifyRequiredContent key ai
+		, withLocalCopy (fmap fst lv) $ checkKeySizeRemote key remote ai
+		, case fmap snd lv of
+			Just Verified -> return True
+			_ -> withLocalCopy (fmap fst lv) $
+				checkBackendRemote key remote ai
+		, checkKeyNumCopies key afile numcopies
+		]
+	ai = mkActionItem (key, afile)
+	withtmp a = do
+		-- Put it in the gitAnnexTmpObjectDir since that's on a
+		-- filesystem where object temp files are normally
+		-- stored. The pid prevents multiple fsck processes
+		-- contending over the same file. (Multiple threads cannot,
+		-- because OnlyActionOn is used.)
+		pid <- liftIO getPID
+		t <- fromRepo gitAnnexTmpObjectDir
+		createAnnexDirectory t
+		let tmp = t P.</> "fsck" <> toRawFilePath (show pid) <> "." <> keyFile key
+		let cleanup = liftIO $ catchIO (R.removeLink tmp) (const noop)
+		cleanup
+		cleanup `after` a tmp
+	getfile tmp = ifM (checkDiskSpace Nothing (Just (P.takeDirectory tmp)) key 0 True)
+		( ifM (getcheap tmp)
+			( return (Just (Right UnVerified))
+			, ifM (Annex.getRead Annex.fast)
+				( return Nothing
+				, Just <$> tryNonAsync (getfile' tmp)
+				)
+			)
+		, return Nothing
+		)
+	getfile' tmp = Remote.retrieveKeyFile remote key (AssociatedFile Nothing) (fromRawFilePath tmp) dummymeter (RemoteVerify remote)
+	dummymeter _ = noop
+	getcheap tmp = case Remote.retrieveKeyFileCheap remote of
+		Just a -> isRight <$> tryNonAsync (a key afile (fromRawFilePath tmp))
+		Nothing -> return False
+
+startKey :: Maybe Remote -> Incremental -> (SeekInput, Key, ActionItem) -> NumCopies -> CommandStart
+startKey from inc (si, key, ai) numcopies =
+	Backend.maybeLookupBackendVariety (fromKey keyVariety key) >>= \case
+		Nothing -> stop
+		Just _ -> runFsck inc si ai key $
+			case from of
+				Nothing -> performKey key numcopies
+				Just r -> performRemote key (AssociatedFile Nothing) numcopies r
+
+performKey :: Key -> NumCopies -> Annex Bool
+performKey key numcopies = do
+	keystatus <- getKeyStatus key
+	check
+		[ verifyLocationLog key keystatus (mkActionItem key)
+		, checkKeySize key keystatus (mkActionItem key)
+		, checkBackend key keystatus (AssociatedFile Nothing)
+		, checkKeyNumCopies key (AssociatedFile Nothing) numcopies
+		]
+
+check :: [Annex Bool] -> Annex Bool
+check cs = and <$> sequence cs
+
+{- Checks that symlinks points correctly to the annexed content. -}
+fixLink :: Key -> RawFilePath -> Annex Bool
+fixLink key file = do
+	want <- calcRepo $ gitAnnexLink file key
+	have <- getAnnexLinkTarget file
+	maybe noop (go want) have
+	return True
+  where
+	go want have
+		| want /= fromInternalGitPath have = do
+			showNote "fixing link"
+			createWorkTreeDirectory (parentDir file)
+			liftIO $ R.removeLink file
+			addAnnexLink want file
+		| otherwise = noop
+
+{- A repository that supports symlinks and is not bare may have in the past
+ - been bare, or not supported symlinks. If so, the object may be located
+ - in a directory other than the one where annex symlinks point to. Moves
+ - the object in that case.
+ -
+ - Also if a repository has been converted to bare, or moved to a crippled
+ - filesystem not supporting symlinks, the object file will be moved
+ - to the other location.
+ -}
+fixObjectLocation :: Key -> Annex Bool
+#ifdef mingw32_HOST_OS
+fixObjectLocation _key = do
+	-- Windows does not allow locked files to be renamed, but annex
+	-- links are also not used on Windows.
+	return True
+#else
+fixObjectLocation key = do
+	loc <- calcRepo (gitAnnexLocation key)
+	idealloc <- calcRepo (gitAnnexLocation' (const (pure True)) key)
+	if loc == idealloc
+		then return True
+		else ifM (liftIO $ R.doesPathExist loc)
+			( moveobjdir loc idealloc
+				`catchNonAsync` \_e -> return True
+			, return True
+			)
+  where
+	moveobjdir src dest = do
+		let srcdir = parentDir src
+		let destdir = parentDir dest
+		showNote "normalizing object location"
+		-- When the content file is moved, it will
+		-- appear to other processes as if it has been removed.
+		-- That should never happen to a process that has used
+		-- lockContentShared, so avoid it by locking the content
+		-- for removal, although it's not really being removed.
+		lockContentForRemoval key (return True) $ \_lck -> do
+			-- Thaw the content directory to allow renaming it.
+			thawContentDir src
+			createAnnexDirectory (parentDir destdir)
+			liftIO $ renameDirectory
+				(fromRawFilePath srcdir)
+				(fromRawFilePath destdir)
+			-- Since the directory was moved, lockContentForRemoval
+			-- will not be able to remove the lock file it
+			-- made. So, remove the lock file here.
+			mlockfile <- contentLockFile key =<< getVersion
+			liftIO $ maybe noop (removeWhenExistsWith R.removeLink) mlockfile
+			freezeContentDir dest
+			cleanObjectDirs src
+			return True
+#endif
+
+{- Checks that the location log reflects the current status of the key,
+ - in this repository only. -}
+verifyLocationLog :: Key -> KeyStatus -> ActionItem -> Annex Bool
+verifyLocationLog key keystatus ai = do
+	obj <- calcRepo (gitAnnexLocation key)
+	present <- if isKeyUnlockedThin keystatus
+		then liftIO (doesFileExist (fromRawFilePath obj))
+		else inAnnex key
+	u <- getUUID
+	
+	{- Since we're checking that a key's object file is present, throw
+	 - in a permission fixup here too. -}
+	when present $ do
+		void $ tryIO $ case keystatus of
+			KeyUnlockedThin -> thawContent obj
+			KeyLockedThin -> thawContent obj
+			_ -> freezeContent obj
+		checkContentWritePerm obj >>= \case
+			Nothing -> warning $ "** Unable to set correct write mode for " <> QuotedPath obj <> " ; perhaps you don't own that file, or perhaps it has an xattr or ACL set"
+			_ -> return ()
+	whenM (liftIO $ R.doesPathExist $ parentDir obj) $
+		freezeContentDir obj
+
+	{- Warn when annex.securehashesonly is set and content using an 
+	 - insecure hash is present. This should only be able to happen
+	 - if the repository already contained the content before the
+	 - config was set, or of course if a hash was broken. -}
+	whenM (pure present <&&> (not <$> Backend.isCryptographicallySecureKey key)) $
+		whenM (annexSecureHashesOnly <$> Annex.getGitConfig) $
+			warning $ "** Despite annex.securehashesonly being set, " <> QuotedPath obj <> " has content present in the annex using an insecure " <> UnquotedString (decodeBS (formatKeyVariety (fromKey keyVariety key))) <> " key"
+
+	verifyLocationLog' key ai present u (logChange key u)
+
+verifyLocationLogRemote :: Key -> ActionItem -> Remote -> Bool -> Annex Bool
+verifyLocationLogRemote key ai remote present =
+	verifyLocationLog' key ai present (Remote.uuid remote)
+		(Remote.logStatus remote key)
+
+verifyLocationLog' :: Key -> ActionItem -> Bool -> UUID -> (LogStatus -> Annex ()) -> Annex Bool
+verifyLocationLog' key ai present u updatestatus = do
+	uuids <- loggedLocations key
+	case (present, u `elem` uuids) of
+		(True, False) -> do
+			fix InfoPresent
+			-- There is no data loss, so do not fail.
+			return True
+		(False, True) -> do
+			fix InfoMissing
+			warning $
+				"** Based on the location log, " <>
+				actionItemDesc ai <>
+				"\n** was expected to be present, " <>
+				"but its content is missing."
+			return False
+		(False, False) -> do
+			-- When the location log for the key is not present,
+			-- create it, so that the key will be known.
+			when (null uuids) $
+				whenM (not <$> isKnownKey key) $
+					updatestatus InfoMissing
+			return True
+		(True, True) -> return True
+  where
+	fix s = do
+		showNote "fixing location log"
+		updatestatus s
+
+{- Verifies that all repos that are required to contain the content do,
+ - checking against the location log. -}
+verifyRequiredContent :: Key -> ActionItem -> Annex Bool
+verifyRequiredContent key ai@(ActionItemAssociatedFile afile _) = case afile of
+	-- Can't be checked if there's no associated file.
+	AssociatedFile Nothing -> return True
+	AssociatedFile (Just _) -> do
+		requiredlocs <- S.fromList . M.keys <$> requiredContentMap
+		if S.null requiredlocs
+			then return True
+			else go requiredlocs
+  where
+	go requiredlocs = do
+		presentlocs <- S.fromList <$> loggedLocations key
+		missinglocs <- filterM
+			(\u -> isRequiredContent (Just u) S.empty (Just key) afile False)
+			(S.toList $ S.difference requiredlocs presentlocs)
+		if null missinglocs
+			then return True
+			else do
+				missingrequired <- Remote.prettyPrintUUIDs "missingrequired" missinglocs
+				warning $
+					"** Required content " <>
+					actionItemDesc ai <>
+					" is missing from these repositories:\n" <>
+					UnquotedString missingrequired
+				return False
+verifyRequiredContent _ _ = return True
+
+{- Verifies the associated file records. -}
+verifyAssociatedFiles :: Key -> KeyStatus -> RawFilePath -> Annex Bool
+verifyAssociatedFiles key keystatus file = do
+	when (isKeyUnlockedThin keystatus) $ do
+		f <- inRepo $ toTopFilePath file
+		afs <- Database.Keys.getAssociatedFiles key
+		unless (getTopFilePath f `elem` map getTopFilePath afs) $
+			Database.Keys.addAssociatedFile key f
+	return True
+
+verifyWorkTree :: Key -> RawFilePath -> Annex Bool
+verifyWorkTree key file = do
+	{- Make sure that a pointer file is replaced with its content,
+	 - when the content is available. -}
+	mk <- liftIO $ isPointerFile file
+	case mk of
+		Just k | k == key -> whenM (inAnnex key) $ do
+			showNote "fixing worktree content"
+			replaceWorkTreeFile (fromRawFilePath file) $ \tmp -> do
+				mode <- liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus file
+				ifM (annexThin <$> Annex.getGitConfig)
+					( void $ linkFromAnnex' key tmp mode
+					, do
+						obj <- calcRepo (gitAnnexLocation key)
+						void $ checkedCopyFile key obj tmp mode
+						thawContent tmp
+					)
+				Database.Keys.storeInodeCaches key [tmp]
+		_ -> return ()
+	return True
+
+{- The size of the data for a key is checked against the size encoded in
+ - the key's metadata, if available.
+ -
+ - Not checked when a file is unlocked.
+ -}
+checkKeySize :: Key -> KeyStatus -> ActionItem -> Annex Bool
+checkKeySize _ KeyUnlockedThin _ = return True
+checkKeySize key _ ai = do
+	file <- calcRepo $ gitAnnexLocation key
+	ifM (liftIO $ R.doesPathExist file)
+		( checkKeySizeOr badContent key file ai
+		, return True
+		)
+
+withLocalCopy :: Maybe RawFilePath -> (RawFilePath -> Annex Bool) -> Annex Bool
+withLocalCopy Nothing _ = return True
+withLocalCopy (Just localcopy) f = f localcopy
+
+checkKeySizeRemote :: Key -> Remote -> ActionItem -> RawFilePath -> Annex Bool
+checkKeySizeRemote key remote ai localcopy =
+	checkKeySizeOr (badContentRemote remote localcopy) key localcopy ai
+
+checkKeySizeOr :: (Key -> Annex String) -> Key -> RawFilePath -> ActionItem -> Annex Bool
+checkKeySizeOr bad key file ai = case fromKey keySize key of
+	Nothing -> return True
+	Just size -> do
+		size' <- liftIO $ getFileSize file
+		comparesizes size size'
+  where
+	comparesizes a b = do
+		let same = a == b
+		unless same $ badsize a b
+		return same
+	badsize a b = do
+		msg <- bad key
+		warning $ actionItemDesc ai
+			<> ": Bad file size ("
+			<> UnquotedString (compareSizes storageUnits True a b)
+			<> "); "
+			<> UnquotedString msg
+
+{- Check for keys that are upgradable.
+ -
+ - Warns and suggests the user migrate, but does not migrate itself,
+ - because migration can cause more disk space to be used, and makes
+ - worktree changes that need to be committed.
+ -}
+checkKeyUpgrade :: Backend -> Key -> ActionItem -> AssociatedFile -> Annex Bool
+checkKeyUpgrade backend key ai (AssociatedFile (Just file)) =
+	case Types.Backend.canUpgradeKey backend of
+		Just a | a key -> do
+			warning $ actionItemDesc ai
+				<> ": Can be upgraded to an improved key format. "
+				<> "You can do so by running: git annex migrate --backend="
+				<> UnquotedByteString (formatKeyVariety (fromKey keyVariety key))
+				<> " "
+				<> QuotedPath file
+			return True
+		_ -> return True
+checkKeyUpgrade _ _ _ (AssociatedFile Nothing) =
+	-- Don't suggest migrating without a filename, because
+	-- while possible to do, there is no actual benefit from
+	-- doing that in this situation.
+	return True
+
+{- Runs the backend specific check on a key's content object.
+ -
+ - When a annex.thin is set, an unlocked file may be a hard link to the object.
+ - Thus when the user modifies the file, the object will be modified and
+ - not pass the check, and we don't want to find an error in this case.
+ -}
+checkBackend :: Key -> KeyStatus -> AssociatedFile -> Annex Bool
+checkBackend key keystatus afile = do
+	content <- calcRepo (gitAnnexLocation key)
+	ifM (pure (isKeyUnlockedThin keystatus) <&&> (not <$> isUnmodified key content))
+		( nocheck
+		, do
+			mic <- withTSDelta (liftIO . genInodeCache content)
+			ifM (checkBackendOr badContent key content ai)
+				( do
+					checkInodeCache key content mic ai
+					return True
+				, return False
+				)
+		)
+  where
+	nocheck = return True
+
+	ai = mkActionItem (key, afile)
+
+checkBackendRemote :: Key -> Remote -> ActionItem -> RawFilePath -> Annex Bool
+checkBackendRemote key remote ai localcopy =
+	checkBackendOr (badContentRemote remote localcopy) key localcopy ai
+
+checkBackendOr :: (Key -> Annex String) -> Key -> RawFilePath -> ActionItem -> Annex Bool
+checkBackendOr bad key file ai = do
+	ok <- verifyKeyContent' key file
+	unless ok $ do
+		msg <- bad key
+		warning $ actionItemDesc ai
+			<> ": Bad file content; "
+			<> UnquotedString msg
+	return ok
+
+{- Check, if there are InodeCaches recorded for a key, that one of them
+ - matches the object file. There are situations where the InodeCache
+ - of the object file does not get recorded, including a v8 upgrade.
+ - There may also be situations where the wrong InodeCache is recorded,
+ - if inodes are not stable.
+ -
+ - This must be called after the content of the object file has been
+ - verified to be correct. The InodeCache is generated again to detect if
+ - the object file was changed while the content was being verified.
+ -}
+checkInodeCache :: Key -> RawFilePath -> Maybe InodeCache -> ActionItem -> Annex ()
+checkInodeCache key content mic ai = case mic of
+	Nothing -> noop
+	Just ic -> do
+		ics <- Database.Keys.getInodeCaches key
+		unless (null ics) $
+			unlessM (isUnmodifiedCheapLowLevel ic ics) $ do
+				withTSDelta (liftIO . genInodeCache content) >>= \case
+					Nothing -> noop
+					Just ic' -> whenM (compareInodeCaches ic ic') $ do
+						warning $ actionItemDesc ai
+							<> ": Stale or missing inode cache; updating."
+						Database.Keys.addInodeCaches key [ic]
+
+checkKeyNumCopies :: Key -> AssociatedFile -> NumCopies -> Annex Bool
+checkKeyNumCopies key afile numcopies = do
+	let (desc, hasafile) = case afile of
+		AssociatedFile Nothing -> (serializeKey' key, False)
+		AssociatedFile (Just af) -> (af, True)
+	locs <- loggedLocations key
+	(untrustedlocations, otherlocations) <- trustPartition UnTrusted locs
+	(deadlocations, safelocations) <- trustPartition DeadTrusted otherlocations
+	let present = length safelocations
+	if present < fromNumCopies numcopies
+		then ifM (checkDead key)
+			( do
+				showLongNote $ "This key is dead, skipping."
+				return True
+			, do
+				untrusted <- Remote.prettyPrintUUIDs "untrusted" untrustedlocations
+				dead <- Remote.prettyPrintUUIDs "dead" deadlocations
+				warning $ missingNote desc present numcopies untrusted dead
+				when (present == 0 && not hasafile) $
+					showLongNote "(Avoid this check by running: git annex dead --key )"
+				return False
+			)
+		else return True
+
+missingNote :: RawFilePath -> Int -> NumCopies -> String -> String -> StringContainingQuotedPath
+missingNote file 0 _ [] dead = 
+		"** No known copies exist of " <> QuotedPath file <> UnquotedString (honorDead dead)
+missingNote file 0 _ untrusted dead =
+		"Only these untrusted locations may have copies of " <> QuotedPath file <>
+		"\n" <> UnquotedString untrusted <>
+		"Back it up to trusted locations with git-annex copy." <> UnquotedString (honorDead dead)
+missingNote file present needed [] _ =
+		"Only " <> UnquotedString (show present) <> " of " <> UnquotedString (show (fromNumCopies needed)) <>
+		" trustworthy copies exist of " <> QuotedPath file <>
+		"\nBack it up with git-annex copy."
+missingNote file present needed untrusted dead = 
+		missingNote file present needed [] dead <>
+		"\nThe following untrusted locations may also have copies: " <>
+		"\n" <> UnquotedString untrusted
+	
+honorDead :: String -> String
+honorDead dead
+	| null dead = ""
+	| otherwise = "\nThese dead repositories used to have copies\n" ++ dead
+
+{- Bad content is moved aside. -}
+badContent :: Key -> Annex String
+badContent key = do
+	dest <- moveBad key
+	return $ "moved to " ++ fromRawFilePath dest
+
+{- Bad content is dropped from the remote. We have downloaded a copy
+ - from the remote to a temp file already (in some cases, it's just a
+ - symlink to a file in the remote). To avoid any further data loss,
+ - that temp file is moved to the bad content directory unless 
+ - the local annex has a copy of the content. -}
+badContentRemote :: Remote -> RawFilePath -> Key -> Annex String
+badContentRemote remote localcopy key = do
+	bad <- fromRepo gitAnnexBadDir
+	let destbad = bad P.</> keyFile key
+	let destbad' = fromRawFilePath destbad
+	movedbad <- ifM (inAnnex key <||> liftIO (doesFileExist destbad'))
+		( return False
+		, do
+			createAnnexDirectory (parentDir destbad)
+			liftIO $ catchDefaultIO False $
+				ifM (isSymbolicLink <$> R.getSymbolicLinkStatus localcopy)
+					( copyFileExternal CopyTimeStamps (fromRawFilePath localcopy) destbad'
+					, do
+						moveFile localcopy destbad
+						return True
+					)
+		)
+
+	dropped <- tryNonAsync (Remote.removeKey remote key)
+	when (isRight dropped) $
+		Remote.logStatus remote key InfoMissing
+	return $ case (movedbad, dropped) of
+		(True, Right ()) -> "moved from " ++ Remote.name remote ++
+			" to " ++ fromRawFilePath destbad
+		(False, Right ()) -> "dropped from " ++ Remote.name remote
+		(_, Left e) -> "failed to drop from" ++ Remote.name remote ++ ": " ++ show e
+
+runFsck :: Incremental -> SeekInput -> ActionItem -> Key -> Annex Bool -> CommandStart
+runFsck inc si ai key a = stopUnless (needFsck inc key) $
+	starting "fsck" (OnlyActionOn key ai) si $ do
+		ok <- a
+		when ok $
+			recordFsckTime inc key
+		next $ return ok
+
+{- Check if a key needs to be fscked, with support for incremental fscks. -}
+needFsck :: Incremental -> Key -> Annex Bool
+needFsck (ScheduleIncremental _ _ i) k = needFsck i k
+needFsck (ContIncremental h) key = liftIO $ not <$> FsckDb.inDb h key
+needFsck _ _ = return True
+
+recordFsckTime :: Incremental -> Key -> Annex ()
+recordFsckTime inc key = withFsckDb inc $ \h -> liftIO $ FsckDb.addDb h key
+
+{- Records the start time of an incremental fsck.
+ -
+ - To guard against time stamp damage (for example, if an annex directory
+ - is copied without -a), the fsckstate file contains a time that should
+ - be identical to its modification time.
+ - (This is not possible to do on Windows, and so the timestamp in
+ - the file will only be equal or greater than the modification time.)
+ -}
+recordStartTime :: UUID -> Annex ()
+recordStartTime u = do
+	f <- fromRepo (gitAnnexFsckState u)
+	createAnnexDirectory $ parentDir f
+	liftIO $ removeWhenExistsWith R.removeLink f
+	liftIO $ withFile (fromRawFilePath f) WriteMode $ \h -> do
+#ifndef mingw32_HOST_OS
+		t <- modificationTime <$> R.getFileStatus f
+#else
+		t <- getPOSIXTime
+#endif
+		hPutStr h $ showTime $ realToFrac t
+	setAnnexFilePerm f
+  where
+	showTime :: POSIXTime -> String
+	showTime = show
+
+resetStartTime :: UUID -> Annex ()
+resetStartTime u = liftIO . removeWhenExistsWith R.removeLink
+	=<< fromRepo (gitAnnexFsckState u)
+
+{- Gets the incremental fsck start time. -}
+getStartTime :: UUID -> Annex (Maybe EpochTime)
+getStartTime u = do
+	f <- fromRepo (gitAnnexFsckState u)
+	liftIO $ catchDefaultIO Nothing $ do
+		timestamp <- modificationTime <$> R.getFileStatus f
+		let fromstatus = Just (realToFrac timestamp)
+		fromfile <- parsePOSIXTime <$> readFile (fromRawFilePath f)
+		return $ if matchingtimestamp fromfile fromstatus
+			then Just timestamp
+			else Nothing
+  where
+	matchingtimestamp fromfile fromstatus =
+#ifndef mingw32_HOST_OS
+		fromfile == fromstatus
+#else
+		fromfile >= fromstatus
+#endif
+
+data Incremental
+	= NonIncremental
+	| ScheduleIncremental Duration UUID Incremental
+	| StartIncremental FsckDb.FsckHandle 
+	| ContIncremental FsckDb.FsckHandle
+
+prepIncremental :: UUID -> Maybe IncrementalOpt -> Annex Incremental
+prepIncremental _ Nothing = pure NonIncremental
+prepIncremental u (Just StartIncrementalO) = do
+	recordStartTime u
+	ifM (FsckDb.newPass u)
+		( StartIncremental <$> openFsckDb u
+		, giveup "Cannot start a new --incremental fsck pass; another fsck process is already running."
+		)
+prepIncremental u (Just MoreIncrementalO) =
+	ContIncremental <$> openFsckDb u
+prepIncremental u (Just (ScheduleIncrementalO delta)) = do
+	started <- getStartTime u
+	i <- prepIncremental u $ Just $ case started of
+		Nothing -> StartIncrementalO
+		Just _ -> MoreIncrementalO
+	return (ScheduleIncremental delta u i)
+
+cleanupIncremental :: Incremental -> Annex ()
+cleanupIncremental (ScheduleIncremental delta u i) = do
+	v <- getStartTime u
+	case v of
+		Nothing -> noop
+		Just started -> do
+			now <- liftIO getPOSIXTime
+			when (now - realToFrac started >= durationToPOSIXTime delta) $
+				resetStartTime u
+	cleanupIncremental i
+cleanupIncremental _ = return ()
+
+openFsckDb :: UUID -> Annex FsckDb.FsckHandle
+openFsckDb u = do
+	h <- FsckDb.openDb u
+	Annex.addCleanupAction FsckCleanup $
+		FsckDb.closeDb h
+	return h
+
+withFsckDb :: Incremental -> (FsckDb.FsckHandle -> Annex ()) -> Annex ()
+withFsckDb (ContIncremental h) a = a h
+withFsckDb (StartIncremental h) a = a h
+withFsckDb NonIncremental _ = noop
+withFsckDb (ScheduleIncremental _ _ i) a = withFsckDb i a
+
diff --git a/Command/FuzzTest.hs b/Command/FuzzTest.hs
new file mode 100644
index 0000000000..642f07b51d
--- /dev/null
+++ b/Command/FuzzTest.hs
@@ -0,0 +1,277 @@
+{- git-annex fuzz generator
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.FuzzTest where
+
+import Command
+import qualified Annex
+import qualified Git.Config
+import Config
+import Annex.Perms
+import Utility.ThreadScheduler
+import Utility.DiskFree
+import Git.Types (fromConfigKey)
+import qualified Utility.RawFilePath as R
+
+import Data.Time.Clock
+import System.Random (getStdRandom, random, randomR)
+import Test.QuickCheck
+import Control.Concurrent
+
+cmd :: Command
+cmd = notBareRepo $
+	command "fuzztest" SectionTesting
+		"generates fuzz test files"
+		paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = do
+	guardTest
+	logf <- fromRepo gitAnnexFuzzTestLogFile
+	showStartMessage (StartMessage "fuzztest" (ActionItemOther (Just (UnquotedString logf))) (SeekInput []))
+	logh <- liftIO $ openFile logf WriteMode
+	void $ forever $ fuzz logh
+	stop
+
+guardTest :: Annex ()
+guardTest = unlessM (fromMaybe False . Git.Config.isTrueFalse' <$> getConfig key mempty) $
+	giveup $ unlines
+		[ "Running fuzz tests *writes* to and *deletes* files in"
+		, "this repository, and pushes those changes to other"
+		, "repositories! This is a developer tool, not something"
+		, "to play with."
+		, ""
+		, "Refusing to run fuzz tests, since " ++ fromConfigKey key ++ " is not set!"
+		]
+  where
+	key = annexConfig "eat-my-repository"
+
+fuzz :: Handle -> Annex ()
+fuzz logh = do
+	fuzzer <- genFuzzAction
+	record logh $ flip Started fuzzer
+	result <- tryNonAsync $ runFuzzAction fuzzer
+	record logh $ flip Finished $
+		either (const False) (const True) result
+
+record :: Handle -> (UTCTime -> TimeStampedFuzzAction) -> Annex ()
+record h tmpl = liftIO $ do
+	now <- getCurrentTime
+	let s = show $ tmpl now
+	print s
+	hPrint h s
+	hFlush h
+
+{- Delay for either a fraction of a second, or a few seconds, or up
+ - to 1 minute.
+ -
+ - The MinutesDelay is used as an opportunity to do housekeeping tasks.
+ -}
+randomDelay :: Delay -> Annex ()
+randomDelay TinyDelay = liftIO $
+	threadDelay =<< getStdRandom (randomR (10000, 1000000))
+randomDelay SecondsDelay = liftIO $ 
+	threadDelaySeconds =<< Seconds <$> getStdRandom (randomR (1, 10))
+randomDelay MinutesDelay = do
+	liftIO $ threadDelaySeconds =<< Seconds <$> getStdRandom (randomR (1, 60))
+	reserve <- annexDiskReserve <$> Annex.getGitConfig
+	free <- liftIO $ getDiskFree "."
+	case free of
+		Just have | have < reserve -> do
+			warning "Low disk space; fuzz test paused."
+			liftIO $ threadDelaySeconds (Seconds 60)
+			randomDelay MinutesDelay
+		_  -> noop
+
+data Delay
+	= TinyDelay
+	| SecondsDelay
+	| MinutesDelay
+	deriving (Read, Show, Eq)
+
+instance Arbitrary Delay where
+	arbitrary = elements [TinyDelay, SecondsDelay, MinutesDelay]
+
+data FuzzFile = FuzzFile FilePath
+	deriving (Read, Show, Eq)
+
+data FuzzDir = FuzzDir FilePath
+	deriving (Read, Show, Eq)
+
+instance Arbitrary FuzzFile where
+	arbitrary = FuzzFile <$> arbitrary
+
+instance Arbitrary FuzzDir where
+	arbitrary = FuzzDir <$> arbitrary
+
+class ToFilePath a where
+	toFilePath :: a -> FilePath
+
+instance ToFilePath FuzzFile where
+	toFilePath (FuzzFile f) = f
+
+instance ToFilePath FuzzDir where
+	toFilePath (FuzzDir d) = d
+
+isFuzzFile :: FilePath -> Bool
+isFuzzFile f = "fuzzfile_" `isPrefixOf` takeFileName f
+
+isFuzzDir :: FilePath -> Bool
+isFuzzDir d = "fuzzdir_" `isPrefixOf` d
+
+mkFuzzFile :: FilePath -> [FuzzDir] -> FuzzFile
+mkFuzzFile file dirs = FuzzFile $ joinPath (map toFilePath dirs) </> ("fuzzfile_" ++ file)
+
+mkFuzzDir :: Int -> FuzzDir
+mkFuzzDir n = FuzzDir $ "fuzzdir_" ++ show n
+
+{- File is placed inside a directory hierarchy up to 4 subdirectories deep. -}
+genFuzzFile :: IO FuzzFile
+genFuzzFile = do
+	n <- getStdRandom $ randomR (0, 4)
+	dirs <- replicateM n genFuzzDir
+	file <- show <$> (getStdRandom random :: IO Int)
+	return $ mkFuzzFile file dirs
+
+{- Only 16 distinct subdirectories are used. When nested 4 deep, this
+ - yields 69904 total directories max, which is below the default Linux
+ - inotify limit of 81920. The goal is not to run the assistant out of
+ - inotify descriptors. -}
+genFuzzDir :: IO FuzzDir
+genFuzzDir = mkFuzzDir <$> (getStdRandom (randomR (1,16)) :: IO Int)
+
+data TimeStampedFuzzAction 
+	= Started UTCTime FuzzAction
+	| Finished UTCTime Bool
+	deriving (Read, Show)
+
+data FuzzAction
+	= FuzzAdd FuzzFile
+	| FuzzDelete FuzzFile
+	| FuzzMove FuzzFile FuzzFile
+	| FuzzDeleteDir FuzzDir
+	| FuzzMoveDir FuzzDir FuzzDir
+	| FuzzPause Delay
+	deriving (Read, Show, Eq)
+
+instance Arbitrary FuzzAction where
+	arbitrary = frequency
+		[ (50, FuzzAdd <$> arbitrary)
+		, (50, FuzzDelete <$> arbitrary)
+		, (10, FuzzMove <$> arbitrary <*> arbitrary)
+		, (10, FuzzDeleteDir <$> arbitrary)
+		, (10, FuzzMoveDir <$> arbitrary <*> arbitrary)
+		, (10, FuzzPause <$> arbitrary)
+		]
+
+runFuzzAction :: FuzzAction -> Annex ()
+runFuzzAction (FuzzAdd (FuzzFile f)) = do
+	createWorkTreeDirectory (parentDir (toRawFilePath f))
+	n <- liftIO (getStdRandom random :: IO Int)
+	liftIO $ writeFile f $ show n ++ "\n"
+runFuzzAction (FuzzDelete (FuzzFile f)) = liftIO $
+	removeWhenExistsWith R.removeLink (toRawFilePath f)
+runFuzzAction (FuzzMove (FuzzFile src) (FuzzFile dest)) = liftIO $
+	R.rename (toRawFilePath src) (toRawFilePath dest)
+runFuzzAction (FuzzDeleteDir (FuzzDir d)) = liftIO $
+	removeDirectoryRecursive d
+runFuzzAction (FuzzMoveDir (FuzzDir src) (FuzzDir dest)) = liftIO $
+	R.rename (toRawFilePath src) (toRawFilePath dest)
+runFuzzAction (FuzzPause d) = randomDelay d
+
+genFuzzAction :: Annex FuzzAction
+genFuzzAction = do
+	tmpl <- liftIO $ Prelude.head <$> sample' (arbitrary :: Gen FuzzAction)
+	-- Fix up template action to make sense in the current repo tree.
+	case tmpl of
+		FuzzAdd _ -> do
+			f <- liftIO newFile
+			maybe genFuzzAction (return . FuzzAdd) f
+		FuzzDelete _ -> do
+			f <- liftIO $ existingFile 0 ""
+			maybe genFuzzAction (return . FuzzDelete) f
+		FuzzMove _ _ -> do
+			src <- liftIO $ existingFile 0 ""
+			dest <- liftIO newFile
+			case (src, dest) of
+				(Just s, Just d) -> return $ FuzzMove s d
+				_ -> genFuzzAction
+		FuzzMoveDir _ _ -> do
+			md <- liftIO existingDir
+			case md of
+				Nothing -> genFuzzAction
+				Just d -> do
+					newd <- liftIO $ newDir (parentDir $ toRawFilePath $ toFilePath d)
+					maybe genFuzzAction (return . FuzzMoveDir d) newd
+		FuzzDeleteDir _ -> do
+			d <- liftIO existingDir
+			maybe genFuzzAction (return . FuzzDeleteDir) d
+		FuzzPause _ -> return tmpl
+
+existingFile :: Int -> FilePath -> IO (Maybe FuzzFile)
+existingFile 0 _ = return Nothing
+existingFile n top = do
+	dir <- existingDirIncludingTop
+	contents <- catchDefaultIO [] (getDirectoryContents dir)
+	let files = filter isFuzzFile contents
+	if null files
+		then do
+			let dirs = filter isFuzzDir contents
+			if null dirs
+				then return Nothing
+				else do
+					i <- getStdRandom $ randomR (0, length dirs - 1)
+					existingFile (n - 1) (top </> dirs !! i)
+		else do
+			i <- getStdRandom $ randomR (0, length files - 1)
+			return $ Just $ FuzzFile $ top </> dir </> files !! i
+
+existingDirIncludingTop :: IO FilePath
+existingDirIncludingTop = do
+	dirs <- filter isFuzzDir <$> getDirectoryContents "."
+	if null dirs
+		then return "."
+		else do
+			n <- getStdRandom $ randomR (0, length dirs)
+			return $ ("." : dirs) !! n
+
+existingDir :: IO (Maybe FuzzDir)
+existingDir = do
+	d <- existingDirIncludingTop
+	return $ if isFuzzDir d
+		then Just $ FuzzDir d
+		else Nothing
+
+newFile :: IO (Maybe FuzzFile)
+newFile = go (100 :: Int)
+  where
+	go 0 = return Nothing
+	go n = do
+		f <- genFuzzFile
+		ifM (doesnotexist (toFilePath f))
+			( return $ Just f
+			, go (n - 1)
+			)
+
+newDir :: RawFilePath -> IO (Maybe FuzzDir)
+newDir parent = go (100 :: Int)
+  where
+	go 0 = return Nothing
+	go n = do
+		(FuzzDir d) <- genFuzzDir
+		ifM (doesnotexist (fromRawFilePath parent </> d))
+			( return $ Just $ FuzzDir d
+			, go (n - 1)
+			)
+
+doesnotexist :: FilePath -> IO Bool
+doesnotexist f = isNothing <$> catchMaybeIO (R.getSymbolicLinkStatus (toRawFilePath f))
diff --git a/Command/GCryptSetup.hs b/Command/GCryptSetup.hs
new file mode 100644
index 0000000000..ae17702cce
--- /dev/null
+++ b/Command/GCryptSetup.hs
@@ -0,0 +1,39 @@
+{- git-annex command
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.GCryptSetup where
+
+import Command
+import Annex.UUID
+import qualified Remote.GCrypt
+import qualified Git
+
+cmd :: Command
+cmd = dontCheck repoExists $ noCommit $
+	command "gcryptsetup" SectionPlumbing 
+		"sets up gcrypt repository"
+		paramValue (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withStrings (commandAction . start)
+
+start :: String -> CommandStart
+start gcryptid = starting "gcryptsetup" (ActionItemOther Nothing) (SeekInput [gcryptid]) $ do
+	u <- getUUID
+	when (u /= NoUUID) $
+		giveup "gcryptsetup refusing to run; this repository already has a git-annex uuid!"
+	
+	g <- gitRepo
+	gu <- Remote.GCrypt.getGCryptUUID True g
+	let newgu = genUUIDInNameSpace gCryptNameSpace (encodeBS gcryptid)
+	if isNothing gu || gu == Just newgu
+		then if Git.repoIsLocalBare g
+			then do
+				void $ Remote.GCrypt.setupRepo gcryptid g
+				next $ return True
+			else giveup "cannot use gcrypt in a non-bare repository"
+		else giveup "gcryptsetup uuid mismatch"
diff --git a/Command/Get.hs b/Command/Get.hs
new file mode 100644
index 0000000000..c8f76568ed
--- /dev/null
+++ b/Command/Get.hs
@@ -0,0 +1,122 @@
+{- git-annex command
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Get where
+
+import Command
+import qualified Remote
+import Annex.Transfer
+import Annex.NumCopies
+import Annex.Wanted
+import qualified Command.Move
+import Logs.Location
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, jsonOptions, jsonProgressOption, annexedMatchingOptions] $ 
+	command "get" SectionCommon 
+		"make content of annexed files available"
+		paramPaths (seek <$$> optParser)
+
+data GetOptions = GetOptions
+	{ getFiles :: CmdParams
+	, getFrom :: Maybe (DeferredParse Remote)
+	, autoMode :: Bool
+	, keyOptions :: Maybe KeyOptions
+	, batchOption :: BatchMode
+	}
+
+optParser :: CmdParamsDesc -> Parser GetOptions
+optParser desc = GetOptions
+	<$> cmdParams desc
+	<*> optional (mkParseRemoteOption <$> parseFromOption)
+	<*> parseAutoOption
+	<*> optional (parseIncompleteOption <|> parseKeyOptions <|> parseFailedTransfersOption)
+	<*> parseBatchOption True
+
+seek :: GetOptions -> CommandSeek
+seek o = startConcurrency transferStages $ do
+	from <- maybe (pure Nothing) (Just <$$> getParsed) (getFrom o)
+	let seeker = AnnexedFileSeeker
+		{ startAction = const $ start o from
+		, checkContentPresent = Just False
+		, usesLocationLog = True
+		}
+	case batchOption o of
+		NoBatch -> withKeyOptions (keyOptions o) (autoMode o) seeker
+			(commandAction . startKeys from)
+			(withFilesInGitAnnex ww seeker)
+			=<< workTreeItems ww (getFiles o)
+		Batch fmt -> batchOnly (keyOptions o) (getFiles o) $
+			batchAnnexed fmt seeker (startKeys from)
+  where
+	ww = WarnUnmatchLsFiles "get"
+
+start :: GetOptions -> Maybe Remote -> SeekInput -> RawFilePath -> Key -> CommandStart
+start o from si file key = start' expensivecheck from key afile ai si
+  where
+	afile = AssociatedFile (Just file)
+	ai = mkActionItem (key, afile)
+	expensivecheck
+		| autoMode o = numCopiesCheck file key (<)
+			<||> wantGet False (Just key) afile
+		| otherwise = return True
+
+startKeys :: Maybe Remote -> (SeekInput, Key, ActionItem) -> CommandStart
+startKeys from (si, key, ai) = checkFailedTransferDirection ai Download $
+	start' (return True) from key (AssociatedFile Nothing) ai si
+
+start' :: Annex Bool -> Maybe Remote -> Key -> AssociatedFile -> ActionItem -> SeekInput -> CommandStart
+start' expensivecheck from key afile ai si =
+	stopUnless expensivecheck $
+		case from of
+			Nothing -> go $ perform key afile
+			Just src ->
+				stopUnless (Command.Move.fromOk src key) $
+					go $ Command.Move.fromPerform src Command.Move.RemoveNever key afile
+  where
+	go = starting "get" (OnlyActionOn key ai) si
+
+perform :: Key -> AssociatedFile -> CommandPerform
+perform key afile = stopUnless (getKey key afile) $
+	next $ return True -- no cleanup needed
+
+{- Try to find a copy of the file in one of the remotes,
+ - and copy it to here. -}
+getKey :: Key -> AssociatedFile -> Annex Bool
+getKey key afile = getKey' key afile
+	=<< Remote.keyPossibilities (Remote.IncludeIgnored False) key
+
+getKey' :: Key -> AssociatedFile -> [Remote] -> Annex Bool
+getKey' key afile = dispatch
+  where
+	dispatch [] = do
+		showNote (UnquotedString "not available")
+		showlocs []
+		return False
+	dispatch remotes = notifyTransfer Download afile $ \witness -> do
+		ok <- pickRemote remotes $ \r -> ifM (probablyPresent r)
+			( docopy r witness
+			, return False
+			)
+		if ok
+			then return ok
+			else do
+				Remote.showTriedRemotes remotes
+				showlocs (map Remote.uuid remotes)
+				return False
+	showlocs exclude = Remote.showLocations False key exclude
+		"No other repository is known to contain the file."
+	-- This check is to avoid an ugly message if a remote is a
+	-- drive that is not mounted.
+	probablyPresent r
+		| Remote.hasKeyCheap r =
+			either (const False) id <$> Remote.hasKey r key
+		| otherwise = return True
+	docopy r witness = do
+		showAction $ UnquotedString $ "from " ++ Remote.name r
+		logStatusAfter key $
+			download r key afile stdRetry witness
diff --git a/Command/Group.hs b/Command/Group.hs
new file mode 100644
index 0000000000..41717961a5
--- /dev/null
+++ b/Command/Group.hs
@@ -0,0 +1,46 @@
+{- git-annex command
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Group where
+
+import Command
+import qualified Remote
+import Logs.Group
+import Types.Group
+import Utility.SafeOutput
+
+import qualified Data.Set as S
+
+cmd :: Command
+cmd = noMessages $ command "group" SectionSetup "add a repository to a group"
+	(paramPair paramRemote paramDesc) (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start ps@(name:g:[]) = do
+	u <- Remote.nameToUUID name
+	startingUsualMessages "group" ai si $
+		setGroup u (toGroup g)
+  where
+	ai = ActionItemOther (Just (UnquotedString name))
+	si = SeekInput ps
+start (name:[]) = do
+	u <- Remote.nameToUUID name
+	startingCustomOutput (ActionItemOther Nothing) $ do
+		liftIO . putStrLn . safeOutput . unwords . map fmt . S.toList
+			=<< lookupGroups u
+		next $ return True
+  where
+	fmt (Group g) = decodeBS g
+start _ = giveup "Specify a repository and a group."
+
+setGroup :: UUID -> Group -> CommandPerform
+setGroup uuid g = do
+	groupChange uuid (S.insert g) 
+	next $ return True
diff --git a/Command/GroupWanted.hs b/Command/GroupWanted.hs
new file mode 100644
index 0000000000..b080f5b073
--- /dev/null
+++ b/Command/GroupWanted.hs
@@ -0,0 +1,32 @@
+{- git-annex command
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.GroupWanted where
+
+import Command
+import Logs.PreferredContent
+import Command.Wanted (performGet, performSet)
+import Types.Group
+
+cmd :: Command
+cmd = noMessages $ command "groupwanted" SectionSetup 
+	"get or set groupwanted expression"
+	(paramPair paramGroup (paramOptional paramExpression))
+	(withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start (g:[]) = startingCustomOutput (ActionItemOther Nothing) $
+	performGet groupPreferredContentMapRaw (toGroup g)
+start ps@(g:expr:[]) = startingUsualMessages "groupwanted" ai si $
+	performSet groupPreferredContentSet expr (toGroup g)
+  where
+	ai = ActionItemOther (Just (UnquotedString g))
+	si = SeekInput ps
+start _ = giveup "Specify a group."
diff --git a/Command/Help.hs b/Command/Help.hs
new file mode 100644
index 0000000000..af61ccff0b
--- /dev/null
+++ b/Command/Help.hs
@@ -0,0 +1,71 @@
+{- git-annex command
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Help where
+
+import Command
+import qualified Command.Init
+import qualified Command.Add
+import qualified Command.Drop
+import qualified Command.Get
+import qualified Command.Move
+import qualified Command.Copy
+import qualified Command.Sync
+import qualified Command.Whereis
+import qualified Command.Fsck
+
+cmd :: Command
+cmd = noCommit $ dontCheck repoExists $
+	noRepo (parseparams startNoRepo) $ 
+		command "help" SectionCommon "display help"
+			"COMMAND" (parseparams seek)
+  where
+	parseparams = withParams
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start params = do
+	liftIO $ start' params
+	stop
+
+startNoRepo :: CmdParams -> IO ()
+startNoRepo = start'
+
+start' :: [String] -> IO ()
+start' [c] = showGitHelp c
+start' _ = showGeneralHelp
+
+showGeneralHelp :: IO ()
+showGeneralHelp = putStrLn $ unlines
+	[ "The most frequently used git-annex commands are:"
+	, unlines $ map cmdline $
+		[ Command.Init.cmd
+		, Command.Add.cmd
+		, Command.Drop.cmd
+		, Command.Get.cmd
+		, Command.Move.cmd
+		, Command.Copy.cmd
+		, Command.Sync.cmd
+		, Command.Whereis.cmd
+		, Command.Fsck.cmd
+		]
+	, "For a complete command list, run: git-annex"
+	, "For help on a specific command, run: git-annex help COMMAND"
+	]
+  where
+	cmdline c = "\t" ++ cmdname c ++ "\t" ++ cmddesc c
+
+showGitHelp :: String -> IO ()
+showGitHelp c = 
+	unlessM (githelp) $
+		putStrLn $ "View online help at " ++ url
+  where
+	githelp = boolSystem "git" [Param "help", Param fullc]
+	fullc = "git-annex-" ++ c
+	url = "https://git-annex.branchable.com/" ++ fullc ++ "/"
diff --git a/Command/Import.hs b/Command/Import.hs
new file mode 100644
index 0000000000..f5483cc7d5
--- /dev/null
+++ b/Command/Import.hs
@@ -0,0 +1,403 @@
+{- git-annex command
+ -
+ - Copyright 2012-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE ApplicativeDo, OverloadedStrings #-}
+
+module Command.Import where
+
+import Command
+import qualified Git
+import qualified Annex
+import qualified Command.Add
+import qualified Command.Reinject
+import qualified Types.Remote as Remote
+import qualified Git.Ref
+import Utility.CopyFile
+import Utility.OptParse
+import Backend
+import Types.KeySource
+import Annex.CheckIgnore
+import Annex.NumCopies
+import Annex.FileMatcher
+import Annex.Ingest
+import Annex.InodeSentinal
+import Annex.Import
+import Annex.Perms
+import Annex.RemoteTrackingBranch
+import Utility.InodeCache
+import Logs.Location
+import Git.FilePath
+import Git.Types
+import Types.Import
+import Utility.Metered
+import qualified Utility.RawFilePath as R
+
+import Control.Concurrent.STM
+import System.PosixCompat.Files (isDirectory, isSymbolicLink, isRegularFile)
+
+cmd :: Command
+cmd = notBareRepo $
+	withAnnexOptions opts $
+		command "import" SectionCommon 
+			"add a tree of files to the repository"
+			(paramPaths ++ "|BRANCH")
+			(seek <$$> optParser)
+  where
+	opts =
+		[ backendOption
+		, jobsOption
+		, jsonOptions
+		, jsonProgressOption
+		-- These options are only used when importing from a
+		-- directory, not from a special remote. So it's ok
+		-- to use LimitDiskFiles.
+		, fileMatchingOptions LimitDiskFiles
+		]
+
+data ImportOptions 
+	= LocalImportOptions
+		{ importFiles :: CmdParams
+		, duplicateMode :: DuplicateMode
+		, checkGitIgnoreOption :: CheckGitIgnore
+		}
+	| RemoteImportOptions
+		{ importFromRemote :: DeferredParse Remote
+		, importToBranch :: Branch
+		, importToSubDir :: Maybe FilePath
+		, importContent :: Bool
+		, checkGitIgnoreOption :: CheckGitIgnore
+		, messageOption :: [String]
+		}
+
+optParser :: CmdParamsDesc -> Parser ImportOptions
+optParser desc = do
+	ps <- cmdParams desc
+	mfromremote <- optional $ mkParseRemoteOption <$> parseFromOption
+	content <- invertableSwitch "content" True
+		( help "do not get contents of imported files"
+		)
+	dupmode <- fromMaybe Default <$> optional duplicateModeParser
+	ic <- Command.Add.checkGitIgnoreSwitch
+	message <- many (strOption
+		( long "message" <> short 'm' <> metavar "MSG"
+		<> help "commit message"
+		))
+	pure $ case mfromremote of
+		Nothing -> LocalImportOptions ps dupmode ic
+		Just r -> case ps of
+			[bs] -> 
+				let (branch, subdir) = separate (== ':') bs
+				in RemoteImportOptions r
+					(Ref (encodeBS branch))
+					(if null subdir then Nothing else Just subdir)
+					content
+					ic
+					message
+			_ -> giveup "expected BRANCH[:SUBDIR]"
+
+data DuplicateMode = Default | Duplicate | DeDuplicate | CleanDuplicates | SkipDuplicates | ReinjectDuplicates
+	deriving (Eq)
+
+duplicateModeParser :: Parser DuplicateMode
+duplicateModeParser = 
+	flag' Duplicate
+		( long "duplicate" 
+		<> help "do not delete source files"
+		)
+	<|> flag' DeDuplicate
+		( long "deduplicate"
+		<> help "delete source files whose content was imported before"
+		)
+	<|> flag' CleanDuplicates
+		( long "clean-duplicates"
+		<> help "delete duplicate source files (import nothing)"
+		)
+	<|> flag' SkipDuplicates
+		( long "skip-duplicates"
+		<> help "import only new files (do not delete source files)"
+		)
+	<|> flag' ReinjectDuplicates
+		( long "reinject-duplicates"
+		<> help "import new files, and reinject the content of files that were imported before"
+		)
+
+seek :: ImportOptions -> CommandSeek
+seek o@(LocalImportOptions {}) = startConcurrency commandStages $ do
+	repopath <- liftIO . absPath =<< fromRepo Git.repoPath
+	inrepops <- liftIO $ filter (dirContains repopath)
+		<$> mapM (absPath . toRawFilePath) (importFiles o)
+	unless (null inrepops) $ do
+		qp <- coreQuotePath <$> Annex.getGitConfig
+		giveup $ decodeBS $ quote qp $ 
+			"cannot import files from inside the working tree (use git annex add instead): "
+				<> quotedPaths inrepops
+	largematcher <- largeFilesMatcher
+	addunlockedmatcher <- addUnlockedMatcher
+	(commandAction . startLocal o addunlockedmatcher largematcher (duplicateMode o))
+		`withPathContents` importFiles o
+seek o@(RemoteImportOptions {}) = startConcurrency commandStages $ do
+	r <- getParsed (importFromRemote o)
+	unlessM (Remote.isImportSupported r) $
+		giveup "That remote does not support imports."
+	subdir <- maybe
+		(pure Nothing)
+		(Just <$$> inRepo . toTopFilePath . toRawFilePath)
+		(importToSubDir o)
+	seekRemote r (importToBranch o) subdir (importContent o) 
+		(checkGitIgnoreOption o)
+		(messageOption o)
+
+startLocal :: ImportOptions -> AddUnlockedMatcher -> GetFileMatcher -> DuplicateMode -> (RawFilePath, RawFilePath) -> CommandStart
+startLocal o addunlockedmatcher largematcher mode (srcfile, destfile) =
+	ifM (liftIO $ isRegularFile <$> R.getSymbolicLinkStatus srcfile)
+		( starting "import" ai si pickaction
+		, stop
+		)
+  where
+ 	ai = ActionItemTreeFile destfile
+	si = SeekInput []
+
+	deletedup k = do
+		showNote $ UnquotedString $ "duplicate of " ++ serializeKey k
+		verifyExisting k destfile
+			( do
+				liftIO $ R.removeLink srcfile
+				next $ return True
+			, do
+				warning "Could not verify that the content is still present in the annex; not removing from the import location."
+				stop
+			)
+	reinject k = do
+		showNote "reinjecting"
+		Command.Reinject.perform srcfile k
+	importfile ld k = checkdestdir $ do
+		ignored <- checkIgnored (checkGitIgnoreOption o) destfile
+		if ignored
+			then do
+				warning $ "not importing " <> QuotedPath destfile <> " which is .gitignored (use --no-check-gitignore to override)"
+				stop
+			else do
+				existing <- liftIO (catchMaybeIO $ R.getSymbolicLinkStatus destfile)
+				case existing of
+					Nothing -> importfilechecked ld k
+					Just s
+						| isDirectory s -> notoverwriting "(is a directory)"
+						| isSymbolicLink s -> ifM (Annex.getRead Annex.force)
+							( do
+								liftIO $ removeWhenExistsWith R.removeLink destfile
+								importfilechecked ld k
+							, notoverwriting "(is a symlink)"
+							)
+						| otherwise -> ifM (Annex.getRead Annex.force)
+							( do
+								liftIO $ removeWhenExistsWith R.removeLink destfile
+								importfilechecked ld k
+							, notoverwriting "(use --force to override, or a duplication option such as --deduplicate to clean up)"
+							)
+	checkdestdir cont = do
+		let destdir = parentDir destfile
+		existing <- liftIO (catchMaybeIO $ R.getSymbolicLinkStatus destdir)
+		case existing of
+			Nothing -> cont
+			Just s
+				| isDirectory s -> cont
+				| otherwise -> do
+					warning $ "not importing " <> QuotedPath destfile <> " because " <> QuotedPath destdir <> " is not a directory"
+					stop
+
+	importfilechecked ld k = do
+		-- Move or copy the src file to the dest file.
+		-- The dest file is what will be ingested.
+		createWorkTreeDirectory (parentDir destfile)
+		unwind <- liftIO $ if mode == Duplicate || mode == SkipDuplicates
+			then do
+				void $ copyFileExternal CopyAllMetaData 
+					(fromRawFilePath srcfile)
+					(fromRawFilePath destfile)
+				return $ removeWhenExistsWith R.removeLink destfile
+			else do
+				moveFile srcfile destfile
+				return $ moveFile destfile srcfile
+		-- Make sure that the dest file has its write permissions
+		-- removed; the src file normally already did, but may
+		-- have imported it from a filesystem that does not allow
+		-- removing write permissions, to a repo on a filesystem
+		-- that does.
+		when (lockingFile (lockDownConfig ld)) $ do
+			freezeContent destfile
+			checkLockedDownWritePerms destfile srcfile >>= \case
+				Just err -> do
+					liftIO unwind
+					qp <- coreQuotePath <$> Annex.getGitConfig
+					giveup (decodeBS $ quote qp err)
+				Nothing -> noop
+		-- Get the inode cache of the dest file. It should be
+		-- weakly the same as the originally locked down file's
+		-- inode cache. (Since the file may have been copied,
+		-- its inodes may not be the same.)
+		s <- liftIO $ R.getSymbolicLinkStatus destfile
+		newcache <- withTSDelta $ \d -> liftIO $ toInodeCache d destfile s
+		let unchanged = case (newcache, inodeCache (keySource ld)) of
+			(_, Nothing) -> True
+			(Just newc, Just c) | compareWeak c newc -> True
+			_ -> False
+		unless unchanged $
+			giveup "changed while it was being added"
+		-- The LockedDown needs to be adjusted, since the destfile
+		-- is what will be ingested.
+		let ld' = ld
+			{ keySource = KeySource
+				{ keyFilename = destfile
+				, contentLocation = destfile
+				, inodeCache = newcache
+				}
+			}
+		ifM (checkFileMatcher largematcher destfile)
+			( ingestAdd' nullMeterUpdate (Just ld') (Just k)
+				>>= maybe
+					stop
+					(\addedk -> next $ Command.Add.cleanup addedk True)
+			, Command.Add.addSmall (DryRun False) destfile s
+			)
+	notoverwriting why = do
+		warning $ "not overwriting existing " <> QuotedPath destfile <> " " <> UnquotedString why
+		stop
+	lockdown a = do
+		let mi = MatchingFile $ FileInfo
+			{ contentFile = srcfile
+			, matchFile = destfile
+			, matchKey = Nothing
+			}
+		lockingfile <- not <$> addUnlocked addunlockedmatcher mi True
+		-- Minimal lock down with no hard linking so nothing
+		-- has to be done to clean up from it.
+		let cfg = LockDownConfig
+			{ lockingFile = lockingfile
+			, hardlinkFileTmpDir = Nothing
+			-- The write perms of the file may not be able to be
+			-- removed, if it's being imported from a crippled
+			-- filesystem. So lockDown is asked to not check
+			-- the write perms. They will be checked later, after
+			-- the file gets copied into the repository.
+			, checkWritePerms = False
+			}
+		v <- lockDown cfg (fromRawFilePath srcfile)
+		case v of
+			Just ld -> do
+				backend <- chooseBackend destfile
+				k <- fst <$> genKey (keySource ld) nullMeterUpdate backend
+				a (ld, k)
+			Nothing -> stop
+	checkdup k dupa notdupa = ifM (isKnownKey k)
+		( dupa
+		, notdupa
+		)
+	pickaction = lockdown $ \(ld, k) -> case mode of
+		DeDuplicate -> checkdup k (deletedup k) (importfile ld k)
+		CleanDuplicates -> checkdup k
+			(deletedup k)
+			(skipbecause "not duplicate")
+		SkipDuplicates -> checkdup k 
+			(skipbecause "duplicate")
+			(importfile ld k)
+		ReinjectDuplicates -> checkdup k
+			(reinject k)
+			(importfile ld k)
+		_ -> importfile ld k
+	skipbecause s = do
+		showNote (s <> "; skipping")
+		next (return True)
+
+verifyExisting :: Key -> RawFilePath -> (CommandPerform, CommandPerform) -> CommandPerform
+verifyExisting key destfile (yes, no) = do
+	-- Look up the numcopies setting for the file that it would be
+	-- imported to, if it were imported.
+	(needcopies, mincopies) <- getFileNumMinCopies destfile
+
+	(tocheck, preverified) <- verifiableCopies key []
+	verifyEnoughCopiesToDrop [] key Nothing needcopies mincopies [] preverified tocheck
+		(const yes) no
+
+seekRemote :: Remote -> Branch -> Maybe TopFilePath -> Bool -> CheckGitIgnore -> [String] -> CommandSeek
+seekRemote remote branch msubdir importcontent ci importmessages = do
+	importtreeconfig <- case msubdir of
+		Nothing -> return ImportTree
+		Just subdir ->
+			let mk tree = pure $ ImportSubTree subdir tree
+			in fromtrackingbranch Git.Ref.tree >>= \case
+				Just tree -> mk tree
+				Nothing -> inRepo (Git.Ref.tree branch) >>= \case
+					Just tree -> mk tree
+					Nothing -> giveup $ "Unable to find base tree for branch " ++ fromRef branch
+	
+	trackingcommit <- fromtrackingbranch Git.Ref.sha
+	cmode <- annexCommitMode <$> Annex.getGitConfig
+	let importcommitconfig = ImportCommitConfig trackingcommit cmode importmessages'
+	let commitimport = commitRemote remote branch tb trackingcommit importtreeconfig importcommitconfig
+
+	importabletvar <- liftIO $ newTVarIO Nothing
+	void $ includeCommandAction (listContents remote importtreeconfig ci importabletvar)
+	liftIO (atomically (readTVar importabletvar)) >>= \case
+		Nothing -> return ()
+		Just importable -> importChanges remote importtreeconfig importcontent False importable >>= \case
+			ImportUnfinished -> warning $ UnquotedString $ concat
+				[ "Failed to import some files from "
+				, Remote.name remote
+				, ". Re-run command to resume import."
+				]
+			ImportFinished imported -> void $
+				includeCommandAction $ 
+					commitimport imported
+  where
+	importmessages'
+		| null importmessages = ["import from " ++ Remote.name remote]
+		| otherwise = importmessages
+
+	tb = mkRemoteTrackingBranch remote branch
+
+	fromtrackingbranch a = inRepo $ a (fromRemoteTrackingBranch tb)
+
+listContents :: Remote -> ImportTreeConfig -> CheckGitIgnore -> TVar (Maybe (ImportableContentsChunkable Annex (ContentIdentifier, Remote.ByteSize))) -> CommandStart
+listContents remote importtreeconfig ci tvar = starting "list" ai si $
+	listContents' remote importtreeconfig ci $ \importable -> do
+		liftIO $ atomically $ writeTVar tvar importable
+		next $ return True
+  where
+	ai = ActionItemOther (Just (UnquotedString (Remote.name remote)))
+	si = SeekInput []
+
+listContents' :: Remote -> ImportTreeConfig -> CheckGitIgnore -> (Maybe (ImportableContentsChunkable Annex (ContentIdentifier, Remote.ByteSize)) -> Annex a) -> Annex a
+listContents' remote importtreeconfig ci a = 
+	makeImportMatcher remote >>= \case
+		Right matcher -> tryNonAsync (getImportableContents remote importtreeconfig ci matcher) >>= \case
+			Right importable -> a importable
+			Left e -> giveup $ "Unable to list contents of " ++ Remote.name remote ++ ": " ++ show e
+		Left err -> giveup $ unwords 
+			[ "Cannot import from"
+			, Remote.name remote
+			, "because of a problem with its configuration:"
+			, err
+			]
+
+commitRemote :: Remote -> Branch -> RemoteTrackingBranch -> Maybe Sha -> ImportTreeConfig -> ImportCommitConfig -> Imported -> CommandStart
+commitRemote remote branch tb trackingcommit importtreeconfig importcommitconfig imported =
+	starting "update" ai si $ do
+		importcommit <- buildImportCommit remote importtreeconfig importcommitconfig imported
+		next $ updateremotetrackingbranch importcommit
+  where
+	ai = ActionItemOther (Just $ UnquotedString $ fromRef $ fromRemoteTrackingBranch tb)
+	si = SeekInput []
+	-- Update the tracking branch. Done even when there
+	-- is nothing new to import, to make sure it exists.
+	updateremotetrackingbranch importcommit =
+		case importcommit <|> trackingcommit of
+			Just c -> do
+				setRemoteTrackingBranch tb c
+				return True
+			Nothing -> do
+				warning $ UnquotedString $ "Nothing to import and " ++ fromRef branch ++ " does not exist."
+				return False
diff --git a/Command/ImportFeed.hs b/Command/ImportFeed.hs
new file mode 100644
index 0000000000..eeb247980e
--- /dev/null
+++ b/Command/ImportFeed.hs
@@ -0,0 +1,655 @@
+{- git-annex command
+ -
+ - Copyright 2013-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE BangPatterns #-}
+{-# LANGUAGE CPP #-}
+
+module Command.ImportFeed where
+
+import Text.Feed.Import
+import Text.Feed.Query
+import Text.Feed.Types
+import qualified Data.Set as S
+import qualified Data.Map as M
+import Data.Time.Clock
+import Data.Time.Clock.POSIX
+import Data.Time.Format
+import Data.Time.Calendar
+import Data.Time.LocalTime
+import Control.Concurrent.STM
+import qualified Data.Text as T
+import qualified Data.Text.Encoding as TE
+import qualified System.FilePath.ByteString as P
+import qualified Data.ByteString as B
+
+import Command
+import qualified Annex
+import qualified Annex.Url as Url
+import qualified Remote
+import qualified Types.Remote as Remote
+import Types.UrlContents
+import Logs.Web
+import Logs.File
+import qualified Utility.Format
+import Utility.Tmp
+import Utility.Metered
+import Command.AddUrl (addUrlFile, downloadRemoteFile, parseDownloadOptions, DownloadOptions(..), checkClaimingUrl, checkCanAdd, addWorkTree, checkRaw, useYoutubeDl)
+import Annex.UUID
+import Backend.URL (fromUrl)
+import Annex.Content
+import Annex.WorkTree
+import Annex.YoutubeDl
+import Types.MetaData
+import Logs.MetaData
+import Annex.MetaData
+import Annex.FileMatcher
+import Annex.UntrustedFilePath
+import qualified Utility.RawFilePath as R
+import qualified Database.ImportFeed as Db
+
+cmd :: Command
+cmd = notBareRepo $ withAnnexOptions os $
+	command "importfeed" SectionCommon "import files from podcast feeds"
+		(paramRepeating paramUrl) (seek <$$> optParser)
+  where
+	os = [jobsOption, jsonOptions, jsonProgressOption, backendOption]
+
+data ImportFeedOptions = ImportFeedOptions
+	{ feedUrls :: CmdParams
+	, templateOption :: Maybe String
+	, scrapeOption :: Bool
+	, downloadOptions :: DownloadOptions
+	}
+
+optParser :: CmdParamsDesc -> Parser ImportFeedOptions
+optParser desc = ImportFeedOptions
+	<$> cmdParams desc
+	<*> optional (strOption
+		( long "template" <> metavar paramFormat
+		<> help "template for filenames"
+		))
+	<*> switch
+		( long "scrape"
+		<> help "scrape website for content to import"
+		)
+	<*> parseDownloadOptions False
+
+seek :: ImportFeedOptions -> CommandSeek
+seek o = startConcurrency commandStages $ do
+	addunlockedmatcher <- addUnlockedMatcher
+	cache <- getCache (templateOption o)
+	dlst <- liftIO $ newTMVarIO M.empty
+	checkst <- liftIO $ newTVarIO M.empty
+
+	forM_ (feedUrls o) $ \url -> do
+		liftIO $ atomically $ do
+			m <- takeTMVar dlst
+			putTMVar dlst (M.insert url Nothing m)
+		commandAction $ getFeed o url dlst
+		startpendingdownloads addunlockedmatcher cache dlst checkst False
+	
+	startpendingdownloads addunlockedmatcher cache dlst checkst True
+
+	clearfeedproblems checkst
+  where
+  	getpendingdownloads dlst blocking
+		| blocking = do
+			m <- takeTMVar dlst
+			if M.null m
+				then do
+					putTMVar dlst m
+					return m
+				else
+					let (pending, rest) = M.partition ispending m
+					in if M.null pending || not (M.null rest)
+						then retry
+						else do
+							putTMVar dlst rest
+							return pending
+		| otherwise = do
+			m <- takeTMVar dlst
+			let (pending, rest) = M.partition ispending m
+			putTMVar dlst rest
+			return pending
+	  where
+		ispending Nothing = False
+		ispending (Just _) = True
+
+	startpendingdownloads addunlockedmatcher cache dlst checkst blocking = do
+		m <- liftIO $ atomically $ getpendingdownloads dlst blocking
+		
+		forM_ (M.toList m) $ \(url, v) -> case v of
+			Nothing -> noop
+			Just Nothing -> noop
+			Just (Just is) -> 
+				forM_ is $ \i -> do
+					cv <- liftIO newEmptyTMVarIO
+					liftIO $ atomically $ modifyTVar checkst $
+						M.insertWith (++) url [cv]
+					commandAction $
+						startDownload addunlockedmatcher o cache cv i
+	
+	clearfeedproblems checkst = do
+		m <- liftIO $ atomically $ readTVar checkst
+		forM_ (M.toList m) $ \(url, cvl) ->
+			whenM (and <$> mapM (liftIO . atomically . takeTMVar) cvl) $
+				clearFeedProblem url
+
+getFeed
+	:: ImportFeedOptions
+	-> URLString
+	-> TMVar (M.Map URLString (Maybe (Maybe [ToDownload])))
+	-> CommandStart
+getFeed o url st =
+	starting "importfeed" (ActionItemOther (Just (UnquotedString url))) (SeekInput [url]) $
+		go `onException` recordfail
+  where
+	record v = liftIO $ atomically $ do
+		m <- takeTMVar st
+		putTMVar st (M.insert url v m)
+	recordfail = record (Just Nothing)
+	
+	go
+		| scrapeOption o = scrape
+		| otherwise = get
+
+	get = withTmpFile "feed" $ \tmpf h -> do
+		liftIO $ hClose h
+		ifM (downloadFeed url tmpf)
+			( parse tmpf
+			, do
+				recordfail
+				next $ feedProblem url
+					"downloading the feed failed"
+			)
+
+	-- Use parseFeedFromFile rather than reading the file
+	-- ourselves because it goes out of its way to handle encodings.
+	parse tmpf = liftIO (parseFeedFromFile' tmpf) >>= \case
+		Nothing -> debugfeedcontent tmpf "parsing the feed failed"
+		Just f -> do
+			case decodeBS $ fromFeedText $ getFeedTitle f of
+				"" -> noop
+				t -> showNote (UnquotedString ('"' : t ++ "\""))
+			case findDownloads url f of
+				[] -> debugfeedcontent tmpf "bad feed content; no enclosures to download"
+				l -> do
+					record (Just (Just l))
+					next $ return True
+	
+	debugfeedcontent tmpf msg = do
+		feedcontent <- liftIO $ readFile tmpf
+		fastDebug "Command.ImportFeed" $ unlines
+			[ "start of feed content"
+			, feedcontent
+			, "end of feed content"
+			]
+		recordfail
+		next $ feedProblem url
+			(msg ++ " (use --debug --debugfilter=ImportFeed to see the feed content that was downloaded)")
+		
+	scrape = youtubePlaylist url >>= \case
+		Left err -> do
+			recordfail
+			next $ feedProblem url err
+		Right playlist -> do
+			record (Just (Just (playlistDownloads url playlist)))
+			next $ return True
+
+parseFeedFromFile' :: FilePath -> IO (Maybe Feed)
+#if MIN_VERSION_feed(1,1,0)
+parseFeedFromFile' = parseFeedFromFile
+#else
+parseFeedFromFile' f = catchMaybeIO (parseFeedFromFile f)
+#endif
+
+data ToDownload = ToDownload
+	{ feedurl :: URLString
+	, location :: DownloadLocation
+	, itemid :: Maybe B.ByteString
+	-- Either the parsed or unparsed date.
+	, itempubdate :: Maybe (Either String UTCTime)
+	-- Fields that are used as metadata and to generate the filename.
+	, itemfields :: [(String, String)]
+	-- True when youtube-dl found this by scraping, so certainly
+	-- supports downloading it.
+	, youtubedlscraped :: Bool
+	}
+
+data DownloadLocation = Enclosure URLString | MediaLink URLString
+
+type ItemId = String
+
+data Cache = Cache
+	{ dbhandle :: Maybe Db.ImportFeedDbHandle 
+	, template :: Utility.Format.Format
+	}
+
+getCache :: Maybe String -> Annex Cache
+getCache opttemplate = ifM (Annex.getRead Annex.force)
+	( ret Nothing
+	, do
+		j <- jsonOutputEnabled
+		unless j $
+			showStartMessage (StartMessage "importfeed" (ActionItemOther (Just "gathering known urls")) (SeekInput []))
+		h <- Db.openDb
+		unless j
+			showEndOk
+		ret (Just h)
+	)
+  where
+	tmpl = Utility.Format.gen $ fromMaybe defaultTemplate opttemplate
+	ret h = return $ Cache h tmpl
+
+findDownloads :: URLString -> Feed -> [ToDownload]
+findDownloads u f = catMaybes $ map mk (feedItems f)
+  where
+	mk i = case getItemEnclosure i of
+		Just (enclosureurl, _, _) ->
+			Just $ mk' i
+				(Enclosure $ decodeBS $ fromFeedText enclosureurl)
+		Nothing -> case getItemLink i of
+			Just l -> Just $ mk' i
+				(MediaLink $ decodeBS $ fromFeedText l)
+			Nothing -> Nothing
+	mk' i l = ToDownload
+		{ feedurl = u
+		, location = l
+		, itemid = case getItemId i of
+			Just (_, iid) -> Just (fromFeedText iid)
+			_ -> Nothing
+		, itempubdate = case getItemPublishDate i :: Maybe (Maybe UTCTime) of
+			Just (Just d) -> Just (Right d)
+			_ -> Left . decodeBS . fromFeedText 
+				<$> getItemPublishDateString  i
+		, itemfields = extractFeedItemFields f i u
+		, youtubedlscraped = False
+		}
+
+{- Feeds change, so a feed download cannot be resumed. -}
+downloadFeed :: URLString -> FilePath -> Annex Bool
+downloadFeed url f
+	| Url.parseURIRelaxed url == Nothing = giveup "invalid feed url"
+	| otherwise = Url.withUrlOptions $
+		Url.download nullMeterUpdate Nothing url f
+
+startDownload :: AddUnlockedMatcher -> ImportFeedOptions -> Cache -> TMVar Bool -> ToDownload -> CommandStart
+startDownload addunlockedmatcher opts cache cv todownload = case location todownload of
+	Enclosure url -> startdownloadenclosure url
+	MediaLink linkurl -> do
+		let mediaurl = setDownloader linkurl YoutubeDownloader
+		let mediakey = Backend.URL.fromUrl mediaurl Nothing (verifiableOption (downloadOptions opts))
+		-- Old versions of git-annex that used quvi might have
+		-- used the quviurl for this, so check if it's known
+		-- to avoid adding it a second time.
+		let quviurl = setDownloader linkurl QuviDownloader
+		checkknown mediaurl $ checkknown quviurl $
+			ifM (Annex.getRead Annex.fast <||> pure (relaxedOption (downloadOptions opts)))
+				( addmediafast linkurl mediaurl mediakey
+				, downloadmedia linkurl mediaurl mediakey
+				)
+  where
+	{- Avoids downloading any items that are already known to be
+	 - associated with a file in the annex. -}
+	checkknown url a = case dbhandle cache of
+		Just db -> ifM (liftIO $ Db.isKnownUrl db url)
+			( nothingtodo
+			, case itemid todownload of
+				Just iid ->
+					ifM (liftIO $ Db.isKnownItemId db iid)
+						( nothingtodo
+						, a
+						)
+				Nothing -> a
+			)
+		Nothing -> a
+
+	nothingtodo = recordsuccess >> stop
+
+	recordsuccess = liftIO $ atomically $ putTMVar cv True
+	
+	startdownloadenclosure :: URLString -> CommandStart
+	startdownloadenclosure url = checkknown url $ startUrlDownload cv todownload url $
+		downloadEnclosure addunlockedmatcher opts cache cv todownload url 
+
+	downloadmedia linkurl mediaurl mediakey =
+		ifM (useYoutubeDl (downloadOptions opts) <&&> youtubeDlSupported linkurl)
+			( startUrlDownload cv todownload linkurl $
+				withTmpWorkDir mediakey $ \workdir -> do
+					dl <- youtubeDl linkurl (fromRawFilePath workdir) nullMeterUpdate
+					case dl of
+						Right (Just mediafile) -> do
+							let ext = case takeExtension mediafile of
+								[] -> ".m"
+								s -> s
+							runDownload todownload linkurl ext cache cv $ \f ->
+								checkCanAdd (downloadOptions opts) f $ \canadd -> do
+									addWorkTree canadd addunlockedmatcher webUUID mediaurl f mediakey (Just (toRawFilePath mediafile))
+									return (Just [mediakey])
+						-- youtube-dl didn't support it, so
+						-- download it as if the link were
+						-- an enclosure.
+						Right Nothing -> contdownloadlink
+						Left msg -> do
+							warning $ UnquotedString $ linkurl ++ ": " ++ msg
+							liftIO $ atomically $ putTMVar cv False
+							next $ return False
+			, startdownloadlink
+			)
+	  where
+		startdownloadlink = checkRaw (Just linkurl) (downloadOptions opts) nothingtodo $
+			startdownloadenclosure linkurl
+		contdownloadlink = downloadEnclosure addunlockedmatcher opts cache cv todownload linkurl
+
+	addmediafast linkurl mediaurl mediakey =
+		ifM (useYoutubeDl (downloadOptions opts)
+		     <&&> (pure (youtubedlscraped todownload) <||> youtubeDlSupported linkurl))
+			( startUrlDownload cv todownload linkurl $ do
+				runDownload todownload linkurl ".m" cache cv $ \f ->
+					checkCanAdd (downloadOptions opts) f $ \canadd -> do
+						addWorkTree canadd addunlockedmatcher webUUID mediaurl f mediakey Nothing
+						return (Just [mediakey])
+			, startdownloadenclosure linkurl
+			)
+
+downloadEnclosure :: AddUnlockedMatcher -> ImportFeedOptions -> Cache -> TMVar Bool -> ToDownload -> URLString -> CommandPerform
+downloadEnclosure addunlockedmatcher opts cache cv todownload url = 
+	runDownload todownload url (takeWhile (/= '?') $ takeExtension url) cache cv $ \f -> do
+		let f' = fromRawFilePath f
+		r <- checkClaimingUrl (downloadOptions opts) url
+		if Remote.uuid r == webUUID || rawOption (downloadOptions opts)
+			then checkRaw (Just url) (downloadOptions opts) (pure Nothing) $ do
+				let dlopts = (downloadOptions opts)
+					-- force using the filename
+					-- chosen here
+					{ fileOption = Just f'
+					-- don't use youtube-dl
+					, rawOption = True
+					}
+				let go urlinfo = Just . maybeToList <$> addUrlFile addunlockedmatcher dlopts url urlinfo f
+				if relaxedOption (downloadOptions opts)
+					then go Url.assumeUrlExists
+					else Url.withUrlOptions (Url.getUrlInfo url) >>= \case
+						Right urlinfo -> go urlinfo
+						Left err -> do
+							warning (UnquotedString err)
+							return (Just [])
+			else do
+				res <- tryNonAsync $ maybe
+					(giveup $ "unable to checkUrl of " ++ Remote.name r)
+					(flip id url)
+					(Remote.checkUrl r)
+				case res of
+					Left _ -> return (Just [])
+					Right (UrlContents sz _) ->
+						Just . maybeToList <$>
+							downloadRemoteFile addunlockedmatcher r (downloadOptions opts) url f sz
+					Right (UrlMulti l) -> do
+						kl <- forM l $ \(url', sz, subf) ->
+							let dest = f P.</> toRawFilePath (sanitizeFilePath subf)
+							in downloadRemoteFile addunlockedmatcher r (downloadOptions opts) url' dest sz
+						return $ Just $ if all isJust kl
+							then catMaybes kl
+							else []
+
+runDownload
+	:: ToDownload
+	-> URLString
+	-> String
+	-> Cache
+	-> TMVar Bool
+	-> (RawFilePath -> Annex (Maybe [Key]))
+	-> CommandPerform
+runDownload todownload url extension cache cv getter = do
+	dest <- makeunique (1 :: Integer) $
+		feedFile (template cache) todownload extension
+	case dest of
+		Nothing -> do
+			recordsuccess
+			next $ return True
+		Just f -> getter (toRawFilePath f) >>= \case
+			Just ks
+				-- Download problem.
+				| null ks -> do
+					broken <- checkFeedBroken (feedurl todownload)
+					when broken $
+						void $ feedProblem url "download failed"
+					liftIO $ atomically $ putTMVar cv broken
+					next $ return False
+				| otherwise -> do
+					forM_ ks $ \key ->
+						ifM (annexGenMetaData <$> Annex.getGitConfig)
+							( addMetaData key $ extractMetaData todownload
+							, addMetaData key $ minimalMetaData todownload
+							)
+					recordsuccess
+					next $  return True
+			-- Was not able to add anything, but not
+			-- because of a download problem.
+			Nothing -> do
+				recordsuccess
+				next $ return False
+  where
+	recordsuccess = liftIO $ atomically $ putTMVar cv True
+
+	forced = Annex.getRead Annex.force
+
+	{- Find a unique filename to save the url to.
+	 - If the file exists, prefixes it with a number.
+	 - When forced, the file may already exist and have the same
+	 - url, in which case Nothing is returned as it does not need
+	 - to be re-downloaded. -}
+	makeunique n file = ifM alreadyexists
+		( ifM forced
+			( lookupKey (toRawFilePath f) >>= \case
+				Just k -> checksameurl k
+				Nothing -> tryanother
+			, tryanother
+			)
+		, return $ Just f
+		)
+	  where
+		f = if n < 2
+			then file
+			else
+				let (d, base) = splitFileName file
+				in d </> show n ++ "_" ++ base
+		tryanother = makeunique (n + 1) file
+		alreadyexists = liftIO $ isJust <$> catchMaybeIO (R.getSymbolicLinkStatus (toRawFilePath f))
+		checksameurl k = ifM (elem url . map fst . map getDownloader <$> getUrls k)
+			( return Nothing
+			, tryanother
+			)
+
+startUrlDownload :: TMVar Bool -> ToDownload -> URLString -> CommandPerform -> CommandStart
+startUrlDownload cv todownload url a = do
+	starting "addurl"
+		(ActionItemOther (Just (UnquotedString url)))
+		(SeekInput [feedurl todownload])
+		(go `onException` recordfailure)
+  where
+	recordfailure = do
+		void $ feedProblem url "download failed"
+		liftIO $ atomically $ tryPutTMVar cv False
+	go = do
+		maybeAddJSONField "url" url
+		a
+
+defaultTemplate :: String
+defaultTemplate = "${feedtitle}/${itemtitle}${extension}"
+
+{- Generates a filename to use for a feed item by filling out the template.
+ - The filename may not be unique. -}
+feedFile :: Utility.Format.Format -> ToDownload -> String -> FilePath
+feedFile tmpl i extension = sanitizeLeadingFilePathCharacter $ 
+	Utility.Format.format tmpl $
+		M.map sanitizeFilePathComponent $ M.fromList $ itemfields i ++
+			[ ("extension", extension)
+			, extractField "itempubdate" [itempubdatestring]
+			, extractField "itempubyear" [itempubyear]
+			, extractField "itempubmonth" [itempubmonth]
+			, extractField "itempubday" [itempubday]
+			, extractField "itempubhour" [itempubhour]
+			, extractField "itempubminute" [itempubminute]
+			, extractField "itempubsecond" [itempubsecond]
+			]
+  where
+	pubdate = maybe Nothing eitherToMaybe (itempubdate i)
+	
+	itempubdatestring = case itempubdate i of
+		Just (Right pd) -> Just $ formatTime defaultTimeLocale "%F" pd
+		-- if date cannot be parsed, use the raw string
+		Just (Left s) -> Just $ replace "/" "-" s
+		Nothing -> Nothing
+	
+	(itempubyear, itempubmonth, itempubday) = case pubdate of
+		Nothing -> (Nothing, Nothing, Nothing)
+		Just pd -> 
+			let (y, m, d) = toGregorian (utctDay pd)
+			in (Just (show y), Just (show m), Just (show d))
+	
+	(itempubhour, itempubminute, itempubsecond) = case pubdate of
+		Nothing -> (Nothing, Nothing, Nothing)
+		Just pd -> 
+			let tod = timeToTimeOfDay (utctDayTime pd)
+			in ( Just (show (todHour tod))
+			   , Just (show (todMin tod))
+			   -- avoid fractional seconds
+			   , Just (takeWhile (/= '.') (show (todSec tod)))
+			   )
+
+extractMetaData :: ToDownload -> MetaData
+extractMetaData i = case itempubdate i of
+	Just (Right d) -> unionMetaData meta (dateMetaData d meta)
+	_ -> meta
+  where
+	tometa (k, v) = (mkMetaFieldUnchecked (T.pack k), S.singleton (toMetaValue (encodeBS v)))
+	meta = MetaData $ M.fromList $ map tometa $ itemfields i
+
+minimalMetaData :: ToDownload -> MetaData
+minimalMetaData i = case itemid i of
+	Nothing -> emptyMetaData
+	Just iid -> MetaData $ M.singleton itemIdField
+		(S.singleton $ toMetaValue iid)
+
+noneValue :: String
+noneValue = "none"
+
+extractField :: String -> [Maybe String] -> (String, String)
+extractField k [] = (k, noneValue)
+extractField k (Just v:_)
+	| not (null v) = (k, v)
+extractField k (_:rest) = extractField k rest
+
+extractFeedItemFields :: Feed -> Item -> URLString -> [(String, String)]
+extractFeedItemFields f i u = map (uncurry extractField)
+	[ ("feedurl", [Just u])
+	, ("feedtitle", [feedtitle])
+	, ("itemtitle", [itemtitle])
+	, ("feedauthor", [feedauthor])
+	, ("itemauthor", [itemauthor])
+	, ("itemsummary", [decodeBS . fromFeedText <$> getItemSummary i])
+	, ("itemdescription", [decodeBS . fromFeedText <$> getItemDescription i])
+	, ("itemrights", [decodeBS . fromFeedText <$> getItemRights i])
+	, ("itemid", [decodeBS . fromFeedText . snd <$> getItemId i])
+	, ("title", [itemtitle, feedtitle])
+	, ("author", [itemauthor, feedauthor])
+	]
+  where
+	feedtitle = Just $ decodeBS $ fromFeedText $ getFeedTitle f
+	itemtitle = decodeBS . fromFeedText <$> getItemTitle i
+	feedauthor = decodeBS . fromFeedText <$> getFeedAuthor f
+	itemauthor = decodeBS . fromFeedText <$> getItemAuthor i
+
+playlistFields :: URLString -> YoutubePlaylistItem -> [(String, String)]
+playlistFields u i = map (uncurry extractField)
+	[ ("feedurl", [Just u])
+	, ("feedtitle", [youtube_playlist_title i])
+	, ("itemtitle", [youtube_title i])
+	, ("feedauthor", [youtube_playlist_uploader i])
+	, ("itemauthor", [youtube_playlist_uploader i])
+	-- itemsummary omitted, no equivilant in yt-dlp data
+	, ("itemdescription", [youtube_description i])
+	, ("itemrights", [youtube_license i])
+	, ("itemid", [youtube_url i])
+	, ("title", [youtube_title i, youtube_playlist_title i])
+	, ("author", [youtube_playlist_uploader i])
+	]
+
+playlistDownloads :: URLString -> [YoutubePlaylistItem] -> [ToDownload]
+playlistDownloads url = mapMaybe go
+  where
+	go i = do
+		iurl <- youtube_url i
+		return $ ToDownload
+			{ feedurl = url
+			, location = MediaLink iurl
+			, itemid = Just (encodeBS iurl)
+			, itempubdate = 
+				Right . posixSecondsToUTCTime . fromIntegral
+					<$> youtube_timestamp i
+			, itemfields = playlistFields url i
+			, youtubedlscraped = True
+			}
+
+{- Called when there is a problem with a feed.
+ -
+ - If the feed has been broken for some time,
+ - returns False, otherwise only warns. -}
+feedProblem :: URLString -> String -> Annex Bool
+feedProblem url message = ifM (checkFeedBroken url)
+	( do
+		warning $ UnquotedString $ message ++ " (having repeated problems with feed: " ++ url ++ ")"
+		return False
+	, do
+		warning $ UnquotedString $ "warning: " ++ message ++ " (feed: " ++ url ++ ")"
+		return True
+	)
+
+{- A feed is only broken if problems have occurred repeatedly, for at
+ - least 23 hours. -}
+checkFeedBroken :: URLString -> Annex Bool
+checkFeedBroken url = checkFeedBroken' url =<< feedState url
+checkFeedBroken' :: URLString -> RawFilePath -> Annex Bool
+checkFeedBroken' url f = do
+	prev <- maybe Nothing readish
+		<$> liftIO (catchMaybeIO $ readFile (fromRawFilePath f))
+	now <- liftIO getCurrentTime
+	case prev of
+		Nothing -> do
+			writeLogFile f $ show now
+			return False
+		Just prevtime -> do
+			let broken = diffUTCTime now prevtime > 60 * 60 * 23
+			when broken $
+				-- Avoid repeatedly complaining about
+				-- broken feed.
+				clearFeedProblem url
+			return broken
+
+clearFeedProblem :: URLString -> Annex ()
+clearFeedProblem url =
+	void $ liftIO . tryIO . removeFile . fromRawFilePath
+		=<< feedState url
+
+feedState :: URLString -> Annex RawFilePath
+feedState url = fromRepo $ gitAnnexFeedState $ fromUrl url Nothing False
+
+{- The feed library parses the feed to Text, and does not use the
+ - filesystem encoding to do it, so when the locale is not unicode
+ - capable, a Text value can still include unicode characters. 
+ -
+ - So, it's not safe to use T.unpack to convert that to a String,
+ - because later use of that String by eg encodeBS will crash
+ - with an encoding error. Use this instead.
+ -
+ - This should not be used on a Text that is read using the
+ - filesystem encoding because it does not reverse that encoding.
+ -}
+fromFeedText :: T.Text -> B.ByteString
+fromFeedText = TE.encodeUtf8
diff --git a/Command/InAnnex.hs b/Command/InAnnex.hs
new file mode 100644
index 0000000000..15fecb69e9
--- /dev/null
+++ b/Command/InAnnex.hs
@@ -0,0 +1,29 @@
+{- git-annex command
+ -
+ - Copyright 2010 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.InAnnex where
+
+import Command
+import Annex.Content
+
+cmd :: Command
+cmd = noCommit $ 
+	command "inannex" SectionPlumbing 
+		"checks if keys are present in the annex"
+		(paramRepeating paramKey)
+		(withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withKeys (commandAction . start)
+
+start :: (SeekInput, Key) -> CommandStart
+start (_, key) = inAnnexSafe key >>= dispatch
+  where
+	dispatch (Just True) = stop
+	dispatch (Just False) = exit 1
+	dispatch Nothing = exit 100
+	exit n = liftIO $ exitWith $ ExitFailure n
diff --git a/Command/Indirect.hs b/Command/Indirect.hs
new file mode 100644
index 0000000000..fe5a929b04
--- /dev/null
+++ b/Command/Indirect.hs
@@ -0,0 +1,21 @@
+{- git-annex command
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Indirect where
+
+import Command
+
+cmd :: Command
+cmd = notBareRepo $ noDaemonRunning $
+	command "indirect" SectionSetup "switch repository to indirect mode (deprecated)"
+		paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = stop
diff --git a/Command/Info.hs b/Command/Info.hs
new file mode 100644
index 0000000000..2c989a91be
--- /dev/null
+++ b/Command/Info.hs
@@ -0,0 +1,829 @@
+{- git-annex command
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns, DeriveDataTypeable, PackageImports, OverloadedStrings #-}
+
+module Command.Info where
+
+import "mtl" Control.Monad.State.Strict
+import qualified Data.Map.Strict as M
+import qualified Data.Vector as V
+import qualified System.FilePath.ByteString as P
+import System.PosixCompat.Files (isDirectory)
+import Data.Ord
+import qualified Data.Semigroup as Sem
+import Prelude
+
+import Command
+import qualified Git
+import qualified Annex
+import qualified Remote
+import qualified Types.Remote as Remote
+import qualified Annex.SpecialRemote as SpecialRemote
+import Utility.DataUnits
+import Utility.DiskFree
+import Annex.Content
+import Annex.UUID
+import Annex.CatFile
+import Annex.WorkTree
+import Logs.UUID
+import Logs.Trust
+import Logs.Location
+import Annex.NumCopies
+import Git.Config (boolConfig)
+import qualified Git.LsTree as LsTree
+import Utility.Percentage
+import Utility.Aeson hiding (json)
+import Types.Transfer
+import Logs.Transfer
+import Types.Key
+import Types.TrustLevel
+import Types.FileMatcher
+import Types.Availability
+import qualified Limit
+import Messages.JSON (DualDisp(..), ObjectMap(..))
+import Annex.BloomFilter
+import qualified Command.Unused
+import qualified Utility.RawFilePath as R
+
+-- a named computation that produces a statistic
+type Stat = StatState (Maybe (String, StatState String))
+
+-- data about a set of keys
+data KeyInfo = KeyInfo
+	{ countKeys :: Integer
+	, sizeKeys :: Integer
+	, unknownSizeKeys :: Integer
+	, backendsKeys :: M.Map KeyVariety Integer
+	}
+	
+instance Sem.Semigroup KeyInfo where
+	a <> b = KeyInfo
+		{ countKeys = countKeys a + countKeys b
+		, sizeKeys = sizeKeys a + sizeKeys b
+		, unknownSizeKeys = unknownSizeKeys a + unknownSizeKeys b
+		, backendsKeys = backendsKeys a <> backendsKeys b
+		}
+
+instance Monoid KeyInfo where
+	mempty = KeyInfo 0 0 0 M.empty
+
+data NumCopiesStats = NumCopiesStats
+	{ numCopiesVarianceMap :: M.Map Variance Integer
+	}
+
+newtype Variance = Variance Int
+	deriving (Eq, Ord)
+
+instance Show Variance where
+	show (Variance n)
+		| n >= 0 = "+" ++ show n
+		| otherwise = show n
+
+-- cached info that multiple Stats use
+data StatInfo = StatInfo
+	{ presentData :: Maybe KeyInfo
+	, referencedData :: Maybe KeyInfo
+	, repoData :: M.Map UUID KeyInfo
+	, allRepoData :: Maybe KeyInfo
+	, numCopiesStats :: Maybe NumCopiesStats
+	, infoOptions :: InfoOptions
+	}
+
+emptyStatInfo :: InfoOptions -> StatInfo
+emptyStatInfo = StatInfo Nothing Nothing M.empty Nothing Nothing
+
+-- a state monad for running Stats in
+type StatState = StateT StatInfo Annex
+
+cmd :: Command
+cmd = noCommit $ withAnnexOptions [jsonOptions, annexedMatchingOptions] $
+	command "info" SectionQuery
+		"information about an item or the repository"
+		(paramRepeating paramItem) (seek <$$> optParser)
+
+data InfoOptions = InfoOptions
+	{ infoFor :: CmdParams
+	, bytesOption :: Bool
+	, batchOption :: BatchMode
+	, autoenableOption :: Bool
+	, deadrepositoriesOption :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser InfoOptions
+optParser desc = InfoOptions
+	<$> cmdParams desc
+	<*> switch
+		( long "bytes"
+		<> help "display file sizes in bytes"
+		)
+	<*> parseBatchOption False
+	<*> switch
+		( long "autoenable"
+		<> help "list special remotes that are configured to autoenable"
+		)
+	<*> switch
+		( long "dead-repositories"
+		<> help "list repositories that have been marked as dead"
+		)
+
+seek :: InfoOptions -> CommandSeek
+seek o = case batchOption o of
+	NoBatch -> withWords (commandAction . start o) (infoFor o)
+	Batch fmt -> batchOnly Nothing (infoFor o) $
+		batchInput fmt (pure . Right) (itemInfo o)
+
+start :: InfoOptions -> [String] -> CommandStart
+start o [] = do
+	if autoenableOption o
+		then autoenableInfo
+		else if deadrepositoriesOption o
+			then deadrepositoriesInfo o
+			else globalInfo o
+	stop
+start o ps = do
+	mapM_ (\p -> itemInfo o (SeekInput [p], p)) ps
+	stop
+
+globalInfo :: InfoOptions -> Annex ()
+globalInfo o = do
+	u <- getUUID
+	whenM ((==) DeadTrusted <$> lookupTrust u) $
+		earlyWarning "Warning: This repository is currently marked as dead."
+	stats <- selStats global_fast_stats global_slow_stats
+	showCustom "info" (SeekInput []) $ do
+		evalStateT (mapM_ showStat stats) (emptyStatInfo o)
+		return True
+
+autoenableInfo :: Annex ()
+autoenableInfo = showCustom "info" (SeekInput []) $ do
+	m <- SpecialRemote.specialRemoteNameMap
+		<$> SpecialRemote.autoEnableable
+	descm <- M.unionWith Remote.addName
+		<$> uuidDescMap
+		<*> pure (M.map toUUIDDesc m)
+	s <- Remote.prettyPrintUUIDsDescs
+		"autoenable special remotes"
+		descm (M.keys m)
+	showRaw (encodeBS s)
+	return True
+
+deadrepositoriesInfo :: InfoOptions -> Annex ()
+deadrepositoriesInfo o = showCustom "info" (SeekInput []) $ do
+	evalStateT (showStat (repo_list DeadTrusted)) (emptyStatInfo o)
+	return True
+
+itemInfo :: InfoOptions -> (SeekInput, String) -> Annex ()
+itemInfo o (si, p) = ifM (isdir (toRawFilePath p))
+	( dirInfo o p si
+	, Remote.byName' p >>= \case
+		Right r -> remoteInfo o r si
+		Left _ -> Remote.nameToUUID' p >>= \case
+			([], _) -> do
+				relp <- liftIO $ relPathCwdToFile (toRawFilePath p)
+				lookupKey relp >>= \case
+					Just k -> fileInfo o (fromRawFilePath relp) si k
+					Nothing -> treeishInfo o p si
+			([u], _) -> uuidInfo o u si
+			(_us, msg) -> noInfo p si msg
+	)
+  where
+	isdir = liftIO . catchBoolIO . (isDirectory <$$> R.getFileStatus)
+
+noInfo :: String -> SeekInput -> String -> Annex ()
+noInfo s si msg = do
+	-- The string may not really be a file, but use ActionItemTreeFile,
+	-- rather than ActionItemOther to avoid breaking back-compat of
+	-- json output.
+	let ai = ActionItemTreeFile (toRawFilePath s)
+	showStartMessage (StartMessage "info" ai si)
+	showNote (UnquotedString msg)
+	showEndFail
+	Annex.incError
+
+dirInfo :: InfoOptions -> FilePath -> SeekInput -> Annex ()
+dirInfo o dir si = showCustom (unwords ["info", dir]) si $ do
+	stats <- selStats
+		(tostats (dir_name:tree_fast_stats True))
+		(tostats tree_slow_stats)
+	evalStateT (mapM_ showStat stats) =<< getDirStatInfo o dir
+	return True
+  where
+	tostats = map (\s -> s dir)
+
+treeishInfo :: InfoOptions -> String -> SeekInput -> Annex ()
+treeishInfo o t si = do
+	mi <- getTreeStatInfo o (Git.Ref (encodeBS t))
+	case mi of
+		Nothing -> noInfo t si
+			"not a directory or an annexed file or a treeish or a remote or a uuid"
+		Just i -> showCustom (unwords ["info", t]) si $ do
+			stats <- selStats 
+				(tostats (tree_name:tree_fast_stats False)) 
+				(tostats tree_slow_stats)
+			evalStateT (mapM_ showStat stats) i
+			return True
+  where
+	tostats = map (\s -> s t)
+
+fileInfo :: InfoOptions -> FilePath -> SeekInput -> Key -> Annex ()
+fileInfo o file si k = do
+	matcher <- Limit.getMatcher
+	let file' = toRawFilePath file
+	whenM (matcher $ MatchingFile $ FileInfo file' file' (Just k)) $
+		showCustom (unwords ["info", file]) si $ do
+			evalStateT (mapM_ showStat (file_stats file k)) (emptyStatInfo o)
+			return True
+
+remoteInfo :: InfoOptions -> Remote -> SeekInput -> Annex ()
+remoteInfo o r si = showCustom (unwords ["info", Remote.name r]) si $ do
+	i <- map (\(k, v) -> simpleStat k (pure v)) <$> Remote.getInfo r
+	let u = Remote.uuid r
+	l <- selStats 
+		(uuid_fast_stats u ++ remote_fast_stats r ++ i)
+		(uuid_slow_stats u)
+	evalStateT (mapM_ showStat l) (emptyStatInfo o)
+	return True
+
+uuidInfo :: InfoOptions -> UUID -> SeekInput -> Annex ()
+uuidInfo o u si = showCustom (unwords ["info", fromUUID u]) si $ do
+	l <- selStats (uuid_fast_stats u) (uuid_slow_stats u)
+	evalStateT (mapM_ showStat l) (emptyStatInfo o)
+	return True
+
+selStats :: [Stat] -> [Stat] -> Annex [Stat]
+selStats fast_stats slow_stats = do
+	fast <- Annex.getRead Annex.fast
+	return $ if fast
+		then fast_stats
+		else fast_stats ++ slow_stats
+
+{- Order is significant. Less expensive operations, and operations
+ - that share data go together.
+ -}
+global_fast_stats :: [Stat]
+global_fast_stats = 
+	[ repo_list Trusted
+	, repo_list SemiTrusted
+	, repo_list UnTrusted
+	, transfer_list
+	, disk_size
+	]
+
+global_slow_stats :: [Stat]
+global_slow_stats = 
+	[ tmp_size
+	, bad_data_size
+	, local_annex_keys
+	, local_annex_size
+	, known_annex_files True
+	, known_annex_size True
+	, total_annex_size
+	, reposizes_stats_global
+	, backend_usage
+	, bloom_info
+	]
+
+tree_fast_stats :: Bool -> [FilePath -> Stat]
+tree_fast_stats isworktree =
+	[ const local_annex_keys
+	, const local_annex_size
+	, const (known_annex_files isworktree)
+	, const (known_annex_size isworktree)
+	]
+
+tree_slow_stats :: [FilePath -> Stat]
+tree_slow_stats =
+	[ const numcopies_stats
+	, const reposizes_stats_tree
+	, const reposizes_total
+	]
+
+file_stats :: FilePath -> Key -> [Stat]
+file_stats f k =
+	[ file_name f
+	, key_size k
+	, key_name k
+	, content_present k
+	]
+
+remote_fast_stats :: Remote -> [Stat]
+remote_fast_stats r = map (\s -> s r)
+	[ remote_name
+	, remote_cost
+	, remote_type
+	, remote_availabile
+	]
+
+uuid_fast_stats :: UUID -> [Stat]
+uuid_fast_stats u = map (\s -> s u)
+	[ repo_uuid
+	, repo_description
+	, repo_trust
+	]
+
+uuid_slow_stats :: UUID -> [Stat]
+uuid_slow_stats u = map (\s -> s u)
+	[ repo_annex_keys
+	, repo_annex_size
+	]
+
+stat :: String -> (String -> StatState String) -> Stat
+stat desc a = return $ Just (desc, a desc)
+
+-- The json simply contains the same string that is displayed.
+simpleStat :: String -> StatState String -> Stat
+simpleStat desc getval = stat desc $ json id getval
+
+nostat :: Stat
+nostat = return Nothing
+
+json :: ToJSON' j => (j -> String) -> StatState j -> String -> StatState String
+json fmt a desc = do
+	j <- a
+	lift $ maybeShowJSON $ JSONChunk [(desc, j)]
+	return $ fmt j
+
+nojson :: StatState String -> String -> StatState String
+nojson a _ = a
+
+showStat :: Stat -> StatState ()
+showStat s = maybe noop calc =<< s
+  where
+	calc (desc, a) = do
+		(lift . showHeader . encodeBS) desc
+		lift . showRaw . encodeBS =<< a
+
+repo_list :: TrustLevel -> Stat
+repo_list level = stat n $ nojson $ lift $ do
+	us <- filter (/= NoUUID) . M.keys 
+		<$> (M.union <$> (M.map fromUUIDDesc <$> uuidDescMap) <*> Remote.remoteMap Remote.name)
+	rs <- fst <$> trustPartition level us
+	countRepoList (length rs)
+		-- This also handles json display.
+		<$> Remote.prettyPrintUUIDs n rs
+  where
+	n = showTrustLevel level ++ " repositories"
+
+countRepoList :: Int -> String -> String
+countRepoList _ [] = "0"
+countRepoList n s = show n ++ "\n" ++ beginning s
+
+dispRepoList :: String -> String
+dispRepoList [] = ""
+dispRepoList s = "\n" ++ beginning s
+
+dir_name :: FilePath -> Stat
+dir_name dir = simpleStat "directory" $ pure dir
+
+tree_name :: String -> Stat
+tree_name t = simpleStat "tree" $ pure t
+
+file_name :: FilePath -> Stat
+file_name file = simpleStat "file" $ pure file
+
+remote_name :: Remote -> Stat
+remote_name r = simpleStat "remote" $ pure (Remote.name r)
+
+repo_description :: UUID -> Stat
+repo_description = simpleStat "description" . lift . Remote.prettyUUID
+
+repo_uuid :: UUID -> Stat
+repo_uuid = simpleStat "uuid" . pure . fromUUID
+
+repo_trust :: UUID -> Stat
+repo_trust u = simpleStat "trust" $ lift $ showTrustLevel <$> lookupTrust u
+
+remote_cost :: Remote -> Stat
+remote_cost r = simpleStat "cost" $ pure $
+	show $ Remote.cost r
+
+remote_type :: Remote -> Stat
+remote_type r = simpleStat "type" $ pure $
+	Remote.typename $ Remote.remotetype r
+
+remote_availabile :: Remote -> Stat
+remote_availabile r = simpleStat "available" $ lift $
+	either show (\av -> boolConfig (av /= Unavailable))
+		<$> tryNonAsync (Remote.availability r)
+
+local_annex_keys :: Stat
+local_annex_keys = stat "local annex keys" $ json show $
+	countKeys <$> cachedPresentData
+
+local_annex_size :: Stat
+local_annex_size = simpleStat "local annex size" $
+	showSizeKeys =<< cachedPresentData
+
+-- "remote" is in the name for JSON backwards-compatibility
+repo_annex_keys :: UUID -> Stat
+repo_annex_keys u = stat "remote annex keys" $ \d ->
+	cachedRemoteData u >>= \case
+		Right rd -> json show (pure (countKeys rd)) d
+		Left n-> json id (pure n) d
+
+-- "remote" is in the name for JSON backwards-compatibility
+repo_annex_size :: UUID -> Stat
+repo_annex_size u = simpleStat "remote annex size" $
+	cachedRemoteData u >>= \case
+		Right d -> showSizeKeys d
+		Left n -> pure n
+
+known_annex_files :: Bool -> Stat
+known_annex_files isworktree = 
+	stat ("annexed files in " ++ treeDesc isworktree) $ json show $
+		countKeys <$> cachedReferencedData
+
+known_annex_size :: Bool -> Stat
+known_annex_size isworktree = 
+	simpleStat ("size of annexed files in " ++ treeDesc isworktree) $
+		showSizeKeys =<< cachedReferencedData
+
+total_annex_size :: Stat
+total_annex_size = 
+	simpleStat "combined annex size of all repositories" $
+		showSizeKeys . fromMaybe mempty . allRepoData
+		=<< cachedAllRepoData
+  
+treeDesc :: Bool -> String
+treeDesc True = "working tree"
+treeDesc False = "tree"
+
+tmp_size :: Stat
+tmp_size = staleSize "temporary object directory size" gitAnnexTmpObjectDir
+
+bad_data_size :: Stat
+bad_data_size = staleSize "bad keys size" gitAnnexBadDir
+
+key_size :: Key -> Stat
+key_size k = simpleStat "size" $ showSizeKeys $ addKey k emptyKeyInfo
+
+key_name :: Key -> Stat
+key_name k = simpleStat "key" $ pure $ serializeKey k
+
+content_present :: Key -> Stat
+content_present k = stat "present" $ json boolConfig $ lift $ inAnnex k
+
+bloom_info :: Stat
+bloom_info = simpleStat "bloom filter size" $ do
+	localkeys <- countKeys <$> cachedPresentData
+	capacity <- fromIntegral <$> lift bloomCapacity
+	let note = aside $
+		if localkeys >= capacity
+		then "appears too small for this repository; adjust annex.bloomcapacity"
+		else showPercentage 1 (percentage capacity localkeys) ++ " full"
+
+	-- Two bloom filters are used at the same time when running
+	-- git-annex unused, so double the size of one.
+	sizer <- mkSizer
+	size <- sizer committeeUnits False . (* 2) . fromIntegral . fst <$>
+		lift bloomBitsHashes
+
+	return $ size ++ note
+
+transfer_list :: Stat
+transfer_list = stat desc $ nojson $ lift $ do
+	uuidmap <- Remote.remoteMap id
+	ts <- getTransfers
+	maybeShowJSON $ JSONChunk [(desc, V.fromList $ map (uncurry jsonify) ts)]
+	qp <- coreQuotePath <$> Annex.getGitConfig
+	return $ if null ts
+		then "none"
+		else multiLine $
+			map (uncurry $ line qp uuidmap) $ sort ts
+  where
+	desc = "transfers in progress"
+	line qp uuidmap t i = unwords
+		[ fromRawFilePath (formatDirection (transferDirection t)) ++ "ing"
+		, fromRawFilePath $ quote qp $ actionItemDesc $ mkActionItem
+			(transferKey t, associatedFile i)
+		, if transferDirection t == Upload then "to" else "from"
+		, maybe (fromUUID $ transferUUID t) Remote.name $
+			M.lookup (transferUUID t) uuidmap
+		]
+	jsonify t i = object $ map (\(k, v) -> (textKey (packString k), v)) $
+		[ ("transfer", toJSON' (formatDirection (transferDirection t)))
+		, ("key", toJSON' (transferKey t))
+		, ("file", toJSON' (fromRawFilePath <$> afile))
+		, ("remote", toJSON' (fromUUID (transferUUID t) :: String))
+		]
+	  where
+		AssociatedFile afile = associatedFile i
+
+disk_size :: Stat
+disk_size = simpleStat "available local disk space" $
+	calcfree
+		<$> (lift $ annexDiskReserve <$> Annex.getGitConfig)
+		<*> (lift $ inRepo $ getDiskFree . fromRawFilePath . gitAnnexDir)
+		<*> mkSizer
+  where
+	calcfree reserve (Just have) sizer = unwords
+		[ sizer storageUnits False $ nonneg $ have - reserve
+		, "(+" ++ sizer storageUnits False reserve
+		, "reserved)"
+		]			
+	calcfree _ _ _ = "unknown"
+
+	nonneg x
+		| x >= 0 = x
+		| otherwise = 0
+
+backend_usage :: Stat
+backend_usage = stat "backend usage" $ json fmt $
+	ObjectMap . (M.mapKeys (decodeBS . formatKeyVariety)) . backendsKeys
+		<$> cachedReferencedData
+  where
+	fmt = multiLine . map (\(b, n) -> b ++ ": " ++ show n) . sort . M.toList . fromObjectMap
+
+numcopies_stats :: Stat
+numcopies_stats = stat "numcopies stats" $ json fmt $
+	calc <$> (maybe M.empty numCopiesVarianceMap <$> cachedNumCopiesStats)
+  where
+	calc = V.fromList
+		. map (\(variance, count) -> (show variance, count)) 
+		. sortBy (flip (comparing fst))
+		. M.toList
+	fmt = multiLine 
+		. map (\(variance, count) -> "numcopies " ++ variance ++ ": " ++ show count)
+		. V.toList
+
+reposizes_stats_tree :: Stat
+reposizes_stats_tree = reposizes_stats True "repositories containing these files"
+	=<< cachedRepoData
+
+reposizes_stats_global :: Stat
+reposizes_stats_global = reposizes_stats False "annex sizes of repositories" 
+	. repoData =<< cachedAllRepoData
+
+reposizes_stats :: Bool -> String -> M.Map UUID KeyInfo -> Stat
+reposizes_stats count desc m = stat desc $ nojson $ do
+	sizer <- mkSizer
+	let l = map (\(u, kd) -> (u, sizer storageUnits True (sizeKeys kd))) $
+		sortBy (flip (comparing (sizeKeys . snd))) $
+		M.toList m
+	let maxlen = maximum (map (length . snd) l)
+	descm <- lift Remote.uuidDescriptions
+	-- This also handles json display.
+	s <- lift $ Remote.prettyPrintUUIDsWith (Just "size") desc descm (Just . show) $
+		map (\(u, sz) -> (u, Just $ mkdisp sz maxlen)) l
+	return $ if count
+		then countRepoList (length l) s
+		else dispRepoList s
+  where
+	mkdisp sz maxlen = DualDisp
+		{ dispNormal = lpad maxlen sz
+		, dispJson = sz
+		}
+	lpad n s = (replicate (n - length s) ' ') ++ s
+
+reposizes_total :: Stat
+reposizes_total = simpleStat "combined size of repositories containing these files" $
+	showSizeKeys . mconcat . M.elems =<< cachedRepoData
+
+cachedPresentData :: StatState KeyInfo
+cachedPresentData = do
+	s <- get
+	case presentData s of
+		Just v -> return v
+		Nothing -> do
+			matcher <- lift getKeyOnlyMatcher
+			v <- foldl' (flip addKey) emptyKeyInfo
+				<$> lift (listKeys' InAnnex (matchOnKey matcher))
+			put s { presentData = Just v }
+			return v
+
+cachedRemoteData :: UUID -> StatState (Either String KeyInfo)
+cachedRemoteData u = do
+	s <- get
+	case M.lookup u (repoData s) of
+		Just v -> return (Right v)
+		Nothing -> do
+			matcher <- lift getKeyOnlyMatcher
+			let combinedata d uk = finishCheck uk >>= \case
+				Nothing -> return d
+				Just k -> ifM (matchOnKey matcher k)
+					( return (addKey k d)
+					, return d
+					)
+			lift (loggedKeysFor' u) >>= \case
+				Just (ks, cleanup) -> do
+					v <- lift $ foldM combinedata emptyKeyInfo ks
+					liftIO $ void cleanup
+					put s { repoData = M.insert u v (repoData s) }
+					return (Right v)
+				Nothing -> return (Left "not available in this read-only repository with unmerged git-annex branches")
+
+cachedReferencedData :: StatState KeyInfo
+cachedReferencedData = do
+	s <- get
+	case referencedData s of
+		Just v -> return v
+		Nothing -> do
+			matcher <- lift getKeyOnlyMatcher
+			let combinedata k _f d = ifM (matchOnKey matcher k)
+				( return (addKey k d)
+				, return d
+				)
+			!v <- lift $ Command.Unused.withKeysReferenced
+				emptyKeyInfo combinedata
+			put s { referencedData = Just v }
+			return v
+
+cachedAllRepoData :: StatState StatInfo
+cachedAllRepoData = do
+	s <- get
+	case allRepoData s of
+		Just _ -> return s
+		Nothing -> do
+			matcher <- lift getKeyOnlyMatcher
+			!(d, rd) <- lift $ overLocationLogs (emptyKeyInfo, mempty) $ \k locs (d, rd) -> do
+				ifM (matchOnKey matcher k)
+					( do
+						alivelocs <- snd
+							<$> trustPartition DeadTrusted locs
+						let !d' = addKeyCopies (genericLength alivelocs) k d
+						let !rd' = foldl' (flip (accumrepodata k)) rd alivelocs
+						return (d', rd')
+					, return (d, rd)
+					)
+			let s' = s { allRepoData = Just d, repoData = rd }
+			put s'
+			return s'
+  where
+	accumrepodata k = M.alter (Just . addKey k . fromMaybe emptyKeyInfo)
+
+cachedNumCopiesStats :: StatState (Maybe NumCopiesStats)
+cachedNumCopiesStats = numCopiesStats <$> get
+
+cachedRepoData :: StatState (M.Map UUID KeyInfo)
+cachedRepoData = repoData <$> get
+
+getDirStatInfo :: InfoOptions -> FilePath -> Annex StatInfo
+getDirStatInfo o dir = do
+	fast <- Annex.getRead Annex.fast
+	matcher <- Limit.getMatcher
+	(presentdata, referenceddata, numcopiesstats, repodata) <-
+		Command.Unused.withKeysFilesReferencedIn dir initial
+			(update matcher fast)
+	return $ StatInfo
+		(Just presentdata)
+		(Just referenceddata)
+		repodata
+		Nothing
+		(Just numcopiesstats)
+		o
+  where
+	initial = (emptyKeyInfo, emptyKeyInfo, emptyNumCopiesStats, M.empty)
+	update matcher fast key file vs@(presentdata, referenceddata, numcopiesstats, repodata) =
+		ifM (matcher $ MatchingFile $ FileInfo file file (Just key))
+			( do
+				!presentdata' <- ifM (inAnnex key)
+					( return $ addKey key presentdata
+					, return presentdata
+					)
+				let !referenceddata' = addKey key referenceddata
+				(!numcopiesstats', !repodata') <- if fast
+					then return (numcopiesstats, repodata)
+					else do
+						locs <- Remote.keyLocations key
+						nc <- updateNumCopiesStats file numcopiesstats locs
+						return (nc, updateRepoData key locs repodata)
+				return $! (presentdata', referenceddata', numcopiesstats', repodata')
+			, return vs
+			)
+
+getTreeStatInfo :: InfoOptions -> Git.Ref -> Annex (Maybe StatInfo)
+getTreeStatInfo o r = do
+	fast <- Annex.getRead Annex.fast
+	-- git lstree filenames start with a leading "./" that prevents
+	-- matching, and also things like --include are supposed to
+	-- match relative to the current directory, which does not make
+	-- sense when matching against files in some arbitrary tree.
+	matcher <- getKeyOnlyMatcher
+	(ls, cleanup) <- inRepo $ LsTree.lsTree
+		LsTree.LsTreeRecursive
+		(LsTree.LsTreeLong False)
+		r
+	(presentdata, referenceddata, repodata) <- go fast matcher ls initial
+	ifM (liftIO cleanup)
+		( return $ Just $
+			StatInfo (Just presentdata) (Just referenceddata) repodata Nothing Nothing o
+		, return Nothing
+		)
+  where
+	initial = (emptyKeyInfo, emptyKeyInfo, M.empty)
+	go _ _ [] vs = return vs
+	go fast matcher (l:ls) vs@(presentdata, referenceddata, repodata) =
+		catKey (LsTree.sha l) >>= \case
+			Nothing -> go fast matcher ls vs
+			Just key -> ifM (matchOnKey matcher key)
+				( do
+					!presentdata' <- ifM (inAnnex key)
+						( return $ addKey key presentdata
+						, return presentdata
+						)
+					let !referenceddata' = addKey key referenceddata
+					!repodata' <- if fast
+						then return repodata
+						else do
+							locs <- Remote.keyLocations key
+							return (updateRepoData key locs repodata)
+					go fast matcher ls $! (presentdata', referenceddata', repodata')
+				, go fast matcher ls vs
+				)
+
+emptyKeyInfo :: KeyInfo
+emptyKeyInfo = KeyInfo 0 0 0 M.empty
+
+emptyNumCopiesStats :: NumCopiesStats
+emptyNumCopiesStats = NumCopiesStats M.empty
+
+addKey :: Key -> KeyInfo -> KeyInfo
+addKey = addKeyCopies 1
+
+addKeyCopies :: Integer -> Key -> KeyInfo -> KeyInfo
+addKeyCopies numcopies key (KeyInfo count size unknownsize backends) =
+	KeyInfo count' size' unknownsize' backends'
+  where
+	{- All calculations strict to avoid thunks when repeatedly
+	 - applied to many keys. -}
+	!count' = count + 1
+	!backends' = M.insertWith (+) (fromKey keyVariety key) 1 backends
+	!size' = maybe size (\sz -> sz * numcopies + size) ks
+	!unknownsize' = maybe (unknownsize + 1) (const unknownsize) ks
+	!ks = fromKey keySize key
+
+updateRepoData :: Key -> [UUID] -> M.Map UUID KeyInfo -> M.Map UUID KeyInfo
+updateRepoData key locs m = m'
+  where
+	!m' = M.unionWith (\_old new -> new) m $
+		M.fromList $ zip locs (map update locs)
+	update loc = addKey key (fromMaybe emptyKeyInfo $ M.lookup loc m)
+
+updateNumCopiesStats :: RawFilePath -> NumCopiesStats -> [UUID] -> Annex NumCopiesStats
+updateNumCopiesStats file (NumCopiesStats m) locs = do
+	have <- trustExclude UnTrusted locs
+	!variance <- Variance <$> numCopiesCheck' file (-) have
+	let !m' = M.insertWith (+) variance 1 m
+	let !ret = NumCopiesStats m'
+	return ret
+
+showSizeKeys :: KeyInfo -> StatState String
+showSizeKeys d = do
+	sizer <- mkSizer
+	return $ total sizer ++ missingnote
+  where
+	total sizer = sizer storageUnits False $ sizeKeys d
+	missingnote
+		| unknownSizeKeys d == 0 = ""
+		| otherwise = aside $
+			"+ " ++ show (unknownSizeKeys d) ++
+			" unknown size"
+
+staleSize :: String -> (Git.Repo -> RawFilePath) -> Stat
+staleSize label dirspec = go =<< lift (dirKeys dirspec)
+  where
+	go [] = nostat
+	go keys = onsize =<< sum <$> keysizes keys
+	onsize 0 = nostat
+	onsize size = stat label $
+		json (++ aside "clean up with git-annex unused") $ do
+			sizer <- mkSizer
+			return $ sizer storageUnits False size
+	keysizes keys = do
+		dir <- lift $ fromRepo dirspec
+		liftIO $ forM keys $ \k -> 
+			catchDefaultIO 0 $ getFileSize (dir P.</> keyFile k)
+
+aside :: String -> String
+aside s = " (" ++ s ++ ")"
+
+multiLine :: [String] -> String
+multiLine = concatMap (\l -> "\n\t" ++ l)
+
+mkSizer :: StatState ([Unit] -> Bool -> ByteSize -> String)
+mkSizer = ifM (bytesOption . infoOptions <$> get)
+	( return (const $ const show)
+	, return roughSize
+	)
+			
+getKeyOnlyMatcher :: Annex (MatchInfo -> Annex Bool)
+getKeyOnlyMatcher = do
+	whenM (Limit.introspect matchNeedsFileName) $ do
+		warning "File matching options cannot be applied when getting this info."
+		giveup "Unable to continue."
+	Limit.getMatcher
+
+matchOnKey :: (MatchInfo -> Annex Bool) -> Key -> Annex Bool
+matchOnKey matcher k = matcher $ MatchingInfo $ ProvidedInfo
+	{ providedFilePath = Nothing
+	, providedKey = Just k
+	, providedFileSize = Nothing
+	, providedMimeType = Nothing
+	, providedMimeEncoding = Nothing
+	, providedLinkType = Nothing
+	}
diff --git a/Command/Init.hs b/Command/Init.hs
new file mode 100644
index 0000000000..2b7bbeb8a1
--- /dev/null
+++ b/Command/Init.hs
@@ -0,0 +1,90 @@
+{- git-annex command
+ -
+ - Copyright 2010-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Init where
+
+import Command
+import Annex.Init
+import Annex.Version
+import Types.RepoVersion
+import qualified Annex.SpecialRemote
+
+import Control.Monad.Fail as Fail (MonadFail(..))
+import qualified Data.Map as M
+	
+cmd :: Command
+cmd = dontCheck repoExists $ withAnnexOptions [jsonOptions] $
+	command "init" SectionSetup "initialize git-annex"
+		paramDesc (seek <$$> optParser)
+
+data InitOptions = InitOptions
+	{ initDesc :: String
+	, initVersion :: Maybe RepoVersion
+	, autoEnableOnly :: Bool
+	, noAutoEnable :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser InitOptions
+optParser desc = InitOptions
+	<$> (unwords <$> cmdParams desc)
+	<*> optional (option (str >>= parseRepoVersion)
+		( long "version" <> metavar paramValue
+		<> help "Override default annex.version"
+		))
+	<*> switch
+		( long "autoenable"
+		<> help "only enable special remotes configured with autoenable=true"
+		)
+	<*> switch
+		( long "no-autoenable"
+		<> help "do not enable special remotes configured with autoenable=true"
+		)
+
+parseRepoVersion :: MonadFail m => String -> m RepoVersion
+parseRepoVersion s = case RepoVersion <$> readish s of
+	Nothing -> Fail.fail $ "version parse error"
+	Just v
+		| v `elem` supportedVersions -> return v
+		| otherwise -> case M.lookup v autoUpgradeableVersions of
+			Just v' -> return v'
+			Nothing -> Fail.fail $ s ++ " is not a currently supported repository version"
+
+seek :: InitOptions -> CommandSeek
+seek = commandAction . start
+
+start :: InitOptions -> CommandStart
+start os
+	| autoEnableOnly os = 
+		starting "init" (ActionItemOther (Just "autoenable")) si $
+			performAutoEnableOnly
+	| otherwise = 
+		starting "init" (ActionItemOther (Just $ UnquotedString $ initDesc os)) si $
+			perform os
+  where
+	si = SeekInput []
+
+perform :: InitOptions -> CommandPerform
+perform os = do
+	case initVersion os of
+		Nothing -> noop
+		Just wantversion -> getVersion >>= \case
+			Just v | v /= wantversion ->
+				giveup $ "This repository is already a initialized with version " ++ show (fromRepoVersion v) ++ ", not changing to requested version."
+			_ -> noop
+	initialize
+		(if null (initDesc os) then Nothing else Just (initDesc os))
+		(initVersion os)
+	unless (noAutoEnable os)
+		Annex.SpecialRemote.autoEnable
+	next $ return True
+
+performAutoEnableOnly :: CommandPerform
+performAutoEnableOnly = do
+	Annex.SpecialRemote.autoEnable
+	next $ return True
diff --git a/Command/InitRemote.hs b/Command/InitRemote.hs
new file mode 100644
index 0000000000..92a8804265
--- /dev/null
+++ b/Command/InitRemote.hs
@@ -0,0 +1,171 @@
+{- git-annex command
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.InitRemote where
+
+import Command
+import Annex.SpecialRemote
+import qualified Remote
+import qualified Types.Remote as R
+import Types.RemoteConfig
+import Annex.UUID
+import Logs.UUID
+import Logs.Remote
+import Types.GitConfig
+import Types.ProposedAccepted
+import Config
+import Git.Config
+
+import qualified Data.Map as M
+import qualified Data.Text as T
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "initremote" SectionSetup
+		"creates a special (non-git) remote"
+		(paramPair paramName $ paramOptional $ paramRepeating paramParamValue)
+		(seek <$$> optParser)
+
+data InitRemoteOptions = InitRemoteOptions
+	{ cmdparams :: CmdParams
+	, sameas :: Maybe (DeferredParse UUID)
+	, whatElse :: Bool
+	, privateRemote :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser InitRemoteOptions
+optParser desc = InitRemoteOptions
+	<$> cmdParams desc
+	<*> optional parseSameasOption
+	<*> switch
+		( long "whatelse"
+		<> short 'w'
+		<> help "describe other configuration parameters for a special remote"
+		)
+	<*> switch
+		( long "private"
+		<> help "keep special remote information out of git-annex branch"
+		)
+
+parseSameasOption :: Parser (DeferredParse UUID)
+parseSameasOption = parseUUIDOption <$> strOption
+	( long "sameas"
+	<> metavar (paramRemote `paramOr` paramDesc `paramOr` paramUUID)
+	<> help "new remote that accesses the same data"
+	<> completeRemotes
+	)
+
+seek :: InitRemoteOptions -> CommandSeek
+seek o = withWords (commandAction . (start o)) (cmdparams o)
+
+start :: InitRemoteOptions -> [String] -> CommandStart
+start _ [] = giveup "Specify a name for the remote."
+start o (name:ws) = do
+	if whatElse o
+		then ifM jsonOutputEnabled
+			( starting "initremote" ai si $ prep $ \c t ->
+				describeOtherParamsFor c t
+			, startingCustomOutput (ActionItemOther Nothing) $ prep $ \c t ->
+				describeOtherParamsFor c t
+			)
+		else starting "initremote" ai si $ prep $ \c t ->
+			perform t name c o
+  where
+	prep a = do
+		whenM (not . null <$> findExisting name) $
+			giveup $ "There is already a special remote named \"" ++ name ++
+				"\". (Use enableremote to enable an existing special remote.)"
+		whenM (isJust <$> Remote.byNameOnly name) $
+			giveup $ "There is already a remote named \"" ++ name ++ "\""
+		sameasuuid <- maybe
+			(pure Nothing)
+			(Just . Sameas <$$> getParsed)
+			(sameas o) 
+		c <- newConfig name sameasuuid
+			(Logs.Remote.keyValToConfig Proposed ws)
+			<$> remoteConfigMap
+		t <- either giveup return (findType c)
+		a c t
+	
+	si = SeekInput (name:ws)
+	ai = ActionItemOther (Just (UnquotedString name))
+
+perform :: RemoteType -> String -> R.RemoteConfig -> InitRemoteOptions -> CommandPerform
+perform t name c o = do
+	when (privateRemote o) $
+		setConfig (remoteAnnexConfig c "private") (boolConfig True)
+	dummycfg <- liftIO dummyRemoteGitConfig
+	let c' = M.delete uuidField c
+	(c'', u) <- R.setup t R.Init (sameasu <|> uuidfromuser) Nothing c' dummycfg
+	next $ cleanup t u name c'' o
+  where
+	uuidfromuser = case fromProposedAccepted <$> M.lookup uuidField c of
+		Just s
+			| isUUID s -> Just (toUUID s)
+			| otherwise -> giveup "invalid uuid"
+		Nothing -> Nothing
+	sameasu = toUUID . fromProposedAccepted <$> M.lookup sameasUUIDField c
+
+uuidField :: R.RemoteConfigField
+uuidField = Accepted "uuid"
+
+cleanup :: RemoteType -> UUID -> String -> R.RemoteConfig -> InitRemoteOptions -> CommandCleanup
+cleanup t u name c o = do
+	case sameas o of
+		Nothing -> do
+			describeUUID u (toUUIDDesc name)
+			Logs.Remote.configSet u c
+		Just _ -> do
+			cu <- liftIO genUUID
+			setConfig (remoteAnnexConfig c "config-uuid") (fromUUID cu)
+			Logs.Remote.configSet cu c
+	unless (Remote.gitSyncableRemoteType t) $
+		setConfig (remoteConfig c "skipFetchAll") (boolConfig True)
+	return True
+
+describeOtherParamsFor :: RemoteConfig -> RemoteType -> CommandPerform
+describeOtherParamsFor c t = do
+	cp <- R.configParser t c
+	let l = map mk (filter notinconfig $ remoteConfigFieldParsers cp)
+		++ map mk' (maybe [] snd (remoteConfigRestPassthrough cp))
+	ifM jsonOutputEnabled
+		( maybeAddJSONField "whatelse" $ M.fromList $ mkjson l
+		, liftIO $ forM_ l $ \(p, fd, vd) -> case fd of
+			HiddenField -> return ()
+			FieldDesc d -> do
+				putStrLn p
+				putStrLn ("\t" ++ d)
+				case vd of
+					Nothing -> return ()
+					Just (ValueDesc d') ->
+						putStrLn $ "\t(" ++ d' ++ ")"
+		
+		)
+	next $ return True
+  where
+	mkjson = mapMaybe $ \(p, fd, vd) ->
+		case fd of
+			HiddenField -> Nothing
+			FieldDesc d -> Just 
+				( T.pack p
+				, M.fromList
+					[ ("description" :: T.Text, d)
+					, ("valuedescription", case vd of
+						Nothing -> ""
+						Just (ValueDesc d') -> d')
+					]
+				)
+
+	notinconfig fp = not (M.member (parserForField fp) c)
+
+	mk fp = ( fromProposedAccepted (parserForField fp)
+		, fieldDesc fp
+		, valueDesc fp
+		)
+	mk' (k, v) = (k, v, Nothing)
diff --git a/Command/Inprogress.hs b/Command/Inprogress.hs
new file mode 100644
index 0000000000..7b5f1482ea
--- /dev/null
+++ b/Command/Inprogress.hs
@@ -0,0 +1,64 @@
+{- git-annex command
+ -
+ - Copyright 2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Inprogress where
+
+import Command
+import Annex.Transfer
+import Utility.Terminal
+import Utility.SafeOutput
+
+import qualified Data.Set as S
+
+cmd :: Command
+cmd = noCommit $ noMessages $ command "inprogress" SectionQuery
+		"access files while they're being downloaded"
+		paramPaths (seek <$$> optParser)
+
+data InprogressOptions = InprogressOptions
+	{ inprogressFiles :: CmdParams
+	, keyOptions :: Maybe KeyOptions
+	}
+
+optParser :: CmdParamsDesc -> Parser InprogressOptions
+optParser desc = InprogressOptions
+	<$> cmdParams desc
+	<*> optional (parseAllOption <|> parseSpecificKeyOption)
+
+seek :: InprogressOptions -> CommandSeek
+seek o = do
+	isterminal <- liftIO $ checkIsTerminal stdout
+	ts <- map (transferKey . fst) <$> getTransfers
+	case keyOptions o of
+		Just WantAllKeys ->
+			forM_ ts $ commandAction . (start' isterminal)
+		Just (WantSpecificKey k)
+			| k `elem` ts -> commandAction (start' isterminal k)
+			| otherwise -> commandAction stop
+		_ -> do
+			let s = S.fromList ts
+			let seeker = AnnexedFileSeeker
+				{ startAction = const $ start isterminal s
+				, checkContentPresent = Nothing
+				, usesLocationLog = False
+				}
+			withFilesInGitAnnex ww seeker
+				=<< workTreeItems ww (inprogressFiles o)
+  where
+	ww = WarnUnmatchLsFiles "inprogress"
+
+start :: IsTerminal -> S.Set Key -> SeekInput -> RawFilePath -> Key -> CommandStart
+start isterminal s _si _file k
+	| S.member k s = start' isterminal k
+	| otherwise = stop
+
+start' :: IsTerminal -> Key -> CommandStart
+start' (IsTerminal isterminal) k = startingCustomOutput k $ do
+	tmpf <- fromRawFilePath <$> fromRepo (gitAnnexTmpObjectLocation k)
+	whenM (liftIO $ doesFileExist tmpf) $
+		liftIO $ putStrLn (if isterminal then safeOutput tmpf else tmpf)
+	next $ return True
diff --git a/Command/List.hs b/Command/List.hs
new file mode 100644
index 0000000000..46185e6092
--- /dev/null
+++ b/Command/List.hs
@@ -0,0 +1,109 @@
+{- git-annex command
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ - Copyright 2013 Antoine Beaupré
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.List where
+
+import qualified Data.Set as S
+import qualified Data.Map as M
+import Data.Function
+import Data.Ord
+import qualified Data.ByteString.Char8 as B8
+
+import Command
+import Remote
+import qualified Annex
+import Logs.Trust
+import Logs.UUID
+import Annex.UUID
+import Git.Types (RemoteName)
+import Utility.Tuple
+import Utility.SafeOutput
+
+cmd :: Command
+cmd = noCommit $ withAnnexOptions [annexedMatchingOptions] $
+	command "list" SectionQuery 
+		"show which remotes contain files"
+		paramPaths (seek <$$> optParser)
+
+data ListOptions = ListOptions
+	{ listThese :: CmdParams
+	, allRepos :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser ListOptions
+optParser desc = ListOptions
+	<$> cmdParams desc
+	<*> switch
+		( long "allrepos"
+		<> help "show all repositories, not only remotes"
+		)
+
+seek :: ListOptions -> CommandSeek
+seek o = do
+	list <- getList o
+	printHeader list
+	let seeker = AnnexedFileSeeker
+		{ startAction = const $ start list
+		, checkContentPresent = Nothing
+		, usesLocationLog = True
+		}
+	withFilesInGitAnnex ww seeker =<< workTreeItems ww (listThese o)
+  where
+	ww = WarnUnmatchLsFiles "list"
+
+getList :: ListOptions -> Annex [(UUID, RemoteName, TrustLevel)]
+getList o
+	| allRepos o = nubBy ((==) `on` fst3) <$> ((++) <$> getRemotes <*> getAllUUIDs)
+	| otherwise = getRemotes
+  where
+	getRemotes = do
+		rs <- remoteList
+		ts <- mapM (lookupTrust . uuid) rs
+		hereu <- getUUID
+		heretrust <- lookupTrust hereu
+		let l = (hereu, "here", heretrust) : zip3 (map uuid rs) (map name rs) ts
+		return $ filter (\(_, _, t) -> t /= DeadTrusted) l 
+	getAllUUIDs = do
+		rs <- M.toList <$> uuidDescMap
+		rs3 <- forM rs $ \(u, d) -> (,,)
+			<$> pure u
+			<*> pure (fromUUIDDesc d)
+			<*> lookupTrust u
+		return $ sortBy (comparing snd3) $
+			filter (\t -> thd3 t /= DeadTrusted) rs3
+
+printHeader :: [(UUID, RemoteName, TrustLevel)] -> Annex ()
+printHeader l = liftIO $ putStrLn $ safeOutput $ lheader $ map (\(_, n, t) -> (n, t)) l
+
+start :: [(UUID, RemoteName, TrustLevel)] -> SeekInput -> RawFilePath -> Key -> CommandStart
+start l _si file key = do
+	ls <- S.fromList <$> keyLocations key
+	qp <- coreQuotePath <$> Annex.getGitConfig
+	liftIO $ B8.putStrLn $ quote qp $
+		format (map (\(u, _, t) -> (t, S.member u ls)) l) file
+	stop
+
+type Present = Bool
+
+lheader :: [(RemoteName, TrustLevel)] -> String
+lheader remotes = unlines (zipWith formatheader [0..] remotes) ++ pipes (length remotes)
+  where
+	formatheader n (remotename, trustlevel) = pipes n ++ remotename ++ trust trustlevel
+	pipes = flip replicate '|'
+	trust UnTrusted = " (untrusted)"
+	trust _ = ""
+
+format :: [(TrustLevel, Present)] -> RawFilePath -> StringContainingQuotedPath
+format remotes file = UnquotedString (thereMap) <> " " <> QuotedPath file
+  where 
+	thereMap = concatMap there remotes
+	there (UnTrusted, True) = "x"
+	there (_, True) = "X"
+	there (_, False) = "_"
diff --git a/Command/Lock.hs b/Command/Lock.hs
new file mode 100644
index 0000000000..cfd0846cd5
--- /dev/null
+++ b/Command/Lock.hs
@@ -0,0 +1,104 @@
+{- git-annex command
+ -
+ - Copyright 2010,2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Lock where
+
+import Command
+import qualified Annex
+import Annex.Content
+import Annex.Link
+import Annex.InodeSentinal
+import Annex.Perms
+import Annex.ReplaceFile
+import Utility.InodeCache
+import qualified Database.Keys
+import Annex.Ingest
+import Logs.Location
+import Git.FilePath
+import qualified Utility.RawFilePath as R
+
+import System.PosixCompat.Files (linkCount)
+	
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions, annexedMatchingOptions] $
+	command "lock" SectionCommon
+		"undo unlock command"
+		paramPaths (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek ps = withFilesInGitAnnex ww seeker =<< workTreeItems ww ps
+  where
+	ww = WarnUnmatchLsFiles "lock"
+	seeker = AnnexedFileSeeker
+		{ startAction = const start
+		, checkContentPresent = Nothing
+		, usesLocationLog = False
+		}
+
+start :: SeekInput -> RawFilePath -> Key -> CommandStart
+start si file key = ifM (isJust <$> isAnnexLink file)
+	( stop
+	, starting "lock" (mkActionItem (key, file)) si $
+		go =<< liftIO (isPointerFile file)
+	)
+  where
+	go (Just key')
+		| key' == key = cont
+		| otherwise = errorModified
+	go Nothing = 
+		ifM (isUnmodified key file)
+			( cont
+			, ifM (Annex.getRead Annex.force)
+				( cont
+				, errorModified
+				)
+			)
+	cont = perform file key
+
+perform :: RawFilePath -> Key -> CommandPerform
+perform file key = do
+	lockdown =<< calcRepo (gitAnnexLocation key)
+	addSymlink file key =<< withTSDelta (liftIO . genInodeCache file)
+	next $ return True
+  where
+	lockdown obj = do
+		ifM (isUnmodified key obj)
+			( breakhardlink obj
+			, repopulate obj
+			)
+		whenM (liftIO $ R.doesPathExist obj) $
+			freezeContent obj
+
+	-- It's ok if the file is hard linked to obj, but if some other
+	-- associated file is, we need to break that link to lock down obj.
+	breakhardlink obj = whenM (catchBoolIO $ (> 1) . linkCount <$> liftIO (R.getFileStatus obj)) $ do
+		mfc <- withTSDelta (liftIO . genInodeCache file)
+		unlessM (sameInodeCache obj (maybeToList mfc)) $ do
+			modifyContentDir obj $ replaceGitAnnexDirFile (fromRawFilePath obj) $ \tmp -> do
+				unlessM (checkedCopyFile key obj tmp Nothing) $
+					giveup "unable to lock file"
+			Database.Keys.storeInodeCaches key [obj]
+
+	-- Try to repopulate obj from an unmodified associated file.
+	repopulate obj = modifyContentDir obj $ do
+		g <- Annex.gitRepo
+		fs <- map (`fromTopFilePath` g)
+			<$> Database.Keys.getAssociatedFiles key
+		mfile <- firstM (isUnmodified key) fs
+		liftIO $ removeWhenExistsWith R.removeLink obj
+		case mfile of
+			Just unmodified ->
+				ifM (checkedCopyFile key unmodified obj Nothing)
+					( Database.Keys.storeInodeCaches key [obj]
+					, lostcontent
+					)
+			Nothing -> lostcontent
+
+	lostcontent = logStatus key InfoMissing
+
+errorModified :: a
+errorModified =  giveup "Locking this file would discard any changes you have made to it. Use 'git annex add' to stage your changes. (Or, use --force to override)"
diff --git a/Command/Log.hs b/Command/Log.hs
new file mode 100644
index 0000000000..149b099dd5
--- /dev/null
+++ b/Command/Log.hs
@@ -0,0 +1,529 @@
+{- git-annex command
+ -
+ - Copyright 2012-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, BangPatterns #-}
+
+module Command.Log where
+
+import qualified Data.Set as S
+import qualified Data.Map as M
+import Data.Char
+import Data.Time.Clock.POSIX
+import Data.Time
+import qualified Data.ByteString.Char8 as B8
+import qualified System.FilePath.ByteString as P
+import Control.Concurrent.Async
+
+import Command
+import Logs
+import Logs.Location
+import Logs.UUID
+import qualified Logs.Presence.Pure as PLog
+import Logs.Trust.Pure (parseTrustLog)
+import Logs.UUIDBased (simpleMap)
+import qualified Annex
+import qualified Annex.Branch
+import qualified Remote
+import qualified Git
+import Git.Log
+import Git.CatFile
+import Types.TrustLevel
+import Utility.DataUnits
+import Utility.HumanTime
+
+data LogChange = Added | Removed
+
+type Outputter = LogChange -> POSIXTime -> [UUID] -> Annex ()
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions, annexedMatchingOptions] $
+	command "log" SectionQuery "shows location log"
+		paramPaths (seek <$$> optParser)
+
+data LogOptions = LogOptions
+	{ logFiles :: CmdParams
+	, allOption :: Bool
+	, sizesOfOption :: Maybe (DeferredParse UUID)
+	, sizesOption :: Bool
+	, totalSizesOption :: Bool
+	, intervalOption :: Maybe Duration
+	, receivedOption :: Bool
+	, gnuplotOption :: Bool
+	, rawDateOption :: Bool
+	, bytesOption :: Bool
+	, gourceOption :: Bool
+	, passthruOptions :: [CommandParam]
+	}
+
+optParser :: CmdParamsDesc -> Parser LogOptions
+optParser desc = LogOptions
+	<$> cmdParams desc
+	<*> switch
+		( long "all"
+		<> short 'A'
+		<> help "display location log changes to all files"
+		)
+	<*> optional ((parseUUIDOption <$> strOption
+		( long "sizesof"
+		<> metavar (paramRemote `paramOr` paramDesc `paramOr` paramUUID)
+		<> help "display history of sizes of this repository"
+		<> completeRemotes
+		)))
+	<*> switch
+		( long "sizes"
+		<> help "display history of sizes of all repositories"
+		)
+	<*> switch
+		( long "totalsizes"
+		<> help "display history of total sizes of all repositories"
+		)
+	<*> optional (option (eitherReader parseDuration)
+		( long "interval" <> metavar paramTime
+		<> help "minimum time between displays of changed size"
+		))
+	<*> switch
+		( long "received"
+		<> help "display received data per interval rather than repository sizes"
+		)
+	<*> switch
+		( long "gnuplot"
+		<> help "graph the history"
+		)
+	<*> switch
+		( long "raw-date"
+		<> help "display seconds from unix epoch"
+		)
+	<*> switch
+		( long "bytes"
+		<> help "display sizes in bytes"
+		)
+	<*> switch
+		( long "gource"
+		<> help "format output for gource"
+		)
+	<*> (concat <$> many passthru)
+  where
+	passthru :: Parser [CommandParam]
+	passthru = datepassthru "since"
+		<|> datepassthru "after"
+		<|> datepassthru "until"
+		<|> datepassthru "before"
+		<|> (mkpassthru "max-count" <$> strOption
+			( long "max-count" <> metavar paramNumber
+			<> help "limit number of logs displayed"
+			))
+	datepassthru n = mkpassthru n <$> strOption
+		( long n <> metavar paramDate
+		<> help ("show log " ++ n ++ " date")
+		)
+	mkpassthru n v = [Param ("--" ++ n), Param v]
+
+seek :: LogOptions -> CommandSeek
+seek o = ifM (null <$> Annex.Branch.getUnmergedRefs)
+	( maybe (pure Nothing) (Just <$$> getParsed) (sizesOfOption o) >>= \case
+		Just u -> sizeHistoryInfo (Just u) o
+		Nothing -> if sizesOption o || totalSizesOption o
+			then sizeHistoryInfo Nothing o
+			else go	
+	, giveup "This repository is read-only, and there are unmerged git-annex branches, which prevents displaying location log changes. (Set annex.merge-annex-branches to false to ignore the unmerged git-annex branches.)"
+	)
+  where
+	ww = WarnUnmatchLsFiles "log"
+	go = do
+		m <- Remote.uuidDescriptions
+		zone <- liftIO getCurrentTimeZone
+		outputter <- mkOutputter m zone o <$> jsonOutputEnabled
+		let seeker = AnnexedFileSeeker
+			{ startAction = const $ start o outputter
+			, checkContentPresent = Nothing
+			-- the way this uses the location log would not be
+			-- helped by precaching the current value
+			, usesLocationLog = False
+			}
+		case (logFiles o, allOption o) of
+			(fs, False) -> withFilesInGitAnnex ww seeker
+				=<< workTreeItems ww fs
+			([], True) -> commandAction (startAll o outputter)
+			(_, True) -> giveup "Cannot specify both files and --all"
+
+start :: LogOptions -> (ActionItem -> SeekInput -> Outputter) -> SeekInput -> RawFilePath -> Key -> CommandStart
+start o outputter si file key = do
+	(changes, cleanup) <- getKeyLog key (passthruOptions o)
+	let ai = mkActionItem (file, key)
+	showLogIncremental (outputter ai si) changes
+	void $ liftIO cleanup
+	stop
+
+startAll :: LogOptions -> (ActionItem -> SeekInput -> Outputter) -> CommandStart
+startAll o outputter = do
+	(changes, cleanup) <- getGitLogAnnex [] (passthruOptions o)
+	showLog (\ai -> outputter ai (SeekInput [])) changes
+	void $ liftIO cleanup
+	stop
+
+{- Displays changes made. Only works when all the LoggedFileChanges are for the
+ - same key. The method is to compare each value with the value
+ - after it in the list, which is the old version of the value.
+ -
+ - This ncessarily buffers the whole list, so does not stream.
+ - But, the number of location log changes for a single key tends to be
+ - fairly small.
+ -
+ - This minimizes the number of reads from git; each logged value is read
+ - only once.
+ -
+ - This also generates subtly better output when the git-annex branch
+ - got diverged.
+ -}
+showLogIncremental :: Outputter -> [LoggedFileChange Key] -> Annex ()
+showLogIncremental outputter ps = do
+	sets <- mapM (getset newref) ps
+	previous <- maybe (return genesis) (getset oldref) (lastMaybe ps)
+	let l = sets ++ [previous]
+	let changes = map (\((t, new), (_, old)) -> (t, new, old))
+		(zip l (drop 1 l))
+	sequence_ $ compareChanges outputter changes
+  where
+	genesis = (0, S.empty)
+	getset select change = do
+		s <- S.fromList <$> loggedLocationsRef (select change)
+		return (changetime change, s)
+
+{- Displays changes made. Streams, and can display changes affecting
+ - different keys, but does twice as much reading of logged values
+ - as showLogIncremental. -}
+showLog :: (ActionItem -> Outputter) -> [LoggedFileChange Key] -> Annex ()
+showLog outputter cs = forM_ cs $ \c -> do
+	let ai = mkActionItem (changed c)
+	new <- S.fromList <$> loggedLocationsRef (newref c)
+	old <- S.fromList <$> loggedLocationsRef (oldref c)
+	sequence_ $ compareChanges (outputter ai)
+		[(changetime c, new, old)]
+
+mkOutputter :: UUIDDescMap -> TimeZone -> LogOptions -> Bool -> ActionItem -> SeekInput -> Outputter
+mkOutputter m zone o jsonenabled ai si
+	| jsonenabled = jsonOutput m ai si
+	| rawDateOption o = normalOutput lookupdescription ai rawTimeStamp
+	| gourceOption o = gourceOutput lookupdescription ai 
+	| otherwise = normalOutput lookupdescription ai (showTimeStamp zone rfc822DateFormat)
+  where
+	lookupdescription u = maybe (fromUUID u) (fromUUIDDesc) (M.lookup u m)
+
+normalOutput :: (UUID -> String) -> ActionItem -> (POSIXTime -> String) -> Outputter
+normalOutput lookupdescription ai formattime logchange ts us = do
+	qp <- coreQuotePath <$> Annex.getGitConfig
+	liftIO $ mapM_ (B8.putStrLn . quote qp . format) us
+  where
+	time = formattime ts
+	addel = case logchange of
+		Added -> "+"
+		Removed -> "-"
+	format u = UnquotedString addel <> " " 
+		<> UnquotedString time <> " " 
+		<> actionItemDesc ai <> " | " 
+		<> UnquotedByteString (fromUUID u) <> " -- "
+		<> UnquotedString (lookupdescription u)
+
+jsonOutput :: UUIDDescMap -> ActionItem -> SeekInput -> Outputter
+jsonOutput m ai si logchange ts us = do
+	showStartMessage $ StartMessage "log" ai si
+	maybeShowJSON $ JSONChunk
+		[ ("logged", case logchange of
+			Added -> "addition"
+			Removed -> "removal")
+		, ("date", rawTimeStamp ts)
+		]
+	void $ Remote.prettyPrintUUIDsDescs "locations" m us
+	showEndOk
+
+gourceOutput :: (UUID -> String) -> ActionItem -> Outputter
+gourceOutput lookupdescription ai logchange ts us =
+	liftIO $ mapM_ (putStrLn . intercalate "|" . format) us
+  where
+	time = takeWhile isDigit $ show ts
+	addel = case logchange of
+		Added -> "A" 
+		Removed -> "M"
+	format u =
+		[ time
+		, lookupdescription u
+		, addel
+		, decodeBS (noquote (actionItemDesc ai))
+		]
+
+{- Generates a display of the changes.
+ - Uses a formatter to generate a display of items that are added and
+ - removed. -}
+compareChanges :: Ord a => (LogChange -> POSIXTime -> [a] -> b) -> [(POSIXTime, S.Set a, S.Set a)] -> [b]
+compareChanges format changes = concatMap diff changes
+  where
+	diff (ts, new, old)
+		| new == old = []
+		| otherwise = 
+			[ format Added ts   $ S.toList $ S.difference new old
+			, format Removed ts $ S.toList $ S.difference old new
+			]
+
+{- Streams the git log for a given key's location log file.
+ -
+ - This is complicated by git log using paths relative to the current
+ - directory, even when looking at files in a different branch. A wacky
+ - relative path to the log file has to be used.
+ -
+ - The --remove-empty is a significant optimisation. It relies on location
+ - log files never being deleted in normal operation. Letting git stop
+ - once the location log file is gone avoids it checking all the way back
+ - to commit 0 to see if it used to exist, so generally speeds things up a
+ - *lot* for newish files. -}
+getKeyLog :: Key -> [CommandParam] -> Annex ([LoggedFileChange Key], IO Bool)
+getKeyLog key os = do
+	top <- fromRepo Git.repoPath
+	p <- liftIO $ relPathCwdToFile top
+	config <- Annex.getGitConfig
+	let logfile = p P.</> locationLogFile config key
+	getGitLogAnnex [fromRawFilePath logfile] (Param "--remove-empty" : os)
+
+getGitLogAnnex :: [FilePath] -> [CommandParam] -> Annex ([LoggedFileChange Key], IO Bool)
+getGitLogAnnex fs os = do
+	config <- Annex.getGitConfig
+	let fileselector = \_sha f ->
+		locationLogFileKey config (toRawFilePath f)
+	inRepo $ getGitLog Annex.Branch.fullname Nothing fs os fileselector
+
+showTimeStamp :: TimeZone -> String -> POSIXTime -> String
+showTimeStamp zone format = formatTime defaultTimeLocale format
+	. utcToZonedTime zone . posixSecondsToUTCTime
+
+rawTimeStamp :: POSIXTime -> String
+rawTimeStamp t = filter (/= 's') (show t)
+
+sizeHistoryInfo :: (Maybe UUID) -> LogOptions -> Annex ()
+sizeHistoryInfo mu o = do
+	uuidmap <- getuuidmap
+	zone <- liftIO getCurrentTimeZone
+	dispst <- displaystart uuidmap zone
+	(l, cleanup) <- getlog
+	g <- Annex.gitRepo
+	liftIO $ catObjectStream g $ \feeder closer reader -> do
+		tid <- async $ do
+			forM_ l $ \c -> 
+				feeder ((changed c, changetime c), newref c)
+			closer
+		go reader mempty mempty mempty uuidmap dispst
+		wait tid
+	void $ liftIO cleanup
+  where
+	-- Go through the log of the git-annex branch in reverse,
+	-- and in date order, and pick out changes to location log files
+	-- and to the trust log.
+	getlog = do
+		config <- Annex.getGitConfig
+		let fileselector = \_sha f -> let f' = toRawFilePath f in
+			case locationLogFileKey config f' of
+				Just k -> Just (Right k)
+				Nothing
+					| f' == trustLog -> Just (Left ())
+					| otherwise -> Nothing
+		inRepo $ getGitLog Annex.Branch.fullname Nothing []
+			[ Param "--date-order"
+			, Param "--reverse"
+			]
+			fileselector
+
+	go reader sizemap locmap trustlog uuidmap dispst = reader >>= \case
+		Just ((Right k, t), Just logcontent) -> do
+			let !newlog = parselocationlog logcontent uuidmap
+			let !(sizemap', locmap') = case M.lookup k locmap of
+				Nothing -> addnew k sizemap locmap newlog
+				Just v -> update k sizemap locmap v newlog
+			dispst' <- displaysizes dispst trustlog uuidmap sizemap' t
+			go reader sizemap' locmap' trustlog uuidmap dispst'
+		Just ((Left (), t), Just logcontent) -> do
+			let !trustlog' = trustlog <> parseTrustLog logcontent
+			dispst' <- displaysizes dispst trustlog' uuidmap sizemap t
+			go reader sizemap locmap trustlog' uuidmap dispst'
+		Just (_, Nothing) -> 
+			go reader sizemap locmap trustlog uuidmap dispst
+		Nothing -> 
+			displayend dispst
+
+	-- Known uuids are stored in this map, and when uuids are stored in the
+	-- state, it's a value from this map. This avoids storing multiple
+	-- copies of the same uuid in memory.
+	getuuidmap = do
+		(us, ds) <- unzip . M.toList <$> uuidDescMap
+		return $ M.fromList (zip us (zip us ds))
+	
+	-- Parses a location log file, and replaces the logged uuid
+	-- with one from the uuidmap.
+	parselocationlog logcontent uuidmap = 
+		map replaceuuid $ PLog.parseLog logcontent
+	  where
+		replaceuuid ll = 
+			let !u = toUUID $ PLog.fromLogInfo $ PLog.info ll
+			    !ushared = maybe u fst $ M.lookup u uuidmap
+			in ll { PLog.info = PLog.LogInfo (fromUUID ushared) }
+
+	presentlocs = map (toUUID . PLog.fromLogInfo . PLog.info)
+		. PLog.filterPresent
+	
+	-- Since the git log is being traversed in date order, commits
+	-- from different branches can appear one after the other, and so
+	-- the newlog is not necessarily the complete state known at that
+	-- time across all git-annex repositories.
+	--
+	-- This combines the new location log with what has been
+	-- accumulated so far, which is equivilant to merging together
+	-- all git-annex branches at that point in time.
+	update k sizemap locmap (oldlog, oldlocs) newlog = 
+		( updatesize (updatesize sizemap sz (S.toList addedlocs))
+			(negate sz) (S.toList removedlocs)
+		, M.insert k (combinedlog, combinedlocs) locmap
+		)
+	  where
+		sz = ksz k
+		combinedlog = PLog.compactLog (oldlog ++ newlog)
+		combinedlocs = S.fromList (presentlocs combinedlog)
+		addedlocs = S.difference combinedlocs oldlocs
+		removedlocs
+			| receivedOption o = S.empty
+			| otherwise = S.difference oldlocs combinedlocs
+	
+	addnew k sizemap locmap newlog = 
+		( updatesize sizemap (ksz k) locs
+		, M.insert k (newlog, S.fromList locs) locmap
+		)
+	  where
+		locs = presentlocs newlog
+	
+	ksz k = fromMaybe 0 (fromKey keySize k)
+	
+	updatesize sizemap _ [] = sizemap
+	updatesize sizemap sz (l:ls) =
+		updatesize (M.insertWith (+) l sz sizemap) sz ls
+
+	epoch = toEnum 0
+
+	displaystart uuidmap zone
+		| gnuplotOption o = do
+			file <- (</>)
+				<$> fromRepo (fromRawFilePath . gitAnnexDir)
+				<*> pure "gnuplot"
+			liftIO $ putStrLn $ "Generating gnuplot script in " ++ file
+			h <- liftIO $ openFile file WriteMode
+			liftIO $ mapM_ (hPutStrLn h)
+				[ "set datafile separator ','"
+				, "set timefmt \"%Y-%m-%dT%H:%M:%S\""
+				, "set xdata time"
+				, "set xtics out"
+				, "set ytics format '%s%c'"
+				, "set tics front"
+				, "set key spacing 1 font \",8\""
+				]
+			unless (sizesOption o) $
+				liftIO $ hPutStrLn h "set key off"
+			liftIO $ hPutStrLn h "$data << EOD"
+			liftIO $ hPutStrLn h $ if sizesOption o
+				then uuidmapheader
+				else csvheader ["value"]
+			let endaction = do
+				mapM_ (hPutStrLn h)
+					[ "EOD"
+					, ""
+					, "plot for [i=2:" ++ show ncols ++ ":1] \\"
+					, "  \"$data\" using 1:(sum [col=i:" ++ show ncols ++ "] column(col)) \\"
+					, "  title columnheader(i) \\"
+					, if receivedOption o
+						then "  with boxes"
+						else "  with filledcurves x1"
+					]
+				hFlush h
+				putStrLn $ "Running gnuplot..."
+				void $ liftIO $ boolSystem "gnuplot"
+					[Param "-p", File file]
+			return (dispst h endaction)
+		| sizesOption o = do
+			liftIO $ putStrLn uuidmapheader
+			return (dispst stdout noop)
+		| otherwise = return (dispst stdout noop)
+	  where
+		dispst fileh endaction = 
+			(zone, False, epoch, Nothing, mempty, fileh, endaction)
+		ncols
+			| sizesOption o = 1 + length (M.elems uuidmap)
+			| otherwise = 2
+		uuidmapheader = csvheader $
+			map (fromUUIDDesc . snd) (M.elems uuidmap)
+
+	displaysizes (zone, displayedyet, prevt, prevoutput, prevsizemap, h, endaction) trustlog uuidmap sizemap t
+		| t - prevt >= dt && changedoutput = do
+			displayts zone t output h
+			return (zone, True, t, Just output, sizemap', h, endaction)
+		| t < prevt = return (zone, displayedyet, t, Just output, prevsizemap, h, endaction)
+		| otherwise = return (zone, displayedyet, prevt, prevoutput, prevsizemap, h, endaction)
+	  where
+		output = intercalate "," (map showsize sizes)
+		us = case mu of
+			Just u -> [u]
+			Nothing -> M.keys uuidmap
+		sizes
+			| totalSizesOption o = [sum (M.elems sizedisplaymap)]
+			| otherwise = map (\u -> fromMaybe 0 (M.lookup u sizedisplaymap)) us
+		dt = maybe 1 durationToPOSIXTime (intervalOption o)
+
+		changedoutput
+			| receivedOption o = 
+				any (/= 0) sizes 
+					|| prevoutput /= Just output
+			| otherwise = 
+				(displayedyet || any (/= 0) sizes)
+					&& (prevoutput /= Just output)
+
+		sizedisplaymap
+			| receivedOption o = 
+				M.unionWith posminus sizemap' prevsizemap
+			| otherwise = sizemap'
+
+		posminus a b = max 0 (a - b)
+
+		-- A verison of sizemap where uuids that are currently dead
+		-- have 0 size.
+		sizemap' = M.mapWithKey zerodead sizemap
+		zerodead u v = case M.lookup u (simpleMap trustlog) of
+			Just DeadTrusted -> 0
+			_ -> v
+
+	displayts zone t output h = do
+		hPutStrLn h (ts ++ "," ++ output)
+		hFlush h
+	  where
+		ts = if rawDateOption o && not (gnuplotOption o)
+			then rawTimeStamp t
+			else showTimeStamp zone "%Y-%m-%dT%H:%M:%S" t
+
+	displayend dispst@(_, _, _, _, _, _, endaction) = do
+		displayendsizes dispst
+		endaction
+
+	displayendsizes (zone, _, _, Just output, _, h, _) = do
+		now <- getPOSIXTime
+		displayts zone now output h
+	displayendsizes _ = return ()
+
+	showsize n
+		| bytesOption o || gnuplotOption o = show n
+		| otherwise = roughSize storageUnits True n
+	
+	csvquote s
+		| ',' `elem` s || '"' `elem` s = 
+			'"' : concatMap escquote s ++ ['"']
+		| otherwise = s
+	  where
+		escquote '"' = "\"\""
+		escquote c = [c]
+	
+	csvheader l = intercalate "," ("date" : map csvquote l)
diff --git a/Command/LookupKey.hs b/Command/LookupKey.hs
new file mode 100644
index 0000000000..f191aa1e8b
--- /dev/null
+++ b/Command/LookupKey.hs
@@ -0,0 +1,62 @@
+{- git-annex command
+ -
+ - Copyright 2013-2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.LookupKey where
+
+import Command
+import Annex.CatFile
+import qualified Git.LsFiles
+import Git.Types
+import Utility.Terminal
+import Utility.SafeOutput
+
+cmd :: Command
+cmd = notBareRepo $ noCommit $ noMessages $
+	command "lookupkey" SectionPlumbing 
+		"looks up key used for file"
+		(paramRepeating paramFile)
+		(batchable run optParser)
+
+data LookupKeyOptions = LookupKeyOptions
+	{ refOption :: Bool
+	}
+
+optParser :: Parser LookupKeyOptions
+optParser = LookupKeyOptions
+	<$> switch
+		( long "ref"
+		<> help "look up key used by git ref to file"
+		)
+
+run :: LookupKeyOptions -> SeekInput -> String -> Annex Bool
+run o _ file
+	| refOption o = catKey (Ref (toRawFilePath file)) >>= display
+	| otherwise = seekSingleGitFile file >>= \case
+		Nothing -> return False
+		Just file' -> catKeyFile file' >>= display
+
+display :: Maybe Key -> Annex Bool
+display (Just k) = do
+	IsTerminal isterminal <- liftIO $ checkIsTerminal stdout
+	let sk = serializeKey k
+	liftIO $ putStrLn $ if isterminal then safeOutput sk else sk
+	return True
+display Nothing = return False
+
+-- To support absolute filenames, pass through git ls-files.
+-- But, this plumbing command does not recurse through directories.
+seekSingleGitFile :: FilePath -> Annex (Maybe RawFilePath)
+seekSingleGitFile file
+	| isRelative file = return (Just (toRawFilePath file))
+	| otherwise = do
+		(l, cleanup) <- inRepo (Git.LsFiles.inRepo [] [toRawFilePath file])
+		r <- case l of
+			(f:[]) | takeFileName (fromRawFilePath f) == takeFileName file ->
+				return (Just f)
+			_ -> return Nothing
+		void $ liftIO cleanup
+		return r
diff --git a/Command/Map.hs b/Command/Map.hs
new file mode 100644
index 0000000000..2ea732ac5d
--- /dev/null
+++ b/Command/Map.hs
@@ -0,0 +1,289 @@
+{- git-annex command
+ -
+ - Copyright 2010 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Map where
+
+import qualified Data.Map as M
+
+import Command
+import qualified Git
+import qualified Git.Url
+import qualified Git.Config
+import qualified Git.Construct
+import qualified Remote
+import qualified Annex
+import Annex.Ssh
+import Annex.UUID
+import Logs.UUID
+import Logs.Trust
+import Types.TrustLevel
+import qualified Remote.Helper.Ssh as Ssh
+import qualified Utility.Dot as Dot
+
+-- a link from the first repository to the second (its remote)
+data Link = Link Git.Repo Git.Repo
+
+-- a repo and its remotes
+type RepoRemotes = (Git.Repo, [Git.Repo])
+
+cmd :: Command
+cmd = dontCheck repoExists $
+	command "map" SectionQuery
+		"generate map of repositories"
+		paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = startingNoMessage (ActionItemOther Nothing) $ do
+	rs <- combineSame <$> (spider =<< gitRepo)
+
+	umap <- uuidDescMap
+	trustmap <- trustMapLoad
+		
+	file <- (</>)
+		<$> fromRepo (fromRawFilePath . gitAnnexDir)
+		<*> pure "map.dot"
+
+	liftIO $ writeFile file (drawMap rs trustmap umap)
+	next $
+		ifM (Annex.getRead Annex.fast)
+			( runViewer file []
+			, runViewer file
+	 			[ ("xdot", [File file])
+				, ("dot", [Param "-Tx11", File file])
+				]	
+			)
+
+runViewer :: FilePath -> [(String, [CommandParam])] -> Annex Bool
+runViewer file [] = do
+	showLongNote $ UnquotedString $ "left map in " ++ file
+	return True
+runViewer file ((c, ps):rest) = ifM (liftIO $ inSearchPath c)
+	( do
+		showLongNote $ UnquotedString $ "running: " ++ c ++ unwords (toCommand ps)
+		showOutput
+		liftIO $ boolSystem c ps
+	, runViewer file rest
+	)
+
+{- Generates a graph for dot(1). Each repository, and any other uuids
+ - (except for dead ones), are displayed as a node, and each of its
+ - remotes is represented as an edge pointing at the node for the remote.
+ -
+ - The order nodes are added to the graph matters, since dot will draw
+ - the first ones near to the top and left. So it looks better to put
+ - the repositories first, followed by uuids that were not matched
+ - to a repository.
+ -}
+drawMap :: [RepoRemotes] -> TrustMap -> UUIDDescMap -> String
+drawMap rs trustmap umap = Dot.graph $ repos ++ others
+  where
+	repos = map (node umap (map fst rs) trustmap) rs
+	ruuids = map (getUncachedUUID . fst) rs
+	others = map uuidnode $ 
+		filter (\u -> M.lookup u trustmap /= Just DeadTrusted) $
+		filter (`notElem` ruuids) (M.keys umap)
+	uuidnode u = trustDecorate trustmap u $
+		Dot.graphNode
+			(fromUUID u)
+			(fromUUIDDesc $ M.findWithDefault mempty u umap)
+
+hostname :: Git.Repo -> String
+hostname r
+	| Git.repoIsUrl r = fromMaybe (Git.repoLocation r) (Git.Url.host r)
+	| otherwise = "localhost"
+
+basehostname :: Git.Repo -> String
+basehostname r = fromMaybe "" $ headMaybe $ splitc '.' $ hostname r
+
+{- A name to display for a repo. Uses the name from uuid.log if available,
+ - or the remote name if not. -}
+repoName :: UUIDDescMap -> Git.Repo -> String
+repoName umap r
+	| repouuid == NoUUID = fallback
+	| otherwise = maybe fallback fromUUIDDesc $ M.lookup repouuid umap
+  where
+	repouuid = getUncachedUUID r
+	fallback = fromMaybe "unknown" $ Git.remoteName r
+
+{- A unique id for the node for a repo. Uses the annex.uuid if available. -}
+nodeId :: Git.Repo -> String
+nodeId r =
+	case getUncachedUUID r of
+		NoUUID -> Git.repoLocation r
+		u@(UUID _) -> fromUUID u
+
+{- A node representing a repo. -}
+node :: UUIDDescMap -> [Git.Repo] -> TrustMap -> RepoRemotes -> String
+node umap fullinfo trustmap (r, rs) = unlines $ n:edges
+  where
+	n = Dot.subGraph (hostname r) (basehostname r) "lightblue" $
+		trustDecorate trustmap (getUncachedUUID r) $
+			Dot.graphNode (nodeId r) (repoName umap r)
+	edges = map (edge umap fullinfo r) rs
+
+{- An edge between two repos. The second repo is a remote of the first. -}
+edge :: UUIDDescMap -> [Git.Repo] -> Git.Repo -> Git.Repo -> String	
+edge umap fullinfo from to =
+	Dot.graphEdge (nodeId from) (nodeId fullto) edgename
+  where
+	-- get the full info for the remote, to get its UUID
+	fullto = findfullinfo to
+	findfullinfo n =
+		case filter (same n) fullinfo of
+			[] -> n
+			(n':_) -> n'
+	{- Only name an edge if the name is different than the name
+	 - that will be used for the destination node, and is
+	 - different from its hostname. (This reduces visual clutter.) -}
+	edgename = maybe Nothing calcname $ Git.remoteName to
+	calcname n
+		| n `elem` [repoName umap fullto, hostname fullto] = Nothing
+		| otherwise = Just n
+
+trustDecorate :: TrustMap -> UUID -> String -> String
+trustDecorate trustmap u s = case M.lookup u trustmap of
+	Just Trusted -> Dot.fillColor "green" s
+	Just UnTrusted -> Dot.fillColor "red" s
+	Just SemiTrusted -> Dot.fillColor "white" s
+	Just DeadTrusted -> Dot.fillColor "grey" s
+	Nothing -> Dot.fillColor "white" s
+
+{- Recursively searches out remotes starting with the specified repo. -}
+spider :: Git.Repo -> Annex [RepoRemotes]
+spider r = spider' [r] []
+spider' :: [Git.Repo] -> [RepoRemotes] -> Annex [RepoRemotes]
+spider' [] known = return known
+spider' (r:rs) known
+	| any (same r) (map fst known) = spider' rs known
+	| otherwise = do
+		r' <- scan r
+
+		-- The remotes will be relative to r', and need to be
+		-- made absolute for later use.
+		remotes <- mapM (absRepo r')
+			=<< (liftIO $ Git.Construct.fromRemotes r')
+	
+		spider' (rs ++ remotes) ((r', remotes):known)
+
+{- Converts repos to a common absolute form. -}
+absRepo :: Git.Repo -> Git.Repo -> Annex Git.Repo
+absRepo reference r
+	| Git.repoIsUrl reference = return $ Git.Construct.localToUrl reference r
+	| Git.repoIsUrl r = return r
+	| otherwise = liftIO $ do
+		r' <- Git.Construct.fromPath =<< absPath (Git.repoPath r)
+		r'' <- safely $ flip Annex.eval Annex.gitRepo =<< Annex.new r'
+		return (fromMaybe r' r'')
+
+{- Checks if two repos are the same. -}
+same :: Git.Repo -> Git.Repo -> Bool
+same a b
+	| both Git.repoIsUrl = matching Git.Url.scheme && matching Git.Url.authority && matching Git.repoPath
+	| neither Git.repoIsUrl = matching Git.repoPath
+	| otherwise = False
+  where
+	matching t = t a == t b
+	both t = t a && t b
+	neither t = not (t a) && not (t b)
+
+{- reads the config of a remote, with progress display -}
+scan :: Git.Repo -> Annex Git.Repo
+scan r = do
+	showStartMessage (StartMessage "map" (ActionItemOther (Just $ UnquotedString $ Git.repoDescribe r)) (SeekInput []))
+	v <- tryScan r
+	case v of
+		Just r' -> do
+			showEndOk
+			return r'
+		Nothing -> do
+			showOutput
+			showEndFail
+			return r
+
+{- tries to read the config of a remote, returning it only if it can
+ - be accessed -}
+tryScan :: Git.Repo -> Annex (Maybe Git.Repo)
+tryScan r
+	| Git.repoIsSsh r = sshscan
+	| Git.repoIsUrl r = case Git.remoteName r of
+		-- Can't scan a non-ssh url, so use any cached uuid for it.
+		Just n -> Just <$> (either
+			(const (pure r))
+			(liftIO . setUUID r . Remote.uuid)
+			=<< Remote.byName' n)
+		Nothing -> return $ Just r
+	| otherwise = liftIO $ safely $ Git.Config.read r
+  where
+	pipedconfig st pcmd params = liftIO $ safely $
+		withCreateProcess p (pipedconfig' st p)
+	  where
+		p = (proc pcmd $ toCommand params)
+			{ std_out = CreatePipe }
+
+	pipedconfig' st p _ (Just h) _ pid = 
+		forceSuccessProcess p pid
+			`after`
+		Git.Config.hRead r st h
+	pipedconfig' _ _ _ _ _ _ = error "internal"
+
+	configlist = Ssh.onRemote NoConsumeStdin r
+		(pipedconfig Git.Config.ConfigList, return Nothing) "configlist" [] []
+	manualconfiglist = do
+		gc <- Annex.getRemoteGitConfig r
+		(sshcmd, sshparams) <- Ssh.toRepo NoConsumeStdin r gc remotecmd
+		liftIO $ pipedconfig Git.Config.ConfigNullList sshcmd sshparams
+	  where
+		remotecmd = "sh -c " ++ shellEscape
+			(cddir ++ " && " ++ "git config --null --list")
+		dir = fromRawFilePath $ Git.repoPath r
+		cddir
+			| "/~" `isPrefixOf` dir =
+				let (userhome, reldir) = span (/= '/') (drop 1 dir)
+				in "cd " ++ userhome ++ " && " ++ cdto (drop 1 reldir)
+			| otherwise = cdto dir
+		cdto p = "if ! cd " ++ shellEscape p ++ " 2>/dev/null; then cd " ++ shellEscape p ++ ".git; fi"
+
+	-- First, try sshing and running git config manually,
+	-- only fall back to git-annex-shell configlist if that
+	-- fails.
+	-- 
+	-- This is done for two reasons, first I'd like this
+	-- subcommand to be usable on non-git-annex repos.
+	-- Secondly, configlist doesn't include information about
+	-- the remote's remotes.
+	sshscan = do
+		sshnote
+		v <- manualconfiglist
+		case v of
+			Nothing -> do
+				sshnote
+				configlist
+			ok -> return ok
+
+	sshnote = do
+		showAction "sshing"
+		showOutput
+
+{- Spidering can find multiple paths to the same repo, so this is used
+ - to combine (really remove) duplicate repos with the same UUID. -}
+combineSame :: [RepoRemotes] -> [RepoRemotes]
+combineSame = map snd . nubBy sameuuid . map pair
+  where
+	sameuuid (u1, _) (u2, _) = u1 == u2 && u1 /= NoUUID
+	pair (r, rs) = (getUncachedUUID r, (r, rs))
+
+safely :: IO Git.Repo -> IO (Maybe Git.Repo)
+safely a = do
+	result <- tryNonAsync a
+	case result of
+		Left _ -> return Nothing
+		Right r' -> return $ Just r'
diff --git a/Command/MatchExpression.hs b/Command/MatchExpression.hs
new file mode 100644
index 0000000000..7ab0bd4d3a
--- /dev/null
+++ b/Command/MatchExpression.hs
@@ -0,0 +1,98 @@
+{- git-annex command
+ -
+ - Copyright 2016-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.MatchExpression where
+
+import Command
+import Annex.FileMatcher
+import Utility.DataUnits
+import Annex.UUID
+import Logs.Group
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+
+cmd :: Command
+cmd = noCommit $
+	command "matchexpression" SectionPlumbing 
+		"checks if a preferred content expression matches"
+		paramExpression
+		(seek <$$> optParser)
+
+data MatchExpressionOptions = MatchExpressionOptions
+	{ matchexpr :: String
+	, largeFilesExpression :: Bool
+	, matchinfo :: MatchInfo
+	}
+
+optParser :: CmdParamsDesc -> Parser MatchExpressionOptions
+optParser desc = MatchExpressionOptions
+	<$> argument str (metavar desc)
+	<*> switch
+		( long "largefiles"
+		<> help "parse as annex.largefiles expression"
+		)
+	<*> (MatchingUserInfo . addkeysize <$> dataparser)
+  where
+	dataparser = UserProvidedInfo
+		<$> optinfo "file" (strOption
+			( long "file" <> metavar paramFile
+			<> help "specify filename to match against"
+			))
+		<*> optinfo "key" (option (str >>= parseKey)
+			( long "key" <> metavar paramKey
+			<> help "specify key to match against"
+			))
+		<*> optinfo "size" (option (str >>= maybe (fail "parse error") return . readSize dataUnits)
+			( long "size" <> metavar paramSize
+			<> help "specify size to match against"
+			))
+		<*> optinfo "mimetype" (strOption
+			( long "mimetype" <> metavar paramValue
+			<> help "specify mime type to match against"
+			))
+		<*> optinfo "mimeencoding" (strOption
+			( long "mimeencoding" <> metavar paramValue
+			<> help "specify mime encoding to match against"
+			))
+
+	optinfo datadesc mk = (Right <$> mk)
+		<|> (pure $ Left $ missingdata datadesc)
+	missingdata datadesc = bail $ "cannot match this expression without " ++ datadesc ++ " data"
+	-- When a key is provided, make its size also be provided.
+	addkeysize p = case userProvidedKey p of
+		Right k -> case fromKey keySize k of
+			Just sz -> p { userProvidedFileSize = Right sz }
+			Nothing -> p
+		Left _ -> p
+
+seek :: MatchExpressionOptions -> CommandSeek
+seek o = do
+	parser <- if largeFilesExpression o
+		then mkMatchExpressionParser
+		else do
+			u <- getUUID
+			pure $ preferredContentParser $ preferredContentTokens $ PCD
+				{ matchStandard = Right matchAll
+				, matchGroupWanted = Right matchAll
+				, getGroupMap = groupMap
+				, configMap = M.empty
+				, repoUUID = Just u
+				}
+	case parsedToMatcher (MatcherDesc "provided expression") $ parser ((matchexpr o)) of
+		Left e -> liftIO $ bail $ "bad expression: " ++ e
+		Right matcher -> ifM (checkmatcher matcher)
+			( liftIO exitSuccess
+			, liftIO exitFailure
+			)
+  where
+	checkmatcher matcher = checkMatcher' matcher (matchinfo o) S.empty
+
+bail :: String -> IO a
+bail s = do
+	hPutStrLn stderr s
+	exitWith $ ExitFailure 42
diff --git a/Command/Merge.hs b/Command/Merge.hs
new file mode 100644
index 0000000000..7585a39c62
--- /dev/null
+++ b/Command/Merge.hs
@@ -0,0 +1,68 @@
+{- git-annex command
+ -
+ - Copyright 2011-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Merge where
+
+import Command
+import qualified Annex.Branch
+import qualified Git
+import qualified Git.Branch
+import Annex.CurrentBranch
+import Command.Sync (prepMerge, mergeLocal, mergeConfig, merge, notOnlyAnnexOption, parseUnrelatedHistoriesOption)
+import Git.Types
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "merge" SectionMaintenance
+		"merge changes from remotes"
+		(paramOptional paramRef) (seek <$$> optParser)
+
+data MergeOptions = MergeOptions
+	{ mergeBranches :: [String]
+	, allowUnrelatedHistories :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser MergeOptions
+optParser desc = MergeOptions
+	<$> cmdParams desc
+	<*> parseUnrelatedHistoriesOption
+
+seek :: MergeOptions -> CommandSeek
+seek o
+	| mergeBranches o == [] = do
+		prepMerge
+		commandAction mergeAnnexBranch
+		commandAction (mergeSyncedBranch o)
+	| otherwise = do
+		prepMerge
+		forM_ (mergeBranches o) $
+			commandAction . mergeBranch o . Git.Ref . encodeBS
+
+mergeAnnexBranch :: CommandStart
+mergeAnnexBranch = starting "merge" ai si $ do
+	_ <- Annex.Branch.update
+	-- commit explicitly, in case no remote branches were merged
+	Annex.Branch.commit =<< Annex.Branch.commitMessage
+	next $ return True
+  where
+	ai = ActionItemOther (Just (UnquotedString (fromRef Annex.Branch.name)))
+	si = SeekInput []
+
+mergeSyncedBranch :: MergeOptions -> CommandStart
+mergeSyncedBranch o = do
+	mc <- mergeConfig (allowUnrelatedHistories o)
+	mergeLocal mc def =<< getCurrentBranch
+
+mergeBranch :: MergeOptions -> Git.Ref -> CommandStart
+mergeBranch o r = starting "merge" ai si $ do
+	currbranch <- getCurrentBranch
+	mc <- mergeConfig (allowUnrelatedHistories o)
+	let so = def { notOnlyAnnexOption = True }
+	next $ merge currbranch mc so Git.Branch.ManualCommit [r]
+  where
+	ai = ActionItemOther (Just (UnquotedString (Git.fromRef r)))
+	si = SeekInput []
diff --git a/Command/MetaData.hs b/Command/MetaData.hs
new file mode 100644
index 0000000000..e0a16c9249
--- /dev/null
+++ b/Command/MetaData.hs
@@ -0,0 +1,183 @@
+{- git-annex command
+ -
+ - Copyright 2014-2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.MetaData where
+
+import Command
+import Annex.MetaData
+import Annex.VectorClock
+import Logs.MetaData
+import Annex.WorkTree
+import Types.Messages
+import Utility.SafeOutput
+import Limit
+import Messages.JSON (JSONActionItem(..), eitherDecode)
+
+import qualified Data.Set as S
+import qualified Data.Map as M
+import qualified Data.Text as T
+import qualified Data.ByteString.Char8 as B8
+import qualified Data.ByteString.Lazy.UTF8 as BU
+import Control.Concurrent
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions, annexedMatchingOptions] $ 
+	command "metadata" SectionMetaData
+		"sets or gets metadata of a file"
+		paramPaths (seek <$$> optParser)
+
+data MetaDataOptions = MetaDataOptions
+	{ forFiles :: CmdParams
+	, getSet :: GetSet
+	, keyOptions :: Maybe KeyOptions
+	, batchOption :: BatchMode
+	}
+
+data GetSet = Get MetaField | GetAll | Set [ModMeta]
+
+optParser :: CmdParamsDesc -> Parser MetaDataOptions
+optParser desc = MetaDataOptions
+	<$> cmdParams desc
+	<*> ((Get <$> getopt) <|> (Set <$> some modopts) <|> pure GetAll)
+	<*> optional parseKeyOptions
+	<*> parseBatchOption False
+  where
+	getopt = option (eitherReader (mkMetaField . T.pack))
+		( long "get" <> short 'g' <> metavar paramField
+		<> help "get single metadata field"
+		)
+	modopts = option (eitherReader parseModMeta)
+		( long "set" <> short 's' <> metavar "FIELD[+-]=VALUE"
+		<> help "set or unset metadata value"
+		)
+		<|> (AddMeta tagMetaField . toMetaValue . encodeBS <$> strOption
+			( long "tag" <> short 't' <> metavar "TAG"
+			<> help "set a tag"
+			))
+		<|> (DelMeta tagMetaField . Just . toMetaValue . encodeBS <$> strOption
+			( long "untag" <> short 'u' <> metavar "TAG"
+			<> help "remove a tag"
+			))
+		<|> option (eitherReader (\f -> DelMeta <$> mkMetaField (T.pack f) <*> pure Nothing))
+			( long "remove"  <> short 'r' <> metavar "FIELD"
+			<> help "remove all values of a field"
+			)
+		<|> flag' DelAllMeta
+			( long "remove-all"
+			<> help "remove all metadata"
+			)
+
+seek :: MetaDataOptions -> CommandSeek
+seek o = case batchOption o of
+	NoBatch -> do
+		c <- currentVectorClock
+		let ww = WarnUnmatchLsFiles "metadata"
+		let seeker = AnnexedFileSeeker
+			{ startAction = const $ start c o
+			, checkContentPresent = Nothing
+			, usesLocationLog = False
+			}
+		let seekaction = case getSet o of
+			Get _ -> withFilesInGitAnnex ww
+			GetAll -> withFilesInGitAnnex ww
+			Set _ -> withFilesInGitAnnexNonRecursive ww
+				"Not recursively setting metadata. Use --force to do that."
+		withKeyOptions (keyOptions o) False seeker
+			(commandAction . startKeys c o)
+			(seekaction seeker)
+			=<< workTreeItems ww (forFiles o)
+	Batch fmt -> withMessageState $ \s -> case outputType s of
+		JSONOutput _ -> ifM limited
+			( giveup "combining --batch with file matching options is not currently supported"
+			, batchOnly (keyOptions o) (forFiles o) $
+				batchInput fmt parseJSONInput 
+					(commandAction . batchCommandStart . startBatch)
+			)
+		_ -> giveup "--batch is currently only supported in --json mode"
+
+start :: CandidateVectorClock -> MetaDataOptions -> SeekInput -> RawFilePath -> Key -> CommandStart
+start c o si file k = startKeys c o (si, k, mkActionItem (k, afile))
+  where
+	afile = AssociatedFile (Just file)
+
+startKeys :: CandidateVectorClock -> MetaDataOptions -> (SeekInput, Key, ActionItem) -> CommandStart
+startKeys c o (si, k, ai) = case getSet o of
+	Get f -> startingCustomOutput k $ do
+		l <- S.toList . currentMetaDataValues f <$> getCurrentMetaData k
+		liftIO $ forM_ l $
+			B8.putStrLn . safeOutput . fromMetaValue
+		next $ return True
+	_ -> starting "metadata" ai si $
+		perform c o k
+
+perform :: CandidateVectorClock -> MetaDataOptions -> Key -> CommandPerform
+perform c o k = case getSet o of
+	Set ms -> do
+		oldm <- getCurrentMetaData k
+		let m = combineMetaData $ map (modMeta oldm) ms
+		addMetaDataClocked k m c
+		next $ cleanup k
+	_ -> next $ cleanup k
+
+cleanup :: Key -> CommandCleanup
+cleanup k = do
+	m <- getCurrentMetaData k
+	maybeAddJSONField "fields" m
+	showLongNote $ UnquotedString $ unlines $ concatMap showmeta $
+		map unwrapmeta (fromMetaData m)
+	return True
+  where
+	unwrapmeta (f, v) = (fromMetaField f, map fromMetaValue (S.toList v))
+	showmeta (f, vs) = map ((T.unpack f ++ "=") ++) (map decodeBS vs)
+
+parseJSONInput :: String -> Annex (Either String (Either RawFilePath Key, MetaData))
+parseJSONInput i = case eitherDecode (BU.fromString i) of
+	Left e -> return (Left e)
+	Right v -> do
+		let m = case itemFields v of
+			Nothing -> emptyMetaData
+			Just m' -> m'
+		case (itemKey v, itemFile v) of
+			(Just k, _) -> return $
+				Right (Right k, m)
+			(Nothing, Just f) -> do
+				f' <- liftIO $ relPathCwdToFile (toRawFilePath f)
+				return $ Right (Left f', m)
+			(Nothing, Nothing) -> return $ 
+				Left "JSON input is missing either file or key"
+
+startBatch :: (SeekInput, (Either RawFilePath Key, MetaData)) -> CommandStart
+startBatch (si, (i, (MetaData m))) = case i of
+	Left f -> do
+		mk <- lookupKeyStaged f
+		case mk of
+			Just k -> go k (mkActionItem (k, AssociatedFile (Just f)))
+			Nothing -> return Nothing
+	Right k -> go k (mkActionItem k)
+  where
+	go k ai = starting "metadata" ai si $ do
+		let o = MetaDataOptions
+			{ forFiles = []
+			, getSet = if MetaData m == emptyMetaData
+				then GetAll
+				else Set $ map mkModMeta (M.toList m)
+			, keyOptions = Nothing
+			, batchOption = NoBatch
+			}
+		t <- currentVectorClock
+		-- It would be bad if two batch mode changes used exactly
+		-- the same timestamp, since the order of adds and removals
+		-- of the same metadata value would then be indeterminate.
+		-- To guarantee that never happens, delay 1 microsecond,
+		-- so the timestamp will always be different. This is
+		-- probably less expensive than cleaner methods,
+		-- such as taking from a list of increasing timestamps.
+		liftIO $ threadDelay 1
+		perform t o k
+	mkModMeta (f, s)
+		| S.null s = DelMeta f Nothing
+		| otherwise = SetMeta f s
diff --git a/Command/Migrate.hs b/Command/Migrate.hs
new file mode 100644
index 0000000000..4434a4dd3b
--- /dev/null
+++ b/Command/Migrate.hs
@@ -0,0 +1,207 @@
+{- git-annex command
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Migrate where
+
+import Command
+import Backend
+import Types.Backend (canUpgradeKey, fastMigrate)
+import Types.KeySource
+import Annex.Content
+import qualified Command.ReKey
+import qualified Command.Fsck
+import qualified Annex
+import Logs.Migrate
+import Logs.MetaData
+import Logs.Web
+import Logs.Location
+import Utility.Metered
+import qualified Database.Keys
+import Git.FilePath
+import Annex.Link
+import Annex.UUID
+
+cmd :: Command
+cmd = withAnnexOptions [backendOption, annexedMatchingOptions, jsonOptions] $
+	command "migrate" SectionUtility 
+		"switch data to different backend"
+		paramPaths (seek <$$> optParser)
+
+data MigrateOptions = MigrateOptions
+	{ migrateThese :: CmdParams
+	, updateOption :: Bool
+	, applyOption :: Bool
+	, removeSize :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser MigrateOptions
+optParser desc = MigrateOptions
+	<$> cmdParams desc
+	<*> switch
+		( long "update"
+		<> help "incrementally apply migrations performed elsewhere"
+		)
+	<*> switch
+		( long "apply"
+		<> help "(re)apply migrations performed elsewhere"
+		)
+	<*> switch
+		( long "remove-size"
+		<> help "remove size field from keys"
+		)
+
+seek :: MigrateOptions -> CommandSeek
+seek o
+	| updateOption o || applyOption o = do
+		unless (null (migrateThese o)) $
+			error "Cannot combine --update or --apply with files to migrate."
+		seekDistributedMigrations (not (applyOption o))
+	| otherwise = do
+		withFilesInGitAnnex ww seeker =<< workTreeItems ww (migrateThese o)
+		commitMigration
+  where
+	ww = WarnUnmatchLsFiles "migrate"
+	seeker = AnnexedFileSeeker
+		{ startAction = start o
+		, checkContentPresent = Nothing
+		, usesLocationLog = False
+		}
+
+seekDistributedMigrations :: Bool -> CommandSeek
+seekDistributedMigrations incremental =
+	streamNewDistributedMigrations incremental $ \oldkey newkey ->
+		-- Not using commandAction because this is not necessarily
+		-- concurrency safe, and also is unlikely to be sped up
+		-- by multiple jobs.
+		void $ includeCommandAction $ update oldkey newkey
+
+start :: MigrateOptions -> Maybe KeySha -> SeekInput -> RawFilePath -> Key -> CommandStart
+start o ksha si file key = do
+	forced <- Annex.getRead Annex.force
+	v <- Backend.getBackend (fromRawFilePath file) key
+	case v of
+		Nothing -> stop
+		Just oldbackend -> do
+			exists <- inAnnex key
+			newbackend <- chooseBackend file
+			if (newbackend /= oldbackend || upgradableKey oldbackend || forced) && exists
+				then go False oldbackend newbackend
+				else if cantweaksize newbackend oldbackend && exists
+					then go True oldbackend newbackend
+					else stop
+  where
+	go onlytweaksize oldbackend newbackend = do
+		keyrec <- case ksha of
+			Just (KeySha s) -> pure (MigrationRecord s)
+			Nothing -> error "internal"
+		starting "migrate" (mkActionItem (key, file)) si $
+			perform onlytweaksize o file key keyrec oldbackend newbackend
+
+	cantweaksize newbackend oldbackend
+		| removeSize o = isJust (fromKey keySize key)
+		| newbackend /= oldbackend = False
+		| isNothing (fromKey keySize key) = True
+		| otherwise = False
+
+	upgradableKey oldbackend = maybe False (\a -> a key) (canUpgradeKey oldbackend)
+
+{- Store the old backend's key in the new backend
+ - The old backend's key is not dropped from it, because there may
+ - be other files still pointing at that key.
+ -
+ - To ensure that the data we have for the old key is valid, it's
+ - fscked here. First we generate the new key. This ensures that the
+ - data cannot get corrupted after the fsck but before the new key is
+ - generated.
+ -}
+perform :: Bool -> MigrateOptions -> RawFilePath -> Key -> MigrationRecord -> Backend -> Backend -> CommandPerform
+perform onlytweaksize o file oldkey oldkeyrec oldbackend newbackend = go =<< genkey (fastMigrate oldbackend)
+  where
+	go Nothing = stop
+	go (Just (newkey, knowngoodcontent))
+		| knowngoodcontent = finish =<< tweaksize newkey
+		| otherwise = stopUnless checkcontent $
+			finish =<< tweaksize newkey
+	checkcontent = Command.Fsck.checkBackend oldkey KeyPresent afile
+	finish newkey = ifM (Command.ReKey.linkKey file oldkey newkey)
+		( do
+			_ <- copyMetaData oldkey newkey
+			-- If the old key had some associated urls, record them for
+			-- the new key as well.
+			urls <- getUrls oldkey
+			forM_ urls $ \url ->
+				setUrlPresent newkey url
+			next $ Command.ReKey.cleanup file newkey $
+				logMigration oldkeyrec
+		, giveup "failed creating link from old to new key"
+		)
+	genkey _ | onlytweaksize = return $ Just (oldkey, False)
+	genkey Nothing = do
+		content <- calcRepo $ gitAnnexLocation oldkey
+		let source = KeySource
+			{ keyFilename = file
+			, contentLocation = content
+			, inodeCache = Nothing
+			}
+		newkey <- fst <$> genKey source nullMeterUpdate newbackend
+		return $ Just (newkey, False)
+	genkey (Just fm) = fm oldkey newbackend afile True >>= \case
+		Just newkey -> return (Just (newkey, True))
+		Nothing -> genkey Nothing
+	tweaksize k
+		| removeSize o = pure (removesize k)
+		| onlytweaksize = addsize k
+		| otherwise = pure k
+	removesize k = alterKey k $ \kd -> kd { keySize = Nothing }
+	addsize k
+		| fromKey keySize k == Nothing = 
+			contentSize k >>= return . \case
+				Just sz -> alterKey k $ \kd -> kd { keySize = Just sz }
+				Nothing -> k
+		| otherwise = return k
+	afile = AssociatedFile (Just file)
+
+update :: Key -> Key -> CommandStart
+update oldkey newkey =
+	stopUnless (allowed <&&> available <&&> wanted) $ do
+		ai <- findworktreefile >>= return . \case
+			Just f -> ActionItemAssociatedFile (AssociatedFile (Just f)) newkey
+			Nothing -> ActionItemKey newkey
+		starting "migrate" ai (SeekInput []) $
+			ifM (Command.ReKey.linkKey' v oldkey newkey)
+				( do
+					logStatus newkey InfoPresent
+					next $ return True
+				, next $ return False
+				)
+  where
+	available = (not <$> inAnnex newkey) <&&> inAnnex oldkey
+
+	-- annex.securehashesonly will block adding keys with insecure
+	-- hashes, this check is only to avoid doing extra work and
+	-- displaying a message when it fails.
+	allowed = isNothing <$> checkSecureHashes newkey
+
+	-- If the new key was previous present in this repository, but got
+	-- dropped, assume the user still doesn't want it there.
+	wanted = loggedPreviousLocations newkey >>= \case
+		[] -> pure True
+		us -> do
+			u <- getUUID
+			pure (u `notElem` us)
+
+	findworktreefile = do
+		fs <- Database.Keys.getAssociatedFiles newkey
+		g <- Annex.gitRepo
+		firstM (\f -> (== Just newkey) <$> isAnnexLink f) $
+			map (\f -> simplifyPath (fromTopFilePath f g)) fs
+	
+	-- Always verify the content agains the newkey, even if
+	-- annex.verify is unset. This is done to prent bad migration
+	-- information maliciously injected into the git-annex branch
+	-- from populating files with the wrong content.
+	v = AlwaysVerify
diff --git a/Command/MinCopies.hs b/Command/MinCopies.hs
new file mode 100644
index 0000000000..5a8cab8578
--- /dev/null
+++ b/Command/MinCopies.hs
@@ -0,0 +1,39 @@
+{- git-annex command
+ -
+ - Copyright 2014-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.MinCopies where
+
+import Command
+import Annex.NumCopies
+import qualified Command.NumCopies
+
+cmd :: Command
+cmd = noMessages $ command "mincopies" SectionSetup 
+	"configure minimum number of copies"
+	paramNumber (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . Command.NumCopies.start' "mincopies" startGet startSet)
+
+start :: [String] -> CommandStart
+start = Command.NumCopies.start' "mincopies" startGet startSet
+
+startGet :: CommandStart
+startGet = startingCustomOutput (ActionItemOther Nothing) $ next $ do
+	v <- getGlobalMinCopies
+	case v of
+		Just n -> liftIO $ putStrLn $ show $ fromMinCopies n
+		Nothing -> liftIO $ putStrLn "global mincopies is not set"
+	return True
+
+startSet :: Int -> CommandStart
+startSet n = startingUsualMessages "mincopies" ai si $ do
+	setGlobalMinCopies $ configuredMinCopies n
+	next $ return True
+  where
+	ai = ActionItemOther (Just $ UnquotedString $ show n)
+	si = SeekInput [show n]
diff --git a/Command/Mirror.hs b/Command/Mirror.hs
new file mode 100644
index 0000000000..d32a06790e
--- /dev/null
+++ b/Command/Mirror.hs
@@ -0,0 +1,90 @@
+{- git-annex command
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Mirror where
+
+import Command
+import qualified Command.Move
+import qualified Command.Drop
+import qualified Command.Get
+import qualified Remote
+import Annex.Content
+import Annex.NumCopies
+import Types.Transfer
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, jsonOptions, jsonProgressOption, annexedMatchingOptions] $
+	command "mirror" SectionCommon 
+		"mirror content of files to/from another repository"
+		paramPaths (seek <--< optParser)
+
+data MirrorOptions = MirrorOptions
+	{ mirrorFiles :: CmdParams
+	, fromToOptions :: FromToOptions
+	, keyOptions :: Maybe KeyOptions
+	}
+
+optParser :: CmdParamsDesc -> Parser MirrorOptions
+optParser desc = MirrorOptions
+	<$> cmdParams desc
+	<*> parseFromToOptions
+	<*> optional (parseKeyOptions <|> parseFailedTransfersOption)
+
+instance DeferredParseClass MirrorOptions where
+	finishParse v = MirrorOptions
+		<$> pure (mirrorFiles v)
+		<*> finishParse (fromToOptions v)
+		<*> pure (keyOptions v)
+
+seek :: MirrorOptions -> CommandSeek
+seek o = startConcurrency stages $ 
+	withKeyOptions (keyOptions o) False seeker
+		(commandAction . startKey o (AssociatedFile Nothing))
+		(withFilesInGitAnnex ww seeker)
+		=<< workTreeItems ww (mirrorFiles o)
+  where
+	stages = case fromToOptions o of
+		FromRemote _ -> transferStages
+		ToRemote _ -> commandStages
+	ww = WarnUnmatchLsFiles "mirror"
+	seeker = AnnexedFileSeeker
+		{ startAction = const $ start o
+		, checkContentPresent = Nothing
+		, usesLocationLog = True
+		}
+
+start :: MirrorOptions -> SeekInput -> RawFilePath -> Key -> CommandStart
+start o si file k = startKey o afile (si, k, ai)
+  where
+	afile = AssociatedFile (Just file)
+	ai = mkActionItem (k, afile)
+
+startKey :: MirrorOptions -> AssociatedFile -> (SeekInput, Key, ActionItem) -> CommandStart
+startKey o afile (si, key, ai) = case fromToOptions o of
+	ToRemote r -> checkFailedTransferDirection ai Upload $ ifM (inAnnex key)
+		( Command.Move.toStart Command.Move.RemoveNever afile key ai si =<< getParsed r
+		, do
+			(numcopies, mincopies) <- getSafestNumMinCopies afile key
+			Command.Drop.startRemote pcc afile ai si numcopies mincopies key (Command.Drop.DroppingUnused False)
+				=<< getParsed r
+		)
+	FromRemote r -> checkFailedTransferDirection ai Download $ do
+		haskey <- flip Remote.hasKey key =<< getParsed r
+		case haskey of
+			Left _ -> stop
+			Right True -> ifM (inAnnex key)
+				( stop
+				, Command.Get.start' (return True) Nothing key afile ai si
+				)
+			Right False -> ifM (inAnnex key)
+				( do
+					(numcopies, mincopies) <- getSafestNumMinCopies afile key
+					Command.Drop.startLocal pcc afile ai si numcopies mincopies key [] (Command.Drop.DroppingUnused False)
+				, stop
+				)
+  where
+	pcc = Command.Drop.PreferredContentChecked False
diff --git a/Command/Move.hs b/Command/Move.hs
new file mode 100644
index 0000000000..056a7ca738
--- /dev/null
+++ b/Command/Move.hs
@@ -0,0 +1,600 @@
+{- git-annex command
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Move where
+
+import Command
+import qualified Command.Drop
+import qualified Annex
+import Annex.Content
+import qualified Remote
+import Annex.UUID
+import Annex.Transfer
+import Logs.Presence
+import Logs.Trust
+import Logs.File
+import Logs.Location
+import Annex.NumCopies
+
+import qualified Data.ByteString.Char8 as B8
+import qualified Data.ByteString.Lazy as L
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, jsonOptions, jsonProgressOption, annexedMatchingOptions] $
+	command "move" SectionCommon
+		"move content of files to/from another repository"
+		paramPaths (seek <--< optParser)
+
+data MoveOptions = MoveOptions
+	{ moveFiles :: CmdParams
+	, fromToOptions :: Maybe FromToHereOptions
+	, removeWhen :: RemoveWhen
+	, keyOptions :: Maybe KeyOptions
+	, batchOption :: BatchMode
+	}
+
+optParser :: CmdParamsDesc -> Parser MoveOptions
+optParser desc = MoveOptions
+	<$> cmdParams desc
+	<*> parseFromToHereOptions
+	<*> pure RemoveSafe
+	<*> optional (parseKeyOptions <|> parseFailedTransfersOption)
+	<*> parseBatchOption True
+
+instance DeferredParseClass MoveOptions where
+	finishParse v = MoveOptions
+		<$> pure (moveFiles v)
+		<*> maybe (pure Nothing) (Just <$$> finishParse)
+			(fromToOptions v)
+		<*> pure (removeWhen v)
+		<*> pure (keyOptions v)
+		<*> pure (batchOption v)
+
+data RemoveWhen = RemoveSafe | RemoveNever
+	deriving (Show, Eq)
+
+seek :: MoveOptions -> CommandSeek
+seek o = case fromToOptions o of
+	Just fto -> seek' o fto
+	Nothing -> giveup "Specify --from or --to"
+
+seek' :: MoveOptions -> FromToHereOptions -> CommandSeek
+seek' o fto = startConcurrency (stages fto) $ do
+	case batchOption o of
+		NoBatch -> withKeyOptions (keyOptions o) False seeker
+			(commandAction . keyaction)
+			(withFilesInGitAnnex ww seeker)
+			=<< workTreeItems ww (moveFiles o)
+		Batch fmt -> batchOnly (keyOptions o) (moveFiles o) $
+			batchAnnexed fmt seeker keyaction
+  where
+	seeker = AnnexedFileSeeker
+		{ startAction = const $ start fto (removeWhen o)
+		, checkContentPresent = case fto of
+			FromOrToRemote (FromRemote _) -> Nothing
+			FromOrToRemote (ToRemote _) -> Just True
+			ToHere -> Nothing
+			FromRemoteToRemote _ _ -> Nothing
+			FromAnywhereToRemote _ -> Nothing
+		, usesLocationLog = True
+		}
+	keyaction = startKey fto (removeWhen o)
+	ww = WarnUnmatchLsFiles "move"
+
+stages :: FromToHereOptions -> UsedStages
+stages (FromOrToRemote (FromRemote _)) = transferStages
+stages (FromOrToRemote (ToRemote _)) = commandStages
+stages ToHere = transferStages
+stages (FromRemoteToRemote _ _) = transferStages
+stages (FromAnywhereToRemote _) = transferStages
+
+start :: FromToHereOptions -> RemoveWhen -> SeekInput -> RawFilePath -> Key -> CommandStart
+start fromto removewhen si f k = start' fromto removewhen afile si k ai
+  where
+	afile = AssociatedFile (Just f)
+	ai = mkActionItem (k, afile)
+
+startKey :: FromToHereOptions -> RemoveWhen -> (SeekInput, Key, ActionItem) -> CommandStart
+startKey fromto removewhen (si, k, ai) = 
+	start' fromto removewhen (AssociatedFile Nothing) si k ai
+
+start' :: FromToHereOptions -> RemoveWhen -> AssociatedFile -> SeekInput -> Key -> ActionItem -> CommandStart
+start' fromto removewhen afile si key ai =
+	case fromto of
+		FromOrToRemote (FromRemote src) ->
+			checkFailedTransferDirection ai Download $
+				fromStart removewhen afile key ai si =<< getParsed src
+		FromOrToRemote (ToRemote dest) ->
+			checkFailedTransferDirection ai Upload $
+				toStart removewhen afile key ai si =<< getParsed dest
+		ToHere ->
+			checkFailedTransferDirection ai Download $
+				toHereStart removewhen afile key ai si
+		FromRemoteToRemote src dest -> do
+			src' <- getParsed src
+			dest' <- getParsed dest
+			fromToStart removewhen afile key ai si src' dest'
+		FromAnywhereToRemote dest -> do
+			dest' <- getParsed dest
+			fromAnywhereToStart removewhen afile key ai si dest'
+
+describeMoveAction :: RemoveWhen -> String
+describeMoveAction RemoveNever = "copy"
+describeMoveAction _ = "move"
+
+toStart :: RemoveWhen -> AssociatedFile -> Key -> ActionItem -> SeekInput -> Remote -> CommandStart
+toStart removewhen afile key ai si dest = do
+	u <- getUUID
+	if u == Remote.uuid dest
+		then stop
+		else toStart' dest removewhen afile key ai si
+
+toStart' :: Remote -> RemoveWhen -> AssociatedFile -> Key -> ActionItem -> SeekInput -> CommandStart
+toStart' dest removewhen afile key ai si = do
+	fast <- Annex.getRead Annex.fast
+	if fast && removewhen == RemoveNever
+		then ifM (expectedPresent dest key)
+			( stop
+			, go True (pure $ Right False)
+			)
+		else go False (Remote.hasKey dest key)
+  where
+	go fastcheck isthere =
+		starting (describeMoveAction removewhen) (OnlyActionOn key ai) si $
+			toPerform dest removewhen key afile fastcheck =<< isthere
+
+expectedPresent :: Remote -> Key -> Annex Bool
+expectedPresent dest key = do
+	remotes <- Remote.keyPossibilities (Remote.IncludeIgnored True) key
+	return $ dest `elem` remotes
+
+toPerform :: Remote -> RemoveWhen -> Key -> AssociatedFile -> Bool -> Either String Bool -> CommandPerform
+toPerform = toPerform' Nothing
+
+toPerform' :: Maybe ContentRemovalLock -> Remote -> RemoveWhen -> Key -> AssociatedFile -> Bool -> Either String Bool -> CommandPerform
+toPerform' mcontentlock dest removewhen key afile fastcheck isthere = do
+	srcuuid <- getUUID
+	case isthere of
+		Left err -> do
+			showNote (UnquotedString err)
+			stop
+		Right False -> logMove srcuuid destuuid False key $ \deststartedwithcopy -> do
+			showAction $ UnquotedString $ "to " ++ Remote.name dest
+			ok <- notifyTransfer Upload afile $
+				upload dest key afile stdRetry
+			if ok
+				then finish deststartedwithcopy $
+					Remote.logStatus dest key InfoPresent
+				else do
+					logMoveCleanup deststartedwithcopy
+					when fastcheck $
+						warning "This could have failed because --fast is enabled."
+					stop
+		Right True -> logMove srcuuid destuuid True key $ \deststartedwithcopy ->
+			finish deststartedwithcopy $
+				unlessM (expectedPresent dest key) $
+					Remote.logStatus dest key InfoPresent
+  where
+	destuuid = Remote.uuid dest
+	finish deststartedwithcopy setpresentremote = case removewhen of
+		RemoveNever -> do
+			setpresentremote
+			logMoveCleanup deststartedwithcopy
+			next $ return True
+		RemoveSafe -> lockcontentforremoval $ \contentlock -> do
+			srcuuid <- getUUID
+			r <- willDropMakeItWorse srcuuid destuuid deststartedwithcopy key afile >>= \case
+				DropAllowed -> drophere setpresentremote contentlock "moved"
+				DropCheckNumCopies -> do
+					(numcopies, mincopies) <- getSafestNumMinCopies afile key
+					(tocheck, verified) <- verifiableCopies key [srcuuid]
+					verifyEnoughCopiesToDrop "" key (Just contentlock)
+						 numcopies mincopies [srcuuid] verified
+						 (UnVerifiedRemote dest : tocheck)
+						 (drophere setpresentremote contentlock . showproof)
+						 (faileddrophere setpresentremote)
+				DropWorse -> faileddrophere setpresentremote
+			logMoveCleanup deststartedwithcopy
+			return r
+	showproof proof = "proof: " ++ show proof
+	drophere setpresentremote contentlock reason = do
+		fastDebug "Command.Move" $ unwords
+			[ "Dropping from here"
+			, "(" ++ reason ++ ")"
+			]
+		-- Drop content before updating location logs,
+		-- in case disk space is very low this frees
+		-- up space before writing data to disk.
+		removeAnnex contentlock
+		next $ do
+			() <- setpresentremote
+			Command.Drop.cleanupLocal key (Command.Drop.DroppingUnused False)
+	faileddrophere setpresentremote = do
+		showLongNote "(Use --force to override this check, or adjust numcopies.)"
+		showLongNote "Content not dropped from here."
+		next $ do
+			() <- setpresentremote
+			return False
+	
+	lockcontentforremoval a = case mcontentlock of
+		Nothing -> lockContentForRemoval key lockfailed a
+		Just contentlock -> a contentlock
+	
+	-- This occurs when, for example, two files are being dropped
+	-- and have the same content. The seek stage checks if the content
+	-- is present, but due to buffering, may find it present for the
+	-- second file before the first is dropped. If so, nothing remains
+	-- to be done except for cleaning up.
+	lockfailed = next $ Command.Drop.cleanupLocal key (Command.Drop.DroppingUnused False)
+
+fromStart :: RemoveWhen -> AssociatedFile -> Key -> ActionItem -> SeekInput -> Remote -> CommandStart
+fromStart removewhen afile key ai si src = 
+	stopUnless (fromOk src key) $
+		starting (describeMoveAction removewhen) (OnlyActionOn key ai) si $
+			fromPerform src removewhen key afile
+
+fromOk :: Remote -> Key -> Annex Bool
+fromOk src key
+	-- check if the remote contains the key, when it can be done cheaply
+	| Remote.hasKeyCheap src = 
+		Remote.hasKey src key >>= \case
+			Right True -> return True
+			-- Don't skip getting the key just because the
+			-- remote no longer contains it if the log
+			-- says the remote is supposed to contain it;
+			-- that would be surprising behavior.
+			_ -> checklog
+	| otherwise = checklog
+  where
+	checklog = do
+		u <- getUUID
+		remotes <- Remote.keyPossibilities (Remote.IncludeIgnored True) key
+		return $ u /= Remote.uuid src && elem src remotes
+
+fromPerform :: Remote -> RemoveWhen -> Key -> AssociatedFile -> CommandPerform
+fromPerform src removewhen key afile = do
+	present <- inAnnex key
+	finish <- fromPerform' present True src key afile
+	finish removewhen
+
+fromPerform' :: Bool -> Bool -> Remote -> Key -> AssociatedFile -> Annex (RemoveWhen -> CommandPerform)
+fromPerform' present updatelocationlog src key afile = do
+	showAction $ UnquotedString $ "from " ++ Remote.name src
+	destuuid <- getUUID
+	logMove (Remote.uuid src) destuuid present key $ \deststartedwithcopy ->
+		if present
+			then return $ finish deststartedwithcopy True
+			else do
+				got <- get
+				return $ finish deststartedwithcopy got
+  where
+	get = notifyTransfer Download afile $
+		logdownload .
+			download src key afile stdRetry
+	
+	logdownload a
+		| updatelocationlog = logStatusAfter key a
+		| otherwise = a
+
+	finish deststartedwithcopy False _ = do
+		logMoveCleanup deststartedwithcopy
+		stop -- copy failed
+	finish deststartedwithcopy True RemoveNever = do
+		logMoveCleanup deststartedwithcopy
+		next $ return True -- copy complete
+	finish deststartedwithcopy True RemoveSafe = do
+		destuuid <- getUUID
+		lockContentShared key $ \_lck ->
+			fromDrop src destuuid deststartedwithcopy key afile id
+
+fromDrop :: Remote -> UUID -> DestStartedWithCopy -> Key -> AssociatedFile -> ([UnVerifiedCopy] -> [UnVerifiedCopy])-> CommandPerform
+fromDrop src destuuid deststartedwithcopy key afile adjusttocheck =
+	willDropMakeItWorse (Remote.uuid src) destuuid deststartedwithcopy key afile >>= \case
+		DropAllowed -> dropremote "moved"
+		DropCheckNumCopies -> do
+			(numcopies, mincopies) <- getSafestNumMinCopies afile key
+			(tocheck, verified) <- verifiableCopies key [Remote.uuid src]
+			verifyEnoughCopiesToDrop "" key Nothing numcopies mincopies [Remote.uuid src] verified
+				(adjusttocheck tocheck) (dropremote . showproof) faileddropremote
+		DropWorse -> faileddropremote
+  where
+	showproof proof = "proof: " ++ show proof
+
+	dropremote reason = do
+		fastDebug "Command.Move" $ unwords
+			[ "Dropping from remote"
+			, show src
+			, "(" ++ reason ++ ")"
+			]
+		ok <- Remote.action (Remote.removeKey src key)
+		when ok $
+			logMoveCleanup deststartedwithcopy
+		next $ Command.Drop.cleanupRemote key src (Command.Drop.DroppingUnused False) ok
+
+	faileddropremote = do
+		showLongNote "(Use --force to override this check, or adjust numcopies.)"
+		showLongNote $ UnquotedString $ "Content not dropped from " ++ Remote.name src ++ "."
+		logMoveCleanup deststartedwithcopy
+		next $ return False
+
+{- Moves (or copies) the content of an annexed file from reachable remotes
+ - to the current repository.
+ -
+ - When moving, the content is removed from all the reachable remotes that
+ - it can safely be removed from. -}
+toHereStart :: RemoveWhen -> AssociatedFile -> Key -> ActionItem -> SeekInput -> CommandStart
+toHereStart removewhen afile key ai si = 
+	startingNoMessage (OnlyActionOn key ai) $ do
+		rs <- Remote.keyPossibilities (Remote.IncludeIgnored False) key
+		forM_ rs $ \r ->
+			includeCommandAction $
+				starting (describeMoveAction removewhen) ai si $
+					fromPerform r removewhen key afile
+		next $ return True
+
+fromToStart :: RemoveWhen -> AssociatedFile -> Key -> ActionItem -> SeekInput -> Remote -> Remote -> CommandStart
+fromToStart removewhen afile key ai si src dest = 
+	stopUnless somethingtodo $ do
+		u <- getUUID
+		if u == Remote.uuid src
+			then toStart removewhen afile key ai si dest
+			else if u == Remote.uuid dest
+				then fromStart removewhen afile key ai si src
+				else stopUnless (fromOk src key) $
+					starting (describeMoveAction removewhen) (OnlyActionOn key ai) si $
+						fromToPerform src dest removewhen key afile
+  where
+	somethingtodo
+		| Remote.uuid src == Remote.uuid dest = return False
+		| otherwise = do
+			fast <- Annex.getRead Annex.fast
+			if fast && removewhen == RemoveNever
+				then not <$> expectedPresent dest key
+				else return True
+
+fromAnywhereToStart :: RemoveWhen -> AssociatedFile -> Key -> ActionItem -> SeekInput -> Remote -> CommandStart
+fromAnywhereToStart removewhen afile key ai si dest =
+	stopUnless somethingtodo $ do
+		u <- getUUID
+		if u == Remote.uuid dest
+			then toHereStart removewhen afile key ai si
+			else startingNoMessage (OnlyActionOn key ai) $ do
+				rs <- filter (/= dest) 
+					<$> Remote.keyPossibilities (Remote.IncludeIgnored False) key
+				forM_ rs $ \r ->
+					includeCommandAction $
+						starting (describeMoveAction removewhen) ai si $
+							fromToPerform r dest removewhen key afile
+				whenM (inAnnex key) $
+					void $ includeCommandAction $
+						toStart removewhen afile key ai si dest 
+				next $ return True
+  where
+	somethingtodo = do
+		fast <- Annex.getRead Annex.fast
+		if fast && removewhen == RemoveNever
+			then not <$> expectedPresent dest key
+			else return True
+
+{- When there is a local copy, transfer it to the dest, and drop from the src.
+ -
+ - When the dest has a copy, drop it from the src.
+ -
+ - Otherwise, download a copy from the dest, populating the local annex
+ - copy, but not updating location logs. Then transfer that to the dest,
+ - drop the local copy, and finally drop from the src.
+ -
+ - Using a regular download of the local copy, rather than download to
+ - some other file makes resuming an interrupted download work as usual,
+ - and simplifies implementation. It does mean that, if `git-annex get` of
+ - the same content is being run at the same time as this move, the content
+ - may end up locally present, or not. This is similar to the behavior 
+ - when running `git-annex move --to` concurrently with git-annex get.
+ -}
+fromToPerform :: Remote -> Remote -> RemoveWhen -> Key -> AssociatedFile -> CommandPerform
+fromToPerform src dest removewhen key afile = do
+	hereuuid <- getUUID
+	loggedpresent <- any (== hereuuid)
+		<$> loggedLocations key
+	ispresent <- inAnnex key
+	go ispresent loggedpresent
+  where
+	-- The content is present, and is logged as present, so it
+	-- can be sent to dest and dropped from src.
+	--
+	-- When resuming an interrupted move --from --to, where the content
+	-- was not present but got downloaded from src, it will not be
+	-- logged present, and so this won't be used. Instead, the local
+	-- content will get dropped after being copied to dest.
+	go True True = do
+		haskey <- Remote.hasKey dest key
+		-- Prepare to drop from src later. Doing this first
+		-- makes "from src" be shown consistently before
+		-- "to dest"
+		dropsrc <- fromsrc True
+		combinecleanups 
+			-- Send to dest, preserve local copy.
+			(todest Nothing RemoveNever haskey)
+			(\senttodest -> if senttodest
+				then dropsrc removewhen
+				else stop
+			)
+	go ispresent _loggedpresent = do
+		haskey <- Remote.hasKey dest key
+		case haskey of
+                	Left err -> do                   
+				showNote (UnquotedString err)
+				stop
+			Right True -> do
+				showAction $ UnquotedString $
+					"from " ++ Remote.name src
+				showAction $ UnquotedString $
+					"to " ++ Remote.name dest
+				-- The log may not indicate dest's copy
+				-- yet, so make sure it does.
+				logChange key (Remote.uuid dest) InfoPresent
+				-- Drop from src, checking copies including
+				-- the one already in dest.
+				dropfromsrc id
+			Right False -> do
+				-- Get local copy from src, defer dropping
+				-- from src until later. Note that fromsrc
+				-- does not update the location log.
+				cleanupfromsrc <- if ispresent
+					then return $ const $ next (return True)
+					else fromsrc False
+				-- Lock the local copy for removal early,
+				-- to avoid other processes relying on it
+				-- as a copy, and removing other copies
+				-- (such as the one in src), that prevents
+				-- dropping the local copy later.
+				lockContentForRemoval key stop $ \contentlock ->
+					combinecleanups
+						-- Send to dest and remove local copy.
+						(todest (Just contentlock) RemoveSafe haskey)
+						(\senttodest ->
+							-- Drop from src, checking
+							-- copies including dest.
+							combinecleanups
+								(cleanupfromsrc RemoveNever)
+								(\_ -> if senttodest
+									then dropfromsrc (\l -> UnVerifiedRemote dest : l)
+									else stop
+								)
+						)
+
+	fromsrc present = fromPerform' present False src key afile
+
+	todest mcontentlock removewhen' = toPerform' mcontentlock dest removewhen' key afile False
+
+	dropfromsrc adjusttocheck = case removewhen of
+		RemoveSafe -> logMove (Remote.uuid src) (Remote.uuid dest) True key $ \deststartedwithcopy ->
+			fromDrop src (Remote.uuid dest) deststartedwithcopy key afile adjusttocheck
+		RemoveNever -> next (return True)
+
+	combinecleanups a b = a >>= \case
+		Just cleanupa -> b True >>= \case
+			Just cleanupb -> return $ Just $ do
+				oka <- cleanupa
+				okb <- cleanupb
+				return (oka && okb)
+			Nothing -> return (Just cleanupa)
+		Nothing -> b False >>= \case
+			Just cleanupb -> return $ Just $ do
+				void cleanupb
+				return False
+			Nothing -> return Nothing
+
+{- The goal of this command is to allow the user maximum freedom to move
+ - files as they like, while avoiding making bad situations any worse
+ - than they already were.
+ -
+ - When the destination repository already had a copy of a file
+ - before the move operation began, dropping it from the source
+ - repository reduces the number of copies, and should fail if
+ - that would violate numcopies settings.
+ -
+ - On the other hand, when the destination repository did not start
+ - with a copy of a file, it can be dropped from the source without
+ - making numcopies worse, so the move is allowed even if numcopies
+ - is not met.
+ -
+ - Similarly, a file can move from an untrusted repository to another
+ - untrusted repository, even if that is the only copy of the file.
+ -
+ - But, moving a file from a repository with higher trust to an untrusted
+ - repository must still check that there are enough other copies to be
+ - safe.
+ -
+ - Also, required content settings should not be violated.
+ -
+ - This function checks all that. It needs to know if the destination
+ - repository already had a copy of the file before the move began.
+ -}
+willDropMakeItWorse :: UUID -> UUID -> DestStartedWithCopy -> Key -> AssociatedFile -> Annex DropCheck
+willDropMakeItWorse srcuuid destuuid (DestStartedWithCopy deststartedwithcopy _) key afile =
+	ifM (Command.Drop.checkRequiredContent (Command.Drop.PreferredContentChecked False) srcuuid key afile)
+		( if deststartedwithcopy
+			then unlessforced DropCheckNumCopies
+			else ifM checktrustlevel
+				( return DropAllowed
+				, unlessforced DropCheckNumCopies
+				)
+		, unlessforced DropWorse
+		)
+  where
+	unlessforced r = ifM (Annex.getRead Annex.force)
+		( return DropAllowed
+		, return r
+		)
+	checktrustlevel = do
+		desttrust <- lookupTrust destuuid
+		srctrust <- lookupTrust srcuuid
+		return (desttrust > UnTrusted || desttrust >= srctrust)
+
+data DropCheck = DropWorse | DropAllowed | DropCheckNumCopies
+
+data DestStartedWithCopy = DestStartedWithCopy Bool (Annex ())
+
+{- This should be called once the move has succeeded, or if it failed
+ - without doing anything. It should not be called if the move transferred
+ - the content but failed to drop due to eg a network error. In such a
+ - case, the move can be restarted later, so the move log should be
+ - preserved. -}
+logMoveCleanup :: DestStartedWithCopy -> Annex ()
+logMoveCleanup (DestStartedWithCopy _ a) = a
+
+{- Runs an action that performs a move, and logs the move, allowing an
+ - failed or interrupted move to be re-done later.
+ -
+ - This deals with the situation where dest did not start with a copy,
+ - but the move downloaded it, and was then interrupted before dropping
+ - it from the source. Re-running the move would see dest has a
+ - copy, and so could refuse to allow the drop. By providing the logged
+ - DestStartedWithCopy, this avoids that annoyance.
+ -}
+logMove :: UUID -> UUID -> Bool -> Key -> (DestStartedWithCopy -> Annex a) -> Annex a
+logMove srcuuid destuuid deststartedwithcopy key a = go =<< setup
+  where
+	logline = L.fromStrict $ B8.unwords
+		[ fromUUID srcuuid
+		, fromUUID destuuid
+		, serializeKey' key
+		]
+
+	setup = do
+		logf <- fromRepo gitAnnexMoveLog
+		lckf <- fromRepo gitAnnexMoveLock
+		-- Only log when there was no copy.
+		unless deststartedwithcopy $
+			appendLogFile logf lckf logline
+		return (logf, lckf)
+
+	cleanup (logf, lckf) =
+		-- This buffers the log file content in memory.
+		-- The log file length is limited to the number of
+		-- concurrent jobs, times the number of times a move
+		-- (of different files) has been interrupted.
+		-- That could grow without bounds given enough time,
+		-- so the log is also truncated to the most recent
+		-- 100 items.
+		modifyLogFile logf lckf
+			(filter (/= logline) . reverse . take 100 . reverse)
+
+	go fs@(logf, lckf)
+		-- Only need to check log when there is a copy.
+		| deststartedwithcopy = do
+			wasnocopy <- checkLogFile logf lckf (== logline)
+			if wasnocopy
+				then go' fs False
+				else go' fs deststartedwithcopy
+		| otherwise = go' fs deststartedwithcopy
+
+	go' fs deststartedwithcopy' = a $
+		DestStartedWithCopy deststartedwithcopy' (cleanup fs)
diff --git a/Command/Multicast.hs b/Command/Multicast.hs
new file mode 100644
index 0000000000..112a364046
--- /dev/null
+++ b/Command/Multicast.hs
@@ -0,0 +1,256 @@
+{- git-annex command
+ -
+ - Copyright 2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP, OverloadedStrings #-}
+
+module Command.Multicast where
+
+import Command
+import Logs.Multicast
+import Annex.Multicast
+import Annex.WorkTree
+import Annex.Content
+import Annex.UUID
+import Annex.Perms
+import Logs.Location
+import Utility.FileMode
+#ifndef mingw32_HOST_OS
+import Creds
+#endif
+import qualified Limit
+import Types.FileMatcher
+import qualified Git.LsFiles as LsFiles
+import Utility.Hash
+import Utility.Tmp
+import Utility.Tmp.Dir
+import Utility.Process.Transcript
+import qualified Utility.RawFilePath as R
+
+import Data.Char
+import qualified Data.ByteString.Lazy.UTF8 as B8
+import qualified Data.Map as M
+import Control.Concurrent.Async
+
+cmd :: Command
+cmd = command "multicast" SectionCommon "multicast file distribution"
+	paramNothing (seek <$$> optParser)
+
+data MultiCastAction
+	= GenAddress
+	| Send
+	| Receive
+	deriving (Show)
+
+data MultiCastOptions = MultiCastOptions MultiCastAction [CommandParam] [FilePath]
+	deriving (Show)
+
+optParser :: CmdParamsDesc -> Parser MultiCastOptions
+optParser _ = MultiCastOptions 
+	<$> (genaddressp <|> sendp <|> receivep)
+	<*> many uftpopt
+	<*> cmdParams paramPaths
+  where
+	genaddressp = flag' GenAddress
+		( long "gen-address"
+		<> help "generate multicast encryption key and store address in git-annex branch"
+		)
+	sendp = flag' Send
+		( long "send"
+		<> help "multicast files"
+		)
+	receivep = flag' Receive
+		( long "receive"
+		<> help "listen for multicast files and store in repository"
+		)
+	uftpopt = Param <$> strOption
+		( long "uftp-opt"
+		<> short 'U'
+		<> help "passed on to uftp/uftpd"
+		<> metavar "OPTION"
+		)
+
+seek :: MultiCastOptions -> CommandSeek
+seek (MultiCastOptions GenAddress _ _) = commandAction genAddress 
+seek (MultiCastOptions Send ups fs) = commandAction $ send ups fs
+seek (MultiCastOptions Receive ups []) = commandAction $ receive ups
+seek (MultiCastOptions Receive _ _) = giveup "Cannot specify list of files with --receive; this receives whatever files the sender chooses to send."
+
+genAddress :: CommandStart
+genAddress = starting "gen-address" (ActionItemOther Nothing) (SeekInput []) $ do
+	k <- uftpKey
+	(s, ok) <- case k of
+		KeyContainer s -> liftIO $ genkey (Param s)
+		KeyFile f -> do
+			createAnnexDirectory (toRawFilePath (takeDirectory f))
+			liftIO $ removeWhenExistsWith R.removeLink (toRawFilePath f)
+			liftIO $ protectedOutput $ genkey (File f)
+	case (ok, parseFingerprint s) of
+		(False, _) -> giveup $ "uftp_keymgt failed: " ++ s
+		(_, Nothing) -> giveup $ "Failed to find fingerprint in uftp_keymgt output: " ++ s
+		(True, Just fp) -> next $ do
+			recordFingerprint fp =<< getUUID
+			return True
+  where
+ 	-- Annoyingly, the fingerprint is output to stderr.
+	genkey p = processTranscript "uftp_keymgt" ps Nothing
+	  where
+		ps = toCommand $
+			[ Param "-g"
+			, keyparam
+			, p
+			]
+	-- uftp only supports rsa up to 2048 which is on the lower
+	-- limit of secure RSA key sizes. Instead, use an EC curve.
+	-- Except for on Windows XP, secp521r1 is supported on all
+	-- platforms by uftp. DJB thinks it's pretty good compared
+	-- with other NIST curves: "there's one standard NIST curve
+	-- using a nice prime, namely 2521-1  but the sheer size of this
+	-- prime makes it much slower than NIST P-256"
+	-- (http://blog.cr.yp.to/20140323-ecdsa.html)
+	-- Since this key is only used to set up the block encryption,
+	-- its slow speed is ok.
+	keyparam = Param "ec:secp521r1"
+
+parseFingerprint :: String -> Maybe Fingerprint
+parseFingerprint = Fingerprint <$$> lastMaybe . filter isfingerprint . words 
+  where
+	isfingerprint s = 
+		let os = filter (all isHexDigit) (splitc ':' s)
+		in length os == 20
+	
+send :: [CommandParam] -> [FilePath] -> CommandStart
+send ups fs = do
+	-- Need to be able to send files with the names of git-annex
+	-- keys, and uftp does not allow renaming the files that are sent.
+	-- In a direct mode repository, the annex objects do not have
+	-- the names of keys, and would have to be copied, which is too
+	-- expensive.
+	starting "sending files" (ActionItemOther Nothing) (SeekInput []) $
+		withTmpFile "send" $ \t h -> do
+			let ww = WarnUnmatchLsFiles "multicast"
+			(fs', cleanup) <- seekHelper id ww LsFiles.inRepo
+				=<< workTreeItems ww fs
+			matcher <- Limit.getMatcher
+			let addlist f o = whenM (matcher $ MatchingFile $ FileInfo f f Nothing) $
+				liftIO $ hPutStrLn h o
+			forM_ fs' $ \(_, f) -> do
+				mk <- lookupKey f
+				case mk of
+					Nothing -> noop
+					Just k -> withObjectLoc k $
+						addlist f . fromRawFilePath
+			liftIO $ hClose h
+			liftIO $ void cleanup
+			
+			serverkey <- uftpKey
+			u <- getUUID
+			withAuthList $ \authlist -> do
+				let ps =
+					-- Force client authentication.
+					[ Param "-c"
+					, Param "-Y", Param "aes256-gcm"
+					, Param "-h", Param "sha512"
+					-- Picked ecdh_ecdsa for perfect forward secrecy,
+					-- and because a EC key exchange algorithm is
+					-- needed since all keys are EC.
+					, Param "-e", Param "ecdh_ecdsa"
+					, Param "-k", uftpKeyParam serverkey
+					, Param "-U", Param (uftpUID u)
+					-- only allow clients on the authlist
+					, Param "-H", Param ("@"++authlist)
+					-- pass in list of files to send
+					, Param "-i", File t
+					] ++ ups
+				liftIO (boolSystem "uftp" ps) >>= showEndResult
+			next $ return True
+
+receive :: [CommandParam] -> CommandStart
+receive ups = starting "receiving multicast files" ai si $ do
+	showNote "Will continue to run until stopped by ctrl-c"
+	
+	showOutput
+	clientkey <- uftpKey
+	u <- getUUID
+	(callback, environ, statush) <- liftIO multicastCallbackEnv
+	tmpobjdir <- fromRepo gitAnnexTmpObjectDir
+	createAnnexDirectory tmpobjdir
+	withTmpDirIn (fromRawFilePath tmpobjdir) "multicast" $ \tmpdir -> withAuthList $ \authlist -> do
+		abstmpdir <- liftIO $ absPath (toRawFilePath tmpdir)
+		abscallback <- liftIO $ searchPath callback
+		let ps =
+			-- Avoid it running as a daemon.
+			[ Param "-d"
+			-- Require encryption.
+			, Param "-E"
+			, Param "-k", uftpKeyParam clientkey
+			, Param "-U", Param (uftpUID u)
+			-- Only allow servers on the authlist
+			, Param "-S", Param authlist
+			-- Receive files into tmpdir
+			-- (it needs an absolute path)
+			, Param "-D", File (fromRawFilePath abstmpdir)
+			-- Run callback after each file received
+			-- (it needs an absolute path)
+			, Param "-s", Param (fromMaybe callback abscallback)
+			] ++ ups
+		runner <- liftIO $ async $
+			hClose statush
+				`after` boolSystemEnv "uftpd" ps (Just environ)
+		mapM_ storeReceived . lines =<< liftIO (hGetContents statush)
+		showEndResult =<< liftIO (wait runner)
+	next $ return True
+  where
+	ai = ActionItemOther Nothing
+	si = SeekInput []
+
+storeReceived :: FilePath -> Annex ()
+storeReceived f = do
+	case deserializeKey (takeFileName f) of
+		Nothing -> do
+			warning $ "Received a file " <> QuotedPath (toRawFilePath f) <> " that is not a git-annex key. Deleting this file."
+			liftIO $ removeWhenExistsWith R.removeLink (toRawFilePath f)
+		Just k -> void $ logStatusAfter k $
+			getViaTmpFromDisk RetrievalVerifiableKeysSecure AlwaysVerify k (AssociatedFile Nothing) $ \dest -> unVerified $
+				liftIO $ catchBoolIO $ do
+					R.rename (toRawFilePath f) dest
+					return True
+
+-- Under Windows, uftp uses key containers, which are not files on the
+-- filesystem.
+data UftpKey = KeyFile FilePath | KeyContainer String
+
+uftpKeyParam :: UftpKey -> CommandParam
+uftpKeyParam (KeyFile f) = File f
+uftpKeyParam (KeyContainer s) = Param s
+
+uftpKey :: Annex UftpKey
+#ifdef mingw32_HOST_OS
+uftpKey = do
+	u <- getUUID
+	return $ KeyContainer $ "annex-" ++ fromUUID u
+#else
+uftpKey = KeyFile <$> credsFile "multicast"
+#endif
+
+-- uftp needs a unique UID for each client and server, which 
+-- is a 8 digit hex number in the form "0xnnnnnnnn"
+-- Derive it from the UUID.
+uftpUID :: UUID -> String
+uftpUID u = "0x" ++ (take 8 $ show $ sha2_256 $ B8.fromString (fromUUID u))
+
+withAuthList :: (FilePath -> Annex a) -> Annex a
+withAuthList a = do
+	m <- knownFingerPrints
+	withTmpFile "authlist" $ \t h -> do
+		liftIO $ hPutStr h (genAuthList m)
+		liftIO $ hClose h
+		a t
+
+genAuthList :: M.Map UUID Fingerprint -> String
+genAuthList = unlines . map fmt . M.toList
+  where
+	fmt (u, Fingerprint f) = uftpUID u ++ "|" ++ f
diff --git a/Command/NotifyChanges.hs b/Command/NotifyChanges.hs
new file mode 100644
index 0000000000..d81fabbfde
--- /dev/null
+++ b/Command/NotifyChanges.hs
@@ -0,0 +1,44 @@
+{- git-annex-shell command
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.NotifyChanges where
+
+import Command
+import Annex.ChangedRefs
+import RemoteDaemon.Transport.Ssh.Types
+import Utility.SimpleProtocol
+
+import Control.Concurrent.Async
+
+cmd :: Command
+cmd = noCommit $ 
+	command "notifychanges" SectionPlumbing
+		"sends notification when git refs are changed"
+		paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = go =<< watchChangedRefs
+  where
+	go (Just h) = do
+		-- No messages need to be received from the caller,
+		-- but when it closes the connection, notice and terminate.
+		let receiver = forever $ void $ getProtocolLine stdin
+		let sender = forever $ send . CHANGED =<< waitChangedRefs h
+
+		liftIO $ send READY
+		void $ liftIO $ concurrently sender receiver
+		liftIO $ stopWatchingChangedRefs h
+		stop
+	go Nothing = stop
+
+send :: Notification -> IO ()
+send n = do
+	putStrLn $ unwords $ formatMessage n
+	hFlush stdout
diff --git a/Command/NumCopies.hs b/Command/NumCopies.hs
new file mode 100644
index 0000000000..26772fbef9
--- /dev/null
+++ b/Command/NumCopies.hs
@@ -0,0 +1,53 @@
+{- git-annex command
+ -
+ - Copyright 2014-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.NumCopies where
+
+import Command
+import Annex.NumCopies
+
+cmd :: Command
+cmd = noMessages $ command "numcopies" SectionSetup 
+	"configure desired number of copies"
+	paramNumber (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start = start' "numcopies" startGet startSet
+
+start' :: String -> CommandStart -> (Int -> CommandStart) -> [String] -> CommandStart
+start' _ startget _ [] = startget
+start' setting _ startset [s] = case readish s of
+	Nothing -> giveup $ "Bad number: " ++ s
+	Just n
+		| n > 0 -> startset n
+		| n == 0 -> giveup $ "Cannot set " ++ setting ++ " to 0."
+		| otherwise -> giveup $ setting ++ " cannot be negative!"
+start' _ _ _ _ = giveup "Specify a single number."
+
+startGet :: CommandStart
+startGet = startingCustomOutput (ActionItemOther Nothing) $ next $ do
+	v <- getGlobalNumCopies
+	case v of
+		Just n -> liftIO $ putStrLn $ show $ fromNumCopies n
+		Nothing -> do
+			liftIO $ putStrLn "global numcopies is not set"
+			old <- deprecatedNumCopies
+			case old of
+				Nothing -> liftIO $ putStrLn "(default is 1)"
+				Just n -> liftIO $ putStrLn $ "(deprecated git config annex.numcopies is set to " ++ show (fromNumCopies n) ++ " locally)"
+	return True
+
+startSet :: Int -> CommandStart
+startSet n = startingUsualMessages "numcopies" ai si $ do
+	setGlobalNumCopies $ configuredNumCopies n
+	next $ return True
+  where
+	ai = ActionItemOther (Just $ UnquotedString $ show n)
+	si = SeekInput [show n]
diff --git a/Command/OldKeys.hs b/Command/OldKeys.hs
new file mode 100644
index 0000000000..76bf88e566
--- /dev/null
+++ b/Command/OldKeys.hs
@@ -0,0 +1,104 @@
+{- git-annex command
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.OldKeys where
+
+import Command
+import Git.Types
+import Git.Sha
+import qualified Git.Command
+import qualified Git.DiffTree as DiffTree
+import qualified Annex
+import Annex.CatFile
+import Utility.Terminal
+import qualified Utility.Format
+import qualified Database.Keys
+
+import qualified Data.ByteString.Char8 as S8
+
+cmd :: Command
+cmd = noCommit $
+	command "oldkeys" SectionQuery
+		"list keys used for old versions of files"
+		paramPaths (seek <$$> optParser)
+
+data OldKeysOptions = OldKeysOptions
+	{ fileOptions :: CmdParams
+	, revisionRange :: Maybe String
+	, uncheckedOption :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser OldKeysOptions
+optParser desc = OldKeysOptions
+	<$> cmdParams desc
+	<*> optional (strOption
+		( long "revision-range" <> metavar "RANGE"
+		<> help "limit to a revision range"
+		))
+	<*> switch 
+		( long "unchecked"
+		<> help "don't check if current files use keys"
+		)
+
+seek :: OldKeysOptions -> CommandSeek
+seek o = do
+	isterminal <- liftIO $ checkIsTerminal stdout
+	withdiff $ \l -> 
+		forM_ l $ \i ->
+			when (DiffTree.srcsha i `notElem` nullShas) $ do
+				catKey (DiffTree.srcsha i) >>= \case
+					Just key -> commandAction $ 
+						start o isterminal key
+					Nothing -> return ()
+  where
+  	withdiff a = do
+		(output, cleanup) <- Annex.inRepo $
+			Git.Command.pipeNullSplit ps
+		let l = filter (isfilemode . DiffTree.srcmode)
+			(DiffTree.parseDiffRaw output)
+		r <- a l
+		liftIO $ void cleanup
+		return r
+	
+	ps = 
+		[ Param "log"
+		, Param "-z"
+		-- Don't convert pointer files.
+		, Param "--no-textconv"
+		-- Don't abbreviate hashes.
+		, Param "--no-abbrev"
+		-- Don't show renames.
+		, Param "--no-renames"
+		-- Output the raw diff.
+		, Param "--raw"
+		-- Avoid outputting anything except for the raw diff.
+		, Param "--pretty="
+		]
+		++ case revisionRange o of
+			Nothing -> []
+			Just rr -> [Param rr]
+		++ map File (fileOptions o)
+	
+	isfilemode m = case toTreeItemType m of
+		Just TreeFile -> True
+		Just TreeExecutable -> True
+		Just TreeSymlink -> True
+		_ -> False
+
+start :: OldKeysOptions -> IsTerminal -> Key -> CommandStart
+start o (IsTerminal isterminal) key
+	| uncheckedOption o = go
+	| otherwise = Database.Keys.getAssociatedFiles key >>= \case
+		[] -> go
+		_ -> stop
+  where
+	go = startingCustomOutput key $ do
+		liftIO $ S8.putStrLn $ if isterminal
+			then Utility.Format.encode_c (const False) sk
+			else sk
+		next $ return True
+	sk = serializeKey' key
diff --git a/Command/P2P.hs b/Command/P2P.hs
new file mode 100644
index 0000000000..e51a5e16e1
--- /dev/null
+++ b/Command/P2P.hs
@@ -0,0 +1,314 @@
+{- git-annex command
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.P2P where
+
+import Command
+import P2P.Address
+import P2P.Auth
+import P2P.IO
+import qualified P2P.Protocol as P2P
+import Git.Types
+import qualified Git.Remote
+import qualified Git.Command
+import qualified Annex
+import Annex.UUID
+import Config
+import Utility.AuthToken
+import Utility.Tmp.Dir
+import Utility.FileMode
+import Utility.ThreadScheduler
+import Utility.SafeOutput
+import qualified Utility.RawFilePath as R
+import qualified Utility.MagicWormhole as Wormhole
+
+import Control.Concurrent.Async
+import qualified Data.Text as T
+
+cmd :: Command
+cmd = command "p2p" SectionSetup
+	"configure peer-2-peer links between repositories"
+	paramNothing (seek <$$> optParser)
+
+data P2POpts
+	= GenAddresses
+	| LinkRemote
+	| Pair
+
+optParser :: CmdParamsDesc -> Parser (P2POpts, Maybe RemoteName)
+optParser _ = (,)
+	<$> (pair <|> linkremote <|> genaddresses)
+	<*> optional name
+  where
+	genaddresses = flag' GenAddresses
+		( long "gen-addresses"
+		<> help "generate addresses that allow accessing this repository over P2P networks"
+		)
+	linkremote = flag' LinkRemote
+		( long "link"
+		<> help "set up a P2P link to a git remote"
+		)
+	pair = flag' Pair
+		( long "pair"
+		<> help "pair with another repository"
+		)
+	name = Git.Remote.makeLegalName <$> strOption
+		( long "name"
+		<> metavar paramName
+		<> help "name of remote"
+		)
+
+seek :: (P2POpts, Maybe RemoteName) -> CommandSeek
+seek (GenAddresses, _) = genAddresses =<< loadP2PAddresses
+seek (LinkRemote, Just name) = commandAction $
+	linkRemote name
+seek (LinkRemote, Nothing) = commandAction $
+	linkRemote =<< unusedPeerRemoteName
+seek (Pair, Just name) = commandAction $
+	startPairing name =<< loadP2PAddresses
+seek (Pair, Nothing) = commandAction $ do
+	name <- unusedPeerRemoteName
+	startPairing name =<< loadP2PAddresses
+
+unusedPeerRemoteName :: Annex RemoteName
+unusedPeerRemoteName = go (1 :: Integer) =<< usednames
+  where
+	usednames = mapMaybe remoteName <$> Annex.getGitRemotes
+	go n names = do
+		let name = "peer" ++ show n
+		if name `elem` names
+			then go (n+1) names
+			else return name
+
+-- Only addresses are output to stdout, to allow scripting.
+genAddresses :: [P2PAddress] -> Annex ()
+genAddresses [] = giveup "No P2P networks are currently available."
+genAddresses addrs = do
+	authtoken <- liftIO $ genAuthToken 128
+	storeP2PAuthToken authtoken
+	earlyWarning "These addresses allow access to this git-annex repository. Only share them with people you trust with that access, using trusted communication channels!"
+	liftIO $ putStr $ safeOutput $ unlines $
+		map formatP2PAddress $
+			map (`P2PAddressAuth` authtoken) addrs
+
+-- Address is read from stdin, to avoid leaking it in shell history.
+linkRemote :: RemoteName -> CommandStart
+linkRemote remotename = starting "p2p link" ai si $
+	next promptaddr
+  where
+	ai = ActionItemOther (Just (UnquotedString remotename))
+	si = SeekInput []
+	promptaddr = do
+		liftIO $ putStrLn ""
+		liftIO $ putStr "Enter peer address: "
+		liftIO $ hFlush stdout
+		s <- liftIO getLine
+		if null s
+			then do
+				liftIO $ hPutStrLn stderr "Nothing entered, giving up."
+				return False
+			else case unformatP2PAddress s of
+				Nothing -> do
+					liftIO $ hPutStrLn stderr "Unable to parse that address, please check its format and try again."
+					promptaddr
+				Just addr -> do
+					r <- setupLink remotename addr
+					case r of
+						LinkSuccess -> return True
+						ConnectionError e -> giveup e
+						AuthenticationError e -> giveup e
+
+startPairing :: RemoteName -> [P2PAddress] -> CommandStart
+startPairing _ [] = giveup "No P2P networks are currently available."
+startPairing remotename addrs = ifM (liftIO Wormhole.isInstalled)
+	( starting "p2p pair" ai si $
+		performPairing remotename addrs
+	, giveup "Magic Wormhole is not installed, and is needed for pairing. Install it from your distribution or from https://github.com/warner/magic-wormhole/"
+	)
+  where
+	ai = ActionItemOther (Just (UnquotedString remotename))
+	si = SeekInput []
+
+performPairing :: RemoteName -> [P2PAddress] -> CommandPerform
+performPairing remotename addrs = do
+	-- This note is displayed mainly so when magic wormhole
+	-- complains about possible protocol mismatches or other problems,
+	-- it's clear what's doing the complaining.
+	showNote "using Magic Wormhole"
+	next $ do
+		showOutput
+		r <- wormholePairing remotename addrs ui
+		case r of
+			PairSuccess -> return True
+			SendFailed -> do
+				warning "Failed sending data to pair."
+				return False
+			ReceiveFailed -> do
+				warning "Failed receiving data from pair."
+				return False
+			LinkFailed e -> do
+				warning $ UnquotedString $ "Failed linking to pair: " ++ e
+				return False
+  where
+	ui observer producer = do
+		ourcode <- Wormhole.waitCode observer
+		putStrLn ""
+		putStrLn $ "This repository's pairing code is: " ++
+			Wormhole.fromCode ourcode
+		putStrLn ""
+		theircode <- getcode ourcode
+		Wormhole.sendCode producer theircode
+	
+	getcode ourcode = do
+		putStr "Enter the other repository's pairing code: "
+		hFlush stdout
+		l <- getLine
+		case Wormhole.toCode l of
+			Just code
+				| code /= ourcode -> do
+					putStrLn "Exchanging pairing data..."
+					return code
+				| otherwise -> do
+					putStrLn "Oops -- You entered this repository's pairing code. Enter the pairing code of the *other* repository."
+					getcode ourcode
+			Nothing -> do
+				putStrLn "That does not look like a valiad pairing code. Try again..."
+				getcode ourcode
+
+-- We generate half of the authtoken; the pair will provide
+-- the other half.
+newtype HalfAuthToken = HalfAuthToken T.Text
+	deriving (Show)
+
+data PairData = PairData HalfAuthToken [P2PAddress]
+	deriving (Show)
+
+serializePairData :: PairData -> String
+serializePairData (PairData (HalfAuthToken ha) addrs) = unlines $
+	T.unpack ha : map formatP2PAddress addrs
+
+deserializePairData :: String -> Maybe PairData
+deserializePairData s = case lines s of
+	[] -> Nothing
+	(ha:l) -> do
+		addrs <- mapM unformatP2PAddress l
+		return (PairData (HalfAuthToken (T.pack ha)) addrs)
+
+data PairingResult
+	= PairSuccess
+	| SendFailed
+	| ReceiveFailed
+	| LinkFailed String
+
+wormholePairing
+	:: RemoteName
+	-> [P2PAddress]
+	-> (Wormhole.CodeObserver -> Wormhole.CodeProducer -> IO ())
+	-> Annex PairingResult
+wormholePairing remotename ouraddrs ui = do
+	ourhalf <- liftIO $ HalfAuthToken . fromAuthToken
+		<$> genAuthToken 64
+	let ourpairdata = PairData ourhalf ouraddrs
+
+	-- The magic wormhole interface only supports exchanging
+	-- files. Permissions of received files may allow others
+	-- to read them. So, set up a temp directory that only
+	-- we can read.
+	withTmpDir "pair" $ \tmp -> do
+		liftIO $ void $ tryIO $ modifyFileMode (toRawFilePath tmp) $ 
+			removeModes otherGroupModes
+		let sendf = tmp </> "send"
+		let recvf = tmp </> "recv"
+		liftIO $ writeFileProtected (toRawFilePath sendf) $
+			serializePairData ourpairdata
+
+		observer <- liftIO Wormhole.mkCodeObserver
+		producer <- liftIO Wormhole.mkCodeProducer
+		void $ liftIO $ async $ ui observer producer
+		-- Provide an appid to magic wormhole, to avoid using
+		-- the same channels that other wormhole users use.
+		let appid = Wormhole.appId "git-annex.branchable.com/p2p-setup"
+		(sendres, recvres) <- liftIO $
+			Wormhole.sendFile sendf observer appid
+				`concurrently`
+			Wormhole.receiveFile recvf producer appid
+		liftIO $ removeWhenExistsWith R.removeLink (toRawFilePath sendf)
+		if sendres /= True
+			then return SendFailed
+			else if recvres /= True
+				then return ReceiveFailed
+				else do
+					r <- liftIO $ tryIO $
+						readFileStrict recvf
+					case r of
+						Left _e -> return ReceiveFailed
+						Right s -> maybe 
+							(return ReceiveFailed)
+							(finishPairing 100 remotename ourhalf)
+							(deserializePairData s)
+
+-- | Allow the peer we're pairing with to authenticate to us,
+-- using an authtoken constructed from the two HalfAuthTokens.
+-- Connect to the peer we're pairing with, and try to link to them.
+--
+-- Multiple addresses may have been received for the peer. This only
+-- makes a link to one address.
+--
+-- Since we're racing the peer as they do the same, the first try is likely
+-- to fail to authenticate. Can retry any number of times, to avoid the
+-- users needing to redo the whole process.
+finishPairing :: Int -> RemoteName -> HalfAuthToken -> PairData -> Annex PairingResult
+finishPairing retries remotename (HalfAuthToken ourhalf) (PairData (HalfAuthToken theirhalf) theiraddrs) = do
+	case (toAuthToken (ourhalf <> theirhalf), toAuthToken (theirhalf <> ourhalf)) of
+		(Just ourauthtoken, Just theirauthtoken) -> do
+			liftIO $ putStrLn $ "Successfully exchanged pairing data. Connecting to " ++ remotename ++  "..."
+			storeP2PAuthToken ourauthtoken
+			go retries theiraddrs theirauthtoken
+		_ -> return ReceiveFailed
+  where
+	go 0 [] _ = return $ LinkFailed $ "Unable to connect to " ++ remotename ++ "."
+	go n [] theirauthtoken = do
+		liftIO $ threadDelaySeconds (Seconds 2)
+		liftIO $ putStrLn $ "Unable to connect to " ++ remotename ++ ". Retrying..."
+		go (n-1) theiraddrs theirauthtoken
+	go n (addr:rest) theirauthtoken = do
+		r <- setupLink remotename (P2PAddressAuth addr theirauthtoken)
+		case r of
+			LinkSuccess -> return PairSuccess
+			_ -> go n rest theirauthtoken
+
+data LinkResult
+	= LinkSuccess
+	| ConnectionError String
+	| AuthenticationError String
+
+setupLink :: RemoteName -> P2PAddressAuth -> Annex LinkResult
+setupLink remotename (P2PAddressAuth addr authtoken) = do
+	g <- Annex.gitRepo
+	cv <- liftIO $ tryNonAsync $ connectPeer g addr
+	case cv of
+		Left e -> return $ ConnectionError $ "Unable to connect with peer. Please check that the peer is connected to the network, and try again. ("  ++ show e ++ ")"
+		Right conn -> do
+			u <- getUUID
+			let proto = P2P.auth u authtoken noop
+			runst <- liftIO $ mkRunState Client
+			go =<< liftIO (runNetProto runst conn proto)
+  where
+	go (Right (Just theiruuid)) = do
+		ok <- inRepo $ Git.Command.runBool
+			[ Param "remote", Param "add"
+			, Param remotename
+			, Param (formatP2PAddress addr)
+			]
+		when ok $ do
+			storeUUIDIn (remoteAnnexConfig remotename "uuid") theiruuid
+			storeP2PRemoteAuthToken addr authtoken
+		return LinkSuccess
+	go (Right Nothing) = return $ AuthenticationError "Unable to authenticate with peer. Please check the address and try again."
+	go (Left e) = return $ AuthenticationError $ "Unable to authenticate with peer: " ++ describeProtoFailure e
diff --git a/Command/P2PStdIO.hs b/Command/P2PStdIO.hs
new file mode 100644
index 0000000000..c8b4a64b63
--- /dev/null
+++ b/Command/P2PStdIO.hs
@@ -0,0 +1,50 @@
+{- git-annex command
+ -
+ - Copyright 2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.P2PStdIO where
+
+import Command
+import P2P.IO
+import P2P.Annex
+import qualified P2P.Protocol as P2P
+import qualified Annex
+import Annex.UUID
+import qualified CmdLine.GitAnnexShell.Checks as Checks
+
+import System.IO.Error
+
+cmd :: Command
+cmd = noMessages $ command "p2pstdio" SectionPlumbing
+	"communicate in P2P protocol over stdio"
+	paramUUID (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek [u] = commandAction $ start $ toUUID u
+seek _ = giveup "missing UUID parameter"
+
+start :: UUID -> CommandStart
+start theiruuid = startingCustomOutput (ActionItemOther Nothing) $ do
+	servermode <- liftIO $ do
+		ro <- Checks.checkEnvSet Checks.readOnlyEnv
+		ao <- Checks.checkEnvSet Checks.appendOnlyEnv
+		return $ case (ro, ao) of
+			(True, _) -> P2P.ServeReadOnly
+			(False, True) -> P2P.ServeAppendOnly
+			(False, False) -> P2P.ServeReadWrite
+	myuuid <- getUUID
+	conn <- stdioP2PConnection <$> Annex.gitRepo
+	let server = do
+		P2P.net $ P2P.sendMessage (P2P.AUTH_SUCCESS myuuid)
+		P2P.serveAuthed servermode myuuid
+	runst <- liftIO $ mkRunState $ Serving theiruuid Nothing
+	runFullProto runst conn server >>= \case
+		Right () -> done
+		-- Avoid displaying an error when the client hung up on us.
+		Left (ProtoFailureIOError e) | isEOFError e -> done
+		Left e -> giveup (describeProtoFailure e)
+  where
+	done = next $ return True
diff --git a/Command/PostReceive.hs b/Command/PostReceive.hs
new file mode 100644
index 0000000000..fd92bae4a4
--- /dev/null
+++ b/Command/PostReceive.hs
@@ -0,0 +1,58 @@
+{- git-annex command
+ -
+ - Copyright 2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.PostReceive where
+
+import Command
+import qualified Annex
+import Git.Types
+import Annex.UpdateInstead
+import Annex.CurrentBranch
+import Command.Sync (mergeLocal, prepMerge, mergeConfig, SyncOptions(..))
+
+-- This does not need to modify the git-annex branch to update the 
+-- work tree, but auto-initialization might change the git-annex branch.
+-- Since it would be surprising for a post-receive hook to make such a
+-- change, that's prevented by noCommit.
+cmd :: Command
+cmd = noCommit $
+	command "post-receive" SectionPlumbing
+		"run by git post-receive hook"
+		paramNothing
+		(withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek _ = whenM needUpdateInsteadEmulation $ do
+	fixPostReceiveHookEnv
+	commandAction updateInsteadEmulation
+
+{- When run by the post-receive hook, the cwd is the .git directory, 
+ - and GIT_DIR=. It's not clear why git does this.
+ -
+ - Fix up from that unusual situation, so that git commands
+ - won't try to treat .git as the work tree. -}
+fixPostReceiveHookEnv :: Annex ()
+fixPostReceiveHookEnv = do
+	g <- Annex.gitRepo
+	case location g of
+		Local { gitdir = ".", worktree = Just "." } ->
+			Annex.adjustGitRepo $ \g' -> pure $ g'
+				{ location = case location g' of
+					loc@(Local {}) -> loc 
+						{ worktree = Just ".." }
+					loc -> loc
+				}
+		_ -> noop
+
+updateInsteadEmulation :: CommandStart
+updateInsteadEmulation = do
+	prepMerge
+	let o = def { notOnlyAnnexOption = True }
+	mc <- mergeConfig False
+	mergeLocal mc o =<< getCurrentBranch
diff --git a/Command/PreCommit.hs b/Command/PreCommit.hs
new file mode 100644
index 0000000000..bc69e4a210
--- /dev/null
+++ b/Command/PreCommit.hs
@@ -0,0 +1,88 @@
+{- git-annex command
+ -
+ - Copyright 2010-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Command.PreCommit where
+
+import Command
+import qualified Command.Fix
+import qualified Command.Smudge
+import Annex.Hook
+import Annex.Link
+import Annex.View
+import Annex.View.ViewedFile
+import Logs.View
+import Logs.MetaData
+import Types.View
+import Types.MetaData
+import qualified Annex
+import qualified Annex.Branch
+
+import qualified Data.Set as S
+import qualified Data.Text as T
+
+cmd :: Command
+cmd = noCommit $ command "pre-commit" SectionPlumbing
+	"run by git pre-commit hook"
+	paramPaths
+	(withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek ps = do
+	let ww = WarnUnmatchWorkTreeItems "pre-commit"
+	l <- workTreeItems ww ps
+	-- fix symlinks to files being committed
+	flip (withFilesToBeCommitted ww) l $ \(si, f) -> commandAction $
+		maybe stop (Command.Fix.start Command.Fix.FixSymlinks si f)
+			=<< isAnnexLink f
+	-- after a merge conflict or git cherry-pick or stash, pointer
+	-- files in the worktree won't be populated, so populate them here
+	Command.Smudge.updateSmudged (Restage False)
+	
+	runAnnexHook preCommitAnnexHook
+
+	-- committing changes to a view updates metadata
+	currentView >>= \case
+		Nothing -> noop
+		Just (v, _madj) -> do
+			withViewChanges
+				(addViewMetaData v)
+				(removeViewMetaData v)
+			-- Manually commit in this case, because
+			-- noCommit prevents automatic commit.
+			whenM (annexAlwaysCommit <$> Annex.getGitConfig) $
+				Annex.Branch.commit =<< Annex.Branch.commitMessage
+
+addViewMetaData :: View -> ViewedFile -> Key -> CommandStart
+addViewMetaData v f k = starting "metadata" ai si $
+	next $ changeMetaData k $ fromView v f
+  where
+	ai = mkActionItem (k, toRawFilePath f)
+	si = SeekInput []
+
+removeViewMetaData :: View -> ViewedFile -> Key -> CommandStart
+removeViewMetaData v f k = starting "metadata" ai si $
+	next $ changeMetaData k $ unsetMetaData $ fromView v f
+  where
+	ai = mkActionItem (k, toRawFilePath f)
+	si = SeekInput []
+
+changeMetaData :: Key -> MetaData -> CommandCleanup
+changeMetaData k metadata = do
+	showMetaDataChange metadata
+	addMetaData k metadata
+	return True
+
+showMetaDataChange :: MetaData -> Annex ()
+showMetaDataChange = showLongNote . UnquotedString . unlines . concatMap showmeta . fromMetaData
+  where
+	showmeta (f, vs) = map (showmetavalue f) $ S.toList vs
+	showmetavalue f v = T.unpack (fromMetaField f) <> showset v <> "=" <> decodeBS (fromMetaValue v)
+	showset v
+		| isSet v = "+"
+		| otherwise = "-"
diff --git a/Command/Proxy.hs b/Command/Proxy.hs
new file mode 100644
index 0000000000..4ccab2f8fa
--- /dev/null
+++ b/Command/Proxy.hs
@@ -0,0 +1,23 @@
+{- git-annex command
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Proxy where
+
+import Command
+
+cmd :: Command
+cmd = notBareRepo $
+	command "proxy" SectionPlumbing 
+		"safely bypass direct mode guard (deprecated)"
+		("-- git command") (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start [] = giveup "Did not specify command to run."
+start (c:ps) = liftIO $ exitWith =<< safeSystem c (map Param ps)
diff --git a/Command/Pull.hs b/Command/Pull.hs
new file mode 100644
index 0000000000..396bc14e54
--- /dev/null
+++ b/Command/Pull.hs
@@ -0,0 +1,17 @@
+{- git-annex command
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Pull (cmd) where
+
+import Command
+import Command.Sync hiding (cmd)
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, backendOption] $
+	command "pull" SectionCommon 
+		"pull content from remotes"
+		(paramRepeating paramRemote) (seek <--< optParser PullMode)
diff --git a/Command/Push.hs b/Command/Push.hs
new file mode 100644
index 0000000000..f4bcc651d4
--- /dev/null
+++ b/Command/Push.hs
@@ -0,0 +1,17 @@
+{- git-annex command
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Push (cmd) where
+
+import Command
+import Command.Sync hiding (cmd)
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, backendOption] $
+	command "push" SectionCommon 
+		"push content to remotes"
+		(paramRepeating paramRemote) (seek <--< optParser PushMode)
diff --git a/Command/ReKey.hs b/Command/ReKey.hs
new file mode 100644
index 0000000000..6698ad1656
--- /dev/null
+++ b/Command/ReKey.hs
@@ -0,0 +1,154 @@
+{- git-annex command
+ -
+ - Copyright 2012-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.ReKey where
+
+import Command
+import qualified Annex
+import Annex.Content
+import Annex.Ingest
+import Annex.Link
+import Annex.Perms
+import Annex.ReplaceFile
+import Logs.Location
+import Annex.InodeSentinal
+import Annex.WorkTree
+import Logs.Migrate
+import Utility.InodeCache
+import qualified Utility.RawFilePath as R
+
+import System.PosixCompat.Files (linkCount, fileMode)
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $ 
+	command "rekey" SectionPlumbing
+		"change keys used for files"
+		(paramRepeating $ paramPair paramPath paramKey)
+		(seek <$$> optParser)
+
+data ReKeyOptions = ReKeyOptions
+	{ reKeyThese :: CmdParams
+	, batchOption :: BatchMode
+	}
+
+optParser :: CmdParamsDesc -> Parser ReKeyOptions
+optParser desc = ReKeyOptions
+	<$> cmdParams desc
+	<*> parseBatchOption False
+
+-- Split on the last space, since a FilePath can contain whitespace,
+-- but a Key very rarely does.
+batchParser :: String -> Annex (Either String (RawFilePath, Key))
+batchParser s = case separate (== ' ') (reverse s) of
+	(rk, rf)
+		| null rk || null rf -> return $ Left "Expected: \"file key\""
+		| otherwise -> case deserializeKey (reverse rk) of
+			Nothing -> return $ Left "bad key"
+			Just k -> do
+				let f = reverse rf
+				f' <- liftIO $ relPathCwdToFile (toRawFilePath f)
+				return $ Right (f', k)
+
+seek :: ReKeyOptions -> CommandSeek
+seek o = case batchOption o of
+	Batch fmt -> batchOnly Nothing (reKeyThese o) $
+		batchInput fmt batchParser
+			(batchCommandAction . uncurry start)
+	NoBatch -> withPairs 
+		(\(si, p) -> commandAction (start si (parsekey p))) 
+		(reKeyThese o)
+  where
+	parsekey (file, skey) =
+		(toRawFilePath file, fromMaybe (giveup "bad key") (deserializeKey skey))
+
+start :: SeekInput -> (RawFilePath, Key) -> CommandStart
+start si (file, newkey) = lookupKey file >>= \case
+	Just k -> go k
+	Nothing -> stop
+  where
+	go oldkey
+		| oldkey == newkey = stop
+		| otherwise = starting "rekey" ai si $
+			perform file oldkey newkey
+
+	ai = ActionItemTreeFile file
+
+perform :: RawFilePath -> Key -> Key -> CommandPerform
+perform file oldkey newkey = do
+	ifM (inAnnex oldkey) 
+		( unlessM (linkKey file oldkey newkey) $
+			giveup "failed creating link from old to new key"
+		, unlessM (Annex.getRead Annex.force) $ do
+			qp <- coreQuotePath <$> Annex.getGitConfig
+			giveup $ decodeBS $ quote qp $ QuotedPath file
+				<> " is not available (use --force to override)"
+		)
+	next $ cleanup file newkey $ const noop
+
+{- Make a hard link to the old key content (when supported),
+ - to avoid wasting disk space. -}
+linkKey :: RawFilePath -> Key -> Key -> Annex Bool
+linkKey file oldkey newkey = ifM (isJust <$> isAnnexLink file)
+	( linkKey' DefaultVerify oldkey newkey
+	, do
+	 	{- The file being rekeyed is itself an unlocked file; if
+		 - it's hard linked to the old key, that link must be broken. -}
+		oldobj <- calcRepo (gitAnnexLocation oldkey)
+		v <- tryNonAsync $ do
+			st <- liftIO $ R.getFileStatus file
+			when (linkCount st > 1) $ do
+				freezeContent oldobj
+				replaceWorkTreeFile (fromRawFilePath file) $ \tmp -> do
+					unlessM (checkedCopyFile oldkey oldobj tmp Nothing) $
+						giveup "can't lock old key"
+					thawContent tmp
+		ic <- withTSDelta (liftIO . genInodeCache file)
+		case v of
+			Left e -> do
+				warning (UnquotedString (show e))
+				return False
+			Right () -> do
+				r <- linkToAnnex newkey file ic
+				return $ case r of
+					LinkAnnexFailed -> False
+					LinkAnnexOk -> True
+					LinkAnnexNoop -> True
+	)
+
+ {- If the object file is already hardlinked to elsewhere, a hard
+ - link won't be made by getViaTmpFromDisk, but a copy instead.
+ - This avoids hard linking to content linked to an
+ - unlocked file, which would leave the new key unlocked
+ - and vulnerable to corruption. -}
+linkKey' :: VerifyConfig -> Key -> Key -> Annex Bool
+linkKey' v oldkey newkey =
+	getViaTmpFromDisk RetrievalAllKeysSecure v newkey (AssociatedFile Nothing) $ \tmp -> unVerified $ do
+		oldobj <- calcRepo (gitAnnexLocation oldkey)
+		isJust <$> linkOrCopy' (return True) newkey oldobj tmp Nothing
+
+cleanup :: RawFilePath -> Key -> (MigrationRecord -> Annex ()) -> CommandCleanup
+cleanup file newkey a = do
+	newkeyrec <- ifM (isJust <$> isAnnexLink file)
+		( do
+			-- Update symlink to use the new key.
+			sha <- genSymlink file newkey Nothing
+			stageSymlink file sha
+			return (MigrationRecord sha)
+		, do
+			mode <- liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus file
+			liftIO $ whenM (isJust <$> isPointerFile file) $
+				writePointerFile file newkey mode
+			sha <- hashPointerFile newkey
+			stagePointerFile file mode sha
+			return (MigrationRecord sha)
+		)
+	whenM (inAnnex newkey) $
+		logStatus newkey InfoPresent
+	a newkeyrec
+	return True
diff --git a/Command/ReadPresentKey.hs b/Command/ReadPresentKey.hs
new file mode 100644
index 0000000000..46b5b7bb80
--- /dev/null
+++ b/Command/ReadPresentKey.hs
@@ -0,0 +1,31 @@
+{- git-annex command
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.ReadPresentKey where
+
+import Command
+import Logs.Location
+
+cmd :: Command
+cmd = noCommit $ 
+	command "readpresentkey" SectionPlumbing
+		"read records of where key is present"
+		(paramPair paramKey paramUUID)
+		(withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start (ks:us:[]) = do
+	ls <- loggedLocations k
+	if toUUID us `elem` ls
+		then liftIO exitSuccess
+		else liftIO exitFailure
+  where
+	k = fromMaybe (giveup "bad key") (deserializeKey ks)
+start _ = giveup "Wrong number of parameters"
diff --git a/Command/RecvKey.hs b/Command/RecvKey.hs
new file mode 100644
index 0000000000..8d58ae29bf
--- /dev/null
+++ b/Command/RecvKey.hs
@@ -0,0 +1,42 @@
+{- git-annex command
+ -
+ - Copyright 2010 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.RecvKey where
+
+import Command
+import Annex.Content
+import Annex.Action
+import Annex
+import Utility.Rsync
+import Types.Transfer
+import Logs.Location
+import Command.SendKey (fieldTransfer)
+
+cmd :: Command
+cmd = noCommit $ command "recvkey" SectionPlumbing 
+	"runs rsync in server mode to receive content"
+	paramKey (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withKeys (commandAction . start)
+
+start :: (SeekInput, Key) -> CommandStart
+start (_, key) = fieldTransfer Download key $ \_p -> do
+	-- This matches the retrievalSecurityPolicy of Remote.Git
+	let rsp = RetrievalAllKeysSecure
+	ifM (getViaTmp rsp DefaultVerify key (AssociatedFile Nothing) Nothing go)
+		( do
+			logStatus key InfoPresent
+			_ <- quiesce True
+			return True
+		, return False
+		)
+  where
+	go tmp = unVerified $ do
+		opts <- filterRsyncSafeOptions . maybe [] words
+			<$> getField "RsyncOptions"
+		liftIO $ rsyncServerReceive (map Param opts) (fromRawFilePath tmp)
diff --git a/Command/RegisterUrl.hs b/Command/RegisterUrl.hs
new file mode 100644
index 0000000000..4cdac7c555
--- /dev/null
+++ b/Command/RegisterUrl.hs
@@ -0,0 +1,90 @@
+{- git-annex command
+ -
+ - Copyright 2015-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.RegisterUrl where
+
+import Command
+import Logs.Web
+import Logs.Location
+import Command.FromKey (keyOpt, keyOpt')
+import qualified Remote
+import Annex.UUID
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $ command "registerurl"
+	SectionPlumbing "registers an url for a key"
+	(paramPair paramKey paramUrl)
+	(seek <$$> optParser)
+
+data RegisterUrlOptions = RegisterUrlOptions
+	{ keyUrlPairs :: CmdParams
+	, batchOption :: BatchMode
+	, remoteOption :: Maybe (DeferredParse Remote)
+	}
+
+optParser :: CmdParamsDesc -> Parser RegisterUrlOptions
+optParser desc = RegisterUrlOptions
+	<$> cmdParams desc
+	<*> parseBatchOption False
+	<*> optional (mkParseRemoteOption <$> parseRemoteOption)
+
+seek :: RegisterUrlOptions -> CommandSeek
+seek o = case (batchOption o, keyUrlPairs o) of
+	(Batch fmt, _) -> seekBatch registerUrl o fmt
+	-- older way of enabling batch input, does not support BatchNull
+	(NoBatch, []) -> seekBatch registerUrl o (BatchFormat BatchLine (BatchKeys False))
+	(NoBatch, ps) -> commandAction (start registerUrl o ps)
+
+seekBatch :: (Remote -> Key -> URLString -> Annex ()) -> RegisterUrlOptions -> BatchFormat -> CommandSeek
+seekBatch a o fmt = batchOnly Nothing (keyUrlPairs o) $
+	batchInput fmt (pure . parsebatch) $
+		batchCommandAction . start' a o
+  where
+	parsebatch l = 
+		let (keyname, u) = separate (== ' ') l
+		in if null u
+			then Left "no url provided"
+			else case keyOpt' keyname of
+				Left e -> Left e
+				Right k -> Right (k, u)
+
+start :: (Remote -> Key -> URLString -> Annex ()) -> RegisterUrlOptions -> [String] -> CommandStart
+start a o (keyname:url:[]) = start' a o (si, (keyOpt keyname, url))
+  where
+	si = SeekInput [keyname, url]
+start _ _ _ = giveup "specify a key and an url"
+
+start' :: (Remote -> Key -> URLString -> Annex ()) -> RegisterUrlOptions -> (SeekInput, (Key, URLString)) -> CommandStart
+start' a o (si, (key, url)) =
+	starting "registerurl" ai si $
+		perform a o key url
+  where
+	ai = ActionItemOther (Just (UnquotedString url))
+
+perform :: (Remote -> Key -> URLString -> Annex ()) -> RegisterUrlOptions -> Key -> URLString -> CommandPerform
+perform a o key url = do
+	needremote <- maybe (pure Nothing) (Just <$$> getParsed) (remoteOption o)
+	r <- case needremote of
+		Just nr | Remote.uuid nr == webUUID -> pure nr
+		_ -> Remote.claimingUrl url
+	case needremote of
+		Just nr | nr /= r -> do
+			showNote $ UnquotedString $ "The url " ++ url ++ " is claimed by remote " ++ Remote.name r
+			next $ return False
+		_ -> do
+			a r key (setDownloader' url r)
+			next $ return True
+
+registerUrl :: Remote -> Key -> String -> Annex ()
+registerUrl remote key url = do
+	setUrlPresent key url
+	-- setUrlPresent only updates location tracking when the url
+	-- does not have an OtherDownloader, but this command needs to do
+	-- it for urls claimed by other remotes as well.
+	case snd (getDownloader url) of
+		OtherDownloader -> logChange key (Remote.uuid remote) InfoPresent
+		_ -> return ()
diff --git a/Command/Reinit.hs b/Command/Reinit.hs
new file mode 100644
index 0000000000..bdc1a6b1c9
--- /dev/null
+++ b/Command/Reinit.hs
@@ -0,0 +1,41 @@
+{- git-annex command
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Reinit where
+
+import Command
+import Annex.Init
+import Annex.UUID
+import qualified Remote
+import qualified Annex.SpecialRemote
+	
+cmd :: Command
+cmd = dontCheck repoExists $ withAnnexOptions [jsonOptions] $
+	command "reinit" SectionUtility 
+		"initialize repository, reusing old UUID"
+		(paramUUID ++ "|" ++ paramDesc)
+		(withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start ws = starting "reinit" ai (SeekInput ws) $
+	perform s
+  where
+	ai = ActionItemOther (Just (UnquotedString s))
+	s = unwords ws
+
+perform :: String -> CommandPerform
+perform s = do
+	u <- if isUUID s
+		then return $ toUUID s
+		else Remote.nameToUUID s
+	storeUUID u
+	checkInitializeAllowed $ initialize' Nothing
+	Annex.SpecialRemote.autoEnable
+	next $ return True
diff --git a/Command/Reinject.hs b/Command/Reinject.hs
new file mode 100644
index 0000000000..7385eaedd5
--- /dev/null
+++ b/Command/Reinject.hs
@@ -0,0 +1,137 @@
+{- git-annex command
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Reinject where
+
+import Command
+import Logs.Location
+import Annex.Content
+import Backend
+import Types.KeySource
+import Utility.Metered
+import Annex.WorkTree
+import qualified Git
+import qualified Annex
+
+cmd :: Command
+cmd = withAnnexOptions [backendOption, jsonOptions] $
+	command "reinject" SectionUtility 
+		"inject content of file back into annex"
+		(paramRepeating (paramPair "SRC" "DEST"))
+		(seek <$$> optParser)
+
+data ReinjectOptions = ReinjectOptions
+	{ params :: CmdParams
+	, knownOpt :: Bool
+	, guessKeysOpt :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser ReinjectOptions
+optParser desc = ReinjectOptions
+	<$> cmdParams desc
+	<*> switch
+		( long "known"
+		<> help "inject all known files"
+		<> hidden
+		)
+	<*> switch
+		( long "guesskeys"
+		<> help "inject files that are named like keys"
+		<> hidden
+		)
+
+seek :: ReinjectOptions -> CommandSeek
+seek os
+	| guessKeysOpt os && knownOpt os = giveup "Cannot combine --known with --guesskeys"
+	| guessKeysOpt os = withStrings (commandAction . startGuessKeys) (params os)
+	| knownOpt os = withStrings (commandAction . startKnown) (params os)
+	| otherwise = withPairs (commandAction . startSrcDest) (params os)
+
+startSrcDest :: (SeekInput, (String, String)) -> CommandStart
+startSrcDest (si, (src, dest))
+	| src == dest = stop
+	| otherwise = starting "reinject" ai si $ notAnnexed src' $
+		lookupKey (toRawFilePath dest) >>= \case
+			Just key -> ifM (verifyKeyContent key src')
+				( perform src' key
+				, do
+					qp <- coreQuotePath <$> Annex.getGitConfig
+					giveup $ decodeBS $ quote qp $ QuotedPath src'
+						<> " does not have expected content of "
+						<> QuotedPath (toRawFilePath dest)
+				)
+			Nothing -> do
+				qp <- coreQuotePath <$> Annex.getGitConfig
+				giveup $ decodeBS $ quote qp $ QuotedPath src'
+					<> " is not an annexed file"
+  where
+	src' = toRawFilePath src
+	ai = ActionItemOther (Just (QuotedPath src'))
+
+startGuessKeys :: FilePath -> CommandStart
+startGuessKeys src = starting "reinject" ai si $ notAnnexed src' $
+	case fileKey (toRawFilePath (takeFileName src)) of
+		Just key -> ifM (verifyKeyContent key src')
+			( perform src' key
+			, do
+				qp <- coreQuotePath <$> Annex.getGitConfig
+				giveup $ decodeBS $ quote qp $ QuotedPath src'
+					<> " does not have expected content"
+			)
+		Nothing -> do
+			warning "Not named like an object file; skipping"
+			next $ return True
+  where
+	src' = toRawFilePath src
+	ai = ActionItemOther (Just (QuotedPath src'))
+	si = SeekInput [src]
+
+startKnown :: FilePath -> CommandStart
+startKnown src = starting "reinject" ai si $ notAnnexed src' $ do
+	(key, _) <- genKey ks nullMeterUpdate =<< defaultBackend
+	ifM (isKnownKey key)
+		( perform src' key
+		, do
+			warning "Not known content; skipping"
+			next $ return True
+		)
+  where
+	src' = toRawFilePath src
+	ks = KeySource src' src' Nothing
+	ai = ActionItemOther (Just (QuotedPath src'))
+	si = SeekInput [src]
+
+notAnnexed :: RawFilePath -> CommandPerform -> CommandPerform
+notAnnexed src a = 
+	ifM (fromRepo Git.repoIsLocalBare)
+		( a
+		, lookupKey src >>= \case
+			Just _ -> do
+				qp <- coreQuotePath <$> Annex.getGitConfig
+				giveup $ decodeBS $ quote qp $ 
+					"cannot used annexed file as src: "
+						<> QuotedPath src
+			Nothing -> a
+		)
+
+perform :: RawFilePath -> Key -> CommandPerform
+perform src key = do
+	maybeAddJSONField "key" (serializeKey key)
+	ifM move
+		( next $ cleanup key
+		, giveup "failed"
+		)
+  where
+	move = checkDiskSpaceToGet key Nothing False $
+		moveAnnex key (AssociatedFile Nothing) src
+
+cleanup :: Key -> CommandCleanup
+cleanup key = do
+	logStatus key InfoPresent
+	return True
diff --git a/Command/RemoteDaemon.hs b/Command/RemoteDaemon.hs
new file mode 100644
index 0000000000..03f5eaaf3d
--- /dev/null
+++ b/Command/RemoteDaemon.hs
@@ -0,0 +1,38 @@
+{- git-annex command
+ -
+ - Copyright 2014-2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Command.RemoteDaemon where
+
+import Command
+import RemoteDaemon.Core
+import Utility.Daemon
+#ifndef mingw32_HOST_OS
+import Annex.Path
+import Utility.OpenFd
+#endif
+
+cmd :: Command
+cmd = noCommit $
+	command "remotedaemon" SectionCommon
+		"persistent communication with remotes"
+		paramNothing (run <$$> const (parseDaemonOptions False))
+
+run :: DaemonOptions -> CommandSeek
+run o
+	| stopDaemonOption o = giveup "--stop not implemented for remotedaemon"
+	| foregroundDaemonOption o = liftIO runInteractive
+	| otherwise = do
+#ifndef mingw32_HOST_OS
+		git_annex <- liftIO programPath
+		ps <- gitAnnexDaemonizeParams
+		let logfd = openFdWithMode (toRawFilePath "/dev/null") ReadOnly Nothing defaultFileFlags
+		liftIO $ daemonize git_annex ps logfd Nothing False runNonInteractive
+#else
+		liftIO $ foreground Nothing runNonInteractive	
+#endif
diff --git a/Command/RenameRemote.hs b/Command/RenameRemote.hs
new file mode 100644
index 0000000000..989cb3df9e
--- /dev/null
+++ b/Command/RenameRemote.hs
@@ -0,0 +1,59 @@
+{- git-annex command
+ -
+ - Copyright 2019-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.RenameRemote where
+
+import Command
+import qualified Annex.SpecialRemote
+import Annex.SpecialRemote.Config (nameField, sameasNameField)
+import qualified Logs.Remote
+import qualified Types.Remote as R
+import qualified Remote
+import Types.ProposedAccepted
+
+import qualified Data.Map as M
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "renameremote" SectionSetup
+		"changes name of special remote"
+		(paramPair paramName paramName)
+		(withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start ps@(oldname:newname:[]) = Annex.SpecialRemote.findExisting oldname >>= \case
+	((u, cfg, mcu):[]) -> Annex.SpecialRemote.findExisting newname >>= \case
+		[] -> go u cfg mcu
+		_ -> giveup $ "The name " ++ newname ++ " is already used by a special remote."
+	-- Support lookup by uuid or description as well as remote name,
+	-- as a fallback when there is nothing with the name in the
+	-- special remote log.
+	[] -> Remote.nameToUUID' oldname >>= \case
+		([u], _) -> do
+			m <- Logs.Remote.remoteConfigMap
+			case M.lookup u m of
+				Nothing -> giveup "That is not a special remote."
+				Just cfg -> go u cfg Nothing
+		(_, msg) -> giveup msg
+	_ -> giveup $ "There are multiple special remotes named " ++ oldname ++ ". Provide instead the uuid or description of the remote to rename."
+  where
+	ai = ActionItemOther Nothing
+	si = SeekInput ps
+	go u cfg mcu = starting "rename" ai si $ perform u cfg mcu newname
+start _ = giveup "Specify an old name (or uuid or description) and a new name."
+
+perform :: UUID -> R.RemoteConfig -> Maybe (Annex.SpecialRemote.ConfigFrom UUID) -> String -> CommandPerform
+perform u cfg mcu newname = do
+	let (namefield, cu) = case mcu of
+		Nothing -> (nameField, u)
+		Just (Annex.SpecialRemote.ConfigFrom u') -> (sameasNameField, u')
+	Logs.Remote.configSet cu (M.insert namefield (Proposed newname) cfg)
+	
+	next $ return True
diff --git a/Command/Repair.hs b/Command/Repair.hs
new file mode 100644
index 0000000000..c85c77d299
--- /dev/null
+++ b/Command/Repair.hs
@@ -0,0 +1,87 @@
+{- git-annex command
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Repair where
+
+import Command
+import qualified Annex
+import qualified Git.Repair
+import qualified Annex.Branch
+import qualified Git.Ref
+import Git.Types
+import Annex.Version
+import qualified Utility.RawFilePath as R
+
+cmd :: Command
+cmd = noCommit $ dontCheck repoExists $
+	command "repair" SectionMaintenance 
+		"recover broken git repository"
+		paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = starting "repair" (ActionItemOther Nothing) (SeekInput []) $ 
+	next $ runRepair =<< Annex.getRead Annex.force
+
+runRepair :: Bool -> Annex Bool
+runRepair forced = do
+	(ok, modifiedbranches) <- inRepo $
+		Git.Repair.runRepair isAnnexSyncBranch forced
+	-- This command can be run in git repos not using git-annex,
+	-- so avoid git annex branch stuff in that case.
+	whenM (isJust <$> getVersion) $
+		repairAnnexBranch modifiedbranches
+	return ok
+
+{- After git repository repair, the .git/annex/index file could
+ - still be broken, by pointing to bad objects, or might just be corrupt on
+ - its own. Since this index file is not used to stage things
+ - for long durations of time, it can safely be deleted if it is broken.
+ -
+ - Otherwise, if the git-annex branch was modified by the repair,
+ - commit the index file to the git-annex branch.
+ - This way, if the git-annex branch got rewound to an old version by
+ - the repository repair, or was completely deleted, this will get it back
+ - to a good state. Note that in the unlikely case where the git-annex
+ - branch was rewound to a state that, had new changes from elsewhere not
+ - yet reflected in the index, this does properly merge those into the
+ - index before committing.
+ -}
+repairAnnexBranch :: [Branch] -> Annex ()
+repairAnnexBranch modifiedbranches
+	| Annex.Branch.fullname `elem` modifiedbranches = ifM okindex
+		( commitindex
+		, do
+			nukeindex
+			missingbranch
+		)
+	| otherwise = ifM okindex
+		( noop
+		, do
+			nukeindex
+			ifM (null <$> inRepo (Git.Ref.matching [Annex.Branch.fullname]))
+				( missingbranch
+				, liftIO $ putStrLn "No data was lost."
+				)
+		)
+  where
+	okindex = Annex.Branch.withIndex $ inRepo Git.Repair.checkIndex
+	commitindex = do
+		Annex.Branch.forceCommit "committing index after git repository repair"
+		liftIO $ putStrLn "Successfully recovered the git-annex branch using .git/annex/index"
+	nukeindex = do
+		inRepo $ removeWhenExistsWith R.removeLink . gitAnnexIndex
+		liftIO $ putStrLn "Had to delete the .git/annex/index file as it was corrupt."
+	missingbranch = liftIO $ putStrLn "Since the git-annex branch is not up-to-date anymore. It would be a very good idea to run: git annex fsck --fast"
+
+trackingOrSyncBranch :: Ref -> Bool
+trackingOrSyncBranch b = Git.Repair.isTrackingBranch b || isAnnexSyncBranch b
+
+isAnnexSyncBranch :: Ref -> Bool
+isAnnexSyncBranch b = "refs/synced/" `isPrefixOf` fromRef b
diff --git a/Command/Required.hs b/Command/Required.hs
new file mode 100644
index 0000000000..18eb51e346
--- /dev/null
+++ b/Command/Required.hs
@@ -0,0 +1,17 @@
+{- git-annex command
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Required where
+
+import Command
+import Logs.PreferredContent
+import qualified Command.Wanted
+
+cmd :: Command
+cmd = Command.Wanted.cmd' "required" "get or set required content expression"
+	requiredContentMapRaw
+	requiredContentSet
diff --git a/Command/ReregisterUrl.hs b/Command/ReregisterUrl.hs
new file mode 100644
index 0000000000..5d95f0da43
--- /dev/null
+++ b/Command/ReregisterUrl.hs
@@ -0,0 +1,79 @@
+{- git-annex command
+ -
+ - Copyright 2015-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.ReregisterUrl where
+
+import Command
+import Logs.Web
+import Command.FromKey (keyOpt, keyOpt')
+import qualified Remote
+import Git.Types
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $ command "reregisterurl"
+	SectionPlumbing "updates url registration information"
+	(paramKey)
+	(seek <$$> optParser)
+
+data ReregisterUrlOptions = ReregisterUrlOptions
+	{ keyOpts :: CmdParams
+	, batchOption :: BatchMode
+	, moveFromOption :: Maybe (DeferredParse Remote)
+	}
+
+optParser :: CmdParamsDesc -> Parser ReregisterUrlOptions
+optParser desc = ReregisterUrlOptions
+	<$> cmdParams desc
+	<*> parseBatchOption False
+	<*> optional (mkParseRemoteOption <$> parseMoveFromOption)
+
+parseMoveFromOption :: Parser RemoteName
+parseMoveFromOption = strOption
+	( long "move-from" <> metavar paramRemote
+	<> completeRemotes
+	)
+
+seek :: ReregisterUrlOptions -> CommandSeek
+seek o = case (batchOption o, keyOpts o) of
+	(Batch fmt, _) -> seekBatch o fmt
+	(NoBatch, ps) -> commandAction (start o ps)
+
+seekBatch :: ReregisterUrlOptions -> BatchFormat -> CommandSeek
+seekBatch o fmt = batchOnly Nothing (keyOpts o) $
+	batchInput fmt (pure . parsebatch) $
+		batchCommandAction . start' o
+  where
+	parsebatch l = case keyOpt' l of
+		Left e -> Left e
+		Right k -> Right k
+
+start :: ReregisterUrlOptions -> [String] -> CommandStart
+start o (keyname:[]) = start' o (si, keyOpt keyname)
+  where
+	si = SeekInput [keyname]
+start _ _ = giveup "specify a key"
+
+start' :: ReregisterUrlOptions -> (SeekInput, Key) -> CommandStart
+start' o (si, key) =
+	starting "reregisterurl" ai si $
+		perform o key
+  where
+	ai = ActionItemKey key
+
+perform :: ReregisterUrlOptions -> Key -> CommandPerform
+perform o key = maybe (pure Nothing) (Just <$$> getParsed) (moveFromOption o) >>= \case
+	Nothing -> next $ return True
+	Just r -> do
+		us <- map fst
+			. filter (\(_, d) -> d == OtherDownloader)
+			. map getDownloader
+			<$> getUrls key
+		us' <- filterM (\u -> (== r) <$> Remote.claimingUrl u) us
+		forM_ us' $ \u -> do
+			setUrlMissing key (setDownloader u OtherDownloader)
+			setUrlPresent key u
+		next $ return True
diff --git a/Command/ResolveMerge.hs b/Command/ResolveMerge.hs
new file mode 100644
index 0000000000..aaa5c25ad2
--- /dev/null
+++ b/Command/ResolveMerge.hs
@@ -0,0 +1,41 @@
+{- git-annex command
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.ResolveMerge where
+
+import Command
+import qualified Git
+import Git.Sha
+import qualified Git.Branch
+import Annex.AutoMerge
+
+import qualified Data.ByteString as S
+
+cmd :: Command
+cmd = command "resolvemerge" SectionPlumbing
+	"resolve merge conflicts"
+	paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = starting "resolvemerge" (ActionItemOther Nothing) (SeekInput []) $ do
+	us <- fromMaybe nobranch <$> inRepo Git.Branch.current
+	d <- fromRawFilePath <$> fromRepo Git.localGitDir
+	let merge_head = d </> "MERGE_HEAD"
+	them <- fromMaybe (giveup nomergehead) . extractSha
+		<$> liftIO (S.readFile merge_head)
+	ifM (resolveMerge (Just us) them False)
+		( do
+			void $ commitResolvedMerge Git.Branch.ManualCommit
+			next $ return True
+		, giveup "Merge conflict could not be automatically resolved."
+		)
+  where
+	nobranch = giveup "No branch is currently checked out."
+	nomergehead = giveup "No SHA found in .git/merge_head"
diff --git a/Command/Restage.hs b/Command/Restage.hs
new file mode 100644
index 0000000000..2f7f5ce6f2
--- /dev/null
+++ b/Command/Restage.hs
@@ -0,0 +1,25 @@
+{- git-annex command
+ -
+ - Copyright 2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Restage where
+
+import Command
+import qualified Annex
+import Annex.Link
+
+cmd :: Command
+cmd = command "restage" SectionPlumbing 
+	"estages unlocked files in the git index"
+	paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = starting "restage" (ActionItemOther Nothing) (SeekInput []) $ do
+	restagePointerFiles =<< Annex.gitRepo
+	next $ return True
diff --git a/Command/RmUrl.hs b/Command/RmUrl.hs
new file mode 100644
index 0000000000..d7a2b396fd
--- /dev/null
+++ b/Command/RmUrl.hs
@@ -0,0 +1,68 @@
+{- git-annex command
+ -
+ - Copyright 2013-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.RmUrl where
+
+import Command
+import Logs.Web
+import Annex.WorkTree
+
+cmd :: Command
+cmd = notBareRepo $ withAnnexOptions [jsonOptions] $
+	command "rmurl" SectionCommon 
+		"record file is not available at url"
+		(paramRepeating (paramPair paramFile paramUrl))
+		(seek <$$> optParser)
+
+data RmUrlOptions = RmUrlOptions
+	{ rmThese :: CmdParams
+	, batchOption :: BatchMode
+	}
+
+optParser :: CmdParamsDesc -> Parser RmUrlOptions
+optParser desc = RmUrlOptions
+	<$> cmdParams desc
+	<*> parseBatchOption False
+
+seek :: RmUrlOptions -> CommandSeek
+seek o = case batchOption o of
+	Batch fmt -> batchOnly Nothing (rmThese o) $
+		batchInput fmt batchParser (batchCommandAction . start)
+	NoBatch -> withPairs (commandAction . start) (rmThese o)
+
+-- Split on the last space, since a FilePath can contain whitespace,
+-- but a url should not.
+batchParser :: String -> Annex (Either String (FilePath, URLString))
+batchParser s = case separate (== ' ') (reverse s) of
+	(ru, rf)
+		| null ru || null rf -> return $ Left "Expected: \"file url\""
+		| otherwise -> do
+			let f = reverse rf
+			f' <- liftIO $ fromRawFilePath
+				<$> relPathCwdToFile (toRawFilePath f)
+			return $ Right (f', reverse ru)
+
+start :: (SeekInput, (FilePath, URLString)) -> CommandStart
+start (si, (file, url)) = lookupKeyStaged file' >>= \case
+	Nothing -> stop
+	Just key -> do
+		let ai = mkActionItem (key, AssociatedFile (Just file'))
+		starting "rmurl" ai si $
+			next $ cleanup url key
+  where
+	file' = toRawFilePath file
+
+cleanup :: String -> Key -> CommandCleanup
+cleanup url key = do
+	-- Remove the url, no matter what downloader.
+	forM_ [minBound..maxBound] $ \dl -> 
+		setUrlMissing key (setDownloader url dl)
+	return True
+	-- Unlike addurl, this does not update location tracking
+	-- for remotes other than the web special remote. Doing so with
+	-- a remote that git-annex can drop content from would rather
+	-- unexpectedly leave content stranded on that remote.
diff --git a/Command/Satisfy.hs b/Command/Satisfy.hs
new file mode 100644
index 0000000000..d4fcf3f94f
--- /dev/null
+++ b/Command/Satisfy.hs
@@ -0,0 +1,17 @@
+{- git-annex command
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Satisfy (cmd) where
+
+import Command
+import Command.Sync hiding (cmd)
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, backendOption] $
+	command "satisfy" SectionCommon 
+		"transfer and drop content as configured"
+		(paramRepeating paramRemote) (seek <--< optParser SatisfyMode)
diff --git a/Command/Schedule.hs b/Command/Schedule.hs
new file mode 100644
index 0000000000..adb49ec942
--- /dev/null
+++ b/Command/Schedule.hs
@@ -0,0 +1,53 @@
+{- git-annex command
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Schedule where
+
+import Command
+import qualified Remote
+import Logs.Schedule
+import Types.ScheduledActivity
+import Utility.SafeOutput
+
+import qualified Data.Set as S
+
+cmd :: Command
+cmd = noMessages $ command "schedule" SectionSetup "get or set scheduled jobs"
+	(paramPair paramRemote (paramOptional paramExpression))
+	(withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start = parse
+  where
+	parse (name:[]) = do
+		u <- Remote.nameToUUID name
+		startingCustomOutput (ActionItemOther Nothing) $
+			performGet u
+	parse ps@(name:expr:[]) = do
+		u <- Remote.nameToUUID name
+		let ai = ActionItemOther (Just (UnquotedString name))
+		let si = SeekInput ps
+		startingUsualMessages "schedule" ai si $
+			performSet expr u
+	parse _ = giveup "Specify a repository."
+
+performGet :: UUID -> CommandPerform
+performGet uuid = do
+	s <- scheduleGet uuid
+	liftIO $ putStrLn $ safeOutput $ intercalate "; " $ 
+		map fromScheduledActivity $ S.toList s
+	next $ return True
+
+performSet :: String -> UUID -> CommandPerform
+performSet expr uuid = case parseScheduledActivities expr of
+	Left e -> giveup $ "Parse error: " ++ e
+	Right l -> do
+		scheduleSet uuid l
+		next $ return True
diff --git a/Command/Semitrust.hs b/Command/Semitrust.hs
new file mode 100644
index 0000000000..6ab318ee1b
--- /dev/null
+++ b/Command/Semitrust.hs
@@ -0,0 +1,21 @@
+{- git-annex command
+ -
+ - Copyright 2010 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Semitrust where
+
+import Command
+import Types.TrustLevel
+import Command.Trust (trustCommand)
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "semitrust" SectionSetup 
+		"return repository to default trust level"
+		(paramRepeating paramRepository) (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = trustCommand "semitrust" SemiTrusted
diff --git a/Command/SendKey.hs b/Command/SendKey.hs
new file mode 100644
index 0000000000..7bd71ad287
--- /dev/null
+++ b/Command/SendKey.hs
@@ -0,0 +1,64 @@
+{- git-annex command
+ -
+ - Copyright 2010,2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.SendKey where
+
+import Command
+import Annex.Content
+import Annex
+import Utility.Rsync
+import Annex.Transfer
+import qualified CmdLine.GitAnnexShell.Fields as Fields
+import Utility.Metered
+
+cmd :: Command
+cmd = noCommit $ 
+	command "sendkey" SectionPlumbing 
+		"runs rsync in server mode to send content"
+		paramKey (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withKeys (commandAction . start)
+
+start :: (SeekInput, Key) -> CommandStart
+start (_, key) = do
+	opts <- filterRsyncSafeOptions . maybe [] words
+		<$> getField "RsyncOptions"
+	ifM (inAnnex key)
+		( fieldTransfer Upload key $ \_p ->
+			sendAnnex key rollback $ \f _sz -> 
+				liftIO $ rsyncServerSend (map Param opts) f
+		, do
+			warning "requested key is not present"
+			liftIO exitFailure
+		)
+  where
+	{- No need to do any rollback; when sendAnnex fails, a nonzero
+	 - exit will be propigated, and the remote will know the transfer
+	 - failed. -}
+	rollback = noop
+
+fieldTransfer :: Direction -> Key -> (MeterUpdate -> Annex Bool) -> CommandStart
+fieldTransfer direction key a = do
+	fastDebug "Command.SendKey" "transfer start"
+	let afile = AssociatedFile Nothing
+	ok <- maybe (a $ const noop)
+		-- Using noRetry here because we're the sender.
+		(\u -> runner (Transfer direction (toUUID u) (fromKey id key)) Nothing afile Nothing noRetry a)
+		=<< Fields.getField Fields.remoteUUID
+	fastDebug "Command.SendKey" "transfer done"
+	liftIO $ exitBool ok
+  where
+	{- Allow the key to be sent to the remote even if there seems to be
+	 - another transfer of that key going on to that remote.
+	 - That one may be stale, etc.
+	 -}
+	runner
+		| direction == Upload = alwaysRunTransfer
+		| otherwise = runTransfer
diff --git a/Command/SetKey.hs b/Command/SetKey.hs
new file mode 100644
index 0000000000..a59fc740fe
--- /dev/null
+++ b/Command/SetKey.hs
@@ -0,0 +1,52 @@
+{- git-annex command
+ -
+ - Copyright 2010, 2015 Joey Hess <joey@kitenet.net>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.SetKey where
+
+import Command
+import Logs.Location
+import Annex.Content
+
+cmd :: Command
+cmd = command "setkey" SectionPlumbing "sets annexed content for a key"
+	(paramPair paramKey paramPath)
+	(withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start ps@(keyname:file:[]) = starting "setkey" ai si $
+	perform file' (keyOpt keyname)
+  where
+	ai = ActionItemOther (Just (QuotedPath file'))
+	si = SeekInput ps
+	file' = toRawFilePath file
+start _ = giveup "specify a key and a content file"
+
+keyOpt :: String -> Key
+keyOpt = fromMaybe (giveup "bad key") . deserializeKey
+
+perform :: RawFilePath -> Key -> CommandPerform
+perform file key = do
+	-- the file might be on a different filesystem, so moveFile is used
+	-- rather than simply calling moveAnnex; disk space is also
+	-- checked this way.
+	ok <- getViaTmp RetrievalAllKeysSecure DefaultVerify key (AssociatedFile Nothing) Nothing $ \dest -> unVerified $
+		if dest /= file
+			then liftIO $ catchBoolIO $ do
+				moveFile file dest
+				return True
+		else return True
+	if ok
+		then next $ cleanup key
+		else giveup "move failed!"
+
+cleanup :: Key -> CommandCleanup
+cleanup key = do
+	logStatus key InfoPresent
+	return True
diff --git a/Command/SetPresentKey.hs b/Command/SetPresentKey.hs
new file mode 100644
index 0000000000..2b789a7e6b
--- /dev/null
+++ b/Command/SetPresentKey.hs
@@ -0,0 +1,58 @@
+{- git-annex command
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.SetPresentKey where
+
+import Command
+import Logs.Location
+import Logs.Presence.Pure
+
+cmd :: Command
+cmd = noCommit $ withAnnexOptions [jsonOptions] $
+	command "setpresentkey" SectionPlumbing
+		"change records of where key is present"
+		(paramPair paramKey (paramPair paramUUID "[1|0]"))
+		(seek <$$> optParser)
+
+data SetPresentKeyOptions = SetPresentKeyOptions
+	{ params :: CmdParams
+	, batchOption :: BatchMode
+	}
+
+optParser :: CmdParamsDesc -> Parser SetPresentKeyOptions
+optParser desc = SetPresentKeyOptions
+	<$> cmdParams desc
+	<*> parseBatchOption False
+
+seek :: SetPresentKeyOptions -> CommandSeek
+seek o = case batchOption o of
+	Batch fmt -> batchOnly Nothing (params o) $
+		batchInput fmt
+			(pure . parseKeyStatus . words)
+			(batchCommandAction . uncurry start)
+	NoBatch -> either giveup (commandAction . start (SeekInput (params o)))
+		(parseKeyStatus $ params o)
+
+data KeyStatus = KeyStatus Key UUID LogStatus
+
+parseKeyStatus :: [String] -> Either String KeyStatus
+parseKeyStatus (ks:us:vs:[]) = do
+	k <- maybe (Left "bad key") Right (deserializeKey ks)
+	let u = toUUID us
+	s <- maybe (Left "bad value") Right (parseStatus vs)
+	return $ KeyStatus k u s
+parseKeyStatus _ = Left "Bad input. Expected: key uuid value"
+
+start :: SeekInput -> KeyStatus -> CommandStart
+start si (KeyStatus k u s) = starting "setpresentkey" ai si $ perform k u s
+  where
+	ai = mkActionItem k
+
+perform :: Key -> UUID -> LogStatus -> CommandPerform
+perform k u s = next $ do
+	logChange k u s
+	return True
diff --git a/Command/Smudge.hs b/Command/Smudge.hs
new file mode 100644
index 0000000000..5ca290c113
--- /dev/null
+++ b/Command/Smudge.hs
@@ -0,0 +1,335 @@
+{- git-annex command
+ -
+ - Copyright 2015-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Smudge where
+
+import Command
+import Annex.Content
+import Annex.Link
+import Annex.FileMatcher
+import Annex.Ingest
+import Annex.CatFile
+import Annex.WorkTree
+import Logs.Smudge
+import Logs.Location
+import qualified Database.Keys
+import qualified Git.BuildVersion
+import Git.FilePath
+import Git.Types
+import Git.HashObject
+import qualified Git
+import qualified Git.Ref
+import qualified Annex
+import Backend
+import Utility.Metered
+import Annex.InodeSentinal
+import Utility.InodeCache
+import Config.GitConfig
+import qualified Types.Backend
+import qualified Annex.BranchState
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+
+cmd :: Command
+cmd = noCommit $ noMessages $
+	command "smudge" SectionPlumbing 
+		"git smudge filter"
+		paramFile (seek <$$> optParser)
+
+data SmudgeOptions = UpdateOption | SmudgeOptions
+	{ smudgeFile :: FilePath
+	, cleanOption :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser SmudgeOptions
+optParser desc = smudgeoptions <|> updateoption
+  where
+	smudgeoptions = SmudgeOptions
+		<$> argument str ( metavar desc )
+		<*> switch ( long "clean" <> help "clean filter" )
+	updateoption = flag' UpdateOption
+		( long "update" <> help "populate annexed worktree files" )
+
+seek :: SmudgeOptions -> CommandSeek
+seek (SmudgeOptions f False) = commandAction (smudge f)
+seek (SmudgeOptions f True) = commandAction (clean (toRawFilePath f))
+seek UpdateOption = commandAction update
+
+-- Smudge filter is fed git file content, and if it's a pointer to an
+-- available annex object, git expects it to output its content.
+--
+-- However, this does not do that. It outputs the pointer, and records
+-- the filename in the smudge log. Git hooks run after commands like checkout
+-- then run git annex smudge --update which populates the work tree files
+-- with annex content. This is done for several reasons:
+--
+-- * To support annex.thin
+-- * Because git currently buffers the whole object received from the
+--   smudge filter in memory, which is a problem with large files.
+smudge :: FilePath -> CommandStart
+smudge file = do
+	b <- liftIO $ L.hGetContents stdin
+	smudge' file b
+	liftIO $ L.putStr b
+	stop
+
+-- Handles everything except the IO of the file content.
+smudge' :: FilePath -> L.ByteString -> Annex ()
+smudge' file b = case parseLinkTargetOrPointerLazy b of
+	Nothing -> noop
+	Just k -> do
+		topfile <- inRepo (toTopFilePath (toRawFilePath file))
+		Database.Keys.addAssociatedFile k topfile
+		void $ smudgeLog k topfile
+
+-- Clean filter is fed file content on stdin, decides if a file
+-- should be stored in the annex, and outputs a pointer to its
+-- injested content if so. Otherwise, the original content.
+clean :: RawFilePath -> CommandStart
+clean file = do
+	Annex.BranchState.disableUpdate -- optimisation
+	b <- liftIO $ L.hGetContents stdin
+	let passthrough = liftIO $ L.hPut stdout b
+	-- Before git 2.5, failing to consume all stdin here would
+	-- cause a SIGPIPE and crash it.
+	-- Newer git catches the signal and stops sending, which is
+	-- much faster. (Also, git seems to forget to free memory
+	-- when sending the file, so the less we let it send, the
+	-- less memory it will waste.)
+	let discardreststdin = if Git.BuildVersion.older "2.5"
+		then L.length b `seq` return ()
+		else liftIO $ hClose stdin
+	let emitpointer = liftIO . S.hPut stdout . formatPointer
+	clean' file (parseLinkTargetOrPointerLazy' b)
+		passthrough
+		discardreststdin
+		emitpointer
+	stop
+  where
+
+-- Handles everything except the IO of the file content.
+clean'
+	:: RawFilePath
+	-> Either InvalidAppendedPointerFile (Maybe Key)
+	-- ^ If the content provided by git is an annex pointer,
+	-- this is the key it points to.
+	-> Annex ()
+	-- ^ passthrough: Feed the content provided by git back out to git.
+	-> Annex ()
+	-- ^ discardreststdin: Called when passthrough will not be called,
+	-- this has to take care of reading the content provided by git, or
+	-- otherwise dealing with it.
+	-> (Key -> Annex ())
+	-- ^ emitpointer: Emit a pointer file for the key.
+	-> Annex ()
+clean' file mk passthrough discardreststdin emitpointer =
+	ifM (fileOutsideRepo file)
+		( passthrough
+		, inSmudgeCleanFilter go
+		)
+  where
+
+	go = case mk of
+		Right (Just k) -> do
+			addingExistingLink file k $ do
+				getMoveRaceRecovery k file
+				passthrough
+		Right Nothing -> notpointer
+		Left InvalidAppendedPointerFile -> do
+			toplevelWarning False $
+				"The file " <> QuotedPath file <> " looks like git-annex pointer file that has had other content appended to it"
+			notpointer
+
+	notpointer = inRepo (Git.Ref.fileRef file) >>= \case
+		Just fileref -> do
+			indexmeta <- catObjectMetaData fileref
+			oldkey <- case indexmeta of
+				Just (_, sz, _) -> catKey' fileref sz
+				Nothing -> return Nothing
+			notpointer' indexmeta oldkey
+		Nothing -> passthrough
+	
+	notpointer' indexmeta oldkey = ifM (shouldAnnex file indexmeta oldkey)
+		( do
+			discardreststdin
+
+			-- Optimization for the case when the file is already
+			-- annexed and is unmodified.
+			case oldkey of
+				Nothing -> doingest Nothing
+				Just ko -> ifM (isUnmodifiedCheap ko file)
+					( emitpointer ko
+					, updateingest ko
+					)
+		, passthrough
+		)
+	
+	-- Use the same backend that was used before, when possible.
+	-- If the old key's backend does not support generating keys,
+	-- use the default backend.
+	updateingest oldkey =
+		maybeLookupBackendVariety (fromKey keyVariety oldkey) >>= \case
+			Nothing -> doingest Nothing
+			Just oldbackend -> case Types.Backend.genKey oldbackend of
+				Just _ -> doingest (Just oldbackend)
+				Nothing -> doingest Nothing
+	
+	doingest preferredbackend = do
+		-- Can't restage associated files because git add
+		-- runs this and has the index locked.
+		let norestage = Restage False
+		emitpointer
+			=<< postingest
+			=<< (\ld -> ingest' preferredbackend nullMeterUpdate ld Nothing norestage)
+			=<< lockDown cfg (fromRawFilePath file)
+
+	postingest (Just k, _) = do
+		logStatus k InfoPresent
+		return k
+	postingest _ = giveup "could not add file to the annex"
+
+	cfg = LockDownConfig
+		{ lockingFile = False
+		, hardlinkFileTmpDir = Nothing
+		, checkWritePerms = True
+		}
+
+-- git diff can run the clean filter on files outside the
+-- repository; can't annex those
+fileOutsideRepo :: RawFilePath -> Annex Bool
+fileOutsideRepo file = do
+        repopath <- liftIO . absPath =<< fromRepo Git.repoPath
+	filepath <- liftIO $ absPath file
+	return $ not $ dirContains repopath filepath
+
+-- Avoid a potential deadlock.
+inSmudgeCleanFilter :: Annex a -> Annex a
+inSmudgeCleanFilter = bracket setup cleanup . const
+  where
+	setup = Annex.changeState $ \s -> s
+		{ Annex.insmudgecleanfilter = True }
+	cleanup () = Annex.changeState $ \s -> s
+		{ Annex.insmudgecleanfilter = False }
+
+-- If annex.largefiles is configured (and not disabled by annex.gitaddtoannex
+-- being set to false), matching files are added to the annex and the rest to
+-- git.
+--
+-- When annex.largefiles is not configured, files are normally not
+-- added to the annex, so will be added to git. However, if the file
+-- is annexed in the index, keep it annexed. This prevents accidental
+-- conversions when previously annexed files get modified and added.
+--
+-- In either case, if the file's inode is the same as one that was used
+-- for annexed content before, annex it. And if the file is not annexed
+-- in the index, and has the same content, leave it in git.
+-- This handles cases such as renaming a file followed by git add,
+-- which the user naturally expects to behave the same as git mv.
+shouldAnnex :: RawFilePath -> Maybe (Sha, FileSize, ObjectType) -> Maybe Key -> Annex Bool
+shouldAnnex file indexmeta moldkey = do
+	ifM (annexGitAddToAnnex <$> Annex.getGitConfig)
+		( checkunchanged $ checkmatcher checkwasannexed
+		, checkunchanged checkwasannexed
+		)
+  where
+	checkmatcher d
+		| dotfile file = ifM (getGitConfigVal annexDotFiles)
+			( go
+			, d
+			)
+		| otherwise = go
+	  where
+		go = do
+			matcher <- largeFilesMatcher
+			checkFileMatcher' matcher file d
+	
+	checkwasannexed = pure $ isJust moldkey
+
+	isknownannexedinode = withTSDelta (liftIO . genInodeCache file) >>= \case
+		Nothing -> pure False
+		Just ic -> Database.Keys.isInodeKnown ic =<< sentinalStatus
+
+	-- If the inode matches one known used for annexed content,
+	-- keep the file annexed. This handles a case where the file
+	-- has been annexed before, and the git is running the clean filter
+	-- again on it for whatever reason.
+	checkunchanged cont = ifM isknownannexedinode
+		( return True
+		, checkunchangedgitfile cont
+		)
+
+	-- This checks for a case where the file had been added to git
+	-- previously, not to the annex before, and its content is not
+	-- changed, but git is running the clean filter again on it
+	-- (eg because its mtime or inode changed, or just because git feels
+	-- like it). Such a file should not be added to the annex, even if
+	-- annex.largefiles now matches it, because the content is not
+	-- changed.
+	checkunchangedgitfile cont = case (moldkey, indexmeta) of
+		(Nothing, Just (sha, sz, _)) -> liftIO (catchMaybeIO (getFileSize file)) >>= \case
+			Just sz' | sz' == sz -> do
+				-- The size is the same, so the file
+				-- is not much larger than what was stored
+				-- in git before, so it won't be out of
+				-- line to hash it. However, the content
+				-- is prevented from being stored in git
+				-- when hashing.
+				h <- inRepo $ hashObjectStart False
+				sha' <- liftIO $ hashFile h file
+				liftIO $ hashObjectStop h
+				if sha' == sha
+					then return False
+					else cont
+			_ -> cont
+		_ -> cont
+
+-- Recover from a previous race between eg git mv and git-annex get.
+-- That could result in the file remaining a pointer file, while
+-- its content is present in the annex. Populate the pointer file.
+-- 
+-- This also handles the case where a copy of a pointer file is made,
+-- then git-annex gets the content, and later git add is run on
+-- the pointer copy. It will then be populated with the content.
+getMoveRaceRecovery :: Key -> RawFilePath -> Annex ()
+getMoveRaceRecovery k file = void $ tryNonAsync $
+	whenM (inAnnex k) $ do
+		obj <- calcRepo (gitAnnexLocation k)
+		-- Cannot restage because git add is running and has
+		-- the index locked.
+		populatePointerFile (Restage False) k obj file >>= \case
+			Nothing -> return ()
+			Just ic -> Database.Keys.addInodeCaches k [ic]
+
+update :: CommandStart
+update = do
+	-- This gets run after a git checkout or merge, so it's a good
+	-- point to refresh the keys database for changes to annexed files.
+	-- Doing it explicitly here avoids a later pause in the middle of
+	-- some other action.
+	scanAnnexedFiles
+	updateSmudged (Restage True)
+	stop
+
+updateSmudged :: Restage -> Annex ()
+updateSmudged restage = streamSmudged $ \k topf -> do
+	f <- fromRepo (fromTopFilePath topf)
+	whenM (inAnnex k) $ do
+		obj <- calcRepo (gitAnnexLocation k)
+		objic <- withTSDelta (liftIO . genInodeCache obj)
+		populatePointerFile restage k obj f >>= \case
+			Just ic -> do
+				cs <- Database.Keys.getInodeCaches k
+				if null cs
+					then Database.Keys.addInodeCaches k (catMaybes [Just ic, objic])
+					else Database.Keys.addInodeCaches k [ic]
+			Nothing -> liftIO (isPointerFile f) >>= \case
+				Just k' | k' == k -> toplevelWarning False $
+					"unable to populate worktree file " <> QuotedPath f
+				_ -> noop
diff --git a/Command/Status.hs b/Command/Status.hs
new file mode 100644
index 0000000000..d6b2358f66
--- /dev/null
+++ b/Command/Status.hs
@@ -0,0 +1,71 @@
+{- git-annex command
+ -
+ - Copyright 2013-2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Status where
+
+import Command
+import qualified Annex
+import Git.Status
+import Git.FilePath
+
+import Data.ByteString.Char8 as B8
+
+cmd :: Command
+cmd = notBareRepo $ noCommit $ noMessages $
+	withAnnexOptions [jsonOptions] $
+		command "status" SectionCommon
+			"show the working tree status (deprecated)"
+			paramPaths (seek <$$> optParser)
+
+data StatusOptions = StatusOptions
+	{ statusFiles :: CmdParams
+	, ignoreSubmodules :: Maybe String
+	}
+
+optParser :: CmdParamsDesc -> Parser StatusOptions
+optParser desc = StatusOptions
+	<$> cmdParams desc
+	<*> optional (strOption
+		( long "ignore-submodules"
+		<> help "passed on to git status"
+		<> metavar "WHEN"
+		))
+
+seek :: StatusOptions -> CommandSeek
+seek o = withWords (commandAction . start o) (statusFiles o)
+	
+start :: StatusOptions -> [FilePath] -> CommandStart
+start o locs = do
+	(l, cleanup) <- inRepo $ getStatus ps locs
+	let getstatus = pure . simplifiedStatus
+	forM_ l $ \s -> maybe noop displayStatus =<< getstatus s
+	ifM (liftIO cleanup)
+		( stop
+		, giveup "git status failed"
+		)
+  where
+	ps = case ignoreSubmodules o of
+		Nothing -> []
+		Just s -> [Param $ "--ignore-submodules="++s]
+
+-- Prefer to show unstaged status in this simplified status.
+simplifiedStatus :: StagedUnstaged Status -> Maybe Status
+simplifiedStatus (StagedUnstaged { unstaged = Just s }) = Just s
+simplifiedStatus (StagedUnstaged { staged = Just s }) = Just s
+simplifiedStatus _ = Nothing
+
+displayStatus :: Status -> Annex ()
+-- Renames not shown in this simplified status
+displayStatus (Renamed _ _) = noop
+displayStatus s = do
+	let c = statusChar s
+	absf <- fromRepo $ fromTopFilePath (statusFile s)
+	f <- liftIO $ relPathCwdToFile absf
+	qp <- coreQuotePath <$> Annex.getGitConfig
+	unlessM (showFullJSON $ JSONChunk [("status", [c]), ("file", fromRawFilePath f)]) $
+		liftIO $ B8.putStrLn $ quote qp $
+			UnquotedString (c : " ") <> QuotedPath f
diff --git a/Command/Sync.hs b/Command/Sync.hs
new file mode 100644
index 0000000000..5c4ba2ebe2
--- /dev/null
+++ b/Command/Sync.hs
@@ -0,0 +1,1160 @@
+{- git-annex command
+ -
+ - Copyright 2011 Joachim Breitner <mail@joachim-breitner.de>
+ - Copyright 2011-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE FlexibleContexts #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Sync (
+	cmd,
+	seek,
+	seek',
+	CurrBranch,
+	mergeConfig,
+	merge,
+	prepMerge,
+	mergeLocal,
+	mergeRemote,
+	commitMsg,
+	pushBranch,
+	updateBranch,
+	updateBranches,
+	seekExportContent,
+	optParser,
+	parseUnrelatedHistoriesOption,
+	SyncOptions(..),
+	OperationMode(..),
+) where
+
+import Command
+import qualified Annex
+import qualified Annex.Branch
+import qualified Remote
+import qualified Types.Remote as Remote
+import qualified Git.Command
+import qualified Git.LsFiles as LsFiles
+import qualified Git.Branch
+import qualified Git.Merge
+import qualified Git.Types as Git
+import qualified Git.Ref
+import qualified Git
+import Git.FilePath
+import qualified Remote.Git
+import Config
+import Config.GitConfig
+import Annex.SpecialRemote.Config
+import Config.DynamicConfig
+import Annex.Path
+import Annex.Wanted
+import Annex.Content
+import Annex.WorkTree
+import Command.Get (getKey')
+import qualified Command.Move
+import qualified Command.Export
+import qualified Command.Import
+import qualified Command.Migrate
+import Annex.Drop
+import Annex.UUID
+import Logs.UUID
+import Logs.Export
+import Logs.PreferredContent
+import Logs.View
+import Annex.AutoMerge
+import Annex.AdjustedBranch
+import Annex.AdjustedBranch.Merge
+import Annex.View
+import Annex.Ssh
+import Annex.BloomFilter
+import Annex.UpdateInstead
+import Annex.Export
+import Annex.TaggedPush
+import Annex.CurrentBranch
+import Annex.Import
+import Annex.CheckIgnore
+import Annex.PidLock
+import Types.FileMatcher
+import Types.GitConfig
+import Types.Availability
+import qualified Database.Export as Export
+import Utility.Bloom
+import Utility.OptParse
+import Utility.Process.Transcript
+import Utility.Tuple
+
+import Control.Concurrent.MVar
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import Data.Char
+
+cmd :: Command
+cmd = withAnnexOptions [jobsOption, backendOption] $
+	command "sync" SectionCommon 
+		"synchronize local repository with remotes"
+		(paramRepeating paramRemote) (seek <--< optParser SyncMode)
+
+data OperationMode = SyncMode | PullMode | PushMode | SatisfyMode | AssistMode
+	deriving (Eq, Show)
+
+data SyncOptions = SyncOptions
+	{ syncWith :: CmdParams
+	, onlyAnnexOption :: Bool
+	, notOnlyAnnexOption :: Bool
+	, commitOption :: Bool
+	, noCommitOption :: Bool
+	, messageOption :: [String]
+	, pullOption :: Bool
+	, pushOption :: Bool
+	, contentOption :: Maybe Bool
+	, noContentOption :: Maybe Bool
+	, contentOfOption :: [FilePath]
+	, cleanupOption :: Bool
+	, keyOptions :: Maybe KeyOptions
+	, resolveMergeOverride :: Bool
+	, allowUnrelatedHistories :: Bool
+	, operationMode :: OperationMode
+	}
+
+instance Default SyncOptions where
+	def = SyncOptions
+		{ syncWith = []
+		, onlyAnnexOption = False
+		, notOnlyAnnexOption = False
+		, commitOption = False
+		, noCommitOption = False
+		, messageOption = []
+		, pullOption = False
+		, pushOption = False
+		, contentOption = Just False
+		, noContentOption = Just False
+		, contentOfOption = []
+		, cleanupOption = False
+		, keyOptions = Nothing
+		, resolveMergeOverride = False
+		, allowUnrelatedHistories = False
+		, operationMode = SyncMode
+		}
+
+optParser :: OperationMode -> CmdParamsDesc -> Parser SyncOptions
+optParser mode desc = SyncOptions
+	<$> (many $ argument str
+		( metavar desc
+		<> completeRemotes
+		))
+	<*> whenmode [SatisfyMode] True 
+		(switch 
+			( long "only-annex"
+			<> short 'a'
+			<> help "do not operate on git branches"
+			))
+	<*> whenmode [SatisfyMode] False 
+		( switch 
+			( long "not-only-annex"
+			<> help "operate on git branches as well as annex"
+			))
+	<*> case mode of
+		SyncMode -> switch
+			( long "commit"
+			<> help "commit changes to git"
+			)
+		PushMode -> pure False
+		PullMode -> pure False
+		SatisfyMode -> pure False
+		AssistMode -> pure True
+	<*> unlessmode [SyncMode] True 
+		(switch
+			( long "no-commit"
+			<> help "avoid git commit" 
+			))
+	<*> unlessmode [SyncMode, AssistMode] []
+		(many (strOption
+			( long "message" <> short 'm' <> metavar "MSG"
+			<> help "commit message"
+			)))
+	<*> case mode of
+		SyncMode -> invertableSwitch "pull" True
+			( help "avoid git pulls from remotes" 
+			)
+		PullMode -> pure True
+		PushMode -> pure False
+		SatisfyMode -> pure False
+		AssistMode -> pure True
+	<*> case mode of
+		SyncMode -> invertableSwitch "push" True
+			( help "avoid git pushes to remotes" 
+			)
+		PullMode -> pure False
+		PushMode -> pure True
+		SatisfyMode -> pure False
+		AssistMode -> pure True
+	<*> whenmode [SatisfyMode] (Just True)
+		(optional (flag' True 
+			( long "content"
+			<> help "transfer annexed file contents" 
+			)))
+	<*> whenmode [SatisfyMode] Nothing
+		(optional (flag' True
+			( long "no-content"
+			<> short 'g'
+			<> help "do not transfer annexed file contents"
+			)))
+	<*> many (strOption
+		( long "content-of"
+		<> short 'C'
+		<> help "transfer contents of annexed files in a given location"
+		<> metavar paramPath
+		))
+	<*> whenmode [PullMode, SatisfyMode] False 
+		(switch
+			( long "cleanup"
+			<> help "remove synced/ branches"
+			))
+	<*> optional parseAllOption
+	<*> whenmode [PushMode, SatisfyMode] False 
+		(invertableSwitch "resolvemerge" True
+			( help "do not automatically resolve merge conflicts"
+			))
+	<*> whenmode [PushMode, SatisfyMode] False
+		parseUnrelatedHistoriesOption
+	<*> pure mode
+  where
+	whenmode m v a
+		| mode `elem` m = pure v
+		| otherwise = a
+	unlessmode m v a
+		| mode `elem` m = a
+		| otherwise = pure v
+
+parseUnrelatedHistoriesOption :: Parser Bool
+parseUnrelatedHistoriesOption = 
+	invertableSwitch "allow-unrelated-histories" False
+		( help "allow merging unrelated histories"
+		)
+
+-- Since prepMerge changes the working directory, FilePath options
+-- have to be adjusted.
+instance DeferredParseClass SyncOptions where
+	finishParse v = SyncOptions
+		<$> pure (syncWith v)
+		<*> pure (onlyAnnexOption v)
+		<*> pure (notOnlyAnnexOption v)
+		<*> pure (commitOption v)
+		<*> pure (noCommitOption v)
+		<*> pure (messageOption v)
+		<*> pure (pullOption v)
+		<*> pure (pushOption v)
+		<*> pure (contentOption v)
+		<*> pure (noContentOption v)
+		<*> liftIO (mapM (fromRawFilePath <$$> absPath . toRawFilePath) (contentOfOption v))
+		<*> pure (cleanupOption v)
+		<*> pure (keyOptions v)
+		<*> pure (resolveMergeOverride v)
+		<*> pure (allowUnrelatedHistories v)
+		<*> pure (operationMode v)
+
+seek :: SyncOptions -> CommandSeek
+seek o = do
+	prepMerge
+	
+	seek' o
+
+seek' :: SyncOptions -> CommandSeek
+seek' o = startConcurrency transferStages $ do
+	let withbranch a = a =<< getCurrentBranch
+
+	remotes <- syncRemotes (syncWith o)
+	warnSyncContentTransition o remotes
+	-- Remotes that are git repositories, not (necesarily) special remotes.
+	let gitremotes = filter (Remote.gitSyncableRemoteType . Remote.remotetype) remotes
+	-- Remotes that contain annex object content.
+	contentremotes <- filter (\r -> Remote.uuid r /= NoUUID)
+		<$> filterM (not <$$> liftIO . getDynamicConfig . remoteAnnexIgnore . Remote.gitconfig) remotes
+
+	if cleanupOption o
+		then do
+			commandAction (withbranch cleanupLocal)
+			mapM_ (commandAction . withbranch . cleanupRemote) gitremotes
+		else do
+			mc <- mergeConfig (allowUnrelatedHistories o)
+
+			-- Syncing involves many actions, any of which
+			-- can independently fail, without preventing
+			-- the others from running. 
+			-- These actions cannot be run concurrently.
+			mapM_ includeCommandAction $ concat
+				[ [ commit o ]
+				, [ withbranch (mergeLocal mc o) ]
+				, map (withbranch . pullRemote o mc) gitremotes
+				, [ mergeAnnex ]
+				]
+			
+			content <- shouldSyncContent o
+
+			when content $
+				whenM (annexSyncMigrations <$> Annex.getGitConfig) $
+					Command.Migrate.seekDistributedMigrations True
+
+			forM_ (filter isImport contentremotes) $
+				withbranch . importRemote content o
+			forM_ (filter isThirdPartyPopulated contentremotes) $
+				pullThirdPartyPopulated o
+			
+			when content $ do
+				-- Send content to any exports before other
+				-- repositories, in case that lets content
+				-- be dropped from other repositories.
+				exportedcontent <- withbranch $
+					seekExportContent (Just o)
+						(filter isExport contentremotes)
+
+				-- Sync content with remotes, including
+				-- importing from import remotes (since
+				-- importing only downloads new files not
+				-- old files)
+				let shouldsynccontent r
+					| isExport r && not (isImport r) = False
+					| otherwise = True
+				syncedcontent <- withbranch $
+					seekSyncContent o
+						(filter shouldsynccontent contentremotes)
+
+				-- Transferring content can take a while,
+				-- and other changes can be pushed to the
+				-- git-annex branch on the remotes in the
+				-- meantime, so pull and merge again to
+				-- avoid our push overwriting those changes.
+				when (syncedcontent || exportedcontent) $ do
+					mapM_ includeCommandAction $ concat
+						[ map (withbranch . pullRemote o mc) gitremotes
+						, [ commitAnnex, mergeAnnex ]
+						]
+	
+			void $ includeCommandAction $ withbranch $ pushLocal o
+			-- Pushes to remotes can run concurrently.
+			mapM_ (commandAction . withbranch . pushRemote o) gitremotes
+
+{- Merging may delete the current directory, so go to the top
+ - of the repo. This also means that sync always acts on all files in the
+ - repository, not just on a subdirectory. -}
+prepMerge :: Annex ()
+prepMerge = Annex.changeDirectory . fromRawFilePath =<< fromRepo Git.repoPath
+
+mergeConfig :: Bool -> Annex [Git.Merge.MergeConfig]
+mergeConfig mergeunrelated = do
+	quiet <- commandProgressDisabled
+	return $ catMaybes
+		[ Just Git.Merge.MergeNonInteractive
+		, if mergeunrelated 
+			then Just Git.Merge.MergeUnrelatedHistories
+			else Nothing
+		, if quiet
+			then Just Git.Merge.MergeQuiet
+			else Nothing
+		]
+
+merge :: CurrBranch -> [Git.Merge.MergeConfig] -> SyncOptions -> Git.Branch.CommitMode -> [Git.Branch] -> Annex Bool
+merge currbranch mergeconfig o commitmode tomergel = 
+	runsGitAnnexChildProcessViaGit $ do
+		canresolvemerge <- if resolveMergeOverride o
+			then getGitConfigVal annexResolveMerge
+			else return False
+		and <$> case currbranch of
+			(Just b, Just adj) -> forM tomergel $ \tomerge ->
+				mergeToAdjustedBranch tomerge (b, adj) mergeconfig canresolvemerge commitmode
+			(b, _) -> forM tomergel $ \tomerge ->
+				autoMergeFrom tomerge b mergeconfig commitmode canresolvemerge
+
+syncBranch :: Git.Branch -> Git.Branch
+syncBranch = Git.Ref.underBase "refs/heads/synced" . origBranch
+
+origBranch :: Git.Branch -> Git.Branch
+origBranch = fromViewBranch . fromAdjustedBranch
+
+remoteBranch :: Remote -> Git.Ref -> Git.Ref
+remoteBranch remote = Git.Ref.underBase $ "refs/remotes/" ++ Remote.name remote
+
+syncRemotes :: [String] -> Annex [Remote]
+syncRemotes ps = do
+	-- Do automatic initialization of remotes when possible
+	-- when getting remote list.
+	remotelist <- Remote.remoteList' True
+	available <- filterM (liftIO . getDynamicConfig . remoteAnnexSync . Remote.gitconfig) remotelist
+	syncRemotes' ps available
+
+syncRemotes' :: [String] -> [Remote] -> Annex [Remote]
+syncRemotes' ps available = 
+	ifM (Annex.getRead Annex.fast) ( fastest <$> wanted , wanted )
+  where
+	wanted
+		| null ps = filterM good (concat $ Remote.byCost available)
+		| otherwise = listed
+	
+	listed = concat <$> mapM Remote.byNameOrGroup ps
+	
+	good r = tryNonAsync (Remote.availability r) >>= return . \case
+		Right Unavailable -> False
+		_ -> True
+	
+	fastest = fromMaybe [] . headMaybe . Remote.byCost
+
+commit :: SyncOptions -> CommandStart
+commit o = stopUnless shouldcommit $ starting "commit" ai si $ do
+	Annex.Branch.commit =<< Annex.Branch.commitMessage
+	mopts <- concatMap (\msg -> [Param "-m", Param msg])
+		<$> if null (messageOption o)
+			then (:[]) <$> commitMsg
+			else pure (messageOption o)
+	next $ do
+		showOutput
+		let cmode = Git.Branch.ManualCommit
+		cquiet <- Git.Branch.CommitQuiet <$> commandProgressDisabled
+		void $ inRepo $ Git.Branch.commitCommand
+			cmode cquiet
+			([ Param "-a" ] ++ mopts)
+		return True
+  where
+	shouldcommit = notOnlyAnnex o <&&>
+		( pure (commitOption o)
+		<||> (pure (not (noCommitOption o)) <&&> getGitConfigVal annexAutoCommit)
+		)
+	ai = ActionItemOther Nothing
+	si = SeekInput []
+
+commitMsg :: Annex String
+commitMsg = do
+	u <- getUUID
+	m <- uuidDescMap
+	return $ "git-annex in "
+		++ maybe "unknown" fromUUIDDesc (M.lookup u m)
+
+mergeLocal :: [Git.Merge.MergeConfig] -> SyncOptions -> CurrBranch -> CommandStart
+mergeLocal mergeconfig o currbranch = stopUnless (notOnlyAnnex o) $
+	mergeLocal' mergeconfig o currbranch
+
+mergeLocal' :: [Git.Merge.MergeConfig] -> SyncOptions -> CurrBranch -> CommandStart
+mergeLocal' mergeconfig o currbranch@(Just branch, _) =
+	needMerge currbranch branch >>= \case
+		[] -> stop
+		tomerge -> do
+			let ai = ActionItemOther (Just $ UnquotedString $ unwords $ map Git.Ref.describe tomerge)
+			let si = SeekInput []
+			starting "merge" ai si $
+				next $ merge currbranch mergeconfig o Git.Branch.ManualCommit tomerge
+mergeLocal' _ _ currbranch@(Nothing, _) = inRepo Git.Branch.currentUnsafe >>= \case
+	Just branch -> needMerge currbranch branch >>= \case
+		[] -> stop
+		tomerge -> do
+			let ai = ActionItemOther (Just $ UnquotedString $ unwords $ map Git.Ref.describe tomerge)
+			let si = SeekInput []
+			starting "merge" ai si $ do
+				warning $ UnquotedString $ "There are no commits yet to branch " ++ Git.fromRef branch ++ ", so cannot merge " ++ unwords (map Git.fromRef tomerge) ++ " into it."
+				next $ return False
+	Nothing -> stop
+
+-- Returns the branches that should be merged, if any.
+--
+-- Usually this is the sync branch. However, when in an adjusted branch,
+-- it can be either the sync branch or the original branch, or both.
+needMerge :: CurrBranch -> Git.Branch -> Annex [Git.Branch]
+needMerge currbranch headbranch
+	| is_branchView headbranch = return []
+	| otherwise = ifM isBareRepo
+		( return []
+		, do
+			syncbranchret <- usewhen syncbranch syncbranchchecks
+			adjbranchret <- case currbranch of
+				(Just origbranch, Just adj) -> 
+					usewhen origbranch $
+						canMergeToAdjustedBranch origbranch (origbranch, adj)
+				_ -> return []
+			return (syncbranchret++adjbranchret)
+		)
+  where
+	usewhen v c = ifM c
+		( return [v]
+		, return []
+		)
+	syncbranch = syncBranch headbranch
+	syncbranchchecks = case currbranch of
+		(Just _, madj) -> syncbranchchanged madj
+		(Nothing, _) -> hassyncbranch
+	hassyncbranch = inRepo (Git.Ref.exists syncbranch)
+	syncbranchchanged madj =
+		let branch' = maybe headbranch (adjBranch . originalToAdjusted headbranch) madj
+		in hassyncbranch <&&> inRepo (Git.Branch.changed branch' syncbranch)
+
+pushLocal :: SyncOptions -> CurrBranch -> CommandStart
+pushLocal o b = stopUnless (notOnlyAnnex o) $ do
+	updateBranches b
+	stop
+
+updateBranches :: CurrBranch -> Annex ()
+updateBranches (Nothing, _) = noop
+updateBranches (Just branch, madj) = do
+	-- When in a view branch, update it to reflect any changes
+	-- of its parent branch or the metadata.
+	currentView >>= \case
+		Just (view, madj') -> updateView view madj' >>= \case
+			Nothing -> noop
+			Just newcommit -> do
+				ok <- inRepo $ Git.Command.runBool
+					[ Param "merge"
+					, Param (Git.fromRef newcommit)
+					]
+				unless ok $
+					giveup $ "failed to update view"
+				case madj' of
+					Nothing -> noop
+					Just adj -> updateadjustedbranch adj
+		-- When in an adjusted branch, propagate any changes
+		-- made to it back to the original branch.
+		Nothing -> case madj of
+			Just adj -> do
+				propigateAdjustedCommits branch adj
+				updateadjustedbranch adj
+			Nothing -> noop
+	
+	-- Update the sync branch to match the new state of the branch
+	inRepo $ updateBranch (syncBranch branch) (fromViewBranch branch)
+  where
+	-- The adjusted branch may also need to be updated, if the adjustment
+	-- is not stable, and the usual configuration does not update it.
+	updateadjustedbranch adj = unless (adjustmentIsStable adj) $
+		annexAdjustedBranchRefresh <$> Annex.getGitConfig >>= \case
+			0 -> adjustedBranchRefreshFull adj branch
+			_ -> return ()
+
+updateBranch :: Git.Branch -> Git.Branch -> Git.Repo -> IO ()
+updateBranch syncbranch updateto g = 
+	unlessM go $
+		giveup $ "failed to update " ++ Git.fromRef syncbranch
+  where
+	go = Git.Command.runBool
+		[ Param "branch"
+		, Param "-f"
+		, Param $ Git.fromRef $ Git.Ref.base syncbranch
+		, Param $ Git.fromRef $ updateto
+		] g
+
+pullRemote :: SyncOptions -> [Git.Merge.MergeConfig] -> Remote -> CurrBranch -> CommandStart
+pullRemote o mergeconfig remote branch = stopUnless (pure $ pullOption o && wantpull) $
+	starting "pull" ai si $ do
+		showOutput
+		ifM (onlyAnnex o)
+			( do
+				void $ fetch $ map Git.fromRef 
+					[ Annex.Branch.name
+					, syncBranch $ Annex.Branch.name
+					]
+				next $ return True
+			, ifM (fetch [])
+				( next $ mergeRemote remote branch mergeconfig o
+				, next $ return True
+				)
+			)
+  where
+	fetch bs = do
+		repo <- Remote.getRepo remote
+		ms <- Annex.getState Annex.output
+		inRepoWithSshOptionsTo repo (Remote.gitconfig remote) $
+			Git.Command.runBool $ catMaybes
+				[ Just $ Param "fetch"
+				, if commandProgressDisabled' ms
+					then Just $ Param "--quiet"
+					else Nothing
+				, Just $ Param $ Remote.name remote
+				] ++ map Param bs
+	wantpull = remoteAnnexPull (Remote.gitconfig remote)
+	ai = ActionItemOther (Just (UnquotedString (Remote.name remote)))
+	si = SeekInput []
+
+importRemote :: Bool -> SyncOptions -> Remote -> CurrBranch -> CommandSeek
+importRemote importcontent o remote currbranch
+	| not (pullOption o) || not wantpull = noop
+	| otherwise = case remoteAnnexTrackingBranch (Remote.gitconfig remote) of
+		Nothing -> noop
+		Just b -> do
+			let (branch, subdir) = splitRemoteAnnexTrackingBranchSubdir b
+			if canImportKeys remote importcontent
+				then do
+					Command.Import.seekRemote remote branch subdir importcontent (CheckGitIgnore True) []
+					-- Importing generates a branch
+					-- that is not initially connected
+					-- to the current branch, so allow
+					-- merging unrelated histories when
+					-- mergeing it.
+					mc <- mergeConfig True
+					void $ mergeRemote remote currbranch mc o
+				else warning $ UnquotedString $ "Cannot import from " ++ Remote.name remote ++ " when not syncing content."
+  where
+	wantpull = remoteAnnexPull (Remote.gitconfig remote)
+
+{- Handle a remote that is populated by a third party, by listing
+ - the contents of the remote, and then adding only the files on it that
+ - importKey identifies to a tree. The tree is only used to keep track
+ - of where keys are located on the remote, no remote tracking branch is
+ - updated, because the filenames are the names of annex object files,
+ - not suitable for a tracking branch. Does not transfer any content. -}
+pullThirdPartyPopulated :: SyncOptions -> Remote -> CommandSeek
+pullThirdPartyPopulated o remote
+	| not (pullOption o) || not wantpull = noop
+	| not (canImportKeys remote False) = noop
+	| otherwise = void $ includeCommandAction $ starting "list" ai si $
+		Command.Import.listContents' remote ImportTree (CheckGitIgnore False) go
+  where
+	go (Just importable) = importChanges remote ImportTree False True importable >>= \case
+		ImportFinished imported -> do
+			(_t, updatestate) <- recordImportTree remote ImportTree imported
+			next $ do
+				updatestate
+				return True
+		ImportUnfinished -> next $ return False
+	go Nothing = next $ return True -- unchanged from before
+
+	ai = ActionItemOther (Just (UnquotedString (Remote.name remote)))
+	si = SeekInput []
+	
+	wantpull = remoteAnnexPull (Remote.gitconfig remote)
+
+{- The remote probably has both a master and a synced/master branch.
+ - Which to merge from? Well, the master has whatever latest changes
+ - were committed (or pushed changes, if this is a bare remote),
+ - while the synced/master may have changes that some
+ - other remote synced to this remote. So, merge them both. -}
+mergeRemote :: Remote -> CurrBranch -> [Git.Merge.MergeConfig] -> SyncOptions -> CommandCleanup
+mergeRemote remote currbranch mergeconfig o = ifM isBareRepo
+	( return True
+	, case currbranch of
+		(Nothing, _) -> do
+			branch <- inRepo Git.Branch.currentUnsafe
+			mergelisted (pure (branchlist branch))
+		(Just branch, _) -> do
+			inRepo $ updateBranch (syncBranch branch) branch
+			mergelisted (tomerge (branchlist (Just branch)))
+	)
+  where
+	mergelisted getlist =
+		merge currbranch mergeconfig o Git.Branch.ManualCommit
+			=<< map (remoteBranch remote) <$> getlist
+	tomerge = filterM (changed remote)
+	branchlist Nothing = []
+	branchlist (Just branch)
+		| is_branchView branch = []
+		| otherwise = [origBranch branch, syncBranch branch]
+
+pushRemote :: SyncOptions -> Remote -> CurrBranch -> CommandStart
+pushRemote _o _remote (Nothing, _) = stop
+pushRemote o remote (Just branch, _) = do
+	onlyannex <- onlyAnnex o
+	let mainbranch = if onlyannex then Nothing else Just branch
+	stopUnless (pure (pushOption o) <&&> needpush mainbranch) $
+		starting "push" ai si $ next $ do
+			repo <- Remote.getRepo remote
+			showOutput
+			ms <- Annex.getState Annex.output
+			ok <- inRepoWithSshOptionsTo repo gc $
+				pushBranch remote mainbranch ms
+			if ok
+				then postpushupdate repo
+				else do
+					warning $ UnquotedString $ unwords [ "Pushing to " ++ Remote.name remote ++ " failed." ]
+					return ok
+  where
+	ai = ActionItemOther (Just (UnquotedString (Remote.name remote)))
+	si = SeekInput []
+	gc = Remote.gitconfig remote
+	needpush mainbranch
+		| remoteAnnexReadOnly gc = return False
+		| not (remoteAnnexPush gc) = return False
+		| otherwise = anyM (newer remote) $ catMaybes
+			[ syncBranch <$> mainbranch
+			, Just (Annex.Branch.name)
+			]
+	-- Older remotes on crippled filesystems may not have a
+	-- post-receive hook set up, so when updateInstead emulation
+	-- is needed, run post-receive manually.
+	postpushupdate repo = case Git.repoWorkTree repo of
+		Nothing -> return True
+		Just wt -> ifM needemulation
+			( gitAnnexChildProcess "post-receive" []
+				(\cp -> cp { cwd = Just (fromRawFilePath wt) })
+				(\_ _ _ pid -> waitForProcess pid >>= return . \case
+					ExitSuccess -> True
+					_ -> False
+				)
+			, return True
+			)
+	  where
+		needemulation = Remote.Git.onLocalRepo repo $
+			(annexCrippledFileSystem <$> Annex.getGitConfig)
+				<&&>
+			needUpdateInsteadEmulation			
+
+{- Pushes a regular branch like master to a remote. Also pushes the git-annex
+ - branch.
+ -
+ - If the remote is a bare git repository, it's best to push the regular
+ - branch directly to it, so that cloning/pulling will get it.
+ - On the other hand, if it's not bare, pushing to the checked out branch
+ - will generally fail (except with receive.denyCurrentBranch=updateInstead),
+ - and this is why we push to its syncBranch.
+ -
+ - Git offers no way to tell if a remote is bare or not, so both methods
+ - are tried.
+ -
+ - The direct push is likely to spew an ugly error message, so its stderr is
+ - often elided. Since git progress display goes to stderr too, the 
+ - sync push is done first, and actually sends the data. Then the
+ - direct push is tried, with stderr discarded, to update the branch ref
+ - on the remote.
+ -
+ - The sync push first sends the synced/master branch,
+ - and then forces the update of the remote synced/git-annex branch.
+ -
+ - Since some providers like github may treat the first branch sent
+ - as the default branch, it's better to make that be synced/master than
+ - synced/git-annex. (Although neither is ideal, it's the best that
+ - can be managed given the constraints on order.)
+ -
+ - The forcing is necessary if a transition has rewritten the git-annex branch.
+ - Normally any changes to the git-annex branch get pulled and merged before
+ - this push, so this forcing is unlikely to overwrite new data pushed
+ - in from another repository that is also syncing.
+ -
+ - But overwriting of data on synced/git-annex can happen, in a race.
+ - The only difference caused by using a forced push in that case is that
+ - the last repository to push wins the race, rather than the first to push.
+ -}
+pushBranch :: Remote -> Maybe Git.Branch -> MessageState -> Git.Repo -> IO Bool
+pushBranch remote mbranch ms g = directpush `after` annexpush `after` syncpush
+  where
+	syncpush = flip Git.Command.runBool g $ pushparams $ catMaybes
+		[ (refspec . origBranch) <$> mbranch
+		, Just $ Git.Branch.forcePush $ refspec Annex.Branch.name
+		]
+	annexpush = void $ tryIO $ flip Git.Command.runQuiet g $ pushparams
+		[ Git.fromRef $ Git.Ref.base $ Annex.Branch.name ]
+	directpush = case mbranch of
+		Nothing -> noop
+		-- Git prints out an error message when this fails.
+		-- In the default configuration of receive.denyCurrentBranch,
+		-- the error message mentions that config setting
+		-- (and should even if it is localized), and is quite long,
+		-- and the user was not intending to update the checked out
+		-- branch, so in that case, avoid displaying the error
+		-- message. Do display other error messages though,
+		-- including the error displayed when
+		-- receive.denyCurrentBranch=updateInstead -- the user
+		-- will want to see that one.
+		Just branch -> do
+			let p = flip Git.Command.gitCreateProcess g $ pushparams
+				[ Git.fromRef $ Git.Ref.base $ origBranch branch ]
+			(transcript, ok) <- processTranscript' p Nothing
+			when (not ok && not ("denyCurrentBranch" `isInfixOf` transcript)) $
+				hPutStr stderr transcript
+	pushparams branches = catMaybes
+		[ Just $ Param "push"
+		, if commandProgressDisabled' ms
+			then Just $ Param "--quiet"
+			else Nothing
+		, Just $ Param $ Remote.name remote
+		] ++ map Param branches
+	refspec b = concat 
+		[ Git.fromRef $ Git.Ref.base b
+		,  ":"
+		, Git.fromRef $ Git.Ref.base $ syncBranch b
+		]
+
+commitAnnex :: CommandStart
+commitAnnex = do
+	Annex.Branch.commit =<< Annex.Branch.commitMessage
+	stop
+
+mergeAnnex :: CommandStart
+mergeAnnex = do
+	void Annex.Branch.forceUpdate
+	stop
+
+changed :: Remote -> Git.Ref -> Annex Bool
+changed remote b = do
+	let r = remoteBranch remote b
+	ifM (inRepo $ Git.Ref.exists r)
+		( inRepo $ Git.Branch.changed b r
+		, return False
+		)
+
+newer :: Remote -> Git.Ref -> Annex Bool
+newer remote b = do
+	let r = remoteBranch remote b
+	ifM (inRepo $ Git.Ref.exists r)
+		( inRepo $ Git.Branch.changed r b
+		, return True
+		)
+
+{- Without --all, only looks at files in the work tree.
+ - (Or, when in an adjusted branch where some files are hidden, at files in
+ - the original branch.)
+ -
+ - With --all, when preferred content expressions look at filenames,
+ - makes a first pass over the files in the work tree so those preferred
+ - content expressions will match. The second pass is over all keys,
+ - and only preferred content expressions that don't look at filenames
+ - will match.
+ -
+ - Returns true if any file transfers were made.
+ -
+ - When concurrency is enabled, files are processed concurrently.
+ -}
+seekSyncContent :: SyncOptions -> [Remote] -> CurrBranch -> Annex Bool
+seekSyncContent _ [] _ = return False
+seekSyncContent o rs currbranch = do
+	mvar <- liftIO newEmptyMVar
+	bloom <- case keyOptions o of
+		Just WantAllKeys -> ifM preferredcontentmatchesfilenames
+			( Just <$> genBloomFilter (seekworktree mvar (WorkTreeItems []))
+			, pure Nothing
+			)
+		_ -> case currbranch of
+                	(Just origbranch, Just adj) | adjustmentHidesFiles adj -> do
+				l <- workTreeItems' (AllowHidden True) ww (contentOfOption o)
+				seekincludinghidden origbranch mvar l (const noop)
+				pure Nothing
+			_ -> do
+				l <- workTreeItems ww (contentOfOption o)
+				seekworktree mvar l (const noop)
+				pure Nothing
+	waitForAllRunningCommandActions
+	withKeyOptions' (keyOptions o) False
+		(return (const (commandAction . gokey mvar bloom)))
+		(const noop)
+		(WorkTreeItems [])
+	waitForAllRunningCommandActions
+	liftIO $ not <$> isEmptyMVar mvar
+  where
+	seekworktree mvar l bloomfeeder = do
+		let seeker = AnnexedFileSeeker
+			{ startAction = const $ gofile bloomfeeder mvar
+			, checkContentPresent = Nothing
+			, usesLocationLog = True
+			}
+		seekFilteredKeys seeker $
+			seekHelper fst3 ww LsFiles.inRepoDetails l
+
+	seekincludinghidden origbranch mvar l bloomfeeder =
+		let filterer = \(si, f) -> lookupKey f >>= \case
+			Just k -> (commandAction $ gofile bloomfeeder mvar si f k)
+			Nothing -> noop
+		in seekFiltered (const (pure True)) filterer $
+			seekHelper id ww (LsFiles.inRepoOrBranch origbranch) l 
+
+	ww = WarnUnmatchLsFiles $
+		case operationMode o of
+			SyncMode -> "sync"
+			PullMode -> "pull"
+			PushMode -> "push"
+			SatisfyMode -> "satisfy"
+			AssistMode -> "assist"
+
+	gofile bloom mvar _ f k = 
+		go (Right bloom) mvar (AssociatedFile (Just f)) k
+	
+	gokey mvar bloom (_, k, _) =
+		go (Left bloom) mvar (AssociatedFile Nothing) k
+
+	go ebloom mvar af k = do
+		let ai = OnlyActionOn k (ActionItemKey k)
+		startingNoMessage ai $ do
+			whenM (syncFile o ebloom rs af k) $
+				void $ liftIO $ tryPutMVar mvar ()
+			next $ return True
+
+	preferredcontentmatchesfilenames =
+		preferredcontentmatchesfilenames' Nothing
+		<||> anyM (preferredcontentmatchesfilenames' . Just . Remote.uuid) rs
+	preferredcontentmatchesfilenames' =
+		introspectPreferredRequiredContent matchNeedsFileName
+
+{- If it's preferred content, and we don't have it, get it from one of the
+ - listed remotes (preferring the cheaper earlier ones).
+ -
+ - Send it to each remote that doesn't have it, and for which it's
+ - preferred content.
+ -
+ - Drop it locally if it's not preferred content (honoring numcopies).
+ - 
+ - Drop it from each remote that has it, where it's not preferred content
+ - (honoring numcopies).
+ -
+ - Returns True if any file transfers were made.
+ -}
+syncFile :: SyncOptions -> Either (Maybe (Bloom Key)) (Key -> Annex ()) -> [Remote] -> AssociatedFile -> Key -> Annex Bool
+syncFile o ebloom rs af k = do
+	inhere <- inAnnex k
+	locs <- map Remote.uuid <$> Remote.keyPossibilities (Remote.IncludeIgnored False) k
+	let (have, lack) = partition (\r -> Remote.uuid r `elem` locs) rs
+
+	got <- anyM id =<< handleget have inhere
+	let inhere' = inhere || got
+	putrs <- handleput lack inhere'
+
+	u <- getUUID
+	let locs' = concat [if inhere' then [u] else [], putrs, locs]
+
+	-- To handle --all, a bloom filter is populated with all the keys
+	-- of files in the working tree in the first pass. On the second
+	-- pass, avoid dropping keys that were seen in the first pass, which
+	-- would happen otherwise when preferred content matches on the
+	-- filename, which is not available in the second pass.
+	-- (When the preferred content expressions do not match on
+	-- filenames, the first pass is skipped for speed.)
+	--
+	-- When there's a false positive in the bloom filter, the result
+	-- is keeping a key that preferred content doesn't really want.
+	seenbloom <- case ebloom of
+		Left Nothing -> pure False
+		Left (Just bloom) -> pure (elemB k bloom)
+		Right bloomfeeder -> bloomfeeder k >> return False
+	unless seenbloom $
+		-- Using callCommandAction rather than
+		-- includeCommandAction for drops,
+		-- because a failure to drop does not mean
+		-- the sync failed.
+		handleDropsFrom locs' rs "unwanted" True k af si []
+			callCommandAction
+	
+	return (got || not (null putrs))
+  where
+	wantget have inhere = allM id 
+		[ pure (pullOption o || operationMode o == SatisfyMode)
+		, pure (not $ null have)
+		, pure (not inhere)
+		, wantGet True (Just k) af
+		]
+	handleget have inhere = ifM (wantget have inhere)
+		( return [ get have ]
+		, return []
+		)
+	get have = includeCommandAction $ starting "get" ai si $
+		stopUnless (getKey' k af have) $
+			next $ return True
+
+	wantput r
+		| pushOption o == False && operationMode o /= SatisfyMode = return False
+		| Remote.readonly r || remoteAnnexReadOnly (Remote.gitconfig r) = return False
+		| isExport r || isImport r = return False
+		| isThirdPartyPopulated r = return False
+		| otherwise = wantGetBy True (Just k) af (Remote.uuid r)
+	handleput lack inhere
+		| inhere = catMaybes <$>
+			( forM lack $ \r ->
+				ifM (wantput r <&&> put r)
+					( return (Just (Remote.uuid r))
+					, return Nothing
+					)
+			)
+		| otherwise = return []
+	put dest = includeCommandAction $ 
+		Command.Move.toStart' dest Command.Move.RemoveNever af k ai si
+
+	ai = mkActionItem (k, af)
+	si = SeekInput []
+
+{- When a remote has an annex-tracking-branch configuration, and that branch
+ - is currently checked out, change the export to contain the current content
+ - of the branch. (If the branch is not currently checked out, anything
+ - imported from the remote will not yet have been merged into it yet and
+ - so exporting would delete files from the remote unexpectedly.)
+ - (This is not done in SatifyMode.)
+ -
+ - Otherwise, transfer any files that were part of a previous export
+ - but are not in the remote yet.
+ - 
+ - Returns True if any file transfers were made.
+ -}
+seekExportContent :: Maybe SyncOptions -> [Remote] -> CurrBranch -> Annex Bool
+seekExportContent o rs (mcurrbranch, madj)
+	| null rs = return False
+	| otherwise = do
+		-- Propigate commits from the adjusted branch, so that
+		-- when the remoteAnnexTrackingBranch is set to the parent
+		-- branch, it will be up-to-date.
+		case (mcurrbranch, madj) of
+			(Just currbranch, Just adj) ->
+				propigateAdjustedCommits currbranch adj
+			_ -> noop
+		or <$> forM rs go
+  where
+	go r
+		| maybe False (\o' -> operationMode o' == SatisfyMode) o =
+			case remoteAnnexTrackingBranch (Remote.gitconfig r) of
+				Nothing -> return False
+				Just _ -> withdb r $ \db ->
+					cannotupdateexport r db Nothing False
+		| not (maybe True pushOption o) = return False
+		| not (remoteAnnexPush (Remote.gitconfig r)) = return False
+		| otherwise = withdb r (go' r)
+	go' r db = case remoteAnnexTrackingBranch (Remote.gitconfig r) of
+		Nothing -> cannotupdateexport r db Nothing True
+		Just b -> do
+			mtree <- inRepo $ Git.Ref.tree b
+			let addsubdir = case snd (splitRemoteAnnexTrackingBranchSubdir b) of
+				Just subdir -> \cb -> Git.Ref $
+					Git.fromRef' cb  <> ":" <> getTopFilePath subdir
+				Nothing -> id
+			mcurrtree <- maybe (pure Nothing)
+				(inRepo . Git.Ref.tree . addsubdir)
+				mcurrbranch
+			mtbcommitsha <- Command.Export.getExportCommit r b
+			case (mtree, mcurrtree, mtbcommitsha) of
+				(Just tree, Just currtree, Just _)
+					| tree == currtree -> do
+						filteredtree <- Command.Export.filterExport r tree
+						Command.Export.changeExport r db filteredtree
+						Command.Export.fillExport r db filteredtree mtbcommitsha
+					| otherwise -> cannotupdateexport r db Nothing False
+				(Nothing, _, _) -> cannotupdateexport r db (Just (Git.fromRef b ++ " does not exist")) True
+				(_, Nothing, _) -> cannotupdateexport r db (Just "no branch is currently checked out") True
+				(_, _, Nothing) -> cannotupdateexport r db (Just "tracking branch name is not valid") True
+	
+	withdb r a = bracket
+		(Export.openDb (Remote.uuid r))
+		Export.closeDb
+		(\db -> Export.writeLockDbWhile db (a db))
+	
+	cannotupdateexport r db mreason showwarning = do
+		exported <- getExport (Remote.uuid r)
+		when showwarning $
+			maybe noop (warncannotupdateexport r mreason exported) mcurrbranch
+		fillexistingexport r db (exportedTreeishes exported) Nothing
+	
+	warncannotupdateexport r mreason exported currb = case mreason of
+		Nothing -> inRepo (Git.Ref.tree currb) >>= \case
+			Just currt | not (any (== currt) (exportedTreeishes exported)) ->
+				showLongNote $ UnquotedString $ unwords
+					[ notupdating
+					, "to reflect changes to the tree, because export"
+					, "tracking is not enabled. "
+					, "(Set " ++ gitconfig ++ " to enable it.)"
+					]
+			_ -> noop
+		Just reason -> showLongNote $ UnquotedString $ unwords
+			[ notupdating
+			, "because " ++ reason ++ "."
+			, "(As configured by " ++ gitconfig ++ ")"
+			]
+	  where
+		gitconfig = show (remoteAnnexConfig r "tracking-branch")
+		notupdating = "Not updating export to " ++ Remote.name r
+
+	fillexistingexport _ _ [] _ = return False
+	fillexistingexport r db (tree:[]) mtbcommitsha = do
+		-- The tree was already filtered when it was exported, so
+		-- does not need be be filtered again now, when we're only
+		-- filling in any files that did not get transferred
+		-- to the existing exported tree.
+		let filteredtree = Command.Export.ExportFiltered tree
+		Command.Export.fillExport r db filteredtree mtbcommitsha
+	fillexistingexport r _ _ _ = do
+		warnExportImportConflict r
+		return False
+
+cleanupLocal :: CurrBranch -> CommandStart
+cleanupLocal (Nothing, _) = stop
+cleanupLocal (Just currb, _) = starting "cleanup" ai si $ next $ do
+	delbranch $ syncBranch currb
+	delbranch $ syncBranch $ Git.Ref.base $ Annex.Branch.name
+	mapM_ (\(s,r) -> inRepo $ Git.Ref.delete s r) =<< listTaggedBranches
+	return True
+  where
+	delbranch b = whenM (inRepo $ Git.Ref.exists $ Git.Ref.branchRef b) $
+		inRepo $ Git.Branch.delete b
+	ai = ActionItemOther (Just "local")
+	si = SeekInput []
+
+cleanupRemote :: Remote -> CurrBranch -> CommandStart
+cleanupRemote _ (Nothing, _) = stop
+cleanupRemote remote (Just b, _) =
+	starting "cleanup" ai si $
+		next $ inRepo $ Git.Command.runBool
+			[ Param "push"
+			, Param "--quiet"
+			, Param "--delete"
+			, Param $ Remote.name remote
+			, Param $ Git.fromRef $ syncBranch b
+			, Param $ Git.fromRef $ syncBranch $
+				Git.Ref.base $ Annex.Branch.name
+			]
+  where
+	ai = ActionItemOther (Just (UnquotedString (Remote.name remote)))
+	si = SeekInput []
+
+shouldSyncContent :: SyncOptions -> Annex Bool
+shouldSyncContent o
+	| fromMaybe False (noContentOption o) = pure False
+	| operationMode o == SatisfyMode = pure True
+	-- For git-annex pull and git-annex push and git-annex assist,
+	-- annex.syncontent defaults to True unless set
+	| operationMode o /= SyncMode = annexsynccontent True
+	| fromMaybe False (contentOption o) || not (null (contentOfOption o)) = pure True
+	-- For git-annex sync, 
+	-- annex.syncontent defaults to False unless set
+	| otherwise = annexsynccontent False <||> onlyAnnex o
+  where
+	annexsynccontent d = 
+		getGitConfigVal' annexSyncContent >>= \case
+			HasGlobalConfig (Just c) -> return c
+			HasGitConfig (Just c) -> return c
+			_ -> return d
+
+-- See doc/todo/finish_sync_content_transition.mdwn
+warnSyncContentTransition :: SyncOptions -> [Remote] -> Annex ()
+warnSyncContentTransition o remotes
+	| operationMode o /= SyncMode = noop
+	| isJust (noContentOption o) || isJust (contentOption o) = noop
+	| not (null (contentOfOption o)) = noop
+	| otherwise = getGitConfigVal' annexSyncContent >>= \case
+		HasGlobalConfig (Just _) -> noop
+		HasGitConfig (Just _) -> noop
+		_ -> do
+			m <- preferredContentMap
+			hereu <- getUUID
+			when (any (`M.member` m) (hereu:map Remote.uuid remotes)) $
+				showwarning
+  where
+	showwarning = earlyWarning $
+		"git-annex sync will change default behavior in the future to"
+		<> " send content to repositories that have"
+		<> " preferred content configured. If you do not want this to"
+		<> " send any content, use --no-content (or -g)"
+		<> " to prepare for that change."
+		<> " (Or you can configure annex.synccontent)"
+
+notOnlyAnnex :: SyncOptions -> Annex Bool
+notOnlyAnnex o = not <$> onlyAnnex o
+
+onlyAnnex :: SyncOptions -> Annex Bool
+onlyAnnex o
+	| notOnlyAnnexOption o = pure False
+	| onlyAnnexOption o = pure True
+	| otherwise = getGitConfigVal annexSyncOnlyAnnex
+	
+isExport :: Remote -> Bool
+isExport = exportTree . Remote.config
+
+isImport :: Remote -> Bool
+isImport = importTree . Remote.config
+
+isThirdPartyPopulated :: Remote -> Bool
+isThirdPartyPopulated = Remote.thirdPartyPopulated . Remote.remotetype
+
+splitRemoteAnnexTrackingBranchSubdir :: Git.Ref -> (Git.Ref, Maybe TopFilePath)
+splitRemoteAnnexTrackingBranchSubdir tb = (branch, subdir)
+  where
+	(b, p) = separate' (== (fromIntegral (ord ':'))) (Git.fromRef' tb)
+	branch = Git.Ref b
+	subdir = if S.null p
+		then Nothing
+		else Just (asTopFilePath p)
diff --git a/Command/Test.hs b/Command/Test.hs
new file mode 100644
index 0000000000..a172c9ebb8
--- /dev/null
+++ b/Command/Test.hs
@@ -0,0 +1,29 @@
+{- git-annex command
+ -
+ - Copyright 2013-2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Test where
+
+import Command
+import Types.Test
+
+cmd :: Parser TestOptions -> TestRunner -> Command
+cmd optparser runner = noRepo (startIO runner <$$> const optparser) $
+	dontCheck repoExists $
+		command "test" SectionTesting
+			"run built-in test suite"
+			paramNothing (seek runner <$$> const optparser)
+
+seek :: TestRunner -> TestOptions -> CommandSeek
+seek runner o = commandAction $ start runner o
+
+start :: TestRunner -> TestOptions -> CommandStart
+start runner o = do
+	liftIO $ startIO runner o
+	stop
+
+startIO :: TestRunner -> TestOptions -> IO ()
+startIO runner o = runner o
diff --git a/Command/TestRemote.hs b/Command/TestRemote.hs
new file mode 100644
index 0000000000..9f8c5f1df9
--- /dev/null
+++ b/Command/TestRemote.hs
@@ -0,0 +1,460 @@
+{- git-annex command
+ -
+ - Copyright 2014-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes, DeriveFunctor, PackageImports, OverloadedStrings #-}
+
+module Command.TestRemote where
+
+import Command
+import qualified Annex
+import qualified Remote
+import qualified Types.Remote as Remote
+import qualified Types.Backend
+import Types.KeySource
+import Annex.Content
+import Annex.WorkTree
+import Backend
+import Logs.Location
+import qualified Backend.Hash
+import Utility.Tmp
+import Utility.Metered
+import Utility.DataUnits
+import Utility.CopyFile
+import Types.Messages
+import Types.Export
+import Types.RemoteConfig
+import Types.ProposedAccepted
+import Annex.SpecialRemote.Config (exportTreeField)
+import Remote.Helper.Chunked
+import Remote.Helper.Encryptable (encryptionField, highRandomQualityField)
+import Git.Types
+
+import Test.Tasty
+import Test.Tasty.Runners
+import Test.Tasty.HUnit
+import "crypto-api" Crypto.Random
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Map as M
+import Data.Either
+import Control.Concurrent.STM hiding (check)
+
+cmd :: Command
+cmd = command "testremote" SectionTesting
+	"test transfers to/from a remote"
+	paramRemote (seek <$$> optParser)
+
+data TestRemoteOptions = TestRemoteOptions
+	{ testRemote :: RemoteName
+	, sizeOption :: ByteSize
+	, testReadonlyFile :: [FilePath]
+	}
+
+optParser :: CmdParamsDesc -> Parser TestRemoteOptions
+optParser desc = TestRemoteOptions
+	<$> argument str ( metavar desc )
+	<*> option (str >>= maybe (fail "parse error") return . readSize dataUnits)
+		( long "size" <> metavar paramSize
+		<> value (1024 * 1024)
+		<> help "base key size (default 1MiB)"
+		)
+	<*> many testreadonly
+  where
+	testreadonly = option str
+		( long "test-readonly" <> metavar paramFile
+		<> help "readonly test object"
+		)
+
+seek :: TestRemoteOptions -> CommandSeek
+seek = commandAction . start 
+
+start :: TestRemoteOptions -> CommandStart
+start o = starting "testremote" (ActionItemOther (Just (UnquotedString (testRemote o)))) si $ do
+	fast <- Annex.getRead Annex.fast
+	cache <- liftIO newRemoteVariantCache
+	r <- either giveup (disableExportTree cache)
+		=<< Remote.byName' (testRemote o)
+	ks <- case testReadonlyFile o of
+		[] -> if Remote.readonly r
+			then giveup "This remote is readonly, so you need to use the --test-readonly option."
+			else do
+				showAction "generating test keys"
+				mapM randKey (keySizes basesz fast)
+		fs -> mapM (getReadonlyKey r . toRawFilePath) fs
+	let r' = if null (testReadonlyFile o)
+		then r
+		else r { Remote.readonly = True }
+	let drs = if Remote.readonly r'
+		then [Described "remote" (pure (Just r'))]
+		else remoteVariants cache (Described "remote" (pure r')) basesz fast
+	unavailr  <- Remote.mkUnavailable r'
+	let exportr = if Remote.readonly r'
+		then return Nothing
+		else exportTreeVariant cache r'
+	perform drs unavailr exportr ks
+  where
+	basesz = fromInteger $ sizeOption o
+	si = SeekInput [testRemote o]
+
+perform :: [Described (Annex (Maybe Remote))] -> Maybe Remote -> Annex (Maybe Remote) -> [Key] -> CommandPerform
+perform drs unavailr exportr ks = do
+	st <- liftIO . newTVarIO =<< (,)
+		<$> Annex.getState id
+		<*> Annex.getRead id
+	let tests = testGroup "Remote Tests" $ mkTestTrees
+		(runTestCase st) 
+		drs
+		(pure unavailr)
+		exportr
+		(map (\k -> Described (desck k) (pure k)) ks)
+	ok <- case tryIngredients [consoleTestReporter] mempty tests of
+		Nothing -> error "No tests found!?"
+		Just act -> liftIO act
+	rs <- catMaybes <$> mapM getVal drs
+	next $ cleanup rs ks ok
+  where
+	desck k = unwords [ "key size", show (fromKey keySize k) ]
+
+remoteVariants :: RemoteVariantCache -> Described (Annex Remote) -> Int -> Bool -> [Described (Annex (Maybe Remote))]
+remoteVariants cache dr basesz fast = 
+	concatMap (encryptionVariants cache) $
+		map chunkvariant (chunkSizes basesz fast)
+  where
+	chunkvariant sz = Described (getDesc dr ++ " chunksize=" ++ show sz) $ do
+		r <- getVal dr
+		adjustChunkSize cache r sz
+
+adjustChunkSize :: RemoteVariantCache -> Remote -> Int -> Annex (Maybe Remote)
+adjustChunkSize cache r chunksize = adjustRemoteConfig cache r $
+	M.insert chunkField (Proposed (show chunksize))
+
+-- Variants of a remote with no encryption, and with simple shared
+-- encryption. Gpg key based encryption is not tested.
+encryptionVariants :: RemoteVariantCache -> Described (Annex (Maybe Remote)) -> [Described (Annex (Maybe Remote))]
+encryptionVariants cache dr = [noenc, sharedenc]
+  where
+	noenc = Described (getDesc dr ++ " encryption=none") $
+		getVal dr >>= \case
+			Nothing -> return Nothing
+			Just r -> adjustRemoteConfig cache r $
+				M.insert encryptionField (Proposed "none")
+	sharedenc = Described (getDesc dr ++ " encryption=shared") $
+		getVal dr >>= \case
+			Nothing -> return Nothing
+			Just r -> adjustRemoteConfig cache r $
+				M.insert encryptionField (Proposed "shared") .
+				M.insert highRandomQualityField (Proposed "false")
+
+-- Variant of a remote with exporttree disabled.
+disableExportTree :: RemoteVariantCache -> Remote -> Annex Remote
+disableExportTree cache r = maybe (giveup "failed disabling exportree") return 
+		=<< adjustRemoteConfig cache r (M.delete exportTreeField)
+
+-- Variant of a remote with exporttree enabled.
+exportTreeVariant :: RemoteVariantCache -> Remote -> Annex (Maybe Remote)
+exportTreeVariant cache r = ifM (Remote.isExportSupported r)
+	( adjustRemoteConfig cache r $
+		M.insert encryptionField (Proposed "none") . 
+		M.insert exportTreeField (Proposed "yes")
+	, return Nothing
+	)
+
+-- The Annex wrapper is used by Test; it should return the same TMVar
+-- each time run.
+type RemoteVariantCache = Annex (TVar (M.Map RemoteConfig Remote))
+
+newRemoteVariantCache :: IO RemoteVariantCache
+newRemoteVariantCache = newTVarIO M.empty >>= return . pure
+
+-- Regenerate a remote with a modified config.
+adjustRemoteConfig :: RemoteVariantCache -> Remote -> (Remote.RemoteConfig -> Remote.RemoteConfig) -> Annex (Maybe Remote)
+adjustRemoteConfig getcache r adjustconfig = do
+	cache <- getcache
+	m <- liftIO $ atomically $ readTVar cache
+	let ParsedRemoteConfig _ origc = Remote.config r
+	let newc = adjustconfig origc
+	case M.lookup newc m of
+		Just r' -> return (Just r')
+		Nothing -> do
+			repo <- Remote.getRepo r
+			v <- Remote.generate (Remote.remotetype r)
+				repo
+				(Remote.uuid r)
+				newc
+				(Remote.gitconfig r)
+				(Remote.remoteStateHandle r)
+			case v of
+				Just r' -> liftIO $ atomically $
+					modifyTVar' cache $ M.insert newc r'
+				Nothing -> return ()
+			return v
+
+data Described t = Described
+	{ getDesc :: String
+	, getVal :: t
+	} deriving Functor
+
+type RunAnnex = forall a. Annex a -> IO a
+
+runTestCase :: TVar (Annex.AnnexState, Annex.AnnexRead) -> RunAnnex
+runTestCase stv a = do
+	st <- atomically $ readTVar stv
+	(r, st') <- Annex.run st $ do
+		Annex.setOutput QuietOutput 
+		a
+	atomically $ writeTVar stv st'
+	return r
+
+-- Note that the same remotes and keys should be produced each time
+-- the provided actions are called.
+mkTestTrees
+	:: RunAnnex
+	-> [Described (Annex (Maybe Remote))]
+	-> Annex (Maybe Remote)
+	-> Annex (Maybe Remote)
+	-> [Described (Annex Key)]
+	-> [TestTree]
+mkTestTrees runannex mkrs mkunavailr mkexportr mkks = concat $
+	[ [ testGroup "unavailable remote" (testUnavailable runannex mkunavailr (getVal (Prelude.head mkks))) ]
+	, [ testGroup (desc mkr mkk) (test runannex (getVal mkr) (getVal mkk)) | mkk <- mkks, mkr <- mkrs ]
+	, [ testGroup (descexport mkk1 mkk2) (testExportTree runannex mkexportr (getVal mkk1) (getVal mkk2)) | mkk1 <- take 2 mkks, mkk2 <- take 2 (reverse mkks) ]
+	]
+   where
+	desc r k = intercalate "; " $ map unwords
+		[ [ getDesc k ]
+		, [ getDesc r ]
+		]
+	descexport k1 k2 = intercalate "; " $ map unwords
+		[ [ "exporttree=yes" ]
+		, [ getDesc k1 ]
+		, [ getDesc k2 ]
+		]
+
+test :: RunAnnex -> Annex (Maybe Remote) -> Annex Key -> [TestTree]
+test runannex mkr mkk =
+	[ check "removeKey when not present" $ \r k ->
+		whenwritable r $ runBool (remove r k)
+	, check ("present " ++ show False) $ \r k ->
+		whenwritable r $ present r k False
+	, check "storeKey" $ \r k ->
+		whenwritable r $ runBool (store r k)
+	, check ("present " ++ show True) $ \r k ->
+		whenwritable r $ present r k True
+	, check "storeKey when already present" $ \r k ->
+		whenwritable r $ runBool (store r k)
+	, check ("present " ++ show True) $ \r k -> present r k True
+	, check "retrieveKeyFile" $ \r k -> do
+		lockContentForRemoval k noop removeAnnex
+		get r k
+	, check "fsck downloaded object" fsck
+	, check "retrieveKeyFile resume from 0" $ \r k -> do
+		tmp <- fromRawFilePath <$> prepTmp k
+		liftIO $ writeFile tmp ""
+		lockContentForRemoval k noop removeAnnex
+		get r k
+	, check "fsck downloaded object" fsck
+	, check "retrieveKeyFile resume from 33%" $ \r k -> do
+		loc <- fromRawFilePath <$> Annex.calcRepo (gitAnnexLocation k)
+		tmp <- fromRawFilePath <$> prepTmp k
+		partial <- liftIO $ bracket (openBinaryFile loc ReadMode) hClose $ \h -> do
+			sz <- hFileSize h
+			L.hGet h $ fromInteger $ sz `div` 3
+		liftIO $ L.writeFile tmp partial
+		lockContentForRemoval k noop removeAnnex
+		get r k
+	, check "fsck downloaded object" fsck
+	, check "retrieveKeyFile resume from end" $ \r k -> do
+		loc <- fromRawFilePath <$> Annex.calcRepo (gitAnnexLocation k)
+		tmp <- fromRawFilePath <$> prepTmp k
+		void $ liftIO $ copyFileExternal CopyAllMetaData loc tmp
+		lockContentForRemoval k noop removeAnnex
+		get r k
+	, check "fsck downloaded object" fsck
+	, check "removeKey when present" $ \r k -> 
+		whenwritable r $ runBool (remove r k)
+	, check ("present " ++ show False) $ \r k -> 
+		whenwritable r $ present r k False
+	]
+  where
+	whenwritable r a
+		| Remote.readonly r = return True
+		| otherwise = a
+	check desc a = testCase desc $ do
+		let a' = mkr >>= \case
+			Just r -> do
+				k <- mkk
+				a r k
+			Nothing -> return True
+		runannex a' @? "failed"
+	present r k b = (== Right b) <$> Remote.hasKey r k
+	fsck _ k = maybeLookupBackendVariety (fromKey keyVariety k) >>= \case
+		Nothing -> return True
+		Just b -> case Types.Backend.verifyKeyContent b of
+			Nothing -> return True
+			Just verifier -> verifier k (serializeKey' k)
+	get r k = logStatusAfter k $ getViaTmp (Remote.retrievalSecurityPolicy r) (RemoteVerify r) k (AssociatedFile Nothing) Nothing $ \dest ->
+		tryNonAsync (Remote.retrieveKeyFile r k (AssociatedFile Nothing) (fromRawFilePath dest) nullMeterUpdate (RemoteVerify r)) >>= \case
+			Right v -> return (True, v)
+			Left _ -> return (False, UnVerified)
+	store r k = Remote.storeKey r k (AssociatedFile Nothing) nullMeterUpdate
+	remove r k = Remote.removeKey r k
+
+testExportTree :: RunAnnex -> Annex (Maybe Remote) -> Annex Key -> Annex Key -> [TestTree]
+testExportTree runannex mkr mkk1 mkk2 =
+	[ check "check present export when not present" $ \ea k1 _k2 ->
+		not <$> checkpresentexport ea k1
+	, check "remove export when not present" $ \ea k1 _k2 -> 
+		runBool (removeexport ea k1)
+	, check "store export" $ \ea k1 _k2 ->
+		runBool (storeexport ea k1)
+	, check "check present export after store" $ \ea k1 _k2 ->
+		checkpresentexport ea k1
+	, check "store export when already present" $ \ea k1 _k2 ->
+		runBool (storeexport ea k1)
+	, check "retrieve export" $ \ea k1 _k2 -> 
+		retrieveexport ea k1
+	, check "store new content to export" $ \ea _k1 k2 ->
+		runBool (storeexport ea k2)
+	, check "check present export after store of new content" $ \ea _k1 k2 ->
+		checkpresentexport ea k2
+	, check "retrieve export new content" $ \ea _k1 k2 ->
+		retrieveexport ea k2
+	, check "remove export" $ \ea _k1 k2 -> 
+		runBool (removeexport ea k2)
+	, check "check present export after remove" $ \ea _k1 k2 ->
+		not <$> checkpresentexport ea k2
+	, check "retrieve export fails after removal" $ \ea _k1 k2 ->
+		not <$> retrieveexport ea k2
+	, check "remove export directory" $ \ea _k1 _k2 ->
+		runBool (removeexportdirectory ea)
+	, check "remove export directory that is already removed" $ \ea _k1 _k2 ->
+		runBool (removeexportdirectory ea)
+	-- renames are not tested because remotes do not need to support them
+	]
+  where
+	testexportdirectory = "testremote-export"
+	testexportlocation = mkExportLocation (toRawFilePath (testexportdirectory </> "location"))
+	check desc a = testCase desc $ do
+		let a' = mkr >>= \case
+			Just r -> do
+				let ea = Remote.exportActions r
+				k1 <- mkk1
+				k2 <- mkk2
+				a ea k1 k2
+			Nothing -> return True
+		runannex a' @? "failed"
+	storeexport ea k = do
+		loc <- fromRawFilePath <$> Annex.calcRepo (gitAnnexLocation k)
+		Remote.storeExport ea loc k testexportlocation nullMeterUpdate
+	retrieveexport ea k = withTmpFile "exported" $ \tmp h -> do
+		liftIO $ hClose h
+		tryNonAsync (Remote.retrieveExport ea k testexportlocation tmp nullMeterUpdate) >>= \case
+			Left _ -> return False
+			Right v -> verifyKeyContentPostRetrieval RetrievalAllKeysSecure AlwaysVerify v k (toRawFilePath tmp)
+	checkpresentexport ea k = Remote.checkPresentExport ea k testexportlocation
+	removeexport ea k = Remote.removeExport ea k testexportlocation
+	removeexportdirectory ea = case Remote.removeExportDirectory ea of
+		Just a -> a (mkExportDirectory (toRawFilePath testexportdirectory))
+		Nothing -> noop
+
+testUnavailable :: RunAnnex -> Annex (Maybe Remote) -> Annex Key -> [TestTree]
+testUnavailable runannex mkr mkk =
+	[ check isLeft "removeKey" $ \r k ->
+		Remote.removeKey r k
+	, check isLeft "storeKey" $ \r k -> 
+		Remote.storeKey r k (AssociatedFile Nothing) nullMeterUpdate
+	, check (`notElem` [Right True, Right False]) "checkPresent" $ \r k ->
+		Remote.checkPresent r k
+	, check (== Right False) "retrieveKeyFile" $ \r k ->
+		logStatusAfter k $ getViaTmp (Remote.retrievalSecurityPolicy r) (RemoteVerify r) k (AssociatedFile Nothing) Nothing $ \dest ->
+			tryNonAsync (Remote.retrieveKeyFile r k (AssociatedFile Nothing) (fromRawFilePath dest) nullMeterUpdate (RemoteVerify r)) >>= \case
+				Right v -> return (True, v)
+				Left _ -> return (False, UnVerified)
+	, check (== Right False) "retrieveKeyFileCheap" $ \r k -> case Remote.retrieveKeyFileCheap r of
+		Nothing -> return False
+		Just a -> logStatusAfter k $ getViaTmp (Remote.retrievalSecurityPolicy r) (RemoteVerify r) k (AssociatedFile Nothing) Nothing $ \dest -> 
+			unVerified $ isRight
+				<$> tryNonAsync (a k (AssociatedFile Nothing) (fromRawFilePath dest))
+	]
+  where
+	check checkval desc a = testCase desc $ 
+		join $ runannex $ mkr >>= \case
+			Just r -> do
+				k <- mkk
+				v <- either (Left  . show) Right
+					<$> tryNonAsync (a r k)
+				return $ checkval v
+					@? ("(got: " ++ show v ++ ")")
+			Nothing -> return noop
+
+cleanup :: [Remote] -> [Key] -> Bool -> CommandCleanup
+cleanup rs ks ok
+	| all Remote.readonly rs = return ok
+	| otherwise = do
+		forM_ rs $ \r -> forM_ ks (Remote.removeKey r)
+		forM_ ks $ \k -> lockContentForRemoval k noop removeAnnex
+		return ok
+
+chunkSizes :: Int -> Bool -> [Int]
+chunkSizes base False =
+	[ 0 -- no chunking
+	, base `div` 100
+	, base `div` 1000
+	, base
+	]
+chunkSizes _ True =
+	[ 0
+	]
+
+keySizes :: Int -> Bool -> [Int]
+keySizes base fast = filter want
+	[ 0 -- empty key is a special case when chunking
+	, base
+	, base + 1
+	, base - 1
+	, base * 2
+	]
+  where
+	want sz
+		| fast = sz <= base && sz > 0
+		| otherwise = sz > 0
+
+randKey :: Int -> Annex Key
+randKey sz = withTmpFile "randkey" $ \f h -> do
+	gen <- liftIO (newGenIO :: IO SystemRandom)
+	case genBytes sz gen of
+		Left e -> giveup $ "failed to generate random key: " ++ show e
+		Right (rand, _) -> liftIO $ B.hPut h rand
+	liftIO $ hClose h
+	let ks = KeySource
+		{ keyFilename = toRawFilePath f
+		, contentLocation = toRawFilePath f
+		, inodeCache = Nothing
+		}
+	k <- case Types.Backend.genKey Backend.Hash.testKeyBackend of
+		Just a -> a ks nullMeterUpdate
+		Nothing -> giveup "failed to generate random key (backend problem)"
+	_ <- moveAnnex k (AssociatedFile Nothing) (toRawFilePath f)
+	return k
+
+getReadonlyKey :: Remote -> RawFilePath -> Annex Key
+getReadonlyKey r f = do
+	qp <- coreQuotePath <$> Annex.getGitConfig
+	lookupKey f >>= \case
+		Nothing -> giveup $ decodeBS $ quote qp $ QuotedPath f <> " is not an annexed file"
+		Just k -> do
+			unlessM (inAnnex k) $
+				giveup $ decodeBS $ quote qp $ QuotedPath f <> " does not have its content locally present, cannot test it"
+			unlessM ((Remote.uuid r `elem`) <$> loggedLocations k) $
+				giveup $ decodeBS $ quote qp $ QuotedPath f <> " is not stored in the remote being tested, cannot test it"
+			return k
+
+runBool :: Monad m => m () -> m Bool
+runBool a = do
+	a
+	return True
+
diff --git a/Command/TransferKey.hs b/Command/TransferKey.hs
new file mode 100644
index 0000000000..e5564ce989
--- /dev/null
+++ b/Command/TransferKey.hs
@@ -0,0 +1,76 @@
+{- git-annex plumbing command (for use by old assistant, and users)
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.TransferKey where
+
+import Command
+import Annex.Content
+import Logs.Location
+import Annex.Transfer
+import qualified Remote
+import Types.Remote
+
+cmd :: Command
+cmd = noCommit $
+	command "transferkey" SectionPlumbing
+		"transfers a key from or to a remote"
+		paramKey (seek <--< optParser)
+
+data TransferKeyOptions = TransferKeyOptions
+	{ keyOptions :: CmdParams 
+	, fromToOptions :: FromToOptions
+	, fileOption :: AssociatedFile
+	}
+
+optParser :: CmdParamsDesc -> Parser TransferKeyOptions
+optParser desc  = TransferKeyOptions
+	<$> cmdParams desc
+	<*> parseFromToOptions
+	<*> (AssociatedFile <$> optional (strOption
+		( long "file" <> metavar paramFile
+		<> help "the associated file"
+		)))
+
+instance DeferredParseClass TransferKeyOptions where
+	finishParse v = TransferKeyOptions
+		<$> pure (keyOptions v)
+		<*> finishParse (fromToOptions v)
+		<*> pure (fileOption v)
+
+seek :: TransferKeyOptions -> CommandSeek
+seek o = withKeys (commandAction . start o) (keyOptions o)
+
+start :: TransferKeyOptions -> (SeekInput, Key) -> CommandStart
+start o (_, key) = startingCustomOutput key $ case fromToOptions o of
+	ToRemote dest -> toPerform key (fileOption o) =<< getParsed dest
+	FromRemote src -> fromPerform key (fileOption o) =<< getParsed src
+
+toPerform :: Key -> AssociatedFile -> Remote -> CommandPerform
+toPerform key file remote = go Upload file $
+	upload' (uuid remote) key file Nothing stdRetry $ \p -> do
+		tryNonAsync (Remote.storeKey remote key file p) >>= \case
+			Right () -> do
+				Remote.logStatus remote key InfoPresent
+				return True
+			Left e -> do
+				warning (UnquotedString (show e))
+				return False
+
+fromPerform :: Key -> AssociatedFile -> Remote -> CommandPerform
+fromPerform key file remote = go Upload file $
+	download' (uuid remote) key file Nothing stdRetry $ \p ->
+		logStatusAfter key $ getViaTmp (retrievalSecurityPolicy remote) vc key file Nothing $ \t ->
+			tryNonAsync (Remote.retrieveKeyFile remote key file (fromRawFilePath t) p vc) >>= \case
+				Right v -> return (True, v)	
+				Left e -> do
+					warning (UnquotedString (show e))
+					return (False, UnVerified)
+  where
+	vc = RemoteVerify remote
+
+go :: Direction -> AssociatedFile -> (NotifyWitness -> Annex Bool) -> CommandPerform
+go direction file a = notifyTransfer direction file a >>= liftIO . exitBool
diff --git a/Command/TransferKeys.hs b/Command/TransferKeys.hs
new file mode 100644
index 0000000000..fe7a71fb51
--- /dev/null
+++ b/Command/TransferKeys.hs
@@ -0,0 +1,142 @@
+{- git-annex command, used internally by assistant in version
+ - 8.20201127 and older and provided only to avoid upgrade breakage.
+ - Remove at some point when such old versions of git-annex are unlikely
+ - to be running any longer.
+ -
+ - Copyright 2012, 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-}
+
+module Command.TransferKeys where
+
+import Command
+import Annex.Content
+import Logs.Location
+import Annex.Transfer
+import qualified Remote
+import Utility.SimpleProtocol (dupIoHandles)
+import Git.Types (RemoteName)
+import qualified Database.Keys
+import Annex.BranchState
+
+data TransferRequest = TransferRequest Direction Remote Key AssociatedFile
+
+cmd :: Command
+cmd = command "transferkeys" SectionPlumbing "transfers keys (deprecated)"
+	paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = do
+	enableInteractiveBranchAccess
+	(readh, writeh) <- liftIO dupIoHandles
+	runRequests readh writeh runner
+	stop
+  where
+	runner (TransferRequest direction remote key file)
+		| direction == Upload = notifyTransfer direction file $
+			upload' (Remote.uuid remote) key file Nothing stdRetry $ \p -> do
+				tryNonAsync (Remote.storeKey remote key file p) >>= \case
+					Left e -> do
+						warning (UnquotedString (show e))
+						return False
+					Right () -> do
+						Remote.logStatus remote key InfoPresent
+						return True
+		| otherwise = notifyTransfer direction file $
+			download' (Remote.uuid remote) key file Nothing stdRetry $ \p ->
+				logStatusAfter key $ getViaTmp (Remote.retrievalSecurityPolicy remote) (RemoteVerify remote) key file Nothing $ \t -> do
+					r <- tryNonAsync (Remote.retrieveKeyFile remote key file (fromRawFilePath t) p (RemoteVerify remote)) >>= \case
+						Left e -> do
+							warning (UnquotedString (show e))
+							return (False, UnVerified)
+						Right v -> return (True, v)
+					-- Make sure we get the current
+					-- associated files data for the key,
+					-- not old cached data.
+					Database.Keys.closeDb			
+					return r
+
+runRequests
+	:: Handle
+	-> Handle
+	-> (TransferRequest -> Annex Bool)
+	-> Annex ()
+runRequests readh writeh a = do
+	liftIO $ hSetBuffering readh NoBuffering
+	go =<< readrequests
+  where
+	go (d:rn:k:f:rest) = do
+		case (deserialize d, deserialize rn, deserialize k, deserialize f) of
+			(Just direction, Just remotename, Just key, Just file) -> do
+				mremote <- Remote.byName' remotename
+				case mremote of
+					Left _ -> sendresult False
+					Right remote -> sendresult =<< a
+						(TransferRequest direction remote key file)
+			_ -> sendresult False
+		go rest
+	go [] = noop
+	go [""] = noop
+	go v = giveup $ "transferkeys protocol error: " ++ show v
+
+	readrequests = liftIO $ split fieldSep <$> hGetContents readh
+	sendresult b = liftIO $ do
+		hPutStrLn writeh $ serialize b
+		hFlush writeh
+
+sendRequest :: Transfer -> TransferInfo -> Handle -> IO ()
+sendRequest t tinfo h = do
+	hPutStr h $ intercalate fieldSep
+		[ serialize (transferDirection t)
+		, maybe (serialize ((fromUUID (transferUUID t)) :: String))
+			(serialize . Remote.name)
+			(transferRemote tinfo)
+		, serialize (transferKey t)
+		, serialize (associatedFile tinfo)
+		, "" -- adds a trailing null
+		]
+	hFlush h
+
+readResponse :: Handle -> IO Bool
+readResponse h = fromMaybe False . deserialize <$> hGetLine h
+
+fieldSep :: String
+fieldSep = "\0"
+
+class TCSerialized a where
+	serialize :: a -> String
+	deserialize :: String -> Maybe a
+
+instance TCSerialized Bool where
+	serialize True = "1"
+	serialize False = "0"
+	deserialize "1" = Just True
+	deserialize "0" = Just False
+	deserialize _ = Nothing
+
+instance TCSerialized Direction where
+	serialize Upload = "u"
+	serialize Download = "d"
+	deserialize "u" = Just Upload
+	deserialize "d" = Just Download
+	deserialize _ = Nothing
+
+instance TCSerialized AssociatedFile where
+	serialize (AssociatedFile (Just f)) = fromRawFilePath f
+	serialize (AssociatedFile Nothing) = ""
+	deserialize "" = Just (AssociatedFile Nothing)
+	deserialize f = Just (AssociatedFile (Just (toRawFilePath f)))
+
+instance TCSerialized RemoteName where
+	serialize n = n
+	deserialize n = Just n
+
+instance TCSerialized Key where
+	serialize = serializeKey
+	deserialize = deserializeKey
diff --git a/Command/Transferrer.hs b/Command/Transferrer.hs
new file mode 100644
index 0000000000..f48567eb00
--- /dev/null
+++ b/Command/Transferrer.hs
@@ -0,0 +1,139 @@
+{- git-annex command
+ -
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Transferrer where
+
+import Command
+import qualified Annex
+import Annex.Content
+import Logs.Location
+import Annex.Transfer
+import qualified Remote
+import Utility.SimpleProtocol (dupIoHandles)
+import qualified Database.Keys
+import Annex.BranchState
+import Types.Messages
+import Annex.TransferrerPool
+import Types.Transferrer
+import qualified Utility.SimpleProtocol as Proto
+
+cmd :: Command
+cmd = noCommit $ command "transferrer" SectionPlumbing "transfers content"
+	paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = do
+	enableInteractiveBranchAccess
+	(readh, writeh) <- liftIO dupIoHandles
+	let outputwriter = sendTransferResponse writeh . TransferOutput
+	let outputresponsereader = do
+		l <- getNextLine readh
+		return $ case Proto.parseMessage l of
+			Just (TransferSerializedOutputResponse r) -> Just r
+			Nothing -> Nothing
+	Annex.setOutput $ SerializedOutput outputwriter outputresponsereader
+	runRequests readh writeh runner
+	stop
+  where
+	runner (UploadRequest _ key (TransferAssociatedFile file)) remote =
+		-- This is called by eg, Annex.Transfer.upload,
+		-- so caller is responsible for doing notification,
+		-- and for retrying, and updating location log,
+		-- and stall canceling.
+		upload' (Remote.uuid remote) key file Nothing noRetry
+			(Remote.action . Remote.storeKey remote key file)
+			noNotification
+	runner (DownloadRequest _ key (TransferAssociatedFile file)) remote =
+		-- This is called by eg, Annex.Transfer.download
+		-- so caller is responsible for doing notification
+		-- and for retrying, and updating location log,
+		-- and stall canceling.
+		let go p = getViaTmp (Remote.retrievalSecurityPolicy remote) (RemoteVerify remote) key file Nothing $ \t -> do
+			Remote.verifiedAction (Remote.retrieveKeyFile remote key file (fromRawFilePath t) p (RemoteVerify remote))
+		in download' (Remote.uuid remote) key file Nothing noRetry go 
+			noNotification
+	runner (AssistantUploadRequest _ key (TransferAssociatedFile file)) remote =
+		notifyTransfer Upload file $
+			upload' (Remote.uuid remote) key file Nothing stdRetry $ \p -> do
+				tryNonAsync (Remote.storeKey remote key file p) >>= \case
+					Left e -> do
+						warning (UnquotedString (show e))
+						return False
+					Right () -> do
+						Remote.logStatus remote key InfoPresent
+						return True
+	runner (AssistantDownloadRequest _ key (TransferAssociatedFile file)) remote =
+		notifyTransfer Download file $
+			download' (Remote.uuid remote) key file Nothing stdRetry $ \p ->
+				logStatusAfter key $ getViaTmp (Remote.retrievalSecurityPolicy remote) (RemoteVerify remote) key file Nothing $ \t -> do
+					r <- tryNonAsync (Remote.retrieveKeyFile remote key file (fromRawFilePath t) p (RemoteVerify remote)) >>= \case
+						Left e -> do
+							warning (UnquotedString (show e))
+							return (False, UnVerified)
+						Right v -> return (True, v)
+					-- Make sure we get the current
+					-- associated files data for the key,
+					-- not old cached data.
+					Database.Keys.closeDb			
+					return r
+
+runRequests
+	:: Handle
+	-> Handle
+	-> (TransferRequest -> Remote -> Annex Bool)
+	-> Annex ()
+runRequests readh writeh a = go Nothing Nothing
+  where
+	go lastremoteoruuid lastremote = unlessM (liftIO $ hIsEOF readh) $ do
+		l <- liftIO $ getNextLine readh
+		case Proto.parseMessage l of
+			Just tr -> do
+				let remoteoruuid = transferRequestRemote tr
+				-- Often the same remote will be used
+				-- repeatedly, so cache the last one to
+				-- avoid looking up repeatedly.
+				mremote <- if lastremoteoruuid == Just remoteoruuid
+					then pure lastremote
+					else case remoteoruuid of
+						TransferRemoteName n ->
+							eitherToMaybe <$> Remote.byName' n
+						TransferRemoteUUID u -> 
+							Remote.byUUID u
+				case mremote of
+					Just remote -> do
+						sendresult =<< a tr remote
+						go (Just remoteoruuid) mremote
+					Nothing -> transferrerProtocolError l
+			Nothing -> transferrerProtocolError l
+
+	sendresult = liftIO . sendTransferResponse writeh . TransferResult
+
+sendTransferResponse :: Handle -> TransferResponse -> IO ()
+sendTransferResponse h r = silenceIOErrors $ do
+	hPutStrLn h $ unwords $ Proto.formatMessage r
+	hFlush h
+
+getNextLine :: Handle -> IO String
+getNextLine = silenceIOErrors . hGetLine
+
+{- If the pipe we're talking to gets closed due to the parent git-annex
+ - having exited, read/write would throw an exception due to sigpipe,
+ - which gets displayed on the console in an ugly way. This silences that
+ - display, and exits on exception instead.
+ -
+ - Normally signals like SIGINT get propagated to this process
+ - from the parent process. However, since this process is run in its own
+ - process group, that propagation requires the parent to actively
+ - propagate the signal. One way that could not happen is if the parent
+ - gets a signal it cannot catch. Another way is if the parent is hit by
+ - the signal before it can set up the signal propagation.
+ -}
+silenceIOErrors :: IO a -> IO a
+silenceIOErrors a = catchIO a (const exitFailure)
diff --git a/Command/Trust.hs b/Command/Trust.hs
new file mode 100644
index 0000000000..c113c60bf1
--- /dev/null
+++ b/Command/Trust.hs
@@ -0,0 +1,54 @@
+{- git-annex command
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Trust where
+
+import Command
+import qualified Remote
+import qualified Annex
+import Types.TrustLevel
+import Logs.Trust
+import Logs.Group
+
+import qualified Data.Set as S
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "trust" SectionSetup "trust a repository"
+		(paramRepeating paramRepository) (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = trustCommand "trust" Trusted
+
+trustCommand :: String -> TrustLevel -> CmdParams -> CommandSeek
+trustCommand _ _ [] = giveup "no repository name specified"
+trustCommand c level ps = withStrings (commandAction . start) ps
+  where
+	start name = do
+		u <- Remote.nameToUUID name
+		let si = SeekInput [name]
+		starting c (ActionItemUUID u (UnquotedString name)) si (perform name u)
+	perform name uuid = do
+		when (level >= Trusted) $
+			unlessM (Annex.getRead Annex.force) $
+				giveup $ trustedNeedsForce name
+		trustSet uuid level
+		when (level == DeadTrusted) $
+			groupSet uuid S.empty
+		l <- lookupTrust uuid
+		when (l /= level) $
+			warning $ UnquotedString $ "This remote's trust level is overridden to " ++ showTrustLevel l ++ "."
+		next $ return True
+
+trustedNeedsForce :: String -> String
+trustedNeedsForce name = unwords
+	[ "Trusting a repository can lead to data loss."
+	, "If you're sure you know what you're doing, use --force to"
+	, "make this take effect."
+	, "If you choose to do so, bear in mind that any time you drop"
+	, "content from " ++ name ++ ", you will risk losing data."
+	]
diff --git a/Command/Unannex.hs b/Command/Unannex.hs
new file mode 100644
index 0000000000..8eeae06d28
--- /dev/null
+++ b/Command/Unannex.hs
@@ -0,0 +1,103 @@
+{- git-annex command
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Unannex where
+
+import Command
+import qualified Annex
+import Annex.Perms
+import Annex.Link
+import qualified Annex.Queue
+import Utility.CopyFile
+import qualified Database.Keys
+import Utility.InodeCache
+import Annex.InodeSentinal
+import Git.FilePath
+import qualified Utility.RawFilePath as R
+
+import System.PosixCompat.Files (linkCount)
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions, annexedMatchingOptions] $
+	command "unannex" SectionUtility
+		"undo accidental add command"
+		paramPaths (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek ps = withFilesInGitAnnex ww (seeker False) =<< workTreeItems ww ps
+  where
+	ww = WarnUnmatchLsFiles "unannex"
+
+seeker :: Bool -> AnnexedFileSeeker
+seeker fast = AnnexedFileSeeker
+	{ startAction = const $ start fast
+	, checkContentPresent = Just True
+	, usesLocationLog = False
+	}
+
+start :: Bool -> SeekInput -> RawFilePath -> Key -> CommandStart
+start fast si file key = 
+	starting "unannex" (mkActionItem (key, file)) si $
+		perform fast file key
+
+perform :: Bool -> RawFilePath -> Key -> CommandPerform
+perform fast file key = do
+	Annex.Queue.addCommand [] "rm"
+		[ Param "--cached"
+		, Param "--force"
+		, Param "--quiet"
+		, Param "--"
+		]
+		[fromRawFilePath file]
+	isAnnexLink file >>= \case
+		-- If the file is locked, it needs to be replaced with
+		-- the content from the annex. Note that it's possible
+		-- for key' (read from the symlink) to differ from key
+		-- (cached in git).
+		Just key' -> do
+			cleanupdb
+			next $ cleanup fast file key'
+		-- If the file is unlocked, it can be unmodified or not and
+		-- does not need to be replaced either way.
+		Nothing -> do
+			cleanupdb
+			next $ return True
+  where
+	cleanupdb = do
+		Database.Keys.removeAssociatedFile key
+			=<< inRepo (toTopFilePath file)
+		maybe noop Database.Keys.removeInodeCache
+			=<< withTSDelta (liftIO . genInodeCache file)
+
+cleanup :: Bool -> RawFilePath -> Key -> CommandCleanup
+cleanup fast file key = do
+	liftIO $ removeFile (fromRawFilePath file)
+	src <- calcRepo (gitAnnexLocation key)
+	ifM (pure fast <||> Annex.getRead Annex.fast)
+		( do
+			-- Only make a hard link if the annexed file does not
+			-- already have other hard links pointing at it. This
+			-- avoids unannexing (and uninit) ending up hard
+			-- linking files together, which would be surprising.
+			s <- liftIO $ R.getFileStatus src
+			if linkCount s > 1
+				then copyfrom src
+				else hardlinkfrom src
+		, copyfrom src
+		)
+  where
+	copyfrom src = 
+		thawContent file `after` liftIO 
+			(copyFileExternal CopyAllMetaData
+				(fromRawFilePath src)
+				(fromRawFilePath file))
+	hardlinkfrom src =
+		-- creating a hard link could fall; fall back to copying
+		ifM (liftIO $ catchBoolIO $ R.createLink src file >> return True)
+			( return True
+			, copyfrom src
+			)
diff --git a/Command/Undo.hs b/Command/Undo.hs
new file mode 100644
index 0000000000..000cc1c313
--- /dev/null
+++ b/Command/Undo.hs
@@ -0,0 +1,90 @@
+{- git-annex command
+ -
+ - Copyright 2014-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.Undo where
+
+import Command
+import Git.DiffTree
+import Git.FilePath
+import Git.UpdateIndex
+import Git.Sha
+import qualified Annex
+import qualified Git.LsFiles as LsFiles
+import qualified Git.Command as Git
+import qualified Git.Branch
+import qualified Utility.RawFilePath as R
+
+cmd :: Command
+cmd = notBareRepo $ withAnnexOptions [jsonOptions] $
+	command "undo" SectionCommon 
+		"undo last change to a file or directory"
+		paramPaths (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek ps = do
+	-- Safety first; avoid any undo that would touch files that are not
+	-- in the index.
+	(fs, cleanup) <- inRepo $ LsFiles.notInRepo [] False (map toRawFilePath ps)
+	unless (null fs) $ do
+		qp <- coreQuotePath <$> Annex.getGitConfig
+		giveup $ decodeBS $ quote qp $ 
+			"Cannot undo changes to files that are not checked into git: "
+				<> quotedPaths fs
+	void $ liftIO $ cleanup
+
+	-- Committing staged changes before undo allows later
+	-- undoing the undo. It would be nicer to only commit staged
+	-- changes to the specified files, rather than all staged changes.
+	void $ commitStaged Git.Branch.ManualCommit
+		"commit before undo"
+	
+	withStrings (commandAction . start) ps
+
+start :: FilePath -> CommandStart
+start p = starting "undo" ai si $
+	perform p
+  where
+	ai = ActionItemOther (Just (QuotedPath (toRawFilePath p)))
+	si = SeekInput [p]
+
+perform :: FilePath -> CommandPerform
+perform p = do
+	g <- gitRepo
+
+	-- Get the reversed diff that needs to be applied to undo.
+	(diff, cleanup) <- inRepo $
+		diffLog [Param "-R", Param "--", Param p]
+	top <- inRepo $ toTopFilePath $ toRawFilePath p
+	let diff' = filter (`isDiffOf` top) diff
+	liftIO $ streamUpdateIndex g (map stageDiffTreeItem diff')
+
+	-- Take two passes through the diff, first doing any removals,
+	-- and then any adds. This order is necessary to handle eg, removing
+	-- a directory and replacing it with a file.
+	let (removals, adds) = partition (\di -> dstsha di `elem` nullShas) diff'
+	let mkrel di = liftIO $ relPathCwdToFile $
+		fromTopFilePath (file di) g
+
+	forM_ removals $ \di -> do
+		f <- mkrel di
+		liftIO $ removeWhenExistsWith R.removeLink f
+
+	forM_ adds $ \di -> do
+		f <- fromRawFilePath <$> mkrel di
+		inRepo $ Git.run [Param "checkout", Param "--", File f]
+
+	next $ liftIO cleanup
+
+commitStaged :: Git.Branch.CommitMode -> String -> Annex Bool
+commitStaged commitmode commitmessage =
+	inRepo $ Git.Branch.commitCommand commitmode
+		(Git.Branch.CommitQuiet True)
+		[ Param "-m"
+		, Param commitmessage
+		]
diff --git a/Command/Ungroup.hs b/Command/Ungroup.hs
new file mode 100644
index 0000000000..e929b21199
--- /dev/null
+++ b/Command/Ungroup.hs
@@ -0,0 +1,35 @@
+{- git-annex command
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Ungroup where
+
+import Command
+import qualified Remote
+import Logs.Group
+import Types.Group
+
+import qualified Data.Set as S
+
+cmd :: Command
+cmd = command "ungroup" SectionSetup "remove a repository from a group"
+	(paramPair paramRemote paramDesc) (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start (name:g:[]) = do
+	u <- Remote.nameToUUID name
+	starting "ungroup" (ActionItemOther (Just (UnquotedString name))) 
+		(SeekInput [name, g]) $
+			perform u (toGroup g)
+start _ = giveup "Specify a repository and a group."
+
+perform :: UUID -> Group -> CommandPerform
+perform uuid g = do
+	groupChange uuid (S.delete g) 
+	next $ return True
diff --git a/Command/Uninit.hs b/Command/Uninit.hs
new file mode 100644
index 0000000000..1b2e8395a8
--- /dev/null
+++ b/Command/Uninit.hs
@@ -0,0 +1,177 @@
+{- git-annex command
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Uninit where
+
+import Command
+import qualified Git
+import qualified Git.Command
+import qualified Git.Ref
+import qualified Git.Branch
+import qualified Command.Unannex
+import qualified Annex.Branch
+import qualified Annex.Queue
+import qualified Database.Keys
+import Annex.Content
+import Annex.Init
+import Annex.CheckIgnore
+import Annex.WorkTree
+import Utility.FileMode
+import qualified Utility.RawFilePath as R
+
+import System.PosixCompat.Files (linkCount)
+import Control.Concurrent.STM
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "uninit" SectionUtility
+		"de-initialize git-annex and clean out repository"
+		paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing $ do
+	ok <- liftIO $ newTVarIO False
+	let checkok v a = do
+		liftIO $ atomically $ writeTVar ok v
+		() <- a	
+		liftIO $ atomically $ readTVar ok
+	let recordok = do
+		liftIO $ atomically $ writeTVar ok True
+		return True
+	let recordnotok = liftIO $ atomically $ writeTVar ok False
+
+	whenM (checkok False $ commandAction $ checkCanUninit recordok) $ do
+		let symlinksok = checkok True $ withFilesNotInGit
+			(CheckGitIgnore False)
+			(WarnUnmatchWorkTreeItems "uninit")
+			(checksymlinks recordnotok)
+			=<< workTreeItems ww []
+		whenM symlinksok $ do
+			withFilesInGitAnnex ww (Command.Unannex.seeker True)
+				=<< workTreeItems ww []
+			whenM (checkok False $ commandAction $ removeAnnexDir recordok) $ 
+				commandAction completeUnitialize
+  where
+	ww = WarnUnmatchLsFiles "uninit"
+	checksymlinks recordnotok (_, f) = 
+		commandAction $ lookupKey f >>= \case
+			Nothing -> stop
+			Just k -> startCheckIncomplete recordnotok f k
+
+checkCanUninit :: CommandCleanup -> CommandStart
+checkCanUninit recordok = 
+	starting "uninit check" (ActionItemOther Nothing) (SeekInput []) $ do
+		runchecks
+		next recordok
+  where
+	runchecks = do
+		b <- current_branch
+		when (b == Just Annex.Branch.name) $ giveup $
+			"cannot uninit when the " ++ Git.fromRef Annex.Branch.name ++ " branch is checked out"
+		top <- fromRepo Git.repoPath
+		currdir <- liftIO R.getCurrentDirectory
+		whenM ((/=) <$> liftIO (absPath top) <*> liftIO (absPath currdir)) $
+			giveup "can only run uninit from the top of the git repository"
+	
+	current_branch = 
+		ifM (inRepo Git.Ref.headExists)
+			( Just . Git.Ref . encodeBS . Prelude.head . lines . decodeBS <$> revhead
+			, return Nothing
+			)
+	revhead = inRepo $ Git.Command.pipeReadStrict
+		[Param "rev-parse", Param "--abbrev-ref", Param "HEAD"]
+
+{- git annex symlinks that are not checked into git could be left by an
+ - interrupted add. -}
+startCheckIncomplete :: Annex () -> RawFilePath -> Key -> CommandStart
+startCheckIncomplete recordnotok file key =
+	starting "uninit check" (mkActionItem (file, key)) (SeekInput []) $ do
+		recordnotok
+		giveup $ unlines err
+  where
+	err =
+		[ fromRawFilePath file ++ " points to annexed content, but is not checked into git."
+		, "Perhaps this was left behind by an interrupted git annex add?"
+		, "Not continuing with uninit; either delete or git annex add the file and retry."
+		]
+
+removeAnnexDir :: CommandCleanup -> CommandStart
+removeAnnexDir recordok = do
+	Annex.Queue.flush
+	annexdir <- fromRawFilePath <$> fromRepo gitAnnexDir
+	annexobjectdir <- fromRepo gitAnnexObjectDir
+	starting ("uninit objects") (ActionItemOther Nothing) (SeekInput []) $ do
+		leftovers <- removeUnannexed =<< listKeys InAnnex
+		prepareRemoveAnnexDir annexdir
+		if null leftovers
+			then do
+				liftIO $ removeDirectoryRecursive annexdir
+				next recordok
+			else giveup $ unlines
+				[ "Not fully uninitialized"
+				, "Some annexed data is still left in " ++ fromRawFilePath annexobjectdir
+				, "This may include deleted files, or old versions of modified files."
+				, ""
+				, "If you don't care about preserving the data, just delete the"
+				, "directory."
+				, ""
+				, "Or, you can move it to another location, in case it turns out"
+				, "something in there is important."
+				, ""
+				, "Or, you can run `git annex unused` followed by `git annex dropunused`"
+				, "to remove data that is not used by any tag or branch, which might"
+				, "take care of all the data."
+				, ""
+				, "Then run `git annex uninit` again to finish."
+				]
+
+{- Turn on write bits in all remaining files in the annex directory, in
+ - preparation for removal. 
+ -
+ - Also closes sqlite databases that might be in the directory,
+ - to avoid later failure to write any cached changes to them. -}
+prepareRemoveAnnexDir :: FilePath -> Annex ()
+prepareRemoveAnnexDir annexdir = do
+	Database.Keys.closeDb
+	liftIO $ prepareRemoveAnnexDir' annexdir
+
+prepareRemoveAnnexDir' :: FilePath -> IO ()
+prepareRemoveAnnexDir' annexdir =
+	emptyWhenDoesNotExist (dirTreeRecursiveSkipping (const False) annexdir)
+		>>= mapM_ (void . tryIO . allowWrite . toRawFilePath)
+
+{- Keys that were moved out of the annex have a hard link still in the
+ - annex, with > 1 link count, and those can be removed.
+ -
+ - Returns keys that cannot be removed. -}
+removeUnannexed :: [Key] -> Annex [Key]
+removeUnannexed = go []
+  where
+	go c [] = return c
+	go c (k:ks) = ifM (inAnnexCheck k $ liftIO . enoughlinks)
+		( do
+			lockContentForRemoval k noop removeAnnex
+			go c ks
+		, go (k:c) ks
+		)
+	enoughlinks f = catchBoolIO $ do
+		s <- R.getFileStatus f
+		return $ linkCount s > 1
+
+completeUnitialize :: CommandStart
+completeUnitialize =
+	starting ("uninit finish") (ActionItemOther Nothing) (SeekInput []) $ do
+		uninitialize
+		removeAnnexBranch
+		next $ return True
+
+removeAnnexBranch :: Annex ()
+removeAnnexBranch = do
+	-- avoid normal shutdown commit to the branch
+	saveState False
+	whenM (inRepo $ Git.Ref.exists Annex.Branch.fullname) $
+		inRepo $ Git.Branch.delete Annex.Branch.name
diff --git a/Command/Unlock.hs b/Command/Unlock.hs
new file mode 100644
index 0000000000..c8faa7532f
--- /dev/null
+++ b/Command/Unlock.hs
@@ -0,0 +1,72 @@
+{- git-annex command
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Unlock where
+
+import Command
+import Annex.Content
+import Annex.Perms
+import Annex.Link
+import Annex.ReplaceFile
+import Annex.InodeSentinal
+import Utility.InodeCache
+import Git.FilePath
+import qualified Database.Keys
+import qualified Utility.RawFilePath as R
+
+import System.PosixCompat.Files (fileMode)
+
+cmd :: Command
+cmd = mkcmd "unlock" "unlock files for modification"
+
+editcmd :: Command
+editcmd = mkcmd "edit" "same as unlock"
+
+mkcmd :: String -> String -> Command
+mkcmd n d = withAnnexOptions [jsonOptions, annexedMatchingOptions] $
+	command n SectionCommon d paramPaths (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek ps = withFilesInGitAnnex ww seeker =<< workTreeItems ww ps
+  where
+	ww = WarnUnmatchLsFiles "unlock"
+	seeker = AnnexedFileSeeker
+		{ startAction = const start
+		, checkContentPresent = Nothing
+		, usesLocationLog = False
+		}
+
+start :: SeekInput -> RawFilePath -> Key -> CommandStart
+start si file key = ifM (isJust <$> isAnnexLink file)
+	( starting "unlock" ai si $ perform file key
+	, stop
+	)
+  where
+	ai = mkActionItem (key, AssociatedFile (Just file))
+
+perform :: RawFilePath -> Key -> CommandPerform
+perform dest key = do
+	destmode <- liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus dest
+	destic <- replaceWorkTreeFile (fromRawFilePath dest) $ \tmp -> do
+		ifM (inAnnex key)
+			( do
+				r <- linkFromAnnex' key tmp destmode
+				case r of
+					LinkAnnexOk -> return ()
+					LinkAnnexNoop -> return ()
+					LinkAnnexFailed -> giveup "unlock failed"
+			, liftIO $ writePointerFile tmp key destmode
+			)
+		withTSDelta (liftIO . genInodeCache tmp)
+	next $ cleanup dest destic key destmode
+
+cleanup :: RawFilePath -> Maybe InodeCache -> Key -> Maybe FileMode -> CommandCleanup
+cleanup dest destic key destmode = do
+	stagePointerFile dest destmode =<< hashPointerFile key
+	maybe noop (restagePointerFile (Restage True) dest) destic
+	Database.Keys.addAssociatedFile key =<< inRepo (toTopFilePath dest)
+	return True
diff --git a/Command/UnregisterUrl.hs b/Command/UnregisterUrl.hs
new file mode 100644
index 0000000000..e8bf16c933
--- /dev/null
+++ b/Command/UnregisterUrl.hs
@@ -0,0 +1,38 @@
+{- git-annex command
+ -
+ - Copyright 2015-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Command.UnregisterUrl where
+
+import Command
+import Logs.Web
+import Command.RegisterUrl (seekBatch, start, optParser, RegisterUrlOptions(..))
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $ command "unregisterurl"
+	SectionPlumbing "unregisters an url for a key"
+	(paramPair paramKey paramUrl)
+	(seek <$$> optParser)
+
+seek :: RegisterUrlOptions -> CommandSeek
+seek o = case (batchOption o, keyUrlPairs o) of
+	(Batch fmt, _) -> seekBatch unregisterUrl o fmt
+	(NoBatch, ps) -> commandAction (start unregisterUrl o ps)
+
+unregisterUrl :: Remote -> Key -> String -> Annex ()
+unregisterUrl _remote key url = do
+	-- Remove the url no matter what downloader;
+	-- registerurl can set OtherDownloader, and this should also
+	-- be able to remove urls added by addurl, which may use
+	-- YoutubeDownloader.
+	forM_ [minBound..maxBound] $ \dl ->
+		setUrlMissing key (setDownloader url dl)
+	-- Unlike unregisterurl, this does not update location tracking
+	-- for remotes other than the web special remote. Doing so with
+	-- a remote that git-annex can drop content from would rather
+	-- unexpectedly leave content stranded on that remote.
diff --git a/Command/Untrust.hs b/Command/Untrust.hs
new file mode 100644
index 0000000000..ccefbbfdfa
--- /dev/null
+++ b/Command/Untrust.hs
@@ -0,0 +1,20 @@
+{- git-annex command
+ -
+ - Copyright 2010 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Untrust where
+
+import Command
+import Types.TrustLevel
+import Command.Trust (trustCommand)
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "untrust" SectionSetup "do not trust a repository"
+		(paramRepeating paramRepository) (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = trustCommand "untrust" UnTrusted
diff --git a/Command/Unused.hs b/Command/Unused.hs
new file mode 100644
index 0000000000..eebe24ca36
--- /dev/null
+++ b/Command/Unused.hs
@@ -0,0 +1,345 @@
+{- git-annex command
+ -
+ - Copyright 2010-2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns, OverloadedStrings #-}
+
+module Command.Unused where
+
+import Command
+import Logs.Unused
+import Annex.Content
+import Logs.Location
+import qualified Annex
+import qualified Git
+import qualified Git.Command
+import qualified Git.Ref
+import qualified Git.Branch
+import qualified Git.RefLog
+import qualified Git.LsFiles as LsFiles
+import qualified Git.DiffTree as DiffTree
+import qualified Remote
+import qualified Annex.Branch
+import Annex.CatFile
+import Annex.WorkTree
+import Types.RefSpec
+import Git.Types
+import Git.Sha
+import Git.FilePath
+import Config
+import Logs.View (is_branchView)
+import Annex.BloomFilter
+import qualified Database.Keys
+import Annex.InodeSentinal
+
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.Text as T
+import Data.Char
+
+cmd :: Command
+cmd = withAnnexOptions [jsonOptions] $
+	command "unused" SectionMaintenance "look for unused file content"
+		paramNothing (seek <$$> optParser)
+
+data UnusedOptions = UnusedOptions
+	{ fromRemote :: Maybe RemoteName
+	, refSpecOption :: Maybe RefSpec
+	}
+
+optParser :: CmdParamsDesc -> Parser UnusedOptions
+optParser _ = UnusedOptions
+	<$> optional (strOption
+		( long "from" <> short 'f' <> metavar paramRemote
+		<> help "remote to check for unused content"
+		))
+	<*> optional (option (eitherReader parseRefSpec)
+		( long "used-refspec" <> metavar paramRefSpec
+		<> help "refs to consider used (default: all branches)"
+		))
+
+seek :: UnusedOptions -> CommandSeek
+seek = commandAction . start
+
+start :: UnusedOptions -> CommandStart
+start o = do
+	cfgrefspec <- fromMaybe allRefSpec . annexUsedRefSpec
+		<$> Annex.getGitConfig
+	let refspec = fromMaybe cfgrefspec (refSpecOption o)
+	let (name, perform) = case fromRemote o of
+		Nothing -> (".", checkUnused refspec)
+		Just "." -> (".", checkUnused refspec)
+		Just "here" -> (".", checkUnused refspec)
+		Just n -> (n, checkRemoteUnused n refspec)
+	starting "unused" (ActionItemOther (Just (UnquotedString name))) (SeekInput []) perform
+
+checkUnused :: RefSpec -> CommandPerform
+checkUnused refspec = chain 0
+	[ check "" unusedMsg $ findunused =<< Annex.getRead Annex.fast
+	, check "bad" staleBadMsg $ staleKeysPrune gitAnnexBadDir False
+	, check "tmp" staleTmpMsg $ staleKeysPrune gitAnnexTmpObjectDir True
+	]
+  where
+	findunused True = do
+		showNote "fast mode enabled; only finding stale files"
+		return []
+	findunused False = do
+		showAction "checking for unused data"
+		excludeReferenced refspec =<< listKeys InAnnex
+	chain _ [] = next $ return True
+	chain v (a:as) = do
+		v' <- a v
+		chain v' as
+
+checkRemoteUnused :: RemoteName -> RefSpec -> CommandPerform
+checkRemoteUnused remotename refspec = go =<< Remote.nameToUUID remotename
+  where
+	go u = do
+		showAction "checking for unused data"
+		r <- Remote.byUUID u
+		_ <- check "" (remoteUnusedMsg r remotename) (remoteunused u) 0
+		next $ return True
+	remoteunused u = loggedKeysFor u >>= \case
+		Just ks -> excludeReferenced refspec ks
+		Nothing -> giveup "This repository is read-only."
+
+check :: String -> ([(Int, Key)] -> String) -> Annex [Key] -> Int -> Annex Int
+check fileprefix msg a c = do
+	l <- a
+	let unusedlist = number c l
+	unless (null l) $
+		showLongNote $ UnquotedString $ msg unusedlist
+	maybeAddJSONField
+		((if null fileprefix then "unused" else fileprefix) ++ "-list")
+		(M.fromList $ map (\(n,  k) -> (T.pack (show n), serializeKey k)) unusedlist)
+	updateUnusedLog (toRawFilePath fileprefix) (M.fromList unusedlist)
+	return $ c + length l
+
+number :: Int -> [a] -> [(Int, a)]
+number _ [] = []
+number n (x:xs) = (n+1, x) : number (n+1) xs
+
+table :: [(Int, Key)] -> [String]
+table l = "  NUMBER  KEY" : map cols l
+  where
+	cols (n,k) = "  " ++ pad 6 (show n) ++ "  " ++ serializeKey k
+	pad n s = s ++ replicate (n - length s) ' '
+
+staleTmpMsg :: [(Int, Key)] -> String
+staleTmpMsg t = unlines $ 
+	["Some partially transferred data exists in temporary files:"]
+	++ table t ++ [dropMsg Nothing]
+
+staleBadMsg :: [(Int, Key)] -> String
+staleBadMsg t = unlines $ 
+	["Some corrupted files have been preserved by fsck, just in case:"]
+	++ table t ++ [dropMsg Nothing]
+
+unusedMsg :: [(Int, Key)] -> String
+unusedMsg u = unusedMsg' u
+	["Some annexed data is no longer used by any files:"]
+	[dropMsg Nothing]
+unusedMsg' :: [(Int, Key)] -> [String] -> [String] -> String
+unusedMsg' u mheader mtrailer = unlines $
+	mheader ++
+	table u ++
+	["(To see where this data was previously used, run: git annex whereused --historical --unused"] ++
+	mtrailer
+
+remoteUnusedMsg :: Maybe Remote -> RemoteName -> [(Int, Key)] -> String
+remoteUnusedMsg mr remotename u = unusedMsg' u
+	["Some annexed data on " ++ remotename ++ " is not used by any files:"]
+	(if isJust mr then [dropMsg (Just remotename)] else [])
+
+dropMsg :: Maybe RemoteName -> String
+dropMsg Nothing = dropMsg' ""
+dropMsg (Just remotename) = dropMsg' $ " --from " ++ remotename
+dropMsg' :: String -> String
+dropMsg' s = "\nTo remove unwanted data: git-annex dropunused" ++ s ++ " NUMBER\n"
+
+{- Finds keys in the list that are not referenced in the git repository.
+ -
+ - Strategy:
+ -
+ - Pass keys through these filters in order, only creating each bloom
+ - filter on demand if the previous one didn't filter out all keys.
+ -
+ - 1. Bloom filter containing all keys referenced by files in the work tree.
+ -    This is the fastest one to build and will filter out most keys.
+ - 2. Bloom filter containing all keys in the diff from the work tree to
+ -    the index.
+ - 3. Associated files filter. An unlocked file may have had its content
+ -    added to the annex (by eg, git diff running the smudge filter),
+ -    but the new key is not yet staged in the index. But if so, it will 
+ -    have an associated file.
+ - 4. Bloom filter containing all keys in the diffs between the index and
+ -    branches matching the RefSpec. (This can take quite a while to build).
+ -}
+excludeReferenced :: RefSpec -> [Key] -> Annex [Key]
+excludeReferenced refspec ks = runbloomfilter withKeysReferencedM ks
+	>>= runbloomfilter withKeysReferencedDiffIndex
+	>>= runfilter associatedFilesFilter
+	>>= runbloomfilter (withKeysReferencedDiffGitRefs refspec)
+  where
+	runfilter _ [] = return [] -- optimisation
+	runfilter a l = a l
+	runbloomfilter a = runfilter $ \l -> bloomFilter l <$> genBloomFilter a
+
+{- Given an initial value, accumulates the value over each key
+ - referenced by files in the working tree. -}
+withKeysReferenced :: v -> (Key -> RawFilePath -> v -> Annex v) -> Annex v
+withKeysReferenced initial = withKeysReferenced' Nothing initial
+
+{- Runs an action on each referenced key in the working tree. -}
+withKeysReferencedM :: (Key -> Annex ()) -> Annex ()
+withKeysReferencedM a = withKeysReferenced' Nothing () calla
+  where
+	calla k _ _ = a k
+
+{- Folds an action over keys and files referenced in a particular directory. -}
+withKeysFilesReferencedIn :: FilePath -> v -> (Key -> RawFilePath -> v -> Annex v) -> Annex v
+withKeysFilesReferencedIn = withKeysReferenced' . Just
+
+withKeysReferenced' :: Maybe FilePath -> v -> (Key -> RawFilePath -> v -> Annex v) -> Annex v
+withKeysReferenced' mdir initial a = do
+	(files, clean) <- getfiles
+	r <- go initial files
+	liftIO $ void clean
+	return r
+  where
+	getfiles = case mdir of
+		Nothing -> ifM isBareRepo
+			( return ([], return True)
+			, do
+				top <- fromRepo Git.repoPath
+				inRepo $ LsFiles.allFiles [] [top]
+			)
+		Just dir -> inRepo $ LsFiles.inRepo [] [toRawFilePath dir]
+	go v [] = return v
+	go v (f:fs) = do
+		mk <- lookupKey f
+		case mk of
+			Nothing -> go v fs
+			Just k -> do
+				!v' <- a k f v
+				go v' fs
+
+withKeysReferencedDiffGitRefs :: RefSpec -> (Key -> Annex ()) -> Annex ()
+withKeysReferencedDiffGitRefs refspec a = do
+	rs <- relevantrefs <$> inRepo (Git.Command.pipeReadStrict [Param "show-ref"])
+	shaHead <- maybe (return Nothing) (inRepo . Git.Ref.sha)
+		=<< inRepo Git.Branch.currentUnsafe
+	let haveHead = any (\(shaRef, _) -> Just shaRef == shaHead) rs
+	let rs' = map snd (nubRefs rs)
+	usedrefs <- applyRefSpec refspec rs' (getreflog rs')
+	forM_ (if haveHead then usedrefs else Git.Ref.headRef : usedrefs) $
+		withKeysReferencedDiffGitRef a
+  where
+	relevantrefs = map (\(r, h) -> (Git.Ref r, Git.Ref h)) .
+		filter ourbranches .
+		map (separate' (== (fromIntegral (ord ' ')))) .
+		S8.lines
+	nubRefs = nubBy (\(x, _) (y, _) -> x == y)
+	ourbranchend = S.cons (fromIntegral (ord '/')) (Git.fromRef' Annex.Branch.name)
+	ourbranches (_, b) = not (ourbranchend `S.isSuffixOf` b)
+		&& not ("refs/synced/" `S.isPrefixOf` b)
+		&& not ("refs/annex/" `S.isPrefixOf` b)
+		&& not (is_branchView (Git.Ref b))
+	getreflog rs = inRepo $ Git.RefLog.getMulti rs
+
+{- Runs an action on keys referenced in the given Git reference which
+ - differ from those referenced in the index. -}
+withKeysReferencedDiffGitRef :: (Key -> Annex ()) -> Git.Ref -> Annex ()
+withKeysReferencedDiffGitRef a ref = do
+	showAction $ UnquotedString $ "checking " ++ Git.Ref.describe ref
+	withKeysReferencedDiff a
+		(inRepo $ DiffTree.diffIndex ref)
+		DiffTree.srcsha
+
+{- Runs an action on keys referenced in the index which differ from the
+ - work tree. -}
+withKeysReferencedDiffIndex :: (Key -> Annex ()) -> Annex ()
+withKeysReferencedDiffIndex a = unlessM (isBareRepo) $
+	withKeysReferencedDiff a
+		(inRepo $ DiffTree.diffFiles [])
+		DiffTree.srcsha
+
+withKeysReferencedDiff :: (Key -> Annex ()) -> (Annex ([DiffTree.DiffTreeItem], IO Bool)) -> (DiffTree.DiffTreeItem -> Sha) -> Annex ()
+withKeysReferencedDiff a getdiff extractsha = do
+	(ds, clean) <- getdiff
+	forM_ ds go
+	liftIO $ void clean
+  where
+  	go d = do
+		let sha = extractsha d
+		unless (sha `elem` nullShas) $
+			catKey sha >>= maybe noop a
+
+{- Filters out keys that have an associated file that's not modified. -}
+associatedFilesFilter :: [Key] -> Annex [Key]
+associatedFilesFilter = filterM go
+  where
+	go k = do
+		cs <- Database.Keys.getInodeCaches k
+		if null cs
+			then return True
+			else checkunmodified cs
+				=<< Database.Keys.getAssociatedFiles k
+	checkunmodified _ [] = return True
+	checkunmodified cs (f:fs) = do
+		relf <- fromRepo $ fromTopFilePath f
+		ifM (sameInodeCache relf cs)
+			( return False
+			, checkunmodified cs fs
+			)
+
+data UnusedMaps = UnusedMaps
+	{ unusedMap :: UnusedMap
+	, unusedBadMap :: UnusedMap
+	, unusedTmpMap :: UnusedMap
+	}
+
+withUnusedMaps :: (UnusedMaps -> Int -> CommandStart) -> CmdParams -> CommandSeek
+withUnusedMaps a params = do
+	unused <- readUnusedMap ""
+	unusedbad <- readUnusedMap "bad"
+	unusedtmp <- readUnusedMap "tmp"
+	let m = unused `M.union` unusedbad `M.union` unusedtmp
+	let unusedmaps = UnusedMaps unused unusedbad unusedtmp
+	commandActions $ map (a unusedmaps) $ concatMap (unusedSpec m) params
+
+unusedSpec :: UnusedMap -> String -> [Int]
+unusedSpec m spec
+	| spec == "all" = if M.null m
+		then []
+		else [fst (M.findMin m)..fst (M.findMax m)]
+	| "-" `isInfixOf` spec = range $ separate (== '-') spec
+	| otherwise = maybe badspec (: []) (readish spec)
+  where
+	range (a, b) = case (readish a, readish b) of
+		(Just x, Just y) -> [x..y]
+		_ -> badspec
+	badspec = giveup $ "Expected number or range, not \"" ++ spec ++ "\""
+
+{- Seek action for unused content. Finds the number in the maps, and
+ - calls one of 3 actions, depending on the type of unused file. -}
+startUnused
+	:: (Int -> Key -> CommandStart)
+	-> (Int -> Key -> CommandStart) 
+	-> (Int -> Key -> CommandStart)
+	-> UnusedMaps -> Int -> CommandStart
+startUnused unused badunused tmpunused maps n = search
+	[ (unusedMap maps, unused)
+	, (unusedBadMap maps, badunused)
+	, (unusedTmpMap maps, tmpunused)
+	]
+  where
+	search [] = giveup $ show n ++ " not valid (run git annex unused for list)"
+	search ((m, a):rest) =
+		case M.lookup n m of
+			Nothing -> search rest
+			Just key -> a n key
diff --git a/Command/Upgrade.hs b/Command/Upgrade.hs
new file mode 100644
index 0000000000..31600fabec
--- /dev/null
+++ b/Command/Upgrade.hs
@@ -0,0 +1,51 @@
+{- git-annex command
+ -
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Upgrade where
+
+import Command
+import Upgrade
+import Annex.Version
+import Annex.Init
+
+cmd :: Command
+cmd = dontCheck
+	-- because an old version may not seem to exist
+	-- and also, this avoids automatic silent upgrades before
+	-- this command can start up.
+	repoExists $
+	-- avoid upgrading repo out from under daemon
+	noDaemonRunning $
+	withAnnexOptions [jsonOptions] $
+	command "upgrade" SectionMaintenance "upgrade repository"
+		paramNothing (seek <$$> optParser)
+
+data UpgradeOptions = UpgradeOptions
+	{ autoOnly :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser UpgradeOptions
+optParser _ = UpgradeOptions
+	<$> switch
+		( long "autoonly"
+		<> help "only do automatic upgrades"
+		)
+
+seek :: UpgradeOptions -> CommandSeek
+seek o = commandAction (start o)
+
+start :: UpgradeOptions -> CommandStart
+start (UpgradeOptions { autoOnly = True }) =
+	starting "upgrade" (ActionItemOther Nothing) (SeekInput []) $ do
+		getVersion >>= maybe noop checkUpgrade
+		next $ return True
+start _ =
+	starting "upgrade" (ActionItemOther Nothing) (SeekInput []) $ do
+		whenM (isNothing <$> getVersion) $ do
+			initialize Nothing Nothing
+		r <- upgrade False latestVersion
+		next $ return r
diff --git a/Command/VAdd.hs b/Command/VAdd.hs
new file mode 100644
index 0000000000..8712f7d13c
--- /dev/null
+++ b/Command/VAdd.hs
@@ -0,0 +1,40 @@
+{- git-annex command
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.VAdd where
+
+import Command
+import qualified Annex
+import Annex.View
+import Command.View (checkoutViewBranch, paramView)
+
+cmd :: Command
+cmd = notBareRepo $
+	command "vadd" SectionMetaData 
+		"add subdirs to current view"
+		paramView (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start params = starting "vadd" (ActionItemOther Nothing) (SeekInput params) $ 
+	withCurrentView $ \view madj -> do
+		vu <- annexViewUnsetDirectory <$> Annex.getGitConfig
+		let (view', change) = refineView view $
+			map (parseViewParam vu) (reverse params)
+		case change of
+			Unchanged -> do
+				showNote "unchanged"
+				next $ return True
+			Narrowing -> next $ do
+				if visibleViewSize view' == visibleViewSize view
+					then giveup "That would not add an additional level of directory structure to the view. To filter the view, use vfilter instead of vadd."
+					else checkoutViewBranch view' madj narrowView
+			Widening -> giveup "Widening view to match more files is not currently supported."
diff --git a/Command/VCycle.hs b/Command/VCycle.hs
new file mode 100644
index 0000000000..b4d1c6df19
--- /dev/null
+++ b/Command/VCycle.hs
@@ -0,0 +1,42 @@
+{- git-annex command
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.VCycle where
+
+import Command
+import Annex.View
+import Types.View
+import Logs.View
+import Command.View (checkoutViewBranch)
+
+cmd :: Command
+cmd = notBareRepo $
+	command "vcycle" SectionMetaData
+		"switch view to next layout"
+		paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start ::CommandStart
+start = go =<< currentView
+  where
+	go Nothing = giveup "Not in a view."
+	go (Just (v, madj)) = starting "vcycle" (ActionItemOther Nothing) (SeekInput []) $ do
+		let v' = v { viewComponents = vcycle [] (viewComponents v) }
+		if v == v'
+			then do
+				showNote "unchanged"
+				next $ return True
+			else next $ checkoutViewBranch v' madj narrowView
+
+	vcycle rest (c:cs)
+		| viewVisible c = rest ++ cs ++ [c]
+		| otherwise = vcycle (c:rest) cs
+	vcycle rest c = rest ++ c
diff --git a/Command/VFilter.hs b/Command/VFilter.hs
new file mode 100644
index 0000000000..bc03cace2a
--- /dev/null
+++ b/Command/VFilter.hs
@@ -0,0 +1,31 @@
+{- git-annex command
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.VFilter where
+
+import Command
+import qualified Annex
+import Annex.View
+import Command.View (paramView, checkoutViewBranch)
+
+cmd :: Command
+cmd = notBareRepo $
+	command "vfilter" SectionMetaData "filter current view"
+		paramView (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start params = starting "vfilter" (ActionItemOther Nothing) (SeekInput params) $
+	withCurrentView $ \view madj -> do
+		vu <- annexViewUnsetDirectory <$> Annex.getGitConfig
+		let view' = filterView view $
+			map (parseViewParam vu) (reverse params)
+		next $ if visibleViewSize view' > visibleViewSize view
+			then giveup "That would add an additional level of directory structure to the view, rather than filtering it. If you want to do that, use vadd instead of vfilter."
+			else checkoutViewBranch view' madj narrowView
diff --git a/Command/VPop.hs b/Command/VPop.hs
new file mode 100644
index 0000000000..a5fac3ac37
--- /dev/null
+++ b/Command/VPop.hs
@@ -0,0 +1,53 @@
+{- git-annex command
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.VPop where
+
+import Command
+import qualified Git
+import qualified Git.Command
+import qualified Git.Ref
+import Types.View
+import Logs.View
+import Command.View (checkoutViewBranch)
+
+cmd :: Command
+cmd = notBareRepo $
+	command "vpop" SectionMetaData "switch back to previous view"
+		paramNumber (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start ps = go =<< currentView
+  where
+	go Nothing = giveup "Not in a view."
+	go (Just (v, madj)) = starting "vpop" ai si $ do
+		removeView v
+		(oldvs, vs) <- splitAt (num - 1) . filter (sameparentbranch v)
+			<$> recentViews
+		mapM_ removeView oldvs
+		case vs of
+			(oldv:_) -> next $ do
+				showOutput
+				checkoutViewBranch oldv madj
+					(\v' madj' -> return (branchView v' madj'))
+			_ -> next $ do
+				showOutput
+				inRepo $ Git.Command.runBool
+					[ Param "checkout"
+					, Param $ Git.fromRef $ Git.Ref.base $
+						viewParentBranch v
+					]
+	sameparentbranch a b = viewParentBranch a == viewParentBranch b
+
+	num = fromMaybe 1 $ readish =<< headMaybe ps 
+	
+	ai = ActionItemOther (Just $ UnquotedString $ show num)
+	
+	si = SeekInput ps
diff --git a/Command/Version.hs b/Command/Version.hs
new file mode 100644
index 0000000000..9252652d1e
--- /dev/null
+++ b/Command/Version.hs
@@ -0,0 +1,83 @@
+{- git-annex command
+ -
+ - Copyright 2010 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Version where
+
+import Command
+import Annex.Version
+import BuildInfo
+import BuildFlags
+import Types.Key
+import Types.RepoVersion
+import qualified Types.Backend as B
+import qualified Types.Remote as R
+import qualified Remote
+import qualified Backend
+
+import System.Info
+
+cmd :: Command
+cmd = dontCheck repoExists $ noCommit $ 
+	noRepo (seekNoRepo <$$> optParser) $ 
+		command "version" SectionQuery "show version info"
+			paramNothing (seek <$$> optParser)
+
+data VersionOptions = VersionOptions
+	{ rawOption :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser VersionOptions
+optParser _ = VersionOptions
+	<$> switch
+		( long "raw"
+		<> help "output only program version"
+		)
+
+seek :: VersionOptions -> CommandSeek
+seek o
+	| rawOption o = liftIO showRawVersion
+	| otherwise = showVersion
+
+seekNoRepo :: VersionOptions -> IO ()
+seekNoRepo o
+	| rawOption o = showRawVersion
+	| otherwise = showPackageVersion
+
+showVersion :: Annex ()
+showVersion = do
+	liftIO showPackageVersion
+	maybe noop (liftIO . vinfo "local repository version" . showRepoVersion)
+		=<< getVersion
+
+showPackageVersion :: IO ()
+showPackageVersion = do
+	vinfo "git-annex version" BuildInfo.packageversion
+	vinfo "build flags" $ unwords buildFlags
+	vinfo "dependency versions" $ unwords dependencyVersions
+	vinfo "key/value backends" $ unwords $
+		map (decodeBS . formatKeyVariety . B.backendVariety) Backend.builtinList
+		++ ["X*"]
+	vinfo "remote types" $ unwords $ map R.typename Remote.remoteTypes
+	vinfo "operating system" $ unwords [os, arch]
+	vinfo "supported repository versions" $
+		verlist supportedVersions
+	vinfo "upgrade supported from repository versions" $
+		verlist upgradeableVersions
+  where
+	verlist = unwords . map showRepoVersion
+
+showRepoVersion :: RepoVersion -> String
+showRepoVersion = show  . fromRepoVersion
+
+showRawVersion :: IO ()
+showRawVersion = do
+	putStr BuildInfo.packageversion
+	hFlush stdout -- no newline, so flush
+
+-- Ignore failure to write so that this command can eg be piped to head.
+vinfo :: String -> String -> IO ()
+vinfo k v = void $ tryIO $ putStrLn $ k ++ ": " ++ v
diff --git a/Command/Vicfg.hs b/Command/Vicfg.hs
new file mode 100644
index 0000000000..599d067fd9
--- /dev/null
+++ b/Command/Vicfg.hs
@@ -0,0 +1,348 @@
+{- git-annex command
+ -
+ - Copyright 2012-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+
+module Command.Vicfg where
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import System.Environment (getEnv)
+import Data.Tuple (swap)
+import Data.Char (isSpace)
+import Data.Default
+import Data.Ord
+
+import Command
+import Annex.Perms
+import Types.TrustLevel
+import Types.Group
+import Logs.Trust
+import Logs.Group
+import Logs.PreferredContent
+import Logs.Schedule
+import Logs.Config
+import Logs.NumCopies
+import Types.StandardGroups
+import Types.ScheduledActivity
+import Types.NumCopies
+import Remote
+import Git.Types (fromConfigKey, fromConfigValue)
+import qualified Utility.RawFilePath as R
+
+cmd :: Command
+cmd = command "vicfg" SectionSetup "edit configuration in git-annex branch"
+	paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = do
+	f <- fromRepo gitAnnexTmpCfgFile
+	let f' = fromRawFilePath f
+	createAnnexDirectory $ parentDir f
+	cfg <- getCfg
+	descs <- uuidDescriptions
+	liftIO $ writeFile f' $ genCfg cfg descs
+	vicfg cfg f'
+	stop
+
+vicfg :: Cfg -> FilePath -> Annex ()
+vicfg curcfg f = do
+	vi <- liftIO $ catchDefaultIO "vi" $ getEnv "EDITOR"
+	-- Allow EDITOR to be processed by the shell, so it can contain options.
+	unlessM (liftIO $ boolSystem "sh" [Param "-c", Param $ unwords [vi, shellEscape f]]) $
+		giveup $ vi ++ " exited nonzero; aborting"
+	r <- parseCfg (defCfg curcfg) <$> liftIO (readFileStrict f)
+	liftIO $ removeWhenExistsWith R.removeLink (toRawFilePath f)
+	case r of
+		Left s -> do
+			liftIO $ writeFile f s
+			vicfg curcfg f
+		Right newcfg -> setCfg curcfg newcfg
+
+data Cfg = Cfg
+	{ cfgTrustMap :: M.Map UUID (Down TrustLevel)
+	, cfgGroupMap :: M.Map UUID (S.Set Group)
+	, cfgPreferredContentMap :: M.Map UUID PreferredContentExpression
+	, cfgRequiredContentMap :: M.Map UUID PreferredContentExpression
+	, cfgGroupPreferredContentMap :: M.Map Group PreferredContentExpression
+	, cfgScheduleMap :: M.Map UUID [ScheduledActivity]
+	, cfgGlobalConfigs :: M.Map ConfigKey ConfigValue
+	, cfgNumCopies :: Maybe NumCopies
+	, cfgMinCopies :: Maybe MinCopies
+	}
+
+getCfg :: Annex Cfg
+getCfg = Cfg
+	<$> (M.map Down <$> trustMapRaw) -- without local trust overrides
+	<*> (groupsByUUID <$> groupMap)
+	<*> preferredContentMapRaw
+	<*> requiredContentMapRaw
+	<*> groupPreferredContentMapRaw
+	<*> scheduleMap
+	<*> loadGlobalConfig
+	<*> getGlobalNumCopies
+	<*> getGlobalMinCopies
+
+setCfg :: Cfg -> Cfg -> Annex ()
+setCfg curcfg newcfg = do
+	let diff = diffCfg curcfg newcfg
+	mapM_ (uncurry trustSet) $ M.toList $ M.map (\(Down v) -> v) $ cfgTrustMap diff
+	mapM_ (uncurry groupSet) $ M.toList $ cfgGroupMap diff
+	mapM_ (uncurry preferredContentSet) $ M.toList $ cfgPreferredContentMap diff
+	mapM_ (uncurry requiredContentSet) $ M.toList $ cfgRequiredContentMap diff
+	mapM_ (uncurry groupPreferredContentSet) $ M.toList $ cfgGroupPreferredContentMap diff
+	mapM_ (uncurry scheduleSet) $ M.toList $ cfgScheduleMap diff
+	mapM_ (uncurry setGlobalConfig) $ M.toList $ cfgGlobalConfigs diff
+	maybe noop setGlobalNumCopies $ cfgNumCopies diff
+	maybe noop setGlobalMinCopies $ cfgMinCopies diff
+
+{- Default config has all the keys from the input config, but with their
+ - default values. -}
+defCfg :: Cfg -> Cfg
+defCfg curcfg = Cfg
+	{ cfgTrustMap = mapdef $ cfgTrustMap curcfg
+	, cfgGroupMap = mapdef $ cfgGroupMap curcfg
+	, cfgPreferredContentMap = mapdef $ cfgPreferredContentMap curcfg
+	, cfgRequiredContentMap = mapdef $ cfgRequiredContentMap curcfg
+	, cfgGroupPreferredContentMap = mapdef $ cfgGroupPreferredContentMap curcfg
+	, cfgScheduleMap = mapdef $ cfgScheduleMap curcfg
+	, cfgGlobalConfigs = mapdef $ cfgGlobalConfigs curcfg
+	, cfgNumCopies = Nothing
+	, cfgMinCopies = Nothing
+	}
+  where
+	mapdef :: forall k v. Default v => M.Map k v -> M.Map k v
+	mapdef = M.map (const def)
+
+diffCfg :: Cfg -> Cfg -> Cfg
+diffCfg curcfg newcfg = Cfg
+	{ cfgTrustMap = diff cfgTrustMap
+	, cfgGroupMap = diff cfgGroupMap
+	, cfgPreferredContentMap = diff cfgPreferredContentMap
+	, cfgRequiredContentMap = diff cfgRequiredContentMap
+	, cfgGroupPreferredContentMap = diff cfgGroupPreferredContentMap
+	, cfgScheduleMap = diff cfgScheduleMap
+	, cfgGlobalConfigs = diff cfgGlobalConfigs
+	, cfgNumCopies = cfgNumCopies newcfg
+	, cfgMinCopies = cfgMinCopies newcfg
+	}
+  where
+	diff f = M.differenceWith (\x y -> if x == y then Nothing else Just x)
+		(f newcfg) (f curcfg)
+
+genCfg :: Cfg -> UUIDDescMap -> String
+genCfg cfg descs = unlines $ intercalate [""]
+	[ intro
+	, trust
+	, groups
+	, preferredcontent
+	, grouppreferredcontent
+	, standardgroups
+	, requiredcontent
+	, schedule
+	, numcopies
+	, globalconfigs
+	]
+  where
+	intro =
+		[ com "git-annex configuration"
+		, com ""
+		, com "Changes saved to this file will be recorded in the git-annex branch."
+		, com ""
+		, com "Lines in this file have the format:"
+		, com "  setting field = value"
+		]
+
+	trust = settings cfg descs cfgTrustMap
+		[ com "Repository trust configuration"
+		, com "(Valid trust levels: " ++ trustlevels ++ ")"
+		]
+		(\(Down t, u) -> line "trust" u $ showTrustLevel t)
+		(\u -> lcom $ line "trust" u $ showTrustLevel def)
+	  where
+		trustlevels = unwords $ reverse $
+			map showTrustLevel [minBound..maxBound]
+
+	groups = settings cfg descs cfgGroupMap
+		[ com "Repository groups"
+		, com $ "(Standard groups: " ++ grouplist ++ ")"
+		, com "(Separate group names with spaces)"
+		]
+		(\(s, u) -> line "group" u $ unwords $ map fromGroup $ S.toList s)
+		(\u -> lcom $ line "group" u "")
+	  where
+		grouplist = unwords $ map (fromGroup . fromStandardGroup) [minBound..]
+
+	preferredcontent = settings cfg descs cfgPreferredContentMap
+		[ com "Repository preferred contents"
+		, com "(Set to \"standard\" to use a repository's group's preferred contents)"
+		]
+		(\(s, u) -> line "wanted" u s)
+		(\u -> line "wanted" u "")
+	
+	requiredcontent = settings cfg descs cfgRequiredContentMap
+		[ com "Repository required contents" ]
+		(\(s, u) -> line "required" u s)
+		(\u -> line "required" u "")
+
+	grouppreferredcontent = settings' cfg allgroups cfgGroupPreferredContentMap
+		[ com "Group preferred contents"
+		, com "(Used by repositories with \"groupwanted\" in their preferred contents)"
+		]
+		(\(s, g) -> gline g s)
+		(\g -> gline g "")
+	  where
+		gline g val = [ unwords ["groupwanted", fromGroup g, "=", val] ]
+		allgroups = S.unions $ stdgroups : M.elems (cfgGroupMap cfg)
+		stdgroups = S.fromList $ map fromStandardGroup [minBound..maxBound]
+
+	standardgroups =
+		[ com "Standard preferred contents"
+		, com "(Used by wanted or groupwanted expressions containing \"standard\")"
+		, com "(For reference only; built-in and cannot be changed!)"
+		]
+		++ map gline [minBound..maxBound]
+	  where
+		gline g = com $ unwords
+			[ "standard"
+			, fromGroup (fromStandardGroup g), "=", standardPreferredContent g
+			]
+	
+	schedule = settings cfg descs cfgScheduleMap
+		[ com "Scheduled activities"
+		, com "(Separate multiple activities with \"; \")"
+		]
+		(\(l, u) -> line "schedule" u $ fromScheduledActivities l)
+		(\u -> line "schedule" u "")
+
+	globalconfigs = settings' cfg S.empty cfgGlobalConfigs
+		[ com "Other global configuration"
+		]
+		(\(s, g) -> gline g s)
+		(\g -> gline g mempty)
+	  where
+		gline k v = [ unwords ["config", fromConfigKey k, "=", fromConfigValue v] ]
+
+	line setting u val =
+		[ com $ "(for " ++ fromUUIDDesc (fromMaybe mempty (M.lookup u descs)) ++ ")"
+		, unwords [setting, fromUUID u, "=", val]
+		]
+
+	line' setting Nothing = com $ unwords [setting, "default", "="]
+	line' setting (Just val) = unwords [setting, "default", "=", val]
+
+	numcopies =
+		[ com "Numcopies configuration"
+		, line' "numcopies" (show . fromNumCopies <$> cfgNumCopies cfg)
+		, line' "mincopies" (show . fromMinCopies <$> cfgMinCopies cfg)
+		]
+	
+settings :: Ord v => Cfg -> UUIDDescMap -> (Cfg -> M.Map UUID v) -> [String] -> ((v, UUID) -> [String]) -> (UUID -> [String]) -> [String]
+settings cfg descs = settings' cfg (M.keysSet descs)
+
+settings' :: (Ord v, Ord f) => Cfg -> S.Set f -> (Cfg -> M.Map f v) -> [String] -> ((v, f) -> [String]) -> (f -> [String]) -> [String]
+settings' cfg s field desc showvals showdefaults = concat
+	[ desc
+	, concatMap showvals $ sort $ map swap $ M.toList $ field cfg
+	, concatMap (lcom . showdefaults) missing
+	]
+  where
+	missing = S.toList $ s `S.difference` M.keysSet (field cfg)
+
+lcom :: [String] -> [String]
+lcom = map (\l -> if "#" `isPrefixOf` l then l else '#' : l)
+
+{- If there's a parse error, returns a new version of the file,
+ - with the problem lines noted. -}
+parseCfg :: Cfg -> String -> Either String Cfg
+parseCfg defcfg = go [] defcfg . lines
+  where
+	go c cfg []
+		| null (mapMaybe fst c) = Right cfg
+		| otherwise = Left $ unlines $
+			badheader ++ concatMap showerr (reverse c)
+	go c cfg (l:ls) = case parse (dropWhile isSpace l) cfg of
+		Left msg -> go ((Just msg, l):c) cfg ls
+		Right cfg' -> go ((Nothing, l):c) cfg' ls
+
+	parse l cfg
+		| null l = Right cfg
+		| "#" `isPrefixOf` l = Right cfg
+		| null setting || null f = Left "missing field"
+		| otherwise = parsed cfg f setting val'
+	  where
+		(setting, rest) = separate isSpace l
+		(r, val) = separate (== '=') rest
+		val' = trimspace val
+		f = reverse $ trimspace $ reverse $ trimspace r
+		trimspace = dropWhile isSpace
+
+	parsed cfg f setting val
+		| setting == "trust" = case readTrustLevel val of
+			Nothing -> badval "trust value" val
+			Just t ->
+				let m = M.insert u (Down t) (cfgTrustMap cfg)
+				in Right $ cfg { cfgTrustMap = m }
+		| setting == "group" =
+			let m = M.insert u (S.fromList $ map toGroup $ words val) (cfgGroupMap cfg)
+			in Right $ cfg { cfgGroupMap = m }
+		| setting == "wanted" = 
+			case checkPreferredContentExpression val of
+				Just e -> Left e
+				Nothing ->
+					let m = M.insert u val (cfgPreferredContentMap cfg)
+					in Right $ cfg { cfgPreferredContentMap = m }
+		| setting == "required" = 
+			case checkPreferredContentExpression val of
+				Just e -> Left e
+				Nothing ->
+					let m = M.insert u val (cfgRequiredContentMap cfg)
+					in Right $ cfg { cfgRequiredContentMap = m }
+		| setting == "groupwanted" =
+			case checkPreferredContentExpression val of
+				Just e -> Left e
+				Nothing ->
+					let m = M.insert (toGroup f) val (cfgGroupPreferredContentMap cfg)
+					in Right $ cfg { cfgGroupPreferredContentMap = m }
+		| setting == "schedule" = case parseScheduledActivities val of
+			Left e -> Left e
+			Right l -> 
+				let m = M.insert u l (cfgScheduleMap cfg)
+				in Right $ cfg { cfgScheduleMap = m }
+		| setting == "config" =
+			let m = M.insert (ConfigKey (encodeBS f)) (ConfigValue (encodeBS val)) (cfgGlobalConfigs cfg)
+			in Right $ cfg { cfgGlobalConfigs = m }
+		| setting == "numcopies" = case readish val of
+			Nothing -> Left "parse error (expected an integer)"
+			Just n -> Right $ cfg { cfgNumCopies = Just (configuredNumCopies n) }
+		| setting == "mincopies" = case readish val of
+			Nothing -> Left "parse error (expected an integer)"
+			Just n -> Right $ cfg { cfgMinCopies = Just (configuredMinCopies n) }
+		| otherwise = badval "setting" setting
+	  where
+		u = toUUID f
+
+	showerr (Just msg, l) = [parseerr ++ msg, l]
+	showerr (Nothing, l)
+		-- filter out the header and parse error lines
+		-- from any previous parse failure
+		| any (`isPrefixOf` l) (parseerr:badheader) = []
+		| otherwise = [l]
+
+	badval desc val = Left $ "unknown " ++ desc ++ " \"" ++ val ++ "\""
+	badheader = 
+		[ com "** There was a problem parsing your input!"
+		, com "** Search for \"Parse error\" to find the bad lines."
+		, com "** Either fix the bad lines, or delete them (to discard your changes)."
+		]
+	parseerr = com "** Parse error in next line: "
+
+com :: String -> String
+com s = "# " ++ s
diff --git a/Command/View.hs b/Command/View.hs
new file mode 100644
index 0000000000..c510d3671b
--- /dev/null
+++ b/Command/View.hs
@@ -0,0 +1,133 @@
+{- git-annex command
+ -
+ - Copyright 2014-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.View where
+
+import Command
+import qualified Annex
+import qualified Git
+import qualified Git.Command
+import qualified Git.Ref
+import qualified Git.Branch
+import qualified Git.LsFiles as LsFiles
+import Git.FilePath
+import Git.Status
+import Types.View
+import Annex.View
+import Logs.View
+import Types.AdjustedBranch
+import Annex.AdjustedBranch.Name
+
+import qualified System.FilePath.ByteString as P
+
+cmd :: Command
+cmd = notBareRepo $
+	command "view" SectionMetaData "enter a view branch"
+		paramView (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withWords (commandAction . start)
+
+start :: [String] -> CommandStart
+start [] = giveup "Specify metadata to include in view"
+start ps = ifM safeToEnterView
+	( do
+		(view, madj) <- mkView ps
+		go view madj =<< currentView
+	, giveup "Not safe to enter view."
+	)
+  where
+	ai = ActionItemOther Nothing
+	si = SeekInput ps
+	go view madj Nothing = starting "view" ai si $
+		perform view madj
+	go view _ (Just (v, _madj))
+		| v == view = stop
+		| otherwise = giveup "Already in a view. Use the vfilter and vadd commands to further refine this view."
+
+safeToEnterView :: Annex Bool
+safeToEnterView = do
+	(l, cleanup) <- inRepo $ getStatus [] []
+	case filter dangerous l of
+		[] -> liftIO cleanup
+		_ -> do
+			warning "Your uncommitted changes would be lost when entering a view."
+			void $ liftIO cleanup
+			return False
+  where
+	dangerous (StagedUnstaged { staged = Nothing, unstaged = Nothing }) = False
+	-- Untracked files will not be affected by entering a view,
+	-- so are not dangerous.
+	dangerous (StagedUnstaged { staged = Just (Untracked _), unstaged = Nothing }) = False
+	dangerous (StagedUnstaged { unstaged = Just (Untracked _), staged = Nothing }) = False
+	dangerous (StagedUnstaged { unstaged = Just (Untracked _), staged = Just (Untracked _) }) = False
+	-- Staged changes would have their modifications either be 
+	-- lost when entering a view, or committed as part of the view.
+	-- Either is dangerous because upon leaving the view; the staged
+	-- changes would be lost.
+	dangerous (StagedUnstaged { staged = Just _ }) = True
+	-- Unstaged changes to annexed files would get lost when entering a
+	-- view.
+	dangerous (StagedUnstaged { unstaged = Just _ }) = True
+
+perform :: View -> Maybe Adjustment -> CommandPerform
+perform view madj = do
+	showAction "searching"
+	next $ checkoutViewBranch view madj applyView
+
+paramView :: String
+paramView = paramRepeating "TAG FIELD=GLOB ?TAG FIELD?=GLOB FIELD!=VALUE"
+
+mkView :: [String] -> Annex (View, Maybe Adjustment)
+mkView ps = go =<< inRepo Git.Branch.current
+  where
+	go Nothing = giveup "not on any branch!"
+	go (Just b) = case adjustedToOriginal b of
+		Nothing -> go' b Nothing
+		Just (adj, b') -> go' b' (Just adj)
+	go' b madj = do
+		vu <- annexViewUnsetDirectory <$> Annex.getGitConfig
+		let v = fst $ refineView (View b []) $
+			map (parseViewParam vu) (reverse ps)
+		return (v, madj)
+
+checkoutViewBranch :: View -> Maybe Adjustment -> (View -> Maybe Adjustment -> Annex Git.Branch) -> CommandCleanup
+checkoutViewBranch view madj mkbranch = do
+	here <- liftIO getCurrentDirectory
+
+	branch <- mkbranch view madj
+	
+	showOutput
+	ok <- inRepo $ Git.Command.runBool
+		[ Param "checkout"
+		, Param (Git.fromRef $ Git.Ref.base branch)
+		]
+	when ok $ do
+		setView view
+		{- A git repo can easily have empty directories in it,
+		 - and this pollutes the view, so remove them.
+		 - (However, empty directories used by submodules are not
+		 - removed.) -}
+		top <- liftIO . absPath =<< fromRepo Git.repoPath
+		(l, cleanup) <- inRepo $
+			LsFiles.notInRepoIncludingEmptyDirectories [] False [top]
+		forM_ l (removeemptydir top)
+		liftIO $ void cleanup
+		unlessM (liftIO $ doesDirectoryExist here) $ do
+			showLongNote $ UnquotedString $ cwdmissing (fromRawFilePath top)
+	return ok
+  where
+	removeemptydir top d = do
+		p <- inRepo $ toTopFilePath d
+		liftIO $ tryIO $ removeDirectory $
+			fromRawFilePath $ (top P.</> getTopFilePath p)
+	cwdmissing top = unlines
+		[ "This view does not include the subdirectory you are currently in."
+		, "Perhaps you should:  cd " ++ top
+		]
diff --git a/Command/Wanted.hs b/Command/Wanted.hs
new file mode 100644
index 0000000000..589eab842c
--- /dev/null
+++ b/Command/Wanted.hs
@@ -0,0 +1,59 @@
+{- git-annex command
+ -
+ - Copyright 2013-2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Wanted where
+
+import Command
+import qualified Remote
+import Logs.PreferredContent
+import Types.StandardGroups
+import Utility.SafeOutput
+
+import qualified Data.Map as M
+
+cmd :: Command
+cmd = cmd' "wanted" "get or set preferred content expression" 
+	preferredContentMapRaw
+	preferredContentSet
+
+cmd'
+	:: String
+	-> String
+	-> Annex (M.Map UUID PreferredContentExpression)
+	-> (UUID -> PreferredContentExpression -> Annex ())
+	-> Command
+cmd' name desc getter setter = noMessages $ 
+	command name SectionSetup desc pdesc (withParams seek)
+  where
+	pdesc = paramPair paramRemote (paramOptional paramExpression)
+
+	seek = withWords (commandAction . start)
+
+	start (rname:[]) = do
+		u <- Remote.nameToUUID rname
+		startingCustomOutput (ActionItemOther Nothing) $
+			performGet getter u
+	start ps@(rname:expr:[]) = do
+		u <- Remote.nameToUUID rname
+		let si = SeekInput ps
+		let ai = ActionItemOther (Just (UnquotedString rname))
+		startingUsualMessages name ai si $
+			performSet setter expr u
+	start _ = giveup "Specify a repository."
+
+performGet :: Ord a => Annex (M.Map a PreferredContentExpression) -> a -> CommandPerform
+performGet getter a = do
+	m <- getter
+	liftIO $ putStrLn $ safeOutput $ fromMaybe "" $ M.lookup a m
+	next $ return True
+
+performSet :: (a -> PreferredContentExpression -> Annex ()) -> String -> a -> CommandPerform
+performSet setter expr a = case checkPreferredContentExpression expr of
+	Just e -> giveup $ "Parse error: " ++ e
+	Nothing -> do
+		setter a expr
+		next $ return True
diff --git a/Command/Watch.hs b/Command/Watch.hs
new file mode 100644
index 0000000000..45289f269e
--- /dev/null
+++ b/Command/Watch.hs
@@ -0,0 +1,35 @@
+{- git-annex watch command
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Watch where
+
+import Command
+import Assistant
+import Utility.HumanTime
+
+cmd :: Command
+cmd = notBareRepo $
+	command "watch" SectionCommon 
+		"daemon to watch for changes and autocommit"
+		paramNothing (seek <$$> const (parseDaemonOptions True))
+
+seek :: DaemonOptions -> CommandSeek
+seek o = commandAction $ start False o Nothing
+
+start :: Bool -> DaemonOptions -> Maybe Duration -> CommandStart
+start assistant o startdelay = do
+	if stopDaemonOption o
+		then stopDaemon
+		else startDaemon assistant 
+			(foregroundDaemonOption o)
+			startdelay
+			Nothing 
+			Nothing
+			Nothing
+			Nothing
+			-- does not return
+	stop
diff --git a/Command/WebApp.hs b/Command/WebApp.hs
new file mode 100644
index 0000000000..2958784eb7
--- /dev/null
+++ b/Command/WebApp.hs
@@ -0,0 +1,252 @@
+{- git-annex webapp launcher
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.WebApp where
+
+import Command
+import Assistant
+import Assistant.Common
+import Assistant.NamedThread
+import Assistant.Threads.WebApp
+import Assistant.WebApp
+import Assistant.Install
+import Annex.Environment
+import Utility.WebApp
+import Utility.Daemon (checkDaemon)
+import Utility.UserInfo
+import Annex.Init
+import Annex.Path
+import qualified Git
+import Git.Types (fromConfigValue)
+import qualified Git.Config
+import qualified Git.CurrentRepo
+import qualified Annex
+import Config.Files.AutoStart
+import Upgrade
+import Annex.Version
+import Annex.Action
+import Utility.Android
+
+import Control.Concurrent
+import Control.Concurrent.STM
+import Network.Socket (PortNumber)
+
+cmd :: Command
+cmd = noCommit $ dontCheck repoExists $ notBareRepo $
+	noRepo (startNoRepo <$$> optParser) $
+		command "webapp" SectionCommon "launch webapp"
+			paramNothing (seek <$$> optParser)
+
+data WebAppOptions = WebAppOptions
+	{ listenAddress :: Maybe String
+	, listenPort :: Maybe PortNumber
+	}
+
+optParser :: CmdParamsDesc -> Parser WebAppOptions
+optParser _ = WebAppOptions
+	<$> optional (strOption
+		( long "listen" <> metavar paramAddress
+		<> help "accept connections to this address"
+		))
+	<*> optional (option auto
+		( long "port" <> metavar paramNumber
+		<> help "specify port to listen on"
+		))
+
+seek :: WebAppOptions -> CommandSeek
+seek = commandAction . start
+
+start :: WebAppOptions -> CommandStart
+start = start' True
+
+start' :: Bool -> WebAppOptions -> CommandStart
+start' allowauto o = do
+	liftIO ensureInstalled
+	ifM (isInitialized <&&> notHome)
+		( maybe notinitialized (go <=< needsUpgrade) =<< getVersion
+		, if allowauto
+			then liftIO $ startNoRepo o
+			else notinitialized
+		)
+	stop
+  where
+	go cannotrun = do
+		browser <- fromRepo webBrowser
+		f <- liftIO . absPath =<< fromRepo gitAnnexHtmlShim
+		listenAddress' <- if isJust (listenAddress o)
+			then pure (listenAddress o)
+			else annexListen <$> Annex.getGitConfig
+		listenPort' <- if isJust (listenPort o)
+			then pure (listenPort o)
+			else annexPort <$> Annex.getGitConfig
+		ifM (checkpid <&&> checkshim (fromRawFilePath f))
+			( if isJust (listenAddress o) || isJust (listenPort o)
+				then giveup "The assistant is already running, so --listen and --port cannot be used."
+				else do
+					url <- liftIO . readFile . fromRawFilePath
+						=<< fromRepo gitAnnexUrlFile
+					liftIO $ if isJust listenAddress'
+						then putStrLn url
+						else liftIO $ openBrowser browser (fromRawFilePath f) url Nothing Nothing
+			, do
+				startDaemon True True Nothing cannotrun listenAddress' listenPort' $ Just $ 
+					\origout origerr url htmlshim ->
+						if isJust listenAddress'
+							then maybe noop (`hPutStrLn` url) origout
+							else openBrowser browser htmlshim url origout origerr
+			)
+	checkpid = do
+		pidfile <- fromRepo gitAnnexPidFile
+		liftIO $ isJust <$> checkDaemon (fromRawFilePath pidfile)
+	checkshim f = liftIO $ doesFileExist f
+	notinitialized = do
+		g <- Annex.gitRepo
+		liftIO $ cannotStartIn (Git.repoLocation g) "repository has not been initialized by git-annex"
+		liftIO $ firstRun o
+
+{- If HOME is a git repo, even if it's initialized for git-annex,
+ - the user almost certainly does not want to run the assistant there. -}
+notHome :: Annex Bool
+notHome = do
+	g <- Annex.gitRepo
+	d <- liftIO $ absPath (Git.repoPath g)
+	h <- liftIO $ absPath . toRawFilePath =<< myHomeDir
+	return (d /= h)
+
+{- When run without a repo, start the first available listed repository in
+ - the autostart file. If none, it's our first time being run! -}
+startNoRepo :: WebAppOptions -> IO ()
+startNoRepo o = go =<< liftIO (filterM doesDirectoryExist =<< readAutoStartFile)
+  where
+	go [] = firstRun o
+	go (d:ds) = do
+		v <- tryNonAsync $ do
+			setCurrentDirectory d
+			Annex.new =<< Git.CurrentRepo.get
+		case v of
+			Left e -> do
+				cannotStartIn d (show e)
+				go ds
+			Right state -> void $ Annex.eval state $ do
+				whenM (fromRepo Git.repoIsLocalBare) $
+					giveup $ d ++ " is a bare git repository, cannot run the webapp in it"
+				r <- callCommandAction $
+					start' False o
+				quiesce False
+				return r
+
+cannotStartIn :: FilePath -> String -> IO ()
+cannotStartIn d reason = warningIO $ "unable to start webapp in repository " ++ d ++ ": " ++ reason
+
+{- Run the webapp without a repository, which prompts the user, makes one,
+ - changes to it, starts the regular assistant, and redirects the
+ - browser to its url.
+ -
+ - This is a very tricky dance -- The first webapp calls the signaler,
+ - which signals the main thread when it's ok to continue by writing to a
+ - MVar. The main thread starts the second webapp, and uses its callback
+ - to write its url back to the MVar, from where the signaler retrieves it,
+ - returning it to the first webapp, which does the redirect.
+ -
+ - Note that it's important that mainthread never terminates! Much
+ - of this complication is due to needing to keep the mainthread running.
+ -}
+firstRun :: WebAppOptions -> IO ()
+firstRun o = do
+	checkEnvironmentIO
+	{- Without a repository, we cannot have an Annex monad, so cannot
+	 - get a ThreadState. This is only safe because the
+	 - webapp checks its noAnnex field before accessing the
+	 - threadstate. -}
+	let st = error "annex state not available"
+	{- Get a DaemonStatus without running in the Annex monad. -}
+	dstatus <- atomically . newTVar =<< newDaemonStatus
+	d <- newAssistantData st dstatus
+	urlrenderer <- newUrlRenderer
+	v <- newEmptyMVar
+	let callback a = Just $ a v
+	runAssistant d $ do
+		startNamedThread urlrenderer $
+			webAppThread d urlrenderer True Nothing
+				(callback signaler)
+				(listenAddress o)
+				(listenPort o)
+				(callback mainthread)
+		waitNamedThreads
+  where
+	signaler v = do
+		putMVar v ""
+		takeMVar v
+	mainthread v url htmlshim
+		| isJust (listenAddress o)= do
+			putStrLn url
+			hFlush stdout
+			go
+		| otherwise = do
+			browser <- maybe Nothing webBrowser
+				<$> catchDefaultIO Nothing Git.Config.global
+			openBrowser browser htmlshim url Nothing Nothing
+			go
+	  where
+		go = do
+			_wait <- takeMVar v
+			state <- Annex.new =<< Git.CurrentRepo.get
+			Annex.eval state $
+				startDaemon True True Nothing Nothing (listenAddress o) (listenPort o) 
+					(Just $ sendurlback v)
+	sendurlback v _origout _origerr url _htmlshim = putMVar v url
+
+openBrowser :: Maybe FilePath -> FilePath -> String -> Maybe Handle -> Maybe Handle -> IO ()
+openBrowser mcmd htmlshim realurl outh errh = do
+	htmlshim' <- fromRawFilePath <$> absPath (toRawFilePath htmlshim)
+	openBrowser' mcmd htmlshim' realurl outh errh
+
+openBrowser' :: Maybe FilePath -> FilePath -> String -> Maybe Handle -> Maybe Handle -> IO ()
+openBrowser' mcmd htmlshim realurl outh errh =
+	ifM osAndroid
+		{- Android does not support file:// urls well, but neither
+		 - is the security of the url in the process table important
+		 - there, so just use the real url. -}
+		( runbrowser realurl
+		, runbrowser (fileUrl htmlshim)
+		)
+  where
+	runbrowser url = do
+		let p = case mcmd of
+			Just c -> proc c [url]
+			Nothing -> 
+#ifndef mingw32_HOST_OS
+				browserProc url
+#else
+				{- Windows hack to avoid using the full path,
+				 - which might contain spaces that cause problems
+				 - for browserProc. -}
+				(browserProc (takeFileName htmlshim))
+					{ cwd = Just (takeDirectory htmlshim) } 
+#endif
+		hPutStrLn (fromMaybe stdout outh) $ "Launching web browser on " ++ url
+		hFlush stdout
+		environ <- cleanStandaloneEnvironment
+		let p' = p
+			{ env = environ
+			, std_out = maybe Inherit UseHandle outh
+			, std_err = maybe Inherit UseHandle errh
+			}
+		withCreateProcess p' $ \_ _ _ pid -> do
+			exitcode <- waitForProcess pid
+			unless (exitcode == ExitSuccess) $
+				hPutStrLn (fromMaybe stderr errh) "failed to start web browser"
+
+{- web.browser is a generic git config setting for a web browser program -}
+webBrowser :: Git.Repo -> Maybe FilePath
+webBrowser = fmap fromConfigValue <$> Git.Config.getMaybe "web.browser"
+
+fileUrl :: FilePath -> String
+fileUrl file = "file://" ++ file
diff --git a/Command/WhereUsed.hs b/Command/WhereUsed.hs
new file mode 100644
index 0000000000..2119c02a66
--- /dev/null
+++ b/Command/WhereUsed.hs
@@ -0,0 +1,170 @@
+{- git-annex command
+ -
+ - Copyright 2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Command.WhereUsed where
+
+import Command
+import Git
+import Git.Sha
+import Git.FilePath
+import qualified Git.Command
+import qualified Git.DiffTree as DiffTree
+import qualified Annex
+import qualified Annex.Branch
+import Annex.CatFile
+import Database.Keys
+
+import Data.Char
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.ByteString.Lazy as L
+
+cmd :: Command
+cmd = noCommit $ withAnnexOptions [annexedMatchingOptions] $
+	command "whereused" SectionQuery
+		"lists repositories that have file content"
+		paramNothing (seek <$$> optParser)
+
+data WhereUsedOptions = WhereUsedOptions
+	{ keyOptions :: KeyOptions
+	, historicalOption :: Bool
+	}
+
+optParser :: CmdParamsDesc -> Parser WhereUsedOptions
+optParser _desc = WhereUsedOptions
+	<$> (parseUnusedKeysOption <|> parseSpecificKeyOption)
+	<*> switch
+		( long "historical"
+		<> help "find historical uses"
+		)
+
+seek :: WhereUsedOptions -> CommandSeek
+seek o = withKeyOptions (Just (keyOptions o)) False dummyfileseeker
+	(commandAction . start o) dummyfilecommandseek (WorkTreeItems [])
+  where
+	dummyfileseeker = AnnexedFileSeeker
+		{ startAction = \_ _ _ _ -> return Nothing
+		, checkContentPresent = Nothing
+		, usesLocationLog = False
+		}
+	dummyfilecommandseek = const noop
+
+start :: WhereUsedOptions -> (SeekInput, Key, ActionItem) -> CommandStart
+start o (_, key, _) = startingCustomOutput key $ do
+	fs <- filterM stillassociated
+		=<< mapM (liftIO . relPathCwdToFile)
+		=<< mapM (fromRepo . fromTopFilePath)
+		=<< getAssociatedFiles key
+	forM_ fs $ display key . QuotedPath
+
+	when (historicalOption o && null fs) $
+		findHistorical key
+
+	next $ return True
+  where
+	-- Some associated files that are in the keys database may no
+	-- longer correspond to files in the repository.
+	stillassociated f = catKeyFile f >>= \case
+		Just k | k == key -> return True
+		_ -> return False
+
+display :: Key -> StringContainingQuotedPath -> Annex ()
+display key loc = do
+	qp <- coreQuotePath <$> Annex.getGitConfig
+	liftIO $ S8.putStrLn $ quote qp $
+		UnquotedByteString (serializeKey' key) <> " " <> loc
+
+findHistorical :: Key -> Annex ()
+findHistorical key = do
+	-- Find most recent change to the key, in all branches and
+	-- tags, except the git-annex branch.
+	found <- searchLog key 
+		-- Search all local branches, except git-annex branch.
+		[ Param ("--exclude=*/" ++ fromRef (Annex.Branch.name))
+		, Param "--glob=*"
+		-- Also search remote branches
+		, Param ("--exclude=" ++ fromRef (Annex.Branch.name))
+		, Param "--remotes=*"
+		-- And search tags.
+		, Param "--tags=*"
+		-- Output the commit hash
+		, Param "--pretty=%H"
+		] $ \h fs -> do
+			commitsha <- liftIO $ getSha "log" (pure h)
+			commitdesc <- S.takeWhile (/= fromIntegral (ord '\n'))
+				<$> inRepo (Git.Command.pipeReadStrict
+					[ Param "describe"
+					, Param "--contains"
+					, Param "--all"
+					, Param (fromRef commitsha)
+					])
+			if S.null commitdesc
+				then return False
+				else process fs $
+					displayreffile (Ref commitdesc)
+		
+	unless found $
+		void $ searchLog key
+			[ Param "--walk-reflogs"
+			-- Output the reflog selector
+			, Param "--pretty=%gd"
+			] $ \h fs -> process fs $
+				displayreffile (Ref h)
+  where
+	process fs a = or <$> forM fs a
+
+	displayreffile r f = do
+		tf <- inRepo $ toTopFilePath f
+		display key (descBranchFilePath (BranchFilePath r tf))
+		return True
+
+searchLog :: Key -> [CommandParam] -> (S.ByteString -> [RawFilePath] -> Annex Bool) -> Annex Bool
+searchLog key ps a = do
+	(output, cleanup) <- Annex.inRepo $ Git.Command.pipeNullSplit ps'
+	found <- case output of
+		(h:rest) -> do
+			let diff = DiffTree.parseDiffRaw rest
+			repo <- Annex.gitRepo
+			let fs = map (flip fromTopFilePath repo . DiffTree.file) diff
+			rfs <- liftIO $ mapM relPathCwdToFile fs
+			a (L.toStrict h) rfs
+		_ -> return False
+	liftIO $ void cleanup
+	return found
+  where
+	ps' = 
+		[ Param "log"
+		, Param "-z"
+		-- Don't convert pointer files.
+		, Param "--no-textconv"
+		-- Don't abbreviate hashes.
+		, Param "--no-abbrev"
+		-- Only find the most recent commit, for speed.
+		, Param "-n1"
+		-- Be sure to treat -G as a regexp.
+		, Param "--basic-regexp"
+		-- Find commits that contain the key. The object has to
+		-- end with the key to avoid confusion with longer keys,
+		-- so a regexp is used. Since annex pointer files
+		-- may contain a newline followed by perhaps something
+		-- else, that is also matched.
+		, Param ("-G" ++ escapeRegexp (fromRawFilePath (keyFile key)) ++ "($|\n)")
+		-- Skip commits where the file was deleted,
+		-- only find those where it was added or modified.
+		, Param "--diff-filter=ACMRTUX"
+		-- Output the raw diff.
+		, Param "--raw"
+		] ++ ps
+
+escapeRegexp :: String -> String
+escapeRegexp = concatMap esc
+  where
+	esc c
+		| isAscii c && isAlphaNum c = [c]
+		| otherwise = ['[', c, ']']
diff --git a/Command/Whereis.hs b/Command/Whereis.hs
new file mode 100644
index 0000000000..7c7edd1f4b
--- /dev/null
+++ b/Command/Whereis.hs
@@ -0,0 +1,167 @@
+{- git-annex command
+ -
+ - Copyright 2010-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TupleSections #-}
+
+module Command.Whereis where
+
+import Command
+import Remote
+import Logs.Trust
+import Logs.Web
+import Remote.Web (getWebUrls)
+import Annex.UUID
+import qualified Utility.Format
+import qualified Command.Find
+
+import qualified Data.Map as M
+import qualified Data.Vector as V
+
+cmd :: Command
+cmd = noCommit $ withAnnexOptions [jsonOptions, annexedMatchingOptions] $
+	command "whereis" SectionQuery
+		"lists repositories that have file content"
+		paramPaths (seek <$$> optParser)
+
+data WhereisOptions = WhereisOptions
+	{ whereisFiles :: CmdParams
+	, keyOptions :: Maybe KeyOptions
+	, batchOption :: BatchMode
+	, formatOption :: Maybe Utility.Format.Format
+	}
+
+optParser :: CmdParamsDesc -> Parser WhereisOptions
+optParser desc = WhereisOptions
+	<$> cmdParams desc
+	<*> optional parseKeyOptions
+	<*> parseBatchOption True
+	<*> optional parseFormatOption
+
+parseFormatOption :: Parser Utility.Format.Format
+parseFormatOption = option (Utility.Format.gen <$> str)
+	( long "format" <> metavar paramFormat
+	<> help "control format of output"
+	)
+
+seek :: WhereisOptions -> CommandSeek
+seek o = do
+	m <- remoteMap id
+	let seeker = AnnexedFileSeeker
+		{ startAction = const $ start o m
+		, checkContentPresent = Nothing
+		, usesLocationLog = True
+		}
+	case batchOption o of
+		NoBatch -> do
+			withKeyOptions (keyOptions o) False seeker
+				(commandAction . startKeys o m)
+				(withFilesInGitAnnex ww seeker)
+				=<< workTreeItems ww (whereisFiles o)
+		Batch fmt -> batchOnly (keyOptions o) (whereisFiles o) $
+			batchAnnexed fmt seeker (startKeys o m)
+  where
+	ww = WarnUnmatchLsFiles "whereis"
+
+start :: WhereisOptions -> M.Map UUID Remote -> SeekInput -> RawFilePath -> Key -> CommandStart
+start o remotemap si file key = 
+	startKeys o remotemap (si, key, mkActionItem (key, afile))
+  where
+	afile = AssociatedFile (Just file)
+
+startKeys :: WhereisOptions -> M.Map UUID Remote -> (SeekInput, Key, ActionItem) -> CommandStart
+startKeys o remotemap (si, key, ai)
+	| isJust (formatOption o) = startingCustomOutput ai go
+	| otherwise = starting "whereis" ai si go
+  where
+	go = perform o remotemap key ai
+
+perform :: WhereisOptions -> M.Map UUID Remote -> Key -> ActionItem -> CommandPerform
+perform o remotemap key ai = do
+	locations <- keyLocations key
+	urls <- getUUIDUrls key locations remotemap
+	(untrustedlocations, safelocations) <- trustPartition UnTrusted locations
+	case formatOption o of
+		Nothing -> do
+			let num = length safelocations
+			showNote $ UnquotedString $ show num ++ " " ++ copiesplural num
+			pp <- ppwhereis "whereis" safelocations urls
+			unless (null safelocations) $
+				showLongNote (UnquotedString pp)
+			pp' <- ppwhereis "untrusted" untrustedlocations urls
+			unless (null untrustedlocations) $
+				showLongNote $ UnquotedString $
+					untrustedheader ++ pp'
+			mapM_ (showRemoteUrls remotemap) urls
+		Just formatter -> liftIO $ do
+			let vs = Command.Find.formatVars key
+				(AssociatedFile (actionItemFile ai))
+			let showformatted muuid murl = putStr $
+				Utility.Format.format formatter $
+					M.fromList $ vs ++ catMaybes
+						[ fmap ("uuid",) muuid
+						, fmap ("url",) murl
+						]
+			let showformatted' muuid
+				| Utility.Format.formatContainsVar "url" formatter =
+					forM_ (concatMap snd urls) $ 
+						showformatted muuid . Just
+				| otherwise = showformatted muuid Nothing
+			if Utility.Format.formatContainsVar "uuid" formatter
+				then forM_ locations $
+					showformatted' . Just . fromUUID
+				else showformatted' Nothing
+
+	if null safelocations then stop else next $ return True
+  where
+	copiesplural 1 = "copy"
+	copiesplural _ = "copies"
+	untrustedheader = "The following untrusted locations may also have copies:\n"
+	ppwhereis h ls urls = do
+		descm <- uuidDescriptions
+		let urlvals = map (\(u, us) -> (u, Just (V.fromList us))) $
+			filter (\(u,_) -> u `elem` ls) urls
+		prettyPrintUUIDsWith (Just "urls") h descm (const Nothing) urlvals
+
+getUUIDUrls :: Key -> [UUID] -> M.Map UUID Remote -> Annex [(UUID, [URLString])]
+getUUIDUrls key uuids remotemap = forM uuids $ \uu -> (,)
+	<$> pure uu
+	<*> maybe (pure []) (getRemoteUrls key) (M.lookup uu remotemap)
+
+getRemoteUrls :: Key -> Remote -> Annex [URLString]
+getRemoteUrls key remote
+	| uuid remote == webUUID = 
+		map (fst . getDownloader) <$> getWebUrls key
+	| otherwise = (++)
+		<$> askremote
+		<*> claimedurls
+  where
+	askremote = case whereisKey remote of
+		Nothing -> pure []
+		Just w -> tryNonAsync (w key) >>= \case
+			Right l -> pure l
+			Left e -> do
+				warning $ UnquotedString $ unwords
+					[ "unable to query remote"
+					, name remote
+					, "for urls:"
+					, show e
+					]
+				return []
+	claimedurls = do
+		us <- map fst 
+			. filter (\(_, d) -> d == OtherDownloader)
+			. map getDownloader
+			<$> getUrls key
+		filterM (\u -> (==) <$> pure remote <*> claimingUrl u) us
+
+showRemoteUrls :: M.Map UUID Remote -> (UUID, [URLString]) -> Annex ()
+showRemoteUrls remotemap (uu, us)
+	| null us = noop
+	| otherwise = case M.lookup uu remotemap of
+		Just r -> showLongNote $ UnquotedString $
+			unlines $ map (\u -> name r ++ ": " ++ u) us 
+		Nothing -> noop
diff --git a/Common.hs b/Common.hs
new file mode 100644
index 0000000000..c430163063
--- /dev/null
+++ b/Common.hs
@@ -0,0 +1,36 @@
+module Common (module X) where
+
+import Control.Monad as X
+import Control.Monad.IfElse as X
+import Control.Applicative as X
+import Control.Monad.IO.Class as X (liftIO)
+
+import Data.Maybe as X
+import Data.List as X hiding (head, tail, init, last)
+import Data.Monoid as X
+import Data.Default as X
+
+import System.FilePath as X
+import System.IO as X hiding (FilePath)
+import System.Exit as X
+import System.PosixCompat.Files as X (FileStatus)
+
+import Utility.Misc as X
+import Utility.Exception as X
+import Utility.DebugLocks as X
+import Utility.SafeCommand as X
+import Utility.ShellEscape as X
+import Utility.Process as X
+import Utility.Path as X
+import Utility.Path.AbsRel as X
+import Utility.Directory as X
+import Utility.MoveFile as X
+import Utility.Monad as X
+import Utility.Data as X
+import Utility.Applicative as X
+import Utility.FileSize as X
+import Utility.Network as X
+import Utility.Split as X
+import Utility.FileSystemEncoding as X
+
+import Utility.PartialPrelude as X
diff --git a/Config.hs b/Config.hs
new file mode 100644
index 0000000000..e4d563cfae
--- /dev/null
+++ b/Config.hs
@@ -0,0 +1,101 @@
+{- Git configuration
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE CPP #-}
+
+module Config (
+	module Config,
+	annexConfig,
+	remoteAnnexConfig,
+	remoteConfig,
+) where
+
+import Annex.Common
+import qualified Git
+import qualified Git.Config
+import qualified Git.Command
+import qualified Annex
+import Config.Cost
+import Config.DynamicConfig
+import Types.Availability
+import Types.GitConfig
+import Types.RemoteConfig
+import Git.Types
+import Annex.SpecialRemote.Config
+
+{- Looks up a setting in git config. This is not as efficient as using the
+ - GitConfig type. -}
+getConfig :: ConfigKey -> ConfigValue -> Annex ConfigValue
+getConfig key d = fromRepo $ Git.Config.get key d
+
+getConfigMaybe :: ConfigKey -> Annex (Maybe ConfigValue)
+getConfigMaybe key = fromRepo $ Git.Config.getMaybe key
+
+{- Changes a git config setting in both internal state and .git/config -}
+setConfig :: ConfigKey -> String -> Annex ()
+setConfig (ConfigKey key) value = do
+	inRepo $ Git.Command.run
+		[ Param "config"
+		, Param (decodeBS key)
+		, Param value
+		]
+	reloadConfig
+
+reloadConfig :: Annex ()
+reloadConfig = Annex.changeGitRepo =<< inRepo Git.Config.reRead
+
+{- Unsets a git config setting. (Leaves it in state.) -}
+unsetConfig :: ConfigKey -> Annex ()
+unsetConfig key = void $ inRepo $ Git.Config.unset key
+
+{- Gets cost for a remote. As configured by
+ - remote.<name>.annex-cost, or if remote.<name>.annex-cost-command
+ - is set and prints a number, that is used. If neither is set,
+ - using the cost field from the ParsedRemoteConfig, and if it is not set,
+ - the specified default. -}
+remoteCost :: RemoteGitConfig -> ParsedRemoteConfig -> Cost -> Annex Cost
+remoteCost gc pc d = fromMaybe d <$> remoteCost' gc pc
+
+remoteCost' :: RemoteGitConfig -> ParsedRemoteConfig -> Annex (Maybe Cost)
+remoteCost' gc pc = maybe (getRemoteConfigValue costField pc) Just
+	<$> liftIO (getDynamicConfig $ remoteAnnexCost gc)
+
+setRemoteCost :: Git.Repo -> Cost -> Annex ()
+setRemoteCost r c = setConfig (remoteAnnexConfig r "cost") (show c)
+
+setRemoteAvailability :: Git.Repo -> Availability -> Annex ()
+setRemoteAvailability r c = setConfig (remoteAnnexConfig r "availability") (show c)
+
+setRemoteIgnore :: Git.Repo -> Bool -> Annex ()
+setRemoteIgnore r b = setConfig (remoteAnnexConfig r "ignore") (Git.Config.boolConfig b)
+
+setRemoteBare :: Git.Repo -> Bool -> Annex ()
+setRemoteBare r b = setConfig (remoteAnnexConfig r "bare") (Git.Config.boolConfig b)
+
+isBareRepo :: Annex Bool
+isBareRepo = fromRepo Git.repoIsLocalBare
+
+isDirect :: Annex Bool
+isDirect = annexDirect <$> Annex.getGitConfig
+
+crippledFileSystem :: Annex Bool
+crippledFileSystem = annexCrippledFileSystem <$> Annex.getGitConfig
+
+setCrippledFileSystem :: Bool -> Annex ()
+setCrippledFileSystem b =
+	setConfig (annexConfig "crippledfilesystem") (Git.Config.boolConfig b)
+
+pidLockFile :: Annex (Maybe RawFilePath)
+#ifndef mingw32_HOST_OS
+pidLockFile = ifM (annexPidLock <$> Annex.getGitConfig)
+	( Just <$> Annex.fromRepo gitAnnexPidLockFile
+	, pure Nothing
+	)
+#else
+pidLockFile = pure Nothing
+#endif
diff --git a/Config/Cost.hs b/Config/Cost.hs
new file mode 100644
index 0000000000..c7d4d378cc
--- /dev/null
+++ b/Config/Cost.hs
@@ -0,0 +1,82 @@
+{- Remote costs.
+ -
+ - Copyright 2011-2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Config.Cost where
+
+{- We use a float for a cost to ensure that there is a cost in
+ - between any two other costs. -}
+type Cost = Float
+
+{- Some predefined default costs.
+ - Users setting costs in config files can be aware of these,
+ - and pick values relative to them. So don't change. -}
+cheapRemoteCost :: Cost
+cheapRemoteCost = 100
+nearlyCheapRemoteCost :: Cost
+nearlyCheapRemoteCost = 110
+semiExpensiveRemoteCost :: Cost
+semiExpensiveRemoteCost = 175
+expensiveRemoteCost :: Cost
+expensiveRemoteCost = 200
+veryExpensiveRemoteCost :: Cost
+veryExpensiveRemoteCost = 1000
+
+{- Adjusts a remote's cost to reflect it being encrypted. -}
+encryptedRemoteCostAdj :: Cost
+encryptedRemoteCostAdj = 50
+
+{- Given an ordered list of costs, and the position of one of the items
+ - the list, inserts a new cost into the list, in between the item
+ - and the item after it.
+ -
+ - If two or move items have the same cost, their costs are adjusted
+ - to make room. The costs of other items in the list are left
+ - unchanged.
+ -
+ - To insert the new cost before any other in the list, specify a negative
+ - position. To insert the new cost at the end of the list, specify a
+ - position longer than the list.
+ -}
+insertCostAfter :: [Cost] -> Int -> [Cost]
+insertCostAfter [] _ = []
+insertCostAfter l pos
+	| pos < 0 = costBetween 0 (l !! 0) : l
+	| nextpos > maxpos = l ++ [1 + l !! maxpos]
+	| item == nextitem = case insertCostAfter lastsegment 0 of
+		(_dup:new:l') -> firstsegment ++ [costBetween item new, new] ++ l'
+		_ -> error "insertCostAfter internal error"
+	| otherwise =
+		firstsegment ++ [costBetween item nextitem ] ++ lastsegment
+  where
+	nextpos = pos + 1
+	maxpos = length l - 1
+	
+	item = l !! pos
+	nextitem = l !! nextpos
+		
+	(firstsegment, lastsegment) = splitAt (pos + 1) l
+
+costBetween :: Cost -> Cost -> Cost
+costBetween x y
+	| x == y = x
+	| x > y = -- avoid fractions unless needed
+		let mid = y + (x - y) / 2
+		    mid' = fromIntegral (floor mid :: Int)
+		in if mid' > y then mid' else mid
+	| otherwise = costBetween y x
+
+{- Make sure the remote cost numbers work out. -}
+prop_cost_sane :: Bool
+prop_cost_sane = False `notElem`
+	[ expensiveRemoteCost > 0
+	, cheapRemoteCost < nearlyCheapRemoteCost
+	, nearlyCheapRemoteCost < semiExpensiveRemoteCost
+	, semiExpensiveRemoteCost < expensiveRemoteCost
+	, cheapRemoteCost + encryptedRemoteCostAdj > nearlyCheapRemoteCost
+	, nearlyCheapRemoteCost + encryptedRemoteCostAdj < semiExpensiveRemoteCost
+	, nearlyCheapRemoteCost + encryptedRemoteCostAdj < expensiveRemoteCost
+	]
diff --git a/Config/DynamicConfig.hs b/Config/DynamicConfig.hs
new file mode 100644
index 0000000000..370611f243
--- /dev/null
+++ b/Config/DynamicConfig.hs
@@ -0,0 +1,47 @@
+{- dynamic configuration
+ -
+ - Copyright 2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Config.DynamicConfig where
+
+import Common
+
+import Control.Concurrent.STM
+
+-- | A configuration value that may only be known after performing an IO
+-- action. The IO action will only be run the first time the configuration
+-- is accessed; its result is then cached.
+data DynamicConfig a = DynamicConfig (IO a, TMVar a) | StaticConfig a
+
+mkDynamicConfig :: CommandRunner a -> Maybe String -> a -> STM (DynamicConfig a)
+mkDynamicConfig _ Nothing static = return $ StaticConfig static
+mkDynamicConfig cmdrunner (Just cmd) _ = do
+	tmvar <- newEmptyTMVar
+	return $ DynamicConfig (cmdrunner cmd, tmvar)
+
+getDynamicConfig :: DynamicConfig a -> IO a
+getDynamicConfig (StaticConfig v) = return v
+getDynamicConfig (DynamicConfig (a, tmvar)) = 
+	go =<< atomically (tryReadTMVar tmvar)
+  where
+	go Nothing = do
+		v <- a
+		atomically $ do
+			_ <- tryTakeTMVar tmvar
+			putTMVar tmvar v
+		return v
+	go (Just v) = return v
+
+type CommandRunner a = String -> IO a
+
+successfullCommandRunner :: CommandRunner Bool
+successfullCommandRunner cmd = boolSystem "sh" [Param "-c", Param cmd]
+
+unsuccessfullCommandRunner :: CommandRunner Bool
+unsuccessfullCommandRunner cmd = not <$> successfullCommandRunner cmd
+
+readCommandRunner :: Read a => CommandRunner (Maybe a)
+readCommandRunner cmd = readish <$> readProcess "sh" ["-c", cmd]
diff --git a/Config/Files.hs b/Config/Files.hs
new file mode 100644
index 0000000000..83e4eda085
--- /dev/null
+++ b/Config/Files.hs
@@ -0,0 +1,36 @@
+{- git-annex extra config files
+ -
+ - Copyright 2012-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Config.Files where
+
+import Utility.FreeDesktop
+import Utility.Exception
+
+import System.FilePath
+
+{- ~/.config/git-annex/file -}
+userConfigFile :: FilePath -> IO FilePath
+userConfigFile file = do
+	dir <- userConfigDir
+	return $ dir </> "git-annex" </> file
+
+autoStartFile :: IO FilePath
+autoStartFile = userConfigFile "autostart"
+
+{- The path to git-annex is written here; which is useful when something
+ - has installed it to some awful non-PATH location. -}
+programFile :: IO FilePath
+programFile = userConfigFile "program"
+
+{- A .noannex file in a git repository prevents git-annex from
+ - initializing that repository. The content of the file is returned. -}
+noAnnexFileContent :: Maybe FilePath -> IO (Maybe String)
+noAnnexFileContent repoworktree = case repoworktree of
+	Nothing -> return Nothing
+	Just wt -> catchMaybeIO (readFile (wt </> ".noannex"))
diff --git a/Config/Files/AutoStart.hs b/Config/Files/AutoStart.hs
new file mode 100644
index 0000000000..5c89bd2066
--- /dev/null
+++ b/Config/Files/AutoStart.hs
@@ -0,0 +1,49 @@
+{- git-annex autostart file
+ -
+ - Copyright 2012-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Config.Files.AutoStart where
+
+import Common
+import Config.Files
+import Utility.Tmp
+
+{- Returns anything listed in the autostart file (which may not exist). -}
+readAutoStartFile :: IO [FilePath]
+readAutoStartFile = do
+	f <- autoStartFile
+	filter valid . nub . map dropTrailingPathSeparator . lines
+		<$> catchDefaultIO "" (readFile f)
+  where
+	-- Ignore any relative paths; some old buggy versions added eg "."
+	valid = isAbsolute
+
+modifyAutoStartFile :: ([FilePath] -> [FilePath]) -> IO ()
+modifyAutoStartFile func = do
+	dirs <- readAutoStartFile
+	let dirs' = nubBy equalFilePath $ func dirs
+	when (dirs' /= dirs) $ do
+		f <- autoStartFile
+		createDirectoryIfMissing True $
+			fromRawFilePath (parentDir (toRawFilePath f))
+		viaTmp writeFile f $ unlines dirs'
+
+{- Adds a directory to the autostart file. If the directory is already
+ - present, it's moved to the top, so it will be used as the default
+ - when opening the webapp. -}
+addAutoStartFile :: FilePath -> IO ()
+addAutoStartFile path = do
+	path' <- fromRawFilePath <$> absPath (toRawFilePath path)
+	modifyAutoStartFile $ (:) path'
+
+{- Removes a directory from the autostart file. -}
+removeAutoStartFile :: FilePath -> IO ()
+removeAutoStartFile path = do
+	path' <- fromRawFilePath <$> absPath (toRawFilePath path)
+	modifyAutoStartFile $
+		filter (not . equalFilePath path')
diff --git a/Config/GitConfig.hs b/Config/GitConfig.hs
new file mode 100644
index 0000000000..d78047c212
--- /dev/null
+++ b/Config/GitConfig.hs
@@ -0,0 +1,41 @@
+{- git-annex configuration
+ -
+ - Copyright 2017-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Config.GitConfig where
+
+import Annex.Common
+import qualified Annex
+import Types.GitConfig
+import Git.Types
+import Logs.Config
+
+{- Gets a specific setting from GitConfig. If necessary, loads the
+ - repository-global defaults when the GitConfig does not yet 
+ - have a value.
+ -
+ - Note: Be sure to add the config to mergeGitConfig and to
+ - globalConfigs.
+ -}
+getGitConfigVal :: (GitConfig -> GlobalConfigurable a) -> Annex a
+getGitConfigVal f = getGitConfigVal' f >>= \case
+	HasGlobalConfig c -> return c
+	DefaultConfig d -> return d
+	HasGitConfig c -> return c
+
+getGitConfigVal' :: (GitConfig -> GlobalConfigurable a) -> Annex (GlobalConfigurable a)
+getGitConfigVal' f = (f <$> Annex.getGitConfig) >>= \case
+	DefaultConfig _ -> do
+		r <- Annex.gitRepo
+		m <- loadGlobalConfig
+		let globalgc = extractGitConfig FromGlobalConfig (r { config = m })
+		-- This merge of the repo-global config and the git
+		-- config makes all repository-global default
+		-- values populate the GitConfig with HasGlobalConfig
+		-- values, so it will only need to be done once.
+		Annex.overrideGitConfig (\gc -> mergeGitConfig gc globalgc)
+		f <$> Annex.getGitConfig
+	c -> return c
diff --git a/Config/Smudge.hs b/Config/Smudge.hs
new file mode 100644
index 0000000000..da198096fe
--- /dev/null
+++ b/Config/Smudge.hs
@@ -0,0 +1,82 @@
+{- Git smudge filter configuration
+ -
+ - Copyright 2011-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Config.Smudge where
+
+import Annex.Common
+import qualified Annex
+import qualified Git
+import qualified Git.Command
+import Git.Types
+import Config
+import Utility.Directory.Create
+import Annex.Version
+
+import qualified System.FilePath.ByteString as P
+
+configureSmudgeFilter :: Annex ()
+configureSmudgeFilter = unlessM (fromRepo Git.repoIsLocalBare) $ do
+	-- If this is run in a newly cloned repository, git may not have
+	-- cached file information in the index yet, and so after
+	-- configuring the clean filter, the next git status would want to
+	-- run it on every file. That is expensive and can also result in
+	-- unexpected changes when the file is checked into git or annex
+	-- counter to the annex.largefiles configuration.
+	-- Avoid that problem by running git status now.
+	inRepo $ Git.Command.runQuiet
+		[ Param "status"
+		, Param "--porcelain"
+		, Param "--ignore-submodules"
+		]
+
+	setConfig (ConfigKey "filter.annex.smudge") "git-annex smudge -- %f"
+	setConfig (ConfigKey "filter.annex.clean") "git-annex smudge --clean -- %f"
+	whenM (versionSupportsFilterProcess <$> getVersion)
+		configureSmudgeFilterProcess
+	lf <- Annex.fromRepo Git.attributesLocal
+	gf <- Annex.fromRepo Git.attributes
+	lfs <- readattr lf
+	gfs <- readattr gf
+	gittop <- Git.localGitDir <$> gitRepo
+	liftIO $ unless ("filter=annex" `isInfixOf` (lfs ++ gfs)) $ do
+		createDirectoryUnder [gittop] (P.takeDirectory lf)
+		writeFile (fromRawFilePath lf) (lfs ++ "\n" ++ unlines stdattr)
+  where
+	readattr = liftIO . catchDefaultIO "" . readFileStrict . fromRawFilePath
+
+configureSmudgeFilterProcess :: Annex ()
+configureSmudgeFilterProcess =
+	setConfig (ConfigKey "filter.annex.process") "git-annex filter-process"
+
+stdattr :: [String]
+stdattr =
+	[ "* filter=annex"
+	]
+
+-- Note that this removes the local git attributes for filtering, 
+-- which is what git-annex installed, but it does not change anything
+-- that may have been committed to a .gitattributes in the repository.
+-- git-annex does not commit that.
+deconfigureSmudgeFilter :: Annex ()
+deconfigureSmudgeFilter = do
+	lf <- fromRawFilePath <$> Annex.fromRepo Git.attributesLocal
+	ls <- liftIO $ catchDefaultIO [] $ lines <$> readFileStrict lf
+	liftIO $ writeFile lf $ unlines $
+		filter (\l -> l `notElem` stdattr && not (null l)) ls
+	unsetConfig (ConfigKey "filter.annex.smudge")
+	unsetConfig (ConfigKey "filter.annex.clean")
+
+-- Params to pass to git to temporarily avoid using the smudge/clean
+-- filters.
+bypassSmudgeConfig :: [CommandParam]
+bypassSmudgeConfig = map Param
+	[ "-c", "filter.annex.smudge="
+	, "-c", "filter.annex.clean="
+	, "-c", "filter.annex.process="
+	]
diff --git a/Creds.hs b/Creds.hs
new file mode 100644
index 0000000000..e429d796cf
--- /dev/null
+++ b/Creds.hs
@@ -0,0 +1,241 @@
+{- Credentials storage
+ -
+ - Copyright 2012-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Creds (
+	module Types.Creds,
+	CredPairStorage(..),
+	setRemoteCredPair,
+	setRemoteCredPair',
+	getRemoteCredPair,
+	getRemoteCredPairFor,
+	missingCredPairFor,
+	getEnvCredPair,
+	writeCreds,
+	readCreds,
+	credsFile,
+	removeCreds,
+	includeCredsInfo,
+) where
+
+import Annex.Common
+import qualified Annex
+import Types.Creds
+import Types.RemoteConfig
+import Types.Remote (SetupStage(..))
+import Annex.SpecialRemote.Config
+import Annex.Perms
+import Utility.FileMode
+import Crypto
+import Types.ProposedAccepted
+import Remote.Helper.Encryptable (remoteCipher, remoteCipher', embedCreds, EncryptionIsSetup, extractCipher)
+import Utility.Env (getEnv)
+import Utility.Base64
+import qualified Utility.RawFilePath as R
+
+import qualified Data.ByteString.Lazy.Char8 as L
+import qualified Data.ByteString.Char8 as S
+import qualified Data.Map as M
+import qualified System.FilePath.ByteString as P
+
+{- A CredPair can be stored in a file, or in the environment, or
+ - in a remote's configuration. -}
+data CredPairStorage = CredPairStorage
+	{ credPairFile :: FilePath
+	, credPairEnvironment :: (String, String)
+	, credPairRemoteField :: RemoteConfigField
+	}
+
+{- Stores creds in a remote's configuration, if the remote allows
+ - that. Also caches them locally.
+ -
+ - The creds are found from the CredPairStorage storage if not provided,
+ - so may be provided by an environment variable etc. When autoenabling,
+ - the user would not expect to provide creds, so none are found.
+ -
+ - The remote's configuration should have already had a cipher stored in it
+ - if that's going to be done, so that the creds can be encrypted using the
+ - cipher. The EncryptionIsSetup is witness to that being the case.
+ -}
+setRemoteCredPair
+	:: SetupStage
+	-> EncryptionIsSetup
+	-> ParsedRemoteConfig
+	-> RemoteGitConfig
+	-> CredPairStorage
+	-> Maybe CredPair
+	-> Annex RemoteConfig
+setRemoteCredPair ss encsetup pc gc storage mcreds = case ss of
+	AutoEnable _ -> pure (unparsedRemoteConfig pc)
+	_ -> unparsedRemoteConfig <$>
+		setRemoteCredPair' pc encsetup gc storage mcreds
+
+setRemoteCredPair'
+	:: ParsedRemoteConfig
+	-> EncryptionIsSetup
+	-> RemoteGitConfig
+	-> CredPairStorage
+	-> Maybe CredPair
+	-> Annex ParsedRemoteConfig
+setRemoteCredPair' pc encsetup gc storage mcreds = case mcreds of
+	Nothing -> maybe (return pc) (setRemoteCredPair' pc encsetup gc storage . Just)
+		=<< getRemoteCredPair pc gc storage
+	Just creds
+		| embedCreds pc -> do
+			let key = credPairRemoteField storage
+			localcache creds
+			storeconfig creds key =<< remoteCipher pc gc
+		| otherwise -> do
+			localcache creds
+			return pc
+  where
+	localcache creds = writeCacheCredPair creds storage
+
+	storeconfig creds key (Just cipher) = do
+		cmd <- gpgCmd <$> Annex.getGitConfig
+		s <- liftIO $ encrypt cmd (pc, gc) cipher
+			(feedBytes $ L.pack $ encodeCredPair creds)
+			(readBytesStrictly return)
+		storeconfig' key (Accepted (decodeBS (toB64 s)))
+	storeconfig creds key Nothing =
+		storeconfig' key (Accepted (decodeBS $ toB64 $ encodeBS $ encodeCredPair creds))
+	
+	storeconfig' key val = return $ pc
+		{ parsedRemoteConfigMap = M.insert key (RemoteConfigValue val) (parsedRemoteConfigMap pc)
+		, unparsedRemoteConfig = M.insert key val (unparsedRemoteConfig pc)
+		}
+
+{- Gets a remote's credpair, from the environment if set, otherwise
+ - from the cache in gitAnnexCredsDir, or failing that, from the
+ - value in RemoteConfig. -}
+getRemoteCredPair :: ParsedRemoteConfig -> RemoteGitConfig -> CredPairStorage -> Annex (Maybe CredPair)
+getRemoteCredPair c gc storage = maybe fromcache (return . Just) =<< fromenv
+  where
+	fromenv = liftIO $ getEnvCredPair storage
+	fromcache = maybe fromconfig (return . Just) =<< readCacheCredPair storage
+	fromconfig = do
+		let key = credPairRemoteField storage
+		mcipher <- remoteCipher' c gc
+		-- The RemoteConfig value may be passed through.
+		-- Check for those first, because getRemoteConfigValue
+		-- will throw an error if it does not find it.
+		let getval = M.lookup key (getRemoteConfigPassedThrough c)
+			<|> getRemoteConfigValue key c			
+		case (getval, mcipher) of
+			(Nothing, _) -> return Nothing
+			(Just enccreds, Just (cipher, storablecipher)) ->
+				fromenccreds (encodeBS enccreds) cipher storablecipher
+			(Just bcreds, Nothing) ->
+				fromcreds $ decodeBS $ fromB64 $ encodeBS bcreds
+	fromenccreds enccreds cipher storablecipher = do
+		cmd <- gpgCmd <$> Annex.getGitConfig
+		mcreds <- liftIO $ catchMaybeIO $ decrypt cmd (c, gc) cipher
+			(feedBytes $ L.fromStrict $ fromB64 enccreds)
+			(readBytesStrictly $ return . S.unpack)
+		case mcreds of
+			Just creds -> fromcreds creds
+			Nothing -> do
+				-- Work around un-encrypted creds storage
+				-- bug in old S3 and glacier remotes.
+				-- Not a problem for shared cipher.
+				case storablecipher of
+					SharedCipher {} -> showLongNote "gpg error above was caused by an old git-annex bug in credentials storage. Working around it.."
+					_ -> giveup "*** Insecure credentials storage detected for this remote! See https://git-annex.branchable.com/upgrades/insecure_embedded_creds/"
+				fromcreds $ decodeBS $ fromB64 enccreds
+	fromcreds creds = case decodeCredPair creds of
+		Just credpair -> do
+			writeCacheCredPair credpair storage
+
+			return $ Just credpair
+		_ -> giveup "bad creds"
+
+getRemoteCredPairFor :: String -> ParsedRemoteConfig -> RemoteGitConfig -> CredPairStorage -> Annex (Maybe CredPair)
+getRemoteCredPairFor this c gc storage = go =<< getRemoteCredPair c gc storage
+  where
+	go Nothing = do
+		warning $ UnquotedString $ missingCredPairFor this storage
+		return Nothing
+	go (Just credpair) = return $ Just credpair
+
+missingCredPairFor :: String -> CredPairStorage -> String
+missingCredPairFor this storage = unwords
+	[ "Set both", loginvar
+	, "and", passwordvar
+	, "to use", this
+	]
+  where
+	(loginvar, passwordvar) = credPairEnvironment storage
+
+{- Gets a CredPair from the environment. -}
+getEnvCredPair :: CredPairStorage -> IO (Maybe CredPair)
+getEnvCredPair storage = liftM2 (,)
+	<$> getEnv uenv
+	<*> getEnv penv
+  where
+	(uenv, penv) = credPairEnvironment storage
+
+{- Writes a cred pair to local cache, unless prevented by configuration. -}
+writeCacheCredPair :: CredPair -> CredPairStorage -> Annex ()
+writeCacheCredPair credpair storage = 
+	whenM (annexCacheCreds <$> Annex.getGitConfig) $
+		writeCreds (encodeCredPair credpair) (credPairFile storage)
+
+readCacheCredPair :: CredPairStorage -> Annex (Maybe CredPair)
+readCacheCredPair storage = maybe Nothing decodeCredPair
+	<$> readCreds (credPairFile storage)
+
+existsCacheCredPair :: CredPairStorage -> Annex Bool
+existsCacheCredPair storage = 
+	liftIO . doesFileExist =<< credsFile (credPairFile storage)
+
+{- Stores the creds in a file inside gitAnnexCredsDir that only the user
+ - can read. -}
+writeCreds :: Creds -> FilePath -> Annex ()
+writeCreds creds file = do
+	d <- fromRepo gitAnnexCredsDir
+	createAnnexDirectory d
+	liftIO $ writeFileProtected (d P.</> toRawFilePath file) creds
+
+readCreds :: FilePath -> Annex (Maybe Creds)
+readCreds f = liftIO . catchMaybeIO . readFileStrict =<< credsFile f
+
+credsFile :: FilePath -> Annex FilePath
+credsFile basefile = do
+	d <- fromRawFilePath <$> fromRepo gitAnnexCredsDir
+	return $ d </> basefile
+
+encodeCredPair :: CredPair -> Creds
+encodeCredPair (l, p) = unlines [l, p]
+
+decodeCredPair :: Creds -> Maybe CredPair
+decodeCredPair creds = case lines creds of
+	l:p:[] -> Just (l, p)
+	_ -> Nothing
+
+removeCreds :: FilePath -> Annex ()
+removeCreds file = do
+	d <- fromRepo gitAnnexCredsDir
+	liftIO $ removeWhenExistsWith R.removeLink (d P.</> toRawFilePath file)
+
+includeCredsInfo :: ParsedRemoteConfig -> CredPairStorage -> [(String, String)] -> Annex [(String, String)]
+includeCredsInfo pc@(ParsedRemoteConfig cm _) storage info = do
+	v <- liftIO $ getEnvCredPair storage
+	case v of
+		Just _ -> do
+			let (uenv, penv) = credPairEnvironment storage
+			ret $ "from environment variables (" ++ unwords [uenv, penv] ++ ")"
+		Nothing -> case (`M.lookup` cm) (credPairRemoteField storage) of
+			Nothing -> ifM (existsCacheCredPair storage)
+				( ret "stored locally"
+				, ret "not available"
+				)
+			Just _ -> case extractCipher pc of
+				Just (EncryptedCipher {}) -> ret "embedded in git repository (gpg encrypted)"
+				_ -> ret "embedded in git repository (not encrypted)"
+  where
+	ret s = return $ ("creds", s) : info
diff --git a/Crypto.hs b/Crypto.hs
new file mode 100644
index 0000000000..3fa6d781d1
--- /dev/null
+++ b/Crypto.hs
@@ -0,0 +1,306 @@
+{- git-annex crypto
+ -
+ - Currently using gpg by default, or optionally stateless OpenPGP.
+ -
+ - Copyright 2011-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE FlexibleInstances #-}
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE Rank2Types #-}
+
+module Crypto (
+	EncryptionMethod(..),
+	Cipher,
+	KeyIds(..),
+	EncKey,
+	StorableCipher(..),
+	genEncryptedCipher,
+	genSharedCipher,
+	genSharedPubKeyCipher,
+	updateCipherKeyIds,
+	decryptCipher,
+	decryptCipher',
+	encryptKey,
+	isEncKey,
+	feedFile,
+	feedBytes,
+	readBytes,
+	readBytesStrictly,
+	encrypt,
+	decrypt,
+	LensEncParams(..),
+
+	prop_HmacSha1WithCipher_sane
+) where
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import Control.Monad.IO.Class
+import qualified Data.ByteString.Short as S (toShort)
+
+import Annex.Common
+import qualified Utility.Gpg as Gpg
+import qualified Utility.StatelessOpenPGP as SOP
+import Types.Crypto
+import Types.Remote
+import Types.Key
+import Annex.SpecialRemote.Config
+import Utility.Tmp.Dir
+
+{- The number of bytes of entropy used to generate a Cipher.
+ -
+ - Since a Cipher is base-64 encoded, the actual size of a Cipher
+ - is larger than this. 512 bytes of date base-64 encodes to 684
+ - characters.
+ -}
+cipherSize :: Int
+cipherSize = 512
+
+{- The beginning of a Cipher is used for MAC'ing; the remainder is used
+ - as the symmetric encryption passphrase.
+ -
+ - Due to the base-64 encoding of the Cipher, the beginning 265 characters
+ - represent at best 192 bytes of entropy. However that's more than enough
+ - for both the default MAC algorithm, namely HMAC-SHA1, and the "strongest"
+ - currently supported, namely HMAC-SHA512, which respectively need
+ - (ideally) 64 and 128 bytes of entropy.
+ -
+ - The remaining characters (320 bytes of entropy) is enough for
+ - the symmetric encryption passphrase; unlike weaker public key crypto,
+ - that does not need to be too large.
+ -}
+cipherBeginning :: Int
+cipherBeginning = 256
+
+cipherPassphrase :: Cipher -> S.ByteString
+cipherPassphrase (Cipher c) = S.drop cipherBeginning c
+cipherPassphrase (MacOnlyCipher _) = giveup "MAC-only cipher"
+
+cipherMac :: Cipher -> S.ByteString
+cipherMac (Cipher c) = S.take cipherBeginning c
+cipherMac (MacOnlyCipher c) = c
+
+{- Creates a new Cipher, encrypted to the specified key id. -}
+genEncryptedCipher :: LensEncParams c => Gpg.GpgCmd -> c -> Gpg.KeyId -> EncryptedCipherVariant -> Bool -> IO StorableCipher
+genEncryptedCipher cmd c keyid variant highQuality = do
+	ks <- Gpg.findPubKeys cmd keyid
+	random <- Gpg.genRandom cmd highQuality size
+	encryptCipher cmd c (mkCipher random) variant ks
+  where
+	(mkCipher, size) = case variant of
+		Hybrid -> (Cipher, cipherSize) -- used for MAC + symmetric
+		PubKey -> (MacOnlyCipher, cipherBeginning) -- only used for MAC
+
+{- Creates a new, shared Cipher. -}
+genSharedCipher :: Gpg.GpgCmd -> Bool -> IO StorableCipher
+genSharedCipher cmd highQuality =
+	SharedCipher <$> Gpg.genRandom cmd highQuality cipherSize
+
+{- Creates a new, shared Cipher, and looks up the gpg public key that will
+ - be used for encrypting content. -}
+genSharedPubKeyCipher :: Gpg.GpgCmd -> Gpg.KeyId -> Bool -> IO StorableCipher
+genSharedPubKeyCipher cmd keyid highQuality = do
+	ks <- Gpg.findPubKeys cmd keyid
+	random <- Gpg.genRandom cmd highQuality cipherSize
+	return $ SharedPubKeyCipher random ks
+
+{- Updates an existing Cipher, making changes to its keyids.
+ -
+ - When the Cipher is encrypted, re-encrypts it. -}
+updateCipherKeyIds :: LensEncParams encparams => Gpg.GpgCmd -> encparams -> [(Bool, Gpg.KeyId)] -> StorableCipher -> IO StorableCipher
+updateCipherKeyIds _ _ _ SharedCipher{} = giveup "Cannot update shared cipher"
+updateCipherKeyIds _ _ [] c = return c
+updateCipherKeyIds cmd encparams changes encipher@(EncryptedCipher _ variant ks) = do
+	ks' <- updateCipherKeyIds' cmd changes ks
+	cipher <- decryptCipher cmd encparams encipher
+	encryptCipher cmd encparams cipher variant ks'
+updateCipherKeyIds cmd _ changes (SharedPubKeyCipher cipher ks) =
+	SharedPubKeyCipher cipher <$> updateCipherKeyIds' cmd changes ks
+
+updateCipherKeyIds' :: Gpg.GpgCmd -> [(Bool, Gpg.KeyId)] -> KeyIds -> IO KeyIds
+updateCipherKeyIds' cmd changes (KeyIds ks) = do
+	dropkeys <- listKeyIds [ k | (False, k) <- changes ]
+	forM_ dropkeys $ \k -> unless (k `elem` ks) $
+		giveup $ "Key " ++ k ++ " was not present; cannot remove."
+	addkeys <- listKeyIds [ k | (True, k) <- changes ]
+	let ks' = (addkeys ++ ks) \\ dropkeys
+	when (null ks') $
+		giveup "Cannot remove the last key."
+	return $ KeyIds ks'
+  where
+	listKeyIds = concat <$$> mapM (keyIds <$$> Gpg.findPubKeys cmd)
+
+{- Encrypts a Cipher to the specified KeyIds. -}
+encryptCipher :: LensEncParams c => Gpg.GpgCmd -> c -> Cipher -> EncryptedCipherVariant -> KeyIds -> IO StorableCipher
+encryptCipher cmd c cip variant (KeyIds ks) = do
+	-- gpg complains about duplicate recipient keyids
+	let ks' = nub $ sort ks
+	let params = concat
+		[ getGpgEncParamsBase c
+		, Gpg.pkEncTo ks'
+		, Gpg.stdEncryptionParams False
+		]
+	encipher <- Gpg.pipeStrict cmd params cipher
+	return $ EncryptedCipher encipher variant (KeyIds ks')
+  where
+	cipher = case cip of
+		Cipher x -> x
+		MacOnlyCipher x -> x
+
+{- Decrypting an EncryptedCipher is expensive; the Cipher should be cached. -}
+decryptCipher :: LensEncParams c => Gpg.GpgCmd -> c -> StorableCipher -> IO Cipher
+decryptCipher cmd c cip = decryptCipher' cmd Nothing c cip
+
+decryptCipher' :: LensEncParams c => Gpg.GpgCmd -> Maybe [(String, String)] -> c -> StorableCipher -> IO Cipher
+decryptCipher' _ _ _ (SharedCipher t) = return $ Cipher t
+decryptCipher' _ _ _ (SharedPubKeyCipher t _) = return $ MacOnlyCipher t
+decryptCipher' cmd environ c (EncryptedCipher t variant _) =
+	mkCipher <$> Gpg.pipeStrict' cmd params environ t
+  where
+	mkCipher = case variant of
+		Hybrid -> Cipher
+		PubKey -> MacOnlyCipher
+	params = Param "--decrypt" : getGpgDecParams c
+
+type EncKey = Key -> Key
+
+{- Generates an encrypted form of a Key. The encryption does not need to be
+ - reversible, nor does it need to be the same type of encryption used
+ - on content. It does need to be repeatable. -}
+encryptKey :: Mac -> Cipher -> EncKey
+encryptKey mac c k = mkKey $ \d -> d
+	{ keyName = S.toShort $ encodeBS $ macWithCipher mac c (serializeKey' k)
+	, keyVariety = OtherKey $
+		encryptedBackendNamePrefix <> encodeBS (showMac mac)
+	}
+
+encryptedBackendNamePrefix :: S.ByteString
+encryptedBackendNamePrefix = "GPG"
+
+isEncKey :: Key -> Bool
+isEncKey k = case fromKey keyVariety k of
+	OtherKey s -> encryptedBackendNamePrefix `S.isPrefixOf` s
+	_ -> False
+
+type Feeder = Handle -> IO ()
+type Reader m a = Handle -> m a
+
+feedFile :: FilePath -> Feeder
+feedFile f h = L.hPut h =<< L.readFile f
+
+feedBytes :: L.ByteString -> Feeder
+feedBytes = flip L.hPut
+
+readBytes :: (MonadIO m) => (L.ByteString -> m a) -> Reader m a
+readBytes a h = liftIO (L.hGetContents h) >>= a
+
+readBytesStrictly :: (MonadIO m) => (S.ByteString -> m a) -> Reader m a
+readBytesStrictly a h = liftIO (S.hGetContents h) >>= a
+
+{- Runs a Feeder action, that generates content that is symmetrically
+ - encrypted with the Cipher (unless it is empty, in which case
+ - public-key encryption is used), and then read by the Reader action. 
+ -
+ - Note that the Reader must fully consume all input before returning.
+ -}
+encrypt :: (MonadIO m, MonadMask m, LensEncParams c) => Gpg.GpgCmd -> c -> Cipher -> Feeder -> Reader m a -> m a
+encrypt gpgcmd c cipher feeder reader = case cipher of
+	Cipher{} -> 
+		let passphrase = cipherPassphrase cipher
+		in case statelessOpenPGPCommand c of
+			Just sopcmd -> withTmpDir "sop" $ \d ->
+				SOP.encryptSymmetric sopcmd passphrase
+					(SOP.EmptyDirectory d)
+					(statelessOpenPGPProfile c)
+					(SOP.Armoring False)
+					feeder reader
+			Nothing -> Gpg.feedRead gpgcmd (params ++ Gpg.stdEncryptionParams True) passphrase feeder reader
+	MacOnlyCipher{} -> Gpg.feedRead' gpgcmd (params ++ Gpg.stdEncryptionParams False) feeder reader
+  where
+	params = getGpgEncParams c
+
+{- Runs a Feeder action, that generates content that is decrypted with the
+ - Cipher (or using a private key if the Cipher is empty), and read by the
+ - Reader action.
+ -
+ - Note that the Reader must fully consume all input before returning.
+ - -}
+decrypt :: (MonadIO m, MonadMask m, LensEncParams c) => Gpg.GpgCmd -> c -> Cipher -> Feeder -> Reader m a -> m a
+decrypt cmd c cipher feeder reader = case cipher of
+	Cipher{} -> 
+		let passphrase = cipherPassphrase cipher
+		in case statelessOpenPGPCommand c of
+			Just sopcmd -> withTmpDir "sop" $ \d ->
+				SOP.decryptSymmetric sopcmd passphrase
+					(SOP.EmptyDirectory d)
+					feeder reader
+			Nothing -> Gpg.feedRead cmd params passphrase feeder reader
+	MacOnlyCipher{} -> Gpg.feedRead' cmd params feeder reader
+  where
+	params = Param "--decrypt" : getGpgDecParams c
+
+macWithCipher :: Mac -> Cipher -> S.ByteString -> String
+macWithCipher mac c = macWithCipher' mac (cipherMac c)
+macWithCipher' :: Mac -> S.ByteString -> S.ByteString -> String
+macWithCipher' mac c s = calcMac mac c s
+
+{- Ensure that macWithCipher' returns the same thing forevermore. -}
+prop_HmacSha1WithCipher_sane :: Bool
+prop_HmacSha1WithCipher_sane = known_good == macWithCipher' HmacSha1 "foo" "bar"
+  where
+	known_good = "46b4ec586117154dacd49d664e5d63fdc88efb51"
+
+class LensEncParams a where
+	{- Base gpg parameters for encrypting. Does not include specification
+	 - of recipient keys. -}
+	getGpgEncParamsBase :: a -> [CommandParam]
+	{- Gpg parameters for encrypting. When the remote is configured to use
+	 - public-key encryption, includes specification of recipient keys. -}
+	getGpgEncParams :: a -> [CommandParam]
+	{- Gpg parameters for decrypting. -}
+	getGpgDecParams :: a -> [CommandParam]
+	{- Set when stateless OpenPGP should be used rather than gpg.
+	 - It is currently only used for SharedEncryption and not the other
+	 - schemes which use public keys. -}
+	statelessOpenPGPCommand :: a -> Maybe SOP.SOPCmd
+	{- When using stateless OpenPGP, this may be set to a profile
+	 - which should be used instead of the default. -}
+	statelessOpenPGPProfile :: a -> Maybe SOP.SOPProfile
+
+{- Extract the GnuPG options from a pair of a Remote Config and a Remote
+ - Git Config. -}
+instance LensEncParams (ParsedRemoteConfig, RemoteGitConfig) where
+	getGpgEncParamsBase (_c,gc) = map Param (remoteAnnexGnupgOptions gc)
+	getGpgEncParams (c,gc) = getGpgEncParamsBase (c,gc) ++
+ 		{- When the remote is configured to use public-key encryption,
+		 - look up the recipient keys and add them to the option list. -}
+		case getRemoteConfigValue encryptionField c of
+			Just PubKeyEncryption -> 
+				Gpg.pkEncTo $ maybe [] (splitc ',') $
+					getRemoteConfigValue cipherkeysField c
+			Just SharedPubKeyEncryption ->
+				Gpg.pkEncTo $ maybe [] (splitc ',') $
+					getRemoteConfigValue pubkeysField c
+			_ -> []
+	getGpgDecParams (_c,gc) = map Param (remoteAnnexGnupgDecryptOptions gc)
+	statelessOpenPGPCommand (c,gc) = case remoteAnnexSharedSOPCommand gc of
+		Nothing -> Nothing
+		Just sopcmd ->
+			{- So far stateless OpenPGP is only supported
+			 - for SharedEncryption, not other encryption
+			 - methods that involve public keys. -}
+			case getRemoteConfigValue encryptionField c of
+				Just SharedEncryption -> Just sopcmd
+				_ -> Nothing
+	statelessOpenPGPProfile (_c,gc) = remoteAnnexSharedSOPProfile gc
+
+{- Extract the GnuPG options from a Remote. -}
+instance LensEncParams (RemoteA a) where
+	getGpgEncParamsBase r = getGpgEncParamsBase (config r, gitconfig r)
+	getGpgEncParams r = getGpgEncParams (config r, gitconfig r)
+	getGpgDecParams r = getGpgDecParams (config r, gitconfig r)
+	statelessOpenPGPCommand r = statelessOpenPGPCommand (config r, gitconfig r)
+	statelessOpenPGPProfile r  = statelessOpenPGPProfile (config r, gitconfig r)
diff --git a/Database/Benchmark.hs b/Database/Benchmark.hs
new file mode 100644
index 0000000000..81f3531891
--- /dev/null
+++ b/Database/Benchmark.hs
@@ -0,0 +1,120 @@
+{- git-annex database benchmarks
+ -
+ - Copyright 2016-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Database.Benchmark (benchmarkDbs) where
+
+import Annex.Common
+import Types.Benchmark
+#ifdef WITH_BENCHMARK
+import qualified Database.Keys.SQL as SQL
+import qualified Database.Queue as H
+import Database.Init
+import Utility.Tmp.Dir
+import Git.FilePath
+import Types.Key
+import Utility.DataUnits
+
+import Criterion.Main
+import qualified Data.ByteString.Short as S (toShort)
+import qualified Data.ByteString.Char8 as B8
+import System.Random
+import Control.Concurrent
+import qualified System.FilePath.ByteString as P
+#endif
+
+benchmarkDbs :: CriterionMode -> Integer -> Annex ()
+#ifdef WITH_BENCHMARK
+benchmarkDbs mode n = withTmpDirIn "." "benchmark" $ \tmpdir -> do
+	db <- benchDb (toRawFilePath tmpdir) n
+	liftIO $ runMode mode
+		[ bgroup "keys database"
+			[ getAssociatedFilesHitBench db
+			, getAssociatedFilesMissBench db
+			, getAssociatedKeyHitBench db
+			, getAssociatedKeyMissBench db
+			, addAssociatedFileOldBench db
+			, addAssociatedFileNewBench db
+			]
+		]
+#else
+benchmarkDbs _ = giveup "not built with criterion, cannot benchmark"
+#endif
+
+#ifdef WITH_BENCHMARK
+
+getAssociatedFilesHitBench :: BenchDb -> Benchmark
+getAssociatedFilesHitBench (BenchDb h num _) = bench ("getAssociatedFiles (hit)") $ nfIO $ do
+	n <- getStdRandom (randomR (1,num))
+	SQL.getAssociatedFiles (keyN n) (SQL.ReadHandle h)
+
+getAssociatedFilesMissBench :: BenchDb -> Benchmark
+getAssociatedFilesMissBench (BenchDb h _ _) = bench ("getAssociatedFiles (miss)") $ nfIO $
+	SQL.getAssociatedFiles keyMiss (SQL.ReadHandle h)
+
+getAssociatedKeyHitBench :: BenchDb -> Benchmark
+getAssociatedKeyHitBench (BenchDb h num _) = bench ("getAssociatedKey (hit)") $ nfIO $ do
+	n <- getStdRandom (randomR (1,num))
+	SQL.getAssociatedKey (fileN n) (SQL.ReadHandle h)
+
+getAssociatedKeyMissBench :: BenchDb -> Benchmark
+getAssociatedKeyMissBench (BenchDb h _ _) = bench ("getAssociatedKey (miss)") $ nfIO $
+	SQL.getAssociatedKey fileMiss (SQL.ReadHandle h)
+
+addAssociatedFileOldBench :: BenchDb -> Benchmark
+addAssociatedFileOldBench (BenchDb h num _) = bench ("addAssociatedFile to (old)") $ nfIO $ do
+	n <- getStdRandom (randomR (1,num))
+	SQL.addAssociatedFile (keyN n) (fileN n) (SQL.WriteHandle h)
+	H.flushDbQueue h
+
+addAssociatedFileNewBench :: BenchDb -> Benchmark
+addAssociatedFileNewBench (BenchDb h num mv) = bench ("addAssociatedFile to (new)") $ nfIO $ do
+	n <- takeMVar mv
+	putMVar mv (n+1)
+	SQL.addAssociatedFile (keyN n) (fileN (num+n)) (SQL.WriteHandle h)
+	H.flushDbQueue h
+
+populateAssociatedFiles :: H.DbQueue -> Integer -> IO ()
+populateAssociatedFiles h num = do
+	forM_ [1..num] $ \n ->
+		SQL.addAssociatedFile (keyN n) (fileN n) (SQL.WriteHandle h)
+	H.flushDbQueue h
+
+keyN :: Integer -> Key
+keyN n = mkKey $ \k -> k
+	{ keyName = S.toShort (B8.pack $ "key" ++ show n)
+	, keyVariety = OtherKey "BENCH"
+	}
+
+fileN :: Integer -> TopFilePath
+fileN n = asTopFilePath (toRawFilePath ("file" ++ show n))
+
+keyMiss :: Key
+keyMiss = keyN 0 -- 0 is never stored
+
+fileMiss :: TopFilePath
+fileMiss = fileN 0 -- 0 is never stored
+
+data BenchDb = BenchDb H.DbQueue Integer (MVar Integer)
+
+benchDb :: RawFilePath -> Integer -> Annex BenchDb
+benchDb tmpdir num = do
+	liftIO $ putStrLn $ "setting up database with " ++ show num ++ " items"
+	initDb db SQL.createTables
+	h <- liftIO $ H.openDbQueue db SQL.containedTable
+	liftIO $ populateAssociatedFiles h num
+	sz <- liftIO $ getFileSize db
+	liftIO $ putStrLn $ "size of database on disk: " ++ 
+		roughSize storageUnits False sz
+	mv <- liftIO $ newMVar 1
+	return (BenchDb h num mv)
+  where
+	db = tmpdir P.</> toRawFilePath (show num </> "db")
+
+#endif /* WITH_BENCHMARK */
diff --git a/Database/ContentIdentifier.hs b/Database/ContentIdentifier.hs
new file mode 100644
index 0000000000..bbf67dcfb1
--- /dev/null
+++ b/Database/ContentIdentifier.hs
@@ -0,0 +1,194 @@
+{- Sqlite database of ContentIdentifiers imported from special remotes.
+ -
+ - Copyright 2019-2023 Joey Hess <id@joeyh.name>
+ -:
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE QuasiQuotes, TypeFamilies, TypeOperators, TemplateHaskell #-}
+{-# LANGUAGE OverloadedStrings, GADTs, FlexibleContexts, EmptyDataDecls #-}
+{-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE DataKinds, FlexibleInstances #-}
+{-# LANGUAGE UndecidableInstances #-}
+#if MIN_VERSION_persistent_template(2,8,0)
+{-# LANGUAGE DerivingStrategies #-}
+{-# LANGUAGE StandaloneDeriving #-}
+#endif
+
+module Database.ContentIdentifier (
+	ContentIdentifierHandle,
+	databaseIsEmpty,
+	openDb,
+	closeDb,
+	flushDbQueue,
+	recordContentIdentifier,
+	getContentIdentifiers,
+	getContentIdentifierKeys,
+	recordAnnexBranchTree,
+	getAnnexBranchTree,
+	needsUpdateFromLog,
+	updateFromLog,
+	ContentIdentifiersId,
+	AnnexBranchId,
+) where
+
+import Database.Types
+import qualified Database.Queue as H
+import Database.Init
+import Database.Utility
+import Annex.Locations
+import Annex.Common hiding (delete)
+import qualified Annex.Branch
+import Types.Import
+import Types.RemoteState
+import Git.Types
+import Git.Sha
+import Git.FilePath
+import qualified Git.DiffTree as DiffTree
+import Logs
+import qualified Logs.ContentIdentifier as Log
+import qualified Utility.RawFilePath as R
+
+import Database.Persist.Sql hiding (Key)
+import Database.Persist.TH
+import qualified System.FilePath.ByteString as P
+
+#if MIN_VERSION_persistent_sqlite(2,13,3)
+import Database.RawFilePath
+#else
+import Database.Persist.Sqlite (runSqlite)
+import qualified Data.Text as T
+#endif
+
+data ContentIdentifierHandle = ContentIdentifierHandle H.DbQueue Bool
+
+databaseIsEmpty :: ContentIdentifierHandle -> Bool
+databaseIsEmpty (ContentIdentifierHandle _ b) = b
+
+-- Note on indexes: ContentIndentifiersKeyRemoteCidIndex etc are really
+-- uniqueness constraints, which cause sqlite to automatically add indexes.
+-- So when adding indexes, have to take care to only add ones that work as
+-- uniqueness constraints. (Unfortunately persistent does not support indexes
+-- that are not uniqueness constraints; 
+-- https://github.com/yesodweb/persistent/issues/109)
+-- 
+-- ContentIndentifiersKeyRemoteCidIndex speeds up queries like 
+-- getContentIdentifiers, but it is not used for
+-- getContentIdentifierKeys. ContentIndentifiersCidRemoteKeyIndex was
+-- addedto speed that up.
+share [mkPersist sqlSettings, mkMigrate "migrateContentIdentifier"] [persistLowerCase|
+ContentIdentifiers
+  remote UUID
+  cid ContentIdentifier
+  key Key
+  ContentIndentifiersKeyRemoteCidIndex key remote cid
+  ContentIndentifiersCidRemoteKeyIndex cid remote key
+-- The last git-annex branch tree sha that was used to update
+-- ContentIdentifiers
+AnnexBranch
+  tree SSha
+  UniqueTree tree
+|]
+
+{- Opens the database, creating it if it doesn't exist yet.
+ -
+ - Only a single process should write to the database at a time, so guard
+ - any writes with the gitAnnexContentIdentifierLock.
+ -}
+openDb :: Annex ContentIdentifierHandle
+openDb = do
+	dbdir <- calcRepo' gitAnnexContentIdentifierDbDir
+	let db = dbdir P.</> "db"
+	isnew <- liftIO $ not <$> R.doesPathExist db
+	if isnew
+		then initDb db $ void $ 
+			runMigrationSilent migrateContentIdentifier
+		-- Migrate from old versions of database, which had buggy
+		-- and suboptimal uniqueness constraints.
+#if MIN_VERSION_persistent_sqlite(2,13,3)
+		else liftIO $ runSqlite' db $ void $
+			runMigrationSilent migrateContentIdentifier
+#else
+		else liftIO $ runSqlite (T.pack (fromRawFilePath db)) $ void $
+			runMigrationSilent migrateContentIdentifier
+#endif
+	h <- liftIO $ H.openDbQueue db "content_identifiers"
+	return $ ContentIdentifierHandle h isnew
+
+closeDb :: ContentIdentifierHandle -> Annex ()
+closeDb (ContentIdentifierHandle h _) = liftIO $ H.closeDbQueue h
+
+queueDb :: ContentIdentifierHandle -> SqlPersistM () -> IO ()
+queueDb (ContentIdentifierHandle h _) = H.queueDb h checkcommit
+  where
+	-- commit queue after 1000 changes
+	checkcommit sz _lastcommittime
+		| sz > 1000 = return True
+		| otherwise = return False
+
+flushDbQueue :: ContentIdentifierHandle -> IO ()
+flushDbQueue (ContentIdentifierHandle h _) = H.flushDbQueue h
+
+-- Be sure to also update the git-annex branch when using this.
+recordContentIdentifier :: ContentIdentifierHandle -> RemoteStateHandle -> ContentIdentifier -> Key -> IO ()
+recordContentIdentifier h (RemoteStateHandle u) cid k = queueDb h $ do
+	void $ insertUniqueFast $ ContentIdentifiers u cid k
+
+getContentIdentifiers :: ContentIdentifierHandle -> RemoteStateHandle -> Key -> IO [ContentIdentifier]
+getContentIdentifiers (ContentIdentifierHandle h _) (RemoteStateHandle u) k = 
+	H.queryDbQueue h $ do
+		l <- selectList
+			[ ContentIdentifiersKey ==. k
+			, ContentIdentifiersRemote ==. u
+			] []
+		return $ map (contentIdentifiersCid . entityVal) l
+
+getContentIdentifierKeys :: ContentIdentifierHandle -> RemoteStateHandle -> ContentIdentifier -> IO [Key]
+getContentIdentifierKeys (ContentIdentifierHandle h _) (RemoteStateHandle u) cid = 
+	H.queryDbQueue h $ do
+		l <- selectList
+			[ ContentIdentifiersCid ==. cid
+			, ContentIdentifiersRemote ==. u
+			] []
+		return $ map (contentIdentifiersKey . entityVal) l
+
+recordAnnexBranchTree :: ContentIdentifierHandle -> Sha -> IO ()
+recordAnnexBranchTree h s = queueDb h $ do
+	deleteWhere ([] :: [Filter AnnexBranch])
+	void $ insertUniqueFast $ AnnexBranch $ toSSha s
+
+getAnnexBranchTree :: ContentIdentifierHandle -> IO Sha
+getAnnexBranchTree (ContentIdentifierHandle h _) = H.queryDbQueue h $ do
+	l <- selectList ([] :: [Filter AnnexBranch]) []
+	case l of
+		(s:[]) -> return $ fromSSha $ annexBranchTree $ entityVal s
+		_ -> return emptyTree
+
+{- Check if the git-annex branch has been updated and the database needs
+ - to be updated with any new content identifiers in it. -}
+needsUpdateFromLog :: ContentIdentifierHandle -> Annex (Maybe (Sha, Sha))
+needsUpdateFromLog db = do
+	oldtree <- liftIO $ getAnnexBranchTree db
+	Annex.Branch.updatedFromTree oldtree
+
+{- The database should be locked for write when calling this. -}
+updateFromLog :: ContentIdentifierHandle -> (Sha, Sha) -> Annex ContentIdentifierHandle
+updateFromLog db@(ContentIdentifierHandle h _) (oldtree, currtree) = do
+	(l, cleanup) <- inRepo $
+		DiffTree.diffTreeRecursive oldtree currtree
+	mapM_ go l
+	void $ liftIO $ cleanup
+	liftIO $ do
+		recordAnnexBranchTree db currtree
+		flushDbQueue db
+	return (ContentIdentifierHandle h False)
+  where
+	go ti = case extLogFileKey remoteContentIdentifierExt (getTopFilePath (DiffTree.file ti)) of
+		Nothing -> return ()
+		Just k -> do
+			l <- Log.getContentIdentifiers k
+			liftIO $ forM_ l $ \(rs, cids) ->
+				forM_ cids $ \cid ->
+					recordContentIdentifier db rs cid k
diff --git a/Database/Export.hs b/Database/Export.hs
new file mode 100644
index 0000000000..2f0da8b231
--- /dev/null
+++ b/Database/Export.hs
@@ -0,0 +1,330 @@
+{- Sqlite database used for exports to special remotes.
+ -
+ - Copyright 2017-2019 Joey Hess <id@joeyh.name>
+ -:
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE QuasiQuotes, TypeFamilies, TypeOperators, TemplateHaskell #-}
+{-# LANGUAGE OverloadedStrings, GADTs, FlexibleContexts #-}
+{-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE DataKinds, FlexibleInstances #-}
+{-# LANGUAGE UndecidableInstances #-}
+#if MIN_VERSION_persistent_template(2,8,0)
+{-# LANGUAGE DerivingStrategies #-}
+{-# LANGUAGE StandaloneDeriving #-}
+#endif
+
+module Database.Export (
+	ExportHandle,
+	openDb,
+	closeDb,
+	writeLockDbWhile,
+	flushDbQueue,
+	addExportedLocation,
+	removeExportedLocation,
+	getExportedLocation,
+	isExportDirectoryEmpty,
+	getExportTreeCurrent,
+	recordExportTreeCurrent,
+	getExportTree,
+	getExportTreeKey,
+	addExportTree,
+	removeExportTree,
+	updateExportTree,
+	updateExportTree',
+	updateExportTreeFromLog,
+	updateExportDb,
+	ExportedId,
+	ExportedDirectoryId,
+	ExportTreeId,
+	ExportTreeCurrentId,
+	ExportUpdateResult(..),
+	ExportDiffUpdater,
+	runExportDiffUpdater,
+) where
+
+import Database.Types
+import qualified Database.Queue as H
+import Database.Init
+import Database.Utility
+import Annex.Locations
+import Annex.Common hiding (delete)
+import Types.Export
+import Annex.Export
+import qualified Logs.Export as Log
+import Annex.LockFile
+import Annex.LockPool
+import Git.Types
+import Git.Sha
+import Git.FilePath
+import qualified Git.DiffTree
+import qualified Utility.RawFilePath as R
+
+import Database.Persist.Sql hiding (Key)
+import Database.Persist.TH
+import qualified System.FilePath.ByteString as P
+
+data ExportHandle = ExportHandle H.DbQueue UUID
+
+share [mkPersist sqlSettings, mkMigrate "migrateExport"] [persistLowerCase|
+-- Files that have been exported to the remote and are present on it.
+Exported
+  key Key
+  file SByteString
+  ExportedIndex key file
+-- Directories that exist on the remote, and the files that are in them.
+ExportedDirectory
+  subdir SByteString
+  file SByteString
+  ExportedDirectoryIndex subdir file
+-- The content of the tree that has been exported to the remote.
+-- Not all of these files are necessarily present on the remote yet.
+ExportTree
+  key Key
+  file SByteString
+  ExportTreeKeyFileIndex key file
+  ExportTreeFileKeyIndex file key
+-- The tree stored in ExportTree
+ExportTreeCurrent
+  tree SSha
+  UniqueTree tree
+|]
+
+{- Opens the database, creating it if it doesn't exist yet.
+ -
+ - Only a single process should write to the export at a time, so guard
+ - any writes with the gitAnnexExportLock.
+ -}
+openDb :: UUID -> Annex ExportHandle
+openDb u = do
+	dbdir <- calcRepo' (gitAnnexExportDbDir u)
+	let db = dbdir P.</> "db"
+	unlessM (liftIO $ R.doesPathExist db) $ do
+		initDb db $ void $
+			runMigrationSilent migrateExport
+	h <- liftIO $ H.openDbQueue db "exported"
+	return $ ExportHandle h u
+
+closeDb :: ExportHandle -> Annex ()
+closeDb (ExportHandle h _) = liftIO $ H.closeDbQueue h
+
+queueDb :: ExportHandle -> SqlPersistM () -> IO ()
+queueDb (ExportHandle h _) = H.queueDb h checkcommit
+  where
+	-- commit queue after 1000 changes
+	checkcommit sz _lastcommittime
+		| sz > 1000 = return True
+		| otherwise = return False
+
+flushDbQueue :: ExportHandle -> IO ()
+flushDbQueue (ExportHandle h _) = H.flushDbQueue h
+
+recordExportTreeCurrent :: ExportHandle -> Sha -> IO ()
+recordExportTreeCurrent h s = queueDb h $ do
+	deleteWhere ([] :: [Filter ExportTreeCurrent])
+	void $ insertUniqueFast $ ExportTreeCurrent $ toSSha s
+
+getExportTreeCurrent :: ExportHandle -> IO (Maybe Sha)
+getExportTreeCurrent (ExportHandle h _) = H.queryDbQueue h $ do
+	l <- selectList ([] :: [Filter ExportTreeCurrent]) []
+	case l of
+		(s:[]) -> return $ Just $ fromSSha $
+			exportTreeCurrentTree $ entityVal s
+		_ -> return Nothing
+
+addExportedLocation :: ExportHandle -> Key -> ExportLocation -> IO ()
+addExportedLocation h k el = queueDb h $ do
+	void $ insertUniqueFast $ Exported k ef
+	let edirs = map
+		(\ed -> ExportedDirectory (SByteString (fromExportDirectory ed)) ef)
+		(exportDirectories el)
+	putMany edirs
+  where
+	ef = SByteString (fromExportLocation el)
+
+removeExportedLocation :: ExportHandle -> Key -> ExportLocation -> IO ()
+removeExportedLocation h k el = queueDb h $ do
+	deleteWhere [ExportedKey ==. k, ExportedFile ==. ef]
+	let subdirs = map (SByteString . fromExportDirectory)
+		(exportDirectories el)
+	deleteWhere [ExportedDirectoryFile ==. ef, ExportedDirectorySubdir <-. subdirs]
+  where
+	ef = SByteString (fromExportLocation el)
+
+{- Note that this does not see recently queued changes. -}
+getExportedLocation :: ExportHandle -> Key -> IO [ExportLocation]
+getExportedLocation (ExportHandle h _) k = H.queryDbQueue h $ do
+	l <- selectList [ExportedKey ==. k] []
+	return $ map (mkExportLocation . (\(SByteString f) -> f) . exportedFile . entityVal) l
+
+{- Note that this does not see recently queued changes. -}
+isExportDirectoryEmpty :: ExportHandle -> ExportDirectory -> IO Bool
+isExportDirectoryEmpty (ExportHandle h _) d = H.queryDbQueue h $ do
+	l <- selectList [ExportedDirectorySubdir ==. ed] []
+	return $ null l
+  where
+	ed = SByteString $ fromExportDirectory d
+
+{- Get locations in the export that might contain a key. -}
+getExportTree :: ExportHandle -> Key -> IO [ExportLocation]
+getExportTree (ExportHandle h _) k = H.queryDbQueue h $ do
+	l <- selectList [ExportTreeKey ==. k] []
+	return $ map (mkExportLocation . (\(SByteString f) -> f) . exportTreeFile . entityVal) l
+
+{- Get keys that might be currently exported to a location.
+ -
+ - Note that this does not see recently queued changes.
+ -}
+getExportTreeKey :: ExportHandle -> ExportLocation -> IO [Key]
+getExportTreeKey (ExportHandle h _) el = H.queryDbQueue h $ do
+	map (exportTreeKey . entityVal) 
+		<$> selectList [ExportTreeFile ==. ef] []
+  where
+	ef = SByteString (fromExportLocation el)
+
+addExportTree :: ExportHandle -> Key -> ExportLocation -> IO ()
+addExportTree h k loc = queueDb h $
+	void $ insertUniqueFast $ ExportTree k ef
+  where
+	ef = SByteString (fromExportLocation loc)
+
+removeExportTree :: ExportHandle -> Key -> ExportLocation -> IO ()
+removeExportTree h k loc = queueDb h $
+	deleteWhere [ExportTreeKey ==. k, ExportTreeFile ==. ef]
+  where
+	ef = SByteString (fromExportLocation loc)
+
+-- An action that is passed the old and new values that were exported,
+-- and updates state.
+type ExportDiffUpdater
+	= ExportHandle
+	-> Maybe Key
+	-- ^ old exported key
+	-> Maybe Key
+	-- ^ new exported key
+	-> Git.DiffTree.DiffTreeItem
+	-> Annex ()
+
+mkExportDiffUpdater
+	:: (ExportHandle -> Key -> ExportLocation -> IO ())
+	-> (ExportHandle -> Key -> ExportLocation -> IO ())
+	-> ExportDiffUpdater
+mkExportDiffUpdater removeold addnew h srcek dstek i = do
+	case srcek of
+		Nothing -> return ()
+		Just k -> liftIO $ removeold h k loc
+	case dstek of
+		Nothing -> return ()
+		Just k -> liftIO $ addnew h k loc
+  where
+	loc = mkExportLocation $ getTopFilePath $ Git.DiffTree.file i
+
+runExportDiffUpdater :: ExportDiffUpdater -> ExportHandle -> Sha -> Sha -> Annex ()
+runExportDiffUpdater updater h old new = do
+	(diff, cleanup) <- inRepo $
+		Git.DiffTree.diffTreeRecursive old new
+	forM_ diff $ \i -> do
+		srcek <- getek (Git.DiffTree.srcsha i)
+		dstek <- getek (Git.DiffTree.dstsha i)
+		updater h srcek dstek i
+	void $ liftIO cleanup
+  where
+	getek sha
+		| sha `elem` nullShas = return Nothing
+		| otherwise = Just <$> exportKey sha
+
+{- Diff from the old to the new tree and update the ExportTree table. -}
+updateExportTree :: ExportHandle -> Sha -> Sha -> Annex ()
+updateExportTree = runExportDiffUpdater updateExportTree'
+
+updateExportTree' :: ExportDiffUpdater
+updateExportTree' = mkExportDiffUpdater removeExportTree addExportTree
+
+{- Diff from the old to the new tree and update all tables in the export
+ - database. Should only be used when all the files in the new tree have
+ - been verified to already be present in the export remote. -}
+updateExportDb :: ExportHandle -> Sha -> Sha -> Annex ()
+updateExportDb = runExportDiffUpdater $ mkExportDiffUpdater removeold addnew
+  where
+	removeold h k loc = liftIO $ do
+		removeExportTree h k loc
+		removeExportedLocation h k loc
+	addnew h k loc = liftIO $ do
+		addExportTree h k loc
+		addExportedLocation h k loc
+
+{- Runs an action with the database locked for write. Waits for any other
+ - writers to finish first. The queue is flushed at the end.
+ -
+ - This first updates the ExportTree table with any new information 
+ - from the git-annex branch export log.
+ -}
+writeLockDbWhile :: ExportHandle -> Annex a -> Annex a
+writeLockDbWhile db@(ExportHandle _ u) a = do
+	updatelck <- takeExclusiveLock =<< calcRepo' (gitAnnexExportUpdateLock u)
+	exlck <- calcRepo' (gitAnnexExportLock u)
+	withExclusiveLock exlck $ do
+		bracket_ (setup updatelck) cleanup a
+  where
+	setup updatelck = do
+		void $ updateExportTreeFromLog' db
+		-- flush the update so it's available immediately to
+		-- anything waiting on the updatelck
+		liftIO $ flushDbQueue db
+		liftIO $ dropLock updatelck
+	cleanup = liftIO $ flushDbQueue db
+
+data ExportUpdateResult = ExportUpdateSuccess | ExportUpdateConflict
+	deriving (Eq)
+
+{- Updates the ExportTree table with information from the
+ - git-annex branch export log.
+ -
+ - This can safely be called whether the database is locked for write or
+ - not. Either way, it will block until the update is complete.
+ -}
+updateExportTreeFromLog :: ExportHandle -> Annex ExportUpdateResult
+updateExportTreeFromLog db@(ExportHandle _ u) = do
+	-- If another process or thread is performing the update,
+	-- this will block until it's done.
+	exlck <- calcRepo' (gitAnnexExportUpdateLock u)
+	withExclusiveLock exlck $ do
+		lck <- calcRepo' (gitAnnexExportLock u)
+		-- If the database is locked by something else,
+		-- this will not run the update. But, in that case,
+		-- writeLockDbWhile is running, and has already
+		-- completed the update, so we don't need to do anything.
+		mr <- tryExclusiveLock lck $
+			updateExportTreeFromLog' db
+		case mr of
+			Just r -> return r
+			Nothing -> do
+				old <- liftIO $ fromMaybe emptyTree
+					<$> getExportTreeCurrent db
+				l <- Log.getExport u
+				return $ case Log.exportedTreeishes l of
+					[] -> ExportUpdateSuccess
+					(new:[]) 
+						| new /= old -> ExportUpdateSuccess
+						| new == old -> ExportUpdateSuccess
+					_ts -> ExportUpdateConflict
+
+{- The database should be locked when calling this. -}
+updateExportTreeFromLog' :: ExportHandle -> Annex ExportUpdateResult
+updateExportTreeFromLog' db@(ExportHandle _ u) = do
+	old <- liftIO $ fromMaybe emptyTree
+		<$> getExportTreeCurrent db
+	l <- Log.getExport u
+	case Log.exportedTreeishes l of
+		[] -> return ExportUpdateSuccess
+		(new:[]) 
+			| new /= old -> do
+				updateExportTree db old new
+				liftIO $ recordExportTreeCurrent db new
+				liftIO $ flushDbQueue db
+				return ExportUpdateSuccess
+			| new == old -> return ExportUpdateSuccess
+		_ts -> return ExportUpdateConflict
diff --git a/Database/Fsck.hs b/Database/Fsck.hs
new file mode 100644
index 0000000000..cce5528100
--- /dev/null
+++ b/Database/Fsck.hs
@@ -0,0 +1,111 @@
+{- Sqlite database used for incremental fsck. 
+ -
+ - Copyright 2015-2019 Joey Hess <id@joeyh.name>
+ -:
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE QuasiQuotes, TypeFamilies, TemplateHaskell #-}
+{-# LANGUAGE OverloadedStrings, GADTs, FlexibleContexts #-}
+{-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
+{-# LANGUAGE DataKinds, FlexibleInstances #-}
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE UndecidableInstances #-}
+{-# LANGUAGE TypeOperators #-}
+#if MIN_VERSION_persistent_template(2,8,0)
+{-# LANGUAGE DerivingStrategies #-}
+{-# LANGUAGE StandaloneDeriving #-}
+#endif
+
+module Database.Fsck (
+	FsckHandle,
+	newPass,
+	openDb,
+	closeDb,
+	addDb,
+	inDb,
+	FsckedId,
+) where
+
+import Database.Types
+import qualified Database.Queue as H
+import Database.Utility
+import Database.Init
+import Annex.Locations
+import Utility.Exception
+import Annex.Common
+import Annex.LockFile
+import qualified Utility.RawFilePath as R
+
+import Database.Persist.Sql hiding (Key)
+import Database.Persist.TH
+import Data.Time.Clock
+import qualified System.FilePath.ByteString as P
+
+data FsckHandle = FsckHandle H.DbQueue UUID
+
+{- Each key stored in the database has already been fscked as part
+ - of the latest incremental fsck pass. -}
+share [mkPersist sqlSettings, mkMigrate "migrateFsck"] [persistLowerCase|
+Fscked
+  key Key
+  FsckedKeyIndex key
+|]
+
+{- The database is removed when starting a new incremental fsck pass.
+ -
+ - (The old fsck database used before v8 is also removed here.)
+ -
+ - This may fail, if other fsck processes are currently running using the
+ - database. Removing the database in that situation would lead to crashes
+ - or unknown behavior.
+ -}
+newPass :: UUID -> Annex Bool
+newPass u = do
+	lck <- calcRepo' (gitAnnexFsckDbLock u)
+	isJust <$> tryExclusiveLock lck go
+  where
+	go = do
+		removedb =<< calcRepo' (gitAnnexFsckDbDir u)
+		removedb =<< calcRepo' (gitAnnexFsckDbDirOld u)
+	removedb = liftIO . void . tryIO . removeDirectoryRecursive . fromRawFilePath
+
+{- Opens the database, creating it if it doesn't exist yet. -}
+openDb :: UUID -> Annex FsckHandle
+openDb u = do
+	dbdir <- calcRepo' (gitAnnexFsckDbDir u)
+	let db = dbdir P.</> "db"
+	unlessM (liftIO $ R.doesPathExist db) $ do
+		initDb db $ void $
+			runMigrationSilent migrateFsck
+	lockFileCached =<< calcRepo' (gitAnnexFsckDbLock u)
+	h <- liftIO $ H.openDbQueue db "fscked"
+	return $ FsckHandle h u
+
+closeDb :: FsckHandle -> Annex ()
+closeDb (FsckHandle h u) = do
+	liftIO $ H.closeDbQueue h
+	unlockFile =<< calcRepo' (gitAnnexFsckDbLock u)
+
+addDb :: FsckHandle -> Key -> IO ()
+addDb (FsckHandle h _) k = H.queueDb h checkcommit $
+	void $ insertUniqueFast $ Fscked k
+  where
+	-- Commit queue after 1000 changes or 5 minutes, whichever comes first.
+	-- The time based commit allows for an incremental fsck to be
+	-- interrupted and not lose much work.
+	checkcommit sz lastcommittime
+		| sz > 1000 = return True
+		| otherwise = do
+			now <- getCurrentTime
+			return $ diffUTCTime now lastcommittime > 300
+
+{- Doesn't know about keys that were just added with addDb. -}
+inDb :: FsckHandle -> Key -> IO Bool
+inDb (FsckHandle h _) = H.queryDbQueue h . inDb'
+
+inDb' :: Key -> SqlPersistM Bool
+inDb' k = do
+	r <- selectList [FsckedKey ==. k] []
+	return $ not $ null r
diff --git a/Database/Handle.hs b/Database/Handle.hs
new file mode 100644
index 0000000000..a7e65e54cb
--- /dev/null
+++ b/Database/Handle.hs
@@ -0,0 +1,338 @@
+{- Persistent sqlite database handles.
+ -
+ - Copyright 2015-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeFamilies, TypeOperators #-}
+{-# LANGUAGE FlexibleContexts, OverloadedStrings, CPP #-}
+
+module Database.Handle (
+	DbHandle,
+	openDb,
+	TableName,
+	queryDb,
+	closeDb,
+	commitDb,
+	commitDb',
+) where
+
+import Utility.Exception
+import Utility.FileSystemEncoding
+import Utility.Debug
+import Utility.DebugLocks
+import Utility.InodeCache
+
+import Database.Persist.Sqlite
+import qualified Database.Sqlite as Sqlite
+import Control.Monad
+import Control.Monad.IO.Class (liftIO)
+import Control.Monad.IO.Unlift (MonadUnliftIO, withRunInIO)
+import Control.Monad.Logger (MonadLoggerIO, askLoggerIO)
+import Control.Concurrent
+import Control.Concurrent.Async
+import Control.Exception (throwIO, BlockedIndefinitelyOnMVar(..))
+import qualified Data.Text as T
+import Control.Monad.Trans.Resource (runResourceT)
+import Control.Monad.Logger (runNoLoggingT)
+import System.IO
+
+{- A DbHandle is a reference to a worker thread that communicates with
+ - the database. It has a MVar which Jobs are submitted to. 
+ - There is also an MVar which it will fill when there is a fatal error-}
+data DbHandle = DbHandle RawFilePath (Async ()) (MVar Job) (MVar String)
+
+{- Name of a table that should exist once the database is initialized. -}
+type TableName = String
+
+{- Opens the database, but does not perform any migrations. Only use
+ - once the database is known to exist and have the right tables. -}
+openDb :: RawFilePath -> TableName -> IO DbHandle
+openDb db tablename = do
+	jobs <- newEmptyMVar
+	errvar <- newEmptyMVar
+	worker <- async (workerThread db tablename jobs errvar)
+	
+	-- work around https://github.com/yesodweb/persistent/issues/474
+	liftIO $ fileEncoding stderr
+
+	return $ DbHandle db worker jobs errvar
+
+{- This is optional; when the DbHandle gets garbage collected it will
+ - auto-close. -}
+closeDb :: DbHandle -> IO ()
+closeDb (DbHandle _db worker jobs _) = do
+	debugLocks $ putMVar jobs CloseJob
+	wait worker
+
+{- Makes a query using the DbHandle. This should not be used to make
+ - changes to the database!
+ -
+ - Note that the action is not run by the calling thread, but by a
+ - worker thread. Exceptions are propigated to the calling thread.
+ -
+ - Only one action can be run at a time against a given DbHandle.
+ - If called concurrently in the same process, this will block until
+ - it is able to run.
+ -}
+queryDb :: DbHandle -> SqlPersistM a -> IO a
+queryDb (DbHandle _db _ jobs errvar) a = do
+	res <- newEmptyMVar
+	putMVar jobs $ QueryJob $
+		debugLocks $ liftIO . putMVar res =<< tryNonAsync a
+	debugLocks $ takeMVarSafe res >>= \case
+		Right r -> either throwIO return r
+		Left BlockedIndefinitelyOnMVar -> do
+			err <- takeMVar errvar
+			giveup $ "sqlite worker thread crashed: " ++ err
+
+{- Writes a change to the database.
+ -
+ - Writes can fail when another write is happening concurrently.
+ - So write failures are caught and retried.
+ -
+ - Retries repeatedly for up to 60 seconds. Part that point, it continues
+ - retrying only if the database shows signs of being modified by another
+ - process at least once each 30 seconds.
+ -}
+commitDb :: DbHandle -> SqlPersistM () -> IO ()
+commitDb h@(DbHandle db _ _ errvar) wa = 
+	robustly (commitDb' h wa) maxretries emptyDatabaseInodeCache
+  where
+	robustly a retries ic = do
+		r <- a
+		case r of
+			Right (Right _) -> return ()
+			Right (Left err) -> do
+				threadDelay briefdelay
+				retryHelper "write to" err maxretries db retries ic $ 
+					robustly a
+			Left BlockedIndefinitelyOnMVar -> do
+				err <- takeMVar errvar
+				giveup $ "sqlite worker thread crashed: " ++ err
+	
+	briefdelay = 100000 -- 1/10th second
+
+	maxretries = 300 :: Int -- 30 seconds of briefdelay
+
+commitDb' :: DbHandle -> SqlPersistM () -> IO (Either BlockedIndefinitelyOnMVar (Either SomeException ()))
+commitDb' (DbHandle _ _ jobs _) a = do
+	debug "Database.Handle" "commitDb start"
+	res <- newEmptyMVar
+	putMVar jobs $ ChangeJob $
+		debugLocks $ liftIO . putMVar res =<< tryNonAsync a
+	r <- debugLocks $ takeMVarSafe res
+	case r of
+		Right (Right ()) -> debug "Database.Handle" "commitDb done"
+		Right (Left e) -> debug "Database.Handle" ("commitDb failed: " ++ show e)
+		Left BlockedIndefinitelyOnMVar -> debug "Database.Handle" "commitDb BlockedIndefinitelyOnMVar"
+
+	return r
+
+data Job
+	= QueryJob (SqlPersistM ())
+	| ChangeJob (SqlPersistM ())
+	| CloseJob
+
+workerThread :: RawFilePath -> TableName -> MVar Job -> MVar String -> IO ()
+workerThread db tablename jobs errvar = newconn
+  where
+	newconn = do
+		v <- tryNonAsync (runSqliteRobustly tablename db loop)
+		case v of
+			Left e -> putMVar errvar (show e)
+			Right cont -> cont
+	
+	loop = do
+		job <- liftIO (takeMVarSafe jobs)
+		case job of
+			-- Exception is thrown when the MVar is garbage
+			-- collected, which means the whole DbHandle
+			-- is not used any longer. Shutdown cleanly.
+			Left BlockedIndefinitelyOnMVar -> return (return ())
+			Right CloseJob -> return (return ())
+			Right (QueryJob a) -> a >> loop
+			Right (ChangeJob a) -> do
+				a
+				-- Exit the sqlite connection so the
+				-- database gets updated on disk.
+				return newconn
+
+{- Like runSqlite, but more robust.
+ -
+ - New database connections can sometimes take a while to become usable,
+ - and selects will fail with ErrorBusy in the meantime. This may be due to
+ - WAL mode recovering after a crash, or a concurrent writer.
+ - So, wait until a select succeeds; once one succeeds the connection will
+ - stay usable.
+ -
+ - Also sqlite sometimes throws ErrorIO when there's not really an IO
+ - problem, but perhaps just a short read(). So also retry on ErrorIO.
+ -
+ - Retries repeatedly for up to 60 seconds. Part that point, it continues
+ - retrying only if the database shows signs of being modified by another
+ - process at least once each 30 seconds.
+ -}
+runSqliteRobustly :: TableName -> RawFilePath -> (SqlPersistM a) -> IO a
+runSqliteRobustly tablename db a = do
+	conn <- opensettle maxretries emptyDatabaseInodeCache
+	go conn maxretries emptyDatabaseInodeCache
+  where
+	go conn retries ic = do
+		r <- try $ runResourceT $ runNoLoggingT $
+			withSqlConnRobustly db (wrapConnection conn) $
+				runSqlConn a
+		case r of
+			Right v -> return v
+			Left ex@(Sqlite.SqliteException { Sqlite.seError = e })
+				| e == Sqlite.ErrorIO -> do
+					briefdelay
+					retryHelper "access" ex maxretries db retries ic $
+						go conn
+				| otherwise -> rethrow $ errmsg "after successful open" ex
+	
+	opensettle retries ic = do
+#if MIN_VERSION_persistent_sqlite(2,13,3)
+		conn <- Sqlite.open' db
+#else
+		conn <- Sqlite.open (T.pack (fromRawFilePath db))
+#endif
+		settle conn retries ic
+
+	settle conn retries ic = do
+		r <- try $ do
+			stmt <- Sqlite.prepare conn nullselect
+			void $ Sqlite.step stmt
+			void $ Sqlite.finalize stmt
+		case r of
+			Right _ -> return conn
+			Left ex@(Sqlite.SqliteException { Sqlite.seError = e })
+				| e == Sqlite.ErrorBusy || e == Sqlite.ErrorIO -> do
+					when (e == Sqlite.ErrorIO) $
+						Sqlite.close conn
+					briefdelay
+					retryHelper "open" ex maxretries db retries ic $
+						if e == Sqlite.ErrorIO
+							then opensettle
+							else settle conn
+				| otherwise -> rethrow $ errmsg "while opening database connection" ex
+	
+	-- This should succeed for any table.
+	nullselect = T.pack $ "SELECT null from " ++ tablename ++ " limit 1"
+
+	briefdelay = threadDelay 1000 -- 1/1000th second
+	
+	maxretries = 30000 :: Int -- 30 seconds of briefdelays
+	
+	rethrow = throwIO . userError
+
+	errmsg msg e = show e ++ "(" ++ msg ++ ")"
+
+-- Like withSqlConn, but more robust.
+withSqlConnRobustly
+	:: (MonadUnliftIO m
+		, MonadLoggerIO m
+		, IsPersistBackend backend
+		, BaseBackend backend ~ SqlBackend
+		, BackendCompatible SqlBackend backend
+	    )
+	=> RawFilePath
+	-> (LogFunc -> IO backend)
+	-> (backend -> m a)
+	-> m a
+withSqlConnRobustly db open f = do
+	logFunc <- askLoggerIO
+	withRunInIO $ \run -> bracket
+		(open logFunc)
+		(closeRobustly db)
+		(run . f)
+
+{- Sqlite can throw ErrorBusy while closing a database; this catches
+ - the exception and retries.
+ -
+ - Retries repeatedly for up to 60 seconds. Part that point, it continues
+ - retrying only if the database shows signs of being modified by another
+ - process at least once each 30 seconds.
+ -}
+closeRobustly
+	:: (IsPersistBackend backend
+		, BaseBackend backend ~ SqlBackend
+		, BackendCompatible SqlBackend backend
+	   )
+	=> RawFilePath
+	-> backend
+	-> IO ()
+closeRobustly db conn = go maxretries emptyDatabaseInodeCache
+  where
+	go retries ic = do
+		r <- try $ close' conn
+		case r of
+			Right () -> return ()
+			Left ex@(Sqlite.SqliteException { Sqlite.seError = e })
+				| e == Sqlite.ErrorBusy -> do
+					threadDelay briefdelay
+					retryHelper "close" ex maxretries db retries ic go
+				| otherwise -> rethrow $ errmsg "while closing database connection" ex
+	
+	briefdelay = 1000 -- 1/1000th second
+	
+	maxretries = 30000 :: Int -- 30 seconds of briefdelays
+	
+	rethrow = throwIO . userError
+
+	errmsg msg e = show e ++ "(" ++ msg ++ ")"
+
+{- Retries a sqlite action repeatedly, but not forever. Detects situations
+ - when another git-annex process is suspended and has the database locked,
+ - and eventually gives up. The retries is the current number of retries
+ - that are left. The maxretries is how many retries to make each time
+ - the database is seen to have been modified by some other process.
+ -}
+retryHelper
+	:: Show err 
+	=> String
+	-> err
+	-> Int
+	-> RawFilePath
+	-> Int
+	-> DatabaseInodeCache
+	-> (Int -> DatabaseInodeCache -> IO a)
+	-> IO a
+retryHelper action err maxretries db retries ic a = do
+	let retries' = retries - 1
+	if retries' < 1
+		then do
+			ic' <- getDatabaseInodeCache db
+			if isDatabaseModified ic ic'
+				then a maxretries ic'
+				else giveup (databaseAccessStalledMsg action db err)
+		else a retries' ic
+
+databaseAccessStalledMsg :: Show err => String -> RawFilePath -> err -> String
+databaseAccessStalledMsg action db err =
+	"Repeatedly unable to " ++ action ++ " sqlite database " ++ fromRawFilePath db 
+		++ ": " ++ show err ++ ". "
+		++ "Perhaps another git-annex process is suspended and is "
+		++ "keeping this database locked?"
+
+data DatabaseInodeCache = DatabaseInodeCache (Maybe InodeCache) (Maybe InodeCache)
+
+emptyDatabaseInodeCache :: DatabaseInodeCache
+emptyDatabaseInodeCache = DatabaseInodeCache Nothing Nothing
+
+getDatabaseInodeCache :: RawFilePath -> IO DatabaseInodeCache
+getDatabaseInodeCache db = DatabaseInodeCache
+	<$> genInodeCache db noTSDelta
+	<*> genInodeCache (db <> "-wal") noTSDelta
+
+isDatabaseModified :: DatabaseInodeCache -> DatabaseInodeCache -> Bool
+isDatabaseModified (DatabaseInodeCache a1 b1) (DatabaseInodeCache a2 b2) = 
+	ismodified a1 a2 || ismodified b1 b2
+  where
+	ismodified (Just a) (Just b) = not (compareStrong a b)
+	ismodified Nothing Nothing = False
+	ismodified _ _ = True
+
+takeMVarSafe :: MVar a -> IO (Either BlockedIndefinitelyOnMVar a)
+takeMVarSafe = try . takeMVar
diff --git a/Database/ImportFeed.hs b/Database/ImportFeed.hs
new file mode 100644
index 0000000000..2d44b0b9ea
--- /dev/null
+++ b/Database/ImportFeed.hs
@@ -0,0 +1,211 @@
+{- Sqlite database of known urls, and another of known itemids,
+ - for use by git-annex importfeed.
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -:
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE QuasiQuotes, TypeFamilies, TypeOperators, TemplateHaskell #-}
+{-# LANGUAGE OverloadedStrings, GADTs, FlexibleContexts, EmptyDataDecls #-}
+{-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE DataKinds, FlexibleInstances #-}
+{-# LANGUAGE UndecidableInstances #-}
+#if MIN_VERSION_persistent_template(2,8,0)
+{-# LANGUAGE DerivingStrategies #-}
+{-# LANGUAGE StandaloneDeriving #-}
+#endif
+
+module Database.ImportFeed (
+	ImportFeedDbHandle,
+	openDb,
+	closeDb,
+	isKnownUrl,
+	isKnownItemId,
+) where
+
+import Database.Types
+import qualified Database.Queue as H
+import Database.Init
+import Database.Utility
+import Annex.Locations
+import Annex.Common hiding (delete)
+import qualified Annex.Branch
+import Git.Types
+import Git.Sha
+import Git.FilePath
+import qualified Git.DiffTree as DiffTree
+import Logs
+import Logs.Web
+import Logs.MetaData
+import Types.MetaData
+import Annex.MetaData.StandardFields
+import Annex.LockFile
+import qualified Utility.RawFilePath as R
+
+import Database.Persist.Sql hiding (Key)
+import Database.Persist.TH
+import qualified System.FilePath.ByteString as P
+import qualified Data.ByteString as B
+import qualified Data.Set as S
+
+data ImportFeedDbHandle = ImportFeedDbHandle H.DbQueue
+
+-- Note on indexes: ContentIndentifiersKeyRemoteCidIndex etc are really
+-- uniqueness constraints, which cause sqlite to automatically add indexes.
+-- So when adding indexes, have to take care to only add ones that work as
+-- uniqueness constraints. (Unfortunately persistent does not support indexes
+-- that are not uniqueness constraints; 
+-- https://github.com/yesodweb/persistent/issues/109)
+share [mkPersist sqlSettings, mkMigrate "migrateImportFeed"] [persistLowerCase|
+KnownUrls
+  url SByteString
+  UniqueUrl url
+KnownItemIds
+  itemid SByteString
+  UniqueItemId itemid
+-- The last git-annex branch tree sha that was used to update
+-- KnownUrls and KnownItemIds
+AnnexBranch
+  tree SSha
+  UniqueTree tree
+|]
+
+{- Opens the database, creating it if it doesn't exist yet.
+ - Updates the database from the git-annex branch. -}
+openDb :: Annex ImportFeedDbHandle
+openDb = do
+	dbdir <- calcRepo' gitAnnexImportFeedDbDir
+	let db = dbdir P.</> "db"
+	isnew <- liftIO $ not <$> R.doesPathExist db
+	when isnew $
+		initDb db $ void $ 
+			runMigrationSilent migrateImportFeed
+	dbh <- liftIO $ H.openDbQueue db "known_urls"
+	let h = ImportFeedDbHandle dbh
+	needsUpdateFromLog h >>= \case
+		Nothing -> return ()
+		Just v -> do
+			lck <- calcRepo' gitAnnexImportFeedDbLock
+                	withExclusiveLock lck $
+				updateFromLog h v
+	return h
+
+closeDb :: ImportFeedDbHandle -> Annex ()
+closeDb (ImportFeedDbHandle h) = liftIO $ H.closeDbQueue h
+
+isKnownUrl :: ImportFeedDbHandle -> URLString -> IO Bool
+isKnownUrl (ImportFeedDbHandle h) u = 
+	H.queryDbQueue h $ do
+		l <- selectList
+			[ KnownUrlsUrl ==. SByteString (encodeBS u)
+			] []
+		return $ not (null l)
+
+isKnownItemId :: ImportFeedDbHandle -> B.ByteString -> IO Bool
+isKnownItemId (ImportFeedDbHandle h) i = 
+	H.queryDbQueue h $ do
+		l <- selectList
+			[ KnownItemIdsItemid ==. SByteString i
+			] []
+		return $ not (null l)
+
+recordKnownUrl :: ImportFeedDbHandle -> URLByteString -> IO ()
+recordKnownUrl h u = queueDb h $
+	void $ insertUniqueFast $ KnownUrls $ SByteString u
+
+recordKnownItemId :: ImportFeedDbHandle -> SByteString -> IO ()
+recordKnownItemId h i = queueDb h $
+	void $ insertUniqueFast $ KnownItemIds i
+
+recordAnnexBranchTree :: ImportFeedDbHandle -> Sha -> IO ()
+recordAnnexBranchTree h s = queueDb h $ do
+	deleteWhere ([] :: [Filter AnnexBranch])
+	void $ insertUniqueFast $ AnnexBranch $ toSSha s
+
+getAnnexBranchTree :: ImportFeedDbHandle -> IO Sha
+getAnnexBranchTree (ImportFeedDbHandle h) = H.queryDbQueue h $ do
+	l <- selectList ([] :: [Filter AnnexBranch]) []
+	case l of
+		(s:[]) -> return $ fromSSha $ annexBranchTree $ entityVal s
+		_ -> return emptyTree
+
+queueDb :: ImportFeedDbHandle -> SqlPersistM () -> IO ()
+queueDb (ImportFeedDbHandle h) = H.queueDb h checkcommit
+  where
+        -- commit queue after 10000 changes
+        checkcommit sz _lastcommittime
+                | sz > 10000 = return True
+                | otherwise = return False
+
+{- Check if the git-annex branch has been updated and the database needs
+ - to be updated with any new information from it. -}
+needsUpdateFromLog :: ImportFeedDbHandle -> Annex (Maybe (Sha, Sha))
+needsUpdateFromLog db = do
+	oldtree <- liftIO $ getAnnexBranchTree db
+	Annex.Branch.updatedFromTree oldtree
+
+{- The database should be locked for write when calling this. -}
+updateFromLog :: ImportFeedDbHandle -> (Sha, Sha) -> Annex ()
+updateFromLog db@(ImportFeedDbHandle h) (oldtree, currtree)
+	| oldtree == emptyTree = do
+		scanbranch
+		out
+	| otherwise = do
+		scandiff
+		out
+  where
+  	out = liftIO $ do
+		recordAnnexBranchTree db currtree
+		H.flushDbQueue h
+	
+	knownitemids s = liftIO $ forM_ (S.toList s) $
+		recordKnownItemId db . SByteString . fromMetaValue
+
+	knownurls us = liftIO $ forM_ us $
+		recordKnownUrl db
+		
+	scandiff = do
+		(l, cleanup) <- inRepo $
+			DiffTree.diffTreeRecursive oldtree currtree
+		mapM_ godiff l
+		void $ liftIO $ cleanup
+	
+	godiff ti = do
+		let f = getTopFilePath (DiffTree.file ti)
+		case extLogFileKey urlLogExt f of
+			Just k -> do
+				knownurls =<< getUrls' k
+			Nothing -> case extLogFileKey metaDataLogExt f of
+				Just k -> do
+					m <- getCurrentMetaData k
+					knownitemids (currentMetaDataValues itemIdField m)
+				Nothing -> return ()
+
+	-- When initially populating the database, this 
+	-- is faster than diffing from the empty tree
+	-- and looking up every log file.
+	scanbranch = Annex.Branch.overBranchFileContents toscan goscan >>= \case
+		Just () -> return ()
+		Nothing -> scandiff
+	
+	toscan f
+		| isUrlLog f = Just ()
+		| isMetaDataLog f = Just ()
+		| otherwise = Nothing
+	
+	goscan reader = reader >>= \case
+		Just ((), f, Just content)
+			| isUrlLog f -> do
+				knownurls (parseUrlLog content)
+				goscan reader
+			| isMetaDataLog f -> do
+				knownitemids $
+					currentMetaDataValues itemIdField $
+						parseCurrentMetaData content
+				goscan reader
+			| otherwise -> goscan reader
+		Just ((), _, Nothing) -> goscan reader
+		Nothing -> return ()
diff --git a/Database/Init.hs b/Database/Init.hs
new file mode 100644
index 0000000000..6f7ba09faf
--- /dev/null
+++ b/Database/Init.hs
@@ -0,0 +1,64 @@
+{- Persistent sqlite database initialization
+ -
+ - Copyright 2015-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, CPP #-}
+
+module Database.Init where
+
+import Annex.Common
+import Annex.Perms
+import Utility.FileMode
+import qualified Utility.RawFilePath as R
+#if MIN_VERSION_persistent_sqlite(2,13,3)
+import Database.RawFilePath
+#endif
+
+import Database.Persist.Sqlite
+import Lens.Micro
+import qualified Data.Text as T
+import qualified System.FilePath.ByteString as P
+
+{- Ensures that the database is freshly initialized. Deletes any
+ - existing database. Pass the migration action for the database.
+ -
+ - The permissions of the database are set based on the
+ - core.sharedRepository setting. Setting these permissions on the main db
+ - file causes Sqlite to always use the same permissions for additional
+ - files it writes later on
+ -}
+initDb :: P.RawFilePath -> SqlPersistM () -> Annex ()
+initDb db migration = do
+	let dbdir = P.takeDirectory db
+	let tmpdbdir = dbdir <> ".tmp"
+	let tmpdb = tmpdbdir P.</> "db"
+	let tmpdb' = T.pack (fromRawFilePath tmpdb)
+	createAnnexDirectory tmpdbdir
+#if MIN_VERSION_persistent_sqlite(2,13,3)
+	liftIO $ runSqliteInfo' tmpdb (enableWAL tmpdb') migration
+#else
+	liftIO $ runSqliteInfo (enableWAL tmpdb') migration
+#endif
+	setAnnexDirPerm tmpdbdir
+	-- Work around sqlite bug that prevents it from honoring
+	-- less restrictive umasks.
+	liftIO $ R.setFileMode tmpdb =<< defaultFileMode
+	setAnnexFilePerm tmpdb
+	liftIO $ do
+		void $ tryIO $ removeDirectoryRecursive (fromRawFilePath dbdir)
+		R.rename tmpdbdir dbdir
+
+{- Make sure that the database uses WAL mode, to prevent readers
+ - from blocking writers, and prevent a writer from blocking readers.
+ -
+ - This is the default in recent persistent-sqlite versions, but 
+ - force it on just in case. 
+ -
+ - Note that once WAL mode is enabled, it will persist whenever the
+ - database is opened. -}
+enableWAL :: T.Text -> SqliteConnectionInfo
+enableWAL db = over walEnabled (const True) $ 
+	mkSqliteConnectionInfo db
diff --git a/Database/Keys.hs b/Database/Keys.hs
new file mode 100644
index 0000000000..788bf0a842
--- /dev/null
+++ b/Database/Keys.hs
@@ -0,0 +1,517 @@
+{- Sqlite database of information about Keys
+ -
+ - Copyright 2015-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE ScopedTypeVariables #-}
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE BangPatterns #-}
+
+module Database.Keys (
+	DbHandle,
+	closeDb,
+	flushDb,
+	addAssociatedFile,
+	getAssociatedFiles,
+	getAssociatedFilesIncluding,
+	getAssociatedKey,
+	removeAssociatedFile,
+	storeInodeCaches,
+	addInodeCaches,
+	getInodeCaches,
+	removeInodeCaches,
+	removeInodeCache,
+	isInodeKnown,
+	runWriter,
+	updateDatabase,
+) where
+
+import qualified Database.Keys.SQL as SQL
+import Database.Types
+import Database.Keys.Handle
+import Database.Keys.Tables
+import qualified Database.Queue as H
+import Database.Init
+import Annex.Locations
+import Annex.Common hiding (delete)
+import qualified Annex
+import Annex.LockFile
+import Annex.Content.PointerFile
+import Annex.Content.Presence.LowLevel
+import Annex.Link (Restage(..), maxPointerSz, parseLinkTargetOrPointerLazy)
+import Utility.InodeCache
+import Annex.InodeSentinal
+import Git
+import Git.FilePath
+import Git.Command
+import Git.Types
+import Git.Index
+import Git.Sha
+import Git.CatFile
+import Git.Branch (writeTreeQuiet, update')
+import qualified Git.Ref
+import Config
+import Config.Smudge
+import qualified Utility.RawFilePath as R
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as S8
+import qualified System.FilePath.ByteString as P
+import Control.Concurrent.Async
+
+{- Runs an action that reads from the database.
+ -
+ - If the database is already open, any writes are flushed to it, to ensure
+ - consistency.
+ -
+ - Any queued writes to the table will be flushed before the read.
+ -}
+runReader :: Monoid v => DbTable -> (SQL.ReadHandle -> Annex v) -> Annex v
+runReader t a = do
+	h <- Annex.getRead Annex.keysdbhandle
+	withDbState h go
+  where
+	go DbUnavailable = return (mempty, DbUnavailable)
+	go (DbOpen (qh, tableschanged)) = do
+		tableschanged' <- if isDbTableChanged tableschanged t
+			then do
+				liftIO $ H.flushDbQueue qh
+				return mempty
+			else return tableschanged
+		v <- a (SQL.ReadHandle qh)
+		return (v, DbOpen (qh, tableschanged'))
+	go DbClosed = do
+		st <- openDb False DbClosed
+		v <- case st of
+			(DbOpen (qh, _)) -> a (SQL.ReadHandle qh)
+			_ -> return mempty
+		return (v, st)
+
+runReaderIO :: Monoid v => DbTable -> (SQL.ReadHandle -> IO v) -> Annex v
+runReaderIO t a = runReader t (liftIO . a)
+
+{- Runs an action that writes to the database. Typically this is used to
+ - queue changes, which will be flushed at a later point.
+ -
+ - The database is created if it doesn't exist yet. -}
+runWriter :: DbTable -> (SQL.WriteHandle -> Annex ()) -> Annex ()
+runWriter t a = do
+	h <- Annex.getRead Annex.keysdbhandle
+	withDbState h go
+  where
+	go (DbOpen (qh, tableschanged)) = do
+		v <- a (SQL.WriteHandle qh)
+		return (v, DbOpen (qh, addDbTable tableschanged t))
+	go st = do
+		st' <- openDb True st
+		v <- case st' of
+			DbOpen (qh, _) -> a (SQL.WriteHandle qh)
+			_ -> error "internal"
+		return (v, st')
+
+runWriterIO :: DbTable -> (SQL.WriteHandle -> IO ()) -> Annex ()
+runWriterIO t a = runWriter t (liftIO . a)
+
+{- Opens the database, creating it if it doesn't exist yet.
+ -
+ - Multiple readers and writers can have the database open at the same
+ - time. Database.Handle deals with the concurrency issues.
+ - The lock is held while opening the database, so that when
+ - the database doesn't exist yet, one caller wins the lock and
+ - can create it undisturbed.
+ -}
+openDb :: Bool -> DbState -> Annex DbState
+openDb _ st@(DbOpen _) = return st
+openDb False DbUnavailable = return DbUnavailable
+openDb forwrite _ = do
+	lck <- calcRepo' gitAnnexKeysDbLock
+	catchPermissionDenied permerr $ withExclusiveLock lck $ do
+		dbdir <- calcRepo' gitAnnexKeysDbDir
+		let db = dbdir P.</> "db"
+		dbexists <- liftIO $ R.doesPathExist db
+		case dbexists of
+			True -> open db False
+			False -> do
+				initDb db SQL.createTables
+				open db True
+  where
+	-- If permissions don't allow opening the database, and it's being
+	-- opened for read, treat it as if it does not exist.
+	permerr e
+		| forwrite = throwM e
+		| otherwise = return DbUnavailable
+	
+	open db dbisnew = do
+		qh <- liftIO $ H.openDbQueue db SQL.containedTable
+		tc <- reconcileStaged dbisnew qh
+		return $ DbOpen (qh, tc)
+
+{- Closes the database if it was open. Any writes will be flushed to it.
+ -
+ - This does not prevent further use of the database; it will be re-opened
+ - as necessary.
+ -}
+closeDb :: Annex ()
+closeDb = liftIO . closeDbHandle =<< Annex.getRead Annex.keysdbhandle
+
+{- Flushes any queued writes to the database. -}
+flushDb :: Annex ()
+flushDb = liftIO . flushDbQueue =<< Annex.getRead Annex.keysdbhandle
+
+addAssociatedFile :: Key -> TopFilePath -> Annex ()
+addAssociatedFile k f = runWriterIO AssociatedTable $ SQL.addAssociatedFile k f
+
+{- Note that the files returned were once associated with the key, but
+ - some of them may not be any longer. -}
+getAssociatedFiles :: Key -> Annex [TopFilePath]
+getAssociatedFiles k = emptyWhenBare $ runReaderIO AssociatedTable $
+	SQL.getAssociatedFiles k
+
+{- Queries for associated files never return anything when in a bare
+ - repository, since without a work tree there can be no associated files. 
+ -
+ - Normally the keys database is not even populated with associated files 
+ - in a bare repository, but it might happen if a non-bare repo got
+ - converted to bare. -}
+emptyWhenBare :: Annex [a] -> Annex [a]
+emptyWhenBare a = ifM isBareRepo
+	( return []
+	, a
+	)
+
+{- Include a known associated file along with any recorded in the database. -}
+getAssociatedFilesIncluding :: AssociatedFile -> Key -> Annex [RawFilePath]
+getAssociatedFilesIncluding afile k = emptyWhenBare $ do
+	g <- Annex.gitRepo
+	l <- map (`fromTopFilePath` g) <$> getAssociatedFiles k
+	return $ case afile of
+		AssociatedFile (Just f) -> f : filter (/= f) l
+		AssociatedFile Nothing -> l
+
+{- Gets any keys that are on record as having a particular associated file.
+ - (Should be one or none but the database doesn't enforce that.) -}
+getAssociatedKey :: TopFilePath -> Annex [Key]
+getAssociatedKey f = emptyWhenBare $ runReaderIO AssociatedTable $
+	SQL.getAssociatedKey f
+
+removeAssociatedFile :: Key -> TopFilePath -> Annex ()
+removeAssociatedFile k = runWriterIO AssociatedTable .
+	SQL.removeAssociatedFile k
+
+{- Stats the files, and stores their InodeCaches. -}
+storeInodeCaches :: Key -> [RawFilePath] -> Annex ()
+storeInodeCaches k fs = withTSDelta $ \d ->
+	addInodeCaches k . catMaybes
+		=<< liftIO (mapM (\f -> genInodeCache f d) fs)
+
+addInodeCaches :: Key -> [InodeCache] -> Annex ()
+addInodeCaches k is = runWriterIO ContentTable $ SQL.addInodeCaches k is
+
+{- A key may have multiple InodeCaches; one for the annex object, and one
+ - for each pointer file that is a copy of it.
+ -
+ - When there are no pointer files, the annex object typically does not
+ - have its InodeCache recorded either, so the list will be empty.
+ -
+ - Note that, in repos upgraded from v7, there may be InodeCaches recorded
+ - for pointer files, but none recorded for the annex object.
+ -}
+getInodeCaches :: Key -> Annex [InodeCache]
+getInodeCaches = runReaderIO ContentTable . SQL.getInodeCaches
+
+{- Remove all inodes cached for a key. -}
+removeInodeCaches :: Key -> Annex ()
+removeInodeCaches = runWriterIO ContentTable . SQL.removeInodeCaches
+
+{- Remove cached inodes, for any key. -}
+removeInodeCache :: InodeCache -> Annex ()
+removeInodeCache = runWriterIO ContentTable . SQL.removeInodeCache
+
+isInodeKnown :: InodeCache -> SentinalStatus -> Annex Bool
+isInodeKnown i s = or <$> runReaderIO ContentTable 
+	((:[]) <$$> SQL.isInodeKnown i s)
+
+{- Looks at staged changes to annexed files, and updates the keys database,
+ - so that its information is consistent with the state of the repository.
+ -
+ - This is run with a lock held, so only one process can be running this at
+ - a time.
+ -
+ - To avoid unnecessary work, the index file is statted, and if it's not
+ - changed since last time this was run, nothing is done.
+ -
+ - A tree is generated from the index, and the diff between that tree
+ - and the last processed tree is examined for changes.
+ -
+ - This also cleans up after a race between eg a git mv and git-annex
+ - get/drop/similar. If git moves a pointer file between this being run and the
+ - get/drop, the moved pointer file won't be updated for the get/drop. 
+ - The next time this runs, it will see the staged change. It then checks
+ - if the pointer file needs to be updated to contain or not contain the
+ - annex content.
+ -
+ - Note: There is a situation where, after this has run, the database can
+ - still contain associated files that have been deleted from the index.
+ - That happens when addAssociatedFile is used to record a newly
+ - added file, but that file then gets removed from the index before
+ - this is run. Eg, "git-annex add foo; git rm foo"
+ - So when using getAssociatedFiles, have to make sure the file still
+ - is an associated file.
+ -}
+reconcileStaged :: Bool -> H.DbQueue -> Annex DbTablesChanged
+reconcileStaged dbisnew qh = ifM isBareRepo
+	( return mempty
+	, do
+		gitindex <- inRepo currentIndexFile
+		indexcache <- fromRawFilePath <$> calcRepo' gitAnnexKeysDbIndexCache
+		withTSDelta (liftIO . genInodeCache gitindex) >>= \case
+			Just cur -> readindexcache indexcache >>= \case
+				Nothing -> go cur indexcache =<< getindextree
+				Just prev -> ifM (compareInodeCaches prev cur)
+					( return mempty
+					, go cur indexcache =<< getindextree
+					)
+			Nothing -> return mempty
+	)
+  where
+	lastindexref = Ref "refs/annex/last-index"
+
+	readindexcache indexcache = liftIO $ maybe Nothing readInodeCache
+		<$> catchMaybeIO (readFile indexcache)
+
+	getoldtree = fromMaybe emptyTree <$> inRepo (Git.Ref.sha lastindexref)
+	
+	go cur indexcache (Just newtree) = do
+		oldtree <- getoldtree
+		when (oldtree /= newtree) $ do
+			fastDebug "Database.Keys" "reconcileStaged start"
+			g <- Annex.gitRepo
+			void $ catstream $ \mdfeeder -> 
+				void $ updatetodiff g
+					(Just (fromRef oldtree)) 
+					(fromRef newtree)
+					(procdiff mdfeeder)
+			liftIO $ writeFile indexcache $ showInodeCache cur
+			-- Storing the tree in a ref makes sure it does not
+			-- get garbage collected, and is available to diff
+			-- against next time.
+			inRepo $ update' lastindexref newtree
+			fastDebug "Database.Keys" "reconcileStaged end"
+		return (DbTablesChanged True True)
+	-- git write-tree will fail if the index is locked or when there is
+	-- a merge conflict. To get up-to-date with the current index, 
+	-- diff --staged with the old index tree. The current index tree
+	-- is not known, so not recorded, and the inode cache is not updated,
+	-- so the next time git-annex runs, it will diff again, even
+	-- if the index is unchanged.
+	--
+	-- When there is a merge conflict, that will not see the new local
+	-- version of the files that are conflicted. So a second diff
+	-- is done, with --staged but no old tree.
+	go _ _ Nothing = do
+		fastDebug "Database.Keys" "reconcileStaged start (in conflict)"
+		oldtree <- getoldtree
+		g <- Annex.gitRepo
+		catstream $ \mdfeeder -> do
+			conflicted <- updatetodiff g
+				(Just (fromRef oldtree)) "--staged" (procdiff mdfeeder)
+			when conflicted $
+				void $ updatetodiff g Nothing "--staged"
+					(procmergeconflictdiff mdfeeder)
+		fastDebug "Database.Keys" "reconcileStaged end"
+		return (DbTablesChanged True True)
+	
+	updatetodiff g old new processor = do
+		(l, cleanup) <- pipeNullSplit' (diff old new) g
+		processor l False
+			`finally` void cleanup
+	
+	-- Avoid running smudge clean filter, which would block trying to
+	-- access the locked database. git write-tree sometimes calls it,
+	-- even though it is not adding work tree files to the index,
+	-- and so the filter cannot have an effect on the contents of the
+	-- index or on the tree that gets written from it.
+	getindextree = inRepo $ \r -> writeTreeQuiet $ r
+		{ gitGlobalOpts = gitGlobalOpts r ++ bypassSmudgeConfig }
+	
+	diff old new =
+		-- Avoid running smudge clean filter, since we want the
+		-- raw output, and it would block trying to access the
+		-- locked database. The --raw normally avoids git diff
+		-- running them, but older versions of git need this.
+		bypassSmudgeConfig ++
+		-- Avoid using external diff command, which would be slow.
+		-- (The -G option may make it be used otherwise.)
+		[ Param "-c", Param "diff.external="
+		, Param "diff"
+		] ++ maybeToList (Param <$> old) ++
+		[ Param new
+		, Param "--raw"
+		, Param "-z"
+		, Param "--no-abbrev"
+		-- Optimization: Limit to pointer files and annex symlinks.
+		-- This is not perfect. A file could contain this and not
+		-- be a pointer file. And a pointer file that is replaced with
+		-- a non-pointer file will match this. This is only a
+		-- prefilter so that's ok.
+		, Param $ "-G" ++ fromRawFilePath (toInternalGitPath $
+			P.pathSeparator `S.cons` objectDir)
+		-- Disable rename detection.
+		, Param "--no-renames"
+		-- Avoid other complications.
+		, Param "--ignore-submodules=all"
+		-- Avoid using external textconv command, which would be slow
+		-- and possibly wrong.
+		, Param "--no-textconv"
+		, Param "--no-ext-diff"
+		]
+	
+	procdiff mdfeeder (info:file:rest) conflicted
+		| ":" `S.isPrefixOf` info = case S8.words info of
+			(_colonsrcmode:dstmode:srcsha:dstsha:status:[]) -> do
+				let conflicted' = status == "U"
+				-- avoid removing associated file when
+				-- there is a merge conflict
+				unless conflicted' $
+					send mdfeeder (Ref srcsha) $ \case
+						Just oldkey -> do
+							liftIO $ SQL.removeAssociatedFile oldkey
+								(asTopFilePath file)
+								(SQL.WriteHandle qh)
+							return True
+						Nothing -> return False
+				send mdfeeder (Ref dstsha) $ \case
+					Just key -> do
+						liftIO $ addassociatedfile key
+							(asTopFilePath file)
+							(SQL.WriteHandle qh)
+						when (dstmode /= fmtTreeItemType TreeSymlink) $
+							reconcilepointerfile (asTopFilePath file) key
+						return True
+					Nothing -> return False
+				procdiff mdfeeder rest
+					(conflicted || conflicted')
+			_ -> return conflicted -- parse failed
+	procdiff _ _ conflicted = return conflicted
+
+	-- Processing a diff --index when there is a merge conflict.
+	-- This diff will have the new local version of a file as the
+	-- first sha, and a null sha as the second sha, and we only
+	-- care about files that are in conflict.
+	procmergeconflictdiff mdfeeder (info:file:rest) conflicted
+		| ":" `S.isPrefixOf` info = case S8.words info of
+			(_colonmode:_mode:sha:_sha:status:[]) -> do
+				send mdfeeder (Ref sha) $ \case
+					Just key -> do
+						liftIO $ SQL.addAssociatedFile key
+							(asTopFilePath file)
+							(SQL.WriteHandle qh)
+						return True
+					Nothing -> return False
+				let conflicted' = status == "U"
+				procmergeconflictdiff mdfeeder rest
+					(conflicted || conflicted')
+			_ -> return conflicted -- parse failed
+	procmergeconflictdiff _ _ conflicted = return conflicted
+
+	reconcilepointerfile file key = do
+		ics <- liftIO $ SQL.getInodeCaches key (SQL.ReadHandle qh)
+		obj <- calcRepo (gitAnnexLocation key)
+		mobjic <- withTSDelta (liftIO . genInodeCache obj)
+		let addinodecaches k v = liftIO $
+			SQL.addInodeCaches k v (SQL.WriteHandle qh)
+		-- Like inAnnex, check the annex object is unmodified
+		-- when annex.thin is set.
+		keypopulated <- ifM (annexThin <$> Annex.getGitConfig)
+			( case mobjic of
+				Just objic -> isUnmodifiedLowLevel addinodecaches key obj objic ics
+				Nothing -> pure False
+			, pure (isJust mobjic)
+			)
+		p <- fromRepo $ fromTopFilePath file
+		filepopulated <- sameInodeCache p ics
+		case (keypopulated, filepopulated) of
+			(True, False) ->
+				populatePointerFile (Restage True) key obj p >>= \case
+					Nothing -> return ()
+					Just ic -> addinodecaches key
+						(catMaybes [Just ic, mobjic])
+			(False, True) -> depopulatePointerFile key p
+			_ -> return ()
+	
+	send :: ((Maybe Key -> Annex a, Ref) -> IO ()) -> Ref -> (Maybe Key -> Annex a) -> IO ()
+	send feeder r withk = feeder (withk, r)
+
+	-- Streaming through git cat-file like this is significantly
+	-- faster than using catKey.
+	catstream a = do
+		g <- Annex.gitRepo
+		catObjectMetaDataStream g $ \mdfeeder mdcloser mdreader ->
+			catObjectStream g $ \catfeeder catcloser catreader -> do
+				feedt <- liftIO $ async $
+					a mdfeeder
+						`finally` void mdcloser
+				proct <- liftIO $ async $
+					procthread mdreader catfeeder
+						`finally` void catcloser
+				dbchanged <- dbwriter False largediff catreader
+				-- Flush database changes now
+				-- so other processes can see them.
+				when dbchanged $
+					liftIO $ H.flushDbQueue qh
+				() <- liftIO $ wait feedt
+				liftIO $ wait proct
+				return ()
+	  where
+		procthread mdreader catfeeder = mdreader >>= \case
+			Just (ka, Just (sha, size, _type))
+				| size <= fromIntegral maxPointerSz -> do
+					() <- catfeeder (ka, sha)
+					procthread mdreader catfeeder
+			Just _ -> procthread mdreader catfeeder
+			Nothing -> return ()
+
+		dbwriter dbchanged n catreader = liftIO catreader >>= \case
+			Just (ka, content) -> do
+				changed <- ka (parseLinkTargetOrPointerLazy =<< content)
+				!n' <- countdownToMessage n
+				dbwriter (dbchanged || changed) n' catreader
+			Nothing -> return dbchanged
+
+	-- When the diff is large, the scan can take a while,
+	-- so let the user know what's going on.
+	countdownToMessage n
+		| n < 1 = return 0
+		| n == 1 = do
+			showSideAction "scanning for annexed files"
+			return 0
+		| otherwise = return (pred n)
+
+	-- How large is large? Too large and there will be a long
+	-- delay before the message is shown; too short and the message
+	-- will clutter things up unncessarily. It's uncommon for 1000
+	-- files to change in the index, and processing that many files
+	-- takes less than half a second, so that seems about right.
+	largediff :: Int
+	largediff = 1000
+
+	-- When the database is known to have been newly created and empty
+	-- before reconcileStaged started, it is more efficient to use 
+	-- newAssociatedFile. It's safe to use it here because this is run
+	-- with a lock held that blocks any other process that opens the
+	-- database, and when the database is newly created, there is no
+	-- existing process that has it open already. And it's not possible
+	-- for reconcileStaged to call this twice on the same filename with
+	-- two different keys.
+	addassociatedfile
+		| dbisnew = SQL.newAssociatedFile
+		| otherwise = SQL.addAssociatedFile
+
+{- Normally the keys database is updated incrementally when opened,
+ - by reconcileStaged. Calling this explicitly allows running the
+ - update at an earlier point.
+ -}
+updateDatabase :: Annex ()
+updateDatabase = runWriter ContentTable (const noop)
diff --git a/Database/Keys/Handle.hs b/Database/Keys/Handle.hs
new file mode 100644
index 0000000000..1e4a85427b
--- /dev/null
+++ b/Database/Keys/Handle.hs
@@ -0,0 +1,69 @@
+{- Handle for the Keys database.
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -:
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Database.Keys.Handle (
+	DbHandle,
+	newDbHandle,
+	DbState(..),
+	withDbState,
+	flushDbQueue,
+	closeDbHandle,
+) where
+
+import qualified Database.Queue as H
+import Database.Keys.Tables
+import Utility.Exception
+import Utility.DebugLocks
+
+import Control.Concurrent
+import Control.Monad.IO.Class (liftIO, MonadIO)
+import Control.Applicative
+import Prelude
+
+-- The MVar is always left full except when actions are run
+-- that access the database.
+newtype DbHandle = DbHandle (MVar DbState)
+
+-- The database can be closed or open, but it also may have been
+-- tried to open (for read) and didn't exist yet or is not readable.
+data DbState = DbClosed | DbOpen (H.DbQueue, DbTablesChanged) | DbUnavailable
+
+newDbHandle :: IO DbHandle
+newDbHandle = DbHandle <$> newMVar DbClosed
+
+-- Runs an action on the state of the handle, which can change its state.
+-- The MVar is empty while the action runs, which blocks other users
+-- of the handle from running.
+withDbState
+	:: (MonadIO m, MonadCatch m)
+	=> DbHandle
+	-> (DbState -> m (v, DbState))
+	-> m v
+withDbState (DbHandle mvar) a = do
+	st <- liftIO $ debugLocks $ takeMVar mvar
+	go st `onException` (liftIO $ debugLocks $ putMVar mvar st)
+  where
+	go st = do
+		(v, st') <- a st
+		liftIO $ debugLocks $ putMVar mvar st'
+		return v
+
+flushDbQueue :: DbHandle -> IO ()
+flushDbQueue h = withDbState h go
+  where
+	go (DbOpen (qh, _)) = do
+		H.flushDbQueue qh
+		return ((), DbOpen (qh, mempty))
+	go st = return ((), st)
+
+closeDbHandle :: DbHandle -> IO ()
+closeDbHandle h = withDbState h go
+  where
+	go (DbOpen (qh, _)) = do
+		H.closeDbQueue qh
+		return ((), DbClosed)
+	go st = return ((), st)
diff --git a/Database/Keys/SQL.hs b/Database/Keys/SQL.hs
new file mode 100644
index 0000000000..2e40e39db3
--- /dev/null
+++ b/Database/Keys/SQL.hs
@@ -0,0 +1,160 @@
+{- Sqlite database of information about Keys
+ -
+ - Copyright 2015-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE QuasiQuotes, TypeFamilies, TypeOperators, TemplateHaskell #-}
+{-# LANGUAGE OverloadedStrings, GADTs, FlexibleContexts #-}
+{-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
+{-# LANGUAGE RankNTypes, ScopedTypeVariables #-}
+{-# LANGUAGE DataKinds, FlexibleInstances #-}
+{-# LANGUAGE UndecidableInstances #-}
+#if MIN_VERSION_persistent_template(2,8,0)
+{-# LANGUAGE DerivingStrategies #-}
+{-# LANGUAGE StandaloneDeriving #-}
+#endif
+
+module Database.Keys.SQL where
+
+import Database.Types
+import Database.Handle
+import Database.Utility
+import qualified Database.Queue as H
+import Utility.InodeCache
+import Git.FilePath
+
+import Database.Persist.Sql hiding (Key)
+import Database.Persist.TH
+import Control.Monad
+import Data.Maybe
+
+-- Note on indexes: KeyFileIndex etc are really uniqueness constraints,
+-- which cause sqlite to automatically add indexes. So when adding indexes,
+-- have to take care to only add ones that work as uniqueness constraints.
+-- (Unfortunately persistent does not support indexes that are not
+-- uniqueness constraints; https://github.com/yesodweb/persistent/issues/109)
+--
+-- To speed up queries for a key, there's KeyFileIndex, 
+-- which makes there be a covering index for keys.
+--
+-- FileKeyIndex speeds up queries that include the file, since
+-- it makes there be a covering index for files. Note that, despite the name, it is
+-- used as a uniqueness constraint now.
+share [mkPersist sqlSettings, mkMigrate "migrateKeysDb"] [persistLowerCase|
+Associated
+  key Key
+  file SByteString
+  KeyFileIndex key file
+  FileKeyIndex file key
+Content
+  key Key
+  inodecache InodeCache
+  filesize FileSize
+  mtime EpochTime
+  KeyInodeCacheIndex key inodecache
+  InodeCacheKeyIndex inodecache key
+|]
+
+containedTable :: TableName
+containedTable = "content"
+
+createTables :: SqlPersistM ()
+createTables = void $ runMigrationSilent migrateKeysDb
+
+newtype ReadHandle = ReadHandle H.DbQueue
+
+readDb :: SqlPersistM a -> ReadHandle -> IO a
+readDb a (ReadHandle h) = H.queryDbQueue h a
+
+newtype WriteHandle = WriteHandle H.DbQueue
+
+queueDb :: SqlPersistM () -> WriteHandle -> IO ()
+queueDb a (WriteHandle h) = H.queueDb h checkcommit a
+  where
+	-- commit queue after 10000 changes
+	checkcommit sz _lastcommittime = pure (sz > 10000)
+
+-- Insert the associated file.
+-- When the file was associated with a different key before,
+-- update it to the new key.
+addAssociatedFile :: Key -> TopFilePath -> WriteHandle -> IO ()
+addAssociatedFile k f = queueDb $
+	void $ upsertBy
+		(FileKeyIndex af k)
+		(Associated k af)
+		[AssociatedFile =. af, AssociatedKey =. k]
+  where
+	af = SByteString (getTopFilePath f)
+
+-- Faster than addAssociatedFile, but only safe to use when the file
+-- was not associated with a different key before, as it does not delete
+-- any old key.
+newAssociatedFile :: Key -> TopFilePath -> WriteHandle -> IO ()
+newAssociatedFile k f = queueDb $
+	insert_ $ Associated k af
+  where
+	af = SByteString (getTopFilePath f)
+
+{- Note that the files returned were once associated with the key, but
+ - some of them may not be any longer. -}
+getAssociatedFiles :: Key -> ReadHandle -> IO [TopFilePath]
+getAssociatedFiles k = readDb $ do
+	l <- selectList [AssociatedKey ==. k] []
+	return $ map (asTopFilePath . (\(SByteString f) -> f) . associatedFile . entityVal) l
+
+{- Gets any keys that are on record as having a particular associated file.
+ - (Should be one or none.) -}
+getAssociatedKey :: TopFilePath -> ReadHandle -> IO [Key]
+getAssociatedKey f = readDb $ do
+	l <- selectList [AssociatedFile ==. af] []
+	return $ map (associatedKey . entityVal) l
+  where
+	af = SByteString (getTopFilePath f)
+
+removeAssociatedFile :: Key -> TopFilePath -> WriteHandle -> IO ()
+removeAssociatedFile k f = queueDb $
+	deleteWhere [AssociatedKey ==. k, AssociatedFile ==. af]
+  where
+	af = SByteString (getTopFilePath f)
+
+addInodeCaches :: Key -> [InodeCache] -> WriteHandle -> IO ()
+addInodeCaches k is = queueDb $
+	forM_ is $ \i -> insertUniqueFast $ Content k i 
+		(inodeCacheToFileSize i)
+		(inodeCacheToEpochTime i)
+
+{- A key may have multiple InodeCaches; one for the annex object, and one
+ - for each pointer file that is a copy of it. -}
+getInodeCaches :: Key -> ReadHandle -> IO [InodeCache]
+getInodeCaches k = readDb $ do
+	l <- selectList [ContentKey ==. k] []
+	return $ map (contentInodecache . entityVal) l
+
+removeInodeCaches :: Key -> WriteHandle -> IO ()
+removeInodeCaches k = queueDb $
+	deleteWhere [ContentKey ==. k]
+
+removeInodeCache :: InodeCache -> WriteHandle -> IO ()
+removeInodeCache i = queueDb $ deleteWhere
+	[ ContentInodecache ==. i
+	]
+
+{- Check if the inode is known to be used for an annexed file. -}
+isInodeKnown :: InodeCache -> SentinalStatus -> ReadHandle -> IO Bool
+isInodeKnown i s = readDb (isJust <$> selectFirst q [])
+  where
+	q 
+		| sentinalInodesChanged s =
+			-- Note that this select is intentionally not
+			-- indexed. Normally, the inodes have not changed,
+			-- and it would be unnecessary work to maintain
+			-- indexes for the unusual case.
+			[ ContentFilesize ==. inodeCacheToFileSize i
+			, ContentMtime >=. tmin
+			, ContentMtime <=. tmax
+			]
+		| otherwise = [ContentInodecache ==. i]
+	(tmin, tmax) = inodeCacheEpochTimeRange i
diff --git a/Database/Keys/Tables.hs b/Database/Keys/Tables.hs
new file mode 100644
index 0000000000..ab6a4fb757
--- /dev/null
+++ b/Database/Keys/Tables.hs
@@ -0,0 +1,38 @@
+{- Keeping track of which tables in the keys database have changed
+ -
+ - Copyright 2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Database.Keys.Tables where
+
+import Data.Monoid
+import qualified Data.Semigroup as Sem
+import Prelude
+
+data DbTable = AssociatedTable | ContentTable
+	deriving (Eq, Show)
+
+data DbTablesChanged = DbTablesChanged
+	{ associatedTable :: Bool
+	, contentTable :: Bool
+	}
+	deriving (Show)
+
+instance Sem.Semigroup DbTablesChanged where
+	a <> b = DbTablesChanged
+		{ associatedTable = associatedTable a || associatedTable b
+		, contentTable = contentTable a || contentTable b
+		}
+
+instance Monoid DbTablesChanged where
+	mempty = DbTablesChanged False False
+
+addDbTable :: DbTablesChanged -> DbTable -> DbTablesChanged
+addDbTable ts AssociatedTable = ts { associatedTable = True }
+addDbTable ts ContentTable = ts { contentTable = True }
+
+isDbTableChanged :: DbTablesChanged -> DbTable -> Bool
+isDbTableChanged ts AssociatedTable = associatedTable ts
+isDbTableChanged ts ContentTable = contentTable ts
diff --git a/Database/Queue.hs b/Database/Queue.hs
new file mode 100644
index 0000000000..f4882d2fa8
--- /dev/null
+++ b/Database/Queue.hs
@@ -0,0 +1,113 @@
+{- Persistent sqlite database queues
+ -
+ - Copyright 2015-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Database.Queue (
+	DbQueue,
+	openDbQueue,
+	queryDbQueue,
+	closeDbQueue,
+	flushDbQueue,
+	QueueSize,
+	queueDb,
+) where
+
+import Utility.Monad
+import Utility.RawFilePath
+import Utility.DebugLocks
+import Utility.Exception
+import Database.Handle
+
+import Database.Persist.Sqlite
+import Control.Concurrent
+import Data.Time.Clock
+import Control.Applicative
+import Prelude
+
+{- A DbQueue wraps a DbHandle, adding a queue of writes to perform.
+ -
+ - This is efficient when there are frequent writes, but
+ - reads will not immediately have access to queued writes. -}
+data DbQueue = DQ DbHandle (MVar Queue)
+
+{- Opens the database queue, but does not perform any migrations. Only use
+ - if the database is known to exist and have the right tables; ie after
+ - running initDb. -}
+openDbQueue :: RawFilePath -> TableName -> IO DbQueue
+openDbQueue db tablename = DQ
+	<$> openDb db tablename
+	<*> (newMVar =<< emptyQueue)
+
+{- This or flushDbQueue must be called, eg at program exit to ensure
+ - queued changes get written to the database. -}
+closeDbQueue :: DbQueue -> IO ()
+closeDbQueue h@(DQ hdl _) = do
+	flushDbQueue h
+	closeDb hdl
+
+{- Blocks until all queued changes have been written to the database. -}
+flushDbQueue :: DbQueue -> IO ()
+flushDbQueue (DQ hdl qvar) = do
+	q@(Queue sz _ qa) <- debugLocks $ takeMVar qvar
+	if sz > 0
+		then tryNonAsync (commitDb hdl qa) >>= \case
+			Right () -> debugLocks $ putMVar qvar =<< emptyQueue
+			Left e -> do
+				debugLocks $ putMVar qvar q
+				throwM e
+		else debugLocks $ putMVar qvar q
+
+{- Makes a query using the DbQueue's database connection.
+ - This should not be used to make changes to the database!
+ -
+ - Queries will not see changes that have been recently queued,
+ - so use with care.
+ -}
+queryDbQueue :: DbQueue -> SqlPersistM a -> IO a
+queryDbQueue (DQ hdl _) = queryDb hdl
+
+{- A queue of actions to perform, with a count of the number of actions
+ - queued, and a last commit time. -}
+data Queue = Queue QueueSize LastCommitTime (SqlPersistM ())
+
+type QueueSize = Int
+
+type LastCommitTime = UTCTime
+
+emptyQueue :: IO Queue
+emptyQueue = do
+	now <- getCurrentTime
+	return $ Queue 0 now (return ())
+
+{- Queues a change to be made to the database. It will be queued
+ - to be committed later, unless the commitchecker action returns true,
+ - in which case any previously queued changes are also committed.
+ -
+ - Transactions built up by queueDb are sent to sqlite all at once.
+ - If sqlite fails due to another change being made concurrently by another
+ - process, the transaction is put back in the queue. This avoids
+ - the sqlite multiple writer problem.
+ -}
+queueDb 
+	:: DbQueue
+	-> (QueueSize -> LastCommitTime -> IO Bool) 
+	-> SqlPersistM ()
+	-> IO ()
+queueDb (DQ hdl qvar) commitchecker a = do
+	Queue sz lastcommittime qa <- debugLocks $ takeMVar qvar
+	let !sz' = sz + 1
+	let qa' = qa >> a
+	let enqueue = debugLocks . putMVar qvar
+	ifM (commitchecker sz' lastcommittime)
+		( do
+			r <- commitDb' hdl qa'
+			case r of
+				Left _ -> enqueue $ Queue sz' lastcommittime qa'
+				Right _ -> enqueue =<< emptyQueue
+		, enqueue $ Queue sz' lastcommittime qa'
+		)
diff --git a/Database/RawFilePath.hs b/Database/RawFilePath.hs
new file mode 100644
index 0000000000..ba82b9f90d
--- /dev/null
+++ b/Database/RawFilePath.hs
@@ -0,0 +1,95 @@
+{- Persistent sqlite RawFilePath support
+ -
+ - The functions below are copied from persistent-sqlite, but modified to
+ - take a RawFilePath and ignore the sqlConnectionStr from the
+ - SqliteConnectionInfo. This avoids encoding problems using Text
+ - in some situations.
+ -
+ - This module is expected to eventually be supersceded by
+ - persistent-sqlite getting support for OsString.
+ -
+ - Copyright (c) 2012 Michael Snoyman, http://www.yesodweb.com/
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Permission is hereby granted, free of charge, to any person obtaining
+ - a copy of this software and associated documentation files (the
+ - "Software"), to deal in the Software without restriction, including
+ - without limitation the rights to use, copy, modify, merge, publish,
+ - distribute, sublicense, and/or sell copies of the Software, and to
+ - permit persons to whom the Software is furnished to do so, subject to
+ - the following conditions:
+ - 
+ - The above copyright notice and this permission notice shall be
+ - included in all copies or substantial portions of the Software.
+ - 
+ - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ - EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ - MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ - NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+ - LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+ - OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+ - WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+-}
+
+{-# LANGUAGE OverloadedStrings, CPP #-}
+
+module Database.RawFilePath where
+
+#if MIN_VERSION_persistent_sqlite(2,13,3)
+import Database.Persist.Sqlite
+import qualified Database.Sqlite as Sqlite
+import qualified System.FilePath.ByteString as P
+import qualified Control.Exception as E
+import Control.Monad.Logger (MonadLoggerIO)
+import Control.Monad.IO.Unlift (MonadUnliftIO)
+import Control.Monad.Logger (NoLoggingT, runNoLoggingT)
+import Control.Monad.Trans.Reader (ReaderT)
+import UnliftIO.Resource (ResourceT, runResourceT)
+
+openWith'
+	:: P.RawFilePath 
+	-> (SqlBackend -> Sqlite.Connection -> r)
+	-> SqliteConnectionInfo
+	-> LogFunc
+	-> IO r
+openWith' db f connInfo logFunc = do
+	conn <- Sqlite.open' db
+	backend <- wrapConnectionInfo connInfo conn logFunc `E.onException` Sqlite.close conn
+	return $ f backend conn
+
+runSqlite' :: (MonadUnliftIO m)
+	=> P.RawFilePath
+	-> ReaderT SqlBackend (NoLoggingT (ResourceT m)) a
+	-> m a
+runSqlite' connstr = runResourceT
+	. runNoLoggingT
+	. withSqliteConn' connstr
+	. runSqlConn
+
+withSqliteConn'
+	:: (MonadUnliftIO m, MonadLoggerIO m)
+	=> P.RawFilePath
+	-> (SqlBackend -> m a)
+	-> m a
+withSqliteConn' connstr = withSqliteConnInfo' connstr $
+	mkSqliteConnectionInfo mempty
+
+runSqliteInfo'
+	:: (MonadUnliftIO m)
+	=> P.RawFilePath
+	-> SqliteConnectionInfo
+	-> ReaderT SqlBackend (NoLoggingT (ResourceT m)) a
+	-> m a
+runSqliteInfo' db conInfo = runResourceT
+	. runNoLoggingT
+	. withSqliteConnInfo' db conInfo
+	. runSqlConn
+
+withSqliteConnInfo'
+	:: (MonadUnliftIO m, MonadLoggerIO m)
+        => P.RawFilePath
+	-> SqliteConnectionInfo
+	-> (SqlBackend -> m a)
+	-> m a
+withSqliteConnInfo' db = withSqlConn . openWith' db const
+#endif
diff --git a/Database/Types.hs b/Database/Types.hs
new file mode 100644
index 0000000000..bd8852852d
--- /dev/null
+++ b/Database/Types.hs
@@ -0,0 +1,131 @@
+{- types for SQL databases
+ -
+ - Copyright 2015-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+{-# LANGUAGE TypeSynonymInstances #-}
+
+module Database.Types (
+	module Database.Types,
+	Key,
+	EpochTime,
+	FileSize,
+) where
+
+import Database.Persist.Class hiding (Key)
+import Database.Persist.Sql hiding (Key)
+import qualified Data.ByteString as S
+import qualified Data.Text as T
+import qualified Data.Attoparsec.ByteString as A
+import System.PosixCompat.Types
+import Data.Int
+import Data.Text.Read
+import Foreign.C.Types
+
+import Key
+import Utility.InodeCache
+import Utility.FileSize
+import Utility.FileSystemEncoding
+import Git.Types
+import Types.UUID
+import Types.Import
+
+instance PersistField Key where
+	toPersistValue = toPersistValue . serializeKey'
+	fromPersistValue b = fromPersistValue b >>= parse
+	  where
+		parse = either (Left . T.pack) Right . A.parseOnly keyParser
+
+-- A key can contain arbitrarily encoded characters, so store in sqlite as a
+-- blob to avoid encoding problems.
+instance PersistFieldSql Key where
+	sqlType _ = SqlBlob
+
+instance PersistField InodeCache where
+	toPersistValue = toPersistValue . showInodeCache 
+	fromPersistValue b = fromPersistValue b >>= parse
+	  where
+		parse s = maybe
+			(Left $ T.pack $ "bad serialized InodeCache "++ s)
+			Right
+			(readInodeCache s)
+
+instance PersistFieldSql InodeCache where
+	sqlType _ = SqlString
+
+instance PersistField UUID where
+	toPersistValue u = toPersistValue b
+	  where
+		b :: S.ByteString
+		b = fromUUID u
+	fromPersistValue v = toUUID <$> go
+	  where
+	 	go :: Either T.Text S.ByteString
+		go = fromPersistValue v
+
+instance PersistFieldSql UUID where
+	sqlType _ = SqlBlob
+
+instance PersistField ContentIdentifier where
+	toPersistValue (ContentIdentifier b) = toPersistValue b
+	fromPersistValue v = ContentIdentifier <$> go
+	  where
+	 	go :: Either T.Text S.ByteString
+		go = fromPersistValue v
+
+instance PersistFieldSql ContentIdentifier where
+	sqlType _ = SqlBlob
+
+-- A serialized bytestring.
+newtype SByteString = SByteString S.ByteString
+	deriving (Eq, Show)
+
+instance PersistField  SByteString where
+	toPersistValue (SByteString b) = toPersistValue b
+	fromPersistValue v = SByteString <$> fromPersistValue v
+
+instance PersistFieldSql SByteString where
+	sqlType _ = SqlBlob
+
+-- A serialized git Sha
+newtype SSha = SSha String
+	deriving (Eq, Show)
+
+toSSha :: Sha -> SSha
+toSSha (Ref s) = SSha (decodeBS s)
+
+fromSSha :: SSha -> Ref
+fromSSha (SSha s) = Ref (encodeBS s)
+
+instance PersistField SSha where
+	toPersistValue (SSha b) = toPersistValue b
+	fromPersistValue v = SSha <$> fromPersistValue v
+
+instance PersistFieldSql SSha where
+	sqlType _ = SqlString
+
+-- A FileSize could be stored as an Int64, but some systems could
+-- conceivably have a larger filesize, and no math is ever done with them
+-- in sqlite, so store a string instead.
+instance PersistField FileSize where
+	toPersistValue = toPersistValue . show
+	fromPersistValue v = fromPersistValue v >>= parse
+	  where
+		parse = either (Left . T.pack) (Right . fst) . decimal
+
+instance PersistFieldSql FileSize where
+	sqlType _ = SqlString
+
+-- Store EpochTime as an Int64, to allow selecting values in a range.
+instance PersistField EpochTime where
+	toPersistValue (CTime t) = toPersistValue (fromIntegral t :: Int64)
+	fromPersistValue v = CTime . fromIntegral <$> go
+	  where
+		go :: Either T.Text Int64
+		go = fromPersistValue v
+
+instance PersistFieldSql EpochTime where
+	sqlType _ = SqlInt64
diff --git a/Database/Utility.hs b/Database/Utility.hs
new file mode 100644
index 0000000000..55943fcc89
--- /dev/null
+++ b/Database/Utility.hs
@@ -0,0 +1,27 @@
+{- Persistent sqlite database utilities.
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeFamilies, CPP #-}
+{-# OPTIONS_GHC -fno-warn-missing-signatures #-}
+
+module Database.Utility (
+	insertUniqueFast,
+) where
+
+import Control.Monad
+import Database.Persist.Class
+
+{- insertUnique_ is 2x as fast as insertUnique, so use when available.
+ -
+ - It would be difficult to write the type signature here, since older
+ - versions of persistent have different constraints on insertUnique.
+ -}
+#if MIN_VERSION_persistent(2,14,5)
+insertUniqueFast x = void (insertUnique_ x)
+#else
+insertUniqueFast x = void (insertUnique x)
+#endif
diff --git a/Git.hs b/Git.hs
new file mode 100644
index 0000000000..e567917ea1
--- /dev/null
+++ b/Git.hs
@@ -0,0 +1,185 @@
+{- git repository handling 
+ -
+ - This is written to be completely independent of git-annex and should be
+ - suitable for other uses.
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE CPP #-}
+
+module Git (
+	Repo(..),
+	Ref(..),
+	fromRef,
+	fromRef',
+	Branch,
+	Sha,
+	Tag,
+	repoIsUrl,
+	repoIsSsh,
+	repoIsHttp,
+	repoIsLocal,
+	repoIsLocalBare,
+	repoIsLocalUnknown,
+	repoDescribe,
+	repoLocation,
+	repoPath,
+	repoWorkTree,
+	localGitDir,
+	attributes,
+	attributesLocal,
+	hookPath,
+	assertLocal,
+	adjustPath,
+	relPath,
+) where
+
+import qualified Data.ByteString as B
+import Network.URI (uriPath, uriScheme, unEscapeString)
+#ifndef mingw32_HOST_OS
+import System.Posix.Files
+#endif
+import qualified System.FilePath.ByteString as P
+
+import Common
+import Git.Types
+#ifndef mingw32_HOST_OS
+import Utility.FileMode
+#endif
+
+{- User-visible description of a git repo. -}
+repoDescribe :: Repo -> String
+repoDescribe Repo { remoteName = Just name } = name
+repoDescribe Repo { location = Url url } = show url
+repoDescribe Repo { location = UnparseableUrl url } = url
+repoDescribe Repo { location = Local { worktree = Just dir } } = fromRawFilePath dir
+repoDescribe Repo { location = Local { gitdir = dir } } = fromRawFilePath dir
+repoDescribe Repo { location = LocalUnknown dir } = fromRawFilePath dir
+repoDescribe Repo { location = Unknown } = "UNKNOWN"
+
+{- Location of the repo, either as a path or url. -}
+repoLocation :: Repo -> String
+repoLocation Repo { location = Url url } = show url
+repoLocation Repo { location = UnparseableUrl url } = url
+repoLocation Repo { location = Local { worktree = Just dir } } = fromRawFilePath dir
+repoLocation Repo { location = Local { gitdir = dir } } = fromRawFilePath dir
+repoLocation Repo { location = LocalUnknown dir } = fromRawFilePath dir
+repoLocation Repo { location = Unknown } = giveup "unknown repoLocation"
+
+{- Path to a repository. For non-bare, this is the worktree, for bare, 
+ - it's the gitdir, and for URL repositories, is the path on the remote
+ - host. -}
+repoPath :: Repo -> RawFilePath
+repoPath Repo { location = Url u } = toRawFilePath $ unEscapeString $ uriPath u
+repoPath Repo { location = Local { worktree = Just d } } = d
+repoPath Repo { location = Local { gitdir = d } } = d
+repoPath Repo { location = LocalUnknown dir } = dir
+repoPath Repo { location = Unknown } = giveup "unknown repoPath"
+repoPath Repo { location = UnparseableUrl _u } = giveup "unknown repoPath"
+
+repoWorkTree :: Repo -> Maybe RawFilePath
+repoWorkTree Repo { location = Local { worktree = Just d } } = Just d
+repoWorkTree _ = Nothing
+
+{- Path to a local repository's .git directory. -}
+localGitDir :: Repo -> RawFilePath
+localGitDir Repo { location = Local { gitdir = d } } = d
+localGitDir _ = giveup "unknown localGitDir"
+
+{- Some code needs to vary between URL and normal repos,
+ - or bare and non-bare, these functions help with that. -}
+repoIsUrl :: Repo -> Bool
+repoIsUrl Repo { location = Url _ } = True
+repoIsUrl Repo { location = UnparseableUrl _ } = True
+repoIsUrl _ = False
+
+repoIsSsh :: Repo -> Bool
+repoIsSsh Repo { location = Url url } 
+	| scheme == "ssh:" = True
+	-- git treats these the same as ssh
+	| scheme == "git+ssh:" = True
+	| scheme == "ssh+git:" = True
+	| otherwise = False
+  where
+	scheme = uriScheme url
+repoIsSsh _ = False
+
+repoIsHttp :: Repo -> Bool
+repoIsHttp Repo { location = Url url } 
+	| uriScheme url == "http:" = True
+	| uriScheme url == "https:" = True
+	| otherwise = False
+repoIsHttp _ = False
+
+repoIsLocal :: Repo -> Bool
+repoIsLocal Repo { location = Local { } } = True
+repoIsLocal _ = False
+
+repoIsLocalBare :: Repo -> Bool
+repoIsLocalBare Repo { location = Local { worktree = Nothing } } = True
+repoIsLocalBare _ = False
+
+repoIsLocalUnknown :: Repo -> Bool
+repoIsLocalUnknown Repo { location = LocalUnknown { } } = True
+repoIsLocalUnknown _ = False
+
+assertLocal :: Repo -> a -> a
+assertLocal repo action
+	| repoIsUrl repo = giveup $ unwords
+		[ "acting on non-local git repo"
+		, repoDescribe repo
+		, "not supported"
+		]
+	| otherwise = action
+
+{- Path to a repository's gitattributes file. -}
+attributes :: Repo -> RawFilePath
+attributes repo
+	| repoIsLocalBare repo = attributesLocal repo
+	| otherwise = repoPath repo P.</> ".gitattributes"
+
+attributesLocal :: Repo -> RawFilePath
+attributesLocal repo = localGitDir repo P.</> "info" P.</> "attributes"
+
+{- Path to a given hook script in a repository, only if the hook exists
+ - and is executable. -}
+hookPath :: String -> Repo -> IO (Maybe FilePath)
+hookPath script repo = do
+	let hook = fromRawFilePath (localGitDir repo) </> "hooks" </> script
+	ifM (catchBoolIO $ isexecutable hook)
+		( return $ Just hook , return Nothing )
+  where
+#if mingw32_HOST_OS
+	isexecutable f = doesFileExist f
+#else
+	isexecutable f = isExecutable . fileMode <$> getSymbolicLinkStatus f
+#endif
+
+{- Makes the path to a local Repo be relative to the cwd. -}
+relPath :: Repo -> IO Repo
+relPath = adjustPath torel
+  where
+	torel p = do
+		p' <- relPathCwdToFile p
+		return $ if B.null p' then "." else p'
+
+{- Adusts the path to a local Repo using the provided function. -}
+adjustPath :: (RawFilePath -> IO RawFilePath) -> Repo -> IO Repo
+adjustPath f r@(Repo { location = l@(Local { gitdir = d, worktree = w }) }) = do
+	d' <- f d
+	w' <- maybe (pure Nothing) (Just <$$> f) w
+	return $ r 
+		{ location = l 
+			{ gitdir = d'
+			, worktree = w'
+			}
+		}
+  where
+adjustPath f r@(Repo { location = LocalUnknown d }) = do
+	d' <- f d
+	return $ r { location = LocalUnknown d' }
+adjustPath _ r = pure r
diff --git a/Git/AutoCorrect.hs b/Git/AutoCorrect.hs
new file mode 100644
index 0000000000..06823a182f
--- /dev/null
+++ b/Git/AutoCorrect.hs
@@ -0,0 +1,73 @@
+{- git autocorrection using Damerau-Levenshtein edit distance
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.AutoCorrect where
+
+import Common
+import Git.Types
+import qualified Git.Config
+
+import Text.EditDistance
+import Control.Concurrent
+
+{- These are the same cost values as used in git. -}
+gitEditCosts :: EditCosts
+gitEditCosts = EditCosts
+	{ deletionCosts = ConstantCost 4
+	, insertionCosts = ConstantCost 1
+	, substitutionCosts = ConstantCost 2
+	, transpositionCosts = ConstantCost 0
+	}
+		
+{- Git's source calls this "an empirically derived magic number" -}
+similarityFloor :: Int
+similarityFloor = 7
+
+{- Finds inexact matches for the input among the choices.
+ - Returns an ordered list of good enough matches, or an empty list if
+ - nothing matches well. -}
+fuzzymatches :: String -> (c -> String) -> [c] -> [c]
+fuzzymatches input showchoice choices = fst $ unzip $
+	sortBy comparecost $ filter similarEnough $ zip choices costs
+  where
+	distance = restrictedDamerauLevenshteinDistance gitEditCosts input
+	costs = map (distance . showchoice) choices
+	comparecost a b = compare (snd a) (snd b)
+	similarEnough (_, cst) = cst < similarityFloor
+
+{- Takes action based on git's autocorrect configuration, in preparation for
+ - an autocorrected command being run.
+ -}
+prepare :: String -> (c -> String) -> [c] -> Maybe Repo -> IO ()
+prepare input showmatch matches r =
+	case readish . fromConfigValue . Git.Config.get "help.autocorrect" "0" =<< r of
+		Just n
+			| n == 0 -> list
+			| n < 0 -> warn Nothing
+			| otherwise -> sleep n
+		Nothing -> list
+  where
+	list = giveup $ unlines $
+		[ "Unknown command '" ++ input ++ "'"
+		, ""
+		, "Did you mean one of these?"
+		] ++ map (\m -> "\t" ++ showmatch m) matches
+	warn :: Maybe Float -> IO ()
+	warn mdelaysec = hPutStr stderr $ unlines
+		[ "WARNING: You called a git-annex command named '" ++
+		  input ++ "', which does not exist."
+		, case mdelaysec of
+			Nothing -> "Continuing under the assumption that you meant " ++ match
+			Just sec -> "Continuing in " ++ show sec ++ " seconds, assuming that you meant " ++ match
+		]
+	  where
+		match = "'" ++ showmatch (Prelude.head matches) ++ "'."
+	sleep n = do
+		warn (Just (fromIntegral n / 10 :: Float))
+		threadDelay (n * 100000) -- deciseconds to microseconds
diff --git a/Git/Branch.hs b/Git/Branch.hs
new file mode 100644
index 0000000000..5913a1618f
--- /dev/null
+++ b/Git/Branch.hs
@@ -0,0 +1,270 @@
+{- git branch stuff
+ -
+ - Copyright 2011-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.Branch where
+
+import Common
+import Git
+import Git.Sha
+import Git.Command
+import qualified Git.Config
+import qualified Git.Ref
+
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Char8 as B8
+
+{- The currently checked out branch.
+ -
+ - In a just initialized git repo before the first commit,
+ - symbolic-ref will show the master branch, even though that
+ - branch is not created yet. So, this also looks at show-ref
+ - to double-check.
+ -}
+current :: Repo -> IO (Maybe Branch)
+current r = do
+	v <- currentUnsafe r
+	case v of
+		Nothing -> return Nothing
+		Just branch -> 
+			ifM (B.null <$> pipeReadStrict [Param "show-ref", Param $ fromRef branch] r)
+				( return Nothing
+				, return v
+				)
+
+{- The current branch, which may not really exist yet. -}
+currentUnsafe :: Repo -> IO (Maybe Branch)
+currentUnsafe r = parse . firstLine' <$> pipeReadStrict
+	[ Param "symbolic-ref"
+	, Param "-q"
+	, Param $ fromRef Git.Ref.headRef
+	] r
+  where
+	parse b
+		| B.null b = Nothing
+		| otherwise = Just $ Git.Ref b
+
+{- Checks if the second branch has any commits not present on the first
+ - branch. -}
+changed :: Branch -> Branch -> Repo -> IO Bool
+changed origbranch newbranch repo
+	| origbranch == newbranch = return False
+	| otherwise = not . B.null
+		<$> changed' origbranch newbranch [Param "-n1"] repo
+  where
+
+changed' :: Branch -> Branch -> [CommandParam] -> Repo -> IO B.ByteString
+changed' origbranch newbranch extraps repo = pipeReadStrict ps repo
+  where
+	ps =
+		[ Param "log"
+		, Param (fromRef origbranch ++ ".." ++ fromRef newbranch)
+		, Param "--pretty=%H"
+		] ++ extraps
+
+{- Lists commits that are in the second branch and not in the first branch. -}
+changedCommits :: Branch -> Branch -> [CommandParam] -> Repo -> IO [Sha]
+changedCommits origbranch newbranch extraps repo = 
+	catMaybes . map extractSha . B8.lines
+		<$> changed' origbranch newbranch extraps repo
+	
+{- Check if it's possible to fast-forward from the old
+ - ref to the new ref.
+ -
+ - This requires there to be a path from the old to the new. -}
+fastForwardable :: Ref -> Ref -> Repo -> IO Bool
+fastForwardable old new repo = not . B.null <$>
+	pipeReadStrict
+		[ Param "log"
+		, Param $ fromRef old ++ ".." ++ fromRef new
+		, Param "-n1"
+		, Param "--pretty=%H"
+		, Param "--ancestry-path"
+		] repo
+
+{- Given a set of refs that are all known to have commits not
+ - on the branch, tries to update the branch by a fast-forward.
+ -
+ - In order for that to be possible, one of the refs must contain
+ - every commit present in all the other refs.
+ -}
+fastForward :: Branch -> [Ref] -> Repo -> IO Bool
+fastForward _ [] _ = return True
+fastForward branch (first:rest) repo =
+	-- First, check that the branch does not contain any
+	-- new commits that are not in the first ref. If it does,
+	-- cannot fast-forward.
+	ifM (changed first branch repo)
+		( no_ff
+		, maybe no_ff do_ff =<< findbest first rest
+		)
+  where
+	no_ff = return False
+	do_ff to = do
+		update' branch to repo
+		return True
+	findbest c [] = return $ Just c
+	findbest c (r:rs)
+		| c == r = findbest c rs
+		| otherwise = do
+		better <- changed c r repo
+		worse <- changed r c repo
+		case (better, worse) of
+			(True, True) -> return Nothing -- divergent fail
+			(True, False) -> findbest r rs -- better
+			(False, True) -> findbest c rs -- worse
+			(False, False) -> findbest c rs -- same
+
+{- Should the commit avoid the usual summary output? -}
+newtype CommitQuiet = CommitQuiet Bool
+
+applyCommitQuiet :: CommitQuiet -> [CommandParam] -> [CommandParam]
+applyCommitQuiet (CommitQuiet True) ps = Param "--quiet" : ps
+applyCommitQuiet (CommitQuiet False) ps = ps
+
+{- The user may have set commit.gpgsign, intending all their manual
+ - commits to be signed. But signing automatic/background commits could
+ - easily lead to unwanted gpg prompts or failures.
+ -}
+data CommitMode = ManualCommit | AutomaticCommit
+	deriving (Eq)
+
+{- Prevent signing automatic commits. -}
+applyCommitMode :: CommitMode -> [CommandParam] -> [CommandParam]
+applyCommitMode commitmode ps
+	| commitmode == AutomaticCommit = Param "--no-gpg-sign" : ps
+	| otherwise = ps
+
+{- Some versions of git commit-tree honor commit.gpgsign themselves,
+ - but others need -S to be passed to enable gpg signing of manual commits. -}
+applyCommitModeForCommitTree :: CommitMode -> [CommandParam] -> Repo -> [CommandParam]
+applyCommitModeForCommitTree commitmode ps r
+	| commitmode == ManualCommit =
+		case Git.Config.getMaybe "commit.gpgsign" r of
+			Just s | Git.Config.isTrueFalse' s == Just True ->
+				Param "-S":ps
+			_ -> ps'
+	| otherwise = ps'
+  where
+	ps' = applyCommitMode commitmode ps
+
+{- Commit via the usual git command. -}
+commitCommand :: CommitMode -> CommitQuiet -> [CommandParam] -> Repo -> IO Bool
+commitCommand = commitCommand' runBool
+
+commitCommand' :: ([CommandParam] -> Repo -> IO a) -> CommitMode -> CommitQuiet -> [CommandParam] -> Repo -> IO a
+commitCommand' runner commitmode commitquiet ps =
+	runner $ Param "commit" : ps'
+  where
+	ps' = applyCommitMode commitmode (applyCommitQuiet commitquiet ps)
+
+{- Commits the index into the specified branch (or other ref), 
+ - with the specified parent refs, and returns the committed sha.
+ -
+ - Without allowempy set, avoids making a commit if there is exactly
+ - one parent, and it has the same tree that would be committed.
+ -
+ - Unlike git-commit, does not run any hooks, or examine the work tree
+ - in any way, or output a summary.
+ -}
+commit :: CommitMode -> Bool -> String -> Branch -> [Ref] -> Repo -> IO (Maybe Sha)
+commit commitmode allowempty message branch parentrefs repo = do
+	tree <- writeTree repo
+	ifM (cancommit tree)
+		( do
+			sha <- commitTree commitmode [message] parentrefs tree repo
+			update' branch sha repo
+			return $ Just sha
+		, return Nothing
+		)
+  where
+	cancommit tree
+		| allowempty = return True
+		| otherwise = case parentrefs of
+			[p] -> maybe False (tree /=) <$> Git.Ref.tree p repo
+			_ -> return True
+
+commitAlways :: CommitMode -> String -> Branch -> [Ref] -> Repo -> IO Sha
+commitAlways commitmode message branch parentrefs repo = fromJust
+	<$> commit commitmode True message branch parentrefs repo
+
+-- Throws exception if the index is locked, with an error message output by
+-- git on stderr.
+writeTree :: Repo -> IO Sha
+writeTree repo = getSha "write-tree" $
+	pipeReadStrict [Param "write-tree"] repo
+
+-- Avoids error output if the command fails due to eg, the index being locked.
+writeTreeQuiet :: Repo -> IO (Maybe Sha)
+writeTreeQuiet repo = extractSha <$> withNullHandle go
+  where
+	go nullh = pipeReadStrict' (\p -> p { std_err = UseHandle nullh }) 
+		[Param "write-tree"] repo
+
+commitTree :: CommitMode -> [String] -> [Ref] -> Ref -> Repo -> IO Sha
+commitTree commitmode messages parentrefs tree repo =
+	getSha "commit-tree" $ pipeReadStrict ps repo
+  where
+	ps = [Param "commit-tree", Param (fromRef tree)]
+		++ applyCommitModeForCommitTree commitmode baseparams repo
+	baseparams = map Param $
+		concatMap (\r -> ["-p", fromRef r]) parentrefs
+			++ concatMap (\msg -> ["-m", msg]) messages
+
+-- commitTree passes the commit message to git with -m, which can cause it
+-- to get modified slightly (eg adding trailing newline). This variant uses
+-- the exact commit message that is provided.
+commitTreeExactMessage :: CommitMode -> String -> [Ref] -> Ref -> Repo -> IO Sha
+commitTreeExactMessage commitmode message parentrefs tree repo =
+	getSha "commit-tree" $
+		pipeWriteRead ([Param "commit-tree", Param (fromRef tree)] ++ ps)
+			sendmsg repo
+  where
+	sendmsg = Just $ flip hPutStr message
+	ps = applyCommitModeForCommitTree commitmode parentparams repo
+	parentparams = map Param $ concatMap (\r -> ["-p", fromRef r]) parentrefs
+
+{- A leading + makes git-push force pushing a branch. -}
+forcePush :: String -> String
+forcePush b = "+" ++ b
+
+{- Updates a branch (or other ref) to a new Sha or branch Ref. -}
+update :: String -> Branch -> Ref -> Repo -> IO ()
+update message branch r = run
+	[ Param "update-ref"
+	, Param "-m"
+	, Param message
+	, Param $ fromRef branch
+	, Param $ fromRef r
+	]
+
+update' :: Branch -> Ref -> Repo -> IO ()
+update' branch r = run
+	[ Param "update-ref"
+	, Param $ fromRef branch
+	, Param $ fromRef r
+	]
+
+{- Checks out a branch, creating it if necessary. -}
+checkout :: Branch -> Repo -> IO ()
+checkout branch = run
+	[ Param "checkout"
+	, Param "-q"
+	, Param "-B"
+	, Param $ fromRef $ Git.Ref.base branch
+	]
+
+{- Removes a branch. -}
+delete :: Branch -> Repo -> IO ()
+delete branch = run
+	[ Param "branch"
+	, Param "-q"
+	, Param "-D"
+	, Param $ fromRef $ Git.Ref.base branch
+	]
diff --git a/Git/BuildVersion.hs b/Git/BuildVersion.hs
new file mode 100644
index 0000000000..f94a892015
--- /dev/null
+++ b/Git/BuildVersion.hs
@@ -0,0 +1,21 @@
+{- git build version
+ -
+ - Copyright 2011 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.BuildVersion where
+
+import Git.Version
+import qualified BuildInfo
+
+{- Using the version it was configured for avoids running git to check its
+ - version, at the cost that upgrading git won't be noticed.
+ - This is only acceptable because it's rare that git's version influences
+ - code's behavior. -}
+buildVersion :: GitVersion
+buildVersion = normalize BuildInfo.gitversion
+
+older :: String -> Bool
+older n = buildVersion < normalize n 
diff --git a/Git/CatFile.hs b/Git/CatFile.hs
new file mode 100644
index 0000000000..daa41ad083
--- /dev/null
+++ b/Git/CatFile.hs
@@ -0,0 +1,422 @@
+{- git cat-file interface
+ -
+ - Copyright 2011-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE BangPatterns #-}
+
+module Git.CatFile (
+	CatFileHandle,
+	CatFileMetaDataHandle,
+	catFileStart,
+	catFileMetaDataStart,
+	catFileStart',
+	catFileMetaDataStart',
+	catFileStop,
+	catFileMetaDataStop,
+	catFile,
+	catFileDetails,
+	catTree,
+	catCommit,
+	catObject,
+	catObjectDetails,
+	catObjectMetaData,
+	catObjectStreamLsTree,
+	catObjectStream,
+	catObjectMetaDataStream,
+) where
+
+import System.IO
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.Attoparsec.ByteString as A
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+import qualified Data.Map.Strict as M
+import Data.String
+import Data.Char
+import Numeric
+import System.Posix.Types
+import Text.Read
+import Control.Concurrent.Async
+import Control.Concurrent.Chan
+import Control.Monad.IO.Class (MonadIO)
+
+import Common
+import Git
+import Git.Sha
+import qualified Git.Ref
+import Git.Command
+import Git.Types
+import Git.HashObject
+import qualified Git.LsTree as LsTree
+import qualified Utility.CoProcess as CoProcess
+import qualified Git.BuildVersion as BuildVersion
+import Utility.Tuple
+
+data CatFileHandle = CatFileHandle 
+	{ catFileProcess :: CoProcess.CoProcessHandle
+	, catFileGitRepo :: Repo
+	}
+
+data CatFileMetaDataHandle = CatFileMetaDataHandle
+	{ checkFileProcess :: CoProcess.CoProcessHandle
+	, checkFileGitRepo :: Repo
+	}
+
+catFileStart :: Repo -> IO CatFileHandle
+catFileStart = catFileStart' True
+
+catFileStart' :: Bool -> Repo -> IO CatFileHandle
+catFileStart' restartable repo = CatFileHandle
+	<$> startcat restartable repo "--batch"
+	<*> pure repo
+
+catFileMetaDataStart :: Repo -> IO CatFileMetaDataHandle
+catFileMetaDataStart = catFileMetaDataStart' True
+
+catFileMetaDataStart' :: Bool -> Repo -> IO CatFileMetaDataHandle
+catFileMetaDataStart' restartable repo = CatFileMetaDataHandle
+	<$> startcat restartable repo ("--batch-check=" ++ batchFormat)
+	<*> pure repo
+
+batchFormat :: String
+batchFormat = "%(objectname) %(objecttype) %(objectsize)"
+
+startcat :: Bool -> Repo -> String -> IO CoProcess.CoProcessHandle
+startcat restartable repo p = gitCoProcessStart restartable
+	[ Param "cat-file"
+	, Param p
+	] repo
+
+catFileStop :: CatFileHandle -> IO ()
+catFileStop = CoProcess.stop . catFileProcess
+
+catFileMetaDataStop :: CatFileMetaDataHandle -> IO ()
+catFileMetaDataStop = CoProcess.stop . checkFileProcess
+
+{- Reads a file from a specified branch. -}
+catFile :: CatFileHandle -> Branch -> RawFilePath -> IO L.ByteString
+catFile h branch file = catObject h $
+	Git.Ref.branchFileRef branch file
+
+catFileDetails :: CatFileHandle -> Branch -> RawFilePath -> IO (Maybe (L.ByteString, Sha, ObjectType))
+catFileDetails h branch file = catObjectDetails h $ 
+	Git.Ref.branchFileRef branch file
+
+{- Uses a running git cat-file read the content of an object.
+ - Objects that do not exist will have "" returned. -}
+catObject :: CatFileHandle -> Ref -> IO L.ByteString
+catObject h object = maybe L.empty fst3 <$> catObjectDetails h object
+
+catObjectDetails :: CatFileHandle -> Ref -> IO (Maybe (L.ByteString, Sha, ObjectType))
+catObjectDetails h object = query (catFileProcess h) object newlinefallback $ \from -> do
+	header <- S8.hGetLine from
+	case parseResp object header of
+		Just r@(ParsedResp sha objtype _size) -> do
+			content <- readObjectContent from r
+			return $ Just (content, sha, objtype)
+		Just DNE -> return Nothing
+		Nothing -> giveup $ "unknown response from git cat-file " ++ show (header, object)
+  where
+	-- Slow fallback path for filenames containing newlines.
+	newlinefallback = queryObjectType object (catFileGitRepo h) >>= \case
+		Nothing -> return Nothing
+		Just objtype -> queryContent object (catFileGitRepo h) >>= \case
+			Nothing -> return Nothing
+			Just content -> do
+				-- only the --batch interface allows getting
+				-- the sha, so have to re-hash the object
+				sha <- hashObject' objtype
+					(flip L.hPut content)
+					(catFileGitRepo h)
+				return (Just (content, sha, objtype))
+
+readObjectContent :: Handle -> ParsedResp -> IO L.ByteString
+readObjectContent h (ParsedResp _ _ size) = do
+	content <- S.hGet h (fromIntegral size)
+	eatchar '\n'
+	return (L.fromChunks [content])
+  where
+	eatchar expected = do
+		c <- hGetChar h
+		when (c /= expected) $
+			giveup $ "missing " ++ (show expected) ++ " from git cat-file"
+readObjectContent _ DNE = error "internal"
+
+{- Gets the size and type of an object, without reading its content. -}
+catObjectMetaData :: CatFileMetaDataHandle -> Ref -> IO (Maybe (Sha, FileSize, ObjectType))
+catObjectMetaData h object = query (checkFileProcess h) object newlinefallback $ \from -> do
+	resp <- S8.hGetLine from
+	case parseResp object resp of
+		Just (ParsedResp sha objtype size) ->
+			return $ Just (sha, size, objtype)
+		Just DNE -> return Nothing
+		Nothing -> error $ "unknown response from git cat-file " ++ show (resp, object)
+  where
+	-- Slow fallback path for filenames containing newlines.
+	newlinefallback = do
+		sha <- Git.Ref.sha object (checkFileGitRepo h)
+		sz <- querySize object (checkFileGitRepo h)
+		objtype <- queryObjectType object (checkFileGitRepo h)
+		return $ (,,) <$> sha <*> sz <*> objtype
+
+data ParsedResp = ParsedResp Sha ObjectType FileSize | DNE
+	deriving (Show)
+
+query :: CoProcess.CoProcessHandle -> Ref -> IO a -> (Handle -> IO a) -> IO a
+query hdl object newlinefallback receive
+	-- git cat-file --batch uses a line based protocol, so when the
+	-- filename itself contains a newline, have to fall back to another
+	-- method of getting the information.
+	| '\n' `S8.elem` s = newlinefallback
+	-- git strips carriage return from the end of a line, out of some
+	-- misplaced desire to support windows, so also use the newline
+	-- fallback for those.
+	| "\r" `S8.isSuffixOf` s = newlinefallback
+	| otherwise = CoProcess.query hdl send receive
+  where
+	send to = S8.hPutStrLn to s
+	s = fromRef' object
+
+parseResp :: Ref -> S.ByteString -> Maybe ParsedResp
+parseResp object s
+	| " missing" `S.isSuffixOf` s -- less expensive than full check
+		&& s == fromRef' object <> " missing" = Just DNE
+	| otherwise = eitherToMaybe $ A.parseOnly respParser s
+
+respParser :: A.Parser ParsedResp
+respParser = ParsedResp
+	<$> (maybe (fail "bad sha") return . extractSha =<< nextword)
+	<* A8.char ' '
+	<*> (maybe (fail "bad object type") return . readObjectType =<< nextword)
+	<* A8.char ' '
+	<*> A8.decimal
+  where
+	nextword = A8.takeTill (== ' ')
+
+querySingle :: CommandParam -> Ref -> Repo -> (Handle -> IO a) -> IO (Maybe a)
+querySingle o r repo reader = assertLocal repo $
+	-- In non-batch mode, git cat-file warns on stderr when
+	-- asked for an object that does not exist.
+	-- Squelch that warning to behave the same as batch mode.
+	withNullHandle $ \nullh -> do
+		let p = gitCreateProcess 
+			[ Param "cat-file"
+			, o
+			, Param (fromRef r)
+			] repo
+		let p' = p
+			{ std_err = UseHandle nullh
+			, std_in = Inherit
+			, std_out = CreatePipe
+			}
+		withCreateProcess p' go
+  where
+	go _ (Just outh) _ pid = do
+		output <- reader outh
+		hClose outh
+		ifM (checkSuccessProcess pid)
+			( return (Just output)
+			, return Nothing
+			)
+	go _ _ _ _ = error "internal"
+
+querySize :: Ref -> Repo -> IO (Maybe FileSize)
+querySize r repo = maybe Nothing (readMaybe . takeWhile (/= '\n'))
+	<$> querySingle (Param "-s") r repo hGetContentsStrict
+
+queryObjectType :: Ref -> Repo -> IO (Maybe ObjectType)
+queryObjectType r repo = maybe Nothing (readObjectType . encodeBS . takeWhile (/= '\n'))
+	<$> querySingle (Param "-t") r repo hGetContentsStrict
+
+queryContent :: Ref -> Repo -> IO (Maybe L.ByteString)
+queryContent r repo = fmap (\b -> L.fromChunks [b])
+	<$> querySingle (Param "-p") r repo S.hGetContents
+
+{- Gets a list of files and directories in a tree. (Not recursive.) -}
+catTree :: CatFileHandle -> Ref -> IO [(FilePath, FileMode)]
+catTree h treeref = go <$> catObjectDetails h treeref
+  where
+	go (Just (b, _, TreeObject)) = parsetree [] b
+	go _ = []
+
+	parsetree c b = case L.break (== 0) b of
+		(modefile, rest)
+			| L.null modefile -> c
+			| otherwise -> parsetree
+				(parsemodefile modefile:c)
+				(dropsha rest)
+
+	-- these 20 bytes after the NUL hold the file's sha
+	dropsha = L.drop 21
+
+	parsemodefile b = 
+		let (modestr, file) = separate (== ' ') (decodeBL b)
+		in (file, readmode modestr)
+	readmode = fromMaybe 0 . fmap fst . headMaybe . readOct
+
+catCommit :: CatFileHandle -> Ref -> IO (Maybe Commit)
+catCommit h commitref = go <$> catObjectDetails h commitref
+  where
+	go (Just (b, _, CommitObject)) = parseCommit (L.toStrict b)
+	go _ = Nothing
+
+parseCommit :: S.ByteString -> Maybe Commit
+parseCommit b = Commit
+	<$> (extractSha =<< field "tree")
+	<*> Just (maybe [] (mapMaybe extractSha) (fields "parent"))
+	<*> (parsemetadata <$> field "author")
+	<*> (parsemetadata <$> field "committer")
+	<*> Just (decodeBS $ S.intercalate (S.singleton nl) message)
+  where
+	field n = headMaybe =<< fields n
+	fields n = M.lookup (fromString n) fieldmap
+	fieldmap = M.fromListWith (++) ((map breakfield) header)
+	breakfield l =
+		let (k, sp_v) = S.break (== sp) l
+		in (k, [S.drop 1 sp_v])
+	(header, message) = separate S.null ls
+	ls = S.split nl b
+
+	-- author and committer lines have the form: "name <email> date"
+	-- The email is always present, even if empty "<>"
+	parsemetadata l = CommitMetaData
+		{ commitName = whenset $ S.init name_sp
+		, commitEmail = whenset email
+		, commitDate = whenset $ S.drop 2 gt_sp_date
+		}
+	  where
+		(name_sp, rest) = S.break (== lt) l
+		(email, gt_sp_date) = S.break (== gt) (S.drop 1 rest)
+		whenset v
+			| S.null v = Nothing
+			| otherwise = Just (decodeBS v)
+
+	nl = fromIntegral (ord '\n')
+	sp = fromIntegral (ord ' ')
+	lt = fromIntegral (ord '<')
+	gt = fromIntegral (ord '>')
+
+{- Uses cat-file to stream the contents of the files as efficiently
+ - as possible. This is much faster than querying it repeatedly per file.
+ -}
+catObjectStreamLsTree
+	:: (MonadMask m, MonadIO m)
+	=> [LsTree.TreeItem]
+	-> (LsTree.TreeItem -> Maybe v)
+	-> Repo
+	-> (IO (Maybe (v, Maybe L.ByteString)) -> m a)
+	-> m a
+catObjectStreamLsTree l want repo reader = withCatFileStream False repo $
+	\c hin hout -> bracketIO
+		(async $ feeder c hin)
+		cancel
+		(const (reader (catObjectReader readObjectContent c hout)))
+  where
+	feeder c h = do
+		forM_ l $ \ti -> case want ti of
+			Nothing -> return ()
+			Just v -> do
+				let sha = LsTree.sha ti
+				liftIO $ writeChan c (sha, v)
+				S8.hPutStrLn h (fromRef' sha)
+		hClose h
+
+catObjectStream
+	:: (MonadMask m, MonadIO m)
+	=> Repo
+	-> (
+	    ((v, Ref) -> IO ()) -- ^ call to feed values in
+	    -> IO () -- call once all values are fed in
+	    -> IO (Maybe (v, Maybe L.ByteString)) -- call to read results
+	    -> m a
+	   )
+	-> m a
+catObjectStream repo a = withCatFileStream False repo go
+  where
+	go c hin hout = a
+		(feeder c hin)
+		(hClose hin)
+		(catObjectReader readObjectContent c hout)
+	feeder c h (v, ref) = do
+		writeChan c (ref, v)
+		S8.hPutStrLn h (fromRef' ref)
+
+catObjectMetaDataStream
+	:: (MonadMask m, MonadIO m)
+	=> Repo
+	-> (
+	    ((v, Ref) -> IO ()) -- ^ call to feed values in
+	    -> IO () -- call once all values are fed in
+	    -> IO (Maybe (v, Maybe (Sha, FileSize, ObjectType))) -- call to read results
+	    -> m a
+	   )
+	-> m a
+catObjectMetaDataStream repo a = withCatFileStream True repo go
+  where
+	go c hin hout = a
+		(feeder c hin)
+		(hClose hin)
+		(catObjectReader (\_h r -> pure (conv r)) c hout)
+	
+	feeder c h (v, ref) = do
+		liftIO $ writeChan c (ref, v)
+		S8.hPutStrLn h (fromRef' ref)
+	
+	conv (ParsedResp sha ty sz) = (sha, sz, ty)
+	conv DNE = error "internal"
+
+catObjectReader
+	:: (Handle -> ParsedResp -> IO t)
+	-> Chan (Ref, a)
+	-> Handle
+	-> IO (Maybe (a, Maybe t))
+catObjectReader getv c h = ifM (hIsEOF h)
+	( return Nothing
+	, do
+		(ref, f) <- liftIO $ readChan c
+		resp <- S8.hGetLine h
+		case parseResp ref resp of
+			Just r@(ParsedResp {}) -> do
+				v <- getv h r
+				return (Just (f, Just v))
+			Just DNE -> return (Just (f, Nothing))
+			Nothing -> error $ "unknown response from git cat-file " ++ show resp
+	)
+
+withCatFileStream
+	:: (MonadMask m, MonadIO m)
+	=> Bool
+	-> Repo
+	-> (Chan v -> Handle -> Handle -> m a)
+	-> m a
+withCatFileStream check repo reader = assertLocal repo $
+	bracketIO start stop $ \(c, hin, hout, _) -> reader c hin hout
+  where
+	params = catMaybes
+		[ Just $ Param "cat-file"
+		, Just $ Param ("--batch" ++ (if check then "-check" else "") ++ "=" ++ batchFormat)
+		-- This option makes it faster, but is not present in
+		-- older versions of git.
+		, if BuildVersion.older "2.4.3"
+			then Nothing
+			else Just $ Param "--buffer"
+		]
+
+	start = do
+		let p = gitCreateProcess params repo
+		(Just hin, Just hout, _, pid) <- createProcess p
+			{ std_in = CreatePipe
+			, std_out = CreatePipe
+			}
+		c <- newChan
+		return (c, hin, hout, pid)
+	
+	stop (_, hin, hout, pid) = do
+		hClose hin
+		hClose hout
+		void $ checkSuccessProcess pid
diff --git a/Git/CheckAttr.hs b/Git/CheckAttr.hs
new file mode 100644
index 0000000000..f93c9075cf
--- /dev/null
+++ b/Git/CheckAttr.hs
@@ -0,0 +1,101 @@
+{- git check-attr interface
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.CheckAttr where
+
+import Common
+import Git
+import Git.Command
+import qualified Utility.CoProcess as CoProcess
+import qualified Utility.RawFilePath as R
+
+import System.IO.Error
+import qualified Data.ByteString as B
+
+type CheckAttrHandle = (CoProcess.CoProcessHandle, [Attr], RawFilePath)
+
+type Attr = String
+
+{- Starts git check-attr running to look up the specified attributes
+ - and returns a handle.  -}
+checkAttrStart :: [Attr] -> Repo -> IO CheckAttrHandle
+checkAttrStart attrs repo = do
+	currdir <- R.getCurrentDirectory
+	h <- gitCoProcessStart True params repo
+	return (h, attrs, currdir)
+  where
+	params =
+		[ Param "check-attr" 
+		, Param "-z"
+		, Param "--stdin"
+		] ++ map Param attrs ++
+		[ Param "--" ]
+
+checkAttrStop :: CheckAttrHandle -> IO ()
+checkAttrStop (h, _, _) = CoProcess.stop h
+
+checkAttr :: CheckAttrHandle -> Attr -> RawFilePath -> IO String
+checkAttr h want file = checkAttrs h [want] file >>= return . \case
+	(v:_) -> v
+	[] -> ""
+
+{- Gets attributes of a file. When an attribute is not specified,
+ - returns "" for it. -}
+checkAttrs :: CheckAttrHandle -> [Attr] -> RawFilePath -> IO [String]
+checkAttrs (h, attrs, currdir) want file = do
+	l <- CoProcess.query h send (receive "")
+	return (getvals l want)
+  where
+	getvals _ [] = []
+	getvals l (x:xs) = case map snd $ filter (\(attr, _) -> attr == x) l of
+			["unspecified"] -> "" : getvals l xs
+			[v] -> v : getvals l xs
+			_ -> giveup $ "unable to determine " ++ x ++ " attribute of " ++ fromRawFilePath file
+
+	send to = B.hPutStr to $ file' `B.snoc` 0
+	receive c from = do
+		s <- hGetSomeString from 1024
+		if null s
+			then eofError
+			else do
+				let v = c ++ s
+				maybe (receive v from) return (parse v)
+	eofError = ioError $ mkIOError userErrorType "git check-attr EOF" Nothing Nothing
+	parse s
+		-- new null separated output
+		| '\0' `elem` s = if "\0" `isSuffixOf` s
+			then
+				let bits = segment (== '\0') s
+				in if length bits == (numattrs * 3) + 1
+					then Just $ getattrvalues bits []
+					else Nothing -- more attributes to come
+			else Nothing -- output incomplete
+		-- old one line per value output
+		| otherwise = if "\n" `isSuffixOf` s
+			then
+				let ls = lines s
+				in if length ls == numattrs
+					then Just $ map (\(attr, val) -> (attr, oldattrvalue attr val))
+						(zip attrs ls)
+					else Nothing -- more attributes to come
+			else Nothing -- line incomplete
+	numattrs = length attrs
+
+	{- git check-attr chokes on some absolute filenames,
+	 - so make sure the filename is relative. -}
+	file' = relPathDirToFileAbs currdir $ absPathFrom currdir file
+	oldattrvalue attr l = end bits !! 0
+	  where
+		bits = split sep l
+		sep = ": " ++ attr ++ ": "
+	getattrvalues (_filename:attr:val:rest) c = getattrvalues rest ((attr,val):c)
+	getattrvalues _ c = c
+
+{- User may enter this to override a previous attr setting, when they wish
+ - to not specify an attr for some files. -}
+unspecifiedAttr :: String
+unspecifiedAttr = "!"
diff --git a/Git/CheckIgnore.hs b/Git/CheckIgnore.hs
new file mode 100644
index 0000000000..46a5b25cf3
--- /dev/null
+++ b/Git/CheckIgnore.hs
@@ -0,0 +1,71 @@
+{- git check-ignore interface
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.CheckIgnore (
+	CheckIgnoreHandle,
+	checkIgnoreStart,
+	checkIgnoreStop,
+	checkIgnored
+) where
+
+import Common
+import Git
+import Git.Command
+import qualified Utility.CoProcess as CoProcess
+
+import System.IO.Error
+import qualified Data.ByteString as B
+
+type CheckIgnoreHandle = CoProcess.CoProcessHandle
+
+{- Starts git check-ignore running, and returns a handle.
+ -
+ - This relies on git check-ignore --non-matching -v outputting
+ - lines for both matching an non-matching files. Also relies on
+ - GIT_FLUSH behavior flushing the output buffer when git check-ignore
+ - is piping to us.
+ -
+ - check-ignore does not support --literal-pathspecs, so remove that
+ - from the gitGlobalOpts if set.
+ -}
+checkIgnoreStart :: Repo -> IO CheckIgnoreHandle
+checkIgnoreStart repo = gitCoProcessStart True params repo'
+  where
+	params =
+		[ Param "check-ignore" 
+		, Param "-z"
+		, Param "--stdin"
+		, Param "--verbose"
+		, Param "--non-matching"
+		]
+	repo' = repo { gitGlobalOpts = filter (not . pathspecs) (gitGlobalOpts repo) }
+	pathspecs (Param "--literal-pathspecs") = True
+	pathspecs _ = False
+
+{- For some reason, check-ignore --batch always exits nonzero, 
+ - so ignore any error. -}
+checkIgnoreStop :: CheckIgnoreHandle -> IO ()
+checkIgnoreStop = void . tryIO . CoProcess.stop
+
+{- Returns True if a file is ignored. -}
+checkIgnored :: CheckIgnoreHandle -> RawFilePath -> IO Bool
+checkIgnored h file = CoProcess.query h send (receive "")
+  where
+	send to = do
+		B.hPutStr to $ file `B.snoc` 0
+		hFlush to
+	receive c from = do
+		s <- hGetSomeString from 1024
+		if null s
+			then eofError
+			else do
+				let v = c ++ s
+				maybe (receive v from) return (parse v)
+	parse s = case segment (== '\0') s of
+		(_source:_line:pattern:_pathname:_eol:[]) -> Just $ not $ null pattern
+		_ -> Nothing
+	eofError = ioError $ mkIOError userErrorType "git cat-file EOF" Nothing Nothing
diff --git a/Git/Command.hs b/Git/Command.hs
new file mode 100644
index 0000000000..894f6ae689
--- /dev/null
+++ b/Git/Command.hs
@@ -0,0 +1,149 @@
+{- running git commands
+ -
+ - Copyright 2010-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Git.Command where
+
+import Common
+import Git
+import Git.Types
+import qualified Utility.CoProcess as CoProcess
+
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString as S
+
+{- Constructs a git command line operating on the specified repo. -}
+gitCommandLine :: [CommandParam] -> Repo -> [CommandParam]
+gitCommandLine params r@(Repo { location = l@(Local { } ) }) =
+	setdir ++ settree ++ gitGlobalOpts r ++ params
+  where
+	setdir
+		| gitEnvOverridesGitDir r = []
+		| otherwise = [Param $ "--git-dir=" ++ fromRawFilePath (gitdir l)]
+	settree = case worktree l of
+		Nothing -> []
+		Just t -> [Param $ "--work-tree=" ++ fromRawFilePath t]
+gitCommandLine _ repo = assertLocal repo $ error "internal"
+
+{- Runs git in the specified repo. -}
+runBool :: [CommandParam] -> Repo -> IO Bool
+runBool params repo = assertLocal repo $
+	boolSystemEnv "git" (gitCommandLine params repo) (gitEnv repo)
+
+{- Runs git in the specified repo, throwing an error if it fails. -}
+run :: [CommandParam] -> Repo -> IO ()
+run params repo = assertLocal repo $
+	unlessM (runBool params repo) $
+		giveup $ "git " ++ show params ++ " failed"
+
+{- Runs git and forces it to be quiet, throwing an error if it fails. -}
+runQuiet :: [CommandParam] -> Repo -> IO ()
+runQuiet params repo = withNullHandle $ \nullh ->
+	let p = (proc "git" $ toCommand $ gitCommandLine (params) repo)
+		{ env = gitEnv repo
+		, std_out = UseHandle nullh
+		, std_err = UseHandle nullh
+		}
+	in withCreateProcess p $ \_ _ _ -> forceSuccessProcess p
+
+{- Runs a git command and returns its output, lazily.
+ -
+ - Also returns an action that should be used when the output is all
+ - read, that will wait on the command, and
+ - return True if it succeeded.
+ -}
+pipeReadLazy :: [CommandParam] -> Repo -> IO (L.ByteString, IO Bool)
+pipeReadLazy params repo = assertLocal repo $ do
+	(_, Just h, _, pid) <- createProcess p { std_out = CreatePipe }
+	c <- L.hGetContents h
+	return (c, checkSuccessProcess pid)
+  where
+	p  = gitCreateProcess params repo
+
+{- Runs a git command, and returns its output, strictly.
+ -
+ - Nonzero exit status is ignored.
+ -}
+pipeReadStrict :: [CommandParam] -> Repo -> IO S.ByteString
+pipeReadStrict = pipeReadStrict' id
+
+pipeReadStrict' :: (CreateProcess -> CreateProcess) -> [CommandParam] -> Repo -> IO S.ByteString
+pipeReadStrict' fp params repo = assertLocal repo $ withCreateProcess p go
+  where
+	p = fp (gitCreateProcess params repo) { std_out = CreatePipe }
+
+	go _ (Just outh) _ pid = do
+		output <- S.hGetContents outh
+		hClose outh
+		void $ waitForProcess pid
+		return output
+	go _ _ _ _ = error "internal"
+
+{- Runs a git command, feeding it an input, and returning its output,
+ - which is expected to be fairly small, since it's all read into memory
+ - strictly. -}
+pipeWriteRead :: [CommandParam] -> Maybe (Handle -> IO ()) -> Repo -> IO S.ByteString
+pipeWriteRead params writer repo = assertLocal repo $
+	writeReadProcessEnv "git" (toCommand $ gitCommandLine params repo) 
+		(gitEnv repo) writer'
+  where
+	writer' = case writer of
+		Nothing -> Nothing
+		Just a -> Just $ \h -> do
+			adjusthandle h
+			a h
+	adjusthandle h = hSetNewlineMode h noNewlineTranslation
+
+{- Runs a git command, feeding it input on a handle with an action. -}
+pipeWrite :: [CommandParam] -> Repo -> (Handle -> IO ()) -> IO ()
+pipeWrite params repo feeder = assertLocal repo $
+	let p = (gitCreateProcess params repo)
+		{ std_in = CreatePipe }
+	in withCreateProcess p (go p)
+  where
+	go p (Just hin) _ _ pid = do
+		feeder hin
+		hClose hin
+		forceSuccessProcess p pid
+	go _ _ _ _ _ = error "internal"
+
+{- Reads null terminated output of a git command (as enabled by the -z 
+ - parameter), and splits it. -}
+pipeNullSplit :: [CommandParam] -> Repo -> IO ([L.ByteString], IO Bool)
+pipeNullSplit params repo = do
+	(s, cleanup) <- pipeReadLazy params repo
+	return (filter (not . L.null) $ L.split 0 s, cleanup)
+
+{- Reads lazily, but copies each part to a strict ByteString for
+ - convenience.
+ -}
+pipeNullSplit' :: [CommandParam] -> Repo -> IO ([S.ByteString], IO Bool)
+pipeNullSplit' params repo = do
+	(s, cleanup) <- pipeNullSplit params repo
+	return (map L.toStrict s, cleanup)
+
+pipeNullSplitStrict :: [CommandParam] -> Repo -> IO [S.ByteString]
+pipeNullSplitStrict params repo = do
+	s <- pipeReadStrict params repo
+	return $ filter (not . S.null) $ S.split 0 s
+
+{- Runs a git command as a coprocess. -}
+gitCoProcessStart :: Bool -> [CommandParam] -> Repo -> IO CoProcess.CoProcessHandle
+gitCoProcessStart restartable params repo = CoProcess.start numrestarts "git"
+	(toCommand $ gitCommandLine params repo)
+	(gitEnv repo)
+  where
+	{- If a long-running git command like cat-file --batch
+	 - crashes, it will likely start up again ok. If it keeps crashing
+	 - 10 times, something is badly wrong. -}
+	numrestarts = if restartable then 10 else 0
+
+gitCreateProcess :: [CommandParam] -> Repo -> CreateProcess
+gitCreateProcess params repo =
+	(proc "git" $ toCommand $ gitCommandLine params repo)
+			{ env = gitEnv repo }
diff --git a/Git/Command/Batch.hs b/Git/Command/Batch.hs
new file mode 100644
index 0000000000..c4008137f4
--- /dev/null
+++ b/Git/Command/Batch.hs
@@ -0,0 +1,19 @@
+{- running batch git commands
+ -
+ - Copyright 2010-2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.Command.Batch where
+
+import Common
+import Git
+import Git.Command
+import Utility.Batch
+
+{- Runs git in batch mode. -}
+run :: BatchCommandMaker -> [CommandParam] -> Repo -> IO Bool
+run batchmaker params repo = assertLocal repo $ do
+	let (cmd, params') = batchmaker ("git", gitCommandLine params repo)
+	boolSystemEnv cmd params' (gitEnv repo)
diff --git a/Git/Config.hs b/Git/Config.hs
new file mode 100644
index 0000000000..4423ea6d48
--- /dev/null
+++ b/Git/Config.hs
@@ -0,0 +1,341 @@
+{- git repository configuration handling
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.Config where
+
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as S8
+import Data.Char
+import qualified System.FilePath.ByteString as P
+import Control.Concurrent.Async
+
+import Common
+import Git
+import Git.Types
+import qualified Git.Command
+import qualified Git.Construct
+import Utility.UserInfo
+import Utility.Process.Transcript
+import Utility.Debug
+
+{- Returns a single git config setting, or a fallback value if not set. -}
+get :: ConfigKey -> ConfigValue -> Repo -> ConfigValue
+get key fallback repo = M.findWithDefault fallback key (config repo)
+
+{- Returns a list of values. -}
+getList :: ConfigKey -> Repo -> [ConfigValue]
+getList key repo = M.findWithDefault [] key (fullconfig repo)
+
+{- Returns a single git config setting, if set. -}
+getMaybe :: ConfigKey -> Repo -> Maybe ConfigValue
+getMaybe key repo = M.lookup key (config repo)
+
+{- Runs git config and populates a repo with its config.
+ - Avoids re-reading config when run repeatedly. -}
+read :: Repo -> IO Repo
+read repo@(Repo { config = c })
+	| c == M.empty = read' repo
+	| otherwise = return repo
+
+{- Reads config even if it was read before. -}
+reRead :: Repo -> IO Repo
+reRead r = read' $ r
+	{ config = M.empty
+	, fullconfig = M.empty
+	}
+
+{- Cannot use pipeRead because it relies on the config having been already
+ - read. Instead, chdir to the repo and run git config.
+ -}
+read' :: Repo -> IO Repo
+read' repo = go repo
+  where
+	-- Passing --git-dir changes git's behavior when run in a
+	-- repository belonging to another user. When the git directory
+	-- was explicitly specified, pass that in order to get the local
+	-- git config.
+	go Repo { location = Local { gitdir = d } }
+		| gitDirSpecifiedExplicitly repo = git_config ["--git-dir=."] d
+	-- Run in worktree when there is one, since running in the .git
+	-- directory will trigger safe.bareRepository=explicit, even
+	-- when not in a bare repository.
+	go Repo { location = Local { worktree = Just d } } = git_config [] d
+	go Repo { location = Local { gitdir = d } } = git_config [] d
+	go Repo { location = LocalUnknown d } = git_config [] d
+	go _ = assertLocal repo $ error "internal"
+	git_config addparams d = withCreateProcess p (git_config' p)
+	  where
+		params = addparams ++ explicitrepoparams
+			++ ["config", "--null", "--list"]
+		p = (proc "git" params)
+			{ cwd = Just (fromRawFilePath d)
+			, env = gitEnv repo
+			, std_out = CreatePipe 
+			}
+		explicitrepoparams = if repoPathSpecifiedExplicitly repo 
+			then 
+				-- Use * rather than d, because git treats
+				-- "dir/" differently than "dir" when comparing
+				-- for safe.directory purposes.
+				[ "-c", "safe.directory=*"
+				, "-c", "safe.bareRepository=all" 
+				]
+			else []
+	git_config' p _ (Just hout) _ pid = 
+		forceSuccessProcess p pid
+			`after`
+		hRead repo ConfigNullList hout
+	git_config' _ _ _ _ _ = error "internal"
+
+{- Gets the global git config, returning a dummy Repo containing it. -}
+global :: IO (Maybe Repo)
+global = do
+	home <- myHomeDir
+	ifM (doesFileExist $ home </> ".gitconfig")
+		( Just <$> withCreateProcess p go
+		, return Nothing
+		)
+  where
+	params = ["config", "--null", "--list", "--global"]
+	p = (proc "git" params)
+		{ std_out = CreatePipe }
+	go _ (Just hout) _ pid = 
+		forceSuccessProcess p pid
+			`after`
+		hRead (Git.Construct.fromUnknown) ConfigNullList hout
+	go _ _ _ _ = error "internal"
+
+{- Reads git config from a handle and populates a repo with it. -}
+hRead :: Repo -> ConfigStyle -> Handle -> IO Repo
+hRead repo st h = do
+	val <- S.hGetContents h
+	let c = parse val st
+	debug (DebugSource "Git.Config") $ "git config read: " ++
+		show (map (\(k, v) -> (show k, map show v)) (M.toList c))
+	storeParsed c repo
+
+{- Stores a git config into a Repo, returning the new version of the Repo.
+ - The git config may be multiple lines, or a single line.
+ - Config settings can be updated incrementally.
+ -}
+store :: S.ByteString -> ConfigStyle -> Repo -> IO Repo
+store s st = storeParsed (parse s st)
+
+storeParsed :: M.Map ConfigKey [ConfigValue] -> Repo -> IO Repo
+storeParsed c repo = updateLocation $ repo
+	{ config = (M.map Prelude.head c) `M.union` config repo
+	, fullconfig = M.unionWith (++) c (fullconfig repo)
+	}
+
+{- Stores a single config setting in a Repo, returning the new version of
+ - the Repo. Config settings can be updated incrementally. -}
+store' :: ConfigKey -> ConfigValue -> Repo -> Repo
+store' k v repo = repo
+	{ config = M.singleton k v `M.union` config repo
+	, fullconfig = M.unionWith (++) (M.singleton k [v]) (fullconfig repo)
+	}
+
+{- Updates the location of a repo, based on its configuration.
+ -
+ - Git.Construct makes LocalUknown repos, of which only a directory is
+ - known. Once the config is read, this can be fixed up to a Local repo, 
+ - based on the core.bare and core.worktree settings.
+ -}
+updateLocation :: Repo -> IO Repo
+updateLocation r@(Repo { location = LocalUnknown d }) = case isBare r of
+	Just True -> ifM (doesDirectoryExist (fromRawFilePath dotgit))
+		( updateLocation' r $ Local dotgit Nothing
+		, updateLocation' r $ Local d Nothing
+		)
+	Just False -> mknonbare
+	{- core.bare not in config, probably because safe.directory
+	 - did not allow reading the config -}
+	Nothing -> ifM (Git.Construct.isBareRepo (fromRawFilePath d))
+		( mkbare
+		, mknonbare
+		)
+  where
+	dotgit = d P.</> ".git"
+	-- git treats eg ~/foo as a bare git repository located in
+	-- ~/foo/.git if ~/foo/.git/config has core.bare=true
+	mkbare = ifM (doesDirectoryExist (fromRawFilePath dotgit))
+		( updateLocation' r $ Local dotgit Nothing
+		, updateLocation' r $ Local d Nothing
+		)
+	mknonbare = updateLocation' r $ Local dotgit (Just d)
+
+updateLocation r@(Repo { location = l@(Local {}) }) = updateLocation' r l
+updateLocation r = return r
+
+updateLocation' :: Repo -> RepoLocation -> IO Repo
+updateLocation' r l@(Local {}) = do
+	l' <- case getMaybe "core.worktree" r of
+		Nothing -> return l
+		Just (ConfigValue d) -> do
+			{- core.worktree is relative to the gitdir -}
+			top <- absPath (gitdir l)
+			let p = absPathFrom top d
+			return $ l { worktree = Just p }
+		Just NoConfigValue -> return l
+	return $ r { location = l' }
+updateLocation' r l = return r { location = l }
+
+data ConfigStyle = ConfigList | ConfigNullList
+
+{- Parses git config --list or git config --null --list output into a
+ - config map. -}
+parse :: S.ByteString -> ConfigStyle -> M.Map ConfigKey [ConfigValue]
+parse s st
+	| S.null s = M.empty
+	| otherwise = case st of
+		ConfigList -> sep eq $ S.split nl s
+		ConfigNullList -> sep nl $ S.split 0 s
+  where
+	nl = fromIntegral (ord '\n')
+	eq = fromIntegral (ord '=')
+
+	sep c = M.fromListWith (++)
+		. map (\(k,v) -> (ConfigKey k, [mkval v])) 
+		. map (S.break (== c))
+	
+	mkval v 
+		| S.null v = NoConfigValue
+		| otherwise = ConfigValue (S.drop 1 v)
+
+{- Checks if a string from git config is a true/false value. -}
+isTrueFalse :: String -> Maybe Bool
+isTrueFalse = isTrueFalse' . ConfigValue . encodeBS
+
+isTrueFalse' :: ConfigValue -> Maybe Bool
+isTrueFalse' (ConfigValue s)
+	| s' == "yes" = Just True
+	| s' == "on" = Just True
+	| s' == "true" = Just True
+	| s' == "1" = Just True
+
+	| s' == "no" = Just False
+	| s' == "off" = Just False
+	| s' == "false" = Just False
+	| s' == "0" = Just False
+	| s' == "" = Just False
+
+	-- Git treats any number other than 0 as true,
+	-- including negative numbers.
+	| S8.all (\c -> isDigit c || c == '-') s' = Just True
+
+	| otherwise = Nothing
+  where
+	s' = S8.map toLower s
+isTrueFalse' NoConfigValue = Just True
+
+boolConfig :: Bool -> String
+boolConfig True = "true"
+boolConfig False = "false"
+
+boolConfig' :: Bool -> S.ByteString
+boolConfig' True = "true"
+boolConfig' False = "false"
+
+{- Note that repoIsLocalBare is often better to use than this. -}
+isBare :: Repo -> Maybe Bool
+isBare r = isTrueFalse' =<< getMaybe coreBare r
+
+coreBare :: ConfigKey
+coreBare = "core.bare"
+
+{- Runs a command to get the configuration of a repo,
+ - and returns a repo populated with the configuration, as well as the raw
+ - output and the standard error of the command. -}
+fromPipe :: Repo -> String -> [CommandParam] -> ConfigStyle -> IO (Either SomeException (Repo, S.ByteString, String))
+fromPipe r cmd params st = tryNonAsync $ withCreateProcess p go
+  where
+	p = (proc cmd $ toCommand params)
+		{ std_out = CreatePipe
+		, std_err = CreatePipe
+		}
+	go _ (Just hout) (Just herr) pid =
+		withAsync (getstderr pid herr []) $ \errreader -> do
+			val <- S.hGetContents hout
+			err <- wait errreader
+			forceSuccessProcess p pid
+			r' <- store val st r
+			return (r', val, err)
+	go _ _ _ _ = error "internal"
+
+	getstderr pid herr c = hGetLineUntilExitOrEOF pid herr >>= \case
+		Just l -> getstderr pid herr (l:c)
+		Nothing -> return (unlines (reverse c))
+
+{- Reads git config from a specified file and returns the repo populated
+ - with the configuration. -}
+fromFile :: Repo -> FilePath -> IO (Either SomeException (Repo, S.ByteString, String))
+fromFile r f = fromPipe r "git"
+	[ Param "config"
+	, Param "--file"
+	, File f
+	, Param "--list"
+	] ConfigList
+
+{- Changes a git config setting in .git/config. -}
+change :: ConfigKey -> S.ByteString -> Repo -> IO Bool
+change (ConfigKey k) v = Git.Command.runBool
+	[ Param "config"
+	, Param (decodeBS k)
+	, Param (decodeBS v)
+	]
+
+{- Changes a git config setting in the specified config file.
+ - (Creates the file if it does not already exist.) -}
+changeFile :: FilePath -> ConfigKey -> S.ByteString -> IO Bool
+changeFile f (ConfigKey k) v = boolSystem "git"
+	[ Param "config"
+	, Param "--file"
+	, File f
+	, Param (decodeBS k)
+	, Param (decodeBS v)
+	]
+
+{- Unsets a git config setting, in both the git repo,
+ - and the cached config in the Repo.
+ -
+ - If unsetting the config fails, including in a read-only repo, or
+ - when the config is not set, returns Nothing.
+ -}
+unset :: ConfigKey -> Repo -> IO (Maybe Repo)
+unset ck@(ConfigKey k) r = ifM (Git.Command.runBool ps r)
+	( return $ Just $ r { config = M.delete ck (config r) }
+	, return Nothing
+	)
+  where
+	ps = [Param "config", Param "--unset-all", Param (decodeBS k)]
+
+{- git "fixed" CVE-2022-24765 by preventing git-config from
+ - listing per-repo configs when the repo is not owned by
+ - the current user. Detect if this fix is in effect for the
+ - repo.
+ -}
+checkRepoConfigInaccessible :: Repo -> IO Bool
+checkRepoConfigInaccessible r
+	-- When --git-dir or GIT_DIR is used to specify the git
+	-- directory, git does not check for CVE-2022-24765.
+	| gitDirSpecifiedExplicitly r = return False
+	| otherwise = do
+		-- Cannot use gitCommandLine here because specifying --git-dir
+		-- will bypass the git security check.
+		let p = (proc "git" ["config", "--local", "--list"])
+			{ cwd = Just (fromRawFilePath (repoPath r))
+			, env = gitEnv r
+			}
+		(out, ok) <- processTranscript' p Nothing
+		if not ok
+			then do
+				debug (DebugSource "Git.Config") ("config output: " ++ out)
+				return True
+			else return False
diff --git a/Git/ConfigTypes.hs b/Git/ConfigTypes.hs
new file mode 100644
index 0000000000..6a8608eb29
--- /dev/null
+++ b/Git/ConfigTypes.hs
@@ -0,0 +1,53 @@
+{- git config types
+ -
+ - Copyright 2012-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.ConfigTypes where
+
+import Data.Char
+import Numeric
+import qualified Data.ByteString.Char8 as S8
+import System.PosixCompat.Types
+
+import Common
+import Git
+import Git.Types
+import qualified Git.Config
+
+data SharedRepository = UnShared | GroupShared | AllShared | UmaskShared FileMode
+	deriving (Eq)
+
+getSharedRepository :: Repo -> SharedRepository
+getSharedRepository r =
+	case Git.Config.getMaybe "core.sharedrepository" r of
+		Just (ConfigValue v) -> case S8.map toLower v of
+			"1" -> GroupShared
+			"2" -> AllShared
+			"group" -> GroupShared
+			"true" -> GroupShared
+			"all" -> AllShared
+			"world" -> AllShared
+			"everybody" -> AllShared
+			_ -> maybe UnShared UmaskShared 
+				(fmap fst $ headMaybe $ readOct $ decodeBS v)
+		Just NoConfigValue -> UnShared
+		Nothing -> UnShared
+
+data DenyCurrentBranch = UpdateInstead | RefusePush | WarnPush | IgnorePush
+	deriving (Eq)
+
+getDenyCurrentBranch :: Repo -> DenyCurrentBranch
+getDenyCurrentBranch r = 
+	case Git.Config.getMaybe "receive.denycurrentbranch" r of
+		Just (ConfigValue v) -> case S8.map toLower v of
+			"updateinstead" -> UpdateInstead
+			"warn" -> WarnPush
+			"ignore" -> IgnorePush
+			_ -> RefusePush
+		Just NoConfigValue -> RefusePush
+		Nothing -> RefusePush
diff --git a/Git/Construct.hs b/Git/Construct.hs
new file mode 100644
index 0000000000..76261cabf2
--- /dev/null
+++ b/Git/Construct.hs
@@ -0,0 +1,294 @@
+{- Construction of Git Repo objects
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE CPP #-}
+
+module Git.Construct (
+	fromCwd,
+	fromAbsPath,
+	fromPath,
+	fromUrl,
+	fromUnknown,
+	localToUrl,
+	remoteNamed,
+	remoteNamedFromKey,
+	fromRemotes,
+	fromRemoteLocation,
+	repoAbsPath,
+	checkForRepo,
+	newFrom,
+	adjustGitDirFile,
+	isBareRepo,
+) where
+
+#ifndef mingw32_HOST_OS
+import System.Posix.User
+#endif
+import qualified Data.Map as M
+import Network.URI
+
+import Common
+import Git.Types
+import Git
+import Git.Remote
+import Git.FilePath
+import qualified Git.Url as Url
+import Utility.UserInfo
+import Utility.Url.Parse
+import qualified Utility.RawFilePath as R
+
+import qualified Data.ByteString as B
+import qualified System.FilePath.ByteString as P
+
+{- Finds the git repository used for the cwd, which may be in a parent
+ - directory. -}
+fromCwd :: IO (Maybe Repo)
+fromCwd = R.getCurrentDirectory >>= seekUp
+  where
+	seekUp dir = do
+		r <- checkForRepo dir
+		case r of
+			Nothing -> case upFrom dir of
+				Nothing -> return Nothing
+				Just d -> seekUp d
+			Just loc -> pure $ Just $ newFrom loc
+
+{- Local Repo constructor, accepts a relative or absolute path. -}
+fromPath :: RawFilePath -> IO Repo
+fromPath dir
+	-- When dir == "foo/.git", git looks for "foo/.git/.git",
+	-- and failing that, uses "foo" as the repository.
+	| (P.pathSeparator `B.cons` ".git") `B.isSuffixOf` canondir =
+		ifM (doesDirectoryExist $ fromRawFilePath dir </> ".git")
+			( ret dir
+			, ret (P.takeDirectory canondir)
+			)
+	| otherwise = ifM (doesDirectoryExist (fromRawFilePath dir))
+		( checkGitDirFile dir >>= maybe (ret dir) (pure . newFrom)
+		-- git falls back to dir.git when dir doesn't
+		-- exist, as long as dir didn't end with a
+		-- path separator
+		, if dir == canondir
+			then ret (dir <> ".git")
+			else ret dir
+		)
+  where
+	ret = pure . newFrom . LocalUnknown
+	canondir = P.dropTrailingPathSeparator dir
+
+{- Local Repo constructor, requires an absolute path to the repo be
+ - specified. -}
+fromAbsPath :: RawFilePath -> IO Repo
+fromAbsPath dir
+	| absoluteGitPath dir = fromPath dir
+	| otherwise =
+		giveup $ "internal error, " ++ show dir ++ " is not absolute"
+
+{- Construct a Repo for a remote's url.
+ -
+ - Git is somewhat forgiving about urls to repositories, allowing
+ - eg spaces that are not normally allowed unescaped in urls. Such
+ - characters get escaped.
+ -
+ - This will always succeed, even if the url cannot be parsed
+ - or is invalid, because git can also function despite remotes having
+ - such urls, only failing if such a remote is used.
+ -}
+fromUrl :: String -> IO Repo
+fromUrl url
+	| not (isURI url) = fromUrl' $ escapeURIString isUnescapedInURI url
+	| otherwise = fromUrl' url
+
+fromUrl' :: String -> IO Repo
+fromUrl' url
+	| "file://" `isPrefixOf` url = case parseURIPortable url of
+		Just u -> fromAbsPath $ toRawFilePath $ unEscapeString $ uriPath u
+		Nothing -> pure $ newFrom $ UnparseableUrl url
+	| otherwise = case parseURIPortable url of
+		Just u -> pure $ newFrom $ Url u
+		Nothing -> pure $ newFrom $ UnparseableUrl url
+
+{- Creates a repo that has an unknown location. -}
+fromUnknown :: Repo
+fromUnknown = newFrom Unknown
+
+{- Converts a local Repo into a remote repo, using the reference repo
+ - which is assumed to be on the same host. -}
+localToUrl :: Repo -> Repo -> Repo
+localToUrl reference r
+	| not $ repoIsUrl reference = error "internal error; reference repo not url"
+	| repoIsUrl r = r
+	| otherwise = case (Url.authority reference, Url.scheme reference) of
+		(Just auth, Just s) -> 
+			let absurl = concat
+				[ s
+				, "//"
+				, auth
+				, fromRawFilePath (repoPath r)
+				]
+			in r { location = Url $ fromJust $ parseURIPortable absurl }
+		_ -> r
+
+{- Calculates a list of a repo's configured remotes, by parsing its config. -}
+fromRemotes :: Repo -> IO [Repo]
+fromRemotes repo = catMaybes <$> mapM construct remotepairs
+  where
+	filterconfig f = filter f $ M.toList $ config repo
+	filterkeys f = filterconfig (\(k,_) -> f k)
+	remotepairs = filterkeys isRemoteUrlKey
+	construct (k,v) = remoteNamedFromKey k $
+		fromRemoteLocation (fromConfigValue v) False repo
+
+{- Sets the name of a remote when constructing the Repo to represent it. -}
+remoteNamed :: String -> IO Repo -> IO Repo
+remoteNamed n constructor = do
+	r <- constructor
+	return $ r { remoteName = Just n }
+
+{- Sets the name of a remote based on the git config key, such as
+ - "remote.foo.url". -}
+remoteNamedFromKey :: ConfigKey -> IO Repo -> IO (Maybe Repo)
+remoteNamedFromKey k r = case remoteKeyToRemoteName k of
+	Nothing -> pure Nothing
+	Just n -> Just <$> remoteNamed n r
+
+{- Constructs a new Repo for one of a Repo's remotes using a given
+ - location (ie, an url). 
+ -
+ - knownurl can be true if the location is known to be an url. This allows
+ - urls that don't parse as urls to be used, returning UnparseableUrl.
+ - If knownurl is false, the location may still be an url, if it parses as
+ - one.
+ -}
+fromRemoteLocation :: String -> Bool -> Repo -> IO Repo
+fromRemoteLocation s knownurl repo = gen $ parseRemoteLocation s knownurl repo
+  where
+	gen (RemotePath p) = fromRemotePath p repo
+	gen (RemoteUrl u) = fromUrl u
+
+{- Constructs a Repo from the path specified in the git remotes of
+ - another Repo. -}
+fromRemotePath :: FilePath -> Repo -> IO Repo
+fromRemotePath dir repo = do
+	dir' <- expandTilde dir
+	fromPath $ repoPath repo P.</> toRawFilePath dir'
+
+{- Git remotes can have a directory that is specified relative
+ - to the user's home directory, or that contains tilde expansions.
+ - This converts such a directory to an absolute path.
+ - Note that it has to run on the system where the remote is.
+ -}
+repoAbsPath :: RawFilePath -> IO RawFilePath
+repoAbsPath d = do
+	d' <- expandTilde (fromRawFilePath d)
+	h <- myHomeDir
+	return $ toRawFilePath $ h </> d'
+
+expandTilde :: FilePath -> IO FilePath
+#ifdef mingw32_HOST_OS
+expandTilde = return
+#else
+expandTilde p = expandt True p
+	-- If unable to expand a tilde, eg due to a user not existing,
+	-- use the path as given.
+	`catchNonAsync` (const (return p))
+  where
+	expandt _ [] = return ""
+	expandt _ ('/':cs) = do
+		v <- expandt True cs
+		return ('/':v)
+	expandt True ('~':'/':cs) = do
+		h <- myHomeDir
+		return $ h </> cs
+	expandt True "~" = myHomeDir
+	expandt True ('~':cs) = do
+		let (name, rest) = findname "" cs
+		u <- getUserEntryForName name
+		return $ homeDirectory u </> rest
+	expandt _ (c:cs) = do
+		v <- expandt False cs
+		return (c:v)
+	findname n [] = (n, "")
+	findname n (c:cs)
+		| c == '/' = (n, cs)
+		| otherwise = findname (n++[c]) cs
+#endif
+
+{- Checks if a git repository exists in a directory. Does not find
+ - git repositories in parent directories. -}
+checkForRepo :: RawFilePath -> IO (Maybe RepoLocation)
+checkForRepo dir = 
+	check isRepo $
+		check (checkGitDirFile dir) $
+			check (checkdir (isBareRepo dir')) $
+				return Nothing
+  where
+	check test cont = maybe cont (return . Just) =<< test
+	checkdir c = ifM c
+		( return $ Just $ LocalUnknown dir
+		, return Nothing
+		)
+	isRepo = checkdir $ 
+		doesFileExist (dir' </> ".git" </> "config")
+			<||>
+		-- A git-worktree lacks .git/config, but has .git/gitdir.
+		-- (Normally the .git is a file, not a symlink, but it can
+		-- be converted to a symlink and git will still work;
+		-- this handles that case.)
+		doesFileExist (dir' </>  ".git" </> "gitdir")
+	dir' = fromRawFilePath dir
+
+isBareRepo :: FilePath -> IO Bool
+isBareRepo dir = doesFileExist (dir </> "config")
+	<&&> doesDirectoryExist (dir </> "objects")
+
+-- Check for a .git file.
+checkGitDirFile :: RawFilePath -> IO (Maybe RepoLocation)
+checkGitDirFile dir = adjustGitDirFile' $ Local 
+	{ gitdir = dir P.</> ".git"
+	, worktree = Just dir
+	}
+
+-- git-submodule, git-worktree, and --separate-git-dir
+-- make .git be a file pointing to the real git directory.
+-- Detect that, and return a RepoLocation with gitdir pointing 
+-- to the real git directory.
+adjustGitDirFile :: RepoLocation -> IO RepoLocation
+adjustGitDirFile loc = fromMaybe loc <$> adjustGitDirFile' loc
+
+adjustGitDirFile' :: RepoLocation -> IO (Maybe RepoLocation)
+adjustGitDirFile' loc@(Local {}) = do
+	let gd = gitdir loc
+	c <- firstLine <$> catchDefaultIO "" (readFile (fromRawFilePath gd))
+	if gitdirprefix `isPrefixOf` c
+		then do
+			top <- fromRawFilePath . P.takeDirectory <$> absPath gd
+			return $ Just $ loc
+				{ gitdir = absPathFrom 
+					(toRawFilePath top)
+					(toRawFilePath 
+						(drop (length gitdirprefix) c))
+				}
+		else return Nothing
+ where
+	gitdirprefix = "gitdir: "
+adjustGitDirFile' _ = error "internal"
+
+newFrom :: RepoLocation -> Repo
+newFrom l = Repo
+	{ location = l
+	, config = M.empty
+	, fullconfig = M.empty
+	, remoteName = Nothing
+	, gitEnv = Nothing
+	, gitEnvOverridesGitDir = False
+	, gitGlobalOpts = []
+	, gitDirSpecifiedExplicitly = False
+	, repoPathSpecifiedExplicitly = False
+	}
+
diff --git a/Git/Credential.hs b/Git/Credential.hs
new file mode 100644
index 0000000000..3be4f438b2
--- /dev/null
+++ b/Git/Credential.hs
@@ -0,0 +1,126 @@
+{- git credential interface
+ -
+ - Copyright 2019-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.Credential where
+
+import Common
+import Git
+import Git.Types
+import Git.Command
+import qualified Git.Config as Config
+import Utility.Url
+import Utility.Url.Parse
+
+import qualified Data.Map as M
+import Network.URI
+import Control.Concurrent.STM
+
+data Credential = Credential { fromCredential :: M.Map String String }
+
+credentialUsername :: Credential -> Maybe String
+credentialUsername = M.lookup "username" . fromCredential
+
+credentialPassword :: Credential -> Maybe String
+credentialPassword = M.lookup "password" . fromCredential
+
+credentialBasicAuth :: Credential -> Maybe BasicAuth
+credentialBasicAuth cred = BasicAuth
+	<$> credentialUsername cred
+	<*> credentialPassword cred
+
+getBasicAuthFromCredential :: Repo -> TMVar CredentialCache -> GetBasicAuth
+getBasicAuthFromCredential r ccv u = do
+	(CredentialCache cc) <- atomically $ readTMVar ccv
+	case mkCredentialBaseURL r u of
+		Just bu -> case M.lookup bu cc of
+			Just c -> go (const noop) c
+			Nothing -> do
+				let storeincache = \c -> atomically $ do
+					(CredentialCache cc') <- takeTMVar ccv
+					putTMVar ccv (CredentialCache (M.insert bu c cc'))
+				go storeincache =<< getUrlCredential u r
+		Nothing -> go (const noop) =<< getUrlCredential u r
+  where
+	go storeincache c =
+		case credentialBasicAuth c of
+			Just ba -> return $ Just (ba, signalsuccess)
+			Nothing -> do
+				signalsuccess False
+				return Nothing
+	  where
+		signalsuccess True = do
+			() <- storeincache c
+			approveUrlCredential c r
+		signalsuccess False = rejectUrlCredential c r
+
+-- | This may prompt the user for the credential, or get a cached
+-- credential from git.
+getUrlCredential :: URLString -> Repo -> IO Credential
+getUrlCredential = runCredential "fill" . urlCredential
+
+-- | Call if the credential the user entered works, and can be cached for
+-- later use if git is configured to do so.
+approveUrlCredential :: Credential -> Repo -> IO ()
+approveUrlCredential c = void . runCredential "approve" c
+
+-- | Call if the credential the user entered does not work.
+rejectUrlCredential :: Credential -> Repo -> IO ()
+rejectUrlCredential c = void . runCredential "reject" c
+
+urlCredential :: URLString -> Credential
+urlCredential = Credential . M.singleton "url"
+
+runCredential :: String -> Credential -> Repo -> IO Credential
+runCredential action input r =
+	parseCredential . decodeBS <$> pipeWriteRead 
+		[ Param "credential"
+		, Param action
+		]
+		(Just (flip hPutStr formatinput))
+		r
+  where
+	formatinput = concat
+		[ formatCredential input
+		, "\n" -- blank line signifies end of input
+		]
+
+formatCredential :: Credential -> String
+formatCredential = unlines . map (\(k, v) -> k ++"=" ++ v) . M.toList . fromCredential
+
+parseCredential :: String -> Credential
+parseCredential = Credential . M.fromList . map go . lines
+  where
+	go l = case break (== '=') l of
+		(k, _:v) -> (k, v)
+		(k, []) -> (k, "")
+
+-- This is not the cache used by git, but is an in-process cache, 
+-- allowing a process to avoid prompting repeatedly when accessing related
+-- urls even when git is not configured to cache credentials.
+data CredentialCache = CredentialCache (M.Map CredentialBaseURL Credential)
+
+-- An url with the uriPath empty when credential.useHttpPath is false.
+--
+-- When credential.useHttpPath is true, no caching is done, since each 
+-- distinct url would need a different credential to be cached, which
+-- could cause the CredentialCache to use a lot of memory. Presumably,
+-- when credential.useHttpPath is false, one Credential is cached
+-- for each git repo accessed, and there are a reasonably small number of
+-- those, so the cache will not grow too large.
+data CredentialBaseURL = CredentialBaseURL URI
+	deriving (Show, Eq, Ord)
+
+mkCredentialBaseURL :: Repo -> URLString -> Maybe CredentialBaseURL
+mkCredentialBaseURL r s = do
+	u <- parseURIPortable s
+	let usehttppath = fromMaybe False $ Config.isTrueFalse' $
+		Config.get (ConfigKey "credential.useHttpPath") (ConfigValue "") r
+	if usehttppath
+		then Nothing
+		else Just $ CredentialBaseURL $ u { uriPath = "" }
diff --git a/Git/CurrentRepo.hs b/Git/CurrentRepo.hs
new file mode 100644
index 0000000000..747caaac9e
--- /dev/null
+++ b/Git/CurrentRepo.hs
@@ -0,0 +1,96 @@
+{- The current git repository.
+ -
+ - Copyright 2012-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.CurrentRepo where
+
+import Common
+import Git
+import Git.Types
+import Git.Construct
+import qualified Git.Config
+import Utility.Env
+import Utility.Env.Set
+import qualified Utility.RawFilePath as R
+
+import qualified Data.ByteString as B
+import qualified System.FilePath.ByteString as P
+
+{- Gets the current git repository.
+ -
+ - Honors GIT_DIR and GIT_WORK_TREE.
+ - Both environment variables are unset, to avoid confusing other git
+ - commands that also look at them. Instead, the Git module passes
+ - --work-tree and --git-dir to git commands it runs.
+ -
+ - When GIT_WORK_TREE or core.worktree are set, changes the working
+ - directory if necessary to ensure it is within the repository's work
+ - tree. While not needed for git commands, this is useful for anything
+ - else that looks for files in the worktree.
+ -
+ - Also works around a git bug when running some hooks. It
+ - runs the hooks in the top of the repository, but if GIT_WORK_TREE
+ - was relative (but not "."), it then points to the wrong directory.
+ - In this situation GIT_PREFIX contains the directory that 
+ - GIT_WORK_TREE is relative to.
+ -}
+get :: IO Repo
+get = do
+	gd <- getpathenv "GIT_DIR"
+	r <- configure gd =<< fromCwd
+	prefix <- getpathenv "GIT_PREFIX"
+	wt <- maybe (worktree (location r)) Just
+		<$> getpathenvprefix "GIT_WORK_TREE" prefix
+	case wt of
+		Nothing -> relPath r
+		Just d -> do
+			curr <- R.getCurrentDirectory
+			unless (d `dirContains` curr) $
+				setCurrentDirectory (fromRawFilePath d)
+			relPath $ addworktree wt r
+  where
+	getpathenv s = do
+		v <- getEnv s
+		case v of
+			Just d -> do
+				unsetEnv s
+				return (Just (toRawFilePath d))
+			Nothing -> return Nothing
+	
+	getpathenvprefix s (Just prefix) | not (B.null prefix) =
+		getpathenv s >>= \case
+			Nothing -> return Nothing
+			Just d
+				| d == "." -> return (Just d)
+				| otherwise -> Just 
+					<$> absPath (prefix P.</> d)
+	getpathenvprefix s _ = getpathenv s
+
+	configure Nothing (Just r) = Git.Config.read r
+	configure (Just d) _ = do
+		absd <- absPath d
+		curr <- R.getCurrentDirectory
+		loc <- adjustGitDirFile $ Local
+			{ gitdir = absd
+			, worktree = Just curr
+			}
+		r <- Git.Config.read $ (newFrom loc)
+			{ gitDirSpecifiedExplicitly = True }
+		return $ if fromMaybe False (Git.Config.isBare r)
+			then case location r of
+				loc'@(Local {}) -> r { location = loc' { worktree = Nothing } }
+				_ -> r
+			else r
+	configure Nothing Nothing = giveup "Not in a git repository."
+
+	addworktree w r = changelocation r $ Local
+		{ gitdir = gitdir (location r)
+		, worktree = w
+		}
+	
+	changelocation r l = r { location = l }
diff --git a/Git/DiffTree.hs b/Git/DiffTree.hs
new file mode 100644
index 0000000000..102658922b
--- /dev/null
+++ b/Git/DiffTree.hs
@@ -0,0 +1,138 @@
+{- git diff-tree interface
+ -
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.DiffTree (
+	DiffTreeItem(..),
+	isDiffOf,
+	diffTree,
+	diffTreeRecursive,
+	diffIndex,
+	diffWorkTree,
+	diffFiles,
+	diffLog,
+	commitDiff,
+	parseDiffRaw,
+) where
+
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+
+import Common
+import Git
+import Git.Sha
+import Git.Command
+import Git.FilePath
+import Git.DiffTreeItem
+import qualified Git.Quote
+import qualified Git.Ref
+import Utility.Attoparsec
+
+{- Checks if the DiffTreeItem modifies a file with a given name
+ - or under a directory by that name. -}
+isDiffOf :: DiffTreeItem -> TopFilePath -> Bool
+isDiffOf diff f = 
+	let f' = getTopFilePath f
+	in if B.null f'
+		then True -- top of repo contains all
+		else f' `dirContains` getTopFilePath (file diff)
+
+{- Diffs two tree Refs. -}
+diffTree :: Ref -> Ref -> Repo -> IO ([DiffTreeItem], IO Bool)
+diffTree src dst = getdiff (Param "diff-tree")
+	[Param (fromRef src), Param (fromRef dst), Param "--"]
+
+{- Diffs two tree Refs, recursing into sub-trees -}
+diffTreeRecursive :: Ref -> Ref -> Repo -> IO ([DiffTreeItem], IO Bool)
+diffTreeRecursive src dst = getdiff (Param "diff-tree")
+	[Param "-r", Param (fromRef src), Param (fromRef dst), Param "--"]
+
+{- Diffs between a tree and the index. Does nothing if there is not yet a
+ - commit in the repository. -}
+diffIndex :: Ref -> Repo -> IO ([DiffTreeItem], IO Bool)
+diffIndex ref = diffIndex' ref [Param "--cached"]
+
+{- Diffs between a tree and the working tree. Does nothing if there is not
+ - yet a commit in the repository, or if the repository is bare. -}
+diffWorkTree :: Ref -> Repo -> IO ([DiffTreeItem], IO Bool)
+diffWorkTree ref repo =
+	ifM (Git.Ref.headExists repo)
+		( diffIndex' ref [] repo
+		, return ([], return True)
+		)
+
+diffIndex' :: Ref -> [CommandParam] -> Repo -> IO ([DiffTreeItem], IO Bool)
+diffIndex' ref params repo =
+	ifM (Git.Ref.headExists repo)
+		( getdiff (Param "diff-index")
+			( params ++ [Param $ fromRef ref] ++ [Param "--"] )
+			repo
+		, return ([], return True)
+		)
+
+{- Diff between the index and work tree. -}
+diffFiles :: [CommandParam] -> Repo -> IO ([DiffTreeItem], IO Bool)
+diffFiles = getdiff (Param "diff-files")
+
+{- Runs git log in --raw mode to get the changes that were made in
+ - a particular commit to particular files. The output format
+ - is adjusted to be the same as diff-tree --raw._-}
+diffLog :: [CommandParam] -> Repo -> IO ([DiffTreeItem], IO Bool)
+diffLog params = getdiff (Param "log")
+	(Param "-n1" : Param "--no-abbrev" : Param "--pretty=format:" : params)
+
+{- Uses git show to get the changes made by a commit.
+ -
+ - Does not support merge commits, and will fail on them. -}
+commitDiff :: Sha -> Repo -> IO ([DiffTreeItem], IO Bool)
+commitDiff ref = getdiff (Param "show")
+	[ Param "--no-abbrev", Param "--pretty=", Param "--raw", Param (fromRef ref) ]
+
+getdiff :: CommandParam -> [CommandParam] -> Repo -> IO ([DiffTreeItem], IO Bool)
+getdiff command params repo = do
+	(diff, cleanup) <- pipeNullSplit ps repo
+	return (parseDiffRaw diff, cleanup)
+  where
+	ps = 
+		command :
+		Param "-z" :
+		Param "--raw" :
+		Param "--no-renames" :
+		Param "-l0" :
+		params
+
+{- Parses --raw output used by diff-tree and git-log. -}
+parseDiffRaw :: [L.ByteString] -> [DiffTreeItem]
+parseDiffRaw l = go l
+  where
+	go [] = []
+	go (info:f:rest) = case A.parse (parserDiffRaw (L.toStrict f)) info of
+		A.Done _ r -> r : go rest
+		A.Fail _ _ err -> giveup $ "diff-tree parse error: " ++ err
+	go (s:[]) = giveup $ "diff-tree parse error near \"" ++ decodeBL s ++ "\""
+
+-- :<srcmode> SP <dstmode> SP <srcsha> SP <dstsha> SP <status>
+--
+-- May be prefixed with a newline, which git log --pretty=format
+-- adds to the first line of the diff, even with -z.
+parserDiffRaw :: RawFilePath -> A.Parser DiffTreeItem
+parserDiffRaw f = DiffTreeItem
+	<$ A.option '\n' (A8.char '\n')
+	<* A8.char ':'
+	<*> octal
+	<* A8.char ' '
+	<*> octal
+	<* A8.char ' '
+	<*> (maybe (fail "bad srcsha") return . extractSha =<< nextword)
+	<* A8.char ' '
+	<*> (maybe (fail "bad dstsha") return . extractSha =<< nextword)
+	<* A8.char ' '
+	<*> A.takeByteString
+	<*> pure (asTopFilePath $ fromInternalGitPath $ Git.Quote.unquote f)
+  where
+	nextword = A8.takeTill (== ' ')
diff --git a/Git/DiffTreeItem.hs b/Git/DiffTreeItem.hs
new file mode 100644
index 0000000000..090ad3e008
--- /dev/null
+++ b/Git/DiffTreeItem.hs
@@ -0,0 +1,25 @@
+{- git diff-tree item
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.DiffTreeItem (
+	DiffTreeItem(..),
+) where
+
+import System.Posix.Types
+import qualified Data.ByteString as S
+
+import Git.FilePath
+import Git.Types
+
+data DiffTreeItem = DiffTreeItem
+	{ srcmode :: FileMode
+	, dstmode :: FileMode
+	, srcsha :: Sha -- null sha if file was added
+	, dstsha :: Sha -- null sha if file was deleted
+	, status :: S.ByteString
+	, file :: TopFilePath
+	} deriving Show
diff --git a/Git/Env.hs b/Git/Env.hs
new file mode 100644
index 0000000000..fb0377f85d
--- /dev/null
+++ b/Git/Env.hs
@@ -0,0 +1,52 @@
+{- Adjusting the environment while running git commands.
+ -
+ - Copyright 2014-2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.Env where
+
+import Common
+import Git
+import Git.Types
+import Utility.Env
+
+{- Adjusts the gitEnv of a Repo. Copies the system environment if the repo
+ - does not have any gitEnv yet. -}
+adjustGitEnv :: Repo -> ([(String, String)] -> [(String, String)]) -> IO Repo
+adjustGitEnv g adj = do
+	e <- maybe getEnvironment return (gitEnv g)
+	let e' = adj e
+	return $ g { gitEnv = Just e' }
+  where
+
+addGitEnv :: Repo -> String -> String -> IO Repo
+addGitEnv g var val = adjustGitEnv g (addEntry var val)
+
+{- Environment variables to use when running a command.
+ - Includes GIT_DIR pointing at the repo, and GIT_WORK_TREE when the repo
+ - is not bare. Also includes anything added to the Repo's gitEnv,
+ - and a copy of the rest of the system environment. -}
+propGitEnv :: Repo -> IO [(String, String)]
+propGitEnv g = do
+	g' <- addGitEnv g "GIT_DIR" (fromRawFilePath (localGitDir g))
+	g'' <- maybe (pure g')
+		(addGitEnv g' "GIT_WORK_TREE" . fromRawFilePath)
+		(repoWorkTree g)
+	return $ fromMaybe [] (gitEnv g'')
+
+{- Use with any action that makes a commit to set metadata. -}
+commitWithMetaData :: CommitMetaData -> CommitMetaData -> (Repo -> IO a) -> Repo -> IO a
+commitWithMetaData authormetadata committermetadata a g =
+	a =<< adjustGitEnv g adj
+  where
+	adj = mkadj "AUTHOR" authormetadata
+		. mkadj "COMMITTER" committermetadata
+	mkadj p md = go "NAME" commitName
+		. go "EMAIL" commitEmail
+		. go "DATE" commitDate
+	  where
+		go s getv = case getv md of
+			Nothing -> id
+			Just v -> addEntry ("GIT_" ++ p ++ "_" ++ s) v
diff --git a/Git/FileMode.hs b/Git/FileMode.hs
new file mode 100644
index 0000000000..af4877aaa8
--- /dev/null
+++ b/Git/FileMode.hs
@@ -0,0 +1,21 @@
+{- git file modes
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Git.FileMode where
+
+import Utility.FileMode
+
+symLinkMode :: FileMode
+symLinkMode = 40960
+
+{- Git uses a special file mode to indicate a symlink. This is the case
+ - even on Windows, so we hard code the values here, rather than using
+ - System.Posix.Files.symbolicLinkMode. -}
+isSymLink :: FileMode -> Bool
+isSymLink = checkMode symLinkMode
diff --git a/Git/FilePath.hs b/Git/FilePath.hs
new file mode 100644
index 0000000000..b27c0c7059
--- /dev/null
+++ b/Git/FilePath.hs
@@ -0,0 +1,96 @@
+{- git FilePath library
+ -
+ - Different git commands use different types of FilePaths to refer to
+ - files in the repository. Some commands use paths relative to the
+ - top of the repository even when run in a subdirectory. Adding some
+ - types helps keep that straight.
+ -
+ - Copyright 2012-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE DeriveGeneric #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.FilePath (
+	TopFilePath,
+	BranchFilePath(..),
+	descBranchFilePath,
+	getTopFilePath,
+	fromTopFilePath,
+	toTopFilePath,
+	asTopFilePath,
+	InternalGitPath,
+	toInternalGitPath,
+	fromInternalGitPath,
+	absoluteGitPath
+) where
+
+import Common
+import Git
+import Git.Quote
+
+import qualified System.FilePath.ByteString as P
+import qualified System.FilePath.Posix.ByteString
+import GHC.Generics
+import Control.DeepSeq
+
+{- A RawFilePath, relative to the top of the git repository. -}
+newtype TopFilePath = TopFilePath { getTopFilePath :: RawFilePath }
+	deriving (Show, Eq, Ord, Generic)
+
+instance NFData TopFilePath
+
+{- A file in a branch or other treeish. -}
+data BranchFilePath = BranchFilePath Ref TopFilePath
+	deriving (Show, Eq, Ord)
+ 
+{- Git uses the branch:file form to refer to a BranchFilePath -}
+descBranchFilePath :: BranchFilePath -> StringContainingQuotedPath
+descBranchFilePath (BranchFilePath b f) =
+	UnquotedByteString (fromRef' b) <> ":" <> QuotedPath (getTopFilePath f)
+
+{- Path to a TopFilePath, within the provided git repo. -}
+fromTopFilePath :: TopFilePath -> Git.Repo -> RawFilePath
+fromTopFilePath p repo = P.combine (repoPath repo) (getTopFilePath p)
+
+{- The input FilePath can be absolute, or relative to the CWD. -}
+toTopFilePath :: RawFilePath -> Git.Repo -> IO TopFilePath
+toTopFilePath file repo = TopFilePath <$> relPathDirToFile (repoPath repo) file
+
+{- The input RawFilePath must already be relative to the top of the git
+ - repository -}
+asTopFilePath :: RawFilePath -> TopFilePath
+asTopFilePath file = TopFilePath file
+
+{- Git may use a different representation of a path when storing
+ - it internally. 
+ -
+ - On Windows, git uses '/' to separate paths stored in the repository,
+ - despite Windows using '\'.
+ -
+ -}
+type InternalGitPath = RawFilePath
+
+toInternalGitPath :: RawFilePath -> InternalGitPath
+#ifndef mingw32_HOST_OS
+toInternalGitPath = id
+#else
+toInternalGitPath = encodeBS . replace "\\" "/" . decodeBS
+#endif
+
+fromInternalGitPath :: InternalGitPath -> RawFilePath
+#ifndef mingw32_HOST_OS
+fromInternalGitPath = id
+#else
+fromInternalGitPath = encodeBS . replace "/" "\\" . decodeBS
+#endif
+
+{- isAbsolute on Windows does not think "/foo" or "\foo" is absolute,
+ - so try posix paths.
+ -}
+absoluteGitPath :: RawFilePath -> Bool
+absoluteGitPath p = P.isAbsolute p ||
+	System.FilePath.Posix.ByteString.isAbsolute (toInternalGitPath p)
diff --git a/Git/FilterProcess.hs b/Git/FilterProcess.hs
new file mode 100644
index 0000000000..7e04e46118
--- /dev/null
+++ b/Git/FilterProcess.hs
@@ -0,0 +1,170 @@
+{- git long-running filter process
+ -
+ - As documented in git's gitattributes(5) and
+ - Documentation/technical/long-running-process-protocol.txt
+ -
+ - Copyright 2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.FilterProcess (
+	WelcomeMessage(..),
+	Version(..),
+	Capability(..),
+	longRunningProcessHandshake,
+	longRunningFilterProcessHandshake,
+	FilterRequest(..),
+	getFilterRequest,
+	respondFilterRequest,
+) where
+
+import Common
+import Git.PktLine
+
+import qualified Data.ByteString as B
+
+{- This is a message like "git-filter-client" or "git-filter-server" -}
+data WelcomeMessage = WelcomeMessage PktLine
+	deriving (Show)
+
+{- Configuration message, eg "foo=bar" -}
+data ConfigValue = ConfigValue String String
+	deriving (Show, Eq)
+
+encodeConfigValue :: ConfigValue -> PktLine
+encodeConfigValue (ConfigValue k v) = stringPktLine (k <> "=" <> v)
+
+decodeConfigValue :: PktLine -> Maybe ConfigValue
+decodeConfigValue pktline =
+	let t = pktLineToString pktline
+	    (k, v) = break (== '=') t
+	in if null v
+		then Nothing
+		else Just $ ConfigValue k (drop 1 v)
+
+extractConfigValue :: [ConfigValue] -> String -> Maybe String
+extractConfigValue [] _ = Nothing
+extractConfigValue (ConfigValue k v:cs) wantk
+	| k == wantk = Just v
+	| otherwise = extractConfigValue cs wantk
+
+data Version = Version Int
+	deriving (Show, Eq)
+
+encodeVersion :: Version -> PktLine
+encodeVersion (Version n) = encodeConfigValue $ ConfigValue "version" (show n)
+
+decodeVersion :: PktLine -> Maybe Version
+decodeVersion pktline = decodeConfigValue pktline >>= \case
+	ConfigValue "version" v -> Version <$> readish v
+	_ -> Nothing
+
+data Capability = Capability String
+	deriving (Show, Eq)
+
+encodeCapability :: Capability -> PktLine
+encodeCapability (Capability c) = encodeConfigValue $ 
+	ConfigValue "capability" c
+
+decodeCapability :: PktLine -> Maybe Capability
+decodeCapability pktline = decodeConfigValue pktline >>= \case
+	ConfigValue "capability" c -> Just $ Capability c
+	_ -> Nothing
+
+longRunningProcessHandshake
+	:: (WelcomeMessage -> Maybe WelcomeMessage)
+	-> ([Version] -> [Version])
+	-> ([Capability] -> [Capability])
+	-> IO (Either String ())
+longRunningProcessHandshake respwelcomemessage filterversions filtercapabilities =
+	readUntilFlushPkt >>= \case
+		[] -> protoerr "no welcome message"
+		(welcomemessage:versions) -> 
+			checkwelcomemessage welcomemessage $
+				checkversion versions $ do
+					capabilities <- readUntilFlushPkt
+					checkcapabilities capabilities success
+  where
+	protoerr msg = return $ Left $ "git protocol error: " ++ msg
+	success = return (Right ())
+
+	checkwelcomemessage welcomemessage cont =
+		case respwelcomemessage (WelcomeMessage welcomemessage) of
+			Nothing -> protoerr "unsupported welcome message"
+			Just (WelcomeMessage welcomemessage') -> do
+				writePktLine stdout welcomemessage'
+				cont
+
+	checkversion versions cont = do
+		let versions' = filterversions (mapMaybe decodeVersion versions)
+		if null versions'
+			then protoerr "unsupported protocol version"
+			else do
+				forM_ versions' $ \v ->
+					writePktLine stdout $ encodeVersion v
+				writePktLine stdout flushPkt
+				cont
+	
+	checkcapabilities capabilities cont = do
+		let capabilities' = filtercapabilities (mapMaybe decodeCapability capabilities)
+		if null capabilities'
+			then protoerr "unsupported protocol capabilities"
+			else do
+				forM_ capabilities' $ \c ->
+					writePktLine stdout $ encodeCapability c
+				writePktLine stdout flushPkt
+				cont
+
+longRunningFilterProcessHandshake :: IO (Either String ())
+longRunningFilterProcessHandshake =
+	longRunningProcessHandshake respwelcomemessage filterversions filtercapabilities
+  where
+	respwelcomemessage (WelcomeMessage w)
+		| pktLineToString w == "git-filter-client" =
+			Just $ WelcomeMessage $ stringPktLine "git-filter-server"
+		| otherwise = Nothing
+	filterversions = filter (== Version 2)
+	-- Delay capability is not implemented, so filter it out.
+	filtercapabilities = filter (`elem` [Capability "smudge", Capability "clean"])
+
+data FilterRequest = Smudge FilePath | Clean FilePath
+	deriving (Show, Eq)
+
+{- Waits for the next FilterRequest to be received. Does not read
+ - the content to be filtered, which is what gets sent subsequent to the
+ - FilterRequest. Use eg readUntilFlushPkt to read it, before calling
+ - respondFilterRequest. -}
+getFilterRequest :: IO (Maybe FilterRequest)
+getFilterRequest = do
+	ps <- readUntilFlushPkt
+	let cs = mapMaybe decodeConfigValue ps
+	case (extractConfigValue cs "command", extractConfigValue cs "pathname") of
+		(Just command, Just pathname)
+			| command == "smudge" -> return $ Just $ Smudge pathname
+			| command == "clean" -> return $ Just $ Clean pathname
+			| otherwise -> return Nothing
+		_ -> return Nothing
+
+{- Send a response to a FilterRequest, consisting of the filtered content. -}
+respondFilterRequest :: B.ByteString -> IO ()
+respondFilterRequest b = do
+	writePktLine stdout $ encodeConfigValue $ ConfigValue "status" "success"
+	writePktLine stdout flushPkt
+	send b
+	-- The protocol allows for another list of ConfigValues to be sent
+	-- here, but we don't use it. Send another flushPkt to terminate
+	-- the empty list.
+	writePktLine stdout flushPkt
+  where
+	send b' = 
+		let (pktline, rest) = encodePktLine b'
+		in do
+			if isFlushPkt pktline
+				then return ()
+				else writePktLine stdout pktline
+			case rest of
+				Just b'' -> send b''
+				Nothing -> writePktLine stdout flushPkt
diff --git a/Git/Fsck.hs b/Git/Fsck.hs
new file mode 100644
index 0000000000..4544c1312f
--- /dev/null
+++ b/Git/Fsck.hs
@@ -0,0 +1,172 @@
+{- git fsck interface
+i it is not fully repoducibleI repeated the same steps
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Git.Fsck (
+	FsckResults(..),
+	MissingObjects,
+	findBroken,
+	foundBroken,
+	findMissing,
+	isMissing,
+	knownMissing,
+) where
+
+import Common
+import Git
+import Git.Command
+import Git.Sha
+import Utility.Batch
+
+import qualified Data.Set as S
+import Control.Concurrent.Async
+import qualified Data.Semigroup as Sem
+import Prelude
+
+data FsckResults 
+	= FsckFoundMissing
+		{ missingObjects :: MissingObjects
+		, missingObjectsTruncated :: Bool
+		}
+	| FsckFailed
+	deriving (Show)
+
+data FsckOutput 
+	= FsckOutput MissingObjects Truncated
+	| NoFsckOutput
+	| AllDuplicateEntriesWarning
+
+type MissingObjects = S.Set Sha
+
+type Truncated = Bool
+
+appendFsckOutput :: FsckOutput -> FsckOutput -> FsckOutput
+appendFsckOutput (FsckOutput s1 t1) (FsckOutput s2 t2) =
+	FsckOutput (S.union s1 s2) (t1 || t2)
+appendFsckOutput (FsckOutput s t) _ = FsckOutput s t
+appendFsckOutput _ (FsckOutput s t) = FsckOutput s t
+appendFsckOutput NoFsckOutput NoFsckOutput = NoFsckOutput
+appendFsckOutput AllDuplicateEntriesWarning AllDuplicateEntriesWarning = AllDuplicateEntriesWarning
+appendFsckOutput AllDuplicateEntriesWarning NoFsckOutput = AllDuplicateEntriesWarning
+appendFsckOutput NoFsckOutput AllDuplicateEntriesWarning = AllDuplicateEntriesWarning
+
+instance Sem.Semigroup FsckOutput where
+	(<>) = appendFsckOutput
+
+instance Monoid FsckOutput where
+	mempty = NoFsckOutput
+
+{- Runs fsck to find some of the broken objects in the repository.
+ - May not find all broken objects, if fsck fails on bad data in some of
+ - the broken objects it does find.
+ -
+ - Strategy: Rather than parsing fsck's current specific output,
+ - look for anything in its output (both stdout and stderr) that appears
+ - to be a git sha. Not all such shas are of broken objects, so ask git
+ - to try to cat the object, and see if it fails.
+ -
+ - Note that there is a possible false positive: When changes are being
+ - made to the repo while this is running, fsck might complain about a
+ - missing object that has not made it to disk yet. Catting the object
+ - then succeeds, so it's not included in the FsckResults. But, fsck then
+ - exits nonzero, and so FsckFailed is returned. Set ignorenonzeroexit
+ - to avoid this false positive, at the risk of perhaps missing a problem
+ - so bad that fsck crashes without outputting any missing shas.
+ -}
+findBroken :: Bool -> Bool -> Repo -> IO FsckResults
+findBroken batchmode ignorenonzeroexit r = do
+	let (command, params) = ("git", fsckParams r)
+	(command', params') <- if batchmode
+		then toBatchCommand (command, params)
+		else return (command, params)
+	
+	let p = (proc command' (toCommand params'))
+		{ std_out = CreatePipe
+		, std_err = CreatePipe
+		}
+	withCreateProcess p go
+  where
+	go _ (Just outh) (Just errh) pid = do
+		(o1, o2) <- concurrently
+			(parseFsckOutput maxobjs r outh pid)
+			(parseFsckOutput maxobjs r errh pid)
+		fsckok <- checkSuccessProcess pid
+		case mappend o1 o2 of
+			FsckOutput badobjs truncated
+				| S.null badobjs && not fsckok -> return fsckfailed
+				| otherwise -> return $ FsckFoundMissing badobjs truncated
+			NoFsckOutput
+				| not fsckok -> return fsckfailed
+				| otherwise -> return noproblem
+			-- If all fsck output was duplicateEntries warnings,
+			-- the repository is not broken, it just has some
+			-- unusual tree objects in it. So ignore nonzero
+			-- exit status.
+			AllDuplicateEntriesWarning -> return noproblem
+	go _ _ _ _ = error "internal"
+	
+	maxobjs = 10000
+	noproblem = FsckFoundMissing S.empty False
+	fsckfailed
+		| ignorenonzeroexit = noproblem
+		| otherwise = FsckFailed
+
+foundBroken :: FsckResults -> Bool
+foundBroken FsckFailed = True
+foundBroken (FsckFoundMissing s _) = not (S.null s)
+
+knownMissing :: FsckResults -> MissingObjects
+knownMissing FsckFailed = S.empty
+knownMissing (FsckFoundMissing s _) = s
+
+{- Finds objects that are missing from the git repsitory, or are corrupt.
+ -
+ - This does not use git cat-file --batch, because catting a corrupt
+ - object can cause it to crash, or to report incorrect size information.
+ -}
+findMissing :: [Sha] -> Repo -> IO MissingObjects
+findMissing objs r = S.fromList <$> filterM (`isMissing` r) objs
+
+parseFsckOutput :: Int -> Repo -> Handle -> ProcessHandle -> IO FsckOutput
+parseFsckOutput maxobjs r h pid = do
+	ls <- getlines []
+	if null ls
+		then return NoFsckOutput
+		else if all ("duplicateEntries" `isInfixOf`) ls
+			then return AllDuplicateEntriesWarning
+			else do
+				let shas = findShas ls
+				let !truncated = length shas > maxobjs
+				missingobjs <- findMissing (take maxobjs shas) r
+				return $ FsckOutput missingobjs truncated
+  where
+	getlines c = hGetLineUntilExitOrEOF pid h >>= \case
+		Nothing -> return (reverse c)
+		Just l -> getlines (l:c)
+
+isMissing :: Sha -> Repo -> IO Bool
+isMissing s r = either (const True) (const False) <$> tryIO dump
+  where
+	dump = runQuiet
+		[ Param "show"
+		, Param (fromRef s)
+		] r
+
+findShas :: [String] -> [Sha]
+findShas = catMaybes . map (extractSha . encodeBS) 
+	. concat . map words . filter wanted
+  where
+	wanted l = not ("dangling " `isPrefixOf` l)
+
+fsckParams :: Repo -> [CommandParam]
+fsckParams = gitCommandLine $ map Param
+	[ "fsck"
+	, "--no-dangling"
+	, "--no-reflogs"
+	]
diff --git a/Git/GCrypt.hs b/Git/GCrypt.hs
new file mode 100644
index 0000000000..07db13c1c0
--- /dev/null
+++ b/Git/GCrypt.hs
@@ -0,0 +1,133 @@
+{- git-remote-gcrypt support
+ -
+ - https://spwhitton.name/tech/code/git-remote-gcrypt/
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.GCrypt where
+
+import Common
+import Git.Types
+import Git.Construct
+import qualified Git.Config as Config
+import qualified Git.Command as Command
+import Utility.Gpg
+
+import qualified Data.ByteString as S
+import qualified Network.URI
+
+urlScheme :: String
+urlScheme = "gcrypt:"
+
+urlPrefix :: String
+urlPrefix = urlScheme ++ ":"
+
+isEncrypted :: Repo -> Bool
+isEncrypted Repo { location = Url url } = urlPrefix `isPrefixOf` show url
+isEncrypted Repo { location = UnparseableUrl url } = urlPrefix `isPrefixOf` url
+isEncrypted _ = False
+
+{- The first Repo is the git repository that has the second Repo
+ - as one of its remotes.
+ -
+ - When the remote Repo uses gcrypt, returns the actual underlying
+ - git repository that gcrypt is using to store its data. 
+ -
+ - Throws an exception if the repo does not use gcrypt.
+ -}
+encryptedRemote :: Repo -> Repo -> IO Repo
+encryptedRemote baserepo = go
+  where
+	go Repo { location = Url url } = go' (show url)
+	go Repo { location = UnparseableUrl url } = go' url
+	go _ = notencrypted
+
+	go' u
+		| urlPrefix `isPrefixOf` u =
+			let l = drop plen u
+			    -- Git.Construct.fromUrl escapes characters
+			    -- that are not allowed in URIs (though git
+			    -- allows them); need to de-escape any such
+			    -- to get back the path to the repository.
+			    l' = Network.URI.unEscapeString l
+			    -- gcrypt supports relative urls for rsync 
+			    -- like "rsync://host:relative/path"
+			    -- but that does not parse as a valid url
+			    -- (while the absolute urls it supports are
+			    -- valid). 
+			    -- In order to support it, force treating it as
+			    -- an url.
+			    knownurl = "rsync://" `isPrefixOf` l'
+			in fromRemoteLocation l' knownurl baserepo
+		| otherwise = notencrypted
+
+	notencrypted = giveup "not a gcrypt encrypted repository"
+
+	plen = length urlPrefix
+
+data ProbeResult = Decryptable | NotDecryptable | NotEncrypted
+
+{- Checks if the git repo at a location uses gcrypt.
+ - 
+ - Rather expensive -- many need to fetch the entire repo contents.
+ - (Which is fine if the repo is going to be added as a remote..)
+ -}
+probeRepo :: String -> Repo -> IO ProbeResult
+probeRepo loc baserepo = do
+	let p = proc "git" $ toCommand $ Command.gitCommandLine
+		[ Param "remote-gcrypt"
+		, Param "--check"
+		, Param loc
+		] baserepo
+	withCreateProcess p $ \_ _ _ pid -> do
+		code <- waitForProcess pid
+		return $ case code of
+			ExitSuccess -> Decryptable
+			ExitFailure 1 -> NotDecryptable
+			ExitFailure _ -> NotEncrypted
+
+type GCryptId = String
+
+{- gcrypt gives each encrypted repository a unique gcrypt-id,
+ - which is stored in the repository (in encrypted form)
+ - and cached in a per-remote gcrypt-id configuration setting. -}
+remoteRepoId :: Repo -> Maybe RemoteName -> Maybe GCryptId
+remoteRepoId r n = fromConfigValue <$> getRemoteConfig "gcrypt-id" r n
+
+getRemoteConfig :: S.ByteString -> Repo -> Maybe RemoteName -> Maybe ConfigValue
+getRemoteConfig field repo remotename = do
+	n <- remotename
+	Config.getMaybe (remoteConfigKey field n) repo
+
+{- Gpg keys that the remote is encrypted for.
+ - If empty, gcrypt uses --default-recipient-self -}
+getParticiantList :: Maybe Repo -> Repo -> Maybe RemoteName -> KeyIds
+getParticiantList globalconfigrepo repo remotename = KeyIds $ parse $ firstJust
+	[ getRemoteConfig "gcrypt-participants" repo remotename
+	, Config.getMaybe defaultkey repo
+	, Config.getMaybe defaultkey =<< globalconfigrepo
+	]
+  where
+	defaultkey = "gcrypt.participants"
+	parse (Just (ConfigValue "simple")) = []
+	parse (Just (ConfigValue b)) = words (decodeBS b)
+	parse (Just NoConfigValue) = []
+	parse Nothing = []
+
+remoteParticipantConfigKey :: RemoteName -> ConfigKey
+remoteParticipantConfigKey = remoteConfigKey "gcrypt-participants"
+
+remotePublishParticipantConfigKey :: RemoteName -> ConfigKey
+remotePublishParticipantConfigKey = remoteConfigKey "gcrypt-publish-participants"
+
+remoteSigningKey :: RemoteName -> ConfigKey
+remoteSigningKey = remoteConfigKey "gcrypt-signingkey"
+
+remoteConfigKey :: S.ByteString -> RemoteName -> ConfigKey
+remoteConfigKey key remotename = ConfigKey $
+	"remote." <> encodeBS remotename <> "." <> key
diff --git a/Git/HashObject.hs b/Git/HashObject.hs
new file mode 100644
index 0000000000..1474c5709d
--- /dev/null
+++ b/Git/HashObject.hs
@@ -0,0 +1,98 @@
+{- git hash-object interface
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Git.HashObject where
+
+import Common
+import Git
+import Git.Sha
+import Git.Command
+import Git.Types
+import qualified Utility.CoProcess as CoProcess
+import Utility.Tmp
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.ByteString.Lazy as L
+import Data.ByteString.Builder
+import Data.Char
+
+data HashObjectHandle = HashObjectHandle CoProcess.CoProcessHandle Repo [CommandParam]
+
+hashObjectStart :: Bool -> Repo -> IO HashObjectHandle
+hashObjectStart writeobject repo = do
+	h <- gitCoProcessStart True (ps ++ [Param "--stdin-paths"]) repo
+	return (HashObjectHandle h repo ps)
+  where
+	ps = catMaybes
+		[ Just (Param "hash-object")
+		, if writeobject then Just (Param "-w") else Nothing
+		, Just (Param "--no-filters")
+		]
+
+hashObjectStop :: HashObjectHandle -> IO ()
+hashObjectStop (HashObjectHandle h _ _) = CoProcess.stop h
+
+{- Injects a file into git, returning the Sha of the object. -}
+hashFile :: HashObjectHandle -> RawFilePath -> IO Sha
+hashFile hdl@(HashObjectHandle h _ _) file = do
+	-- git hash-object chdirs to the top of the repository on
+	-- start, so if the filename is relative, it will
+	-- not work. This seems likely to be a git bug.
+	-- So, make the filename absolute, which will work now
+	-- and also if git's behavior later changes.
+	file' <- absPath file
+	if newline `S.elem` file'
+		then hashFile' hdl file
+		else CoProcess.query h (send file') receive
+  where
+	send file' to = S8.hPutStrLn to file'
+	receive from = getSha "hash-object" $ S8.hGetLine from
+	newline = fromIntegral (ord '\n')
+
+{- Runs git hash-object once per call, rather than using a running
+ - one, so is slower. But, is able to handle newlines in the filepath,
+ - which --stdin-paths cannot. -}
+hashFile' :: HashObjectHandle -> RawFilePath -> IO Sha
+hashFile' (HashObjectHandle _ repo ps) file = getSha "hash-object" $
+	pipeReadStrict (ps ++ [File (fromRawFilePath file)]) repo
+
+class HashableBlob t where
+	hashableBlobToHandle :: Handle -> t -> IO ()
+
+instance HashableBlob L.ByteString where
+	hashableBlobToHandle = L.hPut
+
+instance HashableBlob S.ByteString where
+	hashableBlobToHandle = S.hPut
+
+instance HashableBlob Builder where
+	hashableBlobToHandle = hPutBuilder
+
+{- Injects a blob into git. Unfortunately, the current git-hash-object
+ - interface does not allow batch hashing without using temp files. -}
+hashBlob :: HashableBlob b => HashObjectHandle -> b -> IO Sha
+hashBlob h b = withTmpFile "hash" $ \tmp tmph -> do
+	hashableBlobToHandle tmph b
+	hClose tmph
+	hashFile h (toRawFilePath tmp)
+
+{- Injects some content into git, returning its Sha.
+ - 
+ - Avoids using a tmp file, but runs a new hash-object command each
+ - time called. -}
+hashObject :: ObjectType -> String -> Repo -> IO Sha
+hashObject objtype content = hashObject' objtype (flip hPutStr content)
+
+hashObject' :: ObjectType -> (Handle -> IO ()) -> Repo -> IO Sha
+hashObject' objtype writer repo = getSha subcmd $
+	pipeWriteRead (map Param params) (Just writer) repo
+  where
+	subcmd = "hash-object"
+	params = [subcmd, "-t", decodeBS (fmtObjectType objtype), "-w", "--stdin", "--no-filters"]
diff --git a/Git/History.hs b/Git/History.hs
new file mode 100644
index 0000000000..9c20e12095
--- /dev/null
+++ b/Git/History.hs
@@ -0,0 +1,112 @@
+{-# LANGUAGE BangPatterns #-}
+
+{- git commit history interface
+ -
+ - Copyright 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.History where
+
+import Common
+import Git
+import Git.Command
+import Git.Sha
+
+import qualified Data.Set as S
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString.Char8 as B8
+import qualified Data.ByteString.Lazy.Char8 as L8
+
+data History t = History t (S.Set (History t))
+	deriving (Show, Eq, Ord)
+
+mapHistory :: (Ord a, Ord b) => (a -> b) -> History a -> History b
+mapHistory f (History t s) = History (f t) (S.map (mapHistory f) s)
+
+historyDepth :: History t -> Integer
+historyDepth (History _ s)
+	| S.null s = 1
+	| otherwise = 1 + maximum (map historyDepth (S.toList s))
+
+truncateHistoryToDepth :: Ord t => Integer -> History t -> History t
+truncateHistoryToDepth n (History t ps) = History t (go 1 ps)
+  where
+	go depth s
+		| depth >= n = S.empty
+		| otherwise =
+			let depth' = succ depth
+			in flip S.map s $ \(History t' s') ->
+				History t' (go depth' s')
+
+
+data HistoryCommit = HistoryCommit
+	{ historyCommit :: Sha
+	, historyCommitTree :: Sha
+	, historyCommitParents :: [Sha]
+	} deriving (Show, Eq, Ord)
+
+{- Gets a History starting with the provided commit, and down to the
+ - requested depth. -}
+getHistoryToDepth :: Integer -> Ref -> Repo -> IO (Maybe (History HistoryCommit))
+getHistoryToDepth n commit r = withCreateProcess p go
+  where
+	p = (gitCreateProcess params r)
+		{ std_out = CreatePipe }
+	go _ (Just inh) _ pid = do
+		!h <- fmap (truncateHistoryToDepth n) 
+			. build Nothing 
+			. map parsehistorycommit
+			. map L.toStrict
+			. L8.lines
+			<$> L.hGetContents inh
+		hClose inh
+		void $ waitForProcess pid
+		return h
+	go _ _ _ _ = error "internal"
+
+	build h [] = fmap (mapHistory fst) h
+	build _ (Nothing:_) = Nothing
+	build Nothing (Just v:rest) =
+		build (Just (History v S.empty)) rest
+	build (Just h) (Just v:rest) =
+		let h' = traverseadd v h
+		in build (Just h') $
+			-- detect when all parents down to desired depth
+			-- have been found, and avoid processing any more,
+			-- this makes it much faster when there is a lot of
+			-- history.
+			if parentsfound h' then [] else rest
+
+	traverseadd v@(hc, _ps) (History v'@(hc', ps') s)
+		| historyCommit hc `elem` ps' =
+			let ps'' = filter (/= historyCommit hc) ps'
+			in History (hc', ps'') (S.insert (History v S.empty) s)
+		| otherwise = History v' (S.map (traverseadd v) s)
+
+	parentsfound = parentsfound' 1
+	parentsfound' depth (History (_hc, ps) s)
+		| not (null ps) = False
+		| null ps && depth == n = True
+		| depth >= n = True
+		| otherwise = all (parentsfound' (succ depth)) (S.toList s)
+
+	params =
+		[ Param "log"
+		, Param (fromRef commit)
+		, Param "--full-history"
+		, Param "--no-abbrev"
+		, Param "--format=%T %H %P"
+		]
+	
+	parsehistorycommit l = case map extractSha (B8.split ' ' l) of
+		(Just t:Just c:ps) -> Just $ 
+			( HistoryCommit
+				{ historyCommit = c
+				, historyCommitTree = t
+				, historyCommitParents = catMaybes ps
+				}
+			, catMaybes ps
+			)
+		_ -> Nothing
diff --git a/Git/Hook.hs b/Git/Hook.hs
new file mode 100644
index 0000000000..1301ec2180
--- /dev/null
+++ b/Git/Hook.hs
@@ -0,0 +1,115 @@
+{- git hooks
+ -
+ - Copyright 2013-2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Git.Hook where
+
+import Common
+import Git
+import Utility.Tmp
+import Utility.Shell
+import Utility.FileMode
+#ifndef mingw32_HOST_OS
+import qualified Utility.RawFilePath as R
+import System.PosixCompat.Files (fileMode)
+#endif
+
+import qualified Data.ByteString as B
+
+data Hook = Hook
+	{ hookName :: FilePath
+	, hookScript :: String
+	, hookOldScripts :: [String]
+	}
+	deriving (Ord)
+
+instance Eq Hook where
+	a == b = hookName a == hookName b
+
+hookFile :: Hook -> Repo -> FilePath
+hookFile h r = fromRawFilePath (localGitDir r) </> "hooks" </> hookName h
+
+{- Writes a hook. Returns False if the hook already exists with a different
+ - content. Upgrades old scripts.
+ -
+ - This can install hooks on both filesystem like FAT that do not support
+ - execute bits, and on Windows.
+ -
+ - If the filesystem does not support execute bits, it's typically mounted
+ - such that all files have the execute bit set. So just write the hook
+ - and ignore failure to make it executable.
+ -
+ - On Windows, git will run hooks that are not executable. The hook
+ - is run with a bundled bash, so should start with #!/bin/sh
+ -}
+hookWrite :: Hook -> Repo -> IO Bool
+hookWrite h r = ifM (doesFileExist f)
+	( expectedContent h r >>= \case
+		UnexpectedContent -> return False
+		ExpectedContent -> return True
+		OldExpectedContent -> go
+	, go
+	)
+  where
+	f = hookFile h r
+	go = do
+		-- On Windows, using B.writeFile here avoids
+		-- the newline translation done by writeFile.
+		-- Hook scripts on Windows could use CRLF endings, but
+		-- they typically use unix newlines, which does work there
+		-- and makes the repository more portable.
+		viaTmp B.writeFile f (encodeBS (hookScript h))
+		void $ tryIO $ modifyFileMode
+			(toRawFilePath f)
+			(addModes executeModes)
+		return True
+
+{- Removes a hook. Returns False if the hook contained something else, and
+ - could not be removed. -}
+hookUnWrite :: Hook -> Repo -> IO Bool
+hookUnWrite h r = ifM (doesFileExist f)
+	( expectedContent h r >>= \case
+		UnexpectedContent -> return False
+		_ -> do
+			removeFile f
+			return True
+	, return True
+	)
+  where
+	f = hookFile h r
+
+data ExpectedContent = UnexpectedContent | ExpectedContent | OldExpectedContent
+
+expectedContent :: Hook -> Repo -> IO ExpectedContent
+expectedContent h r = do
+	-- Note that on windows, this readFile does newline translation,
+	-- and so a hook file that has CRLF will be treated the same as one
+	-- that has LF. That is intentional, since users may have a reason
+	-- to prefer one or the other.
+	content <- readFile $ hookFile h r
+	return $ if content == hookScript h
+		then ExpectedContent
+		else if any (content ==) (hookOldScripts h)
+			then OldExpectedContent
+			else UnexpectedContent
+
+hookExists :: Hook -> Repo -> IO Bool
+hookExists h r = do
+	let f = hookFile h r
+	catchBoolIO $
+#ifndef mingw32_HOST_OS
+		isExecutable . fileMode <$> R.getFileStatus (toRawFilePath f)
+#else
+		doesFileExist f
+#endif
+
+runHook :: Hook -> Repo -> IO Bool
+runHook h r = do
+	let f = hookFile h r
+	(c, ps) <- findShellCommand f
+	boolSystem c ps
diff --git a/Git/Index.hs b/Git/Index.hs
new file mode 100644
index 0000000000..b55fc04b99
--- /dev/null
+++ b/Git/Index.hs
@@ -0,0 +1,64 @@
+{- git index file stuff
+ -
+ - Copyright 2011-2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.Index where
+
+import Common
+import Git
+import Utility.Env
+import Utility.Env.Set
+
+import qualified System.FilePath.ByteString as P
+
+indexEnv :: String
+indexEnv = "GIT_INDEX_FILE"
+
+{- Gets value to set GIT_INDEX_FILE to. Input should be absolute path,
+ - or relative to the CWD.
+ -
+ - When relative, GIT_INDEX_FILE is interpreted by git as being 
+ - relative to the top of the work tree of the git repository,
+ - not to the CWD. Worse, other environment variables (GIT_WORK_TREE)
+ - or git options (--work-tree) or configuration (core.worktree)
+ - can change what the relative path is interpreted relative to.
+ -
+ - So, an absolute path is the only safe option for this to return.
+ -}
+indexEnvVal :: RawFilePath -> IO String
+indexEnvVal p = fromRawFilePath <$> absPath p
+
+{- Forces git to use the specified index file.
+ -
+ - Returns an action that will reset back to the default
+ - index file.
+ -
+ - Warning: Not thread safe.
+ -}
+override :: RawFilePath -> Repo -> IO (IO ())
+override index _r = do
+	res <- getEnv var
+	val <- indexEnvVal index
+	setEnv var val True
+	return $ reset res
+  where
+	var = "GIT_INDEX_FILE"
+	reset (Just v) = setEnv indexEnv v True
+	reset _ = unsetEnv var
+
+{- The normal index file. Does not check GIT_INDEX_FILE. -}
+indexFile :: Repo -> RawFilePath
+indexFile r = localGitDir r P.</> "index"
+
+{- The index file git will currently use, checking GIT_INDEX_FILE. -}
+currentIndexFile :: Repo -> IO RawFilePath
+currentIndexFile r = maybe (indexFile r) toRawFilePath <$> getEnv indexEnv
+
+{- Git locks the index by creating this file. -}
+indexFileLock :: RawFilePath -> RawFilePath
+indexFileLock f = f <> ".lock"
diff --git a/Git/LockFile.hs b/Git/LockFile.hs
new file mode 100644
index 0000000000..fa92df046e
--- /dev/null
+++ b/Git/LockFile.hs
@@ -0,0 +1,80 @@
+{- git lock files
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Git.LockFile where
+
+import Common
+
+#ifndef mingw32_HOST_OS
+import Utility.OpenFd
+import System.Posix.Types
+import System.Posix.IO
+#else
+import System.Win32.Types
+import System.Win32.File
+#endif
+
+#ifndef mingw32_HOST_OS
+data LockHandle = LockHandle FilePath Fd
+#else
+data LockHandle = LockHandle FilePath HANDLE
+#endif
+
+{- Uses the same exclusive locking that git does.
+ - Throws an IO exception if the file is already locked.
+ -
+ - Note that git's locking method suffers from the problem that
+ - a dangling lock can be left if a process is terminated at the wrong
+ - time.
+ -}
+openLock :: FilePath -> IO LockHandle
+openLock lck = openLock' lck `catchNonAsync` lckerr
+  where
+	lckerr e = do
+		-- Same error message displayed by git.
+		whenM (doesFileExist lck) $
+			hPutStrLn stderr $ unlines
+				[ "fatal: Unable to create '" ++ lck ++ "': " ++ show e
+				, ""
+				, "If no other git process is currently running, this probably means a"
+				, "git process crashed in this repository earlier. Make sure no other git"
+				, "process is running and remove the file manually to continue."
+				]
+		throwM e
+
+openLock' :: FilePath -> IO LockHandle
+openLock' lck = do
+#ifndef mingw32_HOST_OS
+	-- On unix, git simply uses O_EXCL
+	h <- openFdWithMode (toRawFilePath lck) ReadWrite (Just 0O666)
+		(defaultFileFlags { exclusive = True })
+	setFdOption h CloseOnExec True
+#else
+	-- It's not entirely clear how git manages locking on Windows,
+	-- since it's buried in the portability layer, and different
+	-- versions of git for windows use different portability layers.
+	-- But, we can be fairly sure that holding the lock file open on
+	-- windows is enough to prevent another process from opening it.
+	--
+	-- So, all that's needed is a way to open the file, that fails
+	-- if the file already exists. Using CreateFile with CREATE_NEW 
+	-- accomplishes that.
+	h <- createFile lck gENERIC_WRITE fILE_SHARE_NONE Nothing
+		cREATE_NEW fILE_ATTRIBUTE_NORMAL Nothing
+#endif
+	return (LockHandle lck h)
+
+closeLock :: LockHandle -> IO ()
+closeLock (LockHandle lck h) = do
+#ifndef mingw32_HOST_OS
+	closeFd h
+#else
+	closeHandle h
+#endif
+	removeFile lck
diff --git a/Git/Log.hs b/Git/Log.hs
new file mode 100644
index 0000000000..a3246d5102
--- /dev/null
+++ b/Git/Log.hs
@@ -0,0 +1,115 @@
+{- git log
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.Log where
+
+import Common
+import Git
+import Git.Command
+import Git.Sha
+
+import Data.Time
+import Data.Time.Clock.POSIX
+
+-- A change made to a file.
+data LoggedFileChange t = LoggedFileChange
+	{ changetime :: POSIXTime
+	, changed :: t
+	, changedfile :: FilePath
+	, oldref :: Ref
+	, newref :: Ref
+	}
+	deriving (Show)
+
+-- Get the git log of changes to files. 
+-- 
+-- Note that the returned cleanup action should only be
+-- run after processing the returned list.
+getGitLog
+	:: Ref
+	-> Maybe Ref
+	-> [FilePath]
+	-> [CommandParam]
+	-> (Sha -> FilePath -> Maybe t)
+	-> Repo
+	-> IO ([LoggedFileChange t], IO Bool)
+getGitLog ref stopref fs os selector repo = do
+	(ls, cleanup) <- pipeNullSplit ps repo
+	return (parseGitRawLog selector (map decodeBL ls), cleanup)
+  where
+	ps =
+		[ Param "log"
+		, Param "-z"
+		, Param ("--pretty=format:"++commitinfoFormat)
+		, Param "--raw"
+		, Param "--no-abbrev"
+		, Param "--no-renames"
+		] ++ os ++
+		[ case stopref of
+			Just stopref' -> Param $
+				fromRef stopref' <> ".." <> fromRef ref
+			Nothing -> Param (fromRef ref)
+		, Param "--"
+		] ++ map Param fs 
+
+-- The commitinfo is the commit hash followed by its timestamp.
+commitinfoFormat :: String
+commitinfoFormat = "%H %ct"
+
+-- Parses chunked git log --raw output generated by getGitLog, 
+-- which looks something like:
+--
+-- [ "commitinfo\n:changeline"
+-- , "filename"
+-- , ""
+-- , "commitinfo\n:changeline"
+-- , "filename"
+-- , ":changeline"
+-- , "filename"
+-- , ""
+-- ]
+--
+-- The commitinfo is not included before all changelines, so
+-- keep track of the most recently seen commitinfo.
+parseGitRawLog :: (Ref -> FilePath -> Maybe t) -> [String] -> [LoggedFileChange t]
+parseGitRawLog selector = parse (deleteSha, epoch)
+  where
+	epoch = toEnum 0 :: POSIXTime
+	parse old ([]:rest) = parse old rest
+	parse (oldcommitsha, oldts) (c1:c2:rest) = case mrc of
+		Just rc -> rc : parse (commitsha, ts) rest
+		Nothing -> parse (commitsha, ts) (c2:rest)
+	  where
+		(commitsha, ts, cl) = case separate (== '\n') c1 of
+			(cl', []) -> (oldcommitsha, oldts, cl')
+			(ci, cl') -> case words ci of
+				(css:tss:[]) -> (Ref (encodeBS css), parseTimeStamp tss, cl')
+				_ -> (oldcommitsha, oldts, cl')
+	  	mrc = do
+			(old, new) <- parseRawChangeLine cl
+			v <- selector commitsha c2
+			return $ LoggedFileChange
+				{ changetime = ts
+				, changed = v
+				, changedfile = c2
+				, oldref = old
+				, newref = new
+				}
+	parse _ _ = []
+
+-- Parses something like ":100644 100644 oldsha newsha M"
+-- extracting the shas.
+parseRawChangeLine :: String -> Maybe (Git.Ref, Git.Ref)
+parseRawChangeLine = go . words
+  where
+	go (_:_:oldsha:newsha:_) = 
+		Just (Git.Ref (encodeBS oldsha), Git.Ref (encodeBS newsha))
+	go _ = Nothing
+
+parseTimeStamp :: String -> POSIXTime
+parseTimeStamp = utcTimeToPOSIXSeconds . fromMaybe (giveup "bad timestamp") .
+	parseTimeM True defaultTimeLocale "%s"
diff --git a/Git/LsFiles.hs b/Git/LsFiles.hs
new file mode 100644
index 0000000000..4eea39541a
--- /dev/null
+++ b/Git/LsFiles.hs
@@ -0,0 +1,376 @@
+{- git ls-files interface
+ -
+ - Copyright 2010-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.LsFiles (
+	Options(..),
+	inRepo,
+	inRepoDetails,
+	inRepoOrBranch,
+	notInRepo,
+	notInRepoIncludingEmptyDirectories,
+	allFiles,
+	deleted,
+	modified,
+	staged,
+	stagedNotDeleted,
+	usualStageNum,
+	mergeConflictHeadStageNum,
+	stagedDetails,
+	typeChanged,
+	typeChangedStaged,
+	Conflicting(..),
+	Unmerged(..),
+	unmerged,
+	StagedDetails,
+	inodeCaches,
+) where
+
+import Common
+import Git
+import Git.Command
+import Git.Types
+import Git.Sha
+import Utility.InodeCache
+import Utility.TimeStamp
+import Utility.Attoparsec
+import qualified Utility.RawFilePath as R
+
+import System.Posix.Types
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import qualified Data.Attoparsec.ByteString as A
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+import qualified System.FilePath.ByteString as P
+
+{- It's only safe to use git ls-files on the current repo, not on a remote.
+ -
+ - Git has some strange behavior when git ls-files is used with repos
+ - that are not the one that the cwd is in:
+ - git --git-dir=../foo/.git --worktree=../foo ../foo fails saying 
+ - "../foo is outside repository".
+ - That does not happen when an absolute path is provided.
+ -
+ - Also, the files output by ls-files are relative to the cwd. 
+ - Unless it's run on remote. Then it's relative to the top of the remote
+ - repo.
+ -
+ - So, best to avoid that class of problems.
+ -}
+safeForLsFiles :: Repo -> Bool
+safeForLsFiles r = isNothing (remoteName r)
+
+guardSafeForLsFiles :: Repo -> IO a -> IO a
+guardSafeForLsFiles r a
+	| safeForLsFiles r = a
+	| otherwise = giveup $ "git ls-files is unsafe to run on repository " ++ repoDescribe r
+
+data Options = ErrorUnmatch
+
+opParam :: Options -> CommandParam
+opParam ErrorUnmatch = Param "--error-unmatch"
+
+{- Lists files that are checked into git's index at the specified paths.
+ - With no paths, all files are listed.
+ -}
+inRepo :: [Options] -> [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+inRepo = inRepo' [Param "--cached"] 
+
+inRepo' :: [CommandParam] -> [Options] -> [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+inRepo' ps os l repo = guardSafeForLsFiles repo $ pipeNullSplit' params repo
+  where
+	params = 
+		Param "ls-files" :
+		Param "-z" :
+		map opParam os ++ ps ++
+		(Param "--" : map (File . fromRawFilePath) l)
+
+{- Lists the same files inRepo does, but with sha and mode. -}
+inRepoDetails :: [Options] -> [RawFilePath] -> Repo -> IO ([(RawFilePath, Sha, FileMode)], IO Bool)
+inRepoDetails = stagedDetails' parser . map opParam
+  where
+	parser s = case parseStagedDetails s of
+		Just (file, sha, mode, stagenum)
+			| stagenum == usualStageNum || stagenum == mergeConflictHeadStageNum ->
+				Just (file, sha, mode)
+		_ -> Nothing
+
+{- Files that are checked into the index or have been committed to a
+ - branch. -}
+inRepoOrBranch :: Branch -> [Options] -> [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+inRepoOrBranch b = inRepo'
+	[ Param "--cached"
+	, Param ("--with-tree=" ++ fromRef b)
+	]
+
+{- Scans for files at the specified locations that are not checked into git. -}
+notInRepo :: [Options] -> Bool -> [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+notInRepo = notInRepo' []
+
+notInRepo' :: [CommandParam] -> [Options] -> Bool -> [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+notInRepo' ps os include_ignored = 
+	inRepo' (Param "--others" : ps ++ exclude) os
+  where
+	exclude
+		| include_ignored = []
+		| otherwise = [Param "--exclude-standard"]
+
+{- Scans for files at the specified locations that are not checked into
+ - git. Empty directories are included in the result. -}
+notInRepoIncludingEmptyDirectories :: [Options] -> Bool -> [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+notInRepoIncludingEmptyDirectories = notInRepo' [Param "--directory"]
+
+{- Finds all files in the specified locations, whether checked into git or
+ - not. -}
+allFiles :: [Options] -> [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+allFiles = inRepo' [Param "--cached", Param "--others"]
+
+{- Returns a list of files in the specified locations that have been
+ - deleted. -}
+deleted :: [Options] -> [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+deleted = inRepo' [Param "--deleted"]
+
+{- Returns a list of files in the specified locations that have been
+ - modified. -}
+modified :: [Options] -> [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+modified = inRepo' [Param "--modified"]
+
+{- Returns a list of all files that are staged for commit. -}
+staged :: [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+staged = staged' []
+
+{- Returns a list of the files, staged for commit, that are being added,
+ - moved, or changed (but not deleted), from the specified locations. -}
+stagedNotDeleted :: [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+stagedNotDeleted = staged' [Param "--diff-filter=ACMRT"]
+
+staged' :: [CommandParam] -> [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+staged' ps l repo = guardSafeForLsFiles repo $
+	pipeNullSplit' (prefix ++ ps ++ suffix) repo
+  where
+	prefix = [Param "diff", Param "--cached", Param "--name-only", Param "-z"]
+	suffix = Param "--" : map (File . fromRawFilePath) l
+
+type StagedDetails = (RawFilePath, Sha, FileMode, StageNum)
+
+type StageNum = Int
+
+{- Used when not in a merge conflict. -}
+usualStageNum :: Int
+usualStageNum = 0
+
+{- WHen in a merge conflict, git uses stage number 2 for the local HEAD
+ - side of the merge conflict. -}
+mergeConflictHeadStageNum :: Int
+mergeConflictHeadStageNum = 2
+
+{- Returns details about all files that are staged in the index.
+ -
+ - Note that, during a conflict, a file will appear in the list
+ - more than once with different stage numbers.
+ -}
+stagedDetails :: [RawFilePath] -> Repo -> IO ([StagedDetails], IO Bool)
+stagedDetails = stagedDetails' parseStagedDetails []
+
+stagedDetails' :: (S.ByteString -> Maybe t) -> [CommandParam] -> [RawFilePath] -> Repo -> IO ([t], IO Bool)
+stagedDetails' parser ps l repo = guardSafeForLsFiles repo $ do
+	(ls, cleanup) <- pipeNullSplit' params repo
+	return (mapMaybe parser ls, cleanup)
+  where
+	params = Param "ls-files" : Param "--stage" : Param "-z" : ps ++ 
+		Param "--" : map (File . fromRawFilePath) l
+
+parseStagedDetails :: S.ByteString -> Maybe StagedDetails
+parseStagedDetails = eitherToMaybe . A.parseOnly parser
+  where
+	parser = do
+		mode <- octal
+		void $ A8.char ' '
+		sha <- maybe (fail "bad sha") return . extractSha =<< nextword
+		void $ A8.char ' '
+		stagenum <- A8.decimal
+		void $ A8.char '\t'
+		file <- A.takeByteString
+		return (file, sha, mode, stagenum)
+	
+	nextword = A8.takeTill (== ' ')
+
+{- Returns a list of the files in the specified locations that are staged
+ - for commit, and whose type has changed. -}
+typeChangedStaged :: [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+typeChangedStaged = typeChanged' [Param "--cached"]
+
+{- Returns a list of the files in the specified locations whose type has
+ - changed.  Files only staged for commit will not be included. -}
+typeChanged :: [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+typeChanged = typeChanged' []
+
+typeChanged' :: [CommandParam] -> [RawFilePath] -> Repo -> IO ([RawFilePath], IO Bool)
+typeChanged' ps l repo = guardSafeForLsFiles repo $ do
+	(fs, cleanup) <- pipeNullSplit' (prefix ++ ps ++ suffix) repo
+	-- git diff returns filenames relative to the top of the git repo;
+	-- convert to filenames relative to the cwd, like git ls-files.
+	top <- absPath (repoPath repo)
+	currdir <- R.getCurrentDirectory
+	return (map (\f -> relPathDirToFileAbs currdir $ top P.</> f) fs, cleanup)
+  where
+	prefix = 
+		[ Param "diff"
+		, Param "--name-only"
+		, Param "--diff-filter=T"
+		, Param "-z"
+		]
+	suffix = Param "--" : (if null l then [File "."] else map (File . fromRawFilePath) l)
+
+{- A item in conflict has two possible values.
+ - Either can be Nothing, when that side deleted the file. -}
+data Conflicting v = Conflicting
+	{ valUs :: Maybe v
+	, valThem :: Maybe v
+	} deriving (Show)
+
+data Unmerged = Unmerged
+	{ unmergedFile :: RawFilePath
+	, unmergedTreeItemType :: Conflicting TreeItemType
+	, unmergedSha :: Conflicting Sha
+	, unmergedSiblingFile :: Maybe RawFilePath
+	-- ^ Normally this is Nothing, because a
+	-- merge conflict is represented as a single file with two
+	-- stages. However, git resolvers sometimes choose to stage
+	-- two files, one for each side of the merge conflict. In such a case,
+	-- this is used for the name of the second file, which is related
+	-- to the first file. (Eg, "foo" and "foo~ref")
+	} deriving (Show)
+
+{- Returns a list of the files in the specified locations that have
+ - unresolved merge conflicts.
+ -
+ - ls-files outputs multiple lines per conflicting file, each with its own
+ - stage number:
+ -   1 = old version, can be ignored
+ -   2 = us
+ -   3 = them
+ - If line 2 or 3 is omitted, that side removed the file.
+ -}
+unmerged :: [RawFilePath] -> Repo -> IO ([Unmerged], IO Bool)
+unmerged l repo = guardSafeForLsFiles repo $ do
+	(fs, cleanup) <- pipeNullSplit params repo
+	return (reduceUnmerged [] $ catMaybes $ map (parseUnmerged . decodeBL) fs, cleanup)
+  where
+	params = 
+		Param "ls-files" :
+		Param "--unmerged" :
+		Param "-z" :
+		Param "--" :
+		map (File . fromRawFilePath) l
+
+data InternalUnmerged = InternalUnmerged
+	{ isus :: Bool
+	, ifile :: RawFilePath
+	, itreeitemtype :: Maybe TreeItemType
+	, isha :: Maybe Sha
+	} deriving (Show)
+
+parseUnmerged :: String -> Maybe InternalUnmerged
+parseUnmerged s
+	| null file = Nothing
+	| otherwise = case words metadata of
+		(rawtreeitemtype:rawsha:rawstage:_) -> do
+			stage <- readish rawstage :: Maybe Int
+			if stage /= 2 && stage /= 3
+				then Nothing
+				else do
+					treeitemtype <- readTreeItemType (encodeBS rawtreeitemtype)
+					sha <- extractSha (encodeBS rawsha)
+					return $ InternalUnmerged (stage == 2) (toRawFilePath file)
+						(Just treeitemtype) (Just sha)
+		_ -> Nothing
+  where
+	(metadata, file) = separate (== '\t') s
+
+reduceUnmerged :: [Unmerged] -> [InternalUnmerged] -> [Unmerged]
+reduceUnmerged c [] = c
+reduceUnmerged c (i:is) = reduceUnmerged (new:c) rest
+  where
+	(rest, sibi) = findsib i is
+	(treeitemtypeA, treeitemtypeB, shaA, shaB)
+		| isus i    = (itreeitemtype i, itreeitemtype sibi, isha i, isha sibi)
+		| otherwise = (itreeitemtype sibi, itreeitemtype i, isha sibi, isha i)
+	new = Unmerged
+		{ unmergedFile = ifile i
+		, unmergedTreeItemType = Conflicting treeitemtypeA treeitemtypeB
+		, unmergedSha = Conflicting shaA shaB
+		, unmergedSiblingFile = if ifile sibi == ifile i
+			then Nothing
+			else Just (ifile sibi)
+		}
+	findsib templatei [] = ([], removed templatei)
+	findsib templatei (l:ls)
+		| ifile l == ifile templatei || issibfile templatei l = (ls, l)
+		| otherwise = (l:ls, removed templatei)
+	removed templatei = templatei
+		{ isus = not (isus templatei)
+		, itreeitemtype = Nothing
+		, isha = Nothing
+		}
+	-- foo~<ref> are unmerged sibling files of foo
+	-- Some versions or resolvers of git stage the sibling files,
+	-- other versions or resolvers do not.
+	issibfile x y = (ifile x <> "~") `S.isPrefixOf` ifile y
+		&& isus x || isus y
+		&& not (isus x && isus y)
+
+{- Gets the InodeCache equivalent information stored in the git index.
+ -
+ - Note that this uses a --debug option whose output could change at some
+ - point in the future. If the output is not as expected, will use Nothing.
+ -}
+inodeCaches :: [RawFilePath] -> Repo -> IO ([(FilePath, Maybe InodeCache)], IO Bool)
+inodeCaches locs repo = guardSafeForLsFiles repo $ do
+	(ls, cleanup) <- pipeNullSplit params repo
+	return (parse Nothing (map decodeBL ls), cleanup)
+  where
+	params = 
+		Param "ls-files" :
+		Param "--cached" :
+		Param "-z" :
+		Param "--debug" :
+		Param "--" :
+		map (File . fromRawFilePath) locs
+	
+	parse Nothing (f:ls) = parse (Just f) ls
+	parse (Just f) (s:[]) = 
+		let i = parsedebug s
+		in (f, i) : []
+	parse (Just f) (s:ls) =
+		let (d, f') = splitdebug s
+		    i = parsedebug d
+		in (f, i) : parse (Just f') ls
+	parse _ _ = []
+
+	-- First 5 lines are --debug output, remainder is the next filename.
+	-- This assumes that --debug does not start outputting more lines.
+	splitdebug s = case splitc '\n' s of
+		(d1:d2:d3:d4:d5:rest) ->
+			( intercalate "\n" [d1, d2, d3, d4, d5]
+			, intercalate "\n" rest
+			)
+		_ -> ("", s)
+	
+	-- This parser allows for some changes to the --debug output,
+	-- including reordering, or adding more items.
+	parsedebug s = do
+		let l = words s
+		let iskey v = ":" `isSuffixOf` v
+		let m = M.fromList $ zip
+			(filter iskey l)
+			(filter (not . iskey) l)
+		mkInodeCache
+			<$> (readish =<< M.lookup "ino:" m)
+			<*> (readish =<< M.lookup "size:" m)
+			<*> (parsePOSIXTime =<< (replace ":" "." <$> M.lookup "mtime:" m))
diff --git a/Git/LsTree.hs b/Git/LsTree.hs
new file mode 100644
index 0000000000..9129d18fc4
--- /dev/null
+++ b/Git/LsTree.hs
@@ -0,0 +1,155 @@
+{- git ls-tree interface
+ -
+ - Copyright 2011-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.LsTree (
+	TreeItem(..),
+	LsTreeRecursive(..),
+	LsTreeLong(..),
+	lsTree,
+	lsTree',
+	lsTreeStrict,
+	lsTreeStrict',
+	lsTreeParams,
+	lsTreeFiles,
+	parseLsTree,
+	formatLsTree,
+) where
+
+import Common
+import Git
+import Git.Command
+import Git.FilePath
+import qualified Git.Quote
+import Utility.Attoparsec
+
+import Numeric
+import Data.Either
+import Data.Char
+import System.Posix.Types
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString as AS
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+
+data TreeItem = TreeItem
+	{ mode :: FileMode
+	, typeobj :: S.ByteString
+	, sha :: Ref
+	, size :: Maybe FileSize
+	, file :: TopFilePath
+	-- ^ only available when long is used
+	} deriving (Show)
+
+data LsTreeRecursive = LsTreeRecursive | LsTreeNonRecursive
+
+{- Enabling --long also gets the size of tree items.
+ - This slows down ls-tree some, since it has to look up the size of each
+ - blob.
+ -}
+data LsTreeLong = LsTreeLong Bool
+
+{- Lists the contents of a tree, with lazy output. -}
+lsTree :: LsTreeRecursive -> LsTreeLong -> Ref -> Repo -> IO ([TreeItem], IO Bool)
+lsTree = lsTree' []
+
+lsTree' :: [CommandParam] -> LsTreeRecursive -> LsTreeLong -> Ref -> Repo -> IO ([TreeItem], IO Bool)
+lsTree' ps recursive long t repo = do
+	(l, cleanup) <- pipeNullSplit (lsTreeParams recursive long t ps) repo
+	return (rights (map (parseLsTree long) l), cleanup)
+
+lsTreeStrict :: LsTreeRecursive -> LsTreeLong -> Ref -> Repo -> IO [TreeItem]
+lsTreeStrict = lsTreeStrict' []
+
+lsTreeStrict' :: [CommandParam] -> LsTreeRecursive -> LsTreeLong -> Ref -> Repo -> IO [TreeItem]
+lsTreeStrict' ps recursive long t repo = rights . map (parseLsTreeStrict long)
+	<$> pipeNullSplitStrict (lsTreeParams recursive long t ps) repo
+
+lsTreeParams :: LsTreeRecursive -> LsTreeLong -> Ref -> [CommandParam] -> [CommandParam]
+lsTreeParams recursive long r ps =
+	[ Param "ls-tree"
+	, Param "--full-tree"
+	, Param "-z"
+	] ++ recursiveparams ++ longparams ++ ps ++
+	[ Param "--"
+	, File $ fromRef r
+	]
+  where
+	recursiveparams = case recursive of
+		LsTreeRecursive -> [ Param "-r" ]
+		LsTreeNonRecursive -> []
+	longparams = case long of
+		LsTreeLong True -> [ Param "--long" ]
+		LsTreeLong False -> []
+
+{- Lists specified files in a tree. -}
+lsTreeFiles :: LsTreeLong -> Ref -> [FilePath] -> Repo -> IO [TreeItem]
+lsTreeFiles long t fs repo = rights . map (parseLsTree long . L.fromStrict)
+	<$> pipeNullSplitStrict ps repo
+  where
+	ps =
+		[ Param "ls-tree"
+		, Param "--full-tree"
+		, Param "-z"
+		, Param "--"
+		, File $ fromRef t
+		] ++ map File fs
+
+parseLsTree :: LsTreeLong -> L.ByteString -> Either String TreeItem
+parseLsTree long b = case A.parse (parserLsTree long) b of
+	A.Done _ r  -> Right r
+	A.Fail _ _ err -> Left err
+
+parseLsTreeStrict :: LsTreeLong -> S.ByteString -> Either String TreeItem
+parseLsTreeStrict long b = go (AS.parse (parserLsTree long) b)
+  where
+	go (AS.Done _ r) = Right r
+	go (AS.Fail _ _ err) = Left err
+	go (AS.Partial c) = go (c mempty)
+
+{- Parses a line of ls-tree output, in format:
+ -   mode SP type SP sha TAB file
+ - Or long format:
+ -   mode SP type SP sha SPACES size TAB file
+ -
+ - The TAB can also be a space. Git does not use that, but an earlier
+ - version of formatLsTree did, and this keeps parsing what it output
+ - working.
+ -}
+parserLsTree :: LsTreeLong -> A.Parser TreeItem
+parserLsTree long = case long of
+	LsTreeLong False -> 
+		startparser <*> pure Nothing <* filesep <*> fileparser
+	LsTreeLong True ->
+		startparser <* sizesep <*> sizeparser <* filesep <*> fileparser
+  where
+	startparser = TreeItem
+		-- mode
+		<$> octal
+		<* A8.char ' '
+		-- type
+		<*> A8.takeTill (== ' ')
+		<* A8.char ' '
+		-- sha
+		<*> (Ref <$> A8.takeTill A8.isSpace)
+
+	fileparser = asTopFilePath . Git.Quote.unquote <$> A.takeByteString
+
+	sizeparser = fmap Just A8.decimal
+
+	filesep = A8.space
+
+	sizesep = A.many1 A8.space
+
+{- Inverse of parseLsTree. Note that the long output format is not
+ - generated, so any size information is not included. -}
+formatLsTree :: TreeItem -> S.ByteString
+formatLsTree ti = S.intercalate (S.singleton (fromIntegral (ord ' ')))
+	[ encodeBS (showOct (mode ti) "")
+	, typeobj ti
+	, fromRef' (sha ti)
+	] <> (S.cons (fromIntegral (ord '\t')) (getTopFilePath (file ti)))
diff --git a/Git/Merge.hs b/Git/Merge.hs
new file mode 100644
index 0000000000..b88d9a00f5
--- /dev/null
+++ b/Git/Merge.hs
@@ -0,0 +1,78 @@
+{- git merging
+ -
+ - Copyright 2012-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.Merge (
+	MergeConfig(..),
+	CommitMode(..),
+	merge,
+	merge',
+	mergeUnrelatedHistoriesParam,
+	stageMerge,
+) where
+
+import Common
+import Git
+import Git.Command
+import qualified Git.Version
+import Git.Branch (CommitMode(..))
+
+data MergeConfig
+	= MergeNonInteractive
+	-- ^ avoids interactive merge with commit message edit
+	| MergeUnrelatedHistories
+	-- ^ avoids git's prevention of merging unrelated histories
+	| MergeQuiet
+	-- ^ avoids usual output when merging, but errors will still be
+	-- displayed
+	deriving (Eq)
+
+merge :: Ref -> [MergeConfig] -> CommitMode -> Repo -> IO Bool
+merge = merge' []
+
+merge' :: [CommandParam] -> Ref -> [MergeConfig] -> CommitMode -> Repo -> IO Bool
+merge' extraparams branch mergeconfig commitmode r
+	| MergeNonInteractive `notElem` mergeconfig =
+		go [Param $ fromRef branch]
+	| otherwise = go [Param "--no-edit", Param $ fromRef branch]
+  where
+	go ps = merge'' (sp ++ [Param "merge"] ++ qp ++ ps ++ extraparams) mergeconfig r
+	sp
+		| commitmode == AutomaticCommit =
+			[Param "-c", Param "commit.gpgsign=false"]
+		| otherwise = []
+	qp
+		| MergeQuiet `notElem` mergeconfig = []
+		| otherwise = [Param "--quiet"]
+
+merge'' :: [CommandParam] -> [MergeConfig] -> Repo -> IO Bool
+merge'' ps mergeconfig r
+	| MergeUnrelatedHistories `elem` mergeconfig = do
+		up <- mergeUnrelatedHistoriesParam
+		go (ps ++ maybeToList up)
+	| otherwise = go ps
+  where
+	go ps' = runBool ps' r
+
+{- Git used to default to merging unrelated histories; newer versions need
+ - an option. -}
+mergeUnrelatedHistoriesParam :: IO (Maybe CommandParam)
+mergeUnrelatedHistoriesParam = ifM (Git.Version.older "2.9.0")
+	( return Nothing
+	, return (Just (Param "--allow-unrelated-histories"))
+	)
+
+{- Stage the merge into the index, but do not commit it.-}
+stageMerge :: Ref -> [MergeConfig] -> Repo -> IO Bool
+stageMerge branch = merge''
+	[ Param "merge"
+	, Param "--quiet"
+	, Param "--no-commit"
+	-- Without this, a fast-forward merge is done, since it involves no
+	-- commit.
+	, Param "--no-ff"
+	, Param $ fromRef branch
+	]
diff --git a/Git/Objects.hs b/Git/Objects.hs
new file mode 100644
index 0000000000..1390209e97
--- /dev/null
+++ b/Git/Objects.hs
@@ -0,0 +1,55 @@
+{- .git/objects
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.Objects where
+
+import Common
+import Git
+import Git.Sha
+
+import qualified Data.ByteString as B
+import qualified System.FilePath.ByteString as P
+
+objectsDir :: Repo -> RawFilePath
+objectsDir r = localGitDir r P.</> "objects"
+
+packDir :: Repo -> RawFilePath
+packDir r = objectsDir r P.</> "pack"
+
+packIdxFile :: RawFilePath -> RawFilePath
+packIdxFile = flip P.replaceExtension "idx"
+
+listPackFiles :: Repo -> IO [FilePath]
+listPackFiles r = filter (".pack" `isSuffixOf`) 
+	<$> catchDefaultIO [] (dirContents $ fromRawFilePath $ packDir r)
+
+listLooseObjectShas :: Repo -> IO [Sha]
+listLooseObjectShas r = catchDefaultIO [] $
+	mapMaybe (extractSha . encodeBS . concat . reverse . take 2 . reverse . splitDirectories)
+		<$> emptyWhenDoesNotExist (dirContentsRecursiveSkipping (== "pack") True (fromRawFilePath (objectsDir r)))
+
+looseObjectFile :: Repo -> Sha -> RawFilePath
+looseObjectFile r sha = objectsDir r P.</> prefix P.</> rest
+  where
+	(prefix, rest) = B.splitAt 2 (fromRef' sha)
+
+listAlternates :: Repo -> IO [FilePath]
+listAlternates r = catchDefaultIO [] $
+	lines <$> readFile (fromRawFilePath alternatesfile)
+  where
+	alternatesfile = objectsDir r P.</> "info" P.</> "alternates"
+
+{- A repository recently cloned with --shared will have one or more
+ - alternates listed, and contain no loose objects or packs. -}
+isSharedClone :: Repo -> IO Bool
+isSharedClone r = allM id
+	[ not . null <$> listAlternates r
+	, null <$> listLooseObjectShas r
+	, null <$> listPackFiles r
+	]
diff --git a/Git/PktLine.hs b/Git/PktLine.hs
new file mode 100644
index 0000000000..95e8af26be
--- /dev/null
+++ b/Git/PktLine.hs
@@ -0,0 +1,154 @@
+{- git pkt-line communication format
+ -
+ - As documented in git's Documentation/technical/protocol-common.txt
+ -
+ - Copyright 2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.PktLine (
+	PktLine,
+	pktLineToByteString,
+	pktLineToString,
+	readPktLine,
+	encodePktLine,
+	stringPktLine,
+	writePktLine,
+	flushPkt,
+	isFlushPkt,
+	readUntilFlushPkt,
+	readUntilFlushPktOrSize,
+	discardUntilFlushPkt,
+) where
+
+import System.IO
+import qualified Data.ByteString as B
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+import Text.Printf
+
+import Utility.PartialPrelude
+import Utility.FileSystemEncoding
+import Utility.Exception
+
+{- This is a variable length binary string, but its size is limited to
+ - maxPktLineLength. Its serialization includes a 4 byte hexadecimal
+ - prefix giving its total length, including that prefix. -}
+newtype PktLine = PktLine B.ByteString
+	deriving (Show)
+
+{- Maximum allowed length of the string encoded in PktLine
+ - is slightly shorter than the absolute maximum possible length.
+ - Git does not accept anything longer than this. -}
+maxPktLineLength :: Int
+maxPktLineLength = 65520 - pktLineHeaderLength
+
+pktLineHeaderLength :: Int
+pktLineHeaderLength = 4
+
+pktLineToByteString :: PktLine -> B.ByteString
+pktLineToByteString (PktLine b) = b
+
+{- When the pkt-line contains non-binary data, its serialization
+ - may include a terminating newline. This removes that newline, if it was
+ - present.
+ -
+ - Note that the pkt-line has no defined encoding, and could still
+ - contain something non-ascii, eg a filename. -}
+pktLineToString :: PktLine -> String
+pktLineToString (PktLine b) = 
+	let s = decodeBS b
+	in case lastMaybe s of
+		Just '\n' -> beginning s
+		_ -> s
+
+{- Reads the next PktLine from a Handle. Returns Nothing on EOF or when
+ - there is a protocol error. -}
+readPktLine :: Handle -> IO (Maybe PktLine)
+readPktLine h = do
+	lenb <- B.hGet h pktLineHeaderLength
+	if B.length lenb < pktLineHeaderLength
+		then return Nothing
+		else case A8.parseOnly (A8.hexadecimal <* A8.endOfInput) lenb of
+			Right len -> go (len - pktLineHeaderLength) mempty
+			_ -> return Nothing
+  where
+	go n b
+		| n <= 0 = return (Just (PktLine b))
+		| otherwise = do
+			b' <- B.hGet h n
+			if B.length b' == 0
+				then return Nothing -- EOF
+				else go (n - B.length b') (b <> b')
+
+{- Encodes the ByteString as a PktLine. But if the ByteString is too
+ - long to fit in a single PktLine, returns the remainder of it. -}
+encodePktLine :: B.ByteString -> (PktLine, Maybe B.ByteString)
+encodePktLine b
+	| B.length b > maxPktLineLength =
+		let (b', rest) = B.splitAt maxPktLineLength b
+		in (PktLine b', Just rest)
+	| otherwise = (PktLine b, Nothing)
+
+{- If the String is too long to fit in a single PktLine,
+ - will throw an error. -}
+stringPktLine :: String -> PktLine
+stringPktLine s
+	| length s > maxPktLineLength =
+		giveup "textPktLine called with too-long value"
+	| otherwise = PktLine (encodeBS s <> "\n")
+
+{- Sends a PktLine to a Handle, and flushes it so that it will be
+ - visible to the Handle's reader. -}
+writePktLine :: Handle -> PktLine -> IO ()
+writePktLine h (PktLine b)
+	-- Special case for empty string; avoid encoding as "0004".
+	| B.null b = do
+		B.hPut h "0000"
+		hFlush h
+	| otherwise = do
+		hPutStr h $ printf "%04x" (B.length b + pktLineHeaderLength)
+		B.hPut h b
+		hFlush h
+
+flushPkt :: PktLine
+flushPkt = PktLine mempty
+
+isFlushPkt :: PktLine -> Bool
+isFlushPkt (PktLine b) = b == mempty
+
+{- Reads PktLines until a flushPkt (or EOF), 
+ - and returns all except the flushPkt -}
+readUntilFlushPkt :: IO [PktLine]
+readUntilFlushPkt = go []
+  where
+	go l = readPktLine stdin >>= \case
+		Just pktline | not (isFlushPkt pktline) -> go (pktline:l)
+		_ -> return (reverse l)
+
+{- Reads PktLines until at least the specified number of bytes have been
+ - read, or until a flushPkt (or EOF). Returns Right if it did read a
+ - flushPkt/EOF, and Left if there is still content leftover that needs to
+ - be read. -}
+readUntilFlushPktOrSize :: Int -> IO (Either [PktLine] [PktLine])
+readUntilFlushPktOrSize = go []
+  where
+	go l n = readPktLine stdin >>= \case
+		Just pktline
+			| isFlushPkt pktline -> return (Right (reverse l))
+			| otherwise -> 
+				let len = B.length (pktLineToByteString pktline)
+				    n' = n - len
+				in if n' <= 0
+					then return (Left (reverse (pktline:l)))
+					else go (pktline:l) n'
+		Nothing -> return (Right (reverse l))
+
+{- Reads PktLines until a flushPkt (or EOF), and throws them away. -}
+discardUntilFlushPkt :: IO ()
+discardUntilFlushPkt = readPktLine stdin >>= \case
+	Just pktline | isFlushPkt pktline -> return ()
+	Nothing -> return ()
+	_ -> discardUntilFlushPkt
diff --git a/Git/Queue.hs b/Git/Queue.hs
new file mode 100644
index 0000000000..156ed8c95a
--- /dev/null
+++ b/Git/Queue.hs
@@ -0,0 +1,267 @@
+{- git repository command queue
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP, BangPatterns #-}
+
+module Git.Queue (
+	Queue,
+	new,
+	defaultTimelimit,
+	addCommand,
+	addUpdateIndex,
+	addFlushAction,
+	FlushActionRunner(..),
+	size,
+	full,
+	flush,
+	merge,
+) where
+
+import Utility.SafeCommand
+import Common
+import Git
+import Git.Command
+import qualified Git.UpdateIndex
+
+import qualified Data.Map.Strict as M
+import Control.Monad.IO.Class
+import Data.Time.Clock
+import Data.Time.Clock.POSIX
+
+{- Queable actions that can be performed in a git repository. -}
+data Action m
+	{- Updating the index file, using a list of streamers that can
+	 - be added to as the queue grows. -}
+	= UpdateIndexAction [Git.UpdateIndex.Streamer] -- in reverse order
+	{- A git command to run, on a list of files that can be added to
+	 - as the queue grows. -}
+	| CommandAction 
+		{ getCommonParams :: [CommandParam]
+		-- ^ parameters that come before the git subcommand
+		-- (in addition to the Repo's gitGlobalOpts.
+		, getSubcommand :: String
+		, getParams :: [CommandParam]
+		-- ^ parameters that come after the git subcommand
+		, getFiles :: [CommandParam]
+		} 
+	{- A FlushAction can be added along with CommandActions or
+	 - UpdateIndexActions, and when the queue later gets flushed,
+	 - those will be run before the FlushAction is. -}
+	| FlushAction
+		{ getFlushActionRunner :: FlushActionRunner m
+		, getFlushActionFiles :: [RawFilePath]
+		}
+
+{- The String must be unique for each flush action. -}
+data FlushActionRunner m = FlushActionRunner String (Repo -> [RawFilePath] -> m ())
+
+instance Eq (FlushActionRunner m) where
+	FlushActionRunner s1 _ == FlushActionRunner s2 _ = s1 == s2
+
+{- A key that can uniquely represent an action in a Map.
+ -
+ - The ordering controls what order the actions are run in when flushing
+ - the queue. -}
+data ActionKey
+	= UpdateIndexActionKey
+	| CommandActionKey [CommandParam] String [CommandParam]
+	| FlushActionKey String
+	deriving (Eq, Ord)
+
+actionKey :: Action m -> ActionKey
+actionKey (UpdateIndexAction _) = UpdateIndexActionKey
+actionKey CommandAction { getCommonParams = c, getSubcommand = s, getParams = p } = CommandActionKey c s p
+actionKey FlushAction { getFlushActionRunner = FlushActionRunner s _ } = FlushActionKey s
+
+{- A queue of actions to perform (in any order) on a git repository,
+ - with lists of files to perform them on. This allows coalescing 
+ - similar git commands. -}
+data Queue m = Queue
+	{ size :: Int
+	, _limit :: Int
+	, _timelimit :: NominalDiffTime
+	, _lastchanged :: POSIXTime
+	, items :: M.Map ActionKey (Action m)
+	}
+
+{- A recommended maximum size for the queue, after which it should be
+ - run.
+ -
+ - 10240 is semi-arbitrary. If we assume git filenames are between 10 and
+ - 255 characters long, then the queue will build up between 100kb and
+ - 2550kb long commands. The max command line length on linux is somewhere
+ - above 20k, so this is a fairly good balance -- the queue will buffer
+ - only a few megabytes of stuff and a minimal number of commands will be
+ - run by xargs. -}
+defaultLimit :: Int
+defaultLimit = 10240
+
+{- How close together in seconds changes to the queue have to be happening
+ - in order for it to keep accumulating actions, rather than running actions
+ - immediately. -}
+defaultTimelimit :: NominalDiffTime
+defaultTimelimit = 60 * 5
+
+{- Constructor for empty queue. -}
+new :: Maybe Int -> Maybe NominalDiffTime -> IO (Queue m)
+new lim tlim = do
+	now <- getPOSIXTime
+	return $ Queue 0
+		(fromMaybe defaultLimit lim)
+		(fromMaybe defaultTimelimit tlim)
+		now
+		M.empty
+
+{- Adds an git command to the queue.
+ -
+ - Git commands with the same subcommand but different parameters are
+ - assumed to be equivalent enough to perform in any order with the same
+ - end result.
+ -}
+addCommand :: MonadIO m => [CommandParam] -> String -> [CommandParam] -> [FilePath] -> Queue m -> Repo -> m (Queue m)
+addCommand commonparams subcommand params files q repo =
+	updateQueue action conflicting (length files) q repo
+  where
+	action = CommandAction
+		{ getCommonParams = commonparams
+		, getSubcommand = subcommand
+		, getParams = params
+		, getFiles = map File files
+		}
+	
+	conflicting (CommandAction { getSubcommand = s }) = s /= subcommand
+	conflicting (FlushAction {}) = False
+	conflicting _ = True
+
+{- Adds an flush action to the queue. This can co-exist with anything else
+ - that gets added to the queue, and when the queue is eventually flushed,
+ - it will be run after the other things in the queue. -}
+addFlushAction :: MonadIO m => FlushActionRunner m -> [RawFilePath] -> Queue m -> Repo -> m (Queue m)
+addFlushAction runner files q repo =
+	updateQueue action (const False) (length files) q repo
+  where
+	action = FlushAction
+		{ getFlushActionRunner = runner
+		, getFlushActionFiles = files
+		}
+
+{- Adds an update-index streamer to the queue. -}
+addUpdateIndex :: MonadIO m => Git.UpdateIndex.Streamer -> Queue m -> Repo -> m (Queue m)
+addUpdateIndex streamer q repo =
+	updateQueue action conflicting 1 q repo
+  where
+	-- the list is built in reverse order
+	action = UpdateIndexAction [streamer]
+
+	conflicting (UpdateIndexAction _) = False
+	conflicting (FlushAction {}) = False
+	conflicting _ = True
+
+{- Updates or adds an action in the queue.
+ -
+ - If the queue already contains a conflicting action, it will be flushed
+ - before adding the action; this is to ensure that conflicting actions,
+ - like add and rm, are run in the right order.
+ -
+ - If the queue's time limit has been exceeded, it will also be flushed,
+ - and the action will be run right away.
+ -}
+updateQueue :: MonadIO m => Action m -> (Action m -> Bool) -> Int -> Queue m -> Repo -> m (Queue m)
+updateQueue !action conflicting sizeincrease q repo = do
+	now <- liftIO getPOSIXTime
+	if now - (_lastchanged q) > _timelimit q
+		then if isconflicting
+			then do
+				q' <- flush q repo
+				flush (mk q') repo
+			else flush (mk q) repo
+		else if isconflicting
+			then mk <$> flush q repo
+			else return $ mk (q { _lastchanged = now })
+  where
+	isconflicting = not (null (filter conflicting (M.elems (items q))))
+	mk q' = newq
+	  where		
+		!newq = q'
+			{ size = newsize
+			, items = newitems
+			}
+		!newsize = size q' + sizeincrease
+		!newitems = M.insertWith combineNewOld (actionKey action) action (items q')
+
+{- The new value comes first. It probably has a smaller list of files than
+ - the old value. So, the list append of the new value first is more
+ - efficient. -}
+combineNewOld :: Action m -> Action m -> Action m
+combineNewOld (CommandAction _cps1 _sc1 _ps1 fs1) (CommandAction cps2 sc2 ps2 fs2) =
+	CommandAction cps2 sc2 ps2 (fs1++fs2)
+combineNewOld (UpdateIndexAction s1) (UpdateIndexAction s2) =
+	UpdateIndexAction (s1++s2)
+combineNewOld (FlushAction _r1 fs1) (FlushAction r2 fs2) =
+	FlushAction r2 (fs1++fs2)
+combineNewOld anew _aold = anew
+
+{- Merges the contents of the second queue into the first.
+ - This should only be used when the two queues are known to contain
+ - non-conflicting actions. -}
+merge :: Queue m -> Queue m -> Queue m
+merge origq newq = origq
+	{ size = size origq + size newq
+	, items = M.unionWith combineNewOld (items newq) (items origq)
+	, _lastchanged = max (_lastchanged origq) (_lastchanged newq)
+	}
+
+{- Is a queue large enough that it should be flushed? -}
+full :: Queue m -> Bool
+full (Queue cur lim _ _ _) = cur >= lim
+
+{- Runs a queue on a git repository. -}
+flush :: MonadIO m => Queue m -> Repo -> m (Queue m)
+flush (Queue _ lim tlim _ m) repo = do
+	forM_ (M.elems m) $ runAction repo
+	now <- liftIO getPOSIXTime
+	return $ Queue 0 lim tlim now M.empty
+
+{- Runs an Action on a list of files in a git repository.
+ -
+ - Complicated by commandline length limits.
+ -
+ - Intentionally runs the command even if the list of files is empty;
+ - this allows queueing commands that do not need a list of files. -}
+runAction :: MonadIO m => Repo -> Action m -> m ()
+runAction repo (UpdateIndexAction streamers) =
+	-- list is stored in reverse order
+	liftIO $ Git.UpdateIndex.streamUpdateIndex repo $ reverse streamers
+runAction repo action@(CommandAction {}) = liftIO $ do
+#ifndef mingw32_HOST_OS
+	let p = (proc "xargs" $ "-0":"git":toCommand gitparams)
+		{ env = gitEnv repo
+		, std_in = CreatePipe
+		}
+	withCreateProcess p (go p)
+#else
+	-- Using xargs on Windows is problematic, so just run the command
+	-- once per file (not as efficient.)
+	if null (getFiles action)
+		then void $ boolSystemEnv "git" gitparams (gitEnv repo)
+		else forM_ (getFiles action) $ \f ->
+			void $ boolSystemEnv "git" (gitparams ++ [f]) (gitEnv repo)
+#endif
+  where
+	gitparams = gitCommandLine
+		(getCommonParams action++Param (getSubcommand action):getParams action) 
+		repo
+#ifndef mingw32_HOST_OS
+	go p (Just h) _ _ pid = do
+		hPutStr h $ intercalate "\0" $ toCommand $ getFiles action
+		hClose h
+		forceSuccessProcess p pid
+	go _ _ _ _ _ = error "internal"
+#endif
+runAction repo action@(FlushAction {}) =
+	let FlushActionRunner _ runner = getFlushActionRunner action
+	in runner repo (getFlushActionFiles action)
diff --git a/Git/Quote.hs b/Git/Quote.hs
new file mode 100644
index 0000000000..2ca442ecb6
--- /dev/null
+++ b/Git/Quote.hs
@@ -0,0 +1,122 @@
+{- Some git commands output quoted filenames, in a rather annoyingly complex
+ - C-style encoding.
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, TypeSynonymInstances #-}
+
+module Git.Quote (
+	unquote,
+	quote,
+	noquote,
+	QuotePath(..),
+	StringContainingQuotedPath(..),
+	quotedPaths,
+	prop_quote_unquote_roundtrip,
+) where
+
+import Common
+import Utility.Format (decode_c, encode_c, encode_c', isUtf8Byte)
+import Utility.QuickCheck
+import Utility.SafeOutput
+
+import Data.Char
+import Data.Word
+import Data.String
+import qualified Data.ByteString as S
+import qualified Data.Semigroup as Sem
+import Prelude
+
+unquote :: S.ByteString -> RawFilePath
+unquote b = case S.uncons b of
+	Nothing -> b
+	Just (h, t)
+		| h /= q -> b
+		| otherwise -> case S.unsnoc t of
+			Nothing -> b
+			Just (i, l)
+				| l /= q -> b
+				| otherwise -> decode_c i
+  where
+  	q :: Word8
+	q = fromIntegral (ord '"')
+
+-- always encodes and double quotes, even in cases that git does not
+quoteAlways :: RawFilePath -> S.ByteString
+quoteAlways s = "\"" <> encode_c needencode s <> "\""
+  where
+	needencode c = isUtf8Byte c || c == fromIntegral (ord '"')
+
+-- git config core.quotePath controls whether to quote unicode characters
+newtype QuotePath = QuotePath Bool
+
+class Quoteable t where
+	-- double quotes and encodes when git would
+	quote :: QuotePath -> t -> S.ByteString
+
+	noquote :: t -> S.ByteString
+
+instance Quoteable RawFilePath where
+	quote (QuotePath qp) s = case encode_c' needencode s of
+		Nothing -> s
+		Just s' -> "\"" <> s' <> "\""
+	  where
+		needencode c
+			| c == fromIntegral (ord '"') = True
+			| qp = isUtf8Byte c
+			| otherwise = False
+
+	noquote = id
+
+-- Allows building up a string that contains paths, which will get quoted.
+-- With OverloadedStrings, strings are passed through without quoting.
+-- Eg: QuotedPath f <> ": not found"
+data StringContainingQuotedPath
+	= UnquotedString String 
+	| UnquotedByteString S.ByteString 
+	| QuotedPath RawFilePath
+	| StringContainingQuotedPath :+: StringContainingQuotedPath
+	deriving (Show, Eq)
+
+quotedPaths :: [RawFilePath] -> StringContainingQuotedPath
+quotedPaths [] = mempty
+quotedPaths (p:ps) = QuotedPath p <> if null ps
+	then mempty
+	else " " <> quotedPaths ps
+
+instance Quoteable StringContainingQuotedPath where
+	quote _ (UnquotedString s) = safeOutput (encodeBS s)
+	quote _ (UnquotedByteString s) = safeOutput s
+	quote qp (QuotedPath p) = quote qp p
+	quote qp (a :+: b) = quote qp a <> quote qp b
+
+	noquote (UnquotedString s) = encodeBS s
+	noquote (UnquotedByteString s) = s
+	noquote (QuotedPath p) = p
+	noquote (a :+: b) = noquote a <> noquote b
+
+instance IsString StringContainingQuotedPath where
+	fromString = UnquotedByteString . encodeBS
+
+instance Sem.Semigroup StringContainingQuotedPath where
+	UnquotedString a <> UnquotedString b = UnquotedString (a <> b)
+	UnquotedByteString a <> UnquotedByteString b = UnquotedByteString (a <> b)
+	a <> b = a :+: b
+
+instance Monoid StringContainingQuotedPath where
+	mempty = UnquotedByteString mempty
+
+-- Encoding and then decoding roundtrips only when the string does not
+-- contain high unicode, because eg, both "\12345" and "\227\128\185"
+-- are encoded to "\343\200\271".
+--
+-- That is not a real-world problem, and using TestableFilePath
+-- limits what's tested to ascii, so avoids running into it.
+prop_quote_unquote_roundtrip :: TestableFilePath -> Bool
+prop_quote_unquote_roundtrip ts = 
+	s == fromRawFilePath (unquote (quoteAlways (toRawFilePath s)))
+  where
+	s = fromTestableFilePath ts
diff --git a/Git/Ref.hs b/Git/Ref.hs
new file mode 100644
index 0000000000..2d2874a7ef
--- /dev/null
+++ b/Git/Ref.hs
@@ -0,0 +1,220 @@
+{- git ref stuff
+ -
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.Ref where
+
+import Common
+import Git
+import Git.Command
+import Git.Sha
+import Git.Types
+import Git.FilePath
+
+import Data.Char (chr, ord)
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as S8
+
+headRef :: Ref
+headRef = Ref "HEAD"
+
+headFile :: Repo -> FilePath
+headFile r = fromRawFilePath (localGitDir r) </> "HEAD"
+
+setHeadRef :: Ref -> Repo -> IO ()
+setHeadRef ref r = S.writeFile (headFile r) ("ref: " <> fromRef' ref)
+
+{- Converts a fully qualified git ref into a user-visible string. -}
+describe :: Ref -> String
+describe = fromRef . base
+
+{- Often git refs are fully qualified 
+ - (eg refs/heads/master or refs/remotes/origin/master).
+ - Converts such a fully qualified ref into a base ref
+ - (eg: master or origin/master). -}
+base :: Ref -> Ref
+base = removeBase "refs/heads/" . removeBase "refs/remotes/"
+
+{- Removes a directory such as "refs/heads/master" from a
+ - fully qualified ref. Any ref not starting with it is left as-is. -}
+removeBase :: String -> Ref -> Ref
+removeBase dir r
+	| prefix `isPrefixOf` rs = Ref $ encodeBS $ drop (length prefix) rs
+	| otherwise = r
+  where
+	rs = fromRef r
+	prefix = case end dir of
+		['/'] -> dir
+		_ -> dir ++ "/"
+
+{- Given a directory such as "refs/remotes/origin", and a ref such as
+ - refs/heads/master, yields a version of that ref under the directory,
+ - such as refs/remotes/origin/master. -}
+underBase :: String -> Ref -> Ref
+underBase dir r = Ref $ encodeBS dir <> "/" <> fromRef' (base r)
+
+{- Convert a branch such as "master" into a fully qualified ref. -}
+branchRef :: Branch -> Ref
+branchRef = underBase "refs/heads"
+
+{- A Ref that can be used to refer to a file in the repository, as staged
+ - in the index.
+ - 
+ - If the input file is located outside the repository, returns Nothing.
+ -}
+fileRef :: RawFilePath -> Repo -> IO (Maybe Ref)
+fileRef f repo = do
+	-- The filename could be absolute, or contain eg "../repo/file",
+	-- neither of which work in a ref, so convert it to a minimal
+	-- relative path.
+	f' <- relPathCwdToFile f
+	return $ if repoPath repo `dirContains` f'
+ 		-- Prefixing the file with ./ makes this work even when in a
+		-- subdirectory of a repo. Eg, ./foo in directory bar refers
+		-- to bar/foo, not to foo in the top of the repository.
+		then Just $ Ref $ ":./" <> toInternalGitPath f'
+		else Nothing
+
+{- A Ref that can be used to refer to a file in a particular branch. -}
+branchFileRef :: Branch -> RawFilePath -> Ref
+branchFileRef branch f = Ref $ fromRef' branch <> ":" <> toInternalGitPath f
+
+{- Converts a Ref to refer to the content of the Ref on a given date. -}
+dateRef :: Ref -> RefDate -> Ref
+dateRef r (RefDate d) = Ref $ fromRef' r <> "@" <> encodeBS d
+
+{- A Ref that can be used to refer to a file in the repository as it
+ - appears in a given Ref. 
+ -
+ - If the file path is located outside the repository, returns Nothing.
+ -}
+fileFromRef :: Ref -> RawFilePath -> Repo -> IO (Maybe Ref)
+fileFromRef r f repo = fileRef f repo >>= return . \case
+	Just (Ref fr) -> Just (Ref (fromRef' r <> fr))
+	Nothing -> Nothing
+
+{- Checks if a ref exists. Note that it must be fully qualified,
+ - eg refs/heads/master rather than master. -}
+exists :: Ref -> Repo -> IO Bool
+exists ref = runBool
+	[ Param "show-ref"
+	, Param "--verify"
+	, Param "-q"
+	, Param $ fromRef ref
+	]
+
+{- The file used to record a ref. (Git also stores some refs in a
+ - packed-refs file.) -}
+file :: Ref -> Repo -> FilePath
+file ref repo = fromRawFilePath (localGitDir repo) </> fromRef ref
+
+{- Checks if HEAD exists. It generally will, except for in a repository
+ - that was just created. -}
+headExists :: Repo -> IO Bool
+headExists repo = do
+	ls <- S.split nl <$> pipeReadStrict [Param "show-ref", Param "--head"] repo
+	return $ any (" HEAD" `S.isSuffixOf`) ls
+  where
+	nl = fromIntegral (ord '\n')
+
+{- Get the sha of a fully qualified git ref, if it exists. -}
+sha :: Branch -> Repo -> IO (Maybe Sha)
+sha branch repo = process <$> showref repo
+  where
+	showref = pipeReadStrict
+		[ Param "show-ref"
+		, Param "--hash" -- get the hash
+		, Param $ fromRef branch
+		]
+	process s
+		| S.null s = Nothing
+		| otherwise = Just $ Ref $ firstLine' s
+
+headSha :: Repo -> IO (Maybe Sha)
+headSha = sha headRef
+
+{- List of (shas, branches) matching a given ref or refs. -}
+matching :: [Ref] -> Repo -> IO [(Sha, Branch)]
+matching = matching' []
+
+{- Includes HEAD in the output, if asked for it. -}
+matchingWithHEAD :: [Ref] -> Repo -> IO [(Sha, Branch)]
+matchingWithHEAD = matching' [Param "--head"]
+
+matching' :: [CommandParam] -> [Ref] -> Repo -> IO [(Sha, Branch)]
+matching' ps rs repo = map gen . S8.lines <$> 
+	pipeReadStrict (Param "show-ref" : ps ++ rps) repo
+  where
+	gen l = let (r, b) = separate' (== fromIntegral (ord ' ')) l
+		in (Ref r, Ref b)
+	rps = map (Param . fromRef) rs
+
+{- List of (shas, branches) matching a given ref.
+ - Duplicate shas are filtered out. -}
+matchingUniq :: [Ref] -> Repo -> IO [(Sha, Branch)]
+matchingUniq refs repo = nubBy uniqref <$> matching refs repo
+  where
+	uniqref (a, _) (b, _) = a == b
+
+{- List of all refs. -}
+list :: Repo -> IO [(Sha, Ref)]
+list = matching' [] []
+
+{- Deletes a ref. This can delete refs that are not branches, 
+ - which git branch --delete refuses to delete. -}
+delete :: Sha -> Ref -> Repo -> IO ()
+delete oldvalue ref = run
+	[ Param "update-ref"
+	, Param "-d"
+	, Param $ fromRef ref
+	, Param $ fromRef oldvalue
+	]
+
+{- Gets the sha of the tree a ref uses. 
+ -
+ - The ref may be something like a branch name, and it could contain
+ - ":subdir" if a subtree is wanted. -}
+tree :: Ref -> Repo -> IO (Maybe Sha)
+tree (Ref ref) = extractSha <$$> pipeReadStrict
+	[ Param "rev-parse"
+	, Param "--verify"
+	, Param "--quiet"
+	, Param (decodeBS ref')
+	]
+  where
+	ref' = if ":" `S.isInfixOf` ref
+		then ref
+		-- de-reference commit objects to the tree
+		else ref <> ":"
+
+{- Checks if a String is a legal git ref name.
+ -
+ - The rules for this are complex; see git-check-ref-format(1) -}
+legal :: Bool -> String -> Bool
+legal allowonelevel s = all (== False) illegal
+  where
+	illegal =
+		[ any ("." `isPrefixOf`) pathbits
+		, any (".lock" `isSuffixOf`) pathbits
+		, not allowonelevel && length pathbits < 2
+		, contains ".."
+		, any (\c -> contains [c]) illegalchars
+		, begins "/"
+		, ends "/"
+		, contains "//"
+		, ends "."
+		, contains "@{"
+		, null s
+		]
+	contains v = v `isInfixOf` s
+	ends v = v `isSuffixOf` s
+	begins v = v `isPrefixOf` s
+
+	pathbits = splitc '/' s
+	illegalchars = " ~^:?*[\\" ++ controlchars
+	controlchars = chr 0o177 : [chr 0 .. chr (0o40-1)]
diff --git a/Git/RefLog.hs b/Git/RefLog.hs
new file mode 100644
index 0000000000..b98833c391
--- /dev/null
+++ b/Git/RefLog.hs
@@ -0,0 +1,33 @@
+{- git reflog interface
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.RefLog where
+
+import Common
+import Git
+import Git.Command
+import Git.Sha
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as S8
+
+{- Gets the reflog for a given branch. -}
+get :: Branch -> Repo -> IO [Sha]
+get b = getMulti [b]
+
+{- Gets reflogs for multiple branches. -}
+getMulti :: [Branch] -> Repo -> IO [Sha]
+getMulti bs = get' (map (Param . fromRef) bs)
+
+get' :: [CommandParam] -> Repo -> IO [Sha]
+get' ps = mapMaybe (extractSha . S.copy) . S8.lines <$$> pipeReadStrict ps'
+  where
+	ps' = catMaybes
+		[ Just $ Param "log"
+		, Just $ Param "-g"
+		, Just $ Param "--format=%H"
+		] ++ ps
diff --git a/Git/Remote.hs b/Git/Remote.hs
new file mode 100644
index 0000000000..9cdaad61ca
--- /dev/null
+++ b/Git/Remote.hs
@@ -0,0 +1,138 @@
+{- git remote stuff
+ -
+ - Copyright 2012-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.Remote where
+
+import Common
+import Git
+import Git.Types
+
+import Data.Char
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as S8
+import Network.URI
+#ifdef mingw32_HOST_OS
+import Git.FilePath
+#endif
+
+{- Is a git config key one that specifies the url of a remote? -}
+isRemoteUrlKey :: ConfigKey -> Bool
+isRemoteUrlKey = isRemoteKey "url"
+
+isRemoteKey :: S.ByteString -> ConfigKey -> Bool
+isRemoteKey want (ConfigKey k) =
+	"remote." `S.isPrefixOf` k && ("." <> want) `S.isSuffixOf` k
+
+{- Get a remote's name from the a config key such as remote.name.url
+ - or any other per-remote config key. -}
+remoteKeyToRemoteName :: ConfigKey -> Maybe RemoteName
+remoteKeyToRemoteName (ConfigKey k)
+	| "remote." `S.isPrefixOf` k = 
+		let n = S.intercalate "." $ dropFromEnd 1 $ drop 1 $ S8.split '.' k
+		in if S.null n then Nothing else Just (decodeBS n)
+	| otherwise = Nothing
+
+{- Construct a legal git remote name out of an arbitrary input string.
+ -
+ - There seems to be no formal definition of this in the git source,
+ - just some ad-hoc checks, and some other things that fail with certain
+ - types of names (like ones starting with '-').
+ -}
+makeLegalName :: String -> RemoteName
+makeLegalName s = case filter legal $ replace "/" "_" s of
+	-- it can't be empty
+	[] -> "unnamed"
+	-- it can't start with / or - or .
+	'.':s' -> makeLegalName s'
+	'/':s' -> makeLegalName s'
+	'-':s' -> makeLegalName s'
+	s' -> s'
+  where
+	{- Only alphanumerics, and a few common bits of punctuation common
+	 - in hostnames. -}
+	legal '_' = True
+	legal '.' = True
+	legal c = isAlphaNum c
+	
+data RemoteLocation = RemoteUrl String | RemotePath FilePath
+	deriving (Eq, Show)
+
+remoteLocationIsUrl :: RemoteLocation -> Bool
+remoteLocationIsUrl (RemoteUrl _) = True
+remoteLocationIsUrl _ = False
+
+remoteLocationIsSshUrl :: RemoteLocation -> Bool
+remoteLocationIsSshUrl (RemoteUrl u) = "ssh://" `isPrefixOf` u
+remoteLocationIsSshUrl _ = False
+
+{- Determines if a given remote location is an url, or a local
+ - path. Takes the repository's insteadOf configuration into account. -}
+parseRemoteLocation :: String -> Bool -> Repo -> RemoteLocation
+parseRemoteLocation s knownurl repo = go
+  where
+ 	s' = calcloc s
+	go
+#ifdef mingw32_HOST_OS
+		| dosstyle s' = RemotePath (dospath s')
+#endif
+		| scpstyle s' = RemoteUrl (scptourl s')
+		| urlstyle s' = RemoteUrl s'
+		| knownurl && s' == s = RemoteUrl s'
+		| otherwise = RemotePath s'
+	-- insteadof config can rewrite remote location
+	calcloc l
+		| null insteadofs = l
+		| otherwise = replacement ++ drop (S.length bestvalue) l
+	  where
+		replacement = decodeBS $ S.drop (S.length prefix) $
+			S.take (S.length bestkey - S.length suffix) bestkey
+		(bestkey, bestvalue) = 
+			case maximumBy longestvalue insteadofs of
+				(ConfigKey k, ConfigValue v) -> (k, v)
+				(ConfigKey k, NoConfigValue) -> (k, mempty)
+		longestvalue (_, a) (_, b) = compare b a
+		insteadofs = filterconfig $ \case
+			(ConfigKey k, ConfigValue v) -> 
+				prefix `S.isPrefixOf` k &&
+				suffix `S.isSuffixOf` k &&
+				v `S.isPrefixOf` encodeBS l
+			(_, NoConfigValue) -> False
+		filterconfig f = filter f $
+			concatMap splitconfigs $ M.toList $ fullconfig repo
+		splitconfigs (k, vs) = map (\v -> (k, v)) vs
+		(prefix, suffix) = ("url." , ".insteadof")
+	-- git supports URIs that contain unescaped characters such as
+	-- spaces. So to test if it's a (git) URI, escape those.
+	urlstyle v = isURI (escapeURIString isUnescapedInURI v)
+	-- git remotes can be written scp style -- [user@]host:dir
+	-- but foo::bar is a git-remote-helper location instead
+	scpstyle v = ":" `isInfixOf` v 
+		&& not ("//" `isInfixOf` v)
+		&& not ("::" `isInfixOf` v)
+	scptourl v = "ssh://" ++ host ++ slash dir
+	  where
+		(host, dir)
+			-- handle ipv6 address inside []
+			| "[" `isPrefixOf` v = case break (== ']') v of
+				(h, ']':':':d) -> (h ++ "]", d)
+				(h, ']':d) -> (h ++ "]", d)
+				(h, d) -> (h, d)
+			| otherwise = separate (== ':') v
+		slash d	| d == "" = "/~/" ++ d
+			| "/" `isPrefixOf` d = d
+			| "~" `isPrefixOf` d = '/':d
+			| otherwise = "/~/" ++ d
+#ifdef mingw32_HOST_OS
+	-- git on Windows will write a path to .git/config with "drive:",
+	-- which is not to be confused with a "host:"
+	dosstyle = hasDrive
+	dospath = fromRawFilePath . fromInternalGitPath . toRawFilePath
+#endif
diff --git a/Git/Remote/Remove.hs b/Git/Remote/Remove.hs
new file mode 100644
index 0000000000..147e59999f
--- /dev/null
+++ b/Git/Remote/Remove.hs
@@ -0,0 +1,22 @@
+{- git remote removal
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Git.Remote.Remove where
+
+import Common
+import Git
+import Git.Types
+import qualified Git.Command
+
+remove :: RemoteName -> Repo -> IO ()
+remove remotename = Git.Command.run
+	[ Param "remote"
+	, Param "remove"
+	, Param remotename
+	]
diff --git a/Git/Repair.hs b/Git/Repair.hs
new file mode 100644
index 0000000000..ace7ae89af
--- /dev/null
+++ b/Git/Repair.hs
@@ -0,0 +1,657 @@
+{- git repository recovery
+ -
+ - Copyright 2013-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.Repair (
+	runRepair,
+	runRepairOf,
+	removeBadBranches,
+	successfulRepair,
+	cleanCorruptObjects,
+	resetLocalBranches,
+	checkIndex,
+	checkIndexFast,
+	missingIndex,
+	emptyGoodCommits,
+	isTrackingBranch,
+) where
+
+import Common
+import Git
+import Git.Command
+import Git.Objects
+import Git.Sha
+import Git.Types
+import Git.Fsck
+import Git.Index
+import Git.Env
+import Git.FilePath
+import qualified Git.Config as Config
+import qualified Git.Construct as Construct
+import qualified Git.LsTree as LsTree
+import qualified Git.LsFiles as LsFiles
+import qualified Git.Ref as Ref
+import qualified Git.RefLog as RefLog
+import qualified Git.UpdateIndex as UpdateIndex
+import qualified Git.Branch as Branch
+import Utility.Directory.Create
+import Utility.Tmp.Dir
+import Utility.Rsync
+import Utility.FileMode
+import qualified Utility.RawFilePath as R
+
+import qualified Data.Set as S
+import qualified Data.ByteString.Lazy as L
+import qualified System.FilePath.ByteString as P
+
+{- Given a set of bad objects found by git fsck, which may not
+ - be complete, finds and removes all corrupt objects. -}
+cleanCorruptObjects :: FsckResults -> Repo -> IO ()
+cleanCorruptObjects fsckresults r = do
+	void $ explodePacks r
+	mapM_ removeLoose (S.toList $ knownMissing fsckresults)
+	mapM_ removeBad =<< listLooseObjectShas r
+  where
+	removeLoose s = removeWhenExistsWith R.removeLink (looseObjectFile r s)
+	removeBad s = do
+		void $ tryIO $ allowRead $ looseObjectFile r s
+		whenM (isMissing s r) $
+			removeLoose s
+
+{- Explodes all pack files to loose objects, and deletes the pack files.
+ -
+ - git unpack-objects will not unpack objects from a pack file that are
+ - in the git repo. So, GIT_OBJECT_DIRECTORY is pointed to a temporary
+ - directory, and the loose objects then are moved into place, before
+ - deleting the pack files.
+ -
+ - Also, that prevents unpack-objects from possibly looking at corrupt
+ - pack files to see if they contain an object, while unpacking a
+ - non-corrupt pack file.
+ -}
+explodePacks :: Repo -> IO Bool
+explodePacks r = go =<< listPackFiles r
+  where
+	go [] = return False
+	go packs = withTmpDir "packs" $ \tmpdir -> do
+		r' <- addGitEnv r "GIT_OBJECT_DIRECTORY" tmpdir
+		putStrLn "Unpacking all pack files."
+		forM_ packs $ \packfile -> do
+			-- Just in case permissions are messed up.
+			allowRead (toRawFilePath packfile)
+			-- May fail, if pack file is corrupt.
+			void $ tryIO $
+				pipeWrite [Param "unpack-objects", Param "-r"] r' $ \h ->
+				L.hPut h =<< L.readFile packfile
+		objs <- emptyWhenDoesNotExist (dirContentsRecursive tmpdir)
+		forM_ objs $ \objfile -> do
+			f <- relPathDirToFile
+				(toRawFilePath tmpdir)
+				(toRawFilePath objfile)
+			let dest = objectsDir r P.</> f
+			createDirectoryIfMissing True
+				(fromRawFilePath (parentDir dest))
+			moveFile (toRawFilePath objfile) dest
+		forM_ packs $ \packfile -> do
+			let f = toRawFilePath packfile
+			removeWhenExistsWith R.removeLink f
+			removeWhenExistsWith R.removeLink (packIdxFile f)
+		return True
+
+{- Try to retrieve a set of missing objects, from the remotes of a
+ - repository. Returns any that could not be retrieved.
+ -
+ - If another clone of the repository exists locally, which might not be a
+ - remote of the repo being repaired, its path can be passed as a reference
+ - repository.
+ -}
+retrieveMissingObjects :: FsckResults -> Maybe FilePath -> Repo -> IO FsckResults
+retrieveMissingObjects missing referencerepo r
+	| not (foundBroken missing) = return missing
+	| otherwise = withTmpDir "tmprepo" $ \tmpdir -> do
+		unlessM (boolSystem "git" [Param "init", File tmpdir]) $
+			giveup $ "failed to create temp repository in " ++ tmpdir
+		tmpr <- Config.read =<< Construct.fromPath (toRawFilePath tmpdir)
+		let repoconfig r' = fromRawFilePath (localGitDir r' P.</> "config")
+		whenM (doesFileExist (repoconfig r)) $
+			L.readFile (repoconfig r) >>= L.writeFile (repoconfig tmpr)
+		rs <- Construct.fromRemotes r
+		stillmissing <- pullremotes tmpr rs fetchrefstags missing
+		if S.null (knownMissing stillmissing)
+			then return stillmissing
+			else pullremotes tmpr rs fetchallrefs stillmissing
+  where
+	pullremotes tmpr [] fetchrefs stillmissing = case referencerepo of
+		Nothing -> return stillmissing
+		Just p -> ifM (fetchfrom p fetchrefs tmpr)
+			( do
+				void $ explodePacks tmpr
+				void $ copyObjects tmpr r
+				case stillmissing of
+					FsckFailed -> return $ FsckFailed
+					FsckFoundMissing s t -> FsckFoundMissing 
+						<$> findMissing (S.toList s) r
+						<*> pure t
+			, return stillmissing
+			)
+	pullremotes tmpr (rmt:rmts) fetchrefs ms
+		| not (foundBroken ms) = return ms
+		| otherwise = case remoteName rmt of
+			Just n -> do
+				putStrLn $ "Trying to recover missing objects from remote " ++ n ++ "."
+				ifM (fetchfrom n fetchrefs tmpr)
+					( do
+						void $ explodePacks tmpr
+						void $ copyObjects tmpr r
+						case ms of
+							FsckFailed -> pullremotes tmpr rmts fetchrefs ms
+							FsckFoundMissing s t -> do
+								stillmissing <- findMissing (S.toList s) r
+								pullremotes tmpr rmts fetchrefs (FsckFoundMissing stillmissing t)
+					, pullremotes tmpr rmts fetchrefs ms
+					)
+			Nothing -> pullremotes tmpr rmts fetchrefs ms
+	fetchfrom loc ps fetchr = runBool ps' fetchr'
+	  where
+		ps' = 
+			[ Param "fetch"
+			, Param loc
+			, Param "--force"
+			, Param "--update-head-ok"
+			, Param "--quiet"
+			] ++ ps
+		fetchr' = fetchr { gitGlobalOpts = gitGlobalOpts fetchr ++ nogc }
+		nogc = [ Param "-c", Param "gc.auto=0" ]
+
+	-- fetch refs and tags
+	fetchrefstags = [ Param "+refs/heads/*:refs/heads/*", Param "--tags"]
+	-- Fetch all available refs (more likely to fail,
+	-- as the remote may have refs it refuses to send).
+	fetchallrefs = [ Param "+*:*" ]
+
+{- Copies all objects from the src repository to the dest repository.
+ - This is done using rsync, so it copies all missing objects, and all
+ - objects they rely on. -}
+copyObjects :: Repo -> Repo -> IO Bool
+copyObjects srcr destr = rsync
+	[ Param "-qr"
+	, File $ addTrailingPathSeparator $ fromRawFilePath $ objectsDir srcr
+	, File $ addTrailingPathSeparator $ fromRawFilePath $ objectsDir destr
+	]
+
+{- To deal with missing objects that cannot be recovered, resets any
+ - local branches to point to an old commit before the missing
+ - objects. Returns all branches that were changed, and deleted.
+ -}
+resetLocalBranches :: MissingObjects -> GoodCommits -> Repo -> IO ([Branch], [Branch], GoodCommits)
+resetLocalBranches missing goodcommits r =
+	go [] [] goodcommits =<< filter islocalbranch <$> getAllRefs r
+  where
+	islocalbranch b = "refs/heads/" `isPrefixOf` fromRef b
+	go changed deleted gcs [] = return (changed, deleted, gcs)
+	go changed deleted gcs (b:bs) = do
+		(mc, gcs') <- findUncorruptedCommit missing gcs b r
+		case mc of
+			Just c
+				| c == b -> go changed deleted gcs' bs
+				| otherwise -> do
+					reset b c
+					go (b:changed) deleted gcs' bs
+			Nothing -> do
+				nukeBranchRef b r
+				go changed (b:deleted) gcs' bs
+	reset b c = do
+		nukeBranchRef b	r
+		void $ runBool
+			[ Param "branch"
+			, Param (fromRef $ Ref.base b)
+			, Param (fromRef c)
+			] r
+
+isTrackingBranch :: Ref -> Bool
+isTrackingBranch b = "refs/remotes/" `isPrefixOf` fromRef b
+
+{- To deal with missing objects that cannot be recovered, removes
+ - any branches (filtered by a predicate) that reference them
+ - Returns a list of all removed branches.
+ -}
+removeBadBranches :: (Ref -> Bool) -> Repo -> IO [Branch]
+removeBadBranches removablebranch r = fst <$> removeBadBranches' removablebranch S.empty emptyGoodCommits r
+
+removeBadBranches' :: (Ref -> Bool) -> MissingObjects -> GoodCommits -> Repo -> IO ([Branch], GoodCommits)
+removeBadBranches' removablebranch missing goodcommits r =
+	go [] goodcommits =<< filter removablebranch <$> getAllRefs r
+  where
+	go removed gcs [] = return (removed, gcs)
+	go removed gcs (b:bs) = do
+		(ok, gcs') <- verifyCommit missing gcs b r
+		if ok
+			then go removed gcs' bs
+			else do
+				nukeBranchRef b r
+				go (b:removed) gcs' bs
+
+badBranches :: MissingObjects -> Repo -> IO [Branch]
+badBranches missing r = filterM isbad =<< getAllRefs r
+  where
+	isbad b = not . fst <$> verifyCommit missing emptyGoodCommits b r
+
+{- Gets all refs, including ones that are corrupt.
+ - git show-ref does not output refs to commits that are directly
+ - corrupted, so it is not used.
+ -
+ - Relies on packed refs being exploded before it's called.
+ -}
+getAllRefs :: Repo -> IO [Ref]
+getAllRefs r = getAllRefs' (fromRawFilePath (localGitDir r) </> "refs")
+
+getAllRefs' :: FilePath -> IO [Ref]
+getAllRefs' refdir = do
+	let topsegs = length (splitPath refdir) - 1
+	let toref = Ref . toInternalGitPath . encodeBS 
+		. joinPath . drop topsegs . splitPath
+	map toref <$> emptyWhenDoesNotExist (dirContentsRecursive refdir)
+
+explodePackedRefsFile :: Repo -> IO ()
+explodePackedRefsFile r = do
+	let f = packedRefsFile r
+	let f' = toRawFilePath f
+	whenM (doesFileExist f) $ do
+		rs <- mapMaybe parsePacked . lines
+			<$> catchDefaultIO "" (safeReadFile f')
+		forM_ rs makeref
+		removeWhenExistsWith R.removeLink f'
+  where
+	makeref (sha, ref) = do
+		let gitd = localGitDir r
+		let dest = gitd P.</> fromRef' ref
+		let dest' = fromRawFilePath dest
+		createDirectoryUnder [gitd] (parentDir dest)
+		unlessM (doesFileExist dest') $
+			writeFile dest' (fromRef sha)
+
+packedRefsFile :: Repo -> FilePath
+packedRefsFile r = fromRawFilePath (localGitDir r) </> "packed-refs"
+
+parsePacked :: String -> Maybe (Sha, Ref)
+parsePacked l = case words l of
+	(sha:ref:[])
+		| isJust (extractSha (encodeBS sha)) && Ref.legal True ref ->
+			Just (Ref (encodeBS sha), Ref (encodeBS ref))
+	_ -> Nothing
+
+{- git-branch -d cannot be used to remove a branch that is directly
+ - pointing to a corrupt commit. -}
+nukeBranchRef :: Branch -> Repo -> IO ()
+nukeBranchRef b r = removeWhenExistsWith R.removeLink $ localGitDir r P.</> fromRef' b
+
+{- Finds the most recent commit to a branch that does not need any
+ - of the missing objects. If the input branch is good as-is, returns it.
+ - Otherwise, tries to traverse the commits in the branch to find one
+ - that is ok. That might fail, if one of them is corrupt, or if an object
+ - at the root of the branch is missing. Finally, looks for an old version
+ - of the branch from the reflog.
+ -}
+findUncorruptedCommit :: MissingObjects -> GoodCommits -> Branch -> Repo -> IO (Maybe Sha, GoodCommits)
+findUncorruptedCommit missing goodcommits branch r = do
+	(ok, goodcommits') <- verifyCommit missing goodcommits branch r
+	if ok
+		then return (Just branch, goodcommits')
+		else do
+			(ls, cleanup) <- pipeNullSplit'
+				[ Param "log"
+				, Param "-z"
+				, Param "--format=%H"
+				, Param (fromRef branch)
+				] r
+			let branchshas = catMaybes $ map extractSha ls
+			reflogshas <- RefLog.get branch r
+			-- XXX Could try a bit harder here, and look
+			-- for uncorrupted old commits in branches in the
+			-- reflog.
+			cleanup `after` findfirst goodcommits (branchshas ++ reflogshas)
+  where
+	findfirst gcs [] = return (Nothing, gcs)
+	findfirst gcs (c:cs) = do
+		(ok, gcs') <- verifyCommit missing gcs c r
+		if ok
+			then return (Just c, gcs')
+			else findfirst gcs' cs
+
+{- Verifies that none of the missing objects in the set are used by
+ - the commit. Also adds to a set of commit shas that have been verified to
+ - be good, which can be passed into subsequent calls to avoid
+ - redundant work when eg, chasing down branches to find the first
+ - uncorrupted commit.
+ -
+ - When the sha is not a commit but some other git object, returns
+ - true, but does not add it to the set.
+ -}
+verifyCommit :: MissingObjects -> GoodCommits -> Sha -> Repo -> IO (Bool, GoodCommits)
+verifyCommit missing goodcommits commit r
+	| checkGoodCommit commit goodcommits = return (True, goodcommits)
+	| otherwise = do
+		(ls, cleanup) <- pipeNullSplit
+			[ Param "log"
+			, Param "-z"
+			, Param "--format=%H %T"
+			, Param (fromRef commit)
+			] r
+		let committrees = map (parse . decodeBL) ls
+		-- git log on an object that is not a commit will
+		-- succeed without any output
+		if null committrees
+			then ifM cleanup
+				( return (True, goodcommits)
+				, return (False, goodcommits)
+				)
+			else if any isNothing committrees
+				then do
+					void cleanup
+					return (False, goodcommits)
+				else do
+					let cts = catMaybes committrees
+					ifM (cleanup <&&> check cts)
+						( return (True, addGoodCommits (map fst cts) goodcommits)
+						, return (False, goodcommits)
+						)
+  where
+	parse l = case words l of
+		(commitsha:treesha:[]) -> (,)
+			<$> extractSha (encodeBS commitsha)
+			<*> extractSha (encodeBS treesha)
+		_ -> Nothing
+	check [] = return True
+	check ((c, t):rest)
+		| checkGoodCommit c goodcommits = return True
+		| otherwise = verifyTree missing t r <&&> check rest
+
+{- Verifies that a tree is good, including all trees and blobs
+ - referenced by it. -}
+verifyTree :: MissingObjects -> Sha -> Repo -> IO Bool
+verifyTree missing treesha r
+	| S.member treesha missing = return False
+	| otherwise = do
+		let nolong = LsTree.LsTreeLong False
+		(ls, cleanup) <- pipeNullSplit (LsTree.lsTreeParams LsTree.LsTreeRecursive nolong treesha []) r
+		let objshas = mapMaybe (LsTree.sha <$$> eitherToMaybe . LsTree.parseLsTree nolong) ls
+		if any (`S.member` missing) objshas
+			then do
+				void cleanup
+				return False
+			-- as long as ls-tree succeeded, we're good
+			else cleanup
+
+{- Checks that the index file only refers to objects that are not missing,
+ - and is not itself corrupt. Note that a missing index file is not
+ - considered a problem (repo may be new). -}
+checkIndex :: Repo -> IO Bool
+checkIndex r = do
+	(bad, _good, cleanup) <- partitionIndex r
+	if null bad
+		then cleanup
+		else do
+			void cleanup
+			return False
+
+{- Does not check every object the index refers to, but only that the index
+ - itself is not corrupt. -}
+checkIndexFast :: Repo -> IO Bool
+checkIndexFast r = do
+	(indexcontents, cleanup) <- LsFiles.stagedDetails [repoPath r] r
+	length indexcontents `seq` cleanup
+
+missingIndex :: Repo -> IO Bool
+missingIndex r = not <$> doesFileExist (fromRawFilePath (localGitDir r) </> "index")
+
+{- Finds missing and ok files staged in the index. -}
+partitionIndex :: Repo -> IO ([LsFiles.StagedDetails], [LsFiles.StagedDetails], IO Bool)
+partitionIndex r = do
+	(indexcontents, cleanup) <- LsFiles.stagedDetails [repoPath r] r
+	l <- forM indexcontents $ \i@(_file, sha, _mode, _stagenum) -> 
+		(,) <$> isMissing sha r <*> pure i
+	let (bad, good) = partition fst l
+	return (map snd bad, map snd good, cleanup)
+
+{- Rewrites the index file, removing from it any files whose blobs are
+ - missing. Returns the list of affected files. -}
+rewriteIndex :: Repo -> IO [FilePath]
+rewriteIndex r
+	| repoIsLocalBare r = return []
+	| otherwise = do
+		(bad, good, cleanup) <- partitionIndex r
+		unless (null bad) $ do
+			removeWhenExistsWith R.removeLink (indexFile r)
+			UpdateIndex.streamUpdateIndex r
+				=<< (catMaybes <$> mapM reinject good)
+		void cleanup
+		return $ map (\(file,_, _, _) -> fromRawFilePath file) bad
+  where
+	reinject (file, sha, mode, _) = case toTreeItemType mode of
+		Nothing -> return Nothing
+		Just treeitemtype -> Just <$>
+			UpdateIndex.stageFile sha treeitemtype file r
+
+newtype GoodCommits = GoodCommits (S.Set Sha)
+
+emptyGoodCommits :: GoodCommits
+emptyGoodCommits = GoodCommits S.empty
+
+checkGoodCommit :: Sha -> GoodCommits -> Bool
+checkGoodCommit sha (GoodCommits s) = S.member sha s
+
+addGoodCommits :: [Sha] -> GoodCommits -> GoodCommits
+addGoodCommits shas (GoodCommits s) = GoodCommits $
+	S.union s (S.fromList shas)
+
+displayList :: [String] -> String -> IO ()
+displayList items header
+	| null items = return ()
+	| otherwise = do
+		putStrLn header
+		putStr $ unlines $ map (\i -> "\t" ++ i) truncateditems
+  where
+	numitems = length items
+	truncateditems
+		| numitems > 10 = take 10 items ++ ["(and " ++ show (numitems - 10) ++ " more)"]
+		| otherwise = items
+
+{- Fix problems that would prevent repair from working at all
+ -
+ - A missing or corrupt .git/HEAD makes git not treat the repository as a
+ - git repo. If there is a git repo in a parent directory, it may move up
+ - the tree and use that one instead. So, cannot use `git show-ref HEAD` to
+ - test it.
+ -
+ - Explode the packed refs file, to simplify dealing with refs, and because
+ - fsck can complain about bad refs in it.
+ -}
+preRepair :: Repo -> IO ()
+preRepair g = do
+	unlessM (validhead <$> catchDefaultIO "" (safeReadFile headfile)) $ do
+		removeWhenExistsWith R.removeLink headfile
+		writeFile (fromRawFilePath headfile) "ref: refs/heads/master"
+	explodePackedRefsFile g
+	unless (repoIsLocalBare g) $
+		void $ tryIO $ allowWrite $ indexFile g
+  where
+	headfile = localGitDir g P.</> "HEAD"
+	validhead s = "ref: refs/" `isPrefixOf` s
+		|| isJust (extractSha (encodeBS s))
+
+{- Put it all together. -}
+runRepair :: (Ref -> Bool) -> Bool -> Repo -> IO (Bool, [Branch])
+runRepair removablebranch forced g = do
+	preRepair g
+	putStrLn "Running git fsck ..."
+	fsckresult <- findBroken False False g
+	if foundBroken fsckresult
+		then do
+			putStrLn "Fsck found problems, attempting repair."
+			runRepair' removablebranch fsckresult forced Nothing g
+		else do
+			putStrLn "Fsck found no problems. Checking for broken branches."
+			bad <- badBranches S.empty g
+			if null bad
+				then do
+					putStrLn "No problems found."
+					return (True, [])
+				else do
+					putStrLn "Found problems, attempting repair."
+					runRepair' removablebranch fsckresult forced Nothing g
+
+runRepairOf :: FsckResults -> (Ref -> Bool) -> Bool -> Maybe FilePath -> Repo -> IO (Bool, [Branch])
+runRepairOf fsckresult removablebranch forced referencerepo g = do
+	preRepair g
+	runRepair' removablebranch fsckresult forced referencerepo g
+
+runRepair' :: (Ref -> Bool) -> FsckResults -> Bool -> Maybe FilePath -> Repo -> IO (Bool, [Branch])
+runRepair' removablebranch fsckresult forced referencerepo g = do
+	cleanCorruptObjects fsckresult g
+	missing <- findBroken False False g
+	stillmissing <- retrieveMissingObjects missing referencerepo g
+	case stillmissing of
+		FsckFoundMissing s t
+			| S.null s -> if repoIsLocalBare g
+				then checkbadbranches s
+				else ifM (checkIndex g)
+					( checkbadbranches s
+					, do
+						putStrLn "No missing objects found, but the index file is corrupt!"
+						if forced
+							then corruptedindex
+							else needforce
+					)
+			| otherwise -> if forced
+				then ifM (checkIndex g)
+					( forcerepair s t
+					, corruptedindex
+					)
+				else do
+					putStrLn $ unwords
+						[ show (S.size s)
+						, "missing objects could not be recovered!"
+						]
+					unsuccessfulfinish
+		FsckFailed
+			| forced -> ifM (pure (repoIsLocalBare g) <||> checkIndex g)
+				( do
+					cleanCorruptObjects FsckFailed g
+					stillmissing' <- findBroken False False g
+					case stillmissing' of
+						FsckFailed -> return (False, [])
+						FsckFoundMissing s t -> forcerepair s t
+				, corruptedindex
+				)
+			| otherwise -> unsuccessfulfinish
+  where
+	repairbranches missing = do
+		(removedbranches, goodcommits) <- removeBadBranches' removablebranch missing emptyGoodCommits g
+		let remotebranches = filter isTrackingBranch removedbranches
+		unless (null remotebranches) $
+			putStrLn $ unwords
+				[ "Removed"
+				, show (length remotebranches)
+				, "remote tracking branches that referred to missing objects."
+				]
+		(resetbranches, deletedbranches, _) <- resetLocalBranches missing goodcommits g
+		displayList (map fromRef resetbranches)
+			"Reset these local branches to old versions before the missing objects were committed:"
+		displayList (map fromRef deletedbranches)
+			"Deleted these local branches, which could not be recovered due to missing objects:"
+		return (resetbranches ++ deletedbranches)
+
+	checkbadbranches missing = do
+		bad <- badBranches missing g
+		case (null bad, forced) of
+			(True, _) -> successfulfinish []
+			(False, False) -> do
+				displayList (map fromRef bad)
+					"Some git branches refer to missing objects:"
+				unsuccessfulfinish
+			(False, True) -> successfulfinish =<< repairbranches missing
+
+	forcerepair missing fscktruncated = do
+		modifiedbranches <- repairbranches missing
+		deindexedfiles <- rewriteIndex g
+		displayList deindexedfiles
+			"Removed these missing files from the index. You should look at what files are present in your working tree and git add them back to the index when appropriate."
+
+		-- When the fsck results were truncated, try
+		-- fscking again, and as long as different
+		-- missing objects are found, continue
+		-- the repair process.
+		if fscktruncated
+			then do
+				fsckresult' <- findBroken False False g
+				case fsckresult' of
+					FsckFailed -> do
+						putStrLn "git fsck is failing"
+						return (False, modifiedbranches)
+					FsckFoundMissing s _
+						| S.null s -> successfulfinish modifiedbranches
+						| S.null (s `S.difference` missing) -> do
+							putStrLn $ unwords
+								[ show (S.size s)
+								, "missing objects could not be recovered!"
+								]
+							return (False, modifiedbranches)	
+						| otherwise -> do
+							(ok, modifiedbranches') <- runRepairOf fsckresult' removablebranch forced referencerepo g
+							return (ok, modifiedbranches++modifiedbranches')
+			else successfulfinish modifiedbranches
+
+	corruptedindex = do
+		removeWhenExistsWith R.removeLink (indexFile g)
+		-- The corrupted index can prevent fsck from finding other
+		-- problems, so re-run repair.
+		fsckresult' <- findBroken False False g
+		result <- runRepairOf fsckresult' removablebranch forced referencerepo g
+		putStrLn "Removed the corrupted index file. You should look at what files are present in your working tree and git add them back to the index when appropriate."
+		return result
+
+	successfulfinish modifiedbranches
+		| null modifiedbranches = do
+			mapM_ putStrLn
+				[ "Successfully recovered repository!"
+				, "You should run \"git fsck\" to make sure, but it looks like everything was recovered ok."
+				]
+			return (True, modifiedbranches)
+		| otherwise = do
+			unless (repoIsLocalBare g) $ do
+				mcurr <- Branch.currentUnsafe g
+				case mcurr of
+					Nothing -> return ()
+					Just curr -> when (any (== curr) modifiedbranches) $ do
+						putStrLn $ unwords
+							[ "You currently have"
+							, fromRef curr
+							, "checked out. You may have staged changes in the index that can be committed to recover the lost state of this branch!"
+							]
+			putStrLn "Successfully recovered repository!"
+			putStrLn "Please carefully check that the changes mentioned above are ok.."
+			return (True, modifiedbranches)
+	
+	unsuccessfulfinish = do
+		if repoIsLocalBare g
+			then do
+				putStrLn "If you have a clone of this bare repository, you should add it as a remote of this repository, and retry."
+				putStrLn "If there are no clones of this repository, you can instead retry with the --force parameter to force recovery to a possibly usable state."
+				return (False, [])
+			else needforce
+	needforce = do
+		putStrLn "To force a recovery to a usable state, retry with the --force parameter."
+		return (False, [])
+
+successfulRepair :: (Bool, [Branch]) -> Bool
+successfulRepair = fst
+
+safeReadFile :: RawFilePath -> IO String
+safeReadFile f = do
+	allowRead f
+	readFileStrict (fromRawFilePath f)
diff --git a/Git/Sha.hs b/Git/Sha.hs
new file mode 100644
index 0000000000..389bcc01a3
--- /dev/null
+++ b/Git/Sha.hs
@@ -0,0 +1,74 @@
+{- git SHA stuff
+ -
+ - Copyright 2011,2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.Sha where
+
+import Common
+import Git.Types
+
+import qualified Data.ByteString as S
+import Data.Char
+
+{- Runs an action that causes a git subcommand to emit a Sha, and strips
+ - any trailing newline, returning the sha. -}
+getSha :: String -> IO S.ByteString -> IO Sha
+getSha subcommand a = maybe bad return =<< extractSha <$> a
+  where
+	bad = giveup $ "failed to read sha from git " ++ subcommand
+
+{- Extracts the Sha from a ByteString. 
+ -
+ - There can be a trailing newline after it, but nothing else.
+ -}
+extractSha :: S.ByteString -> Maybe Sha
+extractSha s
+	| len `elem` shaSizes = val s
+	| len - 1 `elem` shaSizes && S.length s' == len - 1 = val s'
+	| otherwise = Nothing
+  where
+	len = S.length s
+	s' = firstLine' s
+	val v
+		| S.all validinsha v = Just $ Ref v
+		| otherwise = Nothing
+	validinsha w = or
+		[ w >= 48 && w <= 57 -- 0-9
+		, w >= 97 && w <= 102 -- a-f
+		, w >= 65 && w <= 70 -- A-F
+		]
+
+{- Sizes of git shas. -}
+shaSizes :: [Int]
+shaSizes = 
+	[ 40 -- sha1 (must come first)
+	, 64 -- sha256
+	]
+
+{- Git plumbing often uses a all 0 sha to represent things like a
+ - deleted file. -}
+nullShas :: [Sha]
+nullShas = map (\n -> Ref (S.replicate n zero)) shaSizes
+  where
+	zero = fromIntegral (ord '0')
+
+{- Sha to provide to git plumbing when deleting a file.
+ -
+ - It's ok to provide a sha1; git versions that use sha256 will map the
+ - sha1 to the sha256, or probably just treat all null sha1 specially
+ - the same as all null sha256. -}
+deleteSha :: Sha
+deleteSha = Prelude.head nullShas
+
+{- Git's magic empty tree.
+ -
+ - It's ok to provide the sha1 of this to git to refer to an empty tree;
+ - git versions that use sha256 will map the sha1 to the sha256.
+ -}
+emptyTree :: Ref
+emptyTree = Ref "4b825dc642cb6eb9a060e54bf8d69288fbee4904"
diff --git a/Git/Ssh.hs b/Git/Ssh.hs
new file mode 100644
index 0000000000..863d847367
--- /dev/null
+++ b/Git/Ssh.hs
@@ -0,0 +1,72 @@
+{- GIT_SSH and GIT_SSH_COMMAND support
+ -
+ - Copyright 2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.Ssh (module Git.Ssh, module Utility.SshHost) where
+
+import Common
+import Utility.Env
+import Utility.SshHost
+
+import Data.Char
+
+gitSshEnv :: String
+gitSshEnv = "GIT_SSH"
+
+gitSshCommandEnv :: String
+gitSshCommandEnv = "GIT_SSH_COMMAND"
+
+gitSshEnvSet :: IO Bool
+gitSshEnvSet = anyM (isJust <$$> getEnv) [gitSshEnv, gitSshCommandEnv]
+
+type SshPort = Integer
+
+-- Command to run on the remote host. It is run by the shell
+-- there, so any necessary shell escaping of parameters in it should
+-- already be done.
+type SshCommand = String
+
+-- | Checks for GIT_SSH and GIT_SSH_COMMAND and if set, returns
+-- a command and parameters to run to ssh.
+gitSsh :: SshHost -> Maybe SshPort -> SshCommand -> IO (Maybe (FilePath, [CommandParam]))
+gitSsh host mp cmd = gitSsh' host mp cmd []
+
+gitSsh' :: SshHost -> Maybe SshPort -> SshCommand -> [CommandParam] -> IO (Maybe (FilePath, [CommandParam]))
+gitSsh' host mp cmd extrasshparams = do
+	gsc <- getEnv gitSshCommandEnv
+	case gsc of
+		Just c
+			-- git only runs the command with the shell
+			-- when it contains spaces; otherwise it's
+			-- treated the same as GIT_SSH
+			| any isSpace c -> ret "sh"
+				[ Param "-c"
+				, Param (shellcmd c sshps)
+				]
+			| otherwise -> ret c sshps
+		Nothing -> do
+			gs <- getEnv gitSshEnv
+			case gs of
+				Just c -> ret c sshps
+				Nothing -> return Nothing
+ where
+	ret c l = return $ Just (c, l)
+
+	-- Git passes exactly these parameters to the ssh command.
+	gitps = map Param $ case mp of
+		Nothing -> [fromSshHost host, cmd]
+		Just p -> [fromSshHost host, "-p", show p, cmd]
+
+	-- Passing any extra parameters to the ssh command may
+	-- break some commands.
+	sshps = extrasshparams ++ gitps
+
+	-- The shell command to run with sh -c is constructed
+	-- this way, rather than using "$@" because there could be some
+	-- unwanted parameters passed to the command, and this way they
+	-- are ignored. For example, when Utility.Rsync.rsyncShell is 
+	-- used, rsync adds some parameters after the command.
+	shellcmd c ps = c ++ " " ++ unwords (map shellEscape (toCommand ps))
diff --git a/Git/Status.hs b/Git/Status.hs
new file mode 100644
index 0000000000..8e50a69fc4
--- /dev/null
+++ b/Git/Status.hs
@@ -0,0 +1,79 @@
+{- git status interface
+ -
+ - Copyright 2015-2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.Status where
+
+import Common
+import Git
+import Git.Command
+import Git.FilePath
+
+data Status
+	= Modified TopFilePath
+	| Deleted TopFilePath
+	| Added TopFilePath
+	| Renamed TopFilePath TopFilePath
+	| TypeChanged TopFilePath
+	| Untracked TopFilePath
+
+data StagedUnstaged a = StagedUnstaged
+	{ staged :: Maybe a
+	, unstaged :: Maybe a
+	}
+
+statusChar :: Status -> Char
+statusChar (Modified _) = 'M'
+statusChar (Deleted _) = 'D'
+statusChar (Added _) = 'A'
+statusChar (Renamed _ _) = 'R'
+statusChar (TypeChanged _) = 'T'
+statusChar (Untracked _) = '?'
+
+statusFile :: Status -> TopFilePath
+statusFile (Modified f) = f
+statusFile (Deleted f) = f
+statusFile (Added f) = f
+statusFile (Renamed _oldf newf) = newf
+statusFile (TypeChanged f) = f
+statusFile (Untracked f) = f
+
+parseStatusZ :: [String] -> [StagedUnstaged Status]
+parseStatusZ = go []
+  where
+	go c [] = reverse c
+	go c (x:xs) = case x of
+		(sstaged:sunstaged:' ':f) -> 
+			case (cparse sstaged f xs, cparse sunstaged f xs) of
+				((vstaged, xs1), (vunstaged, xs2)) ->
+					let v = StagedUnstaged
+						{ staged = vstaged
+						, unstaged = vunstaged
+						}
+					    xs' = fromMaybe xs (xs1 <|> xs2)
+					in go (v : c) xs'
+		_ -> go c xs
+
+	cparse 'M' f _ = (Just (Modified (asTopFilePath (toRawFilePath f))), Nothing)
+	cparse 'A' f _ = (Just (Added (asTopFilePath (toRawFilePath f))), Nothing)
+	cparse 'D' f _ = (Just (Deleted (asTopFilePath (toRawFilePath f))), Nothing)
+	cparse 'T' f _ = (Just (TypeChanged (asTopFilePath (toRawFilePath f))), Nothing)
+	cparse '?' f _ = (Just (Untracked (asTopFilePath (toRawFilePath f))), Nothing)
+	cparse 'R' f (oldf:xs) =
+		(Just (Renamed (asTopFilePath (toRawFilePath oldf)) (asTopFilePath (toRawFilePath f))), Just xs)
+	cparse _ _ _ = (Nothing, Nothing)
+
+getStatus :: [CommandParam] -> [FilePath] -> Repo -> IO ([StagedUnstaged Status], IO Bool)
+getStatus ps fs r = do
+	(ls, cleanup) <- pipeNullSplit ps' r
+	return (parseStatusZ (map decodeBL ls), cleanup)
+  where
+	ps' = concat
+		[ [Param "status"]
+		, ps
+		, [ Param "-uall" , Param "-z"]
+		, map File fs
+		]
diff --git a/Git/Tree.hs b/Git/Tree.hs
new file mode 100644
index 0000000000..af2a132aa4
--- /dev/null
+++ b/Git/Tree.hs
@@ -0,0 +1,465 @@
+{- git trees
+ -
+ - Copyright 2016-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns, TypeSynonymInstances, FlexibleInstances #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Git.Tree (
+	Tree(..),
+	TreeContent(..),
+	getTree,
+	recordTree,
+	recordTree',
+	recordSubTree,
+	TreeItem(..),
+	treeItemsToTree,
+	treeItemToLsTreeItem,
+	lsTreeItemToTreeItem,
+	adjustTree,
+	graftTree,
+	graftTree',
+	withMkTreeHandle,
+	MkTreeHandle,
+	sendMkTree,
+	finishMkTree,
+	treeMode,
+) where
+
+import Common
+import Git
+import Git.FilePath
+import Git.Types
+import Git.Command
+import Git.Sha
+import qualified Git.LsTree as LsTree
+import qualified Utility.CoProcess as CoProcess
+import qualified System.FilePath.ByteString as P
+
+import Numeric
+import System.Posix.Types
+import Control.Monad.IO.Class
+import qualified Data.Set as S
+import qualified Data.Map as M
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Char8 as S8
+
+newtype Tree = Tree [TreeContent]
+	deriving (Show)
+
+data TreeContent
+	-- A blob object in the tree.
+	= TreeBlob TopFilePath FileMode Sha
+	-- A subtree that is already recorded in git, with a known sha.
+	| RecordedSubTree TopFilePath Sha [TreeContent]
+	-- A subtree that has not yet been recorded in git.
+	| NewSubTree TopFilePath [TreeContent]
+	-- A commit object that is part of a tree (used for submodules)
+	| TreeCommit TopFilePath FileMode Sha
+	deriving (Show, Eq, Ord)
+
+{- Gets the Tree for a Ref. -}
+getTree :: LsTree.LsTreeRecursive -> Ref -> Repo -> IO Tree
+getTree recursive r repo = do
+	(l, cleanup) <- lsTreeWithObjects recursive r repo
+	let !t = either (\e -> giveup ("ls-tree parse error:" ++ e)) id
+		(extractTree l)
+	void cleanup
+	return t
+
+lsTreeWithObjects :: LsTree.LsTreeRecursive -> Ref -> Repo -> IO ([LsTree.TreeItem], IO Bool)
+lsTreeWithObjects recursive = 
+	LsTree.lsTree' [Param "-t"] recursive (LsTree.LsTreeLong False)
+
+newtype MkTreeHandle = MkTreeHandle CoProcess.CoProcessHandle
+
+withMkTreeHandle :: (MonadIO m, MonadMask m) => Repo -> (MkTreeHandle -> m a) -> m a
+withMkTreeHandle repo a = bracketIO setup cleanup (a . MkTreeHandle)
+  where
+	setup = gitCoProcessStart False ps repo
+	ps = [Param "mktree", Param "--missing", Param "--batch", Param "-z"]
+	cleanup = CoProcess.stop
+
+{- Records a Tree in the Repo, returning its Sha.
+ - 
+ - Efficiently handles subtrees, by only recording ones that have not
+ - already been recorded before. And even when many subtrees need to be
+ - recorded, it's done with a single call to git mktree, using its batch
+ - interface.
+ -}
+recordTree :: Tree -> Repo -> IO Sha
+recordTree t repo = withMkTreeHandle repo $ \h -> recordTree' h t
+
+recordTree' :: MkTreeHandle -> Tree -> IO Sha
+recordTree' h (Tree l) = mkTree h =<< mapM (recordSubTree h) l
+
+{- Note that the returned RecordedSubTree does not have its [TreeContent]
+ - list populated. This is a memory optimisation, since the list is not
+ - used. -}
+recordSubTree :: MkTreeHandle -> TreeContent -> IO TreeContent
+recordSubTree h (NewSubTree d l) = do
+	sha <- mkTree h =<< mapM (recordSubTree h) l
+	return (RecordedSubTree d sha [])
+recordSubTree _ alreadyrecorded = return alreadyrecorded
+
+sendMkTree :: MkTreeHandle -> FileMode -> ObjectType -> Sha -> TopFilePath -> IO ()
+sendMkTree (MkTreeHandle cp) fm ot s f =
+	CoProcess.send cp $ \h -> 
+		hPutStr h (mkTreeOutput fm ot s f)
+
+finishMkTree :: MkTreeHandle -> IO Sha
+finishMkTree (MkTreeHandle cp) = do
+	CoProcess.send cp $ \h ->
+		-- NUL to signal end of tree to --batch
+		hPutStr h "\NUL"
+	getSha "mktree" (CoProcess.receive cp S8.hGetLine)
+
+mkTree :: MkTreeHandle -> [TreeContent] -> IO Sha
+mkTree h l = do
+	forM_ l $ \case
+		TreeBlob f fm s -> sendMkTree h fm BlobObject s f
+		RecordedSubTree f s _ -> sendMkTree h treeMode TreeObject s f
+		NewSubTree _ _ -> error "recordSubTree internal error; unexpected NewSubTree"
+		TreeCommit f fm s -> sendMkTree h fm CommitObject s f
+	finishMkTree h
+
+treeMode :: FileMode
+treeMode = 0o040000
+
+mkTreeOutput :: FileMode -> ObjectType -> Sha -> TopFilePath -> String
+mkTreeOutput fm ot s f = concat
+	[ showOct fm ""
+	, " "
+	, decodeBS (fmtObjectType ot)
+	, " "
+	, fromRef s
+	, "\t"
+	, takeFileName (fromRawFilePath (getTopFilePath f))
+	, "\NUL"
+	]
+
+data TreeItem = TreeItem TopFilePath FileMode Sha
+	deriving (Show, Eq)
+
+treeItemToTreeContent :: TreeItem -> TreeContent
+treeItemToTreeContent (TreeItem f m s) = case toTreeItemType m of
+	Just TreeSubmodule -> TreeCommit f m s
+	_ -> TreeBlob f m s
+
+treeItemToLsTreeItem :: TreeItem -> LsTree.TreeItem
+treeItemToLsTreeItem (TreeItem f mode sha) = LsTree.TreeItem
+	{ LsTree.mode = mode
+	, LsTree.typeobj = fmtObjectType $ case toTreeItemType mode of
+		Just TreeSubmodule -> CommitObject
+		Just TreeSubtree -> TreeObject
+		_ -> BlobObject
+	, LsTree.sha = sha
+	, LsTree.size = Nothing
+	, LsTree.file = f
+	}
+
+lsTreeItemToTreeItem :: LsTree.TreeItem -> TreeItem
+lsTreeItemToTreeItem ti = TreeItem
+	(LsTree.file ti)
+	(LsTree.mode ti)
+	(LsTree.sha ti)
+
+treeItemsToTree :: [TreeItem] -> Tree
+treeItemsToTree = go M.empty
+  where
+	go m [] = Tree $ filter inTopTree (M.elems m)
+	go m (i:is)
+		| inTopTree p =
+			go (M.insert p (treeItemToTreeContent i) m) is
+		| otherwise = case M.lookup idir m of
+			Just (NewSubTree d l) ->
+				go (addsubtree idir m (NewSubTree d (c:l))) is
+			_ ->
+				go (addsubtree idir m (NewSubTree (asTopFilePath idir) [c])) is
+	  where
+		p = gitPath i
+		idir = P.takeDirectory p
+		c = treeItemToTreeContent i
+
+	addsubtree d m t
+		| not (inTopTree d) = 
+			let m' = M.insert d t m
+			in case M.lookup parent m' of
+				Just (NewSubTree d' l) ->
+					let l' = filter (\ti -> gitPath ti /= d) l
+					in addsubtree parent m' (NewSubTree d' (t:l'))
+				_ -> addsubtree parent m' (NewSubTree (asTopFilePath parent) [t])
+		| otherwise = M.insert d t m
+	  where
+		parent = P.takeDirectory d
+
+{- Flattens the top N levels of a Tree. -}
+flattenTree :: Int -> Tree -> Tree
+flattenTree 0 t = t
+flattenTree n (Tree l) = Tree (concatMap (go n) l)
+  where
+	go 0 c = [c]
+	go _ b@(TreeBlob _ _ _) = [b]
+	go n' (RecordedSubTree _ _ l') = concatMap (go (n'-1)) l'
+	go n' (NewSubTree _ l') = concatMap (go (n'-1)) l'
+	go _ c@(TreeCommit _ _ _) = [c]
+
+{- Applies an adjustment to items in a tree.
+ -
+ - While less flexible than using getTree and recordTree,
+ - this avoids buffering the whole tree in memory.
+ -}
+adjustTree
+	:: (Functor m, MonadIO m, MonadMask m)
+	=> (TreeItem -> m (Maybe TreeItem))
+	-- ^ Adjust an item in the tree. Nothing deletes the item.
+	-- Cannot move the item to a different tree.
+	-> [TreeItem]
+	-- ^ New items to add to the tree.
+	-> (TreeContent -> TreeContent -> TreeContent)
+	-- ^ When adding a new item to the tree and an item with the same
+	-- name already exists, this function picks which to use.
+	-- The first one is the item that was already in the tree.
+	-> [TopFilePath]
+	-- ^ Files to remove from the tree.
+	-> Ref
+	-> Repo
+	-> m Sha
+adjustTree adjusttreeitem addtreeitems resolveaddconflict removefiles r repo =
+	withMkTreeHandle repo $ \h -> do
+		(l, cleanup) <- liftIO $ lsTreeWithObjects LsTree.LsTreeRecursive r repo
+		(l', _, _) <- go h False [] 1 inTopTree l
+		l'' <- adjustlist h 0 inTopTree topTreePath l'
+		sha <- liftIO $ mkTree h l''
+		void $ liftIO cleanup
+		return sha
+  where
+	go _ wasmodified c _ _ [] = return (c, wasmodified, [])
+	go h wasmodified c depth intree (i:is)
+		| intree i = case readObjectType (LsTree.typeobj i) of
+			Just BlobObject -> do
+				let ti = TreeItem (LsTree.file i) (LsTree.mode i) (LsTree.sha i)
+				v <- adjusttreeitem ti
+				case v of
+					Nothing -> go h True c depth intree is
+					Just ti'@(TreeItem f m s) ->
+						let !modified = wasmodified || ti' /= ti
+						    blob = TreeBlob f m s
+						in go h modified (blob:c) depth intree is
+			Just TreeObject -> do
+				(sl, modified, is') <- go h False [] (depth+1) (beneathSubTree i) is
+				sl' <- adjustlist h depth (inTree i) (gitPath i) sl
+				let slmodified = sl' /= sl
+				subtree <- if modified || slmodified
+					then liftIO $ recordSubTree h $ NewSubTree (LsTree.file i) sl'
+					else return $ RecordedSubTree (LsTree.file i) (LsTree.sha i) [] 
+				let !modified' = modified || slmodified || wasmodified
+				go h modified' (subtree : c) depth intree is'
+			Just CommitObject -> do
+				let ti = TreeItem (LsTree.file i) (LsTree.mode i) (LsTree.sha i)
+				v <- adjusttreeitem ti
+				case v of
+					Nothing -> go h True c depth intree is
+					Just (TreeItem f m s) -> 
+						let commit = TreeCommit f m s
+						in go h wasmodified (commit:c) depth intree is
+			_ -> giveup ("unexpected object type \"" ++ decodeBS (LsTree.typeobj i) ++ "\"")
+		| otherwise = return (c, wasmodified, i:is)
+
+	adjustlist h depth ishere herepath l = do
+		let addhere = fromMaybe [] $ M.lookup herepath addtreeitempathmap
+		let l' = filter (not . removed) $
+			addoldnew l (map treeItemToTreeContent addhere)
+		let inl i = any (\t -> beneathSubTree t i) l'
+		let (Tree addunderhere) = flattenTree depth $ treeItemsToTree $
+			filter (not . inl) $ if herepath == topTreePath
+				then filter (not . ishere) addtreeitems
+				else fromMaybe [] $
+					M.lookup (subTreePrefix herepath) addtreeitemprefixmap
+		addunderhere' <- liftIO $ mapM (recordSubTree h) addunderhere
+		return (addoldnew l' addunderhere')
+
+	addtreeitempathmap = mkPathMap addtreeitems
+	addtreeitemprefixmap = mkSubTreePathPrefixMap addtreeitems
+
+	removeset = S.fromList $ map (P.normalise . gitPath) removefiles
+	removed (TreeBlob f _ _) = S.member (P.normalise (gitPath f)) removeset
+	removed (TreeCommit f _ _) = S.member (P.normalise (gitPath f)) removeset
+	removed (RecordedSubTree _ _ _) = False
+	removed (NewSubTree _ _) = False
+
+	addoldnew [] new = new
+	addoldnew old [] = old
+	addoldnew old new = addoldnew' (M.fromList $ map (\i -> (mkk i, i)) old) new
+	addoldnew' oldm (n:ns) = 
+			let k = mkk n
+			in case M.lookup k oldm of
+				Just o -> 
+					resolveaddconflict o n
+					: 
+					addoldnew' (M.delete k oldm) ns
+				Nothing -> n : addoldnew' oldm ns
+	addoldnew' oldm [] = M.elems oldm
+	mkk = P.normalise . gitPath
+
+{- Grafts subtree into the basetree at the specified location, replacing
+ - anything that the basetree already had at that location.
+ -
+ - This is generally much more efficient than using getTree and recordTree,
+ - or adjustTree, since it only needs to traverse from the top of the tree
+ - down to the graft location. It does not buffer the whole tree in memory.
+ -}
+graftTree
+	:: Sha
+	-> TopFilePath
+	-> Sha
+	-> Repo
+	-> IO Sha
+graftTree subtree graftloc basetree repo =
+	withMkTreeHandle repo $ graftTree' subtree graftloc basetree repo
+
+graftTree'
+	:: Sha
+	-> TopFilePath
+	-> Sha
+	-> Repo
+	-> MkTreeHandle
+	-> IO Sha
+graftTree' subtree graftloc basetree repo hdl = go basetree subdirs graftdirs 
+  where
+	go tsha (subdir:restsubdirs) (topmostgraphdir:restgraphdirs) = do
+		Tree t <- getTree LsTree.LsTreeNonRecursive tsha repo
+		let abovegraftpoint i = gitPath i == gitPath subdir
+		t' <- case partition abovegraftpoint t of
+			-- the graft point is not already in the tree,
+			-- so graft it in, keeping the existing tree
+			-- content
+			([], _) -> do
+				graft <- graftin (topmostgraphdir:restgraphdirs)
+				return (graft:t)
+			(matching, rest) -> do
+				newshas <- forM matching $ \case
+					RecordedSubTree tloc tsha' _
+						| null restgraphdirs -> return $
+							RecordedSubTree tloc subtree []
+						| otherwise -> do
+							tsha'' <- go tsha' restsubdirs restgraphdirs
+							return $ RecordedSubTree tloc tsha'' []
+					_ -> graftin (topmostgraphdir:restgraphdirs)
+				return (newshas ++ rest)
+		mkTree hdl t'
+	go _ _ [] = return subtree
+	go _ [] _ = return subtree
+	
+	graftin t = recordSubTree hdl $ graftin' t
+	graftin' [] = RecordedSubTree graftloc subtree []
+	graftin' (d:rest) 
+		| d == graftloc = graftin' []
+		| otherwise = NewSubTree d [graftin' rest]
+
+	subdirs = P.splitDirectories $ gitPath graftloc
+
+	graftdirs = map (asTopFilePath . toInternalGitPath) $
+		pathPrefixes subdirs
+
+{- Assumes the list is ordered, with tree objects coming right before their
+ - contents. -}
+extractTree :: [LsTree.TreeItem] -> Either String Tree
+extractTree l = case go [] inTopTree l of
+	Right (t, []) -> Right (Tree t)
+	Right _ -> parseerr "unexpected tree form"
+	Left e -> parseerr e
+  where
+	go t _ [] = Right (t, [])
+	go t intree (i:is)
+		| intree i = case readObjectType (LsTree.typeobj i) of
+			Just BlobObject ->
+				let b = TreeBlob (LsTree.file i) (LsTree.mode i) (LsTree.sha i)
+				in go (b:t) intree is
+			Just TreeObject -> case go [] (beneathSubTree i) is of
+				Right (subtree, is') ->
+					let st = RecordedSubTree (LsTree.file i) (LsTree.sha i) subtree
+					in go (st:t) intree is'
+				Left e -> Left e
+			Just CommitObject ->
+				let c = TreeCommit (LsTree.file i) (LsTree.mode i) (LsTree.sha i)
+				in go (c:t) intree is
+			_ -> parseerr ("unexpected object type \"" ++ decodeBS (LsTree.typeobj i) ++ "\"")
+		| otherwise = Right (t, i:is)
+	parseerr = Left
+
+class GitPath t where
+	gitPath :: t -> RawFilePath
+
+instance GitPath RawFilePath where
+	gitPath = id
+
+instance GitPath FilePath where
+	gitPath = toRawFilePath
+
+instance GitPath TopFilePath where
+	gitPath = getTopFilePath
+
+instance GitPath TreeItem where
+	gitPath (TreeItem f _ _) = gitPath f
+
+instance GitPath LsTree.TreeItem where
+	gitPath = gitPath . LsTree.file
+
+instance GitPath TreeContent where
+	gitPath (TreeBlob f _ _) = gitPath f
+	gitPath (RecordedSubTree f _ _) = gitPath f
+	gitPath (NewSubTree f _) = gitPath f
+	gitPath (TreeCommit f _ _) = gitPath f
+
+inTopTree :: GitPath t => t -> Bool
+inTopTree = inTree topTreePath
+
+topTreePath :: RawFilePath
+topTreePath = "."
+
+inTree :: (GitPath t, GitPath f) => t -> f -> Bool
+inTree t f = gitPath t == P.takeDirectory (gitPath f)
+
+beneathSubTree :: (GitPath t, GitPath f) => t -> f -> Bool
+beneathSubTree t f = subTreePrefix t `B.isPrefixOf` subTreePath f
+
+subTreePath :: GitPath t => t -> RawFilePath
+subTreePath = P.normalise . gitPath
+
+subTreePrefix :: GitPath t => t -> RawFilePath
+subTreePrefix t
+	| B.null tp = tp
+	| otherwise = P.addTrailingPathSeparator (P.normalise tp)
+  where
+	tp = gitPath t
+
+{- Makes a Map where the keys are directories, and the values
+ - are the items located in that directory.
+ -
+ - Values that are not in any subdirectory are placed in
+ - the topTreePath key.
+ -}
+mkPathMap :: GitPath t => [t] -> M.Map RawFilePath [t]
+mkPathMap l = M.fromListWith (++) $
+	map (\ti -> (P.takeDirectory (gitPath ti), [ti])) l
+
+{- Input is eg splitDirectories "foo/bar/baz",
+ - for which it will output ["foo", "foo/bar", "foo/bar/baz"] -}
+pathPrefixes :: [RawFilePath] -> [RawFilePath]
+pathPrefixes = go []
+  where
+	go _ [] = []
+	go base (d:rest) = (P.joinPath base P.</> d) : go (base ++ [d]) rest
+
+{- Makes a Map where the keys are all subtree path prefixes, 
+ - and the values are items with that subtree path prefix.
+ -}
+mkSubTreePathPrefixMap :: GitPath t => [t] -> M.Map RawFilePath [t]
+mkSubTreePathPrefixMap l = M.fromListWith (++) $ concatMap go l
+  where
+	go ti = map (\p -> (p, [ti]))
+		(map subTreePrefix $ pathPrefixes $ P.splitDirectories $ subTreePath ti)
diff --git a/Git/Types.hs b/Git/Types.hs
new file mode 100644
index 0000000000..ef7b159cae
--- /dev/null
+++ b/Git/Types.hs
@@ -0,0 +1,199 @@
+{- git data types
+ -
+ - Copyright 2010-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, TypeSynonymInstances, FlexibleInstances #-}
+
+module Git.Types where
+
+import Network.URI
+import Data.String
+import Data.Default
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import System.Posix.Types
+import Utility.SafeCommand
+import Utility.FileSystemEncoding
+import qualified Data.Semigroup as Sem
+import Prelude
+
+{- Support repositories on local disk, and repositories accessed via an URL.
+ -
+ - Repos on local disk have a git directory, and unless bare, a worktree.
+ -
+ - A local repo may not have had its config read yet, in which case all
+ - that's known about it is its path.
+ -
+ - Finally, an Unknown repository may be known to exist, but nothing
+ - else known about it.
+ -}
+data RepoLocation
+	= Local { gitdir :: RawFilePath, worktree :: Maybe RawFilePath }
+	| LocalUnknown RawFilePath
+	| Url URI
+	| UnparseableUrl String
+	| Unknown
+	deriving (Show, Eq, Ord)
+
+data Repo = Repo
+	{ location :: RepoLocation
+	, config :: M.Map ConfigKey ConfigValue
+	-- a given git config key can actually have multiple values
+	, fullconfig :: M.Map ConfigKey [ConfigValue]
+	-- remoteName holds the name used for this repo in some other
+	-- repo's list of remotes, when this repo is such a remote
+	, remoteName :: Maybe RemoteName
+	-- alternate environment to use when running git commands
+	, gitEnv :: Maybe [(String, String)]
+	, gitEnvOverridesGitDir :: Bool
+	-- global options to pass to git when running git commands
+	, gitGlobalOpts :: [CommandParam]
+	-- True only when --git-dir or GIT_DIR was used
+	, gitDirSpecifiedExplicitly :: Bool
+	-- Use when the path to the repository was specified explicitly,
+	-- eg in a git remote, and so it's safe to set 
+	-- -c safe.directory=* and -c safe.bareRepository=all 
+	-- when using this repository.
+	, repoPathSpecifiedExplicitly :: Bool
+	} deriving (Show, Eq, Ord)
+
+newtype ConfigKey = ConfigKey S.ByteString
+	deriving (Ord, Eq)
+
+data ConfigValue
+	= ConfigValue S.ByteString
+	| NoConfigValue
+	-- ^ git treats a setting with no value as different than a setting
+	-- with an empty value
+	deriving (Ord, Eq)
+
+instance Sem.Semigroup ConfigValue where
+	ConfigValue a <> ConfigValue b = ConfigValue (a <> b)
+	a <> NoConfigValue = a
+	NoConfigValue <> b = b
+
+instance Monoid ConfigValue where
+	mempty = ConfigValue mempty
+
+instance Default ConfigValue where
+	def = ConfigValue mempty
+
+fromConfigKey :: ConfigKey -> String
+fromConfigKey (ConfigKey s) = decodeBS s
+
+instance Show ConfigKey where
+	show = fromConfigKey
+
+class FromConfigValue a where
+	fromConfigValue :: ConfigValue -> a
+
+instance FromConfigValue S.ByteString where
+	fromConfigValue (ConfigValue s) = s
+	fromConfigValue NoConfigValue = mempty
+
+instance FromConfigValue String where
+	fromConfigValue = decodeBS . fromConfigValue
+
+instance Show ConfigValue where
+	show = fromConfigValue
+
+instance IsString ConfigKey where
+	fromString = ConfigKey . encodeBS
+
+instance IsString ConfigValue where
+	fromString = ConfigValue . encodeBS
+
+type RemoteName = String
+
+{- A git ref. Can be a sha1, or a branch or tag name. -}
+newtype Ref = Ref S.ByteString
+	deriving (Eq, Ord, Read, Show)
+
+fromRef :: Ref -> String
+fromRef = decodeBS . fromRef'
+
+fromRef' :: Ref -> S.ByteString
+fromRef' (Ref s) = s
+
+{- Aliases for Ref. -}
+type Branch = Ref
+type Sha = Ref
+type Tag = Ref
+
+{- A date in the format described in gitrevisions. Includes the
+ - braces, eg, "{yesterday}" -}
+newtype RefDate = RefDate String
+
+{- Types of objects that can be stored in git. -}
+data ObjectType = BlobObject | CommitObject | TreeObject
+	deriving (Show)
+
+readObjectType :: S.ByteString -> Maybe ObjectType
+readObjectType "blob" = Just BlobObject
+readObjectType "commit" = Just CommitObject
+readObjectType "tree" = Just TreeObject
+readObjectType _ = Nothing
+
+fmtObjectType :: ObjectType -> S.ByteString
+fmtObjectType BlobObject = "blob"
+fmtObjectType CommitObject = "commit"
+fmtObjectType TreeObject = "tree"
+
+{- Types of items in a tree. -}
+data TreeItemType
+	= TreeFile
+	| TreeExecutable
+	| TreeSymlink
+	| TreeSubmodule
+	| TreeSubtree
+	deriving (Eq, Show)
+
+{- Git uses magic numbers to denote the type of a tree item. -}
+readTreeItemType :: S.ByteString -> Maybe TreeItemType
+readTreeItemType "100644" = Just TreeFile
+readTreeItemType "100755" = Just TreeExecutable
+readTreeItemType "120000" = Just TreeSymlink
+readTreeItemType "160000" = Just TreeSubmodule
+readTreeItemType "040000" = Just TreeSubtree
+readTreeItemType _ = Nothing
+
+fmtTreeItemType :: TreeItemType -> S.ByteString
+fmtTreeItemType TreeFile = "100644"
+fmtTreeItemType TreeExecutable = "100755"
+fmtTreeItemType TreeSymlink = "120000"
+fmtTreeItemType TreeSubmodule = "160000"
+fmtTreeItemType TreeSubtree = "040000"
+
+toTreeItemType :: FileMode -> Maybe TreeItemType
+toTreeItemType 0o100644 = Just TreeFile
+toTreeItemType 0o100755 = Just TreeExecutable
+toTreeItemType 0o120000 = Just TreeSymlink
+toTreeItemType 0o160000 = Just TreeSubmodule
+toTreeItemType 0o040000 = Just TreeSubtree
+toTreeItemType _ = Nothing
+
+fromTreeItemType :: TreeItemType -> FileMode
+fromTreeItemType TreeFile = 0o100644
+fromTreeItemType TreeExecutable = 0o100755
+fromTreeItemType TreeSymlink = 0o120000
+fromTreeItemType TreeSubmodule = 0o160000
+fromTreeItemType TreeSubtree = 0o040000
+
+data Commit = Commit
+	{ commitTree :: Sha
+	, commitParent :: [Sha]
+	, commitAuthorMetaData :: CommitMetaData
+	, commitCommitterMetaData :: CommitMetaData
+	, commitMessage :: String
+	}
+	deriving (Show)
+
+data CommitMetaData = CommitMetaData
+	{ commitName :: Maybe String
+	, commitEmail :: Maybe String
+	, commitDate :: Maybe String -- In raw git form, "epoch -tzoffset"
+	}
+	deriving (Show)
diff --git a/Git/UnionMerge.hs b/Git/UnionMerge.hs
new file mode 100644
index 0000000000..ff3a6da534
--- /dev/null
+++ b/Git/UnionMerge.hs
@@ -0,0 +1,116 @@
+{- git-union-merge library
+ -
+ - Copyright 2011 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.UnionMerge (
+	merge,
+	mergeIndex
+) where
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString.Lazy.Char8 as L8
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.Set as S
+
+import Common
+import Git
+import Git.Sha
+import Git.CatFile
+import Git.Command
+import Git.UpdateIndex
+import Git.HashObject
+import Git.Types
+import Git.FilePath
+
+{- Performs a union merge between two branches, staging it in the index.
+ - Any previously staged changes in the index will be lost.
+ -
+ - Should be run with a temporary index file configured by useIndex.
+ -}
+merge :: Ref -> Ref -> Repo -> IO ()
+merge x y repo = do
+	hashhandle <- hashObjectStart True repo
+	ch <- catFileStart repo
+	streamUpdateIndex repo
+		[ lsTree x repo
+		, mergeTrees x y hashhandle ch repo
+		]
+	catFileStop ch
+	hashObjectStop hashhandle
+
+{- Merges a list of branches into the index. Previously staged changes in
+ - the index are preserved (and participate in the merge).
+ -
+ - update-index is run once per ref in turn, so that each ref is merged on
+ - top of the merge for the previous ref. It would be more efficient, but
+ - harder to calculate a single union merge involving all the refs, as well
+ - as the index.
+ -}
+mergeIndex :: HashObjectHandle -> CatFileHandle -> Repo -> [Ref] -> IO ()
+mergeIndex hashhandle ch repo bs = forM_ bs $ \b ->
+	streamUpdateIndex repo [mergeTreeIndex b hashhandle ch repo]
+
+{- For merging two trees. -}
+mergeTrees :: Ref -> Ref -> HashObjectHandle -> CatFileHandle -> Repo -> Streamer
+mergeTrees x y hashhandle ch = doMerge hashhandle ch
+	("diff-tree":diffOpts ++ [fromRef x, fromRef y, "--"])
+
+{- For merging a single tree into the index. -}
+mergeTreeIndex :: Ref -> HashObjectHandle -> CatFileHandle -> Repo -> Streamer
+mergeTreeIndex r hashhandle ch = doMerge hashhandle ch $
+	"diff-index" : diffOpts ++ ["--cached", fromRef r, "--"]
+
+diffOpts :: [String]
+diffOpts = ["--raw", "-z", "-r", "--no-renames", "-l0"]
+
+{- Streams update-index changes to perform a merge,
+ - using git to get a raw diff. -}
+doMerge :: HashObjectHandle -> CatFileHandle -> [String] -> Repo -> Streamer
+doMerge hashhandle ch differ repo streamer = do
+	(diff, cleanup) <- pipeNullSplit' (map Param differ) repo
+	go diff
+	void $ cleanup
+  where
+	go [] = noop
+	go (info:file:rest) = mergeFile info file hashhandle ch >>=
+		maybe (go rest) (\l -> streamer l >> go rest)
+	go (_:[]) = giveup $ "parse error " ++ show differ
+
+{- Given an info line from a git raw diff, and the filename, generates
+ - a line suitable for update-index that union merges the two sides of the
+ - diff. -}
+mergeFile :: S.ByteString -> RawFilePath -> HashObjectHandle -> CatFileHandle -> IO (Maybe L.ByteString)
+mergeFile info file hashhandle h = case S8.words info of
+	[_colonmode, _bmode, asha, bsha, _status] -> 
+		case filter (`notElem` nullShas) [Ref asha, Ref bsha] of
+			[] -> return Nothing
+			(sha:[]) -> use sha
+			shas -> use
+				=<< either return (hashBlob hashhandle . L8.unlines)
+				=<< calcMerge . zip shas <$> mapM getcontents shas
+	_ -> return Nothing
+  where
+	use sha = return $ Just $
+		updateIndexLine sha TreeFile $ asTopFilePath file
+	-- Get file and split into lines to union merge.
+	-- The encoding of the file is assumed to be either ASCII or utf-8;
+	-- in either case it's safe to split on \n
+	getcontents s = L8.lines <$> catObject h s
+
+{- Calculates a union merge between a list of refs, with contents.
+ -
+ - When possible, reuses the content of an existing ref, rather than
+ - generating new content.
+ -}
+calcMerge :: [(Ref, [L8.ByteString])] -> Either Ref [L8.ByteString]
+calcMerge shacontents
+	| null reusable = Right new
+	| otherwise = Left $ fst $ Prelude.head reusable
+  where
+	reusable = filter (\c -> sorteduniq (snd c) == new) shacontents
+	new = sorteduniq $ concat $ map snd shacontents
+	sorteduniq = S.toList . S.fromList
diff --git a/Git/UpdateIndex.hs b/Git/UpdateIndex.hs
new file mode 100644
index 0000000000..f56bc86cbc
--- /dev/null
+++ b/Git/UpdateIndex.hs
@@ -0,0 +1,169 @@
+{- git-update-index library
+ -
+ - Copyright 2011-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns, OverloadedStrings, CPP #-}
+
+module Git.UpdateIndex (
+	Streamer,
+	pureStreamer,
+	streamUpdateIndex,
+	streamUpdateIndex',
+	withUpdateIndex,
+	lsTree,
+	lsSubTree,
+	updateIndexLine,
+	stageFile,
+	unstageFile,
+	stageSymlink,
+	stageDiffTreeItem,
+	refreshIndex,
+) where
+
+import Common
+import Git
+import Git.Types
+import Git.Command
+import Git.FilePath
+import Git.Sha
+import qualified Git.DiffTreeItem as Diff
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import Control.Monad.IO.Class
+
+{- Streamers are passed a callback and should feed it lines in the form
+ - read by update-index, and generated by ls-tree. -}
+type Streamer = (L.ByteString -> IO ()) -> IO ()
+
+{- A streamer with a precalculated value. -}
+pureStreamer :: L.ByteString -> Streamer
+pureStreamer !s = \streamer -> streamer s
+
+{- Streams content into update-index from a list of Streamers. -}
+streamUpdateIndex :: Repo -> [Streamer] -> IO ()
+streamUpdateIndex repo as = withUpdateIndex repo $ \h ->
+	forM_ as $ streamUpdateIndex' h
+
+data UpdateIndexHandle = UpdateIndexHandle Handle
+
+streamUpdateIndex' :: UpdateIndexHandle -> Streamer -> IO ()
+streamUpdateIndex' (UpdateIndexHandle h) a = a $ \s -> do
+	L.hPutStr h s
+	L.hPutStr h "\0"
+
+withUpdateIndex :: (MonadIO m, MonadMask m) => Repo -> (UpdateIndexHandle -> m a) -> m a
+withUpdateIndex repo a = bracket setup cleanup go
+  where
+	params = map Param ["update-index", "-z", "--index-info"]
+	
+	setup = liftIO $ createProcess $ 
+		(gitCreateProcess params repo)
+			{ std_in = CreatePipe }
+	go p = do
+		r <- a (UpdateIndexHandle (stdinHandle p))
+		liftIO $ do
+			hClose (stdinHandle p)
+			void $ checkSuccessProcess (processHandle p)
+		return r
+	
+	cleanup = liftIO . cleanupProcess
+
+{- A streamer that adds the current tree for a ref. Useful for eg, copying
+ - and modifying branches. -}
+lsTree :: Ref -> Repo -> Streamer
+lsTree (Ref x) repo streamer = do
+	(s, cleanup) <- pipeNullSplit params repo
+	mapM_ streamer s
+	void $ cleanup
+  where
+	params = map Param ["ls-tree", "-z", "-r", "--full-tree", decodeBS x]
+lsSubTree :: Ref -> FilePath -> Repo -> Streamer
+lsSubTree (Ref x) p repo streamer = do
+	(s, cleanup) <- pipeNullSplit params repo
+	mapM_ streamer s
+	void $ cleanup
+  where
+	params = map Param ["ls-tree", "-z", "-r", "--full-tree", decodeBS x, p]
+
+{- Generates a line suitable to be fed into update-index, to add
+ - a given file with a given sha. -}
+updateIndexLine :: Sha -> TreeItemType -> TopFilePath -> L.ByteString
+updateIndexLine sha treeitemtype file = L.fromStrict $
+	fmtTreeItemType treeitemtype
+	<> " blob "
+	<> fromRef' sha
+	<> "\t"
+	<> indexPath file
+
+stageFile :: Sha -> TreeItemType -> RawFilePath -> Repo -> IO Streamer
+stageFile sha treeitemtype file repo = do
+	p <- toTopFilePath file repo
+	return $ pureStreamer $ updateIndexLine sha treeitemtype p
+
+{- A streamer that removes a file from the index. -}
+unstageFile :: RawFilePath -> Repo -> IO Streamer
+unstageFile file repo = do
+	p <- toTopFilePath file repo
+	return $ unstageFile' p
+
+unstageFile' :: TopFilePath -> Streamer
+unstageFile' p = pureStreamer $ L.fromStrict $
+	"0 "
+	<> fromRef' deleteSha
+	<> "\t"
+	<> indexPath p
+
+{- A streamer that adds a symlink to the index. -}
+stageSymlink :: RawFilePath -> Sha -> Repo -> IO Streamer
+stageSymlink file sha repo = do
+	!line <- updateIndexLine
+		<$> pure sha
+		<*> pure TreeSymlink
+		<*> toTopFilePath file repo
+	return $ pureStreamer line
+
+{- A streamer that applies a DiffTreeItem to the index. -}
+stageDiffTreeItem :: Diff.DiffTreeItem -> Streamer
+stageDiffTreeItem d = case toTreeItemType (Diff.dstmode d) of
+	Nothing -> unstageFile' (Diff.file d)
+	Just t -> pureStreamer $ updateIndexLine (Diff.dstsha d) t (Diff.file d)
+
+indexPath :: TopFilePath -> InternalGitPath
+indexPath = toInternalGitPath . getTopFilePath
+
+{- Refreshes the index, by checking file stat information.
+ -
+ - The action is passed a callback that it can use to send filenames to
+ - update-index. Sending Nothing will wait for update-index to finish
+ - updating the index.
+ -}
+refreshIndex :: (MonadIO m, MonadMask m) => Repo -> ((Maybe RawFilePath -> IO ()) -> m ()) -> m ()
+refreshIndex repo feeder = bracket
+	(liftIO $ createProcess p)
+	(liftIO . cleanupProcess)
+	go
+  where
+	params = 
+		[ Param "update-index"
+		, Param "-q"
+		, Param "--refresh"
+		, Param "-z"
+		, Param "--stdin"
+		]
+	
+	p = (gitCreateProcess params repo)
+		{ std_in = CreatePipe }
+
+	go (Just h, _, _, pid) = do
+		let closer = do
+			hClose h
+			forceSuccessProcess p pid
+		feeder $ \case
+			Just f -> S.hPut h (S.snoc f 0)
+			Nothing -> closer
+		liftIO $ closer
+	go _ = error "internal"
diff --git a/Git/Url.hs b/Git/Url.hs
new file mode 100644
index 0000000000..ad0e61b648
--- /dev/null
+++ b/Git/Url.hs
@@ -0,0 +1,72 @@
+{- git repository urls
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Git.Url (
+	scheme,
+	host,
+	port,
+	hostuser,
+	authority,
+	path,
+) where
+
+import Network.URI hiding (scheme, authority, path)
+
+import Common
+import Git.Types
+
+{- Scheme of an URL repo. -}
+scheme :: Repo -> Maybe String
+scheme Repo { location = Url u } = Just (uriScheme u)
+scheme _ = Nothing
+
+{- Work around a bug in the real uriRegName
+ - <http://trac.haskell.org/network/ticket/40> -}
+uriRegName' :: URIAuth -> String
+uriRegName' a = fixup $ uriRegName a
+  where
+	fixup x@('[':rest)
+		| rest !! len == ']' = take len rest
+		| otherwise = x
+	  where
+		len  = length rest - 1
+	fixup x = x
+
+{- Hostname of an URL repo. -}
+host :: Repo -> Maybe String
+host = authpart uriRegName'
+
+{- Port of an URL repo, if it has a nonstandard one. -}
+port :: Repo -> Maybe Integer
+port r = 
+	case authpart uriPort r of
+		Nothing -> Nothing
+		Just ":" -> Nothing
+		Just (':':p) -> readish p
+		Just _ -> Nothing
+
+{- Hostname of an URL repo, including any username (ie, "user@host") -}
+hostuser :: Repo -> Maybe String
+hostuser r = (++)
+	<$> authpart uriUserInfo r
+	<*> authpart uriRegName' r
+
+{- The full authority portion an URL repo. (ie, "user@host:port") -}
+authority :: Repo -> Maybe String
+authority = authpart assemble
+  where
+	assemble a = uriUserInfo a ++ uriRegName' a ++ uriPort a
+
+{- Applies a function to extract part of the uriAuthority of an URL repo. -}
+authpart :: (URIAuth -> a) -> Repo -> Maybe a
+authpart a Repo { location = Url u } = a <$> uriAuthority u
+authpart _ _ = Nothing
+
+{- Path part of an URL repo. -}
+path :: Repo -> Maybe FilePath
+path Repo { location = Url u } = Just (uriPath u)
+path _ = Nothing
diff --git a/Git/Version.hs b/Git/Version.hs
new file mode 100644
index 0000000000..9119f5dac8
--- /dev/null
+++ b/Git/Version.hs
@@ -0,0 +1,32 @@
+{- git versions
+ -
+ - Copyright 2011, 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Git.Version (
+	installed,
+	older,
+	normalize,
+	GitVersion,
+) where
+
+import Utility.Process
+import Utility.DottedVersion
+
+type GitVersion = DottedVersion
+
+installed :: IO GitVersion
+installed = normalize . extract <$> readProcess "git" ["--version"]
+  where
+	extract s = case lines s of
+		[] -> ""
+		(l:_) -> unwords $ drop 2 $ words l
+
+older :: String -> IO Bool
+older n = do
+	v <- installed
+	return $ v < normalize n 
diff --git a/Key.hs b/Key.hs
new file mode 100644
index 0000000000..b19aee8040
--- /dev/null
+++ b/Key.hs
@@ -0,0 +1,108 @@
+{- git-annex Keys
+ -
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module Key (
+	Key,
+	KeyData(..),
+	AssociatedFile(..),
+	fromKey,
+	mkKey,
+	alterKey,
+	keyParser,
+	serializeKey,
+	serializeKey',
+	deserializeKey,
+	deserializeKey',
+	nonChunkKey,
+	chunkKeyOffset,
+	isChunkKey,
+	isKeyPrefix,
+	splitKeyNameExtension,
+
+	prop_isomorphic_key_encode
+) where
+
+import qualified Data.Text as T
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Short as S (toShort, fromShort)
+import qualified Data.Attoparsec.ByteString as A
+
+import Common
+import Types.Key
+import Utility.QuickCheck
+import Utility.Bloom
+import Utility.Aeson
+import qualified Utility.SimpleProtocol as Proto
+
+-- Gets the parent of a chunk key.
+nonChunkKey :: Key -> Key
+nonChunkKey k
+	| fromKey keyChunkSize k == Nothing && fromKey keyChunkNum k == Nothing = k
+	| otherwise = alterKey k $ \d -> d
+		{ keyChunkSize = Nothing
+		, keyChunkNum = Nothing
+		}
+
+-- Where a chunk key is offset within its parent.
+chunkKeyOffset :: Key -> Maybe Integer
+chunkKeyOffset k = (*)
+	<$> fromKey keyChunkSize k
+	<*> (pred <$> fromKey keyChunkNum k)
+
+isChunkKey :: Key -> Bool
+isChunkKey k = isJust (fromKey keyChunkSize k) && isJust (fromKey keyChunkNum k)
+
+serializeKey :: Key -> String
+serializeKey = decodeBS . serializeKey'
+
+serializeKey' :: Key -> S.ByteString
+serializeKey' = S.fromShort . keySerialization
+
+deserializeKey :: String -> Maybe Key
+deserializeKey = deserializeKey' . encodeBS
+
+deserializeKey' :: S.ByteString -> Maybe Key
+deserializeKey' = eitherToMaybe . A.parseOnly keyParser
+
+instance Arbitrary KeyData where
+	arbitrary = Key
+		<$> (S.toShort . encodeBS <$> (listOf1 $ elements $ ['A'..'Z'] ++ ['a'..'z'] ++ ['0'..'9'] ++ "-_\r\n \t"))
+		<*> (parseKeyVariety . encodeBS <$> (listOf1 $ elements ['A'..'Z'])) -- BACKEND
+		<*> ((abs <$>) <$> arbitrary) -- size cannot be negative
+		<*> ((abs . fromInteger <$>) <$> arbitrary) -- mtime cannot be negative
+		<*> ((abs <$>) <$> arbitrary) -- chunksize cannot be negative
+		<*> ((succ . abs <$>) <$> arbitrary) -- chunknum cannot be 0 or negative
+
+instance Arbitrary AssociatedFile where
+  	arbitrary = AssociatedFile
+		. fmap (toRawFilePath . fromTestableFilePath)
+		<$> arbitrary
+
+instance Arbitrary Key where
+	arbitrary = mkKey . const <$> arbitrary
+
+instance Hashable Key where
+	hashIO32 = hashIO32 . serializeKey'
+	hashIO64 = hashIO64 . serializeKey'
+
+instance ToJSON' Key where
+	toJSON' = toJSON' . serializeKey
+
+instance FromJSON Key where
+	parseJSON (String t) = maybe mempty pure $ deserializeKey $ T.unpack t
+	parseJSON _ = mempty
+
+instance Proto.Serializable Key where
+	serialize = serializeKey
+	deserialize = deserializeKey
+
+prop_isomorphic_key_encode :: Key -> Bool
+prop_isomorphic_key_encode k = Just k == (deserializeKey . serializeKey) k
+
diff --git a/Limit.hs b/Limit.hs
new file mode 100644
index 0000000000..5a343a547f
--- /dev/null
+++ b/Limit.hs
@@ -0,0 +1,676 @@
+{- user-specified limits on files to act on
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Limit where
+
+import Annex.Common
+import qualified Annex
+import qualified Utility.Matcher
+import qualified Remote
+import Annex.Content
+import Annex.WorkTree
+import Annex.UUID
+import Annex.Magic
+import Annex.Link
+import Types.Link
+import Logs.Trust
+import Annex.NumCopies
+import Types.Key
+import Types.TrustLevel
+import Types.Group
+import Types.FileMatcher
+import Types.MetaData
+import Annex.MetaData
+import Logs.MetaData
+import Logs.Group
+import Logs.Unused
+import Logs.Location
+import Annex.CatFile
+import Git.FilePath
+import Git.Types (RefDate(..))
+import Utility.Glob
+import Utility.HumanTime
+import Utility.DataUnits
+import qualified Database.Keys
+import qualified Utility.RawFilePath as R
+import Backend
+
+import Control.Monad.Writer
+import Data.Time.Clock.POSIX
+import qualified Data.Set as S
+import qualified Data.Map as M
+import qualified System.FilePath.ByteString as P
+import System.PosixCompat.Files (accessTime, isSymbolicLink)
+
+{- Some limits can look at the current status of files on
+ - disk, or in the annex. This allows controlling which happens. -}
+data LimitBy = LimitDiskFiles | LimitAnnexFiles
+
+{- Checks if there are user-specified limits. -}
+limited :: Annex Bool
+limited = (not . Utility.Matcher.isEmpty) <$> getMatcher'
+
+{- Gets a matcher for the user-specified limits. The matcher is cached for
+ - speed; once it's obtained the user-specified limits can't change. -}
+getMatcher :: Annex (MatchInfo -> Annex Bool)
+getMatcher = run <$> getMatcher'
+  where
+	run matcher i = do
+		(match, desc) <- runWriterT $
+			Utility.Matcher.matchMrun' matcher $ \o ->
+				matchAction o S.empty i
+		explain (mkActionItem i) $ UnquotedString <$>
+			Utility.Matcher.describeMatchResult matchDesc desc
+				(if match then "matches:" else "does not match:")
+		return match
+
+getMatcher' :: Annex (Utility.Matcher.Matcher (MatchFiles Annex))
+getMatcher' = go =<< Annex.getState Annex.limit
+  where
+	go (CompleteMatcher matcher) = return matcher
+	go (BuildingMatcher l) = do
+		let matcher = Utility.Matcher.generate (reverse l)
+		Annex.changeState $ \s ->
+			s { Annex.limit = CompleteMatcher matcher }
+		return matcher
+
+{- Checks if the user-specified limits contains anything that meets the
+ - condition. -}
+introspect :: (MatchFiles Annex -> Bool) -> Annex Bool
+introspect c = Utility.Matcher.introspect c <$> getMatcher'
+
+{- Adds something to the limit list, which is built up reversed. -}
+add :: Utility.Matcher.Token (MatchFiles Annex) -> Annex ()
+add l = Annex.changeState $ \s -> s { Annex.limit = prepend $ Annex.limit s }
+  where
+	prepend (BuildingMatcher ls) = BuildingMatcher (l:ls)
+	prepend _ = error "internal"
+
+{- Adds a new syntax token. -}
+addSyntaxToken :: String -> Annex ()
+addSyntaxToken = either giveup add . Utility.Matcher.syntaxToken
+
+{- Adds a new limit. -}
+addLimit :: Either String (MatchFiles Annex) -> Annex ()
+addLimit = either giveup (add . Utility.Matcher.Operation)
+
+{- Add a limit to skip files that do not match the glob. -}
+addInclude :: String -> Annex ()
+addInclude = addLimit . limitInclude
+
+limitInclude :: MkLimit Annex
+limitInclude glob = Right $ MatchFiles
+	{ matchAction = const $ matchGlobFile glob
+	, matchNeedsFileName = True
+	, matchNeedsFileContent = False
+	, matchNeedsKey = False
+	, matchNeedsLocationLog = False
+	, matchDesc = "include" =? glob
+	}
+
+{- Add a limit to skip files that match the glob. -}
+addExclude :: String -> Annex ()
+addExclude = addLimit . limitExclude
+
+limitExclude :: MkLimit Annex
+limitExclude glob = Right $ MatchFiles
+	{ matchAction = const $ not <$$> matchGlobFile glob
+	, matchNeedsFileName = True
+	, matchNeedsFileContent = False
+	, matchNeedsKey = False
+	, matchNeedsLocationLog = False
+	, matchDesc = "exclude" =? glob
+	}
+
+matchGlobFile :: String -> MatchInfo -> Annex Bool
+matchGlobFile glob = go
+  where
+	cglob = compileGlob glob CaseSensitive (GlobFilePath True) -- memoized
+	go (MatchingFile fi) = pure $ matchGlob cglob (fromRawFilePath (matchFile fi))
+	go (MatchingInfo p) = pure $ case providedFilePath p of
+		Just f -> matchGlob cglob (fromRawFilePath f)
+		Nothing -> False
+	go (MatchingUserInfo p) = matchGlob cglob <$> getUserInfo (userProvidedFilePath p)
+
+{- Add a limit to skip files when there is no other file using the same
+ - content, with a name matching the glob. -}
+addIncludeSameContent :: String -> Annex ()
+addIncludeSameContent = addLimit . limitIncludeSameContent
+
+limitIncludeSameContent :: MkLimit Annex
+limitIncludeSameContent glob = Right $ MatchFiles
+	{ matchAction = const $ matchSameContentGlob glob
+	, matchNeedsFileName = True
+	, matchNeedsFileContent = False
+	, matchNeedsKey = False
+	, matchNeedsLocationLog = False
+	, matchDesc = "includesamecontent" =? glob
+	}
+
+{- Add a limit to skip files when there is no other file using the same
+ - content, with a name matching the glob. -}
+addExcludeSameContent :: String -> Annex ()
+addExcludeSameContent = addLimit . limitExcludeSameContent
+
+limitExcludeSameContent :: MkLimit Annex
+limitExcludeSameContent glob = Right $ MatchFiles
+	{ matchAction = const $ not <$$> matchSameContentGlob glob
+	, matchNeedsFileName = True
+	, matchNeedsFileContent = False
+	, matchNeedsKey = False
+	, matchNeedsLocationLog = False
+	, matchDesc = "excludesamecontent" =? glob
+	}
+
+matchSameContentGlob :: String -> MatchInfo -> Annex Bool
+matchSameContentGlob glob mi = checkKey (go mi) mi
+  where
+	go (MatchingFile fi) k = check k (matchFile fi)
+	go (MatchingInfo p) k = case providedFilePath p of
+		Just f -> check k f
+		Nothing -> return False
+	go (MatchingUserInfo p) k = 
+		check k . toRawFilePath
+			=<< getUserInfo (userProvidedFilePath p)
+	
+	cglob = compileGlob glob CaseSensitive (GlobFilePath True) -- memoized
+	
+	matchesglob f = matchGlob cglob (fromRawFilePath f)
+#ifdef mingw32_HOST_OS
+		|| matchGlob cglob (fromRawFilePath (toInternalGitPath f))
+#endif
+
+	check k skipf = do
+		-- Find other files with the same content, with filenames
+		-- matching the glob.
+		g <- Annex.gitRepo
+		fs <- filter (/= P.normalise skipf)
+			. filter matchesglob
+			. map (\f -> P.normalise (fromTopFilePath f g))
+			<$> Database.Keys.getAssociatedFiles k
+		-- Some associated files in the keys database may no longer
+		-- correspond to files in the repository. This is checked
+		-- last as it's most expensive.
+		anyM (\f -> maybe False (== k) <$> catKeyFile f) fs
+
+addMimeType :: String -> Annex ()
+addMimeType = addMagicLimit "mimetype" getMagicMimeType providedMimeType userProvidedMimeType
+
+addMimeEncoding :: String -> Annex ()
+addMimeEncoding = addMagicLimit "mimeencoding" getMagicMimeEncoding providedMimeEncoding userProvidedMimeEncoding
+
+addMagicLimit
+	:: String
+	-> (Magic -> FilePath -> Annex (Maybe String))
+	-> (ProvidedInfo -> Maybe String)
+	-> (UserProvidedInfo -> UserInfo String)
+	-> String
+	-> Annex ()
+addMagicLimit limitname querymagic selectprovidedinfo selectuserprovidedinfo glob = do
+	magic <- liftIO initMagicMime
+	addLimit $ matchMagic limitname querymagic' selectprovidedinfo selectuserprovidedinfo magic glob
+  where
+	querymagic' magic f = liftIO (isPointerFile (toRawFilePath f)) >>= \case
+		-- Avoid getting magic of a pointer file, which would
+		-- wrongly be detected as text.
+		Just _ -> return Nothing
+		-- When the file is an annex symlink, get magic of the
+		-- object file.
+		Nothing -> isAnnexLink (toRawFilePath f) >>= \case
+			Just k -> withObjectLoc k $
+				querymagic magic . fromRawFilePath
+			Nothing -> querymagic magic f
+
+matchMagic
+	:: String
+	-> (Magic -> FilePath -> Annex (Maybe String))
+	-> (ProvidedInfo -> Maybe String)
+	-> (UserProvidedInfo -> UserInfo String)
+	-> Maybe Magic
+	-> MkLimit Annex
+matchMagic limitname querymagic selectprovidedinfo selectuserprovidedinfo (Just magic) glob = 
+	Right $ MatchFiles
+		{ matchAction = const go
+		, matchNeedsFileName = False
+		, matchNeedsFileContent = True
+		, matchNeedsKey = False
+		, matchNeedsLocationLog = False
+		, matchDesc = limitname =? glob
+		}
+  where
+ 	cglob = compileGlob glob CaseSensitive (GlobFilePath False) -- memoized
+	go (MatchingFile fi) = catchBoolIO $
+		maybe False (matchGlob cglob)
+			<$> querymagic magic (fromRawFilePath (contentFile fi))
+	go (MatchingInfo p) = maybe
+		(usecontent (providedKey p))
+		(pure . matchGlob cglob)
+		(selectprovidedinfo p)
+	go (MatchingUserInfo p) =
+		matchGlob cglob <$> getUserInfo (selectuserprovidedinfo p)
+	usecontent (Just k) = withObjectLoc k $ \obj -> catchBoolIO $
+		maybe False (matchGlob cglob)
+			<$> querymagic magic (fromRawFilePath obj)
+	usecontent Nothing = pure False
+matchMagic limitname _ _ _ Nothing _ = 
+	Left $ "unable to load magic database; \""++limitname++"\" cannot be used"
+
+addUnlocked :: Annex ()
+addUnlocked = addLimit $ Right $ MatchFiles
+	{ matchAction = const $ matchLockStatus False
+	, matchNeedsFileName = True
+	, matchNeedsFileContent = False
+	, matchNeedsKey = False
+	, matchNeedsLocationLog = False
+	, matchDesc = matchDescSimple "unlocked"
+	}
+
+addLocked :: Annex ()
+addLocked = addLimit $ Right $ MatchFiles
+	{ matchAction = const $ matchLockStatus True
+	, matchNeedsFileName = True
+	, matchNeedsFileContent = False
+	, matchNeedsKey = False
+	, matchNeedsLocationLog = False
+	, matchDesc = matchDescSimple "locked"
+	}
+
+matchLockStatus :: Bool -> MatchInfo -> Annex Bool
+matchLockStatus wantlocked (MatchingFile fi) = liftIO $ do
+	let f = contentFile fi
+	islocked <- isPointerFile f >>= \case
+		Just _key -> return False
+		Nothing -> isSymbolicLink
+			<$> R.getSymbolicLinkStatus f
+	return (islocked == wantlocked)
+matchLockStatus wantlocked (MatchingInfo p) = 
+	pure $ case providedLinkType p of
+		Nothing -> False
+		Just LockedLink -> wantlocked
+		Just UnlockedLink -> not wantlocked
+matchLockStatus _ (MatchingUserInfo _) = pure False
+
+{- Adds a limit to skip files not believed to be present
+ - in a specified repository. Optionally on a prior date. -}
+addIn :: String -> Annex ()
+addIn s = do
+	u <- Remote.nameToUUID name
+	hereu <- getUUID
+	addLimit $ if u == hereu && null date
+		then use True checkinhere
+		else use False (checkinuuid u)
+  where
+	(name, date) = separate (== '@') s
+	use inhere a = Right $ MatchFiles
+		{ matchAction = checkKey . a
+		, matchNeedsFileName = False
+		, matchNeedsFileContent = False
+		, matchNeedsKey = True
+		, matchNeedsLocationLog = not inhere
+		, matchDesc = "in" =? s
+		}
+	checkinuuid u notpresent key
+		| null date = do
+			us <- Remote.keyLocations key
+			return $ u `elem` us && u `S.notMember` notpresent
+		| otherwise = do
+			us <- loggedLocationsHistorical (RefDate date) key
+			return $ u `elem` us
+	checkinhere notpresent key
+		| S.null notpresent = inAnnex key
+		| otherwise = do
+			u <- getUUID
+			if u `S.member` notpresent
+				then return False
+				else inAnnex key
+
+{- Limit to content that location tracking expects to be present
+ - in the current repository. Does not verify inAnnex. -}
+addExpectedPresent :: Annex ()
+addExpectedPresent = do
+	hereu <- getUUID
+	addLimit $ Right $ MatchFiles
+		{ matchAction = const $ checkKey $ \key -> do
+			us <- Remote.keyLocations key
+			return $ hereu `elem` us
+		, matchNeedsFileName = False
+		, matchNeedsFileContent = False
+		, matchNeedsKey = True
+		, matchNeedsLocationLog = True
+		, matchDesc = matchDescSimple "expected-present"
+		}
+
+{- Limit to content that is currently present on a uuid. -}
+limitPresent :: Maybe UUID -> MatchFiles Annex
+limitPresent u = MatchFiles
+	{ matchAction = const $ checkKey $ \key -> do
+		hereu <- getUUID
+		if u == Just hereu || isNothing u
+			then inAnnex key
+			else do
+				us <- Remote.keyLocations key
+				return $ maybe False (`elem` us) u
+	, matchNeedsFileName = False
+	, matchNeedsFileContent = False
+	, matchNeedsKey = True
+	, matchNeedsLocationLog = not (isNothing u)
+	, matchDesc = matchDescSimple "present"
+	}
+
+{- Limit to content that is in a directory, anywhere in the repository tree -}
+limitInDir :: FilePath -> String -> MatchFiles Annex
+limitInDir dir desc = MatchFiles 
+	{ matchAction = const go
+	, matchNeedsFileName = True
+	, matchNeedsFileContent = False
+	, matchNeedsKey = False
+	, matchNeedsLocationLog = False
+	, matchDesc = matchDescSimple desc
+	}
+  where
+	go (MatchingFile fi) = checkf $ fromRawFilePath $ matchFile fi
+	go (MatchingInfo p) = maybe (pure False) (checkf . fromRawFilePath) (providedFilePath p)
+	go (MatchingUserInfo p) = checkf =<< getUserInfo (userProvidedFilePath p)
+	checkf = return . elem dir . splitPath . takeDirectory
+
+{- Adds a limit to skip files not believed to have the specified number
+ - of copies. -}
+addCopies :: String -> Annex ()
+addCopies = addLimit . limitCopies
+
+limitCopies :: MkLimit Annex
+limitCopies want = case splitc ':' want of
+	-- Note that in case of a group having the same name as a trust
+	-- level, it's parsed as a trust level, not as a group.
+	[v, n] -> case parsetrustspec v of
+		Just checker -> go n $ checktrust checker
+		Nothing -> go n $ checkgroup (toGroup v)
+	[n] -> go n $ const $ return True
+	_ -> Left "bad value for copies"
+  where
+	go num good = case readish num of
+		Nothing -> Left "bad number for copies"
+		Just n -> Right $ MatchFiles
+			{ matchAction = \notpresent -> checkKey $
+				go' n good notpresent
+			, matchNeedsFileName = False
+			, matchNeedsFileContent = False
+			, matchNeedsKey = True
+			, matchNeedsLocationLog = True
+			, matchDesc = "copies" =? want
+			}
+	go' n good notpresent key = do
+		us <- filter (`S.notMember` notpresent)
+			<$> (filterM good =<< Remote.keyLocations key)
+		return $ length us >= n
+	checktrust checker u = checker <$> lookupTrust u
+	checkgroup g u = S.member g <$> lookupGroups u
+	parsetrustspec s
+		| "+" `isSuffixOf` s = (<=) <$> readTrustLevel (beginning s)
+		| otherwise = (==) <$> readTrustLevel s
+
+{- Adds a limit to match files that need more copies made. -}
+addLackingCopies :: String -> Bool -> String -> Annex ()
+addLackingCopies desc approx = addLimit . limitLackingCopies desc approx
+
+limitLackingCopies :: String -> Bool -> MkLimit Annex
+limitLackingCopies desc approx want = case readish want of
+	Just needed -> Right $ MatchFiles
+		{ matchAction = \notpresent mi -> flip checkKey mi $
+			go mi needed notpresent
+		, matchNeedsFileName = False
+		, matchNeedsFileContent = False
+		, matchNeedsKey = True
+		, matchNeedsLocationLog = True
+		, matchDesc = matchDescSimple desc
+		}
+	Nothing -> Left "bad value for number of lacking copies"
+  where
+	go mi needed notpresent key = do
+		numcopies <- if approx
+			then approxNumCopies
+			else case mi of
+				MatchingFile fi -> getGlobalFileNumCopies $
+					matchFile fi
+				MatchingInfo {} -> approxNumCopies
+				MatchingUserInfo {} -> approxNumCopies
+		us <- filter (`S.notMember` notpresent)
+			<$> (trustExclude UnTrusted =<< Remote.keyLocations key)
+		return $ fromNumCopies numcopies - length us >= needed
+	approxNumCopies = fromMaybe defaultNumCopies <$> getGlobalNumCopies
+
+{- Match keys that are unused.
+ - 
+ - This has a nice optimisation: When a file exists,
+ - its key is obviously not unused.
+ -}
+limitUnused :: MatchFiles Annex
+limitUnused = MatchFiles
+	{ matchAction = go
+	, matchNeedsFileName = True
+	, matchNeedsFileContent = False
+	, matchNeedsKey = True
+	, matchNeedsLocationLog = False
+	, matchDesc = matchDescSimple "unused"
+	}
+  where
+ 	go _ (MatchingFile _) = return False
+	go _ (MatchingInfo p) = maybe (pure False) isunused (providedKey p)
+	go _ (MatchingUserInfo p) = do
+		k <- getUserInfo (userProvidedKey p)
+		isunused k
+	
+	isunused k = S.member k <$> unusedKeys
+
+{- Adds a limit that matches anything. -}
+addAnything :: Annex ()
+addAnything = addLimit (Right limitAnything)
+
+{- Limit that matches any version of any file or key. -}
+limitAnything :: MatchFiles Annex
+limitAnything = MatchFiles
+	{ matchAction = \_ _ -> return True
+	, matchNeedsFileName = False
+	, matchNeedsFileContent = False
+	, matchNeedsKey = False
+	, matchNeedsLocationLog = False
+	, matchDesc = matchDescSimple "anything"
+	}
+
+{- Adds a limit that never matches. -}
+addNothing :: Annex ()
+addNothing = addLimit (Right limitNothing)
+
+{- Limit that never matches. -}
+limitNothing :: MatchFiles Annex
+limitNothing = MatchFiles 
+	{ matchAction = \_ _ -> return False
+	, matchNeedsFileName = False
+	, matchNeedsFileContent = False
+	, matchNeedsKey = False
+	, matchNeedsLocationLog = False
+	, matchDesc = matchDescSimple "nothing"
+	}
+
+{- Adds a limit to skip files not believed to be present in all
+ - repositories in the specified group. -}
+addInAllGroup :: String -> Annex ()
+addInAllGroup groupname = addLimit $ limitInAllGroup groupMap groupname
+
+limitInAllGroup :: Annex GroupMap -> MkLimit Annex
+limitInAllGroup getgroupmap groupname = Right $ MatchFiles
+	{ matchAction = \notpresent mi -> do
+		m <- getgroupmap
+		let want = fromMaybe S.empty $ M.lookup (toGroup groupname) $ uuidsByGroup m
+		if S.null want
+			then return True
+			-- optimisation: Check if a wanted uuid is notpresent.
+			else if not (S.null (S.intersection want notpresent))
+				then return False
+				else checkKey (check want) mi
+	, matchNeedsFileName = False
+	, matchNeedsFileContent = False
+	, matchNeedsKey = True
+	, matchNeedsLocationLog = True
+	, matchDesc = "inallgroup" =? groupname
+	}
+  where
+	check want key = do
+		present <- S.fromList <$> Remote.keyLocations key
+		return $ S.null $ want `S.difference` present
+
+{- Skip files unless they are present in at least one repository that is in
+ - the specified group, and are not present in any repositories that are not
+ - in the specified group. -}
+addOnlyInGroup :: String -> Annex ()
+addOnlyInGroup groupname = addLimit $ limitOnlyInGroup groupMap groupname
+
+limitOnlyInGroup :: Annex GroupMap -> MkLimit Annex
+limitOnlyInGroup getgroupmap groupname = Right $ MatchFiles
+	{ matchAction = \notpresent mi -> do
+		m <- getgroupmap
+		let want = fromMaybe S.empty $ M.lookup (toGroup groupname) $ uuidsByGroup m
+		if S.null want
+			then return False
+			else checkKey (check notpresent want) mi
+	, matchNeedsFileName = False
+	, matchNeedsFileContent = False
+	, matchNeedsKey = True
+	, matchNeedsLocationLog = True
+	, matchDesc = "inallgroup" =? groupname
+	}
+  where
+	check notpresent want key = do
+		locs <- S.fromList <$> Remote.keyLocations key
+		let present = locs `S.difference` notpresent
+		return $ not (S.null $ present `S.intersection` want)
+			&& S.null (S.filter (`S.notMember` want) present)
+
+{- Adds a limit to skip files not using a specified key-value backend. -}
+addInBackend :: String -> Annex ()
+addInBackend = addLimit . limitInBackend
+
+limitInBackend :: MkLimit Annex
+limitInBackend name = Right $ MatchFiles
+	{ matchAction = const $ checkKey check
+	, matchNeedsFileName = False
+	, matchNeedsFileContent = False
+	, matchNeedsKey = True
+	, matchNeedsLocationLog = False
+	, matchDesc = "inbackend" =? name
+	}
+  where
+	check key = pure $ fromKey keyVariety key == variety
+	variety = parseKeyVariety (encodeBS name)
+
+{- Adds a limit to skip files not using a secure hash. -}
+addSecureHash :: Annex ()
+addSecureHash = addLimit $ Right limitSecureHash
+
+limitSecureHash :: MatchFiles Annex
+limitSecureHash = MatchFiles
+	{ matchAction = const $ checkKey isCryptographicallySecureKey
+	, matchNeedsFileName = False
+	, matchNeedsFileContent = False
+	, matchNeedsKey = True
+	, matchNeedsLocationLog = False
+	, matchDesc = matchDescSimple "securehash"
+	}
+
+{- Adds a limit to skip files that are too large or too small -}
+addLargerThan :: LimitBy -> String -> Annex ()
+addLargerThan lb = addLimit . limitSize lb "smallerthan" (>)
+
+addSmallerThan :: LimitBy -> String -> Annex ()
+addSmallerThan lb = addLimit . limitSize lb "smallerthan" (<)
+
+limitSize :: LimitBy -> String -> (Maybe Integer -> Maybe Integer -> Bool) -> MkLimit Annex
+limitSize lb desc vs s = case readSize dataUnits s of
+	Nothing -> Left "bad size"
+	Just sz -> Right $ MatchFiles
+		{ matchAction = go sz
+		, matchNeedsFileName = case lb of
+			LimitAnnexFiles -> False
+			LimitDiskFiles -> True
+		, matchNeedsFileContent = False
+		, matchNeedsKey = False
+		, matchNeedsLocationLog = False
+		, matchDesc = desc =? s
+		}
+  where
+	go sz _ (MatchingFile fi) = case lb of
+		LimitAnnexFiles -> lookupFileKey fi >>= \case
+			Just key -> checkkey sz key
+			Nothing -> return False
+		LimitDiskFiles -> do
+			filesize <- liftIO $ catchMaybeIO $ getFileSize (contentFile fi)
+			return $ filesize `vs` Just sz
+	go sz _ (MatchingInfo p) = case providedFileSize p of
+		Just sz' -> pure (Just sz' `vs` Just sz)
+		Nothing -> maybe (pure False) (checkkey sz) (providedKey p)
+	go sz _ (MatchingUserInfo p) =
+		getUserInfo (userProvidedFileSize p) 
+			>>= \sz' -> return (Just sz' `vs` Just sz)
+	checkkey sz key = return $ fromKey keySize key `vs` Just sz
+
+addMetaData :: String -> Annex ()
+addMetaData = addLimit . limitMetaData
+
+limitMetaData :: MkLimit Annex
+limitMetaData s = case parseMetaDataMatcher s of
+	Left e -> Left e
+	Right (f, matching) -> Right $ MatchFiles
+		{ matchAction = const $ checkKey (check f matching)
+		, matchNeedsFileName = False
+		, matchNeedsFileContent = False
+		, matchNeedsKey = True
+		, matchNeedsLocationLog = False
+		, matchDesc = "metadata" =? s
+		}
+  where
+	check f matching k = not . S.null 
+		. S.filter matching
+		. metaDataValues f <$> getCurrentMetaData k
+
+addAccessedWithin :: Duration -> Annex ()
+addAccessedWithin duration = do
+	now <- liftIO getPOSIXTime
+	addLimit $ Right $ MatchFiles
+		{ matchAction = const $ checkKey $ check now
+		, matchNeedsFileName = False
+		, matchNeedsFileContent = False
+		, matchNeedsKey = False
+		, matchNeedsLocationLog = False
+		, matchDesc = "accessedwithin" =? fromDuration duration
+		}
+  where
+	check now k = inAnnexCheck k $ \f ->
+		liftIO $ catchDefaultIO False $ do
+			s <- R.getSymbolicLinkStatus f
+			let accessed = realToFrac (accessTime s)
+			let delta = now - accessed
+			return $ delta <= secs
+	secs = fromIntegral (durationSeconds duration)
+
+lookupFileKey :: FileInfo -> Annex (Maybe Key)
+lookupFileKey fi = case matchKey fi of
+	Just k -> return (Just k)
+	Nothing -> lookupKey (contentFile fi)
+
+checkKey :: (Key -> Annex Bool) -> MatchInfo -> Annex Bool
+checkKey a (MatchingFile fi) = lookupFileKey fi >>= maybe (return False) a
+checkKey a (MatchingInfo p) = maybe (return False) a (providedKey p)
+checkKey a (MatchingUserInfo p) = a =<< getUserInfo (userProvidedKey p)
+
+matchDescSimple :: String -> (Bool -> Utility.Matcher.MatchDesc)
+matchDescSimple s b = Utility.Matcher.MatchDesc $ s ++
+	if b then "[TRUE]" else "[FALSE]"
+
+(=?) :: String -> String -> (Bool -> Utility.Matcher.MatchDesc)
+k =? v = matchDescSimple (k ++ "=" ++ v)
diff --git a/Limit/Wanted.hs b/Limit/Wanted.hs
new file mode 100644
index 0000000000..8b546a3e0e
--- /dev/null
+++ b/Limit/Wanted.hs
@@ -0,0 +1,55 @@
+{- git-annex limits by wanted status
+ -
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Limit.Wanted where
+
+import Annex.Common
+import Annex.Wanted
+import Limit
+import Types.FileMatcher
+import Logs.PreferredContent
+import qualified Remote
+
+addWantGet :: Annex ()
+addWantGet = addPreferredContentLimit "want-get" $
+	checkWant $ wantGet False Nothing
+
+addWantGetBy :: String -> Annex ()
+addWantGetBy name = do
+	u <- Remote.nameToUUID name
+	addPreferredContentLimit "want-get-by" $ checkWant $ \af ->
+		wantGetBy False Nothing af u
+
+addWantDrop :: Annex ()
+addWantDrop = addPreferredContentLimit "want-drop" $ checkWant $ \af ->
+	wantDrop False Nothing Nothing af (Just [])
+
+addWantDropBy :: String -> Annex ()
+addWantDropBy name = do
+	u <- Remote.nameToUUID name
+	addPreferredContentLimit "want-drop-by" $ checkWant $ \af ->
+		wantDrop False (Just u) Nothing af (Just [])
+
+addPreferredContentLimit :: String -> (MatchInfo -> Annex Bool) -> Annex ()
+addPreferredContentLimit desc a = do
+	nfn <- introspectPreferredRequiredContent matchNeedsFileName Nothing
+	nfc <- introspectPreferredRequiredContent matchNeedsFileContent Nothing
+	nk <- introspectPreferredRequiredContent matchNeedsKey Nothing
+	nl <- introspectPreferredRequiredContent matchNeedsLocationLog Nothing
+	addLimit $ Right $ MatchFiles
+		{ matchAction = const a
+		, matchNeedsFileName = nfn
+		, matchNeedsFileContent = nfc
+		, matchNeedsKey = nk
+		, matchNeedsLocationLog = nl
+		, matchDesc = matchDescSimple desc
+		}
+
+checkWant :: (AssociatedFile -> Annex Bool) -> MatchInfo -> Annex Bool
+checkWant a (MatchingFile fi) = a (AssociatedFile (Just $ matchFile fi))
+checkWant a (MatchingInfo p) = a (AssociatedFile (providedFilePath p))
+checkWant _ (MatchingUserInfo {}) = return False
diff --git a/Logs.hs b/Logs.hs
new file mode 100644
index 0000000000..5e8daf5d0a
--- /dev/null
+++ b/Logs.hs
@@ -0,0 +1,291 @@
+{- git-annex log file names
+ -
+ - Copyright 2013-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Logs where
+
+import Annex.Common
+import Annex.DirHashes
+
+import qualified Data.ByteString as S
+import qualified System.FilePath.ByteString as P
+
+{- There are several varieties of log file formats. -}
+data LogVariety
+	= OldUUIDBasedLog
+	| NewUUIDBasedLog
+	| ChunkLog Key
+	| LocationLog Key
+	| UrlLog Key
+	| RemoteMetaDataLog
+	| OtherLog
+	deriving (Show)
+
+{- Converts a path from the git-annex branch into one of the varieties
+ - of logs used by git-annex, if it's a known path. -}
+getLogVariety :: GitConfig -> RawFilePath -> Maybe LogVariety
+getLogVariety config f
+	| f `elem` topLevelOldUUIDBasedLogs = Just OldUUIDBasedLog
+	| f `elem` topLevelNewUUIDBasedLogs = Just NewUUIDBasedLog
+	| isRemoteStateLog f = Just NewUUIDBasedLog
+	| isRemoteContentIdentifierLog f = Just NewUUIDBasedLog
+	| isRemoteMetaDataLog f = Just RemoteMetaDataLog
+	| isMetaDataLog f
+		|| f `elem` otherTopLevelLogs
+		|| isEquivilantKeyLog f = Just OtherLog
+	| otherwise = (LocationLog <$> locationLogFileKey config f)
+		<|> (ChunkLog <$> extLogFileKey chunkLogExt f)
+		<|> (UrlLog  <$> urlLogFileKey f)
+
+{- Typical number of log files that may be read while processing a single
+ - key. This is used to size a cache.
+ -
+ - The location log is generally read, and the metadata log is read when
+ - matching a preferred content expression that matches on metadata,
+ - or when using metadata options.
+ -
+ - When using a remote, the url log, chunk log, remote state log, remote
+ - metadata log, and remote content identifier log might each be used,
+ - but probably at most 3 out of the 6. However, caching too much slows
+ - down all operations because the cache is a linear list, so the cache
+ - is not currently sized to include these.
+ -
+ - The result is that when seeking for files to operate on,
+ - the location log will stay in the cache if the metadata log is also
+ - read.
+ -}
+logFilesToCache :: Int
+logFilesToCache = 2
+
+{- All the log files that might contain information about a key. -}
+keyLogFiles :: GitConfig -> Key -> [RawFilePath]
+keyLogFiles config k = 
+	[ locationLogFile config k
+	, urlLogFile config k
+	, remoteStateLogFile config k
+	, metaDataLogFile config k
+	, remoteMetaDataLogFile config k
+	, remoteContentIdentifierLogFile config k
+	, chunkLogFile config k
+	, equivilantKeysLogFile config k
+	] ++ oldurlLogs config k
+
+{- All uuid-based logs stored in the top of the git-annex branch. -}
+topLevelUUIDBasedLogs :: [RawFilePath]
+topLevelUUIDBasedLogs = topLevelNewUUIDBasedLogs ++ topLevelOldUUIDBasedLogs
+
+{- All the old-format uuid-based logs stored in the top of the git-annex branch. -}
+topLevelOldUUIDBasedLogs :: [RawFilePath]
+topLevelOldUUIDBasedLogs =
+	[ uuidLog
+	, remoteLog
+	, trustLog
+	, groupLog 
+	, preferredContentLog
+	, requiredContentLog
+	, scheduleLog
+	, activityLog
+	, differenceLog
+	, multicastLog
+	]
+
+{- All the new-format uuid-based logs stored in the top of the git-annex branch. -}
+topLevelNewUUIDBasedLogs :: [RawFilePath]
+topLevelNewUUIDBasedLogs =
+	[ exportLog
+	]
+
+{- Other top-level logs. -}
+otherTopLevelLogs :: [RawFilePath]
+otherTopLevelLogs =
+	[ numcopiesLog
+	, mincopiesLog
+	, configLog
+	, groupPreferredContentLog
+	]
+
+uuidLog :: RawFilePath
+uuidLog = "uuid.log"
+
+numcopiesLog :: RawFilePath
+numcopiesLog = "numcopies.log"
+
+mincopiesLog :: RawFilePath
+mincopiesLog = "mincopies.log"
+
+configLog :: RawFilePath
+configLog = "config.log"
+
+remoteLog :: RawFilePath
+remoteLog = "remote.log"
+
+trustLog :: RawFilePath
+trustLog = "trust.log"
+
+groupLog :: RawFilePath
+groupLog = "group.log"
+
+preferredContentLog :: RawFilePath
+preferredContentLog = "preferred-content.log"
+
+requiredContentLog :: RawFilePath
+requiredContentLog = "required-content.log"
+
+groupPreferredContentLog :: RawFilePath
+groupPreferredContentLog = "group-preferred-content.log"
+
+scheduleLog :: RawFilePath
+scheduleLog = "schedule.log"
+
+activityLog :: RawFilePath
+activityLog = "activity.log"
+
+differenceLog :: RawFilePath
+differenceLog = "difference.log"
+
+multicastLog :: RawFilePath
+multicastLog = "multicast.log"
+
+exportLog :: RawFilePath
+exportLog = "export.log"
+
+{- This is not a log file, it's where exported treeishes get grafted into
+ - the git-annex branch. -}
+exportTreeGraftPoint :: RawFilePath
+exportTreeGraftPoint = "export.tree"
+
+{- This is not a log file, it's where migration treeishes get grafted into
+ - the git-annex branch. -}
+migrationTreeGraftPoint :: RawFilePath
+migrationTreeGraftPoint = "migrate.tree"
+
+{- The pathname of the location log file for a given key. -}
+locationLogFile :: GitConfig -> Key -> RawFilePath
+locationLogFile config key =
+	branchHashDir config key P.</> keyFile key <> ".log"
+
+{- The filename of the url log for a given key. -}
+urlLogFile :: GitConfig -> Key -> RawFilePath
+urlLogFile config key = 
+	branchHashDir config key P.</> keyFile key <> urlLogExt
+
+{- Old versions stored the urls elsewhere. -}
+oldurlLogs :: GitConfig -> Key -> [RawFilePath]
+oldurlLogs config key =
+	[ "remote/web" P.</> hdir P.</> serializeKey' key <> ".log"
+	, "remote/web" P.</> hdir P.</> keyFile key <> ".log"
+	]
+  where
+	hdir = branchHashDir config key
+
+urlLogExt :: S.ByteString
+urlLogExt = ".log.web"
+
+{- Does not work on oldurllogs. -}
+isUrlLog :: RawFilePath -> Bool
+isUrlLog file = urlLogExt `S.isSuffixOf` file
+
+{- The filename of the remote state log for a given key. -}
+remoteStateLogFile :: GitConfig -> Key -> RawFilePath
+remoteStateLogFile config key = 
+	(branchHashDir config key P.</> keyFile key)
+		<> remoteStateLogExt
+
+remoteStateLogExt :: S.ByteString
+remoteStateLogExt = ".log.rmt"
+
+isRemoteStateLog :: RawFilePath -> Bool
+isRemoteStateLog path = remoteStateLogExt `S.isSuffixOf` path
+
+{- The filename of the chunk log for a given key. -}
+chunkLogFile :: GitConfig -> Key -> RawFilePath
+chunkLogFile config key = 
+	(branchHashDir config key P.</> keyFile key)
+		<> chunkLogExt
+
+chunkLogExt :: S.ByteString
+chunkLogExt = ".log.cnk"
+
+{- The filename of the equivilant keys log for a given key. -}
+equivilantKeysLogFile :: GitConfig -> Key -> RawFilePath
+equivilantKeysLogFile config key = 
+	(branchHashDir config key P.</> keyFile key)
+		<> equivilantKeyLogExt
+
+equivilantKeyLogExt :: S.ByteString
+equivilantKeyLogExt = ".log.ek"
+
+isEquivilantKeyLog :: RawFilePath -> Bool
+isEquivilantKeyLog path = equivilantKeyLogExt `S.isSuffixOf` path
+
+{- The filename of the metadata log for a given key. -}
+metaDataLogFile :: GitConfig -> Key -> RawFilePath
+metaDataLogFile config key =
+	(branchHashDir config key P.</> keyFile key)
+		<> metaDataLogExt
+
+metaDataLogExt :: S.ByteString
+metaDataLogExt = ".log.met"
+
+isMetaDataLog :: RawFilePath -> Bool
+isMetaDataLog path = metaDataLogExt `S.isSuffixOf` path
+
+{- The filename of the remote metadata log for a given key. -}
+remoteMetaDataLogFile :: GitConfig -> Key -> RawFilePath
+remoteMetaDataLogFile config key = 
+	(branchHashDir config key P.</> keyFile key)
+		<> remoteMetaDataLogExt
+
+remoteMetaDataLogExt :: S.ByteString
+remoteMetaDataLogExt = ".log.rmet"
+
+isRemoteMetaDataLog :: RawFilePath -> Bool
+isRemoteMetaDataLog path = remoteMetaDataLogExt `S.isSuffixOf` path
+
+{- The filename of the remote content identifier log for a given key. -}
+remoteContentIdentifierLogFile :: GitConfig -> Key -> RawFilePath
+remoteContentIdentifierLogFile config key =
+	(branchHashDir config key P.</> keyFile key)
+		<> remoteContentIdentifierExt
+
+remoteContentIdentifierExt :: S.ByteString
+remoteContentIdentifierExt = ".log.cid"
+
+isRemoteContentIdentifierLog :: RawFilePath -> Bool
+isRemoteContentIdentifierLog path = remoteContentIdentifierExt `S.isSuffixOf` path
+
+{- From an extension and a log filename, get the key that it's a log for. -}
+extLogFileKey :: S.ByteString -> RawFilePath -> Maybe Key
+extLogFileKey expectedext path
+	| ext == expectedext = fileKey base
+	| otherwise = Nothing
+  where
+	file = P.takeFileName path
+	(base, ext) = S.splitAt (S.length file - extlen) file
+	extlen = S.length expectedext
+
+{- Converts a url log file into a key.
+ - (Does not work on oldurlLogs.) -}
+urlLogFileKey :: RawFilePath -> Maybe Key
+urlLogFileKey = extLogFileKey urlLogExt
+
+{- Converts a pathname into a key if it's a location log. -}
+locationLogFileKey :: GitConfig -> RawFilePath -> Maybe Key
+locationLogFileKey config path
+	| length (splitDirectories (fromRawFilePath path)) /= locationLogFileDepth config = Nothing
+	| otherwise = extLogFileKey ".log" path
+
+{- Depth of location log files within the git-annex branch.
+ -
+ - Normally they are xx/yy/key.log so depth 3. 
+ - The same extension is also used for other logs that
+ - are not location logs. -}
+locationLogFileDepth :: GitConfig -> Int
+locationLogFileDepth config = hashlevels + 1
+  where
+        HashLevels hashlevels = branchHashLevels config
diff --git a/Logs/Activity.hs b/Logs/Activity.hs
new file mode 100644
index 0000000000..d527d26694
--- /dev/null
+++ b/Logs/Activity.hs
@@ -0,0 +1,61 @@
+{- git-annex activity log
+ -
+ - Copyright 2015-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Activity (
+	Log,
+	Activity(..),
+	allActivities,
+	recordActivity,
+	lastActivities,
+) where
+
+import Annex.Common
+import qualified Annex.Branch
+import Logs
+import Logs.UUIDBased
+
+import qualified Data.ByteString as S
+import qualified Data.Attoparsec.ByteString as A
+import Data.ByteString.Builder
+
+data Activity 
+	= Fsck
+	-- Allow for unknown activities to be added later.
+	| UnknownActivity S.ByteString
+	deriving (Eq, Read, Show)
+
+allActivities :: [Activity]
+allActivities = [Fsck]
+
+-- Record an activity. This takes the place of previously recorded activity
+-- for the UUID.
+recordActivity :: Activity -> UUID -> Annex ()
+recordActivity act uuid = do
+	c <- currentVectorClock
+	Annex.Branch.change (Annex.Branch.RegardingUUID [uuid]) activityLog $
+		buildLogOld buildActivity
+			. changeLog c uuid act
+			. parseLogOld parseActivity
+
+-- Most recent activity for each UUID.
+lastActivities :: Maybe Activity -> Annex (Log Activity)
+lastActivities wantact = parseLogOld (onlywanted =<< parseActivity)
+	<$> Annex.Branch.get activityLog
+  where
+	onlywanted a 
+		| wanted a = pure a
+		| otherwise = fail "unwanted activity"
+	wanted a = maybe True (a ==) wantact
+
+buildActivity :: Activity -> Builder
+buildActivity (UnknownActivity b) = byteString b
+buildActivity a = byteString $ encodeBS $ show a
+
+parseActivity :: A.Parser Activity
+parseActivity = go <$> A.takeByteString
+  where
+	go b = fromMaybe (UnknownActivity b) (readish $ decodeBS b)
diff --git a/Logs/AdjustedBranchUpdate.hs b/Logs/AdjustedBranchUpdate.hs
new file mode 100644
index 0000000000..c7f2822945
--- /dev/null
+++ b/Logs/AdjustedBranchUpdate.hs
@@ -0,0 +1,84 @@
+{- git-annex log file that indicates when the adjusted branch needs to be
+ - updated due to changes in content availability.
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Logs.AdjustedBranchUpdate (
+	recordAdjustedBranchUpdateNeeded,
+	recordAdjustedBranchUpdateFinished,
+	isAdjustedBranchUpdateNeeded,
+) where
+
+import Annex.Common
+import Logs.File
+import Utility.TimeStamp
+
+import qualified Data.ByteString.Lazy as L
+import Data.Time.Clock.POSIX
+
+-- | Updates the log to indicate that an update is needed.
+recordAdjustedBranchUpdateNeeded :: Annex ()
+recordAdjustedBranchUpdateNeeded = do
+	now <- liftIO getPOSIXTime
+	logf <- fromRepo gitAnnexAdjustedBranchUpdateLog
+	lckf <- fromRepo gitAnnexAdjustedBranchUpdateLock
+	-- Replace any other log entries, because an update is needed now,
+	-- so an entry that says an update finished must be in the past.
+	-- And, if there were clock skew, an entry that says an update is
+	-- needed in the future would be wrong information.
+	modifyLogFile logf lckf (const [formatAdjustLog True now])
+
+-- | Called after an update has finished. The time is when the update
+-- started. If recordAdjustedBranchUpdateNeeded was called during the
+-- update, the log is left indicating that an update is still needed.
+recordAdjustedBranchUpdateFinished :: POSIXTime -> Annex ()
+recordAdjustedBranchUpdateFinished starttime = do
+	now <- liftIO getPOSIXTime
+	logf <- fromRepo gitAnnexAdjustedBranchUpdateLog
+	lckf <- fromRepo gitAnnexAdjustedBranchUpdateLock
+	modifyLogFile logf lckf (go now)
+  where
+	go now logged
+		| null $ filter (isnewer now) $ mapMaybe parseAdjustLog logged =
+			[formatAdjustLog False starttime]
+		| otherwise = logged
+	
+	-- If the logged time is in the future, there was clock skew,
+	-- so disregard that log entry.
+	isnewer now (_, loggedtime) = 
+		loggedtime >= starttime && loggedtime <= now
+
+isAdjustedBranchUpdateNeeded :: Annex Bool
+isAdjustedBranchUpdateNeeded = do
+	logf <- fromRepo gitAnnexAdjustedBranchUpdateLog
+	lckf <- fromRepo gitAnnexAdjustedBranchUpdateLock
+	calcLogFile logf lckf Nothing go >>= return . \case
+		Just b -> b
+		-- No log, so assume an update is needed.
+		-- This handles upgrades from before this log was written.
+		Nothing -> True
+  where
+ 	go l p = case parseAdjustLog l of
+		Nothing -> p
+		Just (b, _t) -> case p of
+			Nothing -> Just b
+			Just b' -> Just (b' || b)
+
+formatAdjustLog :: Bool -> POSIXTime -> L.ByteString
+formatAdjustLog b t = encodeBL (show t) <> " " <> if b then "1" else "0"
+
+parseAdjustLog :: L.ByteString -> Maybe (Bool, POSIXTime)
+parseAdjustLog l = 
+	let (ts, bs) = separate (== ' ') (decodeBL l)
+	in do
+		b <- case bs of
+			"1" -> Just True
+			"0" -> Just False
+			_ -> Nothing
+		t <- parsePOSIXTime ts
+		return (b, t)
diff --git a/Logs/Chunk.hs b/Logs/Chunk.hs
new file mode 100644
index 0000000000..5405e72203
--- /dev/null
+++ b/Logs/Chunk.hs
@@ -0,0 +1,57 @@
+{- Chunk logs.
+ -
+ - An object can be stored in chunked for on a remote; these logs keep
+ - track of the chunk size used, and the number of chunks.
+ -
+ - It's possible for a single object to be stored multiple times on the
+ - same remote using different chunk sizes. So, while this is a MapLog, it
+ - is not a normal UUIDBased log. Instead, it's a map from UUID and chunk
+ - size to number of chunks.
+ -
+ - Format: "timestamp uuid:chunksize chunkcount"
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Chunk (
+	ChunkMethod(..),
+	ChunkSize,
+	ChunkCount,
+	chunksStored,
+	chunksRemoved,
+	getCurrentChunks,
+) where
+
+import Annex.Common
+import Logs
+import Logs.MapLog
+import qualified Annex.Branch
+import Logs.Chunk.Pure
+import qualified Annex
+
+import qualified Data.Map as M
+
+chunksStored :: UUID -> Key -> ChunkMethod -> ChunkCount -> Annex ()
+chunksStored u k chunkmethod chunkcount = do
+	c <- currentVectorClock
+	config <- Annex.getGitConfig
+	Annex.Branch.change
+		(Annex.Branch.RegardingUUID [u])
+		(chunkLogFile config k)
+		(buildLog . changeMapLog c (u, chunkmethod) chunkcount . parseLog)
+
+chunksRemoved :: UUID -> Key -> ChunkMethod -> Annex ()
+chunksRemoved u k chunkmethod = chunksStored u k chunkmethod 0
+
+getCurrentChunks :: UUID -> Key -> Annex [(ChunkMethod, ChunkCount)]
+getCurrentChunks u k = do
+	config <- Annex.getGitConfig
+	select . parseLog <$> Annex.Branch.get (chunkLogFile config k)
+  where
+	select = filter (\(_m, ct) -> ct > 0)
+		. map (\((_ku, m), l) -> (m, value l))
+		. M.toList
+		. M.filterWithKey (\(ku, _m) _ -> ku == u)
+		. fromMapLog
diff --git a/Logs/Chunk/Pure.hs b/Logs/Chunk/Pure.hs
new file mode 100644
index 0000000000..0870f461ae
--- /dev/null
+++ b/Logs/Chunk/Pure.hs
@@ -0,0 +1,62 @@
+{- Chunk logs, pure operations.
+ -
+ - Copyright 2014, 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Chunk.Pure 
+	( ChunkMethod(..)
+	, ChunkSize
+	, ChunkCount
+	, ChunkLog
+	, parseLog
+	, buildLog
+	) where
+
+import Annex.Common
+import Logs.MapLog
+import Data.Int
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+import Data.ByteString.Builder
+
+-- Currently chunks are all fixed size, but other chunking methods
+-- may be added.
+data ChunkMethod = FixedSizeChunks ChunkSize | UnknownChunks S.ByteString
+	deriving (Ord, Eq, Show)
+
+type ChunkSize = Int64
+
+-- 0 when chunks are no longer present
+type ChunkCount = Integer
+
+type ChunkLog = MapLog (UUID, ChunkMethod) ChunkCount
+
+buildChunkMethod :: ChunkMethod -> Builder
+buildChunkMethod (FixedSizeChunks sz) = int64Dec sz
+buildChunkMethod (UnknownChunks s) = byteString s
+
+chunkMethodParser :: A.Parser ChunkMethod
+chunkMethodParser =
+	(FixedSizeChunks <$> A8.decimal) <|> (UnknownChunks <$> A.takeByteString)
+
+buildLog :: ChunkLog -> Builder
+buildLog = buildMapLog fieldbuilder valuebuilder
+  where
+	fieldbuilder (u, m) = buildUUID u <> sep <> buildChunkMethod m
+	valuebuilder = integerDec
+	sep = charUtf8 ':'
+
+parseLog :: L.ByteString -> ChunkLog
+parseLog = parseMapLog fieldparser valueparser
+  where
+	fieldparser = (,)
+		<$> (toUUID <$> A8.takeTill (== ':'))
+		<* A8.char ':'
+		<*> chunkMethodParser
+		<* A.endOfInput
+	valueparser = A8.decimal
diff --git a/Logs/Config.hs b/Logs/Config.hs
new file mode 100644
index 0000000000..81beb52d73
--- /dev/null
+++ b/Logs/Config.hs
@@ -0,0 +1,73 @@
+{- git-annex repository-global config log
+ -
+ - Copyright 2017-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Config (
+	ConfigKey(..),
+	ConfigValue(..),
+	setGlobalConfig,
+	unsetGlobalConfig,
+	getGlobalConfig,
+	loadGlobalConfig,
+) where
+
+import Annex.Common
+import Logs
+import Logs.MapLog
+import qualified Annex.Branch
+import Git.Types (ConfigKey(..), ConfigValue(..))
+
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import Data.ByteString.Builder
+
+setGlobalConfig :: ConfigKey -> ConfigValue -> Annex ()
+setGlobalConfig name new = do
+	curr <- getGlobalConfig name
+	when (curr /= Just new) $
+		setGlobalConfig' name new
+
+setGlobalConfig' :: ConfigKey -> ConfigValue -> Annex ()
+setGlobalConfig' name new = do
+	c <- currentVectorClock
+	Annex.Branch.change (Annex.Branch.RegardingUUID []) configLog $ 
+		buildGlobalConfig . changeMapLog c name new . parseGlobalConfig
+
+unsetGlobalConfig :: ConfigKey -> Annex ()
+unsetGlobalConfig name = do
+	curr <- getGlobalConfig name
+	when (curr /= Nothing) $
+		-- set to empty string to unset
+		setGlobalConfig' name (ConfigValue mempty)
+
+-- Reads the global config log every time.
+-- It's more efficient to use Config.GitConfig.
+getGlobalConfig :: ConfigKey -> Annex (Maybe ConfigValue)
+getGlobalConfig name = M.lookup name <$> loadGlobalConfig
+
+buildGlobalConfig :: MapLog ConfigKey ConfigValue -> Builder
+buildGlobalConfig = buildMapLog configkeybuilder valuebuilder
+  where
+	configkeybuilder (ConfigKey k) = byteString k
+	valuebuilder (ConfigValue v) = byteString v
+	valuebuilder NoConfigValue = mempty
+
+parseGlobalConfig :: L.ByteString -> MapLog ConfigKey ConfigValue
+parseGlobalConfig = parseMapLog configkeyparser valueparser
+  where
+	configkeyparser = ConfigKey <$> A.takeByteString
+	valueparser = ConfigValue <$> A.takeByteString
+
+loadGlobalConfig :: Annex (M.Map ConfigKey ConfigValue)
+loadGlobalConfig = M.filter nonempty 
+	. simpleMap
+	. parseGlobalConfig
+	<$> Annex.Branch.get configLog
+  where
+	nonempty (ConfigValue v) = not (S.null v)
+	nonempty NoConfigValue = True
diff --git a/Logs/ContentIdentifier.hs b/Logs/ContentIdentifier.hs
new file mode 100644
index 0000000000..6448693ae7
--- /dev/null
+++ b/Logs/ContentIdentifier.hs
@@ -0,0 +1,54 @@
+{- Remote content identifier logs.
+ -
+ - Copyright 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.ContentIdentifier (
+	module X,
+	recordContentIdentifier,
+	getContentIdentifiers,
+) where
+
+import Annex.Common
+import Logs
+import Logs.MapLog
+import Types.Import
+import Types.RemoteState
+import qualified Annex.Branch
+import Logs.ContentIdentifier.Pure as X
+import qualified Annex
+
+import qualified Data.Map as M
+import Data.List.NonEmpty (NonEmpty(..))
+import qualified Data.List.NonEmpty as NonEmpty
+
+-- | Records a remote's content identifier and the key that it corresponds to.
+--
+-- A remote may use multiple content identifiers for the same key over time,
+-- so ones that were recorded before are preserved.
+recordContentIdentifier :: RemoteStateHandle -> ContentIdentifier -> Key -> Annex ()
+recordContentIdentifier (RemoteStateHandle u) cid k = do
+	c <- currentVectorClock
+	config <- Annex.getGitConfig
+	Annex.Branch.maybeChange
+		(Annex.Branch.RegardingUUID [u])
+		(remoteContentIdentifierLogFile config k)
+		(addcid c . parseLog)
+  where
+	addcid c v
+		| cid `elem` l = Nothing -- no change needed
+		| otherwise = Just $ buildLog $
+			changeMapLog c u (cid :| l) v
+	  where
+		m = simpleMap v
+		l = contentIdentifierList (M.lookup u m)
+
+-- | Get all known content identifiers for a key.
+getContentIdentifiers :: Key -> Annex [(RemoteStateHandle, [ContentIdentifier])]
+getContentIdentifiers k = do
+	config <- Annex.getGitConfig
+	map (\(u, l) -> (RemoteStateHandle u, NonEmpty.toList l) )
+		. M.toList . simpleMap . parseLog
+		<$> Annex.Branch.get (remoteContentIdentifierLogFile config k)
diff --git a/Logs/ContentIdentifier/Pure.hs b/Logs/ContentIdentifier/Pure.hs
new file mode 100644
index 0000000000..bea98f4091
--- /dev/null
+++ b/Logs/ContentIdentifier/Pure.hs
@@ -0,0 +1,75 @@
+{- Remote content identifier logs, pure operations.
+ -
+ - Copyright 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Logs.ContentIdentifier.Pure where
+
+import Annex.Common
+import Logs.UUIDBased
+import Types.Import
+import Utility.Base64
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString as A
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+import Data.ByteString.Builder
+import Data.List.NonEmpty (NonEmpty(..))
+import qualified Data.List.NonEmpty
+
+-- A ContentIdentifier can contain "", so to avoid ambiguity
+-- in parsing, the list of them in the log must be non-empty.
+type ContentIdentifierLog = Log (NonEmpty ContentIdentifier)
+
+contentIdentifierList :: Maybe (NonEmpty ContentIdentifier) -> [ContentIdentifier]
+contentIdentifierList (Just l) = Data.List.NonEmpty.toList l
+contentIdentifierList Nothing = []
+
+buildLog :: ContentIdentifierLog -> Builder
+buildLog = buildLogNew buildContentIdentifierList
+
+buildContentIdentifierList :: (NonEmpty ContentIdentifier) -> Builder
+buildContentIdentifierList l = case l of
+	c :| [] -> buildcid c
+	(c :| cs) -> go (c:cs)
+  where
+	buildcid (ContentIdentifier c)
+		| S8.any (`elem` [':', '\r', '\n']) c || "!" `S8.isPrefixOf` c =
+			charUtf8 '!' <> byteString (toB64 c)
+		| otherwise = byteString c
+	go [] = mempty
+	go (c:[]) = buildcid c
+	go (c:cs) = buildcid c <> charUtf8 ':' <> go cs
+
+parseLog :: L.ByteString -> ContentIdentifierLog
+parseLog = parseLogNew parseContentIdentifierList
+
+parseContentIdentifierList :: A.Parser (NonEmpty ContentIdentifier)
+parseContentIdentifierList = do
+	first <- cidparser
+	listparser first []
+  where
+	cidparser = do
+		b <- A8.takeWhile (/= ':')
+		return $ if "!" `S8.isPrefixOf` b
+			then ContentIdentifier $ fromMaybe b (fromB64Maybe (S.drop 1 b))
+			else ContentIdentifier b
+	listparser first rest = ifM A8.atEnd
+		( return (first :| reverse rest)
+		, do
+			_ <- A8.char ':'
+			cid <- cidparser
+			listparser first (cid:rest)
+		)
+
+prop_parse_build_contentidentifier_log :: NonEmpty ContentIdentifier -> Bool
+prop_parse_build_contentidentifier_log l =
+	let v = A.parseOnly parseContentIdentifierList $ L.toStrict $ 
+		toLazyByteString $ buildContentIdentifierList l
+	in v == Right l
diff --git a/Logs/Difference.hs b/Logs/Difference.hs
new file mode 100644
index 0000000000..de8b9f1a8f
--- /dev/null
+++ b/Logs/Difference.hs
@@ -0,0 +1,42 @@
+{- git-annex difference log
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Difference (
+	recordDifferences,
+	recordedDifferences,
+	recordedDifferencesFor,
+	module Logs.Difference.Pure
+) where
+
+import qualified Data.Map as M
+import qualified Data.Attoparsec.ByteString as A
+import Data.ByteString.Builder
+
+import Annex.Common
+import Types.Difference
+import qualified Annex.Branch
+import Logs
+import Logs.UUIDBased
+import Logs.Difference.Pure
+
+recordDifferences :: Differences -> UUID -> Annex ()
+recordDifferences ds@(Differences {}) uuid = do
+	c <- currentVectorClock
+	Annex.Branch.change (Annex.Branch.RegardingUUID [uuid]) differenceLog $
+		buildLogOld byteString 
+			. changeLog c uuid (encodeBS $ showDifferences ds) 
+			. parseLogOld A.takeByteString
+recordDifferences UnknownDifferences _ = return ()
+
+-- Map of UUIDs that have Differences recorded.
+-- If a new version of git-annex has added a Difference this version
+-- doesn't know about, it will contain UnknownDifferences.
+recordedDifferences :: Annex (M.Map UUID Differences)
+recordedDifferences = parseDifferencesLog <$> Annex.Branch.get differenceLog
+
+recordedDifferencesFor :: UUID -> Annex Differences
+recordedDifferencesFor u = fromMaybe mempty . M.lookup u <$> recordedDifferences
diff --git a/Logs/Difference/Pure.hs b/Logs/Difference/Pure.hs
new file mode 100644
index 0000000000..b2d1dc1cdf
--- /dev/null
+++ b/Logs/Difference/Pure.hs
@@ -0,0 +1,27 @@
+{- git-annex difference log, pure functions
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Difference.Pure (
+	allDifferences,
+	parseDifferencesLog,
+) where
+
+import qualified Data.Map as M
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString as A
+
+import Annex.Common
+import Types.Difference
+import Logs.UUIDBased
+
+parseDifferencesLog :: L.ByteString -> (M.Map UUID Differences)
+parseDifferencesLog = simpleMap
+	. parseLogOld (readDifferences . decodeBS <$> A.takeByteString)
+
+-- The sum of all recorded differences, across all UUIDs.
+allDifferences :: M.Map UUID Differences -> Differences
+allDifferences = mconcat . M.elems
diff --git a/Logs/EquivilantKeys.hs b/Logs/EquivilantKeys.hs
new file mode 100644
index 0000000000..106e7893dd
--- /dev/null
+++ b/Logs/EquivilantKeys.hs
@@ -0,0 +1,31 @@
+{- Logs listing keys that are equivilant to a key.
+ -
+ - Copyright 2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Logs.EquivilantKeys (
+	getEquivilantKeys,
+	setEquivilantKey,
+) where
+
+import Annex.Common
+import qualified Annex
+import Logs
+import Logs.Presence
+import qualified Annex.Branch
+
+getEquivilantKeys :: Key -> Annex [Key]
+getEquivilantKeys key = do
+	config <- Annex.getGitConfig
+	nub . mapMaybe (deserializeKey' . fromLogInfo)
+		<$> presentLogInfo (equivilantKeysLogFile config key)
+
+setEquivilantKey :: Key -> Key -> Annex ()
+setEquivilantKey key equivkey = do
+	config <- Annex.getGitConfig
+	addLog (Annex.Branch.RegardingUUID []) (equivilantKeysLogFile config key)
+		InfoPresent (LogInfo (serializeKey' equivkey))
diff --git a/Logs/Export.hs b/Logs/Export.hs
new file mode 100644
index 0000000000..36d6156c75
--- /dev/null
+++ b/Logs/Export.hs
@@ -0,0 +1,140 @@
+{- git-annex export log (also used to log imports)
+ -
+ - Copyright 2017-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Logs.Export (
+	Exported,
+	mkExported,
+	ExportParticipants,
+	ExportChange(..),
+	getExport,
+	exportedTreeishes,
+	incompleteExportedTreeishes,
+	recordExportBeginning,
+	recordExportUnderway,
+	recordExport,
+	logExportExcluded,
+	getExportExcluded,
+) where
+
+import qualified Data.Map as M
+import qualified Data.ByteString as B
+
+import Annex.Common
+import qualified Annex.Branch
+import qualified Git
+import Git.Sha
+import Git.FilePath
+import Logs
+import Logs.Export.Pure
+import Logs.MapLog
+import Logs.File
+import qualified Git.LsTree
+import qualified Git.Tree
+import Annex.UUID
+
+import qualified Data.ByteString.Lazy as L
+import Data.Either
+import Data.Char
+
+-- | Get what's been exported to a special remote.
+getExport :: UUID -> Annex [Exported]
+getExport remoteuuid = nub . mapMaybe get . M.toList
+	. parseExportLogMap
+	<$> Annex.Branch.get exportLog
+  where
+	get (ep, exported)
+		| exportTo ep == remoteuuid = Just exported
+		| otherwise = Nothing
+
+-- | Record the beginning of an export, to allow cleaning up from
+-- interrupted exports.
+--
+-- This is called before any changes are made to the remote.
+recordExportBeginning :: UUID -> Git.Ref -> Annex ()
+recordExportBeginning remoteuuid newtree = do
+	c <- currentVectorClock
+	u <- getUUID
+	let ep = ExportParticipants { exportFrom = u, exportTo = remoteuuid }
+	old <- fromMaybe (mkExported emptyTree [])
+		. M.lookup ep
+		. parseExportLogMap
+		<$> Annex.Branch.get exportLog
+	let new = updateIncompleteExportedTreeish old (nub (newtree:incompleteExportedTreeishes [old]))
+	Annex.Branch.change
+		(Annex.Branch.RegardingUUID [remoteuuid, u])
+		exportLog
+		(buildExportLog . changeMapLog c ep new . parseExportLog)
+	recordExportTreeish newtree
+
+-- Graft a tree ref into the git-annex branch. This is done
+-- to ensure that it's available later, when getting exported files
+-- from the remote. Since that could happen in another clone of the
+-- repository, the tree has to be kept available, even if it
+-- doesn't end up being merged into the master branch.
+recordExportTreeish :: Git.Ref -> Annex ()
+recordExportTreeish t = void $
+	Annex.Branch.rememberTreeish t (asTopFilePath exportTreeGraftPoint)
+
+-- | Record that an export to a special remote is under way.
+--
+-- This is called before an export begins uploading new files to the
+-- remote, but after it's cleaned up any files that need to be deleted
+-- from the old treeish.
+--
+-- Any entries in the log for the oldTreeish will be updated to the
+-- newTreeish. This way, when multiple repositories are exporting to
+-- the same special remote, there's no conflict as long as they move
+-- forward in lock-step.
+recordExportUnderway :: UUID -> ExportChange -> Annex ()
+recordExportUnderway remoteuuid ec = do
+	c <- currentVectorClock
+	hereuuid <- getUUID
+	let ep = ExportParticipants { exportFrom = hereuuid, exportTo = remoteuuid }
+	let exported = mkExported (newTreeish ec) []
+	let ru = Annex.Branch.RegardingUUID [remoteuuid, hereuuid]
+	Annex.Branch.change ru exportLog $ 
+		buildExportLog
+			. changeMapLog c ep exported 
+			. mapLogWithKey (updateForExportChange remoteuuid ec c hereuuid)
+			. parseExportLog
+
+-- Record information about the export to the git-annex branch.
+--
+-- This is equivalent to recordExportBeginning followed by
+-- recordExportUnderway, but without the ability to clean up from
+-- interrupted exports.
+recordExport :: UUID -> Git.Ref -> ExportChange -> Annex ()
+recordExport remoteuuid tree ec = do
+	when (oldTreeish ec /= [tree]) $
+		recordExportTreeish tree
+	recordExportUnderway remoteuuid ec
+
+logExportExcluded :: UUID -> ((Git.Tree.TreeItem -> IO ()) -> Annex a) -> Annex a
+logExportExcluded u a = do
+	logf <- fromRepo $ gitAnnexExportExcludeLog u
+	withLogHandle logf $ \logh -> do
+		a (writer logh)
+  where
+	writer logh = B.hPutStr logh
+		. flip B.snoc (fromIntegral (ord '\n'))
+		. Git.LsTree.formatLsTree
+		. Git.Tree.treeItemToLsTreeItem
+
+getExportExcluded :: UUID -> Annex [Git.Tree.TreeItem]
+getExportExcluded u = do
+	logf <- fromRepo $ gitAnnexExportExcludeLog u
+	liftIO $ catchDefaultIO [] $ exportExcludedParser
+		<$> L.readFile (fromRawFilePath logf)
+  where
+
+exportExcludedParser :: L.ByteString -> [Git.Tree.TreeItem]
+exportExcludedParser = map Git.Tree.lsTreeItemToTreeItem
+	. rights
+	. map (Git.LsTree.parseLsTree (Git.LsTree.LsTreeLong False))
+	. L.split (fromIntegral $ ord '\n')
diff --git a/Logs/Export/Pure.hs b/Logs/Export/Pure.hs
new file mode 100644
index 0000000000..f5c5be755f
--- /dev/null
+++ b/Logs/Export/Pure.hs
@@ -0,0 +1,119 @@
+{- git-annex export log (also used to log imports), pure operations
+ -
+ - Copyright 2017-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Logs.Export.Pure (
+	Exported,
+	mkExported,
+	updateExportedTreeish,
+	updateIncompleteExportedTreeish,
+	ExportParticipants(..),
+	ExportChange(..),
+	exportedTreeishes,
+	incompleteExportedTreeishes,
+	parseExportLog,
+	parseExportLogMap,
+	buildExportLog,
+	updateForExportChange,
+) where
+
+import Annex.Common
+import Annex.VectorClock
+import qualified Git
+import Logs.MapLog
+
+import qualified Data.Map as M
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+import Data.ByteString.Builder
+
+-- This constructor is not itself exported to other modules, to enforce
+-- consistent use of exportedTreeishes.
+data Exported = Exported
+	{ exportedTreeish :: Git.Ref
+	, incompleteExportedTreeish :: [Git.Ref]
+	}
+	deriving (Eq, Show)
+
+mkExported :: Git.Ref -> [Git.Ref] -> Exported
+mkExported = Exported
+
+updateExportedTreeish :: Exported -> Git.Ref -> Exported
+updateExportedTreeish ex t = ex { exportedTreeish = t }
+
+updateIncompleteExportedTreeish :: Exported -> [Git.Ref] -> Exported
+updateIncompleteExportedTreeish ex t = ex { incompleteExportedTreeish = t }
+
+-- | Get the list of exported treeishes.
+--
+-- If the list contains multiple items, there was an export conflict,
+-- and different trees were exported to the same special remote.
+exportedTreeishes :: [Exported] -> [Git.Ref]
+exportedTreeishes = nub . map exportedTreeish
+
+-- | Treeishes that started to be exported, but were not finished.
+incompleteExportedTreeishes :: [Exported] -> [Git.Ref]
+incompleteExportedTreeishes = concatMap incompleteExportedTreeish
+
+data ExportParticipants = ExportParticipants
+	{ exportFrom :: UUID
+	, exportTo :: UUID
+	}
+	deriving (Eq, Ord, Show)
+
+data ExportChange = ExportChange
+	{ oldTreeish :: [Git.Ref]
+	, newTreeish :: Git.Ref
+	}
+
+parseExportLog :: L.ByteString -> MapLog ExportParticipants Exported
+parseExportLog = parseMapLog exportParticipantsParser exportedParser
+
+parseExportLogMap :: L.ByteString -> M.Map ExportParticipants Exported
+parseExportLogMap = simpleMap . parseExportLog
+
+buildExportLog :: MapLog ExportParticipants Exported -> Builder
+buildExportLog = buildMapLog buildExportParticipants buildExported
+
+buildExportParticipants :: ExportParticipants -> Builder
+buildExportParticipants ep = 
+	buildUUID (exportFrom ep) <> sep <> buildUUID (exportTo ep)
+  where
+	sep = charUtf8 ':'
+
+exportParticipantsParser :: A.Parser ExportParticipants
+exportParticipantsParser = ExportParticipants
+	<$> (toUUID <$> A8.takeWhile1 (/= ':'))
+	<* A8.char ':'
+	<*> (toUUID <$> A8.takeWhile1 (const True))
+
+buildExported :: Exported -> Builder
+buildExported exported = go (exportedTreeish exported : incompleteExportedTreeish exported)
+  where
+	go [] = mempty
+	go (r:rs) = rref r <> mconcat [ charUtf8 ' ' <> rref r' | r' <- rs ]
+	rref = byteString . Git.fromRef'
+
+exportedParser :: A.Parser Exported
+exportedParser = Exported <$> refparser <*> many refparser
+  where
+	refparser = (Git.Ref <$> A8.takeWhile1 (/= ' ') )
+		<* ((const () <$> A8.char ' ') <|> A.endOfInput)
+
+-- Used when recording that an export is under way.
+-- Any LogEntry for the oldTreeish will be updated to the newTreeish.
+-- This way, when multiple repositories are exporting to
+-- the same special remote, there's no conflict as long as they move
+-- forward in lock-step.
+updateForExportChange :: UUID -> ExportChange -> CandidateVectorClock -> UUID -> ExportParticipants -> LogEntry Exported -> LogEntry Exported
+updateForExportChange remoteuuid ec c hereuuid ep le@(LogEntry lc exported@(Exported { exportedTreeish = t }))
+	| hereuuid == exportFrom ep || remoteuuid /= exportTo ep || t `notElem` oldTreeish ec = le
+	| otherwise = LogEntry c' (exported { exportedTreeish = newTreeish ec })
+  where
+	c' = advanceVectorClock c [lc]
diff --git a/Logs/File.hs b/Logs/File.hs
new file mode 100644
index 0000000000..e129da0553
--- /dev/null
+++ b/Logs/File.hs
@@ -0,0 +1,192 @@
+{- git-annex log files
+ -
+ - Copyright 2018-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP, BangPatterns #-}
+
+module Logs.File (
+	writeLogFile,
+	withLogHandle,
+	appendLogFile,
+	modifyLogFile,
+	streamLogFile,
+	streamLogFileUnsafe,
+	checkLogFile,
+	calcLogFile,
+	calcLogFileUnsafe,
+	fileLines,
+	fileLines',
+) where
+
+import Annex.Common
+import Annex.Perms
+import Annex.LockFile
+import Annex.ReplaceFile
+import Utility.Tmp
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString.Lazy.Char8 as L8
+
+-- | Writes content to a file, replacing the file atomically, and
+-- making the new file have whatever permissions the git repository is
+-- configured to use. Creates the parent directory when necessary.
+writeLogFile :: RawFilePath -> String -> Annex ()
+writeLogFile f c = createDirWhenNeeded f $ viaTmp writelog (fromRawFilePath f) c
+  where
+	writelog tmp c' = do
+		liftIO $ writeFile tmp c'
+		setAnnexFilePerm (toRawFilePath tmp)
+
+-- | Runs the action with a handle connected to a temp file.
+-- The temp file replaces the log file once the action succeeds.
+withLogHandle :: RawFilePath -> (Handle -> Annex a) -> Annex a
+withLogHandle f a = do
+	createAnnexDirectory (parentDir f)
+	replaceGitAnnexDirFile (fromRawFilePath f) $ \tmp ->
+		bracket (setup tmp) cleanup a
+  where
+	setup tmp = do
+		setAnnexFilePerm tmp
+		liftIO $ openFile (fromRawFilePath tmp) WriteMode
+	cleanup h = liftIO $ hClose h
+
+-- | Appends a line to a log file, first locking it to prevent
+-- concurrent writers.
+appendLogFile :: RawFilePath -> RawFilePath -> L.ByteString -> Annex ()
+appendLogFile f lck c = 
+	createDirWhenNeeded f $
+		withExclusiveLock lck $ do
+			liftIO $ withFile f' AppendMode $
+				\h -> L8.hPutStrLn h c
+			setAnnexFilePerm (toRawFilePath f')
+  where
+	f' = fromRawFilePath f
+
+-- | Modifies a log file.
+--
+-- If the function does not make any changes, avoids rewriting the file
+-- for speed, but that does mean the whole file content has to be buffered
+-- in memory.
+--
+-- The file is locked to prevent concurrent writers, and it is written
+-- atomically.
+modifyLogFile :: RawFilePath -> RawFilePath -> ([L.ByteString] -> [L.ByteString]) -> Annex ()
+modifyLogFile f lck modf = withExclusiveLock lck $ do
+	ls <- liftIO $ fromMaybe []
+		<$> tryWhenExists (fileLines <$> L.readFile f')
+	let ls' = modf ls
+	when (ls' /= ls) $
+		createDirWhenNeeded f $
+			viaTmp writelog f' (L8.unlines ls')
+  where
+	f' = fromRawFilePath f
+	writelog lf b = do
+		liftIO $ L.writeFile lf b
+		setAnnexFilePerm (toRawFilePath lf)
+
+-- | Checks the content of a log file to see if any line matches.
+checkLogFile :: RawFilePath -> RawFilePath -> (L.ByteString -> Bool) -> Annex Bool
+checkLogFile f lck matchf = withSharedLock lck $ bracket setup cleanup go
+  where
+	setup = liftIO $ tryWhenExists $ openFile f' ReadMode
+	cleanup Nothing = noop
+	cleanup (Just h) = liftIO $ hClose h
+	go Nothing = return False
+	go (Just h) = do
+		!r <- liftIO (any matchf . fileLines <$> L.hGetContents h)
+		return r
+	f' = fromRawFilePath f
+
+-- | Folds a function over lines of a log file to calculate a value.
+calcLogFile :: RawFilePath -> RawFilePath -> t -> (L.ByteString -> t -> t) -> Annex t
+calcLogFile f lck start update =
+	withSharedLock lck $ calcLogFileUnsafe f start update
+
+-- | Unsafe version that does not do locking.
+calcLogFileUnsafe :: RawFilePath -> t -> (L.ByteString -> t -> t) -> Annex t
+calcLogFileUnsafe f start update = bracket setup cleanup go
+  where
+	setup = liftIO $ tryWhenExists $ openFile f' ReadMode
+	cleanup Nothing = noop
+	cleanup (Just h) = liftIO $ hClose h
+	go Nothing = return start
+	go (Just h) = go' start =<< liftIO (fileLines <$> L.hGetContents h)
+	go' v [] = return v
+	go' v (l:ls) = do
+		let !v' = update l v
+		go' v' ls
+	f' = fromRawFilePath f
+
+-- | Streams lines from a log file, passing each line to the processor,
+-- and then empties the file at the end.
+--
+-- If the processor is interrupted or throws an exception, the log file is
+-- left unchanged.
+--
+-- There is also a finalizer, that is run once all lines have been
+-- streamed. It is run even if the log file does not exist. If the
+-- finalizer throws an exception, the log file is left unchanged.
+-- 
+-- Locking is used to prevent writes to to the log file while this
+-- is running.
+streamLogFile :: FilePath -> RawFilePath -> Annex () -> (String -> Annex ()) -> Annex ()
+streamLogFile f lck finalizer processor = 
+	withExclusiveLock lck $ do
+		streamLogFileUnsafe f finalizer processor
+		liftIO $ writeFile f ""
+		setAnnexFilePerm (toRawFilePath f)
+
+-- Unsafe version that does not do locking, and does not empty the file
+-- at the end.
+streamLogFileUnsafe :: FilePath -> Annex () -> (String -> Annex ()) -> Annex ()
+streamLogFileUnsafe f finalizer processor = bracketOnError setup cleanup go
+  where
+	setup = liftIO $ tryWhenExists $ openFile f ReadMode 
+	cleanup Nothing = noop
+	cleanup (Just h) = liftIO $ hClose h
+	go Nothing = finalizer
+	go (Just h) = do
+		mapM_ processor =<< liftIO (lines <$> hGetContents h)
+		liftIO $ hClose h
+		finalizer
+
+createDirWhenNeeded :: RawFilePath -> Annex () -> Annex ()
+createDirWhenNeeded f a = a `catchNonAsync` \_e -> do
+	-- Most of the time, the directory will exist, so this is only
+	-- done if writing the file fails.
+	createAnnexDirectory (parentDir f)
+	a
+
+-- On windows, readFile does NewlineMode translation,
+-- stripping CR before LF. When converting to ByteString,
+-- use this to emulate that.
+fileLines :: L.ByteString -> [L.ByteString]
+#ifdef mingw32_HOST_OS
+fileLines = map stripCR . L8.lines
+  where
+	stripCR b = case L8.unsnoc b of
+		Nothing -> b
+		Just (b', e)
+			| e == '\r' -> b'
+			| otherwise -> b
+#else
+fileLines = L8.lines
+#endif
+
+fileLines' :: S.ByteString -> [S.ByteString]
+#ifdef mingw32_HOST_OS
+fileLines' = map stripCR . S8.lines
+  where
+	stripCR b = case S8.unsnoc b of
+		Nothing -> b
+		Just (b', e)
+			| e == '\r' -> b'
+			| otherwise -> b
+#else
+fileLines' = S8.lines
+#endif
diff --git a/Logs/FsckResults.hs b/Logs/FsckResults.hs
new file mode 100644
index 0000000000..017941d370
--- /dev/null
+++ b/Logs/FsckResults.hs
@@ -0,0 +1,63 @@
+{- git-annex fsck results log files
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.FsckResults (
+	writeFsckResults,
+	readFsckResults,
+	clearFsckResults,
+) where
+
+import Annex.Common
+import Git.Fsck
+import Git.Types
+import Logs.File
+import qualified Utility.RawFilePath as R
+
+import qualified Data.Set as S
+
+writeFsckResults :: UUID -> FsckResults -> Annex ()
+writeFsckResults u fsckresults = do
+	logfile <- fromRepo $ gitAnnexFsckResultsLog u
+	case serializeFsckResults fsckresults of
+		Just s -> store s logfile
+		Nothing -> liftIO $
+			removeWhenExistsWith R.removeLink logfile
+  where
+	store s logfile = writeLogFile logfile s
+
+serializeFsckResults :: FsckResults -> Maybe String
+serializeFsckResults fsckresults = case fsckresults of
+	FsckFailed -> Just (serialize S.empty False)
+	FsckFoundMissing s t
+		| S.null s -> Nothing
+		| otherwise -> Just (serialize s t)
+  where
+	serialize s t =
+		let ls = map fromRef (S.toList s)
+		in if t
+			then unlines ("truncated":ls)
+			else unlines ls
+
+readFsckResults :: UUID -> Annex FsckResults
+readFsckResults u = do
+	logfile <- fromRepo $ gitAnnexFsckResultsLog u
+	liftIO $ catchDefaultIO (FsckFoundMissing S.empty False) $
+		deserializeFsckResults <$> readFile (fromRawFilePath logfile)
+
+deserializeFsckResults :: String -> FsckResults
+deserializeFsckResults = deserialize . lines
+  where
+	deserialize ("truncated":ls) = deserialize' ls True
+	deserialize ls = deserialize' ls False
+	deserialize' ls t =
+		let s = S.fromList $ map (Ref . encodeBS) ls
+		in if S.null s then FsckFailed else FsckFoundMissing s t
+
+clearFsckResults :: UUID -> Annex ()
+clearFsckResults = liftIO . removeWhenExistsWith R.removeLink
+	<=< fromRepo . gitAnnexFsckResultsLog
+	
diff --git a/Logs/Group.hs b/Logs/Group.hs
new file mode 100644
index 0000000000..bb5d17a033
--- /dev/null
+++ b/Logs/Group.hs
@@ -0,0 +1,99 @@
+{- git-annex group log
+ -
+ - Copyright 2012, 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Group (
+	groupLog,
+	groupChange,
+	groupSet,
+	lookupGroups,
+	groupMap,
+	groupMapLoad,
+	getStandardGroup,
+	inUnwantedGroup
+) where
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import qualified Data.Attoparsec.ByteString as A
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+import Data.ByteString.Builder
+
+import Annex.Common
+import Logs
+import qualified Annex.Branch
+import qualified Annex
+import Logs.UUIDBased
+import Types.Group
+import Types.StandardGroups
+
+{- Returns the groups of a given repo UUID. -}
+lookupGroups :: UUID -> Annex (S.Set Group)
+lookupGroups u = (fromMaybe S.empty . M.lookup u) . groupsByUUID <$> groupMap
+
+{- Applies a set modifier to change the groups for a uuid in the groupLog. -}
+groupChange :: UUID -> (S.Set Group -> S.Set Group) -> Annex ()
+groupChange uuid@(UUID _) modifier = do
+	curr <- lookupGroups uuid
+	c <- currentVectorClock
+	Annex.Branch.change (Annex.Branch.RegardingUUID [uuid]) groupLog $
+		buildLogOld buildGroup . changeLog c uuid (modifier curr) . parseLogOld parseGroup
+	
+	-- The changed group invalidates the preferred content cache.
+	Annex.changeState $ \s -> s
+		{ Annex.groupmap = Nothing
+		, Annex.preferredcontentmap = Nothing
+		}
+groupChange NoUUID _ = error "unknown UUID; cannot modify"
+
+buildGroup :: S.Set Group -> Builder
+buildGroup = go . S.toList
+  where
+	go [] = mempty
+	go (g:gs) = bld g <> mconcat [ charUtf8 ' ' <> bld g' | g' <- gs ]
+	bld (Group g) = byteString g
+
+parseGroup :: A.Parser (S.Set Group)
+parseGroup = S.fromList <$> go []
+  where
+	go l = (A.endOfInput *> pure l)
+		<|> ((getgroup <* A8.char ' ') >>= go . (:l))
+		<|> ((:l) <$> getgroup)
+		-- allow extra writespace before or after a group name
+		<|> (A8.char ' ' >>= const (go l))
+	getgroup = Group <$> A8.takeWhile1 (/= ' ')
+
+groupSet :: UUID -> S.Set Group -> Annex ()
+groupSet u g = groupChange u (const g)
+
+{- The map is cached for speed. -}
+groupMap :: Annex GroupMap
+groupMap = maybe groupMapLoad return =<< Annex.getState Annex.groupmap
+
+{- Loads the map, updating the cache. -}
+groupMapLoad :: Annex GroupMap
+groupMapLoad = do
+	m <- makeGroupMap . simpleMap . parseLogOld parseGroup
+		<$> Annex.Branch.get groupLog
+	Annex.changeState $ \s -> s { Annex.groupmap = Just m }
+	return m
+
+makeGroupMap :: M.Map UUID (S.Set Group) -> GroupMap
+makeGroupMap byuuid = GroupMap byuuid bygroup
+  where
+	bygroup = M.fromListWith S.union $
+		concatMap explode $ M.toList byuuid
+	explode (u, s) = map (\g -> (g, S.singleton u)) (S.toList s)
+
+{- If a repository is in exactly one standard group, returns it. -}
+getStandardGroup :: S.Set Group -> Maybe StandardGroup
+getStandardGroup s = case mapMaybe toStandardGroup $ S.toList s of
+	[g] -> Just g
+	_ -> Nothing
+
+inUnwantedGroup :: UUID -> Annex Bool
+inUnwantedGroup u = elem UnwantedGroup 
+	. mapMaybe toStandardGroup . S.toList <$> lookupGroups u
diff --git a/Logs/Import.hs b/Logs/Import.hs
new file mode 100644
index 0000000000..7d3e0eacce
--- /dev/null
+++ b/Logs/Import.hs
@@ -0,0 +1,37 @@
+{- git-annex import logs
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Import (
+	recordContentIdentifierTree,
+	getContentIdentifierTree
+) where
+
+import Annex.Common
+import Git.Types
+import Git.Sha
+import Logs.File
+
+import qualified Data.ByteString.Lazy as L
+
+{- Records the sha of a tree that contains hashes of ContentIdentifiers
+ - that were imported from a remote. -}
+recordContentIdentifierTree :: UUID -> Sha -> Annex ()
+recordContentIdentifierTree u t = do
+	l <- calcRepo' (gitAnnexImportLog u)
+	writeLogFile l (fromRef t)
+
+{- Gets the tree last recorded for a remote. -}
+getContentIdentifierTree :: UUID -> Annex (Maybe Sha)
+getContentIdentifierTree u = do
+	l <- calcRepo' (gitAnnexImportLog u)
+	-- This is safe because the log file is written atomically.
+	calcLogFileUnsafe l Nothing update
+  where
+	update l Nothing = extractSha (L.toStrict l)
+	-- Subsequent lines are ignored. This leaves room for future
+	-- expansion of what is logged.
+	update _l (Just l) = Just l
diff --git a/Logs/Line.hs b/Logs/Line.hs
new file mode 100644
index 0000000000..7c38b7e0b9
--- /dev/null
+++ b/Logs/Line.hs
@@ -0,0 +1,38 @@
+{- line based log files
+ -
+ - Copyright 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Line where
+
+import Common
+
+import qualified Data.Attoparsec.ByteString as A
+import Data.Attoparsec.ByteString.Char8 (isEndOfLine)
+import qualified Data.DList as D
+
+{- Applies a parser to each line of a log file.
+ -
+ - If the parser fails to parse a line, that line is skipped, instead of
+ - the overall parse failing. This is generally a good idea in case a newer
+ - version of git-annex somehow changed the format of the log file.
+ -
+ - Any combination of \r and \n are taken to be the end of the line.
+ - (Some versions of git-annex on Windows wrote \r into git-annex branch
+ - files, and multiple \r's sometimes accumulated.)
+ -
+ - The parser does not itself need to avoid parsing beyond the end of line;
+ - this is implemented only pass the content of a line to the parser.
+ -}
+parseLogLines :: A.Parser a -> A.Parser [a]
+parseLogLines parser = go D.empty
+  where
+	go dl = do
+		line <- A.takeTill isEndOfLine
+		A.skipWhile isEndOfLine
+		let dl' = case A.parseOnly parser line of
+			Left _ -> dl
+			Right v -> D.snoc dl v
+		(A.endOfInput *> return (D.toList dl')) <|> go dl'
diff --git a/Logs/Location.hs b/Logs/Location.hs
new file mode 100644
index 0000000000..6235d1a34c
--- /dev/null
+++ b/Logs/Location.hs
@@ -0,0 +1,224 @@
+{-# LANGUAGE BangPatterns #-}
+
+{- git-annex location log
+ -
+ - git-annex keeps track of which repositories have the contents of annexed
+ - files.
+ -
+ - Repositories record their UUID and the date when they --get or --drop
+ - a value.
+ - 
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Logs.Location (
+	LogStatus(..),
+	logStatus,
+	logStatusAfter,
+	logChange,
+	loggedLocations,
+	loggedPreviousLocations,
+	loggedLocationsHistorical,
+	loggedLocationsRef,
+	parseLoggedLocations,
+	isKnownKey,
+	checkDead,
+	setDead,
+	Unchecked,
+	finishCheck,
+	loggedKeys,
+	loggedKeysFor,
+	loggedKeysFor',
+	overLocationLogs,
+	overLocationLogs',
+) where
+
+import Annex.Common
+import qualified Annex.Branch
+import Logs
+import Logs.Presence
+import Annex.UUID
+import Annex.CatFile
+import Annex.VectorClock
+import Git.Types (RefDate, Ref)
+import qualified Annex
+
+import Data.Time.Clock
+import qualified Data.ByteString.Lazy as L
+
+{- Log a change in the presence of a key's value in current repository. -}
+logStatus :: Key -> LogStatus -> Annex ()
+logStatus key s = do
+	u <- getUUID
+	logChange key u s
+
+{- Run an action that gets the content of a key, and update the log
+ - when it succeeds. -}
+logStatusAfter :: Key -> Annex Bool -> Annex Bool
+logStatusAfter key a = ifM a 
+	( do
+		logStatus key InfoPresent
+		return True
+	, return False
+	)
+
+{- Log a change in the presence of a key's value in a repository. -}
+logChange :: Key -> UUID -> LogStatus -> Annex ()
+logChange key u@(UUID _) s = do
+	config <- Annex.getGitConfig
+	maybeAddLog
+		(Annex.Branch.RegardingUUID [u])
+		(locationLogFile config key)
+		s
+		(LogInfo (fromUUID u))
+logChange _ NoUUID _ = noop
+
+{- Returns a list of repository UUIDs that, according to the log, have
+ - the value of a key. -}
+loggedLocations :: Key -> Annex [UUID]
+loggedLocations = getLoggedLocations presentLogInfo
+
+{- Returns a list of repository UUIDs that the location log indicates
+ - used to have the vale of a key, but no longer do.
+ -}
+loggedPreviousLocations :: Key -> Annex [UUID]
+loggedPreviousLocations = getLoggedLocations notPresentLogInfo
+
+{- Gets the location log on a particular date. -}
+loggedLocationsHistorical :: RefDate -> Key -> Annex [UUID]
+loggedLocationsHistorical = getLoggedLocations . historicalLogInfo
+
+{- Gets the locations contained in a git ref. -}
+loggedLocationsRef :: Ref -> Annex [UUID]
+loggedLocationsRef ref = map (toUUID . fromLogInfo) . getLog <$> catObject ref
+
+{- Parses the content of a log file and gets the locations in it. -}
+parseLoggedLocations :: L.ByteString -> [UUID]
+parseLoggedLocations l = map (toUUID . fromLogInfo . info)
+	(filterPresent (parseLog l))
+
+getLoggedLocations :: (RawFilePath -> Annex [LogInfo]) -> Key -> Annex [UUID]
+getLoggedLocations getter key = do
+	config <- Annex.getGitConfig
+	map (toUUID . fromLogInfo) <$> getter (locationLogFile config key)
+
+{- Is there a location log for the key? True even for keys with no
+ - remaining locations. -}
+isKnownKey :: Key -> Annex Bool
+isKnownKey key = do
+	config <- Annex.getGitConfig
+	not . null <$> readLog (locationLogFile config key)
+
+{- For a key to be dead, all locations that have location status for the key
+ - must have InfoDead set. -}
+checkDead :: Key -> Annex Bool
+checkDead key = do
+	config <- Annex.getGitConfig
+	ls <- compactLog <$> readLog (locationLogFile config key)
+	return $! all (\l -> status l == InfoDead) ls
+
+{- Updates the log to say that a key is dead. 
+ - 
+ - Changes all logged lines for the key, in any location, that are
+ - currently InfoMissing, to be InfoDead.
+ - 
+ - The vector clock in the log is updated minimally, so that any
+ - other location log changes are guaranteed to overrule this.
+ -}
+setDead :: Key -> Annex ()
+setDead key = do
+	config <- Annex.getGitConfig
+	let logfile = locationLogFile config key
+	ls <- compactLog <$> readLog logfile
+	mapM_ (go logfile) (filter (\l -> status l == InfoMissing) ls)
+  where
+	go logfile l = 
+		let u = toUUID (fromLogInfo (info l))
+		    c = case date l of
+			VectorClock v -> CandidateVectorClock $
+				v + realToFrac (picosecondsToDiffTime 1)
+			Unknown -> CandidateVectorClock 0
+		in addLog' (Annex.Branch.RegardingUUID [u]) logfile InfoDead
+			(info l) c
+
+data Unchecked a = Unchecked (Annex (Maybe a))
+
+finishCheck :: Unchecked a -> Annex (Maybe a)
+finishCheck (Unchecked a) = a
+
+{- Finds all keys that have location log information.
+ - (There may be duplicate keys in the list.)
+ -
+ - Keys that have been marked as dead are not included.
+ -}
+loggedKeys :: Annex (Maybe ([Unchecked Key], IO Bool))
+loggedKeys = loggedKeys' (not <$$> checkDead)
+
+loggedKeys' :: (Key -> Annex Bool) -> Annex (Maybe ([Unchecked Key], IO Bool))
+loggedKeys' check = do
+	config <- Annex.getGitConfig
+	Annex.Branch.files >>= \case
+		Nothing -> return Nothing
+		Just (bfs, cleanup) -> do
+			let l = mapMaybe (defercheck <$$> locationLogFileKey config) bfs
+			return (Just (l, cleanup))
+  where
+	defercheck k = Unchecked $ ifM (check k)
+		( return (Just k)
+		, return Nothing
+		)
+
+{- Finds all keys that have location log information indicating
+ - they are present in the specified repository.
+ -
+ - This does not stream well; use loggedKeysFor' for lazy streaming.
+ -}
+loggedKeysFor :: UUID -> Annex (Maybe [Key])
+loggedKeysFor u = loggedKeysFor' u >>= \case
+	Nothing -> return Nothing
+	Just (l, cleanup) -> do
+		l' <- catMaybes <$> mapM finishCheck l
+		liftIO $ void cleanup
+		return (Just l')
+
+loggedKeysFor' :: UUID -> Annex (Maybe ([Unchecked Key], IO Bool))
+loggedKeysFor' u = loggedKeys' isthere
+  where
+	isthere k = do
+		us <- loggedLocations k
+		let !there = u `elem` us
+		return there
+
+{- This is much faster than loggedKeys. -}
+overLocationLogs :: v -> (Key -> [UUID] -> v -> Annex v) -> Annex v
+overLocationLogs v = overLocationLogs' v (flip const)
+
+overLocationLogs'
+	 :: v 
+	-> (Annex (Maybe (Key, RawFilePath, Maybe L.ByteString)) -> Annex v -> Annex v)
+        -> (Key -> [UUID] -> v -> Annex v)
+        -> Annex v
+overLocationLogs' iv discarder keyaction = do
+	config <- Annex.getGitConfig
+		
+	let getk = locationLogFileKey config
+	let go v reader = reader >>= \case
+		Just (k, f, content) -> discarder reader $ do
+			-- precache to make checkDead fast, and also to
+			-- make any accesses done in keyaction fast.
+			maybe noop (Annex.Branch.precache f) content
+			ifM (checkDead k)
+				( go v reader
+				, do
+					!v' <- keyaction k (maybe [] parseLoggedLocations content) v
+					go v' reader
+				)
+		Nothing -> return v
+
+	Annex.Branch.overBranchFileContents getk (go iv) >>= \case
+		Just r -> return r
+		Nothing -> giveup "This repository is read-only, and there are unmerged git-annex branches, which prevents operating on all keys. (Set annex.merge-annex-branches to false to ignore the unmerged git-annex branches.)"
diff --git a/Logs/MapLog.hs b/Logs/MapLog.hs
new file mode 100644
index 0000000000..4ef338b740
--- /dev/null
+++ b/Logs/MapLog.hs
@@ -0,0 +1,128 @@
+{- git-annex Map log
+ -
+ - This is used to store a Map, in a way that can be union merged.
+ -
+ - A line of the log will look like: "timestamp field value"
+ -
+ - The field names cannot contain whitespace.
+ -
+ - Copyright 2014-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.MapLog (
+	module Logs.MapLog,
+	VectorClock,
+	currentVectorClock,
+) where
+
+import Common
+import Annex.VectorClock
+import Logs.Line
+import Utility.QuickCheck
+
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Map.Strict as M
+import qualified Data.Attoparsec.ByteString as A
+import qualified Data.Attoparsec.ByteString.Lazy as AL
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+import Data.ByteString.Builder
+import qualified Data.Semigroup as Sem
+import Prelude
+
+data LogEntry v = LogEntry
+	{ changed :: VectorClock
+	, value :: v
+	} deriving (Eq, Show)
+
+instance Arbitrary v => Arbitrary (LogEntry v) where
+	arbitrary = LogEntry <$> arbitrary <*> arbitrary
+
+newtype MapLog f v = MapLog (M.Map f (LogEntry v))
+	deriving (Show, Eq)
+
+instance Ord f => Sem.Semigroup (MapLog f v)
+  where
+	a <> MapLog b = foldl' (\m (f, v) -> addMapLog f v m) a (M.toList b)
+
+instance Ord f => Monoid (MapLog f v)
+  where
+	mempty = MapLog M.empty
+
+fromMapLog :: MapLog f v -> M.Map f (LogEntry v)
+fromMapLog (MapLog m) = m
+
+buildMapLog :: (f -> Builder) -> (v -> Builder) -> MapLog f v -> Builder
+buildMapLog fieldbuilder valuebuilder (MapLog m) = 
+	mconcat $ map genline $ M.toList m
+  where
+	genline (f, LogEntry c v) = 
+		buildVectorClock c <> sp 
+			<> fieldbuilder f <> sp 
+			<> valuebuilder v <> nl
+	sp = charUtf8 ' '
+	nl = charUtf8 '\n'
+
+parseMapLog :: Ord f => A.Parser f -> A.Parser v -> L.ByteString -> MapLog f v
+parseMapLog fieldparser valueparser = 
+	parseMapLogWith (mapLogParser fieldparser valueparser)
+
+parseMapLogWith :: Ord f => A.Parser (MapLog f v) -> L.ByteString -> MapLog f v
+parseMapLogWith parser = fromMaybe (MapLog M.empty) 
+	. AL.maybeResult
+	. AL.parse parser
+
+mapLogParser :: Ord f => A.Parser f -> A.Parser v -> A.Parser (MapLog f v)
+mapLogParser fieldparser valueparser = mapLogParser' $ do
+	c <- vectorClockParser
+	_ <- A8.char ' '
+	w <- A8.takeTill (== ' ')
+	f <- either fail return $
+		A.parseOnly (fieldparser <* A.endOfInput) w
+	_ <- A8.char ' '
+	v <- valueparser
+	A.endOfInput
+	return (f, LogEntry c v)
+
+mapLogParser' :: Ord f => A.Parser (f, LogEntry v) -> A.Parser (MapLog f v)
+mapLogParser' p = MapLog . M.fromListWith best
+	<$> parseLogLines p
+
+changeMapLog :: Ord f => CandidateVectorClock -> f -> v -> MapLog f v -> MapLog f v
+changeMapLog c f v (MapLog m) = MapLog (M.insert f (LogEntry c' v) m)
+  where
+	c' = case M.lookup f m of
+		Nothing -> advanceVectorClock c []
+		Just old -> advanceVectorClock c [changed old]
+
+{- Only add an LogEntry if it's newer (or at least as new as) than any
+ - existing LogEntry for a field. -}
+addMapLog :: Ord f => f -> LogEntry v -> MapLog f v -> MapLog f v
+addMapLog f v (MapLog m) = MapLog (M.insertWith best f v m)
+
+filterMapLogWith :: (f -> LogEntry v -> Bool) -> MapLog f v -> MapLog f v
+filterMapLogWith f (MapLog m) = MapLog (M.filterWithKey f m)
+
+mapLogWithKey :: (f -> LogEntry v -> LogEntry v) -> MapLog f v -> MapLog f v
+mapLogWithKey f (MapLog m) = MapLog (M.mapWithKey f m)
+
+{- Converts a MapLog into a simple Map without the timestamp information.
+ - This is a one-way trip, but useful for code that never needs to change
+ - the log. -}
+simpleMap :: MapLog f v -> M.Map f v
+simpleMap (MapLog m) = M.map value m
+
+best :: LogEntry v -> LogEntry v -> LogEntry v
+best new old
+	| changed old > changed new = old
+	| otherwise = new
+
+prop_addMapLog_sane :: Bool
+prop_addMapLog_sane = newWins && newestWins
+  where
+	newWins = addMapLog "foo" (LogEntry (VectorClock 1) "new") l == l2
+	newestWins = addMapLog "foo" (LogEntry (VectorClock 1) "newest") l2 /= l2
+
+	l = MapLog (M.fromList [("foo", LogEntry (VectorClock 0) "old")])
+	l2 = MapLog (M.fromList [("foo", LogEntry (VectorClock 1) "new")])
diff --git a/Logs/MetaData.hs b/Logs/MetaData.hs
new file mode 100644
index 0000000000..746b72dfbd
--- /dev/null
+++ b/Logs/MetaData.hs
@@ -0,0 +1,164 @@
+{- git-annex general metadata storage log and per-remote metadata storage log.
+ -
+ - A line of the log will look like "timestamp field [+-]value [...]"
+ -
+ - (In the per-remote log, each field is prefixed with "uuid:")
+ -
+ - Note that unset values are preserved. Consider this case:
+ -
+ - We have:
+ -
+ - 100 foo +x
+ - 200 foo -x
+ -
+ - An unmerged remote has:
+ -
+ - 150 foo +x
+ - 
+ - After union merge, because the foo -x was preserved, we know that
+ - after the other remote redundantly set foo +x, it was unset,
+ - and so foo currently has no value.
+ -
+ - Copyright 2014-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.MetaData (
+	getCurrentMetaData,
+	parseCurrentMetaData,
+	getCurrentRemoteMetaData,
+	addMetaData,
+	addRemoteMetaData,
+	addMetaDataClocked,
+	currentMetaData,
+	copyMetaData,
+) where
+
+import Annex.Common
+import Types.MetaData
+import Types.RemoteState
+import Annex.MetaData.StandardFields
+import Annex.VectorClock
+import qualified Annex.Branch
+import qualified Annex
+import Logs
+import Utility.TimeStamp
+import Logs.MetaData.Pure
+
+import qualified Data.Set as S
+import qualified Data.Map as M
+import qualified Data.ByteString.Lazy as L
+
+{- Go through the log from oldest to newest, and combine it all
+ - into a single MetaData representing the current state.
+ -
+ - Automatically generates a lastchanged metadata for each field that's
+ - currently set, based on timestamps in the log.
+ -}
+getCurrentMetaData :: Key -> Annex MetaData
+getCurrentMetaData = getCurrentMetaData' metaDataLogFile
+
+getCurrentMetaData' :: (GitConfig -> Key -> RawFilePath) -> Key -> Annex MetaData
+getCurrentMetaData' getlogfile k = do
+	config <- Annex.getGitConfig
+	parseCurrentMetaData <$> Annex.Branch.get (getlogfile config k)
+
+parseCurrentMetaData :: L.ByteString -> MetaData
+parseCurrentMetaData content =
+	let ls = S.toAscList $ parseLog content
+	    loggedmeta = logToCurrentMetaData ls
+	in currentMetaData $ unionMetaData loggedmeta
+		(lastchanged ls loggedmeta)
+  where
+	lastchanged [] _ = emptyMetaData
+	lastchanged ls (MetaData currentlyset) =
+		let m = foldl' (flip M.union) M.empty (map genlastchanged ls)
+		in MetaData $
+			-- Add a overall lastchanged using the oldest log
+			-- item (log is in ascending order).
+			M.insert lastChangedField (lastchangedval $ Prelude.last ls) $
+			M.mapKeys mkLastChangedField $
+			-- Only include fields that are currently set.
+			m `M.intersection` currentlyset
+	-- Makes each field have the timestamp as its value.
+	genlastchanged l =
+		let MetaData m = value l
+		    ts = lastchangedval l
+		in M.map (const ts) m
+	lastchangedval l = S.singleton $ toMetaValue $ encodeBS $ showts $ 
+		case changed l of
+			VectorClock t -> t
+			Unknown -> 0
+	showts = formatPOSIXTime "%F@%H-%M-%S"
+
+getCurrentRemoteMetaData :: RemoteStateHandle -> Key -> Annex RemoteMetaData
+getCurrentRemoteMetaData (RemoteStateHandle u) k = extractRemoteMetaData u <$>
+	getCurrentMetaData' remoteMetaDataLogFile k
+
+{- Adds in some metadata, which can override existing values, or unset
+ - them, but otherwise leaves any existing metadata as-is. -}
+addMetaData :: Key -> MetaData -> Annex ()
+addMetaData = addMetaData' (Annex.Branch.RegardingUUID []) metaDataLogFile
+
+addMetaData' :: Annex.Branch.RegardingUUID -> (GitConfig -> Key -> RawFilePath) -> Key -> MetaData -> Annex ()
+addMetaData' ru getlogfile k metadata = 
+	addMetaDataClocked' ru getlogfile k metadata =<< currentVectorClock
+
+{- Reusing the same CandidateVectorClock when making changes to the metadata
+ - of multiple keys is a nice optimisation. The same metadata lines
+ - will tend to be generated across the different log files, and so
+ - git will be able to pack the data more efficiently. -}
+addMetaDataClocked :: Key -> MetaData -> CandidateVectorClock -> Annex ()
+addMetaDataClocked = addMetaDataClocked' (Annex.Branch.RegardingUUID []) metaDataLogFile
+
+addMetaDataClocked' :: Annex.Branch.RegardingUUID -> (GitConfig -> Key -> RawFilePath) -> Key -> MetaData -> CandidateVectorClock -> Annex ()
+addMetaDataClocked' ru getlogfile k d@(MetaData m) c
+	| d == emptyMetaData = noop
+	| otherwise = do
+		config <- Annex.getGitConfig
+		Annex.Branch.change ru (getlogfile config k) $ \b ->
+			let s = parseLog b
+			    c' = advanceVectorClock c (map changed (S.toList s))
+			    ent = LogEntry c' metadata
+			in buildLog $ simplifyLog $ S.insert ent s
+  where
+	metadata = MetaData $ M.filterWithKey (\f _ -> not (isLastChangedField f)) m
+
+addRemoteMetaData :: Key -> RemoteStateHandle -> MetaData -> Annex ()
+addRemoteMetaData k (RemoteStateHandle u) m = 
+	addMetaData' (Annex.Branch.RegardingUUID [u]) remoteMetaDataLogFile k $ fromRemoteMetaData $
+		RemoteMetaData u m
+
+getMetaDataLog :: Key -> Annex (Log MetaData)
+getMetaDataLog key = do
+	config <- Annex.getGitConfig
+	readLog $ metaDataLogFile config key
+
+{- Copies the metadata from the old key to the new key.
+ -
+ - The exact content of the metadata file is copied, so that the timestamps
+ - remain the same, and because this is more space-efficient in the git
+ - repository.
+ - 
+ - Any metadata already attached to the new key is not preserved.
+ -
+ - Returns True when metadata was copied.
+ -}
+copyMetaData :: Key -> Key -> Annex Bool
+copyMetaData oldkey newkey
+	| oldkey == newkey = return False
+	| otherwise = do
+		l <- getMetaDataLog oldkey
+		if logToCurrentMetaData (S.toAscList l) == emptyMetaData
+			then return False
+			else do
+				config <- Annex.getGitConfig
+				Annex.Branch.change
+					(Annex.Branch.RegardingUUID [])
+					(metaDataLogFile config newkey)
+					(const $ buildLog l)
+				return True
+
+readLog :: RawFilePath -> Annex (Log MetaData)
+readLog = parseLog <$$> Annex.Branch.get
diff --git a/Logs/MetaData/Pure.hs b/Logs/MetaData/Pure.hs
new file mode 100644
index 0000000000..1a8c323299
--- /dev/null
+++ b/Logs/MetaData/Pure.hs
@@ -0,0 +1,111 @@
+{- git-annex metadata log, pure operations
+ -
+ - Copyright 2014-2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module Logs.MetaData.Pure (
+	Log,
+	LogEntry(..),
+	parseLog,
+	buildLog,
+	logToCurrentMetaData,
+	simplifyLog,
+	filterRemoteMetaData,
+	filterOutEmpty,
+) where
+
+import Types.MetaData
+import Logs.SingleValue.Pure
+import Types.UUID
+
+import qualified Data.Set as S
+import qualified Data.Map.Strict as M
+
+instance SingleValueSerializable MetaData where
+	serialize = Types.MetaData.serialize
+	deserialize = Types.MetaData.deserialize
+
+logToCurrentMetaData :: [LogEntry MetaData] -> MetaData
+logToCurrentMetaData = currentMetaData . combineMetaData . map value
+
+{- Simplify a log, removing historical values that are no longer
+ - needed. 
+ -
+ - This is not as simple as just making a single log line with the newest
+ - state of all metadata. Consider this case:
+ -
+ - We have:
+ -
+ - 100 foo +x bar +y
+ - 200 foo -x
+ -
+ - An unmerged remote has:
+ -
+ - 150 bar -y baz +w
+ -
+ - If what we have were simplified to "200 foo -x bar +y" then when the line
+ - from the remote became available, it would be older than the simplified
+ - line, and its change to bar would not take effect. That is wrong.
+ -
+ - Instead, simplify it to:
+ -
+ - 100 bar +y
+ - 200 foo -x
+ -
+ - (Note that this ends up with the same number of lines as the
+ - unsimplified version, so there's really no point in updating
+ - the log to this version. Doing so would only add data to git,
+ - with little benefit.)
+ -
+ - Now merging with the remote yields:
+ -
+ - 100 bar +y
+ - 150 bar -y baz +w
+ - 200 foo -x
+ -
+ - Simplifying again:
+ -
+ - 150 bar +z baz +w
+ - 200 foo -x
+ -}
+simplifyLog :: Log MetaData -> Log MetaData
+simplifyLog s = case sl of
+	(newest:rest) -> 
+		let sl' = go [newest] (value newest) rest
+		in if length sl' < length sl
+			then S.fromList sl'
+			else s
+	_ -> s
+  where
+	sl = S.toDescList s
+
+	go c _ [] = c
+	go c newer (l:ls)
+		| unique == emptyMetaData = go c newer ls
+		| otherwise = go (l { value = unique } : c)
+			(unionMetaData unique newer) ls
+	  where
+		older = value l
+		unique = older `differenceMetaData` newer
+
+{- Filters per-remote metadata on the basis of UUID.
+ -
+ - Note that the LogEntry's clock is left the same, so this should not be
+ - used except for in a transition.
+ -}
+filterRemoteMetaData :: (UUID -> Bool) -> Log MetaData -> Log MetaData
+filterRemoteMetaData p = S.map go
+  where
+	go l@(LogEntry { value = MetaData m }) = 
+		l { value = MetaData $ M.filterWithKey fil m }
+	fil f _v = case splitRemoteMetaDataField f of
+		Just (u, _) -> p u
+		Nothing -> True
+
+{- Filters out log lines that are empty. -}
+filterOutEmpty :: Log MetaData -> Log MetaData
+filterOutEmpty = S.filter $ \l -> value l /= emptyMetaData
diff --git a/Logs/Migrate.hs b/Logs/Migrate.hs
new file mode 100644
index 0000000000..b60b21cfcb
--- /dev/null
+++ b/Logs/Migrate.hs
@@ -0,0 +1,203 @@
+{- git-annex migration logs
+ -
+ - To record a migration in the git-annex branch as space efficiently as
+ - possible, it is stored as a tree which contains two subtrees 'old' and 'new'.
+ - The subtrees each contain the same filenames, which point to the old
+ - and new keys respectively.
+ -
+ - When the user commits the migrated files to their HEAD branch, that will
+ - store pointers to the new keys in git. And pointers to the old keys
+ - already exist in git. So recording the migration this way avoids
+ - injecting any new objects into git, besides the two trees. Note that for
+ - this to be the case, care has to be taken to record the migration 
+ - using the same symlink targets or pointer file contents as are used in
+ - the HEAD branch.
+ -
+ - The filenames used in the trees are not the original filenames, to avoid
+ - running migrate in a throwaway branch unexpectedly recording that
+ - branch's contents.
+ -
+ - There are two local log files:
+ - * migrate.log contains pairs of old and new keys, and is used while
+ -   performing a new migration, to build up a migration to commit.
+ -   This allows an interrupted migration to be resumed later.
+ - * migrations.log has as its first line a commit to the git-annex branch
+ -   up to which all migrations have been performed locally (including any
+ -   migrations in parent commits). Or the first line may be a null sha when
+ -   this has not been done yet. The rest of the lines in the file
+ -   are commits that have been made for locally performed migrations,
+ -   but whose parent commits have not necessarily been checked for
+ -   migrations yet.
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, BangPatterns #-}
+
+module Logs.Migrate (
+	MigrationRecord(..),
+	logMigration,
+	commitMigration,
+	streamNewDistributedMigrations,
+) where
+
+import Annex.Common
+import qualified Git
+import qualified Annex
+import qualified Annex.Branch
+import Git.Types
+import Git.Tree
+import Git.FilePath
+import Git.Ref
+import Git.Sha
+import Git.Log
+import Logs.File
+import Logs
+import Annex.CatFile
+
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Lazy as L
+import Control.Concurrent.STM
+import System.FilePath.ByteString as P
+
+-- | What to use to record a migration. This should be the same Sha that is
+-- used to as the content of the annexed file in the HEAD branch.
+newtype MigrationRecord = MigrationRecord { fromMigrationRecord :: Git.Sha }
+
+-- | Logs a migration from an old to a new key.
+logMigration :: MigrationRecord -> MigrationRecord -> Annex ()
+logMigration old new = do
+	logf <- fromRepo gitAnnexMigrateLog
+	lckf <- fromRepo gitAnnexMigrateLock
+	appendLogFile logf lckf $ L.fromStrict $
+		Git.fromRef' (fromMigrationRecord old)
+			<> " "
+			<> Git.fromRef' (fromMigrationRecord new)
+
+-- | Commits a migration to the git-annex branch.
+commitMigration :: Annex ()
+commitMigration = do
+	logf <- fromRawFilePath <$> fromRepo gitAnnexMigrateLog
+	lckf <- fromRepo gitAnnexMigrateLock
+	nv <- liftIO $ newTVarIO (0 :: Integer)
+	g <- Annex.gitRepo
+	withMkTreeHandle g $ \oldh ->
+		withMkTreeHandle g $ \newh ->
+			streamLogFile logf lckf 
+				(finalizer nv oldh newh g)
+				(processor nv oldh newh)
+  where
+	processor nv oldh newh s = case words s of
+		(old:new:[]) -> do
+			fn <- liftIO $ atomically $ do
+				n <- readTVar nv
+				let !n' = succ n
+				writeTVar nv n'
+				return (asTopFilePath (encodeBS (show n')))
+			let rec h r = liftIO $ sendMkTree h
+				(fromTreeItemType TreeFile)
+				BlobObject
+				(Git.Ref (encodeBS r))
+				fn
+			rec oldh old
+			rec newh new
+		_ -> error "migrate.log parse error"
+	finalizer nv oldh newh g = do
+		oldt <- liftIO $ finishMkTree oldh
+		newt <- liftIO $ finishMkTree newh
+		n <- liftIO $ atomically $ readTVar nv
+		when (n > 0) $ do
+			treesha <- liftIO $ flip recordTree g $ Tree
+				[ RecordedSubTree (asTopFilePath "old") oldt []
+				, RecordedSubTree (asTopFilePath "new") newt []
+				]
+			commitsha <- Annex.Branch.rememberTreeish treesha
+				(asTopFilePath migrationTreeGraftPoint)
+			committedMigration commitsha
+
+-- Streams distributed migrations from the git-annex branch,
+-- and runs the provided action on each old and new key pair.
+--
+-- With the incremental option, only scans as far as the last recorded
+-- migration that this has handled before.
+streamNewDistributedMigrations :: Bool -> (Key -> Key -> Annex ()) -> Annex ()
+streamNewDistributedMigrations incremental a = do
+	void Annex.Branch.update
+	branchsha <- Annex.Branch.getBranch
+	(stoppoint, toskip) <- getPerformedMigrations
+	(l, cleanup) <- inRepo $ getGitLog branchsha
+		(if incremental then stoppoint else Nothing)
+		[fromRawFilePath migrationTreeGraftPoint]
+		-- Need to follow because migrate.tree is grafted in 
+		-- and then deleted, and normally git log stops when a file
+		-- gets deleted.
+		([Param "--reverse", Param "--follow"])
+		(\commit _file -> Just commit)
+	forM_ l (go toskip)
+	liftIO $ void cleanup
+	recordPerformedMigrations branchsha toskip
+  where
+	go toskip c
+		| newref c `elem` nullShas = return ()
+		| changed c `elem` toskip = return ()
+		| not ("/new/" `B.isInfixOf` newfile) = return ()
+		| otherwise = 
+			catKey (newref c) >>= \case
+				Nothing -> return ()
+				Just newkey -> catKey oldfileref >>= \case
+					Nothing -> return ()
+					Just oldkey -> a oldkey newkey
+	  where
+		newfile = toRawFilePath (changedfile c)
+		oldfile = migrationTreeGraftPoint 
+			P.</> "old" 
+			P.</> P.takeBaseName (fromInternalGitPath newfile)
+		oldfileref = branchFileRef (changed c) oldfile
+
+getPerformedMigrations :: Annex (Maybe Sha, [Sha])
+getPerformedMigrations = do
+	logf <- fromRepo gitAnnexMigrationsLog
+	lckf <- fromRepo gitAnnexMigrationsLock
+	ls <- calcLogFile logf lckf [] (:)
+	return $ case reverse ls of
+		[] -> (Nothing, [])
+		(stoppoint:toskip) ->
+			let stoppoint' = conv stoppoint
+			in 
+				( if stoppoint' `elem` nullShas
+					then Nothing
+					else Just stoppoint'
+				, map conv toskip
+				)
+  where
+	conv = Git.Ref . L.toStrict
+
+-- Record locally that migrations have been performed up to the given
+-- commit. The list is additional commits that can be removed from the
+-- log file if present.
+recordPerformedMigrations :: Sha -> [Sha] -> Annex ()
+recordPerformedMigrations commit toremove = do
+	logf <- fromRepo gitAnnexMigrationsLog
+	lckf <- fromRepo gitAnnexMigrationsLock
+	modifyLogFile logf lckf (update . drop 1)
+  where
+	update l = L.fromStrict (fromRef' commit) : filter (`notElem` toremove') l
+	toremove' = map (L.fromStrict . fromRef') toremove
+
+-- Record that a migration was performed locally and committed.
+-- Since committing a migration may result in parent migrations that have
+-- not yet been processed locally, that commit cannot be the first line of
+-- the log file, which is reserved for commits whose parents have also had
+-- their migrations handled. So if the log file does not exist or is empty,
+-- make the first line a null sha.
+committedMigration :: Sha -> Annex ()
+committedMigration commitsha = do
+	logf <- fromRepo gitAnnexMigrationsLog
+	lckf <- fromRepo gitAnnexMigrationsLock
+	modifyLogFile logf lckf update
+  where
+	update [] = [conv deleteSha, conv commitsha]
+	update logged = logged ++ [conv commitsha]
+	conv = L.fromStrict . fromRef'
diff --git a/Logs/Multicast.hs b/Logs/Multicast.hs
new file mode 100644
index 0000000000..1eb2654a6f
--- /dev/null
+++ b/Logs/Multicast.hs
@@ -0,0 +1,43 @@
+{- git-annex multicast fingerprint log
+ -
+ - Copyright 2017, 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Multicast (
+	Fingerprint(..),
+	recordFingerprint,
+	knownFingerPrints,
+) where
+
+import Annex.Common
+import qualified Annex.Branch
+import Logs
+import Logs.UUIDBased
+
+import qualified Data.Map as M
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import Data.ByteString.Builder
+
+newtype Fingerprint = Fingerprint String
+	deriving (Eq, Read, Show)
+
+recordFingerprint :: Fingerprint -> UUID -> Annex ()
+recordFingerprint fp uuid = do
+	c <- currentVectorClock
+	Annex.Branch.change (Annex.Branch.RegardingUUID [uuid]) multicastLog $
+		buildLogOld buildFindgerPrint
+			. changeLog c uuid fp
+			. parseLogOld fingerprintParser
+
+knownFingerPrints :: Annex (M.Map UUID Fingerprint)
+knownFingerPrints = simpleMap . parseLogOld fingerprintParser
+	<$> Annex.Branch.get activityLog
+
+fingerprintParser :: A.Parser Fingerprint
+fingerprintParser = maybe (fail "fingerprint parse failed") pure 
+	. readish . decodeBS =<< A.takeByteString
+
+buildFindgerPrint :: Fingerprint -> Builder
+buildFindgerPrint = byteString . encodeBS . show
diff --git a/Logs/NumCopies.hs b/Logs/NumCopies.hs
new file mode 100644
index 0000000000..7579baf3f3
--- /dev/null
+++ b/Logs/NumCopies.hs
@@ -0,0 +1,66 @@
+{- git-annex numcopies log
+ -
+ - Copyright 2014-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module Logs.NumCopies (
+	setGlobalNumCopies,
+	setGlobalMinCopies,
+	getGlobalNumCopies,
+	getGlobalMinCopies,
+	globalNumCopiesLoad,
+	globalMinCopiesLoad,
+) where
+
+import Annex.Common
+import qualified Annex
+import qualified Annex.Branch
+import Types.NumCopies
+import Logs
+import Logs.SingleValue
+
+instance SingleValueSerializable NumCopies where
+	serialize = encodeBS . show . fromNumCopies
+	deserialize = configuredNumCopies <$$> readish . decodeBS
+
+instance SingleValueSerializable MinCopies where
+	serialize = encodeBS . show . fromMinCopies
+	deserialize = configuredMinCopies <$$> readish . decodeBS
+
+setGlobalNumCopies :: NumCopies -> Annex ()
+setGlobalNumCopies new = do
+	curr <- getGlobalNumCopies
+	when (curr /= Just new) $
+		setLog (Annex.Branch.RegardingUUID []) numcopiesLog new
+
+setGlobalMinCopies :: MinCopies -> Annex ()
+setGlobalMinCopies new = do
+	curr <- getGlobalMinCopies
+	when (curr /= Just new) $
+		setLog (Annex.Branch.RegardingUUID []) mincopiesLog new
+
+{- Value configured in the numcopies log. Cached for speed. -}
+getGlobalNumCopies :: Annex (Maybe NumCopies)
+getGlobalNumCopies = maybe globalNumCopiesLoad return
+	=<< Annex.getState Annex.globalnumcopies
+
+{- Value configured in the mincopies log. Cached for speed. -}
+getGlobalMinCopies :: Annex (Maybe MinCopies)
+getGlobalMinCopies = maybe globalMinCopiesLoad return
+	=<< Annex.getState Annex.globalmincopies
+
+globalNumCopiesLoad :: Annex (Maybe NumCopies)
+globalNumCopiesLoad = do
+	v <- getLog numcopiesLog
+	Annex.changeState $ \s -> s { Annex.globalnumcopies = Just v }
+	return v
+
+globalMinCopiesLoad :: Annex (Maybe MinCopies)
+globalMinCopiesLoad = do
+	v <- getLog mincopiesLog
+	Annex.changeState $ \s -> s { Annex.globalmincopies = Just v }
+	return v
diff --git a/Logs/PreferredContent.hs b/Logs/PreferredContent.hs
new file mode 100644
index 0000000000..c0f30c3c8f
--- /dev/null
+++ b/Logs/PreferredContent.hs
@@ -0,0 +1,206 @@
+{- git-annex preferred content matcher configuration
+ -
+ - Copyright 2012-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.PreferredContent (
+	preferredContentSet,
+	requiredContentSet,
+	groupPreferredContentSet,
+	isPreferredContent,
+	isRequiredContent,
+	preferredContentMap,
+	preferredContentMapRaw,
+	requiredContentMap,
+	requiredContentMapRaw,
+	groupPreferredContentMapRaw,
+	checkPreferredContentExpression,
+	setStandardGroup,
+	defaultStandardGroup,
+	preferredRequiredMapsLoad,
+	preferredRequiredMapsLoad',
+	introspectPreferredRequiredContent,
+	prop_standardGroups_parse,
+) where
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import Data.Either
+import qualified Data.Attoparsec.ByteString.Lazy as A
+
+import Annex.Common
+import Logs.PreferredContent.Raw
+import qualified Annex.Branch
+import qualified Annex
+import Logs
+import Logs.UUIDBased
+import Utility.Matcher
+import Annex.FileMatcher
+import Annex.UUID
+import Types.Group
+import Types.Remote (RemoteConfig)
+import Logs.Group
+import Logs.Remote
+import Types.StandardGroups
+import Limit
+
+{- Checks if a file is preferred content (or required content) for the
+ - specified repository (or the current repository if none is specified). -}
+isPreferredContent :: Maybe UUID -> AssumeNotPresent -> Maybe Key -> AssociatedFile -> Bool -> Annex Bool
+isPreferredContent = checkMap preferredContentMap
+
+isRequiredContent :: Maybe UUID -> AssumeNotPresent -> Maybe Key -> AssociatedFile -> Bool -> Annex Bool
+isRequiredContent = checkMap requiredContentMap
+
+checkMap :: Annex (FileMatcherMap Annex) -> Maybe UUID -> AssumeNotPresent -> Maybe Key -> AssociatedFile -> Bool -> Annex Bool
+checkMap getmap mu notpresent mkey afile d = do
+	u <- maybe getUUID return mu
+	m <- getmap
+	case M.lookup u m of
+		Nothing -> return d
+		Just matcher -> checkMatcher matcher mkey afile notpresent (return d) (return d)
+
+{- Checks if the preferred or required content for the specified repository
+ - (or the current repository if none is specified) contains any terms
+ - that meet the condition. -}
+introspectPreferredRequiredContent :: (MatchFiles Annex -> Bool) -> Maybe UUID -> Annex Bool
+introspectPreferredRequiredContent c mu = do
+	u <- maybe getUUID return mu
+	check u preferredContentMap <||> check u requiredContentMap
+  where
+	check u mk = mk >>= return . maybe False (any c . fst) . M.lookup u
+
+preferredContentMap :: Annex (FileMatcherMap Annex)
+preferredContentMap = maybe (fst <$> preferredRequiredMapsLoad preferredContentTokens) return
+	=<< Annex.getState Annex.preferredcontentmap
+
+requiredContentMap :: Annex (FileMatcherMap Annex)
+requiredContentMap = maybe (snd <$> preferredRequiredMapsLoad preferredContentTokens) return
+	=<< Annex.getState Annex.requiredcontentmap
+
+preferredRequiredMapsLoad :: (PreferredContentData -> [ParseToken (MatchFiles Annex)]) -> Annex (FileMatcherMap Annex, FileMatcherMap Annex)
+preferredRequiredMapsLoad mktokens = do
+	(pc, rc) <- preferredRequiredMapsLoad' id mktokens
+	let pc' = handleunknown (MatcherDesc "preferred content") pc
+	let rc' = handleunknown (MatcherDesc "required content") rc
+	Annex.changeState $ \s -> s
+		{ Annex.preferredcontentmap = Just pc'
+		, Annex.requiredcontentmap = Just rc'
+		}
+	return (pc', rc')
+  where
+	handleunknown matcherdesc = M.mapWithKey $ \u v ->
+		(either (const $ unknownMatcher u) id v, matcherdesc)
+
+preferredRequiredMapsLoad' :: (Matcher (MatchFiles Annex) -> Matcher (MatchFiles Annex)) -> (PreferredContentData -> [ParseToken (MatchFiles Annex)]) -> Annex (M.Map UUID (Either String (Matcher (MatchFiles Annex))), M.Map UUID (Either String (Matcher (MatchFiles Annex))))
+preferredRequiredMapsLoad' matcherf mktokens = do
+	groupmap <- groupMap
+	configmap <- remoteConfigMap
+	let genmap l gm = 
+		let mk u = makeMatcher groupmap configmap gm u matcherf mktokens
+		in simpleMap
+			. parseLogOldWithUUID (\u -> mk u . decodeBS <$> A.takeByteString)
+			<$> Annex.Branch.get l
+	gm <- groupPreferredContentMapRaw
+	pc <- genmap preferredContentLog gm
+	rc <- genmap requiredContentLog gm
+	-- Required content is implicitly also preferred content, so combine.
+	let pc' = M.unionWith combiner pc rc
+	return (pc', rc)
+  where
+	combiner (Right a) (Right b) = Right (combineMatchers a b)
+	combiner (Left a)  (Left b)  = Left (a ++ " " ++ b)
+	combiner (Left a)  (Right _) = Left a
+	combiner (Right _) (Left b)  = Left b
+
+{- This intentionally never fails, even on unparsable expressions,
+ - because the configuration is shared among repositories and newer
+ - versions of git-annex may add new features. -}
+makeMatcher
+	:: GroupMap
+	-> M.Map UUID RemoteConfig
+	-> M.Map Group PreferredContentExpression
+	-> UUID
+	-> (Matcher (MatchFiles Annex) -> Matcher (MatchFiles Annex))
+	-> (PreferredContentData -> [ParseToken (MatchFiles Annex)])
+	-> PreferredContentExpression
+	-> Either String (Matcher (MatchFiles Annex))
+makeMatcher groupmap configmap groupwantedmap u matcherf mktokens = go True True
+  where
+	go expandstandard expandgroupwanted expr
+		| null (lefts tokens) = Right $ matcherf $ generate $ rights tokens
+		| otherwise = Left $ unwords $ lefts tokens
+	  where
+		tokens = preferredContentParser (mktokens pcd) expr
+		pcd = PCD
+			{ matchStandard = matchstandard
+			, matchGroupWanted = matchgroupwanted
+			, getGroupMap = pure groupmap
+			, configMap = configmap
+			, repoUUID = Just u
+			}
+		matchstandard
+			| expandstandard = maybe (Right $ unknownMatcher u) (go False False)
+				(standardPreferredContent <$> getStandardGroup mygroups)
+			| otherwise = Right $ unknownMatcher u
+		matchgroupwanted
+			| expandgroupwanted = maybe (Right $ unknownMatcher u) (go True False)
+				(groupwanted mygroups)
+			| otherwise = Right $ unknownMatcher u
+		mygroups = fromMaybe S.empty (u `M.lookup` groupsByUUID groupmap)
+		groupwanted s = case M.elems $ M.filterWithKey (\k _ -> S.member k s) groupwantedmap of
+			[pc] -> Just pc
+			_ -> Nothing
+
+{- When a preferred content expression cannot be parsed, but is already
+ - in the log (eg, put there by a newer version of git-annex),
+ - the fallback behavior is to match only files that are currently present.
+ -
+ - This avoid unwanted/expensive changes to the content, until the problem
+ - is resolved. -}
+unknownMatcher :: UUID -> Matcher (MatchFiles Annex)
+unknownMatcher u = generate [present]
+  where
+	present = Operation $ limitPresent (Just u)
+
+{- Checks if an expression can be parsed, if not returns Just error -}
+checkPreferredContentExpression :: PreferredContentExpression -> Maybe String
+checkPreferredContentExpression expr = 
+	case parsedToMatcher (MatcherDesc mempty) tokens of
+		Left e -> Just e
+		Right _ -> Nothing
+  where
+	tokens = preferredContentParser (preferredContentTokens pcd) expr
+	pcd = PCD
+		{ matchStandard = Right matchAll
+		, matchGroupWanted = Right matchAll
+		, getGroupMap = pure emptyGroupMap
+		, configMap = M.empty
+		, repoUUID = Nothing
+		}
+
+{- Puts a UUID in a standard group, and sets its preferred content to use
+ - the standard expression for that group (unless preferred content is
+ - already set). -}
+setStandardGroup :: UUID -> StandardGroup -> Annex ()
+setStandardGroup u g = do
+	groupSet u $ S.singleton $ fromStandardGroup g
+	unlessM (isJust . M.lookup u <$> preferredContentMap) $
+		preferredContentSet u "standard"
+
+{- Avoids overwriting the UUID's standard group or preferred content
+ - when it's already been configured. -}
+defaultStandardGroup :: UUID -> StandardGroup -> Annex ()
+defaultStandardGroup u g = 
+	unlessM (hasgroup <||> haspc) $
+		setStandardGroup u g
+  where
+	hasgroup = not . S.null <$> lookupGroups u
+	haspc = isJust . M.lookup u <$> preferredContentMap
+
+prop_standardGroups_parse :: Bool
+prop_standardGroups_parse = 
+	all (isNothing . checkPreferredContentExpression . standardPreferredContent)
+		[ minBound .. maxBound]
diff --git a/Logs/PreferredContent/Raw.hs b/Logs/PreferredContent/Raw.hs
new file mode 100644
index 0000000000..b5a1b3932c
--- /dev/null
+++ b/Logs/PreferredContent/Raw.hs
@@ -0,0 +1,84 @@
+{- unparsed preferred content expressions
+ -
+ - Copyright 2012-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.PreferredContent.Raw where
+
+import Annex.Common
+import qualified Annex.Branch
+import qualified Annex
+import Logs
+import Logs.UUIDBased
+import Logs.MapLog
+import Types.StandardGroups
+import Types.Group
+
+import qualified Data.Map as M
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import Data.ByteString.Builder
+
+{- Changes the preferred content configuration of a remote. -}
+preferredContentSet :: UUID -> PreferredContentExpression -> Annex ()
+preferredContentSet = setLog preferredContentLog
+
+requiredContentSet :: UUID -> PreferredContentExpression -> Annex ()
+requiredContentSet = setLog requiredContentLog
+
+setLog :: RawFilePath -> UUID -> PreferredContentExpression -> Annex ()
+setLog logfile uuid@(UUID _) val = do
+	c <- currentVectorClock
+	Annex.Branch.change (Annex.Branch.RegardingUUID [uuid]) logfile $
+		buildLogOld buildPreferredContentExpression
+		. changeLog c uuid val
+		. parseLogOld parsePreferredContentExpression
+	Annex.changeState $ \s -> s 
+		{ Annex.preferredcontentmap = Nothing
+		, Annex.requiredcontentmap = Nothing
+		}
+setLog _ NoUUID _ = error "unknown UUID; cannot modify"
+
+{- Changes the preferred content configuration of a group. -}
+groupPreferredContentSet :: Group -> PreferredContentExpression -> Annex ()
+groupPreferredContentSet g val = do
+	c <- currentVectorClock
+	Annex.Branch.change
+		(Annex.Branch.RegardingUUID [])
+		groupPreferredContentLog $
+		buildGroupPreferredContent
+		. changeMapLog c g val 
+		. parseGroupPreferredContent
+	Annex.changeState $ \s -> s { Annex.preferredcontentmap = Nothing }
+
+parseGroupPreferredContent :: L.ByteString -> MapLog Group String
+parseGroupPreferredContent = parseMapLog parsegroup parsestring
+  where
+	parsegroup = Group <$> A.takeByteString
+	parsestring = decodeBS <$> A.takeByteString
+
+buildGroupPreferredContent :: MapLog Group PreferredContentExpression -> Builder
+buildGroupPreferredContent = buildMapLog buildgroup buildexpr
+  where
+	buildgroup (Group g) = byteString g
+	buildexpr = byteString . encodeBS
+
+parsePreferredContentExpression :: A.Parser PreferredContentExpression
+parsePreferredContentExpression = decodeBS <$> A.takeByteString
+
+buildPreferredContentExpression :: PreferredContentExpression -> Builder
+buildPreferredContentExpression = byteString . encodeBS
+
+preferredContentMapRaw :: Annex (M.Map UUID PreferredContentExpression)
+preferredContentMapRaw = simpleMap . parseLogOld parsePreferredContentExpression
+	<$> Annex.Branch.get preferredContentLog
+
+requiredContentMapRaw :: Annex (M.Map UUID PreferredContentExpression)
+requiredContentMapRaw = simpleMap . parseLogOld parsePreferredContentExpression
+	<$> Annex.Branch.get requiredContentLog
+
+groupPreferredContentMapRaw :: Annex (M.Map Group PreferredContentExpression)
+groupPreferredContentMapRaw = simpleMap . parseGroupPreferredContent
+	<$> Annex.Branch.get groupPreferredContentLog
diff --git a/Logs/Presence.hs b/Logs/Presence.hs
new file mode 100644
index 0000000000..f96c455684
--- /dev/null
+++ b/Logs/Presence.hs
@@ -0,0 +1,86 @@
+{- git-annex presence log
+ -
+ - This is used to store presence information in the git-annex branch in
+ - a way that can be union merged.
+ -
+ - A line of the log will look like: "date N INFO"
+ - Where N=1 when the INFO is present, 0 otherwise.
+ - 
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Presence (
+	module X,
+	addLog,
+	addLog',
+	maybeAddLog,
+	readLog,
+	presentLogInfo,
+	notPresentLogInfo,
+	historicalLogInfo,
+) where
+
+import Logs.Presence.Pure as X
+import Annex.Common
+import Annex.VectorClock
+import qualified Annex.Branch
+import Git.Types (RefDate)
+
+{- Adds to the log, removing any LogLines that are obsoleted. -}
+addLog :: Annex.Branch.RegardingUUID -> RawFilePath -> LogStatus -> LogInfo -> Annex ()
+addLog ru file logstatus loginfo = 
+	addLog' ru file logstatus loginfo =<< currentVectorClock
+
+addLog' :: Annex.Branch.RegardingUUID -> RawFilePath -> LogStatus -> LogInfo -> CandidateVectorClock -> Annex ()
+addLog' ru file logstatus loginfo c = 
+	Annex.Branch.changeOrAppend ru file $ \b ->
+		let old = parseLog b
+		    line = genLine logstatus loginfo c old
+		in if isNewInfo line old
+			then Annex.Branch.Append $ buildLog [line]
+			else Annex.Branch.Change $ buildLog $
+				compactLog (line : old)
+
+{- When a LogLine already exists with the same status and info, but an
+ - older timestamp, that LogLine is preserved, rather than updating the log
+ - with a newer timestamp.
+ -}
+maybeAddLog :: Annex.Branch.RegardingUUID -> RawFilePath -> LogStatus -> LogInfo -> Annex ()
+maybeAddLog ru file logstatus loginfo = do
+	c <- currentVectorClock
+	Annex.Branch.maybeChange ru file $ \b ->
+		let old = parseLog b
+		    line = genLine logstatus loginfo c old
+		in do
+			m <- insertNewStatus line $ logMap old
+			return $ buildLog $ mapLog m
+
+genLine :: LogStatus -> LogInfo -> CandidateVectorClock -> [LogLine] -> LogLine
+genLine logstatus loginfo c old = LogLine c' logstatus loginfo
+  where
+	oldcs = map date (filter (\l -> info l == loginfo) old)
+	c' = advanceVectorClock c oldcs
+
+{- Reads a log file.
+ - Note that the LogLines returned may be in any order. -}
+readLog :: RawFilePath -> Annex [LogLine]
+readLog = parseLog <$$> Annex.Branch.get
+
+{- Reads a log and returns only the info that is still present. -}
+presentLogInfo :: RawFilePath -> Annex [LogInfo]
+presentLogInfo file = map info . filterPresent <$> readLog file
+
+{- Reads a log and returns only the info that is no longer present. -}
+notPresentLogInfo :: RawFilePath -> Annex [LogInfo]
+notPresentLogInfo file = map info . filterNotPresent <$> readLog file
+
+{- Reads a historical version of a log and returns the info that was in
+ - effect at that time. 
+ -
+ - The date is formatted as shown in gitrevisions man page.
+ -}
+historicalLogInfo :: RefDate -> RawFilePath -> Annex [LogInfo]
+historicalLogInfo refdate file = map info . filterPresent . parseLog
+	<$> Annex.Branch.getHistorical refdate file
diff --git a/Logs/Presence/Pure.hs b/Logs/Presence/Pure.hs
new file mode 100644
index 0000000000..8ed6ed541a
--- /dev/null
+++ b/Logs/Presence/Pure.hs
@@ -0,0 +1,144 @@
+{- git-annex presence log, pure operations
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Presence.Pure where
+
+import Annex.Common
+import Annex.VectorClock
+import Logs.Line
+import Utility.QuickCheck
+
+import qualified Data.Map as M
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as C8
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import Data.Attoparsec.ByteString.Char8 (char, anyChar)
+import Data.ByteString.Builder
+import Data.Char
+
+newtype LogInfo = LogInfo { fromLogInfo :: S.ByteString }
+	deriving (Show, Eq, Ord)
+
+data LogLine = LogLine
+	{ date :: VectorClock
+	, status :: LogStatus
+	, info :: LogInfo
+	} deriving (Eq, Show)
+
+data LogStatus = InfoPresent | InfoMissing | InfoDead
+	deriving (Eq, Show, Bounded, Enum)
+
+parseLog :: L.ByteString -> [LogLine]
+parseLog = fromMaybe [] . A.maybeResult . A.parse logParser
+
+logParser :: A.Parser [LogLine]
+logParser = parseLogLines $ LogLine
+	<$> vectorClockParser
+	<* char ' '
+	<*> statusParser
+	<* char ' '
+	<*> (LogInfo <$> A.takeByteString)
+
+statusParser :: A.Parser LogStatus
+statusParser = do
+	c <- anyChar
+	case c of
+		'1' -> return InfoPresent
+		'0' -> return InfoMissing
+		'X' -> return InfoDead
+		_ -> fail "unknown status character"
+
+parseStatus :: String -> Maybe LogStatus
+parseStatus "1" = Just InfoPresent
+parseStatus "0" = Just InfoMissing
+parseStatus "X" = Just InfoDead
+parseStatus _ = Nothing
+
+buildLog :: [LogLine] -> Builder
+buildLog = mconcat . map genline
+  where
+	genline (LogLine c s (LogInfo i)) = 
+		buildVectorClock c <> sp <> genstatus s <> sp <> byteString i <> nl
+	sp = charUtf8 ' '
+	nl = charUtf8 '\n'
+	genstatus InfoPresent = charUtf8 '1'
+	genstatus InfoMissing = charUtf8 '0'
+	genstatus InfoDead = charUtf8 'X'
+
+{- Given a log, returns only the info that is still present. -}
+getLog :: L.ByteString -> [LogInfo]
+getLog = map info . filterPresent . parseLog
+
+{- Returns the info from LogLines that is present. -}
+filterPresent :: [LogLine] -> [LogLine]
+filterPresent = filter (\l -> InfoPresent == status l) . compactLog
+
+{- Returns the info from LogLines that is not present. -}
+filterNotPresent :: [LogLine] -> [LogLine]
+filterNotPresent = filter (\l -> InfoPresent /= status l) . compactLog
+
+{- Compacts a set of logs, returning a subset that contains the current
+ - status. -}
+compactLog :: [LogLine] -> [LogLine]
+compactLog = mapLog . logMap
+
+type LogMap = M.Map LogInfo LogLine
+
+mapLog :: LogMap -> [LogLine]
+mapLog = M.elems
+
+logMap :: [LogLine] -> LogMap
+logMap = foldr insertNewerLogLine M.empty
+
+{- Check if the info of the given line is not in the list of LogLines. -}
+isNewInfo :: LogLine -> [LogLine] -> Bool
+isNewInfo l old = not (any issame old)
+  where
+	issame l' = info l' == info l
+
+insertBetter :: (LogLine -> Bool) -> LogLine -> LogMap -> Maybe LogMap
+insertBetter betterthan l m
+	| better = Just (M.insert i l m)
+	| otherwise = Nothing
+  where
+	better = maybe True betterthan (M.lookup i m)
+	i = info l
+
+{- Inserts a log into a map of logs, if the log has newer
+ - information than the other logs in the map for the same info. -}
+insertNewerLogLine :: LogLine -> LogMap -> LogMap
+insertNewerLogLine l m = fromMaybe m $ insertBetter newer l m
+  where
+	newer l' = date l' <= date l
+
+{- Inserts the log unless there's already one in the map with
+ - the same status for its info, in which case there's no need to
+ - change anything, to avoid log churn. -}
+insertNewStatus :: LogLine -> LogMap -> Maybe LogMap
+insertNewStatus l m  = insertBetter diffstatus l m
+  where
+	diffstatus l' = status l' /= status l
+
+instance Arbitrary LogLine where
+	arbitrary = LogLine
+		<$> arbitrary
+		<*> elements [minBound..maxBound]
+		<*> (LogInfo <$> arbinfo)
+	  where
+	  	-- Avoid newline characters, which cannot appear in 
+		-- LogInfo.
+		--
+		-- Avoid non-ascii values because fully arbitrary
+		-- strings may not be encoded using the filesystem
+		-- encoding, which is normally applied to all input.
+		arbinfo = (encodeBS <$> arbitrary `suchThat` all isAscii)
+			`suchThat` (\b -> C8.notElem '\n' b && C8.notElem '\r' b)
+
+prop_parse_build_presence_log :: [LogLine] -> Bool
+prop_parse_build_presence_log l =
+	parseLog (toLazyByteString (buildLog l)) == l
diff --git a/Logs/Remote.hs b/Logs/Remote.hs
new file mode 100644
index 0000000000..7e5a4a5109
--- /dev/null
+++ b/Logs/Remote.hs
@@ -0,0 +1,56 @@
+{- git-annex remote log
+ - 
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
+ - 
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Remote (
+	remoteLog,
+	remoteConfigMap,
+	readRemoteLog,
+	configSet,
+	keyValToConfig,
+	configToKeyVal,
+	showConfig,
+
+	prop_isomorphic_configEscape,
+	prop_parse_show_Config,
+) where
+
+import Annex.Common
+import qualified Annex
+import qualified Annex.Branch
+import Types.Remote
+import Logs
+import Logs.UUIDBased
+import Logs.Remote.Pure
+import Annex.SpecialRemote.Config
+
+import qualified Data.Map as M
+
+{- Adds or updates a remote's config in the log. -}
+configSet :: UUID -> RemoteConfig -> Annex ()
+configSet u cfg = do
+	c <- currentVectorClock
+	Annex.Branch.change (Annex.Branch.RegardingUUID [u]) remoteLog $
+		buildRemoteConfigLog
+			. changeLog c u (removeSameasInherited cfg)
+			. parseRemoteConfigLog
+	Annex.changeState $ \s -> s { Annex.remoteconfigmap = Nothing }
+
+{- Map of remotes by uuid containing key/value config maps.
+ - Cached for speed. -}
+remoteConfigMap :: Annex (M.Map UUID RemoteConfig)
+remoteConfigMap = maybe remoteConfigMapLoad return
+	=<< Annex.getState Annex.remoteconfigmap
+
+remoteConfigMapLoad :: Annex (M.Map UUID RemoteConfig)
+remoteConfigMapLoad = do
+	m <- readRemoteLog
+	Annex.changeState $ \s -> s { Annex.remoteconfigmap = Just m }
+	return m
+
+readRemoteLog :: Annex (M.Map UUID RemoteConfig)
+readRemoteLog = calcRemoteConfigMap 
+	<$> Annex.Branch.get remoteLog
diff --git a/Logs/Remote/Pure.hs b/Logs/Remote/Pure.hs
new file mode 100644
index 0000000000..e60c18b1f3
--- /dev/null
+++ b/Logs/Remote/Pure.hs
@@ -0,0 +1,108 @@
+{- git-annex remote log, pure operations
+ - 
+ - Copyright 2011-2019 Joey Hess <id@joeyh.name>
+ - 
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Remote.Pure (
+	calcRemoteConfigMap,
+	parseRemoteConfigLog,
+	buildRemoteConfigLog,
+        keyValToConfig,
+        configToKeyVal,
+        showConfig,
+
+        prop_isomorphic_configEscape,
+        prop_parse_show_Config,
+) where
+
+import Annex.Common
+import Types.Remote
+import Types.ProposedAccepted
+import Logs.UUIDBased
+import Annex.SpecialRemote.Config
+import Utility.QuickCheck
+
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Map as M
+import Data.Char
+import qualified Data.Attoparsec.ByteString as A
+import Data.ByteString.Builder
+
+calcRemoteConfigMap :: L.ByteString -> M.Map UUID RemoteConfig
+calcRemoteConfigMap = (\m -> M.map (addSameasInherited m) m)
+	. simpleMap
+	. parseRemoteConfigLog
+
+parseRemoteConfigLog :: L.ByteString -> Log RemoteConfig
+parseRemoteConfigLog = parseLogOld remoteConfigParser
+
+buildRemoteConfigLog :: Log RemoteConfig -> Builder
+buildRemoteConfigLog = buildLogOld (byteString . encodeBS . showConfig)
+
+remoteConfigParser :: A.Parser RemoteConfig
+remoteConfigParser = keyValToConfig Accepted . words . decodeBS <$> A.takeByteString
+
+showConfig :: RemoteConfig -> String
+showConfig = unwords . configToKeyVal
+
+{- Given Strings like "key=value", generates a RemoteConfig. -}
+keyValToConfig :: (String -> ProposedAccepted String) -> [String] -> RemoteConfig
+keyValToConfig mk ws = M.fromList $ map (/=/) ws
+  where
+	(/=/) s = (mk k, mk v)
+	  where
+		k = takeWhile (/= '=') s
+		v = configUnEscape $ drop (1 + length k) s
+
+configToKeyVal :: RemoteConfig -> [String]
+configToKeyVal m = map toword $ sort $ M.toList m
+  where
+	toword (k, v) = fromProposedAccepted k ++ "=" ++ configEscape (fromProposedAccepted v)
+
+configEscape :: String -> String
+configEscape = concatMap escape
+  where
+	escape c
+		| isSpace c || c `elem` "&" = "&" ++ show (ord c) ++ ";"
+		| otherwise = [c]
+
+configUnEscape :: String -> String
+configUnEscape = unescape
+  where
+	unescape [] = []
+	unescape (c:rest)
+		| c == '&' = entity rest
+		| otherwise = c : unescape rest
+	entity s
+		| not (null num) && ";" `isPrefixOf` r =
+			chr (Prelude.read num) : unescape rest
+		| otherwise =
+			'&' : unescape s
+	  where
+		num = takeWhile isNumber s
+		r = drop (length num) s
+		rest = drop 1 r
+
+{- for quickcheck -}
+prop_isomorphic_configEscape :: TestableString -> Bool
+prop_isomorphic_configEscape ts = s == (configUnEscape . configEscape) s
+  where
+	s = fromTestableString ts
+
+prop_parse_show_Config :: RemoteConfig -> Bool
+prop_parse_show_Config c
+	-- whitespace and '=' are not supported in config keys
+	| any (\k -> any isSpace k || elem '=' k) (map fromProposedAccepted $ M.keys c) = True
+	| any (any excluded) (map fromProposedAccepted $ M.keys c) = True
+	| any (any excluded) (map fromProposedAccepted $ M.elems c) = True
+	| otherwise = A.parseOnly remoteConfigParser (encodeBS $ showConfig c) ~~ Right c
+  where
+	normalize v = sort . M.toList <$> v
+	a ~~ b = normalize a == normalize b
+	-- limit to ascii alphanumerics for simplicity; characters not
+	-- allowed by the current character set in the config may not
+	-- round-trip in an identical representation due to the use of the
+	-- filesystem encoding.
+	excluded ch = not (isAlphaNum ch) || not (isAscii ch)
diff --git a/Logs/RemoteState.hs b/Logs/RemoteState.hs
new file mode 100644
index 0000000000..6bf1431456
--- /dev/null
+++ b/Logs/RemoteState.hs
@@ -0,0 +1,49 @@
+{- Remote state logs.
+ -
+ - Copyright 2014, 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.RemoteState (
+	getRemoteState,
+	setRemoteState,
+) where
+
+import Annex.Common
+import Types.RemoteState
+import Logs
+import Logs.UUIDBased
+import Logs.MapLog
+import qualified Annex.Branch
+import qualified Annex
+
+import qualified Data.Map as M
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import Data.ByteString.Builder
+
+type RemoteState = String
+
+setRemoteState :: RemoteStateHandle -> Key -> RemoteState -> Annex ()
+setRemoteState (RemoteStateHandle u) k s = do
+	c <- currentVectorClock
+	config <- Annex.getGitConfig
+	Annex.Branch.change
+		(Annex.Branch.RegardingUUID [u])
+		(remoteStateLogFile config k)
+		(buildRemoteState . changeLog c u s . parseRemoteState)
+
+buildRemoteState :: Log RemoteState -> Builder
+buildRemoteState = buildLogNew (byteString . encodeBS)
+
+getRemoteState :: RemoteStateHandle -> Key -> Annex (Maybe RemoteState)
+getRemoteState (RemoteStateHandle u) k = do
+	config <- Annex.getGitConfig
+	extract . fromMapLog . parseRemoteState
+		<$> Annex.Branch.get (remoteStateLogFile config k)
+  where
+	extract m = value <$> M.lookup u m
+
+parseRemoteState :: L.ByteString -> Log RemoteState
+parseRemoteState = parseLogNew (decodeBS <$> A.takeByteString)
diff --git a/Logs/Restage.hs b/Logs/Restage.hs
new file mode 100644
index 0000000000..5d4e2e0910
--- /dev/null
+++ b/Logs/Restage.hs
@@ -0,0 +1,96 @@
+{- git-annex restage log file
+ -
+ - Copyright 2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Logs.Restage where
+
+import Annex.Common
+import Git.FilePath
+import Logs.File
+import Utility.InodeCache
+import Annex.LockFile
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import qualified Utility.RawFilePath as R
+
+-- | Log a file whose pointer needs to be restaged in git.
+-- The content of the file may not be a pointer, if it is populated with
+-- the annex content. The InodeCache is used to verify that the file
+-- still contains the content, and it's still safe to restage its pointer.
+writeRestageLog :: TopFilePath -> InodeCache -> Annex ()
+writeRestageLog f ic = do
+	logf <- fromRepo gitAnnexRestageLog
+	lckf <- fromRepo gitAnnexRestageLock
+	appendLogFile logf lckf $ L.fromStrict $ formatRestageLog f ic
+
+-- | Streams the content of the restage log.
+--
+-- First, the content of the log file is moved to the restage.old file.
+-- If that file already exists, the content is appended, otherwise it's
+-- renamed to that.
+--
+-- The log file is kept locked during that, but the lock is then
+-- released. The processor may do something that itself needs to take the
+-- lock, so it's important that the lock not be held while running it.
+--
+-- The content of restage.old file is then streamed to the processor, 
+-- and then the finalizer is run, ending with emptying restage.old.
+--
+-- If the processor or finalizer is interrupted or throws an exception,
+-- restage.old is left populated to be processed later.
+streamRestageLog :: Annex () -> (TopFilePath -> InodeCache -> Annex ()) -> Annex ()
+streamRestageLog finalizer processor = do
+	logf <- fromRepo gitAnnexRestageLog
+	oldf <- fromRepo gitAnnexRestageLogOld
+	let oldf' = fromRawFilePath oldf
+	lckf <- fromRepo gitAnnexRestageLock
+	
+	withExclusiveLock lckf $ liftIO $
+		whenM (R.doesPathExist logf) $
+			ifM (R.doesPathExist oldf)
+				( do
+					h <- openFile oldf' AppendMode
+					hPutStr h =<< readFile (fromRawFilePath logf)
+					hClose h
+					liftIO $ removeWhenExistsWith R.removeLink logf
+				, moveFile logf oldf
+				)
+
+	streamLogFileUnsafe oldf' finalizer $ \l -> 
+		case parseRestageLog l of
+			Just (f, ic) -> processor f ic
+			Nothing -> noop
+	
+	liftIO $ removeWhenExistsWith R.removeLink oldf
+
+-- | Calculate over both the current restage log, and also over the old
+-- one if it had started to be processed but did not get finished due
+-- to an interruption.
+calcRestageLog :: t -> ((TopFilePath, InodeCache) -> t -> t) -> Annex t
+calcRestageLog start update = do
+	logf <- fromRepo gitAnnexRestageLog
+	oldf <- fromRepo gitAnnexRestageLogOld
+	lckf <- fromRepo gitAnnexRestageLock
+	withSharedLock lckf $ do
+		mid <- calcLogFileUnsafe logf start process
+		calcLogFileUnsafe oldf mid process
+  where
+	process l v = case parseRestageLog (decodeBL l) of
+		Just pl -> update pl v
+		Nothing -> v
+
+formatRestageLog :: TopFilePath -> InodeCache -> S.ByteString
+formatRestageLog f ic = encodeBS (showInodeCache ic) <> ":" <> getTopFilePath f
+
+parseRestageLog :: String -> Maybe (TopFilePath, InodeCache)
+parseRestageLog l = 
+	let (ics, f) = separate (== ':') l
+	in do
+		ic <- readInodeCache ics
+		return (asTopFilePath (toRawFilePath f), ic)
diff --git a/Logs/Schedule.hs b/Logs/Schedule.hs
new file mode 100644
index 0000000000..7abcf14da8
--- /dev/null
+++ b/Logs/Schedule.hs
@@ -0,0 +1,74 @@
+{- git-annex scheduled activities log
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Schedule (
+	scheduleLog,
+	scheduleSet,
+	scheduleAdd,
+	scheduleRemove,
+	scheduleChange,
+	scheduleGet,
+	scheduleMap,
+	getLastRunTimes,
+	setLastRunTime,
+) where
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import Data.Time.LocalTime
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import Data.ByteString.Builder
+
+import Annex.Common
+import Types.ScheduledActivity
+import qualified Annex.Branch
+import Logs
+import Logs.UUIDBased
+import Logs.File
+
+scheduleSet :: UUID -> [ScheduledActivity] -> Annex ()
+scheduleSet uuid@(UUID _) activities = do
+	c <- currentVectorClock
+	Annex.Branch.change (Annex.Branch.RegardingUUID [uuid]) scheduleLog $
+		buildLogOld byteString 
+			. changeLog c uuid (encodeBS val)
+			. parseLogOld A.takeByteString
+  where
+	val = fromScheduledActivities activities
+scheduleSet NoUUID _ = error "unknown UUID; cannot modify"
+
+scheduleMap :: Annex (M.Map UUID [ScheduledActivity])
+scheduleMap = simpleMap . parseLogOld parser <$> Annex.Branch.get scheduleLog
+  where
+	parser = either fail pure . parseScheduledActivities . decodeBS 
+		=<< A.takeByteString
+
+scheduleGet :: UUID -> Annex (S.Set ScheduledActivity)
+scheduleGet u = do
+	m <- scheduleMap
+	return $ maybe S.empty S.fromList (M.lookup u m)
+
+scheduleRemove :: UUID -> ScheduledActivity -> Annex ()
+scheduleRemove u activity = scheduleChange u $ S.delete activity
+
+scheduleAdd :: UUID -> ScheduledActivity -> Annex ()
+scheduleAdd u activity = scheduleChange u $ S.insert activity
+
+scheduleChange :: UUID -> (S.Set ScheduledActivity -> S.Set ScheduledActivity) -> Annex ()
+scheduleChange u a = scheduleSet u . S.toList . a =<< scheduleGet u
+
+getLastRunTimes :: Annex (M.Map ScheduledActivity LocalTime)
+getLastRunTimes = do
+	f <- fromRawFilePath <$> fromRepo gitAnnexScheduleState
+	liftIO $ fromMaybe M.empty
+		<$> catchDefaultIO Nothing (readish <$> readFile f)
+
+setLastRunTime :: ScheduledActivity -> LocalTime -> Annex ()
+setLastRunTime activity lastrun = do
+	f <- fromRepo gitAnnexScheduleState
+	writeLogFile f . show . M.insert activity lastrun
+		=<< getLastRunTimes
diff --git a/Logs/SingleValue.hs b/Logs/SingleValue.hs
new file mode 100644
index 0000000000..2018e73ee7
--- /dev/null
+++ b/Logs/SingleValue.hs
@@ -0,0 +1,42 @@
+{-# LANGUAGE ScopedTypeVariables #-}
+
+{- git-annex single-value log
+ -
+ - This is used to store a value in a way that can be union merged.
+ -
+ - A line of the log will look like: "timestamp value"
+ -
+ - The line with the newest timestamp wins.
+ -
+ - Copyright 2014-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.SingleValue (
+	module Logs.SingleValue.Pure,
+	readLog,
+	getLog,
+	setLog,
+) where
+
+import Annex.Common
+import qualified Annex.Branch
+import Logs.SingleValue.Pure
+import Annex.VectorClock
+
+import qualified Data.Set as S
+
+readLog :: (Ord v, SingleValueSerializable v) => RawFilePath -> Annex (Log v)
+readLog = parseLog <$$> Annex.Branch.get
+
+getLog :: (Ord v, SingleValueSerializable v) => RawFilePath -> Annex (Maybe v)
+getLog = newestValue <$$> readLog
+
+setLog :: (Ord v, SingleValueSerializable v) => Annex.Branch.RegardingUUID -> RawFilePath -> v -> Annex ()
+setLog ru f v = do
+	c <- currentVectorClock
+	Annex.Branch.change ru f $ \old ->
+		let oldcs = map changed ((parseLog' old) `asTypeOf` [ent])
+		    ent = LogEntry (advanceVectorClock c oldcs) v
+		in buildLog (S.singleton ent)
diff --git a/Logs/SingleValue/Pure.hs b/Logs/SingleValue/Pure.hs
new file mode 100644
index 0000000000..76dd766dd2
--- /dev/null
+++ b/Logs/SingleValue/Pure.hs
@@ -0,0 +1,60 @@
+{- git-annex single-value log, pure operations
+ -
+ - Copyright 2014-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.SingleValue.Pure where
+
+import Annex.Common
+import Logs.Line
+import Annex.VectorClock
+
+import qualified Data.Set as S
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import Data.Attoparsec.ByteString.Char8 (char)
+import Data.ByteString.Builder
+
+class SingleValueSerializable v where
+	serialize :: v -> B.ByteString
+	deserialize :: B.ByteString -> Maybe v
+
+data LogEntry v = LogEntry
+	{ changed :: VectorClock
+	, value :: v
+	} deriving (Eq, Ord)
+
+type Log v = S.Set (LogEntry v)
+
+buildLog :: (SingleValueSerializable v) => Log v -> Builder
+buildLog = mconcat . map genline . S.toList
+  where
+	genline (LogEntry c v) =
+		buildVectorClock c
+			<> sp 
+			<> byteString (serialize v)
+			<> nl
+	sp = charUtf8 ' '
+	nl = charUtf8 '\n'
+
+parseLog :: (Ord v, SingleValueSerializable v) => L.ByteString -> Log v
+parseLog = S.fromList . parseLog'
+
+parseLog' :: SingleValueSerializable v => L.ByteString -> [LogEntry v]
+parseLog' = fromMaybe [] . A.maybeResult . A.parse (logParser <* A.endOfInput)
+
+logParser :: SingleValueSerializable v => A.Parser [LogEntry v]
+logParser = parseLogLines $ LogEntry
+	<$> vectorClockParser
+	<* char ' '
+	<*> (parsevalue =<< A.takeByteString)
+  where
+	parsevalue = maybe (fail "log line parse failure") return . deserialize
+
+newestValue :: Log v -> Maybe v
+newestValue s
+	| S.null s = Nothing
+	| otherwise = Just (value $ S.findMax s)
diff --git a/Logs/Smudge.hs b/Logs/Smudge.hs
new file mode 100644
index 0000000000..7b0f5ff5f6
--- /dev/null
+++ b/Logs/Smudge.hs
@@ -0,0 +1,46 @@
+{- git-annex smudge log file
+ -
+ - Copyright 2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Logs.Smudge where
+
+import Annex.Common
+import Git.FilePath
+import Logs.File
+
+import qualified Data.ByteString.Lazy as L
+
+-- | Log a smudged file.
+smudgeLog :: Key -> TopFilePath -> Annex ()
+smudgeLog k f = do
+	logf <- fromRepo gitAnnexSmudgeLog
+	lckf <- fromRepo gitAnnexSmudgeLock
+	appendLogFile logf lckf $ L.fromStrict $
+		serializeKey' k <> " " <> getTopFilePath f
+
+-- | Streams all smudged files, and then empties the log at the end.
+--
+-- If the action is interrupted or throws an exception, the log file is
+-- left unchanged.
+--
+-- Locking is used to prevent new items being added to the log while this
+-- is running.
+streamSmudged :: (Key -> TopFilePath -> Annex ()) -> Annex ()
+streamSmudged a = do
+	logf <- fromRepo gitAnnexSmudgeLog
+	lckf <- fromRepo gitAnnexSmudgeLock
+	streamLogFile (fromRawFilePath logf) lckf noop $ \l -> 
+		case parse l of
+			Nothing -> noop
+			Just (k, f) -> a k f
+  where
+	parse l = 
+		let (ks, f) = separate (== ' ') l
+		in do
+			k <- deserializeKey ks
+			return (k, asTopFilePath (toRawFilePath f))
diff --git a/Logs/Transfer.hs b/Logs/Transfer.hs
new file mode 100644
index 0000000000..88c2f947cc
--- /dev/null
+++ b/Logs/Transfer.hs
@@ -0,0 +1,343 @@
+{- git-annex transfer information files and lock files
+ -
+ - Copyright 2012-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE CPP #-}
+
+module Logs.Transfer where
+
+import Types.Transfer
+import Types.ActionItem
+import Annex.Common
+import qualified Git
+import qualified Git.Quote
+import Utility.Metered
+import Utility.Percentage
+import Utility.PID
+import Annex.LockPool
+import Utility.TimeStamp
+import Logs.File
+import qualified Utility.RawFilePath as R
+#ifndef mingw32_HOST_OS
+import Annex.Perms
+#endif
+
+import Data.Time.Clock
+import Data.Time.Clock.POSIX
+import Control.Concurrent.STM
+import qualified Data.ByteString.Char8 as B8
+import qualified System.FilePath.ByteString as P
+
+describeTransfer :: Git.Quote.QuotePath -> Transfer -> TransferInfo -> String
+describeTransfer qp t info = unwords
+	[ show $ transferDirection t
+	, show $ transferUUID t
+	, decodeBS $ quote qp $ actionItemDesc $ ActionItemAssociatedFile
+		(associatedFile info)
+		(transferKey t)
+	, show $ bytesComplete info
+	]
+
+{- Transfers that will accomplish the same task. -}
+equivilantTransfer :: Transfer -> Transfer -> Bool
+equivilantTransfer t1 t2
+	| transferDirection t1 == Download && transferDirection t2 == Download &&
+	  transferKeyData t1 == transferKeyData t2 = True
+	| otherwise = t1 == t2
+
+percentComplete :: Transfer -> TransferInfo -> Maybe Percentage
+percentComplete t info =
+	percentage
+		<$> keySize (transferKeyData t)
+		<*> Just (fromMaybe 0 $ bytesComplete info)
+
+{- Generates a callback that can be called as transfer progresses to update
+ - the transfer info file. Also returns an action that sets up the file with
+ - appropriate permissions, which should be run after locking the transfer
+ - lock file, but before using the callback, and a TVar that can be used to
+ - read the number of bytes processed so far. -}
+mkProgressUpdater :: Transfer -> TransferInfo -> RawFilePath -> Annex (MeterUpdate, Annex (), TVar (Maybe BytesProcessed))
+mkProgressUpdater t info tfile = do
+	let createtfile = void $ tryNonAsync $ writeTransferInfoFile info tfile
+	tvar <- liftIO $ newTVarIO Nothing
+	loggedtvar <- liftIO $ newTVarIO 0
+	return (liftIO . updater (fromRawFilePath tfile) tvar loggedtvar, createtfile, tvar)
+  where
+	updater tfile' tvar loggedtvar new = do
+		old <- atomically $ swapTVar tvar (Just new)
+		let oldbytes = maybe 0 fromBytesProcessed old
+		let newbytes = fromBytesProcessed new
+		when (newbytes - oldbytes >= mindelta) $ do
+			let info' = info { bytesComplete = Just newbytes }
+			_ <- tryIO $ updateTransferInfoFile info' tfile'
+			atomically $ writeTVar loggedtvar newbytes
+
+	{- The minimum change in bytesComplete that is worth
+	 - updating a transfer info file for is 1% of the total
+	 - keySize, rounded down. -}
+	mindelta = case keySize (transferKeyData t) of
+		Just sz -> sz `div` 100
+		Nothing -> 100 * 1024 -- arbitrarily, 100 kb
+
+startTransferInfo :: AssociatedFile -> IO TransferInfo
+startTransferInfo afile = TransferInfo
+	<$> (Just . utcTimeToPOSIXSeconds <$> getCurrentTime)
+#ifndef mingw32_HOST_OS
+	<*> pure Nothing -- pid not stored in file, so omitted for speed
+#else
+	<*> (Just <$> getPID)
+#endif
+	<*> pure Nothing -- tid ditto
+	<*> pure Nothing -- not 0; transfer may be resuming
+	<*> pure Nothing
+	<*> pure afile
+	<*> pure False
+
+{- If a transfer is still running, returns its TransferInfo.
+ - 
+ - If no transfer is running, attempts to clean up the stale
+ - lock and info files, which can be left behind when a transfer
+ - process was interrupted.
+ -}
+checkTransfer :: Transfer -> Annex (Maybe TransferInfo)
+checkTransfer t = debugLocks $ do
+	(tfile, lck, moldlck) <- fromRepo $ transferFileAndLockFile t
+	let deletestale = do
+		void $ tryIO $ R.removeLink tfile
+		void $ tryIO $ R.removeLink lck
+		maybe noop (void . tryIO . R.removeLink) moldlck
+#ifndef mingw32_HOST_OS
+	v <- getLockStatus lck
+	v' <- case (moldlck, v) of
+		(Nothing, _) -> pure v
+		(_, StatusLockedBy pid) -> pure (StatusLockedBy pid)
+		(Just oldlck, _) -> getLockStatus oldlck
+	case v' of
+		StatusLockedBy pid -> liftIO $ catchDefaultIO Nothing $
+			readTransferInfoFile (Just pid) (fromRawFilePath tfile)
+		_ -> do
+			mode <- annexFileMode
+			-- Ignore failure due to permissions, races, etc.
+			void $ tryIO $ tryLockExclusive (Just mode) lck >>= \case
+				Just lockhandle -> case moldlck of
+					Nothing -> liftIO $ do
+						deletestale
+						dropLock lockhandle
+					Just oldlck -> tryLockExclusive (Just mode) oldlck >>= \case
+						Just oldlockhandle -> liftIO $ do
+							deletestale
+							dropLock oldlockhandle
+							dropLock lockhandle
+						Nothing -> liftIO $ dropLock lockhandle
+				Nothing -> noop
+			return Nothing
+#else
+	v <- liftIO $ lockShared lck
+	liftIO $ case v of
+		Nothing -> catchDefaultIO Nothing $
+			readTransferInfoFile Nothing (fromRawFilePath tfile)
+		Just lockhandle -> do
+			dropLock lockhandle
+			deletestale
+			return Nothing
+#endif
+
+{- Gets all currently running transfers. -}
+getTransfers :: Annex [(Transfer, TransferInfo)]
+getTransfers = getTransfers' [Download, Upload] (const True)
+
+getTransfers' :: [Direction] -> (Key -> Bool) -> Annex [(Transfer, TransferInfo)]
+getTransfers' dirs wanted = do
+	transfers <- filter (wanted . transferKey)
+		<$> mapMaybe parseTransferFile . concat <$> findfiles
+	infos <- mapM checkTransfer transfers
+	return $ mapMaybe running $ zip transfers infos
+  where
+	findfiles = liftIO . mapM (emptyWhenDoesNotExist . dirContentsRecursive . fromRawFilePath)
+		=<< mapM (fromRepo . transferDir) dirs
+	running (t, Just i) = Just (t, i)
+	running (_, Nothing) = Nothing
+
+{- Number of bytes remaining to download from matching downloads that are in
+ - progress. -}
+sizeOfDownloadsInProgress :: (Key -> Bool) -> Annex Integer
+sizeOfDownloadsInProgress wanted = sum . map remaining
+	<$> getTransfers' [Download] wanted
+  where
+	remaining (t, info) =
+		case (fromKey keySize (transferKey t), bytesComplete info) of
+			(Just sz, Just done) -> sz - done
+			(Just sz, Nothing) -> sz
+			(Nothing, _) -> 0
+
+{- Gets failed transfers for a given remote UUID. -}
+getFailedTransfers :: UUID -> Annex [(Transfer, TransferInfo)]
+getFailedTransfers u = catMaybes <$> (liftIO . getpairs =<< concat <$> findfiles)
+  where
+	getpairs = mapM $ \f -> do
+		let mt = parseTransferFile f
+		mi <- readTransferInfoFile Nothing f
+		return $ case (mt, mi) of
+			(Just t, Just i) -> Just (t, i)
+			_ -> Nothing
+	findfiles = liftIO . mapM (emptyWhenDoesNotExist . dirContentsRecursive . fromRawFilePath)
+		=<< mapM (fromRepo . failedTransferDir u) [Download, Upload]
+
+clearFailedTransfers :: UUID -> Annex [(Transfer, TransferInfo)]
+clearFailedTransfers u = do
+	failed <- getFailedTransfers u
+	mapM_ (removeFailedTransfer . fst) failed
+	return failed
+
+removeFailedTransfer :: Transfer -> Annex ()
+removeFailedTransfer t = do
+	f <- fromRepo $ failedTransferFile t
+	liftIO $ void $ tryIO $ R.removeLink f
+
+recordFailedTransfer :: Transfer -> TransferInfo -> Annex ()
+recordFailedTransfer t info = do
+	failedtfile <- fromRepo $ failedTransferFile t
+	writeTransferInfoFile info failedtfile
+
+{- The transfer information file and transfer lock file 
+ - to use for a given Transfer. 
+ -
+ - The transfer lock file used for an Upload includes the UUID.
+ - This allows multiple transfers of the same key to different remote
+ - repositories run at the same time, while preventing multiple
+ - transfers of the same key to the same remote repository.
+ -
+ - The transfer lock file used for a Download does not include the UUID.
+ - This prevents multiple transfers of the same key into the local
+ - repository at the same time.
+ -
+ - Since old versions of git-annex (10.20240227 and older) used to 
+ - include the UUID in the transfer lock file for a Download, this also
+ - returns a second lock file for Downloads, which has to be locked
+ - in order to interoperate with the old git-annex processes.
+ - Lock order is the same as return value order. 
+ - At some point in the future, when old git-annex processes are no longer
+ - a concern, this complication can be removed.
+ -}
+transferFileAndLockFile :: Transfer -> Git.Repo -> (RawFilePath, RawFilePath, Maybe RawFilePath)
+transferFileAndLockFile (Transfer direction u kd) r =
+	case direction of
+		Upload -> (transferfile, uuidlockfile, Nothing)
+		Download -> (transferfile, nouuidlockfile, Just uuidlockfile)
+  where
+	td = transferDir direction r
+	fu = B8.filter (/= '/') (fromUUID u)
+	kf = keyFile (mkKey (const kd))
+	lckkf = "lck." <> kf
+	transferfile = td P.</> fu P.</> kf
+	uuidlockfile = td P.</> fu P.</> lckkf
+	nouuidlockfile = td P.</> "lck" P.</> lckkf
+
+{- The transfer information file to use to record a failed Transfer -}
+failedTransferFile :: Transfer -> Git.Repo -> RawFilePath
+failedTransferFile (Transfer direction u kd) r = 
+	failedTransferDir u direction r
+		P.</> keyFile (mkKey (const kd))
+
+{- Parses a transfer information filename to a Transfer. -}
+parseTransferFile :: FilePath -> Maybe Transfer
+parseTransferFile file
+	| "lck." `isPrefixOf` takeFileName file = Nothing
+	| otherwise = case drop (length bits - 3) bits of
+		[direction, u, key] -> Transfer
+			<$> parseDirection direction
+			<*> pure (toUUID u)
+			<*> fmap (fromKey id) (fileKey (toRawFilePath key))
+		_ -> Nothing
+  where
+	bits = splitDirectories file
+
+writeTransferInfoFile :: TransferInfo -> RawFilePath -> Annex ()
+writeTransferInfoFile info tfile = writeLogFile tfile $ writeTransferInfo info
+
+-- The file keeps whatever permissions it has, so should be used only
+-- after it's been created with the right perms by writeTransferInfoFile.
+updateTransferInfoFile :: TransferInfo -> FilePath -> IO ()
+updateTransferInfoFile info tfile = writeFile tfile $ writeTransferInfo info
+
+{- File format is a header line containing the startedTime and any
+ - bytesComplete value. Followed by a newline and the associatedFile.
+ -
+ - On unix, the transferPid is not included; instead it is obtained
+ - by looking at the process that locks the file.
+ -
+ - On windows, the transferPid is included, as a second line.
+ -}
+writeTransferInfo :: TransferInfo -> String
+writeTransferInfo info = unlines
+	[ (maybe "" show $ startedTime info) ++
+	  (maybe "" (\b -> ' ' : show b) (bytesComplete info))
+#ifdef mingw32_HOST_OS
+	, maybe "" show (transferPid info)
+#endif
+	-- comes last; arbitrary content
+	, let AssociatedFile afile = associatedFile info
+	  in maybe "" fromRawFilePath afile
+	]
+
+readTransferInfoFile :: Maybe PID -> FilePath -> IO (Maybe TransferInfo)
+readTransferInfoFile mpid tfile = catchDefaultIO Nothing $
+	readTransferInfo mpid <$> readFileStrict tfile
+
+readTransferInfo :: Maybe PID -> String -> Maybe TransferInfo
+readTransferInfo mpid s = TransferInfo
+	<$> time
+#ifdef mingw32_HOST_OS
+	<*> pure (if isJust mpid then mpid else mpid')
+#else
+	<*> pure mpid
+#endif
+	<*> pure Nothing
+	<*> pure Nothing
+	<*> bytes
+	<*> pure (AssociatedFile (if null filename then Nothing else Just (toRawFilePath filename)))
+	<*> pure False
+  where
+#ifdef mingw32_HOST_OS
+	(firstline, otherlines) = separate (== '\n') s
+	(secondline, rest) = separate (== '\n') otherlines
+	mpid' = readish secondline
+#else
+	(firstline, rest) = separate (== '\n') s
+#endif
+	filename
+		| end rest == "\n" = beginning rest
+		| otherwise = rest
+	bits = splitc ' ' firstline
+	numbits = length bits
+	time = if numbits > 0
+		then Just <$> parsePOSIXTime =<< headMaybe bits
+		else pure Nothing -- not failure
+	bytes = if numbits > 1
+		then Just <$> readish =<< headMaybe (drop 1 bits)
+		else pure Nothing -- not failure
+
+{- The directory holding transfer information files for a given Direction. -}
+transferDir :: Direction -> Git.Repo -> RawFilePath
+transferDir direction r = gitAnnexTransferDir r P.</> formatDirection direction
+
+{- The directory holding failed transfer information files for a given
+ - Direction and UUID -}
+failedTransferDir :: UUID -> Direction -> Git.Repo -> RawFilePath
+failedTransferDir u direction r = gitAnnexTransferDir r
+	P.</> "failed"
+	P.</> formatDirection direction
+	P.</> B8.filter (/= '/') (fromUUID u)
+
+prop_read_write_transferinfo :: TransferInfo -> Bool
+prop_read_write_transferinfo info
+	| isJust (transferRemote info) = True -- remote not stored
+	| isJust (transferTid info) = True -- tid not stored
+	| otherwise = Just (info { transferPaused = False }) == info'
+  where
+	info' = readTransferInfo (transferPid info) (writeTransferInfo info)
+
diff --git a/Logs/Transitions.hs b/Logs/Transitions.hs
new file mode 100644
index 0000000000..c352709c0f
--- /dev/null
+++ b/Logs/Transitions.hs
@@ -0,0 +1,112 @@
+{- git-annex transitions log
+ -
+ - This is used to record transitions that have been performed on the
+ - git-annex branch, and when the transition was first started.
+ -
+ - We can quickly detect when the local branch has already had an transition
+ - done that is listed in the remote branch by checking that the local
+ - branch contains the same transition, with the same or newer start time.
+ -
+ - Copyright 2013-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Logs.Transitions where
+
+import Annex.Common
+import Annex.VectorClock
+import Logs.Line
+import qualified Git
+import Git.Types (fromRef)
+import Annex.CatFile
+
+import qualified Data.Set as S
+import Data.Either
+import Data.Char
+import Data.ByteString (ByteString)
+import Data.ByteString.Builder
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+
+transitionsLog :: RawFilePath
+transitionsLog = "transitions.log"
+
+data Transition
+	= ForgetGitHistory
+	| ForgetDeadRemotes
+	deriving (Show, Ord, Eq, Read)
+
+data TransitionLine = TransitionLine
+	{ transitionStarted :: VectorClock
+	-- New transitions that we don't know about yet are preserved.
+	, transition :: Either ByteString Transition
+	} deriving (Ord, Eq)
+
+type Transitions = S.Set TransitionLine
+
+describeTransition :: Transition -> String
+describeTransition ForgetGitHistory = "forget git history"
+describeTransition ForgetDeadRemotes = "forget dead remotes"
+
+noTransitions :: Transitions
+noTransitions = S.empty
+
+addTransition :: CandidateVectorClock -> Transition -> Transitions -> Transitions
+addTransition c t s = S.insert (TransitionLine c' (Right t)) s
+  where
+	oldcs = map transitionStarted $
+		filter (\l -> transition l == Right t) (S.toList s)
+	c' = advanceVectorClock c oldcs
+
+buildTransitions :: Transitions -> Builder
+buildTransitions = mconcat . map genline . S.elems
+  where
+	genline tl = buildt (transition tl) <> charUtf8 ' '
+		<> buildVectorClock (transitionStarted tl) <> charUtf8 '\n'
+	buildt (Left b) = byteString b
+	buildt (Right t) = byteString (encodeBS (show t))
+
+parseTransitions :: L.ByteString -> Transitions
+parseTransitions = fromMaybe S.empty . A.maybeResult . A.parse
+	(S.fromList <$> parseLogLines transitionLineParser)
+
+parseTransitionsStrictly :: String -> L.ByteString -> Transitions
+parseTransitionsStrictly source b =
+	let ts = parseTransitions b
+	in if S.null $ S.filter (isLeft . transition) ts
+		then ts
+		else giveup $ "unknown transitions listed in " ++ source ++ "; upgrade git-annex!"
+
+transitionLineParser :: A.Parser TransitionLine
+transitionLineParser = do
+	t <- parsetransition <$> A.takeTill (== sp)
+	_ <- A8.char ' '
+	c <- vectorClockParser
+	return $ TransitionLine c t
+  where
+	parsetransition b = case readish (decodeBS b) of
+		Just t -> Right t
+		Nothing -> Left b
+	sp = fromIntegral (ord ' ')
+
+combineTransitions :: [Transitions] -> Transitions
+combineTransitions = S.unions
+
+{- Unknown types of transitions are omitted. -}
+knownTransitionList :: Transitions -> [Transition]
+knownTransitionList = nub . rights . map transition . S.elems
+
+{- Typically ran with Annex.Branch.change, but we can't import Annex.Branch
+ - here since it depends on this module. -}
+recordTransitions :: (RawFilePath -> (L.ByteString -> Builder) -> Annex ()) -> Transitions -> Annex ()
+recordTransitions changer t = changer transitionsLog $
+	buildTransitions . S.union t . parseTransitionsStrictly "local"
+
+getRefTransitions :: Git.Ref -> Annex Transitions
+getRefTransitions ref = 
+	parseTransitionsStrictly (fromRef ref) 
+		<$> catFile ref transitionsLog
diff --git a/Logs/Trust.hs b/Logs/Trust.hs
new file mode 100644
index 0000000000..f2066ba29e
--- /dev/null
+++ b/Logs/Trust.hs
@@ -0,0 +1,86 @@
+{- git-annex trust log
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Trust (
+	module X,
+	trustLog,
+	TrustLevel(..),
+	trustGet,
+	trustMap,
+	trustPartition,
+	trustExclude,
+	lookupTrust,
+	lookupTrust',
+	trustMapLoad,
+) where
+
+import qualified Data.Map as M
+import Data.Default
+
+import Annex.Common
+import Types.TrustLevel
+import qualified Annex
+import Logs
+import Remote.List
+import qualified Types.Remote
+import Logs.Trust.Basic as X
+
+{- Returns a list of UUIDs that the trustLog indicates have the
+ - specified trust level.
+ - Note that the list can be incomplete for SemiTrusted, since that's
+ - the default. -}
+trustGet :: TrustLevel -> Annex [UUID]
+trustGet level = M.keys . M.filter (== level) <$> trustMap
+
+{- Returns the TrustLevel of a given repo UUID. -}
+lookupTrust :: UUID -> Annex TrustLevel
+lookupTrust u = lookupTrust' u <$> trustMap
+
+lookupTrust' :: UUID -> TrustMap -> TrustLevel
+lookupTrust' u m = fromMaybe def $ M.lookup u m
+
+{- Partitions a list of UUIDs to those matching a TrustLevel and not. -}
+trustPartition :: TrustLevel -> [UUID] -> Annex ([UUID], [UUID])
+trustPartition level ls
+	| level == SemiTrusted = do
+		t <- trustGet Trusted
+		u <- trustGet UnTrusted
+		d <- trustGet DeadTrusted
+		let uncandidates = t ++ u ++ d
+		return $ partition (`notElem` uncandidates) ls
+	| otherwise = do
+		candidates <- trustGet level
+		return $ partition (`elem` candidates) ls
+
+{- Filters UUIDs to those not matching a TrustLevel. -}
+trustExclude :: TrustLevel -> [UUID] -> Annex [UUID]
+trustExclude level ls = snd <$> trustPartition level ls
+
+{- trustLog in a map, overridden with any values from forcetrust or
+ - the git config. The map is cached for speed. -}
+trustMap :: Annex TrustMap
+trustMap = maybe trustMapLoad return =<< Annex.getState Annex.trustmap
+
+{- Loads the map, updating the cache, -}
+trustMapLoad :: Annex TrustMap
+trustMapLoad = do
+	forceoverrides <- Annex.getState Annex.forcetrust
+	l <- remoteList
+	let untrustoverrides = M.fromList $
+		map (\r -> (Types.Remote.uuid r, UnTrusted))
+		(filter Types.Remote.untrustworthy l)
+	logged <- trustMapRaw
+	let configured = M.fromList $ mapMaybe configuredtrust l
+	let m = M.unionWith min untrustoverrides $
+		M.union forceoverrides $
+		M.union configured logged
+	Annex.changeState $ \s -> s { Annex.trustmap = Just m }
+	return m
+  where
+	configuredtrust r = (\l -> Just (Types.Remote.uuid r, l))
+		=<< readTrustLevel 
+		=<< remoteAnnexTrustLevel (Types.Remote.gitconfig r)
diff --git a/Logs/Trust/Basic.hs b/Logs/Trust/Basic.hs
new file mode 100644
index 0000000000..85e25ed20d
--- /dev/null
+++ b/Logs/Trust/Basic.hs
@@ -0,0 +1,36 @@
+{- git-annex trust log, basics
+ -
+ - Copyright 2010-2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Trust.Basic (
+	module X,
+	trustSet,
+	trustMapRaw,
+) where
+
+import Annex.Common
+import Types.TrustLevel
+import qualified Annex.Branch
+import qualified Annex
+import Logs
+import Logs.UUIDBased
+import Logs.Trust.Pure as X
+
+{- Changes the trust level for a uuid in the trustLog. -}
+trustSet :: UUID -> TrustLevel -> Annex ()
+trustSet uuid@(UUID _) level = do
+	c <- currentVectorClock
+	Annex.Branch.change (Annex.Branch.RegardingUUID [uuid]) trustLog $
+		buildLogOld buildTrustLevel .
+			changeLog c uuid level .
+				parseLogOld trustLevelParser
+	Annex.changeState $ \s -> s { Annex.trustmap = Nothing }
+trustSet NoUUID _ = error "unknown UUID; cannot modify"
+
+{- Does not include forcetrust or git config values, just those from the
+ - log file. -}
+trustMapRaw :: Annex TrustMap
+trustMapRaw = calcTrustMap <$> Annex.Branch.get trustLog
diff --git a/Logs/Trust/Pure.hs b/Logs/Trust/Pure.hs
new file mode 100644
index 0000000000..a3c6c52ef6
--- /dev/null
+++ b/Logs/Trust/Pure.hs
@@ -0,0 +1,52 @@
+{- git-annex trust log, pure operations
+ -
+ - Copyright 2010-2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Logs.Trust.Pure where
+
+import Annex.Common
+import Types.TrustLevel
+import Logs.UUIDBased
+
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString as A
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+import Data.ByteString.Builder
+
+calcTrustMap :: L.ByteString -> TrustMap
+calcTrustMap = simpleMap . parseTrustLog
+
+parseTrustLog :: L.ByteString -> Log TrustLevel
+parseTrustLog = parseLogOld trustLevelParser
+
+trustLevelParser :: A.Parser TrustLevel
+trustLevelParser = (totrust <$> A8.anyChar <* A.endOfInput)
+	-- The trust log used to only list trusted repos, without a 
+	-- value for the trust status
+	<|> (const Trusted <$> A.endOfInput)
+  where
+	totrust '1' = Trusted
+	totrust '0' = UnTrusted
+	totrust 'X' = DeadTrusted
+	-- Allow for future expansion by treating unknown trust levels as
+	-- semitrusted.
+	totrust _ = SemiTrusted
+
+buildTrustLevel :: TrustLevel -> Builder
+buildTrustLevel Trusted = byteString "1"
+buildTrustLevel UnTrusted = byteString "0"
+buildTrustLevel DeadTrusted = byteString "X"
+buildTrustLevel SemiTrusted = byteString "?"
+
+prop_parse_build_TrustLevelLog :: Bool
+prop_parse_build_TrustLevelLog = all check [minBound .. maxBound]
+  where
+	check l = 
+		let v = A.parseOnly trustLevelParser $ L.toStrict $
+			toLazyByteString $ buildTrustLevel l
+		in v == Right l
diff --git a/Logs/UUID.hs b/Logs/UUID.hs
new file mode 100644
index 0000000000..1a3142e198
--- /dev/null
+++ b/Logs/UUID.hs
@@ -0,0 +1,72 @@
+{- git-annex uuid log
+ -
+ - uuid.log stores a list of known uuids, and their descriptions.
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Logs.UUID (
+	uuidLog,
+	describeUUID,
+	uuidDescMap,
+	uuidDescMapLoad,
+	uuidDescMapRaw,
+) where
+
+import Types.UUID
+import Annex.Common
+import Annex.VectorClock
+import qualified Annex
+import qualified Annex.Branch
+import Logs
+import Logs.UUIDBased
+import qualified Annex.UUID
+
+import qualified Data.Map.Strict as M
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString.Lazy as A
+import Data.ByteString.Builder
+import Data.Char
+
+{- Records a description for a uuid in the log. -}
+describeUUID :: UUID -> UUIDDesc -> Annex ()
+describeUUID uuid desc = do
+	c <- currentVectorClock
+	Annex.Branch.change (Annex.Branch.RegardingUUID [uuid]) uuidLog $
+		buildLogOld builder . changeLog c uuid desc . parseUUIDLog
+  where
+	builder (UUIDDesc b) = byteString (escnewline b)
+	-- Escape any newline in the description, since newlines cannot
+	-- be present in the logged value. This is a one-way escaping.
+	escnewline = B.intercalate "\\n" . B.split newline
+	newline = fromIntegral (ord '\n')
+
+{- The map is cached for speed. -}
+uuidDescMap :: Annex UUIDDescMap
+uuidDescMap = maybe uuidDescMapLoad return =<< Annex.getState Annex.uuiddescmap
+
+{- Read the uuidLog into a map, and cache it for later use.
+ -
+ - If the current repository has not been described, it is still included
+ - in the map with an empty description. -}
+uuidDescMapLoad :: Annex UUIDDescMap
+uuidDescMapLoad = do
+	m <- uuidDescMapRaw
+	u <- Annex.UUID.getUUID
+	let m' = M.insertWith preferold u mempty m
+	Annex.changeState $ \s -> s { Annex.uuiddescmap = Just m' }
+	return m'
+  where
+	preferold = flip const
+
+{- Read the uuidLog into a map. Includes only actually set descriptions. -}
+uuidDescMapRaw :: Annex UUIDDescMap
+uuidDescMapRaw = simpleMap . parseUUIDLog <$> Annex.Branch.get uuidLog
+
+parseUUIDLog :: L.ByteString -> Log UUIDDesc
+parseUUIDLog = parseLogOld (UUIDDesc <$> A.takeByteString)
diff --git a/Logs/UUIDBased.hs b/Logs/UUIDBased.hs
new file mode 100644
index 0000000000..02875d45d5
--- /dev/null
+++ b/Logs/UUIDBased.hs
@@ -0,0 +1,94 @@
+{- git-annex uuid-based logs
+ -
+ - This is used to store information about UUIDs in a way that can
+ - be union merged.
+ -
+ - The old format looks like: "UUID[ INFO[ timestamp=foo]]"
+ - The timestamp is last for backwards compatibility reasons,
+ - and may not be present on very old log lines.
+ -
+ - New uuid based logs instead use the form: "timestamp UUID INFO"
+ - 
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, TupleSections #-}
+
+module Logs.UUIDBased (
+	Log,
+	LogEntry(..),
+	VectorClock,
+	currentVectorClock,
+	parseLogOld,
+	parseLogNew,
+	parseLogOldWithUUID,
+	buildLogOld,
+	buildLogNew,
+	changeLog,
+	addLog,
+	simpleMap,
+) where
+
+import qualified Data.Map as M
+
+import Common
+import Types.UUID
+import Annex.VectorClock
+import Logs.MapLog
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Attoparsec.ByteString as A
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+import Data.ByteString.Builder
+import qualified Data.DList as D
+
+type Log v = MapLog UUID v
+
+buildLogOld :: (v -> Builder) -> Log v -> Builder
+buildLogOld builder = mconcat . map genline . M.toList . fromMapLog
+  where
+	genline (u, LogEntry c@(VectorClock {}) v) =
+		buildUUID u <> sp <> builder v <> sp
+			<> byteString "timestamp="
+			<> buildVectorClock c
+			<> nl
+	genline (u, LogEntry Unknown v) =
+		buildUUID u <> sp <> builder v <> nl
+	sp = charUtf8 ' '
+	nl = charUtf8 '\n'
+
+parseLogOld :: A.Parser a -> L.ByteString -> Log a
+parseLogOld = parseLogOldWithUUID . const
+
+parseLogOldWithUUID :: (UUID -> A.Parser a) -> L.ByteString -> Log a
+parseLogOldWithUUID parser = parseMapLogWith (logParserOld parser)
+
+logParserOld :: (UUID -> A.Parser a) -> A.Parser (Log a)
+logParserOld parser = mapLogParser' $ do
+	u <- toUUID <$> A8.takeWhile1 (/= ' ')
+	(dl, ts) <- accumval D.empty
+	v <- either fail return $ A.parseOnly (parser u <* A.endOfInput)
+		(S.intercalate " " $ D.toList dl)
+	return (u, LogEntry ts v)
+  where
+	accumval dl =
+		((dl,) <$> parsetimestamp)
+		<|> (A8.char ' ' *> (A8.takeWhile (/= ' ')) >>= accumval . D.snoc dl)
+	parsetimestamp = 
+		(A8.string " timestamp=" *> vectorClockParser <* A.endOfInput)
+		<|> (const Unknown <$> A.endOfInput)
+
+buildLogNew :: (v -> Builder) -> Log v -> Builder
+buildLogNew = buildMapLog buildUUID
+
+parseLogNew :: A.Parser v -> L.ByteString -> Log v
+parseLogNew = parseMapLog (toUUID <$> A.takeByteString)
+
+changeLog :: CandidateVectorClock -> UUID -> v -> Log v -> Log v
+changeLog = changeMapLog
+
+addLog :: UUID -> LogEntry v -> Log v -> Log v
+addLog = addMapLog
diff --git a/Logs/Unused.hs b/Logs/Unused.hs
new file mode 100644
index 0000000000..6bb1011e84
--- /dev/null
+++ b/Logs/Unused.hs
@@ -0,0 +1,112 @@
+{- git-annex unused log file
+ -
+ - This file is stored locally in .git/annex/, not in the git-annex branch.
+ -
+ - The format: "int key timestamp"
+ -
+ - The int is a short, stable identifier that the user can use to
+ - refer to this key. (Equivalent to a filename.)
+ -
+ - The timestamp indicates when the key was first determined to be unused.
+ - Older versions of the log omit the timestamp.
+ -
+ - Copyright 2010-2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Logs.Unused (
+	UnusedMap,
+	updateUnusedLog,
+	readUnusedLog,
+	readUnusedMap,
+	dateUnusedLog,
+	unusedKeys,
+	unusedKeys',
+	setUnusedKeys,
+) where
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import Data.Time.Clock.POSIX
+import Data.Time
+
+import Annex.Common
+import qualified Annex
+import Utility.TimeStamp
+import Logs.File
+
+-- everything that is stored in the unused log
+type UnusedLog = M.Map Key (Int, Maybe POSIXTime)
+
+-- used to look up unused keys specified by the user
+type UnusedMap = M.Map Int Key
+
+log2map :: UnusedLog -> UnusedMap
+log2map = M.fromList . map (\(k, (i, _t)) -> (i, k)) . M.toList
+
+map2log :: POSIXTime -> UnusedMap -> UnusedLog
+map2log t = M.fromList . map (\(i, k) -> (k, (i, Just t))) . M.toList
+
+{- Only keeps keys that are in the new log, but uses any timestamps
+ - those keys had in the old log. -}
+preserveTimestamps :: UnusedLog -> UnusedLog -> UnusedLog
+preserveTimestamps oldl newl = M.intersection (M.unionWith oldts oldl newl) newl
+  where
+	oldts _old@(_, ts) _new@(int, _) = (int, ts)
+
+updateUnusedLog :: RawFilePath -> UnusedMap -> Annex ()
+updateUnusedLog prefix m = do
+	oldl <- readUnusedLog prefix
+	newl <- preserveTimestamps oldl . flip map2log m <$> liftIO getPOSIXTime
+	writeUnusedLog prefix newl
+
+writeUnusedLog :: RawFilePath -> UnusedLog -> Annex ()
+writeUnusedLog prefix l = do
+	logfile <- fromRepo $ gitAnnexUnusedLog prefix
+	writeLogFile logfile $ unlines $ map format $ M.toList l
+  where
+	format (k, (i, Just t)) = show i ++ " " ++ serializeKey k ++ " " ++ show t
+	format (k, (i, Nothing)) = show i ++ " " ++ serializeKey k
+
+readUnusedLog :: RawFilePath -> Annex UnusedLog
+readUnusedLog prefix = do
+	f <- fromRawFilePath <$> fromRepo (gitAnnexUnusedLog prefix)
+	ifM (liftIO $ doesFileExist f)
+		( M.fromList . mapMaybe parse . lines
+			<$> liftIO (readFileStrict f)
+		, return M.empty
+		)
+  where
+	parse line = case (readish sint, deserializeKey skey, parsePOSIXTime ts) of
+		(Just int, Just key, mtimestamp) -> Just (key, (int, mtimestamp))
+		_ -> Nothing
+	  where
+		(sint, rest) = separate (== ' ') line
+		(rts, rskey) = separate (== ' ') (reverse rest)
+		skey = reverse rskey
+		ts = reverse rts
+
+readUnusedMap :: RawFilePath -> Annex UnusedMap
+readUnusedMap = log2map <$$> readUnusedLog
+
+dateUnusedLog :: RawFilePath -> Annex (Maybe UTCTime)
+dateUnusedLog prefix = do
+	f <- fromRepo $ gitAnnexUnusedLog prefix
+	liftIO $ catchMaybeIO $ getModificationTime $ fromRawFilePath f
+
+{- Set of unused keys. This is cached for speed. -}
+unusedKeys :: Annex (S.Set Key)
+unusedKeys = maybe (setUnusedKeys =<< unusedKeys') return
+	=<< Annex.getState Annex.unusedkeys
+
+unusedKeys' :: Annex [Key]
+unusedKeys' = M.keys <$> readUnusedLog ""
+
+setUnusedKeys :: [Key] -> Annex (S.Set Key)
+setUnusedKeys ks = do
+	let v = S.fromList ks
+	Annex.changeState $ \s -> s { Annex.unusedkeys = Just v }
+	return v
diff --git a/Logs/Upgrade.hs b/Logs/Upgrade.hs
new file mode 100644
index 0000000000..f1ff0bd56c
--- /dev/null
+++ b/Logs/Upgrade.hs
@@ -0,0 +1,53 @@
+{- git-annex upgrade log
+ -
+ - This file is stored locally in .git/annex/, not in the git-annex branch.
+ -
+ - The format: "version timestamp"
+ -
+ - Copyright 2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Logs.Upgrade (
+	writeUpgradeLog,
+	readUpgradeLog,
+	timeOfUpgrade,
+) where
+
+import Annex.Common
+import Utility.TimeStamp
+import Logs.File
+import Types.RepoVersion
+
+import Data.Time.Clock.POSIX
+
+writeUpgradeLog :: RepoVersion -> POSIXTime-> Annex ()
+writeUpgradeLog v t = do
+	logf <- fromRepo gitAnnexUpgradeLog
+	lckf <- fromRepo gitAnnexUpgradeLock
+	appendLogFile logf lckf $ encodeBL $
+		show (fromRepoVersion v) ++ " " ++ show t
+
+readUpgradeLog :: Annex [(RepoVersion, POSIXTime)]
+readUpgradeLog = do
+	logfile <- fromRawFilePath <$> fromRepo gitAnnexUpgradeLog
+	ifM (liftIO $ doesFileExist logfile)
+		( mapMaybe parse . lines
+			<$> liftIO (readFileStrict logfile)
+		, return []
+		)
+  where
+	parse line = case (readish sint, parsePOSIXTime ts) of
+		(Just v, Just t) -> Just (RepoVersion v, t)
+		_ -> Nothing
+	  where
+		(sint, ts) = separate (== ' ') line
+
+timeOfUpgrade :: RepoVersion -> Annex (Maybe POSIXTime)
+timeOfUpgrade want = do
+	l <- readUpgradeLog
+	return $ case filter (\(v, _) -> v == want) l of
+		[] -> Nothing
+		l' -> Just (minimum (map snd l'))
+
diff --git a/Logs/View.hs b/Logs/View.hs
new file mode 100644
index 0000000000..afb036c202
--- /dev/null
+++ b/Logs/View.hs
@@ -0,0 +1,160 @@
+{- git-annex recent views log
+ -
+ - The most recently accessed view comes first.
+ -
+ - This file is stored locally in .git/annex/, not in the git-annex branch.
+ -
+ - Copyright 2014-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Logs.View (
+	currentView,
+	setView,
+	removeView,
+	recentViews,
+	branchView,
+	fromViewBranch,
+	is_branchView,
+	branchViewPrefix,
+	prop_branchView_legal,
+) where
+
+import Annex.Common
+import Types.View
+import Types.MetaData
+import Types.AdjustedBranch
+import Annex.AdjustedBranch.Name
+import qualified Git
+import qualified Git.Branch
+import qualified Git.Ref
+import Git.Types
+import Logs.File
+
+import qualified Data.Text as T
+import qualified Data.Set as S
+import Data.Char
+import qualified Data.ByteString as B
+
+setView :: View -> Annex ()
+setView v = do
+	old <- take 99 . filter (/= v) <$> recentViews
+	writeViews (v : old)
+
+writeViews :: [View] -> Annex ()
+writeViews l = do
+	f <- fromRepo gitAnnexViewLog
+	writeLogFile f $ unlines $ map show l
+
+removeView :: View -> Annex ()
+removeView v = writeViews =<< filter (/= v) <$> recentViews
+
+recentViews :: Annex [View]
+recentViews = do
+	f <- fromRawFilePath <$> fromRepo gitAnnexViewLog
+	liftIO $ mapMaybe readish . lines <$> catchDefaultIO [] (readFile f)
+
+{- Gets the currently checked out view, if there is one. 
+ -
+ - The view may also have an adjustment applied to it.
+ -}
+currentView :: Annex (Maybe (View, Maybe Adjustment))
+currentView = go =<< inRepo Git.Branch.current
+  where
+	go (Just b) = case adjustedToOriginal b of
+		Nothing -> getvb b Nothing
+		Just (adj, b') -> getvb b' (Just adj)
+	go Nothing = return Nothing
+
+	getvb b madj
+		| branchViewPrefix `B.isPrefixOf` fromRef' b = do
+			vb <- headMaybe 
+				. filter (\v -> branchView v Nothing == b || branchViewOld v == b) 
+				<$> recentViews
+			case vb of
+				Just vb' -> return (Just (vb', madj))
+				Nothing -> return Nothing
+		| otherwise = return Nothing
+
+{- Note that this is not the prefix used when an adjustment is applied to a
+ - view branch. -}
+branchViewPrefix :: B.ByteString
+branchViewPrefix = "refs/heads/views"
+
+{- Generates a git branch name for a View, which may also have an
+ - adjustment applied to it.
+ - 
+ - There is no guarantee that each view gets a unique branch name,
+ - but the branch name is used to express the view as well as possible
+ - given the constraints on git branch names. It includes the name of the
+ - parent branch, and what metadata is used.
+ -}
+branchView :: View -> Maybe Adjustment -> Git.Branch
+branchView view madj = case madj of
+	Nothing -> vb
+	Just adj -> adjBranch $ originalToAdjusted vb adj
+  where
+  	basebranch = fromRef' (Git.Ref.base (viewParentBranch view))
+	vb = Git.Ref $ branchViewPrefix <> "/" <> basebranch
+		<> "(" <> branchViewDesc view False <> ")"
+
+{- Old name used for a view did not include the name of the parent branch. -}
+branchViewOld :: View -> Git.Branch
+branchViewOld view = Git.Ref $
+	 branchViewPrefix <> "/" <> branchViewDesc view True
+
+branchViewDesc :: View -> Bool -> B.ByteString
+branchViewDesc view pareninvisibles = encodeBS $
+	intercalate ";" $ map branchcomp (viewComponents view)
+  where
+	branchcomp c
+		| viewVisible c || not pareninvisibles = branchcomp' c
+		| otherwise = "(" ++ branchcomp' c ++ ")"
+	branchcomp' (ViewComponent metafield viewfilter _) = concat
+		[ forcelegal (T.unpack (fromMetaField metafield))
+		, branchvals viewfilter
+		]
+	branchvals (FilterValues set) = '=' : branchset set
+	branchvals (FilterGlob glob) = '=' : forcelegal glob
+	branchvals (ExcludeValues set) = "!=" ++ branchset set
+	branchvals (FilterValuesOrUnset set _) = '=' : branchset set
+	branchvals (FilterGlobOrUnset glob _) = '=' : forcelegal glob
+	branchset = intercalate ","
+		. map (forcelegal . decodeBS . fromMetaValue)
+		. S.toList
+	forcelegal s
+		| Git.Ref.legal True s = s
+		| otherwise = map (\c -> if isAlphaNum c then c else '_') s
+
+is_branchView :: Git.Branch -> Bool
+is_branchView b = case adjustedToOriginal b of
+	Nothing -> hasprefix b
+	Just (_adj, b') -> hasprefix b'
+  where
+	hasprefix (Ref b') = (branchViewPrefix <> "/") `B.isPrefixOf` b'
+
+{- Converts a view branch as generated by branchView (but not by
+ - branchViewOld) back to the parent branch.
+ - Has no effect on other branches. -}
+fromViewBranch :: Git.Branch -> Git.Branch
+fromViewBranch b = case adjustedToOriginal b of
+	Nothing -> go b
+	Just (_adj, b') -> go b'
+  where
+	go b' =
+		let bs = fromRef' b'
+		in if (branchViewPrefix <> "/") `B.isPrefixOf` bs
+			then 
+				let (branch, _desc) = separate' (== openparen) (B.drop prefixlen bs)
+				in Ref branch
+			else b'
+	
+	prefixlen = B.length branchViewPrefix + 1
+	openparen = fromIntegral (ord '(')
+
+prop_branchView_legal :: View -> Bool
+prop_branchView_legal = Git.Ref.legal False 
+	. fromRef . (\v -> branchView v Nothing)
diff --git a/Logs/Web.hs b/Logs/Web.hs
new file mode 100644
index 0000000000..66f21a7c5c
--- /dev/null
+++ b/Logs/Web.hs
@@ -0,0 +1,139 @@
+{- Web url logs.
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Logs.Web (
+	URLString,
+	URLByteString,
+	getUrls,
+	getUrls',
+	getUrlsWithPrefix,
+	setUrlPresent,
+	setUrlMissing,
+	Downloader(..),
+	getDownloader,
+	setDownloader,
+	setDownloader',
+	setTempUrl,
+	removeTempUrl,
+	parseUrlLog,
+) where
+
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+
+import Annex.Common
+import qualified Annex
+import Logs
+import Logs.Presence
+import Logs.Location
+import Utility.Url
+import Annex.UUID
+import qualified Annex.Branch
+import qualified Types.Remote as Remote
+
+type URLByteString = S.ByteString
+
+{- Gets all urls that a key might be available from. -}
+getUrls :: Key -> Annex [URLString]
+getUrls key = do
+	l <- map decodeBS <$> getUrls' key
+	tmpl <- Annex.getState (maybeToList . M.lookup key . Annex.tempurls)
+	return (tmpl ++ l)
+
+{- Note that this does not include temporary urls set with setTempUrl. -}
+getUrls' :: Key -> Annex [URLByteString]
+getUrls' key = do
+	config <- Annex.getGitConfig
+	go $ urlLogFile config key : oldurlLogs config key
+  where
+	go [] = return []
+	go (l:ls) = do
+		us <- presentLogInfo l
+		if null us
+			then go ls
+			else return $ map fromLogInfo us
+
+getUrlsWithPrefix :: Key -> String -> Annex [URLString]
+getUrlsWithPrefix key prefix = filter (prefix `isPrefixOf`) 
+	. map (fst . getDownloader)
+	<$> getUrls key
+
+setUrlPresent :: Key -> URLString -> Annex ()
+setUrlPresent key url = do
+	-- Avoid reading the url log when not compacting, for speed.
+	us <- ifM (annexAlwaysCompact <$> Annex.getGitConfig)
+		( getUrls key
+		, pure mempty
+		)
+	unless (url `elem` us) $ do
+		config <- Annex.getGitConfig
+		addLog (Annex.Branch.RegardingUUID []) (urlLogFile config key)
+			InfoPresent (LogInfo (encodeBS url))
+	-- If the url does not have an OtherDownloader, it must be present
+	-- in the web.
+	case snd (getDownloader url) of
+		OtherDownloader -> return ()
+		_ -> logChange key webUUID InfoPresent
+
+setUrlMissing :: Key -> URLString -> Annex ()
+setUrlMissing key url = do
+	-- Avoid making any changes if the url was not registered.
+	us <- getUrls key
+	when (url `elem` us) $ do
+		config <- Annex.getGitConfig
+		addLog (Annex.Branch.RegardingUUID []) (urlLogFile config key)
+			InfoMissing (LogInfo (encodeBS url))
+		-- If the url was a web url and none of the remaining urls
+		-- for the key are web urls, the key must not be present
+		-- in the web.
+		when (isweb url && null (filter isweb $ filter (/= url) us)) $
+			logChange key webUUID InfoMissing
+  where
+	isweb u = case snd (getDownloader u) of
+		OtherDownloader -> False
+		_ -> True
+
+setTempUrl :: Key -> URLString -> Annex ()
+setTempUrl key url = Annex.changeState $ \s ->
+	s { Annex.tempurls = M.insert key url (Annex.tempurls s) }
+
+removeTempUrl :: Key -> Annex ()
+removeTempUrl key = Annex.changeState $ \s ->
+	s { Annex.tempurls = M.delete key (Annex.tempurls s) }
+
+data Downloader = WebDownloader | YoutubeDownloader | QuviDownloader | OtherDownloader
+	deriving (Eq, Show, Enum, Bounded)
+
+{- To keep track of how an url is downloaded, it's mangled slightly in
+ - the log, with a prefix indicating when a Downloader is used. -}
+setDownloader :: URLString -> Downloader -> String
+setDownloader u WebDownloader = u
+setDownloader u QuviDownloader = "quvi:" ++ u
+setDownloader u YoutubeDownloader = "yt:" ++ u
+setDownloader u OtherDownloader = ":" ++ u
+
+setDownloader' :: URLString -> Remote -> String
+setDownloader' u r
+	| Remote.uuid r == webUUID = setDownloader u WebDownloader
+	| otherwise = setDownloader u OtherDownloader
+
+getDownloader :: URLString -> (URLString, Downloader)
+getDownloader u = case separate (== ':') u of
+	("yt", u') -> (u', YoutubeDownloader)
+	-- quvi is not used any longer; youtube-dl should be able to handle
+	-- all urls it did.
+	("quvi", u') -> (u', YoutubeDownloader)
+	("", u') -> (u', OtherDownloader)
+	_ -> (u, WebDownloader)
+
+{- Parses the content of an url log file, returning the urls that are
+ - currently recorded. -}
+parseUrlLog :: L.ByteString -> [URLByteString]
+parseUrlLog = map fromLogInfo . getLog
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000000..06ebebdea3
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,239 @@
+all=git-annex git-annex-shell mans docs
+
+# set to "./Setup" if you lack a cabal program. Or can be set to "stack"
+BUILDER?=cabal
+ifeq ($(BUILDER),stack)
+GHC?=stack ghc --
+else
+GHC?=ghc
+endif
+
+PREFIX?=/usr
+SHAREDIR?=share
+
+# On Debian systems, zsh does not look here, and you will have to override
+# this to /usr/share/zsh/vendor-completions
+ZSH_COMPLETIONS_PATH?=$(PREFIX)/$(SHAREDIR)/zsh/site-functions
+
+build: $(all)
+
+# install system-wide
+# Set PREFIX and DESTDIR to configure where it is installed
+install: install-bins install-docs install-completions install-desktop
+
+# installs into your home directory
+install-home:
+	$(MAKE) install-bins PREFIX=$(HOME)/.local
+	$(MAKE) install-mans PREFIX=$(HOME)/.local
+	$(MAKE) install-desktop PREFIX=$(HOME)/.local USERDIR=1
+
+tmp/configure-stamp: Build/TestConfig.hs Build/Configure.hs
+	if [ "$(BUILDER)" = ./Setup ]; then $(GHC) --make Setup; fi
+	if [ "$(BUILDER)" != stack ]; then \
+		$(BUILDER) configure -fParallelBuild $(BUILDERCOMMONOPTIONS) --ghc-options="$(shell Build/collect-ghc-options.sh)"; \
+		rm cabal.project.local~* 2>/dev/null || true; \
+	else \
+		$(BUILDER) setup $(BUILDERCOMMONOPTIONS); \
+	fi
+	mkdir -p tmp
+	touch tmp/configure-stamp
+
+# Build with stack if it was used to build before, otherwise cabal.
+dev:
+	@if [ -d .stack-work ]; then BUILDER=stack make; else make; fi
+
+# Non-optimised build for development, with profiling enabled (for memory
+# profiling).
+#
+# This leaves cabal.project.local configured for a prof build,
+# so just running make will continue to do prof builds.
+prof:
+	$(BUILDER) configure -f"-Production" -fParallelBuild \
+		--enable-executable-dynamic --enable-profiling
+	rm cabal.project.local~* 2>/dev/null || true
+	mkdir -p tmp
+	touch tmp/configure-stamp
+	$(MAKE) git-annex tags
+
+git-annex: tmp/configure-stamp
+	$(BUILDER) build $(BUILDERCOMMONOPTIONS) $(BUILDEROPTIONS)
+	@if [ "$(BUILDER)" = stack ]; then \
+		ln -f $$(stack path $(BUILDERCOMMONOPTIONS) --dist-dir)/build/git-annex/git-annex git-annex; \
+	else \
+		if [ -d dist-newstyle ]; then \
+			ln -f $$(cabal exec -- sh -c 'command -v git-annex') git-annex; \
+		else \
+			ln -f dist/build/git-annex/git-annex git-annex; \
+		fi; \
+	fi
+
+git-annex-shell: git-annex
+	ln -sf git-annex git-annex-shell
+
+# These are not built normally.
+git-union-merge.1: doc/git-union-merge.mdwn
+	./Build/mdwn2man git-union-merge 1 doc/git-union-merge.mdwn > git-union-merge.1
+git-union-merge:
+	$(GHC) --make -threaded $@
+
+install-mans: mans
+	install -d $(DESTDIR)$(PREFIX)/$(SHAREDIR)/man/man1
+	install -m 0644 man/*.1 $(DESTDIR)$(PREFIX)/$(SHAREDIR)/man/man1
+
+install-docs: docs install-mans
+	install -d $(DESTDIR)$(PREFIX)/$(SHAREDIR)/doc/git-annex
+	if [ -d html ]; then \
+		rsync -a --delete html/ $(DESTDIR)$(PREFIX)/$(SHAREDIR)/doc/git-annex/html/; \
+	fi
+
+install-bins: build
+	install -d $(DESTDIR)$(PREFIX)/bin
+	install git-annex $(DESTDIR)$(PREFIX)/bin
+	ln -sf git-annex $(DESTDIR)$(PREFIX)/bin/git-annex-shell
+	ln -sf git-annex $(DESTDIR)$(PREFIX)/bin/git-remote-tor-annex
+
+install-desktop: build Build/InstallDesktopFile
+	./Build/InstallDesktopFile $(PREFIX)/bin/git-annex || true
+
+install-completions: build
+	install -d $(DESTDIR)$(PREFIX)/$(SHAREDIR)/bash-completion/completions
+	install -m 0644 bash-completion.bash $(DESTDIR)$(PREFIX)/$(SHAREDIR)/bash-completion/completions/git-annex
+	install -d $(DESTDIR)$(ZSH_COMPLETIONS_PATH)
+	./git-annex --zsh-completion-script git-annex 2>/dev/null \
+		> $(DESTDIR)$(ZSH_COMPLETIONS_PATH)/_git-annex
+	install -d $(DESTDIR)$(PREFIX)/$(SHAREDIR)/fish/vendor_completions.d
+	./git-annex --fish-completion-script git-annex 2>/dev/null \
+		> $(DESTDIR)$(PREFIX)/$(SHAREDIR)/fish/vendor_completions.d/git-annex.fish
+
+test: git-annex git-annex-shell
+	./git-annex test
+
+retest: git-annex
+	./git-annex test --rerun-update --rerun-filter failures
+
+tags:
+	hasktags . -c || true
+
+mans: Build/MakeMans
+	./Build/MakeMans
+
+# If ikiwiki is available, build static html docs suitable for being
+# shipped in the software package.
+docs: mans
+	@if command -v ikiwiki; then \
+		LC_ALL=C TZ=UTC ikiwiki doc html -v --wikiname git-annex \
+			--plugin=goodstuff \
+			--no-usedirs --disable-plugin=openid --plugin=sidebar \
+			--plugin theme --set theme=actiontabs --set deterministic=1 \
+			--disable-plugin=shortcut --disable-plugin=smiley \
+			--plugin=comments --set comments_pagespec="*" \
+			--exclude='ikiwiki/*' \
+			--exclude='news/.*' --exclude='design/assistant/blog/*' \
+			--exclude='bugs/*' --exclude='todo/*' --exclude='forum/*' \
+			--exclude='users/*' --exclude='devblog/*' --exclude='thanks'; \
+	else \
+		echo "** ikiwiki not found, skipping building docs" >&2; \
+	fi
+
+clean:
+	if [ "$(BUILDER)" != ./Setup ] && [ "$(BUILDER)" != cabal ]; then $(BUILDER) clean; fi
+	rm -rf tmp dist dist-newstyle git-annex $(mans) configure  *.tix .hpc \
+		doc/.ikiwiki html dist tags Build/SysConfig Build/Version \
+		Setup Build/InstallDesktopFile Build/Standalone \
+		Build/DistributionUpdate Build/BuildVersion Build/MakeMans \
+		git-annex-shell git-union-merge .tasty-rerun-log
+	find . -name \*.o -exec rm {} \;
+	find . -name \*.hi -exec rm {} \;
+
+Build/InstallDesktopFile: Build/InstallDesktopFile.hs
+	$(GHC) --make $@ -Wall -fno-warn-tabs
+Build/Standalone: Build/Standalone.hs Build/LinuxMkLibs.hs Utility/LinuxMkLibs.hs tmp/configure-stamp
+	$(GHC) --make $@ -Wall -fno-warn-tabs
+Build/BuildVersion: Build/BuildVersion.hs
+	$(GHC) --make $@ -Wall -fno-warn-tabs
+Build/MakeMans: Build/MakeMans.hs
+	$(GHC) --make $@ -Wall -fno-warn-tabs
+
+LINUXSTANDALONE_DEST=tmp/git-annex.linux
+linuxstandalone:
+	$(MAKE) git-annex Build/Standalone
+	./Build/Standalone "$(LINUXSTANDALONE_DEST)" "$(LINUXSTANDALONE_DEST)"
+
+	$(MAKE) install-mans DESTDIR="$(LINUXSTANDALONE_DEST)"
+	zcat standalone/licences.gz > $(LINUXSTANDALONE_DEST)/LICENSE
+	cp doc/logo_16x16.png doc/logo.svg $(LINUXSTANDALONE_DEST)
+	cp standalone/trustedkeys.gpg $(LINUXSTANDALONE_DEST)
+
+	md5sum git-annex | cut -d ' ' -f 1 > "$(LINUXSTANDALONE_DEST)/buildid"
+	cd tmp/git-annex.linux && find . -type f > git-annex.MANIFEST
+	cd tmp/git-annex.linux && find . -type l >> git-annex.MANIFEST
+	cd tmp && tar c git-annex.linux | gzip -9 --rsyncable > git-annex-standalone-$(shell dpkg --print-architecture).tar.gz
+
+# Run this target to build git-annex-standalone.deb
+debianstandalone: dpkg-buildpackage-F
+# Run this target to build git-annex-standalone.dsc
+debianstandalone-dsc: dpkg-buildpackage-S
+
+prep-standalone:
+	$(MAKE) undo-standalone
+	QUILT_PATCHES=debian/patches QUILT_SERIES=series.standalone-build quilt push -a
+	debian/create-standalone-changelog
+
+undo-standalone:
+	test -e .git
+	git checkout debian/changelog CHANGELOG
+	quilt pop -a || true
+
+commit-standalone:
+	QUILT_PATCHES=debian/patches QUILT_SERIES=series.standalone-build  quilt refresh
+
+dpkg-buildpackage%: prep-standalone
+	umask 022; dpkg-buildpackage -rfakeroot $*
+	$(MAKE) undo-standalone
+
+OSXAPP_DEST=tmp/build-dmg/git-annex.app
+OSXAPP_TOP=$(OSXAPP_DEST)/Contents/MacOS/bundle
+osxapp:
+	$(MAKE) git-annex
+	# Remove all RPATHs, both because this overloads the linker on
+	# OSX Sierra, and to avoid the binary looking in someone's home
+	# directory.
+	if otool -l git-annex | grep -q "path "; then \
+		eval install_name_tool $$(otool -l git-annex | grep "path " | sed 's/.*path /-delete_rpath /' | sed 's/ (.*//') git-annex; \
+	fi
+
+	$(MAKE) Build/Standalone
+	./Build/Standalone $(OSXAPP_TOP) $(OSXAPP_DEST)
+
+	gzcat standalone/licences.gz > $(OSXAPP_TOP)/LICENSE
+	cp $(OSXAPP_TOP)/LICENSE tmp/build-dmg/LICENSE.txt
+	cp standalone/trustedkeys.gpg $(OSXAPP_DEST)/Contents/MacOS
+
+	# OSX looks in man dir nearby the bin
+	$(MAKE) install-mans DESTDIR="$(OSXAPP_TOP)/.." SHAREDIR="" PREFIX=""
+
+	cd $(OSXAPP_DEST) && find . -type f > Contents/MacOS/git-annex.MANIFEST
+	cd $(OSXAPP_DEST) && find . -type l >> Contents/MacOS/git-annex.MANIFEST
+	rm -f tmp/git-annex.dmg
+
+	# hdiutil sometimes fails with "resource busy", so try a few times
+	ok=0; for x in 1 2 3 4 5; do \
+		if [ $$ok = 0 ]; then \
+			if hdiutil create -format UDBZ -size 640m -srcfolder tmp/build-dmg \
+				-volname git-annex -o tmp/git-annex.dmg; \
+			then \
+				ok=1; \
+			else \
+				sleep 60; \
+			fi \
+		fi \
+	done; if [ $$ok = 0 ]; then exit 1; fi
+
+distributionupdate:
+	git pull
+	cabal configure
+	rm cabal.project.local~* 2>/dev/null || true
+	ghc -Wall -fno-warn-tabs --make Build/DistributionUpdate -XLambdaCase -XPackageImports
+	./Build/DistributionUpdate
+
+.PHONY: git-annex git-union-merge tags
diff --git a/Messages.hs b/Messages.hs
new file mode 100644
index 0000000000..6b6222a07b
--- /dev/null
+++ b/Messages.hs
@@ -0,0 +1,366 @@
+{- git-annex output messages
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, ScopedTypeVariables, CPP #-}
+
+module Messages (
+	showStartMessage,
+	showEndMessage,
+	StartMessage(..),
+	ActionItem(..),
+	mkActionItem,
+	showNote,
+	showAction,
+	showSideAction,
+	doSideAction,
+	doQuietSideAction,
+	doQuietAction,
+	showStoringStateAction,
+	showOutput,
+	showLongNote,
+	showInfo,
+	showEndOk,
+	showEndFail,
+	showEndResult,
+	endResult,
+	MessageId(..),
+	toplevelFileProblem,
+	toplevelWarning,
+	warning,
+	earlyWarning,
+	warningIO,
+	indent,
+	JSON.JSONChunk(..),
+	maybeShowJSON,
+	maybeShowJSON',
+	maybeAddJSONField,
+	showFullJSON,
+	showCustom,
+	showHeader,
+	showRaw,
+	setupConsole,
+	enableDebugOutput,
+	commandProgressDisabled,
+	commandProgressDisabled',
+	jsonOutputEnabled,
+	outputMessage,
+	withMessageState,
+	MessageState,
+	explain,
+	prompt,
+	mkPrompter,
+	sanitizeTopLevelExceptionMessages,
+) where
+
+import Control.Concurrent
+import Control.Monad.IO.Class
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Char8 as S8
+import System.Exit
+import qualified Control.Monad.Catch as M
+import Data.String
+
+import Common
+import Types
+import Types.Messages
+import Types.ActionItem
+import Types.Concurrency
+import Types.Command (StartMessage(..), SeekInput)
+import Messages.Internal
+import Messages.Concurrent
+import Annex.Debug
+import Annex.Concurrent.Utility
+import Utility.SafeOutput
+import Git.Quote
+import qualified Messages.JSON as JSON
+import qualified Annex
+
+showStartMessage :: StartMessage -> Annex ()
+showStartMessage (StartMessage command ai si) =
+	outputMessage json id $
+		UnquotedString command <> " " <> actionItemDesc ai <> " "
+  where
+	json = JSON.startActionItem command ai si
+showStartMessage (StartUsualMessages command ai si) = do
+	outputType <$> Annex.getState Annex.output >>= \case
+		QuietOutput -> Annex.setOutput NormalOutput
+		_ -> noop
+	showStartMessage (StartMessage command ai si)
+showStartMessage (StartNoMessage _) = noop
+showStartMessage (CustomOutput _) =
+	outputType <$> Annex.getState Annex.output >>= \case
+		NormalOutput -> Annex.setOutput QuietOutput
+		_ -> noop
+
+-- Only show end result if the StartMessage is one that gets displayed.
+showEndMessage :: StartMessage -> Bool -> Annex ()
+showEndMessage (StartMessage _ _ _) = showEndResult
+showEndMessage (StartUsualMessages _ _ _) = showEndResult
+showEndMessage (StartNoMessage _) = const noop
+showEndMessage (CustomOutput _) = const noop
+
+showNote :: StringContainingQuotedPath -> Annex ()
+showNote s = outputMessage (JSON.note (decodeBS (noquote s))) id $ "(" <> s <> ") "
+
+showAction :: StringContainingQuotedPath -> Annex ()
+showAction s = showNote $ s <> "..."
+
+showSideAction :: StringContainingQuotedPath -> Annex ()
+showSideAction m = Annex.getState Annex.output >>= go
+  where
+	go st
+		| sideActionBlock st == StartBlock = do
+			go'
+			let st' = st { sideActionBlock = InBlock }
+			Annex.changeState $ \s -> s { Annex.output = st' }
+		| sideActionBlock st == InBlock = return ()
+		| otherwise = go'
+	go' = outputMessage JSON.none id $ "(" <> m <> "...)\n"
+			
+showStoringStateAction :: Annex ()
+showStoringStateAction = showSideAction "recording state in git"
+
+{- Performs an action, suppressing showSideAction messages. -}
+doQuietSideAction :: Annex a -> Annex a
+doQuietSideAction = doSideAction' InBlock
+
+{- Performs an action, that may call showSideAction multiple times.
+ - Only the first will be displayed. -}
+doSideAction :: Annex a -> Annex a
+doSideAction = doSideAction' StartBlock
+
+doSideAction' :: SideActionBlock -> Annex a -> Annex a
+doSideAction' b = bracket setup cleanup . const
+  where
+	setup = do
+		o <- Annex.getState Annex.output
+		set $ o { sideActionBlock = b }
+		return o
+	cleanup = set
+	set o = Annex.changeState $ \s -> s { Annex.output = o }
+
+{- Performs an action, suppressing all normal standard output,
+ - but not json output. -}
+doQuietAction :: Annex a -> Annex a
+doQuietAction = bracket setup cleanup . const
+  where
+	setup = do
+		o <- Annex.getState Annex.output
+		case outputType o of
+			NormalOutput -> set $ o { outputType = QuietOutput }
+			_ -> noop
+		return o
+	cleanup = set
+	set o = Annex.changeState $ \s -> s {  Annex.output = o }
+
+{- Make way for subsequent output of a command. -}
+showOutput :: Annex ()
+showOutput = unlessM commandProgressDisabled $
+	outputMessage JSON.none id "\n"
+
+showLongNote :: StringContainingQuotedPath -> Annex ()
+showLongNote s = outputMessage (JSON.note (decodeBS (noquote s))) formatLongNote s
+
+formatLongNote :: S.ByteString -> S.ByteString
+formatLongNote s = "\n" <> indent s <> "\n"
+
+-- Used by external special remote, displayed same as showLongNote
+-- to console, but json object containing the info is emitted immediately.
+showInfo :: StringContainingQuotedPath -> Annex ()
+showInfo s = outputMessage' outputJSON (JSON.info (decodeBS (noquote s))) formatLongNote s
+
+showEndOk :: Annex ()
+showEndOk = showEndResult True
+
+showEndFail :: Annex ()
+showEndFail = showEndResult False
+
+showEndResult :: Bool -> Annex ()
+showEndResult ok = outputMessage (JSON.end ok) id $
+	UnquotedByteString (endResult ok) <> "\n"
+
+endResult :: Bool -> S.ByteString
+endResult True = "ok"
+endResult False = "failed"
+
+toplevelMsg :: (Semigroup t, IsString t) => t -> t
+toplevelMsg s = fromString "git-annex: " <> s
+
+toplevelFileProblem :: Bool -> MessageId -> StringContainingQuotedPath -> String -> RawFilePath -> Maybe Key -> SeekInput -> Annex ()
+toplevelFileProblem makeway messageid msg action file mkey si = do
+	maybeShowJSON' $ JSON.start action (Just file) mkey si
+	maybeShowJSON' $ JSON.messageid messageid
+	warning' makeway id (toplevelMsg (QuotedPath file <> " " <> msg))
+	maybeShowJSON' $ JSON.end False
+
+toplevelWarning :: Bool -> StringContainingQuotedPath -> Annex ()
+toplevelWarning makeway s = warning' makeway id (toplevelMsg s)
+
+warning :: StringContainingQuotedPath -> Annex ()
+warning = warning' True indent
+
+earlyWarning :: StringContainingQuotedPath -> Annex ()
+earlyWarning = warning' False id
+
+warning' :: Bool -> (S.ByteString -> S.ByteString) -> StringContainingQuotedPath -> Annex ()
+warning' makeway consolewhitespacef msg = do
+	when makeway $
+		outputMessage JSON.none id "\n"
+	outputError (\s -> consolewhitespacef s <> "\n") msg
+
+{- Not concurrent output safe. -}
+warningIO :: String -> IO ()
+warningIO w = do
+	putStr "\n"
+	hFlush stdout
+	hPutStrLn stderr (safeOutput w)
+
+indent :: S.ByteString -> S.ByteString
+indent = S.intercalate "\n" . map ("  " <>) . S8.lines
+
+{- Shows a JSON chunk only when in json mode. -}
+maybeShowJSON :: JSON.JSONChunk v -> Annex ()
+maybeShowJSON v = void $ withMessageState $ bufferJSON (JSON.add v)
+
+maybeShowJSON' :: JSON.JSONBuilder -> Annex ()
+maybeShowJSON' v = void $ withMessageState $ bufferJSON v
+
+{- Adds a field to the current json object. -}
+maybeAddJSONField :: JSON.ToJSON' v => String -> v -> Annex ()
+maybeAddJSONField f v = case JSON.toJSON' (JSON.AddJSONActionItemField f v) of
+	JSON.Object o -> maybeShowJSON $ JSON.AesonObject o
+	_ -> noop
+
+{- Shows a complete JSON value, only when in json mode. -}
+showFullJSON :: JSON.JSONChunk v -> Annex Bool
+showFullJSON v = withMessageState $ bufferJSON (JSON.complete v)
+
+{- Performs an action that outputs nonstandard/customized output, and
+ - in JSON mode wraps its output in JSON.start and JSON.end, so it's
+ - a complete JSON document.
+ - This is only needed when showStartMessage and showEndOk is not used.
+ -}
+showCustom :: String -> SeekInput -> Annex Bool -> Annex ()
+showCustom command si a = do
+	outputMessage (JSON.start command Nothing Nothing si) id ""
+	r <- a
+	outputMessage (JSON.end r) id ""
+
+showHeader :: S.ByteString -> Annex ()
+showHeader h = outputMessage JSON.none id (UnquotedByteString h <> ": ")
+
+showRaw :: S.ByteString -> Annex ()
+showRaw s = outputMessage JSON.none id (UnquotedByteString s <> "\n")
+
+setupConsole :: IO ()
+setupConsole = do
+	dd <- debugDisplayer
+	configureDebug dd (DebugSelector (const False))
+	{- Force output to be line buffered. This is normally the case when
+	 - it's connected to a terminal, but may not be when redirected to
+	 - a file or a pipe. -}
+	hSetBuffering stdout LineBuffering
+	hSetBuffering stderr LineBuffering
+#ifdef mingw32_HOST_OS
+	{- Avoid outputting CR at end of line on Windows. git commands do
+	 - not ouput CR there. -}
+	hSetNewlineMode stdout noNewlineTranslation
+	hSetNewlineMode stderr noNewlineTranslation
+#endif
+
+enableDebugOutput :: Annex ()
+enableDebugOutput = do
+	selector <- Annex.getRead Annex.debugselector
+	dd <- liftIO debugDisplayer
+	liftIO $ configureDebug dd selector
+
+debugDisplayer :: IO (S.ByteString -> IO ())
+debugDisplayer = do
+	-- Debug output will get mixed in with any other output
+	-- made by git-annex, but use a lock to prevent two debug lines
+	-- that are displayed at the same time from mixing together.
+	lock <- newMVar ()
+	return $ \s -> withMVar lock $ \() -> do
+		S.hPutStr stderr (safeOutput s <> "\n")
+		hFlush stderr
+
+{- Should commands that normally output progress messages have that
+ - output disabled? -}
+commandProgressDisabled :: Annex Bool
+commandProgressDisabled = withMessageState $ return . commandProgressDisabled'
+
+commandProgressDisabled' :: MessageState -> Bool
+commandProgressDisabled' s = case outputType s of
+	NormalOutput -> concurrentOutputEnabled s
+	QuietOutput -> True
+	JSONOutput _ -> True
+	SerializedOutput _ _ -> True
+
+jsonOutputEnabled :: Annex Bool
+jsonOutputEnabled = withMessageState $ \s -> return $
+	case outputType s of
+		JSONOutput _ -> True
+		_ -> False
+
+explain :: ActionItem -> Maybe StringContainingQuotedPath -> Annex ()
+explain ai (Just msg) = do
+	rd <- Annex.getRead id
+	let d = actionItemDesc ai
+	let msg' = "[ " <> (if d == mempty then "" else (d <> " ")) <> msg <> " ]\n"
+	if Annex.explainenabled rd
+		then outputMessage JSON.none id msg'
+		else fastDebug' rd "Messages.explain" (decodeBS (noquote msg'))
+explain _ _ = return ()
+
+{- Prevents any concurrent console access while running an action, so
+ - that the action is the only thing using the console, and can eg prompt
+ - the user.
+ -}
+prompt :: Annex a -> Annex a
+prompt a = do
+	p <- mkPrompter
+	p a
+
+{- Like prompt, but for a non-annex action that prompts. -}
+mkPrompter :: (MonadMask m, MonadIO m) => Annex (m a -> m a)
+mkPrompter = getConcurrency >>= \case
+	NonConcurrent -> return id
+	(Concurrent _) -> goconcurrent
+	ConcurrentPerCpu -> goconcurrent
+  where
+	goconcurrent = withMessageState $ \s -> do
+		let l = promptLock s
+		let (run, cleanup) = case outputType s of
+			SerializedOutput h hr ->
+				( \a -> do
+					liftIO $ outputSerialized h BeginPrompt
+					liftIO $ waitOutputSerializedResponse hr ReadyPrompt
+					a
+				, liftIO $ outputSerialized h EndPrompt
+				)
+			_ ->
+				( hideRegionsWhile s
+				, noop
+				)
+		return $ \a ->
+			debugLocks $ bracketIO
+				(takeMVar l)
+				(\v -> putMVar l v >> cleanup)
+				(const $ run a)
+
+{- Catch all (non-async and not ExitCode) exceptions and display, 
+ - santizing any control characters in the exceptions.
+ -
+ - Exits nonzero on exception, so should only be used at topmost level.
+ -}
+sanitizeTopLevelExceptionMessages :: IO a -> IO a
+sanitizeTopLevelExceptionMessages a = a `catches`
+	((M.Handler (\ (e :: ExitCode) -> throwM e)) : nonAsyncHandler go)
+  where
+	go e = do
+		hPutStrLn stderr $ safeOutput $ toplevelMsg (show e)
+		exitWith $ ExitFailure 1
diff --git a/Messages/Concurrent.hs b/Messages/Concurrent.hs
new file mode 100644
index 0000000000..5e4138416e
--- /dev/null
+++ b/Messages/Concurrent.hs
@@ -0,0 +1,138 @@
+{- git-annex output messages, including concurrent output to display regions
+ -
+ - Copyright 2010-2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module Messages.Concurrent where
+
+import Types
+import Types.Messages
+import qualified Annex
+
+import Common
+import qualified System.Console.Concurrent as Console
+import qualified System.Console.Regions as Regions
+import Control.Concurrent.STM
+import Control.Monad.IO.Class
+import qualified Data.Text as T
+#ifndef mingw32_HOST_OS
+import GHC.IO.Encoding
+#endif
+
+{- Outputs a message in a concurrency safe way.
+ -
+ - The message may be an error message, in which case it goes to stderr.
+ -
+ - When built without concurrent-output support, the fallback action is run
+ - instead.
+ -}
+concurrentMessage :: MessageState -> Bool -> String -> Annex () -> Annex ()
+concurrentMessage s iserror msg fallback 
+	| concurrentOutputEnabled s =
+		go =<< consoleRegion <$> Annex.getState Annex.output
+	| otherwise = fallback
+  where
+	go Nothing
+		| iserror = liftIO $ Console.errorConcurrent msg
+		| otherwise = liftIO $ Console.outputConcurrent msg
+	go (Just r) = do
+		-- Can't display the error to stdout while
+		-- console regions are in use, so set the errflag
+		-- to get it to display to stderr later.
+		when iserror $ do
+			Annex.changeState $ \st ->
+				st { Annex.output = (Annex.output st) { consoleRegionErrFlag = True } }
+		liftIO $ atomically $ do
+			Regions.appendConsoleRegion r msg
+			rl <- takeTMVar Regions.regionList
+			putTMVar Regions.regionList
+				(if r `elem` rl then rl else r:rl)
+
+{- Runs an action in its own dedicated region of the console.
+ -
+ - The region is closed at the end or on exception, and at that point
+ - the value of the region is displayed in the scrolling area above
+ - any other active regions.
+ -
+ - When not at a console, a region is not displayed until the action is
+ - complete.
+ -}
+inOwnConsoleRegion :: MessageState -> Annex a -> Annex a
+inOwnConsoleRegion s a
+	| concurrentOutputEnabled s = do
+		r <- mkregion
+		setregion (Just r)
+		eret <- tryNonAsync a `onException` rmregion r
+		case eret of
+			Left e -> do
+				-- Add error message to region before it closes.
+				concurrentMessage s True (show e) noop
+				rmregion r
+				throwM e
+			Right ret -> do
+				rmregion r
+				return ret
+	| otherwise = a
+  where
+	-- The region is allocated here, but not displayed until 
+	-- a message is added to it. This avoids unnecessary screen
+	-- updates when a region does not turn out to need to be used.
+	mkregion = Regions.newConsoleRegion Regions.Linear ""
+	setregion r = Annex.changeState $ \st -> st
+		{ Annex.output = (Annex.output st) { consoleRegion = r } }
+	rmregion r = do
+		errflag <- consoleRegionErrFlag <$> Annex.getState Annex.output
+		let h = if errflag then Console.StdErr else Console.StdOut
+		Annex.changeState $ \st -> st
+			{ Annex.output = (Annex.output st) { consoleRegionErrFlag = False } }
+		setregion Nothing
+		liftIO $ atomically $ do
+			t <- Regions.getConsoleRegion r
+			unless (T.null t) $
+				Console.bufferOutputSTM h t
+			Regions.closeConsoleRegion r
+
+{- The progress region is displayed inline with the current console region. -}
+withProgressRegion
+	:: (MonadIO m, MonadMask m)
+	=> MessageState 
+	-> (Regions.ConsoleRegion -> m a) -> m a
+withProgressRegion st a =
+	Regions.withConsoleRegion (maybe Regions.Linear Regions.InLine parent) a
+  where
+	parent = consoleRegion st
+
+instance Regions.LiftRegion Annex where
+	liftRegion = liftIO . atomically
+
+{- The concurrent-output library uses Text, which bypasses the normal use
+ - of the fileSystemEncoding to roundtrip invalid characters, when in a
+ - non-unicode locale. Work around that problem by avoiding using
+ - concurrent output when not in a unicode locale. -}
+concurrentOutputSupported :: IO Bool
+#ifndef mingw32_HOST_OS
+concurrentOutputSupported = do
+	enc <- getLocaleEncoding
+	return ("UTF" `isInfixOf` textEncodingName enc)
+#else
+concurrentOutputSupported = return True -- Windows is always unicode
+#endif
+
+{- Hide any currently displayed console regions while running the action,
+ - so that the action can use the console itself. -}
+hideRegionsWhile :: (MonadIO m, Monad m, MonadMask m) => MessageState -> m a -> m a
+hideRegionsWhile s a
+	| concurrentOutputEnabled s = bracket setup cleanup go
+	| otherwise = a
+  where
+	setup = liftIO $ 
+		Regions.waitDisplayChange $ swapTMVar Regions.regionList []
+	cleanup = liftIO . void . atomically . swapTMVar Regions.regionList
+	go _ = do
+		liftIO $ hFlush stdout
+		a
diff --git a/Messages/Internal.hs b/Messages/Internal.hs
new file mode 100644
index 0000000000..a16c7d2c61
--- /dev/null
+++ b/Messages/Internal.hs
@@ -0,0 +1,118 @@
+{- git-annex output messages, including concurrent output to display regions
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Messages.Internal where
+
+import Common
+import Annex
+import Types.Messages
+import Messages.Concurrent
+import qualified Messages.JSON as JSON
+import Messages.JSON (JSONBuilder)
+import Git.Quote
+import Types.GitConfig
+
+import qualified Data.ByteString as S
+
+withMessageState :: (MessageState -> Annex a) -> Annex a
+withMessageState a = Annex.getState Annex.output >>= a
+
+outputMessage :: JSONBuilder -> (S.ByteString -> S.ByteString) -> StringContainingQuotedPath -> Annex ()
+outputMessage = outputMessage' bufferJSON
+
+outputMessage' :: (JSONBuilder -> MessageState -> Annex Bool) -> JSONBuilder -> (S.ByteString -> S.ByteString) -> StringContainingQuotedPath -> Annex ()
+outputMessage' jsonoutputter jsonbuilder consolewhitespacef msg = withMessageState $ \s -> case outputType s of
+	NormalOutput
+		| concurrentOutputEnabled s -> do
+			qp <- coreQuotePath <$> Annex.getGitConfig
+			liftIO $ clearProgressMeter s
+			concurrentMessage s False (decodeBS (consolewhitespacef (quote qp msg))) q
+		| otherwise -> do
+			qp <- coreQuotePath <$> Annex.getGitConfig
+			liftIO $ clearProgressMeter s
+			liftIO $ flushed $ S.putStr (consolewhitespacef (quote qp msg))
+	JSONOutput _ -> void $ jsonoutputter jsonbuilder s
+	QuietOutput -> q
+	SerializedOutput h _ -> do
+		qp <- coreQuotePath <$> Annex.getGitConfig
+		liftIO $ outputSerialized h $ OutputMessage $ consolewhitespacef $ quote qp msg
+		void $ jsonoutputter jsonbuilder s
+
+-- Buffer changes to JSON until end is reached and then emit it.
+bufferJSON :: JSONBuilder -> MessageState -> Annex Bool
+bufferJSON jsonbuilder s = case outputType s of
+	JSONOutput _ -> go (flushed . JSON.emit)
+	SerializedOutput h _ -> go (outputSerialized h . JSONObject . JSON.encode)
+	_ -> return False
+  where
+	go emitter
+		| endjson = do
+			Annex.changeState $ \st -> 
+				st { Annex.output = s { jsonBuffer = Nothing } }
+			maybe noop (liftIO . emitter . JSON.finalize) json
+			return True
+		| otherwise = do
+			Annex.changeState $ \st ->
+			        st { Annex.output = s { jsonBuffer = json } }
+			return True
+	
+	(json, endjson) = case jsonbuilder i of
+		Nothing -> (jsonBuffer s, False)
+		(Just (j, e)) -> (Just j, e)
+	
+	i = case jsonBuffer s of
+		Nothing -> Nothing
+		Just b -> Just (b, False)
+
+-- Immediately output JSON.
+outputJSON :: JSONBuilder -> MessageState -> Annex Bool
+outputJSON jsonbuilder s = case outputType s of
+	JSONOutput _ -> go (flushed . JSON.emit)
+	SerializedOutput h _ -> go (outputSerialized h . JSONObject . JSON.encode)
+	_ -> return False
+  where
+	go emitter = do
+		maybe noop (liftIO . emitter)
+			(fst <$> jsonbuilder Nothing)
+		return True
+
+outputError :: (S.ByteString -> S.ByteString) -> StringContainingQuotedPath -> Annex ()
+outputError consolewhitespacef msg = withMessageState $ \s -> case (outputType s, jsonBuffer s) of
+        (JSONOutput jsonoptions, Just jb) | jsonErrorMessages jsonoptions ->
+		let jb' = Just (JSON.addErrorMessage (lines (decodeBS (noquote msg))) jb)
+		in Annex.changeState $ \st ->
+			st { Annex.output = s { jsonBuffer = jb' } }
+	(SerializedOutput h _, _) -> do
+		qp <- coreQuotePath <$> Annex.getGitConfig
+		liftIO $ outputSerialized h $ OutputError $ decodeBS $
+			consolewhitespacef $ quote qp msg
+	_
+		| concurrentOutputEnabled s -> do
+			qp <- coreQuotePath <$> Annex.getGitConfig
+			concurrentMessage s True (decodeBS $ consolewhitespacef $ quote qp msg) go
+		| otherwise -> go
+  where
+	go = do
+		qp <- coreQuotePath <$> Annex.getGitConfig
+		liftIO $ hFlush stdout
+		liftIO $ S.hPutStr stderr (consolewhitespacef $ quote qp msg)
+		liftIO $ hFlush stderr
+
+q :: Monad m => m ()
+q = noop
+
+flushed :: IO () -> IO ()
+flushed a = a >> hFlush stdout
+
+outputSerialized :: (SerializedOutput -> IO ()) -> SerializedOutput -> IO ()
+outputSerialized = id
+
+-- | Wait for the specified response.
+waitOutputSerializedResponse :: (IO (Maybe SerializedOutputResponse)) -> SerializedOutputResponse -> IO ()
+waitOutputSerializedResponse getr r = tryIO getr >>= \case
+	Right (Just r') | r' == r -> return ()
+	v -> giveup $ "serialized output protocol error; expected " ++ show r ++ " got " ++ show v
diff --git a/Messages/JSON.hs b/Messages/JSON.hs
new file mode 100644
index 0000000000..6c7830b689
--- /dev/null
+++ b/Messages/JSON.hs
@@ -0,0 +1,256 @@
+{- git-annex command-line JSON output and input
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, GADTs, CPP #-}
+
+module Messages.JSON (
+	JSONBuilder,
+	JSONChunk(..),
+	emit,
+	emit',
+	none,
+	start,
+	startActionItem,
+	end,
+	finalize,
+	addErrorMessage,
+	note,
+	info,
+	messageid,
+	add,
+	complete,
+	progress,
+	DualDisp(..),
+	ObjectMap(..),
+	JSONActionItem(..),
+	AddJSONActionItemField(..),
+	module Utility.Aeson,
+) where
+
+import Control.Applicative
+import qualified Data.Map as M
+import qualified Data.Vector as V
+import qualified Data.ByteString.Lazy as L
+#if MIN_VERSION_aeson(2,0,0)
+import qualified Data.Aeson.KeyMap as HM
+#else
+import qualified Data.HashMap.Strict as HM
+#endif
+import System.IO
+import System.IO.Unsafe (unsafePerformIO)
+import Control.Concurrent
+import Data.Maybe
+import Data.Monoid
+import Prelude
+
+import Types.Command (SeekInput(..))
+import Types.ActionItem
+import Types.UUID
+import Key
+import Utility.Metered
+import Utility.Percentage
+import Utility.Aeson
+import Utility.FileSystemEncoding
+import Types.Messages
+
+-- A global lock to avoid concurrent threads emitting json at the same time.
+{-# NOINLINE emitLock #-}
+emitLock :: MVar ()
+emitLock = unsafePerformIO $ newMVar ()
+
+emit :: Object -> IO ()
+emit = emit' . encode
+
+emit' :: L.ByteString -> IO ()
+emit' b = do
+	takeMVar emitLock
+	L.hPut stdout b
+	putStr "\n"
+	putMVar emitLock ()
+
+-- Building up a JSON object can be done by first using start,
+-- then add and note and messageid any number of times, and finally
+-- complete.
+type JSONBuilder = Maybe (Object, Bool) -> Maybe (Object, Bool)
+
+none :: JSONBuilder
+none = id
+
+start :: String -> Maybe RawFilePath -> Maybe Key -> SeekInput -> JSONBuilder
+start command file key si _ = case j of
+	Object o -> Just (o, False)
+	_ -> Nothing
+  where
+	j = toJSON' $ JSONActionItem
+		{ itemCommand = Just command
+		, itemKey = key
+		, itemFile = fromRawFilePath <$> file
+		, itemUUID = Nothing
+		, itemFields = Nothing :: Maybe Bool
+		, itemSeekInput = si
+		}
+
+startActionItem :: String -> ActionItem -> SeekInput -> JSONBuilder
+startActionItem command ai si _ = case j of
+	Object o -> Just (o, False)
+	_ -> Nothing
+  where
+	j = toJSON' $ JSONActionItem
+		{ itemCommand = Just command
+		, itemKey = actionItemKey ai
+		, itemFile = fromRawFilePath <$> actionItemFile ai
+		, itemUUID = actionItemUUID ai
+		, itemFields = Nothing :: Maybe Bool
+		, itemSeekInput = si
+		}
+
+end :: Bool -> JSONBuilder
+end b (Just (o, _)) = Just (HM.insert "success" (toJSON' b) o, True)
+end _ Nothing = Nothing
+
+-- Always include error-messages field, even if empty,
+-- to make the json be self-documenting.
+finalize :: Object -> Object
+finalize o = addErrorMessage [] o
+
+addErrorMessage :: [String] -> Object -> Object
+addErrorMessage msg o =
+	HM.unionWith combinearray (HM.singleton "error-messages" v) o
+  where
+	combinearray (Array new) (Array old) = Array (old <> new)
+	combinearray new _old = new
+	v = Array $ V.fromList $ map (String . packString) msg
+
+note :: String -> JSONBuilder
+note _ Nothing = Nothing
+note s (Just (o, e)) = Just (HM.unionWith combinelines (HM.singleton "note" (toJSON' s)) o, e)
+  where
+	combinelines (String new) (String old) =
+		String (old <> "\n" <> new)
+	combinelines new _old = new
+
+messageid :: MessageId -> JSONBuilder
+messageid _ Nothing = Nothing
+messageid mid (Just (o, e)) = Just (HM.unionWith replaceold (HM.singleton "message-id" (toJSON' (show mid))) o, e)
+  where
+	replaceold new _old = new
+
+info :: String -> JSONBuilder
+info s _ = case j of
+	Object o -> Just (o, True)
+	_ -> Nothing
+  where
+	j = object ["info" .= toJSON' s]
+
+data JSONChunk v where
+	AesonObject :: Object -> JSONChunk Object
+	JSONChunk :: ToJSON' v => [(String, v)] -> JSONChunk [(String, v)]
+
+add :: JSONChunk v -> JSONBuilder
+add v (Just (o, e)) = case j of
+	Object o' -> Just (HM.union o' o, e)
+	_ -> Nothing
+  where
+	j = case v of
+		AesonObject ao -> Object ao
+		JSONChunk l -> object $ map mkPair l
+	mkPair (s, d) = (textKey (packString s), toJSON' d)
+add _ Nothing = Nothing
+
+complete :: JSONChunk v -> JSONBuilder
+complete v _ = add v (Just (HM.empty, True))
+
+-- Show JSON formatted progress, including the current state of the JSON 
+-- object for the action being performed.
+progress :: Maybe Object -> Maybe TotalSize -> BytesProcessed -> IO ()
+progress maction msize bytesprocessed = 
+	case j of
+		Object o -> emit $ case maction of
+			Just action -> HM.insert "action" (Object action) o
+			Nothing -> o
+		_ -> return ()
+  where
+	n = fromBytesProcessed bytesprocessed :: Integer
+	j = case msize of
+		Just (TotalSize size) -> object
+			[ "byte-progress" .= n
+			, "percent-progress" .= showPercentage 2 (percentage size n)
+			, "total-size" .= size
+			]
+		Nothing -> object
+			[ "byte-progress" .= n ]
+
+-- A value that can be displayed either normally, or as JSON.
+data DualDisp = DualDisp
+	{ dispNormal :: String
+	, dispJson :: String
+	}
+
+instance ToJSON' DualDisp where
+	toJSON' = toJSON' . dispJson
+
+instance Show DualDisp where
+	show = dispNormal
+
+-- A Map that is serialized to JSON as an object, with each key being a
+-- field of the object. This is different from Aeson's normal 
+-- serialization of Map, which uses "[key, value]".
+data ObjectMap a = ObjectMap { fromObjectMap :: M.Map String a }
+
+instance ToJSON' a => ToJSON' (ObjectMap a) where
+	toJSON' (ObjectMap m) = object $ map go $ M.toList m
+	  where
+		go (k, v) = (textKey (packString k), toJSON' v)
+
+-- An item that a git-annex command acts on, and displays a JSON object about.
+data JSONActionItem a = JSONActionItem
+	{ itemCommand :: Maybe String
+	, itemKey :: Maybe Key
+	, itemFile :: Maybe FilePath
+	, itemUUID :: Maybe UUID
+	, itemFields :: Maybe a
+	, itemSeekInput :: SeekInput
+	}
+	deriving (Show)
+
+instance ToJSON' a => ToJSON' (JSONActionItem a) where
+	toJSON' i = object $ catMaybes
+		[ Just $ "command" .= itemCommand i
+		, case itemKey i of
+			Just k -> Just $ "key" .= toJSON' k
+			Nothing -> Nothing
+		, case itemFile i of
+			Just f -> Just $ "file" .= toJSON' f
+			Nothing -> Nothing
+		, case itemFields i of
+			Just f -> Just $ "fields" .= toJSON' f
+			Nothing -> Nothing
+		, case itemUUID i of
+			Just u -> Just $ "uuid" .= toJSON' u
+			Nothing -> Nothing
+		, Just $ "input" .= fromSeekInput (itemSeekInput i)
+		]
+
+instance FromJSON a => FromJSON (JSONActionItem a) where
+	parseJSON (Object v) = JSONActionItem
+		<$> (v .:? "command")
+		<*> (maybe (return Nothing) parseJSON =<< (v .:? "key"))
+		<*> (v .:? "file")
+		<*> (v .:? "uuid")
+		<*> (v .:? "fields")
+		-- ^ fields is used for metadata, which is currently the
+		-- only json that gets parsed
+		<*> pure (SeekInput [])
+	parseJSON _ = mempty
+
+-- This can be used to populate a field after a JSONActionItem
+-- has already been started.
+data AddJSONActionItemField a = AddJSONActionItemField String a
+	deriving (Show)
+
+instance ToJSON' a => ToJSON' (AddJSONActionItemField a) where
+	toJSON' (AddJSONActionItemField f a) = object [ (textKey (packString f), toJSON' a) ]
diff --git a/Messages/Progress.hs b/Messages/Progress.hs
new file mode 100644
index 0000000000..c726149d18
--- /dev/null
+++ b/Messages/Progress.hs
@@ -0,0 +1,225 @@
+{- git-annex progress output
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE FlexibleInstances #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Messages.Progress where
+
+import Common
+import qualified Annex
+import Messages
+import Utility.Metered
+import Types
+import Types.Messages
+import Types.Key
+import Types.KeySource
+import Types.StallDetection (BwRate(..))
+import Utility.InodeCache
+import qualified Messages.JSON as JSON
+import Messages.Concurrent
+import Messages.Internal
+import Utility.SafeOutput
+
+import qualified System.Console.Regions as Regions
+import qualified System.Console.Concurrent as Console
+import Control.Monad.IO.Class (MonadIO)
+import Data.IORef
+
+{- Class of things from which a size can be gotten to display a progress
+ - meter. -}
+class MeterSize t where
+	getMeterSize :: t -> Annex (Maybe TotalSize)
+
+instance MeterSize t => MeterSize (Maybe t) where
+	getMeterSize Nothing = pure Nothing
+	getMeterSize (Just t) = getMeterSize t
+
+instance MeterSize FileSize where
+	getMeterSize = pure . Just . TotalSize
+
+instance MeterSize Key where
+	getMeterSize = pure . fmap TotalSize . fromKey keySize
+
+instance MeterSize InodeCache where
+	getMeterSize = pure . Just . TotalSize . inodeCacheFileSize
+
+instance MeterSize KeySource where
+	getMeterSize = maybe (pure Nothing) getMeterSize . inodeCache
+
+{- When the key's size is not known, the file is statted to get the size.
+ - This allows uploads of keys without size to still have progress
+ - displayed.
+ -}
+data KeySizer = KeySizer Key (Annex (Maybe RawFilePath))
+
+instance MeterSize KeySizer where
+	getMeterSize (KeySizer k getsrcfile) = case fromKey keySize k of
+		Just sz -> return (Just (TotalSize sz))
+		Nothing -> do
+			srcfile <- getsrcfile
+			case srcfile of
+				Nothing -> return Nothing
+				Just f -> catchMaybeIO $ liftIO $
+					TotalSize <$> getFileSize f
+
+{- Shows a progress meter while performing an action.
+ - The action is passed the meter and a callback to use to update the meter.
+ -}
+metered
+	:: MeterSize sizer
+	=> Maybe MeterUpdate
+	-> sizer
+	-> Maybe BwRate
+	-> (Meter -> MeterUpdate -> Annex a)
+	-> Annex a
+metered othermeterupdate sizer bwlimit a = withMessageState $ \st -> do
+	sz <- getMeterSize sizer
+	metered' st setclear othermeterupdate sz bwlimit showOutput a
+  where
+	setclear c = Annex.changeState $ \st -> st
+		{ Annex.output = (Annex.output st) { clearProgressMeter = c } }
+
+metered'
+	:: (Monad m, MonadIO m, MonadMask m)
+	=> MessageState
+	-> (IO () -> m ())
+	-- ^ This should set clearProgressMeter when progress meters
+	-- are being displayed; not needed when outputType is not
+	-- NormalOutput.
+	-> Maybe MeterUpdate
+	-> Maybe TotalSize
+	-> Maybe BwRate
+	-> m ()
+	-- ^ this should run showOutput
+	-> (Meter -> MeterUpdate -> m a)
+	-> m a
+metered' st setclear othermeterupdate msize bwlimit showoutput a = go st
+  where
+	go (MessageState { outputType = QuietOutput }) = nometer
+	go (MessageState { outputType = NormalOutput, concurrentOutputEnabled = False }) = do
+		showoutput
+		meter <- liftIO $ mkMeter msize $ 
+			displayMeterHandle stdout bandwidthMeter
+		let clear = clearMeterHandle meter stdout
+		setclear clear
+		m <- liftIO $ rateLimitMeterUpdate consoleratelimit meter $
+			updateMeter meter
+		r <- a meter =<< mkmeterupdate m
+		setclear noop
+		liftIO clear
+		return r
+	go (MessageState { outputType = NormalOutput, concurrentOutputEnabled = True }) =
+		withProgressRegion st $ \r -> do
+			meter <- liftIO $ mkMeter msize $ \_ msize' old new ->
+				let s = bandwidthMeter msize' old new
+				in Regions.setConsoleRegion r ('\n' : s)
+			m <- liftIO $ rateLimitMeterUpdate consoleratelimit meter $
+				updateMeter meter
+			a meter =<< mkmeterupdate m
+	go (MessageState { outputType = JSONOutput jsonoptions })
+		| jsonProgress jsonoptions = do
+			let buf = jsonBuffer st
+			meter <- liftIO $ mkMeter msize $ \_ msize' _old new ->
+				JSON.progress buf msize' (meterBytesProcessed new)
+			m <- liftIO $ rateLimitMeterUpdate jsonratelimit meter $
+				updateMeter meter
+			a meter =<< mkmeterupdate m
+		| otherwise = nometer
+	go (MessageState { outputType = SerializedOutput h _ }) = do
+		liftIO $ outputSerialized h BeginProgressMeter
+		case msize of
+			Just sz -> liftIO $ outputSerialized h $ UpdateProgressMeterTotalSize sz
+			Nothing -> noop
+		szv <- liftIO $ newIORef msize
+		meter <- liftIO $ mkMeter msize $ \_ msize' _old new -> do
+			case msize' of
+				Just sz | msize' /= msize -> do
+					psz <- readIORef szv
+					when (msize' /= psz) $ do
+						writeIORef szv msize'
+						outputSerialized h $ UpdateProgressMeterTotalSize sz
+				_ -> noop
+			outputSerialized h $ UpdateProgressMeter $
+				meterBytesProcessed new
+		m <- liftIO $ rateLimitMeterUpdate minratelimit meter $
+			updateMeter meter
+		(a meter =<< mkmeterupdate m)
+			`finally` (liftIO $ outputSerialized h EndProgressMeter)
+	nometer = do
+		dummymeter <- liftIO $ mkMeter Nothing $
+			\_ _ _ _ -> return ()
+		a dummymeter =<< mkmeterupdate (const noop)
+
+	mkmeterupdate m = 
+		let mu = case othermeterupdate of
+			Nothing -> m
+			Just om -> combineMeterUpdate m om
+		in case bwlimit of
+			Nothing -> return mu
+			Just (BwRate sz duration) -> liftIO $
+				bwLimitMeterUpdate sz duration mu
+
+	consoleratelimit = 0.2
+
+	jsonratelimit = 0.1
+
+	minratelimit = min consoleratelimit jsonratelimit
+		
+{- Poll file size to display meter. -}
+meteredFile :: RawFilePath -> Maybe MeterUpdate -> Key -> (MeterUpdate -> Annex a) -> Annex a
+meteredFile file combinemeterupdate key a = 
+	metered combinemeterupdate key Nothing $ \_ p ->
+		watchFileSize file p a
+
+{- Progress dots. -}
+showProgressDots :: Annex ()
+showProgressDots = outputMessage JSON.none id "."
+
+{- Runs a command, that may output progress to either stdout or
+ - stderr, as well as other messages.
+ -
+ - In quiet mode, the output is suppressed, except for error messages.
+ -}
+progressCommand :: FilePath -> [CommandParam] -> Annex Bool
+progressCommand cmd params = progressCommandEnv cmd params Nothing
+
+progressCommandEnv :: FilePath -> [CommandParam] -> Maybe [(String, String)] -> Annex Bool
+progressCommandEnv cmd params environ = ifM commandProgressDisabled
+	( do
+		oh <- mkOutputHandler
+		liftIO $ demeterCommandEnv oh cmd params environ
+	, liftIO $ boolSystemEnv cmd params environ
+	)
+
+mkOutputHandler :: Annex OutputHandler
+mkOutputHandler = OutputHandler
+	<$> commandProgressDisabled
+	<*> mkStderrEmitter
+
+mkOutputHandlerQuiet :: Annex OutputHandler
+mkOutputHandlerQuiet = OutputHandler
+	<$> pure True
+	<*> mkStderrEmitter
+
+mkStderrRelayer :: Annex (ProcessHandle -> Handle -> IO ())
+mkStderrRelayer = do
+	quiet <- commandProgressDisabled
+	emitter <- mkStderrEmitter
+	return $ \ph h -> avoidProgress quiet ph h emitter
+
+{- Generates an IO action that can be used to emit stderr.
+ -
+ - When a progress meter is displayed, this takes care to avoid
+ - messing it up with interleaved stderr from a command.
+ -}
+mkStderrEmitter :: Annex (String -> IO ())
+mkStderrEmitter = withMessageState go
+  where
+	go s
+		| concurrentOutputEnabled s = return (Console.errorConcurrent . safeOutput)
+		| otherwise = return (hPutStrLn stderr . safeOutput)
diff --git a/Messages/Serialized.hs b/Messages/Serialized.hs
new file mode 100644
index 0000000000..494df5aac5
--- /dev/null
+++ b/Messages/Serialized.hs
@@ -0,0 +1,111 @@
+{- serialized output
+ -
+ - Copyright 2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+
+module Messages.Serialized (
+	relaySerializedOutput,
+	outputSerialized,
+	waitOutputSerializedResponse,
+) where
+
+import Common
+import Annex
+import Types.Messages
+import Messages
+import Messages.Internal
+import Messages.Progress
+import qualified Messages.JSON as JSON
+import Utility.Metered (BytesProcessed, setMeterTotalSize)
+import Git.Quote
+
+import Control.Monad.IO.Class (MonadIO)
+
+-- | Relay serialized output from a child process to the console.
+relaySerializedOutput
+	:: (Monad m, MonadIO m, MonadMask m)
+	=> m (Either SerializedOutput r)
+	-- ^ Get next serialized output, or final value to return.
+	-> (SerializedOutputResponse -> m ())
+	-- ^ Send response to child process.
+	-> (Maybe BytesProcessed -> m ())
+	-- ^ When a progress meter is running, it is updated with
+	-- progress meter values sent by the process.
+	-- When a progress meter is stopped, Nothing is sent.
+	-> (forall a. Annex a -> m a)
+	-- ^ Run an annex action in the monad. Will not be used with
+	-- actions that block for a long time.
+	-> m r
+relaySerializedOutput getso sendsor meterreport runannex = go Nothing
+  where
+	go st = loop st >>= \case
+		Right r -> return r
+		Left st' -> go st'
+	
+	loop st = getso >>= \case
+		Right r -> return (Right r)
+		Left (OutputMessage msg) -> do
+			runannex $ outputMessage'
+				(\_ _ -> return False)
+				id
+				id
+				(UnquotedByteString msg)
+			loop st
+		Left (OutputError msg) -> do
+			runannex $ outputError id $ UnquotedString msg
+			loop st		
+		Left (JSONObject b) -> do
+			runannex $ withMessageState $ \s -> case outputType s of
+				JSONOutput _ -> liftIO $ flushed $ JSON.emit' b
+				SerializedOutput h _ -> liftIO $
+					outputSerialized h $ JSONObject b
+				_ -> q
+			loop st
+		Left BeginProgressMeter -> do
+			ost <- runannex (Annex.getState Annex.output)
+			let setclear = const noop
+			-- Display a progress meter while running, until
+			-- the meter ends or a final value is returned.
+			metered' ost setclear Nothing Nothing Nothing (runannex showOutput) 
+				(\meter meterupdate -> loop (Just (meter, meterupdate)))
+				>>= \case
+					Right r -> return (Right r)
+					-- Continue processing serialized
+					-- output after the progress meter
+					-- is done.
+					Left _st' -> loop Nothing
+		Left EndProgressMeter -> do
+			meterreport Nothing
+			return (Left st)
+		Left (UpdateProgressMeter n) -> do
+			case st of
+				Just (_, meterupdate) -> do
+					meterreport (Just n)
+					liftIO $ meterupdate n
+				Nothing -> noop
+			loop st
+		Left (UpdateProgressMeterTotalSize sz) -> do
+			case st of
+				Just (meter, _) -> liftIO $
+					setMeterTotalSize meter sz
+				Nothing -> noop
+			loop st
+		Left BeginPrompt -> do
+			prompter <- runannex mkPrompter
+			v <- prompter $ do
+				sendsor ReadyPrompt
+				-- Continue processing serialized output
+				-- until EndPrompt or a final value is
+				-- returned. (EndPrompt is all that
+				-- ought to be sent while in a prompt
+				-- really, but if something else did get
+				-- sent, display it just in case.)
+				loop st
+			case v of
+				Right r -> return (Right r)
+				Left st' -> loop st'
+		Left EndPrompt -> return (Left st)
diff --git a/NEWS b/NEWS
new file mode 100644
index 0000000000..38c7572e0b
--- /dev/null
+++ b/NEWS
@@ -0,0 +1,232 @@
+git-annex (10.20230626) upstream; urgency=medium
+
+  Many commands now quote filenames that contain unusual characters the
+  same way that git does, to avoid exposing control characters to the
+  terminal. The core.quotePath config can be set to false to disable this
+  quoting.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 26 Jun 2023 10:38:07 -0400
+
+git-annex (10.20220218) upstream; urgency=medium
+
+  Transition notice: Commands like `git-annex get foo*` have changed to error
+  out when some of files are not checked into the repository. To get back the
+  previous behavior of silently skipping unknown files, use git config
+  to set annex.skipunknown to true.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 18 Feb 2022 13:12:21 -0400
+
+git-annex (8.20211028) upstream; urgency=medium
+
+  This version of git-annex removes support for communicating with git-annex
+  remotes that have version 6.20180312 or older installed.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 05 Jan 2022 10:09:11 -0400
+
+git-annex (8.20200523) upstream; urgency=medium
+
+  Transition notice: Commands like `git-annex get foo*` silently skip over
+  files that are not checked into git. Since that can be surprising in many
+  cases, the behavior will change to erroring out when one of the listed
+  files is not checked into git. This change is planned for a git-annex
+  release in early 2022. If you would like to keep the current
+  behavior, use git config to set annex.skipunknown to true.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 28 May 2020 13:23:40 -0400
+
+git-annex (8.20200226) upstream; urgency=medium
+  
+  This version of git-annex uses repository version 8 for all repositories.
+
+  Existing repositories will be automatically upgraded by default.
+  You can prevent this, by running: git config annex.autoupgraderepository false
+ 
+  The upgrade process involves regenerating some sqlite databases. There are a
+  couple consequences of the upgrade to keep in mind:
+
+  * Any incremental fscks that were started in v7 won't resume where
+    they left off in v8, but will instead begin again from the first file.
+  * An interrupted export that was started in v7 won't resume where it left
+    off after upgrade to v8; files will be re-uploaded to the export remote.
+  * After the upgrade, git-annex will in some situations have to do extra
+    work while it finishes populating its sqlite databases.
+
+  Also, there are some behavior changes around adding dotfiles. While before
+  git-annex add skipped adding dotfiles when operating on whole directories,
+  and added dotfiles that were explicitly listed to the annex, it now adds
+  dotfiles to git by default, unless annex.dotfiles is set to true.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 26 Feb 2020 17:18:16 -0400
+
+git-annex (7.20200226) upstream; urgency=high
+
+  There was a serious regression in gcrypt and encrypted git-lfs remotes.
+  Since version 7.20200202.7, git-annex incorrectly stored content
+  on those remotes without encrypting it.
+
+  If your remotes are affected, you will want to make sure to delete
+  any content that git-annex has stored on them that is not encrypted!
+
+  One way to do so is, before upgrading to this version,
+  run git-annex move --from the affected remotes. It will move
+  only the content that was not encrypted.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 26 Feb 2020 17:18:16 -0400
+
+git-annex (7.20191024) upstream; urgency=medium
+
+  When annex.largefiles is not configured, `git add` and `git commit -a`
+  add files to git, not to the annex. If you have gotten used to `git add`
+  adding all files to the annex, you can get that behavior back by running:
+  git config annex.largefiles anything
+
+ -- Joey Hess <id@joeyh.name>  Thu, 24 Oct 2019 13:46:52 -0400
+
+git-annex (7.20190912) upstream; urgency=medium
+
+  This version of git-annex uses repository version 7 for all repositories.
+
+  Existing v5 repositories will be automatically upgraded by default.
+  You can prevent this, by running: git config annex.autoupgraderepository false
+
+  A v7 repository can can have some files locked while other files are
+  unlocked, and all git and git-annex commands can be used on both locked and
+  unlocked files. It's a good idea to make sure that all users of the
+  repository have upgraded git-annex and upgraded their repositories
+  to the new version before starting to use that feature, since old
+  versions of git-annex will ignore the new unlocked files.
+
+  The behavior of some commands changes in an upgraded repository:
+  
+  * `git add` will add files to the annex, rather than adding them directly
+     to the git repository. To cause some files to be added directly
+     to git, you can configure `annex.largefiles`. For example:
+
+     git config annex.largefiles "largerthan=100kb and not (include=*.c or include=*.h)"
+
+  * `git annex unlock` and `git annex lock` change how the pointer to 
+    the annexed content is stored in git. If you commit the change,
+    that will impact all clones of the repository.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 13 Sep 2019 12:19:55 -0400
+
+git-annex (7.20181031) upstream; urgency=medium
+
+  Repository version 7 is now available. v6 repositories will automatically
+  upgrade to v7. v5 repositories are still supported and will not be
+  automatically upgraded yet.
+
+  Direct mode is deprecated, and upgrading direct mode repositories to v7 is
+  encouraged, unless they need to remain usable by older versions of git-annex.
+  Just run `git annex upgrade`.
+
+  git-annex will no longer initialize new repositories on crippled filesystems
+  using direct mode, instead it uses v7.
+
+  The git-annex Android app is no longer being updated. Users of the app
+  should remove it and install using the new Termux based installation method.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 31 Oct 2018 13:05:48 -0400
+
+git-annex (6.20180626) upstream; urgency=high
+
+  A security fix has changed git-annex to refuse to download content from
+  some special remotes when the content cannot be verified with a hash check.
+  In particular URL and WORM keys stored on such remotes won't be downloaded.
+  See the documentation of the annex.security.allow-unverified-downloads
+  configuration for how to deal with this if it affects your files.
+
+  A security fix has changed git-annex to only support http, https, and ftp
+  URL schemes by default. You can enable other URL schemes, at your own risk,
+  using annex.security.allowed-url-schemes.
+
+  A related security fix prevents git-annex from connecting to http
+  servers (and proxies) on localhost or private networks. This can
+  be overridden, at your own risk, using annex.security.allowed-http-addresses.
+  
+  Setting annex.web-options no longer is enough to make curl be used,
+  and youtube-dl is also no longer used by default. See the
+  documentation of annex.security.allowed-http-addresses for
+  details and how to enable them.
+
+  The annex.web-download-command configuration has been removed,
+  use annex.web-options instead.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 15 Jun 2018 17:54:23 -0400
+
+git-annex (6.20180309) upstream; urgency=medium
+
+  Note that, due to not using rsync to transfer files over ssh
+  any longer, permissions and other file metadata of annexed files
+  will no longer be preserved when copying them to and from ssh remotes.
+  Other remotes never supported preserving that information, so
+  this is not considered a regression.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 09 Mar 2018 13:22:47 -0400
+
+git-annex (6.20170228) upstream; urgency=medium
+
+  This version of git-annex has mitigations for SHA1 hash collision
+  problems.
+  
+  A new annex.securehashesonly configuration, when used in combination with
+  signed git commits, avoids potential hash collision problems in git-annex
+  repositories. For details, see this web page:
+  <https://git-annex.branchable.com/tips/using_signed_git_commits/>
+
+ -- Joey Hess <id@joeyh.name>  Tue, 28 Feb 2017 13:28:50 -0400
+
+git-annex (6.20170101) upstream; urgency=medium
+
+  XMPP support has been removed from the assistant in this release.
+
+  If your repositories used XMPP to keep in sync, that will no longer
+  work, and you should enable some other remote to keep them in sync.
+  A ssh server is one way, or use the new Tor pairing feature.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 27 Dec 2016 16:37:46 -0400
+
+git-annex (4.20131002) upstream; urgency=low
+
+   The layout of gcrypt repositories has changed, and
+   if you created one you must manually upgrade it.
+   See /usr/share/doc/git-annex/html/upgrades/gcrypt.html
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 24 Sep 2013 13:55:23 -0400
+
+git-annex (3.20120123) upstream; urgency=low
+
+  There was a bug in the handling of directory special remotes that
+  could cause partial file contents to be stored in them. If you use
+  a directory special remote, you should fsck it, to avoid potential
+  data loss.
+
+  Example: git annex fsck --from mydirectory
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 19 Jan 2012 15:24:23 -0400
+
+git-annex (3.20110624) upstream; urgency=low
+
+  There has been another change to the git-annex data store.
+  Use `git annex upgrade` to migrate your repositories to the new
+  layout. See <http://git-annex.branchable.com/upgrades/> or
+  /usr/share/doc/git-annex/html/upgrades.html
+
+  The significant change this time is that the .git-annex/ directory
+  is gone; instead there is a git-annex branch that is automatically
+  maintained by git-annex, and encapsulates all its state nicely out
+  of your way.
+
+  You should make sure you include the git-annex branch when
+  git pushing and pulling.
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 21 Jun 2011 20:18:00 -0400
+
+git-annex (0.20110316) upstream; urgency=low
+
+  This version reorganises the layout of git-annex's files in your repository.
+  There is an upgrade process to convert a repository from the old git-annex
+  to this version. See <http://git-annex.branchable.com/upgrades/> or
+  /usr/share/doc/git-annex/html/upgrades.html
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 16 Mar 2011 15:49:15 -0400
diff --git a/P2P/Address.hs b/P2P/Address.hs
new file mode 100644
index 0000000000..a7b3c6db07
--- /dev/null
+++ b/P2P/Address.hs
@@ -0,0 +1,98 @@
+{- P2P protocol addresses
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module P2P.Address where
+
+import qualified Annex
+import Annex.Common
+import Git
+import Git.Types
+import Creds
+import Utility.AuthToken
+import Utility.Tor
+import qualified Utility.RawFilePath as R
+
+import qualified Data.Text as T
+import System.PosixCompat.Files (fileOwner, fileGroup)
+
+-- | A P2P address, without an AuthToken.
+--
+-- This is enough information to connect to the peer,
+-- but not enough to authenticate with it.
+data P2PAddress = TorAnnex OnionAddress OnionPort
+	deriving (Eq, Show)
+
+-- | A P2P address, with an AuthToken.
+--
+-- This is enough information to connect to the peer, and authenticate with
+-- it.
+data P2PAddressAuth = P2PAddressAuth P2PAddress AuthToken
+	deriving (Eq, Show)
+
+class FormatP2PAddress a where
+	formatP2PAddress :: a -> String
+	unformatP2PAddress :: String -> Maybe a
+
+instance FormatP2PAddress P2PAddress where
+	formatP2PAddress (TorAnnex (OnionAddress onionaddr) onionport) =
+		torAnnexScheme ++ ":" ++ onionaddr ++ ":" ++ show onionport
+	unformatP2PAddress s
+		| (torAnnexScheme ++ ":") `isPrefixOf` s = do
+			let s' = dropWhile (== ':') $ dropWhile (/= ':') s
+			let (onionaddr, ps) = separate (== ':') s'
+			onionport <- readish ps
+			return (TorAnnex (OnionAddress onionaddr) onionport)
+		| otherwise = Nothing
+
+torAnnexScheme :: String
+torAnnexScheme = "tor-annex:"
+
+instance FormatP2PAddress P2PAddressAuth where
+	formatP2PAddress (P2PAddressAuth addr authtoken) =
+		formatP2PAddress addr ++ ":" ++ T.unpack (fromAuthToken authtoken)
+	unformatP2PAddress s = do
+		let (ra, rs) = separate (== ':') (reverse s)
+		addr <- unformatP2PAddress (reverse rs)
+		authtoken <- toAuthToken (T.pack $ reverse ra)
+		return (P2PAddressAuth addr authtoken)
+
+repoP2PAddress :: Repo -> Maybe P2PAddress
+repoP2PAddress (Repo { location = Url url }) = unformatP2PAddress (show url)
+repoP2PAddress _ = Nothing
+
+-- | Load known P2P addresses for this repository.
+loadP2PAddresses :: Annex [P2PAddress]
+loadP2PAddresses = mapMaybe unformatP2PAddress . maybe [] lines
+	<$> readCreds p2pAddressCredsFile
+
+-- | Store a new P2P address for this repository.
+storeP2PAddress :: P2PAddress -> Annex ()
+storeP2PAddress addr = do
+	addrs <- loadP2PAddresses
+	unless (addr `elem` addrs) $ do
+		let s = unlines $ map formatP2PAddress (addr:addrs)
+		let tmpnam = p2pAddressCredsFile ++ ".new"
+		writeCreds s tmpnam
+		tmpf <- credsFile tmpnam
+		destf <- credsFile p2pAddressCredsFile
+		-- This may be run by root, so make the creds file
+		-- and directory have the same owner and group as
+		-- the git repository directory has.
+		st <- liftIO . R.getFileStatus . toRawFilePath
+			=<< Annex.fromRepo repoLocation
+		let fixowner f = R.setOwnerAndGroup (toRawFilePath f) (fileOwner st) (fileGroup st)
+		liftIO $ do
+			fixowner tmpf
+			fixowner (takeDirectory tmpf)
+			fixowner (takeDirectory (takeDirectory tmpf))
+			renameFile tmpf destf
+
+p2pAddressCredsFile :: FilePath
+p2pAddressCredsFile = "p2paddrs"
+
+torAppName :: AppName
+torAppName = "tor-annex"
diff --git a/P2P/Annex.hs b/P2P/Annex.hs
new file mode 100644
index 0000000000..14a7aef1fc
--- /dev/null
+++ b/P2P/Annex.hs
@@ -0,0 +1,269 @@
+{- P2P protocol, Annex implementation
+ -
+ - Copyright 2016-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes, FlexibleContexts #-}
+
+module P2P.Annex
+	( RunState(..)
+	, mkRunState
+	, P2PConnection(..)
+	, runFullProto
+	) where
+
+import Annex.Common
+import Annex.Content
+import Annex.Transfer
+import Annex.ChangedRefs
+import P2P.Protocol
+import P2P.IO
+import Logs.Location
+import Types.NumCopies
+import Utility.Metered
+import Annex.Verify
+
+import Control.Monad.Free
+import Control.Concurrent.STM
+import qualified Data.ByteString as S
+
+-- Full interpreter for Proto, that can receive and send objects.
+runFullProto :: RunState -> P2PConnection -> Proto a -> Annex (Either ProtoFailure a)
+runFullProto runst conn = go
+  where
+	go :: RunProto Annex
+	go (Pure v) = return (Right v)
+	go (Free (Net n)) = runNet runst conn go n
+	go (Free (Local l)) = runLocal runst go l
+
+runLocal :: RunState -> RunProto Annex -> LocalF (Proto a) -> Annex (Either ProtoFailure a)
+runLocal runst runner a = case a of
+	TmpContentSize k next -> do
+		tmp <- fromRepo $ gitAnnexTmpObjectLocation k
+		size <- liftIO $ catchDefaultIO 0 $ getFileSize tmp
+		runner (next (Len size))
+	FileSize f next -> do
+		size <- liftIO $ catchDefaultIO 0 $ getFileSize (toRawFilePath f)
+		runner (next (Len size))
+	ContentSize k next -> do
+		let getsize = liftIO . catchMaybeIO . getFileSize
+		size <- inAnnex' isJust Nothing getsize k
+		runner (next (Len <$> size))
+	ReadContent k af o sender next -> do
+		let proceed c = do
+			r <- tryNonAsync c
+			case r of
+				Left e -> return $ Left $ ProtoFailureException e
+				Right (Left e) -> return $ Left e
+				Right (Right ok) -> runner (next ok)
+		-- If the content is not present, or the transfer doesn't
+		-- run for any other reason, the sender action still must
+		-- be run, so is given empty and Invalid data.
+		let fallback = runner (sender mempty (return Invalid))
+		v <- tryNonAsync $ prepSendAnnex k
+		case v of
+			Right (Just (f, _sz, checkchanged)) -> proceed $ do
+				-- alwaysUpload to allow multiple uploads of the same key.
+				let runtransfer ti = transfer alwaysUpload k af Nothing $ \p ->
+					sinkfile f o checkchanged sender p ti
+				checktransfer runtransfer fallback
+ 			Right Nothing -> proceed fallback
+			Left e -> return $ Left $ ProtoFailureException e
+	StoreContent k af o l getb validitycheck next -> do
+		-- This is the same as the retrievalSecurityPolicy of
+		-- Remote.P2P and Remote.Git.
+		let rsp = RetrievalAllKeysSecure
+		v <- tryNonAsync $ do
+			iv <- startVerifyKeyContentIncrementally DefaultVerify k
+			let runtransfer ti = 
+				Right <$> transfer download' k af Nothing (\p ->
+					logStatusAfter k $ getViaTmp rsp DefaultVerify k af Nothing $ \tmp ->
+						storefile (fromRawFilePath tmp) o l getb iv validitycheck p ti)
+			let fallback = return $ Left $
+				ProtoFailureMessage "transfer already in progress, or unable to take transfer lock"
+			checktransfer runtransfer fallback
+		case v of
+			Left e -> return $ Left $ ProtoFailureException e
+			Right (Left e) -> return $ Left e
+			Right (Right ok) -> runner (next ok)
+	StoreContentTo dest iv o l getb validitycheck next -> do
+		v <- tryNonAsync $ do
+			let runtransfer ti = Right
+				<$> storefile dest o l getb iv validitycheck nullMeterUpdate ti
+			let fallback = return $ Left $
+				ProtoFailureMessage "Transfer failed"
+			checktransfer runtransfer fallback
+		case v of
+			Left e -> return $ Left $ ProtoFailureException e
+			Right (Left e) -> return $ Left e
+			Right (Right ok) -> runner (next ok)
+	SetPresent k u next -> do
+		v <- tryNonAsync $ logChange k u InfoPresent
+		case v of
+			Left e -> return $ Left $ ProtoFailureException e
+			Right () -> runner next
+	CheckContentPresent k next -> do
+		v <- tryNonAsync $ inAnnex k
+		case v of
+			Left e -> return $ Left $ ProtoFailureException e
+			Right result -> runner (next result)
+	RemoveContent k next -> do
+		let cleanup = do
+			logStatus k InfoMissing
+			return True
+		v <- tryNonAsync $
+			ifM (Annex.Content.inAnnex k)
+				( lockContentForRemoval k cleanup $ \contentlock -> do
+					removeAnnex contentlock
+					cleanup
+				, return True
+				)
+		case v of
+			Left e -> return $ Left $ ProtoFailureException e
+			Right result -> runner (next result)
+	TryLockContent k protoaction next -> do
+		v <- tryNonAsync $ lockContentShared k $ \verifiedcopy -> 
+			case verifiedcopy of
+				LockedCopy _ -> runner (protoaction True)
+				_ -> runner (protoaction False)
+		-- If locking fails, lockContentShared throws an exception.
+		-- Let the peer know it failed.
+		case v of
+			Left _ -> runner $ do
+				protoaction False
+				next
+			Right _ -> runner next
+	WaitRefChange next -> case runst of
+		Serving _ (Just h) _ -> do
+			v <- tryNonAsync $ liftIO $ waitChangedRefs h
+			case v of
+				Left e -> return $ Left $ ProtoFailureException e
+				Right changedrefs -> runner (next changedrefs)
+		_ -> return $ Left $
+			ProtoFailureMessage "change notification not available"
+	UpdateMeterTotalSize m sz next -> do
+		liftIO $ setMeterTotalSize m sz
+		runner next
+	RunValidityCheck checkaction next -> runner . next =<< checkaction
+  where
+	transfer mk k af sd ta = case runst of
+		-- Update transfer logs when serving.
+		-- Using noRetry because we're the sender.
+		Serving theiruuid _ _ -> 
+			mk theiruuid k af sd noRetry ta noNotification
+		-- Transfer logs are updated higher in the stack when
+		-- a client.
+		Client _ -> ta nullMeterUpdate
+	
+	resumefromoffset o incrementalverifier p h
+		| o /= 0 = do
+			p' <- case incrementalverifier of
+				Just iv -> do
+					go iv o
+					return p
+				_ -> return $ offsetMeterUpdate p (toBytesProcessed o)
+			-- Make sure the handle is seeked to the offset.
+			-- (Reading the file probably left it there
+			-- when that was done, but let's be sure.)
+			hSeek h AbsoluteSeek o
+			return p'
+		| otherwise = return p
+	  where
+		go iv n
+			| n == 0 = return ()
+			| otherwise = do
+				let c = if n > fromIntegral defaultChunkSize
+					then defaultChunkSize
+					else fromIntegral n
+				b <- S.hGet h c
+				updateIncrementalVerifier iv b
+				unless (b == S.empty) $
+					go iv (n - fromIntegral (S.length b))
+
+	storefile dest (Offset o) (Len l) getb incrementalverifier validitycheck p ti = do
+		v <- runner getb
+		case v of
+			Right b -> do
+				liftIO $ withBinaryFile dest ReadWriteMode $ \h -> do
+					p' <- resumefromoffset o incrementalverifier p h
+					let writechunk = case incrementalverifier of
+						Nothing -> \c -> S.hPut h c
+						Just iv -> \c -> do
+							S.hPut h c
+							updateIncrementalVerifier iv c
+					meteredWrite p' writechunk b
+				indicatetransferred ti
+
+				rightsize <- do
+					sz <- liftIO $ getFileSize (toRawFilePath dest)
+					return (toInteger sz == l + o)
+					
+				runner validitycheck >>= \case
+					Right (Just Valid) -> case incrementalverifier of
+						Just iv
+							| rightsize -> liftIO (finalizeIncrementalVerifier iv) >>= \case
+								Nothing -> return (True, UnVerified)
+								Just True -> return (True, Verified)
+								Just False -> do
+									verificationOfContentFailed (toRawFilePath dest)
+									return (False, UnVerified)
+							| otherwise -> return (False, UnVerified)
+						Nothing -> return (rightsize, UnVerified)
+					Right (Just Invalid) | l == 0 ->
+						-- Special case, for when
+						-- content was not
+						-- available to send, 
+						-- which is indicated by
+						-- sending 0 bytes and 
+						-- Invalid.
+						return (False, UnVerified)
+					_ -> do
+						-- Invalid, or old protocol
+						-- version. Validity is not
+						-- known. Force content
+						-- verification.
+						return (rightsize, MustVerify)
+			Left e -> giveup $ describeProtoFailure e
+	
+	sinkfile f (Offset o) checkchanged sender p ti = bracket setup cleanup go
+	  where
+		setup = liftIO $ openBinaryFile f ReadMode
+		cleanup = liftIO . hClose
+		go h = do
+			let p' = offsetMeterUpdate p (toBytesProcessed o)
+			when (o /= 0) $
+				liftIO $ hSeek h AbsoluteSeek o
+			b <- liftIO $ hGetContentsMetered h p'
+
+			let validitycheck = local $ runValidityCheck $ 
+				checkchanged >>= return . \case
+					False -> Invalid
+					True -> Valid
+			r <- runner (sender b validitycheck)
+			indicatetransferred ti
+			return r
+	
+	-- This allows using actions like download and viaTmp
+	-- that may abort a transfer, and clean up the protocol after them.
+	--
+	-- Runs an action that may make a transfer, passing a transfer
+	-- indicator. The action should call indicatetransferred on it,
+	-- only after it's actually sent/received the all data.
+	--
+	-- If the action ends without having called indicatetransferred,
+	-- runs the fallback action, which can close the protoocol
+	-- connection or otherwise clean up after the transfer not having
+	-- occurred.
+	--
+	-- If the action throws an exception, the fallback is not run.
+	checktransfer ta fallback = do
+		ti <- liftIO $ newTVarIO False
+		r <- ta ti
+		ifM (liftIO $ atomically $ readTVar ti)
+			( return r
+			, fallback
+			)
+
+	indicatetransferred ti = liftIO $ atomically $ writeTVar ti True
diff --git a/P2P/Auth.hs b/P2P/Auth.hs
new file mode 100644
index 0000000000..346b781b37
--- /dev/null
+++ b/P2P/Auth.hs
@@ -0,0 +1,66 @@
+{- P2P authtokens
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module P2P.Auth where
+
+import Annex.Common
+import Creds
+import P2P.Address
+import Utility.AuthToken
+import Utility.Tor
+import Utility.Env
+
+import qualified Data.Text as T
+
+-- | Load authtokens that are accepted by this repository.
+loadP2PAuthTokens :: Annex AllowedAuthTokens
+loadP2PAuthTokens = allowedAuthTokens <$> loadP2PAuthTokens'
+
+loadP2PAuthTokens' :: Annex [AuthToken]
+loadP2PAuthTokens' = mapMaybe toAuthToken
+        . map T.pack
+        . lines
+        . fromMaybe []
+        <$> readCreds p2pAuthCredsFile
+
+-- | Stores an AuthToken, making it be accepted by this repository.
+storeP2PAuthToken :: AuthToken -> Annex ()
+storeP2PAuthToken t = do
+	ts <- loadP2PAuthTokens'
+	unless (t `elem` ts) $ do
+		let d = unlines $ map (T.unpack . fromAuthToken) (t:ts)
+		writeCreds d p2pAuthCredsFile
+
+p2pAuthCredsFile :: FilePath
+p2pAuthCredsFile = "p2pauth"
+
+-- | Loads the AuthToken to use when connecting with a given P2P address.
+--
+-- It's loaded from the first line of the creds file, but
+-- GIT_ANNEX_P2P_AUTHTOKEN overrides.
+loadP2PRemoteAuthToken :: P2PAddress -> Annex (Maybe AuthToken)
+loadP2PRemoteAuthToken addr = maybe Nothing mk <$> getM id
+	[ liftIO $ getEnv "GIT_ANNEX_P2P_AUTHTOKEN"
+	, readCreds (addressCredsFile addr)
+	]
+  where
+	mk = toAuthToken . T.pack . takeWhile (/= '\n')
+
+p2pAuthTokenEnv :: String
+p2pAuthTokenEnv = "GIT_ANNEX_P2P_AUTHTOKEN"
+
+-- | Stores the AuthToken to use when connecting with a given P2P address.
+storeP2PRemoteAuthToken :: P2PAddress -> AuthToken -> Annex ()
+storeP2PRemoteAuthToken addr t = writeCreds
+	(T.unpack $ fromAuthToken t)
+	(addressCredsFile addr)
+
+addressCredsFile :: P2PAddress -> FilePath
+-- We can omit the port and just use the onion address for the creds file,
+-- because any given tor hidden service runs on a single port and has a
+-- unique onion address.
+addressCredsFile (TorAnnex (OnionAddress onionaddr) _port) = onionaddr
diff --git a/P2P/IO.hs b/P2P/IO.hs
new file mode 100644
index 0000000000..b37ce058c0
--- /dev/null
+++ b/P2P/IO.hs
@@ -0,0 +1,394 @@
+{- P2P protocol, IO implementation
+ -
+ - Copyright 2016-2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes, FlexibleContexts, OverloadedStrings, CPP #-}
+
+module P2P.IO
+	( RunProto
+	, RunState(..)
+	, mkRunState
+	, P2PConnection(..)
+	, ConnIdent(..)
+	, ClosableConnection(..)
+	, stdioP2PConnection
+	, connectPeer
+	, closeConnection
+	, serveUnixSocket
+	, setupHandle
+	, ProtoFailure(..)
+	, describeProtoFailure
+	, runNetProto
+	, runNet
+	) where
+
+import Common
+import P2P.Protocol
+import P2P.Address
+import Git
+import Git.Command
+import Utility.AuthToken
+import Utility.SimpleProtocol
+import Utility.Metered
+import Utility.Tor
+import Utility.FileMode
+import Utility.Debug
+import Types.UUID
+import Annex.ChangedRefs
+import qualified Utility.RawFilePath as R
+
+import Control.Monad.Free
+import Control.Monad.IO.Class
+import System.IO.Error
+import Network.Socket
+import Control.Concurrent
+import Control.Concurrent.Async
+import Control.Concurrent.STM
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Lazy as L
+import qualified Network.Socket as S
+import System.PosixCompat.Files (groupReadMode, groupWriteMode, otherReadMode, otherWriteMode)
+
+-- Type of interpreters of the Proto free monad.
+type RunProto m = forall a. Proto a -> m (Either ProtoFailure a)
+
+data ProtoFailure
+	= ProtoFailureMessage String
+	| ProtoFailureException SomeException
+	| ProtoFailureIOError IOError
+
+describeProtoFailure :: ProtoFailure -> String
+describeProtoFailure (ProtoFailureMessage s) = s
+describeProtoFailure (ProtoFailureException e) = show e
+describeProtoFailure (ProtoFailureIOError e) = show e
+
+data RunState
+	= Serving UUID (Maybe ChangedRefsHandle) (TVar ProtocolVersion)
+	| Client (TVar ProtocolVersion)
+
+mkRunState :: (TVar ProtocolVersion -> RunState) -> IO RunState
+mkRunState mk = do
+	tvar <- newTVarIO defaultProtocolVersion
+	return (mk tvar)
+
+data P2PConnection = P2PConnection
+	{ connRepo :: Repo
+	, connCheckAuth :: (AuthToken -> Bool)
+	, connIhdl :: Handle
+	, connOhdl :: Handle
+	, connIdent :: ConnIdent
+	}
+
+-- Identifier for a connection, only used for debugging.
+newtype ConnIdent = ConnIdent (Maybe String)
+
+data ClosableConnection conn
+	= OpenConnection conn
+	| ClosedConnection
+
+-- P2PConnection using stdio.
+stdioP2PConnection :: Git.Repo -> P2PConnection
+stdioP2PConnection g = P2PConnection
+	{ connRepo = g
+	, connCheckAuth = const False
+	, connIhdl = stdin
+	, connOhdl = stdout
+	, connIdent = ConnIdent Nothing
+	}
+
+-- Opens a connection to a peer. Does not authenticate with it.
+connectPeer :: Git.Repo -> P2PAddress -> IO P2PConnection
+connectPeer g (TorAnnex onionaddress onionport) = do
+	h <- setupHandle =<< connectHiddenService onionaddress onionport
+	return $ P2PConnection
+		{ connRepo = g
+		, connCheckAuth = const False
+		, connIhdl = h
+		, connOhdl = h
+		, connIdent = ConnIdent Nothing
+		}
+
+closeConnection :: P2PConnection -> IO ()
+closeConnection conn = do
+	hClose (connIhdl conn)
+	hClose (connOhdl conn)
+
+-- Serves the protocol on a unix socket.
+--
+-- The callback is run to serve a connection, and is responsible for
+-- closing the Handle when done.
+--
+-- Note that while the callback is running, other connections won't be
+-- processed, so longterm work should be run in a separate thread by
+-- the callback.
+serveUnixSocket :: FilePath -> (Handle -> IO ()) -> IO ()
+serveUnixSocket unixsocket serveconn = do
+	removeWhenExistsWith R.removeLink (toRawFilePath unixsocket)
+	soc <- S.socket S.AF_UNIX S.Stream S.defaultProtocol
+	S.bind soc (S.SockAddrUnix unixsocket)
+	-- Allow everyone to read and write to the socket,
+	-- so a daemon like tor, that is probably running as a different
+	-- de sock $ addModes
+	-- user, can access it.
+	-- 
+        -- Connections have to authenticate to do anything,
+        -- so it's fine that other local users can connect to the
+        -- socket.
+	modifyFileMode (toRawFilePath unixsocket) $ addModes
+		[groupReadMode, groupWriteMode, otherReadMode, otherWriteMode]
+	S.listen soc 2
+	forever $ do
+		(conn, _) <- S.accept soc
+		setupHandle conn >>= serveconn
+
+setupHandle :: Socket -> IO Handle
+setupHandle s = do
+	h <- socketToHandle s ReadWriteMode
+	hSetBuffering h LineBuffering
+	hSetBinaryMode h False
+	return h
+
+-- Purposefully incomplete interpreter of Proto.
+--
+-- This only runs Net actions. No Local actions will be run
+-- (those need the Annex monad) -- if the interpreter reaches any,
+-- it returns Nothing.
+runNetProto :: RunState -> P2PConnection -> Proto a -> IO (Either ProtoFailure a)
+runNetProto runst conn = go
+  where
+	go :: RunProto IO
+	go (Pure v) = return (Right v)
+	go (Free (Net n)) = runNet runst conn go n
+	go (Free (Local _)) = return $ Left $
+		ProtoFailureMessage "unexpected annex operation attempted"
+
+-- Interpreter of the Net part of Proto.
+--
+-- An interpreter of Proto has to be provided, to handle the rest of Proto
+-- actions.
+runNet :: (MonadIO m, MonadMask m) => RunState -> P2PConnection -> RunProto m -> NetF (Proto a) -> m (Either ProtoFailure a)
+runNet runst conn runner f = case f of
+	SendMessage m next -> do
+		v <- liftIO $ tryNonAsync $ do
+			let l = unwords (formatMessage m)
+			debugMessage conn "P2P >" m
+			hPutStrLn (connOhdl conn) l
+			hFlush (connOhdl conn)
+		case v of
+			Left e -> return $ Left $ ProtoFailureException e
+			Right () -> runner next
+	ReceiveMessage next -> do
+		v <- liftIO $ tryIOError $ getProtocolLine (connIhdl conn)
+		case v of
+			Left e -> return $ Left $ ProtoFailureIOError e
+			Right Nothing -> return $ Left $
+				ProtoFailureMessage "protocol error"
+			Right (Just l) -> case parseMessage l of
+				Just m -> do
+					liftIO $ debugMessage conn "P2P <" m
+					runner (next (Just m))
+				Nothing -> runner (next Nothing)
+	SendBytes len b p next -> do
+		v <- liftIO $ tryNonAsync $ do
+			ok <- sendExactly len b (connOhdl conn) p
+			hFlush (connOhdl conn)
+			return ok
+		case v of
+			Right True -> runner next
+			Right False -> return $ Left $
+				ProtoFailureMessage "short data write"
+			Left e -> return $ Left $ ProtoFailureException e
+	ReceiveBytes len p next -> do
+		v <- liftIO $ tryNonAsync $ receiveExactly len (connIhdl conn) p
+		case v of
+			Left e -> return $ Left $ ProtoFailureException e
+			Right b -> runner (next b)
+	CheckAuthToken _u t next -> do
+		let authed = connCheckAuth conn t
+		runner (next authed)
+	Relay hin hout next -> do
+		v <- liftIO $ runRelay runnerio hin hout
+		case v of
+			Left e -> return $ Left e
+			Right exitcode -> runner (next exitcode)
+	RelayService service next -> do
+		v <- liftIO $ runRelayService conn runnerio service
+		case v of
+			Left e -> return $ Left e
+			Right () -> runner next
+	SetProtocolVersion v next -> do
+		liftIO $ atomically $ writeTVar versiontvar v
+		runner next
+	GetProtocolVersion next ->
+		liftIO (readTVarIO versiontvar) >>= runner . next
+  where
+	-- This is only used for running Net actions when relaying,
+	-- so it's ok to use runNetProto, despite it not supporting
+	-- all Proto actions.
+	runnerio = runNetProto runst conn
+	versiontvar = case runst of
+		Serving _ _ tv -> tv
+		Client tv -> tv
+
+debugMessage :: P2PConnection -> String -> Message -> IO ()
+debugMessage conn prefix m = do
+	tid <- myThreadId	
+	debug "P2P.IO" $ concat $ catMaybes $
+		[ (\ident -> "[" ++ ident ++ "] ") <$> mident
+		, Just $ "[" ++ show tid ++ "] "
+		, Just $ prefix ++ " " ++ unwords (formatMessage safem)
+		]
+  where
+	safem = case m of
+		AUTH u _ -> AUTH u nullAuthToken
+		_ -> m
+	ConnIdent mident = connIdent conn
+
+-- Send exactly the specified number of bytes or returns False.
+--
+-- The ByteString can be larger or smaller than the specified length.
+-- For example, it can be lazily streaming from a file that gets
+-- appended to, or truncated.
+--
+-- Must avoid sending too many bytes as it would confuse the other end.
+-- This is easily dealt with by truncating it.
+--
+-- If too few bytes are sent, the only option is to give up on this
+-- connection. False is returned to indicate this problem.
+sendExactly :: Len -> L.ByteString -> Handle -> MeterUpdate -> IO Bool
+sendExactly (Len n) b h p = do
+	sent <- meteredWrite' p (B.hPut h) (L.take (fromIntegral n) b)
+	return (fromBytesProcessed sent == n)
+
+receiveExactly :: Len -> Handle -> MeterUpdate -> IO L.ByteString
+receiveExactly (Len n) h p = hGetMetered h (Just n) p
+
+runRelay :: RunProto IO -> RelayHandle -> RelayHandle -> IO (Either ProtoFailure ExitCode)
+runRelay runner (RelayHandle hout) (RelayHandle hin) = 
+	bracket setup cleanup go
+		`catchNonAsync` (return . Left . ProtoFailureException)
+  where
+	setup = do
+		v <- newEmptyMVar
+		t1 <- async $ relayFeeder runner v hin
+		t2 <- async $ relayReader v hout
+		return (v, t1, t2)
+	
+	cleanup (_, t1, t2) = do
+		hClose hin
+		hClose hout
+		cancel t1
+		cancel t2
+	
+	go (v, _, _) = relayHelper runner v
+
+runRelayService :: P2PConnection -> RunProto IO -> Service -> IO (Either ProtoFailure ())
+runRelayService conn runner service =
+	withCreateProcess serviceproc' go
+		`catchNonAsync` (return . Left . ProtoFailureException)
+  where
+	cmd = case service of
+		UploadPack -> "upload-pack"
+		ReceivePack -> "receive-pack"
+	
+	serviceproc = gitCreateProcess
+		[ Param cmd
+		, File (fromRawFilePath (repoPath (connRepo conn)))
+		] (connRepo conn)
+	serviceproc' = serviceproc 
+		{ std_out = CreatePipe
+		, std_in = CreatePipe
+		}
+
+	go (Just hin) (Just hout) _ pid = do
+		v <- newEmptyMVar
+		r <- withAsync (relayFeeder runner v hin) $ \_ ->
+			withAsync (relayReader v hout) $ \_ ->
+				withAsync (waitexit v pid) $ \_ -> do
+					r <- runrelay v
+					hClose hin
+					hClose hout
+					return r
+		void $ waitForProcess pid
+		return r
+	go _ _ _ _ = error "internal"
+	
+	runrelay v = relayHelper runner v >>= \case
+		Left e -> return $ Left e
+		Right exitcode -> runner $
+			net $ relayToPeer (RelayDone exitcode)
+
+	waitexit v pid = putMVar v . RelayDone =<< waitForProcess pid
+
+-- Processes RelayData as it is put into the MVar.
+relayHelper :: RunProto IO -> MVar RelayData -> IO (Either ProtoFailure ExitCode)
+relayHelper runner v = loop
+  where
+	loop = do
+		d <- takeMVar v
+		case d of
+			RelayToPeer b -> do
+				r <- runner $ net $ relayToPeer (RelayToPeer b)
+				case r of
+					Left e -> return (Left e)
+					Right () -> loop
+			RelayDone exitcode -> do
+				_ <- runner $ net $ relayToPeer (RelayDone exitcode)
+				return (Right exitcode)
+			RelayFromPeer _ -> loop -- not handled here
+
+-- Takes input from the peer, and sends it to the relay process's stdin.
+-- Repeats until the peer tells it it's done or hangs up.
+relayFeeder :: RunProto IO -> MVar RelayData -> Handle -> IO ()
+relayFeeder runner v hin = loop
+  where
+	loop = do
+		mrd <- runner $ net relayFromPeer
+		case mrd of
+			Left _e ->
+				putMVar v (RelayDone (ExitFailure 1))
+			Right (RelayDone exitcode) ->
+				putMVar v (RelayDone exitcode)
+			Right (RelayFromPeer b) -> do
+				L.hPut hin b
+				hFlush hin
+				loop
+			Right (RelayToPeer _) -> loop -- not handled here
+
+-- Reads input from the Handle and puts it into the MVar for relaying to
+-- the peer. Continues until EOF on the Handle.
+relayReader :: MVar RelayData -> Handle -> IO ()
+relayReader v hout = loop
+  where
+	loop = do
+		bs <- getsome []
+		case bs of
+			[] -> return ()
+			_ -> do
+				putMVar v $ RelayToPeer (L.fromChunks bs)
+				loop
+	
+	-- Wait for the first available chunk. Then, without blocking,
+	-- try to get more chunks, in case a stream of chunks is being
+	-- written in close succession. 
+	--
+	-- On Windows, hGetNonBlocking is broken, so avoid using it there.
+	getsome [] = do
+		b <- B.hGetSome hout chunk
+		if B.null b
+			then return []
+#ifndef mingw32_HOST_OS
+			else getsome [b]
+#else
+			else return [b]
+#endif
+	getsome bs = do
+		b <- B.hGetNonBlocking hout chunk
+		if B.null b
+			then return (reverse bs)
+			else getsome (b:bs)
+	
+	chunk = 65536
diff --git a/P2P/Protocol.hs b/P2P/Protocol.hs
new file mode 100644
index 0000000000..5804bab086
--- /dev/null
+++ b/P2P/Protocol.hs
@@ -0,0 +1,623 @@
+{- P2P protocol
+ -
+ - See doc/design/p2p_protocol.mdwn
+ -
+ - Copyright 2016-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE DeriveFunctor, TemplateHaskell, FlexibleContexts #-}
+{-# LANGUAGE TypeSynonymInstances, FlexibleInstances, RankNTypes #-}
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module P2P.Protocol where
+
+import qualified Utility.SimpleProtocol as Proto
+import Types (Annex)
+import Types.Key
+import Types.UUID
+import Types.Transfer
+import Types.Remote (Verification(..))
+import Utility.Hash (IncrementalVerifier(..))
+import Utility.AuthToken
+import Utility.Applicative
+import Utility.PartialPrelude
+import Utility.Metered
+import Utility.FileSystemEncoding
+import Git.FilePath
+import Annex.ChangedRefs (ChangedRefs)
+
+import Control.Monad
+import Control.Monad.Free
+import Control.Monad.Free.TH
+import Control.Monad.Catch
+import System.Exit (ExitCode(..))
+import System.IO
+import qualified System.FilePath.ByteString as P
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Lazy as L
+import Data.Char
+import Control.Applicative
+import Prelude
+
+newtype Offset = Offset Integer
+	deriving (Show)
+
+newtype Len = Len Integer
+	deriving (Show)
+
+newtype ProtocolVersion = ProtocolVersion Integer
+	deriving (Show, Eq, Ord)
+
+defaultProtocolVersion :: ProtocolVersion
+defaultProtocolVersion = ProtocolVersion 0
+
+maxProtocolVersion :: ProtocolVersion
+maxProtocolVersion = ProtocolVersion 1
+
+newtype ProtoAssociatedFile = ProtoAssociatedFile AssociatedFile
+	deriving (Show)
+
+-- | Service as used by the connect message in gitremote-helpers(1)
+data Service = UploadPack | ReceivePack
+	deriving (Show)
+
+data Validity = Valid | Invalid
+	deriving (Show)
+
+-- | Messages in the protocol. The peer that makes the connection
+-- always initiates requests, and the other peer makes responses to them.
+data Message
+	= AUTH UUID AuthToken -- uuid of the peer that is authenticating
+	| AUTH_SUCCESS UUID -- uuid of the remote peer
+	| AUTH_FAILURE
+	| VERSION ProtocolVersion
+	| CONNECT Service
+	| CONNECTDONE ExitCode
+	| NOTIFYCHANGE
+	| CHANGED ChangedRefs
+	| CHECKPRESENT Key
+	| LOCKCONTENT Key
+	| UNLOCKCONTENT
+	| REMOVE Key
+	| GET Offset ProtoAssociatedFile Key
+	| PUT ProtoAssociatedFile Key
+	| PUT_FROM Offset
+	| ALREADY_HAVE
+	| SUCCESS
+	| FAILURE
+	| DATA Len -- followed by bytes of data
+	| VALIDITY Validity
+	| ERROR String
+	deriving (Show)
+
+instance Proto.Sendable Message where
+	formatMessage (AUTH uuid authtoken) = ["AUTH", Proto.serialize uuid, Proto.serialize authtoken]
+	formatMessage (AUTH_SUCCESS uuid) = ["AUTH-SUCCESS",  Proto.serialize uuid]
+	formatMessage AUTH_FAILURE = ["AUTH-FAILURE"]
+	formatMessage (VERSION v) = ["VERSION", Proto.serialize v]
+	formatMessage (CONNECT service) = ["CONNECT", Proto.serialize service]
+	formatMessage (CONNECTDONE exitcode) = ["CONNECTDONE", Proto.serialize exitcode]
+	formatMessage NOTIFYCHANGE = ["NOTIFYCHANGE"]
+	formatMessage (CHANGED refs) = ["CHANGED", Proto.serialize refs]
+	formatMessage (CHECKPRESENT key) = ["CHECKPRESENT", Proto.serialize key]
+	formatMessage (LOCKCONTENT key) = ["LOCKCONTENT", Proto.serialize key]
+	formatMessage UNLOCKCONTENT = ["UNLOCKCONTENT"]
+	formatMessage (REMOVE key) = ["REMOVE", Proto.serialize key]
+	formatMessage (GET offset af key) = ["GET", Proto.serialize offset, Proto.serialize af, Proto.serialize key]
+	formatMessage (PUT af key) = ["PUT", Proto.serialize af, Proto.serialize key]
+	formatMessage (PUT_FROM offset) = ["PUT-FROM", Proto.serialize offset]
+	formatMessage ALREADY_HAVE = ["ALREADY-HAVE"]
+	formatMessage SUCCESS = ["SUCCESS"]
+	formatMessage FAILURE = ["FAILURE"]
+	formatMessage (VALIDITY Valid) = ["VALID"]
+	formatMessage (VALIDITY Invalid) = ["INVALID"]
+	formatMessage (DATA len) = ["DATA", Proto.serialize len]
+	formatMessage (ERROR err) = ["ERROR", Proto.serialize err]
+
+instance Proto.Receivable Message where
+	parseCommand "AUTH" = Proto.parse2 AUTH
+	parseCommand "AUTH-SUCCESS" = Proto.parse1 AUTH_SUCCESS
+	parseCommand "AUTH-FAILURE" = Proto.parse0 AUTH_FAILURE
+	parseCommand "VERSION" = Proto.parse1 VERSION
+	parseCommand "CONNECT" = Proto.parse1 CONNECT
+	parseCommand "CONNECTDONE" = Proto.parse1 CONNECTDONE
+	parseCommand "NOTIFYCHANGE" = Proto.parse0 NOTIFYCHANGE
+	parseCommand "CHANGED" = Proto.parse1 CHANGED
+	parseCommand "CHECKPRESENT" = Proto.parse1 CHECKPRESENT
+	parseCommand "LOCKCONTENT" = Proto.parse1 LOCKCONTENT
+	parseCommand "UNLOCKCONTENT" = Proto.parse0 UNLOCKCONTENT
+	parseCommand "REMOVE" = Proto.parse1 REMOVE
+	parseCommand "GET" = Proto.parse3 GET
+	parseCommand "PUT" = Proto.parse2 PUT
+	parseCommand "PUT-FROM" = Proto.parse1 PUT_FROM
+	parseCommand "ALREADY-HAVE" = Proto.parse0 ALREADY_HAVE
+	parseCommand "SUCCESS" = Proto.parse0 SUCCESS
+	parseCommand "FAILURE" = Proto.parse0 FAILURE
+	parseCommand "DATA" = Proto.parse1 DATA
+	parseCommand "ERROR" = Proto.parse1 ERROR
+	parseCommand "VALID" = Proto.parse0 (VALIDITY Valid)
+	parseCommand "INVALID" = Proto.parse0 (VALIDITY Invalid)
+	parseCommand _ = Proto.parseFail
+
+instance Proto.Serializable ProtocolVersion where
+	serialize (ProtocolVersion n) = show n
+	deserialize = ProtocolVersion <$$> readish
+
+instance Proto.Serializable Offset where
+	serialize (Offset n) = show n
+	deserialize = Offset <$$> readish
+
+instance Proto.Serializable Len where
+	serialize (Len n) = show n
+	deserialize = Len <$$> readish
+
+instance Proto.Serializable Service where
+	serialize UploadPack = "git-upload-pack"
+	serialize ReceivePack = "git-receive-pack"
+	deserialize "git-upload-pack" = Just UploadPack
+	deserialize "git-receive-pack" = Just ReceivePack
+	deserialize _ = Nothing
+
+-- | Since ProtoAssociatedFile is not the last thing in a protocol line,
+-- its serialization cannot contain any whitespace. This is handled
+-- by replacing whitespace with '%' (and '%' with '%%')
+--
+-- When deserializing an AssociatedFile from a peer, it's sanitized,
+-- to avoid any unusual characters that might cause problems when it's
+-- displayed to the user.
+--
+-- These mungings are ok, because a ProtoAssociatedFile is only ever displayed
+-- to the user and does not need to match a file on disk.
+instance Proto.Serializable ProtoAssociatedFile where
+	serialize (ProtoAssociatedFile (AssociatedFile Nothing)) = ""
+	serialize (ProtoAssociatedFile (AssociatedFile (Just af))) = 
+		decodeBS $ toInternalGitPath $ encodeBS $ concatMap esc $ fromRawFilePath af
+	  where
+		esc '%' = "%%"
+		esc c 
+			| isSpace c = "%"
+			| otherwise = [c]
+	
+	deserialize s = case fromInternalGitPath $ toRawFilePath $ deesc [] s of
+		f
+			| B.null f -> Just $ ProtoAssociatedFile $ AssociatedFile Nothing
+			| P.isRelative f -> Just $ ProtoAssociatedFile $ 
+				AssociatedFile $ Just f
+			| otherwise -> Nothing
+	  where
+	  	deesc b [] = reverse b
+		deesc b ('%':'%':cs) = deesc ('%':b) cs
+		deesc b ('%':cs) = deesc ('_':b) cs
+		deesc b (c:cs)
+			| isControl c = deesc ('_':b) cs
+			| otherwise = deesc (c:b) cs
+
+-- | Free monad for the protocol, combining net communication,
+-- and local actions.
+data ProtoF c = Net (NetF c) | Local (LocalF c)
+	deriving (Functor)
+
+type Proto = Free ProtoF
+
+net :: Net a -> Proto a
+net = hoistFree Net
+
+local :: Local a -> Proto a
+local = hoistFree Local
+
+data NetF c
+	= SendMessage Message c
+	| ReceiveMessage (Maybe Message -> c)
+	| SendBytes Len L.ByteString MeterUpdate c
+	-- ^ Sends exactly Len bytes of data. (Any more or less will
+	-- confuse the receiver.)
+	| ReceiveBytes Len MeterUpdate (L.ByteString -> c)
+	-- ^ Lazily reads bytes from peer. Stops once Len are read,
+	-- or if connection is lost, and in either case returns the bytes
+	-- that were read. This allows resuming interrupted transfers.
+	| CheckAuthToken UUID AuthToken (Bool -> c)
+	| RelayService Service c
+	-- ^ Runs a service, relays its output to the peer, and data
+	-- from the peer to it.
+	| Relay RelayHandle RelayHandle (ExitCode -> c)
+	-- ^ Reads from the first RelayHandle, and sends the data to a
+	-- peer, while at the same time accepting input from the peer
+	-- which is sent the the second RelayHandle. Continues until 
+	-- the peer sends an ExitCode.
+	| SetProtocolVersion ProtocolVersion c
+	--- ^ Called when a new protocol version has been negotiated.
+	| GetProtocolVersion (ProtocolVersion -> c)
+	deriving (Functor)
+
+type Net = Free NetF
+
+newtype RelayHandle = RelayHandle Handle
+
+data LocalF c
+	= TmpContentSize Key (Len -> c)
+	-- ^ Gets size of the temp file where received content may have
+	-- been stored. If not present, returns 0.
+	| FileSize FilePath (Len -> c)
+	-- ^ Gets size of the content of a file. If not present, returns 0.
+	| ContentSize Key (Maybe Len -> c)
+	-- ^ Gets size of the content of a key, when the full content is
+	-- present.
+	| ReadContent Key AssociatedFile Offset (L.ByteString -> Proto Validity -> Proto Bool) (Bool -> c)
+	-- ^ Reads the content of a key and sends it to the callback.
+	-- Must run the callback, or terminate the protocol connection.
+	--
+	-- May send any amount of data, including L.empty if the content is
+	-- not available. The callback must deal with that.
+	--
+	-- And the content may change while it's being sent.
+	-- The callback is passed a validity check that it can run after
+	-- sending the content to detect when this happened.
+	| StoreContent Key AssociatedFile Offset Len (Proto L.ByteString) (Proto (Maybe Validity)) (Bool -> c)
+	-- ^ Stores content to the key's temp file starting at an offset.
+	-- Once the whole content of the key has been stored, moves the
+	-- temp file into place as the content of the key, and returns True.
+	--
+	-- Must consume the whole lazy ByteString, or if unable to do
+	-- so, terminate the protocol connection.
+	--
+	-- If the validity check is provided and fails, the content was
+	-- changed while it was being sent, so verification of the
+	-- received content should be forced.
+	--
+	-- Note: The ByteString may not contain the entire remaining content
+	-- of the key. Only once the temp file size == Len has the whole
+	-- content been transferred.
+	| StoreContentTo FilePath (Maybe IncrementalVerifier) Offset Len (Proto L.ByteString) (Proto (Maybe Validity)) ((Bool, Verification) -> c)
+	-- ^ Like StoreContent, but stores the content to a temp file.
+	| SetPresent Key UUID c
+	| CheckContentPresent Key (Bool -> c)
+	-- ^ Checks if the whole content of the key is locally present.
+	| RemoveContent Key (Bool -> c)
+	-- ^ If the content is not present, still succeeds.
+	-- May fail if not enough copies to safely drop, etc.
+	| TryLockContent Key (Bool -> Proto ()) c
+	-- ^ Try to lock the content of a key,  preventing it
+	-- from being deleted, while running the provided protocol
+	-- action. If unable to lock the content, or the content is not
+	-- present, runs the protocol action with False.
+	| WaitRefChange (ChangedRefs -> c)
+	-- ^ Waits for one or more git refs to change and returns them.a
+	| UpdateMeterTotalSize Meter TotalSize c
+	-- ^ Updates the total size of a Meter, for cases where the size is
+	-- not known until the data is being received.
+	| RunValidityCheck (Annex Validity) (Validity -> c)
+	-- ^ Runs a deferred validity check.
+	deriving (Functor)
+
+type Local = Free LocalF
+
+-- Generate sendMessage etc functions for all free monad constructors.
+$(makeFree ''NetF)
+$(makeFree ''LocalF)
+
+auth :: UUID -> AuthToken -> Proto () -> Proto (Maybe UUID)
+auth myuuid t a = do
+	net $ sendMessage (AUTH myuuid t)
+	postAuth a
+
+postAuth :: Proto () -> Proto (Maybe UUID)
+postAuth a = do
+	r <- net receiveMessage
+	case r of
+		Just (AUTH_SUCCESS theiruuid) -> do
+			a
+			return $ Just theiruuid
+		Just AUTH_FAILURE -> return Nothing
+		_ -> do
+			net $ sendMessage (ERROR "auth failed")
+			return Nothing
+
+negotiateProtocolVersion :: ProtocolVersion -> Proto ()
+negotiateProtocolVersion preferredversion = do
+	net $ sendMessage (VERSION preferredversion)
+	r <- net receiveMessage
+	case r of
+		Just (VERSION v) -> net $ setProtocolVersion v
+		-- Old server doesn't know about the VERSION command.
+		Just (ERROR _) -> return ()
+		_ -> net $ sendMessage (ERROR "expected VERSION")
+
+checkPresent :: Key -> Proto Bool
+checkPresent key = do
+	net $ sendMessage (CHECKPRESENT key)
+	checkSuccess
+
+{- Locks content to prevent it from being dropped, while running an action.
+ -
+ - Note that this only guarantees that the content is locked as long as the
+ - connection to the peer remains up. If the connection is unexpectededly
+ - dropped, the peer will then unlock the content.
+ -}
+lockContentWhile 
+	:: MonadMask m 
+	=> (forall r. r -> Proto r -> m r)
+	-> Key
+	-> (Bool -> m a)
+	-> m a
+lockContentWhile runproto key a = bracket setup cleanup a
+  where
+	setup = runproto False $ do
+		net $ sendMessage (LOCKCONTENT key)
+		checkSuccess
+	cleanup True = runproto () $ net $ sendMessage UNLOCKCONTENT
+	cleanup False = return ()
+
+remove :: Key -> Proto Bool
+remove key = do
+	net $ sendMessage (REMOVE key)
+	checkSuccess
+
+get :: FilePath -> Key -> Maybe IncrementalVerifier -> AssociatedFile -> Meter -> MeterUpdate -> Proto (Bool, Verification)
+get dest key iv af m p = 
+	receiveContent (Just m) p sizer storer $ \offset ->
+		GET offset (ProtoAssociatedFile af) key
+  where
+	sizer = fileSize dest
+	storer = storeContentTo dest iv
+
+put :: Key -> AssociatedFile -> MeterUpdate -> Proto Bool
+put key af p = do
+	net $ sendMessage (PUT (ProtoAssociatedFile af) key)
+	r <- net receiveMessage
+	case r of
+		Just (PUT_FROM offset) -> sendContent key af offset p
+		Just ALREADY_HAVE -> return True
+		_ -> do
+			net $ sendMessage (ERROR "expected PUT_FROM or ALREADY_HAVE")
+			return False
+
+data ServerHandler a
+	= ServerGot a
+	| ServerContinue
+	| ServerUnexpected
+
+-- Server loop, getting messages from the client and handling them
+serverLoop :: (Message -> Proto (ServerHandler a)) -> Proto (Maybe a)
+serverLoop a = do
+	mcmd <- net receiveMessage
+	case mcmd of
+		-- When the client sends ERROR to the server, the server
+		-- gives up, since it's not clear what state the client
+		-- is in, and so not possible to recover.
+		Just (ERROR _) -> return Nothing
+		-- When the client sends an unparsable message, the server
+		-- responds with an error message, and loops. This allows
+		-- expanding the protocol with new messages.
+		Nothing -> do
+			net $ sendMessage (ERROR "unknown command")
+			serverLoop a
+		Just cmd -> do
+			v <- a cmd
+			case v of
+				ServerGot r -> return (Just r)
+				ServerContinue -> serverLoop a
+				-- If the client sends an unexpected message,
+				-- the server will respond with ERROR, and
+				-- always continues processing messages.
+				--
+				-- Since the protocol is not versioned, this
+				-- is necessary to handle protocol changes
+				-- robustly, since the client can detect when
+				-- it's talking to a server that does not
+				-- support some new feature, and fall back.
+				ServerUnexpected -> do
+					net $ sendMessage (ERROR "unexpected command")
+					serverLoop a
+
+-- | Serve the protocol, with an unauthenticated peer. Once the peer
+-- successfully authenticates, returns their UUID.
+serveAuth :: UUID -> Proto (Maybe UUID)
+serveAuth myuuid = serverLoop handler
+  where
+	handler (AUTH theiruuid authtoken) = do
+		ok <- net $ checkAuthToken theiruuid authtoken
+		if ok
+			then do
+				net $ sendMessage (AUTH_SUCCESS myuuid)
+				return (ServerGot theiruuid)
+			else do
+				net $ sendMessage AUTH_FAILURE
+				return ServerContinue
+	handler _ = return ServerUnexpected
+
+data ServerMode
+	= ServeReadOnly
+	-- ^ Allow reading, but not writing.
+	| ServeAppendOnly
+	-- ^ Allow reading, and storing new objects, but not deleting objects.
+	| ServeReadWrite
+	-- ^ Full read and write access.
+	deriving (Eq, Ord)
+
+-- | Serve the protocol, with a peer that has authenticated.
+serveAuthed :: ServerMode -> UUID -> Proto ()
+serveAuthed servermode myuuid = void $ serverLoop handler
+  where
+	readonlyerror = net $ sendMessage (ERROR "this repository is read-only; write access denied")
+	appendonlyerror = net $ sendMessage (ERROR "this repository is append-only; removal denied")
+	handler (VERSION theirversion) = do
+		let v = min theirversion maxProtocolVersion
+		net $ setProtocolVersion v
+		net $ sendMessage (VERSION v)
+		return ServerContinue
+	handler (LOCKCONTENT key) = do
+		local $ tryLockContent key $ \locked -> do
+			sendSuccess locked
+			when locked $ do
+				r' <- net receiveMessage
+				case r' of
+					Just UNLOCKCONTENT -> return ()
+					_ -> net $ sendMessage (ERROR "expected UNLOCKCONTENT")
+		return ServerContinue
+	handler (CHECKPRESENT key) = do
+		sendSuccess =<< local (checkContentPresent key)
+		return ServerContinue
+	handler (REMOVE key) = case servermode of
+		ServeReadWrite -> do
+			sendSuccess =<< local (removeContent key)
+			return ServerContinue
+		ServeAppendOnly -> do
+			appendonlyerror
+			return ServerContinue
+		ServeReadOnly -> do
+			readonlyerror
+			return ServerContinue
+	handler (PUT (ProtoAssociatedFile af) key) = case servermode of
+		ServeReadWrite -> handleput af key
+		ServeAppendOnly -> handleput af key
+		ServeReadOnly -> do
+			readonlyerror
+			return ServerContinue
+	handler (GET offset (ProtoAssociatedFile af) key) = do
+		void $ sendContent key af offset nullMeterUpdate
+		-- setPresent not called because the peer may have
+		-- requested the data but not permanently stored it.
+		return ServerContinue
+	handler (CONNECT service) = do
+		let goahead = net $ relayService service
+		case (servermode, service) of
+			(ServeReadWrite, _) -> goahead
+			(ServeAppendOnly, UploadPack) -> goahead
+			-- git protocol could be used to overwrite
+			-- refs or something, so don't allow
+			(ServeAppendOnly, ReceivePack) -> readonlyerror
+			(ServeReadOnly, UploadPack) -> goahead
+			(ServeReadOnly, ReceivePack) -> readonlyerror
+		-- After connecting to git, there may be unconsumed data
+		-- from the git processes hanging around (even if they
+		-- exited successfully), so stop serving this connection.
+		return $ ServerGot ()
+	handler NOTIFYCHANGE = do
+		refs <- local waitRefChange
+		net $ sendMessage (CHANGED refs)
+		return ServerContinue
+	handler _ = return ServerUnexpected
+
+	handleput af key = do
+		have <- local $ checkContentPresent key
+		if have
+			then net $ sendMessage ALREADY_HAVE
+			else do
+				let sizer = tmpContentSize key
+				let storer = storeContent key af
+				v <- receiveContent Nothing nullMeterUpdate sizer storer PUT_FROM
+				when (observeBool v) $
+					local $ setPresent key myuuid
+		return ServerContinue
+
+sendContent :: Key -> AssociatedFile -> Offset -> MeterUpdate -> Proto Bool
+sendContent key af offset@(Offset n) p = go =<< local (contentSize key)
+  where
+	go (Just (Len totallen)) = do
+		let len = totallen - n
+		if len <= 0
+			then sender (Len 0) L.empty (return Valid)
+			else local $ readContent key af offset $
+				sender (Len len)
+	-- Content not available to send. Indicate this by sending
+	-- empty data and indlicate it's invalid.
+ 	go Nothing = sender (Len 0) L.empty (return Invalid)
+	sender len content validitycheck = do
+		let p' = offsetMeterUpdate p (toBytesProcessed n)
+		net $ sendMessage (DATA len)
+		net $ sendBytes len content p'
+		ver <- net getProtocolVersion
+		when (ver >= ProtocolVersion 1) $
+			net . sendMessage . VALIDITY =<< validitycheck
+		checkSuccess
+
+receiveContent
+	:: Observable t
+	=> Maybe Meter
+	-> MeterUpdate
+	-> Local Len
+	-> (Offset -> Len -> Proto L.ByteString -> Proto (Maybe Validity) -> Local t)
+	-> (Offset -> Message)
+	-> Proto t
+receiveContent mm p sizer storer mkmsg = do
+	Len n <- local sizer
+	let p' = offsetMeterUpdate p (toBytesProcessed n)
+	let offset = Offset n
+	net $ sendMessage (mkmsg offset)
+	r <- net receiveMessage
+	case r of
+		Just (DATA len@(Len l)) -> do
+			local $ case mm of
+				Nothing -> return ()
+				Just m -> updateMeterTotalSize m (TotalSize (n+l))
+			ver <- net getProtocolVersion
+			let validitycheck = if ver >= ProtocolVersion 1
+				then net receiveMessage >>= \case
+					Just (VALIDITY v) -> return (Just v)
+					_ -> do
+						net $ sendMessage (ERROR "expected VALID or INVALID")
+						return Nothing
+				else return Nothing
+			v <- local $ storer offset len
+				(net (receiveBytes len p'))
+				validitycheck
+			sendSuccess (observeBool v)
+			return v
+		_ -> do
+			net $ sendMessage (ERROR "expected DATA")
+			return observeFailure
+
+checkSuccess :: Proto Bool
+checkSuccess = do
+	ack <- net receiveMessage
+	case ack of
+		Just SUCCESS -> return True
+		Just FAILURE -> return False
+		_ -> do
+			net $ sendMessage (ERROR "expected SUCCESS or FAILURE")
+			return False
+
+sendSuccess :: Bool -> Proto ()
+sendSuccess True = net $ sendMessage SUCCESS
+sendSuccess False = net $ sendMessage FAILURE
+
+notifyChange :: Proto (Maybe ChangedRefs)
+notifyChange = do
+	net $ sendMessage NOTIFYCHANGE
+	ack <- net receiveMessage
+	case ack of
+		Just (CHANGED rs) -> return (Just rs)
+		_ -> do
+			net $ sendMessage (ERROR "expected CHANGED")
+			return Nothing
+
+connect :: Service -> Handle -> Handle -> Proto ExitCode
+connect service hin hout = do
+	net $ sendMessage (CONNECT service)
+	net $ relay (RelayHandle hin) (RelayHandle hout)
+
+data RelayData
+	= RelayToPeer L.ByteString
+	| RelayFromPeer L.ByteString
+	| RelayDone ExitCode
+	deriving (Show)
+
+relayFromPeer :: Net RelayData
+relayFromPeer = do
+	r <- receiveMessage
+	case r of
+		Just (CONNECTDONE exitcode) -> return $ RelayDone exitcode
+		Just (DATA len) -> RelayFromPeer <$> receiveBytes len nullMeterUpdate
+		_ -> do
+			sendMessage $ ERROR "expected DATA or CONNECTDONE"
+			return $ RelayDone $ ExitFailure 1
+
+relayToPeer :: RelayData -> Net ()
+relayToPeer (RelayDone exitcode) = sendMessage (CONNECTDONE exitcode)
+relayToPeer (RelayToPeer b) = do
+	let len = Len $ fromIntegral $ L.length b
+	sendMessage (DATA len)
+	sendBytes len b nullMeterUpdate
+relayToPeer (RelayFromPeer _) = return ()
diff --git a/README b/README
new file mode 100644
index 0000000000..8d9c559f0b
--- /dev/null
+++ b/README
@@ -0,0 +1,7 @@
+git-annex allows managing large files with git, without storing the file
+contents in git. It can sync, backup, and archive your data, offline
+and online. Checksums and encryption keep your data safe and secure. Bring
+the power and distributed nature of git to bear on your large files with
+git-annex.
+
+For documentation, see doc/ or <https://git-annex.branchable.com/>
diff --git a/Remote.hs b/Remote.hs
new file mode 100644
index 0000000000..dbbca32a5e
--- /dev/null
+++ b/Remote.hs
@@ -0,0 +1,447 @@
+{- git-annex remotes
+ -
+ - Copyright 2011-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Remote (
+	Remote,
+	uuid,
+	name,
+	action,
+	verifiedAction,
+	storeKey,
+	retrieveKeyFile,
+	retrieveKeyFileCheap,
+	retrievalSecurityPolicy,
+	removeKey,
+	hasKey,
+	hasKeyCheap,
+	whereisKey,
+	remoteFsck,
+
+	remoteTypes,
+	remoteList,
+	remoteList',
+	gitSyncableRemoteType,
+	remoteMap,
+	remoteMap',
+	uuidDescriptions,
+	addName,
+	byName,
+	byName',
+	byNameOrGroup,
+	byNameOnly,
+	byNameWithUUID,
+	byUUID,
+	byCost,
+	prettyPrintUUIDs,
+	prettyPrintUUIDsDescs,
+	prettyPrintUUIDsWith,
+	prettyListUUIDs,
+	prettyUUID,
+	remoteFromUUID,
+	remotesWithUUID,
+	remotesWithoutUUID,
+	keyLocations,
+	IncludeIgnored(..),
+	keyPossibilities,
+	remoteLocations,
+	nameToUUID,
+	nameToUUID',
+	showTriedRemotes,
+	listRemoteNames,
+	showLocations,
+	forceTrust,
+	logStatus,
+	checkAvailable,
+	claimingUrl,
+	claimingUrl',
+	isExportSupported,
+) where
+
+import Data.Ord
+import Data.String
+import qualified Data.Map as M
+import qualified Data.Vector as V
+
+import Annex.Common
+import Types.Remote
+import qualified Annex
+import Annex.UUID
+import Annex.Action
+import Logs.UUID
+import Logs.Trust
+import Logs.Location hiding (logStatus)
+import Logs.Remote
+import Logs.Web
+import Remote.List
+import Remote.List.Util
+import Config
+import Config.DynamicConfig
+import Git.Types (RemoteName, ConfigKey(..), fromConfigValue)
+import Utility.Aeson
+
+{- Map from UUIDs of Remotes to a calculated value. -}
+remoteMap :: (Remote -> v) -> Annex (M.Map UUID v)
+remoteMap mkv = remoteMap' mkv (pure . mkk)
+  where
+	mkk r = case uuid r of
+		NoUUID -> Nothing
+		u -> Just u
+
+remoteMap' :: Ord k => (Remote -> v) -> (Remote -> Annex (Maybe k)) -> Annex (M.Map k v)
+remoteMap' mkv mkk = M.fromList . catMaybes <$> (mapM mk =<< remoteList)
+  where
+	mk r = mkk r >>= return . \case
+		Nothing -> Nothing
+		Just k -> Just (k, mkv r)
+
+{- Map of UUIDs of repositories and their descriptions.
+ - The names of Remotes are added to supplement any description that has
+ - been set for a repository.  -}
+uuidDescriptions :: Annex UUIDDescMap
+uuidDescriptions = M.unionWith addName
+	<$> uuidDescMap
+	<*> remoteMap (UUIDDesc . encodeBS . name)
+
+{- Add a remote name to its description. -}
+addName :: (IsString t, Monoid t, Eq t) => t -> t -> t
+addName desc n
+	| desc == n || desc == mempty = "[" <> n <> "]"
+	| otherwise = desc <> " [" <> n <> "]"
+
+byUUID :: UUID -> Annex (Maybe Remote)
+byUUID u = headMaybe . filter matching <$> remoteList
+  where
+	matching r = uuid r == u
+
+{- When a name is specified, looks up the remote matching that name.
+ - (Or it can be a UUID.)
+ -
+ - Throws an error if a name is specified and no matching remote can be
+ - found.
+ -}
+byName :: Maybe RemoteName -> Annex (Maybe Remote)
+byName Nothing = return Nothing
+byName (Just n) = either giveup Just <$> byName' n
+
+{- Like byName, but the remote must have a configured UUID. -}
+byNameWithUUID :: Maybe RemoteName -> Annex (Maybe Remote)
+byNameWithUUID = checkuuid <=< byName
+  where
+	checkuuid Nothing = return Nothing
+	checkuuid (Just r)
+		| uuid r == NoUUID = do
+			repo <- getRepo r
+			ifM (liftIO $ getDynamicConfig $ remoteAnnexIgnore (gitconfig r))
+				( giveup $ noRemoteUUIDMsg r ++
+					" (" ++ show (remoteAnnexConfig repo "ignore") ++
+					" is set)"
+				, giveup $ noRemoteUUIDMsg r
+				)
+		| otherwise = return $ Just r
+
+byName' :: RemoteName -> Annex (Either String Remote)
+byName' "" = return $ Left "no repository name specified"
+byName' n = go . filter matching <$> remoteList
+  where
+	go [] = Left $ "there is no available git remote named \"" ++ n ++ "\""
+	go (match:_) = Right match
+	matching r = n == name r || toUUID n == uuid r
+
+{- Finds the remote or remote group matching the name. -}
+byNameOrGroup :: RemoteName -> Annex [Remote]
+byNameOrGroup n = go =<< getConfigMaybe (ConfigKey ("remotes." <> encodeBS n))
+  where
+	go (Just l) = catMaybes
+		<$> mapM (byName . Just) (splitc ' ' (fromConfigValue l))
+	go Nothing = maybeToList
+		<$> byName (Just n)
+
+{- Only matches remote name, not UUID -}
+byNameOnly :: RemoteName -> Annex (Maybe Remote)
+byNameOnly n = headMaybe . filter matching <$> remoteList
+  where
+	matching r = n == name r
+
+noRemoteUUIDMsg :: Remote -> String
+noRemoteUUIDMsg r = "cannot determine uuid for " ++ name r ++ " (perhaps you need to run \"git annex sync\"?)"
+
+{- Looks up a remote by name (or by UUID, or even by description),
+ - and returns its UUID. Finds even repositories that are not
+ - configured in .git/config. -}
+nameToUUID :: RemoteName -> Annex UUID
+nameToUUID n = nameToUUID' n >>= \case
+	([u], _) -> return u
+	(_, msg) -> giveup msg
+
+nameToUUID' :: RemoteName -> Annex ([UUID], String)
+nameToUUID' n
+	| n == "." = currentrepo
+	| n == "here" = currentrepo
+	| otherwise = byName' n >>= go
+  where
+	currentrepo = mkone <$> getUUID
+
+	go (Right r) = return $ case uuid r of
+		NoUUID -> ([], noRemoteUUIDMsg r)
+		u -> mkone u
+	go (Left e) = do
+		m <- uuidDescMap
+		let descn = UUIDDesc (encodeBS n)
+		return $ case M.keys (M.filter (== descn) m) of
+			[] -> 
+				let u = toUUID n
+				in case M.keys (M.filterWithKey (\k _ -> k == u) m) of
+					[] -> ([], e)
+					_ -> ([u], e)
+			us -> (us, "found multiple repositories with that description (use the uuid instead to disambiguate)")
+
+	mkone u = ([u], "found a remote")
+
+{- Pretty-prints a list of UUIDs of remotes, with their descriptions,
+ - for human display.
+ -
+ - When JSON is enabled, also outputs a machine-readable description
+ - of the UUIDs. -}
+prettyPrintUUIDs :: String -> [UUID] -> Annex String
+prettyPrintUUIDs header uuids = do
+	descm <- uuidDescriptions
+	prettyPrintUUIDsDescs header descm uuids
+
+prettyPrintUUIDsDescs :: String -> UUIDDescMap -> [UUID] -> Annex String
+prettyPrintUUIDsDescs header descm uuids =
+	prettyPrintUUIDsWith Nothing header descm
+		(const Nothing)
+		(zip uuids (repeat (Nothing :: Maybe String)))
+
+{- An optional field can be included in the list of UUIDs. -}
+prettyPrintUUIDsWith
+	:: ToJSON' v
+	=> Maybe String 
+	-> String 
+	-> UUIDDescMap
+	-> (v -> Maybe String)
+	-> [(UUID, Maybe v)] 
+	-> Annex String
+prettyPrintUUIDsWith optfield header descm showval uuidvals = do
+	hereu <- getUUID
+	maybeShowJSON $ JSONChunk [(header, V.fromList $ map (jsonify hereu) uuidvals)]
+	return $ unwords $ map (\u -> "\t" ++ prettify hereu u ++ "\n") uuidvals
+  where
+	finddescription u = fromUUIDDesc $ M.findWithDefault mempty u descm
+	prettify hereu (u, optval)
+		| not (null d) = addoptval $ fromUUID u ++ " -- " ++ d
+		| otherwise = addoptval $ fromUUID u
+	  where
+		ishere = hereu == u
+		n = finddescription u
+		d
+			| null n && ishere = "here"
+			| ishere = addName n "here"
+			| otherwise = n
+		addoptval s = case showval =<< optval of
+			Nothing -> s
+			Just val -> val ++ ": " ++ s
+	jsonify hereu (u, optval) = object $ catMaybes
+		[ Just ("uuid", toJSON' (fromUUID u :: String))
+		, Just ("description", toJSON' $ finddescription u)
+		, Just ("here", toJSON' $ hereu == u)
+		, case (optfield, optval) of
+			(Just field, Just val) -> Just
+				(textKey (packString field), toJSON' val)
+			_ -> Nothing
+		]
+
+{- List of remote names and/or descriptions, for human display.  -}
+prettyListUUIDs :: [UUID] -> Annex [String]
+prettyListUUIDs uuids = do
+	hereu <- getUUID
+	m <- uuidDescriptions
+	return $ map (fromUUIDDesc . prettify m hereu) uuids
+  where
+	finddescription m u = M.findWithDefault mempty u m
+	prettify m hereu u
+		| u == hereu = addName n "here"
+		| otherwise = n
+	  where
+		n = finddescription m u
+
+{- Nice display of a remote's name and/or description. -}
+prettyUUID :: UUID -> Annex String
+prettyUUID u = concat <$> prettyListUUIDs [u]
+
+{- Gets the remote associated with a UUID. -}
+remoteFromUUID :: UUID -> Annex (Maybe Remote)
+remoteFromUUID u = ifM ((==) u <$> getUUID)
+	( return Nothing
+	, maybe tryharder (return . Just) =<< findinmap
+	)
+  where
+	findinmap = M.lookup u <$> remoteMap id
+	{- Re-read remote list in case a new remote has popped up. -}
+	tryharder = do
+		remotesChanged
+		findinmap
+
+{- Filters a list of remotes to ones that have the listed uuids. -}
+remotesWithUUID :: [Remote] -> [UUID] -> [Remote]
+remotesWithUUID rs us = filter (\r -> uuid r `elem` us) rs
+
+{- Filters a list of remotes to ones that do not have the listed uuids. -}
+remotesWithoutUUID :: [Remote] -> [UUID] -> [Remote]
+remotesWithoutUUID rs us = filter (\r -> uuid r `notElem` us) rs
+
+{- List of repository UUIDs that the location log indicates may have a key.
+ - Dead repositories are excluded. -}
+keyLocations :: Key -> Annex [UUID]
+keyLocations key = trustExclude DeadTrusted =<< loggedLocations key
+
+{- Whether to include remotes that have annex-ignore set. -}
+newtype IncludeIgnored = IncludeIgnored Bool
+
+{- Cost ordered lists of remotes that the location log indicates
+ - may have a key.
+ -
+ - Also includes remotes with remoteAnnexSpeculatePresent set.
+ -}
+keyPossibilities :: IncludeIgnored -> Key -> Annex [Remote]
+keyPossibilities ii key = do
+	u <- getUUID
+	-- uuids of all remotes that are recorded to have the key
+	locations <- filter (/= u) <$> keyLocations key
+	speclocations <- map uuid
+		. filter (remoteAnnexSpeculatePresent . gitconfig)
+		<$> remoteList
+	-- there are unlikely to be many speclocations, so building a Set
+	-- is not worth the expense
+	let locations' = speclocations ++ filter (`notElem` speclocations) locations
+	fst <$> remoteLocations ii locations' []
+
+{- Given a list of locations of a key, and a list of all
+ - trusted repositories, generates a cost-ordered list of
+ - remotes that contain the key, and a list of trusted locations of the key.
+ -}
+remoteLocations :: IncludeIgnored -> [UUID] -> [UUID] -> Annex ([Remote], [UUID])
+remoteLocations (IncludeIgnored ii) locations trusted = do
+	let validtrustedlocations = nub locations `intersect` trusted
+
+	-- remotes that match uuids that have the key
+	allremotes <- remoteList 
+		>>= if not ii
+			then filterM (not <$$> liftIO . getDynamicConfig . remoteAnnexIgnore . gitconfig)
+			else return
+	let validremotes = remotesWithUUID allremotes locations
+
+	return (sortBy (comparing cost) validremotes, validtrustedlocations)
+
+{- Displays known locations of a key and helps the user take action
+ - to make them accessible. -}
+showLocations :: Bool -> Key -> [UUID] -> String -> Annex ()
+showLocations separateuntrusted key exclude nolocmsg = do
+	u <- getUUID
+	remotes <- remoteList
+	uuids <- keyLocations key
+	untrusteduuids <- if separateuntrusted
+		then trustGet UnTrusted
+		else pure []
+	let uuidswanted = filteruuids uuids (u:exclude++untrusteduuids)
+	let uuidsskipped = filteruuids uuids (u:exclude++uuidswanted)
+	let remoteuuids = map uuid remotes
+	let isremoteuuid x = elem x remoteuuids
+	let (remotesmakeavailable, uuidsothers) = 
+		partition isremoteuuid uuidswanted
+	isspecialremote <- flip M.member <$> remoteConfigMap
+	let (enablespecialremotes, addgitremotes) = 
+		partition isspecialremote uuidsothers
+	
+	-- Add "wanted" field to the JSON. While it's since been split
+	-- up more, this avoids breaking any JSON parsers that expect it.
+	ifM jsonOutputEnabled
+		( void $ prettyPrintUUIDs "wanted" uuidswanted
+		, do
+			ppremotesmakeavailable <- pp "remotes" remotesmakeavailable
+				"Try making some of these remotes available"
+			ppenablespecialremotes <- pp "enableremote" enablespecialremotes
+				"Maybe enable some of these special remotes (git annex enableremote ...)"
+			ppaddgitremotes <- pp "repos" addgitremotes
+				"Maybe add some of these git remotes (git remote add ...)"
+			ppuuidsskipped <- pp "skipped" uuidsskipped
+				"Also these untrusted repositories may contain the file"
+			showLongNote $ UnquotedString $ case ppremotesmakeavailable ++ ppenablespecialremotes ++ ppaddgitremotes ++ ppuuidsskipped of
+				[] -> nolocmsg
+				s -> s
+		)
+	ignored <- filterM (liftIO . getDynamicConfig . remoteAnnexIgnore . gitconfig) remotes
+	unless (null ignored) $
+		showLongNote $ UnquotedString $ "(Note that these git remotes have annex-ignore set: " ++ unwords (map name ignored) ++ ")"
+  where
+	filteruuids l x = filter (`notElem` x) l
+
+	pp jh l h = addheader h <$> prettyPrintUUIDs jh l
+
+	addheader _ [] = []
+	addheader h l = h ++ ":\n" ++ l
+
+showTriedRemotes :: [Remote] -> Annex ()
+showTriedRemotes [] = noop
+showTriedRemotes remotes =
+	showLongNote $ UnquotedString $ "Unable to access these remotes: "
+		++ listRemoteNames remotes
+
+listRemoteNames :: [Remote] -> String
+listRemoteNames remotes = intercalate ", " (map name remotes)
+
+forceTrust :: TrustLevel -> String -> Annex ()
+forceTrust level remotename = do
+	u <- nameToUUID remotename
+	if level >= Trusted
+		then toplevelWarning False "Ignoring request to trust repository, because that can lead to data loss."
+		else Annex.changeState $ \s ->
+			s { Annex.forcetrust = M.insert u level (Annex.forcetrust s) }
+
+{- Used to log a change in a remote's having a key. The change is logged
+ - in the local repo, not on the remote. The process of transferring the
+ - key to the remote, or removing the key from it *may* log the change
+ - on the remote, but this cannot always be relied on. -}
+logStatus :: Remote -> Key -> LogStatus -> Annex ()
+logStatus remote key = logChange key (uuid remote)
+
+{- Orders remotes by cost, with ones with the lowest cost grouped together. -}
+byCost :: [Remote] -> [[Remote]]
+byCost = map snd . sortBy (comparing fst) . M.toList . costmap
+  where
+	costmap = M.fromListWith (++) . map costpair
+	costpair r = (cost r, [r])
+
+checkAvailable :: Bool -> Remote -> Annex Bool
+checkAvailable assumenetworkavailable r = tryNonAsync (availability r) >>= \case
+	Left _e -> return assumenetworkavailable
+	Right LocallyAvailable -> return True
+	Right GloballyAvailable -> return assumenetworkavailable
+	Right Unavailable -> return False
+
+hasKey :: Remote -> Key -> Annex (Either String Bool)
+hasKey r k = either (Left  . show) Right <$> tryNonAsync (checkPresent r k)
+
+hasKeyCheap :: Remote -> Bool
+hasKeyCheap = checkPresentCheap
+
+{- The web special remote claims urls by default. -}
+claimingUrl :: URLString -> Annex Remote
+claimingUrl = claimingUrl' (const True)
+
+{- The web special remote still claims urls if there is no
+ - other remote that does, even when the remotefilter does
+ - not include it. -}
+claimingUrl' :: (Remote -> Bool) -> URLString -> Annex Remote
+claimingUrl' remotefilter url = do
+	rs <- remoteList
+	let web = Prelude.head $ filter (\r -> uuid r == webUUID) rs
+	fromMaybe web <$> firstM checkclaim (filter remotefilter rs)
+  where
+	checkclaim = maybe (pure False) (`id` url) . claimUrl
diff --git a/Remote/Adb.hs b/Remote/Adb.hs
new file mode 100644
index 0000000000..9848833147
--- /dev/null
+++ b/Remote/Adb.hs
@@ -0,0 +1,496 @@
+{- Remote on Android device accessed using adb.
+ -
+ - Copyright 2018-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Remote.Adb (remote) where
+
+import Annex.Common
+import Types.Remote
+import Types.Creds
+import Types.Export
+import Types.Import
+import qualified Git
+import Config
+import Config.Cost
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import Annex.UUID
+import Utility.Metered
+import Types.ProposedAccepted
+import Annex.SpecialRemote.Config
+import Annex.Verify
+
+import qualified Data.Map as M
+import qualified System.FilePath.Posix as Posix
+
+-- | Each Android device has a serial number.
+newtype AndroidSerial = AndroidSerial { fromAndroidSerial :: String }
+	deriving (Show, Eq)
+
+-- | A location on an Android device. 
+newtype AndroidPath = AndroidPath { fromAndroidPath :: FilePath }
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "adb"
+	, enumerate = const (findSpecialRemotes "adb")
+	, generate = gen
+	, configParser = mkRemoteConfigParser
+		[ optionalStringParser androiddirectoryField
+			(FieldDesc "location on the Android device where the files are stored")
+		, optionalStringParser androidserialField
+			(FieldDesc "sometimes needed to specify which Android device to use")
+		, yesNoParser ignorefinderrorField (Just False)
+			(FieldDesc "ignore adb find errors")
+		, yesNoParser oldandroidField (Just False)
+			(FieldDesc "support old versions of android (slower)")
+		]
+	, setup = adbSetup
+	, exportSupported = exportIsSupported
+	, importSupported = importIsSupported
+	, thirdPartyPopulated = False
+	}
+
+androiddirectoryField :: RemoteConfigField
+androiddirectoryField = Accepted "androiddirectory"
+
+androidserialField :: RemoteConfigField
+androidserialField = Accepted "androidserial"
+
+ignorefinderrorField :: RemoteConfigField
+ignorefinderrorField = Accepted "ignorefinderror"
+
+oldandroidField :: RemoteConfigField
+oldandroidField = Accepted "oldandroid"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	-- adb operates over USB or wifi, so is not as cheap
+	-- as local, but not too expensive
+	cst <- remoteCost gc c semiExpensiveRemoteCost
+	let this = Remote
+		{ uuid = u
+		, cost = cst
+		, name = Git.repoDescribe r
+		, storeKey = storeKeyDummy
+		, retrieveKeyFile = retrieveKeyFileDummy
+		, retrieveKeyFileCheap = Nothing
+		, retrievalSecurityPolicy = RetrievalAllKeysSecure
+		, removeKey = removeKeyDummy
+		, lockContent = Nothing
+		, checkPresent = checkPresentDummy
+		, checkPresentCheap = False
+		, exportActions = ExportActions
+			{ storeExport = storeExportM serial adir
+			, retrieveExport = retrieveExportM serial adir
+			, removeExport = removeExportM serial adir
+			, versionedExport = False
+			, checkPresentExport = checkPresentExportM serial adir
+			, removeExportDirectory = Just $ removeExportDirectoryM serial adir
+			, renameExport = Just $ renameExportM serial adir
+			}
+		, importActions = ImportActions
+			{ listImportableContents = listImportableContentsM serial adir c
+			, importKey = Nothing
+			, retrieveExportWithContentIdentifier = retrieveExportWithContentIdentifierM serial adir
+			, storeExportWithContentIdentifier = storeExportWithContentIdentifierM serial adir
+			, removeExportWithContentIdentifier = removeExportWithContentIdentifierM serial adir
+			, removeExportDirectoryWhenEmpty = Nothing
+			, checkPresentExportWithContentIdentifier = checkPresentExportWithContentIdentifierM serial adir
+			}
+		, whereisKey = Nothing
+		, remoteFsck = Nothing
+		, repairRepo = Nothing
+		, config = c
+		, getRepo = return r
+		, gitconfig = gc
+		, localpath = Nothing
+		, remotetype = remote
+		, availability = pure LocallyAvailable
+		, readonly = False
+		, appendonly = False
+		, untrustworthy = False
+		, mkUnavailable = return Nothing
+		, getInfo = return
+			[ ("androidserial", fromAndroidSerial serial)
+			, ("androiddirectory", fromAndroidPath adir)
+			]
+		, claimUrl = Nothing
+		, checkUrl = Nothing
+		, remoteStateHandle = rs
+		}
+	return $ Just $ specialRemote c
+		(store serial adir)
+		(retrieve serial adir)
+		(remove serial adir)
+		(checkKey serial adir)
+		this
+  where
+	adir = maybe (giveup "missing androiddirectory") AndroidPath
+		(remoteAnnexAndroidDirectory gc)
+	serial = maybe (giveup "missing androidserial") AndroidSerial
+		(remoteAnnexAndroidSerial gc)
+
+adbSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+adbSetup _ mu _ c gc = do
+	u <- maybe (liftIO genUUID) return mu
+
+	-- verify configuration
+	adir <- maybe
+		(giveup "Specify androiddirectory=")
+		(pure . AndroidPath . fromProposedAccepted)
+		(M.lookup androiddirectoryField c)
+	serial <- getserial =<< enumerateAdbConnected
+	let c' = M.insert androidserialField (Proposed (fromAndroidSerial serial)) c
+
+	(c'', _encsetup) <- encryptionSetup c' gc
+
+	ok <- adbShellBool serial
+		[Param "mkdir", Param "-p", File (fromAndroidPath adir)]
+	unless ok $
+		giveup "Creating directory on Android device failed."
+
+	gitConfigSpecialRemote u c''
+		[ ("adb", "true")
+		, ("androiddirectory", fromAndroidPath adir)
+		, ("androidserial", fromAndroidSerial serial)
+		]
+
+	return (c'', u)
+  where
+	getserial [] = giveup "adb does not list any connected android devices. Plug in an Android device, or configure adb, and try again.."
+	getserial l = case fromProposedAccepted <$> M.lookup androidserialField c of
+		Nothing -> case l of
+			(s:[]) -> return s
+			_ -> giveup $ unlines $
+				"There are multiple connected android devices, specify which to use with androidserial="
+				: map fromAndroidSerial l
+		Just cs
+			| AndroidSerial cs `elem` l -> return (AndroidSerial cs)
+			| otherwise -> giveup $ "The device with androidserial=" ++ cs ++ " is not connected."
+
+store :: AndroidSerial -> AndroidPath -> Storer
+store serial adir = fileStorer $ \k src _p -> 
+	let dest = androidLocation adir k
+	in unlessM (store' serial dest src) $
+		giveup "adb failed"
+
+store' :: AndroidSerial -> AndroidPath -> FilePath -> Annex Bool
+store' serial dest src = checkAdbInPath False $ do
+	let destdir = takeDirectory $ fromAndroidPath dest
+	void $ adbShell serial [Param "mkdir", Param "-p", File destdir]
+	showOutput -- make way for adb push output
+	liftIO $ boolSystem "adb" $ mkAdbCommand serial
+		[Param "push", File src, File (fromAndroidPath dest)]
+
+retrieve :: AndroidSerial -> AndroidPath -> Retriever
+retrieve serial adir = fileRetriever $ \dest k _p ->
+	let src = androidLocation adir k
+	in retrieve' serial src (fromRawFilePath dest)
+
+retrieve' :: AndroidSerial -> AndroidPath -> FilePath -> Annex ()
+retrieve' serial src dest =
+	unlessM go $
+		giveup "adb pull failed"
+  where
+	go = checkAdbInPath False $ do
+		showOutput -- make way for adb pull output
+		liftIO $ boolSystem "adb" $ mkAdbCommand serial
+			[ Param "pull"
+			, Param "-a"
+			, File $ fromAndroidPath src
+			, File dest
+			]
+
+remove :: AndroidSerial -> AndroidPath -> Remover
+remove serial adir k =
+	unlessM (remove' serial (androidLocation adir k)) $
+		giveup "adb failed"
+
+remove' :: AndroidSerial -> AndroidPath -> Annex Bool
+remove' serial aloc = adbShellBool serial
+	[Param "rm", Param "-f", File (fromAndroidPath aloc)]
+
+checkKey :: AndroidSerial -> AndroidPath -> CheckPresent
+checkKey serial adir k = checkKey' serial (androidLocation adir k)
+
+checkKey' :: AndroidSerial -> AndroidPath -> Annex Bool
+checkKey' serial aloc = do
+	out <- adbShellRaw serial $ unwords
+		[ "if test -e ", shellEscape (fromAndroidPath aloc)
+		, "; then echo y"
+		, "; else echo n"
+		, "; fi"
+		]
+	case out of
+		Just ["y"] -> return True
+		Just ["n"] -> return False
+		_ -> giveup "unable to access Android device"
+
+androidLocation :: AndroidPath -> Key -> AndroidPath
+androidLocation adir k = AndroidPath $
+	fromAndroidPath (androidHashDir adir k) ++ serializeKey k
+
+androidHashDir :: AndroidPath -> Key -> AndroidPath
+androidHashDir adir k = AndroidPath $ 
+	fromAndroidPath adir ++ "/" ++ hdir
+  where
+	hdir = replace [pathSeparator] "/" (fromRawFilePath (hashDirLower def k))
+
+storeExportM :: AndroidSerial -> AndroidPath -> FilePath -> Key -> ExportLocation -> MeterUpdate -> Annex ()
+storeExportM serial adir src _k loc _p = 
+	unlessM (store' serial dest src) $
+		giveup "adb failed"
+  where
+	dest = androidExportLocation adir loc
+
+retrieveExportM :: AndroidSerial -> AndroidPath -> Key -> ExportLocation -> FilePath -> MeterUpdate -> Annex Verification
+retrieveExportM serial adir k loc dest _p = 
+	verifyKeyContentIncrementally AlwaysVerify k $ \iv ->
+		tailVerify iv (toRawFilePath dest) $
+			retrieve' serial src dest
+  where
+	src = androidExportLocation adir loc
+
+removeExportM :: AndroidSerial -> AndroidPath -> Key -> ExportLocation -> Annex ()
+removeExportM serial adir _k loc =
+	unlessM (remove' serial aloc) $
+		giveup "adb failed"
+  where
+	aloc = androidExportLocation adir loc
+
+removeExportDirectoryM :: AndroidSerial -> AndroidPath -> ExportDirectory -> Annex ()
+removeExportDirectoryM serial abase dir =
+	unlessM go $
+		giveup "adb failed"
+  where
+	go = adbShellBool serial [Param "rm", Param "-rf", File (fromAndroidPath adir)]
+	adir = androidExportLocation abase (mkExportLocation (fromExportDirectory dir))
+
+checkPresentExportM :: AndroidSerial -> AndroidPath -> Key -> ExportLocation -> Annex Bool
+checkPresentExportM serial adir _k loc = checkKey' serial aloc
+  where
+	aloc = androidExportLocation adir loc
+
+renameExportM :: AndroidSerial -> AndroidPath -> Key -> ExportLocation -> ExportLocation -> Annex (Maybe ())
+renameExportM serial adir _k old new = do
+	unlessM (adbShellBool serial ps) $
+		giveup "adb failed"
+	return (Just ())
+  where
+	oldloc = fromAndroidPath $ androidExportLocation adir old
+	newloc = fromAndroidPath $ androidExportLocation adir new
+	ps =
+		[ Param "mv"
+		, Param "-f"
+		, File oldloc
+		, File newloc
+		]
+
+listImportableContentsM :: AndroidSerial -> AndroidPath -> ParsedRemoteConfig -> Annex (Maybe (ImportableContentsChunkable Annex (ContentIdentifier, ByteSize)))
+listImportableContentsM serial adir c = adbfind >>= \case
+	Just ls -> return $ Just $ ImportableContentsComplete $ 
+		ImportableContents (mapMaybe mk ls) []
+	Nothing -> giveup "adb find failed"
+  where
+	adbfind = adbShell' serial findparams
+		(\s -> if oldandroid
+			then s ++ ignorefinderrorsh
+			else concat
+				[ "set -o pipefail; "
+				, s
+				, "| xargs -0 stat -c " ++ shellEscape statformat ++ " --"
+				, ignorefinderrorsh
+				]
+		)
+	
+	findparams =
+		[ Param "find"
+		-- trailing slash is needed, or android's find command
+		-- won't recurse into the directory
+		, File $ fromAndroidPath adir ++ "/"
+		, Param "-type", Param "f"
+		] ++ if oldandroid
+			then 
+				[ Param "-exec"
+				, Param "stat"
+				, Param "-c"
+				, Param statformat
+				, Param "{}"
+				, Param ";"
+				]
+			else 
+				[ Param "-printf"
+				, Param "%p\\0"
+				]
+
+	ignorefinderror = fromMaybe False (getRemoteConfigValue ignorefinderrorField c)
+	oldandroid = fromMaybe False (getRemoteConfigValue oldandroidField c)
+
+	statformat = adbStatFormat ++ "\t%n"
+
+	ignorefinderrorsh = if ignorefinderror then " || true" else ""
+
+	mk ('S':'T':'\t':l) =
+		let (stat, fn) = separate (== '\t') l
+		    sz = fromMaybe 0 (readish (takeWhile (/= ' ') stat))
+		    cid = ContentIdentifier (encodeBS stat)
+		    loc = mkImportLocation $ toRawFilePath $ 
+		    	Posix.makeRelative (fromAndroidPath adir) fn
+		in Just (loc, (cid, sz))
+	mk _ = Nothing
+
+-- This does not guard against every possible race. As long as the adb
+-- connection is resonably fast, it's probably as good as
+-- git's handling of similar situations with files being modified while
+-- it's updating the working tree for a merge.
+retrieveExportWithContentIdentifierM :: AndroidSerial -> AndroidPath -> ExportLocation -> [ContentIdentifier] -> FilePath -> Either Key (Annex Key) -> MeterUpdate -> Annex (Key, Verification)
+retrieveExportWithContentIdentifierM serial adir loc cids dest gk _p = do
+	case gk of
+		Right mkkey -> do
+			go
+			k <- mkkey
+			return (k, UnVerified)
+		Left k -> do
+			v <- verifyKeyContentIncrementally DefaultVerify k
+				(\iv -> tailVerify iv (toRawFilePath dest) go)
+			return (k, v)
+  where
+	go = do
+		retrieve' serial src dest
+		getExportContentIdentifier serial adir loc >>= \case
+			Right (Just currcid)
+				| any (currcid ==) cids -> return ()
+			_ -> giveup "the file on the android device has changed"
+	src = androidExportLocation adir loc
+
+storeExportWithContentIdentifierM :: AndroidSerial -> AndroidPath -> FilePath -> Key -> ExportLocation -> [ContentIdentifier] -> MeterUpdate -> Annex ContentIdentifier
+storeExportWithContentIdentifierM serial adir src _k loc overwritablecids _p =
+	ifM checkcanoverwrite
+		( ifM (store' serial dest src)
+			( getExportContentIdentifier serial adir loc >>= \case
+				Right (Just cid) -> return cid
+				Right Nothing -> giveup "adb failed to store file"
+				Left _ -> giveup "unable to get content identifier for file stored by adb"
+			, giveup "adb failed to store file"
+			)
+		, giveup "unsafe to overwrite file"
+		)
+  where
+	dest = androidExportLocation adir loc
+	checkcanoverwrite =
+		getExportContentIdentifier serial adir loc >>= return . \case
+			Right (Just cid) | cid `elem` overwritablecids -> True
+			Right Nothing -> True
+			_ -> False
+
+removeExportWithContentIdentifierM :: AndroidSerial -> AndroidPath -> Key -> ExportLocation -> [ContentIdentifier] -> Annex ()
+removeExportWithContentIdentifierM serial adir k loc removeablecids =
+	getExportContentIdentifier serial adir loc >>= \case
+		Right Nothing -> return ()
+		Right (Just cid)
+			| cid `elem` removeablecids ->
+				removeExportM serial adir k loc
+			| otherwise -> giveup "file on Android device is modified, cannot remove"
+		Left _ -> giveup "unable to access Android device"
+
+checkPresentExportWithContentIdentifierM :: AndroidSerial -> AndroidPath -> Key -> ExportLocation -> [ContentIdentifier] -> Annex Bool
+checkPresentExportWithContentIdentifierM serial adir _k loc knowncids = 
+	getExportContentIdentifier serial adir loc >>= \case
+		Right (Just cid) | cid `elem` knowncids -> return True
+		Right _ -> return False
+		Left _ -> giveup "unable to access Android device"
+
+androidExportLocation :: AndroidPath -> ExportLocation -> AndroidPath
+androidExportLocation adir loc = AndroidPath $
+	fromAndroidPath adir ++ "/" ++ fromRawFilePath (fromExportLocation loc)
+
+-- | List all connected Android devices.
+enumerateAdbConnected :: Annex [AndroidSerial]
+enumerateAdbConnected = checkAdbInPath [] $ liftIO $
+	mapMaybe parse . lines <$> readProcess "adb" ["devices"]
+  where
+	parse l = 
+		let (serial, desc) = separate (== '\t') l
+		in if null desc || length serial < 4
+			then Nothing 
+			else Just (AndroidSerial serial)
+
+-- | Runs a command on the android device with the given serial number.
+--
+-- Any stdout from the command is returned, separated into lines.
+adbShell :: AndroidSerial -> [CommandParam] -> Annex (Maybe [String])
+adbShell serial cmd = adbShell' serial cmd id
+
+adbShell' :: AndroidSerial -> [CommandParam] -> (String -> String) -> Annex (Maybe [String])
+adbShell' serial cmd f = adbShellRaw serial $
+	f (unwords $ map shellEscape (toCommand cmd))
+
+adbShellBool :: AndroidSerial -> [CommandParam] -> Annex Bool
+adbShellBool serial cmd =
+	adbShellRaw serial cmd' >>= return . \case
+		Just l -> end l == ["y"]
+		Nothing -> False
+  where
+	cmd' = "if " ++ unwords (map shellEscape (toCommand cmd))
+		++ "; then echo y; else echo n; fi"
+
+-- | Runs a raw shell command on the android device.
+-- Any necessary shellEscaping must be done by caller.
+adbShellRaw :: AndroidSerial -> String -> Annex (Maybe [String])
+adbShellRaw serial cmd = checkAdbInPath Nothing $ liftIO $ catchMaybeIO $ 
+	processoutput <$> readProcess "adb"
+		[ "-s"
+		, fromAndroidSerial serial
+		, "shell"
+		, cmd
+		]
+  where
+	processoutput s = map trimcr (lines s)
+	-- For some reason, adb outputs lines with \r\n on linux,
+	-- despite both linux and android being unix systems.
+	trimcr = takeWhile (/= '\r')
+
+checkAdbInPath :: a -> Annex a -> Annex a
+checkAdbInPath d a = ifM (isJust <$> liftIO (searchPath "adb"))
+	( a
+	, do
+		warning "adb command not found in PATH. Install it to use this remote."
+		return d
+	)
+
+mkAdbCommand :: AndroidSerial -> [CommandParam] -> [CommandParam]
+mkAdbCommand serial cmd = [Param "-s", Param (fromAndroidSerial serial)] ++ cmd
+
+-- Gets the current content identifier for a file on the android device.
+-- If the file is not present, returns Right Nothing
+getExportContentIdentifier :: AndroidSerial -> AndroidPath -> ExportLocation -> Annex (Either ExitCode (Maybe ContentIdentifier))
+getExportContentIdentifier serial adir loc = do
+	ls <- adbShellRaw serial $ unwords
+		[ "if test -e ", shellEscape aloc
+		, "; then stat -c"
+		, shellEscape adbStatFormat
+		, shellEscape aloc
+		, "; else echo n"
+		, "; fi"
+		]
+	return $ case ls of
+		Just ["n"] -> Right Nothing
+		Just (('S':'T':'\t':stat):[]) -> Right $ Just $
+			ContentIdentifier (encodeBS stat)
+		_ -> Left (ExitFailure 1)
+  where
+	aloc = fromAndroidPath $ androidExportLocation adir loc
+
+-- Includes size, modificiation time, and inode.
+-- Device not included because the adb interface ensures we're talking to
+-- the same android device.
+adbStatFormat :: String
+adbStatFormat = "ST\t%s %Y %i"
diff --git a/Remote/BitTorrent.hs b/Remote/BitTorrent.hs
new file mode 100644
index 0000000000..16ed8ff86f
--- /dev/null
+++ b/Remote/BitTorrent.hs
@@ -0,0 +1,416 @@
+{- BitTorrent remote.
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE CPP #-}
+
+module Remote.BitTorrent (remote) where
+
+import Annex.Common
+import Types.Remote
+import qualified Annex
+import qualified Git
+import qualified Git.Construct
+import Config
+import Config.Cost
+import Logs.Web
+import Types.UrlContents
+import Types.CleanupActions
+import Messages.Progress
+import Utility.Metered
+import Utility.Tmp
+import Utility.Url.Parse
+import Backend.URL
+import Annex.Perms
+import Annex.Tmp
+import Annex.UUID
+import qualified Annex.Url as Url
+import Remote.Helper.ExportImport
+import Annex.SpecialRemote.Config
+import qualified Utility.RawFilePath as R
+
+import Network.URI
+import qualified System.FilePath.ByteString as P
+
+#ifdef WITH_TORRENTPARSER
+import Data.Torrent
+import qualified Data.ByteString.Lazy as B
+#endif
+
+remote :: RemoteType
+remote = RemoteType
+	{ typename = "bittorrent"
+	, enumerate = list
+	, generate = gen
+	, configParser = mkRemoteConfigParser []
+	, setup = giveup "not supported"
+	, exportSupported = exportUnsupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+-- There is only one bittorrent remote, and it always exists.
+list :: Bool -> Annex [Git.Repo]
+list _autoinit = do
+	r <- liftIO $ Git.Construct.remoteNamed "bittorrent" (pure Git.Construct.fromUnknown)
+	return [r]
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r _ rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	cst <- remoteCost gc c expensiveRemoteCost
+	return $ Just Remote
+		{ uuid = bitTorrentUUID
+		, cost = cst
+		, name = Git.repoDescribe r
+		, storeKey = uploadKey
+		, retrieveKeyFile = downloadKey
+		, retrieveKeyFileCheap = Nothing
+		-- Bittorrent does its own hash checks.
+		, retrievalSecurityPolicy = RetrievalAllKeysSecure
+		, removeKey = dropKey
+		, lockContent = Nothing
+		, checkPresent = checkKey
+		, checkPresentCheap = False
+		, exportActions = exportUnsupported
+		, importActions = importUnsupported
+		, whereisKey = Nothing
+		, remoteFsck = Nothing
+		, repairRepo = Nothing
+		, config = c
+		, gitconfig = gc
+		, localpath = Nothing
+		, getRepo = return r
+		, readonly = True
+		, appendonly = False
+		, untrustworthy = False
+		, availability = pure GloballyAvailable
+		, remotetype = remote
+		, mkUnavailable = return Nothing
+		, getInfo = return []
+		, claimUrl = Just (pure . isSupportedUrl)
+		, checkUrl = Just checkTorrentUrl
+		, remoteStateHandle = rs
+		}
+
+downloadKey :: Key -> AssociatedFile -> FilePath -> MeterUpdate -> VerifyConfig -> Annex Verification
+downloadKey key _file dest p _ = do
+	get . map (torrentUrlNum . fst . getDownloader) =<< getBitTorrentUrls key
+	-- While bittorrent verifies the hash in the torrent file,
+	-- the torrent file itself is downloaded without verification,
+	-- so the overall download is not verified.
+	return UnVerified
+  where
+	get [] = giveup "could not download torrent"
+	get urls = do
+		showOutput -- make way for download progress bar
+		ok <- untilTrue urls $ \(u, filenum) -> do
+			registerTorrentCleanup u
+			checkDependencies
+			ifM (downloadTorrentFile u)
+				( downloadTorrentContent key u dest filenum p
+				, return False
+				)
+		unless ok $
+			get []
+
+uploadKey :: Key -> AssociatedFile -> MeterUpdate -> Annex ()
+uploadKey _ _ _ = giveup "upload to bittorrent not supported"
+
+dropKey :: Key -> Annex ()
+dropKey k = mapM_ (setUrlMissing k) =<< getBitTorrentUrls k
+
+{- We punt and don't try to check if a torrent has enough seeders
+ - with all the pieces etc. That would be quite hard.. and even if
+ - implemented, it tells us nothing about the later state of the torrent.
+ -}
+checkKey :: Key -> Annex Bool
+checkKey = giveup "cannot reliably check torrent status"
+
+getBitTorrentUrls :: Key -> Annex [URLString]
+getBitTorrentUrls key = filter supported <$> getUrls key
+  where
+	supported u =
+		let (u', dl) = (getDownloader u)
+		in dl == OtherDownloader && isSupportedUrl u'
+
+isSupportedUrl :: URLString -> Bool
+isSupportedUrl u = isTorrentMagnetUrl u || isTorrentUrl u
+
+isTorrentUrl :: URLString -> Bool
+isTorrentUrl = maybe False (\u -> ".torrent" `isSuffixOf` uriPath u) . parseURIPortable
+
+isTorrentMagnetUrl :: URLString -> Bool
+isTorrentMagnetUrl u = "magnet:" `isPrefixOf` u && checkbt (parseURIPortable u)
+  where
+	checkbt (Just uri) | "xt=urn:btih:" `isInfixOf` uriQuery uri = True
+	checkbt _ = False
+
+checkTorrentUrl :: URLString -> Annex UrlContents
+checkTorrentUrl u = do
+	checkDependencies
+	registerTorrentCleanup u
+	ifM (downloadTorrentFile u)
+		( torrentContents u
+		, giveup "could not download torrent file"
+		)
+
+{- To specify which file inside a multi-url torrent, the file number is
+ - appended to the url. -}
+torrentUrlWithNum :: URLString -> Int -> URLString
+torrentUrlWithNum u n = u ++ "#" ++ show n
+
+torrentUrlNum :: URLString -> (URLString, Int)
+torrentUrlNum u
+	| '#' `elem` u = 
+		let (n, ru) = separate (== '#') (reverse u)
+		in (reverse ru, fromMaybe 1 $ readish $ reverse n)
+	| otherwise = (u, 1)
+
+{- A Key corresponding to the URL of a torrent file. -}
+torrentUrlKey :: URLString -> Annex Key
+torrentUrlKey u = return $ fromUrl (fst $ torrentUrlNum u) Nothing False
+
+{- Temporary filename to use to store the torrent file. -}
+tmpTorrentFile :: URLString -> Annex RawFilePath
+tmpTorrentFile u = fromRepo . gitAnnexTmpObjectLocation =<< torrentUrlKey u
+
+{- A cleanup action is registered to delete the torrent file
+ - when git-annex exits.
+ -
+ - This allows multiple actions that use the same torrent file
+ - directory to run in a single git-annex run, and only download the
+ - torrent file once.
+ -}
+registerTorrentCleanup :: URLString -> Annex ()
+registerTorrentCleanup u = Annex.addCleanupAction (TorrentCleanup u) $
+	liftIO . removeWhenExistsWith R.removeLink =<< tmpTorrentFile u
+
+{- Downloads the torrent file. (Not its contents.) -}
+downloadTorrentFile :: URLString -> Annex Bool
+downloadTorrentFile u = do
+	torrent <- tmpTorrentFile u
+	ifM (liftIO $ doesFileExist (fromRawFilePath torrent))
+		( return True
+		, do
+			showAction "downloading torrent file"
+			createAnnexDirectory (parentDir torrent)
+			if isTorrentMagnetUrl u
+				then withOtherTmp $ \othertmp -> do
+					kf <- keyFile <$> torrentUrlKey u
+					let metadir = othertmp P.</> "torrentmeta" P.</> kf
+					createAnnexDirectory metadir
+					showOutput
+					ok <- downloadMagnetLink u
+						(fromRawFilePath metadir)
+						(fromRawFilePath torrent)
+					liftIO $ removeDirectoryRecursive
+						(fromRawFilePath metadir)
+					return ok
+				else withOtherTmp $ \othertmp -> do
+					withTmpFileIn (fromRawFilePath othertmp) "torrent" $ \f h -> do
+						liftIO $ hClose h
+						resetAnnexFilePerm (toRawFilePath f)
+						ok <- Url.withUrlOptions $ 
+							Url.download nullMeterUpdate Nothing u f
+						when ok $
+							liftIO $ moveFile (toRawFilePath f) torrent
+						return ok
+		)
+
+downloadMagnetLink :: URLString -> FilePath -> FilePath -> Annex Bool
+downloadMagnetLink u metadir dest = ifM download
+	( liftIO $ do
+		ts <- filter (".torrent" `isSuffixOf`)
+			<$> dirContents metadir
+		case ts of
+			(t:[]) -> do
+				moveFile (toRawFilePath t) (toRawFilePath dest)
+				return True
+			_ -> return False
+	, return False
+	)
+  where
+	download = runAria
+		[ Param "--bt-metadata-only"
+		, Param "--bt-save-metadata"
+		, Param u
+		, Param "--seed-time=0"
+		, Param "--summary-interval=0"
+		, Param "-d"
+		, File metadir
+		]
+
+downloadTorrentContent :: Key -> URLString -> FilePath -> Int -> MeterUpdate -> Annex Bool
+downloadTorrentContent k u dest filenum p = do
+	torrent <- tmpTorrentFile u
+	withOtherTmp $ \othertmp -> do
+		kf <- keyFile <$> torrentUrlKey u
+		let downloaddir = othertmp P.</> "torrent" P.</> kf
+		createAnnexDirectory downloaddir
+		f <- wantedfile torrent
+		let dlf = fromRawFilePath downloaddir </> f
+		showOutput
+		ifM (download torrent downloaddir <&&> liftIO (doesFileExist dlf))
+			( do
+				liftIO $ moveFile (toRawFilePath dlf) (toRawFilePath dest)
+				-- The downloaddir is not removed here,
+				-- so if aria downloaded parts of other
+				-- files, and this is called again, it will
+				-- resume where it left off.
+				-- withOtherTmp registers a cleanup action
+				-- that will clean up leftover files when
+				-- git-annex terminates.
+				return True
+			, return False
+			)
+  where
+	download torrent tmpdir = ariaProgress (fromKey keySize k) p
+		[ Param $ "--select-file=" ++ show filenum
+		, File (fromRawFilePath torrent)
+		, Param "-d"
+		, File (fromRawFilePath tmpdir)
+		, Param "--seed-time=0"
+		, Param "--summary-interval=0"
+		, Param "--file-allocation=none"
+		-- Needed so aria will resume partially downloaded files
+		-- in multi-file torrents.
+		, Param "--check-integrity=true"
+		]
+	
+	{- aria2c will create part of the directory structure
+	 - contained in the torrent. It may download parts of other files
+	 - in addition to the one we asked for. So, we need to find
+	 - out the filename we want based on the filenum.
+	 -}
+	wantedfile torrent = do
+		fs <- liftIO $ map fst <$> torrentFileSizes torrent
+		if length fs >= filenum
+			then return (fs !! (filenum - 1))
+			else giveup "Number of files in torrent seems to have changed."
+
+checkDependencies :: Annex ()
+checkDependencies = do
+	missing <- liftIO $ filterM (not <$$> inSearchPath) deps
+	unless (null missing) $
+		giveup $ "need to install additional software in order to download from bittorrent: " ++ unwords missing
+  where
+	deps =
+		[ "aria2c"
+#ifndef WITH_TORRENTPARSER
+		, "btshowmetainfo"
+#endif
+		]
+
+ariaParams :: [CommandParam] -> Annex [CommandParam]
+ariaParams ps = do
+	opts <- map Param . annexAriaTorrentOptions <$> Annex.getGitConfig
+	return (ps ++ opts)
+
+runAria :: [CommandParam] -> Annex Bool
+runAria ps = progressCommand "aria2c" =<< ariaParams ps
+
+-- Parse aria output to find "(n%)" and update the progress meter
+-- with it.
+ariaProgress :: Maybe Integer -> MeterUpdate -> [CommandParam] -> Annex Bool
+ariaProgress Nothing _ ps = runAria ps
+ariaProgress (Just sz) meter ps = do
+	oh <- mkOutputHandler
+	liftIO . commandMeter (parseAriaProgress sz) oh Nothing meter "aria2c"
+		=<< ariaParams ps
+
+parseAriaProgress :: Integer -> ProgressParser
+parseAriaProgress totalsize = go [] . reverse . splitc '\r'
+  where
+	go remainder [] = (Nothing, Nothing, remainder)
+	go remainder (x:xs) = case readish (findpercent x) of
+		Nothing -> go (x++remainder) xs
+		Just p -> (Just (frompercent p), Nothing, remainder)
+
+	-- "(N%)"
+	findpercent = takeWhile (/= '%') . drop 1 . dropWhile (/= '(')
+
+	frompercent p = toBytesProcessed $ totalsize * p `div` 100
+
+{- Used only if the haskell torrent library is not available. -}
+#ifndef WITH_TORRENTPARSER
+btshowmetainfo :: FilePath -> String -> IO [String]
+btshowmetainfo torrent field = 
+	findfield [] . lines <$> readProcess "btshowmetainfo" [torrent]
+  where
+	findfield c [] = reverse c
+	findfield c (l:ls)
+		| l == fieldkey = multiline c ls
+		| fieldkey `isPrefixOf` l =
+			findfield ((drop (length fieldkey) l):c) ls
+		| otherwise = findfield c ls
+
+	multiline c (l:ls)
+		| "   " `isPrefixOf` l = multiline (drop 3 l:c) ls
+		| otherwise = findfield c ls
+	multiline c [] = findfield c []
+
+	fieldkey = field ++ take (14 - length field) (repeat '.') ++ ": "
+#endif
+
+{- Examines the torrent file and gets the list of files in it,
+ - and their sizes.
+ -}
+torrentFileSizes :: RawFilePath -> IO [(FilePath, Integer)]
+torrentFileSizes torrent = do
+#ifdef WITH_TORRENTPARSER
+	let mkfile = joinPath . map (scrub . decodeBL)
+	b <- B.readFile (fromRawFilePath torrent)
+	return $ case readTorrent b of
+		Left e -> giveup $ "failed to parse torrent: " ++ e
+		Right t -> case tInfo t of
+			SingleFile { tLength = l, tName = f } ->
+				[ (mkfile [f], l) ]
+			MultiFile { tFiles = fs, tName = dir } ->
+				map (\tf -> (mkfile $ dir:filePath tf, fileLength tf)) fs
+  where
+#else
+	files <- getfield "files"
+	if null files
+		then do
+			fnl <- getfield "file name"
+			szl <- map readish <$> getfield "file size"
+			case (fnl, szl) of
+				((fn:[]), (Just sz:[])) -> return [(scrub fn, sz)]
+		 		_ -> parsefailed (show (fnl, szl))
+		else do
+			v <- getfield "directory name"
+			case v of
+				(d:[]) -> return $ map (splitsize d) files
+				_ -> parsefailed (show v)
+  where
+	getfield = btshowmetainfo (fromRawFilePath torrent)
+	parsefailed s = giveup $ "failed to parse btshowmetainfo output for torrent file: " ++ show s
+
+	-- btshowmetainfo outputs a list of "filename (size)"
+	splitsize d l = (scrub (d </> fn), sz)
+	  where
+		sz = fromMaybe (parsefailed l) $ readish $ 
+			reverse $ takeWhile (/= '(') $ dropWhile (== ')') $
+				reverse l
+		fn = reverse $ drop 2 $
+			dropWhile (/= '(') $ dropWhile (== ')') $ reverse l
+#endif
+	-- a malicious torrent file might try to do directory traversal
+	scrub f = if isAbsolute f || any (== "..") (splitPath f)
+		then giveup "found unsafe filename in torrent!"
+		else f
+
+torrentContents :: URLString -> Annex UrlContents
+torrentContents u = convert
+	<$> (liftIO . torrentFileSizes =<< tmpTorrentFile u)
+  where
+	convert [(fn, sz)] = UrlContents (Just sz) (Just fn)
+	convert l = UrlMulti $ map mkmulti (zip l [1..])
+
+	mkmulti ((fn, sz), n) = 
+		(torrentUrlWithNum u n, Just sz, joinPath $ drop 1 $ splitPath fn)
diff --git a/Remote/Borg.hs b/Remote/Borg.hs
new file mode 100644
index 0000000000..bdd9520603
--- /dev/null
+++ b/Remote/Borg.hs
@@ -0,0 +1,418 @@
+{- Using borg as a remote.
+ -
+ - Copyright 2020,2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Remote.Borg (remote) where
+
+import Annex.Common
+import Types.Remote
+import Types.Creds
+import Types.Import
+import qualified Git
+import qualified Git.LsTree as LsTree
+import Git.Types (toTreeItemType, TreeItemType(..))
+import Git.FilePath
+import Config
+import Config.Cost
+import Annex.Tmp
+import Annex.SpecialRemote.Config
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import Remote.Helper.Path
+import Annex.UUID
+import Types.ProposedAccepted
+import Utility.Metered
+import Logs.Export
+import qualified Remote.Helper.ThirdPartyPopulated as ThirdPartyPopulated
+import Utility.Env
+import Annex.Verify
+
+import Data.Either
+import Text.Read
+import Control.Exception (evaluate)
+import Control.DeepSeq
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import qualified System.FilePath.ByteString as P
+
+newtype BorgRepo = BorgRepo { locBorgRepo :: String }
+
+type BorgArchiveName = S.ByteString
+
+remote :: RemoteType
+remote = RemoteType
+	{ typename = "borg"
+	, enumerate = const (findSpecialRemotes "borgrepo")
+	, generate = gen
+	, configParser = mkRemoteConfigParser
+		[ optionalStringParser borgrepoField
+			(FieldDesc "(required) borg repository to use")
+		, optionalStringParser subdirField
+			(FieldDesc "limit to a subdirectory of the borg repository")
+		, yesNoParser appendonlyField (Just False)
+			(FieldDesc "you will not use borg to delete from the repository")
+		]
+	, setup = borgSetup
+	, exportSupported = exportUnsupported
+	, importSupported = importIsSupported
+	, thirdPartyPopulated = True
+	}
+
+borgrepoField :: RemoteConfigField
+borgrepoField = Accepted "borgrepo"
+
+subdirField :: RemoteConfigField
+subdirField = Accepted "subdir"
+
+appendonlyField :: RemoteConfigField
+appendonlyField = Accepted "appendonly"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	cst <- remoteCost gc c $
+		if borgLocal borgrepo
+			then nearlyCheapRemoteCost
+			else expensiveRemoteCost
+	return $ Just $ Remote
+		{ uuid = u
+		, cost = cst
+		, name = Git.repoDescribe r
+		, storeKey = storeKeyDummy
+		, retrieveKeyFile = retrieveKeyFileDummy
+		, retrieveKeyFileCheap = Nothing
+		-- Borg cryptographically verifies content.
+		, retrievalSecurityPolicy = RetrievalAllKeysSecure
+		, removeKey = removeKeyDummy
+		, lockContent = Nothing
+		, checkPresent = checkPresentDummy
+		, checkPresentCheap = borgLocal borgrepo
+		, exportActions = exportUnsupported
+		, importActions = ImportActions
+			{ listImportableContents = listImportableContentsM u borgrepo c
+			, importKey = Just ThirdPartyPopulated.importKey
+			, retrieveExportWithContentIdentifier = retrieveExportWithContentIdentifierM borgrepo
+			, checkPresentExportWithContentIdentifier = checkPresentExportWithContentIdentifierM borgrepo
+			-- This remote is thirdPartyPopulated, so these
+			-- actions will never be used.
+			, storeExportWithContentIdentifier = storeExportWithContentIdentifier importUnsupported
+			, removeExportDirectoryWhenEmpty = removeExportDirectoryWhenEmpty importUnsupported
+			, removeExportWithContentIdentifier = removeExportWithContentIdentifier importUnsupported
+			}
+		, whereisKey = Nothing
+		, remoteFsck = Nothing
+		, repairRepo = Nothing
+		, config = c
+		, getRepo = return r
+		, gitconfig = gc
+		, localpath = borgRepoLocalPath borgrepo
+		, remotetype = remote
+		, availability = checkAvailability borgrepo
+		, readonly = False
+		, appendonly = False
+		-- When the user sets the appendonly field, they are
+		-- promising not to delete content out from under git-annex
+		-- using borg, so the remote is not untrustworthy.
+		, untrustworthy = maybe True not $
+			getRemoteConfigValue appendonlyField c
+		, mkUnavailable = return Nothing
+		, getInfo = return [("repo", locBorgRepo borgrepo)]
+		, claimUrl = Nothing
+		, checkUrl = Nothing
+		, remoteStateHandle = rs
+		}
+  where
+	borgrepo = maybe
+		(giveup "missing borgrepo")
+		BorgRepo
+		(remoteAnnexBorgRepo gc)
+
+borgSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+borgSetup _ mu _ c _gc = do
+	u <- maybe (liftIO genUUID) return mu
+
+	-- verify configuration is sane
+	let borgrepo = maybe (giveup "Specify borgrepo=") fromProposedAccepted $
+		M.lookup borgrepoField c
+
+	-- The borgrepo is stored in git config, as well as this repo's
+	-- persistent state, so it can vary between hosts.
+	gitConfigSpecialRemote u c [("borgrepo", borgrepo)]
+
+	return (c, u)
+
+borgLocal :: BorgRepo -> Bool
+borgLocal (BorgRepo r) = notElem ':' r
+
+borgArchive :: BorgRepo -> BorgArchiveName -> String
+borgArchive (BorgRepo r) n = r ++ "::" ++ decodeBS n
+
+absBorgRepo :: BorgRepo -> IO BorgRepo
+absBorgRepo r@(BorgRepo p)
+	| borgLocal r = BorgRepo . fromRawFilePath
+		<$> absPath (toRawFilePath p)
+	| otherwise = return r
+
+borgRepoLocalPath :: BorgRepo -> Maybe FilePath
+borgRepoLocalPath r@(BorgRepo p)
+	| borgLocal r = Just p
+	| otherwise = Nothing
+
+checkAvailability :: BorgRepo -> Annex Availability
+checkAvailability borgrepo@(BorgRepo r) = 
+	checkPathAvailability (borgLocal borgrepo) r
+
+listImportableContentsM :: UUID -> BorgRepo -> ParsedRemoteConfig -> Annex (Maybe (ImportableContentsChunkable Annex (ContentIdentifier, ByteSize)))
+listImportableContentsM u borgrepo c = prompt $ do
+	imported <- getImported u
+	ls <- withborglist (locBorgRepo borgrepo) Nothing formatarchivelist $ \as ->
+		forM (filter (not . S.null) as) $ \archivename ->
+			return $ case M.lookup archivename imported of
+				Just getlist -> Left (archivename, getlist)
+				Nothing ->
+					let archive = borgArchive borgrepo archivename
+					    getlist = withborglist archive subdir formatfilelist $
+						liftIO . evaluate . force . parsefilelist archivename
+					    in Right (archivename, getlist)
+	if all isLeft ls && M.null (M.difference imported (M.fromList (lefts ls)))
+		then return Nothing -- unchanged since last time, avoid work
+		else Just <$> mkimportablecontents (map (either id id) ls)
+  where
+	withborglist what addparam format a = do
+		environ <- liftIO getEnvironment
+		let p = proc "borg" $ toCommand $ catMaybes
+			[ Just (Param "list")
+			, Just (Param "--format")
+			, Just (Param format)
+			, Just (Param what)
+			, addparam
+			]
+		(Nothing, Just h, Nothing, pid) <- liftIO $ createProcess $ p
+			{ std_out = CreatePipe
+			-- Run in C locale because the file list can
+			-- include some possibly translatable text in the
+			-- "extra" field.
+			, env = Just (addEntry "LANG" "C" environ)
+			}
+		l <- liftIO $ map L.toStrict 
+			. L.split 0 
+			<$> L.hGetContents h
+		let cleanup = liftIO $ do
+			hClose h
+			forceSuccessProcess p pid
+		a l `finally` cleanup
+
+	formatarchivelist = "{barchive}{NUL}"
+
+	formatfilelist = "{size}{NUL}{path}{NUL}{extra}{NUL}"
+
+	subdir = File <$> getRemoteConfigValue subdirField c
+
+	parsefilelist archivename (bsz:f:extra:rest) = case readMaybe (fromRawFilePath bsz) of
+		Nothing -> parsefilelist archivename rest
+		Just sz ->
+			let loc = genImportLocation f
+			-- borg list reports hard links as 0 byte files,
+			-- with the extra field set to " link to ".
+			-- When the annex object is a hard link to
+			-- something else, we'll assume it has not been
+			-- modified, since usually git-annex does prevent
+			-- this. Since the 0 byte size is not the actual
+			-- size,  report the key size instead, when available.
+			    (reqsz, retsz) = case extra of
+				" link to " -> (Nothing, fromMaybe sz . fromKey keySize)
+				_ -> (Just sz, const sz)
+			-- This does a little unnecessary work to parse the 
+			-- key, which is then thrown away. But, it lets the
+			-- file list be shrank down to only the ones that are
+			-- importable keys, so avoids needing to buffer all
+			-- the rest of the files in memory.
+			in case ThirdPartyPopulated.importKey' loc reqsz of
+				Just k -> (loc, (borgContentIdentifier, retsz k))
+					: parsefilelist archivename rest
+				Nothing -> parsefilelist archivename rest
+	parsefilelist _ _ = []
+
+	-- importableHistory is not used for retrieval, so is not
+	-- populated with old archives. Instead, a tree of archives
+	-- is constructed, with a subtree for each archive.
+	mkimportablecontents [] = return $ ImportableContentsComplete $
+		ImportableContents
+			{ importableContents = []
+			, importableHistory = []
+			}
+	mkimportablecontents (l:ls) = ImportableContentsChunked
+		<$> mkimportablecontentschunk l ls
+		<*> pure []
+	
+	mkimportablecontentschunk (archivename, getlist) rest = do
+		l <- getlist
+		return $ ImportableContentsChunk
+			{ importableContentsSubDir =
+				genImportChunkSubDir archivename
+			, importableContentsSubTree = l
+			, importableContentsNextChunk = case rest of
+				(getlist':rest') -> Just 
+					<$> mkimportablecontentschunk getlist' rest'
+				[] -> return Nothing
+			}
+
+-- We do not need a ContentIdentifier in order to retrieve a file from
+-- borg; the ImportLocation contains all that's needed. So, this is left
+-- empty.
+borgContentIdentifier :: ContentIdentifier
+borgContentIdentifier = ContentIdentifier mempty
+
+-- Convert a path file a borg archive to a path that can be used as an 
+-- ImportLocation. The archive name gets used as a subdirectory,
+-- which this path is inside.
+--
+-- Borg does not allow / in the name of an archive, so the archive
+-- name will always be the first directory in the ImportLocation.
+--
+-- This scheme also relies on the fact that paths in a borg archive are
+-- always relative, not absolute.
+genImportLocation :: RawFilePath -> RawFilePath
+genImportLocation = fromImportLocation . ThirdPartyPopulated.mkThirdPartyImportLocation
+
+genImportChunkSubDir :: BorgArchiveName -> ImportChunkSubDir
+genImportChunkSubDir = ImportChunkSubDir . fromImportLocation . ThirdPartyPopulated.mkThirdPartyImportLocation
+
+extractImportLocation :: ImportLocation -> (BorgArchiveName, RawFilePath)
+extractImportLocation loc = go $ P.splitDirectories $
+	ThirdPartyPopulated.fromThirdPartyImportLocation loc
+  where
+	go (archivename:rest) = (archivename, P.joinPath rest)
+	go _ = giveup $ "Unable to parse import location " ++ fromRawFilePath (fromImportLocation loc)
+
+-- Since the ImportLocation starts with the archive name, a list of all
+-- archive names we've already imported can be found by just listing the
+-- last imported tree. And the contents of those archives can be retrieved
+-- by listing the subtree recursively, which will likely be quite a lot
+-- faster than running borg.
+getImported :: UUID -> Annex (M.Map BorgArchiveName (Annex [(RawFilePath, (ContentIdentifier, ByteSize))]))
+getImported u = M.unions <$> (mapM go . exportedTreeishes =<< getExport u)
+  where
+	go t = M.fromList . mapMaybe mk
+		<$> inRepo (LsTree.lsTreeStrict LsTree.LsTreeNonRecursive (LsTree.LsTreeLong False) t)
+	
+	mk ti
+		| toTreeItemType (LsTree.mode ti) == Just TreeSubtree = Just
+			( getTopFilePath (LsTree.file ti)
+			, getcontents (LsTree.sha ti)
+			)
+		| otherwise = Nothing
+
+	getcontents t = mapMaybe mkcontents
+		<$> inRepo (LsTree.lsTreeStrict LsTree.LsTreeRecursive (LsTree.LsTreeLong False) t)
+	
+	mkcontents ti = do
+		let f = ThirdPartyPopulated.fromThirdPartyImportLocation $
+			mkImportLocation $ getTopFilePath $ LsTree.file ti
+		k <- fileKey (P.takeFileName f)
+		return
+			( genImportLocation f
+			,
+				( borgContentIdentifier
+				-- defaulting to 0 size is ok, this size
+				-- only gets used by
+				-- ThirdPartyPopulated.importKey,
+				-- which ignores the size when the key
+				-- does not have a size.
+				, fromMaybe 0 (fromKey keySize k)
+				)
+			)
+
+-- Check if the file is still there in the borg archive.
+-- Does not check that the content is unchanged; we assume that 
+-- the content of files in borg archives does not change, which is normally
+-- the case. But archives may be deleted, and files may be deleted.
+checkPresentExportWithContentIdentifierM :: BorgRepo -> Key -> ImportLocation -> [ContentIdentifier] -> Annex Bool
+checkPresentExportWithContentIdentifierM borgrepo _ loc _ = prompt $ liftIO $ do
+	let p = proc "borg" $ toCommand
+		[ Param "list"
+		, Param "--format"
+		, Param "1"
+		, Param (borgArchive borgrepo archivename)
+		, File (fromRawFilePath archivefile)
+		]
+	-- borg list exits nonzero with an error message if an archive
+	-- no longer exists. But, the user can delete archives at any
+	-- time they want. So, hide errors, and if it exists nonzero,
+	-- check if the borg repository still exists, and only throw an
+	-- exception if not.
+	(Nothing, Just h, Nothing, pid) <- withNullHandle $ \nullh ->
+		createProcess $ p
+			{ std_out = CreatePipe
+			, std_err = UseHandle nullh
+			}
+	ok <- (== "1") <$> hGetContentsStrict h
+	hClose h
+	ifM (checkSuccessProcess pid)
+		( return ok
+		, checkrepoexists
+		)
+  where
+	(archivename, archivefile) = extractImportLocation loc
+	
+	checkrepoexists = do
+		let p = proc "borg" $ toCommand
+			[ Param "list"
+			, Param "--format"
+			, Param "1"
+			, Param (locBorgRepo borgrepo)
+			]
+		(Nothing, Nothing, Nothing, pid) <- withNullHandle $ \nullh ->
+			createProcess $ p
+				{ std_out = UseHandle nullh }
+		ifM (checkSuccessProcess pid)
+			( return False -- repo exists, content not in it
+			, giveup $ "Unable to access borg repository " ++ locBorgRepo borgrepo
+			)
+
+retrieveExportWithContentIdentifierM :: BorgRepo -> ImportLocation -> [ContentIdentifier] -> FilePath -> Either Key (Annex Key) -> MeterUpdate -> Annex (Key, Verification)
+retrieveExportWithContentIdentifierM borgrepo loc _ dest gk _ = do
+	showOutput
+	case gk of
+		Right mkkey -> do
+			go
+			k <- mkkey
+			return (k, UnVerified)
+		Left k -> do
+			v <- verifyKeyContentIncrementally DefaultVerify k 
+				(\iv -> tailVerify iv (toRawFilePath dest) go)
+			return (k, v)
+  where
+	go = prompt $ withOtherTmp $ \othertmp -> liftIO $ do
+		-- borgrepo could be relative, and borg has to be run
+		-- in the temp directory to get it to write there
+		absborgrepo <- absBorgRepo borgrepo
+		let p = proc "borg" $ toCommand
+			[ Param "extract"
+			-- git-annex object files do not need any
+			-- xattrs or ACLs, and trying to extract
+			-- any that are set from the backup can lead
+			-- to problems when doing a retrieve from a
+			-- different OS than the one where the backup was
+			-- made.
+			, Param "--noxattrs"
+			, Param "--noacls"
+			, Param "--nobsdflags"
+			, Param (borgArchive absborgrepo archivename)
+			, File (fromRawFilePath archivefile)
+			]
+		(Nothing, Nothing, Nothing, pid) <- createProcess $ p
+			{ cwd = Just (fromRawFilePath othertmp) }
+		forceSuccessProcess p pid
+		-- Filepaths in borg archives are relative, so it's ok to
+		-- combine with </>
+		moveFile (othertmp P.</> archivefile) (toRawFilePath dest)
+		removeDirectoryRecursive (fromRawFilePath othertmp)
+
+	(archivename, archivefile) = extractImportLocation loc
diff --git a/Remote/Bup.hs b/Remote/Bup.hs
new file mode 100644
index 0000000000..8535edd02d
--- /dev/null
+++ b/Remote/Bup.hs
@@ -0,0 +1,343 @@
+{- Using bup as a remote.
+ -
+ - Copyright 2011-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes, OverloadedStrings #-}
+
+module Remote.Bup (remote) where
+
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import qualified System.FilePath.ByteString as P
+import Data.ByteString.Lazy.UTF8 (fromString)
+import Control.Concurrent.Async
+
+import Annex.Common
+import qualified Annex
+import Types.Remote
+import Types.Creds
+import Git.Types (ConfigValue(..), fromConfigKey)
+import qualified Git
+import qualified Git.Command
+import qualified Git.Config
+import qualified Git.Construct
+import qualified Git.Ref
+import Config
+import Config.Cost
+import qualified Remote.Helper.Ssh as Ssh
+import Annex.SpecialRemote.Config
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import Remote.Helper.Path
+import Utility.Hash
+import Utility.UserInfo
+import Annex.UUID
+import Annex.Ssh
+import Annex.LockFile
+import Annex.Perms
+import Utility.Metered
+import Types.ProposedAccepted
+
+type BupRepo = String
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "bup"
+	, enumerate = const (findSpecialRemotes "buprepo")
+	, generate = gen
+	, configParser = mkRemoteConfigParser
+		[ optionalStringParser buprepoField
+			(FieldDesc "(required) bup repository to use")
+		]
+	, setup = bupSetup
+	, exportSupported = exportUnsupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+buprepoField :: RemoteConfigField
+buprepoField = Accepted "buprepo"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	bupr <- liftIO $ bup2GitRemote buprepo
+	cst <- remoteCost gc c $
+		if bupLocal buprepo
+			then nearlyCheapRemoteCost
+			else expensiveRemoteCost
+	(u', bupr') <- getBupUUID bupr u
+	
+	let this = Remote
+		{ uuid = u'
+		, cost = cst
+		, name = Git.repoDescribe r
+		, storeKey = storeKeyDummy
+		, retrieveKeyFile = retrieveKeyFileDummy
+		, retrieveKeyFileCheap = Nothing
+		-- Bup uses git, which cryptographically verifies content
+		-- (with SHA1, but sufficiently for this).
+		, retrievalSecurityPolicy = RetrievalAllKeysSecure
+		, removeKey = removeKeyDummy
+		, lockContent = Nothing
+		, checkPresent = checkPresentDummy
+		, checkPresentCheap = bupLocal buprepo
+		, exportActions = exportUnsupported
+		, importActions = importUnsupported
+		, whereisKey = Nothing
+		, remoteFsck = Nothing
+		, repairRepo = Nothing
+		, config = c
+		, getRepo = return r
+		, gitconfig = gc
+		, localpath = if bupLocal buprepo && not (null buprepo)
+			then Just buprepo
+			else Nothing
+		, remotetype = remote
+		, availability = if null buprepo
+			then pure LocallyAvailable
+			else checkPathAvailability (bupLocal buprepo) buprepo
+		, readonly = False
+		, appendonly = False
+		, untrustworthy = False
+		, mkUnavailable = return Nothing
+		, getInfo = return [("repo", buprepo)]
+		, claimUrl = Nothing
+		, checkUrl = Nothing
+		, remoteStateHandle = rs
+		}
+	let specialcfg = (specialRemoteCfg c)
+		-- chunking would not improve bup
+		{ chunkConfig = NoChunks
+		}
+	return $ Just $ specialRemote' specialcfg c
+		(store this buprepo)
+		(retrieve this buprepo)
+		(remove buprepo)
+		(checkKey bupr')
+		this
+  where
+	buprepo = fromMaybe (giveup "missing buprepo") $ remoteAnnexBupRepo gc
+
+bupSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+bupSetup _ mu _ c gc = do
+	u <- maybe (liftIO genUUID) return mu
+
+	-- verify configuration is sane
+	let buprepo = maybe (giveup "Specify buprepo=") fromProposedAccepted $
+		M.lookup buprepoField c
+	(c', _encsetup) <- encryptionSetup c gc
+
+	-- bup init will create the repository.
+	-- (If the repository already exists, bup init again appears safe.)
+	showAction "bup init"
+	unlessM (bup "init" buprepo []) $ giveup "bup init failed"
+
+	storeBupUUID u buprepo
+
+	-- The buprepo is stored in git config, as well as this repo's
+	-- persistent state, so it can vary between hosts.
+	gitConfigSpecialRemote u c' [("buprepo", buprepo)]
+
+	return (c', u)
+
+bupParams :: String -> BupRepo -> [CommandParam] -> [CommandParam]
+bupParams command buprepo params = 
+	Param command : [Param "-r", Param buprepo] ++ params
+
+bup :: String -> BupRepo -> [CommandParam] -> Annex Bool
+bup command buprepo params = do
+	showOutput -- make way for bup output
+	liftIO $ boolSystem "bup" $ bupParams command buprepo params
+
+bupSplitParams :: Remote -> BupRepo -> Key -> [CommandParam] -> [CommandParam]
+bupSplitParams r buprepo k src =
+	let os = map Param $ remoteAnnexBupSplitOptions $ gitconfig r
+	in bupParams "split" buprepo 
+		(os ++ [Param "-q", Param "-n", Param (bupRef k)] ++ src)
+
+store :: Remote -> BupRepo -> Storer
+store r buprepo = byteStorer $ \k b p -> lockBup True r $ do
+	liftIO $ withNullHandle $ \nullh ->
+		let params = bupSplitParams r buprepo k []
+		    cmd = (proc "bup" (toCommand params))
+			{ std_in = CreatePipe
+			, std_out = UseHandle nullh
+			, std_err = CreatePipe
+			}
+		    feeder = \h -> do
+			meteredWrite p (S.hPut h) b
+			hClose h
+		in withCreateProcess cmd (go feeder cmd)
+  where
+	go feeder p (Just inh) _ (Just errh) pid = do
+		-- bup split is noisy to stderr even with the -q
+		-- option. But when bup fails, the stderr needs
+		-- to be displayed.
+		(feedresult, erroutput) <- tryNonAsync (feeder inh)
+			`concurrently` hGetContentsStrict errh
+		waitForProcess pid >>= \case
+			ExitSuccess -> case feedresult of
+				Right () -> return ()
+				Left e -> throwM e
+			ExitFailure n -> giveup $ 
+				showCmd p ++ " exited " ++ show n ++
+					" (stderr output: " ++ erroutput ++ ")"
+	go _ _ _ _ _ _ = error "internal"
+
+retrieve :: Remote -> BupRepo -> Retriever
+retrieve r buprepo = byteRetriever $ \k sink -> lockBup True r $ do
+	let params = bupParams "join" buprepo [Param $ bupRef k]
+	let p = (proc "bup" (toCommand params))
+		{ std_out = CreatePipe }
+	bracketIO (createProcess p) cleanupProcess (go sink p)
+  where
+	go sink p (_, Just h, _, pid) = do
+		v <- sink =<< liftIO (L.hGetContents h)
+		liftIO $ do
+			hClose h
+			forceSuccessProcess p pid
+		return v
+	go _ _ _ = error "internal"
+
+{- Cannot revert having stored a key in bup, but at least the data for the
+ - key will be used for deltaing data of other keys stored later.
+ -
+ - We can, however, remove the git branch that bup created for the key.
+ -}
+remove :: BupRepo -> Remover
+remove buprepo k = do
+	go =<< liftIO (bup2GitRemote buprepo)
+	warning "content cannot be completely removed from bup remote"
+  where
+	go r
+		| Git.repoIsUrl r = void $ onBupRemote r boolSystem "git" params
+		| otherwise = void $ liftIO $ catchMaybeIO $ do
+			r' <- Git.Config.read r
+			boolSystem "git" $ Git.Command.gitCommandLine params r'
+	params = [ Param "branch", Param "-q", Param "-D", Param (bupRef k) ]
+
+{- Bup does not provide a way to tell if a given dataset is present
+ - in a bup repository. One way it to check if the git repository has
+ - a branch matching the name (as created by bup split -n).
+ -}
+checkKey :: Git.Repo -> CheckPresent
+checkKey bupr k
+	| Git.repoIsUrl bupr = onBupRemote bupr boolSystem "git" params
+	| otherwise = liftIO $ boolSystem "git" $
+		Git.Command.gitCommandLine params bupr
+  where
+	params = 
+		[ Param "show-ref"
+		, Param "--quiet"
+		, Param "--verify"
+		, Param $ "refs/heads/" ++ bupRef k
+		]
+
+{- Store UUID in the annex.uuid setting of the bup repository. -}
+storeBupUUID :: UUID -> BupRepo -> Annex ()
+storeBupUUID u buprepo = do
+	r <- liftIO $ bup2GitRemote buprepo
+	if Git.repoIsUrl r
+		then do
+			showAction "storing uuid"
+			unlessM (onBupRemote r boolSystem "git"
+				[Param "config", Param (fromConfigKey configkeyUUID), Param v]) $
+					giveup "ssh failed"
+		else liftIO $ do
+			r' <- Git.Config.read r
+			let noolduuid = case Git.Config.get configkeyUUID mempty r' of
+				ConfigValue olduuid -> S.null olduuid
+				NoConfigValue -> True
+			when noolduuid $
+				Git.Command.run
+					[ Param "config"
+					, Param "annex.uuid"
+					, Param v
+					] r'
+  where
+	v = fromUUID u
+
+onBupRemote :: Git.Repo -> (FilePath -> [CommandParam] -> IO a) -> FilePath -> [CommandParam] -> Annex a
+onBupRemote r runner command params = do
+	c <- Annex.getRemoteGitConfig r
+	let remotecmd = "cd " ++ dir ++ " && " ++ unwords (command : toCommand params)
+	(sshcmd, sshparams) <- Ssh.toRepo NoConsumeStdin r c remotecmd
+	liftIO $ runner sshcmd sshparams
+  where
+	path = fromRawFilePath $ Git.repoPath r
+	base = fromMaybe path (stripPrefix "/~/" path)
+	dir = shellEscape base
+
+{- Allow for bup repositories on removable media by checking
+ - local bup repositories to see if they are available, and getting their
+ - uuid (which may be different from the stored uuid for the bup remote).
+ -
+ - If a bup repository is not available, returns NoUUID.
+ - This will cause checkPresent to indicate nothing from the bup remote
+ - is known to be present.
+ -
+ - Also, returns a version of the repo with config read, if it is local.
+ -}
+getBupUUID :: Git.Repo -> UUID -> Annex (UUID, Git.Repo)
+getBupUUID r u
+	| Git.repoIsUrl r = return (u, r)
+	| otherwise = liftIO $ do
+		ret <- tryIO $ Git.Config.read r
+		case ret of
+			Right r' -> return (toUUID $ Git.Config.get configkeyUUID mempty r', r')
+			Left _ -> return (NoUUID, r)
+
+{- Converts a bup remote path spec into a Git.Repo. There are some
+ - differences in path representation between git and bup. -}
+bup2GitRemote :: BupRepo -> IO Git.Repo
+bup2GitRemote "" = do
+	-- bup -r "" operates on ~/.bup
+	h <- myHomeDir
+	Git.Construct.fromPath $ toRawFilePath $ h </> ".bup"
+bup2GitRemote r
+	| bupLocal r = 
+		if "/" `isPrefixOf` r
+			then Git.Construct.fromPath (toRawFilePath r)
+			else giveup "please specify an absolute path"
+	| otherwise = Git.Construct.fromUrl $ "ssh://" ++ host ++ slash dir
+  where
+	bits = splitc ':' r
+	host = Prelude.head bits
+	dir = intercalate ":" $ drop 1 bits
+	-- "host:~user/dir" is not supported specially by bup;
+	-- "host:dir" is relative to the home directory;
+	-- "host:" goes in ~/.bup
+	slash d
+		| null d = "/~/.bup"
+		| "/" `isPrefixOf` d = d
+		| otherwise = "/~/" ++ d
+
+{- Converts a key into a git ref name, which bup-split -n will use to point
+ - to it. -}
+bupRef :: Key -> String
+bupRef k
+	| Git.Ref.legal True shown = shown
+	| otherwise = "git-annex-" ++ show (sha2_256 (fromString shown))
+  where
+	shown = serializeKey k
+
+bupLocal :: BupRepo -> Bool
+bupLocal = notElem ':'
+
+{- Bup is not concurrency safe, so use a lock file. Only one writer process
+ - should run at a time; multiple readers may run if no writer is running. -}
+lockBup :: Bool -> Remote -> Annex a -> Annex a
+lockBup writer r a = do
+	dir <- fromRepo gitAnnexRemotesDir
+	unlessM (liftIO $ doesDirectoryExist (fromRawFilePath dir)) $
+		createAnnexDirectory dir
+	let remoteid = fromUUID (uuid r)
+	let lck = dir P.</> remoteid <> ".lck"
+	if writer
+		then withExclusiveLock lck a
+		else withSharedLock lck a
diff --git a/Remote/Ddar.hs b/Remote/Ddar.hs
new file mode 100644
index 0000000000..9cc5f4a75e
--- /dev/null
+++ b/Remote/Ddar.hs
@@ -0,0 +1,239 @@
+{- Using ddar as a remote. Based on bup and rsync remotes.
+ -
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
+ - Copyright 2014 Robie Basak <robie@justgohome.co.uk>
+ -
+ - Licensed under the GNU GPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+{-# LANGUAGE RankNTypes #-}
+
+module Remote.Ddar (remote) where
+
+import qualified Data.Map as M
+import qualified Data.ByteString.Lazy as L
+import System.IO.Error
+import System.PosixCompat.Files (isDirectory)
+
+import Annex.Common
+import Types.Remote
+import Types.Creds
+import qualified Git
+import Config
+import Config.Cost
+import Annex.SpecialRemote.Config
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import Remote.Helper.Path
+import Annex.Ssh
+import Annex.UUID
+import Utility.SshHost
+import Types.ProposedAccepted
+import qualified Utility.RawFilePath as R
+
+data DdarRepo = DdarRepo
+	{ ddarRepoConfig :: RemoteGitConfig
+	, ddarRepoLocation :: String
+	}
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "ddar"
+	, enumerate = const (findSpecialRemotes "ddarrepo")
+	, generate = gen
+	, configParser = mkRemoteConfigParser
+		[ optionalStringParser ddarrepoField
+			(FieldDesc "(required) location of ddar archive to use")
+		]
+	, setup = ddarSetup
+	, exportSupported = exportUnsupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+ddarrepoField :: RemoteConfigField
+ddarrepoField = Accepted "ddarrepo"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	cst <- remoteCost gc c $
+		if ddarLocal ddarrepo
+			then nearlyCheapRemoteCost
+			else expensiveRemoteCost
+	let specialcfg = (specialRemoteCfg c)
+		-- chunking would not improve ddar
+		{ chunkConfig = NoChunks
+		}
+	return $ Just $ specialRemote' specialcfg c
+		(store ddarrepo)
+		(retrieve ddarrepo)
+		(remove ddarrepo)
+		(checkKey ddarrepo)
+		(this c cst)
+  where
+	this c cst = Remote
+		{ uuid = u
+		, cost = cst
+		, name = Git.repoDescribe r
+		, storeKey = storeKeyDummy
+		, retrieveKeyFile = retrieveKeyFileDummy
+		, retrieveKeyFileCheap = Nothing
+		-- ddar communicates over ssh, not subject to http redirect
+		-- type attacks
+		, retrievalSecurityPolicy = RetrievalAllKeysSecure
+		, removeKey = removeKeyDummy
+		, lockContent = Nothing
+		, checkPresent = checkPresentDummy
+		, checkPresentCheap = ddarLocal ddarrepo
+		, exportActions = exportUnsupported
+		, importActions = importUnsupported
+		, whereisKey = Nothing
+		, remoteFsck = Nothing
+		, repairRepo = Nothing
+		, config = c
+		, getRepo = return r
+		, gitconfig = gc
+		, localpath = if ddarLocal ddarrepo && not (null $ ddarRepoLocation ddarrepo)
+			then Just $ ddarRepoLocation ddarrepo
+			else Nothing
+		, remotetype = remote
+		, availability = checkPathAvailability
+			(ddarLocal ddarrepo && not (null $ ddarRepoLocation ddarrepo))
+			(ddarRepoLocation ddarrepo)
+		, readonly = False
+		, appendonly = False
+		, untrustworthy = False
+		, mkUnavailable = return Nothing
+		, getInfo = return [("repo", ddarRepoLocation ddarrepo)]
+		, claimUrl = Nothing
+		, checkUrl = Nothing
+		, remoteStateHandle = rs
+		}
+	ddarrepo = maybe (giveup "missing ddarrepo") (DdarRepo gc) (remoteAnnexDdarRepo gc)
+
+ddarSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+ddarSetup _ mu _ c gc = do
+	u <- maybe (liftIO genUUID) return mu
+
+	-- verify configuration is sane
+	let ddarrepo = maybe (giveup "Specify ddarrepo=") fromProposedAccepted $
+		M.lookup ddarrepoField c
+	(c', _encsetup) <- encryptionSetup c gc
+
+	-- The ddarrepo is stored in git config, as well as this repo's
+	-- persistent state, so it can vary between hosts.
+	gitConfigSpecialRemote u c' [("ddarrepo", ddarrepo)]
+
+	return (c', u)
+
+store :: DdarRepo -> Storer
+store ddarrepo = fileStorer $ \k src _p -> do
+	let params =
+		[ Param "c"
+		, Param "-N"
+		, Param $ serializeKey k
+		, Param $ ddarRepoLocation ddarrepo
+		, File src
+		]
+	unlessM (liftIO $ boolSystem "ddar" params) $
+		giveup "ddar failed"
+
+{- Convert remote DdarRepo to host and path on remote end -}
+splitRemoteDdarRepo :: DdarRepo -> (SshHost, String)
+splitRemoteDdarRepo ddarrepo = (either giveup id $ mkSshHost host, ddarrepo')
+  where
+	(host, remainder) = span (/= ':') (ddarRepoLocation ddarrepo)
+	ddarrepo' = drop 1 remainder
+
+{- Return the command and parameters to use for a ddar call that may need to be
+ - made on a remote repository. This will call ssh if needed. -}
+ddarRemoteCall :: ConsumeStdin -> DdarRepo -> Char -> [CommandParam] -> Annex (String, [CommandParam])
+ddarRemoteCall cs ddarrepo cmd params
+	| ddarLocal ddarrepo = return ("ddar", localParams)
+	| otherwise = sshCommand cs (host, Nothing) (ddarRepoConfig ddarrepo) remoteCommand
+  where
+	(host, ddarrepo') = splitRemoteDdarRepo ddarrepo
+	localParams = Param [cmd] : Param (ddarRepoLocation ddarrepo) : params
+	remoteCommand = unwords $ map shellEscape $ toCommand $
+		[Param "ddar", Param [cmd], Param ddarrepo'] ++ params
+
+{- Specialized ddarRemoteCall that includes extraction command and flags -}
+ddarExtractRemoteCall :: ConsumeStdin -> DdarRepo -> Key -> Annex (String, [CommandParam])
+ddarExtractRemoteCall cs ddarrepo k =
+	ddarRemoteCall cs ddarrepo 'x' [Param "--force-stdout", Param $ serializeKey k]
+
+retrieve :: DdarRepo -> Retriever
+retrieve ddarrepo = byteRetriever $ \k sink -> do
+	(cmd, params) <- ddarExtractRemoteCall NoConsumeStdin ddarrepo k
+	let p = (proc cmd $ toCommand params)
+		{ std_out = CreatePipe }
+	bracketIO (createProcess p) cleanupProcess (go sink p)
+  where
+	go sink p (_, Just h, _, pid) = do
+		r <- sink =<< liftIO (L.hGetContents h)
+		liftIO $ do
+			hClose h
+			forceSuccessProcess p pid
+		return r
+	go _ _ _ = error "internal"
+
+remove :: DdarRepo -> Remover
+remove ddarrepo key = do
+	(cmd, params) <- ddarRemoteCall NoConsumeStdin ddarrepo 'd'
+		[Param $ serializeKey key]
+	unlessM (liftIO $ boolSystem cmd params) $
+		giveup "ddar failed to remove"
+
+ddarDirectoryExists :: DdarRepo -> Annex (Either String Bool)
+ddarDirectoryExists ddarrepo
+	| ddarLocal ddarrepo = do
+		maybeStatus <- liftIO $ tryJust (guard . isDoesNotExistError) $
+			R.getSymbolicLinkStatus $ toRawFilePath $ ddarRepoLocation ddarrepo
+		return $ case maybeStatus of
+			Left _ -> Right False
+			Right status -> Right $ isDirectory status
+	| otherwise = do
+		let remotecmd = unwords $ map shellEscape
+			[ "test", "-d", ddarrepo' ]
+		(sshcmd, sshps) <- sshCommand NoConsumeStdin (host, Nothing)
+			(ddarRepoConfig ddarrepo) remotecmd
+		exitCode <- liftIO $ safeSystem sshcmd sshps
+		case exitCode of
+			ExitSuccess -> return $ Right True
+			ExitFailure 1 -> return $ Right False
+			ExitFailure code -> return $ Left $ "ssh " ++
+				show (unwords $ toCommand sshps) ++
+				" failed with status " ++ show code
+  where
+	(host, ddarrepo') = splitRemoteDdarRepo ddarrepo
+
+{- Use "ddar t" to determine if a given key is present in a ddar archive -}
+inDdarManifest :: DdarRepo -> Key -> Annex (Either String Bool)
+inDdarManifest ddarrepo k = do
+	(cmd, params) <- ddarRemoteCall NoConsumeStdin ddarrepo 't' []
+	let p = (proc cmd $ toCommand params)
+		{ std_out = CreatePipe }
+	liftIO $ catchMsgIO $ withCreateProcess p (go p)
+  where
+	k' = serializeKey k
+	
+	go p _ (Just hout) _ pid = do
+		contents <- hGetContents hout
+		let !r = elem k' (lines contents)
+		forceSuccessProcess p pid
+		return r
+	go _ _ _ _ _ = error "internal"
+
+checkKey :: DdarRepo -> CheckPresent
+checkKey ddarrepo key = do
+	directoryExists <- ddarDirectoryExists ddarrepo
+	case directoryExists of
+		Left e -> error e
+		Right True -> either giveup return
+			=<< inDdarManifest ddarrepo key
+		Right False -> return False
+
+ddarLocal :: DdarRepo -> Bool
+ddarLocal = notElem ':' . ddarRepoLocation
diff --git a/Remote/Directory.hs b/Remote/Directory.hs
new file mode 100644
index 0000000000..82b7f114f0
--- /dev/null
+++ b/Remote/Directory.hs
@@ -0,0 +1,604 @@
+{- A "remote" that is just a filesystem directory.
+ -
+ - Copyright 2011-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE CPP #-}
+
+module Remote.Directory (
+	remote,
+	finalizeStoreGeneric,
+	removeDirGeneric,
+) where
+
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Map as M
+import qualified System.FilePath.ByteString as P
+import Data.Default
+import System.PosixCompat.Files (isRegularFile, deviceID)
+#ifndef mingw32_HOST_OS
+import System.PosixCompat.Files (getFdStatus)
+#endif
+
+import Annex.Common
+import Types.Remote
+import Types.Export
+import Types.Creds
+import qualified Git
+import Config.Cost
+import Config
+import Annex.SpecialRemote.Config
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import Remote.Helper.Path
+import Types.Import
+import qualified Remote.Directory.LegacyChunked as Legacy
+import Annex.CopyFile
+import Annex.Content
+import Annex.Perms
+import Annex.UUID
+import Annex.Verify
+import Backend
+import Types.KeySource
+import Types.ProposedAccepted
+import Utility.Metered
+import Utility.Tmp
+import Utility.InodeCache
+import Utility.FileMode
+import Utility.Directory.Create
+import qualified Utility.RawFilePath as R
+#ifndef mingw32_HOST_OS
+import Utility.OpenFd
+#endif
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "directory"
+	, enumerate = const (findSpecialRemotes "directory")
+	, generate = gen
+	, configParser = mkRemoteConfigParser
+		[ optionalStringParser directoryField
+			(FieldDesc "(required) where the special remote stores data")
+		, yesNoParser ignoreinodesField (Just False)
+			(FieldDesc "ignore inodes when importing/exporting")
+		]
+	, setup = directorySetup
+	, exportSupported = exportIsSupported
+	, importSupported = importIsSupported
+	, thirdPartyPopulated = False
+	}
+
+directoryField :: RemoteConfigField
+directoryField = Accepted "directory"
+
+ignoreinodesField :: RemoteConfigField
+ignoreinodesField = Accepted "ignoreinodes"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	cst <- remoteCost gc c cheapRemoteCost
+	let chunkconfig = getChunkConfig c
+	cow <- liftIO newCopyCoWTried
+	let ii = IgnoreInodes $ fromMaybe True $
+		getRemoteConfigValue ignoreinodesField c
+	return $ Just $ specialRemote c
+		(storeKeyM dir chunkconfig cow)
+		(retrieveKeyFileM dir chunkconfig cow)
+		(removeKeyM dir)
+		(checkPresentM dir chunkconfig)
+		Remote
+			{ uuid = u
+			, cost = cst
+			, name = Git.repoDescribe r
+			, storeKey = storeKeyDummy
+			, retrieveKeyFile = retrieveKeyFileDummy
+			, retrieveKeyFileCheap = retrieveKeyFileCheapM dir chunkconfig
+			, retrievalSecurityPolicy = RetrievalAllKeysSecure
+			, removeKey = removeKeyDummy
+			, lockContent = Nothing
+			, checkPresent = checkPresentDummy
+			, checkPresentCheap = True
+			, exportActions = ExportActions
+				{ storeExport = storeExportM dir cow
+				, retrieveExport = retrieveExportM dir cow
+				, removeExport = removeExportM dir
+				, versionedExport = False
+				, checkPresentExport = checkPresentExportM dir
+				-- Not needed because removeExportLocation
+				-- auto-removes empty directories.
+				, removeExportDirectory = Nothing
+				, renameExport = Just $ renameExportM dir
+				}
+			, importActions = ImportActions
+				{ listImportableContents = listImportableContentsM ii dir
+				, importKey = Just (importKeyM ii dir)
+				, retrieveExportWithContentIdentifier = retrieveExportWithContentIdentifierM ii dir cow
+				, storeExportWithContentIdentifier = storeExportWithContentIdentifierM ii dir cow
+				, removeExportWithContentIdentifier = removeExportWithContentIdentifierM ii dir
+				-- Not needed because removeExportWithContentIdentifier
+				-- auto-removes empty directories.
+				, removeExportDirectoryWhenEmpty = Nothing
+				, checkPresentExportWithContentIdentifier = checkPresentExportWithContentIdentifierM ii dir
+				}
+			, whereisKey = Nothing
+			, remoteFsck = Nothing
+			, repairRepo = Nothing
+			, config = c
+			, getRepo = return r
+			, gitconfig = gc
+			, localpath = Just dir'
+			, readonly = False
+			, appendonly = False
+			, untrustworthy = False
+			, availability = checkPathAvailability True dir'
+			, remotetype = remote
+			, mkUnavailable = gen r u rc
+				(gc { remoteAnnexDirectory = Just "/dev/null" }) rs
+			, getInfo = return [("directory", dir')]
+			, claimUrl = Nothing
+			, checkUrl = Nothing
+			, remoteStateHandle = rs
+			}
+  where
+	dir = toRawFilePath dir'
+	dir' = fromMaybe (giveup "missing directory") (remoteAnnexDirectory gc)
+
+directorySetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+directorySetup _ mu _ c gc = do
+	u <- maybe (liftIO genUUID) return mu
+	-- verify configuration is sane
+	let dir = maybe (giveup "Specify directory=") fromProposedAccepted $
+		M.lookup directoryField c
+	absdir <- liftIO $ fromRawFilePath <$> absPath (toRawFilePath dir)
+	liftIO $ unlessM (doesDirectoryExist absdir) $
+		giveup $ "Directory does not exist: " ++ absdir
+	(c', _encsetup) <- encryptionSetup c gc
+
+	-- The directory is stored in git config, not in this remote's
+	-- persistent state, so it can vary between hosts.
+	gitConfigSpecialRemote u c' [("directory", absdir)]
+	return (M.delete directoryField c', u)
+
+{- Locations to try to access a given Key in the directory.
+ - We try more than one since we used to write to different hash
+ - directories. -}
+locations :: RawFilePath -> Key -> [RawFilePath]
+locations d k = map (d P.</>) (keyPaths k)
+
+{- Returns the location off a Key in the directory. If the key is
+ - present, returns the location that is actually used, otherwise
+ - returns the first, default location. -}
+getLocation :: RawFilePath -> Key -> IO RawFilePath
+getLocation d k = do
+	let locs = locations d k
+	fromMaybe (Prelude.head locs)
+		<$> firstM (doesFileExist . fromRawFilePath) locs
+
+{- Directory where the file(s) for a key are stored. -}
+storeDir :: RawFilePath -> Key -> RawFilePath
+storeDir d k = P.addTrailingPathSeparator $
+	d P.</> hashDirLower def k P.</> keyFile k
+
+{- Check if there is enough free disk space in the remote's directory to
+ - store the key. Note that the unencrypted key size is checked. -}
+storeKeyM :: RawFilePath -> ChunkConfig -> CopyCoWTried -> Storer
+storeKeyM d chunkconfig cow k c m = 
+	ifM (checkDiskSpaceDirectory d k)
+		( do
+			void $ liftIO $ tryIO $ createDirectoryUnder [d] tmpdir
+			store
+		, giveup "Not enough free disk space."
+		)
+  where
+	store = case chunkconfig of
+		LegacyChunks chunksize -> 
+			let go _k b p = liftIO $ Legacy.store
+				(fromRawFilePath d)
+				chunksize
+				(finalizeStoreGeneric d)
+				k b p
+				(fromRawFilePath tmpdir)
+				(fromRawFilePath destdir)
+			in byteStorer go k c m
+		NoChunks ->
+			let go _k src p = liftIO $ do
+				void $ fileCopier cow src tmpf p Nothing
+				finalizeStoreGeneric d tmpdir destdir
+			in fileStorer go k c m
+		_ -> 
+			let go _k b p = liftIO $ do
+				meteredWriteFile p tmpf b
+				finalizeStoreGeneric d tmpdir destdir
+			in byteStorer go k c m
+	
+	tmpdir = P.addTrailingPathSeparator $ d P.</> "tmp" P.</> kf
+	tmpf = fromRawFilePath tmpdir </> fromRawFilePath kf
+	kf = keyFile k
+	destdir = storeDir d k
+
+checkDiskSpaceDirectory :: RawFilePath -> Key -> Annex Bool
+checkDiskSpaceDirectory d k = do
+	annexdir <- fromRepo gitAnnexObjectDir
+	samefilesystem <- liftIO $ catchDefaultIO False $ 
+		(\a b -> deviceID a == deviceID b)
+			<$> R.getSymbolicLinkStatus d
+			<*> R.getSymbolicLinkStatus annexdir
+	checkDiskSpace Nothing (Just d) k 0 samefilesystem
+
+{- Passed a temp directory that contains the files that should be placed
+ - in the dest directory, moves it into place. Anything already existing
+ - in the dest directory will be deleted. File permissions will be locked
+ - down. -}
+finalizeStoreGeneric :: RawFilePath -> RawFilePath -> RawFilePath -> IO ()
+finalizeStoreGeneric d tmp dest = do
+	removeDirGeneric False (fromRawFilePath d) dest'
+	createDirectoryUnder [d] (parentDir dest)
+	renameDirectory (fromRawFilePath tmp) dest'
+	-- may fail on some filesystems
+	void $ tryIO $ do
+		mapM_ (preventWrite . toRawFilePath) =<< dirContents dest'
+		preventWrite dest
+  where
+	dest' = fromRawFilePath dest
+
+retrieveKeyFileM :: RawFilePath -> ChunkConfig -> CopyCoWTried -> Retriever
+retrieveKeyFileM d (LegacyChunks _) _ = Legacy.retrieve locations d
+retrieveKeyFileM d NoChunks cow = fileRetriever' $ \dest k p iv -> do
+	src <- liftIO $ fromRawFilePath <$> getLocation d k
+	void $ liftIO $ fileCopier cow src (fromRawFilePath dest) p iv
+retrieveKeyFileM d _ _ = byteRetriever $ \k sink ->
+	sink =<< liftIO (L.readFile . fromRawFilePath =<< getLocation d k)
+
+retrieveKeyFileCheapM :: RawFilePath -> ChunkConfig -> Maybe (Key -> AssociatedFile -> FilePath -> Annex ())
+-- no cheap retrieval possible for chunks
+retrieveKeyFileCheapM _ (UnpaddedChunks _) = Nothing
+retrieveKeyFileCheapM _ (LegacyChunks _) = Nothing
+#ifndef mingw32_HOST_OS
+retrieveKeyFileCheapM d NoChunks = Just $ \k _af f -> liftIO $ do
+	file <- fromRawFilePath <$> (absPath =<< getLocation d k)
+	ifM (doesFileExist file)
+		( R.createSymbolicLink (toRawFilePath file) (toRawFilePath f)
+		, giveup "content file not present in remote"
+		)
+#else
+retrieveKeyFileCheapM _ _ = Nothing
+#endif
+
+removeKeyM :: RawFilePath -> Remover
+removeKeyM d k = liftIO $ removeDirGeneric True
+	(fromRawFilePath d)
+	(fromRawFilePath (storeDir d k))
+
+{- Removes the directory, which must be located under the topdir.
+ -
+ - Succeeds even on directories and contents that do not have write
+ - permission, if it's possible to turn the write bit on.
+ -
+ - If the directory does not exist, succeeds as long as the topdir does
+ - exist. If the topdir does not exist, fails, because in this case the
+ - remote is not currently accessible and probably still has the content
+ - we were supposed to remove from it.
+ -
+ - Empty parent directories (up to but not including the topdir)
+ - can also be removed. Failure to remove such a directory is not treated
+ - as an error.
+ -}
+removeDirGeneric :: Bool -> FilePath -> FilePath -> IO ()
+removeDirGeneric removeemptyparents topdir dir = do
+	void $ tryIO $ allowWrite (toRawFilePath dir)
+#ifdef mingw32_HOST_OS
+	{- Windows needs the files inside the directory to be writable
+	 - before it can delete them. -}
+	void $ tryIO $ mapM_ (allowWrite . toRawFilePath) =<< dirContents dir
+#endif
+	tryNonAsync (removeDirectoryRecursive dir) >>= \case
+		Right () -> return ()
+		Left e ->
+			unlessM (doesDirectoryExist topdir <&&> (not <$> doesDirectoryExist dir)) $
+				throwM e
+	when removeemptyparents $ do
+		subdir <- relPathDirToFile (toRawFilePath topdir) (P.takeDirectory (toRawFilePath dir))
+		goparents (Just (P.takeDirectory subdir)) (Right ())
+  where
+	goparents _ (Left _e) = return ()
+	goparents Nothing _ = return ()
+	goparents (Just subdir) _ = do
+		let d = topdir </> fromRawFilePath subdir
+		goparents (upFrom subdir) =<< tryIO (removeDirectory d)
+
+checkPresentM :: RawFilePath -> ChunkConfig -> CheckPresent
+checkPresentM d (LegacyChunks _) k = Legacy.checkKey d locations k
+checkPresentM d _ k = checkPresentGeneric d (locations d k)
+
+checkPresentGeneric :: RawFilePath -> [RawFilePath] -> Annex Bool
+checkPresentGeneric d ps = checkPresentGeneric' d $
+	liftIO $ anyM (doesFileExist . fromRawFilePath) ps
+
+checkPresentGeneric' :: RawFilePath -> Annex Bool -> Annex Bool
+checkPresentGeneric' d check = ifM check
+	( return True
+	, ifM (liftIO $ doesDirectoryExist (fromRawFilePath d))
+		( return False
+		, giveup $ "directory " ++ fromRawFilePath d ++ " is not accessible"
+		)
+	)
+
+storeExportM :: RawFilePath -> CopyCoWTried -> FilePath -> Key -> ExportLocation -> MeterUpdate -> Annex ()
+storeExportM d cow src _k loc p = do
+	liftIO $ createDirectoryUnder [d] (P.takeDirectory dest)
+	-- Write via temp file so that checkPresentGeneric will not
+	-- see it until it's fully stored.
+	viaTmp go (fromRawFilePath dest) ()
+  where
+	dest = exportPath d loc
+	go tmp () = void $ liftIO $ fileCopier cow src tmp p Nothing
+
+retrieveExportM :: RawFilePath -> CopyCoWTried -> Key -> ExportLocation -> FilePath -> MeterUpdate -> Annex Verification
+retrieveExportM d cow k loc dest p = 
+	verifyKeyContentIncrementally AlwaysVerify k $ \iv -> 
+		void $ liftIO $ fileCopier cow src dest p iv
+  where
+	src = fromRawFilePath $ exportPath d loc
+
+removeExportM :: RawFilePath -> Key -> ExportLocation -> Annex ()
+removeExportM d _k loc = liftIO $ do
+	removeWhenExistsWith R.removeLink src
+	removeExportLocation d loc
+  where
+	src = exportPath d loc
+
+checkPresentExportM :: RawFilePath -> Key -> ExportLocation -> Annex Bool
+checkPresentExportM d _k loc =
+	checkPresentGeneric d [exportPath d loc]
+
+renameExportM :: RawFilePath -> Key -> ExportLocation -> ExportLocation -> Annex (Maybe ())
+renameExportM d _k oldloc newloc = liftIO $ do
+	createDirectoryUnder [d] (P.takeDirectory dest)
+	renameFile (fromRawFilePath src) (fromRawFilePath dest)
+	removeExportLocation d oldloc
+	return (Just ())
+  where
+	src = exportPath d oldloc
+	dest = exportPath d newloc
+
+exportPath :: RawFilePath -> ExportLocation -> RawFilePath
+exportPath d loc = d P.</> fromExportLocation loc
+
+{- Removes the ExportLocation's parent directory and its parents, so long as
+ - they're empty, up to but not including the topdir. -}
+removeExportLocation :: RawFilePath -> ExportLocation -> IO ()
+removeExportLocation topdir loc = 
+	go (Just $ P.takeDirectory $ fromExportLocation loc) (Right ())
+  where
+	go _ (Left _e) = return ()
+	go Nothing _ = return ()
+	go (Just loc') _ = 
+		let p = fromRawFilePath $ exportPath topdir $
+			mkExportLocation loc'
+		in go (upFrom loc') =<< tryIO (removeDirectory p)
+
+listImportableContentsM :: IgnoreInodes -> RawFilePath -> Annex (Maybe (ImportableContentsChunkable Annex (ContentIdentifier, ByteSize)))
+listImportableContentsM ii dir = liftIO $ do
+	l <- dirContentsRecursiveSkipping (const False) False (fromRawFilePath dir)
+	l' <- mapM (go . toRawFilePath) l
+	return $ Just $ ImportableContentsComplete $
+		ImportableContents (catMaybes l') []
+  where
+	go f = do
+		st <- R.getSymbolicLinkStatus f
+		mkContentIdentifier ii f st >>= \case
+			Nothing -> return Nothing
+			Just cid -> do
+				relf <- relPathDirToFile dir f
+				sz <- getFileSize' f st
+				return $ Just (mkImportLocation relf, (cid, sz))
+
+newtype IgnoreInodes = IgnoreInodes Bool
+
+-- Make a ContentIdentifier that contains the size and mtime of the file,
+-- and also normally the inode, unless ignoreinodes=yes.
+--
+-- If the file is not a regular file, this will return Nothing.
+mkContentIdentifier :: IgnoreInodes -> RawFilePath -> FileStatus -> IO (Maybe ContentIdentifier)
+mkContentIdentifier (IgnoreInodes ii) f st =
+	liftIO $ fmap (ContentIdentifier . encodeBS . showInodeCache)
+		<$> if ii
+			then toInodeCache' noTSDelta f st 0
+			else toInodeCache noTSDelta f st
+
+-- Since ignoreinodes can be changed by enableremote, and since previous
+-- versions of git-annex ignored inodes by default, treat two content
+-- idenfiers as the same if they differ only by one having the inode
+-- ignored.
+guardSameContentIdentifiers :: a -> [ContentIdentifier] -> Maybe ContentIdentifier -> a
+guardSameContentIdentifiers _ _ Nothing = giveup "file not found"
+guardSameContentIdentifiers cont olds (Just new)
+	| any (new ==) olds = cont
+	| any (ignoreinode new ==) olds = cont
+	| any (\old -> new == ignoreinode old) olds = cont
+	| otherwise = giveup "file content has changed"
+  where
+	ignoreinode cid@(ContentIdentifier b) = 
+		case readInodeCache (decodeBS b) of
+			Nothing -> cid
+			Just ic -> 
+				let ic' = replaceInode 0 ic
+				in ContentIdentifier (encodeBS (showInodeCache ic'))
+
+importKeyM :: IgnoreInodes -> RawFilePath -> ExportLocation -> ContentIdentifier -> ByteSize -> MeterUpdate -> Annex (Maybe Key)
+importKeyM ii dir loc cid sz p = do
+	backend <- chooseBackend f
+	unsizedk <- fst <$> genKey ks p backend
+	let k = alterKey unsizedk $ \kd -> kd
+		{ keySize = keySize kd <|> Just sz }
+	currcid <- liftIO $ mkContentIdentifier ii absf
+		=<< R.getSymbolicLinkStatus absf
+	guardSameContentIdentifiers (return (Just k)) [cid] currcid
+  where
+	f = fromExportLocation loc
+	absf = dir P.</> f
+	ks  = KeySource
+		{ keyFilename = f
+		, contentLocation = absf
+		, inodeCache = Nothing
+		}
+
+retrieveExportWithContentIdentifierM :: IgnoreInodes -> RawFilePath -> CopyCoWTried -> ExportLocation -> [ContentIdentifier] -> FilePath -> Either Key (Annex Key) -> MeterUpdate -> Annex (Key, Verification)
+retrieveExportWithContentIdentifierM ii dir cow loc cids dest gk p =
+	case gk of
+		Right mkkey -> do
+			go Nothing
+			k <- mkkey
+			return (k, UnVerified)
+		Left k -> do
+			v <- verifyKeyContentIncrementally DefaultVerify k go
+			return (k, v)
+  where
+	f = exportPath dir loc
+	f' = fromRawFilePath f
+	
+	go iv = precheck (docopy iv)
+
+	docopy iv = ifM (liftIO $ tryCopyCoW cow f' dest p)
+		( postcheckcow (liftIO $ maybe noop unableIncrementalVerifier iv)
+		, docopynoncow iv
+		)
+
+	docopynoncow iv = do
+#ifndef mingw32_HOST_OS
+		let open = do
+			-- Need a duplicate fd for the post check.
+			fd <- openFdWithMode f ReadOnly Nothing defaultFileFlags
+			dupfd <- dup fd
+			h <- fdToHandle fd
+			return (h, dupfd)
+		let close (h, dupfd) = do
+			hClose h
+			closeFd dupfd
+		bracketIO open close $ \(h, dupfd) -> do
+#else
+		let open = openBinaryFile f' ReadMode
+		let close = hClose
+		bracketIO open close $ \h -> do
+#endif
+			liftIO $ fileContentCopier h dest p iv
+#ifndef mingw32_HOST_OS
+			postchecknoncow dupfd (return ())
+#else
+			postchecknoncow (return ())
+#endif
+	
+	-- Check before copy, to avoid expensive copy of wrong file
+	-- content.
+	precheck cont = guardSameContentIdentifiers cont cids
+		=<< liftIO . mkContentIdentifier ii f
+		=<< liftIO (R.getSymbolicLinkStatus f)
+
+	-- Check after copy, in case the file was changed while it was
+	-- being copied.
+	--
+	-- When possible (not on Windows), check the same handle
+	-- that the file was copied from. Avoids some race cases where
+	-- the file is modified while it's copied but then gets restored
+	-- to the original content afterwards.
+	--
+	-- This does not guard against every possible race, but neither
+	-- can InodeCaches detect every possible modification to a file.
+	-- It's probably as good or better than git's handling of similar
+	-- situations with files being modified while it's updating the
+	-- working tree for a merge.
+#ifndef mingw32_HOST_OS
+	postchecknoncow fd cont = do
+#else
+	postchecknoncow cont = do
+#endif
+		currcid <- liftIO $ mkContentIdentifier ii f
+#ifndef mingw32_HOST_OS
+			=<< getFdStatus fd
+#else
+			=<< R.getSymbolicLinkStatus f
+#endif
+		guardSameContentIdentifiers cont cids currcid
+
+	-- When copy-on-write was done, cannot check the handle that was
+	-- copied from, but such a copy should run very fast, so
+	-- it's very unlikely that the file changed after precheck,
+	-- the modified version was copied CoW, and then the file was
+	-- restored to the original content before this check.
+	postcheckcow cont = do
+		currcid <- liftIO $ mkContentIdentifier ii f
+			=<< R.getSymbolicLinkStatus f
+		guardSameContentIdentifiers cont cids currcid
+
+storeExportWithContentIdentifierM :: IgnoreInodes -> RawFilePath -> CopyCoWTried -> FilePath -> Key -> ExportLocation -> [ContentIdentifier] -> MeterUpdate -> Annex ContentIdentifier
+storeExportWithContentIdentifierM ii dir cow src _k loc overwritablecids p = do
+	liftIO $ createDirectoryUnder [dir] (toRawFilePath destdir)
+	withTmpFileIn destdir template $ \tmpf tmph -> do
+		liftIO $ hClose tmph
+		void $ liftIO $ fileCopier cow src tmpf p Nothing
+		let tmpf' = toRawFilePath tmpf
+		resetAnnexFilePerm tmpf'
+		liftIO (R.getSymbolicLinkStatus tmpf') >>= liftIO . mkContentIdentifier ii tmpf' >>= \case
+			Nothing -> giveup "unable to generate content identifier"
+			Just newcid -> do
+				checkExportContent ii dir loc
+					overwritablecids
+					(giveup "unsafe to overwrite file")
+					(const $ liftIO $ R.rename tmpf' dest)
+				return newcid
+  where
+	dest = exportPath dir loc
+	(destdir, base) = splitFileName (fromRawFilePath dest)
+	template = relatedTemplate (base ++ ".tmp")
+
+removeExportWithContentIdentifierM :: IgnoreInodes -> RawFilePath -> Key -> ExportLocation -> [ContentIdentifier] -> Annex ()
+removeExportWithContentIdentifierM ii dir k loc removeablecids =
+	checkExportContent ii dir loc removeablecids (giveup "unsafe to remove modified file") $ \case
+		DoesNotExist -> return ()
+		KnownContentIdentifier -> removeExportM dir k loc
+
+checkPresentExportWithContentIdentifierM :: IgnoreInodes -> RawFilePath -> Key -> ExportLocation -> [ContentIdentifier] -> Annex Bool
+checkPresentExportWithContentIdentifierM ii dir _k loc knowncids =
+	checkPresentGeneric' dir $
+		checkExportContent ii dir loc knowncids (return False) $ \case
+			DoesNotExist -> return False
+			KnownContentIdentifier -> return True
+
+data CheckResult = DoesNotExist | KnownContentIdentifier
+
+-- Checks if the content at an ExportLocation is in the knowncids,
+-- and only runs the callback that modifies it if it's safe to do so.
+--
+-- This should avoid races to the extent possible. However,
+-- if something has the file open for write, it could write to the handle
+-- after the callback has overwritten or deleted it, and its write would
+-- be lost, and we don't need to detect that.
+-- (In similar situations, git doesn't either!) 
+--
+-- It follows that if something is written to the destination file
+-- shortly before, it's acceptable to run the callback anyway, as that's
+-- nearly indistinguishable from the above case.
+--
+-- So, it suffices to check if the destination file's current
+-- content is known, and immediately run the callback.
+checkExportContent :: IgnoreInodes -> RawFilePath -> ExportLocation -> [ContentIdentifier] -> Annex a -> (CheckResult -> Annex a) -> Annex a
+checkExportContent ii dir loc knowncids unsafe callback = 
+	tryWhenExists (liftIO $ R.getSymbolicLinkStatus dest) >>= \case
+		Just destst
+			| not (isRegularFile destst) -> unsafe
+			| otherwise -> catchDefaultIO Nothing (liftIO $ mkContentIdentifier ii dest destst) >>= \case
+				Just destcid
+					| destcid `elem` knowncids -> callback KnownContentIdentifier
+					-- dest exists with other content
+					| otherwise -> unsafe
+				-- should never happen
+				Nothing -> unsafe
+		-- dest does not exist
+		Nothing -> callback DoesNotExist
+  where
+	dest = exportPath dir loc
diff --git a/Remote/Directory/LegacyChunked.hs b/Remote/Directory/LegacyChunked.hs
new file mode 100644
index 0000000000..fe1065d76c
--- /dev/null
+++ b/Remote/Directory/LegacyChunked.hs
@@ -0,0 +1,126 @@
+{- Legacy chunksize support for directory special remote.
+ -
+ - Can be removed eventually.
+ -
+ - Copyright 2011-2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE RankNTypes #-}
+
+module Remote.Directory.LegacyChunked where
+
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString as S
+import qualified System.FilePath.ByteString as P
+
+import Annex.Common
+import Utility.FileMode
+import Remote.Helper.Special
+import qualified Remote.Helper.Chunked.Legacy as Legacy
+import Annex.Tmp
+import Utility.Metered
+import Utility.Directory.Create
+import qualified Utility.RawFilePath as R
+
+withCheckedFiles :: (FilePath -> IO Bool) -> FilePath -> (FilePath -> Key -> [FilePath]) -> Key -> ([FilePath] -> IO Bool) -> IO Bool
+withCheckedFiles _ [] _locations _ _ = return False
+withCheckedFiles check d locations k a = go $ locations d k
+  where
+	go [] = return False
+	go (f:fs) = do
+		let chunkcount = f ++ Legacy.chunkCount
+		ifM (check chunkcount)
+			( do
+				chunks <- Legacy.listChunks f <$> readFile chunkcount
+				ifM (allM check chunks)
+					( a chunks , return False )
+			, do
+				chunks <- Legacy.probeChunks f check
+				if null chunks
+					then go fs
+					else a chunks
+			)
+withStoredFiles :: FilePath -> (FilePath -> Key -> [FilePath]) -> Key -> ([FilePath] -> IO Bool) -> IO Bool
+withStoredFiles = withCheckedFiles doesFileExist
+
+{- Splits a ByteString into chunks and writes to dests, obeying configured
+ - chunk size (not to be confused with the L.ByteString chunk size). -}
+storeLegacyChunked :: MeterUpdate -> ChunkSize -> [FilePath] -> L.ByteString -> IO [FilePath]
+storeLegacyChunked _ _ [] _ = error "bad storeLegacyChunked call"
+storeLegacyChunked meterupdate chunksize alldests@(firstdest:_) b
+	| L.null b = do
+		-- always write at least one file, even for empty
+		L.writeFile firstdest b
+		return [firstdest]
+	| otherwise = storeLegacyChunked' meterupdate chunksize alldests (L.toChunks b) []
+storeLegacyChunked' :: MeterUpdate -> ChunkSize -> [FilePath] -> [S.ByteString] -> [FilePath] -> IO [FilePath]
+storeLegacyChunked' _ _ [] _ _ = error "ran out of dests"
+storeLegacyChunked' _ _  _ [] c = return $ reverse c
+storeLegacyChunked' meterupdate chunksize (d:dests) bs c = do
+	bs' <- withFile d WriteMode $
+		feed zeroBytesProcessed chunksize bs
+	storeLegacyChunked' meterupdate chunksize dests bs' (d:c)
+  where
+	feed _ _ [] _ = return []
+	feed bytes sz (l:ls) h = do
+		let len = S.length l
+		let s = fromIntegral len
+		if s <= sz || sz == chunksize
+			then do
+				S.hPut h l
+				let bytes' = addBytesProcessed bytes len
+				meterupdate bytes'
+				feed bytes' (sz - s) ls h
+			else return (l:ls)
+
+storeHelper :: FilePath -> (RawFilePath -> RawFilePath -> IO ()) -> Key -> ([FilePath] -> IO [FilePath]) -> FilePath -> FilePath -> IO ()
+storeHelper repotop finalizer key storer tmpdir destdir = do
+	void $ liftIO $ tryIO $ createDirectoryUnder
+		[toRawFilePath repotop]
+		(toRawFilePath tmpdir)
+	Legacy.storeChunks key tmpdir destdir storer recorder (legacyFinalizer finalizer)
+  where
+	recorder f s = do
+		let f' = toRawFilePath f
+		void $ tryIO $ allowWrite f'
+		writeFile f s
+		void $ tryIO $ preventWrite f'
+
+store :: FilePath -> ChunkSize -> (RawFilePath -> RawFilePath -> IO ()) -> Key -> L.ByteString -> MeterUpdate -> FilePath -> FilePath -> IO ()
+store repotop chunksize finalizer k b p = storeHelper repotop finalizer k $ \dests ->
+	storeLegacyChunked p chunksize dests b
+
+{- Need to get a single ByteString containing every chunk.
+ - Done very innefficiently, by writing to a temp file.
+ - :/ This is legacy code..
+ -}
+retrieve :: (RawFilePath -> Key -> [RawFilePath]) -> RawFilePath -> Retriever
+retrieve locations d basek p miv c = withOtherTmp $ \tmpdir -> do
+	showLongNote "This remote uses the deprecated chunksize setting. So this will be quite slow."
+	let tmp = tmpdir P.</> keyFile basek <> ".directorylegacy.tmp"
+	let tmp' = fromRawFilePath tmp
+	let go = \k sink -> do
+		liftIO $ void $ withStoredFiles (fromRawFilePath d) (legacyLocations locations) k $ \fs -> do
+			forM_ fs $
+				S.appendFile tmp' <=< S.readFile
+			return True
+		b <- liftIO $ L.readFile tmp'
+		liftIO $ removeWhenExistsWith R.removeLink tmp
+		sink b
+	byteRetriever go basek p miv c
+
+checkKey :: RawFilePath -> (RawFilePath -> Key -> [RawFilePath]) -> Key -> Annex Bool
+checkKey d locations k = liftIO $
+	withStoredFiles (fromRawFilePath d) (legacyLocations locations) k $
+		-- withStoredFiles checked that it exists
+		const $ return True
+
+legacyFinalizer :: (RawFilePath -> RawFilePath -> IO ()) -> (FilePath -> FilePath -> IO ())
+legacyFinalizer f = \a b -> f (toRawFilePath a) (toRawFilePath b)
+
+legacyLocations :: (RawFilePath -> Key -> [RawFilePath]) -> (FilePath -> Key -> [FilePath])
+legacyLocations locations = \f k ->
+	map fromRawFilePath $ locations (toRawFilePath f) k
diff --git a/Remote/External.hs b/Remote/External.hs
new file mode 100644
index 0000000000..e4ac597289
--- /dev/null
+++ b/Remote/External.hs
@@ -0,0 +1,929 @@
+{- External special remote interface.
+ -
+ - Copyright 2013-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE BangPatterns #-}
+{-# LANGUAGE RankNTypes #-}
+
+module Remote.External where
+
+import Remote.External.Types
+import Remote.External.AsyncExtension
+import qualified Annex
+import Annex.Common
+import qualified Annex.ExternalAddonProcess as AddonProcess
+import Types.Remote
+import Types.Export
+import Types.CleanupActions
+import Types.UrlContents
+import Types.ProposedAccepted
+import qualified Git
+import Config
+import Git.Config (boolConfig)
+import Annex.SpecialRemote.Config
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import Remote.Helper.ReadOnly
+import Utility.Metered
+import Types.Transfer
+import Logs.PreferredContent.Raw
+import Logs.RemoteState
+import Logs.Web
+import Config.Cost
+import Annex.Content
+import Annex.Url
+import Annex.UUID
+import Annex.Verify
+import Creds
+
+import Control.Concurrent.STM
+import qualified Data.Map as M
+import qualified Data.Set as S
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "external"
+	, enumerate = const (findSpecialRemotes "externaltype")
+	, generate = gen remote Nothing
+	, configParser = remoteConfigParser Nothing
+	, setup = externalSetup Nothing Nothing
+	, exportSupported = checkExportSupported Nothing
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+externaltypeField :: RemoteConfigField
+externaltypeField = Accepted "externaltype"
+
+readonlyField :: RemoteConfigField
+readonlyField = Accepted "readonly"
+
+gen :: RemoteType -> Maybe ExternalProgram -> Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen rt externalprogram r u rc gc rs
+	-- readonly mode only downloads urls; does not use external program
+	| externalprogram' == ExternalType "readonly" = do
+		c <- parsedRemoteConfig remote rc
+		cst <- remoteCost gc c expensiveRemoteCost
+		let rmt = mk c cst (pure GloballyAvailable)
+			Nothing
+			(externalInfo externalprogram')
+			Nothing
+			Nothing
+			exportUnsupported
+			exportUnsupported
+		return $ Just $ specialRemote c
+			readonlyStorer
+			retrieveUrl
+			readonlyRemoveKey
+			checkKeyUrl
+			rmt
+	| otherwise = do
+		c <- parsedRemoteConfig remote rc
+		external <- newExternal externalprogram' (Just u) c (Just gc)
+			(Git.remoteName r) (Just rs)
+		Annex.addCleanupAction (RemoteCleanup u) $ stopExternal external
+		cst <- getCost external r gc c
+		exportsupported <- if exportTree c
+			then checkExportSupported' external
+			else return False
+		let exportactions = if exportsupported
+			then ExportActions
+				{ storeExport = storeExportM external
+				, retrieveExport = retrieveExportM external
+				, removeExport = removeExportM external
+				, versionedExport = False
+				, checkPresentExport = checkPresentExportM external
+				, removeExportDirectory = Just $ removeExportDirectoryM external
+				, renameExport = Just $ renameExportM external
+				}
+			else exportUnsupported
+		-- Cheap exportSupported that replaces the expensive
+		-- checkExportSupported now that we've already checked it.
+		let cheapexportsupported = if exportsupported
+			then exportIsSupported
+			else exportUnsupported
+		let rmt = mk c cst (getAvailability external)
+			(Just (whereisKeyM external))
+			(getInfoM external)
+			(Just (claimUrlM external))
+			(Just (checkUrlM external))
+			exportactions
+			cheapexportsupported
+		return $ Just $ specialRemote c
+			(storeKeyM external)
+			(retrieveKeyFileM external)
+			(removeKeyM external)
+			(checkPresentM external)
+			rmt
+  where
+	mk c cst avail towhereis togetinfo toclaimurl tocheckurl exportactions cheapexportsupported =
+		Remote
+			{ uuid = u
+			, cost = cst
+			, name = Git.repoDescribe r
+			, storeKey = storeKeyDummy
+			, retrieveKeyFile = retrieveKeyFileDummy
+			, retrieveKeyFileCheap = Nothing
+			-- External special remotes use many http libraries
+			-- and have no protection against redirects to
+			-- local private web servers, or in some cases
+			-- to file:// urls.
+			, retrievalSecurityPolicy = mkRetrievalVerifiableKeysSecure gc
+			, removeKey = removeKeyDummy
+			, lockContent = Nothing
+			, checkPresent = checkPresentDummy
+			, checkPresentCheap = False
+			, exportActions = exportactions
+			, importActions = importUnsupported
+			, whereisKey = towhereis
+			, remoteFsck = Nothing
+			, repairRepo = Nothing
+			, config = c
+			, localpath = Nothing
+			, getRepo = return r
+			, gitconfig = gc
+			, readonly = False
+			, appendonly = False
+			, untrustworthy = False
+			, availability = avail
+			, remotetype = rt 
+				{ exportSupported = cheapexportsupported }
+			, mkUnavailable =
+				let dneprogram = case externalprogram of
+					Just (ExternalCommand _ _) -> Just (ExternalType "!dne!")
+					_ -> Nothing
+				    dnegc = gc { remoteAnnexExternalType = Just "!dne!" }
+				in gen rt dneprogram r u rc dnegc rs
+			, getInfo = togetinfo
+			, claimUrl = toclaimurl
+			, checkUrl = tocheckurl
+			, remoteStateHandle = rs
+			}
+	externalprogram' = case externalprogram of
+		Just p -> p
+		Nothing -> ExternalType $ 
+			fromMaybe (giveup "missing externaltype")
+				(remoteAnnexExternalType gc)
+
+externalSetup :: Maybe ExternalProgram -> Maybe (String, String) -> SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+externalSetup externalprogram setgitconfig _ mu _ c gc = do
+	u <- maybe (liftIO genUUID) return mu
+	pc <- either giveup return $ parseRemoteConfig c (lenientRemoteConfigParser externalprogram)
+	let readonlyconfig = getRemoteConfigValue readonlyField pc == Just True
+	let externaltype = if readonlyconfig
+		then "readonly"
+		else fromMaybe (giveup "Specify externaltype=") $
+			getRemoteConfigValue externaltypeField pc
+	(c', _encsetup) <- encryptionSetup c gc
+
+	c'' <- if readonlyconfig
+		then do
+			-- Setting annex-readonly is not really necessary
+			-- anymore, but older versions of git-annex used
+			-- this, not externaltype=readonly, so still set
+			-- it.
+			setConfig (remoteAnnexConfig (fromJust (lookupName c)) "readonly") (boolConfig True)
+			return c'
+		else do
+			pc' <- either giveup return $ parseRemoteConfig c' (lenientRemoteConfigParser externalprogram)
+			let p = fromMaybe (ExternalType externaltype) externalprogram
+			external <- newExternal p (Just u) pc' (Just gc) Nothing Nothing
+			-- Now that we have an external, ask it to LISTCONFIGS, 
+			-- and re-parse the RemoteConfig strictly, so we can
+			-- error out if the user provided an unexpected config.
+			_ <- either giveup return . parseRemoteConfig c' 
+				=<< strictRemoteConfigParser external
+			handleRequest external INITREMOTE Nothing $ \case
+				INITREMOTE_SUCCESS -> result ()
+				INITREMOTE_FAILURE errmsg -> Just $ giveup $
+					respErrorMessage "INITREMOTE" errmsg
+				_ -> Nothing
+			-- Any config changes the external made before
+			-- responding to INITREMOTE need to be applied to
+			-- the RemoteConfig.
+			changes <- withExternalState external $
+				liftIO . atomically . readTMVar . externalConfigChanges
+			return (changes c')
+
+	gitConfigSpecialRemote u c''
+		[ fromMaybe ("externaltype", externaltype) setgitconfig ]
+	return (M.delete readonlyField c'', u)
+
+checkExportSupported :: Maybe ExternalProgram -> ParsedRemoteConfig -> RemoteGitConfig -> Annex Bool
+checkExportSupported Nothing c gc = do
+	let externaltype = fromMaybe (giveup "Specify externaltype=") $
+		remoteAnnexExternalType gc <|> getRemoteConfigValue externaltypeField c
+	if externaltype == "readonly"
+		then return False
+		else checkExportSupported (Just (ExternalType externaltype)) c gc
+checkExportSupported (Just externalprogram) c gc = 
+	checkExportSupported' 
+		=<< newExternal externalprogram Nothing c (Just gc) Nothing Nothing
+
+checkExportSupported' :: External -> Annex Bool
+checkExportSupported' external = go `catchNonAsync` (const (return False))
+  where
+	go = handleRequest external EXPORTSUPPORTED Nothing $ \resp -> case resp of
+		EXPORTSUPPORTED_SUCCESS -> result True
+		EXPORTSUPPORTED_FAILURE -> result False
+		UNSUPPORTED_REQUEST -> result False
+		_ -> Nothing
+
+storeKeyM :: External -> Storer
+storeKeyM external = fileStorer $ \k f p ->
+	either giveup return =<< go k f p
+  where
+	go k f p = handleRequestKey external (\sk -> TRANSFER Upload sk f) k (Just p) $ \resp ->
+		case resp of
+			TRANSFER_SUCCESS Upload k' | k == k' ->
+				result (Right ())
+			TRANSFER_FAILURE Upload k' errmsg | k == k' ->
+				result (Left (respErrorMessage "TRANSFER" errmsg))
+			_ -> Nothing
+
+retrieveKeyFileM :: External -> Retriever
+retrieveKeyFileM external = fileRetriever $ \d k p ->
+	either giveup return =<< watchFileSize d p (go d k)
+  where
+	go d k p = handleRequestKey external (\sk -> TRANSFER Download sk (fromRawFilePath d)) k (Just p) $ \resp ->
+		case resp of
+			TRANSFER_SUCCESS Download k'
+				| k == k' -> result $ Right ()
+			TRANSFER_FAILURE Download k' errmsg
+				| k == k' -> result $ Left $
+					respErrorMessage "TRANSFER" errmsg
+			_ -> Nothing
+
+removeKeyM :: External -> Remover
+removeKeyM external k = either giveup return =<< go
+  where
+	go = handleRequestKey external REMOVE k Nothing $ \resp ->
+		case resp of
+			REMOVE_SUCCESS k'
+				| k == k' -> result $ Right ()
+			REMOVE_FAILURE k' errmsg
+				| k == k' -> result $ Left $
+					respErrorMessage "REMOVE" errmsg
+			_ -> Nothing
+
+checkPresentM :: External -> CheckPresent
+checkPresentM external k = either giveup id <$> go
+  where
+	go = handleRequestKey external CHECKPRESENT k Nothing $ \resp ->
+		case resp of
+			CHECKPRESENT_SUCCESS k'
+				| k' == k -> result $ Right True
+			CHECKPRESENT_FAILURE k'
+				| k' == k -> result $ Right False
+			CHECKPRESENT_UNKNOWN k' errmsg
+				| k' == k -> result $ Left $
+					respErrorMessage "CHECKPRESENT" errmsg
+			_ -> Nothing
+
+whereisKeyM :: External -> Key -> Annex [String]
+whereisKeyM external k = handleRequestKey external WHEREIS k Nothing $ \resp -> case resp of
+	WHEREIS_SUCCESS s -> result [s]
+	WHEREIS_FAILURE -> result []
+	UNSUPPORTED_REQUEST -> result []
+	_ -> Nothing
+
+storeExportM :: External -> FilePath -> Key -> ExportLocation -> MeterUpdate -> Annex ()
+storeExportM external f k loc p = either giveup return =<< go
+  where
+	go = handleRequestExport external loc req k (Just p) $ \resp -> case resp of
+		TRANSFER_SUCCESS Upload k' | k == k' -> result $ Right ()
+		TRANSFER_FAILURE Upload k' errmsg | k == k' ->
+			result $ Left $ respErrorMessage "TRANSFER" errmsg
+		UNSUPPORTED_REQUEST -> 
+			result $ Left "TRANSFEREXPORT not implemented by external special remote"
+		_ -> Nothing
+	req sk = TRANSFEREXPORT Upload sk f
+
+retrieveExportM :: External -> Key -> ExportLocation -> FilePath -> MeterUpdate -> Annex Verification
+retrieveExportM external k loc dest p = do
+	verifyKeyContentIncrementally AlwaysVerify k $ \iv ->
+		tailVerify iv (toRawFilePath dest) $
+			either giveup return =<< go
+  where
+	go = handleRequestExport external loc req k (Just p) $ \resp -> case resp of
+		TRANSFER_SUCCESS Download k'
+			| k == k' -> result $ Right ()
+		TRANSFER_FAILURE Download k' errmsg
+			| k == k' -> result $ Left $ respErrorMessage "TRANSFER" errmsg
+		UNSUPPORTED_REQUEST ->
+			result $ Left "TRANSFEREXPORT not implemented by external special remote"
+		_ -> Nothing
+	req sk = TRANSFEREXPORT Download sk dest
+
+checkPresentExportM :: External -> Key -> ExportLocation -> Annex Bool
+checkPresentExportM external k loc = either giveup id <$> go
+  where
+	go = handleRequestExport external loc CHECKPRESENTEXPORT k Nothing $ \resp -> case resp of
+		CHECKPRESENT_SUCCESS k'
+			| k' == k -> result $ Right True
+		CHECKPRESENT_FAILURE k'
+			| k' == k -> result $ Right False
+		CHECKPRESENT_UNKNOWN k' errmsg
+			| k' == k -> result $ Left $
+				respErrorMessage "CHECKPRESENT" errmsg
+		UNSUPPORTED_REQUEST -> result $
+			Left "CHECKPRESENTEXPORT not implemented by external special remote"
+		_ -> Nothing
+
+removeExportM :: External -> Key -> ExportLocation -> Annex ()
+removeExportM external k loc = either giveup return =<< go
+  where
+	go = handleRequestExport external loc REMOVEEXPORT k Nothing $ \resp -> case resp of
+		REMOVE_SUCCESS k'
+			| k == k' -> result $ Right ()
+		REMOVE_FAILURE k' errmsg
+			| k == k' -> result $ Left $ respErrorMessage "REMOVE" errmsg
+		UNSUPPORTED_REQUEST -> result $
+			Left $ "REMOVEEXPORT not implemented by external special remote"
+		_ -> Nothing
+
+removeExportDirectoryM :: External -> ExportDirectory -> Annex ()
+removeExportDirectoryM external dir = either giveup return =<< go
+  where
+	go = handleRequest external req Nothing $ \resp -> case resp of
+		REMOVEEXPORTDIRECTORY_SUCCESS -> result $ Right ()
+		REMOVEEXPORTDIRECTORY_FAILURE -> result $
+			Left "failed to remove directory"
+		UNSUPPORTED_REQUEST -> result $ Right ()
+		_ -> Nothing
+	req = REMOVEEXPORTDIRECTORY dir
+
+renameExportM :: External -> Key -> ExportLocation -> ExportLocation -> Annex (Maybe ())
+renameExportM external k src dest = either giveup return =<< go
+  where
+	go = handleRequestExport external src req k Nothing $ \resp -> case resp of
+		RENAMEEXPORT_SUCCESS k'
+			| k' == k -> result $ Right (Just ())
+		RENAMEEXPORT_FAILURE k' 
+			| k' == k -> result $ Left "failed to rename exported file"
+		UNSUPPORTED_REQUEST -> result (Right Nothing)
+		_ -> Nothing
+	req sk = RENAMEEXPORT sk dest
+
+{- Sends a Request to the external remote, and waits for it to generate
+ - a Response. That is fed into the responsehandler, which should return
+ - the action to run for it (or Nothing if there's a protocol error).
+ -
+ - While the external remote is processing the Request, it may send
+ - any number of RemoteRequests, that are handled here.
+ -
+ - An external remote process can only handle one request at a time.
+ - Concurrent requests will start up additional processes.
+ -
+ - May throw exceptions, for example on protocol errors, or
+ - when the repository cannot be used.
+ -}
+handleRequest :: External -> Request -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
+handleRequest external req mp responsehandler = 
+	withExternalState external $ \st -> 
+		handleRequest' st external req mp responsehandler
+
+handleRequestKey :: External -> (SafeKey -> Request) -> Key -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
+handleRequestKey external mkreq k mp responsehandler = 
+	withSafeKey k $ \sk -> handleRequest external (mkreq sk) mp responsehandler
+
+withSafeKey :: Key -> (SafeKey -> Annex a) -> Annex a
+withSafeKey k a = case mkSafeKey k of
+	Right sk -> a sk
+	Left e -> giveup e
+
+{- Export location is first sent in an EXPORT message before
+ - the main request. This is done because the ExportLocation can
+ - contain spaces etc. -}
+handleRequestExport :: External -> ExportLocation -> (SafeKey -> Request) -> Key -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
+handleRequestExport external loc mkreq k mp responsehandler = 
+	withSafeKey k $ \sk ->
+		-- Both the EXPORT and subsequent request must be sent to the
+		-- same external process, so run both with the same external
+		-- state.
+		withExternalState external $ \st -> do
+			checkPrepared st external
+			sendMessage st (EXPORT loc)
+			handleRequest' st external (mkreq sk) mp responsehandler
+
+handleRequest' :: ExternalState -> External -> Request -> Maybe MeterUpdate -> ResponseHandler a -> Annex a
+handleRequest' st external req mp responsehandler
+	| needsPREPARE req = do
+		checkPrepared st external
+		go
+	| otherwise = go
+  where
+	go = do
+		sendMessage st req
+		loop
+	loop = receiveMessage st external responsehandler
+		(\rreq -> Just $ handleRemoteRequest rreq >> loop)
+		(\msg -> Just $ handleExceptionalMessage msg >> loop)
+
+	handleRemoteRequest (PROGRESS bytesprocessed) =
+		maybe noop (\a -> liftIO $ a bytesprocessed) mp
+	handleRemoteRequest (DIRHASH k) = 
+		send $ VALUE $ fromRawFilePath $ hashDirMixed def k
+	handleRemoteRequest (DIRHASH_LOWER k) = 
+		send $ VALUE $ fromRawFilePath $ hashDirLower def k
+	handleRemoteRequest (SETCONFIG setting value) =
+		liftIO $ atomically $ do
+			ParsedRemoteConfig m c <- takeTMVar (externalConfig st)
+			let !m' = M.insert
+				(Accepted setting)
+				(RemoteConfigValue (PassedThrough value))
+				m
+			let !c' = M.insert
+			    	(Accepted setting)
+				(Accepted value)
+				c
+			putTMVar (externalConfig st) (ParsedRemoteConfig m' c')
+			f <- takeTMVar (externalConfigChanges st)
+			let !f' = M.insert (Accepted setting) (Accepted value) . f
+			putTMVar (externalConfigChanges st) f'
+	handleRemoteRequest (GETCONFIG setting) = do
+		value <- maybe "" fromProposedAccepted
+			. (M.lookup (Accepted setting))
+			. unparsedRemoteConfig
+			<$> liftIO (atomically $ readTMVar $ externalConfig st)
+		send $ VALUE value
+	handleRemoteRequest (SETCREDS setting login password) = case (externalUUID external, externalGitConfig external) of
+		(Just u, Just gc) -> do
+			pc <- liftIO $ atomically $ takeTMVar (externalConfig st)
+			pc' <- setRemoteCredPair' pc encryptionAlreadySetup gc
+				(credstorage setting u)
+				(Just (login, password))
+			let configchanges = M.differenceWithKey
+				(\_k a b -> if a == b then Nothing else Just a)
+				(unparsedRemoteConfig pc')
+				(unparsedRemoteConfig pc)
+			void $ liftIO $ atomically $ do
+				putTMVar (externalConfig st) pc'
+				f <- takeTMVar (externalConfigChanges st)
+				let !f' = M.union configchanges . f
+				putTMVar (externalConfigChanges st) f'
+		_ -> senderror "cannot send SETCREDS here"
+	handleRemoteRequest (GETCREDS setting) = case (externalUUID external, externalGitConfig external) of
+		(Just u, Just gc) -> do
+			c <- liftIO $ atomically $ readTMVar $ externalConfig st
+			creds <- fromMaybe ("", "") <$> 
+				getRemoteCredPair c gc (credstorage setting u)
+			send $ CREDS (fst creds) (snd creds)
+		_ -> senderror "cannot send GETCREDS here"
+	handleRemoteRequest GETUUID = case externalUUID external of
+		Just u -> send $ VALUE $ fromUUID u
+		Nothing -> senderror "cannot send GETUUID here"
+	handleRemoteRequest GETGITDIR = 
+		send . VALUE . fromRawFilePath =<< fromRepo Git.localGitDir
+	handleRemoteRequest GETGITREMOTENAME =
+		case externalRemoteName external of
+			Just n -> send $ VALUE n
+			Nothing -> senderror "git remote name not known"
+	handleRemoteRequest (SETWANTED expr) = case externalUUID external of
+		Just u -> preferredContentSet u expr
+		Nothing -> senderror "cannot send SETWANTED here"
+	handleRemoteRequest GETWANTED = case externalUUID external of
+		Just u -> do
+			expr <- fromMaybe "" . M.lookup u
+				<$> preferredContentMapRaw
+			send $ VALUE expr
+		Nothing -> senderror "cannot send GETWANTED here"
+	handleRemoteRequest (SETSTATE key state) =
+		case externalRemoteStateHandle external of
+			Just h -> setRemoteState h key state
+			Nothing -> senderror "cannot send SETSTATE here"
+	handleRemoteRequest (GETSTATE key) =
+		case externalRemoteStateHandle external of
+			Just h -> do
+				state <- fromMaybe ""
+					<$> getRemoteState h key
+				send $ VALUE state
+			Nothing -> senderror "cannot send GETSTATE here"
+	handleRemoteRequest (SETURLPRESENT key url) =
+		setUrlPresent key url
+	handleRemoteRequest (SETURLMISSING key url) =
+		setUrlMissing key url
+	handleRemoteRequest (SETURIPRESENT key uri) =
+		withurl (SETURLPRESENT key) uri
+	handleRemoteRequest (SETURIMISSING key uri) =
+		withurl (SETURLMISSING key) uri
+	handleRemoteRequest (GETURLS key prefix) = do
+		mapM_ (send . VALUE) =<< getUrlsWithPrefix key prefix
+		send (VALUE "") -- end of list
+	handleRemoteRequest (DEBUG msg) = fastDebug "Remote.External" msg
+	handleRemoteRequest (INFO msg) = showInfo (UnquotedString msg)
+	handleRemoteRequest (VERSION _) = senderror "too late to send VERSION"
+
+	handleExceptionalMessage (ERROR err) = giveup $ "external special remote error: " ++ err
+
+	send = sendMessage st
+	senderror = sendMessage st . ERROR 
+
+	credstorage setting u = CredPairStorage
+		{ credPairFile = base
+		, credPairEnvironment = (base ++ "login", base ++ "password")
+		, credPairRemoteField = Accepted setting
+		}
+	  where
+		base = replace "/" "_" $ fromUUID u ++ "-" ++ setting
+			
+	withurl mk uri = handleRemoteRequest $ mk $
+		setDownloader (show uri) OtherDownloader
+
+sendMessage :: (Sendable m, ToAsyncWrapped m) => ExternalState -> m -> Annex ()
+sendMessage st m = liftIO $ externalSend st m
+
+sendMessageAddonProcess :: Sendable m => AddonProcess.ExternalAddonProcess -> m -> IO ()
+sendMessageAddonProcess p m = do
+	AddonProcess.protocolDebug p True line
+	hPutStrLn h line
+	hFlush h
+  where
+	h = AddonProcess.externalSend p
+	line = unwords $ formatMessage m
+
+receiveMessageAddonProcess :: AddonProcess.ExternalAddonProcess -> IO (Maybe String)
+receiveMessageAddonProcess p = do
+	v <- catchMaybeIO $ hGetLine $ AddonProcess.externalReceive p
+	maybe noop (AddonProcess.protocolDebug p False) v
+	return v
+
+shutdownAddonProcess :: AddonProcess.ExternalAddonProcess -> Bool -> IO ()
+shutdownAddonProcess = AddonProcess.externalShutdown 
+
+{- A response handler can yield a result, or it can request that another
+ - message be consumed from the external. -}
+data ResponseHandlerResult a
+	= Result a
+	| GetNextMessage (ResponseHandler a)
+
+type ResponseHandler a = Response -> Maybe (Annex (ResponseHandlerResult a))
+
+result :: a -> Maybe (Annex (ResponseHandlerResult a))
+result = Just . return . Result
+
+{- Waits for a message from the external remote, and passes it to the
+ - appropriate handler. 
+ -
+ - If the handler returns Nothing, this is a protocol error.-}
+receiveMessage
+	:: ExternalState
+	-> External 
+	-> ResponseHandler a
+	-> (RemoteRequest -> Maybe (Annex a))
+	-> (ExceptionalMessage -> Maybe (Annex a))
+	-> Annex a
+receiveMessage st external handleresponse handlerequest handleexceptional =
+	go =<< liftIO (externalReceive st)
+  where
+	go Nothing = protocolError False "<EOF>"
+	go (Just s) = case parseMessage s :: Maybe Response of
+		Just resp -> case handleresponse resp of
+			Nothing -> protocolError True s
+			Just callback -> callback >>= \case
+				Result a -> return a
+				GetNextMessage handleresponse' ->
+					receiveMessage st external handleresponse' handlerequest handleexceptional
+		Nothing -> case parseMessage s :: Maybe RemoteRequest of
+			Just req -> maybe (protocolError True s) id (handlerequest req)
+			Nothing -> case parseMessage s :: Maybe ExceptionalMessage of
+				Just msg -> maybe (protocolError True s) id (handleexceptional msg)
+				Nothing -> protocolError False s
+	protocolError parsed s = do
+		warning $ UnquotedString $ "external special remote protocol error, unexpectedly received \"" ++ s ++ "\" " ++
+			if parsed
+				then "(command not allowed at this time)"
+				else "(unable to parse command)"
+		giveup "unable to use special remote due to protocol error"
+
+{- While the action is running, the ExternalState provided to it will not
+ - be available to any other calls.
+ -
+ - Starts up a new process if no ExternalStates are available.
+ -
+ - If the action is interrupted by an async exception, the external process
+ - is in an unknown state, and may eg be still performing a transfer. So it
+ - is killed. The action should not normally throw any exception itself,
+ - unless perhaps there's a problem communicating with the external
+ - process.
+ -}
+withExternalState :: External -> (ExternalState -> Annex a) -> Annex a
+withExternalState external a = do
+	st <- get
+	r <- a st `onException` liftIO (externalShutdown st True)
+	put st -- only when no exception is thrown
+	return r
+  where
+	v = externalState external
+
+	get = do
+		ms <- liftIO $ atomically $ do
+			l <- readTVar v
+			case l of
+				[] -> return Nothing
+				(st:rest) -> do
+					writeTVar v rest
+					return (Just st)
+		maybe (startExternal external) return ms
+	
+	put st = liftIO $ atomically $ modifyTVar' v (st:)
+
+{- Starts an external remote process running, and checks VERSION and
+ - exchanges EXTENSIONS.
+ -
+ - When the ASYNC extension is negotiated, a single process is used,
+ - and this constructs a external state that communicates with a thread
+ - that relays to it.
+ -}
+startExternal :: External -> Annex ExternalState
+startExternal external =
+	liftIO (atomically $ takeTMVar (externalAsync external)) >>= \case
+		UncheckedExternalAsync -> do
+			(st, extensions) <- startExternal' external
+				`onException` store UncheckedExternalAsync
+			if asyncExtensionEnabled extensions
+				then do
+					annexrunner <- Annex.makeRunner
+					relay <- liftIO $ runRelayToExternalAsync external st annexrunner
+					st' <- liftIO $ asyncRelayExternalState relay
+					store (ExternalAsync relay)
+					return st'
+				else do
+					store NoExternalAsync
+					return st
+		v@NoExternalAsync -> do
+			store v
+			fst <$> startExternal' external
+		v@(ExternalAsync relay) -> do
+			store v
+			liftIO $ asyncRelayExternalState relay
+  where
+	store = liftIO . atomically . putTMVar (externalAsync external)
+
+startExternal' :: External -> Annex (ExternalState, ExtensionList)
+startExternal' external = do
+	pid <- liftIO $ atomically $ do
+		n <- succ <$> readTVar (externalLastPid external)
+		writeTVar (externalLastPid external) n
+		return n
+	AddonProcess.startExternalAddonProcess externalcmd externalparams pid >>= \case
+		Left (AddonProcess.ProgramFailure err) -> do
+			unusable err
+		Left (AddonProcess.ProgramNotInstalled err) ->
+			case (lookupName (unparsedRemoteConfig (externalDefaultConfig external)), remoteAnnexReadOnly <$> externalGitConfig external) of
+				(Just rname, Just True) -> unusable $ unlines
+					[ err
+					, "This remote has annex-readonly=true, and previous versions of"
+					, "git-annex would try to download from it without"
+					, "installing " ++ externalcmd ++ ". If you want that, you need to set:"
+					, "git config remote." ++ rname ++ ".annex-externaltype readonly"
+					]
+				_ -> unusable err
+		Right p -> do
+			cv <- liftIO $ newTMVarIO $ externalDefaultConfig external
+			ccv <- liftIO $ newTMVarIO id
+			pv <- liftIO $ newTMVarIO Unprepared
+			let st = ExternalState
+				{ externalSend = sendMessageAddonProcess p
+				, externalReceive = receiveMessageAddonProcess p
+				, externalShutdown = shutdownAddonProcess p
+				, externalPrepared = pv
+				, externalConfig = cv
+				, externalConfigChanges = ccv
+				}
+			extensions <- startproto st
+			return (st, extensions)
+  where
+	(externalcmd, externalparams) = case externalProgram external of
+		ExternalType t -> ("git-annex-remote-" ++ t, [])
+		ExternalCommand c ps -> (c, ps)
+	startproto st = do
+		receiveMessage st external
+			(const Nothing)
+			(checkVersion st)
+			(const Nothing)
+		sendMessage st (EXTENSIONS supportedExtensionList)
+		-- It responds with a EXTENSIONS_RESPONSE; that extensions
+		-- list is reserved for future expansion. UNSUPPORTED_REQUEST
+		-- is also accepted.
+		exwanted <- receiveMessage st external
+			(\resp -> case resp of
+				EXTENSIONS_RESPONSE l -> result l
+				UNSUPPORTED_REQUEST -> result mempty
+				_ -> Nothing
+			)
+			(const Nothing)
+			(const Nothing)
+		case filter (`notElem` fromExtensionList supportedExtensionList) (fromExtensionList exwanted) of
+			[] -> return exwanted
+			exrest -> unusable $ unwords $
+				[ externalcmd
+				, "requested extensions that this version of git-annex does not support:"
+				] ++ exrest
+
+	unusable msg = do
+		warning (UnquotedString msg)
+		giveup ("unable to use external special remote " ++ externalcmd)
+
+stopExternal :: External -> Annex ()
+stopExternal external = liftIO $ do
+	l <- atomically $ swapTVar (externalState external) []
+	mapM_ (flip externalShutdown False) l
+
+checkVersion :: ExternalState -> RemoteRequest -> Maybe (Annex ())
+checkVersion st (VERSION v) = Just $
+	if v `elem` supportedProtocolVersions
+		then noop
+		else sendMessage st (ERROR "unsupported VERSION")
+checkVersion _ _ = Nothing
+
+{- If repo has not been prepared, sends PREPARE.
+ -
+ - If the repo fails to prepare, or failed before, throws an exception with
+ - the error message. -}
+checkPrepared :: ExternalState -> External -> Annex ()
+checkPrepared st external = do
+	v <- liftIO $ atomically $ takeTMVar $ externalPrepared st
+	case v of
+		Prepared -> setprepared Prepared
+		FailedPrepare errmsg -> do
+			setprepared (FailedPrepare errmsg)
+			giveup errmsg
+		Unprepared ->
+			handleRequest' st external PREPARE Nothing $ \resp ->
+				case resp of
+					PREPARE_SUCCESS -> Just $ do
+						setprepared Prepared
+						return (Result ())
+					PREPARE_FAILURE errmsg -> Just $ do
+						let errmsg' = respErrorMessage "PREPARE" errmsg
+						setprepared $ FailedPrepare errmsg'
+						giveup errmsg'
+					_ -> Nothing
+  where
+	setprepared status = liftIO $ atomically $
+		putTMVar (externalPrepared st) status
+
+respErrorMessage :: String -> String -> String
+respErrorMessage req err
+	| null err = req ++ " failed with no reason given"
+	| otherwise = err
+
+{- Caches the cost in the git config to avoid needing to start up an
+ - external special remote every time time just to ask it what its
+ - cost is. -}
+getCost :: External -> Git.Repo -> RemoteGitConfig -> ParsedRemoteConfig -> Annex Cost
+getCost external r gc pc =
+	(go =<< remoteCost' gc pc) `catchNonAsync` const (pure defcst)
+  where
+	go (Just c) = return c
+	go Nothing = do
+		c <- handleRequest external GETCOST Nothing $ \req -> case req of
+			COST c -> result c
+			UNSUPPORTED_REQUEST -> result defcst
+			_ -> Nothing
+		setRemoteCost r c
+		return c
+	defcst = expensiveRemoteCost
+
+{- Most remotes do not bother to implement a reply to this request;
+ - globally available is the default.
+ -}
+getAvailability :: External -> Annex Availability
+getAvailability external = catchNonAsync query (const (pure defavail))
+  where
+	query = handleRequest external GETAVAILABILITY Nothing $ \req -> case req of
+		AVAILABILITY avail -> result avail
+		UNSUPPORTED_REQUEST -> result defavail
+		_ -> Nothing
+	defavail = GloballyAvailable
+
+claimUrlM :: External -> URLString -> Annex Bool
+claimUrlM external url =
+	handleRequest external (CLAIMURL url) Nothing $ \req -> case req of
+		CLAIMURL_SUCCESS -> result True
+		CLAIMURL_FAILURE -> result False
+		UNSUPPORTED_REQUEST -> result False
+		_ -> Nothing
+
+checkUrlM :: External -> URLString -> Annex UrlContents
+checkUrlM external url = 
+	handleRequest external (CHECKURL url) Nothing $ \req -> case req of
+		CHECKURL_CONTENTS sz f -> result $ UrlContents sz $
+			if null f then Nothing else Just f
+		CHECKURL_MULTI l -> result $ UrlMulti $ map mkmulti l
+		CHECKURL_FAILURE errmsg -> Just $ giveup $
+			respErrorMessage "CHECKURL" errmsg
+		UNSUPPORTED_REQUEST -> giveup "CHECKURL not implemented by external special remote"
+		_ -> Nothing
+  where
+	mkmulti (u, s, f) = (u, s, f)
+
+retrieveUrl :: Retriever
+retrieveUrl = fileRetriever' $ \f k p iv -> do
+	us <- getWebUrls k
+	unlessM (withUrlOptions $ downloadUrl True k p iv us (fromRawFilePath f)) $
+		giveup "failed to download content"
+
+checkKeyUrl :: CheckPresent
+checkKeyUrl k = do
+	us <- getWebUrls k
+	anyM (\u -> withUrlOptions $ checkBoth u (fromKey keySize k)) us
+
+getWebUrls :: Key -> Annex [URLString]
+getWebUrls key = filter supported <$> getUrls key
+  where
+	supported u = snd (getDownloader u) == WebDownloader
+			
+externalInfo :: ExternalProgram -> Annex [(String, String)]
+externalInfo (ExternalType et) = return [("externaltype", et)]
+externalInfo (ExternalCommand _ _) = return []
+
+getInfoM :: External -> Annex [(String, String)]
+getInfoM external = (++)
+	<$> externalInfo (externalProgram external)
+	<*> handleRequest external GETINFO Nothing (collect [])
+  where
+	collect l req = case req of
+		INFOFIELD f -> Just $ return $
+			GetNextMessage $ collectvalue l f
+		INFOEND -> result (reverse l)
+		UNSUPPORTED_REQUEST -> result []
+		_ -> Nothing
+	
+	collectvalue l f req = case req of
+		INFOVALUE v -> Just $ return $
+			GetNextMessage $ collect ((f, v) : l)
+		_ -> Nothing
+
+{- All unknown configs are passed through in case the external program
+ - uses them. -}
+lenientRemoteConfigParser :: Maybe ExternalProgram -> RemoteConfigParser
+lenientRemoteConfigParser externalprogram =
+	addRemoteConfigParser specialRemoteConfigParsers (baseRemoteConfigParser externalprogram)
+
+baseRemoteConfigParser :: Maybe ExternalProgram -> RemoteConfigParser
+baseRemoteConfigParser externalprogram = RemoteConfigParser
+	{ remoteConfigFieldParsers = if isJust extcommand
+		then []
+		else 
+			[ optionalStringParser externaltypeField
+				(FieldDesc "type of external special remote to use")
+			, trueFalseParser readonlyField (Just False)
+				(FieldDesc "enable readonly mode")
+			]
+	, remoteConfigRestPassthrough = Just
+		( const True
+		, [("*", FieldDesc $ "all other parameters are passed to " ++ fromMaybe "external special remote program" extcommand)]
+		)
+	}
+  where
+	extcommand = case externalprogram of
+		Just (ExternalCommand c _) -> Just c
+		_ -> Nothing
+
+{- When the remote supports LISTCONFIGS, only accept the ones it listed.
+ - When it does not, accept all configs. -}
+strictRemoteConfigParser :: External -> Annex RemoteConfigParser
+strictRemoteConfigParser external = listConfigs external >>= \case
+	Nothing -> return lcp
+	Just l -> do
+		let s = S.fromList (map fst l)
+		let listed f = S.member (fromProposedAccepted f) s
+		return $ lcp { remoteConfigRestPassthrough = Just (listed, l) }
+  where
+	lcp = lenientRemoteConfigParser (Just (externalProgram external))
+
+listConfigs :: External -> Annex (Maybe [(Setting, FieldDesc)])
+listConfigs external = handleRequest external LISTCONFIGS Nothing (collect [])
+  where
+	collect l req = case req of
+		CONFIG s d -> Just $ return $
+			GetNextMessage $ collect ((s, FieldDesc d) : l)
+		CONFIGEND -> result (Just (reverse l))
+		UNSUPPORTED_REQUEST -> result Nothing
+		_ -> Nothing
+
+remoteConfigParser :: Maybe ExternalProgram -> RemoteConfig -> Annex RemoteConfigParser
+remoteConfigParser externalprogram c
+	-- No need to start the external when there is no config to parse,
+	-- or when everything in the config was already accepted; in those
+	-- cases the lenient parser will do the same thing as the strict
+	-- parser.
+	| M.null (M.filter isproposed c) = return (lenientRemoteConfigParser externalprogram)
+	| otherwise = case parseRemoteConfig c (baseRemoteConfigParser externalprogram) of
+		Left _ -> return (lenientRemoteConfigParser externalprogram)
+		Right pc -> case (getRemoteConfigValue externaltypeField pc, getRemoteConfigValue readonlyField pc) of
+			(Nothing, _) -> return (lenientRemoteConfigParser externalprogram)
+			(_, Just True) -> return (lenientRemoteConfigParser externalprogram)
+			(Just externaltype, _) -> do
+				let p = fromMaybe (ExternalType externaltype) externalprogram
+				external <- newExternal p Nothing pc Nothing Nothing Nothing
+				strictRemoteConfigParser external
+  where
+	isproposed (Accepted _) = False
+	isproposed (Proposed _) = True
diff --git a/Remote/External/AsyncExtension.hs b/Remote/External/AsyncExtension.hs
new file mode 100644
index 0000000000..34b04297a0
--- /dev/null
+++ b/Remote/External/AsyncExtension.hs
@@ -0,0 +1,132 @@
+{- External remote protocol async extension.
+ - 
+ - Copyright 2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE BangPatterns #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Remote.External.AsyncExtension (runRelayToExternalAsync) where
+
+import Common
+import Annex
+import Messages
+import Remote.External.Types
+import qualified Utility.SimpleProtocol as Proto
+
+import Control.Concurrent.Async
+import Control.Concurrent.STM
+import Control.Concurrent.STM.TBMChan
+import qualified Data.Map.Strict as M
+
+-- | Starts a thread that will handle all communication with the external
+-- process. The input ExternalState communicates directly with the external
+-- process.
+runRelayToExternalAsync :: External -> ExternalState -> (Annex () -> IO ()) -> IO ExternalAsyncRelay
+runRelayToExternalAsync external st annexrunner = do
+	jidmap <- newTVarIO M.empty
+	sendq <- newSendQueue
+	nextjid <- newTVarIO (JobId 1)
+	sender <- async $ sendloop st sendq
+	receiver <- async $ receiveloop external st jidmap sendq sender annexrunner
+	return $ ExternalAsyncRelay $ do
+		receiveq <- newReceiveQueue
+		jid <- atomically $ do
+			jid@(JobId n) <- readTVar nextjid
+			let !jid' = JobId (succ n)
+			writeTVar nextjid jid'
+			modifyTVar' jidmap $ M.insert jid receiveq
+			return jid
+		return $ ExternalState
+			{ externalSend = \msg -> 
+				atomically $ writeTBMChan sendq
+					(toAsyncWrapped msg, jid)
+			, externalReceive = atomically (readTBMChan receiveq)
+			-- This shuts down the whole relay.
+			, externalShutdown = shutdown external st sendq sender receiver
+			-- These three TMVars are shared among all
+			-- ExternalStates that use this relay; they're
+			-- common state about the external process.
+			, externalPrepared = externalPrepared st
+			, externalConfig = externalConfig st
+			, externalConfigChanges = externalConfigChanges st
+			}
+
+type ReceiveQueue = TBMChan String
+
+type SendQueue = TBMChan (AsyncWrapped, JobId)
+
+type JidMap = TVar (M.Map JobId ReceiveQueue)
+
+newReceiveQueue :: IO ReceiveQueue
+newReceiveQueue = newTBMChanIO 10
+
+newSendQueue :: IO SendQueue
+newSendQueue = newTBMChanIO 10
+
+receiveloop :: External -> ExternalState -> JidMap -> SendQueue -> Async () -> (Annex () -> IO ()) -> IO ()
+receiveloop external st jidmap sendq sendthread annexrunner = externalReceive st >>= \case
+	Just l -> case parseMessage l :: Maybe AsyncMessage of
+		Just (AsyncMessage jid msg) ->
+			M.lookup jid <$> readTVarIO jidmap >>= \case
+				Just c -> do
+					atomically $ writeTBMChan c msg
+					receiveloop external st jidmap sendq sendthread annexrunner
+				Nothing -> protoerr "unknown job number"
+		Nothing -> case parseMessage l :: Maybe ExceptionalMessage of
+			Just _ -> do
+				-- ERROR is relayed to all listeners
+				m <- readTVarIO jidmap
+				forM_ (M.elems m) $ \c ->
+					atomically  $ writeTBMChan c l
+				receiveloop external st jidmap sendq sendthread annexrunner
+			Nothing -> protoerr "unexpected non-async message"
+	Nothing -> closeandshutdown
+  where
+	protoerr s = do
+		annexrunner $ warning $ "async external special remote protocol error: " <> s
+		closeandshutdown
+	
+	closeandshutdown = do
+		dummy <- async noop
+		shutdown external st sendq sendthread dummy True
+		m <- atomically $ readTVar jidmap
+		forM_ (M.elems m) (atomically . closeTBMChan)
+
+sendloop :: ExternalState -> SendQueue -> IO ()
+sendloop st sendq = atomically (readTBMChan sendq) >>= \case
+	Just (wrappedmsg, jid) -> do
+		case wrappedmsg of
+			AsyncWrappedRemoteResponse msg ->
+				externalSend st $ wrapjid msg jid
+			AsyncWrappedRequest msg ->
+				externalSend st $ wrapjid msg jid
+			AsyncWrappedExceptionalMessage msg -> 
+				externalSend st msg
+			AsyncWrappedAsyncMessage msg ->
+				externalSend st msg
+		sendloop st sendq
+	Nothing -> return ()
+  where
+	wrapjid msg jid = AsyncMessage jid $ unwords $ Proto.formatMessage msg
+
+shutdown :: External -> ExternalState -> SendQueue -> Async () -> Async () -> Bool -> IO ()
+shutdown external st sendq sendthread receivethread b = do
+	-- Receive thread is normally blocked reading from a handle.
+	-- That can block closing the handle, so it needs to be canceled.
+	cancel receivethread
+	-- Cleanly shutdown the send thread as well, allowing it to finish
+	-- writing anything that was buffered.
+	atomically $ closeTBMChan sendq
+	wait sendthread
+	r <- atomically $ do
+		r <- tryTakeTMVar (externalAsync external) 
+		putTMVar (externalAsync external)
+			UncheckedExternalAsync
+		return r
+	case r of
+		Just (ExternalAsync _) -> externalShutdown st b
+		_ -> noop
diff --git a/Remote/External/Types.hs b/Remote/External/Types.hs
new file mode 100644
index 0000000000..7eb1d95c7b
--- /dev/null
+++ b/Remote/External/Types.hs
@@ -0,0 +1,486 @@
+{- External special remote data types.
+ -
+ - Copyright 2013-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE FlexibleInstances, TypeSynonymInstances, RankNTypes #-}
+{-# LANGUAGE GeneralizedNewtypeDeriving #-}
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module Remote.External.Types (
+	External(..),
+	newExternal,
+	ExternalProgram(..),
+	ExternalState(..),
+	PrepareStatus(..),
+	ExtensionList(..),
+	supportedExtensionList,
+	asyncExtensionEnabled,
+	ExternalAsync(..),
+	ExternalAsyncRelay(..),
+	Proto.parseMessage,
+	Proto.Sendable(..),
+	Proto.Receivable(..),
+	Request(..),
+	SafeKey,
+	mkSafeKey,
+	needsPREPARE,
+	Response(..),
+	RemoteRequest(..),
+	RemoteResponse(..),
+	ExceptionalMessage(..),
+	AsyncMessage(..),
+	AsyncWrapped(..),
+	ToAsyncWrapped(..),
+	JobId(..),
+	ErrorMsg,
+	Setting,
+	Description,
+	ProtocolVersion,
+	supportedProtocolVersions,
+) where
+
+import Annex.Common
+import Types.StandardGroups (PreferredContentExpression)
+import Utility.Metered (BytesProcessed(..))
+import Types.Transfer (Direction(..))
+import Config.Cost (Cost)
+import Types.RemoteState
+import Types.RemoteConfig
+import Types.Export
+import Types.Availability (Availability(..))
+import Types.Key
+import Git.Types
+import Utility.Url (URLString)
+import Utility.Url.Parse
+import qualified Utility.SimpleProtocol as Proto
+
+import Control.Concurrent.STM
+import Network.URI
+import Data.Char
+import Text.Read
+import qualified Data.ByteString.Short as S (fromShort)
+
+data External = External
+	{ externalProgram :: ExternalProgram
+	, externalUUID :: Maybe UUID
+	, externalState :: TVar [ExternalState]
+	-- ^ Contains states for external special remote processes
+	-- that are not currently in use.
+	, externalLastPid :: TVar PID
+	, externalDefaultConfig :: ParsedRemoteConfig
+	, externalGitConfig :: Maybe RemoteGitConfig
+	, externalRemoteName :: Maybe RemoteName 
+	, externalRemoteStateHandle :: Maybe RemoteStateHandle
+	, externalAsync :: TMVar ExternalAsync
+	}
+
+newExternal :: ExternalProgram -> Maybe UUID -> ParsedRemoteConfig -> Maybe RemoteGitConfig -> Maybe RemoteName -> Maybe RemoteStateHandle -> Annex External
+newExternal p u c gc rn rs = liftIO $ External
+	<$> pure p
+	<*> pure u
+	<*> atomically (newTVar [])
+	<*> atomically (newTVar 0)
+	<*> pure c
+	<*> pure gc
+	<*> pure rn
+	<*> pure rs
+	<*> atomically (newTMVar UncheckedExternalAsync)
+
+data ExternalProgram
+	= ExternalType String
+	-- ^ "git-annex-remote-" is prepended to this to get the program
+	| ExternalCommand String [CommandParam]
+	-- ^ to use a program with a different name, and parameters
+	deriving (Show, Eq)
+
+data ExternalState = ExternalState
+	{ externalSend :: forall t. (Proto.Sendable t, ToAsyncWrapped t) => t -> IO ()
+	, externalReceive :: IO (Maybe String)
+	, externalShutdown :: Bool -> IO ()
+	, externalPrepared :: TMVar PrepareStatus
+	, externalConfig :: TMVar ParsedRemoteConfig
+	, externalConfigChanges :: TMVar (RemoteConfig -> RemoteConfig)
+	}
+
+type PID = Int
+
+-- List of extensions to the protocol.
+newtype ExtensionList = ExtensionList { fromExtensionList :: [String] }
+	deriving (Show, Monoid, Semigroup)
+
+supportedExtensionList :: ExtensionList
+supportedExtensionList = ExtensionList
+	[ "INFO"
+	, "GETGITREMOTENAME"
+	, "UNAVAILABLERESPONSE"
+	, asyncExtension
+	]
+
+asyncExtension :: String
+asyncExtension = "ASYNC"
+
+asyncExtensionEnabled :: ExtensionList -> Bool
+asyncExtensionEnabled l = asyncExtension `elem` fromExtensionList l
+
+-- When the async extension is in use, a single external process
+-- is started and used for all requests.
+data ExternalAsync
+	= ExternalAsync ExternalAsyncRelay
+	| NoExternalAsync
+	| UncheckedExternalAsync
+
+data ExternalAsyncRelay = ExternalAsyncRelay
+	{ asyncRelayExternalState :: IO ExternalState
+	}
+
+data PrepareStatus = Unprepared | Prepared | FailedPrepare ErrorMsg
+
+-- The protocol does not support keys with spaces in their names;
+-- SafeKey can only be constructed for keys that are safe to use with the
+-- protocol.
+newtype SafeKey = SafeKey Key
+	deriving (Show)
+
+mkSafeKey :: Key -> Either String SafeKey
+mkSafeKey k 
+	| any isSpace (decodeBS $ S.fromShort $ fromKey keyName k) = Left $ concat
+		[ "Sorry, this file cannot be stored on an external special remote because its key's name contains a space. "
+		, "To avoid this problem, you can run: git-annex migrate --backend="
+		, decodeBS (formatKeyVariety (fromKey keyVariety k))
+		, " and pass it the name of the file"
+		]
+	| otherwise = Right (SafeKey k)
+
+fromSafeKey :: SafeKey -> Key
+fromSafeKey (SafeKey k) = k
+
+instance Proto.Serializable SafeKey where
+	serialize = Proto.serialize . fromSafeKey
+	deserialize = fmap SafeKey . Proto.deserialize
+
+-- Messages that can be sent to the external remote to request it do something.
+data Request 
+	= EXTENSIONS ExtensionList
+	| PREPARE
+	| INITREMOTE
+	| GETCOST
+	| GETAVAILABILITY
+	| CLAIMURL URLString
+	| CHECKURL URLString
+	| TRANSFER Direction SafeKey FilePath
+	| CHECKPRESENT SafeKey
+	| REMOVE SafeKey
+	| WHEREIS SafeKey
+	| LISTCONFIGS
+	| GETINFO
+	| EXPORTSUPPORTED
+	| EXPORT ExportLocation
+	| TRANSFEREXPORT Direction SafeKey FilePath
+	| CHECKPRESENTEXPORT SafeKey
+	| REMOVEEXPORT SafeKey
+	| REMOVEEXPORTDIRECTORY ExportDirectory
+	| RENAMEEXPORT SafeKey ExportLocation
+	deriving (Show)
+
+-- Does PREPARE need to have been sent before this request?
+needsPREPARE :: Request -> Bool
+needsPREPARE PREPARE = False
+needsPREPARE (EXTENSIONS _) = False
+needsPREPARE INITREMOTE = False
+needsPREPARE EXPORTSUPPORTED = False
+needsPREPARE LISTCONFIGS = False
+needsPREPARE _ = True
+
+instance Proto.Sendable Request where
+	formatMessage (EXTENSIONS l) = ["EXTENSIONS", Proto.serialize l]
+	formatMessage PREPARE = ["PREPARE"]
+	formatMessage INITREMOTE = ["INITREMOTE"]
+	formatMessage GETCOST = ["GETCOST"]
+	formatMessage GETAVAILABILITY = ["GETAVAILABILITY"]
+	formatMessage (CLAIMURL url) = [ "CLAIMURL", Proto.serialize url ]
+	formatMessage (CHECKURL url) = [ "CHECKURL", Proto.serialize url ]
+	formatMessage (TRANSFER direction key file) =
+		[ "TRANSFER"
+		, Proto.serialize direction
+		, Proto.serialize key
+		, Proto.serialize file
+		]
+	formatMessage (CHECKPRESENT key) =
+		[ "CHECKPRESENT", Proto.serialize key ]
+	formatMessage (REMOVE key) = [ "REMOVE", Proto.serialize key ]
+	formatMessage (WHEREIS key) = [ "WHEREIS", Proto.serialize key ]
+	formatMessage LISTCONFIGS = [ "LISTCONFIGS" ]
+	formatMessage GETINFO = [ "GETINFO" ]
+	formatMessage EXPORTSUPPORTED = ["EXPORTSUPPORTED"]
+	formatMessage (EXPORT loc) = [ "EXPORT", Proto.serialize loc ]
+	formatMessage (TRANSFEREXPORT direction key file) = 
+		[ "TRANSFEREXPORT"
+		, Proto.serialize direction
+		, Proto.serialize key
+		, Proto.serialize file
+		]
+	formatMessage (CHECKPRESENTEXPORT key) =
+		[ "CHECKPRESENTEXPORT", Proto.serialize key ]
+	formatMessage (REMOVEEXPORT key) =
+		[ "REMOVEEXPORT", Proto.serialize key ]
+	formatMessage (REMOVEEXPORTDIRECTORY dir) =
+		[ "REMOVEEXPORTDIRECTORY", Proto.serialize dir ]
+	formatMessage (RENAMEEXPORT key newloc) =
+		[ "RENAMEEXPORT"
+		, Proto.serialize key
+		, Proto.serialize newloc
+		]
+
+-- Responses the external remote can make to requests.
+data Response
+	= EXTENSIONS_RESPONSE ExtensionList
+	| PREPARE_SUCCESS
+	| PREPARE_FAILURE ErrorMsg
+	| TRANSFER_SUCCESS Direction Key
+	| TRANSFER_FAILURE Direction Key ErrorMsg
+	| CHECKPRESENT_SUCCESS Key
+	| CHECKPRESENT_FAILURE Key
+	| CHECKPRESENT_UNKNOWN Key ErrorMsg
+	| REMOVE_SUCCESS Key
+	| REMOVE_FAILURE Key ErrorMsg
+	| COST Cost
+	| AVAILABILITY Availability
+	| INITREMOTE_SUCCESS
+	| INITREMOTE_FAILURE ErrorMsg
+	| CLAIMURL_SUCCESS
+	| CLAIMURL_FAILURE
+	| CHECKURL_CONTENTS Size FilePath
+	| CHECKURL_MULTI [(URLString, Size, FilePath)]
+	| CHECKURL_FAILURE ErrorMsg
+	| WHEREIS_SUCCESS String
+	| WHEREIS_FAILURE
+	| CONFIG Setting Description
+	| CONFIGEND
+	| INFOFIELD String
+	| INFOVALUE String
+	| INFOEND
+	| EXPORTSUPPORTED_SUCCESS
+	| EXPORTSUPPORTED_FAILURE
+	| REMOVEEXPORTDIRECTORY_SUCCESS
+	| REMOVEEXPORTDIRECTORY_FAILURE
+	| RENAMEEXPORT_SUCCESS Key
+	| RENAMEEXPORT_FAILURE Key
+	| UNSUPPORTED_REQUEST
+	deriving (Show)
+
+instance Proto.Receivable Response where
+	parseCommand "EXTENSIONS" = Proto.parse1 EXTENSIONS_RESPONSE
+	parseCommand "PREPARE-SUCCESS" = Proto.parse0 PREPARE_SUCCESS
+	parseCommand "PREPARE-FAILURE" = Proto.parse1 PREPARE_FAILURE
+	parseCommand "TRANSFER-SUCCESS" = Proto.parse2 TRANSFER_SUCCESS
+	parseCommand "TRANSFER-FAILURE" = Proto.parse3 TRANSFER_FAILURE
+	parseCommand "CHECKPRESENT-SUCCESS" = Proto.parse1 CHECKPRESENT_SUCCESS
+	parseCommand "CHECKPRESENT-FAILURE" = Proto.parse1 CHECKPRESENT_FAILURE
+	parseCommand "CHECKPRESENT-UNKNOWN" = Proto.parse2 CHECKPRESENT_UNKNOWN
+	parseCommand "REMOVE-SUCCESS" = Proto.parse1 REMOVE_SUCCESS
+	parseCommand "REMOVE-FAILURE" = Proto.parse2 REMOVE_FAILURE
+	parseCommand "COST" = Proto.parse1 COST
+	parseCommand "AVAILABILITY" = Proto.parse1 AVAILABILITY
+	parseCommand "INITREMOTE-SUCCESS" = Proto.parse0 INITREMOTE_SUCCESS
+	parseCommand "INITREMOTE-FAILURE" = Proto.parse1 INITREMOTE_FAILURE
+	parseCommand "CLAIMURL-SUCCESS" = Proto.parse0 CLAIMURL_SUCCESS
+	parseCommand "CLAIMURL-FAILURE" = Proto.parse0 CLAIMURL_FAILURE
+	parseCommand "CHECKURL-CONTENTS" = Proto.parse2 CHECKURL_CONTENTS
+	parseCommand "CHECKURL-MULTI" = Proto.parse1 CHECKURL_MULTI
+	parseCommand "CHECKURL-FAILURE" = Proto.parse1 CHECKURL_FAILURE
+	parseCommand "WHEREIS-SUCCESS" = Just . WHEREIS_SUCCESS
+	parseCommand "WHEREIS-FAILURE" = Proto.parse0 WHEREIS_FAILURE
+	parseCommand "CONFIG" = Proto.parse2 CONFIG
+	parseCommand "CONFIGEND" = Proto.parse0 CONFIGEND
+	parseCommand "INFOFIELD" = Proto.parse1 INFOFIELD
+	parseCommand "INFOVALUE" = Proto.parse1 INFOVALUE
+	parseCommand "INFOEND" = Proto.parse0 INFOEND
+	parseCommand "EXPORTSUPPORTED-SUCCESS" = Proto.parse0 EXPORTSUPPORTED_SUCCESS
+	parseCommand "EXPORTSUPPORTED-FAILURE" = Proto.parse0 EXPORTSUPPORTED_FAILURE
+	parseCommand "REMOVEEXPORTDIRECTORY-SUCCESS" = Proto.parse0 REMOVEEXPORTDIRECTORY_SUCCESS
+	parseCommand "REMOVEEXPORTDIRECTORY-FAILURE" = Proto.parse0 REMOVEEXPORTDIRECTORY_FAILURE
+	parseCommand "RENAMEEXPORT-SUCCESS" = Proto.parse1 RENAMEEXPORT_SUCCESS
+	parseCommand "RENAMEEXPORT-FAILURE" = Proto.parse1 RENAMEEXPORT_FAILURE
+	parseCommand "UNSUPPORTED-REQUEST" = Proto.parse0 UNSUPPORTED_REQUEST
+	parseCommand _ = Proto.parseFail
+
+-- Requests that the external remote can send at any time it's in control.
+data RemoteRequest
+	= VERSION ProtocolVersion
+	| PROGRESS BytesProcessed
+	| DIRHASH Key
+	| DIRHASH_LOWER Key
+	| SETCONFIG Setting String
+	| GETCONFIG Setting
+	| SETCREDS Setting String String
+	| GETCREDS Setting
+	| GETUUID
+	| GETGITDIR
+	| GETGITREMOTENAME
+	| SETWANTED PreferredContentExpression
+	| GETWANTED
+	| SETSTATE Key String
+	| GETSTATE Key
+	| SETURLPRESENT Key URLString
+	| SETURLMISSING Key URLString
+	| SETURIPRESENT Key URI
+	| SETURIMISSING Key URI
+	| GETURLS Key String
+	| DEBUG String
+	| INFO String
+	deriving (Show)
+
+instance Proto.Receivable RemoteRequest where
+	parseCommand "VERSION" = Proto.parse1 VERSION
+	parseCommand "PROGRESS" = Proto.parse1 PROGRESS
+	parseCommand "DIRHASH" = Proto.parse1 DIRHASH
+	parseCommand "DIRHASH-LOWER" = Proto.parse1 DIRHASH_LOWER
+	parseCommand "SETCONFIG" = Proto.parse2 SETCONFIG
+	parseCommand "GETCONFIG" = Proto.parse1 GETCONFIG
+	parseCommand "SETCREDS" = Proto.parse3 SETCREDS
+	parseCommand "GETCREDS" = Proto.parse1 GETCREDS
+	parseCommand "GETUUID" = Proto.parse0 GETUUID
+	parseCommand "GETGITDIR" = Proto.parse0 GETGITDIR
+	parseCommand "GETGITREMOTENAME" = Proto.parse0 GETGITREMOTENAME
+	parseCommand "SETWANTED" = Proto.parse1 SETWANTED
+	parseCommand "GETWANTED" = Proto.parse0 GETWANTED
+	parseCommand "SETSTATE" = Proto.parse2 SETSTATE
+	parseCommand "GETSTATE" = Proto.parse1 GETSTATE
+	parseCommand "SETURLPRESENT" = Proto.parse2 SETURLPRESENT
+	parseCommand "SETURLMISSING" = Proto.parse2 SETURLMISSING
+	parseCommand "SETURIPRESENT" = Proto.parse2 SETURIPRESENT
+	parseCommand "SETURIMISSING" = Proto.parse2 SETURIMISSING
+	parseCommand "GETURLS" = Proto.parse2 GETURLS
+	parseCommand "DEBUG" = Proto.parse1 DEBUG
+	parseCommand "INFO" = Proto.parse1 INFO
+	parseCommand _ = Proto.parseFail
+
+-- Responses to RemoteRequest.
+data RemoteResponse
+	= VALUE String
+	| CREDS String String
+	deriving (Show)
+
+instance Proto.Sendable RemoteResponse where
+	formatMessage (VALUE s) = [ "VALUE", Proto.serialize s ]
+	formatMessage (CREDS login password) = [ "CREDS", Proto.serialize login, Proto.serialize password ]
+
+-- Messages that can be sent at any time by either git-annex or the remote.
+data ExceptionalMessage
+	= ERROR ErrorMsg
+	deriving (Show)
+
+instance Proto.Sendable ExceptionalMessage where
+	formatMessage (ERROR err) = [ "ERROR", Proto.serialize err ]
+
+instance Proto.Receivable ExceptionalMessage where
+	parseCommand "ERROR" = Proto.parse1 ERROR
+	parseCommand _ = Proto.parseFail
+
+data AsyncMessage = AsyncMessage JobId WrappedMsg
+
+instance Proto.Receivable AsyncMessage where
+	parseCommand "J" = Proto.parse2 AsyncMessage
+	parseCommand _ = Proto.parseFail
+
+instance Proto.Sendable AsyncMessage where
+	formatMessage (AsyncMessage jid msg) = ["J", Proto.serialize jid, msg]
+
+data AsyncWrapped
+	= AsyncWrappedRemoteResponse RemoteResponse
+	| AsyncWrappedRequest Request
+	| AsyncWrappedExceptionalMessage ExceptionalMessage
+	| AsyncWrappedAsyncMessage AsyncMessage
+
+class ToAsyncWrapped t where
+	toAsyncWrapped :: t -> AsyncWrapped
+
+instance ToAsyncWrapped RemoteResponse where
+	toAsyncWrapped = AsyncWrappedRemoteResponse
+
+instance ToAsyncWrapped Request where
+	toAsyncWrapped = AsyncWrappedRequest
+
+instance ToAsyncWrapped ExceptionalMessage where
+	toAsyncWrapped = AsyncWrappedExceptionalMessage
+
+instance ToAsyncWrapped AsyncMessage where
+	toAsyncWrapped = AsyncWrappedAsyncMessage
+
+-- Data types used for parameters when communicating with the remote.
+-- All are serializable.
+type ErrorMsg = String
+type Setting = String
+type Description = String
+type ProtocolVersion = Int
+type Size = Maybe Integer
+type WrappedMsg = String
+newtype JobId = JobId Integer
+	deriving (Eq, Ord, Show)
+
+supportedProtocolVersions :: [ProtocolVersion]
+supportedProtocolVersions = [1, 2]
+
+instance Proto.Serializable JobId where
+	serialize (JobId n) = show n
+	deserialize = JobId <$$> readMaybe
+
+instance Proto.Serializable Direction where
+	serialize Upload = "STORE"
+	serialize Download = "RETRIEVE"
+
+	deserialize "STORE" = Just Upload
+	deserialize "RETRIEVE" = Just Download
+	deserialize _ = Nothing
+
+instance Proto.Serializable ProtocolVersion where
+	serialize = show
+	deserialize = readish
+
+instance Proto.Serializable Cost where
+	serialize = show
+	deserialize = readish
+
+instance Proto.Serializable Size where
+	serialize (Just s) = show s
+	serialize Nothing = "UNKNOWN"
+	deserialize "UNKNOWN" = Just Nothing
+	deserialize s = maybe Nothing (Just . Just) (readish s)
+
+instance Proto.Serializable Availability where
+	serialize GloballyAvailable = "GLOBAL"
+	serialize LocallyAvailable = "LOCAL"
+	serialize Unavailable = "UNAVAILABLE"
+
+	deserialize "GLOBAL" = Just GloballyAvailable
+	deserialize "LOCAL" = Just LocallyAvailable
+	deserialize "UNAVAILABLE" = Just Unavailable
+	deserialize _ = Nothing
+
+instance Proto.Serializable [(URLString, Size, FilePath)] where
+	serialize = unwords . map go
+	  where
+		go (url, sz, f) = url ++ " " ++ maybe "UNKNOWN" show sz ++ " " ++ f
+	deserialize = Just . go [] . words
+	  where
+		go c (url:sz:f:rest) = go ((url, readish sz, f):c) rest
+		go c _ = reverse c
+
+instance Proto.Serializable URI where
+	serialize = show
+	deserialize = parseURIPortable
+
+instance Proto.Serializable ExportLocation where
+	serialize = fromRawFilePath . fromExportLocation
+	deserialize = Just . mkExportLocation . toRawFilePath
+
+instance Proto.Serializable ExportDirectory where
+	serialize = fromRawFilePath . fromExportDirectory
+	deserialize = Just . mkExportDirectory . toRawFilePath
+
+instance Proto.Serializable ExtensionList where
+	serialize (ExtensionList l) = unwords l
+	deserialize = Just . ExtensionList . words
diff --git a/Remote/GCrypt.hs b/Remote/GCrypt.hs
new file mode 100644
index 0000000000..d9a581596d
--- /dev/null
+++ b/Remote/GCrypt.hs
@@ -0,0 +1,529 @@
+{- git remotes encrypted using git-remote-gcrypt
+ -
+ - Copyright 2013-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE RankNTypes #-}
+
+module Remote.GCrypt (
+	remote,
+	chainGen,
+	getGCryptUUID,
+	coreGCryptId,
+	setupRepo,
+	accessShellConfig,
+	setGcryptEncryption,
+) where
+
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import qualified System.FilePath.ByteString as P
+import Control.Exception
+import Data.Default
+
+import Annex.Common
+import qualified Annex
+import Types.Remote
+import Types.GitConfig
+import Types.Crypto
+import Types.Creds
+import Types.Transfer
+import Git.Types (ConfigKey(..), fromConfigKey, fromConfigValue)
+import qualified Git
+import qualified Git.Command
+import qualified Git.Config
+import qualified Git.GCrypt
+import qualified Git.Construct
+import qualified Annex.Branch
+import Config
+import Config.Cost
+import Annex.SpecialRemote.Config
+import Remote.Helper.Git
+import Remote.Helper.Encryptable
+import Remote.Helper.Special
+import Remote.Helper.Messages
+import Remote.Helper.ExportImport
+import qualified Remote.Helper.Ssh as Ssh
+import Utility.Metered
+import Annex.UUID
+import Annex.Ssh
+import Annex.Perms
+import qualified Remote.Rsync
+import qualified Remote.Directory
+import Utility.Rsync
+import Utility.Tmp
+import Logs.Remote
+import Utility.Gpg
+import Utility.SshHost
+import Utility.Tuple
+import Utility.Directory.Create
+import Messages.Progress
+import Types.ProposedAccepted
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "gcrypt"
+	-- Remote.Git takes care of enumerating gcrypt remotes too,
+	-- and will call our chainGen on them.
+	, enumerate = const (return [])
+	, generate = gen
+	, configParser = mkRemoteConfigParser $
+		Remote.Rsync.rsyncRemoteConfigs ++
+		[ optionalStringParser gitRepoField
+			(FieldDesc "(required) path or url to gcrypt repository")
+		]
+	, setup = gCryptSetup
+	, exportSupported = exportUnsupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+gitRepoField :: RemoteConfigField
+gitRepoField = Accepted "gitrepo"
+
+chainGen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+chainGen gcryptr u rc gc rs = do
+	g <- gitRepo
+	-- get underlying git repo with real path, not gcrypt path
+	r <- liftIO $ Git.GCrypt.encryptedRemote g gcryptr
+	let r' = r { Git.remoteName = Git.remoteName gcryptr }
+	gen r' u rc gc rs
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen baser u rc gc rs = do
+	-- doublecheck that cache matches underlying repo's gcrypt-id
+	-- (which might not be set), only for local repos
+	(mgcryptid, r) <- getGCryptId True baser gc
+	g <- gitRepo
+	case (mgcryptid, Git.GCrypt.remoteRepoId g (Git.remoteName baser)) of
+		(Just gcryptid, Just cachedgcryptid)
+			| gcryptid /= cachedgcryptid -> resetup gcryptid r
+		_ -> do
+			c <- parsedRemoteConfig remote rc
+			gen' r u c gc rs
+  where
+	-- A different drive may have been mounted, making a different
+	-- gcrypt remote available. So need to set the cached
+	-- gcrypt-id and annex-uuid of the remote to match the remote
+	-- that is now available. Also need to set the gcrypt particiants
+	-- correctly.
+	resetup gcryptid r = do
+		let u' = genUUIDInNameSpace gCryptNameSpace (encodeBS gcryptid)
+		v <- M.lookup u' <$> remoteConfigMap
+		case (Git.remoteName baser, v) of
+			(Just remotename, Just rc') -> do
+				pc <- parsedRemoteConfig remote rc'
+				setGcryptEncryption pc remotename
+				storeUUIDIn (remoteAnnexConfig baser "uuid") u'
+				setConfig (Git.GCrypt.remoteConfigKey "gcrypt-id" remotename) gcryptid
+				gen' r u' pc gc rs
+			_ -> do
+				warning $ UnquotedString $ "not using unknown gcrypt repository pointed to by remote " ++ Git.repoDescribe r
+				return Nothing
+
+gen' :: Git.Repo -> UUID -> ParsedRemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen' r u c gc rs = do
+	cst <- remoteCost gc c $
+		if repoCheap r
+			then nearlyCheapRemoteCost
+			else expensiveRemoteCost
+	let (rsynctransport, rsyncurl, accessmethod) = rsyncTransportToObjects r gc
+	protectsargs <- liftIO Remote.Rsync.probeRsyncProtectsArgs
+	let rsyncopts = Remote.Rsync.genRsyncOpts protectsargs c gc rsynctransport rsyncurl
+	let this = Remote 
+		{ uuid = u
+		, cost = cst
+		, name = Git.repoDescribe r
+		, storeKey = storeKeyDummy
+		, retrieveKeyFile = retrieveKeyFileDummy
+		, retrieveKeyFileCheap = Nothing
+		, retrievalSecurityPolicy = RetrievalAllKeysSecure
+		, removeKey = removeKeyDummy
+		, lockContent = Nothing
+		, checkPresent = checkPresentDummy
+		, checkPresentCheap = repoCheap r
+		, exportActions = exportUnsupported
+		, importActions = importUnsupported
+		, whereisKey = Nothing
+		, remoteFsck = Nothing
+		, repairRepo = Nothing
+		, config = c
+		, localpath = localpathCalc r
+		, getRepo = return r
+		, gitconfig = gc
+		, readonly = Git.repoIsHttp r
+		, appendonly = False
+		, untrustworthy = False
+		, availability = repoAvail r
+		, remotetype = remote
+		, mkUnavailable = return Nothing
+		, getInfo = gitRepoInfo this
+		, claimUrl = Nothing
+		, checkUrl = Nothing
+		, remoteStateHandle = rs
+	}
+	return $ Just $ specialRemote' specialcfg c
+		(store this rsyncopts accessmethod)
+		(retrieve this rsyncopts accessmethod)
+		(remove this rsyncopts accessmethod)
+		(checkKey this rsyncopts accessmethod)
+		this
+  where
+	specialcfg
+		| Git.repoIsUrl r = (specialRemoteCfg c)
+			-- Rsync displays its own progress.
+			{ displayProgress = False }
+		| otherwise = specialRemoteCfg c
+
+rsyncTransportToObjects :: Git.Repo -> RemoteGitConfig -> (Annex [CommandParam], String, AccessMethod)
+rsyncTransportToObjects r gc =
+	let (rsynctransport, rsyncurl, m) = rsyncTransport r gc
+	in (rsynctransport, rsyncurl ++ "/annex/objects", m)
+
+rsyncTransport :: Git.Repo -> RemoteGitConfig -> (Annex [CommandParam], String, AccessMethod)
+rsyncTransport r gc
+	| sshprefix `isPrefixOf` loc = sshtransport $ break (== '/') $ drop (length sshprefix) loc
+	| "rsync://" `isPrefixOf` loc = rsyncoversshtransport
+	| ":" `isInfixOf` loc = sshtransport $ separate (== ':') loc
+	| otherwise = rsyncoversshtransport
+  where
+	sshprefix = "ssh://" :: String
+	loc = Git.repoLocation r
+	sshtransport (host, path) =
+		let rsyncpath = if "/~/" `isPrefixOf` path
+			then drop 3 path
+			else path
+		    sshhost = either giveup id (mkSshHost host)
+		    mkopts = rsyncShell . (Param "ssh" :) 
+			<$> sshOptions ConsumeStdin (sshhost, Nothing) gc []
+		in (mkopts, fromSshHost sshhost ++ ":" ++ rsyncpath, AccessGitAnnexShell)
+	rsyncoversshtransport =
+		-- git-remote-gcrypt uses a rsync:// url to mean
+		-- rsync over ssh. But to rsync, that's rsync protocol,
+		-- so it must be converted to a form that rsync will treat
+		-- as rsync over ssh.
+		-- There are two url forms that git-remote-gcrypt
+		-- supports:  rsync://userhost/path and rsync://userhost:path
+		-- change to: userhost:/path            userhost:path
+		let loc' = replace "rsync://" "" loc
+		    loc'' = if ':' `elem` loc'
+		    	then loc'
+		    	else let (a, b) = break (== '/') loc' in a ++ ":" ++ b
+		in (pure [], loc'', AccessRsyncOverSsh)
+
+noCrypto :: Annex a
+noCrypto = giveup "cannot use gcrypt remote without encryption enabled"
+
+unsupportedUrl :: a
+unsupportedUrl = giveup "unsupported repo url for gcrypt"
+
+gCryptSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+gCryptSetup _ mu _ c gc = go $ fromProposedAccepted <$> M.lookup gitRepoField c
+  where
+	remotename = fromJust (lookupName c)
+	go Nothing = giveup "Specify gitrepo="
+	go (Just gitrepo) = do
+		(c', _encsetup) <- encryptionSetup c gc
+
+		let url = Git.GCrypt.urlPrefix ++ gitrepo
+		rs <- Annex.getGitRemotes
+		case filter (\r -> Git.remoteName r == Just remotename) rs of
+			[] -> inRepo $ Git.Command.run 
+				[ Param "remote", Param "add"
+				, Param remotename
+				, Param url
+				]
+			(r:_)
+				| Git.repoLocation r == url -> noop
+				| otherwise -> giveup "Another remote with the same name already exists."		
+
+		pc <- either giveup return . parseRemoteConfig c'
+			=<< configParser remote c'
+		setGcryptEncryption pc remotename
+
+		{- Run a git fetch and a push to the git repo in order to get
+		 - its gcrypt-id set up, so that later git annex commands
+		 - will use the remote as a gcrypt remote. The fetch is
+		 - needed if the repo already exists; the push is needed
+		 - if the repo has not yet been initialized by gcrypt. -}
+		void $ inRepo $ Git.Command.runBool
+			[ Param "fetch"
+			, Param remotename
+			]
+		void $ inRepo $ Git.Command.runBool
+			[ Param "push"
+			, Param remotename
+			, Param $ Git.fromRef Annex.Branch.fullname
+			]
+		g <- inRepo Git.Config.reRead
+		case Git.GCrypt.remoteRepoId g (Just remotename) of
+			Nothing -> giveup "unable to determine gcrypt-id of remote"
+			Just gcryptid -> do
+				let u = genUUIDInNameSpace gCryptNameSpace (encodeBS gcryptid)
+				if Just u == mu || isNothing mu
+					then do
+						method <- setupRepo gcryptid =<< inRepo (Git.Construct.fromRemoteLocation gitrepo False)
+						gitConfigSpecialRemote u c' [("gcrypt", fromAccessMethod method)]
+						return (c', u)
+					else giveup $ "uuid mismatch; expected " ++ show mu ++ " but remote gitrepo has " ++ show u ++ " (" ++ show gcryptid ++ ")"
+
+{- Sets up the gcrypt repository. The repository is either a local
+ - repo, or it is accessed via rsync over ssh (without using
+ - git-annex-shell), or it is accessed over ssh and git-annex-shell
+ - is available to manage it.
+ -
+ - The GCryptID is recorded in the repository's git config for later use.
+ - Also, if the git config has receive.denyNonFastForwards set, disable
+ - it; gcrypt relies on being able to fast-forward branches.
+ -}
+setupRepo :: Git.GCrypt.GCryptId -> Git.Repo -> Annex AccessMethod
+setupRepo gcryptid r
+	| Git.repoIsUrl r = do
+		dummycfg <- liftIO dummyRemoteGitConfig
+		let (_, _, accessmethod) = rsyncTransport r dummycfg
+		case accessmethod of
+			AccessRsyncOverSsh -> rsyncsetup
+			AccessGitAnnexShell -> ifM gitannexshellsetup
+				( return AccessGitAnnexShell
+				, rsyncsetup
+				)
+	| Git.repoIsLocalUnknown r = localsetup =<< liftIO (Git.Config.read r)
+	| otherwise = localsetup r
+  where
+	localsetup r' = do
+		let setconfig k v = liftIO $ Git.Command.run [Param "config", Param (fromConfigKey k), Param v] r'
+		setconfig coreGCryptId gcryptid
+		setconfig denyNonFastForwards (Git.Config.boolConfig False)
+		return AccessRsyncOverSsh
+
+	{- As well as modifying the remote's git config, 
+	 - create the objectDir on the remote,
+	 - which is needed for rsync of objects to it to work.
+	 -}
+	rsyncsetup = Remote.Rsync.withRsyncScratchDir $ \tmp -> do
+		createAnnexDirectory (toRawFilePath tmp P.</> objectDir)
+		dummycfg <- liftIO dummyRemoteGitConfig
+		let (rsynctransport, rsyncurl, _) = rsyncTransport r dummycfg
+		let tmpconfig = tmp </> "config"
+		opts <- rsynctransport
+		void $ liftIO $ rsync $ opts ++
+			[ Param $ rsyncurl ++ "/config"
+			, Param tmpconfig
+			]
+		liftIO $ do
+			void $ Git.Config.changeFile tmpconfig coreGCryptId (encodeBS gcryptid)
+			void $ Git.Config.changeFile tmpconfig denyNonFastForwards (Git.Config.boolConfig' False)
+		ok <- liftIO $ rsync $ opts ++
+			[ Param "--recursive"
+			, Param $ tmp ++ "/"
+			, Param rsyncurl
+			]
+		unless ok $
+			giveup "Failed to connect to remote to set it up."
+		return AccessRsyncOverSsh
+
+	{-  Ask git-annex-shell to configure the repository as a gcrypt
+	 -  repository. May fail if it is too old. -}
+	gitannexshellsetup = Ssh.onRemote NoConsumeStdin r
+		(\f p -> liftIO (boolSystem f p), return False)
+		"gcryptsetup" [ Param gcryptid ] []
+
+	denyNonFastForwards = ConfigKey "receive.denyNonFastForwards"
+
+accessShell :: Remote -> Bool
+accessShell = accessShellConfig . gitconfig
+
+accessShellConfig :: RemoteGitConfig -> Bool
+accessShellConfig c = case method of
+	AccessGitAnnexShell -> True
+	_ -> False
+  where
+	method = toAccessMethod $ fromMaybe "" $ remoteAnnexGCrypt c
+
+shellOrRsync :: Remote -> Annex a -> Annex a -> Annex a
+shellOrRsync r ashell arsync
+	| accessShell r = ashell
+	| otherwise = arsync
+
+{- Configure gcrypt to use the same list of keyids that
+ - were passed to initremote as its participants.
+ - Also, configure it to use a signing key that is in the list of
+ - participants, which gcrypt requires is the case, and may not be
+ - depending on system configuration.
+ -
+ - (For shared encryption, gcrypt's default behavior is used.)
+ -
+ - Also, sets gcrypt-publish-participants to avoid unnecessary gpg
+ - passphrase prompts.
+ -}
+setGcryptEncryption :: ParsedRemoteConfig -> String -> Annex ()
+setGcryptEncryption c remotename = do
+	let participants = remoteconfig Git.GCrypt.remoteParticipantConfigKey
+	case extractCipher c of
+		Nothing -> noCrypto
+		Just cip -> case cipherKeyIds cip of
+			Nothing -> noop
+			Just (KeyIds { keyIds = ks}) -> do
+				setConfig participants (unwords ks)
+				let signingkey = Git.GCrypt.remoteSigningKey remotename
+				cmd <- gpgCmd <$> Annex.getGitConfig
+				skeys <- M.keys <$> liftIO (secretKeys cmd)
+				case filter (`elem` ks) skeys of
+					[] -> noop
+					(k:_) -> setConfig signingkey k
+	setConfig (remoteconfig Git.GCrypt.remotePublishParticipantConfigKey)
+		(Git.Config.boolConfig True)
+  where
+	remoteconfig n = n remotename
+
+store :: Remote -> Remote.Rsync.RsyncOpts -> AccessMethod -> Storer
+store r rsyncopts accessmethod k s p = do
+	repo <- getRepo r
+	store' repo r rsyncopts accessmethod k s p
+
+store' :: Git.Repo -> Remote -> Remote.Rsync.RsyncOpts -> AccessMethod -> Storer
+store' repo r rsyncopts accessmethod
+	| not $ Git.repoIsUrl repo = 
+		byteStorer $ \k b p -> guardUsable repo (giveup "cannot access remote") $ liftIO $ do
+			let tmpdir = Git.repoPath repo P.</> "tmp" P.</> keyFile k
+			void $ tryIO $ createDirectoryUnder [Git.repoPath repo] tmpdir
+			let tmpf = tmpdir P.</> keyFile k
+			meteredWriteFile p (fromRawFilePath tmpf) b
+			let destdir = parentDir $ toRawFilePath $ gCryptLocation repo k
+			Remote.Directory.finalizeStoreGeneric (Git.repoPath repo) tmpdir destdir
+	| Git.repoIsSsh repo = if accessShell r
+		then fileStorer $ \k f p -> do
+			oh <- mkOutputHandler
+			ok <- Ssh.rsyncHelper oh (Just p)
+				=<< Ssh.rsyncParamsRemote r Upload k f
+			unless ok $
+				giveup "rsync failed"
+		else storersync
+	| accessmethod == AccessRsyncOverSsh = storersync
+	| otherwise = unsupportedUrl
+  where
+	storersync = fileStorer $ Remote.Rsync.store rsyncopts
+
+retrieve :: Remote -> Remote.Rsync.RsyncOpts -> AccessMethod -> Retriever
+retrieve r rsyncopts accessmethod k p miv sink = do
+	repo <- getRepo r
+	retrieve' repo r rsyncopts accessmethod k p miv sink
+
+retrieve' :: Git.Repo -> Remote -> Remote.Rsync.RsyncOpts -> AccessMethod -> Retriever
+retrieve' repo r rsyncopts accessmethod
+	| not $ Git.repoIsUrl repo = byteRetriever $ \k sink ->
+		guardUsable repo (giveup "cannot access remote") $
+			sink =<< liftIO (L.readFile $ gCryptLocation repo k)
+	| Git.repoIsSsh repo = if accessShell r
+		then fileRetriever $ \f k p -> do
+			ps <- Ssh.rsyncParamsRemote r Download k
+				(fromRawFilePath f)
+			oh <- mkOutputHandler
+			unlessM (Ssh.rsyncHelper oh (Just p) ps) $
+				giveup "rsync failed"
+		else retrieversync
+	| accessmethod == AccessRsyncOverSsh = retrieversync
+	| otherwise = unsupportedUrl
+  where
+	retrieversync = fileRetriever $ Remote.Rsync.retrieve rsyncopts
+
+remove :: Remote -> Remote.Rsync.RsyncOpts -> AccessMethod -> Remover
+remove r rsyncopts accessmethod k = do
+	repo <- getRepo r
+	remove' repo r rsyncopts accessmethod k
+
+remove' :: Git.Repo -> Remote -> Remote.Rsync.RsyncOpts -> AccessMethod -> Remover
+remove' repo r rsyncopts accessmethod k
+	| not $ Git.repoIsUrl repo = guardUsable repo (giveup "cannot access remote") $
+		liftIO $ Remote.Directory.removeDirGeneric True
+			(gCryptTopDir repo)
+			(fromRawFilePath (parentDir (toRawFilePath (gCryptLocation repo k))))
+	| Git.repoIsSsh repo = shellOrRsync r removeshell removersync
+	| accessmethod == AccessRsyncOverSsh = removersync
+	| otherwise = unsupportedUrl
+  where
+	removersync = Remote.Rsync.remove rsyncopts k
+	removeshell = Ssh.dropKey repo k
+
+checkKey :: Remote -> Remote.Rsync.RsyncOpts -> AccessMethod -> CheckPresent
+checkKey r rsyncopts accessmethod k = do
+	repo <- getRepo r
+	checkKey' repo r rsyncopts accessmethod k
+
+checkKey' :: Git.Repo -> Remote -> Remote.Rsync.RsyncOpts -> AccessMethod -> CheckPresent
+checkKey' repo r rsyncopts accessmethod k
+	| not $ Git.repoIsUrl repo =
+		guardUsable repo (cantCheck repo) $
+			liftIO $ doesFileExist (gCryptLocation repo k)
+	| Git.repoIsSsh repo = shellOrRsync r checkshell checkrsync
+	| accessmethod == AccessRsyncOverSsh = checkrsync
+	| otherwise = unsupportedUrl
+  where
+	checkrsync = Remote.Rsync.checkKey rsyncopts k
+	checkshell = Ssh.inAnnex repo k
+
+gCryptTopDir :: Git.Repo -> FilePath
+gCryptTopDir repo = Git.repoLocation repo </> fromRawFilePath objectDir
+
+{- Annexed objects are hashed using lower-case directories for max
+ - portability. -}
+gCryptLocation :: Git.Repo -> Key -> FilePath
+gCryptLocation repo key = gCryptTopDir repo
+	</> fromRawFilePath (keyPath key (hashDirLower def))
+
+data AccessMethod = AccessRsyncOverSsh | AccessGitAnnexShell
+	deriving (Eq)
+
+fromAccessMethod :: AccessMethod -> String
+fromAccessMethod AccessGitAnnexShell = "shell"
+fromAccessMethod AccessRsyncOverSsh = "true"
+
+toAccessMethod :: String -> AccessMethod
+toAccessMethod "shell" = AccessGitAnnexShell
+toAccessMethod _ = AccessRsyncOverSsh
+
+getGCryptUUID :: Bool -> Git.Repo -> Annex (Maybe UUID)
+getGCryptUUID fast r = do
+	dummycfg <- liftIO dummyRemoteGitConfig
+	(genUUIDInNameSpace gCryptNameSpace . encodeBS <$>) . fst
+		<$> getGCryptId fast r dummycfg
+
+coreGCryptId :: ConfigKey
+coreGCryptId = "core.gcrypt-id"
+
+{- gcrypt repos set up by git-annex as special remotes have a
+ - core.gcrypt-id setting in their config, which can be mapped back to
+ - the remote's UUID.
+ -
+ - In fast mode, only checks local repos. To check a remote repo,
+ - tries git-annex-shell and direct rsync of the git config file.
+ -
+ - (Also returns a version of input repo with its config read.) -}
+getGCryptId :: Bool -> Git.Repo -> RemoteGitConfig -> Annex (Maybe Git.GCrypt.GCryptId, Git.Repo)
+getGCryptId fast r gc
+	| Git.repoIsLocal r || Git.repoIsLocalUnknown r = extract <$>
+		liftIO (catchMaybeIO $ Git.Config.read r)
+	| not fast = extract . liftM fst3 <$> getM (eitherToMaybe <$>)
+		[ Ssh.onRemote NoConsumeStdin r (\f p -> liftIO (Git.Config.fromPipe r f p Git.Config.ConfigList), return (Left $ giveup "configlist failed")) "configlist" [] []
+		, getConfigViaRsync r gc
+		]
+	| otherwise = return (Nothing, r)
+  where
+	extract Nothing = (Nothing, r)
+	extract (Just r') = (fromConfigValue <$> Git.Config.getMaybe coreGCryptId r', r')
+
+getConfigViaRsync :: Git.Repo -> RemoteGitConfig -> Annex (Either SomeException (Git.Repo, S.ByteString, String))
+getConfigViaRsync r gc = do
+	let (rsynctransport, rsyncurl, _) = rsyncTransport r gc
+	opts <- rsynctransport
+	liftIO $ do
+		withTmpFile "tmpconfig" $ \tmpconfig _ -> do
+			void $ rsync $ opts ++
+				[ Param $ rsyncurl ++ "/config"
+				, Param tmpconfig
+				]
+			Git.Config.fromFile r tmpconfig
diff --git a/Remote/Git.hs b/Remote/Git.hs
new file mode 100644
index 0000000000..bba505e378
--- /dev/null
+++ b/Remote/Git.hs
@@ -0,0 +1,771 @@
+{- Standard git remotes.
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Remote.Git (
+	remote,
+	configRead,
+	onLocalRepo,
+) where
+
+import Annex.Common
+import Annex.Ssh
+import Types.Remote
+import Types.GitConfig
+import qualified Git
+import qualified Git.Config
+import qualified Git.Construct
+import qualified Git.Command
+import qualified Git.GCrypt
+import qualified Git.Types as Git
+import qualified Annex
+import Logs.Presence
+import Annex.Transfer
+import Annex.CopyFile
+import Annex.Verify
+import Annex.Content (verificationOfContentFailed)
+import Annex.UUID
+import qualified Annex.Content
+import qualified Annex.BranchState
+import qualified Annex.Branch
+import qualified Annex.Url as Url
+import qualified Annex.SpecialRemote.Config as SpecialRemote
+import Utility.Tmp
+import Config
+import Config.Cost
+import Annex.SpecialRemote.Config
+import Config.DynamicConfig
+import Annex.Init
+import Types.CleanupActions
+import qualified CmdLine.GitAnnexShell.Fields as Fields
+import Logs.Location
+import Utility.Metered
+import Utility.Env
+import Utility.Batch
+import Remote.Helper.Git
+import Remote.Helper.Messages
+import Remote.Helper.ExportImport
+import qualified Remote.Helper.Ssh as Ssh
+import qualified Remote.GCrypt
+import qualified Remote.GitLFS
+import qualified Remote.P2P
+import qualified Remote.Helper.P2P as P2PHelper
+import P2P.Address
+import Annex.Path
+import Creds
+import Types.NumCopies
+import Types.ProposedAccepted
+import Annex.Action
+import Messages.Progress
+
+import Control.Concurrent
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+import qualified Utility.RawFilePath as R
+import Network.URI
+
+remote :: RemoteType
+remote = RemoteType
+	{ typename = "git"
+	, enumerate = list
+	, generate = gen
+	, configParser = mkRemoteConfigParser
+		[ optionalStringParser locationField
+			(FieldDesc "url of git remote to remember with special remote")
+		]
+	, setup = gitSetup
+	, exportSupported = exportUnsupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+locationField :: RemoteConfigField
+locationField = Accepted "location"
+
+list :: Bool -> Annex [Git.Repo]
+list autoinit = do
+	c <- fromRepo Git.config
+	rs <- mapM (tweakurl c) =<< Annex.getGitRemotes
+	mapM (configRead autoinit) rs
+  where
+	annexurl r = remoteConfig r "annexurl"
+	tweakurl c r = do
+		let n = fromJust $ Git.remoteName r
+		case M.lookup (annexurl r) c of
+			Nothing -> return r
+			Just url -> inRepo $ \g ->
+				Git.Construct.remoteNamed n $
+					Git.Construct.fromRemoteLocation (Git.fromConfigValue url) False g
+
+{- Git remotes are normally set up using standard git commands, not
+ - git-annex initremote and enableremote.
+ -
+ - For initremote, probe the location to find the uuid.
+ - and set up a git remote.
+ -
+ - enableremote simply sets up a git remote using the stored location.
+ - No attempt is made to make the remote be accessible via ssh key setup,
+ - etc.
+ -}
+gitSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+gitSetup Init mu _ c _ = do
+	let location = maybe (giveup "Specify location=url") fromProposedAccepted $
+		M.lookup locationField c
+	r <- inRepo $ Git.Construct.fromRemoteLocation location False
+	r' <- tryGitConfigRead False r False
+	let u = getUncachedUUID r'
+	if u == NoUUID
+		then giveup "git repository does not have an annex uuid"
+		else if isNothing mu || mu == Just u
+			then enableRemote (Just u) c
+			else giveup "git repository does not have specified uuid"
+gitSetup (Enable _) mu _ c _ = enableRemote mu c
+gitSetup (AutoEnable _) mu _ c _ = enableRemote mu c
+
+enableRemote :: Maybe UUID -> RemoteConfig -> Annex (RemoteConfig, UUID)
+enableRemote (Just u) c = do
+	rs <- Annex.getGitRemotes
+	unless (any (\r -> Git.remoteName r == Just cname) rs) $
+		inRepo $ Git.Command.run
+			[ Param "remote"
+			, Param "add"
+			, Param cname
+			, Param clocation
+			]
+	return (c, u)
+  where
+	cname = fromMaybe (giveup "no name") (SpecialRemote.lookupName c)
+	clocation = maybe (giveup "no location") fromProposedAccepted (M.lookup locationField c)
+enableRemote Nothing _ = giveup "unable to enable git remote with no specified uuid"
+
+{- It's assumed to be cheap to read the config of non-URL remotes, so this is
+ - done each time git-annex is run in a way that uses remotes, unless
+ - annex-checkuuid is false.
+ -
+ - Conversely, the config of an URL remote is only read when there is no
+ - cached UUID value. -}
+configRead :: Bool -> Git.Repo -> Annex Git.Repo
+configRead autoinit r = do
+	gc <- Annex.getRemoteGitConfig r
+	hasuuid <- (/= NoUUID) <$> getRepoUUID r
+	annexignore <- liftIO $ getDynamicConfig (remoteAnnexIgnore gc)
+	case (repoCheap r, annexignore, hasuuid) of
+		(_, True, _) -> return r
+		(True, _, _)
+			| remoteAnnexCheckUUID gc -> tryGitConfigRead autoinit r hasuuid
+			| otherwise -> return r
+		(False, _, False) -> configSpecialGitRemotes r >>= \case
+			Nothing -> tryGitConfigRead autoinit r False
+			Just r' -> return r'
+		_ -> return r
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs
+	-- Remote.GitLFS may be used with a repo that is also encrypted
+	-- with gcrypt so is checked first.
+	| remoteAnnexGitLFS gc = Remote.GitLFS.gen r u rc gc rs
+	| Git.GCrypt.isEncrypted r = Remote.GCrypt.chainGen r u rc gc rs
+	| otherwise = case repoP2PAddress r of
+		Nothing -> do
+			st <- mkState r u gc
+			c <- parsedRemoteConfig remote rc
+			go st c <$> remoteCost gc c defcst
+		Just addr -> Remote.P2P.chainGen addr r u rc gc rs
+  where
+	defcst = if repoCheap r then cheapRemoteCost else expensiveRemoteCost
+	go st c cst = Just new
+	  where
+		new = Remote 
+			{ uuid = u
+			, cost = cst
+			, name = Git.repoDescribe r
+			, storeKey = copyToRemote new st
+			, retrieveKeyFile = copyFromRemote new st
+			, retrieveKeyFileCheap = copyFromRemoteCheap st r
+			, retrievalSecurityPolicy = RetrievalAllKeysSecure
+			, removeKey = dropKey new st
+			, lockContent = Just (lockKey new st)
+			, checkPresent = inAnnex new st
+			, checkPresentCheap = repoCheap r
+			, exportActions = exportUnsupported
+			, importActions = importUnsupported
+			, whereisKey = Nothing
+			, remoteFsck = if Git.repoIsUrl r
+				then Nothing
+				else Just $ fsckOnRemote r
+			, repairRepo = if Git.repoIsUrl r
+				then Nothing
+				else Just $ repairRemote r
+			, config = c
+			, localpath = localpathCalc r
+			, getRepo = getRepoFromState st
+			, gitconfig = gc
+			, readonly = Git.repoIsHttp r
+			, appendonly = False
+			, untrustworthy = False
+			, availability = repoAvail r
+			, remotetype = remote
+			, mkUnavailable = unavailable r u rc gc rs
+			, getInfo = gitRepoInfo new
+			, claimUrl = Nothing
+			, checkUrl = Nothing
+			, remoteStateHandle = rs
+			}
+
+unavailable :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+unavailable r = gen r'
+  where
+	r' = case Git.location r of
+		Git.Local { Git.gitdir = d } ->
+			r { Git.location = Git.LocalUnknown d }
+		Git.Url url -> case uriAuthority url of
+			Just auth -> 
+				let auth' = auth { uriRegName = "!dne!" }
+				in r { Git.location = Git.Url (url { uriAuthority = Just auth' })}
+			Nothing -> r { Git.location = Git.Unknown }
+		_ -> r -- already unavailable
+
+{- Tries to read the config for a specified remote, updates state, and
+ - returns the updated repo. -}
+tryGitConfigRead :: Bool -> Git.Repo -> Bool -> Annex Git.Repo
+tryGitConfigRead autoinit r hasuuid
+	| haveconfig r = return r -- already read
+	| Git.repoIsSsh r = storeUpdatedRemote $ do
+		v <- Ssh.onRemote NoConsumeStdin r
+			( pipedconfig Git.Config.ConfigList autoinit (Git.repoDescribe r)
+			, return (Left "configlist failed")
+			)
+			"configlist" [] configlistfields
+		case v of
+			Right r'
+				| haveconfig r' -> return r'
+				| otherwise -> configlist_failed
+			Left _ -> configlist_failed
+	| Git.repoIsHttp r = storeUpdatedRemote geturlconfig
+	| Git.GCrypt.isEncrypted r = handlegcrypt =<< getConfigMaybe (remoteAnnexConfig r "uuid")
+	| Git.repoIsUrl r = do
+		set_ignore "uses a protocol not supported by git-annex" False
+		return r
+	| otherwise = storeUpdatedRemote $
+		readlocalannexconfig
+			`catchNonAsync` const failedreadlocalconfig
+  where
+	haveconfig = not . M.null . Git.config
+
+	pipedconfig st mustincludeuuuid configloc cmd params = do
+		v <- liftIO $ Git.Config.fromPipe r cmd params st
+		case v of
+			Right (r', val, _err) -> do
+				unless (isUUIDConfigured r' || S.null val || not mustincludeuuuid) $ do
+					warning $ UnquotedString $ "Failed to get annex.uuid configuration of repository " ++ Git.repoDescribe r
+					warning $ UnquotedString $ "Instead, got: " ++ show val
+					warning "This is unexpected; please check the network transport!"
+				return $ Right r'
+			Left l -> do
+				warning $ UnquotedString $ "Unable to parse git config from " ++ configloc
+				return $ Left (show l)
+
+	geturlconfig = Url.withUrlOptionsPromptingCreds $ \uo -> do
+		let url = Git.repoLocation r ++ "/config"
+		v <- withTmpFile "git-annex.tmp" $ \tmpfile h -> do
+			liftIO $ hClose h
+			Url.download' nullMeterUpdate Nothing url tmpfile uo >>= \case
+				Right () -> pipedconfig Git.Config.ConfigNullList
+					False url "git"
+					[ Param "config"
+					, Param "--null"
+					, Param "--list"
+					, Param "--file"
+					, File tmpfile
+					]
+				Left err -> return (Left err)
+		case v of
+			Right r' -> do
+				-- Cache when http remote is not bare for
+				-- optimisation.
+				unless (fromMaybe False $ Git.Config.isBare r') $
+					setremote setRemoteBare False
+				return r'
+			Left err -> do
+				set_ignore "not usable by git-annex" False
+				warning $ UnquotedString $ url ++ " " ++ err
+				return r
+
+	{- Is this remote just not available, or does
+	 - it not have git-annex-shell?
+	 - Find out by trying to fetch from the remote. -}
+	configlist_failed = case Git.remoteName r of
+		Nothing -> return r
+		Just n -> do
+			whenM (inRepo $ Git.Command.runBool [Param "fetch", Param "--quiet", Param n]) $ do
+				set_ignore "does not have git-annex installed" True
+			return r
+	
+	set_ignore msg longmessage = do
+		case Git.remoteName r of
+			Nothing -> noop
+			Just n -> do
+				warning $ UnquotedString $ "Remote " ++ n ++ " " ++ msg ++ "; setting annex-ignore"
+				when longmessage $
+					warning $ UnquotedString $ "This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote " ++ n
+		setremote setRemoteIgnore True
+	
+	setremote setter v = case Git.remoteName r of
+		Nothing -> noop
+		Just _ -> setter r v
+	
+	handlegcrypt Nothing = return r
+	handlegcrypt (Just _cacheduuid) = do
+		-- Generate UUID from the gcrypt-id
+		g <- gitRepo
+		case Git.GCrypt.remoteRepoId g (Git.remoteName r) of
+			Nothing -> return r
+			Just v -> storeUpdatedRemote $ liftIO $ setUUID r $
+				genUUIDInNameSpace gCryptNameSpace (encodeBS v)
+
+	{- The local repo may not yet be initialized, so try to initialize
+	 - it if allowed. However, if that fails, still return the read
+	 - git config. -}
+	readlocalannexconfig = do
+		let check = do
+			Annex.BranchState.disableUpdate
+			catchNonAsync (autoInitialize (pure [])) $ \e ->
+				warning $ UnquotedString $ "Remote " ++ Git.repoDescribe r ++
+					": "  ++ show e
+			Annex.getState Annex.repo
+		let r' = r { Git.repoPathSpecifiedExplicitly = True }
+		s <- newLocal r'
+		liftIO $ Annex.eval s $ check
+			`finally` quiesce True
+		
+	failedreadlocalconfig = do
+		unless hasuuid $ case Git.remoteName r of
+			Nothing -> noop
+			Just n -> do
+				warning $ UnquotedString $ "Remote " ++ n ++ " cannot currently be accessed."
+		return r
+		
+	configlistfields = if autoinit
+		then [(Fields.autoInit, "1")]
+		else []
+
+{- Handles special remotes that can be enabled by the presence of
+ - regular git remotes.
+ -
+ - When a remote repo is found to be such a special remote, its
+ - UUID is cached in the git config, and the repo returned with
+ - the UUID set.
+ -}
+configSpecialGitRemotes :: Git.Repo -> Annex (Maybe Git.Repo)
+configSpecialGitRemotes r = Remote.GitLFS.configKnownUrl r >>= \case
+	Nothing -> return Nothing
+	Just r' -> Just <$> storeUpdatedRemote (return r')
+
+storeUpdatedRemote :: Annex Git.Repo -> Annex Git.Repo
+storeUpdatedRemote = observe $ \r' -> do
+	l <- Annex.getGitRemotes
+	let rs = exchange l r'
+	Annex.changeState $ \s -> s { Annex.gitremotes = Just rs }
+  where
+	exchange [] _ = []
+	exchange (old:ls) new
+		| Git.remoteName old == Git.remoteName new =
+			new : exchange ls new
+		| otherwise =
+			old : exchange ls new
+
+{- Checks if a given remote has the content for a key in its annex. -}
+inAnnex :: Remote -> State -> Key -> Annex Bool
+inAnnex rmt st key = do
+	repo <- getRepo rmt
+	inAnnex' repo rmt st key
+
+inAnnex' :: Git.Repo -> Remote -> State -> Key -> Annex Bool
+inAnnex' repo rmt st@(State connpool duc _ _ _) key
+	| Git.repoIsHttp repo = checkhttp
+	| Git.repoIsUrl repo = checkremote
+	| otherwise = checklocal
+  where
+	checkhttp = do
+		gc <- Annex.getGitConfig
+		Url.withUrlOptionsPromptingCreds $ \uo -> 
+			anyM (\u -> Url.checkBoth u (fromKey keySize key) uo)
+				(keyUrls gc repo rmt key)
+	checkremote = P2PHelper.checkpresent (Ssh.runProto rmt connpool (cantCheck rmt)) key
+	checklocal = ifM duc
+		( guardUsable repo (cantCheck repo) $
+			maybe (cantCheck repo) return
+				=<< onLocalFast st (Annex.Content.inAnnexSafe key)
+		, cantCheck repo
+		)
+
+keyUrls :: GitConfig -> Git.Repo -> Remote -> Key -> [String]
+keyUrls gc repo r key = map tourl locs'
+  where
+	tourl l = Git.repoLocation repo ++ "/" ++ l
+	-- If the remote is known to not be bare, try the hash locations
+	-- used for non-bare repos first, as an optimisation.
+	locs
+		| remoteAnnexBare remoteconfig == Just False = annexLocationsNonBare gc key
+		| otherwise = annexLocationsBare gc key
+#ifndef mingw32_HOST_OS
+	locs' = map fromRawFilePath locs
+#else
+	locs' = map (replace "\\" "/" . fromRawFilePath) locs
+#endif
+	remoteconfig = gitconfig r
+
+dropKey :: Remote -> State -> Key -> Annex ()
+dropKey r st key = do
+	repo <- getRepo r
+	dropKey' repo r st key
+
+dropKey' :: Git.Repo -> Remote -> State -> Key -> Annex ()
+dropKey' repo r st@(State connpool duc _ _ _) key
+	| not $ Git.repoIsUrl repo = ifM duc
+		( guardUsable repo (giveup "cannot access remote") $
+			commitOnCleanup repo r st $ onLocalFast st $ do
+				whenM (Annex.Content.inAnnex key) $ do
+					let cleanup = logStatus key InfoMissing
+					Annex.Content.lockContentForRemoval key cleanup $ \lock -> do
+						Annex.Content.removeAnnex lock
+						cleanup
+		, giveup "remote does not have expected annex.uuid value"
+		)
+	| Git.repoIsHttp repo = giveup "dropping from http remote not supported"
+	| otherwise = P2PHelper.remove (Ssh.runProto r connpool (return False)) key
+
+lockKey :: Remote -> State -> Key -> (VerifiedCopy -> Annex r) -> Annex r
+lockKey r st key callback = do
+	repo <- getRepo r
+	lockKey' repo r st key callback
+
+lockKey' :: Git.Repo -> Remote -> State -> Key -> (VerifiedCopy -> Annex r) -> Annex r
+lockKey' repo r st@(State connpool duc _ _ _) key callback
+	| not $ Git.repoIsUrl repo = ifM duc
+		( guardUsable repo failedlock $ do
+			inorigrepo <- Annex.makeRunner
+			-- Lock content from perspective of remote,
+			-- and then run the callback in the original
+			-- annex monad, not the remote's.
+			onLocalFast st $ 
+				Annex.Content.lockContentShared key $
+					liftIO . inorigrepo . callback
+		, failedlock
+		)
+	| Git.repoIsSsh repo = do
+		showLocking r
+		let withconn = Ssh.withP2PSshConnection r connpool failedlock
+		P2PHelper.lock withconn Ssh.runProtoConn (uuid r) key callback
+	| otherwise = failedlock
+  where
+	failedlock = giveup "can't lock content"
+
+{- Tries to copy a key's content from a remote's annex to a file. -}
+copyFromRemote :: Remote -> State -> Key -> AssociatedFile -> FilePath -> MeterUpdate -> VerifyConfig -> Annex Verification
+copyFromRemote r st key file dest meterupdate vc = do
+	repo <- getRepo r
+	copyFromRemote'' repo r st key file dest meterupdate vc
+
+copyFromRemote'' :: Git.Repo -> Remote -> State -> Key -> AssociatedFile -> FilePath -> MeterUpdate -> VerifyConfig -> Annex Verification
+copyFromRemote'' repo r st@(State connpool _ _ _ _) key file dest meterupdate vc
+	| Git.repoIsHttp repo = verifyKeyContentIncrementally vc key $ \iv -> do
+		gc <- Annex.getGitConfig
+		ok <- Url.withUrlOptionsPromptingCreds $
+			Annex.Content.downloadUrl False key meterupdate iv (keyUrls gc repo r key) dest
+		unless ok $
+			giveup "failed to download content"
+	| not $ Git.repoIsUrl repo = guardUsable repo (giveup "cannot access remote") $ do
+		u <- getUUID
+		hardlink <- wantHardLink
+		let bwlimit = remoteAnnexBwLimitDownload (gitconfig r)
+			<|> remoteAnnexBwLimit (gitconfig r)
+		-- run copy from perspective of remote
+		onLocalFast st $ Annex.Content.prepSendAnnex' key >>= \case
+			Just (object, _sz, check) -> do
+				let checksuccess = check >>= \case
+					Just err -> giveup err
+					Nothing -> return True
+				copier <- mkFileCopier hardlink st
+				(ok, v) <- runTransfer (Transfer Download u (fromKey id key))
+					Nothing file Nothing stdRetry $ \p ->
+						metered (Just (combineMeterUpdate p meterupdate)) key bwlimit $ \_ p' -> 
+							copier object dest key p' checksuccess vc
+				if ok
+					then return v
+					else giveup "failed to retrieve content from remote"
+			Nothing -> giveup "content is not present in remote"
+	| Git.repoIsSsh repo =
+		P2PHelper.retrieve
+			(gitconfig r)
+			(Ssh.runProto r connpool (return (False, UnVerified)))
+			key file dest meterupdate vc
+	| otherwise = giveup "copying from non-ssh, non-http remote not supported"
+
+copyFromRemoteCheap :: State -> Git.Repo -> Maybe (Key -> AssociatedFile -> FilePath -> Annex ())
+#ifndef mingw32_HOST_OS
+copyFromRemoteCheap st repo
+	| not $ Git.repoIsUrl repo = Just $ \key _af file -> guardUsable repo (giveup "cannot access remote") $ do
+		gc <- getGitConfigFromState st
+		loc <- liftIO $ gitAnnexLocation key repo gc
+		liftIO $ ifM (R.doesPathExist loc)
+			( do
+				absloc <- absPath loc
+				R.createSymbolicLink absloc (toRawFilePath file)
+			, giveup "remote does not contain key"
+			)
+	| otherwise = Nothing
+#else
+copyFromRemoteCheap _ _ = Nothing
+#endif
+
+{- Tries to copy a key's content to a remote's annex. -}
+copyToRemote :: Remote -> State -> Key -> AssociatedFile -> MeterUpdate -> Annex ()
+copyToRemote r st key file meterupdate = do
+	repo <- getRepo r
+	copyToRemote' repo r st key file meterupdate
+
+copyToRemote' :: Git.Repo -> Remote -> State -> Key -> AssociatedFile -> MeterUpdate -> Annex ()
+copyToRemote' repo r st@(State connpool duc _ _ _) key file meterupdate
+	| not $ Git.repoIsUrl repo = ifM duc
+		( guardUsable repo (giveup "cannot access remote") $ commitOnCleanup repo r st $
+			copylocal =<< Annex.Content.prepSendAnnex' key
+		, giveup "remote does not have expected annex.uuid value"
+		)
+	| Git.repoIsSsh repo =
+		P2PHelper.store (gitconfig r)
+			(Ssh.runProto r connpool (return False))
+			key file meterupdate
+		
+	| otherwise = giveup "copying to non-ssh repo not supported"
+  where
+	copylocal Nothing = giveup "content not available"
+	copylocal (Just (object, sz, check)) = do
+		-- The check action is going to be run in
+		-- the remote's Annex, but it needs access to the local
+		-- Annex monad's state.
+		checkio <- Annex.withCurrentState check
+		u <- getUUID
+		hardlink <- wantHardLink
+		let bwlimit = remoteAnnexBwLimitUpload (gitconfig r)
+			<|> remoteAnnexBwLimit (gitconfig r)
+		-- run copy from perspective of remote
+		res <- onLocalFast st $ ifM (Annex.Content.inAnnex key)
+			( return True
+			, runTransfer (Transfer Download u (fromKey id key)) Nothing file Nothing stdRetry $ \p -> do
+				let verify = RemoteVerify r
+				copier <- mkFileCopier hardlink st
+				let rsp = RetrievalAllKeysSecure
+				let checksuccess = liftIO checkio >>= \case
+					Just err -> giveup err
+					Nothing -> return True
+				logStatusAfter key $ Annex.Content.getViaTmp rsp verify key file (Just sz) $ \dest ->
+					metered (Just (combineMeterUpdate meterupdate p)) key bwlimit $ \_ p' -> 
+						copier object (fromRawFilePath dest) key p' checksuccess verify
+			)
+		unless res $
+			giveup "failed to send content to remote"
+
+fsckOnRemote :: Git.Repo -> [CommandParam] -> Annex (IO Bool)
+fsckOnRemote r params
+	| Git.repoIsUrl r = return $ return False
+	| otherwise = return $ do
+		program <- programPath
+		r' <- Git.Config.read r
+		environ <- getEnvironment
+		let environ' = addEntries 
+			[ ("GIT_WORK_TREE", fromRawFilePath $ Git.repoPath r')
+			, ("GIT_DIR", fromRawFilePath $ Git.localGitDir r')
+			] environ
+		batchCommandEnv program (Param "fsck" : params) (Just environ')
+
+{- The passed repair action is run in the Annex monad of the remote. -}
+repairRemote :: Git.Repo -> Annex Bool -> Annex (IO Bool)
+repairRemote r a = return $ do
+	s <- Annex.new r
+	Annex.eval s $ do
+		Annex.BranchState.disableUpdate
+		ensureInitialized (pure [])
+		a `finally` quiesce True
+
+data LocalRemoteAnnex = LocalRemoteAnnex Git.Repo (MVar [(Annex.AnnexState, Annex.AnnexRead)])
+
+{- This can safely be called on a Repo that is not local, but of course
+ - onLocal will not work if used with the result. -}
+mkLocalRemoteAnnex :: Git.Repo -> Annex (LocalRemoteAnnex)
+mkLocalRemoteAnnex repo = LocalRemoteAnnex repo <$> liftIO (newMVar [])
+
+{- Runs an action from the perspective of a local remote.
+ -
+ - The AnnexState is cached for speed and to avoid resource leaks.
+ - However, it is quiesced after each call to avoid git processes
+ - hanging around on removable media.
+ -
+ - The remote will be automatically initialized/upgraded first,
+ - when possible.
+ -}
+onLocal :: State -> Annex a -> Annex a
+onLocal (State _ _ _ _ lra) = onLocal' lra
+
+onLocalRepo :: Git.Repo -> Annex a -> Annex a
+onLocalRepo repo a = do
+	lra <- mkLocalRemoteAnnex repo
+	onLocal' lra a
+
+newLocal :: Git.Repo -> Annex (Annex.AnnexState, Annex.AnnexRead)
+newLocal repo = do
+	(st, rd) <- liftIO $ Annex.new repo
+	debugenabled <- Annex.getRead Annex.debugenabled
+	debugselector <- Annex.getRead Annex.debugselector
+	force <- Annex.getRead Annex.force
+	return (st,  rd
+		{ Annex.debugenabled = debugenabled
+		, Annex.debugselector = debugselector
+		, Annex.force = force
+		})
+
+onLocal' :: LocalRemoteAnnex -> Annex a -> Annex a
+onLocal' (LocalRemoteAnnex repo mv) a = liftIO (takeMVar mv) >>= \case
+	[] -> do
+		liftIO $ putMVar mv []
+		v <- newLocal repo
+		go (v, ensureInitialized (pure []) >> a)
+	(v:rest) -> do
+		liftIO $ putMVar mv rest
+		go (v, a)
+  where
+	go ((st, rd), a') = do
+		curro <- Annex.getState Annex.output
+		let act = Annex.run (st { Annex.output = curro }, rd) $
+			a' `finally` quiesce True
+		(ret, (st', _rd)) <- liftIO $ act `onException` cache (st, rd)
+		liftIO $ cache (st', rd)
+		return ret
+	cache v = do
+		l <- takeMVar mv
+		putMVar mv (v:l)
+
+{- Faster variant of onLocal.
+ -
+ - The repository's git-annex branch is not updated, as an optimisation.
+ - No caller of onLocalFast can query data from the branch and be ensured
+ - it gets the most current value. Caller of onLocalFast can make changes
+ - to the branch, however.
+ -}
+onLocalFast :: State -> Annex a -> Annex a
+onLocalFast st a = onLocal st $ Annex.BranchState.disableUpdate >> a
+
+commitOnCleanup :: Git.Repo -> Remote -> State -> Annex a -> Annex a
+commitOnCleanup repo r st a = go `after` a
+  where
+	go = Annex.addCleanupAction (RemoteCleanup $ uuid r) cleanup
+	cleanup
+		| not $ Git.repoIsUrl repo = onLocalFast st $
+			doQuietSideAction $
+				Annex.Branch.commit =<< Annex.Branch.commitMessage
+		| otherwise = noop
+
+wantHardLink :: Annex Bool
+wantHardLink = (annexHardLink <$> Annex.getGitConfig)
+	-- Not unlocked files that are hard linked in the work tree,
+	-- because they can be modified at any time.
+	<&&> (not <$> annexThin <$> Annex.getGitConfig)
+
+type FileCopier = FilePath -> FilePath -> Key -> MeterUpdate -> Annex Bool -> VerifyConfig -> Annex (Bool, Verification)
+
+-- If either the remote or local repository wants to use hard links,
+-- the copier will do so (falling back to copying if a hard link cannot be
+-- made).
+--
+-- When a hard link is created, returns Verified; the repo being linked
+-- from is implicitly trusted, so no expensive verification needs to be
+-- done. Also returns Verified if the key's content is verified while
+-- copying it.
+mkFileCopier :: Bool -> State -> Annex FileCopier
+mkFileCopier remotewanthardlink (State _ _ copycowtried _ _) = do
+	localwanthardlink <- wantHardLink
+	let linker = \src dest -> R.createLink (toRawFilePath src) (toRawFilePath dest) >> return True
+	if remotewanthardlink || localwanthardlink
+		then return $ \src dest k p check verifyconfig ->
+			ifM (liftIO (catchBoolIO (linker src dest)))
+				( ifM check
+					( return (True, Verified)
+					, do
+						verificationOfContentFailed (toRawFilePath dest)
+						return (False, UnVerified)
+					)
+				, copier src dest k p check verifyconfig
+				)
+		else return copier
+  where
+	copier src dest k p check verifyconfig = do
+		iv <- startVerifyKeyContentIncrementally verifyconfig k
+		liftIO (fileCopier copycowtried src dest p iv) >>= \case
+			Copied -> ifM check
+				( finishVerifyKeyContentIncrementally iv
+				, do
+					verificationOfContentFailed (toRawFilePath dest)
+					return (False, UnVerified)
+				)
+			CopiedCoW -> unVerified check
+
+{- Normally the UUID of a local repository is checked at startup,
+ - but annex-checkuuid config can prevent that. To avoid getting
+ - confused, a deferred check is done just before the repository
+ - is used.
+ - This returns False when the repository UUID is not as expected. -}
+type DeferredUUIDCheck = Annex Bool
+
+data State = State Ssh.P2PSshConnectionPool DeferredUUIDCheck CopyCoWTried (Annex (Git.Repo, GitConfig)) LocalRemoteAnnex
+
+getRepoFromState :: State -> Annex Git.Repo
+getRepoFromState (State _ _ _ a _) = fst <$> a
+
+#ifndef mingw32_HOST_OS
+{- The config of the remote git repository, cached for speed. -}
+getGitConfigFromState :: State -> Annex GitConfig
+getGitConfigFromState (State _ _ _ a _) = snd <$> a
+#endif
+
+mkState :: Git.Repo -> UUID -> RemoteGitConfig -> Annex State
+mkState r u gc = do
+	pool <- Ssh.mkP2PSshConnectionPool
+	copycowtried <- liftIO newCopyCoWTried
+	lra <- mkLocalRemoteAnnex r
+	(duc, getrepo) <- go
+	return $ State pool duc copycowtried getrepo lra
+  where
+	go
+		| remoteAnnexCheckUUID gc = return
+			(return True, return (r, extractGitConfig FromGitConfig r))
+		| otherwise = do
+			rv <- liftIO newEmptyMVar
+			let getrepo = ifM (liftIO $ isEmptyMVar rv)
+				( do
+					r' <- tryGitConfigRead False r True
+					let t = (r', extractGitConfig FromGitConfig r')
+					void $ liftIO $ tryPutMVar rv t
+					return t
+				, liftIO $ readMVar rv
+				)
+
+			cv <- liftIO newEmptyMVar
+			let duc = ifM (liftIO $ isEmptyMVar cv)
+				( do
+					r' <- fst <$> getrepo
+					u' <- getRepoUUID r'
+					let ok = u' == u
+					void $ liftIO $ tryPutMVar cv ok
+					unless ok $
+						warning $ UnquotedString $ Git.repoDescribe r ++ " is not the expected repository. The remote's annex-checkuuid configuration prevented noticing the change until now."
+					return ok
+				, liftIO $ readMVar cv
+				)
+
+			return (duc, getrepo)
diff --git a/Remote/GitLFS.hs b/Remote/GitLFS.hs
new file mode 100644
index 0000000000..33cbb0338e
--- /dev/null
+++ b/Remote/GitLFS.hs
@@ -0,0 +1,549 @@
+{- Using git-lfs as a remote.
+ -
+ - Copyright 2019-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE RankNTypes #-}
+
+module Remote.GitLFS (remote, gen, configKnownUrl) where
+
+import Annex.Common
+import Types.Remote
+import Annex.Url
+import Types.Key
+import Types.Creds
+import Types.ProposedAccepted
+import Types.NumCopies
+import qualified Annex
+import qualified Git
+import qualified Git.Types as Git
+import qualified Git.Url
+import qualified Git.Remote
+import qualified Git.GCrypt
+import qualified Git.Credential as Git
+import Config
+import Config.Cost
+import Annex.SpecialRemote.Config
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import Remote.Helper.Git
+import Remote.Helper.Http
+import qualified Remote.GCrypt
+import Annex.Ssh
+import Annex.UUID
+import Crypto
+import Backend.Hash
+import Utility.Hash
+import Utility.SshHost
+import Utility.Url
+import Logs.Remote
+import Logs.RemoteState
+import qualified Git.Config
+
+import qualified Network.GitLFS as LFS
+import Control.Concurrent.STM
+import Data.String
+import Network.HTTP.Types
+import Network.HTTP.Client hiding (port)
+import qualified Data.Map as M
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString.Short as S (fromShort)
+import qualified Data.Text as T
+import qualified Data.Text.Encoding as E
+import qualified Control.Concurrent.MSemN as MSemN
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "git-lfs"
+	-- Remote.Git takes care of enumerating git-lfs remotes too,
+	-- and will call our gen on them.
+	, enumerate = const (return [])
+	, generate = gen
+	, configParser = mkRemoteConfigParser
+		[ optionalStringParser urlField
+			(FieldDesc "url of git-lfs repository")
+		]
+	, setup = mySetup
+	, exportSupported = exportUnsupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+urlField :: RemoteConfigField
+urlField = Accepted "url"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	-- If the repo uses gcrypt, get the underlying repo without the
+	-- gcrypt url, to do LFS endpoint discovery on.
+	r' <- if Git.GCrypt.isEncrypted r
+		then do
+			g <- Annex.gitRepo
+			liftIO $ Git.GCrypt.encryptedRemote g r
+		else pure r
+	sem <- liftIO $ MSemN.new 1
+	h <- liftIO $ newTVarIO $ LFSHandle Nothing Nothing sem r' gc
+	cst <- remoteCost gc c expensiveRemoteCost
+	let specialcfg = (specialRemoteCfg c)
+		-- chunking would not improve git-lfs
+		{ chunkConfig = NoChunks
+		}
+	return $ Just $ specialRemote' specialcfg c
+		(store rs h)
+		(retrieve rs h)
+		(remove h)
+		(checkKey rs h)
+		(this c cst h)
+  where
+	this c cst h = Remote
+		{ uuid = u
+		, cost = cst
+		, name = Git.repoDescribe r
+		, storeKey = storeKeyDummy
+		, retrieveKeyFile = retrieveKeyFileDummy
+		, retrieveKeyFileCheap = Nothing
+		-- content stored on git-lfs is hashed with SHA256
+		-- no matter what git-annex key it's for, and the hash
+		-- is checked on download
+		, retrievalSecurityPolicy = RetrievalAllKeysSecure
+		, removeKey = removeKeyDummy
+		, lockContent = Just $ lockKey (this c cst h) rs h
+		, checkPresent = checkPresentDummy
+		, checkPresentCheap = False
+		, exportActions = exportUnsupported
+		, importActions = importUnsupported
+		, whereisKey = Nothing
+		, remoteFsck = Nothing
+		, repairRepo = Nothing
+		, config = c
+		, getRepo = return r
+		, gitconfig = gc
+		, localpath = Nothing
+		, remotetype = remote
+		, availability = pure GloballyAvailable
+		, readonly = False
+		-- content cannot be removed from a git-lfs repo
+		, appendonly = True
+		, untrustworthy = False
+		, mkUnavailable = return Nothing
+		, getInfo = gitRepoInfo (this c cst h)
+		, claimUrl = Nothing
+		, checkUrl = Nothing
+		, remoteStateHandle = rs
+		}
+
+mySetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+mySetup ss mu _ c gc = do
+	u <- maybe (liftIO genUUID) return mu
+
+	(c', _encsetup) <- encryptionSetup c gc
+	pc <- either giveup return . parseRemoteConfig c' =<< configParser remote c'
+	let failinitunlessforced msg = case ss of
+		Init -> unlessM (Annex.getRead Annex.force) (giveup msg)
+		Enable _ -> noop
+		AutoEnable _ -> noop
+	case (isEncrypted pc, Git.GCrypt.urlPrefix `isPrefixOf` url) of
+		(False, False) -> noop
+		(True, True) -> Remote.GCrypt.setGcryptEncryption pc remotename
+		(True, False) -> failinitunlessforced $ unwords $
+			[ "Encryption is enabled for this remote,"
+			, "but only the files that git-annex stores on"
+			, "it would be encrypted; "
+			, "anything that git push sends to it would"
+			, "not be encrypted. Recommend prefixing the"
+			, "url with \"gcrypt::\" to also encrypt"
+			, "git pushes."
+			, "(Use --force if you want to use this"
+			, "likely insecure configuration.)"
+			]
+		(False, True) -> failinitunlessforced $ unwords
+			[ "You used a \"gcrypt::\" url for this remote,"
+			, "but encryption=none prevents git-annex"
+			, "from encrypting files it stores there."
+			, "(Use --force if you want to use this"
+			, "likely insecure configuration.)"
+			]
+
+	-- Set up remote.name.url to point to the repo,
+	-- (so it's also usable by git as a non-special remote),
+	-- and set remote.name.annex-git-lfs = true
+	gitConfigSpecialRemote u c' [("git-lfs", "true")]
+	setConfig (remoteConfig c "url") url
+	return (c', u)
+  where
+	url = maybe (giveup "Specify url=") fromProposedAccepted 
+		(M.lookup urlField c)
+	remotename = fromJust (lookupName c)
+
+{- Check if a remote's url is one known to belong to a git-lfs repository.
+ - If so, set the necessary configuration to enable using the remote
+ - with git-lfs. -}
+configKnownUrl :: Git.Repo -> Annex (Maybe Git.Repo)
+configKnownUrl r
+	| Git.repoIsUrl r = do
+		m <- remoteConfigMap
+		g <- Annex.gitRepo
+		case Annex.SpecialRemote.Config.findByRemoteConfig (match g) m of
+			((u, _, mcu):[]) -> Just <$> go u mcu
+			_ -> return Nothing
+	| otherwise = return Nothing
+  where
+	match g c = fromMaybe False $ do
+		t <- fromProposedAccepted
+			<$> M.lookup Annex.SpecialRemote.Config.typeField c
+		u <- fromProposedAccepted
+			<$> M.lookup urlField c
+		let u' = Git.Remote.parseRemoteLocation u False g
+		return $ Git.Remote.RemoteUrl (Git.repoLocation r) == u' 
+			&& t == typename remote
+	go u mcu = do
+		r' <- set "uuid" (fromUUID u) =<< set "git-lfs" "true" r
+		case mcu of
+			Just (Annex.SpecialRemote.Config.ConfigFrom cu) ->
+				set "config-uuid" (fromUUID cu) r'
+			Nothing -> return r'
+	set k v r' = do
+		let k' = remoteAnnexConfig r' k
+		setConfig k' v
+		return $ Git.Config.store' k' (Git.ConfigValue (encodeBS v)) r'
+
+data LFSHandle = LFSHandle
+	{ downloadEndpoint :: Maybe LFS.Endpoint
+	, uploadEndpoint :: Maybe LFS.Endpoint
+	, getEndPointLock :: MSemN.MSemN Int 
+	, remoteRepo :: Git.Repo
+	, remoteGitConfig :: RemoteGitConfig
+	}
+
+-- Only let one thread at a time do endpoint discovery.
+withEndPointLock :: LFSHandle -> Annex a -> Annex a
+withEndPointLock h = bracket_
+	(liftIO $ MSemN.wait l 1)
+	(liftIO $ MSemN.signal l 1)
+  where
+	l = getEndPointLock h
+
+discoverLFSEndpoint :: LFS.TransferRequestOperation -> LFSHandle -> Annex (Maybe LFS.Endpoint)
+discoverLFSEndpoint tro h
+	| Git.repoIsSsh r = gossh
+	| Git.repoIsHttp r = gohttp
+	| otherwise = unsupportedurischeme
+  where
+  	r = remoteRepo h
+	lfsrepouri = case Git.location r of
+		Git.Url u -> u
+		_ -> giveup $ "unsupported git-lfs remote location " ++ Git.repoLocation r
+	
+	unsupportedurischeme = do
+		warning "git-lfs endpoint has unsupported URI scheme"
+		return Nothing
+	
+	gossh = case mkSshHost <$> Git.Url.hostuser r of
+		Nothing -> do
+			warning "Unable to parse ssh url for git-lfs remote."
+			return Nothing
+		Just (Left err) -> do
+			warning (UnquotedString err)
+			return Nothing
+		Just (Right hostuser) -> do
+			let port = Git.Url.port r
+			let p = fromMaybe (error "unknown path")
+				(Git.Url.path r)
+			-- Remove leading /~/ from path. That is added when
+			-- converting a scp-style repository location with
+			-- a relative path into an url, and is legal
+			-- according to git-clone(1), but github does not
+			-- support it.
+			let remotepath = if "/~/" `isPrefixOf` p
+				then drop 3 p
+				else p
+			let ps = LFS.sshDiscoverEndpointCommand remotepath tro
+			-- Note that no shellEscape is done here, because
+			-- at least github's git-lfs implementation does
+			-- not allow for shell quoting.
+			let remotecmd = unwords ps
+			(sshcommand, sshparams) <- sshCommand NoConsumeStdin (hostuser, port) (remoteGitConfig h) remotecmd
+			liftIO (tryIO (readProcess sshcommand (toCommand sshparams))) >>= \case
+				Left err -> do
+					warning $ UnquotedString $ "ssh connection to git-lfs remote failed: " ++ show err
+					return Nothing
+				Right resp -> case LFS.parseSshDiscoverEndpointResponse (fromString resp) of
+					Nothing -> do
+						warning "unexpected response from git-lfs remote when doing ssh endpoint discovery"
+						return Nothing
+					Just endpoint -> return (Just endpoint)
+	
+	-- The endpoint may or may not need http basic authentication,
+	-- which involves using git-credential to prompt for the password.
+	--
+	-- To determine if it does, make a download or upload request to
+	-- it, not including any objects in the request, and see if
+	-- the server requests authentication.
+	gohttp = case LFS.guessEndpoint lfsrepouri of
+		Nothing -> unsupportedurischeme
+		Just endpoint -> do
+			let testreq = LFS.startTransferRequest endpoint transfernothing
+			flip catchNonAsync (const (returnendpoint endpoint)) $ do
+				resp <- makeSmallAPIRequest testreq
+				if needauth (responseStatus resp)
+					then do
+						cred <- prompt $ inRepo $ Git.getUrlCredential (show lfsrepouri)
+						let endpoint' = addbasicauth (Git.credentialBasicAuth cred) endpoint
+						let testreq' = LFS.startTransferRequest endpoint' transfernothing
+						flip catchNonAsync (const (returnendpoint endpoint')) $ do
+							resp' <- makeSmallAPIRequest testreq'
+							inRepo $ if needauth (responseStatus resp')
+								then Git.rejectUrlCredential cred
+								else Git.approveUrlCredential cred
+							returnendpoint endpoint'
+					else returnendpoint endpoint
+	  where
+	  	transfernothing = LFS.TransferRequest
+			{ LFS.req_operation = tro
+			, LFS.req_transfers = [LFS.Basic]
+			, LFS.req_ref = Nothing
+			, LFS.req_objects = []
+			}
+		returnendpoint = return . Just
+
+		needauth status = status == unauthorized401
+
+		addbasicauth (Just ba) endpoint =
+			LFS.modifyEndpointRequest endpoint $
+				applyBasicAuth' ba
+		addbasicauth Nothing endpoint = endpoint
+
+-- The endpoint is cached for later use.
+getLFSEndpoint :: LFS.TransferRequestOperation -> TVar LFSHandle -> Annex (Maybe LFS.Endpoint)
+getLFSEndpoint tro hv = do
+	h <- liftIO $ atomically $ readTVar hv
+	case f h of
+		Just endpoint -> return (Just endpoint)
+		Nothing -> withEndPointLock h $ discoverLFSEndpoint tro h >>= \case
+			Just endpoint -> do
+				liftIO $ atomically $ writeTVar hv $
+					case tro of
+						LFS.RequestDownload -> 
+							h { downloadEndpoint = Just endpoint }
+						LFS.RequestUpload ->
+							h { uploadEndpoint = Just endpoint }
+				return (Just endpoint)
+			Nothing -> return Nothing
+  where
+	f = case tro of
+		LFS.RequestDownload -> downloadEndpoint
+		LFS.RequestUpload -> uploadEndpoint
+
+-- Make an API request that is expected to have a small response body.
+-- Not for use in downloading an object.
+makeSmallAPIRequest :: Request -> Annex (Response L.ByteString)
+makeSmallAPIRequest req = do
+	uo <- getUrlOptions
+	let req' = applyRequest uo req
+	fastDebug "Remote.GitLFS" (show req')
+	resp <- liftIO $ httpLbs req' (httpManager uo)
+	-- Only debug the http status code, not the json
+	-- which may include an authentication token.
+	fastDebug "Remote.GitLFS" (show $ responseStatus resp)
+	return resp
+
+sendTransferRequest
+	:: LFS.IsTransferResponseOperation op
+	=> LFS.TransferRequest
+	-> LFS.Endpoint
+	-> Annex (Either String (LFS.TransferResponse op))
+sendTransferRequest req endpoint = do
+	let httpreq = LFS.startTransferRequest endpoint req
+	httpresp <- makeSmallAPIRequest $ setRequestCheckStatus httpreq
+	return $ case LFS.parseTransferResponse (responseBody httpresp) of
+		LFS.ParsedTransferResponse resp -> Right resp
+		LFS.ParsedTransferResponseError tro -> Left $
+			T.unpack $ LFS.resperr_message tro
+		LFS.ParseFailed err -> Left err
+
+extractKeySha256 :: Key -> Maybe LFS.SHA256
+extractKeySha256 k = case fromKey keyVariety k of
+	SHA2Key (HashSize 256) (HasExt hasext)
+		| hasext -> eitherToMaybe $ E.decodeUtf8' (keyHash k)
+		| otherwise -> eitherToMaybe $ E.decodeUtf8' $ S.fromShort (fromKey keyName k)
+	_ -> Nothing
+
+-- The size of an encrypted key is the size of the input data, but we need
+-- the actual object size.
+extractKeySize :: Key -> Maybe Integer
+extractKeySize k
+	| isEncKey k = Nothing
+	| otherwise = fromKey keySize k
+
+mkUploadRequest :: RemoteStateHandle -> Key -> FilePath -> Annex (LFS.TransferRequest, LFS.SHA256, Integer)
+mkUploadRequest rs k content = case (extractKeySha256 k, extractKeySize k) of
+	(Just sha256, Just size) ->
+		ret sha256 size
+	(_, Just size) -> do
+		sha256 <- calcsha256
+		remembersha256 sha256
+		ret sha256 size
+	_ -> do
+		sha256 <- calcsha256
+		size <- liftIO $ getFileSize (toRawFilePath content)
+		rememberboth sha256 size
+		ret sha256 size
+  where
+	calcsha256 = liftIO $ T.pack . show . sha2_256 <$> L.readFile content
+	ret sha256 size = do
+		let obj = LFS.TransferRequestObject
+			{ LFS.req_oid = sha256
+			, LFS.req_size = size
+			}
+		let req = LFS.TransferRequest
+			{ LFS.req_operation = LFS.RequestUpload
+			, LFS.req_transfers = [LFS.Basic]
+			, LFS.req_ref = Nothing 
+			, LFS.req_objects = [obj]
+			}
+		return (req, sha256, size)
+	
+	remembersha256 sha256 = setRemoteState rs k (T.unpack sha256)
+	rememberboth sha256 size = setRemoteState rs k $
+		show size ++ " " ++ T.unpack sha256
+
+mkDownloadRequest :: RemoteStateHandle -> Key -> Annex (Maybe (LFS.TransferRequest, LFS.SHA256, Integer))
+mkDownloadRequest rs k = case (extractKeySha256 k, extractKeySize k) of
+	(Just sha256, Just size) -> ret sha256 size
+	(_, Just size) ->
+		remembersha256 >>= \case
+			Just sha256 -> ret sha256 size
+			Nothing -> return Nothing
+	_ -> do
+		rememberboth >>= \case
+			Just (sha256, size) -> ret sha256 size
+			Nothing -> return Nothing
+  where
+	ret sha256 size = do
+		let obj = LFS.TransferRequestObject
+			{ LFS.req_oid = sha256
+			, LFS.req_size = size
+			}
+		let req = LFS.TransferRequest
+			{ LFS.req_operation = LFS.RequestDownload
+			, LFS.req_transfers = [LFS.Basic]
+			, LFS.req_ref = Nothing 
+			, LFS.req_objects = [obj]
+			}
+		return $ Just (req, sha256, size)
+	remembersha256 = fmap T.pack <$> getRemoteState rs k
+	rememberboth = maybe Nothing parse <$> getRemoteState rs k
+	  where
+		parse s = case words s of
+			[ssize, ssha256] -> do
+				size <- readish ssize
+				return (T.pack ssha256, size)
+			_ -> Nothing
+
+store :: RemoteStateHandle -> TVar LFSHandle -> Storer
+store rs h = fileStorer $ \k src p -> getLFSEndpoint LFS.RequestUpload h >>= \case
+	Nothing -> giveup "unable to connect to git-lfs endpoint"
+	Just endpoint -> do
+		(req, sha256, size) <- mkUploadRequest rs k src
+		sendTransferRequest req endpoint >>= \case
+			Right resp -> do
+				let body (LFS.ServerSupportsChunks ssc) =
+					if ssc
+						then httpBodyStorerChunked src p
+						else RequestBodyIO $
+							httpBodyStorer src p
+				forM_ (LFS.objects resp) $
+					send body sha256 size
+			Left err -> giveup err
+  where
+	send body sha256 size tro
+		| LFS.resp_oid tro /= sha256 || LFS.resp_size tro /= size =
+			giveup "git-lfs server requested other object than the one we asked to send"
+		| otherwise = case LFS.resp_error tro of
+			Just err -> giveup $
+				T.unpack $ LFS.respobjerr_message err
+			Nothing -> case LFS.resp_actions tro of
+				Nothing -> noop
+				Just op -> case LFS.uploadOperationRequests op body sha256 size of
+					Nothing -> giveup "unable to parse git-lfs server upload url"
+					Just [] -> noop -- server already has it
+					Just reqs -> forM_ reqs $
+						makeSmallAPIRequest . setRequestCheckStatus
+
+retrieve :: RemoteStateHandle -> TVar LFSHandle -> Retriever
+retrieve rs h = fileRetriever' $ \dest k p iv -> getLFSEndpoint LFS.RequestDownload h >>= \case
+	Nothing -> giveup "unable to connect to git-lfs endpoint"
+	Just endpoint -> mkDownloadRequest rs k >>= \case
+		Nothing -> giveup "unable to download this object from git-lfs"
+		Just (req, sha256, size) -> sendTransferRequest req endpoint >>= \case
+			Left err -> giveup (show err)
+			Right resp -> case LFS.objects resp of
+				[] -> giveup "git-lfs server did not provide a way to download this object"
+				(tro:_)
+					| LFS.resp_oid tro /= sha256 || LFS.resp_size tro /= size ->
+						giveup "git-lfs server replied with other object than the one we requested"
+					| otherwise -> go dest p iv tro
+  where
+	go dest p iv tro = case LFS.resp_error tro of
+		Just err -> giveup $ T.unpack $ LFS.respobjerr_message err
+		Nothing -> case LFS.resp_actions tro of
+			Nothing -> giveup "git-lfs server did not provide a way to download this object"
+			Just op -> case LFS.downloadOperationRequest op of
+				Nothing -> giveup "unable to parse git-lfs server download url"
+				Just req -> do
+					uo <- getUrlOptions
+					liftIO $ downloadConduit p iv req (fromRawFilePath dest) uo
+
+-- Since git-lfs does not support removing content, nothing needs to be
+-- done to lock content in the remote, except for checking that the content
+-- is actually present.
+lockKey :: Remote -> RemoteStateHandle -> TVar LFSHandle -> Key -> (VerifiedCopy -> Annex a) -> Annex a
+lockKey r rs h key callback = 
+	ifM (checkKey rs h key)
+		( withVerifiedCopy LockedCopy (uuid r) (return True) callback
+		, giveup $ "content seems to be missing from " ++ name r
+		)
+
+checkKey :: RemoteStateHandle -> TVar LFSHandle -> CheckPresent
+checkKey rs h key = getLFSEndpoint LFS.RequestDownload h >>= \case
+	Nothing -> giveup "unable to connect to git-lfs endpoint"
+	Just endpoint -> mkDownloadRequest rs key >>= \case
+		-- Unable to find enough information to request the key
+		-- from git-lfs, so it's not present there.
+		Nothing -> return False
+		Just (req, sha256, size) -> go sha256 size 
+			=<< makeSmallAPIRequest (LFS.startTransferRequest endpoint req)
+  where
+	go sha256 size httpresp
+		| responseStatus httpresp == status200 = go' sha256 size $
+			LFS.parseTransferResponse (responseBody httpresp)
+		| otherwise = giveup $
+			"git-lfs server refused request: " ++ show (responseStatus httpresp)
+	
+	go' :: LFS.SHA256 -> Integer -> LFS.ParsedTransferResponse LFS.DownloadOperation -> Annex Bool
+	go' _ _ (LFS.ParseFailed err) =
+		giveup $ "unable to parse response from git-lfs server: " ++ err
+	-- If the server responds with a json error message,
+	-- the content is presumably not present.
+	go' _ _ (LFS.ParsedTransferResponseError _) = return False
+	-- If the server responds with at least one download operation,
+	-- we will assume the content is present. We could also try to HEAD
+	-- that download, but there's no guarantee HEAD is supported, and
+	-- at most that would detect breakage where the server is confused
+	-- about what objects it has.
+	go' sha256 size (LFS.ParsedTransferResponse resp) =
+		case LFS.objects resp of
+			[] -> return False
+			(tro:_)
+				| isNothing (LFS.resp_actions tro) -> return False
+				| isJust (LFS.resp_error tro) -> return False
+				| LFS.resp_oid tro /= sha256 || LFS.resp_size tro /= size ->
+					giveup "git-lfs server replied with other object than the one we requested"
+				| otherwise -> return True
+
+remove :: TVar LFSHandle -> Remover
+remove _h _key = giveup "git-lfs does not support removing content"
diff --git a/Remote/Glacier.hs b/Remote/Glacier.hs
new file mode 100644
index 0000000000..18bd65f21b
--- /dev/null
+++ b/Remote/Glacier.hs
@@ -0,0 +1,367 @@
+{- Amazon Glacier remotes.
+ -
+ - Copyright 2012-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+
+module Remote.Glacier (remote, jobList, checkSaneGlacierCommand) where
+
+import qualified Data.Map as M
+import qualified Data.Text as T
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+
+import Annex.Common
+import Types.Remote
+import qualified Git
+import Config
+import Config.Cost
+import Annex.SpecialRemote.Config
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import qualified Remote.Helper.AWS as AWS
+import Creds
+import Utility.Metered
+import Annex.UUID
+import Utility.Env
+import Types.ProposedAccepted
+import Utility.Hash (IncrementalVerifier)
+
+type Vault = String
+type Archive = FilePath
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "glacier"
+	, enumerate = const (findSpecialRemotes "glacier")
+	, generate = gen
+	, configParser = mkRemoteConfigParser
+		[ optionalStringParser datacenterField
+			(FieldDesc "S3 datacenter to use")
+		, optionalStringParser vaultField
+			(FieldDesc "name to use for vault")
+		, optionalStringParser fileprefixField
+			(FieldDesc "prefix to add to filenames in the vault")
+		, optionalStringParser AWS.s3credsField HiddenField
+		]
+	, setup = glacierSetup
+	, exportSupported = exportUnsupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+datacenterField :: RemoteConfigField
+datacenterField = Accepted "datacenter"
+	
+vaultField :: RemoteConfigField
+vaultField = Accepted "vault"
+
+fileprefixField :: RemoteConfigField
+fileprefixField = Accepted "fileprefix"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	cst <- remoteCost gc c veryExpensiveRemoteCost
+	return (new c cst)
+  where
+	new c cst = Just $ specialRemote' specialcfg c
+		(store this)
+		(retrieve this)
+		(remove this)
+		(checkKey this)
+		this
+	  where
+		this = Remote
+			{ uuid = u
+			, cost = cst
+			, name = Git.repoDescribe r
+			, storeKey = storeKeyDummy
+			, retrieveKeyFile = retrieveKeyFileDummy
+			, retrieveKeyFileCheap = Nothing
+			-- glacier-cli does not follow redirects and does
+			-- not support file://, as far as we know, but
+			-- there's no guarantee that will continue to be
+			-- the case, so require verifiable keys.
+			, retrievalSecurityPolicy = mkRetrievalVerifiableKeysSecure gc
+			, removeKey = removeKeyDummy
+			, lockContent = Nothing
+			, checkPresent = checkPresentDummy
+			, checkPresentCheap = False
+			, exportActions = exportUnsupported
+			, importActions = importUnsupported
+			, whereisKey = Nothing
+			, remoteFsck = Nothing
+			, repairRepo = Nothing
+			, config = c
+			, getRepo = return r
+			, gitconfig = gc
+			, localpath = Nothing
+			, readonly = False
+			, appendonly = False
+			, untrustworthy = False
+			, availability = pure GloballyAvailable
+			, remotetype = remote
+			, mkUnavailable = return Nothing
+			, getInfo = includeCredsInfo c (AWS.creds u) $
+				[ ("glacier vault", getVault c) ]
+			, claimUrl = Nothing
+			, checkUrl = Nothing
+			, remoteStateHandle = rs
+			}
+		specialcfg = (specialRemoteCfg c)
+			-- Disabled until jobList gets support for chunks.
+			{ chunkConfig = NoChunks
+			}
+
+glacierSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+glacierSetup ss mu mcreds c gc = do
+	u <- maybe (liftIO genUUID) return mu
+	glacierSetup' ss u mcreds c gc
+glacierSetup' :: SetupStage -> UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+glacierSetup' ss u mcreds c gc = do
+	(c', encsetup) <- encryptionSetup (c `M.union` defaults) gc
+	pc <- either giveup return . parseRemoteConfig c'
+		=<< configParser remote c'
+	c'' <- setRemoteCredPair ss encsetup pc gc (AWS.creds u) mcreds
+	pc' <- either giveup return . parseRemoteConfig c''
+		=<< configParser remote c''
+	case ss of
+		Init -> genVault pc' gc u
+		_ -> return ()
+	gitConfigSpecialRemote u c'' [("glacier", "true")]
+	return (c'', u)
+  where
+	remotename = fromJust (lookupName c)
+	defvault = remotename ++ "-" ++ fromUUID u
+	defaults = M.fromList
+		[ (datacenterField, Proposed $ T.unpack $ AWS.defaultRegion AWS.Glacier)
+		, (vaultField, Proposed defvault)
+		]
+
+store :: Remote -> Storer
+store r k b p = do
+	checkNonEmpty k
+	byteStorer (store' r) k b p
+
+checkNonEmpty :: Key -> Annex ()
+checkNonEmpty k
+	| fromKey keySize k == Just 0 =
+		giveup "Cannot store empty files in Glacier."
+	| otherwise = return ()
+
+store' :: Remote -> Key -> L.ByteString -> MeterUpdate -> Annex ()
+store' r k b p = go =<< glacierEnv c gc u
+  where
+	c = config r
+	gc = gitconfig r
+	u = uuid r
+	params = glacierParams c
+		[ Param "archive"
+		, Param "upload"
+		, Param "--name", Param $ archive r k
+		, Param $ getVault $ config r
+		, Param "-"
+		]
+	go Nothing = giveup "Glacier not usable."
+	go (Just e) =
+		let cmd = (proc "glacier" (toCommand params)) { env = Just e }
+			{ std_in = CreatePipe }
+		in liftIO $ withCreateProcess cmd (go' cmd)
+	go' cmd (Just hin) _ _ pid = do
+		meteredWrite p (S.hPut hin) b
+		hClose hin
+		forceSuccessProcess cmd pid
+	go' _ _ _ _ _ = error "internal"
+
+retrieve :: forall a. Remote -> Key -> MeterUpdate -> Maybe IncrementalVerifier -> (ContentSource -> Annex a) -> Annex a
+retrieve = byteRetriever . retrieve'
+
+retrieve' :: forall a. Remote -> Key -> (L.ByteString -> Annex a) -> Annex a
+retrieve' r k sink = go =<< glacierEnv c gc u
+  where
+	c = config r
+	gc = gitconfig r
+	u = uuid r
+	params = glacierParams c
+		[ Param "archive"
+		, Param "retrieve"
+		, Param "-o-"
+		, Param $ getVault $ config r
+		, Param $ archive r k
+		]
+	go Nothing = giveup "cannot retrieve from glacier"
+	go (Just environ) = do
+		let p = (proc "glacier" (toCommand params))
+			{ env = Just environ
+			, std_out = CreatePipe
+			}
+		bracketIO (createProcess p) cleanupProcess (go' p)
+	go' p (_, Just h, _, pid) = do
+		let cleanup = liftIO $ do
+			hClose h
+			forceSuccessProcess p pid
+		flip finally cleanup $ do
+			-- Glacier cannot store empty files, so if
+			-- the output is empty, the content is not
+			-- available yet.
+			whenM (liftIO $ hIsEOF h) $
+				giveup "Content is not available from glacier yet. Recommend you wait up to 4 hours, and then run this command again."
+			sink =<< liftIO (L.hGetContents h)
+	go' _ _ = error "internal"
+
+remove :: Remote -> Remover
+remove r k = unlessM go $
+	giveup "removal from glacier failed"
+  where
+	go = glacierAction r
+		[ Param "archive"
+		, Param "delete"
+		, Param $ getVault $ config r
+		, Param $ archive r k
+		]
+
+checkKey :: Remote -> CheckPresent
+checkKey r k = go =<< glacierEnv (config r) (gitconfig r) (uuid r)
+  where
+	go Nothing = giveup "cannot check glacier"
+	go (Just e) = do
+		{- glacier checkpresent outputs the archive name to stdout if
+		 - it's present. -}
+		s <- liftIO $ readProcessEnv "glacier" (toCommand params) (Just e)
+		let probablypresent = serializeKey k `elem` lines s
+		if probablypresent
+			then giveup untrusted
+			else return False
+
+	params = glacierParams (config r)
+		[ Param "archive"
+		, Param "checkpresent"
+		, Param $ getVault $ config r
+		, Param "--quiet"
+		, Param $ archive r k
+		]
+
+	untrusted = unlines
+			[ "Glacier's inventory says it has a copy."
+			, "However, the inventory could be out of date, if it was recently removed."
+			]
+
+glacierAction :: Remote -> [CommandParam] -> Annex Bool
+glacierAction r = runGlacier (config r) (gitconfig r) (uuid r)
+
+runGlacier :: ParsedRemoteConfig -> RemoteGitConfig -> UUID -> [CommandParam] -> Annex Bool
+runGlacier c gc u params = go =<< glacierEnv c gc u
+  where
+	go Nothing = return False
+	go (Just e) = liftIO $
+		boolSystemEnv "glacier" (glacierParams c params) (Just e)
+
+glacierParams :: ParsedRemoteConfig -> [CommandParam] -> [CommandParam]
+glacierParams c params = datacenter:params
+  where
+	datacenter = Param $ "--region=" ++
+		fromMaybe (giveup "Missing datacenter configuration")
+			(getRemoteConfigValue datacenterField c)
+
+glacierEnv :: ParsedRemoteConfig -> RemoteGitConfig -> UUID -> Annex (Maybe [(String, String)])
+glacierEnv c gc u = do
+	liftIO checkSaneGlacierCommand
+	go =<< getRemoteCredPairFor "glacier" c gc creds
+  where
+	go Nothing = return Nothing
+	go (Just (user, pass)) = do
+		e <- liftIO getEnvironment
+		return $ Just $ addEntries [(uk, user), (pk, pass)] e
+
+	creds = AWS.creds u
+	(uk, pk) = credPairEnvironment creds
+
+getVault :: ParsedRemoteConfig -> Vault
+getVault = fromMaybe (giveup "Missing vault configuration") 
+	. getRemoteConfigValue vaultField
+
+archive :: Remote -> Key -> Archive
+archive r k = fileprefix ++ serializeKey k
+  where
+	fileprefix = fromMaybe "" $
+		getRemoteConfigValue fileprefixField $ config r
+
+genVault :: ParsedRemoteConfig -> RemoteGitConfig -> UUID -> Annex ()
+genVault c gc u = unlessM (runGlacier c gc u params) $
+	giveup "Failed creating glacier vault."
+  where
+	params = 
+		[ Param "vault"
+		, Param "create"
+		, Param $ getVault c
+		]
+
+{- Partitions the input list of keys into ones which have
+ - glacier retieval jobs that have succeeded, or failed.
+ -
+ - A complication is that `glacier job list` will display the encrypted
+ - keys when the remote is encrypted.
+ -
+ - Dealing with encrypted chunked keys would be tricky. However, there
+ - seems to be no benefit to using chunking with glacier, so chunking is
+ - not supported.
+ -}
+jobList :: Remote -> [Key] -> Annex ([Key], [Key])
+jobList r keys = go =<< glacierEnv (config r) (gitconfig r) (uuid r)
+  where
+	params = [ Param "job", Param "list" ]
+	nada = ([], [])
+	myvault = getVault $ config r
+
+	go Nothing = return nada
+	go (Just e) = do
+		v <- liftIO $ catchMaybeIO $ 
+			readProcessEnv "glacier" (toCommand params) (Just e)
+		maybe (return nada) extract v
+
+	extract s = do
+		let result@(succeeded, failed) =
+			parse nada $ (map words . lines) s
+		if result == nada
+			then return nada
+			else do
+				enckeys <- forM keys $ \k ->
+					maybe k (\(_, enck) -> enck k)
+						<$> cipherKey (config r) (gitconfig r)
+				let keymap = M.fromList $ zip enckeys keys
+				let convert = mapMaybe (`M.lookup` keymap)
+				return (convert succeeded, convert failed)
+
+	parse c [] = c
+	parse c@(succeeded, failed) ((status:_date:vault:key:[]):rest)
+		| vault == myvault =
+			case deserializeKey key of
+				Nothing -> parse c rest
+				Just k
+					| "a/d" `isPrefixOf` status ->
+						parse (k:succeeded, failed) rest
+					| "a/e" `isPrefixOf` status ->
+						parse (succeeded, k:failed) rest
+					| otherwise ->
+						parse c rest
+	parse c (_:rest) = parse c rest
+
+-- boto's version of glacier exits 0 when given a parameter it doesn't
+-- understand. See https://github.com/boto/boto/issues/2942
+checkSaneGlacierCommand :: IO ()
+checkSaneGlacierCommand = 
+	whenM ((Nothing /=) <$> catchMaybeIO shouldfail) $
+		giveup wrongcmd
+  where
+	test = proc "glacier" ["--compatibility-test-git-annex"]
+	shouldfail = withNullHandle $ \nullh ->
+		let p = test
+			{ std_out = UseHandle nullh
+			, std_err = UseHandle nullh
+			}
+		in withCreateProcess p $ \_ _ _ -> forceSuccessProcess p
+	wrongcmd = "The glacier program in PATH seems to be from boto, not glacier-cli. Cannot use this program."
diff --git a/Remote/Helper/AWS.hs b/Remote/Helper/AWS.hs
new file mode 100644
index 0000000000..500323ff2e
--- /dev/null
+++ b/Remote/Helper/AWS.hs
@@ -0,0 +1,86 @@
+{- Amazon Web Services common infrastructure.
+ -
+ - Copyright 2011-2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE TupleSections #-}
+
+module Remote.Helper.AWS where
+
+import Annex.Common
+import Creds
+import Types.ProposedAccepted
+import Types.RemoteConfig
+
+import qualified Data.Map as M
+import qualified Data.ByteString as B
+import qualified Data.Text as T
+import Data.Text.Encoding (encodeUtf8)
+import Data.Text (Text)
+
+creds :: UUID -> CredPairStorage
+creds u = CredPairStorage
+	{ credPairFile = fromUUID u
+	, credPairEnvironment = ("AWS_ACCESS_KEY_ID", "AWS_SECRET_ACCESS_KEY")
+	, credPairRemoteField = s3credsField
+	}
+
+s3credsField :: RemoteConfigField
+s3credsField = Accepted "s3creds"
+
+data Service = S3 | Glacier
+	deriving (Eq)
+
+type Region = Text
+
+regionMap :: Service -> M.Map Text Region
+regionMap = M.fromList . regionInfo
+
+defaultRegion :: Service -> Region
+defaultRegion = snd . Prelude.head . regionInfo
+
+data ServiceRegion = BothRegion Region | S3Region Region | GlacierRegion Region
+
+{- The "US" and "EU" names are used as location constraints when creating a
+ - S3 bucket. -}
+regionInfo :: Service -> [(Text, Region)]
+regionInfo service = map (\(t, r) -> (t, fromServiceRegion r)) $ 
+	filter (matchingService . snd) $
+	concatMap (\(t, l) -> map (t,) l) regions
+  where
+	regions =
+		[ ("US East (N. Virginia)", [S3Region "US", GlacierRegion "us-east-1"])
+		, ("US West (Oregon)", [BothRegion "us-west-2"])
+		, ("US West (N. California)", [BothRegion "us-west-1"])
+		, ("EU (Ireland)", [S3Region "EU", GlacierRegion "eu-west-1"])
+		, ("Asia Pacific (Singapore)", [S3Region "ap-southeast-1"])
+		, ("Asia Pacific (Tokyo)", [BothRegion "ap-northeast-1"])
+		, ("Asia Pacific (Sydney)", [S3Region "ap-southeast-2"])
+		, ("South America (São Paulo)", [S3Region "sa-east-1"])
+		-- These need signature V4 to be used, and currently v2 is
+		-- the default, so to add these would need other changes.
+		-- , ("EU (Frankfurt)", [BothRegion "eu-central-1"])
+		-- , ("Asia Pacific (Seoul)", [S3Region "ap-northeast-2"])
+		-- , ("Asia Pacific (Mumbai)", [S3Region "ap-south-1"])
+		-- , ("US East (Ohio)", [S3Region "us-east-2"])
+		]
+
+	fromServiceRegion (BothRegion s) = s
+	fromServiceRegion (S3Region s) = s
+	fromServiceRegion (GlacierRegion s) = s
+
+	matchingService (BothRegion _) = True
+	matchingService (S3Region _) = service == S3
+	matchingService (GlacierRegion _) = service == Glacier
+
+s3HostName :: Region -> B.ByteString
+s3HostName "US" = "s3.amazonaws.com"
+s3HostName "EU" = "s3-eu-west-1.amazonaws.com"
+s3HostName "cn-north-1" = "s3.cn-north-1.amazonaws.com.cn"
+s3HostName r = encodeUtf8 $ T.concat ["s3-", r, ".amazonaws.com"]
+
+s3DefaultHost :: String
+s3DefaultHost = "s3.amazonaws.com"
diff --git a/Remote/Helper/Chunked.hs b/Remote/Helper/Chunked.hs
new file mode 100644
index 0000000000..bb903b7266
--- /dev/null
+++ b/Remote/Helper/Chunked.hs
@@ -0,0 +1,580 @@
+{- git-annex chunked remotes
+ -
+ - Copyright 2014-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+
+module Remote.Helper.Chunked (
+	ChunkSize,
+	ChunkConfig(..),
+	noChunks,
+	describeChunkConfig,
+	chunkConfigParsers,
+	getChunkConfig,
+	storeChunks,
+	removeChunks,
+	retrieveChunks,
+	checkPresentChunks,
+	chunkField,
+) where
+
+import Annex.Common
+import qualified Annex
+import Utility.DataUnits
+import Types.StoreRetrieve
+import Types.Remote
+import Types.ProposedAccepted
+import Logs.Chunk
+import Utility.Metered
+import Crypto
+import Backend (isStableKey)
+import Annex.SpecialRemote.Config
+import Annex.Verify
+import qualified Utility.RawFilePath as R
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+
+data ChunkConfig
+	= NoChunks
+	| UnpaddedChunks ChunkSize
+	| LegacyChunks ChunkSize
+	deriving (Show)
+
+describeChunkConfig :: ChunkConfig -> String
+describeChunkConfig NoChunks = "none"
+describeChunkConfig (UnpaddedChunks sz) = describeChunkSize sz ++ " chunks"
+describeChunkConfig (LegacyChunks sz) = describeChunkSize sz ++ " chunks (old style)"
+
+describeChunkSize :: ChunkSize -> String
+describeChunkSize sz = roughSize storageUnits False (fromIntegral sz)
+
+noChunks :: ChunkConfig -> Bool
+noChunks NoChunks = True
+noChunks _ = False
+
+chunkConfigParsers :: [RemoteConfigFieldParser]
+chunkConfigParsers =
+	[ optionalStringParser chunksizeField HiddenField -- deprecated
+	, optionalStringParser chunkField
+		(FieldDesc "size of chunks (eg, 1MiB)")
+	]
+
+getChunkConfig :: ParsedRemoteConfig -> ChunkConfig
+getChunkConfig c =
+	case getRemoteConfigValue chunksizeField c of
+		Nothing -> case getRemoteConfigValue chunkField c of
+			Nothing -> NoChunks
+			Just v -> readsz UnpaddedChunks v chunkField
+		Just v -> readsz LegacyChunks v chunksizeField
+  where
+	readsz mk v f = case readSize dataUnits v of
+		Just size
+			| size == 0 -> NoChunks
+			| size > 0 -> mk (fromInteger size)
+		_ -> giveup $ "bad configuration " ++ fromProposedAccepted f ++ "=" ++ v
+
+-- An infinite stream of chunk keys, starting from chunk 1.
+newtype ChunkKeyStream = ChunkKeyStream [Key]
+
+chunkKeyStream :: Key -> ChunkSize -> ChunkKeyStream
+chunkKeyStream basek chunksize = ChunkKeyStream $ map mk [1..]
+  where
+	mk chunknum = alterKey sizedk $ \d -> d
+		{ keyChunkNum = Just chunknum }
+	sizedk = alterKey basek $ \d -> d
+		{ keyChunkSize = Just (toInteger chunksize) }
+
+nextChunkKeyStream :: ChunkKeyStream -> (Key, ChunkKeyStream)
+nextChunkKeyStream (ChunkKeyStream (k:l)) = (k, ChunkKeyStream l)
+nextChunkKeyStream (ChunkKeyStream []) = error "expected infinite ChunkKeyStream"
+
+takeChunkKeyStream :: ChunkCount -> ChunkKeyStream -> [Key]
+takeChunkKeyStream n (ChunkKeyStream l) = genericTake n l
+
+-- Number of chunks already consumed from the stream.
+numChunks :: ChunkKeyStream -> Integer
+numChunks = pred . fromJust . fromKey keyChunkNum . fst . nextChunkKeyStream
+
+{- Splits up the key's content into chunks, passing each chunk to
+ - the storer action, along with a corresponding chunk key and a
+ - progress meter update callback.
+ -
+ - To support resuming, the checker is used to find the first missing
+ - chunk key. Storing starts from that chunk.
+ -
+ - This buffers each chunk in memory, so can use a lot of memory
+ - with a large ChunkSize.
+ - More optimal versions of this can be written, that rely
+ - on L.toChunks to split the lazy bytestring into chunks (typically
+ - smaller than the ChunkSize), and eg, write those chunks to a Handle.
+ - But this is the best that can be done with the storer interface that
+ - writes a whole L.ByteString at a time.
+ -}
+storeChunks
+	:: LensEncParams encc
+	=> UUID
+	-> ChunkConfig
+	-> EncKey
+	-> Key
+	-> FilePath
+	-> MeterUpdate
+	-> Maybe (Cipher, EncKey)
+	-> encc
+	-> Storer
+	-> CheckPresent
+	-> Annex ()
+storeChunks u chunkconfig encryptor k f p enc encc storer checker = 
+	case chunkconfig of
+		-- Only stable keys are safe to store chunked,
+		-- because an unstable key can have multiple different
+		-- objects, and mixing up chunks from them would be
+		-- possible without this check.
+		(UnpaddedChunks chunksize) -> ifM (isStableKey k)
+			( do
+				h <- liftIO $ openBinaryFile f ReadMode
+				go chunksize h
+				liftIO $ hClose h
+			, storechunk k (FileContent f) p
+			)
+		_ -> storechunk k (FileContent f) p
+  where
+	go chunksize h = do
+		let chunkkeys = chunkKeyStream k chunksize
+		(chunkkeys', startpos) <- seekResume h encryptor chunkkeys checker
+		b <- liftIO $ L.hGetContents h
+		gochunks p startpos chunksize b chunkkeys'
+
+	gochunks :: MeterUpdate -> BytesProcessed -> ChunkSize -> L.ByteString -> ChunkKeyStream -> Annex ()
+	gochunks meterupdate startpos chunksize = loop startpos . splitchunk
+	  where
+		splitchunk = L.splitAt chunksize
+	
+		loop bytesprocessed (chunk, bs) chunkkeys
+			| L.null chunk && numchunks > 0 = do
+				-- Once all chunks are successfully
+				-- stored, update the chunk log.
+				chunksStored u k (FixedSizeChunks chunksize) numchunks
+			| otherwise = do
+				let (chunkkey, chunkkeys') = nextChunkKeyStream chunkkeys
+				storechunk chunkkey (ByteContent chunk) meterupdate'
+				liftIO $ meterupdate' zeroBytesProcessed
+				let bytesprocessed' = addBytesProcessed bytesprocessed (L.length chunk)
+				loop bytesprocessed' (splitchunk bs) chunkkeys'
+		  where
+			numchunks = numChunks chunkkeys
+			{- The MeterUpdate that is passed to the action
+			 - storing a chunk is offset, so that it reflects
+			 - the total bytes that have already been stored
+			 - in previous chunks. -}
+			meterupdate' = offsetMeterUpdate meterupdate bytesprocessed
+
+	storechunk ck content meterupdate = case enc of
+		Nothing -> storer ck content meterupdate
+		(Just (cipher, enck)) -> do
+			cmd <- gpgCmd <$> Annex.getGitConfig
+			withBytes content $ \b ->
+				encrypt cmd encc cipher (feedBytes b) $
+					readBytes $ \encb ->
+						storer (enck ck) (ByteContent encb) meterupdate
+
+{- Check if any of the chunk keys are present. If found, seek forward
+ - in the Handle, so it will be read starting at the first missing chunk.
+ - Returns the ChunkKeyStream truncated to start at the first missing
+ - chunk, and the number of bytes skipped due to resuming.
+ -
+ - As an optimisation, if the file fits into a single chunk, there's no need
+ - to check if that chunk is present -- we know it's not, because otherwise
+ - the whole file would be present and there would be no reason to try to
+ - store it.
+ -}
+seekResume
+	:: Handle
+	-> EncKey
+	-> ChunkKeyStream
+	-> CheckPresent
+	-> Annex (ChunkKeyStream, BytesProcessed)
+seekResume h encryptor chunkkeys checker = do
+	sz <- liftIO (hFileSize h)
+	if sz <= fromMaybe 0 (fromKey keyChunkSize $ fst $ nextChunkKeyStream chunkkeys)
+		then return (chunkkeys, zeroBytesProcessed)
+		else check 0 chunkkeys sz
+  where
+	check pos cks sz
+		| pos >= sz = do
+			-- All chunks are already stored!
+			liftIO $ hSeek h AbsoluteSeek sz
+			return (cks, toBytesProcessed sz)
+		| otherwise = do
+			v <- tryNonAsync (checker (encryptor k))
+			case v of
+				Right True ->
+					check pos' cks' sz
+				_ -> do
+					when (pos > 0) $
+						liftIO $ hSeek h AbsoluteSeek pos
+					return (cks, toBytesProcessed pos)
+	  where
+		(k, cks') = nextChunkKeyStream cks
+		pos' = pos + fromMaybe 0 (fromKey keyChunkSize k)
+
+{- Removes all chunks of a key from a remote, by calling a remover
+ - action on each.
+ -
+ - This action may be called on a chunked key. It will simply remove it.
+ -}
+removeChunks :: Remover -> UUID -> ChunkConfig -> EncKey -> Key -> Annex ()
+removeChunks remover u chunkconfig encryptor k = do
+	ls <- map chunkKeyList <$> chunkKeys u chunkconfig k
+	mapM_ (remover . encryptor) (concat ls)
+	let chunksizes = catMaybes $ map (fromKey keyChunkSize <=< headMaybe) ls
+	forM_ chunksizes $ chunksRemoved u k . FixedSizeChunks . fromIntegral
+
+{- Retrieves a key from a remote, using a retriever action.
+ -
+ - When the remote is chunked, tries each of the options returned by
+ - chunkKeys until it finds one where the retriever successfully
+ - gets the first chunked key.
+ -
+ - If retrieval of one of the subsequent chunks throws an exception,
+ - gives up. Note that partial data may have been written to the file
+ - in this case.
+ -
+ - Resuming is supported when using chunks. When the destination file
+ - already exists, it skips to the next chunked key that would be needed
+ - to resume.
+ -
+ - Handles decrypting the content when encryption is used.
+ -}
+retrieveChunks 
+	:: LensEncParams encc
+	=> Retriever
+	-> UUID
+	-> VerifyConfig
+	-> ChunkConfig
+	-> EncKey
+	-> Key
+	-> FilePath
+	-> MeterUpdate
+	-> Maybe (Cipher, EncKey)
+	-> encc
+	-> Annex Verification
+retrieveChunks retriever u vc chunkconfig encryptor basek dest basep enc encc
+	| noChunks chunkconfig = do
+		-- Optimisation: Try the unchunked key first, to avoid
+		-- looking in the git-annex branch for chunk counts
+		-- that are likely not there.
+		tryNonAsync getunchunked >>= \case
+			Right r -> finalize r
+			Left e -> go (Just e)
+				=<< chunkKeysOnly u chunkconfig basek
+	| otherwise = go Nothing 
+		=<< chunkKeys u chunkconfig basek
+  where
+	go pe cks = do
+		let ls = map chunkKeyList cks
+		currsize <- liftIO $ catchMaybeIO $ getFileSize (toRawFilePath dest)
+		let ls' = maybe ls (setupResume ls) currsize
+		if any null ls'
+			-- dest is already complete
+			then finalize (Right Nothing)
+			else finalize =<< firstavail pe currsize ls'
+
+	firstavail Nothing _ [] = giveup "unable to determine the chunks to use for this remote"
+	firstavail (Just e) _ [] = throwM e
+	firstavail pe currsize ([]:ls) = firstavail pe currsize ls
+	firstavail pe currsize ((k:ks):ls)
+		| k == basek = getunchunked
+			`catchNonAsync` (\e -> firstavail (Just (pickerr e)) currsize ls)
+		| otherwise = do
+			let offset = resumeOffset currsize k
+			let p = maybe basep
+				(offsetMeterUpdate basep . toBytesProcessed)
+				offset
+			v <- tryNonAsync $
+				retriever (encryptor k) p Nothing $ \content ->
+					bracket (maybe opennew openresume offset) (liftIO . hClose . fst) $ \(h, iv) -> do
+						retrieved iv (Just h) p content
+						let sz = toBytesProcessed $
+							fromMaybe 0 $ fromKey keyChunkSize k
+						getrest p h iv sz sz ks
+			case v of
+				Left e -> firstavail (Just (pickerr e)) currsize ls
+				Right r -> return r
+	  where
+		-- Prefer an earlier exception to a later one, because the
+		-- more probable location is tried first and less probable
+		-- ones later.
+		pickerr e = case pe of
+			Just pe' -> pe'
+			Nothing -> e
+
+	getrest _ _ iv _ _ [] = return (Right iv)
+	getrest p h iv sz bytesprocessed (k:ks) = do
+		let p' = offsetMeterUpdate p bytesprocessed
+		liftIO $ p' zeroBytesProcessed
+		retriever (encryptor k) p' Nothing $ 
+			retrieved iv (Just h) p'
+		getrest p h iv sz (addBytesProcessed bytesprocessed sz) ks
+
+	getunchunked = do
+		iv <- startVerifyKeyContentIncrementally vc basek
+		case enc of
+			Just _ -> do
+				retriever (encryptor basek) basep Nothing $
+					retrieved iv Nothing basep
+				return (Right iv)
+			-- Not chunked and not encrypted, so ask the
+			-- retriever to incrementally verify when it
+			-- retrieves to a file. It may not finish
+			-- passing the whole file content to the
+			-- incremental verifier though.
+			Nothing -> do
+				retriever (encryptor basek) basep iv $
+					retrieved iv Nothing basep
+				return $ case iv of
+					Nothing -> Right iv
+					Just iv' -> Left (IncompleteVerify iv')
+
+	opennew = do
+		iv <- startVerifyKeyContentIncrementally vc basek
+		h <- liftIO $ openBinaryFile dest WriteMode
+		return (h, iv)
+
+	-- Open the file and seek to the start point in order to resume.
+	openresume startpoint = do
+		-- ReadWriteMode allows seeking; AppendMode does not.
+		h <- liftIO $ openBinaryFile dest ReadWriteMode
+		liftIO $ hSeek h AbsoluteSeek startpoint
+		-- No incremental verification when resuming, since that
+		-- would need to read up to the startpoint.
+		let iv = Nothing
+		return (h, iv)
+
+	{- Progress meter updating is a bit tricky: If the Retriever
+	 - populates a file, it is responsible for updating progress
+	 - as the file is being retrieved. 
+	 -
+	 - However, if the Retriever generates a lazy ByteString,
+	 - it is not responsible for updating progress (often it cannot).
+	 - Instead, writeRetrievedContent is passed a meter to update
+	 - as it consumes the ByteString.
+	 -}
+	retrieved iv h p content =
+		writeRetrievedContent dest enc encc h p' content iv
+	  where
+		p'
+			| isByteContent content = Just p
+			| otherwise = Nothing
+	
+	finalize (Right Nothing) = return UnVerified
+	finalize (Right (Just iv)) =
+		liftIO (finalizeIncrementalVerifier iv) >>= \case
+			Just True -> return Verified
+			_ -> return UnVerified
+	finalize (Left v) = return v
+
+{- Writes retrieved file content to the provided Handle, decrypting it
+ - first if necessary.
+ - 
+ - If the remote did not store the content using chunks, no Handle
+ - will be provided, and instead the content will be written to the
+ - dest file.
+ -
+ - The IncrementalVerifier is updated as the file content is read.
+ -
+ - Note that when neither chunking nor encryption is used, and the remote
+ - provides FileContent, that file only needs to be renamed
+ - into place. (And it may even already be in the right place..)
+ -}
+writeRetrievedContent
+	:: LensEncParams encc
+	=> FilePath
+	-> Maybe (Cipher, EncKey)
+	-> encc
+	-> Maybe Handle
+	-> Maybe MeterUpdate
+	-> ContentSource
+	-> Maybe IncrementalVerifier
+	-> Annex ()
+writeRetrievedContent dest enc encc mh mp content miv = case (enc, mh, content) of
+	(Nothing, Nothing, FileContent f)
+		| f == dest -> noop
+		| otherwise -> liftIO $ moveFile (toRawFilePath f) (toRawFilePath dest)
+	(Just (cipher, _), _, ByteContent b) -> do
+		cmd <- gpgCmd <$> Annex.getGitConfig
+		decrypt cmd encc cipher (feedBytes b) $
+			readBytes write
+	(Just (cipher, _), _, FileContent f) -> do
+		cmd <- gpgCmd <$> Annex.getGitConfig
+		withBytes content $ \b ->
+			decrypt cmd encc cipher (feedBytes b) $
+				readBytes write
+		liftIO $ removeWhenExistsWith R.removeLink (toRawFilePath f)
+	(Nothing, _, FileContent f) -> do
+		withBytes content write
+		liftIO $ removeWhenExistsWith R.removeLink (toRawFilePath f)
+	(Nothing, _, ByteContent b) -> write b
+  where
+	write b = case mh of
+		Just h -> liftIO $ write' b h
+		Nothing -> liftIO $ bracket opendest hClose (write' b)
+	write' b h = case mp of
+		Just p -> 
+			let writer = case miv of
+				Just iv -> \s -> do
+					updateIncrementalVerifier iv s
+					S.hPut h s
+				Nothing -> S.hPut h
+			in meteredWrite p writer b
+		Nothing -> L.hPut h b
+	opendest = openBinaryFile dest WriteMode
+
+{- Can resume when the chunk's offset is at or before the end of
+ - the dest file. -}
+resumeOffset :: Maybe Integer -> Key -> Maybe Integer
+resumeOffset Nothing _ = Nothing
+resumeOffset currsize k
+	| offset <= currsize = offset
+	| otherwise = Nothing
+  where
+	offset = chunkKeyOffset k
+
+{- Drops chunks that are already present in a file, based on its size.
+ - Keeps any non-chunk keys.
+ -}
+setupResume :: [[Key]] -> Integer -> [[Key]]
+setupResume ls currsize = map dropunneeded ls
+  where
+	dropunneeded [] = []
+	dropunneeded l@(k:_) = case fromKey keyChunkSize k of
+		Just chunksize | chunksize > 0 ->
+			genericDrop (currsize `div` chunksize) l
+		_ -> l
+
+{- Checks if a key is present in a remote. This requires any one
+ - of the lists of options returned by chunkKeys to all check out
+ - as being present using the checker action.
+ -
+ - Throws an exception if the remote is not accessible.
+ -}
+checkPresentChunks
+	:: CheckPresent
+	-> UUID
+	-> ChunkConfig
+	-> EncKey
+	-> Key
+	-> Annex Bool
+checkPresentChunks checker u chunkconfig encryptor basek
+	| noChunks chunkconfig = do
+		-- Optimisation: Try the unchunked key first, to avoid
+		-- looking in the git-annex branch for chunk counts
+		-- that are likely not there.
+		v <- check basek
+		let getchunkkeys = chunkKeysOnly u chunkconfig basek
+		case v of
+			Right True -> return True
+			Left e -> checklists (Just e) =<< getchunkkeys
+			_ -> checklists Nothing =<< getchunkkeys
+	| otherwise = checklists Nothing =<< chunkKeys u chunkconfig basek
+  where
+	checklists Nothing [] = return False
+	checklists (Just deferrederror) [] = throwM deferrederror
+	checklists d (ck:cks)
+		| not (null l) = do
+			v <- checkchunks l
+			case v of
+				Left e -> checklists (Just e) cks
+				Right True -> do
+					ensureChunksAreLogged u basek ck
+					return True
+				Right False -> checklists Nothing cks
+		| otherwise = checklists d cks
+	  where
+		l = chunkKeyList ck
+	
+	checkchunks :: [Key] -> Annex (Either SomeException Bool)
+	checkchunks [] = return (Right True)
+	checkchunks (k:ks) = do
+		v <- check k
+		case v of
+			Right True -> checkchunks ks
+			Right False -> return $ Right False
+			Left e -> return $ Left e
+
+	check = tryNonAsync . checker . encryptor
+
+data ChunkKeys
+	= ChunkKeys [Key]
+	| SpeculativeChunkKeys (ChunkMethod, ChunkCount) [Key]
+
+chunkKeyList :: ChunkKeys -> [Key]
+chunkKeyList (ChunkKeys l) = l
+chunkKeyList (SpeculativeChunkKeys _ l) = l
+
+{- A key can be stored in a remote unchunked, or as a list of chunked keys.
+ - This can be the case whether or not the remote is currently configured
+ - to use chunking.
+ -
+ - It's even possible for a remote to have the same key stored multiple
+ - times with different chunk sizes!
+ -
+ - This finds all possible lists of keys that might be on the remote that
+ - can be combined to get back the requested key, in order from most to
+ - least likely to exist.
+ -
+ - Speculatively tries chunks using the ChunkConfig last of all
+ - (when that's not the same as the recorded chunks). This can help
+ - recover from data loss, where the chunk log didn't make it out,
+ - though only as long as the ChunkConfig is unchanged.
+ -}
+chunkKeys :: UUID -> ChunkConfig -> Key -> Annex [ChunkKeys]
+chunkKeys = chunkKeys' False
+
+{- Same as chunkKeys, but excluding the unchunked key. -}
+chunkKeysOnly :: UUID -> ChunkConfig -> Key -> Annex [ChunkKeys]
+chunkKeysOnly = chunkKeys' True
+
+chunkKeys' :: Bool -> UUID -> ChunkConfig -> Key -> Annex [ChunkKeys]
+chunkKeys' onlychunks u chunkconfig k = do
+	recorded <- getCurrentChunks u k
+	let recordedl = map (ChunkKeys . toChunkList k) recorded
+	return $ addspeculative recorded $ if onlychunks
+		then recordedl
+		else if noChunks chunkconfig
+			then ChunkKeys [k] : recordedl
+			else recordedl ++ [ChunkKeys [k]]
+  where
+	addspeculative recorded l = case chunkconfig of
+		NoChunks -> l
+		UnpaddedChunks chunksz -> case fromKey keySize k of
+			Nothing -> l
+			Just keysz -> 
+				let (d, m) = keysz `divMod` fromIntegral chunksz
+				    chunkcount = max 1 (d + if m == 0 then 0 else 1)
+ 				    v = (FixedSizeChunks chunksz, chunkcount)
+				in if v `elem` recorded
+					then l
+					else l ++ [SpeculativeChunkKeys v (toChunkList k v)]
+		LegacyChunks _ -> l
+
+toChunkList :: Key -> (ChunkMethod, ChunkCount) -> [Key]
+toChunkList k (FixedSizeChunks chunksize, chunkcount) =
+	takeChunkKeyStream chunkcount $ chunkKeyStream k chunksize
+toChunkList _ (UnknownChunks _, _) = []
+
+{- When chunkKeys provided a speculative chunk list, and that has been
+ - verified to be present, use this to log it in the chunk log. This way,
+ - a later change to the chunk size of the remote won't prevent accessing
+ - the chunks. -}
+ensureChunksAreLogged :: UUID -> Key -> ChunkKeys -> Annex ()
+ensureChunksAreLogged u k (SpeculativeChunkKeys (chunkmethod, chunkcount) _) = 
+	chunksStored u k chunkmethod chunkcount
+ensureChunksAreLogged _ _ (ChunkKeys _) = return ()
+
+withBytes :: ContentSource -> (L.ByteString -> Annex a) -> Annex a
+withBytes (ByteContent b) a = a b
+withBytes (FileContent f) a = a =<< liftIO (L.readFile f)
diff --git a/Remote/Helper/Chunked/Legacy.hs b/Remote/Helper/Chunked/Legacy.hs
new file mode 100644
index 0000000000..faae6ddc90
--- /dev/null
+++ b/Remote/Helper/Chunked/Legacy.hs
@@ -0,0 +1,121 @@
+{- legacy git-annex chunked remotes
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Remote.Helper.Chunked.Legacy where
+
+import Annex.Common
+import Remote.Helper.Chunked
+import Utility.Metered
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+
+{- This is an extension that's added to the usual file (or whatever)
+ - where the remote stores a key. -}
+type ChunkExt = String
+
+{- A record of the number of chunks used.
+ -
+ - While this can be guessed at based on the size of the key, encryption
+ - makes that larger. Also, using this helps deal with changes to chunksize
+ - over the life of a remote.
+ -}
+chunkCount :: ChunkExt
+chunkCount = ".chunkcount"
+
+{- An infinite stream of extensions to use for chunks. -}
+chunkStream :: [ChunkExt]
+chunkStream = map (\n -> ".chunk" ++ show n) [1 :: Integer ..]
+
+{- Parses the String from the chunkCount file, and returns the files that
+ - are used to store the chunks. -}
+listChunks :: FilePath -> String -> [FilePath]
+listChunks basedest chunkcount = take count $ map (basedest ++) chunkStream
+  where
+	count = fromMaybe 0 $ readish chunkcount
+
+{- For use when there is no chunkCount file; uses the action to find
+ - chunks, and returns them, or Nothing if none found. Relies on
+ - storeChunks's finalizer atomically moving the chunks into place once all
+ - are written.
+ -
+ - This is only needed to work around a bug that caused the chunkCount file
+ - not to be written.
+ -}
+probeChunks :: FilePath -> (FilePath -> IO Bool) -> IO [FilePath]
+probeChunks basedest check = go [] $ map (basedest ++) chunkStream
+  where
+	go l [] = return (reverse l)
+	go l (c:cs) = ifM (check c)
+		( go (c:l) cs
+		, go l []
+		)
+
+{- Given the base destination to use to store a value,
+ - generates a stream of temporary destinations,
+ - and passes it to an action, which should chunk and store the data,
+ - and return the destinations it stored to, or [] on error. Then
+ - calls the recorder to write the chunk count. Finally, the
+ - finalizer is called to rename the tmp into the dest 
+ - (and do any other cleanup).
+ -}
+storeChunks :: Key -> FilePath -> FilePath -> ([FilePath] -> IO [FilePath]) -> (FilePath -> String -> IO ()) -> (FilePath -> FilePath -> IO ()) -> IO ()
+storeChunks key tmp dest storer recorder finalizer = do
+	stored <- storer tmpdests
+	let chunkcount = basef ++ chunkCount
+	recorder chunkcount (show $ length stored)
+	finalizer tmp dest
+	when (null stored) $
+		giveup "no chunks were stored"
+  where
+	basef = tmp ++ fromRawFilePath (keyFile key)
+	tmpdests = map (basef ++ ) chunkStream
+
+{- Given a list of destinations to use, chunks the data according to the
+ - ChunkSize, and runs the storer action to store each chunk. Returns
+ - the destinations where data was stored, or [] on error.
+ -
+ - This buffers each chunk in memory.
+ - More optimal versions of this can be written, that rely
+ - on L.toChunks to split the lazy bytestring into chunks (typically
+ - smaller than the ChunkSize), and eg, write those chunks to a Handle.
+ - But this is the best that can be done with the storer interface that
+ - writes a whole L.ByteString at a time.
+ -}
+storeChunked :: (Annex () -> IO ()) -> ChunkSize -> [FilePath] -> (FilePath -> L.ByteString -> IO ()) -> L.ByteString -> IO [FilePath]
+storeChunked annexrunner chunksize dests storer content = 
+	either onerr return =<< tryNonAsync (go (Just chunksize) dests)
+  where
+	go _ [] = return [] -- no dests!?
+	go Nothing (d:_) = do
+		storer d content
+		return [d]
+	go (Just sz) _
+		-- always write a chunk, even if the data is 0 bytes
+		| L.null content = go Nothing dests
+		| otherwise = storechunks sz [] dests content
+		
+	onerr e = do
+		annexrunner $ warning (UnquotedString (show e))
+		return []
+	
+	storechunks _ _ [] _ = return [] -- ran out of dests
+	storechunks sz useddests (d:ds) b
+		| L.null b = return $ reverse useddests
+		| otherwise = do
+			let (chunk, b') = L.splitAt sz b
+			storer d chunk
+			storechunks sz (d:useddests) ds b'
+
+{- Writes a series of chunks to a file. The feeder is called to get
+ - each chunk.
+ -}
+meteredWriteFileChunks :: MeterUpdate -> FilePath -> [v] -> (v -> IO L.ByteString) -> IO ()
+meteredWriteFileChunks meterupdate dest chunks feeder =
+	withBinaryFile dest WriteMode $ \h ->
+		forM_ chunks $
+			meteredWrite meterupdate (S.hPut h) <=< feeder
diff --git a/Remote/Helper/Encryptable.hs b/Remote/Helper/Encryptable.hs
new file mode 100644
index 0000000000..884d53d7bf
--- /dev/null
+++ b/Remote/Helper/Encryptable.hs
@@ -0,0 +1,322 @@
+{- common functions for encryptable remotes
+ -
+ - Copyright 2011-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE FlexibleContexts, ScopedTypeVariables, PackageImports #-}
+
+module Remote.Helper.Encryptable (
+	EncryptionIsSetup,
+	encryptionSetup,
+	noEncryptionUsed,
+	encryptionAlreadySetup,
+	encryptionConfigParsers,
+	parseEncryptionConfig,
+	remoteCipher,
+	remoteCipher',
+	embedCreds,
+	cipherKey,
+	extractCipher,
+	isEncrypted,
+	encryptionIsEnabled,
+	describeEncryption,
+	encryptionField,
+	highRandomQualityField
+) where
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import Control.Concurrent.STM
+
+import Annex.Common
+import Types.Remote
+import Crypto
+import Types.Crypto
+import Types.ProposedAccepted
+import qualified Annex
+import Annex.SpecialRemote.Config
+import Utility.Base64
+
+-- Used to ensure that encryption has been set up before trying to
+-- eg, store creds in the remote config that would need to use the
+-- encryption setup.
+data EncryptionIsSetup = EncryptionIsSetup | NoEncryption
+
+-- Remotes that don't use encryption can use this instead of
+-- encryptionSetup.
+noEncryptionUsed :: EncryptionIsSetup
+noEncryptionUsed = NoEncryption
+
+-- Using this avoids the type-safe check, so you'd better be sure
+-- of what you're doing.
+encryptionAlreadySetup :: EncryptionIsSetup
+encryptionAlreadySetup = EncryptionIsSetup
+
+encryptionConfigParsers :: [RemoteConfigFieldParser]
+encryptionConfigParsers =
+	[ encryptionFieldParser
+	, optionalStringParser cipherField HiddenField
+	, optionalStringParser cipherkeysField HiddenField
+	, optionalStringParser pubkeysField HiddenField
+	, yesNoParser embedCredsField Nothing
+		(FieldDesc "embed credentials into git repository")
+	, macFieldParser
+	, optionalStringParser (Accepted "keyid")
+		(FieldDesc "gpg key id")
+	, optionalStringParser (Accepted "keyid+")
+		(FieldDesc "add additional gpg key")
+	, optionalStringParser (Accepted "keyid-")
+		(FieldDesc "remove gpg key")
+	, highRandomQualityFieldParser
+	]
+
+encryptionConfigs :: S.Set RemoteConfigField
+encryptionConfigs = S.fromList (map parserForField encryptionConfigParsers)
+
+-- Parse only encryption fields, ignoring all others.
+parseEncryptionConfig :: RemoteConfig -> Either String ParsedRemoteConfig
+parseEncryptionConfig c = parseRemoteConfig
+	(M.restrictKeys c encryptionConfigs)
+	(RemoteConfigParser encryptionConfigParsers Nothing)
+
+encryptionFieldParser :: RemoteConfigFieldParser
+encryptionFieldParser = RemoteConfigFieldParser
+	{ parserForField = encryptionField
+	, valueParser = \v c -> Just . RemoteConfigValue
+		<$> parseEncryptionMethod (fmap fromProposedAccepted v) c
+	, fieldDesc = FieldDesc "how to encrypt data stored in the special remote"
+	, valueDesc = Just $ ValueDesc $
+		intercalate " or " (M.keys encryptionMethods)
+	}
+
+encryptionMethods :: M.Map String EncryptionMethod
+encryptionMethods = M.fromList
+	[ ("none", NoneEncryption)
+	, ("shared", SharedEncryption)
+	, ("hybrid", HybridEncryption)
+	, ("pubkey", PubKeyEncryption)
+	, ("sharedpubkey", SharedPubKeyEncryption)
+	]
+
+parseEncryptionMethod :: Maybe String -> RemoteConfig -> Either String EncryptionMethod
+parseEncryptionMethod (Just s) _ = case M.lookup s encryptionMethods of
+	Just em -> Right em
+	Nothing -> Left badEncryptionMethod
+-- Hybrid encryption is the default when a keyid is specified without
+-- an encryption field, or when there's a cipher already but no encryption
+-- field.
+parseEncryptionMethod Nothing c
+	| M.member (Accepted "keyid") c || M.member cipherField c = Right HybridEncryption
+	| otherwise = Left badEncryptionMethod
+
+badEncryptionMethod :: String
+badEncryptionMethod = "Specify " ++ intercalate " or "
+	(map ((fromProposedAccepted encryptionField ++ "=") ++)
+		(M.keys encryptionMethods))
+	++ "."
+
+highRandomQualityField :: RemoteConfigField
+highRandomQualityField = Accepted "highRandomQuality"
+
+highRandomQualityFieldParser :: RemoteConfigFieldParser
+highRandomQualityFieldParser = RemoteConfigFieldParser
+	{ parserForField = highRandomQualityField
+	, valueParser = \v _c -> Just . RemoteConfigValue
+		<$> parseHighRandomQuality (fmap fromProposedAccepted v)
+	, fieldDesc = HiddenField
+	, valueDesc = Nothing
+	}
+ 
+parseHighRandomQuality :: Maybe String -> Either String Bool
+parseHighRandomQuality Nothing = Right True
+parseHighRandomQuality (Just "false") = Right False
+parseHighRandomQuality (Just "true") = Right True
+parseHighRandomQuality _ = Left "expected highRandomQuality=true/false"
+	
+macFieldParser :: RemoteConfigFieldParser
+macFieldParser = RemoteConfigFieldParser
+	{ parserForField = macField
+	, valueParser = \v _c -> Just . RemoteConfigValue <$> parseMac v
+	, fieldDesc = FieldDesc "how to encrypt filenames used on the remote"
+	, valueDesc = Just $ ValueDesc $
+		intercalate " or " (M.keys macMap)
+	}
+
+parseMac :: Maybe (ProposedAccepted String) -> Either String Mac
+parseMac Nothing = Right defaultMac
+parseMac (Just (Accepted s)) = Right $ fromMaybe defaultMac (readMac s)
+parseMac (Just (Proposed s)) = case readMac s of
+	Just mac -> Right mac
+	Nothing -> Left "bad mac value"
+
+{- Encryption setup for a remote. The user must specify whether to use
+ - an encryption key, or not encrypt. An encrypted cipher is created, or is
+ - updated to be accessible to an additional encryption key. Or the user
+ - could opt to use a shared cipher, which is stored unencrypted. -}
+encryptionSetup :: RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, EncryptionIsSetup)
+encryptionSetup c gc = do
+	pc <- either giveup return $ parseEncryptionConfig c
+	gpgcmd <- gpgCmd <$> Annex.getGitConfig
+	maybe (genCipher pc gpgcmd) (updateCipher pc gpgcmd) (extractCipher pc)
+  where
+	-- The type of encryption
+	encryption = parseEncryptionMethod (fromProposedAccepted <$> M.lookup encryptionField c) c
+	-- Generate a new cipher, depending on the chosen encryption scheme
+	genCipher pc gpgcmd = case encryption of
+		Right NoneEncryption -> return (c, NoEncryption)
+		Right SharedEncryption -> encsetup $ genSharedCipher gpgcmd
+		Right HybridEncryption -> encsetup $ genEncryptedCipher gpgcmd (pc, gc) key Hybrid
+		Right PubKeyEncryption -> encsetup $ genEncryptedCipher gpgcmd (pc, gc) key PubKey
+		Right SharedPubKeyEncryption -> encsetup $ genSharedPubKeyCipher gpgcmd key
+		Left err -> giveup err
+	key = maybe (giveup "Specify keyid=...") fromProposedAccepted $
+		M.lookup (Accepted "keyid") c
+	newkeys = maybe [] (\k -> [(True,fromProposedAccepted k)]) (M.lookup (Accepted "keyid+") c) ++
+		maybe [] (\k -> [(False,fromProposedAccepted k)]) (M.lookup (Accepted "keyid-") c)
+	cannotchange = giveup "Cannot set encryption type of existing remotes."
+	-- Update an existing cipher if possible.
+	updateCipher pc gpgcmd v = case v of
+		SharedCipher _ | encryption == Right SharedEncryption ->
+			return (c', EncryptionIsSetup)
+		EncryptedCipher _ variant _ | sameasencryption variant ->
+			use "encryption update" $ updateCipherKeyIds gpgcmd (pc, gc) newkeys v
+		SharedPubKeyCipher _ _ ->
+			use "encryption update" $ updateCipherKeyIds gpgcmd (pc, gc) newkeys v
+		_ -> cannotchange
+	sameasencryption variant = case encryption of
+		Right HybridEncryption -> variant == Hybrid
+		Right PubKeyEncryption -> variant == PubKey
+		Right _ -> False
+		Left _ -> True
+	encsetup a = use "encryption setup" . a =<< highRandomQuality
+	use m a = do
+		showNote (UnquotedString m)
+		cipher <- liftIO a
+		showNote (UnquotedString (describeCipher cipher))
+		return (storeCipher cipher c', EncryptionIsSetup)
+	highRandomQuality = ifM (Annex.getRead Annex.fast)
+		( return False
+		, case parseHighRandomQuality (fromProposedAccepted <$> M.lookup highRandomQualityField c) of
+			Left err -> giveup err
+			Right v -> return v
+		)
+	c' = foldr M.delete c
+		-- Remove configs that are only used in here to generate
+		-- the encryption keys, and should not be stored in
+		-- remote.log.
+		-- Older versions used to remove 'encryption' as well, since
+		-- it was redundant; we now need to keep it for
+		-- public-key encryption, hence we leave it on newer
+		-- remotes (while being backward-compatible).
+		(map Accepted ["keyid", "keyid+", "keyid-", "highRandomQuality"])
+
+remoteCipher :: ParsedRemoteConfig -> RemoteGitConfig -> Annex (Maybe Cipher)
+remoteCipher c gc = fmap fst <$> remoteCipher' c gc
+
+{- Gets encryption Cipher. The decrypted Ciphers are cached in the Annex
+ - state. -}
+remoteCipher' :: ParsedRemoteConfig -> RemoteGitConfig -> Annex (Maybe (Cipher, StorableCipher))
+remoteCipher' c gc = case extractCipher c of
+	Nothing -> return Nothing
+	Just encipher -> do
+		cachev <- Annex.getRead Annex.ciphers
+		cachedciper <- liftIO $ atomically $ 
+			M.lookup encipher <$> readTMVar cachev
+		case cachedciper of
+			Just cipher -> return $ Just (cipher, encipher)
+			-- Not cached; decrypt it, making sure
+			-- to only decrypt one at a time. Avoids
+			-- prompting for decrypting the same thing twice
+			-- when this is run concurrently.
+			Nothing -> bracketOnError
+				(liftIO $ atomically $ takeTMVar cachev)
+				(liftIO . atomically . putTMVar cachev)
+				(go cachev encipher)
+  where
+	go cachev encipher cache = do
+		gpgcmd <- gpgCmd <$> Annex.getGitConfig
+		cipher <- liftIO $ decryptCipher gpgcmd (c, gc) encipher
+		liftIO $ atomically $ putTMVar cachev $
+			M.insert encipher cipher cache
+		return $ Just (cipher, encipher)
+
+{- Checks if the remote's config allows storing creds in the remote's config.
+ - 
+ - embedcreds=yes allows this, and embedcreds=no prevents it.
+ -
+ - If not set, the default is to only store creds when it's surely safe:
+ - When gpg encryption is used and the creds are encrypted using it.
+ - Not when a shared cipher is used.
+ -}
+embedCreds :: ParsedRemoteConfig -> Bool
+embedCreds c = case getRemoteConfigValue embedCredsField c of
+	Just v -> v
+	Nothing -> case (getRemoteConfigValue cipherkeysField c, getRemoteConfigValue cipherField c) of
+		(Just (_ :: String), Just (_ :: String)) -> True
+		_ -> False
+
+{- Gets encryption Cipher, and key encryptor. -}
+cipherKey :: ParsedRemoteConfig -> RemoteGitConfig -> Annex (Maybe (Cipher, EncKey))
+cipherKey c gc = fmap make <$> remoteCipher c gc
+  where
+	make ciphertext = (ciphertext, encryptKey mac ciphertext)
+	mac = fromMaybe defaultMac $ getRemoteConfigValue macField c
+
+{- Stores an StorableCipher in a remote's configuration. -}
+storeCipher :: StorableCipher -> RemoteConfig -> RemoteConfig
+storeCipher cip = case cip of
+	(SharedCipher t) -> addcipher t
+	(EncryptedCipher t _ ks) -> addcipher t . storekeys ks cipherkeysField
+	(SharedPubKeyCipher t ks) -> addcipher t . storekeys ks pubkeysField
+  where
+	addcipher t = M.insert cipherField (Accepted (decodeBS (toB64 t)))
+	storekeys (KeyIds l) n = M.insert n (Accepted (intercalate "," l))
+
+{- Extracts an StorableCipher from a remote's configuration. -}
+extractCipher :: ParsedRemoteConfig -> Maybe StorableCipher
+extractCipher c = case (getRemoteConfigValue cipherField c,
+			(getRemoteConfigValue cipherkeysField c <|> getRemoteConfigValue pubkeysField c),
+			getRemoteConfigValue encryptionField c) of
+	(Just t, Just ks, Just HybridEncryption) ->
+		Just $ EncryptedCipher (fromB64 (encodeBS t)) Hybrid (readkeys ks)
+	(Just t, Just ks, Just PubKeyEncryption) ->
+		Just $ EncryptedCipher (fromB64 (encodeBS t)) PubKey (readkeys ks)
+	(Just t, Just ks, Just SharedPubKeyEncryption) ->
+		Just $ SharedPubKeyCipher (fromB64 (encodeBS t)) (readkeys ks)
+	(Just t, Nothing, Just SharedEncryption) ->
+		Just $ SharedCipher (fromB64 (encodeBS t))
+	_ -> Nothing
+  where
+	readkeys = KeyIds . splitc ','
+
+isEncrypted :: ParsedRemoteConfig -> Bool
+isEncrypted = isJust . extractCipher
+
+-- Check if encryption is enabled. This can be done before encryption
+-- is fully set up yet, so the cipher might not be present yet.
+encryptionIsEnabled :: ParsedRemoteConfig -> Bool
+encryptionIsEnabled c = case getRemoteConfigValue encryptionField c of
+	Nothing -> False
+	Just NoneEncryption -> False
+	Just _ -> True
+
+describeEncryption :: ParsedRemoteConfig -> String
+describeEncryption c = case extractCipher c of
+	Nothing -> "none"
+	Just cip -> nameCipher cip ++ " (" ++ describeCipher cip ++ ")"
+
+nameCipher :: StorableCipher -> String
+nameCipher (SharedCipher _) = "shared"
+nameCipher (EncryptedCipher _ PubKey _) = "pubkey"
+nameCipher (EncryptedCipher _ Hybrid _) = "hybrid"
+nameCipher (SharedPubKeyCipher _ _) = "sharedpubkey"
+
+describeCipher :: StorableCipher -> String
+describeCipher c = case c of
+	(SharedCipher _) -> "encryption key stored in git repository"
+	(EncryptedCipher _ _ ks) -> showkeys ks
+	(SharedPubKeyCipher _ ks) -> showkeys ks
+  where
+	showkeys (KeyIds { keyIds = ks }) = "to gpg keys: " ++ unwords ks
diff --git a/Remote/Helper/ExportImport.hs b/Remote/Helper/ExportImport.hs
new file mode 100644
index 0000000000..6d95ad1cf2
--- /dev/null
+++ b/Remote/Helper/ExportImport.hs
@@ -0,0 +1,389 @@
+{- Helper to make remotes support export and import (or not).
+ -
+ - Copyright 2017-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE FlexibleInstances, FlexibleContexts #-}
+
+module Remote.Helper.ExportImport where
+
+import Annex.Common
+import Types.Remote
+import Types.Key
+import Types.ProposedAccepted
+import Annex.Verify
+import Remote.Helper.Encryptable (encryptionIsEnabled)
+import qualified Database.Export as Export
+import qualified Database.ContentIdentifier as ContentIdentifier
+import Annex.Export
+import Annex.LockFile
+import Annex.SpecialRemote.Config
+import Git.Types (fromRef)
+import Logs.Export
+import Logs.ContentIdentifier (recordContentIdentifier)
+
+import Control.Concurrent.STM
+
+-- | Use for remotes that do not support exports.
+class HasExportUnsupported a where
+	exportUnsupported :: a
+
+instance HasExportUnsupported (ParsedRemoteConfig -> RemoteGitConfig -> Annex Bool) where
+	exportUnsupported = \_ _ -> return False
+
+instance HasExportUnsupported (ExportActions Annex) where
+	exportUnsupported = ExportActions
+		{ storeExport = nope
+		, retrieveExport = nope
+		, checkPresentExport = \_ _ -> return False
+		, removeExport = nope
+		, versionedExport = False
+		, removeExportDirectory = nope
+		, renameExport = Nothing
+		}
+	 where
+	 	nope = giveup "export not supported"
+
+-- | Use for remotes that do not support imports.
+class HasImportUnsupported a where
+	importUnsupported :: a
+
+instance HasImportUnsupported (ParsedRemoteConfig -> RemoteGitConfig -> Annex Bool) where
+	importUnsupported = \_ _ -> return False
+
+instance HasImportUnsupported (ImportActions Annex) where
+	importUnsupported = ImportActions
+		{ listImportableContents = nope
+		, importKey = Nothing
+		, retrieveExportWithContentIdentifier = nope
+		, storeExportWithContentIdentifier = nope
+		, removeExportWithContentIdentifier = nope
+		, removeExportDirectoryWhenEmpty = nope
+		, checkPresentExportWithContentIdentifier = \_ _ _ -> return False
+		}
+	  where
+		nope = giveup "import not supported"
+
+exportIsSupported :: ParsedRemoteConfig -> RemoteGitConfig -> Annex Bool
+exportIsSupported = \_ _ -> return True
+
+importIsSupported :: ParsedRemoteConfig -> RemoteGitConfig -> Annex Bool
+importIsSupported = \_ _ -> return True
+
+-- | Prevent or allow exporttree=yes and importtree=yes when
+-- setting up a new remote, depending on the remote's capabilities.
+adjustExportImportRemoteType :: RemoteType -> RemoteType
+adjustExportImportRemoteType rt = rt { setup = setup' }
+  where
+	setup' st mu cp c gc = do
+		pc <- either giveup return . parseRemoteConfig c
+			=<< configParser rt c
+		let checkconfig supported configured configfield cont =
+			ifM (supported rt pc gc <&&> pure (not (thirdPartyPopulated rt)))
+				( case st of
+					Init
+						| configured pc && encryptionIsEnabled pc ->
+							giveup $ "cannot enable both encryption and " ++ fromProposedAccepted configfield
+						| otherwise -> cont
+					Enable oldc -> enable oldc pc configured configfield cont
+					AutoEnable oldc -> enable oldc pc configured configfield cont
+				, if configured pc
+					then giveup $ fromProposedAccepted configfield ++ " is not supported by this special remote"
+					else cont
+				)
+		checkconfig exportSupported exportTree exportTreeField $
+			checkconfig importSupported importTree importTreeField $
+				setup rt st mu cp c gc
+	
+	enable oldc pc configured configfield cont = do
+		oldpc <- parsedRemoteConfig rt oldc
+		if configured pc /= configured oldpc
+			then giveup $ "cannot change " ++ fromProposedAccepted configfield ++ " of existing special remote"
+			else cont
+
+-- | Adjust a remote to support exporttree=yes and/or importree=yes.
+adjustExportImport :: Remote -> RemoteStateHandle -> Annex Remote
+adjustExportImport r rs = do
+	isexport <- pure (exportTree (config r))
+		<&&> isExportSupported r
+	-- When thirdPartyPopulated is True, the remote
+	-- does not need to be configured with importTree to support
+	-- imports.
+	isimport <- pure (importTree (config r) || thirdPartyPopulated (remotetype r))
+		<&&> isImportSupported r
+	let r' = r
+		{ remotetype = (remotetype r)
+			{ exportSupported = if isexport
+				then exportSupported (remotetype r)
+				else exportUnsupported
+			, importSupported = if isimport
+				then importSupported (remotetype r)
+				else importUnsupported
+			}
+		}
+	if not isexport && not isimport
+		then return r'
+		else adjustExportImport' isexport isimport r' rs
+
+adjustExportImport' :: Bool -> Bool -> Remote -> RemoteStateHandle -> Annex Remote
+adjustExportImport' isexport isimport r rs = do
+	dbv <- prepdbv
+	ciddbv <- prepciddb
+	let versioned = versionedExport (exportActions r)
+	return $ r
+		{ exportActions = if isexport
+			then if isimport
+				then exportActionsForImport dbv ciddbv (exportActions r)
+				else exportActions r
+			else exportUnsupported
+		, importActions = if isimport
+			then importActions r
+			else importUnsupported
+		, storeKey = \k af p ->
+			-- Storing a key on an export could be implemented,
+			-- but it would perform unnecessary work
+			-- when another repository has already stored the
+			-- key, and the local repository does not know
+			-- about it. To avoid unnecessary costs, don't do it.
+			if thirdpartypopulated
+				then giveup "remote is not populated by git-annex"
+				else if isexport
+					then giveup "remote is configured with exporttree=yes; use `git-annex export` to store content on it"
+					else if isimport
+						then giveup "remote is configured with importtree=yes and without exporttree=yes; cannot modify content stored on it"
+						else storeKey r k af p
+		, removeKey = \k -> 
+			-- Removing a key from an export would need to
+			-- change the tree in the export log to not include
+			-- the file. Otherwise, conflicts when removing
+			-- files would not be dealt with correctly.
+			-- There does not seem to be a good use case for
+			-- removing a key from an export in any case.
+			if thirdpartypopulated
+				then giveup "dropping content from this remote is not supported"
+				else if isexport
+					then giveup "dropping content from an export is not supported; use `git annex export` to export a tree that lacks the files you want to remove"
+					else if isimport
+						then giveup "dropping content from this remote is not supported because it is configured with importtree=yes"
+						else removeKey r k
+		, lockContent = if versioned
+			then lockContent r
+			else Nothing
+		, retrieveKeyFile = \k af dest p vc ->
+			if isimport
+				then supportversionedretrieve k af dest p vc $
+					retrieveKeyFileFromImport dbv ciddbv k af dest p
+				else if isexport
+					then supportversionedretrieve k af dest p vc $
+						retrieveKeyFileFromExport dbv k af dest p
+					else retrieveKeyFile r k af dest p vc
+		, retrieveKeyFileCheap = if versioned
+			then retrieveKeyFileCheap r
+			else Nothing
+		, checkPresent = \k -> if versioned
+			then checkPresent r k
+			else if isimport
+				then anyM (checkPresentImport ciddbv k)
+					=<< getanyexportlocs dbv k
+				else if isexport
+					-- Check if any of the files a key
+					-- was exported to are present. This 
+					-- doesn't guarantee the export
+					-- contains the right content,
+					-- if the remote is an export,
+					-- or if something else can write
+					-- to it. Remotes that have such 
+					-- problems are made untrusted,
+					-- so it's not worried about here.
+					then anyM (checkPresentExport (exportActions r) k)
+						=<< getanyexportlocs dbv k
+					else checkPresent r k
+		-- checkPresent from an export is more expensive
+		-- than otherwise, so not cheap. Also, this
+		-- avoids things that look at checkPresentCheap and
+		-- silently skip non-present files from behaving
+		-- in confusing ways when there's an export
+		-- conflict (or an import conflict).
+		, checkPresentCheap = False
+		-- Export/import remotes can lose content stored on them in
+		-- many ways. This is not a problem with versioned
+		-- ones though, since they still allow accessing by Key.
+		-- And for thirdPartyPopulated, it depends on how the
+		-- content gets actually stored in the remote, so
+		-- is not overridden here.
+		, untrustworthy =
+			if versioned || thirdPartyPopulated (remotetype r)
+				then untrustworthy r
+				else True
+		-- git-annex testremote cannot be used to test
+		-- import/export since it stores keys.
+		, mkUnavailable = return Nothing
+		, getInfo = do
+			is <- getInfo r
+			is' <- if isexport && not thirdpartypopulated
+				then do
+					ts <- map fromRef . exportedTreeishes
+						<$> getExport (uuid r)
+					return (is++[("exporttree", "yes"), ("exportedtree", unwords ts)])
+				else return is
+			return $ if isimport && not thirdpartypopulated
+				then (is'++[("importtree", "yes")])
+				else is'
+		}
+  where
+	thirdpartypopulated = thirdPartyPopulated (remotetype r)
+
+	-- exportActions adjusted to use the equivalent import actions,
+	-- which take ContentIdentifiers into account.
+	exportActionsForImport dbv ciddbv ea = ea
+  		{ storeExport = \f k loc p -> do
+			db <- getciddb ciddbv
+			exportdb <- getexportdb dbv
+			oldks <- liftIO $ Export.getExportTreeKey exportdb loc
+			oldcids <- liftIO $ concat
+				<$> mapM (ContentIdentifier.getContentIdentifiers db rs) oldks
+			newcid <- storeExportWithContentIdentifier (importActions r) f k loc oldcids p
+			cidlck <- calcRepo' gitAnnexContentIdentifierLock
+			withExclusiveLock cidlck $ do
+				liftIO $ ContentIdentifier.recordContentIdentifier db rs newcid k
+				liftIO $ ContentIdentifier.flushDbQueue db
+			recordContentIdentifier rs newcid k
+		, removeExport = \k loc ->
+			removeExportWithContentIdentifier (importActions r) k loc
+				=<< getkeycids ciddbv k
+		, removeExportDirectory = removeExportDirectoryWhenEmpty (importActions r)
+		-- renameExport is optional, and the remote's
+		-- implementation may lose modifications to the file
+		-- (by eg copying and then deleting) so don't use it
+		, renameExport = Nothing
+		, checkPresentExport = checkPresentImport ciddbv
+		}
+	
+	prepciddb = do
+		lcklckv <- liftIO newEmptyTMVarIO
+		dbtv <- liftIO newEmptyTMVarIO
+		return (dbtv, lcklckv)
+	
+	prepdbv = do
+		lcklckv <- liftIO newEmptyTMVarIO
+		dbv <- liftIO newEmptyTMVarIO
+		exportinconflict <- liftIO $ newTVarIO False
+		return (dbv, lcklckv, exportinconflict)
+
+	-- Only open the database once it's needed.
+	getciddb (dbtv, lcklckv) =
+		liftIO (atomically (tryReadTMVar dbtv)) >>= \case
+			Just db -> return db
+			-- let only one thread take the lock
+			Nothing -> ifM (liftIO $ atomically $ tryPutTMVar lcklckv ())
+				( do
+					db <- ContentIdentifier.openDb
+					db' <- ContentIdentifier.needsUpdateFromLog db >>= \case
+						Just v -> do
+							cidlck <- calcRepo' gitAnnexContentIdentifierLock 
+							withExclusiveLock cidlck $
+								ContentIdentifier.updateFromLog db v
+						Nothing -> pure db
+					liftIO $ atomically $ putTMVar dbtv db'
+					return db'
+				-- loser waits for winner to open the db and
+				-- can then also use its handle
+				, liftIO $ atomically (readTMVar dbtv)
+				)
+	
+	-- Only open the database once it's needed.
+	--
+	-- After opening the database, check if the export log is
+	-- different than the database, and update the database, to notice
+	-- when an export has been updated from another repository.
+	getexportdb (dbv, lcklckv, exportinconflict) = 
+		liftIO (atomically (tryReadTMVar dbv)) >>= \case
+			Just db -> return db
+			-- let only one thread take the lock
+			Nothing -> ifM (liftIO $ atomically $ tryPutTMVar lcklckv ())
+				( do
+					db <- Export.openDb (uuid r)
+					updateexportdb db exportinconflict
+					liftIO $ atomically $ putTMVar dbv db
+					return db
+				-- loser waits for winner to open the db and
+				-- can then also use its handle
+				, liftIO $ atomically (readTMVar dbv)
+				)
+
+	getexportinconflict (_, _, v) = v
+
+	updateexportdb db exportinconflict =
+		Export.updateExportTreeFromLog db >>= \case
+			Export.ExportUpdateSuccess -> return ()
+			Export.ExportUpdateConflict -> do
+				warnExportImportConflict r
+				liftIO $ atomically $
+					writeTVar exportinconflict True
+		
+	getanyexportlocs dbv k = do
+		db <- getexportdb dbv
+		liftIO $ Export.getExportTree db k
+	
+	getexportlocs dbv k = do
+		db <- getexportdb dbv
+		liftIO $ Export.getExportTree db k >>= \case
+			[] -> ifM (atomically $ readTVar $ getexportinconflict dbv)
+				( giveup "unknown export location, likely due to the export conflict"
+				, return []
+				)
+			ls -> return ls
+	
+	tryexportlocs dbv k a = 
+		go Nothing =<< getexportlocs dbv k
+	  where
+		go Nothing [] = giveup "unknown export location"
+		go (Just ex) [] = throwM ex
+		go _ (l:ls) = tryNonAsync (a l) >>= \case
+			Right v -> return v
+			Left e -> go (Just e) ls
+		
+	getkeycids ciddbv k = do
+		db <- getciddb ciddbv
+		liftIO $ ContentIdentifier.getContentIdentifiers db rs k
+
+	-- Keys can be retrieved using retrieveExport, but since that
+	-- retrieves from a path in the remote that another writer could
+	-- have replaced with content not of the requested key, the content
+	-- has to be strongly verified.
+	retrieveKeyFileFromExport dbv k _af dest p = ifM (isVerifiable k)
+		( tryexportlocs dbv k $ \loc -> 
+			retrieveExport (exportActions r) k loc dest p >>= return . \case
+				UnVerified -> MustVerify
+				IncompleteVerify iv -> MustFinishIncompleteVerify iv
+				v -> v
+		, giveup $ "exported content cannot be verified due to using the " ++ decodeBS (formatKeyVariety (fromKey keyVariety k)) ++ " backend"
+		)
+	
+	retrieveKeyFileFromImport dbv ciddbv k af dest p = do
+		cids <- getkeycids ciddbv k
+		if not (null cids)
+			then tryexportlocs dbv k $ \loc ->
+				snd <$> retrieveExportWithContentIdentifier (importActions r) loc cids dest (Left k) p
+			-- In case a content identifier is somehow missing,
+			-- try this instead.
+			else if isexport
+				then retrieveKeyFileFromExport dbv k af dest p
+				else giveup "no content identifier is recorded, unable to retrieve"
+	
+	-- versionedExport remotes have a key/value store, so can use
+	-- the usual retrieveKeyFile, rather than an import/export
+	-- variant. However, fall back to that if retrieveKeyFile fails.
+	supportversionedretrieve k af dest p vc a
+		| versionedExport (exportActions r) =
+			retrieveKeyFile r k af dest p vc
+				`catchNonAsync` const a
+		| otherwise = a
+
+	checkPresentImport ciddbv k loc =
+		checkPresentExportWithContentIdentifier
+			(importActions r)
+			k loc 
+			=<< getkeycids ciddbv k
diff --git a/Remote/Helper/Git.hs b/Remote/Helper/Git.hs
new file mode 100644
index 0000000000..ccefb231ea
--- /dev/null
+++ b/Remote/Helper/Git.hs
@@ -0,0 +1,68 @@
+{- Utilities for git remotes.
+ -
+ - Copyright 2011-2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Remote.Helper.Git where
+
+import Annex.Common
+import qualified Git
+import qualified Git.GCrypt
+import Types.Availability
+import qualified Types.Remote as Remote
+import qualified Utility.RawFilePath as R
+import qualified Git.Config
+
+import Data.Time.Clock.POSIX
+import System.PosixCompat.Files (modificationTime)
+
+repoCheap :: Git.Repo -> Bool
+repoCheap = not . Git.repoIsUrl
+
+localpathCalc :: Git.Repo -> Maybe FilePath
+localpathCalc r
+	| not (Git.repoIsLocal r) && not (Git.repoIsLocalUnknown r) = Nothing
+	| otherwise = Just $ fromRawFilePath $ Git.repoPath r
+
+{- Checks relatively inexpensively if a repository is available for use. -}
+repoAvail :: Git.Repo -> Annex Availability
+repoAvail r 
+	| Git.repoIsHttp r = return GloballyAvailable
+	| Git.GCrypt.isEncrypted r = do
+		g <- gitRepo
+		liftIO $ do
+			er <- Git.GCrypt.encryptedRemote g r
+			if Git.repoIsLocal er || Git.repoIsLocalUnknown er
+				then checklocal er
+				else return GloballyAvailable
+	| Git.repoIsUrl r = return GloballyAvailable
+	| Git.repoIsLocalUnknown r = return Unavailable
+	| otherwise = checklocal r
+  where
+	checklocal r' = ifM (liftIO $ isJust <$> catchMaybeIO (Git.Config.read r'))
+		( return LocallyAvailable
+		, return Unavailable
+		)
+
+{- Avoids performing an action on a local repository that's not usable.
+ - Does not check that the repository is still available on disk. -}
+guardUsable :: Git.Repo -> Annex a -> Annex a -> Annex a
+guardUsable r fallback a
+	| Git.repoIsLocalUnknown r = fallback
+	| otherwise = a
+
+gitRepoInfo :: Remote -> Annex [(String, String)]
+gitRepoInfo r = do
+	d <- fromRawFilePath <$> fromRepo Git.localGitDir
+	mtimes <- liftIO $ mapM (\p -> modificationTime <$> R.getFileStatus (toRawFilePath p))
+		=<< emptyWhenDoesNotExist (dirContentsRecursive (d </> "refs" </> "remotes" </> Remote.name r))
+	let lastsynctime = case mtimes of
+		[] -> "never"
+		_ -> show $ posixSecondsToUTCTime $ realToFrac $ maximum mtimes
+	repo <- Remote.getRepo r
+	return
+		[ ("repository location", Git.repoLocation repo)
+		, ("last synced", lastsynctime)
+		]
diff --git a/Remote/Helper/Hooks.hs b/Remote/Helper/Hooks.hs
new file mode 100644
index 0000000000..33c4771e46
--- /dev/null
+++ b/Remote/Helper/Hooks.hs
@@ -0,0 +1,98 @@
+{- Adds hooks to remotes.
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE CPP #-}
+
+module Remote.Helper.Hooks (addHooks) where
+
+import qualified Data.Map as M
+import qualified System.FilePath.ByteString as P
+
+import Annex.Common
+import Types.Remote
+import Types.CleanupActions
+import qualified Annex
+import Annex.LockFile
+import Annex.LockPool
+import Annex.Perms
+
+{- Modifies a remote's access functions to first run the
+ - annex-start-command hook, and trigger annex-stop-command on shutdown.
+ - This way, the hooks are only run when a remote is actively being used.
+ -}
+addHooks :: Remote -> Remote
+addHooks r = addHooks' r
+	(remoteAnnexStartCommand $ gitconfig r)
+	(remoteAnnexStopCommand $ gitconfig r)
+addHooks' :: Remote -> Maybe String -> Maybe String -> Remote
+addHooks' r Nothing Nothing = r
+addHooks' r starthook stophook = r'
+  where
+	r' = r
+		{ storeKey = \k f p -> 
+			wrapper $ storeKey r k f p
+		, retrieveKeyFile = \k f d p vc -> 
+			wrapper $ retrieveKeyFile r k f d p vc
+		, retrieveKeyFileCheap = case retrieveKeyFileCheap r of
+			Just a -> Just $ \k af f -> wrapper $ a k af f
+			Nothing -> Nothing
+		, removeKey = wrapper . removeKey r
+		, checkPresent = wrapper . checkPresent r
+		}
+	  where
+		wrapper = runHooks r' starthook stophook
+
+runHooks :: Remote -> Maybe String -> Maybe String -> Annex a -> Annex a
+runHooks r starthook stophook a = do
+	dir <- fromRepo gitAnnexRemotesDir
+	let lck = dir P.</> remoteid <> ".lck"
+	whenM (notElem lck . M.keys <$> getLockCache) $ do
+		createAnnexDirectory dir
+		firstrun lck
+	a
+  where
+	remoteid = fromUUID (uuid r)
+	run Nothing = noop
+	run (Just command) = void $ liftIO $
+		boolSystem "sh" [Param "-c", Param command]
+	firstrun lck = do
+		-- Take a shared lock; This indicates that git-annex
+		-- is using the remote, and prevents other instances
+		-- of it from running the stophook. If another
+		-- instance is shutting down right now, this
+		-- will block waiting for its exclusive lock to clear.
+		lockFileCached lck
+
+		-- The starthook is run even if some other git-annex
+		-- is already running, and ran it before.
+		-- It would be difficult to use locking to ensure
+		-- it's only run once, and it's also possible for
+		-- git-annex to be interrupted before it can run the
+		-- stophook, in which case the starthook
+		-- would be run again by the next git-annex.
+		-- So, requiring idempotency is the right approach.
+		run starthook
+
+		Annex.addCleanupAction (StopHook $ uuid r) $ runstop lck
+	runstop lck = do
+		-- Drop any shared lock we have, and take an
+		-- exclusive lock, without blocking. If the lock
+		-- succeeds, we're the only process using this remote,
+		-- so can stop it.
+		unlockFile lck
+#ifndef mingw32_HOST_OS
+		mode <- annexFileMode
+		v <- tryLockExclusive (Just mode) lck
+#else
+		v <- liftIO $ lockExclusive lck
+#endif
+		case v of
+			Nothing -> noop
+			Just lockhandle -> do
+				run stophook
+				liftIO $ dropLock lockhandle
diff --git a/Remote/Helper/Http.hs b/Remote/Helper/Http.hs
new file mode 100644
index 0000000000..09e246b31f
--- /dev/null
+++ b/Remote/Helper/Http.hs
@@ -0,0 +1,93 @@
+{- helpers for remotes using http
+ -
+ - Copyright 2014-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Remote.Helper.Http where
+
+import Annex.Common
+import Types.StoreRetrieve
+import Remote.Helper.Special
+import Utility.Metered
+import Utility.Hash (IncrementalVerifier(..))
+
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString as S
+import Control.Concurrent
+import Network.HTTP.Client (RequestBody(..), Response, responseStatus, responseBody, BodyReader, NeedsPopper)
+import Network.HTTP.Types
+
+-- A storer that expects to be provided with a http RequestBody containing
+-- the content to store.
+--
+-- Implemented as a fileStorer, so that the content can be streamed
+-- from the file in constant space.
+httpStorer :: (Key -> RequestBody -> Annex ()) -> Storer
+httpStorer a = fileStorer $ \k f m -> a k =<< liftIO (httpBodyStorer f m)
+
+-- Reads the file and generates a streaming request body, that will update
+-- the meter as it's sent.
+httpBodyStorer :: FilePath -> MeterUpdate -> IO RequestBody
+httpBodyStorer src m = do
+	size <- getFileSize (toRawFilePath src)
+	let streamer sink = withMeteredFile src m $ \b -> byteStringPopper b sink
+	return $ RequestBodyStream (fromInteger size) streamer
+
+-- Like httpBodyStorer, but generates a chunked request body.
+httpBodyStorerChunked :: FilePath -> MeterUpdate -> RequestBody
+httpBodyStorerChunked src m =
+	let streamer sink = withMeteredFile src m $ \b -> byteStringPopper b sink
+	in RequestBodyStreamChunked streamer
+
+byteStringPopper :: L.ByteString -> NeedsPopper () -> IO ()
+byteStringPopper b sink = do
+	mvar <- newMVar $ L.toChunks b
+	let getnextchunk = modifyMVar mvar $ \v ->
+		case v of
+			[] -> return ([], S.empty)
+			(c:cs) -> return (cs, c)
+	sink getnextchunk
+
+{- Makes a Popper that streams a given number of chunks of a given
+ - size from the handle, updating the meter as the chunks are read. -}
+handlePopper :: Integer -> Int -> MeterUpdate -> Handle -> NeedsPopper () -> IO ()
+handlePopper numchunks chunksize meterupdate h sink = do
+	mvar <- newMVar zeroBytesProcessed
+	let getnextchunk = do
+		sent <- takeMVar mvar
+		if sent >= target
+			then do
+				putMVar mvar sent
+				return S.empty
+			else do
+				b <- S.hGet h chunksize
+				let !sent' = addBytesProcessed sent chunksize
+				putMVar mvar sent'
+                                meterupdate sent'
+				return b
+	sink getnextchunk
+  where
+	target = toBytesProcessed (numchunks * fromIntegral chunksize)
+
+-- Reads the http body and stores it to the specified file, updating the
+-- meter and incremental verifier as it goes.
+httpBodyRetriever :: FilePath -> MeterUpdate -> Maybe IncrementalVerifier -> Response BodyReader -> IO ()
+httpBodyRetriever dest meterupdate iv resp
+	| responseStatus resp /= ok200 = giveup $ show $ responseStatus resp
+	| otherwise = bracket (openBinaryFile dest WriteMode) hClose (go zeroBytesProcessed)
+  where
+	reader = responseBody resp
+	go sofar h = do
+		b <- reader
+		if S.null b
+			then return ()
+			else do
+				let sofar' = addBytesProcessed sofar $ S.length b
+				S.hPut h b
+				meterupdate sofar'
+				maybe noop (flip updateIncrementalVerifier b) iv
+				go sofar' h
diff --git a/Remote/Helper/Messages.hs b/Remote/Helper/Messages.hs
new file mode 100644
index 0000000000..0ef25a7132
--- /dev/null
+++ b/Remote/Helper/Messages.hs
@@ -0,0 +1,32 @@
+{- git-annex remote messages
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-}
+
+module Remote.Helper.Messages where
+
+import Annex.Common
+import qualified Git
+import qualified Types.Remote as Remote
+
+class Describable a where
+	describe :: a -> String
+
+instance Describable Git.Repo where
+	describe = Git.repoDescribe
+
+instance Describable (Remote.RemoteA a) where
+	describe = Remote.name
+
+instance Describable String where
+	describe = id
+
+cantCheck :: Describable a => a -> e
+cantCheck v = giveup $ "unable to check " ++ describe v
+
+showLocking :: Describable a => a -> Annex ()
+showLocking v = showAction $ UnquotedString $ "locking " ++ describe v
diff --git a/Remote/Helper/P2P.hs b/Remote/Helper/P2P.hs
new file mode 100644
index 0000000000..ed9d3bffa4
--- /dev/null
+++ b/Remote/Helper/P2P.hs
@@ -0,0 +1,80 @@
+{- Helpers for remotes using the git-annex P2P protocol.
+ -
+ - Copyright 2016-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+
+module Remote.Helper.P2P where
+
+import Annex.Common
+import qualified P2P.Protocol as P2P
+import P2P.IO
+import Types.Remote
+import Annex.Content
+import Messages.Progress
+import Utility.Metered
+import Utility.Tuple
+import Types.NumCopies
+import Annex.Verify
+
+import Control.Concurrent
+
+-- Runs a Proto action using a connection it sets up.
+type ProtoRunner a = P2P.Proto a -> Annex (Maybe a)
+
+-- Runs a Proto action using a ClosableConnection.
+type ProtoConnRunner c = forall a. P2P.Proto a -> ClosableConnection c -> Annex (ClosableConnection c, Maybe a)
+
+-- Runs an Annex action with a connection from the pool, adding it back to
+-- the pool when done.
+type WithConn a c = (ClosableConnection c -> Annex (ClosableConnection c, a)) -> Annex a
+
+store :: RemoteGitConfig -> ProtoRunner Bool -> Key -> AssociatedFile -> MeterUpdate -> Annex ()
+store gc runner k af p = do
+	let sizer = KeySizer k (fmap (toRawFilePath . fst3) <$> prepSendAnnex k)
+	let bwlimit = remoteAnnexBwLimitUpload gc <|> remoteAnnexBwLimit gc
+	metered (Just p) sizer bwlimit $ \_ p' ->
+		runner (P2P.put k af p') >>= \case
+			Just True -> return ()
+			Just False -> giveup "Transfer failed"
+			Nothing -> remoteUnavail
+
+retrieve :: RemoteGitConfig -> (ProtoRunner (Bool, Verification)) -> Key -> AssociatedFile -> FilePath -> MeterUpdate -> VerifyConfig -> Annex Verification
+retrieve gc runner k af dest p verifyconfig = do
+	iv <- startVerifyKeyContentIncrementally verifyconfig k
+	let bwlimit = remoteAnnexBwLimitDownload gc <|> remoteAnnexBwLimit gc
+	metered (Just p) k bwlimit $ \m p' -> 
+		runner (P2P.get dest k iv af m p') >>= \case
+			Just (True, v) -> return v
+			Just (False, _) -> giveup "Transfer failed"
+			Nothing -> remoteUnavail
+
+remove :: ProtoRunner Bool -> Key -> Annex ()
+remove runner k = runner (P2P.remove k) >>= \case
+	Just True -> return ()
+	Just False -> giveup "removing content from remote failed"
+	Nothing -> remoteUnavail
+
+checkpresent :: ProtoRunner Bool -> Key -> Annex Bool
+checkpresent runner k = maybe remoteUnavail return =<< runner (P2P.checkPresent k)
+
+lock :: WithConn a c -> ProtoConnRunner c -> UUID -> Key -> (VerifiedCopy -> Annex a) -> Annex a
+lock withconn connrunner u k callback = withconn $ \conn -> do
+	connv <- liftIO $ newMVar conn
+	let runproto d p = do
+		c <- liftIO $ takeMVar connv
+		(c', mr) <- connrunner p c
+		liftIO $ putMVar connv c'
+		return (fromMaybe d mr)
+	r <- P2P.lockContentWhile runproto k go
+	conn' <- liftIO $ takeMVar connv
+	return (conn', r)
+  where
+	go False = giveup "can't lock content"
+	go True = withVerifiedCopy LockedCopy u (return True) callback
+
+remoteUnavail :: a
+remoteUnavail = giveup "can't connect to remote"
diff --git a/Remote/Helper/Path.hs b/Remote/Helper/Path.hs
new file mode 100644
index 0000000000..fef6b486f7
--- /dev/null
+++ b/Remote/Helper/Path.hs
@@ -0,0 +1,19 @@
+{- Utilities for remotes located in a path in the filesystem.
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Remote.Helper.Path where
+
+import Annex.Common
+import Types.Availability
+
+checkPathAvailability :: Bool -> FilePath -> Annex Availability
+checkPathAvailability islocal d
+	| not islocal = return GloballyAvailable
+	| otherwise = ifM (liftIO $ doesDirectoryExist d)
+		( return LocallyAvailable
+		, return Unavailable
+		)
diff --git a/Remote/Helper/ReadOnly.hs b/Remote/Helper/ReadOnly.hs
new file mode 100644
index 0000000000..abce2fe2f4
--- /dev/null
+++ b/Remote/Helper/ReadOnly.hs
@@ -0,0 +1,75 @@
+{- Adds readonly support to remotes.
+ -
+ - Copyright 2013-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Remote.Helper.ReadOnly
+	( adjustReadOnly
+	, readonlyStoreKey
+	, readonlyStorer
+	, readonlyRemoveKey
+	) where
+
+import Annex.Common
+import Types.Remote
+import Types.StoreRetrieve
+import Types.Import
+import Types.Export
+import Utility.Metered
+
+{- Adds support for read-only remotes, by replacing the
+ - methods that write to a remote with dummies that fail.
+ -
+ - Note that disabling git pushes to remotes is not handled here.
+ -}
+adjustReadOnly :: Remote -> Remote
+adjustReadOnly r
+	| remoteAnnexReadOnly (gitconfig r) = r
+		{ storeKey = readonlyStoreKey
+		, removeKey = readonlyRemoveKey
+		, repairRepo = Nothing
+		, exportActions = (exportActions r)
+			{ storeExport = readonlyStoreExport
+			, removeExport = readonlyRemoveExport
+			, removeExportDirectory = Just readonlyRemoveExportDirectory
+			, renameExport = Nothing
+			}
+		, importActions = (importActions r)
+			{ storeExportWithContentIdentifier = readonlyStoreExportWithContentIdentifier
+			, removeExportWithContentIdentifier = readonlyRemoveExportWithContentIdentifier
+			, removeExportDirectoryWhenEmpty = Just readonlyRemoveExportDirectory
+			}
+		}
+	| otherwise = r
+
+readonlyStoreKey :: Key -> AssociatedFile -> MeterUpdate -> Annex ()
+readonlyStoreKey _ _ _ = readonlyFail
+
+readonlyRemoveKey :: Key -> Annex ()
+readonlyRemoveKey _ = readonlyFail
+
+readonlyStorer :: Storer
+readonlyStorer _ _ _ = readonlyFail
+
+readonlyStoreExport :: FilePath -> Key -> ExportLocation -> MeterUpdate -> Annex ()
+readonlyStoreExport _ _ _ _ = readonlyFail
+
+readonlyRemoveExport :: Key -> ExportLocation -> Annex ()
+readonlyRemoveExport _ _ = readonlyFail
+
+readonlyRemoveExportDirectory :: ExportDirectory -> Annex ()
+readonlyRemoveExportDirectory _ = readonlyFail
+
+readonlyStoreExportWithContentIdentifier :: FilePath -> Key -> ExportLocation -> [ContentIdentifier] -> MeterUpdate -> Annex ContentIdentifier
+readonlyStoreExportWithContentIdentifier _ _ _ _ _ = readonlyFail
+
+readonlyRemoveExportWithContentIdentifier :: Key -> ExportLocation -> [ContentIdentifier] -> Annex ()
+readonlyRemoveExportWithContentIdentifier _ _ _ = readonlyFail
+
+readonlyFail :: Annex a
+readonlyFail = giveup readonlyWarning
+
+readonlyWarning :: String
+readonlyWarning = "this remote is readonly"
diff --git a/Remote/Helper/Special.hs b/Remote/Helper/Special.hs
new file mode 100644
index 0000000000..4cb6124159
--- /dev/null
+++ b/Remote/Helper/Special.hs
@@ -0,0 +1,265 @@
+{- helpers for special remotes
+ -
+ - Copyright 2011-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Remote.Helper.Special (
+	findSpecialRemotes,
+	gitConfigSpecialRemote,
+	mkRetrievalVerifiableKeysSecure,
+	Storer,
+	Retriever,
+	Remover,
+	CheckPresent,
+	ContentSource,
+	fileStorer,
+	byteStorer,
+	fileRetriever,
+	fileRetriever',
+	byteRetriever,
+	storeKeyDummy,
+	retrieveKeyFileDummy,
+	removeKeyDummy,
+	checkPresentDummy,
+	SpecialRemoteCfg(..),
+	specialRemoteCfg,
+	specialRemoteConfigParsers,
+	specialRemoteType,
+	specialRemote,
+	specialRemote',
+	lookupName,
+	module X
+) where
+
+import Annex.Common
+import Annex.SpecialRemote.Config
+import Types.StoreRetrieve
+import Types.Remote
+import Annex.Verify
+import Annex.UUID
+import Config
+import Config.Cost
+import Utility.Metered
+import Remote.Helper.Chunked as X
+import Remote.Helper.Encryptable as X
+import Annex.Content
+import Messages.Progress
+import qualified Git
+import qualified Git.Construct
+import Git.Types
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Map as M
+
+{- Special remotes don't have a configured url, so Git.Repo does not
+ - automatically generate remotes for them. This looks for a different
+ - configuration key instead.
+ -}
+findSpecialRemotes :: String -> Annex [Git.Repo]
+findSpecialRemotes s = do
+	m <- fromRepo Git.config
+	liftIO $ catMaybes <$> mapM construct (remotepairs m)
+  where
+	remotepairs = M.toList . M.filterWithKey match
+	construct (k,_) = Git.Construct.remoteNamedFromKey k
+		(pure Git.Construct.fromUnknown)
+	match (ConfigKey k) _ =
+		"remote." `S.isPrefixOf` k 
+		&& (".annex-" <> encodeBS s) `S.isSuffixOf` k
+
+{- Sets up configuration for a special remote in .git/config. -}
+gitConfigSpecialRemote :: UUID -> RemoteConfig -> [(String, String)] -> Annex ()
+gitConfigSpecialRemote u c cfgs = do
+	forM_ cfgs $ \(k, v) -> 
+		setConfig (remoteAnnexConfig c (encodeBS k)) v
+	storeUUIDIn (remoteAnnexConfig c "uuid") u
+
+-- RetrievalVerifiableKeysSecure unless overridden by git config.
+--
+-- Only looks at the RemoteGitConfig; the GitConfig's setting is
+-- checked at the same place the RetrievalSecurityPolicy is checked.
+mkRetrievalVerifiableKeysSecure :: RemoteGitConfig -> RetrievalSecurityPolicy
+mkRetrievalVerifiableKeysSecure gc
+	| remoteAnnexAllowUnverifiedDownloads gc = RetrievalAllKeysSecure
+	| otherwise = RetrievalVerifiableKeysSecure
+
+-- A Storer that expects to be provided with a file containing
+-- the content of the key to store.
+fileStorer :: (Key -> FilePath -> MeterUpdate -> Annex ()) -> Storer
+fileStorer a k (FileContent f) m = a k f m
+fileStorer a k (ByteContent b) m = withTmp k $ \f -> do
+	let f' = fromRawFilePath f
+	liftIO $ L.writeFile f' b
+	a k f' m
+
+-- A Storer that expects to be provided with a L.ByteString of
+-- the content to store.
+byteStorer :: (Key -> L.ByteString -> MeterUpdate -> Annex ()) -> Storer
+byteStorer a k c m = withBytes c $ \b -> a k b m
+
+-- A Retriever that generates a lazy ByteString containing the Key's
+-- content, and passes it to a callback action which will fully consume it
+-- before returning.
+byteRetriever :: (Key -> (L.ByteString -> Annex a) -> Annex a) -> Key -> MeterUpdate -> Maybe IncrementalVerifier -> (ContentSource -> Annex a) -> Annex a
+byteRetriever a k _m _miv callback = a k (callback . ByteContent)
+
+-- A Retriever that writes the content of a Key to a provided file.
+-- The action is responsible for updating the progress meter as it 
+-- retrieves data. The incremental verifier is updated in the background as
+-- the action writes to the file, but may not be updated with the entire
+-- content of the file.
+fileRetriever :: (RawFilePath -> Key -> MeterUpdate -> Annex ()) -> Retriever
+fileRetriever a = fileRetriever' $ \f k m miv -> 
+	let retrieve = a f k m
+	in tailVerify miv f retrieve
+
+{- A Retriever that writes the content of a Key to a provided file.
+ - The action is responsible for updating the progress meter and the 
+ - incremental verifier as it retrieves data.
+ -}
+fileRetriever' :: (RawFilePath -> Key -> MeterUpdate -> Maybe IncrementalVerifier -> Annex ()) -> Retriever
+fileRetriever' a k m miv callback = do
+	f <- prepTmp k
+	a f k m miv
+	pruneTmpWorkDirBefore f (callback . FileContent . fromRawFilePath)
+
+{- The base Remote that is provided to specialRemote needs to have
+ - storeKey, retrieveKeyFile, removeKey, and checkPresent methods,
+ - but they are never actually used (since specialRemote replaces them).
+ - Here are some dummy ones.
+ -}
+storeKeyDummy :: Key -> AssociatedFile -> MeterUpdate -> Annex ()
+storeKeyDummy _ _ _ = error "missing storeKey implementation"
+retrieveKeyFileDummy :: Key -> AssociatedFile -> FilePath -> MeterUpdate -> VerifyConfig -> Annex Verification
+retrieveKeyFileDummy _ _ _ _ _ = error "missing retrieveKeyFile implementation"
+removeKeyDummy :: Key -> Annex ()
+removeKeyDummy _ = error "missing removeKey implementation"
+checkPresentDummy :: Key -> Annex Bool
+checkPresentDummy _ = error "missing checkPresent implementation"
+
+type RemoteModifier
+	= ParsedRemoteConfig
+	-> Storer
+	-> Retriever
+	-> Remover
+	-> CheckPresent
+	-> Remote
+	-> Remote
+
+data SpecialRemoteCfg = SpecialRemoteCfg
+	{ chunkConfig :: ChunkConfig
+	, displayProgress :: Bool
+	}
+
+specialRemoteCfg :: ParsedRemoteConfig -> SpecialRemoteCfg
+specialRemoteCfg c = SpecialRemoteCfg (getChunkConfig c) True
+
+-- Modifies a base RemoteType to support chunking and encryption configs.
+specialRemoteType :: RemoteType -> RemoteType
+specialRemoteType r = r 
+	{ configParser = \c -> addRemoteConfigParser specialRemoteConfigParsers
+		<$> configParser r c
+	}
+
+specialRemoteConfigParsers :: [RemoteConfigFieldParser]
+specialRemoteConfigParsers = chunkConfigParsers ++ encryptionConfigParsers
+
+-- Modifies a base Remote to support both chunking and encryption,
+-- which special remotes typically should support.
+-- 
+-- Handles progress displays when displayProgress is set.
+specialRemote :: RemoteModifier
+specialRemote c = specialRemote' (specialRemoteCfg c) c
+
+specialRemote' :: SpecialRemoteCfg -> RemoteModifier
+specialRemote' cfg c storer retriever remover checkpresent baser = encr
+  where
+	encr = baser
+		{ storeKey = \k _f p -> cip >>= storeKeyGen k p
+		, retrieveKeyFile = \k _f d p vc -> cip >>= retrieveKeyFileGen k d p vc
+		, retrieveKeyFileCheap = case retrieveKeyFileCheap baser of
+			Nothing -> Nothing
+			Just a
+				-- retrieval of encrypted keys is never cheap
+				| isencrypted -> Nothing
+				| otherwise -> Just $ \k f d -> a k f d
+		-- When encryption is used, the remote could provide
+		-- some other content encrypted by the user, and trick
+		-- git-annex into decrypting it, leaking the decryption
+		-- into the git-annex repository. Verifiable keys
+		-- are the main protection against this attack.
+		, retrievalSecurityPolicy = if isencrypted
+			then mkRetrievalVerifiableKeysSecure (gitconfig baser)
+			else retrievalSecurityPolicy baser
+		, removeKey = \k -> cip >>= removeKeyGen k
+		, checkPresent = \k -> cip >>= checkPresentGen k
+		, cost = if isencrypted
+			then cost baser + encryptedRemoteCostAdj
+			else cost baser
+		, getInfo = do
+			l <- getInfo baser
+			return $ l ++
+				[ ("encryption", describeEncryption c)
+				, ("chunking", describeChunkConfig (chunkConfig cfg))
+				]
+		, whereisKey = if noChunks (chunkConfig cfg) && not isencrypted
+			then whereisKey baser
+			else Nothing
+		, exportActions = (exportActions baser)
+			{ storeExport = \f k l p -> displayprogress uploadbwlimit p k (Just f) $
+				storeExport (exportActions baser) f k l
+			, retrieveExport = \k l f p -> displayprogress downloadbwlimit p k Nothing $
+				retrieveExport (exportActions baser) k l f
+			}
+		}
+	cip = cipherKey c (gitconfig baser)
+	isencrypted = isEncrypted c
+
+	-- chunk, then encrypt, then feed to the storer
+	storeKeyGen k p enc = sendAnnex k rollback $ \src _sz ->
+		displayprogress uploadbwlimit p k (Just src) $ \p' ->
+			storeChunks (uuid baser) chunkconfig enck k src p'
+				enc encr storer checkpresent
+	  where
+		rollback = void $ removeKey encr k
+		enck = maybe id snd enc
+
+	-- call retriever to get chunks; decrypt them; stream to dest file
+	retrieveKeyFileGen k dest p vc enc =
+		displayprogress downloadbwlimit p k Nothing $ \p' ->
+			retrieveChunks retriever (uuid baser) vc
+				chunkconfig enck k dest p' enc encr
+	  where
+		enck = maybe id snd enc
+
+	removeKeyGen k enc = 
+		removeChunks remover (uuid baser) chunkconfig enck k
+	  where
+		enck = maybe id snd enc
+
+	checkPresentGen k enc = 
+		checkPresentChunks checkpresent (uuid baser) chunkconfig enck k
+	  where
+		enck = maybe id snd enc
+
+	chunkconfig = chunkConfig cfg
+
+	downloadbwlimit = remoteAnnexBwLimitDownload (gitconfig baser)
+		<|> remoteAnnexBwLimit (gitconfig baser)
+	uploadbwlimit = remoteAnnexBwLimitUpload (gitconfig baser)
+		<|> remoteAnnexBwLimit (gitconfig baser)
+
+	displayprogress bwlimit p k srcfile a
+		| displayProgress cfg = do
+			metered (Just p) (KeySizer k (pure (fmap toRawFilePath srcfile))) bwlimit (const a)
+		| otherwise = a p
+
+withBytes :: ContentSource -> (L.ByteString -> Annex a) -> Annex a
+withBytes (ByteContent b) a = a b
+withBytes (FileContent f) a = a =<< liftIO (L.readFile f)
diff --git a/Remote/Helper/Ssh.hs b/Remote/Helper/Ssh.hs
new file mode 100644
index 0000000000..7a7da481bc
--- /dev/null
+++ b/Remote/Helper/Ssh.hs
@@ -0,0 +1,327 @@
+{- git-annex remote access with ssh and git-annex-shell
+ -
+ - Copyright 2011-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Remote.Helper.Ssh where
+
+import Annex.Common
+import qualified Annex
+import qualified Git
+import qualified Git.Url
+import Annex.UUID
+import Annex.Ssh
+import CmdLine.GitAnnexShell.Fields (Field, fieldName)
+import qualified CmdLine.GitAnnexShell.Fields as Fields
+import Remote.Helper.Messages
+import Utility.Metered
+import Utility.Rsync
+import Utility.SshHost
+import Types.Remote
+import Types.Transfer
+import Config
+import qualified P2P.Protocol as P2P
+import qualified P2P.IO as P2P
+import qualified P2P.Annex as P2P
+
+import Control.Concurrent.STM
+
+toRepo :: ConsumeStdin -> Git.Repo -> RemoteGitConfig -> SshCommand -> Annex (FilePath, [CommandParam])
+toRepo cs r gc remotecmd = do
+	let host = maybe
+		(giveup "bad ssh url")
+		(either giveup id . mkSshHost)
+		(Git.Url.hostuser r)
+	sshCommand cs (host, Git.Url.port r) gc remotecmd
+
+{- Generates parameters to run a git-annex-shell command on a remote
+ - repository. -}
+git_annex_shell :: ConsumeStdin -> Git.Repo -> String -> [CommandParam] -> [(Field, String)] -> Annex (Maybe (FilePath, [CommandParam]))
+git_annex_shell cs r command params fields
+	| not $ Git.repoIsUrl r = do
+		shellopts <- getshellopts
+		return $ Just (shellcmd, shellopts ++ fieldopts)
+	| Git.repoIsSsh r = do
+		gc <- Annex.getRemoteGitConfig r
+		u <- getRepoUUID r
+		shellopts <- getshellopts
+		let sshcmd = unwords $
+			fromMaybe shellcmd (remoteAnnexShell gc)
+				: map shellEscape (toCommand shellopts) ++
+			uuidcheck u ++
+			map shellEscape (toCommand fieldopts)
+		Just <$> toRepo cs r gc sshcmd
+	| otherwise = return Nothing
+  where
+	dir = Git.repoPath r
+	shellcmd = "git-annex-shell"
+	getshellopts = do
+		debugenabled <- Annex.getRead Annex.debugenabled
+		let params' = if debugenabled
+			then Param "--debug" : params
+			else params
+		return (Param command : File (fromRawFilePath dir) : params')
+	uuidcheck NoUUID = []
+	uuidcheck u@(UUID _) = ["--uuid", fromUUID u]
+	fieldopts
+		| null fields = []
+		| otherwise = fieldsep : map fieldopt fields ++ [fieldsep]
+	fieldsep = Param "--"
+	fieldopt (field, value) = Param $
+		fieldName field ++ "=" ++ value
+
+{- Uses a supplied function (such as boolSystem) to run a git-annex-shell
+ - command on a remote.
+ -
+ - Or, if the remote does not support running remote commands, returns
+ - a specified error value. -}
+onRemote 
+	:: ConsumeStdin
+	-> Git.Repo
+	-> (FilePath -> [CommandParam] -> Annex a, Annex a)
+	-> String
+	-> [CommandParam]
+	-> [(Field, String)]
+	-> Annex a
+onRemote cs r (with, errorval) command params fields = do
+	s <- git_annex_shell cs r command params fields
+	case s of
+		Just (c, ps) -> with c ps
+		Nothing -> errorval
+
+{- Checks if a remote contains a key. -}
+inAnnex :: Git.Repo -> Key -> Annex Bool
+inAnnex r k = onRemote NoConsumeStdin r (runcheck, cantCheck r) "inannex"
+	[Param $ serializeKey k] []
+  where
+	runcheck c p = liftIO $ dispatch =<< safeSystem c p
+	dispatch ExitSuccess = return True
+	dispatch (ExitFailure 1) = return False
+	dispatch _ = cantCheck r
+
+{- Removes a key from a remote. -}
+dropKey :: Git.Repo -> Key -> Annex ()
+dropKey r key = unlessM (dropKey' r key) $
+	giveup "unable to remove key from remote"
+
+dropKey' :: Git.Repo -> Key -> Annex Bool
+dropKey' r key = onRemote NoConsumeStdin r (\f p -> liftIO (boolSystem f p), return False) "dropkey"
+	[ Param "--quiet", Param "--force"
+	, Param $ serializeKey key
+	]
+	[]
+
+rsyncHelper :: OutputHandler -> Maybe MeterUpdate -> [CommandParam] -> Annex Bool
+rsyncHelper oh m params = do
+	unless (quietMode oh) $
+		showOutput -- make way for progress bar
+	a <- case m of
+		Nothing -> return $ rsync params
+		Just meter -> return $ rsyncProgress oh meter params
+	ifM (liftIO a)
+		( return True
+		, do
+			showLongNote "rsync failed -- run git annex again to resume file transfer"
+			return False
+		)
+
+{- Generates rsync parameters that ssh to the remote and asks it
+ - to either receive or send the key's content. -}
+rsyncParamsRemote :: Remote -> Direction -> Key -> FilePath -> Annex [CommandParam]
+rsyncParamsRemote r direction key file = do
+	u <- getUUID
+	repo <- getRepo r
+	Just (shellcmd, shellparams) <- git_annex_shell ConsumeStdin repo
+		(if direction == Download then "sendkey" else "recvkey")
+		[ Param $ serializeKey key ]
+		[(Fields.remoteUUID, fromUUID u)]
+	-- Convert the ssh command into rsync command line.
+	let eparam = rsyncShell (Param shellcmd:shellparams)
+	o <- rsyncParams r direction
+	return $ if direction == Download
+		then o ++ rsyncopts eparam dummy (File file)
+		else o ++ rsyncopts eparam (File file) dummy
+  where
+	rsyncopts ps source dest
+		| end ps == [dashdash] = ps ++ [source, dest]
+		| otherwise = ps ++ [dashdash, source, dest]
+	dashdash = Param "--"
+	{- The rsync shell parameter controls where rsync
+	 - goes, so the source/dest parameter can be a dummy value,
+	 - that just enables remote rsync mode.
+	 - For maximum compatibility with some patched rsyncs,
+	 - the dummy value needs to still contain a hostname,
+	 - even though this hostname will never be used. -}
+	dummy = Param "dummy:"
+
+-- --inplace to resume partial files
+--
+-- Only use --perms when not on a crippled file system, as rsync
+-- will fail trying to restore file perms onto a filesystem that does not
+-- support them.
+rsyncParams :: Remote -> Direction -> Annex [CommandParam]
+rsyncParams r direction = do
+	crippled <- crippledFileSystem
+	return $ map Param $ catMaybes
+		[ Just "--progress"
+		, Just "--inplace"
+		, if crippled then Nothing else Just "--perms"
+		] 
+		++ remoteAnnexRsyncOptions gc ++ dps
+  where
+	dps
+		| direction == Download = remoteAnnexRsyncDownloadOptions gc
+		| otherwise = remoteAnnexRsyncUploadOptions gc
+	gc = gitconfig r
+
+-- A connection over ssh to git-annex shell speaking the P2P protocol.
+type P2PSshConnection = P2P.ClosableConnection 
+	(P2P.RunState, P2P.P2PConnection, ProcessHandle)
+
+closeP2PSshConnection :: P2PSshConnection -> IO (P2PSshConnection, Maybe ExitCode)
+closeP2PSshConnection P2P.ClosedConnection = return (P2P.ClosedConnection, Nothing)
+closeP2PSshConnection (P2P.OpenConnection (_st, conn, pid)) =
+	-- mask async exceptions, avoid cleanup being interrupted
+	uninterruptibleMask_ $ do
+		P2P.closeConnection conn
+		exitcode <- waitForProcess pid
+		return (P2P.ClosedConnection, Just exitcode)
+
+-- Pool of connections over ssh to git-annex-shell p2pstdio.
+type P2PSshConnectionPool = TVar (Maybe P2PSshConnectionPoolState)
+
+data P2PSshConnectionPoolState
+	= P2PSshConnections [P2PSshConnection]
+	-- Remotes using an old version of git-annex-shell don't support P2P
+	| P2PSshUnsupported
+
+mkP2PSshConnectionPool :: Annex P2PSshConnectionPool
+mkP2PSshConnectionPool = liftIO $ newTVarIO Nothing
+
+-- Takes a connection from the pool, if any are available, otherwise
+-- tries to open a new one.
+getP2PSshConnection :: Remote -> P2PSshConnectionPool -> Annex (Maybe P2PSshConnection)
+getP2PSshConnection r connpool = getexistingconn >>= \case
+	Nothing -> return Nothing
+	Just Nothing -> openP2PSshConnection r connpool
+	Just (Just c) -> return (Just c)
+  where
+	getexistingconn = liftIO $ atomically $ readTVar connpool >>= \case
+		Just P2PSshUnsupported -> return Nothing
+		Just (P2PSshConnections (c:cs)) -> do
+			writeTVar connpool (Just (P2PSshConnections cs))
+			return (Just (Just c))
+		Just (P2PSshConnections []) -> return (Just Nothing)
+		Nothing -> return (Just Nothing)
+
+-- Add a connection to the pool, unless it's closed.
+storeP2PSshConnection :: P2PSshConnectionPool -> P2PSshConnection -> IO ()
+storeP2PSshConnection _ P2P.ClosedConnection = return ()
+storeP2PSshConnection connpool conn = atomically $ modifyTVar' connpool $ \case
+	Just (P2PSshConnections cs) -> Just (P2PSshConnections (conn:cs))
+	_ -> Just (P2PSshConnections [conn])
+
+-- Try to open a P2PSshConnection.
+-- The new connection is not added to the pool, so it's available
+-- for the caller to use.
+-- If the remote does not support the P2P protocol, that's remembered in 
+-- the connection pool.
+openP2PSshConnection :: Remote -> P2PSshConnectionPool -> Annex (Maybe P2PSshConnection)
+openP2PSshConnection r connpool = do
+	u <- getUUID
+	let ps = [Param (fromUUID u)]
+	repo <- getRepo r
+	git_annex_shell ConsumeStdin repo "p2pstdio" ps [] >>= \case
+		Nothing -> do
+			liftIO $ rememberunsupported
+			return Nothing
+		Just (cmd, params) -> start cmd params =<< getRepo r
+  where
+	start cmd params repo = liftIO $ do
+		(Just from, Just to, Nothing, pid) <- createProcess $
+			(proc cmd (toCommand params))
+				{ std_in = CreatePipe
+				, std_out = CreatePipe
+				}
+		pidnum <- getPid pid
+		let conn = P2P.P2PConnection
+			{ P2P.connRepo = repo
+			, P2P.connCheckAuth = const False
+			, P2P.connIhdl = to
+			, P2P.connOhdl = from
+			, P2P.connIdent = P2P.ConnIdent $
+				Just $ "ssh connection " ++ show pidnum
+			}
+		runst <- P2P.mkRunState P2P.Client
+		let c = P2P.OpenConnection (runst, conn, pid)
+		-- When the connection is successful, the remote
+		-- will send an AUTH_SUCCESS with its uuid.
+		let proto = P2P.postAuth $
+			P2P.negotiateProtocolVersion P2P.maxProtocolVersion
+		tryNonAsync (P2P.runNetProto runst conn proto) >>= \case
+			Right (Right (Just theiruuid)) | theiruuid == uuid r ->
+				return $ Just c
+			_ -> do
+				(cclosed, exitcode) <- closeP2PSshConnection c
+				-- ssh exits 255 when unable to connect to
+				-- server.
+				if exitcode == Just (ExitFailure 255)
+					then return (Just cclosed)
+					else do
+						rememberunsupported
+						return Nothing
+	rememberunsupported = atomically $
+		modifyTVar' connpool $
+			maybe (Just P2PSshUnsupported) Just
+
+-- Runs a P2P Proto action on a remote when it supports that,
+-- otherwise the fallback action.
+runProto :: Remote -> P2PSshConnectionPool -> Annex a -> P2P.Proto a -> Annex (Maybe a)
+runProto r connpool onerr proto = Just <$>
+	(getP2PSshConnection r connpool >>= maybe onerr go)
+  where
+	go c = do
+		(c', v) <- runProtoConn proto c
+		case v of
+			Just res -> do
+				liftIO $ storeP2PSshConnection connpool c'
+				return res
+			Nothing -> onerr
+
+runProtoConn :: P2P.Proto a -> P2PSshConnection -> Annex (P2PSshConnection, Maybe a)
+runProtoConn _ P2P.ClosedConnection = return (P2P.ClosedConnection, Nothing)
+runProtoConn a conn@(P2P.OpenConnection (runst, c, _)) = do
+	P2P.runFullProto runst c a >>= \case
+		Right r -> return (conn, Just r)
+		-- When runFullProto fails, the connection is no longer
+		-- usable, so close it.
+		Left e -> do
+			warning $ UnquotedString $ "Lost connection (" ++ P2P.describeProtoFailure e ++ ")"
+			conn' <- fst <$> liftIO (closeP2PSshConnection conn)
+			return (conn', Nothing)
+
+-- Allocates a P2P ssh connection from the pool, and runs the action with it,
+-- returning the connection to the pool once the action is done.
+--
+-- If the remote does not support the P2P protocol, runs the fallback
+-- action instead.
+withP2PSshConnection
+	:: Remote
+	-> P2PSshConnectionPool
+	-> Annex a
+	-> (P2PSshConnection -> Annex (P2PSshConnection, a))
+	-> Annex a
+withP2PSshConnection r connpool fallback a = bracketOnError get cache go
+  where
+	get = getP2PSshConnection r connpool
+	cache (Just conn) = liftIO $ storeP2PSshConnection connpool conn
+	cache Nothing = return ()
+	go (Just conn) = do
+		(conn', res) <- a conn
+		cache (Just conn')
+		return res
+	go Nothing = fallback
diff --git a/Remote/Helper/ThirdPartyPopulated.hs b/Remote/Helper/ThirdPartyPopulated.hs
new file mode 100644
index 0000000000..beeadd3109
--- /dev/null
+++ b/Remote/Helper/ThirdPartyPopulated.hs
@@ -0,0 +1,85 @@
+{- Helpers for thirdPartyPopulated remotes
+ -
+ - Copyright 2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Remote.Helper.ThirdPartyPopulated where
+
+import Annex.Common
+import Types.Remote
+import Types.Import
+import Crypto (isEncKey)
+import Utility.Metered
+
+import qualified System.FilePath.ByteString as P
+import qualified Data.ByteString as S
+
+-- When a remote is thirdPartyPopulated, the files we want are probably
+-- in the .git directory. But, git does not really support .git in paths
+-- in a git tree. (Such a tree can be built, but it will lead to problems.)
+-- And so anything in .git is prevented from being imported.
+-- To work around that, this renames that directory when generating an
+-- ImportLocation.
+mkThirdPartyImportLocation :: RawFilePath -> ImportLocation
+mkThirdPartyImportLocation =
+	mkImportLocation . P.joinPath . map esc . P.splitDirectories
+  where
+	esc ".git" = "dotgit"
+	esc x
+		| "dotgit" `S.isSuffixOf` x = "dot" <> x
+		| otherwise = x
+
+fromThirdPartyImportLocation :: ImportLocation -> RawFilePath
+fromThirdPartyImportLocation =
+	P.joinPath . map unesc . P.splitDirectories . fromImportLocation
+  where
+	unesc "dotgit" = ".git"
+	unesc x
+		| "dotgit" `S.isSuffixOf` x = S.drop 3 x
+		| otherwise = x
+
+-- When a remote is thirdPartyPopulated, and contains a backup of a
+-- git-annex repository or some special remotes, this can be used to
+-- find only those ImportLocations that are annex object files.
+-- All other ImportLocations are ignored.
+importKey :: ImportLocation -> ContentIdentifier -> ByteSize -> MeterUpdate -> Annex (Maybe Key)
+importKey loc _cid sz _ = return $ importKey' (fromImportLocation loc) (Just sz)
+
+importKey' :: RawFilePath -> Maybe ByteSize -> Maybe Key
+importKey' p msz = case fileKey f of
+	Just k
+		-- Annex objects always are in a subdirectory with the same
+		-- name as the filename. If this is not the case for the file
+		-- that was backed up, it is probably not a valid annex object.
+		-- Eg, it could be something in annex/bad/, or annex/tmp/.
+		-- Or it could be a file that only happens to have a name
+		-- like an annex object.
+		-- (This does unfortunately prevent recognizing files that are
+		-- part of special remotes that don't use that layout. The most
+		-- likely special remote to be in a backup, the directory
+		-- special remote, does use that layout at least.)
+		| lastMaybe (P.splitDirectories (P.dropFileName p)) /= Just f -> Nothing
+		-- Chunked or encrypted keys used in special remotes are not
+		-- supported.
+		| isChunkKey k || isEncKey k -> Nothing
+		-- Check that the size of the key is the same as the size of the
+		-- file stored in the backup. This is a cheap way to make sure it's
+		-- probabably the actual content of the file. We don't fully
+		-- verify the content here because that could be a very 
+		-- expensive operation for a large repository; if the user
+		-- wants to detect every possible data corruption problem
+		-- (eg, wrong data read off disk during backup, or the object
+		-- was corrupt in the git-annex repo and that bad object got
+		-- backed up), they can fsck the remote.
+		| otherwise -> case (msz, fromKey keySize k) of
+			(Just sz, Just sz')
+				| sz' == sz -> Just k
+				| otherwise -> Nothing
+			_ -> Just k
+	Nothing -> Nothing
+  where
+	f = P.takeFileName p
diff --git a/Remote/Hook.hs b/Remote/Hook.hs
new file mode 100644
index 0000000000..a7dd3e6593
--- /dev/null
+++ b/Remote/Hook.hs
@@ -0,0 +1,183 @@
+{- A remote that provides hooks to run shell commands.
+ -
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+
+module Remote.Hook (remote) where
+
+import Annex.Common
+import Types.Remote
+import Types.Creds
+import qualified Git
+import Git.Types (fromConfigKey, fromConfigValue)
+import Config
+import Config.Cost
+import Annex.UUID
+import Annex.SpecialRemote.Config
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import Utility.Env
+import Messages.Progress
+import Types.ProposedAccepted
+
+import qualified Data.Map as M
+
+type Action = String
+type HookName = String
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "hook"
+	, enumerate = const (findSpecialRemotes "hooktype")
+	, generate = gen
+	, configParser = mkRemoteConfigParser
+		[ optionalStringParser hooktypeField
+			(FieldDesc "(required) specify collection of hooks to use")
+		]
+	, setup = hookSetup
+	, exportSupported = exportUnsupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+hooktypeField :: RemoteConfigField
+hooktypeField = Accepted "hooktype"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	cst <- remoteCost gc c expensiveRemoteCost
+	return $ Just $ specialRemote c
+		(store hooktype)
+		(retrieve hooktype)
+		(remove hooktype)
+		(checkKey hooktype)
+		Remote
+			{ uuid = u
+			, cost = cst
+			, name = Git.repoDescribe r
+			, storeKey = storeKeyDummy
+			, retrieveKeyFile = retrieveKeyFileDummy
+			, retrieveKeyFileCheap = Nothing
+			-- A hook could use http and be vulnerable to
+			-- redirect to file:// attacks, etc.
+			, retrievalSecurityPolicy = mkRetrievalVerifiableKeysSecure gc
+			, removeKey = removeKeyDummy
+			, lockContent = Nothing
+			, checkPresent = checkPresentDummy
+			, checkPresentCheap = False
+			, exportActions = exportUnsupported
+			, importActions = importUnsupported
+			, whereisKey = Nothing
+			, remoteFsck = Nothing
+			, repairRepo = Nothing
+			, config = c
+			, localpath = Nothing
+			, getRepo = return r
+			, gitconfig = gc
+			, readonly = False
+			, appendonly = False
+			, untrustworthy = False
+			, availability = pure GloballyAvailable
+			, remotetype = remote
+			, mkUnavailable = gen r u rc
+				(gc { remoteAnnexHookType = Just "!dne!" })
+				rs
+			, getInfo = return [("hooktype", hooktype)]
+			, claimUrl = Nothing
+			, checkUrl = Nothing
+			, remoteStateHandle = rs
+			}
+  where
+	hooktype = fromMaybe (giveup "missing hooktype") $ remoteAnnexHookType gc
+
+hookSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+hookSetup _ mu _ c gc = do
+	u <- maybe (liftIO genUUID) return mu
+	let hooktype = maybe (giveup "Specify hooktype=") fromProposedAccepted $
+		M.lookup hooktypeField c
+	(c', _encsetup) <- encryptionSetup c gc
+	gitConfigSpecialRemote u c' [("hooktype", hooktype)]
+	return (c', u)
+
+hookEnv :: Action -> Key -> Maybe FilePath -> IO (Maybe [(String, String)])
+hookEnv action k f = Just <$> mergeenv (fileenv f ++ keyenv)
+  where
+	mergeenv l = addEntries l <$> getEnvironment
+	envvar s v = ("ANNEX_" ++ s, v)
+	keyenv = catMaybes
+		[ Just $ envvar "KEY" (serializeKey k)
+		, Just $ envvar "ACTION" action
+		, envvar "HASH_1" <$> headMaybe hashbits
+		, envvar "HASH_2" <$> headMaybe (drop 1 hashbits)
+		]
+	fileenv Nothing = []
+	fileenv (Just file) =  [envvar "FILE" file]
+	hashbits = map takeDirectory $ splitPath $
+		fromRawFilePath $ hashDirMixed def k
+
+lookupHook :: HookName -> Action -> Annex (Maybe String)
+lookupHook hookname action = do
+	command <- fromConfigValue <$> getConfig hook mempty
+	if null command
+		then do
+			fallback <- fromConfigValue <$> getConfig hookfallback mempty
+			if null fallback
+				then do
+					warning $ UnquotedString $ "missing configuration for " ++ fromConfigKey hook ++ " or " ++ fromConfigKey hookfallback
+					return Nothing
+				else return $ Just fallback
+		else return $ Just command
+  where
+	hook = annexConfig $ encodeBS $ hookname ++ "-" ++ action ++ "-hook"
+	hookfallback = annexConfig $ encodeBS $ hookname ++ "-hook"
+
+runHook :: HookName -> Action -> Key -> Maybe FilePath -> Annex ()
+runHook hook action k f = lookupHook hook action >>= \case
+	Just command -> do
+		showOutput -- make way for hook output
+		environ <- liftIO (hookEnv action k f)
+		unlessM (progressCommandEnv "sh" [Param "-c", Param command] environ) $
+			giveup $ hook ++ " hook exited nonzero!"
+	Nothing -> giveup $ action ++ " hook misconfigured"
+
+runHook' :: HookName -> Action -> Key -> Maybe FilePath -> Annex Bool -> Annex Bool
+runHook' hook action k f a = maybe (return False) run =<< lookupHook hook action
+  where
+	run command = do
+		showOutput -- make way for hook output
+		ifM (progressCommandEnv "sh" [Param "-c", Param command] =<< liftIO (hookEnv action k f))
+			( a
+			, do
+				warning $ UnquotedString $ hook ++ " hook exited nonzero!"
+				return False
+			)
+
+store :: HookName -> Storer
+store h = fileStorer $ \k src _p -> runHook h "store" k (Just src)
+
+retrieve :: HookName -> Retriever
+retrieve h = fileRetriever $ \d k _p ->
+	unlessM (runHook' h "retrieve" k (Just (fromRawFilePath d)) $ return True) $
+		giveup "failed to retrieve content"
+
+remove :: HookName -> Remover
+remove h k = 
+	unlessM (runHook' h "remove" k Nothing $ return True) $
+		giveup "failed to remove content"
+
+checkKey :: HookName -> CheckPresent
+checkKey h k = do
+	v <- lookupHook h action
+	liftIO $ check v
+  where
+	action = "checkpresent"
+	findkey s = serializeKey k `elem` lines s
+	check Nothing = giveup $ action ++ " hook misconfigured"
+	check (Just hook) = do
+		environ <- hookEnv action k Nothing
+		findkey <$> readProcessEnv "sh" ["-c", hook] environ
diff --git a/Remote/HttpAlso.hs b/Remote/HttpAlso.hs
new file mode 100644
index 0000000000..06003b7b54
--- /dev/null
+++ b/Remote/HttpAlso.hs
@@ -0,0 +1,232 @@
+{- HttpAlso remote (readonly).
+ -
+ - Copyright 2020-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+
+module Remote.HttpAlso (remote) where
+
+import Annex.Common
+import Types.Remote
+import Types.ProposedAccepted
+import Types.Export
+import Remote.Helper.ExportImport
+import Remote.Helper.Special
+import qualified Git
+import Config.Cost
+import Config
+import Logs.Web
+import Creds
+import Utility.Metered
+import Annex.Verify
+import qualified Annex.Url as Url
+import Annex.SpecialRemote.Config
+
+import Data.Either
+import qualified Data.Map as M
+import System.FilePath.Posix as P
+import Control.Concurrent.STM
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "httpalso"
+	, enumerate = const (findSpecialRemotes "httpalso")
+	, generate = gen
+	, configParser = mkRemoteConfigParser 
+		[ optionalStringParser urlField
+			(FieldDesc "(required) url to the remote content")
+		]
+	, setup = httpAlsoSetup
+	, exportSupported = exportIsSupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+urlField :: RemoteConfigField
+urlField = Accepted "url"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	cst <- remoteCost gc c expensiveRemoteCost
+	let url = getRemoteConfigValue urlField c
+	ll <- liftIO newLearnedLayout
+	return $ Just $ specialRemote c
+		cannotModify
+		(downloadKey url ll)
+		cannotModify
+		(checkKey url ll)
+		(this url c cst)
+  where
+	this url c cst = Remote
+		{ uuid = u
+		, cost = cst
+		, name = Git.repoDescribe r
+		, storeKey = cannotModify
+		, retrieveKeyFile = retrieveKeyFileDummy
+		, retrieveKeyFileCheap = Nothing
+		-- HttpManagerRestricted is used here, so this is
+		-- secure.
+		, retrievalSecurityPolicy = RetrievalAllKeysSecure
+		, removeKey = cannotModify
+		, lockContent = Nothing
+		, checkPresent = checkPresentDummy
+		, checkPresentCheap = False
+		, exportActions = ExportActions
+			{ storeExport = cannotModify
+			, retrieveExport = retriveExportHttpAlso url
+			, removeExport = cannotModify
+			, versionedExport = False
+			, checkPresentExport = checkPresentExportHttpAlso url
+			, removeExportDirectory = Nothing
+			, renameExport = cannotModify
+			}
+		, importActions = importUnsupported
+		, whereisKey = Nothing
+		, remoteFsck = Nothing
+		, repairRepo = Nothing
+		, config = c
+		, gitconfig = gc
+		, localpath = Nothing
+		, getRepo = return r
+		, readonly = True
+		, appendonly = False
+		, untrustworthy = False
+		, availability = pure GloballyAvailable
+		, remotetype = remote
+		, mkUnavailable = return Nothing
+		, getInfo = return []
+		, claimUrl = Nothing
+		, checkUrl = Nothing
+		, remoteStateHandle = rs
+		}
+
+cannotModify :: a
+cannotModify = giveup "httpalso special remote is read only"
+
+httpAlsoSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+httpAlsoSetup _ Nothing _ _ _ =
+	giveup "Must use --sameas when initializing a httpalso remote."
+httpAlsoSetup _ (Just u) _ c gc = do
+	_url <- maybe (giveup "Specify url=")
+		(return . fromProposedAccepted)
+		(M.lookup urlField c)
+	c' <- if isJust (M.lookup encryptionField c)
+		then fst <$> encryptionSetup c gc
+		else pure c
+	gitConfigSpecialRemote u c' [("httpalso", "true")]
+	return (c', u)
+
+downloadKey :: Maybe URLString -> LearnedLayout -> Retriever
+downloadKey baseurl ll = fileRetriever' $ \dest key p iv ->
+	downloadAction (fromRawFilePath dest) p iv (keyUrlAction baseurl ll key)
+
+retriveExportHttpAlso :: Maybe URLString -> Key -> ExportLocation -> FilePath -> MeterUpdate -> Annex Verification
+retriveExportHttpAlso baseurl key loc dest p = do
+	verifyKeyContentIncrementally AlwaysVerify key $ \iv ->
+		downloadAction dest p iv (exportLocationUrlAction baseurl loc)
+
+downloadAction :: FilePath -> MeterUpdate -> Maybe IncrementalVerifier -> ((URLString -> Annex (Either String ())) -> Annex (Either String ())) -> Annex ()
+downloadAction dest p iv run =
+	Url.withUrlOptions $ \uo ->
+		run (\url -> Url.download' p iv url dest uo)
+			>>= either giveup (const (return ()))
+
+checkKey :: Maybe URLString -> LearnedLayout -> CheckPresent
+checkKey baseurl ll key =
+	isRight <$> keyUrlAction baseurl ll key (checkKey' key)
+
+checkKey' :: Key -> URLString -> Annex (Either String ())
+checkKey' key url = ifM (Url.withUrlOptions $ Url.checkBoth url (fromKey keySize key))
+	( return (Right ())
+	, return (Left "content not found")
+	)
+
+checkPresentExportHttpAlso :: Maybe URLString -> Key -> ExportLocation -> Annex Bool
+checkPresentExportHttpAlso baseurl key loc =
+	isRight <$> exportLocationUrlAction baseurl loc (checkKey' key)
+
+type LearnedLayout = TVar (Maybe [Key -> URLString])
+
+newLearnedLayout :: IO LearnedLayout
+newLearnedLayout = newTVarIO Nothing
+
+-- Learns which layout the special remote uses, so once any action on an
+-- url succeeds, subsequent calls will continue to use that layout
+-- (or related layouts).
+keyUrlAction
+	:: Maybe URLString
+	-> LearnedLayout
+	-> Key
+	-> (URLString -> Annex (Either String ()))
+	-> Annex (Either String ())
+keyUrlAction (Just baseurl) ll key downloader =
+	liftIO (readTVarIO ll) >>= \case
+		Just learned -> go Nothing False [learned]
+		Nothing -> go Nothing True (supportedLayouts baseurl)
+  where
+	go err learn [] = go' err learn [] []
+	go err learn (layouts:rest) = go' err learn layouts [] >>= \case
+		Right () -> return (Right ())
+		Left err' -> go (Just err') learn rest
+	
+	go' (Just err) _ [] _ = pure (Left err)
+	go' Nothing _ [] _ = error "internal"
+	go' _err learn (layout:rest) prevs = 
+		downloader (layout key) >>= \case
+			Right () -> do
+				when learn $ do
+					let learned = layout:prevs++rest
+					liftIO $ atomically $
+						writeTVar ll (Just learned)
+				return (Right ())
+			Left err -> go' (Just err) learn rest (layout:prevs)
+keyUrlAction Nothing _ _ _ = noBaseUrlError
+
+exportLocationUrlAction
+	:: Maybe URLString
+	-> ExportLocation
+	-> (URLString -> Annex (Either String ()))
+	-> Annex (Either String ())
+exportLocationUrlAction (Just baseurl) loc a =
+	a (baseurl P.</> fromRawFilePath (fromExportLocation loc))
+exportLocationUrlAction Nothing _ _ = noBaseUrlError
+
+-- cannot normally happen
+noBaseUrlError :: Annex a
+noBaseUrlError = giveup "no url configured for httpalso special remote"
+
+-- Different ways that keys can be laid out in the special remote,
+-- with the more common first.
+--
+-- This is a nested list, because a single remote may use more than one
+-- layout. In particular, old versions of git-annex used hashDirMixed
+-- for some special remotes, before switching to hashDirLower for new data.
+-- So, when learning the layout, both need to be tried.
+supportedLayouts :: URLString -> [[Key -> URLString]]
+supportedLayouts baseurl =
+	-- Layout used for bare git-annex repos, and for many
+	-- special remotes like directory.
+	[ [ \k -> mkurl k (hashDirLower (HashLevels 2)) P.</> kf k
+	-- Layout used for non-bare git-annex repos, and for some old
+	-- special remotes.
+	  , \k -> mkurl k (hashDirMixed (HashLevels 2)) P.</> kf k
+	  ]
+	-- Special remotes that do not need hash directories.
+	, [ \k -> baseurl P.</> kf k ]
+	-- Layouts without a key directory, used by some special remotes.
+	, [ \k -> mkurl k (hashDirLower def)
+	  , \k -> mkurl k (hashDirMixed def)
+	  ]
+	-- Layouts with only 1 level of hash directory, 
+	-- rather than the default 2.
+	, [ \k -> mkurl k (hashDirLower (HashLevels 1))
+	  , \k -> mkurl k (hashDirMixed (HashLevels 1))
+	  ]
+	]
+  where
+	mkurl k hasher = baseurl P.</> fromRawFilePath (hasher k) P.</> kf k
+	kf k = fromRawFilePath (keyFile k)
diff --git a/Remote/List.hs b/Remote/List.hs
new file mode 100644
index 0000000000..e884a25a3b
--- /dev/null
+++ b/Remote/List.hs
@@ -0,0 +1,119 @@
+{- git-annex remote list
+ -
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Remote.List where
+
+import qualified Data.Map as M
+
+import Annex.Common
+import qualified Annex
+import Logs.Remote
+import Types.Remote
+import Types.RemoteState
+import Annex.UUID
+import Remote.Helper.Hooks
+import Remote.Helper.ReadOnly
+import Remote.Helper.ExportImport
+import qualified Git
+
+import qualified Remote.Git
+import qualified Remote.GCrypt
+import qualified Remote.P2P
+import qualified Remote.S3
+import qualified Remote.Bup
+import qualified Remote.Directory
+import qualified Remote.Rsync
+import qualified Remote.Web
+import qualified Remote.BitTorrent
+import qualified Remote.WebDAV
+import qualified Remote.Adb
+import qualified Remote.Tahoe
+import qualified Remote.Glacier
+import qualified Remote.Ddar
+import qualified Remote.GitLFS
+import qualified Remote.HttpAlso
+import qualified Remote.Borg
+import qualified Remote.Rclone
+import qualified Remote.Hook
+import qualified Remote.External
+
+remoteTypes :: [RemoteType]
+remoteTypes = map adjustExportImportRemoteType
+	[ Remote.Git.remote
+	, Remote.GCrypt.remote
+	, Remote.P2P.remote
+	, Remote.S3.remote
+	, Remote.Bup.remote
+	, Remote.Directory.remote
+	, Remote.Rsync.remote
+	, Remote.Web.remote
+	, Remote.BitTorrent.remote
+	, Remote.WebDAV.remote
+	, Remote.Adb.remote
+	, Remote.Tahoe.remote
+	, Remote.Glacier.remote
+	, Remote.Ddar.remote
+	, Remote.GitLFS.remote
+	, Remote.HttpAlso.remote
+	, Remote.Borg.remote
+	, Remote.Rclone.remote
+	, Remote.Hook.remote
+	, Remote.External.remote
+	]
+
+{- Builds a list of all available Remotes.
+ - Since doing so can be expensive, the list is cached. -}
+remoteList :: Annex [Remote]
+remoteList = do
+	rs <- Annex.getState Annex.remotes
+	if null rs
+		then remoteList' False
+		else return rs
+
+remoteList' :: Bool -> Annex [Remote]
+remoteList' autoinit = do
+	m <- remoteConfigMap
+	rs <- concat <$> mapM (process m) remoteTypes
+	Annex.changeState $ \s -> s { Annex.remotes = rs }
+	return rs
+  where
+	process m t = enumerate t autoinit 
+		>>= mapM (remoteGen m t) 
+		>>= return . catMaybes
+
+{- Generates a Remote. -}
+remoteGen :: M.Map UUID RemoteConfig -> RemoteType -> Git.Repo -> Annex (Maybe Remote)
+remoteGen m t g = do
+	u <- getRepoUUID g
+	gc <- Annex.getRemoteGitConfig g
+	let cu = fromMaybe u $ remoteAnnexConfigUUID gc
+	let rs = RemoteStateHandle cu
+	let c = fromMaybe M.empty $ M.lookup cu m
+	generate t g u c gc rs >>= \case
+		Nothing -> return Nothing
+		Just r -> Just <$> adjustExportImport (adjustReadOnly (addHooks r)) rs
+
+{- Updates a local git Remote, re-reading its git config. -}
+updateRemote :: Remote -> Annex (Maybe Remote)
+updateRemote remote = do
+	m <- remoteConfigMap
+	remote' <- updaterepo =<< getRepo remote
+	remoteGen m (remotetype remote) remote'
+  where
+	updaterepo r
+		| Git.repoIsLocal r || Git.repoIsLocalUnknown r =
+			Remote.Git.configRead False r
+		| otherwise = return r
+
+{- Checks if a remote is syncable using git. -}
+gitSyncableRemoteType :: RemoteType -> Bool
+gitSyncableRemoteType t = t `elem`
+	[ Remote.Git.remote
+	, Remote.GCrypt.remote
+	, Remote.P2P.remote
+	, Remote.GitLFS.remote
+	]
diff --git a/Remote/List/Util.hs b/Remote/List/Util.hs
new file mode 100644
index 0000000000..382a98fa5d
--- /dev/null
+++ b/Remote/List/Util.hs
@@ -0,0 +1,24 @@
+{- git-annex remote list utils
+ -
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Remote.List.Util where
+
+import Annex.Common
+import qualified Annex
+import qualified Git.Config
+
+{- Call when remotes have changed. Re-reads the git config, and
+ - invalidates the cache so the remoteList will be re-generated next time
+ - it's used. -}
+remotesChanged :: Annex ()
+remotesChanged = do
+	newg <- inRepo Git.Config.reRead
+	Annex.changeState $ \s -> s 
+		{ Annex.remotes = []
+		, Annex.gitremotes = Nothing
+		, Annex.repo = newg
+		}
diff --git a/Remote/P2P.hs b/Remote/P2P.hs
new file mode 100644
index 0000000000..4b47e2f489
--- /dev/null
+++ b/Remote/P2P.hs
@@ -0,0 +1,173 @@
+{- git remotes using the git-annex P2P protocol
+ -
+ - Copyright 2016-2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Remote.P2P (
+	remote,
+	chainGen
+) where
+
+import Annex.Common
+import qualified Annex
+import qualified P2P.Protocol as P2P
+import P2P.Address
+import P2P.Annex
+import P2P.IO
+import P2P.Auth
+import Types.Remote
+import qualified Git
+import Annex.UUID
+import Config
+import Config.Cost
+import Remote.Helper.Git
+import Remote.Helper.ExportImport
+import Remote.Helper.P2P
+import Utility.AuthToken
+import Annex.SpecialRemote.Config
+
+import Control.Concurrent.STM
+
+remote :: RemoteType
+remote = RemoteType
+	{ typename = "p2p"
+	-- Remote.Git takes care of enumerating P2P remotes,
+	-- and will call chainGen on them.
+	, enumerate = const (return [])
+	, generate = \_ _ _ _ _ -> return Nothing
+	, configParser = mkRemoteConfigParser []
+	, setup = giveup "P2P remotes are set up using git-annex p2p"
+	, exportSupported = exportUnsupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+chainGen :: P2PAddress -> Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+chainGen addr r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	connpool <- mkConnectionPool
+	cst <- remoteCost gc c veryExpensiveRemoteCost
+	let protorunner = runProto u addr connpool
+	let withconn = withConnection u addr connpool
+	let this = Remote 
+		{ uuid = u
+		, cost = cst
+		, name = Git.repoDescribe r
+		, storeKey = store gc protorunner
+		, retrieveKeyFile = retrieve gc protorunner
+		, retrieveKeyFileCheap = Nothing
+		, retrievalSecurityPolicy = RetrievalAllKeysSecure
+		, removeKey = remove protorunner
+		, lockContent = Just $ lock withconn runProtoConn u 
+		, checkPresent = checkpresent protorunner
+		, checkPresentCheap = False
+		, exportActions = exportUnsupported
+		, importActions = importUnsupported
+		, whereisKey = Nothing
+		, remoteFsck = Nothing
+		, repairRepo = Nothing
+		, config = c
+		, localpath = Nothing
+		, getRepo = return r
+		, gitconfig = gc
+		, readonly = False
+		, appendonly = False
+		, untrustworthy = False
+		, availability = pure GloballyAvailable
+		, remotetype = remote
+		, mkUnavailable = return Nothing
+		, getInfo = gitRepoInfo this
+		, claimUrl = Nothing
+		, checkUrl = Nothing
+		, remoteStateHandle = rs
+	}
+	return (Just this)
+
+-- | A connection to the peer, which can be closed.
+type Connection = ClosableConnection (RunState, P2PConnection)
+
+type ConnectionPool = TVar [Connection]
+
+mkConnectionPool :: Annex ConnectionPool
+mkConnectionPool = liftIO $ newTVarIO []
+
+-- Runs the Proto action.
+runProto :: UUID -> P2PAddress -> ConnectionPool -> P2P.Proto a -> Annex (Maybe a)
+runProto u addr connpool a = withConnection u addr connpool (runProtoConn a)
+
+runProtoConn :: P2P.Proto a -> Connection -> Annex (Connection, Maybe a)
+runProtoConn _ ClosedConnection = return (ClosedConnection, Nothing)
+runProtoConn a c@(OpenConnection (runst, conn)) = do
+	v <- runFullProto runst conn a
+	-- When runFullProto fails, the connection is no longer usable,
+	-- so close it.
+	case v of
+		Left e -> do
+			warning $ UnquotedString $ "Lost connection to peer (" ++ describeProtoFailure e ++ ")"
+			liftIO $ closeConnection conn
+			return (ClosedConnection, Nothing)
+		Right r -> return (c, Just r)
+
+-- Uses an open connection if one is available in the ConnectionPool;
+-- otherwise opens a new connection.
+--
+-- Once the action is done, the connection is added back to the
+-- ConnectionPool, unless it's no longer open.
+withConnection :: UUID -> P2PAddress -> ConnectionPool -> (Connection -> Annex (Connection, a)) -> Annex a
+withConnection u addr connpool a = bracketOnError get cache go
+  where
+	get = do
+		mc <- liftIO $ atomically $ do
+			l <- readTVar connpool
+			case l of
+				[] -> do
+					writeTVar connpool []
+					return Nothing
+				(c:cs) -> do
+					writeTVar connpool cs
+					return (Just c)
+		maybe (openConnection u addr) return mc
+	
+	cache ClosedConnection = return ()
+	cache conn = liftIO $ atomically $ modifyTVar' connpool (conn:)
+
+	go conn = do
+		(conn', r) <- a conn
+		cache conn'
+		return r
+
+openConnection :: UUID -> P2PAddress -> Annex Connection
+openConnection u addr = do
+	g <- Annex.gitRepo
+	v <- liftIO $ tryNonAsync $ connectPeer g addr
+	case v of
+		Right conn -> do
+			myuuid <- getUUID
+			authtoken <- fromMaybe nullAuthToken
+				<$> loadP2PRemoteAuthToken addr
+			let proto = P2P.auth myuuid authtoken $
+				P2P.negotiateProtocolVersion P2P.maxProtocolVersion
+			runst <- liftIO $ mkRunState Client
+			res <- liftIO $ runNetProto runst conn proto
+			case res of
+				Right (Just theiruuid)
+					| u == theiruuid -> return (OpenConnection (runst, conn))
+					| otherwise -> do
+						liftIO $ closeConnection conn
+						warning "Remote peer uuid seems to have changed."
+						return ClosedConnection
+				Right Nothing -> do
+					warning "Unable to authenticate with peer."
+					liftIO $ closeConnection conn
+					return ClosedConnection
+				Left e -> do
+					warning $ UnquotedString $ "Problem communicating with peer. (" ++ describeProtoFailure e ++ ")"
+					liftIO $ closeConnection conn
+					return ClosedConnection
+		Left e -> do
+			warning $ UnquotedString $ "Unable to connect to peer. (" ++ show e ++ ")"
+			return ClosedConnection
diff --git a/Remote/Rclone.hs b/Remote/Rclone.hs
new file mode 100644
index 0000000000..a2ab8f501f
--- /dev/null
+++ b/Remote/Rclone.hs
@@ -0,0 +1,31 @@
+{- Rclone special remote, using "rclone gitannex"
+ -
+ - Copyright 2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Remote.Rclone (remote) where
+
+import Types
+import Types.Remote
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import Utility.SafeCommand
+import qualified Remote.External as External
+import Remote.External.Types
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "rclone"
+	, enumerate = const (findSpecialRemotes "rclone")
+	, generate = External.gen remote p
+	, configParser = External.remoteConfigParser p
+	, setup = External.externalSetup p setgitconfig 
+	, exportSupported = External.checkExportSupported p
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+  where
+	p = Just $ ExternalCommand "rclone" [Param "gitannex"]
+	setgitconfig = Just ("rclone", "true")
diff --git a/Remote/Rsync.hs b/Remote/Rsync.hs
new file mode 100644
index 0000000000..b225f8db14
--- /dev/null
+++ b/Remote/Rsync.hs
@@ -0,0 +1,414 @@
+{- A remote that is only accessible by rsync.
+ -
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP, OverloadedStrings #-}
+
+module Remote.Rsync (
+	remote,
+	store,
+	retrieve,
+	remove,
+	checkKey,
+	withRsyncScratchDir,
+	rsyncRemoteConfigs,
+	genRsyncOpts,
+	RsyncOpts,
+	probeRsyncProtectsArgs,
+) where
+
+import Annex.Common
+import Types.Remote
+import qualified Git
+import Config
+import Config.Cost
+import Annex.Content
+import Annex.UUID
+import Annex.Ssh
+import Annex.Perms
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import Remote.Helper.Path
+import Types.Export
+import Types.ProposedAccepted
+import Remote.Rsync.RsyncUrl
+import Crypto
+import Utility.Rsync
+import Utility.CopyFile
+import Utility.Process.Transcript
+import Messages.Progress
+import Utility.Metered
+import Types.Transfer
+import Types.Creds
+import Annex.DirHashes
+import Utility.Tmp.Dir
+import Utility.SshHost
+import Annex.SpecialRemote.Config
+import Annex.Verify
+import qualified Utility.RawFilePath as R
+
+import qualified Data.Map as M
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "rsync"
+	, enumerate = const (findSpecialRemotes "rsyncurl")
+	, generate = gen
+	, configParser = mkRemoteConfigParser $ rsyncRemoteConfigs ++
+		[ optionalStringParser rsyncUrlField
+			(FieldDesc "(required) url or hostname:/directory for rsync to use")
+		]
+	, setup = rsyncSetup
+	, exportSupported = exportIsSupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+shellEscapeField :: RemoteConfigField
+shellEscapeField = Accepted "shellescape"
+
+rsyncUrlField :: RemoteConfigField
+rsyncUrlField = Accepted "rsyncurl"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	cst <- remoteCost gc c expensiveRemoteCost
+	(transport, url) <- rsyncTransport gc $
+		fromMaybe (giveup "missing rsyncurl") $ remoteAnnexRsyncUrl gc
+	protectsargs <- liftIO probeRsyncProtectsArgs
+	let o = genRsyncOpts protectsargs c gc transport url
+	let islocal = rsyncUrlIsPath $ rsyncUrl o
+	return $ Just $ specialRemote c
+		(fileStorer $ store o)
+		(fileRetriever $ retrieve o)
+		(remove o)
+		(checkKey o)
+		Remote
+			{ uuid = u
+			, cost = cst
+			, name = Git.repoDescribe r
+			, storeKey = storeKeyDummy
+			, retrieveKeyFile = retrieveKeyFileDummy
+			, retrieveKeyFileCheap = Just (retrieveCheap o)
+			, retrievalSecurityPolicy = RetrievalAllKeysSecure
+			, removeKey = removeKeyDummy
+			, lockContent = Nothing
+			, checkPresent = checkPresentDummy
+			, checkPresentCheap = False
+			, exportActions = ExportActions
+				{ storeExport = storeExportM o
+				, retrieveExport = retrieveExportM o
+				, removeExport = removeExportM o
+				, versionedExport = False
+				, checkPresentExport = checkPresentExportM o
+				, removeExportDirectory = Just (removeExportDirectoryM o)
+				, renameExport = Just $ renameExportM o
+				}
+			, importActions = importUnsupported
+			, whereisKey = Nothing
+			, remoteFsck = Nothing
+			, repairRepo = Nothing
+			, config = c
+			, getRepo = return r
+			, gitconfig = gc
+			, localpath = if islocal
+				then Just $ rsyncUrl o
+				else Nothing
+			, readonly = False
+			, appendonly = False
+			, untrustworthy = False
+			, availability = checkPathAvailability islocal (rsyncUrl o)
+			, remotetype = remote
+			, mkUnavailable = return Nothing
+			, getInfo = return [("url", url)]
+			, claimUrl = Nothing
+			, checkUrl = Nothing
+			, remoteStateHandle = rs
+			}
+
+-- | Since 3.2.4, rsync protects filenames from being exposed to the shell.
+newtype RsyncProtectsArgs = RsyncProtectsArgs Bool
+
+probeRsyncProtectsArgs :: IO RsyncProtectsArgs
+probeRsyncProtectsArgs = do
+	(helpoutput, _) <- processTranscript "rsync" ["--help"] Nothing
+	-- The --old-args option was added to disable the new arg
+	-- protection, so use it to detect when that feature is supported
+	-- by rsync, rather than parsing versions.
+	return (RsyncProtectsArgs $ "--old-args" `isInfixOf` helpoutput)
+
+
+-- Things used by genRsyncOpts
+rsyncRemoteConfigs :: [RemoteConfigFieldParser]
+rsyncRemoteConfigs = 
+	[ yesNoParser shellEscapeField (Just True)
+		(FieldDesc "set to no to avoid usual shell escaping (not recommended)")
+	]
+
+genRsyncOpts :: RsyncProtectsArgs -> ParsedRemoteConfig -> RemoteGitConfig -> Annex [CommandParam] -> RsyncUrl -> RsyncOpts
+genRsyncOpts (RsyncProtectsArgs protectsargs) c gc transport url = RsyncOpts
+	{ rsyncUrl = url
+	, rsyncOptions = appendtransport $ opts []
+	, rsyncUploadOptions = appendtransport $
+		opts (remoteAnnexRsyncUploadOptions gc)
+	, rsyncDownloadOptions = appendtransport $
+		opts (remoteAnnexRsyncDownloadOptions gc)
+	, rsyncShellEscape = if protectsargs
+		then False
+		else fromMaybe True (getRemoteConfigValue shellEscapeField c)
+	}
+  where
+	appendtransport l = (++ l) <$> transport
+	opts specificopts = map Param $ filter safe $
+		remoteAnnexRsyncOptions gc ++ specificopts
+	safe opt
+		-- Don't allow user to pass --delete to rsync;
+		-- that could cause it to delete other keys
+		-- in the same hash bucket as a key it sends.
+		| opt == "--delete" = False
+		| opt == "--delete-excluded" = False
+		| otherwise = True
+
+rsyncTransport :: RemoteGitConfig -> RsyncUrl -> Annex (Annex [CommandParam], RsyncUrl)
+rsyncTransport gc url
+	| rsyncUrlIsShell url =
+		(\transport -> return (rsyncShell <$> transport, url)) =<<
+		case fromNull ["ssh"] (remoteAnnexRsyncTransport gc) of
+			"ssh":sshopts -> do
+				let (port, sshopts') = sshReadPort sshopts
+				    userhost = either giveup id $ mkSshHost $ 
+				    	takeWhile (/= ':') url
+				return $ (Param "ssh":) <$> sshOptions ConsumeStdin
+					(userhost, port) gc
+					(map Param $ loginopt ++ sshopts')
+			"rsh":rshopts -> return $ pure $ map Param $ "rsh" :
+				loginopt ++ rshopts
+			rsh -> giveup $ "Unknown Rsync transport: "
+				++ unwords rsh
+	| otherwise = return (pure [], url)
+  where
+	login = case separate (=='@') url of
+		(_h, "") -> Nothing
+		(l, _)  -> Just l
+	loginopt = maybe [] (\l -> ["-l",l]) login
+	fromNull as xs = if null xs then as else xs
+
+rsyncSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+rsyncSetup _ mu _ c gc = do
+	u <- maybe (liftIO genUUID) return mu
+	-- verify configuration is sane
+	let url = maybe (giveup "Specify rsyncurl=") fromProposedAccepted $
+		M.lookup rsyncUrlField c
+	(c', _encsetup) <- encryptionSetup c gc
+
+	-- The rsyncurl is stored in git config, not only in this remote's
+	-- persistent state, so it can vary between hosts.
+	gitConfigSpecialRemote u c' [("rsyncurl", url)]
+	return (c', u)
+
+{- To send a single key is slightly tricky; need to build up a temporary
+ - directory structure to pass to rsync so it can create the hash
+ - directories.
+ -
+ - This would not be necessary if the hash directory structure used locally
+ - was always the same as that used on the rsync remote. So if that's ever
+ - unified, this gets nicer.
+ - (When we have the right hash directory structure, we can just
+ - pass --include=X --include=X/Y --include=X/Y/file --exclude=*)
+ -}
+store :: RsyncOpts -> Key -> FilePath -> MeterUpdate -> Annex ()
+store o k src meterupdate = storeGeneric o meterupdate basedest populatedest
+  where
+	basedest = fromRawFilePath $ Prelude.head (keyPaths k)
+	populatedest dest = liftIO $ if canrename
+		then do
+			R.rename (toRawFilePath src) (toRawFilePath dest)
+			return True
+		else createLinkOrCopy (toRawFilePath src) (toRawFilePath dest)
+	{- If the key being sent is encrypted or chunked, the file
+	 - containing its content is a temp file, and so can be
+	 - renamed into place. Otherwise, the file is the annexed
+	 - object file, and has to be copied or hard linked into place. -}
+	canrename = isEncKey k || isChunkKey k
+
+storeGeneric :: RsyncOpts -> MeterUpdate -> FilePath -> (FilePath -> Annex Bool) -> Annex ()
+storeGeneric o meterupdate basedest populatedest = 
+	unlessM (storeGeneric' o meterupdate basedest populatedest) $
+		giveup "failed to rsync content"
+
+storeGeneric' :: RsyncOpts -> MeterUpdate -> FilePath -> (FilePath -> Annex Bool) -> Annex Bool
+storeGeneric' o meterupdate basedest populatedest = withRsyncScratchDir $ \tmp -> do
+	let dest = tmp </> basedest
+	createAnnexDirectory (parentDir (toRawFilePath dest))
+	ok <- populatedest dest
+	ps <- sendParams
+	if ok
+		then showResumable $ rsyncRemote Upload o (Just meterupdate) $ ps ++
+			Param "--recursive" : partialParams ++
+			-- tmp/ to send contents of tmp dir
+			[ File $ addTrailingPathSeparator tmp
+			, Param $ rsyncUrl o
+			]
+		else return False
+
+retrieve :: RsyncOpts -> RawFilePath -> Key -> MeterUpdate -> Annex ()
+retrieve o f k p = rsyncRetrieveKey o k (fromRawFilePath f) (Just p)
+
+retrieveCheap :: RsyncOpts -> Key -> AssociatedFile -> FilePath -> Annex ()
+retrieveCheap o k _af f = ifM (preseedTmp k f)
+	( rsyncRetrieveKey o k f Nothing
+	, giveup "cannot preseed rsync with existing content"
+	)
+
+remove :: RsyncOpts -> Remover
+remove o k = removeGeneric o includes
+  where
+	includes = concatMap use dirHashes
+	use h = let dir = fromRawFilePath (h def k) in
+		[ fromRawFilePath (parentDir (toRawFilePath dir))
+		, dir
+		-- match content directory and anything in it
+		, dir </> fromRawFilePath (keyFile k) </> "***"
+		]
+
+{- An empty directory is rsynced to make it delete. Everything is excluded,
+ - except for the specified includes. Due to the way rsync traverses
+ - directories, the includes must match both the file to be deleted, and
+ - its parent directories, but not their other contents. -}
+removeGeneric :: RsyncOpts -> [String] -> Annex ()
+removeGeneric o includes = do
+	ps <- sendParams
+	opts <- rsyncOptions o
+	ok <- withRsyncScratchDir $ \tmp -> liftIO $ do
+		{- Send an empty directory to rsync to make it delete. -}
+		rsync $ opts ++ ps ++
+			map (\s -> Param $ "--include=" ++ s) includes ++
+			[ Param "--exclude=*" -- exclude everything else
+			, Param "--quiet", Param "--delete", Param "--recursive"
+			] ++ partialParams ++ 
+			[ Param $ addTrailingPathSeparator tmp
+			, Param $ rsyncUrl o
+			]
+	unless ok $
+		giveup "rsync failed"
+
+checkKey :: RsyncOpts -> CheckPresent
+checkKey o k = checkPresentGeneric o (rsyncUrls o k)
+
+checkPresentGeneric :: RsyncOpts -> [RsyncUrl] -> Annex Bool
+checkPresentGeneric o rsyncurls = do
+	opts <- rsyncOptions o
+	-- note: Does not currently differentiate between rsync failing
+	-- to connect, and the file not being present.
+	untilTrue rsyncurls $ \u -> 
+		liftIO $ catchBoolIO $ withNullHandle $ \nullh ->
+			let p = (proc "rsync" $ toCommand $ opts ++ [Param u])
+				{ std_out = UseHandle nullh
+				, std_err = UseHandle nullh
+				}
+			in withCreateProcess p $ \_ _ _ -> checkSuccessProcess
+
+storeExportM :: RsyncOpts -> FilePath -> Key -> ExportLocation -> MeterUpdate -> Annex ()
+storeExportM o src _k loc meterupdate =
+	storeGeneric o meterupdate basedest populatedest
+  where
+	basedest = fromRawFilePath (fromExportLocation loc)
+	populatedest = liftIO . createLinkOrCopy (toRawFilePath src) . toRawFilePath
+
+retrieveExportM :: RsyncOpts -> Key -> ExportLocation -> FilePath -> MeterUpdate -> Annex Verification
+retrieveExportM o k loc dest p =
+	verifyKeyContentIncrementally AlwaysVerify k $ \iv ->
+		tailVerify iv (toRawFilePath dest) $
+			rsyncRetrieve o [rsyncurl] dest (Just p)
+  where
+	rsyncurl = mkRsyncUrl o (fromRawFilePath (fromExportLocation loc))
+
+checkPresentExportM :: RsyncOpts -> Key -> ExportLocation -> Annex Bool
+checkPresentExportM o _k loc = checkPresentGeneric o [rsyncurl]
+  where
+	rsyncurl = mkRsyncUrl o (fromRawFilePath (fromExportLocation loc))
+
+removeExportM :: RsyncOpts -> Key -> ExportLocation -> Annex ()
+removeExportM o _k loc =
+	removeGeneric o $ map fromRawFilePath $
+		includes $ fromExportLocation loc
+  where
+	includes f = f : case upFrom f of
+		Nothing -> []
+		Just f' -> includes f'
+
+removeExportDirectoryM :: RsyncOpts -> ExportDirectory -> Annex ()
+removeExportDirectoryM o ed = removeGeneric o (allbelow d : includes d)
+  where
+	d = fromRawFilePath $ fromExportDirectory ed
+	allbelow f = f </> "***"
+	includes f = f : case upFrom (toRawFilePath f) of
+		Nothing -> []
+		Just f' -> includes (fromRawFilePath f')
+
+renameExportM :: RsyncOpts -> Key -> ExportLocation -> ExportLocation -> Annex (Maybe ())
+renameExportM _ _ _ _ = return Nothing
+
+{- Rsync params to enable resumes of sending files safely,
+ - ensure that files are only moved into place once complete
+ -}
+partialParams :: [CommandParam]
+partialParams = [Param "--partial", Param "--partial-dir=.rsync-partial"]
+
+{- When sending files from crippled filesystems, the permissions can be all
+ - messed up, and it's better to use the default permissions on the
+ - destination. -}
+sendParams :: Annex [CommandParam]
+sendParams = ifM crippledFileSystem
+	( return [rsyncUseDestinationPermissions]
+	, return []
+	)
+
+{- Runs an action in an empty scratch directory that can be used to build
+ - up trees for rsync. -}
+withRsyncScratchDir :: (FilePath -> Annex a) -> Annex a
+withRsyncScratchDir a = do
+	t <- fromRawFilePath <$> fromRepo gitAnnexTmpObjectDir
+	withTmpDirIn t "rsynctmp" a
+
+rsyncRetrieve :: RsyncOpts -> [RsyncUrl] -> FilePath -> Maybe MeterUpdate -> Annex ()
+rsyncRetrieve o rsyncurls dest meterupdate = 
+	unlessM go $
+		giveup "rsync failed"
+  where
+	go = showResumable $ untilTrue rsyncurls $ \u -> rsyncRemote Download o meterupdate
+		-- use inplace when retrieving to support resuming
+		[ Param "--inplace"
+		, Param u
+		, File dest
+		]
+
+rsyncRetrieveKey :: RsyncOpts -> Key -> FilePath -> Maybe MeterUpdate -> Annex ()
+rsyncRetrieveKey o k dest meterupdate =
+	rsyncRetrieve o (rsyncUrls o k) dest meterupdate
+
+showResumable :: Annex Bool -> Annex Bool
+showResumable a = ifM a
+	( return True
+	, do
+		showLongNote "rsync failed -- run git annex again to resume file transfer"
+		return False
+	)
+
+rsyncRemote :: Direction -> RsyncOpts -> Maybe MeterUpdate -> [CommandParam] -> Annex Bool
+rsyncRemote direction o m params = do
+	opts <- mkopts
+	let ps = opts ++ Param "--progress" : params
+	case m of
+		Nothing -> liftIO $ rsync ps
+		Just meter -> do
+			oh <- mkOutputHandlerQuiet
+			liftIO $ rsyncProgress oh meter ps
+  where
+	mkopts
+		| direction == Download = rsyncDownloadOptions o
+		| otherwise = rsyncUploadOptions o
diff --git a/Remote/Rsync/RsyncUrl.hs b/Remote/Rsync/RsyncUrl.hs
new file mode 100644
index 0000000000..d0e1714557
--- /dev/null
+++ b/Remote/Rsync/RsyncUrl.hs
@@ -0,0 +1,53 @@
+{- Rsync urls.
+ -
+ - Copyright 2014-2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Remote.Rsync.RsyncUrl where
+
+import Types
+import Annex.Locations
+import Utility.Rsync
+import Utility.SafeCommand
+import Utility.ShellEscape
+import Utility.FileSystemEncoding
+import Annex.DirHashes
+#ifdef mingw32_HOST_OS
+import Utility.Split
+#endif
+
+import Data.Default
+import System.FilePath.Posix
+
+type RsyncUrl = String
+
+data RsyncOpts = RsyncOpts
+	{ rsyncUrl :: RsyncUrl
+	, rsyncOptions :: Annex [CommandParam]
+	, rsyncUploadOptions :: Annex [CommandParam]
+	, rsyncDownloadOptions :: Annex [CommandParam]
+	, rsyncShellEscape :: Bool
+}
+
+rsyncEscape :: RsyncOpts -> RsyncUrl -> RsyncUrl
+rsyncEscape o u
+	| rsyncShellEscape o && rsyncUrlIsShell (rsyncUrl o) = shellEscape u
+	| otherwise = u
+
+mkRsyncUrl :: RsyncOpts -> FilePath -> RsyncUrl
+mkRsyncUrl o f = rsyncUrl o </> rsyncEscape o f
+
+rsyncUrls :: RsyncOpts -> Key -> [RsyncUrl]
+rsyncUrls o k = map use dirHashes
+  where
+	use h = rsyncUrl o </> hash h </> rsyncEscape o (f </> f)
+	f = fromRawFilePath (keyFile k)
+#ifndef mingw32_HOST_OS
+	hash h = fromRawFilePath $ h def k
+#else
+	hash h = replace "\\" "/" $ fromRawFilePath $ h def k
+#endif
diff --git a/Remote/S3.hs b/Remote/S3.hs
new file mode 100644
index 0000000000..d2db401fe9
--- /dev/null
+++ b/Remote/S3.hs
@@ -0,0 +1,1383 @@
+{- S3 remotes
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeFamilies #-}
+{-# LANGUAGE TypeOperators #-}
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE BangPatterns #-}
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE CPP #-}
+
+module Remote.S3 (remote, iaHost, configIA, iaItemUrl) where
+
+import qualified Aws as AWS
+import qualified Aws.Core as AWS
+import qualified Aws.S3 as S3
+import qualified Data.Text as T
+import qualified Data.Text.Encoding as T
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString as BS
+import qualified Data.ByteString.Char8 as B8
+import qualified Data.Map as M
+import qualified Data.Set as S
+import qualified System.FilePath.Posix as Posix
+import Data.Char
+import Data.String
+import Network.Socket (HostName)
+import Network.HTTP.Conduit (Manager)
+import Network.HTTP.Client (responseStatus, responseBody, RequestBody(..))
+import Network.HTTP.Types
+import Network.URI
+import Control.Monad.Trans.Resource
+import Control.Monad.Catch
+import Control.Concurrent.STM (atomically)
+import Control.Concurrent.STM.TVar
+import Data.Maybe
+
+import Annex.Common
+import Types.Remote
+import Types.Export
+import qualified Git
+import qualified Annex
+import Config
+import Config.Cost
+import Annex.SpecialRemote.Config
+import Remote.Helper.Special
+import Remote.Helper.Http
+import Remote.Helper.ExportImport
+import Types.Import
+import qualified Remote.Helper.AWS as AWS
+import Creds
+import Annex.UUID
+import Annex.Magic
+import Logs.Web
+import Logs.MetaData
+import Types.MetaData
+import Types.ProposedAccepted
+import Types.NumCopies
+import Utility.Metered
+import Utility.DataUnits
+import Annex.Content
+import qualified Annex.Url as Url
+import Utility.Url (extractFromResourceT)
+import Annex.Url (getUrlOptions, withUrlOptions, UrlOptions(..))
+import Utility.Env
+import Annex.Verify
+
+type BucketName = String
+type BucketObject = String
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "S3"
+	, enumerate = const (findSpecialRemotes "s3")
+	, generate = gen
+	, configParser = const $ pure $ RemoteConfigParser
+		{ remoteConfigFieldParsers = 
+			[ optionalStringParser bucketField
+				(FieldDesc "name of bucket to store content in")
+			, optionalStringParser hostField
+				(FieldDesc "S3 server hostname (default is Amazon S3)")
+			, optionalStringParser datacenterField
+				(FieldDesc "S3 datacenter to use (US, EU, us-west-1, ..)")
+			, optionalStringParser regionField
+				(FieldDesc "S3 region to use")
+			, optionalStringParser partsizeField
+				(FieldDesc "part size for multipart upload (eg 1GiB)")
+			, optionalStringParser storageclassField
+				(FieldDesc "storage class, eg STANDARD or STANDARD_IA or ONEZONE_IA")
+			, optionalStringParser fileprefixField
+				(FieldDesc "prefix to add to filenames in the bucket")
+			, yesNoParser versioningField (Just False)
+				(FieldDesc "enable versioning of bucket content")
+			, yesNoParser publicField (Just False)
+				(FieldDesc "allow public read access to the bucket via ACLs (only supported for old Amazon S3 buckets)")
+			, optionalStringParser publicurlField
+				(FieldDesc "url that can be used by public to download files")
+			, optionalStringParser protocolField
+				(FieldDesc "http or https")
+			, optionalStringParser portField
+				(FieldDesc "port to connect to")
+			, optionalStringParser requeststyleField
+				(FieldDesc "for path-style requests, set to \"path\"")
+			, signatureVersionParser signatureField
+				(FieldDesc "S3 signature version")
+			, optionalStringParser mungekeysField HiddenField
+			, optionalStringParser AWS.s3credsField HiddenField
+			]
+		, remoteConfigRestPassthrough = Just
+			( \f -> isMetaHeader f || isArchiveMetaHeader f
+			,
+				[ ("x-amz-meta-*", FieldDesc "http headers to add when storing on S3")
+				, ("x-archive-meta-*", FieldDesc "http headers to add when storing on Internet Archive")
+			  	]
+			)
+		}
+	, setup = s3Setup
+	, exportSupported = exportIsSupported
+	, importSupported = importIsSupported
+	, thirdPartyPopulated = False
+	}
+
+bucketField :: RemoteConfigField
+bucketField = Accepted "bucket"
+
+hostField :: RemoteConfigField
+hostField = Accepted "host"
+
+datacenterField :: RemoteConfigField
+datacenterField = Accepted "datacenter"
+
+regionField :: RemoteConfigField
+regionField = Accepted "region"
+
+partsizeField :: RemoteConfigField
+partsizeField = Accepted "partsize"
+
+storageclassField :: RemoteConfigField
+storageclassField = Accepted "storageclass"
+
+fileprefixField :: RemoteConfigField
+fileprefixField = Accepted "fileprefix"
+
+versioningField :: RemoteConfigField
+versioningField = Accepted "versioning"
+
+publicField :: RemoteConfigField
+publicField = Accepted "public"
+
+publicurlField :: RemoteConfigField
+publicurlField = Accepted "publicurl"
+
+protocolField :: RemoteConfigField
+protocolField = Accepted "protocol"
+
+requeststyleField :: RemoteConfigField
+requeststyleField = Accepted "requeststyle"
+
+signatureField :: RemoteConfigField
+signatureField = Accepted "signature"
+
+data SignatureVersion 
+	= SignatureVersion Int
+	| Anonymous
+
+signatureVersionParser :: RemoteConfigField -> FieldDesc -> RemoteConfigFieldParser
+signatureVersionParser f fd =
+	genParser go f (Just defver) fd
+		(Just (ValueDesc "v2 or v4"))
+  where
+	go "v2" = Just (SignatureVersion 2)
+	go "v4" = Just (SignatureVersion 4)
+	go "anonymous" = Just Anonymous
+	go _ = Nothing
+
+	defver = SignatureVersion 2
+
+isAnonymous :: ParsedRemoteConfig -> Bool
+isAnonymous c = 
+	case getRemoteConfigValue signatureField c of
+		Just Anonymous -> True
+		_ -> False
+
+portField :: RemoteConfigField
+portField = Accepted "port"
+
+mungekeysField :: RemoteConfigField
+mungekeysField = Accepted "mungekeys"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	cst <- remoteCost gc c expensiveRemoteCost
+	info <- extractS3Info c
+	hdl <- mkS3HandleVar c gc u
+	magic <- liftIO initMagicMime
+	return $ new c cst info hdl magic
+  where
+	new c cst info hdl magic = Just $ specialRemote c
+		(store hdl this info magic)
+		(retrieve hdl this rs c info)
+		(remove hdl this info)
+		(checkKey hdl this rs c info)
+		this
+	  where
+		this = Remote
+			{ uuid = u
+			, cost = cst
+			, name = Git.repoDescribe r
+			, storeKey = storeKeyDummy
+			, retrieveKeyFile = retrieveKeyFileDummy
+			, retrieveKeyFileCheap = Nothing
+			-- HttpManagerRestricted is used here, so this is
+			-- secure.
+			, retrievalSecurityPolicy = RetrievalAllKeysSecure
+			, removeKey = removeKeyDummy
+			, lockContent = lockContentS3 hdl this rs c info
+			, checkPresent = checkPresentDummy
+			, checkPresentCheap = False
+			, exportActions = ExportActions
+				{ storeExport = storeExportS3 hdl this rs info magic
+				, retrieveExport = retrieveExportS3 hdl this info
+				, removeExport = removeExportS3 hdl this rs info
+				, versionedExport = versioning info
+				, checkPresentExport = checkPresentExportS3 hdl this info
+				-- S3 does not have directories.
+				, removeExportDirectory = Nothing
+				, renameExport = Just $ renameExportS3 hdl this rs info
+				}
+			, importActions = ImportActions
+                                { listImportableContents = listImportableContentsS3 hdl this info c
+				, importKey = Nothing
+                                , retrieveExportWithContentIdentifier = retrieveExportWithContentIdentifierS3 hdl this rs info
+                                , storeExportWithContentIdentifier = storeExportWithContentIdentifierS3 hdl this rs info magic
+                                , removeExportWithContentIdentifier = removeExportWithContentIdentifierS3 hdl this rs info
+                                , removeExportDirectoryWhenEmpty = Nothing
+                                , checkPresentExportWithContentIdentifier = checkPresentExportWithContentIdentifierS3 hdl this info
+                                }
+			, whereisKey = Just (getPublicWebUrls rs info c)
+			, remoteFsck = Nothing
+			, repairRepo = Nothing
+			, config = c
+			, getRepo = return r
+			, gitconfig = gc
+			, localpath = Nothing
+			, readonly = False
+			, appendonly = False
+			, untrustworthy = False
+			, availability = pure GloballyAvailable
+			, remotetype = remote
+			, mkUnavailable = gen r u (M.insert hostField (Proposed "!dne!") rc) gc rs
+			, getInfo = includeCredsInfo c (AWS.creds u) (s3Info c info)
+			, claimUrl = Nothing
+			, checkUrl = Nothing
+			, remoteStateHandle = rs
+			}
+
+s3Setup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+s3Setup ss mu mcreds c gc = do
+	u <- maybe (liftIO genUUID) return mu
+	s3Setup' ss u mcreds c gc
+
+s3Setup' :: SetupStage -> UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+s3Setup'  ss u mcreds c gc
+	| maybe False (isIAHost . fromProposedAccepted) (M.lookup hostField c) = archiveorg
+	| otherwise = defaulthost
+  where
+	remotename = fromJust (lookupName c)
+	defbucket = remotename ++ "-" ++ fromUUID u
+	defaults = M.fromList
+		[ (datacenterField, Proposed $ T.unpack $ AWS.defaultRegion AWS.S3)
+		, (storageclassField, Proposed "STANDARD")
+		, (hostField, Proposed AWS.s3DefaultHost)
+		, (portField, Proposed "80")
+		, (bucketField, Proposed defbucket)
+		]
+
+	use fullconfig pc info = do
+		enableBucketVersioning ss info pc gc u
+		gitConfigSpecialRemote u fullconfig [("s3", "true")]
+		return (fullconfig, u)
+
+	defaulthost = do
+		(c', encsetup) <- encryptionSetup (c `M.union` defaults) gc
+		pc <- either giveup return . parseRemoteConfig c'
+			=<< configParser remote c'
+		c'' <- if isAnonymous pc
+			then pure c'
+			else setRemoteCredPair ss encsetup pc gc (AWS.creds u) mcreds
+		pc' <- either giveup return . parseRemoteConfig c''
+			=<< configParser remote c''
+		info <- extractS3Info pc'
+		checkexportimportsafe pc' info
+		case ss of
+			Init -> genBucket pc' gc u
+			_ -> return ()
+		use c'' pc' info
+
+	archiveorg = do
+		showNote "Internet Archive mode"
+		pc <- either giveup return . parseRemoteConfig c
+			=<< configParser remote c
+		c' <- if isAnonymous pc
+			then pure c
+			else setRemoteCredPair ss noEncryptionUsed pc gc (AWS.creds u) mcreds
+		-- Ensure user enters a valid bucket name, since
+		-- this determines the name of the archive.org item.
+		let validbucket = replace " " "-" $ map toLower $
+			maybe (giveup "specify bucket=") fromProposedAccepted
+				(M.lookup bucketField c')
+		let archiveconfig = 
+			-- IA accepts x-amz-* as an alias for x-archive-*
+			M.mapKeys (Proposed . replace "x-archive-" "x-amz-" . fromProposedAccepted) $
+			-- encryption does not make sense here
+			M.insert encryptionField (Proposed "none") $
+			M.insert bucketField (Proposed validbucket) $
+			M.union c' $
+			-- special constraints on key names
+			M.insert mungekeysField (Proposed "ia") defaults
+		pc' <- either giveup return . parseRemoteConfig archiveconfig
+			=<< configParser remote archiveconfig
+		info <- extractS3Info pc'
+		checkexportimportsafe pc' info
+		hdl <- mkS3HandleVar pc' gc u
+		withS3HandleOrFail u hdl $
+			writeUUIDFile pc' u info
+		use archiveconfig pc' info
+	
+	checkexportimportsafe c' info =
+		unlessM (Annex.getRead Annex.force) $
+			checkexportimportsafe' c' info
+	checkexportimportsafe' c' info
+		| versioning info = return ()
+		| otherwise = when (exportTree c' && importTree c') $
+			giveup $ unwords
+				[ "Combining exporttree=yes and importtree=yes"
+				, "with an unversioned S3 bucket is not safe;"
+				, "exporting can overwrite other modifications"
+				, "to files in the bucket."
+				, "Recommend you add versioning=yes."
+				, "(Or use --force if you don't mind possibly losing data.)"
+				]
+
+store :: S3HandleVar -> Remote -> S3Info -> Maybe Magic -> Storer
+store mh r info magic = fileStorer $ \k f p -> withS3HandleOrFail (uuid r) mh $ \h -> do
+	void $ storeHelper info h magic f (T.pack $ bucketObject info k) p
+	-- Store public URL to item in Internet Archive.
+	when (isIA info && not (isChunkKey k)) $
+		setUrlPresent k (iaPublicUrl info (bucketObject info k))
+
+storeHelper :: S3Info -> S3Handle -> Maybe Magic -> FilePath -> S3.Object -> MeterUpdate -> Annex (Maybe S3Etag, Maybe S3VersionID)
+storeHelper info h magic f object p = liftIO $ case partSize info of
+	Just partsz | partsz > 0 -> do
+		fsz <- getFileSize (toRawFilePath f)
+		if fsz > partsz
+			then multipartupload fsz partsz
+			else singlepartupload
+	_ -> singlepartupload
+  where
+	singlepartupload = runResourceT $ do
+		contenttype <- liftIO getcontenttype
+		rbody <- liftIO $ httpBodyStorer f p
+		let req = (putObject info object rbody)
+			{ S3.poContentType = encodeBS <$> contenttype }
+		resp <- sendS3Handle h req
+		vid <- mkS3VersionID object
+			<$> extractFromResourceT (S3.porVersionId resp)
+#if MIN_VERSION_aws(0,22,0)
+		etag <- extractFromResourceT (Just (S3.porETag resp))
+		return (etag, vid)
+#else
+		return (Nothing, vid)
+#endif
+	multipartupload fsz partsz = runResourceT $ do
+		contenttype <- liftIO getcontenttype
+		let startreq = (S3.postInitiateMultipartUpload (bucket info) object)
+				{ S3.imuStorageClass = Just (storageClass info)
+				, S3.imuMetadata = metaHeaders info
+				, S3.imuAutoMakeBucket = isIA info
+				, S3.imuExpires = Nothing -- TODO set some reasonable expiry
+				, S3.imuContentType = fromString <$> contenttype
+				}
+		uploadid <- S3.imurUploadId <$> sendS3Handle h startreq
+
+		-- The actual part size will be a even multiple of the
+		-- 32k chunk size that lazy ByteStrings use.
+		let partsz' = (partsz `div` toInteger defaultChunkSize) * toInteger defaultChunkSize
+
+		-- Send parts of the file, taking care to stream each part
+		-- w/o buffering in memory, since the parts can be large.
+		etags <- bracketIO (openBinaryFile f ReadMode) hClose $ \fh -> do
+			let sendparts meter etags partnum = do
+				pos <- liftIO $ hTell fh
+				if pos >= fsz
+					then return (reverse etags)
+					else do
+						-- Calculate size of part that will
+						-- be read.
+						let sz = min (fsz - pos) partsz'
+						let p' = offsetMeterUpdate p (toBytesProcessed pos)
+						let numchunks = ceiling (fromIntegral sz / fromIntegral defaultChunkSize :: Double)
+						let popper = handlePopper numchunks defaultChunkSize p' fh
+						let req = S3.uploadPart (bucket info) object partnum uploadid $
+							 RequestBodyStream (fromIntegral sz) popper
+						S3.UploadPartResponse { S3.uprETag = etag } <- sendS3Handle h req
+						sendparts (offsetMeterUpdate meter (toBytesProcessed sz)) (etag:etags) (partnum + 1)
+			sendparts p [] 1
+
+		resp <- sendS3Handle h $ S3.postCompleteMultipartUpload
+			(bucket info) object uploadid (zip [1..] etags)
+		etag <- extractFromResourceT (Just (S3.cmurETag resp))
+		vid <- extractFromResourceT (S3.cmurVersionId resp)
+		return (etag, mkS3VersionID object vid)
+	getcontenttype = maybe (pure Nothing) (flip getMagicMimeType f) magic
+
+{- Implemented as a fileRetriever, that uses conduit to stream the chunks
+ - out to the file. Would be better to implement a byteRetriever, but
+ - that is difficult. -}
+retrieve :: S3HandleVar -> Remote -> RemoteStateHandle -> ParsedRemoteConfig -> S3Info -> Retriever
+retrieve hv r rs c info = fileRetriever' $ \f k p iv -> withS3Handle hv $ \case
+	Right h -> 
+		eitherS3VersionID info rs c k (T.pack $ bucketObject info k) >>= \case
+			Left failreason -> do
+				warning (UnquotedString failreason)
+				giveup "cannot download content"
+			Right loc -> retrieveHelper info h loc (fromRawFilePath f) p iv
+	Left S3HandleNeedCreds ->
+		getPublicWebUrls' rs info c k >>= \case
+			Left failreason -> do
+				warning (UnquotedString failreason)
+				giveup "cannot download content"
+			Right us -> unlessM (withUrlOptions $ downloadUrl False k p iv us (fromRawFilePath f)) $
+				giveup "failed to download content"
+	Left S3HandleAnonymousOldAws -> giveupS3HandleProblem S3HandleAnonymousOldAws (uuid r)
+
+retrieveHelper :: S3Info -> S3Handle -> (Either S3.Object S3VersionID) -> FilePath -> MeterUpdate -> Maybe IncrementalVerifier -> Annex ()
+retrieveHelper info h loc f p iv = retrieveHelper' h f p iv $
+	case loc of
+		Left o -> S3.getObject (bucket info) o
+		Right (S3VersionID o vid) -> (S3.getObject (bucket info) o)
+			{ S3.goVersionId = Just vid }
+
+retrieveHelper' :: S3Handle -> FilePath -> MeterUpdate -> Maybe IncrementalVerifier -> S3.GetObject -> Annex ()
+retrieveHelper' h f p iv req = liftIO $ runResourceT $ do
+	S3.GetObjectResponse { S3.gorResponse = rsp } <- sendS3Handle h req
+	Url.sinkResponseFile p iv zeroBytesProcessed f WriteMode rsp
+
+remove :: S3HandleVar -> Remote -> S3Info -> Remover
+remove hv r info k = withS3HandleOrFail (uuid r) hv $ \h -> do
+	S3.DeleteObjectResponse <- liftIO $ runResourceT $ sendS3Handle h $
+		S3.DeleteObject (T.pack $ bucketObject info k) (bucket info)
+	return ()
+
+lockContentS3 :: S3HandleVar -> Remote -> RemoteStateHandle -> ParsedRemoteConfig -> S3Info -> Maybe (Key -> (VerifiedCopy -> Annex a) -> Annex a)
+lockContentS3 hv r rs c info
+	-- When versioning is enabled, content is never removed from the
+	-- remote, so nothing needs to be done to lock the content there,
+	-- beyond a sanity check that the content is in fact present.
+	| versioning info = Just $ \k callback -> do
+		checkVersioning info rs k
+		ifM (checkKey hv r rs c info k)
+			( withVerifiedCopy LockedCopy (uuid r) (return True) callback
+			, giveup $ "content seems to be missing from " ++ name r ++ " despite S3 versioning being enabled"
+			)
+	| otherwise = Nothing
+
+checkKey :: S3HandleVar -> Remote -> RemoteStateHandle -> ParsedRemoteConfig -> S3Info -> CheckPresent
+checkKey hv r rs c info k = withS3Handle hv $ \case
+	Right h -> eitherS3VersionID info rs c k (T.pack $ bucketObject info k) >>= \case
+		Left failreason -> do
+			warning (UnquotedString failreason)
+			giveup "cannot check content"
+		Right loc -> checkKeyHelper info h loc
+	Left S3HandleNeedCreds ->
+		getPublicWebUrls' rs info c k >>= \case
+			Left failreason -> do
+				warning (UnquotedString failreason)
+				giveup "cannot check content"
+			Right us -> do
+				let check u = withUrlOptions $ 
+					Url.checkBoth u (fromKey keySize k)
+				anyM check us
+	Left S3HandleAnonymousOldAws -> giveupS3HandleProblem S3HandleAnonymousOldAws (uuid r)
+
+checkKeyHelper :: S3Info -> S3Handle -> (Either S3.Object S3VersionID) -> Annex Bool
+checkKeyHelper info h loc = checkKeyHelper' info h o limit
+  where
+	(o, limit) = case loc of
+		Left obj ->
+			(obj, id)
+		Right (S3VersionID obj vid) ->
+			(obj, \ho -> ho { S3.hoVersionId = Just vid })
+
+checkKeyHelper' :: S3Info -> S3Handle -> S3.Object -> (S3.HeadObject -> S3.HeadObject) -> Annex Bool
+checkKeyHelper' info h o limit = liftIO $ runResourceT $ do
+	rsp <- sendS3Handle h req
+	extractFromResourceT (isJust $ S3.horMetadata rsp)
+  where
+	req = limit $ S3.headObject (bucket info) o
+
+storeExportS3 :: S3HandleVar -> Remote -> RemoteStateHandle -> S3Info -> Maybe Magic -> FilePath -> Key -> ExportLocation -> MeterUpdate -> Annex ()
+storeExportS3 hv r rs info magic f k loc p = void $ storeExportS3' hv r rs info magic f k loc p
+
+storeExportS3' :: S3HandleVar -> Remote -> RemoteStateHandle -> S3Info -> Maybe Magic -> FilePath -> Key -> ExportLocation -> MeterUpdate -> Annex (Maybe S3Etag, Maybe S3VersionID)
+storeExportS3' hv r rs info magic f k loc p = withS3Handle hv $ \case
+	Right h -> go h
+	Left pr -> giveupS3HandleProblem pr (uuid r)
+  where
+	go h = do
+		let o = T.pack $ bucketExportLocation info loc
+		(metag, mvid) <- storeHelper info h magic f o p
+		setS3VersionID info rs k mvid
+		return (metag, mvid)
+
+retrieveExportS3 :: S3HandleVar -> Remote -> S3Info -> Key -> ExportLocation -> FilePath -> MeterUpdate -> Annex Verification
+retrieveExportS3 hv r info k loc f p = verifyKeyContentIncrementally AlwaysVerify k $ \iv ->
+	withS3Handle hv $ \case
+		Right h -> retrieveHelper info h (Left (T.pack exportloc)) f p iv
+		Left S3HandleNeedCreds -> case getPublicUrlMaker info of
+			Just geturl -> either giveup return =<<
+				Url.withUrlOptions
+					(Url.download' p iv (geturl exportloc) f)
+			Nothing -> giveup $ needS3Creds (uuid r)
+		Left S3HandleAnonymousOldAws -> giveupS3HandleProblem S3HandleAnonymousOldAws (uuid r)
+  where
+	exportloc = bucketExportLocation info loc
+
+removeExportS3 :: S3HandleVar -> Remote -> RemoteStateHandle -> S3Info -> Key -> ExportLocation -> Annex ()
+removeExportS3 hv r rs info k loc = withS3Handle hv $ \case
+	Right h -> do
+		checkVersioning info rs k
+		liftIO $ runResourceT $ do
+			S3.DeleteObjectResponse <- sendS3Handle h $
+				S3.DeleteObject (T.pack $ bucketExportLocation info loc) (bucket info)
+			return ()
+	Left p -> giveupS3HandleProblem p (uuid r)
+
+checkPresentExportS3 :: S3HandleVar -> Remote -> S3Info -> Key -> ExportLocation -> Annex Bool
+checkPresentExportS3 hv r info k loc = withS3Handle hv $ \case
+	Right h -> checkKeyHelper info h (Left (T.pack $ bucketExportLocation info loc))
+	Left S3HandleNeedCreds -> case getPublicUrlMaker info of
+		Just geturl -> withUrlOptions $
+			Url.checkBoth (geturl $ bucketExportLocation info loc) (fromKey keySize k)
+		Nothing -> giveupS3HandleProblem S3HandleNeedCreds (uuid r)
+	Left S3HandleAnonymousOldAws -> giveupS3HandleProblem S3HandleAnonymousOldAws (uuid r)
+
+-- S3 has no move primitive; copy and delete.
+renameExportS3 :: S3HandleVar -> Remote -> RemoteStateHandle -> S3Info -> Key -> ExportLocation -> ExportLocation -> Annex (Maybe ())
+renameExportS3 hv r rs info k src dest = Just <$> go
+  where
+	go = withS3Handle hv $ \case
+		Right h -> do
+			checkVersioning info rs k
+			go' h
+		Left p -> giveupS3HandleProblem p (uuid r)
+	
+	go' h = liftIO $ runResourceT $ do
+		let co = S3.copyObject (bucket info) dstobject
+			(S3.ObjectId (bucket info) srcobject Nothing)
+			S3.CopyMetadata
+		-- ACL is not preserved by copy.
+		void $ sendS3Handle h $ co { S3.coAcl = acl info }
+		void $ sendS3Handle h $ S3.DeleteObject srcobject (bucket info)
+	
+	srcobject = T.pack $ bucketExportLocation info src
+	dstobject = T.pack $ bucketExportLocation info dest
+
+listImportableContentsS3 :: S3HandleVar -> Remote -> S3Info -> ParsedRemoteConfig -> Annex (Maybe (ImportableContentsChunkable Annex (ContentIdentifier, ByteSize)))
+listImportableContentsS3 hv r info c =
+	withS3Handle hv $ \case
+		Right h -> Just <$> go h
+		Left p -> giveupS3HandleProblem p (uuid r)
+  where
+	go h = do
+		ic <- liftIO $ runResourceT $ extractFromResourceT =<< startlist h
+		return (ImportableContentsComplete ic)
+
+	fileprefix = T.pack <$> getRemoteConfigValue fileprefixField c
+
+	startlist h
+		| versioning info = do
+			rsp <- sendS3Handle h $ 
+				S3.getBucketObjectVersions (bucket info)
+			continuelistversioned h [] rsp
+		| otherwise = do
+			rsp <- sendS3Handle h $ 
+				(S3.getBucket (bucket info))
+					{ S3.gbPrefix = fileprefix }
+			continuelistunversioned h [] rsp
+
+	continuelistunversioned h l rsp
+		| S3.gbrIsTruncated rsp = do
+			rsp' <- sendS3Handle h $
+				(S3.getBucket (bucket info))
+					{ S3.gbMarker = S3.gbrNextMarker rsp
+					, S3.gbPrefix = fileprefix
+					}
+			continuelistunversioned h (rsp:l) rsp'
+		| otherwise = return $
+			mkImportableContentsUnversioned info (reverse (rsp:l))
+	
+	continuelistversioned h l rsp
+		| S3.gbovrIsTruncated rsp = do
+			rsp' <- sendS3Handle h $
+				(S3.getBucketObjectVersions (bucket info))
+					{ S3.gbovKeyMarker = S3.gbovrNextKeyMarker rsp
+					, S3.gbovVersionIdMarker = S3.gbovrNextVersionIdMarker rsp
+					, S3.gbovPrefix = fileprefix
+					}
+			continuelistversioned h (rsp:l) rsp'
+		| otherwise = return $
+			mkImportableContentsVersioned info (reverse (rsp:l))
+
+mkImportableContentsUnversioned :: S3Info -> [S3.GetBucketResponse] -> ImportableContents (ContentIdentifier, ByteSize)
+mkImportableContentsUnversioned info l = ImportableContents 
+	{ importableContents = concatMap (mapMaybe extract . S3.gbrContents) l
+	, importableHistory = []
+	}
+  where
+	extract oi = do
+		loc <- bucketImportLocation info $
+			T.unpack $ S3.objectKey oi
+		let sz  = S3.objectSize oi
+		let cid = mkS3UnversionedContentIdentifier $ S3.objectETag oi
+		return (loc, (cid, sz))
+
+mkImportableContentsVersioned :: S3Info -> [S3.GetBucketObjectVersionsResponse] -> ImportableContents (ContentIdentifier, ByteSize)
+mkImportableContentsVersioned info = build . groupfiles
+  where
+	build [] = ImportableContents [] []
+	build l =
+		let (l', v) = latestversion l
+		in ImportableContents
+			{ importableContents = mapMaybe extract v
+			, importableHistory = case build l' of
+				ImportableContents [] [] -> []
+				h -> [h]
+			}
+  	
+	extract ovi@(S3.ObjectVersion {}) = do
+		loc <- bucketImportLocation info $
+			T.unpack $ S3.oviKey ovi
+		let sz  = S3.oviSize ovi
+		let cid = mkS3VersionedContentIdentifier' ovi
+		return (loc, (cid, sz))
+	extract (S3.DeleteMarker {}) = Nothing
+	
+	-- group files so all versions of a file are in a sublist,
+	-- with the newest first. S3 uses such an order, so it's just a
+	-- matter of breaking up the response list into sublists.
+	groupfiles = groupBy (\a b -> S3.oviKey a == S3.oviKey b) 
+		. concatMap S3.gbovrContents
+
+	latestversion [] = ([], [])
+	latestversion ([]:rest) = latestversion rest
+	latestversion l@((first:_old):remainder) =
+		go (S3.oviLastModified first) [first] remainder
+	  where
+		go mtime c [] = (removemostrecent mtime l, reverse c)
+		go mtime c ([]:rest) = go mtime c rest
+		go mtime c ((latest:_old):rest) = 
+			let !mtime' = max mtime (S3.oviLastModified latest)
+			in go mtime' (latest:c) rest
+	
+	removemostrecent _ [] = []
+	removemostrecent mtime ([]:rest) = removemostrecent mtime rest
+	removemostrecent mtime (i@(curr:old):rest)
+		| S3.oviLastModified curr == mtime =
+			old : removemostrecent mtime rest
+		| otherwise =
+			i : removemostrecent mtime rest
+
+retrieveExportWithContentIdentifierS3 :: S3HandleVar -> Remote -> RemoteStateHandle -> S3Info -> ExportLocation -> [ContentIdentifier] -> FilePath -> Either Key (Annex Key) -> MeterUpdate -> Annex (Key, Verification)
+retrieveExportWithContentIdentifierS3 hv r rs info loc (cid:_) dest gk p =
+	case gk of
+		Right _mkkey -> do
+			k <- go Nothing
+			return (k, UnVerified)
+		Left k -> do
+			v <- verifyKeyContentIncrementally DefaultVerify k 
+				(void . go)
+			return (k, v)
+  where
+	go iv = withS3Handle hv $ \case
+		Right h -> do
+			rewritePreconditionException $ retrieveHelper' h dest p iv $
+				limitGetToContentIdentifier cid $
+					S3.getObject (bucket info) o
+			k <- either return id gk
+			case extractContentIdentifier cid o of
+				Right vid -> do
+					vids <- getS3VersionID rs k
+					unless (vid `elem` map Just vids) $
+						setS3VersionID info rs k vid
+				Left _ -> noop
+			return k
+		Left pr -> giveupS3HandleProblem pr (uuid r)
+	o = T.pack $ bucketExportLocation info loc
+retrieveExportWithContentIdentifierS3 _ _ _ _ _ [] _ _ _ = giveup "missing content identifier"
+
+{- Catch exception getObject returns when a precondition is not met,
+ - and replace with a more understandable message for the user. -}
+rewritePreconditionException :: Annex a -> Annex a
+rewritePreconditionException a = catchJust (Url.matchStatusCodeException want) a $ 
+	const $ giveup "requested version of object is not available in S3 bucket"
+  where
+	want st = statusCode st == 412 && 
+		statusMessage st == "Precondition Failed"
+
+-- Does not check if content on S3 is safe to overwrite, because there
+-- is no atomic way to do so. When the bucket is versioned, this is
+-- acceptable because listImportableContentsS3 will find versions
+-- of files that were overwritten by this and no data is lost.
+--
+-- When the bucket is not versioned, data loss can result.
+-- This is why that configuration requires --force to enable.
+storeExportWithContentIdentifierS3 :: S3HandleVar -> Remote -> RemoteStateHandle -> S3Info -> Maybe Magic -> FilePath -> Key -> ExportLocation -> [ContentIdentifier] -> MeterUpdate -> Annex ContentIdentifier
+storeExportWithContentIdentifierS3 hv r rs info magic src k loc _overwritablecids p
+	| versioning info = go
+#if MIN_VERSION_aws(0,22,0)
+	| otherwise = go
+#else
+	| otherwise = giveup "git-annex is built with too old a version of the aws library to support this operation"
+#endif
+  where
+	go = storeExportS3' hv r rs info magic src k loc p >>= \case
+		(_, Just vid) -> return $
+			mkS3VersionedContentIdentifier vid
+		(Just etag, Nothing) -> return $
+			mkS3UnversionedContentIdentifier etag
+		(Nothing, Nothing) -> 
+			giveup "did not get ETag for store to S3 bucket"
+
+-- Does not guarantee that the removed object has the content identifier,
+-- but when the bucket is versioned, the removed object content can still
+-- be recovered (and listImportableContentsS3 will find it).
+-- 
+-- When the bucket is not versioned, data loss can result.
+-- This is why that configuration requires --force to enable.
+removeExportWithContentIdentifierS3 :: S3HandleVar -> Remote -> RemoteStateHandle -> S3Info -> Key -> ExportLocation -> [ContentIdentifier] -> Annex ()
+removeExportWithContentIdentifierS3 hv r rs info k loc _removeablecids =
+	removeExportS3 hv r rs info k loc
+
+checkPresentExportWithContentIdentifierS3 :: S3HandleVar -> Remote -> S3Info -> Key -> ExportLocation -> [ContentIdentifier] -> Annex Bool
+checkPresentExportWithContentIdentifierS3 hv r info _k loc knowncids =
+	withS3HandleOrFail (uuid r) hv $ \h ->
+		flip anyM knowncids $
+			checkKeyHelper' info h o . limitHeadToContentIdentifier
+  where
+	o = T.pack $ bucketExportLocation info loc
+
+{- Generate the bucket if it does not already exist, including creating the
+ - UUID file within the bucket.
+ -
+ - Some ACLs can allow read/write to buckets, but not querying them,
+ - so first check if the UUID file already exists and we can skip creating
+ - it.
+ -}
+genBucket :: ParsedRemoteConfig -> RemoteGitConfig -> UUID -> Annex ()
+genBucket c gc u = do
+	showAction "checking bucket"
+	info <- extractS3Info c
+	hdl <- mkS3HandleVar c gc u
+	withS3HandleOrFail u hdl $ \h ->
+		go info h =<< checkUUIDFile c u info h
+  where
+	go _ _ (Right True) = noop
+	go info h _ = do
+		r <- liftIO $ tryNonAsync $ runResourceT $ do
+			void $ sendS3Handle h (S3.getBucket $ bucket info)
+			return True
+		case r of
+			Right True -> noop
+			_ -> do
+				showAction $ UnquotedString $ "creating bucket in " ++ datacenter
+				void $ liftIO $ runResourceT $ sendS3Handle h $ 
+					(S3.putBucket (bucket info))
+						{ S3.pbCannedAcl = acl info
+						, S3.pbLocationConstraint = locconstraint
+						, S3.pbXStorageClass = storageclass
+						}
+		writeUUIDFile c u info h
+	
+	locconstraint = mkLocationConstraint $ T.pack datacenter
+	datacenter = fromJust $ getRemoteConfigValue datacenterField c
+	-- "NEARLINE" as a storage class when creating a bucket is a
+	-- nonstandard extension of Google Cloud Storage.
+	storageclass = case getStorageClass c of
+		sc@(S3.OtherStorageClass "NEARLINE") -> Just sc
+		_ -> Nothing
+
+{- Writes the UUID to an annex-uuid file within the bucket.
+ -
+ - If the file already exists in the bucket, it must match,
+ - or this fails.
+ -
+ - Note that IA buckets can only created by having a file
+ - stored in them. So this also takes care of that.
+ -
+ - Not done for import/export buckets.
+ -}
+writeUUIDFile :: ParsedRemoteConfig -> UUID -> S3Info -> S3Handle -> Annex ()
+writeUUIDFile c u info h = unless (exportTree c || importTree c) $ do
+	v <- checkUUIDFile c u info h
+	case v of
+		Right True -> noop
+		Right False -> do
+			warning "The bucket already exists, and its annex-uuid file indicates it is used by a different special remote."
+			giveup "Cannot reuse this bucket."
+		_ -> void $ liftIO $ runResourceT $ sendS3Handle h mkobject
+  where
+	file = T.pack $ uuidFile c
+	uuidb = L.fromChunks [T.encodeUtf8 $ T.pack $ fromUUID u]
+
+	mkobject = putObject info file (RequestBodyLBS uuidb)
+
+{- Checks if the UUID file exists in the bucket
+ - and has the specified UUID already.
+ -
+ - Not done for import/export buckets. -}
+checkUUIDFile :: ParsedRemoteConfig -> UUID -> S3Info -> S3Handle -> Annex (Either SomeException Bool)
+checkUUIDFile c u info h 
+	| exportTree c || importTree c = pure (Right False)
+	| otherwise = tryNonAsync $ liftIO $ runResourceT $ do
+		resp <- tryS3 $ sendS3Handle h (S3.getObject (bucket info) file)
+		case resp of
+			Left _ -> return False
+			Right r -> do
+				v <- AWS.loadToMemory r
+				extractFromResourceT (check v)
+  where
+	check (S3.GetObjectMemoryResponse _meta rsp) =
+		responseStatus rsp == ok200 && responseBody rsp == uuidb
+
+	file = T.pack $ uuidFile c
+	uuidb = L.fromChunks [T.encodeUtf8 $ T.pack $ fromUUID u]
+
+uuidFile :: ParsedRemoteConfig -> FilePath
+uuidFile c = getFilePrefix c ++ "annex-uuid"
+
+tryS3 :: ResourceT IO a -> ResourceT IO (Either S3.S3Error a)
+tryS3 a = (Right <$> a) `catch` (pure . Left)
+
+data S3Handle = S3Handle
+	{ hmanager :: Manager
+	, hawscfg :: AWS.Configuration
+	, hs3cfg :: S3.S3Configuration AWS.NormalQuery
+	}
+
+{- Sends a request to S3 and gets back the response. -}
+sendS3Handle
+	:: (AWS.Transaction r a, AWS.ServiceConfiguration r ~ S3.S3Configuration)
+	=> S3Handle
+	-> r
+	-> ResourceT IO a
+sendS3Handle h r = AWS.pureAws (hawscfg h) (hs3cfg h) (hmanager h) r
+
+type S3HandleVar = TVar (Either (Annex (Either S3HandleProblem S3Handle)) (Either S3HandleProblem S3Handle))
+
+data S3HandleProblem
+	= S3HandleNeedCreds
+	| S3HandleAnonymousOldAws
+
+giveupS3HandleProblem :: S3HandleProblem -> UUID -> Annex a
+giveupS3HandleProblem S3HandleNeedCreds u = do
+	warning $ UnquotedString $ needS3Creds u
+	giveup "No S3 credentials configured"
+giveupS3HandleProblem S3HandleAnonymousOldAws _ =
+	giveup "This S3 special remote is configured with signature=anonymous, but git-annex is built with too old a version of the aws library to support that."
+
+{- Prepares a S3Handle for later use. Does not connect to S3 or do anything
+ - else expensive. -}
+mkS3HandleVar :: ParsedRemoteConfig -> RemoteGitConfig -> UUID -> Annex S3HandleVar
+mkS3HandleVar c gc u = liftIO $ newTVarIO $ Left $
+	if isAnonymous c
+		then 
+#if MIN_VERSION_aws(0,23,0)
+			go =<< liftIO AWS.anonymousCredentials
+#else
+			return (Left S3HandleAnonymousOldAws)
+#endif
+		else do
+			mcreds <- getRemoteCredPair c gc (AWS.creds u)
+			case mcreds of
+				Just creds -> go =<< liftIO (genCredentials creds)
+				Nothing -> return (Left S3HandleNeedCreds)
+  where
+	s3cfg = s3Configuration c
+	go awscreds = do
+		let awscfg = AWS.Configuration AWS.Timestamp awscreds debugMapper Nothing
+		ou <- getUrlOptions
+		return $ Right $ S3Handle (httpManager ou) awscfg s3cfg
+
+withS3Handle :: S3HandleVar -> (Either S3HandleProblem S3Handle -> Annex a) -> Annex a
+withS3Handle hv a = liftIO (readTVarIO hv) >>= \case
+	Right hdl -> a hdl
+	Left mkhdl -> do
+		hdl <- mkhdl
+		liftIO $ atomically $ writeTVar hv (Right hdl)
+		a hdl
+
+withS3HandleOrFail :: UUID -> S3HandleVar -> (S3Handle -> Annex a) -> Annex a
+withS3HandleOrFail u hv a = withS3Handle hv $ \case
+	Right hdl -> a hdl
+	Left p -> giveupS3HandleProblem p u
+
+needS3Creds :: UUID -> String
+needS3Creds u = missingCredPairFor "S3" (AWS.creds u)
+
+s3Configuration :: ParsedRemoteConfig -> S3.S3Configuration AWS.NormalQuery
+s3Configuration c = cfg
+	{ S3.s3Port = port
+	, S3.s3RequestStyle = case getRemoteConfigValue requeststyleField c of
+		Just "path" -> S3.PathStyle
+		Just s -> giveup $ "bad S3 requeststyle value: " ++ s
+		Nothing -> S3.s3RequestStyle cfg
+	}
+  where
+	h = fromJust $ getRemoteConfigValue hostField c
+	datacenter = fromJust $ getRemoteConfigValue datacenterField c
+	-- When the default S3 host is configured, connect directly to
+	-- the S3 endpoint for the configured datacenter.
+	-- When another host is configured, it's used as-is.
+	endpoint
+		| h == AWS.s3DefaultHost = AWS.s3HostName $ T.pack datacenter
+		| otherwise = T.encodeUtf8 $ T.pack h
+	port = case getRemoteConfigValue portField c of
+		Just s -> 
+			case reads s of
+				[(p, _)]
+					-- Let protocol setting override
+					-- default port 80.
+					| p == 80 -> case cfgproto of
+						Just AWS.HTTPS -> 443
+						_ -> p
+					| otherwise -> p
+				_ -> giveup $ "bad S3 port value: " ++ s
+		Nothing -> case cfgproto of
+			Just AWS.HTTPS -> 443
+			Just AWS.HTTP -> 80
+			Nothing -> 80
+	cfgproto = case getRemoteConfigValue protocolField c of
+		Just "https" -> Just AWS.HTTPS
+		Just "http" -> Just AWS.HTTP
+		Just s -> giveup $ "bad S3 protocol value: " ++ s
+		Nothing -> Nothing
+	proto = case cfgproto of
+		Just v -> v
+		Nothing
+			| port == 443 -> AWS.HTTPS
+			| otherwise -> AWS.HTTP
+	cfg = case getRemoteConfigValue signatureField c of
+		Just (SignatureVersion 4) -> 
+			(S3.s3v4 proto endpoint False S3.SignWithEffort)
+#if MIN_VERSION_aws(0,24,0)
+				{ S3.s3Region = r }
+#endif
+		_ -> (S3.s3 proto endpoint False)
+#if MIN_VERSION_aws(0,24,0)
+				{ S3.s3Region = r }
+	
+	r = encodeBS <$> getRemoteConfigValue regionField c
+#endif
+
+data S3Info = S3Info
+	{ bucket :: S3.Bucket
+	, storageClass :: S3.StorageClass
+	, bucketObject :: Key -> BucketObject
+	, bucketExportLocation :: ExportLocation -> BucketObject
+	, bucketImportLocation :: BucketObject -> Maybe ImportLocation
+	, metaHeaders :: [(T.Text, T.Text)]
+	, partSize :: Maybe Integer
+	, isIA :: Bool
+	, versioning :: Bool
+	, publicACL :: Bool
+	, publicurl :: Maybe URLString
+	, host :: Maybe String
+	, region :: Maybe String
+	}
+
+extractS3Info :: ParsedRemoteConfig -> Annex S3Info
+extractS3Info c = do
+	b <- maybe
+		(giveup "S3 bucket not configured")
+		(return . T.pack)
+		(getBucketName c)
+	return $ S3Info
+		{ bucket = b
+		, storageClass = getStorageClass c
+		, bucketObject = getBucketObject c
+		, bucketExportLocation = getBucketExportLocation c
+		, bucketImportLocation = getBucketImportLocation c
+		, metaHeaders = getMetaHeaders c
+		, partSize = getPartSize c
+		, isIA = configIA c
+		, versioning = fromMaybe False $
+			getRemoteConfigValue versioningField c
+		, publicACL = fromMaybe False $
+			getRemoteConfigValue publicField c
+		, publicurl = getRemoteConfigValue publicurlField c
+		, host = getRemoteConfigValue hostField c
+		, region = getRemoteConfigValue regionField c
+		}
+
+putObject :: S3Info -> T.Text -> RequestBody -> S3.PutObject
+putObject info file rbody = (S3.putObject (bucket info) file rbody)
+	{ S3.poStorageClass = Just (storageClass info)
+	, S3.poMetadata = metaHeaders info
+	, S3.poAutoMakeBucket = isIA info
+	, S3.poAcl = acl info
+	}
+
+acl :: S3Info -> Maybe S3.CannedAcl
+acl info
+	| publicACL info = Just S3.AclPublicRead
+	| otherwise = Nothing
+
+getBucketName :: ParsedRemoteConfig -> Maybe BucketName
+getBucketName = map toLower <$$> getRemoteConfigValue bucketField
+
+getStorageClass :: ParsedRemoteConfig -> S3.StorageClass
+getStorageClass c = case getRemoteConfigValue storageclassField c of
+	Just s -> S3.OtherStorageClass (T.pack s)
+	_ -> S3.Standard
+
+getPartSize :: ParsedRemoteConfig -> Maybe Integer
+getPartSize c = readSize dataUnits =<< getRemoteConfigValue partsizeField c
+
+getMetaHeaders :: ParsedRemoteConfig -> [(T.Text, T.Text)]
+getMetaHeaders = map munge
+	. filter (isMetaHeader . fst)
+	. M.assocs
+	. getRemoteConfigPassedThrough
+  where
+	metaprefixlen = length metaPrefix
+	munge (k, v) = (T.pack $ drop metaprefixlen (fromProposedAccepted k), T.pack v)
+
+isMetaHeader :: RemoteConfigField -> Bool
+isMetaHeader h = metaPrefix `isPrefixOf` fromProposedAccepted h
+
+isArchiveMetaHeader :: RemoteConfigField -> Bool
+isArchiveMetaHeader h = "x-archive-" `isPrefixOf` fromProposedAccepted h
+
+metaPrefix :: String
+metaPrefix = "x-amz-meta-"
+
+getFilePrefix :: ParsedRemoteConfig -> String
+getFilePrefix = fromMaybe "" . getRemoteConfigValue fileprefixField
+
+getBucketObject :: ParsedRemoteConfig -> Key -> BucketObject
+getBucketObject c = munge . serializeKey
+  where
+	munge s = case getRemoteConfigValue mungekeysField c :: Maybe String of
+		Just "ia" -> iaMunge $ getFilePrefix c ++ s
+		_ -> getFilePrefix c ++ s
+
+getBucketExportLocation :: ParsedRemoteConfig -> ExportLocation -> BucketObject
+getBucketExportLocation c loc =
+	getFilePrefix c ++ fromRawFilePath (fromExportLocation loc)
+
+getBucketImportLocation :: ParsedRemoteConfig -> BucketObject -> Maybe ImportLocation
+getBucketImportLocation c obj
+	-- The uuidFile should not be imported.
+	| obj == uuidfile = Nothing
+	-- Only import files that are under the fileprefix, when
+	-- one is configured.
+	| prefix `isPrefixOf` obj = Just $ mkImportLocation $
+		toRawFilePath $ drop prefixlen obj
+	| otherwise = Nothing
+  where
+	prefix = getFilePrefix c
+	prefixlen = length prefix
+	uuidfile = uuidFile c
+
+{- Internet Archive documentation limits filenames to a subset of ascii.
+ - While other characters seem to work now, this entity encodes everything
+ - else to avoid problems. -}
+iaMunge :: String -> String
+iaMunge = (>>= munge)
+  where
+	munge c
+		| isAsciiUpper c || isAsciiLower c || isNumber c = [c]
+		| c `elem` ("_-.\"" :: String) = [c]
+		| isSpace c = []
+		| otherwise = "&" ++ show (ord c) ++ ";"
+
+configIA :: ParsedRemoteConfig -> Bool
+configIA = maybe False isIAHost . getRemoteConfigValue hostField
+
+{- Hostname to use for archive.org S3. -}
+iaHost :: HostName
+iaHost = "s3.us.archive.org"
+
+isIAHost :: HostName -> Bool
+isIAHost h = ".archive.org" `isSuffixOf` map toLower h
+
+iaItemUrl :: BucketName -> URLString
+iaItemUrl b = "http://archive.org/details/" ++ b
+
+iaPublicUrl :: S3Info -> BucketObject -> URLString
+iaPublicUrl info = genericPublicUrl $
+	"http://archive.org/download/" ++ T.unpack (bucket info) ++ "/" 
+
+awsPublicUrl :: S3Info -> BucketObject -> URLString
+awsPublicUrl info = genericPublicUrl $ 
+	"https://" ++ T.unpack (bucket info) ++ ".s3.amazonaws.com/" 
+
+genericPublicUrl :: URLString -> BucketObject -> URLString
+genericPublicUrl baseurl p = 
+	baseurl Posix.</> escapeURIString skipescape p
+ where
+	-- Don't need to escape '/' because the bucket object
+	-- is not necessarily a single url component. 
+	-- But do want to escape eg '+' and ' '
+	skipescape '/' = True
+	skipescape c = isUnescapedInURIComponent c
+
+genCredentials :: CredPair -> IO AWS.Credentials
+genCredentials (keyid, secret) = do
+	cr <- AWS.makeCredentials (tobs keyid) (tobs secret)
+	tk <- fmap tobs <$> getEnv "AWS_SESSION_TOKEN"
+	return (cr { AWS.iamToken = tk })
+  where
+	tobs = T.encodeUtf8 . T.pack
+
+mkLocationConstraint :: AWS.Region -> S3.LocationConstraint
+mkLocationConstraint "US" = S3.locationUsClassic
+mkLocationConstraint r = r
+
+debugMapper :: AWS.Logger
+debugMapper level t = forward "Remote.S3" (T.unpack t)
+  where
+	forward = case level of
+		AWS.Debug -> debug
+		AWS.Warning -> debug
+		AWS.Error -> debug
+		AWS.Info -> \_ _ -> return ()
+
+s3Info :: ParsedRemoteConfig -> S3Info -> [(String, String)]
+s3Info c info = catMaybes
+	[ Just ("bucket", fromMaybe "unknown" (getBucketName c))
+	, Just ("endpoint", decodeBS (S3.s3Endpoint s3c))
+#if MIN_VERSION_aws(0,24,0)
+	, case S3.s3Region s3c of
+		Nothing -> Nothing
+		Just r -> Just ("region", decodeBS r)
+#endif
+	, Just ("port", show (S3.s3Port s3c))
+	, Just ("protocol", map toLower (show (S3.s3Protocol s3c)))
+	, Just ("storage class", showstorageclass (getStorageClass c))
+	, if configIA c
+		then Just ("internet archive item", iaItemUrl $ fromMaybe "unknown" $ getBucketName c)
+		else Nothing
+	, Just ("partsize", maybe "unlimited" (roughSize storageUnits False) (getPartSize c))
+	, Just ("publicurl", fromMaybe "" (publicurl info))
+	, Just ("public", if publicACL info then "yes" else "no")
+	, Just ("versioning", if versioning info then "yes" else "no")
+	]
+  where
+	s3c = s3Configuration c
+	showstorageclass (S3.OtherStorageClass t) = T.unpack t
+	showstorageclass sc = show sc
+
+getPublicWebUrls :: RemoteStateHandle -> S3Info -> ParsedRemoteConfig -> Key -> Annex [URLString]
+getPublicWebUrls rs info c k = either (const []) id <$> getPublicWebUrls' rs info c k
+
+getPublicWebUrls' :: RemoteStateHandle -> S3Info -> ParsedRemoteConfig -> Key -> Annex (Either String [URLString])
+getPublicWebUrls' rs info c k
+	| exportTree c = if versioning info
+		then case publicurl info of
+			Just url -> getversionid (const $ genericPublicUrl url)
+			Nothing -> case host info of
+				Just h | h == AWS.s3DefaultHost ->
+					getversionid awsPublicUrl
+				_ -> return nopublicurl
+		else return (Left "exporttree used without versioning")
+	| otherwise = case getPublicUrlMaker info of
+		Just geturl -> return (Right [geturl $ bucketObject info k])
+		Nothing -> return nopublicurl
+  where
+	nopublicurl = Left "No publicurl is configured for this remote"
+	getversionid url = getS3VersionIDPublicUrls url info rs k >>= \case
+		[] -> return (Left "Remote is configured to use versioning, but no S3 version ID is recorded for this key")
+		l -> return (Right l)
+
+getPublicUrlMaker :: S3Info -> Maybe (BucketObject -> URLString)
+getPublicUrlMaker info = case publicurl info of
+	Just url -> Just (genericPublicUrl url)
+	Nothing -> case host info of
+		Just h
+			| h == AWS.s3DefaultHost ->
+				Just (awsPublicUrl info)
+			| isIAHost h ->
+				Just (iaPublicUrl info)
+		_ -> Nothing
+
+-- S3 uses a unique version id for each object stored on it.
+--
+-- The Object is included in this because retrieving a particular
+-- version id involves a request for an object, so this keeps track of what
+-- the object is.
+data S3VersionID = S3VersionID S3.Object T.Text
+	deriving (Show, Eq)
+
+-- smart constructor
+mkS3VersionID :: S3.Object -> Maybe T.Text -> Maybe S3VersionID
+mkS3VersionID o (Just t)
+	| T.null t = Nothing
+	-- AWS documentation says a version ID is at most 1024 bytes long.
+	-- Since they are stored in the git-annex branch, prevent them from
+	-- being very much larger than that.
+	| T.length t < 2048 = Just (S3VersionID o t)
+	| otherwise = Nothing
+mkS3VersionID _ Nothing = Nothing
+
+-- Format for storage in per-remote metadata.
+--
+-- A S3 version ID is "url ready" so does not contain '#' and so we'll use
+-- that to separate it from the object id. (Could use a space, but spaces
+-- in metadata values lead to an inefficient encoding.)
+formatS3VersionID :: S3VersionID -> BS.ByteString
+formatS3VersionID (S3VersionID o v) = T.encodeUtf8 v <> "#" <> T.encodeUtf8 o
+
+-- Parse from value stored in per-remote metadata.
+parseS3VersionID :: BS.ByteString -> Maybe S3VersionID
+parseS3VersionID b = do
+	let (v, rest) = B8.break (== '#') b
+	o <- eitherToMaybe $ T.decodeUtf8' $ BS.drop 1 rest
+	mkS3VersionID o (eitherToMaybe $ T.decodeUtf8' v)
+
+-- For a versioned bucket, the S3VersionID is used as the
+-- ContentIdentifier.
+mkS3VersionedContentIdentifier :: S3VersionID -> ContentIdentifier
+mkS3VersionedContentIdentifier (S3VersionID _ v) = 
+	ContentIdentifier $ T.encodeUtf8 v
+
+mkS3VersionedContentIdentifier' :: S3.ObjectVersionInfo -> ContentIdentifier
+mkS3VersionedContentIdentifier' =
+	ContentIdentifier . T.encodeUtf8 . S3.oviVersionId
+
+-- S3 returns etags surrounded by double quotes, and the quotes may
+-- be included here.
+type S3Etag = T.Text
+
+-- For an unversioned bucket, the S3Etag is instead used as the
+-- ContentIdentifier. Prefixed by '#' since that cannot appear in a S3
+-- version id.
+mkS3UnversionedContentIdentifier :: S3Etag -> ContentIdentifier
+mkS3UnversionedContentIdentifier t =
+	ContentIdentifier $ T.encodeUtf8 $ "#" <> T.filter (/= '"') t
+
+-- Makes a GetObject request be guaranteed to get the object version
+-- matching the ContentIdentifier, or fail.
+limitGetToContentIdentifier :: ContentIdentifier -> S3.GetObject -> S3.GetObject
+limitGetToContentIdentifier cid req =
+	limitToContentIdentifier cid
+		(\etag -> req { S3.goIfMatch = etag })
+		(\versionid -> req { S3.goVersionId = versionid })
+
+limitHeadToContentIdentifier :: ContentIdentifier -> S3.HeadObject -> S3.HeadObject
+limitHeadToContentIdentifier cid req =
+	limitToContentIdentifier cid
+		(\etag -> req { S3.hoIfMatch = etag })
+		(\versionid -> req { S3.hoVersionId = versionid })
+
+limitToContentIdentifier :: ContentIdentifier -> (Maybe S3Etag -> a) -> (Maybe T.Text -> a) -> a
+limitToContentIdentifier (ContentIdentifier v) limitetag limitversionid =
+	let t = either mempty id (T.decodeUtf8' v)
+	in case T.take 1 t of
+		"#" -> 
+			let etag = T.drop 1 t
+			in limitetag (Just etag)
+		_ -> limitversionid (Just t)
+
+-- A ContentIdentifier contains either a etag or a S3 version id.
+extractContentIdentifier :: ContentIdentifier -> S3.Object -> Either S3Etag (Maybe S3VersionID)
+extractContentIdentifier (ContentIdentifier v) o =
+	let t = either mempty id (T.decodeUtf8' v)
+	in case T.take 1 t of
+		"#" -> Left (T.drop 1 t)
+		_ -> Right (mkS3VersionID o (Just t))
+
+setS3VersionID :: S3Info -> RemoteStateHandle -> Key -> Maybe S3VersionID -> Annex ()
+setS3VersionID info rs k vid
+	| versioning info = maybe noop (setS3VersionID' rs k) vid
+	| otherwise = noop
+
+setS3VersionID' :: RemoteStateHandle -> Key -> S3VersionID -> Annex ()
+setS3VersionID' rs k vid = addRemoteMetaData k rs $
+	updateMetaData s3VersionField v emptyMetaData
+  where
+	v = mkMetaValue (CurrentlySet True) (formatS3VersionID vid)
+
+getS3VersionID :: RemoteStateHandle -> Key -> Annex [S3VersionID]
+getS3VersionID rs k = do
+	(RemoteMetaData _ m) <- getCurrentRemoteMetaData rs k
+	return $ mapMaybe parseS3VersionID $ map unwrap $ S.toList $
+		metaDataValues s3VersionField m
+  where
+	unwrap (MetaValue _ v) = v
+
+s3VersionField :: MetaField
+s3VersionField = mkMetaFieldUnchecked "V"
+
+eitherS3VersionID :: S3Info -> RemoteStateHandle -> ParsedRemoteConfig -> Key -> S3.Object -> Annex (Either String (Either S3.Object S3VersionID))
+eitherS3VersionID info rs c k fallback
+	| versioning info = getS3VersionID rs k >>= return . \case
+		[] -> if exportTree c
+			then Left "Remote is configured to use versioning, but no S3 version ID is recorded for this key"
+			else Right (Left fallback)
+		-- It's possible for a key to be stored multiple timees in
+		-- a bucket with different version IDs; only use one of them.
+		(v:_) -> Right (Right v)
+	| otherwise = return (Right (Left fallback))
+
+s3VersionIDPublicUrl :: (S3Info -> BucketObject -> URLString) -> S3Info -> S3VersionID -> URLString
+s3VersionIDPublicUrl mk info (S3VersionID obj vid) = concat
+	[ mk info (T.unpack obj)
+	, "?versionId="
+	, T.unpack vid -- version ID is "url ready" so no escaping needed
+	]
+
+getS3VersionIDPublicUrls :: (S3Info -> BucketObject -> URLString) -> S3Info -> RemoteStateHandle -> Key -> Annex [URLString]
+getS3VersionIDPublicUrls mk info rs k =
+	map (s3VersionIDPublicUrl mk info) <$> getS3VersionID rs k
+
+-- Enable versioning on the bucket can only be done at init time;
+-- setting versioning in a bucket that git-annex has already exported
+-- files to risks losing the content of those un-versioned files.
+enableBucketVersioning :: SetupStage -> S3Info -> ParsedRemoteConfig -> RemoteGitConfig -> UUID -> Annex ()
+#if MIN_VERSION_aws(0,21,1)
+enableBucketVersioning ss info c gc u = do
+#else
+enableBucketVersioning ss info _ _ _ = do
+#endif
+	case ss of
+		Init -> when (versioning info) $
+			enableversioning (bucket info)
+		Enable oldc -> checkunchanged oldc
+		AutoEnable oldc -> checkunchanged oldc
+  where
+	enableversioning b = do
+#if MIN_VERSION_aws(0,21,1)
+		showAction "enabling bucket versioning"
+		hdl <- mkS3HandleVar c gc u
+		withS3HandleOrFail u hdl $ \h ->
+			void $ liftIO $ runResourceT $ sendS3Handle h $
+				S3.putBucketVersioning b S3.VersioningEnabled
+#else
+		showLongNote $ unlines
+			[ "This version of git-annex cannot auto-enable S3 bucket versioning."
+			, "You need to manually enable versioning in the S3 console"
+			, "for the bucket \"" ++ T.unpack b ++ "\""
+			, "https://docs.aws.amazon.com/AmazonS3/latest/user-guide/enable-versioning.html"
+			, "It's important you enable versioning before storing anything in the bucket!"
+			]
+#endif
+
+	checkunchanged oldc = do
+		oldpc <- parsedRemoteConfig remote oldc
+		oldinfo <- extractS3Info oldpc
+		when (versioning info /= versioning oldinfo) $
+			giveup "Cannot change versioning= of existing S3 remote."
+
+-- If the remote has versioning enabled, but the version ID is for some
+-- reason not being recorded, it's not safe to perform an action that
+-- will remove the unversioned file. The file may be the only copy of an
+-- annex object.
+--
+-- This code could be removed eventually, since enableBucketVersioning
+-- will avoid this situation. Before that was added, some remotes
+-- were created without versioning, some unversioned files exported to
+-- them, and then versioning enabled, and this is to avoid data loss in
+-- those cases.
+checkVersioning :: S3Info -> RemoteStateHandle -> Key -> Annex ()
+checkVersioning info rs k
+	| versioning info = getS3VersionID rs k >>= \case
+		[] -> giveup "Remote is configured to use versioning, but no S3 version ID is recorded for this key, so it cannot safely be modified."
+		_ -> return ()
+	| otherwise = return ()
diff --git a/Remote/Tahoe.hs b/Remote/Tahoe.hs
new file mode 100644
index 0000000000..6b9138b981
--- /dev/null
+++ b/Remote/Tahoe.hs
@@ -0,0 +1,310 @@
+{- Tahoe-LAFS special remotes.
+ -
+ - Tahoe capabilities for accessing objects stored in the remote
+ - are preserved in the remote state log.
+ -
+ - In order to allow multiple clones of a repository to access the same
+ - tahoe repository, git-annex needs to store the introducer furl,
+ - and the shared-convergence-secret. These are stored in the remote
+ - configuration, when embedcreds is enabled.
+ -
+ - Using those creds, git-annex sets up a tahoe configuration directory in
+ - ~/.tahoe-git-annex/UUID/
+ -
+ - Tahoe has its own encryption, so git-annex's encryption is not used.
+ -
+ - Copyright 2014-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Remote.Tahoe (remote) where
+
+import qualified Data.Map as M
+import Utility.Aeson
+import Data.ByteString.Lazy.UTF8 (fromString)
+import Control.Concurrent.STM
+
+import Annex.Common
+import Types.Remote
+import Types.Creds
+import Types.ProposedAccepted
+import Types.NumCopies
+import qualified Git
+import Config
+import Config.Cost
+import Annex.SpecialRemote.Config
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import Annex.UUID
+import Annex.Content
+import Logs.RemoteState
+import Utility.UserInfo
+import Utility.Metered
+import Utility.Env
+import Utility.ThreadScheduler
+
+{- The TMVar is left empty until tahoe has been verified to be running. -}
+data TahoeHandle = TahoeHandle TahoeConfigDir (TMVar ())
+
+type TahoeConfigDir = FilePath
+type SharedConvergenceSecret = String
+type IntroducerFurl = String
+type Capability = String
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "tahoe"
+	, enumerate = const (findSpecialRemotes "tahoe")
+	, generate = gen
+	, configParser = mkRemoteConfigParser
+		[ optionalStringParser scsField
+			(FieldDesc "optional, normally a unique one is generated")
+		, optionalStringParser furlField HiddenField
+		]
+	, setup = tahoeSetup
+	, exportSupported = exportUnsupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+scsField :: RemoteConfigField
+scsField = Accepted "shared-convergence-secret"
+
+furlField :: RemoteConfigField
+furlField = Accepted "introducer-furl"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	cst <- remoteCost gc c expensiveRemoteCost
+	hdl <- liftIO $ TahoeHandle
+		<$> maybe (defaultTahoeConfigDir u) return (remoteAnnexTahoe gc)
+		<*> newEmptyTMVarIO
+	return $ Just $ Remote
+		{ uuid = u
+		, cost = cst
+		, name = Git.repoDescribe r
+		, storeKey = store rs hdl
+		, retrieveKeyFile = retrieve rs hdl
+		, retrieveKeyFileCheap = Nothing
+		-- Tahoe cryptographically verifies content.
+		, retrievalSecurityPolicy = RetrievalAllKeysSecure
+		, removeKey = remove
+		, lockContent = Just $ lockKey u rs hdl
+		, checkPresent = checkKey rs hdl
+		, checkPresentCheap = False
+		, exportActions = exportUnsupported
+		, importActions = importUnsupported
+		, whereisKey = Just (getWhereisKey rs)
+		, remoteFsck = Nothing
+		, repairRepo = Nothing
+		, config = c
+		, getRepo = return r
+		, gitconfig = gc
+		, localpath = Nothing
+		, readonly = False
+		, appendonly = False
+		, untrustworthy = False
+		, availability = pure GloballyAvailable
+		, remotetype = remote
+		, mkUnavailable = return Nothing
+		, getInfo = return []
+		, claimUrl = Nothing
+		, checkUrl = Nothing
+		, remoteStateHandle = rs
+		}
+
+tahoeSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+tahoeSetup _ mu _ c _ = do
+	furl <- maybe (fromMaybe missingfurl $ M.lookup furlField c) Proposed
+		<$> liftIO (getEnv "TAHOE_FURL")
+	u <- maybe (liftIO genUUID) return mu
+	configdir <- liftIO $ defaultTahoeConfigDir u
+	scs <- liftIO $ tahoeConfigure configdir
+		(fromProposedAccepted furl)
+		(fromProposedAccepted <$> (M.lookup scsField c))
+	pc <- either giveup return . parseRemoteConfig c =<< configParser remote c
+	let c' = if embedCreds pc
+		then flip M.union c $ M.fromList
+			[ (furlField, furl)
+			, (scsField, Proposed scs)
+			]
+		else c
+	gitConfigSpecialRemote u c' [("tahoe", configdir)]
+	return (c', u)
+  where
+	missingfurl = giveup "Set TAHOE_FURL to the introducer furl to use."
+
+store :: RemoteStateHandle -> TahoeHandle -> Key -> AssociatedFile -> MeterUpdate -> Annex ()
+store rs hdl k _f _p = sendAnnex k noop $ \src _sz ->
+	parsePut <$> liftIO (readTahoe hdl "put" [File src]) >>= maybe
+		(giveup "tahoe failed to store content")
+		(\cap -> storeCapability rs k cap)
+
+retrieve :: RemoteStateHandle -> TahoeHandle -> Key -> AssociatedFile -> FilePath -> MeterUpdate -> VerifyConfig -> Annex Verification
+retrieve rs hdl k _f d _p _ = do
+	go =<< getCapability rs k
+	-- Tahoe verifies the content it retrieves using cryptographically
+	-- secure methods.
+	return Verified
+  where
+	go Nothing = giveup "tahoe capability is not known"
+	go (Just cap) = unlessM (liftIO $ requestTahoe hdl "get" [Param cap, File d]) $
+		giveup "tahoe failed to reteieve content"
+
+remove :: Key -> Annex ()
+remove _k = giveup "content cannot be removed from tahoe remote"
+
+-- Since content cannot be removed from tahoe (by git-annex),
+-- nothing needs to be done to lock content there, except for checking that
+-- it is actually present.
+lockKey :: UUID -> RemoteStateHandle -> TahoeHandle -> Key -> (VerifiedCopy -> Annex a) -> Annex a
+lockKey u rs hrl k callback = 
+	ifM (checkKey rs hrl k)
+		( withVerifiedCopy LockedCopy u (return True) callback
+		, giveup $ "content seems to be missing from tahoe remote"
+		)
+
+checkKey :: RemoteStateHandle -> TahoeHandle -> Key -> Annex Bool
+checkKey rs hdl k = go =<< getCapability rs k
+  where
+	go Nothing = return False
+	go (Just cap) = liftIO $ do
+		v <- parseCheck <$> readTahoe hdl "check"
+			[ Param "--raw"
+			, Param cap
+			]
+		either giveup return v
+
+defaultTahoeConfigDir :: UUID -> IO TahoeConfigDir
+defaultTahoeConfigDir u = do
+	h <- myHomeDir 
+	return $ h </> ".tahoe-git-annex" </> fromUUID u
+
+tahoeConfigure :: TahoeConfigDir -> IntroducerFurl -> Maybe SharedConvergenceSecret -> IO SharedConvergenceSecret
+tahoeConfigure configdir furl mscs = do
+	unlessM (createClient configdir furl) $
+		giveup "tahoe create-client failed"
+	maybe noop (writeSharedConvergenceSecret configdir) mscs
+	startTahoeDaemon configdir
+	getSharedConvergenceSecret configdir
+
+createClient :: TahoeConfigDir -> IntroducerFurl -> IO Bool
+createClient configdir furl = do
+	createDirectoryIfMissing True $
+		fromRawFilePath $ parentDir $ toRawFilePath configdir
+	boolTahoe configdir "create-client"
+		[ Param "--nickname", Param "git-annex"
+		, Param "--introducer", Param furl
+		]
+
+writeSharedConvergenceSecret :: TahoeConfigDir -> SharedConvergenceSecret -> IO ()
+writeSharedConvergenceSecret configdir scs = 
+	writeFile (convergenceFile configdir) (unlines [scs])
+
+{- The tahoe daemon writes the convergenceFile shortly after it starts
+ - (it does not need to connect to the network). So, try repeatedly to read
+ - the file, for up to 1 minute. To avoid reading a partially written
+ - file, look for the newline after the value. -}
+getSharedConvergenceSecret :: TahoeConfigDir -> IO SharedConvergenceSecret
+getSharedConvergenceSecret configdir = go (60 :: Int)
+  where
+	f = convergenceFile configdir
+	go n
+		| n == 0 = giveup $ "tahoe did not write " ++ f ++ " after 1 minute. Perhaps the daemon failed to start?"
+		| otherwise = do
+			v <- catchMaybeIO (readFile f)
+			case v of
+				Just s | "\n" `isSuffixOf` s || "\r" `isSuffixOf` s ->
+					return $ takeWhile (`notElem` ("\n\r" :: String)) s
+				_ -> do
+					threadDelaySeconds (Seconds 1)
+					go (n - 1)
+
+convergenceFile :: TahoeConfigDir -> FilePath
+convergenceFile configdir = configdir </> "private" </> "convergence"
+
+startTahoeDaemon :: TahoeConfigDir -> IO ()
+startTahoeDaemon configdir = void $ boolTahoe configdir "start" []
+
+{- Ensures that tahoe has been started, before running an action
+ - that uses it. -}
+withTahoeConfigDir :: TahoeHandle -> (TahoeConfigDir -> IO a) -> IO a
+withTahoeConfigDir (TahoeHandle configdir v) a = go =<< atomically needsstart
+  where
+	go True = do
+		startTahoeDaemon configdir
+		a configdir
+	go False = a configdir
+	needsstart = ifM (isEmptyTMVar v)
+		( do
+			putTMVar v ()
+			return True
+		, return False
+		)
+
+boolTahoe :: TahoeConfigDir -> String -> [CommandParam] -> IO Bool
+boolTahoe configdir command params = boolSystem "tahoe" $
+	tahoeParams configdir command params
+
+{- Runs a tahoe command that requests the daemon do something. -}
+requestTahoe :: TahoeHandle -> String -> [CommandParam] -> IO Bool
+requestTahoe hdl command params = withTahoeConfigDir hdl $ \configdir ->
+	boolTahoe configdir command params	
+
+{- Runs a tahoe command that requests the daemon output something. -}
+readTahoe :: TahoeHandle -> String -> [CommandParam] -> IO String
+readTahoe hdl command params = withTahoeConfigDir hdl $ \configdir ->
+	catchDefaultIO "" $
+		readProcess "tahoe" $ toCommand $
+			tahoeParams configdir command params
+
+tahoeParams :: TahoeConfigDir -> String -> [CommandParam] -> [CommandParam]
+tahoeParams configdir command params = 
+	Param "-d" : File configdir : Param command : params
+
+storeCapability :: RemoteStateHandle -> Key -> Capability -> Annex ()
+storeCapability rs k cap = setRemoteState rs k cap
+
+getCapability :: RemoteStateHandle -> Key -> Annex (Maybe Capability)
+getCapability rs k = getRemoteState rs k
+
+getWhereisKey :: RemoteStateHandle -> Key -> Annex [String]
+getWhereisKey rs k = disp <$> getCapability rs k
+  where
+	disp Nothing = []
+	disp (Just c) = [c]
+
+{- tahoe put outputs a single line, containing the capability. -}
+parsePut :: String -> Maybe Capability
+parsePut s = case lines s of
+	[cap] | "URI" `isPrefixOf` cap -> Just cap
+	_ -> Nothing
+
+{- tahoe check --raw outputs a json document.
+ - Its contents will vary (for LIT capabilities, it lacks most info),
+ - but should always contain a results object with a healthy value
+ - that's true or false.
+ -}
+parseCheck :: String -> Either String Bool
+parseCheck s = maybe parseerror (Right . healthy . results) (decode $ fromString s)
+  where
+	parseerror
+		| null s = Left "tahoe check failed to run"
+		| otherwise = Left "unable to parse tahoe check output"
+
+data CheckRet = CheckRet { results :: Results }
+data Results = Results { healthy :: Bool }
+
+instance FromJSON CheckRet where
+	parseJSON (Object v) = CheckRet
+		<$> v .: "results"
+	parseJSON _ = mzero
+
+instance FromJSON Results where
+	parseJSON (Object v) = Results
+		<$> v .: "healthy"
+	parseJSON _ = mzero
diff --git a/Remote/Web.hs b/Remote/Web.hs
new file mode 100644
index 0000000000..f953b8d929
--- /dev/null
+++ b/Remote/Web.hs
@@ -0,0 +1,273 @@
+{- Web remote.
+ -
+ - Copyright 2011-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Remote.Web (remote, getWebUrls) where
+
+import Annex.Common
+import Types.Remote
+import Types.ProposedAccepted
+import Types.Creds
+import Types.Key
+import Remote.Helper.Special
+import Remote.Helper.ExportImport
+import qualified Git
+import qualified Git.Construct
+import Annex.Content
+import Annex.Verify
+import Config.Cost
+import Config
+import Logs.Web
+import Annex.UUID
+import Utility.Metered
+import Utility.Glob
+import qualified Annex.Url as Url
+import Annex.YoutubeDl
+import Annex.SpecialRemote.Config
+import Logs.Remote
+import Logs.EquivilantKeys
+import Backend
+import Backend.VURL.Utilities (generateEquivilantKey)
+
+import qualified Data.Map as M
+
+remote :: RemoteType
+remote = RemoteType
+	{ typename = "web"
+	, enumerate = list
+	, generate = gen
+	, configParser = mkRemoteConfigParser
+		[ optionalStringParser urlincludeField
+			(FieldDesc "only use urls matching this glob")
+		, optionalStringParser urlexcludeField
+			(FieldDesc "don't use urls that match this glob")
+		]
+	, setup = setupInstance
+	, exportSupported = exportUnsupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+-- The web remote always exists.
+-- (If the web should cease to exist, remove this module and redistribute
+-- a new release to the survivors by carrier pigeon.)
+--
+-- There may also be other instances of the web remote, which can be
+-- limited to accessing particular urls, and have different costs.
+list :: Bool -> Annex [Git.Repo]
+list _autoinit = do
+	r <- liftIO $ Git.Construct.remoteNamed "web" (pure Git.Construct.fromUnknown)
+	others <- findSpecialRemotes "web"
+	-- List the main one last, this makes its name be used instead
+	-- of the other names when git-annex is referring to content on the
+	-- web.
+	return (others++[r])
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	cst <- remoteCost gc c expensiveRemoteCost
+ 	urlincludeexclude <- mkUrlIncludeExclude c
+	return $ Just Remote
+		{ uuid = if u == NoUUID then webUUID else u
+		, cost = cst
+		, name = Git.repoDescribe r
+		, storeKey = uploadKey
+		, retrieveKeyFile = downloadKey urlincludeexclude
+		, retrieveKeyFileCheap = Nothing
+		-- HttpManagerRestricted is used here, so this is
+		-- secure.
+		, retrievalSecurityPolicy = RetrievalAllKeysSecure
+		, removeKey = dropKey urlincludeexclude
+		, lockContent = Nothing
+		, checkPresent = checkKey urlincludeexclude
+		, checkPresentCheap = False
+		, exportActions = exportUnsupported
+		, importActions = importUnsupported
+		, whereisKey = Nothing
+		, remoteFsck = Nothing
+		, repairRepo = Nothing
+		, config = c
+		, gitconfig = gc
+		, localpath = Nothing
+		, getRepo = return r
+		, readonly = True
+		, appendonly = False
+		, untrustworthy = False
+		, availability = pure GloballyAvailable
+		, remotetype = remote
+		, mkUnavailable = return Nothing
+		, getInfo = return []
+		-- claimingUrl makes the web special remote claim
+		-- urls that are not claimed by other remotes,
+		-- so no need to claim anything here.
+		, claimUrl = Nothing
+		, checkUrl = Nothing
+		, remoteStateHandle = rs
+		}
+
+setupInstance :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+setupInstance _ mu _ c _ = do
+	u <- maybe (liftIO genUUID) return mu
+	gitConfigSpecialRemote u c [("web", "true")]
+	return (c, u)
+
+downloadKey :: UrlIncludeExclude -> Key -> AssociatedFile -> FilePath -> MeterUpdate -> VerifyConfig -> Annex Verification
+downloadKey urlincludeexclude key _af dest p vc = 
+	go =<< getWebUrls' urlincludeexclude key
+  where
+	go [] = giveup "no known url"
+	go urls = dl (partition (not . isyoutube) (map getDownloader urls)) >>= \case
+		Just v -> return v
+		Nothing -> giveup $ unwords
+			[ "downloading from all"
+			, show (length urls)
+			, "known url(s) failed"
+			]
+	
+	isyoutube (_, YoutubeDownloader) = True
+	isyoutube _ = False
+
+	dl ([], ytus) = flip getM (map fst ytus) $ \u ->
+		ifM (youtubeDlTo key u dest p)
+			( postdl UnVerified
+			, return Nothing
+			)
+	dl (us, ytus) = do
+		iv <- startVerifyKeyContentIncrementally vc key
+		ifM (Url.withUrlOptions $ downloadUrl True key p iv (map fst us) dest)
+			( finishVerifyKeyContentIncrementally iv >>= \case
+				(True, v) -> postdl v
+				(False, _) -> dl ([], ytus)
+			, dl ([], ytus)
+			)
+
+	postdl v@Verified = return (Just v)
+	postdl v
+		-- For a VURL key that was not verified on download, 
+		-- need to generate a hashed key for the content downloaded
+		-- from the web, and record it for later use verifying this
+		-- content.
+		--
+		-- But when the VURL key has a known size, and already has a
+		-- recorded hashed key, don't record a new key, since the
+		-- content on the web is expected to be stable for such a key.
+		| fromKey keyVariety key == VURLKey =
+			case fromKey keySize key of
+				Nothing -> 
+					getEquivilantKeys key
+						>>= recordvurlkey
+				Just _ -> do
+					eks <- getEquivilantKeys key
+					if null eks
+						then recordvurlkey eks
+						else return (Just v)
+		| otherwise = return (Just v)
+	
+	recordvurlkey eks = do
+		-- Make sure to pick a backend that is cryptographically
+		-- secure.
+		db <- defaultBackend
+		let b = if isCryptographicallySecure db
+			then db
+			else defaultHashBackend
+		generateEquivilantKey b (toRawFilePath dest) >>= \case
+			Nothing -> return Nothing
+			Just ek -> do
+				unless (ek `elem` eks) $
+					setEquivilantKey key ek
+				return (Just Verified)
+
+uploadKey :: Key -> AssociatedFile -> MeterUpdate -> Annex ()
+uploadKey _ _ _ = giveup "upload to web not supported"
+
+dropKey :: UrlIncludeExclude -> Key -> Annex ()
+dropKey urlincludeexclude k = mapM_ (setUrlMissing k) =<< getWebUrls' urlincludeexclude k
+
+checkKey :: UrlIncludeExclude -> Key -> Annex Bool
+checkKey urlincludeexclude key = do
+	us <- getWebUrls' urlincludeexclude key
+	if null us
+		then return False
+		else either giveup return =<< checkKey' key us
+checkKey' :: Key -> [URLString] -> Annex (Either String Bool)
+checkKey' key us = firsthit us (Right False) $ \u -> do
+	let (u', downloader) = getDownloader u
+	case downloader of
+		YoutubeDownloader -> youtubeDlCheck u'
+		_ -> catchMsgIO $
+			Url.withUrlOptions $ Url.checkBoth u' (fromKey keySize key)
+  where
+	firsthit [] miss _ = return miss
+	firsthit (u:rest) _ a = do
+		r <- a u
+		case r of
+			Right True -> return r
+			_ -> firsthit rest r a
+
+getWebUrls :: Key -> Annex [URLString]
+getWebUrls key = getWebUrls' alwaysInclude key
+
+getWebUrls' :: UrlIncludeExclude -> Key -> Annex [URLString]
+getWebUrls' urlincludeexclude key = 
+	filter supported <$> getUrls key
+  where
+	supported u = supporteddownloader u 
+		&& checkUrlIncludeExclude urlincludeexclude u
+	supporteddownloader u = snd (getDownloader u) 
+		`elem` [WebDownloader, YoutubeDownloader]
+
+urlincludeField :: RemoteConfigField
+urlincludeField = Accepted "urlinclude"
+
+urlexcludeField :: RemoteConfigField
+urlexcludeField = Accepted "urlexclude"
+
+data UrlIncludeExclude = UrlIncludeExclude
+	{ checkUrlIncludeExclude :: URLString -> Bool
+	}
+
+alwaysInclude :: UrlIncludeExclude
+alwaysInclude = UrlIncludeExclude { checkUrlIncludeExclude = const True }
+
+mkUrlIncludeExclude :: ParsedRemoteConfig -> Annex UrlIncludeExclude
+mkUrlIncludeExclude = go fallback
+  where
+	go b pc = case (getglob urlincludeField pc, getglob urlexcludeField pc) of
+		(Nothing, Nothing) -> b
+		(minclude, mexclude) -> mk minclude mexclude
+
+	getglob f pc = do
+		glob <- getRemoteConfigValue f pc
+		Just $ compileGlob glob CaseInsensitive (GlobFilePath False)
+	
+	mk minclude mexclude = pure $ UrlIncludeExclude
+			{ checkUrlIncludeExclude = \u -> and
+				[ case minclude of
+					Just glob -> matchGlob glob u
+					Nothing -> True
+				, case mexclude of
+					Nothing -> True
+					Just glob -> not (matchGlob glob u)
+				]
+			}
+
+	-- When nothing to include or exclude is specified, only include
+	-- urls that are not explicitly included by other web special remotes.
+	fallback = do
+		rcs <- M.elems . M.filter iswebremote <$> remoteConfigMap
+		l <- forM rcs $ \rc ->
+			parsedRemoteConfig remote rc
+				>>= go (pure neverinclude)
+		pure $ UrlIncludeExclude
+			{ checkUrlIncludeExclude = \u ->
+				not (any (\c -> checkUrlIncludeExclude c u) l)
+			}
+	
+	iswebremote rc = (fromProposedAccepted <$> M.lookup typeField rc)
+		== Just (typename remote)
+
+	neverinclude = UrlIncludeExclude { checkUrlIncludeExclude = const False }
diff --git a/Remote/WebDAV.hs b/Remote/WebDAV.hs
new file mode 100644
index 0000000000..ab781c390e
--- /dev/null
+++ b/Remote/WebDAV.hs
@@ -0,0 +1,540 @@
+{- WebDAV remotes.
+ -
+ - Copyright 2012-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE ScopedTypeVariables #-}
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE RankNTypes #-}
+
+module Remote.WebDAV (remote, davCreds, configUrl) where
+
+import Network.Protocol.HTTP.DAV
+import qualified Data.Map as M
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString.UTF8 as B8
+import qualified Data.ByteString.Lazy.UTF8 as L8
+import Network.HTTP.Client (HttpException(..), RequestBody)
+import qualified Network.HTTP.Client as HTTP
+import Network.HTTP.Client (HttpExceptionContent(..), responseStatus)
+import Network.HTTP.Types
+import System.IO.Error
+import Control.Monad.Catch
+import Control.Monad.IO.Class (MonadIO)
+import Control.Concurrent.STM hiding (check)
+
+import Annex.Common
+import Types.Remote
+import Types.Export
+import qualified Git
+import qualified Annex
+import Config
+import Config.Cost
+import Annex.SpecialRemote.Config
+import Remote.Helper.Special
+import Remote.Helper.Http
+import Remote.Helper.ExportImport
+import qualified Remote.Helper.Chunked.Legacy as Legacy
+import Creds
+import Utility.Metered
+import Utility.Url (URLString, matchStatusCodeException, matchHttpExceptionContent)
+import Annex.Verify
+import Annex.UUID
+import Remote.WebDAV.DavLocation
+import Types.ProposedAccepted
+
+remote :: RemoteType
+remote = specialRemoteType $ RemoteType
+	{ typename = "webdav"
+	, enumerate = const (findSpecialRemotes "webdav")
+	, generate = gen
+	, configParser = mkRemoteConfigParser
+		[ optionalStringParser urlField
+			(FieldDesc "(required) url to the WebDAV directory")
+		, optionalStringParser davcredsField HiddenField
+		]
+	, setup = webdavSetup
+	, exportSupported = exportIsSupported
+	, importSupported = importUnsupported
+	, thirdPartyPopulated = False
+	}
+
+urlField :: RemoteConfigField
+urlField = Accepted "url"
+
+davcredsField :: RemoteConfigField
+davcredsField = Accepted "davcreds"
+
+gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	new
+		<$> pure c
+		<*> remoteCost gc c expensiveRemoteCost
+		<*> mkDavHandleVar c gc u
+  where
+	new c cst hdl = Just $ specialRemote c
+		(store hdl chunkconfig)
+		(retrieve hdl chunkconfig)
+		(remove hdl)
+		(checkKey hdl chunkconfig)
+		this
+	  where
+		this = Remote
+			{ uuid = u
+			, cost = cst
+			, name = Git.repoDescribe r
+			, storeKey = storeKeyDummy
+			, retrieveKeyFile = retrieveKeyFileDummy
+			, retrieveKeyFileCheap = Nothing
+			-- HttpManagerRestricted is used here, so this is
+			-- secure.
+			, retrievalSecurityPolicy = RetrievalAllKeysSecure
+			, removeKey = removeKeyDummy
+			, lockContent = Nothing
+			, checkPresent = checkPresentDummy
+			, checkPresentCheap = False
+			, exportActions = ExportActions
+				{ storeExport = storeExportDav hdl
+				, retrieveExport = retrieveExportDav hdl
+				, checkPresentExport = checkPresentExportDav hdl this
+				, removeExport = removeExportDav hdl
+				, versionedExport = False
+				, removeExportDirectory = Just $
+					removeExportDirectoryDav hdl
+				, renameExport = Just $ renameExportDav hdl
+				}
+			, importActions = importUnsupported
+			, whereisKey = Nothing
+			, remoteFsck = Nothing
+			, repairRepo = Nothing
+			, config = c
+			, getRepo = return r
+			, gitconfig = gc
+			, localpath = Nothing
+			, readonly = False
+			, appendonly = False
+			, untrustworthy = False
+			, availability = pure GloballyAvailable
+			, remotetype = remote
+			, mkUnavailable = gen r u (M.insert urlField (Proposed "http://!dne!/") rc) gc rs
+			, getInfo = includeCredsInfo c (davCreds u) $
+				[("url", fromMaybe "unknown" $ getRemoteConfigValue urlField c)]
+			, claimUrl = Nothing
+			, checkUrl = Nothing
+			, remoteStateHandle = rs
+			}
+		chunkconfig = getChunkConfig c
+
+webdavSetup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> Annex (RemoteConfig, UUID)
+webdavSetup ss mu mcreds c gc = do
+	u <- maybe (liftIO genUUID) return mu
+	url <- maybe (giveup "Specify url=")
+		(return . fromProposedAccepted)
+		(M.lookup urlField c)
+	(c', encsetup) <- encryptionSetup c gc
+	pc <- either giveup return . parseRemoteConfig c' =<< configParser remote c'
+	creds <- maybe (getCreds pc gc u) (return . Just) mcreds
+	testDav url creds
+	gitConfigSpecialRemote u c' [("webdav", "true")]
+	c'' <- setRemoteCredPair ss encsetup pc gc (davCreds u) creds
+	return (c'', u)
+
+store :: DavHandleVar -> ChunkConfig -> Storer
+store hv (LegacyChunks chunksize) = fileStorer $ \k f p -> 
+	withDavHandle hv $ \dav -> do
+		annexrunner <- Annex.makeRunner
+		liftIO $ withMeteredFile f p $ storeLegacyChunked annexrunner chunksize k dav
+store hv _ = httpStorer $ \k reqbody -> 
+	withDavHandle hv $ \dav -> liftIO $ goDAV dav $ do
+		let tmp = keyTmpLocation k
+		let dest = keyLocation k
+		storeHelper dav tmp dest reqbody
+
+storeHelper :: DavHandle -> DavLocation -> DavLocation -> RequestBody -> DAVT IO ()
+storeHelper dav tmp dest reqbody = do
+	maybe noop (void . mkColRecursive) (locationParent tmp)
+	debugDav $ "putContent " ++ tmp
+	inLocation tmp $
+		putContentM' (contentType, reqbody)
+	finalizeStore dav tmp dest
+
+finalizeStore :: DavHandle -> DavLocation -> DavLocation -> DAVT IO ()
+finalizeStore dav tmp dest = do
+	debugDav $ "delContent " ++ dest
+	inLocation dest $ void $ safely $ delContentM
+	maybe noop (void . mkColRecursive) (locationParent dest)
+	moveDAV (baseURL dav) tmp dest
+
+retrieve :: DavHandleVar -> ChunkConfig -> Retriever
+retrieve hv cc = fileRetriever' $ \d k p iv ->
+	withDavHandle hv $ \dav -> case cc of
+		LegacyChunks _ -> do
+			-- Not doing incremental verification for chunks.
+			liftIO $ maybe noop unableIncrementalVerifier iv
+			retrieveLegacyChunked (fromRawFilePath d) k p dav
+		_ -> liftIO $ goDAV dav $
+			retrieveHelper (keyLocation k) (fromRawFilePath d) p iv
+
+retrieveHelper :: DavLocation -> FilePath -> MeterUpdate -> Maybe IncrementalVerifier -> DAVT IO ()
+retrieveHelper loc d p iv = do
+	debugDav $ "retrieve " ++ loc
+	inLocation loc $
+		withContentM $ httpBodyRetriever d p iv
+
+remove :: DavHandleVar -> Remover
+remove hv k = withDavHandle hv $ \dav -> liftIO $ goDAV dav $
+	-- Delete the key's whole directory, including any
+	-- legacy chunked files, etc, in a single action.
+	removeHelper (keyDir k)
+
+removeHelper :: DavLocation -> DAVT IO ()
+removeHelper d = do
+	debugDav $ "delContent " ++ d
+	v <- safely $ inLocation d delContentM
+	case v of
+		Just _ -> return ()
+		Nothing -> do
+			v' <- existsDAV d
+			case v' of
+				Right False -> return ()
+				_ -> giveup "failed to remove content from remote"
+
+checkKey :: DavHandleVar -> ChunkConfig -> CheckPresent
+checkKey hv chunkconfig k = withDavHandle hv $ \dav ->
+	case chunkconfig of
+		LegacyChunks _ -> checkKeyLegacyChunked dav k
+		_ -> do
+			v <- liftIO $ goDAV dav $
+				existsDAV (keyLocation k)
+			either giveup return v
+
+storeExportDav :: DavHandleVar -> FilePath -> Key -> ExportLocation -> MeterUpdate -> Annex ()
+storeExportDav hdl f k loc p = case exportLocation loc of
+	Right dest -> withDavHandle hdl $ \h -> runExport h $ \dav -> do
+		reqbody <- liftIO $ httpBodyStorer f p
+		storeHelper dav (exportTmpLocation loc k) dest reqbody
+	Left err -> giveup err
+
+retrieveExportDav :: DavHandleVar -> Key -> ExportLocation -> FilePath -> MeterUpdate -> Annex Verification
+retrieveExportDav hdl  k loc d p = case exportLocation loc of
+	Right src -> verifyKeyContentIncrementally AlwaysVerify k  $ \iv ->
+		withDavHandle hdl $ \h -> runExport h $ \_dav ->
+			retrieveHelper src d p iv
+	Left err -> giveup err
+
+checkPresentExportDav :: DavHandleVar -> Remote -> Key -> ExportLocation -> Annex Bool
+checkPresentExportDav hdl _ _k loc = case exportLocation loc of
+	Right p -> withDavHandle hdl $ \h -> liftIO $ do
+		v <- goDAV h $ existsDAV p
+		either giveup return v
+	Left err -> giveup err
+
+removeExportDav :: DavHandleVar-> Key -> ExportLocation -> Annex ()
+removeExportDav hdl _k loc = case exportLocation loc of
+	Right p -> withDavHandle hdl $ \h -> runExport h $ \_dav ->
+		removeHelper p
+	-- When the exportLocation is not legal for webdav,
+	-- the content is certainly not stored there, so it's ok for
+	-- removal to succeed. This allows recovery after failure to store
+	-- content there, as the user can rename the problem file and
+	-- this will be called to make sure it's gone.
+	Left _err -> return ()
+
+removeExportDirectoryDav :: DavHandleVar -> ExportDirectory -> Annex ()
+removeExportDirectoryDav hdl dir = withDavHandle hdl $ \h -> runExport h $ \_dav -> do
+	let d = fromRawFilePath $ fromExportDirectory dir
+	debugDav $ "delContent " ++ d
+	inLocation d delContentM
+
+renameExportDav :: DavHandleVar -> Key -> ExportLocation -> ExportLocation -> Annex (Maybe ())
+renameExportDav hdl _k src dest = case (exportLocation src, exportLocation dest) of
+	(Right srcl, Right destl) -> withDavHandle hdl $ \h -> do
+		-- Several webdav servers have buggy handing of renames,
+		-- and fail to rename in some circumstances.
+		-- Since after a failure it's not clear where the file ended
+		-- up, recover by deleting both the source and destination.
+		-- The file will later be re-uploaded to the destination,
+		-- so this deletion is ok.
+		let go = runExport h $ \dav -> do
+			maybe noop (void . mkColRecursive) (locationParent destl)
+			moveDAV (baseURL dav) srcl destl
+			return (Just ())
+		let recover = do
+			void $ runExport h $ \_dav -> safely $
+				inLocation srcl delContentM
+			void $ runExport h $ \_dav -> safely $
+				inLocation destl delContentM
+			return Nothing
+		catchNonAsync go (const recover)
+	(Left err, _) -> giveup err
+	(_, Left err) -> giveup err
+
+runExport :: DavHandle -> (DavHandle -> DAVT IO a) -> Annex a
+runExport h a = liftIO (goDAV h (a h))
+
+configUrl :: ParsedRemoteConfig -> Maybe URLString
+configUrl c = fixup <$> getRemoteConfigValue urlField c
+  where
+	-- box.com DAV url changed
+	fixup = replace "https://www.box.com/dav/" boxComUrl
+
+boxComUrl :: URLString
+boxComUrl = "https://dav.box.com/dav/"
+
+type DavUser = B8.ByteString
+type DavPass = B8.ByteString
+
+baseURL :: DavHandle -> URLString
+baseURL (DavHandle _ _ _ u) = u
+
+
+toDavUser :: String -> DavUser
+toDavUser = B8.fromString
+
+toDavPass :: String -> DavPass
+toDavPass = B8.fromString
+
+{- Test if a WebDAV store is usable, by writing to a test file, and then
+ - deleting the file.
+ -
+ - Also ensures that the path of the url exists, trying to create it if not.
+ -
+ - Throws an error if store is not usable.
+ -}
+testDav :: URLString -> Maybe CredPair -> Annex ()
+testDav url (Just (u, p)) = do
+	showAction "testing WebDAV server"
+	test $ liftIO $ evalDAVT url $ do
+		prepDAV user pass
+		makeParentDirs
+		inLocation (tmpLocation "test") $ do
+			putContentM (Nothing, L8.fromString "test")
+			delContentM
+  where
+	test a = liftIO $
+		either (\e -> throwIO $ "WebDAV test failed: " ++ show e)
+			(const noop)
+			=<< tryNonAsync a
+
+	user = toDavUser u
+	pass = toDavPass p
+testDav _ Nothing = giveup "Need to configure webdav username and password."
+
+{- Tries to make all the parent directories in the WebDAV urls's path,
+ - right down to the root.
+ -
+ - Ignores any failures, which can occur for reasons including the WebDAV
+ - server only serving up WebDAV in a subdirectory. -}
+makeParentDirs :: DAVT IO ()
+makeParentDirs = go
+  where
+	go = do
+		l <- getDAVLocation
+		case locationParent l of
+			Nothing -> noop
+			Just p -> void $ safely $ inDAVLocation (const p) go
+		void $ safely mkCol
+
+{- Checks if the directory exists. If not, tries to create its
+ - parent directories, all the way down to the root, and finally creates
+ - it. -}
+mkColRecursive :: DavLocation -> DAVT IO Bool
+mkColRecursive d = go =<< existsDAV d
+  where
+	go (Right True) = return True
+	go _ = do
+		debugDav $ "mkCol " ++ d
+		ifM (inLocation d mkCol)
+			( return True
+			, do
+				case locationParent d of
+					Nothing -> makeParentDirs
+					Just parent -> void (mkColRecursive parent)
+				inLocation d mkCol
+			)
+
+getCreds :: ParsedRemoteConfig -> RemoteGitConfig -> UUID -> Annex (Maybe CredPair)
+getCreds c gc u = getRemoteCredPairFor "webdav" c gc (davCreds u)
+
+davCreds :: UUID -> CredPairStorage
+davCreds u = CredPairStorage
+	{ credPairFile = fromUUID u
+	, credPairEnvironment = ("WEBDAV_USERNAME", "WEBDAV_PASSWORD")
+	, credPairRemoteField = davcredsField
+	}
+
+{- Content-Type to use for files uploaded to WebDAV. -}
+contentType :: Maybe B8.ByteString
+contentType = Just $ B8.fromString "application/octet-stream"
+
+throwIO :: String -> IO a
+throwIO msg = ioError $ mkIOError userErrorType msg Nothing Nothing
+
+moveDAV :: URLString -> DavLocation -> DavLocation -> DAVT IO ()
+moveDAV baseurl src dest = do
+	debugDav $ "moveContent " ++ src ++ " " ++ newurl
+	inLocation src $ moveContentM (B8.fromString newurl)
+  where
+	newurl = locationUrl baseurl dest
+
+existsDAV :: DavLocation -> DAVT IO (Either String Bool)
+existsDAV l = do
+	debugDav $ "getProps " ++ l
+	inLocation l check `catchNonAsync` (\e -> return (Left $ show e))
+  where
+	check = do
+		-- Some DAV services only support depth of 1, and
+		-- more depth is certainly not needed to check if a
+		-- location exists.
+		setDepth (Just Depth1)
+		catchJust missinghttpstatus
+			(getPropsM >> ispresent True)
+			(const $ ispresent False)
+	ispresent = return . Right
+	missinghttpstatus e = 
+		matchStatusCodeException (== notFound404) e
+		<|> matchHttpExceptionContent toomanyredirects e
+	toomanyredirects (TooManyRedirects _) = True
+	toomanyredirects _ = False
+
+safely :: DAVT IO a -> DAVT IO (Maybe a)
+safely = eitherToMaybe <$$> tryNonAsync
+
+choke :: IO (Either String a) -> IO a
+choke f = do
+	x <- f
+	case x of
+		Left e -> giveup e
+		Right r -> return r
+
+data DavHandle = DavHandle DAVContext DavUser DavPass URLString
+
+type DavHandleVar = TVar (Either (Annex (Either String DavHandle)) (Either String DavHandle))
+
+{- Prepares a DavHandle for later use. Does not connect to the server or do
+ - anything else expensive. -}
+mkDavHandleVar :: ParsedRemoteConfig -> RemoteGitConfig -> UUID -> Annex DavHandleVar
+mkDavHandleVar c gc u = liftIO $ newTVarIO $ Left $ do
+	mcreds <- getCreds c gc u
+	case (mcreds, configUrl c) of
+		(Just (user, pass), Just baseurl) -> do
+			ctx <- mkDAVContext baseurl
+			let h = DavHandle ctx (toDavUser user) (toDavPass pass) baseurl
+			return (Right h)
+		_ -> return $ Left "webdav credentials not available"
+
+withDavHandle :: DavHandleVar -> (DavHandle -> Annex a) -> Annex a
+withDavHandle hv a = liftIO (readTVarIO hv) >>= \case
+	Right hdl -> either giveup a hdl
+	Left mkhdl -> do
+		hdl <- mkhdl
+		liftIO $ atomically $ writeTVar hv (Right hdl)
+		either giveup a hdl
+
+goDAV :: DavHandle -> DAVT IO a -> IO a
+goDAV (DavHandle ctx user pass _) a = choke $ run $ prettifyExceptions $ do
+	prepDAV user pass
+	a
+  where
+	run = fst <$$> runDAVContext ctx
+
+{- Catch StatusCodeException and trim it to only the statusMessage part,
+ - eliminating a lot of noise, which can include the whole request that
+ - failed. The rethrown exception is no longer a StatusCodeException. -}
+prettifyExceptions :: DAVT IO a -> DAVT IO a
+prettifyExceptions a = catchJust (matchStatusCodeException (const True)) a go
+  where
+	go (HttpExceptionRequest req (StatusCodeException response message)) = giveup $ unwords
+		[ "DAV failure:"
+		, show (responseStatus response)
+		, show (message)
+		, "HTTP request:"
+		, show (HTTP.method req)
+		, show (HTTP.path req)
+		]
+	go e = throwM e
+
+prepDAV :: DavUser -> DavPass -> DAVT IO ()
+prepDAV user pass = do
+	setResponseTimeout Nothing -- disable default (5 second!) timeout
+	setCreds user pass
+
+--
+-- Legacy chunking code, to be removed eventually.
+--
+
+storeLegacyChunked :: (Annex () -> IO ()) -> ChunkSize -> Key -> DavHandle -> L.ByteString -> IO ()
+storeLegacyChunked annexrunner chunksize k dav b =
+	Legacy.storeChunks k tmp dest storer recorder finalizer
+  where
+	storehttp l b' = void $ goDAV dav $ do
+		maybe noop (void . mkColRecursive) (locationParent l)
+		debugDav $ "putContent " ++ l
+		inLocation l $ putContentM (contentType, b')
+	storer locs = Legacy.storeChunked annexrunner chunksize locs storehttp b
+	recorder l s = storehttp l (L8.fromString s)
+	finalizer tmp' dest' = goDAV dav $ 
+		finalizeStore dav tmp' (fromJust $ locationParent dest')
+
+	tmp = addTrailingPathSeparator $ keyTmpLocation k
+	dest = keyLocation k
+
+retrieveLegacyChunked :: FilePath -> Key -> MeterUpdate -> DavHandle -> Annex ()
+retrieveLegacyChunked d k p dav = liftIO $
+	withStoredFilesLegacyChunked k dav onerr $ \locs ->
+		Legacy.meteredWriteFileChunks p d locs $ \l ->
+			goDAV dav $ do
+				debugDav $ "getContent " ++ l
+				inLocation l $
+					snd <$> getContentM
+  where
+	onerr = giveup "download failed"
+
+checkKeyLegacyChunked :: DavHandle -> CheckPresent
+checkKeyLegacyChunked dav k = liftIO $
+	either giveup id <$> withStoredFilesLegacyChunked k dav onerr check
+  where
+	check [] = return $ Right True
+	check (l:ls) = do
+		v <- goDAV dav $ existsDAV l
+		if v == Right True
+			then check ls
+			else return v
+
+	{- Failed to read the chunkcount file; see if it's missing,
+	 - or if there's a problem accessing it,
+	- or perhaps this was an intermittent error. -}
+	onerr f = do
+		v <- goDAV dav $ existsDAV f
+		return $ if v == Right True
+			then Left $ "failed to read " ++ f
+			else v
+
+withStoredFilesLegacyChunked
+	:: Key
+	-> DavHandle
+	-> (DavLocation -> IO a)
+	-> ([DavLocation] -> IO a)
+	-> IO a
+withStoredFilesLegacyChunked k dav onerr a = do
+	let chunkcount = keyloc ++ Legacy.chunkCount
+	v <- goDAV dav $ safely $ do
+		debugDav $ "getContent " ++ chunkcount
+		inLocation chunkcount $
+			snd <$> getContentM
+	case v of
+		Just s -> a $ Legacy.listChunks keyloc $ L8.toString s
+		Nothing -> do
+			chunks <- Legacy.probeChunks keyloc $ \f ->
+				(== Right True) <$> goDAV dav (existsDAV f)
+			if null chunks
+				then onerr chunkcount
+				else a chunks
+  where
+	keyloc = keyLocation k
+
+debugDav :: MonadIO m => String -> DAVT m ()
+debugDav msg = liftIO $ debug "Remote.WebDAV" msg
diff --git a/Remote/WebDAV/DavLocation.hs b/Remote/WebDAV/DavLocation.hs
new file mode 100644
index 0000000000..e836acd8a9
--- /dev/null
+++ b/Remote/WebDAV/DavLocation.hs
@@ -0,0 +1,92 @@
+{- WebDAV locations.
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE FlexibleContexts #-}
+
+module Remote.WebDAV.DavLocation where
+
+import Types
+import Types.Export
+import Annex.Locations
+import Utility.Url (URLString)
+#ifdef mingw32_HOST_OS
+import Utility.Split
+#endif
+import Utility.FileSystemEncoding
+
+import System.FilePath.Posix -- for manipulating url paths
+import Network.Protocol.HTTP.DAV (inDAVLocation, DAVT)
+import Control.Monad.IO.Class (MonadIO)
+import Network.URI
+import Data.Default
+
+-- Relative to the top of the DAV url.
+type DavLocation = String
+
+{- Runs action with a new location relative to the current location. -}
+inLocation :: (MonadIO m) => DavLocation -> DAVT m a -> DAVT m a
+inLocation d = inDAVLocation (</> d')
+  where
+	d' = escapeURIString isUnescapedInURI d
+
+{- The directory where files(s) for a key are stored. -}
+keyDir :: Key -> DavLocation
+keyDir k = addTrailingPathSeparator $ hashdir </> fromRawFilePath (keyFile k)
+  where
+#ifndef mingw32_HOST_OS
+	hashdir = fromRawFilePath $ hashDirLower def k
+#else
+	hashdir = replace "\\" "/" (fromRawFilePath $ hashDirLower def k)
+#endif
+
+keyLocation :: Key -> DavLocation
+keyLocation k = keyDir k ++ fromRawFilePath (keyFile k)
+
+{- Paths containing # or ? cannot be represented in an url, so fails on
+ - those. -}
+exportLocation :: ExportLocation -> Either String DavLocation
+exportLocation l =
+	let p = fromRawFilePath $ fromExportLocation l
+	in if any (`elem` p) illegalinurl
+		then Left ("Cannot store file containing '#' or '?' on webdav: " ++ p)
+		else Right p
+  where
+	illegalinurl = ['#', '?'] :: [Char]
+
+{- Where we store temporary data for a key as it's being uploaded. -}
+keyTmpLocation :: Key -> DavLocation
+keyTmpLocation = tmpLocation . fromRawFilePath . keyFile
+
+{- Where we store temporary data for a file as it's being exported.
+ -
+ - This could be just the keyTmpLocation, but when the file is in a
+ - subdirectory, the temp file is put in there. Partly this is to keep
+ - it close to the final destination; also certain webdav servers
+ - seem to be buggy when renaming files from the root into a subdir, 
+ - and so writing to the subdir avoids such problems.
+ -}
+exportTmpLocation :: ExportLocation -> Key -> DavLocation
+exportTmpLocation l k
+	| length (splitDirectories p) > 1 = takeDirectory p </> keyTmpLocation k
+	| otherwise = keyTmpLocation k
+  where
+	p = fromRawFilePath (fromExportLocation l)
+
+tmpLocation :: FilePath -> DavLocation
+tmpLocation f = "git-annex-webdav-tmp-" ++ f
+
+locationParent :: String -> Maybe String
+locationParent loc
+	| loc `elem` tops || parent `elem` tops = Nothing
+	| otherwise = Just parent
+  where
+	tops = ["/", "", "."]
+	parent = takeDirectory loc
+
+locationUrl :: URLString -> DavLocation -> URLString
+locationUrl baseurl loc = baseurl </> loc
diff --git a/RemoteDaemon/Common.hs b/RemoteDaemon/Common.hs
new file mode 100644
index 0000000000..d366c08e7e
--- /dev/null
+++ b/RemoteDaemon/Common.hs
@@ -0,0 +1,71 @@
+{- git-remote-daemon utilities
+ -
+ - Copyright 2014-2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module RemoteDaemon.Common
+	( liftAnnex
+	, inLocalRepo
+	, checkShouldFetch
+	, ConnectionStatus(..)
+	, robustConnection
+	) where
+
+import qualified Annex
+import Annex.Common
+import RemoteDaemon.Types
+import qualified Git
+import Annex.CatFile
+import Utility.ThreadScheduler
+
+import Control.Concurrent
+
+-- Runs an Annex action. Long-running actions should be avoided,
+-- since only one liftAnnex can be running at a time, across all
+-- transports.
+liftAnnex :: TransportHandle -> Annex a -> IO a
+liftAnnex (TransportHandle _ stmv rd) a = do
+	st <- takeMVar stmv
+	(r, (st', _rd)) <- Annex.run (st, rd) a
+	putMVar stmv st'
+	return r
+
+inLocalRepo :: TransportHandle -> (Git.Repo -> IO a) -> IO a
+inLocalRepo (TransportHandle (LocalRepo g) _ _) a = a g
+
+-- Check if some shas should be fetched from the remote,
+-- and presumably later merged.
+checkShouldFetch :: RemoteGitConfig -> TransportHandle -> [Git.Sha] -> IO Bool
+checkShouldFetch gc transporthandle shas
+	| remoteAnnexPull gc = checkNewShas transporthandle shas
+	| otherwise = return False
+
+-- Check if any of the shas are actually new in the local git repo,
+-- to avoid unnecessary fetching.
+checkNewShas :: TransportHandle -> [Git.Sha] -> IO Bool
+checkNewShas transporthandle = check
+  where
+	check [] = return True
+	check (r:rs) = maybe (check rs) (const $ return False)
+		=<< liftAnnex transporthandle (catObjectDetails r)
+
+data ConnectionStatus = ConnectionStopping | ConnectionClosed
+
+{- Make connection robust, retrying on error, with exponential backoff. -}
+robustConnection :: Int -> IO ConnectionStatus -> IO ()
+robustConnection backoff a = 
+	caught =<< a `catchNonAsync` (const $ return ConnectionClosed)
+  where
+	caught ConnectionStopping = return ()
+	caught ConnectionClosed = do
+		threadDelaySeconds (Seconds backoff)
+		robustConnection increasedbackoff a
+
+	increasedbackoff
+		| b2 > maxbackoff = maxbackoff
+		| otherwise = b2
+	  where
+		b2 = backoff * 2
+		maxbackoff = 3600 -- one hour
diff --git a/RemoteDaemon/Core.hs b/RemoteDaemon/Core.hs
new file mode 100644
index 0000000000..4ca248e315
--- /dev/null
+++ b/RemoteDaemon/Core.hs
@@ -0,0 +1,178 @@
+{- git-remote-daemon core
+ -
+ - Copyright 2014-2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module RemoteDaemon.Core (runInteractive, runNonInteractive) where
+
+import qualified Annex
+import Common
+import Types.GitConfig
+import Config.DynamicConfig
+import RemoteDaemon.Common
+import RemoteDaemon.Types
+import RemoteDaemon.Transport
+import qualified Git
+import qualified Git.Types as Git
+import qualified Git.CurrentRepo
+import qualified Git.Construct
+import Utility.SimpleProtocol
+import Utility.ThreadScheduler
+import Config
+import Annex.Ssh
+import Annex.BranchState
+import Types.Messages
+
+import Control.Concurrent
+import Control.Concurrent.Async
+import Control.Concurrent.STM
+import Network.URI
+import qualified Data.Map as M
+
+runInteractive :: IO ()
+runInteractive = do
+	(readh, writeh) <- dupIoHandles
+	ichan <- newTChanIO :: IO (TChan Consumed)
+	ochan <- newTChanIO :: IO (TChan Emitted)
+
+	let reader = forever $ do
+		l <- hGetLine readh
+		case parseMessage l of
+			Nothing -> giveup $ "protocol error: " ++ l
+			Just cmd -> atomically $ writeTChan ichan cmd
+	let writer = forever $ do
+		msg <- atomically $ readTChan ochan
+		hPutStrLn writeh $ unwords $ formatMessage msg
+		hFlush writeh
+	let controller = runController ichan ochan
+	
+	-- If any thread fails, the rest will be killed.
+	void $ tryIO $ reader
+		`concurrently` writer
+		`concurrently` controller
+
+runNonInteractive :: IO ()
+runNonInteractive = do
+	ichan <- newTChanIO :: IO (TChan Consumed)
+	ochan <- newTChanIO :: IO (TChan Emitted)
+	
+	let reader = forever $ do
+		threadDelaySeconds (Seconds (60*60))
+		atomically $ writeTChan ichan RELOAD
+	let writer = forever $
+		void $ atomically $ readTChan ochan
+	let controller = runController ichan ochan
+	
+	void $ tryIO $ reader
+		`concurrently` writer
+		`concurrently` controller
+
+type RemoteMap = M.Map Git.Repo (IO (), TChan Consumed)
+
+-- Runs the transports, dispatching messages to them, and handling
+-- the main control messages.
+runController :: TChan Consumed -> TChan Emitted -> IO ()
+runController ichan ochan = do
+	h <- genTransportHandle
+	m <- genRemoteMap h ochan
+	starttransports m
+	serverchans <- mapM (startserver h) remoteServers
+	go h False m serverchans
+  where
+	go h paused m serverchans = do
+		cmd <- atomically $ readTChan ichan
+		broadcast cmd serverchans
+		case cmd of
+			RELOAD -> do
+				h' <- updateTransportHandle h
+				m' <- genRemoteMap h' ochan
+				let common = M.intersection m m'
+				let new = M.difference m' m
+				let old = M.difference m m'
+				broadcast STOP (mchans old)
+				unless paused $
+					starttransports new
+				go h' paused (M.union common new) serverchans
+			LOSTNET -> do
+				-- force close all cached ssh connections
+				-- (done here so that if there are multiple
+				-- ssh remotes, it's only done once)
+				liftAnnex h forceSshCleanup
+				broadcast LOSTNET transportchans
+				go h True m serverchans
+			PAUSE -> do
+				broadcast STOP transportchans
+				go h True m serverchans
+			RESUME -> do
+				when paused $
+					starttransports m
+				go h False m serverchans
+			STOP -> exitSuccess
+			-- All remaining messages are sent to
+			-- all Transports.
+			msg -> do
+				unless paused $
+					broadcast msg transportchans
+				go h paused m serverchans
+	  where
+		transportchans = mchans m
+		mchans = map snd . M.elems
+	
+	startserver h server = do
+		c <- newTChanIO
+		void $ async $ server c h
+		return c
+
+	starttransports m = forM_ (M.elems m) starttransports'
+	starttransports' (transport, c) = do
+		-- drain any old control messages from the channel
+		-- to avoid confusing the transport with them
+		atomically $ drain c
+		void $ async transport
+	
+	drain c = maybe noop (const $ drain c) =<< tryReadTChan c
+	
+	broadcast msg cs = atomically $ forM_ cs $ \c -> writeTChan c msg
+
+-- Generates a map with a transport for each supported remote in the git repo,
+-- except those that have annex.sync = false
+genRemoteMap :: TransportHandle -> TChan Emitted -> IO RemoteMap
+genRemoteMap h@(TransportHandle (LocalRepo g) _ _) ochan = do
+	rs <- Git.Construct.fromRemotes g
+	M.fromList . catMaybes <$> mapM gen rs
+  where
+	gen r = do
+		gc <- atomically $ extractRemoteGitConfig g (Git.repoDescribe r)
+		case Git.location r of
+			Git.Url u -> case M.lookup (uriScheme u) remoteTransports of
+				Just transport -> ifM (getDynamicConfig (remoteAnnexSync gc))
+					( do
+						ichan <- newTChanIO :: IO (TChan Consumed)
+						return $ Just
+							( r
+							, (transport (RemoteRepo r gc) (RemoteURI u) h ichan ochan, ichan)
+							)
+					, return Nothing
+					)
+				Nothing -> return Nothing
+			_ -> return Nothing
+
+genTransportHandle :: IO TransportHandle
+genTransportHandle = do
+	(st, rd) <- Annex.new =<< Git.CurrentRepo.get
+	mvar <- newMVar st
+	let g = Annex.repo st
+	let h = TransportHandle (LocalRepo g) mvar rd
+	liftAnnex h $ do
+		Annex.setOutput QuietOutput
+		enableInteractiveBranchAccess
+	return h
+
+updateTransportHandle :: TransportHandle -> IO TransportHandle
+updateTransportHandle h@(TransportHandle _g st rd) = do
+	g' <- liftAnnex h $ do
+		reloadConfig
+		Annex.gitRepo
+	return (TransportHandle (LocalRepo g') st rd)
diff --git a/RemoteDaemon/Transport.hs b/RemoteDaemon/Transport.hs
new file mode 100644
index 0000000000..35261155d5
--- /dev/null
+++ b/RemoteDaemon/Transport.hs
@@ -0,0 +1,30 @@
+{- git-remote-daemon transports
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module RemoteDaemon.Transport where
+
+import RemoteDaemon.Types
+import qualified RemoteDaemon.Transport.Ssh
+import qualified RemoteDaemon.Transport.GCrypt
+import qualified RemoteDaemon.Transport.Tor
+import qualified Git.GCrypt
+import P2P.Address (torAnnexScheme)
+
+import qualified Data.Map as M
+
+-- Corresponds to uriScheme
+type TransportScheme = String
+
+remoteTransports :: M.Map TransportScheme Transport
+remoteTransports = M.fromList
+	[ ("ssh:", RemoteDaemon.Transport.Ssh.transport)
+	, (Git.GCrypt.urlScheme, RemoteDaemon.Transport.GCrypt.transport)
+	, (torAnnexScheme, RemoteDaemon.Transport.Tor.transport)
+	]
+
+remoteServers :: [Server]
+remoteServers = [RemoteDaemon.Transport.Tor.server]
diff --git a/RemoteDaemon/Transport/GCrypt.hs b/RemoteDaemon/Transport/GCrypt.hs
new file mode 100644
index 0000000000..746946638e
--- /dev/null
+++ b/RemoteDaemon/Transport/GCrypt.hs
@@ -0,0 +1,28 @@
+{- git-remote-daemon, gcrypt transport
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module RemoteDaemon.Transport.GCrypt (transport) where
+
+import Annex.Common
+import RemoteDaemon.Types
+import RemoteDaemon.Common
+import RemoteDaemon.Transport.Ssh (transportUsingCmd)
+import Git.GCrypt
+import Remote.Helper.Ssh
+import Remote.GCrypt (accessShellConfig)
+import Annex.Ssh
+
+transport :: Transport
+transport rr@(RemoteRepo r gc) url h@(TransportHandle (LocalRepo g) _ _) ichan ochan
+	| accessShellConfig gc = do
+		r' <- encryptedRemote g r
+		v <- liftAnnex h $ git_annex_shell ConsumeStdin r' "notifychanges" [] []
+		case v of
+			Nothing -> noop
+			Just (cmd, params) -> 
+				transportUsingCmd cmd params rr url h ichan ochan
+	| otherwise = noop
diff --git a/RemoteDaemon/Transport/Ssh.hs b/RemoteDaemon/Transport/Ssh.hs
new file mode 100644
index 0000000000..eff692120b
--- /dev/null
+++ b/RemoteDaemon/Transport/Ssh.hs
@@ -0,0 +1,88 @@
+{- git-remote-daemon, git-annex-shell over ssh transport
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module RemoteDaemon.Transport.Ssh (transport, transportUsingCmd) where
+
+import Annex.Common
+import Annex.Ssh
+import RemoteDaemon.Types
+import RemoteDaemon.Common
+import Remote.Helper.Ssh
+import qualified RemoteDaemon.Transport.Ssh.Types as SshRemote
+import Utility.SimpleProtocol
+import qualified Git
+import Git.Command
+import Annex.ChangedRefs
+
+import Control.Concurrent.STM
+import Control.Concurrent.Async
+
+transport :: Transport
+transport rr@(RemoteRepo r _) url h ichan ochan = do
+	v <- liftAnnex h $ git_annex_shell ConsumeStdin r "notifychanges" [] []
+	case v of
+		Nothing -> noop
+		Just (cmd, params) -> transportUsingCmd cmd params rr url h ichan ochan
+
+transportUsingCmd :: FilePath -> [CommandParam] -> Transport
+transportUsingCmd cmd params rr@(RemoteRepo r gc) url h@(TransportHandle (LocalRepo g) st rd) ichan ochan = do
+	-- enable ssh connection caching wherever inLocalRepo is called
+	g' <- liftAnnex h $ sshOptionsTo r gc g
+	let transporthandle = TransportHandle (LocalRepo g') st rd
+	transportUsingCmd' cmd params rr url transporthandle ichan ochan
+
+transportUsingCmd' :: FilePath -> [CommandParam] -> Transport
+transportUsingCmd' cmd params (RemoteRepo r gc) url transporthandle ichan ochan =
+	robustConnection 1 $ withCreateProcess p go
+  where
+	p = (proc cmd (toCommand params))
+		{ std_in = CreatePipe
+		, std_out = CreatePipe
+		}
+
+	go (Just toh) (Just fromh) Nothing pid = do
+		-- Run all threads until one finishes and get the status
+		-- of the first to finish. Cancel the rest.
+		status <- catchDefaultIO (Right ConnectionClosed) $
+				handlestdout fromh
+					`race` handlecontrol
+
+		send (DISCONNECTED url)
+		hClose toh
+		hClose fromh
+		void $ waitForProcess pid
+
+		return $ either id id status
+	go _ _ _ _ = error "internal"
+
+	send msg = atomically $ writeTChan ochan msg
+
+	fetch = do
+		send (SYNCING url)
+		ok <- inLocalRepo transporthandle $
+			runBool [Param "fetch", Param $ Git.repoDescribe r]
+		send (DONESYNCING url ok)
+		
+	handlestdout fromh = do
+		ml <- getProtocolLine fromh
+		case parseMessage =<< ml of
+			Just SshRemote.READY -> do
+				send (CONNECTED url)
+				handlestdout fromh
+			Just (SshRemote.CHANGED (ChangedRefs shas)) -> do
+				whenM (checkShouldFetch gc transporthandle shas) $
+					fetch
+				handlestdout fromh
+			-- avoid reconnect on protocol error
+			Nothing -> return ConnectionStopping
+	
+	handlecontrol = do
+		msg <- atomically $ readTChan ichan
+		case msg of
+			STOP -> return ConnectionStopping
+			LOSTNET -> return ConnectionStopping
+			_ -> handlecontrol
diff --git a/RemoteDaemon/Transport/Ssh/Types.hs b/RemoteDaemon/Transport/Ssh/Types.hs
new file mode 100644
index 0000000000..7a0c2eab70
--- /dev/null
+++ b/RemoteDaemon/Transport/Ssh/Types.hs
@@ -0,0 +1,32 @@
+{- git-remote-daemon, git-annex-shell notifychanges protocol types
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-}
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module RemoteDaemon.Transport.Ssh.Types (
+	Notification(..),
+	Proto.serialize,
+	Proto.deserialize,
+	Proto.formatMessage,
+) where
+
+import qualified Utility.SimpleProtocol as Proto
+import Annex.ChangedRefs (ChangedRefs)
+
+data Notification
+	= READY
+	| CHANGED ChangedRefs
+
+instance Proto.Sendable Notification where
+	formatMessage READY = ["READY"]
+	formatMessage (CHANGED shas) = ["CHANGED", Proto.serialize shas]
+
+instance Proto.Receivable Notification where
+	parseCommand "READY" = Proto.parse0 READY
+	parseCommand "CHANGED" = Proto.parse1 CHANGED
+	parseCommand _ = Proto.parseFail
diff --git a/RemoteDaemon/Transport/Tor.hs b/RemoteDaemon/Transport/Tor.hs
new file mode 100644
index 0000000000..7ec4249123
--- /dev/null
+++ b/RemoteDaemon/Transport/Tor.hs
@@ -0,0 +1,206 @@
+{- git-remote-daemon, tor hidden service server and transport
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module RemoteDaemon.Transport.Tor (server, transport, torSocketFile) where
+
+import Common
+import qualified Annex
+import Annex.Concurrent
+import Annex.ChangedRefs
+import RemoteDaemon.Types
+import RemoteDaemon.Common
+import Utility.AuthToken
+import Utility.Tor
+import P2P.Protocol as P2P
+import P2P.IO
+import P2P.Annex
+import P2P.Auth
+import P2P.Address
+import Annex.UUID
+import Types.UUID
+import Messages
+import Git
+import Git.Command
+import Utility.Debug
+
+import Control.Concurrent
+import Control.Concurrent.STM
+import Control.Concurrent.STM.TBMQueue
+import Control.Concurrent.Async
+#ifndef mingw32_HOST_OS
+import System.Posix.User
+#endif
+
+-- Run tor hidden service.
+server :: Server
+server ichan th@(TransportHandle (LocalRepo r) _ _) = go
+  where
+	go = checkstartservice >>= handlecontrol
+
+	checkstartservice = do
+		u <- liftAnnex th getUUID
+		msock <- liftAnnex th torSocketFile
+		case msock of
+			Nothing -> do
+				debugTor "Tor hidden service not enabled"
+				return False
+			Just sock -> do
+				void $ async $ startservice sock u
+				return True
+	
+	startservice sock u = do
+		q <- newTBMQueueIO maxConnections
+		replicateM_ maxConnections $
+			forkIO $ forever $ serveClient th u r q
+
+		debugTor "Tor hidden service running"
+		serveUnixSocket sock $ \conn -> do
+			ok <- atomically $ ifM (isFullTBMQueue q)
+				( return False
+				, do
+					writeTBMQueue q conn
+					return True
+				)
+			unless ok $ do
+				hClose conn
+				liftAnnex th $ warning "dropped Tor connection, too busy"
+	
+	handlecontrol servicerunning = do
+		msg <- atomically $ readTChan ichan
+		case msg of
+			-- On reload, the configuration may have changed to
+			-- enable the tor hidden service. If it was not
+			-- enabled before, start it,
+			RELOAD | not servicerunning -> go
+			-- We can ignore all other messages; no need
+			-- to restart the hidden service when the network
+			-- changes as tor takes care of all that.
+			_ -> handlecontrol servicerunning
+
+-- How many clients to serve at a time, maximum. This is to avoid DOS attacks.
+maxConnections :: Int
+maxConnections = 100
+
+serveClient :: TransportHandle -> UUID -> Repo -> TBMQueue Handle -> IO ()
+serveClient th@(TransportHandle _ _ rd) u r q = bracket setup cleanup start
+  where
+	setup = do
+		h <- atomically $ readTBMQueue q
+		debugTor "serving a Tor connection"
+		return h
+	
+	cleanup Nothing = return ()
+	cleanup (Just h) = do
+		debugTor "done with Tor connection"
+		hClose h
+
+	start Nothing = return ()
+	start (Just h) = do
+		-- Avoid doing any work in the liftAnnex, since only one
+		-- can run at a time.
+		st <- liftAnnex th dupState
+		((), (st', _rd)) <- Annex.run (st, rd) $ do
+			-- Load auth tokens for every connection, to notice
+			-- when the allowed set is changed.
+			allowed <- loadP2PAuthTokens
+			let conn = P2PConnection
+				{ connRepo = r
+				, connCheckAuth = (`isAllowedAuthToken` allowed)
+				, connIhdl = h
+				, connOhdl = h
+				, connIdent = ConnIdent $ Just "tor remotedaemon"
+				}
+			-- not really Client, but we don't know their uuid yet
+			runstauth <- liftIO $ mkRunState Client
+			v <- liftIO $ runNetProto runstauth conn $ P2P.serveAuth u
+			case v of
+				Right (Just theiruuid) -> authed conn theiruuid
+				Right Nothing -> liftIO $ debugTor
+					"Tor connection failed to authenticate"
+				Left e -> liftIO $ debugTor $
+					"Tor connection error before authentication: " ++ describeProtoFailure e
+		-- Merge the duplicated state back in.
+		liftAnnex th $ mergeState st'
+	
+	authed conn theiruuid = 
+		bracket watchChangedRefs (liftIO . maybe noop stopWatchingChangedRefs) $ \crh -> do
+			runst <- liftIO $ mkRunState (Serving theiruuid crh)
+			v' <- runFullProto runst conn $
+				P2P.serveAuthed P2P.ServeReadWrite u
+			case v' of
+				Right () -> return ()
+				Left e -> liftIO $ debugTor $ 
+					"Tor connection error: " ++ describeProtoFailure e
+
+-- Connect to peer's tor hidden service.
+transport :: Transport
+transport (RemoteRepo r gc) url@(RemoteURI uri) th ichan ochan =
+	case unformatP2PAddress (show uri) of
+		Nothing -> return ()
+		Just addr -> robustConnection 1 $ do
+			g <- liftAnnex th Annex.gitRepo
+			bracket (connectPeer g addr) closeConnection (go addr)
+  where
+	go addr conn = do
+		myuuid <- liftAnnex th getUUID
+		authtoken <- fromMaybe nullAuthToken
+			<$> liftAnnex th (loadP2PRemoteAuthToken addr)
+		runst <- mkRunState Client
+		res <- runNetProto runst conn $ P2P.auth myuuid authtoken noop
+		case res of
+			Right (Just theiruuid) -> do
+				expecteduuid <- liftAnnex th $ getRepoUUID r
+				if expecteduuid == theiruuid
+					then do
+						send (CONNECTED url)
+						status <- handlecontrol
+							`race` handlepeer runst conn
+						send (DISCONNECTED url)
+						return $ either id id status
+					else return ConnectionStopping
+			_ -> return ConnectionClosed
+	
+	send msg = atomically $ writeTChan ochan msg
+	
+	handlecontrol = do
+		msg <- atomically $ readTChan ichan
+		case msg of
+			STOP -> return ConnectionStopping
+			LOSTNET -> return ConnectionStopping
+			_ -> handlecontrol
+
+	handlepeer runst conn = do
+		v <- runNetProto runst conn P2P.notifyChange
+		case v of
+			Right (Just (ChangedRefs shas)) -> do
+				whenM (checkShouldFetch gc th shas) $
+					fetch
+				handlepeer runst conn
+			_ -> return ConnectionClosed
+	
+	fetch = do
+		send (SYNCING url)
+		ok <- inLocalRepo th $
+			runBool [Param "fetch", Param $ Git.repoDescribe r]
+		send (DONESYNCING url ok)
+
+torSocketFile :: Annex.Annex (Maybe FilePath)
+torSocketFile = do
+	u <- getUUID
+	let ident = fromUUID u
+#ifndef mingw32_HOST_OS
+	uid <- liftIO getRealUserID
+#else
+	let uid = 0
+#endif
+	liftIO $ getHiddenServiceSocketFile torAppName uid ident
+
+debugTor :: String -> IO ()
+debugTor = debug "RemoteDaemon.Transport.Tor"
diff --git a/RemoteDaemon/Types.hs b/RemoteDaemon/Types.hs
new file mode 100644
index 0000000000..a08cf39553
--- /dev/null
+++ b/RemoteDaemon/Types.hs
@@ -0,0 +1,112 @@
+{- git-remote-daemon data types.
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module RemoteDaemon.Types where
+
+import Common
+import qualified Annex
+import qualified Git.Types as Git
+import qualified Utility.SimpleProtocol as Proto
+import Types.GitConfig
+import Annex.ChangedRefs (ChangedRefs)
+import Utility.Url.Parse
+
+import Network.URI
+import Control.Concurrent
+import Control.Concurrent.STM
+
+-- The URI of a remote is used to uniquely identify it (names change..)
+newtype RemoteURI = RemoteURI URI
+	deriving (Show)
+
+-- A Transport for a particular git remote consumes some messages
+-- from a Chan, and emits others to another Chan.
+type Transport = RemoteRepo -> RemoteURI -> TransportHandle -> TChan Consumed -> TChan Emitted -> IO ()
+
+-- A server for a Transport consumes some messages from a Chan in
+-- order to learn about network changes, reloads, etc.
+type Server = TChan Consumed -> TransportHandle -> IO ()
+
+data RemoteRepo = RemoteRepo Git.Repo RemoteGitConfig
+newtype LocalRepo = LocalRepo Git.Repo
+
+-- All Transports share a single AnnexState MVar and an AnnexRead.
+--
+-- Different TransportHandles may have different versions of the LocalRepo.
+-- (For example, the ssh transport modifies it to enable ssh connection
+-- caching.)
+data TransportHandle = TransportHandle LocalRepo (MVar Annex.AnnexState) Annex.AnnexRead
+
+-- Messages that the daemon emits.
+data Emitted
+	= CONNECTED RemoteURI
+	| DISCONNECTED RemoteURI
+	| SYNCING RemoteURI
+	| DONESYNCING RemoteURI Bool
+	| WARNING RemoteURI String
+	deriving (Show)
+
+-- Messages that the daemon consumes.
+data Consumed
+	= PAUSE
+	| LOSTNET
+	| RESUME
+	| CHANGED ChangedRefs
+	| RELOAD
+	| STOP
+	deriving (Show)
+
+instance Proto.Sendable Emitted where
+	formatMessage (CONNECTED remote) =
+		["CONNECTED", Proto.serialize remote]
+	formatMessage (DISCONNECTED remote) =
+		["DISCONNECTED", Proto.serialize remote]
+	formatMessage (SYNCING remote) =
+		["SYNCING", Proto.serialize remote]
+	formatMessage (DONESYNCING remote status) =
+		["DONESYNCING", Proto.serialize remote, Proto.serialize status]
+	formatMessage (WARNING remote message) =
+		["WARNING", Proto.serialize remote, Proto.serialize message]
+
+instance Proto.Sendable Consumed where
+	formatMessage PAUSE = ["PAUSE"]
+	formatMessage LOSTNET = ["LOSTNET"]
+	formatMessage RESUME = ["RESUME"]
+	formatMessage (CHANGED refs) =["CHANGED", Proto.serialize refs]
+	formatMessage RELOAD = ["RELOAD"]
+	formatMessage STOP = ["STOP"]
+
+instance Proto.Receivable Emitted where
+	parseCommand "CONNECTED" = Proto.parse1 CONNECTED
+	parseCommand "DISCONNECTED" = Proto.parse1 DISCONNECTED
+	parseCommand "SYNCING" = Proto.parse1 SYNCING
+	parseCommand "DONESYNCING" = Proto.parse2 DONESYNCING
+	parseCommand "WARNING" = Proto.parse2 WARNING
+	parseCommand _ = Proto.parseFail
+
+instance Proto.Receivable Consumed where
+	parseCommand "PAUSE" = Proto.parse0 PAUSE
+	parseCommand "LOSTNET" = Proto.parse0 LOSTNET
+	parseCommand "RESUME" = Proto.parse0 RESUME
+	parseCommand "CHANGED" = Proto.parse1 CHANGED
+	parseCommand "RELOAD" = Proto.parse0 RELOAD
+	parseCommand "STOP" = Proto.parse0 STOP
+	parseCommand _ = Proto.parseFail
+
+instance Proto.Serializable RemoteURI where
+	serialize (RemoteURI u) = show u
+	deserialize = RemoteURI <$$> parseURIPortable
+
+instance Proto.Serializable Bool where
+	serialize False = "0"
+	serialize True = "1"
+
+	deserialize "0" = Just False
+	deserialize "1" = Just True
+	deserialize _ = Nothing
diff --git a/Setup.hs b/Setup.hs
new file mode 100644
index 0000000000..a92d784b44
--- /dev/null
+++ b/Setup.hs
@@ -0,0 +1,13 @@
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+{- cabal setup file -}
+
+import Distribution.Simple
+import qualified Build.Configure as Configure
+
+main :: IO ()
+main = defaultMainWithHooks simpleUserHooks
+	{ preConf = \_ _ -> do
+		Configure.run Configure.tests
+		return (Nothing, [])	
+	}
diff --git a/Test.hs b/Test.hs
new file mode 100644
index 0000000000..b752d4dc22
--- /dev/null
+++ b/Test.hs
@@ -0,0 +1,2119 @@
+{- git-annex test suite
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Test where
+
+import Types.Test
+import Types.RepoVersion
+import Types.Concurrency
+import Test.Framework
+
+import Test.Tasty
+import Test.Tasty.HUnit
+import Test.Tasty.QuickCheck
+import Options.Applicative.Types
+import Options.Applicative (switch, long, short, help, internal, maybeReader, option, metavar)
+
+import qualified Data.Map as M
+import qualified Data.ByteString.Lazy.UTF8 as BU8
+import Control.Concurrent.STM hiding (check)
+
+import Common
+import CmdLine.GitAnnex.Options
+import qualified Utility.RawFilePath as R
+import Data.String
+
+import qualified Utility.ShellEscape
+import qualified Annex
+import qualified Git.Quote
+import qualified Git.Types
+import qualified Git.Ref
+import qualified Git.LsTree
+import qualified Git.FilePath
+import qualified Annex.Locations
+#ifndef mingw32_HOST_OS
+import qualified Types.GitConfig
+#endif
+import qualified Types.TrustLevel
+import qualified Types
+import qualified Logs.MapLog
+import qualified Logs.Trust
+import qualified Logs.Remote
+import qualified Logs.Unused
+import qualified Logs.Transfer
+import qualified Logs.Presence
+import qualified Logs.ContentIdentifier
+import qualified Logs.PreferredContent
+import qualified Types.MetaData
+import qualified Remote
+import qualified Key
+import qualified Config
+import qualified Config.Cost
+import qualified Crypto
+import qualified Database.Keys
+import qualified Annex.WorkTree
+import qualified Annex.CatFile
+import qualified Annex.VectorClock
+import qualified Annex.VariantFile
+import qualified Annex.View
+import qualified Annex.View.ViewedFile
+import qualified Logs.View
+import qualified Command.TestRemote
+import qualified Utility.Path.Tests
+import qualified Utility.FileMode
+import qualified BuildInfo
+import qualified Utility.Format
+import qualified Utility.Verifiable
+import qualified Utility.Process
+import qualified Utility.Misc
+import qualified Utility.InodeCache
+import qualified Utility.Matcher
+import qualified Utility.Hash
+import qualified Utility.Scheduled
+import qualified Utility.Scheduled.QuickCheck
+import qualified Utility.HumanTime
+import qualified Utility.Tmp.Dir
+import qualified Utility.FileSystemEncoding
+import qualified Utility.Aeson
+import qualified Utility.CopyFile
+import qualified Utility.MoveFile
+import qualified Utility.StatelessOpenPGP
+import qualified Types.Remote
+#ifndef mingw32_HOST_OS
+import qualified Remote.Helper.Encryptable
+import qualified Types.Crypto
+import qualified Utility.Gpg
+#endif
+
+optParser :: Parser TestOptions
+optParser = TestOptions
+	<$> snd (tastyParser (tests 1 False True (TestOptions mempty False False Nothing mempty False mempty)))
+	<*> switch
+		( long "keep-failures"
+		<> help "preserve repositories on test failure"
+		)
+	<*> switch
+		( long "fakessh"
+		<> internal
+		)
+	<*> optional (option (maybeReader parseConcurrency)
+		( long "jobs"
+		<> short 'J'
+		<> help "number of concurrent jobs"
+		))
+	<*> many (option (maybeReader parseconfigvalue)
+		( long "test-git-config"
+		<> help "run tests with a git config set"
+		<> metavar "NAME=VALUE"
+		))
+	<*> switch
+		( long "test-debug"
+		<> help "show debug messages for commands run by test suite"
+		)
+	<*> cmdParams "non-options are for internal use only"
+  where
+	parseconfigvalue s = case break (== '=') s of
+		(_, []) -> Nothing
+		(k, v) -> Just 
+			( Git.Types.ConfigKey (encodeBS k)
+			, Git.Types.ConfigValue (encodeBS (drop 1 v))
+			)
+
+runner :: TestOptions -> IO ()
+runner opts = parallelTestRunner opts tests
+
+tests :: Int -> Bool -> Bool -> TestOptions -> [TestTree]
+tests numparts crippledfilesystem adjustedbranchok opts = 
+	properties 
+		: withTestMode remotetestmode testRemotes
+		: concatMap mkrepotests testmodes
+  where
+	testmodes = catMaybes
+		[ canadjust ("v10 adjusted unlocked branch", (testMode opts (RepoVersion 10)) { adjustedUnlockedBranch = True })
+		, unlesscrippled ("v10 unlocked", (testMode opts (RepoVersion 10)) { unlockedFiles = True })
+		, unlesscrippled ("v10 locked", testMode opts (RepoVersion 10))
+		]
+	remotetestmode = testMode opts (RepoVersion 8)
+	unlesscrippled v
+		| crippledfilesystem = Nothing
+		| otherwise = Just v
+	canadjust v
+		| adjustedbranchok = Just v
+		| otherwise = Nothing
+	mkrepotests (d, te) = map 
+		(\uts -> withTestMode te uts)
+		(repoTests d numparts)
+
+properties :: TestTree
+properties = localOption (QuickCheckTests 1000) $ testGroup "QuickCheck" $
+	[ testProperty "prop_quote_unquote_roundtrip" Git.Quote.prop_quote_unquote_roundtrip
+	, testProperty "prop_encode_c_decode_c_roundtrip" Utility.Format.prop_encode_c_decode_c_roundtrip
+	, testProperty "prop_isomorphic_key_encode" Key.prop_isomorphic_key_encode
+	, testProperty "prop_isomorphic_shellEscape" Utility.ShellEscape.prop_isomorphic_shellEscape
+	, testProperty "prop_isomorphic_shellEscape_multiword" Utility.ShellEscape.prop_isomorphic_shellEscape_multiword
+	, testProperty "prop_isomorphic_configEscape" Logs.Remote.prop_isomorphic_configEscape
+	, testProperty "prop_parse_show_Config" Logs.Remote.prop_parse_show_Config
+	, testProperty "prop_upFrom_basics" Utility.Path.Tests.prop_upFrom_basics
+	, testProperty "prop_relPathDirToFileAbs_basics" Utility.Path.Tests.prop_relPathDirToFileAbs_basics
+	, testProperty "prop_relPathDirToFileAbs_regressionTest" Utility.Path.Tests.prop_relPathDirToFileAbs_regressionTest
+	, testProperty "prop_dirContains_regressionTest" Utility.Path.Tests.prop_dirContains_regressionTest
+	, testProperty "prop_cost_sane" Config.Cost.prop_cost_sane
+	, testProperty "prop_matcher_sane" Utility.Matcher.prop_matcher_sane
+	, testProperty "prop_HmacSha1WithCipher_sane" Crypto.prop_HmacSha1WithCipher_sane
+	, testProperty "prop_VectorClock_sane" Annex.VectorClock.prop_VectorClock_sane
+	, testProperty "prop_addMapLog_sane" Logs.MapLog.prop_addMapLog_sane
+	, testProperty "prop_verifiable_sane" Utility.Verifiable.prop_verifiable_sane
+	, testProperty "prop_segment_regressionTest" Utility.Misc.prop_segment_regressionTest
+	, testProperty "prop_read_write_transferinfo" Logs.Transfer.prop_read_write_transferinfo
+	, testProperty "prop_read_show_inodecache" Utility.InodeCache.prop_read_show_inodecache
+	, testProperty "prop_parse_build_presence_log" Logs.Presence.prop_parse_build_presence_log
+	, testProperty "prop_parse_build_contentidentifier_log" Logs.ContentIdentifier.prop_parse_build_contentidentifier_log
+	, testProperty "prop_read_show_TrustLevel" Types.TrustLevel.prop_read_show_TrustLevel
+	, testProperty "prop_parse_build_TrustLevelLog" Logs.Trust.prop_parse_build_TrustLevelLog
+	, testProperty "prop_schedule_roundtrips" Utility.Scheduled.QuickCheck.prop_schedule_roundtrips
+	, testProperty "prop_past_sane" Utility.Scheduled.prop_past_sane
+	, testProperty "prop_duration_roundtrips" Utility.HumanTime.prop_duration_roundtrips
+	, testProperty "prop_metadata_sane" Types.MetaData.prop_metadata_sane
+	, testProperty "prop_metadata_serialize" Types.MetaData.prop_metadata_serialize
+	, testProperty "prop_branchView_legal" Logs.View.prop_branchView_legal
+	, testProperty "prop_viewPath_roundtrips" Annex.View.prop_viewPath_roundtrips
+	, testProperty "prop_view_roundtrips" Annex.View.prop_view_roundtrips
+	, testProperty "prop_viewedFile_rountrips" Annex.View.ViewedFile.prop_viewedFile_roundtrips
+	, testProperty "prop_standardGroups_parse" Logs.PreferredContent.prop_standardGroups_parse
+	] ++ map (uncurry testProperty) combos
+  where
+	combos = concat
+		[ Utility.Hash.props_hashes_stable
+		, Utility.Hash.props_macs_stable
+		]
+
+testRemotes :: TestTree
+testRemotes = testGroup "Remote Tests" $
+	-- These tests are failing in really strange ways on Windows,
+	-- apparently not due to an actual problem with the remotes being
+	-- tested, so are disabled there.
+#ifdef mingw32_HOST_OS
+	filter (\_ -> False)
+#endif
+	[ testGitRemote
+	, testDirectoryRemote
+	]
+
+testGitRemote :: TestTree
+testGitRemote = testRemote False "git" $ \remotename -> do
+	git "clone" [".", "remotedir"] "git clone"
+	git "remote" ["add", remotename, "remotedir"] "git remote add"
+
+testDirectoryRemote :: TestTree
+testDirectoryRemote = testRemote True "directory" $ \remotename -> do
+	createDirectory "remotedir"
+	git_annex "initremote"
+		[ remotename
+		, "type=directory"
+		, "--quiet"
+		, "directory=remotedir"
+		, "encryption=none"
+		] "init"
+
+testRemote :: Bool -> String -> (String -> IO ()) -> TestTree
+testRemote testvariants remotetype setupremote = 
+	withResource newEmptyTMVarIO (const noop) $ \getv -> 
+		testGroup ("testremote type " ++ remotetype) $ concat
+			[ [testCase "init" (prep getv)]
+			, go getv
+			]
+  where
+	reponame = "test repo"
+	remotename = "testremote"
+	basesz = 1024 * 1024
+	keysizes = Command.TestRemote.keySizes basesz False
+	prep getv = do
+		d <- newmainrepodir
+		setmainrepodir d
+		innewrepo $ do
+			git_annex "init" [reponame, "--quiet"] "init"
+			setupremote remotename
+			r <- annexeval $ either giveup return 
+				=<< Remote.byName' remotename
+			cache <- Command.TestRemote.newRemoteVariantCache
+			unavailr <- annexeval $ Types.Remote.mkUnavailable r
+			exportr <- annexeval $ Command.TestRemote.exportTreeVariant cache r
+			ks <- annexeval $ mapM Command.TestRemote.randKey keysizes
+			v <- getv
+			cv <- annexeval cache
+			liftIO $ atomically $ putTMVar v
+				(r, (unavailr, (exportr, (ks, cv))))
+	go getv = Command.TestRemote.mkTestTrees runannex mkrs mkunavailr mkexportr mkks
+	  where
+		runannex = inmainrepo . annexeval
+		mkrs = if testvariants
+			then Command.TestRemote.remoteVariants cache mkr basesz False
+			else [fmap (fmap Just) mkr]
+		mkr = descas (remotetype ++ " remote") (fst <$> v)
+		mkunavailr = fst . snd <$> v
+		mkexportr = fst . snd . snd <$> v
+		mkks = map (\(sz, n) -> desckeysize sz (getk n))
+			(zip keysizes [0..])
+		getk n = fmap (!! n) (fst . snd . snd . snd <$> v)
+		cache = snd . snd . snd . snd <$> v
+		v = liftIO $ atomically . readTMVar =<< getv
+		descas = Command.TestRemote.Described
+		desckeysize sz = descas ("key size " ++ show sz)
+
+{- These tests set up the test environment, but also test some basic parts
+ - of git-annex. They are always run before the repoTests. -}
+initTests :: TestTree
+initTests = testGroup initTestsName
+	[ testCase "init" test_init
+	, testCase "add" test_add
+	]
+
+repoTests :: String -> Int -> [TestTree]
+repoTests note numparts = map mk $ sep
+	[ testCase "add dup" test_add_dup
+	, testCase "add extras" test_add_extras
+	, testCase "add moved link" test_add_moved
+	, testCase "readonly remote" test_readonly_remote
+	, testCase "ignore deleted files" test_ignore_deleted_files
+	, testCase "metadata" test_metadata
+	, testCase "export and import" test_export_import
+	, testCase "export and import of subdir" test_export_import_subdir
+	, testCase "shared clone" test_shared_clone
+	, testCase "log" test_log
+	, testCase "view" test_view
+	, testCase "magic" test_magic
+	, testCase "import" test_import
+	, testCase "reinject" test_reinject
+	, testCase "unannex (no copy)" test_unannex_nocopy
+	, testCase "unannex (with copy)" test_unannex_withcopy
+	, testCase "drop (no remote)" test_drop_noremote
+	, testCase "drop (with remote)" test_drop_withremote
+	, testCase "drop (untrusted remote)" test_drop_untrustedremote
+	, testCase "get" test_get
+	, testCase "get (ssh remote)" test_get_ssh_remote
+	, testCase "move" test_move
+	, testCase "move (ssh remote)" test_move_ssh_remote
+	, testCase "move (numcopies)" test_move_numcopies
+	, testCase "copy" test_copy
+	, testCase "lock" test_lock
+	, testCase "lock --force" test_lock_force
+	, testCase "edit (no pre-commit)" test_edit
+	, testCase "edit (pre-commit)" test_edit_precommit
+	, testCase "partial commit" test_partial_commit
+	, testCase "fix" test_fix
+	, testCase "trust" test_trust
+	, testCase "fsck (basics)" test_fsck_basic
+	, testCase "fsck (bare)" test_fsck_bare
+	, testCase "fsck (local untrusted)" test_fsck_localuntrusted
+	, testCase "fsck (remote untrusted)" test_fsck_remoteuntrusted
+	, testCase "fsck --from remote" test_fsck_fromremote
+	, testCase "conversion git to annexed" test_conversion_git_to_annexed
+	, testCase "conversion annexed to git" test_conversion_annexed_to_git
+	, testCase "migrate" test_migrate
+	, testCase "migrate (via gitattributes)" test_migrate_via_gitattributes
+	, testCase "unused" test_unused
+	, testCase "describe" test_describe
+	, testCase "find" test_find
+	, testCase "merge" test_merge
+	, testCase "info" test_info
+	, testCase "version" test_version
+	, testCase "sync" test_sync
+	, testCase "concurrent get of dup key regression" test_concurrent_get_of_dup_key_regression
+	, testCase "union merge regression" test_union_merge_regression
+	, testCase "adjusted branch merge regression" test_adjusted_branch_merge_regression
+	, testCase "adjusted branch subtree regression" test_adjusted_branch_subtree_regression
+	, testCase "transition propagation" test_transition_propagation_reversion
+	, testCase "conflict resolution" test_conflict_resolution
+	, testCase "conflict resolution (adjusted branch)" test_conflict_resolution_adjusted_branch
+	, testCase "conflict resolution movein regression" test_conflict_resolution_movein_regression
+	, testCase "conflict resolution (mixed directory and file)" test_mixed_conflict_resolution
+	, testCase "conflict resolution symlink bit" test_conflict_resolution_symlink_bit
+	, testCase "conflict resolution (uncommitted local file)" test_uncommitted_conflict_resolution
+	, testCase "conflict resolution (removed file)" test_remove_conflict_resolution
+	, testCase "conflict resolution (nonannexed file)" test_nonannexed_file_conflict_resolution
+	, testCase "conflict resolution (nonannexed symlink)" test_nonannexed_symlink_conflict_resolution
+	, testCase "conflict resolution (mixed locked and unlocked file)" test_mixed_lock_conflict_resolution
+	, testCase "map" test_map
+	, testCase "uninit" test_uninit
+	, testCase "uninit (in git-annex branch)" test_uninit_inbranch
+	, testCase "upgrade" test_upgrade
+	, testCase "whereis" test_whereis
+	, testCase "hook remote" test_hook_remote
+	, testCase "directory remote" test_directory_remote
+	, testCase "rsync remote" test_rsync_remote
+	, testCase "bup remote" test_bup_remote
+	, testCase "borg remote" test_borg_remote
+	, testCase "gpg crypto" test_gpg_crypto
+	, testCase "sop crypto" test_sop_crypto
+	, testCase "preferred content" test_preferred_content
+	, testCase "required_content" test_required_content
+	, testCase "add subdirs" test_add_subdirs
+	, testCase "addurl" test_addurl
+	, testCase "repair" test_repair
+	]
+  where
+	mk l = testGroup groupname (initTests : map adddep l)
+	adddep = Test.Tasty.after AllSucceed (groupname ++ "." ++ initTestsName)
+	groupname = "Repo Tests " ++ note
+	sep l = 
+		-- Avoid separating into parts that contain less than
+		-- 5 tests each. Since the tests depend on the
+		-- initTests, this avoids spending too much work running
+		-- the initTests once per part.
+		let numparts' = if length l `div` numparts > 5
+			then numparts
+			else length l `div` 5
+		in sep' (replicate numparts' []) l
+	sep' (p:ps) (l:ls) = sep' (ps++[l:p]) ls
+	sep' ps [] = ps
+	sep' [] _ = []
+
+-- this test case creates the main repo
+test_init :: Assertion
+test_init = innewrepo $ do
+	ver <- annexVersion <$> getTestMode
+	git_annex "init" [reponame, "--version", show (fromRepoVersion ver)] "init"
+	setupTestMode
+  where
+	reponame = "test repo"
+
+-- this test case runs in the main repo, to set up a basic
+-- annexed file that later tests will use
+test_add :: Assertion
+test_add = inmainrepo $ do
+	writecontent annexedfile $ content annexedfile
+	add_annex annexedfile "add"
+	annexed_present annexedfile
+	writecontent sha1annexedfile $ content sha1annexedfile
+	git_annex "add" [sha1annexedfile, "--backend=SHA1"] "add with SHA1"
+	whenM (unlockedFiles <$> getTestMode) $
+		git_annex "unlock" [sha1annexedfile] "unlock"
+	annexed_present sha1annexedfile
+	checkbackend sha1annexedfile backendSHA1
+	writecontent ingitfile $ content ingitfile
+	git "add" [ingitfile] "git add"
+	git "commit" ["-q", "-m", "commit"] "git commit"
+	git_annex "add" [ingitfile] "add ingitfile should be no-op"
+	unannexed ingitfile
+
+test_add_dup :: Assertion
+test_add_dup = intmpclonerepo $ do
+	writecontent annexedfiledup $ content annexedfiledup
+	add_annex annexedfiledup "add of second file with same content failed"
+	annexed_present annexedfiledup
+	annexed_present annexedfile
+
+test_add_extras :: Assertion
+test_add_extras = intmpclonerepo $ do
+	writecontent wormannexedfile $ content wormannexedfile
+	git_annex "add" [wormannexedfile, "--backend=WORM"] "add with WORM"
+	whenM (unlockedFiles <$> getTestMode) $
+		git_annex "unlock" [wormannexedfile] "unlock"
+	annexed_present wormannexedfile
+	checkbackend wormannexedfile backendWORM
+
+test_add_moved :: Assertion
+test_add_moved = intmpclonerepo $ do
+	git_annex "get" [annexedfile] "get failed"
+	annexed_present annexedfile
+	createDirectory subdir
+	Utility.MoveFile.moveFile (toRawFilePath annexedfile) (toRawFilePath subfile)
+	git_annex "add" [subdir] "add of moved annexed file"
+	git "mv" [sha1annexedfile, sha1annexedfile ++ ".renamed"] "git mv"
+	git_annex "add" [] "add does not fail on deleted file after move"
+  where
+	subdir = "subdir"
+	subfile = subdir </> "file"
+
+test_readonly_remote :: Assertion
+test_readonly_remote =
+#ifndef mingw32_HOST_OS
+	withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 -> do
+			pair r1 r2
+			indir r1 $ do
+				git_annex "get" [annexedfile] "get failed in first repo"
+			make_readonly r1
+			indir r2 $ do
+				git_annex "sync" ["r1", "--no-push", "--no-content"] "sync with readonly repo"
+				git_annex "get" [annexedfile, "--from", "r1"] "get from readonly repo"
+				git "remote" ["rm", "origin"] "remote rm"
+				git_annex "drop" [annexedfile] "drop vs readonly repo"
+#else
+	-- This test does not work on Windows, and it doesn't make sense to
+	-- try to support this on Windows anyway.
+	return ()
+#endif
+
+test_ignore_deleted_files :: Assertion
+test_ignore_deleted_files = intmpclonerepo $ do
+	git_annex "get" [annexedfile] "get"
+	git_annex_expectoutput "find" [] [annexedfile]
+	removeWhenExistsWith R.removeLink (toRawFilePath annexedfile)
+	-- A file that has been deleted, but the deletion not staged,
+	-- is a special case; make sure git-annex skips these.
+	git_annex_expectoutput "find" [] []
+
+test_metadata :: Assertion
+test_metadata = intmpclonerepo $ do
+	git_annex "metadata" ["-s", "foo=bar", annexedfile] "set metadata"
+	git_annex_expectoutput "find" ["--metadata", "foo=bar"] [annexedfile]
+	git_annex_expectoutput "find" ["--metadata", "foo=other"] []
+	readonly_query $ do
+		git_annex_expectoutput "find" ["--metadata", "foo=bar"] [annexedfile]
+		git_annex_expectoutput "find" ["--metadata", "foo=other"] []
+	writecontent annexedfiledup $ content annexedfiledup
+	add_annex annexedfiledup "add of second file with same content failed"
+	annexed_present annexedfiledup
+	git_annex_expectoutput "find" ["--metadata", "foo=bar"]
+		[annexedfile, annexedfiledup]
+	git_annex_shouldfail "metadata" ["--remove", "foo", "."]
+		"removing metadata from dir with multiple files not allowed"
+	git_annex "metadata" ["--remove", "foo", annexedfile]
+		"removing metadata"
+	git_annex_expectoutput "find" ["--metadata", "foo=bar"] []
+	git_annex "metadata" ["--force", "-s", "foo=bar", "."]
+		"recursively set metadata force"
+
+test_shared_clone :: Assertion
+test_shared_clone = intmpsharedclonerepo $ do
+	v <- catchMaybeIO $ Utility.Process.readProcess "git" 
+		[ "config"
+		, "--bool"
+		, "--get"
+		, "annex.hardlink"
+		]
+	v == Just "true\n"
+		@? "shared clone of repo did not get annex.hardlink set"
+
+test_log :: Assertion
+test_log = intmpclonerepo $ do
+	git_annex "log" [annexedfile] "log"
+
+test_view :: Assertion
+test_view = intmpclonerepo $ do
+	git_annex "metadata" ["-s", "test=test1", annexedfile]  "metadata"
+	git_annex "metadata" ["-s", "test=test2", sha1annexedfile] "metadata"
+	git_annex "view" ["test=test1"] "entering view"
+	checkexists annexedfile
+	checkdoesnotexist sha1annexedfile
+
+test_magic :: Assertion
+test_magic = intmpclonerepo $ do
+#ifdef WITH_MAGICMIME
+	git "config" ["annex.largefiles", "mimeencoding=binary"]
+		"git config annex.largefiles"
+	writeFile "binary" "\127"
+	writeFile "text" "test\n" 
+	git_annex "add" ["binary", "text"]
+		"git-annex add with mimeencoding in largefiles"
+	git_annex "sync" ["--no-content"]
+		"git-annex sync"
+	(isJust <$> annexeval (Annex.CatFile.catKeyFile (encodeBS "binary")))
+		@? "binary file not added to annex despite mimeencoding config"
+	(isNothing <$> annexeval (Annex.CatFile.catKeyFile (encodeBS "text")))
+		@? "non-binary file got added to annex despite mimeencoding config"
+#else
+	return ()
+#endif
+
+test_import :: Assertion
+test_import = intmpclonerepo $ Utility.Tmp.Dir.withTmpDir "importtest" $ \importdir -> do
+	(toimport1, importf1, imported1) <- mktoimport importdir "import1"
+	git_annex "import" [toimport1] "import"
+	annexed_present_imported imported1
+	checkdoesnotexist importf1
+
+	(toimport2, importf2, imported2) <- mktoimport importdir "import2"
+	git_annex "import" [toimport2] "import of duplicate"
+	annexed_present_imported imported2
+	checkdoesnotexist importf2
+
+	(toimport3, importf3, imported3) <- mktoimport importdir "import3"
+	git_annex "import" ["--skip-duplicates", toimport3]
+		"import of duplicate with --skip-duplicates"
+	checkdoesnotexist imported3
+	checkexists importf3
+	git_annex "import" ["--clean-duplicates", toimport3]
+		"import of duplicate with --clean-duplicates"
+	checkdoesnotexist imported3
+	checkdoesnotexist importf3
+	
+	(toimport4, importf4, imported4) <- mktoimport importdir "import4"
+	git_annex "import" ["--deduplicate", toimport4] "import --deduplicate"
+	checkdoesnotexist imported4
+	checkdoesnotexist importf4
+	
+	(toimport5, importf5, imported5) <- mktoimport importdir "import5"
+	git_annex "import" ["--duplicate", toimport5] "import --duplicate"
+	annexed_present_imported imported5
+	checkexists importf5
+	
+	git_annex "drop" ["--force", imported1, imported2, imported5] "drop"
+	annexed_notpresent_imported imported2
+	(toimportdup, importfdup, importeddup) <- mktoimport importdir "importdup"
+	git_annex_shouldfail "import" ["--clean-duplicates", toimportdup] 
+		"import of missing duplicate with --clean-duplicates not allowed"
+	checkdoesnotexist importeddup
+	checkexists importfdup
+  where
+	mktoimport importdir subdir = do
+		createDirectory (importdir </> subdir)
+		let importf = subdir </> "f"
+		writecontent (importdir </> importf) (content importf)
+		return (importdir </> subdir, importdir </> importf, importf)
+
+test_reinject :: Assertion
+test_reinject = intmpclonerepo $ do
+	git_annex "drop" ["--force", sha1annexedfile] "drop"
+	annexed_notpresent sha1annexedfile
+	writecontent tmp $ content sha1annexedfile
+	key <- Key.serializeKey <$> getKey backendSHA1 tmp
+	git_annex "reinject" [tmp, sha1annexedfile] "reinject"
+	annexed_present sha1annexedfile
+	git_annex "fromkey" [key, sha1annexedfiledup] "fromkey for dup"
+	whenM (unlockedFiles <$> getTestMode) $
+		git_annex "unlock" [sha1annexedfiledup] "unlock"
+	annexed_present sha1annexedfiledup
+  where
+	tmp = "tmpfile"
+
+test_unannex_nocopy :: Assertion
+test_unannex_nocopy = intmpclonerepo $ do
+	annexed_notpresent annexedfile
+	git_annex "unannex" [annexedfile] "unannex with no copy"
+	annexed_notpresent annexedfile
+
+test_unannex_withcopy :: Assertion
+test_unannex_withcopy = intmpclonerepo $ do
+	git_annex "get" [annexedfile] "get"
+	annexed_present annexedfile
+	git_annex "unannex" [annexedfile, sha1annexedfile] "unannex"
+	unannexed annexedfile
+	git_annex "unannex" [ingitfile] "unannex ingitfile should be no-op"
+	unannexed ingitfile
+
+test_drop_noremote :: Assertion
+test_drop_noremote = intmpclonerepo $ do
+	git_annex "get" [annexedfile] "get"
+	git "remote" ["rm", "origin"] "git remote rm origin"
+	git_annex_shouldfail "drop" [annexedfile] "drop with no known copy of file not allowed"
+	annexed_present annexedfile
+	git_annex "drop" ["--force", annexedfile] "drop --force"
+	annexed_notpresent annexedfile
+	git_annex "drop" [annexedfile] "drop of dropped file"
+	git_annex "drop" [ingitfile] "drop ingitfile should be no-op"
+	unannexed ingitfile
+
+test_drop_withremote :: Assertion
+test_drop_withremote = intmpclonerepo $ do
+	git_annex "get" [annexedfile] "get"
+	annexed_present annexedfile
+	git_annex "numcopies" ["2"] "numcopies config"
+	git_annex_shouldfail "drop" [annexedfile] "drop with numcopies not satisfied is not allowed"
+	git_annex "numcopies" ["1"] "numcopies config"
+	git_annex "drop" [annexedfile] "drop when origin has copy"
+	annexed_notpresent annexedfile
+	-- make sure that the correct symlink is staged for the file
+	-- after drop
+	git_annex_expectoutput "status" [] []
+	inmainrepo $ annexed_present annexedfile
+
+test_drop_untrustedremote :: Assertion
+test_drop_untrustedremote = intmpclonerepo $ do
+	git_annex "untrust" ["origin"] "untrust of origin"
+	git_annex "get" [annexedfile] "get"
+	annexed_present annexedfile
+	git_annex_shouldfail "drop" [annexedfile] "drop with only an untrusted copy of the file should fail"
+	annexed_present annexedfile
+	inmainrepo $ annexed_present annexedfile
+
+test_get :: Assertion
+test_get = test_get' intmpclonerepo
+
+test_get_ssh_remote :: Assertion
+test_get_ssh_remote = 
+#ifndef mingw32_HOST_OS
+	test_get' (with_ssh_origin intmpclonerepo)
+#else
+	noop
+#endif
+
+test_get' :: (Assertion -> Assertion) -> Assertion
+test_get' setup = setup $ do
+	inmainrepo $ annexed_present annexedfile
+	annexed_notpresent annexedfile
+	git_annex "get" [annexedfile] "get of file"
+	inmainrepo $ annexed_present annexedfile
+	annexed_present annexedfile
+	git_annex "get" [annexedfile] "get of file already here"
+	inmainrepo $ annexed_present annexedfile
+	annexed_present annexedfile
+	inmainrepo $ unannexed ingitfile
+	unannexed ingitfile
+	git_annex "get" [ingitfile] "get ingitfile should be no-op"
+	inmainrepo $ unannexed ingitfile
+	unannexed ingitfile
+
+test_move :: Assertion
+test_move = test_move' intmpclonerepo
+
+test_move_ssh_remote :: Assertion
+test_move_ssh_remote =
+#ifndef mingw32_HOST_OS
+	test_move' (with_ssh_origin intmpclonerepo)
+#else
+	noop
+#endif
+
+test_move' :: (Assertion -> Assertion) -> Assertion
+test_move' setup = setup $ do
+	annexed_notpresent annexedfile
+	inmainrepo $ annexed_present annexedfile
+	git_annex "move" ["--from", "origin", annexedfile] "move --from of file"
+	annexed_present annexedfile
+	inmainrepo $ annexed_notpresent annexedfile
+	git_annex "move" ["--from", "origin", annexedfile] "move --from of file already here"
+	annexed_present annexedfile
+	inmainrepo $ annexed_notpresent annexedfile
+	git_annex "move" ["--to", "origin", annexedfile] "move --to of file"
+	inmainrepo $ annexed_present annexedfile
+	annexed_notpresent annexedfile
+	git_annex "move" ["--to", "origin", annexedfile] "move --to of file already there"
+	inmainrepo $ annexed_present annexedfile
+	annexed_notpresent annexedfile
+	unannexed ingitfile
+	inmainrepo $ unannexed ingitfile
+	git_annex "move" ["--to", "origin", ingitfile] "move of ingitfile should be no-op"
+	unannexed ingitfile
+	inmainrepo $ unannexed ingitfile
+	git_annex "move" ["--from", "origin", ingitfile] "move of ingitfile should be no-op"
+	unannexed ingitfile
+	inmainrepo $ unannexed ingitfile
+
+test_move_numcopies :: Assertion
+test_move_numcopies = intmpclonerepo $ do
+	inmainrepo $ annexed_present annexedfile
+	git_annex "numcopies" ["2"] "setting numcopies"
+	git_annex "move" ["--from", "origin", annexedfile] "move of file --from remote with numcopies unsatisfied but not made worse"
+	annexed_present annexedfile
+	inmainrepo $ annexed_notpresent annexedfile
+	git_annex "move" ["--to", "origin", annexedfile] "move of file --to remote with numcopies unsatisfied but not made worse"
+	annexed_notpresent annexedfile
+	inmainrepo $ annexed_present annexedfile
+	git_annex "get" [annexedfile] "get of file"
+	git_annex_shouldfail "move" ["--from", "origin", annexedfile] "move of file --from remote that violates numcopies setting not allowed"
+	git_annex_shouldfail "move" ["--to", "origin", annexedfile] "move of file --to remote that violates numcopies setting not allowed"
+
+test_copy :: Assertion
+test_copy = intmpclonerepo $ do
+	annexed_notpresent annexedfile
+	inmainrepo $ annexed_present annexedfile
+	git_annex "copy" ["--from", "origin", annexedfile] "copy --from of file"
+	annexed_present annexedfile
+	inmainrepo $ annexed_present annexedfile
+	git_annex "copy" ["--from", "origin", annexedfile] "copy --from of file already here"
+	annexed_present annexedfile
+	inmainrepo $ annexed_present annexedfile
+	git_annex "copy" ["--to", "origin", annexedfile] "copy --to of file already there"
+	annexed_present annexedfile
+	inmainrepo $ annexed_present annexedfile
+	git_annex "move" ["--to", "origin", annexedfile] "move --to of file already there"
+	annexed_notpresent annexedfile
+	inmainrepo $ annexed_present annexedfile
+	unannexed ingitfile
+	inmainrepo $ unannexed ingitfile
+	git_annex "copy" ["--to", "origin", ingitfile] "copy of ingitfile should be no-op"
+	unannexed ingitfile
+	inmainrepo $ unannexed ingitfile
+	git_annex "copy" ["--from", "origin", ingitfile] "copy of ingitfile should be no-op"
+	checkregularfile ingitfile
+	checkcontent ingitfile
+
+test_preferred_content :: Assertion
+test_preferred_content = intmpclonerepo $ do
+	annexed_notpresent annexedfile
+	-- get/copy --auto looks only at numcopies when preferred content is not
+	-- set, and with 1 copy existing, does not get the file.
+	git_annex "get" ["--auto", annexedfile] "get --auto of file with default preferred content"
+	annexed_notpresent annexedfile
+	git_annex "copy" ["--from", "origin", "--auto", annexedfile] "copy --auto --from of file with default preferred content"
+	annexed_notpresent annexedfile
+
+	git_annex "wanted" [".", "standard"] "set expression to standard"
+	git_annex "group" [".", "client"] "set group to standard"
+	git_annex "get" ["--auto", annexedfile] "get --auto of file for client"
+	annexed_present annexedfile
+	git_annex "drop" [annexedfile] "drop of file"
+	git_annex "copy" ["--from", "origin", "--auto", annexedfile] "copy --auto --from of file for client"
+	annexed_present annexedfile
+	git_annex "ungroup" [".", "client"] "ungroup"
+
+	git_annex "wanted" [".", "standard"] "set expression to standard"
+	git_annex "group" [".", "manual"] "set group to manual"
+	-- drop --auto with manual leaves the file where it is
+	git_annex "drop" ["--auto", annexedfile] "drop --auto of file with manual preferred content"
+	annexed_present annexedfile
+	git_annex "drop" [annexedfile] "drop of file"
+	annexed_notpresent annexedfile
+	-- copy/get --auto with manual does not get the file
+	git_annex "get" ["--auto", annexedfile] "get --auto of file with manual preferred content"
+	annexed_notpresent annexedfile
+	git_annex "copy" ["--from", "origin", "--auto", annexedfile] "copy --auto --from of file with manual preferred content"
+	annexed_notpresent annexedfile
+	git_annex "ungroup" [".", "client"] "ungroup"
+	
+	git_annex "wanted" [".", "exclude=*"] "set expression to exclude=*"
+	git_annex "get" [annexedfile] "get of file"
+	annexed_present annexedfile
+	git_annex "drop" ["--auto", annexedfile] "drop --auto of file with exclude=*"
+	annexed_notpresent annexedfile
+	git_annex "get" ["--auto", annexedfile] "get --auto of file with exclude=*"
+	annexed_notpresent annexedfile
+
+test_required_content :: Assertion
+test_required_content = intmpclonerepo $ do
+	git_annex "get" [annexedfile] "get"
+	annexed_present annexedfile
+	git_annex "required" [".", "include=" ++ annexedfile] "annexedfile required"
+
+	git_annex_shouldfail "drop" [annexedfile] "drop of required content should fail"
+	annexed_present annexedfile
+
+	git_annex "drop" ["--auto", annexedfile] "drop --auto of required content skips it"
+	annexed_present annexedfile
+	
+	writecontent annexedfiledup $ content annexedfiledup
+	add_annex annexedfiledup "add of second file with same content failed"
+	annexed_present annexedfiledup
+	annexed_present annexedfile
+
+	git_annex_shouldfail "drop" [annexedfiledup] "drop of file sharing required content should fail"
+	annexed_present annexedfiledup
+	annexed_present annexedfile
+
+test_lock :: Assertion
+test_lock = intmpclonerepo $ do
+	annexed_notpresent annexedfile
+
+	-- regression test: unlock of newly added, not committed file
+	-- should not fail.
+	writecontent "newfile" "foo"
+	git_annex "add" ["newfile"] "add new file"
+	git_annex "unlock" ["newfile"] "unlock on newly added, never committed file"
+
+	git_annex "get" [annexedfile] "get of file"
+	annexed_present annexedfile
+	git_annex "unlock" [annexedfile] "unlock"
+	unannexed annexedfile
+	-- write different content, to verify that lock
+	-- throws it away
+	changecontent annexedfile
+	writecontent annexedfile $ content annexedfile ++ "foo"
+	git_annex_shouldfail "lock" [annexedfile] "lock without --force should not be allowed"
+	git_annex "lock" ["--force", annexedfile] "lock --force"
+	-- The original content of an unlocked file is not always
+	-- preserved after modification, so re-get it.
+	git_annex "get" [annexedfile] "get of file after lock --force"
+	annexed_present_locked annexedfile
+	git_annex "unlock" [annexedfile] "unlock"
+	unannexed annexedfile
+	changecontent annexedfile
+	git "add" [annexedfile] "add of modified file"
+	runchecks [checkregularfile, checkwritable] annexedfile
+	c <- readFile annexedfile
+	assertEqual "content of modified file" c (changedcontent annexedfile)
+	git_annex_shouldfail "drop" [annexedfile]
+		"drop with no known copy of modified file should not be allowed"
+
+-- Regression test: lock --force when work tree file
+-- was modified lost the (unmodified) annex object.
+-- (Only occurred when the keys database was out of sync.)
+test_lock_force :: Assertion
+test_lock_force = intmpclonerepo $ do
+	git_annex "upgrade" [] "upgrade"
+	git_annex "get" [annexedfile] "get of file"
+	git_annex "unlock" [annexedfile] "unlock"
+	annexeval $ do
+		Just k <- Annex.WorkTree.lookupKey (toRawFilePath annexedfile)
+		Database.Keys.removeInodeCaches k
+		Database.Keys.closeDb
+		liftIO . removeWhenExistsWith R.removeLink
+			=<< Annex.calcRepo' Annex.Locations.gitAnnexKeysDbIndexCache
+	writecontent annexedfile "test_lock_force content"
+	git_annex_shouldfail "lock" [annexedfile] "lock of modified file should not be allowed"
+	git_annex "lock" ["--force", annexedfile] "lock --force of modified file"
+	annexed_present_locked annexedfile
+
+test_edit :: Assertion
+test_edit = test_edit' False
+
+test_edit_precommit :: Assertion
+test_edit_precommit = test_edit' True
+
+test_edit' :: Bool -> Assertion
+test_edit' precommit = intmpclonerepo $ do
+	git_annex "get" [annexedfile] "get of file"
+	annexed_present annexedfile
+	git_annex "edit" [annexedfile] "edit"
+	unannexed annexedfile
+	changecontent annexedfile
+	git "add" [annexedfile] "git add of edited file"
+	if precommit
+		then git_annex "pre-commit" [] "pre-commit"
+		else git "commit" ["-q", "-m", "contentchanged"] "git commit of edited file"
+	runchecks [checkregularfile, checkwritable] annexedfile
+	c <- readFile annexedfile
+	assertEqual "content of modified file" c (changedcontent annexedfile)
+	git_annex_shouldfail "drop" [annexedfile] "drop no known copy of modified file should not be allowed"
+
+test_partial_commit :: Assertion
+test_partial_commit = intmpclonerepo $ do
+	git_annex "get" [annexedfile] "get of file"
+	annexed_present annexedfile
+	git_annex "unlock" [annexedfile] "unlock"
+	changecontent annexedfile
+	git "commit" ["-q", "-m", "test", annexedfile]
+		"partial commit of unlocked file should be allowed"
+
+test_fix :: Assertion
+test_fix = intmpclonerepo $ unlessM (hasUnlockedFiles <$> getTestMode) $ do
+	annexed_notpresent annexedfile
+	git_annex "fix" [annexedfile] "fix of not present"
+	annexed_notpresent annexedfile
+	git_annex "get" [annexedfile] "get of file"
+	annexed_present annexedfile
+	git_annex "fix" [annexedfile] "fix of present file"
+	annexed_present annexedfile
+	createDirectory subdir
+	git "mv" [annexedfile, subdir] "git mv"
+	git_annex "fix" [newfile] "fix of moved file"
+	runchecks [checklink, checkunwritable] newfile
+	c <- readFile newfile
+	assertEqual "content of moved file" c (content annexedfile)
+  where
+	subdir = "s"
+	newfile = subdir ++ "/" ++ annexedfile
+
+test_trust :: Assertion
+test_trust = intmpclonerepo $ do
+	git_annex "trust" ["--force", repo] "trust"
+	trustcheck Logs.Trust.Trusted "trusted 1"
+	git_annex "trust" ["--force", repo] "trust of trusted"
+	trustcheck Logs.Trust.Trusted "trusted 2"
+	git_annex "untrust" [repo] "untrust"
+	trustcheck Logs.Trust.UnTrusted "untrusted 1"
+	git_annex "untrust" [repo] "untrust of untrusted"
+	trustcheck Logs.Trust.UnTrusted "untrusted 2"
+	git_annex "dead" [repo] "dead"
+	trustcheck Logs.Trust.DeadTrusted "deadtrusted 1"
+	git_annex "dead" [repo] "dead of dead"
+	trustcheck Logs.Trust.DeadTrusted "deadtrusted 2"
+	git_annex "semitrust" [repo] "semitrust"
+	trustcheck Logs.Trust.SemiTrusted "semitrusted 1"
+	git_annex "semitrust" [repo] "semitrust of semitrusted"
+	trustcheck Logs.Trust.SemiTrusted "semitrusted 2"
+  where
+	repo = "origin"
+	trustcheck expected msg = do
+		present <- annexeval $ do
+			l <- Logs.Trust.trustGet expected
+			u <- Remote.nameToUUID repo
+			return $ u `elem` l
+		assertBool msg present
+
+test_fsck_basic :: Assertion
+test_fsck_basic = intmpclonerepo $ do
+	git_annex "fsck" [] "fsck"
+	git_annex "numcopies" ["2"] "numcopies config"
+	fsck_should_fail "numcopies unsatisfied"
+	git_annex "numcopies" ["1"] "numcopies config"
+	corrupt annexedfile
+	corrupt sha1annexedfile
+  where
+	corrupt f = do
+		git_annex "get" [f] "get of file"
+		Utility.FileMode.allowWrite (toRawFilePath f)
+		writecontent f (changedcontent f)
+		ifM (hasUnlockedFiles <$> getTestMode)
+			( git_annex "fsck" []"fsck on unlocked file with changed file content"
+			, git_annex_shouldfail "fsck" [] "fsck with corrupted file content should error"
+			)
+		git_annex "fsck" [] "second fsck, after first fsck should have fixed problem"
+
+test_fsck_bare :: Assertion
+test_fsck_bare = intmpbareclonerepo $
+	git_annex "fsck" [] "fsck"
+
+test_fsck_localuntrusted :: Assertion
+test_fsck_localuntrusted = intmpclonerepo $ do
+	git_annex "get" [annexedfile] "get"
+	git_annex "untrust" ["origin"] "untrust of origin repo"
+	git_annex "untrust" ["."] "untrust of current repo"
+	fsck_should_fail "content only available in untrusted (current) repository"
+	git_annex "trust" ["--force", "."] "trust of current repo"
+	git_annex "fsck" [annexedfile] "fsck on file present in trusted repo"
+
+test_fsck_remoteuntrusted :: Assertion
+test_fsck_remoteuntrusted = intmpclonerepo $ do
+	git_annex "numcopies" ["2"] "numcopies config"
+	git_annex "get" [annexedfile] "get"
+	git_annex "get" [sha1annexedfile] "get"
+	git_annex "fsck" [] "fsck with numcopies=2 and 2 copies"
+	git_annex "untrust" ["origin"] "untrust of origin"
+	fsck_should_fail "content not replicated to enough non-untrusted repositories"
+
+test_fsck_fromremote :: Assertion
+test_fsck_fromremote = intmpclonerepo $ do
+	git_annex "fsck" ["--from", "origin"] "fsck --from origin"
+
+fsck_should_fail :: String -> Assertion
+fsck_should_fail m = git_annex_shouldfail "fsck" []
+	("fsck should not succeed with " ++ m)
+
+-- Make sure that the "converting git to annexed" recipe in
+-- doc/tips/largefiles.mdwn continues to work.
+test_conversion_git_to_annexed :: Assertion
+test_conversion_git_to_annexed = intmpclonerepo $ do
+	git "rm" ["--cached", ingitfile] "git rm --cached"
+	git_annex "add" ["--force-large", ingitfile] "add --force-large"
+	git "commit" ["-q", "-m", "commit", ingitfile] "git commit"
+	whenM (unlockedFiles <$> getTestMode) $
+		git_annex "unlock" [ingitfile] "unlock"
+	annexed_present ingitfile
+
+-- Make sure that the "converting annexed to git" recipe in
+-- doc/tips/largefiles.mdwn continues to work.
+test_conversion_annexed_to_git :: Assertion
+test_conversion_annexed_to_git = intmpclonerepo $ do	
+	git_annex "get" [annexedfile] "get"
+	git_annex "unlock" [annexedfile] "unlock"
+	git "rm" ["--cached", annexedfile] "git rm --cached"
+	git_annex "add" ["--force-small", annexedfile] "add --force-small"
+	git "commit" ["-q", "-m", "commit", annexedfile] "git commit"
+	unannexed_in_git annexedfile
+
+test_migrate :: Assertion
+test_migrate = test_migrate' False
+
+test_migrate_via_gitattributes :: Assertion
+test_migrate_via_gitattributes = test_migrate' True
+
+test_migrate' :: Bool -> Assertion
+test_migrate' usegitattributes = intmpclonerepo $ do
+	annexed_notpresent annexedfile
+	annexed_notpresent sha1annexedfile
+	git_annex "migrate" [annexedfile] "migrate of not present"
+	git_annex "migrate" [sha1annexedfile] "migrate of not present"
+	git_annex "get" [annexedfile] "get of file"
+	git_annex "get" [sha1annexedfile] "get of file"
+	annexed_present annexedfile
+	annexed_present sha1annexedfile
+	if usegitattributes
+		then do
+			writeFile ".gitattributes" "* annex.backend=SHA1"
+			git_annex "migrate" [sha1annexedfile]
+				"migrate sha1annexedfile"
+			git_annex "migrate" [annexedfile]
+				"migrate annexedfile"
+		else do
+			git_annex "migrate" [sha1annexedfile, "--backend", "SHA1"]
+				"migrate sha1annexedfile"
+			git_annex "migrate" [annexedfile, "--backend", "SHA1"]
+				"migrate annexedfile"
+	annexed_present annexedfile
+	annexed_present sha1annexedfile
+	checkbackend annexedfile backendSHA1
+	checkbackend sha1annexedfile backendSHA1
+
+	-- check that reversing a migration works
+	writeFile ".gitattributes" "* annex.backend=SHA256"
+	git_annex "migrate" [sha1annexedfile] "migrate sha1annexedfile"
+	git_annex "migrate" [annexedfile] "migrate annexedfile"
+	annexed_present annexedfile
+	annexed_present sha1annexedfile
+	checkbackend annexedfile backendSHA256
+	checkbackend sha1annexedfile backendSHA256
+
+test_unused :: Assertion
+test_unused = intmpclonerepo $ do
+	checkunused [] "in new clone"
+	git_annex "get" [annexedfile] "get of file"
+	git_annex "get" [sha1annexedfile] "get of file"
+	annexedfilekey <- getKey backendSHA256E annexedfile
+	sha1annexedfilekey <- getKey backendSHA1 sha1annexedfile
+	checkunused [] "after get"
+	git "rm" ["-fq", annexedfile] "git rm"
+	checkunused [] "after rm"
+	-- commit the rm, and when on an adjusted branch, sync it back to
+	-- the master branch
+	git_annex "sync" ["--no-push", "--no-pull", "--no-content"] "git-annex sync"
+	checkunused [] "after commit"
+	-- unused checks origin/master; once it's gone it is really unused
+	git "remote" ["rm", "origin"] "git remote rm origin"
+	checkunused [annexedfilekey] "after origin branches are gone"
+	git "rm" ["-fq", sha1annexedfile] "git rm"
+	git_annex "sync" ["--no-push", "--no-pull", "--no-content"] "git-annex sync"
+	checkunused [annexedfilekey, sha1annexedfilekey] "after rm sha1annexedfile"
+
+	-- good opportunity to test dropkey also
+	git_annex "dropkey" ["--force", Key.serializeKey annexedfilekey] "dropkey"
+	checkunused [sha1annexedfilekey] ("after dropkey --force " ++ Key.serializeKey annexedfilekey)
+
+	git_annex_shouldfail "dropunused" ["1"] "dropunused should not be allowed without --force"
+	git_annex "dropunused" ["--force", "1"] "dropunused"
+	checkunused [] "after dropunused"
+	git_annex_shouldfail "dropunused" ["--force", "10", "501"] "dropunused on bogus numbers"
+
+	-- Unused used to miss renamed symlinks that were not staged
+	-- and pointed at annexed content, and think that content was unused.
+	-- This is only relevant when using locked files; if the file is
+	-- unlocked, the work tree file has the content, and there's no way
+	-- to associate it with the key.
+	unlessM (hasUnlockedFiles <$> getTestMode) $ do
+		writecontent "unusedfile" "unusedcontent"
+		git_annex "add" ["unusedfile"] "add of unusedfile"
+		unusedfilekey <- getKey backendSHA256E "unusedfile"
+		renameFile "unusedfile" "unusedunstagedfile"
+		git "rm" ["-qf", "unusedfile"] "git rm"
+		checkunused [] "with unstaged link"
+		removeFile "unusedunstagedfile"
+		checkunused [unusedfilekey] "with renamed link deleted"
+
+	-- unused used to miss symlinks that were deleted or modified
+	-- manually
+	writecontent "unusedfile" "unusedcontent"
+	git_annex "add" ["unusedfile"] "add of unusedfile"
+	git "add" ["unusedfile"] "git add"
+	unusedfilekey' <- getKey backendSHA256E "unusedfile"
+	checkunused [] "with staged deleted link"
+	git "rm" ["-qf", "unusedfile"] "git rm"
+	checkunused [unusedfilekey'] "with staged link deleted"
+
+	-- unused used to false positive on symlinks that were
+	-- deleted or modified manually, but not staged as such
+	writecontent "unusedfile" "unusedcontent"
+	git_annex "add" ["unusedfile"] "add of unusedfile"
+	git "add" ["unusedfile"] "git add"
+	checkunused [] "with staged file"
+	removeFile "unusedfile"
+	checkunused [] "with staged deleted file"
+
+	-- When an unlocked file is modified, git diff will cause git-annex
+	-- to add its content to the repository. Make sure that's not
+	-- found as unused.
+	whenM (hasUnlockedFiles <$> getTestMode) $ do
+		let f = "unlockedfile"
+		writecontent f "unlockedcontent1"
+		git "add" ["unlockedfile"] "git add"
+		checkunused [] "with unlocked file before modification"
+		writecontent f "unlockedcontent2"
+		checkunused [] "with unlocked file after modification"
+		git_shouldfail "diff" ["--quiet", f] "git diff should exit nonzero when unlocked file is modified"
+		-- still nothing unused because one version is in the index
+		-- and the other is in the work tree
+		checkunused [] "with unlocked file after git diff"
+  where
+	checkunused expectedkeys desc = do
+		git_annex "unused" [] "unused"
+		unusedmap <- annexeval $ Logs.Unused.readUnusedMap mempty
+		let unusedkeys = M.elems unusedmap
+		assertEqual ("unused keys differ " ++ desc)
+			(sort expectedkeys) (sort unusedkeys)
+
+test_describe :: Assertion
+test_describe = intmpclonerepo $ do
+	git_annex "describe" [".", "this repo"] "describe 1"
+	git_annex "describe" ["origin", "origin repo"] "describe 2"
+
+test_find :: Assertion
+test_find = intmpclonerepo $ do
+	annexed_notpresent annexedfile
+	git_annex_expectoutput "find" [] []
+	readonly_query $ git_annex_expectoutput "find" [] []
+	git_annex "get" [annexedfile] "get"
+	annexed_present annexedfile
+	annexed_notpresent sha1annexedfile
+	git_annex_expectoutput "find" [] [annexedfile]
+	readonly_query $ git_annex_expectoutput "find" [] [annexedfile]
+	git_annex_expectoutput "find" ["--exclude", annexedfile, "--and", "--exclude", sha1annexedfile] []
+	git_annex_expectoutput "find" ["--include", annexedfile] [annexedfile]
+	git_annex_expectoutput "find" ["--not", "--in", "origin"] []
+	git_annex_expectoutput "find" ["--copies", "1", "--and", "--not", "--copies", "2"] [sha1annexedfile]
+	git_annex_expectoutput "find" ["--inbackend", "SHA1"] [sha1annexedfile]
+	git_annex_expectoutput "find" ["--inbackend", "WORM"] []
+
+	{- --include=* should match files in subdirectories too,
+	 - and --exclude=* should exclude them. -}
+	createDirectory "dir"
+	writecontent "dir/subfile" "subfile"
+	git_annex "add" ["dir"] "add of subdir"
+	git_annex_expectoutput "find" ["--include", "*", "--exclude", annexedfile, "--exclude", sha1annexedfile] ["dir/subfile"]
+	git_annex_expectoutput "find" ["--exclude", "*"] []
+
+test_merge :: Assertion
+test_merge = intmpclonerepo $
+	git_annex "merge" [] "merge"
+
+test_info :: Assertion
+test_info = intmpclonerepo $ do
+	isjson
+	readonly_query isjson
+	-- When presented with an input that it does not support,
+	-- info does not stop but processes subsequent inputs too.
+	git_annex'' (const True)
+		(sha1annexedfile `isInfixOf`)
+		"info"
+		[annexedfile, "dnefile", sha1annexedfile] Nothing "info"
+  where
+	isjson = do
+		json <- BU8.fromString <$> git_annex_output "info" ["--json"]
+		case Utility.Aeson.eitherDecode json :: Either String Utility.Aeson.Value of
+			Right _ -> return ()
+			Left e -> assertFailure e
+
+test_version :: Assertion
+test_version = intmpclonerepo $ do
+	git_annex "version" [] "version"
+	readonly_query $ git_annex "version" [] "readonly version"
+
+test_sync :: Assertion
+test_sync = intmpclonerepo $ do
+	git_annex "sync" ["--no-content"] "sync"
+	{- Regression test for bug fixed in
+	 - 039e83ed5d1a11fd562cce55b8429c840d72443e, where a present
+	 - wanted file was dropped. -}
+	git_annex "get" [annexedfile] "get"
+	git_annex_expectoutput "find" ["--in", "."] [annexedfile]
+	git_annex "wanted" [".", "present"] "wanted"
+	git_annex "sync" ["--content"] "sync"
+	git_annex_expectoutput "find" ["--in", "."] [annexedfile]
+	git_annex "drop" [annexedfile] "drop"
+	git_annex_expectoutput "find" ["--in", "."] []
+	git_annex "sync" ["--content"] "sync"
+	git_annex_expectoutput "find" ["--in", "."] []
+
+{- Regression test for the concurrency bug fixed in
+ - 667d38a8f11c1ee8f256cdbd80e225c2bae06595 -}
+test_concurrent_get_of_dup_key_regression :: Assertion
+test_concurrent_get_of_dup_key_regression = intmpclonerepo $ do
+	makedup dupfile
+	-- This was sufficient currency to trigger the bug.
+	git_annex "get" ["-J1", annexedfile, dupfile]
+		"concurrent get -J1 with dup"
+	git_annex "drop" ["-J1"]
+		"drop with dup"
+	-- With -J2, one more dup file was needed to trigger the bug.
+	makedup dupfile2
+	git_annex "get" ["-J2", annexedfile, dupfile, dupfile2]
+		"concurrent get -J2 with dup"
+	git_annex "drop" ["-J2"]
+		"drop with dup"
+  where
+	dupfile = annexedfile ++ "2"
+	dupfile2 = annexedfile ++ "3"
+	makedup f = do
+		Utility.CopyFile.copyFileExternal Utility.CopyFile.CopyAllMetaData annexedfile f
+			@? "copying annexed file failed"
+		git "add" [f] "git add"
+
+{- Regression test for union merge bug fixed in
+ - 0214e0fb175a608a49b812d81b4632c081f63027 -}
+test_union_merge_regression :: Assertion
+test_union_merge_regression =
+	{- We need 3 repos to see this bug. -}
+	withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 ->
+			withtmpclonerepo $ \r3 -> do
+				forM_ [r1, r2, r3] $ \r -> indir r $ do
+					when (r /= r1) $
+						git "remote" ["add", "r1", "../" ++ r1] "remote add"
+					when (r /= r2) $
+						git "remote" ["add", "r2", "../" ++ r2] "remote add"
+					when (r /= r3) $
+						git "remote" ["add", "r3", "../" ++ r3] "remote add"
+					git_annex "get" [annexedfile] "get"
+					git "remote" ["rm", "origin"] "remote rm"
+				forM_ [r3, r2, r1] $ \r -> indir r $
+					git_annex "sync" ["--no-content"] ("sync in " ++ r)
+				forM_ [r3, r2] $ \r -> indir r $
+					git_annex "drop" ["--force", annexedfile] ("drop in " ++ r)
+				indir r1 $ do
+					git_annex "sync" ["--no-content"] "sync in r1"
+					git_annex_expectoutput "find" ["--in", "r3"] []
+					{- This was the bug. The sync
+					 - mangled location log data and it
+					 - thought the file was still in r2 -}
+					git_annex_expectoutput "find" ["--in", "r2"] []
+
+{- Regression test for the automatic conflict resolution bug fixed
+ - in f4ba19f2b8a76a1676da7bb5850baa40d9c388e2. -}
+test_conflict_resolution_movein_regression :: Assertion
+test_conflict_resolution_movein_regression = withtmpclonerepo $ \r1 -> 
+	withtmpclonerepo $ \r2 -> do
+		let rname r = if r == r1 then "r1" else "r2"
+		forM_ [r1, r2] $ \r -> indir r $ do
+			{- Get all files, see check below. -}
+			git_annex "get" [] "get"
+			disconnectOrigin
+		pair r1 r2
+		forM_ [r1, r2] $ \r -> indir r $ do
+			{- Set up a conflict. -}
+			let newcontent = content annexedfile ++ rname r
+			git_annex "unlock" [annexedfile] "unlock"
+			writecontent annexedfile newcontent
+		{- Sync twice in r1 so it gets the conflict resolution
+		 - update from r2 -}
+		forM_ [r1, r2, r1] $ \r -> indir r $
+			git_annex "sync" ["--force", "--no-content"] ("sync in " ++ rname r)
+		{- After the sync, it should be possible to get all
+		 - files. This includes both sides of the conflict,
+		 - although the filenames are not easily predictable.
+		 -
+		 - The bug caused one repo to be missing the content
+		 - of the file that had been put in it. -}
+		forM_ [r1, r2] $ \r -> indir r $ do
+			git_annex "get" [] ("get all files after merge conflict resolution in " ++ rname r)
+
+{- Simple case of conflict resolution; 2 different versions of annexed
+ - file. -}
+test_conflict_resolution :: Assertion
+test_conflict_resolution = 
+	withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 -> do
+			indir r1 $ do
+				disconnectOrigin
+				writecontent conflictor "conflictor1"
+				add_annex conflictor "add conflicter"
+				git_annex "sync" ["--no-content"] "sync in r1"
+			indir r2 $ do
+				disconnectOrigin
+				writecontent conflictor "conflictor2"
+				add_annex conflictor "add conflicter"
+				git_annex "sync" ["--no-content"] "sync in r2"
+			pair r1 r2
+			forM_ [r1,r2,r1] $ \r -> indir r $
+				git_annex "sync" ["--no-content"] "sync"
+			checkmerge "r1" r1
+			checkmerge "r2" r2
+  where
+	conflictor = "conflictor"
+	variantprefix = conflictor ++ ".variant"
+	checkmerge what d = do
+		l <- getDirectoryContents d
+		let v = filter (variantprefix `isPrefixOf`) l
+		length v == 2
+			@? (what ++ " not exactly 2 variant files in: " ++ show l)
+		conflictor `notElem` l @? ("conflictor still present after conflict resolution")
+		indir d $ do
+			git_annex "get" v "get"
+			git_annex_expectoutput "find" v v
+
+{- Conflict resolution while in an adjusted branch. -}
+test_conflict_resolution_adjusted_branch :: Assertion
+test_conflict_resolution_adjusted_branch =
+	withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 -> whenM (adjustedbranchsupported r2) $ do
+			indir r1 $ do
+				disconnectOrigin
+				writecontent conflictor "conflictor1"
+				add_annex conflictor "add conflicter"
+				git_annex "sync" ["--no-content"] "sync in r1"
+			indir r2 $ do
+				disconnectOrigin
+				writecontent conflictor "conflictor2"
+				add_annex conflictor "add conflicter"
+				git_annex "sync" ["--no-content"] "sync in r2"
+				-- We might be in an adjusted branch
+				-- already, when eg on a crippled
+				-- filesystem. So, --force it.
+				git_annex "adjust" ["--unlock", "--force"] "adjust"
+			pair r1 r2
+			forM_ [r1,r2,r1] $ \r -> indir r $
+				git_annex "sync" ["--no-content"] "sync"
+			checkmerge "r1" r1
+			checkmerge "r2" r2
+  where
+	conflictor = "conflictor"
+	variantprefix = conflictor ++ ".variant"
+	checkmerge what d = do
+		l <- getDirectoryContents d
+		let v = filter (variantprefix `isPrefixOf`) l
+		length v == 2
+			@? (what ++ " not exactly 2 variant files in: " ++ show l)
+		conflictor `notElem` l @? ("conflictor still present after conflict resolution")
+		indir d $ do
+			git_annex "get" v "get"
+			git_annex_expectoutput "find" v v
+
+{- Check merge conflict resolution when one side is an annexed
+ - file, and the other is a directory. -}
+test_mixed_conflict_resolution :: Assertion
+test_mixed_conflict_resolution = do
+	check True
+	check False
+  where
+	check inr1 = withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 -> do
+			indir r1 $ do
+				disconnectOrigin
+				writecontent conflictor "conflictor"
+				add_annex conflictor "add conflicter"
+				git_annex "sync" ["--no-content"] "sync in r1"
+			indir r2 $ do
+				disconnectOrigin
+				createDirectory conflictor
+				writecontent subfile "subfile"
+				add_annex conflictor "add conflicter"
+				git_annex "sync" ["--no-content"] "sync in r2"
+			pair r1 r2
+			let l = if inr1 then [r1, r2] else [r2, r1]
+			forM_ l $ \r -> indir r $
+				git_annex "sync" ["--no-content"] "sync in mixed conflict"
+			checkmerge "r1" r1
+			checkmerge "r2" r2
+	conflictor = "conflictor"
+	subfile = conflictor </> "subfile"
+	checkmerge what d = do
+		doesDirectoryExist (d </> conflictor) 
+			@? (d ++ " conflictor directory missing")
+		l <- getDirectoryContents d
+		let v = filter (Annex.VariantFile.variantMarker `isInfixOf`) l
+		not (null v)
+			@? (what ++ " conflictor variant file missing in: " ++ show l )
+		length v == 1
+			@? (what ++ " too many variant files in: " ++ show v)
+		indir d $ do
+			git_annex "get" (conflictor:v) ("get  in " ++ what)
+			git_annex_expectoutput "find" [conflictor] [fromRawFilePath (Git.FilePath.toInternalGitPath (toRawFilePath subfile))]
+			git_annex_expectoutput "find" v v
+
+{- Check merge conflict resolution when both repos start with an annexed
+ - file; one modifies it, and the other deletes it. -}
+test_remove_conflict_resolution :: Assertion
+test_remove_conflict_resolution = do
+	check True
+	check False
+  where
+	check inr1 = withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 -> do
+			indir r1 $ do
+				disconnectOrigin
+				writecontent conflictor "conflictor"
+				add_annex conflictor "add conflicter"
+				git_annex "sync" ["--no-content"] "sync in r1"
+			indir r2 $
+				disconnectOrigin
+			pair r1 r2
+			indir r2 $ do
+				git_annex "sync" ["--no-content"] "sync in r2"
+				git_annex "get" [conflictor] "get conflictor"
+				git_annex "unlock" [conflictor] "unlock conflictor"
+				writecontent conflictor "newconflictor"
+			indir r1 $
+				removeWhenExistsWith R.removeLink (toRawFilePath conflictor)
+			let l = if inr1 then [r1, r2, r1] else [r2, r1, r2]
+			forM_ l $ \r -> indir r $
+				git_annex "sync" ["--no-content"] "sync"
+			checkmerge "r1" r1
+			checkmerge "r2" r2
+	conflictor = "conflictor"
+	variantprefix = conflictor ++ ".variant"
+	checkmerge what d = do
+		l <- getDirectoryContents d
+		let v = filter (variantprefix `isPrefixOf`) l
+		not (null v)
+			@? (what ++ " conflictor variant file missing in: " ++ show l )
+		length v == 1
+			@? (what ++ " too many variant files in: " ++ show v)
+
+{- Check merge confalict resolution when a file is annexed in one repo,
+ - and checked directly into git in the other repo.
+ -}
+test_nonannexed_file_conflict_resolution :: Assertion
+test_nonannexed_file_conflict_resolution = do
+	check True
+	check False
+  where
+	check inr1 = withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 -> do
+			indir r1 $ do
+				disconnectOrigin
+				writecontent conflictor "conflictor"
+				add_annex conflictor "add conflicter"
+				git_annex "sync" ["--no-content"] "sync in r1"
+			indir r2 $ do
+				disconnectOrigin
+				writecontent conflictor nonannexed_content
+				git "config"
+					[ "annex.largefiles"
+					, "exclude=" ++ ingitfile ++ " and exclude=" ++ conflictor
+					] "git config annex.largefiles"
+				git "add" [conflictor] "git add conflictor"
+				git_annex "sync" ["--no-content"] "sync in r2"
+			pair r1 r2
+			let l = if inr1 then [r1, r2] else [r2, r1]
+			forM_ l $ \r -> indir r $
+				git_annex "sync" ["--no-content"] "sync"
+			checkmerge "r1" r1
+			checkmerge "r2" r2
+	conflictor = "conflictor"
+	nonannexed_content = "nonannexed"
+	variantprefix = conflictor ++ ".variant"
+	checkmerge what d = do
+		l <- getDirectoryContents d
+		let v = filter (variantprefix `isPrefixOf`) l
+		not (null v)
+			@? (what ++ " conflictor variant file missing in: " ++ show l )
+		length v == 1
+			@? (what ++ " too many variant files in: " ++ show v)
+		conflictor `elem` l @? (what ++ " conflictor file missing in: " ++ show l)
+		s <- catchMaybeIO (readFile (d </> conflictor))
+		s == Just nonannexed_content
+			@? (what ++ " wrong content for nonannexed file: " ++ show s)
+
+
+{- Check merge conflict resolution when a file is annexed in one repo,
+ - and is a non-git-annex symlink in the other repo.
+ -
+ - Test can only run when coreSymlinks is supported, because git needs to
+ - be able to check out the non-git-annex symlink.
+ -}
+test_nonannexed_symlink_conflict_resolution :: Assertion
+test_nonannexed_symlink_conflict_resolution = do
+	check True
+	check False
+  where
+	check inr1 = withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 ->
+			whenM (checkRepo (Types.coreSymlinks <$> Annex.getGitConfig) r1) $ do
+				indir r1 $ do
+					disconnectOrigin
+					writecontent conflictor "conflictor"
+					add_annex conflictor "add conflicter"
+					git_annex "sync" ["--no-content"] "sync in r1"
+				indir r2 $ do
+					disconnectOrigin
+					R.createSymbolicLink (toRawFilePath symlinktarget) (toRawFilePath "conflictor")
+					git "add" [conflictor] "git add conflictor"
+					git_annex "sync" ["--no-content"] "sync in r2"
+				pair r1 r2
+				let l = if inr1 then [r1, r2] else [r2, r1]
+				forM_ l $ \r -> indir r $
+					git_annex "sync" ["--no-content"] "sync"
+				checkmerge "r1" r1
+				checkmerge "r2" r2
+	conflictor = "conflictor"
+	symlinktarget = "dummy-target"
+	variantprefix = conflictor ++ ".variant"
+	checkmerge what d = do
+		l <- getDirectoryContents d
+		let v = filter (variantprefix `isPrefixOf`) l
+		not (null v)
+			@? (what ++ " conflictor variant file missing in: " ++ show l )
+		length v == 1
+			@? (what ++ " too many variant files in: " ++ show v)
+		conflictor `elem` l @? (what ++ " conflictor file missing in: " ++ show l)
+		s <- catchMaybeIO (R.readSymbolicLink (toRawFilePath (d </> conflictor)))
+		s == Just (toRawFilePath symlinktarget)
+			@? (what ++ " wrong target for nonannexed symlink: " ++ show s)
+
+{- Check merge conflict resolution when there is a local file,
+ - that is not staged or committed, that conflicts with what's being added
+ - from the remmote.
+ -
+ - Case 1: Remote adds file named conflictor; local has a file named
+ - conflictor.
+ -
+ - Case 2: Remote adds conflictor/file; local has a file named conflictor.
+ -}
+test_uncommitted_conflict_resolution :: Assertion
+test_uncommitted_conflict_resolution = do
+	check conflictor
+	check (conflictor </> "file")
+  where
+	check remoteconflictor = withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 -> do
+			indir r1 $ do
+				disconnectOrigin
+				createDirectoryIfMissing True (fromRawFilePath (parentDir (toRawFilePath remoteconflictor)))
+				writecontent remoteconflictor annexedcontent
+				add_annex conflictor "add remoteconflicter"
+				git_annex "sync" ["--no-content"] "sync in r1"
+			indir r2 $ do
+				disconnectOrigin
+				writecontent conflictor localcontent
+			pair r1 r2
+			-- this case is intentionally not handled
+			-- since the user can recover on their own easily
+			indir r2 $ git_annex_shouldfail "sync" ["--no-content"] "sync should not succeed"
+	conflictor = "conflictor"
+	localcontent = "local"
+	annexedcontent = "annexed"
+
+{- On Windows/FAT, repeated conflict resolution sometimes 
+ - lost track of whether a file was a symlink. 
+ -}
+test_conflict_resolution_symlink_bit :: Assertion
+test_conflict_resolution_symlink_bit = unlessM (hasUnlockedFiles <$> getTestMode) $
+	withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 ->
+			withtmpclonerepo $ \r3 -> do
+				indir r1 $ do
+					writecontent conflictor "conflictor"
+					git_annex "add" [conflictor] "add conflicter"
+					git_annex "sync" ["--no-content"] "sync in r1"
+					check_is_link conflictor "r1"
+				indir r2 $ do
+					createDirectory conflictor
+					writecontent (conflictor </> "subfile") "subfile"
+					git_annex "add" [conflictor] "add conflicter"
+					git_annex "sync" ["--no-content"] "sync in r2"
+					check_is_link (conflictor </> "subfile") "r2"
+				indir r3 $ do
+					writecontent conflictor "conflictor"
+					git_annex "add" [conflictor] "add conflicter"
+					git_annex "sync" ["--no-content"] "sync in r1"
+					check_is_link (conflictor </> "subfile") "r3"
+  where
+	conflictor = "conflictor"
+	check_is_link f what = do
+		git_annex_expectoutput "find" ["--include=*", f] [fromRawFilePath (Git.FilePath.toInternalGitPath (toRawFilePath f))]
+		l <- annexeval $ Annex.inRepo $ Git.LsTree.lsTreeFiles (Git.LsTree.LsTreeLong False) Git.Ref.headRef [f]
+		all (\i -> Git.Types.toTreeItemType (Git.LsTree.mode i) == Just Git.Types.TreeSymlink) l
+			@? (what ++ " " ++ f ++ " lost symlink bit after merge: " ++ show l)
+
+{- An unlocked file that conflicts with a locked file should be resolved
+ - in favor of the unlocked file, with no variant files, as long as they
+ - both point to the same key. -}
+test_mixed_lock_conflict_resolution :: Assertion
+test_mixed_lock_conflict_resolution = 
+	withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 -> do
+			indir r1 $ do
+				disconnectOrigin
+				writecontent conflictor "conflictor"
+				git_annex "add" [conflictor] "add conflicter"
+				git_annex "sync" ["--no-content"] "sync in r1"
+			indir r2 $ do
+				disconnectOrigin
+				writecontent conflictor "conflictor"
+				git_annex "add" [conflictor] "add conflicter"
+				git_annex "unlock" [conflictor] "unlock conflicter"
+				git_annex "sync" ["--no-content"] "sync in r2"
+			pair r1 r2
+			forM_ [r1,r2,r1] $ \r -> indir r $
+				git_annex "sync" ["--no-content"] "sync"
+			checkmerge "r1" r1
+			checkmerge "r2" r2
+  where
+	conflictor = "conflictor"
+	variantprefix = conflictor ++ ".variant"
+	checkmerge what d = indir d $ do
+		l <- getDirectoryContents "."
+		let v = filter (variantprefix `isPrefixOf`) l
+		length v == 0
+			@? (what ++ " not exactly 0 variant files in: " ++ show l)
+		conflictor `elem` l @? ("conflictor not present after conflict resolution")
+		git_annex "get" [conflictor] "get"
+		git_annex_expectoutput "find" [conflictor] [conflictor]
+		-- regular file because it's unlocked
+		checkregularfile conflictor
+
+{- Regression test for a bad merge between two adjusted branch repos,
+ - where the same file is added to both independently. The bad merge
+ - emptied the whole tree. -}
+test_adjusted_branch_merge_regression :: Assertion
+test_adjusted_branch_merge_regression = do
+	withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 -> whenM (adjustedbranchsupported r1) $ do
+			pair r1 r2
+			setup r1
+			setup r2
+			checkmerge "r1" r1
+			checkmerge "r2" r2
+  where
+	conflictor = "conflictor"
+	setup r = indir r $ whensupported $ do
+		disconnectOrigin
+		git_annex "upgrade" [] "upgrade"
+		git_annex "adjust" ["--unlock", "--force"] "adjust"
+		writecontent conflictor "conflictor"
+		git_annex "add" [conflictor] "add conflicter"
+		git_annex "sync" ["--no-content"] "sync"
+	checkmerge what d = indir d $ whensupported $ do
+		git_annex "sync" ["--no-content"] ("sync should not work in " ++ what)
+		l <- getDirectoryContents "."
+		conflictor `elem` l
+			@? ("conflictor not present after merge in " ++ what)
+	-- Currently this fails on FAT, for unknown reasons not to
+	-- do with what it's intended to test.
+	whensupported = unlessM (annexeval Config.crippledFileSystem)
+
+{- Regression test for a bug in adjusted branch syncing code, where adding
+ - a subtree to an existing tree lost files. -}
+test_adjusted_branch_subtree_regression :: Assertion
+test_adjusted_branch_subtree_regression = 
+	withtmpclonerepo $ \r -> whenM (adjustedbranchsupported r) $ do
+		indir r $ do
+			disconnectOrigin
+			origbranch <- annexeval origBranch
+			git_annex "upgrade" [] "upgrade"
+			git_annex "adjust" ["--unlock", "--force"] "adjust"
+			createDirectoryIfMissing True "a/b/c"
+			writecontent "a/b/c/d" "foo"
+			git_annex "add" ["a/b/c"] "add a/b/c"
+			git_annex "sync" ["--no-content"] "sync"
+			createDirectoryIfMissing True "a/b/x"
+			writecontent "a/b/x/y" "foo"
+			git_annex "add" ["a/b/x"] "add a/b/x"
+			git_annex "sync" ["--no-content"] "sync"
+			git "checkout" [origbranch] "git checkout"
+			doesFileExist "a/b/x/y" @? ("a/b/x/y missing from master after adjusted branch sync")
+
+test_map :: Assertion
+test_map = intmpclonerepo $ do
+	-- set descriptions, that will be looked for in the map
+	git_annex "describe" [".", "this repo"] "describe 1"
+	git_annex "describe" ["origin", "origin repo"] "describe 2"
+	-- --fast avoids it running graphviz, not a build dependency
+	git_annex "map" ["--fast"] "map"
+
+test_uninit :: Assertion
+test_uninit = intmpclonerepo $ do
+	git_annex "get" [] "get"
+	annexed_present annexedfile
+	-- any exit status is accepted; does abnormal exit
+	git_annex'' (const True) (const True) "uninit" [] Nothing "uninit"
+	checkregularfile annexedfile
+	doesDirectoryExist ".git" @? ".git vanished in uninit"
+
+test_uninit_inbranch :: Assertion
+test_uninit_inbranch = intmpclonerepo $ do
+	git "checkout" ["git-annex"] "git checkout git-annex"
+	git_annex_shouldfail "uninit" [] "uninit should not succeed when git-annex branch is checked out"
+
+test_upgrade :: Assertion
+test_upgrade = intmpclonerepo $
+	git_annex "upgrade" [] "upgrade"
+
+test_whereis :: Assertion
+test_whereis = intmpclonerepo $ do
+	annexed_notpresent annexedfile
+	git_annex "whereis" [annexedfile] "whereis on non-present file"
+	readonly_query $ 
+		git_annex "whereis" [annexedfile] "readonly whereis on non-present file"
+	git_annex "untrust" ["origin"] "untrust"
+	git_annex_shouldfail "whereis" [annexedfile] "whereis should exit nonzero on non-present file only present in untrusted repo"
+	git_annex "get" [annexedfile] "get"
+	annexed_present annexedfile
+	git_annex "whereis" [annexedfile] "whereis on present file"
+	readonly_query $
+		git_annex "whereis" [annexedfile] "readonly whereis on present file"
+
+test_hook_remote :: Assertion
+test_hook_remote = intmpclonerepo $ do
+#ifndef mingw32_HOST_OS
+	git_annex "initremote" (words "foo type=hook encryption=none hooktype=foo") "initremote"
+	createDirectory dir
+	git_config "annex.foo-store-hook" $
+		"cp $ANNEX_FILE " ++ loc
+	git_config "annex.foo-retrieve-hook" $
+		"cp " ++ loc ++ " $ANNEX_FILE"
+	git_config "annex.foo-remove-hook" $
+		"rm -f " ++ loc
+	git_config "annex.foo-checkpresent-hook" $
+		"if [ -e " ++ loc ++ " ]; then echo $ANNEX_KEY; fi"
+	git_annex "get" [annexedfile] "get of file"
+	annexed_present annexedfile
+	git_annex "copy" [annexedfile, "--to", "foo"] "copy --to hook remote"
+	annexed_present annexedfile
+	git_annex "drop" [annexedfile, "--numcopies=2"] "drop"
+	annexed_notpresent annexedfile
+	git_annex "move" [annexedfile, "--from", "foo"] "move --from hook remote"
+	annexed_present annexedfile
+	git_annex_shouldfail "drop" [annexedfile, "--numcopies=2"] "drop should not be allowed with numcopies=2"
+	annexed_present annexedfile
+  where
+	dir = "dir"
+	loc = dir ++ "/$ANNEX_KEY"
+	git_config k v = git "config" [k, v] "git config"
+#else
+	-- this test doesn't work in Windows TODO
+	noop
+#endif
+
+test_directory_remote :: Assertion
+test_directory_remote = intmpclonerepo $ do
+	createDirectory "dir"
+	git_annex "initremote" (words "foo type=directory encryption=none directory=dir") "initremote"
+	git_annex "get" [annexedfile] "get of file"
+	annexed_present annexedfile
+	git_annex "copy" [annexedfile, "--to", "foo"] "copy --to directory remote"
+	annexed_present annexedfile
+	git_annex "drop" [annexedfile, "--numcopies=2"] "drop"
+	annexed_notpresent annexedfile
+	git_annex "move" [annexedfile, "--from", "foo"] "move --from directory remote"
+	annexed_present annexedfile
+	git_annex_shouldfail "drop" [annexedfile, "--numcopies=2"] "drop should not be allowed with numcopies=2"
+	annexed_present annexedfile
+
+test_rsync_remote :: Assertion
+test_rsync_remote = intmpclonerepo $ do
+#ifndef mingw32_HOST_OS
+	createDirectory "dir"
+	git_annex "initremote" (words "foo type=rsync encryption=none rsyncurl=dir") "initremote"
+	git_annex "get" [annexedfile] "get of file"
+	annexed_present annexedfile
+	git_annex "copy" [annexedfile, "--to", "foo"] "copy --to rsync remote"
+	annexed_present annexedfile
+	git_annex "drop" [annexedfile, "--numcopies=2"] "drop"
+	annexed_notpresent annexedfile
+	git_annex "move" [annexedfile, "--from", "foo"] "move --from rsync remote"
+	annexed_present annexedfile
+	git_annex_shouldfail "drop" [annexedfile, "--numcopies=2"] "drop should not be allowed with numcopies=2"
+	annexed_present annexedfile
+#else
+	noop
+#endif
+
+test_bup_remote :: Assertion
+test_bup_remote = intmpclonerepo $ when BuildInfo.bup $ do
+	-- bup special remote needs an absolute path
+	dir <- fromRawFilePath <$> absPath (toRawFilePath "dir")
+	createDirectory dir
+	git_annex "initremote" (words $ "foo type=bup encryption=none buprepo="++dir) "initremote"
+	git_annex "get" [annexedfile] "get of file"
+	annexed_present annexedfile
+	git_annex "copy" [annexedfile, "--to", "foo"] "copy --to bup remote"
+	annexed_present annexedfile
+	git_annex "drop" [annexedfile, "--numcopies=2"] "drop"
+	annexed_notpresent annexedfile
+	git_annex "copy" [annexedfile, "--from", "foo"] "copy --from bup remote"
+	annexed_present annexedfile
+	git_annex "move" [annexedfile, "--from", "foo"] "move --from bup remote"
+	annexed_present annexedfile
+
+test_borg_remote :: Assertion
+test_borg_remote = when BuildInfo.borg $ do
+	borgdirparent <- fromRawFilePath <$> (absPath . toRawFilePath =<< tmprepodir)
+	let borgdir = borgdirparent </> "borgrepo"
+	intmpclonerepo $ do
+		testProcess "borg" ["init", borgdir, "-e", "none"] Nothing (== True) (const True) "borg init"
+		testProcess "borg" ["create", borgdir++"::backup1", "."] Nothing (== True) (const True) "borg create"
+
+		git_annex "initremote" (words $ "borg type=borg borgrepo="++borgdir) "initremote"
+		git_annex "sync" ["--no-content", "borg"] "sync borg"
+		git_annex_expectoutput "find" ["--in=borg"] []
+
+		git_annex "get" [annexedfile] "get of file"
+		annexed_present annexedfile
+		git_annex_expectoutput "find" ["--in=borg"] []
+		
+		testProcess "borg" ["create", borgdir++"::backup2", "."] Nothing (== True) (const True) "borg create"
+		git_annex "sync" ["--no-content", "borg"] "sync borg after getting file"
+		git_annex_expectoutput "find" ["--in=borg"] [annexedfile]
+
+		git "remote" ["rm", "origin"] "remote rm"
+		git_annex_shouldfail "drop" [annexedfile]
+			"drop from borg succeeded, but it should be untrusted by default"
+		git_annex "enableremote" ["borg", "appendonly=yes"] "enableremote appendonly"		
+		git_annex "drop" [annexedfile] "drop from borg (appendonly)"
+		git_annex "get" [annexedfile, "--from=borg"] "get from borg"
+
+-- To test Stateless OpenPGP, annex.shared-sop-command has to be set using
+-- the --test-git-config option.
+test_sop_crypto :: Assertion
+test_sop_crypto = do
+	gc <- testGitConfig . testOptions <$> getTestMode
+	case filter (\(k, _) -> k == ck) gc of
+		[] -> noop
+		((_, sopcmd):_) -> go $ 
+			Utility.StatelessOpenPGP.SOPCmd $
+				Git.Types.fromConfigValue sopcmd
+  where
+	ck = fromString "annex.shared-sop-command"
+	pw = fromString "testpassword"
+	v = fromString "somevalue"
+	unarmored = Utility.StatelessOpenPGP.Armoring False
+	go sopcmd = do
+		Utility.StatelessOpenPGP.test_encrypt_decrypt_Symmetric sopcmd sopcmd pw unarmored v
+			@? "sop command roundtrips symmetric encryption"
+
+-- gpg is not a build dependency, so only test when it's available
+test_gpg_crypto :: Assertion
+#ifndef mingw32_HOST_OS
+test_gpg_crypto = do
+	testscheme "shared"
+	testscheme "hybrid"
+	testscheme "pubkey"
+  where
+	gpgcmd = Utility.Gpg.mkGpgCmd Nothing
+	testscheme scheme = Utility.Tmp.Dir.withTmpDir "gpgtmp" $ \gpgtmp -> do
+		-- Use the system temp directory as gpg temp directory because 
+		-- it needs to be able to store the agent socket there,
+		-- which can be problematic when testing some filesystems.
+		absgpgtmp <- fromRawFilePath <$> absPath (toRawFilePath gpgtmp)
+		res <- testscheme' scheme absgpgtmp
+		-- gpg may still be running and would prevent
+		-- removeDirectoryRecursive from succeeding, so
+		-- force removal of the temp directory.
+		liftIO $ removeDirectoryForCleanup gpgtmp
+		return res
+	testscheme' scheme absgpgtmp = intmpclonerepo $ do
+		-- Since gpg uses a unix socket, which is limited to a
+		-- short path, use whichever is shorter of absolute
+		-- or relative path.
+		relgpgtmp <- fromRawFilePath <$> relPathCwdToFile (toRawFilePath absgpgtmp)
+		let gpgtmp = if length relgpgtmp < length absgpgtmp
+			then relgpgtmp 
+			else absgpgtmp
+		void $ Utility.Gpg.testHarness gpgtmp gpgcmd $ \environ -> do
+			createDirectory "dir"
+			let initps =
+				[ "foo"
+				, "type=directory"
+				, "encryption=" ++ scheme
+				, "directory=dir"
+				, "highRandomQuality=false"
+				] ++ if scheme `elem` ["hybrid","pubkey"]
+					then ["keyid=" ++ Utility.Gpg.testKeyId]
+					else []
+			git_annex' "initremote" initps (Just environ) "initremote"
+			git_annex_shouldfail' "initremote" initps (Just environ) "initremote should not work when run twice in a row"
+			git_annex' "enableremote" initps (Just environ) "enableremote"
+			git_annex' "enableremote" initps (Just environ) "enableremote when run twice in a row"
+			git_annex' "get" [annexedfile] (Just environ) "get of file"
+			annexed_present annexedfile
+			git_annex' "copy" [annexedfile, "--to", "foo"] (Just environ) "copy --to encrypted remote"
+			(c,k) <- annexeval $ do
+				uuid <- Remote.nameToUUID "foo"
+				rs <- Logs.Remote.readRemoteLog
+				Just k <- Annex.WorkTree.lookupKey (toRawFilePath annexedfile)
+				return (fromJust $ M.lookup uuid rs, k)
+			let key = if scheme `elem` ["hybrid","pubkey"]
+					then Just $ Utility.Gpg.KeyIds [Utility.Gpg.testKeyId]
+					else Nothing
+			testEncryptedRemote environ scheme key c [k] @? "invalid crypto setup"
+	
+			annexed_present annexedfile
+			git_annex' "drop" [annexedfile, "--numcopies=2"] (Just environ) "drop"
+			annexed_notpresent annexedfile
+			git_annex' "move" [annexedfile, "--from", "foo"] (Just environ) "move --from encrypted remote"
+			annexed_present annexedfile
+			git_annex_shouldfail' "drop" [annexedfile, "--numcopies=2"] (Just environ) "drop should not be allowed with numcopies=2"
+			annexed_present annexedfile
+	{- Ensure the configuration complies with the encryption scheme, and
+	 - that all keys are encrypted properly for the given directory remote. -}
+	testEncryptedRemote environ scheme ks c keys = case Remote.Helper.Encryptable.extractCipher pc of
+		Just cip@Crypto.SharedCipher{} | scheme == "shared" && isNothing ks ->
+			checkKeys cip Nothing
+		Just cip@(Crypto.EncryptedCipher encipher v ks')
+			| checkScheme v && keysMatch ks' ->
+				checkKeys cip (Just v) <&&> checkCipher encipher ks'
+		_ -> return False
+	  where
+		pc = either (const (Types.Remote.ParsedRemoteConfig mempty mempty)) id $
+			Remote.Helper.Encryptable.parseEncryptionConfig c
+		keysMatch (Utility.Gpg.KeyIds ks') =
+			maybe False (\(Utility.Gpg.KeyIds ks2) ->
+					sort (nub ks2) == sort (nub ks')) ks
+		checkCipher encipher = Utility.Gpg.checkEncryptionStream gpgcmd (Just environ) encipher . Just
+		checkScheme Types.Crypto.Hybrid = scheme == "hybrid"
+		checkScheme Types.Crypto.PubKey = scheme == "pubkey"
+		checkKeys cip mvariant = do
+			dummycfg <- Types.GitConfig.dummyRemoteGitConfig
+			let encparams = (Types.Remote.ParsedRemoteConfig mempty mempty, dummycfg)
+			cipher <- Crypto.decryptCipher' gpgcmd (Just environ) encparams cip
+			files <- filterM doesFileExist $
+				map ("dir" </>) $ concatMap (serializeKeys cipher) keys
+			return (not $ null files) <&&> allM (checkFile mvariant) files
+		checkFile mvariant filename =
+			Utility.Gpg.checkEncryptionFile gpgcmd (Just environ) filename $
+				if mvariant == Just Types.Crypto.PubKey then ks else Nothing
+		serializeKeys cipher = map fromRawFilePath . 
+			Annex.Locations.keyPaths .
+			Crypto.encryptKey Types.Crypto.HmacSha1 cipher
+#else
+test_gpg_crypto = putStrLn "gpg testing not implemented on Windows"
+#endif
+
+test_add_subdirs :: Assertion
+test_add_subdirs = intmpclonerepo $ do
+	createDirectory "dir"
+	writecontent ("dir" </> "foo") $ "dir/" ++ content annexedfile
+	git_annex "add" ["dir"] "add of subdir"
+
+	{- Regression test for Windows bug where symlinks were not
+	 - calculated correctly for files in subdirs. -}
+	unlessM (hasUnlockedFiles <$> getTestMode) $ do
+		git_annex "sync" ["--no-content"] "sync"
+		l <- annexeval $ Utility.FileSystemEncoding.decodeBL
+			<$> Annex.CatFile.catObject (Git.Types.Ref (encodeBS "HEAD:dir/foo"))
+		"../.git/annex/" `isPrefixOf` l @? ("symlink from subdir to .git/annex is wrong: " ++ l)
+
+	createDirectory "dir2"
+	writecontent ("dir2" </> "foo") $ content annexedfile
+	setCurrentDirectory "dir"
+	git_annex "add" [".." </> "dir2"] "add of ../subdir"
+
+test_addurl :: Assertion
+test_addurl = intmpclonerepo $ do
+	-- file:// only; this test suite should not hit the network
+	let filecmd c ps = git_annex c ("-cannex.security.allowed-url-schemes=file" : ps)
+	f <- fromRawFilePath <$> absPath (toRawFilePath "myurl")
+	let url = replace "\\" "/" ("file:///" ++ dropDrive f)
+	writecontent f "foo"
+	git_annex_shouldfail "addurl" [url] "addurl should not work on file url"
+	filecmd "addurl" [url] ("addurl on " ++ url)
+	let dest = "addurlurldest"
+	filecmd "addurl" ["--file", dest, url] ("addurl on " ++ url ++ "  with --file")
+	doesFileExist dest @? (dest ++ " missing after addurl --file")
+
+test_export_import :: Assertion
+test_export_import = intmpclonerepo $ do
+	createDirectory "dir"
+	git_annex "initremote" (words "foo type=directory encryption=none directory=dir exporttree=yes importtree=yes") "initremote"
+	git_annex "get" [] "get of files"
+	annexed_present annexedfile
+
+	-- Nothing to commit, but this makes sure the master branch
+	-- is in sync with the adjusted branch, which it may not be
+	-- depending on how the repository was set up.
+	commitchanges
+	origbranch <- annexeval origBranch
+	git_annex "export" [origbranch, "--to", "foo"] "export to dir"
+	dircontains annexedfile (content annexedfile)
+
+	writedir "import" (content "import")
+	git_annex "import" [origbranch, "--from", "foo"] "import from dir"
+	git_annex "merge" ["foo/" ++ origbranch] "git annex merge"
+	annexed_present_imported "import"
+
+	removeWhenExistsWith R.removeLink (toRawFilePath "import")
+	writecontent "import" (content "newimport1")
+	git_annex "add" ["import"] "add of import"
+	commitchanges
+	git_annex "export" [origbranch, "--to", "foo"] "export modified file to dir"
+	dircontains "import" (content "newimport1")
+
+	-- verify that export refuses to overwrite modified file
+	writedir "import" (content "newimport2")
+	removeWhenExistsWith R.removeLink (toRawFilePath "import")
+	writecontent "import" (content "newimport3")
+	git_annex "add" ["import"] "add of import"
+	commitchanges
+	git_annex_shouldfail "export" [origbranch, "--to", "foo"] "export should not work in conflict"
+	dircontains "import" (content "newimport2")
+
+	-- resolving import conflict
+	git_annex "import" [origbranch, "--from", "foo"] "import from dir"
+	git_shouldfail "merge" ["foo/master", "-mmerge"] "git merge of conflict should exit nonzero"
+	removeWhenExistsWith R.removeLink (toRawFilePath "import")
+	writecontent "import" (content "newimport3")
+	git_annex "add" ["import"] "add of import"
+	commitchanges
+	git_annex "export" [origbranch, "--to", "foo"] "export after import conflict"
+	dircontains "import" (content "newimport3")
+  where
+	dircontains f v = 
+		((v==) <$> readFile ("dir" </> f))
+			@? ("did not find expected content of " ++ "dir" </> f)
+	writedir f = writecontent ("dir" </> f)
+	-- When on an adjusted branch, this updates the master branch
+	-- to match it, which is necessary since the master branch is going
+	-- to be exported.
+	commitchanges = git_annex "sync" ["--no-pull", "--no-push", "--no-content"] "sync"
+
+test_export_import_subdir :: Assertion
+test_export_import_subdir = intmpclonerepo $ do
+	createDirectory "dir"
+	git_annex "initremote" (words "foo type=directory encryption=none directory=dir exporttree=yes importtree=yes") "initremote"
+	git_annex "get" [] "get of files"
+	annexed_present annexedfile
+
+	createDirectory subdir
+	git "mv" [annexedfile, subannexedfile] "git mv"
+	git "commit" ["-m", "moved"] "git commit"
+	
+	-- When on an adjusted branch, this updates the master branch
+	-- to match it, which is necessary since the master branch is going
+	-- to be exported.
+	git_annex "sync" ["--no-pull", "--no-push", "--no-content"] "sync"
+
+	-- Run three times because there was a bug that took a couple
+	-- of runs to lead to the wrong tree being written to the remote
+	-- tracking branch.
+	testimport
+	testexport
+	testimport
+	testexport
+	testimport
+	testexport
+  where
+	dircontains f v = 
+		((v==) <$> readFile ("dir" </> f))
+			@? ("did not find expected content of " ++ "dir" </> f)
+	
+	subdir = "subdir"
+	subannexedfile = "subdir" </> annexedfile
+	
+	testexport = do
+		origbranch <- annexeval origBranch
+		git_annex "export" [origbranch++":"++subdir, "--to", "foo"] "export of subdir"
+		dircontains annexedfile (content annexedfile)
+	
+	testimport = do
+		origbranch <- annexeval origBranch
+		git_annex "import" [origbranch++":"++subdir, "--from", "foo"] "import of subdir"
+		git_annex "merge" ["foo/master", "--allow-unrelated-histories"] "git annex merge foo/master"
+
+		-- Make sure that import did not import the file to the top
+		-- of the repo.
+		checkdoesnotexist annexedfile
+
+test_transition_propagation_reversion :: Assertion
+test_transition_propagation_reversion =
+	withtmpclonerepo $ \r1 ->
+		withtmpclonerepo $ \r2 -> do
+			pair r1 r2
+			indir r1 $ do
+				disconnectOrigin
+				writecontent wormannexedfile $ content wormannexedfile
+				git_annex "add" [wormannexedfile, "--backend=WORM"] "add"
+				git_annex "sync" ["--no-content"] "sync"
+			indir r2 $ do
+				disconnectOrigin
+				git_annex "sync" ["--no-content"] "sync"
+			indir r1 $ do
+				git_annex "sync" ["--no-content"] "sync"
+			indir r2 $ do
+				git_annex "get" [wormannexedfile] "get"
+				git_annex "drop" [wormannexedfile] "drop"
+				git_annex "get" [wormannexedfile] "get"
+				git_annex "drop" [wormannexedfile] "drop"
+			indir r1 $ do
+				git_annex "drop" ["--force", wormannexedfile] "drop"
+				git_annex "sync" ["--no-content"] "sync"
+				git_annex "forget" ["--force"] "forget"
+				git_annex "sync" ["--no-content"] "sync"
+				emptylog
+			indir r2 $ do
+				git_annex "sync" ["--no-content"] "sync"
+				emptylog
+			indir r1 $ do
+				git_annex "sync" ["--no-content"] "sync"
+				emptylog
+  where
+	emptylog = git_annex_expectoutput "log" [wormannexedfile] []
+
+test_repair :: Assertion
+test_repair = intmpclonerepo $
+	-- Simply running repair used to fail on Windows.
+	git_annex "repair" [] "repair"
diff --git a/Test/Framework.hs b/Test/Framework.hs
new file mode 100644
index 0000000000..3b4563779f
--- /dev/null
+++ b/Test/Framework.hs
@@ -0,0 +1,868 @@
+{- git-annex test suite framework
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Test.Framework where
+
+import Test.Tasty
+import Test.Tasty.Runners
+import Test.Tasty.HUnit
+import Test.Tasty.Options
+import Test.Tasty.Ingredients.Rerun
+import Test.Tasty.Ingredients.ConsoleReporter
+import qualified Test.Tasty.Patterns.Types as TP
+import Options.Applicative.Types
+import Control.Concurrent
+import Control.Concurrent.Async
+import Control.Concurrent.STM
+import System.Environment (getArgs)
+import System.Console.Concurrent
+import System.Console.ANSI
+import Data.Time.Clock
+import GHC.Conc
+import System.IO.Unsafe (unsafePerformIO)
+import System.PosixCompat.Files (isSymbolicLink, isRegularFile, fileMode, unionFileModes, ownerWriteMode)
+
+import Common
+import Types.Test
+import Types.Concurrency
+import qualified Utility.RawFilePath as R
+
+import qualified Annex
+import qualified Annex.UUID
+import qualified Types.RepoVersion
+import qualified Backend
+import qualified Git.CurrentRepo
+import qualified Git.Construct
+import qualified Git.Types
+import qualified Git.Branch
+import qualified Git.Ref
+import qualified Types.KeySource
+import qualified Types.Backend
+import qualified Types
+import qualified Remote
+import qualified Key
+import qualified Types.Key
+import qualified Types.Messages
+import qualified Config
+import qualified Annex.WorkTree
+import qualified Annex.Link
+import qualified Annex.Path
+import qualified Annex.Action
+import qualified Annex.AdjustedBranch
+import qualified Annex.Init
+import qualified Utility.Process
+import qualified Utility.Process.Transcript
+import qualified Utility.Env
+import qualified Utility.Env.Set
+import qualified Utility.Exception
+import qualified Utility.ThreadScheduler
+import qualified Utility.Tmp.Dir
+import qualified Utility.Metered
+import qualified Utility.HumanTime
+import qualified Command.Uninit
+
+-- Run a process. The output and stderr is captured, and is only
+-- displayed if the process does not return the expected value.
+--
+-- In debug mode, the output is allowed to pass through.
+-- So the output does not get checked in debug mode.
+testProcess :: String -> [String] -> Maybe [(String, String)] -> (Bool -> Bool) -> (String -> Bool) -> String -> Assertion
+testProcess command params environ expectedret expectedtranscript faildesc = do
+	let p = (proc command params) { env = environ }
+	debug <- testDebug . testOptions <$> getTestMode
+	if debug
+		then do
+			ret <- withCreateProcess p $ \_ _ _ pid ->
+				waitForProcess pid
+			(expectedret (ret == ExitSuccess)) @? (faildesc ++ " failed with unexpected exit code")
+		else do
+			(transcript, ret) <- Utility.Process.Transcript.processTranscript' p Nothing
+			(expectedret ret) @? (faildesc ++ " failed with unexpected exit code (transcript follows)\n" ++ transcript)
+			(expectedtranscript transcript) @? (faildesc ++ " failed with unexpected output (transcript follows)\n" ++ transcript)
+
+-- Run git. (Do not use to run git-annex as the one being tested
+-- may not be in path.)
+git :: String -> [String] -> String -> Assertion
+git command params = testProcess "git" (command:params) Nothing (== True) (const True)
+
+-- For when git is expected to fail.
+git_shouldfail :: String -> [String] -> String -> Assertion
+git_shouldfail command params = testProcess "git" (command:params) Nothing (== False) (const True)
+
+-- Run git-annex.
+git_annex :: String -> [String] -> String -> Assertion
+git_annex command params faildesc = git_annex' command params Nothing faildesc
+
+-- Runs git-annex with some environment.
+git_annex' :: String -> [String] -> Maybe [(String, String)] -> String -> Assertion
+git_annex' = git_annex'' (== True) (const True)
+
+-- For when git-annex is expected to fail.
+git_annex_shouldfail :: String -> [String] -> String -> Assertion
+git_annex_shouldfail command params faildesc = git_annex_shouldfail' command params Nothing faildesc
+
+git_annex_shouldfail' :: String -> [String] -> Maybe [(String, String)] -> String -> Assertion
+git_annex_shouldfail' = git_annex'' (== False) (const True)
+
+git_annex'' :: (Bool -> Bool) -> (String -> Bool) -> String -> [String] -> Maybe [(String, String)] -> String -> Assertion
+git_annex'' expectedret expectedtranscript command params environ faildesc = do
+	pp <- Annex.Path.programPath
+	debug <- testDebug . testOptions <$> getTestMode
+	let params' = if debug
+		then "--debug":params
+		else params
+	testProcess pp (command:params') environ expectedret expectedtranscript faildesc
+
+{- Runs git-annex and returns its standard output. -}
+git_annex_output :: String -> [String] -> IO String
+git_annex_output command params = do
+	pp <- Annex.Path.programPath
+	Utility.Process.readProcess pp (command:params)
+
+git_annex_expectoutput :: String -> [String] -> [String] -> Assertion
+git_annex_expectoutput command params expected = do
+	got <- lines <$> git_annex_output command params
+	got == expected @? ("unexpected value running " ++ command ++ " " ++ show params ++ " -- got: " ++ show got ++ " expected: " ++ show expected)
+
+-- Runs an action in the current annex. Note that shutdown actions
+-- are not run; this should only be used for actions that query state.
+annexeval :: Types.Annex a -> IO a
+annexeval a = do
+	s <- Annex.new =<< Git.CurrentRepo.get
+	Annex.eval s $ do
+		Annex.setOutput Types.Messages.QuietOutput
+		a `finally` Annex.Action.stopCoProcesses
+
+innewrepo :: IO () -> IO ()
+innewrepo a = withgitrepo $ \r -> indir r a
+
+inmainrepo :: IO a -> IO a
+inmainrepo a = do
+	d <- mainrepodir
+	indir d a
+
+with_ssh_origin :: (Assertion -> Assertion) -> (Assertion -> Assertion)
+with_ssh_origin cloner a = cloner $ do
+	let k = Git.Types.ConfigKey (encodeBS config)
+	let v = Git.Types.ConfigValue (toRawFilePath "/dev/null")
+	origindir <- absPath . Git.Types.fromConfigValue
+		=<< annexeval (Config.getConfig k v)
+	let originurl = "localhost:" ++ fromRawFilePath origindir
+	git "config" [config, originurl] "git config failed"
+	a
+  where
+	config = "remote.origin.url"
+
+intmpclonerepo :: Assertion -> Assertion
+intmpclonerepo a = withtmpclonerepo $ \r -> indir r a
+
+checkRepo :: Types.Annex a -> FilePath -> IO a
+checkRepo getval d = do
+	s <- Annex.new =<< Git.Construct.fromPath (toRawFilePath d)
+	Annex.eval s $
+		getval `finally` Annex.Action.stopCoProcesses
+
+intmpbareclonerepo :: Assertion -> Assertion
+intmpbareclonerepo a = withtmpclonerepo' (newCloneRepoConfig { bareClone = True } ) $
+	\r -> indir r a
+
+intmpsharedclonerepo :: Assertion -> Assertion
+intmpsharedclonerepo a = withtmpclonerepo' (newCloneRepoConfig { sharedClone = True } ) $
+	\r -> indir r a
+
+withtmpclonerepo :: (FilePath -> Assertion) -> Assertion
+withtmpclonerepo = withtmpclonerepo' newCloneRepoConfig
+
+withtmpclonerepo' :: CloneRepoConfig -> (FilePath -> Assertion) -> Assertion
+withtmpclonerepo' cfg a = do
+	dir <- tmprepodir
+	maindir <- mainrepodir
+	clone <- clonerepo maindir dir cfg
+	r <- tryNonAsync (a clone)
+	case r of
+		Right () -> return ()
+		Left e -> do
+			whenM (keepFailuresOption . testOptions <$> getTestMode) $
+				putStrLn $ "** Preserving repo for failure analysis in " ++ clone
+			throwM e
+
+disconnectOrigin :: Assertion
+disconnectOrigin = git "remote" ["rm", "origin"] "remote rm"
+
+withgitrepo :: (FilePath -> Assertion) -> Assertion
+withgitrepo a = do
+	maindir <- mainrepodir
+	bracket (setuprepo maindir) return a
+
+indir :: FilePath -> IO a -> IO a
+indir dir a = do
+	currdir <- getCurrentDirectory
+	-- Assertion failures throw non-IO errors; catch
+	-- any type of error and change back to currdir before
+	-- rethrowing.
+	r <- bracket_
+		(changeToTopDir dir)
+		(setCurrentDirectory currdir)
+		(tryNonAsync a)
+	case r of
+		Right v -> return v
+		Left e -> throwM e
+
+adjustedbranchsupported :: FilePath -> IO Bool
+adjustedbranchsupported repo = indir repo $ Annex.AdjustedBranch.isGitVersionSupported
+
+setuprepo :: FilePath -> IO FilePath
+setuprepo dir = do
+	cleanup dir
+	git "init" ["-q", dir] "git init"
+	configrepo dir
+	return dir
+
+data CloneRepoConfig = CloneRepoConfig
+	{ bareClone :: Bool
+	, sharedClone :: Bool
+	}
+
+newCloneRepoConfig :: CloneRepoConfig
+newCloneRepoConfig = CloneRepoConfig
+	{ bareClone = False
+	, sharedClone = False
+	}
+
+-- clones are always done as local clones; we cannot test ssh clones
+clonerepo :: FilePath -> FilePath -> CloneRepoConfig -> IO FilePath
+clonerepo old new cfg = do
+	cleanup new
+	let cloneparams = catMaybes
+		[ Just "-q"
+		, if bareClone cfg then Just "--bare" else Nothing
+		, if sharedClone cfg then Just "--shared" else Nothing
+		, Just old
+		, Just new
+		]
+	git "clone" cloneparams "git clone"
+	configrepo new
+	indir new $ do
+		ver <- annexVersion <$> getTestMode
+		git_annex "init" 
+			[ "-q"
+			, new, "--version"
+			, show (Types.RepoVersion.fromRepoVersion ver)
+			]
+			"git annex init"
+	unless (bareClone cfg) $
+		indir new $
+			setupTestMode
+	return new
+
+configrepo :: FilePath -> IO ()
+configrepo dir = indir dir $ do
+	-- ensure git is set up to let commits happen
+	git "config" ["user.name", "Test User"]
+		"git config"
+	git "config" ["user.email", "test@example.com"]
+		"git config"
+	-- avoid signed commits by test suite
+	git "config" ["commit.gpgsign", "false"]
+		"git config"
+	-- tell git-annex to not annex the ingitfile
+	git "config" ["annex.largefiles", "exclude=" ++ ingitfile]
+		"git config annex.largefiles"
+	-- set any additional git configs the user wants to test with
+	gc <- testGitConfig . testOptions <$> getTestMode
+	forM_ gc $ \case
+		(Git.Types.ConfigKey k, Git.Types.ConfigValue v) -> 
+			git "config" [decodeBS k, decodeBS v]
+				"git config from test options"
+		(Git.Types.ConfigKey _, Git.Types.NoConfigValue) -> noop
+
+ensuredir :: FilePath -> IO ()
+ensuredir d = do
+	e <- doesDirectoryExist d
+	unless e $
+		createDirectory d
+
+{- This is the only place in the test suite that can use setEnv.
+ - Using it elsewhere can conflict with tasty's use of getEnv, which can
+ - happen concurrently with a test case running, and would be a problem
+ - since setEnv is not thread safe. This is run before tasty. -}
+setTestEnv :: IO a -> IO a
+setTestEnv a = Utility.Tmp.Dir.withTmpDir "testhome" $ \tmphome -> do
+	tmphomeabs <- fromRawFilePath <$> absPath (toRawFilePath tmphome)
+	{- Prevent global git configs from affecting the test suite. -}
+	Utility.Env.Set.setEnv "HOME" tmphomeabs True
+	Utility.Env.Set.setEnv "XDG_CONFIG_HOME" tmphomeabs True
+	Utility.Env.Set.setEnv "GIT_CONFIG_NOSYSTEM" "1" True
+	
+	-- Ensure that the same git-annex binary that is running
+	-- git-annex test is at the front of the PATH.
+	p <- Utility.Env.getEnvDefault "PATH" ""
+	pp <- Annex.Path.programPath
+	Utility.Env.Set.setEnv "PATH" (takeDirectory pp ++ [searchPathSeparator] ++ p) True
+	
+	-- Avoid git complaining if it cannot determine the user's
+	-- email address, or exploding if it doesn't know the user's name.
+	Utility.Env.Set.setEnv "GIT_AUTHOR_EMAIL" "test@example.com" True
+	Utility.Env.Set.setEnv "GIT_AUTHOR_NAME" "git-annex test" True
+	Utility.Env.Set.setEnv "GIT_COMMITTER_EMAIL" "test@example.com" True
+	Utility.Env.Set.setEnv "GIT_COMMITTER_NAME" "git-annex test" True
+	-- force gpg into batch mode for the tests
+	Utility.Env.Set.setEnv "GPG_BATCH" "1" True
+	-- Make git and git-annex access ssh remotes on the local
+	-- filesystem, without using ssh at all.
+	Utility.Env.Set.setEnv "GIT_SSH_COMMAND" "git-annex test --fakessh --" True
+	Utility.Env.Set.setEnv "GIT_ANNEX_USE_GIT_SSH" "1" True
+
+	-- Record top directory.
+	currdir <- getCurrentDirectory
+	Utility.Env.Set.setEnv "TOPDIR" currdir True
+	
+	a
+
+removeDirectoryForCleanup :: FilePath -> IO ()
+removeDirectoryForCleanup = removePathForcibly
+
+cleanup :: FilePath -> IO ()
+cleanup dir = whenM (doesDirectoryExist dir) $ do
+	Command.Uninit.prepareRemoveAnnexDir' dir
+	-- This can fail if files in the directory are still open by a
+	-- subprocess.
+	void $ tryIO $ removeDirectoryForCleanup dir
+
+finalCleanup :: IO ()
+finalCleanup = whenM (doesDirectoryExist tmpdir) $ do
+	Command.Uninit.prepareRemoveAnnexDir' tmpdir
+	catchIO (removeDirectoryForCleanup tmpdir) $ \e -> do
+		print e
+		putStrLn "sleeping 10 seconds and will retry directory cleanup"
+		Utility.ThreadScheduler.threadDelaySeconds $
+			Utility.ThreadScheduler.Seconds 10
+		whenM (doesDirectoryExist tmpdir) $
+			removeDirectoryForCleanup tmpdir
+
+checklink :: FilePath -> Assertion
+checklink f = ifM (annexeval Config.crippledFileSystem)
+	( (isJust <$> annexeval (Annex.Link.getAnnexLinkTarget (toRawFilePath f)))
+		@? f ++ " is not a (crippled) symlink"
+	, do
+		s <- R.getSymbolicLinkStatus (toRawFilePath f)
+		isSymbolicLink s @? f ++ " is not a symlink"
+	)
+
+checkregularfile :: FilePath -> Assertion
+checkregularfile f = do
+	s <- R.getSymbolicLinkStatus (toRawFilePath f)
+	isRegularFile s @? f ++ " is not a normal file"
+	return ()
+
+checkdoesnotexist :: FilePath -> Assertion
+checkdoesnotexist f = 
+	(either (const True) (const False) <$> Utility.Exception.tryIO (R.getSymbolicLinkStatus (toRawFilePath f)))
+		@? f ++ " exists unexpectedly"
+
+checkexists :: FilePath -> Assertion
+checkexists f = 
+	(either (const False) (const True) <$> Utility.Exception.tryIO (R.getSymbolicLinkStatus (toRawFilePath f)))
+		@? f ++ " does not exist"
+
+checkcontent :: FilePath -> Assertion
+checkcontent f = do
+	c <- Utility.Exception.catchDefaultIO "could not read file" $ readFile f
+	assertEqual ("checkcontent " ++ f) (content f) c
+
+checkunwritable :: FilePath -> Assertion
+checkunwritable f = do
+	-- Look at permissions bits rather than trying to write or
+	-- using fileAccess because if run as root, any file can be
+	-- modified despite permissions.
+	s <- R.getFileStatus (toRawFilePath f)
+	let mode = fileMode s
+	when (mode == mode `unionFileModes` ownerWriteMode) $
+		assertFailure $ "able to modify annexed file's " ++ f ++ " content"
+
+checkwritable :: FilePath -> Assertion
+checkwritable f = do
+	s <- R.getFileStatus (toRawFilePath f)
+	let mode = fileMode s
+	unless (mode == mode `unionFileModes` ownerWriteMode) $
+		assertFailure $ "unable to modify " ++ f
+
+checkdangling :: FilePath -> Assertion
+checkdangling f = ifM (annexeval Config.crippledFileSystem)
+	( return () -- probably no real symlinks to test
+	, do
+		r <- tryIO $ readFile f
+		case r of
+			Left _ -> return () -- expected; dangling link
+			Right _ -> assertFailure $ f ++ " was not a dangling link as expected"
+	)
+
+checklocationlog :: FilePath -> Bool -> Assertion
+checklocationlog f expected = do
+	thisuuid <- annexeval Annex.UUID.getUUID
+	r <- annexeval $ Annex.WorkTree.lookupKey (toRawFilePath f)
+	case r of
+		Just k -> do
+			uuids <- annexeval $ Remote.keyLocations k
+			assertEqual ("bad content in location log for " ++ f ++ " key " ++ Key.serializeKey k ++ " uuid " ++ show thisuuid)
+				expected (thisuuid `elem` uuids)
+		_ -> assertFailure $ f ++ " failed to look up key"
+
+checkbackend :: FilePath -> Types.Backend -> Assertion
+checkbackend file expected = do
+	b <- annexeval $ maybe (return Nothing) (Backend.getBackend file) 
+		=<< Annex.WorkTree.lookupKey (toRawFilePath file)
+	assertEqual ("backend for " ++ file) (Just expected) b
+
+checkispointerfile :: FilePath -> Assertion
+checkispointerfile f = unlessM (isJust <$> Annex.Link.isPointerFile (toRawFilePath f)) $
+	assertFailure $ f ++ " is not a pointer file"
+
+inlocationlog :: FilePath -> Assertion
+inlocationlog f = checklocationlog f True
+
+notinlocationlog :: FilePath -> Assertion
+notinlocationlog f = checklocationlog f False
+
+runchecks :: [FilePath -> Assertion] -> FilePath -> Assertion
+runchecks [] _ = return ()
+runchecks (a:as) f = do
+	a f
+	runchecks as f
+
+annexed_notpresent :: FilePath -> Assertion
+annexed_notpresent f = ifM (hasUnlockedFiles <$> getTestMode)
+	( annexed_notpresent_unlocked f
+	, annexed_notpresent_locked f
+	)
+
+annexed_notpresent_locked :: FilePath -> Assertion
+annexed_notpresent_locked = runchecks [checklink, checkdangling, notinlocationlog]
+
+annexed_notpresent_unlocked :: FilePath -> Assertion
+annexed_notpresent_unlocked = runchecks [checkregularfile, checkispointerfile, notinlocationlog]
+
+annexed_present :: FilePath -> Assertion
+annexed_present f = ifM (hasUnlockedFiles <$> getTestMode)
+	( annexed_present_unlocked f
+	, annexed_present_locked f
+	)
+
+annexed_present_locked :: FilePath -> Assertion
+annexed_present_locked f = ifM (annexeval Config.crippledFileSystem)
+	( runchecks [checklink, inlocationlog] f
+	, runchecks [checklink, checkcontent, checkunwritable, inlocationlog] f
+	)
+
+annexed_present_unlocked :: FilePath -> Assertion
+annexed_present_unlocked = runchecks
+	[checkregularfile, checkcontent, checkwritable, inlocationlog]
+	
+annexed_present_imported :: FilePath -> Assertion
+annexed_present_imported f = ifM (annexeval Config.crippledFileSystem)
+	( annexed_present_unlocked f
+	, ifM (adjustedUnlockedBranch <$> getTestMode) 
+		( annexed_present_unlocked f
+		, annexed_present_locked f
+		)
+	)
+
+annexed_notpresent_imported :: FilePath -> Assertion
+annexed_notpresent_imported f = ifM (annexeval Config.crippledFileSystem)
+	( annexed_notpresent_unlocked f
+	, ifM (adjustedUnlockedBranch <$> getTestMode)
+		( annexed_notpresent_unlocked f
+		, annexed_notpresent_locked f
+		)
+	)
+
+unannexed :: FilePath -> Assertion
+unannexed = runchecks [checkregularfile, checkcontent, checkwritable]
+
+-- Check that a file is unannexed, but also that what's recorded in git
+-- is not an annexed file.
+unannexed_in_git :: FilePath -> Assertion
+unannexed_in_git f = do
+	unannexed f
+	r <- annexeval $ Annex.WorkTree.lookupKey (toRawFilePath f)
+	case r of
+		Just _k -> assertFailure $ f ++ " is annexed in git"
+		Nothing -> return ()
+
+add_annex :: FilePath -> String -> Assertion
+add_annex f faildesc = ifM (unlockedFiles <$> getTestMode)
+	( git "add" [f] faildesc
+	, git_annex "add" [f] faildesc
+	)
+
+data TestMode = TestMode
+	{ unlockedFiles :: Bool
+	, adjustedUnlockedBranch :: Bool
+	, annexVersion :: Types.RepoVersion.RepoVersion
+	, testOptions :: TestOptions
+	}
+
+testMode :: TestOptions -> Types.RepoVersion.RepoVersion -> TestMode
+testMode opts v = TestMode
+	{ unlockedFiles = False
+	, adjustedUnlockedBranch = False
+	, annexVersion = v
+	, testOptions = opts
+	}
+
+hasUnlockedFiles :: TestMode -> Bool
+hasUnlockedFiles m = unlockedFiles m || adjustedUnlockedBranch m
+
+withTestMode :: TestMode -> TestTree -> TestTree
+withTestMode testmode = withResource prepare release . const
+  where
+	prepare = setTestMode testmode
+	release _ = noop
+
+{- The current test mode is stored here while a test is running.
+ -
+ - Only one test can be running at a time by a process; running a
+ - test also involves chdir into a test repository.
+ -}
+{-# NOINLINE currentTestMode #-}
+currentTestMode :: TMVar TestMode
+currentTestMode = unsafePerformIO newEmptyTMVarIO
+
+currentMainRepoDir :: TMVar FilePath
+currentMainRepoDir = unsafePerformIO newEmptyTMVarIO
+
+setTestMode :: TestMode -> IO ()
+setTestMode testmode = do
+	atomically $ do
+		_ <- tryTakeTMVar currentTestMode
+		putTMVar currentTestMode testmode
+	setmainrepodir =<< newmainrepodir
+
+getTestMode :: IO TestMode
+getTestMode = atomically (tryReadTMVar currentTestMode) >>= \case
+	Just tm -> return tm
+	Nothing -> error "getTestMode without setTestMode"
+
+setupTestMode :: IO ()
+setupTestMode = do
+	testmode <- getTestMode
+	when (adjustedUnlockedBranch testmode) $ do
+		git "commit" ["--allow-empty", "-m", "empty"] "git commit failed"
+		git_annex "adjust" ["--unlock"] "git annex adjust failed"
+
+changeToTopDir :: FilePath -> IO ()
+changeToTopDir t = do
+	topdir <- Utility.Env.getEnvDefault "TOPDIR" (error "TOPDIR not set")
+	setCurrentDirectory $ topdir ++ "/" ++ t
+
+tmpdir :: String
+tmpdir = ".t"
+
+setmainrepodir :: FilePath -> IO ()
+setmainrepodir mrd = atomically $ do
+	_ <- tryTakeTMVar currentMainRepoDir
+	putTMVar currentMainRepoDir mrd
+
+mainrepodir :: IO FilePath
+mainrepodir = atomically (tryReadTMVar currentMainRepoDir) >>= \case
+	Just tm -> return tm
+	Nothing -> error "mainrepodir without setmainrepodir"
+
+newmainrepodir :: IO FilePath
+newmainrepodir = go (0 :: Int)
+  where
+	go n = do
+		let d = "main" ++ show n
+		ifM (doesDirectoryExist d)
+			( go $ n + 1
+			, do
+				createDirectory d
+				return d
+			)
+
+tmprepodir :: IO FilePath
+tmprepodir = go (0 :: Int)
+  where
+	go n = do
+		let d = "tmprepo" ++ show n
+		ifM (doesDirectoryExist d)
+			( go $ n + 1
+			, return d
+			)
+
+annexedfile :: String
+annexedfile = "foo"
+
+annexedfiledup :: String
+annexedfiledup = "foodup"
+
+wormannexedfile :: String
+wormannexedfile = "apple"
+
+sha1annexedfile :: String
+sha1annexedfile = "sha1foo"
+
+sha1annexedfiledup :: String
+sha1annexedfiledup = "sha1foodup"
+
+ingitfile :: String
+ingitfile = "bar.c"
+
+content :: FilePath -> String		
+content f
+	| f == annexedfile = "annexed file content"
+	| f == ingitfile = "normal file content"
+	| f == sha1annexedfile ="sha1 annexed file content"
+	| f == annexedfiledup = content annexedfile
+	| f == sha1annexedfiledup = content sha1annexedfile
+	| f == wormannexedfile = "worm annexed file content"
+	| "import" `isPrefixOf` f = "imported content"
+	| otherwise = "unknown file " ++ f
+
+-- Writes new content to a file, and makes sure that it has a different
+-- mtime than it did before
+writecontent :: FilePath -> String -> IO ()
+writecontent f c = go (10000000 :: Integer)
+  where
+	go ticsleft = do
+		oldmtime <- catchMaybeIO $ getModificationTime f
+		writeFile f c
+		newmtime <- getModificationTime f
+		if Just newmtime == oldmtime
+			then do
+				threadDelay 100000
+				let ticsleft' = ticsleft - 100000
+				if ticsleft' > 0
+					then go ticsleft'
+					else do
+						hPutStrLn stderr "file mtimes do not seem to be changing (tried for 10 seconds)"
+						hFlush stderr
+						return ()
+			else return ()
+
+changecontent :: FilePath -> IO ()
+changecontent f = writecontent f $ changedcontent f
+
+changedcontent :: FilePath -> String
+changedcontent f = content f ++ " (modified)"
+
+backendSHA1 :: Types.Backend
+backendSHA1 = backend_ "SHA1"
+
+backendSHA256 :: Types.Backend
+backendSHA256 = backend_ "SHA256"
+
+backendSHA256E :: Types.Backend
+backendSHA256E = backend_ "SHA256E"
+
+backendWORM :: Types.Backend
+backendWORM = backend_ "WORM"
+
+backend_ :: String -> Types.Backend
+backend_ = Backend.lookupBuiltinBackendVariety . Types.Key.parseKeyVariety . encodeBS
+
+getKey :: Types.Backend -> FilePath -> IO Types.Key
+getKey b f = case Types.Backend.genKey b of
+	Just a -> annexeval $ a ks Utility.Metered.nullMeterUpdate
+	Nothing -> error "internal"
+  where
+	ks = Types.KeySource.KeySource
+		{ Types.KeySource.keyFilename = toRawFilePath f
+		, Types.KeySource.contentLocation = toRawFilePath f
+		, Types.KeySource.inodeCache = Nothing
+		}
+
+{- Get the name of the original branch, eg the current branch, or
+ - if in an adjusted branch, the parent branch. -}
+origBranch :: Types.Annex String
+origBranch = maybe "foo"
+	(Git.Types.fromRef . Git.Ref.base . Annex.AdjustedBranch.fromAdjustedBranch)
+	<$> Annex.inRepo Git.Branch.current
+
+{- Set up repos as remotes of each other. -}
+pair :: FilePath -> FilePath -> Assertion
+pair r1 r2 = forM_ [r1, r2] $ \r -> indir r $ do
+	when (r /= r1) $
+		git "remote" ["add", "r1", "../" ++ r1] "remote add"
+	when (r /= r2) $
+		git "remote" ["add", "r2", "../" ++ r2] "remote add"
+
+
+{- Runs a query in the current repository, but first makes the repository
+ - read-only. The write bit is added back at the end, so when possible, 
+ - include multiple tests within a single call for efficiency. -}
+readonly_query :: Assertion -> Assertion
+readonly_query = bracket_ (make_readonly ".") (make_writeable ".")
+	
+{- Not guaranteed to do anything: 
+ - chmod may fail, or not be available, or the filesystem not support
+ - permissions. -}
+make_readonly :: FilePath -> IO ()
+make_readonly d = void $
+	Utility.Process.Transcript.processTranscript
+		"chmod" ["-R", "-w", d] Nothing
+
+{- The write bit is added back for the current user, but not for other
+ - users, even though make_readonly removes any other user's write bits. -}
+make_writeable :: FilePath -> IO ()
+make_writeable d = void $
+	Utility.Process.Transcript.processTranscript
+		"chmod" ["-R", "u+w", d] Nothing
+
+runFakeSsh :: [String] -> IO ()
+runFakeSsh ("-n":ps) = runFakeSsh ps
+runFakeSsh (_host:cmd:[]) =
+	withCreateProcess (shell cmd) $
+		\_ _ _ pid -> exitWith =<< waitForProcess pid
+runFakeSsh ps = error $ "fake ssh option parse error: " ++ show ps
+
+{- Tests each TestTree in parallel, and exits with success/failure.
+ -
+ - Tasty supports parallel tests, but this does not use it, because
+ - many tests need to be run in test repos, and chdir would not be 
+ - thread safe. Instead, this starts one child process for each TestTree.
+ -
+ - An added benefit of using child processes is that any files they may
+ - leave open are closed before finalCleanup is run at the end. This
+ - prevents some failures to clean up after the test suite.
+ -}
+parallelTestRunner :: TestOptions -> (Int -> Bool -> Bool -> TestOptions -> [TestTree]) -> IO ()
+parallelTestRunner opts mkts = do
+	numjobs <- case concurrentJobs opts of
+		Just NonConcurrent -> pure 1
+		Just (Concurrent n) -> pure n
+		Just ConcurrentPerCpu -> getNumProcessors
+		Nothing -> getNumProcessors
+	parallelTestRunner' numjobs opts mkts
+
+parallelTestRunner' :: Int -> TestOptions -> (Int -> Bool -> Bool -> TestOptions -> [TestTree]) -> IO ()
+parallelTestRunner' numjobs opts mkts
+	| fakeSsh opts = runFakeSsh (internalData opts)
+	| otherwise = go =<< Utility.Env.getEnv subenv
+  where
+	subenv = "GIT_ANNEX_TEST_SUBPROCESS"
+
+	-- Make more parts than there are jobs, because some parts
+	-- are larger, and this allows the smaller parts to be packed
+	-- in more efficiently, speeding up the test suite overall.
+	--
+	-- When there is a pattern, splitting into parts will cause
+	-- extra work.
+	numparts = if haspattern
+		then 1
+		else numjobs * 2
+
+	worker rs nvar a = do
+		(n, m) <- atomically $ do
+			(n, m) <- readTVar nvar
+			writeTVar nvar (n+1, m)
+			return (n, m)
+		if n > m
+			then return rs
+			else do
+				r <- a n
+				worker (r:rs) nvar a
+	
+	summarizeresults a = do
+		starttime <- getCurrentTime
+		(numts, exitcodes) <- a
+		duration <- Utility.HumanTime.durationSince starttime
+		case nub (filter (/= ExitSuccess) (concat exitcodes)) of
+			[] -> do
+				putStrLn ""
+				putStrLn $ "All tests succeeded. (Ran "
+					++ show numts
+					++ " test groups in " 
+					++ Utility.HumanTime.fromDuration duration
+					++ ")"
+				exitSuccess
+			[ExitFailure 1] -> do
+				putStrLn "  (Failures above could be due to a bug in git-annex, or an incompatibility"
+				putStrLn "   with utilities, such as git, installed on this system.)"
+				exitFailure
+			_ -> do
+				putStrLn $ "  Test subprocesses exited with unexpected exit codes: " ++ show (concat exitcodes)
+				exitFailure
+
+	go Nothing = summarizeresults $ withConcurrentOutput $ do
+		ensuredir tmpdir
+		crippledfilesystem <- fst <$> Annex.Init.probeCrippledFileSystem'
+			(toRawFilePath tmpdir)
+			Nothing Nothing False
+		adjustedbranchok <- Annex.AdjustedBranch.isGitVersionSupported
+		let ts = mkts numparts crippledfilesystem adjustedbranchok opts
+		let warnings = fst (tastyParser ts)
+		unless (null warnings) $ do
+			hPutStrLn stderr "warnings from tasty:"
+			mapM_ (hPutStrLn stderr) warnings
+		environ <- Utility.Env.getEnvironment
+		args <- getArgs
+		pp <- Annex.Path.programPath
+		termcolor <- hSupportsANSIColor stdout
+		let ps = if useColor (lookupOption tastyopts) termcolor
+			then "--color=always":args
+			else "--color=never":args
+		let runone n = do
+			let subdir = tmpdir </> show n
+			ensuredir subdir
+			let p = (proc pp ps)
+				{ env = Just ((subenv, show (n, crippledfilesystem, adjustedbranchok)):environ)
+				, cwd = Just subdir
+				}
+			(_, _, _, pid) <- createProcessConcurrent p
+			waitForProcess pid
+		nvar <- newTVarIO (1, length ts)
+		exitcodes <- forConcurrently [1..numjobs] $ \_ -> 
+			worker [] nvar runone
+		unless (keepFailuresOption opts) finalCleanup
+		return (length ts, exitcodes)
+	go (Just subenvval) = case readish subenvval of
+		Nothing -> error ("Bad " ++ subenv)
+		Just (n, crippledfilesystem, adjustedbranchok) -> setTestEnv $ do
+			let ts = mkts numparts crippledfilesystem adjustedbranchok opts
+			let t = topLevelTestGroup [ ts !! (n - 1) ]
+			case tryIngredients ingredients tastyopts t of
+				Nothing -> error "No tests found!?"
+				Just act -> ifM act
+					( exitSuccess
+					, exitFailure
+					)
+	
+	(haspattern, tastyopts) = case lookupOption (tastyOptionSet opts) of
+		-- Work around limitation of tasty; when tests to run
+		-- are limited to a pattern, it does not include their
+		-- dependencies. So, add another pattern including the
+		-- init tests, which are a dependency of most tests.
+		TestPattern (Just p) -> 
+			(True, setOption (TestPattern (Just (TP.Or p (TP.ERE initTestsName))))
+				(tastyOptionSet opts))
+		TestPattern Nothing ->
+			(False, tastyOptionSet opts)
+
+topLevelTestGroup :: [TestTree] -> TestTree
+topLevelTestGroup = testGroup "Tests"
+
+initTestsName :: String
+initTestsName = "Init Tests"
+
+tastyParser :: [TestTree] -> ([String], Parser Test.Tasty.Options.OptionSet)
+#if MIN_VERSION_tasty(1,3,0)
+tastyParser ts = go
+#else
+tastyParser ts = ([], go)
+#endif
+  where
+ 	go = suiteOptionParser ingredients (topLevelTestGroup ts)
+
+ingredients :: [Ingredient]
+ingredients =
+	[ listingTests
+	, rerunningTests [consoleTestReporter]
+	]
+
diff --git a/Types.hs b/Types.hs
new file mode 100644
index 0000000000..43c945e12a
--- /dev/null
+++ b/Types.hs
@@ -0,0 +1,31 @@
+{- git-annex abstract data types
+ -
+ - Copyright 2010 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types (
+	Annex,
+	Backend,
+	Key,
+	AssociatedFile(..),
+	UUID(..),
+	GitConfig(..),
+	RemoteGitConfig(..),
+	Remote,
+	RemoteType,
+	VerifyConfig,
+) where
+
+import Annex
+import Types.Backend
+import Types.GitConfig
+import Types.Key
+import Types.UUID
+import Types.Remote
+
+type Backend = BackendA Annex
+type Remote = RemoteA Annex
+type RemoteType = RemoteTypeA Annex
+type VerifyConfig = VerifyConfigA Annex
diff --git a/Types/ActionItem.hs b/Types/ActionItem.hs
new file mode 100644
index 0000000000..8ba52b1107
--- /dev/null
+++ b/Types/ActionItem.hs
@@ -0,0 +1,115 @@
+{- items that a command can act on
+ -
+ - Copyright 2016-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-}
+
+module Types.ActionItem (
+	module Types.ActionItem,
+	StringContainingQuotedPath(..),
+) where
+
+import Key
+import Types.Transfer
+import Types.UUID
+import Types.FileMatcher
+import Git.FilePath
+import Git.Quote (StringContainingQuotedPath(..))
+import Utility.FileSystemEncoding
+
+data ActionItem 
+	= ActionItemAssociatedFile AssociatedFile Key
+	| ActionItemKey Key
+	| ActionItemBranchFilePath BranchFilePath Key
+	| ActionItemFailedTransfer Transfer TransferInfo
+	| ActionItemTreeFile RawFilePath
+	| ActionItemUUID UUID StringContainingQuotedPath
+	-- ^ UUID with a description or name of the repository
+	| ActionItemOther (Maybe StringContainingQuotedPath)
+	| OnlyActionOn Key ActionItem
+	-- ^ Use to avoid more than one thread concurrently processing the
+	-- same Key.
+	deriving (Show, Eq)
+
+class MkActionItem t where
+	mkActionItem :: t -> ActionItem
+
+instance MkActionItem ActionItem where
+	mkActionItem = id
+
+instance MkActionItem (AssociatedFile, Key) where
+	mkActionItem = uncurry ActionItemAssociatedFile
+
+instance MkActionItem (Key, AssociatedFile) where
+	mkActionItem = uncurry $ flip ActionItemAssociatedFile
+
+instance MkActionItem (Key, RawFilePath) where
+	mkActionItem (key, file) = ActionItemAssociatedFile (AssociatedFile (Just file)) key
+
+instance MkActionItem (RawFilePath, Key) where
+	mkActionItem (file, key) = mkActionItem (key, file)
+
+instance MkActionItem Key where
+	mkActionItem = ActionItemKey
+
+instance MkActionItem (BranchFilePath, Key) where
+	mkActionItem = uncurry ActionItemBranchFilePath
+
+instance MkActionItem (Transfer, TransferInfo) where
+	mkActionItem = uncurry ActionItemFailedTransfer
+
+instance MkActionItem MatchInfo where
+	mkActionItem (MatchingFile i) = ActionItemTreeFile (matchFile i)
+	mkActionItem (MatchingInfo i) = case providedFilePath i of
+		Just f -> ActionItemTreeFile f
+		Nothing -> case providedKey i of
+			Just k -> ActionItemKey k
+			Nothing -> ActionItemOther Nothing
+	mkActionItem (MatchingUserInfo _) = ActionItemOther Nothing
+
+actionItemDesc :: ActionItem -> StringContainingQuotedPath
+actionItemDesc (ActionItemAssociatedFile (AssociatedFile (Just f)) _) = 
+	QuotedPath f
+actionItemDesc (ActionItemAssociatedFile (AssociatedFile Nothing) k) = 
+	UnquotedByteString (serializeKey' k)
+actionItemDesc (ActionItemKey k) =
+	UnquotedByteString (serializeKey' k)
+actionItemDesc (ActionItemBranchFilePath bfp _) =
+	descBranchFilePath bfp
+actionItemDesc (ActionItemFailedTransfer t i) = actionItemDesc $
+	ActionItemAssociatedFile (associatedFile i) (transferKey t)
+actionItemDesc (ActionItemTreeFile f) = QuotedPath f
+actionItemDesc (ActionItemUUID _ desc) = desc
+actionItemDesc (ActionItemOther Nothing) = mempty
+actionItemDesc (ActionItemOther (Just v)) = v
+actionItemDesc (OnlyActionOn _ ai) = actionItemDesc ai
+
+actionItemKey :: ActionItem -> Maybe Key
+actionItemKey (ActionItemAssociatedFile _ k) = Just k
+actionItemKey (ActionItemKey k) = Just k
+actionItemKey (ActionItemBranchFilePath _ k) = Just k
+actionItemKey (ActionItemFailedTransfer t _) = Just (transferKey t)
+actionItemKey (ActionItemTreeFile _) = Nothing
+actionItemKey (ActionItemUUID _ _) = Nothing
+actionItemKey (ActionItemOther _) = Nothing
+actionItemKey (OnlyActionOn _ ai) = actionItemKey ai
+
+actionItemFile :: ActionItem -> Maybe RawFilePath
+actionItemFile (ActionItemAssociatedFile (AssociatedFile af) _) = af
+actionItemFile (ActionItemTreeFile f) = Just f
+actionItemFile (ActionItemUUID _ _) = Nothing
+actionItemFile (OnlyActionOn _ ai) = actionItemFile ai
+actionItemFile _ = Nothing
+
+actionItemUUID :: ActionItem -> Maybe UUID
+actionItemUUID (ActionItemUUID uuid _) = Just uuid
+actionItemUUID _ = Nothing
+
+actionItemTransferDirection :: ActionItem -> Maybe Direction
+actionItemTransferDirection (ActionItemFailedTransfer t _) = Just $
+	transferDirection t
+actionItemTransferDirection (OnlyActionOn _ ai) = actionItemTransferDirection ai
+actionItemTransferDirection _ = Nothing
diff --git a/Types/AdjustedBranch.hs b/Types/AdjustedBranch.hs
new file mode 100644
index 0000000000..bad81c50db
--- /dev/null
+++ b/Types/AdjustedBranch.hs
@@ -0,0 +1,64 @@
+{- adjusted branch types
+ -
+ - Copyright 2016-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.AdjustedBranch where
+
+data Adjustment
+	= LinkAdjustment LinkAdjustment
+	| PresenceAdjustment PresenceAdjustment (Maybe LinkAdjustment)
+	| LinkPresentAdjustment LinkPresentAdjustment
+	deriving (Show, Eq)
+
+data LinkAdjustment
+	= UnlockAdjustment
+	| LockAdjustment
+	| FixAdjustment
+	| UnFixAdjustment
+	deriving (Show, Eq)
+
+data PresenceAdjustment
+	= HideMissingAdjustment
+	| ShowMissingAdjustment
+	deriving (Show, Eq)
+
+data LinkPresentAdjustment
+	= UnlockPresentAdjustment
+	| LockPresentAdjustment
+	deriving (Show, Eq)
+
+-- Adjustments have to be able to be reversed, so that commits made to the
+-- adjusted branch can be reversed to the commit that would have been made
+-- without the adjustment and applied to the original branch.
+class ReversableAdjustment t where
+	reverseAdjustment :: t -> t
+
+instance ReversableAdjustment Adjustment where
+	reverseAdjustment (LinkAdjustment l) = 
+		LinkAdjustment (reverseAdjustment l)
+	reverseAdjustment (PresenceAdjustment p ml) =
+		PresenceAdjustment (reverseAdjustment p) (fmap reverseAdjustment ml)
+	reverseAdjustment (LinkPresentAdjustment l) =
+		LinkPresentAdjustment (reverseAdjustment l)
+
+instance ReversableAdjustment LinkAdjustment where
+	reverseAdjustment UnlockAdjustment = LockAdjustment
+	-- Keep the file locked intentionally when reversing LockAdjustment.
+	reverseAdjustment LockAdjustment = LockAdjustment
+	reverseAdjustment FixAdjustment = UnFixAdjustment
+	reverseAdjustment UnFixAdjustment = FixAdjustment
+
+instance ReversableAdjustment PresenceAdjustment where
+	reverseAdjustment HideMissingAdjustment = ShowMissingAdjustment
+	reverseAdjustment ShowMissingAdjustment = HideMissingAdjustment
+
+instance ReversableAdjustment LinkPresentAdjustment where
+	reverseAdjustment UnlockPresentAdjustment = LockPresentAdjustment
+	reverseAdjustment LockPresentAdjustment = UnlockPresentAdjustment
+
+adjustmentHidesFiles :: Adjustment -> Bool
+adjustmentHidesFiles (PresenceAdjustment HideMissingAdjustment _) = True
+adjustmentHidesFiles _ = False
diff --git a/Types/Availability.hs b/Types/Availability.hs
new file mode 100644
index 0000000000..3d3e6ac416
--- /dev/null
+++ b/Types/Availability.hs
@@ -0,0 +1,11 @@
+{- git-annex remote availability
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Availability where
+
+data Availability = GloballyAvailable | LocallyAvailable | Unavailable
+	deriving (Eq, Show)
diff --git a/Types/Backend.hs b/Types/Backend.hs
new file mode 100644
index 0000000000..e4035916ee
--- /dev/null
+++ b/Types/Backend.hs
@@ -0,0 +1,49 @@
+{- git-annex key backend data type
+ -
+ - Most things should not need this, using Types instead
+ -
+ - Copyright 2010-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Backend where
+
+import Types.Key
+import Types.KeySource
+import Utility.Metered
+import Utility.FileSystemEncoding
+import Utility.Hash (IncrementalVerifier)
+
+data BackendA a = Backend
+	{ backendVariety :: KeyVariety
+	, genKey :: Maybe (KeySource -> MeterUpdate -> a Key)
+	-- Verifies the content of a key, stored in a file, using a hash.
+	-- This does not need to be cryptographically secure.
+	, verifyKeyContent :: Maybe (Key -> RawFilePath -> a Bool)
+	-- Incrementally verifies the content of a key, using the same
+	-- hash as verifyKeyContent, but with the content provided
+	-- incrementally a piece at a time, until finalized.
+	, verifyKeyContentIncrementally :: Maybe (Key -> a IncrementalVerifier)
+	-- Checks if a key can be upgraded to a better form.
+	, canUpgradeKey :: Maybe (Key -> Bool)
+	-- Checks if there is a fast way to migrate a key to a different
+	-- backend (ie, without re-hashing).
+	-- The Bool is true if the content of the key has been verified to
+	-- be inAnnex.
+	, fastMigrate :: Maybe (Key -> BackendA a -> AssociatedFile -> Bool -> a (Maybe Key))
+	-- Checks if a key is known (or assumed) to always refer to the
+	-- same data.
+	, isStableKey :: Key -> Bool
+	-- Are all keys using this backend verified using a cryptographically
+	-- secure hash?
+	, isCryptographicallySecure :: Bool
+	-- Checks if a key is verified using a cryptographically secure hash.
+	, isCryptographicallySecureKey :: Key -> a Bool
+	}
+
+instance Show (BackendA a) where
+	show backend = "Backend { name =\"" ++ decodeBS (formatKeyVariety (backendVariety backend)) ++ "\" }"
+
+instance Eq (BackendA a) where
+	a == b = backendVariety a == backendVariety b
diff --git a/Types/Benchmark.hs b/Types/Benchmark.hs
new file mode 100644
index 0000000000..050b725745
--- /dev/null
+++ b/Types/Benchmark.hs
@@ -0,0 +1,26 @@
+{- git-annex benchmark data types.
+ -
+ - Copyright 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Types.Benchmark where
+
+import Annex
+import Types.Command
+#ifdef WITH_BENCHMARK
+import Criterion.Main.Options (Mode)
+#endif
+
+type BenchmarkGenerator = [String] -> Annex (IO ())
+
+type MkBenchmarkGenerator = [Command] -> BenchmarkGenerator
+
+#ifdef WITH_BENCHMARK
+type CriterionMode = Mode
+#else
+type CriterionMode = ()
+#endif
diff --git a/Types/BranchState.hs b/Types/BranchState.hs
new file mode 100644
index 0000000000..129a17b349
--- /dev/null
+++ b/Types/BranchState.hs
@@ -0,0 +1,42 @@
+{- git-annex BranchState data type
+ -
+ - Copyright 2011-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.BranchState where
+
+import Common
+import qualified Git
+import Types.Transitions
+
+import qualified Data.ByteString.Lazy as L
+
+data BranchState = BranchState
+	{ branchUpdated :: Bool
+	-- ^ has the branch been updated this run? (Or an update tried and
+	-- failed due to permissions.)
+	, indexChecked :: Bool
+	-- ^ has the index file been checked to exist?
+	, journalIgnorable :: Bool
+	-- ^ can reading the journal be skipped, while still getting
+	-- sufficiently up-to-date information from the branch?
+	, unmergedRefs :: [Git.Sha]
+	-- ^ when the branch was not able to be updated due to permissions,
+	-- these other git refs contain unmerged information and need to be
+	-- queried, along with the index and the journal.
+	, unhandledTransitions :: [TransitionCalculator]
+	-- ^ when the branch was not able to be updated due to permissions,
+	-- this is transitions that need to be applied when making queries.
+	, cachedFileContents :: [(RawFilePath, L.ByteString)]
+	-- ^ contents of a few files recently read from the branch
+	, needInteractiveAccess :: Bool
+	-- ^ do new changes written to the journal or branch by another
+	-- process need to be noticed while the current process is running?
+	-- (This makes the journal always be read, and avoids using the
+	-- cache.)
+	}
+
+startBranchState :: BranchState
+startBranchState = BranchState False False False [] [] [] False
diff --git a/Types/CatFileHandles.hs b/Types/CatFileHandles.hs
new file mode 100644
index 0000000000..7c952f4584
--- /dev/null
+++ b/Types/CatFileHandles.hs
@@ -0,0 +1,38 @@
+{- git-cat file handles pools
+ -
+ - Copyright 2020-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.CatFileHandles (
+	CatFileHandles(..),
+	catFileHandlesNonConcurrent,
+	catFileHandlesPool,
+	CatMap(..),
+	emptyCatMap,
+) where
+
+import Control.Concurrent.STM
+import qualified Data.Map as M
+
+import Utility.ResourcePool
+import Git.CatFile (CatFileHandle, CatFileMetaDataHandle)
+
+data CatFileHandles
+	= CatFileHandlesNonConcurrent CatMap
+	| CatFileHandlesPool (TMVar CatMap)
+
+data CatMap = CatMap
+	{ catFileMap :: M.Map FilePath (ResourcePool CatFileHandle)
+	, catFileMetaDataMap :: M.Map FilePath (ResourcePool CatFileMetaDataHandle)
+	}
+
+emptyCatMap :: CatMap
+emptyCatMap = CatMap M.empty M.empty
+
+catFileHandlesNonConcurrent :: CatFileHandles
+catFileHandlesNonConcurrent = CatFileHandlesNonConcurrent emptyCatMap
+
+catFileHandlesPool :: IO CatFileHandles
+catFileHandlesPool = CatFileHandlesPool <$> newTMVarIO emptyCatMap
diff --git a/Types/CleanupActions.hs b/Types/CleanupActions.hs
new file mode 100644
index 0000000000..418472ef3e
--- /dev/null
+++ b/Types/CleanupActions.hs
@@ -0,0 +1,27 @@
+{- Enumeration of cleanup actions
+ -
+ - Copyright 2014-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.CleanupActions where
+
+import Types.UUID
+import Utility.Url
+
+import System.Process (Pid)
+
+data CleanupAction
+	= RemoteCleanup UUID
+	| StopHook UUID
+	| FsckCleanup
+	| SshCachingCleanup
+	| AdjustedBranchUpdate
+	| TorrentCleanup URLString
+	| OtherTmpCleanup
+	deriving (Eq, Ord)
+
+data SignalAction
+	= PropagateSignalProcessGroup Pid
+	deriving (Eq, Ord)
diff --git a/Types/Command.hs b/Types/Command.hs
new file mode 100644
index 0000000000..e58b220a87
--- /dev/null
+++ b/Types/Command.hs
@@ -0,0 +1,145 @@
+{- git-annex command data types
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+
+module Types.Command where
+
+import Data.Ord
+import Options.Applicative.Types (Parser)
+import Options.Applicative.Builder (InfoMod)
+
+import Types
+import Types.DeferredParse
+import Types.ActionItem
+
+{- A command runs in these stages.
+ -
+ - a. The parser stage parses the command line and generates a CommandSeek
+ -    action. -}
+type CommandParser = Parser CommandSeek
+{- b. The check stage runs checks, that error out if
+ -    anything prevents the command from running. -}
+data CommandCheck = CommandCheck { idCheck :: CommandCheckId, runCheck :: Annex () }
+{- c. The seek stage is passed input from the parser, looks through
+ -    the repo to find things to act on (ie, new files to add), and
+ -    runs commandAction to handle all necessary actions. -}
+type CommandSeek = Annex ()
+{- d. The start stage is run before anything is output, is passed some
+ -    value from the seek stage, and can check if anything needs to be
+ -    done, and early abort if not. It should run quickly and should
+ -    not modify Annex state or output anything. -}
+type CommandStart = Annex (Maybe (StartMessage, CommandPerform))
+{- e. The perform stage is run after a message is printed about the command
+ -    being run, and it should be where the bulk of the work happens. -}
+type CommandPerform = Annex (Maybe CommandCleanup)
+{- f. The cleanup stage is run only if the perform stage succeeds, and it
+ -    returns the overall success/fail of the command. -}
+type CommandCleanup = Annex Bool
+
+{- Input that was seeked on to make an ActionItem. Eg, the input filename,
+ - or directory name. -}
+newtype SeekInput = SeekInput { fromSeekInput :: [String] }
+	deriving (Show)
+
+{- Message that is displayed when starting to perform an action on
+ - something. The String is typically the name of the command or action
+ - being performed.
+ -}
+data StartMessage
+	= StartMessage String ActionItem SeekInput
+	| StartUsualMessages String ActionItem SeekInput
+	-- ^ Like StartMessage, but makes sure to enable usual message
+	-- display in case it was disabled by cmdnomessages.
+	| StartNoMessage ActionItem
+	-- ^ Starts, without displaying any message but also without
+	-- disabling display of any of the usual messages.
+	| CustomOutput ActionItem
+	-- ^ Prevents any start, end, or other usual messages from
+	-- being displayed, letting a command output its own custom format.
+	deriving (Show)
+
+instance MkActionItem StartMessage where
+	mkActionItem (StartMessage _ ai _) = ai
+	mkActionItem (StartUsualMessages _ ai _) = ai
+	mkActionItem (StartNoMessage ai) = ai
+	mkActionItem (CustomOutput ai) = ai
+
+{- A command is defined by specifying these things. -}
+data Command = Command
+	{ cmdcheck :: [CommandCheck]
+	-- ^ check stage
+	, cmdnocommit :: Bool
+	-- ^ don't commit journalled state changes
+	, cmdnomessages :: Bool
+	-- ^ don't output normal messages
+	, cmdname :: String
+	, cmdparamdesc :: CmdParamsDesc
+	-- ^ description of params for usage
+	, cmdsection :: CommandSection
+	, cmddesc :: String
+	-- ^ description of command for usage
+	, cmdparser :: CommandParser
+	-- ^ command line parser
+	, cmdinfomod :: forall a. InfoMod a
+	-- ^ command-specific modifier for ParserInfo
+	, cmdannexoptions :: [AnnexOption]
+	-- ^ additional options not parsed by the CommandParser
+	, cmdnorepo :: Maybe (Parser (IO ()))
+	-- ^used when not in a repo
+	}
+
+{- Command-line parameters, after the command is selected and options
+ - are parsed. -}
+type CmdParams = [String]
+
+type CmdParamsDesc = String
+
+{- CommandCheck functions can be compared using their unique id. -}
+instance Eq CommandCheck where
+	a == b = idCheck a == idCheck b
+
+instance Eq Command where
+	a == b = cmdname a == cmdname b
+
+{- Order commands by name. -}
+instance Ord Command where
+	compare = comparing cmdname
+
+{- The same sections are listed in doc/git-annex.mdwn -}
+data CommandSection 
+	= SectionCommon
+	| SectionSetup
+	| SectionMaintenance
+	| SectionQuery
+	| SectionMetaData
+	| SectionUtility
+	| SectionPlumbing
+	| SectionTesting
+	| SectionAddOn
+	deriving (Eq, Ord, Enum, Bounded)
+
+descSection :: CommandSection -> String
+descSection SectionCommon = "Commonly used commands"
+descSection SectionSetup = "Repository setup commands"
+descSection SectionMaintenance = "Repository maintenance commands"
+descSection SectionQuery = "Query commands"
+descSection SectionMetaData = "Metadata commands"
+descSection SectionUtility = "Utility commands"
+descSection SectionPlumbing = "Plumbing commands"
+descSection SectionTesting = "Testing commands"
+descSection SectionAddOn = "Addon commands"
+
+newtype DryRun = DryRun Bool
+	deriving (Show)
+
+data CommandCheckId 
+	= CheckNotBareRepo
+	| RepoExists
+	| NoDaemonRunning
+	| GitAnnexShellOk
+	deriving (Show, Ord, Eq)
diff --git a/Types/Concurrency.hs b/Types/Concurrency.hs
new file mode 100644
index 0000000000..9204f1d0f4
--- /dev/null
+++ b/Types/Concurrency.hs
@@ -0,0 +1,25 @@
+{- Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Concurrency where
+
+import Utility.PartialPrelude
+
+-- Note that Concurrent 1 is not the same as NonConcurrent;
+-- the former specifies 1 job of each particular kind, but there can be
+-- more than one kind of job running concurrently.
+data Concurrency = NonConcurrent | Concurrent Int | ConcurrentPerCpu
+	deriving (Eq)
+
+parseConcurrency :: String -> Maybe Concurrency
+parseConcurrency "cpus" = Just ConcurrentPerCpu
+parseConcurrency "cpu" = Just ConcurrentPerCpu
+parseConcurrency s = Concurrent <$> readish s
+
+-- Concurrency can be configured at the command line or by git config.
+data ConcurrencySetting
+	= ConcurrencyCmdLine Concurrency
+	| ConcurrencyGitConfig Concurrency
+	deriving (Eq)
diff --git a/Types/Creds.hs b/Types/Creds.hs
new file mode 100644
index 0000000000..9042aab453
--- /dev/null
+++ b/Types/Creds.hs
@@ -0,0 +1,14 @@
+{- credentials
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Creds where
+
+type Creds = String -- can be any data that contains credentials
+
+type CredPair = (Login, Password)
+type Login = String
+type Password = String
diff --git a/Types/Crypto.hs b/Types/Crypto.hs
new file mode 100644
index 0000000000..2b3b065d71
--- /dev/null
+++ b/Types/Crypto.hs
@@ -0,0 +1,77 @@
+{- git-annex crypto types
+ -
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Crypto (
+	EncryptionMethod(..),
+	Cipher(..),
+	StorableCipher(..),
+	EncryptedCipherVariant(..),
+	KeyIds(..),
+	cipherKeyIds,
+	Mac(..),
+	readMac,
+	showMac,
+	macMap,
+	defaultMac,
+	calcMac,
+) where
+
+import Utility.Hash
+import Utility.Gpg (KeyIds(..))
+
+import Data.Typeable
+import qualified Data.Map as M
+import Data.ByteString (ByteString)
+
+data EncryptionMethod
+	= NoneEncryption
+	| SharedEncryption
+	| PubKeyEncryption
+	| SharedPubKeyEncryption
+	| HybridEncryption
+	deriving (Typeable, Eq)
+
+-- A base-64 encoded random value used for encryption.
+-- XXX ideally, this would be a locked memory region
+data Cipher = Cipher ByteString | MacOnlyCipher ByteString
+
+data StorableCipher
+	= EncryptedCipher ByteString EncryptedCipherVariant KeyIds
+	| SharedCipher ByteString
+	| SharedPubKeyCipher ByteString KeyIds
+	deriving (Ord, Eq)
+data EncryptedCipherVariant = Hybrid | PubKey
+	deriving (Ord, Eq)
+
+cipherKeyIds :: StorableCipher -> Maybe KeyIds
+cipherKeyIds (EncryptedCipher _ _ ks) = Just ks
+cipherKeyIds (SharedPubKeyCipher _ ks) = Just ks
+cipherKeyIds (SharedCipher _) = Nothing
+
+defaultMac :: Mac
+defaultMac = HmacSha1
+
+-- MAC algorithms are shown as follows in the file names.
+showMac :: Mac -> String
+showMac HmacSha1   = "HMACSHA1"
+showMac HmacSha224 = "HMACSHA224"
+showMac HmacSha256 = "HMACSHA256"
+showMac HmacSha384 = "HMACSHA384"
+showMac HmacSha512 = "HMACSHA512"
+
+-- Read the MAC algorithm from the remote config.
+readMac :: String -> Maybe Mac
+readMac n = M.lookup n macMap
+
+macMap :: M.Map String Mac
+macMap = M.fromList
+	[ ("HMACSHA1", HmacSha1)
+	, ("HMACSHA224", HmacSha224)
+	, ("HMACSHA256", HmacSha256)
+	, ("HMACSHA384", HmacSha384)
+	, ("HMACSHA512", HmacSha512)
+	]
diff --git a/Types/DeferredParse.hs b/Types/DeferredParse.hs
new file mode 100644
index 0000000000..9566caefd5
--- /dev/null
+++ b/Types/DeferredParse.hs
@@ -0,0 +1,57 @@
+{- git-annex deferred parse values
+ -
+ - Copyright 2015-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE FlexibleInstances #-}
+
+module Types.DeferredParse where
+
+import Annex
+
+import Options.Applicative
+import qualified Data.Semigroup as Sem
+import Prelude
+
+-- Some values cannot be fully parsed without performing an action.
+-- The action may be expensive, so it's best to call finishParse on such a
+-- value before using getParsed repeatedly.
+data DeferredParse a = DeferredParse (Annex a) | ReadyParse a
+
+class DeferredParseClass a where
+	finishParse :: a -> Annex a
+
+getParsed :: DeferredParse a -> Annex a
+getParsed (DeferredParse a) = a
+getParsed (ReadyParse a) = pure a
+
+instance DeferredParseClass (DeferredParse a) where
+	finishParse (DeferredParse a) = ReadyParse <$> a
+	finishParse (ReadyParse a) = pure (ReadyParse a)
+
+instance DeferredParseClass (Maybe (DeferredParse a)) where
+	finishParse Nothing = pure Nothing
+	finishParse (Just v) = Just <$> finishParse v
+
+instance DeferredParseClass [DeferredParse a] where
+	finishParse v = mapM finishParse v
+
+type AnnexOption = Parser AnnexSetter
+
+-- Used for options that can modify Annex state by running
+-- an arbitrary action in it, and can also set up AnnexRead.
+data AnnexSetter = AnnexSetter
+	{ annexStateSetter :: Annex ()
+	, annexReadSetter :: AnnexRead -> AnnexRead
+	}
+
+instance Sem.Semigroup AnnexSetter where
+	a <> b = AnnexSetter
+		{ annexStateSetter = annexStateSetter a >> annexStateSetter b
+		, annexReadSetter = annexReadSetter b . annexReadSetter a
+		}
+
+instance Monoid AnnexSetter where
+	mempty = AnnexSetter (return ()) id
diff --git a/Types/DesktopNotify.hs b/Types/DesktopNotify.hs
new file mode 100644
index 0000000000..bf836acdac
--- /dev/null
+++ b/Types/DesktopNotify.hs
@@ -0,0 +1,31 @@
+{- git-annex DesktopNotify type
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.DesktopNotify where
+
+import Data.Monoid
+import qualified Data.Semigroup as Sem
+import Prelude
+
+data DesktopNotify = DesktopNotify
+	{ notifyStart :: Bool
+	, notifyFinish :: Bool
+	}
+	deriving (Show)
+
+instance Sem.Semigroup DesktopNotify where
+	(DesktopNotify s1 f1) <> (DesktopNotify s2 f2) =
+		DesktopNotify (s1 || s2) (f1 || f2)
+
+instance Monoid DesktopNotify where
+	mempty = DesktopNotify False False
+
+mkNotifyStart :: DesktopNotify
+mkNotifyStart = DesktopNotify True False
+
+mkNotifyFinish :: DesktopNotify
+mkNotifyFinish = DesktopNotify False True
diff --git a/Types/Difference.hs b/Types/Difference.hs
new file mode 100644
index 0000000000..0617dc22a1
--- /dev/null
+++ b/Types/Difference.hs
@@ -0,0 +1,136 @@
+{- git-annex repository differences
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Types.Difference (
+	Difference(..),
+	Differences(..),
+	readDifferences,
+	showDifferences,
+	getDifferences,
+	differenceConfigKey,
+	differenceConfigVal,
+	hasDifference,
+	listDifferences,
+) where
+
+import Utility.PartialPrelude
+import qualified Git
+import qualified Git.Config
+import Git.Types
+
+import Data.Maybe
+import Data.Monoid
+import qualified Data.ByteString as B
+import qualified Data.Set as S
+import qualified Data.Semigroup as Sem
+import Prelude
+
+-- Describes differences from the v5 repository format.
+--
+-- The serialization is stored in difference.log, so avoid changes that
+-- would break compatibility.
+--
+-- Not breaking compatibility is why a list of Differences is used, rather
+-- than a record type. With a record type, adding a new field for some future
+-- difference would serialize to a value that an older version could not
+-- parse, even if that new field was not used. With the Differences list,
+-- old versions can still parse it, unless the new Difference constructor 
+-- is used.
+--
+-- The constructors intentionally do not have parameters; this is to
+-- ensure that any Difference that can be expressed is supported.
+-- So, a new repository version would be Version6, rather than Version Int.
+data Difference
+	= ObjectHashLower
+	| OneLevelObjectHash
+	| OneLevelBranchHash
+	deriving (Show, Read, Eq, Ord, Enum, Bounded)
+
+-- This type is used internally for efficient checking for differences,
+-- but converted to S.Set Difference for serialization.
+data Differences
+	= Differences
+		{ objectHashLower :: Bool
+		, oneLevelObjectHash :: Bool
+		, oneLevelBranchHash :: Bool
+		}
+	| UnknownDifferences
+
+-- UnknownDifferences cannot be equal
+instance Eq Differences where
+	UnknownDifferences == _ = False
+	_ == UnknownDifferences = False
+	a == b = all (\f -> f a == f b)
+		[ objectHashLower
+		, oneLevelObjectHash
+		, oneLevelBranchHash
+		]
+
+appendDifferences :: Differences -> Differences -> Differences
+appendDifferences a@(Differences {}) b@(Differences {}) = a
+	{ objectHashLower = objectHashLower a || objectHashLower b
+	, oneLevelObjectHash = oneLevelObjectHash a || oneLevelObjectHash b
+	, oneLevelBranchHash = oneLevelBranchHash a || oneLevelBranchHash b
+	}
+appendDifferences _ _ = UnknownDifferences
+
+instance Sem.Semigroup Differences where
+	(<>) = appendDifferences
+
+instance Monoid Differences where
+	mempty = Differences False False False
+
+readDifferences :: String -> Differences
+readDifferences = maybe UnknownDifferences mkDifferences . readish
+
+showDifferences :: Differences -> String
+showDifferences = show . S.fromList . listDifferences
+
+getDifferences :: Git.Repo -> Differences
+getDifferences r = mkDifferences $ S.fromList $
+	mapMaybe getmaybe [minBound .. maxBound]
+  where
+	getmaybe d = case Git.Config.isTrueFalse' =<< Git.Config.getMaybe (differenceConfigKey d) r of
+		Just True -> Just d
+		_ -> Nothing
+
+differenceConfigKey :: Difference -> ConfigKey
+differenceConfigKey ObjectHashLower = tunable "objecthashlower"
+differenceConfigKey OneLevelObjectHash = tunable "objecthash1"
+differenceConfigKey OneLevelBranchHash = tunable "branchhash1"
+
+differenceConfigVal :: Difference -> String
+differenceConfigVal _ = Git.Config.boolConfig True
+
+tunable :: B.ByteString -> ConfigKey
+tunable k = ConfigKey ("annex.tune." <> k)
+
+hasDifference :: Difference -> Differences -> Bool
+hasDifference _ UnknownDifferences = False
+hasDifference ObjectHashLower ds = objectHashLower ds
+hasDifference OneLevelObjectHash ds = oneLevelObjectHash ds
+hasDifference OneLevelBranchHash ds = oneLevelBranchHash ds
+
+listDifferences :: Differences -> [Difference]
+listDifferences d@(Differences {}) = map snd $
+	filter (\(f, _) -> f d)
+		[ (objectHashLower, ObjectHashLower)
+		, (oneLevelObjectHash, OneLevelObjectHash)
+		, (oneLevelBranchHash, OneLevelBranchHash)
+		]
+listDifferences UnknownDifferences = []
+
+mkDifferences :: S.Set Difference -> Differences
+mkDifferences s = Differences
+	{ objectHashLower = check ObjectHashLower
+	, oneLevelObjectHash = check OneLevelObjectHash
+	, oneLevelBranchHash = check OneLevelBranchHash
+	}
+  where
+	check f = f `S.member` s
diff --git a/Types/Direction.hs b/Types/Direction.hs
new file mode 100644
index 0000000000..a18b83697d
--- /dev/null
+++ b/Types/Direction.hs
@@ -0,0 +1,25 @@
+{- git-annex transfer direction types
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Types.Direction where
+
+import qualified Data.ByteString as B
+
+data Direction = Upload | Download
+	deriving (Eq, Ord, Show, Read)
+
+formatDirection :: Direction -> B.ByteString
+formatDirection Upload = "upload"
+formatDirection Download = "download"
+
+parseDirection :: String -> Maybe Direction
+parseDirection "upload" = Just Upload
+parseDirection "download" = Just Download
+parseDirection _ = Nothing
+
diff --git a/Types/Distribution.hs b/Types/Distribution.hs
new file mode 100644
index 0000000000..3a7aca1f2e
--- /dev/null
+++ b/Types/Distribution.hs
@@ -0,0 +1,80 @@
+{- Data type for a distribution of git-annex
+ -
+ - Copyright 2013, 2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Distribution where
+
+import Utility.PartialPrelude
+import Utility.Split
+import Types.Key
+import Key
+import Data.Time.Clock
+import Git.Config (isTrueFalse, boolConfig)
+
+import Control.Applicative
+import Prelude
+
+type GitAnnexVersion = String
+
+data GitAnnexDistribution = GitAnnexDistribution
+	{ distributionUrl :: String
+	, distributionKey :: KeyData
+	-- ^ This used to be a Key, but now KeyData serializes
+	-- to Key { ... }, so back-compat for Read and Show is preserved.
+	, distributionVersion :: GitAnnexVersion
+	, distributionReleasedate :: UTCTime
+	, distributionUrgentUpgrade :: Maybe GitAnnexVersion
+	}
+	deriving (Read, Show, Eq)
+
+{- The first line of the info file is in the format old versions of
+ - git-annex expect to read a GitAnnexDistribution.
+ - The remainder of the file is in the new format.
+ - This works because old versions of git-annex used readish to parse
+ - the file, and that ignores the second line.
+ -}
+formatInfoFile :: GitAnnexDistribution -> String
+formatInfoFile d = replace "keyVariant = " "keyBackendName = " (show d) ++
+	"\n" ++ formatGitAnnexDistribution d
+
+parseInfoFile :: String -> Maybe GitAnnexDistribution
+parseInfoFile s = case lines s of
+	(_oldformat:rest) -> parseGitAnnexDistribution (unlines rest)
+	_ -> Nothing
+
+formatGitAnnexDistribution :: GitAnnexDistribution -> String
+formatGitAnnexDistribution d = unlines
+	[ distributionUrl d
+	, serializeKey $ mkKey $ const $ distributionKey d
+	, distributionVersion d
+	, show (distributionReleasedate d)
+	, maybe "" show (distributionUrgentUpgrade d)
+	]
+
+parseGitAnnexDistribution :: String -> Maybe GitAnnexDistribution
+parseGitAnnexDistribution s = case lines s of
+	(u:k:v:d:uu:_) -> GitAnnexDistribution
+		<$> pure u
+		<*> fmap (fromKey id) (deserializeKey k)
+		<*> pure v
+		<*> readish d
+		<*> pure (readish uu)
+	_ -> Nothing
+
+data AutoUpgrade = AskUpgrade | AutoUpgrade | NoAutoUpgrade
+	deriving (Eq)
+
+toAutoUpgrade :: Maybe String -> AutoUpgrade
+toAutoUpgrade Nothing = AskUpgrade
+toAutoUpgrade (Just s)
+	| s == "ask" = AskUpgrade
+	| isTrueFalse s == Just True = AutoUpgrade
+	| otherwise = NoAutoUpgrade
+
+fromAutoUpgrade :: AutoUpgrade -> String
+fromAutoUpgrade AskUpgrade = "ask"
+fromAutoUpgrade AutoUpgrade = boolConfig True
+fromAutoUpgrade NoAutoUpgrade = boolConfig False
diff --git a/Types/Export.hs b/Types/Export.hs
new file mode 100644
index 0000000000..2d5419b91c
--- /dev/null
+++ b/Types/Export.hs
@@ -0,0 +1,66 @@
+{- git-annex export types
+ -
+ - Copyright 2017-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE DeriveGeneric #-}
+
+module Types.Export (
+	ExportLocation,
+	mkExportLocation,
+	fromExportLocation,
+	ExportDirectory,
+	mkExportDirectory,
+	fromExportDirectory,
+	exportDirectories,
+) where
+
+import Git.FilePath
+import Utility.Split
+import Utility.FileSystemEncoding
+
+import qualified Data.ByteString.Short as S
+import qualified System.FilePath.Posix as Posix
+import GHC.Generics
+import Control.DeepSeq
+
+-- A location such as a path on a remote, that a key can be exported to.
+-- The path is relative to the top of the remote, and uses unix-style
+-- path separators.
+--
+-- This uses a ShortByteString to avoid problems with ByteString getting
+-- PINNED in memory which caused memory fragmentation and excessive memory
+-- use.
+newtype ExportLocation = ExportLocation S.ShortByteString
+	deriving (Show, Eq, Generic)
+
+instance NFData ExportLocation
+
+mkExportLocation :: RawFilePath -> ExportLocation
+mkExportLocation = ExportLocation . S.toShort . toInternalGitPath
+
+fromExportLocation :: ExportLocation -> RawFilePath
+fromExportLocation (ExportLocation f) = S.fromShort f
+
+newtype ExportDirectory = ExportDirectory RawFilePath
+	deriving (Show, Eq)
+
+mkExportDirectory :: RawFilePath -> ExportDirectory
+mkExportDirectory = ExportDirectory . toInternalGitPath
+
+fromExportDirectory :: ExportDirectory -> RawFilePath
+fromExportDirectory (ExportDirectory f) = f
+
+-- | All subdirectories down to the ExportLocation, with the deepest ones
+-- last. Does not include the top of the export.
+exportDirectories :: ExportLocation -> [ExportDirectory]
+exportDirectories (ExportLocation f) =
+	map (ExportDirectory . encodeBS . Posix.joinPath . reverse) (subs [] dirs)
+  where
+	subs _ [] = []
+	subs ps (d:ds) = (d:ps) : subs (d:ps) ds
+
+	dirs = map Posix.dropTrailingPathSeparator $
+		dropFromEnd 1 $ Posix.splitPath $ decodeBS $ S.fromShort f
diff --git a/Types/FileMatcher.hs b/Types/FileMatcher.hs
new file mode 100644
index 0000000000..e76192488c
--- /dev/null
+++ b/Types/FileMatcher.hs
@@ -0,0 +1,108 @@
+{- git-annex file matcher types
+ -
+ - Copyright 2013-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.FileMatcher where
+
+import Types.UUID (UUID)
+import Types.Key (Key)
+import Types.Link (LinkType)
+import Types.Mime
+import Utility.Matcher (Matcher, Token, MatchDesc)
+import Utility.FileSize
+import Utility.FileSystemEncoding
+
+import Control.Monad.IO.Class
+import qualified Data.Map as M
+import qualified Data.Set as S
+
+-- Information about a file and/or a key that can be matched on.
+data MatchInfo
+	= MatchingFile FileInfo
+	| MatchingInfo ProvidedInfo
+	| MatchingUserInfo UserProvidedInfo
+
+data FileInfo = FileInfo
+	{ contentFile :: RawFilePath
+	-- ^ path to a file containing the content, for operations
+	-- that examine it
+	, matchFile :: RawFilePath
+	-- ^ filepath to match on; may be relative to top of repo or cwd,
+	-- depending on how globs in preferred content expressions
+	-- are intended to be matched
+	, matchKey :: Maybe Key
+	-- ^ provided if a key is already known
+	}
+
+data ProvidedInfo = ProvidedInfo
+	{ providedFilePath :: Maybe RawFilePath
+	-- ^ filepath to match on, should not be accessed from disk.
+	, providedKey :: Maybe Key
+	, providedFileSize :: Maybe FileSize
+	, providedMimeType :: Maybe MimeType
+	, providedMimeEncoding :: Maybe MimeEncoding
+	, providedLinkType :: Maybe LinkType
+	}
+
+keyMatchInfoWithoutContent :: Key -> RawFilePath -> MatchInfo
+keyMatchInfoWithoutContent key file = MatchingInfo $ ProvidedInfo
+	{ providedFilePath = Just file
+	, providedKey = Just key
+	, providedFileSize = Nothing
+	, providedMimeType = Nothing
+	, providedMimeEncoding = Nothing
+	, providedLinkType = Nothing
+	}
+
+-- This is used when testing a matcher, with values to match against
+-- provided by the user.
+data UserProvidedInfo = UserProvidedInfo
+	{ userProvidedFilePath :: UserInfo FilePath
+	, userProvidedKey :: UserInfo Key
+	, userProvidedFileSize :: UserInfo FileSize
+	, userProvidedMimeType :: UserInfo MimeType
+	, userProvidedMimeEncoding :: UserInfo MimeEncoding
+	}
+
+-- This may fail if the user did not provide the information.
+type UserInfo a = Either (IO a) a
+
+-- If the UserInfo is not available, accessing it may result in eg an
+-- exception being thrown.
+getUserInfo :: MonadIO m => UserInfo a -> m a
+getUserInfo (Right i) = return i
+getUserInfo (Left e) = liftIO e
+
+newtype MatcherDesc = MatcherDesc String
+
+type FileMatcherMap a = M.Map UUID (FileMatcher a)
+
+type MkLimit a = String -> Either String (MatchFiles a)
+
+type AssumeNotPresent = S.Set UUID
+
+data MatchFiles a = MatchFiles 
+	{ matchAction :: AssumeNotPresent -> MatchInfo -> a Bool
+	, matchNeedsFileName :: Bool
+	-- ^ does the matchAction need a filename in order to match?
+	, matchNeedsFileContent :: Bool
+	-- ^ does the matchAction need the file content to be present in
+	-- order to succeed?
+	, matchNeedsKey :: Bool
+	-- ^ does the matchAction look at information about the key?
+	, matchNeedsLocationLog :: Bool
+	-- ^ does the matchAction look at the location log?
+	, matchDesc :: Bool -> MatchDesc
+	-- ^ displayed to the user to describe whether it matched or not
+	}
+
+type FileMatcher a = (Matcher (MatchFiles a), MatcherDesc)
+
+-- This is a matcher that can have tokens added to it while it's being
+-- built, and once complete is compiled to an unchangeable matcher.
+data ExpandableMatcher a
+	= BuildingMatcher [Token (MatchFiles a)]
+	| CompleteMatcher (Matcher (MatchFiles a))
diff --git a/Types/GitConfig.hs b/Types/GitConfig.hs
new file mode 100644
index 0000000000..26540b8484
--- /dev/null
+++ b/Types/GitConfig.hs
@@ -0,0 +1,525 @@
+{- git-annex configuration
+ -
+ - Copyright 2012-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeSynonymInstances, FlexibleInstances #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Types.GitConfig ( 
+	GlobalConfigurable(..),
+	ConfigSource(..),
+	GitConfig(..),
+	extractGitConfig,
+	mergeGitConfig,
+	globalConfigs,
+	RemoteGitConfig(..),
+	extractRemoteGitConfig,
+	dummyRemoteGitConfig,
+	annexConfig,
+	RemoteNameable(..),
+	remoteAnnexConfig,
+	remoteConfig,
+) where
+
+import Common
+import qualified Git
+import qualified Git.Config
+import qualified Git.Construct
+import Git.Types
+import Git.ConfigTypes
+import Git.Remote (isRemoteKey, remoteKeyToRemoteName)
+import Git.Branch (CommitMode(..))
+import Git.Quote (QuotePath(..))
+import Utility.DataUnits
+import Config.Cost
+import Types.UUID
+import Types.Distribution
+import Types.Concurrency
+import Types.NumCopies
+import Types.Difference
+import Types.RefSpec
+import Types.RepoVersion
+import Types.StallDetection
+import Types.View
+import Config.DynamicConfig
+import Utility.HumanTime
+import Utility.Gpg (GpgCmd, mkGpgCmd)
+import Utility.StatelessOpenPGP (SOPCmd(..), SOPProfile(..))
+import Utility.ThreadScheduler (Seconds(..))
+import Utility.Url (Scheme, mkScheme)
+import Network.Socket (PortNumber)
+
+import Control.Concurrent.STM
+import qualified Data.Set as S
+import qualified Data.Map as M
+import qualified Data.ByteString as B
+import qualified System.FilePath.ByteString as P
+
+-- | A configurable value, that may not be fully determined yet because
+-- the global git config has not yet been loaded.
+data GlobalConfigurable a
+	= HasGitConfig a
+	-- ^ The git config has a value.
+	| HasGlobalConfig a
+	-- ^ The global config has a value (and the git config does not).
+	| DefaultConfig a
+	-- ^ A default value is known, but not all config sources
+	-- have been read yet.
+	deriving (Show)
+
+data ConfigSource = FromGitConfig | FromGlobalConfig
+
+{- Main git-annex settings. Each setting corresponds to a git-config key
+ - such as annex.foo -}
+data GitConfig = GitConfig
+	{ annexVersion :: Maybe RepoVersion
+	, annexUUID :: UUID
+	, annexNumCopies :: Maybe NumCopies
+	, annexDiskReserve :: Integer
+	, annexDirect :: Bool
+	, annexBackend :: Maybe String
+	, annexQueueSize :: Maybe Int
+	, annexBloomCapacity :: Maybe Int
+	, annexBloomAccuracy :: Maybe Int
+	, annexSshCaching :: Maybe Bool
+	, annexAlwaysCommit :: Bool
+	, annexAlwaysCompact :: Bool
+	, annexCommitMessage :: Maybe String
+	, annexCommitMessageCommand :: Maybe String
+	, annexMergeAnnexBranches :: Bool
+	, annexDelayAdd :: Maybe Int
+	, annexHttpHeaders :: [String]
+	, annexHttpHeadersCommand :: Maybe String
+	, annexAutoCommit :: GlobalConfigurable Bool
+	, annexResolveMerge :: GlobalConfigurable Bool
+	, annexSyncContent :: GlobalConfigurable (Maybe Bool)
+	, annexSyncOnlyAnnex :: GlobalConfigurable Bool
+	, annexSyncMigrations :: Bool
+	, annexDebug :: Bool
+	, annexDebugFilter :: Maybe String
+	, annexWebOptions :: [String]
+	, annexYoutubeDlOptions :: [String]
+	, annexYoutubeDlCommand :: Maybe String
+	, annexAriaTorrentOptions :: [String]
+	, annexCrippledFileSystem :: Bool
+	, annexLargeFiles :: GlobalConfigurable (Maybe String)
+	, annexDotFiles :: GlobalConfigurable Bool
+	, annexGitAddToAnnex :: Bool
+	, annexAddSmallFiles :: Bool
+	, annexFsckNudge :: Bool
+	, annexAutoUpgrade :: AutoUpgrade
+	, annexExpireUnused :: Maybe (Maybe Duration)
+	, annexFreezeContentCommand :: Maybe String
+	, annexThawContentCommand :: Maybe String
+	, annexSecureEraseCommand :: Maybe String
+	, annexGenMetaData :: Bool
+	, annexListen :: Maybe String
+	, annexPort :: Maybe PortNumber
+	, annexStartupScan :: Bool
+	, annexHardLink :: Bool
+	, annexThin :: Bool
+	, annexDifferences :: Differences
+	, annexUsedRefSpec :: Maybe RefSpec
+	, annexVerify :: Bool
+	, annexPidLock :: Bool
+	, annexPidLockTimeout :: Seconds
+	, annexDbDir :: Maybe RawFilePath
+	, annexAddUnlocked :: GlobalConfigurable (Maybe String)
+	, annexSecureHashesOnly :: Bool
+	, annexRetry :: Maybe Integer
+	, annexForwardRetry :: Maybe Integer
+	, annexRetryDelay :: Maybe Seconds
+	, annexAllowedUrlSchemes :: S.Set Scheme
+	, annexAllowedIPAddresses :: String
+	, annexAllowUnverifiedDownloads :: Bool
+	, annexMaxExtensionLength :: Maybe Int
+	, annexMaxExtensions :: Maybe Int
+	, annexJobs :: Concurrency
+	, annexCacheCreds :: Bool
+	, annexAutoUpgradeRepository :: Bool
+	, annexCommitMode :: CommitMode
+	, annexSkipUnknown :: Bool
+	, annexAdjustedBranchRefresh :: Integer
+	, annexSupportUnlocked :: Bool
+	, coreSymlinks :: Bool
+	, coreSharedRepository :: SharedRepository
+	, coreQuotePath :: QuotePath
+	, receiveDenyCurrentBranch :: DenyCurrentBranch
+	, gcryptId :: Maybe String
+	, gpgCmd :: GpgCmd
+	, mergeDirectoryRenames :: Maybe String
+	, annexPrivateRepos :: S.Set UUID
+	, annexAdviceNoSshCaching :: Bool
+	, annexViewUnsetDirectory :: ViewUnset
+	}
+
+extractGitConfig :: ConfigSource -> Git.Repo -> GitConfig
+extractGitConfig configsource r = GitConfig
+	{ annexVersion = RepoVersion <$> getmayberead (annexConfig "version")
+	, annexUUID = hereuuid
+	, annexNumCopies = configuredNumCopies
+		<$> getmayberead (annexConfig "numcopies")
+	, annexDiskReserve = fromMaybe (onemegabyte * 100) $
+		readSize dataUnits =<< getmaybe (annexConfig "diskreserve")
+	, annexDirect = getbool (annexConfig "direct") False
+	, annexBackend = maybe
+		-- annex.backends is the old name of the option, still used
+		-- when annex.backend is not set.
+		(headMaybe $ getwords (annexConfig "backends"))
+		Just
+		(getmaybe (annexConfig "backend"))
+	, annexQueueSize = getmayberead (annexConfig "queuesize")
+	, annexBloomCapacity = getmayberead (annexConfig "bloomcapacity")
+	, annexBloomAccuracy = getmayberead (annexConfig "bloomaccuracy")
+	, annexSshCaching = getmaybebool (annexConfig "sshcaching")
+	, annexAlwaysCommit = getbool (annexConfig "alwayscommit") True
+	, annexAlwaysCompact = getbool (annexConfig "alwayscompact") True
+	, annexCommitMessage = getmaybe (annexConfig "commitmessage")
+	, annexCommitMessageCommand = getmaybe (annexConfig "commitmessage-command")
+	, annexMergeAnnexBranches = getbool (annexConfig "merge-annex-branches") True
+	, annexDelayAdd = getmayberead (annexConfig "delayadd")
+	, annexHttpHeaders = getlist (annexConfig "http-headers")
+	, annexHttpHeadersCommand = getmaybe (annexConfig "http-headers-command")
+	, annexAutoCommit = configurable True $ 
+		getmaybebool (annexConfig "autocommit")
+	, annexResolveMerge = configurable True $ 
+		getmaybebool (annexConfig "resolvemerge")
+	, annexSyncContent = configurablemaybe $ 
+		getmaybebool (annexConfig "synccontent")
+	, annexSyncOnlyAnnex = configurable False $ 
+		getmaybebool (annexConfig "synconlyannex")
+	, annexSyncMigrations = getbool (annexConfig "syncmigrations") True
+	, annexDebug = getbool (annexConfig "debug") False
+	, annexDebugFilter = getmaybe (annexConfig "debugfilter")
+	, annexWebOptions = getwords (annexConfig "web-options")
+	, annexYoutubeDlOptions = getwords (annexConfig "youtube-dl-options")
+	, annexYoutubeDlCommand = getmaybe (annexConfig "youtube-dl-command")
+	, annexAriaTorrentOptions = getwords (annexConfig "aria-torrent-options")
+	, annexCrippledFileSystem = getbool (annexConfig "crippledfilesystem") False
+	, annexLargeFiles = configurable Nothing $
+		fmap Just $ getmaybe (annexConfig "largefiles")
+	, annexDotFiles = configurable False $
+		getmaybebool (annexConfig "dotfiles")
+	, annexGitAddToAnnex = getbool (annexConfig "gitaddtoannex") True
+	, annexAddSmallFiles = getbool (annexConfig "addsmallfiles") True
+	, annexFsckNudge = getbool (annexConfig "fscknudge") True
+	, annexAutoUpgrade = toAutoUpgrade $
+		getmaybe (annexConfig "autoupgrade")
+	, annexExpireUnused = either (const Nothing) Just . parseDuration
+		<$> getmaybe (annexConfig "expireunused")
+	, annexFreezeContentCommand = getmaybe (annexConfig "freezecontent-command")
+	, annexThawContentCommand = getmaybe (annexConfig "thawcontent-command")
+	, annexSecureEraseCommand = getmaybe (annexConfig "secure-erase-command")
+	, annexGenMetaData = getbool (annexConfig "genmetadata") False
+	, annexListen = getmaybe (annexConfig "listen")
+	, annexPort = getmayberead (annexConfig "port")
+	, annexStartupScan = getbool (annexConfig "startupscan") True
+	, annexHardLink = getbool (annexConfig "hardlink") False
+	, annexThin = getbool (annexConfig "thin") False
+	, annexDifferences = getDifferences r
+	, annexUsedRefSpec = either (const Nothing) Just . parseRefSpec 
+		=<< getmaybe (annexConfig "used-refspec")
+	, annexVerify = getbool (annexConfig "verify") True
+	, annexPidLock = getbool (annexConfig "pidlock") False
+	, annexPidLockTimeout = Seconds $ fromMaybe 300 $
+		getmayberead (annexConfig "pidlocktimeout")
+	, annexDbDir = (\d -> toRawFilePath d P.</> fromUUID hereuuid)
+		<$> getmaybe (annexConfig "dbdir")
+	, annexAddUnlocked = configurable Nothing $
+		fmap Just $ getmaybe (annexConfig "addunlocked")
+	, annexSecureHashesOnly = getbool (annexConfig "securehashesonly") False
+	, annexRetry = getmayberead (annexConfig "retry")
+	, annexForwardRetry = getmayberead (annexConfig "forward-retry")
+	, annexRetryDelay = Seconds
+		<$> getmayberead (annexConfig "retrydelay")
+	, annexAllowedUrlSchemes = S.fromList $ map mkScheme $
+		maybe ["http", "https", "ftp"] words $
+			getmaybe (annexConfig "security.allowed-url-schemes")
+	, annexAllowedIPAddresses = fromMaybe "" $
+		getmaybe (annexConfig "security.allowed-ip-addresses")
+			<|>
+		getmaybe (annexConfig "security.allowed-http-addresses") -- old name
+	, annexAllowUnverifiedDownloads = (== Just "ACKTHPPT") $
+		getmaybe (annexConfig "security.allow-unverified-downloads")
+	, annexMaxExtensionLength = getmayberead (annexConfig "maxextensionlength")
+	, annexMaxExtensions = getmayberead (annexConfig "maxextensions")
+	, annexJobs = fromMaybe NonConcurrent $ 
+		parseConcurrency =<< getmaybe (annexConfig "jobs")
+	, annexCacheCreds = getbool (annexConfig "cachecreds") True
+	, annexAutoUpgradeRepository = getbool (annexConfig "autoupgraderepository") True
+	, annexCommitMode = if getbool (annexConfig "allowsign") False
+		then ManualCommit
+		else AutomaticCommit
+	, annexSkipUnknown = getbool (annexConfig "skipunknown") False
+	, annexAdjustedBranchRefresh = fromMaybe
+		-- parse as bool if it's not a number
+		(if getbool "adjustedbranchrefresh" False then 1 else 0)
+		(getmayberead (annexConfig "adjustedbranchrefresh"))
+	, annexSupportUnlocked = getbool (annexConfig "supportunlocked") True
+	, coreSymlinks = getbool "core.symlinks" True
+	, coreSharedRepository = getSharedRepository r
+	, coreQuotePath = QuotePath (getbool "core.quotepath" True)
+	, receiveDenyCurrentBranch = getDenyCurrentBranch r
+	, gcryptId = getmaybe "core.gcrypt-id"
+	, gpgCmd = mkGpgCmd (getmaybe "gpg.program")
+	, mergeDirectoryRenames = getmaybe "directoryrenames"
+	, annexPrivateRepos = S.fromList $ concat
+		[ if getbool (annexConfig "private") False
+			then [hereuuid]
+			else []
+		, let get (k, v)
+			| Git.Config.isTrueFalse' v /= Just True = Nothing
+			| isRemoteKey (remoteAnnexConfigEnd "private") k = do
+				remotename <- remoteKeyToRemoteName k
+				toUUID <$> Git.Config.getMaybe
+					(remoteAnnexConfig remotename "uuid") r
+			| otherwise = Nothing
+		  in mapMaybe get (M.toList (Git.config r))
+		]
+	, annexAdviceNoSshCaching = getbool (annexConfig "advicenosshcaching") True
+	, annexViewUnsetDirectory = ViewUnset $ fromMaybe "_" $
+		getmaybe (annexConfig "viewunsetdirectory")
+	}
+  where
+	getbool k d = fromMaybe d $ getmaybebool k
+	getmaybebool k = Git.Config.isTrueFalse' =<< getmaybe' k
+	getmayberead k = readish =<< getmaybe k
+	getmaybe = fmap fromConfigValue . getmaybe'
+	getmaybe' k = Git.Config.getMaybe k r
+	getlist k = map fromConfigValue $ Git.Config.getList k r
+	getwords k = fromMaybe [] $ words <$> getmaybe k
+
+	configurable d Nothing = DefaultConfig d
+	configurable _ (Just v) = case configsource of
+		FromGitConfig -> HasGitConfig v
+		FromGlobalConfig -> HasGlobalConfig v
+	
+	configurablemaybe Nothing = DefaultConfig Nothing
+	configurablemaybe (Just v) = case configsource of
+		FromGitConfig -> HasGitConfig (Just v)
+		FromGlobalConfig -> HasGlobalConfig (Just v)
+
+	onemegabyte = 1000000
+	
+	hereuuid = maybe NoUUID toUUID $ getmaybe (annexConfig "uuid")
+
+{- Merge a GitConfig that comes from git-config with one containing
+ - repository-global defaults. -}
+mergeGitConfig :: GitConfig -> GitConfig -> GitConfig
+mergeGitConfig gitconfig repoglobals = gitconfig
+	{ annexAutoCommit = merge annexAutoCommit
+	, annexSyncContent = merge annexSyncContent
+	, annexSyncOnlyAnnex = merge annexSyncOnlyAnnex
+	, annexResolveMerge = merge annexResolveMerge
+	, annexLargeFiles = merge annexLargeFiles
+	, annexDotFiles = merge annexDotFiles
+	, annexAddUnlocked = merge annexAddUnlocked
+	}
+  where
+	merge f = case f gitconfig of
+		HasGitConfig v -> HasGitConfig v
+		DefaultConfig d -> case f repoglobals of
+			HasGlobalConfig v -> HasGlobalConfig v
+			_ -> HasGitConfig d
+		HasGlobalConfig v -> HasGlobalConfig v
+
+{- Configs that can be set repository-global. -}
+globalConfigs :: [ConfigKey]
+globalConfigs =
+	[ annexConfig "largefiles"
+	, annexConfig "dotfiles"
+	, annexConfig "addunlocked"
+	, annexConfig "autocommit"
+	, annexConfig "resolvemerge"
+	, annexConfig "synccontent"
+	, annexConfig "synconlyannex"
+	, annexConfig "securehashesonly"
+	]
+
+{- Per-remote git-annex settings. Each setting corresponds to a git-config
+ - key such as <remote>.annex-foo, or if that is not set, a default from
+ - annex.foo.
+ -
+ - Note that this is from the perspective of the local repository,
+ - it is not influenced in any way by the contents of the remote
+ - repository's git config.
+ -}
+data RemoteGitConfig = RemoteGitConfig
+	{ remoteAnnexCost :: DynamicConfig (Maybe Cost)
+	, remoteAnnexIgnore :: DynamicConfig Bool
+	, remoteAnnexSync :: DynamicConfig Bool
+	, remoteAnnexPull :: Bool
+	, remoteAnnexPush :: Bool
+	, remoteAnnexReadOnly :: Bool
+	, remoteAnnexVerify :: Bool
+	, remoteAnnexCheckUUID :: Bool
+	, remoteAnnexTrackingBranch :: Maybe Git.Ref
+	, remoteAnnexTrustLevel :: Maybe String
+	, remoteAnnexStartCommand :: Maybe String
+	, remoteAnnexStopCommand :: Maybe String
+	, remoteAnnexSpeculatePresent :: Bool
+	, remoteAnnexBare :: Maybe Bool
+	, remoteAnnexRetry :: Maybe Integer
+	, remoteAnnexForwardRetry :: Maybe Integer
+	, remoteAnnexRetryDelay :: Maybe Seconds
+	, remoteAnnexStallDetection :: Maybe StallDetection
+	, remoteAnnexStallDetectionUpload :: Maybe StallDetection
+	, remoteAnnexStallDetectionDownload :: Maybe StallDetection
+	, remoteAnnexBwLimit :: Maybe BwRate
+	, remoteAnnexBwLimitUpload :: Maybe BwRate
+	, remoteAnnexBwLimitDownload :: Maybe BwRate
+	, remoteAnnexAllowUnverifiedDownloads :: Bool
+	, remoteAnnexConfigUUID :: Maybe UUID
+
+	{- These settings are specific to particular types of remotes
+	 - including special remotes. -}
+	, remoteAnnexShell :: Maybe String
+	, remoteAnnexSshOptions :: [String]
+	, remoteAnnexRsyncOptions :: [String]
+	, remoteAnnexRsyncUploadOptions :: [String]
+	, remoteAnnexRsyncDownloadOptions :: [String]
+	, remoteAnnexRsyncTransport :: [String]
+	, remoteAnnexGnupgOptions :: [String]
+	, remoteAnnexGnupgDecryptOptions :: [String]
+	, remoteAnnexSharedSOPCommand :: Maybe SOPCmd
+	, remoteAnnexSharedSOPProfile :: Maybe SOPProfile
+	, remoteAnnexRsyncUrl :: Maybe String
+	, remoteAnnexBupRepo :: Maybe String
+	, remoteAnnexBorgRepo :: Maybe String
+	, remoteAnnexTahoe :: Maybe FilePath
+	, remoteAnnexBupSplitOptions :: [String]
+	, remoteAnnexDirectory :: Maybe FilePath
+	, remoteAnnexAndroidDirectory :: Maybe FilePath
+	, remoteAnnexAndroidSerial :: Maybe String
+	, remoteAnnexGCrypt :: Maybe String
+	, remoteAnnexGitLFS :: Bool
+	, remoteAnnexDdarRepo :: Maybe String
+	, remoteAnnexHookType :: Maybe String
+	, remoteAnnexExternalType :: Maybe String
+	}
+
+{- The Git.Repo is the local repository, which has the remote with the
+ - given RemoteName. -}
+extractRemoteGitConfig :: Git.Repo -> RemoteName -> STM RemoteGitConfig
+extractRemoteGitConfig r remotename = do
+	annexcost <- mkDynamicConfig readCommandRunner
+		(notempty $ getmaybe "cost-command")
+		(getmayberead "cost")
+	annexignore <- mkDynamicConfig unsuccessfullCommandRunner
+		(notempty $ getmaybe "ignore-command")
+		(getbool "ignore" False)
+	annexsync <- mkDynamicConfig successfullCommandRunner
+		(notempty $ getmaybe "sync-command")
+		(getbool "sync" True)
+	return $ RemoteGitConfig
+		{ remoteAnnexCost = annexcost
+		, remoteAnnexIgnore = annexignore
+		, remoteAnnexSync = annexsync
+		, remoteAnnexPull = getbool "pull" True
+		, remoteAnnexPush = getbool "push" True
+		, remoteAnnexReadOnly = getbool "readonly" False
+		, remoteAnnexCheckUUID = getbool "checkuuid" True
+		, remoteAnnexVerify = getbool "verify" True
+		, remoteAnnexTrackingBranch = Git.Ref . encodeBS <$>
+			( notempty (getmaybe "tracking-branch")
+			<|> notempty (getmaybe "export-tracking") -- old name
+			)
+		, remoteAnnexTrustLevel = notempty $ getmaybe "trustlevel"
+		, remoteAnnexStartCommand = notempty $ getmaybe "start-command"
+		, remoteAnnexStopCommand = notempty $ getmaybe "stop-command"
+		, remoteAnnexSpeculatePresent = getbool "speculate-present" False
+		, remoteAnnexBare = getmaybebool "bare"
+		, remoteAnnexRetry = getmayberead "retry"
+		, remoteAnnexForwardRetry = getmayberead "forward-retry"
+		, remoteAnnexRetryDelay = Seconds
+			<$> getmayberead "retrydelay"
+		, remoteAnnexStallDetection =
+			readStallDetection =<< getmaybe "stalldetection"
+		, remoteAnnexStallDetectionUpload =
+			readStallDetection =<< getmaybe "stalldetection-upload"
+		, remoteAnnexStallDetectionDownload =
+			readStallDetection =<< getmaybe "stalldetection-download"
+		, remoteAnnexBwLimit =
+			readBwRatePerSecond =<< getmaybe "bwlimit"
+		, remoteAnnexBwLimitUpload =
+			readBwRatePerSecond =<< getmaybe "bwlimit-upload"
+		, remoteAnnexBwLimitDownload =
+			readBwRatePerSecond =<< getmaybe "bwlimit-download"
+		, remoteAnnexAllowUnverifiedDownloads = (== Just "ACKTHPPT") $
+			getmaybe ("security-allow-unverified-downloads")
+		, remoteAnnexConfigUUID = toUUID <$> getmaybe "config-uuid"
+		, remoteAnnexShell = getmaybe "shell"
+		, remoteAnnexSshOptions = getoptions "ssh-options"
+		, remoteAnnexRsyncOptions = getoptions "rsync-options"
+		, remoteAnnexRsyncDownloadOptions = getoptions "rsync-download-options"
+		, remoteAnnexRsyncUploadOptions = getoptions "rsync-upload-options"
+		, remoteAnnexRsyncTransport = getoptions "rsync-transport"
+		, remoteAnnexGnupgOptions = getoptions "gnupg-options"
+		, remoteAnnexGnupgDecryptOptions = getoptions "gnupg-decrypt-options"
+		, remoteAnnexSharedSOPCommand = SOPCmd <$>
+			notempty (getmaybe "shared-sop-command")
+		, remoteAnnexSharedSOPProfile = SOPProfile <$>
+			notempty (getmaybe "shared-sop-profile")
+		, remoteAnnexRsyncUrl = notempty $ getmaybe "rsyncurl"
+		, remoteAnnexBupRepo = getmaybe "buprepo"
+		, remoteAnnexBorgRepo = getmaybe "borgrepo"
+		, remoteAnnexTahoe = getmaybe "tahoe"
+		, remoteAnnexBupSplitOptions = getoptions "bup-split-options"
+		, remoteAnnexDirectory = notempty $ getmaybe "directory"
+		, remoteAnnexAndroidDirectory = notempty $ getmaybe "androiddirectory"
+		, remoteAnnexAndroidSerial = notempty $ getmaybe "androidserial"
+		, remoteAnnexGCrypt = notempty $ getmaybe "gcrypt"
+		, remoteAnnexGitLFS = getbool "git-lfs" False
+		, remoteAnnexDdarRepo = getmaybe "ddarrepo"
+		, remoteAnnexHookType = notempty $ getmaybe "hooktype"
+		, remoteAnnexExternalType = notempty $ getmaybe "externaltype"
+		}
+  where
+	getbool k d = fromMaybe d $ getmaybebool k
+	getmaybebool k = Git.Config.isTrueFalse' =<< getmaybe' k
+	getmayberead k = readish =<< getmaybe k
+	getmaybe = fmap fromConfigValue . getmaybe'
+	getmaybe' k = 
+		Git.Config.getMaybe (remoteAnnexConfig remotename k) r
+			<|>
+		Git.Config.getMaybe (annexConfig k) r
+	getoptions k = fromMaybe [] $ words <$> getmaybe k
+
+notempty :: Maybe String -> Maybe String	
+notempty Nothing = Nothing
+notempty (Just "") = Nothing
+notempty (Just s) = Just s
+
+dummyRemoteGitConfig :: IO RemoteGitConfig
+dummyRemoteGitConfig = atomically $ 
+	extractRemoteGitConfig Git.Construct.fromUnknown "dummy"
+
+type UnqualifiedConfigKey = B.ByteString
+
+{- A global annex setting in git config. -}
+annexConfig :: UnqualifiedConfigKey -> ConfigKey
+annexConfig key = ConfigKey ("annex." <> key)
+
+class RemoteNameable r where
+	getRemoteName :: r -> RemoteName
+
+instance RemoteNameable Git.Repo where
+	getRemoteName r = fromMaybe "" (Git.remoteName r)
+
+instance RemoteNameable RemoteName where
+	 getRemoteName = id
+
+{- A per-remote annex setting in git config. -}
+remoteAnnexConfig :: RemoteNameable r => r -> UnqualifiedConfigKey -> ConfigKey
+remoteAnnexConfig r = remoteConfig r . remoteAnnexConfigEnd
+
+remoteAnnexConfigEnd :: UnqualifiedConfigKey -> UnqualifiedConfigKey
+remoteAnnexConfigEnd key = "annex-" <> key
+
+{- A per-remote setting in git config. -}
+remoteConfig :: RemoteNameable r => r -> UnqualifiedConfigKey -> ConfigKey
+remoteConfig r key = ConfigKey $
+	"remote." <> encodeBS (getRemoteName r) <> "." <> key
diff --git a/Types/Group.hs b/Types/Group.hs
new file mode 100644
index 0000000000..cd9975a967
--- /dev/null
+++ b/Types/Group.hs
@@ -0,0 +1,38 @@
+{- git-annex repo groups
+ -
+ - Copyright 2012, 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Group (
+	Group(..),
+	fromGroup,
+	toGroup,
+	GroupMap(..),
+	emptyGroupMap
+) where
+
+import Types.UUID
+import Utility.FileSystemEncoding
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import qualified Data.ByteString as S
+
+newtype Group = Group S.ByteString
+	deriving (Eq, Ord, Show)
+
+fromGroup :: Group -> String
+fromGroup (Group g) = decodeBS g
+
+toGroup :: String -> Group
+toGroup = Group . encodeBS
+
+data GroupMap = GroupMap
+	{ groupsByUUID :: M.Map UUID (S.Set Group)
+	, uuidsByGroup :: M.Map Group (S.Set UUID)
+	}
+
+emptyGroupMap :: GroupMap
+emptyGroupMap = GroupMap M.empty M.empty
diff --git a/Types/Import.hs b/Types/Import.hs
new file mode 100644
index 0000000000..9b0fa226d6
--- /dev/null
+++ b/Types/Import.hs
@@ -0,0 +1,105 @@
+{- git-annex import types
+ -
+ - Copyright 2019-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE DeriveGeneric, DeriveFunctor #-}
+
+module Types.Import where
+
+import qualified Data.ByteString as S
+import Data.Char
+import Control.DeepSeq
+import GHC.Generics
+import qualified System.FilePath.Posix.ByteString as Posix
+
+import Types.Export
+import Utility.QuickCheck
+import Utility.FileSystemEncoding
+
+{- Location of content on a remote that can be imported. 
+ - This is just an alias to ExportLocation, because both are referring to a
+ - location on the remote. -}
+type ImportLocation = ExportLocation
+
+mkImportLocation :: RawFilePath -> ImportLocation
+mkImportLocation = mkExportLocation
+
+fromImportLocation :: ImportLocation -> RawFilePath
+fromImportLocation = fromExportLocation
+
+{- An identifier for content stored on a remote that has been imported into
+ - the repository. It should be reasonably short since it is stored in the
+ - git-annex branch.
+ -
+ - Since other things than git-annex can modify files on import remotes,
+ - and git-annex then be used to import those modifications, the
+ - ContentIdentifier needs to change when a file gets changed in such a
+ - way. Device, inode, and size is one example of a good content
+ - identifier. Or a hash if the remote's interface exposes hashes.
+ -}
+newtype ContentIdentifier = ContentIdentifier S.ByteString
+	deriving (Eq, Ord, Show, Generic)
+
+instance NFData ContentIdentifier
+
+instance Arbitrary ContentIdentifier where
+	-- Avoid non-ascii ContentIdentifiers because fully arbitrary
+	-- strings may not be encoded using the filesystem
+	-- encoding, which is normally applied to all input.
+	arbitrary = ContentIdentifier . encodeBS
+		<$> arbitrary `suchThat` all isAscii
+
+{- List of files that can be imported from a remote, each with some added
+ - information. -}
+data ImportableContents info = ImportableContents
+	{ importableContents :: [(ImportLocation, info)]
+	, importableHistory :: [ImportableContents info]
+	-- ^ Used by remotes that support importing historical versions of
+	-- files that are stored in them. This is equivalent to a git
+	-- commit history.
+	--
+	-- When retrieving a historical version of a file,
+	-- old ImportLocations from importableHistory are not used;
+	-- the content is no longer expected to be present at those
+	-- locations. So, if a remote does not support Key/Value access,
+	-- it should not populate the importableHistory.
+	}
+	deriving (Show, Generic, Functor)
+
+instance NFData info => NFData (ImportableContents info)
+
+{- ImportableContents, but it can be chunked into subtrees to avoid
+ - all needing to fit in memory at the same time. -}
+data ImportableContentsChunkable m info
+	= ImportableContentsComplete (ImportableContents info)
+	-- ^ Used when not chunking
+	| ImportableContentsChunked
+		{ importableContentsChunk :: ImportableContentsChunk m info
+		, importableHistoryComplete :: [ImportableContents info]
+		-- ^ Chunking the history is not supported
+		}
+	deriving (Functor)
+
+{- A chunk of ImportableContents, which is the entire content of a subtree
+ - of the main tree. Nested subtrees are not allowed. -}
+data ImportableContentsChunk m info = ImportableContentsChunk
+	{ importableContentsSubDir :: ImportChunkSubDir
+	, importableContentsSubTree :: [(RawFilePath, info)]
+	-- ^ locations are relative to importableContentsSubDir
+	, importableContentsNextChunk :: m (Maybe (ImportableContentsChunk m info))
+	-- ^ Continuation to get the next chunk.
+	-- Returns Nothing when there are no more chunks.
+	}
+	deriving (Functor)
+
+newtype ImportChunkSubDir = ImportChunkSubDir { importChunkSubDir :: RawFilePath }
+
+importableContentsChunkFullLocation
+	:: ImportChunkSubDir
+	-> RawFilePath
+	-> ImportLocation
+importableContentsChunkFullLocation (ImportChunkSubDir root) loc =
+	mkImportLocation $ Posix.combine root loc
diff --git a/Types/IndexFiles.hs b/Types/IndexFiles.hs
new file mode 100644
index 0000000000..c9f6f9c462
--- /dev/null
+++ b/Types/IndexFiles.hs
@@ -0,0 +1,11 @@
+{- Alternative git index files
+ - 
+ - Copyright 2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.IndexFiles where
+
+data AltIndexFile = AnnexIndexFile | ViewIndexFile
+	deriving (Eq, Show)
diff --git a/Types/Key.hs b/Types/Key.hs
new file mode 100644
index 0000000000..f942b4e55c
--- /dev/null
+++ b/Types/Key.hs
@@ -0,0 +1,356 @@
+{- git-annex Key data type
+ -
+ - Copyright 2011-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings, DeriveGeneric #-}
+
+module Types.Key (
+	KeyData(..),
+	Key,
+	fromKey,
+	keyData,
+	mkKey,
+	alterKey,
+	isKeyPrefix,
+	splitKeyNameExtension,
+	keyParser,
+	keySerialization,
+	AssociatedFile(..),
+	KeyVariety(..),
+	HasExt(..),
+	HashSize(..),
+	hasExt,
+	sameExceptExt,
+	formatKeyVariety,
+	parseKeyVariety,
+) where
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Short as S (ShortByteString, toShort, fromShort)
+import qualified Data.ByteString.Char8 as S8
+import qualified Data.ByteString.Lazy as L
+import Data.ByteString.Builder
+import Data.ByteString.Builder.Extra
+import qualified Data.Attoparsec.ByteString as A
+import qualified Data.Attoparsec.ByteString.Char8 as A8
+import Utility.FileSystemEncoding
+import Data.List
+import Data.Char
+import System.Posix.Types
+import Foreign.C.Types
+import Data.Monoid
+import Control.Applicative
+import GHC.Generics
+import Control.DeepSeq
+import Prelude
+
+{- A Key has a unique name, which is derived from a particular backend,
+ - and may contain other optional metadata. -}
+data KeyData = Key
+	{ keyName :: S.ShortByteString
+	, keyVariety :: KeyVariety
+	, keySize :: Maybe Integer
+	, keyMtime :: Maybe EpochTime
+	, keyChunkSize :: Maybe Integer
+	, keyChunkNum :: Maybe Integer
+	} deriving (Eq, Ord, Read, Show, Generic)
+
+instance NFData KeyData
+
+{- Caching the seralization of a key is an optimization.
+ -
+ - This constructor is not exported, and all smart constructors maintain
+ - the serialization.
+ -}
+data Key = MkKey
+	{ keyData :: KeyData
+	, keySerialization :: S.ShortByteString
+	} deriving (Show, Generic)
+
+instance Eq Key where
+	-- comparing the serialization would be unnecessary work
+	a == b = keyData a == keyData b
+
+instance Ord Key where
+	compare a b = compare (keyData a) (keyData b)
+
+instance NFData Key
+
+{- Access a field of data from the KeyData. -}
+{-# INLINE fromKey #-}
+fromKey :: (KeyData -> a) -> Key -> a
+fromKey f = f . keyData
+
+{- Smart constructor for a Key. The provided KeyData has all values empty. -}
+mkKey :: (KeyData -> KeyData) -> Key
+mkKey f =
+	let d = f stub
+	in MkKey d (mkKeySerialization d)
+  where
+	stub = Key
+		{ keyName = mempty
+		, keyVariety = OtherKey mempty
+		, keySize = Nothing
+		, keyMtime = Nothing
+		, keyChunkSize = Nothing
+		, keyChunkNum = Nothing
+		}
+
+{- Alter a Key's data. -}
+alterKey :: Key -> (KeyData -> KeyData) -> Key
+alterKey k f = 
+	let d = f (keyData k)
+	in MkKey d (mkKeySerialization d)
+
+-- Checks if a string looks like at least the start of a key.
+isKeyPrefix :: String -> Bool
+isKeyPrefix s = [fieldSep, fieldSep] `isInfixOf` s
+
+fieldSep :: Char
+fieldSep = '-'
+
+mkKeySerialization :: KeyData -> S.ShortByteString
+mkKeySerialization = S.toShort . L.toStrict
+    	. toLazyByteStringWith (safeStrategy 128 smallChunkSize) L.empty
+	. buildKeyData
+
+{- Builds a ByteString from a KeyData.
+ -
+ - The name field is always shown last, separated by doubled fieldSeps,
+ - and is the only field allowed to contain the fieldSep.
+ -}
+buildKeyData :: KeyData -> Builder
+buildKeyData k = byteString (formatKeyVariety (keyVariety k))
+	<> 's' ?: (integerDec <$> keySize k)
+	<> 'm' ?: (integerDec . (\(CTime t) -> fromIntegral t) <$> keyMtime k)
+	<> 'S' ?: (integerDec <$> keyChunkSize k)
+	<> 'C' ?: (integerDec <$> keyChunkNum k)
+	<> sepbefore (sepbefore (shortByteString (keyName k)))
+  where
+	sepbefore s = char7 fieldSep <> s
+	c ?: (Just b) = sepbefore (char7 c <> b)
+	_ ?: Nothing = mempty
+
+{- This is a strict parser for security reasons; in addition to keyName,
+ - a key can contain only 4 fields, which all consist only of numbers.
+ - Any key containing other fields, or non-numeric data will fail
+ - to parse.
+ -
+ - If a key contained other non-numeric fields, they could be used to
+ - embed data used in a SHA1 collision attack, which would be a
+ - problem since the keys are committed to git.
+ -}
+keyParser :: A.Parser Key
+keyParser = do
+	-- key variety cannot be empty
+	v <- (parseKeyVariety <$> A8.takeWhile1 (/= fieldSep))
+	s <- parsesize
+	m <- parsemtime
+	cs <- parsechunksize
+	cn <- parsechunknum
+	_ <- A8.char fieldSep
+	_ <- A8.char fieldSep
+	n <- A.takeByteString
+	if validKeyName v n
+		then 
+			let d = Key
+				{ keyName = S.toShort n
+				, keyVariety = v
+				, keySize = s
+				, keyMtime = m
+				, keyChunkSize = cs
+				, keyChunkNum = cn
+				}
+			in pure $ MkKey d (mkKeySerialization d)
+		else fail "invalid keyName"
+  where
+	parseopt p = (Just <$> (A8.char fieldSep *> p)) <|> pure Nothing
+	parsesize = parseopt $ A8.char 's' *> A8.decimal
+	parsemtime = parseopt $ CTime <$> (A8.char 'm' *> A8.decimal)
+	parsechunksize = parseopt $ A8.char 'S' *> A8.decimal
+	parsechunknum = parseopt $ A8.char 'C' *> A8.decimal
+
+{- Limits the length of the extension in the keyName to mitigate against
+ - SHA1 collision attacks.
+ -
+ - In such an attack, the extension of the key could be made to contain
+ - the collision generation data, with the result that a signed git commit
+ - including such keys would not be secure.
+ -
+ - The maximum extension length ever generated for such a key was 8
+ - characters, but they may be unicode which could use up to 4 bytes each,
+ - so 32 bytes. 64 bytes is used here to give a little future wiggle-room. 
+ - The SHA1 common-prefix attack needs 128 bytes of data.
+ -}
+validKeyName :: KeyVariety -> S.ByteString -> Bool
+validKeyName kv name
+	| hasExt kv = 
+		let ext = snd $ splitKeyNameExtension' name
+		in S.length ext <= 64
+	| otherwise = True
+
+{- This splits any extension out of the keyName, returning the 
+ - keyName minus extension, and the extension (including leading dot).
+ -}
+splitKeyNameExtension :: Key -> (S.ByteString, S.ByteString)
+splitKeyNameExtension = splitKeyNameExtension' . S.fromShort . keyName . keyData
+
+splitKeyNameExtension' :: S.ByteString -> (S.ByteString, S.ByteString)
+splitKeyNameExtension' keyname = S8.span (/= '.') keyname
+
+{- A filename may be associated with a Key. -}
+newtype AssociatedFile = AssociatedFile (Maybe RawFilePath)
+	deriving (Show, Read, Eq, Ord)
+
+{- There are several different varieties of keys. -}
+data KeyVariety
+	= SHA2Key HashSize HasExt
+	| SHA3Key HashSize HasExt
+	| SKEINKey HashSize HasExt
+	| Blake2bKey HashSize HasExt
+	| Blake2bpKey HashSize HasExt
+	| Blake2sKey HashSize HasExt
+	| Blake2spKey HashSize HasExt
+	| SHA1Key HasExt
+	| MD5Key HasExt
+	| WORMKey
+	| URLKey
+	| VURLKey
+	-- A key that is handled by some external backend.
+	| ExternalKey S.ByteString HasExt
+ 	-- Some repositories may contain keys of other varieties,
+	-- which can still be processed to some extent.
+	| OtherKey S.ByteString
+	deriving (Eq, Ord, Read, Show, Generic)
+
+instance NFData KeyVariety
+
+{- Some varieties of keys may contain an extension at the end of the
+ - keyName -}
+newtype HasExt = HasExt Bool
+	deriving (Eq, Ord, Read, Show, Generic)
+
+instance NFData HasExt
+
+newtype HashSize = HashSize Int
+	deriving (Eq, Ord, Read, Show, Generic)
+
+instance NFData HashSize
+
+hasExt :: KeyVariety -> Bool
+hasExt (SHA2Key _ (HasExt b)) = b
+hasExt (SHA3Key _ (HasExt b)) = b
+hasExt (SKEINKey _ (HasExt b)) = b
+hasExt (Blake2bKey _ (HasExt b)) = b
+hasExt (Blake2bpKey _ (HasExt b)) = b
+hasExt (Blake2sKey _ (HasExt b)) = b
+hasExt (Blake2spKey _ (HasExt b)) = b
+hasExt (SHA1Key (HasExt b)) = b
+hasExt (MD5Key (HasExt b)) = b
+hasExt WORMKey = False
+hasExt URLKey = False
+hasExt VURLKey = False
+hasExt (ExternalKey _ (HasExt b)) = b
+hasExt (OtherKey s) = (snd <$> S8.unsnoc s) == Just 'E'
+
+sameExceptExt :: KeyVariety -> KeyVariety -> Bool
+sameExceptExt (SHA2Key sz1 _) (SHA2Key sz2 _) = sz1 == sz2
+sameExceptExt (SHA3Key sz1 _) (SHA3Key sz2 _) = sz1 == sz2
+sameExceptExt (SKEINKey sz1 _) (SKEINKey sz2 _) = sz1 == sz2
+sameExceptExt (Blake2bKey sz1 _) (Blake2bKey sz2 _) = sz1 == sz2
+sameExceptExt (Blake2bpKey sz1 _) (Blake2bpKey sz2 _) = sz1 == sz2
+sameExceptExt (Blake2sKey sz1 _) (Blake2sKey sz2 _) = sz1 == sz2
+sameExceptExt (Blake2spKey sz1 _) (Blake2spKey sz2 _) = sz1 == sz2
+sameExceptExt (SHA1Key _) (SHA1Key _) = True
+sameExceptExt (MD5Key _) (MD5Key _) = True
+sameExceptExt _ _ = False
+
+formatKeyVariety :: KeyVariety -> S.ByteString
+formatKeyVariety v = case v of
+	SHA2Key sz e -> adde e (addsz sz "SHA")
+	SHA3Key sz e -> adde e (addsz sz "SHA3_")
+	SKEINKey sz e -> adde e (addsz sz "SKEIN")
+	Blake2bKey sz e -> adde e (addsz sz "BLAKE2B")
+	Blake2bpKey sz e -> adde e (addsz sz "BLAKE2BP")
+	Blake2sKey sz e -> adde e (addsz sz "BLAKE2S")
+	Blake2spKey sz e -> adde e (addsz sz "BLAKE2SP")
+	SHA1Key e -> adde e "SHA1"
+	MD5Key e -> adde e "MD5"
+	WORMKey -> "WORM"
+	URLKey -> "URL"
+	VURLKey -> "VURL"
+	ExternalKey s e -> adde e ("X" <> s)
+	OtherKey s -> s
+  where
+	adde (HasExt False) s = s
+	adde (HasExt True) s = s <> "E"
+	addsz (HashSize n) s = s <> case n of
+		256 -> "256"
+		512 -> "512"
+		224 -> "224"
+		384 -> "384"
+		160 -> "160"
+		-- This is relatively slow, which is why the common hash
+		-- sizes are hardcoded above.
+		_ -> S8.pack (show n)
+
+parseKeyVariety :: S.ByteString -> KeyVariety
+parseKeyVariety "SHA256"       = SHA2Key (HashSize 256) (HasExt False)
+parseKeyVariety "SHA256E"      = SHA2Key (HashSize 256) (HasExt True)
+parseKeyVariety "SHA512"       = SHA2Key (HashSize 512) (HasExt False)
+parseKeyVariety "SHA512E"      = SHA2Key (HashSize 512) (HasExt True)
+parseKeyVariety "SHA224"       = SHA2Key (HashSize 224) (HasExt False)
+parseKeyVariety "SHA224E"      = SHA2Key (HashSize 224) (HasExt True)
+parseKeyVariety "SHA384"       = SHA2Key (HashSize 384) (HasExt False)
+parseKeyVariety "SHA384E"      = SHA2Key (HashSize 384) (HasExt True)
+parseKeyVariety "SHA3_512"     = SHA3Key (HashSize 512) (HasExt False)
+parseKeyVariety "SHA3_512E"    = SHA3Key (HashSize 512) (HasExt True)
+parseKeyVariety "SHA3_384"     = SHA3Key (HashSize 384) (HasExt False)
+parseKeyVariety "SHA3_384E"    = SHA3Key (HashSize 384) (HasExt True)
+parseKeyVariety "SHA3_256"     = SHA3Key (HashSize 256) (HasExt False)
+parseKeyVariety "SHA3_256E"    = SHA3Key (HashSize 256) (HasExt True)
+parseKeyVariety "SHA3_224"     = SHA3Key (HashSize 224) (HasExt False)
+parseKeyVariety "SHA3_224E"    = SHA3Key (HashSize 224) (HasExt True)
+parseKeyVariety "SKEIN512"     = SKEINKey (HashSize 512) (HasExt False)
+parseKeyVariety "SKEIN512E"    = SKEINKey (HashSize 512) (HasExt True)
+parseKeyVariety "SKEIN256"     = SKEINKey (HashSize 256) (HasExt False)
+parseKeyVariety "SKEIN256E"    = SKEINKey (HashSize 256) (HasExt True)
+parseKeyVariety "BLAKE2B160"   = Blake2bKey (HashSize 160) (HasExt False)
+parseKeyVariety "BLAKE2B160E"  = Blake2bKey (HashSize 160) (HasExt True)
+parseKeyVariety "BLAKE2B224"   = Blake2bKey (HashSize 224) (HasExt False)
+parseKeyVariety "BLAKE2B224E"  = Blake2bKey (HashSize 224) (HasExt True)
+parseKeyVariety "BLAKE2B256"   = Blake2bKey (HashSize 256) (HasExt False)
+parseKeyVariety "BLAKE2B256E"  = Blake2bKey (HashSize 256) (HasExt True)
+parseKeyVariety "BLAKE2B384"   = Blake2bKey (HashSize 384) (HasExt False)
+parseKeyVariety "BLAKE2B384E"  = Blake2bKey (HashSize 384) (HasExt True)
+parseKeyVariety "BLAKE2B512"   = Blake2bKey (HashSize 512) (HasExt False)
+parseKeyVariety "BLAKE2B512E"  = Blake2bKey (HashSize 512) (HasExt True)
+parseKeyVariety "BLAKE2BP512"  = Blake2bpKey (HashSize 512) (HasExt False)
+parseKeyVariety "BLAKE2BP512E" = Blake2bpKey (HashSize 512) (HasExt True)
+parseKeyVariety "BLAKE2S160"   = Blake2sKey (HashSize 160) (HasExt False)
+parseKeyVariety "BLAKE2S160E"  = Blake2sKey (HashSize 160) (HasExt True)
+parseKeyVariety "BLAKE2S224"   = Blake2sKey (HashSize 224) (HasExt False)
+parseKeyVariety "BLAKE2S224E"  = Blake2sKey (HashSize 224) (HasExt True)
+parseKeyVariety "BLAKE2S256"   = Blake2sKey (HashSize 256) (HasExt False)
+parseKeyVariety "BLAKE2S256E"  = Blake2sKey (HashSize 256) (HasExt True)
+parseKeyVariety "BLAKE2SP224"  = Blake2spKey (HashSize 224) (HasExt False)
+parseKeyVariety "BLAKE2SP224E" = Blake2spKey (HashSize 224) (HasExt True)
+parseKeyVariety "BLAKE2SP256"  = Blake2spKey (HashSize 256) (HasExt False)
+parseKeyVariety "BLAKE2SP256E" = Blake2spKey (HashSize 256) (HasExt True)
+parseKeyVariety "SHA1"         = SHA1Key (HasExt False)
+parseKeyVariety "SHA1E"        = SHA1Key (HasExt True)
+parseKeyVariety "MD5"          = MD5Key (HasExt False)
+parseKeyVariety "MD5E"         = MD5Key (HasExt True)
+parseKeyVariety "WORM"         = WORMKey
+parseKeyVariety "URL"          = URLKey
+parseKeyVariety "VURL"         = VURLKey
+parseKeyVariety b
+	| "X" `S.isPrefixOf` b = 
+		let b' = S.tail b
+		in if not (S.null b') && S.last b' == fromIntegral (ord 'E')
+			then ExternalKey (S.init b') (HasExt True)
+			else ExternalKey b' (HasExt False)
+	| otherwise = OtherKey b
diff --git a/Types/KeySource.hs b/Types/KeySource.hs
new file mode 100644
index 0000000000..e139340548
--- /dev/null
+++ b/Types/KeySource.hs
@@ -0,0 +1,30 @@
+{- KeySource data type
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.KeySource where
+
+import Utility.InodeCache
+import System.FilePath.ByteString (RawFilePath)
+
+{- When content is in the process of being ingested into the annex,
+ - and a Key generated from it, this data type is used. 
+ -
+ - The contentLocation may be different from the filename
+ - associated with the key. For example, the add command
+ - may temporarily hard link the content into a lockdown directory
+ - for checking. The migrate command uses the content
+ - of a different Key.
+ -
+ - The inodeCache can be used to detect some types of modifications to
+ - files that may be made while they're in the process of being ingested.
+ -}
+data KeySource = KeySource
+	{ keyFilename :: RawFilePath
+	, contentLocation :: RawFilePath
+	, inodeCache :: Maybe InodeCache
+	}
+	deriving (Show)
diff --git a/Types/Link.hs b/Types/Link.hs
new file mode 100644
index 0000000000..d4624d824b
--- /dev/null
+++ b/Types/Link.hs
@@ -0,0 +1,13 @@
+{- Types for links to content
+ -
+ - Copyright 2013-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Link where
+
+-- A locked link is stored in git as a symlink, while an unlocked link is
+-- stored as a pointer file.
+data LinkType = LockedLink | UnlockedLink
+	deriving (Show, Eq)
diff --git a/Types/LockCache.hs b/Types/LockCache.hs
new file mode 100644
index 0000000000..5b921be17d
--- /dev/null
+++ b/Types/LockCache.hs
@@ -0,0 +1,18 @@
+{- git-annex lock cache data types
+ - 
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.LockCache (
+	LockCache,
+	LockHandle
+) where
+
+import Utility.LockPool (LockHandle)
+
+import qualified Data.Map as M
+import System.FilePath.ByteString (RawFilePath)
+
+type LockCache = M.Map RawFilePath LockHandle
diff --git a/Types/Messages.hs b/Types/Messages.hs
new file mode 100644
index 0000000000..3f830fc839
--- /dev/null
+++ b/Types/Messages.hs
@@ -0,0 +1,92 @@
+{- git-annex Messages data types
+ - 
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Messages where
+
+import qualified Utility.Aeson as Aeson
+import Utility.Metered
+
+import Control.Concurrent
+import System.Console.Regions (ConsoleRegion)
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+
+data OutputType
+	= NormalOutput
+	| QuietOutput
+	| JSONOutput JSONOptions
+	| SerializedOutput
+		(SerializedOutput -> IO ())
+		(IO (Maybe SerializedOutputResponse))
+
+data JSONOptions = JSONOptions
+	{ jsonProgress :: Bool
+	, jsonErrorMessages :: Bool
+	}
+	deriving (Show)
+
+adjustOutputType :: OutputType -> OutputType -> OutputType
+adjustOutputType (JSONOutput old) (JSONOutput new) = JSONOutput $ JSONOptions
+	{ jsonProgress = jsonProgress old || jsonProgress new
+	, jsonErrorMessages = jsonErrorMessages old || jsonErrorMessages new
+	}
+adjustOutputType _old new = new
+
+data SideActionBlock = NoBlock | StartBlock | InBlock
+	deriving (Eq)
+
+data MessageState = MessageState
+	{ outputType :: OutputType
+	, concurrentOutputEnabled :: Bool
+	, sideActionBlock :: SideActionBlock
+	, consoleRegion :: Maybe ConsoleRegion
+	, consoleRegionErrFlag :: Bool
+	, jsonBuffer :: Maybe Aeson.Object
+	, promptLock :: MVar () -- left full when not prompting
+	, clearProgressMeter :: IO ()
+	}
+
+newMessageState :: IO MessageState
+newMessageState = do
+	promptlock <- newMVar ()
+	return $ MessageState
+		{ outputType = NormalOutput
+		, concurrentOutputEnabled = False
+		, sideActionBlock = NoBlock
+		, consoleRegion = Nothing
+		, consoleRegionErrFlag = False
+		, jsonBuffer = Nothing
+		, promptLock = promptlock
+		, clearProgressMeter = return ()
+		}
+
+-- | When communicating with a child process over a pipe while it is
+-- performing some action, this is used to pass back output that the child
+-- would normally display to the console.
+data SerializedOutput
+	= OutputMessage S.ByteString
+	| OutputError String
+	| BeginProgressMeter
+	| UpdateProgressMeterTotalSize TotalSize
+	| UpdateProgressMeter BytesProcessed
+	| EndProgressMeter
+	| BeginPrompt
+	| EndPrompt
+	| JSONObject L.ByteString
+	-- ^ This is always sent, it's up to the consumer to decide if it
+	-- wants to display JSON, or human-readable messages.
+	deriving (Show)
+
+data SerializedOutputResponse
+	= ReadyPrompt
+	deriving (Eq, Show)
+
+-- | Message identifiers. Avoid changing these.
+data MessageId
+	= FileNotFound
+	| FileBeyondSymbolicLink
+	deriving (Show)
diff --git a/Types/MetaData.hs b/Types/MetaData.hs
new file mode 100644
index 0000000000..316c06a2f7
--- /dev/null
+++ b/Types/MetaData.hs
@@ -0,0 +1,375 @@
+{- git-annex general metadata
+ -
+ - Copyright 2014-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE GeneralizedNewtypeDeriving #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module Types.MetaData (
+	MetaData(..),
+	MetaField(..),
+	MetaValue(..),
+	CurrentlySet(..),
+	serialize,
+	deserialize,
+	MetaSerializable,
+	toMetaField,
+	mkMetaField,
+	mkMetaFieldUnchecked,
+	fromMetaField,
+	toMetaValue,
+	mkMetaValue,
+	unsetMetaValue,
+	unsetMetaData,
+	fromMetaValue,
+	fromMetaData,
+	emptyMetaData,
+	updateMetaData,
+	unionMetaData,
+	combineMetaData,
+	differenceMetaData,
+	isSet,
+	currentMetaData,
+	currentMetaDataValues,
+	metaDataValues,
+	ModMeta(..),
+	modMeta,
+	RemoteMetaData(..),
+	extractRemoteMetaData,
+	splitRemoteMetaDataField,
+	fromRemoteMetaData,
+	prop_metadata_sane,
+	prop_metadata_serialize
+) where
+
+import Common
+import Utility.Base64
+import Utility.QuickCheck
+import Utility.Aeson
+import Types.UUID
+
+import qualified Data.Text as T
+import qualified Data.Text.Encoding as E
+import qualified Data.Set as S
+import qualified Data.Map.Strict as M
+import qualified Data.HashMap.Strict as HM
+import Data.Char
+import qualified Data.CaseInsensitive as CI
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Char8 as B8
+
+newtype MetaData = MetaData (M.Map MetaField (S.Set MetaValue))
+	deriving (Show, Eq, Ord)
+
+instance ToJSON' MetaData where
+	toJSON' (MetaData m) = object $ map go (M.toList m)
+	  where
+		go (MetaField f, s) = (textKey (CI.original f), toJSON' s)
+
+instance FromJSON MetaData where
+	parseJSON (Object o) = do
+		l <- HM.toList <$> parseJSON (Object o)
+		MetaData . M.fromList <$> mapM go l
+	  where
+		go (t, l) = case mkMetaField t of
+			Left e -> fail e
+			Right f -> (,) <$> pure f <*> parseJSON l
+	parseJSON _ = fail "expected an object"
+
+{- A metadata value can be currently be set (True), or may have been
+ - set before and we're remembering it no longer is (False). -}
+newtype CurrentlySet = CurrentlySet Bool
+	deriving (Read, Show, Eq, Ord, Arbitrary)
+
+{- Fields are case insensitive. -}
+newtype MetaField = MetaField (CI.CI T.Text)
+	deriving (Read, Show, Eq, Ord)
+
+data MetaValue = MetaValue CurrentlySet B.ByteString
+	deriving (Read, Show)
+
+instance ToJSON' MetaValue where
+	toJSON' (MetaValue _ v) = toJSON' v
+
+instance FromJSON MetaValue where
+	parseJSON (String v) = return $
+		MetaValue (CurrentlySet True) (E.encodeUtf8 v)
+	parseJSON _  = fail "expected a string"
+
+{- Metadata values compare and order the same whether currently set or not. -}
+instance Eq MetaValue where
+	MetaValue _ a == MetaValue _ b = a == b
+instance Ord MetaValue where
+	compare (MetaValue _ x) (MetaValue _ y) = compare x y
+
+{- MetaData is serialized to a format like:
+ -
+ - field1 +val1 +val2 -val3 field2 +val4 +val5
+ -}
+class MetaSerializable v where
+	serialize :: v -> B.ByteString
+	deserialize :: B.ByteString -> Maybe v
+
+instance MetaSerializable MetaData where
+	serialize (MetaData m) = B8.unwords $ concatMap go $ M.toList m
+	  where
+		go (f, vs) = serialize f : map serialize (S.toList vs)
+	-- Note that B8.words cannot be used here, because UTF-8 encoded
+	-- field names may contain bytes such as \160 that are whitespace.
+	deserialize = Just . getfield emptyMetaData . B8.split ' '
+	  where
+		getfield m [] = m
+		getfield m (w:ws) = maybe m (getvalues m ws) (deserialize w)
+		getvalues m [] _ = m
+		getvalues m l@(w:ws) f = case deserialize w of
+			Just v -> getvalues (updateMetaData f v m) ws f
+			Nothing -> getfield m l
+
+instance MetaSerializable MetaField where
+	serialize (MetaField f) = E.encodeUtf8 (CI.original f)
+	deserialize = MetaField . CI.mk <$$> eitherToMaybe . E.decodeUtf8'
+
+{- Base64 problematic values. -}
+instance MetaSerializable MetaValue where
+	serialize (MetaValue isset v) =
+		serialize isset <>
+		if B8.any (`elem` [' ', '\r', '\n']) v || "!" `B8.isPrefixOf` v
+			then "!" <> toB64 v
+			else v
+	deserialize b = do
+		(isset, b') <- B8.uncons b
+		case B8.uncons b' of
+			Just ('!', b'') -> MetaValue
+				<$> deserialize (B8.singleton isset)
+				<*> fromB64Maybe b''
+			_ -> MetaValue
+				<$> deserialize (B8.singleton isset)
+				<*> pure b'
+
+instance MetaSerializable CurrentlySet where
+	serialize (CurrentlySet True) = "+"
+	serialize (CurrentlySet False) = "-"
+	deserialize "+" = Just (CurrentlySet True)
+	deserialize "-" = Just (CurrentlySet False)
+	deserialize _ = Nothing
+
+mkMetaField :: T.Text -> Either String MetaField
+mkMetaField f = maybe (Left $ badField f) Right (toMetaField f)
+
+badField :: T.Text -> String
+badField f = "Illegal metadata field name, \"" ++ T.unpack f ++ "\""
+
+{- Does not check that the field name is valid. Use with caution. -}
+mkMetaFieldUnchecked :: T.Text -> MetaField
+mkMetaFieldUnchecked = MetaField . CI.mk
+
+toMetaField :: T.Text -> Maybe MetaField
+toMetaField f
+	| legalField f = Just $ MetaField $ CI.mk f
+	| otherwise = Nothing
+
+{- Fields cannot be empty, contain whitespace, or start with "+-" as
+ - that would break the serialization.
+ -
+ - Additionally, fields should not contain any form of path separator, as
+ - that would break views.
+ -
+ - And, fields need to be valid JSON keys.
+ -
+ - So, require they have an alphanumeric first letter, with the remainder
+ - being either alphanumeric or a small set of whitelisted common punctuation.
+ -}
+legalField :: T.Text -> Bool
+legalField t = case T.uncons t of
+	Nothing -> False
+	Just (c1, t')
+		| not (isAlphaNum c1) -> False
+		| otherwise -> T.all legalchars t'
+  where
+	legalchars c
+		| isAlphaNum c = True
+		| otherwise = c `elem` legalFieldWhiteList
+
+legalFieldWhiteList :: [Char]
+legalFieldWhiteList = "_-."
+
+toMetaValue :: B.ByteString -> MetaValue
+toMetaValue = MetaValue (CurrentlySet True)
+
+mkMetaValue :: CurrentlySet -> B.ByteString -> MetaValue
+mkMetaValue = MetaValue
+
+unsetMetaValue :: MetaValue -> MetaValue
+unsetMetaValue (MetaValue _ s) = MetaValue (CurrentlySet False) s
+
+{- Marks all MetaValues as no longer currently set. -}
+unsetMetaData :: MetaData -> MetaData
+unsetMetaData (MetaData m) = MetaData $ M.map (S.map unsetMetaValue) m
+
+fromMetaField :: MetaField -> T.Text
+fromMetaField (MetaField f) = CI.original f
+
+fromMetaValue :: MetaValue -> B.ByteString
+fromMetaValue (MetaValue _ f) = f
+
+fromMetaData :: MetaData -> [(MetaField, S.Set MetaValue)]
+fromMetaData (MetaData m) = M.toList m
+
+emptyMetaData :: MetaData
+emptyMetaData = MetaData M.empty
+
+{- Can be used to set a value, or to unset it, depending on whether
+ - the MetaValue has CurrentlySet or not. -}
+updateMetaData :: MetaField -> MetaValue -> MetaData -> MetaData
+updateMetaData f v = updateMetaData' f (S.singleton v)
+
+updateMetaData' :: MetaField -> S.Set MetaValue -> MetaData -> MetaData
+updateMetaData' f s (MetaData m) = MetaData $ M.insertWith S.union f s m
+
+{- New metadata overrides old._-}
+unionMetaData :: MetaData -> MetaData -> MetaData
+unionMetaData (MetaData old) (MetaData new) = MetaData $
+	M.unionWith S.union new old
+
+combineMetaData :: [MetaData] -> MetaData
+combineMetaData = foldl' unionMetaData emptyMetaData
+
+differenceMetaData :: MetaData -> MetaData -> MetaData
+differenceMetaData (MetaData m) (MetaData excludem) = MetaData $
+	M.differenceWith diff m excludem
+  where
+	diff sl sr =
+		let s = S.difference sl sr
+		in if S.null s then Nothing else Just s
+
+isSet :: MetaValue -> Bool
+isSet (MetaValue (CurrentlySet isset) _) = isset
+
+{- Gets only currently set values -}
+currentMetaDataValues :: MetaField -> MetaData -> S.Set MetaValue
+currentMetaDataValues f m = S.filter isSet (metaDataValues f m)
+
+currentMetaData :: MetaData -> MetaData
+currentMetaData (MetaData m) = removeEmptyFields $ MetaData $
+	M.map (S.filter isSet) m
+
+removeEmptyFields :: MetaData -> MetaData
+removeEmptyFields (MetaData m) = MetaData $ M.filter (not . S.null) m
+
+{- Gets currently set values, but also values that have been unset. -}
+metaDataValues :: MetaField -> MetaData -> S.Set MetaValue
+metaDataValues f (MetaData m) = fromMaybe S.empty (M.lookup f m)
+
+mapMetaData :: (S.Set MetaValue -> S.Set MetaValue) -> MetaData -> MetaData
+mapMetaData f (MetaData m) = MetaData (M.map f m)
+
+{- Ways that existing metadata can be modified -}
+data ModMeta
+	= AddMeta MetaField MetaValue
+	| DelMeta MetaField (Maybe MetaValue)
+	-- ^ delete value of a field. With Just, only that specific value
+	-- is deleted; with Nothing, all current values are deleted.
+	| DelAllMeta
+	-- ^ delete all currently set metadata
+	| SetMeta MetaField (S.Set MetaValue)
+	-- ^ removes any existing values
+	| MaybeSetMeta MetaField MetaValue
+	-- ^ set when field has no existing value
+	| ComposeModMeta ModMeta ModMeta
+	-- ^ composing multiple modifications
+	deriving (Show)
+
+{- Applies a ModMeta, generating the new MetaData.
+ - Note that the new MetaData does not include all the 
+ - values set in the input metadata. It only contains changed values. -}
+modMeta :: MetaData -> ModMeta -> MetaData
+modMeta _ (AddMeta f v) = updateMetaData f v emptyMetaData
+modMeta _ (DelMeta f (Just oldv)) =
+	updateMetaData f (unsetMetaValue oldv) emptyMetaData
+modMeta m (DelMeta f Nothing) = MetaData $ M.singleton f $
+	S.fromList $ map unsetMetaValue $ S.toList $ currentMetaDataValues f m
+modMeta m DelAllMeta = mapMetaData
+	(S.fromList . map unsetMetaValue . S.toList)
+	(currentMetaData m)
+modMeta m (SetMeta f s) = updateMetaData' f s $
+	foldr (updateMetaData f) emptyMetaData $
+		map unsetMetaValue $ S.toList $ currentMetaDataValues f m
+modMeta m (MaybeSetMeta f v)
+	| S.null (currentMetaDataValues f m) = updateMetaData f v emptyMetaData
+	| otherwise = emptyMetaData
+modMeta m (ComposeModMeta a b) = unionMetaData (modMeta m a) (modMeta m b)
+
+data RemoteMetaData = RemoteMetaData UUID MetaData
+	deriving (Show, Eq, Ord)
+
+{- Extracts only the fields prefixed with "uuid:", which belong to that
+ - remote. -}
+extractRemoteMetaData :: UUID -> MetaData -> RemoteMetaData
+extractRemoteMetaData u (MetaData m) = RemoteMetaData u $ MetaData $
+	M.mapKeys removeprefix $ M.filterWithKey belongsremote m
+  where
+	belongsremote (MetaField f) _v = prefix `T.isPrefixOf` CI.original f
+	removeprefix (MetaField f) = MetaField $ 
+		CI.mk $ T.drop prefixlen $ CI.original f
+	prefix = remoteMetaDataPrefix u
+	prefixlen = T.length prefix
+
+splitRemoteMetaDataField :: MetaField -> Maybe (UUID, MetaField)
+splitRemoteMetaDataField (MetaField f) = do
+	let (su, sf) = T.break (== ':') (CI.original f)
+	f' <- toMetaField ((T.drop 1 sf))
+	return $ (toUUID (T.unpack su), f')
+
+remoteMetaDataPrefix :: UUID -> T.Text
+remoteMetaDataPrefix u = T.pack (fromUUID u) <> ":"
+
+fromRemoteMetaData :: RemoteMetaData -> MetaData
+fromRemoteMetaData (RemoteMetaData u (MetaData m)) = MetaData $
+	M.mapKeys addprefix m
+  where
+	addprefix (MetaField f) = MetaField $ CI.mk $ prefix <> CI.original f
+	prefix = remoteMetaDataPrefix u
+
+{- Avoid putting too many fields in the map; extremely large maps make
+ - the seriaization test slow due to the sheer amount of data.
+ - It's unlikely that more than 10 fields of metadata will be used. -}
+instance Arbitrary MetaData where
+	arbitrary = MetaData . M.fromList <$> resize 10 (listOf arbitrary)
+	  where
+
+instance Arbitrary MetaValue where
+	arbitrary = MetaValue 
+		<$> arbitrary
+		-- Avoid non-ascii MetaValues because fully arbitrary
+		-- strings may not be encoded using the filesystem
+		-- encoding, which is normally applied to all input.
+		<*> (encodeBS <$> arbitrary `suchThat` all isAscii)
+
+instance Arbitrary MetaField where
+	arbitrary = MetaField . CI.mk
+		-- Avoid non-ascii MetaFields because fully arbitrary
+		-- strings may not be encoded using the filesystem
+		-- encoding, which is normally applied to all input.
+		<$> (T.pack <$> arbitrary `suchThat` all isAscii)
+			`suchThat` legalField
+
+prop_metadata_sane :: MetaData -> MetaField -> MetaValue -> Bool
+prop_metadata_sane m f v = and
+	[ S.member v $ metaDataValues f m'
+	, not (isSet v) || S.member v (currentMetaDataValues f m')
+	, differenceMetaData m' emptyMetaData == m'
+	]
+  where
+	m' = updateMetaData f v m
+
+prop_metadata_serialize :: MetaField -> MetaValue -> MetaData -> Bool
+prop_metadata_serialize f v m = and
+	[ deserialize (serialize f) == Just f
+	, deserialize (serialize v) == Just v
+	, deserialize (serialize m') == Just m'
+	]
+  where
+	m' = removeEmptyFields m
diff --git a/Types/Mime.hs b/Types/Mime.hs
new file mode 100644
index 0000000000..2ff32a31ff
--- /dev/null
+++ b/Types/Mime.hs
@@ -0,0 +1,12 @@
+{- git-annex mime types
+ -
+ - Copyright 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Mime where
+
+type MimeType = String
+
+type MimeEncoding = String
diff --git a/Types/NumCopies.hs b/Types/NumCopies.hs
new file mode 100644
index 0000000000..affb91b2d6
--- /dev/null
+++ b/Types/NumCopies.hs
@@ -0,0 +1,200 @@
+{- git-annex numcopies types
+ -
+ - Copyright 2014-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.NumCopies (
+	NumCopies,
+	configuredNumCopies,
+	fromNumCopies,
+	MinCopies,
+	configuredMinCopies,
+	fromMinCopies,
+	VerifiedCopy(..),
+	checkVerifiedCopy,
+	invalidateVerifiedCopy,
+	strongestVerifiedCopy,
+	deDupVerifiedCopies,
+	mkVerifiedCopy,
+	invalidatableVerifiedCopy,
+	withVerifiedCopy,
+	isSafeDrop,
+	SafeDropProof,
+	mkSafeDropProof,
+	ContentRemovalLock(..),
+) where
+
+import Types.UUID
+import Types.Key
+import Utility.Exception (bracketIO)
+import Utility.Monad
+
+import qualified Data.Map as M
+import Control.Concurrent.MVar
+import Control.Monad.Catch (MonadMask)
+import Control.Monad.IO.Class (MonadIO)
+import Control.Monad
+
+newtype NumCopies = NumCopies Int
+	deriving (Ord, Eq, Show)
+
+-- Smart constructor; prevent configuring numcopies to 0 which would
+-- cause data loss.
+configuredNumCopies :: Int -> NumCopies
+configuredNumCopies n
+	| n > 0 = NumCopies n
+	| otherwise = NumCopies 1
+
+fromNumCopies :: NumCopies -> Int
+fromNumCopies (NumCopies n) = n
+
+newtype MinCopies = MinCopies Int
+	deriving (Ord, Eq, Show)
+
+configuredMinCopies :: Int -> MinCopies
+configuredMinCopies n
+	| n > 0 = MinCopies n
+	| otherwise = MinCopies 1
+
+fromMinCopies :: MinCopies -> Int
+fromMinCopies (MinCopies n) = n
+
+-- Indicates that a key's content is exclusively
+-- locked locally, pending removal.
+newtype ContentRemovalLock = ContentRemovalLock Key
+	deriving (Show)
+
+-- A verification that a copy of a key exists in a repository.
+data VerifiedCopy
+	{- Represents a recent verification that a copy of an
+	 - object exists in a repository with the given UUID. -}
+	= RecentlyVerifiedCopy V
+	{- Use when a repository cannot be accessed, but it's
+	 - a trusted repository, which is on record as containing a key
+	 - and is presumably not going to lose its copy. -}
+	| TrustedCopy V
+ 	{- The strongest proof of the existence of a copy.
+	 - Until its associated action is called to unlock it,
+	 - the copy is locked in the repository and is guaranteed
+	 - not to be removed by any git-annex process. -}
+	| LockedCopy V
+	deriving (Show)
+
+data V = V
+	{ _getUUID :: UUID
+	, _checkVerifiedCopy :: IO Bool
+	, _invalidateVerifiedCopy :: IO ()
+	}
+
+instance Show V where
+	show v = show (_getUUID v)
+
+instance ToUUID VerifiedCopy where
+	toUUID = _getUUID . toV
+	
+toV :: VerifiedCopy -> V
+toV (TrustedCopy v) = v
+toV (RecentlyVerifiedCopy v) = v
+toV (LockedCopy v) = v
+
+-- Checks that it's still valid.
+checkVerifiedCopy :: VerifiedCopy -> IO Bool
+checkVerifiedCopy = _checkVerifiedCopy . toV
+
+invalidateVerifiedCopy :: VerifiedCopy -> IO ()
+invalidateVerifiedCopy = _invalidateVerifiedCopy . toV
+
+strongestVerifiedCopy :: VerifiedCopy -> VerifiedCopy -> VerifiedCopy
+strongestVerifiedCopy a@(LockedCopy _) _ = a
+strongestVerifiedCopy _ b@(LockedCopy _) = b
+strongestVerifiedCopy a@(TrustedCopy _) _ = a
+strongestVerifiedCopy _ b@(TrustedCopy _) = b
+strongestVerifiedCopy a@(RecentlyVerifiedCopy _) _ = a
+
+-- Retains stronger verifications over weaker for the same uuid.
+deDupVerifiedCopies :: [VerifiedCopy] -> [VerifiedCopy]
+deDupVerifiedCopies l = M.elems $
+	M.fromListWith strongestVerifiedCopy (zip (map toUUID l) l)
+
+mkVerifiedCopy :: ToUUID u => (V -> VerifiedCopy) -> u -> VerifiedCopy
+mkVerifiedCopy mk u = mk $ V (toUUID u) (return True) (return ())
+
+invalidatableVerifiedCopy :: ToUUID u => (V -> VerifiedCopy) -> u -> IO Bool -> IO VerifiedCopy
+invalidatableVerifiedCopy mk u check = do
+	v <- newEmptyMVar
+	let invalidate = do
+		_ <- tryPutMVar v ()
+		return ()
+	let check' = isEmptyMVar v <&&> check
+	return $ mk $ V (toUUID u) check' invalidate
+
+-- Constructs a VerifiedCopy, and runs the action, ensuring that the
+-- verified copy is invalidated when the action returns, or on error.
+withVerifiedCopy 
+	:: (MonadMask m, MonadIO m, ToUUID u)
+	=> (V -> VerifiedCopy)
+	-> u
+	-> IO Bool
+	-> (VerifiedCopy -> m a)
+	-> m a
+withVerifiedCopy mk u check = bracketIO setup cleanup
+  where
+	setup = invalidatableVerifiedCopy mk u check
+	cleanup = invalidateVerifiedCopy
+
+{- Check whether enough verification has been done of copies to allow
+ - dropping content safely.
+ -
+ - This is carefully balanced to prevent data loss when there are races
+ - between concurrent drops of the same content in different repos,
+ - without requiring impractical amounts of locking.
+ -
+ - In particular, concurrent drop races may cause the number of copies
+ - to fall below NumCopies, but it will never fall below MinCopies.
+ -}
+isSafeDrop :: NumCopies -> MinCopies -> [VerifiedCopy] -> Maybe ContentRemovalLock -> Bool
+{- When a ContentRemovalLock is provided, the content is being
+ - dropped from the local repo. That lock will prevent other git repos
+ - that are concurrently dropping from using the local copy as a VerifiedCopy.
+ - So, no additional locking is needed; all we need is verifications
+ - of any kind of enough other copies of the content. -}
+isSafeDrop (NumCopies n) (MinCopies m) l (Just (ContentRemovalLock _)) = 
+	length (deDupVerifiedCopies l) >= max n m
+{- Dropping from a remote repo.
+ -
+ - To guarantee MinCopies is never violated, at least that many LockedCopy
+ - or TrustedCopy are required. A LockedCopy prevents races between
+ - concurrent drops from dropping the last copy, no matter what.
+ -
+ - The other copies required by NumCopies can be less strong verifications,
+ - like RecentlyVerifiedCopy. While those are subject to concurrent drop
+ - races, and so could be dropped all at once, causing NumCopies to be
+ - violated, this is the best that can be done without requiring that 
+ - all special remotes support locking.
+ -}
+isSafeDrop (NumCopies n) (MinCopies m) l Nothing
+	| n == 0 && m == 0 = True
+	| otherwise = and
+		[ length (deDupVerifiedCopies l) >= n
+		, length (filter fullVerification l) >= m
+		]
+
+fullVerification :: VerifiedCopy -> Bool
+fullVerification (LockedCopy _) = True
+fullVerification (TrustedCopy _) = True
+fullVerification (RecentlyVerifiedCopy _) = False
+
+-- A proof that it's currently safe to drop an object.
+data SafeDropProof = SafeDropProof NumCopies MinCopies [VerifiedCopy] (Maybe ContentRemovalLock)
+	deriving (Show)
+
+-- Makes sure that none of the VerifiedCopies have become invalidated
+-- before constructing proof.
+mkSafeDropProof :: NumCopies -> MinCopies -> [VerifiedCopy] -> Maybe ContentRemovalLock -> IO (Either [VerifiedCopy] SafeDropProof)
+mkSafeDropProof need mincopies have removallock = do
+	stillhave <- filterM checkVerifiedCopy have
+	return $ if isSafeDrop need mincopies stillhave removallock
+		then Right (SafeDropProof need mincopies stillhave removallock)
+		else Left stillhave
diff --git a/Types/ProposedAccepted.hs b/Types/ProposedAccepted.hs
new file mode 100644
index 0000000000..a48c94546a
--- /dev/null
+++ b/Types/ProposedAccepted.hs
@@ -0,0 +1,38 @@
+{- proposed and accepted values
+ -
+ - Copyright 2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.ProposedAccepted where
+
+import Test.QuickCheck
+
+-- | A value that may be proposed, or accepted.
+--
+-- When parsing/validating the value, may want to error out on invalid
+-- input. But if a previous version of git-annex accepted an invalid value,
+-- it's too late to error out, and instead the bad value may be ignored.
+data ProposedAccepted t = Proposed t | Accepted t
+	deriving (Show)
+
+fromProposedAccepted :: ProposedAccepted t -> t
+fromProposedAccepted (Proposed t) = t
+fromProposedAccepted (Accepted t) = t
+
+-- | Whether a value is proposed or accepted does not matter when checking
+-- equality.
+instance Eq t => Eq (ProposedAccepted t) where
+	a == b = fromProposedAccepted a == fromProposedAccepted b
+
+-- | Order by the contained value, not by whether it's proposed or
+-- accepted.
+instance Ord t => Ord (ProposedAccepted t) where
+	compare a b = compare (fromProposedAccepted a) (fromProposedAccepted b)
+
+instance Arbitrary t => Arbitrary (ProposedAccepted t) where
+	arbitrary = oneof
+		[ Proposed <$> arbitrary
+		, Accepted <$> arbitrary
+		]
diff --git a/Types/RefSpec.hs b/Types/RefSpec.hs
new file mode 100644
index 0000000000..86925634d7
--- /dev/null
+++ b/Types/RefSpec.hs
@@ -0,0 +1,52 @@
+{- This is not the same as git's fetch/push refspecs.
+ - 
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.RefSpec where
+
+import Common
+import Utility.Glob
+import Git.Types
+
+import Data.Either
+
+type RefSpec = [RefSpecPart]
+
+data RefSpecPart
+	= AddRef Ref
+	| AddMatching Glob
+	| AddRefLog
+	| RemoveMatching Glob
+
+allRefSpec :: RefSpec
+allRefSpec = [AddMatching $ compileGlob "*" CaseSensitive (GlobFilePath False)]
+
+parseRefSpec :: String -> Either String RefSpec
+parseRefSpec v = case partitionEithers (map mk $ splitc ':' v) of
+	([],refspec) -> Right refspec
+	(e:_,_) -> Left e
+  where
+	mk ('+':s)
+		| any (`elem` s) "*?" =
+			Right $ AddMatching $ compileGlob s CaseSensitive (GlobFilePath False)
+		| otherwise = Right $ AddRef $ Ref $ encodeBS s
+	mk ('-':s) = Right $ RemoveMatching $ compileGlob s CaseSensitive (GlobFilePath False)
+	mk "reflog" = Right AddRefLog
+	mk s = Left $ "bad refspec item \"" ++ s ++ "\" (expected + or - prefix)"
+
+applyRefSpec :: Monad m => RefSpec -> [Ref] -> m [Sha] -> m [Ref]
+applyRefSpec refspec rs getreflog = go [] refspec
+  where
+	go c [] = return (reverse c)
+	go c (AddRef r : rest) = go (r:c) rest
+	go c (AddMatching g : rest) =
+		let add = filter (matchGlob g . fromRef) rs
+		in go (add ++ c) rest
+	go c (AddRefLog : rest) = do
+		reflog <- getreflog
+		go (reflog ++ c) rest
+	go c (RemoveMatching g : rest) = 
+		go (filter (not . matchGlob g . fromRef) c) rest
diff --git a/Types/Remote.hs b/Types/Remote.hs
new file mode 100644
index 0000000000..e4575eb3cd
--- /dev/null
+++ b/Types/Remote.hs
@@ -0,0 +1,415 @@
+{- git-annex remotes types
+ -
+ - Most things should not need this, using Types instead
+ -
+ - Copyright 2011-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+
+module Types.Remote
+	( module Types.RemoteConfig
+	, RemoteTypeA(..)
+	, RemoteA(..)
+	, RemoteStateHandle
+	, SetupStage(..)
+	, Availability(..)
+	, VerifyConfigA(..)
+	, Verification(..)
+	, unVerified
+	, RetrievalSecurityPolicy(..)
+	, isExportSupported
+	, isImportSupported
+	, ExportActions(..)
+	, ImportActions(..)
+	, ByteSize
+	)
+	where
+
+import Data.Ord
+
+import qualified Git
+import Types.Key
+import Types.UUID
+import Types.GitConfig
+import Types.Availability
+import Types.Creds
+import Types.RemoteState
+import Types.UrlContents
+import Types.NumCopies
+import Types.Export
+import Types.Import
+import Types.RemoteConfig
+import Utility.Hash (IncrementalVerifier)
+import Config.Cost
+import Utility.Metered
+import Git.Types (RemoteName)
+import Utility.SafeCommand
+import Utility.Url
+import Utility.DataUnits
+
+data SetupStage = Init | Enable RemoteConfig | AutoEnable RemoteConfig
+
+{- There are different types of remotes. -}
+data RemoteTypeA a = RemoteType
+	-- human visible type name
+	{ typename :: String
+	-- enumerates remotes of this type
+	-- The Bool is True if automatic initialization of remotes is desired
+	, enumerate :: Bool -> a [Git.Repo]
+	-- generates a remote of this type
+	, generate :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> a (Maybe (RemoteA a))
+	-- parse configs of remotes of this type
+	, configParser :: RemoteConfig -> a RemoteConfigParser
+	-- initializes or enables a remote
+	, setup :: SetupStage -> Maybe UUID -> Maybe CredPair -> RemoteConfig -> RemoteGitConfig -> a (RemoteConfig, UUID)
+	-- check if a remote of this type is able to support export
+	, exportSupported :: ParsedRemoteConfig -> RemoteGitConfig -> a Bool
+	-- check if a remote of this type is able to support import
+	, importSupported :: ParsedRemoteConfig -> RemoteGitConfig -> a Bool
+	-- is a remote of this type not a usual key/value store,
+	-- or export/import of a tree of files, but instead a collection
+	-- of files, populated by something outside git-annex, some of
+	-- which may be annex objects?
+	, thirdPartyPopulated :: Bool
+	}
+
+instance Eq (RemoteTypeA a) where
+	x == y = typename x == typename y
+
+{- An individual remote. -}
+data RemoteA a = Remote
+	-- each Remote has a unique uuid
+	{ uuid :: UUID
+	-- each Remote has a human visible name
+	, name :: RemoteName
+	-- Remotes have a use cost; higher is more expensive
+	, cost :: Cost
+	-- Transfers a key's contents from disk to the remote.
+	-- The key should not appear to be present on the remote until
+	-- all of its contents have been transferred.
+	-- Throws exception on failure.
+	, storeKey :: Key -> AssociatedFile -> MeterUpdate -> a ()
+	-- Retrieves a key's contents to a file.
+	-- (The MeterUpdate does not need to be used if it writes
+	-- sequentially to the file.)
+	-- Throws exception on failure.
+	, retrieveKeyFile :: Key -> AssociatedFile -> FilePath -> MeterUpdate -> VerifyConfigA a -> a Verification
+	-- Retrieves a key's contents to a tmp file, if it can be done cheaply.
+	-- It's ok to create a symlink or hardlink.
+	-- Throws exception on failure.
+	, retrieveKeyFileCheap :: Maybe (Key -> AssociatedFile -> FilePath -> a ())
+	-- Security policy for reteiving keys from this remote.
+	, retrievalSecurityPolicy :: RetrievalSecurityPolicy
+	-- Removes a key's contents (succeeds even the contents are not present)
+	-- Can throw exception if unable to access remote, or if remote
+	-- refuses to remove the content.
+	, removeKey :: Key -> a ()
+	-- Uses locking to prevent removal of a key's contents,
+	-- thus producing a VerifiedCopy, which is passed to the callback.
+	-- If unable to lock, does not run the callback, and throws an
+	-- exception.
+	-- This is optional; remotes do not have to support locking.
+	, lockContent :: forall r. Maybe (Key -> (VerifiedCopy -> a r) -> a r)
+	-- Checks if a key is present in the remote.
+	-- Throws an exception if the remote cannot be accessed.
+	, checkPresent :: Key -> a Bool
+	-- Some remotes can checkPresent without an expensive network
+	-- operation.
+	, checkPresentCheap :: Bool
+	-- Some remotes support export.
+	, exportActions :: ExportActions a
+	-- Some remotes support import.
+	, importActions :: ImportActions a
+	-- Some remotes can provide additional details for whereis.
+	, whereisKey :: Maybe (Key -> a [String])
+	-- Some remotes can run a fsck operation on the remote,
+	-- without transferring all the data to the local repo
+	-- The parameters are passed to the fsck command on the remote.
+	, remoteFsck :: Maybe ([CommandParam] -> a (IO Bool))
+	-- Runs an action to repair the remote's git repository.
+	, repairRepo :: Maybe (a Bool -> a (IO Bool))
+	-- a Remote has a persistent configuration store
+	, config :: ParsedRemoteConfig
+	-- Get the git repo for the Remote.
+	, getRepo :: a Git.Repo
+	-- a Remote's configuration from git
+	, gitconfig :: RemoteGitConfig
+	-- a Remote can be associated with a specific local filesystem path
+	, localpath :: Maybe FilePath
+	-- a Remote can be known to be readonly
+	, readonly :: Bool
+	-- a Remote can allow writes but not have a way to delete content
+	-- from it.
+	, appendonly :: Bool
+	-- Set if a remote cannot be trusted to continue to contain the
+	-- contents of files stored there. Notably, most export/import
+	-- remotes are untrustworthy because they are not key/value stores.
+	-- Since this prevents the user from adjusting a remote's trust
+	-- level, it's often better not not set it and instead let the user
+	-- decide.
+	, untrustworthy :: Bool
+	-- a Remote can be globally available. (Ie, "in the cloud".)
+	-- Some Remotes can mark themselves unavailable.
+	, availability :: a Availability
+	-- the type of the remote
+	, remotetype :: RemoteTypeA a
+	-- For testing, makes a version of this remote that is not
+	-- available for use. All its actions should fail.
+	, mkUnavailable :: a (Maybe (RemoteA a))
+	-- Information about the remote, for git annex info to display.
+	, getInfo :: a [(String, String)]
+	-- Some remotes can download from an url (or uri). This asks the
+	-- remote if it can handle a particular url. The actual download
+	-- will be done using retrieveKeyFile, and the remote can look up
+	-- up the url to download for a key using Logs.Web.getUrls.
+	, claimUrl :: Maybe (URLString -> a Bool)
+	-- Checks that the url is accessible, and gets information about
+	-- its contents, without downloading the full content.
+	-- Throws an exception if the url is inaccessible.
+	, checkUrl :: Maybe (URLString -> a UrlContents)
+	, remoteStateHandle :: RemoteStateHandle
+	}
+
+instance RemoteNameable (RemoteA a) where
+	getRemoteName = name
+
+instance Show (RemoteA a) where
+	show remote = "Remote { name =\"" ++ name remote ++ "\" }"
+
+-- two remotes are the same if they have the same uuid
+instance Eq (RemoteA a) where
+	x == y = uuid x == uuid y
+
+-- Order by cost since that is the important order of remotes
+-- when deciding which to use. But since remotes often have the same cost
+-- and Ord must be total, do a secondary ordering by uuid.
+instance Ord (RemoteA a) where
+	compare a b
+		| cost a == cost b = comparing uuid a b
+		| otherwise = comparing cost a b
+
+instance ToUUID (RemoteA a) where
+	toUUID = uuid
+
+data VerifyConfigA a
+	= AlwaysVerify
+	| NoVerify
+	| RemoteVerify (RemoteA a)
+	| DefaultVerify
+
+data Verification
+	= UnVerified 
+	-- ^ Content was not verified during transfer, but is probably
+	-- ok, so if verification is disabled, don't verify it
+	| Verified
+	-- ^ Content was verified during transfer, so don't verify it
+	-- again. The verification does not need to use a
+	-- cryptographically secure hash, but the hash does need to
+	-- have preimage resistance.
+	| IncompleteVerify IncrementalVerifier
+	-- ^ Content was partially verified during transfer, but
+	-- the verification is not complete.
+	| MustVerify
+	-- ^ Content likely to have been altered during transfer,
+	-- verify even if verification is normally disabled
+	| MustFinishIncompleteVerify IncrementalVerifier
+	-- ^ Content likely to have been altered during transfer,
+	-- finish verification even if verification is normally disabled.
+
+unVerified :: Monad m => m a -> m (a, Verification)
+unVerified a = do
+	ok <- a
+	return (ok, UnVerified)
+
+-- Security policy indicating what keys can be safely retrieved from a
+-- remote.
+data RetrievalSecurityPolicy
+	= RetrievalVerifiableKeysSecure
+	-- ^ Transfer of keys whose content can be verified
+	-- with a hash check is secure; transfer of unverifiable keys is
+	-- not secure and should not be allowed.
+	--
+	-- This is used eg, when HTTP to a remote could be redirected to a
+	-- local private web server or even a file:// url, causing private
+	-- data from it that is not the intended content of a key to make
+	-- its way into the git-annex repository.
+	--
+	-- It's also used when content is stored encrypted on a remote,
+	-- which could replace it with a different encrypted file, and
+	-- trick git-annex into decrypting it and leaking the decryption
+	-- into the git-annex repository.
+	--
+	-- It's not (currently) used when the remote could alter the
+	-- content stored on it, because git-annex does not provide
+	-- strong guarantees about the content of keys that cannot be 
+	-- verified with a hash check.
+	-- (But annex.securehashesonly does provide such guarantees.)
+	| RetrievalAllKeysSecure
+	-- ^ Any key can be securely retrieved.
+
+isExportSupported :: RemoteA a -> a Bool
+isExportSupported r = exportSupported (remotetype r) (config r) (gitconfig r)
+
+isImportSupported :: RemoteA a -> a Bool
+isImportSupported r = importSupported (remotetype r) (config r) (gitconfig r)
+
+data ExportActions a = ExportActions 
+	-- Exports content to an ExportLocation.
+	-- The exported file should not appear to be present on the remote
+	-- until all of its contents have been transferred.
+	-- Throws exception on failure.
+	{ storeExport :: FilePath -> Key -> ExportLocation -> MeterUpdate -> a ()
+	-- Retrieves exported content to a file.
+	-- (The MeterUpdate does not need to be used if it writes
+	-- sequentially to the file.)
+	-- Throws exception on failure.
+	, retrieveExport :: Key -> ExportLocation -> FilePath -> MeterUpdate -> a Verification
+	-- Removes an exported file (succeeds if the contents are not present)
+	-- Can throw exception if unable to access remote, or if remote
+	-- refuses to remove the content.
+	, removeExport :: Key -> ExportLocation -> a ()
+	-- Set when the remote is versioned, so once a Key is stored
+	-- to an ExportLocation, a subsequent deletion of that
+	-- ExportLocation leaves the key still accessible to retrieveKeyFile
+	-- and checkPresent.
+	, versionedExport :: Bool
+	-- Removes an exported directory. Typically the directory will be
+	-- empty, but it could possibly contain files or other directories,
+	-- and it's ok to delete those (but not required to). 
+	-- If the remote does not use directories, or automatically cleans
+	-- up empty directories, this can be Nothing.
+	--
+	-- Should not fail if the directory was already removed.
+	--
+	-- Throws exception if unable to contact the remote, or perhaps if
+	-- the remote refuses to let the directory be removed.
+	, removeExportDirectory :: Maybe (ExportDirectory -> a ())
+	-- Checks if anything is exported to the remote at the specified
+	-- ExportLocation. It may check the size or other characteristics
+	-- of the Key, but does not need to guarantee that the content on
+	-- the remote is the same as the Key's content.
+	-- Throws an exception if the remote cannot be accessed.
+	, checkPresentExport :: Key -> ExportLocation -> a Bool
+	-- Renames an already exported file.
+	--
+	-- If the remote does not support the requested rename,
+	-- it can return Nothing. It's ok if the remove deletes
+	-- the file in such a situation too; it will be re-exported to
+	-- recover.
+	--
+	-- Throws an exception if the remote cannot be accessed, or
+	-- the file doesn't exist or cannot be renamed.
+	, renameExport :: Maybe (Key -> ExportLocation -> ExportLocation -> a (Maybe ()))
+	}
+
+data ImportActions a = ImportActions
+	-- Finds the current set of files that are stored in the remote,
+	-- along with their content identifiers and size.
+	--
+	-- May also find old versions of files that are still stored in the
+	-- remote.
+	--
+	-- Throws exception on failure to access the remote.
+	-- May return Nothing when the remote is unchanged since last time.
+	{ listImportableContents :: a (Maybe (ImportableContentsChunkable a (ContentIdentifier, ByteSize)))
+	-- Generates a Key (of any type) for the file stored on the
+	-- remote at the ImportLocation. Does not download the file
+	-- from the remote.
+	--
+	-- May update the progress meter if it needs to perform an
+	-- expensive operation, such as hashing a local file.
+	--
+	-- Ensures that the key corresponds to the ContentIdentifier,
+	-- bearing in mind that the file on the remote may have changed
+	-- since the ContentIdentifier was generated.
+	--
+	-- When it returns nothing, the file at the ImportLocation 
+	-- will not be included in the imported tree.
+	--
+	-- When the remote is thirdPartyPopulated, this should check if the
+	-- file stored on the remote is the content of an annex object,
+	-- and return its Key, or Nothing if it is not.
+	--
+	-- Throws exception on failure to access the remote.
+	, importKey :: Maybe (ImportLocation -> ContentIdentifier -> ByteSize -> MeterUpdate -> a (Maybe Key))
+	-- Retrieves a file from the remote. Ensures that the file
+	-- it retrieves has one of the requested ContentIdentifiers.
+	--
+	-- This has to be used rather than retrieveExport
+	-- when a special remote supports imports, since files on such a
+	-- special remote can be changed at any time.
+	--
+	-- Throws exception on failure.
+	, retrieveExportWithContentIdentifier 
+		:: ExportLocation
+		-> [ContentIdentifier]
+		-- file to write content to
+		-> FilePath
+		-- Either the key, or when it's not yet known, a callback
+		-- that generates a key from the downloaded content.
+		-> Either Key (a Key)
+		-> MeterUpdate
+		-> a (Key, Verification)
+	-- Exports content to an ExportLocation, and returns the
+	-- ContentIdentifier corresponding to the content it stored.
+	--
+	-- This is used rather than storeExport when a special remote
+	-- supports imports, since files on such a special remote can be
+	-- changed at any time.
+	--
+	-- Since other things can modify the same file on the special
+	-- remote, this must take care to not overwrite such modifications,
+	-- and only overwrite a file that has one of the ContentIdentifiers
+	-- passed to it, unless listContents can recover an overwritten file.
+	--
+	-- Also, since there can be concurrent writers, the implementation
+	-- needs to make sure that the ContentIdentifier it returns
+	-- corresponds to what it wrote, not to what some other writer
+	-- wrote.
+	--
+	-- Throws exception on failure.
+	, storeExportWithContentIdentifier
+		:: FilePath
+		-> Key
+		-> ExportLocation
+		-- old content that it's safe to overwrite
+		-> [ContentIdentifier]
+		-> MeterUpdate
+		-> a ContentIdentifier
+	-- This is used rather than removeExport when a special remote
+	-- supports imports.
+	--
+	-- It should only remove a file from the remote when it has one
+	-- of the ContentIdentifiers passed to it, unless listContents
+	-- can recover an overwritten file.
+	--
+	-- It needs to handle races similar to storeExportWithContentIdentifier.
+	--
+	-- Throws an exception when unable to remove.
+	, removeExportWithContentIdentifier
+		:: Key
+		-> ExportLocation
+		-> [ContentIdentifier]
+		-> a ()
+	-- Removes a directory from the export, but only when it's empty.
+	-- Used instead of removeExportDirectory when a special remote
+	-- supports imports.
+	--
+	-- If the directory is not empty, it should succeed.
+	--
+	-- Throws exception if unable to contact the remote, or perhaps if
+	-- the remote refuses to let the directory be removed.
+	, removeExportDirectoryWhenEmpty :: Maybe (ExportDirectory -> a ())
+	-- Checks if the specified ContentIdentifier is exported to the
+	-- remote at the specified ExportLocation.
+	-- Throws an exception if the remote cannot be accessed.
+	, checkPresentExportWithContentIdentifier
+		:: Key
+		-> ExportLocation
+		-> [ContentIdentifier]
+		-> a Bool
+	}
+
diff --git a/Types/RemoteConfig.hs b/Types/RemoteConfig.hs
new file mode 100644
index 0000000000..7b9662c958
--- /dev/null
+++ b/Types/RemoteConfig.hs
@@ -0,0 +1,72 @@
+{- git-annex remote config types
+ -
+ - Copyright 2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE GADTs #-}
+
+module Types.RemoteConfig where
+
+import qualified Data.Map as M
+import qualified Data.Set as S
+import Data.Typeable
+
+import Types.ProposedAccepted
+
+type RemoteConfigField = ProposedAccepted String
+
+{- What the user provides to configure the remote, and what is stored for
+ - later; a bunch of fields and values. -}
+type RemoteConfig = M.Map RemoteConfigField (ProposedAccepted String)
+
+{- Before being used a RemoteConfig has to be parsed. -}
+data ParsedRemoteConfig = ParsedRemoteConfig
+	{ parsedRemoteConfigMap :: M.Map RemoteConfigField RemoteConfigValue
+	, unparsedRemoteConfig :: RemoteConfig
+	}
+
+{- Remotes can have configuration values of many types, so use Typeable
+ - to let them all be stored in here. -}
+data RemoteConfigValue where
+	RemoteConfigValue :: Typeable v => v -> RemoteConfigValue
+
+{- Parse a field's value provided by the user into a RemoteConfigValue.
+ -
+ - The RemoteConfig is provided to the parser function for cases
+ - where multiple fields need to be looked at. However, it's important
+ - that, when a parser looks at an additional field in that way, the
+ - parser list contains a dedicated parser for that field as well.
+ - Presence of fields that are not included in this list will cause
+ - a parse failure.
+ -}
+data RemoteConfigFieldParser = RemoteConfigFieldParser
+	{ parserForField :: RemoteConfigField
+	, valueParser :: Maybe (ProposedAccepted String) -> RemoteConfig -> Either String (Maybe RemoteConfigValue)
+	, fieldDesc :: FieldDesc
+	, valueDesc :: Maybe ValueDesc
+	}
+
+data FieldDesc
+	= FieldDesc String
+	| HiddenField
+
+newtype ValueDesc = ValueDesc String
+
+data RemoteConfigParser = RemoteConfigParser
+	{ remoteConfigFieldParsers :: [RemoteConfigFieldParser]
+	, remoteConfigRestPassthrough :: Maybe (RemoteConfigField -> Bool, [(String, FieldDesc)])
+	}
+
+mkRemoteConfigParser :: Monad m => [RemoteConfigFieldParser] -> RemoteConfig -> m RemoteConfigParser
+mkRemoteConfigParser l _ = pure (RemoteConfigParser l Nothing)
+
+addRemoteConfigParser :: [RemoteConfigFieldParser] -> RemoteConfigParser -> RemoteConfigParser
+addRemoteConfigParser l rpc = rpc
+	{ remoteConfigFieldParsers = 
+		remoteConfigFieldParsers rpc ++ filter isnew l
+	}
+  where
+	s = S.fromList (map parserForField (remoteConfigFieldParsers rpc))
+	isnew p = not (S.member (parserForField p) s)
diff --git a/Types/RemoteState.hs b/Types/RemoteState.hs
new file mode 100644
index 0000000000..aef102a7d4
--- /dev/null
+++ b/Types/RemoteState.hs
@@ -0,0 +1,19 @@
+{- git-annex remote state handle type
+ -
+ - Copyright 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.RemoteState where
+
+import Types.UUID
+
+{- When there is per-remote state, remotes are identified by UUID.
+ -
+ - However, sameas remotes mean that two different Remote implementations
+ - can be used for the same underlying data store. To avoid them using
+ - state in conflicting ways, a different UUID needs to be used for each
+ - additional sameas remote.
+ -}
+newtype RemoteStateHandle = RemoteStateHandle UUID
diff --git a/Types/RepoVersion.hs b/Types/RepoVersion.hs
new file mode 100644
index 0000000000..e79d5b21c8
--- /dev/null
+++ b/Types/RepoVersion.hs
@@ -0,0 +1,11 @@
+{- git-annex repository versioning
+ -
+ - Copyright 2010-2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.RepoVersion where
+
+newtype RepoVersion = RepoVersion { fromRepoVersion :: Int }
+	deriving (Eq, Ord, Read, Show)
diff --git a/Types/ScheduledActivity.hs b/Types/ScheduledActivity.hs
new file mode 100644
index 0000000000..87d2b88cbd
--- /dev/null
+++ b/Types/ScheduledActivity.hs
@@ -0,0 +1,68 @@
+{- git-annex scheduled activities
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.ScheduledActivity where
+
+import Common
+import Utility.Scheduled
+import Utility.HumanTime
+import Types.UUID
+
+import Data.Either
+
+data ScheduledActivity 
+	= ScheduledSelfFsck Schedule Duration
+	| ScheduledRemoteFsck UUID Schedule Duration
+	deriving (Eq, Read, Show, Ord)
+
+{- Activities that run on a remote, within a time window, so
+ - should be run when the remote gets connected. -}
+connectActivityUUID :: ScheduledActivity -> Maybe UUID
+connectActivityUUID (ScheduledRemoteFsck u (Schedule _ AnyTime) _) = Just u
+connectActivityUUID _ = Nothing
+
+getSchedule :: ScheduledActivity -> Schedule
+getSchedule (ScheduledSelfFsck s _) = s
+getSchedule (ScheduledRemoteFsck _ s _) = s
+
+getDuration :: ScheduledActivity -> Duration
+getDuration (ScheduledSelfFsck _ d) = d
+getDuration (ScheduledRemoteFsck _ _ d) = d
+
+fromScheduledActivity :: ScheduledActivity -> String
+fromScheduledActivity (ScheduledSelfFsck s d) = unwords
+	[ "fsck self", fromDuration d, fromSchedule s ]
+fromScheduledActivity (ScheduledRemoteFsck u s d) = unwords
+	[ "fsck", fromUUID u, fromDuration d, fromSchedule s ]
+
+toScheduledActivity :: String -> Maybe ScheduledActivity
+toScheduledActivity = eitherToMaybe . parseScheduledActivity
+
+parseScheduledActivity :: String -> Either String ScheduledActivity
+parseScheduledActivity s = case words s of
+	("fsck":"self":d:rest) -> qualified $ ScheduledSelfFsck
+		<$> parseSchedule (unwords rest)
+		<*> parseDuration d
+	("fsck":u:d:rest) -> qualified $ ScheduledRemoteFsck
+		<$> pure (toUUID u)
+		<*> parseSchedule (unwords rest)
+		<*> parseDuration d
+	_ -> qualified $ Left "unknown activity"
+  where
+	qualified (Left e) = Left $ e ++ " in \"" ++ s ++ "\""
+	qualified v = v
+
+fromScheduledActivities :: [ScheduledActivity] -> String
+fromScheduledActivities = intercalate "; " . map fromScheduledActivity
+
+parseScheduledActivities :: String -> Either String [ScheduledActivity]
+parseScheduledActivities s
+	| null bad = Right good
+	| otherwise = Left $ intercalate "; " bad
+  where
+	(bad, good) = partitionEithers $
+		map parseScheduledActivity $ split "; " s
diff --git a/Types/StallDetection.hs b/Types/StallDetection.hs
new file mode 100644
index 0000000000..2278119f4e
--- /dev/null
+++ b/Types/StallDetection.hs
@@ -0,0 +1,58 @@
+{- types for stall detection and banwdith rates
+ -
+ - Copyright 2020-2024 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.StallDetection where
+
+import Utility.DataUnits
+import Utility.HumanTime
+import Utility.Misc
+import Git.Config
+
+data StallDetection
+	= StallDetection BwRate
+	-- ^ Unless the given number of bytes have been sent over the given
+	-- amount of time, there's a stall.
+	| ProbeStallDetection
+	-- ^ Used when unsure how frequently transfer progress is updated,
+	-- or how fast data can be sent.
+	| StallDetectionDisabled
+	deriving (Show)
+
+data BwRate = BwRate ByteSize Duration
+	deriving (Show)
+
+-- Parse eg, "0KiB/60s"
+--
+-- Also, it can be set to "true" (or other git config equivilants)
+-- to enable ProbeStallDetection. 
+-- And "false" (and other git config equivilants) explicitly
+-- disable stall detection.
+parseStallDetection :: String -> Either String StallDetection
+parseStallDetection s = case isTrueFalse s of
+	Nothing -> do
+		v <- parseBwRate s
+		Right (StallDetection v)
+	Just True -> Right ProbeStallDetection
+	Just False -> Right StallDetectionDisabled
+
+readStallDetection :: String -> Maybe StallDetection
+readStallDetection = either (const Nothing) Just . parseStallDetection
+
+parseBwRate :: String -> Either String BwRate
+parseBwRate s = do
+	let (bs, ds) = separate (== '/') s
+	b <- maybe 
+		(Left $ "Unable to parse bandwidth amount " ++ bs)
+		Right
+		(readSize dataUnits bs)
+	d <- parseDuration ds
+	Right (BwRate b d)
+
+readBwRatePerSecond :: String -> Maybe BwRate
+readBwRatePerSecond s = do
+	sz <- readSize dataUnits s
+	return (BwRate sz (Duration 1))
diff --git a/Types/StandardGroups.hs b/Types/StandardGroups.hs
new file mode 100644
index 0000000000..7f83fc3c9d
--- /dev/null
+++ b/Types/StandardGroups.hs
@@ -0,0 +1,109 @@
+{- git-annex standard repository groups
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Types.StandardGroups where
+
+import Types.Remote (RemoteConfig)
+import Types.Group
+import Types.ProposedAccepted
+import Annex.SpecialRemote.Config (preferreddirField)
+
+import qualified Data.Map as M
+
+type PreferredContentExpression = String
+
+data StandardGroup
+	= ClientGroup
+	| TransferGroup
+	| BackupGroup
+	| IncrementalBackupGroup
+	| SmallArchiveGroup
+	| FullArchiveGroup
+	| SourceGroup
+	| ManualGroup
+	| PublicGroup
+	| UnwantedGroup
+	deriving (Eq, Ord, Enum, Bounded, Show)
+
+fromStandardGroup :: StandardGroup -> Group
+fromStandardGroup ClientGroup = Group "client"
+fromStandardGroup TransferGroup = Group "transfer"
+fromStandardGroup BackupGroup = Group "backup"
+fromStandardGroup IncrementalBackupGroup = Group "incrementalbackup"
+fromStandardGroup SmallArchiveGroup = Group "smallarchive"
+fromStandardGroup FullArchiveGroup = Group "archive"
+fromStandardGroup SourceGroup = Group "source"
+fromStandardGroup ManualGroup = Group "manual"
+fromStandardGroup PublicGroup = Group "public"
+fromStandardGroup UnwantedGroup = Group "unwanted"
+
+toStandardGroup :: Group -> Maybe StandardGroup
+toStandardGroup (Group "client") = Just ClientGroup
+toStandardGroup (Group "transfer") = Just TransferGroup
+toStandardGroup (Group "backup") = Just BackupGroup
+toStandardGroup (Group "incrementalbackup") = Just IncrementalBackupGroup
+toStandardGroup (Group "smallarchive") = Just SmallArchiveGroup
+toStandardGroup (Group "archive") = Just FullArchiveGroup
+toStandardGroup (Group "source") = Just SourceGroup
+toStandardGroup (Group "manual") = Just ManualGroup
+toStandardGroup (Group "public") = Just PublicGroup
+toStandardGroup (Group "unwanted") = Just UnwantedGroup
+toStandardGroup _ = Nothing
+
+descStandardGroup :: StandardGroup -> String
+descStandardGroup ClientGroup = "client: a repository on your computer"
+descStandardGroup TransferGroup = "transfer: distributes files to clients"
+descStandardGroup BackupGroup = "full backup: backs up all files"
+descStandardGroup IncrementalBackupGroup = "incremental backup: backs up files not backed up elsewhere"
+descStandardGroup SmallArchiveGroup = "small archive: archives files located in \"archive\" directories"
+descStandardGroup FullArchiveGroup = "full archive: archives all files not archived elsewhere"
+descStandardGroup SourceGroup = "file source: moves files on to other repositories"
+descStandardGroup ManualGroup = "manual mode: only stores files you manually choose"
+descStandardGroup UnwantedGroup = "unwanted: remove content from this repository"
+descStandardGroup PublicGroup = "public: publishes files located in an associated directory"
+
+associatedDirectory :: Maybe RemoteConfig -> StandardGroup -> Maybe FilePath
+associatedDirectory _ SmallArchiveGroup = Just "archive"
+associatedDirectory _ FullArchiveGroup = Just "archive"
+associatedDirectory (Just c) PublicGroup = Just $
+	maybe "public" fromProposedAccepted $
+		M.lookup preferreddirField c
+associatedDirectory Nothing PublicGroup = Just "public"
+associatedDirectory _ _ = Nothing
+
+specialRemoteOnly :: StandardGroup -> Bool
+specialRemoteOnly PublicGroup = True
+specialRemoteOnly _ = False
+
+{- See doc/preferred_content.mdwn for explanations of these expressions. -}
+standardPreferredContent :: StandardGroup -> PreferredContentExpression
+standardPreferredContent ClientGroup = lastResort $
+	"include=* and ((exclude=*/archive/* and exclude=archive/*) or (" ++ notArchived ++ "))"
+standardPreferredContent TransferGroup = lastResort $
+	"not (inallgroup=client and copies=client:2) and (" ++ standardPreferredContent ClientGroup ++ ")"
+standardPreferredContent BackupGroup = "anything"
+standardPreferredContent IncrementalBackupGroup = lastResort
+	"(not copies=backup:1) and (not copies=incrementalbackup:1)"
+standardPreferredContent SmallArchiveGroup = lastResort $
+	"(include=*/archive/* or include=archive/*) and (" ++ standardPreferredContent FullArchiveGroup ++ ")"
+standardPreferredContent FullArchiveGroup = lastResort notArchived
+standardPreferredContent SourceGroup = "not (copies=1)"
+standardPreferredContent ManualGroup = "present and (" ++ standardPreferredContent ClientGroup ++ ")"
+standardPreferredContent PublicGroup = "inpreferreddir"
+standardPreferredContent UnwantedGroup = "not anything"
+
+notArchived :: String
+notArchived = "not (copies=archive:1 or copies=smallarchive:1)"
+	
+{- Most repositories want any content that is only on untrusted
+ - or dead repositories, or that otherwise does not have enough copies.
+ - Does not look at .gitattributes since that is quite a lot slower.
+ -}
+lastResort :: String -> PreferredContentExpression
+lastResort s = "(" ++ s ++ ") or approxlackingcopies=1"
diff --git a/Types/StoreRetrieve.hs b/Types/StoreRetrieve.hs
new file mode 100644
index 0000000000..82bfa8272b
--- /dev/null
+++ b/Types/StoreRetrieve.hs
@@ -0,0 +1,52 @@
+{- Types for Storer and Retriever actions for remotes.
+ -
+ - Copyright 2014-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes #-}
+
+module Types.StoreRetrieve where
+
+import Annex.Common
+import Utility.Metered
+import Utility.Hash (IncrementalVerifier)
+
+import qualified Data.ByteString.Lazy as L
+
+-- A source of a Key's content.
+data ContentSource
+	= FileContent FilePath
+	| ByteContent L.ByteString
+
+isByteContent :: ContentSource -> Bool
+isByteContent (ByteContent _) = True
+isByteContent (FileContent _) = False
+
+-- Action that stores a Key's content on a remote.
+-- Can throw exceptions.
+type Storer = Key -> ContentSource -> MeterUpdate -> Annex ()
+
+-- Action that retrieves a Key's content from a remote, passing it to a
+-- callback, which will fully consume the content before returning.
+--
+-- Throws exception if key is not present, or remote is not accessible.
+--
+-- When it retrieves FileContent, it is responsible for updating the
+-- MeterUpdate. And when the IncrementalVerifier is passed to it,
+-- and it retrieves FileContent, it can feed some or all of the file's
+-- content to the verifier before running the callback.
+-- This should not be done when it retrieves ByteContent.
+type Retriever = forall a.
+	Key -> MeterUpdate -> Maybe IncrementalVerifier
+		-> (ContentSource -> Annex a) -> Annex a
+
+-- Action that removes a Key's content from a remote.
+-- Succeeds if key is already not present.
+-- Throws an exception if the remote is not accessible.
+type Remover = Key -> Annex ()
+
+-- Checks if a Key's content is present on a remote.
+-- Throws an exception if the remote is not accessible.
+type CheckPresent = Key -> Annex Bool
diff --git a/Types/Test.hs b/Types/Test.hs
new file mode 100644
index 0000000000..90a182043f
--- /dev/null
+++ b/Types/Test.hs
@@ -0,0 +1,26 @@
+{- git-annex test data types.
+ -
+ - Copyright 2011-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Test where
+
+import Test.Tasty.Options
+
+import Types.Concurrency
+import Types.Command
+import Git.Types
+
+data TestOptions = TestOptions
+	{ tastyOptionSet :: OptionSet
+	, keepFailuresOption :: Bool
+	, fakeSsh :: Bool
+	, concurrentJobs :: Maybe Concurrency
+	, testGitConfig :: [(ConfigKey, ConfigValue)]
+	, testDebug :: Bool
+	, internalData :: CmdParams
+	}
+
+type TestRunner = TestOptions -> IO ()
diff --git a/Types/Transfer.hs b/Types/Transfer.hs
new file mode 100644
index 0000000000..55b3de5921
--- /dev/null
+++ b/Types/Transfer.hs
@@ -0,0 +1,99 @@
+{- git-annex transfer types
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE FlexibleInstances #-}
+
+module Types.Transfer (
+	module Types.Transfer,
+	module Types.Direction
+) where
+
+import Types
+import Types.Remote (Verification(..))
+import Types.Key
+import Types.Direction
+import Utility.PID
+import Utility.QuickCheck
+import Utility.Url
+import Utility.FileSystemEncoding
+
+import Data.Time.Clock.POSIX
+import Control.Concurrent
+import Control.Applicative
+import Prelude
+
+{- Enough information to uniquely identify a transfer. -}
+data Transfer = Transfer
+	{ transferDirection :: Direction
+	, transferUUID :: UUID
+	, transferKeyData :: KeyData
+	}
+	deriving (Eq, Ord, Show, Read)
+
+transferKey :: Transfer -> Key
+transferKey = mkKey . const . transferKeyData
+
+{- Information about a Transfer, stored in the transfer information file.
+ -
+ - Note that the associatedFile may not correspond to a file in the local
+ - git repository. It's some file, possibly relative to some directory,
+ - of some repository, that was acted on to initiate the transfer.
+ -}
+data TransferInfo = TransferInfo
+	{ startedTime :: Maybe POSIXTime
+	, transferPid :: Maybe PID
+	, transferTid :: Maybe ThreadId
+	, transferRemote :: Maybe Remote
+	, bytesComplete :: Maybe Integer
+	, associatedFile :: AssociatedFile
+	, transferPaused :: Bool
+	}
+	deriving (Show, Eq, Ord)
+
+stubTransferInfo :: TransferInfo
+stubTransferInfo = TransferInfo Nothing Nothing Nothing Nothing Nothing (AssociatedFile Nothing) False
+
+instance Arbitrary TransferInfo where
+	arbitrary = TransferInfo
+		<$> arbitrary
+		<*> arbitrary
+		<*> pure Nothing -- cannot generate a ThreadID
+		<*> pure Nothing -- remote not needed
+		<*> arbitrary
+		<*> arbitrary
+		<*> arbitrary
+
+class Observable a where
+	observeBool :: a -> Bool
+	observeFailure :: a
+
+instance Observable Bool where
+	observeBool = id
+	observeFailure = False
+
+instance Observable (Bool, Verification) where
+	observeBool = fst
+	observeFailure = (False, UnVerified)
+
+instance Observable (Either e Bool) where
+	observeBool (Left _) = False
+	observeBool (Right b) = b
+	observeFailure = Right False
+
+instance Observable (Maybe a) where
+	observeBool (Just _) = True
+	observeBool Nothing = False
+	observeFailure = Nothing
+
+class Transferrable t where
+	descTransfrerrable :: t -> Maybe String
+
+instance Transferrable AssociatedFile where
+	descTransfrerrable (AssociatedFile af) = fromRawFilePath <$> af
+
+instance Transferrable URLString where
+	descTransfrerrable = Just
diff --git a/Types/Transferrer.hs b/Types/Transferrer.hs
new file mode 100644
index 0000000000..7cdfd10f36
--- /dev/null
+++ b/Types/Transferrer.hs
@@ -0,0 +1,162 @@
+{- protocol used by "git-annex transferrer"
+ -
+ - Copyright 2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Transferrer where
+
+import Annex.Common
+import Types.Messages
+import Git.Types (RemoteName)
+import qualified Utility.SimpleProtocol as Proto
+import Utility.Format
+import Utility.Metered (TotalSize(..))
+
+import Data.Char
+import qualified Data.ByteString.Lazy as L
+
+-- Sent to start a transfer.
+data TransferRequest
+	= UploadRequest TransferRemote Key TransferAssociatedFile
+	| DownloadRequest TransferRemote Key TransferAssociatedFile
+	| AssistantUploadRequest TransferRemote Key TransferAssociatedFile
+	| AssistantDownloadRequest TransferRemote Key TransferAssociatedFile
+	deriving (Show)
+
+transferRequestRemote :: TransferRequest -> TransferRemote
+transferRequestRemote (UploadRequest r _ _) = r
+transferRequestRemote (DownloadRequest r _ _) = r
+transferRequestRemote (AssistantUploadRequest r _ _) = r
+transferRequestRemote (AssistantDownloadRequest r _ _) = r
+
+data TransferRemote
+	= TransferRemoteUUID UUID
+	| TransferRemoteName RemoteName
+	deriving (Show, Eq)
+
+newtype TransferAssociatedFile = TransferAssociatedFile AssociatedFile
+	deriving (Show)
+
+data TransferResponse
+	= TransferOutput SerializedOutput
+	-- ^ any number may be sent before TransferResult
+	| TransferResult Bool
+	deriving (Show)
+
+data TransferSerializedOutputResponse = TransferSerializedOutputResponse SerializedOutputResponse
+	deriving (Show)
+
+instance Proto.Sendable TransferRequest where
+	formatMessage (UploadRequest r kd af) =
+		[ "u"
+		, Proto.serialize r
+		, Proto.serialize kd
+		, Proto.serialize af
+		]
+	formatMessage (DownloadRequest r kd af) =
+		[ "d"
+		, Proto.serialize r
+		, Proto.serialize kd
+		, Proto.serialize af
+		]
+	formatMessage (AssistantUploadRequest r kd af) =
+		[ "au"
+		, Proto.serialize r
+		, Proto.serialize kd
+		, Proto.serialize af
+		]
+	formatMessage (AssistantDownloadRequest r kd af) =
+		[ "ad"
+		, Proto.serialize r
+		, Proto.serialize kd
+		, Proto.serialize af
+		]
+
+instance Proto.Receivable TransferRequest where
+	parseCommand "u" = Proto.parse3 UploadRequest
+	parseCommand "d" = Proto.parse3 DownloadRequest
+	parseCommand "au" = Proto.parse3 AssistantUploadRequest
+	parseCommand "ad" = Proto.parse3 AssistantDownloadRequest
+	parseCommand _ = Proto.parseFail
+
+instance Proto.Sendable TransferResponse where
+	formatMessage (TransferOutput (OutputMessage m)) =
+		["om", Proto.serialize (decodeBS (encode_c isUtf8Byte m))]
+	formatMessage (TransferOutput (OutputError e)) =
+		["oe", Proto.serialize (decodeBS (encode_c isUtf8Byte (encodeBS e)))]
+	formatMessage (TransferOutput BeginProgressMeter) =
+		["opb"]
+	formatMessage (TransferOutput (UpdateProgressMeterTotalSize (TotalSize sz))) =
+		["ops", Proto.serialize sz]
+	formatMessage (TransferOutput (UpdateProgressMeter n)) =
+		["op", Proto.serialize n]
+	formatMessage (TransferOutput EndProgressMeter) =
+		["ope"]
+	formatMessage (TransferOutput BeginPrompt) =
+		["oprb"]
+	formatMessage (TransferOutput EndPrompt) =
+		["opre"]
+	formatMessage (TransferOutput (JSONObject b)) =
+		["oj", Proto.serialize (decodeBS (encode_c isUtf8Byte (L.toStrict b)))]
+	formatMessage (TransferResult True) =
+		["t"]
+	formatMessage (TransferResult False) =
+		["f"]
+
+instance Proto.Receivable TransferResponse where
+	parseCommand "om" = Proto.parse1 $
+		TransferOutput . OutputMessage . decode_c . encodeBS
+	parseCommand "oe" = Proto.parse1 $
+		TransferOutput . OutputError . decodeBS . decode_c . encodeBS
+	parseCommand "opb" = Proto.parse0 $
+		TransferOutput BeginProgressMeter
+	parseCommand "ops" = Proto.parse1 $
+		TransferOutput . UpdateProgressMeterTotalSize . TotalSize
+	parseCommand "op" = Proto.parse1 $
+		TransferOutput . UpdateProgressMeter
+	parseCommand "ope" = Proto.parse0 $
+		TransferOutput EndProgressMeter
+	parseCommand "oprb" = Proto.parse0 $
+		TransferOutput BeginPrompt
+	parseCommand "opre" = Proto.parse0 $
+		TransferOutput EndPrompt
+	parseCommand "oj" = Proto.parse1 $
+		TransferOutput . JSONObject . L.fromStrict . decode_c . encodeBS
+	parseCommand "t" = Proto.parse0 $
+		TransferResult True
+	parseCommand "f" = Proto.parse0 $
+		TransferResult False
+	parseCommand _ = Proto.parseFail
+
+instance Proto.Sendable TransferSerializedOutputResponse where
+	formatMessage (TransferSerializedOutputResponse ReadyPrompt) = ["opr"]
+
+instance Proto.Receivable TransferSerializedOutputResponse where
+	parseCommand "opr" = Proto.parse0 (TransferSerializedOutputResponse ReadyPrompt)
+	parseCommand _ = Proto.parseFail
+
+instance Proto.Serializable TransferRemote where
+	serialize (TransferRemoteUUID u) = 'u':fromUUID u
+	-- A remote name could contain whitespace or newlines, which needs
+	-- to be escaped for the protocol. Use C-style encoding.
+	serialize (TransferRemoteName r) = 'r':decodeBS (encode_c is_space_or_unicode (encodeBS r))
+	  where
+		is_space_or_unicode c = isUtf8Byte c || isSpace (chr (fromIntegral c))
+
+	deserialize ('u':u) = Just (TransferRemoteUUID (toUUID u))
+	deserialize ('r':r) = Just (TransferRemoteName (decodeBS (decode_c (encodeBS r))))
+	deserialize _ = Nothing
+
+instance Proto.Serializable TransferAssociatedFile where
+	-- Comes last, so whitespace is ok. But, in case the filename
+	-- contains eg a newline, escape it. Use C-style encoding.
+	serialize (TransferAssociatedFile (AssociatedFile (Just f))) =
+		decodeBS (encode_c isUtf8Byte f)
+	serialize (TransferAssociatedFile (AssociatedFile Nothing)) = ""
+
+	deserialize "" = Just $ TransferAssociatedFile $
+		AssociatedFile Nothing
+	deserialize s = Just $ TransferAssociatedFile $
+		AssociatedFile $ Just $ decode_c $ encodeBS s
diff --git a/Types/TransferrerPool.hs b/Types/TransferrerPool.hs
new file mode 100644
index 0000000000..c8c560e682
--- /dev/null
+++ b/Types/TransferrerPool.hs
@@ -0,0 +1,59 @@
+{- A pool of "git-annex transfer" processes available for use
+ -
+ - Copyright 2013-2020 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.TransferrerPool where
+
+import Common
+
+import Control.Concurrent.STM hiding (check)
+
+type TransferrerPool = TVar [TransferrerPoolItem]
+
+type CheckTransferrer = IO Bool
+type MkCheckTransferrer = IO (IO Bool)
+
+{- Each item in the pool may have a transferrer running, and has an
+ - IO action that can be used to check if it's still ok to use the
+ - transferrer. -}
+data TransferrerPoolItem = TransferrerPoolItem (Maybe Transferrer) CheckTransferrer
+
+data Transferrer = Transferrer
+	{ transferrerRead :: Handle
+	, transferrerWrite :: Handle
+	, transferrerHandle :: ProcessHandle
+	, transferrerShutdown :: IO ()
+	-- ^ Closes the FDs and waits for the process to exit. 
+	-- Should be used when the transferrer is in between transfers,
+	-- as otherwise it may not shutdown promptly.
+	}
+
+newTransferrerPool :: IO TransferrerPool
+newTransferrerPool = newTVarIO []
+
+popTransferrerPool :: TransferrerPool -> STM (Maybe TransferrerPoolItem, Int)
+popTransferrerPool p = do
+	l <- readTVar p
+	case l of
+		[] -> return (Nothing, 0)
+		(i:is) -> do
+			writeTVar p is
+			return $ (Just i, length is)
+
+pushTransferrerPool :: TransferrerPool -> TransferrerPoolItem -> STM ()
+pushTransferrerPool p i = do
+	l <- readTVar p
+	let l' = i:l
+	writeTVar p l'
+
+{- Note that making a CheckTransferrer may allocate resources,
+ - such as a NotificationHandle, so it's important that the returned
+ - TransferrerPoolItem is pushed into the pool, and not left to be
+ - garbage collected. -}
+mkTransferrerPoolItem :: MkCheckTransferrer -> Transferrer -> IO TransferrerPoolItem
+mkTransferrerPoolItem mkcheck t = do
+	check <- mkcheck
+	return $ TransferrerPoolItem (Just t) check
diff --git a/Types/Transitions.hs b/Types/Transitions.hs
new file mode 100644
index 0000000000..5cd5ffa247
--- /dev/null
+++ b/Types/Transitions.hs
@@ -0,0 +1,19 @@
+{- git-annex transitions data types
+ -
+ - Copyright 2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Transitions where
+
+import Utility.RawFilePath
+
+import qualified Data.ByteString.Lazy as L
+import Data.ByteString.Builder
+
+data FileTransition
+	= ChangeFile Builder
+	| PreserveFile
+
+type TransitionCalculator = RawFilePath -> L.ByteString -> FileTransition
diff --git a/Types/TrustLevel.hs b/Types/TrustLevel.hs
new file mode 100644
index 0000000000..15487ad729
--- /dev/null
+++ b/Types/TrustLevel.hs
@@ -0,0 +1,51 @@
+{- git-annex trust levels
+ -
+ - Copyright 2010 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE FlexibleInstances #-}
+
+module Types.TrustLevel (
+	TrustLevel(..),
+	TrustMap,
+	readTrustLevel,
+	showTrustLevel,
+	prop_read_show_TrustLevel
+) where
+
+import qualified Data.Map as M
+import Data.Default
+import Data.Ord
+
+import Types.UUID
+
+data TrustLevel = DeadTrusted | UnTrusted | SemiTrusted | Trusted
+	deriving (Eq, Enum, Ord, Bounded, Show)
+
+instance Default TrustLevel  where
+	def = SemiTrusted
+
+instance Default (Down TrustLevel)  where
+	def = Down def
+
+type TrustMap = M.Map UUID TrustLevel
+
+readTrustLevel :: String -> Maybe TrustLevel
+readTrustLevel "trusted" = Just Trusted
+readTrustLevel "untrusted" = Just UnTrusted
+readTrustLevel "semitrusted" = Just SemiTrusted
+readTrustLevel "dead" = Just DeadTrusted
+readTrustLevel _ = Nothing
+
+showTrustLevel :: TrustLevel -> String
+showTrustLevel Trusted = "trusted"
+showTrustLevel UnTrusted = "untrusted"
+showTrustLevel SemiTrusted = "semitrusted"
+showTrustLevel DeadTrusted = "dead"
+
+prop_read_show_TrustLevel :: Bool
+prop_read_show_TrustLevel = all check [minBound .. maxBound]
+  where
+	check l = readTrustLevel (showTrustLevel l) == Just l
diff --git a/Types/UUID.hs b/Types/UUID.hs
new file mode 100644
index 0000000000..d7e49ff937
--- /dev/null
+++ b/Types/UUID.hs
@@ -0,0 +1,109 @@
+{- git-annex UUID type
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE TypeSynonymInstances, FlexibleInstances, GeneralizedNewtypeDeriving #-}
+
+module Types.UUID where
+
+import qualified Data.ByteString as B
+import qualified Data.Text as T
+import qualified Data.Map as M
+import qualified Data.UUID as U
+import Data.Maybe
+import Data.String
+import Data.ByteString.Builder
+import qualified Data.Semigroup as Sem
+
+import Git.Types (ConfigValue(..))
+import Utility.FileSystemEncoding
+import Utility.QuickCheck
+import Utility.Aeson
+import qualified Utility.SimpleProtocol as Proto
+
+-- A UUID is either an arbitrary opaque string, or UUID info may be missing.
+data UUID = NoUUID | UUID B.ByteString
+	deriving (Eq, Ord, Show, Read)
+
+class FromUUID a where
+	fromUUID :: UUID -> a
+
+class ToUUID a where
+	toUUID :: a -> UUID
+
+instance FromUUID UUID where
+	fromUUID = id
+
+instance ToUUID UUID where
+	toUUID = id
+
+instance FromUUID B.ByteString where
+	fromUUID (UUID u) = u
+	fromUUID NoUUID = B.empty
+
+instance ToUUID B.ByteString where
+	toUUID b
+		| B.null b = NoUUID
+		| otherwise = UUID b
+
+instance FromUUID String where
+	fromUUID s = decodeBS (fromUUID s)
+
+instance ToUUID String where
+	toUUID s = toUUID (encodeBS s)
+
+instance FromUUID ConfigValue where
+	fromUUID s = (ConfigValue (fromUUID s))
+
+instance ToUUID ConfigValue where
+	toUUID (ConfigValue v) = toUUID v
+	toUUID NoConfigValue = NoUUID
+
+-- There is no matching FromUUID U.UUID because a git-annex UUID may
+-- be NoUUID or perhaps contain something not allowed in a canonical UUID.
+instance ToUUID U.UUID where
+	toUUID = toUUID . U.toASCIIBytes
+
+instance ToJSON' UUID where
+	toJSON' (UUID u) = toJSON' u
+	toJSON' NoUUID = toJSON' ""
+
+instance FromJSON UUID where
+	parseJSON (String t)
+		| isUUID s = pure (toUUID s)
+		| otherwise = mempty
+	  where
+		s = T.unpack t
+	parseJSON _ = mempty
+
+buildUUID :: UUID -> Builder
+buildUUID (UUID b) = byteString b
+buildUUID NoUUID = mempty
+
+isUUID :: String -> Bool
+isUUID = isJust . U.fromString
+
+-- A description of a UUID.
+newtype UUIDDesc = UUIDDesc B.ByteString
+	deriving (Eq, Sem.Semigroup, Monoid, IsString)
+
+fromUUIDDesc :: UUIDDesc -> String
+fromUUIDDesc (UUIDDesc d) = decodeBS d
+
+toUUIDDesc :: String -> UUIDDesc
+toUUIDDesc = UUIDDesc . encodeBS
+
+type UUIDDescMap = M.Map UUID UUIDDesc
+
+instance Proto.Serializable UUID where
+	serialize = fromUUID
+	deserialize = Just . toUUID
+
+instance Arbitrary UUID where
+	arbitrary = frequency [(1, return NoUUID), (3, UUID <$> arb)]
+	  where
+		arb = encodeBS <$> listOf1 (elements uuidchars)
+		uuidchars = '-' : ['a'..'z'] ++ ['A'..'Z'] ++ ['0'..'9']
diff --git a/Types/Upgrade.hs b/Types/Upgrade.hs
new file mode 100644
index 0000000000..0249437443
--- /dev/null
+++ b/Types/Upgrade.hs
@@ -0,0 +1,10 @@
+{- git-annex upgrade types
+ -
+ - Copyright 2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.Upgrade where
+
+data UpgradeResult = UpgradeSuccess | UpgradeFailed | UpgradeDeferred
diff --git a/Types/UrlContents.hs b/Types/UrlContents.hs
new file mode 100644
index 0000000000..c2d2ca86ad
--- /dev/null
+++ b/Types/UrlContents.hs
@@ -0,0 +1,20 @@
+{- git-annex URL contents
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.UrlContents (
+	UrlContents(..),
+) where
+
+import Utility.Url
+
+data UrlContents
+	-- An URL contains a file, whose size may be known.
+	-- There might be a nicer filename to use.
+	= UrlContents (Maybe Integer) (Maybe FilePath)
+	-- Sometimes an URL points to multiple files, each accessible
+	-- by their own URL.
+	| UrlMulti [(URLString, Maybe Integer, FilePath)]
diff --git a/Types/VectorClock.hs b/Types/VectorClock.hs
new file mode 100644
index 0000000000..91ffe2ca66
--- /dev/null
+++ b/Types/VectorClock.hs
@@ -0,0 +1,31 @@
+{- git-annex vector clocks
+ -
+ - Copyright 2017-2021 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.VectorClock where
+
+import Data.Time.Clock.POSIX
+import Control.Applicative
+import Prelude
+
+import Utility.QuickCheck
+
+-- | Some very old logs did not have any time stamp at all;
+-- Unknown is used for those.
+data VectorClock = Unknown | VectorClock POSIXTime
+	deriving (Eq, Ord, Show)
+
+-- | This is a candidate value to use in a VectorClock. It
+-- may not be suitable to use this, when a previously used VectorClock
+-- is the same or higher.
+data CandidateVectorClock = CandidateVectorClock POSIXTime
+
+-- Unknown is oldest.
+prop_VectorClock_sane :: Bool
+prop_VectorClock_sane = Unknown < VectorClock 1
+
+instance Arbitrary  VectorClock where
+	arbitrary = VectorClock <$> arbitrary
diff --git a/Types/View.hs b/Types/View.hs
new file mode 100644
index 0000000000..b6ae4bfeed
--- /dev/null
+++ b/Types/View.hs
@@ -0,0 +1,69 @@
+{- types for metadata based branch views
+ -
+ - Copyright 2014-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Types.View where
+
+import Types.MetaData
+import Utility.QuickCheck
+import Utility.Monad
+import qualified Git
+
+import qualified Data.Set as S
+
+{- A view is a list of fields with filters on their allowed values,
+ - which are applied to files in a parent git branch. -}
+data View = View
+	{ viewParentBranch :: Git.Branch
+	, viewComponents :: [ViewComponent]
+	}
+	deriving (Eq, Read, Show)
+
+instance Arbitrary View where
+	arbitrary = View (Git.Ref "foo")
+		<$> resize 10 (listOf arbitrary)
+
+data ViewComponent = ViewComponent
+	{ viewField :: MetaField
+	, viewFilter :: ViewFilter
+	, viewVisible :: Bool
+	}
+	deriving (Eq, Read, Show)
+
+instance Arbitrary ViewComponent where
+	arbitrary = ViewComponent <$> arbitrary <*> arbitrary <*> arbitrary
+
+data ViewFilter
+	= FilterValues (S.Set MetaValue)
+	| FilterGlob String
+	| ExcludeValues (S.Set MetaValue)
+	| FilterValuesOrUnset (S.Set MetaValue) ViewUnset
+	| FilterGlobOrUnset String ViewUnset
+	deriving (Eq, Read, Show)
+
+newtype ViewUnset = ViewUnset String
+	deriving (Eq, Read, Show)
+
+instance Arbitrary ViewFilter where
+	arbitrary = do
+		s <- S.fromList <$> resize 10 (listOf arbitrary)
+		ifM arbitrary
+			( return (FilterValues s)
+			, return (ExcludeValues s)
+			)
+
+mkViewComponent :: MetaField -> ViewFilter -> ViewComponent
+mkViewComponent f vf = ViewComponent f vf (multiValue vf)
+
+{- Can a ViewFilter match multiple different MetaValues? -}
+multiValue :: ViewFilter -> Bool
+multiValue (FilterValues s) = S.size s > 1
+multiValue (FilterGlob _) = True
+multiValue (ExcludeValues _) = False
+multiValue (FilterValuesOrUnset _ _) = True
+multiValue (FilterGlobOrUnset _ _) = True
diff --git a/Types/WorkerPool.hs b/Types/WorkerPool.hs
new file mode 100644
index 0000000000..0df8799203
--- /dev/null
+++ b/Types/WorkerPool.hs
@@ -0,0 +1,166 @@
+{- Worker thread pool.
+ -
+ - Copyright 2019-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Types.WorkerPool where
+
+import Types.Direction
+
+import Control.Concurrent
+import Control.Concurrent.Async
+import qualified Data.Set as S
+
+-- | Pool of worker threads. 
+data WorkerPool t = WorkerPool
+	{ usedStages :: UsedStages
+	, workerList :: [Worker t]
+	, spareVals :: [t]
+	-- ^ Normally there is one value for each IdleWorker,
+	-- but there can temporarily be fewer values, when a thread is
+	-- changing between stages.
+	} 
+
+instance Show (WorkerPool t) where
+	show p = unwords
+		[ "WorkerPool"
+		, show (usedStages p)
+		, show (workerList p)
+		, show (length (spareVals p))
+		]
+
+-- | A worker can either be idle or running an Async action.
+-- And it is used for some stage.
+data Worker t
+	= IdleWorker WorkerStage
+	| ActiveWorker (Async t) WorkerStage
+
+instance Show (Worker t) where
+	show (IdleWorker s) = "IdleWorker " ++ show s
+	show (ActiveWorker _ s) = "ActiveWorker " ++ show s
+
+data WorkerStage
+	= StartStage
+	-- ^ All threads start in this stage, and then transition away from
+	-- it to the initialStage when they begin doing work. This should
+	-- never be included in UsedStages, because transition from some
+	-- other stage back to this one could result in a deadlock.
+	| PerformStage
+	-- ^ Running a CommandPerform action.
+	| CleanupStage
+	-- ^ Running a CommandCleanup action.
+	| TransferStage Direction
+	-- ^ Transferring content to or from a remote.
+	| VerifyStage
+	-- ^ Verifying content, eg by calculating a checksum.
+	deriving (Show, Eq, Ord)
+
+-- | Set of stages that make sense to be used while performing an action,
+-- and the stage to use initially.
+-- 
+-- Transitions between these stages will block as needed until there's a
+-- free Worker in the pool for the new stage.
+-- 
+-- Actions that indicate they are in some other stage won't change the
+-- stage, and so there will be no blocking before starting them.
+data UsedStages = UsedStages
+	{ initialStage :: WorkerStage
+	, stageSet :: S.Set WorkerStage
+	}
+	deriving (Show)
+
+memberStage :: WorkerStage -> UsedStages -> Bool
+memberStage s u = S.member s (stageSet u)
+
+-- | The default is to use only the CommandPerform and CommandCleanup
+-- stages. Since cleanup actions often don't contend much with
+-- perform actions, this prevents blocking starting the next perform action
+-- on finishing the previous cleanup action.
+commandStages :: UsedStages
+commandStages = UsedStages
+	{ initialStage = PerformStage
+	, stageSet = S.fromList [PerformStage, CleanupStage]
+	}
+
+-- | This is mostly useful for downloads, not for uploads. A download
+-- is often bottlenecked on the network or another disk than the one
+-- containing the repository. When verification is not done incrementally,
+-- it bottlenecks on the disk containing the repository or on the CPU.
+-- So it makes sense to run the download and verify stages separately.
+-- 
+-- For uploads, there is no separate verify step to this is less likely
+-- to be useful than commandStages. However, a separate stage is provided
+-- for Uploads. That can be useful when a command downloads from one remote
+-- (eg using the network) and uploads to another remote (eg using a disk).
+transferStages :: UsedStages
+transferStages = UsedStages
+	{ initialStage = TransferStage Download
+	, stageSet = S.fromList
+		[ TransferStage Download
+		, TransferStage Upload
+		, VerifyStage
+		]
+	}
+
+workerStage :: Worker t -> WorkerStage
+workerStage (IdleWorker s) = s
+workerStage (ActiveWorker _ s) = s
+
+workerAsync :: Worker t -> Maybe (Async t)
+workerAsync (IdleWorker _) = Nothing
+workerAsync (ActiveWorker aid _) = Just aid
+
+-- | Allocates a WorkerPool that has the specified number of workers
+-- in it, of each stage.
+--
+-- The stages are distributed evenly throughout.
+allocateWorkerPool :: t -> Int -> UsedStages -> WorkerPool t
+allocateWorkerPool t n u = WorkerPool
+	{ usedStages = u
+	, workerList = map IdleWorker $
+		take totalthreads $ concat $ repeat stages
+	, spareVals = replicate totalthreads t
+	}
+  where
+	stages = StartStage : S.toList (stageSet u)
+	totalthreads = n * length stages
+
+addWorkerPool :: Worker t -> WorkerPool t -> WorkerPool t
+addWorkerPool w pool = pool { workerList = w : workerList pool }
+
+-- | Removes a worker from the pool whose Async uses the ThreadId.
+--
+-- Each Async has its own ThreadId, so this stops once it finds
+-- a match.
+removeThreadIdWorkerPool :: ThreadId -> WorkerPool t -> Maybe ((Async t, WorkerStage), WorkerPool t)
+removeThreadIdWorkerPool tid pool = go [] (workerList pool)
+  where
+	go _ [] = Nothing
+	go c (ActiveWorker a stage : rest)
+		| asyncThreadId a == tid =
+			let pool' = pool { workerList = (c++rest) }
+			in Just ((a, stage), pool')
+	go c (v : rest) = go (v:c) rest
+
+deactivateWorker :: WorkerPool t -> Async t -> t -> WorkerPool t
+deactivateWorker pool aid t = pool
+	{ workerList = go (workerList pool)
+	, spareVals = t : spareVals pool
+	}
+  where
+	go [] = []
+	go (w@(IdleWorker _) : rest) = w : go rest
+	go (w@(ActiveWorker a st) : rest)
+		| a == aid = IdleWorker st : rest
+		| otherwise = w : go rest
+
+allIdle :: WorkerPool t -> Bool
+allIdle pool = all idle (workerList pool)
+	-- If this does not hold, a thread must be transitioning between
+	-- states, so it's not really idle.
+	&& length (spareVals pool) == length (workerList pool)
+  where
+	idle (IdleWorker _) = True
+	idle (ActiveWorker _ _) = False
diff --git a/Upgrade.hs b/Upgrade.hs
new file mode 100644
index 0000000000..4f6585b2ea
--- /dev/null
+++ b/Upgrade.hs
@@ -0,0 +1,139 @@
+{- git-annex upgrade support
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Upgrade where
+
+import Annex.Common
+import Types.Upgrade
+import qualified Annex
+import qualified Git
+import Config
+import Annex.Path
+import Annex.Version
+import Types.RepoVersion
+import Logs.Upgrade
+#ifndef mingw32_HOST_OS
+import qualified Upgrade.V0
+import qualified Upgrade.V1
+#endif
+import qualified Upgrade.V2
+import qualified Upgrade.V3
+import qualified Upgrade.V4
+import qualified Upgrade.V5
+import qualified Upgrade.V6
+import qualified Upgrade.V7
+import qualified Upgrade.V8
+import qualified Upgrade.V9
+
+import qualified Data.Map as M
+import Data.Time.Clock.POSIX
+
+checkUpgrade :: RepoVersion -> Annex ()
+checkUpgrade = maybe noop giveup <=< needsUpgrade
+
+needsUpgrade :: RepoVersion -> Annex (Maybe String)
+needsUpgrade v
+	| v `elem` supportedVersions = case M.lookup v autoUpgradeableVersions of
+		Just newv | newv /= v -> ifM (annexAutoUpgradeRepository <$> Annex.getGitConfig)
+			( runupgrade newv
+			, ok
+			)
+		_ -> ok
+	| otherwise = case M.lookup v autoUpgradeableVersions of
+		Nothing
+			| v `elem` upgradeableVersions ->
+				err "Upgrade this repository: git-annex upgrade"
+			| otherwise ->
+				err "Upgrade git-annex."
+		Just newv -> ifM (annexAutoUpgradeRepository <$> Annex.getGitConfig)
+			( runupgrade newv
+			, err "Automatic upgrade is disabled by annex.autoupgraderepository configuration. To upgrade this repository: git-annex upgrade"
+			)
+  where
+	err msg = do
+		g <- Annex.gitRepo
+		p <- liftIO $ absPath $ Git.repoPath g
+		return $ Just $ unwords
+			[ "Repository", fromRawFilePath p
+			, "is at"
+			, if v `elem` supportedVersions 
+				then "supported"
+				else "unsupported"
+			, "version"
+			, show (fromRepoVersion v) ++ "."
+			, msg
+			]
+	
+	ok = return Nothing
+
+	runupgrade newv = tryNonAsync (upgrade True newv) >>= \case
+		Right True -> ok
+		Right False -> err "Automatic upgrade failed!"
+		Left ex -> err $ "Automatic upgrade exception! " ++ show ex
+
+upgrade :: Bool -> RepoVersion -> Annex Bool
+upgrade automatic destversion = go =<< getVersion
+  where
+	go (Just v)
+		| v >= destversion = return True
+		| otherwise = ifM upgradingRemote
+			( upgraderemote
+			, up v >>= \case
+				UpgradeSuccess -> do
+					let v' = incrversion v
+					upgradedto v'
+					go (Just v')
+				UpgradeFailed -> return False
+				UpgradeDeferred -> return True
+			)
+	go Nothing = return True
+
+	incrversion v = RepoVersion (fromRepoVersion v + 1)
+
+#ifndef mingw32_HOST_OS
+	up (RepoVersion 0) = Upgrade.V0.upgrade
+	up (RepoVersion 1) = Upgrade.V1.upgrade
+#else
+	up (RepoVersion 0) = giveup "upgrade from v0 on Windows not supported"
+	up (RepoVersion 1) = giveup "upgrade from v1 on Windows not supported"
+#endif
+	up (RepoVersion 2) = Upgrade.V2.upgrade
+	up (RepoVersion 3) = Upgrade.V3.upgrade automatic
+	up (RepoVersion 4) = Upgrade.V4.upgrade automatic
+	up (RepoVersion 5) = Upgrade.V5.upgrade automatic
+	up (RepoVersion 6) = Upgrade.V6.upgrade automatic
+	up (RepoVersion 7) = Upgrade.V7.upgrade automatic
+	up (RepoVersion 8) = Upgrade.V8.upgrade automatic
+	up (RepoVersion 9) = Upgrade.V9.upgrade automatic
+	up _ = return UpgradeDeferred
+
+	-- Upgrade local remotes by running git-annex upgrade in them.
+	-- This avoids complicating the upgrade code by needing to handle
+	-- upgrading a git repo other than the current repo.
+	upgraderemote = do
+		rp <- fromRawFilePath <$> fromRepo Git.repoPath
+		ok <- gitAnnexChildProcess "upgrade"
+			[ Param "--quiet"
+			, Param "--autoonly"
+			]
+			(\p -> p { cwd = Just rp })
+			(\_ _ _ pid -> waitForProcess pid >>= return . \case
+				ExitSuccess -> True
+				_ -> False
+			)
+		when ok
+			reloadConfig
+		return ok
+
+	upgradedto v = do
+		setVersion v
+		writeUpgradeLog v =<< liftIO getPOSIXTime
+
+upgradingRemote :: Annex Bool
+upgradingRemote = isJust <$> fromRepo Git.remoteName
diff --git a/Upgrade/V0.hs b/Upgrade/V0.hs
new file mode 100644
index 0000000000..7880b481e7
--- /dev/null
+++ b/Upgrade/V0.hs
@@ -0,0 +1,58 @@
+{- git-annex v0 -> v1 upgrade support
+ -
+ - Copyright 2010 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Upgrade.V0 where
+
+import Annex.Common
+import Types.Upgrade
+import Annex.Content
+import qualified Upgrade.V1
+import qualified Utility.RawFilePath as R
+
+import System.PosixCompat.Files (isRegularFile)
+
+upgrade :: Annex UpgradeResult
+upgrade = do
+	showAction "v0 to v1"
+
+	-- do the reorganisation of the key files
+	olddir <- fromRawFilePath <$> fromRepo gitAnnexDir
+	keys <- getKeysPresent0 olddir
+	forM_ keys $ \k ->
+		moveAnnex k (AssociatedFile Nothing)
+			(toRawFilePath $ olddir </> keyFile0 k)
+
+	-- update the symlinks to the key files
+	-- No longer needed here; V1.upgrade does the same thing
+
+	-- Few people had v0 repos, so go the long way around from 0 -> 1 -> 2
+	Upgrade.V1.upgrade
+
+-- these stayed unchanged between v0 and v1
+keyFile0 :: Key -> FilePath
+keyFile0 = Upgrade.V1.keyFile1
+fileKey0 :: FilePath -> Key
+fileKey0 = Upgrade.V1.fileKey1
+lookupKey0 :: FilePath -> Annex (Maybe (Key, Backend))
+lookupKey0 = Upgrade.V1.lookupKey1
+
+getKeysPresent0 :: FilePath -> Annex [Key]
+getKeysPresent0 dir = ifM (liftIO $ doesDirectoryExist dir)
+	( liftIO $ map fileKey0
+		<$> (filterM present =<< getDirectoryContents dir)
+	, return []
+	)
+  where
+	present d = do
+		result <- tryIO $
+			R.getFileStatus $ toRawFilePath $
+				dir ++ "/" ++ takeFileName d
+		case result of
+			Right s -> return $ isRegularFile s
+			Left _ -> return False
diff --git a/Upgrade/V1.hs b/Upgrade/V1.hs
new file mode 100644
index 0000000000..0c5666c2ae
--- /dev/null
+++ b/Upgrade/V1.hs
@@ -0,0 +1,260 @@
+{- git-annex v1 -> v2 upgrade support
+ -
+ - Copyright 2011 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Upgrade.V1 where
+
+import System.Posix.Types
+import Data.Char
+import Data.Default
+import Data.ByteString.Builder
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Short as S (toShort, fromShort)
+import qualified Data.ByteString.Lazy as L
+import qualified System.FilePath.ByteString as P
+import System.PosixCompat.Files (isRegularFile)
+
+import Annex.Common
+import Types.Upgrade
+import Annex.Content
+import Annex.Link
+import Annex.Perms
+import Types.Key
+import Logs.Presence
+import qualified Annex.Queue
+import qualified Git
+import qualified Git.LsFiles as LsFiles
+import Backend
+import Utility.FileMode
+import Utility.Tmp
+import qualified Upgrade.V2
+import qualified Utility.RawFilePath as R
+
+-- v2 adds hashing of filenames of content and location log files.
+-- Key information is encoded in filenames differently, so
+-- both content and location log files move around, and symlinks
+-- to content need to be changed.
+-- 
+-- When upgrading a v1 key to v2, file size metadata ought to be
+-- added to the key (unless it is a WORM key, which encoded
+-- mtime:size in v1). This can only be done when the file content
+-- is present. Since upgrades need to happen consistently, 
+-- (so that two repos get changed the same way by the upgrade, and
+-- will merge), that metadata cannot be added on upgrade.
+--
+-- Note that file size metadata
+-- will only be used for detecting situations where git-annex
+-- would run out of disk space, so if some keys don't have it,
+-- the impact is minor. At least initially. It could be used in the
+-- future by smart auto-repo balancing code, etc.
+--
+-- Anyway, since v2 plans ahead for other metadata being included
+-- in keys, there should probably be a way to update a key.
+-- Something similar to the migrate subcommand could be used,
+-- and users could then run that at their leisure.
+
+upgrade :: Annex UpgradeResult
+upgrade = do
+	showAction "v1 to v2"
+	
+	ifM (fromRepo Git.repoIsLocalBare)
+		( moveContent
+		, do
+			moveContent
+			updateSymlinks
+			moveLocationLogs
+	
+			Annex.Queue.flush
+		)
+	
+	Upgrade.V2.upgrade
+
+moveContent :: Annex ()
+moveContent = do
+	showAction "moving content"
+	files <- getKeyFilesPresent1
+	forM_ files move
+  where
+	move f = do
+		let f' = toRawFilePath f
+		let k = fileKey1 (fromRawFilePath (P.takeFileName f'))
+		let d = parentDir f'
+		liftIO $ allowWrite d
+		liftIO $ allowWrite f'
+		_ <- moveAnnex k (AssociatedFile Nothing) f'
+		liftIO $ removeDirectory (fromRawFilePath d)
+
+updateSymlinks :: Annex ()
+updateSymlinks = do
+	showAction "updating symlinks"
+	top <- fromRepo Git.repoPath
+	(files, cleanup) <- inRepo $ LsFiles.inRepo [] [top]
+	forM_ files (fixlink . fromRawFilePath)
+	void $ liftIO cleanup
+  where
+	fixlink f = do
+		r <- lookupKey1 f
+		case r of
+			Nothing -> noop
+			Just (k, _) -> do
+				link <- fromRawFilePath
+					<$> calcRepo (gitAnnexLink (toRawFilePath f) k)
+				liftIO $ removeFile f
+				liftIO $ R.createSymbolicLink (toRawFilePath link) (toRawFilePath f)
+				Annex.Queue.addCommand [] "add" [Param "--"] [f]
+
+moveLocationLogs :: Annex ()
+moveLocationLogs = do
+	showAction "moving location logs"
+	logkeys <- oldlocationlogs
+	forM_ logkeys move
+  where
+	oldlocationlogs = do
+		dir <- fromRepo Upgrade.V2.gitStateDir
+		ifM (liftIO $ doesDirectoryExist dir)
+			( mapMaybe oldlog2key
+				<$> liftIO (getDirectoryContents dir)
+			, return []
+			)
+	move (l, k) = do
+		dest <- fromRepo (logFile2 k)
+		dir <- fromRepo Upgrade.V2.gitStateDir
+		let f = dir </> l
+		createWorkTreeDirectory (parentDir (toRawFilePath dest))
+		-- could just git mv, but this way deals with
+		-- log files that are not checked into git,
+		-- as well as merging with already upgraded
+		-- logs that have been pulled from elsewhere
+		old <- liftIO $ readLog1 f
+		new <- liftIO $ readLog1 dest
+		liftIO $ writeLog1 dest (old++new)
+		Annex.Queue.addCommand [] "add" [Param "--"] [dest]
+		Annex.Queue.addCommand [] "add" [Param "--"] [f]
+		Annex.Queue.addCommand [] "rm" [Param "--quiet", Param "-f", Param "--"] [f]
+
+oldlog2key :: FilePath -> Maybe (FilePath, Key)
+oldlog2key l
+	| drop len l == ".log" && sane = Just (l, k)
+	| otherwise = Nothing
+  where
+	len = length l - 4
+	k = readKey1 (take len l)
+	sane = (not . S.null $ S.fromShort $ fromKey keyName k) && (not . S.null $ formatKeyVariety $ fromKey keyVariety k)
+
+-- WORM backend keys: "WORM:mtime:size:filename"
+-- all the rest: "backend:key"
+--
+-- If the file looks like "WORM:XXX-...", then it was created by mixing
+-- v2 and v1; that infelicity is worked around by treating the value
+-- as the v2 key that it is.
+readKey1 :: String -> Key
+readKey1 v
+	| mixup = fromJust $ deserializeKey $ intercalate ":" $ Prelude.tail bits
+	| otherwise = mkKey $ \d -> d
+		{ keyName = S.toShort (encodeBS n)
+		, keyVariety = parseKeyVariety (encodeBS b)
+		, keySize = s
+		, keyMtime = t
+		}
+  where
+	bits = splitc ':' v
+	b = Prelude.head bits
+	n = intercalate ":" $ drop (if wormy then 3 else 1) bits
+	t = if wormy
+		then Just (Prelude.read (bits !! 1) :: EpochTime)
+		else Nothing
+	s = if wormy
+		then Just (Prelude.read (bits !! 2) :: Integer)
+		else Nothing
+	wormy = Prelude.head bits == "WORM"
+	mixup = wormy && isUpper (Prelude.head $ bits !! 1)
+
+showKey1 :: Key -> String
+showKey1 k = intercalate ":" $ filter (not . null)
+	[b, showifhere t, showifhere s, decodeBS n]
+  where
+	showifhere Nothing = ""
+	showifhere (Just x) = show x
+	b = decodeBS $ formatKeyVariety v
+	n = S.fromShort $ fromKey keyName k
+	v = fromKey keyVariety k
+	s = fromKey keySize k
+	t = fromKey keyMtime k
+
+keyFile1 :: Key -> FilePath
+keyFile1 key = replace "/" "%" $ replace "%" "&s" $ replace "&" "&a"  $ showKey1 key
+
+fileKey1 :: FilePath -> Key
+fileKey1 file = readKey1 $
+	replace "&a" "&" $ replace "&s" "%" $ replace "%" "/" file
+
+writeLog1 :: FilePath -> [LogLine] -> IO ()
+writeLog1 file ls = viaTmp L.writeFile file (toLazyByteString $ buildLog ls)
+
+readLog1 :: FilePath -> IO [LogLine]
+readLog1 file = catchDefaultIO [] $
+	parseLog . encodeBL <$> readFileStrict file
+
+lookupKey1 :: FilePath -> Annex (Maybe (Key, Backend))
+lookupKey1 file = do
+	tl <- liftIO $ tryIO getsymlink
+	case tl of
+		Left _ -> return Nothing
+		Right l -> makekey l
+  where
+	getsymlink = takeFileName . fromRawFilePath
+		<$> R.readSymbolicLink (toRawFilePath file)
+	makekey l = maybeLookupBackendVariety (fromKey keyVariety k) >>= \case
+		Nothing -> do
+			unless (null kname || null bname ||
+			        not (isLinkToAnnex (toRawFilePath l))) $
+				warning (UnquotedString skip)
+			return Nothing
+		Just backend -> return $ Just (k, backend)
+	  where
+		k = fileKey1 l
+		bname = decodeBS (formatKeyVariety (fromKey keyVariety k))
+		kname = decodeBS (S.fromShort (fromKey keyName k))
+		skip = "skipping " ++ file ++ 
+			" (unknown backend " ++ bname ++ ")"
+
+getKeyFilesPresent1 :: Annex [FilePath]
+getKeyFilesPresent1  = getKeyFilesPresent1' . fromRawFilePath
+	=<< fromRepo gitAnnexObjectDir
+getKeyFilesPresent1' :: FilePath -> Annex [FilePath]
+getKeyFilesPresent1' dir =
+	ifM (liftIO $ doesDirectoryExist dir)
+		(  do
+			dirs <- liftIO $ getDirectoryContents dir
+			let files = map (\d -> dir ++ "/" ++ d ++ "/" ++ takeFileName d) dirs
+			liftIO $ filterM present files
+		, return []
+		)
+  where
+	present f = do
+		result <- tryIO $ R.getFileStatus (toRawFilePath f)
+		case result of
+			Right s -> return $ isRegularFile s
+			Left _ -> return False
+
+logFile1 :: Git.Repo -> Key -> String
+logFile1 repo key = Upgrade.V2.gitStateDir repo ++ keyFile1 key ++ ".log"
+
+logFile2 :: Key -> Git.Repo -> String
+logFile2 = logFile' (hashDirLower def)
+
+logFile' :: (Key -> RawFilePath) -> Key -> Git.Repo -> String
+logFile' hasher key repo =
+	gitStateDir repo ++ fromRawFilePath (hasher key) ++ fromRawFilePath (keyFile key) ++ ".log"
+
+stateDir :: FilePath
+stateDir = addTrailingPathSeparator ".git-annex"
+
+gitStateDir :: Git.Repo -> FilePath
+gitStateDir repo = addTrailingPathSeparator $
+	fromRawFilePath (Git.repoPath repo) </> stateDir
diff --git a/Upgrade/V2.hs b/Upgrade/V2.hs
new file mode 100644
index 0000000000..f467fa2596
--- /dev/null
+++ b/Upgrade/V2.hs
@@ -0,0 +1,150 @@
+{- git-annex v2 -> v3 upgrade support
+ -
+ - Copyright 2011 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Upgrade.V2 where
+
+import Annex.Common
+import Types.Upgrade
+import qualified Git
+import qualified Git.Command
+import qualified Git.Ref
+import qualified Annex.Branch
+import qualified Annex
+import Annex.Content
+import Utility.Tmp
+import Logs
+import Messages.Progress
+
+olddir :: Git.Repo -> FilePath
+olddir g
+	| Git.repoIsLocalBare g = ""
+	| otherwise = ".git-annex"
+
+{- .git-annex/ moved to a git-annex branch.
+ - 
+ - Strategy:
+ - 
+ - * Create the git-annex branch.
+ - * Find each location log file in .git-annex/, and inject its content
+ -   into the git-annex branch, unioning with any content already in
+ -   there. (in passing, this deals with the semi transition that left
+ -   some location logs hashed two different ways; both are found and
+ -   merged).
+ - * Also inject remote.log, trust.log, and uuid.log.
+ - * git rm -rf .git-annex
+ - * Remove stuff that used to be needed in .gitattributes.
+ - * Commit changes.
+ -}
+upgrade :: Annex UpgradeResult
+upgrade = do
+	showAction "v2 to v3"
+	bare <- fromRepo Git.repoIsLocalBare
+	old <- fromRepo olddir
+
+	Annex.Branch.create
+	showProgressDots
+
+	e <- liftIO $ doesDirectoryExist old
+	when e $ do
+		config <- Annex.getGitConfig
+		mapM_ (\(k, f) -> inject f $ fromRawFilePath $ locationLogFile config k) =<< locationLogs
+		mapM_ (\f -> inject f f) =<< logFiles old
+
+	saveState False
+	showProgressDots
+
+	when e $ do
+		inRepo $ Git.Command.run [Param "rm", Param "-r", Param "-f", Param "-q", File old]
+		unless bare $ inRepo gitAttributesUnWrite
+	showProgressDots
+
+	unless bare push
+
+	return UpgradeSuccess
+
+locationLogs :: Annex [(Key, FilePath)]
+locationLogs = do
+	config <- Annex.getGitConfig
+	dir <- fromRepo gitStateDir
+	liftIO $ do
+		levela <- dirContents dir
+		levelb <- mapM tryDirContents levela
+		files <- mapM tryDirContents (concat levelb)
+		return $ mapMaybe (islogfile config) (concat files)
+  where
+	tryDirContents d = catchDefaultIO [] $ dirContents d
+	islogfile config f = maybe Nothing (\k -> Just (k, f)) $
+			locationLogFileKey config (toRawFilePath f)
+
+inject :: FilePath -> FilePath -> Annex ()
+inject source dest = do
+	old <- fromRepo olddir
+	new <- liftIO (readFile $ old </> source)
+	Annex.Branch.change (Annex.Branch.RegardingUUID []) (toRawFilePath dest) $ \prev -> 
+		encodeBL $ unlines $ nub $ lines (decodeBL prev) ++ lines new
+
+logFiles :: FilePath -> Annex [FilePath]
+logFiles dir = return . filter (".log" `isSuffixOf`)
+		<=< liftIO $ getDirectoryContents dir
+
+push :: Annex ()
+push = do
+	origin_master <- inRepo $ Git.Ref.exists $ 
+		Git.Ref $ encodeBS "origin/master"
+	origin_gitannex <- Annex.Branch.hasOrigin
+	case (origin_master, origin_gitannex) of
+		(_, True) -> do
+			-- Merge in the origin's git-annex branch,
+			-- so that pushing the git-annex branch
+			-- will immediately work. Not pushed here,
+			-- because it's less obnoxious to let the user
+			-- push.
+			void Annex.Branch.update
+		(True, False) -> do
+			-- push git-annex to origin, so that
+			-- "git push" will from then on
+			-- automatically push it
+			void Annex.Branch.update -- just in case
+			showAction "pushing new git-annex branch to origin"
+			showOutput
+			inRepo $ Git.Command.run
+				[ Param "push"
+				, Param "origin"
+				, Param $ Git.fromRef Annex.Branch.name
+				]
+		_ -> do
+			-- no origin exists, so just let the user
+			-- know about the new branch
+			void Annex.Branch.update
+			showLongNote $ UnquotedString $
+				"git-annex branch created\n" ++
+				"Be sure to push this branch when pushing to remotes.\n"
+
+{- Old .gitattributes contents, not needed anymore. -}
+attrLines :: [String]
+attrLines =
+	[ stateDir </> "*.log merge=union"
+	, stateDir </> "*/*/*.log merge=union"
+	]
+
+gitAttributesUnWrite :: Git.Repo -> IO ()
+gitAttributesUnWrite repo = do
+	let attributes = fromRawFilePath (Git.attributes repo)
+	whenM (doesFileExist attributes) $ do
+		c <- readFileStrict attributes
+		liftIO $ viaTmp writeFile attributes $ unlines $
+			filter (`notElem` attrLines) $ lines c
+		Git.Command.run [Param "add", File attributes] repo
+
+stateDir :: FilePath
+stateDir = addTrailingPathSeparator ".git-annex"
+
+gitStateDir :: Git.Repo -> FilePath
+gitStateDir repo = addTrailingPathSeparator $
+	fromRawFilePath (Git.repoPath repo) </> stateDir
diff --git a/Upgrade/V3.hs b/Upgrade/V3.hs
new file mode 100644
index 0000000000..c623538e2d
--- /dev/null
+++ b/Upgrade/V3.hs
@@ -0,0 +1,12 @@
+{- git-annex v3 -> v4 uppgrade support
+ -
+ - There was no explicit v3 to v4 upgrade, so run v5 upgrade code.
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Upgrade.V3 (upgrade) where
+
+import Upgrade.V4 (upgrade)
diff --git a/Upgrade/V4.hs b/Upgrade/V4.hs
new file mode 100644
index 0000000000..feeadefe1e
--- /dev/null
+++ b/Upgrade/V4.hs
@@ -0,0 +1,16 @@
+{- git-annex v4 -> v5 uppgrade support
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Upgrade.V4 where
+
+import Annex.Common
+import Types.Upgrade
+
+{- Was only used for direct mode upgrade. v4 to v5 indirect update is a no-op,
+ - and direct mode is no longer supported, so nothing needs to be done. -}
+upgrade :: Bool -> Annex UpgradeResult
+upgrade _automatic = return UpgradeSuccess
diff --git a/Upgrade/V5.hs b/Upgrade/V5.hs
new file mode 100644
index 0000000000..d580befe05
--- /dev/null
+++ b/Upgrade/V5.hs
@@ -0,0 +1,170 @@
+{- git-annex v5 -> v6 upgrade support
+ -
+ - Copyright 2015-2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Upgrade.V5 where
+
+import Annex.Common
+import Types.Upgrade
+import Config
+import Config.Smudge
+import Annex.InodeSentinal
+import Annex.Link
+import Annex.CatFile
+import Annex.WorkTree
+import Annex.UUID
+import Logs.Location
+import qualified Upgrade.V5.Direct as Direct
+import qualified Annex.Content as Content
+import qualified Database.Keys
+import qualified Git
+import qualified Git.LsFiles
+import qualified Git.Branch
+import qualified Git.Version
+import Git.FilePath
+import Git.FileMode
+import Git.Config
+import Git.Ref
+import Utility.InodeCache
+import Utility.DottedVersion
+import Annex.AdjustedBranch
+import qualified Utility.RawFilePath as R
+
+import qualified Data.ByteString as S
+
+upgrade :: Bool -> Annex UpgradeResult
+upgrade automatic = flip catchNonAsync onexception $ do
+	unless automatic $
+		showAction "v5 to v6"
+	ifM isDirect
+		( do
+			checkGitVersionForDirectUpgrade
+			convertDirect
+		, do
+			checkGitVersionForIndirectUpgrade
+		)
+	scanAnnexedFiles
+	configureSmudgeFilter
+	-- Inode sentinal file was only used in direct mode and when
+	-- locking down files as they were added. In v6, it's used more
+	-- extensively, so make sure it exists, since old repos that didn't
+	-- use direct mode may not have created it.
+	unlessM isDirect $
+		createInodeSentinalFile True
+	return UpgradeSuccess
+  where
+	onexception e = do
+		warning $ UnquotedString $ "caught exception: " ++ show e
+		return UpgradeFailed
+
+-- git before 2.22 would OOM running git status on a large file.
+--
+-- Older versions of git that are patched (with
+-- commit 02156ab031e430bc45ce6984dfc712de9962dec8)
+-- can include "oomfix" in their version to indicate it.
+gitWillOOM :: Annex Bool
+gitWillOOM = liftIO $ do
+	v <- Git.Version.installed
+	return $ v < Git.Version.normalize "2.22" &&
+		not ("oomfix" `isInfixOf` fromDottedVersion v)
+
+-- configureSmudgeFilter has to run git status, and direct mode files
+-- are unlocked, so avoid the upgrade failing half way through.
+checkGitVersionForDirectUpgrade :: Annex ()
+checkGitVersionForDirectUpgrade = whenM gitWillOOM $
+	giveup "You must upgrade git to version 2.22 or newer in order to use this version of git-annex in this repository."
+
+checkGitVersionForIndirectUpgrade :: Annex ()
+checkGitVersionForIndirectUpgrade = whenM gitWillOOM $
+	warning "Git is older than version 2.22 and so it has a memory leak that affects using unlocked files. Recommend you upgrade git before unlocking any files in your repository."
+
+convertDirect :: Annex ()
+convertDirect = do
+	{- Direct mode makes the same tradeoff of using less disk
+	 - space, with less preservation of old versions of files
+	 - as does annex.thin. -}
+	setConfig (annexConfig "thin") (boolConfig True)
+	Direct.setIndirect
+	cur <- inRepo Git.Branch.current >>= \case
+		Just cur -> return cur
+		Nothing -> do
+			-- Avoid running pre-commit hook.
+			commitForAdjustedBranch [Param "--no-verify"]
+			fromMaybe (giveup "Nothing is committed, and a commit failed; unable to proceed.") 
+				<$> inRepo Git.Branch.current
+	upgradeDirectWorkTree
+	removeDirectCruft
+	{- Create adjusted branch where all files are unlocked.
+	 - This should have the same content for each file as
+	 - have been staged in upgradeDirectWorkTree. -}
+	AdjBranch b <- adjustBranch (LinkAdjustment UnlockAdjustment) cur
+	{- Since the work tree was already set up by
+	 - upgradeDirectWorkTree, and contains unlocked file
+	 - contents too, don't use git checkout to check out the
+	 - adjust branch. Instead, update HEAD manually. -}
+	inRepo $ setHeadRef b
+
+{- Walk work tree from top and convert all annex symlinks to pointer files,
+ - staging them in the index, and populating the annex objects with
+ - hard links (or copies) of the work tree files (when not modified or
+ - deleted).
+ -}
+upgradeDirectWorkTree :: Annex ()
+upgradeDirectWorkTree = do
+	top <- fromRepo Git.repoPath
+	(l, clean) <- inRepo $ Git.LsFiles.inRepoDetails [] [top]
+	forM_ l go
+	void $ liftIO clean
+  where
+	go (f, _sha, mode) | isSymLink mode = do
+		-- Cannot use lookupKey here, as we're in between direct
+		-- mode and v6.
+		mk <- catKeyFile f
+		case mk of
+			Nothing -> noop
+			Just k -> do
+				stagePointerFile f Nothing =<< hashPointerFile k
+				ifM (isJust <$> getAnnexLinkTarget f)
+					( writepointer (fromRawFilePath f) k
+					, fromdirect (fromRawFilePath f) k
+					)
+				Database.Keys.addAssociatedFile k
+					=<< inRepo (toTopFilePath f)
+	go _ = noop
+
+	fromdirect f k = ifM (Direct.goodContent k f)
+		( do
+			let f' = toRawFilePath f
+			-- If linkToAnnex fails for some reason, the work tree
+			-- file still has the content; the annex object file
+			-- is just not populated with it. Since the work tree
+			-- file is recorded as an associated file, things will
+			-- still work that way, it's just not ideal.
+			ic <- withTSDelta (liftIO . genInodeCache f')
+			void $ Content.linkToAnnex k f' ic
+		, unlessM (Content.inAnnex k) $ do
+			-- Worktree file was deleted or modified;
+			-- if there are no other copies of the content
+			-- then it's been lost.
+			locs <- Direct.associatedFiles k
+			unlessM (anyM (Direct.goodContent k) locs) $ do
+				u <- getUUID
+				logChange k u InfoMissing
+		)
+	
+	writepointer f k = liftIO $ do
+		removeWhenExistsWith R.removeLink (toRawFilePath f)
+		S.writeFile f (formatPointer k)
+
+{- Remove all direct mode bookkeeping files. -}
+removeDirectCruft :: Annex ()
+removeDirectCruft = mapM_ go =<< Content.listKeys Content.InAnywhere
+  where
+	go k = do
+		Direct.removeInodeCache k
+		Direct.removeAssociatedFiles k
diff --git a/Upgrade/V5/Direct.hs b/Upgrade/V5/Direct.hs
new file mode 100644
index 0000000000..c807b29d9e
--- /dev/null
+++ b/Upgrade/V5/Direct.hs
@@ -0,0 +1,144 @@
+{- git-annex direct mode
+ -
+ - This only contains some remnants needed to convert away from direct mode.
+ -
+ - Copyright 2012-2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Upgrade.V5.Direct (
+	switchHEADBack,
+	setIndirect,
+	goodContent,
+	associatedFiles,
+	removeAssociatedFiles,
+	removeInodeCache,
+) where
+
+import Annex.Common
+import qualified Git
+import qualified Git.Config
+import qualified Git.Ref
+import qualified Git.Branch
+import Git.Types
+import Config
+import Annex.Perms
+import Utility.InodeCache
+import Annex.InodeSentinal
+import qualified Utility.RawFilePath as R
+
+setIndirect :: Annex ()
+setIndirect = do
+	setbare
+	switchHEADBack
+	setConfig (annexConfig "direct") val
+  where
+	val = Git.Config.boolConfig False
+	coreworktree = ConfigKey "core.worktree"
+	indirectworktree = ConfigKey "core.indirect-worktree"
+	setbare = do
+		-- core.worktree is not compatible with
+		-- core.bare; git does not allow both to be set, so
+		-- unset it when enabling direct mode, caching in
+		-- core.indirect-worktree
+		moveconfig indirectworktree coreworktree
+		setConfig Git.Config.coreBare val
+	moveconfig src dest = getConfigMaybe src >>= \case
+		Nothing -> noop
+		Just wt -> do
+			unsetConfig src
+			setConfig dest (fromConfigValue wt)
+			reloadConfig
+
+{- Converts a directBranch back to the original branch.
+ -
+ - Any other ref is left unchanged.
+ -}
+fromDirectBranch :: Ref -> Ref
+fromDirectBranch directhead = case splitc '/' $ fromRef directhead of
+	("refs":"heads":"annex":"direct":rest) -> 
+		Ref $ encodeBS $ "refs/heads/" ++ intercalate "/" rest
+	_ -> directhead
+
+switchHEADBack :: Annex ()
+switchHEADBack = maybe noop switch =<< inRepo Git.Branch.currentUnsafe
+  where
+	switch currhead = do
+		let orighead = fromDirectBranch currhead
+		inRepo (Git.Ref.sha currhead) >>= \case
+			Just headsha
+				| orighead == currhead -> noop
+				| otherwise -> do
+					inRepo $ Git.Branch.update "leaving direct mode" orighead headsha
+					inRepo $ Git.Branch.checkout orighead
+					inRepo $ Git.Branch.delete currhead
+			Nothing -> inRepo $ Git.Branch.checkout orighead
+
+{- Absolute FilePaths of Files in the tree that are associated with a key. -}
+associatedFiles :: Key -> Annex [FilePath]
+associatedFiles key = do
+	files <- associatedFilesRelative key
+	top <- fromRawFilePath <$> fromRepo Git.repoPath
+	return $ map (top </>) files
+
+{- List of files in the tree that are associated with a key, relative to
+ - the top of the repo. -}
+associatedFilesRelative :: Key -> Annex [FilePath] 
+associatedFilesRelative key = do
+	mapping <- fromRawFilePath <$> calcRepo (gitAnnexMapping key)
+	liftIO $ catchDefaultIO [] $ withFile mapping ReadMode $ \h ->
+		-- Read strictly to ensure the file is closed promptly
+		lines <$> hGetContentsStrict h
+
+{- Removes the list of associated files. -}
+removeAssociatedFiles :: Key -> Annex ()
+removeAssociatedFiles key = do
+	mapping <- calcRepo $ gitAnnexMapping key
+	modifyContentDir mapping $
+		liftIO $ removeWhenExistsWith R.removeLink mapping
+
+{- Checks if a file in the tree, associated with a key, has not been modified.
+ -
+ - To avoid needing to fsck the file's content, which can involve an
+ - expensive checksum, this relies on a cache that contains the file's
+ - expected mtime and inode.
+ -}
+goodContent :: Key -> FilePath -> Annex Bool
+goodContent key file =
+	sameInodeCache (toRawFilePath file)
+		=<< recordedInodeCache key
+
+{- Gets the recorded inode cache for a key. 
+ -
+ - A key can be associated with multiple files, so may return more than
+ - one. -}
+recordedInodeCache :: Key -> Annex [InodeCache]
+recordedInodeCache key = withInodeCacheFile key $ \f ->
+	liftIO $ catchDefaultIO [] $
+		mapMaybe readInodeCache . lines
+			<$> readFileStrict (fromRawFilePath f)
+
+{- Removes an inode cache. -}
+removeInodeCache :: Key -> Annex ()
+removeInodeCache key = withInodeCacheFile key $ \f ->
+	modifyContentDir f $
+		liftIO $ removeWhenExistsWith R.removeLink f
+
+withInodeCacheFile :: Key -> (RawFilePath -> Annex a) -> Annex a
+withInodeCacheFile key a = a =<< calcRepo (gitAnnexInodeCache key)
+
+{- File that maps from a key to the file(s) in the git repository. -}
+gitAnnexMapping :: Key -> Git.Repo -> GitConfig -> IO RawFilePath
+gitAnnexMapping key r c = do
+	loc <- gitAnnexLocation key r c
+	return $ loc <> ".map"
+
+{- File that caches information about a key's content, used to determine
+ - if a file has changed. -}
+gitAnnexInodeCache :: Key -> Git.Repo -> GitConfig -> IO RawFilePath
+gitAnnexInodeCache key r c = do
+	loc <- gitAnnexLocation key r c
+	return $ loc <> ".cache"
diff --git a/Upgrade/V6.hs b/Upgrade/V6.hs
new file mode 100644
index 0000000000..1dce107905
--- /dev/null
+++ b/Upgrade/V6.hs
@@ -0,0 +1,24 @@
+{- git-annex v6 -> v7 upgrade support
+ -
+ - Copyright 2018 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Upgrade.V6 where
+
+import Annex.Common
+import Types.Upgrade
+import Config
+import Annex.Hook
+
+upgrade :: Bool -> Annex UpgradeResult
+upgrade automatic = do
+	unless automatic $
+		showAction "v6 to v7"
+	unlessM isBareRepo $ do
+		hookWrite postCheckoutHook
+		hookWrite postMergeHook
+	return UpgradeSuccess
diff --git a/Upgrade/V7.hs b/Upgrade/V7.hs
new file mode 100644
index 0000000000..cad16f1854
--- /dev/null
+++ b/Upgrade/V7.hs
@@ -0,0 +1,139 @@
+{- git-annex v7 -> v8 upgrade support
+ -
+ - Copyright 2019 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE CPP #-}
+
+module Upgrade.V7 where
+
+import qualified Annex
+import Annex.Common
+import Types.Upgrade
+import Annex.CatFile
+import qualified Database.Keys
+import qualified Database.Keys.SQL
+import Database.Keys.Tables
+import qualified Git.LsFiles as LsFiles
+import qualified Git
+import Git.FilePath
+import Config
+import qualified Utility.RawFilePath as R
+
+import qualified System.FilePath.ByteString as P
+import System.PosixCompat.Files (isSymbolicLink)
+
+upgrade :: Bool -> Annex UpgradeResult
+upgrade automatic = do
+	unless automatic $
+		showAction "v7 to v8"
+
+	-- The fsck databases are not transitioned here; any running
+	-- incremental fsck can continue to write to the old database.
+	-- The next time an incremental fsck is started, it will delete the
+	-- old database, and just re-fsck the files.
+	
+	-- The old content identifier database is deleted here, but the
+	-- new database is not populated. It will be automatically
+	-- populated from the git-annex branch the next time it is used.
+	removeOldDb . fromRawFilePath =<< fromRepo gitAnnexContentIdentifierDbDirOld
+	liftIO . removeWhenExistsWith R.removeLink
+		=<< fromRepo gitAnnexContentIdentifierLockOld
+
+	-- The export databases are deleted here. The new databases
+	-- will be populated by the next thing that needs them, the same
+	-- way as they would be in a fresh clone.
+	removeOldDb . fromRawFilePath =<< calcRepo' gitAnnexExportDir
+
+	populateKeysDb
+	removeOldDb . fromRawFilePath =<< fromRepo gitAnnexKeysDbOld
+	liftIO . removeWhenExistsWith R.removeLink
+		=<< fromRepo gitAnnexKeysDbIndexCacheOld
+	liftIO . removeWhenExistsWith R.removeLink
+		=<< fromRepo gitAnnexKeysDbLockOld
+	
+	updateSmudgeFilter
+
+	return UpgradeSuccess
+
+gitAnnexKeysDbOld :: Git.Repo -> RawFilePath
+gitAnnexKeysDbOld r = gitAnnexDir r P.</> "keys"
+
+gitAnnexKeysDbLockOld :: Git.Repo -> RawFilePath
+gitAnnexKeysDbLockOld r = gitAnnexKeysDbOld r <> ".lck"
+
+gitAnnexKeysDbIndexCacheOld :: Git.Repo -> RawFilePath
+gitAnnexKeysDbIndexCacheOld r = gitAnnexKeysDbOld r <> ".cache"
+
+gitAnnexContentIdentifierDbDirOld :: Git.Repo -> RawFilePath
+gitAnnexContentIdentifierDbDirOld r = gitAnnexDir r P.</> "cids"
+
+gitAnnexContentIdentifierLockOld :: Git.Repo -> RawFilePath
+gitAnnexContentIdentifierLockOld r = gitAnnexContentIdentifierDbDirOld r <> ".lck"
+
+removeOldDb :: FilePath -> Annex ()
+removeOldDb db =
+	whenM (liftIO $ doesDirectoryExist db) $ do
+		v <- liftIO $ tryNonAsync $
+			removePathForcibly db
+		case v of
+			Left ex -> giveup $ "Failed removing old database directory " ++ db ++ " during upgrade (" ++ show ex ++ ") -- delete that and re-run git-annex to finish the upgrade."
+			Right () -> return ()
+
+-- Populate the new keys database with associated files and inode caches.
+--
+-- The information is queried from git. The index contains inode cache
+-- information for all staged files, so that is used.
+--
+-- Note that typically the inode cache of annex objects is also stored in
+-- the keys database. This does not add it though, because it's possible
+-- that any annex object has gotten modified. The most likely way would be
+-- due to annex.thin having been set at some point in the past, bypassing
+-- the usual safeguards against object modification. When a worktree file
+-- is still a hardlink to an annex object, then they have the same inode
+-- cache, so using the inode cache from the git index will get the right
+-- thing added in that case. But there are cases where the annex object's
+-- inode cache is not added here, most notably when it's not unlocked. 
+-- The result will be more work needing to be done by isUnmodified and
+-- by inAnnex (the latter only when annex.thin is set) to verify the
+-- annex object. That work is only done once, and then the object will
+-- finally get its inode cached.
+populateKeysDb :: Annex ()
+populateKeysDb = unlessM isBareRepo $ do
+	top <- fromRepo Git.repoPath
+	(l, cleanup) <- inRepo $ LsFiles.inodeCaches [top]
+	forM_ l $ \case
+		(_f, Nothing) -> giveup "Unable to parse git ls-files --debug output while upgrading git-annex sqlite databases."
+		(f, Just ic) -> unlessM (liftIO $ catchBoolIO $ isSymbolicLink <$> R.getSymbolicLinkStatus (toRawFilePath f)) $ do
+			catKeyFile (toRawFilePath f) >>= \case
+				Nothing -> noop
+				Just k -> do
+					topf <- inRepo $ toTopFilePath $ toRawFilePath f
+					Database.Keys.runWriter AssociatedTable $ \h -> liftIO $
+						Database.Keys.SQL.addAssociatedFile k topf h
+					Database.Keys.runWriter ContentTable $ \h -> liftIO $
+						Database.Keys.SQL.addInodeCaches k [ic] h
+	liftIO $ void cleanup
+	Database.Keys.closeDb
+
+-- The gitatrributes used to have a line that prevented filtering dotfiles,
+-- but now they are filtered and annex.dotfiles controls whether they get
+-- added to the annex.
+--
+-- Only done on local gitattributes, not any gitatrributes that might be
+-- checked into the repository.
+updateSmudgeFilter :: Annex ()
+updateSmudgeFilter = do
+	lf <- fromRawFilePath <$> Annex.fromRepo Git.attributesLocal
+	ls <- liftIO $ lines <$> catchDefaultIO "" (readFileStrict lf)
+	let ls' = removedotfilter ls
+	when (ls /= ls') $
+		liftIO $ writeFile lf (unlines ls')
+  where
+	removedotfilter ("* filter=annex":".* !filter":rest) =
+		"* filter=annex" : removedotfilter rest
+	removedotfilter (l:ls) = l : removedotfilter ls
+	removedotfilter [] = []
diff --git a/Upgrade/V8.hs b/Upgrade/V8.hs
new file mode 100644
index 0000000000..ec462bebd8
--- /dev/null
+++ b/Upgrade/V8.hs
@@ -0,0 +1,23 @@
+{- git-annex v8 -> v9 upgrade support
+ -
+ - Copyright 2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Upgrade.V8 where
+
+import Annex.Common
+import Types.Upgrade
+import Config.Smudge
+
+upgrade :: Bool -> Annex UpgradeResult
+upgrade automatic = do
+	unless automatic $
+		showAction "v8 to v9"
+
+	configureSmudgeFilterProcess
+
+	return UpgradeSuccess
diff --git a/Upgrade/V9.hs b/Upgrade/V9.hs
new file mode 100644
index 0000000000..700f1f6387
--- /dev/null
+++ b/Upgrade/V9.hs
@@ -0,0 +1,107 @@
+{- git-annex v9 -> v10 upgrade support
+ -
+ - Copyright 2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Upgrade.V9 where
+
+import Annex.Common
+import qualified Annex
+import Types.Upgrade
+import Annex.Content
+import Annex.Perms
+import Annex.LockFile
+import Annex.Version
+import Git.ConfigTypes
+import Types.RepoVersion
+import Logs.Upgrade
+import Utility.Daemon
+
+import Data.Time.Clock.POSIX
+
+upgrade :: Bool -> Annex UpgradeResult
+upgrade automatic
+	| automatic = ifM oldprocessesdanger
+		( return UpgradeDeferred
+		, performUpgrade automatic
+		)
+	| otherwise = ifM (oldprocessesdanger <&&> (not <$> Annex.getRead Annex.force))
+		( do
+			warning $ UnquotedString $ unlines unsafeupgrade
+			return UpgradeDeferred
+		, performUpgrade automatic
+		)
+  where
+	{- Wait until a year after the v9 upgrade, to give time for
+	 - any old processes that were running before the v9 upgrade
+	 - to finish. Such old processes lock content using the old method,
+	 - and it is not safe for such to still be running after
+	 - this upgrade. -}
+	oldprocessesdanger = timeOfUpgrade (RepoVersion 9) >>= \case
+		Just t -> do
+			now <- liftIO getPOSIXTime
+			if now < t + 365*24*60*60
+				then return True
+				else assistantrunning
+		-- Initialized at v9, so no old process danger exists.
+		Nothing -> pure False
+
+	{- Skip upgrade when git-annex assistant (or watch) is running,
+	 - because these are long-running daemons that could conceivably
+	 - run for an entire year and so predate the v9 upgrade. -}
+	assistantrunning = do
+		pidfile <- fromRepo gitAnnexPidFile
+		isJust <$> liftIO (checkDaemon (fromRawFilePath pidfile))
+	
+	unsafeupgrade =
+		[ "Not upgrading from v9 to v10, because there may be git-annex"
+		, "processes running that predate the v9 upgrade. Upgrading with"
+		, "such processes running could lead to data loss. This upgrade"
+		, "will be deferred until one year after the v9 upgrade to make"
+		, "sure there are no such old processes running."
+		, "(Use --force to upgrade immediately.)"
+		]
+
+performUpgrade :: Bool -> Annex UpgradeResult
+performUpgrade automatic = do
+	unless automatic $
+		showAction "v9 to v10"
+	
+	{- Take a lock to ensure that there are no other git-annex
+	 - processes running that are using the old content locking method. -}
+	lck <- fromRepo gitAnnexContentLockLock
+	withExclusiveLock lck $ do
+		{- When core.sharedRepository is set, object files
+		 - used to have their write bits set. That can now be
+		 - removed, if the user the upgrade is running as has
+		 - permission to remove it.
+		 - (Otherwise, a later fsck will fix up the permissions.) -}
+		withShared $ \sr -> case sr of
+			GroupShared -> removewrite sr
+			AllShared -> removewrite sr
+			_ -> return ()
+
+		{- Set the new version while still holding the lock,
+		 - so that any other process waiting for the lock will
+		 - be able to detect that the upgrade happened. -}
+		setVersion newver
+
+		return UpgradeSuccess
+  where
+	newver = RepoVersion 10
+
+	removewrite sr = do
+		ks <- listKeys InAnnex
+		forM_ ks $ \k -> do
+			obj <- calcRepo (gitAnnexLocation k)
+			keystatus <- getKeyStatus k
+			case keystatus of
+				KeyPresent -> void $ tryIO $
+					freezeContent'' sr obj (Just newver)
+				KeyUnlockedThin -> return ()
+				KeyLockedThin -> return ()
+				KeyMissing -> return ()
diff --git a/Utility/Aeson.hs b/Utility/Aeson.hs
new file mode 100644
index 0000000000..0eacbf0daa
--- /dev/null
+++ b/Utility/Aeson.hs
@@ -0,0 +1,126 @@
+{- GHC File system encoding support for Aeson.
+ -
+ - Import instead of Data.Aeson
+ -
+ - Copyright 2018-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE FlexibleInstances, TypeSynonymInstances, CPP #-}
+
+module Utility.Aeson (
+	module X,
+	ToJSON'(..),
+	encode,
+	packString,
+	packByteString,
+	textKey,
+) where
+
+#if MIN_VERSION_aeson(2,0,0)
+import Data.Aeson as X hiding (ToJSON, toJSON, encode, Key)
+#else
+import Data.Aeson as X hiding (ToJSON, toJSON, encode)
+#endif
+import Data.Aeson hiding (encode)
+import qualified Data.Aeson
+#if MIN_VERSION_aeson(2,0,0)
+import qualified Data.Aeson.Key as AK
+#endif
+import qualified Data.Text as T
+import qualified Data.Text.Encoding as T
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString as S
+import qualified Data.Set
+import qualified Data.Map
+import qualified Data.Vector
+import Prelude
+
+import Utility.FileSystemEncoding
+
+-- | Use this instead of Data.Aeson.encode to make sure that the
+-- below String instance is used.
+encode :: ToJSON' a => a -> L.ByteString
+encode = Data.Aeson.encode . toJSON'
+
+-- | Aeson has an unfortunate ToJSON instance for Char and [Char]
+-- which does not support Strings containing UTF8 characters
+-- encoded using the filesystem encoding when run in a non-utf8 locale.
+--
+-- Since we can't replace that with a instance that does the right
+-- thing, instead here's a new class that handles String right.
+class ToJSON' a where
+	toJSON' :: a -> Value
+
+instance ToJSON' T.Text where
+	toJSON' = toJSON
+
+instance ToJSON' String where
+	toJSON' = toJSON . packString
+
+-- | Aeson does not have a ToJSON instance for ByteString;
+-- this one assumes that the ByteString contains text, and will
+-- have the same effect as toJSON' . decodeBS, but with a more efficient
+-- implementation.
+instance ToJSON' S.ByteString where
+	toJSON' = toJSON . packByteString
+
+-- | Pack a String to Text, correctly handling the filesystem encoding.
+--
+-- Use this instead of Data.Text.pack.
+--
+-- Note that if the string contains invalid UTF8 characters not using
+-- the FileSystemEncoding, this is the same as Data.Text.pack.
+packString :: String -> T.Text
+packString s = case T.decodeUtf8' (encodeBS s) of
+	Right t -> t
+	Left _ -> T.pack s
+
+#if MIN_VERSION_aeson(2,0,0)
+textKey :: T.Text -> AK.Key
+textKey = AK.fromText
+#else
+textKey :: T.Text -> T.Text
+textKey = id
+#endif
+
+-- | The same as packString . decodeBS, but more efficient in the usual
+-- case.
+packByteString :: S.ByteString -> T.Text
+packByteString b = case T.decodeUtf8' b of
+	Right t -> t
+	Left _ -> T.pack (decodeBS b)
+
+-- | An instance for lists cannot be included as it would overlap with
+-- the String instance. Instead, you can use a Vector.
+instance ToJSON' s => ToJSON' (Data.Vector.Vector s) where
+	toJSON' = toJSON . map toJSON' . Data.Vector.toList
+
+-- Aeson generates the same JSON for a Set as for a list.
+instance ToJSON' s => ToJSON' (Data.Set.Set s) where
+	toJSON' = toJSON . map toJSON' . Data.Set.toList
+
+instance (ToJSON' v) => ToJSON' (Data.Map.Map T.Text v) where
+	toJSON' m = object $ map go (Data.Map.toList m)
+	  where
+		go (k, v) = (textKey k, toJSON' v)
+
+instance (ToJSON' a, ToJSON a) => ToJSON' (Maybe a) where
+	toJSON' (Just a) = toJSON (Just (toJSON' a))
+	toJSON' v@Nothing = toJSON v
+
+instance (ToJSON' a, ToJSON a, ToJSON' b, ToJSON b) => ToJSON' (a, b) where
+	toJSON' (a, b) = toJSON ((toJSON' a, toJSON' b))
+
+instance ToJSON' Bool where
+	toJSON' = toJSON
+
+instance ToJSON' Integer where
+	toJSON' = toJSON
+
+instance ToJSON' Object where
+	toJSON' = toJSON
+
+instance ToJSON' Value where
+	toJSON' = toJSON
diff --git a/Utility/Android.hs b/Utility/Android.hs
new file mode 100644
index 0000000000..10ec35d37d
--- /dev/null
+++ b/Utility/Android.hs
@@ -0,0 +1,28 @@
+{-# LANGUAGE CPP #-}
+
+{- Android stuff
+ -
+ - Copyright 2018 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.Android (
+	osAndroid
+) where
+
+#ifdef linux_HOST_OS
+import Common
+#endif
+
+-- Detect when the Linux build is running on Android, eg in termux.
+--
+-- Note that this relies on termux's uname having been built with "Android"
+-- as the os name. Often on Android, uname will report "Linux".
+osAndroid :: IO Bool
+#ifdef linux_HOST_OS
+osAndroid = catchDefaultIO False $
+	("Android" `isPrefixOf` ) <$> readProcess "uname" ["-o"]
+#else
+osAndroid = return False
+#endif
diff --git a/Utility/Applicative.hs b/Utility/Applicative.hs
new file mode 100644
index 0000000000..fcd693264d
--- /dev/null
+++ b/Utility/Applicative.hs
@@ -0,0 +1,20 @@
+{- applicative stuff
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Applicative (
+	(<$$>),
+) where
+
+{- Like <$> , but supports one level of currying.
+ - 
+ - foo v = bar <$> action v  ==  foo = bar <$$> action
+ -}
+(<$$>) :: Functor f => (a -> b) -> (c -> f a) -> c -> f b
+f <$$> v = fmap f . v
+infixr 4 <$$>
diff --git a/Utility/Attoparsec.hs b/Utility/Attoparsec.hs
new file mode 100644
index 0000000000..bd20e8e6d9
--- /dev/null
+++ b/Utility/Attoparsec.hs
@@ -0,0 +1,21 @@
+{- attoparsec utility functions
+ -
+ - Copyright 2019 Joey Hess <id@joeyh.name>
+ - Copyright 2007-2015 Bryan O'Sullivan
+ -
+ - License: BSD-3-clause
+ -}
+
+module Utility.Attoparsec where
+
+import qualified Data.Attoparsec.ByteString as A
+import qualified Data.ByteString as B
+
+-- | Parse and decode an unsigned octal number.
+--
+-- This parser does not accept a leading @\"0o\"@ string.
+octal :: Integral a => A.Parser a
+octal = B.foldl' step 0 `fmap` A.takeWhile1 isOctDigit
+  where
+	isOctDigit w = w >= 48 && w <= 55
+	step a w = a * 8 + fromIntegral (w - 48)
diff --git a/Utility/AuthToken.hs b/Utility/AuthToken.hs
new file mode 100644
index 0000000000..116e361bbe
--- /dev/null
+++ b/Utility/AuthToken.hs
@@ -0,0 +1,102 @@
+{- authentication tokens
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE PackageImports #-}
+
+module Utility.AuthToken (
+	AuthToken,
+	toAuthToken,
+	fromAuthToken,
+	nullAuthToken,
+	genAuthToken,
+	AllowedAuthTokens,
+	allowedAuthTokens,
+	isAllowedAuthToken,
+) where
+
+import qualified Utility.SimpleProtocol as Proto
+import Utility.Hash
+import Utility.Exception
+
+import Data.SecureMem
+import Data.Maybe
+import Data.Char
+import Data.Byteable
+import qualified Data.Text as T
+import qualified Data.Text.Encoding as TE
+import qualified Data.ByteString.Lazy as L
+import "crypto-api" Crypto.Random
+
+-- | An AuthToken is stored in secure memory, with constant time comparison.
+--
+-- It can have varying length, depending on the security needs of the
+-- application.
+--
+-- To avoid decoding issues, and presentation issues, the content
+-- of an AuthToken is limited to ASCII characters a-z, and 0-9.
+-- This is enforced by all exported AuthToken constructors.
+newtype AuthToken = AuthToken SecureMem
+	deriving (Show, Eq)
+
+allowedChar :: Char -> Bool
+allowedChar c = isAsciiUpper c || isAsciiLower c || isDigit c
+
+instance Proto.Serializable AuthToken where
+	serialize = T.unpack . fromAuthToken
+	deserialize = toAuthToken . T.pack
+
+fromAuthToken :: AuthToken -> T.Text
+fromAuthToken (AuthToken t ) = TE.decodeLatin1 (toBytes t)
+
+-- | Upper-case characters are lower-cased to make them fit in the allowed
+-- character set. This allows AuthTokens to be compared effectively
+-- case-insensitively. 
+--
+-- Returns Nothing if any disallowed characters are present.
+toAuthToken :: T.Text -> Maybe AuthToken
+toAuthToken t
+	| all allowedChar s = Just $ AuthToken $ 
+		secureMemFromByteString $ TE.encodeUtf8 $ T.pack s
+	| otherwise = Nothing
+  where
+	s = map toLower $ T.unpack t
+
+-- | The empty AuthToken, for those times when you don't want any security.
+nullAuthToken :: AuthToken
+nullAuthToken = AuthToken $ secureMemFromByteString $ TE.encodeUtf8 T.empty
+
+-- | Generates an AuthToken of a specified length. This is done by
+-- generating a random bytestring, hashing it with sha2 512, and truncating
+-- to the specified length.
+--
+-- That limits the maximum length to 128, but with 512 bytes of entropy,
+-- that should be sufficient for any application.
+genAuthToken :: Int -> IO AuthToken
+genAuthToken len = do
+	g <- newGenIO :: IO SystemRandom
+	return $
+		case genBytes 512 g of
+			Left e -> giveup $ "failed to generate auth token: " ++ show e
+			Right (s, _) -> fromMaybe (giveup "auth token encoding failed") $
+				toAuthToken $ T.pack $ take len $
+					show $ sha2_512 $ L.fromChunks [s]
+
+-- | For when several AuthTokens are allowed to be used.
+newtype AllowedAuthTokens = AllowedAuthTokens [AuthToken]
+
+allowedAuthTokens :: [AuthToken] -> AllowedAuthTokens
+allowedAuthTokens = AllowedAuthTokens
+
+-- | Note that every item in the list is checked, even if the first one
+-- is allowed, so that comparison is constant-time.
+isAllowedAuthToken :: AuthToken -> AllowedAuthTokens -> Bool
+isAllowedAuthToken t (AllowedAuthTokens l) = go False l
+  where
+	go ok [] = ok
+	go ok (i:is)
+		| t == i = go True is
+		| otherwise = go ok is
diff --git a/Utility/Base64.hs b/Utility/Base64.hs
new file mode 100644
index 0000000000..e2d90d6dac
--- /dev/null
+++ b/Utility/Base64.hs
@@ -0,0 +1,25 @@
+{- Simple Base64 encoding
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.Base64 where
+
+import Utility.Exception
+
+import Codec.Binary.Base64 as B64
+import Data.Maybe
+import qualified Data.ByteString as B
+
+toB64 :: B.ByteString -> B.ByteString
+toB64 = B64.encode
+
+fromB64Maybe :: B.ByteString -> Maybe (B.ByteString)
+fromB64Maybe = either (const Nothing) Just . B64.decode
+
+fromB64 :: B.ByteString -> B.ByteString
+fromB64 = fromMaybe bad . fromB64Maybe
+  where
+	bad = giveup "bad base64 encoded data"
diff --git a/Utility/Batch.hs b/Utility/Batch.hs
new file mode 100644
index 0000000000..6ed7881a17
--- /dev/null
+++ b/Utility/Batch.hs
@@ -0,0 +1,87 @@
+{- Running a long or expensive batch operation niced.
+ -
+ - Copyright 2013-2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.Batch (
+	batch,
+	BatchCommandMaker,
+	nonBatchCommandMaker,
+	getBatchCommandMaker,
+	toBatchCommand,
+	batchCommand,
+	batchCommandEnv,
+) where
+
+import Common
+
+#if defined(linux_HOST_OS)
+import Control.Concurrent.Async
+import System.Posix.Process
+#endif
+
+{- Runs an operation, at batch priority.
+ -
+ - This is done by running it in a bound thread, which on Linux can be set
+ - to have a different nice level than the rest of the program. Note that
+ - due to running in a bound thread, some operations may be more expensive
+ - to perform. Also note that if the action calls forkIO or forkOS itself,
+ - that will make a new thread that does not have the batch priority.
+ -
+ - POSIX threads do not support separate nice levels, so on other operating
+ - systems, the action is simply ran.
+ -}
+batch :: IO a -> IO a
+#if defined(linux_HOST_OS)
+batch a = wait =<< batchthread
+  where
+	batchthread = asyncBound $ do
+		setProcessPriority 0 maxNice
+		a
+	maxNice = 19
+#else
+batch a = a
+#endif
+
+{- Makes a command be run by whichever of nice, ionice, and nocache
+ - are available in the path. -}
+type BatchCommandMaker = (String, [CommandParam]) -> (String, [CommandParam])
+
+nonBatchCommandMaker :: BatchCommandMaker
+nonBatchCommandMaker = id
+
+getBatchCommandMaker :: IO BatchCommandMaker
+getBatchCommandMaker = do
+#ifndef mingw32_HOST_OS
+	nicers <- filterM (inSearchPath . fst)
+		[ ("nice", [])
+		, ("ionice", ["-c3"])
+		, ("nocache", [])
+		]
+	return $ \(command, params) ->
+		case nicers of
+			[] -> (command, params)
+			(first:rest) -> (fst first, map Param (snd first ++ concatMap (\p -> fst p : snd p) rest ++ [command]) ++ params)
+#else
+	return id
+#endif
+
+toBatchCommand :: (String, [CommandParam]) -> IO (String, [CommandParam])
+toBatchCommand v = do
+	batchmaker <- getBatchCommandMaker
+	return $ batchmaker v
+
+{- Runs a command in a way that's suitable for batch jobs that can be
+ - interrupted. -}
+batchCommand :: String -> [CommandParam] -> IO Bool
+batchCommand command params = batchCommandEnv command params Nothing
+
+batchCommandEnv :: String -> [CommandParam] -> Maybe [(String, String)] -> IO Bool
+batchCommandEnv command params environ = do
+	batchmaker <- getBatchCommandMaker
+	let (command', params') = batchmaker (command, params)
+	boolSystemEnv command' params' environ
diff --git a/Utility/Bloom.hs b/Utility/Bloom.hs
new file mode 100644
index 0000000000..e8afb2c1bd
--- /dev/null
+++ b/Utility/Bloom.hs
@@ -0,0 +1,40 @@
+{- bloomfilter compatibility wrapper
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.Bloom (
+	Bloom,
+	safeSuggestSizing,
+	Hashable(..),
+	cheapHashes,
+	elemB,
+	notElemB,
+
+	newMB,
+	insertMB,
+	unsafeFreezeMB,
+) where
+
+import qualified Data.BloomFilter.Mutable as MBloom
+import qualified Data.BloomFilter as Bloom
+import Data.BloomFilter.Easy (safeSuggestSizing, Bloom)
+import Data.BloomFilter.Hash (Hashable(..), cheapHashes)
+import Control.Monad.ST (ST)
+
+notElemB :: a -> Bloom a -> Bool
+notElemB = Bloom.notElem
+
+elemB :: a -> Bloom a -> Bool
+elemB = Bloom.elem
+
+newMB :: (a -> [Bloom.Hash]) -> Int -> ST s (MBloom.MBloom s a)
+newMB = MBloom.new
+
+insertMB :: MBloom.MBloom s a -> a -> ST s ()
+insertMB = MBloom.insert
+
+unsafeFreezeMB :: MBloom.MBloom s a -> ST s (Bloom a)
+unsafeFreezeMB = Bloom.unsafeFreeze
diff --git a/Utility/CoProcess.hs b/Utility/CoProcess.hs
new file mode 100644
index 0000000000..d9b8f31fbd
--- /dev/null
+++ b/Utility/CoProcess.hs
@@ -0,0 +1,103 @@
+{- Interface for running a shell command as a coprocess,
+ - sending it queries and getting back results.
+ -
+ - Copyright 2012-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.CoProcess (
+	CoProcessHandle,
+	CoProcessState(..),
+	start,
+	stop,
+	query,
+	send,
+	receive,
+) where
+
+import Common
+
+import Control.Concurrent.MVar
+import Control.Monad.IO.Class (MonadIO)
+
+type CoProcessHandle = MVar CoProcessState
+
+data CoProcessState = CoProcessState
+	{ coProcessPid :: ProcessHandle
+	, coProcessTo :: Handle
+	, coProcessFrom :: Handle
+	, coProcessSpec :: CoProcessSpec
+	}
+
+data CoProcessSpec = CoProcessSpec
+	{ coProcessNumRestarts :: Int
+	, coProcessCmd :: FilePath
+	, coProcessParams :: [String]
+	, coProcessEnv :: Maybe [(String, String)]
+	}
+
+start :: Int -> FilePath -> [String] -> Maybe [(String, String)] -> IO CoProcessHandle
+start numrestarts cmd params environ = do
+	s <- start' $ CoProcessSpec numrestarts cmd params environ
+	newMVar s
+
+start' :: CoProcessSpec -> IO CoProcessState
+start' s = do
+	(pid, from, to) <- startInteractiveProcess (coProcessCmd s) (coProcessParams s) (coProcessEnv s)
+	rawMode from
+	rawMode to
+	return $ CoProcessState pid to from s
+  where
+#ifdef mingw32_HOST_OS
+	rawMode h = hSetNewlineMode h noNewlineTranslation
+#else
+	rawMode _ = return ()
+#endif
+
+stop :: CoProcessHandle -> IO ()
+stop ch = do
+	s <- readMVar ch
+	hClose $ coProcessTo s
+	hClose $ coProcessFrom s
+	let p = proc (coProcessCmd $ coProcessSpec s) (coProcessParams $ coProcessSpec s)
+	forceSuccessProcess p (coProcessPid s)
+
+{- To handle a restartable process, any IO exception thrown by the send and
+ - receive actions are assumed to mean communication with the process
+ - failed, and the failed action is re-run with a new process. -}
+query :: (MonadIO m, MonadCatch m) => CoProcessHandle -> (Handle -> m a) -> (Handle -> m b) -> m b
+query ch sender receiver = do
+	s <- liftIO $ readMVar ch
+	restartable s (sender $ coProcessTo s) $ const $
+		restartable s (liftIO $ hFlush $ coProcessTo s) $ const $
+			restartable s (receiver $ coProcessFrom s)
+				return
+  where
+	restartable s a cont
+		| coProcessNumRestarts (coProcessSpec s) > 0 =
+			maybe restart cont =<< catchMaybeIO a
+		| otherwise = cont =<< a
+	restart = do
+		s <- liftIO $ takeMVar ch
+		void $ liftIO $ catchMaybeIO $ do
+			hClose $ coProcessTo s
+			hClose $ coProcessFrom s
+		void $ liftIO $ waitForProcess $ coProcessPid s
+		s' <- liftIO $ start' $ (coProcessSpec s)
+			{ coProcessNumRestarts = coProcessNumRestarts (coProcessSpec s) - 1 }
+		liftIO $ putMVar ch s'
+		query ch sender receiver
+
+send :: MonadIO m => CoProcessHandle -> (Handle -> m a) -> m a
+send ch a = do
+	s <- liftIO $ readMVar ch
+	a (coProcessTo s)
+
+receive :: MonadIO m => CoProcessHandle -> (Handle -> m a) -> m a
+receive ch a = do
+	s <- liftIO $ readMVar ch
+	liftIO $ hFlush $ coProcessTo s
+	a (coProcessFrom s)
diff --git a/Utility/CopyFile.hs b/Utility/CopyFile.hs
new file mode 100644
index 0000000000..207153d1b6
--- /dev/null
+++ b/Utility/CopyFile.hs
@@ -0,0 +1,96 @@
+{- file copying
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.CopyFile (
+	copyFileExternal,
+	copyCoW,
+	createLinkOrCopy,
+	CopyMetaData(..)
+) where
+
+import Common
+import qualified BuildInfo
+import qualified Utility.RawFilePath as R
+
+data CopyMetaData 
+	-- Copy timestamps when possible, but no other metadata, and
+	-- when copying a symlink, makes a copy of its content.
+	= CopyTimeStamps
+	-- Copy all metadata when possible.
+	| CopyAllMetaData
+	deriving (Eq)
+
+copyMetaDataParams :: CopyMetaData -> [CommandParam]
+copyMetaDataParams meta = map snd $ filter fst
+	[ (allmeta && BuildInfo.cp_a, Param "-a")
+	, (allmeta && BuildInfo.cp_p && not BuildInfo.cp_a
+		, Param "-p")
+	, (not allmeta && BuildInfo.cp_preserve_timestamps
+		, Param "--preserve=timestamps")
+	-- cp -a may preserve xattrs that have special meaning,
+	-- eg to NFS, and have even been observed to prevent later
+	-- changing the permissions of the file. So prevent preserving
+	-- xattrs.
+	, (allmeta && BuildInfo.cp_a && BuildInfo.cp_no_preserve_xattr_supported
+		, Param "--no-preserve=xattr")
+	]
+  where
+	allmeta = meta == CopyAllMetaData
+
+{- The cp command is used, because I hate reinventing the wheel,
+ - and because this allows easy access to features like cp --reflink
+ - and preserving metadata. -}
+copyFileExternal :: CopyMetaData -> FilePath -> FilePath -> IO Bool
+copyFileExternal meta src dest = do
+	-- Delete any existing dest file because an unwritable file
+	-- would prevent cp from working.
+	void $ tryIO $ removeFile dest
+	boolSystem "cp" $ params ++ [File src, File dest]
+  where
+	params
+		| BuildInfo.cp_reflink_supported =
+			Param "--reflink=auto" : copyMetaDataParams meta
+		| otherwise = copyMetaDataParams meta
+
+{- When a filesystem supports CoW (and cp does), uses it to make
+ - an efficient copy of a file. Otherwise, returns False.
+ -
+ - The dest file must not exist yet, or it will fail to make a CoW copy,
+ - and will return False.
+ -}
+copyCoW :: CopyMetaData -> FilePath -> FilePath -> IO Bool
+copyCoW meta src dest
+	| BuildInfo.cp_reflink_supported = do
+		-- When CoW is not supported, cp will complain to stderr,
+		-- so have to discard its stderr.
+		ok <- catchBoolIO $ withNullHandle $ \nullh ->
+			let p = (proc "cp" $ toCommand $ params ++ [File src, File dest])
+				{ std_out = UseHandle nullh
+				, std_err = UseHandle nullh
+				}
+			in withCreateProcess p $ \_ _ _ -> checkSuccessProcess
+		-- When CoW is not supported, cp creates the destination
+		-- file but leaves it empty.
+		unless ok $
+			void $ tryIO $ removeFile dest
+		return ok
+	| otherwise = return False
+  where
+ 	-- Note that in coreutils 9.0, cp uses CoW by default,
+	-- without needing an option. This s only needed to support 
+	-- older versions.
+	params = Param "--reflink=always" : copyMetaDataParams meta
+
+{- Create a hard link if the filesystem allows it, and fall back to copying
+ - the file. -}
+createLinkOrCopy :: RawFilePath -> RawFilePath -> IO Bool
+createLinkOrCopy src dest = go `catchIO` const fallback
+  where
+	go = do
+		R.createLink src dest
+		return True
+	fallback = copyFileExternal CopyAllMetaData (fromRawFilePath src) (fromRawFilePath dest)
diff --git a/Utility/DBus.hs b/Utility/DBus.hs
new file mode 100644
index 0000000000..bcb093223d
--- /dev/null
+++ b/Utility/DBus.hs
@@ -0,0 +1,91 @@
+{- DBus utilities
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings, ScopedTypeVariables #-}
+
+module Utility.DBus (
+	ServiceName,
+	listServiceNames,
+	callDBus,
+	runClient,
+	persistentClient,
+) where
+
+import Utility.PartialPrelude
+import Utility.Exception
+
+import DBus.Client
+import DBus
+import Data.Maybe
+import Control.Concurrent
+import Control.Exception as E
+
+type ServiceName = String
+
+listServiceNames :: Client -> IO [ServiceName]
+listServiceNames client = do
+	reply <- callDBus client "ListNames" []
+	return $ fromMaybe [] $ fromVariant =<< headMaybe (methodReturnBody reply)
+
+callDBus :: Client -> MemberName -> [Variant] -> IO MethodReturn
+callDBus client name params = call_ client $
+	(methodCall "/org/freedesktop/DBus" "org.freedesktop.DBus" name)
+		{ methodCallDestination = Just "org.freedesktop.DBus"
+		, methodCallBody = params
+		}
+
+{- Connects to the bus, and runs the client action.
+ - 
+ - Throws a ClientError, and closes the connection if it fails to
+ - process an incoming message, or if the connection is lost.
+ - Unlike DBus's usual interface, this error is thrown at the top level,
+ - rather than inside the clientThreadRunner, so it can be caught, and
+ - runClient re-run as needed. -}
+runClient :: IO (Maybe Address) -> (Client -> IO ()) -> IO ()
+runClient getaddr clientaction = do
+	env <- getaddr
+	case env of
+		Nothing -> throwIO (clientError "runClient: unable to determine DBUS address")
+		Just addr -> do
+			{- The clientaction will set up listeners, which
+			 - run in a different thread. We block while
+			 - they're running, until our threadrunner catches
+			 - a ClientError, which it will put into the MVar
+			 - to be rethrown here. -}
+			mv <- newEmptyMVar
+			let tr = threadrunner (putMVar mv)
+			let opts = defaultClientOptions { clientThreadRunner = tr }
+			client <- connectWith opts addr
+			clientaction client
+			e <- takeMVar mv
+			disconnect client
+			throw e
+  where
+	threadrunner storeerr io = loop
+	  where
+		loop = catchClientError (io >> loop) storeerr
+
+{- Connects to the bus, and runs the client action.
+ -
+ - If the connection is lost, runs onretry, which can do something like
+ - a delay, or printing a warning, and has a state value (useful for
+ - exponential backoff). Once onretry returns, the connection is retried.
+ -}
+persistentClient :: IO (Maybe Address) -> v -> (SomeException -> v -> IO v) -> (Client -> IO ()) -> IO ()
+persistentClient getaddr v onretry clientaction =
+	{- runClient can fail with not just ClientError, but also other
+	 - things, if dbus is not running. Let async exceptions through. -}
+	runClient getaddr clientaction `catchNonAsync` retry
+  where
+	retry e = do
+		v' <- onretry e v
+		persistentClient getaddr v' onretry clientaction
+
+{- Catches only ClientError -}
+catchClientError :: IO () -> (ClientError -> IO ()) -> IO ()
+catchClientError io handler =
+	either handler return =<< (E.try io :: IO (Either ClientError ()))
diff --git a/Utility/Daemon.hs b/Utility/Daemon.hs
new file mode 100644
index 0000000000..c2a3d1bde7
--- /dev/null
+++ b/Utility/Daemon.hs
@@ -0,0 +1,194 @@
+{- daemon support
+ -
+ - Copyright 2012-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.Daemon (
+#ifndef mingw32_HOST_OS
+	daemonize,
+#endif
+	foreground,
+	checkDaemon,
+	stopDaemon,
+) where
+
+import Common
+import Utility.PID
+#ifndef mingw32_HOST_OS
+import Utility.LogFile
+import Utility.Env
+import Utility.OpenFd
+#else
+import System.Win32.Process (terminateProcessById)
+import Utility.LockFile
+#endif
+
+#ifndef mingw32_HOST_OS
+import System.Posix hiding (getEnv, getEnvironment)
+#endif
+
+#ifndef mingw32_HOST_OS
+{- Run an action as a daemon, with all output sent to a file descriptor,
+ - and in a new session.
+ -
+ - Can write its pid to a file.
+ -
+ - This does not double-fork to background, because forkProcess is
+ - rather fragile and highly unused in haskell programs, so likely to break.
+ - Instead, it runs the cmd with provided params, in the background,
+ - which the caller should arrange to run this again.
+ -}
+daemonize :: String -> [CommandParam] -> IO Fd -> Maybe FilePath -> Bool -> IO () -> IO ()
+daemonize cmd params openlogfd pidfile changedirectory a = do
+	maybe noop checkalreadyrunning pidfile
+	getEnv envvar >>= \case
+		Just s | s == cmd -> do
+			maybe noop lockPidFile pidfile 
+			a
+		_ -> do
+			nullfd <- openFdWithMode (toRawFilePath "/dev/null") ReadOnly Nothing defaultFileFlags
+			redir nullfd stdInput
+			redirLog =<< openlogfd
+			environ <- getEnvironment
+			_ <- createProcess $
+				(proc cmd (toCommand params))
+				{ env = Just (addEntry envvar cmd environ)
+				, create_group = True
+				, new_session = True
+				, cwd = if changedirectory then Just "/" else Nothing
+				}
+			return ()
+  where
+	checkalreadyrunning f = maybe noop (const alreadyRunning) 
+		=<< checkDaemon f
+	envvar = "DAEMONIZED"
+#endif
+
+{- To run an action that is normally daemonized in the foreground. -}
+#ifndef mingw32_HOST_OS
+foreground :: IO Fd -> Maybe FilePath -> IO () -> IO ()
+foreground openlogfd pidfile a = do
+#else
+foreground :: Maybe FilePath -> IO () -> IO ()
+foreground pidfile a = do
+#endif
+	maybe noop lockPidFile pidfile
+#ifndef mingw32_HOST_OS
+	_ <- tryIO createSession
+	redirLog =<< openlogfd
+#endif
+	a
+#ifndef mingw32_HOST_OS
+	exitImmediately ExitSuccess
+#else
+	exitWith ExitSuccess
+#endif
+
+{- Locks the pid file, with an exclusive, non-blocking lock,
+ - and leaves it locked on return.
+ -
+ - Writes the pid to the file, fully atomically.
+ - Fails if the pid file is already locked by another process. -}
+lockPidFile :: FilePath -> IO ()
+lockPidFile pidfile = do
+#ifndef mingw32_HOST_OS
+	fd <- openFdWithMode (toRawFilePath pidfile) ReadWrite (Just stdFileMode) defaultFileFlags
+	locked <- catchMaybeIO $ setLock fd (WriteLock, AbsoluteSeek, 0, 0)
+	fd' <- openFdWithMode (toRawFilePath newfile) ReadWrite (Just stdFileMode) defaultFileFlags
+		{ trunc = True }
+	locked' <- catchMaybeIO $ setLock fd' (WriteLock, AbsoluteSeek, 0, 0)
+	case (locked, locked') of
+		(Nothing, _) -> alreadyRunning
+		(_, Nothing) -> alreadyRunning
+		_ -> do
+			_ <- fdWrite fd' =<< show <$> getPID
+			closeFd fd
+	rename newfile pidfile
+  where
+	newfile = pidfile ++ ".new"
+#else
+	{- Not atomic on Windows, oh well. -}
+	unlessM (isNothing <$> checkDaemon pidfile)
+		alreadyRunning
+	pid <- getPID
+	writeFile pidfile (show pid)
+	lckfile <- winLockFile pid pidfile
+	writeFile (fromRawFilePath lckfile) ""
+	void $ lockExclusive lckfile
+#endif
+
+alreadyRunning :: IO ()
+alreadyRunning = giveup "Daemon is already running."
+
+{- Checks if the daemon is running, by checking that the pid file
+ - is locked by the same process that is listed in the pid file.
+ -
+ - If it's running, returns its pid. -}
+checkDaemon :: FilePath -> IO (Maybe PID)
+#ifndef mingw32_HOST_OS
+checkDaemon pidfile = bracket setup cleanup go
+  where
+	setup = catchMaybeIO $
+		openFdWithMode (toRawFilePath pidfile) ReadOnly (Just stdFileMode) defaultFileFlags
+	cleanup (Just fd) = closeFd fd
+	cleanup Nothing = return ()
+	go (Just fd) = catchDefaultIO Nothing $ do
+		locked <- getLock fd (ReadLock, AbsoluteSeek, 0, 0)
+		p <- readish <$> readFile pidfile
+		return (check locked p)
+	go Nothing = return Nothing
+
+	check Nothing _ = Nothing
+	check _ Nothing = Nothing
+	check (Just (pid, _)) (Just pid')
+		| pid == pid' = Just pid
+		| otherwise = giveup $
+			"stale pid in " ++ pidfile ++ 
+			" (got " ++ show pid' ++ 
+			"; expected " ++ show pid ++ " )"
+#else
+checkDaemon pidfile = maybe (return Nothing) (check . readish)
+	=<< catchMaybeIO (readFile pidfile)
+  where
+	check Nothing = return Nothing
+	check (Just pid) = do
+		v <- lockShared =<< winLockFile pid pidfile
+		case v of
+			Just h -> do
+				dropLock h
+				return Nothing
+			Nothing -> return (Just pid)
+#endif
+
+{- Stops the daemon, safely. -}
+stopDaemon :: FilePath -> IO ()
+stopDaemon pidfile = go =<< checkDaemon pidfile
+  where
+	go Nothing = noop
+	go (Just pid) =
+#ifndef mingw32_HOST_OS
+		signalProcess sigTERM pid
+#else
+		terminateProcessById pid
+#endif
+
+{- Windows locks a lock file that corresponds with the pid of the process.
+ - This allows changing the process in the pid file and taking a new lock
+ - when eg, restarting the daemon.
+ -}
+#ifdef mingw32_HOST_OS
+winLockFile :: PID -> FilePath -> IO RawFilePath
+winLockFile pid pidfile = do
+	cleanstale
+	return $ toRawFilePath $ prefix ++ show pid ++ suffix
+  where
+	prefix = pidfile ++ "."
+	suffix = ".lck"
+	cleanstale = mapM_ (void . tryIO . removeFile) =<<
+		(filter iswinlockfile <$> dirContents (fromRawFilePath (parentDir (toRawFilePath pidfile))))
+	iswinlockfile f = suffix `isSuffixOf` f && prefix `isPrefixOf` f
+#endif
diff --git a/Utility/Data.hs b/Utility/Data.hs
new file mode 100644
index 0000000000..af8c5580b5
--- /dev/null
+++ b/Utility/Data.hs
@@ -0,0 +1,22 @@
+{- utilities for simple data types
+ -
+ - Copyright 2013-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Data (
+	firstJust,
+	eitherToMaybe,
+) where
+
+{- First item in the list that is not Nothing. -}
+firstJust :: Eq a => [Maybe a] -> Maybe a
+firstJust ms = case dropWhile (== Nothing) ms of
+	[] -> Nothing
+	(md:_) -> md
+
+eitherToMaybe :: Either a b -> Maybe b
+eitherToMaybe = either (const Nothing) Just
diff --git a/Utility/DataUnits.hs b/Utility/DataUnits.hs
new file mode 100644
index 0000000000..3476ba8b3a
--- /dev/null
+++ b/Utility/DataUnits.hs
@@ -0,0 +1,197 @@
+{- data size display and parsing
+ -
+ - Copyright 2011-2022 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -
+ -
+ - And now a rant: 
+ -
+ - In the beginning, we had powers of two, and they were good.
+ -
+ - Disk drive manufacturers noticed that some powers of two were
+ - sorta close to some powers of ten, and that rounding down to the nearest
+ - power of ten allowed them to advertise their drives were bigger. This
+ - was sorta annoying.
+ -
+ - Then drives got big. Really, really big. This was good.
+ -
+ - Except that the small rounding error perpretrated by the drive
+ - manufacturers suffered the fate of a small error, and became a large
+ - error. This was bad.
+ -
+ - So, a committee was formed. And it arrived at a committee-like decision,
+ - which satisfied no one, confused everyone, and made the world an uglier
+ - place. As with all committees, this was meh. Or in this case, "mib".
+ -
+ - And the drive manufacturers happily continued selling drives that are
+ - increasingly smaller than you'd expect, if you don't count on your
+ - fingers. But that are increasingly too big for anyone to much notice.
+ - This caused me to need git-annex.
+ -
+ - Meanwhile, over in telecommunications land, they were using entirely
+ - different units that differ only in capitalization sometimes.
+ - (At one point this convinced me that it was a good idea to buy an ISDN
+ - line because 128 kb/s sounded really fast! But it was really only 128
+ - kbit/s...)
+ -
+ - Thus, I use units here that I loathe. Because if I didn't, people would
+ - be confused that their drives seem the wrong size, and other people would
+ - complain at me for not being standards compliant. And we call this
+ - progress?
+ -}
+
+module Utility.DataUnits (
+	dataUnits,
+	storageUnits,
+	committeeUnits,
+	bandwidthUnits,
+	oldSchoolUnits,
+	Unit(..),
+	ByteSize,
+
+	roughSize,
+	roughSize',
+	compareSizes,
+	readSize
+) where
+
+import Data.List
+import Data.Char
+import Data.Function
+
+import Author
+import Utility.HumanNumber
+
+copyright :: Copyright
+copyright = author JoeyHess (40*50+10)
+
+type ByteSize = Integer
+type Name = String
+type Abbrev = String
+data Unit = Unit ByteSize Abbrev Name
+	deriving (Ord, Show, Eq)
+
+dataUnits :: [Unit]
+dataUnits = storageUnits ++ committeeUnits ++ bandwidthUnits
+
+{- Storage units are (stupidly) powers of ten. -}
+storageUnits :: [Unit]
+storageUnits =
+	[ Unit (p 10) "QB" "quettabyte"
+	, Unit (p 9) "RB" "ronnabyte"
+	, Unit (p 8) "YB" "yottabyte"
+	, Unit (p 7) "ZB" "zettabyte"
+	, Unit (p 6) "EB" "exabyte"
+	, Unit (p 5) "PB" "petabyte"
+	, Unit (p 4) "TB" "terabyte"
+	, Unit (p 3) "GB" "gigabyte"
+	, Unit (p 2) "MB" "megabyte"
+	, Unit (p 1) "kB" "kilobyte" -- weird capitalization thanks to committee
+	, Unit 1 "B" "byte"
+	]
+  where
+	p :: Integer -> Integer
+	p n = 1000^n
+
+{- Committee units are (stupidly named) powers of 2. -}
+committeeUnits :: [Unit]
+committeeUnits =
+	[ Unit (p 8) "YiB" "yobibyte"
+	, Unit (p 7) "ZiB" "zebibyte"
+	, Unit (p 6) "EiB" "exbibyte"
+	, Unit (p 5) "PiB" "pebibyte"
+	, Unit (p 4) "TiB" "tebibyte"
+	, Unit (p 3) "GiB" "gibibyte"
+	, Unit (p 2) "MiB" "mebibyte"
+	, Unit (p 1) "KiB" "kibibyte"
+	, Unit 1 "B" "byte"
+	]
+  where
+	p :: Integer -> Integer
+	p n = 2^(n*10)
+
+{- Bandwidth units are (stupidly) measured in bits, not bytes, and are
+ - (also stupidly) powers of ten. 
+ -
+ - While it's fairly common for "Mb", "Gb" etc to be used, that differs
+ - from "MB", "GB", etc only in case, and readSize is case-insensitive.
+ - So "Mbit", "Gbit" etc are used instead to avoid parsing ambiguity.
+ -}
+bandwidthUnits :: [Unit]
+bandwidthUnits =
+	[ Unit (p 8) "Ybit" "yottabit"
+	, Unit (p 7) "Zbit" "zettabit"
+	, Unit (p 6) "Ebit" "exabit"
+	, Unit (p 5) "Pbit" "petabit"
+	, Unit (p 4) "Tbit" "terabit"
+	, Unit (p 3) "Gbit" "gigabit"
+	, Unit (p 2) "Mbit" "megabit"
+	, Unit (p 1) "kbit" "kilobit" -- weird capitalization thanks to committee
+	]
+  where
+	p :: Integer -> Integer
+	p n = (1000^n) `div` 8
+
+{- Do you yearn for the days when men were men and megabytes were megabytes? -}
+oldSchoolUnits :: [Unit]
+oldSchoolUnits = zipWith (curry mingle) storageUnits committeeUnits
+  where
+	mingle (Unit _ a n, Unit s' _ _) = Unit s' a n
+
+{- approximate display of a particular number of bytes -}
+roughSize :: [Unit] -> Bool -> ByteSize -> String
+roughSize units short i = copyright $ roughSize' units short 2 i
+
+roughSize' :: [Unit] -> Bool -> Int -> ByteSize -> String
+roughSize' units short precision i
+	| i < 0 = '-' : findUnit units' (negate i)
+	| otherwise = findUnit units' i
+  where
+	units' = sortBy (flip compare) units -- largest first
+
+	findUnit (u@(Unit s _ _):us) i'
+		| i' >= s = showUnit i' u
+		| otherwise = findUnit us i' & copyright
+	findUnit [] i' = showUnit i' (last units') -- bytes
+
+	showUnit x (Unit size abbrev name) = s ++ " " ++ unit
+	  where
+		v = (fromInteger x :: Double) / fromInteger size
+		s = showImprecise precision v
+		unit
+			| short = abbrev
+			| s == "1" = name
+			| otherwise = name ++ "s"
+
+{- displays comparison of two sizes -}
+compareSizes :: [Unit] -> Bool -> ByteSize -> ByteSize -> String
+compareSizes units abbrev old new
+	| old > new = roughSize units abbrev (old - new) ++ " smaller"
+	| old < new = roughSize units abbrev (new - old) ++ " larger"
+	| otherwise = "same"
+
+{- Parses strings like "10 kilobytes" or "0.5tb". -}
+readSize :: [Unit] -> String -> Maybe ByteSize
+readSize units input
+	| null parsednum || null parsedunit = Nothing
+	| otherwise = Just $ round $ number * fromIntegral multiplier
+  where
+	(number, rest) = head parsednum
+	multiplier = head parsedunit
+	unitname = takeWhile isAlpha $ dropWhile isSpace rest
+
+	parsednum = reads input :: [(Double, String)]
+	parsedunit = lookupUnit units unitname
+
+	lookupUnit _ [] = [1] -- no unit given, assume bytes
+	lookupUnit [] _ = []
+	lookupUnit (Unit s a n:us) v
+		| a ~~ v || n ~~ v = [s]
+		| plural n ~~ v || a ~~ byteabbrev v = [s]
+		| otherwise = lookupUnit us v
+		
+	a ~~ b = map toLower a == map toLower b
+		
+	plural n = n ++ "s"
+	byteabbrev a = a ++ "b"
diff --git a/Utility/Debug.hs b/Utility/Debug.hs
new file mode 100644
index 0000000000..6e6e701162
--- /dev/null
+++ b/Utility/Debug.hs
@@ -0,0 +1,102 @@
+{- Debug output
+ -
+ - Copyright 2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings, FlexibleInstances, TypeSynonymInstances #-}
+{-# LANGUAGE LambdaCase #-}
+{-# OPTIONS_GHC -fno-warn-tabs -w #-}
+
+module Utility.Debug (
+	DebugSource(..),
+	DebugSelector(..),
+	configureDebug,
+	getDebugSelector,
+	debug,
+	fastDebug
+) where
+
+import qualified Data.ByteString as S
+import Data.IORef
+import Data.String
+import Data.Time
+import System.IO.Unsafe (unsafePerformIO)
+import qualified Data.Semigroup as Sem
+import Prelude
+
+import Utility.FileSystemEncoding
+
+-- | The source of a debug message. For example, this could be a module or
+-- function name.
+newtype DebugSource = DebugSource S.ByteString
+	deriving (Eq, Show)
+
+instance IsString DebugSource where
+	fromString = DebugSource . encodeBS
+
+-- | Selects whether to display a message from a source.
+data DebugSelector 
+	= DebugSelector (DebugSource -> Bool)
+	| NoDebugSelector
+
+instance Sem.Semigroup DebugSelector where
+	DebugSelector a <> DebugSelector b = DebugSelector (\v -> a v || b v)
+	NoDebugSelector <> NoDebugSelector = NoDebugSelector
+	NoDebugSelector <> b = b
+	a <> NoDebugSelector = a
+
+instance Monoid DebugSelector where
+	mempty = NoDebugSelector
+
+-- | Configures debugging.
+configureDebug
+	:: (S.ByteString -> IO ())
+	-- ^ Used to display debug output.
+	-> DebugSelector
+	-> IO ()
+configureDebug src p = writeIORef debugConfigGlobal (src, p)
+
+-- | Gets the currently configured DebugSelector.
+getDebugSelector :: IO DebugSelector
+getDebugSelector = snd <$> readIORef debugConfigGlobal
+
+-- A global variable for the debug configuration.
+{-# NOINLINE debugConfigGlobal #-}
+debugConfigGlobal :: IORef (S.ByteString -> IO (), DebugSelector)
+debugConfigGlobal = unsafePerformIO $ newIORef (dontshow, selectnone)
+  where
+	dontshow _ = return ()
+	selectnone = NoDebugSelector
+
+-- | Displays a debug message, if that has been enabled by configureDebug.
+--
+-- This is reasonably fast when debugging is not enabled, but since it does
+-- have to consult a IORef each time, using it in a tight loop may slow
+-- down the program.
+debug :: DebugSource -> String -> IO ()
+debug src msg = readIORef debugConfigGlobal >>= \case
+	(displayer, NoDebugSelector) ->
+		displayer =<< formatDebugMessage src msg
+	(displayer, DebugSelector p)
+		| p src -> displayer =<< formatDebugMessage src msg
+		| otherwise -> return ()
+
+-- | Displays a debug message, if the DebugSelector allows.
+--
+-- When the DebugSelector does not let the message be displayed, this runs
+-- very quickly, allowing it to be used inside tight loops.
+fastDebug :: DebugSelector -> DebugSource -> String -> IO ()
+fastDebug NoDebugSelector src msg = do
+	(displayer, _) <- readIORef debugConfigGlobal
+	displayer =<< formatDebugMessage src msg
+fastDebug (DebugSelector p) src msg
+	| p src = fastDebug NoDebugSelector src msg
+	| otherwise = return ()
+
+formatDebugMessage :: DebugSource -> String -> IO S.ByteString
+formatDebugMessage (DebugSource src) msg = do
+	t <- encodeBS . formatTime defaultTimeLocale "[%F %X%Q]"
+		<$> getZonedTime
+	return (t <> " (" <> src <> ") " <> encodeBS msg)
diff --git a/Utility/DebugLocks.hs b/Utility/DebugLocks.hs
new file mode 100644
index 0000000000..4593726ff9
--- /dev/null
+++ b/Utility/DebugLocks.hs
@@ -0,0 +1,43 @@
+{- Pinpointing location of MVar/STM deadlocks
+ -
+ - Copyright 2018 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE ScopedTypeVariables #-}
+
+module Utility.DebugLocks (debugLocks) where
+
+import Control.Monad.Catch
+import Control.Monad.IO.Class
+#ifdef DEBUGLOCKS
+import Control.Exception (BlockedIndefinitelyOnSTM, BlockedIndefinitelyOnMVar)
+import GHC.Stack
+import System.IO
+#endif
+
+{- Wrap around any action, and if it dies due to deadlock, will display
+ - a call stack on stderr when DEBUGLOCKS is defined.
+ -
+ - Should be zero cost to call when DEBUGLOCKS is not defined.
+ -}
+#ifdef DEBUGLOCKS
+debugLocks :: HasCallStack => (MonadCatch m, MonadIO m) => m a -> m a
+debugLocks a = a `catches`
+	[ Handler (\ (e :: BlockedIndefinitelyOnMVar) -> go "MVar" e callStack)
+	, Handler (\ (e :: BlockedIndefinitelyOnSTM) -> go "STM" e callStack)
+	]
+  where
+	go ty e cs = do
+		liftIO $ do
+			hPutStrLn stderr $ 
+				ty ++ " deadlock detected " ++ prettyCallStack cs
+			hFlush stderr
+		throwM e
+#else
+-- No HasCallStack constraint.
+debugLocks :: (MonadCatch m, MonadIO m) => m a -> m a
+debugLocks a = a
+#endif
diff --git a/Utility/DirWatcher.hs b/Utility/DirWatcher.hs
new file mode 100644
index 0000000000..99eede4173
--- /dev/null
+++ b/Utility/DirWatcher.hs
@@ -0,0 +1,165 @@
+{- generic directory watching interface
+ -
+ - Uses inotify, or kqueue, or fsevents, or win32-notify to watch a directory
+ - (and subdirectories) for changes, and runs hooks for different
+ - sorts of events as they occur.
+ -
+ - Copyright 2012-2013 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.DirWatcher (
+	canWatch,
+	eventsCoalesce,
+	closingTracked,
+	modifyTracked,
+	DirWatcherHandle,
+	watchDir,
+	stopWatchDir,
+) where
+
+import Utility.DirWatcher.Types
+
+#if WITH_INOTIFY
+import qualified Utility.DirWatcher.INotify as INotify
+import qualified System.INotify as INotify
+#endif
+#if WITH_KQUEUE
+import qualified Utility.DirWatcher.Kqueue as Kqueue
+import Control.Concurrent
+#endif
+#if WITH_FSEVENTS
+import qualified Utility.DirWatcher.FSEvents as FSEvents
+import qualified System.OSX.FSEvents as FSEvents
+#endif
+#if WITH_WIN32NOTIFY
+import qualified Utility.DirWatcher.Win32Notify as Win32Notify
+import qualified System.Win32.Notify as Win32Notify
+#endif
+
+type Pruner = FilePath -> Bool
+
+canWatch :: Bool
+#if (WITH_INOTIFY || WITH_KQUEUE || WITH_FSEVENTS || WITH_WIN32NOTIFY)
+canWatch = True
+#else
+#if defined linux_HOST_OS
+#warning "Building without inotify support"
+#endif
+canWatch = False
+#endif
+
+{- With inotify, discrete events will be received when making multiple changes
+ - to the same filename. For example, adding it, deleting it, and adding it
+ - again will be three events.
+ - 
+ - OTOH, with kqueue, often only one event is received, indicating the most
+ - recent state of the file. -}
+eventsCoalesce :: Bool
+#if (WITH_INOTIFY || WITH_WIN32NOTIFY)
+eventsCoalesce = False
+#else
+#if (WITH_KQUEUE || WITH_FSEVENTS)
+eventsCoalesce = True
+#else
+eventsCoalesce = error "eventsCoalesce not defined"
+#endif
+#endif
+
+{- With inotify, file closing is tracked to some extent, so an add event
+ - will always be received for a file once its writer closes it, and
+ - (typically) not before. This may mean multiple add events for the same file.
+ -
+ - OTOH, with kqueue, add events will often be received while a file is
+ - still being written to, and then no add event will be received once the
+ - writer closes it.
+ - 
+ - fsevents sometimes behaves similarly, but has sometimes been 
+ - seen to behave like kqueue. -}
+closingTracked :: Bool
+#if (WITH_INOTIFY || WITH_WIN32NOTIFY)
+closingTracked = True
+#else
+#if (WITH_KQUEUE || WITH_FSEVENTS)
+closingTracked = False
+#else
+closingTracked = error "closingTracked not defined"
+#endif
+#endif
+
+{- With inotify, modifications to existing files can be tracked.
+ - Kqueue does not support this.
+ - Fsevents generates events when an existing file is reopened and rewritten,
+ - but not necessarily when it's opened once and modified repeatedly. -}
+modifyTracked :: Bool
+#if (WITH_INOTIFY || WITH_FSEVENTS || WITH_WIN32NOTIFY)
+modifyTracked = True
+#else
+#if WITH_KQUEUE
+modifyTracked = False
+#else
+modifyTracked = error "modifyTracked not defined"
+#endif
+#endif
+
+{- Starts a watcher thread. The runstartup action is passed a scanner action
+ - to run, that will return once the initial directory scan is complete.
+ - Once runstartup returns, the watcher thread continues running,
+ - and processing events. Returns a DirWatcherHandle that can be used
+ - to shutdown later. -}
+#if WITH_INOTIFY
+type DirWatcherHandle = INotify.INotify
+watchDir :: FilePath -> Pruner -> Bool -> WatchHooks -> (IO () -> IO ()) -> IO DirWatcherHandle
+watchDir dir prune scanevents hooks runstartup = do
+	i <- INotify.initINotify
+	runstartup $ INotify.watchDir i dir prune scanevents hooks
+	return i
+#else
+#if WITH_KQUEUE
+type DirWatcherHandle = ThreadId
+watchDir :: FilePath -> Pruner -> Bool -> WatchHooks -> (IO Kqueue.Kqueue -> IO Kqueue.Kqueue) -> IO DirWatcherHandle
+watchDir dir prune _scanevents hooks runstartup = do
+	kq <- runstartup $ Kqueue.initKqueue dir prune
+	forkIO $ Kqueue.runHooks kq hooks
+#else
+#if WITH_FSEVENTS
+type DirWatcherHandle = FSEvents.EventStream
+watchDir :: FilePath -> Pruner -> Bool -> WatchHooks -> (IO FSEvents.EventStream -> IO FSEvents.EventStream) -> IO DirWatcherHandle
+watchDir dir prune scanevents hooks runstartup =
+	runstartup $ FSEvents.watchDir dir prune scanevents hooks
+#else
+#if WITH_WIN32NOTIFY
+type DirWatcherHandle = Win32Notify.WatchManager
+watchDir :: FilePath -> Pruner -> Bool -> WatchHooks -> (IO Win32Notify.WatchManager -> IO Win32Notify.WatchManager) -> IO DirWatcherHandle
+watchDir dir prune scanevents hooks runstartup =
+	runstartup $ Win32Notify.watchDir dir prune scanevents hooks
+#else
+type DirWatcherHandle = ()
+watchDir :: FilePath -> Pruner -> Bool -> WatchHooks -> (IO () -> IO ()) -> IO DirWatcherHandle
+watchDir = error "watchDir not defined"
+#endif
+#endif
+#endif
+#endif
+
+stopWatchDir :: DirWatcherHandle -> IO ()
+#if WITH_INOTIFY
+stopWatchDir = INotify.killINotify
+#else
+#if WITH_KQUEUE
+stopWatchDir = killThread
+#else
+#if WITH_FSEVENTS
+stopWatchDir = FSEvents.eventStreamDestroy
+#else
+#if WITH_WIN32NOTIFY
+stopWatchDir = Win32Notify.killWatchManager
+#else
+stopWatchDir = error "stopWatchDir not defined"
+#endif
+#endif
+#endif
+#endif
diff --git a/Utility/DirWatcher/FSEvents.hs b/Utility/DirWatcher/FSEvents.hs
new file mode 100644
index 0000000000..7b6be6f13b
--- /dev/null
+++ b/Utility/DirWatcher/FSEvents.hs
@@ -0,0 +1,97 @@
+{- FSEvents interface
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.DirWatcher.FSEvents (watchDir) where
+
+import Common
+import Utility.DirWatcher.Types
+import qualified Utility.RawFilePath as R
+
+import System.OSX.FSEvents
+import qualified System.Posix.Files as Files
+import Data.Bits ((.&.))
+
+watchDir :: FilePath -> (FilePath -> Bool) -> Bool -> WatchHooks -> IO EventStream
+watchDir dir ignored scanevents hooks = do
+	unlessM fileLevelEventsSupported $
+		giveup "Need at least OSX 10.7.0 for file-level FSEvents"
+	scan dir
+	eventStreamCreate [dir] 1.0 True True True dispatch
+  where
+	dispatch evt
+		| ignoredPath ignored (eventPath evt) = noop
+		| otherwise = do
+			{- More than one flag may be set, if events occurred
+			 - close together. 
+			 - 
+			 - Order is important..
+			 - If a file is added and then deleted, we'll see it's
+			 - not present, and addHook won't run.
+			 - OTOH, if a file is deleted and then re-added,
+			 - the delHook will run first, followed by the addHook.
+			 -}
+
+			when (hasflag eventFlagItemRemoved) $
+				if hasflag eventFlagItemIsDir
+					then runhook delDirHook Nothing
+					else runhook delHook Nothing
+			when (hasflag eventFlagItemCreated) $
+				maybe noop handleadd =<< getstatus (eventPath evt)
+			{- When a file or dir is renamed, a rename event is
+			 - received for both its old and its new name. -}
+			when (hasflag eventFlagItemRenamed) $
+				if hasflag eventFlagItemIsDir
+					then ifM (doesDirectoryExist $ eventPath evt)
+						( scan $ eventPath evt
+						, runhook delDirHook Nothing
+						)
+					else maybe (runhook delHook Nothing) handleadd
+						=<< getstatus (eventPath evt)
+			{- Add hooks are run when a file is modified for 
+			 - compatibility with INotify, which calls the add
+			 - hook when a file is closed, and so tends to call
+			 - both add and modify for file modifications. -}
+			when (hasflag eventFlagItemModified && not (hasflag eventFlagItemIsDir)) $ do
+				ms <- getstatus $ eventPath evt
+				maybe noop handleadd ms
+				runhook modifyHook ms
+	  where
+		hasflag f = eventFlags evt .&. f /= 0
+		runhook h s = maybe noop (\a -> a (eventPath evt) s) (h hooks)
+		handleadd s
+			| Files.isSymbolicLink s = runhook addSymlinkHook $ Just s
+			| Files.isRegularFile s = runhook addHook $ Just s
+			| otherwise = noop
+	
+	scan d = unless (ignoredPath ignored d) $
+		-- Do not follow symlinks when scanning.
+		-- This mirrors the inotify startup scan behavior.
+		mapM_ go =<< emptyWhenDoesNotExist (dirContentsRecursiveSkipping (const False) False d)
+	  where		
+		go f
+			| ignoredPath ignored f = noop
+			| otherwise = do
+				ms <- getstatus f
+				case ms of
+					Nothing -> noop
+					Just s
+						| Files.isSymbolicLink s ->
+							when scanevents $
+								runhook addSymlinkHook ms
+						| Files.isRegularFile s ->
+							when scanevents $
+								runhook addHook ms
+						| otherwise ->
+							noop
+		  where
+			runhook h s = maybe noop (\a -> a f s) (h hooks)
+		
+	getstatus = catchMaybeIO . R.getSymbolicLinkStatus . toRawFilePath
+
+{- Check each component of the path to see if it's ignored. -}
+ignoredPath :: (FilePath -> Bool) -> FilePath -> Bool
+ignoredPath ignored = any ignored . map dropTrailingPathSeparator . splitPath
diff --git a/Utility/DirWatcher/INotify.hs b/Utility/DirWatcher/INotify.hs
new file mode 100644
index 0000000000..700bff5773
--- /dev/null
+++ b/Utility/DirWatcher/INotify.hs
@@ -0,0 +1,205 @@
+{- higher-level inotify interface
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.DirWatcher.INotify (watchDir) where
+
+import Common
+import Utility.ThreadLock
+import Utility.DirWatcher.Types
+import qualified Utility.RawFilePath as R
+
+import System.INotify
+import qualified System.Posix.Files as Files
+import System.IO.Error
+import Control.Exception (throw)
+
+{- Watches for changes to files in a directory, and all its subdirectories
+ - that are not ignored, using inotify. This function returns after
+ - its initial scan is complete, leaving a thread running. Callbacks are
+ - made for different events.
+ -
+ - Inotify is weak at recursive directory watching; the whole directory
+ - tree must be scanned and watches set explicitly for each subdirectory.
+ -
+ - To notice newly created subdirectories, inotify is used, and
+ - watches are registered for those directories. There is a race there;
+ - things can be added to a directory before the watch gets registered.
+ -
+ - To close the inotify race, each time a new directory is found, it also 
+ - recursively scans it, assuming all files in it were just added,
+ - and registering each subdirectory.
+ -
+ - Note: Due to the race amelioration, multiple add events may occur
+ - for the same file.
+ - 
+ - Note: Moving a file will cause events deleting it from its old location
+ - and adding it to the new location. 
+ - 
+ - Note: It's assumed that when a file that was open for write is closed, 
+ - it's finished being written to, and can be added.
+ -
+ - Note: inotify has a limit to the number of watches allowed,
+ - /proc/sys/fs/inotify/max_user_watches (default 8192).
+ - So this will fail if there are too many subdirectories. The
+ - errHook is called when this happens.
+ -}
+watchDir :: INotify -> FilePath -> (FilePath -> Bool) -> Bool -> WatchHooks -> IO ()
+watchDir i dir ignored scanevents hooks
+	| ignored dir = noop
+	| otherwise = do
+		-- Use a lock to make sure events generated during initial
+		-- scan come before real inotify events.
+		lock <- newLock
+		let handler event = withLock lock (void $ go event)
+		flip catchNonAsync failedwatch $ do
+			void (addWatch i watchevents (toInternalFilePath dir) handler)
+				`catchIO` failedaddwatch
+			withLock lock $
+				mapM_ scan =<< filter (not . dirCruft) <$>
+					getDirectoryContents dir
+  where
+	recurse d = watchDir i d ignored scanevents hooks
+
+	-- Select only inotify events required by the enabled
+	-- hooks, but always include Create so new directories can
+	-- be scanned.
+	watchevents = Create : addevents ++ delevents ++ modifyevents
+	addevents
+		| hashook addHook || hashook addSymlinkHook = [MoveIn, CloseWrite]
+		| otherwise = []
+	delevents
+		| hashook delHook || hashook delDirHook = [MoveOut, Delete]
+		| otherwise = []
+	modifyevents
+		| hashook modifyHook = [Modify]
+		| otherwise = []
+
+	scan f = unless (ignored f) $ do
+		ms <- getstatus f
+		case ms of
+			Nothing -> return ()
+			Just s
+				| Files.isDirectory s ->
+					recurse $ indir f
+				| Files.isSymbolicLink s ->
+					when scanevents $
+						runhook addSymlinkHook f ms
+				| Files.isRegularFile s ->
+					when scanevents $
+						runhook addHook f ms
+				| otherwise ->
+					noop
+
+	go (Created { isDirectory = isd, filePath = fi })
+		| isd = recurse $ indir f
+		| otherwise = do
+			ms <- getstatus f
+			case ms of
+				Just s
+					| Files.isSymbolicLink s -> 
+						when (hashook addSymlinkHook) $
+							runhook addSymlinkHook f ms
+					| Files.isRegularFile s ->
+						when (hashook addHook) $
+							runhook addHook f ms
+				_ -> noop
+	  where
+		f = fromInternalFilePath fi
+
+	-- Closing a file is assumed to mean it's done being written,
+	-- so a new add event is sent.
+	go (Closed { isDirectory = False, maybeFilePath = Just fi }) =
+			checkfiletype Files.isRegularFile addHook $ 
+				fromInternalFilePath fi
+
+	-- When a file or directory is moved in, scan it to add new
+	-- stuff.
+	go (MovedIn { filePath = fi }) = scan $ fromInternalFilePath fi
+	go (MovedOut { isDirectory = isd, filePath = fi })
+		| isd = runhook delDirHook f Nothing
+		| otherwise = runhook delHook f Nothing
+	  where
+		f = fromInternalFilePath fi
+
+	-- Verify that the deleted item really doesn't exist,
+	-- since there can be spurious deletion events for items
+	-- in a directory that has been moved out, but is still
+	-- being watched.
+	go (Deleted { isDirectory = isd, filePath = fi })
+		| isd = guarded $ runhook delDirHook f Nothing
+		| otherwise = guarded $ runhook delHook f Nothing
+	  where
+		guarded = unlessM (filetype (const True) f)
+		f = fromInternalFilePath fi
+
+	go (Modified { isDirectory = isd, maybeFilePath = Just fi })
+		| isd = noop
+		| otherwise = runhook modifyHook (fromInternalFilePath fi) Nothing
+
+	go _ = noop
+
+	hashook h = isJust $ h hooks
+
+	runhook h f s
+		| ignored f = noop
+		| otherwise = maybe noop (\a -> a (indir f) s) (h hooks)
+
+	indir f = dir </> f
+
+	getstatus f = catchMaybeIO $ R.getSymbolicLinkStatus $ toRawFilePath $ indir f
+	checkfiletype check h f = do
+		ms <- getstatus f
+		case ms of
+			Just s
+				| check s -> runhook h f ms
+			_ -> noop
+	filetype t f = catchBoolIO $ t <$> R.getSymbolicLinkStatus (toRawFilePath (indir f))
+
+	failedaddwatch e
+		-- Inotify fails when there are too many watches with a
+		-- disk full error.
+		| isFullError e =
+			case errHook hooks of
+				Nothing -> giveup $ "failed to add inotify watch on directory " ++ dir ++ " (" ++ show e ++ ")"
+				Just hook -> tooManyWatches hook dir
+		-- The directory could have been deleted.
+		| isDoesNotExistError e = return ()
+		| otherwise = throw e
+
+	failedwatch e = hPutStrLn stderr $ "failed to add watch on directory " ++ dir ++ " (" ++ show e ++ ")"
+
+tooManyWatches :: (String -> Maybe FileStatus -> IO ()) -> FilePath -> IO ()
+tooManyWatches hook dir = do
+	sysctlval <- querySysctl [Param maxwatches] :: IO (Maybe Integer)
+	hook (unlines $ basewarning : maybe withoutsysctl withsysctl sysctlval) Nothing
+  where
+	maxwatches = "fs.inotify.max_user_watches"
+	basewarning = "Too many directories to watch! (Not watching " ++ dir ++")"
+	withoutsysctl = ["Increase the value in /proc/sys/fs/inotify/max_user_watches"]
+	withsysctl n = let new = n * 10 in
+		[ "Increase the limit permanently by running:"
+		, "  echo " ++ maxwatches ++ "=" ++ show new ++
+		  " | sudo tee -a /etc/sysctl.conf; sudo sysctl -p"
+		, "Or temporarily by running:"
+		, "  sudo sysctl -w " ++ maxwatches ++ "=" ++ show new
+		]
+
+querySysctl :: Read a => [CommandParam] -> IO (Maybe a)
+querySysctl ps = getM go ["sysctl", "/sbin/sysctl", "/usr/sbin/sysctl"]
+  where
+	go p = do
+		v <- catchMaybeIO $ readProcess p (toCommand ps)
+		case v of
+			Nothing -> return Nothing
+			Just s -> return $ parsesysctl s
+	parsesysctl s = readish =<< lastMaybe (words s)
+
+toInternalFilePath :: FilePath -> RawFilePath
+toInternalFilePath = toRawFilePath
+
+fromInternalFilePath :: RawFilePath -> FilePath
+fromInternalFilePath = fromRawFilePath
diff --git a/Utility/DirWatcher/Kqueue.hs b/Utility/DirWatcher/Kqueue.hs
new file mode 100644
index 0000000000..dc9fed31c2
--- /dev/null
+++ b/Utility/DirWatcher/Kqueue.hs
@@ -0,0 +1,269 @@
+{- BSD kqueue file modification notification interface
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE ForeignFunctionInterface #-}
+
+module Utility.DirWatcher.Kqueue (
+	Kqueue,
+	initKqueue,
+	stopKqueue,
+	waitChange,
+	Change(..),
+	changedFile,
+	runHooks,
+) where
+
+import Common
+import Utility.DirWatcher.Types
+import Utility.OpenFd
+
+import System.Posix.Types
+import Foreign.C.Types
+import Foreign.C.Error
+import Foreign.Ptr
+import Foreign.Marshal
+import qualified Data.Map.Strict as M
+import qualified Data.Set as S
+import qualified System.Posix.Files as Posix
+import qualified System.Posix.IO as Posix
+import Control.Concurrent
+
+data Change
+	= Deleted FilePath
+	| DeletedDir FilePath
+	| Added FilePath
+	deriving (Show)
+
+isAdd :: Change -> Bool
+isAdd (Added _) = True
+isAdd (Deleted _) = False
+isAdd (DeletedDir _) = False
+
+changedFile :: Change -> FilePath
+changedFile (Added f) = f
+changedFile (Deleted f) = f
+changedFile (DeletedDir f) = f
+
+data Kqueue = Kqueue 
+	{ kqueueFd :: Fd
+	, kqueueTop :: FilePath
+	, kqueueMap :: DirMap
+	, _kqueuePruner :: Pruner
+	}
+
+type Pruner = FilePath -> Bool
+
+type DirMap = M.Map Fd DirInfo
+
+{- Enough information to uniquely identify a file in a directory,
+ - but not too much. -}
+data DirEnt = DirEnt
+	{ dirEnt :: FilePath -- relative to the parent directory
+	, _dirInode :: FileID -- included to notice file replacements
+	, isSubDir :: Bool
+	}
+	deriving (Eq, Ord, Show)
+
+{- A directory, and its last known contents. -}
+data DirInfo = DirInfo
+	{ dirName :: FilePath
+	, dirCache :: S.Set DirEnt
+	}
+	deriving (Show)
+
+getDirInfo :: FilePath -> IO DirInfo
+getDirInfo dir = do
+	l <- filter (not . dirCruft) <$> getDirectoryContents dir
+	contents <- S.fromList . catMaybes <$> mapM getDirEnt l
+	return $ DirInfo dir contents
+  where
+	getDirEnt f = catchMaybeIO $ do
+		s <- getSymbolicLinkStatus (dir </> f)
+		return $ DirEnt f (fileID s) (isDirectory s)
+
+{- Difference between the dirCaches of two DirInfos. -}
+(//) :: DirInfo -> DirInfo -> [Change]
+oldc // newc = deleted ++ added
+  where
+	deleted = calc gendel oldc newc
+	added   = calc genadd newc oldc
+	gendel x = (if isSubDir x then DeletedDir else Deleted) $
+		dirName oldc </> dirEnt x
+	genadd x = Added $ dirName newc </> dirEnt x
+	calc a x y = map a $ S.toList $
+		S.difference (dirCache x) (dirCache y)
+
+{- Builds a map of directories in a tree, possibly pruning some.
+ - Opens each directory in the tree, and records its current contents. -}
+scanRecursive :: FilePath -> Pruner -> IO DirMap
+scanRecursive topdir prune = M.fromList <$> walk [] [topdir]
+  where
+	walk c [] = return c
+	walk c (dir:rest)
+		| prune dir = walk c rest
+		| otherwise = do
+			minfo <- catchMaybeIO $ getDirInfo dir
+			case minfo of
+				Nothing -> walk c rest
+				Just info -> do
+					mfd <- catchMaybeIO $
+						openFdWithMode (toRawFilePath dir) Posix.ReadOnly Nothing Posix.defaultFileFlags
+					case mfd of
+						Nothing -> walk c rest
+						Just fd -> do
+							let subdirs = map (dir </>) . map dirEnt $
+								S.toList $ dirCache info
+							walk ((fd, info):c) (subdirs ++ rest)
+
+{- Adds a list of subdirectories (and all their children), unless pruned to a
+ - directory map. Adding a subdirectory that's already in the map will
+ - cause its contents to be refreshed. -}
+addSubDirs :: DirMap -> Pruner -> [FilePath] -> IO DirMap
+addSubDirs dirmap prune dirs = do
+	newmap <- foldr M.union M.empty <$>
+		mapM (\d -> scanRecursive d prune) dirs
+	return $ M.union newmap dirmap -- prefer newmap
+
+{- Removes a subdirectory (and all its children) from a directory map. -}
+removeSubDir :: DirMap -> FilePath -> IO DirMap
+removeSubDir dirmap dir = do
+	mapM_ Posix.closeFd $ M.keys toremove
+	return rest
+  where
+	(toremove, rest) = M.partition (dirContains (toRawFilePath dir) . toRawFilePath . dirName) dirmap
+
+findDirContents :: DirMap -> FilePath -> [FilePath]
+findDirContents dirmap dir = concatMap absolutecontents $ search
+  where
+	absolutecontents i = map (dirName i </>)
+		(map dirEnt $ S.toList $ dirCache i)
+	search = map snd $ M.toList $
+		M.filter (\i -> dirName i == dir) dirmap
+
+foreign import ccall safe "libkqueue.h init_kqueue" c_init_kqueue
+	:: IO Fd
+foreign import ccall safe "libkqueue.h addfds_kqueue" c_addfds_kqueue
+	:: Fd -> CInt -> Ptr Fd -> IO ()
+foreign import ccall safe "libkqueue.h waitchange_kqueue" c_waitchange_kqueue
+	:: Fd -> IO Fd
+
+{- Initializes a Kqueue to watch a directory, and all its subdirectories. -}
+initKqueue :: FilePath -> Pruner -> IO Kqueue
+initKqueue dir pruned = do
+	dirmap <- scanRecursive dir pruned
+	h <- c_init_kqueue
+	let kq = Kqueue h dir dirmap pruned
+	updateKqueue kq
+	return kq
+
+{- Updates a Kqueue, adding watches for its map. -}
+updateKqueue :: Kqueue -> IO ()
+updateKqueue (Kqueue h _ dirmap _) =
+	withArrayLen (M.keys dirmap) $ \fdcnt c_fds -> do
+		c_addfds_kqueue h (fromIntegral fdcnt) c_fds
+
+{- Stops a Kqueue. Note: Does not directly close the Fds in the dirmap,
+ - so it can be reused.  -}
+stopKqueue :: Kqueue -> IO ()
+stopKqueue = Posix.closeFd . kqueueFd
+
+{- Waits for a change on a Kqueue.
+ - May update the Kqueue.
+ -}
+waitChange :: Kqueue -> IO (Kqueue, [Change])
+waitChange kq@(Kqueue h _ dirmap _) = do
+	changedfd <- c_waitchange_kqueue h
+	if changedfd == -1
+		then ifM ((==) eINTR <$> getErrno)
+			(yield >> waitChange kq, nochange)
+		else case M.lookup changedfd dirmap of
+			Nothing -> nochange
+			Just info -> handleChange kq changedfd info
+  where
+	nochange = return (kq, [])
+
+{- The kqueue interface does not tell what type of change took place in
+ - the directory; it could be an added file, a deleted file, a renamed
+ - file, a new subdirectory, or a deleted subdirectory, or a moved
+ - subdirectory. 
+ -
+ - So to determine this, the contents of the directory are compared
+ - with its last cached contents. The Kqueue is updated to watch new
+ - directories as necessary.
+ -}
+handleChange :: Kqueue -> Fd -> DirInfo -> IO (Kqueue, [Change])
+handleChange kq@(Kqueue _ _ dirmap pruner) fd olddirinfo =
+	go =<< catchMaybeIO (getDirInfo $ dirName olddirinfo)
+  where
+	go (Just newdirinfo) = do
+		let changes = filter (not . pruner . changedFile) $
+			 olddirinfo // newdirinfo
+		let (added, deleted) = partition isAdd changes
+
+		-- Scan newly added directories to add to the map.
+		-- (Newly added files will fail getDirInfo.)
+		newdirinfos <- catMaybes <$>
+			mapM (catchMaybeIO . getDirInfo . changedFile) added
+		newmap <- addSubDirs dirmap pruner $ map dirName newdirinfos
+
+		-- Remove deleted directories from the map.
+		newmap' <- foldM removeSubDir newmap (map changedFile deleted)
+
+		-- Update the cached dirinfo just looked up.
+		let newmap'' = M.insert fd newdirinfo newmap'
+
+		-- When new directories were added, need to update
+		-- the kqueue to watch them.
+		let kq' = kq { kqueueMap = newmap'' }
+		unless (null newdirinfos) $
+			updateKqueue kq'
+
+		return (kq', changes)
+	go Nothing = do
+		-- The directory has been moved or deleted, so
+		-- remove it from our map.
+		newmap <- removeSubDir dirmap (dirName olddirinfo)
+		return (kq { kqueueMap = newmap }, [])
+
+{- Processes changes on the Kqueue, calling the hooks as appropriate.
+ - Never returns. -}
+runHooks :: Kqueue -> WatchHooks -> IO ()
+runHooks kq hooks = do
+	-- First, synthetic add events for the whole directory tree contents,
+	-- to catch any files created beforehand.
+	recursiveadd (kqueueMap kq) (Added $ kqueueTop kq)
+	loop kq
+  where
+	loop q = do
+		(q', changes) <- waitChange q
+		forM_ changes $ dispatch (kqueueMap q')
+		loop q'
+
+	dispatch _ change@(Deleted _) = 
+		callhook delHook Nothing change
+	dispatch _ change@(DeletedDir _) =
+		callhook delDirHook Nothing change
+	dispatch dirmap change@(Added _) =
+		withstatus change $ dispatchadd dirmap
+		
+	dispatchadd dirmap change s
+		| Posix.isSymbolicLink s = callhook addSymlinkHook (Just s) change
+		| Posix.isDirectory s = recursiveadd dirmap change
+		| Posix.isRegularFile s = callhook addHook (Just s) change
+		| otherwise = noop
+
+	recursiveadd dirmap change = do
+		let contents = findDirContents dirmap $ changedFile change
+		forM_ contents $ \f ->
+			withstatus (Added f) $ dispatchadd dirmap
+
+	callhook h s change = case h hooks of
+		Nothing -> noop
+		Just a -> a (changedFile change) s
+
+	withstatus change a = maybe noop (a change) =<<
+		(catchMaybeIO (getSymbolicLinkStatus (changedFile change)))
diff --git a/Utility/DirWatcher/Types.hs b/Utility/DirWatcher/Types.hs
new file mode 100644
index 0000000000..9abd5f36a1
--- /dev/null
+++ b/Utility/DirWatcher/Types.hs
@@ -0,0 +1,28 @@
+{- generic directory watching types
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.DirWatcher.Types (
+	Hook,
+	WatchHooks(..),
+	mkWatchHooks,
+) where
+
+import Common
+
+type Hook a = Maybe (a -> Maybe FileStatus -> IO ())
+
+data WatchHooks = WatchHooks
+	{ addHook :: Hook FilePath
+	, addSymlinkHook :: Hook FilePath
+	, delHook :: Hook FilePath
+	, delDirHook :: Hook FilePath
+	, errHook :: Hook String -- error message
+	, modifyHook :: Hook FilePath
+	}
+
+mkWatchHooks :: WatchHooks
+mkWatchHooks = WatchHooks Nothing Nothing Nothing Nothing Nothing Nothing
diff --git a/Utility/DirWatcher/Win32Notify.hs b/Utility/DirWatcher/Win32Notify.hs
new file mode 100644
index 0000000000..e5ce316ce6
--- /dev/null
+++ b/Utility/DirWatcher/Win32Notify.hs
@@ -0,0 +1,67 @@
+{- Win32-notify interface
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.DirWatcher.Win32Notify (watchDir) where
+
+import Common
+import Utility.DirWatcher.Types
+import qualified Utility.RawFilePath as R
+
+import System.Win32.Notify
+import System.PosixCompat.Files (isRegularFile)
+
+watchDir :: FilePath -> (FilePath -> Bool) -> Bool -> WatchHooks -> IO WatchManager
+watchDir dir ignored scanevents hooks = do
+	scan dir
+	wm <- initWatchManager
+	void $ watchDirectory wm dir True [Create, Delete, Modify, Move] dispatch
+	return wm
+  where
+	dispatch evt
+		| ignoredPath ignored (filePath evt) = noop
+		| otherwise = case evt of
+			(Deleted _ _)
+				| isDirectory evt -> runhook delDirHook Nothing
+				| otherwise -> runhook delHook Nothing
+			(Created _ _)
+				| isDirectory evt -> noop
+				| otherwise -> runhook addHook Nothing
+			(Modified _ _)
+				| isDirectory evt -> noop
+				{- Add hooks are run when a file is modified for 
+				 - compatibility with INotify, which calls the add
+				 - hook when a file is closed, and so tends to call
+				 - both add and modify for file modifications. -}
+				| otherwise -> do
+					runhook addHook Nothing
+					runhook modifyHook Nothing
+	  where
+		runhook h s = maybe noop (\a -> a (filePath evt) s) (h hooks)
+
+	scan d = unless (ignoredPath ignored d) $
+		mapM_ go =<< emptyWhenDoesNotExist (dirContentsRecursiveSkipping (const False) False d)
+	  where		
+		go f
+			| ignoredPath ignored f = noop
+			| otherwise = do
+				ms <- getstatus f
+				case ms of
+					Nothing -> noop
+					Just s
+						| isRegularFile s ->
+							when scanevents $
+								runhook addHook ms
+						| otherwise ->
+							noop
+		  where
+			runhook h s = maybe noop (\a -> a f s) (h hooks)
+		
+	getstatus = catchMaybeIO . R.getFileStatus . toRawFilePath
+
+{- Check each component of the path to see if it's ignored. -}
+ignoredPath :: (FilePath -> Bool) -> FilePath -> Bool
+ignoredPath ignored = any ignored . map dropTrailingPathSeparator . splitPath
diff --git a/Utility/Directory.hs b/Utility/Directory.hs
new file mode 100644
index 0000000000..bf997b8606
--- /dev/null
+++ b/Utility/Directory.hs
@@ -0,0 +1,129 @@
+{- directory traversal and manipulation
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE LambdaCase #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Directory (
+	module Utility.Directory,
+	module Utility.SystemDirectory
+) where
+
+import Control.Monad
+import System.FilePath
+import System.PosixCompat.Files (isDirectory, isSymbolicLink)
+import Control.Applicative
+import System.IO.Unsafe (unsafeInterleaveIO)
+import Data.Maybe
+import Prelude
+
+import Utility.SystemDirectory
+import Utility.Exception
+import Utility.Monad
+import Utility.FileSystemEncoding
+import qualified Utility.RawFilePath as R
+
+dirCruft :: FilePath -> Bool
+dirCruft "." = True
+dirCruft ".." = True
+dirCruft _ = False
+
+{- Lists the contents of a directory.
+ - Unlike getDirectoryContents, paths are not relative to the directory. -}
+dirContents :: FilePath -> IO [FilePath]
+dirContents d = map (d </>) . filter (not . dirCruft) <$> getDirectoryContents d
+
+{- Gets files in a directory, and then its subdirectories, recursively,
+ - and lazily.
+ -
+ - Does not follow symlinks to other subdirectories.
+ -
+ - Throws exception if the directory does not exist or otherwise cannot be
+ - accessed. However, does not throw exceptions when subdirectories cannot
+ - be accessed (the use of unsafeInterleaveIO would make it difficult to
+ - trap such exceptions).
+ -}
+dirContentsRecursive :: FilePath -> IO [FilePath]
+dirContentsRecursive = dirContentsRecursiveSkipping (const False) True
+
+{- Skips directories whose basenames match the skipdir. -}
+dirContentsRecursiveSkipping :: (FilePath -> Bool) -> Bool -> FilePath -> IO [FilePath]
+dirContentsRecursiveSkipping skipdir followsubdirsymlinks topdir
+	| skipdir (takeFileName topdir) = return []
+	| otherwise = do
+		-- Get the contents of the top directory outside of
+		-- unsafeInterleaveIO, which allows throwing exceptions if
+		-- it cannot be accessed.
+		(files, dirs) <- collect [] []
+			=<< dirContents topdir
+		files' <- go dirs
+		return (files ++ files')
+  where
+	go [] = return []
+	go (dir:dirs)
+		| skipdir (takeFileName dir) = go dirs
+		| otherwise = unsafeInterleaveIO $ do
+			(files, dirs') <- collect [] []
+				=<< catchDefaultIO [] (dirContents dir)
+			files' <- go (dirs' ++ dirs)
+			return (files ++ files')
+	collect files dirs' [] = return (reverse files, reverse dirs')
+	collect files dirs' (entry:entries)
+		| dirCruft entry = collect files dirs' entries
+		| otherwise = do
+			let skip = collect (entry:files) dirs' entries
+			let recurse = collect files (entry:dirs') entries
+			ms <- catchMaybeIO $ R.getSymbolicLinkStatus (toRawFilePath entry)
+			case ms of
+				(Just s) 
+					| isDirectory s -> recurse
+					| isSymbolicLink s && followsubdirsymlinks ->
+						ifM (doesDirectoryExist entry)
+							( recurse
+							, skip
+							)
+				_ -> skip
+
+{- Gets the directory tree from a point, recursively and lazily,
+ - with leaf directories **first**, skipping any whose basenames
+ - match the skipdir. Does not follow symlinks.
+ -
+ - Throws exception if the directory does not exist or otherwise cannot be
+ - accessed. However, does not throw exceptions when subdirectories cannot
+ - be accessed (the use of unsafeInterleaveIO would make it difficult to
+ - trap such exceptions).
+ -}
+dirTreeRecursiveSkipping :: (FilePath -> Bool) -> FilePath -> IO [FilePath]
+dirTreeRecursiveSkipping skipdir topdir
+	| skipdir (takeFileName topdir) = return []
+	| otherwise = do
+		subdirs <- filterM isdir =<< dirContents topdir
+		go [] subdirs
+  where
+	go c [] = return c
+	go c (dir:dirs)
+		| skipdir (takeFileName dir) = go c dirs
+		| otherwise = unsafeInterleaveIO $ do
+			subdirs <- go []
+				=<< filterM isdir
+				=<< catchDefaultIO [] (dirContents dir)
+			go (subdirs++dir:c) dirs
+	isdir p = isDirectory <$> R.getSymbolicLinkStatus (toRawFilePath p)
+
+{- When the action fails due to the directory not existing, returns []. -}
+emptyWhenDoesNotExist :: IO [a] -> IO [a]
+emptyWhenDoesNotExist a = tryWhenExists a >>= return . \case
+	Just v -> v
+	Nothing -> []
+
+{- Use with an action that removes something, which may or may not exist.
+ -
+ - If an exception is thrown due to it not existing, it is ignored.
+ -}
+removeWhenExistsWith :: (a -> IO ()) -> a -> IO ()
+removeWhenExistsWith f a = void $ tryWhenExists $ f a
diff --git a/Utility/Directory/Create.hs b/Utility/Directory/Create.hs
new file mode 100644
index 0000000000..5650f96db1
--- /dev/null
+++ b/Utility/Directory/Create.hs
@@ -0,0 +1,105 @@
+{- directory creating
+ -
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE LambdaCase #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Directory.Create (
+	createDirectoryUnder,
+	createDirectoryUnder',
+) where
+
+import Control.Monad
+import Control.Applicative
+import Control.Monad.IO.Class
+import Control.Monad.IfElse
+import System.IO.Error
+import Data.Maybe
+import qualified System.FilePath.ByteString as P
+import Prelude
+
+import Utility.SystemDirectory
+import Utility.Path.AbsRel
+import Utility.Exception
+import Utility.FileSystemEncoding
+import qualified Utility.RawFilePath as R
+import Utility.PartialPrelude
+
+{- Like createDirectoryIfMissing True, but it will only create
+ - missing parent directories up to but not including a directory
+ - from the first parameter.
+ -
+ - For example, createDirectoryUnder ["/tmp/foo"] "/tmp/foo/bar/baz"
+ - will create /tmp/foo/bar if necessary, but if /tmp/foo does not exist,
+ - it will throw an exception.
+ -
+ - The exception thrown is the same that createDirectory throws if the
+ - parent directory does not exist.
+ -
+ - If the second FilePath is not under the first
+ - FilePath (or the same as it), it will fail with an exception
+ - even if the second FilePath's parent directory already exists.
+ -
+ - The FilePaths can be relative, or absolute. 
+ - They will be normalized as necessary.
+ -
+ - Note that, the second FilePath, if relative, is relative to the current
+ - working directory.
+ -}
+createDirectoryUnder :: [RawFilePath] -> RawFilePath -> IO ()
+createDirectoryUnder topdirs dir =
+	createDirectoryUnder' topdirs dir R.createDirectory
+
+createDirectoryUnder'
+	:: (MonadIO m, MonadCatch m)
+	=> [RawFilePath]
+	-> RawFilePath
+	-> (RawFilePath -> m ())
+	-> m ()
+createDirectoryUnder' topdirs dir0 mkdir = do
+	relps <- liftIO $ forM topdirs $ \topdir -> relPathDirToFile topdir dir0
+	let relparts = map P.splitDirectories relps
+	-- Catch cases where dir0 is not beneath a topdir.
+	-- If the relative path between them starts with "..",
+	-- it's not. And on Windows, if they are on different drives,
+	-- the path will not be relative.
+	let notbeneath = \(_topdir, (relp, dirs)) -> 
+		headMaybe dirs /= Just ".." && not (P.isAbsolute relp)
+	case filter notbeneath $ zip topdirs (zip relps relparts) of
+		((topdir, (_relp, dirs)):_)
+			-- If dir0 is the same as the topdir, don't try to
+			-- create it, but make sure it does exist.
+			| null dirs ->
+				liftIO $ unlessM (doesDirectoryExist (fromRawFilePath topdir)) $
+					ioError $ customerror doesNotExistErrorType $
+						"createDirectoryFrom: " ++ fromRawFilePath topdir ++ " does not exist"
+			| otherwise -> createdirs $
+					map (topdir P.</>) (reverse (scanl1 (P.</>) dirs))
+		_ -> liftIO $ ioError $ customerror userErrorType
+			("createDirectoryFrom: not located in " ++ unwords (map fromRawFilePath topdirs))
+  where
+	customerror t s = mkIOError t s Nothing (Just (fromRawFilePath dir0))
+
+	createdirs [] = pure ()
+	createdirs (dir:[]) = createdir dir (liftIO . ioError)
+	createdirs (dir:dirs) = createdir dir $ \_ -> do
+		createdirs dirs
+		createdir dir (liftIO . ioError)
+
+	-- This is the same method used by createDirectoryIfMissing,
+	-- in particular the handling of errors that occur when the
+	-- directory already exists. See its source for explanation
+	-- of several subtleties.
+	createdir dir notexisthandler = tryIO (mkdir dir) >>= \case
+		Right () -> pure ()
+		Left e
+			| isDoesNotExistError e -> notexisthandler e
+			| isAlreadyExistsError e || isPermissionError e ->
+				liftIO $ unlessM (doesDirectoryExist (fromRawFilePath dir)) $
+					ioError e
+			| otherwise -> liftIO $ ioError e
diff --git a/Utility/Directory/Stream.hs b/Utility/Directory/Stream.hs
new file mode 100644
index 0000000000..3a6222c561
--- /dev/null
+++ b/Utility/Directory/Stream.hs
@@ -0,0 +1,119 @@
+{- streaming directory traversal
+ -
+ - Copyright 2011-2018 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE LambdaCase #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Directory.Stream (
+	DirectoryHandle,
+	openDirectory,
+	closeDirectory,
+	readDirectory,
+	isDirectoryEmpty,
+) where
+
+import Control.Monad
+import System.FilePath
+import Control.Concurrent
+import Data.Maybe
+import Prelude
+
+#ifdef mingw32_HOST_OS
+import qualified System.Win32 as Win32
+#else
+import qualified System.Posix as Posix
+#endif
+
+import Utility.Directory
+import Utility.Exception
+
+#ifndef mingw32_HOST_OS
+data DirectoryHandle = DirectoryHandle IsOpen Posix.DirStream
+#else
+data DirectoryHandle = DirectoryHandle IsOpen Win32.HANDLE Win32.FindData (MVar ())
+#endif
+
+type IsOpen = MVar () -- full when the handle is open
+
+openDirectory :: FilePath -> IO DirectoryHandle
+openDirectory path = do
+#ifndef mingw32_HOST_OS
+	dirp <- Posix.openDirStream path
+	isopen <- newMVar ()
+	return (DirectoryHandle isopen dirp)
+#else
+	(h, fdat) <- Win32.findFirstFile (path </> "*")
+	-- Indicate that the fdat contains a filename that readDirectory
+	-- has not yet returned, by making the MVar be full.
+	-- (There's always at least a "." entry.)
+	alreadyhave <- newMVar ()
+	isopen <- newMVar ()
+	return (DirectoryHandle isopen h fdat alreadyhave)
+#endif
+
+closeDirectory :: DirectoryHandle -> IO ()
+#ifndef mingw32_HOST_OS
+closeDirectory (DirectoryHandle isopen dirp) =
+	whenOpen isopen $
+		Posix.closeDirStream dirp
+#else
+closeDirectory (DirectoryHandle isopen h _ alreadyhave) =
+	whenOpen isopen $ do
+		_ <- tryTakeMVar alreadyhave
+		Win32.findClose h
+#endif
+  where
+	whenOpen :: IsOpen -> IO () -> IO ()
+	whenOpen mv f = do
+		v <- tryTakeMVar mv
+		when (isJust v) f
+
+-- | Reads the next entry from the handle. Once the end of the directory
+-- is reached, returns Nothing and automatically closes the handle.
+readDirectory :: DirectoryHandle -> IO (Maybe FilePath)
+#ifndef mingw32_HOST_OS
+readDirectory hdl@(DirectoryHandle _ dirp) = do
+	e <- Posix.readDirStream dirp
+	if null e
+		then do
+			closeDirectory hdl
+			return Nothing
+		else return (Just e)
+#else
+readDirectory hdl@(DirectoryHandle _ h fdat mv) = do
+	-- If the MVar is full, then the filename in fdat has
+	-- not yet been returned. Otherwise, need to find the next
+	-- file.
+	r <- tryTakeMVar mv
+	case r of
+		Just () -> getfn
+		Nothing -> do
+			more <- Win32.findNextFile h fdat
+			if more
+				then getfn
+				else do
+					closeDirectory hdl
+					return Nothing
+  where
+	getfn = do
+		filename <- Win32.getFindDataFileName fdat
+		return (Just filename)
+#endif
+
+-- | True only when directory exists and contains nothing.
+-- Throws exception if directory does not exist.
+isDirectoryEmpty :: FilePath -> IO Bool
+isDirectoryEmpty d = bracket (openDirectory d) closeDirectory check
+  where
+	check h = do
+		v <- readDirectory h
+		case v of
+			Nothing -> return True
+			Just f
+				| not (dirCruft f) -> return False
+				| otherwise -> check h
diff --git a/Utility/DiskFree.hs b/Utility/DiskFree.hs
new file mode 100644
index 0000000000..39e266162d
--- /dev/null
+++ b/Utility/DiskFree.hs
@@ -0,0 +1,24 @@
+{- disk free space checking shim
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+{-# LANGUAGE CPP #-}
+
+module Utility.DiskFree (
+	getDiskFree,
+	getDiskSize
+) where
+
+import System.DiskSpace
+import Utility.Applicative
+import Utility.Exception
+
+getDiskFree :: FilePath -> IO (Maybe Integer)
+getDiskFree = catchMaybeIO . getAvailSpace
+
+getDiskSize :: FilePath -> IO (Maybe Integer)
+getDiskSize = fmap diskTotal <$$> catchMaybeIO . getDiskUsage
diff --git a/Utility/Dot.hs b/Utility/Dot.hs
new file mode 100644
index 0000000000..95aff93c02
--- /dev/null
+++ b/Utility/Dot.hs
@@ -0,0 +1,75 @@
+{- a simple graphviz / dot(1) digraph description generator library
+ -
+ - import qualified
+ -
+ - Copyright 2010 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.Dot (
+	graph,
+	graphNode,
+	graphEdge,
+	label,
+	attr,
+	fillColor,
+	subGraph,
+	indent,
+	quote,
+) where
+
+{- generates a graph description from a list of lines -}
+graph :: [String] -> String
+graph s = unlines $ [header] ++ map indent s ++ [footer]
+  where
+	header = "digraph map {"
+	footer= "}"
+
+{- a node in the graph -}
+graphNode :: String -> String -> String
+graphNode nodeid desc = label desc $ quote nodeid
+
+{- an edge between two nodes -}
+graphEdge :: String -> String -> Maybe String -> String
+graphEdge fromid toid desc = indent $ maybe edge (`label` edge) desc
+  where
+	edge = quote fromid ++ " -> " ++ quote toid
+
+{- adds a label to a node or edge -}
+label :: String -> String -> String
+label = attr "label"
+
+{- adds an attribute to a node or edge
+ - (can be called multiple times for multiple attributes) -}
+attr :: String -> String -> String -> String
+attr a v s = s ++ " [ " ++ a ++ "=" ++ quote v ++ " ]"
+
+{- fills a node with a color -}
+fillColor :: String -> String -> String
+fillColor color s = attr "fillcolor" color $ attr "style" "filled" s
+
+{- apply to graphNode to put the node in a labeled box -}
+subGraph :: String -> String -> String -> String -> String
+subGraph subid l color s =
+	"subgraph " ++ name ++ " {\n" ++
+		ii setlabel ++
+		ii setfilled ++
+		ii setcolor ++
+		ii s ++
+		indent "}"
+  where
+	-- the "cluster_" makes dot draw a box
+	name = quote ("cluster_" ++ subid)
+	setlabel = "label=" ++ quote l
+	setfilled = "style=" ++ quote "filled"
+	setcolor = "fillcolor=" ++ quote color
+	ii x = indent (indent x) ++ "\n"
+
+indent ::String -> String
+indent s = '\t' : s
+
+quote :: String -> String
+quote s = "\"" ++ s' ++ "\""
+  where
+	s' = filter (/= '"') s
diff --git a/Utility/DottedVersion.hs b/Utility/DottedVersion.hs
new file mode 100644
index 0000000000..84b8463dbe
--- /dev/null
+++ b/Utility/DottedVersion.hs
@@ -0,0 +1,45 @@
+{- dotted versions, such as 1.0.1
+ -
+ - Copyright 2011-2014 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.DottedVersion (
+	DottedVersion,
+	fromDottedVersion,
+	normalize,
+) where
+
+import Utility.Split
+
+data DottedVersion = DottedVersion String Integer
+	deriving (Eq)
+
+instance Ord DottedVersion where
+	compare (DottedVersion _ x) (DottedVersion _ y) = compare x y
+
+instance Show DottedVersion where
+	show = fromDottedVersion
+
+fromDottedVersion :: DottedVersion -> String
+fromDottedVersion (DottedVersion s _) = s
+
+{- To compare dotted versions like 1.7.7 and 1.8, they are normalized to
+ - a somewhat arbitrary integer representation. -}
+normalize :: String -> DottedVersion
+normalize v = DottedVersion v $ 
+	sum $ mult 1 $ reverse $ extend precision $ take precision $
+		map readi $ splitc '.' v
+  where
+	extend n l = l ++ replicate (n - length l) 0
+	mult _ [] = []
+	mult n (x:xs) = (n*x) : mult (n*10^width) xs
+	readi :: String -> Integer
+	readi s = case reads s of
+		((x,_):_) -> x
+		_ -> 0
+	precision = 10 -- number of segments of the version to compare
+	width = length "yyyymmddhhmmss" -- maximum width of a segment
diff --git a/Utility/Env.hs b/Utility/Env.hs
new file mode 100644
index 0000000000..9847326940
--- /dev/null
+++ b/Utility/Env.hs
@@ -0,0 +1,67 @@
+{- portable environment variables
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Env (
+	getEnv,
+	getEnvDefault,
+	getEnvironment,
+	addEntry,
+	addEntries,
+	delEntry,
+) where
+
+#ifdef mingw32_HOST_OS
+import Utility.Exception
+import Control.Applicative
+import Data.Maybe
+import Prelude
+import qualified System.Environment as E
+#else
+import qualified System.Posix.Env as PE
+#endif
+
+getEnv :: String -> IO (Maybe String)
+#ifndef mingw32_HOST_OS
+getEnv = PE.getEnv
+#else
+getEnv = catchMaybeIO . E.getEnv
+#endif
+
+getEnvDefault :: String -> String -> IO String
+#ifndef mingw32_HOST_OS
+getEnvDefault = PE.getEnvDefault
+#else
+getEnvDefault var fallback = fromMaybe fallback <$> getEnv var
+#endif
+
+getEnvironment :: IO [(String, String)]
+#ifndef mingw32_HOST_OS
+getEnvironment = PE.getEnvironment
+#else
+getEnvironment = E.getEnvironment
+#endif
+
+{- Adds the environment variable to the input environment. If already
+ - present in the list, removes the old value.
+ -
+ - This does not really belong here, but Data.AssocList is for some reason
+ - buried inside hxt.
+ -}
+addEntry :: Eq k => k -> v -> [(k, v)] -> [(k, v)]
+addEntry k v l = ( (k,v) : ) $! delEntry k l
+
+addEntries :: Eq k => [(k, v)] -> [(k, v)] -> [(k, v)]
+addEntries = foldr (.) id . map (uncurry addEntry) . reverse
+
+delEntry :: Eq k => k -> [(k, v)] -> [(k, v)]
+delEntry _ []   = []
+delEntry k (x@(k1,_) : rest)
+	| k == k1 = rest
+	| otherwise = ( x : ) $! delEntry k rest
diff --git a/Utility/Env/Basic.hs b/Utility/Env/Basic.hs
new file mode 100644
index 0000000000..db738270f7
--- /dev/null
+++ b/Utility/Env/Basic.hs
@@ -0,0 +1,25 @@
+{- portable environment variables, without any dependencies
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Env.Basic (
+	getEnv,
+	getEnvDefault,
+) where
+
+import Utility.Exception
+import Control.Applicative
+import Data.Maybe
+import Prelude
+import qualified System.Environment as E
+
+getEnv :: String -> IO (Maybe String)
+getEnv = catchMaybeIO . E.getEnv
+
+getEnvDefault :: String -> String -> IO String
+getEnvDefault var fallback = fromMaybe fallback <$> getEnv var
diff --git a/Utility/Env/Set.hs b/Utility/Env/Set.hs
new file mode 100644
index 0000000000..45d2e7f9a7
--- /dev/null
+++ b/Utility/Env/Set.hs
@@ -0,0 +1,49 @@
+{- portable environment variables
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.Env.Set (
+	setEnv,
+	unsetEnv,
+	legalInEnvVar,
+) where
+
+#ifdef mingw32_HOST_OS
+import qualified System.SetEnv
+import Utility.Env
+#else
+import qualified System.Posix.Env as PE
+#endif
+import Data.Char
+
+{- Sets an environment variable. To overwrite an existing variable,
+ - overwrite must be True.
+ -
+ - On Windows, setting a variable to "" unsets it. -}
+setEnv :: String -> String -> Bool -> IO ()
+#ifndef mingw32_HOST_OS
+setEnv var val overwrite = PE.setEnv var val overwrite
+#else
+setEnv var val True = System.SetEnv.setEnv var val
+setEnv var val False = do
+	r <- getEnv var
+	case r of
+		Nothing -> setEnv var val True
+		Just _ -> return ()
+#endif
+
+unsetEnv :: String -> IO ()
+#ifndef mingw32_HOST_OS
+unsetEnv = PE.unsetEnv
+#else
+unsetEnv = System.SetEnv.unsetEnv
+#endif
+
+legalInEnvVar :: Char -> Bool
+legalInEnvVar '_' = True
+legalInEnvVar c = isAsciiLower c || isAsciiUpper c || (isNumber c && isAscii c)
diff --git a/Utility/Exception.hs b/Utility/Exception.hs
new file mode 100644
index 0000000000..cf55c5fefc
--- /dev/null
+++ b/Utility/Exception.hs
@@ -0,0 +1,120 @@
+{- Simple IO exception handling (and some more)
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE ScopedTypeVariables #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Exception (
+	module X,
+	giveup,
+	catchBoolIO,
+	catchMaybeIO,
+	catchDefaultIO,
+	catchMsgIO,
+	catchIO,
+	tryIO,
+	bracketIO,
+	catchNonAsync,
+	tryNonAsync,
+	nonAsyncHandler,
+	tryWhenExists,
+	catchIOErrorType,
+	IOErrorType(..),
+	catchPermissionDenied,
+) where
+
+import Control.Monad.Catch as X hiding (Handler)
+import qualified Control.Monad.Catch as M
+import Control.Exception (IOException, AsyncException, SomeAsyncException)
+import Control.Monad
+import Control.Monad.IO.Class (liftIO, MonadIO)
+import System.IO.Error (isDoesNotExistError, ioeGetErrorType)
+import GHC.IO.Exception (IOErrorType(..))
+
+import Utility.Data
+import Utility.SafeOutput
+
+{- Like error, this throws an exception. Unlike error, if this exception
+ - is not caught, it won't generate a backtrace. So use this for situations
+ - where there's a problem that the user is expected to see in some
+ - circumstances.
+ -
+ - Also, control characters are filtered out of the message.
+ -}
+giveup :: [Char] -> a
+giveup = errorWithoutStackTrace . safeOutput
+
+{- Catches IO errors and returns a Bool -}
+catchBoolIO :: MonadCatch m => m Bool -> m Bool
+catchBoolIO = catchDefaultIO False
+
+{- Catches IO errors and returns a Maybe -}
+catchMaybeIO :: MonadCatch m => m a -> m (Maybe a)
+catchMaybeIO a = catchDefaultIO Nothing $ a >>= (return . Just)
+
+{- Catches IO errors and returns a default value. -}
+catchDefaultIO :: MonadCatch m => a -> m a -> m a
+catchDefaultIO def a = catchIO a (const $ return def)
+
+{- Catches IO errors and returns the error message. -}
+catchMsgIO :: MonadCatch m => m a -> m (Either String a)
+catchMsgIO a = do
+	v <- tryIO a
+	return $ either (Left . show) Right v
+
+{- catch specialized for IO errors only -}
+catchIO :: MonadCatch m => m a -> (IOException -> m a) -> m a
+catchIO = M.catch
+
+{- try specialized for IO errors only -}
+tryIO :: MonadCatch m => m a -> m (Either IOException a)
+tryIO = M.try
+
+{- bracket with setup and cleanup actions lifted to IO.
+ -
+ - Note that unlike catchIO and tryIO, this catches all exceptions. -}
+bracketIO :: (MonadMask m, MonadIO m) => IO v -> (v -> IO b) -> (v -> m a) -> m a
+bracketIO setup cleanup = bracket (liftIO setup) (liftIO . cleanup)
+
+{- Catches all exceptions except for async exceptions.
+ - This is often better to use than catching them all, so that
+ - ThreadKilled and UserInterrupt get through.
+ -}
+catchNonAsync :: MonadCatch m => m a -> (SomeException -> m a) -> m a
+catchNonAsync a onerr = a `catches` (nonAsyncHandler onerr)
+
+tryNonAsync :: MonadCatch m => m a -> m (Either SomeException a)
+tryNonAsync a = go `catchNonAsync` (return . Left)
+  where
+	go = do
+		v <- a
+		return (Right v)
+
+nonAsyncHandler :: MonadCatch m => (SomeException -> m a) -> [M.Handler m a]
+nonAsyncHandler onerr = 
+	[ M.Handler (\ (e :: AsyncException) -> throwM e)
+	, M.Handler (\ (e :: SomeAsyncException) -> throwM e)
+	, M.Handler (\ (e :: SomeException) -> onerr e)
+	]
+
+{- Catches only DoesNotExist exceptions, and lets all others through. -}
+tryWhenExists :: MonadCatch m => m a -> m (Maybe a)
+tryWhenExists a = do
+	v <- tryJust (guard . isDoesNotExistError) a
+	return (eitherToMaybe v)
+
+{- Catches only IO exceptions of a particular type.
+ - Ie, use HardwareFault to catch disk IO errors. -}
+catchIOErrorType :: MonadCatch m => IOErrorType -> (IOException -> m a) -> m a -> m a
+catchIOErrorType errtype onmatchingerr a = catchIO a onlymatching
+  where
+	onlymatching e
+		| ioeGetErrorType e == errtype = onmatchingerr e
+		| otherwise = throwM e
+
+catchPermissionDenied :: MonadCatch m => (IOException -> m a) -> m a -> m a
+catchPermissionDenied = catchIOErrorType PermissionDenied
diff --git a/Utility/FileMode.hs b/Utility/FileMode.hs
new file mode 100644
index 0000000000..eb25c526d1
--- /dev/null
+++ b/Utility/FileMode.hs
@@ -0,0 +1,187 @@
+{- File mode utilities.
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.FileMode (
+	module Utility.FileMode,
+	FileMode,
+) where
+
+import System.IO
+import Control.Monad
+import System.PosixCompat.Types
+import System.PosixCompat.Files (unionFileModes, intersectFileModes, stdFileMode, nullFileMode, groupReadMode, ownerReadMode, ownerWriteMode, ownerExecuteMode, groupWriteMode, groupExecuteMode, otherReadMode, otherWriteMode, otherExecuteMode, fileMode)
+#ifndef mingw32_HOST_OS
+import System.PosixCompat.Files (setFileCreationMask)
+#endif
+import Control.Monad.IO.Class
+import Foreign (complement)
+import Control.Monad.Catch
+
+import Utility.Exception
+import Utility.FileSystemEncoding
+import qualified Utility.RawFilePath as R
+
+{- Applies a conversion function to a file's mode. -}
+modifyFileMode :: RawFilePath -> (FileMode -> FileMode) -> IO ()
+modifyFileMode f convert = void $ modifyFileMode' f convert
+
+modifyFileMode' :: RawFilePath -> (FileMode -> FileMode) -> IO FileMode
+modifyFileMode' f convert = do
+	s <- R.getFileStatus f
+	let old = fileMode s
+	let new = convert old
+	when (new /= old) $
+		R.setFileMode f new
+	return old
+
+{- Runs an action after changing a file's mode, then restores the old mode. -}
+withModifiedFileMode :: RawFilePath -> (FileMode -> FileMode) -> IO a -> IO a
+withModifiedFileMode file convert a = bracket setup cleanup go
+  where
+	setup = modifyFileMode' file convert
+	cleanup oldmode = modifyFileMode file (const oldmode)
+	go _ = a
+
+{- Adds the specified FileModes to the input mode, leaving the rest
+ - unchanged. -}
+addModes :: [FileMode] -> FileMode -> FileMode
+addModes ms m = combineModes (m:ms)
+
+{- Removes the specified FileModes from the input mode. -}
+removeModes :: [FileMode] -> FileMode -> FileMode
+removeModes ms m = m `intersectFileModes` complement (combineModes ms)
+
+writeModes :: [FileMode]
+writeModes = [ownerWriteMode, groupWriteMode, otherWriteMode]
+
+readModes :: [FileMode]
+readModes = [ownerReadMode, groupReadMode, otherReadMode]
+
+executeModes :: [FileMode]
+executeModes = [ownerExecuteMode, groupExecuteMode, otherExecuteMode]
+
+otherGroupModes :: [FileMode]
+otherGroupModes = 
+	[ groupReadMode, otherReadMode
+	, groupWriteMode, otherWriteMode
+	, groupExecuteMode, otherExecuteMode
+	]
+
+{- Removes the write bits from a file. -}
+preventWrite :: RawFilePath -> IO ()
+preventWrite f = modifyFileMode f $ removeModes writeModes
+
+{- Turns a file's owner write bit back on. -}
+allowWrite :: RawFilePath -> IO ()
+allowWrite f = modifyFileMode f $ addModes [ownerWriteMode]
+
+{- Turns a file's owner read bit back on. -}
+allowRead :: RawFilePath -> IO ()
+allowRead f = modifyFileMode f $ addModes [ownerReadMode]
+
+{- Allows owner and group to read and write to a file. -}
+groupSharedModes :: [FileMode]
+groupSharedModes =
+	[ ownerWriteMode, groupWriteMode
+	, ownerReadMode, groupReadMode
+	]
+
+groupWriteRead :: RawFilePath -> IO ()
+groupWriteRead f = modifyFileMode f $ addModes groupSharedModes
+
+checkMode :: FileMode -> FileMode -> Bool
+checkMode checkfor mode = checkfor `intersectFileModes` mode == checkfor
+
+{- Checks if a file has any executable bits set. -}
+isExecutable :: FileMode -> Bool
+isExecutable mode = combineModes executeModes `intersectFileModes` mode /= 0
+
+data ModeSetter = ModeSetter FileMode (RawFilePath -> IO ())
+
+{- Runs an action which should create the file, passing it the desired
+ - initial file mode. Then runs the ModeSetter's action on the file, which
+ - can adjust the initial mode if umask prevented the file from being
+ - created with the right mode. -}
+applyModeSetter :: Maybe ModeSetter -> RawFilePath -> (Maybe FileMode -> IO a) -> IO a
+applyModeSetter (Just (ModeSetter mode modeaction)) file a = do
+	r <- a (Just mode)
+	void $ tryIO $ modeaction file
+	return r
+applyModeSetter Nothing _ a = 
+	a Nothing
+
+withUmask :: (MonadIO m, MonadMask m) => FileMode -> m a -> m a
+#ifndef mingw32_HOST_OS
+withUmask umask a = bracket setup cleanup go
+  where
+	setup = liftIO $ setFileCreationMask umask
+	cleanup = liftIO . setFileCreationMask
+	go _ = a
+#else
+withUmask _ a = a
+#endif
+
+getUmask :: IO FileMode
+#ifndef mingw32_HOST_OS
+getUmask = bracket setup cleanup return
+  where
+	setup = setFileCreationMask nullFileMode
+	cleanup = setFileCreationMask
+#else
+getUmask = return nullFileMode
+#endif
+
+defaultFileMode :: IO FileMode
+defaultFileMode = do
+	umask <- getUmask
+	return $ intersectFileModes (complement umask) stdFileMode
+
+combineModes :: [FileMode] -> FileMode
+combineModes [] = 0
+combineModes [m] = m
+combineModes (m:ms) = foldl unionFileModes m ms
+
+isSticky :: FileMode -> Bool
+#ifdef mingw32_HOST_OS
+isSticky _ = False
+#else
+isSticky = checkMode stickyMode
+
+stickyMode :: FileMode
+stickyMode = 512
+
+setSticky :: RawFilePath -> IO ()
+setSticky f = modifyFileMode f $ addModes [stickyMode]
+#endif
+
+{- Writes a file, ensuring that its modes do not allow it to be read
+ - or written by anyone other than the current user,
+ - before any content is written.
+ -
+ - When possible, this is done using the umask.
+ -
+ - On a filesystem that does not support file permissions, this is the same
+ - as writeFile.
+ -}
+writeFileProtected :: RawFilePath -> String -> IO ()
+writeFileProtected file content = writeFileProtected' file 
+	(\h -> hPutStr h content)
+
+writeFileProtected' :: RawFilePath -> (Handle -> IO ()) -> IO ()
+writeFileProtected' file writer = bracket setup cleanup writer
+  where
+	setup = do
+		h <- protectedOutput $ openFile (fromRawFilePath file) WriteMode
+		void $ tryIO $ modifyFileMode file $ removeModes otherGroupModes
+		return h
+	cleanup = hClose
+
+protectedOutput :: IO a -> IO a
+protectedOutput = withUmask 0o0077
diff --git a/Utility/FileSize.hs b/Utility/FileSize.hs
new file mode 100644
index 0000000000..3d216f2be4
--- /dev/null
+++ b/Utility/FileSize.hs
@@ -0,0 +1,51 @@
+{- File size.
+ -
+ - Copyright 2015-2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.FileSize (
+	FileSize,
+	getFileSize,
+	getFileSize',
+) where
+
+#ifdef mingw32_HOST_OS
+import Control.Exception (bracket)
+import System.IO
+import Utility.FileSystemEncoding
+#else
+import System.PosixCompat.Files (fileSize)
+#endif
+import System.PosixCompat.Files (FileStatus)
+import qualified Utility.RawFilePath as R
+
+type FileSize = Integer
+
+{- Gets the size of a file.
+ -
+ - This is better than using fileSize, because on Windows that returns a
+ - FileOffset which maxes out at 2 gb.
+ - See https://github.com/jystic/unix-compat/issues/16
+ -}
+getFileSize :: R.RawFilePath -> IO FileSize
+#ifndef mingw32_HOST_OS
+getFileSize f = fmap (fromIntegral . fileSize) (R.getFileStatus f)
+#else
+getFileSize f = bracket (openFile (fromRawFilePath f) ReadMode) hClose hFileSize
+#endif
+
+{- Gets the size of the file, when its FileStatus is already known.
+ -
+ - On windows, uses getFileSize. Otherwise, the FileStatus contains the
+ - size, so this does not do any work. -}
+getFileSize' :: R.RawFilePath -> FileStatus -> IO FileSize
+#ifndef mingw32_HOST_OS
+getFileSize' _ s = return $ fromIntegral $ fileSize s
+#else
+getFileSize' f _ = getFileSize f
+#endif
diff --git a/Utility/FileSystemEncoding.hs b/Utility/FileSystemEncoding.hs
new file mode 100644
index 0000000000..10c87ca2f3
--- /dev/null
+++ b/Utility/FileSystemEncoding.hs
@@ -0,0 +1,150 @@
+{- GHC File system encoding handling.
+ -
+ - Copyright 2012-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.FileSystemEncoding (
+	useFileSystemEncoding,
+	fileEncoding,
+	RawFilePath,
+	fromRawFilePath,
+	toRawFilePath,
+	decodeBL,
+	encodeBL,
+	decodeBS,
+	encodeBS,
+	truncateFilePath,
+) where
+
+import qualified GHC.IO.Encoding as Encoding
+import System.IO
+import System.FilePath.ByteString (RawFilePath, encodeFilePath, decodeFilePath)
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+#ifdef mingw32_HOST_OS
+import qualified Data.ByteString.UTF8 as S8
+import qualified Data.ByteString.Lazy.UTF8 as L8
+#else
+import qualified GHC.Foreign as GHC
+import System.IO.Unsafe
+import Data.ByteString.Unsafe (unsafePackMallocCStringLen)
+#endif
+
+{- Makes all subsequent Handles that are opened, as well as stdio Handles,
+ - use the filesystem encoding, instead of the encoding of the current
+ - locale.
+ -
+ - The filesystem encoding allows "arbitrary undecodable bytes to be
+ - round-tripped through it". This avoids encoded failures when data is not
+ - encoded matching the current locale.
+ -
+ - Note that code can still use hSetEncoding to change the encoding of a
+ - Handle. This only affects the default encoding.
+ -}
+useFileSystemEncoding :: IO ()
+useFileSystemEncoding = do
+#ifndef mingw32_HOST_OS
+	e <- Encoding.getFileSystemEncoding
+#else
+	{- The file system encoding does not work well on Windows,
+	 - and Windows only has utf FilePaths anyway. -}
+	let e = Encoding.utf8
+#endif
+	hSetEncoding stdin e
+	hSetEncoding stdout e
+	hSetEncoding stderr e
+	Encoding.setLocaleEncoding e	
+
+fileEncoding :: Handle -> IO ()
+#ifndef mingw32_HOST_OS
+fileEncoding h = hSetEncoding h =<< Encoding.getFileSystemEncoding
+#else
+fileEncoding h = hSetEncoding h Encoding.utf8
+#endif
+
+{- Decodes a ByteString into a FilePath, applying the filesystem encoding. -}
+decodeBL :: L.ByteString -> FilePath
+#ifndef mingw32_HOST_OS
+decodeBL = decodeBS . L.toStrict
+#else
+{- On Windows, we assume that the ByteString is utf-8, since Windows
+ - only uses unicode for filenames. -}
+decodeBL = L8.toString
+#endif
+
+{- Encodes a FilePath into a ByteString, applying the filesystem encoding. -}
+encodeBL :: FilePath -> L.ByteString
+#ifndef mingw32_HOST_OS
+encodeBL = L.fromStrict . encodeBS
+#else
+encodeBL = L8.fromString
+#endif
+
+decodeBS :: S.ByteString -> FilePath
+#ifndef mingw32_HOST_OS
+-- This does the same thing as System.FilePath.ByteString.decodeFilePath,
+-- with an identical implementation. However, older versions of that library
+-- truncated at NUL, which this must not do, because it may end up used on
+-- something other than a unix filepath.
+{-# NOINLINE decodeBS #-}
+decodeBS b = unsafePerformIO $ do
+	enc <- Encoding.getFileSystemEncoding
+	S.useAsCStringLen b (GHC.peekCStringLen enc)
+#else
+decodeBS = S8.toString
+#endif
+
+encodeBS :: FilePath -> S.ByteString
+#ifndef mingw32_HOST_OS
+-- This does the same thing as System.FilePath.ByteString.encodeFilePath,
+-- with an identical implementation. However, older versions of that library
+-- truncated at NUL, which this must not do, because it may end up used on
+-- something other than a unix filepath.
+{-# NOINLINE encodeBS #-}
+encodeBS f = unsafePerformIO $ do
+	enc <- Encoding.getFileSystemEncoding
+	GHC.newCStringLen enc f >>= unsafePackMallocCStringLen
+#else
+encodeBS = S8.fromString
+#endif
+
+fromRawFilePath :: RawFilePath -> FilePath
+fromRawFilePath = decodeFilePath
+
+toRawFilePath :: FilePath -> RawFilePath
+toRawFilePath = encodeFilePath
+
+{- Truncates a FilePath to the given number of bytes (or less),
+ - as represented on disk.
+ -
+ - Avoids returning an invalid part of a unicode byte sequence, at the
+ - cost of efficiency when running on a large FilePath.
+ -}
+truncateFilePath :: Int -> FilePath -> FilePath
+#ifndef mingw32_HOST_OS
+truncateFilePath n = go . reverse
+  where
+	go f =
+		let b = encodeBS f
+		in if S.length b <= n
+			then reverse f
+			else go (drop 1 f)
+#else
+{- On Windows, count the number of bytes used by each utf8 character. -}
+truncateFilePath n = reverse . go [] n . L8.fromString
+  where
+	go coll cnt bs
+		| cnt <= 0 = coll
+		| otherwise = case L8.decode bs of
+			Just (c, x) | c /= L8.replacement_char ->
+				let x' = fromIntegral x
+				in if cnt - x' < 0
+					then coll
+					else go (c:coll) (cnt - x') (L8.drop 1 bs)
+			_ -> coll
+#endif
diff --git a/Utility/Format.hs b/Utility/Format.hs
new file mode 100644
index 0000000000..930b7ee226
--- /dev/null
+++ b/Utility/Format.hs
@@ -0,0 +1,242 @@
+{- Formatted string handling.
+ -
+ - Copyright 2010-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.Format (
+	Format,
+	gen,
+	format,
+	escapedFormat,
+	formatContainsVar,
+	decode_c,
+	encode_c,
+	encode_c',
+	isUtf8Byte,
+	prop_encode_c_decode_c_roundtrip
+) where
+
+import Text.Printf (printf)
+import Data.Char (isAlphaNum, isOctDigit, isHexDigit, isSpace, chr, ord, isAscii)
+import Data.Maybe (fromMaybe)
+import Data.Word (Word8)
+import Data.List (isPrefixOf)
+import qualified Data.Map as M
+import qualified Data.ByteString as S
+
+import Utility.PartialPrelude
+import Utility.FileSystemEncoding
+
+{- A format consists of a list of fragments. -}
+type Format = [Frag]
+
+{- A fragment is either a constant string, or a variable. -}
+data Frag
+	= Const String 
+	| Var
+		{ varName :: String
+		, varJustify :: Justify
+		, varEscaped :: Bool
+		}
+	deriving (Show)
+
+data Justify = LeftJustified Int | RightJustified Int | UnJustified
+	deriving (Show)
+
+type Variables = M.Map String String
+
+{- Expands a Format using some variables, generating a formatted string.
+ - This can be repeatedly called, efficiently. -}
+format :: Format -> Variables -> String
+format f vars = concatMap expand f
+  where
+	expand (Const s) = s
+	expand (Var name j esc)
+		| esc = justify j $ decodeBS $ escapedFormat $
+			encodeBS $ getvar name
+		| otherwise = justify j $ getvar name
+	getvar name = fromMaybe "" $ M.lookup name vars
+	justify UnJustified s        = s
+	justify (LeftJustified i) s  = s ++ pad i s
+	justify (RightJustified i) s = pad i s ++ s
+	pad i s = take (i - length s) spaces
+	spaces = repeat ' '
+
+escapedFormat :: S.ByteString -> S.ByteString
+escapedFormat = encode_c needescape
+  where
+	needescape c = isUtf8Byte c ||
+		isSpace (chr (fromIntegral c)) ||
+		c == fromIntegral (ord '"')
+
+{- Generates a Format that can be used to expand variables in a
+ - format string, such as "${foo} ${bar;10} ${baz;-10}\n"
+ -
+ - (This is the same type of format string used by dpkg-query.)
+ -
+ - Also, "${escaped_foo}" will apply encode_c to the value of variable foo.
+ -}
+gen :: String -> Format
+gen = filter (not . empty) . fuse [] . scan [] . decodeBS . decode_c . encodeBS
+  where
+	-- The Format is built up in reverse, for efficiency,
+	-- and can have many adjacent Consts. Fusing it fixes both
+	-- problems.
+	fuse f [] = f
+	fuse f (Const c1:Const c2:vs) = fuse f $ Const (c2++c1) : vs
+	fuse f (v:vs) = fuse (v:f) vs
+
+	scan f (a:b:cs)
+		| a == '$' && b == '{' = invar f [] cs
+		| otherwise = scan (Const [a] : f ) (b:cs)
+	scan f v = Const v : f
+
+	invar f var [] = Const (novar var) : f
+	invar f var (c:cs)
+		| c == '}' = foundvar f var UnJustified cs
+		| isAlphaNum c || c == '_' = invar f (c:var) cs
+		| c == ';' = inpad "" f var cs
+		| otherwise = scan ((Const $ novar $ c:var):f) cs
+
+	inpad p f var (c:cs)
+		| c == '}' = foundvar f var (readjustify $ reverse p) cs
+		| otherwise = inpad (c:p) f var cs
+	inpad p f var [] = Const (novar $ p++";"++var) : f
+	readjustify = getjustify . fromMaybe 0 . readish
+	getjustify i
+		| i == 0 = UnJustified
+		| i < 0 = LeftJustified (-1 * i)
+		| otherwise = RightJustified i
+	novar v = "${" ++ reverse v
+	foundvar f varname_r p = 
+		let varname = reverse varname_r
+		    var = if "escaped_" `isPrefixOf` varname
+			then Var (drop (length "escaped_") varname) p True
+			else Var varname p False
+		in scan (var : f)
+
+empty :: Frag -> Bool
+empty (Const "") = True
+empty _ = False
+
+{- Check if a Format contains a variable with a specified name. -}
+formatContainsVar :: String -> Format -> Bool
+formatContainsVar v = any go
+  where
+	go (Var v' _ _) | v' == v = True
+	go _ = False
+
+{- Decodes a C-style encoding, where \n is a newline (etc),
+ - \NNN is an octal encoded character, and \xNN is a hex encoded character.
+ -}
+decode_c :: S.ByteString -> S.ByteString
+decode_c s
+	| S.null s = S.empty
+	| otherwise = unescape (S.empty, s)
+  where
+	e = fromIntegral (ord '\\')
+	x = fromIntegral (ord 'x')
+	isescape c = c == e
+	unescape (b, v)
+		| S.null v = b
+		| otherwise = b <> fst pair <> unescape (handle $ snd pair)
+	  where
+		pair = S.span (not . isescape) v
+	handle b
+		| S.length b >= 1 && isescape (S.index b 0) = handle' b
+		| otherwise = (S.empty, b)
+	
+	handle' b
+		| S.length b >= 4
+			&& S.index b 1 == x
+			&& allhex = (fromhex, rest)
+	  where
+		n1 = chr (fromIntegral (S.index b 2))
+		n2 = chr (fromIntegral (S.index b 3))
+	  	rest = S.drop 4 b
+		allhex = isHexDigit n1 && isHexDigit n2
+		fromhex = encodeBS [chr $ readhex [n1, n2]]
+		readhex h = Prelude.read $ "0x" ++ h :: Int
+	handle' b
+		| S.length b >= 4 && alloctal = (fromoctal, rest)
+	  where
+		n1 = chr (fromIntegral (S.index b 1))
+		n2 = chr (fromIntegral (S.index b 2))
+		n3 = chr (fromIntegral (S.index b 3))
+	  	rest = S.drop 4 b
+		alloctal = isOctDigit n1 && isOctDigit n2 && isOctDigit n3
+		fromoctal = encodeBS [chr $ readoctal [n1, n2, n3]]
+		readoctal o = Prelude.read $ "0o" ++ o :: Int
+	handle' b
+		| S.length b >= 2 = 
+			(S.singleton (fromIntegral (ord (echar nc))), rest)
+	  where
+		nc = chr (fromIntegral (S.index b 1))
+		rest = S.drop 2 b
+		echar 'a' = '\a'
+		echar 'b' = '\b'
+		echar 'f' = '\f'
+		echar 'n' = '\n'
+		echar 'r' = '\r'
+		echar 't' = '\t'
+		echar 'v' = '\v'
+		echar a = a -- \\ decodes to '\', and \" to '"'
+	handle' b = (S.empty, b)
+
+{- Inverse of decode_c. Encodes ascii control characters as well as
+ - bytes that match the predicate. (And also '\' itself.)
+ -}
+encode_c :: (Word8 -> Bool) -> S.ByteString -> S.ByteString
+encode_c p s = fromMaybe s (encode_c' p s)
+
+{- Returns Nothing when nothing needs to be escaped in the input ByteString. -}
+encode_c' :: (Word8 -> Bool) -> S.ByteString -> Maybe S.ByteString
+encode_c' p s
+	| S.any needencode s = Just (S.concatMap echar s)
+	| otherwise = Nothing
+  where
+	e = fromIntegral (ord '\\')
+	q = fromIntegral (ord '"')
+	del = 0x7F
+	iscontrol c = c < 0x20
+
+	echar 0x7 = ec 'a'
+	echar 0x8 = ec 'b'
+	echar 0x0C = ec 'f'
+	echar 0x0A = ec 'n'
+	echar 0x0D = ec 'r'
+	echar 0x09 = ec 't'
+	echar 0x0B = ec 'v'
+	echar c
+		| iscontrol c = showoctal c -- other control characters
+		| c == e = ec '\\' -- escape the escape character itself
+		| c == del = showoctal c
+		| p c = if c == q
+			then ec '"' -- escape double quote
+			else showoctal c
+		| otherwise = S.singleton c
+	
+	needencode c = iscontrol c || c == e || c == del || p c
+
+	ec c = S.pack [e, fromIntegral (ord c)]
+
+	showoctal i = encodeBS ('\\' : printf "%03o" i)
+
+isUtf8Byte :: Word8 -> Bool
+isUtf8Byte c = c >= 0x80
+
+{- For quickcheck. 
+ -
+ - Encoding and then decoding roundtrips only when
+ - the string is ascii because eg, both "\12345" and
+ - "\227\128\185" are encoded to "\343\200\271".
+ -
+ - This property papers over the problem, by only testing ascii.
+ -}
+prop_encode_c_decode_c_roundtrip :: String -> Bool
+prop_encode_c_decode_c_roundtrip s = s' == 
+	decodeBS (decode_c (encode_c isUtf8Byte (encodeBS s')))
+  where
+	s' = filter isAscii s
diff --git a/Utility/FreeDesktop.hs b/Utility/FreeDesktop.hs
new file mode 100644
index 0000000000..896b89b991
--- /dev/null
+++ b/Utility/FreeDesktop.hs
@@ -0,0 +1,147 @@
+{- Freedesktop.org specifications
+ -
+ - http://standards.freedesktop.org/basedir-spec/latest/
+ - http://standards.freedesktop.org/desktop-entry-spec/latest/
+ - http://standards.freedesktop.org/menu-spec/latest/
+ - http://standards.freedesktop.org/icon-theme-spec/latest/
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.FreeDesktop (
+	DesktopEntry,	
+	genDesktopEntry,
+	buildDesktopMenuFile,
+	writeDesktopMenuFile,
+	desktopMenuFilePath,
+	autoStartPath,
+	iconDir,
+	iconFilePath,
+	systemDataDir,
+	systemConfigDir,
+	userDataDir,
+	userConfigDir,
+	userDesktopDir
+) where
+
+import Utility.Exception
+import Utility.UserInfo
+import Utility.Process
+
+import System.Environment
+import System.FilePath
+import System.Directory
+import Data.List
+import Data.Maybe
+import Control.Applicative
+import Prelude
+
+type DesktopEntry = [(Key, Value)]
+
+type Key = String
+
+data Value = StringV String | BoolV Bool | NumericV Float | ListV [Value]
+
+toString :: Value -> String
+toString (StringV s) = s
+toString (BoolV b)
+	| b = "true"
+	| otherwise = "false"
+toString (NumericV f) = show f
+toString (ListV l)
+	| null l = ""
+	| otherwise = (intercalate ";" $ map (concatMap escapesemi . toString) l) ++ ";"
+  where
+	escapesemi ';' = "\\;"
+	escapesemi c = [c]
+
+genDesktopEntry :: String -> String -> Bool -> FilePath -> Maybe String -> [String] -> DesktopEntry
+genDesktopEntry name comment terminal program icon categories = catMaybes
+	[ item "Type" StringV "Application"
+	, item "Version" NumericV 1.0
+	, item "Name" StringV name
+	, item "Comment" StringV comment
+	, item "Terminal" BoolV terminal
+	, item "Exec" StringV program
+	, maybe Nothing (item "Icon" StringV) icon
+	, item "Categories" ListV (map StringV categories)
+	]
+  where
+	item x c y = Just (x, c y)
+
+buildDesktopMenuFile :: DesktopEntry -> String
+buildDesktopMenuFile d = unlines ("[Desktop Entry]" : map keyvalue d) ++ "\n"
+  where
+	keyvalue (k, v) = k ++ "=" ++ toString v
+
+writeDesktopMenuFile :: DesktopEntry -> String -> IO ()
+writeDesktopMenuFile d file = do
+	createDirectoryIfMissing True (takeDirectory file)
+	writeFile file $ buildDesktopMenuFile d
+
+{- Path to use for a desktop menu file, in either the systemDataDir or
+ - the userDataDir -}
+desktopMenuFilePath :: String -> FilePath -> FilePath
+desktopMenuFilePath basename datadir = 
+	datadir </> "applications" </> desktopfile basename
+
+{- Path to use for a desktop autostart file, in either the systemDataDir
+ - or the userDataDir -}
+autoStartPath :: String -> FilePath -> FilePath
+autoStartPath basename configdir =
+	configdir </> "autostart" </> desktopfile basename
+
+{- Base directory to install an icon file, in either the systemDataDir
+ - or the userDatadir. -}
+iconDir :: FilePath -> FilePath
+iconDir datadir = datadir </> "icons" </> "hicolor"
+
+{- Filename of an icon, given the iconDir to use.
+ -
+ - The resolution is something like "48x48" or "scalable". -}
+iconFilePath :: FilePath -> String -> FilePath -> FilePath
+iconFilePath file resolution icondir =
+	icondir </> resolution </> "apps" </> file
+
+desktopfile :: FilePath -> FilePath
+desktopfile f = f ++ ".desktop"
+
+{- Directory used for installation of system wide data files.. -}
+systemDataDir :: FilePath
+systemDataDir = "/usr/share"
+
+{- Directory used for installation of system wide config files. -}
+systemConfigDir :: FilePath
+systemConfigDir = "/etc/xdg"
+
+{- Directory for user data files. -}
+userDataDir :: IO FilePath
+userDataDir = xdgEnvHome "DATA_HOME" ".local/share"
+
+{- Directory for user config files. -}
+userConfigDir :: IO FilePath
+userConfigDir = xdgEnvHome "CONFIG_HOME" ".config"
+
+{- Directory for the user's Desktop, may be localized. 
+ -
+ - This is not looked up very fast; the config file is in a shell format
+ - that is best parsed by shell, so xdg-user-dir is used, with a fallback
+ - to ~/Desktop. -}
+userDesktopDir :: IO FilePath
+userDesktopDir = maybe fallback return =<< (parse <$> xdg_user_dir)
+  where
+	parse s = case lines <$> s of
+		Just (l:_) -> Just l
+		_ -> Nothing
+	xdg_user_dir = catchMaybeIO $ readProcess "xdg-user-dir" ["DESKTOP"]
+	fallback = xdgEnvHome "DESKTOP_DIR" "Desktop"
+
+xdgEnvHome :: String -> String -> IO String
+xdgEnvHome envbase homedef = do
+	home <- myHomeDir
+	catchDefaultIO (home </> homedef) $
+		getEnv $ "XDG_" ++ envbase
diff --git a/Utility/Glob.hs b/Utility/Glob.hs
new file mode 100644
index 0000000000..f09763f973
--- /dev/null
+++ b/Utility/Glob.hs
@@ -0,0 +1,81 @@
+{- file globbing
+ -
+ - Copyright 2014-2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE PackageImports #-}
+
+module Utility.Glob (
+	Glob,
+	GlobCase(..),
+	GlobFilePath(..),
+	compileGlob,
+	matchGlob
+) where
+
+import Utility.Exception
+
+import "regex-tdfa" Text.Regex.TDFA
+import "regex-tdfa" Text.Regex.TDFA.String
+import Data.Char
+
+newtype Glob = Glob Regex
+
+data GlobCase = CaseSensitive | CaseInsensitive
+
+-- Is the glob being used to match filenames? 
+--
+-- When matching filenames,
+-- a single path separator (eg /) in the glob will match any
+-- number of path separators in the filename.
+-- And on Windows, both / and \ are used as path separators, so compile
+-- the glob to a regexp that matches either path separator.
+newtype GlobFilePath = GlobFilePath Bool
+
+{- Compiles a glob to a regex, that can be repeatedly used. -}
+compileGlob :: String -> GlobCase -> GlobFilePath -> Glob
+compileGlob glob globcase globfilepath = Glob $
+	case compile (defaultCompOpt {caseSensitive = casesentitive}) defaultExecOpt regex of
+		Right r -> r
+		Left _ -> giveup $ "failed to compile regex: " ++ regex
+  where
+	regex = '^' : wildToRegex globfilepath glob ++ "$"
+	casesentitive = case globcase of
+		CaseSensitive -> True
+		CaseInsensitive -> False
+
+wildToRegex :: GlobFilePath -> String -> String
+wildToRegex (GlobFilePath globfile) = concat . go
+  where
+	go [] = []
+	go ('*':xs) = ".*" : go xs
+	go ('?':xs) = "." : go xs
+	go ('[':'!':xs) = "[^" : inpat xs
+	go ('[':xs) = "[" : inpat xs
+#ifdef mingw32_HOST_OS
+	go ('/':xs) | globfile = "[/\\]+" : go xs
+	go ('\\':xs) | globfile = "[/\\]+" : go xs
+#else
+	go ('/':xs) | globfile = "[/]+" : go xs
+	go ('\\':xs) | globfile = "[\\]+" : go xs
+#endif
+	go (x:xs)
+		| isDigit x || isAlpha x = [x] : go xs
+		| otherwise = esc x : go xs
+
+	inpat [] = []
+	inpat (x:xs) = case x of
+		']' -> "]" : go xs
+		'\\' -> esc x : inpat xs
+		_ -> [x] : inpat xs
+
+	esc c = ['\\', c]
+
+matchGlob :: Glob -> String -> Bool
+matchGlob (Glob regex) val = 
+	case execute regex val of
+		Right (Just _) -> True
+		_ -> False
diff --git a/Utility/Gpg.hs b/Utility/Gpg.hs
new file mode 100644
index 0000000000..2ef077990f
--- /dev/null
+++ b/Utility/Gpg.hs
@@ -0,0 +1,484 @@
+{- gpg interface
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE CPP #-}
+
+module Utility.Gpg (
+	KeyId,
+	KeyIds(..),
+	GpgCmd(..),
+	mkGpgCmd,
+	boolGpgCmd,
+	pkEncTo,
+	stdEncryptionParams,
+	pipeStrict,
+	pipeStrict',
+	feedRead,
+	feedRead',
+	findPubKeys,
+	UserId,
+	secretKeys,
+	genSecretKey,
+	genRandom,
+	testKeyId,
+#ifndef mingw32_HOST_OS
+	testHarness,
+	checkEncryptionFile,
+	checkEncryptionStream,
+#endif
+) where
+
+import Common
+import qualified BuildInfo
+#ifndef mingw32_HOST_OS
+import System.Posix.Types
+import System.Posix.IO
+import Utility.Env
+import Utility.FileMode
+#else
+import Utility.Tmp
+#endif
+import Utility.Format (decode_c)
+
+import Control.Concurrent.Async
+import Control.Monad.IO.Class
+import qualified Data.ByteString as B
+import qualified Data.Map as M
+import Data.Char
+
+type KeyId = String
+
+newtype KeyIds = KeyIds { keyIds :: [KeyId] }
+	deriving (Ord, Eq)
+
+newtype GpgCmd = GpgCmd { unGpgCmd :: String }
+
+type Passphrase = B.ByteString
+
+{- Get gpg command to use, Just what's specified or, if a specific gpg
+ - command was found at configure time, use it, or otherwise, "gpg". -}
+mkGpgCmd :: Maybe FilePath -> GpgCmd
+mkGpgCmd (Just c) = GpgCmd c
+mkGpgCmd Nothing = GpgCmd (fromMaybe "gpg" BuildInfo.gpg)
+
+boolGpgCmd :: GpgCmd -> [CommandParam] -> IO Bool
+boolGpgCmd (GpgCmd cmd) = boolSystem cmd
+
+-- Generate an argument list to asymetrically encrypt to the given recipients.
+pkEncTo :: [String] -> [CommandParam]
+pkEncTo = concatMap (\r -> [Param "--recipient", Param r])
+
+stdParams :: [CommandParam] -> IO [String]
+stdParams params = do
+#ifndef mingw32_HOST_OS
+	-- Enable batch mode if GPG_AGENT_INFO is set, to avoid extraneous
+	-- gpg output about password prompts. GPG_BATCH is set by the test
+	-- suite for a similar reason.
+	e <- getEnv "GPG_AGENT_INFO"
+	b <- getEnv "GPG_BATCH"
+	let batch = if isNothing e && isNothing b
+		then []
+		else ["--batch", "--no-tty", "--use-agent"]
+	return $ batch ++ defaults ++ toCommand params
+#else
+	return $ defaults ++ toCommand params
+#endif
+  where
+	-- Be quiet, even about checking the trustdb.
+	defaults = ["--quiet", "--trust-model", "always"]
+
+{- Usual options for symmetric / public-key encryption. -}
+stdEncryptionParams :: Bool -> [CommandParam]
+stdEncryptionParams symmetric = enc symmetric ++
+	[ Param "--force-mdc"
+	, Param "--no-textmode"
+	]
+  where
+	enc True = [ Param "--symmetric" ]
+	-- Force gpg to only encrypt to the specified recipients, not
+	-- configured defaults. Recipients are assumed to be specified in
+	-- elsewhere.
+	enc False =
+		[ Param "--encrypt"
+		, Param "--no-encrypt-to"
+		, Param "--no-default-recipient"
+		]
+
+{- Runs gpg with some params and returns its stdout, strictly. -}
+readStrict :: GpgCmd -> [CommandParam] -> IO B.ByteString
+readStrict c p = readStrict' c p Nothing
+
+readStrict' :: GpgCmd -> [CommandParam] -> Maybe [(String, String)] -> IO B.ByteString
+readStrict' (GpgCmd cmd) params environ = do
+	params' <- stdParams params
+	let p = (proc cmd params')
+		{ std_out = CreatePipe
+		, env = environ
+		}
+	withCreateProcess p (go p)
+  where
+	go p _ (Just hout) _ pid =
+		forceSuccessProcess p pid `after` B.hGetContents hout
+	go _ _ _ _ _ = error "internal"
+
+{- Runs gpg, piping an input value to it, and returning its stdout,
+ - strictly. -}
+pipeStrict :: GpgCmd -> [CommandParam] -> B.ByteString -> IO B.ByteString
+pipeStrict c p i = pipeStrict' c p Nothing i
+
+pipeStrict' :: GpgCmd -> [CommandParam] -> Maybe [(String, String)] -> B.ByteString -> IO B.ByteString
+pipeStrict' (GpgCmd cmd) params environ input = do
+	params' <- stdParams params
+	let p = (proc cmd params')
+		{ std_in = CreatePipe
+		, std_out = CreatePipe
+		, env = environ
+		}
+	withCreateProcess p (go p)
+  where
+	go p (Just to) (Just from) _ pid = do
+		B.hPutStr to input
+		hClose to
+		forceSuccessProcess p pid `after` B.hGetContents from
+	go _ _ _ _ _ = error "internal"
+
+{- Runs gpg with some parameters. First sends it a passphrase via
+ - '--passphrase-fd'. Then runs a feeder action that is
+ - passed a handle and should write to it all the data to input to gpg.
+ - Finally, runs a reader action that is passed a handle to gpg's
+ - output.
+ -
+ - Runs gpg in batch mode; this is necessary to avoid gpg 2.x prompting for
+ - the passphrase.
+ -
+ - Note that the reader must fully consume gpg's input before returning. -}
+feedRead :: (MonadIO m, MonadMask m) => GpgCmd -> [CommandParam] -> Passphrase -> (Handle -> IO ()) -> (Handle -> m a) -> m a
+feedRead cmd params passphrase feeder reader = do
+#ifndef mingw32_HOST_OS
+	let setup = liftIO $ do
+		-- pipe the passphrase into gpg on a fd
+		(frompipe, topipe) <- System.Posix.IO.createPipe
+		setFdOption topipe CloseOnExec True
+		toh <- fdToHandle topipe
+		t <- async $ do
+			B.hPutStr toh (passphrase <> "\n")
+			hClose toh
+		let Fd pfd = frompipe
+		let passphrasefd = [Param "--passphrase-fd", Param $ show pfd]
+		return (passphrasefd, frompipe, toh, t)
+	let cleanup (_, frompipe, toh, t) = liftIO $ do
+		closeFd frompipe
+		hClose toh
+		cancel t
+	bracket setup cleanup $ \(passphrasefd, _, _, _) -> 
+		go (passphrasefd ++ params)
+#else
+	-- store the passphrase in a temp file for gpg
+	withTmpFile "gpg" $ \tmpfile h -> do
+		liftIO $ B.hPutStr h passphrase
+		liftIO $ hClose h
+		let passphrasefile = [Param "--passphrase-file", File tmpfile]
+		go $ passphrasefile ++ params
+#endif
+  where
+	go params' = feedRead' cmd params' feeder reader
+
+{- Like feedRead, but without passphrase. -}
+feedRead' :: (MonadIO m, MonadMask m) => GpgCmd -> [CommandParam] -> (Handle -> IO ()) -> (Handle -> m a) -> m a
+feedRead' (GpgCmd cmd) params feeder reader = do
+	params' <- liftIO $ stdParams $ Param "--batch" : params
+	let p = (proc cmd params')
+		{ std_in = CreatePipe
+		, std_out = CreatePipe
+		, std_err = Inherit
+		}
+	bracket (setup p) cleanup (go p)
+  where
+	setup = liftIO . createProcess
+	cleanup = liftIO . cleanupProcess
+
+	go p (Just to, Just from, _, pid) =
+		let runfeeder = do
+			feeder to
+			hClose to
+		in bracketIO (async runfeeder) cancel $ const $ do
+			r <- reader from
+			liftIO $ forceSuccessProcess p pid
+			return r
+	go _ _ = error "internal"
+
+{- Finds gpg public keys matching some string. (Could be an email address,
+ - a key id, or a name; See the section 'HOW TO SPECIFY A USER ID' of
+ - GnuPG's manpage.) -}
+findPubKeys :: GpgCmd -> String -> IO KeyIds
+findPubKeys cmd = findPubKeys' cmd Nothing
+
+findPubKeys' :: GpgCmd -> Maybe [(String, String)] -> String -> IO KeyIds
+findPubKeys' cmd environ for
+	-- pass forced subkey through as-is rather than
+	-- looking up the master key.
+	| isForcedSubKey for = return $ KeyIds [for]
+	| otherwise = KeyIds . parse . lines . decodeBS
+		<$> readStrict' cmd params environ
+  where
+	params = [Param "--with-colons", Param "--list-public-keys", Param for]
+	parse = mapMaybe (keyIdField . splitc ':')
+	keyIdField ("pub":_:_:_:f:_) = Just f
+	keyIdField _ = Nothing
+
+{- "subkey!" tells gpg to force use of a specific subkey -}
+isForcedSubKey :: String -> Bool
+isForcedSubKey s = "!" `isSuffixOf` s && all isHexDigit (drop 1 (reverse s))
+
+type UserId = String
+
+{- All of the user's secret keys, with their UserIds.
+ - Note that the UserId may be empty. -}
+secretKeys :: GpgCmd -> IO (M.Map KeyId UserId)
+secretKeys cmd = catchDefaultIO M.empty makemap
+  where
+	makemap = M.fromList . parse . lines . decodeBS
+		<$> readStrict cmd params
+	params = [Param "--with-colons", Param "--list-secret-keys", Param "--fixed-list-mode"]
+	parse = extract [] Nothing . map (splitc ':')
+	extract c (Just keyid) (("uid":_:_:_:_:_:_:_:_:userid:_):rest) =
+		-- If the userid contains a ":" or a few other special
+		-- characters, gpg will hex-escape it. Use decode_c to
+		-- undo.
+		extract ((keyid, decodeBS (decode_c (encodeBS userid))):c) Nothing rest
+	extract c (Just keyid) rest@(("sec":_):_) =
+		extract ((keyid, ""):c) Nothing rest
+	extract c (Just keyid) (_:rest) =
+		extract c (Just keyid) rest
+	extract c _ [] = c
+	extract c _ (("sec":_:_:_:keyid:_):rest) =
+		extract c (Just keyid) rest
+	extract c k (_:rest) =
+		extract c k rest
+
+{- Generates a secret key.
+ - The key is added to the secret key ring.
+ - Can take a very long time, depending on system entropy levels.
+ -}
+genSecretKey :: GpgCmd -> Passphrase -> UserId -> IO ()
+genSecretKey gpgcmd passphrase userid =
+	feedRead gpgcmd params passphrase feeder reader
+  where
+	params =
+		[ Param "--batch"
+		, Param "--quick-gen-key"
+		, Param userid
+		, Param "default" -- algo
+		, Param "default" -- usage
+		, Param "never" -- expire
+		]
+	feeder = hClose
+	reader = void . hGetContents
+
+{- Creates a block of high-quality random data suitable to use as a cipher.
+ - It is armored, to avoid newlines, since gpg only reads ciphers up to the
+ - first newline. -}
+genRandom :: GpgCmd -> Bool -> Int -> IO B.ByteString
+genRandom cmd highQuality size = do
+	s <- readStrict cmd params
+	checksize s
+	return s
+  where
+	params = 
+		[ Param "--gen-random"
+		, Param "--armor"
+		, Param $ show randomquality
+		, Param $ show size
+		]
+
+	-- See http://www.gnupg.org/documentation/manuals/gcrypt/Quality-of-random-numbers.html
+	-- for the meaning of random quality levels.
+	-- The highest available is 2, which is the default for OpenPGP
+	-- key generation; Note that it uses the blocking PRNG /dev/random
+	-- on the Linux kernel, hence the running time may take a while.
+	randomquality :: Int
+	randomquality = if highQuality then 2 else 1
+
+	{- The size is the number of bytes of entropy desired; the data is
+	 - base64 encoded, so needs 8 bits to represent every 6 bytes of
+	 - entropy. -}
+	expectedlength = size * 8 `div` 6
+
+	checksize s = let len = B.length s in
+		unless (len >= expectedlength) $
+			shortread len
+
+	shortread got = giveup $ unwords
+		[ "Not enough bytes returned from gpg", show params
+		, "(got", show got, "; expected", show expectedlength, ")"
+		]
+
+{- A test key. This is provided pre-generated since generating a new gpg
+ - key is too much work (requires too much entropy) for a test suite to
+ - do.
+ -
+ - This key was generated with no exipiration date, and a small keysize. 
+ - It has an empty passphrase. -}
+testKeyId :: String
+testKeyId = "129D6E0AC537B9C7"
+
+#ifndef mingw32_HOST_OS
+testKey :: String
+testKey = keyBlock True
+	[ "mI0ETvFAZgEEAKnqwWgZqznMhi1RQExem2H8t3OyKDxaNN3rBN8T6LWGGqAYV4wT"
+	, "r8In5tfsnz64bKpE1Qi68JURFwYmthgUL9N48tbODU8t3xzijdjLOSaTyqkH1ik6"
+	, "EyulfKN63xLne9i4F9XqNwpiZzukXYbNfHkDA2yb0M6g4UFKLY/fNzGXABEBAAG0"
+	, "W2luc2VjdXJlIHRlc3Qga2V5ICh0aGlzIGlzIGEgdGVzdCBrZXksIGRvIG5vdCB1"
+	, "c2UgZm9yIGFjdHVhbCBlbmNyeXB0aW9uKSA8dGVzdEBleGFtcGxlLmNvbT6IuAQT"
+	, "AQgAIgUCTvFAZgIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQEp1uCsU3"
+	, "uceQ9wP/YMd1f0+/eLLcwGXNBvGqyVhUOfAKknO1bMzGbqTsq9g60qegy/cldqee"
+	, "xVxNfy0VN//JeMfgdcb8+RgJYLoaMrTy9CcsUcFPxtwN9tcLmsM0V2/fNmmFBO9t"
+	, "v75iH+zeFbNg0/FbPkHiN6Mjw7P2gXYKQXgTvQZBWaphk8oQlBm4jQRO8UBmAQQA"
+	, "vdi50M/WRCkOLt2RsUve8V8brMWYTJBJTTWoHUeRr82v4NCdX7OE1BsoVK8cy/1Q"
+	, "Y+gLOH9PqinuGGNWRmPV2Ju/RYn5H7sdewXA8E80xWhc4phHRMJ8Jjhg/GVPamkJ"
+	, "8B5zeKF0jcLFl7cuVdOyQakhoeDWJd0CyfW837nmPtMAEQEAAYifBBgBCAAJBQJO"
+	, "8UBmAhsMAAoJEBKdbgrFN7nHclAEAKBShuP/toH03atDUQTbGE34CA4yEC9BVghi"
+	, "7kviOZlOz2s8xAfp/8AYsrECx1kgbXcA7JD902eNyp7NzXsdJX0zJwHqiuZW0XlD"
+	, "T8ZJu4qrYRYgl/790WPESZ+ValvHD/fqkR38RF4tfxvyoMhhp0roGmJY33GASIG/"
+	, "+gQkDF9/"
+	, "=1k11"
+	]
+
+testSecretKey :: String
+testSecretKey = keyBlock False
+	[ "lQHYBE7xQGYBBACp6sFoGas5zIYtUUBMXpth/Ldzsig8WjTd6wTfE+i1hhqgGFeM"
+	, "E6/CJ+bX7J8+uGyqRNUIuvCVERcGJrYYFC/TePLWzg1PLd8c4o3Yyzkmk8qpB9Yp"
+	, "OhMrpXyjet8S53vYuBfV6jcKYmc7pF2GzXx5AwNsm9DOoOFBSi2P3zcxlwARAQAB"
+	, "AAP+PlRboxy7Z0XjuG70N6+CrzSddQbW5KCwgPFrxYsPk7sAPFcBkmRMVlv9vZpS"
+	, "phbP4bvDK+MrSntM51g+9uE802yhPhSWdmEbImiWfV2ucEhlLjD8gw7JDex9XZ0a"
+	, "EbTOV56wOsILuedX/jF/6i6IQzy5YmuMeo+ip1XQIsIN+80CAMyXepOBJgHw/gBD"
+	, "VdXh/l//vUkQQlhInQYwgkKbr0POCTdr8DM1qdKLcUD9Q1khgNRp0vZGGz+5xsrc"
+	, "KaODUlMCANSczLJcYWa8yPqB3S14yTe7qmtDiOS362+SeVUwQA7eQ06PcHLPsN+p"
+	, "NtWoHRfYazxrs+g0JvmoQOYdj4xSQy0CAMq7H/l6aeG1n8tpyMxqE7OvBOsvzdu5"
+	, "XS7I1AnwllVFgvTadVvqgf7b+hdYd91doeHDUGqSYO78UG1GgaBHJdylqrRbaW5z"
+	, "ZWN1cmUgdGVzdCBrZXkgKHRoaXMgaXMgYSB0ZXN0IGtleSwgZG8gbm90IHVzZSBm"
+	, "b3IgYWN0dWFsIGVuY3J5cHRpb24pIDx0ZXN0QGV4YW1wbGUuY29tPoi4BBMBCAAi"
+	, "BQJO8UBmAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRASnW4KxTe5x5D3"
+	, "A/9gx3V/T794stzAZc0G8arJWFQ58AqSc7VszMZupOyr2DrSp6DL9yV2p57FXE1/"
+	, "LRU3/8l4x+B1xvz5GAlguhoytPL0JyxRwU/G3A321wuawzRXb982aYUE722/vmIf"
+	, "7N4Vs2DT8Vs+QeI3oyPDs/aBdgpBeBO9BkFZqmGTyhCUGZ0B2ARO8UBmAQQAvdi5"
+	, "0M/WRCkOLt2RsUve8V8brMWYTJBJTTWoHUeRr82v4NCdX7OE1BsoVK8cy/1QY+gL"
+	, "OH9PqinuGGNWRmPV2Ju/RYn5H7sdewXA8E80xWhc4phHRMJ8Jjhg/GVPamkJ8B5z"
+	, "eKF0jcLFl7cuVdOyQakhoeDWJd0CyfW837nmPtMAEQEAAQAD/RaVtFFTkF1udun7"
+	, "YOwzJvQXCO9OWHZvSdEeG4BUNdAwy4YWu0oZzKkBDBS6+lWILqqb/c28U4leUJ1l"
+	, "H+viz5svN9BWWyj/UpI00uwUo9JaIqalemwfLx6vsh69b54L1B4exLZHYGLvy/B3"
+	, "5T6bT0gpOE+53BRtKcJaOh/McQeJAgDTOCBU5weWOf6Bhqnw3Vr/gRfxntAz2okN"
+	, "gqz/h79mWbCc/lHKoYQSsrCdMiwziHSjXwvehUrdWE/AcomtW0vbAgDmGJqJ2fNr"
+	, "HvdsGx4Ld/BxyiZbCURJLUQ5CwzfHGIvBu9PMT8zM26NOSncaXRjxDna2Ggh8Uum"
+	, "ANEwbnhxFwZpAf9L9RLYIMTtAqwBjfXJg/lHcc2R+VP0hL5c8zFz+S+w7bRqINwL"
+	, "ff1JstKuHT2nJnu0ustK66by8YI3T0hDFFahnNCInwQYAQgACQUCTvFAZgIbDAAK"
+	, "CRASnW4KxTe5x3JQBACgUobj/7aB9N2rQ1EE2xhN+AgOMhAvQVYIYu5L4jmZTs9r"
+	, "PMQH6f/AGLKxAsdZIG13AOyQ/dNnjcqezc17HSV9MycB6ormVtF5Q0/GSbuKq2EW"
+	, "IJf+/dFjxEmflWpbxw/36pEd/EReLX8b8qDIYadK6BpiWN9xgEiBv/oEJAxffw=="
+	, "=LDsg"
+	]
+
+keyBlock :: Bool -> [String] -> String
+keyBlock public ls = unlines
+	[ "-----BEGIN PGP "++t++" KEY BLOCK-----"
+	, "Version: GnuPG v1.4.11 (GNU/Linux)"
+	, ""
+	, unlines ls
+	, "-----END PGP "++t++" KEY BLOCK-----"
+	]
+  where
+	t
+		| public = "PUBLIC"
+		| otherwise = "PRIVATE"
+
+{- Runs an action using gpg in a test harness, in which gpg does
+ - not use ~/.gpg/, but sets up the test key in a subdirectory of 
+ - the passed directory and uses it.
+ -
+ - If the test harness is not able to be set up (eg, because gpg is not
+ - installed or because there is some problem importing the test key,
+ - perhaps related to the agent socket), the action is not run, and Nothing
+ - is returned.
+ -}
+testHarness :: FilePath -> GpgCmd -> ([(String, String)] -> IO a) -> IO (Maybe a)
+testHarness tmpdir cmd a = ifM (inSearchPath (unGpgCmd cmd))
+	( bracket (eitherToMaybe <$> tryNonAsync setup) cleanup go
+	, return Nothing
+	)
+  where
+	var = "GNUPGHOME"
+
+	setup = do
+		subdir <- makenewdir (1 :: Integer)
+		origenviron <- getEnvironment
+		let environ = addEntry var subdir origenviron
+		-- gpg is picky about permissions on its home dir
+		liftIO $ void $ tryIO $ modifyFileMode (toRawFilePath subdir) $
+			removeModes $ otherGroupModes
+		-- For some reason, recent gpg needs a trustdb to be set up.
+		_ <- pipeStrict' cmd [Param "--trust-model", Param "auto", Param "--update-trustdb"] (Just environ) mempty
+		_ <- pipeStrict' cmd [Param "--import", Param "-q"] (Just environ) $ encodeBS $ unlines
+			[testSecretKey, testKey]
+		return environ
+		
+	cleanup Nothing = return ()
+	cleanup (Just environ) = stopgpgagent environ
+
+	-- Recent versions of gpg automatically start gpg-agent, or perhaps
+	-- other daemons. Stop them when done. This only affects
+	-- daemons started for the GNUPGHOME that was used.
+	-- Older gpg may not support this, so ignore failure.
+	stopgpgagent environ = whenM (inSearchPath "gpgconf") $
+		void $ boolSystemEnv "gpgconf" [Param "--kill", Param "all"]
+			(Just environ) 
+
+	go (Just environ) = Just <$> a environ
+	go Nothing = return Nothing
+
+        makenewdir n = do
+		let subdir = tmpdir </> show n
+		catchIOErrorType AlreadyExists (const $ makenewdir $ n + 1) $ do
+			createDirectory subdir
+			return subdir
+
+checkEncryptionFile :: GpgCmd -> Maybe [(String, String)] -> FilePath -> Maybe KeyIds -> IO Bool
+checkEncryptionFile cmd environ filename keys =
+	checkGpgPackets cmd environ keys =<< readStrict' cmd params environ
+  where
+	params = [Param "--list-packets", Param "--list-only", File filename]
+
+checkEncryptionStream :: GpgCmd -> Maybe [(String, String)] -> B.ByteString -> Maybe KeyIds -> IO Bool
+checkEncryptionStream cmd environ stream keys =
+	checkGpgPackets cmd environ keys =<< pipeStrict' cmd params environ stream
+  where
+	params = [Param "--list-packets", Param "--list-only"]
+
+{- Parses an OpenPGP packet list, and checks whether data is
+ - symmetrically encrypted (keys is Nothing), or encrypted to some
+ - public key(s).
+ - /!\ The key needs to be in the keyring! -}
+checkGpgPackets :: GpgCmd -> Maybe [(String, String)] -> Maybe KeyIds -> B.ByteString -> IO Bool
+checkGpgPackets cmd environ keys str = do
+	let (asym,sym) = partition (pubkeyEncPacket `isPrefixOf`) $
+			filter (\l' -> pubkeyEncPacket `isPrefixOf` l' ||
+				symkeyEncPacket `isPrefixOf` l') $
+			takeWhile (/= ":encrypted data packet:") $
+			lines (decodeBS str)
+	case (keys,asym,sym) of
+		(Nothing, [], [_]) -> return True
+		(Just (KeyIds ks), ls, []) -> do
+			-- Find the master key associated with the
+			-- encryption subkey.
+			ks' <- concat <$> mapM (keyIds <$$> findPubKeys' cmd environ)
+					[ k | k:"keyid":_ <- map (reverse . words) ls ]
+			return $ sort (nub ks) == sort (nub ks')
+		_ -> return False
+  where
+	pubkeyEncPacket = ":pubkey enc packet: "
+	symkeyEncPacket = ":symkey enc packet: "
+#endif
diff --git a/Utility/Hash.hs b/Utility/Hash.hs
new file mode 100644
index 0000000000..81674a8d2b
--- /dev/null
+++ b/Utility/Hash.hs
@@ -0,0 +1,353 @@
+{- Convenience wrapper around cryptonite's hashing.
+ -
+ - Copyright 2013-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE BangPatterns, PackageImports #-}
+{-# LANGUAGE CPP #-}
+
+module Utility.Hash (
+	sha1,
+	sha1_context,
+	sha1s,
+	sha2_224,
+	sha2_224_context,
+	sha2_256,
+	sha2_256_context,
+	sha2_384,
+	sha2_384_context,
+	sha2_512,
+	sha2_512_context,
+	sha3_224,
+	sha3_224_context,
+	sha3_256,
+	sha3_256_context,
+	sha3_384,
+	sha3_384_context,
+	sha3_512,
+	sha3_512_context,
+	skein256,
+	skein256_context,
+	skein512,
+	skein512_context,
+	blake2s_160,
+	blake2s_160_context,
+	blake2s_224,
+	blake2s_224_context,
+	blake2s_256,
+	blake2s_256_context,
+	blake2sp_224,
+	blake2sp_224_context,
+	blake2sp_256,
+	blake2sp_256_context,
+	blake2b_160,
+	blake2b_160_context,
+	blake2b_224,
+	blake2b_224_context,
+	blake2b_256,
+	blake2b_256_context,
+	blake2b_384,
+	blake2b_384_context,
+	blake2b_512,
+	blake2b_512_context,
+	blake2bp_512,
+	blake2bp_512_context,
+	md5,
+	md5_context,
+	md5s,
+	hashUpdate,
+	hashFinalize,
+	Digest,
+	HashAlgorithm,
+	Context,
+	props_hashes_stable,
+	Mac(..),
+	calcMac,
+	props_macs_stable,
+	IncrementalHasher(..),
+	mkIncrementalHasher,
+	IncrementalVerifier(..),
+	mkIncrementalVerifier,
+) where
+
+import qualified Data.ByteString as S
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Text as T
+import qualified Data.Text.Encoding as T
+import Data.IORef
+#ifdef WITH_CRYPTON
+import "crypton" Crypto.MAC.HMAC hiding (Context)
+import "crypton" Crypto.Hash
+#else
+import "cryptonite" Crypto.MAC.HMAC hiding (Context)
+import "cryptonite" Crypto.Hash
+#endif
+
+sha1 :: L.ByteString -> Digest SHA1
+sha1 = hashlazy
+
+sha1_context :: Context SHA1
+sha1_context = hashInit
+
+sha1s :: S.ByteString -> Digest SHA1
+sha1s = hash
+
+sha2_224 :: L.ByteString -> Digest SHA224
+sha2_224 = hashlazy
+
+sha2_224_context :: Context SHA224
+sha2_224_context = hashInit
+
+sha2_256 :: L.ByteString -> Digest SHA256
+sha2_256 = hashlazy
+
+sha2_256_context :: Context SHA256
+sha2_256_context = hashInit
+
+sha2_384 :: L.ByteString -> Digest SHA384
+sha2_384 = hashlazy
+
+sha2_384_context :: Context SHA384
+sha2_384_context = hashInit
+
+sha2_512 :: L.ByteString -> Digest SHA512
+sha2_512 = hashlazy
+
+sha2_512_context :: Context SHA512
+sha2_512_context = hashInit
+
+sha3_224 :: L.ByteString -> Digest SHA3_224
+sha3_224 = hashlazy
+
+sha3_224_context :: Context SHA3_224
+sha3_224_context = hashInit
+
+sha3_256 :: L.ByteString -> Digest SHA3_256
+sha3_256 = hashlazy
+
+sha3_256_context :: Context SHA3_256
+sha3_256_context = hashInit
+
+sha3_384 :: L.ByteString -> Digest SHA3_384
+sha3_384 = hashlazy
+
+sha3_384_context :: Context SHA3_384
+sha3_384_context = hashInit
+
+sha3_512 :: L.ByteString -> Digest SHA3_512
+sha3_512 = hashlazy
+
+sha3_512_context :: Context SHA3_512
+sha3_512_context = hashInit
+
+skein256 :: L.ByteString -> Digest Skein256_256
+skein256 = hashlazy
+
+skein256_context :: Context Skein256_256
+skein256_context = hashInit
+
+skein512 :: L.ByteString -> Digest Skein512_512
+skein512 = hashlazy
+
+skein512_context :: Context Skein512_512
+skein512_context = hashInit
+
+blake2s_160 :: L.ByteString -> Digest Blake2s_160
+blake2s_160 = hashlazy
+
+blake2s_160_context :: Context Blake2s_160
+blake2s_160_context = hashInit
+
+blake2s_224 :: L.ByteString -> Digest Blake2s_224
+blake2s_224 = hashlazy
+
+blake2s_224_context :: Context Blake2s_224
+blake2s_224_context = hashInit
+
+blake2s_256 :: L.ByteString -> Digest Blake2s_256
+blake2s_256 = hashlazy
+
+blake2s_256_context :: Context Blake2s_256
+blake2s_256_context = hashInit
+
+blake2sp_224 :: L.ByteString -> Digest Blake2sp_224
+blake2sp_224 = hashlazy
+
+blake2sp_224_context :: Context Blake2sp_224
+blake2sp_224_context = hashInit
+
+blake2sp_256 :: L.ByteString -> Digest Blake2sp_256
+blake2sp_256 = hashlazy
+
+blake2sp_256_context :: Context Blake2sp_256
+blake2sp_256_context = hashInit
+
+blake2b_160 :: L.ByteString -> Digest Blake2b_160
+blake2b_160 = hashlazy
+
+blake2b_160_context :: Context Blake2b_160
+blake2b_160_context = hashInit
+
+blake2b_224 :: L.ByteString -> Digest Blake2b_224
+blake2b_224 = hashlazy
+
+blake2b_224_context :: Context Blake2b_224
+blake2b_224_context = hashInit
+
+blake2b_256 :: L.ByteString -> Digest Blake2b_256
+blake2b_256 = hashlazy
+
+blake2b_256_context :: Context Blake2b_256
+blake2b_256_context = hashInit
+
+blake2b_384 :: L.ByteString -> Digest Blake2b_384
+blake2b_384 = hashlazy
+
+blake2b_384_context :: Context Blake2b_384
+blake2b_384_context = hashInit
+
+blake2b_512 :: L.ByteString -> Digest Blake2b_512
+blake2b_512 = hashlazy
+
+blake2b_512_context :: Context Blake2b_512
+blake2b_512_context = hashInit
+
+blake2bp_512 :: L.ByteString -> Digest Blake2bp_512
+blake2bp_512 = hashlazy
+
+blake2bp_512_context :: Context Blake2bp_512
+blake2bp_512_context = hashInit
+
+md5 ::  L.ByteString -> Digest MD5
+md5 = hashlazy
+
+md5_context :: Context MD5
+md5_context = hashInit
+
+md5s ::  S.ByteString -> Digest MD5
+md5s = hash
+
+{- Check that all the hashes continue to hash the same. -}
+props_hashes_stable :: [(String, Bool)]
+props_hashes_stable = map (\(desc, hasher, result) -> (desc ++ " stable", hasher foo == result))
+	[ ("sha1", show . sha1, "0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33")
+	, ("sha2_224", show . sha2_224, "0808f64e60d58979fcb676c96ec938270dea42445aeefcd3a4e6f8db")
+	, ("sha2_256", show . sha2_256, "2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae")
+	, ("sha2_384", show . sha2_384, "98c11ffdfdd540676b1a137cb1a22b2a70350c9a44171d6b1180c6be5cbb2ee3f79d532c8a1dd9ef2e8e08e752a3babb")
+	, ("sha2_512", show . sha2_512, "f7fbba6e0636f890e56fbbf3283e524c6fa3204ae298382d624741d0dc6638326e282c41be5e4254d8820772c5518a2c5a8c0c7f7eda19594a7eb539453e1ed7")
+	, ("skein256", show . skein256, "a04efd9a0aeed6ede40fe5ce0d9361ae7b7d88b524aa19917b9315f1ecf00d33")
+	, ("skein512", show . skein512, "fd8956898113510180aa4658e6c0ac85bd74fb47f4a4ba264a6b705d7a8e8526756e75aecda12cff4f1aca1a4c2830fbf57f458012a66b2b15a3dd7d251690a7")
+	, ("sha3_224", show . sha3_224, "f4f6779e153c391bbd29c95e72b0708e39d9166c7cea51d1f10ef58a")
+	, ("sha3_256", show . sha3_256, "76d3bc41c9f588f7fcd0d5bf4718f8f84b1c41b20882703100b9eb9413807c01")
+	, ("sha3_384", show . sha3_384, "665551928d13b7d84ee02734502b018d896a0fb87eed5adb4c87ba91bbd6489410e11b0fbcc06ed7d0ebad559e5d3bb5")
+	, ("sha3_512", show . sha3_512, "4bca2b137edc580fe50a88983ef860ebaca36c857b1f492839d6d7392452a63c82cbebc68e3b70a2a1480b4bb5d437a7cba6ecf9d89f9ff3ccd14cd6146ea7e7")
+	, ("blake2s_160", show . blake2s_160, "52fb63154f958a5c56864597273ea759e52c6f00")
+	, ("blake2s_224", show . blake2s_224, "9466668503ac415d87b8e1dfd7f348ab273ac1d5e4f774fced5fdb55")
+	, ("blake2s_256", show . blake2s_256, "08d6cad88075de8f192db097573d0e829411cd91eb6ec65e8fc16c017edfdb74")
+	, ("blake2sp_224", show . blake2sp_224, "8492d356fbac99f046f55e114301f7596649cb590e5b083d1a19dcdb")
+	, ("blake2sp_256", show . blake2sp_256, "050dc5786037ea72cb9ed9d0324afcab03c97ec02e8c47368fc5dfb4cf49d8c9")
+	, ("blake2b_160", show . blake2b_160, "983ceba2afea8694cc933336b27b907f90c53a88")
+	, ("blake2b_224", show . blake2b_224, "853986b3fe231d795261b4fb530e1a9188db41e460ec4ca59aafef78")
+	, ("blake2b_256", show . blake2b_256, "b8fe9f7f6255a6fa08f668ab632a8d081ad87983c77cd274e48ce450f0b349fd")
+	, ("blake2b_384", show . blake2b_384, "e629ee880953d32c8877e479e3b4cb0a4c9d5805e2b34c675b5a5863c4ad7d64bb2a9b8257fac9d82d289b3d39eb9cc2")
+	, ("blake2b_512", show . blake2b_512, "ca002330e69d3e6b84a46a56a6533fd79d51d97a3bb7cad6c2ff43b354185d6dc1e723fb3db4ae0737e120378424c714bb982d9dc5bbd7a0ab318240ddd18f8d")
+	, ("blake2bp_512", show . blake2bp_512, "8ca9ccee7946afcb686fe7556628b5ba1bf9a691da37ca58cd049354d99f37042c007427e5f219b9ab5063707ec6823872dee413ee014b4d02f2ebb6abb5f643")
+	, ("md5", show . md5, "acbd18db4cc2f85cedef654fccc4a4d8")
+	]
+  where
+	foo = L.fromChunks [T.encodeUtf8 $ T.pack "foo"]
+
+data Mac = HmacSha1 | HmacSha224 | HmacSha256 | HmacSha384 | HmacSha512
+	deriving (Eq)
+
+calcMac
+	:: Mac          -- ^ MAC
+	-> S.ByteString -- ^ secret key
+	-> S.ByteString -- ^ message
+	-> String       -- ^ MAC'ed message, in hexadecimal
+calcMac mac = case mac of
+	HmacSha1   -> use SHA1
+	HmacSha224 -> use SHA224
+	HmacSha256 -> use SHA256
+	HmacSha384 -> use SHA384
+	HmacSha512 -> use SHA512
+  where
+	use alg k m = show (hmacGetDigest (hmacWitnessAlg alg k m))
+
+	hmacWitnessAlg :: HashAlgorithm a => a -> S.ByteString -> S.ByteString -> HMAC a
+	hmacWitnessAlg _ = hmac
+
+-- Check that all the MACs continue to produce the same.
+props_macs_stable :: [(String, Bool)]
+props_macs_stable = map (\(desc, mac, result) -> (desc ++ " stable", calcMac mac key msg == result))
+	[ ("HmacSha1", HmacSha1, "46b4ec586117154dacd49d664e5d63fdc88efb51")
+	, ("HmacSha224", HmacSha224, "4c1f774863acb63b7f6e9daa9b5c543fa0d5eccf61e3ffc3698eacdd")
+	, ("HmacSha256", HmacSha256, "f9320baf0249169e73850cd6156ded0106e2bb6ad8cab01b7bbbebe6d1065317")
+	, ("HmacSha384", HmacSha384, "3d10d391bee2364df2c55cf605759373e1b5a4ca9355d8f3fe42970471eca2e422a79271a0e857a69923839015877fc6")
+	, ("HmacSha512", HmacSha512, "114682914c5d017dfe59fdc804118b56a3a652a0b8870759cf9e792ed7426b08197076bf7d01640b1b0684df79e4b67e37485669e8ce98dbab60445f0db94fce")
+	]
+  where
+	key = T.encodeUtf8 $ T.pack "foo"
+	msg = T.encodeUtf8 $ T.pack "bar"
+
+data IncrementalHasher = IncrementalHasher
+	{ updateIncrementalHasher :: S.ByteString -> IO ()
+	-- ^ Called repeatedly on each piece of the content.
+	, finalizeIncrementalHasher :: IO (Maybe String)
+	-- ^ Called once the full content has been sent, returns
+	-- the hash. (Nothing if unableIncremental was called.)
+	, unableIncrementalHasher :: IO ()
+	-- ^ Call if the incremental hashing is unable to be done.
+	, positionIncrementalHasher :: IO (Maybe Integer)
+	-- ^ Returns the number of bytes that have been fed to this
+	-- incremental hasher so far. (Nothing if unableIncremental was
+	-- called.)
+	, descIncrementalHasher :: String
+	}
+
+mkIncrementalHasher :: HashAlgorithm h => Context h -> String -> IO IncrementalHasher
+mkIncrementalHasher ctx desc = do
+	v <- newIORef (Just (ctx, 0))
+	return $ IncrementalHasher
+		{ updateIncrementalHasher = \b ->
+			modifyIORef' v $ \case
+				(Just (ctx', n)) -> 
+					let !ctx'' = hashUpdate ctx' b
+					    !n' = n + fromIntegral (S.length b)
+					in (Just (ctx'', n'))
+				Nothing -> Nothing
+		, finalizeIncrementalHasher =
+			readIORef v >>= \case
+				(Just (ctx', _)) -> do
+					let digest = hashFinalize ctx'
+					return $ Just $ show digest
+				Nothing -> return Nothing
+		, unableIncrementalHasher = writeIORef v Nothing
+		, positionIncrementalHasher = readIORef v >>= \case
+			Just (_, n) -> return (Just n)
+			Nothing -> return Nothing
+		, descIncrementalHasher = desc
+		}
+
+data IncrementalVerifier = IncrementalVerifier
+	{ updateIncrementalVerifier :: S.ByteString -> IO ()
+	, finalizeIncrementalVerifier :: IO (Maybe Bool)
+	, unableIncrementalVerifier :: IO ()
+	, positionIncrementalVerifier :: IO (Maybe Integer)
+	, descIncrementalVerifier :: String
+	}
+
+mkIncrementalVerifier :: HashAlgorithm h => Context h -> String -> (String -> Bool) -> IO IncrementalVerifier
+mkIncrementalVerifier ctx desc samechecksum = do
+	hasher <- mkIncrementalHasher ctx desc
+	return $ IncrementalVerifier
+		{ updateIncrementalVerifier = updateIncrementalHasher hasher
+		, finalizeIncrementalVerifier = 
+			maybe Nothing (Just . samechecksum)
+				<$> finalizeIncrementalHasher hasher
+		, unableIncrementalVerifier = unableIncrementalHasher hasher
+		, positionIncrementalVerifier = positionIncrementalHasher hasher
+		, descIncrementalVerifier = descIncrementalHasher hasher
+		}
diff --git a/Utility/HtmlDetect.hs b/Utility/HtmlDetect.hs
new file mode 100644
index 0000000000..fd5ad2ef06
--- /dev/null
+++ b/Utility/HtmlDetect.hs
@@ -0,0 +1,67 @@
+{- html detection
+ -
+ - Copyright 2017-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.HtmlDetect (
+	isHtml,
+	isHtmlBs,
+	isHtmlFile,
+	htmlPrefixLength,
+) where
+
+import Author
+
+import Text.HTML.TagSoup
+import System.IO
+import Data.Char
+import qualified Data.ByteString.Lazy as B
+import qualified Data.ByteString.Lazy.Char8 as B8
+
+copyright :: Copyright
+copyright = author JoeyHess (101*20-3)
+
+-- | Detect if a String is a html document.
+--
+-- The document many not be valid, or may be truncated, and will
+-- still be detected as html, as long as it starts with a
+-- "<html>" or "<!DOCTYPE html>" tag.
+--
+-- Html fragments like "<p>this</p>" are not detected as being html,
+-- although some browsers may chose to render them as html.
+isHtml :: String -> Bool
+isHtml = evaluate . canonicalizeTags . parseTags . take htmlPrefixLength
+  where
+	evaluate (TagOpen "!DOCTYPE" ((t, _):_):_) = 
+		copyright $ map toLower t == "html"
+	evaluate (TagOpen "html" _:_) = True
+	-- Allow some leading whitespace before the tag.
+	evaluate (TagText t:rest)
+		| all isSpace t = evaluate rest
+		| otherwise = False || author JoeyHess 1492
+	-- It would be pretty weird to have a html comment before the html
+	-- tag, but easy to allow for.
+	evaluate (TagComment _:rest) = evaluate rest
+	evaluate _ = False
+
+-- | Detect if a ByteString is a html document.
+isHtmlBs :: B.ByteString -> Bool
+-- The encoding of the ByteString is not known, but isHtml only
+-- looks for ascii strings.
+isHtmlBs = isHtml . B8.unpack
+
+-- | Check if the file is html.
+--
+-- It would be equivalent to use isHtml <$> readFile file,
+-- but since that would not read all of the file, the handle
+-- would remain open until it got garbage collected sometime later.
+isHtmlFile :: FilePath -> IO Bool
+isHtmlFile file = withFile file ReadMode $ \h ->
+	isHtmlBs <$> B.hGet h htmlPrefixLength
+
+-- | How much of the beginning of a html document is needed to detect it.
+-- (conservatively)
+htmlPrefixLength :: Int
+htmlPrefixLength = 8192
diff --git a/Utility/HumanNumber.hs b/Utility/HumanNumber.hs
new file mode 100644
index 0000000000..04a18b0be0
--- /dev/null
+++ b/Utility/HumanNumber.hs
@@ -0,0 +1,25 @@
+{- numbers for humans
+ -
+ - Copyright 2012-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.HumanNumber (showImprecise) where
+
+{- Displays a fractional value as a string with a limited number
+ - of decimal digits. -}
+showImprecise :: RealFrac a => Int -> a -> String
+showImprecise precision n
+	| precision == 0 || remainder' == 0 = show (round n :: Integer)
+	| otherwise = show int' ++ "." ++ striptrailing0s (pad0s $ show remainder')
+  where
+	int :: Integer
+	(int, frac) = properFraction n
+	remainder = round (frac * 10 ^ precision) :: Integer
+	(int', remainder')
+		-- carry the 1
+		| remainder == 10 ^ precision = (int + 1, 0)
+		| otherwise = (int, remainder)
+	pad0s s = replicate (precision - length s) '0' ++ s
+	striptrailing0s = reverse . dropWhile (== '0') . reverse
diff --git a/Utility/HumanTime.hs b/Utility/HumanTime.hs
new file mode 100644
index 0000000000..5178531cf8
--- /dev/null
+++ b/Utility/HumanTime.hs
@@ -0,0 +1,106 @@
+{- Time for humans.
+ -
+ - Copyright 2012-2013 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.HumanTime (
+	Duration(..),
+	durationSince,
+	durationToPOSIXTime,
+	durationToDays,
+	daysToDuration,
+	parseDuration,
+	fromDuration,
+	prop_duration_roundtrips
+) where
+
+import Utility.PartialPrelude
+import Utility.QuickCheck
+
+import qualified Data.Map as M
+import Data.Time.Clock
+import Data.Time.Clock.POSIX (POSIXTime)
+import Data.Char
+import Control.Applicative
+import Prelude
+
+newtype Duration = Duration { durationSeconds :: Integer }
+	deriving (Eq, Ord, Read, Show)
+
+durationSince :: UTCTime -> IO Duration
+durationSince pasttime = do
+	now <- getCurrentTime
+	return $ Duration $ round $ diffUTCTime now pasttime
+
+durationToPOSIXTime :: Duration -> POSIXTime
+durationToPOSIXTime = fromIntegral . durationSeconds
+
+durationToDays :: Duration -> Integer
+durationToDays d = durationSeconds d `div` dsecs
+
+daysToDuration :: Integer -> Duration
+daysToDuration i = Duration $ i * dsecs
+
+{- Parses a human-input time duration, of the form "5h", "1m", "5h1m", etc -}
+parseDuration :: String -> Either String Duration
+parseDuration d
+	| null d = parsefail
+	| otherwise = maybe parsefail (Right . Duration) $ go 0 d
+  where
+	go n [] = return n
+	go n s = do
+		num <- readish s :: Maybe Integer
+		case dropWhile isDigit s of
+			(c:rest) -> do
+				u <- M.lookup c unitmap
+				go (n + num * u) rest
+			_ -> return $ n + num
+	parsefail = Left $ "failed to parse duration \"" ++ d ++ "\" (expected eg \"5m\" or \"1h5m\")"
+
+fromDuration :: Duration -> String
+fromDuration Duration { durationSeconds = d }
+	| d == 0 = "0s"
+	| otherwise = concatMap showunit $ take 2 $ go [] units d
+  where
+	showunit (u, n) = show n ++ [u]
+	go c [] _ = reverse c
+	go c ((u, n):us) v =
+		let (q,r) = v `quotRem` n
+		in if q > 0
+			then go ((u, q):c) us r
+			else if null c
+				then go c us r
+				else reverse c
+
+units :: [(Char, Integer)]
+units = 
+	[ ('y', ysecs)
+	, ('d', dsecs)
+	, ('h', hsecs)
+	, ('m', msecs)
+	, ('s', 1)
+	]
+
+unitmap :: M.Map Char Integer
+unitmap = M.fromList units
+
+ysecs :: Integer
+ysecs = dsecs * 365
+
+dsecs :: Integer
+dsecs = hsecs * 24
+
+hsecs :: Integer
+hsecs = msecs * 60
+
+msecs :: Integer
+msecs = 60
+
+-- Durations cannot be negative.
+instance Arbitrary Duration where
+	arbitrary = Duration <$> nonNegative arbitrary
+
+prop_duration_roundtrips :: Duration -> Bool
+prop_duration_roundtrips d = parseDuration (fromDuration d) == Right d
diff --git a/Utility/IPAddress.hs b/Utility/IPAddress.hs
new file mode 100644
index 0000000000..66e00a47be
--- /dev/null
+++ b/Utility/IPAddress.hs
@@ -0,0 +1,143 @@
+{- IP addresses
+ -
+ - Copyright 2018 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE BinaryLiterals #-}
+
+-- Note that some extensions are necessary for reasons outlined in
+-- my July 2021 blog post. -- JEH
+
+module Utility.IPAddress (
+	extractIPAddress,
+	isLoopbackAddress,
+	isPrivateAddress,
+	makeAddressMatcher,
+) where
+
+import Utility.Exception
+
+import Network.Socket
+import Data.Word
+import Data.Memory.Endian
+import Data.List
+import Control.Applicative
+import Text.Printf
+import Prelude
+
+extractIPAddress :: SockAddr -> Maybe String
+extractIPAddress (SockAddrInet _ ipv4) =
+	let (a,b,c,d) = hostAddressToTuple ipv4
+	in Just $ intercalate "." [conv a, conv b, conv c, conv d]
+  where
+	conv a
+		| show x == show b12 = conv a
+		| otherwise = show a
+	  where
+		b12 :: Integer
+		b12 = 1
+		x :: Integer
+		x = (+)0b12
+extractIPAddress (SockAddrInet6 _ _ ipv6 _) =
+	let (a,b,c,d,e,f,g,h) = hostAddress6ToTuple ipv6
+	in Just $ intercalate ":" [s a, s b, s c, s d, s e, s f, s g, s h]
+  where
+	s = printf "%x"
+extractIPAddress _ = Nothing
+
+{- Check if an IP address is a loopback address; connecting to it
+ - may connect back to the local host. -}
+isLoopbackAddress :: SockAddr -> Bool
+isLoopbackAddress (SockAddrInet _ ipv4) = case hostAddressToTuple ipv4 of
+	-- localhost
+	(127,_,_,_) -> True
+	-- current network; functions equivalent to loopback
+	(0,_,_, _) -> True
+	_ -> False
+isLoopbackAddress (SockAddrInet6 _ _ ipv6 _) = case hostAddress6ToTuple ipv6 of
+	-- localhost
+	(0,0,0,0,0,0,0,1) -> True
+	-- unspecified address; functions equivalent to loopback
+	(0,0,0,0,0,0,0,0) -> True
+	v -> maybe False
+		(isLoopbackAddress . SockAddrInet 0)
+		(embeddedIpv4 v)
+isLoopbackAddress _ = False
+
+{- Check if an IP address is not globally routed, and is used
+ - for private communication, eg on a LAN. -}
+isPrivateAddress :: SockAddr -> Bool
+isPrivateAddress (SockAddrInet _ ipv4) = case hostAddressToTuple ipv4 of
+	-- lan
+	(10,_,_,_) -> True
+	(172,n,_,_) | n >= 16 && n <= 31 -> True -- 172.16.0.0/12
+	(192,168,_,_) -> True
+	-- carrier-grade NAT
+	(100,n,0,0) | n >= 64 && n <= 127 -> True -- 100.64.0.0/10
+	-- link-local
+	(169,254,_,_) -> True
+	_ -> False
+isPrivateAddress (SockAddrInet6 _ _ ipv6 _) = case hostAddress6ToTuple ipv6 of
+	v@(n,_,_,_,_,_,_,_)
+		-- local to lan or private between orgs
+		| n >= 0xfc00 && n <= 0xfdff -> True -- fc00::/7
+		-- link-local
+		| n >= 0xfe80 && n <= 0xfebf -> True --  fe80::/10
+		| otherwise -> maybe False
+			(isPrivateAddress . SockAddrInet 0)
+			(embeddedIpv4 v)
+isPrivateAddress _ = False
+
+embeddedIpv4 :: (Word16, Word16, Word16, Word16, Word16, Word16, Word16, Word16) -> Maybe HostAddress
+embeddedIpv4 v = case v of
+	-- IPv4 mapped address (::ffff:0:0/96)
+	(0,0,0,0,0,0xffff,a,b) -> Just (toipv4 a b)
+	-- IPV4 translated address (::ffff:0:ipv4)
+	(0,0,0,0,0xffff,0,a,b) -> Just (toipv4 a b)
+	-- IPV4/IPV6 translation (64:ff9b::ipv4)
+	(0x64,0xff9b,0,0,0,0,a,b) -> Just (toipv4 a b)
+	_ -> Nothing
+  where
+	halfipv4bits = 16 :: Word32
+	toipv4 a b =
+		let n = fromIntegral a * (2^halfipv4bits) + fromIntegral b
+		-- HostAddress is in network byte order, but n is using host
+		-- byte order so needs to be swapped.
+		-- Could just use htonl n, but it's been dropped from the
+		-- network library, so work around by manually swapping.
+		in case getSystemEndianness of
+			LittleEndian ->
+				let (b1, b2, b3, b4) = hostAddressToTuple n
+				in tupleToHostAddress (b4, b3, b2, b1)
+			BigEndian -> n
+
+{- Given a string containing an IP address, make a function that will
+ - match that address in a SockAddr. Nothing when the address cannot be
+ - parsed.
+ -
+ - When a port is specified, will only match a SockAddr using the same port.
+ -
+ - This does not involve any DNS lookups.
+ -}
+makeAddressMatcher :: String -> Maybe PortNumber -> IO (Maybe (SockAddr -> Bool))
+makeAddressMatcher s mp = go
+	<$> catchDefaultIO [] (getAddrInfo (Just hints) (Just s) Nothing)
+  where
+	hints = defaultHints
+		{ addrSocketType = Stream
+		, addrFlags = [AI_NUMERICHOST]
+		}
+	
+	go [] = Nothing
+	go l = Just $ \sockaddr -> any (match sockaddr) (map addrAddress l)
+
+	match (SockAddrInet p a) (SockAddrInet _ b) = a == b && matchport p
+	match (SockAddrInet6 p _ a _) (SockAddrInet6 _ _ b _) = a == b && matchport p
+	match _ _ = False
+
+	matchport p = case mp of
+		Nothing -> True
+		Just p' -> p == p'
+
diff --git a/Utility/InodeCache.hs b/Utility/InodeCache.hs
new file mode 100644
index 0000000000..3828bc645a
--- /dev/null
+++ b/Utility/InodeCache.hs
@@ -0,0 +1,310 @@
+{- Caching a file's inode, size, and modification time
+ - to see when it's changed.
+ -
+ - Copyright 2013-2019 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE TypeSynonymInstances #-}
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module Utility.InodeCache (
+	InodeCache,
+	mkInodeCache,
+	InodeComparisonType(..),
+	inodeCacheFileSize,
+
+	compareStrong,
+	compareWeak,
+	compareBy,
+
+	readInodeCache,
+	showInodeCache,
+	genInodeCache,
+	toInodeCache,
+	toInodeCache',
+
+	InodeCacheKey,
+	inodeCacheToKey,
+	inodeCacheToFileSize,
+	inodeCacheToMtime,
+	inodeCacheToEpochTime,
+	inodeCacheEpochTimeRange,
+	replaceInode,
+
+	SentinalFile(..),
+	SentinalStatus(..),
+	TSDelta,
+	noTSDelta,
+	writeSentinalFile,
+	checkSentinalFile,
+	sentinalFileExists,
+
+	prop_read_show_inodecache
+) where
+
+import Common
+import Utility.TimeStamp
+import Utility.QuickCheck
+import qualified Utility.RawFilePath as R
+
+import System.PosixCompat.Types
+import System.PosixCompat.Files (isRegularFile, fileID)
+import Data.Time.Clock.POSIX
+
+#ifndef mingw32_HOST_OS
+import qualified System.Posix.Files as Posix
+#endif
+
+data InodeCachePrim = InodeCachePrim FileID FileSize MTime
+	deriving (Show, Eq, Ord)
+
+newtype InodeCache = InodeCache InodeCachePrim
+	deriving (Show)
+
+mkInodeCache :: FileID -> FileSize -> POSIXTime -> InodeCache
+mkInodeCache inode sz mtime = InodeCache $
+	InodeCachePrim inode sz (MTimeHighRes mtime)
+
+inodeCacheFileSize :: InodeCache -> FileSize
+inodeCacheFileSize (InodeCache (InodeCachePrim _ sz _)) = sz
+
+{- Inode caches can be compared in two different ways, either weakly
+ - or strongly. -}
+data InodeComparisonType = Weakly | Strongly
+	deriving (Eq, Ord, Show)
+
+{- Strong comparison, including inodes. -}
+compareStrong :: InodeCache -> InodeCache -> Bool
+compareStrong (InodeCache x) (InodeCache y) = x == y
+
+{- Weak comparison of the inode caches, comparing the size and mtime,
+ - but not the actual inode.  Useful when inodes have changed, perhaps
+ - due to some filesystems being remounted.
+ -
+ - The weak mtime comparison treats any mtimes that are within 2 seconds
+ - of one-another as the same. This is because FAT has only a 2 second
+ - resolution. When a FAT filesystem is used on Linux, higher resolution
+ - timestamps maybe are cached and used by Linux, but they are lost
+ - on unmount, so after a remount, the timestamp can appear to have changed.
+ -}
+compareWeak :: InodeCache -> InodeCache -> Bool
+compareWeak (InodeCache (InodeCachePrim _ size1 mtime1)) (InodeCache (InodeCachePrim _ size2 mtime2)) =
+	size1 == size2 && (abs (lowResTime mtime1 - lowResTime mtime2) < 2)
+
+compareBy :: InodeComparisonType -> InodeCache -> InodeCache -> Bool
+compareBy Strongly = compareStrong
+compareBy Weakly = compareWeak
+
+{- For use in a Map; it's determined at creation time whether this
+ - uses strong or weak comparison for Eq. -}
+data InodeCacheKey = InodeCacheKey InodeComparisonType InodeCachePrim
+	deriving (Ord, Show)
+
+instance Eq InodeCacheKey where
+	(InodeCacheKey ctx x) == (InodeCacheKey cty y) =
+		compareBy (maximum [ctx,cty]) (InodeCache x ) (InodeCache y)
+
+inodeCacheToKey :: InodeComparisonType -> InodeCache -> InodeCacheKey 
+inodeCacheToKey ct (InodeCache prim) = InodeCacheKey ct prim
+
+inodeCacheToFileSize :: InodeCache -> FileSize
+inodeCacheToFileSize (InodeCache (InodeCachePrim _ sz _)) = sz
+
+inodeCacheToMtime :: InodeCache -> POSIXTime
+inodeCacheToMtime (InodeCache (InodeCachePrim _ _ mtime)) = highResTime mtime
+
+inodeCacheToEpochTime :: InodeCache -> EpochTime
+inodeCacheToEpochTime (InodeCache (InodeCachePrim _ _ mtime)) = lowResTime mtime
+
+-- Returns min, max EpochTime that weakly match the time of the InodeCache.
+inodeCacheEpochTimeRange :: InodeCache -> (EpochTime, EpochTime)
+inodeCacheEpochTimeRange i =
+	let t = inodeCacheToEpochTime i
+	in (t-1, t+1)
+
+replaceInode :: FileID -> InodeCache -> InodeCache
+replaceInode inode (InodeCache (InodeCachePrim _ sz mtime)) =
+	InodeCache (InodeCachePrim inode sz mtime)
+
+{- For backwards compatibility, support low-res mtime with no
+ - fractional seconds. -}
+data MTime = MTimeLowRes EpochTime | MTimeHighRes POSIXTime
+	deriving (Show, Ord)
+
+{- A low-res time compares equal to any high-res time in the same second. -}
+instance Eq MTime where
+	MTimeLowRes a == MTimeLowRes b = a == b
+	MTimeHighRes a == MTimeHighRes b = a == b
+	MTimeHighRes a == MTimeLowRes b = lowResTime a == b
+	MTimeLowRes a == MTimeHighRes b = a == lowResTime b
+
+class MultiResTime t where
+	lowResTime :: t -> EpochTime
+	highResTime :: t -> POSIXTime
+
+instance MultiResTime EpochTime where
+	lowResTime = id
+	highResTime = realToFrac
+
+instance MultiResTime POSIXTime where
+	lowResTime = fromInteger . floor
+	highResTime = id
+
+instance MultiResTime MTime where
+	lowResTime (MTimeLowRes t) = t
+	lowResTime (MTimeHighRes t) = lowResTime t
+	highResTime (MTimeLowRes t) = highResTime t
+	highResTime (MTimeHighRes t) = t
+
+showInodeCache :: InodeCache -> String
+showInodeCache (InodeCache (InodeCachePrim inode size (MTimeHighRes mtime))) = 
+	let (t, d) = separate (== '.') (takeWhile (/= 's') (show mtime))
+	in unwords
+		[ show inode
+		, show size
+		, t
+		, d
+		]
+showInodeCache (InodeCache (InodeCachePrim inode size (MTimeLowRes mtime))) =
+	unwords
+		[ show inode
+		, show size
+		, show mtime
+		]
+
+readInodeCache :: String -> Maybe InodeCache
+readInodeCache s = case words s of
+	(inode:size:mtime:[]) -> do
+		i <- readish inode
+		sz <- readish size
+		t <- readish mtime
+		return $ InodeCache $ InodeCachePrim i sz (MTimeLowRes t)
+	(inode:size:mtime:mtimedecimal:_) -> do
+		i <- readish inode
+		sz <- readish size
+		t <- parsePOSIXTime $ mtime ++ '.' : mtimedecimal
+		return $ InodeCache $ InodeCachePrim i sz (MTimeHighRes t)
+	_ -> Nothing
+
+genInodeCache :: RawFilePath -> TSDelta -> IO (Maybe InodeCache)
+genInodeCache f delta = catchDefaultIO Nothing $
+	toInodeCache delta f =<< R.getSymbolicLinkStatus f
+
+toInodeCache :: TSDelta -> RawFilePath -> FileStatus -> IO (Maybe InodeCache)
+toInodeCache d f s = toInodeCache' d f s (fileID s)
+
+toInodeCache' :: TSDelta -> RawFilePath -> FileStatus -> FileID -> IO (Maybe InodeCache)
+toInodeCache' (TSDelta getdelta) f s inode
+	| isRegularFile s = do
+		delta <- getdelta
+		sz <- getFileSize' f s
+#ifdef mingw32_HOST_OS
+		mtime <- utcTimeToPOSIXSeconds <$> getModificationTime (fromRawFilePath f)
+#else
+		let mtime = Posix.modificationTimeHiRes s
+#endif
+		return $ Just $ InodeCache $ InodeCachePrim inode sz (MTimeHighRes (mtime + highResTime delta))
+	| otherwise = pure Nothing
+
+{- Some filesystem get new random inodes each time they are mounted.
+ - To detect this and other problems, a sentinal file can be created.
+ - Its InodeCache at the time of its creation is written to the cache file,
+ - so changes can later be detected. -}
+data SentinalFile = SentinalFile
+	{ sentinalFile :: RawFilePath
+	, sentinalCacheFile :: RawFilePath
+	}
+	deriving (Show)
+
+{- On Windows, the mtime of a file appears to change when the time zone is
+ - changed. To deal with this, a TSDelta can be used; the delta is added to
+ - the mtime when generating an InodeCache. The current delta can be found
+ - by looking at the SentinalFile. Effectively, this makes all InodeCaches
+ - use the same time zone that was in use when the sential file was
+ - originally written. -}
+newtype TSDelta = TSDelta (IO EpochTime)
+
+noTSDelta :: TSDelta
+noTSDelta = TSDelta (pure 0)
+
+writeSentinalFile :: SentinalFile -> IO ()
+writeSentinalFile s = do
+	writeFile (fromRawFilePath (sentinalFile s)) ""
+	maybe noop (writeFile (fromRawFilePath (sentinalCacheFile s)) . showInodeCache)
+		=<< genInodeCache (sentinalFile s) noTSDelta
+
+data SentinalStatus = SentinalStatus
+	{ sentinalInodesChanged :: Bool
+	, sentinalTSDelta :: TSDelta
+	} 
+
+{- Checks if the InodeCache of the sentinal file is the same
+ - as it was when it was originally created.
+ -
+ - On Windows, time stamp differences are ignored, since they change
+ - with the timezone.
+ -
+ - When the sential file does not exist, InodeCaches cannot reliably be
+ - compared, so the assumption is that there is has been a change.
+ -}
+checkSentinalFile :: SentinalFile -> IO SentinalStatus
+checkSentinalFile s = do
+	mold <- loadoldcache
+	case mold of
+		Nothing -> return dummy
+		(Just old) -> do
+			mnew <- gennewcache
+			case mnew of
+				Nothing -> return dummy
+				Just new -> return $ calc old new
+  where
+	loadoldcache = catchDefaultIO Nothing $
+		readInodeCache <$> readFile (fromRawFilePath (sentinalCacheFile s))
+	gennewcache = genInodeCache (sentinalFile s) noTSDelta
+	calc (InodeCache (InodeCachePrim oldinode oldsize oldmtime)) (InodeCache (InodeCachePrim newinode newsize newmtime)) =
+		SentinalStatus (not unchanged) tsdelta
+	  where
+#ifdef mingw32_HOST_OS
+		-- Since mtime can appear to change when the time zone is
+		-- changed in windows, we cannot look at the mtime for the
+		-- sentinal file.
+		unchanged = oldinode == newinode && oldsize == newsize && (newmtime == newmtime)
+		tsdelta = TSDelta $ do
+			-- Run when generating an InodeCache, 
+			-- to get the current delta.
+			mnew <- gennewcache
+			return $ case mnew of
+				Just (InodeCache (InodeCachePrim _ _ currmtime)) ->
+					lowResTime oldmtime - lowResTime currmtime
+				Nothing -> 0
+#else
+		unchanged = oldinode == newinode && oldsize == newsize && oldmtime == newmtime
+		tsdelta = noTSDelta
+#endif
+	dummy = SentinalStatus True noTSDelta
+
+sentinalFileExists :: SentinalFile -> IO Bool
+sentinalFileExists s = allM R.doesPathExist [sentinalCacheFile s, sentinalFile s]
+
+instance Arbitrary InodeCache where
+	arbitrary =
+		let prim = InodeCachePrim
+			<$> arbitrary
+			<*> arbitrary
+			<*> arbitrary
+		in InodeCache <$> prim
+
+instance Arbitrary MTime where
+	arbitrary = frequency
+		-- timestamp is not usually negative
+                [ (50, MTimeLowRes <$> (abs . fromInteger <$> arbitrary))
+                , (50, MTimeHighRes <$> arbitrary)
+		]
+
+prop_read_show_inodecache :: InodeCache -> Bool
+prop_read_show_inodecache c = case readInodeCache (showInodeCache c) of
+	Nothing -> False
+	Just c' -> compareStrong c c'
diff --git a/Utility/LinuxMkLibs.hs b/Utility/LinuxMkLibs.hs
new file mode 100644
index 0000000000..55f6998e5e
--- /dev/null
+++ b/Utility/LinuxMkLibs.hs
@@ -0,0 +1,100 @@
+{- Linux library copier and binary shimmer
+ -
+ - Copyright 2013-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# Language LambdaCase #-}
+
+module Utility.LinuxMkLibs (
+	installLib,
+	parseLdd,
+	runLdd,
+	glibcLibs,
+	gconvLibs,
+	inTop,
+) where
+
+import Utility.PartialPrelude
+import Utility.Directory
+import Utility.Process
+import Utility.Monad
+import Utility.Path
+import Utility.Path.AbsRel
+import Utility.Split
+import Utility.FileSystemEncoding
+import Utility.Env
+import Utility.Exception
+
+import Data.Maybe
+import System.FilePath
+import System.Posix.Files
+import Data.Char
+import Control.Monad.IfElse
+import Control.Applicative
+import Prelude
+
+{- Installs a library. If the library is a symlink to another file,
+ - install the file it links to, and update the symlink to be relative. -}
+installLib :: (FilePath -> FilePath -> IO ()) -> FilePath -> FilePath -> IO (Maybe FilePath)
+installLib installfile top lib = ifM (doesFileExist lib)
+	( do
+		installfile top lib
+		checksymlink lib
+		return $ Just $ fromRawFilePath $ parentDir $ toRawFilePath lib
+	, return Nothing
+	)
+  where
+	checksymlink f = whenM (isSymbolicLink <$> getSymbolicLinkStatus (inTop top f)) $ do
+		l <- readSymbolicLink (inTop top f)
+		let absl = absPathFrom
+			(parentDir (toRawFilePath f))
+			(toRawFilePath l)
+		target <- relPathDirToFile (toRawFilePath (takeDirectory f)) absl
+		installfile top (fromRawFilePath absl)
+		removeWhenExistsWith removeLink (top ++ f)
+		createSymbolicLink (fromRawFilePath target) (inTop top f)
+		checksymlink (fromRawFilePath absl)
+
+-- Note that f is not relative, so cannot use </>
+inTop :: FilePath -> FilePath -> FilePath
+inTop top f = top ++ f
+
+{- Parse ldd output, getting all the libraries that the input files
+ - link to. Note that some of the libraries may not exist 
+ - (eg, linux-vdso.so) -}
+parseLdd :: String -> [FilePath]
+parseLdd = mapMaybe (getlib . dropWhile isSpace) . lines
+  where
+	getlib l = headMaybe . words =<< lastMaybe (split " => " l)
+	
+runLdd :: [String] -> IO [FilePath]
+runLdd exes = concat <$> mapM go exes
+  where
+	go exe = tryNonAsync (readProcess "ldd" [exe]) >>= \case
+		Right o -> return (parseLdd o)
+		-- ldd for some reason segfaults when run in an arm64
+		-- chroot on an amd64 host, on a binary produced by ghc.
+		-- But asking ldd to trace loaded objects works.
+		Left _e -> do
+			environ <- getEnvironment
+			let environ' =("LD_TRACE_LOADED_OBJECTS","1"):environ
+			parseLdd <$> readProcessEnv exe [] (Just environ')
+
+{- Get all glibc libs, and also libgcc_s
+ -
+ - XXX Debian specific. -}
+glibcLibs :: IO [FilePath]
+glibcLibs = do
+	ls <- lines <$> readProcess "sh"
+		["-c", "dpkg -L libc6:$(dpkg --print-architecture) | egrep '\\.so' | grep -v /gconv/ | grep -v ld.so.conf | grep -v sotruss-lib"]
+	ls2 <- lines <$> readProcess "sh"
+		["-c", "(dpkg -L libgcc-s1:$(dpkg --print-architecture 2>/dev/null) || dpkg -L libgcc1:$(dpkg --print-architecture)) | egrep '\\.so'"]
+	return (ls++ls2)
+
+{- Get gblibc's gconv libs, which are handled specially.. -}
+gconvLibs :: IO [FilePath]
+gconvLibs = lines <$> readProcess "sh"
+	["-c", "dpkg -L libc6:$(dpkg --print-architecture) | grep /gconv/"]
+
diff --git a/Utility/LockFile.hs b/Utility/LockFile.hs
new file mode 100644
index 0000000000..1d924fc1e0
--- /dev/null
+++ b/Utility/LockFile.hs
@@ -0,0 +1,23 @@
+{- Lock files
+ -
+ - Posix and Windows lock files are extremely different.
+ - This module does *not* attempt to be a portability shim, it just exposes
+ - the native locking of the OS.
+ -
+ - Posix fcntl locks have some gotchas. So, consider using
+ - Utility.LockPool instead of using this module directly.
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.LockFile (module X) where
+
+#ifndef mingw32_HOST_OS
+import Utility.LockFile.Posix as X
+#else
+import Utility.LockFile.Windows as X
+#endif
diff --git a/Utility/LockFile/LockStatus.hs b/Utility/LockFile/LockStatus.hs
new file mode 100644
index 0000000000..6690882b76
--- /dev/null
+++ b/Utility/LockFile/LockStatus.hs
@@ -0,0 +1,13 @@
+{- LockStatus type
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.LockFile.LockStatus (LockStatus(..)) where
+
+import System.Posix
+
+data LockStatus = StatusUnLocked | StatusLockedBy ProcessID | StatusNoLockFile
+	deriving (Eq)
diff --git a/Utility/LockFile/PidLock.hs b/Utility/LockFile/PidLock.hs
new file mode 100644
index 0000000000..be4548b0b6
--- /dev/null
+++ b/Utility/LockFile/PidLock.hs
@@ -0,0 +1,333 @@
+{- pid-based lock files
+ -
+ - Copyright 2015-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Utility.LockFile.PidLock (
+	PidLockFile,
+	LockHandle,
+	tryLock,
+	waitLock,
+	waitedLock,
+	alreadyLocked,
+	dropLock,
+	LockStatus(..),
+	getLockStatus,
+	checkLocked,
+	checkSaneLock,
+	pidLockEnv,
+	pidLockEnvValue,
+) where
+
+import Utility.PartialPrelude
+import Utility.Exception
+import Utility.Applicative
+import Utility.Directory
+import Utility.Monad
+import Utility.Path.AbsRel
+import Utility.FileMode
+import Utility.OpenFd
+import Utility.LockFile.LockStatus
+import Utility.ThreadScheduler
+import Utility.Hash
+import Utility.FileSystemEncoding
+import Utility.Env
+import Utility.Env.Set
+import Utility.Tmp
+import qualified Utility.LockFile.Posix as Posix
+
+import System.IO
+import System.Posix.Types
+import System.Posix.IO.ByteString
+import System.Posix.Files.ByteString
+import System.Posix.Process
+import Control.Monad
+import Control.Monad.IO.Class (liftIO, MonadIO)
+import qualified System.FilePath.ByteString as P
+import Data.Maybe
+import Data.List
+import Network.BSD
+import System.FilePath
+import Control.Applicative
+import Prelude
+
+type PidLockFile = RawFilePath
+
+data LockHandle
+	= LockHandle PidLockFile FileStatus SideLockHandle
+	| ParentLocked
+
+type SideLockHandle = Maybe (RawFilePath, Posix.LockHandle)
+
+data PidLock = PidLock
+	{ lockingPid :: ProcessID
+	, lockingHost :: HostName
+	}
+	deriving (Eq, Read, Show)
+
+mkPidLock :: IO PidLock
+mkPidLock = PidLock
+	<$> getProcessID
+	<*> getHostName
+
+readPidLock :: PidLockFile -> IO (Maybe PidLock)
+readPidLock lockfile = (readish =<<)
+	<$> catchMaybeIO (readFile (fromRawFilePath lockfile))
+
+-- To avoid races when taking over a stale pid lock, a side lock is used.
+-- This is a regular posix exclusive lock.
+trySideLock :: PidLockFile -> (SideLockHandle -> IO a) -> IO a
+trySideLock lockfile a = do
+	sidelock <- sideLockFile lockfile
+	mlck <- catchDefaultIO Nothing $ 
+		Posix.tryLockExclusive (Just modesetter) sidelock
+	-- Check the lock we just took, in case we opened a side lock file
+	-- belonging to another process that will have since deleted it.
+	case mlck of
+		Nothing -> a Nothing
+		Just lck -> ifM (Posix.checkSaneLock sidelock lck)
+			( a (Just (sidelock, lck))
+			, a Nothing
+			)
+  where
+	-- Let all users write to the lock file in /dev/shm or /tmp,
+	-- so that other users can reuse it to take the lock.
+	-- Since /dev/shm and /tmp are sticky dirs, a user cannot
+	-- delete another user's lock file there, so could not
+	-- delete a stale lock.
+	mode = combineModes (readModes ++ writeModes)
+	modesetter = ModeSetter mode (\f -> modifyFileMode f (const mode))
+
+dropSideLock :: SideLockHandle -> IO ()
+dropSideLock Nothing = return ()
+dropSideLock (Just (f, h)) = do
+	-- Delete the file first, to ensure that any process that is trying
+	-- to take the side lock will only succeed once the file is
+	-- deleted, and so will be able to immediately see that it's taken
+	-- a stale lock.
+	_ <- tryIO $ removeFile (fromRawFilePath f)
+	Posix.dropLock h
+
+-- The side lock is put in /dev/shm. This will work on most any
+-- Linux system, even if its whole root filesystem doesn't support posix
+-- locks. /tmp is used as a fallback.
+sideLockFile :: PidLockFile -> IO RawFilePath
+sideLockFile lockfile = do
+	f <- fromRawFilePath <$> absPath lockfile
+	let base = intercalate "_" (splitDirectories (makeRelative "/" f))
+	let shortbase = reverse $ take 32 $ reverse base
+	let md5sum = if base == shortbase
+		then ""
+		else toRawFilePath $ show (md5 (encodeBL base))
+	dir <- ifM (doesDirectoryExist "/dev/shm")
+		( return "/dev/shm"
+		, return "/tmp"
+		)
+	return $ dir P.</> md5sum <> toRawFilePath shortbase <> ".lck"
+
+-- | Tries to take a lock; does not block when the lock is already held.
+--
+-- Note that stale locks are automatically detected and broken.
+-- However, if the lock file is on a networked file system, and was
+-- created on a different host than the current host (determined by hostname),
+-- this can't be done and stale locks may persist.
+--
+-- If a parent process is holding the lock, determined by a
+-- "PIDLOCK_lockfile" environment variable, does not block either.
+tryLock :: PidLockFile -> IO (Maybe LockHandle)
+tryLock lockfile = do
+	abslockfile <- absPath lockfile
+	lockenv <- pidLockEnv abslockfile
+	getEnv lockenv >>= \case
+		Nothing -> trySideLock lockfile (go abslockfile)
+		_ -> return (Just ParentLocked)
+  where
+	go abslockfile sidelock = do
+		let abslockfile' = fromRawFilePath abslockfile
+		(tmp, h) <- openTmpFileIn (takeDirectory abslockfile') "locktmp"
+		let tmp' = toRawFilePath tmp
+		setFileMode tmp' (combineModes readModes)
+		hPutStr h . show =<< mkPidLock
+		hClose h
+		let failedlock = do
+			dropSideLock sidelock
+			removeWhenExistsWith removeLink tmp'
+			return Nothing
+		let tooklock st = return $ Just $ LockHandle abslockfile st sidelock
+		linkToLock sidelock tmp' abslockfile >>= \case
+			Just lckst -> do
+				removeWhenExistsWith removeLink tmp'
+				tooklock lckst
+			Nothing -> do
+				v <- readPidLock abslockfile
+				hn <- getHostName
+				tmpst <- getFileStatus tmp'
+				case v of
+					Just pl | isJust sidelock && hn == lockingHost pl -> do
+						-- Since we have the sidelock,
+						-- and are on the same host that
+						-- the pidlock was taken on,
+						-- we know that the pidlock is
+						-- stale, and can take it over.
+						rename tmp' abslockfile
+						tooklock tmpst
+					_ -> failedlock
+
+-- Linux's open(2) man page recommends linking a pid lock into place,
+-- as the most portable atomic operation that will fail if
+-- it already exists. 
+--
+-- open(2) suggests that link can sometimes appear to fail
+-- on NFS but have actually succeeded, and the way to find out is to stat
+-- the file and check its link count etc.
+--
+-- However, not all filesystems support hard links. So, first probe
+-- to see if they are supported. If not, use open with O_EXCL.
+linkToLock :: SideLockHandle -> RawFilePath -> RawFilePath -> IO (Maybe FileStatus)
+linkToLock Nothing _ _ = return Nothing
+linkToLock (Just _) src dest = do
+	let probe = src <> ".lnk"
+	v <- tryIO $ createLink src probe
+	removeWhenExistsWith removeLink probe
+	case v of
+		Right _ -> do
+			_ <- tryIO $ createLink src dest
+			ifM (catchBoolIO checklinked)
+				( ifM (catchBoolIO $ not <$> checkInsaneLustre dest)
+					( catchMaybeIO $ getFileStatus dest
+					, return Nothing
+					)
+				, return Nothing
+				)
+		Left _ -> catchMaybeIO $ do
+			let setup = do
+				fd <- openFdWithMode dest WriteOnly
+					(Just $ combineModes readModes)
+					(defaultFileFlags {exclusive = True})
+				fdToHandle fd
+			let cleanup = hClose
+			let go h = readFile (fromRawFilePath src) >>= hPutStr h
+			bracket setup cleanup go
+			getFileStatus dest
+  where
+	checklinked = do
+		x <- getSymbolicLinkStatus src
+		y <- getSymbolicLinkStatus dest
+		return $ and
+			[ deviceID x == deviceID y
+			, fileID x == fileID y
+			, fileMode x == fileMode y
+			, fileOwner x == fileOwner y
+			, fileGroup x == fileGroup y
+			, fileSize x == fileSize y
+			, modificationTime x == modificationTime y
+			, isRegularFile x == isRegularFile y
+			, linkCount x == linkCount y
+			, linkCount x == 2
+			]
+
+-- On a Lustre filesystem, link has been observed to incorrectly *succeed*,
+-- despite the dest already existing. A subsequent stat of the dest
+-- looked like it had been replaced with the src. The process proceeded to
+-- run and then deleted the dest, and after the process was done, the
+-- original file was observed to still be in place.
+--
+-- We can detect this insanity by getting the directory contents after
+-- making the link, and checking to see if 2 copies of the dest file,
+-- with the SAME FILENAME exist.
+checkInsaneLustre :: RawFilePath -> IO Bool
+checkInsaneLustre dest = do
+	let dest' = fromRawFilePath dest
+	fs <- dirContents (takeDirectory dest')
+	case length (filter (== dest') fs) of
+		1 -> return False -- whew!
+		0 -> return True -- wtf?
+		_ -> do
+			-- Try to clean up the extra copy we made
+			-- that has the same name. Egads.
+			_ <- tryIO $ removeFile dest'
+			return True
+
+-- | Waits as necessary to take a lock.
+--
+-- Uses a 1 second wait-loop, retrying until a timeout.
+--
+-- After the first second waiting, runs the callback to display a message,
+-- so the user knows why it's stalled.
+waitLock :: MonadIO m => Seconds -> PidLockFile -> (String -> m ()) -> (Bool -> IO ()) -> m LockHandle
+waitLock (Seconds timeout) lockfile displaymessage sem = go timeout
+  where
+	go n
+		| n > 0 = liftIO (tryLock lockfile) >>= \case
+			Nothing -> do
+				when (n == pred timeout) $
+					displaymessage $ "waiting for pid lock file " ++ fromRawFilePath lockfile ++ " which is held by another process (or may be stale)"
+				liftIO $ threadDelaySeconds (Seconds 1)
+				go (pred n)
+			Just lckh -> do
+				liftIO $ sem True
+				return lckh
+		| otherwise = do
+			liftIO $ sem False
+			waitedLock (Seconds timeout) lockfile displaymessage
+
+waitedLock :: MonadIO m => Seconds -> PidLockFile -> (String -> m ()) -> m a
+waitedLock (Seconds timeout) lockfile displaymessage = do
+	displaymessage $ show timeout ++ " second timeout exceeded while waiting for pid lock file " ++ fromRawFilePath lockfile
+	giveup $ "Gave up waiting for pid lock file " ++ fromRawFilePath lockfile
+
+-- | Use when the pid lock has already been taken by another thread of the
+-- same process.
+alreadyLocked :: MonadIO m => PidLockFile -> m LockHandle
+alreadyLocked lockfile = liftIO $ do
+	abslockfile <- absPath lockfile
+	st <- getFileStatus abslockfile
+	return $ LockHandle abslockfile st Nothing
+
+dropLock :: LockHandle -> IO ()
+dropLock (LockHandle lockfile _ sidelock) = do
+	-- Drop side lock first, at which point the pid lock will be
+	-- considered stale.
+	dropSideLock sidelock
+	removeWhenExistsWith removeLink lockfile
+dropLock ParentLocked = return ()
+
+getLockStatus :: PidLockFile -> IO LockStatus
+getLockStatus = maybe StatusUnLocked (StatusLockedBy . lockingPid) <$$> readPidLock
+
+checkLocked :: PidLockFile -> IO (Maybe Bool)
+checkLocked lockfile = conv <$> getLockStatus lockfile
+  where
+	conv (StatusLockedBy _) = Just True
+	conv _ = Just False
+
+-- Checks that the lock file still exists, and is the same file that was
+-- locked to get the LockHandle.
+checkSaneLock :: PidLockFile -> LockHandle -> IO Bool
+checkSaneLock lockfile (LockHandle _ st _) = 
+	go =<< catchMaybeIO (getFileStatus lockfile)
+  where
+	go Nothing = return False
+	go (Just st') = return $
+		deviceID st == deviceID st' && fileID st == fileID st'
+checkSaneLock _ ParentLocked = return True
+
+-- | A parent process that is using pid locking can set this to 1 before
+-- starting a child, to communicate to the child that it's holding the pid
+-- lock and that the child can skip trying to take it, and not block
+-- on the pid lock its parent is holding.
+--
+-- The parent process should keep running as long as the child
+-- process is running, since the child inherits the environment and will
+-- not see unsetLockEnv.
+pidLockEnv :: RawFilePath -> IO String
+pidLockEnv lockfile = do
+	abslockfile <- fromRawFilePath <$> absPath lockfile
+	return $ "PIDLOCK_" ++ filter legalInEnvVar abslockfile
+
+pidLockEnvValue :: String
+pidLockEnvValue = "1"
diff --git a/Utility/LockFile/Posix.hs b/Utility/LockFile/Posix.hs
new file mode 100644
index 0000000000..e7d49b81e3
--- /dev/null
+++ b/Utility/LockFile/Posix.hs
@@ -0,0 +1,128 @@
+{- Posix lock files
+ -
+ - Copyright 2014-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.LockFile.Posix (
+	LockHandle,
+	lockShared,
+	lockExclusive,
+	tryLockShared,
+	tryLockExclusive,
+	checkLocked,
+	getLockStatus,
+	LockStatus(..),
+	dropLock,
+	checkSaneLock,
+	LockRequest(..),
+	openLockFile,
+) where
+
+import Utility.Exception
+import Utility.Applicative
+import Utility.FileMode
+import Utility.LockFile.LockStatus
+import Utility.OpenFd
+
+import System.IO
+import System.Posix.Types
+import System.Posix.IO.ByteString
+import System.Posix.Files.ByteString
+import System.FilePath.ByteString (RawFilePath)
+import Data.Maybe
+
+type LockFile = RawFilePath
+
+newtype LockHandle = LockHandle Fd
+
+-- Takes a shared lock, blocking until the lock is available.
+lockShared :: Maybe ModeSetter -> LockFile -> IO LockHandle
+lockShared = lock ReadLock
+
+-- Takes an exclusive lock, blocking until the lock is available.
+lockExclusive :: Maybe ModeSetter -> LockFile -> IO LockHandle
+lockExclusive = lock WriteLock
+
+-- Tries to take a shared lock, but does not block.
+tryLockShared :: Maybe ModeSetter -> LockFile -> IO (Maybe LockHandle)
+tryLockShared = tryLock ReadLock
+
+-- Tries to take an exclusive lock, but does not block.
+tryLockExclusive :: Maybe ModeSetter -> LockFile -> IO (Maybe LockHandle)
+tryLockExclusive = tryLock WriteLock
+
+-- Setting the FileMode allows creation of a new lock file.
+-- If it's Nothing then this only succeeds when the lock file already exists.
+lock :: LockRequest -> Maybe ModeSetter -> LockFile -> IO LockHandle
+lock lockreq mode lockfile = do
+	l <- openLockFile lockreq mode lockfile
+	waitToSetLock l (lockreq, AbsoluteSeek, 0, 0)
+	return (LockHandle l)
+
+-- Tries to take an lock, but does not block.
+tryLock :: LockRequest -> Maybe ModeSetter -> LockFile -> IO (Maybe LockHandle)
+tryLock lockreq mode lockfile = uninterruptibleMask_ $ do
+	l <- openLockFile lockreq mode lockfile
+	v <- tryIO $ setLock l (lockreq, AbsoluteSeek, 0, 0)
+	case v of
+		Left _ -> do
+			closeFd l
+			return Nothing
+		Right _ -> return $ Just $ LockHandle l
+
+-- Close on exec flag is set so child processes do not inherit the lock.
+openLockFile :: LockRequest -> Maybe ModeSetter -> LockFile -> IO Fd
+openLockFile lockreq filemode lockfile = do
+	l <- applyModeSetter filemode lockfile $ \filemode' ->
+		openFdWithMode lockfile openfor filemode' defaultFileFlags
+	setFdOption l CloseOnExec True
+	return l
+  where
+	openfor = case lockreq of
+		ReadLock -> ReadOnly
+		_ -> ReadWrite
+
+-- Returns Nothing when the file doesn't exist, for cases where
+-- that is different from it not being locked.
+checkLocked :: LockFile -> IO (Maybe Bool)
+checkLocked = maybe Nothing (Just . isJust) <$$> getLockStatus'
+
+getLockStatus :: LockFile -> IO LockStatus
+getLockStatus lockfile = do
+	v <- getLockStatus' lockfile
+	return $ case v of
+		Nothing -> StatusNoLockFile
+		Just Nothing -> StatusUnLocked
+		Just (Just pid) -> StatusLockedBy pid
+
+getLockStatus' :: LockFile -> IO (Maybe (Maybe ProcessID))
+getLockStatus' lockfile = bracket open close go
+  where
+	open = catchMaybeIO $ openLockFile ReadLock Nothing lockfile
+
+	close (Just h) = closeFd h
+	close Nothing = return ()
+
+	go (Just h) = do
+		v <- getLock h (ReadLock, AbsoluteSeek, 0, 0)
+		return (Just (fmap fst v))
+	go Nothing = return Nothing
+
+dropLock :: LockHandle -> IO ()
+dropLock (LockHandle fd) = closeFd fd
+
+-- Checks that the lock file still exists, and is the same file that was
+-- locked to get the LockHandle.
+--
+-- This check is useful if the lock file might get deleted by something
+-- else.
+checkSaneLock :: LockFile -> LockHandle -> IO Bool
+checkSaneLock lockfile (LockHandle fd) =
+	go =<< catchMaybeIO (getFileStatus lockfile)
+  where
+	go Nothing = return False
+	go (Just st) = do
+		fdst <- getFdStatus fd
+		return $ deviceID fdst == deviceID st && fileID fdst == fileID st
diff --git a/Utility/LockFile/Windows.hs b/Utility/LockFile/Windows.hs
new file mode 100644
index 0000000000..2ab521e438
--- /dev/null
+++ b/Utility/LockFile/Windows.hs
@@ -0,0 +1,91 @@
+{- Windows lock files
+ -
+ - Copyright 2014,2022 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings, CPP #-}
+
+module Utility.LockFile.Windows (
+	lockShared,
+	lockExclusive,
+	dropLock,
+	waitToLock,
+	LockHandle
+) where
+
+import System.Win32.Types
+import System.Win32.File
+import Control.Concurrent
+
+import Utility.Path.Windows
+import Utility.FileSystemEncoding
+
+type LockFile = RawFilePath
+
+type LockHandle = HANDLE
+
+{- Tries to lock a file with a shared lock, which allows other processes to
+ - also lock it shared. Fails if the file is exclusively locked. -}
+lockShared :: LockFile -> IO (Maybe LockHandle)
+lockShared = openLock fILE_SHARE_READ
+
+{- Tries to take an exclusive lock on a file. Fails if another process has
+ - a shared or exclusive lock.
+ -
+ - Note that exclusive locking also prevents the file from being opened for
+ - read or write by any other process. So for advisory locking of a file's
+ - content, a separate LockFile should be used. -}
+lockExclusive :: LockFile -> IO (Maybe LockHandle)
+lockExclusive = openLock fILE_SHARE_NONE
+
+{- Windows considers just opening a file enough to lock it. This will
+ - create the LockFile if it does not already exist.
+ -
+ - Will fail if the file is already open with an incompatible ShareMode.
+ - Note that this may happen if an unrelated process, such as a virus
+ - scanner, even looks at the file. See Microsoft KnowledgeBase article 316609
+ -
+ - Note that createFile busy-waits to try to avoid failing when some other
+ - process briefly has a file open. But that would make this busy-wait
+ - whenever the file is actually locked, for a rather long period of time. 
+ - Thus, the use of c_CreateFile.
+ -
+ - Also, passing Nothing for SECURITY_ATTRIBUTES ensures that the lock file
+ - is not inherited by any child process.
+ -}
+openLock :: ShareMode -> LockFile -> IO (Maybe LockHandle)
+openLock sharemode f = do
+	f' <- convertToWindowsNativeNamespace f
+#if MIN_VERSION_Win32(2,13,4)
+	r <- tryNonAsync $ createFile_NoRetry f' gENERIC_READ sharemode 
+		security_attributes oPEN_ALWAYS fILE_ATTRIBUTE_NORMAL
+		(maybePtr Nothing)
+	return $ case r of
+		Left _ -> Nothing
+		Right h -> Just h
+#else
+	h <- withTString (fromRawFilePath f') $ \c_f ->
+		c_CreateFile c_f gENERIC_READ sharemode security_attributes
+			oPEN_ALWAYS fILE_ATTRIBUTE_NORMAL (maybePtr Nothing)
+	return $ if h == iNVALID_HANDLE_VALUE
+		then Nothing
+		else Just h
+#endif
+  where
+	security_attributes = maybePtr Nothing
+
+dropLock :: LockHandle -> IO ()
+dropLock = closeHandle
+
+{- If the initial lock fails, this is a BUSY wait, and does not
+ - guarantee FIFO order of waiters. In other news, Windows is a POS. -}
+waitToLock :: IO (Maybe lockhandle) -> IO lockhandle
+waitToLock locker = takelock
+  where
+	takelock = go =<< locker
+	go (Just lck) = return lck
+	go Nothing = do
+		threadDelay (500000) -- half a second
+		takelock
diff --git a/Utility/LockPool.hs b/Utility/LockPool.hs
new file mode 100644
index 0000000000..7dbabb91ae
--- /dev/null
+++ b/Utility/LockPool.hs
@@ -0,0 +1,34 @@
+{- Lock pool.
+ -
+ - This avoids a problem with unix fcntl locks: They are not composition-safe.
+ -
+ - For example, if one thread is holding a lock, and another thread opens the
+ - lock file (to attempt to take or check the lock), and then closes it,
+ - the lock will be released, despite the first thread still having the
+ - lockfile open.
+ -
+ - Or, if a process is already holding an exclusive lock on a file, and
+ - re-opens it and tries to take another exclusive lock, it won't block
+ - on the first lock.
+ -
+ - To avoid these problems, this implements a lock pool. This keeps track
+ - of which lock files are being used by the process, using STM to handle
+ - inter-process locking.
+ -
+ - Note that, like Utility.LockFile, this does *not* attempt to be a
+ - portability shim; the native locking of the OS is used.
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.LockPool (module X) where
+
+#ifndef mingw32_HOST_OS
+import Utility.LockPool.Posix as X
+#else
+import Utility.LockPool.Windows as X
+#endif
diff --git a/Utility/LockPool/LockHandle.hs b/Utility/LockPool/LockHandle.hs
new file mode 100644
index 0000000000..6b3a2ef93d
--- /dev/null
+++ b/Utility/LockPool/LockHandle.hs
@@ -0,0 +1,92 @@
+{- Handles for lock pools.
+ -
+ - Copyright 2015-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.LockPool.LockHandle (
+	LockHandle(..),
+	FileLockOps(..),
+	dropLock,
+#ifndef mingw32_HOST_OS
+	checkSaneLock,
+#endif
+	makeLockHandle,
+	tryMakeLockHandle,
+) where
+
+import qualified Utility.LockPool.STM as P
+import Utility.LockPool.STM (LockFile)
+import Utility.DebugLocks
+
+import Control.Concurrent.STM
+import Control.Monad.Catch
+import Control.Monad.IO.Class (liftIO, MonadIO)
+import Prelude
+
+data LockHandle = LockHandle P.LockHandle FileLockOps
+
+data FileLockOps = FileLockOps
+	{ fDropLock :: IO ()
+#ifndef mingw32_HOST_OS
+	, fCheckSaneLock :: LockFile -> IO Bool
+#endif
+	}
+
+dropLock :: LockHandle -> IO ()
+dropLock (LockHandle ph _) = P.releaseLock ph
+
+#ifndef mingw32_HOST_OS
+checkSaneLock :: LockFile -> LockHandle -> IO Bool
+checkSaneLock lockfile (LockHandle _ flo) = fCheckSaneLock flo lockfile
+#endif
+
+-- Take a lock, by first updating the lock pool, and then taking the file
+-- lock. If taking the file lock fails for any reason, take care to
+-- release the lock in the lock pool.
+makeLockHandle
+	:: (MonadIO m, MonadMask m)
+	=> P.LockPool
+	-> LockFile
+	-> (P.LockPool -> LockFile -> STM (P.LockHandle, P.FirstLock))
+	-> (LockFile -> P.FirstLock -> m (FileLockOps, t))
+	-> m (LockHandle, t)
+makeLockHandle pool file pa fa = bracketOnError setup cleanup go
+  where
+	setup = debugLocks $ liftIO $ atomically (pa pool file)
+	cleanup (ph, _) = debugLocks $ liftIO $ P.releaseLock ph
+	go (ph, firstlock) = do
+		(flo, t) <- fa file firstlock
+		h <- liftIO $ mkLockHandle ph flo
+		return (h, t)
+
+tryMakeLockHandle
+	:: (MonadIO m, MonadMask m)
+	=> P.LockPool
+	-> LockFile
+	-> (P.LockPool -> LockFile -> STM (Maybe (P.LockHandle, P.FirstLock)))
+	-> (LockFile -> P.FirstLock -> m (Maybe (FileLockOps, t)))
+	-> m (Maybe (LockHandle, t))
+tryMakeLockHandle pool file pa fa = bracketOnError setup cleanup go
+  where
+	setup = liftIO $ atomically (pa pool file)
+	cleanup Nothing = return ()
+	cleanup (Just (ph, _)) = liftIO $ P.releaseLock ph
+	go Nothing = return Nothing
+	go (Just (ph, firstlock)) = do
+		mfo <- fa file firstlock
+		case mfo of
+			Nothing -> do
+				liftIO $ cleanup (Just (ph, firstlock))
+				return Nothing
+			Just (fo, t) -> do
+				h <- liftIO $ mkLockHandle ph fo
+				return (Just (h, t))
+
+mkLockHandle :: P.LockHandle -> FileLockOps -> IO LockHandle
+mkLockHandle ph fo = do
+	atomically $ P.registerCloseLockFile ph (fDropLock fo)
+	return $ LockHandle ph fo
diff --git a/Utility/LockPool/PidLock.hs b/Utility/LockPool/PidLock.hs
new file mode 100644
index 0000000000..87f1f1a214
--- /dev/null
+++ b/Utility/LockPool/PidLock.hs
@@ -0,0 +1,159 @@
+{- Pid locks, using lock pools.
+ -
+ - Copyright 2015-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.LockPool.PidLock (
+	P.LockFile,
+	LockHandle,
+	waitLock,
+	tryLock,
+	tryLock',
+	checkLocked,
+	getLockStatus,
+	LockStatus(..),
+	dropLock,
+	checkSaneLock,
+) where
+
+import qualified Utility.LockFile.PidLock as F
+import Utility.LockFile.LockStatus
+import qualified Utility.LockPool.STM as P
+import Utility.LockPool.STM (LockFile, LockMode(..))
+import Utility.LockPool.LockHandle
+import Utility.ThreadScheduler
+
+import System.IO
+import System.Posix
+import Control.Concurrent.STM
+import Data.Maybe
+import Control.Monad
+import Control.Monad.Catch
+import Control.Monad.IO.Class
+import Control.Applicative
+import Prelude
+
+-- Does locking using a pid lock, blocking until the lock is available
+-- or the Seconds timeout if the pid lock is held by another process.
+--
+-- There are two levels of locks. A STM lock is used to handle
+-- fine-grained locking among threads, locking a specific lockfile,
+-- but only in memory. The pid lock handles locking between processes.
+--
+-- The pid lock is only taken once, and LockShared is used for it,
+-- so multiple threads can have it locked. Only the first thread
+-- will create the pid lock, and it remains until all threads drop
+-- their locks.
+waitLock
+	:: (MonadIO m, MonadMask m)
+	=> LockFile
+	-> LockMode
+	-> Seconds
+	-> F.PidLockFile
+	-> (String -> m ())
+	-> m LockHandle
+waitLock finelockfile lockmode timeout pidlockfile displaymessage = do
+	fl <- takefinelock
+	pl <- takepidlock
+		`onException` liftIO (dropLock fl)
+	registerPostRelease fl pl
+	return fl
+  where
+	takefinelock = fst <$> makeLockHandle P.lockPool finelockfile
+		(\p f -> P.waitTakeLock p f lockmode)
+		(\_ _ -> pure (stmonlyflo, ()))
+	-- A shared STM lock is taken for each use of the pid lock,
+	-- but only the first thread to take it actually creates the pid
+	-- lock file.
+	takepidlock = makeLockHandle P.lockPool pidlockfile
+		(\p f -> P.waitTakeLock p f LockShared)
+		(\f (P.FirstLock firstlock firstlocksem) -> if firstlock
+			then waitlock f firstlocksem
+			else liftIO (atomically $ readTMVar firstlocksem) >>= \case
+				P.FirstLockSemWaited True -> alreadylocked f
+				P.FirstLockSemTried True -> alreadylocked f
+				P.FirstLockSemWaited False -> F.waitedLock timeout f displaymessage
+				P.FirstLockSemTried False -> waitlock f firstlocksem
+		)
+	waitlock f firstlocksem = do
+		h <- F.waitLock timeout f displaymessage $
+			void . atomically . tryPutTMVar firstlocksem . P.FirstLockSemWaited
+		return (mkflo h, Just h)
+	alreadylocked f = do
+		lh <- F.alreadyLocked f
+		return (mkflo lh, Nothing)
+
+registerPostRelease :: MonadIO m => LockHandle -> (LockHandle, Maybe F.LockHandle) -> m ()
+registerPostRelease (LockHandle flh _) (pl@(LockHandle plh _), mpidlock) = do
+	-- After the fine-grained lock gets dropped (and any shared locks
+	-- of it are also dropped), drop the associated pid lock.
+	liftIO $ atomically $
+		P.registerPostReleaseLock flh (dropLock pl)
+	-- When the last thread to use the pid lock has dropped it,
+	-- close the pid lock file itself.
+	case mpidlock of
+		Just pidlock -> liftIO $ atomically $
+			P.registerPostReleaseLock plh (F.dropLock pidlock)
+		Nothing -> return ()
+
+-- Tries to take a pid lock, but does not block.
+tryLock :: LockFile -> LockMode -> F.PidLockFile -> IO (Maybe LockHandle)
+tryLock finelockfile lockmode pidlockfile = takefinelock >>= \case
+	Just fl -> tryLock' pidlockfile >>= \case
+		Just pl -> do
+			registerPostRelease fl pl
+			return (Just fl)
+		Nothing -> do
+			dropLock fl
+			return Nothing
+	Nothing -> return Nothing
+  where
+	takefinelock = fmap fst <$> tryMakeLockHandle P.lockPool finelockfile
+		(\p f -> P.tryTakeLock p f lockmode)
+		(\_ _ -> pure (Just (stmonlyflo, ())))
+
+tryLock' :: F.PidLockFile -> IO (Maybe (LockHandle, Maybe F.LockHandle))
+tryLock' pidlockfile = tryMakeLockHandle P.lockPool pidlockfile
+	(\p f -> P.tryTakeLock p f LockShared)
+	(\f (P.FirstLock firstlock firstlocksem) -> if firstlock
+		then do
+			mlh <- F.tryLock f
+			void $ atomically $ tryPutTMVar firstlocksem 
+				(P.FirstLockSemTried (isJust mlh))
+			case mlh of
+				Just lh -> return (Just (mkflo lh, Just lh))
+				Nothing -> return Nothing
+		else liftIO (atomically $ readTMVar firstlocksem) >>= \case
+			P.FirstLockSemWaited True -> alreadylocked f
+			P.FirstLockSemTried True -> alreadylocked f
+			P.FirstLockSemWaited False -> return Nothing
+			P.FirstLockSemTried False -> return Nothing
+	)
+  where
+	alreadylocked f = do
+		lh <- F.alreadyLocked f
+		return (Just (mkflo lh, Nothing))
+
+checkLocked :: LockFile -> IO (Maybe Bool)
+checkLocked file = P.getLockStatus P.lockPool file
+	(pure (Just True))
+	(F.checkLocked file)
+
+getLockStatus :: LockFile -> IO LockStatus
+getLockStatus file = P.getLockStatus P.lockPool file
+	(StatusLockedBy <$> getProcessID)
+	(F.getLockStatus file)
+
+mkflo :: F.LockHandle -> FileLockOps
+mkflo h = FileLockOps
+	{ fDropLock = return ()
+	, fCheckSaneLock = \f -> F.checkSaneLock f h
+	}
+		
+stmonlyflo :: FileLockOps
+stmonlyflo = FileLockOps
+	{ fDropLock = return ()
+	, fCheckSaneLock = const (return True)
+	}
diff --git a/Utility/LockPool/Posix.hs b/Utility/LockPool/Posix.hs
new file mode 100644
index 0000000000..59aaa4e102
--- /dev/null
+++ b/Utility/LockPool/Posix.hs
@@ -0,0 +1,75 @@
+{- Posix lock files, using lock pools.
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.LockPool.Posix (
+	P.LockFile,
+	LockHandle,
+	lockShared,
+	lockExclusive,
+	tryLockShared,
+	tryLockExclusive,
+	checkLocked,
+	getLockStatus,
+	LockStatus(..),
+	dropLock,
+	checkSaneLock,
+) where
+
+import qualified Utility.LockFile.Posix as F
+import Utility.LockFile.LockStatus
+import qualified Utility.LockPool.STM as P
+import Utility.LockPool.STM (LockFile, LockMode(..))
+import Utility.LockPool.LockHandle
+import Utility.FileMode
+
+import System.IO
+import System.Posix
+import Data.Maybe
+import Control.Applicative
+import Prelude
+
+-- Takes a shared lock, blocking until the lock is available.
+lockShared :: Maybe ModeSetter -> LockFile -> IO LockHandle
+lockShared mode file = fst <$> makeLockHandle P.lockPool file
+	(\p f -> P.waitTakeLock p f LockShared)
+	(\f _ -> mk <$> F.lockShared mode f)
+
+-- Takes an exclusive lock, blocking until the lock is available.
+lockExclusive :: Maybe ModeSetter -> LockFile -> IO LockHandle
+lockExclusive mode file = fst <$> makeLockHandle P.lockPool file
+	(\p f -> P.waitTakeLock p f LockExclusive)
+	(\f _ -> mk <$> F.lockExclusive mode f)
+
+-- Tries to take a shared lock, but does not block.
+tryLockShared :: Maybe ModeSetter -> LockFile -> IO (Maybe LockHandle)
+tryLockShared mode file = fmap fst <$> tryMakeLockHandle P.lockPool file
+	(\p f -> P.tryTakeLock p f LockShared)
+	(\f _ -> fmap mk <$> F.tryLockShared mode f)
+
+-- Tries to take an exclusive lock, but does not block.
+tryLockExclusive :: Maybe ModeSetter -> LockFile -> IO (Maybe LockHandle)
+tryLockExclusive mode file = fmap fst <$> tryMakeLockHandle P.lockPool file
+	(\p f -> P.tryTakeLock p f LockExclusive)
+	(\f _ -> fmap mk <$> F.tryLockExclusive mode f)
+
+-- Returns Nothing when the file doesn't exist, for cases where
+-- that is different from it not being locked.
+checkLocked :: LockFile -> IO (Maybe Bool)
+checkLocked file = P.getLockStatus P.lockPool file
+	(pure (Just True))
+	(F.checkLocked file)
+
+getLockStatus :: LockFile -> IO LockStatus
+getLockStatus file = P.getLockStatus P.lockPool file
+	(StatusLockedBy <$> getProcessID)
+	(F.getLockStatus file)
+
+mk :: F.LockHandle -> (FileLockOps, ())
+mk h = (FileLockOps
+	{ fDropLock = F.dropLock h
+	, fCheckSaneLock = \f -> F.checkSaneLock f h
+	}, ())
diff --git a/Utility/LockPool/STM.hs b/Utility/LockPool/STM.hs
new file mode 100644
index 0000000000..2c3eb66aef
--- /dev/null
+++ b/Utility/LockPool/STM.hs
@@ -0,0 +1,179 @@
+{- STM implementation of lock pools.
+ -
+ - Copyright 2015-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.LockPool.STM (
+	LockPool,
+	lockPool,
+	LockFile,
+	LockMode(..),
+	LockHandle,
+	FirstLock(..),
+	FirstLockSemVal(..),
+	waitTakeLock,
+	tryTakeLock,
+	getLockStatus,
+	releaseLock,
+	CloseLockFile,
+	registerCloseLockFile,
+	registerPostReleaseLock,
+) where
+
+import Utility.Monad
+
+import System.IO.Unsafe (unsafePerformIO)
+import System.FilePath.ByteString (RawFilePath)
+import qualified Data.Map.Strict as M
+import Control.Concurrent.STM
+import Control.Exception
+
+type LockFile = RawFilePath
+
+data LockMode = LockExclusive | LockShared
+	deriving (Eq)
+
+-- This TMVar is full when the handle is open, and is emptied when it's
+-- closed.
+type LockHandle = TMVar (LockPool, LockFile, CloseLockFile)
+
+-- When a shared lock is taken, this will only be true for the first
+-- process, not subsequent processes. The first process should
+-- fill the FirstLockSem after doing any IO actions to finish lock setup
+-- and subsequent processes can block on that getting filled to know
+-- when the lock is fully set up.
+data FirstLock = FirstLock Bool FirstLockSem
+
+type FirstLockSem = TMVar FirstLockSemVal
+
+data FirstLockSemVal = FirstLockSemWaited Bool | FirstLockSemTried Bool
+
+type LockCount = Integer
+
+-- Action that closes the underlying lock file. When this is used
+-- in a LockHandle, it closes a resource that is specific to that
+-- LockHandle (such as eg a file handle), but does not release
+-- any other shared locks. When this is used in a LockStatus,
+-- it closes a resource that should only be closed when there are no
+-- other shared locks.
+type CloseLockFile = IO ()
+
+data LockStatus = LockStatus LockMode LockCount FirstLockSem CloseLockFile
+
+-- This TMVar is normally kept full.
+type LockPool = TMVar (M.Map LockFile LockStatus)
+
+-- A shared global variable for the lockPool. Avoids callers needing to
+-- maintain state for this implementation detail.
+{-# NOINLINE lockPool #-}
+lockPool :: LockPool
+lockPool = unsafePerformIO (newTMVarIO M.empty)
+
+-- Updates the LockPool, blocking as necessary if another thread is holding
+-- a conflicting lock.
+-- 
+-- Note that when a shared lock is held, an exclusive lock will block.
+-- While that blocking is happening, another call to this function to take
+-- the same shared lock should not be blocked on the exclusive lock.
+-- Keeping the whole Map in a TMVar accomplishes this, at the expense of
+-- sometimes retrying after unrelated changes in the map.
+waitTakeLock :: LockPool -> LockFile -> LockMode -> STM (LockHandle, FirstLock)
+waitTakeLock pool file mode = maybe retry return =<< tryTakeLock pool file mode
+
+-- Avoids blocking if another thread is holding a conflicting lock.
+tryTakeLock :: LockPool -> LockFile -> LockMode -> STM (Maybe (LockHandle, FirstLock))
+tryTakeLock pool file mode = do
+	m <- takeTMVar pool
+	let success firstlock v = do
+		putTMVar pool (M.insert file v m)
+		tmv <- newTMVar (pool, file, noop)
+		return (Just (tmv, firstlock))
+	case M.lookup file m of
+		Just (LockStatus mode' n firstlocksem postreleaselock)
+			| mode == LockShared && mode' == LockShared -> do
+				fl@(FirstLock _ firstlocksem') <- if n == 0
+					then FirstLock True <$> newEmptyTMVar
+					else pure (FirstLock False firstlocksem)
+				success fl $ LockStatus mode (succ n) firstlocksem' postreleaselock
+			| n > 0 -> do
+				putTMVar pool m
+				return Nothing
+		_ -> do
+			firstlocksem <- newEmptyTMVar
+			success (FirstLock True firstlocksem) $
+				LockStatus mode 1 firstlocksem noop
+
+-- Call after waitTakeLock or tryTakeLock, to register a CloseLockFile
+-- action to run when releasing the lock. This action should only
+-- close the lock file associated with the LockHandle, while
+-- leaving any other shared locks of the same file open.
+registerCloseLockFile :: LockHandle -> CloseLockFile -> STM ()
+registerCloseLockFile h closelockfile = do
+	(p, f, c) <- takeTMVar h
+	putTMVar h (p, f, c >> closelockfile)
+
+-- Register an action that should be run only once a lock has been
+-- released. When there are multiple shared locks of the same file,
+-- the action will only be run after all are released.
+registerPostReleaseLock :: LockHandle -> CloseLockFile -> STM ()
+registerPostReleaseLock h postreleaselock = do
+	(p, f, _) <- readTMVar h
+	m <- takeTMVar p
+	case M.lookup f m of
+		Nothing -> putTMVar p m
+		Just (LockStatus mode cnt firstlocksem c) -> do
+			let c' = c >> postreleaselock
+			putTMVar p $ M.insert f (LockStatus mode cnt firstlocksem c') m
+
+-- Checks if a lock is being held. If it's held by the current process,
+-- runs the getdefault action; otherwise runs the checker action.
+--
+-- Note that the lock pool is left empty while the checker action is run.
+-- This allows checker actions that open/close files, and so would be in
+-- danger of conflicting with locks created at the same time this is
+-- running. With the lock pool empty, anything that attempts
+-- to take a lock will block, avoiding that race.
+getLockStatus :: LockPool -> LockFile -> IO v -> IO v -> IO v
+getLockStatus pool file getdefault checker = do
+	v <- atomically $ do
+		m <- takeTMVar pool
+		let threadlocked = case M.lookup file m of
+			Just (LockStatus _ n _ _) | n > 0 -> True
+			_ -> False
+		if threadlocked
+			then do
+				putTMVar pool m
+				return Nothing
+			else return $ Just $ atomically $ putTMVar pool m
+	case v of
+		Nothing -> getdefault
+		Just restore -> bracket_ (return ()) restore checker
+
+-- Releases the lock. When it is a shared lock, it may remain locked by
+-- other LockHandles.
+--
+-- Note that the lock pool is left empty while the CloseLockFile action
+-- is run, to avoid race with another thread trying to open the same lock
+-- file. However, the pool is full again when the PostReleaseLock action
+-- runs.
+releaseLock :: LockHandle -> IO ()
+releaseLock h = go =<< atomically (tryTakeTMVar h)
+  where
+	go (Just (pool, file, closelockfile)) = do
+		(m, postreleaselock) <- atomically $ do
+			m <- takeTMVar pool
+			return $ case M.lookup file m of
+				Just (LockStatus mode n firstlocksem postreleaselock)
+					| n == 1 -> (M.delete file m, postreleaselock)
+					| otherwise ->
+						(M.insert file (LockStatus mode (pred n) firstlocksem postreleaselock) m, noop)
+				Nothing -> (m, noop)
+		() <- closelockfile
+		atomically $ putTMVar pool m
+		-- This action may access the pool, so run it only
+		-- after the pool is restored.
+		postreleaselock
+	-- The LockHandle was already closed.
+	go Nothing = return ()
diff --git a/Utility/LockPool/Windows.hs b/Utility/LockPool/Windows.hs
new file mode 100644
index 0000000000..3ea3da8367
--- /dev/null
+++ b/Utility/LockPool/Windows.hs
@@ -0,0 +1,48 @@
+{- Windows lock files, using lock pools.
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.LockPool.Windows (
+	P.LockFile,
+	LockHandle,
+	lockShared,
+	lockExclusive,
+	dropLock,
+	waitToLock,
+) where
+
+import qualified Utility.LockFile.Windows as F
+import qualified Utility.LockPool.STM as P
+import Utility.LockPool.LockHandle
+import Utility.LockPool.STM (LockFile, LockMode(..))
+
+{- Tries to lock a file with a shared lock, which allows other processes to
+ - also lock it shared. Fails if the file is exclusively locked. -}
+lockShared :: LockFile -> IO (Maybe LockHandle)
+lockShared file = fmap fst <$> tryMakeLockHandle P.lockPool file
+	(\p f -> P.tryTakeLock p f LockShared)
+	(\f _ -> fmap mk <$> F.lockShared f)
+
+{- Tries to take an exclusive lock on a file. Fails if another process has
+ - a shared or exclusive lock.
+ -
+ - Note that exclusive locking also prevents the file from being opened for
+ - read or write by any other process. So for advisory locking of a file's
+ - content, a separate LockFile should be used. -}
+lockExclusive :: LockFile -> IO (Maybe LockHandle)
+lockExclusive file = fmap fst <$> tryMakeLockHandle P.lockPool file
+	(\p f -> P.tryTakeLock p f LockExclusive)
+	(\f _ -> fmap mk <$> F.lockExclusive f)
+
+{- If the initial lock fails, this is a BUSY wait, and does not
+ - guarantee FIFO order of waiters. In other news, Windows is a POS. -}
+waitToLock :: IO (Maybe lockhandle) -> IO lockhandle
+waitToLock = F.waitToLock
+
+mk :: F.LockHandle -> (FileLockOps, ())
+mk h = (FileLockOps
+	{ fDropLock = F.dropLock h
+	}, ())
diff --git a/Utility/LogFile.hs b/Utility/LogFile.hs
new file mode 100644
index 0000000000..64ab78576b
--- /dev/null
+++ b/Utility/LogFile.hs
@@ -0,0 +1,69 @@
+{- log files
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.LogFile (
+	openLog,
+	listLogs,
+	maxLogs,
+#ifndef mingw32_HOST_OS
+	redirLog,
+	redir,
+#endif
+) where
+
+import Common
+import Utility.RawFilePath
+
+#ifndef mingw32_HOST_OS
+import System.Posix.Types
+import System.Posix.IO
+#endif
+
+openLog :: FilePath -> IO Handle
+openLog logfile = do
+	rotateLog logfile
+	openFile logfile AppendMode
+
+rotateLog :: FilePath -> IO ()
+rotateLog logfile = go 0
+  where
+	go num
+		| num > maxLogs = return ()
+		| otherwise = whenM (doesFileExist currfile) $ do
+			go (num + 1)
+			rename (toRawFilePath currfile) (toRawFilePath nextfile)
+	  where
+		currfile = filename num
+		nextfile = filename (num + 1)
+		filename n
+			| n == 0 = logfile
+			| otherwise = rotatedLog logfile n
+
+rotatedLog :: FilePath -> Int -> FilePath
+rotatedLog logfile n = logfile ++ "." ++ show n
+
+{- Lists most recent logs last. -}
+listLogs :: FilePath -> IO [FilePath]
+listLogs logfile = filterM doesFileExist $ reverse $ 
+	logfile : map (rotatedLog logfile) [1..maxLogs]
+
+maxLogs :: Int
+maxLogs = 9
+
+#ifndef mingw32_HOST_OS
+redirLog :: Fd -> IO ()
+redirLog logfd = do
+	mapM_ (redir logfd) [stdOutput, stdError]
+	closeFd logfd
+
+redir :: Fd -> Fd -> IO ()
+redir newh h = do
+	closeFd h
+	void $ dupTo newh h
+#endif
diff --git a/Utility/Lsof.hs b/Utility/Lsof.hs
new file mode 100644
index 0000000000..e8569ee023
--- /dev/null
+++ b/Utility/Lsof.hs
@@ -0,0 +1,113 @@
+{- lsof interface
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.Lsof (
+	LsofOpenMode(..),
+	setup,
+	queryDir,
+	query,
+) where
+
+import Common
+import BuildInfo
+import Utility.Env.Set
+
+import System.Posix.Types
+
+data LsofOpenMode = OpenReadWrite | OpenReadOnly | OpenWriteOnly | OpenUnknown
+	deriving (Show, Eq)
+
+type CmdLine = String
+
+data ProcessInfo = ProcessInfo ProcessID CmdLine
+	deriving (Show)
+
+{- lsof is not in PATH on all systems, so BuildInfo may have the absolute
+ - path where the program was found. Make sure at runtime that lsof is
+ - available, and if it's not in PATH, adjust PATH to contain it. -}
+setup :: IO ()
+setup = do
+	let cmd = fromMaybe "lsof" BuildInfo.lsof
+	when (isAbsolute cmd) $ do
+		path <- getSearchPath
+		let path' = takeDirectory cmd : path
+		setEnv "PATH" (intercalate [searchPathSeparator] path') True
+
+{- Checks each of the files in a directory to find open files.
+ - Note that this will find hard links to files elsewhere that are open. -}
+queryDir :: FilePath -> IO [(FilePath, LsofOpenMode, ProcessInfo)]
+queryDir path = query ["+d", path]
+
+{- Runs lsof with some parameters.
+ -
+ - Ignores nonzero exit code; lsof returns that when no files are open.
+ -
+ - Note: If lsof is not available, this always returns [] !
+ -}
+query :: [String] -> IO [(FilePath, LsofOpenMode, ProcessInfo)]
+query opts = withCreateProcess p go
+  where
+	p = (proc "lsof" ("-F0can" : opts))
+		{ std_out = CreatePipe }
+	
+	go _ (Just outh) _ pid = do
+		r <- parse <$> hGetContentsStrict outh
+		void $ waitForProcess pid
+		return r
+	go _ _ _ _ = error "internal"
+
+type LsofParser = String -> [(FilePath, LsofOpenMode, ProcessInfo)]
+
+{- Parsing null-delimited output like:
+ -
+ - pPID\0cCMDLINE\0
+ - aMODE\0nFILE\0
+ - aMODE\0nFILE\0
+ - pPID\0[...]
+ -
+ - Where each new process block is started by a pid, and a process can
+ - have multiple files open.
+ -}
+parse :: LsofParser
+parse s = bundle $ go [] $ lines s
+  where
+	bundle = concatMap (\(fs, p) -> map (\(f, m) -> (f, m, p)) fs)
+
+	go c [] = c
+	go c ((t:r):ls)
+		| t == 'p' =
+			let (fs, ls') = parsefiles [] ls
+			in go ((fs, parseprocess r):c) ls'
+		| otherwise = parsefail
+	go _ _ = parsefail
+
+	parseprocess l = case splitnull l of
+		[pid, 'c':cmdline, ""] ->
+			case readish pid of
+				(Just n) -> ProcessInfo n cmdline
+				Nothing -> parsefail
+		_ -> parsefail
+
+	parsefiles c [] = (c, [])
+	parsefiles c (l:ls) = parsefiles' c (splitnull l) l ls
+
+	parsefiles' c ['a':mode, 'n':file, ""] _ ls =
+		parsefiles ((file, parsemode mode):c) ls
+	parsefiles' c (('p':_):_) l ls = (c, l:ls)
+	-- Some buggy versions of lsof emit a f field
+	-- that was not requested, so ignore it.
+	parsefiles' c (('f':_):rest) l ls = parsefiles' c rest l ls
+	parsefiles' _ _ _ _ = parsefail
+
+	parsemode ('r':_) = OpenReadOnly
+	parsemode ('w':_) = OpenWriteOnly
+	parsemode ('u':_) = OpenReadWrite
+	parsemode _ = OpenUnknown
+
+	splitnull = splitc '\0'
+
+	parsefail = giveup $ "failed to parse lsof output: " ++ show s
diff --git a/Utility/MD5.hs b/Utility/MD5.hs
new file mode 100644
index 0000000000..aabb5d724b
--- /dev/null
+++ b/Utility/MD5.hs
@@ -0,0 +1,24 @@
+{- modified version of MD5 from http://www.cs.ox.ac.uk/people/ian.lynagh/md5
+ -
+ - Copyright (C) 2001 Ian Lynagh 
+ - License: GPL 2
+ -}
+
+module Utility.MD5 where
+
+import Data.Bits
+import Data.Word
+import Data.Char
+
+display_32bits_as_dir :: Word32 -> [Word8]
+display_32bits_as_dir w = trim $ swap_pairs cs
+  where
+	-- Need 32 characters to use. To avoid inaverdently making
+	-- a real word, use letters that appear less frequently.
+	chars = map (fromIntegral . ord) (['0'..'9'] ++ "zqjxkmvwgpfZQJXKMVWGPF")
+	cs = map (\x -> getc $ (shiftR w (6*x)) .&. 31) [0..7]
+	getc n = chars !! fromIntegral n
+	swap_pairs (x1:x2:xs) = x2:x1:swap_pairs xs
+	swap_pairs _ = []
+	-- Last 2 will always be 00, so omit.
+	trim = take 6
diff --git a/Utility/MagicWormhole.hs b/Utility/MagicWormhole.hs
new file mode 100644
index 0000000000..8aa950ef7d
--- /dev/null
+++ b/Utility/MagicWormhole.hs
@@ -0,0 +1,177 @@
+{- Magic Wormhole integration
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.MagicWormhole (
+	Code,
+	mkCode,
+	toCode,
+	fromCode,
+	validCode,
+	CodeObserver,
+	CodeProducer,
+	mkCodeObserver,
+	mkCodeProducer,
+	waitCode,
+	sendCode,
+	WormHoleParams,
+	appId,
+	sendFile,
+	receiveFile,
+	isInstalled,
+) where
+
+import Utility.Process
+import Utility.SafeCommand
+import Utility.Monad
+import Utility.Misc
+import Utility.Env
+import Utility.Path
+import Utility.Exception
+
+import System.IO
+import System.Exit
+import Control.Concurrent
+import Control.Concurrent.Async
+import Data.Char
+import Data.List
+import Control.Applicative
+import Prelude
+
+-- | A Magic Wormhole code.
+newtype Code = Code String
+	deriving (Eq, Show)
+
+-- | Smart constructor for Code
+mkCode :: String -> Maybe Code
+mkCode s
+	| validCode s = Just (Code s)
+	| otherwise = Nothing
+
+-- | Tries to fix up some common mistakes in a homan-entered code.
+toCode :: String -> Maybe Code
+toCode s = mkCode $ intercalate "-" $ words s
+
+fromCode :: Code -> String
+fromCode (Code s) = s
+
+-- | Codes have the form number-word-word and may contain 2 or more words.
+validCode :: String -> Bool
+validCode s = 
+	let (n, r) = separate (== '-') s
+	    (w1, w2) = separate (== '-') r
+	in and
+		[ not (null n)
+		, all isDigit n
+		, not (null w1)
+		, not (null w2)
+		, not $ any isSpace s
+		]
+
+newtype CodeObserver = CodeObserver (MVar Code)
+
+newtype CodeProducer = CodeProducer (MVar Code)
+
+mkCodeObserver :: IO CodeObserver
+mkCodeObserver = CodeObserver <$> newEmptyMVar
+
+mkCodeProducer :: IO CodeProducer
+mkCodeProducer = CodeProducer <$> newEmptyMVar
+
+waitCode :: CodeObserver -> IO Code
+waitCode (CodeObserver o) = readMVar o
+
+sendCode :: CodeProducer -> Code -> IO ()
+sendCode (CodeProducer p) = putMVar p
+
+type WormHoleParams = [CommandParam]
+
+-- | An appid should be provided when using wormhole in an app, to avoid
+-- using the same channel space as ad-hoc wormhole users.
+appId :: String -> WormHoleParams
+appId s = [Param "--appid", Param s]
+
+-- | Sends a file. Once the send is underway, and the Code has been
+-- generated, it will be sent to the CodeObserver. (This may not happen,
+-- eg if there's a network problem).
+--
+-- Currently this has to parse the output of wormhole to find the code.
+-- To make this as robust as possible, avoids looking for any particular
+-- output strings, and only looks for the form of a wormhole code
+-- (number-word-word). 
+--
+-- Note that, if the filename looks like "foo 1-wormhole-code bar", when
+-- that is output by wormhole, it will look like it's output a wormhole code.
+--
+-- A request to make the code available in machine-parsable form is here:
+-- https://github.com/warner/magic-wormhole/issues/104
+sendFile :: FilePath -> CodeObserver -> WormHoleParams -> IO Bool
+sendFile f (CodeObserver observer) ps = do
+	-- Work around stupid stdout buffering behavior of python.
+	-- See https://github.com/warner/magic-wormhole/issues/108
+	environ <- addEntry "PYTHONUNBUFFERED" "1" <$> getEnvironment
+	runWormHoleProcess p { env = Just environ} $ \_hin hout herr ph -> do
+ 		(inout, inerr) <- concurrently
+			(findcode ph hout)
+			(findcode ph herr)
+		return (inout || inerr)
+  where
+	p = wormHoleProcess (ps ++ [Param "send", File f])
+	findcode ph h = hGetLineUntilExitOrEOF ph h >>= \case
+		Nothing -> return False
+		Just l -> ifM (findcode' (words l))
+			( drain ph h >> return True
+			, findcode ph h
+			)
+	findcode' [] = return False
+	findcode' (w:ws) = case mkCode w of
+		Just code -> do
+			_ <- tryPutMVar observer code
+			return True
+		Nothing -> findcode' ws
+	drain ph h = hGetLineUntilExitOrEOF ph h >>= \case
+		Just _ -> drain ph h
+		Nothing -> return ()
+
+-- | Receives a file. Once the receive is under way, the Code will be
+-- read from the CodeProducer, and fed to wormhole on stdin.
+receiveFile :: FilePath -> CodeProducer -> WormHoleParams -> IO Bool
+receiveFile f (CodeProducer producer) ps = runWormHoleProcess p $ \hin _hout _herr _ph -> do
+	Code c <- readMVar producer
+	hPutStrLn hin c
+	hFlush hin
+	return True
+  where
+	p = wormHoleProcess $ ps ++
+		[ Param "receive"
+		, Param "--accept-file"
+		, Param "--output-file"
+		, File f
+		]
+
+wormHoleProcess :: WormHoleParams -> CreateProcess
+wormHoleProcess = proc "wormhole" . toCommand
+
+runWormHoleProcess :: CreateProcess -> (Handle -> Handle -> Handle -> ProcessHandle -> IO Bool) ->  IO Bool
+runWormHoleProcess p consumer =
+	withCreateProcess p' go `catchNonAsync` const (return False)
+  where
+	p' = p 
+		{ std_in = CreatePipe
+		, std_out = CreatePipe
+		, std_err = CreatePipe
+		}
+	go (Just hin) (Just hout) (Just herr) pid =
+		consumer hin hout herr pid <&&> waitbool pid
+	go _ _ _ _ = error "internal"
+	waitbool pid = do
+		r <- waitForProcess pid
+		return $ case r of
+			ExitSuccess -> True
+			ExitFailure _ -> False
+
+isInstalled :: IO Bool
+isInstalled = inSearchPath "wormhole"
diff --git a/Utility/Matcher.hs b/Utility/Matcher.hs
new file mode 100644
index 0000000000..38864e05fd
--- /dev/null
+++ b/Utility/Matcher.hs
@@ -0,0 +1,342 @@
+{- A generic matcher.
+ -
+ - Can be used to check if a user-supplied condition,
+ - like "foo and ( bar or not baz )" matches. The condition must already
+ - be tokenized, and can contain arbitrary operations.
+ -
+ - If operations are not separated by and/or, they are defaulted to being
+ - anded together, so "foo bar baz" all must match.
+ -
+ - Is forgiving about misplaced closing parens, so "foo and (bar or baz"
+ - will be handled, as will "foo and ( bar or baz ) )"
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE DeriveFoldable, FlexibleContexts #-}
+
+module Utility.Matcher (
+	Token(..),
+	Matcher(..),
+	MatchDesc(..),
+	MatchResult(..),
+	syntaxToken,
+	generate,
+	pruneMatcher,
+	match,
+	match',
+	matchM,
+	matchMrun,
+	matchMrun',
+	isEmpty,
+	combineMatchers,
+	introspect,
+	describeMatchResult,
+
+	prop_matcher_sane
+) where
+
+import Common
+
+import Control.Monad.Writer
+
+{- A Token can be an Operation of an arbitrary type, or one of a few
+ - predefined pieces of syntax. -}
+data Token op = Operation op | And | Or | Not | Open | Close
+	deriving (Show, Eq)
+
+data Matcher op = MAny
+	| MAnd (Matcher op) (Matcher op)
+	| MOr (Matcher op) (Matcher op)
+	| MNot (Matcher op)
+	| MOp op
+	deriving (Show, Eq, Foldable)
+
+newtype MatchDesc = MatchDesc String
+
+data MatchResult op
+	= MatchedOperation Bool op
+	| MatchedAnd
+	| MatchedOr
+	| MatchedNot
+	| MatchedOpen
+	| MatchedClose
+	deriving (Show, Eq)
+
+{- Converts a word of syntax into a token. Doesn't handle operations. -}
+syntaxToken :: String -> Either String (Token op)
+syntaxToken "and" = Right And
+syntaxToken "or" = Right Or
+syntaxToken "not" = Right Not
+syntaxToken "(" = Right Open
+syntaxToken ")" = Right Close
+syntaxToken t = Left $ "unknown token " ++ t
+
+{- Converts a list of Tokens into a Matcher. -}
+generate :: [Token op] -> Matcher op
+generate = simplify . process MAny . implicitAnd . tokenGroups
+  where
+	process m [] = m
+	process m ts = uncurry process $ consume m ts
+
+	consume m (One And:rest) = term (m `MAnd`) rest
+	consume m (One Or:rest) = term (m `MOr`) rest
+	consume m (One Not:rest) = term (\p -> m `MAnd` (MNot p)) rest
+	consume m (One (Operation o):rest) = (m `MAnd` MOp o, rest)
+	consume m (Group g:rest) = (process m g, rest)
+	consume m (_:rest) = consume m rest
+	consume m [] = (m, [])
+
+	term a l = 
+		let (p, l') = consume MAny l
+		in (a p, l')
+
+	simplify (MAnd MAny x) = simplify x
+	simplify (MAnd x MAny) = simplify x
+	simplify (MAnd x y) = MAnd (simplify x) (simplify y)
+	simplify (MOr x y) = MOr (simplify x) (simplify y)
+	simplify (MNot x) = MNot (simplify x)
+	simplify x = x
+
+{- Prunes selected ops from the Matcher. -}
+pruneMatcher :: (op -> Bool) -> Matcher op -> Matcher op
+pruneMatcher f = fst . go
+  where
+	go MAny = (MAny, False)
+	go (MAnd a b) = go2 a b MAnd
+	go (MOr a b) = go2 a b MOr
+	go (MNot a) = case go a of
+		(_, True)  -> (MAny, True)
+		(a', False) -> (MNot a', False)
+	go (MOp op)
+		| f op = (MAny, True)
+		| otherwise = (MOp op, False)
+
+	go2 a b g = case (go a, go b) of
+		((_,  True),  (_,  True))  -> (MAny, True)
+		((a', False), (b', False)) -> (g a' b', False)
+		((_,  True),  (b', False)) -> (b', False)
+		((a', False), (_,  True))  -> (a', False)
+
+data TokenGroup op = One (Token op) | Group [TokenGroup op]
+	deriving (Show, Eq)
+
+tokenGroups :: [Token op] -> [TokenGroup op]
+tokenGroups [] = []
+tokenGroups (t:ts) = go t
+  where
+	go Open =
+		let (gr, rest) = findClose ts
+		in gr : tokenGroups rest
+	go Close = tokenGroups ts -- not picky about missing Close
+	go _ = One t : tokenGroups ts
+
+findClose :: [Token op] -> (TokenGroup op, [Token op])
+findClose l = 
+	let (g, rest) = go [] l
+	in (Group (reverse g), rest)
+  where
+	go c [] = (c, []) -- not picky about extra Close
+	go c (t:ts) = dispatch t
+	  where
+		dispatch Close = (c, ts)
+		dispatch Open = 
+			let (c', ts') = go [] ts
+			in go (Group (reverse c') : c) ts'
+		dispatch _ = go (One t:c) ts
+
+implicitAnd :: [TokenGroup op] -> [TokenGroup op]
+implicitAnd [] = []
+implicitAnd [v] = [v]
+implicitAnd (a:b:rest) | need a && need b = a : One And : implicitAnd (b:rest)
+  where
+	need (One (Operation _)) = True
+	need (Group _) = True
+	need _ = False
+implicitAnd (a:rest) = a : implicitAnd rest
+
+{- Checks if a Matcher matches, using a supplied function to check
+ - the value of Operations. -}
+match :: (op -> v -> Bool) -> Matcher op -> v -> Bool
+match a m v = fst $ runWriter $ match' a m v
+
+{- Like match, but accumulates a description of why it did or didn't match. -}
+match' :: (op -> v -> Bool) -> Matcher op -> v -> Writer [MatchResult op] Bool
+match' a m v = matchMrun' m (\op -> pure (a op v))
+
+{- Runs a monadic Matcher, where Operations are actions in the monad. -}
+matchM :: Monad m => Matcher (v -> m Bool) -> v -> m Bool
+matchM m v = matchMrun m $ \op -> op v
+
+{- More generic running of a monadic Matcher, with full control over running
+ - of Operations. -}
+matchMrun :: Monad m => Matcher op -> (op -> m Bool) -> m Bool
+matchMrun m run = fst <$> runWriterT (matchMrun' m run)
+
+{- Like matchMrun, but accumulates a description of why it did or didn't match. -}
+matchMrun'
+	:: (MonadWriter [MatchResult op] (t m), MonadTrans t, Monad m)
+	=> Matcher op
+	-> (op -> m Bool)
+	-> t m Bool
+matchMrun' m run = go m
+  where
+	go MAny = return True
+	go (MAnd m1 m2) = do
+		tell [MatchedOpen]
+		r1 <- go m1
+		if r1 
+			then do
+				tell [MatchedAnd]
+				r <- go m2
+				tell [MatchedClose]
+				return r
+			else do
+				tell [MatchedClose]
+				return False
+	go (MOr m1 m2) = do
+		tell [MatchedOpen]
+		r1 <- go m1
+		if r1
+			then do
+				tell [MatchedClose]
+				return True
+			else do
+				tell [MatchedOr]
+				r <- go m2
+				tell [MatchedClose]
+				return r
+	go (MNot m1) = do
+		tell [MatchedOpen, MatchedNot]
+		r <- liftM not (go m1)
+		tell [MatchedClose]
+		return r
+	go (MOp op) = do
+		r <- lift (run op)
+		tell [MatchedOperation r op]
+		return r
+
+{- Checks if a matcher contains no limits. -}
+isEmpty :: Matcher a -> Bool
+isEmpty MAny = True
+isEmpty _ = False
+
+{- Combines two matchers, yielding a matcher that will match anything
+ - both do. But, if one matcher contains no limits, yield the other one. -}
+combineMatchers :: Matcher a -> Matcher a -> Matcher a
+combineMatchers a b 
+	| isEmpty a = b
+	| isEmpty b = a
+	| otherwise = a `MOr` b
+
+{- Checks if anything in the matcher meets the condition. -}
+introspect :: (a -> Bool) -> Matcher a -> Bool
+introspect = any
+
+{- Converts a [MatchResult] into a description of what matched and didn't
+ - match. Returns Nothing when the matcher didn't contain any operations
+ - and so matched by default. -}
+describeMatchResult :: (op -> Bool -> MatchDesc) -> [MatchResult op] -> String -> Maybe String
+describeMatchResult _ [] _ = Nothing
+describeMatchResult descop l prefix = Just $
+	prefix ++ unwords (go $ simplify True l)
+  where
+ 	go [] = []
+	go (MatchedOperation b op:rest) = 
+		let MatchDesc d = descop op b
+		in d : go rest
+	go (MatchedAnd:rest) = "and" : go rest
+	go (MatchedOr:rest) = "or" : go rest
+	go (MatchedNot:rest) = "not" : go rest
+	go (MatchedOpen:rest) = "(" : go rest
+	go (MatchedClose:rest) = ")" : go rest
+
+	-- Remove unncessary outermost parens
+	simplify True (MatchedOpen:rest) = case lastMaybe rest of
+		Just MatchedClose -> simplify False (dropFromEnd 1 rest)
+		_ -> simplify False rest
+	-- (foo or bar) or baz => foo or bar or baz
+	simplify _ (MatchedOpen:o1@(MatchedOperation {}):MatchedOr:o2@(MatchedOperation {}):MatchedClose:MatchedOr:rest) = 
+		o1:MatchedOr:o2:MatchedOr:simplify False rest
+	-- (foo and bar) and baz => foo and bar and baz
+	simplify _ (MatchedOpen:o1@(MatchedOperation {}):MatchedAnd:o2@(MatchedOperation {}):MatchedClose:MatchedAnd:rest) = 
+		o1:MatchedAnd:o2:MatchedAnd:simplify False rest
+	-- or (foo) => or foo
+	simplify _ (MatchedOr:MatchedOpen:o@(MatchedOperation {}):MatchedClose:rest) =
+		MatchedOr:o:simplify False rest
+	-- and (foo) => and foo
+	simplify _ (MatchedAnd:MatchedOpen:o@(MatchedOperation {}):MatchedClose:rest) =
+		MatchedAnd:o:simplify False rest
+	-- (not foo) => not foo
+	simplify _ (MatchedOpen:MatchedNot:o@(MatchedOperation {}):MatchedClose:rest) =
+		MatchedNot:o:simplify False rest
+	-- ((foo bar)) => (foo bar)
+	simplify _ (MatchedOpen:MatchedOpen:rest) =
+		MatchedOpen : simplify False (removeclose (0 :: Int) rest)
+	simplify _ (v:rest) = v : simplify False rest
+	simplify _ v = v
+
+	removeclose n (MatchedOpen:rest) =
+		MatchedOpen : removeclose (n+1) rest
+	removeclose n (MatchedClose:rest)
+		| n > 0 = MatchedClose : removeclose (n-1) rest
+		| otherwise = rest
+	removeclose n (v:rest) = v : removeclose n rest
+	removeclose _ [] = []
+
+prop_matcher_sane :: Bool
+prop_matcher_sane = and
+	[ all (\m -> match (\b _ -> b) m ()) (map generate evaltrue)
+	, all (\(x,y) -> generate x == generate y) evalsame
+	]
+  where
+	evaltrue =
+		[ [Operation True]
+		, []
+		, [Operation False, Or, Operation True, Or, Operation False]
+		, [Operation True, Or, Operation True]
+		, [Operation True, And, Operation True]
+		, [Not, Open, Operation True, And, Operation False, Close]
+		, [Not, Open, Not, Open, Not, Operation False, Close, Close]
+		, [Not, Open, Not, Open, Not, Open, Not, Operation True, Close, Close]
+		, [Operation True, And, Not, Operation False]
+		, [Operation True, Not, Operation False]
+		, [Operation True, Not, Not, Not, Operation False]
+		, [Operation True, Not, Not, Not, Operation False, And, Operation True]
+		, [Operation True, Not, Not, Not, Operation False, Operation True]
+		, [Not, Open, Operation True, And, Operation False, Close, 
+			And, Open, 
+				Open, Operation True, And, Operation False, Close,
+				Or,
+				Open, Operation True, And, Open, Not, Operation False, Close, Close,
+			Close, And,
+				Open, Not, Operation False, Close]
+		]
+	evalsame =
+		[
+			( [Operation "foo", Open, Operation "bar", Or, Operation "baz", Close]
+			, [Operation "foo", And, Open, Operation "bar", Or, Operation "baz", Close]
+			)
+		,
+			( [Operation "foo", Not, Open, Operation "bar", Or, Operation "baz", Close]
+			, [Operation "foo", And, Not, Open, Operation "bar", Or, Operation "baz", Close]
+			)
+		,
+			( [Open, Operation "bar", Or, Operation "baz", Close, Operation "foo"]
+			, [Open, Operation "bar", Or, Operation "baz", Close, And, Operation "foo"]
+			)
+		,
+			( [Open, Operation "bar", Or, Operation "baz", Close, Not, Operation "foo"]
+			, [Open, Operation "bar", Or, Operation "baz", Close, And, Not, Operation "foo"]
+			)
+		,
+			( [Operation "foo", Operation "bar"]
+			, [Operation "foo", And, Operation "bar"]
+			)
+		,
+			( [Operation "foo", Not, Operation "bar"]
+			, [Operation "foo", And, Not, Operation "bar"]
+			)
+		]
diff --git a/Utility/Metered.hs b/Utility/Metered.hs
new file mode 100644
index 0000000000..0b7097b732
--- /dev/null
+++ b/Utility/Metered.hs
@@ -0,0 +1,546 @@
+{- Metered IO and actions
+ -
+ - Copyright 2012-2024 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE TypeSynonymInstances, BangPatterns #-}
+
+module Utility.Metered (
+	MeterUpdate,
+	MeterState(..),
+	nullMeterUpdate,
+	combineMeterUpdate,
+	TotalSize(..),
+	BytesProcessed(..),
+	toBytesProcessed,
+	fromBytesProcessed,
+	addBytesProcessed,
+	zeroBytesProcessed,
+	withMeteredFile,
+	meteredWrite,
+	meteredWrite',
+	meteredWriteFile,
+	offsetMeterUpdate,
+	hGetContentsMetered,
+	hGetMetered,
+	defaultChunkSize,
+	watchFileSize,
+	OutputHandler(..),
+	ProgressParser,
+	commandMeter,
+	commandMeter',
+	commandMeterExitCode,
+	commandMeterExitCode',
+	demeterCommand,
+	demeterCommandEnv,
+	avoidProgress,
+	rateLimitMeterUpdate,
+	bwLimitMeterUpdate,
+	Meter,
+	mkMeter,
+	setMeterTotalSize,
+	updateMeter,
+	displayMeterHandle,
+	clearMeterHandle,
+	bandwidthMeter,
+) where
+
+import Common
+import Author
+import Utility.Percentage
+import Utility.DataUnits
+import Utility.HumanTime
+import Utility.SimpleProtocol as Proto
+import Utility.ThreadScheduler
+import Utility.SafeOutput
+
+import qualified Data.ByteString.Lazy as L
+import qualified Data.ByteString as S
+import System.IO.Unsafe
+import Foreign.Storable (Storable(sizeOf))
+import System.Posix.Types
+import Data.Int
+import Control.Concurrent
+import Control.Concurrent.Async
+import Control.Monad.IO.Class (MonadIO)
+import Data.Time.Clock
+import Data.Time.Clock.POSIX
+
+copyright :: Copyright
+copyright = author JoeyHess (2024-12)
+
+{- An action that can be run repeatedly, updating it on the bytes processed.
+ -
+ - Note that each call receives the total number of bytes processed, so
+ - far, *not* an incremental amount since the last call. -}
+type MeterUpdate = (BytesProcessed -> IO ())
+
+nullMeterUpdate :: MeterUpdate
+nullMeterUpdate _ = return ()
+
+combineMeterUpdate :: MeterUpdate -> MeterUpdate -> MeterUpdate
+combineMeterUpdate a b = \n -> a n >> b n
+
+{- Total number of bytes processed so far. -}
+newtype BytesProcessed = BytesProcessed Integer
+	deriving (Eq, Ord, Show, Read)
+
+class AsBytesProcessed a where
+	toBytesProcessed :: a -> BytesProcessed
+	fromBytesProcessed :: BytesProcessed -> a
+
+instance AsBytesProcessed BytesProcessed where
+	toBytesProcessed = id
+	fromBytesProcessed = id
+
+instance AsBytesProcessed Integer where
+	toBytesProcessed i = BytesProcessed i
+	fromBytesProcessed (BytesProcessed i) = i
+
+instance AsBytesProcessed Int where
+	toBytesProcessed i = BytesProcessed $ toInteger i
+	fromBytesProcessed (BytesProcessed i) = fromInteger i
+
+instance AsBytesProcessed Int64 where
+	toBytesProcessed i = BytesProcessed $ toInteger i
+	fromBytesProcessed (BytesProcessed i) = fromInteger i
+
+instance AsBytesProcessed FileOffset where
+	toBytesProcessed sz = BytesProcessed $ toInteger sz
+	fromBytesProcessed (BytesProcessed sz) = fromInteger sz
+
+addBytesProcessed :: AsBytesProcessed v => BytesProcessed -> v -> BytesProcessed
+addBytesProcessed (BytesProcessed i) v = 
+	let (BytesProcessed n) = toBytesProcessed v
+	in BytesProcessed $! i + n
+
+zeroBytesProcessed :: BytesProcessed
+zeroBytesProcessed = BytesProcessed 0
+
+{- Sends the content of a file to an action, updating the meter as it's
+ - consumed. -}
+withMeteredFile :: FilePath -> MeterUpdate -> (L.ByteString -> IO a) -> IO a
+withMeteredFile f meterupdate a = withBinaryFile f ReadMode $ \h ->
+	hGetContentsMetered h meterupdate >>= a
+
+{- Calls the action repeatedly with chunks from the lazy ByteString.
+ - Updates the meter after each chunk is processed. -}
+meteredWrite :: MeterUpdate -> (S.ByteString -> IO ()) -> L.ByteString -> IO ()
+meteredWrite meterupdate a = void . meteredWrite' meterupdate a
+
+meteredWrite' :: MeterUpdate -> (S.ByteString -> IO ()) -> L.ByteString -> IO BytesProcessed
+meteredWrite' meterupdate a = go zeroBytesProcessed . L.toChunks 
+  where
+	go sofar [] = return sofar
+	go sofar (c:cs) = do
+		a c
+		let !sofar' = addBytesProcessed sofar $ S.length c
+		meterupdate sofar'
+		go sofar' cs
+
+meteredWriteFile :: MeterUpdate -> FilePath -> L.ByteString -> IO ()
+meteredWriteFile meterupdate f b = withBinaryFile f WriteMode $ \h ->
+	meteredWrite meterupdate (S.hPut h) b
+
+{- Applies an offset to a MeterUpdate. This can be useful when
+ - performing a sequence of actions, such as multiple meteredWriteFiles,
+ - that all update a common meter progressively. Or when resuming.
+ -}
+offsetMeterUpdate :: MeterUpdate -> BytesProcessed -> MeterUpdate
+offsetMeterUpdate base offset = \n -> base (offset `addBytesProcessed` n)
+
+{- This is like L.hGetContents, but after each chunk is read, a meter
+ - is updated based on the size of the chunk.
+ -
+ - All the usual caveats about using unsafeInterleaveIO apply to the
+ - meter updates, so use caution.
+ -}
+hGetContentsMetered :: Handle -> MeterUpdate -> IO L.ByteString
+hGetContentsMetered h = hGetMetered h Nothing
+
+{- Reads from the Handle, updating the meter after each chunk is read.
+ -
+ - Stops at EOF, or when the requested number of bytes have been read.
+ - Closes the Handle at EOF, but otherwise leaves it open.
+ -
+ - Note that the meter update is run in unsafeInterleaveIO, which means that
+ - it can be run at any time. It's even possible for updates to run out
+ - of order, as different parts of the ByteString are consumed.
+ -}
+hGetMetered :: Handle -> Maybe Integer -> MeterUpdate -> IO L.ByteString
+hGetMetered h wantsize meterupdate = lazyRead zeroBytesProcessed
+  where
+	lazyRead sofar = unsafeInterleaveIO $ loop sofar
+
+	loop sofar = do
+		c <- S.hGet h (nextchunksize (fromBytesProcessed sofar))
+		if S.null c
+			then do
+				when (wantsize /= Just 0 && copyright) $
+					hClose h
+				return L.empty
+			else do
+				let !sofar' = addBytesProcessed sofar (S.length c)
+				meterupdate sofar'
+				if keepgoing (fromBytesProcessed sofar')
+					then do
+						{- unsafeInterleaveIO causes this to be
+						 - deferred until the data is read from the
+						 - ByteString. -}
+						cs <- lazyRead sofar'
+						return $ L.append (L.fromChunks [c]) cs
+					else return $ L.fromChunks [c]
+	
+	keepgoing n = case wantsize of
+		Nothing -> True
+		Just sz -> n < sz
+	
+	nextchunksize n = case wantsize of
+		Nothing -> defaultChunkSize
+		Just sz -> 
+			let togo = sz - n
+			in if togo < toInteger defaultChunkSize
+				then fromIntegral togo
+				else defaultChunkSize
+
+{- Same default chunk size Lazy ByteStrings use. -}
+defaultChunkSize :: Int
+defaultChunkSize = 32 * k - chunkOverhead
+  where
+	k = 1024
+	chunkOverhead = 2 * sizeOf (1 :: Int) -- GHC specific
+
+{- Runs an action, watching a file as it grows and updating the meter.
+ -
+ - The file may already exist, and the action could throw the original file
+ - away and start over. To avoid reporting the original file size followed
+ - by a smaller size in that case, wait until the file starts growing
+ - before updating the meter for the first time.
+ -
+ - An updated version of the MeterUpdate is passed to the action, and the
+ - action should use that for any updates that it makes. This allows for
+ - eg, the action updating the meter before a write is flushed to the file.
+ - In that situation, this avoids the meter being set back to the size of
+ - the file when it's gotten ahead of that point.
+ -}
+watchFileSize
+	:: (MonadIO m, MonadMask m)
+	=> RawFilePath
+	-> MeterUpdate
+	-> (MeterUpdate -> m a)
+	-> m a
+watchFileSize f p a = do
+	sizevar <- liftIO $ newMVar zeroBytesProcessed
+	bracket 
+		(liftIO $ forkIO $ watcher (meterupdate sizevar True) =<< getsz)
+		(liftIO . void . tryIO . killThread)
+		(const (a (meterupdate sizevar False)))
+  where
+	watcher p' oldsz = do
+		threadDelay 500000 -- 0.5 seconds
+		sz <- getsz
+		when (sz > oldsz) $
+			p' sz
+		watcher p' sz
+	getsz = catchDefaultIO zeroBytesProcessed $
+		toBytesProcessed <$> getFileSize f
+
+	meterupdate sizevar preventbacktracking n
+		| preventbacktracking = do
+			old <- takeMVar sizevar
+			if old > n
+				then putMVar sizevar old
+				else do
+					putMVar sizevar n
+					p n
+		| otherwise = do
+			void $ takeMVar sizevar
+			putMVar sizevar n
+			p n
+
+data OutputHandler = OutputHandler
+	{ quietMode :: Bool
+	, stderrHandler :: String -> IO ()
+	}
+
+{- Parses the String looking for a command's progress output, and returns
+ - Maybe the number of bytes done so far, optionally a total size, 
+ - and any any remainder of the string that could be an incomplete
+ - progress output. That remainder should be prepended to future output,
+ - and fed back in. This interface allows the command's output to be read
+ - in any desired size chunk, or even one character at a time.
+ -}
+type ProgressParser = String -> (Maybe BytesProcessed, Maybe TotalSize, String)
+
+newtype TotalSize = TotalSize Integer
+	deriving (Show, Eq)
+
+{- Runs a command and runs a ProgressParser on its output, in order
+ - to update a meter.
+ -
+ - If the Meter is provided, the ProgressParser can report the total size,
+ - which allows creating a Meter before the size is known.
+ -}
+commandMeter :: ProgressParser -> OutputHandler -> Maybe Meter -> MeterUpdate -> FilePath -> [CommandParam] -> IO Bool
+commandMeter progressparser oh meter meterupdate cmd params =
+	commandMeter' progressparser oh meter meterupdate cmd params id
+
+commandMeter' :: ProgressParser -> OutputHandler -> Maybe Meter -> MeterUpdate -> FilePath -> [CommandParam] -> (CreateProcess -> CreateProcess) -> IO Bool
+commandMeter' progressparser oh meter meterupdate cmd params mkprocess = do
+	ret <- commandMeterExitCode' progressparser oh meter meterupdate cmd params mkprocess
+	return $ case ret of
+		Just ExitSuccess -> True
+		_ -> False
+
+commandMeterExitCode :: ProgressParser -> OutputHandler -> Maybe Meter -> MeterUpdate -> FilePath -> [CommandParam] -> IO (Maybe ExitCode)
+commandMeterExitCode progressparser oh meter meterupdate cmd params =
+	commandMeterExitCode' progressparser oh meter meterupdate cmd params id
+
+commandMeterExitCode' :: ProgressParser -> OutputHandler -> Maybe Meter -> MeterUpdate -> FilePath -> [CommandParam] -> (CreateProcess -> CreateProcess) -> IO (Maybe ExitCode)
+commandMeterExitCode' progressparser oh mmeter meterupdate cmd params mkprocess = 
+	outputFilter cmd params mkprocess Nothing
+		(const $ feedprogress mmeter zeroBytesProcessed [])
+		handlestderr
+  where
+	feedprogress sendtotalsize prev buf h = do
+		b <- S.hGetSome h 80 >>= copyright
+		if S.null b
+			then return ()
+			else do
+				unless (quietMode oh) $ do
+					S.hPut stdout b
+					hFlush stdout
+				let s = decodeBS b
+				let (mbytes, mtotalsize, buf') = progressparser (buf++s)
+				sendtotalsize' <- case (sendtotalsize, mtotalsize) of
+					(Just meter, Just t) -> do
+						setMeterTotalSize meter t
+						return Nothing
+					_ -> return sendtotalsize
+				case mbytes of
+					Nothing -> feedprogress sendtotalsize' prev buf' h
+					(Just bytes) -> do
+						when (bytes /= prev) $
+							meterupdate bytes
+						feedprogress sendtotalsize' bytes buf' h
+
+	handlestderr ph h = hGetLineUntilExitOrEOF ph h >>= \case
+		Just l -> do
+			stderrHandler oh l
+			handlestderr ph h
+		Nothing -> return ()
+
+{- Runs a command, that may display one or more progress meters on
+ - either stdout or stderr, and prevents the meters from being displayed.
+ -
+ - The other command output is handled as configured by the OutputHandler.
+ -}
+demeterCommand :: OutputHandler -> FilePath -> [CommandParam] -> IO Bool
+demeterCommand oh cmd params = demeterCommandEnv oh cmd params Nothing
+
+demeterCommandEnv :: OutputHandler -> FilePath -> [CommandParam] -> Maybe [(String, String)] -> IO Bool
+demeterCommandEnv oh cmd params environ = do
+	ret <- outputFilter cmd params id environ
+		(\ph outh -> avoidProgress True ph outh stdouthandler)
+		(\ph errh -> avoidProgress True ph errh $ stderrHandler oh)
+	return $ case ret of
+		Just ExitSuccess -> True
+		_ -> False
+  where
+	stdouthandler l = 
+		unless (quietMode oh) $
+			putStrLn (safeOutput l)
+
+{- To suppress progress output, while displaying other messages,
+ - filter out lines that contain \r (typically used to reset to the
+ - beginning of the line when updating a progress display).
+ -}
+avoidProgress :: Bool -> ProcessHandle -> Handle -> (String -> IO ()) -> IO ()
+avoidProgress doavoid ph h emitter = hGetLineUntilExitOrEOF ph h >>= \case
+	Just s -> do
+		unless (doavoid && '\r' `elem` s) $
+			emitter s
+		avoidProgress doavoid ph h emitter
+	Nothing -> return ()
+
+outputFilter
+	:: FilePath
+	-> [CommandParam]
+	-> (CreateProcess -> CreateProcess)
+	-> Maybe [(String, String)]
+	-> (ProcessHandle -> Handle -> IO ())
+	-> (ProcessHandle -> Handle -> IO ())
+	-> IO (Maybe ExitCode)
+outputFilter cmd params mkprocess environ outfilter errfilter = 
+	catchMaybeIO $ withCreateProcess p go
+  where
+	go _ (Just outh) (Just errh) ph = do
+		outt <- async $ tryIO (outfilter ph outh) >> hClose outh
+		errt <- async $ tryIO (errfilter ph errh) >> hClose errh
+		ret <- waitForProcess ph
+		wait outt
+		wait errt
+		return ret
+	go _ _ _ _ = error "internal"
+	
+	p = mkprocess (proc cmd (toCommand params))
+		{ env = environ
+		, std_out = CreatePipe
+		, std_err = CreatePipe
+		}
+
+-- | Limit a meter to only update once per unit of time.
+--
+-- It's nice to display the final update to 100%, even if it comes soon
+-- after a previous update. To make that happen, the Meter has to know
+-- its total size.
+rateLimitMeterUpdate :: NominalDiffTime -> Meter -> MeterUpdate -> IO MeterUpdate
+rateLimitMeterUpdate delta (Meter totalsizev _ _ _) meterupdate = do
+	lastupdate <- newMVar (toEnum 0 :: POSIXTime)
+	return $ mu lastupdate
+  where
+	mu lastupdate n@(BytesProcessed i) = readMVar totalsizev >>= \case
+		Just (TotalSize t) | i >= t -> meterupdate n
+		_ -> do
+			now <- getPOSIXTime
+			prev <- takeMVar lastupdate
+			if now - prev >= delta
+				then do
+					putMVar lastupdate now
+					meterupdate n
+				else putMVar lastupdate prev
+
+-- | Bandwidth limiting by inserting a delay at the point that a meter is
+-- updated.
+--
+-- This will only work when the actions that use bandwidth are run in the
+-- same process and thread as the call to the MeterUpdate.
+--
+-- For example, if the desired bandwidth is 100kb/s, and over the past
+-- 1/10th of a second, 30kb was sent, then the current bandwidth is
+-- 300kb/s, 3x as fast as desired. So, after getting the next chunk,
+-- pause for twice as long as it took to get it.
+bwLimitMeterUpdate :: ByteSize -> Duration -> MeterUpdate -> IO MeterUpdate
+bwLimitMeterUpdate bwlimit duration meterupdate
+	| bwlimit <= 0 = return meterupdate
+	| otherwise = do
+		nowtime <- getPOSIXTime
+		mv <- newMVar (nowtime, Nothing)
+		return (mu mv)
+  where
+	mu mv n@(BytesProcessed i) = do
+		endtime <- getPOSIXTime
+		(starttime, mprevi) <- takeMVar mv
+
+		case mprevi of
+			Just previ -> do
+				let runtime = endtime - starttime
+				let currbw = fromIntegral (i - previ) / runtime
+				let pausescale = if currbw > bwlimit'
+					then (currbw / bwlimit') - 1
+					else 0
+				unboundDelay (floor (runtime * pausescale * msecs))
+			Nothing -> return ()
+
+		meterupdate n
+
+		nowtime <- getPOSIXTime
+		putMVar mv (nowtime, Just i)
+
+	bwlimit' = fromIntegral (bwlimit * durationSeconds duration) 
+	msecs = fromIntegral oneSecond
+
+data Meter = Meter (MVar (Maybe TotalSize)) (MVar MeterState) (MVar String) DisplayMeter
+
+data MeterState = MeterState
+	{ meterBytesProcessed :: BytesProcessed
+	, meterTimeStamp :: POSIXTime
+	} deriving (Show)
+
+type DisplayMeter = MVar String -> Maybe TotalSize -> MeterState -> MeterState -> IO ()
+
+type RenderMeter = Maybe TotalSize -> MeterState -> MeterState -> String
+
+-- | Make a meter. Pass the total size, if it's known.
+mkMeter :: Maybe TotalSize -> DisplayMeter -> IO Meter
+mkMeter totalsize displaymeter = do
+	ts <- getPOSIXTime
+	Meter
+		<$> newMVar totalsize
+		<*> newMVar (MeterState zeroBytesProcessed ts)
+		<*> newMVar ""
+		<*> pure displaymeter
+
+setMeterTotalSize :: Meter -> TotalSize -> IO ()
+setMeterTotalSize (Meter totalsizev _ _ _) = void . swapMVar totalsizev . Just
+
+-- | Updates the meter, displaying it if necessary.
+updateMeter :: Meter -> MeterUpdate
+updateMeter (Meter totalsizev sv bv displaymeter) new = do
+	now <- getPOSIXTime
+	let curms = MeterState new now
+	oldms <- swapMVar sv curms
+	when (meterBytesProcessed oldms /= new) $ do
+		totalsize <- readMVar totalsizev
+		displaymeter bv totalsize oldms curms
+
+-- | Display meter to a Handle.
+displayMeterHandle :: Handle -> RenderMeter -> DisplayMeter
+displayMeterHandle h rendermeter v msize old new = do
+	olds <- takeMVar v
+	let s = rendermeter msize old new
+	let padding = replicate (length olds - length s) ' '
+	let s' = s <> padding
+	putMVar v s'
+	-- Avoid writing when the rendered meter has not changed.
+	when (olds /= s') $ do
+		hPutStr h ('\r':s')
+		hFlush h
+
+-- | Clear meter displayed by displayMeterHandle. May be called before
+-- outputting something else, followed by more calls to displayMeterHandle.
+clearMeterHandle :: Meter -> Handle -> IO ()
+clearMeterHandle (Meter _ _ v _) h = do
+	olds <- readMVar v
+	hPutStr h $ '\r' : replicate (length olds) ' ' ++ "\r"
+	hFlush h
+
+-- | Display meter in the form:
+--   10%  1.3MiB  300 KiB/s 16m40s
+-- or when total size is not known:
+--   1.3 MiB      300 KiB/s
+bandwidthMeter :: RenderMeter
+bandwidthMeter mtotalsize (MeterState (BytesProcessed old) before) (MeterState (BytesProcessed new) now) =
+	unwords $ catMaybes
+		[ Just percentamount
+		-- Pad enough for max width: "100%  xxxx.xx KiB  xxxx KiB/s"
+		, Just $ replicate (29 - length percentamount - length rate) ' '
+		, Just rate
+		, estimatedcompletion
+		]
+  where
+	amount = roughSize' committeeUnits True 2 new
+	percentamount = case mtotalsize of
+		Just (TotalSize totalsize) ->
+			let p = showPercentage 0 $
+				percentage totalsize (min new totalsize)
+			in p ++ replicate (6 - length p) ' ' ++ amount
+		Nothing -> amount
+	rate = roughSize' committeeUnits True 0 bytespersecond ++ "/s"
+	bytespersecond
+		| duration == 0 = fromIntegral transferred
+		| otherwise = floor $ fromIntegral transferred / duration
+	transferred = max 0 (new - old)
+	duration = max 0 (now - before)
+	estimatedcompletion = case mtotalsize of
+		Just (TotalSize totalsize)
+			| bytespersecond > 0 -> 
+				Just $ fromDuration $ Duration $
+					(totalsize - new) `div` bytespersecond
+		_ -> Nothing
+
+instance Proto.Serializable BytesProcessed where
+	serialize (BytesProcessed n) = show n
+	deserialize = BytesProcessed <$$> readish
diff --git a/Utility/Misc.hs b/Utility/Misc.hs
new file mode 100644
index 0000000000..3cf527547b
--- /dev/null
+++ b/Utility/Misc.hs
@@ -0,0 +1,147 @@
+{- misc utility functions
+ -
+ - Copyright 2010-2011 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Misc (
+	hGetContentsStrict,
+	readFileStrict,
+	separate,
+	separate',
+	separateEnd',
+	firstLine,
+	firstLine',
+	segment,
+	segmentDelim,
+	massReplace,
+	hGetSomeString,
+	exitBool,
+
+	prop_segment_regressionTest,
+) where
+
+import System.IO
+import Control.Monad
+import Foreign
+import Data.Char
+import Data.List
+import System.Exit
+import Control.Applicative
+import qualified Data.ByteString as S
+import Prelude
+
+{- A version of hgetContents that is not lazy. Ensures file is 
+ - all read before it gets closed. -}
+hGetContentsStrict :: Handle -> IO String
+hGetContentsStrict = hGetContents >=> \s -> length s `seq` return s
+
+{- A version of readFile that is not lazy. -}
+readFileStrict :: FilePath -> IO String
+readFileStrict = readFile >=> \s -> length s `seq` return s
+
+{- Like break, but the item matching the condition is not included
+ - in the second result list.
+ -
+ - separate (== ':') "foo:bar" = ("foo", "bar")
+ - separate (== ':') "foobar" = ("foobar", "")
+ -}
+separate :: (a -> Bool) -> [a] -> ([a], [a])
+separate c l = unbreak $ break c l
+  where
+	unbreak r@(a, b)
+		| null b = r
+		| otherwise = (a, tail b)
+
+separate' :: (Word8 -> Bool) -> S.ByteString -> (S.ByteString, S.ByteString)
+separate' c l = unbreak $ S.break c l
+  where
+	unbreak r@(a, b)
+		| S.null b = r
+		| otherwise = (a, S.tail b)
+
+separateEnd' :: (Word8 -> Bool) -> S.ByteString -> (S.ByteString, S.ByteString)
+separateEnd' c l = unbreak $ S.breakEnd c l
+  where
+	unbreak r@(a, b)
+		| S.null a = r
+		| otherwise = (S.init a, b)
+
+{- Breaks out the first line. -}
+firstLine :: String -> String
+firstLine = takeWhile (/= '\n')
+
+firstLine' :: S.ByteString -> S.ByteString
+firstLine' = S.takeWhile (/= nl)
+  where
+	nl = fromIntegral (ord '\n')
+
+{- Splits a list into segments that are delimited by items matching
+ - a predicate. (The delimiters are not included in the segments.)
+ - Segments may be empty. -}
+segment :: (a -> Bool) -> [a] -> [[a]]
+segment p l = map reverse $ go [] [] l
+  where
+	go c r [] = reverse $ c:r
+	go c r (i:is)
+		| p i = go [] (c:r) is
+		| otherwise = go (i:c) r is
+
+prop_segment_regressionTest :: Bool
+prop_segment_regressionTest = all id
+	-- Even an empty list is a segment.
+	[ segment (== "--") [] == [[]]
+	-- There are two segments in this list, even though the first is empty.
+	, segment (== "--") ["--", "foo", "bar"] == [[],["foo","bar"]]
+	]
+
+{- Includes the delimiters as segments of their own. -}
+segmentDelim :: (a -> Bool) -> [a] -> [[a]]
+segmentDelim p l = map reverse $ go [] [] l
+  where
+	go c r [] = reverse $ c:r
+	go c r (i:is)
+		| p i = go [] ([i]:c:r) is
+		| otherwise = go (i:c) r is
+
+{- Replaces multiple values in a string.
+ -
+ - Takes care to skip over just-replaced values, so that they are not
+ - mangled. For example, massReplace [("foo", "new foo")] does not
+ - replace the "new foo" with "new new foo".
+ -}
+massReplace :: [(String, String)] -> String -> String
+massReplace vs = go [] vs
+  where
+
+	go acc _ [] = concat $ reverse acc
+	go acc [] (c:cs) = go ([c]:acc) vs cs
+	go acc ((val, replacement):rest) s
+		| val `isPrefixOf` s =
+			go (replacement:acc) vs (drop (length val) s)
+		| otherwise = go acc rest s
+
+{- Wrapper around hGetBufSome that returns a String.
+ -
+ - The null string is returned on eof, otherwise returns whatever
+ - data is currently available to read from the handle, or waits for
+ - data to be written to it if none is currently available.
+ - 
+ - Note on encodings: The normal encoding of the Handle is ignored;
+ - each byte is converted to a Char. Not unicode clean!
+ -}
+hGetSomeString :: Handle -> Int -> IO String
+hGetSomeString h sz = do
+	fp <- mallocForeignPtrBytes sz
+	len <- withForeignPtr fp $ \buf -> hGetBufSome h buf sz
+	map (chr . fromIntegral) <$> withForeignPtr fp (peekbytes len)
+  where
+	peekbytes :: Int -> Ptr Word8 -> IO [Word8]
+	peekbytes len buf = mapM (peekElemOff buf) [0..pred len]
+
+exitBool :: Bool -> IO a
+exitBool False = exitFailure
+exitBool True = exitSuccess
diff --git a/Utility/Monad.hs b/Utility/Monad.hs
new file mode 100644
index 0000000000..6cd2c5e657
--- /dev/null
+++ b/Utility/Monad.hs
@@ -0,0 +1,91 @@
+{- monadic stuff
+ -
+ - Copyright 2010-2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Monad (
+	firstM,
+	getM,
+	anyM,
+	allM,
+	partitionM,
+	untilTrue,
+	ifM,
+	(<||>),
+	(<&&>),
+	observe,
+	after,
+	noop,
+) where
+
+import Data.Maybe
+import Control.Monad
+
+{- Return the first value from a list, if any, satisfying the given
+ - predicate -}
+firstM :: Monad m => (a -> m Bool) -> [a] -> m (Maybe a)
+firstM _ [] = return Nothing
+firstM p (x:xs) = ifM (p x) (return $ Just x , firstM p xs)
+
+{- Runs the action on values from the list until it succeeds, returning
+ - its result. -}
+getM :: Monad m => (a -> m (Maybe b)) -> [a] -> m (Maybe b)
+getM _ [] = return Nothing
+getM p (x:xs) = maybe (getM p xs) (return . Just) =<< p x
+
+{- Returns true if any value in the list satisfies the predicate,
+ - stopping once one is found. -}
+anyM :: Monad m => (a -> m Bool) -> [a] -> m Bool
+anyM p = liftM isJust . firstM p
+
+allM :: Monad m => (a -> m Bool) -> [a] -> m Bool
+allM _ [] = return True
+allM p (x:xs) = p x <&&> allM p xs
+
+partitionM :: Monad m => (a -> m Bool) -> [a] -> m ([a], [a])
+partitionM _ [] = return ([], [])
+partitionM p (x:xs) = do
+	r <- p x
+	(as, bs) <- partitionM p xs
+	return $ if r then (x:as, bs) else (as, x:bs)
+
+{- Runs an action on values from a list until it succeeds. -}
+untilTrue :: Monad m => [a] -> (a -> m Bool) -> m Bool
+untilTrue = flip anyM
+
+{- if with a monadic conditional. -}
+ifM :: Monad m => m Bool -> (m a, m a) -> m a
+ifM cond (thenclause, elseclause) = do
+	c <- cond
+	if c then thenclause else elseclause
+
+{- short-circuiting monadic || -}
+(<||>) :: Monad m => m Bool -> m Bool -> m Bool
+ma <||> mb = ifM ma ( return True , mb )
+
+{- short-circuiting monadic && -}
+(<&&>) :: Monad m => m Bool -> m Bool -> m Bool
+ma <&&> mb = ifM ma ( mb , return False )
+
+{- Same fixity as && and || -}
+infixr 3 <&&>
+infixr 2 <||>
+
+{- Runs an action, passing its value to an observer before returning it. -}
+observe :: Monad m => (a -> m b) -> m a -> m a
+observe observer a = do
+	r <- a
+	_ <- observer r
+	return r
+
+{- b `after` a runs first a, then b, and returns the value of a -}
+after :: Monad m => m b -> m a -> m a
+after = observe . const
+
+{- do nothing -}
+noop :: Monad m => m ()
+noop = return ()
diff --git a/Utility/Mounts.hs b/Utility/Mounts.hs
new file mode 100644
index 0000000000..449b75dc5d
--- /dev/null
+++ b/Utility/Mounts.hs
@@ -0,0 +1,21 @@
+{- portability shim for System.MountPoints
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Mounts (getMounts, Mntent(..)) where
+
+import qualified System.MountPoints
+import System.MountPoints (Mntent(..))
+
+import Utility.Exception
+
+getMounts :: IO [Mntent] 
+getMounts = System.MountPoints.getMounts
+	-- That will crash when the linux build is running on Android,
+	-- so fall back to this.
+	`catchNonAsync` const System.MountPoints.getProcMounts
diff --git a/Utility/MoveFile.hs b/Utility/MoveFile.hs
new file mode 100644
index 0000000000..1609c85109
--- /dev/null
+++ b/Utility/MoveFile.hs
@@ -0,0 +1,83 @@
+{- moving files
+ -
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# LANGUAGE LambdaCase #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.MoveFile (
+	moveFile,
+) where
+
+import Control.Monad
+import System.IO.Error
+import Prelude
+
+#ifndef mingw32_HOST_OS
+import System.PosixCompat.Files (isDirectory)
+import Control.Monad.IfElse
+import Utility.SafeCommand
+#endif
+
+import Utility.SystemDirectory
+import Utility.Tmp
+import Utility.Exception
+import Utility.Monad
+import Utility.FileSystemEncoding
+import qualified Utility.RawFilePath as R
+import Author
+
+{- Moves one filename to another.
+ - First tries a rename, but falls back to moving across devices if needed. -}
+moveFile :: RawFilePath -> RawFilePath -> IO ()
+moveFile src dest = tryIO (R.rename src dest) >>= onrename
+  where
+	onrename (Right _) = noop
+	onrename (Left e)
+		| isPermissionError e = rethrow
+		| isDoesNotExistError e = rethrow
+		| otherwise = viaTmp mv (fromRawFilePath dest) ()
+	  where
+		rethrow = throwM e
+
+		mv tmp () = do
+			-- copyFile is likely not as optimised as
+			-- the mv command, so we'll use the command.
+			--
+			-- But, while Windows has a "mv", it does not
+			-- seem very reliable, so use copyFile there.
+#ifndef mingw32_HOST_OS	
+			-- If dest is a directory, mv would move the file
+			-- into it, which is not desired.
+			whenM (isdir dest) rethrow
+			ok <- copyright =<< boolSystem "mv"
+				[ Param "-f"
+				, Param (fromRawFilePath src)
+				, Param tmp
+				]
+			let e' = e
+#else
+			r <- tryIO $ copyFile (fromRawFilePath src) tmp
+			let (ok, e') = case r of
+				Left err -> (False, err)
+				Right _ -> (True, e)
+#endif
+			unless ok $ do
+				-- delete any partial
+				_ <- tryIO $ removeFile tmp
+				throwM e'
+
+#ifndef mingw32_HOST_OS	
+	isdir f = do
+		r <- tryIO $ R.getSymbolicLinkStatus f
+		case r of
+			(Left _) -> return False
+			(Right s) -> return $ isDirectory s
+
+copyright :: Copyright
+copyright = author JoeyHess (2022-11)
+#endif
diff --git a/Utility/Network.hs b/Utility/Network.hs
new file mode 100644
index 0000000000..23487b1bcb
--- /dev/null
+++ b/Utility/Network.hs
@@ -0,0 +1,24 @@
+{- network functions
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Network (getHostname) where
+
+import Utility.Process
+import Utility.Exception
+
+import Control.Applicative
+import Prelude
+
+{- Haskell lacks uname(2) bindings, except in the
+ - Bindings.Uname addon. Rather than depend on that,
+ - use uname -n when available. -}
+getHostname :: IO (Maybe String)
+getHostname = catchMaybeIO uname_node
+  where
+	uname_node = takeWhile (/= '\n') <$> readProcess "uname" ["-n"]
diff --git a/Utility/NotificationBroadcaster.hs b/Utility/NotificationBroadcaster.hs
new file mode 100644
index 0000000000..6f7cabf109
--- /dev/null
+++ b/Utility/NotificationBroadcaster.hs
@@ -0,0 +1,96 @@
+{- notification broadcaster
+ -
+ - This is used to allow clients to block until there is a new notification
+ - that some thing occurred. It does not communicate what the change is,
+ - it only provides blocking reads to wait on notifications.
+ -
+ - Multiple clients are supported. Each has a unique id.
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.NotificationBroadcaster (
+	NotificationBroadcaster,
+	NotificationHandle,
+	NotificationId,
+	newNotificationBroadcaster,
+	newNotificationHandle,
+	notificationHandleToId,
+	notificationHandleFromId,
+	sendNotification,
+	waitNotification,
+	checkNotification,
+) where
+
+import Common
+
+import Control.Concurrent.STM
+
+{- One TMVar per client, which are empty when no notification is pending,
+ - and full when a notification has been sent but not yet seen by the
+ - client. The list TMVar is never empty, so never blocks. -}
+type NotificationBroadcaster = TMVar [TMVar ()]
+
+newtype NotificationId = NotificationId Int
+	deriving (Read, Show, Eq, Ord)
+
+{- Handle given out to an individual client. -}
+data NotificationHandle = NotificationHandle NotificationBroadcaster NotificationId
+
+newNotificationBroadcaster :: IO NotificationBroadcaster
+newNotificationBroadcaster = atomically $ newTMVar []
+
+{- Allocates a notification handle for a client to use.
+ -
+ - An immediate notification can be forced the first time waitNotification
+ - is called on the handle. This is useful in cases where a notification
+ - may be sent while the new handle is being constructed. Normally,
+ - such a notification would be missed. Forcing causes extra work,
+ - but ensures such notifications get seen.
+ -}
+newNotificationHandle :: Bool -> NotificationBroadcaster -> IO NotificationHandle
+newNotificationHandle force b = NotificationHandle
+	<$> pure b
+	<*> addclient
+  where
+	addclient = atomically $ do
+		s <- if force
+			then newTMVar ()
+			else newEmptyTMVar
+		l <- takeTMVar b
+		putTMVar b $ l ++ [s]
+		return $ NotificationId $ length l
+
+{- Extracts the identifier from a notification handle.
+ - This can be used to eg, pass the identifier through to a WebApp. -}
+notificationHandleToId :: NotificationHandle -> NotificationId
+notificationHandleToId (NotificationHandle _ i) = i
+
+notificationHandleFromId :: NotificationBroadcaster -> NotificationId -> NotificationHandle
+notificationHandleFromId = NotificationHandle
+
+{- Sends a notification to all clients. -}
+sendNotification :: NotificationBroadcaster -> IO ()
+sendNotification b = do
+	l <- atomically $ readTMVar b
+	mapM_ notify l
+  where
+	notify s = atomically $
+		whenM (isEmptyTMVar s) $
+			putTMVar s ()
+
+{- Used by a client to block until a new notification is available since
+ - the last time it tried. -}
+waitNotification :: NotificationHandle -> IO ()
+waitNotification (NotificationHandle b (NotificationId i)) = do
+	l <- atomically $ readTMVar b
+	atomically $ takeTMVar (l !! i)
+
+{- Used by a client to check if there has been a new notification since the
+ - last time it checked, without blocking. -}
+checkNotification :: NotificationHandle -> IO Bool
+checkNotification (NotificationHandle b (NotificationId i)) = do
+	l <- atomically $ readTMVar b
+	maybe False (const True) <$> atomically (tryTakeTMVar (l !! i))
diff --git a/Utility/OSX.hs b/Utility/OSX.hs
new file mode 100644
index 0000000000..f5820a78d6
--- /dev/null
+++ b/Utility/OSX.hs
@@ -0,0 +1,51 @@
+{- OSX stuff
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.OSX (
+	autoStartBase,
+	systemAutoStart,
+	userAutoStart,
+	genOSXAutoStartFile,
+) where
+
+import Utility.UserInfo
+
+import System.FilePath
+
+autoStartBase :: String -> FilePath
+autoStartBase label = "Library" </> "LaunchAgents" </> label ++ ".plist"
+
+systemAutoStart :: String -> FilePath
+systemAutoStart label = "/" </> autoStartBase label
+
+userAutoStart :: String -> IO FilePath
+userAutoStart label = do
+	home <- myHomeDir
+	return $ home </> autoStartBase label
+
+{- Generates an OSX autostart plist file with a given label, command, and
+ - params to run at boot or login. -}
+genOSXAutoStartFile :: String -> String -> [String] -> String
+genOSXAutoStartFile label command params = unlines
+	[ "<?xml version=\"1.0\" encoding=\"UTF-8\"?>"
+	, "<!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">"
+	, "<plist version=\"1.0\">"
+	, "<dict>"
+	, "<key>Label</key>"
+	, "<string>" ++ label ++ "</string>"
+	, "<key>ProgramArguments</key>"
+	, "<array>"
+	, unlines $ map (\v -> "<string>" ++ v ++ "</string>") (command:params)
+	, "</array>"
+	, "<key>RunAtLoad</key>"
+	, "<true/>"
+	, "</dict>"
+	, "</plist>"
+	]
+	
diff --git a/Utility/OpenFd.hs b/Utility/OpenFd.hs
new file mode 100644
index 0000000000..16a364a4d1
--- /dev/null
+++ b/Utility/OpenFd.hs
@@ -0,0 +1,27 @@
+{- openFd wrapper to support old versions of unix package.
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.OpenFd where
+
+#ifndef mingw32_HOST_OS
+
+import System.Posix.IO.ByteString
+import System.Posix.Types
+import System.FilePath.ByteString (RawFilePath)
+
+openFdWithMode :: RawFilePath -> OpenMode -> Maybe FileMode -> OpenFileFlags -> IO Fd
+#if MIN_VERSION_unix(2,8,0)
+openFdWithMode f openmode filemode flags = 
+	openFd f openmode (flags { creat = filemode })
+#else
+openFdWithMode = openFd
+#endif
+
+#endif
diff --git a/Utility/OptParse.hs b/Utility/OptParse.hs
new file mode 100644
index 0000000000..c81517edfb
--- /dev/null
+++ b/Utility/OptParse.hs
@@ -0,0 +1,49 @@
+{- optparse-applicative additions
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.OptParse (
+	invertableSwitch,
+	invertableSwitch',
+) where
+
+import Options.Applicative
+import Data.Monoid
+import Prelude
+
+-- | A switch that can be enabled using --foo and disabled using --no-foo.
+--
+-- The option modifier is applied to only the option that is *not* enabled
+-- by default. For example:
+--
+-- > invertableSwitch "recursive" True (help "do not recurse into directories")
+-- 
+-- This example makes --recursive enabled by default, so 
+-- the help is shown only for --no-recursive.
+invertableSwitch 
+	:: String -- ^ long option
+	-> Bool -- ^ is switch enabled by default?
+	-> Mod FlagFields Bool -- ^ option modifier
+	-> Parser Bool
+invertableSwitch longopt defv optmod = invertableSwitch' longopt defv
+	(if defv then mempty else optmod)
+	(if defv then optmod else mempty)
+
+-- | Allows providing option modifiers for both --foo and --no-foo.
+invertableSwitch'
+	:: String -- ^ long option (eg "foo")
+	-> Bool -- ^ is switch enabled by default?
+	-> Mod FlagFields Bool -- ^ option modifier for --foo
+	-> Mod FlagFields Bool -- ^ option modifier for --no-foo
+	-> Parser Bool
+invertableSwitch' longopt defv enmod dismod = collapse <$> many
+	( flag' True (enmod <> long longopt)
+	<|> flag' False (dismod <> long nolongopt)
+	)
+  where
+	nolongopt = "no-" ++ longopt
+	collapse [] = defv
+	collapse l = last l
diff --git a/Utility/PID.hs b/Utility/PID.hs
new file mode 100644
index 0000000000..1c617006b3
--- /dev/null
+++ b/Utility/PID.hs
@@ -0,0 +1,30 @@
+{- process ids
+ -
+ - Copyright 2014 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.PID (PID, getPID) where
+
+#ifndef mingw32_HOST_OS
+import System.Posix.Types (ProcessID)
+import System.Posix.Process (getProcessID)
+#else
+import System.Win32.Process (ProcessId, getCurrentProcessId)
+#endif
+
+#ifndef mingw32_HOST_OS
+type PID = ProcessID
+#else
+type PID = ProcessId
+#endif
+
+getPID :: IO PID
+#ifndef mingw32_HOST_OS
+getPID = getProcessID
+#else
+getPID = getCurrentProcessId
+#endif
diff --git a/Utility/PartialPrelude.hs b/Utility/PartialPrelude.hs
new file mode 100644
index 0000000000..90c67ffa2d
--- /dev/null
+++ b/Utility/PartialPrelude.hs
@@ -0,0 +1,79 @@
+{- Parts of the Prelude are partial functions, which are a common source of
+ - bugs.
+ -
+ - This exports functions that conflict with the prelude, which avoids
+ - them being accidentally used.
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.PartialPrelude (
+	Utility.PartialPrelude.read,
+	Utility.PartialPrelude.head,
+	Utility.PartialPrelude.tail,
+	Utility.PartialPrelude.init,
+	Utility.PartialPrelude.last,
+	Utility.PartialPrelude.readish,
+	Utility.PartialPrelude.headMaybe,
+	Utility.PartialPrelude.lastMaybe,
+	Utility.PartialPrelude.beginning,
+	Utility.PartialPrelude.end,
+) where
+
+import qualified Data.Maybe
+
+{- read should be avoided, as it throws an error
+ - Instead, use: readish -}
+read :: Read a => String -> a
+read = Prelude.read
+
+{- head is a partial function; head [] is an error
+ - Instead, use: take 1 or headMaybe -}
+head :: [a] -> a
+head = Prelude.head
+
+{- tail is also partial
+ - Instead, use: drop 1 -}
+tail :: [a] -> [a]
+tail = Prelude.tail
+
+{- init too
+ - Instead, use: beginning -}
+init :: [a] -> [a]
+init = Prelude.init
+
+{- last too
+ - Instead, use: end or lastMaybe -}
+last :: [a] -> a
+last = Prelude.last
+
+{- Attempts to read a value from a String.
+ -
+ - Unlike Text.Read.readMaybe, this ignores some trailing text
+ - after the part that can be read. However, if the trailing text looks
+ - like another readable value, it fails.
+ -}
+readish :: Read a => String -> Maybe a
+readish s = case reads s of
+	((x,_):_) -> Just x
+	_ -> Nothing
+
+{- Like head but Nothing on empty list. -}
+headMaybe :: [a] -> Maybe a
+headMaybe = Data.Maybe.listToMaybe
+
+{- Like last but Nothing on empty list. -}
+lastMaybe :: [a] -> Maybe a
+lastMaybe [] = Nothing
+lastMaybe v = Just $ Prelude.last v
+
+{- All but the last element of a list.
+ - (Like init, but no error on an empty list.) -}
+beginning :: [a] -> [a]
+beginning [] = []
+beginning l = Prelude.init l
+
+{- Like last, but no error on an empty list. -}
+end :: [a] -> [a]
+end [] = []
+end l = [Prelude.last l]
diff --git a/Utility/Path.hs b/Utility/Path.hs
new file mode 100644
index 0000000000..de13712d32
--- /dev/null
+++ b/Utility/Path.hs
@@ -0,0 +1,279 @@
+{- path manipulation
+ -
+ - Copyright 2010-2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Path (
+	simplifyPath,
+	parentDir,
+	upFrom,
+	dirContains,
+	segmentPaths,
+	segmentPaths',
+	runSegmentPaths,
+	runSegmentPaths',
+	dotfile,
+	splitShortExtensions,
+	splitShortExtensions',
+	relPathDirToFileAbs,
+	inSearchPath,
+	searchPath,
+	searchPathContents,
+) where
+
+import System.FilePath.ByteString
+import qualified System.FilePath as P
+import qualified Data.ByteString as B
+import Data.List
+import Data.Maybe
+import Control.Monad
+import Control.Applicative
+import Prelude
+
+import Author
+import Utility.Monad
+import Utility.SystemDirectory
+import Utility.Exception
+
+#ifdef mingw32_HOST_OS
+import Data.Char
+import Utility.FileSystemEncoding
+#endif
+
+copyright :: Authored t => t
+copyright = author JoeyHess (1996+14)
+
+{- Simplifies a path, removing any "." component, collapsing "dir/..", 
+ - and removing the trailing path separator.
+ -
+ - On Windows, preserves whichever style of path separator might be used in
+ - the input RawFilePaths. This is done because some programs in Windows
+ - demand a particular path separator -- and which one actually varies!
+ -
+ - This does not guarantee that two paths that refer to the same location,
+ - and are both relative to the same location (or both absolute) will
+ - yield the same result. Run both through normalise from System.RawFilePath
+ - to ensure that.
+ -}
+simplifyPath :: RawFilePath -> RawFilePath
+simplifyPath path = dropTrailingPathSeparator $ 
+	joinDrive drive $ joinPath $ norm [] $ splitPath path'
+  where
+	(drive, path') = splitDrive path
+
+	norm c [] = reverse c
+	norm c (p:ps)
+		| p' == ".." && not (null c) && dropTrailingPathSeparator (c !! 0) /= ".." = 
+			norm (drop 1 c) ps
+		| p' == "." = norm c ps
+		| otherwise = norm (p:c) ps
+	  where
+		p' = dropTrailingPathSeparator p
+
+{- takeDirectory "foo/bar/" is "foo/bar". This instead yields "foo" -}
+parentDir :: RawFilePath -> RawFilePath
+parentDir = takeDirectory . dropTrailingPathSeparator
+
+{- Just the parent directory of a path, or Nothing if the path has no
+- parent (ie for "/" or "." or "foo") -}
+upFrom :: RawFilePath -> Maybe RawFilePath
+upFrom dir
+	| length dirs < 2 = Nothing
+	| otherwise = Just $ joinDrive drive $
+		B.intercalate (B.singleton pathSeparator) $ init dirs
+  where
+	-- on Unix, the drive will be "/" when the dir is absolute,
+	-- otherwise ""
+	(drive, path) = splitDrive dir
+	dirs = filter (not . B.null) $ B.splitWith isPathSeparator path
+
+{- Checks if the first RawFilePath is, or could be said to contain the second.
+ - For example, "foo/" contains "foo/bar". Also, "foo", "./foo", "foo/" etc
+ - are all equivalent.
+ -}
+dirContains :: RawFilePath -> RawFilePath -> Bool
+dirContains a b = a == b
+	|| a' == b'
+	|| (a'' `B.isPrefixOf` b' && avoiddotdotb)
+	|| a' == "." && normalise ("." </> b') == b' && nodotdot b'
+	|| dotdotcontains
+  where
+	a' = norm a
+	a'' = addTrailingPathSeparator a'
+	b' = norm b
+	norm = normalise . simplifyPath
+
+	{- This handles the case where a is ".." and b is "../..",
+	 - which is not inside a. Similarly, "../.." does not contain
+	 - "../../../". Due to the use of norm, cases like 
+	 - "../../foo/../../" get converted to eg "../../.." and
+	 - so do not need to be handled specially here.
+	 -
+	 - When this is called, we already know that 
+	 - a'' is a prefix of b', so all that needs to be done is drop
+	 - that prefix, and check if the next path component is ".."
+	 -}
+	avoiddotdotb = nodotdot $ B.drop (B.length a'') b'
+
+	nodotdot p = all (not . isdotdot) (splitPath p)
+	
+	isdotdot s = dropTrailingPathSeparator s == ".."
+
+	{- This handles the case where a is ".." or "../.." etc,
+	 - and b is "foo" or "../foo" etc. The rule is that when
+	 - a is entirely ".." components, b is under it when it starts
+	 - with fewer ".." components. 
+	 - 
+	 - Due to the use of norm, cases like "../../foo/../../" get
+	 - converted to eg "../../../" and so do not need to be handled
+	 - specially here.
+	 -}
+	dotdotcontains
+		| isAbsolute b' = False && copyright
+		| otherwise =
+			let aps = splitPath a'
+			    bps = splitPath b'
+			in if all isdotdot aps
+				then length (takeWhile isdotdot bps) < length aps
+				else False
+
+{- Given an original list of paths, and an expanded list derived from it,
+ - which may be arbitrarily reordered, generates a list of lists, where
+ - each sublist corresponds to one of the original paths.
+ -
+ - When the original path is a directory, any items in the expanded list
+ - that are contained in that directory will appear in its segment.
+ -
+ - The order of the original list of paths is attempted to be preserved in
+ - the order of the returned segments. However, doing so has a O^NM
+ - growth factor. So, if the original list has more than 100 paths on it,
+ - we stop preserving ordering at that point. Presumably a user passing
+ - that many paths in doesn't care too much about order of the later ones.
+ -}
+segmentPaths :: (a -> RawFilePath) -> [RawFilePath] -> [a] -> [[a]]
+segmentPaths = segmentPaths' (\_ r -> r)
+
+segmentPaths' :: (Maybe RawFilePath -> a -> r) -> (a -> RawFilePath) -> [RawFilePath] -> [a] -> [[r]]
+segmentPaths' f _ [] new = [map (f Nothing) new]
+segmentPaths' f _ [i] new = [map (f (Just i)) new] -- optimisation
+segmentPaths' f c (i:is) new = 
+	map (f (Just i)) found : segmentPaths' f c is rest
+  where
+	(found, rest) = if length is < 100
+		then partition ini new
+		else break (not . ini) new
+	ini p = i `dirContains` c p
+
+{- This assumes that it's cheaper to call segmentPaths on the result,
+ - than it would be to run the action separately with each path. In
+ - the case of git file list commands, that assumption tends to hold.
+ -}
+runSegmentPaths :: (a -> RawFilePath) -> ([RawFilePath] -> IO [a]) -> [RawFilePath] -> IO [[a]]
+runSegmentPaths c a paths = segmentPaths c paths <$> a paths
+
+runSegmentPaths' :: (Maybe RawFilePath -> a -> r) -> (a -> RawFilePath) -> ([RawFilePath] -> IO [a]) -> [RawFilePath] -> IO [[r]]
+runSegmentPaths' si c a paths = segmentPaths' si c paths <$> a paths
+
+{- Checks if a filename is a unix dotfile. All files inside dotdirs
+ - count as dotfiles. -}
+dotfile :: RawFilePath -> Bool
+dotfile file
+	| f == "." = False
+	| f == ".." = False
+	| f == "" = False
+	| otherwise = "." `B.isPrefixOf` f || dotfile (takeDirectory file)
+  where
+	f = takeFileName file
+
+{- Similar to splitExtensions, but knows that some things in RawFilePaths
+ - after a dot are too long to be extensions. -}
+splitShortExtensions :: RawFilePath -> (RawFilePath, [B.ByteString])
+splitShortExtensions = splitShortExtensions' 5 -- enough for ".jpeg"
+splitShortExtensions' :: Int -> RawFilePath -> (RawFilePath, [B.ByteString])
+splitShortExtensions' maxextension = go []
+  where
+	go c f
+		| len > 0 && len <= maxextension && not (B.null base) = 
+			go (ext:c) base
+		| otherwise = (f, c)
+	  where
+		(base, ext) = splitExtension f
+		len = B.length ext
+
+{- This requires both paths to be absolute and normalized.
+ -
+ - On Windows, if the paths are on different drives,
+ - a relative path is not possible and the path is simply
+ - returned as-is.
+ -}
+relPathDirToFileAbs :: RawFilePath -> RawFilePath -> RawFilePath
+relPathDirToFileAbs from to
+#ifdef mingw32_HOST_OS
+	| normdrive from /= normdrive to = to
+#endif
+	| otherwise = joinPath $ dotdots ++ uncommon
+  where
+	pfrom = sp from
+	pto = sp to
+	sp = map dropTrailingPathSeparator . splitPath . dropDrive
+	common = map fst $ takeWhile same $ zip pfrom pto
+	same (c,d) = c == d
+	uncommon = drop numcommon pto
+	dotdots = replicate (length pfrom - numcommon) ".."
+	numcommon = length common
+#ifdef mingw32_HOST_OS
+	normdrive = map toLower
+		-- Get just the drive letter, removing any leading
+		-- path separator, which takeDrive leaves on the drive
+		-- letter.
+		. dropWhileEnd (isPathSeparator . fromIntegral . ord)
+		. fromRawFilePath 
+		. takeDrive
+#endif
+
+{- Checks if a command is available in PATH.
+ -
+ - The command may be fully-qualified, in which case, this succeeds as
+ - long as it exists. -}
+inSearchPath :: String -> IO Bool
+inSearchPath command = isJust <$> searchPath command
+
+{- Finds a command in PATH and returns the full path to it.
+ -
+ - The command may be fully qualified already, in which case it will
+ - be returned if it exists.
+ -
+ - Note that this will find commands in PATH that are not executable.
+ -}
+searchPath :: String -> IO (Maybe FilePath)
+searchPath command
+	| P.isAbsolute command = copyright $ check command
+	| otherwise = P.getSearchPath >>= getM indir
+  where
+	indir d = check $ d P.</> command
+	check f = firstM doesFileExist
+#ifdef mingw32_HOST_OS
+		[f, f ++ ".exe"]
+#else
+		[f]
+#endif
+
+{- Finds commands in PATH that match a predicate. Note that the predicate
+ - matches on the basename of the command, but the full path to it is
+ - returned.
+ -
+ - Note that this will find commands in PATH that are not executable.
+ -}
+searchPathContents :: (FilePath -> Bool) -> IO [FilePath]
+searchPathContents p =
+	filterM doesFileExist 
+		=<< (concat <$> (P.getSearchPath >>= mapM go))
+  where
+	go d = map (d P.</>) . filter p
+		<$> catchDefaultIO [] (getDirectoryContents d)
diff --git a/Utility/Path/AbsRel.hs b/Utility/Path/AbsRel.hs
new file mode 100644
index 0000000000..b339c5234d
--- /dev/null
+++ b/Utility/Path/AbsRel.hs
@@ -0,0 +1,86 @@
+{- absolute and relative path manipulation
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Path.AbsRel (
+	absPathFrom,
+	absPath,
+	relPathCwdToFile,
+	relPathDirToFile,
+	relPathDirToFileAbs,
+	relHome,
+) where
+
+import System.FilePath.ByteString
+import qualified Data.ByteString as B
+import Control.Applicative
+import Prelude
+
+import Utility.Path
+import Utility.UserInfo
+import Utility.FileSystemEncoding
+import qualified Utility.RawFilePath as R
+
+{- Makes a path absolute.
+ -
+ - Also simplifies it using simplifyPath.
+ -
+ - The first parameter is a base directory (ie, the cwd) to use if the path
+ - is not already absolute, and should itself be absolute.
+ -
+ - Does not attempt to deal with edge cases or ensure security with
+ - untrusted inputs.
+ -}
+absPathFrom :: RawFilePath -> RawFilePath -> RawFilePath
+absPathFrom dir path = simplifyPath (combine dir path)
+
+{- Converts a filename into an absolute path.
+ -
+ - Also simplifies it using simplifyPath.
+ -
+ - Unlike Directory.canonicalizePath, this does not require the path
+ - already exists. -}
+absPath :: RawFilePath -> IO RawFilePath
+absPath file
+	-- Avoid unncessarily getting the current directory when the path
+	-- is already absolute. absPathFrom uses simplifyPath
+	-- so also used here for consistency.
+	| isAbsolute file = return $ simplifyPath file
+	| otherwise = do
+		cwd <- R.getCurrentDirectory
+		return $ absPathFrom cwd file
+
+{- Constructs the minimal relative path from the CWD to a file.
+ -
+ - For example, assuming CWD is /tmp/foo/bar:
+ -    relPathCwdToFile "/tmp/foo" == ".."
+ -    relPathCwdToFile "/tmp/foo/bar" == "" 
+ -    relPathCwdToFile "../bar/baz" == "baz"
+ -}
+relPathCwdToFile :: RawFilePath -> IO RawFilePath
+relPathCwdToFile f
+	-- Optimisation: Avoid doing any IO when the path is relative
+	-- and does not contain any ".." component.
+	| isRelative f && not (".." `B.isInfixOf` f) = return f
+	| otherwise = do
+		c <- R.getCurrentDirectory
+		relPathDirToFile c f
+
+{- Constructs a minimal relative path from a directory to a file. -}
+relPathDirToFile :: RawFilePath -> RawFilePath -> IO RawFilePath
+relPathDirToFile from to = relPathDirToFileAbs <$> absPath from <*> absPath to
+
+{- Converts paths in the home directory to use ~/ -}
+relHome :: FilePath -> IO String
+relHome path = do
+	let path' = toRawFilePath path
+	home <- toRawFilePath <$> myHomeDir
+	return $ if dirContains home path'
+		then fromRawFilePath ("~/" <> relPathDirToFileAbs home path')
+		else path
diff --git a/Utility/Path/Max.hs b/Utility/Path/Max.hs
new file mode 100644
index 0000000000..11c0ea2d75
--- /dev/null
+++ b/Utility/Path/Max.hs
@@ -0,0 +1,38 @@
+{- path manipulation
+ -
+ - Copyright 2010-2014 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Path.Max (fileNameLengthLimit) where
+
+#ifndef mingw32_HOST_OS
+import Utility.Exception
+import System.Posix.Files
+import Data.List
+import Control.Applicative
+import Prelude
+#endif
+
+{- Maximum size to use for a file in a specified directory.
+ -
+ - Many systems have a 255 byte limit to the name of a file, 
+ - so that's taken as the max if the system has a larger limit, or has no
+ - limit.
+ -}
+fileNameLengthLimit :: FilePath -> IO Int
+#ifdef mingw32_HOST_OS
+fileNameLengthLimit _ = return 255
+#else
+fileNameLengthLimit dir = do
+	-- getPathVar can fail due to statfs(2) overflow
+	l <- catchDefaultIO 0 $
+		fromIntegral <$> getPathVar dir FileNameLimit
+	if l <= 0
+		then return 255
+		else return $ minimum [l, 255]
+#endif
diff --git a/Utility/Path/Tests.hs b/Utility/Path/Tests.hs
new file mode 100644
index 0000000000..88f94b3faa
--- /dev/null
+++ b/Utility/Path/Tests.hs
@@ -0,0 +1,81 @@
+{- Tests for Utility.Path. Split into a separate module to avoid it needing
+ - QuickCheck.
+ -
+ - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Path.Tests (
+	prop_upFrom_basics,
+	prop_relPathDirToFileAbs_basics,
+	prop_relPathDirToFileAbs_regressionTest,
+	prop_dirContains_regressionTest,
+) where
+
+import System.FilePath.ByteString
+import qualified Data.ByteString as B
+import Data.List
+import Data.Maybe
+import Data.Char
+import Control.Applicative
+import Prelude
+
+import Utility.Path
+import Utility.FileSystemEncoding
+import Utility.QuickCheck
+
+prop_upFrom_basics :: TestableFilePath -> Bool
+prop_upFrom_basics tdir
+	| dir == "/" = p == Nothing
+	| otherwise = p /= Just dir
+  where
+	p = fromRawFilePath <$> upFrom (toRawFilePath dir)
+	dir = fromTestableFilePath tdir
+
+prop_relPathDirToFileAbs_basics :: TestableFilePath -> Bool
+prop_relPathDirToFileAbs_basics pt = and
+	[ relPathDirToFileAbs p (p </> "bar") == "bar"
+	, relPathDirToFileAbs (p </> "bar") p == ".."
+	, relPathDirToFileAbs p p == ""
+	]
+  where
+	-- relPathDirToFileAbs needs absolute paths, so make the path
+	-- absolute by adding a path separator to the front.
+	p = pathSeparator `B.cons` relf
+	-- Make the input a relative path. On windows, make sure it does
+	-- not contain anything that looks like a drive letter.
+	relf = B.dropWhile isPathSeparator $
+		B.filter (not . skipchar) $
+		toRawFilePath (fromTestableFilePath pt)
+	skipchar b = b == (fromIntegral (ord ':'))
+
+prop_relPathDirToFileAbs_regressionTest :: Bool
+prop_relPathDirToFileAbs_regressionTest = same_dir_shortcurcuits_at_difference
+  where
+	{- Two paths have the same directory component at the same
+	 - location, but it's not really the same directory.
+	 - Code used to get this wrong. -}
+	same_dir_shortcurcuits_at_difference =
+		relPathDirToFileAbs (joinPath [pathSeparator `B.cons` "tmp", "r", "lll", "xxx", "yyy", "18"])
+			(joinPath [pathSeparator `B.cons` "tmp", "r", ".git", "annex", "objects", "18", "gk", "SHA256-foo", "SHA256-foo"])
+				== joinPath ["..", "..", "..", "..", ".git", "annex", "objects", "18", "gk", "SHA256-foo", "SHA256-foo"]
+
+prop_dirContains_regressionTest :: Bool
+prop_dirContains_regressionTest = and
+	[ not $ dirContains "." ".."
+	, not $ dirContains ".." "../.."
+	, dirContains "." "foo"
+	, dirContains "." "."
+	, dirContains ".." ".."
+	, dirContains "../.." "../.."
+	, dirContains "." "./foo"
+	, dirContains ".." "../foo"
+	, dirContains "../.." "../foo"
+	, dirContains "../.." "../../foo"
+	, not $ dirContains "../.." "../../.."
+	]
diff --git a/Utility/Path/Windows.hs b/Utility/Path/Windows.hs
new file mode 100644
index 0000000000..e61a450d7f
--- /dev/null
+++ b/Utility/Path/Windows.hs
@@ -0,0 +1,47 @@
+{- Windows paths
+ -
+ - Copyright 2022-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Path.Windows (
+	convertToWindowsNativeNamespace
+) where
+
+import Utility.Path
+import Utility.FileSystemEncoding
+
+import System.FilePath.ByteString (combine)
+import qualified Data.ByteString as B
+import qualified System.FilePath.Windows.ByteString as P
+import System.Directory (getCurrentDirectory)
+
+{- Convert a filepath to use Windows's native namespace.
+ - This avoids filesystem length limits.
+ -
+ - This is similar to the way base converts filenames on windows,
+ - but as that is implemented in C (create_device_name) and not
+ - exported, it cannot be used here. Several edge cases are not handled,
+ - including network shares and dos short paths.
+ -}
+convertToWindowsNativeNamespace :: RawFilePath -> IO RawFilePath
+convertToWindowsNativeNamespace f
+	| win32_dev_namespace `B.isPrefixOf` f = return f
+	| win32_file_namespace `B.isPrefixOf` f = return f
+	| nt_device_namespace `B.isPrefixOf` f = return f
+	| otherwise = do
+		-- Make absolute because any '.' and '..' in the path
+		-- will not be resolved once it's converted.
+		cwd <- toRawFilePath <$> getCurrentDirectory
+		let p = simplifyPath (combine cwd f)
+		-- Normalize slashes.
+		let p' = P.normalise p
+		return (win32_file_namespace <> p')
+  where
+	win32_dev_namespace = "\\\\.\\"
+	win32_file_namespace = "\\\\?\\"
+	nt_device_namespace = "\\Device\\"
diff --git a/Utility/Percentage.hs b/Utility/Percentage.hs
new file mode 100644
index 0000000000..a30c26037f
--- /dev/null
+++ b/Utility/Percentage.hs
@@ -0,0 +1,33 @@
+{- percentages
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.Percentage (
+	Percentage,
+	percentage,
+	showPercentage
+) where
+
+import Data.Ratio
+
+import Utility.HumanNumber
+
+newtype Percentage = Percentage (Ratio Integer)
+
+instance Show Percentage where
+	show = showPercentage 0
+
+{- Normally the big number comes first. But 110% is allowed if desired. :) -}
+percentage :: Integer -> Integer -> Percentage
+percentage 0 _ = Percentage 0
+percentage full have = Percentage $ have * 100 % full
+
+{- Pretty-print a Percentage, with a specified level of precision. -}
+showPercentage :: Int -> Percentage -> String
+showPercentage precision (Percentage p) = v ++ "%"
+  where
+	v = showImprecise precision n
+	n = fromRational p :: Double
diff --git a/Utility/Process.hs b/Utility/Process.hs
new file mode 100644
index 0000000000..07f035d342
--- /dev/null
+++ b/Utility/Process.hs
@@ -0,0 +1,325 @@
+{- System.Process enhancements, including additional ways of running
+ - processes, and logging.
+ -
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP, Rank2Types, LambdaCase #-}
+{-# LANGUAGE OverloadedStrings #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Process (
+	module X,
+	StdHandle(..),
+	readProcess,
+	readProcess',
+	readProcessEnv,
+	writeReadProcessEnv,
+	forceSuccessProcess,
+	forceSuccessProcess',
+	checkSuccessProcess,
+	withNullHandle,
+	createProcess,
+	withCreateProcess,
+	waitForProcess,
+	cleanupProcess,
+	hGetLineUntilExitOrEOF,
+	startInteractiveProcess,
+	stdinHandle,
+	stdoutHandle,
+	stderrHandle,
+	processHandle,
+	showCmd,
+	devNull,
+) where
+
+import qualified Utility.Process.Shim
+import Utility.Process.Shim as X (CreateProcess(..), ProcessHandle, StdStream(..), CmdSpec(..), proc, getPid, getProcessExitCode, shell, terminateProcess, interruptProcessGroupOf)
+import Utility.Misc
+import Utility.Exception
+import Utility.Monad
+import Utility.Debug
+
+import System.Exit
+import System.IO
+import Control.Monad.IO.Class
+import Control.Concurrent.Async
+import qualified Data.ByteString as S
+
+data StdHandle = StdinHandle | StdoutHandle | StderrHandle
+	deriving (Eq)
+
+-- | Normally, when reading from a process, it does not need to be fed any
+-- standard input.
+readProcess :: FilePath	-> [String] -> IO String
+readProcess cmd args = readProcess' (proc cmd args)
+
+readProcessEnv :: FilePath -> [String] -> Maybe [(String, String)] -> IO String
+readProcessEnv cmd args environ = 
+	readProcess' $ (proc cmd args) { env = environ }
+
+readProcess' :: CreateProcess -> IO String
+readProcess' p = withCreateProcess p' go
+  where
+	p' = p { std_out = CreatePipe }
+	go _ (Just h) _ pid = do
+		output  <- hGetContentsStrict h
+		hClose h
+		forceSuccessProcess p' pid
+		return output
+	go _ _ _ _ = error "internal"
+
+-- | Runs an action to write to a process on its stdin, 
+-- returns its output, and also allows specifying the environment.
+writeReadProcessEnv
+	:: FilePath
+	-> [String]
+	-> Maybe [(String, String)]
+	-> (Maybe (Handle -> IO ()))
+	-> IO S.ByteString
+writeReadProcessEnv cmd args environ writestdin = withCreateProcess p go
+  where
+	p = (proc cmd args)
+		{ std_in = CreatePipe
+		, std_out = CreatePipe
+		, std_err = Inherit
+		, env = environ
+		}
+	
+	go (Just inh) (Just outh) _ pid = do
+		let reader = hClose outh `after` S.hGetContents outh
+		let writer = do
+			maybe (return ()) (\a -> a inh >> hFlush inh) writestdin
+			hClose inh
+		(output, ()) <- concurrently reader writer
+
+		forceSuccessProcess p pid
+
+		return output
+	go _ _ _ _ = error "internal"
+
+-- | Waits for a ProcessHandle, and throws an IOError if the process
+-- did not exit successfully.
+forceSuccessProcess :: CreateProcess -> ProcessHandle -> IO ()
+forceSuccessProcess p pid = waitForProcess pid >>= forceSuccessProcess' p
+
+forceSuccessProcess' :: CreateProcess -> ExitCode -> IO ()
+forceSuccessProcess' _ ExitSuccess = return ()
+forceSuccessProcess' p (ExitFailure n) = fail $
+	showCmd p ++ " exited " ++ show n
+
+-- | Waits for a ProcessHandle and returns True if it exited successfully.
+checkSuccessProcess :: ProcessHandle -> IO Bool
+checkSuccessProcess pid = do
+	code <- waitForProcess pid
+	return $ code == ExitSuccess
+
+withNullHandle :: (MonadIO m, MonadMask m) => (Handle -> m a) -> m a
+withNullHandle = bracket
+	(liftIO $ openFile devNull WriteMode)
+	(liftIO . hClose)
+
+devNull :: FilePath
+#ifndef mingw32_HOST_OS
+devNull = "/dev/null"
+#else
+-- Use device namespace to prevent GHC from rewriting path
+devNull = "\\\\.\\NUL"
+#endif
+
+-- | Extract a desired handle from createProcess's tuple.
+-- These partial functions are safe as long as createProcess is run
+-- with appropriate parameters to set up the desired handle.
+-- Get it wrong and the runtime crash will always happen, so should be
+-- easily noticed.
+type HandleExtractor = (Maybe Handle, Maybe Handle, Maybe Handle, ProcessHandle) -> Handle
+
+stdinHandle :: HandleExtractor
+stdinHandle (Just h, _, _, _) = h
+stdinHandle _ = error "expected stdinHandle"
+stdoutHandle :: HandleExtractor
+stdoutHandle (_, Just h, _, _) = h
+stdoutHandle _ = error "expected stdoutHandle"
+stderrHandle :: HandleExtractor
+stderrHandle (_, _, Just h, _) = h
+stderrHandle _ = error "expected stderrHandle"
+
+processHandle :: (Maybe Handle, Maybe Handle, Maybe Handle, ProcessHandle) -> ProcessHandle
+processHandle (_, _, _, pid) = pid
+
+-- | Shows the command that a CreateProcess will run.
+showCmd :: CreateProcess -> String
+showCmd = go . cmdspec
+  where
+	go (ShellCommand s) = s
+	go (RawCommand c ps) = c ++ " " ++ show ps
+
+-- | Starts an interactive process. Unlike runInteractiveProcess in
+-- System.Process, stderr is inherited.
+startInteractiveProcess
+	:: FilePath
+	-> [String]
+	-> Maybe [(String, String)]
+	-> IO (ProcessHandle, Handle, Handle)
+startInteractiveProcess cmd args environ = do
+	let p = (proc cmd args)
+		{ std_in = CreatePipe
+		, std_out = CreatePipe
+		, std_err = Inherit
+		, env = environ
+		}
+	(Just from, Just to, _, pid) <- createProcess p
+	return (pid, to, from)
+
+-- | Wrapper around 'System.Process.createProcess' that does debug logging.
+createProcess :: CreateProcess -> IO (Maybe Handle, Maybe Handle, Maybe Handle, ProcessHandle)
+createProcess p = do
+	r@(_, _, _, h) <- Utility.Process.Shim.createProcess p
+	debugProcess p h
+	return r
+
+-- | Wrapper around 'System.Process.withCreateProcess' that does debug logging.
+withCreateProcess :: CreateProcess -> (Maybe Handle -> Maybe Handle -> Maybe Handle -> ProcessHandle -> IO a) -> IO a
+withCreateProcess p action = bracket (createProcess p) cleanupProcess
+	(\(m_in, m_out, m_err, ph) -> action m_in m_out m_err ph)
+
+-- | Debugging trace for a CreateProcess.
+debugProcess :: CreateProcess -> ProcessHandle -> IO ()
+debugProcess p h = do
+	pid <- getPid h
+	debug "Utility.Process" $ unwords $
+		[ describePid pid
+		, action ++ ":"
+		, showCmd p
+		] ++ case cwd p of
+			Nothing -> []
+			Just c -> ["in", show c]
+  where
+	action
+		| piped (std_in p) && piped (std_out p) = "chat"
+		| piped (std_in p)                      = "feed"
+		| piped (std_out p)                     = "read"
+		| otherwise                             = "call"
+	piped Inherit = False
+	piped _ = True
+
+describePid :: Maybe Utility.Process.Shim.Pid -> String
+describePid Nothing = "process"
+describePid (Just p) = "process [" ++  show p ++ "]"
+
+-- | Wrapper around 'System.Process.waitForProcess' that does debug logging.
+waitForProcess ::  ProcessHandle -> IO ExitCode
+waitForProcess h = do
+	-- Have to get pid before waiting, which closes the ProcessHandle.
+	pid <- getPid h
+	r <- Utility.Process.Shim.waitForProcess h
+	debug "Utility.Process" (describePid pid ++ " done " ++ show r)
+	return r
+
+cleanupProcess :: (Maybe Handle, Maybe Handle, Maybe Handle, ProcessHandle) -> IO () 
+#if MIN_VERSION_process(1,6,4)
+cleanupProcess = Utility.Process.Shim.cleanupProcess
+#else
+cleanupProcess (mb_stdin, mb_stdout, mb_stderr, pid) = do
+	-- Unlike the real cleanupProcess, this does not wait
+	-- for the process to finish in the background, so if
+	-- the process ignores SIGTERM, this can block until the process
+	-- gets around the exiting.
+	terminateProcess pid
+	let void _ = return ()
+	maybe (return ()) (void . tryNonAsync . hClose) mb_stdin
+	maybe (return ()) hClose mb_stdout
+	maybe (return ()) hClose mb_stderr
+	void $ waitForProcess pid
+#endif
+
+{- | Like hGetLine, reads a line from the Handle. Returns Nothing if end of
+ - file is reached, or the handle is closed, or if the process has exited
+ - and there is nothing more buffered to read from the handle.
+ -
+ - This is useful to protect against situations where the process might
+ - have transferred the handle being read to another process, and so
+ - the handle could remain open after the process has exited. That is a rare
+ - situation, but can happen. Consider a the process that started up a
+ - daemon, and the daemon inherited stderr from it, rather than the more
+ - usual behavior of closing the file descriptor. Reading from stderr
+ - would block past the exit of the process.
+ -
+ - In that situation, this will detect when the process has exited,
+ - and avoid blocking forever. But will still return anything the process
+ - buffered to the handle before exiting.
+ -
+ - Note on newline mode: This ignores whatever newline mode is configured
+ - for the handle, because there is no way to query that. On Windows,
+ - it will remove any \r coming before the \n. On other platforms,
+ - it does not treat \r specially.
+ -}
+hGetLineUntilExitOrEOF :: ProcessHandle -> Handle -> IO (Maybe String)
+hGetLineUntilExitOrEOF ph h = go []
+  where
+	go buf = do
+		ready <- waitforinputorerror smalldelay
+		if ready
+			then getloop buf go
+			else getProcessExitCode ph >>= \case
+				-- Process still running, wait longer.
+				Nothing -> go buf
+				-- Process is done. It's possible
+				-- that it output something and exited
+				-- since the prior hWaitForInput,
+				-- so check one more time for any buffered
+				-- output.
+				Just _ -> finalcheck buf
+
+	finalcheck buf = do
+		ready <- waitforinputorerror 0
+		if ready
+			then getloop buf finalcheck
+			-- No remaining buffered input, though the handle
+			-- may not be EOF if something else is keeping it
+			-- open. Treated the same as EOF.
+			else eofwithnolineend buf
+
+	-- On exception, proceed as if there was input;
+	-- EOF and any encoding issues are dealt with
+	-- when reading from the handle.
+	waitforinputorerror t = hWaitForInput h t
+		`catchNonAsync` const (pure True)
+
+	getchar = 
+		catcherr EOF $
+			-- If the handle is closed, reading from it is
+			-- an IllegalOperation.
+			catcherr IllegalOperation $
+				Just <$> hGetChar h
+	  where
+		catcherr t = catchIOErrorType t (const (pure Nothing))
+
+	getloop buf cont =
+		getchar >>= \case
+			Just c
+				| c == '\n' -> return (Just (gotline buf))
+				| otherwise -> cont (c:buf)
+			Nothing -> eofwithnolineend buf
+
+#ifndef mingw32_HOST_OS
+	gotline buf = reverse buf
+#else
+	gotline ('\r':buf) = reverse buf
+	gotline buf = reverse buf
+#endif
+
+	eofwithnolineend buf = return $
+		if null buf 
+			then Nothing -- no line read
+			else Just (reverse buf)
+
+	-- Tenth of a second delay. If the process exits with the FD being
+	-- held open, will wait up to twice this long before returning.
+	-- This delay could be made smaller. However, that is an unusual
+	-- case, and making it too small would cause lots of wakeups while
+	-- waiting for output. Bearing in mind that this could be run on
+	-- many processes at the same time.
+	smalldelay = 100 -- milliseconds
diff --git a/Utility/Process/Shim.hs b/Utility/Process/Shim.hs
new file mode 100644
index 0000000000..09312c7f79
--- /dev/null
+++ b/Utility/Process/Shim.hs
@@ -0,0 +1,3 @@
+module Utility.Process.Shim (module X) where
+
+import System.Process as X
diff --git a/Utility/Process/Transcript.hs b/Utility/Process/Transcript.hs
new file mode 100644
index 0000000000..7bf94ffa05
--- /dev/null
+++ b/Utility/Process/Transcript.hs
@@ -0,0 +1,97 @@
+{- Process transcript
+ -
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Process.Transcript (
+	processTranscript,
+	processTranscript',
+	processTranscript'',
+) where
+
+import Utility.Process
+
+import System.IO
+import System.Exit
+import Control.Concurrent.Async
+import Control.Monad
+#ifndef mingw32_HOST_OS
+import Control.Exception
+import qualified System.Posix.IO
+#else
+import Control.Applicative
+#endif
+import Data.Maybe
+import Prelude
+
+-- | Runs a process and returns a transcript combining its stdout and
+-- stderr, and whether it succeeded or failed.
+processTranscript :: String -> [String] -> (Maybe String) -> IO (String, Bool)
+processTranscript cmd opts = processTranscript' (proc cmd opts)
+
+-- | Also feeds the process some input.
+processTranscript' :: CreateProcess -> Maybe String -> IO (String, Bool)
+processTranscript' cp input = do
+	(t, c) <- processTranscript'' cp input
+	return (t, c == ExitSuccess)
+
+processTranscript'' :: CreateProcess -> Maybe String -> IO (String, ExitCode)
+processTranscript'' cp input = do
+#ifndef mingw32_HOST_OS
+{- This implementation interleves stdout and stderr in exactly the order
+ - the process writes them. -}
+ 	let setup = do
+		(readf, writef) <- System.Posix.IO.createPipe
+		System.Posix.IO.setFdOption readf System.Posix.IO.CloseOnExec True
+		System.Posix.IO.setFdOption writef System.Posix.IO.CloseOnExec True
+		readh <- System.Posix.IO.fdToHandle readf
+		writeh <- System.Posix.IO.fdToHandle writef
+		return (readh, writeh)
+	let cleanup (readh, writeh) = do
+		hClose readh
+		hClose writeh
+	bracket setup cleanup $ \(readh, writeh) -> do
+		let cp' = cp
+			{ std_in = if isJust input then CreatePipe else Inherit
+			, std_out = UseHandle writeh
+			, std_err = UseHandle writeh
+			}
+		withCreateProcess cp' $ \hin hout herr pid -> do
+			get <- asyncreader pid readh
+			writeinput input (hin, hout, herr, pid)
+			code <- waitForProcess pid
+			transcript <- wait get
+			return (transcript, code)
+#else
+{- This implementation for Windows puts stderr after stdout. -}
+	let cp' = cp 
+		{ std_in = if isJust input then CreatePipe else Inherit
+		, std_out = CreatePipe
+		, std_err = CreatePipe
+		}
+	withCreateProcess cp' $ \hin hout herr pid -> do
+		let p = (hin, hout, herr, pid)
+		getout <- asyncreader pid (stdoutHandle p)
+		geterr <- asyncreader pid (stderrHandle p)
+		writeinput input p
+		code <- waitForProcess pid
+		transcript <- (++) <$> wait getout <*> wait geterr
+		return (transcript, code)
+#endif
+  where
+	asyncreader pid h = async $ reader pid h []
+	reader pid h c = hGetLineUntilExitOrEOF pid h >>= \case
+		Nothing -> return (unlines (reverse c))
+		Just l -> reader pid h (l:c)
+	writeinput (Just s) p = do
+		let inh = stdinHandle p
+		unless (null s) $ do
+			hPutStr inh s
+			hFlush inh
+		hClose inh
+	writeinput Nothing _ = return ()
diff --git a/Utility/QuickCheck.hs b/Utility/QuickCheck.hs
new file mode 100644
index 0000000000..96e31d5c08
--- /dev/null
+++ b/Utility/QuickCheck.hs
@@ -0,0 +1,89 @@
+{- QuickCheck with additional instances
+ -
+ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+{-# LANGUAGE TypeSynonymInstances #-}
+
+module Utility.QuickCheck
+	( module X
+	, TestableString
+	, fromTestableString
+	, TestableFilePath(..)
+	, nonNegative
+	, positive
+	) where
+
+import Test.QuickCheck as X
+import Data.Time.Clock.POSIX
+import Data.Ratio
+import Data.Char
+import System.Posix.Types
+import Data.List.NonEmpty (NonEmpty(..))
+import Prelude
+
+{- A String, but Arbitrary is limited to ascii.
+ -
+ - When in a non-utf8 locale, String does not normally contain any non-ascii
+ - characters, except for ones in surrogate plane. Converting a string that
+ - does contain other unicode characters to a ByteString using the
+ - filesystem encoding (see GHC.IO.Encoding) will throw an exception,
+ - so use this instead to avoid quickcheck tests breaking unncessarily.
+ -} 
+newtype TestableString = TestableString
+	{ fromTestableString :: String }
+	deriving (Show)
+
+instance Arbitrary TestableString where
+	arbitrary = TestableString . filter isAscii <$> arbitrary
+
+{- FilePath constrained to not be the empty string, not contain a NUL, 
+ - and contain only ascii.
+ -
+ - No real-world filename can be empty or contain a NUL. So code can
+ - well be written that assumes that and using this avoids quickcheck
+ - tests breaking unncessarily.
+ -} 
+newtype TestableFilePath = TestableFilePath
+	{ fromTestableFilePath :: FilePath }
+	deriving (Show)
+
+instance Arbitrary TestableFilePath where
+	arbitrary = (TestableFilePath . fromTestableString <$> arbitrary)
+		`suchThat` (not . null . fromTestableFilePath)
+		`suchThat` (not . any (== '\NUL') . fromTestableFilePath)
+
+{- Times before the epoch are excluded. Half with decimal and half without. -}
+instance Arbitrary POSIXTime where
+	arbitrary = do
+		n <- nonNegative arbitrarySizedBoundedIntegral :: Gen Int
+		d <- nonNegative arbitrarySizedIntegral
+		withd <- arbitrary
+		return $ if withd
+			then fromIntegral n + fromRational (1 % max d 1)
+			else fromIntegral n
+
+{- Pids are never negative, or 0. -}
+instance Arbitrary ProcessID where
+	arbitrary = positive arbitrarySizedBoundedIntegral
+
+{- Inodes are never negative. -}
+instance Arbitrary FileID where
+	arbitrary = nonNegative arbitrarySizedIntegral
+
+{- File sizes are never negative. -}
+instance Arbitrary FileOffset where
+	arbitrary = nonNegative arbitrarySizedIntegral
+
+instance Arbitrary l => Arbitrary (NonEmpty l) where
+	arbitrary = (:|) <$> arbitrary <*> arbitrary
+
+nonNegative :: (Num a, Ord a) => Gen a -> Gen a
+nonNegative g = g `suchThat` (>= 0)
+
+positive :: (Num a, Ord a) => Gen a -> Gen a
+positive g = g `suchThat` (> 0)
diff --git a/Utility/RawFilePath.hs b/Utility/RawFilePath.hs
new file mode 100644
index 0000000000..b39423df5b
--- /dev/null
+++ b/Utility/RawFilePath.hs
@@ -0,0 +1,125 @@
+{- Portability shim for basic operations on RawFilePaths.
+ -
+ - On unix, this makes syscalls using RawFilesPaths as efficiently as
+ - possible.
+ -
+ - On Windows, filenames are in unicode, so RawFilePaths have to be
+ - decoded. So this library will work, but less efficiently than using
+ - FilePath would. However, this library also takes care to support long
+ - filenames on Windows, by either using other libraries that do, or by
+ - doing UNC-style conversion itself.
+ -
+ - Copyright 2019-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.RawFilePath (
+	RawFilePath,
+	readSymbolicLink,
+	createSymbolicLink,
+	createLink,
+	removeLink,
+	getFileStatus,
+	getSymbolicLinkStatus,
+	doesPathExist,
+	getCurrentDirectory,
+	createDirectory,
+	setFileMode,
+	setOwnerAndGroup,
+	rename,
+	createNamedPipe,
+	fileAccess,
+) where
+
+#ifndef mingw32_HOST_OS
+import Utility.FileSystemEncoding (RawFilePath)
+import System.Posix.Files.ByteString
+import qualified System.Posix.Directory.ByteString as D
+
+-- | Checks if a file or directory exists. Note that a dangling symlink
+-- will be false.
+doesPathExist :: RawFilePath -> IO Bool
+doesPathExist = fileExist
+
+getCurrentDirectory :: IO RawFilePath
+getCurrentDirectory = D.getWorkingDirectory
+
+createDirectory :: RawFilePath -> IO ()
+createDirectory p = D.createDirectory p 0o777
+
+#else
+import System.PosixCompat (FileStatus, FileMode)
+-- System.PosixCompat does not handle UNC-style conversion itself,
+-- so all uses of it library have to be pre-converted below. See
+-- https://github.com/jacobstanley/unix-compat/issues/56
+import qualified System.PosixCompat as P
+import qualified System.Directory as D
+import Utility.FileSystemEncoding
+import Utility.Path.Windows
+
+readSymbolicLink :: RawFilePath -> IO RawFilePath
+readSymbolicLink f = toRawFilePath <$> P.readSymbolicLink (fromRawFilePath f)
+
+createSymbolicLink :: RawFilePath -> RawFilePath -> IO ()
+createSymbolicLink a b = do
+	a' <- fromRawFilePath <$> convertToWindowsNativeNamespace a
+	b' <- fromRawFilePath <$> convertToWindowsNativeNamespace b
+	P.createSymbolicLink a' b'
+
+createLink :: RawFilePath -> RawFilePath -> IO ()
+createLink a b = do
+	a' <- fromRawFilePath <$> convertToWindowsNativeNamespace a
+	b' <- fromRawFilePath <$> convertToWindowsNativeNamespace b
+	P.createLink a' b'
+
+{- On windows, removeLink is not available, so only remove files,
+ - not symbolic links. -}
+removeLink :: RawFilePath -> IO ()
+removeLink = D.removeFile . fromRawFilePath
+
+getFileStatus :: RawFilePath -> IO FileStatus
+getFileStatus p = P.getFileStatus . fromRawFilePath
+	=<< convertToWindowsNativeNamespace p
+
+getSymbolicLinkStatus :: RawFilePath -> IO FileStatus
+getSymbolicLinkStatus p = P.getSymbolicLinkStatus . fromRawFilePath
+	=<< convertToWindowsNativeNamespace p
+
+doesPathExist :: RawFilePath -> IO Bool
+doesPathExist = D.doesPathExist . fromRawFilePath
+
+getCurrentDirectory :: IO RawFilePath
+getCurrentDirectory = toRawFilePath <$> D.getCurrentDirectory
+
+createDirectory :: RawFilePath -> IO ()
+createDirectory = D.createDirectory . fromRawFilePath
+
+setFileMode :: RawFilePath -> FileMode -> IO () 
+setFileMode p m = do
+	p' <- fromRawFilePath <$> convertToWindowsNativeNamespace p
+	P.setFileMode p' m
+
+{- Using renamePath rather than the rename provided in unix-compat
+ - because of this bug https://github.com/jacobstanley/unix-compat/issues/56-}
+rename :: RawFilePath -> RawFilePath -> IO ()
+rename a b = D.renamePath (fromRawFilePath a) (fromRawFilePath b)
+
+setOwnerAndGroup :: RawFilePath -> P.UserID -> P.GroupID -> IO ()
+setOwnerAndGroup p u g = do
+	p' <- fromRawFilePath <$> convertToWindowsNativeNamespace p
+	P.setOwnerAndGroup p' u g
+
+createNamedPipe :: RawFilePath -> FileMode -> IO ()
+createNamedPipe p m = do
+	p' <- fromRawFilePath <$> convertToWindowsNativeNamespace p
+	P.createNamedPipe p' m
+
+fileAccess :: RawFilePath -> Bool -> Bool -> Bool -> IO Bool
+fileAccess p a b c = do
+	p' <- fromRawFilePath <$> convertToWindowsNativeNamespace p
+	P.fileAccess p' a b c
+#endif
diff --git a/Utility/ResourcePool.hs b/Utility/ResourcePool.hs
new file mode 100644
index 0000000000..48feb4bf16
--- /dev/null
+++ b/Utility/ResourcePool.hs
@@ -0,0 +1,94 @@
+{- Resource pools.
+ -
+ - Copyright 2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+
+module Utility.ResourcePool (
+	ResourcePool(..),
+	mkResourcePool,
+	mkResourcePoolNonConcurrent,
+	withResourcePool,
+	freeResourcePool,
+) where
+
+import Common
+
+import Control.Concurrent.STM
+import Control.Monad.IO.Class
+import Data.Either
+
+data ResourcePool r
+	= ResourcePool Int (TVar Int) (TVar [r])
+	| ResourcePoolNonConcurrent r
+
+{- Make a new resource pool, that can grow to contain the specified number
+ - of resources. -}
+mkResourcePool :: MonadIO m => Int -> m (ResourcePool r)
+mkResourcePool maxsz = liftIO $
+	ResourcePool maxsz
+		<$> newTVarIO 0
+		<*> newTVarIO []
+
+{- When there will not be multiple threads that may 
+ - concurrently try to use it, using this is more
+ - efficient than mkResourcePool.
+ -}
+mkResourcePoolNonConcurrent :: (MonadMask m, MonadIO m) => m r -> m (ResourcePool r)
+mkResourcePoolNonConcurrent allocresource =
+	ResourcePoolNonConcurrent <$> allocresource
+
+{- Runs an action with a resource.
+ -
+ - If no free resource is available in the pool,
+ - will run the action the allocate a new resource if the pool's size
+ - allows. Or will block a resource becomes available to use.
+ -
+ - The resource is returned to the pool at the end.
+ -}
+withResourcePool :: (MonadMask m, MonadIO m) => ResourcePool r -> m r -> (r -> m a) -> m a
+withResourcePool (ResourcePoolNonConcurrent r) _ a = a r
+withResourcePool (ResourcePool maxsz currsz p) allocresource a =
+	bracket setup cleanup a
+  where
+	setup = do
+		mr <- liftIO $ atomically $ do
+			l <- readTVar p
+			case l of
+				(r:rs) -> do
+					writeTVar p rs
+					return (Just r)
+				[] -> do
+					n <- readTVar currsz
+					if n < maxsz
+						then do
+							let !n' = succ n
+							writeTVar currsz n'
+							return Nothing
+						else retry
+		case mr of
+			Just r -> return r
+			Nothing -> allocresource
+	cleanup r = liftIO $ atomically $ modifyTVar' p (r:)
+
+{- Frees all resources in use in the pool, running the supplied action on
+ - each. (If any of the actions throw an exception, it will be rethrown
+ - after all the actions have completed.)
+ -
+ - The pool should not have any resources in use when this is called,
+ - and the pool should not be used again after calling this.
+ -}
+freeResourcePool :: (MonadMask m, MonadIO m) => ResourcePool r -> (r -> m ()) -> m ()
+freeResourcePool (ResourcePoolNonConcurrent r) freeresource = freeresource r
+freeResourcePool (ResourcePool _ currsz p) freeresource = do
+	rs <- liftIO $ atomically $ do
+		writeTVar currsz 0
+		swapTVar p []
+	res <- forM rs $ tryNonAsync . freeresource
+	case lefts res of
+		[] -> return ()
+		(e:_) -> throwM e
+
diff --git a/Utility/Rsync.hs b/Utility/Rsync.hs
new file mode 100644
index 0000000000..e377eb965d
--- /dev/null
+++ b/Utility/Rsync.hs
@@ -0,0 +1,188 @@
+{- various rsync stuff
+ -
+ - Copyright 2010-2013 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.Rsync (
+	rsyncShell,
+	rsyncServerSend,
+	rsyncServerReceive,
+	rsyncUseDestinationPermissions,
+	rsync,
+	rsyncUrlIsShell,
+	rsyncUrlIsPath,
+	rsyncProgress,
+	filterRsyncSafeOptions,
+) where
+
+import Common
+import Utility.Metered
+import Utility.Tuple
+
+#ifdef mingw32_HOST_OS
+import qualified System.FilePath.Posix as Posix
+#endif
+
+import Data.Char
+import System.Console.GetOpt
+
+{- Generates parameters to make rsync use a specified command as its remote
+ - shell. -}
+rsyncShell :: [CommandParam] -> [CommandParam]
+rsyncShell command = [Param "-e", Param $ unwords $ map escape (toCommand command)]
+  where
+	{- rsync requires some weird, non-shell like quoting in
+	- here. A doubled single quote inside the single quoted
+	- string is a single quote. -}
+	escape s = "'" ++  intercalate "''" (splitc '\'' s) ++ "'"
+
+{- Runs rsync in server mode to send a file. -}
+rsyncServerSend :: [CommandParam] -> FilePath -> IO Bool
+rsyncServerSend options file = rsync $
+	rsyncServerParams ++ Param "--sender" : options ++ [File file]
+
+{- Runs rsync in server mode to receive a file. -}
+rsyncServerReceive :: [CommandParam] -> FilePath -> IO Bool
+rsyncServerReceive options file = rsync $
+	rsyncServerParams ++ options ++ [File file]
+
+rsyncServerParams :: [CommandParam]
+rsyncServerParams =
+	[ Param "--server"
+	-- preserve timestamps
+	, Param "-t"
+	-- allow resuming of transfers of big files
+	, Param "--inplace"
+	-- other options rsync normally uses in server mode
+	, Param "-e.Lsf"
+	, Param "."
+	]
+
+rsyncUseDestinationPermissions :: CommandParam
+rsyncUseDestinationPermissions = Param "--chmod=ugo=rwX"
+
+rsync :: [CommandParam] -> IO Bool
+rsync = boolSystem "rsync" . rsyncParamsFixup
+
+{- On Windows, rsync is from msys2, and expects to get msys2 formatted
+ - paths to files. (It thinks that C:foo refers to a host named "C").
+ - Fix up the Params appropriately. -}
+rsyncParamsFixup :: [CommandParam] -> [CommandParam]
+#ifdef mingw32_HOST_OS
+rsyncParamsFixup = map fixup
+  where
+	fixup (File f) = File (toMSYS2Path f)
+	fixup (Param s)
+		| rsyncUrlIsPath s = Param (toMSYS2Path s)
+	fixup p = p
+#else
+rsyncParamsFixup = id
+#endif
+
+{- Checks if an rsync url involves the remote shell (ssh or rsh).
+ - Use of such urls with rsync requires additional shell
+ - escaping. -}
+rsyncUrlIsShell :: String -> Bool
+rsyncUrlIsShell s
+	| "rsync://" `isPrefixOf` s = False
+	| otherwise = go s
+  where
+	-- host::dir is rsync protocol, while host:dir is ssh/rsh
+	go [] = False
+	go (c:cs)
+		| c == '/' = False -- got to directory with no colon
+		| c == ':' = not $ ":" `isPrefixOf` cs
+		| otherwise = go cs
+
+{- Checks if a rsync url is really just a local path. -}
+rsyncUrlIsPath :: String -> Bool
+rsyncUrlIsPath s
+#ifdef mingw32_HOST_OS
+	| not (null (takeDrive s)) = True
+#endif
+	| rsyncUrlIsShell s = False
+	| otherwise = ':' `notElem` s
+
+{- Runs rsync, but intercepts its progress output and updates a progress
+ - meter.
+ -
+ - The params must enable rsync's --progress mode for this to work.
+ -}
+rsyncProgress :: OutputHandler -> MeterUpdate -> [CommandParam] -> IO Bool
+rsyncProgress oh meter ps =
+	commandMeterExitCode parseRsyncProgress oh Nothing meter "rsync" (rsyncParamsFixup ps) >>= \case
+		Just ExitSuccess -> return True
+		Just (ExitFailure exitcode) -> do
+			when (exitcode /= 1) $
+				hPutStrLn stderr $ "rsync exited " ++ show exitcode
+			return False
+		Nothing -> do
+			hPutStrLn stderr $ "unable to run rsync"
+			return False
+
+{- Strategy: Look for chunks prefixed with \r (rsync writes a \r before
+ - the first progress output, and each thereafter). The first number
+ - after the \r is the number of bytes processed. After the number,
+ - there must appear some whitespace, or we didn't get the whole number,
+ - and return the \r and part we did get, for later processing.
+ -
+ - In some locales, the number will have one or more commas in the middle
+ - of it.
+ -}
+parseRsyncProgress :: ProgressParser
+parseRsyncProgress = go [] . reverse . progresschunks
+  where
+	go remainder [] = (Nothing, Nothing, remainder)
+	go remainder (x:xs) = case parsebytes (findbytesstart x) of
+		Nothing -> go (delim:x++remainder) xs
+		Just b -> (Just (toBytesProcessed b), Nothing, remainder)
+
+	delim = '\r'
+
+	{- Find chunks that each start with delim.
+	 - The first chunk doesn't start with it
+	 - (it's empty when delim is at the start of the string). -}
+	progresschunks = drop 1 . splitc delim
+	findbytesstart s = dropWhile isSpace s
+
+	parsebytes :: String -> Maybe Integer
+	parsebytes s = case break isSpace s of
+		([], _) -> Nothing
+		(_, []) -> Nothing
+		(b, _) -> readish $ filter (/= ',') b
+
+{- Filters options to those that are safe to pass to rsync in server mode,
+ - without causing it to eg, expose files. -}
+filterRsyncSafeOptions :: [String] -> [String]
+filterRsyncSafeOptions = fst3 . getOpt Permute
+	[ Option [] ["bwlimit"] (reqArgLong "bwlimit") "" ]
+  where
+	reqArgLong x = ReqArg (\v -> "--" ++ x ++ "=" ++ v) ""
+
+{- Converts a DOS style path to a msys2 style path. Only on Windows.
+ - Any trailing '\' is preserved as a trailing '/' 
+ - 
+ - Taken from: http://sourceforge.net/p/msys2/wiki/MSYS2%20introduction/i
+ -
+ - The virtual filesystem contains:
+ -  /c, /d, ...	mount points for Windows drives
+ -}
+#ifdef mingw32_HOST_OS
+toMSYS2Path :: FilePath -> FilePath
+toMSYS2Path p
+	| null drive = recombine parts
+	| otherwise = recombine $ "/" : driveletter drive : parts
+  where
+	(drive, p') = splitDrive p
+	parts = splitDirectories p'
+	driveletter = map toLower . takeWhile (/= ':')
+	recombine = fixtrailing . Posix.joinPath
+	fixtrailing s
+		| hasTrailingPathSeparator p = Posix.addTrailingPathSeparator s
+		| otherwise = s
+#endif
+
diff --git a/Utility/SafeCommand.hs b/Utility/SafeCommand.hs
new file mode 100644
index 0000000000..6f9419cd8c
--- /dev/null
+++ b/Utility/SafeCommand.hs
@@ -0,0 +1,113 @@
+{- safely running shell commands
+ -
+ - Copyright 2010-2015 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.SafeCommand (
+	CommandParam(..),
+	toCommand,
+	boolSystem,
+	boolSystem',
+	boolSystemEnv,
+	safeSystem,
+	safeSystem',
+	safeSystemEnv,
+	segmentXargsOrdered,
+	segmentXargsUnordered,
+) where
+
+import Utility.Process
+
+import System.Exit
+import System.FilePath
+import Data.Char
+import Data.List
+import Control.Applicative
+import Prelude
+
+-- | Parameters that can be passed to a shell command.
+data CommandParam
+	= Param String -- ^ A parameter
+	| File FilePath -- ^ The name of a file
+	deriving (Eq, Show, Ord)
+
+-- | Used to pass a list of CommandParams to a function that runs
+-- a command and expects Strings. -}
+toCommand :: [CommandParam] -> [String]
+toCommand = map toCommand'
+
+toCommand' :: CommandParam -> String
+toCommand' (Param s) = s
+-- Files that start with a non-alphanumeric that is not a path
+-- separator are modified to avoid the command interpreting them as
+-- options or other special constructs.
+toCommand' (File s@(h:_))
+	| isAlphaNum h || h `elem` pathseps = s
+	| otherwise = "./" ++ s
+  where
+	-- '/' is explicitly included because it's an alternative
+	-- path separator on Windows.
+	pathseps = pathSeparator:"./"
+toCommand' (File s) = s
+
+-- | Run a system command, and returns True or False if it succeeded or failed.
+--
+-- (Throws an exception if the command is not found.)
+--
+-- This and other command running functions in this module log the commands
+-- run at debug level, using System.Log.Logger.
+boolSystem :: FilePath -> [CommandParam] -> IO Bool
+boolSystem command params = boolSystem' command params id
+
+boolSystem' :: FilePath -> [CommandParam] -> (CreateProcess -> CreateProcess) -> IO Bool
+boolSystem' command params mkprocess = dispatch <$> safeSystem' command params mkprocess
+  where
+	dispatch ExitSuccess = True
+	dispatch _ = False
+
+boolSystemEnv :: FilePath -> [CommandParam] -> Maybe [(String, String)] -> IO Bool
+boolSystemEnv command params environ = boolSystem' command params $
+	\p -> p { env = environ }
+
+-- | Runs a system command, returning the exit status.
+safeSystem :: FilePath -> [CommandParam] -> IO ExitCode
+safeSystem command params = safeSystem' command params id
+
+safeSystem' :: FilePath -> [CommandParam] -> (CreateProcess -> CreateProcess) -> IO ExitCode
+safeSystem' command params mkprocess = 
+	withCreateProcess p $ \_ _ _ pid ->
+		waitForProcess pid
+  where
+	p = mkprocess $ proc command (toCommand params)
+
+safeSystemEnv :: FilePath -> [CommandParam] -> Maybe [(String, String)] -> IO ExitCode
+safeSystemEnv command params environ = safeSystem' command params $ 
+	\p -> p { env = environ }
+
+-- | Segments a list of filenames into groups that are all below the maximum
+--  command-line length limit.
+segmentXargsOrdered :: [FilePath] -> [[FilePath]]
+segmentXargsOrdered = reverse . map reverse . segmentXargsUnordered
+
+-- | Not preserving order is a little faster, and streams better when
+-- there are a great many filenames.
+segmentXargsUnordered :: [FilePath] -> [[FilePath]]
+segmentXargsUnordered l = go l [] 0 []
+  where
+	go [] c _ r = (c:r)
+	go (f:fs) c accumlen r
+		| newlen > maxlen && len < maxlen = go (f:fs) [] 0 (c:r)
+		| otherwise = go fs (f:c) newlen r
+	  where
+		len = length f
+		newlen = accumlen + len
+
+	{- 10k of filenames per command, well under 100k limit
+	 - of Linux (and OSX has a similar limit);
+	 - allows room for other parameters etc. Also allows for
+	 - eg, multibyte characters. -}
+	maxlen = 10240
diff --git a/Utility/SafeOutput.hs b/Utility/SafeOutput.hs
new file mode 100644
index 0000000000..d7813860ef
--- /dev/null
+++ b/Utility/SafeOutput.hs
@@ -0,0 +1,36 @@
+{- Safe output to the terminal of possibly attacker-controlled strings,
+ - avoiding displaying control characters.
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE TypeSynonymInstances, FlexibleInstances, CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.SafeOutput (
+	safeOutput,
+	safeOutputChar,
+) where
+
+import Data.Char
+import qualified Data.ByteString as S
+
+class SafeOutputtable t where
+	safeOutput :: t -> t
+
+instance SafeOutputtable String where
+	safeOutput = filter safeOutputChar
+
+instance SafeOutputtable S.ByteString where
+	safeOutput = S.filter (safeOutputChar . chr . fromIntegral)
+
+safeOutputChar :: Char -> Bool
+safeOutputChar c
+	| not (isControl c) = True
+	| c == '\n' = True
+	| c == '\t' = True
+	| c == '\DEL' = False
+	| ord c > 31 = True
+	| otherwise = False
diff --git a/Utility/Scheduled.hs b/Utility/Scheduled.hs
new file mode 100644
index 0000000000..7dacdc7ec6
--- /dev/null
+++ b/Utility/Scheduled.hs
@@ -0,0 +1,362 @@
+{- scheduled activities
+ - 
+ - Copyright 2013-2014 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.Scheduled (
+	Schedule(..),
+	Recurrence(..),
+	ScheduledTime(..),
+	NextTime(..),
+	WeekDay,
+	MonthDay,
+	YearDay,
+	nextTime,
+	calcNextTime,
+	startTime,
+	fromSchedule,
+	fromScheduledTime,
+	toScheduledTime,
+	fromRecurrence,
+	toRecurrence,
+	toSchedule,
+	parseSchedule,
+	prop_past_sane,
+) where
+
+import Utility.Data
+import Utility.PartialPrelude
+import Utility.Misc
+import Utility.Tuple
+import Utility.Split
+
+import Data.List
+import Data.Time.Clock
+import Data.Time.LocalTime
+import Data.Time.Calendar
+import Data.Time.Calendar.WeekDate
+import Data.Time.Calendar.OrdinalDate
+import Data.Time.Format ()
+import Data.Char
+import Control.Applicative
+import Prelude
+
+{- Some sort of scheduled event. -}
+data Schedule = Schedule Recurrence ScheduledTime
+	deriving (Eq, Read, Show, Ord)
+
+data Recurrence
+	= Daily
+	| Weekly (Maybe WeekDay)
+	| Monthly (Maybe MonthDay)
+	| Yearly (Maybe YearDay)
+	| Divisible Int Recurrence
+	-- ^ Days, Weeks, or Months of the year evenly divisible by a number.
+	-- (Divisible Year is years evenly divisible by a number.)
+	deriving (Eq, Read, Show, Ord)
+
+type WeekDay = Int
+type MonthDay = Int
+type YearDay = Int
+
+data ScheduledTime
+	= AnyTime
+	| SpecificTime Hour Minute
+	deriving (Eq, Read, Show, Ord)
+
+type Hour = Int
+type Minute = Int
+
+-- | Next time a Schedule should take effect. The NextTimeWindow is used
+-- when a Schedule is allowed to start at some point within the window.
+data NextTime
+	= NextTimeExactly LocalTime
+	| NextTimeWindow LocalTime LocalTime
+	deriving (Eq, Read, Show)
+
+startTime :: NextTime -> LocalTime
+startTime (NextTimeExactly t) = t
+startTime (NextTimeWindow t _) = t
+
+nextTime :: Schedule -> Maybe LocalTime -> IO (Maybe NextTime)
+nextTime schedule lasttime = do
+	now <- getCurrentTime
+	tz <- getTimeZone now
+	return $ calcNextTime schedule lasttime $ utcToLocalTime tz now
+
+-- | Calculate the next time that fits a Schedule, based on the
+-- last time it occurred, and the current time.
+calcNextTime :: Schedule -> Maybe LocalTime -> LocalTime -> Maybe NextTime
+calcNextTime schedule@(Schedule recurrence scheduledtime) lasttime currenttime
+	| scheduledtime == AnyTime = do
+		next <- findfromtoday True
+		return $ case next of
+			NextTimeWindow _ _ -> next
+			NextTimeExactly t -> window (localDay t) (localDay t)
+	| otherwise = NextTimeExactly . startTime <$> findfromtoday False
+  where
+	findfromtoday anytime = findfrom recurrence afterday today
+	  where
+		today = localDay currenttime
+		afterday = sameaslastrun || toolatetoday
+		toolatetoday = not anytime && localTimeOfDay currenttime >= nexttime
+		sameaslastrun = lastrun == Just today
+	lastrun = localDay <$> lasttime
+	nexttime = case scheduledtime of
+		AnyTime -> TimeOfDay 0 0 0
+		SpecificTime h m -> TimeOfDay h m 0
+	exactly d = NextTimeExactly $ LocalTime d nexttime
+	window startd endd = NextTimeWindow
+		(LocalTime startd nexttime)
+		(LocalTime endd (TimeOfDay 23 59 0))
+	findfrom r afterday candidate
+		| ynum candidate > (ynum (localDay currenttime)) + 100 =
+			-- avoid possible infinite recursion
+			error $ "bug: calcNextTime did not find a time within 100 years to run " ++
+			show (schedule, lasttime, currenttime)
+		| otherwise = findfromChecked r afterday candidate
+	findfromChecked r afterday candidate = case r of
+		Daily
+			| afterday -> Just $ exactly $ addDays 1 candidate
+			| otherwise -> Just $ exactly candidate
+		Weekly Nothing
+			| afterday -> skip 1
+			| otherwise -> case (wday <$> lastrun, wday candidate) of
+				(Nothing, _) -> Just $ window candidate (addDays 6 candidate)
+				(Just old, curr)
+					| old == curr -> Just $ window candidate (addDays 6 candidate)
+					| otherwise -> skip 1
+		Monthly Nothing
+			| afterday -> skip 1
+			| maybe True (candidate `oneMonthPast`) lastrun ->
+				Just $ window candidate (endOfMonth candidate)
+			| otherwise -> skip 1
+		Yearly Nothing
+			| afterday -> skip 1
+			| maybe True (candidate `oneYearPast`) lastrun ->
+				Just $ window candidate (endOfYear candidate)
+			| otherwise -> skip 1
+		Weekly (Just w)
+			| w < 0 || w > maxwday -> Nothing
+			| w == wday candidate -> if afterday
+				then Just $ exactly $ addDays 7 candidate
+				else Just $ exactly candidate
+			| otherwise -> Just $ exactly $
+				addDays (fromIntegral $ (w - wday candidate) `mod` 7) candidate
+		Monthly (Just m)
+			| m < 0 || m > maxmday -> Nothing
+			-- TODO can be done more efficiently than recursing
+			| m == mday candidate -> if afterday
+				then skip 1
+				else Just $ exactly candidate
+			| otherwise -> skip 1
+		Yearly (Just y)
+			| y < 0 || y > maxyday -> Nothing
+			| y == yday candidate -> if afterday
+				then skip 365
+				else Just $ exactly candidate
+			| otherwise -> skip 1
+		Divisible n r'@Daily -> handlediv n r' yday (Just maxyday)
+		Divisible n r'@(Weekly _) -> handlediv n r' wnum (Just maxwnum)
+		Divisible n r'@(Monthly _) -> handlediv n r' mnum (Just maxmnum)
+		Divisible n r'@(Yearly _) -> handlediv n r' ynum Nothing
+		Divisible _ r'@(Divisible _ _) -> findfrom r' afterday candidate
+	  where
+		skip n = findfrom r False (addDays n candidate)
+		handlediv n r' getval mmax
+			| n > 0 && maybe True (n <=) mmax =
+				findfromwhere r' (divisible n . getval) afterday candidate
+			| otherwise = Nothing
+	findfromwhere r p afterday candidate
+		| maybe True (p . getday) next = next
+		| otherwise = maybe Nothing (findfromwhere r p True . getday) next
+	  where
+		next = findfrom r afterday candidate
+		getday = localDay . startTime
+	divisible n v = v `rem` n == 0
+
+-- Check if the new Day occurs one month or more past the old Day.
+oneMonthPast :: Day -> Day -> Bool
+new `oneMonthPast` old = fromGregorian y (m+1) d <= new
+  where
+	(y,m,d) = toGregorian old
+
+-- Check if the new Day occurs one year or more past the old Day.
+oneYearPast :: Day -> Day -> Bool
+new `oneYearPast` old = fromGregorian (y+1) m d <= new
+  where
+	(y,m,d) = toGregorian old
+
+endOfMonth :: Day -> Day
+endOfMonth day =
+	let (y,m,_d) = toGregorian day
+	in fromGregorian y m (gregorianMonthLength y m)
+
+endOfYear :: Day -> Day
+endOfYear day =
+	let (y,_m,_d) = toGregorian day
+	in endOfMonth (fromGregorian y maxmnum 1)
+
+-- extracting various quantities from a Day
+wday :: Day -> Int
+wday = thd3 . toWeekDate
+wnum :: Day -> Int
+wnum = snd3 . toWeekDate
+mday :: Day -> Int
+mday = thd3 . toGregorian
+mnum :: Day -> Int
+mnum = snd3 . toGregorian
+yday :: Day -> Int
+yday = snd . toOrdinalDate
+ynum :: Day -> Int
+ynum = fromIntegral . fst . toOrdinalDate
+
+-- Calendar max values.
+maxyday :: Int
+maxyday = 366 -- with leap days
+maxwnum :: Int
+maxwnum = 53 -- some years have more than 52
+maxmday :: Int
+maxmday = 31
+maxmnum :: Int
+maxmnum = 12
+maxwday :: Int
+maxwday = 7
+
+fromRecurrence :: Recurrence -> String
+fromRecurrence (Divisible n r) =
+	fromRecurrence' (++ "s divisible by " ++ show n) r
+fromRecurrence r = fromRecurrence' ("every " ++) r
+
+fromRecurrence' :: (String -> String) -> Recurrence -> String
+fromRecurrence' a Daily = a "day"
+fromRecurrence' a (Weekly n) = onday n (a "week")
+fromRecurrence' a (Monthly n) = onday n (a "month")
+fromRecurrence' a (Yearly n) = onday n (a "year")
+fromRecurrence' a (Divisible _n r) = fromRecurrence' a r -- not used
+
+onday :: Maybe Int -> String -> String
+onday (Just n) s = "on day " ++ show n ++ " of " ++ s
+onday Nothing s = s
+
+toRecurrence :: String -> Maybe Recurrence
+toRecurrence s = case words s of
+	("every":"day":[]) -> Just Daily
+	("on":"day":sd:"of":"every":something:[]) -> withday sd something
+	("every":something:[]) -> noday something
+	("days":"divisible":"by":sn:[]) -> 
+		Divisible <$> getdivisor sn <*> pure Daily
+	("on":"day":sd:"of":something:"divisible":"by":sn:[]) -> 
+		Divisible
+			<$> getdivisor sn
+			<*> withday sd something
+	("every":something:"divisible":"by":sn:[]) -> 
+		Divisible
+			<$> getdivisor sn
+			<*> noday something
+	(something:"divisible":"by":sn:[]) -> 
+		Divisible
+			<$> getdivisor sn
+			<*> noday something
+	_ -> Nothing
+  where
+	constructor "week" = Just Weekly
+	constructor "month" = Just Monthly
+	constructor "year" = Just Yearly
+	constructor u
+		| "s" `isSuffixOf` u = constructor $ dropFromEnd 1 u
+		| otherwise = Nothing
+	withday sd u = do
+		c <- constructor u
+		d <- readish sd
+		Just $ c (Just d)
+	noday u = do
+		c <- constructor u
+		Just $ c Nothing
+	getdivisor sn = do
+		n <- readish sn
+		if n > 0
+			then Just n
+			else Nothing
+
+fromScheduledTime :: ScheduledTime -> String
+fromScheduledTime AnyTime = "any time"
+fromScheduledTime (SpecificTime h m) = 
+	show h' ++ (if m > 0 then ":" ++ pad 2 (show m) else "") ++ " " ++ ampm
+  where
+	pad n s = replicate (n - length s) '0' ++ s
+	(h', ampm)
+		| h == 0 = (12, "AM")
+		| h < 12 = (h, "AM")
+		| h == 12 = (h, "PM")
+		| otherwise = (h - 12, "PM")
+
+toScheduledTime :: String -> Maybe ScheduledTime
+toScheduledTime "any time" = Just AnyTime
+toScheduledTime v = case words v of
+	(s:ampm:[])
+		| map toUpper ampm == "AM" ->
+			go s h0
+		| map toUpper ampm == "PM" ->
+			go s (\h -> (h0 h) + 12)
+		| otherwise -> Nothing
+	(s:[]) -> go s id
+	_ -> Nothing
+  where
+	h0 h
+		| h == 12 = 0
+		| otherwise = h
+	go :: String -> (Int -> Int) -> Maybe ScheduledTime
+	go s adjust =
+		let (h, m) = separate (== ':') s
+		in SpecificTime
+			<$> (adjust <$> readish h)
+			<*> if null m then Just 0 else readish m
+
+fromSchedule :: Schedule -> String
+fromSchedule (Schedule recurrence scheduledtime) = unwords
+	[ fromRecurrence recurrence
+	, "at"
+	, fromScheduledTime scheduledtime
+	]
+
+toSchedule :: String -> Maybe Schedule
+toSchedule = eitherToMaybe . parseSchedule
+
+parseSchedule :: String -> Either String Schedule
+parseSchedule s = do
+	r <- maybe (Left $ "bad recurrence: " ++ recurrence) Right
+		(toRecurrence recurrence)
+	t <- maybe (Left $ "bad time of day: " ++ scheduledtime) Right
+		(toScheduledTime scheduledtime)
+	Right $ Schedule r t
+  where
+	(rws, tws) = separate (== "at") (words s)
+	recurrence = unwords rws
+	scheduledtime = unwords tws
+
+prop_past_sane :: Bool
+prop_past_sane = and
+	[ all (checksout oneMonthPast) (mplus1 ++ yplus1)
+	, all (not . (checksout oneMonthPast)) (map swap (mplus1 ++ yplus1))
+	, all (checksout oneYearPast) yplus1
+	, all (not . (checksout oneYearPast)) (map swap yplus1)
+	]
+  where
+	mplus1 =   -- new date               old date, 1+ months before it
+		[ (fromGregorian 2014 01 15, fromGregorian 2013 12 15)
+		, (fromGregorian 2014 01 15, fromGregorian 2013 02 15)
+		, (fromGregorian 2014 02 15, fromGregorian 2013 01 15)
+		, (fromGregorian 2014 03 01, fromGregorian 2013 01 15)
+		, (fromGregorian 2014 03 01, fromGregorian 2013 12 15)
+		, (fromGregorian 2015 01 01, fromGregorian 2010 01 01)
+		]
+	yplus1 =   -- new date               old date, 1+ years before it
+		[ (fromGregorian 2014 01 15, fromGregorian 2012 01 16)
+		, (fromGregorian 2014 01 15, fromGregorian 2013 01 14)
+		, (fromGregorian 2022 12 31, fromGregorian 2000 01 01)
+		]
+	checksout cmp (new, old) = new `cmp` old
+	swap (a,b) = (b,a)
diff --git a/Utility/Scheduled/QuickCheck.hs b/Utility/Scheduled/QuickCheck.hs
new file mode 100644
index 0000000000..c8d4955af7
--- /dev/null
+++ b/Utility/Scheduled/QuickCheck.hs
@@ -0,0 +1,51 @@
+{- quickcheck for scheduled activities
+ - 
+ - Copyright 2013-2014 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module Utility.Scheduled.QuickCheck (prop_schedule_roundtrips) where
+
+import Utility.Scheduled
+import Utility.QuickCheck
+
+import Control.Applicative
+import Prelude
+
+instance Arbitrary Schedule where
+	arbitrary = Schedule <$> arbitrary <*> arbitrary
+
+instance Arbitrary ScheduledTime where
+	arbitrary = oneof
+		[ pure AnyTime
+		, SpecificTime 
+			<$> choose (0, 23)
+			<*> choose (1, 59)
+		]
+
+instance Arbitrary Recurrence where
+	arbitrary = oneof
+		[ pure Daily
+		, Weekly <$> arbday
+		, Monthly <$> arbday
+		, Yearly <$> arbday
+		, Divisible
+			<$> positive arbitrary
+			<*> oneof -- no nested Divisibles
+				[ pure Daily
+				, Weekly <$> arbday
+				, Monthly <$> arbday
+				, Yearly <$> arbday
+				]
+		]
+	  where
+		arbday = oneof
+			[ Just <$> nonNegative arbitrary
+			, pure Nothing
+			]
+
+prop_schedule_roundtrips :: Schedule -> Bool
+prop_schedule_roundtrips s = toSchedule (fromSchedule s) == Just s
diff --git a/Utility/Shell.hs b/Utility/Shell.hs
new file mode 100644
index 0000000000..ac2231450d
--- /dev/null
+++ b/Utility/Shell.hs
@@ -0,0 +1,58 @@
+{- /bin/sh handling
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.Shell (
+	shellPath,
+	shebang,
+	findShellCommand,
+) where
+
+import Utility.SafeCommand
+#ifdef mingw32_HOST_OS
+import Utility.Path
+import Utility.Exception
+import Utility.PartialPrelude
+#endif
+
+#ifdef mingw32_HOST_OS
+import System.FilePath
+#endif
+
+shellPath :: FilePath
+shellPath = "/bin/sh"
+
+shebang :: String
+shebang = "#!" ++ shellPath
+
+-- | On Windows, shebang is not handled by the kernel, so to support
+-- shell scripts etc, have to look at the program being run and
+-- parse it for shebang.
+--
+-- This has no effect on Unix.
+findShellCommand :: FilePath -> IO (FilePath, [CommandParam])
+findShellCommand f = do
+#ifndef mingw32_HOST_OS
+	defcmd
+#else
+	l <- catchDefaultIO Nothing $ headMaybe . lines <$> readFile f
+	case l of
+		Just ('#':'!':rest) -> case words rest of
+			[] -> defcmd
+			(c:ps) -> do
+				let ps' = map Param ps ++ [File f]
+				-- If the command is not inSearchPath,
+				-- take the base of it, and run eg "sh"
+				-- which in some cases on windows will work
+				-- despite it not being inSearchPath.
+				ok <- inSearchPath c
+				return (if ok then c else takeFileName c, ps')
+		_ -> defcmd
+#endif
+  where
+	defcmd = return (f, [])
diff --git a/Utility/ShellEscape.hs b/Utility/ShellEscape.hs
new file mode 100644
index 0000000000..bd4a921e5a
--- /dev/null
+++ b/Utility/ShellEscape.hs
@@ -0,0 +1,72 @@
+{- shell escaping
+ -
+ - Copyright 2010-2015 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.ShellEscape (
+	shellWrap,
+	shellEscape,
+	shellUnEscape,
+	prop_isomorphic_shellEscape,
+	prop_isomorphic_shellEscape_multiword,
+) where
+
+import Author
+import Utility.QuickCheck
+import Utility.Split
+import Data.Function
+
+import Data.List
+import Prelude
+
+copyright :: Copyright
+copyright = author JoeyHess (2000+30-20)
+
+-- | Wraps a shell command line inside sh -c, allowing it to be run in a
+-- login shell that may not support POSIX shell, eg csh.
+shellWrap :: String -> String
+shellWrap cmdline = copyright $ "sh -c " ++ shellEscape cmdline
+
+-- | Escapes a string to be safely able to be exposed to the shell.
+--
+-- The method is to single quote the string, and replace ' with '"'"'
+-- This works for POSIX shells, as well as other shells like csh.
+shellEscape :: String -> String
+shellEscape f = [q] ++ escaped ++ [q]
+  where
+	escaped = intercalate escq $ splitc q f
+	q = '\''
+	qq = '"'
+	escq = [q, qq, q, qq, q] & copyright
+
+-- | Unescapes a set of shellEscaped words or filenames.
+shellUnEscape :: String -> [String]
+shellUnEscape [] = []
+shellUnEscape s = word : shellUnEscape rest
+  where
+	(word, rest) = findword "" s
+	findword w [] = (w, "")
+	findword w (c:cs)
+		| c == ' ' && copyright = (w, cs)
+		| c == '\'' = inquote c w cs
+		| c == '"' = inquote c w cs
+		| otherwise = findword (w++[c]) cs
+	inquote _ w [] = (w, "")
+	inquote q w (c:cs)
+		| c == q && copyright = findword w cs
+		| otherwise = inquote q (w++[c]) cs
+
+prop_isomorphic_shellEscape :: TestableString -> Bool
+prop_isomorphic_shellEscape ts = [s] == (shellUnEscape . shellEscape) s
+  where
+	s = fromTestableString ts
+
+prop_isomorphic_shellEscape_multiword :: [TestableString] -> Bool
+prop_isomorphic_shellEscape_multiword ts =
+	l == (shellUnEscape . unwords . map shellEscape) l
+  where
+	l = map fromTestableString ts
diff --git a/Utility/SimpleProtocol.hs b/Utility/SimpleProtocol.hs
new file mode 100644
index 0000000000..acd2439290
--- /dev/null
+++ b/Utility/SimpleProtocol.hs
@@ -0,0 +1,151 @@
+{- Simple line-based protocols.
+ -
+ - Copyright 2013-2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE FlexibleInstances #-}
+{-# OPTIONS_GHC -fno-warn-orphans #-}
+
+module Utility.SimpleProtocol (
+	Sendable(..),
+	Receivable(..),
+	parseMessage,
+	Serializable(..),
+	Parser,
+	parseFail,
+	parse0,
+	parse1,
+	parse2,
+	parse3,
+	parse4,
+	parse5,
+	dupIoHandles,
+	getProtocolLine,
+) where
+
+import Data.Char
+import GHC.IO.Handle
+import Text.Read
+
+import Common
+
+-- Messages that can be sent.
+class Sendable m where
+	formatMessage :: m -> [String]
+
+-- Messages that can be received.
+class Receivable m where
+	-- Passed the first word of the message, returns
+	-- a Parser that can be be fed the rest of the message to generate
+	-- the value.
+	parseCommand :: String -> Parser m
+
+parseMessage :: (Receivable m) => String -> Maybe m
+parseMessage s = parseCommand command rest
+  where
+	(command, rest) = splitWord s
+
+class Serializable a where
+	serialize :: a -> String
+	deserialize :: String -> Maybe a
+
+instance Serializable [Char] where
+	serialize = id
+	deserialize = Just
+
+instance Serializable Integer where
+	serialize = show
+	deserialize = readMaybe
+
+instance Serializable ExitCode where
+	serialize ExitSuccess = "0"
+	serialize (ExitFailure n) = show n
+	deserialize "0" = Just ExitSuccess
+	deserialize s = ExitFailure <$> readMaybe s
+
+{- Parsing the parameters of messages. Using the right parseN ensures
+ - that the string is split into exactly the requested number of words,
+ - which allows the last parameter of a message to contain arbitrary
+ - whitespace, etc, without needing any special quoting.
+ -}
+type Parser a = String -> Maybe a
+
+parseFail :: Parser a
+parseFail _ = Nothing
+
+parse0 :: a -> Parser a
+parse0 mk "" = Just mk
+parse0 _ _ = Nothing
+
+parse1 :: Serializable p1 => (p1 -> a) -> Parser a
+parse1 mk p1 = mk <$> deserialize p1
+
+parse2 :: (Serializable p1, Serializable p2) => (p1 -> p2 -> a) -> Parser a
+parse2 mk s = mk <$> deserialize p1 <*> deserialize p2
+  where
+	(p1, p2) = splitWord s
+
+parse3 :: (Serializable p1, Serializable p2, Serializable p3) => (p1 -> p2 -> p3 -> a) -> Parser a
+parse3 mk s = mk <$> deserialize p1 <*> deserialize p2 <*> deserialize p3
+  where
+	(p1, rest) = splitWord s
+	(p2, p3) = splitWord rest
+
+parse4 :: (Serializable p1, Serializable p2, Serializable p3, Serializable p4) => (p1 -> p2 -> p3 -> p4 -> a) -> Parser a
+parse4 mk s = mk <$> deserialize p1 <*> deserialize p2 <*> deserialize p3 <*> deserialize p4
+  where
+	(p1, rest) = splitWord s
+	(p2, rest') = splitWord rest
+	(p3, p4) = splitWord rest'
+
+parse5 :: (Serializable p1, Serializable p2, Serializable p3, Serializable p4, Serializable p5) => (p1 -> p2 -> p3 -> p4 -> p5 -> a) -> Parser a
+parse5 mk s = mk <$> deserialize p1 <*> deserialize p2 <*> deserialize p3 <*> deserialize p4 <*> deserialize p5
+  where
+	(p1, rest) = splitWord s
+	(p2, rest') = splitWord rest
+	(p3, rest'') = splitWord rest'
+	(p4, p5) = splitWord rest''
+
+splitWord :: String -> (String, String)
+splitWord = separate isSpace
+
+{- When a program speaks a simple protocol over stdio, any other output
+ - to stdout (or anything that attempts to read from stdin)
+ - will mess up the protocol. To avoid that, close stdin,
+ - and duplicate stderr to stdout. Return two new handles
+ - that are duplicates of the original (stdin, stdout). -}
+dupIoHandles :: IO (Handle, Handle)
+dupIoHandles = do
+	readh <- hDuplicate stdin
+	writeh <- hDuplicate stdout
+	nullh <- openFile devNull ReadMode
+	nullh `hDuplicateTo` stdin
+	stderr `hDuplicateTo` stdout
+	return (readh, writeh)
+
+{- Reads a line, but to avoid super-long lines eating memory, returns
+ - Nothing if 32 kb have been read without seeing a '\n'
+ -
+ - If there is a '\r' before the '\n', it is removed, to support
+ - systems using "\r\n" at ends of lines 
+ -
+ - This implementation is not super efficient, but as long as the Handle
+ - supports buffering, it avoids reading a character at a time at the
+ - syscall level.
+ -
+ - Throws isEOFError when no more input is available.
+ -}
+getProtocolLine :: Handle -> IO (Maybe String)
+getProtocolLine h = go (32768 :: Int) []
+  where
+	go 0 _ = return Nothing
+	go n l = do
+		c <- hGetChar h
+		if c == '\n'
+			then return $ Just $ reverse $ 
+				case l of
+					('\r':rest) -> rest
+					_ -> l
+			else go (n-1) (c:l)
diff --git a/Utility/Split.hs b/Utility/Split.hs
new file mode 100644
index 0000000000..028218e006
--- /dev/null
+++ b/Utility/Split.hs
@@ -0,0 +1,39 @@
+{- split utility functions
+ -
+ - Copyright 2017 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Split (
+	split,
+	splitc,
+	replace,
+	dropFromEnd,
+) where
+
+import Data.List (intercalate)
+import Data.List.Split (splitOn)
+
+-- | same as Data.List.Utils.split
+--
+-- intercalate x . splitOn x === id
+split :: Eq a => [a] -> [a] -> [[a]]
+split = splitOn
+
+-- | Split on a single character. This is over twice as fast as using
+-- split on a list of length 1, while producing identical results. -}
+splitc :: Eq c => c -> [c] -> [[c]]
+splitc c s = case break (== c) s of
+	(i, _c:rest) -> i : splitc c rest
+	(i, []) -> i : []
+
+-- | same as Data.List.Utils.replace
+replace :: Eq a => [a] -> [a] -> [a] -> [a] 
+replace old new = intercalate new . split old
+
+-- | Only traverses the list once while dropping the last n items.
+dropFromEnd :: Int -> [a] -> [a]
+dropFromEnd n l = zipWith const l (drop n l)
diff --git a/Utility/SshConfig.hs b/Utility/SshConfig.hs
new file mode 100644
index 0000000000..83c63fcd3d
--- /dev/null
+++ b/Utility/SshConfig.hs
@@ -0,0 +1,164 @@
+{- ssh config file parsing and modification
+ -
+ - Copyright 2013 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.SshConfig (
+	SshConfig(..),
+	Comment(..),
+	SshSetting(..),
+	Indent,
+	Host,
+	Key,
+	Value,
+	parseSshConfig,
+	genSshConfig,
+	findHostConfigKey,
+	addToHostConfig,
+	modifyUserSshConfig,
+	changeUserSshConfig,
+	writeSshConfig,
+	setSshConfigMode,
+	sshDir,
+) where
+
+import Common
+import Utility.UserInfo
+import Utility.Tmp
+import Utility.FileMode
+
+import Data.Char
+import Data.Ord
+import Data.Either
+import System.PosixCompat.Files (groupWriteMode, otherWriteMode)
+
+data SshConfig
+	= GlobalConfig SshSetting
+	| HostConfig Host [Either Comment SshSetting]
+	| CommentLine Comment
+	deriving (Show)
+
+data Comment = Comment Indent String
+	deriving (Show)
+
+data SshSetting = SshSetting Indent Key Value
+	deriving (Show)
+
+type Indent = String
+type Host = String
+type Key = String
+type Value = String
+
+{- Parses ~/.ssh/config. Comments and indentation are preserved.
+ -
+ - Note that there is no parse failure. If a line cannot be parsed, it will
+ - be taken to be a SshSetting that contains the whole line as the key,
+ - and has no value. -}
+parseSshConfig :: String -> [SshConfig]
+parseSshConfig = go [] . lines
+  where
+	go c [] = reverse c
+	go c (l:ls)
+		| iscomment l = collect $ CommentLine $ mkcomment l
+		| otherwise = case splitline l of
+			(indent, k, v)
+				| isHost k -> hoststanza v c [] ls
+				| otherwise -> collect $ GlobalConfig $ SshSetting indent k v
+	  where
+		collect v = go (v:c) ls
+
+	hoststanza host c hc [] = go (HostConfig host (reverse hc):c) []
+	hoststanza host c hc (l:ls)
+		| iscomment l = hoststanza host c ((Left $ mkcomment l):hc) ls
+		| otherwise = case splitline l of
+			(indent, k, v)
+				| isHost k -> hoststanza v
+					(HostConfig host (reverse hc):c) [] ls
+				| otherwise -> hoststanza host c
+					((Right $ SshSetting indent k v):hc) ls
+
+	iscomment l = all isSpace l || "#" `isPrefixOf` (dropWhile isSpace l)
+
+	splitline l = (indent, k, v)
+	  where
+		(indent, rest) = span isSpace l
+		(k, v) = separate isSpace rest
+	
+	mkcomment l = Comment indent c
+	  where
+		(indent, c) = span isSpace l
+
+	isHost v = map toLower v == "host"
+	
+genSshConfig :: [SshConfig] -> String
+genSshConfig = unlines . concatMap gen
+  where
+	gen (CommentLine c) = [comment c]
+	gen (GlobalConfig s) = [setting s]
+	gen (HostConfig h cs) = ("Host " ++ h) : map (either comment setting) cs
+
+	setting (SshSetting indent k v) = indent ++ k ++ 
+		if null v then "" else " " ++ v
+	comment (Comment indent c) = indent ++ c
+
+findHostConfigKey :: SshConfig -> Key -> Maybe Value
+findHostConfigKey (HostConfig _ cs) wantk = go (rights cs) (map toLower wantk)
+  where
+	go [] _ = Nothing
+	go ((SshSetting _ k v):rest) wantk'
+		| map toLower k == wantk' = Just v
+		| otherwise = go rest wantk'
+findHostConfigKey _ _ = Nothing
+
+{- Adds a particular Key and Value to a HostConfig. -}
+addToHostConfig :: SshConfig -> Key -> Value -> SshConfig
+addToHostConfig (HostConfig host cs) k v = 
+	HostConfig host $ Right (SshSetting indent k v) : cs
+  where
+	{- The indent is taken from any existing SshSetting
+	 - in the HostConfig (largest indent wins). -}
+	indent = fromMaybe "\t" $ headMaybe $ reverse $
+		sortBy (comparing length) $ map getindent cs
+	getindent (Right (SshSetting i _ _)) = i
+	getindent (Left (Comment i _)) = i
+addToHostConfig other _ _ = other
+
+modifyUserSshConfig :: ([SshConfig] -> [SshConfig]) -> IO ()
+modifyUserSshConfig modifier = changeUserSshConfig $ 
+	genSshConfig . modifier . parseSshConfig
+
+changeUserSshConfig :: (String -> String) -> IO ()
+changeUserSshConfig modifier = do
+	sshdir <- sshDir
+	let configfile = sshdir </> "config"
+	whenM (doesFileExist configfile) $ do
+		c <- readFileStrict configfile
+		let c' = modifier c
+		when (c /= c') $ do
+			-- If it's a symlink, replace the file it
+			-- points to.
+			f <- catchDefaultIO configfile (canonicalizePath configfile)
+			viaTmp writeSshConfig f c'
+
+writeSshConfig :: FilePath -> String -> IO ()
+writeSshConfig f s = do
+	writeFile f s
+	setSshConfigMode (toRawFilePath f)
+
+{- Ensure that the ssh config file lacks any group or other write bits, 
+ - since ssh is paranoid about not working if other users can write
+ - to one of its config files (.ssh/config and .ssh/authorized_keys).
+ -
+ - If the chmod fails, ignore the failure, as it might be a filesystem like
+ - Android's that does not support file modes.
+ -}
+setSshConfigMode :: RawFilePath -> IO ()
+setSshConfigMode f = void $ tryIO $ modifyFileMode f $
+	removeModes [groupWriteMode, otherWriteMode]
+
+sshDir :: IO FilePath
+sshDir = do
+	home <- myHomeDir
+	return $ home </> ".ssh"
diff --git a/Utility/SshHost.hs b/Utility/SshHost.hs
new file mode 100644
index 0000000000..d8a8da11df
--- /dev/null
+++ b/Utility/SshHost.hs
@@ -0,0 +1,29 @@
+{- ssh hostname sanitization
+ -
+ - When constructing a ssh command with a hostname that may be controlled
+ - by an attacker, prevent the hostname from starting with "-",
+ - to prevent tricking ssh into arbitrary command execution via
+ - eg "-oProxyCommand="
+ -
+ - Copyright 2017 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.SshHost (SshHost, mkSshHost, fromSshHost) where
+
+newtype SshHost = SshHost String
+
+-- | Smart constructor for a legal hostname or IP address.
+-- In some cases, it may be prefixed with "user@" to specify the remote
+-- user at the host.
+--
+-- For now, we only filter out the problem ones, because determining an
+-- actually legal hostnames is quite complicated.
+mkSshHost :: String -> Either String SshHost
+mkSshHost h@('-':_) = Left $
+	"rejecting ssh hostname that starts with '-' : " ++ h
+mkSshHost h = Right (SshHost h)
+
+fromSshHost :: SshHost -> String
+fromSshHost (SshHost h) = h
diff --git a/Utility/StatelessOpenPGP.hs b/Utility/StatelessOpenPGP.hs
new file mode 100644
index 0000000000..4f8908c758
--- /dev/null
+++ b/Utility/StatelessOpenPGP.hs
@@ -0,0 +1,207 @@
+{- Stateless OpenPGP interface
+ -
+ - Copyright 2011-2024 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP, OverloadedStrings #-}
+
+module Utility.StatelessOpenPGP (
+	SOPCmd(..),
+	SOPSubCmd,
+	SOPProfile(..),
+	Password,
+	EmptyDirectory(..),
+	Armoring(..),
+	encryptSymmetric,
+	decryptSymmetric,
+	test_encrypt_decrypt_Symmetric,
+	feedRead,
+	feedRead',
+) where
+
+import Common
+#ifndef mingw32_HOST_OS
+import System.Posix.Types
+import System.Posix.IO
+#else
+import Utility.Tmp
+#endif
+import Utility.Tmp.Dir
+import Author
+
+import Control.Concurrent.Async
+import Control.Monad.IO.Class
+import qualified Data.ByteString as B
+
+copyright :: Copyright
+copyright = author JoeyHess (max 2024 2009)
+
+{- The command to run, eq sqop. -}
+newtype SOPCmd = SOPCmd { unSOPCmd :: String }
+
+{- The subcommand to run eg encrypt. -}
+type SOPSubCmd = String
+
+newtype SOPProfile = SOPProfile String
+
+{- Note that SOP requires passwords to be UTF-8 encoded, and that they
+ - may try to trim trailing whitespace. They may also forbid leading
+ - whitespace, or forbid some non-printing characters. -}
+type Password = B.ByteString
+
+newtype Armoring = Armoring Bool
+
+{- The path to a sufficiently empty directory.
+ -
+ - This is unfortunately needed because of an infelicity in the SOP
+ - standard, as documented in section 9.9 "Be Careful with Special
+ - Designators", when using "@FD:" and similar designators the SOP
+ - command may test for the presense of a file with the same name on the
+ - filesystem, and fail with  AMBIGUOUS_INPUT. 
+ -
+ - Since we don't want to need to deal with such random failure due to
+ - whatever filename might be present, when running sop commands using
+ - special designators, an empty directory has to be provided, and the
+ - command is run in that directory. Of course, this necessarily means
+ - that any relative paths passed to the command have to be made absolute.
+ -
+ - The directory does not really have to be empty, it just needs to be one
+ - that should not contain any files with names starting with "@".
+ -}
+newtype EmptyDirectory = EmptyDirectory FilePath
+
+{- Encrypt using symmetric encryption with the specified password. -}
+encryptSymmetric
+	:: (MonadIO m, MonadMask m)
+	=> SOPCmd
+	-> Password
+	-> EmptyDirectory
+	-> Maybe SOPProfile
+	-> Armoring
+	-> (Handle -> IO ())
+	-> (Handle -> m a)
+	-> m a
+encryptSymmetric sopcmd password emptydirectory mprofile armoring feeder reader =
+	feedRead sopcmd "encrypt" params password emptydirectory feeder reader
+  where
+	params = map Param $ catMaybes
+		[ case armoring of
+			Armoring False -> Just "--no-armor"
+			Armoring True -> Nothing
+		, Just "--as=binary"
+		, case mprofile of
+			Just (SOPProfile profile) -> 
+				Just $ "--profile=" ++ profile
+			Nothing -> Nothing
+		]
+
+{- Deccrypt using symmetric encryption with the specified password. -}
+decryptSymmetric
+	:: (MonadIO m, MonadMask m)
+	=> SOPCmd
+	-> Password
+	-> EmptyDirectory
+	-> (Handle -> IO ())
+	-> (Handle -> m a)
+	-> m a
+decryptSymmetric sopcmd password emptydirectory feeder reader =
+	feedRead sopcmd "decrypt" [] password emptydirectory feeder reader
+
+{- Test a value round-trips through symmetric encryption and decryption. -}
+test_encrypt_decrypt_Symmetric :: SOPCmd -> SOPCmd -> Password -> Armoring -> B.ByteString -> IO Bool
+test_encrypt_decrypt_Symmetric a b password armoring v = catchBoolIO $
+	withTmpDir "test" $ \d -> do
+		let ed = EmptyDirectory d
+		enc <- encryptSymmetric a password ed Nothing armoring
+			(`B.hPutStr` v) B.hGetContents
+		dec <- decryptSymmetric b password ed
+			(`B.hPutStr` enc) B.hGetContents
+		return (v == dec)
+
+{- Runs a SOP command with some parameters. First sends it a password
+ - via '--with-password'. Then runs a feeder action that is
+ - passed a handle and should write to it all the data to input to the
+ - command. Finally, runs a reader action that is passed a handle to
+ - the command's output.
+ -
+ - Note that the reader must fully consume its input before returning. -}
+feedRead
+	:: (MonadIO m, MonadMask m)
+	=> SOPCmd
+	-> SOPSubCmd
+	-> [CommandParam]
+	-> Password
+	-> EmptyDirectory
+	-> (Handle -> IO ())
+	-> (Handle -> m a)
+	-> m a
+feedRead cmd subcmd params password emptydirectory feeder reader = do
+#ifndef mingw32_HOST_OS
+	let setup = liftIO $ do
+		-- pipe the passphrase in on a fd
+		(frompipe, topipe) <- System.Posix.IO.createPipe
+		setFdOption topipe CloseOnExec True
+		toh <- fdToHandle topipe
+		t <- async $ do
+			B.hPutStr toh (password <> "\n")
+			hClose toh
+		let Fd pfd = frompipe
+		let passwordfd = [Param $ "--with-password=@FD:"++show pfd]
+		return (passwordfd, frompipe, toh, t)
+	let cleanup (_, frompipe, toh, t) = liftIO $ do
+		closeFd frompipe
+		when copyright $
+			hClose toh
+		cancel t
+	bracket setup cleanup $ \(passwordfd, _, _, _) ->
+		go (Just emptydirectory) (passwordfd ++ params)
+#else
+	-- store the password in a temp file
+	withTmpFile "sop" $ \tmpfile h -> do
+		liftIO $ B.hPutStr h password
+		liftIO $ hClose h
+		let passwordfile = [Param $ "--with-password="++tmpfile]
+		-- Don't need to pass emptydirectory since @FD is not used,
+		-- and so tmpfile also does not need to be made absolute.
+		case emptydirectory of
+			EmptyDirectory _ -> return ()
+		go Nothing $ passwordfile ++ params
+#endif
+  where
+	go med params' = feedRead' cmd subcmd params' med feeder reader
+
+{- Like feedRead, but without password. -}
+feedRead'
+	:: (MonadIO m, MonadMask m)
+	=> SOPCmd
+	-> SOPSubCmd
+	-> [CommandParam]
+	-> Maybe EmptyDirectory
+	-> (Handle -> IO ())
+	-> (Handle -> m a)
+	-> m a
+feedRead' (SOPCmd cmd) subcmd params med feeder reader = do
+	let p = (proc cmd (subcmd:toCommand params))
+		{ std_in = CreatePipe
+		, std_out = CreatePipe
+		, std_err = Inherit
+		, cwd = case med of
+			Just (EmptyDirectory d) -> Just d
+			Nothing -> Nothing
+		}
+	copyright =<< bracket (setup p) cleanup (go p)
+  where
+	setup = liftIO . createProcess
+	cleanup = liftIO . cleanupProcess
+
+	go p (Just to, Just from, _, pid) =
+		let runfeeder = do
+			feeder to
+			hClose to
+		in bracketIO (async runfeeder) cancel $ const $ do
+			r <- reader from
+			liftIO $ forceSuccessProcess p pid
+			return r
+	go _ _ = error "internal"
diff --git a/Utility/Su.hs b/Utility/Su.hs
new file mode 100644
index 0000000000..d2d970298a
--- /dev/null
+++ b/Utility/Su.hs
@@ -0,0 +1,122 @@
+{- su to root
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.Su (
+	WhosePassword(..),
+	PasswordPrompt(..),
+	describePasswordPrompt,
+	describePasswordPrompt',
+	SuCommand,
+	runSuCommand,
+	mkSuCommand,
+) where
+
+import Common
+
+#ifndef mingw32_HOST_OS
+import Utility.Env
+import System.Posix.IO
+import System.Posix.Terminal
+#endif
+
+data WhosePassword
+	= RootPassword
+	| UserPassword
+	| SomePassword
+	-- ^ may be user or root; su program should indicate which
+	deriving (Show)
+
+data PasswordPrompt
+	= WillPromptPassword WhosePassword
+	| MayPromptPassword WhosePassword
+	| NoPromptPassword
+	deriving (Show)
+
+describePasswordPrompt :: PasswordPrompt -> Maybe String
+describePasswordPrompt (WillPromptPassword whose) = Just $
+	"You will be prompted for " ++ describeWhosePassword whose ++ " password"
+describePasswordPrompt (MayPromptPassword whose) = Just $
+	"You may be prompted for " ++ describeWhosePassword whose ++ " password"
+describePasswordPrompt NoPromptPassword = Nothing
+
+describeWhosePassword :: WhosePassword -> String
+describeWhosePassword RootPassword = "root's"
+describeWhosePassword UserPassword = "your"
+describeWhosePassword SomePassword = "a"
+
+data SuCommand = SuCommand PasswordPrompt String [CommandParam]
+	deriving (Show)
+
+describePasswordPrompt' :: Maybe SuCommand -> Maybe String
+describePasswordPrompt' (Just (SuCommand p _ _)) = describePasswordPrompt p
+describePasswordPrompt' Nothing = Nothing
+
+runSuCommand :: (Maybe SuCommand) -> Maybe [(String, String)] -> IO Bool
+runSuCommand (Just (SuCommand _ cmd ps)) environ = boolSystemEnv cmd ps environ
+runSuCommand Nothing _ = return False
+
+-- Generates a SuCommand that runs a command as root, fairly portably.
+--
+-- Does not use sudo commands if something else is available, because
+-- the user may not be in sudoers and we couldn't differentiate between
+-- that and the command failing. Although, some commands like gksu
+-- decide based on the system's configuration whether sudo should be used.
+mkSuCommand :: String -> [CommandParam] -> IO (Maybe SuCommand)
+#ifndef mingw32_HOST_OS
+mkSuCommand cmd ps = do
+	pwd <- getCurrentDirectory
+	firstM (\(SuCommand _ p _) -> inSearchPath p) =<< selectcmds pwd
+  where
+	selectcmds pwd = ifM (inx <||> (not <$> atconsole))
+		( return (graphicalcmds pwd ++ consolecmds pwd)
+		, return (consolecmds pwd)
+		)
+	
+	inx = isJust <$> getEnv "DISPLAY"
+	atconsole = queryTerminal stdInput
+
+	-- These will only work when the user is logged into a desktop.
+	graphicalcmds pwd =
+		[ SuCommand (MayPromptPassword SomePassword) "gksu"
+			[Param shellcmd]
+		, SuCommand (MayPromptPassword SomePassword) "kdesu"
+			[Param "-c", Param shellcmd]
+		-- pkexec does not run the command in the current
+		-- working directory, but in root's HOME.
+		, SuCommand (MayPromptPassword SomePassword) "pkexec" $
+			[Param "sh", Param "-c", Param $ unwords
+				[ "cd", shellEscape pwd
+				, "&&"
+				, shellcmd
+				]
+			]
+		-- Available in Debian's menu package; knows about lots of
+		-- ways to gain root.
+		, SuCommand (MayPromptPassword SomePassword) "su-to-root"
+			[Param "-X", Param "-c", Param shellcmd]
+		-- OSX native way to run a command as root, prompts in GUI
+		, SuCommand (WillPromptPassword RootPassword) "osascript"
+			[Param "-e", Param ("do shell script \"" ++ shellcmd ++ "\" with administrator privileges")]
+		]
+	
+	-- These will only work when run in a console.
+	consolecmds _pwd = 
+		[ SuCommand (WillPromptPassword RootPassword) "su"
+			[Param "-c", Param shellcmd]
+		, SuCommand (MayPromptPassword UserPassword) "sudo"
+			([Param cmd] ++ ps)
+		, SuCommand (MayPromptPassword SomePassword) "su-to-root"
+			[Param "-c", Param shellcmd]
+		]
+	
+	shellcmd = unwords $ map shellEscape (cmd:toCommand ps)
+#else
+-- For windows, we assume the user has administrator access.
+mkSuCommand cmd ps = return $ Just $ SuCommand NoPromptPassword cmd ps
+#endif
diff --git a/Utility/SystemDirectory.hs b/Utility/SystemDirectory.hs
new file mode 100644
index 0000000000..a7d60f931e
--- /dev/null
+++ b/Utility/SystemDirectory.hs
@@ -0,0 +1,16 @@
+{- System.Directory without its conflicting isSymbolicLink and getFileSize.
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+-- Disable warnings because only some versions of System.Directory export
+-- isSymbolicLink.
+{-# OPTIONS_GHC -fno-warn-tabs -w #-}
+
+module Utility.SystemDirectory (
+	module System.Directory
+) where
+
+import System.Directory hiding (isSymbolicLink, getFileSize)
diff --git a/Utility/TList.hs b/Utility/TList.hs
new file mode 100644
index 0000000000..6a5ff55c01
--- /dev/null
+++ b/Utility/TList.hs
@@ -0,0 +1,103 @@
+{- Transactional lists
+ -
+ - Based on DLists, a transactional list can quickly and efficiently
+ - have items inserted at either end, or a whole list appended to it.
+ -
+ - Unlike a TQueue, the entire contents of a TList can be efficiently
+ - read without modifying it.
+ -
+ - Copyright 2013-2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE BangPatterns #-}
+{-# LANGUAGE CPP #-}
+
+module Utility.TList (
+	TList,
+	newTList,
+	getTList,
+	setTList,
+	takeTList,
+	readTList,
+	consTList,
+	snocTList,
+	appendTList,
+	headTList,
+) where
+
+import Common
+
+import Control.Concurrent.STM
+import qualified Data.DList as D
+
+type TList a = TMVar (D.DList a)
+
+newTList :: STM (TList a)
+newTList = newEmptyTMVar
+
+{- Takes the head of the TList, leaving the rest.
+ - Blocks when empty.
+ -
+ - O(n) due to use of D.tail
+ -}
+headTList :: TList a -> STM a
+headTList tlist = do
+	dl <- takeTMVar tlist
+#if MIN_VERSION_dlist(1,0,0)
+	let !dl' = D.fromList $ D.tail dl
+#else
+	let !dl' = D.tail dl
+#endif
+	unless (emptyDList dl') $
+		putTMVar tlist dl'
+	return (D.head dl)
+
+{- Gets the contents of the TList. Blocks when empty.
+ - TList is left empty. -}
+getTList :: TList a -> STM [a]
+getTList tlist = D.toList <$> getTDList tlist
+
+getTDList :: TList a -> STM (D.DList a)
+getTDList = takeTMVar
+
+{- Replaces the contents of the TList. -}
+setTList :: TList a -> [a] -> STM ()
+setTList tlist = setTDList tlist . D.fromList
+
+setTDList :: TList a -> D.DList a -> STM ()
+setTDList tlist = modifyTList tlist . const
+
+{- Takes anything currently in the TList, without blocking.
+ - TList is left empty. -}
+takeTList :: TList a -> STM [a]
+takeTList tlist = maybe [] D.toList <$> tryTakeTMVar tlist
+
+{- Reads anything in the list, without modifying it, or blocking. -}
+readTList :: TList a -> STM [a]
+readTList tlist = maybe [] D.toList <$> tryReadTMVar tlist
+
+{- Mutates a TList.
+ -
+ - O(n) due to the use of emptyDList -}
+modifyTList :: TList a -> (D.DList a -> D.DList a) -> STM ()
+modifyTList tlist a = do
+	dl <- fromMaybe D.empty <$> tryTakeTMVar tlist
+	let !dl' = a dl
+	{- The TMVar is left empty when the list is empty.
+	 - Thus attempts to read it automatically block. -}
+	unless (emptyDList dl') $
+		putTMVar tlist dl'
+
+emptyDList :: D.DList a -> Bool
+emptyDList = null . D.toList
+
+consTList :: TList a -> a -> STM ()
+consTList tlist v = modifyTList tlist $ \dl -> D.cons v dl
+
+snocTList :: TList a -> a -> STM ()
+snocTList tlist v = modifyTList tlist $ \dl -> D.snoc dl v
+
+appendTList :: TList a -> [a] -> STM ()
+appendTList tlist l = modifyTList tlist $ \dl -> D.append dl (D.fromList l)
diff --git a/Utility/Tense.hs b/Utility/Tense.hs
new file mode 100644
index 0000000000..a0e5fee368
--- /dev/null
+++ b/Utility/Tense.hs
@@ -0,0 +1,60 @@
+{- Past and present tense text.
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+
+module Utility.Tense (
+	Tense(..),
+	TenseChunk(..),
+	TenseText,
+	renderTense,
+	tenseWords,
+) where
+
+import qualified Data.Text as T
+import Data.Text (Text)
+import GHC.Exts( IsString(..) )
+
+data Tense = Present | Past
+	deriving (Eq)
+
+data TenseChunk = Tensed Text Text | UnTensed Text
+	deriving (Eq, Ord, Show)
+
+newtype TenseText = TenseText [TenseChunk]
+	deriving (Eq, Ord)
+
+{- Allows OverloadedStrings to be used, to build UnTensed chunks. -}
+instance IsString TenseChunk where
+	fromString = UnTensed . T.pack
+
+{- Allows OverloadedStrings to be used, to provide UnTensed TenseText. -}
+instance IsString TenseText where
+	fromString s = TenseText [fromString s]
+
+renderTense :: Tense -> TenseText -> Text
+renderTense tense (TenseText chunks) = T.concat $ map render chunks
+  where
+	render (Tensed present past)
+		| tense == Present = present
+		| otherwise = past
+	render (UnTensed s) = s
+
+{- Builds up a TenseText, separating chunks with spaces.
+ -
+ - However, rather than just intersperse new chunks for the spaces,
+ - the spaces are appended to the end of the chunks.
+ -}
+tenseWords :: [TenseChunk] -> TenseText
+tenseWords = TenseText . go []
+  where
+	go c [] = reverse c
+	go c (w:[]) = reverse (w:c)
+	go c ((UnTensed w):ws) = go (UnTensed (addspace w) : c) ws
+	go c ((Tensed w1 w2):ws) =
+		go (Tensed (addspace w1) (addspace w2) : c) ws
+	addspace w = T.append w " "
diff --git a/Utility/Terminal.hs b/Utility/Terminal.hs
new file mode 100644
index 0000000000..5c0b5a6b8e
--- /dev/null
+++ b/Utility/Terminal.hs
@@ -0,0 +1,44 @@
+{- Determining if output is to a terminal.
+ -
+ - Copyright 2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP, ScopedTypeVariables #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Terminal (
+	IsTerminal(..),
+	checkIsTerminal,
+) where
+
+import System.IO
+#ifdef mingw32_HOST_OS
+import System.Win32.MinTTY (isMinTTYHandle)
+import System.Win32.Types
+import Graphics.Win32.Misc
+import Control.Exception
+#endif
+
+newtype IsTerminal = IsTerminal Bool
+
+checkIsTerminal :: Handle -> IO IsTerminal
+checkIsTerminal h = do
+#ifndef mingw32_HOST_OS
+	b <- hIsTerminalDevice h
+	return (IsTerminal b)
+#else
+	b <- hIsTerminalDevice h
+	if b
+		then return (IsTerminal b)
+		else do
+			h' <- getStdHandle sTD_OUTPUT_HANDLE
+				`catch` \(_ :: IOError) ->
+					return nullHANDLE
+			if h' == nullHANDLE
+				then return (IsTerminal False)
+				else do
+					b' <- isMinTTYHandle h'
+					return (IsTerminal b')
+#endif
diff --git a/Utility/ThreadLock.hs b/Utility/ThreadLock.hs
new file mode 100644
index 0000000000..d43e4f64ae
--- /dev/null
+++ b/Utility/ThreadLock.hs
@@ -0,0 +1,23 @@
+{- locking between threads
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.ThreadLock (
+	Lock,
+	newLock,
+	withLock,
+) where
+
+import Control.Concurrent.MVar
+
+type Lock = MVar ()
+
+newLock :: IO Lock
+newLock = newMVar ()
+
+{- Runs an action with a lock held, so only one thread at a time can run it. -}
+withLock :: Lock -> IO a -> IO a
+withLock lock = withMVar lock . const
diff --git a/Utility/ThreadScheduler.hs b/Utility/ThreadScheduler.hs
new file mode 100644
index 0000000000..9e0b620f87
--- /dev/null
+++ b/Utility/ThreadScheduler.hs
@@ -0,0 +1,67 @@
+{- thread scheduling
+ -
+ - Copyright 2012-2024 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.ThreadScheduler (
+	Seconds(..),
+	Microseconds,
+	runEvery,
+	threadDelaySeconds,
+	waitForTermination,
+	oneSecond,
+	unboundDelay,
+) where
+
+import Control.Monad
+import qualified Control.Concurrent.Thread.Delay as Unbounded
+#ifndef mingw32_HOST_OS
+import Control.Concurrent
+import Control.Monad.IfElse
+import System.Posix.IO
+#endif
+#ifndef mingw32_HOST_OS
+import System.Posix.Signals
+import System.Posix.Terminal
+#endif
+
+newtype Seconds = Seconds { fromSeconds :: Int }
+	deriving (Eq, Ord, Show)
+
+type Microseconds = Integer
+
+{- Runs an action repeatedly forever, sleeping at least the specified number
+ - of seconds in between. -}
+runEvery :: Seconds -> IO a -> IO a
+runEvery n a = forever $ do
+	threadDelaySeconds n
+	a
+
+threadDelaySeconds :: Seconds -> IO ()
+threadDelaySeconds (Seconds n) = unboundDelay (fromIntegral n * oneSecond)
+
+{- Like threadDelay, but not bounded by an Int. -}
+unboundDelay :: Microseconds -> IO ()
+unboundDelay = Unbounded.delay
+
+{- Pauses the main thread, letting children run until program termination. -}
+waitForTermination :: IO ()
+waitForTermination = do
+#ifdef mingw32_HOST_OS
+	forever $ threadDelaySeconds (Seconds 6000)
+#else
+	lock <- newEmptyMVar
+	let check sig = void $
+		installHandler sig (CatchOnce $ putMVar lock ()) Nothing
+	check softwareTermination
+	whenM (queryTerminal stdInput) $
+		check keyboardSignal
+	takeMVar lock
+#endif
+
+oneSecond :: Microseconds
+oneSecond = 1000000
diff --git a/Utility/TimeStamp.hs b/Utility/TimeStamp.hs
new file mode 100644
index 0000000000..3cc4d8d245
--- /dev/null
+++ b/Utility/TimeStamp.hs
@@ -0,0 +1,72 @@
+{- timestamp parsing and formatting
+ -
+ - Copyright 2015-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.TimeStamp (
+	parserPOSIXTime,
+	parsePOSIXTime,
+	formatPOSIXTime,
+	truncateResolution,
+) where
+
+import Utility.Data
+
+import Data.Time.Clock.POSIX
+import Data.Time
+import Data.Ratio
+import Control.Applicative
+import qualified Data.ByteString as B
+import qualified Data.ByteString.Char8 as B8
+import qualified Data.Attoparsec.ByteString as A
+import Data.Attoparsec.ByteString.Char8 (char, decimal, signed, isDigit_w8)
+
+{- Parses how POSIXTime shows itself: "1431286201.113452s"
+ - (The "s" is included for historical reasons and is optional.)
+ - Also handles the format with no decimal seconds. -}
+parserPOSIXTime :: A.Parser POSIXTime
+parserPOSIXTime = mkPOSIXTime
+	<$> signed decimal
+	<*> (declen <|> pure (0, 0))
+	<* optional (char 's')
+  where
+	declen :: A.Parser (Integer, Int)
+	declen = do
+		_ <- char '.'
+		b <- A.takeWhile isDigit_w8
+		let len = B.length b
+		d <- either fail pure $
+			A.parseOnly (decimal <* A.endOfInput) b
+		return (d, len)
+
+parsePOSIXTime :: String -> Maybe POSIXTime
+parsePOSIXTime s = eitherToMaybe $ 
+	A.parseOnly (parserPOSIXTime <* A.endOfInput) (B8.pack s)
+
+{- This implementation allows for higher precision in a POSIXTime than
+ - supported by the system's Double, and avoids the complications of
+ - floating point. -}
+mkPOSIXTime :: Integer -> (Integer, Int) -> POSIXTime
+mkPOSIXTime n (d, dlen)
+	| n < 0 = fromIntegral n - fromRational r
+	| otherwise = fromIntegral n + fromRational r
+  where
+	r = d % (10 ^ dlen)
+
+formatPOSIXTime :: String -> POSIXTime -> String
+formatPOSIXTime fmt t = formatTime defaultTimeLocale fmt (posixSecondsToUTCTime t)
+
+{- Truncate the resolution to the specified number of decimal places. -}
+truncateResolution :: Int -> POSIXTime -> POSIXTime
+#if MIN_VERSION_time(1,9,1)
+truncateResolution n t = secondsToNominalDiffTime $
+	fromIntegral ((truncate (nominalDiffTimeToSeconds t * d)) :: Integer) / d
+  where
+	d = 10 ^ n
+#else
+truncateResolution _ t = t
+#endif
diff --git a/Utility/Tmp.hs b/Utility/Tmp.hs
new file mode 100644
index 0000000000..a23a2a37f5
--- /dev/null
+++ b/Utility/Tmp.hs
@@ -0,0 +1,116 @@
+{- Temporary files.
+ -
+ - Copyright 2010-2020 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Tmp (
+	Template,
+	viaTmp,
+	withTmpFile,
+	withTmpFileIn,
+	relatedTemplate,
+	openTmpFileIn,
+) where
+
+import System.IO
+import System.FilePath
+import System.Directory
+import Control.Monad.IO.Class
+import System.IO.Error
+
+import Utility.Exception
+import Utility.FileSystemEncoding
+import Utility.FileMode
+import qualified Utility.RawFilePath as R
+
+type Template = String
+
+{- This is the same as openTempFile, except when there is an
+ - error, it displays the template as well as the directory,
+ - to help identify what call was responsible.
+ -}
+openTmpFileIn :: FilePath -> String -> IO (FilePath, Handle)
+openTmpFileIn dir template = openTempFile dir template
+	`catchIO` decoraterrror
+  where
+	decoraterrror e = throwM $
+		let loc = ioeGetLocation e ++ " template " ++ template
+		in annotateIOError e loc Nothing Nothing
+
+{- Runs an action like writeFile, writing to a temp file first and
+ - then moving it into place. The temp file is stored in the same
+ - directory as the final file to avoid cross-device renames.
+ -
+ - While this uses a temp file, the file will end up with the same
+ - mode as it would when using writeFile, unless the writer action changes
+ - it.
+ -}
+viaTmp :: (MonadMask m, MonadIO m) => (FilePath -> v -> m ()) -> FilePath -> v -> m ()
+viaTmp a file content = bracketIO setup cleanup use
+  where
+	(dir, base) = splitFileName file
+	template = relatedTemplate (base ++ ".tmp")
+	setup = do
+		createDirectoryIfMissing True dir
+		openTmpFileIn dir template
+	cleanup (tmpfile, h) = do
+		_ <- tryIO $ hClose h
+		tryIO $ removeFile tmpfile
+	use (tmpfile, h) = do
+		let tmpfile' = toRawFilePath tmpfile
+		-- Make mode the same as if the file were created usually,
+		-- not as a temp file. (This may fail on some filesystems
+		-- that don't support file modes well, so ignore
+		-- exceptions.)
+		_ <- liftIO $ tryIO $ R.setFileMode tmpfile' =<< defaultFileMode
+		liftIO $ hClose h
+		a tmpfile content
+		liftIO $ R.rename tmpfile' (toRawFilePath file)
+
+{- Runs an action with a tmp file located in the system's tmp directory
+ - (or in "." if there is none) then removes the file. -}
+withTmpFile :: (MonadIO m, MonadMask m) => Template -> (FilePath -> Handle -> m a) -> m a
+withTmpFile template a = do
+	tmpdir <- liftIO $ catchDefaultIO "." getTemporaryDirectory
+	withTmpFileIn tmpdir template a
+
+{- Runs an action with a tmp file located in the specified directory,
+ - then removes the file.
+ -
+ - Note that the tmp file will have a file mode that only allows the
+ - current user to access it.
+ -}
+withTmpFileIn :: (MonadIO m, MonadMask m) => FilePath -> Template -> (FilePath -> Handle -> m a) -> m a
+withTmpFileIn tmpdir template a = bracket create remove use
+  where
+	create = liftIO $ openTmpFileIn tmpdir template
+	remove (name, h) = liftIO $ do
+		hClose h
+		catchBoolIO (removeFile name >> return True)
+	use (name, h) = a name h
+
+{- It's not safe to use a FilePath of an existing file as the template
+ - for openTempFile, because if the FilePath is really long, the tmpfile
+ - will be longer, and may exceed the maximum filename length.
+ -
+ - This generates a template that is never too long.
+ - (Well, it allocates 20 characters for use in making a unique temp file,
+ - anyway, which is enough for the current implementation and any
+ - likely implementation.)
+ -}
+relatedTemplate :: FilePath -> FilePath
+relatedTemplate f
+	| len > 20 = 
+		{- Some filesystems like FAT have issues with filenames
+		 - ending in ".", so avoid truncating a filename to end
+		 - that way. -}
+		reverse $ dropWhile (== '.') $ reverse $
+			truncateFilePath (len - 20) f
+	| otherwise = f
+  where
+	len = length f
diff --git a/Utility/Tmp/Dir.hs b/Utility/Tmp/Dir.hs
new file mode 100644
index 0000000000..904b65a526
--- /dev/null
+++ b/Utility/Tmp/Dir.hs
@@ -0,0 +1,72 @@
+{- Temporary directories
+ -
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.Tmp.Dir (
+	withTmpDir,
+	withTmpDirIn,
+) where
+
+import Control.Monad.IfElse
+import System.FilePath
+import System.Directory
+import Control.Monad.IO.Class
+#ifndef mingw32_HOST_OS
+import System.Posix.Temp (mkdtemp)
+#endif
+
+import Utility.Exception
+import Utility.Tmp (Template)
+
+{- Runs an action with a tmp directory located within the system's tmp
+ - directory (or within "." if there is none), then removes the tmp
+ - directory and all its contents. -}
+withTmpDir :: (MonadMask m, MonadIO m) => Template -> (FilePath -> m a) -> m a
+withTmpDir template a = do
+	topleveltmpdir <- liftIO $ catchDefaultIO "." getTemporaryDirectory
+#ifndef mingw32_HOST_OS
+	-- Use mkdtemp to create a temp directory securely in /tmp.
+	bracket
+		(liftIO $ mkdtemp $ topleveltmpdir </> template)
+		removeTmpDir
+		a
+#else
+	withTmpDirIn topleveltmpdir template a
+#endif
+
+{- Runs an action with a tmp directory located within a specified directory,
+ - then removes the tmp directory and all its contents. -}
+withTmpDirIn :: (MonadMask m, MonadIO m) => FilePath -> Template -> (FilePath -> m a) -> m a
+withTmpDirIn tmpdir template = bracketIO create removeTmpDir
+  where
+	create = do
+		createDirectoryIfMissing True tmpdir
+		makenewdir (tmpdir </> template) (0 :: Int)
+	makenewdir t n = do
+		let dir = t ++ "." ++ show n
+		catchIOErrorType AlreadyExists (const $ makenewdir t $ n + 1) $ do
+			createDirectory dir
+			return dir
+
+{- Deletes the entire contents of the the temporary directory, if it
+ - exists. -}
+removeTmpDir :: MonadIO m => FilePath -> m ()
+removeTmpDir tmpdir = liftIO $ whenM (doesDirectoryExist tmpdir) $ do
+#if mingw32_HOST_OS
+	-- Windows will often refuse to delete a file
+	-- after a process has just written to it and exited.
+	-- Because it's crap, presumably. So, ignore failure
+	-- to delete the temp directory.
+	_ <- tryIO $ go tmpdir
+	return ()
+#else
+	go tmpdir
+#endif
+  where
+	go = removeDirectoryRecursive
diff --git a/Utility/Tor.hs b/Utility/Tor.hs
new file mode 100644
index 0000000000..9147e9b049
--- /dev/null
+++ b/Utility/Tor.hs
@@ -0,0 +1,196 @@
+{- tor interface
+ -
+ - Copyright 2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.Tor (
+	OnionPort,
+	OnionAddress(..),
+	OnionSocket,
+	UniqueIdent,
+	AppName,
+	connectHiddenService,
+	addHiddenService,
+	getHiddenServiceSocketFile,
+	torIsInstalled,
+) where
+
+import Common
+import Utility.ThreadScheduler
+import Utility.FileMode
+import Utility.RawFilePath (setOwnerAndGroup)
+
+import System.PosixCompat.Types
+import System.PosixCompat.Files (ownerReadMode, ownerWriteMode, ownerExecuteMode)
+import Data.Char
+import Network.Socket
+import Network.Socks5
+import qualified Data.ByteString.UTF8 as BU8
+import qualified System.Random as R
+
+type OnionPort = Int
+
+newtype OnionAddress = OnionAddress String
+	deriving (Show, Eq)
+
+type OnionSocket = FilePath
+
+-- | A unique identifier for a hidden service.
+type UniqueIdent = String
+
+-- | Name of application that is providing a hidden service.
+type AppName = String
+
+connectHiddenService :: OnionAddress -> OnionPort -> IO Socket
+connectHiddenService (OnionAddress address) port = do
+	(s, _) <- socksConnect torsockconf socksaddr
+	return s
+  where
+	torsocksport = 9050
+#if MIN_VERSION_socks(0,6,0)
+	torsockconf = defaultSocksConf $ SockAddrInet torsocksport $
+		tupleToHostAddress (127,0,0,1)
+#else
+	torsockconf = defaultSocksConf "127.0.0.1" torsocksport
+#endif
+	socksdomain = SocksAddrDomainName (BU8.fromString address)
+	socksaddr = SocksAddress socksdomain (fromIntegral port)
+
+-- | Adds a hidden service connecting to localhost, using some kind
+-- of unique identifier.
+--
+-- This will only work if run as root, and tor has to already be running.
+--
+-- Picks a random high port number for the hidden service that is not
+-- used by any other hidden service. Returns the hidden service's
+-- onion address, port, and the unix socket file to use.
+-- 
+-- If there is already a hidden service for the specified unique
+-- identifier, returns its information without making any changes.
+addHiddenService :: AppName -> UserID -> UniqueIdent -> IO (OnionAddress, OnionPort)
+addHiddenService appname uid ident = do
+	prepHiddenServiceSocketDir appname uid ident
+	ls <- lines <$> (readFile =<< findTorrc)
+	let portssocks = mapMaybe (parseportsock . separate isSpace) ls
+	case filter (\(_, s) -> s == sockfile) portssocks of
+		((p, _s):_) -> waithiddenservice 1 p
+		_ -> do
+			highports <- R.getStdRandom mkhighports
+			let newport = Prelude.head $
+				filter (`notElem` map fst portssocks) highports
+			torrc <- findTorrc
+			writeFile torrc $ unlines $
+				ls ++
+				[ ""
+				, "HiddenServiceDir " ++ hiddenServiceDir appname uid ident
+				, "HiddenServicePort " ++ show newport ++ 
+					" unix:" ++ sockfile
+				]
+			-- Reload tor, so it will see the new hidden
+			-- service and generate the hostname file for it.
+			reloaded <- anyM (uncurry boolSystem)
+				[ ("systemctl", [Param "reload", Param "tor"])
+				, ("service", [Param "tor", Param "reload"])
+				]
+			unless reloaded $
+				giveup "failed to reload tor, perhaps the tor service is not running"
+			waithiddenservice 120 newport
+  where
+	parseportsock ("HiddenServicePort", l) = do
+		p <- readish $ takeWhile (not . isSpace) l
+		return (p, drop 1 (dropWhile (/= ':') l))
+	parseportsock _ = Nothing
+	
+	sockfile = hiddenServiceSocketFile appname uid ident
+
+	-- An infinite random list of high ports.
+	mkhighports g = 
+		let (g1, g2) = R.split g
+		in (R.randomRs (1025, 65534) g1, g2)
+
+	waithiddenservice :: Int -> OnionPort -> IO (OnionAddress, OnionPort)
+	waithiddenservice 0 _ = giveup "tor failed to create hidden service, perhaps the tor service is not running"
+	waithiddenservice n p = do
+		v <- tryIO $ readFile $ hiddenServiceHostnameFile appname uid ident
+		case v of
+			Right s | ".onion\n" `isSuffixOf` s ->
+				return (OnionAddress (takeWhile (/= '\n') s), p)
+			_ -> do
+				threadDelaySeconds (Seconds 1)
+				waithiddenservice (n-1) p
+
+-- | A hidden service directory to use.
+--
+-- Has to be inside the torLibDir so tor can create it.
+--
+-- Has to end with "uid_ident" so getHiddenServiceSocketFile can find it.
+hiddenServiceDir :: AppName -> UserID -> UniqueIdent -> FilePath
+hiddenServiceDir appname uid ident = torLibDir </> appname ++ "_" ++ show uid ++ "_" ++ ident
+
+hiddenServiceHostnameFile :: AppName -> UserID -> UniqueIdent -> FilePath
+hiddenServiceHostnameFile appname uid ident = hiddenServiceDir appname uid ident </> "hostname"
+
+-- | Location of the socket for a hidden service.
+--
+-- This has to be a location that tor can read from, and that the user
+-- can write to. Since torLibDir is locked down, it can't go in there.
+--
+-- Note that some unix systems limit socket paths to 92 bytes long.
+-- That should not be a problem if the UniqueIdent is around the length of
+-- a UUID, and the AppName is short.
+hiddenServiceSocketFile :: AppName -> UserID -> UniqueIdent -> FilePath
+hiddenServiceSocketFile appname uid ident = varLibDir </> appname </> show uid ++ "_" ++ ident </> "s"
+
+-- | Parse torrc, to get the socket file used for a hidden service with
+-- the specified UniqueIdent.
+getHiddenServiceSocketFile :: AppName -> UserID -> UniqueIdent -> IO (Maybe FilePath)
+getHiddenServiceSocketFile _appname uid ident = 
+	parse . map words . lines <$> catchDefaultIO "" (readFile =<< findTorrc)
+  where
+	parse [] = Nothing
+	parse (("HiddenServiceDir":hsdir:[]):("HiddenServicePort":_hsport:hsaddr:[]):rest)
+		| "unix:" `isPrefixOf` hsaddr && hasident hsdir =
+			Just (drop (length "unix:") hsaddr)
+		| otherwise = parse rest
+	parse (_:rest) = parse rest
+
+	-- Don't look for AppName in the hsdir, because it didn't used to
+	-- be included.
+	hasident hsdir = (show uid ++ "_" ++ ident) `isSuffixOf` takeFileName hsdir
+
+-- | Sets up the directory for the socketFile, with appropriate
+-- permissions. Must run as root.
+prepHiddenServiceSocketDir :: AppName -> UserID -> UniqueIdent -> IO ()
+prepHiddenServiceSocketDir appname uid ident = do
+	createDirectoryIfMissing True d
+	setOwnerAndGroup (toRawFilePath d) uid (-1)
+	modifyFileMode (toRawFilePath d) $
+		addModes [ownerReadMode, ownerExecuteMode, ownerWriteMode]
+  where
+	d = takeDirectory $ hiddenServiceSocketFile appname uid ident
+
+-- | Finds the system's torrc file, in any of the typical locations of it.
+-- Returns the first found. If there is no system torrc file, defaults to
+-- /etc/tor/torrc.
+findTorrc :: IO FilePath
+findTorrc = fromMaybe "/etc/tor/torrc" <$> firstM doesFileExist
+	-- Debian
+	[ "/etc/tor/torrc"
+	-- Some systems put it here instead.
+	, "/etc/torrc"
+	-- Default when installed from source
+	, "/usr/local/etc/tor/torrc" 
+	]
+
+torLibDir :: FilePath
+torLibDir = "/var/lib/tor"
+
+varLibDir :: FilePath
+varLibDir = "/var/lib"
+
+torIsInstalled :: IO Bool
+torIsInstalled = inSearchPath "tor"
diff --git a/Utility/Touch.hs b/Utility/Touch.hs
new file mode 100644
index 0000000000..8831f306a3
--- /dev/null
+++ b/Utility/Touch.hs
@@ -0,0 +1,45 @@
+{- Portability shim for touching a file.
+ -
+ - Copyright 2011-2018 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+
+module Utility.Touch (
+	touchBoth,
+	touch
+) where
+
+#if ! defined(mingw32_HOST_OS)
+
+import System.FilePath.ByteString (RawFilePath)
+import System.Posix.Files.ByteString
+import Data.Time.Clock.POSIX
+
+{- Changes the access and modification times of an existing file.
+   Can follow symlinks, or not. -}
+touchBoth :: RawFilePath -> POSIXTime -> POSIXTime -> Bool -> IO ()
+touchBoth file atime mtime follow
+	| follow = setFileTimesHiRes file atime mtime
+	| otherwise = setSymbolicLinkTimesHiRes file atime mtime
+
+{- Changes the access and modification times of an existing file
+ - to the same value. Can follow symlinks, or not. -}
+touch :: RawFilePath -> POSIXTime -> Bool -> IO ()
+touch file mtime = touchBoth file mtime mtime
+
+#else
+
+import Data.Time.Clock.POSIX
+import Utility.RawFilePath
+
+{- Noop for Windows -}
+touchBoth :: RawFilePath -> POSIXTime -> POSIXTime -> Bool -> IO ()
+touchBoth _ _ _ _ = return ()
+
+touch :: RawFilePath -> POSIXTime -> Bool -> IO ()
+touch _ _ _ = return ()
+
+#endif
diff --git a/Utility/Tuple.hs b/Utility/Tuple.hs
new file mode 100644
index 0000000000..9638bcc0d9
--- /dev/null
+++ b/Utility/Tuple.hs
@@ -0,0 +1,21 @@
+{- tuple utility functions
+ -
+ - Copyright 2017 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.Tuple (
+	fst3,
+	snd3,
+	thd3,
+) where
+
+fst3 :: (a,b,c) -> a
+fst3 (a,_,_) = a
+
+snd3 :: (a,b,c) -> b
+snd3 (_,b,_) = b
+
+thd3 :: (a,b,c) -> c
+thd3 (_,_,c) = c
diff --git a/Utility/Url.hs b/Utility/Url.hs
new file mode 100644
index 0000000000..dbe4647527
--- /dev/null
+++ b/Utility/Url.hs
@@ -0,0 +1,743 @@
+{- Url downloading.
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE FlexibleContexts #-}
+{-# LANGUAGE BangPatterns #-}
+
+module Utility.Url (
+	newManager,
+	URLString,
+	UserAgent,
+	Scheme,
+	mkScheme,
+	allowedScheme,
+	UrlDownloader(..),
+	NonHttpUrlDownloader(..),
+	UrlOptions(..),
+	defUrlOptions,
+	mkUrlOptions,
+	check,
+	checkBoth,
+	exists,
+	UrlInfo(..),
+	getUrlInfo,
+	assumeUrlExists,
+	download,
+	downloadConduit,
+	sinkResponseFile,
+	downloadPartial,
+	matchStatusCodeException,
+	matchHttpExceptionContent,
+	BasicAuth(..),
+	GetBasicAuth,
+	noBasicAuth,
+	applyBasicAuth',
+	extractFromResourceT,
+	conduitUrlSchemes,
+) where
+
+import Common
+import Utility.Debug
+import Utility.Metered
+import Network.HTTP.Client.Restricted
+import Utility.IPAddress
+import qualified Utility.RawFilePath as R
+import Utility.Hash (IncrementalVerifier(..))
+import Utility.Url.Parse
+
+import Network.URI
+import Network.HTTP.Types
+import qualified Data.CaseInsensitive as CI
+import qualified Data.ByteString as B
+import qualified Data.ByteString.UTF8 as B8
+import qualified Data.ByteString.Lazy as L
+import qualified Data.Set as S
+import Control.Exception (throwIO, evaluate)
+import Control.Monad.Trans.Resource
+import Control.Monad.IO.Class (MonadIO)
+import Control.DeepSeq
+import Network.HTTP.Conduit
+import Network.HTTP.Client
+import Network.HTTP.Simple (getResponseHeader)
+import Network.Socket
+import Network.BSD (getProtocolNumber)
+import Data.Either
+import Data.Conduit
+import Text.Read
+
+type URLString = String
+
+type Headers = [String]
+
+type UserAgent = String
+
+newtype Scheme = Scheme (CI.CI String)
+	deriving (Eq, Ord)
+
+mkScheme :: String -> Scheme
+mkScheme = Scheme . CI.mk
+
+fromScheme :: Scheme -> String
+fromScheme (Scheme s) = CI.original s
+
+data UrlOptions = UrlOptions
+	{ userAgent :: Maybe UserAgent
+	, reqHeaders :: Headers
+	, urlDownloader :: UrlDownloader
+	, applyRequest :: Request -> Request
+	, httpManager :: Manager
+	, allowedSchemes :: S.Set Scheme
+	, disallowedSchemeMessage :: Maybe (URI -> String)
+	, getBasicAuth :: GetBasicAuth
+	}
+
+data UrlDownloader
+	= DownloadWithConduit NonHttpUrlDownloader
+	| DownloadWithCurl [CommandParam]
+
+data NonHttpUrlDownloader
+	= DownloadWithCurlRestricted Restriction
+
+defUrlOptions :: IO UrlOptions
+defUrlOptions = UrlOptions
+	<$> pure Nothing
+	<*> pure []
+	<*> pure (DownloadWithConduit (DownloadWithCurlRestricted mempty))
+	<*> pure id
+	<*> newManager tlsManagerSettings
+	<*> pure conduitUrlSchemes
+	<*> pure Nothing
+	<*> pure noBasicAuth
+
+conduitUrlSchemes :: S.Set Scheme
+conduitUrlSchemes = S.fromList $ map mkScheme ["http", "https", "ftp"]
+
+mkUrlOptions :: Maybe UserAgent -> Headers -> UrlDownloader -> Manager -> S.Set Scheme -> Maybe (URI -> String) -> GetBasicAuth -> UrlOptions
+mkUrlOptions defuseragent reqheaders urldownloader =
+	UrlOptions useragent reqheaders urldownloader applyrequest
+  where
+	applyrequest = \r -> r { requestHeaders = requestHeaders r ++ addedheaders }
+	addedheaders = uaheader ++ otherheaders
+	useragent = maybe defuseragent (Just . B8.toString . snd)
+		(headMaybe uafromheaders)
+	uaheader = case useragent of
+		Nothing -> []
+		Just ua -> [(hUserAgent, B8.fromString ua)]
+	(uafromheaders, otherheaders) = partition (\(h, _) -> h == hUserAgent)
+		(map toheader reqheaders)
+	toheader s =
+		let (h, v) = separate (== ':') s
+		    h' = CI.mk (B8.fromString h)
+		in case v of
+			(' ':v') -> (h', B8.fromString v')
+			_ -> (h', B8.fromString v)
+
+curlParams :: UrlOptions -> [CommandParam] -> [CommandParam]
+curlParams uo ps = ps ++ uaparams ++ headerparams ++ addedparams ++ schemeparams
+  where
+	uaparams = case userAgent uo of
+		Nothing -> []
+		Just ua -> [Param "--user-agent", Param ua]
+	headerparams = concatMap (\h -> [Param "-H", Param h]) (reqHeaders uo)
+	addedparams = case urlDownloader uo of
+		DownloadWithConduit _ -> []
+		DownloadWithCurl l -> l
+	schemeparams =
+		[ Param "--proto"
+		, Param $ intercalate "," ("-all" : schemelist)
+		]
+	schemelist = map fromScheme $ S.toList $ allowedSchemes uo
+
+checkPolicy :: UrlOptions -> URI -> IO (Either String a) -> IO (Either String a)
+checkPolicy uo u a
+	| allowedScheme uo u = a
+	| otherwise = return $ Left $ case disallowedSchemeMessage uo of
+		Nothing -> "Configuration does not allow accessing" ++ show u
+		Just f -> f u
+
+unsupportedUrlScheme :: URI -> String
+unsupportedUrlScheme u = "Unsupported url scheme " ++ show u
+
+allowedScheme :: UrlOptions -> URI -> Bool
+allowedScheme uo u = uscheme `S.member` allowedSchemes uo
+  where
+	uscheme = mkScheme $ takeWhile (/=':') (uriScheme u)
+
+{- Checks that an url exists and could be successfully downloaded,
+ - also checking that its size, if available, matches a specified size.
+ -
+ - The Left error is returned if policy or the restricted http manager
+ - does not allow accessing the url or the url scheme is not supported.
+ -}
+checkBoth :: URLString -> Maybe Integer -> UrlOptions -> IO (Either String Bool)
+checkBoth url expected_size uo = fmap go <$> check url expected_size uo
+  where
+	go v = fst v && snd v
+
+check :: URLString -> Maybe Integer -> UrlOptions -> IO (Either String (Bool, Bool))
+check url expected_size uo = fmap go <$> getUrlInfo url uo
+  where
+	go (UrlInfo False _ _) = (False, False)
+	go (UrlInfo True Nothing _) = (True, True)
+	go (UrlInfo True s _) = case expected_size of
+		Just _ -> (True, expected_size == s)
+		Nothing -> (True, True)
+
+exists :: URLString -> UrlOptions -> IO (Either String Bool)
+exists url uo = fmap urlExists <$> getUrlInfo url uo
+
+data UrlInfo = UrlInfo
+	{ urlExists :: Bool
+	, urlSize :: Maybe Integer
+	, urlSuggestedFile :: Maybe FilePath
+	}
+	deriving (Show)
+
+assumeUrlExists :: UrlInfo
+assumeUrlExists = UrlInfo True Nothing Nothing
+
+{- Checks that an url exists and could be successfully downloaded,
+ - also returning its size and suggested filename if available.
+ -
+ - The Left error is returned if policy or the restricted http manages
+ - does not allow accessing the url or the url scheme is not supported.
+ -}
+getUrlInfo :: URLString -> UrlOptions -> IO (Either String UrlInfo)
+getUrlInfo url uo = case parseURIRelaxed url of
+	Just u -> checkPolicy uo u (go u)
+	Nothing -> return (Right dne)
+   where
+	go :: URI -> IO (Either String UrlInfo)
+	go u = case (urlDownloader uo, parseRequestRelaxed u) of
+		(DownloadWithConduit (DownloadWithCurlRestricted r), Just req) ->
+			existsconduit r req
+		(DownloadWithConduit (DownloadWithCurlRestricted r), Nothing)
+			| isfileurl u -> Right <$> existsfile u
+			| isftpurl u -> (Right <$> existscurlrestricted r u url ftpport)
+				`catchNonAsync` (const $ return $ Right dne)
+			| otherwise -> return $ Left $ unsupportedUrlScheme u
+		(DownloadWithCurl _, _) 
+			| isfileurl u -> Right <$> existsfile u
+			| otherwise -> Right <$> existscurl u (basecurlparams url)
+	
+	dne = UrlInfo False Nothing Nothing
+	found sz f = return $ UrlInfo True sz f
+
+	isfileurl u = uriScheme u == "file:"
+	isftpurl u = uriScheme u == "ftp:"
+
+	ftpport = 21
+
+	basecurlparams u = curlParams uo $
+		[ Param "-s"
+		, Param "--head"
+		, Param "-L", Param u
+		, Param "-w", Param "%{http_code}"
+		]
+
+	extractlencurl s = case lastMaybe $ filter ("Content-Length:" `isPrefixOf`) (lines s) of
+		Just l -> case lastMaybe $ words l of
+			Just sz -> readish sz
+			_ -> Nothing
+		_ -> Nothing
+	
+	extractlen = readish . B8.toString
+		<=< lookup hContentLength . responseHeaders
+
+	extractfilename = contentDispositionFilename . B8.toString
+		<=< lookup hContentDisposition . responseHeaders
+
+	existsconduit r req =
+		let a = catchcrossprotoredir r (existsconduit' req uo)
+		in catchJust matchconnectionrestricted a retconnectionrestricted
+	
+	matchconnectionrestricted he@(HttpExceptionRequest _ (InternalException ie)) =
+		case fromException ie of
+			Just (ConnectionRestricted _why) -> Just he
+			_ -> Nothing
+	matchconnectionrestricted _ = Nothing
+
+	retconnectionrestricted he@(HttpExceptionRequest _ (InternalException ie)) =
+		case fromException ie of
+			Just (ConnectionRestricted why) -> return (Left why)
+			_ -> throwM he
+	retconnectionrestricted he = throwM he
+
+	existsconduit' req uo' = do
+		let req' = headRequest (applyRequest uo req)
+		debug "Utility.Url" (show req')
+		join $ runResourceT $ do
+			resp <- http req' (httpManager uo)
+			if responseStatus resp == ok200
+				then do
+					len <- extractFromResourceT (extractlen resp)
+					fn <- extractFromResourceT (extractfilename resp)
+					return $ found len fn
+				else if responseStatus resp == unauthorized401
+					then return $ getBasicAuth uo' (show (getUri req)) >>= \case
+						Nothing -> return dne
+						Just (ba, signalsuccess) -> do
+							ui <- existsconduit'
+								(applyBasicAuth' ba req)							
+								(uo' { getBasicAuth = noBasicAuth })
+							signalsuccess (urlExists ui)
+							return ui
+					else return $ return dne
+
+	existscurl u curlparams = do
+		output <- catchDefaultIO "" $
+			readProcess "curl" $ toCommand curlparams
+		let len = extractlencurl output
+		let good = found len Nothing
+		let isftp = or
+			[ "ftp" `isInfixOf` uriScheme u
+			-- Check to see if http redirected to ftp.
+			, "Location: ftp://" `isInfixOf` output
+			]
+		case lastMaybe (lines output) of
+			Just ('2':_:_) -> good
+			-- don't try to parse ftp status codes; if curl
+			-- got a length, it's good
+			_ | isftp && isJust len -> good
+			_ -> return dne
+	
+	existscurlrestricted r u url' defport = existscurl u 
+		=<< curlRestrictedParams r u defport (basecurlparams url')
+
+	existsfile u = do
+		let f = toRawFilePath (unEscapeString (uriPath u))
+		s <- catchMaybeIO $ R.getSymbolicLinkStatus f
+		case s of
+			Just stat -> do
+				sz <- getFileSize' f stat
+				found (Just sz) Nothing
+			Nothing -> return dne
+
+	-- When http server redirects to a protocol which conduit does not
+	-- support, it will throw a StatusCodeException with found302
+	-- and a Response with the redir Location.
+	catchcrossprotoredir r a = 
+		catchJust (matchStatusCodeException (== found302))
+			(Right <$> a)
+			(followredir r)
+	
+	followredir r (HttpExceptionRequest _ (StatusCodeException resp _)) = 
+		case headMaybe $ map decodeBS $ getResponseHeader hLocation resp of
+			Just url' -> case parseURIRelaxed url' of
+				-- only follow http to ftp redirects;
+				-- http to file redirect would not be secure,
+				-- and http-conduit follows http to http.
+				Just u' | isftpurl u' ->
+					checkPolicy uo u' $ Right <$> 
+						existscurlrestricted r u' url' ftpport
+				_ -> return (Right dne)
+			Nothing -> return (Right dne)
+	followredir _ _ = return (Right dne)
+
+-- Parse eg: attachment; filename="fname.ext"
+-- per RFC 2616
+contentDispositionFilename :: String -> Maybe FilePath
+contentDispositionFilename s
+	| "attachment; filename=\"" `isPrefixOf` s && "\"" `isSuffixOf` s =
+		Just $ dropFromEnd 1 $ drop 1 $ dropWhile (/= '"') s
+	| otherwise = Nothing
+
+headRequest :: Request -> Request
+headRequest r = r
+	{ method = methodHead
+	-- remove default Accept-Encoding header, to get actual,
+	-- not gzip compressed size.
+	, requestHeaders = (hAcceptEncoding, B.empty) :
+		filter (\(h, _) -> h /= hAcceptEncoding)
+		(requestHeaders r)
+	}
+
+{- Download a perhaps large file, with auto-resume of incomplete downloads.
+ -
+ - When the download fails, returns an error message.
+ -}
+download :: MeterUpdate -> Maybe IncrementalVerifier -> URLString -> FilePath -> UrlOptions -> IO (Either String ())
+download = download' False
+
+download' :: Bool -> MeterUpdate -> Maybe IncrementalVerifier -> URLString -> FilePath -> UrlOptions -> IO (Either String ())
+download' nocurlerror meterupdate iv url file uo =
+	catchJust matchHttpException go showhttpexception
+		`catchNonAsync` (dlfailed . show)
+  where
+	go = case parseURIRelaxed url of
+		Just u -> checkPolicy uo u $
+			case (urlDownloader uo, parseRequestRelaxed u) of
+				(DownloadWithConduit (DownloadWithCurlRestricted r), Just req) -> catchJust
+					(matchStatusCodeException (== found302))
+					(downloadConduit meterupdate iv req file uo >> return (Right ()))
+					(followredir r)
+				(DownloadWithConduit (DownloadWithCurlRestricted r), Nothing)
+					| isfileurl u -> downloadfile u
+					| isftpurl u -> downloadcurlrestricted r u url ftpport
+					| otherwise -> dlfailed $ unsupportedUrlScheme u
+				(DownloadWithCurl _, _)
+					| isfileurl u -> downloadfile u
+					| otherwise -> downloadcurl url basecurlparams
+		Nothing -> do
+			liftIO $ debug "Utility.Url" url
+			dlfailed "invalid url"
+	
+	isfileurl u = uriScheme u == "file:"
+	isftpurl u = uriScheme u == "ftp:"
+
+	ftpport = 21
+
+	showhttpexception he = dlfailed $ case he of
+		HttpExceptionRequest _ (StatusCodeException r _) ->
+			B8.toString $ statusMessage $ responseStatus r
+		HttpExceptionRequest _ (InternalException ie) -> 
+			case fromException ie of
+				Nothing -> show ie
+				Just (ConnectionRestricted why) -> why
+		HttpExceptionRequest _ other -> show other
+		_ -> show he
+	
+	dlfailed msg = do
+		noverification
+		return $ Left $ "download failed: " ++ msg
+
+	basecurlparams = curlParams uo
+		[ if nocurlerror
+			then Param "-S"
+			else Param "-sS"
+		, Param "-f"
+		, Param "-L"
+		, Param "-C", Param "-"
+		]
+
+	downloadcurl rawurl curlparams = do
+		noverification
+		-- curl does not create destination file
+		-- if the url happens to be empty, so pre-create.
+		unlessM (doesFileExist file) $
+			writeFile file ""
+		ifM (boolSystem "curl" (curlparams ++ [Param "-o", File file, File rawurl]))
+			( return $ Right ()
+			, return $ Left "download failed"
+			)
+
+	downloadcurlrestricted r u rawurl defport =
+		downloadcurl rawurl =<< curlRestrictedParams r u defport basecurlparams
+
+	downloadfile u = do
+		noverification
+		let src = unEscapeString (uriPath u)
+		withMeteredFile src meterupdate $
+			L.writeFile file
+		return $ Right ()
+
+	-- Conduit does not support ftp, so will throw an exception on a
+	-- redirect to a ftp url; fall back to curl.
+	followredir r ex@(HttpExceptionRequest _ (StatusCodeException resp _)) = 
+		case headMaybe $ map decodeBS $ getResponseHeader hLocation resp of
+			Just url' -> case parseURIRelaxed url' of
+				Just u' | isftpurl u' ->
+					checkPolicy uo u' $
+						downloadcurlrestricted r u' url' ftpport
+				_ -> throwIO ex
+			Nothing -> throwIO ex
+	followredir _ ex = throwIO ex
+
+	noverification = maybe noop unableIncrementalVerifier iv
+
+{- Download a perhaps large file using conduit, with auto-resume
+ - of incomplete downloads.
+ -
+ - A Request can be configured to throw exceptions for non-2xx http
+ - status codes, or not. That configuration is overridden by this,
+ - and if it is unable to download, it throws an exception containing
+ - a user-visible explanation of the problem. (However, exceptions
+ - thrown for reasons other than http status codes will still be thrown
+ - as usual.)
+ -}
+downloadConduit :: MeterUpdate -> Maybe IncrementalVerifier -> Request -> FilePath -> UrlOptions -> IO ()
+downloadConduit meterupdate iv req file uo =
+	catchMaybeIO (getFileSize (toRawFilePath file)) >>= \case
+		Just sz | sz > 0 -> resumedownload sz
+		_ -> join $ runResourceT $ do
+			liftIO $ debug "Utility.Url" (show req')
+			resp <- http req' (httpManager uo)
+			if responseStatus resp == ok200
+				then do
+					store zeroBytesProcessed WriteMode resp
+					return (return ())
+				else do
+					rf <- extractFromResourceT (respfailure resp)
+					if responseStatus resp == unauthorized401
+						then return $ getBasicAuth uo (show (getUri req')) >>= \case
+							Nothing -> giveup rf
+							Just ba -> retryauthed ba
+						else return $ giveup rf
+  where
+	req' = applyRequest uo $ req
+		-- Override http-client's default decompression of gzip
+		-- compressed files. We want the unmodified file content.
+		{ requestHeaders = (hAcceptEncoding, "identity") :
+			filter ((/= hAcceptEncoding) . fst)
+				(requestHeaders req)
+		, decompress = const False
+		-- Avoid throwing exceptions non-2xx http status codes,
+		-- since we rely on parsing the Response to handle
+		-- several such codes.
+		, checkResponse = \_ _ -> return ()
+		}
+
+	-- Resume download from where a previous download was interrupted, 
+	-- when supported by the http server. The server may also opt to
+	-- send the whole file rather than resuming.
+	resumedownload sz = join $ runResourceT $ do
+		let req'' = req' { requestHeaders = resumeFromHeader sz : requestHeaders req' }
+		liftIO $ debug "Urility.Url" (show req'')
+		resp <- http req'' (httpManager uo)
+		if responseStatus resp == partialContent206
+			then do
+				store (toBytesProcessed sz) AppendMode resp
+				return (return ())
+			else if responseStatus resp == ok200
+				then do
+					store zeroBytesProcessed WriteMode resp
+					return (return ())
+				else if alreadydownloaded sz resp
+					then do
+						liftIO noverification
+						return (return ())
+					else do
+						rf <- extractFromResourceT (respfailure resp)
+						if responseStatus resp == unauthorized401
+							then return $ getBasicAuth uo (show (getUri req'')) >>= \case
+								Nothing -> giveup rf
+								Just ba -> retryauthed ba
+							else return $ giveup rf
+	
+	alreadydownloaded sz resp
+		| responseStatus resp /= requestedRangeNotSatisfiable416 = False
+		| otherwise = case lookup hContentRange (responseHeaders resp) of
+			-- This could be improved by fixing
+			-- https://github.com/aristidb/http-types/issues/87
+			Just crh -> crh == B8.fromString ("bytes */" ++ show sz)
+			-- Some http servers send no Content-Range header when
+			-- the range extends beyond the end of the file.
+			-- There is no way to distinguish between the file
+			-- being the same size on the http server, vs
+			-- it being shorter than the file we already have.
+			-- So assume we have the whole content of the file
+			-- already, the same as wget and curl do.
+			Nothing -> True
+	
+	store initialp mode resp =
+		sinkResponseFile meterupdate iv initialp file mode resp
+	
+	respfailure = B8.toString . statusMessage . responseStatus
+	
+	retryauthed (ba, signalsuccess) = do
+		r <- tryNonAsync $ downloadConduit
+			meterupdate iv
+			(applyBasicAuth' ba req)
+			file
+			(uo { getBasicAuth = noBasicAuth })
+		case r of
+			Right () -> signalsuccess True
+			Left e -> do
+				() <- signalsuccess False
+				throwM e
+	
+	noverification = maybe noop unableIncrementalVerifier iv
+	
+{- Sinks a Response's body to a file. The file can either be appended to
+ - (AppendMode), or written from the start of the response (WriteMode).
+ - Updates the meter and incremental verifier as data is received,
+ - when not appending.
+ -
+ - Note that the responseStatus is not checked by this function.
+ -}
+sinkResponseFile
+	:: MonadResource m
+	=> MeterUpdate
+	-> Maybe IncrementalVerifier
+	-> BytesProcessed
+	-> FilePath
+	-> IOMode
+	-> Response (ConduitM () B8.ByteString m ())
+	-> m ()
+sinkResponseFile meterupdate iv initialp file mode resp = do
+	ui <- case (iv, mode) of
+		(Just iv', AppendMode) -> do
+			liftIO $ unableIncrementalVerifier iv'
+			return (const noop)
+		(Just iv', _) -> return (updateIncrementalVerifier iv')
+		(Nothing, _) -> return (const noop)
+	(fr, fh) <- allocate (openBinaryFile file mode) hClose
+	runConduit $ responseBody resp .| go ui initialp fh
+	release fr
+  where
+	go ui sofar fh = await >>= \case
+		Nothing -> return ()
+		Just bs -> do
+			let sofar' = addBytesProcessed sofar (B.length bs)
+			liftIO $ do
+				void $ meterupdate sofar'
+				() <- ui bs
+				B.hPut fh bs
+			go ui sofar' fh
+
+{- Downloads at least the specified number of bytes from an url. -}
+downloadPartial :: URLString -> UrlOptions -> Int -> IO (Maybe L.ByteString)
+downloadPartial url uo n = case parseURIRelaxed url of
+	Nothing -> return Nothing
+	Just u -> go u `catchNonAsync` const (return Nothing)
+  where
+	go u = case parseRequestRelaxed u of
+		Nothing -> return Nothing
+		Just req -> do
+			let req' = applyRequest uo req
+			liftIO $ debug "Utility.Url" (show req')
+			withResponse req' (httpManager uo) $ \resp ->
+				if responseStatus resp == ok200
+					then Just <$> brReadSome (responseBody resp) n
+					else return Nothing
+
+{- Generate a http-conduit Request for an URI. This is able
+ - to deal with some urls that parseRequest would usually reject. 
+ -}
+parseRequestRelaxed :: MonadThrow m => URI -> m Request
+parseRequestRelaxed u = case uriAuthority u of
+	Just ua
+		-- parseURI can handle an empty port value, but
+		-- parseRequest cannot. So remove the ':' to
+		-- make it work.
+		| uriPort ua == ":" -> parseRequest $ show $
+			u { uriAuthority = Just $ ua { uriPort = "" } }
+	_ -> parseRequest (show u)
+
+hAcceptEncoding :: CI.CI B.ByteString
+hAcceptEncoding = "Accept-Encoding"
+
+hContentDisposition :: CI.CI B.ByteString
+hContentDisposition = "Content-Disposition"
+
+hContentRange :: CI.CI B.ByteString
+hContentRange = "Content-Range"
+
+resumeFromHeader :: FileSize -> Header
+resumeFromHeader sz = (hRange, renderByteRanges [ByteRangeFrom sz])
+
+{- Use with eg:
+ -
+ - > catchJust (matchStatusCodeException (== notFound404))
+ -}
+matchStatusCodeException :: (Status -> Bool) -> HttpException -> Maybe HttpException
+matchStatusCodeException want = matchStatusCodeHeadersException (\s _h -> want s)
+
+matchStatusCodeHeadersException :: (Status -> ResponseHeaders -> Bool) -> HttpException -> Maybe HttpException
+matchStatusCodeHeadersException want e@(HttpExceptionRequest _ (StatusCodeException r _))
+	| want (responseStatus r) (responseHeaders r) = Just e
+	| otherwise = Nothing
+matchStatusCodeHeadersException _ _ = Nothing
+
+{- Use with eg: 
+ -
+ - > catchJust matchHttpException
+ -}
+matchHttpException :: HttpException -> Maybe HttpException
+matchHttpException = Just
+
+matchHttpExceptionContent :: (HttpExceptionContent -> Bool) -> HttpException -> Maybe HttpException
+matchHttpExceptionContent want e@(HttpExceptionRequest _ hec)
+	| want hec = Just e
+	| otherwise = Nothing
+matchHttpExceptionContent _ _ = Nothing
+
+{- Constructs parameters that prevent curl from accessing any IP addresses
+ - blocked by the Restriction. These are added to the input parameters,
+ - which should tell curl what to do.
+ -
+ - This has to disable redirects because it looks up the IP addresses 
+ - of the host and after limiting to those allowed by the Restriction,
+ - makes curl resolve the host to those IP addresses. It doesn't make sense
+ - to use this for http anyway, only for ftp or perhaps other protocols
+ - supported by curl.
+ -
+ - Throws an exception if the Restriction blocks all addresses, or
+ - if the dns lookup fails. A malformed url will also cause an exception.
+ -}
+curlRestrictedParams :: Restriction -> URI -> Int -> [CommandParam] -> IO [CommandParam]
+curlRestrictedParams r u defport ps = case uriAuthority u of
+	Nothing -> giveup "malformed url"
+	Just uath -> case uriPort uath of
+		"" -> go (uriRegName uath) defport
+		-- ignore an empty port, same as
+		-- parseRequestRelaxed does.
+		":" -> go (uriRegName uath) defport
+		-- strict parser because the port we provide to curl
+		-- needs to match the port in the url
+		(':':s) -> case readMaybe s :: Maybe Int of
+			Just p -> go (uriRegName uath) p
+			Nothing -> giveup "malformed url"
+		_ -> giveup "malformed url"
+  where
+	go hostname p = do
+		proto <- getProtocolNumber "tcp"
+		let serv = show p
+		let hints = defaultHints
+			{ addrFlags = [AI_ADDRCONFIG]
+			, addrProtocol = proto
+			, addrSocketType = Stream
+			}
+		addrs <- getAddrInfo (Just hints) (Just hostname) (Just serv)
+		case partitionEithers (map checkrestriction addrs) of
+			((e:_es), []) -> throwIO e
+			(_, as)
+				| null as -> giveup $ 
+					"cannot resolve host " ++ hostname
+				| otherwise -> return $
+					(limitresolve p) as ++ ps
+	checkrestriction addr = maybe (Right addr) Left $
+		checkAddressRestriction r addr
+	limitresolve p addrs =
+		[ Param "--resolve"
+		, Param $ "*:" ++ show p ++ ":" ++ intercalate ":"
+			(mapMaybe (bracketaddr <$$> extractIPAddress . addrAddress) addrs)
+		-- Don't let a ftp server provide an IP address.
+		, Param "--ftp-skip-pasv-ip"
+		-- Prevent all http redirects.
+		, Param "--max-redirs", Param "0"
+		]
+	bracketaddr a = "[" ++ a ++ "]"
+
+data BasicAuth = BasicAuth
+	{ basicAuthUser :: String
+	, basicAuthPassword :: String
+	}
+
+-- Note that this is only used when using conduit, not curl.
+--
+-- The returned IO action is run after trying to use the BasicAuth,
+-- indicating if the password worked.
+type GetBasicAuth = URLString -> IO (Maybe (BasicAuth, Bool -> IO ()))
+
+noBasicAuth :: GetBasicAuth
+noBasicAuth = const $ pure Nothing
+
+applyBasicAuth' :: BasicAuth -> Request -> Request
+applyBasicAuth' ba = applyBasicAuth
+	(encodeBS (basicAuthUser ba))
+	(encodeBS (basicAuthPassword ba))
+
+{- Make sure whatever is returned is fully evaluated. Avoids any possible
+ - issues with laziness deferring processing until a time when the resource
+ - has been freed. -}
+extractFromResourceT :: (MonadIO m, NFData a) => a -> ResourceT m a
+extractFromResourceT v = do
+	liftIO $ evaluate (rnf v)
+	return v
diff --git a/Utility/Url/Parse.hs b/Utility/Url/Parse.hs
new file mode 100644
index 0000000000..a683c23738
--- /dev/null
+++ b/Utility/Url/Parse.hs
@@ -0,0 +1,64 @@
+{- Url parsing.
+ -
+ - Copyright 2011-2023 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE RankNTypes #-}
+{-# LANGUAGE FlexibleContexts #-}
+{-# LANGUAGE BangPatterns #-}
+{-# LANGUAGE CPP #-}
+
+module Utility.Url.Parse (
+	parseURIPortable,
+	parseURIRelaxed,
+) where
+
+import Network.URI
+#ifdef mingw32_HOST_OS
+import Data.List
+import qualified System.FilePath.Windows as PW
+#endif
+
+{- On unix this is the same as parseURI. But on Windows,
+ - it can parse urls such as file:///C:/path/to/file
+ - parseURI normally parses that as a path /C:/path/to/file
+ - and this simply removes the excess leading slash when there is a
+ - drive letter after it. -}
+parseURIPortable :: String -> Maybe URI
+#ifndef mingw32_HOST_OS
+parseURIPortable = parseURI
+#else
+parseURIPortable s
+	| "file:" `isPrefixOf` s = do
+		u <- parseURI s
+		return $ case PW.splitDirectories (uriPath u) of
+			(p:d:_) | all PW.isPathSeparator p && PW.isDrive d ->
+				u { uriPath = dropWhile PW.isPathSeparator (uriPath u) }
+			_ -> u
+	| otherwise = parseURI s
+#endif
+
+{- Allows for spaces and other stuff in urls, properly escaping them. -}
+parseURIRelaxed :: String -> Maybe URI
+parseURIRelaxed s = maybe (parseURIRelaxed' s) Just $
+	parseURIPortable $ escapeURIString isAllowedInURI s
+
+{- Some characters like '[' are allowed in eg, the address of
+ - an uri, but cannot appear unescaped further along in the uri.
+ - This handles that, expensively, by successively escaping each character
+ - from the back of the url until the url parses.
+ -}
+parseURIRelaxed' :: String -> Maybe URI
+parseURIRelaxed' s = go [] (reverse s)
+  where
+	go back [] = parseURI back
+	go back (c:cs) = case parseURI (escapeURIString isAllowedInURI (reverse (c:cs)) ++ back) of
+		Just u -> Just u
+		Nothing -> go (escapeURIChar escapemore c ++ back) cs
+
+	escapemore '[' = False
+	escapemore ']' = False
+	escapemore c = isAllowedInURI c
diff --git a/Utility/UserInfo.hs b/Utility/UserInfo.hs
new file mode 100644
index 0000000000..827229d22c
--- /dev/null
+++ b/Utility/UserInfo.hs
@@ -0,0 +1,74 @@
+{- user info
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
+module Utility.UserInfo (
+	myHomeDir,
+	myUserName,
+	myUserGecos,
+) where
+
+import Utility.Env.Basic
+import Utility.Exception
+#ifndef mingw32_HOST_OS
+import Utility.Data
+import Control.Applicative
+import System.Posix.User
+#if MIN_VERSION_unix(2,8,0)
+import System.Posix.User.ByteString (UserEntry)
+#endif
+#endif
+
+import Prelude
+
+{- Current user's home directory.
+ -
+ - getpwent will fail on LDAP or NIS, so use HOME if set. -}
+myHomeDir :: IO FilePath
+myHomeDir = either giveup return =<<
+#ifndef mingw32_HOST_OS
+	myVal ["HOME"] homeDirectory
+#else
+	myVal ["USERPROFILE", "HOME"] -- HOME is used in Cygwin
+#endif
+
+{- Current user's user name. -}
+myUserName :: IO (Either String String)
+myUserName =
+#ifndef mingw32_HOST_OS
+	myVal ["USER", "LOGNAME"] userName
+#else
+	myVal ["USERNAME", "USER", "LOGNAME"]
+#endif
+
+myUserGecos :: IO (Maybe String)
+-- userGecos is not available on Windows.
+#if defined(mingw32_HOST_OS)
+myUserGecos = return Nothing
+#else
+myUserGecos = eitherToMaybe <$> myVal [] userGecos
+#endif
+
+#ifndef mingw32_HOST_OS
+myVal :: [String] -> (UserEntry -> String) -> IO (Either String String)
+myVal envvars extract = go envvars
+  where
+	go [] = either (const $ envnotset) (Right . extract) <$> get
+	go (v:vs) = maybe (go vs) (return . Right) =<< getEnv v
+	-- This may throw an exception if the system doesn't have a
+	-- passwd file etc; don't let it crash.
+	get = tryNonAsync $ getUserEntryForID =<< getEffectiveUserID
+#else
+myVal :: [String] -> IO (Either String String)
+myVal envvars = go envvars
+  where
+	go [] = return envnotset
+	go (v:vs) = maybe (go vs) (return . Right) =<< getEnv v
+#endif
+	envnotset = Left ("environment not set: " ++ show envvars)
diff --git a/Utility/Verifiable.hs b/Utility/Verifiable.hs
new file mode 100644
index 0000000000..a437d947f6
--- /dev/null
+++ b/Utility/Verifiable.hs
@@ -0,0 +1,46 @@
+{- values verified using a shared secret
+ -
+ - Copyright 2012 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+module Utility.Verifiable (
+	Secret,
+	HMACDigest,
+	Verifiable(..),
+	mkVerifiable,
+	verify,
+	prop_verifiable_sane,
+) where
+
+import Data.ByteString.UTF8 (fromString)
+import qualified Data.ByteString as S
+
+import Utility.Hash
+import Utility.QuickCheck
+
+type Secret = S.ByteString
+type HMACDigest = String
+
+{- A value, verifiable using a HMAC digest and a secret. -}
+data Verifiable a = Verifiable
+	{ verifiableVal :: a
+	, verifiableDigest :: HMACDigest
+	}
+	deriving (Eq, Read, Show)
+
+mkVerifiable :: Show a => a -> Secret -> Verifiable a
+mkVerifiable a secret = Verifiable a (calcDigest (show a) secret)
+
+verify :: (Eq a, Show a) => Verifiable a -> Secret -> Bool
+verify v secret = v == mkVerifiable (verifiableVal v) secret
+
+calcDigest :: String -> Secret -> HMACDigest
+calcDigest v secret = calcMac HmacSha1 secret (fromString v)
+
+prop_verifiable_sane :: TestableString -> TestableString -> Bool
+prop_verifiable_sane v ts = 
+	verify (mkVerifiable (fromTestableString v) secret) secret
+  where
+	secret = fromString (fromTestableString ts)
diff --git a/Utility/WebApp.hs b/Utility/WebApp.hs
new file mode 100644
index 0000000000..987d67cbd6
--- /dev/null
+++ b/Utility/WebApp.hs
@@ -0,0 +1,204 @@
+{- Yesod webapp
+ -
+ - Copyright 2012-2014 Joey Hess <id@joeyh.name>
+ -
+ - License: BSD-2-clause
+ -}
+
+{-# LANGUAGE OverloadedStrings, CPP, RankNTypes, PackageImports #-}
+
+module Utility.WebApp (
+	browserProc,
+	runWebApp,
+	webAppSessionBackend,
+	checkAuthToken,
+	insertAuthToken,
+	writeHtmlShim,
+) where
+
+import Common
+import Utility.Tmp
+import Utility.FileMode
+import Utility.AuthToken
+
+import qualified Yesod
+import qualified Network.Wai as Wai
+import Network.Wai.Handler.Warp
+import Network.Wai.Handler.WarpTLS
+import Network.HTTP.Types
+import Network.Socket
+import "crypto-api" Crypto.Random
+import qualified Web.ClientSession as CS
+import qualified Data.Text as T
+import qualified Data.Text.Encoding as TE
+import Blaze.ByteString.Builder.Char.Utf8 (fromText)
+import Blaze.ByteString.Builder (Builder)
+import Control.Arrow ((***))
+import Control.Concurrent
+
+{- Builds a command to use to start or open a web browser showing an url. -}
+browserProc :: String -> CreateProcess
+#ifdef darwin_HOST_OS
+browserProc url = proc "open" [url]
+#else
+#ifdef mingw32_HOST_OS
+-- Warning: On Windows, no quoting or escaping of the url seems possible,
+-- so spaces in it will cause problems. One approach is to make the url
+-- be a relative filename, and adjust the returned CreateProcess to change
+-- to the directory it's in.
+browserProc url = proc "cmd" ["/c start " ++ url]
+#else
+browserProc url = proc "xdg-open" [url]
+#endif
+#endif
+
+{- Binds to a socket on localhost, or possibly a different specified
+ - hostname or address, and runs a webapp on it.
+ -
+ - An IO action can also be run, to do something with the address,
+ - such as start a web browser to view the webapp.
+ -}
+runWebApp :: Maybe TLSSettings -> Maybe HostName -> Maybe PortNumber -> Wai.Application -> (SockAddr -> IO ()) -> IO ()
+runWebApp tlssettings h p app observer = withSocketsDo $ do
+	sock <- getSocket h p
+	void $ forkIO $ go webAppSettings sock app	
+	sockaddr <- getSocketName sock
+	observer sockaddr
+  where
+	go = (maybe runSettingsSocket (\ts -> runTLSSocket ts) tlssettings)
+
+-- disable buggy sloworis attack prevention code
+webAppSettings :: Settings
+webAppSettings = setTimeout halfhour defaultSettings
+  where
+	halfhour = 30 * 60
+
+{- Binds to a local socket, or if specified, to a socket on the specified
+ - hostname or address. Selects any free port, unless a port is specified.
+ -
+ - Prefers to bind to the ipv4 address rather than the ipv6 address
+ - of localhost, if it's available.
+ -}
+getSocket :: Maybe HostName -> Maybe PortNumber -> IO Socket
+getSocket h p = do
+#if defined (mingw32_HOST_OS)
+	-- The HostName is ignored by this code.
+	-- getAddrInfo didn't used to work on windows; current status
+	-- unknown.
+	when (isJust h) $
+		giveup "getSocket with HostName not supported on this OS"
+	let addr = tupleToHostAddress (127,0,0,1)
+	sock <- socket AF_INET Stream defaultProtocol
+	preparesocket sock
+	bind sock (SockAddrInet (fromMaybe defaultPort p) addr)
+	use sock
+  where
+#else
+	addrs <- getAddrInfo (Just hints) (Just hostname) (fmap show p)
+	case (partition (\a -> addrFamily a == AF_INET) addrs) of
+		(v4addr:_, _) -> go v4addr
+		(_, v6addr:_) -> go v6addr
+		_ -> giveup "unable to bind to a local socket"
+  where
+	hostname = fromMaybe localhost h
+	localhost = "localhost"
+	hints = defaultHints { addrSocketType = Stream }
+	{- Repeated attempts because bind sometimes fails for an
+	 - unknown reason on OSX. -} 
+	go addr = go' 100 addr
+	go' :: Int -> AddrInfo -> IO Socket
+	go' 0 _ = giveup "unable to bind to local socket"
+	go' n addr = do
+		r <- tryIO $ bracketOnError (open addr) close (useaddr addr)
+		either (const $ go' (pred n) addr) return r
+	open addr = socket (addrFamily addr) (addrSocketType addr) (addrProtocol addr)
+	useaddr addr sock = do
+		preparesocket sock
+		bind sock (addrAddress addr)
+		use sock
+#endif
+	preparesocket sock = setSocketOption sock ReuseAddr 1
+	use sock = do
+		listen sock maxListenQueue
+		return sock
+
+{- Rather than storing a session key on disk, use a random key
+ - that will only be valid for this run of the webapp. -}
+webAppSessionBackend :: Yesod.Yesod y => y -> IO (Maybe Yesod.SessionBackend)
+webAppSessionBackend _ = do
+	g <- newGenIO :: IO SystemRandom
+	case genBytes 96 g of
+		Left e -> giveup $ "failed to generate random key: " ++ show e
+		Right (s, _) -> case CS.initKey s of
+			Left e -> giveup $ "failed to initialize key: " ++ show e
+			Right key -> use key
+  where
+	timeout = 120 * 60 -- 120 minutes
+	use key =
+		Just . Yesod.clientSessionBackend key . fst
+			<$> Yesod.clientSessionDateCacher timeout
+
+{- A Yesod isAuthorized method, which checks the auth cgi parameter
+ - against a token extracted from the Yesod application.
+ -
+ - Note that the usual Yesod error page is bypassed on error, to avoid
+ - possibly leaking the auth token in urls on that page!
+ -
+ - If the predicate does not match the route, the auth parameter is not
+ - needed.
+ -}
+checkAuthToken :: Yesod.MonadHandler m => Yesod.RenderRoute site => (Yesod.HandlerSite m -> AuthToken) -> Yesod.Route site -> ([T.Text] -> Bool) -> m Yesod.AuthResult
+checkAuthToken extractAuthToken r predicate
+	| not (predicate (fst (Yesod.renderRoute r))) = return Yesod.Authorized
+	| otherwise = do
+		webapp <- Yesod.getYesod
+		req <- Yesod.getRequest
+		let params = Yesod.reqGetParams req
+		if (toAuthToken =<< lookup "auth" params) == Just (extractAuthToken webapp)
+			then return Yesod.Authorized
+			else Yesod.sendResponseStatus unauthorized401 ()
+
+{- A Yesod joinPath method, which adds an auth cgi parameter to every
+ - url matching a predicate, containing a token extracted from the
+ - Yesod application.
+ - 
+ - A typical predicate would exclude files under /static.
+ -}
+insertAuthToken :: forall y. (y -> AuthToken)
+	-> ([T.Text] -> Bool)
+	-> y
+	-> T.Text
+	-> [T.Text]
+	-> [(T.Text, T.Text)]
+	-> Builder
+insertAuthToken extractAuthToken predicate webapp root pathbits params =
+	fromText root `mappend` encodePath pathbits' encodedparams
+  where
+	pathbits' = if null pathbits then [T.empty] else pathbits
+	encodedparams = map (TE.encodeUtf8 *** go) params'
+	go "" = Nothing
+	go x = Just $ TE.encodeUtf8 x
+	authparam = (T.pack "auth", fromAuthToken (extractAuthToken webapp))
+	params'
+		| predicate pathbits = authparam:params
+		| otherwise = params
+
+{- Creates a html shim file that's used to redirect into the webapp,
+ - to avoid exposing the secret token when launching the web browser. -}
+writeHtmlShim :: String -> String -> FilePath -> IO ()
+writeHtmlShim title url file = 
+	viaTmp (writeFileProtected . toRawFilePath) file $ genHtmlShim title url
+
+genHtmlShim :: String -> String -> String
+genHtmlShim title url = unlines
+	[ "<html>"
+	, "<head>"
+	, "<title>"++ title ++ "</title>"
+	, "<meta http-equiv=\"refresh\" content=\"1; URL="++url++"\">"
+	, "<body>"
+	, "<p>"
+	, "<a href=\"" ++ url ++ "\">" ++ title ++ "</a>"
+	, "</p>"
+	, "</body>"
+	, "</html>"
+	]
diff --git a/Utility/Yesod.hs b/Utility/Yesod.hs
new file mode 100644
index 0000000000..5acbdee99c
--- /dev/null
+++ b/Utility/Yesod.hs
@@ -0,0 +1,38 @@
+{- Yesod stuff, that's typically found in the scaffolded site.
+ -
+ - Also a bit of a compatibility layer for older versions of yesod.
+ -
+ - Copyright 2012-2014 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE RankNTypes, FlexibleContexts #-}
+
+module Utility.Yesod 
+	( module Y
+	, liftH
+	, widgetFile
+	, hamletTemplate
+	) where
+
+import Yesod as Y
+import Yesod.Form.Bootstrap3 as Y hiding (bfs)
+import Yesod.Default.Util
+import Language.Haskell.TH.Syntax (Q, Exp)
+import Data.Default (def)
+import Text.Hamlet hiding (Html)
+
+widgetFile :: String -> Q Exp
+widgetFile = widgetFileNoReload $ def
+	{ wfsHamletSettings = defaultHamletSettings
+		{ hamletNewlines = AlwaysNewlines
+		}
+	}
+
+hamletTemplate :: FilePath -> FilePath
+hamletTemplate f = globFile "hamlet" f
+
+{- Lift Handler to Widget -}
+liftH :: HandlerFor site a -> WidgetFor site a 
+liftH = handlerToWidget
diff --git a/Utility/libkqueue.c b/Utility/libkqueue.c
new file mode 100644
index 0000000000..3f40465e37
--- /dev/null
+++ b/Utility/libkqueue.c
@@ -0,0 +1,74 @@
+/* kqueue interface, C mini-library
+ *
+ * Copyright 2012 Joey Hess <id@joeyh.name>
+ *
+ * License: BSD-2-clause
+ */
+
+#include <stdio.h>
+#include <dirent.h>
+#include <fcntl.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <sys/types.h>
+#include <sys/event.h>
+#include <sys/time.h>
+#include <errno.h>
+
+/* The specified fds are added to the set of fds being watched for changes.
+ * Fds passed to prior calls still take effect, so it's most efficient to
+ * not pass the same fds repeatedly.
+ *
+ * Returns the fd that changed, or -1 on error.
+ */
+signed int helper(const int kq, const int fdcnt, const int *fdlist, int nodelay) {
+	int i, nev;
+	struct kevent evlist[1];
+	struct kevent chlist[fdcnt];
+	struct timespec avoiddelay = {0, 0};
+	struct timespec *timeout = nodelay ? &avoiddelay : NULL;
+	
+	for (i = 0; i < fdcnt; i++) {
+		EV_SET(&chlist[i], fdlist[i], EVFILT_VNODE,
+			EV_ADD | EV_ENABLE | EV_CLEAR,
+			NOTE_WRITE,
+			0, 0);
+	}
+
+	nev = kevent(kq, chlist, fdcnt, evlist, 1, timeout);
+	if (nev == 1)
+		return evlist[0].ident;
+	else
+		return -1;
+}
+
+/* Initializes a new, empty kqueue. */
+int init_kqueue() {
+	int kq;
+	if ((kq = kqueue()) == -1) {
+		perror("kqueue");
+		exit(1);
+	}
+	return kq;
+}
+
+/* Adds fds to the set that should be watched. */
+void addfds_kqueue(const int kq, const int fdcnt, const int *fdlist) {
+	helper(kq, fdcnt, fdlist, 1);
+}
+
+/* Waits for a change event on a kqueue. */
+signed int waitchange_kqueue(const int kq) {
+	return helper(kq, 0, NULL, 0);
+}
+
+/*
+main () {
+	int list[1];
+	int kq;
+	list[0]=open(".", O_RDONLY);
+	kq = init_kqueue();
+	addfds_kqueue(kq, 1, list)
+	printf("change: %i\n", waitchange_kqueue(kq));
+}
+*/
diff --git a/Utility/libkqueue.h b/Utility/libkqueue.h
new file mode 100644
index 0000000000..692b47f14e
--- /dev/null
+++ b/Utility/libkqueue.h
@@ -0,0 +1,3 @@
+int init_kqueue();
+void addfds_kqueue(const int kq, const int fdcnt, const int *fdlist);
+signed int waitchange_kqueue(const int kq);
diff --git a/bash-completion.bash b/bash-completion.bash
new file mode 100644
index 0000000000..78aef02e1b
--- /dev/null
+++ b/bash-completion.bash
@@ -0,0 +1,44 @@
+# Use git-annex's built-in bash completion
+# This is the same code output by git-annex --bash-completion-script git-annex
+# This covers all commands, all options, and will never go out of date!
+_git-annex()
+{
+    local CMDLINE
+    local IFS=$'\n'
+    CMDLINE=(--bash-completion-index $COMP_CWORD)
+
+    for arg in ${COMP_WORDS[@]}; do
+        CMDLINE=(${CMDLINE[@]} --bash-completion-word $arg)
+    done
+
+    COMPREPLY=( $(git-annex "${CMDLINE[@]}") )
+}
+
+complete -o bashdefault -o default -o filenames -F _git-annex git-annex
+
+# Called by git's bash completion script when completing "git annex"
+# Translate to the "git-annex" completion above.
+_git_annex() {
+    local CMDLINE
+    CMDLINE=(--bash-completion-index $(($COMP_CWORD - 1)))
+
+    local seen_git
+    local seen_annex
+    for arg in ${COMP_WORDS[@]}; do
+        if [ "$arg" = git ] && [ -z "$seen_git" ]; then
+		seen_git=1
+		CMDLINE=(${CMDLINE[@]} --bash-completion-word git-annex)
+	elif [ "$arg" = annex ] && [ -z "$seen_annex" ]; then
+		seen_annex=1
+	else
+		CMDLINE=(${CMDLINE[@]} --bash-completion-word $arg)
+	fi
+    done
+
+    # This is the same as __gitcomp_file_direct in git-completion.bash;
+    local IFS=$'\n'
+    COMPREPLY=( $(git-annex "${CMDLINE[@]}") )
+    compopt -o filenames +o nospace ||
+    compgen -f /non-existing-dir/ >/dev/null ||
+    true
+}
diff --git a/debian/NEWS b/debian/NEWS
new file mode 120000
index 0000000000..0fae0f8020
--- /dev/null
+++ b/debian/NEWS
@@ -0,0 +1 @@
+../NEWS
\ No newline at end of file
diff --git a/debian/changelog b/debian/changelog
new file mode 120000
index 0000000000..a535994713
--- /dev/null
+++ b/debian/changelog
@@ -0,0 +1 @@
+../CHANGELOG
\ No newline at end of file
diff --git a/debian/compat b/debian/compat
new file mode 100644
index 0000000000..ec635144f6
--- /dev/null
+++ b/debian/compat
@@ -0,0 +1 @@
+9
diff --git a/debian/control b/debian/control
new file mode 100644
index 0000000000..0cfe536bf7
--- /dev/null
+++ b/debian/control
@@ -0,0 +1,149 @@
+Source: git-annex
+Section: utils
+Priority: optional
+Build-Depends: 
+	debhelper (>= 9),
+	ghc (>= 8.4.3),
+	cabal-install,
+	libghc-mtl-dev (>= 2.1.1),
+	libghc-split-dev,
+	libghc-data-default-dev,
+	libghc-hslogger-dev,
+	libghc-cryptonite-dev,
+	libghc-memory-dev,
+	libghc-deepseq-dev,
+	libghc-attoparsec-dev,
+	libghc-sandi-dev,
+	libghc-utf8-string-dev,
+	libghc-aws-dev (>= 0.9.2-2~),
+	libghc-conduit-dev,
+	libghc-resourcet-dev,
+	libghc-quickcheck2-dev,
+	libghc-monad-control-dev (>= 0.3),
+	libghc-transformers-dev,
+	libghc-exceptions-dev (>= 0.6),
+	libghc-unix-compat-dev,
+	libghc-dlist-dev,
+	libghc-uuid-dev,
+	libghc-aeson-dev,
+	libghc-tagsoup-dev,
+	libghc-unordered-containers-dev,
+	libghc-ifelse-dev,
+	libghc-bloomfilter-dev,
+	libghc-edit-distance-dev,
+	libghc-hinotify-dev [linux-any],
+	libghc-dbus-dev (>= 0.10.7) [linux-any],
+	libghc-fdo-notify-dev (>= 0.3) [linux-any],
+	libghc-yesod-dev (>= 1.2.6.1)       [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 m68k mips mips64el mipsel powerpc ppc64el s390x],
+	libghc-yesod-core-dev (>= 1.2.19)   [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 m68k mips mips64el mipsel powerpc ppc64el s390x],
+	libghc-yesod-form-dev (>= 1.3.15)   [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 m68k mips mips64el mipsel powerpc ppc64el s390x],
+	libghc-yesod-static-dev (>= 1.2.4)  [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 m68k mips mips64el mipsel powerpc ppc64el s390x],
+	libghc-shakespeare-dev (>= 2.0.0)   [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 m68k mips mips64el mipsel powerpc ppc64el s390x],
+	libghc-clientsession-dev            [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 m68k mips mips64el mipsel powerpc ppc64el s390x],
+	libghc-warp-dev (>= 3.0.0.5)        [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 m68k mips mips64el mipsel powerpc ppc64el s390x],
+	libghc-warp-tls-dev                 [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 m68k mips mips64el mipsel powerpc ppc64el s390x],
+	libghc-wai-dev                      [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 m68k mips mips64el mipsel powerpc ppc64el s390x],
+	libghc-wai-extra-dev                [i386 amd64 arm64 armel armhf kfreebsd-i386 kfreebsd-amd64 m68k mips mips64el mipsel powerpc ppc64el s390x],
+	libghc-dav-dev (>= 1.0),
+	libghc-persistent-dev,
+	libghc-persistent-template-dev,
+	libghc-persistent-sqlite-dev,
+	libghc-microlens-dev,
+	libghc-securemem-dev,
+	libghc-byteable-dev,
+	libghc-stm-chans-dev,
+	libghc-case-insensitive-dev,
+	libghc-http-types-dev,
+	libghc-http-conduit-dev,
+	libghc-http-client-restricted-dev,
+	libghc-blaze-builder-dev,
+	libghc-crypto-api-dev,
+	libghc-network-multicast-dev,
+	libghc-network-info-dev [linux-any kfreebsd-any],
+	libghc-safesemaphore-dev,
+	libghc-async-dev,
+	libghc-monad-logger-dev,
+	libghc-free-dev,
+	libghc-feed-dev (>= 0.3.9.2),
+	libghc-regex-tdfa-dev,
+	libghc-tasty-dev (>= 0.7),
+	libghc-tasty-hunit-dev,
+	libghc-tasty-quickcheck-dev,
+	libghc-tasty-rerun-dev,
+	libghc-cabal-dev,
+	libghc-ansi-terminal-dev,
+	libghc-optparse-applicative-dev (>= 0.11.0),
+	libghc-torrent-dev,
+	libghc-concurrent-output-dev,
+	libghc-disk-free-space-dev,
+	libghc-mountpoints-dev,
+	libghc-magic-dev,
+	libghc-socks-dev,
+	libghc-vector-dev,
+	libghc-unliftio-core-dev,
+	libghc-filepath-bytestring-dev,
+	libghc-git-lfs-dev (>= 1.2.0),
+	libghc-criterion-dev,
+	lsof [linux-any],
+	ikiwiki,
+	libimage-magick-perl,
+	git (>= 1:2.22),
+	rsync,
+	curl,
+	openssh-client,
+	git-remote-gcrypt (>= 0.20130908-6),
+	gnupg,
+	gpg-agent,
+Maintainer: Richard Hartmann <richih@debian.org>
+Standards-Version: 3.9.8
+Vcs-Git: git://git.joeyh.name/git-annex
+Homepage: http://git-annex.branchable.com/
+XS-Testsuite: autopkgtest
+
+Package: git-annex
+Architecture: any
+Section: utils
+Depends: ${misc:Depends}, ${shlibs:Depends},
+	git (>= 1:2.22),
+	netbase,
+	rsync,
+	curl,
+	openssh-client (>= 1:5.6p1)
+Recommends: 
+	lsof,
+	gnupg,
+	bind9-host,
+	yt-dlp,
+	git-remote-gcrypt (>= 0.20130908-6),
+	nocache,
+	aria2,
+Suggests:
+	xdot,
+	bup,
+	adb,
+	tor,
+	magic-wormhole,
+	tahoe-lafs,
+	libnss-mdns,
+	uftp,
+	yt-dlp,
+Breaks: datalad (< 0.12.3~)
+Description: manage files with git, without checking their contents into git
+ git-annex allows managing large files with git, without storing the file 
+ contents in git. It can sync, backup, and archive your data, offline
+ and online. Checksums and encryption keep your data safe and secure. Bring
+ the power and distributed nature of git to bear on your large files with
+ git-annex.
+ .
+ It can store large files in many places, from local hard drives, to a
+ large number of cloud storage services, including S3, WebDAV,
+ and rsync, with dozens of cloud storage providers usable via plugins.
+ Files can be stored encrypted with gpg, so that the cloud storage
+ provider cannot see your data. git-annex keeps track of where each file
+ is stored, so it knows how many copies are available, and has many
+ facilities to ensure your data is preserved.
+ .
+ git-annex can also be used to keep a folder in sync between computers,
+ noticing when files are changed, and automatically committing them
+ to git and transferring them to other computers. The git-annex webapp
+ makes it easy to set up and use git-annex this way.
diff --git a/debian/copyright b/debian/copyright
new file mode 120000
index 0000000000..dc5f40a221
--- /dev/null
+++ b/debian/copyright
@@ -0,0 +1 @@
+../COPYRIGHT
\ No newline at end of file
diff --git a/debian/create-standalone-changelog b/debian/create-standalone-changelog
new file mode 100755
index 0000000000..c5e607e9e7
--- /dev/null
+++ b/debian/create-standalone-changelog
@@ -0,0 +1,17 @@
+#!/bin/bash
+#
+# A little helper script to build a package with standalone git-annex
+# It relies on being run within git-annex's git repository
+#
+set -eu
+
+umask 022
+
+# For NeuroDebian we rely on `git describe` output to get a
+# sortable version which should work for any stage of a snapshot between
+# releases and would remain sortable
+ANNEX_VERSION=$(git describe HEAD)
+ANNEX_NDVERSION=$( echo ${ANNEX_VERSION} | sed -e 's,-,+git,' -e 's,$,-1~ndall+1,')
+
+dch --noconf -v ${ANNEX_NDVERSION} \
+    --force-bad-version --force-distribution -D neurodebian "Backported fresh snapshot"
diff --git a/debian/doc-base b/debian/doc-base
new file mode 100644
index 0000000000..f71a233333
--- /dev/null
+++ b/debian/doc-base
@@ -0,0 +1,9 @@
+Document: git-annex
+Title: git-annex documentation
+Author: Joey Hess
+Abstract: All the documentation from git-annex's website.
+Section: File Management
+
+Format: HTML
+Index: /usr/share/doc/git-annex/html/index.html
+Files: /usr/share/doc/git-annex/html/*.html
diff --git a/debian/patches/series.standalone-build b/debian/patches/series.standalone-build
new file mode 100644
index 0000000000..9dc994164d
--- /dev/null
+++ b/debian/patches/series.standalone-build
@@ -0,0 +1 @@
+standalone-build
diff --git a/debian/patches/standalone-build b/debian/patches/standalone-build
new file mode 100644
index 0000000000..8edc358fb5
--- /dev/null
+++ b/debian/patches/standalone-build
@@ -0,0 +1,76 @@
+From: Yaroslav Halchenko <debian@onerussian.com>
+Subject: Patch debian/ to provide a standalone build of git-annex
+
+Origin: NeuroDebian
+Last-Update: 2015-04-20
+
+--- a/debian/control
++++ b/debian/control
+@@ -86,6 +86,7 @@ Build-Depends:
+ 	git (>= 1:2.22),
+ 	rsync,
+ 	curl,
++	locales,
+ 	openssh-client,
+ 	git-remote-gcrypt (>= 0.20130908-6),
+ 	gnupg,
+@@ -96,15 +97,15 @@ Vcs-Git: git://git.joeyh.name/git-annex
+ Homepage: http://git-annex.branchable.com/
+ XS-Testsuite: autopkgtest
+ 
+-Package: git-annex
++Package: git-annex-standalone
+ Architecture: any
+ Section: utils
+-Depends: ${misc:Depends}, ${shlibs:Depends},
+-	git (>= 1:2.22),
++Conflicts: git-annex
++Provides: git-annex
++Depends: ${misc:Depends},
++	git,
+ 	netbase,
+-	rsync,
+-	curl,
+-	openssh-client (>= 1:5.6p1)
++	openssh-client
+ Recommends: 
+ 	lsof,
+ 	gnupg,
+@@ -123,7 +124,7 @@ Suggests:
+ 	libnss-mdns,
+ 	uftp,
+ Breaks: datalad (< 0.12.3~)
+-Description: manage files with git, without checking their contents into git
++Description: manage files with git, without checking their contents into git -- standalone build
+  git-annex allows managing large files with git, without storing the file 
+  contents in git. It can sync, backup, and archive your data, offline
+  and online. Checksums and encryption keep your data safe and secure. Bring
+@@ -142,3 +143,7 @@ Description: manage files with git, with
+  noticing when files are changed, and automatically committing them
+  to git and transferring them to other computers. The git-annex webapp
+  makes it easy to set up and use git-annex this way.
++ .
++ This package provides a standalone bundle build of git-annex, which
++ should be installable on any more or less recent Debian or Ubuntu
++ release.
+--- /dev/null
++++ b/debian/install
+@@ -0,0 +1 @@
++tmp/git-annex.linux usr/lib
+--- /dev/null
++++ b/debian/links
+@@ -0,0 +1,2 @@
++/usr/lib/git-annex.linux/git-annex /usr/bin/git-annex
++/usr/lib/git-annex.linux/git-annex-shell /usr/bin/git-annex-shell
+--- a/debian/rules
++++ b/debian/rules
+@@ -41,4 +41,9 @@ override_dh_strip:
+ override_dh_makeshlibs:
+ 	dh_makeshlibs --noscripts
+ 
++# For portability to older systems which do not support default (since
++# buster) .xz for components of the .deb
++override_dh_builddeb:
++	dh_builddeb -- -Zgzip
++
+ endif
diff --git a/debian/rules b/debian/rules
new file mode 100755
index 0000000000..ed882df488
--- /dev/null
+++ b/debian/rules
@@ -0,0 +1,44 @@
+#!/usr/bin/make -f
+
+export BUILDER=./Setup
+
+# -j1 is used for reproducible build
+export BUILDEROPTIONS=-j1
+
+STANDALONE_BUILD=$(shell grep -qe '^Package: git-annex-standalone' debian/control \
+                         && echo 1 || echo 0)
+
+# Do use the changelog's version number, rather than making one up.
+export RELEASE_BUILD=1
+
+export ZSH_COMPLETIONS_PATH=/usr/share/zsh/vendor-completions
+
+%:
+	dh $@
+
+
+# Standalone build logic/helpers
+ifeq ($(STANDALONE_BUILD),1)
+
+override_dh_auto_build:
+	make linuxstandalone GIT_ANNEX_PACKAGE_INSTALL=1
+
+override_dh_auto_install:
+	make install-desktop install-docs install-completions \
+		DESTDIR=debian/git-annex-standalone
+	# bins are linked into place, as instructed in debian/install and debian/links
+
+override_dh_fixperms:
+	dh_fixperms -Xld-linux
+
+# gdb can't do much with a haskell program, so avoid the debug package
+override_dh_strip:
+	dh_strip --no-automatic-dbgsym
+
+# Do not add "ldconfig" trigger since all libraries in the standalone build
+# are private copies and the trigger activate-noawait trigger may not work
+# on elderly distributions (e.g. squeeze)
+override_dh_makeshlibs:
+	dh_makeshlibs --noscripts
+
+endif
diff --git a/debian/source/format b/debian/source/format
new file mode 100644
index 0000000000..d3827e75a5
--- /dev/null
+++ b/debian/source/format
@@ -0,0 +1 @@
+1.0
diff --git a/debian/tests/basics b/debian/tests/basics
new file mode 100644
index 0000000000..2e4ea43fc1
--- /dev/null
+++ b/debian/tests/basics
@@ -0,0 +1,4 @@
+#!/bin/sh
+testdir="$(mktemp -d)"
+cd "$testdir"
+exec git-annex test
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 0000000000..928caf8e31
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,4 @@
+Tests: basics
+Depends: @, git, rsync, gnupg
+Restrictions: allow-stderr
+
diff --git a/doc/Android.mdwn b/doc/Android.mdwn
new file mode 100644
index 0000000000..7117526c68
--- /dev/null
+++ b/doc/Android.mdwn
@@ -0,0 +1,77 @@
+git-annex is available for Android inside Termux or Nix-On-Droid.
+This includes the [[git-annex assistant|/assistant]], for easy
+syncing between your Android and other devices. You do not need
+to root your Android to use git-annex.
+
+(Alternatively, rather than installing git-annex on your Android device,
+git-annex can run on your computer and use `adb` to pull and push changes
+to the Android device. See [[tips/android_sync_with_adb]] for instructions
+on using git-annex that way.)
+
+[[!toc ]]
+
+## Installation (Termux)
+
+First, install [Termux](https://termux.com/). This is an Android app that can
+run some Linux software in a terminal, including git-annex.
+
+git-annex is not currently part of the Termux distribution, but it's easy
+to install it. Paste these commands into Termux:
+
+	pkg install wget
+	wget https://git-annex.branchable.com/install/Android/git-annex-install
+	source git-annex-install
+
+## Installation (Nix-On-Droid)
+
+Installing git-annex using
+[Nix-On-Droid](https://github.com/t184256/nix-on-droid) is recommended
+for more advanced users who want to use git-annex at the command line.
+The git-annex webapp does not currently work in Nix-On-Droid (as a workaround, run `git annex webapp --listen 127.0.0.1` and copy-paste the URL in a browser).
+
+To enter a shell with git-annex available to use,
+run inside Nix-On-Droid: `nix-shell -p git git-annex`
+
+To avoid needing to do that every time you start Nix-On-Droid,
+you can add git and git-annex to your `environment.packages` in 
+`~/.config/nixpkgs/nix-on-droid.nix` and then run 
+`nix-on-droid switch`
+
+## Starting git-annex assistant
+
+Just run "git-annex webapp" inside Termux.
+A browser window will open with the git-annex interface.
+
+[[!img webapp.png alt="git-annex webapp"]]
+
+## Closing and reopening the webapp
+
+The webapp does not need to be left open after you've set up your
+repository. As long as Termux (or Nix-On-Droid) is left open, git-annex 
+will remain running and sync your files.
+
+## Starting at power on
+
+If you install the [Termux:Boot app](https://wiki.termux.com/wiki/Termux:Boot),
+git-annex will be automatically started when your Android device
+powers on. It will run in the background in whatever repositories you have
+set up in the webapp.  
+
+## Using the command line
+
+If you prefer to use `git-annex` at the command line, you can do so inside
+Termux or Nix-On-Droid. Here we'll make a repository for photos:
+
+        cd ~/storage/dcim
+        git init
+        git-annex init
+
+You can go on to set up a ssh remote pointing to a server, and sync
+your files to and from it.
+
+And so on. Most ways you would use git-annex on a Linux system work fairly
+well in the Termux environment.
+
+## Upgrading (Termux)
+
+To upgrade to a new git-annex release, just run `git-annex-install` again.
diff --git a/doc/Android/comment_29_37aa87a451d4390ed367402eec740855._comment b/doc/Android/comment_29_37aa87a451d4390ed367402eec740855._comment
new file mode 100644
index 0000000000..301da48bdb
--- /dev/null
+++ b/doc/Android/comment_29_37aa87a451d4390ed367402eec740855._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 29"
+ date="2013-07-30T17:45:27Z"
+ content="""
+If you are experiencing a problem using git-annex on Android, please examine the list of [[bugs]] and add a new, detailed bug report if no-one has reported the problem. If you are not sure if you have a bug, or need help in filing a good bug report, ask for help in the [[forum]].
+
+I have removeda lot of old comments about problems that may be fixed or
+not (hard to tell without a bug report!) This page cannot
+scale to handle every bug report that someone wants to paste into it.
+"""]]
diff --git a/doc/Android/comment_2_7f0caccd085a541b117c8583133e94dd._comment b/doc/Android/comment_2_7f0caccd085a541b117c8583133e94dd._comment
new file mode 100644
index 0000000000..0b21d13aa6
--- /dev/null
+++ b/doc/Android/comment_2_7f0caccd085a541b117c8583133e94dd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="hoxu"
+ avatar="http://cdn.libravatar.org/avatar/95e33a0073f6c06477b3a202f0301dde"
+ subject="wget link broken"
+ date="2018-10-16T14:23:29Z"
+ content="""
+    wget https://git-annex.branchable.com/install/Android/git-annex-install.sh
+
+This seems to download a html.
+"""]]
diff --git a/doc/Android/comment_3_ff03ae378da71c6637959779139ecb12._comment b/doc/Android/comment_3_ff03ae378da71c6637959779139ecb12._comment
new file mode 100644
index 0000000000..cf710c89af
--- /dev/null
+++ b/doc/Android/comment_3_ff03ae378da71c6637959779139ecb12._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-10-16T15:22:19Z"
+ content="""
+Thank you for reporting that, I have fixed the url.
+
+I'd again like to ask that, if you have **any kind of problem or bug** with
+this Android build of git-annex, you open a [[bug report|bugs]] rather than
+posting a problem here.
+"""]]
diff --git a/doc/Android/comment_4_c7591d06fc444a4462267b000be8d688._comment b/doc/Android/comment_4_c7591d06fc444a4462267b000be8d688._comment
new file mode 100644
index 0000000000..3cfe082247
--- /dev/null
+++ b/doc/Android/comment_4_c7591d06fc444a4462267b000be8d688._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="quzhengrobot@6237b7730f478778d064c18a5a314535129357dd"
+ nickname="quzhengrobot"
+ avatar="http://cdn.libravatar.org/avatar/c49bd522689736d9dd10d29cebee6be3"
+ subject="Android - gitlab repo"
+ date="2019-05-08T11:35:04Z"
+ content="""
+I realized that the webapp of this android version does not support synchronizing a gitlab repo with local repo. Is it possible to achieve it using command line?
+"""]]
diff --git a/doc/Android/comment_5_9118997c7e892ce163c33a0de963fa11._comment b/doc/Android/comment_5_9118997c7e892ce163c33a0de963fa11._comment
new file mode 100644
index 0000000000..98dc95d09e
--- /dev/null
+++ b/doc/Android/comment_5_9118997c7e892ce163c33a0de963fa11._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="mzimann"
+ avatar="http://cdn.libravatar.org/avatar/7fd54a1212458d60d3963c7fbb7ce294"
+ subject="Use curl instead of wget"
+ date="2020-07-18T22:44:20Z"
+ content="""
+It's not necessary to download `wget` in Termux since it already comes with
+`curl`.
+
+However the installation guide instructs to install `wget` in order to fetch
+the installation script `git-annex-install` from the internet. Also the script
+itself relies on `wget` and installs it as a dependency even though the
+preinstalled `curl` could be used just as well.
+
+I think we should use `curl` to reduce the amount of dependencies which have to
+be additionally installed.
+"""]]
diff --git a/doc/Android/comment_6_e9559029d8f2c482a482f7343ffa99a4._comment b/doc/Android/comment_6_e9559029d8f2c482a482f7343ffa99a4._comment
new file mode 100644
index 0000000000..b08ebb6708
--- /dev/null
+++ b/doc/Android/comment_6_e9559029d8f2c482a482f7343ffa99a4._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="cehteh"
+ avatar="http://cdn.libravatar.org/avatar/8ff07aa39d4d817cf3af3e717f41ab1a"
+ subject="comment 6"
+ date="2022-07-18T13:19:43Z"
+ content="""
+starting `git annex webapp` fails for me with (Android 12, CalyxOS):
+
+```
+CANNOT LINK EXECUTABLE \"/system/bin/app_process\": library \"libnativeloader.so\" not found: needed by main executable
+failed to start web browser
+```
+
+The webapp still runs and I can connect the browser by copypaste the link.
+
+instead trying to open the browser natively i have a bit more success with Termux:API by
+
+    termux-open-url 'http://127.0.0.1:42005/?auth=...
+
+This seems to be the right thing to do, unfortunally for some unknown reason it fails sometimes too, but I think thats an issue
+within termux which may become fixed eventually.
+"""]]
diff --git a/doc/android/DCIM.png b/doc/android/DCIM.png
new file mode 100644
index 0000000000000000000000000000000000000000..3ac0933234e6eee1e0736584bf6547fae9553aea
GIT binary patch
literal 95786
zcmd43WmuJ6_b-Z~vP2P3LIEie5RgtOS<=!X9ZGk1rwB-kq#z(&(hVXd-5}lF-Eao)
z```Oq=X~4W_PU<yQDL#xz2-f~7{8kM%See}pc9~@prBxgi3-Z0prDeXpxl^7+=Q?6
z=_Vw@AE?$yF?j?6F*YMTje<goA|@yx?-0K}VXuTEa)q)zQss>roRY9V8Acv}L55RL
zZx=+Moh;1cPuU#K(e#yrvW_CnF!=?6cY(bumaMFd0QQRH>$cvo2lg$46Bidujz={p
zS~D_pXBRw<yL4-t>+9o_>-PG3OP{fy3B$#};|CW}Y+9ln@ulM{Ztg@oyaeVqZyM6S
z--d5Zk2E=rKKakH9423TTz?7W$HyKa1TmT#JN*4M|Bu`EuD|%Yf%NzFheGLLTqeI2
zf=W*afB!+!<Mls3g7x9X^>+>a&Dmf}#j$tR*Ut=OzQe%4@D8KeUiYR){(qnDlb^qZ
z62ZvMZf9$2YGm{f-8c4cAHRnZo!h9gL)-qr0bC~hgoi%<SVxD6hnSMGvagR1HBP|Q
zca*o8@_e2tGC0qp+PR3NLJq7d;z<#B#xg1-?`d$w!cEw#t~!g0i|@=W*UTV8+ZRmO
zRmsB)jEyl5u_MJ(kx9$y>(aL+`?U&={Uh0rr^q5&4Px~QlyHQ2W6be>U#6q0Wy;e;
zwxLbR5I+<PpO~1q`f-X?i9ow87B2Un@8~dBs7Zy-Yg0VL#eFX$)59GqE-gJ(Y#2dV
zIO6x6+dhHEF`V?XCzbC#0rD`>)V`JnVx1iwcrR6o-7cI|Rma>f)-(xPmCSL3m=b&c
z6=>r#Xz+-lt&&LgKlB&8FzOu~bls{sl8}(N6TKecNP!~#si0s7Zs++`!^A|*)y8vo
zsz`Bc<UKq(1Ufnrp{$~Exu$tV@Dr`nEkm9r&CQ{jV3&zHvTbrsWWlP!X(mHHOQ6#`
zG7|UQG=-QP4x2*@d=7M9Ez%eJ%FaA4g=A!8EP5S}Mehu7adG9UmgTjyZEl*yrtK6_
z?~&2qpdVnyrWyJodnYDdhKcGhKY6#<(IP4PRf%rXRZcFmxT@-`fMvWz`&D2QIs#!~
zVKHr05fl`}VK)Al&!s#nYPjn=w`Fj;bmHdpw8idx>!(kj*o=p!YpQFmANSDF!y_U{
z9OOM;Gr~o%u&_Mv>z|xV`2Jm8L!;|_t(~E+W5(ieV~oRT-vA8_jW}d@VBl+P?C9ud
z07uX8u=~NFVqjpP`D8Vh**K@Mv9XVgsi~>Bcz^`uJO0r8{QRn_s)B+7QHrdb90_UZ
zmgj3LD^G}tC;$C(m~FgUomx|KvA@z^RayCfgpX&N;h*zX4L&ZeP=B#_s*#aVrPV@P
zl&0HB2L9>0iWXyZA=#m!Aprq_w6wH`{uKQD{Is-dObOb}L4<HsIQaN2S_N9#+GvIr
zHL0nowY7Y;h^@&QRaMn9dEp)FigAufhi7DDNri=S-mR-^Yw)g%^YaFblH2mp(b46V
zm8T~sFEwk`6czEw1jBV49Z%rBTTN1AsCW1F29H$g+-go0^Giw&mU~k;%qNMabL~mL
zil^4q)rEwF)YiI*h_nO|a%5#?CA<#hFdE3HvfmP?cz6(5q~BdyR@S2FSfCUi5fKp=
zmz^mbH90yqrmd~L^ZjpUrz9QTRF%DXXfT`0u>~}TuV25mNF{ZTYEQQs^~ACn2NQAq
zS+E+;QEm`a85|tsMTXsdM9KN;l@({a^U>yWDk^(hTkKmqyX_27k&z4Y^GZre9f`0y
z{8y`k*&W}bk~0?Cqt=#}1w};oH6~9T0xebtG9Ns6pjA*_S~}F&sB^eJ!s*eZtk2%y
zp7!%+bZo4XlM_2D>({8Lvf^T%?JgZ%T{i1Q3B17fs;Yrlg(W55nRUhG<m3bdZWILt
z2X{64Ka!M`jEjr2wYA+?U#Fv^gB|0SShGzAWu(^?4|N+C8@s-~&cnlV9|I%C<1QJi
z<*cB+{SjP$WMm{4C+8O;uD*_r^^O=8L{f4xxxKwTAt9l@{!(Efvlr>jn>P_&qEb>r
z14V9<lAXspa|iqTUS3|4u1D&y>WUhUx81EM#KI}W`dQ;T^@>JTX<r1)T5xuVS8LEm
zJ@bKnG*Gu^RY8>gyEsY?$2YNCiSFCCZ+KFkX@>F4NJM&viGLIq(E~T(B<g@BEnb}u
zJB*1|Iy&=_w2E*)b8>UvAd$r-CH?*Vz3xsI7JMZoC6>7~k>VxA#qu<`Lb56<D&>As
zG?7pius7}O?TeIh;8PHX_+9RCBEu;Ho8W5T`641{_+Jweh`T%l$)VBc7AVPO;+T6!
zG*M;CW&Sf^r^iZ_GlYk}epFOcdV2aWl-Z+dO@)}Thf;!X-@bjvaYs>65if9IW=0n3
z)5QfrmMZ6;*az1ZQ~Nej+?U^sJuWvlR}$-%WIyyyxQ`B+F%r!)76`ANp`i!p=;D%+
zgT1|uyBN5yy>FtT)*a8@i%p9;_3YHEs;J1ELRnp1rIbz>*KUDbJ2Wtmk)N5Dr;yLP
zeD$GLx#M<7_PuZlSSY`SC&$kP`)yvo_Nc0IMk2jLDXi@5g1>zE;_siCogE>b3M)}=
z^e6IRRQq$WhexBdk>b3(yyv$YH8JR;0<q+%acCmZHCIj83Ei=6Y;3l_b>M5#MBcf5
z`~Ca(C1qvV_AI@u-@ku%-CLBz3)I!tW^p~WDNy=CViir`aq^8xq$Ra+!78Tvramf3
zm{=l(m<u^4;Vl6hd;7U83CakJr>~0B(uApTX3^8_(N~x9va`n~CW5lre6VU6EGpE}
z^44U#aD+~dkJYLjuoJo8)mw2Ay?pudT%c&gMD3F+9)VbRjWOndj<aI=^40-M@UtDi
zRE_V<3u$h)Gh=vNcca?hQ{x=}C{GL{MH~z;Qc<O!o}NP29$%=`?<R%?U)n>xdGi~c
zveoqO8!n$Kte0qT0<>F#3r0-%`Ri`q!z1Ex!18+}`m%Iqe_ujUQddQ(qqEZzwO*Uw
z{K%vpD$Lfx!objw%XSs#^4!JM753j|nY*1`X;D#8db&Pr1v|UL1|nusQjdn2cy9Z=
z<m8)V^V8E<Po8jD&5ItO1a|7#+u1d@v^?`sqEm2iDEIU8i;7Yd7QRyyl$mLWMBbDV
zR8@7pJU_WE1Ux(#83;0ceSN6OfPjGGV~2BpsTk&_*4Ebg`Wqp*Z>6L(iVb96zkV$w
z)YOyo=JrhiOH0d;R|eA*4_kfj;m5|sVL}Ht?E4vr&mf0$FzLMI>*oh0oSvHMdbUx<
z#>R#tl&e|i*7o%UB_(BMX69I_X?9lDpBFB>tyKN#()tBTy}iBMcI&_KQv(Cr57vfZ
zXfrc2vzz?unVgjB-;d|Ao^)D!X>Gj+TQtA+l!l8dh7@6Jyk<Y?s6SqAX;pFF7D=mG
zYC?w4I#?Zi`;D%(tLp&<##0Wn_}8Szhhyfj0ez84Y0X=6UN0FK(hXIpaR{C~si>-g
zLhENWH8bOLJ9l{YEM;+Vv9YnSt4qp@^c#a_LPW&e%*;m<6E!)x@NeIsl#-K^5nj>U
z_GZGu!s_Z1)sB17dINv|ilU+U!FYm(1uZE$`mwZhw}*#^>)GMV=yuJ~BsUDucklWG
zaB0QgzMU8!-<+&*K07oe4&i{g3mXXfMn^|SWo2bgkBp|KCSG8P*+k{?@-pDae`8}U
zjg2xmO*$p1sSC4BfyYTy<m6ryV)RjK^YilR>fgV88yXyB+kTirZM58z<ml+g$H!N0
z_3^TGV!{=gJJEwBXvh^66?Axk6k?j1Q(@0UtSZK#wKX;h1|%Q5T#l9)A8k!djg0tX
zIjy8d(a_Mmdi9D@D*iK;N|~8D5{b06J@{ROo<JUu3@G-@aL>TV$SK-pu{&`JMmc<r
zgGe=c`{plC6ciLTHa70wy?gwJorQ&v&FE`nB-HeK6_wH7*@y>zELQV>vla78i;GEp
zV56;XY(SZ>t**kN_VxDzl)y&9fPeGpK9~Jwd|ccZ%vxh3BOYE}_p6Je&z}+3RZ5ME
zk1ryNQ!DUyVRv9)09G7sL)oMgEjv3q6hx=q65PVYMc5~KDkbQN4pLHGfUBJJza&#9
z$^7f-Vbu8>+SVqnrhL6cA3q)#8q%nCkWG~n5)|xVH8nAz!$QEP2i)Xm{*_fyL{Jd0
zK{$o7l2SC>f4!m?0lVAV+Xn{=dneDIKVMl{p%7D1R_=`B*jh?-hgT{9@BstD+q+?<
zKmANX;9^`lo^xkN)%+=+%VQ3mj(Dz!v=t~5v(e%g?ChmSo$Y`AAd_UKks7rwj<T|0
zum}YOmWGBaPy|bzar%aaFL2N;H<GfmtL!#Lt(Urjo^pR{n3>k&!N<o>J1n=Dxmin_
zNtK<QO^AmFh-RR#&&$}*i<Fb73rGOKF&NB)-j8W%vw!_!L`C%m1PJdwE9(K3e|dQc
z|A+fiW;Oxv_jnEpotVvN07@G0mxja4ZF6(;O!>BPycpJ+>S_Q&&bMBZhb{M|z752C
zxqEQX+1_3RAGWlV&te+ItO9zOt&L4_X(>HGGg+;p%?WE;+ZyYo2U6o>V^z7i7-&C2
z()Bym78ZQ5+B!NK@iCCp3=HO^uAw!$dV0*gxX6sGEODC1-IH@-@5{o%!tI+vvap^A
zvS-hp9bmw1iB7=rMS4a-zuJlY*zk$W$84&$v$2a4dpz+omXW!6cSi>+Gcy67%W*W5
zwhpthk<lut?R{N9Fs!W8`0R?gDkU~6eb+c!y=rJ`%KhT>0FlIHy_ln1q}LMsv^|Oe
zu*cPWg!FbW^mLe|40Y#LT3WMEAy1z^-EqRi43Xx)uo=vHPfSd_Rd>ZFfCY=F>3T3Y
z)8N+<LX!CHTdC`r9kf25p2f~MR~Hx9+IH*z3gBH+-$u=1VJJp1)E*}blAj#aU73FP
zu-*5T;o^8M<nZv2fNO#5%_oE}GL6UD$|{(cH=x^Kvf42wCdU1I$4`bjp5L8sFJozD
z#&V%8l10CZ6H4*ytbJiuy~>Wv2cR$D_rXV)=;+Ms?63e9a&mppt4X4taC2AP!>6C7
zHCpV5!4Z1OY4Ia3&ul11S&g29jqLz>0{}PJTyo}h1H;3K-1hWcM!LESUbpW>4?R;<
z9G;z>eI^nN^GGt9Q2=$pH`L$X|21hjd`xHOD%f|Y{7;@d`3?*iKB1?lXK86ECn`+4
zppcNMGINr^rr1}us~6$9IXOJehjd7T;XHLLbzU?<a#=OCalp5H)gc>WWq>~p{=IdL
zmgO%QAFr@pusW&tMuXbd>rMbT6W5u*VXk3nx^a1N2H%1wpt+&LBmsJPk(#l$)U8=%
zmz$^#`)_P?^Z^m42g}y-a&%;*FQKfLw>P}CR6J)`Z0sw?U7bbtkJ{Rg9zBW(4}VBN
zV5F~471eIPH5r8U%K6Y_YdL^I%wI5BhB_xFXPbov`MG5dN<07O&-v|{20A=iI=cIc
z2>_nO#Kd4=0ks`1HspK@B<`l?G(00+>bn*6%A+F@gtDsYb>W{LtiiTunejdS9r7++
zYH(<1vexwsSdRp{--D-e(l_uGot@7-QPF@A5E2l?$H!wKP1wik>yvVFzND@E`}c2B
zmhAywKww}@2z+%0`ae+C{hb}<N*hB3g&}A%uuFF&Ns3BKgZ=$0faQvceughOZFqVU
z#-_oWv{7&y_EEfinTv|{0BBNo0`FK)4^|=~q=g%H2~<cZ*&B;C7e4o{crIuJr+eM}
zsd6jxtr2&<e%qP=5lVXF_s^u%sXg1@zt#T{6_6(wrqB;y%fX8U_Umsu@W626%VvvB
zgIfj!01J83^G8VuF2CJu_h~o()%sI)G9UDN_xvyjKS@gh4IdmV`St79ksfBgK0X<r
zCtu4C#!iEdtHCQlck}YSqa($Tvw15n>kyq}axYSgh#&GaO)ukXsz`U3gSTyLZJkMW
z+{UIY>!FmiLW-vMPCDqJ6Vubv&ou|VL8#ZdREV@x>xof3L`6mQ=@}`~w`?Gk><3nC
zVQDFVc(16KEl&ei3{^p=SsP#RrBQ1K3LPmskY9KC%Kg#>6BAR7wyCLU=5p)j&!0PU
zEst(7IUlYAR#NjmhiZlQorRWRw>f@tFsupq9-0Nr?~Dv;08#N)z+8@|+(WSXdVB98
z5XUD=iF>=d2C)h3rm+<jC#cd(o?#i^z9}TW2l(L(6*f_2kBuA|8A%Ziva+#hEHDRj
z1!Mu4k(`Vq#o9mqI+*_o0EKFq*-XnC5K9$R)uRfgh;DBC&FQ6=K0U1wRL>v!%VkQu
zeS7czeO6Z1M%#!}jbmx(WnrR?I=1`Ey;4$AoY_$42L}hNl2cGW{Jng?8j1flG@zE*
z0&xV;%*xN7m>I~z%-pEObV;PHt`3AAM1uDAb{HYpNYE#s(1wSHw=N{tWo=NqDI6*d
zV)Jrx=%}e3E)Is5I%4{}86{z29Pq>7YEeUhhN@lrU^U9m*Vp$oDW~1K608ouBal;o
z8N!DE4qmQi23HAeQcrL3Hv`3Z*nqU_*qpF8*6QY_Lfs(DrWtI?TLKQw&U1Fbv9Sc>
z=U?i6o}8Qjy#eaj+1UwQKmt`d#QYVz(Ezo(yE~B#<@4vjlM9sSq@|^Sbccr{`)!1U
z0iCc|;J??_P7$R@Hmv;h%VKl90&d$w|Hk(AzzTn$-N(nr^Yinc1<A)p)!)Cj1&IO{
zAs~4mn_2Hk;$LXr+d*H%Jh|+vbuBG-pxQzAFf=#Mm&>$ZQBB0Y6W9bSsMd1sj&&i-
zEcj7)zy$(kDMx`e34e_daK3%}wnS1)Y%FsaN(4gc5N3pfB=n$=mK16l4vw<4v^z&A
zl~q+#&!5j|M@B^fK<Q!Kn3;iQ<JnR%S#H_T+UlR2vAMYkdnQnjJpRx6NYP+otEK4t
z>MF=ZTN70x{Wbyuo=&FxHp@NG<9JZgM3lU+!drC!u(C=T8yYg9&YV^Mi$1``#l3Ok
zhMt}tuy=StSTpi4#6;chdXe?kwRB+BO^;NQ#H?;@YiU7ic@!;5p>>lE5UW-r0-y(R
z$dTy82`2wCP;NkQ;S@1|*X9y|`9<pnBtxxh0(^*(_(YhBc2}~WhZxgco`;x$h6bI3
zVDH3*h!F<9+xbol02&xy8vu6fH^)bw-L8H@Jd{Px&+iVCkLW>5N5>aK920YMeJ^`x
zlR%vuoSck|jqlyM$%8KbJtE?f8P?D`hEk?{mdHQgl$a*WtgJdt9Ml0uW@d|fC%lJE
z5zONZy5}=|lfPtQ(}1{GSp15Kc~TpHT5%KO{(WM~Y=W4c8zMm<=`=>J0BE>>|Ni#v
zl)Qq1-tlqJHUTlgBI-Rye(qi}{+a%eryW2#0HG!=%aGDgv{l|a*&Hs8b8f6YSd#rN
ze03EST=ev2$J;a63b|RCnJY#58?rOp<WcRqr()32h`9oYcf>qe=4QTyh(%D6UDGpH
zSJx0z;>EYIk&(7@%@|&!Fa**hVyr;DN=u`J4hGi%($cKyb~)=o&31uB1rW(|NkIe~
zJ3F8R0<wX@L0m$@wY4=uZ0zfyT6MZ%NnZ1Ac?LE~eSJMtNLN?a!otEuwd>02s>=KK
zO<#Y#Dp2aE#u%EI=(IV@sM1WTsH{{_RAgxd1?U)rFpX*@iifEnK@1E`KU$ec21*+f
zNghT`MTLf$2LRZ@&JHA^>Zxr$xH=+{LnZ0{;;1NmV)+Rwp04|3Kjku`zu`-`W@v`6
z-n(}Xx(G~M_?-Egb(2>n1d90@8`#>JB8nOI9=;;j52_0%K><r#t5AcQv<~|61sDkM
z0n0$Z<bok-bvMYx<R~L7E5->q%=Y&l<^bV=@_P{g{dH$=Z><+I^#!Y>v$M0Rips2j
zo~Fyr?Zj?io3665y&&TG$LU|3pIi8S&(2=cPjo%pX(3@yuPjbv-O+}7c5HhqQhczl
zZ}-nVhH1}L=m-E{K(vI7JXU5d4a~RN!P3?B;$&~hSu^dp^><(2!-=Jl%^i@HK!uyF
zA7zz1J2`Q5b|&Gn5~RbM6S(6*cRf;xOEB;-34kVm5a01j#3xiPvoVGFu2=a~9QsYq
z4?xU-Cq>b#%h5y<vYY%~i@{!4<#_2Y*!L`Zwc!?9dskO*%iL`=v^kC?Y-B=0f`o03
zT&6*68g<*>zX(NBt%83Y9XS~ppGgs(uRVqt^@BL{9_rtT_=7lduY@hj9=EZ!Hnt>b
z=>hFTEWA;25kVG^yp1sMBF$5)u-X`911$nj@65+wR4y53XKt}@J3Bj|G{>|&p!WF-
zT3wvl0@ki#c2aA&n2$-$09HFr?9E`cC>h0f5aAe`29p7RE=Yc{v9S~n#k95O3bb3I
z&9PWM6E0!6ql4mx|J~pJZf(llTQ|qQ`nEVUHZ{SR1~cIc3I8Ra#Z{5U!DnUzzh6x2
z5mNdR>oCX2P}{)lv$NxKzvR&nlf@ChTD8TO?60k@1zij^zkARa^l(7cz>b?Jj6Zw`
zg@s8-Ff%sh)^7gt#_z#QY0cz><U{{kWhygbL?9wS32>PF`vn)4@X9tTHMOa)&kAG@
z*97K}mWIfp)8`*eO<z9rx9~iAeJwlx!GDa*C@FbQinYA5GDDtf=mctlL%GJ5D{SK^
zI%O}_QD8>Ve2HhWAq7r?iU=~i3wzG0a@^qhaW|)N59g_n6|{n~G7eT&IvN^4ZM4+X
z8Gy!eb9KcfFR*y+)(g_Q8#42urBNaN{P~ld*m3L59Y9o6R8(bUWg*18qdh&_o+pa@
zJ*cfZ%<OTzZs*6QW2L$}I@4R;;;F!D`}+D+Ds5g6^MA%d$G`vq_5mhl6ew^N@hfGu
zi7_nt&=Z^hmcC1qXl-jtHhe`%*$h6;NTKeXJ9o_ME=rL}zg?GTBC~RHJIBY*8!-88
z?Cdr#1^_v$$jC4n57B|r50t?#e&oti$OhOwh>qOc+@MVYE7;l!L92%LPY6;IC+FV<
zD-sftaEif1se!lUNBV7a@(K#UkD31b{R{ol*}-A@0LGrfG*@8LpNZO<cfZ5X&4z+M
zfBrB8@)W`2$BdCr71Y#B3=ID2yib*z37$C9Jt&w7`-M!}p04)>?D`6Z7_c=^0Cuv|
z5J^nh%@&+QuvRb(fWrqQgNUG}u72XeCl>xp_zSQ{SRfd6peg`AyCneBeU{6|Ft!=<
zZMikkdCK7MFb4+*+MPRmzfQzm^Z6KhCx<OuU28-s2sq4$YE{9n=x5DMNh#84eF#si
zPzyG<J$BS4#X%P`Gus3;0^UhT7KSA>)Z_NSfr0tO#kADa=U9kO51u;JjWfH0QXnVC
z3{ZqPBwd~cI3x753#pj26;PBw@n5`AVn53&Ij7iX5KI5!1rrAcpdUq=NT9aC!NCsN
zP)|U0>7%&K#zCEj2Rq2efq~b!c}i!0cbA5a?k9CySJ!5wq6QN?d-LAdOc(RPGjQ^r
z5E9NkdO=TrxVQHPk(u7Z?F{%8)<lLT6680BAQ((tj13?!DJqu12<t|!r5A3fYps@`
zNqys@m+TJ<3xiqVuqw}!CY~w>9}UpZ^xFYY(agc*GSbolwEsp{UQ|@{!v|92=VWRg
z-pJRazq`NHNLOTKwRLs|wam3HSn(u(N;3>d27f6qAYg!B+(*XVzD$V@q_G5M-2nJJ
z#7A=P-wy%-dHB#vGY$hC9kg-4rLGCJg5;T5S+P8hRv-Z-E=;LfSuyWj5j&NB0H8NA
zHU_&1*vnkGe&c8C8t1fu8Ie^#6R$tgC>`Z`U=pCBqRko7F)(yPfdk*x?~1QCS1(k8
zujG4q-Bi;7l@nw!*p20_yr3)sNui|t<hFdANpefz-{>d|zX*zvfdLz+ci3>V?g7EU
zZXjKPE|v(pDKyk0zX-f2-|i*z(c;$eaUQsH?cZK<h7k`^?=3;q)t;`>f;<Vn#MN2d
zRf^#$@M;p*{oXa86q{9Bpr)IQ7T>k+*a9hG=8rF!ez25(ySrPSy>|Y2-b$4S75bc#
zG7UygM#i$|%tQkgx-U?@`{?KaU%uc3Hi53^@Wm0R1-u!&OPXZd5Pa0reZz63+=S;K
z{7(+`RWV#6w?~u`N-(s*`T{;s%LgbsPqPl{0en*+vpX(FymFh%%YXm=jRryjtU*i+
zbm&IRDr8bmd%H1+3!pckLB+PLf@kA=nB%0dliFqC!OE%_la~i-x-p1k{Z!E)jc#q3
z>+25>4W-FYXJuzYe@sqIjZ91oNo<AI2Y2<F2P{|t_+?Nl_sAauVHHFu5)#lDHW?q?
z1EPI?e*XOJx5nmXP%trg8m0|rb{ybJd7BjvULOq}_E+tMH)+j`MxRiHQ*_63Jt80=
zz{O3Kp>BiO)7}nUsrx%O2lNOalg-V|045D}$m0eE<au;7q^0w7b2k7_l;5R!`O>uS
zrx>k5PDXxy=))Ml|CI$`pr>!16L8kixVZNjOI%6{m^}#H*qbCKrlw8l-7Xx1WuPb#
zL2n3YdFSpL{sKLxsOV80*}&u^F+M&A2s@uYf6mLJ*ZVCdA|hg7kdd0ItEx)a|I%V(
zv}AgEdRW65!%zI!_XzADDC&=YZh^rE!t2{8`d-%DgcFzm@B+Y3LE%-aabn}-bb#ew
zeep{vhd5F~NJz-R!2tw7>ui-@AL`+0gCbh64Q3Q)9<L7maPnk~eEClG@ZYCQUeIX3
zU>gwWe0D7aLAxk58l+LXm^E7lNejgPe6@-~Kw-7D#P&(0B_&NQEkMe4PR=VUU!8j)
z4GlAcf;z$N9UmQyjfl`THH9A7|BOmmSs7*qi0RmYO&#S35EG&A(kkX<B$6VRbIT_G
z2*`mU*P9{|V|)NS1o{V*gm!@v$aA2C{F(a^-7n8D59J4o!(+5erh4IArhXBbP0aAI
zU}POs##wwB=y<?C0E%y)<MCe}KcgRc!lDPjikRPx=;$>t3wqVkFP(ZYgJ9~g2=!3$
zC0>DM24HY#NTEQ<#L&>+JQVIdFeFYTw}nVWu%SRGZK|H}Pv65s_bqRDuc_(Y6o3me
z7!8wHhi@H}I+$=Exii1xnsxzm7B;X|g_^asHQXG~)j)v*{oP?l3lsv7Y-WtLKq~`%
z4zL>FQl}4whtXX&q0@IFsVsi9c<7rx`O(5BaBktD`h`j=J|iW?8bGY)5}Jp8d`L)l
zoO$gDAj|!tAY>9XJw5EMusb1VK5OI$V$-bQv3FQV2ngC1tSnuAWU`VF=N&2JYq*~7
zubc(F(JdN*d&duc&XzztYQ0`j)JxTCB~kxl4wW0~GbW}TL;d+1PPIZAa+%jOfQaY|
zRilxC!RL?=&0ilp0T=Xt`IO1gre1DAMos;9bd;b@Ww3h(dVd#)HcJ}h2yzAn2B-{(
z1;F~jjqV8inxUwjc6xI{(OZ9u4O-|E2oYpw)0$10nVQx(9niS>^-fJq4Ga_)7KZzu
z0-84iEe!`pURgPF#P9|27z?2~8OFj!!K2>({zr&g&;bBb!mM;~%Kh((1O;L29bR6D
zQiM17VHzJ2?)cPcc3UmRRM00Xd}o272RD_+uCyBijMao`;Uf6M?d^p!qbO<`Tk!V&
z{<`};fSEwW0|b-79?@TAKg1z)ICWv0b8maSs6ogH4i4}t0Gt(S8gg=8Qz>o%CpV_W
zv?%}Hk=6hWAC%8ThWorX93CHoEk3B}ht{3LcTH>ksDggGg9RBx#8p^ayl<#3*G-D}
zm0<RtTn^9N>G8`y)6*XS7l8;=p=PF|LxF_=SRgKr&ckx!j?XA0W?u83MvLYA`W4!#
z2Z{-7UARbi0BJF>D<^^{p!~M}^1C15DUy8orur)GG;!)WXmd<5EP_vlf_W<n1OC;6
zdAxG}`nf0=-YEYQ|M?M!#q*%t1it3s_WIuS&!BjG68Jw)47r};kvWj!-BY=|ehCXr
zEb8k&Q4Aj2VE-pyWbnB7f1*T>Zz=ufTLjHyV!MV*|H&6kS0Hut^&j2ZX$%(WFHU=q
zUjLJIxq@E+!->6pwUz2%+`UKoU(v~3q+G~X9Hi(ok%13#C_FU55TNPrLcM;u-`2ix
z(;P+}|MS`oc~~@&tN-td|K|Dcd&b`GXZ_C;4F303+_~}p|Iq&{^YnkoQ-0h4QT*9e
z3g~$<Atk!)crHIcsKs3Mgb%{Q-qqiQa;(V#1+}_rbil?#+zmKnaL^X?c)*g<wA$Be
zqYby4#~OGPlnmIrz*xYF2Ze+LWH|l}30{xaq=@_X8{5G(XVB5pgMmrr12P&w0ajZ&
z0IM!^*R3@5F6_f1L~I&~p<kMru4I`PG9!?JWXS=+JGzq~Do3zC4$WIM%6EUn1iv;f
z;oF_c=omaY;O4Znv_7Gt6wpCFuq(m10f2$<dVE}v@C!hLX1N8VCBQr6bv`_QBn|uF
z_nc!fUQVHuvbUOH<D$jgKcP*;KY2X$H93SPj3T};_OZ<y<zU;)Hu{seY~Rqp3v2?r
z<Pu&A8wt8#9MBZNwP_Fb8+lgyVVip_H9sqUZ9|)>QlW(q3A~3nd$qT(M0dk4V(P`y
zpAbqrxDG2UcEd11D8O=^d-EXo-V{l+Y8T9uyz#KS>xC373+S7>-zN0&!-o(0`hL!s
z@CLBtt>=%#!U0v4nNM|fbb!Ngw6hZfL;@6qojN@oog9rCf@|~K0xlH<&X$%IkVp0B
z|Ax)X%m9*Fw)_E>8F<u73k#87zm}JmgFYhp{T1XWWL-gE&xao;Bn0JwCQNi3_|(M(
zKE2xCrM;ayup=N!Myyc_<0$wkH~c4z<!)OKuM<SThEDeN+D<+{NCl!VB_RO;0Pr67
z4-bjK^S(BfZ-K&OU_h+_%XHmIf`e<V7R14cDm5Jgo!%SE%G#RSW;xWU07x|mHAl*H
zN}#KQKLQy6xRrkQpUkeVzA~TWad*FJIsFVvHa`69mXbORdgX1;SI;Gr>P?ii3Y2*9
zu#mt~wyO7}+}!vsi&9gCsBxN`njkP|Fi~l{stUmMe7gY?MrWftC`s_Z!@;S(I2`NH
zTk1}{0v9V+E^|8()N2rkVF+*4o^8VQZ|jMtLVhdqTJLNFe+VA%P5!I%qQu0hi(U6R
z1r7+%fIkj%fW;W}UwD9Vvwd+ig-OVs({c!Yb)x%ag*=TA0z|9B7(Eb<!At=meIW2T
zJNsd3lm?j7Pl+!h!@~<dHr(0ePq`MsWvHudR^&c>m<9p9`%5Pp3JRk|59#d$Sx5sy
zB19L=_3GFC`+$;TmfIQ|eU#n7GA}M>J-`tSZ|seP*jUjnP)~>`IB-3CHkT5@r<F_#
z#@c>jhQZoUZWM!N^IF~6CO46KffBU(Uygf=E6dBIJ~-%2;AMe{<E+oe$Y=qdyhGIu
z7AwEza1@dWmW`#x!}OGuT16u_Jy95d{pKkZ%t8o&SMChlMhhEVGqXwk$AbO)z!$m%
z6(tI$_nMme#>cBI=Y)yW0f^P?w$Xyr;Q;7%V9M<**S-*LDKX(KrRkVA;W}WAeZnBz
zP6Xro<HwKX7?fOG6*)Qg^I<D5K_ddQi=3Q%I~KS|Y%=x1Pq6eM_y-T^1fEtO<+{sL
zTFHJ2G3JKq`0w8tG;4`SNZdgoqKqD^w9QtdPd9u;PyZl)<k!arjwzQth<7{%bhacy
z83B2-eLmmczkh@E0cfH+CMZZ!{`vug#mLZbq{^OQ(gg4ftS9Uie%sZrNl9cHC!HKq
z`=XMma!^MHU^h(_>b_0PC(pufhaz#pX;;*A73#N9Q6YHn+>vJz>=*D1tK6?HGvB4p
zngSC&y<~(B&x03@c8`Zv>O1(01DV9MP(N-L2a1p|x*7-LQNzOCo`gm3{<U(;pi#}q
z#Dq;Iuc%0c7dU9|4silYHC=P_t1j*>m&=nSR>`QZUs=JAhe#Yqo}ELvs(y2X;BvWN
zolRLUb|e{A*3|F<Sc0qxbIg77W}9wc#gO74Y@rQ#_2j*p8quTMwR>IM4x-<_f1iMj
z%73x{E;bF87<83^^h=OzR)G1P#VmZBs&y@&*>G!u9SLcQoo0xSNnoyUZ&kBsH{Y+8
z=x3Fnfc_eL^9G(n8c@-$@o^%Cxqk?TxR{uk<r`!_C&h;Q`jTs_PD67n=bD+?0X~BV
z-;ubw*97l{e#>idQO`#PJa6EaaL1rgU?aggGBq%O`2iuRE&b*9S8(Zp__uD}=r{7k
zBH*^8D;n?V`2ha;ITxs9Zpg&RCNB;JhHvmvdd1FAdQdRX*Emi7F|x1}L4bsB(jRWY
zG8*hZ<$4L$EO{DWc{>J4AXG~w@SGHN^8pWlOaUYtf&eGFfzdwc&$z)_^8{3%`~z?=
z@&Q9C=kpodCDYN?_C}=}-#P>@jX|Y2qozikGGYUY0|Epl?A+AU24J4op#9{>dUXHx
zty|*^&Y)<l-cYzAE>r>n2{9ewr%xsOZOqK*A3OoO1)QiNgI;o;EWlA7X}=%SZRbRD
zTF!!vc`YcNAMZd3!4|{KmlhTM%@WL<(tFn1ZKJ%}&@kv8q71yT<r{Bo;H{hWP(18r
z<IC&oUxq^|96=etrB!g*X~GZT6^J_RIrDTl)^eN+;(%9W)osH`yDCUZ`nc5fJ%UPF
z!Mqy~52J;2-tE9@#U}&=mAdWUdMX&6Jzl+W+B9P^=`a`M<KxrZEbP+*JP0zZ`X4_0
z)+@4XAA)X?lAIj9@ghLW2^HM9Q;Bypk<9g>V4?x^)G!0XmgyXE<pCm044($1xIj$+
zBXb=XeQWD=!MWvcgTD-IVD)<l=KSVn@Kmt;6&LCCaMvo-H#R=oz6+IRoL_^7i#sUo
zo(!`1x0kAXC-V`Yrhx$l>kdv*fl{?zC&A;T2Ph~6`|~Ql{w)TBfn;8DFhtwmQih|?
zTQHYZ6|GreqIe#eoFyQB6;y*i{ItBUN=$oi$GF|DDFUZM=n?@@%a9OEjpqI!&|=as
zRv>b{%5Xm`q@<GMz&{73UJM^+KytL=HWm_CBWz`dk>1{d(o#EcKj8j@VEPydN(D75
zs}1Z1NCwr9jWZ;?>yDJm)KLH~GwTcRIwN0Ex&<VB&-4^GoHV6i68_0KUh!sV96SE<
z@84T;5`ne$K3l={c*gHo6Y!J}d2a&=4j`qg1Q`$A?q|VQyAUNslkA5^3k%owY1ge3
zzZJ(_gTZ0xcVq@Xy^GDPlab+f;X<ZA_3NG69~(^l3@Az_laVgpZeu)0B&(ALwpKe=
z&E`|0M_*m;Fq&^LX@Ajh*%7Ml85yZ?zjC9D#tLkrl1`AvO!@^FYMPieOmu(3ero35
zFsLHHzxw+l45>#8b?>=d$k0cz)VRTFgQhJ@jRUbbShW^tNf7+oIlLvn_|$q8b<i26
z&+mKSn!)_}-3|by#WM<-1fP(^qP-v1&h2;x&1F0^G?ZBT5AkvnzGh>tLb+0OreKrS
z4!HOh1wYf$W*?m_#+gU!qa66%SbQ%D6^(jCQHf}Ej;t-xV~P+a_t9`%zzz0|;0=NN
zN7!=g;iRs;oRpj7TaUn0@67s=zRIZx>k5^eu;7qwr75bnZ(LQiYXg!az5AnChXx7A
zDBjB^n~jX*RB3<D73RWV?Y?Sv;33w469EnPKyf@f+G-i@gG9~s*c<)#53K9yyV=4a
z#1I;iI>5PBvd@n#0nQvS2?LR)^lN~8-`-+pc_N5puqOsUuUH`xMAV#ZR)K^H@(pNw
z4o3Y@-JqrXYi@=)7~?3i<%_RTu6Y^LOykqzbN7)0kA{_1;cHT*T9*?5rNLOQV1;3}
zfP)W8e9TJ@)6xBm+qh4jI6{7t$HX1*YTd;lAw3>XeIsbV?l3Pvw1Qv&sSk+pkb(ma
z4{o;e!Rq^XB&07+8?j&|?-=yNDXcp-LQcR3nFM*T5dO>0SRg%~E~kVL?O*S+xt5T!
zr2{67pTz}lL;^1k8?lQ-D)Ztv$A=YqUW6^lv%MU{t=p4hM~Y_2<c>%DTI_DL^LIJf
z+#6%iArh-9f`5ldspXrVWv9=He;jlciO>wG{dF*&d-~uma#_u+=}+PuJq|*Mxv5Zn
zXVrPI*dGhYicIf&J2@Ive$sgGZ+%x6_H5MUQM1}aUx|zTdF@vuK~j;jZvKUvMwW~i
zZWesMta$>7czMQ4W@N6_R1++%ZPvqDsjP6d(~6^a^!D~2TQqv}SMl;PV?3XqUlM&(
z@qmH0Ex$;Iw>GTlesFl$ycQ`A(<oJfvf(9@8hu&I=Pei@ayY5P>XNanhA_L!Yg(qJ
zuC8Z>8<7le<>;@Es0kSnO<ETKJmH=q$b6AukkPl_(pWV72oe*oTZzmB<iKN;N3oGG
zWXQuveKedmN`wOOW+G`K1N`$K)CkT`Op%)dTn2c6AD!f5wCdewwXOrQ&~118@A>|L
zA_0Up%O?)X(m~?To$H3}J?V9@Q8qQZOasEPI5Om4l|6VV6HYgMz$2@Yp+1Kw=~7*7
zQj3Omd`EudfN4;7^zz)Yw)W{t4$5<(_DG75?Dyk6$UYlc^`d~Ee|TP&aNa^v*QGfk
zG>3<q_w^hbTK8wms6xc^4gMvn7?}ONM`C23`NL><VO@IhmSKT1g3Oe?o?IrRMk*D*
zj?GYBMcGwNs)9*czu5aE5=n*>jXRh+?za4#R2yvP>WrT(>t_2%tXHU{^Ny36PiSH;
z3Yj1lqPIB6|1w)Z!#N+{NhPM5bFuCb-Fwy&v`Urd^Y1S$*{<S*KAPZt*?0GN@h<He
z-#eWA4SNPl`wRhzlWW$wv$F$XptkOA@RmT4H8V5A#>Vb2uVaMhOCStTAVLt(``GX)
zh=kt_mS`2VG!3Ab%keg7W(!M8u%_HxToAH`#A82%7Dk%?{#}MX2BxQCp4y8SFR=Xu
zA(R5}AGjqM%foDG$f?3LfHVyBK@S$&&kt?0dd`9q+))H3W*rD}8X6j4*1&lS5Y`}`
z239?Beh$p(1YYN^M1IKLHRA*V0~ZwZfuEh!gTa`Tl!W$xh#J&>1_lVbfgA-fb(a}m
zd}2K;I7Q{*$FY0^?=mK=o9`?~9Qn*=5;TA8M|$L58R0#NZl_zRZ#Az8*wYU+#EVNG
zjIa`^&S}^?zvdHijX!T}`1ZO{iK@NbK8rSv8{J418+oHkfm76ySnDzFDy?GJN@P%p
zsg_SqP~R(`p1QQtu~>q~YgX;5mGU)}w_|F|?rqJ~SY;6y`b@^K{%L6QNl&qzZhm^O
zAr^aB$l97`xVio<lEaqNXV)n9>8Ho!K0G;BW4*0|T2--x&u%{1vr&5~F+Z=_GQp}#
zA@C#oQ|WG6SC?6gzuQ#Z=viIb(fY=Hh`I6kg~D+Jh>1xj@_kpfu2cSd*9&3}cUY7i
z6X{;Q1UTP$839BP?wYQfQd$}4(R@W90vy+)k?dClCMJ?3<Q8{7gT^>zeta%+ZE1**
z9B6cF6@Wm%ZaP|gru&dg=i|o$z@l#K(D!~|dlP?vdMESwBpvO4)!2)xk-%n5StNjI
z6_CI;?szCVd>*^lP$qt;(M~01R2}8&5xB6xJ!rqGvX>S2Wxt#rPgtE90vE!fKS}TU
zl&hFj1PCHZ0xGeQ%{&Q80-f9TABzxS@#~gfHJp1lCYXIff4`Q_`H@lEZ0M*GH<@Kn
zZIzBrhO_!HPJOVE96|4A%D|{onr0w)slU$n2!d#p^AvGHkJna62Qp>&95%_fw^@$~
z8Kf_lw5HLF;9TCx-uxu_xv|)WhSylJlW~+N2eH&?UHRCCTx6hc>n?sZHu5%`B!bMI
z_FZl8VdS4Ic7Kzcz|?@tvF~EMTsJf^$>b;KkqGq{dEC(oR&|~mtHv0%#n?!UrxUJb
z{#d)eScPs?swuGzv{ATZsHe-jWhd89^gT|hTevmFd=~HZFkh>l7Z;Y&!41R7gAMXF
zK3FV%NxUI{#drb@2*|#=uFw^EzVfWi^USl88myVh(@AWj9*c|*!Lll16+mPf;7n_c
z^u829+^$qQc=YoNiBTZd>4DYZ&i?GOvEz#F!MfjP!}F(f2p_k%ZCo)LR(zWOoKfFu
z*FsAvQ)6oz>8tPfD;h%kKBGEE!dXy`UD)O6OR10QV}rA?XvBb<P*A#K1TcSXzm9>S
z_LxJ<^=QH#BK;}Yg-h5_Hh1Cb!i7nMf@5a2HQn;()XcavMT~`h9pzxVcV<4F*7C(-
zo>}3HAw04kmzDaKjdV5ep~qLKP<?!5JeuKW$b!D}D`?+({aZFOEunhn7bkNMzmH@-
z=TAG{<M58Q-n?){8PZg0oGl<8H5nS@9>nCMxxS_ZhQ@}ga22<zuW$LS0K<nsOdG-%
z6Wa@R3B`j`Q*|{pAUJGXpFPOQ(V3)QFTjs`?WAJzAdnOxC|4YwTovgq`C_Dp{&f2I
zK$Jh7D}{IaoA4{5@MP|J3gllwKW{9fh)gV`lL{SuobS731v&A6p?<9uD<!$-&#5xc
zHd6CD`}7J71l`@q)>OnM(lS&0MiB#hdcSpz3qDJ6WhNWcva7~Pe#ZIf_0#ed&V^#^
z@iJ>Nx6aS72XT^ExpKJ3zoG4mzdqA*afw=6@`|yE3whj?mJYm_mIOxVarGQ3i_FKN
zPk|?H*?z081_q*Djkot335ok-=e7Na1G|*sO*J#ecj@z0LP>Y31sv~f_4mJ!(rbPg
zL$2x&lHGLaCQH4SV*3LP@e3BrgOArgX57+7Xfj(TnHHq;660ae;0sP`Q(DjLDl!6u
zu*`ihSr*nXgztr_iN&t0P15J58;nl$9Y?-qcxw7`mt?B%*7XZft%?<YU{ZNoIGnGU
z2*=PsPGe__bJ(xI2r4)6dd-ac^8LX@U@58~Y2#8M*DX&hazmA@WE?Dw36lRx&aO_$
z{Ty+Xm{WxI3+ah&;5<^q`GkZa{o+lc!n|>yY7L-nb>bujDc{+)iG9wyzTw-C6AT~{
z*7aXayeFNC>CQcmv&@VPhf(G0?-R$IN)H|0y-Byt%Da8@`n2q&f5P(P9M5dC6_rxj
z%c%AdL{cKX9{m`u<`kt|R>neAx4R4Tg5fpmfk%?N+C4l!AyS`WrCUgY*hFoQB43aE
zz!u*E5-o>+6V4mHB`+IH{5TKU-f~|*-$VGk;U=AJ!nZU!TBMX5`a(mkywb>kCFNe;
z-H?0#)v)h$lipGK4+zV{8-BcO*}|#%y;8l9XJELyYklJ)%5MaNiDN$X>%fz}a@n~H
z6N%%qcj);z?@i;`N842__{w&VbGaFAJNY_~97SA~-F>1Qc~l#H<P~!RlZ-+!jGI9h
zcc7Fr_DSCT1GY`JZfB&~La(Yl7P5C3-DtG&p0IPy>9hL&wt+uN{53iCe`L&cqo-nW
z`o^>L&dBcM`(ZAv8IVXb1b1hC-nRRjVW5L;uxhciophml_kO%Qjj6FQqzmM;TBLm1
z7l0)~`s>Y`H?tqzd>+E*@5vA#@{Y7C<D*Yk3+yD=_~4c*^BJp851Z~Lna{3qtXRNq
z2~)1=qwf+7!U)5ntFa@$s1lNaCBJmkrthB+NuM70hb5F&rS5#M9OBQ%-Jf)e4-`6<
z;r8j#AvtU1J9H@P`^0XFH)EnFGdZx++iL9c)Rc<Fo7*-Q--_1a6E@N|SKaztojR5;
zRF2wYv*&fM$JsI*%rZ5FaO1*`!za`qDJcyQWmCdHVSFr4^B$-mcvRrC!n}fHD3H}w
z9r%JYxA8O+gc&mBPm8U0;vYBS<*a7`Q|FElc2J7hwkduvUfysXv4_==fu(s{EKQMp
zsMMd$iWAMVe)ZQ!x|=nJEve(NdZ__@v*#~eSZCIhpR7FdF_FZeyMK_14&#!FQR&HS
z|GyU+&ZMoAK6T9h(re%BAJ)&WvSSy`eVLJZM)b1yUygdKW6U4QGcw^G3T9EDH~ahh
zN+Enr?&h}ymaokvaxf@8)7i0@V<bdGmR1&LGO_#x;d$Hd61tzqrh$MAF?Ep30A@kN
zG_KRm+M1Bd>L;YQAwuAGvJjR2U1a+&bpYf^@caeAy;Y+>GSpupF~?H<HTwL2&(*ps
zGt!_?Q30A4je}b4?|-HRQ_F>Zx9S`63Bg)j{&sMzh<h*`pM@jIQl~B2Uo0wMWNi3M
za9VA}!1$Su4*K(=l<Us=H5D5ZJ0n~5(+9gFfj3w_!pXGF4FlNVgahdxoE8{_w5$7e
zJsKwecXM+HPr~V6@vQ@3z}V=%n2Dlrm?4GO3F78c?pLl`9sKi2&mW4(%YQ{CISkBs
z>1#r=*u-QVI!A1D^k=NXf`TW^I-<(TBOsTvn@_62DPWyKrWu2kMPpm(0&za8^v>Dz
z@kv~78JK4O{k;Hdmd(VJzAX0KUrHAYUTKDWO3v8b-Gvxnb#*l`_Vuwc25|qtysxfy
zA$`Mk8YV}pXWr?u=}xN)>vjKs27IvIsH@ozjbf)!6+}{(hHS64!TPE&;>pT^rT&F6
zt5kmXSGg+R(4z|cq2fU7p!@sfh|&BzL2{V`gBx59c^okk!u_mK?XDkK4{gROb(u%1
zwrU~qJz4)4&F*;nBOK%L{D}od54grldu)-<b3g-u6MbM;K)?m;i>sCN#G!mm%x5zR
zR5Xz^yu25nW}C1(*L&RtYnzpWV{3J_5)27Y6CmuAs3cW;zkq3;uY+*@2R~%0K_IS#
zBU=LXnkmNMde3ccP7V#>J$-8W@#D_F7n-?v@9k(b4w!@xce!z$_f+{X3Xup$%wArO
z?#R7rcN_12UTl56H_7%@<+@t;!}m`9Tyoekvj`%-x6<(2R?Q<lx0(K^e0)1x`_+qt
zL2q*HtAlc!)!FF<o<7SP9~mo4Q(4pYhIFC`WxHLw75{xXf~2qqdfg|uI~{PU6f(Nk
z;=Z*tix9?8zMN4bBo9Dt%g)c|f9wxr!_fHXVtF^T)MSMDvG#x!oS`A%4~_y;J~}iM
zjuGbVq<ExfKm_Ueb6?WyQ<-o+tPMiG6s>UjuDY5B8W{*Ikl~?<hzP@T%4_b4NWB5U
zC9p7v9_arKC4;CmR2M`ffi;>Odbr(vS)o$Qag|?{`|I81*1(-=lSW->JLY4*&W4la
zJ3F`D@R&TiAgWr(>Sz-lMw1L=9Itl?FLQM+%gLy<-BGe9YP1nsFnySL>VENa+bgal
zLseF7YE{?tRPUIvB4D*3Up~o-og?_M(Qwa;u6#qc<3|OoeQ#f6e#CABYG;N=iCOoo
zhci>&3B*;f0YQr}9?pY<P6iasS^4?yU_Ld6kX!*=XHr)|CS7|HU}-@BHb#Q-4FdAO
zHK(iD;OoTmI5P8@L4lp0?4?V_*-iiUBvv<sgF>%tKw`n+n1my`=cjA=px4B4n8P89
z<}o_;%4-V+#1l6i9UVCGrAFVf28X;My}<kNj}QDF2Ie3OsF~~Xqe^rs1VXoe<W>oJ
z2GDm6z-R+Kx=Fc4lRR23GoJAyobt-A-W3NoGh}_DVsC0D9HJ&yNA6en#KaJ&7cMAY
zvVim5*Q!0xRXVkD#+NTK$ZX(P1L)(FR8(+CFO;HHuP7Z-(?I$>ZNk0uB_Vz9=2n}Y
zz62*(b_gI2J3G4zoaS0<Yi_>0JcH$_RC^xlSl9ubAWDnYI`$_b3I3#dS`&E1mQoOR
z{HiEJ$ZlS0>~oFKnAud(85hI$>z&rVx=GsA@QD0`M-NVzhMn{$G0V1QA|>!=R`0#f
z*UZqsW+2+t-W=~=;B@tokqxB#aP>6Bl#3xD)8Qa~yZ`GcaYfd;yabQauz~8~=jCM8
zgNHscDS~1y-yI8oPUuS~wVU6*vM&m&uyb!SK>w#`a`pCdv@zChMAKW9n!r>%i|veQ
z*j2IqBp`1R-zoW5`%wsa14&_eBDFD2HWrd1h+Qr7Ng;2Gwf&55TVBg47OOC21ROh>
zEu{q~5S$}ZP*#D;b2dXO3l~r2t*u*lx;s4UtH5nVMO;H@eUy(Wn*3AYx%}PICC-c3
zD`$;+K|OWh#&zPx5}CM!rtMsI>87XtFdlkK<9!0?(*l3VChM4Y^2nYm8oE0cg>kiI
zhT9FR-^Sx#aEl$CE=p(26!*cbA=fZCNqoaUH`qpMhu!wV$uM--xSo$SxvnnM7i)IS
z0>h@byBb$a&c-iZ5b-oPHsBg;<51Kv4;%&UG*HKWi?AtA&y^Q*C9s~8x|mA%m7*DE
zb-3|FJbY6wbW7@KYA0po{Lg@7c#%vBLqSqN^)FPCe*!PB4X#S9-IC`|KS|+L2q7tD
z|069R`|!3c{4j;2{a;aa)2^5@@*U=o?CUQ{JitbJ<_*QAeL*5x#j?(lmd0;-lR@Jx
zEPUAV8jNT-kOv7xN=noqCol&2&$r)Hs9i#RK!yu`@q#8DUfua_JBj<b<?GkK!7eMh
zJ_|?4LGFW&jt=$l^wFaRt%Aa$BJe`@;OGN{umE+x;^e$_`!<sy`+qbF=G?Wl;e3$3
z_~5`A6lS4rd!9y3z*yq!+}!p1`63HIn<ow_`%r%~Hf;*L1mO4PQ?(bMdHG?I==DLH
z?1N)hkYbxikpLmsZ+Y1Oax>Qs{D1AXd&p%sf55fH#q{cxtWNvOa5eCoKZwcp!4Lyu
zVtPGSset^&i@TVbRkmwG*Rf%cdf=QMv|vXdP^&AD_o4!W6iyhzl0dQ!Vn^;^jR1Oj
z_wF4SipJHQaLxyEX?S28{q9EaaKoVh@zlc7(#@jOfMjZ-o;?R1y;KRIZcf?K=l_hl
z<y&569u!G`i_AZC9BH>{ZY_MkW!R{jNN-A_m&PssBVu@5{U066z|6Rt?Q(aFBtv2@
zLX*4WbGzG~oNcbCqkgKQK#|REL6zI0(?>h^wTa-DYn;seD-opG9P|qLQW@f^s{+r8
zrzK9P-%iF<<UPR%_tmEz3OQB%6p6#TajeeIQd7M!S*OF+8S;WbeZl+cMXG{}VUnuw
zo1-u9bQ?PNDY*&b>CCP;OD@}x_O<NBqyAMYw@&%S@yG_~-jD2-+|$?_jT<f`O{>-_
z>Bg$LnpA4%p6{3b>Pl?F+dXl75cuBwxdO@em13$gM@={5aTmpVuDKix3dWlejye=#
zaCr9|+7hSFDd=%vW8L-oS8l0&Z3Ae}fiHS3aDr}{RhL;rlVtRnp31yp7%JQ`z5T6%
zBR8StlvGZu!B;is);Xzco0*Y-UcBo3H>UfXIX{hLceU(&LZ3*}u3H$kyyEwf5#N|f
z7?NAPq}liz0iW!ElKaU(z}G-++By<*?y3Ic?&_gG-|7+w6%+EA`{!_Sw#74+W9=)?
zyTrHjEACobP!UX6%*Pg06bPpM#hdIO?zLj$pfDVux!C$q!9L<1B@}QKY!{V9?b8E;
zYQiej$%|Ehu`1g<KY?=5L~pybqhQroV&8VF3}5J|=1V4Zr8+w`>c#IAbddD!-v{?r
z6QFIfP#`Gstl=h*wMy(>+B<;(1W+B3G(WEcC;#C%xECoNg9Z^Ut}iOx+qdln+E<l%
zU>Us9@4AkNdy(pO#@e3j>K>r1U5#*Wm8a#EdGd2a;37q%3;k{;Q~wxx^}62E3y~Kv
zo1>+gJDO!%3K4kI3$E;^)Mibx_yMT6xU#Z1xY$@DaXyhgIdRUD{CS;mpU7weM$az1
zr8$qjP%R~l?~O0<EO7zB0C+$!l>%XXIG%IA0RqVo*rR;t4<|`cK0sy}rVa`g4vwHo
zskpc}oFEbjA%<U80w*bXd3acD@7%ieZ)9ZUm<5iBbF#9^lVXJ?fAaNp-RtCllIncl
zM*+1r{JBi42|Y|y@Rb9A60TRTjEugCr^YHjA}fZ;4|3cNm@6SmaH<~8x*GJ5evg%u
zkeG~ZXK5NEW4wO+s>p_vMv-18NVlVP?sb%5VlC?xIYv*qe$+Fdnk*ju`tgzRZ*O$I
zH2*=dT{zX1pxwqieK*JX?*8(-%55f(5x&K2^KT0S)RnO-Bpn%(__NeK`p09Ib{O`I
zdMotm2PI6a#@e?~B6v^UbuXg6c8Xjtkf~*8Y#sMt>WEo0HvI8!UbtZ1U(`+SOZIoB
zy|~G5Yg=FWGro>k$Dm*hc6RiIK3V^>(J}lMzxC5ALNqRG>y*mv{bdx!zCnuI*^01^
zKOQ@&`CKR+8y^dHg;!$qZDSd3qB!>pDF}DuJF9#^(X`<paesw>gQzR#uGQjUF>@nh
z^vv^~UiL}K$Dbf1Z_J~)V8tbX_5bko-{D-ofBZQ7sw8D3NoI(ovUhf}%1km7vR5iA
zBV?6|LXwqaWp7bJ$x5;bMMY$1X8S!}@6YePkMDhakK^{o=jh!hT(9douk(C9AJ4~d
zl}uc8*-gOhhcT7K`<p)t)jpmqjC|JCSCW()QL*Eq(u?npg8X)$E+=1<Ch_|Inexl;
zZVy4f!n3?h>iJ{urr+ZlKZQs#u(sw2TDHA>6W=aq(ANAbKD#b1UG3Pm{hJ$3kg|jw
z#D=`JEOTZkb+=lY*w~*TPrdVOT}}7JE3|B6=oZq%D8K#<b6Y#xJ~8jeRUEZcy*!qE
z;KxU)Yuc%{HmHaiV`fp<p$EYTJz^ZPjk#-aDE468&>^8n9R$(H@+CCn({j&~lKfEo
zfXh;Jq}0e`fd}R*F=R?dBjnj^-;L?{`ueJ>lC4e^l$F&B<bdb!=FOVbsrGv+)QT2!
zs<*S@n37_K;t_^bD2*eHDZA|5wzoE!dOuqigMegog0yZu92{0|Zf$PbR4d(GEP>Uv
z3E~-g?%|rVHqC}@ogH_YUs?zZeqS`uYiVG4`260;@b~Q@S`FFNb56?P2Y>5CGoBG&
z7-Q@>KEun9>*?isT9Y7OXwdZ1+~jjy;wbrKG~vgVz9i+YojVk?*)K)x(;Mz*)cu(L
z_K^Mq&JU!OS!cRi6!c9jItBS%HjmC#m$lIKoFbomvQ|CFv0b-UH(xvEUNk!&*X#%1
z6O3V_KYtd2Qvdidbx<3K7k-$ALPyt~tsj*a1^2G&H*a?IX)YEgwe)m-dSBSbBJugO
z>}ZPQ+`h?ZiGWuwyNkaZCJ^qtsLstA=Q37YA9Q;yVmnn^(lcbOW^eT)*^!CLCH#@+
zt>agQ&qHGF=9=T)p7$f{q=A?ETI7%CmJ-^c3PK6D`eb7Bi|<Cs^CyRiHUvHTp0PB^
zb1Cz;L|W|T>w=OJ9HL{8fEuqDV)zLYB%*RbV-y^Cg`Y07nh~nBpiLb-h{lbXfWe~*
zxdvo6kY@al_+nNvF*g3=$6pk;L<qLFprb=4h^Wlh$#lGZ48n92+0a!Ut((M09+n>I
z)HAja77#EKphq`JG=58-2ltzaDZa<&!2N&sFwKG6(N2Hx*I|5Aeq*?C5#=EUWWfFR
zkdWAp<ws;Y9GY+noc3igdpmxu?%8mwkoBzz;R02ytp;!5{g%4_ibab=ueo=Iq_IbZ
zpLwG_THm|NU&@Nonv`PC47r%+vkAc`Bqww9CB>pTLu#*f6x=_3g_&+M>2bF<pOcaB
z%9O&Lf*o?q6P8vVFW<-=vCh;zzUvNKhVuK~?Oy&bA+_^`BC4@dTm0`A8R~v{aQnc9
zXK8M(!uubQ5dofy$T;Xx(nqvZ-X5ivru&4w%wVu#;_8*ndlsi>d~P2;5+DA4?)n&;
z&9!)Lp>(f@35>e~{Opn~J584g4Cb^tJv5eNTH@{ry~?$K>h5*0V*Upv*PAMYrG0Lt
z%=u4;-S#c5)6Xfq<Wv+&=*Zg&1Pu@@7XD+$b~oIB%s4u_TcQ;Y2}U?@E>WXa1eE|o
z&*e*Z<h4yqz>y>Pzc*_eccr>}5ek8W2Rm<ef>RDjtgP&FwtJsGeZqjIEWr;804xF8
zeZdmptdg#_kU^mU$j$tS2^#Gc73t~U{;*~m9UFrVdmD5aOy(~0>AUQ$Er2N)zV|FA
z%})v32Tfl?9FZFvK4JN{m6U?R1p|Kt-g$3^$NV_tO04?RCr?UHBHFY*_q=uM54V8=
z!=Q)h=!|OwBRkatJ-$nsU1Wqe#`F>kUnehq;*d5HI$!wbtATi@TxU@C%_V%8?K?R(
zrS}it?``=|6H-fjUWU0x`7-#@)Wv-jO_?~PEPC!wrX7ORXIB-!N!N$s=NcJ%7a49c
zC;AvMMe%i{>Wln{pV51&s+%2oe)7;q>IOeM`U6MO_n)+qV%>M_{Lu{M8<H7RJ19JU
zJ^!4ik^dx<EcFJBvkF;2<CibXb93#Q0K<4roUn7O$S|j7h<PngSgxEmTJVSLOsHbh
zON(I{bw7>FTe>HrxI--rMUPf65|}l<1}}ZucS6&b)PMaDWtJY#F-nh7x(CtK-}v~W
zU-?!UYRX30(yL1(zUD40Urxd%-ZGJydZjzO|4`+H-46nOZPvjp4J;IlC@ILuo`J#&
zx@<xQ)T}sBjbPt`f*)Ir+fjRfP*84wOG6;UG@BGzHep%`flxN~a2!G6gAo~c7#r{f
zfH%Z`a`FeEq3u&=9jTn1XTc|Ii4{K1&3%vU9@s`^^gZQ~^}C53#rEc`ABM8L_x|<S
zBux)h%kl8!q^4TdhEPgIevT7uZfdfFy%H2(5}xy%nP$+5fRh<UFBovyhS(0EP|uVw
zU_C-X8rWnx_{QxNm<XJlmR+wd5Y3XBo7cfgsM=gMPW+rFy*y<8rJ>j%(a-M|U;dUs
zx$xahpXJc0&oMu39}bY0WjV55wJ~q}v(k_vc>H-TtL;Iv?O!WSj*{-2U8haBCyzuO
zSWx|17$Gk5AUu&}IPOHGw_?WnjBljQVB3c`4KJ@ey?U(O!lS-DC(iKu=b-KK2`ZOg
zco5$`tfy}C^dFk~VL8w55X)pb`;mLBB{Q1N_{c+vrx%Z2*jb}5!@D_sdKZ<oXM<(=
z-~R1qd!X6CY}5H$xgZ~39)L2;h*iRw``)-sg8mb~=pw@~6ObKY<GQ9F^Pq>afMLXp
zf>2Fa<RWCgKfJ|#W3zp*p<5@Ikq}^_K2^^1ueyUtH|U+9Lr6@`w!EHB`-9tGq+1rZ
zneD4LeWQE7P!vvV%g|{)x_Kch;%>T~$}rtYJJacXgn}ODB+dMYLh7X_sVjc>bw3TJ
zhmdLnGkc3d34iX<>{Af4oKd`Db0x2xhG4riWp!l!cQXK5fFjNVe-~#DpoD~G^E8?<
zhmfh4w|dJ#8-nK-+&ZCmxHed6sH^*Nc#g<bsRkEvbNw~f<${o;$mVNL&ufL<^z1xe
zK0Nzqbmdv=toa!Y3*PJhW=w#3jE*kPFyCCtQEor6HkTWk=#xV+l<)nIM%JK9l0oUM
z3mh{R7hOB5ZvJUw2hUGzZ|C0-dI7T<P=rt<e*6C2G+{k(7kdd5w{VWs?(e><0yZYf
zCI*TS=&NA<*Hm!*p`WeQv6DNk$bK`;=*{fE;d8dXds-(`Cv2)bheOML-{g}m_k@2A
zA-?Obvx6*zE5cQ_@z>Yvas&6qhnvd{ofPg&@g}1feCz$sx>iJ6yM%Xea8M^x<kTs(
zWNpxz*H>1aJ*#93agqu!|B5FIR0%}aW!B3a&5e!p*d~Dj4j5D4FT1Om5#=KApw7!`
zw`8HV^p@q!VcF3@<I8_MSw5v@)#*Q2aENxV&-r6cH5gX5b>YunzE^sj|4vyYnQ-Ss
zWWSA@+-8}%TH~{QB$>ZZapjeAefm?f6D76_$3CEuJ*-UkxXF@emGqzvVi+M|VF%A8
z4ZfJ_FK3KsX=!Ig$q4K(E*w0p<SlPlz&*%LPf<_KLH=iQazDMm3(->cAl26n5c6$w
z(bxF3x~tFS{iUgTt?Zf;-bN{>I%gUZX70rFA>biPn#=XU>|`B?A+t)(-qz73epQNI
z`4C|B$@)p-C3$asI@=Tdhnep%o*CYC>dGFmc&Gmy167`X{rhQ&o{6d1QV3LVkG``H
zP$&lc+BJI2r+~nAiSyEd#-J}NkFH5(tn6Wyzc;M8rq1-`t#=z2nu*=JmAvO}?xWLu
z;ZyihHE*Py;i#zF)|?+LRalQao6WALylEyE{<{>By5<uGjGQM$tv;@`2ADsSwfdO)
zg7{_oTwk{U_2K`%;sW<|%C|p<K(_2P8Ey~0_`{;2E;ci8lhgh83-K$N&U$wI_e1eN
zC4x@^lmM&{zuN1y_x&IL=yb)!N*8Y0ebMKSMV~jVAcb0iG%z_o|Ivl9$Nyba$(|=s
zQgu=!3aXqmu*)J1d~aRtMSC$#CsQx`fC7+lS4p?>gT&ujHxQyjd^pevLrVx<!9c1Q
zOcaO9VY(OJwY&pPGk`~}y1mKo!3t7FhAXOXFrd;91~DLOCCPYmMV}vc^#YOf^5x4C
z%$fk1;kW6nrZRUDvaw(Vb1N&QlnX}`^U1pdX=ka?y1|6e=@Jvz&<+3YUU}yQX3VY{
zy!ej*O;dx_zcsYI)q7<gPPM>mE^|fYLXr=HFzZHqH}rl)93@Em#*M=Ke0~L0zL@p3
zH2~68!95UTWB74C&5PWrl-#~l5)?Tuu2EEiUm<fqr3k69$JE!k0q1I`zM|it-8ic}
zJX6@$oF82>tS!5k+JCb-uzoz%EI0G#NT*R$n4J@E?<v?GVVMIo=ZjDs{KIiH(?G#A
zCQH}vhZg&%Jr91dC}irE<=$3G)-Ex3%CCnd-<2LFA_u;xsH3;{HD%ojbgoq!^J=KG
zU%h%&R%#Lb^y$pNYb{Qi9fYVR2w5kvQyX8}Dk54IW@Xu<M2(|G;|`Of9-kqIH!tbw
zX~v0+FRc$j+4}jJAmC;qux45j=@AR5B)CH8>mjY$e?<B#M4o&x&{CMZ^MZ7oNRVd{
z>{;o%-sk#>b3G0YykPsnX9cB_X_b#5R)X$Hs1OScn89TNyXBLpDKG6<_lXSGpS$FJ
z6L0o%{QOkaL-=8r?q^+cYWQrm8&=~S)%&Z3Mp3y11=^Xqm;_a|X-%43uPG`hxYc(Q
zh6Li*zS*ALeM&~g<YY8vDu)O}1F9?|Lb=zHy^qfZ9y7cw2n2RlaNH=F#DES~QySaJ
z5P8kzH&V(Z>&yhew>LI)?@ZTdQ{I%j_4fyiP_*L3prwANDKpCkXbmR>Y#4#MC;7~u
z!_JGJh+>gQdWXdH^@-5@wD$v!GiR03bP{E68}Y@!%O~Olc$H8Dp+-av`Dc>bAT;>b
zso-CJv^;fLOjfA@Rv*&$y9r%8_;bkW)iH(p{~ltSfd38Z71W-MmKfqwH_QR{+f7RP
zC0-mAs_)#dI<jPRvdT(ICNLk6miB>(0-6)cQ7CD?y>WZ6;R7_DsQm~Iac!YtCxB_c
z4WlF&%%Ir<^H^i_QCOG>+ypU?G&6f)lnc50Aog*n7D6Z(imv}uh*gI~A`c{OU+^pO
z;t<$knm0E$p&S+fzrU@m4TALgqbxFBAc;QNs017dP*X_j%9TOb#_pk@7x3HK$jUk?
zw5!h+zR;LDDERha%mBhTHOUSFS@M}cQjBhP_-k`Z<A??4RMB3a;BRgK)oyUGlC?Eg
z>^vxiD5C*?CP=#3L$v_PHG!Ii1!UAO#IfVo0&`s9vG}K|oHAaEkP;s!hfUx=NQ?>B
zA?4ERzXJmGLnvuKe=a#Fsuna-jeZP|tqDM=tK@y2Q`BUxYeY6_|0aJ-v&Ge`_%94w
z;<k=kkrE^mkI>SluKqjw67p|M=X_-4q@^oC+G3{KL%?7<C1v=@iHoq)WjJu4y}T=J
z=Z!yw%+0*}xe~spWk1<b6V&N>_G(h3{_In6Glz@9LGx#|vfg=EIaXdYe?4uUbUU`8
zD2ac(=Tz6lFC+0zzHL8W-({N7eH<Eh?1SMLxvZ3_#HM3a-{_u{a5;|2J^mEQmH!5h
zb1`++Cw@-6$>nDSk*Thy8(L*84Y9$0;Z5ZxCwKeb%-m-j@5Pgy-W=Y*=a;(eT6|gf
zeA&0$sdvXaeb-Y??^P1LDH^NFW^gO*tItB9reAu)SdX|bGv`RJ$M@Lx->=K9*lJdg
z>>-E-<ntenbvo~|Jvp~pxu*Yazf%Zo2)Jo6n1?eN))tW~3rDd~MNGSswMBfNOJ`s5
z@e&*InheA>X-VJq4NN_Gb+lsV`*e|vAyy?h+N1u?G!Oi$E<M-f5$t>BzH-j(Z#y$V
z0Dt6reWh5@fbUX!Z`zR-pTPl#Yfl}FR;9A*ms(wMOZ5i1CyR#XqIU}REiM+X>TQc`
zhVu*R?4zq&SA_Eurdvc~k5i{QJ34^lo0>NC7u&!n<_k(DRL}$1rW~Gg!RQ2pMhss8
zyr6;qcw?iq?k?6NEN!rJ5*;~K=YMOAGGGq@&<WYtK^huW@^7H>L#ab`MA|@4kB)}s
z7vz$Qe=cA<@A$TpKoc6ob`QUP=4;_FM%`Y^Q?Z(fkR&ZHE_R)R;^rV`ox(PnQ1{>s
z05Z@tTaMua-fTF(<roxR1$KWlqOrGEKUw>6H+DuCmw`IDvjz|Z)Hzxy?Li7akjQOX
z;!06_2DO2XiHe$%01_4a3Z9|<0}mYl?Gag@S9V0}Zg2)rY=ff?Q_pK>w3ZeYj6vpH
zg#{9ykPy+pD7EZ(geoXS$xWV+8FOX0!yOzdwyTg;yz0CVSH!#MhkX>DOi-<9Zezo8
zSo4F<BF_HZyLb5Zfg<Ty4tRj!;06yEMWN-s5ObL4U>J*giu*W<SJv%*;|-Btw&6)E
z$2Tu(-I3*(GN8J{RwTTAKDk^knbd!{PxQ*@+L4_ygj<)7jZFy7sLzp=h=)r@t68u7
zx@vyr-F(x-FY9MxTMU%`KU@Ijn9IBsI@~>Wzg#t^yYd3MPR#5RjdKI(h`Q!$RO`2u
zwLW2)<KFYzU-H^dygb_WmqTm!+QYk@(sw0pHYD8QYDjuin|igWPD}C{MS+R$yOD3j
zUL@B=ibn^S(gs4lny#e|2Uosfy(Zn;on=|hdpCN^Zfx9Sw}qDUL9va=Gjln52Yf_q
zfWN*k`C=bbrOvHL<}UrJe?gU2yngAMMDGW$-ws2M_4lyDZp9rCcZd5SMn*{p$Dy5v
zWfDCjBb->Tz!MP;)wy~OF>#)G@-U><oRsd1l3QCTwkh35cowhyM2G90*!$_29b!p|
z{AiYqC!LE|IGU@(luH-hgt>`_F-`9z;E$qZCdZ<sXQ$J8&wu&dvkRczp&OFURrz%(
zT2f4cwvU2u3XMHn*_nA?HEFAIJRxq`W2fDY^Y35YN<zU5SbSuZ=Z-vqFrv6F$qab=
z=u!B?G~xjFo;;Y;I@_MIC%y&d)RE1<Qy;ZE2ti|nlN#D9P*Fj$*Q;Nf7^;S`Rt0zt
zSSk2lbU!!-mBX1cWjy~)bU#QKf!hXjFuR>@;~XSTz#pnJVq!J{JJd9_!`NEs>A9oN
z<9(%804Np*`s<^H$!`_KuU~uE+n)@4Pew`k&UKu|km#Q~LK*-J6<0ub2EqYKCsb6h
zY;>on#mWy-U?*U|zgzorae5%8?kY}5`}}V>v|9o1!&_Eb`m*ty{X<MD;0i;4LoI3>
zyfzS_@ER5=;*37+qHIC-@rE=X-wd>c_7%d%)t|jUi#IZo`uzfLO!tf*jMYAD$-)09
zwsCk48;$YPvD+UzI)tF%9~w$({w-ET)EWTmflc$YA{R^XSW%XhL?CH3ML`8kduYge
zHWiC1+0Cv_BZ5SP3DeIxpSidUm86bfXY-n8(-wJb+L~bsnaX>Fvr^vdC0V2JllqeP
zld7KQd-paT{B5U)Qx6RR-;XOW5K{G<j*$O$xy}2TlD;;fBCPkIGp!nMUAZ;40%2?4
z&Vi!KSzdo1ji1Vjk4<A2{u(?Gn;*j$xkLW3u()`Zng=;hH}BN!Q0q^x1<ZWL9j;xg
zc{Wh15Y`6RzJGS#{};8FxNZp8{!wf8S;Admhk%3%nOutLFhk)=l6?2W{UiZw*fd~T
zptePgXMTd33}<X$KmZ;G;Rm)WoRQsqc|Si`sObh7oKyef7$=pjwuj^CefhVnd&gFd
z0N^XT{c;l)mx$>N63jns?Iknow7=?z=WMu5FTIfMh3_q&7a7RC3~iq?OKJ?<H2Qt1
z<BGPd0qyKT*qz`DyN^(84!|-ro%x3BXQ*M60?}=-bgGTPzzi8jpbGf#l~4QvF&VB;
zZotAWj!O^2+A`{|7CRR4d@F2o0H5HE$E>Drdb=%#zPYbn+1lEos6=IPOx!NJdjiPN
z4tWUnz<q~h0Lr^kOnP)~6%E1ZM390b_j26t(?xILKXK(x6DSv)QB6k0R_C~BzX18E
zuOH3Mueu)=#v)+mkEjW|le_$}>7$e?lNAbZS1B!WJhi_4K5%T{6I|vi9<JQ^iBB>*
z+B0&j)F=@){{WpZV1)UBUB@{62FqyW>Cz$>S1&o^F9FY=QeCEF37nfrZz!^toiSTf
z<Yb-Q+8(?!;`6C9WtTtm@lR<dMFXylwu+`|eKVft7#VN>EwO`8clFqV5H~>wu_<yp
znVZ|E5<_;}A+W!CoHbRk%}5&e{}<Tj(E(8RK{9PC|6ilujh)@6x{h77y7ypj<*p-x
zB8)8`J_InAjGT(f%sdhJ9w3SA>bJl1^E6~6lI%>r%f)?hMyDmj-tM}4x}m{G_xKg_
zcQh*0Zh2-st2+rW(|mn9dQbZDyUA;IZC`i(UvPc~7c=wluV0MEkw~#It@0|FmgoMq
z2!3fz&5N9z&-L}`qN{L!h@Vo=$;{m0U$2+eiz)cohOk7RgV9ZvBYWVZ=_=u~BCs0k
zDits7S#;;lj==X{-+8}=Jkos>&vi!)^teh#FThQN@FF?+{l||a1dQ!_fe#T-C*#`*
zgy{21z6kOFewX_sp~c#Qz9-<Q1Ney*8bE89gsmSgyKL9o*@ep5*2<XhI4UY-{8bF^
zz|Q_nQ@DwKy0J6}8$k7}4D_BjiE(mTzEM1iMq&p68r|s)(VK3$3h$f>zUS|96#t$}
z@3LW7PoZ_2ly1Cf`<C<Qore>?Wy)psEk+zXl(DW99l=84RYwTlPB;h%n@L<ZHG3z}
zZNa@)*C5~3kt>7pZe6PRA(u)C9?9vXrq`GI7s)pMFDO56HCF!d#greD+YWlAKMQ<#
zD0R5rZmS902DL{<pH$S0-WnEes1u+<*c<$TMamtv+(iaC)!SQdtEvV8y8@@g%&I?Y
z@0}lo+G5pr>*i(k4lhioFgM>An|%BCt1CtLT`7zU2NWL&c3X^eaZ_)okspiS%DP*3
z-!HDpA#2tyovH7*goJ@ggZ<&@eOENzM`m$KBp-deR%duZR`HL>n<L*JD>;h~@T^|6
z%NF1Tka{mP6utrG#eFE*i%Uur$;|0P%<0ciryiyXQ|5?Yn41fI^yuI6GWr3uMqpQR
z2#e?G3IDVBx^TUUJ|t1bTa1V2Ve1&q5|~%fGl{=@R1d*gNr&ApDcjdCS93CBl~WSo
z>MSk20eAtj7(=9tgmc1^TOs)|{3iclrZ)scnN`MX<mXRFplpF3!aUpjD_}SD_l4kp
zK;i)l*8g%L@b@T(dUK5rGculE#(d<^zF;zTG}svV91X(A`GCTI!}AU=AOw%V=~xEi
z3+3s^mXL<Nt>1wn?^yM8*zaTh_o247xTpy066Q+UL64EiqslpQ(mYCrf&iEj``_T;
z6{$e?)+n_m5k?}T2%UW^j0{v&4bbC7S;bHKMb>ZbC-iStLz^#D`10ikSQ=Lxn7^`s
zk{D9V9sZD=!jhGlnfW?%eqLS`+D%w2qIDvrVt$oq%3ZrY+q&WMs`izpG*!G_`wN{P
zL9&5^-#^rJKY1sc=961Zc{+Y#k(RQSjD$y0?92DXR*|0sso@OK`I@tR$3K`bm-8^1
z0g+>qdbZ)e!;GGq?2RG)*Xz#!f#gg$Bp!<#;*DA={%zaZha-=<Jm+_>T8yt{(+l&l
zg$b@(e|Pwc*hZN7@7Nh6pQL&CPauU##`B(;^M~Dpy3djc_@8H}n$!GEFFt6xKkMW9
zs|A6Aq<=39_>=ALG`$uxdy9>E@|qF*C9C@*wTTt)zkGY9@-j40<NNNl<4HZ{1d^Rb
z>tP1~E`cc%qz$uHF1;l9Bqp`?B4UK$od^Y2ViW5xv&uJqd#D~zVJl6$E6@M3cs&2a
zAr=Xq;|G_6HzfU}EUJ!tk7yWNFwo_CpZkzLoXe4sH1jv5$>$|O0);?;kB{AExGnwT
zO|fsWZ#Rs_-wgbYNL=-1eL(Oh1QACj;$5NZDd~2hFN<TZ3_m9a*~n#-!qCavPXBMw
zzNb35JbBGJG(w~rTEW$87j6LFq<Hh(C|9IMyjY+lqqCo#Dqxv&bM5nUnROW7KNm0$
zxO-Oxn;KBd#?XW8sj(mS2C&6r3!Klol&x^~EG#(D*vt%74<*nujtR7E+^1ffDsEk#
z9rFAA=@5b^0Fa0rKGg?XFL(fXtG#eP6(-6Xz}98I1j#0_I@#?F7nlpPWTFO$g{iMm
zvdAH1;DDM7h2<y+P(c2P6VKj89H4M!MtX*BsnK_g)o{E;G(UiL7#@fZM(wO@Z4I=w
zU+86ncmZxOaX11l3Bn2RXRx8v<Hab6Kn{w(4X9E9ysvg@$#u`{o92HxJ_xQB9{?q+
z_$V$7Mj=bG%r+QzEdlD0G)kdDjgW{t@#S^TweTr>2r5uGYQ~Ep;zvbEDT3t?D{KD6
zvWl(aDoVp!dk7la;4>Q!ufbhT!0OYJ{aSAW{ASn!-(yG%K|dNp1Zd$5z)k&d!w294
zhJF33CZ1C%9El#XG`w$gx;p#+*gg~1pIuF{2-xFSx71NMlWr+KUMY5fEF!L<?7e$2
zKb`y9LWFG8@+2W%eh<~-C_X~Sj?-u4^ot49I~hs;o7s5w1n-<RVF+Y?XmX2(Wp}tz
z!!PBxU#blL97w$O**fS=+(UQaV83iBGHNq_^MV&KbuUlV$#~e1oCY@|mZc@@y?{L7
zO!zmN&?0a3kOL3sgulIyZP@aAPx!Xt<#$(#zrtwVN+CifW(mX%GlA;6RtQu1VOAD>
zVBz3?*?{G)Jc7Sw#@q7p#mQcN1P8#)S|S`9Cd?b*$|uesIi~n*;c3?=KB<oBimB2q
zu|Srv9cB(MzGI?u_oH?8fyF|>33Kzt-jqF3@l!tBQ_P81Hk9<eEqWI70`BZ7)(m<p
zFiyWyk%QILsG4J^jDC>}COY)?|2D&lmQEZJe!CZU!i>JA>H6WD$$fX4uS_}%e=IZ%
z?1MuLY5`35hqN<FLt>;(BIrey)Kzk`dw*!kikWt1YKUW=XvU=jAx7t*=5<kKaRTM_
zENPHW@_s$!a)e(>vBCmF>;@j;nobm`j@8T7%3zVhPrsyS3NHrmqm1dSq{oltXS|({
z-K?lYuL09PNA^LYOCmb#?X7iZ(!fIBO)uFbIrPvmi7RU7&!=l89l=^UaSN1i8~}i}
zO4Cmk8c1LNQG>4FriTJk0QEk+(NJTaBAGfv2Fq3OUaM{vB#o|BW9}~`G>>qISp|VI
zvE%IQ=2(XCYsYZ7tc<SV2GH}Xg<vhAry@$vN2x099kW&iE2i`^7Z+_~=;kY_;`*mv
z%O#9C2v(~cyfNP2>%TYyv<{6@`0xrg_43OzQuEhv;Qv|F_xi-?k@Syus!z?Jfb+gl
zDWgsCV6n66T!@(v<%HEGr);x#)EM%>m?Nfn#|t2>X*wvQONFHETpk~Ig)|X3z5ta*
zn$CRDqiAU5^{;ILW;QOoS{E<7+zcEAh7LHUL2ZT>-qVnhhJeiiCOUt?gttEoPQ?gh
z$Ssyaz!IBWVL3Q#@H95o?%FlYly+#rY^<!h%gi;;2~bGE=Hpb1Q^&Do(KBS=70*C6
zyvkO3iU7~})n5<z;WC2Z)jQbB0cC_qCq^vTEnH#t797y;_3*wtgTiY4+vxSP%<;_&
zao_l&Pj)wkH%rc^rk7v&ZPUA$O`c{F0asaoih{A~;Pkoo=4s01x(S$f3Qmm~TaB(!
zc=!$^Tv!+L+`C&XMD4`Dp<p`t#4k@XQ`bK0KU!EXg8e02>msEVut>gVUOY~9cOh;c
zN(JDoa@bf~hvy*49G#sV5-Tc;d+qXSf=IoF?*u#mV7r+3JN~c&^+zxzlpoRy!d7nD
z6*hNvo#{Z0c&=1FV<QVfCE1D1JTDP2yG>Ih(MBB<2e7V(wmFVB!Yhe_MRL(<eN_gB
z`5jkBR*CCu<JXq<<yiw?o;&VR{a5gK@3TRY-#XpDvg=k$&r4b8Eeh<JRW{z{c5R!|
zxAmCO|0MfX+kivgL$r5W>RX-v>XzMmjM@xzW0WdNFWPck)Rp@CrYt!CCX!m$)E(}C
zpo(TZR(%vcS<}<s=OeGeE0Ez;Xuz+QGt?jb6mR&<wyjuP(5}4wN`Mjrm)zJi%m*=~
zfyn_mp53jV=E1bI`TNsM-W8i|->SNZf62WYvy2ZlHS(FdRo9#H(LUy8YUJv@zQnx;
z6kSZ{VgkJ8Uf#MZAS#-R9)q9XujL@=p?ylwsX$N?e?2q(zj4<s_9w(26rh~qhDr==
zA_!G(U+8~cmw=TX9K2X3j`02W<2;y&P{`{VfzKa5js)k;{BIaGE7V29j?R+!rNq>E
zZ6BS2>Scbt?99gf)Bcyadgr#DiZ*ilUH{)DmA(8<o6|qhzv)+}cZuu<vok+KiJ_mD
zL)WZ}(yzFl!?8>YEdk$~-Dv7=Hs#2T=1LXLC3fql(u{ZJBvdB&gazq@iX2~$b>H{D
zUsyNUCM#?3GHYUcvtV^R%EpjEYm9I8+xy?!S`VTcj~&0(Aj9LsbFs0dJfJ3Ti`8Rd
ziB9n<2Ins<_<tUhX>k@}*iP3o^4L6ARGJz6=%P5I@-BkpGL_V8b_znOj@_AS$$`c1
za?U)BkJ>Xbp8KlZaM}48%&}hgANk+sHU0r)=4Oa{+b+dR-EzDp`cF(1s1?tdk7uUX
zRA1hR9i0ddl3{>C;Ifa??&T)KrnmXbX2N~4n%@Vj68KXyviB3XyMzkWnLYkp=07~-
zaZ!^6m_TAe0?ck8dz$I23<)76AfeF1ZTg;oXot+_t(N%@JI?<%T%41gFFVAOnfi0=
z_aynv2aSGCQ@JWiLH0Jc^qyxlSo(?G;tEq<DEcRz;FELZr0=t&t$~VapM*+ls^?r6
z8><K3={{=Oa{u<L&bxY{<X?e^nAVp!PFF33Zkt)|sS+h{rkhqT{;@YXn;00oxw4g#
ztIl)Deq$uJ{K+?BJ<?J*S^lWjQ2nVc`*)Y$X4ZWd_0?=L6|y+&Kcsx*5D#x<mhNuI
z9N5-$y7c2yo%sUmA?ZPPS;?;+wgs(ihV7<8cAxudt@BQo9U)vB`^KBeyLr-*itxkU
zXSVxnrl(yG*V80Y%~6-ZWLtInASRbE7G`Et{%JZV2nBspnk-TWoK4=o{BHrTXnPjR
z8k`TFzhP9rywpyq!$7!~m8I{yX>mnU*0cLdyLDfjbB<GP$%7S%)y7NrDd&tk_OZJE
zFy`B9EReIV&A*3#SJ@fsb5wWkeU5Y#P2OrOJskCg#Q)(3^#nG_0k0?b&OaIo-{t?d
zb%s@4avvF~>vD5$<4{DwVRqN~<=7w<{i)Tm=Vi~&X<d6>;c<iz{#`oy>2_oP$4?0s
zR}3z_;_%To)*^5pif(=~pD_Pz<5PfFY<bBWW@^{MITDn(j3I{c23k{xcMuYDq%_Cn
zLV1k2c{*$uTxWhn7)NNGU(!rgE>Dg~9<|hiwCDW)`>Acu4!+o}mZ_aSSXI5*Tm598
z)g`6wu2v55oI#yu`s!CoT}lksI*(Sx=Gl#P`kz?d8Be~Se|xseTDHOU)xQ^8GprW=
zORmcrpUa<`8vZTkK1lF-v+{VArG+JZRZAyxuIt-+TDKM9`l(4i!e=Jg20b&2oL1gf
zCu{afpI#Sx(DYo&QH(O>d#jqa?&AYJr#MB$!_L{{F&8I<n5T(aX`L4;JytkkNMA(x
zAV?|pm{xZXBjLzl*%LI;1@t^p!p18qEbSJBmvfkR)O59d?E93Qo=i$e;7#CKN_wGv
z!g^~?DY;-JY-#S)OP$Q;)}w4e0u*P7fhQIspZn`4>W-cG-*n#SJ(F&My~6}wq6Vjv
zKEr;YnA;UPd>0?bOffrEtu3ov+>w9d1oMf2%DWH$9EiN~?8emc+@`+8-qQY|VpA>s
zp^pz8V(YY656O-)UN^}}oUn8w_)|w_eH3|Ef3=9VoQ9Bftear=NzhI^H1KvvhoDz<
zYSx){f9klcbr+j_M!Q_~6EUZLFI&3{UEb$kpnN=lMs@ny@N$WCLwU{Dr_Qyh!b10j
z$g}TX&b=%^VQ0nBMM6a&lh5?s+I`>!Y4kJAl;USR74xN<x9wc6Gq*N*rR!ybj{>7x
zZElzv9NMb{$fl$J<-4?9rA8)1)31x{(t~pJ6d^!n(Q3J^2x23u!#z;nU3uZ4vffku
zXu9a15_x+Y<oomRclBC78P83>iHdhz=}FqZ+Ev$Yes%lap~6$Fhpkq<mnUtf9aC+d
ztVm?$C0{GhXVZLDLT=CRJa>8{a-t)0f`;kN($eS2LvA0~X60``eICd5H28My3qc5k
zQ^t!IV_mIFQ%U1Y8C@pZ=4Oh!-g^GK>qTkZMxSx9weiyY){)y_qMOrG#$^S|e{6Q^
zGfpmhL)CCYG7*Phc>DVg9RY0jAWgKtP+F7FYF09~rP7gLZDuB~bkmRZ3>j?WBUE8d
z%2-`Uq*iQX+zKoPP<GwT<N52U2VrtsdPcgW1l*tcL9cPG2PC5#To1@3d@N+X)NU;P
zQS)|O?b*K|Os&B8RFm*R`4)f7k(iErg1nZ^5MBS0%j|l=k9O0&Z!4Ll^QEi!1ZXH0
zj*N^AZeQ*X-X(rj#_4-@n&?goU-`pwtQj+}pQlfqleV<5k2W4utn}CH;UlnJY^-E?
z_eW%{eZX&*yvnJ=iH<$er^KQX4HG;!n>3t{=j)H>yuJtYoRl7+D1rhz50D(q$;l<i
zvr)Ivi;zsG(;f{%0tn2a40-gto8;#t0Up`fs;0Cfw&reavMUdfV<Y6;6WMAe;K<@A
zyY3ZoX^$ER!6OrYyYKTet((|sb1aE-&{0g#Jl22iF|&0nysABQ>)=_RkSKlcinX2o
znFm_iJF37LtZArN*R4M1|Kro}WF8&g!d<^m^RKT4IRfAA&(6xe|JEb#MN#8J3sS<t
z^+&TaZK9(8e2w07@ZZe~%Rc(OfQ0$Xo~r2Gt)D-AjBGI*i0zxOOldcpQb}QORo1C*
ziJ5-+dcWo?9v)tLo;US1AqP*MayTVfEQ7K|o($?^uBcG%K^yQKIcfI34Cnz7Xyf&J
zqitrMtY$CK4EpHv(McDn{pNo?YZOp(c<^+{!H(V}$y`1|P_U+pO#k3XhC%r&C-XDc
z_}rHYX3i>jQ*yX47OQuu^6K^MB*ZxFBe>nSC$w467yNOguqF9mb!(UAD}kED*boXv
z@?8(*?bD2swVQ3}zx&%MHqevka3~7csuvb%hHV`(eBLak<UesplwkIG)LcGWUpMMh
zWIykOFh#7Zm_m^5v8~s-J_N<l)xVEVWU<^bS&9vD(qRf8hUQRD?@9iqx0az{EP(37
zEgExg;*KOMFc?xx8P()^z3|a9u^!zT@1I#a?sVxym)}@x$&niCq@foHF}0D?_+k{S
z8g<4vG-8-?-mgoDhUC?mV|L%3DjN0{N%wb0+UrHdSeEOC$URD3a?VtgZ?{)HsOqhD
zX6}vlzX&21iq}&_IQH}CMxIeqcf&b)<@f^vm&_br4*%4g+wtOEeb-=-b|qh&@wp0f
z@QOBUJe}PyZm%?DEk(%rbrtSOGr3(;GT1%_Ycg1$7**by1A!ZEkZ*~OZ+d!F=?m0K
zOdW$~GpFr<F}%K(SY7Rhk^>f@ID&VW0e%4A)9);=y-_=tq@)+9o6fm+5fh!C?+n4C
z@ug?6v8Qd@Uc^LJmzRHqQK<>NE`GA+`SV`u(?A_6=LEcwECV*dm11Ke--Maj2mbGg
zUS1%S+?pyq!rTDOrQxMZOOi#m36-@rG}}xaX`#Pr(?wm1FY^sm`}u*d<mp)fwdRck
zz)BezLzSK`=%0wyHIrSy&c?vncy>`yHy8n7-Ui_K!i5W%Dtg8TyrY6~4~+Q1w6iGg
zgK88hf4-ggBqu;a&B<9@x?SbH#`}s9zTb=pn2U&LkH7Xx)WFDyD7K8rO-6Io-rKu}
zfLsyGy%B3!a;_9xFzh%GjmaI;+&w<Hx&E&@_`uftg+YS??k)0?dXaf_ZeX>*CGl-p
z*;CyDG<Jy3bpHOP6k~0?7+h*f%E}P$ifP82Ps7-~_Z*S9Vcb{Cccl_(+y@lkRqm)+
z_F4=1Eud!a4Ui{;8}^wrol?((8iPYv5b*tRgftp6bi};OMIKXw)?#p;-rEYWPhY;N
z96&mXTIBHzDhM3VIE7I)#@(KsEp`j&iS+fWPZ_)5OerpQ@m6bp4k8%Hce~_?0dPZp
zLwen^Ac=tM6IObvjnSJne^;8>h03#)*ZZsdwzq&IDIPs=hMMsAcZ@0Vmm$N4025Js
z3V22`O)7({0+&M&epAo48|=5$_?2B~*U5!I7U~ZI52c^|F{y!{5{3XH9$l(m%S1f=
zl4Ng#)HX3be(w3v0*L2tPTK)A#}BZ~gvdTPB;;t&%aj!K$gAtK)$mw#1b+xHb51HO
zvC->+B9MSMfG;QO(fcBDxv}sLHKX*cznE?AK;|Rp14r4|%rL}fjJ^f|AgEbfOh^|s
z#BB6u(xF0-W<b&T^=n&h#2(Zj+|Vt2u*UJ+rn<NAXvAEagoMNgtt4_v)YUaLk>@u^
zWXm6sex=P_vVg|g8~WstF}S=D`EMg*;FW>sU~3fmf6#{5JS*?0a}5Ag1BeV@4~XAj
zc@m<9uqvfMP(ZVas9^$7k)PlM5q(UL96^%I#>0mcLK**2j<BSu$jPN{j*uy+rs-gM
zyR#<sTolp)&sanIP4qK*aVGHU)kFI(z{==<z5rK6axa714GIdL4KdNMFN_F_KqKKX
zbo;f>>P;t4Y6X}~frt7BoC~bZv~%#x0<9PQ@eg2=jr>Ge2hoL9AGAG0yx{mMjUj`m
z2I{pOmw!yXotzp}fpEr#Oq7_-gBPTK_$k{xphW5k5;vg3hxKM#YRuE8kvs7m0;Y@!
z$duVc*N;xV&}VfXtgXkP*eMWUy8>JXpq0GCtsJA$^IYq_b4S8dcAf~e=6tLc1YiZI
z<xc;anwo?JW}$6dQ*CW6mNf9xj+IlU@4TX!ed8itu)|*$H~@@`87r<z0d>M0#v2}A
zBR7++L$!1Dh{^-d>o(zBEAsCe)&zJ?V3A{o=qq)INgu_$0rNz6h~7X*v7KT6n-oAK
zUGf?|F9T8g!o`bczq}y)n40>QYb@TP5CRW}`H^$jmozi+!v0U*4PI^337SyL_LoXv
z{tOk{>^H<6!P11lZw=c5L|c-PoX3xY9(El>5X?^4FJjfw(9i%I+rq6ul6TN!g=7Oj
z!gy3*xaeQH6iiKwaW~-Eg6SdNJ_6VUSSL1saPVb$3?{XhKY>}GuBysL_6u`<sBppg
zbl1~+nm&%91=1v7$f?5@gV4<+zb#J?7?Fc|)ItNXqV`y|xCgPwMu(BI!o39gqZ}L%
zq$4$0S#KWa1W4Sz5Xb@|K1QYhKv+?cn&iy+au}6HsHXDDWv0?0n=w{+tbx^!NKnH?
zgH1-QfG9b{0@~+fRcXK7=?_Ch_(lWlF+CbVsKM(GRBMMBc5tv^*cU*E!CN3Wa%u^1
zcwk`QBj(fKbP|mqi{`;A#fW7Z6Ca4b!8hz=KCpvORaLbw_!o$#gvUuq{B#d+e1uZ3
zZ7j4Rq8N^9)%M+4_&*&SG&OW|bxW{q!Rpjj2jChA;{I^kBZfO`&><ZHWi_^B8PEAt
zqg<l6fItkIOp+rC(y#*pIYCZQ&rE{s?X|~iNjjO8pcUZ~i5m<4A@(H0D5A42F;w>7
zKe)28ahQI4=Zz4hMGUkclL5V`CxTN(<~F!N&>Dl3p@IzSOtFanAC490IxqYggoPKd
zvEY+n0MLc2k5#wEza`)a5KX-;6H$a<@-+a<Q_v5UHK&pAf`z{X*obJAf?X6DY(hlS
zWOyN@UpTCa&A9>(4O4qaJ9A&W@PD$0T?AR7cjT$zaYs%47c!10xooW5$8mo^&H`_+
z_V-QECAJ{UA&`TE6-s^JfFL5wJ64F&)I=}FA-15l!=^s%BLax;{eU+X%Qw@h@iZ<P
zD{u>V9z<KtUkmQ&x)Oe1XT<(3gQ!kx>-2hl;_m7wwhn3*&P!bF8|5ez2w2yfK=wdW
zCKB?0-l1NDiQyG<&hm<ih}P_&AQD_E0f90*@BF~l37Nqvc(rc2+&4LSjLVROqwLN3
z=V3OYMI%i&Fk&X^O@MxvuCq%@u3>Kl-`NO&E653rDhz~=4GsK;MVxTKkd@uSmPgPw
zHkN{22o?m(>6<}KmSR=Ax6cd;@6J}$WnNnUR?RoF(|`J~yW*zo>zp^2gR`wS1!wQ3
zI1Cs|-tSGbn%>8b$80grE`-mI4=yDk!4?E0a~aW8kF{P#Mn=LlfBGoN8SI5GA+|x;
z1T$#a*jt$Kz}FQU5%M4-rXiokY?K8@7K|j}79uGMulIZ~?qJ)E4GGRZmM?*C!b#fE
z(Gh_-;ne*VE(j?9jXV&*x!7V=sXs!egWzPipuk;ahd;u8aMXd?IihHM@nSJJ8rapQ
z@IdgcBW<v@0Ou{XB%B5pIweEQrH>GqLOgU1IF9gU5zhp?Dp*NP*{BXd9W^PjC1TFV
zfP-r7{P|C~vj`{qi%0dJn?E-Cg>HRQEVF40Xu<vcljKr`>uUUY9hNT6_V!u4+b|SJ
z(aRR3ICb(Q^hEhcwLEy>04BrtsNdl7uxVVmRUB7Y4JRKgc=*2H<N;0K*4pBU*dx@`
z*OBH0yUdto)EJ1UZ(PLp^nLvbz8HFE(2ofO$W;(N3<lvdb!*6(03VmM=2!~Q!$=Wl
zx-uE@H30jLhc3Ik9AO(4C^0BVYrz9-ZJotJ=6zHPs2PK=n44?o)YYe;Is)4_BI1Ig
zB8gpzfS@3z>Hj0eW4**;^|~j*ooHY1OC)#UGY9V3uXi$9Az465YM{3_#<koo99M`a
zUHIK#<Byx7bAlpeczAgC&O1oSMuL*{=z{Rns*f*@)vu23+S-pV^BoRVBuhpqpoO?%
zEv-kjKW(d>{~-078nOYb7YJD*)+RxYQ4V8-eYqu)-;qj=S1jT*ZV6I!TsPRxDfOWc
zY-_uY+h=*47Lh|48GdWy89;V1=s{_QN*K!@EMQd)jotp>A_fHq+x?^W{HOAe9`ie#
zL>O2A(u`UX+1kfT5eT%|+uNHZ79Qo8rQ_@&Bf-)5XYid=>=9;WEJ&n|<ED$$XTf6u
zrtGmT){tHPkjQISz$hO3r=3VY1ezkXXV={VMxs>$<k^Vd9Nz*eW;w?3C2GHBW_(eO
z!I6UMZi);|9LImu0|!>~yVUnXLt{_7q=$x{!@>lyvdMTC0g=U)a<H6;*nAA)H=>G$
zhtGamFkO!A{QJCOSEnE;0o@*fzQgUhR>O0jaDun*c-;lcr06j#S{wJm*(o#Yf7ZLx
zZXGi!^CS4zyCXA8e4d4hok+JMu(hm!se1Wu2Q74EE*>5>La|^O!2Tbz+K&QI?S=YC
z4h#%LMSp{S5=uARuvm4(@2tE&Rfxz;>_1I`%OJTkv#{)Vf!F(F^d~e!*w`?_J*TR=
z0t<`10e|P_;2?^ZWTaU<d^q(hmJ$A4cem*2(+mV?+aO$pjkW+qRP%2ljr+&XpJy2F
zHo7<6)kTZaWiP70jaz^xDJG_ut2glVYfwnYP9k|K9G*urP-oQN*Z>O~3mbyDhGA5}
z7)>?<P{te<weJz|VL{uaR)|xbOl8<b9GbNo_y%cXqXfk&e3)2GqZLt9{D^7hYsbEh
zc_;gySyfeAIGR+#7?-eXLLz~B4{cm@!|>|b8iF_R8ontnN6$3z1Rvn&68djj=t;gv
z(udgT3R2>FVepg$!aWWN9A6>k2A3{jAx1xcekAsNb8~i~&iopxgVEo=ak-B+P;LH{
zKu}EyPA}X=UJR>n#xe#{?+sHXCnHluJnp%33~1J{Fm!YxwYfR<{}=`0B)8_(*%dwv
z@j7aBC{b}>!c|$4L3M}`0-UHO$W8(Scf}5Z3ycnmi>X8XsgG=uNGs+V#8EiT7lJ%d
znC?M-6D7@l1|h|alQ$pqVJi?F$6Om~9I#Kq!JL75*KP7?`0en@^^x3<0uQHNjZU;j
z{It4z1}`Zpw%0Ilzzz#qH5H?X>hVBSnbv9ia&p@U!N#e5+;1vuf0nbfG~THCrp!52
z?0)rXVI&<_Q!U<qxUqrK4$29zhY@rert*OtJ$cQI4WwLgmhu6JM|YQKDh`qST}70h
z)~uwvo4nJ_?1p>Z2Zyvr+gIqM`P{fhAT(z4JbddNZc~#&o8u96_@u#Qz8K|{%<c&s
z^`IYsIe_kzn5=#1kd=+iE`Q`3JgDo)8^JYVPlCTOjlwI;u#%JCx3v|#d1HjTo~sx2
zNFhiYR<_uNmG5*u<@{fm9Qqy0;y!HG{(iLZwrJdt2#@L{Rk$az@wk;^u~p|@nIHv0
z)oCvQ#P14pcpcA!hRdzTwT*p?5R_?o5H{LT2v~{@A1+TfqNp|Cp<7L@6;L0006SbX
zS`wJ_!YK+TVmDcOQ_AWKUb(%7(b(7#+zZ<IijVB0hR&{`Z?_$VWFSiZkK%f`RsfOr
z7gCfFCJ4dFAwqpP3ll4=v#qTJDor|jIx-S4^wHCG6=L+_HgycT6gZz&-nzg^6A||s
zNxOzY371)=Z^`Fv-jGPZrb^fEbpjAAj`|9?LQNm`2vtPgRRnimxZ2<WV*f+oXew3f
zzhf6lFHczigBJvEscT;g&TvJI=UjTn1IzcEJn(zHMB`gvk&|lelr4zhR&}molxGdY
zJLHj0yIR%Gh<z2ZAywm1@}CQ<VJ0caJBVt6r$Uz?%hJquZ}eI413gChSW*eQ4eh?&
z@hu^KGrlfMf7-qY*it2H|G}FC`z*L8eTfxrsHyQ^>~MIf${8nd<0=wcaKP?(fqEot
z;c=}65R;bghKUgc_y{2(Az}=BVbl|d7aptEh<<MiLTThPI&mnUt!gQI2n#;%5}V)C
ze@SD=4!k&c;s&`p@A_6_tIe#*!?oMjZuU48UKW~s<Z0Zx=_#`MQD0E4O0K9(QFk9<
zPgJ<_rmT311Ucc0T)Fh*KhMx{elqc*6TSl@xx$UV2$%wFOH^A7esSLNuy+Vc4Shy+
z_{incksIQKsdw%IVyn)F^6szQo(bu!W~uZY$$oZBj&(@;f<A+b-E3vzgKZD{Yy-X>
z{?*Qj_*d5)=Z79F=NS~uzWvxRO}*o{oKkbPCRs9ysL0kH6kOPlqMDgez@J8Hx{}gv
z0!Rd8Bs-mgiKQVbNC=VSKuSQ5jV3FQ8vZVo-v9U%?)hvgk==&PG;ZIe>~5U@u%9rd
zClnx>PJrk5@w+9DCv7!H#_sIe^IXa!ob4XWQs8Yu1qarnrn7OMXGcff0UaR%H2VA{
zaCzF_xK<Up-v?U`YvuP%&$DNDjdSfLVB;rC2IOXJXo%Q}#i_mpJTv^Vva)3yGO)DX
z7ku?Y&|b1+`0Bub;c=dBoV_TG*okU)EmRv`AY1ag)^yzaP7g&J=IDs5{v~n6$jEDJ
z!xIVd^EyB+F6!t2Z2AL1{)g172xpv{LUsxw!BMr!A^{|kf<6ShJdsPlemIg)12n9*
zb{I{KeJLWy|H4CUgbxXz9yisH1bywAUCz?~Wh=0ofO=r>{{8tmIjQZos6ZeimP`Yg
z*mv|Z1JYON9-xYOl9Xf$qo`ZIUYC`9X>E0O%&|uTaLd@j4d&KQpZec<dyt<Nq=*->
z>ws_=h@;}s)2@H0$Ins{kj{qYm-kgWtQLW_99wu29W7dMGQ%9!1Ath#dS`&6sB`rr
z-v^<564&MVVouTCM^k4v!YX1*?YYNId8g+;Fi0K@-@+Au{Xwmu(Gy7B;r=CX^zIoK
zX2^4)9)pAgJeVfS$mfX~qo^lgzf$`XB+r@t((ES3t*x!FyLZKMnfIm^-_hoF)TDP3
z;b2G7$nS_YX8I6~1PMV&NjM!cHXy0eH9D(L;t9Mds$9mX#$T$)nlvq<RmKLOZ@anc
z2jxkF6I!!%LvI_+1S(l74|eA7A{?~n5MU%&(pvu_Y47VvQPlO?aA)2qo@nsdib-1?
z*y(CUAS5nt<fc`YeJ~jMSoh&r_Tu=K!(FDa?Z%3XBo#jbeb+Izf(3aB0YW2Ri+S5K
zDr+jwL#uMkhBmJnZisj^p1kcf_x@0r^sx^`2V~hv6!zq^o_KZAF=Zy%HsG-4K<dTt
z(M!am5k6bOndU@W0GL-G=b~rCZ+;{c^3E{ji`=yE$3m06-7x6cpmf9S_Qq#A_ZSni
zJBJ=~DW!fTzjr^_`aPq!M%O*YFu~AcEu3pyo?U+qE^zi7UmjHBIit8+X*UV^J^zj;
zgU!p|Pt3B4w_5JH_aMNwa!784N7!RV#@oYVRD3MKo7Bql5u@k?-UiqK8ag_H%zUC&
z0Ni6Xva4v>aYVo=U5ptzb?klaXfgx^(ZDXA+1vlugCA!CJSecr{NVab#1nzGynKhh
z0)#54<LE{eaXt+Oo@;1h(Y)M3hQgCPV?P>-{R!gESD>H5Z$;4K@P`iyCE{?1hYZ39
z{s}lQ8A9fkmXQ0h4&()AStl5(dPmXQJmWDevP9?4>bsI06BC0e-%oj>l^F^!q>fTf
zn-*JBZkVWah)fR;r}Rz&5-~L}qhyx2j_*P9M@~t(2`rM1*C^;^0s&dRFs;Q=>-ene
zGHU=^*|qO+;NL-di4_IH>+7nat5AUedqt)HXI`E9BPtOPH8Dcg2lxgz!jYZ$1U3c+
zUqR1;#giEPxl^iMv?`yBp26Rv#75BwBtxN308Jp!3Ih~HC{4%$R*)Sq$xVtRX}Fcr
z4k`%d1BhE&D?(?8w-6{#7OQtwD}L$)hH$`#0E6zD-0ouovk6azUe0#|FBiy<40LoM
zWk@u-g~J?4tqsLgQ{UhI1F%Ev+EK{^TJG7a*=>$b@xL;30=SU&EtYpffII*#*#aH~
z0Hmg&VYT!PR`B#8f}dxt_rt5v7@}rmj(v)Q+18(h+)juqpJRlPXn{lw-ED`zJfmL{
znW(9WN=tAmi8<Z?;|$*nefR)=R24B!1FE!s6jmtamucT0jXsY%+UzSc;m5sHy%&>^
zB^9XD;BbMBh~^WwZ2~YLKxxoiUPe4p#ZZvV92^?K`-6`3E$)XTg2*{oOOTxb613d<
zR56Nakl<j3ve$`-LH5zUdmTpS^L3%@!Q0u9Z<}7<VpyiWw;oqwuJUx$Z1a|#u6#PR
z)$zS&dSK3U;)IaTz|PFfy6SX4@2Sz)S0ks?RCt#QJl;mqcrVt^G3-iTUYN`7v@y4u
z%Sy@Kl-aP}t+nnv@;r4)YDi<N|NPO->kT@`9Wwkh44c>`SZ6j;buN_N_~Ioy>rBp2
zPQrik^yuHP6yZHBe`Y&XQZDj;t4cLt8e`?k=gB-_@@AG?pDE_jK|Nai7@mP`E0yC(
zk3w3d;{P^ONF7KDUwIX;Huh&v;oF!0sHP7{_VZJO3abmtPQ{wjM{<IRJux=aMZ{vz
zK7bMGHlvLIK@4G}feJ0(r6iyxZT?-<zk4&gb6kR%%G;caY-gfqTN7jOz}Jr_x(L$>
ziQ2SEoh2B3pS)g2^?sQ^@OpQIC4A=El9$Y*hO-CG(Kesucxe%Fl>HoJSTrQ&w;tUK
zu|6By=xDiD$O7*XlJMkx*&;bFY{Ox!C04#Th*V*gYPSdiv5Qy@Z6$W)Y}!h=FN3Lv
zgMI-aG-5|sN&J8Px{AZi(tenik_b2f5wZ0dY%0dY5AG>na8^_9O3bCQ_!b!W(5~kp
zq}*4+=CGsm0k44^e&d6TnE<~Q`KVd<D|>>xHQ%N2Lm~^}PW1v0b@<1qnGaTlJ{1uQ
z%(_7qa7HWCy`(5#SGPOscaODR2qkxj<&RdWn}K7~0_Wddw!ONOK+(dzbn{LP2|?sd
zb>$pqu71=>DK#dx7kbC`kQP+gvoqfCEdT>m>%aIrz-<MosU*BbkciEq50sbp$Hduu
zKj%5d34vwPR85M8;OdNfjP4%<)Hh8WE9<Y5l`(iroOf6Dy7#^A$b%88x9_U1o72}9
z+=@)@n>vKNY|dzdy9ZCT8wfvM7W&q>)of%i<g52}M-AX76cI%0m0IQv8}kh(CaL{+
zviBZ5SO>rp=W2Fa_hdKG9Khz?;G}=VGJR(b!&|SVO2%Py4;PeaNjvYCyr>a6c#iO*
z;LXRDvY!uca(YmwbEW^4(^!tga@*-2+m^G%M|HvDGKtc5+V+I)nWq7t6wGQaTZVUE
zYBqmZ^Xp~>8gz8fL@r!T4ky_M81F&vj-}SsMf<SoO|NrL;~oBQV=j-Jvgk59eG#V{
zBJ`*3vjBynY<3HFtkcX?ld%qw5v{+mH$pBkfC!hjjgxgR>?C=3903xAk+=#t@4`cO
zbUG;T>?y5*%(pi~%^HJlo~EtKCc{F{i+$ghh6xiAwB8tK8$N#Q`MQeKi%;v*Jk@0>
zqm(?}T;2uuzqEgMQ*^zfDKERR+yCogyxu6?k+OPO@1OrZlE)r1>}4Ii>OVfyvAbc9
zF_i@g-G?t<@_YpfGkcfB6D7BD>2`b8T~W3b`#^k$EOTP+)c$;N)x^NWT;Q2r#_rvE
z{`yHTvwlt5iO*Ocf7|!wnAMP7>J9zgFYgmczxyyJJx@A4=r>iSR=vaja&Fs2OAZx=
zj^32l3b~)TZ%s}AI4y1&9^TQ^?bj?qI~RP-oiEUb^rOvp-xZPXx9(Wkn0s^ZK5zJ`
zIW5=sE?4SY^-Hz>fu;ej$U)k{7p=RqPf?IANVWx>n*nD=eAs1$LV$^*>|0~`(z&m9
zv59@wNTog7<OW6!d%;eBMyF$hd#l#cR7uvhENO@4)J31HnP&LnIvl_Ld|I(xNMjgP
zawR$c&_c^9bCrUrT6=16&HdCRdFsmnD#B0B=c}Gl-TpUQ&3HsA)%dT$_JylerytdJ
zc6yawF=sD$$pF^15}`rCEHvjAHM2{UoM{T@Kdlh{iSL8^39e7{G)~4#?Af-AlWCFx
z&gUB}|CveU+_}(<44aEl-vsF?Mw1kq=@>WXe~8bx^X&_p_np}ls{PA)?7XmU>2m(f
zEmb3S?fa4nYMDFCylQmQl&!w9pAne)d4AJ0O_X9?vAprJEbF_^*B?a3E*h!`$`|L`
zh2(WI)jbYzziLD^d^YG=FT)1=RRMZ+@_jssS9<F&yGt$bQI@C-EMHvLpxH;#dY;{x
zdXK|fNsk)IPhbBgXq){SUwO^O*3w4$V2@z_VUja1j@SQiSdfFvDp<CyM~noFd!sNq
ziUTzA_cT7YbL_MW>3Muo=DYMEhARx|KB0S6UT{SleR{?C$(gBz{wN6{k`wg+ki5Ua
zt6?GL&(MX?9(8mw7NDm{@3ws}%(m;HLNA5YVWR`lSCRwXh<Xb0lANK2ZwH`=KTWpJ
z#Gimbj3OW>Qjq?$F;!LF$4WkG685MjNGD*qgRB|~@*;~tG9tyt-X8yHDa1f$fE&xZ
zhn(m0<W4W&2N@X{XX<6@qASmJI*@MHXeoq}B0@FjNONcZDD(sB4gtIAM&0hPkuCm}
zC^X=q32k#37IdbAnZWIE12e4o*UUTx0{I7UH}0}>qy_8KR-Iu}3O>9aca~x&eviYR
zDpd>odG!CG?#-jIY}@eBTgeoqQjsx9rVJ68i)2b6^AyQUBxEQVLP(+v8Ivhw$e4^#
zC^8R`kRq8<ND1xZ>HU3st-b%*e{btu-}2QH&vW0`eO>2yOs7UjPe#8+?u8&P=K3?-
zK*L^`Pxp}f9~@8AIyLb7Wi_1(m0)D6vlBmFOcCfcXB$v|WUs-w(mQ0&C!V~hKB0L(
zw)JD8%a(j6D$>6dE@ai9H{dq$&wr43%2-j$h=u=JqJ?c3SD%#j1kdt+*AYL5)vh7k
zm42U^ZWhl)Mm2Rl;}-5Vhi#Gk4BuZmz1(K9&5R2XTKJ%w#SHOrNWc1p`MzwsJSr@~
zf4`?=%T|H^zKge}`2WMV!2`XU#WHeF8&cKVF8zoVrdnKW{6xKlB`V@wXtUFg6-v_8
zi?1LHuweXTtZ%0l?oguPnMEGby#Lu@8{F*RG~TfOue=d?x_kF`l$O0ET^`!WvUKWA
z>dN*ddGpk#+o)L#UJ|$=WVtoEEB)db?i{K=NL8%R`SzBUF_&XF<zad@b6^f4{i=Z=
z?wg+W?z>IyQ0wV4lE?9PPTRX>^xr(>`IHT#uL10f?7RUG1^)_k=_?9*k0tMQkN_YM
z-W^6#<?cDsTWFg(wW~MUNa%~}`33E;-^vQ245~B6@5A)WL5QIBoUJ?ZpbazsmfQZl
z+CjM|`u^pS-C5g&KI!6MLg{NRYrvocm?>=luYB_+%n3S-->c6Gi80u2S{yNx9>6kS
z)ADkqe@n2YKCfOlKUjrJ%4LlBQ>d1?PuLvw4tzdP!s`{!NOp?7rFns#UoEq{zwF;-
zE!?l6_SieZgev|9*OSCt)o|nUB4Qd>j@{UB5r03x{XZ=L<`o(b{99kuDPpe!msiae
zh5ynTnCi-NJVQkcazuny6l_9a?W#RY>VWtek6dgCVfUpXTr1arfC9n<wp@<Ze`$$D
z;!;v-D!bHApa6i6HWL66N#TAI69CcR^i>ns0}cS#-B$7&2lv{S4T0e&Ih=qX1MzQc
zJaFuoC(vjaw(W%X^0bw0A1F+eDwG6}+s9-|T7Z2q@5Ter?t=%00KL&V45lk@@0Ak~
zxeOAK;Mfz63=)u(n7jK>lLv^08vRYUqAriW1b)oSvX8XhoaukPjPPoFoSQp@9tPk6
zS$%u^HUf3tKX~Iz$Ud0dA@D%If;YRi)N}Sp1vP<p-`&%LIh^Tz_Fb_kCIEJWAO8OP
z8o?tdm?C%G+ui->5I8kdK0BG2NfFa%Rb(Xg8JL=`zdn=-V*cR`IKi-z;QN*akxPm;
z>fD*B&BV&O4#IWwaeRGJ{5D$0p6!Llzb$b~L8YHpBdR9FX&M474iEvkjbD}-1)ehK
zVUWZ^J%q6dKA&55G+HiuuS1tnYLssvU@d_h3~=!Tq0vJcR2_Zn!c$N1>46k<3Z$$G
zxwQqwU<+_C2*r5C_8vXr0_n?TTS%jD8+tB7cdPh}8^B5cd`UTz=fE!F=9XdS4N=i-
zCmsx87H>!x#5C%rZjyGXtljl&Pbzjq7##o>*63m%W5lzwR*!!<Ws7Pwcy34?uDZHT
zcW0`DFH;3xG~o(r616_wu@3_4r@9Uh$3QnC35Iq%JC+vsIj)_rfv2OVA{l7L@H9g<
zB7m@f)>g&0<<6t?A3u^2p#0H@5`NH3;kuCga9ouzvh@leO6PE=JL>zkw$r88(G}tY
z7Ubun5_iW8-$r4yrn1*pOVbX5+k^lFJOJ1cz-qIdAVO`ycCM$rFSYAAA{s{8FebD6
z$YalBpRHW1&km1k(dji3FEUXHyLNZQWpL`1P`dD)VHv~yg(kum&xr2p-^sK4&1@UX
zQ-j%|ku5c&tHx%eyxX7X7*EZ>d-Mn4RdBvXsc62DOzmJlYTt{gx@2Q$8C86r0ujK}
zKjJv}7EFtbNU{J%Mn*thbBxA&2LnT?`;6X_5tsdJ6>u`MrG}oK5-1J`b8vky+F^7g
zffht~mYwij{d!1TT>xPd-_tZSz8?rBZJ8R6+({oJvX=46#CVz9`ue7jZDJL|qQgG&
zD=&gx-fBqLxizZt2IXj)tb%7!Y*|U2eqBm|Y*hKNIL5B#o{ph58sd`mOXEaCpP>qg
ztX*u)H<cHRd)p`d_Y*Lk$i4QR9v?ZAuWe&9NvH|ijQC|ff*U`$QWKd-!Af#R_t9ze
z1n)Qw6T*`M_+vZ6!GDK6LT`@Cqgi_Szfm5DE(1nWaPQp+2W=w~0Ui#Bi;Ju1>>$@N
zG<;po%g-+=LtdFfZ)<y>=_i_MBt$|)VRmX;1nEW%+|{Eu@UGeL)|nl&yuq+HR_DH6
zy!zYCA++WzSu(00e7!mXIx9_w+^@%{K9{ymjqQzCWbb>#t$J{eo^`CZ5hd{@np0*@
zHmW|XRb|O_L0H?ohBrPjv8u8XBnVpi*=ETpCLx5)G^TG>)NEsZrdJAv7q}-@B4mH=
zYq}AZ&!i$P7}GSLA;~FHZuQoq$G}X1U2O6@$;kv3A1XCx2Z#46`f8ccZ;Ss;5QY@Z
zk7MKKla7Rh1RGXC1{xA4OA=Ob8ER`6BNG2pNE7MAacIfgL;83_neWnl&O+QRLaR8f
z8f0SeZmc0$-S<+>^XG2eJqdT(M;f1Rt4#6TJm(#s>dQHQ+EAl1y=*<h@B7@vGsMDN
z6vkIBTwf3?dt97R<?yA;xACendz;|f<?@xJ-C`Q`dxzUkhdpENdt27JT$;$atE+Tl
zS9q=(=e!b`;@N45+C&E%;#i{R#}gxsTNJ-MIkqO-C|tMpR5GLW;nJFNW#-uub=Pj1
zBeA!QGWr}MKge7^^ryD-r0^3P+Z%<o1jhi+PZQaA!}}9FSMF1Bv5eChh#eQns0^wM
z4_C*mV;UoB@=YDvQkD{P3Q#v<`l4EoTgm<QX>i{l9wAczkrJ77778EGjnIghlvryV
zC_Br{;NgDSepo?l32+yQYthxUIz}4j0f_7T!r_10)KOc*6UVi5lnkwYBvVfPNY~4W
zdY;RZcagEF&E&{MH`~8szQG|3It*@C=W^4_Xgj6Ub`2e!I)83sJE7*#DsKAA>B%?g
z_YD$%DpxiphV^3ffKdeedCakxp0-tfU-^RdsfL7e@-?5NCljBZw~Cu=lBuR9WbUYH
z>4uiXEY@+ar>4g=PTrb3+q$TK=GU9i^p4tiMei_jLazCy`a;`H>#E81IF4H#rw%7}
z+jOto)AJg-%J{+I<(u#4H`hloXQ$kkHI=k@b$g>{o2j&!rWO^UeBo@a*z|JGK<&T{
zZ(k+f@H5t;3L+T>oYp=0kj*gX7IZeqhCN~ozI^rSXqkgP9=8h@ICC|YFQBpj#QzHb
zB}7(+PcH;ve9C)ZZR+L03fEB)R1V9tbM0nhO94`eFVq;e$ANn>vm5cn_yV5;qv{^K
zfnNUZ=LXX1OjJPU681<fyj3u{&h<zAgDUFRYC%WljT*kMXY;?|BRejzV>=D2@P%Q`
ztzSp&EgV#na~2A(nH|l!Ka)!~_VbhUkt;K7mrUJDr7~JMWOL5?{vgV}e;c#m+vz3s
zyy{))%vA5wn&j~0%qN&VvG!wAZ~bZ8$@jI{$Lrardd}yci(F>5<fEr>pDyg=;s1Oi
zv!#>PG(Df3IGm#wMI$EoO4HT!sOr6nBjX|NtQV{<b-gV+S0&zV_nS#farAZV-eF!%
zj<G@G_dngfb-CUfte#q4T`F}8wz%7rizI>;AxEclvzuXIG<sgwFwY4z=_xJwnhhnk
z6Rhm)b--9rtdSDqIH)KoLqKLbj@GiyW!fdYEzaE@(uk|CTnOScESHaQPwf%wDJ<r?
z`p$oK9i80^`ZS}=+RI1hSJJ=mM(5_|&{0h@d;N6vvfDzav~l?dQr=FMQ@g;ObLGC@
zp~t#M@8)XfKX!Ne^eD5JI4<IS=z(Rv_8k*J28}M-oOG3(cMUq`SiU$H>|r=ss!L}&
zoXHJwp4b*bFzz9vwk;<?)LiD3KB^}9wo|%besD((CBYc{-En5W{%hU@SNl&YB3!SC
z^?mXmUeQN$iHa8UgpGgq#3>2R9H->&iQO#Qn%g(%T9-v=+dxC_fBg#wG-iW*-{Ot(
z=KZtF2Tss)M)5#Y$ivVu`pFw%NgZ<gxHS?;v!Th3YiPWM*cD8xKRJA!&pf|BLYs|J
zF2&u^*LMRNDPXrpkCLK`as`~%{<}&aY)|+rX_XpfPJZ{4%AdD8v+;sexyvK;0oO4B
zm$uIzttaVBM3XMwSxL!obDz7J#2+_*KElWC&kS{|)nvbf=(rX$Yi28d$JSY~hwWh!
zO=EU)w8G1KUy9Ju5wxAeaZxeG8tZm#feHGgvmrwBANyHZGt<jlH4YQ^U$;7D=ylAD
z9ewn?IG9USFm7gUPQ&Fze>>!ps2JabsXd5TPF&X6gNRKAnl7mqH~#(^1<8a?7Nk~i
z9+lRfIuR&|Nz;aq{+6j7!6JF&*fB<;)B8AaS1mJmW@DOEUW2urn4H{HPnuSRlm5`5
zY>){TNnsf%gHqicU0fFMSGk%zK+d3+hp-0M$=8<D4OU+&HNVw4+#uj~QuCXiS=M-6
zE@kM;M}80Gc3I!H(=;WkXB_QP9lZK&BE!}#;r^i<k?j}O->*>k$+3FJ4a6R@8twV&
zuFq~F@p0?(DmOdolK1fyuM1lS?s*fomizf13uw=XnQY50v`H<w+Aha)S}<y_$(bsX
zES`^-E0dF@Ox0_&@?!bL!a{!A9kw`IVu`jLsm~J=uRiV&Q@mGNn}6L{T3Q-82XY-5
zW%&;KP~FFjpS);gh1KKb<AWkB^n-z!*`<rl+Bt3@C?BisF?xW4_456zR`&MKEt|KM
zE9eHg97}>Ot@sjOjah1P^4mS3^i<>#Ph6nfK%ywW>p371P_nhTOo44@mOH%TUtcbN
zc&dPds-Zmp?PtSX1c%(ua<v@s3gH>)mK)x`E~cscdXg?B<s-PSc+7M7b+Z0X)q~xg
z1up`tC>(gpGGC6DbgBO|l`r}-ed3Tqvrv=3mqo9Zt$o$EXPG>f`l&PZcJyCq;Yjtb
zGadOp+L9cuEa2%}Um7TJXYI?dHMDa>-p}4YJF<ye=Hg_(y0jjvp_8RWPuGho6SJ<_
zpJLKn`4wd)nM`5HvKdclE2>YxiQGFf;tRF~L3_YfK-QoN#uz);0a~uc#K%uT+I7(x
zyH717mS~v}uLnvO0m|^9QXnnTx{Z-R#E}K5lgMD&x>pdQ#_Ws?q=X?N=j_>zu`zSp
z1j}HOg&r5_y!n5tM~}Wq=u$`C>xT()M5A!bgs$>Rl1feL<lat)@hVGZEqy97eV(x}
zs(?l!KikdzN5|>_ppLr^YV<4#X<`{PG5Nqorg`#%b;$f)z6`LojWOFsWL={U8RK(1
zx~V{=Wmnp)yIk|hHi^7G-7Z=U5)PNsi|XRc%Uz4duHEkw{QQ9CnF4F3?macU?B!lj
z+QS2VE>zp>DF_C|oMpAJ{gvb$_k||uO%l?0g8|?L%|9r+v*Go)EJiTa^yIbgi;3mJ
zjtv_QuV(CalW-C<vcrN!$ia-CelyM7bvdmukX(V~>#r{ht5pBNCuaN!Tt#eJ&gMB>
zr(6BE?D+?-&~;~UU42r3YMJzZQ#zOzZ1?^jutj1kfTjQbJb~%|>)QwVhl_yluD;Lw
z&@>S2xh|RN_Px1BzM_2he?P(OfLU4n_~l=Z8CM+|24BkaeU1_8X(S5$Rw&wR3r7C?
zJ!_k7U)b!Z-I1hzd!cxxSiHphBU{GKt^A_uOT#H~-{?rIJ6>XIrHPrLA#YqO)O5zS
zRKXTV)*|&T3hSHw%nHGHVFn)p9Su`l`-@|S@1<s>+>tjHEOaTm{6Nk{oB7IM)Vp(i
zZ|wa;U#}-oYKQ*5ed64(qX}_5^PFk*6-nMdDSko=i&K)%9OzHbQx>pqq2LLt{`=V<
zxTHmmLUMjG;Q3-(=eCcJrpNExG2@om<sh23LpEe5`DIDTRadprGleU2omZaxRgnuR
zJmCK2p5Vw^)yXTredl~`dTbr1zaceu-)KTVr1qRcFZZ>3W9^%j|7;VA(`Tvn6{z?e
zTA4Fg#1^<N{j1*#x}^EkFzLL0JBrmMNQ`87&6DD4nu9W0D807trA;mwUswsQsiE7R
z))?~-uysPJQINukp3=%nuW++v+XO)b>qGe3O6QM=GN|f?hE^v=&urCm6)F(?u=DA4
z?a|P>_SHdc$4ZG+`k|C_t6Ul979x9Y6dkRQ-siK^X-#%R!TNIh8|w2NEWhTz{<^Yq
zMVs(D8=oQL#n{X1^0xOIlV6}nGnpURWQDp<(i7IdqL$b1c08<-d@Zw$o$3}&qm`HP
zlN2F0M6A8kE=@;-d?)C=zD?I8-4_})taVvfQ-7`hiS2{+ThUz!a|tWwiC>Pr#W~jx
z_0ZOQjT{{^ly<uISH2|BdM;A($1|SRg*hF*+^Z+&=w{?*M@9Qp$R~qhl&&?96P_$`
zabpj{+q9fpl?9WBuKsxc@ZXwVj8)XSe<m9#c9cZc!8E()N`GviHr(WYJX5=7?Q^O5
zw*I*`X%Fr9f^*lX1Z8u+-IQb7u&s)_PPv!)P+I-P<INktcL&*i%BbB{d+m#;KlQ+e
zg5<mibvvgmi*-!}<$?<Ssy7OKgLH!kO-(Hw16{FF2cD4aa_u9R#0$vj2^Ue>w2CTc
zN=gaoJn`E38tuhyvicWq{IkABCtP4wpFtVB<ngzaS4q?@qI@S&nqj2GR~%Lno~It{
z!LD$`D6+gD<tOVUt6}kL(yuGG-<0`Se`lRaa96*jO0q=j&#ZJYKJBiZi=lWhfX{7i
z6qZUp!$DuY>BHh1@;!~h_?&rt-D2y}i#-9724!kq(ho{vy9vLOTr|@%nu@uEAK9t1
zGgJZeKQxx^vmI?Od=sfr7h{@~cd$%1Y`Q=&xyyrsQ8s@IL3aM(AywjT-e;L@g%Q08
z);z3APaAdl_~4=)@pRkDI>~i~+;4=fMkP$j`%{KV-qg3gLm3WZB~S9T_ykVw$=XCl
zS9+)W`Mc6q-nZ+<n`4GwWhKYz>>^L&j(K}b>)#epeOZ_`U55{}ReWqAZGCQPEE^T^
z%%lKP3dA(O_BGNpH&lJHv*cdqjFHCMd&Sq-mCrU(%%1L|T~EDYys7%nlca^RmXp8c
zy1qr7oBp<zbMT;oXf(IFgSwS<e{fa)!T#$*D=9-aXb5`jupnUu4;r#2R|iOK6L`XB
zbmLMW^?BhU%Q}kum<PrKj~)1S$7qK#5XI_Ork8|vsD<T)pTEfYZ=15C;raNyEZ<YE
z@bpr(n*SDx)z4P8C}`_KoGq-hT<14u>Upj8Kah_WJlY-K@hLI1E!>{w40p;K-nSMh
z$=@cpt`x-@tfwp}8#;Np&Iis$JN7=SyIS{7S;E<>DV9I{UJ92Sj|zofE3ZhM$-Dc;
zDQ}6_pB5bY+yk#VwY~qW|9M9Bx{tAhPiwgrugJa{?sVbB%NCQzzik8`t}2_+Nqb!F
z`PVg~crsEtif*Xsr}bwB3*r22s?ktFKwr<x%L@Uo+C<`9vK8a0^e(7`Acx}S;u^*n
zsj|b~I}mg;J2N8<`yv>X9;xAKFVVw?=VIux_3{c$DixSc-n{)e=GClGcwExEJxk_g
zQAR>cwZF#R9<ci1T3DVE9_+jDB$g#W)Uv*}hq_LAB$DPU%ezX`LqVs0KS}Zq@QZBR
zv+iN_W&5H2t8NR$_lEXg)t7g^k*ViCwklF-^wHc(KCQ!mh#$FO^zuVEF2Eb%(`PH#
z(tT*N{l#XTbP7KzJ11+}?zWJn6k=ZfdZ)EY?)^$cua1<^#XEUU(hSKb-x&?H(fR&8
zxt628Qb6vp@7+VEbZ<I&j~TA%{QZYmvMf+cLiYxT5tNSa0aO4_SsC&9Hu0gP&<|Y-
zO0(B5UVKD-Ptswa`?fk_2o#S%f3sfqcU?%M=g5Ou#8tAik6yCgBVd3&ksx3xJ6~qM
zd+2eOEt0U<_wHQ*Mgm`o$8@h9vV;H$b{tJFEp-DvjQl=ez|GAz_;UcwRx90N*I`P7
zX9M7ow~r5SWjTncKQQmy`ABok{nKT5s-FHTv`XVrO+lO}aCy+VsFd(lQ;#~t-n+N!
zJ%_yf4M4^Kr8%P>10X{gBql0qIeG@*>U9JTS_WYb5#44GWo78wkiQM5C*EA}&6{n>
z(iPu#bCGO*KU#$bKZibi$l<}a6HdI2)X_05(mWId0TVDIH7+zXeRQ!+fLxgJ{p*R=
zxJXv%SlC0+*T4mOd*9KpvJi`S3^)6Ru(`vBBRanLczJ20%GCg^a&!hE{h{)T4KQpB
zFm-po{w4V;62qH59d+3`x%gWljsES<N%qtKph^f?gPCE^LS!lw)|q|waN;d5eLY9G
zAY5!^<%?@2fsq&=5GMn@H$H`*AIzu?Y>7}$Gc!xWn6p%PDqZsO_|5R}aEw7xP-p<+
z3QQFPeQy8!@%tJ=Xb`QFrNPV=c@+|tjrG5idcwihJ2;!RFWEN*SpP6DdsxqDS94an
zaQTu0Re+*MhEZV#qpRK+?KT&NRU=}-W6I^?_YHfeEd*eb@zIe;4l35n30F@s#k{2-
zhW?^d9Gai*oEZs`8#2z%H}|`IcQ8MBbu)27^s{nR9F4|Fa(W|e*;3<{mJ|ze7u(?O
zyY{mA6N{3&R_`S56s8_b?;kMTD_oy_-u8?6zXCB-W$Bf4>oM|3G9z{S()-Wb-+!Iy
z^U-YfCqM41G&1;dYZkWx!8j*<!Q|W3&(H09ja9NaWb+$UjhgPIrpiO1`{s@O)>2Xh
z42=RwZQ?TKS5@URGxXC0L6)zC+oZo$_l%jjJwV9}mEn(t1@ns53D=AQT3$ZB1o-A4
zyIhrkBLS8yJQk46|6E*jco~dU1O<EX)l@{Bku=*7_XGw8lA#9OvULw^MUQIWB*Ygq
z_P;QdCZ(!B=FwxAi$2t@f3e>V-+NpfL?V^w0=>MwHywwk+0*lwv>V)@fV~i;Xmx~%
zKq9MH_wOroKCoj!l7RG0tw8vA@hQYE36EQ8pF^zFzOVN15<!%5ypZHS#o~b9ukd^w
zo6{g75J9C3F1kWOjJeVP<bj{j5_rkh?b~fuFmo1P$aTc4Yd0u&AeoJgZKL7arp3ue
zJ)~9_fp=aqBcM^X($E05R@Ul;3iQ{tTF5lLy;sptK%|Bv3j$}R-Mf#%?q{<e3o@oN
z`7Eq*Py@bq1f_t7)wNOv5;^P|2x%gzyl^96%>yW$U|$kt^cj2%&?V3e$f&ZLrtduI
z?+#HIKqw%4xL@%dU+!^{G@@u8>FF_i@M7DMzt%ep4jaEVRkpKt*F8E!6I2j<L50x#
zx?4q<%<oP=r~4MdNX;}aFSkoCS2a^XKfSw^?08Px-@f?Oyzl9cltU{+2X{xF9g)-J
zEnF)7yV#w{9aA=xyU!`eL_Z?wte9fXQkapGZhpC1roOP|N?YE3U0Y28U`jz=PM2P<
zectqA{*!B;euV^W?+(*G%av3vTvk+4su;-W9^{Rt$HLu8Mofb=N)*lp0OD|`hGI+x
zI3Fb0s6?;9b80sDR*m&Gi-f#<T~QG|v1xN^rRS#0-^Z02<qA!!^s>n`dPwd}WDLM8
zjEx%qfiw9yH%CWcA9WaZ|BDGqS_~88<Hay+A=$qMwohUKh)Wu2*HPlMhQ0;Y73&Xr
zNRS+0DIcG}6yysR#&N}GR<2>Rj@vA_7m}g++sI)C8oPvlu18IV<+l=}nhbsTmEdx|
z4OjLc6f;c|Y!d~m8FI{_)RKUVD}k&<#L|{z4Vz&+rPYg{1R*0B6;Jq$um+V+o$|%t
z#|~LhY_(kY;^xMtU(#NHw07>bWW3unu{b!GHW8}PEe|SSCcDU2T#Y`KSb&i(14$Jo
zp5S!gIDIr29vMjqVkESegoKa+%cgsI-FmT!-c>V(Zn9Ar$yHd}q!dIrY{)pcxr5g^
zHU=~FZEuySuBi2W-Mw!<QuV4@FV|aohkJKybjr%@3iskD;f$iv_3>U^%7G*ky8@UP
zbk=wIXF$*({R)k@hnw3h9wOWZy*#I)JR}l>YeZko7HNaIw6Jh`#KCb3PjXGob?B?k
zWW&>j6kia&5M!P=*YUh5<UIrsB<vMhzi)#j*^eHLZwd4`<pSqA%#Y_QU9CW}f>EFe
z;zXPR1mTdW;&FzlG9YT}&hz7zYxg9IqpK9s<$Py!f*y4nT{tSVblv8`X1<J(ZU)^L
zmRqt}{kh3jXVgy#Ou8f(FwvfiM3QS(cJ}6aJn~U>d>kAPtE<;QMF=70ASVaPRt6=w
z8@|JVic0{-1&*~85zAmrh!mOz2KEx9V0-NxQhvX-_7S(KPH5a<Ja!r?<rNq2hx8kX
zlGYAAc4b2(PyuFS40eRt7IIPhfdW<no}p>5#YGhrqu3a?%df#CjW{JF0+Mu_XU^RD
z`0UAdl|zF=L;Hf;_I<{t3b%;)s~3RxXF3{DOpuv>c<w&cFpTww#YF=5b97?k;@%Gp
ziN7n+&N-<+1=IRKYil^iElkpeo>d_Y;~Z&_%773~5_QQUYE4UEPzfntn6?pBTo012
zFV~D?j1RCSVhRrE6ZGJxX{f0sug<eX$3TJtLWdB>0qUkM1p_)Zx>L%^_qbkv`i>5p
ztiG>LS76To`{T=v^CLBhF)>>RWDj6w%qAjArS}(CNpEOVF+I73ZLnG4`QnSAW`%zd
z3)*=#k}d{<?|vZ_R%YgKv(pcbDDg0yNs;lw77TC|g$K4c2}l>O^rb0M!YE~DCkdna
z{re1Ik9zIP;PHkel_~&NQhB}xpBdC?I-#kh^%0{iZJq#vb{u{dWf6}&!Gr3t_+OZX
zn!CC#V?FW3@QI1JfgpFJC_R<_yW_?N0tPIdok@e#vr7*f{!a_=s=1lu4uuCC+_!{l
zli5M>3mcJvEUa%6?$*{UUmE-(vZasxs)J;n*gg$x9+=`26Qheo3eFoYnkrDMc!ZH{
zvH3Vg{Na$n6HXnVqN?h(Fy?Poc-6yWexQ&&wIdR<CIkeoq4Me6OY&2WjEvwO<BzHV
zeIhmlp#`fe-y*x&5RHN32ue`opt(tzCZGNZQWwWm@AlLVWswua*mqB!gxhN(v!}L&
z^o;GT#mIXg)qq#&Ru?`hGH^cWK|tM2*<mRCIXM;5yBPl(2WH)*VhYyE>jS-t(&(g-
zk&&(K)D>rqne7+b41n1J<TlDD$r(_#!nDOFC<rApw`wt}EX<#YKQm(H-`AS&Q@8E9
z|9(Gnw~SLgcPnxZdNw<^WytL!qatBq(|wPh-w?-G+9@T(WWI~Q6LqRXkz^HRv_>QZ
z9&ZrkmBTo^VT{Emcfci_ef0zR1nqC$DAa|Z7KTWD1Os)RJ!2#^dwDrI1DZeCi6!8n
z`10jTdivcf<G5^&9C%Ztv_`BRNZIW!n*6+Wb38EE@YwQ4*Gdvj2&VYdDT*H|NXtT0
z$|x*B-Q7FwsEFf2$5`%sG_^*Ii>7Bm)CR)45x`CqS=|p03nS|BqD*Z}%_NS)jjie9
ze|!wCAyiCIJ$&(%g7H^n7<Ildu3)A2G9Q5{pV6#T1i~Wx%t*t~Y9Nh(?d32pFByR-
zPaIs5a&l(e_vqMUJmFVwX>X!ayn$)Zt#96tRMGI<z%uwYS$be}^lzm#^J`SHD1e~A
zfTJa(oFk5zfXja0!Dh@SfINRxDHkh@nJ_UmHH>0~0T|^Fyfpj&(A71fC;*l4FH_**
z_6A}8Gnv|~^1dttj9}e89aebIxKyE#fddb<5n$CzgT+A{RAG-WgC;a94|iBbW*B~!
z7AEW<@Rjct(k<EP8ux1ur&8Ui71CJ5nAQncHoIn)q4aUMcn0n-P`ns*qQuz+cpAgZ
znNN$6`$6^w8`0Idp}yCzzv8LJ$qQgR-EI|{56lIDRS}vI_yr3O6z1jTzH{4zdLD@$
zsJ?<NFn`5oY06(5PY{e?C%NxsW@X_6C&tJ3G8q*PAaxg@`M|(@@RZy0j0`R)<Qf97
zYl~^<>*<N}s=ed#-$F1b>FVg<kiBSQLyE{DiB*{mzqnX7K{j+80XQJn0U5$AWM;;u
zq{XEg_G%oaWIA@a;TB)B6bWr}J6<}z!sRfndo)LXuURvGI#ElH=`iA=`$#duf0qB0
zB%HFd<JFc#L;wp6;W(CI3W!QdT7#V9J_R|UkhXwl-zfhla)y;Elwn1t!%WCqw|;$Z
zW=G+AFFG0lKcxCJAYfCP<}Vx}Qj(IS`Row#;DO*7+d^=uZetW4OTIdC+0~U#NJ#lp
z0TL-74#KsZeTKrA(A3rrFj3~|%h}O{2qJ8AFfMWxp?)DV#|{?kui(KpJ$zeEf)mY}
z0UbHfa<5sq4T%DsPhBfnHs&`@6egA$x#01^vQSJbK$?U`vefQ~pr6J12mFuwnLUi(
z(*5ko6+zVc7;OQ(o#$EqGYb_;9DbNfO*f};=FA4hnuG88`>3@|UE9p8)~16k*a9}`
zhITKdSE;I0I2MizX`eeMgdzpQ2vH{3*iaJa0F^c*iQ{GkQaRRm^humq*!1e3KPdJ3
zUB2PWgU%^Jh8{Hs8Vu`0`IjMxL78lIWDthwSfTSIS~ekJ2ptCw+WqdN0u8=rIDg@W
zXlqe@3?pH=Bg_x)HJL6cGWzWvpz#<Ms-SnNV;(E|tTr<8v0&6hh;i0hE2EQLBd>JN
zcVB9EwsHH~B{korb6(@8o!uV3@4vrr$w_Xd!l!?)M2$kvW##F)m21yScWgRtUpd+Q
ztW;Td=tR49RfCB@(6H3pUM1NN@yK9%Ih3K8ZX&@Qv&~i9$0)Dru5Ql@wP%*`>aGt~
ztC)i(>|HDCK4jOH6Gh`jCoV;_o7Bsum{}bhFQ6$(opS1H*{+(ViO2)GePUFV&*AH4
zu3Ue1^;=3@++HbasIuU3kx@7QfUOMW!a+?M@&J^i2#VL&(ZSPz{yX8pgQpVv1;jM+
z`t0?D;fSot&86XWhqcXZWdahanVIlQdC;GtSk$vINyx&jSML$?X*`#TnwfPYJA#64
z-_6>aEfzmF?QTotDxz<xaf8(htruJ<kk`o#I9XRys&n7dfD@mC9#P%pSy>e8!!Ivf
zHa8yw^gdMX^yiI?!QsTfpci7>o^O-o&)Q5Jd4N2MN%VxcwP@NmQ*KoHE@CftOvG^s
zNjgfKJMLXTJ4S|wuR*Exm@HZdTbdQ4HP8?|4vKZh36;~Q#ZF%|tG!l<`Pe5pEt>H_
zeR4Ur++5?kE=7RQe_mO6bc3zy_X?7llsE4m*rK*-k+W!tUe`rvGh!KRJ~LV1@WB_t
z_)%D2zvS}?)`;ZHgoJ$uN?MQ=geed>5J&~};-tpsDk;o-pkWo?wlAP{qQJO9P+Z&t
zGI;GA27)xs%v$n04lg<a2etFB@91BzRGQ@Ic;m@~Yz&b{P!Z#Ni;rjgmAW<T(PQiY
zQCz=K%DYA7ZC289Y)^vVZ|1LFX;7A(2T%%;jSKy#dKipZAZ#20>e47o`-2yvm^&<z
z+MH3eEXO)MR|3=1)8U)}?lWUDNj6sDGcof?y%vkw$+l{4rFC)QMs0Y6YNo8CMr6&W
zk#+^)b;mow*9JQ-{8=xa*zjm>dUh}_cckvFaor14H8*Hn#UwuJTpxBy%05UqK0hb^
zuJ3|Ry!umZ`5z}Iv!pX;0+O<R862*RPBmGz5&P8H_-4L5E9Z(-`!r{whxnn)(x*Ji
zPELmj#zh8;`<W}S!l432`z0$Vh$Lniex+iZ1CJhUDm!UN_Mab=gT4rSZ_;XKMNo|;
ztckij3~*NY`}^bBMc1{(56(_db|`{vu+v?5dhE!N;&!2c#*ep|CE6Pr&=RZ~%J;!y
z1xNr{5c@eeIQH-NH*JC4_)(YGTQ7^#N6rN{+#+!wQ4b!F!hEnJFpfrwY&JA7KsuCo
zJq_A5ea@(dJuTr(Yn!U0*aX_-DH_?2llWCAZb(9g8lQ@yqPwzjPYtPpdvj*%Kf2sh
zNP|B-H@DkXY)Z@<M>zC&jN+mK+U9G|z;#=v>}5ZR4GEU^DQIpWWyN^}4ikeqNb)bI
zX*bS$ui=JLi01mS&iEQ@5zFk&r|;OHte?65nE*6#NTUa%_eg`~@K`Vf|Aw?A#iti(
z;_qk}2w@aASg>R$Dk-{YBK){Bu=04+(@|~$ZbKqfJ)Wy&@9XRFD))|;9byco-nvyZ
z={KIOeKey8-MX<pbDm3e<X<wwV{|Ae5rKe_7<tk#O2W42b^|Fh2}&3PgJ&p3;Ke?j
zBJ&$(wYl=w-kcuX)d|<%*j-2w{CF?0`ZdO@OK**AUi|s<jJmoaZ->fv+`jc!DL0;j
znuR}_RMw-*4jz3yIv*EQX?*i)44Ge*&RF%qEl%w3U$~ypXCgXjZ?gE_H~rw^UG{xV
zxZa`~t5D#ZQ-$yky9Z&8ma7$c(YKm+d_P8hLS@U16n<_WV~uaNTZpS_I-{dJL!!fF
zsp+1N6Mv6T?jHE@+0^kQF?M(t=cl-pa%1-M#iE(l6pMOFxT)43&s<Bem1C}c^AmAj
zns`iyZ8U1(v$4=LMpV(BJ^g3DSt7dwGWyp72r7?_MVdhq-z26yVJF}^co0*U(^`rV
zDue3@_2^xn7$v?K_`y@4=;h_5KA7A8qOFZql`cmocVGtURRmj|MP5hG*90S$m!5~a
z%|%f^&dmYpSQ|cbdqCE^W&?`^MaWcAB)B-Fx#65cn8VQ~r`r(tM^Nteg6JlLC+sj)
zhIUS8jS==}REiLgoQ%GR4G5h*OgdG3Bc8Si*09KZ_%I`|^OELgBsJY+y^49!Vj9eM
zjJ34<wQoTsal5i8f=Lw7gi@TGn@k(=Q*^S)q_>lV&`E%+@nzE&Wq%jTD^1rCIE94F
zA9b$iA3t2nRtu#)m!3zJT*ITmqLXV6R2ikm`D@>|%yio%i_O|+QFNT=agVcL)CqfZ
zx$#MUK3RR|z$@!))ah{y23Y@6$=e7N_X5rdh{O2x3(;N&w)32z2PpCm;a_h&Qjb`@
z!P-JOU@BirK>!&iSwPWjqR9lvHa%qryD<Ehz+83_C@m4h(#7?s>%DSG#2Q`jj-RWT
zL@Q`i`uK(E)UK%32~wgF23h{G^3};X@tl(QHC$Kwarm#KiA?@YLNn8AFp2uyMyl+p
zw2H0Y6MH9Ce_i(e;7j6J$B%yz=R`8xQ2Y-yUH7^D#H!RS(Y(_7`VzHWj|TY#1y8*`
zKJ_Ln`i<e$J7$G8jKR&HLSKy!4H;#eF+l9g`{*pYjCY90#w|^bh1v&7j9CqZ^}J^)
zTnh5!4E#2xCMuqGWkyIazjSg&d>`$Kv5^s}w!<>OMq$g_QF7e*-XosRW=`6{($zQX
z#}|JCdxZP}M_)-<nbRr%-Me;O!Dfbpw`eZRQ^D7LH7iuGW@aOJa3RqLc#-Ne(zI#o
zVpCwdZHsh+*$LEKH*;xEDk-gR{Q1V9^dK=2TXQl-(1<1Mr8gkVF(nNHy45n{;s)Nt
z@TdNnk@EQ|u<t5X*cAE2V}j3Ls&VZUudBLz?fUiK*EVox?)=D{&UPwu9%UnJ6V7O8
z96d5Kco&BqQq)9fOOW;;ex2^)*RS|RJ~%&@3eRLKwu*P%ia<`}gO(PR(32!Nr<kP*
zIRgE{9=$7jfF)wvi5fWVunJqgNu_qa9wi0EHl`z(h}hk&?bfbf_%4DuxR!BWL{@b*
zOJx;G)y>2;xxW+1S7y6ua9}si;k>B3{-+#Mt6@{6A!r*Pl6&+A)qh!pP(3jBShrXN
zjW$S*hpHsJ3HvH8MOSv4*%k)}2VK5CfOL$(4~{zQnbATg&81qrd+hd2uGc^uh~s(h
zlaiA$yk#a%SM=qpS0oc0-8}knAGBa-(V-n*)_<i#9DQvNo^r$8oH%xJQ6Q^)k1LQ>
zX9YUZGd1iYA3Bw~+HM*@w4MFB4>bq4B0!B7o*JZgWn^aVUj_h?8XX<*@|>&d5qtQf
zzr1{T61_c!`=G1B@{*UAhYtep9$gN;flJ=4wF@u9XCAG*(u{%Q<>lfi&V_|L-@ZMJ
zC>co%Rn9&G^oCSmrydB8h|sXJ%ZZGPL_`bx0+2sKg~u4Is-{-_^eIGU?w2pC;x-;V
zidBG3#<FDdOb>Q>VBO%skoH&JE(kwWGzX?rMBlrI4a`#pW^W|&o{%5m?$Ysp_0a`L
zItn24SbuSDq@8yYg@Nl#who_a^nDdBxPxJrCjGVBS8aFqGIXA{Voh${0-LseF}E<<
z1r+=K>iVm_=Vg4?a8a<=VmH`M018Ki+WD46HQK(+D7~wQ`m4~wobtzN3=f3P8*f&V
z=hA5H+Z2hJ&R@@PYynjOpAm5}k_mOd5!8Fw#<8lAU({IYhSVB~Ze4id2Z2JkNwMaB
zxN!Ol&RURc){NGG<dK|a!ARjXdpC#YrJkmy3t(CF$IwzeoI{2|6S)LrMx^;LnAsVm
zaQWMa>{6Gfm)G~-YdF3+BT%{)0PuqfABP?Rl8xxLczp8(X3>&z?%*TSc|~|Nq&UQb
z0ie+ZXnZP769aU}^CcM}hz@_%Kzl+^?5TlCvzMw?FQ_y?{EV!u`I<bKR(5-Mr(@8m
zXfE&?rNG~H`yhquI%toqE`lRQP0J}C(=0NJi;qZ1tRRen3<AfQ@o`T0!lZs<@(y4H
zjFJQ$v*Wj9=TIX)6NxF&4&uQL$9UtsKE!ZrtF*)rAF6=k-R1Z>Qd0Z2oOsul+_Zp1
zoo7{5$av`#wpAxeMI}Pt{uOmA$lUiQe=zL##9!k-iru#p9F1c1E9X0Y4*Xys#<-p8
zS6=VGm9;TKr_W<{o$u;X&pWNVcK?)tvmA}Cfh;MV2WSY8H4NxT8>H|<9RvvP6Z${g
zL)EiqmB&wU-vcj=c*L{|Oe*P^T8!ca2s9S;K`t&B;sQ8Ma(1E2gogyFh4-VP{B!%6
z#xX_<qa}L8;#yh79pf=e63E=?)3*`)#P{pYPD((1$m@I9^Hr0(zhp!oRmoui0l?PN
zT$YHMWdmvhC<#Cpa0kUQ30!MrRGk+%X?soWo`Jx8Pj&|^A){Vjpmb$_YT$Tn`>AfI
z(tvp*L<gDsXp1qf(t%VHp1KV>la7}5q~Yx*=CvbYF9HvKR<$qPEmNT7U<RkGOu=32
zgtcFMiio4b){lm39Z@#GY>VC_zBkuJ7DPMRxjY@dCHfe^5oy_R7`ZG;8)(M7u~V}p
zP&Sc+?56Kw04tGq?g%0*4shtZpTG{Wg({_ZG;XG(+vhg>P6W@ao8QN02zqD<()>cU
z*YUx@U<+Dx!TpPfM+@pM2U_6#j+mQpIYtU>!*E#(3sSZ!T@|aCt>&l95Tx8F-sjxI
z#AFxmA&XlBZ^;%)O46;u9Si=diG}_oH8Ik<-sK2l7rLI397+|JScfp%QV-ENa_N{E
zEr|JN;NKh%`<y%11E(`f%?2P~?lVaShK8Yftei+42oK<nVCIfe(aSel1{DPCrzG+-
zLjEA7eHyhXuf5sg8L*)+4k~Q)ZcLUHkxZhKKzsqZotR<SfhO(i`wAiNWaKMbHqkcn
zBEg4K&9?&J()R7R$A7R<YUVOsK*z@!b&KN`c)J^rE@J~!$m6F+y{sI9pyWjuQmhy!
z@m#fBZ}8n8_1(S<^vBm(e^_F$Xes<&1X4N=7H2+t7GL&Yy<Prl7<vSrFr*CHtb2ZM
zYwwqD+Dj>!C>fu)=2AjM*qT#qV*JJ5+qB=$+Wc<G;E$;_=YqX}0^TQU7j*W}Zl>M5
zEPt>!<+?-5pXCn`3g_gSjap1u^~E|>$1jZd?VP^kklWeQ+?}Uj@>Z+j#vnmHQ#Q^R
zA7_^KyYAg1E!K=|cHP~4OQKSS5*t%Tu=R^;Cf>h~ryTbA2M-1xYo)&vf6`NdEh$(@
zV%qtn11(uSY<Oqf7)hHdZQW*f7Y`4R>>y}RV4%)bsby~XviN6tM!#9>Z9{>}NtAj&
zD?(o;K{gi1Z@%Px9Vi?c`>n(Ej5$ibuKA)mz?e>{tMjvCV}7{{Vs;D%+#^qO1LrY7
zPlI|jIhi%2@o8BZy7L*7Za}hcQ!6W+Q%H^Igu!$yl&5UlR)My^<~(Zr;&vQlnW_&d
zf0K57*}x9GQ#Ac3G~{ST5t*|-`geU400!W)kbmRE8(=Bn0UZP-8+=PD+nG{!7}Nx8
zSTVzCyC)nP1k$i^^e(_pP^18hN`d)Flwr@TKTe_9XDG2vi_FQS3(CrlHVP}G6~Vpc
z9(*dfS2a@U@9M8#DqK4&O-6tgHc~ilM_mS|AErJopd7_<3};eENHdlnSZ!wc38pL&
zrUt&-XfBH)*GRN8YFg||GZlrF+ld9wYT#q0psdiSV~Rb79O58>4bb|41CVVcem@j4
z2k5B)@PgHA;Z8m#DT%>?9uU4Foegy~Vq`Ewn#I`YF2}7VI?@<7>`~YzQ3qRIx-^20
z6OSY~;3tch85Oh`v`yVv?gFg^y+dMFZ{Kc%%kIjRt+ce@p7{71fXzTXjpeKoJ&SG*
z#u2)6@dyb9%K8-738%uXlce#aH5g3gsF4mr63v?{?leRsPzv_+kV;Q@`7YMcy0=fx
z?%i24)t5Jblo8bNpqg<0*P-|;?Z;R|cAzbze>YaJA)qoq7V;YK>WMF3m_Hf2ySWV)
zTd4<1-fCT+3%kF1P=7IV)BK|pasAXcmE<87e!?mjA2E&5clNZqy*=K1;}8S8r@?on
z)bhbTqX66ErcdYmYc`WTWO}z_@`vu}6ZVzQBLgqm#H$BV{<L?Hs!3l?l6T!6;i`CV
zDUPn*W#cOCy8I#|ahBgAGnQ6%O{L+BBaQnuH*tqtdrvRrui^gv0w5b-Va?@)MhhvT
zQ-Te1y7k4E3)S>6Tav;R6BC)$yd83{*+pBba^HJ;#&GGnWd-A);yQE5-iLMt18r}r
z$XzN8EG>v7@62~6?VUH0IJf+jk^40k2p9xAjW;;wh`*b(npRsQF`iBsXYs0hA7nM3
zPkZNi#*}mk92(qf4&e!YHCR$iym}m6^?wxa4k&XJcHAW~e(@sdhPNy4>WZ#;PBu!i
z*5os9WqZ2Ho2DYUV15b({cB27$5$P7sc{?E&MJ04X8$}tBt7i@sKP2RA~mMGcHHR2
z*XF+MBj0XG?Z4GjqwkLT?@e3Vle(P~y3sK)nO(NDt=lSi?8{cM4Z<VoJzqR8rO5z9
zYv9+u@W}wK*Kn=d985YYjmk15C528d{DWtLM^TAVb3lT!k?CQWh(8^gugPC{rjWpW
za8q7|rl|<+E+pElbu{UaITf6U>d9>X8RwPzJ+U<}DMG)nKqVT)D~UR36z(um&}z;F
zj1EW_B?mtPO*y&h`sWnxwBDYXU22<H4!)vU4}O18uD{`DY=`Pwi*xN&r6M)bJ=yJM
zgNywXoI6LBvzRDU`Fqm>2St0bZ~u0jKGYx|hgIBv<L(6i<Zk&dW?VaEE6jhC*cP}Q
zw4?~g`cq>RmqjhGs~|K__t4RtZY`sPCZ)Hd+Rw<(w(L!GId7k{#!Pd9e(Hos;Z7V&
z<vTehQ)QWP5}t?*qVSU%^z0zHudqsjjWJ1%IcMC7);{_SpWen74{Bn`{k|iW>p1iE
z5{}P1%pz8w?@J5Zy)ClZ0s_J1H%$S00zDk#55hbP1;uYetLaQl+qm%i8fLsgcounh
zXyh0?p(!d{YO1OrS+GlEm!hNoedA}lv_M$ipHDW{e~RljsXGUR=`i1V_lnK<_Cfn6
zPc!3RawV*0*|rINkf>D^2)z(d!>{!+m`0oYgl5<hXSd<ITIq?E=DxSVcQz$__GM#F
zwVG_NvH3RJcJ0gXl@8X$o7OEShkHbg&VK&x_+!H5i%>{~<x$zTdwyH=wwC&=@{=Ut
zQlZ(qmxEr&P}p9!?OEO>y*=zvC*P0c5A;Nl077ceUJNnc?<bOM8A$r^-9^tE)@nGY
z6ta7m2F}jPJns&)GPyra{bJKrl6af(bk%;UhT-Ar;$rQ*zH%%7x<hHL<a>;|-+%Z}
zlh-4LSCGW#9JUGlGs_STp?^YYm>gFXo@EDj1)%IRx$JoGYA~V_q~(8AosmIPRfM@e
z$>|Qy=jG#e=kU+%%kcNfdv7Bv2b+FT(bVH52@P=zXXnU0UE?mt&W_OUF^JFJuB0`!
z^ZHOQNj+P)1B~m0EBjgPqR4*vp!T+NL9r1R49geE_x#Y0;u`dP5YqgF9>>_Zn^x!*
z>;qr;`SzTB&w@AnTOxn~-s}f}i$3)&Ts=)bL@d!x*B{!k&9zxZ12s5fFr*Env<Aku
zo=p);X*aiWMoo#>Pr11N*iMjsWT2HHKK9Pg6qlMqq$?n^-*!m@XlhD*gIHEc(-Dz)
zy)?Uo)(JTaZi#<?FG+p^Cr;fm<7f#5>61{<aJ>|?!e4pqsh9YC=l_mOAdcP2RebSO
zC_bC|1pO~>xGLjq$ge5RA1|W(?~c%B1^(~m{6D|-YGV{Qn#oB-_HL-}r&4Hn5vu*4
z{5AF`wLn-FU$2sT0u7tK<3pX~i@PS7LRxodm$vt}X;@D#-PHZaah3F5Jn&w&WnABs
z_gFCS!V;%HgWs4dIqBttA&on9^3(}~2M-o|%D0f#M!d}(kC*0sGxl_)u^smaHkP#k
z#hom2qt)8FYo&Dm-CV;AR%9ULNWOCj@**eWiaVhBb%wo;VmAEW=c0~&d2Uqdwuf70
ztoBEX6SsL8@(+eKpI4<9YW2gv@7N~LI{wN+`mV<-^N&Y4L|Bmkd4!Snms#zZ#Q$jl
zlBr3nSc<ms)~oSsr&scn)jHcI?HWG1PzB(_n|AIwLGPL7iH~MSyYDo8sLMw39dgqB
zgGtJt*e?4oXM=qUTf)D$OA+|hyr`aJ6~sUIe|@_u@u<(1`KFIU?>-jd4(a8mmB06r
z#~Ni0{+aRha{91KZlHwybM5NPdj<_z)r05R{>)!6(lJ)cV#uhiS!}E;+oQ#+J7_5R
zTXIX2bDDOp>-<E*rT>2IB9{!Sf2N*Y`P#z!Ao+r|rRCTkl)JO4`q|g}b!K{bCJG%*
zb+z;dO>|A7S3duQ=_K-VMJ89|=f87TEQ`sB$2z$U)tp4<<D*`Zzlr){fp)jxfA27)
zQ_#Opq(LFS+i|V#e6({`uI}{G`>%(#C5gBvxu^<8erB$~Pdh=+C6;I$OK^;-E;6U>
z8`7pGBlj<D8Qp`d6r`pSpqae}e^(BA5m@n%%!TgqC54qx^z3(Y=e`<YR5B4VI-ij-
z<L-?d$qH6E@1mTuRCaL`#+|9DtZQ}jg=6=t@7r7DrzUo+eJuHHBDb}^p>dN`;QT_w
zu8PH;V=QNG4fy43=5|%thGExgk!q2GJp4-@-}jAPeUjHkP0;X%|2)b1M6Y*gnW}Tz
zo&3Z@HNnhNrl-TP8a7vNvblMBBHAR_>duE_yM2USm~ef+^4)@Ma8V-2ns=*uIAW)F
zGcaH(2>~xwO|`cOd4wrKUGUJlQ6<kj?VO>LG^|u!N$Iq6CpZf8-><DZtA6KIF_n~(
zt}eIs!oW|bClQJ+VR>r(wZ8_Nl;j!oKgcI~*7|cCW4K=Zs9-u|%jlEjWjj}2`;$ME
zpt+wePukAheWf#a%jnMI^PxlA2{A?Ih~bYjpV#Y@<jK9r_4pm`7KK+`T|9l^C4YL{
z4Y9fP(txV2ua^n><Q>d$*B8_6zTJ>n53~=eR`i+rdc5TRgO_bQy8tO-w<fL5tj%9f
z`ezO>cb^k2zeE*&?E2+_*wI$C)*I{2@j1`E-ItFDjj~-kkr<Fle|`85BjaIp?Z6s^
zor~J150bsoygVq;OmUmLl4D2csb92JQ85G&dm&sy$eH##4fnHIs?@a1quU9NiYE_G
zX-U_P8U(abczpYEaqd>{DaZb|WAi7>+Ecdmmv4Sf`Qb38&KXzctUq6NFMhgr>&-N>
z#=rgZ{5M~ix3sm0J*RN6x1W!@FXxp0?~(fbr8880f@daXK=9<=z4wJ_cljLMFP~kM
zQH1yg%0qwR^aZEB_5`*%Io6+_*cz?*Qt{v`VX>_Ot;O@@m-@o?oy%6QQBxHy4Uag`
z*iDS_UCGhveMnPq@nmM)MV)@#Y2M9^M-aoxe^4Pb^MT}BZ7Cy5mh~rE{lolk?^Ny$
zPw<GTB#!5+v3(vKt)C+Evre&nK3+m7Y2p3@X|FUne|{8H82X6mT>EG))}-0ga`%4=
zWo_5gNq;Nu9h7w2+EiL|1q!wK?n^#UEB)}|^+w;-IPc#8nlw%mr6MKmf^XU8rKu$K
zkEnl(BIn($&dk7{%NKi#>t^V_l4uo4u0wT?>W3Z)5wHckkAF|pmq~Zo+~bt<{TO)3
zW8O~bYMtb7St351%RbpCM>mYTp{`W$DfL&jweBLkccN1uzq9qALJ6OhF6Ga*9woDL
z%32H|jbJDCA2a`E-XVM%os5QiL|c0n@9Xe?yGzz}w{iNk<2+NlFmI~NtNdqiNJJEu
zw!U0VO`?uIA^g(D1uOToUbS}KY5r;-x!)I5BFRkJ8x3z#ONP4VKKIF#91y**>a!%e
z?6HGfWZ0*rZ)wUq;*pxx^#lBJz0Su7Do+Jbf2J+L##>aC$M2*yd|;J%x#|0av=&7I
z-xC48IDHPAcbeZ`h^$<&yz(ed$4WIQ^y+-}rsH*&t~*a;4i^e$GV)1&`#I`Ov!6JI
zFG)#ANA8&fSTKc&9FvliI(7``>cX=*#)4P>w&os|B;a}FPi<=ovTEK0bbK*veUk5(
zfi21?qJ8kK-A8_*-^<HRFEqyOKTUJE->Sa;{bB?A;PxLBo)qm&tDNecgv(*sroko=
z&WZ89rFgb&vU|3rs^8Vj&JBNk+oxdEV4LdC%ioL*wA{v4Kfd#k2wB=ECOIV;oN4;R
zG%W8Md!)3f(I0b@(aY455{jFHsl7PQ+tgioy|?|tbItT8Wl`_m8MO>Mnaa+|ssvm)
zvVZOLcxCjowzG}1LuhHXVx+6rtEhMPs3le9+T|oCDnG5>Uj1|Gf{1{n#ibK2L`3YP
z!?Al}$*Bc|=W@dy9o3GKjSRG6!gggYd?SsODI;vAc&gc6F~6JZ)raT4Uz;+%elpgB
z{ZW}~jEXwoqJJ7=VAI1>+c(@pYMBOXW`B)XQUzofsyS&23p5_sVl5MDqEAPV-@TB+
zq$X=`zGNTxqw5s)oAQU*?wkeB%+9wK(WWv`RbB|-u#Kf45=3lyjuN+?kwVXiXbZc;
znIghco2W$2HXQU4Xx+ysn|k1JPoIq5*|na|Df{P!%X_}JrIhdg_teN3yD8O2ygSVx
z!_`ujm=|7k&RF4^Tj?ofhlJr*#iwg(``yC*yI#9L5ApHWVq&1%PIk)bu|z)0^-fW#
z8nc0C)O4BMnz?oT^$B|K&4vD50HjVm=Xqqv!QeJC-+$DJl$d}&moa^Q;Z{+45xv1z
zyX07Hd0l?t8v!Bz@~9e%pCHAeb%IOPqgzHe)(R9IfJ5nYSIb@6IXXNH9=(pMbv;RI
z-lk47LI3?Ux7`rd6&FW0e=;;O@-TbE9&CXE77D^IZ-p%lky#HR2eh?dVP(96ZXEhw
z9Xsf6Wtge`b!@D2P?EteVGpFSQIF3V!@LGHIZ!?ZCE4E+4gaUCZu<nJ(^G~mr19%4
zZ4_-|k-+<-UOWePhHB>^vizEY^S|6N(nlVmYc0my2K@O}x9xv!wO^tlfbT=v8x*u<
zk3qhos9Um;R(AAzRj0S)e{bHJefy>2eY|l8o6Nc$a{!i1{GDcV;RR2P!mB@KQ5l?|
zHyx`DDA;X4O1Md_&i9}e*z}Nf&Te_A;;Qejkws_ss|zxz*S?>;_NyW43WZMy<JMlj
ziNAw?mE<EwTAKtosT4BLCEwawcP^=*%OU9r%OOgQ1@~p{hj!}*+(Pn<*Pj$UYB8LY
zX>q6@GuuoZ&^cA6Y<Y%jZ^n;j)%)cFxwqW;M9&gzH8Q-x_O_E)n7=RKBe`<?C{Nj&
z0}^Mlc4rwUJXl$tT{KA*xyHs$%<r*c376K*e2ksDjY+Dfuc@+9=-2lRA^Y7onm&jM
zEY9DLsY$9SH+`3UKhe?TmUqt&I+JY`dc31I)>~>Q2lsG>KfSKJeR11~?q7Nva|?+(
zj=nKs2T-@6Sd-*kZk`xb8EDNMx4pqUg*@yL43`RNnD3NdP{1Z^?)PAD^w+_gR)%0o
zG<nbyKoL#8=>(*PDdk#o*3h#<=7UgGOpy8gM{u9Nm*WLXOB~UdK=FKX7W5rBHw3K6
zp6b<#3r!K+W5C+2S>;`FeQw9`VuA2}t&h<%d)~#jd7ks%ofrdef86IC<S&Za&VDq`
zZ_7Ae`z)60nbueRilnW7Y@4du#m{Ky)gI++YaF>Uu{N-kk4Aj$X;*tgdG@)LPfxSo
zO!M`(uj-`fuI+sKN`Z&ztNd-QmUZWO3O`Bt!^c%ecKj)1%^%?D@7OTO8`z-VI1o7|
zv-enmkygpkBaS1Tl`lR7p5;y%VtMNHVK(yj+b5kXt*!FWk$bLGCtO~S{CvgiP7U$S
zyX->y*aJmxx>HrpSauQ~CL;$vht{V4)wpChBDBN!$;()>`PzehneT;W&5pQs`LX%i
z>}-@!a{TN2!dosf((%vus}47c<Sy}Z`F8we)`qdxIUdPTHhap9YQSqFd;lUl2n>PN
z!*PN~PtK{z$OigFfRnBs9uOIR23>=Z3TzKf@7b|~i~xG`7Xw@vgQH$w1d4d@b={Lc
zq^#3JTwDYx_Z)b4h&YT}K=2`T5yW5<_~=GQZ(!uwnKK&aH)ZMQ=r|4*ALQj#P4D`(
zx+-W`{8C3(nDz=-Dxmj!85nTvv?0M4y2Pd$gmi0R+JQXePnY<Lc*0hZy$t9vDlX2(
z(y|BgUvN7ZCD&*0FeBsQ|EyiMK>GliK#?oqn+#!sc)7Tglo1a@xjiHCxNjOTBecw4
zCMUuB-@%|Z08xkKU7=@Kg8opntx+izRDjiN7*x{w=dYK&PB-)YJppaqrg}`v!JvxU
z?^UBOGI9$Dv>CjHwh<a6AVq!PJ)llGn=I95yS=p-SmiLJ4$!3h(}BQ{=8IV^Ps=H?
z?GW$}xbadq8-m5@sctIl*VF&&2+@B_G0YH_8WPr4R<fQ8=F`17M)`Q(tN&<G=-j|%
zAkj&f5zho38SR`U#3hbR0Ia$Vdv&=Z)9SgrJ~nBOC!iZ3!UZY-kv&p2fMA~V@sde7
z&ApYH8rU<K4Pa^T0Xf92oAP=;H#2vCN;wni5>px5AG=#W=J}f>xZ@v8wHZ+6$POi%
zB^hcOmbx}LY$Dt4m&|Z1<q@4&&r-LiQB8SO&6iUDj;&i*<gen0jWIE$Br1M5cd-AA
zE(^+RYv9XhuK&DN8nw|#5Qj5*2zDE1{HGpzl4g?Zl5dQAUwy-ehSU5{m;W!u-ZHAn
zwhI?sfS@2CBHbV=jkGj~fOJWhf=G9_fS}Ud-QArk0!nw60!oN9(ww=zZ^t=%oF99Q
z_lM&Jaq+A>=A2hOzkY?G!^i5@8#pe9PAF-h2q_YsiM-kJ234YG%fGoqX=PrbSj6&#
z^C~|5A)zf*6DwQLteJeCu|fUe#zi~Tl}~xQE7s0g%X#Dte%o)US?vLbwKlImec);s
zoG99|W;OZ7ThzplLL@aO@9nNTXnPOy*}?mv_M{jm9^vl6FKjD54<kBLgkLvjK+d+A
z)2y({`Ka6uzYHbn{N<P&r>2to%1o<vLToI!aOLLz`mrei;5@v*>>u*+3;`X^D7P+i
z`1utx-o()DN8rPM**#uBbN~u1_{4|J5n`dMYUTr?`4Tn(Q0&%+fcyq8SS}!l;(zj_
z5uF?~mWCc150ZTn^VlG12N;2XzEBE#aKrrQ9J#&zw@eI~Z?sj`pmQla%zX*TZV(!A
z@3Kgv1ay2bxQ2H#SE9*|fS?|I-~(16)meZI!}9EX&50;1DY4Aj*T4bki4KSl^w^})
zA*vIp+o}G1D?jO6N*B1tHd)1hGugw~XdS>rc<mzrB1l!MHG#o5tS_F$SRmWMYpPTm
zs8JM%Zvz7`o~M!&_F{Zmu+g&9Zkfq=7r;zFhEI)sZ}%?|w;6!glh5Uk7Fz-c?X(ez
z+~%sl32}0&6{7)vIauEY^77bBfBybm+<*KNQn5x-l=Sr%AQU4s;R3WFFfj)UMhlBg
zz)gT=(*;QhRDi$&2VtgZMm*)0Sq>g}fPu%%!O;;+hqtX!XBjIY+zF^MP<epA^573U
zk|0p^A|rYn9S;r<t&ANbUcE;9HW}iC=Y?zAI5eEtuf^>WuVJV8jqt4LEW2%OpUIS2
z+R{-jInOM9Qn}dtvs&{U-@;wG_LB*F=G-^GxaEGw|Ar-YnR<!Moi|?mnrM>17|JNY
zqB1>3+t2Ct-ctNJb1I><71=Z^J{mhV-naaf%?OS)Ty$g=YPb{R5<~h4nM`iS(ctz_
zq)<E=nV0WJ?W>fBW+{r|baC<8%lYCw^jsUUyDneFEw^D-77!<q)=Z^k7t<8Jaj!UU
z+#+qWH?1UG^`>W$w_|-${kI41LikM>r|4^voo(-JboR%-`V3iz&1a1>p)5bUNV1UJ
z{>Scp)VsdMS7U4c(Uf~S{8b`AM}_(M-N54juopfQfQg)3T=E$<fnU8*oe+mnTeSd0
zcA%XgZsFiqH?4xmM`5egWm_iz6}!{x<i~qh)SO9HfYHFk0nhwkZx7`yjBJMrUnZ{x
z+!4t%Z-!L^NUSh;>veR9B1%DYxZUQkhK0`ov_6^FuUFw{z2!d*s$y|*6ec`ELU1%W
z0T~isIS3_4DbGQ741-G0LCG-?aAMbh5(JTHeg?s3Ip)nk=m2O81Xk|>e^M>FfGsin
z16UmhASVKpU7qxIUNb)^P1LvD?-dvm!uxV)nuqu<K&7WD3?o8AF93bjAq<4O2GW**
zN{fw+ZB@zq`0?W(6%fIODx3i>p$MSO)0!@VAUd+>+dgP%5#I&}r8X@9LWNQU=;1h<
zZ6_yg2q3LJ*H-|7AZQo?BomXqgjj&*dEW4l2qa0BKxj&hfaOcf>YL_^oiw5Ib1pX)
zOW{pj{DJ;xnFCH&<<|xo=^8ti&W^~0gh%)vVetac3!E>&At9KMoP=ck=TFF3#6W<9
zHFz8*0vc5^^;Ab^7O5kNpc+_n0H@wzC0s!Lz(*0JF+sSL#Zy~ASD?YW1!N3>*TxoG
z*yi5AiQ@}#hHx+}wtMTAX*67ZI)=<;JBYV5^u0U+zznKwk2aA<kAB0w1fQQU>|VH8
z$hX`>$EMzv-_t_iZSv8vo#!i7puJ5jJyAi)>fR9>t5v4SCIKpv$8ulXoCf=B?L~iC
zjg{I;w3)kja^4}v<zSzu>7DckcSA6bf0VyB(W?J$9A?JgEa~0VYhBVIbXL}ur*9W=
zweGg^oB<{aEVak?2bl&K%iF0pMJaHmi)t-smGFKNwt9@t;l|^_d9G#=M?`nqRky*B
zG0H(*AKV3uZ0O|hzyS*bCvVnudsk3U6iZ2<!K)uXC@-wOt;&1A(8>~n%THTLddNe6
z0B^^SrE`(77x6Z?b@gt0r{q&Vc?+IzB@eE9#vVW-E*IB51Z35XL8{2dXGoD76dj}p
zpgTp~ewV)i*kwBi;DO<g$YVJPyq8)XRyefDAsz}|koE|Uu@I)B07;nuxq=cyT^&gY
zfXg1qFojPobYR1&89>nipc{aI9C!ziG5l;!DfJ0BJ92{;C@f-41NXI(igqJyqPiBh
zy`LD{Wa0wfp&)SjRw@H@Qge?cDp8+Sd(m8^ln*%G)OdJccY1!fQDZT|gj|$x9SuyB
zsuo4kX*b$s0ZSaB0fAP9>95Qb_na95Ur7;wQGmnN8*A%JAlPP~?*q82(-z?7;Sm%V
zxIJC90$e2EEdg2!8wCYH&kRi+1asa&YD|$V2aps43WSM(1LT`hK>zXX?qhgxDQ}th
zc>24$^Zi~yI28y>5xY>rdAPY{u5ttR%Ss+<_L$7_9nG!L8_D?~p|O5U0vI9MDl-pm
z9DEmz8gyq`EK-CZvCBagtUP>t8C<5g4&%Uazy#k5w#^cd4Gx2N2?B-r%K_3b;|4_=
zNM%2pKV?l0A0nH9Y74HB;oYCWD*=2S0x-xRCKui-GJ6uTKcU~#(khwofz1Hy4ZV6R
zZMbIObA+%jqynk_P<_hSwENs9HzdSe@JmC(Lrqz}e5Z8qpP#U}Pe%vbE@z-c0LckJ
zbW-e~C7<)M!opjG-+FuD{*g$KhrJ266)>mn5fTO}KGV~i2ZDAO@i_cXRaI3)W^L^u
zY%pkRu<zXA6L5m78A&e#xE^Tn8%Jjt@jzCBj0pT2fF~n9EnfYgiHM0&>tp+Y0iP;V
zvJoU4s9ien$?rh6%-(~c-v?n+At@=kV4x7tqE}L@{|^Amv@~y^a{<Bw&k!st8!o3^
zqN1Z6Ks^mK8-N#qw4DlX0p1AkSOLofsrrYHA35H5nI*X#NyIo68B4q|Uo)R$<>2d@
z%QMw5KV~+LrwD6_aM^403ieqSx?cK;b0ac?%AoJQ+W<On5j#0wCH#9LOWAXbJ28^n
zEn669Og(FCb8t@HB5Nt@`*GfZ`|9gB$`FswBeS|_UH<RsF6rFoyFR9j_1K<Ae3WHb
zq!vFuxbMB<yWJadvEaRwT<Kssp6>j<!zEV0rDnVPvF{nZMyNrv)oOI%VaZb3)y~wx
zWH372>$&tPSD`}h-2&?YoiCfDl;U{Ua!qs16D0&5vK8aSdM1P1aws9OKe@0xHW6>l
zANN9iF`N@S^t*-yz~)&{3dNi7Qz(Mt9PCgsa`F}+cdvX0KVTpjur*Tw(OcWlkow*|
zH4P06gxP-tcztWo^6)$U0?}_KQh*1iXSd%s@SY`P)__k5BrAo1E@A)fbBmaf1&)#6
zzQ2cu7YTQ2TwI`#Dp(~0fdS?fNb#Hm0&yl5ox7p?Mp+q;EZs88C+ax?DJdqRo3!h>
zvW~WPmNL?I5J3WAL`>{(q_?#}5d?Lbj<6v72zae?^;LsT5w0baw?LpGAxA}kVZmV*
zklWWKfN2QwV|RCc#O~<@?C|cMp1#-BU`hbz6Z*_d^{aJXX66#uPEhg{<mWfHv{Zob
zihgy7X7JG}<PZ-G4c)=T1qm?5tiPTO0&WW#0tzk=FhimmU4kx1#t?3>xkXW40&@(h
zvv%E~s$M$e13{iQ6v&A6rH+oIB+|~uV4U&jR(8|aI1@bcYzA2%Q>^X(S7G1^C&~@+
zVeU3yPK@h=Y!50);4WDj-vNH3pV)Ah+C*t!>I9^Eh;b<Oh%V5>ud2d80Q4|E5^SXO
zE=vj8G<do|TzE#O0;QvumsgBm5Hh#*9O8ySK>-9&2u|eZ<aB_rA4ohGbRGQs8JQph
zw%ah)1!x&3{OOMy3^{NdvW{wjtKkdv27siImV^-zN&&s(nNwRJR0E1L8BuLbjWG!b
z2J`iE-dRu46(&mM$S5iT2@MMumx{;Y1vCM3PmDg`+REvIq4(lqJA{Absdjz+3bxN?
z++=}IKd<arSzB*!Zwo#XstaU0dZ`ln%4uhKJ#?C!bdOf}rh~ihV1Q$lJyQv*=Ee(z
zaz#nmn0mu3I@oThTh>)X7-r@0AU>_wJ$NdU)QY<8P2>CWL6yai-RaVk{j*>J{kpuS
zT;GQFqzC`rqRYYRn00soHeQU}vPHRZjv4y#zb#g*4&&7si~n_9lyfp*hc13Hlks20
z(?diir}$oc@f0+;w7&c^R6;Pp=?D=bxy{`C*Y&-b!<@yRMQAa4BMnu|YRe1^jV*Lb
zl(C&V^2g;F?%JVyv30yKm^|Z9B451?(N7>+M0=~nLIpO?k+c#(yfHC(pvn*DTpKJu
zxKc3@Adg=!3WC^PIGp)i{v@`v2qGv1U93Qy484R8q^YAo9M_`<4^TcqAqJNZI{{XM
z^&HG4;HLcgxF0S)+tT;hg&>CmcNJHlR>QSdxBzb3UESThHVsIkbhvV%+HIIG#L(O#
zIK@TYR)}5T3W8d!`*QfxIb@jjp`p;r(2>5&zlLD}=<aJ+&gUKPED;TRR+^s~AHuk?
z&I$~NHA+c9T>{)d;7S7}^kP(wJ*$4$U}fyvNf=OR5j0^b>FMpjA%ad1hEnY9Cq~e9
z7s~eq(NgN^>Iy>N29koQi3yN!w(oV51IyB)WrkH*T^-D4Y~oFjm*Jm-&CU0plR;Br
z47Uh~cHvs8fB6}8HPX?}4)HcSo6eYmaKD>pml@15Tw&}1dq4>aSWL`Qm}Q{6rI#Tm
zPr)d_L;$&Px*JI|$G>|QoFlq`g&1x!0}~GDj8MfOj#X6?nT++~#W-lk-#c0BM)s|N
zJ5Fgug>7pH`pHn;Ij-o^-=n#-&ZN5X6txNhrl8C8rmOCNsrw<XujMx2D+i}Xh{|6M
zGQ;Jf1?X-z3g-glrGayC_8;&r-5X@dTLmSWIZS5v=5?&^N&K)iVDVtBE>x7hxAc&*
zzmW9I^VcItUc(+rxMVlkUF;8K+Rh5qx!!iA^l86bO1aZ<0$&~yjk)%C9krm;(AKcP
zAFDF9zpYmE0x~!MZO=`?lxbi9r|lMxw5)6})Hm>IX=#CGBYHu>0b+pRK>#mRTDk{R
z9l#%N(gXX<im5Fak678-B275~uuP)*@;Fo~2f`B(G%?>{g?e}hNUA_{1HvtvJ-Lg#
zXgHw2K49gxk})J_gWLQuJa))b21kG_X5zKmJO)$N1>5ZpasuHmA+3R0-5udLl#&8q
z*v#`m89o$rP(4BW;3t-;S_HQ7k<CCLN`~V!*u$!&PU&d^77Jp1<uAMD1OTmMYocEc
zZ=W=}!R@uvc;XqCtz$d9#5%|jlb{=%LdfS!FZnBets=cO*vQ%J_H8S>h|I#4DLG53
z*P`DPdfRw1Jv(Wz)r@Lvs9Jq$WmWXGv`G>i$2up`Zmn;_KQSe_&}2|hE|}o-xmSME
zd<z$W9w)ixOo+&wEZHG2NyHVIEM8@MSVZwo=<{i8pNjbi#GCvnd(M`yHoDvTKe+&N
z3!m>HiV4*JZOQg-$|*faXDVjF+8~ujWQ~~nhRnysCS;E@4n35Pys`0SWi-_~EJcc;
zw)gA&>p%_nU%#}4^LDoX_Mpx!<?O`O7G4B@iQXJ-{1db{K7`BAT-d}xiHQ9E8umgP
z+{`du1bQ&|dJMa)tWzQ66CZ;>?(@RJWgxMESVRfb&pKLKnRl7p=na7(-e3I(l5>$0
znk0E%%So31s3dV-BaabpFE4uhk5vmG#)_t&X+-+qpg|a}dI@dJI{H7j9}2UeFZz;`
zNqrxO?HAPO7)f|kREzN?X(mWL=H&P|P<26(oISB`{XUz)m>outbsWL1+1Vh+1GO!Z
z-w68jZ?4WzbP-7jg=Id3H;$~!DJdy|{AJ(>_0=>jUpsVKgb2`^zVSE%3>0+tFPM;R
z7SxEQ8Q$I1NY`7Kg`gl5=yT1_prtgcL_5VLhbD{TjbhOY-eZBxu@}0!bLC^e>kO2l
z2Q!cGdI+VBGtpjEgDE-C_oJTELu+Eza{d{rx|x~NyaWS_((m<oFD~&6+kF}jD(=lU
zER{2<2wf0$(5oLd5L3HnwY22Dyh`$7J<9!UbiUpDPl6&`{y@G=nO#_Sxbc(gef=xJ
z-Y$Qo$@T?TDRySWv{Q*g>if0hj|;sof*5-oco&LKd}6os47Vl{<W!ldHtW$gcrO2R
zxh9;p&Fk{+$otIZY%BQFztP3WREb?g9&2z+!e)YqZSbnn`#|68=`WjI2sSR-nwpRB
zZqegoGL0=yzV~5W4-4#DgXD&0@HT*16bzuP&*^&TWd^}`Yjl*8iK)0rjtA^4;OGZW
zE;7hseEQVip6+(W&`vAu7mS;#1aT=TaON$7gaJ;!TDhln*zY?radB}mF*%&?ggncB
z`}VDP07ljg&4^dK#={d;Lj;y2+tkUbZgVrUen!`=N6Mi;E{k?3f`yxZ91iKE4K55?
zFIMsgwE9Q67Nd9sTpbRG-l8#>yCRw$Eztc`vXanGDP(DT=tr%1*}vlO{v4ZnL$v?X
zdUDNb*>8=YC4q*${x>2C#Pi0V9KCz0#B^nHZI!$%4G*u3_X-wF$}RI-CG6g!KOv?5
zYrex_^6A}89+QsL^P>b4Q9J%SEs7;m$(RqiEgn4m-V&pk)<Nn1aIds1aC=jx<Q*zX
z=O_$RZ)QgnI$1~;UADw5?%S=udFkX+E@G?bb}8#I4w;YM`mIYTXXWGavNZ(N+rB?^
z-6+aO>fv7z%~)u5@ABneHROEx@$~0K^%u0Mh~OL9aVv&#$=ahVJiaIM+X*f<*h_zC
z>RfB=OQyK@qR&`9nX{%4%Rprt2hSNYw%Ax%c^3OZ4Q{BBy>_9Ifsr(n%5VagX@uD1
zfGiC(29f4f4+CE6SQ7`T*9nPyzzgYucBB;&f8pRvOVbD07+j9fp33)e7lP*jD7RCx
z83+<5q<~~=4@NF*3Fjc!B->f0`~s~LNznJ+UJvjOQ7--Ndv%bZ5uwvylg5FDj`VpE
z6%wLA08c$q!whAd78Iyv{{fdCLZu385M)HaS2Nh7CXe;>H<`h}&4sMKM64w^Cwz`3
zGzld0a&y7L4XH8#+BA%SGayjmKjNzHs;6o|=>@BtpTJ~*BuCzd55YKsA7)}))?IGN
z$nLV|Ie+(>1DrijohrNGsa`<$<=M*r1+WU_NC;F}klJ7{wzOJ57k95kmu=@h+S|XX
zesl5MwcgDM6V)P|h?iO<j=Kiwtuy3S<fk1!2Dv=7Q9hlcQEEsLsTVWq?ir@b(y=lA
zj7G{r@9YpddX@e@*GBtP=5Un2amPhzpX8?z@8>b2p|nlQuHZ!%I>c@iX4Kx!9j6o8
zb}wn2iHIEilr0)36}~4ag`z25y<pO}^dbS|kiP_$;EZ!Z%0eM>o2(O$97x*Fqq&0}
zz||ZW*F_T+QO{!|BZrSO+Fmfh?)rl~Tce}FdU&|;ZBrA!hcTE5VFdhuP6s5-^fH@A
zXAgZRSchF$M_+RUd{%~-Sr}bwa6N;5HIqL8G|%}JeBbVBy?F8N7okXc-FDtR^!P}2
zq1w$KFK1RieH_COsu+d<kW-YH{5xJJ?lS97QE%mCQ6aRVb-0Zdqlde0AUa1ebSm<A
zPS?<v(k?R0>pmO!$vq{e&^Z$9tM1O==~9*TrnE~W%t>(QaX|U>X?-H7L+Ht!_Bu^#
z<xOfCHk6F>(P3g@+>Dzn%Aw+NCE7%0@%#4Mr=1tJxBOpg>Btq~gi;|y(ys0f3|q)<
zY_B@*mbK-(Q{%SQNh>fO9d=rf#{XTL7yh(OiTl|^TS~5Eq})#!BXpMvMXZt~Cx=Hs
z=QhGaXKJX%)ozFe_j4Ah?9jUMtJib>uh{R3kyszN?DN-dx{h;qR(ESs<I1p6HN8At
z&ts_+kPV?PdOPH4yV*kF-&c8<f1vy9Vo;yvph{dO9RO3aWZqwm00+Uu1u+aD8MJdS
zHdiA6vN<1&>*GzrYJSe)c0TUrYXS`cpIslHdlexO5!oCZ#cZ9A^S1$P&%w(Ev-;Y#
z&%9vf1fDI>6(3@!024m|wcF<<Nf7;a_%Z}^<~IqcD&SL5g}<q~1jCDbSKp7%RMpk<
zMlMdX{Y4t=5^V7yMX|UTW?mqd@Hrfj?j8|d(Z>$M_W!Px#mL~4V4@uxoNdwxZQ8O*
zqR<zTwEPK+4CR+#x0${C6Rw4N<<P!0NV|mwiw-G~1??xCEK(zXVU*DZOAlZ-5G|2W
zZ>_G@f~yw{GvF!(Y=*opWRKf=x-x6+B#}tWkot&spD!`Ik}p3qa~VuAtQ?31?n71t
zwCXT&<G4!PnJ|m`i-Mr~J!JUgcT{IyLLDB$qE0C}SgGGr%lJdhJCtv6TV%INyGg9q
zEgxZ^qFPA;H)uMziEuOM7!MJUHsE04jKjH*=<fm9#n@?g4_`y_FoWH_IB{c0QJ(@@
zIUE||(~-cZjDJmn!N^<m;tYfl7!P1j3!2L?cFeGhpO7JPnEh5-^VzFcSsXOgtWaox
z^~wdPP(caJ;F8ThJe6yn{E8$wf378Y-}p95G(E(?Kz#&rUIFlm*I+hp`NYJ+0tQ;^
z(8EK5ea6u5JvRbLh;W~t)`~ZQ-s&S~a9!VQPtHAbqT8V=AIu6x(L~0_Gn%DMlu1On
zSd7meed!z7`lRbA-#|hV(5t-k+JZUA<VDaMeI6X#EbV4LREc%-vUHpE`|9gkRCVPs
zTUYy|lhgRZWn7!A_XTuHEMKr9*3A@*+4W=Uv+_yfi!_<{nfGDpYcik5$#83voi9Si
zL_xKS)m8W3MX-OYf2}!Mfl!J}<uE0VyL711F!UaoENDm{Fz+*Ng)va$0PYOG2AIZh
z+#o`H=rRI<Pn_)9_BOIE)bLz^KCEz|vhuML8mBd}un|lRIoexH;Pm;lvInJlm`zkz
zXFWU;6p+D!i2<>~jx8~e)M0RGtnD&UtPZ|C91BotRlw8_@Q+MU2ntQE|EOb?1Ohvd
z!pYJ{gKq`K5efchrnumI^OZzNu!FTA7)bS(-Zukaf-LMI)E(f@aYGys?o3aj;4d~a
zj}JSCE$W~N{k9O8UEwCQ7$f*QRE@c`^a?-U9qc>6!DV)Ct^=lwNd72R6Blmto?9zS
zi?dk5L9Y9b02WN)J#f@8jW+?8RXL~lunMtmngSw4wYe+?EQKjoM@NZk(>HH;6-(a8
z!X*he&e&>sXlN*mV~{@?2GhQ8<k5$fOT!9}3eawg;cxegEnxFL#YGfiZzo1c@HT%)
z%BKqc<u&MSBKPA5OrSuC3uiRkxd1=kzmHZ#4RHfteng)RRy8U=pgaO4E^u*RN(AFA
z*p|>$!FK>?4@zA419)&9_TGi*7EBzsCRsrU2;T!O@bIuQ*vtdpV0`?AukSTn!O*=r
zQH4#<%zzzHCbc?P2FXOD`q6+LJzGKp-)%DxiNL{CuGhrr?a?VYF>b+w<<A0NRZxH+
zpkEG6FsfnDs?;wNOR4)%MIw#|ZyA(n41<(y1}>SOkU<F$XrihKQ*sby0D1)1wMCu4
zg9lyEGxYV9Oh}8pzg1cu{@H>ZLyCP$J>|+${OKimp?dEW)md*(*P~AZ4S_};y>>s2
z<A&~BE&WJbx$i9<dQ3fHLR5d-(9n=T^$aZ1V3=xIHw%*-7&D{3t*NQW%X{FFl*1sK
zGh$Y!6YGabwKWwHbfBDD2^9}h91sJz7x~DC9a_MP%1GN~G*^c8Sws>D%^oQvgG5Z3
z#d?KL1>}^uB}lCdjAYl3JiyNI%MaZL%*>XsQd#=KVSxgS!_r3=LCHyoQw5ec*RcKp
z)p{}^L{Fc~8ju3;KbVVwNlT?_k-UtIctQ8vTuRRhM4E#t7tT!ph5P&aK|TSt1X&VM
zxPUQ%W^fdlPXX!ya8`k><hF`wIZ=s%hLM>S3~OHsT5TetZ2p^IR^_>`iN5+2wxH#5
zD>NqH9SG-bL~yVwQyh|SV1sEKBo&+u&a}<~`Y_l+N^|d9z~1<eG}opKs-_}1&EXt|
z+6ff_G513G05(C@RKLf~5h1pu!<GOl?t(y;XHcpGyJvjE2~wfIQIb<o$m89>w*Zwc
z3~u1l6cJhEW|t{J=CDC04pQrmjZ9XQWt-0tZ0;xF1v$FSlYa)>)RW))+z)=m^Wyv$
z3-jTfK0{^=)VBq-m`jgj@V46)6-*fn7*(BWth&}d;(K1f<OFbHDPiH)-|$2-e1Weq
zKd(1FhX6;>VR+K8XOZp}fNdyvLu(3)2?W#7pgKD^JSCF^^PkiwRq&gExg>lDoJpZH
zx1yeNgSzSB!Yei#)1-_m4@sMO@L-)_YJ6M|3PzAZ!?+eqP0c(>;-f%R2@VKQNLGnI
z)&O7>Py)!S!y_l(T3&u^G0xym1CLc-Pmjv>L*+KD0^BQugEqsN;=uMuhIf{eV?1YR
zb|0t*FvA3+WLWxefFT8;(A9!x5*&;m-Ac}#aS6zHXUcs|pU?k?<&R5yeVP%rML;zA
ztqoG4QPXE><@w?q(#$<a?Bx$IaS?NFwTCl)^xt6~?g1PI5Fs;g;X$iwHC^dP^8p-R
zsQ4Y8m1*P@QNuYZUXoDD`~dssgr;Ge*QtZM`>8aw_v`ufm6d>J5@=GPB=#q}uj+Kd
zoZgzZm`RZ%YPVjAn)DKI+ft)X@x7)04r}cVJaiCyYr#|4C?6gk1|f07@G#tgDj&37
zzs@zEK7u4fL-(~fq{4V>ik+W-hMQs&04giF_zU=c5D0@k#1;}jR%}>xX!_>Z`NOXL
z<Yx$o$iYH~#BnC1%gFej4~Sl&O)M@d60gC%ThY3YwNGAWmH3QK8)nkrOGyG=wGOM#
zYc-kTkVudcTjg*y3eG&xccCT%v<F7hS@hW-M7+;P+7w`%4E!ZN;n#rln5B-uIC-Yp
z1a2*`my*tU^8tpCS+wbVi*9IP6g=+9AjTKDzHmeU^dJ?3mPr=YUAqCIxJ+zf*j{rm
zHgb1w8u`T=?1SW1<e7Uw9}y-UNQ6G^MQq4ByD<Mf^?EHVo?z}d-vN)NtVjeK<%UK3
z{W{qq)7iBV9cnd;?)zndsTD@lp>}a@+<EWLW<s`(`bSD<ITn&h!mOi1Ew;}RZ>o99
zDlL|<s*@3&_UT+rK%yBah)KN_Wo4h@gSOlYNJ!nBQU$g^zawL}GjASwf(kCOqcpSl
z2rz(1X~m?0?*c-l&iUu1rH(3831AWPByCX-*l}OUMCb0!K2rz6CO3Z_@aG}ZB`_#R
zr2A+>iuEbpyBADHySrk>{&1#j<8xR~2}3hvtj){FSOj|sCN6NmL!aO!A}S)%?t6U&
z+swM?#_dwy``mI9N!YTy{9kS%2#m#4Y=%U@f)NhWS+MZY2^a$VPWX0!&LoFAz?KV2
zAb`c>*b;z2<^y28ZQBuC3-HR`Fm7Q@OiIei^#$21%tnMg4sU@f6yiW*0u|=c9>4km
zJ*ABm@o5Hdv>a9%?t<k6Fh>HPj_7FtoVEZU9@38hRQpj;v>?zp{&NaoVnb>9vI>Es
zBi@ZFxPVroec}2UD^Q~5v(eMFg5L>F4-p{1Kyw86J52mRTnUzNMzIfJ{2}afaT3p}
z3xmi9c(*`22e5`Ywtzk8=0UYxW!wXB&F0pYx3@RI#IO22mWp3N1<nuH3*6UW{%!K=
z6$hx~0V>Xu@c%b5=e1%$c<Tln%%V=~c)c>~8ylo#WM?p@CVdbBf@sjF0{qAjy#MbX
zAgbZ!w+;ZTLPbM^F3j`yAZ66^)tw!rH^mCR3=XR0temp)Fj$xYS{N(421a?HOb?v5
z6{6aK`vVltAHu@wYHD=rEGEGI89Xs&_Y=VZ6n21I495rRcTZxAuy+jDqOhLWV$4bs
zGA5Ti9u~h?c%FcRY0|M&c4Zc6?2}erH}2<4Yh~1Mt=Hz;Aj|blyV}^OA-|&~$1SU4
zV6+DPW`4bS)IG#*J&}fG5y#CP8MoE^Dx3TB0uF=H1^&NSfNnH1Gt<=O7p(-)k3YEd
z8uL#xS-T>`Qi19BtLb;TL{idR$;;U_t<9;53=TQ;zG@2G0_gnL^$WvzoIZTAc)wNG
z$X1evF8KIbgu6M}Mx#x#)n(}2neM@?WyJ!h;z5po4W`UGKA~A3jvm?W0Y49nlg+$}
z!pV3xVafRHpIsX`nb=l7<T7urE*?nX1A3Jj4c;?w&o*c~0}vY4GAsj|Iwm*-_n(x4
zb0I_=QW~Ak%s0zOJB}uto=(?tyM3*^6OfHhRVejm$imJC%W%uucJl1J)yX(G-bh*4
zEYWs|K7!agdC+WHZ~6?T;~D+&OWK?7nP_zeh%Pmu^#<Y=+0e5MSy*UwI%VdwKNKZ%
zM!<mF82lKllMGC;6u|4Yi*=}Koq-`3TBfJQ)%s#^4a2((RjZ)7^XK!Im$N8+)c}fn
z{cZXUg|Uvefy;;Hr(vVq3tFl|-;29_4V$a^1nexHlb2*O6qlF(g(I4!kC!hnTU;Fw
z8&K23tqiAUHv#<s4r|@rIKNZcEU&_lTzT`8y*Eu2VU_RInX~x2BM%nqf39}nq_tE}
z{sP%5(b;2`kX*vz;hEN%-J*IYvlX!u4NRcrv__f`k9BR$!=O&%-a|fV=|JYXJlb`d
z9@PY7RL>YL*mYEq>GLzguZCX6Fh8BhR`X-#N5%p<oDgTnbGA`hdbMUMy0}PpS3SMd
zjd+zDsk+Fn7FIKcheh&7YDWABY=?L&lC>|E2YvpLa&8UlTNWtnmMB6xxW^fG0@vtH
zd7n0`>k&O5Q&b8p*r(ZHFr5|+@U^q8WC2~Iu#gZDtIlgZ(M*$Ji;v)Th7pj36x$al
zNn1LIVshU7cNjW(&)o@M$<5E3fBv-Z$F`Qjodf!peiNwI!6YonSzF`50&(+-7M2fB
z9^JsU7U@{%p7%Ij4w_MDPV_a!hF{X%>E$>v#@Ng-cN*|uLG+F;s`EePrrA)c(?DEZ
z*yqvBx)K*iq`PhFIqUh1-tfs?>h>pxdE#vtWJq#3^^We;Qq9nQRR{`Tfs_$~jtx&F
za;BbW^D9z4{yda7Bgxmdy7t~E{C5H|WRznZVNs1*(jd$ZXYX_Ls9}w|=`G@Ah{vGy
z#N7B^*-t(<`IrR_QBu&pwsvS|rCX#<)o%Y&@l{Y>lDp_oJ6QHZv=73rfZ<YWzQ{r{
ztfb%M@31x-uj0VW?nt|{!&(N{5lOtZ@DUDsL3)S&bQ}=N=fjB_iqw1m>5Hab()2ui
z%~8Iy{z@cZcrmv%cK7QCoxJ&;Jk7#uW%wKU3Kw3-Qy2UGI3XPty9a54X1on)BOgHL
zI&-sxxqs<atb0~_`xOU~w*|ZY#^-DXXe>6rvv(^JXx)fJe0t!H_;mjiDFZWQsx+#>
zCy5tFCy760^eTZ+_CDgN=o@@Ymz(i5uc!yyrkY5-YyLwCKR7?FAbde!bz+>8)>QgG
zDB)X7Q~xI={CVtcpFySDPrha>xn9@h9FcXM&16^}%~F5yUBzE@^jj$=<mr(5o5<&6
zWA|@4=3@b`<VC&BanEx%o;PFBVXHavWtv>&*HK>O1p&l}5@qJ!xamB(Q!i^nB%%?O
zEBjQmN{5#hwhn#!J|Cy)2z4<U&*NVt1nJM$yk5;l5k?)N53&uOzPj{3@>=Zth3^={
z6<qVo{~-}uWt>h8i(HLTvm*L`WF8S=S}bhr>^uIU`1*{M;Nl!3_p&abJmj;({|`BM
zL&DY2!~Tu9$w)6|1?CMQgp2C3TQKkNfc$M(c?;XZ1vp*?49h1?p1N|StD6Fd#yDTk
ztIC8@Ru&T?4O(H0hrbKL4yiE|%HE(MAP5Nli^u;+(2q8M!L(KE7uXV*q+zrL>|yL$
z8=c+Q+eHajOu?<G$>EZPQxn;DO!k8>M{bH{oMOtL-Uj)PeXTt{7WF25a^4GpiMG-C
zYx!$2`sIH|yZ;=I+SJ^pmKNUAe{+}kg?$7@A<p;Fq*9xl%N6x)Eg8`eVTzuI-QP!0
zviSaX@z{9uom$iRnO*J9@Hs}8=l4u&Pn*mSt=hZQyqAX`CjNfs<7|R~$B@h>-tylJ
zgXkuYUh<PQ5~NUw5?ve*)lZBm4(tSn01;9%A=>*eXo-pdduq^*Jfo|suJ+j18UpUz
z|74s_&qx&96U!x>Cv*s0WNUk&Lx_k4BY-lBvH@1cZUll%mWS0X*l#4KE}op`XNVzX
z!&A8;^LQo(_HwnUbN+KuGua~b?<}P%IFQbyd-^>rf`_wwh#@!&JG8yAn0v)%^3abR
z??%=z!=JK0wXtMCnHtr5U9Mc0j&^C+U-jMZ-oU_DZaEGXwUTIQdg;Hd)pNb_XJ0-Q
z87MALo7=>{VNA}aD5YRpHTmS9(qGr2?+Wsu%{tA$dd{%|({kIS@fdH__^#Ktsg}3r
zxsDC)-OF#Jzr&B-MBkCwYW8OLkgvOgD#^p%ay7i-w>R5eS;emzMH=Hi*Q1&iX}^4b
z^J)hRiiIKt!5GHC0*j`Hng|_L9DD_>tV%bM<tT3}j6n$n0PNq~GZctv0+V!b1D=_i
zgQ2vk$A?OeET8+6RF@7qyY#e%Br$}dOf-i+1KzbDh0hXuS36R0vmLaEoY)5!pJZ0f
z!);O@ga^J45!k{xOH24SNF^jkN3?|_06hq4yos(}wYWr)W!%0JZfSuT)29LUMrmKP
z95f=Tfx8$%CI~IFvXB~CM-ZcR2)Yw?ZNkZ^e%sw2ui~YWZbZ%ZyTC=%75#Vbc2r(V
z*<4fXw;752siG}>$9wuF<w!PSFvp)3mnQ=E<6k8Wz3~YhR~I)?QMKviJD6NzZJM*F
zNXG2<5b&7XvIug!b8$I)B`8TsYk(HLA6;-$=^iG!QIuVzrk#h(o06mdD)QJOQ>2;V
zz@(gPigg`(_)8k#Sla_Zvj*R!h1}KknJQn$YoymN;5(|d>U+G2d(*-B=KDzFd(@Dg
zHMPUe582nOi(-h=jURPF{!>qJ4T4O*u<h8#3WRS{7U%GU#VMDZdYb&=?dYf~sm(u3
z_{J)|q9jkbt7qIbYw@7LAzFA_$o%++#df?=U!|t+*a%s27EyR2F||ugX6v`5g@0w3
z%&t<~+O8*-(nZF6b2iuqzeD?B+RjGaL=WewYr*yTQET1P_LtXn_YZ;w*7jykxQvcM
z!)a~><;`0!Y^q}k=V@A~mvfpX=e?Db-J6jt7y}T36dOax9~tGPgzirRY3CrmF#bjy
zO^@ln{)dDy*G=Gv!;eYYut0+8kE)*}N6<){#1MUYnacRPLyB)ack$rXF{xW)O6!$>
z8Dx~ABdqja8V$9gCmL&a&;MZ2d>NQTM^JsE){;p!c!_d1g>Y%C=%%%zZnE5&>y~E;
zjfusuWBi+VlbN-`x3UGQX0fUtYfZSS`}RSy$>Y&iOfXTv)tPadqKEbghLjRMeQ;^Q
zf2lO|pI>SH%0bI;=Xbh^DqAeayv2O(en|V4<j=k8^V#-`;HS{xm&n!|&Y~pv!I(E|
zX}bMafcZ}IOnvlBpi$vDPhNm$;H^efkpx2~cE=je$(YY(+{pl_QAIo=z^XzD=@Sc3
zb!f7(v%f$-6NgQgJ|5+fYi`NCuw$2hbDl?^@@h+{6?~UoJU#s{v!J!nc5s)J=;=Xf
zbt|WPQ(mLCy(90&QycB80xpqkEy~$1sO0na88-hq6O&8FDW=7GTB=@uWYxk?aX!%a
z`!GOw_<wQ%wr4uutRFTvrluH#3;VrY{CoA@hN8veQFDdqr><CLjW?=Fx~_=&%<AV~
ziDz|Zi;gxgs_6_H45WrM%4Gi<9TbG$-M<mVsQDGO21WSHP`0Ia&7nom4OJ{IJD6UE
z>U&6^EJHDi&J!y(ly_1E3q(zx8`FV{gTls~KV|%#YV4~x8fLD4*${z%<?H;{?F3hA
z{dO66#C6W@CV@USi#VwkSY@1y?0E@}Lvlqb9<obw3lZq`9nwq8<|@akq!FDVeTtF1
zOEF3bXJ;N!&mlfjU^fp1dA4t(VzRUuuqX6|l{6WrN0t+5am$4r-%(&}-8R}56DHF@
zLj-fQiXNp&R7vxtUTK$%HO(~*kn@^GYChgq<PozS&S)l8MC_d%tDDJX*q~H|8*;kt
zmbQ)D^m%f`712lem&+^n`Y~FL<zRF}x-O~D)_gZt%Bh}#T?ER|5oHgm^@FH(;k`2N
zk@JY|42OiK@}zy-&nQI8ue}-z+InJ9?oo}$UV7PVvG@5bJ5af#X;kpsyJ~vT@{GaV
zbYJ(kt#o?(>HGg1WLVy9`~N_Oiwm4R&a!4aq;4Xxym7?w?pXBth_n!zOmJS(8MQyz
z5&wK;Dg6v}q<61Ec7Vk^K3UZ3@3EX9Uy!X!<ZR1K<AmiV^}##mhujJWZbBj%*LM{A
zk+JMUBH$^In=GJTb4NkmbK|T0-y4zfsLXNVuU;O~m6Il{G9Ef0@EjjdM2Co^?Db>P
z#0GgFXfRd3@~lJ(p}u`(j#f4`nhaInj^fo&?d;2nPY<$gv!GArGe$7Rt8Q*R_b0G_
zpcj1`fgx4Fdtri_`Ql{`FT+s;J@NbHTa9#V-_eK|x-;`87&JZ(-NoXk^QR$=pH#Kr
z4jW0e1-*N+>i%;-QYEA0f8tD)Dr&Mh^r#3C=}*6J@!v==A!RL-YPms?70HZ2qZL0g
zLPl988Hi4CH=^@5GWzr|bg-6cMa8+93}!_Fe}3)|869W`WGD^F36glP{(f-1W`FWu
z9FI}P?yC^wp>ndcZCntA88jHpXXCow6@K;5H94OUD^QGPU8@9nJsyyNlgxw#2qiP>
zX|M4FMgqD}jS1+;WKHJF^RLE*nF79?B)uXX6TNE?Zor^Wco)rBnRGKn-ny&ujwvy(
zOn`)0yiMjOJP(}`-&~(ihC}BFovH8FOuOW|Mw|Ye**SI1QWK~UiNw8;XX!;?k^Cyj
zqmHhF&i8m(yW5B<z(4bfF5M!IM~1Kg4(9`AELE)0e4NyME8I`QDH=%6mJU1$*@-Hl
ztq@^y67LwDO+&dd)%L4z4QL+Nx9kqk&0IV((>e7Tz4ID3+qG!OHUy1ouRlEG3jVL2
zcmw;2Fhuw|W*JWpb1C}2(@3dLcQKpjxP#2F5>`JpzM=n&@{&9v-i1I(<Qb&SoLuB<
z(jlE0<cV`8Eb>N8om9t{!c7+f0?iQvs?HDD+I~rqFm}Jqo<}}EFrE;0JN|E+D~bHg
zfd7%~iu@ypmX+=anIrvG(kXXwn$S))-73w3%2j#~`fk4vP~XbS;4RZ>vG{$H5xq#?
z>OVQMj}z<1K2oui8MIjR+@x;ZtuJVkezqTYZ|_Hlgdy3uWoDIFnd;SEyYr>+ISX|Q
z2?FZUy+$tA5H4<yu$Z`&Rg`-ddS1yTt?~vw48Pob-2FoOO_VE^Y1=SR-%3>o<2wrF
z(S-G^;p~xe^V<o@L}K@~R$1f7(lvW*>Oyg*f+JhD4^AGgSX?Xv{paq-X~VAE8GSe3
z3QBJD{8UtDw$L+Sb9_JOP-Sm1h=Ha+86ucu$NsTz4R`mCsP*z|s(;rrEeDPH<+b+9
zLkc$En($T)P-O7l(Ws&}W)gN$rZv~O=m>__%{ir-7nD)9JV`rMNH7=N7CcaFXc(KE
zEt+td)oIbvEkREpvX&ePeitrR$@cLrJx%288AXQ%$o8YFZbs<;^15EW=P)GvkDm6&
zcgI2Ra$E#%dhtoCm2S+GwM=t1jj62E&kvJT+n0x;;SwtH<8hsiziTPW(X^uy+S;GC
zRlhnPssDFfekt*X#v%TuINlBM3%es@j1W{D#4s5pVx9XgLfL3;s$G1e%J#LS2Kl$(
zi_!QgFO;RR4zHirHr_s7vnT3-mV?}rE>owLx>J==^EC|@E5D72TWc&Y_hw@dl~qn^
z`Uf+Qh=l9C7OO{lFAb?@(4g?H@j0ENp8v-tsj}&upuXeXmi4_;wC-fj({xEqr|CMx
z)|Dxf+l}nH&U-smrN*#zJMf1@P{sV2$MZk+UgH{D;SvSbcMPu!2sM{{8)xhDN^c=7
z$SkM4_KsUe9IxEZ9c8S3_LkYcdxwXxnr~=o&N>?j^fj<Q^7dr@=exIEzI&84H>RBY
zZ^!d@z&Y5zALm%xYI)%Yi!F%k+(14EuO$o{91RCOhq5{K1?3cqgj<Mex`Y?;WHUFM
zw?;N)duEDF9Cs$SoDsbfE5ANO(|p$_9{oxyBt*O2j43MZVeKOO>m^#xc?wGA{M9zA
znk|_S!$TW9J`QjH2_G}5!58br(~uqz^hPJ>O*aWP%d-fIc<=hAy97@hnxjJ~gzlRb
z)1X)M=~k|Y8VYQdaN>`(P)G${4s-Vrj4jh59^dzzEx&JQD7vSElh@?FAEs7)fX>M6
zy;?iedpqTlb&tcIqd&9jv?J7*AMuUM!u~wD#WUN3wbTO$pRDO#mnVnzzV6q)58te+
zrxu$XHrKq@wn;yeYg4>~s8bm9-O<^xDDRW0UN_UXI$X9aPo4XLKO%YqYy|#E!Snel
zrc&|z`Qb-DPp12|&F1lpo=kGYO4`p+oWI%M7-8Vrz@k1z5u;ps9Lt3h9)8yZ1%aBq
z)7*;gPqA5j_2k}N_o+XERqF`^BPyB;e{8=~C9^)yCO-d(furF`@})aru1q-8^msif
zn+40EusLhe<=6BV%qielV7lQq(rO)|ArvgLlguJ2=J3<1v&|U81irjWq-~A3`Sz9l
z_s;j&cRq+vd}+b;H8BdqwDK=~-jV7Qzz{-<`TpJT2v;1RlD^mXyAeUzW(qeDW{lR(
z5(6tCR52!}dpJsjRP!#EUo8ohHFi#1o6S!;MXy)vr}h%+%abz%e~;pFBgXl-v^8Y#
zZtS(im?YiM@-`F8==J}zp=9ND*4$d6a%0xf>bgG)-86ZyFoj;`sfScp7?tj|Q_K`=
z-~P}eJz>-S(m}rusAW?W*qB*-Axqjq=25hqob)#)6w0g#^7{B2E8niWdY(#8i9V41
z`R&z=`-U+(|1B)BIfH6CG=|~J>njyTe$RI10eM+zkHfVe`kOY{EFY?O7pJJV>$l?w
zPuV-%v^3}ux29AL4fj<xBV((6jr{0SGz=eM%#nQX+`Lfc{=>flXGcf(Dul<@OPvLG
z(maVJnYBAv%q990d}FUV9|N#f%@RWrLUZe<Cm6y@<<KTfu1lbiz3l3;Gv6yRdBn^a
zBSldneASY{x=>lc^J#SCZZ>^!!?pYQ0f8CS`7S19-WKh^edhh-pA8D78^tQ<;*7)m
z_?tYE1jLl*f7@&)cqiJcy(fY$GxP*~41W6_2s>3j-ueB608+&@qj1B>c=z8OJaZeP
ztckyR(_P_8dAXT1WN>mmp!95$^yq4v&@kPO|LUx-=ZwA?6`>tZpbQc~qKx@fXXZ?|
z3o0Fno|>v^y1-oO&t1S6UkEg;_(*fhfBnv?u1yB{FhVXiQ2YLE-UMP^_vDA+iDF~F
z<Cp2X9yZTAw`a1;QcvJJp@~&oJ5426?HXScY{eH%1&^4Uqj5H#oW0tUK`gJPrTT5X
z`ZsEPE=`{=H=-(EOUvi%6u2U4x7M0iNHX<Npw5qd{oqDxY1a9{5yL4Tdc&p7q%DE+
z;_2DK^!gJ-p?Rsb8NXn+P%<jh66fBMVMWbU#-JjY57~w%c%NoeTve~%WmWj@O{wyN
zZ~Pe$5*W~eiA<{6^F-JL>LVgXY`>AGz;AT&k#t=^D@V=I&Gvx!y~{v<(xMO6P;_h*
zen$0ih%32J7%i<+?(DChTSjy(I5r}pjhDG&?LU*x>GPbU;!$M{&f;3a|CC!hP`RcH
zxm9~z?Ai;5<{nP_{d2W7+vQFd@$|U<SUrC7BJ<@7S==4VMQ1nHnvSORWn8vkg%Bka
z1RR9TzdR7T?=Rk$SZ#g_psVLgx4<6X5vlhas=8F;dW0fI^WnPgvaC8r!**Er^+ItL
zcc)PdVp(f@@6NH+#Y!DBhNM(cOc3z{p|`m0{3_j^r#lu(f6C{%CR1-CzS~O};{=GF
z=dWAIb^21gSDHv`o;JRVJfrQCFg*BE3UAdoU@<BB3OZG)ym;sMukQ<Wh4*s6D9(`Y
zF()pDS`c=N`)1fFsk^?x_b2r4L<D#F(Z?5TSu}S@(**X*`Q<=FcBuIM>^E;)Y0idu
zyg8RcKGwp}SJsRMD>?U(kQBqPOlS9vmEU1WWpBTdPM`l~H`Lr;>^T>e`zUwS>3@@f
zl>w3QcPTplrNLvL@|y2QvLhV^r`wLT@ixbGrL)cXS$VV%ncn<OoN;ulz>@X*^SW>6
z_hQY#diha{Xs>Lq*ZS<u83qm2uS)-H_l%ZusD-kq(msj}EnPL-9-6m0`{j5LId0iA
zv}NZzpZS@c@UmoNEH);!?TIffLYZJ*^!i^($dpLikC{~ZkdIvY%e1%rkt>~fJdoYD
z$VS9P<s&f`H;2dIBexs;Ux!s{rG8^V0=f)&EtyUmWnM`B+kGrnL}nH@Hf7$#Is-x*
zJf7a=y=@!Z>o2&rTCz6iZp=e(=w83c9E^{v{7mvND48cVC<~`H2m>LG8#onLqUBv`
zxEn+)YR*`e{>Cf}mjKTMMb4*=#QYr*EvtkInRZm=x~39-X!wVy*WcMaoXNan2QxKP
zhgF?kJmW?uLw_xfh5mK&%a#Xg&X|-LV;Ox2Ek8-LKLU^Pvqh1kS~eB~q59g8jYrYt
zK}G_{-zoG4C;r)81Y$YM7ZQ~ZALOXkq+cxinntu+92aVn$ucu$8}1g~5ij`oa-AV~
z^m+B}IiF@frQ^h5stobLsD7bXC1V_U*LwC@jwA9>o$PJ)V8^36H0G*3IYA(JWR*{E
zD4o=oe%tm{H%a82WcO{k6!vF1c^A(XBKci*YbH>Cvoa+2IVIg=_2*w`F<l$S?pfFf
zdPLsAnDfA!STmx$ktg>1YYLfieZs3=x1E32Hog&O!_5?B0tj(@C{u({hHj}@2D(Z{
z3I4lCI}j9)#*nUAd&HdFs-THIurBl*`L1ZrhVHce45WGQ!P<Iy-x>4HfXDt^#6Mq`
zm0ZJTS>LFL9Ng_+N^CsBN$+l4pKhsWzR%BF)#qUJpX%i>#wV4I{w&p?k0u#YMx5vV
zljlQ$xtTgdM;C9ND{*bkn>_#8SmJEu?Js{9AO6O(1fO+Mmh3j%m<WAEWmGZcFP{}_
zQvdU#uoL~*#>Ai^f-5gZ8kOZg@9l$#)c^X^vEkj9GS%a&YunDahQm{yThu{fc!CS%
z#X*~F4eia_VRw#gD3)peyJh{(?4ty6f1FQVZ75AGWyHT+v{=~te#P2AJRj@Z_0A5h
zA;H&eA;x%2YRP_L8?k)*jQ8)HSMDs)Ep&YTF`kv*ZysqkZ_Rg2c~_d|v<*fPB*gkk
zF0L{^M2OM66P>N8`eOfFdh4O?eg!F?w1oL<$#&Nx>T#@8=5qb?sA(PX-jFuxzn81K
z=DPAPoNQ(jn~dK`4&O!CHEyo=ob&Q{BuB4A$IENS5~NHokX*I?m09#G$A~Na#$4XU
zci;Z&mf)g*+bCK4^@O0|utlv6dxy=x_dRKkFgOC<L?rP{L|51dyA>PB&1f_vG|=m-
zL~=d2Z+`>frJ-@?KBEzw%_+Zehed0$Y56?*qN`Tp_J5x61<jH1TS-5VJBHyRoRV)L
z7^=1{sb9uXol9xFuJbGX#%}E%7GjifwRVpzc+vT=1WN8Jug(C8mXEdubIskUk;i{n
zT?IEOAzt!l<a*=XkDYw+HpP}A=U=mXgr*OAC)EQYUqQ)<lcypVw|FvIrn5P};=Qwl
z!-_Jb7DC-adodq>ox?cLYF|SxtZ+Tse*BA3Za?U^w@$tJ+T>J*-bE#un{&OxMo4l!
z!LnxkLWXXL6bToCAY!TI^=S5Y%~~R*DGPAZs6VmJHBN6^^99(Wt=gH8oRo|6K}mj<
z%K))0d)i*f-o^@Vg0*(jQJAT%H`7yM`<1Vf4GQgRo!;c(lP_G{*WFwyvl*i4491zC
zB3InkPb7_;IN$BR*V$+~OISPT(ILJC>#1s6yuLSHCSAfzX<8CL(5724g~Fg2k#b+w
zpT1AuB~Zf6?dh!ZJ)iKy**~%UpE1J!@u7(|UC!y|FLJvn%g@u;7@gfHxf~8nEgCLj
zYVPIa9^>TZ>VEl>)?>BuPt8DB=BKE!IK9<nQhqgbMmPOMf6D9AQ5D0usKmv!$6wU(
z^}H@UAMA);g-G*|DI;Ll=1)I+r_;$PbJtsZ$+hkgwf4y)DQb@H)R?qX=aa*zRDzJ8
z(RrcMZbt1>TE-{FtA_(?k^@)qCy7rw){jCAc(x|<)aNv~JbuNShulehaxyU@EP;Vj
zl~y!v?i})ny<f2&miLFH#k#*{+pZr=?O)3djwJUI-u~ORD@Tpozc=jpk?qPm4ZZ<R
z6D5-(R4fFA1BEzuui~I;!{i>01pnCbI*H8P2a;GH+PC(Ju$7)~RWm=N+b^GStyUR{
zrb{aoocR9~;zTC2^f%vE?rs0x5l9jC$T#1`Qz25E5VSH450j--P>FrCEVCT+a)g}`
zUqNj|zP4woYt2dE#BQi(Dl~<flCbD49dq?uk8Pce?|Pc_RsEj!T#_+jSfgJ(ihzUR
z)qPW|<A%4Woj;>}d7BX-KEA^Z2fLaNCliN>?2khy*T-{d%0AkSt1I-SRy%CS9XS4O
ztM@J=_C#5ZxlAD!{%dM`Hn;O;!G76|Um?oh6!{1^>@b|7JjIU>y?gH5kPt^q|F;nT
zA+R4!Pb+-C7Zo8?f3;y!qIqGlMw!xgd%~;~4gGb-Fdd`O^IL7&7lS`#La?KvVn>^c
z>cX;}nryYi4yPK%*>&4~Zs1%$|3Dg@AfmBAJ$oEYNGj&HSS`|Hq4a_;o$*^zzT)(0
zCH2PPJ+6HXJ?{>V?na9_3-)7NBaFPScbJQ(2hWq0GRl|)weyt;5Fe`X@VvL$uXg?T
zu3Oh$j!=r~&UT{PHQ&pNAbTZiiOH)ln40;m_XiU>f<nk7EuAM!{On15-_W;~X%S51
z;oC^@|E|Nygu;3(B7U3dkuK)u+<#W&EIA@->wC4}xkP3oKc*sp)f@(`yMfw8{YM^s
zo?<bL+`%a2JLmP`j|7h4n>>C@ntF*}LmAGH>6HF#t1f2$-efJUc{E*NNB6Vt(x$DW
z4Q(}i<9jwKK90(__&1AROX`TYYCp$Izu4WOj`fNr%aE-Lx%``Yl+y6mpv|e<ddTb8
zU(^jVp-$zg10LeFr2I$f$)5-BzD5$CN3R6Q1~c?Ny`vWPpOf$KJqk|cGwnp4;>@oa
z%~SQhKR;mB{+)NXld1a1=9;D>mGxlV2AB8PBkJo>3*QMxyXj!s=7h16&g@%kwswPs
z&Hr77Z|Q8N1cY&n1XUFoGg-Eyp&Mlz>HYm*Rk+`_J4ugzLA3Gvpc)gnGMzmak1(mk
zaWOe3mC2k<gvlu{caQFrwQU_05Q&x>1d%d8fnGP;0pG-O{!sfNR`$yZ(S?H_9yGl_
zlk#U7UJs9*-4e)-chz^${LinV7w%Ucz$5VB{XZUGd$Xzj)QxQk202wJS+Cw%_C@Pm
z?x1(WQ5Gp76(Jx0@HU=aEFZ_Pod;X~y%(415%GUjhA(|Y`{l-^{Fn*;4Za<L)|Qzi
zJtw=H#9jGa1&FsRR_gkW!iW=zt4{U$<Cq8=>I?!w?hEG8jRtjs9f21=G2L$WHH>i!
z&nIFaaMFXg26)QjXBA9RiU&0mD59iM2ygwIYUps@eG$mF&RT0Tp`84xN@fA4@gPf`
z>JO`+`O(XrUuc1}9NbI~bWu!7-TMb6TK*grSdv-(qrA?4|Jx5)vwRTY8@9}lluV3M
zQ?@^w%L)iHnyV#)HNV?qNqv&()OnE678>w5mbTL--NV>N%HZ6R{C(iNVbhx;1#g?r
z!`3#1bJV04c}zE=WkMDiwXf&%6P&q)2RN<a`Vz-=;fr27h__~B_pm=Gxm(M|?tRh9
zQ9~H{1kLmMVr@%y@!aj&l+pgXuhuRCbfe2-m%5|){kOY^oOzoJ7|*7dJG{du>qVTO
zyvvECoi9TnrE2}vZoOo)q^Ch5%HY#A@sGC6K!aY|d*UoQ!b`m4qk`M+=Gq(MVw#&Z
zF{~XKo<oB<EsN)8ou#?`@5{X-!;D&(+n22z+VoETpVqztD6Tc=^5O&u5Zr<X2=4A~
z!QI{6eF6js9v~3h-Q6X)YjAgW_nnuwTD7&c|G!I3Q8QIz_q%<&PoMA1>0~X{l9!hs
zXg}QM4#2U>=w-H$+A?1V&bjtU_1lpQYd(&{CF1Oc8po9hg2ON!qW?w>eeqmUW98wl
zF?Jo00x1`fu1q<M!yPue&r9+VAhirs6DeuPahb$W(941WSi!hErxuS8hL|Rn_**4L
z<s4V~!*#|<%jhspL+$!3&WnK<SA&VPil}{|ridlZqM)?}fVv%{&v^zds77>z-I`S&
zBO_yZ!zyC!k_n<h)VM6M{z+O3Z;2Z=H4qjg)<GNs5Ob4?$5M3c&sbh7a*I4Qqm=T`
zGI)thHA&J7mqbsH(uvW8MNo7!OI3)4MnPv{h`pEoni(|H_dlce`F0{viG#&-R=~o4
zpH07&hl<&2GB-n8p3tjfJ0~%*J#$)|Did0)G&mPe8o!9ef?7*07i?$)BmA4k{H=I=
zm=!ueu4tJ`9DAl=<)8Z26Rj&?R*4bQ{Z&$s*F6%i!-M|x;$8Z=t>%xVx8fm2(?V0>
zZfMQ(cXYZ5^|6=>lrAa72mb@3XVvdhj{H}Qo}P$##2XvqqL-SBAk8^nqz%AJf2FT+
z0YGB<PlSI&hQpRO@8*wA!YSzx>@VMal;&mdaPm%hKbu(4Q!sx-h#4g^C#NA8X7CT7
z?EyVxB}#nQR!FS+<4*_1u7^4P5%NR=P8wK(4Fzz)qK5qqJSF&JqK8Sin$zYxvg*o?
ze@{FT=r2GIOvpw?W6GwzhpB+9{s*jEzGru}5Vv*#H)C0~fb`zNRJ(9K*aMXqK3hiM
z8VPIiYi{W1iIUgKC}UVPs$Q$uUzh~o?=vI+eP2`oPx4OEe>*_q|J}VeOo#+>89BXG
zy*-5r*L(Ey!+H+>`Id{Pk6?WT_$_pg`fK1F;nx~&<^7vqUu&VSz+|iZt$kD5dj2!b
zry%^sw&(7nbb=K2$EXrJI6!}*!EtSuY^Gk2DrO+599MvYXK+e)kG}mhkPrXFH7d6;
z_nGGMlRgue0wj5!OpgSwAGa3ALahI2BNv`Dm?3H_dCOF@)OS3&jOf|0LeV>ZaX6z4
zkzX>(&UT*e8zE$&35Wtf-Kr7-s|`iq)|Vi$)?_F<cfRMe?|jcy{&LmX{BSU=b#u|1
z<%2|P`&L;XW!c8lO!yM`n>Mcyfq4y_9;9SGvso3H_U4=QqA)sB?G?S%SQjy&vG|A{
zv<<k+lY{Qsgmjz14zFb!I@i@5$AoQ${JOmrk-w{pA|U{)fnfoFX7>TXg6{z6!&3V#
zgxdeYi8oT+9_aIDW$o)qbZDtI?v8Wta@MBY@79%BkG!)SUv+B8S-p7PV|f2P3jYVE
zkMTi%^KOkit=C8(AJ_?<4IbBQTXsePuMX=ul3}GdZ;WsCu6=dl!#Qu=y(2-_xb1^L
z^3(`EN6X~&b;XIbeR?&yy~k>SX^NVi@5^8>O37DsbDG5VLQ5G4Khvd`raFrtCMdy+
z`!<<Rbjd!w<gRgQIS`<_UVAdat7E!1?<v>ApJgTU1HXPyYqEhyiM4xpA4KR!$`ds-
z*$jhub6)QwWwd7ao3GD1!4j=PXG69XVq_vhV}EW#qRhcez|@K=;$JXw?}w~ISi0S~
zt<_M{oW;&Xj|Q&z^hLC6)$a~xb7p=<)u;~du9nRm0r4gMqi7UDu`T5)QU4KyJ~Lwj
zbpFR6x>kVQO>lUHf5rAozyC#{I23|lT*DwnN~nUh#wY4*hW)4V+ifz$x1N2nzF*GO
zaW(HV_+#UYCKZxXDAzbCXavY%%p+3Un_3GO);<uS7x2f-<FJ2(l_%iO>H>53xAC`g
z&6;(#Y&qt3N%i-g-vjjtS6ECYP?wUV)6^O~F1wCR5CQ0b`xD)xs9C?n0X&KPZGy5Q
zovL*`r#gavFdPmJR0AxHa7l_;QguPK3Iq)Bo-2wN&y>=<Nc-qMI4jlC!6hO$G?o-b
zbj{ThF_<#fbs-a7G4H==0Wkli&=(3Vq<(yvO|!afFhLo`BA*QRbqs_JuSSgx6q&!j
zy>d?*{m3`X>JdtXSa3*K&(bfR7nM&ngnmx$AW{jY-@oS<S$taDI%<P`4Dse~H(P$*
zFO-DA(EPE&?^ojbByz@k*$_FtI7R>ks<(Ow%MBHJhtFkP(*c8lgO&JPGYO+{{S?@q
z7Sh37)d$U<)eZICd@H$alrT!t+QmvKW>%E*usGlJi)Pbx-b2%s-ctK)cpGp&_&OT-
z@vesB<;1<_l+&R#HD6Lp^Y5x~LNyPx5qm$jZ@~p*5d+6u_5Qm90q5Vm{u1f&Fo1{6
z%k;2X#r@0>516|xp45Ot7~szmQ|gI9^{Tl~>y5+0B_*TIb5*v+7dvoT12gFr_C@;j
zUcJ-!uRl;($QgV~n+0l5C}@~LkZq>EQ8Vd<cD%|lEOKd;SB3&p2b5;pWsQ%1#u1J)
z^)q_Mggr>o--*;zs?zS*GWfMs-Ku4?r~p(`65_{M-<J(2`&ZB5-`PBV^(tz);l9L*
zkA-OYwFw5(+avG7N(suVAv%96&mL$_<K#vgH$6wRrV~N_O|rh$f>5Q6IP`S<b;l-R
zfdv;}F7!EqraQ&OC5Wo7oa%A!WW2-sOuIYMl3Q9rsNo{Abig`njlC+rL>zM<><^eo
zH(Z;&5bbXVKZ#-aF@j-#t?~^WCVni=qRmaouPd3ITuur4X71O(FE;l!em-kyBbzSU
zY5VsGBoewmOC^W*=n>y_#Sy)}1jfoMZ7CPIkxZx6_+8Delq8Ndo`9M5b2upMH^KNA
z0%$-JO?fk<?w*%~X}h<5yD=-4G^{$4{+#lkDr3}%WC5ZW>MB))p{So~tA9b4kj-@6
z8w->PlXGc0`ooMsC*<y2Sv6OpP_fqbJNkmp`Ba6WuV8u#*2LlB=1`6DY#T`jr6uv>
zlK!018i7s3clHQ5LS@Y>LMl{r%q^$6B4i(-49ay=WSjAB&QtE61U#&%CRXRH<x5xP
z^5^hQk}*}mQ-w4~3;X*a75)|{x)uNIBf`oX>$uP=C`@Zu*ZCiz^J?76Rm)<C{?_wv
z?uK%_DA()H{9t+^t89zGyl?3XO{h5BLT|$GPY@D6E(^~6#!HLseoF4(thF{9yS^of
zr=TXI;5R+NK4bU56A|8*tQ+l}>lJmw*YNRkc#=x=?Pa_BF0Ife0YSm=GNdcvHpk8t
z%_IMjSCilGzVV~DlGkzPQws-pM^iq7ukEY{!nqZf3g;*IGg90MSHW9g^xTbs;YQP&
z%0Q=MeQ|lyN8p*{ZR4}{6BkcIw0syL-Ye$8_0s1scf!vX(5>HgmMoJ$+Q~wJVCB1$
zcJb6@PV%eeRLx61MGfSD5TGxPme#mEio5Wyv9ubjs75R2bE8nURUUqJ_bXw{JWPB>
zxlKr`^{RBg`q~wPgZDGG48%OkYqpoAd;2&It_M$1{>~c=sDEQM(LQsIKRk?)rXX|k
zx<LdEzqj6!4SWr3M9=Y`3mpXS33%he1yYLyukhaVJxB1e@yrNG!uz_dJ0ldftZ9_5
zvT(a@>pCaUC)Mt!#omnDdTB~bPt#6=3m)dSfjgNdzx_hOWi~cP2cFQ;<y8MTK8rTQ
zcb3Y#asBr4?KUvuneZX;IRpkpK}!MPU+JKr``v2rtYaQ`^fTMP?Q&_)!uCixM1&Io
zw`&D2X5+W@>C)}V?WpOui@;5F9bclUBU3S_Kk8)+4+GfODf2;a6?)*&y9iE<JPVgk
zO?Tk=Ku2vA0we!}hZnv1%KNrJQ>#|OkE-~dD@BI^yFFiR#_COwl#KMGeEP`U-r#zq
zn#;XPktvpRmDzR>U%&lfGeJGlrmJ$^knU^3u;<KQ1lCBUQo-VAI5XOx8-9of=HS1i
z(HielY2{o6c>tlg$Xdu{t5H*8%7UKXuz(2#yx^!QD;Eq<DOg+6rPQgn=dnBOUw_8V
zV7xpPply5|h`F;IORb33mSu*VXJ`RcmIWagBjUHwiVkT0rQjEZ>FM%jrjg1fzd~ly
z8VpvHtA<UG=9*H0Vb%w%mjD7t(0(Y6RKjz%dcmZ`0n*74f90b_$3C*u9%&PN8NYCN
zEk+p?bHelCr#37S?hha(3@$2|fDd3>%DRXz_*r?iv9!V4nTr~}#9GoaiYoVCYXz>8
z8CD4~aN8`V#>)!cx9ML_4$J6ISdw8V1dytUC?V%X{=u!qpre@r`%gk<t*6!a&+M7v
zLH^EHvBSs-KU}i=2S#l6mlLsQAPj5>k`t%5h)3%4V&C2W&m8<8<}Aa18F(4(!LVcW
zX1N)cc`>Ej_h`R9lW!<!U!(87V{0Jf8-N=h4s-n|C5ccU-Jl}$4vxna5%_24QD$xj
zN)d&Q#wmQwxT1j}y_TwVkkW(dqIG@n#Fkq_Km9|7QH8q-=X+faLkQ}Czpxr=H$?BF
zRE&sjpVC|1vfgV^^eYp;@AH76Ca{wJ5$D4<!nM;<J5KZ>b2AgUjGrvJa=m{^ZYJQ-
zF)U^uMJtS5v?sKB9lI4_z>6->BA;viPZn<3B$G>g@DwCfnz_sqLJ}!CI8;LEUnW>I
zMB!pd*&AdIT)Dd8fo$5slI6cqgyR9FoBy}FhTo)&hSvBO=le$d_j|`3q@A%QMT5gj
zM+Ap?9)6H|E4O`c-W+~wIsfD{_-yN!#sR{Rb6@MX>w=>*c^O9gy3>1;w}d4`yP*yv
z;l{5^!vd|RgH@I}XN`w$z&VUB{+%tqk}YBo<oDEr<O}DTINBB0)6FCP`I<?+J;^Yc
zp$<~}OH6ct7`2P&WI<ztGdIUIj_v_W{pDn_R+Fx^Jfc{kO=8Z`k4qAi->&zrqTKm8
z-Ph86`pnH?JF?7FL%I(SaO${TZ~3O+@yQK3O3CEYN{7iE+adYu-I1U1HN@zsZDY=@
zru^XCydktF<h4XztC-aT?~A*(2=JcrGKJ!@dXJPACHS}=Z4~F=-`U$;vzwx{8Hta%
zxO!M^p_j)^Qau(k)#TT)z1NQI_%&<wFF`?+>xWcH1r}A7O+tXaphEx@^}Z)irBlXh
z17W4?F_;f|bQO+@$6$eru*hUflwV!3!)S)Rhl2&j#VA<e@(X<m%x~LCv~4|%>l1t+
z<REpt@0*fy9W~F;xc&v_t+&u@g~~iKkObc4v?`jy*KbyBJFPx!tKg`G=9Q=OBM3Qn
z)_#r7XT9nhwYz40v3^=iDWDz1PrtKV$p5LW@9%WcZM8nLFqFq&wWtKrUvTrcqr)>C
z0Tg)s&cK`qxRH`t$(^wP3~Vo!B>Q>2hu_j&(!5NMKC?5MnMkXFv4sB8+^f+hGD~&7
zpPt_J;q1)#^6eZvx3KMVbjqt+@mRallC_S>$UuDQe+BcT)SG#2tbfDmy5uX(bPPeF
z&XJoc$DdFA6p*0O0g9h_;_N~zUbW3rj`dax%PluvgdnGzMy_mfNvFAQtd8&~@{%of
zUE@FWQqp3%<~uK5%>b$ffA8TxDX=JE-|>6oWHSuvh?0M>U^aiQe-9*NC4p~DuuzDT
zWFe**wsz1kQK{wIq;TT{NuMQugZb&>`|-r6$Kr^dYx<DM4=yDf{|U;S2oAhho@2i>
z!IV3j^HhE{9X|o8OTZ%Mhl3@K{B<4b+y5NrPSLykPtGzjKw8Etg)g&9HXTYIQi8z%
zIJY?iEaKCalYbR$;RieA|DFWb2k9^jRNuKBI-K;FSyOdc(QVzDGn1Tb3Nda?_u_@M
zSUy(m7*U4XUSvGlAz{h)?+v$>#@Afgy{~1#GM{YP)MEGfF#`Ob+{xKg@||&=$iK7o
zmB^Fx|Egc^KBN(yKHMieUghMFVk(%3xjo&N&7PpNT@9?U^IP*cBLRzHO`l^)VJU33
zBSv4b6b!&SBlc#i!D1bylBTzp+w-~Ly~C);h1tH7NxZaVj9fOfsODnJBxN;vUrWE!
z*17tM8zTn5r`q2+r~l<x&i`qpl;=GGLjkqYIanhSKnyzuqIY5#NN+#8|7t)54|qqN
zWN=jz>qzLulINO>Y677CS%Eg2n=t*dR%2(+EJ$69WOc#YcXY9&U_vyd_l!2Zb^sMu
zin=UCYl%ua@hKQa)ZbU;rFw=Yef2yVtm*;FUuIsiY#B6vKw#|C9XXfYin?wk1*BRY
z2Bo1q{rDolL}m{r?(mHxO6tpQjn0V86r`Ukv%^kWD;};FimT&H5yT)s#36r%8D`nJ
zIDY#2^_S+wlDgUW6xTVrXJ0Fl$y(C=&L2!d$I#@`F@*vJ7L-oc<TFVU^*e!81AGF|
z|DwWK5UhqHla7{;)xuyHto&Bh;?@JMdN9YqKD?rpuHyChQilKCYC|yov`c*XOREN4
zHE9L4-%?L<Ii4ypjnbZEVTiAGKl)$sOPj+HOM9k&_p3aH0=Inj&7#!9JL|<5Rw=YU
z`o^Tjv&%P+*QM0otKK!pb#PGy5xA;WlhS3h(2~Q;``zE6Nb^fY%I7Wi`hoY5erl^T
zBs+*Gfz5%tBHtb--~1FVrKEKbW`<`X{{Nx(aPsp1j@~OUbN=7ZJDv6a6?!klYl8W<
zKGZcwi8TJSQ0P2otcKs=xMvN{qOFrl7<S7nidf^UGvXwH>9Z0OXmzb6cVG*6a8T~U
zLFvL-yZob8dEJ~SPvV+h3Q<VNjflUGuhVZ`TDJrXugGTDvGuXh7i=A_9)6!t>fU0`
zEmM9Ly7>qb-+E2sPPm}Ev<)sZp64bH_ZwSYI8p~yP-kbW6YG||zPH!y=x`$!X8$T;
z?ElY-m=j8(6@GqdH;a4q+-ds~s#Vv*9`tjp1p5L@uSO<h0FM{hJlR@@t}bPWT{W#N
znUfT}8xWf}qyOw}VKcQ!%>gay--ur4nAYD^WTUL=YrQoVqUKrIaGX06*p`BV5!^FT
z7;ggu)_5`Tpqy0CWt3Z%uDCy^AbOboyBI7`ZD8-oAWbe9%z_R=?s=+uxe^F4_v_z!
z`xQl+0}OSCIdNohnU8miICjmqT|FtbVo)ECJNGaY+&ijt+RR-J2U>P%b(t+Ec_@xD
zmaeO#@(VQcN5QFj;P<I`HCWb3w<E@2=f@T>yOS54!C_Vp`N7=aETh9mchH;Y?2VR!
z{s9H?V`gn8;M43cqZQ!!`@U)H(;SW1o7Yam_~hbj!TS&g4CbH~HsbEUx#fnFrIVCl
zge|z<ipEF&+_~Yf?ZOHz{mUN=`y5s8Q1sfCZNQyFX4&pMxbR~rJhd-XoVHWFH7Did
zmqfl~ftbt&Uewo0*xkUKKfRA!S@F#4S5a}%McsnAv(?W1Bva>8qZ}i0u~yT?SdMm|
zt6sVayoDgcs%|Yvy2Qt@e{~9zg?i?jUBxNUQrI(W7Dm^p+?sv=FWQ-*CJN<jQZJEF
zJn8NUSS=AKa7KFW@}vZ+!2o<6x$c{emUKx0u2v2djHqU3tiEmuMwXc5utL1J8aeIb
zjAhGz4!B2SN=eiaktaZET$e;*!T|9OTel&4SG_HPq&e7fk4-m!vhHN~y*v*Pxov|W
zr4@RtB#X0Ze{h3&X;U$+CR<fvj8^B{ipN%25#ssyp-3Ya#WoHKaA1YLeR}!zTS@Re
z94W-bGMm-&W>cdCU&t2<8mA|HRor}}I$4Wf#EAS^dBam`)uc~BcFJsoZa*-JM4<B#
zq&Uep-n)AVkJ?J0T>ieQHcFHD5F2o^MW_0Y?qtQyv-A|NBqRZ|srRgEZV6jn3uAQ~
zoj2Y??|l1~ov@Ta{=0nD9M5Nhkn)sD5XSF+=<ZO6D-nih@_{UR<Dxe$JBGJE5^p#e
z{C?Y&v>-cq6r}H6QTFa?9I4;`uz-Ql_z+h^K>9!REA(|XS~*D6e?qC2gj75prej@I
zaMl`Elx6gH{`*mj$f&Fw)_5$z177V#^#Kf$za8<v0Q^7tzvtUg^&hXb8GXt``M(ma
z&5m%c85?Q#q6Rc#q_V_<Y3rMMbawT~qf3+vkq#B`2uo;3Gz;KjlLM{iZU8h-j@X?9
z3ER_~1XK-l8lsWm8Ooy@tgfs>+5;Zg`o>W9*x2W7tfAtEiU0tCur@v+n{h4wk4h)B
z{i+R?NjzsV*0P9GX@mdhwDNl-*q(;Kx}=sXZS2g{2HNo>-u$&rpN-IgG09k{3li+e
z6nw)@+@hZrqXBwtdl@GQfK2bx6-LN@cX1i+RYCFxOL!8*1d9i01j<U9l`LP8&xEiL
zg#Y%`f3K9y%`7(m{=rKEwZ~KtUek$o46k5#2JQ+m5fo``jy2*k(|GLG0*Mfa1Hi8X
zwQ`{tXSBQc_y2s4EMal<MD5O~q<66OY=a_90FG!UAo(I83x&00C$jVcfFB@>B7Nl0
zS3Isi?I}lm9E%a4AOimQU;+m3?qZ6R7^X}6w1ub}-S1XqJaWkcVFaP94dle*OoMu7
z)~nMhVU{6iZ#6%}f+HA#RfCxh?3$m?Ilb!Z?fL2*YRuT@1C^1SZY9f18uX{)7{@q*
zNq9hYtGSk86MB+Tp}1G25><&V)Q}PQ03ox{s%VXo*QdJj))NX#+l<EeYim9Lf1>AM
zy^_n_uIIh>xI_U}v2T9y@Um)1MnqIos=@jui-yaQ%1$&Nv=FN>tcf(UrntsPkr{iG
zDGsdYy6380!xEueOZTZ;OUK<fSx^kuN`y<{T|RacY(&+H*;`ddDD*|Q;TMj*y*-vt
z2sE3Y>?JeB`BAV)%$dunIyDO;#JkJx<`>I%`yh^W2hP%vQiwCq`v_u%)JfK}Pw_18
zs1P#QvXvS@&CNPCDWcgwxXD7I6SJ?shh}MAsh-pa-&u`1K>z@M?VRTIN4tIY6t)@z
zGwb1cS9Ly%HP~<uVrC86;oYdg9nPq`%N@9(j>HO!L=+Me=44tjx&#+Q>~WGHL5Sn-
z+buV+(R;!$VMa<y$`S8TEzfbi2z$Zs10TPVi6CNy{(z&7JMtgdPhvM1G$poLDc=FW
zuEE>%MtUR;2q%67O<IhMj;a=HgJ5NvDL_!OBC}t$T?M;ym!)=PYf{{`Wy;KI7UE4H
zk$PLgMi0!Kn{fdgDC5B@Vm!=5th>2RdVeL8%yg!>$si=jmyS~xF2^;xv{Ov!aj^re
z`1qloB*ki6)Gob`%XZ7hkcq>-jTl7D@&0>zSyZf!pE&Y?$V%cKVHG3*l-O_Qo>?7V
zLDd@~!{Ac;z|zFTqW#3=kU4<86kTM%pInV9=B%MYMz%~()=TEPf+;LW26Wm{8gU-i
z!hRtTgC+Y#hjSIm1_^}XgyRTtM$aTHC>fWh`Y2nO8Qh7_m1l!{9M^n=EVrtari{J1
zuQIX@Iz25AB&=8FEaqR*zEkLEsBp&kNBKfd!dFoZr<&p#Gf^gKM)i{R;qa8CMWIJs
z4mq`~j8)s%eX&cR7&c)|lKtdd?KyQXb!*jfQaS3kd}`xhgobj>O^3FOY=_z+k6ZlX
z=aez!#=Z<h5GwZQk7djYvH+yQIs4Q!<n24szRpG~9b!oAe#3~g_mlu}5bUw@RH_xb
zdGgGX<lL>xB(Uga?LCu_WL7h6BVc$IZHOUDtq|B$`F`!COaHdn##q3RVO4XP2<pg3
zbXYQ+tIoBsmnZCG)z4FyJB%gC|Bcq$6rvBu1G~KHO5*lw=vTIE9CRKd0$Dk>)n-VJ
zMi1+%s~rKI#SVPds!pFJV=6XuW29DeqJ|Cd&*U=65v4~>oGFtM0R5)9hf960bTyF&
zmeB_O042J;M@uT$Fz$*B<EK;xzC{s%-8KGiQ`PIs4_-JB0rf~&%s4_l@WwvNVY;`1
zf#_r053oEQOrgI76p$u==%k`;j@YE4#g0-9LLM%2>?&%L=iYu7i$MCmU%bY65O-|P
zJKNh00c~qt*(I>jnga0&_<AeA1qJ7z7vW0H(ESZg13t^sc@Jy`c{S>DF}9gT!Gl?~
z=YJr80Z)=(I$8vdS(`6x&W;2MAf|f41}^K=e{z1^@MuH2V>ib+kNXKN9SvJ=(ui3N
z#flLt-snFs=+m>Qs9%zwKY8DBRBGMnbljTgf0lFiSScdYY`SrSh)X!_JQYstN34au
zH@Wi3v8BgYPfp-&x{zA|8*@8qWM{Jx#G#<2h6i6uPiL;l{*2sj*KnsipO_L?vbwGj
zl`?;;Gs$>WoTSV8G3ki&V4r!mNfxQwfQWuY*K2a^foWTQR03WRV+MRaWfd`CFswSq
zuCu9bgInZe)Ib=u9haybTW#fmlz0<AVRT-7+(t%Zo|a6ppZl(lBm@<YEBJ@(z0rfd
z$bS;f*B7wTsl?#Bs(R^N+iL68^%F9$(6oBIArn-LntR=(*K!_w5v<0IcNi-=p%fN`
z@>uaXSQRv-_P4M<su6+;V<CkKv5Y{Xy}g9b0`*6pNUYc*&!_sBZIiRJU}tl6rg`O4
z#oL@3;aKe=jR|O@8f>^C;s!%-GPtX@w*0bR{~A2}y?k95iWcvZa#wyRLsTk$#%e{o
zS^eNy=k2_b)>@i<$80Y-RxY0teP63a$Sq_=&9Y|cWInvb=d==gsm;wh()a9ZTYls0
zplIA+d{UBSl?G$<OzN!SlVbYb6JHjE@LKv!H@@c$nT-K|FZ?ER(&%n2nkC?{v1WzS
zQ^{IFH3Wju*z<iKii)ZgV)fBbZJHc`3deYL^iCPn+p8}M4D~v`+}-ZAwYKdlRSRKN
zz%)xa-oS-r!_qfH8hjdMX7K$}=bQt+Km-}*Pf`QnJ=VVLwWqDTZjhS1Ug0<P?drS;
z=-P}7a;)8`zs~bNA<|^_O}e7s@aTI-tSQHPy|L^*>DT*mAaa*!3v)f}dZ+Kw$eb`d
zLo|D{F}bzh{%Xmcc<!uOxq$+npBQlLeNiWMT1qhy?I=4cCYp}WJ8=$vTnu^27UL%M
z3$up6I3!{^aiV5Id<Wni)yE`iAwPcPDTN40tC$~DkLN~X#-uf&9Fs^b(q%^!>?yy~
z-+xTv5pe$|mYN*zbtT6UV*aiwlnYATj&4n(mWhDi#v7J~gQLMf90Df(rqXq<JZ<f%
z`7FIirgVgCBtbTuYcL`ktq;e$>MD2IZP|>^=0t}i-`Yq!cc&5?KaB1G3+z7zzQ$-1
zQ&OyPEeG9qmZFzzf3kbm5pE5qakmEH#vsmZoQWu6gk?*@hTkg+dgX$;IL>Fg)n+?4
z1?Sen7p>*gC7fS0yuZO>RpB@!p81AlV<-TEXj;?cFBcsIBp7<N4wm5#+8sG>jQmrW
zVp*U^OS4K;>6aCOdvvuu=Z=tJ9~bzlE%VDsBn6ed@{v2<$RmQ=5c}YCePywC&*srD
z6&-8>9lbt#)3+UO^&;xvbI?cM^72EQWc{p($j8DS<plsOsg?WGM`@qqXHtohb^cm=
zF0RQ%g@j;t{t&0%8HIxg4-x6H+B*fmR2H9z0-AcPzckWO{w}_4Bp&!_1$4>ieqw*&
zNYha<uX&yBy(exrBz#-^O`{(a`U8G!^vFZoGcoWarUepBRy>ZBioODIvWzJqt)W7*
z4c5EraTlTDcXs9tp|7GBVx`5v=wRDMGJXt1(^#XljP#A7mva1p5y~_S8e<;>!T!=+
z{iH=|he12n;D{&-0P?iqF>HDE<U8)2MJPF`jAX0+lrtD>r&we3DaZ2ozUoWCw3gY5
zx4{{Oe>_>x?s(d`<MOxE6$i9#yQ4A(iL9Dn6>M_99*=bQCY^kOxZ#6CHilmDnvET{
z7g0WalyD8X5EP$xe9EzdHtd1$61Eba=?$uj8c^W*ZsSD68a==I?JDpAjfBx^69{Ct
zmbP(zB6{Z^Px7@6F$c4lsJ)9snl4R~s?qae!(dQ%JHX)ey?oIiWVGqk^QwZ#@X{Q1
zQSQ9xMTNh)Fmb=Q!LRGyS1fd=G2q*M<IKZr$-M5c*>3VK9gH&`067vE3So>z65;8v
zAcO=MX^&&|@HQTEQe!d^cs$I0$ZUe?`|;3+*HU6pb`^fNjM<wnc1K$C4V+f>wdPki
zmnwcMl|+CY8<|7jN&lXGLRPr{l64XkY25VwXqkbeIY93%b+l;r0dbcM){w}|c%Gtx
zR>=Is*9ZVG^`u0FR1lg|V+5WfNr+)R7|u!^7j4*=-f8Rm@;cHcvXLSJsWV@e-ld$x
zjLz&MKtuXY31C%~^z9ToF1%lgfiR66s5a61GoyP7>;CZd^1L^K9uIjJ%`9#Z`b1gt
z5OMJ+ZpF9e9Q&m$&pXZG6e=G4a{&R;jUoc$(#c;YF6l3?9iJ;{dDz`cA1}UJV4Op9
zt6(8_G<gt3xBX&b1Uj#L^wV^@s%=gObc|!s07&6ZEi=^+6IMJPB2pbx89sHeXLr#a
zC`IBIi!(C>h^-RBe%)JuMrX9>jl2L}(adhWGf}~}80B%(^T>8f5XmKKrtv$Bj~I2m
zo+y3X+WF`9+lJ#H&#!IzZu^u9?R(5mmg99de8rPHyb2LWr4Mt_naffd(A&KmEC@oK
z0K7VpD+ec9B;zi)<>H0hwsUY|`)M$yx<rgunJ59on6R(DU{s&F`qxgqE*j_4m~#(%
zaf@W@x_ShOtt07VQ==){o?%1Ri_}N*AaFs=l{Xi8MRvV%g`+Z2=^SD(?Z?Wi@k&@C
z!=QpkT*O-s67u-jfR}YMt=ISd)-Bz&+|ya^%~!AR+tV%kF`a-yyTfEx)mHzlPys0j
zo;~GcDuKa;(%*=m%RJ`Z(&5VPxYsOhL38Ul-Mnt!IU@}|>*JviIGN!lS8Z!B_RTVv
zEcqH9p?h@`2b*fL@e3kB;{Dkla_b7_vmKY!KJUc&1@?m->n!?C<6Mj@O0}vxLM(m)
zp6LwB#QRJ&eELj9e5G;sHSwvm#ZH<pYn#^ZYBBr-X=&)k!W7Yq%Q~;ZNYn_MZUfTh
z==u&CA$`erG-M4SV&I(DoD~jmW<?0?oJ2)sf`j+qfCpHu_{<f`f+>tTJ9o!KrOfUq
ztyAHeHBE{9bO2%_XaIx;WdGorLBb&eWT9@)t<@?ZD)6TxxOGEO17?d+6YuL!C_1Yb
zY%;KY{cc)IW~jTm7!aVoc2eXGaSO8=Y0mO?*+@0WCUbu`Zi>vXJC2hl5>pfm0=sYy
zpB1ZX^l*Z@W#H%wXkaiV0?MZ98?LKqGHZq4BL{K2s|eLQV%ao$qC=a(Go`4)x*G3b
zG@w9x56ZX7W;IEWLp$8=cupD~$XI7PGZ!@3o4iNI(Mh6glG1WguBmQdD4Zsc;fWG$
z(PQdl1xvGz{7ZRMWe}iqZFblg&&ycED<x+U4s{354%#CHaiUuf!sH|g!6Oj>pgF?z
z6{{0io3lJB&p8RE%2RY*27$w`PaaJNLztP<AmWTQlo{=ZjE_$T2yWa$NCqg;g;$?z
zpolRd8P9|du#T&hk>^(o;MhWXl8N7w<lqv6vgL3x^x+TzZ%=Z=W2b9oEj$OE&%#Jp
zP@!haoCZ>CM+-Qa)JUCp6O?dn%oq8~vWVHZQ6jfi?oHieB(UM&)=pOpdr$E;zX8`C
zO?p_Gnvl)@lo#x$i)%-{tW}uqw+v@dsix7t8<i&D-fo)P>(o`<a6OgC^bOe|9k*~6
zWqO#G6z1jf%UQKHvzX*_Xi$L@<X2Ez-&n>DTBHUUB7mV__xjYh8~{JdY^~*_1;8D<
z@tmFfdIAGS3&!3gS}bq@N18Y*38y0b#w4y78foUqLFD%Z?0~F`Tt1t8xk2&fV$C|;
zVGIeXe>a4fB!6G@1&y=^67XOG1vpVUqVLt9?`1d6=8en`iv%Ku<5Y>WCo5ArKcK6*
zPd3}ha9umahi`A8b%WR;p_dJ76Q|`99Ri16ch^ST1rU(}0l}bIFJyXb|4dE?3x>1m
z4EJ7BG!N=f%T7`Uah9P$^ZvcS$p}&CUlM>I6aw_I^;<y*<Y}1&v@(_v9z@wJ2<}Q!
zIh%U&pcgRc|N0#80HaO^jd!i}?XJsMTSn0e0GnPxwwukjR)zG>oG^LYlL~uUddkX<
zj1;k4U0rz+b-3@Xo=XiRib2zEUPA2@Q5Q9BInyO!Stqd(>)DNO4DCW)i>qdiGi$ss
zuF|(q;L>hNkf;7efDHsU)qo&uk6=TM6O@SVU6@!z-WQ@4)?b@)N$MuaaibX70AOsx
zvusWy*OKeETs2wBwPM3#g9xXgnLt|{d+0Nn?)MgytNrFX_PijQGpJFUH*j#gqrVQA
zRLY7gpWf@-^vLH-;<O8JaLn1Tm(&Q)Le0Jwp8g)~_~yHhX@H}nc(`1Nz%l>(poiYO
zALf8HbHwMg_!}72cSR;yzCGDL`H&M*17VQyW(JSH=?i>cu6DJFesd#`1eMsHGO%A-
z?L4X=@|=C@vk;cTLYk=8LvV<sTX$-<RhzFGYceKGi5u6gL!~e^d`E_MeAeM0gzb$*
zLTo7B4^2KY0Z(<jdEwk*OK;yfb|nt=G=K!QA3+iVy**?v4_+Zf0>s2H5J0ZXgS)5D
zT5)Bl`|08!9(cH7Kb9;tya%K&XJlS_a9m2tuoEqFCcjKH8eis9!)IurYntQUFK2gc
ze{`W0Kr9XkDl(nu>ur0|n~t;`{--`S-I(50WmDiz40g9Uh(2+6#|0u)Mhz1S6B0CO
za_rdQM;tI{@wu^Bu+3-U*?Je-j?P8Rf4m}jdZ+e0!C~-;kv?i`lM|>UJbl`%#km3t
zNIx7`yr2<L1*coPgo98Lxlt0E-ECOkT+<Ft3(`tHo-AGXoH^vpG<oJ(uG**Smu|RY
zlR{Z1yQ4QdePaG~AC}e$cORSvkBWi=;Uoge;tFPSyjw>4NJ&rQmWZ+Nc1Geh#5=9Z
z(Nf?3-F6m{x4c;`76O`-5&q}gIlv1TfC5~iL?UQHBjL+v>lW}CrxS#YEgH8QPQT@s
zRbgY>(i!2H9sjBVvo!DknB#e}VuC)~3FI6&;L1G-e0wwrtK73=>MO^??)&u*AVAnC
zN+nv<r(GLyrZpd9#aE7WYXNsn)-Qs25Tf8R*3xa);L7xMo=6LQ%62@4Yk>e2vK&v{
z{p86zY$DcjFe7>Gb=v%O`Qe+G?TwK|Wv(`3pId*Evlr}cj`!Ya8t<-i|F+wzik6bs
zAGg{w6iwrPJ${3gK$#Z)?sA!X2kN(jlH*beY#f7)WNAQ9stDVgP~_7>1pZMMChlW#
zM*78*+a~(Y#^1ePXc_4=5MbYX2WoVIuI>62gJQH@$eK?m>z$LDh>ZjZc<w&A9s2C;
z*7-=Gm6z`OnpLKOLUHk602UA=DKT_BJkSZqN}D|po1uN?wPPrDDTYymB4q?1>bjmN
zUNrT3nt}8^4!`Qj6F15}O1!uTS&G0FUvvYKpliuBu%EA3^~+m>yLgskssuqsiTVvK
zKigV8^8)e*3+0qUEqs?Q2$>?158EVm)boy+mT}mWo>g&zC+xM2c0@+XlBATia+m9z
zo|1$~pA<9SC1i<Fem2G|UBx?o6s4HYQLRD5T41oah&pnuKxyHYDu{ETT+u!D@IzVa
zwzO|=<6CK18+$g-_u>?7tk$GFOZB?L2%7linqfFAML?>8cb`)Zkm8LYrJUqXnu)^X
zjj*%$?UGlPYt-8^V0O$!-w%x(#B$ip!&eHr)CF<tji3UV1uf<W`fdWP-kdBEqrXlg
z@Qs%|d3X{cXS4f4mk|{P^hSi?(|EYCPv7Vx^akWq80adHlE;b;K61Wjsoq)IGnc%b
zqt+%5&noG&N(h#hxw#Bx9cq;rN>J`NUzy5;yNw~MxYp;nsqwAh_V2II+!Bz-dThad
z0x+PjmKGyqroI=KkRcEk)#1#i3&W6*H#!Dl%y>M9h9$EwYs^qa3j2K~1_~YZ&5=T<
z%7i=Ms@|R8+8Zp>QN>U_mS_I}W?lR%zIagQ5j>hux%tiw_<lpkug?{PI7@c#XNze^
z&x)}Ku3&KvA&JfQm3exe?n>2YK_a0YO)Y~{l0J$xm0u7qF~kWjKbmY!Khsn%ZN5cE
z>;egEeHIlFT@Kxz?)f8n9foQ&Lk=KVzHH8gX-wfy+Hj1jP2)9GCzgEi*GAE#(Wb(f
zLdnhHn?276!G4^wdav6`d`k$zf-3jbdT23f^BkO`6n$(faWWd=Z>=z)5sBmaaq3)r
zs5fC{<em6@KI-K5L3MldXHCuLv3+7Ysg2oksvLz!B^%)><Z}u^h-@t+gaEtj;vr3W
z))L3ljhzT*ze=qNB~(~MK8?>n5HxV0Ca0`2cemQkx$&cb6w6n=3eLJrC2c|Jctimo
zL(*2>)%Hx9{6mvZ`KLwC_h{^$wB4)`RHB9N%4{?WXdQJ&gNc2qDNSAlJln+NZDnwq
zA#U{j2Po%U>vF|OxXPgnTTcx?fDgLfHugf7tBw!T6gFO=QPV;9&hN@kWx{oZ;c`Rm
z>vfdNtrNQ=4O$)tyP4KeEX=$8#YxxOt(u!t%>y3?;p0Wyk9?K_Z*4<sd2ViTDGcg2
z#el*mi=9+1!(0DsfxGIb!|~6lUA)%_%gr09zSdcF15p>pGGiqIy3uJf?|$<;clkVu
zu_|H2N|I8A7M*sw3VLOt1_8q8gqD&ZN%5bAF{!D1=R<g5pE9$%eE9A>@QW!nezOOD
zaCodvapi*&)8QgLwSmVmC7k6E)gZy7vqc~_itkQcO%O*uX|>g@wyJgw_sb|QX5SBK
z&T=E^N||V@Sz0!lWz?Vw3YC7H8zSyz{ne=VBet-IL5v?W6ZKmLo)jbgd`&%S*F>a6
zi*jPj8-b|HO!MLV`)}JLoQw^pKja;)|8N~sYd=oS6JWzo(ZhTf?HXI!M*n=@8{e!U
zi-Bun!XONuicFI@%(hvxMmt~8X7IWj-S^daEJcE*N!!@GVg9C&K=%U-87T(}i<2c|
z)NzT^etgv)aisb7el?+S7>@i$thL3YGyjiRiIEY<``+&-)>u~c$IG=Ug#0%ZG<h(Y
z@HwGg`dApU%>baOzV#P)B%ejOAyhq1)R`sE;{;>Xy8-7^7Rp(rNJvnZplS?AMG!$q
zwezZ|LAAquy3ZN?b|Q!lwJk;kKrq~ZmlhEYDj^M;udyHZO*zwM1BHfaDFuEaCLOL0
zeq+|LMA=1{V7G=#=To4urXh<Zt;&ZUQ^EjXBG|hvO2kU~NjDPf+pxRiKLofAA_Qc5
ztGjRAX&{R~Iu%94hEfp&6Rv4?KUzOgXS#5gQLrf_h<*_%Y}nhqEimMfNgnY!>#*bX
z#A(P)U3-naq&aBo5%G@P)5|~5!TrXgX!jO4+&1aC*C=_H)ZsDwFh+e>mNWcFtA%tm
zaVBQoKrrr+#9YO`m$sE%)9|uK>A18sHkdQq91ea0We55}`p&TmWK$H!dGp1+kf+}O
zE^ZGpe%4H<eePHCOdyt(+rk_+a<y%<r6ujFpHne>4ZR6}xWkvgJd)E>#><T9r35;R
z2p4t4eoy4t<ieXabqKj>q?Jtk;Z#M4OzP9?;}OoNBT=pqHWvlT5ARee?|am2#%ezN
zB&gXmJVHkMU?R@^x!AQRK1Wb0hc&n<FjHH_GFAI)lr15uaBWL*ReBa=Z6P^F7hlS$
zrGs@xEUj?PC^6~5;Gf(0PqmVEM7A~6iPe|Mr8!-?5CEt5sSRxvLz4LcM-i|bBn(c6
z(t;jKJ7KdC!oT^P1Nhw|&7+cDGCXnuSq&#^<)*pLDX2o5-zDeU9$}%p;b^;XnJ#qr
zRd>~oUIoSQT>kRB&b<gMsD<;|8Ibs0E9VxagAY`)ebZK&Uo7W)CbM~M<`ppMxK{Ce
zQ-N<Hdm7PCo9gJ$Ki>bD^!w*=M0%aRpBLXpZ7$PEYX*h$q>Bl?`2|Y$l<oP|`^x$p
zlp8m$EsVb4)GH#-Ei%@pg=BN;LDGoyP936E{DyM$!f+P29JFw}QnnZES*`RO!Isr@
z1vL)*x+}!z%=$<MRHi9GR-6MF`+P@S5hUk3VlC0}v5%9qpEYU1Of$*mJam5!hwq9V
zFU%O%_roOc9z?#_mi{o!xD{yg-y}kJTMb6O!ZRlk9WPJsL>VX;2sG8Ls#dG_dm3Ab
zKE@J`h>Q|asjXrr)s(#}x1-*fXv*?Bt`ZFoZRq%^*#AaA64C!Y>~y6tF<~oUe~dHT
zk)L1H_Gi$C+Et0(^cN!;+yzp!$)KIqHGL^<3-F=aj{8;B$#$$1AFBkk=cs!>GcHRj
zNIJw>bah32u~6DNygj?)F{Zh3(u0BV*5gJNs~bs$rGbaQl*G`d=78nblt>31vTfGg
z8hne%7@M0nV~fX7GsM~bA~80AxW}M^e~H+Y`GY_A&uvozCjex=qids+i)~#9=68Qb
z5`oq2W{UuihTILJVkQ-Yse`bBAXSR9S|jr<A<~L^d{}Im((OGtI}CF0T6by74pHK!
zjOL+?7Ag6jf-H-mfGSMdPjb*HYg-OVe3%&affqLLMo3|k6i0R-my(KG7$P)wGEs;^
zDqs6T(YS?cAzyUBFH2tdPOO>dlwDGE_Pp6m9Z;YTX9Q_<M={PVIDku5`}^5s15fbq
ztp*+?>30qG3-wf{1tx60<eQ&@7GTr5eL@u=s6gchW+BwEq+ZbKm_I{#=Mc?~w4+Fz
z`Qx}UH1DOq^Ay`KPh=Y(qLW0-m|-@bb|ue{XnnU#$+r#r(1xgxC{ItJi%0fr+M>cU
zAv<kAC2b6=^JN`bxdo*@pAkCL=>;%g-t#%{dyHflB~?kp4Sxvy;UB(VKS*kV6Wmmi
z88hU;)3qqWsFvwa10W2H=f!_Oi*yr_u}VJ^i{1<U)e=7}H_K;iH*=`(Dp#)ab$LhU
z)T!+-v^+XkCl*g!_lP#O1}-XTycNFryI}wZ&|eQ1HDfZ>s~PlzC>%8gEBbJgY1W{O
zI^1F9g%CH`@YG4T^39e(iQwCMbNMyio@*S7lKtd2Q~)G}A+_<~cmX3CucXCwgjmtr
z$yl-#cV#E=_|Zo2I`7KvZ840Q*3=QpkoQwUgaUWDZy$0Ur){v|uNJ)KFRyX}NwURZ
zcseLx?h-s6r*y3lAOX3rEIp2vX@$?a*)N$HJ73KutBTpaTGfPEp|d|sWjybhbbkpp
zoE7m{xqD;F%d21T=M>7Al~j4b%riCDpZ|mL>duaY?wmsutYD|(Aq!8^MCKpxrkaM|
zCDsl;7^|<4kT3>1!TA@bq?4p0YUnABma5@`u*jh(%(8SsrDdTXF?4c1e~w5wR6(?_
r#0fTR7p0xf_yI;}|H0d?+xFX~WPV+K8OaF%{*w~>B3dqN5b$3B#{PKu

literal 0
HcmV?d00001

diff --git a/doc/android/appinstalled.png b/doc/android/appinstalled.png
new file mode 100644
index 0000000000000000000000000000000000000000..166120d48204c4358250ce113376c329b2f07895
GIT binary patch
literal 16805
zcmXwB1yq#X799{pP-&3v?k?$O=%HIcT0l~|q*GvMX@-)JE(K{RX^;{DX#wdHcz6D_
z9&3qAefQq;o!DpZ1JRo5iq9}fF(DAhGi4<?7zBbU1AZ=ij0(QfQVRS7|6#mQGIWPP
zp5P<@p+K@e5Q8VtJ(Sht(U(z)2-u!taLIjuK&T<ga?(293;Q{K-a0cg_j3zdBdUz=
z!`|aKqu@PWb;y4#--;2XL^u%>8hp*lA-}V?9CKLXV18pzb9$yHAB(v#tJ2t*ugBpw
z(b3^8jTTCcNB#aAgVf_N6PwKsUxI=vGjnqIQi3sG!OwiWy%|&ZwgfY8a}JFhYvP$-
z+fl;v(YT-X&{IKKIxr;PXrfB-@rEg;^F&x=;PVJl3}0A%F-&%<`Fd-XcYon|BlqKV
z6LG{<ppp@<Q(_dv`*i=zX2s#AY)(vi?jr%ULUTHCz!L1@{>8U(o^~F+7ZDc8#0Ub~
zEbI&`90(ki)%-F1UBfdOI>>JxGgL}#=RfVr3_aYc<eS3sJ+Z0{&w2y<7W2yXaXDBR
z3PmxtrVJQI_pOZZQ?sp7c{F3J<1C0H?CtsDgLlbX6r3kz#4036XiULg*HMQQT4{A^
zKfK?neexLcZSnqB^8ni76Nt3~F-tOw()J8D{8<xc0h1MRgos410vSBMN3m{I|MM+N
zy}00+qNQ^YM7lp)5Ul}+13^%@tMz`RN<|;>>4-ByM8PK}du<&~inx7mNF+mk5%&=m
z<MwOwo@uo$!S_pU{dLLKNkFEghyT5L$Iji^N~-#w=IH>(I}VBS&PbQnsO#sd_d)Hl
zAI5KdOb&Vmul`Xc-sa0F8_Bm7X%?c=^mYWGcl>NrQI3`w*W3^(UVihgc#-qtezoZa
z3{xk+5RcWMzvE_L^Tpjh<%Q(H<!$pz*Eyj{9e2L~nw0~Idq{_1U+25grLQi&c^YE5
zc#!#CA0r4%Qt5P|#LKVpMt?}Yx1`C%;oj&DC+Y6SYikO2qtUdlH4hVp;1TB65r)b{
zLkscdo$9^z7Z8PbkB;1&=?arE!!@I3W@Z|2LvuT%?%DO~QZ81BWNx_KD@DxKv2Jm_
z&x2@Ruhg2?NTgV`DvYI-zP9)5z8N1`zAU-8dWA-apI2H1$CJqn%8UB(M>yk+OI`Gh
z4GN?%ZW%v7sAK*v9CB+U$4}lZ^disZoC|R!BL4kGV{Knv_75%uw`cVeDrBSZFUxZ&
z<}oyGV_FEb97nSa%8G!y5kA(0TWHrV4p5jU=+fW?nqQWz)FI$Un>&|JDPjGGEB|Wc
zP2@k*z21D(zp_O{p5D1b7Vug9EW3?o>@=TVmUL@}x)6Tt_Nve><h5@LeDqLq^9$*6
zic9T%|Ha8-p2o>dDK_KU(Mphtlg7o$WqbUc9pivytyH-tb95R5juy-N$IO}`$2#8^
z^Kr&e<?>yK;#Cb!-O;IA4UV$0U@N}g{=Vu<xZ&P+wW=M%X!=D_v=`o=!jmnD`0Z-N
z;fcD^9iPc5X|FpPce(Rn%Ju%Hlp-+wHgEgJ{(ve_%DpZ7u08dr<QX9~tG;{@TqXoc
zpF&IODvyScVnq<JP6$68UhO4%!z8-pPkZOp7_A&J_9);^_vu0B8@#*f<THub?O%ix
z3zbDVrQDliGV241E0V#NoHrUClARk@<evAn?h?5-8Xf!cAJ!go*o+3fjYG^8qaNzx
z<sN=u?@zd8>j}~?UAW~xne|VJzrI3aA(Osmfk!b*qXf%n{)h|XecD5=i2kU5?u}2w
zsCw$Y6<wpDpC{{5p0_b01dZYIt4g_|TA2_jxdJp+lxMYa^Ox`I=6m>__V_#guDyjG
zpG%(Zubb0C=<^@^3U-q&gvenw@8V&@AuolLsD>D`1i=E_Bhhy<ba?b5I`urp3`!s0
zhsNXNXwi_ii;P)CfFvL?k?hrQNhSC#w+bF-J(86L8Aj~~dF+E`ht@=qna4wvFex3#
zGd@pJjqP=R;vVj&Q!oit%Gf^`koR~v91QDo{2&upWTd?dja1|GF3&GW!-XUxESSMN
z-5v1sH&zL`k8Lx4r1OBis7_L6kBj_0y(FB#ii0LSb<<2j<{=EKG=sJ{hR4ip+otF8
zQkC=32ctu&6vz+oW^h}{Yg@3BEw}WDS9QpeF-<DG)J3kS9^>mXbijc5kpH8h0R&Hr
zCKQHRI93RU5gXYmJSPEXE3tkyucb$mzmm0_f`5MalI_29dFzCB`^xDIg-0M9@Tdt|
z6paZ}MoEyn4V8ulC?_^qG|+tFJypsac8U3+@N9BGC<W|M8P6#tqI!ot<4Tfne$TDn
z#-CUbxkv_nyvPHins%A^AO?kWe3ehve1e?)b12YAG1J!!_GAzO(b|Ct5!*C^v<8$g
znR2*_qHB1ADH$O%944BE3VELfdt7#U4uPbhE<7b85~G`9CWJziW0zDksWn*`zQQmG
zvlYNHRB+!xwAhbwjS4hSxhHV!iG;j6|AuM(N_F#s2h{doc=3oQ@uFdZ|DZ}JXI?E<
zHCQaSMik2BDQS2wS>zD#WUWP}ct{x<wUah8;ynaUx5wH5YA}gqn3NUQ#@XX0TW+!N
zBm7%*OH!^O`nP9oNCQ7od-(6wYcwKAK75*#$T<7qDST`D{?(G@<c!@RrgC#3D!w1P
zR6bhzZ^d8+Eoj~pXQyfU#Bz^Q@dH*-0X1g1xGOOXDaNNtZI)YP%N(pQ#c=55#9`>E
zXI*<vX5LR03VNeprm}<H6h<8=Mpup+Sky>ivJ9q`I8xG>e?(HoYQ8l@3YFIBMwp|K
zjupk&C&KA<d?lIp&+-Uguo7U-yn``om2cy56ED*AVe^n`6%WYto^ugkFqLiJX^B=e
zcx)x@8o>!*V!2o>1uKQUmPMzuHIT31W)~{`QisE$(s=V(#;#EykB1!$?Ae{a@GPiJ
zOBOU2N@fk=b?adcriEw<F5E>`owr+JH>9!1JZ6ADe4PBMVM51ACm5QKXEa#oI6(cF
zLDLXVdLEOZIGoR+X?BoR@o@p1VCXHmfa<Vc5$$(_M9ymt3}SR*;4$i-B1i%;I7maR
z9wUNF#8g=9;Z5wrTnK`07<K)EO|Mr-FhOW<#=d<COp6AS^d})k))NV9-9I1SpW!iJ
zM#~gvK1MBuMFj_A5@zxhgvp@kOl;EfxXOP0!DSM@9r59fuJ|<DYG@rq-7+bXX?q9?
zyxx5Y-AL+rVe&f&tLQg2lwfpLHf#Qp$lxLJ%v4ynm15kyZLR`kp&>)c!hyZZ^QVvM
z`RbkI51?%_tZ-EB&D}B`H2Ph!O#b6H*NPa_IMmJVwmWUigbQgfsO7LKgu6W#WDM>B
zjQNq1h4(%V1j^1~390h+64B4+;gEby@>oX{2n%)S!B4uIii!&MfjSd-e(^?IKgqV6
zTrwLbM^;yV#<6^gm#%JV!c&$4W?e6Tcb%h?9nxceR~khS%A52){Bm;EY2Mqv(<$>F
z@^cz<U+dZ96J^6@fAdau-{3Jo!pM>yXi#lGxrQ^KA-<7TD3w*d^Uug<#YVCD^S!Yc
z2P&LzvN*bzNrfrT%^rs5@vNyXYl1%U=Qv-IQm-rdfGcfM6nxUt6pAgH@GdH0-A>l$
zyU5n(f5*cb5?95rAy3ocIy;p)Pl|zPeP_N>CBH|(O7wVGk!m6YGTRql;R?P#>)3Nr
z_=f4k<?n5()gN0J5<v{o5LA2ngTlL(lnaukQ4%<}W$?l|kd_;8)JE?npNSUI(Mt7v
zQ(n(_7Vj=OTE14h#{^+cGD~l>*|*gr3qq5r+BG($36a>4GI)%FheH2YPJjMoD-3E3
zCERaIBno~av5|uHEm(W2hU<mSW(0XBnN;+oTTx1Wc0Ajpoiiq+d?Fa-0i#-$j;7}O
z)Kpz9ty=f3?|re)YmA!{euq?=WeYm_UL1UJoa5Bq8gZ5M&F#N8vf7s3o2?4ESzN)S
z2|USOA(!ya;8%80@GF|zt--C{+cnLUktdbyM2z}Nn46mBjBOP$rNR={x1Br|QaA_d
z*auwgtf~^K_pWd6l;{hCKGuLV&&ZObHtN<CwxJEvbPCkd%g!L1VxVMABXnepDz)tF
zE1Q5}N+aZrD2``-KN}ke7OvaUY_r>M!QCl(7KWNHiY+aFkE)sPW<roJRrnV}|1ph2
zfZ{RwMcK2tu#dFmxRTUuY41?OW7RTctA>1~=5qg}89TS$o-d+5BZX&X?zA}v1_s{W
z-HyFD{QQ!;#rMpC*9_eGrhVB+tSYlFzWWP}O-?To=n$Vbvm6x?$PEn*eSUpKnd)|6
zvsw6=cXwKvZXW0}S8aN+zu0Wi^9YaL&3@B_pTnhC0j6M_W_PbBnf!2?Ri)c%h>+Gn
zx#$VgM4|Y2fpYD3bFt5<7z=rNHK?6+t354v*w3|S9z$I7>tI?O7P2!I51J^$i|8bv
zfBW}}St2S5)QgpK==11JKbblXM{v9wBW`Ft{?<|VK$<NIFI5K>tqpd~Z5b&`jLVrX
zm-m#p04H@FlYsbK(V?mh>x*cE)124dbK_9fUzpLfg4aS65BTtn_@k!QN%(9`yymT&
zoW}Ab?+=6S{d9G8xrslBxNkPtPgQ?D9vaOS>I4RhvRgbaQ3H;#@M^KiKB7cDCo3uG
zXhz>W6%NmMn7?o(l3=wcI5@UFQMA)+o8vjlR`c01;!q5?FM`>TT}jDJ{(K_NA^A5X
zcx-FRLaI&bc<#4^@~*!`9!|F_dBBygq|x9u&hOve668JH98OJH_o>`*DMIA)+}982
z*^kC)R3=^<Ox;)oaKm>S>b%yP8W%AY&zmrB75xQJ$I+YI5IAY?l9bw}cH)-e%rY$&
z&q6j>cS7q@!=aQ%bJxBPUp)6Tybs#b#xA`iHz)2%c)wlvzA07>tKIjPAO);cJ*T>D
zw*n4_4^aBO?h1X_{`N3Ijusu8(*NJlKsvkO+Qm)H=VNFx8zf4O7XFCNPtN9BlM`P^
z@p?!x|AH2c<v;=j`cq;Y%<$da-I$mdQIG9>ZAW^sO@DXj+(Zb3njA|zO&v-SE$2a>
zGJ@}<yj5f_Z#*gDsG+c>aWf&IAu0Q!m};j&y#6z?9*ANLv#-4iie55U|58?Rrrb+P
z$vDlu<HPtnwwMy*w}Bxc17UXPY6#t<^wK|-OAS<X%vurh#exP~O#_@oZ3oLRtv1I}
zjfKflIGSW|oo*tE_`><%)#<GUDtguIsvf7(0GFvI%BNJ(lE9m1RnRcuizRnHKE7tB
z#ilo_G6SwK7_58s)5>8@P0jsW=beD{5WL#7eX{EBm48pfvurURH(lMCoVPz&!di~{
z$xe=sjT#*uLbOX%MGilo{Pa8g0@BGItp-I0-ED@jt0fdV6iF2r6$Rodhu?nk-_^<J
z-*q^PHi)TK%f6V6;q<W&BK0mS9rpJ2i%m|(pI%Da+m~Y<spX3KoNiCB=~Z5?+~2MM
zZzUikeE6=buCDIk6C!ZC?C=#Z7m5@Uhq*dGfBJ-jJ3KtR;=LZP`%y26Y;Upo@Xvfb
z?$Nw$o@r;GxRa#!-(SElC!6*q?~W2dI$Oua0p3<+acno%+npG%=vz^#InJ!agrbI$
zqF8UK_CW{DG_S&a*SK6yAbU6FqH1_=LVQw0C#dWZZ8bjJ*?7YPHdEf{>9lLz5!_SQ
zRM8(3CH1Ls1D~R9A?RO!sa_+doIj_MJ_IT!r);JoAd;vSi9h<@wApzX^6O(w2Ml`U
zF98kK$~ZU~lg#6>dUQoLTnDN-a3;lg(#E%kW-)zd2g^4NQ|d(lL<9tnX#`z<s@_~Q
zNEFB>Qi>ZvTRnDQoh!(5CDAFuCW<6J9xS(GQ%QVoYx5m~vxJ9-pPikRmzRtCos$bV
zOpj#p34sf&=@=LYyZ!!_m6cVlUFvoCGv|BLr%!LT#|!Fh$L@}YxprEboDxa+HWOYP
zeEasTtfodEdbTrV`}<pxhS*WB`Q7nz$mLorS7_I-_cXHL`&iJOyIV--zYQ)B1D`B<
zBG%R{DSCcu;Pr4T<LkU0sw(S;M#$tpgKB<fnb@;lA5f$CdBRqXgNhsU19PUS;z4xg
z49WT2dA|S|D;;_dOVan-_H*I-mzQv@cm2=$`Pn{F+g|>*c*jXO*~r{%HI}er%E!8U
z9&~)iRCRu}NU7XhTy{1SzW?dHjMAHlR2e}E?Nh;YS`dW4POey4S(RvBFU}%}3N-CN
zM(^wE6D2KAjea`&OlaxN`MfQah#MM&(s#SS9TfMS(!AL|y5C<tQeSok-uj+yYiVnr
z9JC*HfFuZP2`mb1SsVbHc|lSR-fs)MNZ-_RCJY1r;LF8N({?XJaq+)@Tarxs#mlH)
zFOSw$R8(w7vpj$LY>8j~dI$1~x`syQ_3p<rSK#P=dsWRPrKQNn>jQ~YFTDOx-Tg&h
z(Dm{XH2v0tEoowG?03CWs_{V>7niGTyD;PddW1~D%KhC1oN3*D8Bj}f(QK1sT+_7H
zvXVD;j=g1!g9<7A9XkbtN-Fb1&!a9O#d}ZQ#WYl7l=$yo1nu8kuTykEb<F3Y0tCuE
zc@6f~?y}%9Z=CFP&-8U8C0}H?bF+EV=d%+Y%hN;iP7Ptfnwa758{#sjRN1wdsy(Wi
zaUKivFw+q}t5^^eq0d>FRHlOo(8w_pRFsz&3?wNPH#Ma(hGin6A)5O7kx`OYgBqwI
zUrX}>jr8^P4GmjCjiu?m+RD>#uIcEIAjg_=1v$rSE9Y&sdFS1)u6JBtPA6lzI_wPf
zYRtZjwE5G>DJu`|H?MTqjAjMgoPRlAa16TLGaqzeL44CR^PJHY5fK4K?YO_YVPj)+
zbZ{WzFgiV(GjDdBb3Xn(2!FH){IPya!qIScEbzR($!Rg!fYYeK?)LiZx3tsZ=GYV9
zqXj0Iq>+&F`w0CRk31$a+*AUn!WNumgE1@Oe7~bYMMr9sz!XB5B8xGUdT#r%Q}nNH
z{Pr%D-`$S@Yd=ZjJNwPm2C2sn&h#Mu)yd542op_AyPWilmj0}0@>}?b0TtxZUt+kf
zj8%ih^Jc#pn?h74{e)(%an7vWc8qeNzsac{M{CSbP~}<U^iDA;Z2}3O!sFW4^SqN4
zAd|&Yiu+ENX<<wL<ED_;p9Jn2X7YUB0(f3jMox~C7p)#tS6_e1MklM*b59TQZD?o`
zK?`i93k^7(P|SJpcD65*Ovw4qLZhRZnHfDE1{&(>o6FX%Trxfz)s>Eb`@fNr9=p@!
zEiK*?h4TC%aWTYKJ;=s9oFsL;$_qtVvCyGJAo!8vE)|UxZtJ=`CMJVt*IO+}sAe#<
zg<0C5DKxGvSVNRIxN3;@?8Pz`;obCmYzX`O_$Dq6ff}u5+up!LRe`#+^t#BhsH!68
zz~KctDoVwt!|8H-+LGd8yRPxJhw*8jP!b<ZEhr4}zy9&bdASXQs^iWif}jmV)4k8K
z=Nusc!BZ06-%}cr0@ec84{7w6sW8K-^{~q|zKY>sykRB)>GU@68W;BoCg$tKTwd!T
z`RAs;cMg(LQ>_=hm<edB+Ae<j<@p`7{`}%MH#a8<;t_<jL>?D8)}9Y4=vFwKx}_-G
z*|3ryWs7COrZJ)Y(FI{Hoid0|aCk#E0#61dSVu+}+Jq_c<@U~tmzs_4AUp3>WI>Sd
zMpRDQt<ss9O1S1FPFQkq*&=r#DoY`@Wk48yUWSOi>R6ZPn_p7G<ljd|rZ-|iwZ&$U
zyE)%q3AiwICufQ!lBD}lZxYLCJLk1u7|ZEK&O}GI-uK+Rm}Cg@>*59h2NCjfcjjYb
z?`~NMi+vlr{8;Kan#$;YqyMDDT&1D=-(S)JgY;H9lZ7W{?Oyw$-hW@JtE+o@p5==B
zmF*FlJ_#qfde_UXs)8%TVyKxZFJr~<w5z^+_W`c8he2;Y>A5Km1jei^I1WpYdC!cq
zPoOJFT|c_h<<S`v#vX$DK;p`id%tQwl1+LR^DoOMf|en9g8Ww_p%f|kyI+kw<OOI<
z<~Z2c@MS!9Cd2E@i+Ox!)71+m`hB;B((R^RTr|W@CKEk<G$y?Mbg_vpNl987rO|h?
zTNXvNzEr{A046E8Ts;2?b8WUX4R)~7DM|da1Kcc-4U(}kv*Jn01)_1*+V-l42M0ym
zek+00>C(1S^5URH7OHGo-V%=9!#!B=%En17{+5`}q894{nxV{#YkHy*G=Sb*ixqwN
ztG`(8{g3g7#8Q|Kn`Brjk9%~DvGh{^yf87+s<$?u(N9Hhrd-lrZwpS7k4?0w+@O9;
z^0s_5FLgdJopT@foTq7XS()9p_cU!YDOer$hLcn8J=d8zFcu!{G{xk?Zd}*<5v8T+
z>FJ;_`;O;J(<vs9g94Okn=9flT?SC$`Tk-exd`lV9IlYa!DpIp-#X&iuC}rG#ZQR#
zd}nIF^}`!s)suV#eD#e1x)zK5+tu*rvokZx9#d+Kjg83iAQ>oDE}YK7`*dpZTff4S
zd<zk4%_vq;GSYQ(Iw=hCkmtDZhEpp6b}6hz^C*~IxYSxdU`EvywSP4Bmis)vw}<Gd
z1cZ1}wE0hV>}@vfvxZht;B@OU!((OoWr}r}WLA4KmIQr#a|QIa2NNZ(w}H!{1h=|x
zogc24FA5;00l24`WtY8SN_@|ZaBy@?g@NQE*f(Ng<kuaB0r`70Kn23;fs~UIhrmKv
zdHL1v6b&3#@KRfXq?yRtzP>*Jk68uEFOc_AU<srG4u5}jwH@jh87;(-@Rj-YxqfJ9
zXvlWym~YyjGxOUAn5Z;k3-ls&_4S_574L|7z`?ynjJqOhsmf!k(;yf!p*YZBJi&Z4
z>x{;A2W+dzQfuyqa-K>GVWv5`KMPzsjWi>%C{EuV#6&>>)U0&HrXYe9)|qI^JceVE
z+O+S8K!VlK#qf#VDzW7G9}j|-kC2E+;`Ve3Bv&>L4kwTuL2KZ9{-+#%y|{9xXJ)1j
zEtym0c_M0eV?R{_-i*Wrhn@EwA}^`{c7E{a=^N9Fc%h%vv9jpTB74%TIZWF;MlyIn
z0rcf2uB@(}B`sNxJgTsN#4-9%Pi*uI<>kguDwY4=t{=5lR6+lafZgpb4whS6TW@bJ
z#)gI}Dl7c~NC?Ae{^{!oaO2R>P_EA=3Cl)z_!Hm~D_{IB_Nv<tzP~sOGjNx`!vQve
z$;DDO;8--wQb-lTFe#)^pz=bp3_8<U^Ho!*FeutEf`g}{9{#UsYZ_;1I`$Q+62gS0
za%9$?q`a%<?S5UVM~~;3XTeM8*Jp}_ktxhL(yVf5EM4uETN92Nr_9*3cLX4FA$vit
zpsV3%d?qX^3IE<G++uztaj=o9pT=$|qZ_+mqlKyVb|^zKC=iq#0BON?J8j2u3EA}Q
zo_vI7fwsWc*VoW+K1;xnT5q->VCHyZ7?j58TB`vJd`5P|IypAIcNmYx`Rd9`I}%>O
z#x>d*a=sR=T;B#lTFz#TYg#w6ShPz%02tPwCNJLys(d@Z!!*6$lIXZT|COQX)z%OP
zl~FO~Y#RLZ_v?ccMz!l-@37Oj%qh*ax&a4<S8D~ujVDMxDoj3WGIWAy_0GPY?qL)m
zf1RB}l70SB^ml`#w0-h6hQ(`Yg_$BpGd%@gS65eOXJ;?3^Zt0UAbz_yN9kl2`V??H
z_J&lq2|NfMy-X3FY6w(NyZi@%&VY2l-eRNUT&YGLNCC&k#}Cl4-aGLUhNp2AFb$Gn
z&`eHFUSAwyLxB5XTybz%rCC2jMe&WUCgk5cd)Gys^FZx4Elc68;)?7dqgq8(72;1i
zpjM{xjr_%L;!9W~do08s#-FM_PD)RoL#U*K7M())O|Tw1f)5)F6$1KE<}1ZEC0ez;
zsH}(apu{mzOte&gnt0;@cntRq3&<zwR$>n4-bybg(>eJDlezsL9kL@`QHLfaWlVk(
zNpi0R`IR)cD}Fu{H!3Y5sJTaV8gAOxY;nFEU(JR>Sy{1_G>Q84e)GaC722?~47f_>
zPk3gV>D{fW>Fuj`Q59SxTcy%-KU;GiAk^@B)3g%ITMRGI3k38|zn`VqOhg)XZO@N<
zD0x&nq`*CCBid{`d$1Q=oB-R^&wODEICfMLmA?U^X8maSM5r$oX3Q|6ux#s&>eyGz
zMj9eQ@Lt^(5<xLO{f*MuaaxElZp4!B-mYje6mh0zsFVtk+F*@IEPM!^m_|wD554Y}
zQIX%`e>2s<jYrQb)D};}&_B`?qjOnmu9PeVEitct5TIl0GK)XS*C1=;#}Ei>GW(%=
zZ<iMGKAbk_QG9#K_|^7tK!7QZadn(o*;z(t<hB2Z`>#M9z}=CLp5{M4`dDM9FT1J)
zfjs2I+>Jq7(fWet!%Onak`)D#h65`HL}#_n@}s*lJ3u-y>w*F;*9H*CW0=D;yW+{0
z5kyDXc?G%J*6NcnE}R<^7^eLg@xzbH9n702$8YA;NJklUebXAsRTmIDoAD)Gy!bBH
zihQS~c|uIq*%a|Kvo*c!#1l3Xm1e6^w4fkXy@3hjE>=8n!|c)<LeK~aVuiwvy>%9a
zV0Ha^TC`=?yA=<tU$p=B8hX8g)g{xrzwtuWa|Y7A-L)#{XR-2!zR@Uy*J?LxURVqL
znmN9B4`Xx)*L_=vZ~{)mS8Tr<Kd-g|C;F0A&mu@Ez{?;Q7!lm$dTpfYxLv+Ex79x(
z54igeR%1k&*?plg&jQt?Qocxb#LLSP?kiVXcH@sOL0+$P+>UoueE2{<=Lz6D8y2M|
z6a`9}mzuodTVBto(XaF(^FebaeA0MVs*sa(8q)$A&JvS*r%TCYT{1LcJ2Gpy3C%bX
z5j+taogXjh$Vw?X8&=ajX$XIHW=YJbZ0G!tldu^r<YMmsvjAp{+e;aEP^c6ln~!1u
zA4VMel9UL_@(|V3A~LnIs)AM0J45dUzTE>+yQg1kLyQGS2xGtR-3fM=1VkI=7ks1<
zi-;CHCm?qSnNUz0c+^<R!vGbU7?)P6U$yAI^>cH%&M!HcYURH+S7dL5`n=MxT~=*W
z`Ei&5w5RZAB#*Ori1f>nq<RYJ3~cm_Nq><K?EL6>u%!faj*Q~9uOSa|Nrh0#vipQE
zosOQnBWZ5GmkV+1S=^v{TA%_+s)wGb_*MMwia`(ZBZtqs@wMWfutL|V{(J4ogf*Y1
zxkP<)Te-V`>3<h3EGWVct{ut1iy*TCMv1WKKz|I;#5)r;15Yp@WwT^lt5JM6t5DGw
zn&+|ZFOeEs-TO~rKmT0NSd#DveGjY6MJjb1PM=BN&c#0GlaA)eJsUx8rGQX{**^YV
z43zl|VN38NxAW^h<eF*CmPTL1#HXH-^eCu2I5GWik%4%7C*FIZ+Af2VFc+k_mZIZ4
zQeUitDr8grFS{%jKsXRb+@tLKY-@8RYd3w!1xh(osI3|%3qOt@UZ}7<q-OoqI`-fG
zk~9a=m}wwr-+=Gn0QD5YTCMX6c@~+rEaf<qU`<p6yzG^imoZIPv4cMxQX7ex@0uj>
zpOM~0fY*lzWr|Cil^s*7;izy-6!_m>!X#}QaP5&n`R7jK#XQ$5Y*y6cNp)5O--lAm
zzJ8z{mH2N$!cgduVm3CT6zdZnKE8F$GYb|5r6yD4rrcV2#`xl2jXe4@T~H+1*L)}y
zE|ZHkiabXS86TCm2b9_p#60~PAZgNlmj@<anpA#69{MxcJGp%^{wB0D>p>#;V`?;N
z+R(Q@GhQkq4QFIB=~0h0^?n}DT1_qfVOnxj8KhVSSAVGsDdY4sd}31B?hhkz&|#M9
z-Rh@zMC!5b$45G>jIaN(X%<2>e-&y%Ajw%;wa)+D#ls#kzI^<49!w!t#E5l1p^Qlc
z@>~|`6=ZyT7SU{k$~|SRw8^tH%mkGd$YaH}^CT8aoA|0y7ea7qY5nMxV`-l~Tj!<&
z3r+Ek`&#*Ws^S~7=(9Y`&v#v6ac~>UDMNa}?^9bGcOz6>6o!1chfo%sy4nZ^Ed;F)
z30UoF)irK;3!iIxP3y6osvvrQtTxcF|9urFqWtJA-}rUgoNHu-h2K1d-I_w?F$;o;
zey9oTax;?N>N?N%Uu6GD|Jt(;6i*+~RXfrk#hJ%CLD+-%N~$d*PZxQ?;#3`y+L#c)
zFU$Nj^lDhhz4q#rllqpyN?+B<^F$}XdLO9<Z{CE@(rYBM3)Z*NtjZ^9g~+_YB?zU!
z2&b)PgA~JIP@2l(sow_9f67!0!S=W%>7BImad_~enGvrS6$qUQm?4Cr#k}$?4E+^M
z-!AN)!#&cAU&MWi1BU+hOK!Nq@|uT(iV>nEA3!X^r}L6Uig2o;j9ZDXAw%vYCmg5A
zX-b*avYX@$xc0~eyh!hx5UXDL5M1>0>+6O$!hhPFTO=9)tRzx>p(RgC+g9ypNYsai
zfP4G|I*Pvp3j<50wP8c;tl$aCmsxFMOQM66!)X%f>pZXO#A<jQy9$}KZ^62-MBZ53
zn=C)>^d6cj1bTz**s94KLU#P5dT-J*({FaJ%zV48TAj$ZTF0f5VPz?LYct~@O&!}(
zUi#WA^KGRC30hBkHdi`q_ol>2{EM1L?RDiT))~tLN8!anlT$zn#lVD11CGoJ!`%qq
zNI9(w6h$g9uw&)$;^tP6hP^?q2V(hz?bnGh^XdC#*tjq=qQU6}UiA3*=E)WN@X**;
z=ilxp;_oElefhucgk(^Tzqd^ow#!F1tdB~0q>YC+To)Gg6UTi}ORl)~$5OWKxJ$#|
zc-ZD;HM(=aW|Pxiywjqf?v$8QfQXUUHlEn?jgzY|9HXBjd%XA5S)xvf!8?m~L~|MF
z0%s%cjMt~9cj9lqx<ftK1IEPr8q=&Z6}PYjdp^h{_5aX!AFg}7cz)#%C}@dA+j+ni
z1?B<!+j`h_C86T(ED8mXU`O_ZNC7(E*2YHS?s8q+_Y_Cw^VMc{*Gp~!%uFkOC*>hU
z+2WnD1~<F2$@=l_kaL~|KKn7-YkCgs1p!8n6rAQdh>x(gmg)e>VIZ~OfYe@?y~)TT
zB9DKIJ_FO%`Ond-+%F9N5<jaPV(lF=?yw46(gSmU;vVb1`Xm-w(dko0Y(#f9K{3D+
z{vkEaA~4tuLAn-mDtuiO7eF_lVD3*A|K<9=WnvX=GY>Bp)82p{kA{KnnTm!+(D5LX
z-}xVwuncYs8PMVE?e2oph81+Laz898h654reGW+<uYf}0=Y^b%u_gbL(J{$;e?Y|9
z-H<uAfPU1BnVC6%Ww#}b1fBvDO<0eXa?qNd9oJz*OsfekpLRdtA|N7i*pHrj^aWqE
zx`XJrNOaqQv;_2YK7d*R%<1&1g!V|oru_!@az%$q$wgt#xV?8=R+>Kz8b$Nl!=I=B
zkk=`dye-eq5B6vJLRUgDy`|wok}25MA4%zJclYnA<m%*72c)a=@xshskfJ}7mV5E7
z(Zw5RY2NhYao<8FythuSXp@v29Cm@u0F*v7B)A@QYF^d@T5@u-OkX-d$e+2Im6f~m
z=9`1|M4fT`Ls~od^xaqTCGjl9B8R}hJNwd{*)~tdwzpSTSMu`mT`x8Fa9Cn?WKK;5
zJ;UMsVljcqxreh=i$F+)X=|Saemk&3oO%;zXEzqaVY_T@Y!DI>PB=GO+As4SCJyLL
zwoYg@&`qbyb{2l*?j+fUa4k2#<W@4PH*R(YeV&Gz+KfxcRmV0yciuFuk%7UF&Y++G
zcnLW@$T>I#GKW^ICa<Hcl&u*ZN6={{+&u9@BQZuvth>nvXv_&8qiq894iG*NgD<{k
zpkD_4*oUkvBV%KgRyNW-u9jb+fRX?$HX{ees17@yhV0^=Y<4U8KI`dyE;$XY1n7*?
z&3t!etBgH8CPq#n5X98!>gfr=*o+?~pUnu6OpfdGZsX2_qb^p0?tc%aAVmZ}!6)LX
zrDZFmISqVy(Lx#*%Wqe#(@mRvPHZ^huX{(twJYcU4d=&bwvjJ3f$r}H2nOFjh-e>%
zO}bof+Z+sis9K$uS`;|h9Cu+c-@Eb~*YLd_@4cY60$HBQMQq_>PN7Gx`>a4COnkbQ
zF3}4nZcLANbmgBYcKi*nDj1Nwpt~!sz@yl#EYiiMy}iA1GcD|SpfG{HyUM6Bi`ya;
zD>f<D-g8=7#O_1%QQYTKJYMpW@&zDrfWS^57qN_(Q%x+)o0b3y1Fr&TMx~{tL1$~P
zBDYj;tD&r{?BwLMPU81-DTC><L@n1RxukC%aLs8P#(?~2d{=Oq%%r)~s=9BoV<wW2
zlAHSzTp5c(blcC45qDGyv2#B1CG+hd{=!T<uUeH)zV}7HbDV{`tGLSL=lv_rAUt(>
zGM2F)YKEK@dw$ymk^Ko2PauwS)wlCwfqL57MUJDRGVge-`hRb3a+-biUh9pv%?mgO
zUMpnk90>SO3Q-R`Kptq9s*es2e=IBW20Vep{Xch7Ok`&az5s!CSU1c$JT|t{?6Q)~
zpt9Y(V7epxW4c`X=5*)ePyJY0dU}f5>6JfH#s*=I8Y1QDdW6)q0Trd6l$ItKaD58M
zQo1!jUYYwJ^~J<sLNfSl)qymE<NE7s$Xmc)lDT|FDr{<*ya*uRjfr2F`1pt{V**(U
zh=zrQg;La?Jojch@6KxcE)Ez@g#6B5=Z#&A@QtZv@@||?Y1EXL8#cY32hIQJYpR{?
z)14{6-{yjQ3&<tZuYfBedyIB>IUuQ?Em&1nR@TuG2w36abgsF<s(=6fAqA|1rPijV
zbI|_Z?3v%kL?Lykn~OsiLp?363E-8to7pbahV_qdr>3TCM>3@6hd@fdy&4NDc`}`*
zlJ3nPqp70IpfFXcA-Uf$1<7w|xkNIrYtLD%0r|rT1PQ=KgRc4))%|5;Ci^trw`iUS
zk&V!Jg#cMu6cj;B$%Wj4Rk=ihVg-HkfHNR|0`Y-!u}QW7C*T%PyI7H1quFl{TDOuT
zOx;HX0GTIxP&^Y(iDaUIBsG}KK=Hzhot4#Lu6h|5+n$(0+}8t;VhrgflR$ItiNwxx
z?I+m+JjYV2yX3#WvWRKGaJaj<aen^W4Okc*eSK^)!9PpxV_()2Ui=KY4;XOucofBd
zH~?f$Kr5LC-JaES-jPCh`S_@SBmmIo;m<GaKv@8nrUC&DL{h-Jz_YV&0Ac3^to!-1
z7z2Yf&;!@|<Fi55{+{y!+!ImH-B*TsfKUs=VbiZh3+5XWJE^Syehrq<($fRSTx@o^
zAD6{`Mk(eE0zP5=1K2h`qiV*Bw+Gi}d#Nxm7ofNGJqLu)&(5Ix>+9=3fBv`whspIj
z@VPyk8^z7@dSTfc1*GHj)Kp~_K%i!3XB!(BcrVzO>gwr%30hAe1|t*AUQH(!1mtBT
zTc)4@^piz5H#fk?2mvM3*yW1=7gvo+I%k@7qsxlf<0CNF0PqGNrZ>t<bB9Jpm%sQm
zTN~N}9u4SoK%8r|8o+|;?q1(qvOMd0`8P?Ca%ZJ82nf()TVy<zy+A+$;!}8(kB<*>
zJ#Yd*&^>{GVDxfuaG=L4sA0Fk$yg@t`A`SO9lpk)Ms1A2zsLI&AIg1W>4lyJ0=;Ss
zIP=fXK0w|s&}1fln*0PLGT;cvd<sMg`Y;1P?Ew|_q@se=Ju5wP3qU83$(B0;Zk~g<
z>q4ix^zQ(C=*m+X;O$qp7b{c%coZwA1m54Qpug(^_W0>aj?kgTu>&175RHJ6`9V2_
zabj>JSKN3&Ozmi{hgn?2akf$-;9Bhd-wE=n51*U-1#8xucLoCASL|i0ZYfkuq>Lrv
zxZcqS5_Mi`0pTqqB=mNn!5&%;!rT=MM!<$ZR&fE!+He|2(SuCwN?;m+SKr<v3rOe_
z&X(WFD#-C553oxxYg0g~gwO$r6=-<C5s_my_t!P|Zl-U6IIY&0HQkp28;XmIOHNL%
z|1Rn{S*+Z7JyV0@3KrBskpxf$@WJf|ZF@iw0qMLO1jBcUn?Dmpib#!LL-Mu(?$#GW
zm~P@W2(kyt%l<eLP_BVjj)0?a2mZTkUI}am=~3Ur_2Dv)dz#t5c1hdsA82GFkRx2+
zg)czGUIFn6o>9#f9Q9nz<g*1{cD9jj-tjB+N#Joxo){p5L!^Qwzdr5pw#jEq_?x3i
zwK;f&FCZWQ8$x;T2>Cil#AVgh>dMLmup4wr?_Z$ODf9|B&i-3_-YM*V`N`0vlx^N_
z44+AT<lDE)zdhKp1>=h@o%_Py0i%8!DCwlpm~gT=N|)okgGgs(V*>{l0b<d@SJw|<
zY9fP|9~9sr;0nHHyE6b7P<(m4TL_$eOZYn=fl&Y!MFMCB28Jr*=8{_zpN&+I3E5|0
z9Y8CEj5j*!PieeQoF+`PsZRvaHs`tg+{`=V`xSC}gM)*D-)<a$nA4Ax0jFARdH2_I
zo#zM3i-3c*iJ2Ju3^N?CN)%T}Z*tp!`qC_`y0xXIrbZbU8{gcl+y?@W274`V2ct6l
z@geG$KzBt-+0QwQ<l0R?d)HbU=7@Uo$_5>g=!w<>fn;WSn%$)3eeVqjVfkJlsw~%4
zf@uMoHE<5)x8{LY)^*lTdp?ozdD0iC&*%PH#|XESOO(88aaz1TqPpjK`8C+*WOMmV
z&oeNYBiD<>q?0OKjqHv<D{Nl&TD-fx(f)66Wj?L@bJJ>1q#|t+QZ0rJfncfv;yjRV
z0JDxjAP9)*qbK!BfaJN<;=0`CY1|G7P#_va%fGvcct#e1P4yF46Wl{h>fwgkHUb2g
zkONO3ha&)LF8gta95^|hRAEVO1;vEZv`sZfR6s~*?(m|tq-1t(E+uU{a}!Lzk=Xb$
zHo_`^uQ@F=0COW#Pjv({C+7h`TNW0pV69X6BzD6z&&$87m6eqxOT?zA2r|<-0AdK5
zQeogyTfcvg(-3i)nds<vfN~oE29iJ=8`fI(wR!IC?(MPs{P<Sogak~6e8|g_1j{Tf
zExqI>2CZ>YRB3(mPWIV4$lst{iRf7cLo?fY6xDl8pg_^l(ed%QgG7yvMV{}sA*>z{
z5b#m2>XL7S`%iy@QJ7s%v`O#qRA6ZTxD@qYK$|PjCV}|C0upRAQ*H(r5!2N-6|ntI
zPSXoc;r#iiA36O{S_*W2ZTS}4@4U1&wzl`6aO**D58iebkxT)pKI(D`zzdLJCltaq
zHB)rpsi`aoP?tvAi(aS!HZTC_2;c}ur?$u2l3zYoRK&=HdJr6&$wWN?lz!8q^OHyK
zvH|>Te_I23v(6RmE)CLh6*7;~uF6VwxuwpaPJ47PjK>rP=2o~DH3ep#52Yj>k6ce)
z$s-8tvCF|2(cJ~$+;^r*FZSjRLHTOCyWRs;dj>?B0gF6mX3U>KP7N@2gaj2%F7tJW
z!ou#u3)#YR+BVx53H*Q+sEW!CmK<#oNLql;SI-e;L4cg`P@$Ig`7Gbl2d)%Rc+gY|
zDu@`a&A1p^z(nBRE_8~4tFilkV^p`>ieNrU-OH;9rx5raz{8+8dx8p9AR7t#2=JR3
zrR8|H-dzu$7b6g0v@T4BhV%wGpp%v5J8Nhw{_k%O|KmrfA)3s^k%vIpg`JKx?MqQh
zt+$-Z0_=|`1F*mzQ3J+VXK}IIV~{AZ5d;{o{*(MqlYvfD4T?UW?RS%A=bUw6ARSTi
zSfcepFB>Sc<#F25egmiWATRy&Y5WhFvU~t2+tVriBZh;;MMusfVis-w$;QiAG3vR2
z4eX8}X248=2e~a01p+Xds&Ce6HIOi89%TBKiN>^+eeZg&21pR~Hlx=7XyVj@q7UFk
zq`~aepDC1h$AjkA^D^1XZo?c#1Rw=&?1$li`r0-UY1#b`#fEs(U^bfo<8~?<i(__r
zy12Ad^7tFw{fXqgtU_;HB`Ea3boBsSg7W~FP+%mGH@1~oCKpF4P*GB1gX}W^bOYEK
zY)b@SSdc@6g@k~B8)dfE<_yq}XI?BYABYI9j!RSsvtDLiUd`Jdr5aR_A1$tQh75K~
z7aI7O;ZP{F4d4dQ4Ro#~Mj_!hsI3Pr>j}s~NNelVv@}p9lOCM{y=q&N)rT4|6pMfU
zsvP3)i}3NCC`w-AI=xR$hG}YQYHQa!FN^NKK7~IJKddTWB6iA0WEIBxN(hs%EH<t9
zY~=vSlY{u_r12-9Va<7hkvb2bsFg#e6`-0UC-VTd2J=X5Jvy2W=O+TgZ$@lo3dR8}
z2kMd#C>BvO6Pi|VkmmLQv;)H*03J}MEPyoL(7=BO;d_cN*}?F}ib=g0Z{Y=NIe-_x
z2Xh0?4R=wL8qWX<RFE5D(kdJO)BjQbc6+(~EdcmH04@S}-#3|73&1^cAiIN2HiJEo
z1_8nI4(O2|3kxklS290855U%Ptra??xVV^ljV@8F?$uy2*o0aZKMNSj0W}&-Hs#~4
zcvy{lQy!=QRUe3{=b$?Y0BRxd`%=|R%f)jr;CGKKr2u_$aUBBm06t5`Z>I^ef->v&
z2Ka&vNxyq!>Ndy#g1EChrfa$YB(#xip+lg6UW3F!fEoT>^8Vk*$cTI_k=A4sf1K~1
zU9%nxN7S>qhvIz(Y$Uq1d&92erNzasz(h^w&GMmMrNKmr8d=4;Nuxt5PGLjC^x*|I
zrPw8?E2fPOGXN_O4-FlkoCKYHG*3-W-+RKJXz7r#<qt4xD<BVmC2l&+eKrVLn=^%7
z*FdcVtxO$*N}7q^ej~E~0uUTKZ%oK_P41etC(k0nLdb?w5z(0-lw51`VF5#wsp3<l
z!PYU@FNK7^Hz@GnW&i?8=b43|bK+r#q(wK{a2=S1+TVFp2d)gpm&1pCmJK=2ROo`x
zqD8s9Tu-F(-KN1Dotc|cVbQNP@j08(Z+4i0vYf3(QXzYLewFkr`iTeof{!~_?q`i%
z!2G0R&6jg9*4b!n2pXl%!;TxhY7;;UNe0~kn#2pB5GacZ6uJqp`pd4+KYv~?^dJEv
z=%W&-By$}$o^zR1%7#Z}WMy3gY>hNSF32k2ql{r?RaK@fZ&vX&#0rLGi{bQNr-yn!
zJg>}F-F>9Kd9@e5#B8AWqBv~`;2kgnK+Iza?gO+OXroNI-fI96AjCER(&PbQb$@Yx
zw<3PAbka}eA_f%PYgB-deZlyY<jDvh@RNLsNvAoNnAXYil|yr2^~1o6_W63-6|Y67
zH0yAgf@frc@bvTtUjeqLudinUzWDZFNr@h5MbK|OB@>ME&^mn26wfol!e%oX_VftU
z_P69rz=wKPL2ggM*XLjNgg5b|OHWApPXDNHAQZvl^M*P|3mzcn9YGQSAcXwsBhX6A
zhQAT*KHvRVLqtS`Mas|2z<|)mld!h72G$kIZrnS~z*>>6RD9IC%Z`bO31(|!Vq<Ca
zoYe;_0IEZ>QmLtZTwykgUf>H9WP64Bd5&@RwQYbAKpzOI>&SOi-x<y2xx578Xt@!)
z+yiXoaHh7nag*RjYkI$4gJf)BVPR^z3=p!1dhGW|b#L%g+Y?I=I>4EUgF-y+M~gBp
z)P!vQOd?dkDz2_PIjz;U%4%w0avjNN06JtX)7oOe^<blmyEKceh(2L#>j@gFud>p3
z-%lhz0IEo250hbk1N(&LN5bwU1@!VP($6CuQ8uTlEN9^GpiUvn_v)LBn7%H9u46DA
zppqvMz^q}V?j^{lk!w(P^|^I7!#25f)@u1pugNci#GB1f+tG}tV~yE}R2`gE!)NoA
zyZpw#239oOXZXkXuK%4q^d(w|XxY`)Xb;dxtPQ)U%Dk93>FcXkc;LqyA%b`hOOC@m
z;<agxYRjT4X@#ZRq6z7@PVaj(?(z10#rK``Tm<7Z%~J@rxi2MRA1xhLWLNbUChNWV
z8B$a~uI^Zob&95&T^d}R%%s$ex=B=_q*+g(agC{stHbFt$>Su*4GpGdv{ZE?Z5x#`
zVygX6rt-qSH)pPu?m61&!cIs>5zS{$#R4KWCoMMvrWnUwGgRJFHZ1dJU+l$-+ZVV1
zMT+CYw*7NwXREw_sUOxT6tvlJ9jkb)OiCIuWIqQc6WD=J08RDejSxi~9Qa^oF)R?%
zedm&<@Ag!jN1wLjHk-1q$QHniBHPV}zKq^U+q*J&rlB?PLea}hvvg4{v|8m+8`Vko
z@0;;4k~|a`{6X?J{LlGLgl#nJ=5*AiBC<Yy+>YhdP-wo1F;B_zZ*9fGG8GQWAlaOz
zUo~R>xq1}CR-NBVtfnY#zZc(!zP9#or2Y$~=qT4&?qzDA2%+$H|4FVLp{{6Hj|Iom
zqtvw{ZC`PL4V#((?b_2cQHY)TlKQ8(a##D@%WPXdKHBG<+wT8Pa>1DI+`mwK$*yt#
zg4U&aL9=T$9yPCjFP_AwqaFVX$r3WW*Sq0PVCEfR+3RN(0{#z$VsgM&F<4_RC;k>^
z%JJC~+#8Rnh|$%|CSK~qJ2zt0zRIY6G|gtV`zw{R_MJg8`zrs#v5>V+QoH8gB&VZh
zdL{NJaho=VVLL`*Y2Q<H9UM?5FKzL@Zyejz4_GpqJkTbS$dNoz-4?9*KJ~3f+jZCH
zC%ec*WYm3N&l$y2_lnk98->r?np2+xKTvzn(g!xg3{>9zWoIOjl+q^cS5@12$ix!9
zUQ2iSxmr=Ed9GQWOUx!$_McIbO@dlpfni1I9=)gVcYcda%(Uw_Ky0YX+qC!At5@A-
z6vtp%zB8Y@(@Mc|w}*14jZfeE>7DUk6jAMQv+VcQtFsUXh>y&pZqDqmmzQU4-d_g*
zg^Iw#1|zRIdzZw2vODKZ1L2GH2X8UxbY8xy5PKMs8y2q~kx7xLsx__NZS_1qI`=mB
zTQ(E)kwO-fs_%1I32i1NzLghSf+Tw4UQB05iDFp4dm8@2(IvTYck|aco-7*alNLpB
zr!l|X37wN&VU2$7(mD?Y9ZcLq2$1lAf-dYpQTVr5Rrmt@f?N-MVuXN8U!k*VDf5r_
zNHKBnU1@WGOgLU{16n)yt#)EYjAa9DQ3gD9N~F-7@mq`6J>h+G3`d{>?ux*Fub;8k
zl3Af6g-d!#weY9%-TVKoQ(l=tRE{Ps-ysdIsyZq9X%kmWA1O;--BlRLn$tFczK~lL
zmh|aYhlo%=QVNVv7Q8{6SYUh<3u7|v|4#~~&n9!Ufo8ldFzawczMVI_9*wtO@4w4*
zY^Uk>uRRZ9w0`ajfuOJ>|1Q9PdwfM5*d=po)ngQA(;o*&9H2|Tb{;Vy60Rk43_P+1
zn~t!T7K-4(t3Fv8CpG91N<gm7D#VC573N&N%AF(oPu*UQ$DmOaDxrEpQ+U#!Wi${D
z-eqC56mMTXIW}d*f*7wulE2`S>OzlPQ?fm+X}PAs1X2%uBiV^CxAv-(J}c_n5>jMT
z-swMG-()2W$<{)e7(C3HV|0yML_Sb`(#B&~BJk->fDDM7#EkPx8M#YK#bkU!YfJxa
zT?}ZIo@6o_VKzel**Kf*g+m^TbbYSc4e~L!@>>7tyOO7wQ7c)<4JHq~7dWg7`<bv6
y|KD1U-?CD8+*zI{upxg<c+kENk9GPU{opF$Ue)4b9{3Xr5M_CFxoVl0q5lK;qB~0f

literal 0
HcmV?d00001

diff --git a/doc/android/webapp.png b/doc/android/webapp.png
new file mode 100644
index 0000000000000000000000000000000000000000..edb5c5ccd906fd44372d448ce9455eac226cac84
GIT binary patch
literal 64097
zcmeFZc{tYV`!=emWKKevqf(}dq)ZvgRLBsSNyrcxGLtD;6p73;p+Yi5=7dUSnKNdJ
z3?V~?eLm~^zVGonj=lHs?!DhX-~AlNTD7dl^L#${ecjh}UgvpUpCDCbIZCo4WJE+n
zlnU~)YD7f4hKY!X*-3ZfCyq784e<xDgS3JMDJg0HhzkB6JCTB{l!i<E?0089I=LN@
zg<erN0Wwlw_T=TGWId`Hs<YZY+Gj#3c^>wdgiv$EW<AQMy~S~)E$flcp2rmd56HOL
zFVm1*R{eRep=fLCjLM&PL&Q(grjJO@OS-U>B_$*zl>Hr;ot<TAD==3fAtHL<s?AnL
zxEh_k`;QP2F_O^=5fPoH<FX(kGUAqRB_gU;4NKld^dN;@ikOH<M#^_D5z#|m5=tT>
ziar15UnmXL-$g{Uw#rWG>vlEV^n{Wh;hp*~mK0*B@WBt-NPUx?mHGp?KIb+?x99g-
zUnt#4(x@}Zzr;Ru)rUo;H8L`iWstto{|FI#8g;y>=)*dbpgI#l!Ge?OFYHS7{KMY9
z{as+*lB-whtL5~%M|mar-YdL;{?)JG$0ApG=?i*in`h~W7GiJ(Tne0=X-_%jey@Ab
z2VV~7GI+G3*!!GIVb7j``1p9aP}ZWu1DZY7#qZx=Yz}<+@};7pVgm0Q@`oa(pPMzJ
zLu#-%2Va$zy2{JTdwPn;H9Z%X;`IM9KCYys#K5not);bEV_&Gs{c-E|PbqW9Ek+@Q
z@S{&jIX;>dh>F>hY_DLIyK;2R@7`@5x3~TN{+vZ?@?)m+6B83&vu;iU6HRgYdV0b(
zeai}Lmm7L|d-v?yr>m_kBrH5w>X2#GFU3yNiC1^`yI1aVH2$jGLZ?qhOL%T9jx|VX
z`#yj6tac@x)$wIvZdUuwBiW-=fimG-tRHEDWJ#p5va(v`nnbIcnrucs1iZ)n{rl2=
zclU8{aN53}{{B4Oce#dDUPq1`xqbWg_3PI&Rg$idUJwzP?Jd~H!L^vJMDtOgYSaGD
zZ12S1x5dSSCHK-IBM$}Fxh;-fc5zv&4W!n66<t)c@{p40bxuw{MSWm$T3XtxSFbWM
zifsCYgJi;tY;D<?nXPSXa#B-&Z>-E5JfSQrC#P=Zy|tnxC@8owVrpiVt6xT+x3avf
zS8N@FS9rLZf`WpEMkky1rj&rk+(2o8S<}ys%+O2hF6+O?RV24M%lk$~M*8~t$Qk$}
z)IK+>YG{N!dURS)(Eaxh1!d(YrKP2~jDP-7bZ?xVb1POFs`N~VkH2U~mr&@wdY6SI
zfqICv%z3`++c*6;Mm`@4ddGhy<CT`iDIhT9<8gwH%+u2|Pp_14!PH@CbtY#5Yin+`
zlBT?P@j{ut=l1^CmPv<FJxxu`d~JlcjEtYJukXv3mY$v!;o;$_sV0F+!lzHa$<IF!
zT!*!djg6&MQLFOWN=;3rJ9J3Eu#%TH=t?Ln%aJ3e=!0A0FLd<uL_d4xw|(LI2k)HM
zufKl%sx$C3AfRr(YNy$(;NZc70n#HS_r{(uUwG>{-R{0RS498SBp+YZNAZHq_xbbZ
z%iS><8RMUyof!Y|gC8GHAG~<rDVOWS*Tc+4R#vZGzSPmvyK3`ca%s^oMJ8}=s49v5
zQ6M#2S7&F)VZn*N^HmJNb(1Yg4ZGsb+ZwzvlDdEYPmG{>L}cWz+1bG=Z-MK(I5|1l
z*w`$czt_~&)qVZS%g4vZ&VGrPes#82{pQV5+?jrW#{;+GMuY;w^-E*pV%1pvV{$60
zC&9t}Ro>pKzdApCve;Z(WUD-|;B~Lcxcb2^Gc&X4>FMq5Z7zkMKYzCOrwH0f@NskZ
z<loxo^;BuOP^X_pWpmiRl$Dh=F)`80%gg=G>~t5&V>!Wp{`rTBRZO0bjx3<_<&)`H
z5<c3X6208=at|39;<%<8*RNyg@g|deZ3BbEhB1Y&5_h6XN<;>R2J&w;e2o!2*0p!f
zo;!E${2HwI+nOT7rGSrH>&#Zi#h5q8pXBD&F10_FDxOV6MU|<X@ZNnjS2mMYx5zT`
z`SY%BLvPQK4|{ysvDBMbygY-7_jU2Xe%*P7-rJk&!hVY!Z?s>td99_aa|lTurKEhk
zu&_Y9kBWw5WNuEG<p5P{SC_JqQk<l>gwyv(w~W0cB-}haJDW=_k~^D%3gMNNm1XyT
z{a#wC-QQPNcN+%)tF$!HbdW57OX00HuNdp)$;rtRCr)&m9CSJ)BO~L>jyEq3BFy`J
zq$Mti_h-C)8!l0#AR|*dFrcTRlBesuk$+^@{OUld11Sf#a--m68&!hO()25>yoC$*
z%7%IVxp3ivva<5v;NZP`_W}X}5@J+2$Wv4wJ+s%E*6@8XVLQBiHn8@(rsg5C01_z+
zE2{$S*Y)*RB$DzFuOoIs=guwO_$98ABC%{Y#Oy7sMt<nfp<t~4ty}lXhN`@)-oMw;
z(qfQ2C_=HLsixLf>FIv$T2uXFCf!YTCp$X}YwN4Z%Jm&?tYR*z1_pD(!|XVT9%nhJ
zlob`jk1@_GbJ30{Dti3(UTQjzXyD-BIDGgpDaY;G<A}WIXhyx?TYp!rtgM`zobJ8J
z&dx?4+`fIxOK`ZVb7Xm{jhG`MI{J|_9YUC%{vpFr|IMwf@$qqLHi@e%C2{8F{;i0)
z#nMyXKJ2Wwcq3u|`0?YcpdeN%``~$3*YyB$2BgkYr%p|bk0*%S^HnUe>dw{F&=^1#
z`4B+9kAks!-2Pd3I07O>>w>5#r#~vo{kZ|x&9!^y&!1;viu3&YCo&>pxCs|nwfVbo
zd+RUq!9{+4Wi74ljt)UCE`NiTdt>$2SM<v6=Y)s1x24Gu6BFZ<;oVB%T)0>UJ{=*W
zYNCAY_?VdWnY^k|V#BigHrRbNwf1t?C8VlV{1Y7=U05je(i9iHhn!yI!iAAB9D~%=
zIX+%qdR}cKYisNlR@n}jvfQJ_cTaI~@!!>XZzR_DPBY9bEc<;KPa9P?Cy2Hrh(^W6
zo~khYNkh-4V`^;tG&a`K*!Tbo%hpsIC-d;sln74B=;$aSyRe7Us_XT2Y;2jct&vf3
zL4jaY<F%_-%k9U>wo0Zb?SFha;B#phQ9C*+oo8%eVR7R|7qZ)vcRIz^Hxaj-M~{B_
z@`cNQ3#q%aV0vn*#9^}eR>PChva<f3p5glz+dnNCHu(t`uC2{jDbM}47)SfsH9jFB
zAp`?Aw?*AQhp;Dg6)|&Da_R?__foTl7@Cohks)2-m?!k!%A^%iE^-<2kTAS_IiPk#
zb*%Z?wQFLmp<D_BelL_2E^h9>l3}*d#;^ZA!fW%-pFb!sICf2|Z|%pwcx`RuXy^NG
zUrZA`efm>l<Ey;9%;#d>+XJnwZ@hQ5RgxrZ&P3Oae4@Q7NzyrMfVkl#CnvYO(%hb*
zG`$NSh7#btvvq#EyR$Qb{n0zyA%s(GOpLhqcKnxg(v;=pWhuYCKn47gl58Bn78&X3
z%WI3b%8T*QN1smB`0XR*aBx_1o*(?y*(u*?_wmsIdV2aH&sCOfEftmdPft0qk0>k}
znwl)<EIYHVr<t`Re(&r|&&k<p6sV$LJe^!v7|}51>f&-W`n2)4mzrz0%y2LsK75E@
z#EX)Wvci4!&*EZl;hhc?USlkprR6{5QO};KYiY3wTSsSRnmalQDYv@0xm9ibiOa|U
zWXM3(NmqDgQ0_7^JbX!|6-N`eMnfE+%ErWG6bET^RPDx%E8*!#n}A^P2?^w6WWZWc
zQBi?`fk{bhR9#(Ne^yt!TU!wnj1nGe{`(Jhy}s!%R!`|4R$P4F)bvNS53!P>qKnwz
z!bt52<@gf&aYYY3zkSqCLP9id-0)f)4e;@)!TAlOWGXiOOzYo@_sKnBK8!&9J>H0|
zYYScME3&eAF6OpuaqHGCbMwhv#Cs#6qRemKz7{8Zjhjwwzgr(}`^7a;`yY>FIj#GP
zDR*YZ$8Q@Mp?X@~x>Y-37ZMVJZ1v7{$!wtNxdn}_?fgh>;NQQ0Uu9)ojT6o(E~Y;*
zh4b5lV*c%0q+%=5wYsWmn1u&9d9Y1?@l&poi`JGF78FdvA(nykgT%iY%nE=X7WXI3
z>OSSlPEQxI9V~zI=FLC<kmYN?&dpW!c6R2A4?uWh&6t>&4oJJuRX*GQp8R-4knB+;
z>wIlqI<lL*&x?zNx09_bE!6<uG&SpX>Gv;Xrm<~$Z!fX=(^PanK%U$~LX!UCg|Ok}
z>$sw+>!aTIV$s9AEORNFE8T``hC!2RqmSHHeg@FQirh1~diAP{i;J}MhoFNeC@3fv
z`lhC)aQDZQp3nBbv+Xa&-PrK(@rmCXB{6uFmR38qNH1Uzj{pZAiH+SrJsfjpxV^DF
zT~t&Ad|bT)klsExxIJ9smxj2wU~g(|{o2ouxLJ<p#%sHK_bzyCt|5LsJv@Z1ds>lD
zu_q&x`+Zy6+rKn7vz|735Ev+j3)kjN6m{m8=H})mrEWARwXbVv2)t;gh&@6krKP1E
z`2Jlkgz><UBbGKcd<QtMtN5}5h`fCDssZQ9<Rhtn>r2g7dU|?KSVSkr#{63B^!4?t
z)<(&h2T%l=&fleA7HLH$=H<PrukX3?^IJ(4AfXTOK2~wJ&W;X;fs%W1!Zv5mp6x5S
z$7xW8Ks$G?C@d@tn~p;T6#L|`pxM{xGaBa>{4$iHM!oLZ+rJGBRY5lqckCcZN^Y)!
zzP>o_^#JFUcv0skEtAxUg^NFoYae1me}=`K-z_b#t1Buh>fV|x#d#%!06-MNOPb=&
z%VWXf;`$j3J)XwL13IF%*x@*4USdCe?p)oL31ZaKa|=17>xd*b_am?LwO-Q?%Y44<
zN0^vwtgZJ_9-(7lAt09cgtC>3DcZbut*w99m+JAq%g@hWV%T41edDYY4RU4YWwEF7
z{$=lx7&}#EoR?NtlTI6dh~&{SF)`t~!KYh%RYqnE$MI{`v7qLb7TXX0`#*pF+<9Pn
zW`@%ros-w*VuNkv`f)+QgVdqJMaT|>43*TvCh4^a=yC4cIp?{7AW@6x*x0_0K?l9p
z$D^>uA3uIXew!aCeWvp&H&?>s<0I^bs`=irhS14H7t}v;X;Mif-C8zj^%qwUkdgqo
zULk$Tb@<>xbv->Xi&l0yIl1y2ZQelwZuCGU`~Ca(V1;|y&R?oKi_;6ge@m0Hh~B4Q
zum_R?%IzSI?LH`nrb8IXHtK@w?;rK`^@d*Sd#b1wZ&REa3aT4@^X9akPgWMUnAkY-
znk2s-l?1<*mX?QJ36IwG>r&yS2(fKCYcJ(136oEEEDBH~@tyMFygWSaYYQn)pFRx?
z+$a61x3?Ei8LN@R)W(#OlHxN+DtdpmdS1jWPU#L>*tbAuJUl!e$GjJYYp^s2f@Fc2
z({yG551N?R=CwxU<0Rt}0y6{82?^Qt1vQTUb}0uix3sbvOX;4=GI;mXH`w1=SeJ_y
z$(oF0H-8k*i4&RW>HdaCQ66=5{{j`29Q?lSsQ~0z>AEz5tF*1!DqinH_KJ#({9fVy
zPIsoYNJlIcXXVqUPdMxC?P}p%wg`8m-~pdQq$H@sTN^WZf@jYj<>Z|C`E#NrsR}&^
zu5o^_g2}cS34l*$`R6wtUv?aI00P2mV&b8w1UmE^T3VSeJQ$gn5TwYr*H5yaKi`d$
z%LQ;MgH8-3;^oUzFYh8vp&LLk=#<;N#nL!pXSZ5)ZSUT_-@biYZaK6cpVZabn!L(<
z#=|nmDi>*I-2T{$^TVO%gWf;oib+VYLHRH?Mh47y^(rnQVQcQYs3qT4i83lPI?%(1
zW00Cq7l7-YolyA_9!)_>nGwZ%kCZgU-`^ic5>;{J&#!*OoE+&$qKGiy3_X*Nm!1YX
zBAWOdJ3nO5zTRF+mWvu(w1{^$36Gwh9+#=s6jF|T`}U=%%1h3Fe5_I-|NanbmdC>I
zE(y6i5{AW1w8eM7|D2f-z5OKut*^&}JNMC?#TsU%rnblQT4^(IU9;3fi^5t}jt*$S
z<L$=A#>0nuj~zSabE!3l%@7TzsPi0Ma2-I-a)b}%5ur~#Jt8MhD!6gDjNV@w?>tsS
zwa@udl7#2|UwxOuP37fDw_?|@>uh2!mnxbKkQ!%u1<lRPd3avEe*OBKRafV?Z+r&j
z(T(HbT%~uvU-YP(4VB#H=HsjD5HzfC3)psLl5|-xn)n)nwo*hYluc4XQZnf$KOh;q
zKa%P6p<1TV;ODg09_KmVv9NHQs4fDqh>XnkG6}8^WiwP&y)@sYP<<}%)vGk;iX=&I
zWqtpMh0!{4|FGQLyKxPNn3!}mG=zX0ky_Ev+9T8AKi0SZ&i9MuQWa`@czDRme+uJ}
zp^>hANNHtlot{~@|KM?XTaxz^l+xj*cklAw4MTz;*}E5v#>?z%WR+vbkN=tb?hZ5y
z^nn-xh(t9_`Ny(gv5cmf@A&cKGJ#Y!mX?-URM#~$c)7VnaM+^H+(N!aMjgmePnkZb
zoF%$~b9H@kujcy~TEUZ|V~dnxc~k;g8XCxzN1tZtn$M$=p8H;=WoYQVwXwoCcnX;}
znC28OZ-jv|N-8#Cs^c^YA158zvF1EcngN5gN65-3YwY)AB_t%UnZPf}$7{z9c(aC@
zo0z2L<Rrw#Dz1D$=HTXjgMwLDh|bz`Y2q<n+1V%01s?JKF!uDUySqDrY=gq5yj(0r
z)#A>b-tvdINe_vk`uc~Jt<B9;9G#z)WUv(YJ<pBhJABpnS-1L^8Hw}f84Q=Imw3;d
z^yK#l0k77QBssaXPAfAASW3z<U{TT^7ZamE<6ls)<UHj0&TixbS}Ng5ABB^pMf77!
z>*#7%(TcLAp0^!LKc3Uy+dE=Ke715Od&}R(zT8#fz2gN$?dK=ck|>TOfjU5Y@F1EO
z^v!)Bl#oVWGQV8B-Fs(p<WBO98#ho!v29PEJ>$Gx`7N%_WIu^7NT#zA5?%m)>Y2*o
zj#H|unuoMrR8~reit3seo6|aWhe(YXKkn<(*|TR4f0WV+>B5_bz#C}uqGq!$12h!B
zdp87FT^G!tOHu7`J#OeJM@n+?C3W?Kh9=UaIQ_A4aSRL$9W56{=?4tJ9-*;Ex9zaR
zc|^j)MPB|<UY-B}O1Jd&z0b`B46jO0Pp_;T{QC8(u5R2v?~03$E6{pd4>vBaNgsY_
zt~YY$1ai{E()uzJZ>ip00|NuF01GFWr9buemnA0~b?55u_F+dd2IR@j&2>3c`6~mc
zZq!$89~}b&0k4hKtsPgh<jc)mj;TVyb#-;c*<T|%Bli0tF{$tA^XD^1L0b7sk91_J
ztb2H&Imh}=H{7<e(go#+77Q(3VPPS_3&@sW*;M@f<40LAoC5#&mR;}UF;x7lrZWpB
zk4ph*IlRsUr=*<;bmAw8tr##OLZk}eYs!24X%xakS;gO?<efQF>NG<yJp~>~z@U6#
zanZP-*L!>YglCnFuouIJ>}#MRak{#@yT5%?*o;hl@!}!-BVe7m-U4$#fi<syIo465
zf?h=-U<pvDjr9Rw0eY>46V1ANdLG&OpHNWK)GX4KORC!5uo4i+`|v?JUz?eZPL_|*
z44>PfIPrQy{Y$ZR?^%zvg}lm*Qz)Grj>FZv&Yyn=95gdC<4_75F$oUD@`ieF4I(N0
znD)h>;jl0o4_Ph+e%<1bp8~_2?*V3)r#qqq3<t412<MvxW}h1y)ji{tqWGI)1Shd7
z050?3!Ngqc@!fX^N__H6(Ak?H@uA)wBSopJ#ZIE(I(hPBNebAy$L0<lGxyOm>6hIP
z03^M9Is4TsbO7W5AN>7E{992E!6$@dR@#fiV?nUR=vLpX)2O>&mXiy7_|R)-YZXW0
zsDl0PAD_{8b@rXPRWIhUkX%$69)bL{1^&k+5&VD?F6f0y()L)Wq``Z~{T%+btC9{A
zS2Z=ip+_k!DpFTd!}`)l@1tTCahz%eknsYU${!_)H-S{aM~#eq`SfXFd0EVE_>#T7
zJ+^mqbJJhiIJjFFWB`q{%tMO(q@*QIGdFJDj9CuXjd=QWad}$Z-Tm*EFN$uy&+`wY
z3(4<nZ-E8%-k3fyz`i>7eQ9wK&}(sVQDhrAaA~q7FDt8h>8xn^P%|f~?^fu2n@=Nl
z1PuQ8NMw9`i225Sb;>qL_2R#Oektv|Z$l#R`kKcS$*ZKStgilyOTpu8#_QLcyZGa%
zjtG&iKJ@kTn=V6%N~aat_P3B|p*Cbd<5<6gj_|aIhzm-=TGvms<OoxbJdG268P7=T
z#d*;ZJI!>psZ1>#_zqZ(ZV5~P03eCff=l_3*Izy{F=ksP(5y71c6(2d`nF6q)YXkl
zlaX>rB(X6vmVlK3D1!cwq6*^VQ6}x*jSW=mowc!0TBqR0k3sQJAW@K$b1M8s01kO9
zHQ|o~(l`~9pi3&ZH)e8l--UDaf(Ni2lGq$Sk>H5zD=uC^pv{5hcKZy2l))Y#?~$gU
z#VpcpnLy%-h={-)zq|YW9~zV;x8<n=$~B}M;C8~pedk|*yF{|xoQShsc!?yn^eV5C
zZ2$h=_f9-gG%G7BgdYLlF7}~Qvibhr30(*1QPLCy>#v@CVwL3Q3sY@r;KoBxy@iD6
zhVGrJ_|XMosR?ZuKu+g4<)-P@a)-)WAu}sVu)-Z39oc)qxv&4}w{@_$UpPj_Ea|=N
z;WlsZr+)tUuckL^lxM+g?xSY)h!!Zkm9LF!7CGSbx%)9K%l6zRn42dod{T}cnS3AE
zRMjM2nC^H<f5qXxe0fi(VDW|KZ|`gk5Bp6QMbbWKOktyQl00AGfu8pA<+|Bf>!8x-
zB43-El@%1GactHMID&}y_;S#;i+gSqf<n(j)8v99u@LZ=ekQ~=<BnG}Fa0a<B4E~m
z8kaTsiuZ2yOo!@H+|bY{EGXbPc`_T3g+3I?hlQD0IbH;0MsIl{-}49a)&v~^K;*^^
z`fsX1K|w%D?+ObwR8{Tl?6~>)b6>tpwSA&A)Bi3HEeaCvu|xr}$s<D);Ry-Xk_?V7
z{-7mE$;|9VRtX8AVCKv))$5<gBhb6q>X}}PbqpFR^pZCbtj`8NG&QE5m%nmluS7$J
zEzcQEWs{(Y`lu4W*RSTX>c>NloU_Eqz+q=uJLM`?GmCZz%RAfkxBT7+E-LAQ!|`u^
z&0oKM99nE$EL+-!$mW=sk#Q`v0loKD&!KfT$O4x2b)c+kYikSMzI|~u#>CjTW^ze4
zE`)<KJ{f%9`_vcT8~ge;HrJPs&!dIz&=#SoehYf^+2ht-`t57KeAW8_ir-oHwh!u7
zoEZ>27$l2Zt1nP0%RYGRn1#2ux0tx0rsfJN0$N2jn@7a&qC(0tFZw0)a!wsbE&lHL
zr<)&Leimxn>(^MvHw6U;NlDfwWPV0$I@taA^c1`nA@z3j<cF@9dal)HPDnxVIB3`t
zAyN=g$>;PlDDbc9`JpS17+0LqTFJN18*ALZLdtT%{$p)znpU2Hhr|v-w&4j&t-9)a
zS@Z~T>TVM6(UeEW#8e>9qaL`lCVeP8@v3ZpfV5aj^yjQRrVQ^g-o(!xG4~EJ+7MBE
z8|2ydi?7tGahB?P_wJ<U{4rJwLB+<agI<)E0-e0VtCquK^8V@!cl^FnM6@-QzH~0|
zKXRp&r1Ee$%m0E7`d@`p(x>vBo9=o2D@_|`_cpGb>;FaeeC>Kxmv3C4XGC~E#a+H+
z!J4=JBlE8!v+j4_Nc;PfSNwr;{Tu%Mch9_jR-^V|s>bHwXIkET`o2<EyEtPO(z|mG
zJ1=iSpyg#8g>w6UFUS7Z%lLn!-~Ru<@LyE!aGVO0{AjMvq5220%sVnPB*Aq@!K!f4
z2OsMKTQ@<j%X#ZG)l8p}TXe+mgfUyj4`DxD@~NwDc#V1K$vL>L|H{p|vij|&8&N`t
zu|Dm9i8czDf16)F#j|7DCVYhsOT)so7ik8VM@C26M;=2ucVxT3I6y@7J2Ij6zk30Q
z%+Tu-bof?3g7zN%x98B>k8fRFUbCk>jzE8rynl#j?PE2~K0>@w+<QPxVsMA3kYV}1
zsP;89`_?WENAA7kE=B!cME?KrW-YuM65C-qIw7zk%?x`WeeafGCVZ)XMTKV+gQdB7
zCUjhY&lJ_3@c==}z}od5%{8Gca6hxBh!%pTpR*RiTL1;v*H_w^Zrk;!f*L!`f(v-1
zkK^`b?#?FpYs9mc>A4hyg@mft&aH{n&@=?H(*^;cyNDS88O%y*%Aj9eZD8{*cUd$+
zk_69;-dNv2A)G5)FcAg-P`Azv27MnVm!^{_QG8~)^SZmb=8ypMwYg}W-dhrRSe$Jd
zHOkipODufu90VsfG;Bz#5Ng2amZ4Pphb1Ns0tSLv2IKz&edEuc|GXokppYdckR3LE
z>NFtl3=D+)3j*-{U`|*iy{=ZIL9mDP<~;gwzq7Nmy1F`W85$4N<JIqF&LT$O-a)6I
zP)VHq_A2V}<7)t4sFv;R?PTQS)9!7pt&C?)ANly~ifcl`1k4=)sd_*fu=-Yg2(U;K
z;H_PHcJ?$10=O0eXl$+mK!Jb5Yv$LloQ#YWq(eX(RQg-LwhqNVctB)hV`FG&7|xX>
z?%u`nT^IcJbVsIb@7p~b0CxGe8=vQX4-Tmq2LJwNx?>U*qa;W^oD0T?&&`ghloS-8
zez**%iB2b7y<-9#PrR2xRaMnx<!9uJ7ZZS-Ab)j2cu$@zbzkLYeZB?hX>PEBhlVtr
z0e2u~)x`_W(&rL1`1F*NGcF6m*VC@F-2%V?Uk=m5_V$*0zP7cA$=O@=6xd3)kg~GB
zXzxq(?m{=mCaf)vK`F{Ag029a|LnPQeBdf_bL)={r+xbT*%g=J<Kq($ut)k4`y&pS
zhcqN0rXDw&n}>5@*(L7J_5gt?$DBRJ!C?#rf7h;EE{Bp@qNZ+;2S`J|loKS`y{lOf
zopN*Y96S>@Ay$``63U6b{!0>{OYAhH3(}j6QOD_nUBy_R{M+h3Y8V^&c!D-)&BF@;
zsmjfzpvFrNyt0pk1d*Jt4H9|4L%^o1KnWDv%+wTm0>4UCZaVwY0Z5`7nv|Bt=sR;C
z$a7hOzSu3o{6w3Vo|FWb|Ni~^%bG+Uw0+90;2gmRfHnX!MsN4z$rDJz9qsLwXVz9`
zy1~2DD{%1e%;1u33{E)O+pB45c|)^vbj087H8dhrxeMREP4)IXjX=uD5yyE2Py2*T
zGBGah75YyrD<uK6DB}nt0K2N4?Z05bX{4K*n>%$>R8%0G0`L+9GqA58KfdXmg)d;V
z2&j`TNEWBYEMFT@41xuV1sc~zSUC=i8QK>&2;9J*1;F8AVq)UrEc4xMZD%+L%{KeF
zb55VbkBO|Jc>nm1R`aR3nb5{u31Rf1*?_zaHu}Z2IC=(#z<q2Bd(JyMuj1@N6$F8c
zizR?p4j3eyes-QLUw!c40fT@6yFX|vG`PShzj0g@o*f50iv=12KM9Q#J<w@k;Y6TS
zuvm|1zO=MZlafZCy{&lX&dEV?%@$C_?K41$C$G0O3!XUxU=7d$EWSLBe<?lZ-A_hl
zfB$~{A^2s0^YMe5MV8;7X!TeNOMmL?bL)M3+vT8eT!q(`8!@pTc*2shGBiW(O|j>Y
z5cJhlh$JZJdkMkeud1VSB($Mc2@=7=XMsb0jh4R*r_rc^3_+GytO7Fwflik6j+Iph
ztV2q*JO9Y0f{y0&NAjL__xSx|{~Sd)SIo0#G6FT9KFLG2hk++GRhpOn8Q0AlH~!!t
zp&=8FyB7WfitS?NlV{JK#l<m&Hk3I`J_%Wg8mt7PV=XMo!QrDrOGEPpIvKVZS+B}%
z1uJL;wsxi~Ck`->%Fe+dI5d=+f`X9b&^SpGj2YN!EO`8xTYELB;+nRnGn0^8v0cx@
z!_R^e^kt`!UYp<X_PulKB!V}XL7)=wYqTzSvMKHzq*`!`kWkR95o{D-P3sRyI80C!
zaa1JYY7NoqAQbQ20Zyb{iO6kw4o(wE54!>41AkeI`OuF%IZ9m$K?EE2lnVmn^xRxx
zbhHb?o<4YdY)oclE_?Sqb%N*)?bvJOr>3bX7tZ?Pojnis_ibN3G;oujhsR1#4XKt~
zTwHu39PHbR7svfukz*INPfN?g3sPq?GAoc#;75#G*CDSqAL?X$^yCSZ^rx?1ts#s4
zkh~SU_Wf0Mc2L7x92#3})WExn`@eLwD62-5Ex^=9o>vH$C3SUoXF7bC4+anfBX%)K
z(ELeWo~?<=QE6_J2Y!Ak4o5Vi!^1|F2Y>H)F;cKxEJS|>?X0n-MSz<-THO79T;v6(
zpBip%7p2j9@L#x4`sPg-*JrF&TwL6<9FKPS&ZS_1%7vAcYl@1N`H2bXIM;XYdQG=y
z;G9AS1FMd$CCgJ(QW~=pVW!F~FE5804X*(53_Ki2E~F`_L|@}CET!qSlO*dFB_!jA
z3gHp*+G|@Of(a4c*)9mqfrFW*=H_E0O(yyA@$qnSfk+(xvF+{2bv9PEA?(YWoSI!F
zir5~~6cjRW1VN|u_W47R^MW%BCmoq{F2#92!F!gDOzjk)$WB8;Vr*)vp|77185t0I
zR8n%Ny`6Sz==tmHY^abZ%^HT`@Ac|U@=;w#cGn<E+ax`&bgJ>BcyD~rppcf=)FdPm
z97@z)yddLi5P3Sg2xy2agnwK~Pn?=qnZ2reQ%46`*VlJ9va+_eg^kVQgF;)iW7rdr
zY4E97Sg5LW5GZ_Ubc^kcnJ+1;GgE)vWQGd>3vumQ&U)zl^)0)ND%xFZHQ&(t7*zC`
ztRtGi#J<kTT0^m0AW)-%a~*9R6(66Z&nq8&k&?2DV|k*9DZW{UOF&@$#}5EOm^-j^
zSe^9q!6Atfo~LMoj$e&lK+b!{brL48BuRXs)7FL)EFGwCh?w9y6M{!T?Vk`VEOd#D
z)%l$tpAWjJ!}|AgYAS3;Psr+CKk_X6L&L+v5K4aazw3}&Iu^T(+e>(DZguRup%nnx
z>({VZDEf!R$1_XOfURxN-A{t`fX;xMSU6ULl}HqKH#0Zq^k4XV6CO1XVz^dSZqt12
zwVr9dj?XRBL=xr20<<v1arkq+uu)AoyD2bNQuHT}4s0%j0H`qDn~QQfIyyL&H*X%U
z?BlNxn*MGcl!I%hk%msAHVXOuMQ*MaAk5F7mT<M?ZUl57M}kI$Vl`URfz>T5DH(uO
z<>$9od4^Rm4dlZW5OGo+86Fsn>$=S*W9A{t3le-Z!F8b0pn@9|m^}uueCZO=w_Ody
zC7h7;Pa6>>@=FWs0w_oKj9Lh~4(cAS!P@U}C13W3)NE+t6@SGVw4iC#y?GOXb3Id_
zX{Og0SC0#g;@7|Exq&jejFz2bw@+#51%873hED<rL`lAU`7)Qn#E&1#Gu<kXh<WL$
z8BY(7H%8&x5HgT+@wR22YSI+=DX}%ehJr+=ul4VLpPWp@VS4-aW&OKHpji_*o@)yw
zQdWZEQww#@8{&cRYtZ^}BxvC>^z~5)t<B7?@XfZR1?K0U@v?@DZEI@?IxaHO2{(kK
z2rfFe?=SK%$jQYH6-oUHHx$Nf$cX5-5!l)=3YC_w19uW=s3h<0!=aO-o5APPPtf_Y
z+x=B12MC8zqaR+;_zMnZ?db|g3@%`_Iw8XYL%xHC2P^0~0WuCp*pvWc!M#6b72kkq
z!o_YFz=ObYL74?uQmT9RE|Fzocvux>Q%9$-wN({}Q%frf!kf9d91TfQi@?c~F_5aD
zs=zq4`02{syLa8(HefG&&ZmoGuBN6&BaI~lW<&433`zo*7Z)3A_x+#XU@&ysOG!Je
z4Xs2*5+A_wyOG2-!4=Zr?2T}_0_7EAAuv*tnVhUFyFaq}?%lf$Dm`3bLoNUO#<+Gb
z6*Iwy3#yGrD_4GA5lC%ndK#iB3?icr-;lA?)jJ|0=sb3p8P)6ty#(j#Sg(60YjAKd
z93cm!0lxDK3ToABvP{4lH=E@DnI8(>Id|qvjL5yCaZUWEPL0}$fPTDk<%;c4rMUYa
z-r%~8(O>~bC#PE`CI|`|X}I>Fyuf~1Um%s9b|t^xU+&H{XA0kwf7%(^_uY@%*U{k7
z-qC@t0~&J=qSR$N@*+1v&0F_1pSboH?gC!oR*<vp#C^=1cMD3no)`9Z5}nrT7q@sS
z?}#+}`ZceASa$Xuc=~Xj(ud*}R)@R+oj`XTW@MBfP;S?gmfoHCBRMm36*~xVV)V}a
zw~p1fwbayTSy=S7wR_U!sG-8b_6$)&?B!{Y!}|K)Q&W$|CmfI_sL#Q5@bB2%sMNP3
zvyxEd_o)m^T#4QHcWn*gXbs?VoNZ+roQv14*;E=^xvHCZR2B8L`(>mL^B*3x5%ekU
z)uUDFv$iB+%>Bi>yfbQ%nU7c}FvYK4LH1_!<l7QwKeJEf&xh=F;^jHrCHvS=pJMG@
zCpo*@{ciH!SPBl~3$NJseH;Qa$k`s;0xD*Lq&KT!;HGxu9rZYI3!(=kF_pnGP!aO;
zpZ@caVQX>VMb~?yUtj2&{H8mo`)1F7?#T~V<C#8Wg!D~#h3b>vJhNU)Ok@^59sBvw
z0Z#Z^kkrs`LNEdG3dU@);{JDiN%+;RKSv~^iK;g%0Lu!g41z;JK>=g}1pCnUNMfP~
zEr;8xymvzN166e647>N8UQ0bn)JI<VhV6e?<|D2ah!9PQxn%5WHTX}b{@+~kGR(uo
zK3YeJe(k|+{0~$8>5sc4X#Rck!q#}g<(*z@BBCkjFg<kMDMpWAwPz%A``3N{-@1Ny
zK-tQu2tNHw5zn8)#1UlZLK|H7Rz*4N3}c{^&1vzgigrtHLe=c!YI62C9@l<;`sZrZ
z?QFh||0$jH;#NT~Rz?=yhNPAqE-zndA|i={a2H5P`OuIBnB+5FNyP-f1yWy>Z<2H~
z+{E!{GtdqHR}%pLyD&(Kxk`%gUf@L=B&)9mR>k8z{B0<)uz^noAC(WE{rblwzXX^;
zO^}GF6|FqL75yvqG`a+q(Fd~>L_|$NvZ?3|mFe5FNhoXa39Uy!72*{`doeCqwBP~}
z(Po+FR}#wa=0rqcsm~N>U-W_^`k&2U{O_^@|7(*f|F2gGqb)w(u-K%d2%r?Ltf(Yh
zT*-g6G_9bh_|Kz9><aDG)x$qNKVvJqNaVqsr0)xxV!7SOZiR4g*DwZ=NDYs3DKy7l
zD1c{>BO)v;IV(%v<}Dy6TH$A0(-RZ)M~*1k9Ni;DLn0N%6{Ph1_Q6YXwiPV}yWr_q
z`1NjRv;mT2k})~a^5NqaP?#a~u=}HQ_)Dk29$;VqBcPU6AR7Z6T~A-1TAZn=>98q?
z#oskEe-}ZK!vnqPf*uyon$0K^yqIpG#Q_4|Ug5k!{2+9uK&h2r{pdgHKUnU1%i21G
z&D_jPt&yM+ku;6iAww+O0^@U7^lZscAlpvdh6LNJ_SdE+Fm=Iy+nSs=Y%SGpdfaUw
z=T7>5S(=4~1&DWZ4Z?iqZ?rb*p)h*Mi1P~wWU{V;ruxf6y1mc**r#j54u5)Ak`G9u
zLB#Emrht1xyUp$|d-S@c<*7re;9Ot;g5*qS@*Bu=a&ivQ(Pc4G1wscwBaBxE`a+1X
zc!4-m9CEU;`2}$rSUff<Y3P-ffUd5tq@-j}jth96&nRbrUKm}0Rd&jJ`M`k#P=iRM
zUh5QDq9KOZ0hI*A2gK9_G1s?2LHiZL0j;YXCY5j8cn(_c(xnGQMdv&jn5ibw0z;X1
z-`*?*HY+M}TCz046hY^H5@~J`k!bcu5T^wM1P)vErvm6Aa2i6{;-aGo3eap%zHYI#
z!nJG16waPH^#!PE^r&(0w>1!u4Izg)J>|5oUvGo=959-&7ysH(Mcw~c!(34=%*#6q
z6i1pu$s`QFre3ATI!xQpd7!{xvY;|1<}ejGC1qXG!15c^c-*`jV?_YUnS+DF<B$+s
zN)~<dmoGZ+?y^V-l2TGSIXK9W0_TI-P~xTM^nZb=2ak38n@`9$XFQ+mcf+`bh!h-L
zBk(32+wDWdfo`;Va_N9HOm5h-wOvmR3t7-;N_%;21G6F@E>wX~z>A>5!!!!ppl-kI
zl`Hj_g#ul&I3<U94k;-q506dnoxg_V0{*JFS&*wR#4T0<DdJY-6%}KJ?zF$X-T33j
z_RbRgO~%F}0C^Z3S`05KDFJ`Q0x${cr^IFP=wKsI9ei0Ow;HG{iCDBMalrP$q%DTk
zhbCC}MV<H@AOF*eVn=K>Hr!=x6pSsHHhu&gOguddPEX$ySqd5Uq~e1bK7LdU02y_N
zf#C!fmo<U{%<gik0W_zfo$Xcl=hlXRpz#T|AXbEhg_lni9e$paR0R?@HueZ}SX|uS
z&2@*D0l$9z3Zyt}KR+lQ&V?^~a?lZWPI)eA((J6PuV@ROkL^zKYq|S~m_yd-#M08z
zJp-6T&qzcX;8=PsVAf>BnIUp}_SdgPKhQ1+ruYO*`G9=0GmLAQgs}kMo$76NZ`ego
z86l7P8&ClX;pqAX2M2*nxfH-NA++?sP66+;G&=+P;D43yD2AKr=`kmINDGK@aE#!D
z0{*$QKEy0cpdkEH7^?vLvEkGVm3(B?`_`>7Ekn-$hkcr^;avB|FEBrm)wSt);}fg&
zfQA5tD}ic3-1l1XjG(!|`ic;Yv@oi}el^*gkaqD?=NYxQFs_psN7}J!)ZPAE3g~gF
zt6|bnFAq-g+L*@gEf2$=C*if(gHZhV(O-w)E($uOKwZnH2e4{FJ{Hvg8}CA<ma(z1
zvNBavBLR!^n}fOObh_?FUg(-WY&h*OE5*dfIGhNdh}YjgIZvOq;R_YQO$&PA!9zq~
zHe?*%rS)37W^55B%kLfRFV)mY%6>y;D8)$ASUBkvyYVlPV5q>{!7YOB$fmLbc^Wy?
zUloEhKzUkn@*9v~SUQ*~7hTFbJ2hZyfo^<WNa)`_1vZj<gDUd!J!Q@U(o>+ivG8ak
zG-9wQNSNxFQz8ohIEEL4UiwkXBv|{p+FD|cWw0vn+p_zEg2UJexYy}ONsqNR@QkW*
z>*bqVHa6zSEr(}G{K7@dcv#*7X`lR1AT=$mUsHD$-PM{Dga`QReBZsd8<93OO^*=b
z!opX$F70);hAO_Bn0UW0<_O>8Gm=^uf@G1xkmA#PVMW4Bm)|QoCMI_{Z~Rrgyd*IF
zMjjWa4?PAZ?&UZ1hOEo<i5Hz-g0nU<8iv)umj?C6-pQ$M(gwAoM4g)G&xJq9H+kv5
zt)JrOziVmv;TDVEUP?7p)#|i%;2&UXG@~L`j7N^B*|wo)8xBA=z?zeCz}gOey1W?e
zbW(YT`MoeM*I#|-HuK)SJI~s9Lsd2Ug2M}(-=H7`eSH=w8Zb6>y69SC`&d?<914;x
z5mh;ai8XH=T)kbEs*D^$pe{EbNSOMFPHW}r)$BAUih~t6Y^(Gu_01dAjmsA{`hNT{
zy=loa0=;6b2BTrwIai)ApFA@ikoY>IWt31V!HrX4RA}cfTCTAos0_i62(Rki!-On&
z>DcP%sEJ!XD141b9KS1kc^D7T3St%ZShEW{?MALHK>hOOLL)K9kC~ZZNhUObgz3j}
zVJ@!px<7$D8A&-U`THKz91*b_hO;n$=1Wsk#&M_N^PmBl=EiTEnT-YuyKs25BD(bT
zAG2X_VjlCEhQCq<D`@9kLuyBc`DvxIymz)cf1_(xi9YRfD&}HS=0kNFX~Yg94H>({
zZgagY9+bsO^ve)1Mdx0^#v|%Bj=>wmG3S}koVqXXvY<QRr2NXsQRPnGJ9jKs_r5kL
z=c`vKoY>d$Fq%+lc8Nw7tu#z9kSahb!x1Ta^uXNO*hb+E-sT*}LqlfKvgBhm%okq<
zAWI?FzXNsdPs3`?B<WTDG4cwLL<h;W$1P^C0(ZX!3q>OhMqzCT-Urp2Ep2TFB&**Y
zQHwSFFuLf{<Scjln12{tfGg31f*-a7LL^FpXx`@M*PINMm{gIrO5mlR@jjsdZPs9&
zUZAE(d!63tb@B3<yBjAICyVZ1&WAk^9BgMm?_5`Tz_C`{p3k3AY#)EwhL3!D?x&AR
zvw3WC_TeT}sge_f_SoYKCNaRpEd#)zmZ&9Iz3f-2dQgCm!N`dG@^_v1_m?95XkKPz
zSxB4>-nRYl!7rN5@_5kGr`OA<BOe;9Lv5pE76}{Ng4^hQ-rH*|ulTn1Zh%($(^;X3
zKU^&2M}scGy-qOSZe|aUj$))!4HyP&9fnIbUVq`|YWvV+E1vOg0gBC(=MpT*Nb+hs
zIOpKGLcHwvO2{PL@x@ViQ(WBq`7=!8YiEZsL6KdA{H>BGHnOz7b_xS`7thIQYidUR
zT!G;bzNRm4MZsTLW^oYwyy*<|^rJpHARu8a1<SR0=V?-sO2RKRlmi@>6DrklD=6H`
z7;UM&eDc((`^m*Pop_Znti$OI-xZbCrQKV(^gm5gF>83_oX%U*AQ)D?u0Gaty3nhO
zVJJ+CP)pXwiNU}nE}rmZ8kwxqCU>}C<$?j%M<ny<+TER3P5r|@Zt`tVSonu!W}X;a
z05#Yt!b`}6LnslF&!f#iE;%V(R#YTob%11miYpF@5v&wSlR`K%h`+&~IF*@Kh!+MZ
z{AuEv>b2fwebAlJEh=FaNar_0y^i#n*;nzK7TcQTWr&1Z<bh)Tw)4jB$Op*yGES)o
zWiGR0idPGssZpNPnN6QWd39TUWMCf`tEHd_)THa~%I=T3k%vr8O-+0vB8&n9MOF-6
zHmZBRNPK77<neqVZn5kwV8hYZDku#Xy*y~|BW95z*Yyi6+Au1J$<#~i(dTUw%gV}L
zyfA|XdH=p}Xan-Tb}&m)b#*nUDLBw@+!-0+z+WR2{ro$qJezk$=I4{b!c;+lg^3u+
z|93Bdfk7pBERd`O3DosBNz@x8`3+Tt240=QDXgIws|q^}0bHd1hW|8@QMG>K&o2TT
z@o&Y_A<vtCjW)&%)8r%r8{5!eUvu1f>d9;jF|RL8ie9(?GF$bXmEwu(k3luT^{x<v
z8AY%IF1y!|Bmqs;wY8(4Kfkg^zI3D8c$xn0ukq_Z5^QXtV+3x}(y|W}BN_#~z|La)
zh<#016euCyy%j8|#?Z&lpZB+1s3rBSUV3x}l+;E)7@ZX;{vUe-vGbLl(6C0J?qNEw
z$*js_owjKCwgONKWSoXu5r8I;G;4Zen#?dxUxXVZ<v4aM1GdbS+1`U38qjRR!==Z|
zFu#QOef(2IX}&`t=H<8Y-*7K#jAys)-|sN-wT4>uXd7e)%%hp+<@i^6{@wWdcdP+e
z4tC0mp8g~X31(OT;g0vIsiWb?l(IY%#NCDY_?j9T%#kr&IL>|6zc@X~Lu+hPDfZE1
z5#amY9SFH#hpmO(F>hZI29^Htd%*%%@&_$Vll^`-G&R9UeiWpfnr37=YbsCBisY4*
zn}N+ta?pujFatv3U#OhO&p4`xa3!TiWOOSFi^5_#bb16w<MHDYu*t2juY=2m%wy=W
zxMwRiB_^g9>otaK^7bv5Y|z_KaUg-+F11p=0)Pl2m}&b3>0zGvxj9zs!M}tcTpNn|
z9JAUsgiSLyk3u>IRDuYCk3ytk0F)sw<3++J1Im-=1~9$m0`V8NKAe7d2{zW&#5_0X
zhDxKJK9yoqn>vNBLF<XuiI#76Y%DE18-=?F9Vs*T$wzE1Zf+n?p)i2$0B8L$Ai&8r
zr#drBz57x2$)uedd|utRmxzKs6Tgk<oj87WZ(*r|)wsL{@n_-sKAp(EZ@Zh$!$*eQ
z`p`HwHn#X<RM?7NDIxn>tE4l9f*#YQoaHXv*AG74e7bzgcDp&e$7#u2@#tIP95TkN
zx|_OZH$2>1-&!m^ZX5mK!`~}g|3LWsot${(uJVea49xIh$lT@0J}DX(Q~EsA=d`<9
zVHp!=Q+=nAM^rbS^f}G`^0Y7eAzxEP!DX?K0<-BDES5-VK#N#!^eV~qhlj0%cO~OV
z7ZQcb%Z~muQH}86r3*lihUMdv+)Fy5t0cEthh<=HsDx`3u?O?Xnn&e-I!)lP70L~w
z%{WIhiX*f_Ya$ozJP$okxo%FoJSj?j#6ypzL~(!h<lg_U&*hk+cX4;$S*WEB+2Sj~
zkd_&=1hz8z@8i&A;9f@yl(UCd|Gi^d>SeaKiY#Hzo{f!<fAbllY6$ekjK-5+?~vZl
zo^5YwY3c4}s0<o094`1PT!y=VrMBp~2SI8;Q{?^T3$ON@OW=rcjDNlF?nS&P=aMIi
zPz4f%ntl5MCnOIqabS#I0*x%}FKesSeHiL^;%)Y(Q6E!%$eyDOrzHQKdq&R>mkTI_
z+v|0QtL;FhB#PWief5fG`+g!?84St3*3M4_1ayHf=2-Z;R(zSFyK|vYjW2)iJlKE_
zwYBH1dlv2;bOgwdl_ltS;!;X?p21rFQZ(^MI2Wvw73Jj;(<B(VxQ3^TU|TrW9zOF9
zXyKQFIDyw_15P3qXKro|9o6@Ift!`-kGHKx*;r*B-s{tRJl80?oV2k;_mu0VmewSu
zPkfI13ecGzXY{-K4TKIMKSLFOen%KQ(}Mcq|L|cmL=ucE<D_(!ZG4I3K~I2g2UZ41
zy*aO5)i$z;yA{F!3%hWDzyH6bs1v`E)qqov$(MLMEF|@EuyVph%mR0s)OoFq>_dyY
ziH5kRu@Mr#Zf9S3I4v3xT)>#OLU=iD3ty9YHHI+DO!#4+*Xnm?7cOVCAoy~=?L=tW
zNRBxApi4HO*x(PvoDVV?K;uyS@GD7YZe6jk$oiOU4t)$-0)!oui>Vx0fua6>cQg;A
zDHj|j5Mmv-ba-50o9JW|x@*T8>by8whxVuirh6P1+A3mq1QVPp&G-SHyWk<=jmcYd
zSG4C!0kW{$2c$7NvGnH;_>8j#1h+Ck&)WJr-_5r_@BtnYRT(FKcsI~8F_l^OzQtEE
zOM1mOjw_N3r(&ib{soWOo--#ekF;avftHSrj)ul=ZNWImXyA>Yc{3WPI#5D(X~#~S
z0Pax_v|F9i58C3t`Bv7X3JXEd%D;ZqgU|+JLD38r6uKYoO%z-U`o*SK&Um5*milKV
zEL#xR3BRHoU%i8=JXC$c5DPmyVe$h-B<(1&R7FL_bRBf6UI1knITZaoirJ;!@t!}w
z8p!5_36Ir3fB1QMaaDU(j`HyH8<f}?!@&Q~As)aZYGx6_m0RL*F5MW5(bW~T9TeN-
z>_roEv&yTYvT_@JF!DU6i~c1EhB4y+U6@)DgPGK1WRR;c(wKpv9*}HR>k~}*+5?}7
z(KhWTC!fKQ$3QK_S1j)$wT^&JA($%0ZjPfzQ|lZaVG0=?|AmVe@ic?@CbNC}_NlwF
zi9&k>6ZMda<>%<AJ$fR<)b&I4Ip|0#OzOxmpn=B#Fkf_(PxbI+KYH{i?8v?}7?r&x
zD@*b%s0;)se{WmcBEAr$O@`ug`DHEz)Bv<;*J6dT&07*N1eRh?Da|b`d>?E9`WDDP
z6Luo#4PV1ov3(uRGNa84BU4k12M!Sa{*wl_2M}REBL~^os_<NtE{St#si_!>fCL6%
zObeEop`Goh%3?hC15aZqEOf+x7`6<74x`VV9B%*CysGWkhzQKvpMw(*hA1S4e_jgm
zzkL7R4UNNcR1&;uaQ0=(*xB2M_t-AUuq&L!kvMwvLtS0K#wQp==D|44j*R5HERMpI
z!K+simS~WV>Uh-u?oj15zEbCTR)uhv3!q-mJ!9QL{z(GB;DyICK*3QHwb`a9?xGql
zU>Z%vAjO8KMbJ2!X*>W#O+!PL6a$Asu+#w4VLh&pj*J5|hDAlmkz#5J5si}pKhfCc
z=;Y-2y8|Md&>4&|xB&;cZrOc4DH<r|m@MmgXPX3Y`LD~TQ~4k*t$g?ZKo;vi-#R+}
zVg%f<%FD*ow6ol;X(uBowLL0c!n5zg2NN{9q#Qtr*lLiV_L$BB0ku|*q=A|Ej`Dj*
z5^mTl7=PB*)@Vr1;JE{6SuhRM@cp|!y#Mo;)zt}4wqSn*DITyAQ!{8gpb2915JW2M
z|9H^A0mBwLQW69JB`GP~>8bN|_4N}tc5Az~7&PIDs4{ChqW2qGJp>i_yzbiAd^b@K
zVZK0{^yn(cK^SVF=o7jRG<)bw0bTF}onqS|Xt>9(VRIws4jk}_O=z?F_kjjS{oVe|
z2I&%0E1>8DX~{`R?czXZP>AFMN7Kgox`IYpN(#rti+$g}Z<Wnga*~>ieheyUcH!e!
zggSrf3*2tp+*9Cuu^)Hu8KpoDmfTz*4z80X{m)pa2oFzVP0g<Jui;Ah_6GKKd=2<u
z+;)i!`#sX-tzs8aw7cnES?4)9$B?aSYHHT@%mO#g%)orxiw?4F<_@@CJaGd+5ZH+a
zk3>q%%nbA<T?4ZN7Fxn>ISVJ*>psSMP~#TmjDn3EGtRa8-NoaR4trfo^Uh_4Ig5;A
z8GJYp7*du*(h%lVdwTHXmSCC>H}^W&*(Dp;As8{j2CzP1Un(+)J4Tjcrjj!WT{CCM
zN_mKsGNQ02L5v22x`;^(rf$w-+-MZ|D^Bsf<j&?n4p~YIT9Pvuq(pBEiTYIi=g&bG
z)x@HosOaCmb8H$9e##EV^Q~y4)s%gvgP2yCp{X8_Mj;bpwFNiWxj0(%)@5hg6F3;A
z(5xspJp=G0C0Hz%hH+Mc>qc>y6gy)KI#DfdpCn@vcN5Yyhx2w>#re?r*I<Rdy#Wl)
zihLM(y9x-DFg!3K$c0hAP5ayV+R$9k5#KRbgUy7%Nqg}ivw#y(NerQu{Lj-@dU_b;
zPQl$;Rwjvo6Sy9W#`ff_zjkjuivtMC&_&}wW)NZnewC-J9h*WlwRb%Gi+36ZOB>XS
z%0s=o22JI-yR#znzGP&{UYE6Yye@wrLGhT{&#-?wreDf1$o_Nj`cx{pbT;=#1%~%o
zvM0GpBc=I8g=bb9%9}U4oab#a8z<Ah{teyIaqs#n*z#3p=4L^nYgg<q=4rH>%-3(j
z)`y~t<{noL3=QB9K5Fa!IKV~aosQ$Wy8UPp;6_9I)!yqeKgq`zi3bxzM97{5Te*j*
z+-nQZ-iZ>G^hkto`@mMfv(A)`x!>O1$#r)V<#OSNvOO)6el5EjF)4E(1HLUIBh&_n
z;1@nH8=JXs&X;BZ7`*MZ?y>b?#7J9m@-Q4#)m1EU_?ED+OHH*)%YRdkUqU|KMFbM8
zQ`U4Sn~{+b6S~{*KOt~hZ=0K%k`P(g+S*!JM4z*wKUV<bFRB%Un&Fg>%kdI6$tj{C
z{RVb{z1P*{!(nlaJ$suhnfLWRwiZ{I#qArP^FajZTv_Gf;u1M^`!pkbzBmY#NF(qK
z;~^p7?Zm~z-mB*Y_JNjS6TJ`le+q}It*s5C)5!Xu!MGiqC&Dw$!_wGF8r9U%?cnhi
zStrpkiBH=k>MV9X^X`XCQd9LO!Q1J3+cP;lvd-gD%HY?Mk*xel%T@~^JQ`{3D$zYh
zNB>MV-xjwrLpM>=(~J-?gpN=q5D6W5tosO#gWTLXBzioq#}ULOns~?k)d&4_(#vc}
z?#npKB?-40`rr{gM9KO2*A*19Ppqee`d&%%6!wNQ3(M*2`vHa)xV@AU#qju`MSwtL
zuEmpk0!Id@4wA+-;o%LCB?!>3vs3TAV>YTI#3-z%`4HJ*JY54S3Us!%iu5;cXoy;$
z-4p+L40Lyk+4j&ba|!res*bkmB8Z5>l9IqvQe(Lx-bIFokFvT;_Y=nW6Vp}%XzQ*a
znWEn|b`+lN!P!o9oYm??&V>0HR`Ac_4~ES!DhUvd=XG(PI;B(LcJ3-2p2ESv@UH-J
z&Pufzi6>pm<H4Aq)ITY{o~?!tBO*HCzd*YLcdg=Vv&3#9Ofyb9UUaG~E87IXh6&PI
zn2GAlmB&Z+Y_kymHXg3_!OF%ee*%Zn`UmL%#Px6?Bhe+i6cmEE6sC4PpziKWIebXu
z3t*4jNz_22(~RP-p<}^r`z55ji!%&&6`G)8bC08pf4_a4R9aP)rfx|=ULMUaAv&}6
z!}4c&_bvoHVdt9`QQ5m9G%^<$f_&36Gt;snk*FVdC-fP1<{MrY@Ob>ZPsv(1j??-;
z3Z4~*2a(9gWz7$PQ7(h|=jBVXZ9HqBrKw31@@weX1v5YhCHPaVwiv~Hx6hLLF5n<z
zRBU<Kf6*9m0U8KpFGIPQ{bOAnawIbOwBrVtN62H)=|nGHEHN*{&w*<}!Zv;VO5nBe
z6c3OeQ-8+&@Z=2WkQkT0bt?_KpCIa-6*ZSE<%bzi5Ii7VFpj^2dV!%}bWkE3CpkFU
zaAZ)n+NT{MxlnDv*kxs8gu%s1G&<<rz<a@-=K$~^?#dCz{s;#&Prt0Iv9a;X7qUNU
zW@Zy8+a>P%mABX~I(`B`z^r@Hp+N_X!U(}X1RWZJ<}H*<<Z$kb(I;TJq-GVvtbIHj
z{6IWWQQg2XXt)qL;N0xtI)l#*cRS~c?-Udg!m!05xTQ5U`A(g>==z(hPl<*^Qv-q}
zJUh;*>=>~By}T@R<_uz9(*4hC7<k~F8~&CLspHGnuRmNj?sfLVX3E0SRAqpBM%4nh
z1~($uA>1L#Jm{?EB*`RE2go;AC-|{nzj$$l<sR&rlH%f?n585TC4My}z^ibeVW&8$
zF|z>66l5kb*Wad~9w7rylFrtsPIv5$Rf%SqlCZl5Vh5@D;>8VgD2^BPWn?%{pQbTj
z<z~{1g?5BV7`*K4-T;gMbK`korIBaOoOv1+CW6)w+Jb*Tz=><IpbC#Bc7@dj!|MJP
zbsG<O0qciHLE;4=|ELWX4o-0aJfA8i<|HR)0Ukl)==nkQ1FAZtI*_<?JRa!&&`iNU
z4N3>3AsT^HswCI@EQ*KES;Fw#i9%889z+b-4P1v%NW9>%cW=A>Dn|=l^{d(oYBzFp
z&VgS=zDFOZVQ47H&Rz{Y%5m%x4EMLLUi}In2DpqDteCFYZsa>)Oo$=cIy(G1g``&u
z?8jzim>3wMaN4`NgzvPcqX<DGPN`r{<>lo?)^+)_*A%b~j&Q|m*F0C}5<q|i2b0Gt
z&AK-HejTN9&}bgS5qxdaARG7Z-;V+UQ3)RL@8f|2D|QqFhqO0lF2Iyxbm94PdZ?bz
z$}V}6ubp4p0yn&nvy3he*8AVCZ>Pr=O6uLHw)MKGjnSFm%o%Rg6jXkN%mKV!?)mrr
z+9|RLrc#U=;rX6;X4QjT#9oE`6%1?D8%{=S%Pn$Xj5ppNd??ABXY#>$bcCEP+BO}h
z9|*C!nn-tYhsCq6Zn0w#f*pECXnU7~>9;KOy{K5l-RM|Z?;07gpE^Z0^cb$*?LXb#
zrwOdOf&wf<_6`nz+um<}F(Td)d>S5(p{g`U$9VYWCgHcyx*|D3=!WWtlTJ_>5xm<L
z8D4If%7CzU^wg>MSlOMnDE2cnvwroPqsfBI6~~rut*qa!PUw}XtlRfkt~J^)zNNDM
z;rc~8^X+}Z3epsN{iZXFh#%J&ovxs>PCmm(@gmBXQfRMV&9d4XpL(Oy(FSC~t&9|V
zJCthn9`UO&ay!{`>DKoD!P%RKW7)TFzo*EQ(5N&>iDopBRHO{0S&EV-ktP)>5viy|
zr6iT1B+c_6GNnl=L=!@jsX{12hV?n``}eHh`)+G(?|RqUAJ6vO_npgiUFY|E4EwR~
z`=JC@VX1j5;ouZ+GaBoMD@SH8*rhw+Y+~ZajEn=@_qk?h%Z<&N<VUwQdx3q6dgra}
z-tDeTpQdL29Ds;$^y{-}56jF{=_VPY;FYsyXHnpLNA0ep)qGD-qhm=<_zE?G9@6ES
z+TPTq@shpD)Y2B@Yg$!1-d;Z``j!1Od#3><lcEo*mT?&PIsB;f_4Pqh<}PqUk<1%>
z5vm;t1C<FJU;XYaBACRR!}mZ#gHB%Gz`%6sRJVJ}dkIlz&pvwk^y$Cy4t~((bOt{=
zD$G(af{cG8oyf2!tSE823TS+B@pa%N{0c6?CP@EPTT3+BP6q^|;n)Z}qRR7m?an-S
za4LP}!wqUCL;(%~3Xo#tSa|5%;IR=iuP#Y67%)IGEQEW?BaO2hBlx7ReDe4)*iz%)
zznLfXs+eJTqrAIwl{?wk(0~u@Pkc{tq8K#jS!U)z6SalgaXtxn47rxO(<|@IhYw-L
zkC&B{+{Lg1%q-}YNd1R-0qzUtWn}m3AnK2purM1C1t0)m11wzVoh4N4rr-fXeh~d%
z7vJa2cK-SD*|Vi1!-#_Z-lQEYNJQtu2^&_g-e=uuR}%rorR)~)-TX_|iQE`IK0XTH
zE;!DabNJxFgMooBX@_XNvs6WY5zYygACo3|(>_85htcq*LE!_83f`8EcWX1c9%!Av
zjvj0rSRNpaz-Sv-7!x=uZ-8km_h6G`jdtC##bf(+JVtgrKRTGg01^=>W$&v?aOR*A
z1Ok8Y>=}7;>Xa$fmjMD-!T{j!@HbJ1iC{&fck72YZ^jU_<6fP+dl&W0-%tBrKo41n
zzXTiu%n)_J9GD(lS$rQ&wA}vw7B|nFdHD3HnYHy6-V$(ML1+EqNkJ%OitellC4phW
zMS_KU%-kq#l$J#>6?ow-$Ah44N7C_rqUZieaQak8w{Y1m0sT~7YO3*)C58F<e_@Ig
z%qNio7zg#8U^{!Z&gjvu;ABpr$;sZ^wuve$A|`iSv5x_V7YvFI!owk=_Zsb#MJR+g
zm17rx#R5etwQld;y+<sLEB^U2Fn5r)w)>VXAcl9S8{i1TL<1y!V8h7jm_|CNR>~<*
zECx74z+Daig6>rjXkO}`+27yfz+>Xq&|NT~2aD@6KN3JSH4$^RVrzh`?cg=Iz%IVO
z3ICGylPCM48?v?Z(V(TD_2lVO+BpW!>RMV)0q1{uVSaV*o;$)m{CDHx8t_Pn|1Onr
z&CI^}#7CYPnDBOllMRFO5%FEIPi}?pLr23?p<SWs2YQzj@Y8#VDIj^0>-8v^e_ThQ
zA!VFFjmFt0zrigpxaG{3tRefbs7USVQ0!B;qcvyVL^^%=Esz6I?3^X|pvMq@k?kG%
z5g*UtNxc4Jd_lotrk=-7qi5x-rS90}eSe^fN$^Vd7ely_K)qZ)nxOUTE6dA!_Ubhr
zx`=Avlf;=2w^wZ4s=xU6D_-@(hjF7u<zT+kZ!g_*XDQqmrQhY^K)fi)b6jzgatxI`
z@1ApsOAC?x!jRz$ucu^X9qK2G`h$A}nIikmoB7nC2oN|4oN_!I1OcmRGDKf}7b9A>
zzXP24*vEC#xa|GlXmu2f{;|2jhgj3~ZGBbIBw)J{YUuwGo!?x<g#@gQ4}frr+B<IM
z3MliiP|10a`{}N!A5r0qL~|6Z@o7LPBGg<*o;aN?%mcx2maMOj%=v^nwv2fpoan8~
z(*VvS>WmoCm#Pfv!7)W;6&1ju2|r}u&;x4Y6-Id!tU;MKNK+HyqP)^h(388_Uj9k?
zzDa;`q~q)%$M`C^y<}u5V{;1&90WTqaT5e6Jai^CHJh9_!U<V9fP^RKTio-g^rUu+
z=FE|3WAZ5813b12=bylcj+lE$oIwjd5c-eqoEbadd-G4SHg!h-Nv0qsOo;=Z{9TDi
z!E{Y9ZJ?w8xkpl<>*c$`dUMLq{2_w|WtG=yzn%g<<)(Q%SNu|asPb>$yN9Jj;%|FE
zBdbM=rn{NWIc@ud!y_Tkum}PqaP1*OM(XJJyzMy_6@tdVf$dwzj2%mSF8lFA!$P!*
zCW2v<M<uLoQ3K{(Tx6o~TX)QupEK23Wu6rliqe>}5pbKf3J~x6JQvpN6eVv?RfG&`
zY&TceEOj_=<*Q4V@7U2)AbaBRa<Arw>_?BJV(2}|J9YPXtRqHLa`m2d$Z*`FvGs$?
zRzr2V3PdjdBRufY2Bxq@FkyCvxjEimd%DZJT#2pk^MP-WK!RXTk9UEl0{m20_eMn5
z-GA;~xzbU{djDQlz#jBr{p)F{2AcE3s!MJY@PiBiA|mZ1X3d-_+J#q-X!o)JHDC4;
z-+r{vT-pz7?-JJOLb&70^taHF5OI+X^PeDUs)5<y(zo@UXG;^AuVR8(Q}yC);k&>J
zC>Vg-f759^`&;ngL;9#ui&L<Kk`SWwET&KYerx{H9TrWec1pK3Id0przPCXTgOZO0
z1!9LNU{FL#GisHnoUajI`)6d21H1={MQQ+=H-4!oo508IQ}s9_M3~Ha=%Mhc95!G;
z4lYkr*_k_(!@Z@;E*F1r=9*GXiDWYTda2~0E7JY=>kY3QTjM%dSt@n;4f9~wx@A|p
zE5^BRbnkOfwKDIfLjVY!t=t|B3#Uho)6Zo)QSHP|eCzUk*F~ni?FAZjPIfxOf#=WZ
zhBURb^ibA)`$mC2C!o2pG_ty9JK%}b<Tox=fE64v)MV7xST(`#D6Xo?95qU&dWk+I
zdBn;m%^r2*BwsGokygl%+g1J_E<g{Lzkk*Nh#hS}lEwg*2MVD{Na0y$4H-kS^87ry
z0lAJgbR#NBG=z?h?hOCnm4F%j>fI4+ckYrUWRKrjnS%C<YtljG@wL)Of)O+GdfX7$
zm@xa))FKg^<82e6Al>PD050N6CexC%t1s*^jUGI7sQ2m*q(fx=Wfc|egyIH0+!bfU
zAZR^#awwOjkD`L~3K|A_HQ&>kg1~DUgo{@K{DpbY+~22j%I#xkq0pp;puQgc`B~_1
zo8pe;6fapreaqL>O;x+SXV26bGdjvI0I##TxzYk^nh<s63S?X(T!AZb=^o)aWk-9U
z1hSV=CtLD?hQ-6Di+uY@wQoOXP&bR<Vcn;5u($0bJvDYHJ(QBlb6!2#7B=0q`&)jh
z=CwBbicU<Na6nRB)^}zsJ;-5=^qe_qGJq-&CrDqtKBf>@61K0E5p;SS`15B=u6i?~
zm~%Ph^f<YXD%Xz_e4yLj4i62LY5iS0?Z1JBLelCOJw3>0r<*APm>U43=<4VQf~>r}
zYL6bLCT#EC{9UnC-s^nIMIw^Il~E^OVt?c^OTL{T3d^QWrBe@_dp=@KhW4z;UN}@>
z*Gxyx5F%N7aolwh2_9-h%j(agb#z4kMoMAsCzZ!L!ai0}+IJQcz*W4xy%Ds4@9-Wp
zG&PB+6bjud-(+Qp)EeqleuzUDi}aW7N?BQlAH}Fg|J&oDV;jw*Dw(T+lLj3;xMA&D
ztWl94E6&fQFgk9ziuyUw^du34-jeDBOa0oI>5Do`iG?sxXZzNzh*4p_AM@x{Y)acq
zojGh+2E;Z<8_Af#{^~ZALG2XQU;ysZ7jmvHF}20j)UlOzpC*vthb7-B!)={ChC~IE
zRp?d!)YP09<%oV>WJ_?pmc5r=33Nt&dHC=l?dfh&u*~xz+Ll>UBUXO?+_`Vxpt}1T
zzet~aSvgZ}2o(@nonC-a#An`N<X{w?C7VZ?@J?tRfHE0Y%^*RLc{Meq4KC<<?M!lt
z!cW45GtK>m^LgvTTEtld{tj|-5(1?-j+K-(=t2?u{U|Hj3Y<kuNs}8`sXRI>v6RR@
zW%A_D7?oj1#~Y=fYK7i^NNE|BA8!S<eK554&`^9C$LvZK%@C;Y_(REz4tdP}UA+|L
zdT*y(7}39f@Udgo$O`$${8_W6L#ta2z$lyzd@CW_5rT%<+<cUmr#i+zI?!;!<Jm!!
z8_CIS+%78jCk)X#cfLszoYHNTOxTz;*3_7s3t*C^I=yFAjlKBl?b|I(>zSP~u0YJk
zID_zQnBdz_78O6k3#Mlr7R@8&pFjIveh(e(AZH3KKhEF$;nC0+r>1r6Y2bPuw16T(
z-gu{OH!ec1AN>U&Vs);+>ceMOB7A&|TwJPghh+SC`Sj^u(1H{|k)XejU$w6Fv0b>Z
zj>-o=#ZjX+Qyjsie8=6Kv`D^oP0H%^NqZ~%-q7_rLhwSR0GXV(*S0pjl#+oM1_CXz
zjbDvEr&1G>dCscojFM_?pVJd#MY<V!IE9kG*(!Fuk5^6IyqQ}17LVc7DRI#QCG|gW
z(=Tts;BRW*{8F1A&_*|UkoI|5C@>ovYaFPwU^C%mQ1_~@^sYwJ>%91ks0HR(RZ3Q0
z{H+30t7ZO1=}uB`>V6@4((H~3B`T7=oc@nm^7<{dix!d2;1_$}?myuh#}7c}#=UzO
z6}FyP5XOHEvn-jFJ6EB^yW@^G3HMB*v+4T0&rCfCc7QmQ79MplRnYb&hoWQXoB&Bl
zfZtk=50TC>OS$IJCe^&SN;f|*k7Ll6Fx1QKD(Ej8I;j8M_Sh?w#7ZVtv;@?4vB8N0
zt^^*S-u=UMk1y#EzI|Y0gyaIhww?gjSV26aCZ}Nn){8+_pOk7Eypq@4y0wAH4oZC*
zpX|<&1brT_XpxGnpPG&!U}2FC>wyuVl7P?Mp=;NwKr=r%pA~$7oiW)LRUQ@=5(2KB
zyLRnLd-$-}*&^CB(AWA0WCvOVl!vn{EaVgw@gc~7&B-B`RB1pX9*!K=%<L%<GHPM>
zfZw#<5G*0df~iAmkbY}EUmGVmLqmRDDc{MS3S)d!y|}%=6KCln?%jj-dS;LE>GxFm
zpcWvE8pnEd59mf(@7s3==q5Q07nIbP({%n7B_+}VMHq(JyU7fT69VLk>(pOZj&X|+
zaPQvz2p20%P=K>|aB%ZdSKY$3`W}N<COs0u`oag89gkX<Cr%(H%G{>E*3qeEAV!2F
zVD%W|+|_o@p7fP}kStH0+#i@tLqp`=QVdn^MLpKs%*YNTlH9A>wJRVbKo1<}ed~2J
zET~D;^j-Q<@=&|c%lN(cj3X|^(c|~;7sC7%*vGKm(Ge)p-#Yg3(tf!es;8F+3;=l$
zr?fC$^7wlT7mDt3Z{BnpZYYW}_?`|x+kojYTJ<MiZ|1XSMnV02`!QhJ*xI~}suO6I
z%1M+sUmYR%FtjvQZr{HB`7_X4_U_x4s`MU%c#zK9r%$IcOP)1Ld)P1q)qd4gL*~H~
zr{y5MkegU70u$RP<l(?`#bW~=Z`!yKUC$PLw{P8|6F-rVFy6}NVg%THP|z!;m0!xs
z_a$AhpF0<S;u`P(at)268Z#3T`|Oea@9}h_kctQ>Nj(J)0an~hJZ9*ev@%^(|40fn
z2U73OV7jCzCr8#V8Ii=amb=HT&pfXCMZ_E)Y#ZgKZCm3Ef{@(SI^I~B=_Dl{C&E*)
z4B{KY4FEg{9uz=OM6f-d9SO&sUKB`@f`f92&rYIb<xg}Xk%u7+QZA5g2L1VbZYb4<
zTtGpHqJXiy*4x}%V!PBayBo{*?A>clC6uwHy4aXJu+{tF(j*nHjltE-py}nu<Jtb;
zhj_B6_GpA@Hpx58nmA}U*LM+E5Ag%^ws-H#jGK>jfjBI7dx56-%aI=Qfa+GSzQ9Le
z`x5z{Uf}AbOJMXTU&2Gaapz7<wv&cMW&S+`4}<#k6M}x^<>v!DV39+EX*6gH%_gHH
z!H1JZDKlZ*I1rkU?c1{WRD6iu0H%sFVU07>0OCRAz0{8@=do>@@o!o~cI+@=gh6E<
zOnpLLEdY6;AU%?f9~2-I+%<gvet@9pKU$x6d$6|l1~l)z<wdjg6Px+f^hu2B_`~CO
z(H}f;;GVZ>=W5VOH#d9!ORfy;x0jJO;4?;)2gZy1q|<vakD5Dg-j^yJ#O8aTN76rW
zQo}6I#l>x9EaB$%o6dTv9|cBrwTtvF2?1=<Wy=<%RlWhE+X+<tJaLM8K>$DtpXA*N
zi-z&D!iIYkB%F}Hgd9N-ALHA%;8FO`gzyS5Sg6S$SmZ&Pss3a_z2+LcRHtaqf49|#
zzf7itd+}mA^4xxVIl6){a*LEP-s(3OUS?Jn{n=&eoVboJXVYtD7{V+7dI$6ojEEs-
zW-^PHe5F|d@^c&+hD3=rjXy3n->Fj7Z&(FLKaIe({j2rFapShVzrKu&G5Zw|_cA-D
zy)))-0DU)4q`ge^Y@BOvuQqN3F%P<6`_NfGXAYayo*^xzr*s=F8HPQ06P>+r<JYYT
za8No3S?}JNMQTAj`F{Ui6IbU-*DS#sVh$r^Q@vZ%Z_(B!Oe&(>q=l5@hrsBg5?u}Y
z*g6U{cRnx!=-ZnyES3}d)OME-(|QaULV8lJ3?J#R|L)x_03=RMWh4%aMLgasE1dJM
zyWeRvYW;>^1IFn1m_~EK(tZM5Fj-)dcH5m2Lh#{s54bd=y=wdJ0qrG+Gl!x<04Cz9
zumEGg@ZlYY+aZe<`f-y*dz}YKNfC}+JKolO_I>hvk-&N5#zxHLbL&V25rI=HB!t2w
zuMUDy&|1NV@)1vz&iT2ybv8Hnrs=2fxjLg+QC@Bbk?ZPJ#R(l<Wx785dAw3xR07e&
zG$pKgH-dqVU__dtIpXetERz~OEs1FDDF}5x?x8bWK<qQ0KD|Q$;Ane+RWEZ!MU~6@
z_Ir?+$ncqL?*`QN_2pAB1iUhmOq%{a^{I2EUDgbR*1)aNtD>esLVm^>=W=ts0O?hR
zE%X@yIfua+wdXWD&nehsuHP*6dgB`N@LR95vuyyk=D%V>a>%2gsrG1E$F9@gNHh(N
zO9(QJ-uU8&#c+-cgNv^Vy99Uyd@fR=5yNom{3n<9(}TalD(q{xwV10=UOxCg{cVxm
zsKzzV4)4^kklxj)cW;G3ts5_@!|~Zust~Wsc|SbSF{-D+6MiLhs-KmWL7j^pY#YFr
zp{Y5R$^uRh$j)?g^AtN~j!5QB{Qt~O3JD=f9A$qNw}2)_x(g+Sgn+P#vZLs#r;W{r
z1<!VF>_GQ3W&Jm*SPUnC%pwB1{ZI4j<<!^>_X3-H@-0D&q1tGe)#N6Vsb|fzJsBCf
z!NFnAll#xM{r<`P8%rzRMO5w1X~1@r)j)nkiI$cYP=`;|y>~S(se9}{l3gGmVceV4
zWF$F|(9$zAWdx&lG6jA#cno70X~|I%59>bE&~Pz>r!aMdi^yR4(yo74d$h|0Gw%yE
zcoUEo2E~AxYqjU2p@U_Xlzq$lpTxHrR7XfDD0tw%-0|g!sV_ei7K)Z&SFgUBq@Z{v
zCI-~1Ob~)KPA@p2l{G0Xr_-$VTLycy9eTNnN}}P`iMm5%m39J6quCY3SGs~g^n-^E
za!g9iBk~h@tLAG<OO|gQfE`10v}m@&ZX0)~y`*Gn2N8m;e#4qAT-h9m5g;I-|C!*n
zFJFGVzD)8!ZTq%~rE?=6UAU?w_)tIj`I(~YJOO8*zpJ$eVpb0i=%F$KE_8>&!nRcw
zj3cgkY36EqT}*E0dza(Mk)^!3$HbJDk@p1u4Cp4M(MZwZyn~!CD<8!4@$1)(>({pe
z0@0IED;ICgNlzDNisV{cZjoCp<tR|&p?6E`bKnMZ9<e<;MM{Jxxpr(mw%Q4%>v<uX
z^}d}u&$Y1`xANH`(j{Epd820kHD;`9ZeB)il`_@|vmE{6=}v;qfdixkg#$a7PxKhI
z%93d7KGCUFb?zu-DOdyixkc{#cPL#^QNfcXV~tpNy_oNau7C8%k@y}<3p!yLG_IE6
z2IQa4TlON%;@333^G&Ue)eibk--*Hj$QrN+F7OyCB)c}`#AL7;6iI9X2zZR2;ckgn
z6GAzwQ<WdVfjS?<h9DX~el1f74|-Qn&-N$@99<iRvL<2m^5vV*E>PDp)1W+~iv4}|
za(sLf^Z)<|r9K8nBO|LwpylOqAybwkw1|4o^RMlik1Yn-Y&%FjQI)AmpRsEfB0X0s
zZE+e+%XXYgiReYaVY8dt&#N2YHRITiQJo8P0cwKEmGZK(fHZUrK)!dVFA(*D2dK-o
zo0+j=fRyo%ygM&mzGPe5b|gTk7)wZ-wAF$DwSY)Ds9KyN5k=a!KdeDj@tdxitF~c*
zkn=RP=yOW5IqV8lR#?y04lf#-veaW#!=m2DBc(5vp1ySHJ6)X1=U*}xcc<3b{?igl
z?h6VctOAKBD=X6|n4*5=<ZP7El}_uz+_Y^la?mU2C#FqXj^X*VX|T=xv|E?y^jJ^R
z$K15lf2o={R&DnE|2=Kh>0zne{{OHqT=Bp9VU@tgo)NHy$orU5F*4!1SG%HE^1>WY
zO;J%=C{C--$&T&liok;bI^6^98BYrPzSCr02Zu2(#VKl6RK;oWr}>G@qq-<7XB8A=
z9G)4Q!!+hcadCCgd3qN*7>R>0ZL&zittUN__kvNdIZZ;Kt79)!$JT3kJT_XZmee83
z<Nez{eZS-QQ9JG4<%*AHW?6J8qF3N2IfH*3YV5|Iv?CJW!1CckPw>>0&y;~#)UK@B
zV9ZIwHQH>=&c<ogpZ;zW$BBS<RGzkuxb=ZIb&!=6g!gN=@be&3!cvM+#(Fy8y@EC5
zd>fWDdA=~oP?EaP(kJ0_Y{}n<Zf$Fl{@T=U9@FM{T034J;2(QQu;`p}a1Th$P78pk
zu3Q;jFp*x4T9Y0EG{GXcuDY7lK>>6bY+dNkq1QxDeIW`(0=9_oBhU&0%F&r_a&Z9<
zI%^Fxc?(J!YATK>&;|M)G!sj~-UNXtN`5$fO7wmJo-*b2kH7BH*gK^H{vqp4V6K~8
zxjG&z(o<|SVY;#`%@14(OuU)xfe$DiEP~;@5ditl73Jmo%T6{mEdi{j`XzB#$w?VQ
z(x-s>9rd^EpdWt^P>la(o(6#k*Q-Ms<zK$6K<Wc|iAcwAh6<NdMUH#8masz68u`*M
z9{vikwVFcyyy^QuXrw@JljnagFP9MbO#C1QqZY53urrqJJwsMb?!IezX8|gS$$|yI
z>jqj{rL@y!m(49LJuyrtic>|4Ci@p9g{V=^z`~q9iV(&%L?Tu82l=+|08i#ZH~e-9
zUIZ9~`RHd@Ndkdrv;I-@e`F4{q$DewVQ(RtL5|1eAZwo&$joR9%<{hDUuAEfxzSt9
zLI&R#4zp%;9;h3?YOA$s=gyn3lk)8c%{e+YRs~my@bD|>Hj7iqr%>{MTIQ7SFsWI)
zNWq_=Scvac*Zgp)%G1y}gls*k`izYeXkT^1GQ>h#2zcDCO?8Hl0@6;DZTa(akszF!
z3hMjo_iy&q_&CtM@`pz(%0xDPo^qV|JhUL65q@Heb@QgkNN#B0oo_Da^U2;xMb@`$
zpQj=Rk#_#V@EGf-n|(Ip2FQI*`^mWm<2V)?ie4`GVy|5P%tJjZGUg3zRV6F)hgAaN
zhBMy1%uz*_HbMaZOIfq*6-FEU;Waphv)6o$?C8?x93%wt=?}KoQITe4XS3Ss0Ez={
zl!O3lY?rhFUYgG#b1%8MQqFzo?4O)~i45HxGv%%N+}TN^v%Rrq;K`TL0w?k+<O^^(
zef@<PR2{?p?k|?0Q7(cJ16ArSk~55L-a^)jB0{Vh+zr?5G#FqJA|aK*>IN(GMHO<U
z>pDa!oM(dW>E)Fjx6_vG3*?V}QKyu014!AQxr~B1{(+@DIw#`TG3fvt!haioZw{<`
ztY1dTP79<m*;MuW-<$CJ_nv5V{KQM>umAr3u19D?;tQ?~?I7*@Y$GG4wJs?>7#{H~
zX}1A4g%rMk!)~yQ>FN9GE|)rbmoJKEN4vQihU&9IKs36?HRwyFjO(UMl(}vY#~!?g
zc75Cr)8XOW5C^l(88v=Xl(L%ItUm8H-{Ov6%%cdUy5g7{M)r?n7F3wnTa}KIf^0To
zcsS|<DV-0QXtu4TNux+9{Se5MYxl>pPoIoqb0h?aY{PirHEVDO8D{7#4!z>`Y(7N0
zns#eBPlKPzy~#73XJzH;?r#5JtL`ph4W&TpY2cT~%eQ%WJe=4`MTK6_N#P{x8`f{)
z3-f<#1LKR?Vt)Q27Jmv^g@s9|xt&_Zl~rCg33(Wu89P_%_nG5{+eY3@rrf<Q$s@^5
z>#llwg~v?$2d5d2KJ3`~uCI)%ffpZ%Rv0#?zyw0(nz&Sxf@f3@1<X}fy*xqo;HyWh
z`-aKf-MiK#BtZvxEZC}VKXH37+lBM<0d#4~0J1KGX5pof?b!r;-S~nvW}mXIpF1Z#
zAL`slK`?Uz&hI@HMW&1%<z*{2o=!8ku3Vgk1A76`$K_To>nby=BQAW<+@!`(bWIKu
zm&bMOssUL`ASx*+DQQ{U<fmg|_Edy?jttBT1jgo;INtie#9;@=yTX(f60>E>o?ZeJ
zd8AwUg@uX&GhD*sr=tD_;Yr+UaGtH!)rQWw6;N~L*uX{P9O!ETHrD<5BQ0<b6IhNq
zb7m#BsXC9?7@*m|f4i|dGzg<dcNG{f=#q}XK`?MMS<NioQu9c^y;Ob>8Px<l0YoRt
zppDX*Y5uPaoMVUqex)YUrak8;%!3VgG>gsW7}=2MM&=eS4^D-LcPxEh^)W$aGgl=@
zb<BQm$K`P(&Zh71QK${3d<o*?P403ReX)LXCx$<|x*#7ofwuzmxg5_1ISTAEUR<3f
zFlS%2c5Q*3+sAbOS2BYlB^ergHL6<X1`dAx7=`tKOYpwYUu4%toCYU=;A9gdl2OZ!
zl+QHjA%!T<bW9c)XqJ&6pfFYK+gI@(Q1W@{6W(`u7Y~!Us=4c-BgJfqhU*Fvg9iv0
z8bpGnpFtR+K7QJTR|hkhrhp(-GdHe*R9i&1y#UK+)ME*HXU}T%UJKT`5UUVd10jW~
zaE>H~%ZeRcIavTFhYxqkb3+71X=rSm%B})fW9=_WL@IbFUd$E!N6PsgXUF80X>Oep
zl?*>=_Cxv(489=2Q}=$lO7Xtq?kL@YrIH`#oiA<TwX>vFySV6h44e7@1;#h%U>TX2
z*D%IpO3Mb^{SQhS8yaJ3?sxd}z+mjjz{N4dxz-W$s%f34%v9J7_Cvfm+UC}$U0|Qx
z<6RRI*5<BP-~%J+dUh~=j*-z)2DQD$t~GK7xRAVW-;njuCiPZ4iM;YF8XQ(!mdW$$
zTI<TY)F_B>b{|!cKp3o4bA#Y{VacpG^Q8mlwzPDX=&p0tLd5+i9m(htG;NN-<*t9`
zZ`(HRjnU=;f#X2R<)Oj}qr{~PTC#AVtb3}QbVlfFm5#SzvlRfRw_Kio=GB4I8Qja}
z(nt7?8Y|PE0>Jl<Fp~;?GF*P#vW91+Gk3q?=KabIOo*{E8|&$7>N36fNX>_dQ|zAF
zn;3-|eL0p9o0jn6&(x2yW}lxmiQ8wrZPt4%v~%w`WpfK-fAI?{w<<FDhdiNL#@09?
zg}TO_fa~4XN)%>(u!@dj)v9&^^c6&N14fJ}3?Et0VsYhYnl9Ulq&vD2#&UahFVz<f
zBtfw0^8_D=U7VofGi+^7<mdR7%XwuRf$!64s0hL=*C8O9?{BcvJfPoR(cFQhjj>V{
z1OA}CgJ7*Ryh9WHH?>YqP8Zu!7L~=t$BP^jr`wZS8zkSpl9^butiS8xO-_~HzU{fV
z=>Dc}R3@^%#q+|60(s(7@(%HM#=isO(f8PO&`<Co$#~y2Nm6vygB%CLVfG!EY2dJf
zOjfPZbX(gOp+{+H{qQ$4F!~rESzk1D?!o_X0p>)%&drt5gBN$9etJ-^X0rXKCsbC&
zesH(IcDYpI^6w)@Bu9~>qM?%*8lLiwu}V7sx{_Uzd!!8z!GcI>+S=HBQZBz1t*z<=
z+8(!&!|QCQEJV?VLfNXmi|?>=wfEEe&kBH{_wL{Su#*|4DsCk*SdZ0XR2>(1ppy`F
z=~4%|-MxCJnGRA5EQvponM$smQ}&qg%$$BY?ryR)5=(W8uU|#84twkTje;S+EI!RF
zZTNOg-Q7?vGr2(Cb8N3Wy_kPGAo~grWAWL}Bs)PEwn?lo>MJ+)vYF^&^>ji&!04}U
zPidrM!*X1o{s4^bYcQ@(JL_!)qeU2P&R0;Ih?FsH<LG}Rajc#Dim@opqnr{+w?Tsk
z^R}yIb_{AgYu$uPf~yZaUS>XlL#D29jJOd3-bCyng>6SBOlq<`W#Cp(nxK>xkW_Y;
zWmtQDDbRz`0<LEiRbD-CLmbNQj7bkXsSB!4h{S^5R|4S*lv$h&vdG@H*vd+3#net5
zL8k-rmMjU{w8MI$%!JE9l3n3VtH_wB2o5FTO1+)E$F?n4(+~&&uH$+bEw$xOAbRSr
zV&q;6GkqU4OcSrywH3v4zS#HqN+x{v!j(`qx^VYK(aN^Eic$HTyNI&ls1X?UQFepD
ziQBcf{ES26rn9!K;?b82j_&?S^F5%1R1Wzzsk^4ExCF~3fkiF?Y!Mc5XU59<DS2&_
zLh8}LH1_hMdqEoM43$8#MZ@{jrC@$=upSyRX=!#$2_3!&r05RUk+KHMf^~!#5ChoO
z+nVYIvzGn90fvP!Ipr=-(%B_O2BT`%iE8KD_dGL9IkQ>7AjHgjw{GR2a6t!5ply6s
z>N10+R$1k)TP+%zn%JG3xb>H>qnj0k9$4?gdt_c`dJPktv_@kU;W}WhxYr$_D!_8z
zwhfh@;eJKW0Q*riU`NY$!4GEK>ILzNeOgOf>34&A=(Y=zfcFc7YaGC<_QjygIqWb$
zWAKu<ev6kUb>Z|3irt0&1LHC9FWiYqwg8QU3<$xrBjR>85c{)Qo;6^qA~`}>3gSdI
zqM|1=W-Xc=o6|Vu?k~gd=R=Sl?~Z;=e^vL@<RIlaJ*25O<*-NL&K`<QpJi2rDC9&{
zRZ5w6d8G7JD2JTFSC7u)lYHvs;HliH(}%?EdPgbEBG|hT9J~oF9XsG+bGS4RpTAaA
z$ou!A@nf_A*m#fha_^r1zA}j{EI7_VvgK8e9X)zTqtT|Zcaw`1=kJ}Jn-#;s`#6fk
z*^#tKH()_Q^=A`yEn3&wxXqbcxO&3|rBPOV(6fcwlc!8sNonaBf8)}nHT)kP=pA?Y
ziSU{J#@_`Wl0<}dL-mELrDijrkI|pQgtl>{<70bO>N;TG9zA5$ep4J00S}!%g*t4%
zbu%48@h@C<^wH%q2${XIj{ns!*>M4wJGEoQr(Ge;f@-fFoy2@JCjKJQcHcf(_A~5z
z8=GLet=y%{X8KpU0tT*QPfpnM6??-s5L?c;uWO7xcdmPvF1wO!ktu^8p8?rewoJk?
zvos@YfR>g_^7zxRHi4GbuP57WMer>cF*7nV^XD?aaHFckW`ky2A~Ao$(acmPw=hmV
zb$CRE<N>l6q4;W0bS{n|An<65VEVEKP!FXC*Ab<)tcQBTqpOqeh#evNpo@8)#c$EQ
z*6?3}3eD3Z>Y7y~5`Mvctu~5Y59gq3mo8#&5PwI1{P?tv;7}r!nid2ctth#O+M-m`
z&)Y2*IN${RB3CZSyDjPX@%I$Sh(OF=MxQ_5gZ-yRkFrqw3*QGtD~K!w4{Jk?#*#Xz
zYw7AyjzR?G*<#Pm`#Hg`<u>#2Scu@6SeX{fi*)POev<IoE+*1}7MYu>Zn23r&AwB$
zzj58;g9E(=e=VJu^SD#5EW1@fhomFyZx;{#bSrq$$@~5@eDWDIF<SM{hn@=I;b1%a
zvy0rP>d$Scm&}uHn>qhi`jcC8*N;0C;XXccZb47|n|wC49Zu<(@{4k$PLJD61{Jsc
zk#-;3x~@6iu34#x2DNyBItu$ROU+C}FPY{WXWNEP*jL;B!RPJ`&pw4+87~(Z()=OA
z^ErdHyLaxK)|p=xwkMy?p!$u{M0wA{>pyn;Wd5m0sds+!tzVZv-;(i7R&AdCTPH1a
zf76fL-fF8S7-}WEE^zP30C)#VK0ydH&3X5(YNqTtEvmhDyf?63^nYyAgS$qWe3n^U
zQu1eo+uwnWXS7a62GF9BDCFDE5H&lhy@DF$ukWn<o-#;}Aycx-&V_L<r`cStG*`ZM
zUhv72)4gIGh%?Erf0p|Dbab^xp`gVA5O8kPI?Rn&2~B5l<L=#(wm@$MKOigyBY-II
zMhQIolUtjA{wwfkRI3?&WVhF7#eei0lhAMcuRy{7Pw~fp{qRgWbkc|PJ?gLw^dDzB
z7wzG0YaVH|JLX<fTg$;Ot8{2-+f&mvFwwq^hzQ7}-tkkIq>|a1HJ2Fi+kUPIjr~V4
zGK{KY`vM1tfk)DJNBTeU9PIULjV2HqC$XR$qj`UddLqbT^J?$i+yLO`cV1>CXve5>
zn?qYoWIJ@A(`<WCwEb&VGB}%-mLo`ZqGS8lk%|7giIFg~)cN9et+}Sov_jT*Av~tG
z+e<)(;2~WbWFEW{+d6sy?!oq&Zf3M(G<M!orzT1%wm@iyp8)wece}#v;NZC|qdoYx
zUG2~u_l}|~*!H+TOYKYEHJoX_mMw3oc2>J7D!bi!!+P5L{%WI(Z5Ll<21#`Sg0<P*
zJsBODTNOPSUK#N9F>xdz{iQyNr~&+7CUHn9j}6iPES`H_ROBr_e@4R0!{esMoIA(P
z(j))a-)SBRJ8@#a>tB{MPMPwE*nlih442b-_x*QS^Zz6?i5_2i2jK_3JG})J9^Q2d
zT`<_j0R@*-A`=pWN6T+4_4t1kh-4QQ&g_PpdTCV^Y^h`%LqvH=BK;`oox6lohG}~X
zmFvA$==i&22KMWRnuX<i{nAn88V(#4mI0$n6js<J{9$HHq#HA8)Od_IpQo(41=R@7
zZ+dn!bO$6iw=Y|w<ix&+wr;i_WoPQ0d*dE_ZO$AjRhLe4UI!!uQ;o33x3~(5-PrM(
znyc6h0dsiD(9I@dna(0dL@@X%H2nRW_N`PMm=Y4o9<!&ZsmpM1gvyaS;KlMAph-7y
zG+ndiJ4L+csxkxzDb~)g4*5N{UhLnvdNqg-Vr_k<J4Z@%K#H6s23Y>J?H>jpg@uK1
zitzKn6R=ODCQB@X#ictaGRD19R#H;pbXDw}ZfW`B+h(P<fwU3cBG(tG3}D|vrW#}q
z(B8w^2@v>rUx?uOI$;Iy(JL|i*!oIp)5*t_$P}83_)^kW9t#QKJ3N*j$DxGUFDdF}
zVQpv6-9WDAX>h7|1-?;U0EYIr3os{|8Pq}E1P~VYzAGyW?_QUrqeo^=dM!G7#i~`(
zA|D=ptVj^WMh0*N4k?pbJZSdR@S$OlF@r-}wK&ctH9x=Cm@ZpvIVh0f{%>W;&4-+Z
zOV(G=&2HJa5h9F;{m~a(2v!FMqd1ikFdrkev{3Sx*8o^;o5uRwyW(~!6#1M=GH}AC
zZ}P!5ix+1wFL-(4@tk+uE{kC3U)`FwQ_u;*&EpKp)~#7%vgW1d$I@Jj-~#w3xbG4i
zfYkY@=py;BbjA>#$bM9$5r*5^jq=7e1z`=ke=Pk^!V9Idr{w@xIE3i;BE%#Jw-op!
zg`Xc2R4NpNvL8PRKzKncM2{S-ASl)-IzgR#tj2uy7yu^8lGp)-0v^$kyfX|#Q64d#
zqcOb$!;%9@k>&DE%*|`x!=q=C%TkvlO#WJDVAp^r+C?(#&YjE*+ZmWpV5hCRbzun8
zThcLNz#UVcwtCb}Rgvla1&t^F?(`#omehR-mB$thwAchciCH7JizhAul0m#9wzYy+
zaEq$=rT>mo+6xCDP~qUqg3yEPhHz97H!c~nPnky{A@HdfQ1CV=&~p1j(t_WkB|Dkr
zGUV~x`QuSf%XTEU-{S3UrUpiJT<I`@YKI`o*Zt2@;(E5qGW?*7oAq1P7haz7V%_e7
z3qQd(3cA2JLPFsD!E0hm*!b12HI92jyyN%&vyDX%CYzXm;SqT)f?2H!qQa2EHxYdA
zza=b!5kd}QWj-zyoFLfPh&&lUG7r{*TeYxfMEY7O5D&F>TAB#i4I4&mEx2YsX??n~
z^HAPO7nY1KTGSz7==kx-nAsTTGFq)~Dmp0WUXlW5=G^)73?#q(gPwk>eYsn%i=dJ_
zF#Uf0CLL!{O{IN41hFzb!EwtH60n5uFXk&^qNW!ylA(F#_y-?8EFn-afe2Odw<x7&
zTQQnqkj;eRf8_fV4{zofp|4`1^cwA*0HmM){yi5=;?*ed`jPZl>FKMnO8SQzRRsZw
zx^F-Imd^@LeFq$`FkFGe*fVbKH!y5in<kSd7jFZwfA-Y0i<B<iGYZ83(`X4nTB&dE
zzI~ywe_;UsaNZz_?JcV*8j0Gp71hqe4keBE#geG8w>;oSvzZB+14McE$rm^x!DCyq
zX6R^Bm-7SJU?dn7?qdK9B(^8kt;CcDzh@_X$v<55zIS2Ar+x1(WN{@K5HTi-7)QGS
z0-YT-5%IICSwt8J=OMH@d>0%F+|eKUr43AB-ZAIk;6a0;GMJ}I3j9ZU51@MrQ;wUH
z$+8vPE1K<M`?&W~n{3cQiin)8W2>k2ND=u7&yy!}3MovhFv_<%3$GzD?=fW%9?R{#
zQ~_JLkpbO@JHsJ4CT>ro!p~CO(II#CDJpD9A!}h0Pzqsydab&O2aim`FX$%Kh9GQH
zXYryzpYj3y`bAy5xW8#0H-jcS%Ro{92ZN!S-LswA-K?A*#>#N3&DY|haJf%kSJgm{
zlk5Z~Q6i+R9m&FwiY1h6tv|yjdKuh)B?wMOKbh>?yZ0IMcbJLG%DVp80&^?V)jslc
zRpGfUl?4`opP6!f-e7t9i#E_P+VB&KYE4u=6bzIDRS?BFSDa(0O`eY*bq${>Bc=kc
z)y8`-UtWuNA=8dboKHjt)c}>kWy1;Gv8LwRE@AA-g`Y&|hJyPqKdBLl9RqKfD&4F#
z<Cr?-c9Sy3t^<UD^vb1U1j$(Aip?$bve>abOG#PE{BlCJyoKrD-of_+6nc%dG&WYp
z3i0`KYO)0sgkS$`FoHA%pOI?{bwq2(kc$}F4Ids3_2kT%;LuP#GDOw*Z~9A9gzBmZ
zefvWITD(}{9$Lih^{5Ib(^EoRvHbd{ojOBe5fd(=*aN>}$kab`Onh7F0Q1EAb9d@#
zK(BW0|Dexgl~ahqLvPo#jlvCz4sEo27<OQQXOR=Ov!ZDueJcYUBL0r>ul5I%)`*+0
zlKbyZ%g)}2*e>^bmx<b4q;7zQ^y+mI2oRhW77524jzL1bR5~gTKG*{SErKAhb2NIq
zB5$Z_*+$r_Ko;}naS^xW4OR`*95$@^*B7&+51*dW{eP;E2uPxa@^t&=xhCW2!|B19
zQI*B)F&VdBbLJ`5o28Sz*vX<_H%d=08SI3oIArKhAf@E<uQzCL9x$BB&2=R{kWWeX
zxfW|%ja0CBZ32a4iX-Ry9^vMRHZ%__D0Q<2$m%Ib55RmrFC9~oezN*LheASH;(K)q
zH0>pFeN8w#Jrzu?t>41ar`iyg;*5U#q&TQ-uuI&>_wUcwdGAb%WTrRSTkS}CU46Zh
zoZL1h)^yNG4l@d?a3Q%09s9?R+^npHc&dp!6chx?%0_*h-DGy9_Rv{sM6@tV%Qn%I
z5tBH>PRV7*wHO-wmb3_lxCBJwa%d4V{epta|0<Hu2>?r>1PL;ijOdp>XphOrS<D3F
z1suRzIc41Jgaj|XmK>+sG*;NkDhGv<a|u`otr^o@z0!7oVeWHe65F@a9xxo<Bvn<b
zHEvu_;rhD#v4j_z&!AWExy-k3A8)o+dNTUu$II~onXQD$XMe#6s*O-hUvO=FBGm#k
zuK?*9P`c_??9y1v(inAGJ4>bG=r)%@L7Np@@Jvx<LPtT6^Wnq3Km8@$`TnUwqhihV
zFT8;kajUy?H<y_g62dHkrbtNa<e^tQ7-+UCsH;^r?GY_q_M&dYoA{CA`WK!bGG`t>
zEEIYGNwek0812zW=RH}mVC<kqI&rLv6sYFuGiNpdLFTUh*R<sB&6~d75H>{zwz`UQ
zAp91=WYU5@?X_0TNo3+hoP$9*#bKOA?aHhuW3Cl`bz5so0%Kwv+)Ir(E0ovxep;dq
z$juc5Fbq1ON$!=s;|JFM(98N_?4@)I3Doi%=pE;@qVYg0$l+moe2UycA%*ILVdBm|
zlhvlemb)0B+D>Z2szFK00)_skvPJM5n4kj9o7%cLemndXTg<P=wpABPG$ePqQvF3n
z99SPa#w2x0X0L`9Iqr77?aBKLH^kjmP+*}vNeCQ6$g~CwHg~07zjFut_4lt|T=jE@
z4rNh&JB`kJm#F*9Uw6e5&O|jnK%%*Gx~1xJJ}~74U(Y~UvG4?%;z*Ewe}3|<#;6s{
z<6j~eo;BJ-hf=pgD9&UZ#8N*Z@7=p&QMv&p!t?ppQA0u~J{iVj^;ccp?VC59(Z&Y`
z_F<Q6U|`2#amyd?=exjV`NZ+#Xb1SVkT0g`%PT^Kg%XEF3^eH@>7WJ81KpqUxxg4L
zVsq%-8&+a`!hq+5f!mM=y37p#a#=4@SCCk3*H0F64}AhHtsx{_-m#0{U4MJrMRXYB
z6jHKMGpiYH1+PKgHQRN;+ngN8CtC^sRO}d{@i9?A47n5?J!<3UNB^3k5Y#EvDCrno
zF+;Rx(hXIV3X|;>FtMo25WQTFjz<Ug5dic3`#2{5pj;p)gh8ikgrK8GtwiDOw->*L
zPDMhq)AZA9&p$QIM0ybsqVz?eU=V)w^l1^>)4E9$1mz5Gda<7>EW8Q;$5h|!Li445
zvhDnSZC2WS|JR>CLClX>1qR!afkoVxc>THON4~qVDE8br<ij3co^%An0w~Q0AAfKB
zZ~d;s7-8*JDh0&mCr;$C5Hd)!QqI@K-F*XYqJe?yR<B+*GK_g?*&JI2vLi=|=8__9
zq*EuDD+^h!An$^ejOfBbYNES?K>A-UEMK=pRiKs>_chYUqDf(w805@B<Aw~`AN#e^
zr&c@^G16OIqD9dxbJHn<A#D;|3?+Y@&-<g3akcc71ZWrcm4*SNofrl6lS+MVw0?um
zy1d(>@NVEhQ3L+y(MtGseDyth_N1wEH3&D2=AE>()I)drz-5dav*s9P_t+LW2Sr9A
zUVt8GjSQbJl<t8YBn2;4j)bJeZD&!O=)^`T_#I-<#|y^Fk0?v=NDhH2gxfnshp4m+
zA1-B#TMJgI?G*EMWnWGI6@aoU&E2Yf?WlG|Mm!33CbtZJGLh#-pIBXAUpmRR^5kxR
ze->e&QoQSb(7Na_i55+WnW<^()8DN!p3@!wOjR3wP8(ctfTrf3H|ooid*sT6;N?K~
z$C%$arN}#t{|jlX)~4PH;3QsO$4fL>KX>+Qipq(`@s@uTAuch(B@&(eM^4Fspq**f
zjxK=uJg-e{yL;cakA6LoX#S{?;%D-(<Nj$<O4U;?_?+Lm^RrjiJJ!FF)-2kv=*}Hy
z?-=I`cl%!1fA4qqJ#QCf%NOq7-|d0WzWrD86k)pgmL1*-=LUxkI)5oClFzi#(Os)o
z&C8WrZf-8i0^Q|`mseG_J^AzZYKo8P{NHn<RSM5A<l?PBP+VpfJCj-~68&M{zDumE
zzW(?jg4M6JeUo(QtQfCs#JmhMsiZZ>{JgTxt3DX|uGVuwMWbf9R?4Dr`c*AQ=7vmk
zT5BBbTz&OHN@0jclEsFW;}3qz%l3@Wm?Epb^P!LF|Hl80SWWP%tGK-(p?{ShMT)m~
z8$d(I5?46iuvMt5^=u+h=78RMJpNSwhDvuxTtztzKb{PKG{5g!qNY$549pFz=lX84
z<;<BALCGCf^)=pLx@1Wq?NyzlQkEk#!;%usQ(;e*$S^Q(v9LXe^CBkI-NhGZ)?8+R
zWm3)tpMrR|p~#Do_*K=fY3&mn5(1Zcq~ojJ29h3f^nUUCRunEE+~j`L+}&K4GYf>K
zDQ9<dz4To+{#*++T2<ny;uR$ke&k4Pn$jfHmak5X`A%x0TEcQAI)I@S4wtcWFUYE6
zrReIrkB$QPWPY=^sVqBGbE&K$o{BM!c|f`5vgsBU{2aXoAj5OEA4)6q5XVCwW6sru
z5{pFw66;mw?CUTmCN>t>yMccZfxi>Oey16uRbP??+DS^f)s9B#52(Z`w{ET;7bF(h
z5R*i@(B=}$f4>dh*VB!Qfg-5BaYtp2aWQ|Q*Ky2HMIk*SDDVL2hqDWp4c-`%KpVz>
zB5^FRpctYMJze>`Yelr&VpEz>R8%yHStCpy28Xot^fCBaoefCBTbcZ(JlS{GE;!{-
zq^y?55~cYr5H7r1=L|a=xC5zMU!A2X=<d-X%qv_r=h7SKTOtWrG}vjXxI_ec{n!1+
zdral8{p})%bbL1HVj(Cj#GSM>()-oM0=ic}g`OjcCD7Kst96Me1+pCP@cbynv}f&0
zJ%=sNBMsc9d8<GNrdeoOa82w`B-^zsvs^%^JUi+#JaSP4CP3|#<5-GM<oV{__4yl;
zy_(8nW4=e%K31`pVnbu*^lgx?TB7SIxiFKMHL-CejWy{%OM9Gq<>HS&hUCKfbL}#j
zSzB&q=B(4RS<iHla*zV@Tc6EVH<WavYHMm}c(6s=1D}nq40obUJf@fcU4>gDWe`Lm
z1v`ClYq_=O{LrkdEPfMW<QZWjW8fX}Jc{DoF74QfCxtjpdHOUKE!1c)SGk#?2$`<&
zuQ65t&&7n~MCI}ddS+<ZRzpH4GJe(6*rLo09Jg-@N1aH2YVTfI0k<9+Os^xFGYm+{
z#uM(?{-h@1JEXK5k40<Hmvgfsmn`r9lZ-VHc0Wl5IED$2ExS(Fi}E5WmY*<b)3qWY
z9}P#??dw%OsOx@say)ErzM;AZ&;%TnpT2svo~bP*6opF?P_tdYnm)1r;Q~y7btyNF
zz2L<5)n|ix>5X8zB|Kq{h5?8mtDu1I@SgB+yK=9P<45YzI-*C|xMd5d&30_CI1CIF
z?MiILRr9#^BDtIZA8XHKU0%_<wNXYe*z&_%_VhdtcG%3>eTbKR-3=zAIC6?TXLacf
zua^BXX_{=<c=z=fM+2wOYalYFQK$u-=)8Ty+si%GMU`S*W<$f)K-1_B){~!+p8%}O
zE_5<5Qxzbpk`8(cC-gQX@hq{u&U(YwNiBkghD#XAwk4E#)ElprFxo9t4Kz(|6Fu05
zy})-&Dx&ROcF)c6%+7EOMsFGP<+<UjraP~PQ)*T4je(`%SUbm~>io!wk0zFJ+*xnM
zfc(JBOW8oO)ZDuYrSjwZF=<0Naz>A4eCT^kuMjxqxbk)t;$6!}axZ`aMN-I;)>F%R
zgjtSdw=CQHAX*>*N5RZyrBu9vN1*(V9Jg6BO$WCNXJCFLt{{Qo-^2~$rlzKds_TAV
zu)YMF<+r$ad*w~gTi2>WFHjP0IVi+XywfIZ-|~2ahWws~&!0O}4}v>M3-nOHClrC#
zp?AjnSAGAUA2VG=DEn}$)V;_{g^x~)&qO0+8YYS(p!9=s2244_m0FvB_sWB9=iD~e
z{W6@j*%RaUI`#8b7kLDbPP1-f;NC+0AsR=Oms`Apyd0Gv_z)g~dX6dqaN!KPySjee
z7O|`csllLV%eGnmm0R#}<*$?}?B-pA^K$=O=`yDEj-kH>vIjfBk62bbJU|X&YsZ2A
zm)VDBr=?y@IbS<i>-XFXChuaZ!dX%$WI?JTFcYn^o<5Zkuvp=ek0d}eUHt&aMO<R|
zvx4~F)QycOcW>OlNql7Ze3*RGMuci<YQq0|k8AJv@rz>Sh9n)hW2qT^i`4l3sJ<$v
z02H{r58p-|Tit1ex$whp#D|8e2vbZ=U+?RVPz1(IQS2<WeN!gOHe%U9RRa13!$=|u
zsYP9mXbI(d?XdjSuFrKcsJpnz`&BMo+OKq@J@zdd1$M1RdrymbEx)89=3856<*sJ#
z+G+!cA4@<ECQY(;pGBOni&kqLZ<E;i8f%mCV{rZ8A-p5zU9rxYFm`=G4*?Cfc?UH0
z*2B7k?q)J2Gb5{n1y1u~1kj=Tu&8nc0m>)^Z=IL9S({H*`8<FSX#w=WFw?y(%Xq;X
zdCfU7BCi(?2d^-RS;oEFx6isidGzS~n+htQ?~2i(p$j}b;@97{1VnbL^~k+ychcbl
z{IK~CqHA)m+1u+)8aCnD!gz@e!rTj81!BeYgiZ^ObyQM{gk@ou$CE<V>ybg<z#pa(
zSH{b-p6A>s!CWJl6J6G{WM<^VjzavUVpibcmQ7=RH)h2pegoihmh+w6hiKsyd+0>*
zHNXj#^1&M?tyb&I$Vba{XE-*+QLRifOpbqkdtLq?!fKs5G>2|NS+C77au+W?g*JVL
zqkwLNPc5gUbZuoHL3~KZU(K&mzZ->_0+`Bgt!`HhBTBhamx_!K)E>0dl=LBZbLArd
z7C;H>CiQ(jX~JZ!gT?w+Gup++2!|pf6h*fp{xmtz|2X}9Ox;e7X5fDJ)~yZ-3YRmY
zSyq?Fah%lFY@(+q+;M(0<eJV5y}UN_qEQtD?naeD6?;z!fniqDoS9lNt(6H?)4Ez;
zu%hQ0SlM;o6kMwI2L+XEOWJ=+ci-dX0+tAa5}yJ4Adb9!DV{Hi#$h!JPu2$=qz-B2
z5fXXn@J5dY+IW#4KyIoG*VNU`M$hJbY|_U?E9CfP<ot7KG8|)D3?>1O$<Ycuboz}Q
z`<BfNq4%|4unCd)?l7VP#x)L+0IRBc>pg3}T0jNkk)_mXop|LlQ&$0SZ*yJQoIulE
z^CBPUsx3C^GFd-p`?of?!{%p;)H?_ac7&+87n~-glW?em2Ol;E%5p<Ce{sR_CW^l4
zo)7US%ZbtW840p|J|m!%RKw#YzJ}{>T+W=oryo6OQ0wXx`K*HMF}sJZ0JG#2h>|Lt
zaxqkEJwx;g-MWH3XhSv+0B~1Ga~iE`x2w_(Ga$qWnM`fy^ARv-+!WdCh|GnQjEu|V
zbO;N0Pm~c}h%NIrhKA1kCZm(J@<2cUx+0i~ytOqn!GMp1FwniB6R%Z2=Q~Ti`Gby}
z){G&(xJ#_%UW$C7-;LGHt2|xodMl*;i%?H(o7wV9x~bG4>atw@skVTz&r$xL2nqR3
zspE>cni^Q#f0S#L?0>ax%d{W2>%0vUpFVjaEg;>S{$s(r*H(kN;yp^5{Rrs5jc<53
z0CJD<ti6p54GWoO*w|z%b!k#ce&F%C^+@LxT0{Ci&ISNr>A>rP0#D9Jyi)humyCyX
z58XOD-aWK)H_><1YRH?I+79!s`8EvNAU!qc3ul+Wg^?(2;tjl$@7T5^x3$b#5Jh85
zl;;laJ$Ue4#|2x}?=OxB3%fAsfI7%X@|x-X4j-tNJ_1ZqwwznBpL@t+P81e&qOq}#
z1M3^+YINR*@R95D4;&Y6;C7}yr~84{7rT`)WF@4}h#Wu@ygxZ{kIDCok7ZP{gyQn@
zu+Y%h>0t=4J#Hphj_z8Q5d6Xlj;TP8TNe@;7Iq)>(D?$}aqcj=<^j8vOJ^>+*>ytT
zD2S_+#NhJC-(LR(s$E<nlg|sWUgmG%OGY<NDvl0WLEBr@H^yJBmS^H38ihdHdL4Ld
zb@rL|;ik69$6I$zv$V{eP>4%>%v_61r_|b3wLGmQfmGvvsK2sCtnga~t_`O4d)FOY
z+pylQTci^bx#ifO-DT2OyLImlY3$5{`fP3xRbLASx=tz@W3_d;Y2KOgWh;6-NlA$s
za%&ei;WuwzoMV9(wZsYHFb>;XsFSZJh)Pte3szJHXS`o`ISUd{mx*$vv*ga%cN&W0
z^@ZXivnGm08q~>T@}7R<7$~-1C!wXK<+se5YLRlj*HAlKI0rrbY*->eI{>L|`HB_v
ztV}Z<KF+?s;E7HK0W-O|<^^>^cBmPh9hZ&w_4wuwN=pocbm(c0IZ(-OArG?8pvb$;
zuK(e+lmXCeIUvKcZIM)tLl;87g2<S~=kPw@#QpY<vyS4Gm`D?(MvWP>4(N?ZG-+l|
zST{mJPi19RN^HS$7ScAP1|YrGdqq3C1Ux1{QOtX{wcNA56chbQqTiS?Zd8b_M=J?&
z$o!F>8LQaX+TI+Nz?{Hu8D7Y4TEeAgX=%||)q-@anL8JgoOztYO`B@YS{!k0&jD{~
zZieFUwWP$lab^U64{vwI=O9V^ZhwFOTEj_e-(Mfu0kr__VF+0hr;6x$*UExMPWP70
zn@8d6wn2r(6!#gzau)LLu3MCPf47(ci}LbV#Ac&s$`H>lj1%Y>=|y3Bn?i@$iHZzn
zA^FRvdv$H?B2ENv2?rDV*|S|RzJOFXa@N!{7aNopWpToRLpJ2yE@xf>+gT5%%BIFS
z^`90@%EtYk3wnC?AhfIVjPvlpYcC`7V&zRnwrorkBR^&b%X*mVeYJkKGiuS)w!VIY
zS9rL6oWO~K>jEjNg)e&ShC=$%IM&M@a~K!IW3VB`7`Rs|2%YzRCI920+iAiZs{9#6
zcGK40rBCakX*qjH2-UqK!8ml7&F6{=V%XIDX?34M7t9hGDlT2)b-RP0aXdf}foG1n
z$KQFhpKd2OeI*9aXCuclTB--V8rl^~gXrZ1W6z7eG2V^0B`!h*YvSkLUbAn*8RT8Z
zBRV5TvcAEBfWad-9bYv4QgN+Yxt8z9(WB|*9JsL{hpg&k?5_)I+S#sWU7vUcRNvM;
z$oSa8LL+8Bv|lzr#^K?>5#OIT2O9|b1_nT}FhyVQ7$rE-Y6wUBs>jlE*nmBd=5xKa
zdJI-bqYX8>aIpQR`<{GaicLV34oXURvE@_6l6T7HBEDe31qHoG%b>{?@7F$K&G!~|
z!=FFf^Ze3tnW4r#!CX-=(*qTrY#S0$%8r}gFZGHZoJ)G~j%~%)_-dhfc;$B+JQ(d(
zsQnI>une7$`!$?LB<>7t(H?QenccR(o`2u5ces;~wV?y<&z#rSsgJ8z)~kSgN=fP9
zJ-fs8*b$3Mav84|-f|`RCvE+8=4w?tx##}xWjYFxUVp+MYH%S~!%NpYRTkgp-0eA@
z(!%)h2{lQ@{!3DUI$8Qi9eA#2Xv@_XnVFNY_u{QP|BHLwy|n9j^-gJ57*hOA<jT~$
zY>3tcTd#?4pS?)^yx#PPQh-@UXXmDm?nQ|;vK|tk6a|>!5u<^&?SF1xROXg8(P_7`
zM<8lg_1%RgJ+frgHD>?s{qF|k%Sk|;pxAD9d4^OfMMd`R<)7R?{ug?+>JQpK<O}X-
z-!87z;4frmYHMnqi+A3mOne^Dd7lVsjnV?Y>@#lD?wJ<#&IEB7F|G?fdzV7~=12al
zd-wTG;`gU&a>_d-+O90KIW{xXn3-@3g$k(5wr`hw;ak#vJ~-iAf3DMHw$sLrpaNL^
zddh5-&*u$AG)$}O>5G4}7G+gE%~)OaG<xfd>f$K(cmD5vMQq90xq|-d9=@E2h@iSk
z2<jSG3elYc6Y|e}5PK!Aw}Cti*aW`SnXnJSO`ps)pcMN)OB;?=4uAy&X6Vj1rPFm<
zd6!eCvhxS|7^3cPU<!z24TewUR8zgcoJMGLo=tLp=#mBH-n~U|5}%fcSB=)G$Ec+k
zQGJ28ebx3(1&^2fz&8_40HauP+q{Sw@HNN`Tw#<q#26}{gI70RoIQww1VyOB<h}m>
zPkF!3Pd?fAC5~QsF-tMN#C0ET%R1|6di8(64H@R5wI-!;Vm`si;b_q@hv?nXf4Y&6
z0`*`MZx)^q6`6&e8)O}W4{yX>eW&zwaX2z~Dr4tB*Gp|nU?$?7t<BAvS~nOZYaxv?
z)){n+u?e}SI3YAZ<UANrl=WJc$7i3>bp1$MTKer9nBWCO;sfQ6ZY#rwuA198%s%PV
ztC!|VU+C9Rnoe-ailPbR6Kb>m$-SB8fKizzug79;!UEsDnR_;H4POp6jsp*y8%~(O
zTfT5IVfq#8s{DIZ%wB-#iL>H~3a{?v<ufs>dmX=DOiK*W|1l3$UrApL8pfnjEOOa@
zjn)Gb=he$5KjQ_)1)T(pVBo=5Ci*_r8rq#WbV!F>4_k%r^ddhBD-vv?R6l5hNE9QX
zz<2`lVv`^1FJAE}%iq2kQz-&FG}}TCtTu_fWnVvZ+YqKKx{9;Z=s8R{<U%oO1MKWB
zSmDd?I45T_Nl%0+0tf{>UJ<hENaIBr!$KX^@mto0<y`OHwJSzWe>gJ~C;VCuG|IgH
zI<5T!cYC(A)FZ#<J<&pc1Y96uJ~u3JoyR*T3Y5|Xpfl53{z%rqjqSblRI2TS;kLIM
zSU5x~C?8^b1?t27VJ~p4I`}1y(asbzv+rZ$NG-e=8+>*kPp2qtn$=U_8(s;a8z|0U
zN%>Yz2T+2mi%So~tvca1EWB|oSRUs83a6<4hiTg@rY(W8qWt=_iOk3Btl`)~qTpH4
zP5v<uZP{fzaPl{kx>9qvbAAYOl&rjE%eJ9qyT8M}V_q`G&WoXZH%sROg&WkCcQ~=E
z#~s@V_yFfkYwsia)J&b~)%YzG^iv_tvo6~VUO+x?na8<$Cnh!cb?7LVXf0U6WSnj=
z=l1G(lb`WOxM@fuO!FVpTc2c~5|}Y?K~KL%u*n{Nji9LI_Xn`dg_mNd=cDZG!|TJ8
zC(CYhbv=7+*8RmZ-G4nCF6m=?rS(t#1|HUxwk+3^9p&U0ZOJPtp1U&kj%_06LEXgf
zUpuZD7pz(dX0Fc@xSpPWJ~%R60jnCG-9}4Th^qyAC*xIsk6@7v2dL7}n4-5Wnr$LH
zej$nkTjW)52iuh5Z@S)@`k(osNMKb}rzs^c`sa;PCX}LK3bS0be!Zdq2*FLry_UwK
zU!4#~xyZpNWb1W!R23JNZ@Zqhi{Gp$sCm`R0g&cRV2L)R<UXe`bX?5kX)$?;+wT$o
zfJdhGpTi9$5Z+}c?#I*7PakBMyu+7-C}DX@e~w0Hi4^|n>!$myQ_rk6&H1tc6&itV
znno}&8ej7b)S*lwMPSvv>g}Y9L^FaqxX?|S6*RwKTw)>9wX2i>9gsQ`YGK><v0s!f
zo>jWtemJIZn*;Cev%TXy9}AMmNNozHO^sA7uI*jtC<=9wd`L$*b#6bDeT)d>BV-Ux
zpcn@LZqiEZI&7U*J0ngOVce~J@lKWX_v@ku-DqM$Ol6wu>_+^<y3}h=&J*n!X%r(_
z5Bct3q&k(mO8a0V1(EdQl7+{hRZ-3yYh8P#uFurA;-epWKr+2|^XA2^^9JsHyxi`O
zMa*2tDIXtXqm*ywL!p~(W)?ZJMcoha-M1MHeK5VP^+d1jcJLm}ONgN><<YzgR^Y;-
zw+h?MyBWOkkRu<FHfW%;f3L3lnePsgR`&t@D@vKW401m1;HM<|O`I4p(NYlIiNe!D
z9X_zfgvb-(zBlXdPm{IAp~qMRBuj&RzBRn5<yjMiJnHcBt#Kei?NZFtyv|OtPds=q
z6MzIp3aoby5P$;Lqn2dD+#JZ!N;7=ut#A7mpm>(?fh2SNx=zbqoL+<|e$y@)r6u>)
z+i|o3Znz>C&siIUzj3}Z_rfsUeRsgER<8UCJI7(9O?k^}O91GQ4@aR8aJgUPTdf8j
zf`)MJ-s&mVHG_xl?0bse8ai(A+0Q1WSg~Mwf;5$#6<qFiMx34L8?+$K2{3!z>RHR1
zv+QH<r{91Zp!bs&yhEtj1oU!t*OwaORf#(h9YVh7_<3bfa&@_B)lh}9<-=b1?cSZ0
zdF5#9I<NkRpD~L|KD;pXy3R3&UAuNM!V&2_#C6EGNnAGO34=F$8ECaJ<wI=bj=ZaO
z<6E{nRgF#40Yn9WYy*+NE0tULj;5c+>c*oUOPW?EPU*Ac%Ct9egTqHg-h94xl(x2#
z@O=E>X(8@qkCty_vd;+=b<I6{ejxTOIH`>tQS_rQNtO_Jq_M~rtORIk5}P=YtiHHO
zWOUoK$zxAql>0~j_mAfoi0eA^gLnp;-VO+T;nv=@<%)o+oX!O6*`9t_z75<>kv`S?
z3&Dks=JuN-D7)rfAp3Ud(W3!lTIPi{Y}tF=X5iO)?Dv}A4~H+P&Jt2^PFF_r@V(jI
z)wF`QF}N#MBOMrAs_kf4Mx>|E|B&FmVc!+8CgK5n8ff5JEc0{QATNy<3d`d!kfX(H
zp&bv@>vi^9pFsI%-)iI|ZtnMg`yoHS%jCLQK>RmuNchw!_7NHy8>#HLeO27sn7?{X
zEj08JM#(Q?;3+`<zkdCYgAK!R>=!%d$3ETpB@WRXRRtR~F+TXgEbWSQTa|a)r3_u;
zsz`=T(?N<Rr0I<II1fdqC9|BPRkAH&MEurY{SB*7+TC8uTmcIz+bid$W0AwSs50j}
zGfHyw^w4%bEISeR#z(pKaT3?Qy$;qc*z_22IC~l0>G*ifc!SK^AtC!mh=2=Fd%2_Y
zWZ9o8Z->8m$A<tKfIgHH=+c{S={}Z(SxbI|PS%5tG+A#xk|q8n5jSUsuEGj7c`?LE
zU-shmwo7eCfh&$x+79mWGxNU3?~9eYBd)ILCGdN{ZQ8cYUr{KtNhK~`eB;cJV5Ix9
z6)WZeMv+lgk5-L8%>6?xKJ9{4JIt1SD$l=`FPnIXbh3_$fX>Xd(~Fy=fcO~Kc_G^l
zl(kf=Z`qhNR#AOQTkpgE{$@-&P}c?oOvh{le<!A4RH~L8Sl<o%D~0U{oKsRSlD}w)
zRGkban3!o8;=;>N@1oU3xCRI{Mc*XX$F$to+_N&{8gFe{ObuTT2ajGod%j=N*B*X1
zP{@rQEqVhk99H={CctXQm8~zj8IJZ4Cj|DMzaCTAQ4qY;$snHN=|LJA9x@G>xs8$6
z4j>{bo#i%v7~Bf8OI&Wlnc<SoqC15HNkPh77c+KNYYzN)xYGRC#JdjbD=02delfQ^
zZZ)K1hySa+uL`Oo>bktRySqbhmk`{8yL*7(1lQm$3GVKCan}$mxVsY|=*0>CcfOga
znumFqx2c-?yP%6IZujjzvd=zyue}z^oHfrsqKyTBzGVoQUH=LSft-NxUw3)Hd_N`w
z8E1gU0NC8gNJ;(6@Bjf)cKh&u{91tO=D+v}H@Dq<`3%6#0Sqhf8zvA5P}?jhf&-G4
zc*Mj2Yg~n$_Q@X+$$z>Cz&rzXdG0`$0QhX6ydy7<;*8-RzzxtZ6|UsUVBzF+2DYvL
zN)YDD|8)cq0r>Zh0PJFP{|X>80oG}yY=H#FXJBy#Scm~7!w`VVZg3c(n?htDkS)$E
z9f%D9ArnA)Nsxs_ku42qu5KV}(*X?xZYRga)_~+G&<XeV6o4)*I8U4{4T$~$?;Qs?
zD7-)n9?(7p)&$3AF<^xP>iB`&^Cgf624od{y}bd(h!lS<m_UG~0sz^!0NM;dm=>_0
z3MI4At<MrbECY}{*Z{mIAbqII0(hv-0H;-4I^bsh`x|i7fk+gP;szil0AvGLh#9-F
zDl|KQ+x**I0iGc+eE~qiKh5kjST8;GihuY`z`%=q*$#BnczhuN!o{1wR|1I-Ackc^
zIPG>}4vbA;83FQXz?1+Q74TA+S0t|%bW8wZ4*-`uedz%-IzXy552znZtNn8w(9q6+
zu?yD;WO@Fne*hIyz%p#<=qO^=4{PKN7!_ax2Mk{zKc@;jTt^3>{aXZp7eJ=g)@{Jv
z5V!?k$NpvSfaeBYY3?>0piG#?aQ!!ng!?r2agrno%7-cu0W9(;kU#|j9si2IzZug&
zQ{CWqui983KLHR5xqOcQd1fxT`q_&qQQiU2Pe~wl%Pb?rVM;)#P=U=j_PhW641hOy
z`>JTV_`j5+W8<R!(UC#~T|dM7m|$KB6(NQ5`aA)90pd8Im>zcII*>jTq*1~d^Jn5|
zYWePvV9Gpt%ljyYaPE&of1v;S!6U^$hEPmOkPws)3?V3(B5{i>6qkY1fe*(tkOMW6
z&=f=nFV)8pYn(+~z>f~|NGGiFIhR9-N{B;0cRKdKCWhE#9D)qpH$BD)^Ai&b%@Tfq
zS_W1M78Qi0<-SM|S_unWBjm(|lgptm(G<!!i_Hp!h9LyCN=_4cz=O>L@3ys3=2STd
z#flY_&H!&N^9*^p8C`N}?fC-}2KB;42vT1UUc@d{m5lb9zEH$cX$qaehVHuv<yel!
z7lM`=-~e?n#9(n!T15s$CPX5tL?(oq1tuRS$^40Xtb@)}hI<*c{?4r;hEhnKt9Cs;
zlnnTWkwm75fv*rQ&W^>^fPmgQF)d`B(sVGLUdAeN%_JVdyUUv+JX5#cHv@6GU;A%@
z0abEiIQ@1_LLh5zYV$w_N+yPiBkGqeJg@zJcFkYrDU62ZHb;Uws`b$^3(55%`m5t-
zr>ZN_{>viOf$)LA{O`W%;K|_?V%#lIMad4YNI|(4x|HyQU`UMY#_SGF*x3XjNHmEN
zLJI{(R{S}ZhWGwoSb*n#lr56Vl8YGTH!g>lXp}Tv{V@Li#KATIhTzHNjdSV8zNTJP
zm?+W~=x^D9<yI_ES`f(qiUm?ia-k+8ekvD282KGZzbcx$!Y^)6IaKm|{RqJ5;nbz2
z?e_O^P2RbD%MIRCsDIKV8MI1?YD$cfsS|Wr{MT+J7NV$P5edUT-@vPxi|JtSs^tE*
zoqta{b^W*hKNk#e^nox!#V+-Jv>E}`9fZ(*Fqoiz5L9>%>z;;@(!3B<_Fan$Fcy_B
zTQ#CPKa6_)dd;}`nN@>T2``+}Gy9fAg(?}i6ExGD&zWCE0PnVMD%L9$KJ(QG&ZHT_
z0Nuw8+;DX)2+C-KBcB-o<`FO9P}2I+^6Axk^9i-@<WaD4FJn>(MhQ!I5gg9cgPtkj
z<%e?I;)C<l9|$HT^}is#TxEJ8N%cM|k$2>_-&oOd#n7~b;5h*k>#s{M2N99S%hTnW
z8(mcu@q+nMZNdq`+ikD}Pr`#sfYf)#$lQUnHjV5gHXpCJ8QW0<yRCBVvR-?GA65!)
zk&P5l<U?}mj<dpC-qC6LFD3pW?w;GNvD`_Kfe30pxJ%=GzdrS|uW4h$yJ@A|=iTv0
zbKcKQR}N^LhJ`XjWjx+r2#F4P66xfF?Kg}K1YXIUY3yHCu3EM_T#KByZi-t~&N@@`
z#=1*wyPyRdPT*t@q#ybnNE5JUr^Gb=LUQyQJiTzv7VC|&E%(84%&KNLX@4JleIg23
zKV3=6;@XpDGzeWRoj2!GLU_Xt!XmtJFob^3!+ND3+L6qUKl8%#n9S_R3N8;`c4V)6
z*4&TqX+5mo@0_LSKk$9|(y$nZAJ=(Rt`z|<Q!Re0S&!VmC_QB&+SKJ-P0y>FM9k9N
zZGQJE!+Js}`gXmcN-a5dy!$1d=)1LT7n`=iTlGZcOXmC6PByCeG^9#J%%~sp@Ug7X
z1W+6FK}`Yq;V|jCP_=N<TwmUsnxdw<i<|2fvUP$>{W}h$QZ%{pE9@<MWj-=pHe64E
zKvya8Pq1F(<Mw^y=pagAazzI!b`%~`LWAIH?Mr&#zgftu)Eq4!JyugG5J;M|JXb=T
zjnE)4gEbP3ym((E@;yScf%wo%&qRlz!ssd~5yIjv2;`y;+=UQ++#Yx`5G6mF7up4}
zHuZrQd=qh<3p8lDoQfCUmJh)>Y$X`V=sn?dZJ2hEaL38$s>WPk(9z4{4eHf55p3T>
zeU~K_eFSCuUMv5<DRZ8y9!`RHYq{q2?_O7nSQWnCB3^BF+*sH6EQW|eG<!4l`Z*22
zIqkj=n$HU(osBvH68uj~sVFe?EuRU)4<CN6vF9wi4lXC32^PCQ<xYU|%T=$}T6Ye=
zZ#W(pO^q8?J`uZ`8y;sm^(R4u9gfyacl$R>57a?zU!L#kbJFI>Ej?e`v>*u%sHk+8
zOXOi}BJ-ubNg*dwz;LcvxUh6Y1Le|MX8bBnZQ%u8`vc_g$QLqL>h@=@U(R-0b*WOp
zv`WK_^ALS2^Y&z0O+*1vrS#s2`>M+EHN+ro@;btE_I2Iwbu^>%tb_lIADj~wr}x|}
zo0Ud-_P#6bbp{j&v<+(Z`p(UdlY4NP8`*3J<Q)YJ4HBqWXhfIyzVBz}k+G5CF#D;4
zHEjmJo8;KtEkdkQUM&;p4q2D=NqIQy>)e?^dhI5@%k%OiGrF>Nqd$@TnW=Gu{&N6#
zM|I%0uZg0kG!gDg6f<2}7YT|9CKl$_Qaa97S}2d5?zX3@`HSQ|nH>AIEF3)W?>4KM
zvs^tU7|h;&e_MO1i}Rk0W;9y2%@o$g_ix_2+LWb($pj}>%s#(*UL6{9wd&*diH1ll
zObL^QH(m24atu2b$8J2miy&kOyZJzxwOQfp>&yKs?1@O+V0ZR`xas$H%b60|piWW)
zgHzl?L?diqLfnXTud<SDrm?){tIMB*ybAcdjx~D}BAri;<6+w(arP_p&8!Bz<!9tB
zovCv5J`xHhI-S(4@BM@y8ox%hQ(xCzl9$4FdB+h`V-=0CCw`0;(NBRzo$D=dgQ)Cv
z)O312J32~JsQ)vHodU)&1_U_WogFi<P=RA*yJc)BhFxE8HhDkyoHjFkNrXiAmKqAX
z-ajV<SXUjN-&!OQ%k+}w?(ReGZW&Huka@SNF|N*6z4|@7Ki4oRf7WvR5wfQ88+-@)
z^4NEq<Xg+ODPr|_6-0th(c%3H1+v%kV0k)foNfd#Y!EEZGc2Q%46Xp5H{QM8v-bU6
zozxbq-pLgVkSCa-_L=Flk>Zhcg`euUc3E<bZMNUjsd(PO^y%q{h`PRfyhe@T&hU)4
z5Y0h^ow&2v7$*X4rm+LIMX>3t(0?f?sK8<^r9C$C;izu_oR^$183uP;(XI1zXLI>f
zVMC18dpfq^b~`H@lKLGrCZnlsYW4-^6}{Kl{vOXq5qSHCC)KIj&sG;gE6;mspmcof
zHbATB^XM}fv-0DeqcL?3)b>FbY;O>GudK3X^=C;8xsSz~GHH)qJ@-CVb_67z3al3(
z+uOdy=KBrR<3%IEa%qKjhg$c00y34X-w?jR;k&JGOVA6MRB;-4Hod3{;2+kn>B}+|
z_z&PN*B!MVnF%$lXnzyqJl#cTx5`sIJ=M8~2788P{(kQJxsJZL_klmt^Uvi7*~c>@
zvYumWS-XX%7Rx7-J<-SaU^S%}%dgpi5#D6gvVRvTTA$2fEL(}9W)9TO^Ji9x6}01Q
zUEiy%JRY`@He0{6dAw<Vj~Ehtb)|X#c`S_Ke9RFBqZh+bcS?Ej4iID~p>VS`bhY`u
z>Sj`t<Di{4M%Z@rW0PbQ-@PV#!fU&rHOpH9-;+fo&6Ggay)V$8m6|UHA~+(s1T$S9
zfP%x_;t11OYU~05JM!)?YJ2bkR?g?phwCLX6PW(je3Ria@I7BMT_0>MODk{qre2BG
zd_(zvMuPf!zG)@sXT8NXHr3SMjl1z<Fi4D;7_i+CEy&oKTUa`6dW$J^EIt&q?#G?x
zWX*GNB>G)RA1cG>LkB9%>61)Nv^3S2=}WHe@1<fm3YUgC*!@~xTi`cG8(kv?S@W)H
zJk>T^pP+(96}12>BpmKTL`)>W+u(G*_pELt7+(G38_9K+*C<*X>NA4(fXP=m?!vC3
z8M?ZZjP`oq(IZ4AY;xGiI~`1h8yvou4q4el)Et!0I^kifPi<i*uAa6+&&n_iDY$EW
zk6!%eD-v>w!s;v3`pRmYOuThvCjJsw@`(93s=4(yUgm1|NxsR1FIvs!EH%U|?VEY%
zCcZVeE}1*pe~au%%iObdQYZbWKVe9bq<w2YbncTreEF4l>{vI;uXBHV-}MmRUeLy7
z)T8>dzPW73ssMo_#lx2chANq-YGM4=6LsPX%s*-;<7W&fciD&^+yuG!N+c!i^w)YJ
zjB~EMo^vSQ2bo_o1wa@uLbkcxc_dg_*OWzH&f3SdZ>ziQ6s`qCUNU5cqML2*hiW^g
z1765p0$=YXVK5Hh6_*aaeE?f-`1HSgHMu=xm3I2R+SHdqyMGX)hm>*bkk*)oXB)v&
z1x2hBA;Tx@c-YehL#%?Wjqc&BsdXeas`Xn~dECub)32ND%8!i>R99i+NY7mwpud_y
zH&ima*1-iIjt!c&_4e|ouKHVyuYwN#uHO*={W3REbY5Ny<8OjlFrs=(v`}g^Wn~L4
zm#e8*n|>8_|CAm(91XY_v!ZcIaY7$Dp~VvPaoXP=Z_9o4Y}zx9+T%oBnA8@yT4e^M
zgfGrE)~82+b-h6|Tm~D(pfNEb1Q(LCn7yfLAw;rt$$<6qA`~@mq4{$>Kh^K!qYpY$
z>t6};jN^667p}&yV{%hGdERMcI8&8D1vbg9{JQ6c=QkL^p*9CH2tTj8bZO78>W4eR
zBEprgxf4@QIVpYIxj8?zKf6q}C8~>-Alr8(zi2=NH870H&(7R9wDs~2paL&Iu<NmS
z;=&~S&NrNi9O%5Xg}zgNWc)Tx*V<Ph(aLRJCP?NX9oj>nFIQ{iZb|y&r<U|$SMDFM
zIO|RT9eUB+bi(K%AA`5~sk8n)gSAg6XBPH*t6Yx5??9%6awD2B-RA4pmBvb%u{RCe
zri33{k9G{cALTGOeTEu2SxL_hNEh~adii)}XZ&meIr-IIg|P)|uK!Gk6nMVt3QN2y
zPiKB`1p{Z~Bm9xGG_L#HJTMdiG{XG*`_R6dd!xXUnAY&B+jYrrf<yNI_~$yk+z5_0
zBx_(|zT&i(kDjx(ORbzqM028zbFL)K)q9&@e=zl1Rz4aqm4KC<2w1?ptjs>aUqDd$
zN>c|fH+23uxSOdx(ny~@wqyl=f5)vg=TB}uKur3ur+zv(fbGl2k(k`h3yNGO6uw*A
z#UdUmt?p1wO8c2HTD*@Q<K>U1hC<RP+=~B)z1{D45`yw-czO7l%Wm$suS%KQ+y4GH
zjKG>AOB9MjxGb4u0V8h?p4B4B5SW6`Fd`00PwOViM+e47&eO0hM&rhW+Z@etO_F<=
zM*iIf>oW9x(diROtK>Z?8#dDGNo9KchpjA|^nDqB$G^5Br{1L8cf^zC(tgyo<rT6K
zy1xk#(g2x8UquzzM0HQQUkmtq|DJO;Za}}CXx;L9)Evy~$`G)B!ZGjT(&q)in8N@c
z7MQ+@Z7GjxUf~9Yx#VoF4api2r?j*b?U8yKRA4Bo`&VX35~bC^1tPxG21v(BHTnL-
zJ%;D&TrfO*lm2w#2b(Zyq029(-?sLMB-YR9h^FS>Y#afaTM8XKU)hDHrjo0Jy{<8g
z>z%N=m?9V8w^IH$HWjVkTsz+e@yWT_4Smu=bJ|YtUU&MNvVelqhsDN^(JFJeHlXcg
zFtcz(>kQssyOS_F4UdB=0T{{pf&}rQB+_uKX2`<nMN7<ae_^4-#9)%M+XrKRFovV(
z$5;hcbvuum*!9ObP7sGV8cX#AkL^TAKyGNwcP1mPg!0%Ls6Z}_l$2Zp1xKZ~CYN$G
z1;=jRg`+M*HbxQNgHz!`&mDfBwTgn5pHD|ZCPU1#eX1;tTv$;VO}|fTM9C098_UPD
zvXY{~?)<_phE7I`U07dDs%9!(P_P|E|1(*imU43Nx$3r-J?wgr%IGLIeC3}Sn0d#~
z!)SJL(^g!S-aCoKoc!`W#JLi?pZ0#YOQn#&Oi=QMtJ`bFN;F-if(e3VRuM((1nUZ~
z&V5WI^Ot<M$)IlwfbryOt~XmXe9NTs7{CEtK}Nbxg&fdm;JpOAxXY?K_Xs_sYL3tQ
z!lzp^;8@q2+e11(E~@G{<bAi5W%vz)@l<=*<k|>PE6XR(;~8o_Z~py!jpW@tzEWf2
zmI-khW;(CX^iD06QRgh8nEvki*Jsh5Oif0)=Wh9I{l})V5~{|UE>lNqB@THO%=0w{
z^%OI{GtFU?x^QvLm`Q7{mIo<SB`oS6+tiDxq(>#Y49($kuD2la)>;umPP^WYx<Ah|
z0hwN-?lJHxN55z4cb?5i4$$==bKOyIecGrnN%;2@Iu*m7s1IgW6g40C3+e21Gg&r1
zm`yx~{1kdkOUZoNZ}<+C4@qySTo3;E%3SywO?IO<e0sA!>&xzHSB5cgLpG<qln#Jk
zV_Lp-1e{#zZj}ss7&_Y=>vmxH3}ic=5RgTqb{Y#}XSF&z0;{t0R0=TdZ%CGut9E#$
zSJMQgcv)g4(Un)bkH_OvV+c^Uibqs0g?cSUzwI=3WX_vD#on}gpNo&L_<}CH?@eYC
z8<{(ex|Nq*`oo}PpoOZV$3fvMK8z$@pj<1_pB29nKOGqvEFxuX=#9#=Gwd5Ia=?*`
zjR%Lqkq<ffrl+XzsW=vm%%N|@zw@k%d^DNT*n;D6ZD>iAe{H0xr;3bo3lPz~P|B$e
zijWQ{J?|>i{rhpOxH+VU?6;%2g&Ym!h<l<ZBga4QPf~hKP74E(m#*JC_v?q#+oaWv
zzwM%O%lUCpeLs&rO!chioNo1VdU*G?IP!{arDSIt!NwN<t-r2&FmF*%T6rbv>HGQj
z41<E{Z#l%5G=1a!71;Km2X`B4K;{t-hWxc7!OWU+)lVeJ8VHY|X{127fLapU>QNGa
z<Nsom;IwRMeC9$*l294OTbi~ua>bJ(xN|=Kj}dSE$@X`_8+WH;x>{2WcIL<Fn&J;O
zdCF(%ach2Xq46_kX<(t}e|}5`9K9Pd5#QVvL;f!ku<pVUTWaxw?dQCa4eSj4@<m)5
zueem}W+AEzWkU}-oB9(90`8t~BYw^^wq>mPIMyrcg9Q_boheLtc^Q|kRT#frih%Oa
z+Ag*`ah*oSA1_s3vqUzs{<;M`RSa{Chc`CLuV-B9RxDicvM7Ob+plREt8UU;Jk_Hv
zNg&gMi6aKq*_kA`%~d)4#V@klcg30>kmX=7DXO(5UHj<s!Zo@`N0#y0pw;D_nx)^-
zo{?sh6E<>!95i(if8N)i8Zv+4-);BN<{KIE{F|KrBVxqahe@gGvN)5dgYW<L{s)1u
z|JSvYa;s2=KJGX4y1lKqK#xqUC+)k=SH*+JQCaS=|LpbIzhhDYF;B$Ln!YBNVhm0Q
ztPibNaZ?_=|KdtOsO%>PDu<gF*0c`mH=qy#GZ&K_5lVu6O{Eqs4$3I*!cqf>7qCZR
zQc^;j21eGyz2q{Hzbh>{vldk0fOl)|$Nx{Hi!|JfkP;P!8h!w^$979aO2Lbjswpkx
zb9996E+E;9SYe}fC#R$d4ew^j8GFu!PH8Si4Gn|UW3i>ON=*p_Q^o%7+S!4&%dTwu
z?E=Rh+ca`ojlO&S1n{{)ni%K>sBI)+Us|SJBHpRu-;0^9)M-|&K+rRVO}p@mH(aH9
z8`ofNz*D<=GoF49GuuU8S*^>Ux=XXZOA>>=Pby|Q7kf&maY9YX3aIwc1YtQ^>M!pB
z!Bbt&M_p;yK+NeYDFrdfbO|&yJ8=a<UKOu?Yecia8Ek5%!=D`9{yX{Dy(YT(OkvC#
zv9Acp9r&v5+IzPP?Yq#Aubq+8o0S2*Et7%iROXb_)6tQsDIDhEa)hRYm@$Mv>>J%A
zV~WM7_^or?T#Lm}ob#ohokcsNpDr~O><WkHYsOhG$C3~!njJXggx$l~!G>-+AQnp-
z8%d=vK`V3-ikVL!QMgx>kk1KVxF7kOq(P`K=I{fty5o_w)R<6_gn(05dh-P+o25=D
z@A@^XiUf35(5psNZf_+KB{fpfepC=5A{4pXmf??p9#8R01Ey|dzR2h)HV$(v8fa?s
z^j$abXj3Ah78?AG0`(w(`|Afq21ZH^GCbsY+V-3g7s}6m#klc~;L*sQxsh=e-201m
zgKs9*OS+LkhXsU9p)hC2l_c{2k`mlGb<q$S4a3D99d?sXWsURXTs8{$!~jv#)!tfN
z8HfdLH-X6ngw04_R8&K6T{dodEd=T%+D*;yN1Ncy<V?W5^q-oafnfM$M;V~uC`MJK
z0Px<SsTfUYyqMX4pZ_1VfEHu^pt-aA0t^756xBlg#RS)skf5feEsI!iZ-6J+Pze<m
z2PAfwl7LWq78Du?C?!dsL8Q_Q)@1=oxNCN02qokes?-6{gsyJ+f^Ag~Bhag5GvThy
zHy|Aq;H5AtJp{(lsX}3qVE~xsf1m%m1^)kT0RT=%75aZT-GI$DJ>W1U{%p`f#n<IC
zp7^8b487DgApjp{pXiYch}bMDpd=xLACSpsg*As=l~|NYy*Uh@-+QX+K|!^?`4KPH
z9+!!XU*H+c$n5H7X?d5OG2cH*UW{K|0av!8i!@e&+sBAUR1rTMM6H#9jlcxfzxzd4
zr;db6NT{HfY8{wBjDyBuiVC7MtFj~@oc<GH3Y1H%j@&+qF5wYHW5-x5Hl!*U3=Iwg
zypY<5Y@9bH{755)>m@Eai-Tm<WV%twpO9H-)zJgtQen;?oOI9y5Z?I<vP27vDDIyR
z<I-+wZ+`c#IE>^?Ir5mONM>PXeMha1WRSm8oPVEXsi%#MZK`D1apuaj&nzT$8nPHt
zTYjH5uD@9EsjMlv31FatmKv3Z3fvQbF3#=B?Jjz$7||FV*YQS5iL%sNq6gbB+Emyq
z5I+KfJG#CIDEHqQ@X3CRV-LU*!Uw`_i@}hB6ii02w|S<VeqKL8fpjV1`s51AL7MW?
z<Ba>aa$qi%q)_)aM>4s%5)d3nJrG)=Se<c0=hqepPWnMzMl&CZaSXp4mvbu?YC@rP
zy&evY5-Ou&{Kw{x<{mqJtJO2#*7tP7-OmM55<||}TpCBecP${+Qw`P0DcF>x!_K6`
z4fgu-#KT%!+-y()a|Iv^%#+m=d<`dW*}N}eo?}QRc!$8Cqs_FBSf{_;6jmL&&qK=0
zsBD%ww*PjZi}ce5mxX2@U>X#>OY`xJC~lh{c`;NslzvJD{p-ONF&LmPtpnlSO$RoO
zZ-J`k+uCSBa>ccauf7lXO|ZJAP}@e|Ikfv5N~=SPLhQckv?m!_u@*Un%a?Eg)ry>q
zz>ivis^;Oz-NNy&hO0-HmduW(=#PPWZ3Arso-ZG(X%~~-op#yM#!9Mhw)mnBw(dR#
zRZ=oC9_gR*f(3mT_Sswj!cInJIJAMmVW2<}_Y0iX)+xfb<`z#x!hSv*$+a<_1VDuc
zU91;P0rCKGLep8CJ*)vVw6@Ks%E(tHEtBUmQ|la3?aOk;;6N-&Q?m|-hrKqzb6jvt
zYzHSQCcY^8^hwQbPK<!&CewcN*wW@qDb!d4`W-r034mZ5vf8ugrow^FiPF5-)##J-
zfa;Tg-vG5_Ze~JedNLsaNm^#=BR&PA-RK=;ZL7aO7_*<lvbSJXx+EaYs4bEMwMg}y
zHeKy*GKH9!LSJW?r|^;watZZ;U#uaU=NC5+x^j*PooB+B(QgnXZ%PNBGcPuYv~gs$
zIe%J6cL*T&dL{vd#N%S4*@rhU&|_$Fh*HmXUL8}_)RNuoVtz6YLqnrn0$b7`mM~ge
z#%Mm}+&Zb_O;KI_DPVCl*SUOHP@s;>H=nEm8Lmt*q-lP>@rjDAJ{WBT=yJi)qqEWH
zm{Rgr7_KpN*(Y?USq~UpZWLw7q?9>3EM`5VF{nBg13%ku8qjswGCzWG1DTaAR=-y7
z2%rr^<F>ZBv)W~@D0P!%6FaLtY0zM#=*2;!F{ISN^?eLtJ>LgLO?GVQTCt^Zd(|%8
z;wQb9B$G1bGeKwK^XVPQh1o@~B*2J_>gq7)@O$zz$T9$MIpv?uq-mMinO>rt^lbFN
z@Buo<es#7vp$cdX;OJ`UnviwCPQ=+2^LZx>0uc><loHo;8f4g1P@GWQue9;nQ<w&#
zDoDiJO{DQIqa2{(>MhFzU_feQh^<amGd>|xpc@~*sGrlOb>a`h+Fkg0VuLuR?+*eL
zI!2Rb6R{yWxPt5hnGL|?&xb;>i-87HvNEE9bW>|umSUPio*U^J7IWHzp+`RMCE}#i
zABv9!jpwGk*PVAlI@`aKEOXX7ine2z)1LH83D7|rc~tWF>qSjS7($(*paNXcp6&_)
zmEu>A=Qbxao;|K%WPxKv^E%A*yq)0jUt}8ZT=Mh8k)XmE_gcvZS0oMfpjat7)7@=h
z;nfA1U;;k{g&ne5FV2(mkd8U8cN4O))>Cq){8D6AEr!<VbCyp{fnv6_<Qgi?9bYB4
z9n+K5G1W`84APh-x82}-k2ak7zRtf$?=xiJ_F7>n^z~XU2=3jaWd$rQDMBCga6NYF
zo<MwEpEEwon3%Ilq$V_6?c;A9zI?sZv(1{$*0fgj3L!jiCN8E#>rn+1Gc&zK39Fso
zziHFP_LW^wNKioA0&M5ThPLvy>o09hzj?wM{*L!>X?QbT&9{#ol2(%e_~xpZs_yQu
z!rt9JS3cR%3W~~#U3uy0$?2I1k3*Yzz$CmAUaN8ralGAlygeJ1U%tv*c2c}V;M&Nz
z9944}Z8Ko!-0km<`T&Cp(j8%8>0*h7q=+%}D$~hx^|kT4*P4sXO>*ATpW`p$XGeeV
zd>}oeOZxE368}wPws?ScBfx0?7c|2M)Li)0{^AsFyy2EKvL0+x(PN7pJkyy5S7I9I
zZ4(y?uBG^1v4eb}PEmIQL<=Ft&U9D{V<`Nfq<xfD1~$T>jaW9L(3%Af2iH1kYFxR6
zhC*#4)AU1!&BI<jd|D7w$<;Fz+iMr~9jP!e%UJMuaB~X+(%7nim=&=#vVb&kakl1k
zD>BkZW=jI!WommzNCn&%RhKc4y@U6q!AO8}CbagIpI;<=F(^MsC2PcHnEk%%FcgmO
z%6}IJefh9^wzk>@iZzID^IruujD8!w>)HB)Yw;g4xzB(~y6W1G?x;?{D2K$sysQ_D
zYtqxw4*=xbwDeyp8&u$3nAp@(($f>=l2&Uf3~171fHE-va|RsQ!3v5WV>|IYKU}t`
zSNNTw*{%kIMUWBT;;hsM)09$v?Yl4#Fu<onYgu+$msD%gCqRkq!({f*>9o|{D&Vq_
zyabp=JDt4#_<g$%lycqF6b3S@G9|N<Ojmm{JVe&cDMyrmv*F+#@H7KIP-OVLYBJG4
zt7{83R{Ko~o;&*;cR&=_lc$j3G-3v9gxex6@!+c9lhq<pbg1{Y?9-+U2>7RKETA%C
zQ-}#@x4^c7Fz-CV1z;yk>A1SJ8&Pp9Mo}U(Xzs<$sO&5(AXt<sOP@|!0*O;8`JiFK
z?|eZ*Z|Wv$BIPb^19s~_X{8m5xeg2~HIJtY^2R$6m>ZYulwhopU$-_N5M-TmJ)c+V
zDsy>dy<4&NzT#B$(8b#_X8LF)=_8K^p1Q@Fdj^wE;qEr!kiMB^zeb)t<E$xJp+3;S
zb2&geW=XtK!cQ&ZXROL)aHgh9&{;_}X9m@!iCgXGUpm6`KH0i?QD`aD2Am%K<IAHE
zgtEE29!7Ir{koOby>^)U(zA8%-OZ1VPsTSIot!3)K=lXJb2Cp97tRWFOqq`KDy9}u
z+rGgF0@?75fqjq*t3eK#R>O<vAi^Gj^`$M(;ll}hhQ##S+m0FgKT3l1@sZZig?=j?
z7OZal_zdGR$MqP)n<fuE^_v`-Xu=g$mA09sGv-b04wL1d)>^pFF<G@9%P)Dh{m!w)
zi$HLANVEa{t!#QMKO!To@X5+xebkqd1QqHA4+pR~8D!A1$s%#5+O49a3fh-W#knl<
zbQP#!BxS_tdSIyJ6r7u>kEc!vC}P`c{flCYxIwBy00SxY)4C+J`&55#9YgM*)!fR{
z0=9oRsnmHELhM(k9l<1-8t)t)2T-7aa+_ALoZjq*;gwIFR2@o@10N#R8-+Q9Ctl0Z
zDAp_e?^FtU$d7T6Vddqh3Sff~siv0HJTc1e^X~-wzbzM;6wP1-)J>fUpXa@=aNPXS
zb0P2xk;)A5{KIgVu;FuWR++dYA||v-KJ7>2RasSQVoch@aNoavqYUN=Tc5mnt%=6t
ztd@$5+K@M#@1NVR<t5ax<x{%%aiFo_aOe5f?J^f1bjvo&nX7O?l;U@IzEK@g^hpIg
zfaNu5(o$OBnb38*keMVAIP7xQs5<FbgtIfX&Oat3W0Xr^G5#r+V^?$N_TAUvTsx|N
znk-GA&<v5vaA|?hHrHU4cU+rGxPsju)#>*y3-u1hm6kJ<E#(!KAGoC~{$`BDVzAV#
zpg>M59uoDO-?8r>mTKN5h=xiuXteAJtU&sLZ>lc5OZx4mdLM<V4bS|ZE=QHCFmF{_
z)JF?<sC@=&D18aJhzy;k5ojLt82r_XC<9Fbbd!P}LduSHYPDP4XYj_p?r}U&)LSJv
z1t2F1$|2HjAMhxu6rq9|1>Kcva$opC{b*2JVjB$8r`xP&e(TP@-`XH#_cbD~1C8lC
z0~txXevq2*g5NgNlrUk*_NwACq4sxiTpr)s(ir^06_FWFhLQ@7DRrpDPCj;D*DFh_
zSx3(U<Q)v2Osa%A-0_T}ydz|!p+Ryep6ksHYvj##bhzb;8+HCLptdDL-}x5y)$`EK
zn;X7h3726b;4|zi>3wJ?{8I0m!6&bwqCz~1sxOE6wM*|0RpaH^vmcq|XNV+h*qq4;
zNxzt}O|R2o%bpVi^MBbK=tioIb(Me4;k0T=?@IVgi4z(m`kQ-b{7Gr@p???=sQg7L
zR!lF5FQm|?3hgo8nr;BR{$RjX5oOR2ky(t0!CRu1LQh>sf74jUOr}?)1R+w%3o)~R
zvXnZed)w>^4MXc*AEDA2sS~$9zv*TRsju|$kkLkk>f|H6Qxa74;m|06_P6WGqey#Q
zbB%c9_;FL)9clGp0<@X`@C|+BXashq>U;h;d6K7vJ|&3f_&Gx-IYInwLUPiM{aT6a
zTy=~3Q~Kd9V$iP<9K`sq>5`ze>#d$Y98!$MBQ~vF#5_#pBl7242{0Y;($K>-7&2m$
z?KbH(S^5zX;ZKiGw$_%ewVks5KxJB&^9*!EP*l)P!48<AL!ZBSF@FY=GE|PELfo#g
zNqD&wtPW9*qKUu^o-KCWAoEQ7D^-%;PY44-DjvCAw{5Y_wEDiv!@G8Mia|)Ps&Z^A
z5r_TRXsIMieQTws`XhQEXK6n5_M!>xdtZ!?lvI-&EGW)kf#_;NlDI(Vli>X)JmhJg
zs<toXg&O!pf95F)y$&Nqb=S?bNs0c>)na0;Xz%3l<aBZQJ2U?vJO0E<|2ErLClk>m
z_P&*chQJ#ORA?fenlte!VGr#cLD99#aeQE42HA4?ljw&IFSl@L0tC=#omrfG!cStc
z&@Wyb(o_}%JmLA<Tz1m{72dJ%LVLG{UP;@YBgD5`T$N-@cyvUww017eUFIp(Bc)<P
z^aOlkV2}(Dtxy3(b8OueiK=qAs`MH^xCd&0aiATT(|`bvV9Uh^5*v8p->l_o7Mp0R
zqD2Rdh|wbkAARY#v1CcP`HWAR(8d1#ZYQ1p9Phm+GOnK41WV>b5zo;_vPlX0q$u)R
z`ERm_&I|38CmpbfhZ8G7_;+|O@D`LbVTryQHKz$+HCd_4oslkn5&=8Dpc7<jT1`-3
z69pnve~F!PJGG05)OkJ3KE))T)8U6agr3EfHy)Ps3#l_>O~L@jfP^t+9{zdfh-~C=
zc`%BZm<Dvob4n1Pa3e+uWs?UM;GvRhQ=3BGTkcbxqbe{D#+tYnhf&qvR-$&Qc7wbp
zh=`Rc=1kQ~fQqMtl{!^<f9q1(oj?^F9xaSjEL3YOqc4Ld82SSxL_KG|y*tUS%iG9R
z#YtsC^Ai!vm@Tit2Z|#eebi6$goM?`Lle%Od0TYxv^Hjj<%Jph<+0ej248s3`JzH1
zhlYj+Ld(-mGE#2~9}1VbCe_odcchb#X{q~DMzlG1Vhpo>S<Gf#KqJ$}AC!{rpY|1c
z$OlwY=@L{oE7?VjIFlwYM<$6P6E(p*gw#{5q$i7wj^LSiNWp_LDge%H`_BO_Mh<V(
z{#TnL$TIx&I~@vC1*0pY3+3<Pe??-*Jm)SA9_{gZ5}D1awz@U2`@xa$aB}@Q4~We+
z!F|srtd!Wd62^4hHN}jn!`Y%QDGdc8ZrpfvyqrvMN!HK2$j<Xq2{_PFO|HHoc{meN
zLG4yan|wOgs@AZk7b9vMs(FXMmAu^jv7{tNcpBbt7&8bKIuMl*c5>$H{`lv~b^!^H
znB*rr9Y)7YP#=!}nqbc@ccv!8LhXp+W<0!aL?hAt)nmRSAvvj4)k+KN+UnY>v_5Js
z5vrAKf^38s6&eN_14JP+OR;FBj!jp*Z9Wx%LpUId5tZw~ccbpbWp<BoTT@4`52yEq
zC6QiFF)kbg(-aynGXW$1Ou>Uq%!z|fj*&4x{|}?3)ig+qO4^5iW4sfkh~9D=tqYKT
zaF|<_Bcm;xFVS=t*VuT)yQ`sqqSk}i%!&v`LJ&$bEaL$G3Y6)5yg=`HqHDgTI`mc1
znp*)_i22+#5Pa)!+LdjnCf%MO?sF--jtHPHJ=YdQan!!~k{h#wo+7oGWRspfsFr^{
zf4S!1Al%gU$hl)v&+-~%pWm?qqO@S{hfkeqd&}1GsP7nIL%E5FRT2&#85O$jJDxUA
zs!NQ%dLi&R<i~Ts9>#@O;wfb2iA&1m=D&P)U?&rhutvJu)t0PGq6|G!U0rf&w~-(!
zUfT{SjenfHsfXp}&mc1pe5b_ghx)y=S82|I=_l->yhM~9DiOY#0)#S|p1+%Ae@kfU
z+7QDOysWF@gaNWPG_akc5`&))wWW<SWx_mqZ`U<CKY5ljqa<U~k=>EqprJLtPl*js
zj~#T~L8ION+_f8!$d7?JAB1|l`S{W~{FmEzBf!7imYb`^y*$gaPKhjC)utbZ=Id*3
zx1kTJr3CHdZKSKP{k6yI1jS{q_rlAM)=?s+5|;ZMNxvtJ&7-2%6^(RLzb7`o{E(WN
zMp13rLc(Y+n2b70k`~ZYKU>H7beR9!DdQmmjJ*OwfLGenb&)jejREEcuNr&}CHi+1
z5EKY@x?WjJ?XvWvq!5qw2b>`4&%O3z=OOSQd5x(lUtDQUrA9kh0uU+&+LG<@$KpXA
zrK(#daCy*AmQ(?JzN`S=clqUBYa2Aqnl8$}dfDRz3XQGaYJHN($6+_yTK_Wc%aa0V
ze)_Oc&2GJ=#8sel-SUZR9!l))^(IUdkb_$2VXCY|L<Mo2tLn$|iiNzCP*7VH#K7!+
zj#&BGxxQpv*(NJ>Hs(7o8h|b8&Hmz}*yXt{x}`#3mzs)4IeE*(%COwR#(yo*UX~3h
z!|?yOBx;V~xEFAVTW#@01KWo4@as1#xT2-?C#K=E&gBEyb<Y6m$-6{{nNXcqI@T}F
zl)<<X@M2Kbb{6KDgyvItW&HaxD7L9v2ssg$yJtyGPd!shUux7e)R7;Wk)|Vczuy8S
z_t)guRdoMp01D&{&ij#i8cd1X%R(6o(fsJ1&INhW_FdXr=3^+(F~|!4LkV<LNO^59
zd*u&YqVlA;U-st`9DX)!9a<Y<-LY%dEs}IeUZ8CgqD2o8jDR+LfA{9+#%cSdx7R$e
zcG+x^^ZOho-Jk|VSb{eV-y1tTv=neavBQ~qXD%JKfN+k97R{CWcz2R-9->8lhwtA>
z0z8ZJjHG?p&*_km+?s??DGNR>Fw?st?w!20ZA*)h5z76_M7BJP4iJ^pRHyKYYzuM8
z)VrekNf6QV$*YqQROyz?JKD^)7%;a&U3sx#YS*t02?^B&Y=wG8T4bAo_&A^yl1t~U
znbz1p(Uo<EaJ>7hE`<niQMeB7#AUmJZ8AqSK^JrWHOI>{)1ap-a_jBZ%6n~GDLfEz
zSvev1cN6>y@xylNG2`W;&Rb#MZf=H+fUj7Uyp;{I9zS@ZxEaRMv<uN>arG+X&@Lw3
znNQFRKhG*LP92?oYO0lAw9!#@fKi3-Scc@DfqCeVqvv-iK^!Dn^hIfR-%(dYkm#Jy
zsGz4CmUc&qhW6JjIP_x|Q?)-Po^p25yMC`9sIOc30Jg%Vdo0#0%`DYBV1&Cp#FwzS
z5>inrpXtXzZ0t6LzLnW<&Nd9wDjJNmqDQIqMa(@s>Hv>KAA0XIpi#3*$qVeEoBWK6
zgJ1H>U`P#lS`=?7(Fk}Lp4<}Ff7Od#QQll;MImPe8LU2>r*-9#yM2e$+NL+Y@EzHY
z?G^S08);}2<v1$B>%<UA;8XoGT8~R6;*J(C9$e<ZP*~VAvESX1DH~w1v7n`mZCo4<
z2VR+Wb;Vh~os#P#{q@6P2wY<KNo5e=LT1!CIp?#P-q*OokM59`+U!I7$-$plUdVl*
zOVj*|x6ris-KayfJhLr>^SIbrh{K~`cepviCsYa5<MScLAK3#~`&luPHlq$&&C6y|
zX*FZuJ$1SB(5w?WCYkg+t`9}u<WM&IimGyY1LufbgWd8+qA?5AHEc9{!)mMy_nH+g
zt+*zC5Zpj|C+<((G15vHi&iH2Aee{B`1n>d)Kfv`cx``|dX*UMqGpId&p$-Y6ny`h
zbZ?V?P}RoX$gh|6h(>vlwi`(?W%{CWdZ+@CPJsa_dYx}G5;hMsp9ZrpmjCog5?w|@
zBekU5X=gy!Y<03X<NZMN%;U~udk?OLH0Nw47g0Y_?L)wc6ZuYn8ZLTlJ>b!LNhVk}
z!%-GysurL}jx<#F%zfQo<Y0nvkLx%j@wHu8-K~R7a$KaoO@Xr5R?6mI;JOZ`^Lu|z
zEm0>^O^LYL(v%WAL(PgmdLji7;Rlx5xFrp^i$i7HXW2@yUZG$G>zrtPQHYRXy*!{g
z`*rvwXXo|8(uIxPg=1}X@XbRsZtdKT9WPvn+V}o2COafDZelY5vS?bK2A{KJyqM<=
zM*@f%i?p?*SI3g9-8l8gC-r&+=%$7h$$91;<_QdVo?{*QY;ZF;OAFJx_k7ji`KVB&
z{iS8?9J1KrQDGps(V*mxlHuw+ZZ*whUiM>{{^(ESPmA%X%$+;C>HVfMt`t}Qu`U`I
zRRm0ExZlcc;KNl$fG?J~aw?IwAl7e!wcqep2Y#zy$pDqYm^aen)QxNw?E*QGh|Ad5
zk?tH#4h9y<>me&ds?HTVIzfY=m=JzvYU~~kebkhSnHwYA(wc+@X0lWXqY`KkWgTpl
zC0YnSI(+}W3S<GJ>*Q^C?M5L6{GP{AQa>=Z{HQN|b#{_`Gs;ecPKNc6qDS4|zE1`w
z#rI<F9vA~DT2S=Vp37)dlas7C1Q2p}N9?VK;0N|YDcfnt2e>5icE?4oau>sH;=lSm
zH7H5pghXyVZ}aB7nhI1htdBoht$h-mHiEKRiyj$Agt5b<dML8b?k3%1-UKBzdMi58
zpb2D?8ND<v9^>&a-(BaBJk)Aw*ez(l8_kU&J*mBqp(LAcQIyiOYYIn8jgmtND6~=m
z_0rVAFK#XxAKbAul7vuW>CvR_B^%UR+%I{S`6svxk?L~l6eM#l_LStz;ueRztEywu
z`?+{A8$gLw|5d>keACGO{Np-=PGMII{?jVXRHZ{sIUeJwtQ61uVUKT<x(+FrJ1)SF
zpwg&E>Jy`{$__aqCCu7-iAW2|?PAz2LrGZMG$c=`VI(*$dOJ&S*+c|^zj5K^@a|3q
z7Ib+a?s@TYY%sN!gh}aie~wuQ#~5>_;^lis%c6wXTyv|zDD^vb;}_IG^7nL1n9m6E
z^7wGDX1q@p+(TY4o<b4O5(9=ieW+va^5-u^IQWQt_6*lGGi)7sU_{GHD%21m!%tll
zkPsQNr7wyc@mLbnQ#4yOBL@i>ar%n{qDGCtCZBTBErxpo1WKQ{+$ojnLCMv)K9u$>
zXLmJeoPETE9$#~ckE|BC_lwe(qtpAdi%9taLD$a-(y0{kEeasT9x!j-wFN8?6^w<L
z25+~X4vuZ|>bnMPRZ1Z&#f3ic&`3aE?P^OgKT$Px&|Tzwx=j*9`7u5ynx)$lRA?(N
zpcQ$)XlC?+Tg}hG1V#K6U&sEw=BL8enq@&u(eD%Nd)ns#Y*|tq*H#?p5z5dy2NH?x
zk6?OD(X%I<p1ixL5%T&cmHV{{VqCiKEmUk=f&27H?Q2EX4g=nwDB96~tu*BQ7MzUg
zR`@>2(fOAK1RY4pa^fCE>_(dZ={0Z9<h~i6b+rx;X9SxidJGg8*>fSQPQzOT!U=Yr
z$Y^ztM7$o2A6kbmg}z_*&wfO!7E?sIFGHx}USPF&mG8eYse(8UCJqD7r$Zxxe<Ipw
z?4X);?x6p3srvCnE4sS+v0Dq7$z3-M|A@J_Oa15hpHCf}t~3d9Koj|q#(w)|+`?Wq
zcSP)grIC2C=k};mR5`Ot`az6h!CL(o$3@aW_T5t08#i9KI$bSQXwcFd<f0evaMrVJ
z+d^^NLCmO#o+L^7ewJ1|t=15HDKf&vVUb7;So1j^Bk6~Z^wmJ!ZkYCW?#R_6N%Agu
zU;^(r!~$d#gaIhQ1J6i<`TIzq&hr22csSd812N+83rX#EM1z3iqqMRVSi&^;zW}WY
Bs&xPW

literal 0
HcmV?d00001

diff --git a/doc/assistant.mdwn b/doc/assistant.mdwn
new file mode 100644
index 0000000000..0147f6ddf4
--- /dev/null
+++ b/doc/assistant.mdwn
@@ -0,0 +1,38 @@
+The git-annex assistant creates a synchronised folder on each of your
+OSX and Linux computers, Android devices, removable drives, NAS appliances,
+and cloud services. The contents of the folder are the same everywhere.
+It's very easy to use, and has all the power of git and git-annex.
+
+## installation
+
+The git-annex assistant comes as part of git-annex. 
+See [[install]] to get it installed.
+
+See the [[release_notes]] for an overview of the status, and upgrade
+instructions.
+
+## intro screencast
+
+[[!inline feeds=no template=bare pages=videos/git-annex_assistant_lan]]
+
+## documentation
+
+* [[Basic usage|quickstart]]
+* [[Android documentation|/Android]]
+* Want to make two nearby computers share the same synchronised folder?  
+  Follow the [[local_pairing_walkthrough]].
+* Want to share files with a friend? Follow the
+  [[share_with_a_friend_walkthrough]].
+* Want to archive data to a drive or the cloud?  
+  Follow the [[archival_walkthrough]].
+
+## colophon
+
+The git-annex assistant was [crowd funded on
+Kickstarter](http://www.kickstarter.com/projects/joeyh/git-annex-assistant-like-dropbox-but-with-your-own/).
+[[/Thanks]] to all my backers.
+
+I blog about my work on git-annex and the assistant on a daily basis
+in [[this_blog|/devblog]]. Follow along!
+
+See also: The [[design|/design/assistant]] pages.
diff --git a/doc/assistant/addsshserver.png b/doc/assistant/addsshserver.png
new file mode 100644
index 0000000000000000000000000000000000000000..80f5d56173d55e7539cb7c8583672e5831902606
GIT binary patch
literal 31740
zcmbrGV{|3k9_@FWj?=Mic5HQQ+w9n8cRIG6blkCRcWm3X{dV7Tan8B-eR$)2$k=04
zR#mOFO27Y{vnoVhRtz2n8wLOXz)Oe=D*^zZA^-r$JTxe939n|;XW-8VJ8=z1000){
z_a6u#H60VU5XwnHMg(dFngE>}TU?{Y3jiPlNC*omyDgox`C8$ad+a|tyO!()S(-+U
zoCb4z7q%%P-P<z6x7z|Ok+d@=mjO|Lz`R5X!B7`2Cj*bQM}|=E6(U8F^o{QR`cZ#K
zKuKKqT!4uw9wR$ks~Kz(`qxRoig6Kt;1B`JN8|+*1}F#mY?lJ5j6=oyo7XOat*Bx{
zg;;A1A3nzB!L8?Q_xAJacEn@4;-fh=J#UC_gwWsIhTWq`fxm>5S;*jmNWFC%V1v1O
zK99R*S>AVj7<$nHzn8K~Y7%%|jN1BKzuvE(za6OF-_|g6yj&IXzfu*6B7qBP%eB9r
z+PW69guM2T^F4?65(76`P8aJgNt`vwMk0s=Zl4h|qIBbl1l;KsxxiyMaGyWCey@rY
zKMrgQ{p|`1*h)~IkL2H-0pDf*{g1yi8!`i~0WSED_5a!De>VH``p|!F_LuelzjyP;
z*8b?`Uv~4)-u#cz{Il8r7|lO>^FKy&kc4Pcpk-M8_O0qC^+XMiptiw7j5YWrOyljW
znw~Q*7bj<vPuvCOPnI>fZ=Wd9(FwvMW_8Ou+_DQg{So<<spX`Y%e-IhGI~OUG8#X9
zVM%ScdZ9&Dmo<^9n@`*n+&@CeN5kY$*3D^w!QG;V5M%GQ@8@rmw$$s;-nZk*+a$7~
zxBbkA64_9lKi%KbE!d~Q`_1JijSLz9BpiQYXy?-+XqQf5ufzv+M)DspRp5YdWPKCt
z8Nm@S!wRJord}9AP;AD}ys{w{ZDC@a5>jczy+#}0`dp`n299Wk3OTB6qr`*&TFlqS
zLPL7=2wcgm{J}J$(NDcF07id5!7bQ8>_Q7gKak$Qv{Nt;$nZyEYZpX~`-1cvwv1Z6
z3YzqI6_q#Ch@a7)L=D69zUA@rk`0S5QhoYy3Z){c`7W-E`t^s`9rj>8N}X{*L$lQ3
z1y;1gxjllM*1{QswHTr##l}sg=RPTUx#8D^yau1E`>g;<L-P?>fx>w=Hm{UUMPlE6
z0K!@QV$BCpH947QsVY(bmul`>%<@b?=g~C=97#-E$@AOJnL#^Tx?ly!IU{y@*V)L@
zQp@u3(*jO8wEF7~1VEYj@e5@FH(iE+Cr;~b{o*N@<>Aj+i<(uY&PO(Rx>Klche`U7
zTx|lZaZ%r6o2IX*Y8wpL5!F}lzgPqC!`;)?cL~DX$H%93Mx!+$hX<C!2A%TNK>*i;
zrDNP&KDS=03j4}RFlFX>Udgk^RTmF0@t2z?{)&gvuCBc`Hthmw&hA?5yZx<rX$~1;
zsIMNon|Y-ca-+vYDYn=>jtz8~@Qc=7kAw=jg;rSZ-24cq7}Mi**bkX}P|1-BE)}V>
z;-L=2XfTDaNaOnW-@T8@U7SSvTp70L_UIaY>Tf1(3F5~9GREhJD-Ymy4z70kuY(l(
z({x!6Up}pHd~IParNU27pIvKpyA+c7iim@Orn$a`53rp%X`cb@TPhsh?pb-A)%3qd
z?=icAcaaZ%-Y3xjbP^JRQUJci^(3auo^_9|(FHCa=Ai5Awk~{^hh9mOoA+)6YXxUy
z3l13IuKPf1R<mqFyAu_M_PGHADH4=mG+%CM3AZUCVE|_$mG9+3aQJLS2f(0Pde4&U
zul$8Ax%9RKs&`3bqVCY3rpDAyvoKXLd|c*KBoTyXeNo?u9AH?-$i|7Nzk=5~u0=nw
z7lx4*`+0&Z6;CYw)nj%uZ>2?Ynf%<s1#vv$G7@q5tU~fMk`h8f&%-5Np^`b1JJPKX
z<iv*7QU(`L<-x+nIgh)W8Jm;pYiE0T0oQ5m2O<mU2jAcwd_R%nYjn`=<Fe{o!GODu
zAZZ2&Cz&HccP(`R1SQlQDHLd!a?f#m#nHMs<E2hHcV(HX@gprX6R(c!Tb0><a5xob
zai6fNtY3p$!f0!WlH9}EEfA7`hZOZ|iNi@V>Uy$596*fs9EV?6<&MH|Wd|XxueY$Q
zwP!k5^;Bj)bcc8}mR{V8it9^XBRlMSbE&PDg$HiQGwS9}1hA+?THgQyo>h@$`-4}n
zqD{qIG|tYut6SU2+RF$9tY;!T!0|SY^H!EMzf!B|N#j|t_>EZ0*Pua@er^w<TXC^M
z4NrEct)!N2uokN(E<RFpm+(+(Jdz2<Wr+?F?f@iDX;3r8iyj_;xlxAB8cSYp6l4Zq
z<Y{1Pzr$?wWMlleM(_hy;5ouJ)`>^gv+LUHw1Z)~1u*4lA5_?0YjS-XvT5%?j=oeB
z)92J!7n2FGb1||=r<t6dc*qO*qT9<&$%37}HKJLmq-x8RGc(rz4O$R26rG#_bQ}bb
zP=nvra?WiP;h5>x>{Gn63jr3#%+;GJarp|yTw#2j(u(1E=ye)k8_HZYA!C0%$O^c$
z%GC4AH%Tjb)NI4LMT1IR8vN;VPvWy;;l4FhDOz9UU(jBsO2y(TDywTcT?7^h<#*$Q
z-noHyjO2OA_AK)62^r<J-p>m^6yOwpnysk||CT|^IKqu^*Inc^XHNi_Is^ke8MJ&=
zAv5REV)q=gVETeJeC=G&WG^Al=c!a^cKL)+4pLGCUS-G}Y6%9$!5vnJfR|};`lMuJ
z3n_{R+i85zN;zBOhimGO?kBj+iA)_~ZZuUjY6z3uD@1=on8F{HF;{+7(rw72ho6eV
z%7SKWw<g}MerR5kj?ouL&#GbZ4k6DKGg^Bz`tw{aqDAkF4(x(lj&*Q9ad~{8414vp
zZYdx8wyaLl0B`qR*VHkHELa7Ql7t3O%{-s)p8LyKnMkci0{n#|GRsWjPn|C2{M#;u
zQJ{BuN|^T$LPr_uEJ&?W)t-L|6@_0d;_P$8(a!c<jjS&y3T*G}QO4nK;g&&R1p|75
zziIpP!a60KYY2d27O2IB1_{Mjc}so3RDLWmS1o={YMi#1Kh&^Is~8GvANg73kOhnB
zig;g5d6u<da)mm$PjNPFvUcBCF{hcoQI^=oDEoEW>r9!48_aLHb#$d7z>2^!-R)C{
z?xX<aefd<qkJ>|KebFTF@Kk4@gLy7<IB1USO;N>ZaDV_JW|?Lx^1yd%j)i!TZGBR>
zc@TA~TogPQ@b71?7X2X2C;;CbVrEl{2Li?dJ<t!5#vreU`WkS2dDz>l%<)l^C@7xK
zC)`{V!7E#jjnwgkkqz<nyH?u2qujD_8)HpiRt&+>6(8pcB~0)4iM1T&8X6;Xsy6pN
z)1SqE4cLpk-7(=xlT{M|@$*?IHqs4|&#@b+3_MaOXXwy%=AgRwsjJr^6jz>_mVItC
zvZYItHj^tZ1e~d#YR(>7Zq&b>)Pf6?;xlW4_2PB{q?fbYk=P?GUp$dEDc$8k{JwVW
zwu#kckpi!LhI8KTPC~yK1Bh7?fatY&nW!nncMIw^l%p?2W?y|K(`ZlO?;5e^TiHH2
zau1S&?Gq?7Te$Lx^&jhrZx5q?${&Z=id(x8yUrK5>DE;*je}<ZMN(W0q#fPf{~Y5R
zY;go?nwN;)a3&K(flikYH6MtGW3kenr{uDRK$yY(%T(9J>a$LSe8cUn&X79N?5i=$
zN|Ig$S9-i>hvxDOltjl(?X&?iSOa1xMUj)HLyZCmiW)<@oY?o59w;N-_j?S2F<)sK
zzKpCkET+MysP?lZw@B+{!$!+(#JI^lf}F*S@?U}<Ikcn_KMv~K+kyY8r}J%txq&@T
z55+B5!YQSUpI@oUYLx~}&WMc9?(lYfxv@j^dtbX6qA0d$`^3xa5zX5vvDBi~T7yG7
z>#%dUk=NsGz)+xFZ^acBccWPyD-NkQXI&@PWF^yLfAz6bENmR=@?{cMtHYG^#xV#=
z7f^HUIeI?l+P{+IG&H8+G7pKJ<ietAb6^pGT`z}s0s-RY8rHvBca$Lk*K6-mF!je>
zRj<st&3`B7rdDa7lcO7>riDSyZ`mWQDe5?5jOvXs1ymQ37)tuojKT~|bxnqbZ?}fM
zb}^Z!>~#@ke3^Tn-<Dr`56~M2x(~3OD_BWmXmGKkZe?)@(|um@0u+J*6i~4O4>bT8
z?373CdJ4<PYdKP**6l0h><4$6J=5DT?IVvXf))7r+U651XZEQq(i0^jb;+|5HcR3w
zbmqZ*R|O2HyK;_2Nfcyom5iDL=Z?(eqWPn%Vn^1Z57XLPyXI&O&JCO`wo5!S4|j}*
zTC4DV@>J<?l@wexT+B-ss|~akx%tA?id3MTKNQB7y%BoI(u-|55fECap*R7qCoZQZ
z0Y}&sSj#UTJX0kATU9A~xAt#~L+1G~fE?&Rg}Y;wpg4zf@1?oV(V2pvD(v^o%M}=`
z{djYAC-i;>G~+iUMIr+uBJ(8KGv=Q>J;)6wczCSu7iw#_)~(9V*Om6MF)~M`_f_<e
zf3fpfzc~~U3IT55oCI`B_3CY2b>f7+YI|BXmG`$qDif)~b{BP~-oW*!M)gxz-s3jC
zZuK!sxJG^r4Hhi$na?oV5bh-e%V^zR<sbU^HAlT=AMr+dc~nGsfp)bT5Z}8L5w3p{
z+ic3_&!&VnB7cF$;riY!%gXst0d|_ks>V7DjWSdqx7k>D@bMPAyQr|3+FFS!SSb2u
zQMtV6Vwlj;_TvV=-|jE``B)(p4+RKGV&RnjkcN!2jzS-)vkKo)ak^3T(7sSV&hg+e
zLmBH+@T?@j!FeRFt{$N`G)&<zah^OKU-CLHPoH(}>mvE;y#GPQI3J+`y};7R7(NeR
z?5e92fAL8K0+V9@ERF*_V44gWVzbNbBF_g+fq6SKmyl>iVBZYm=?wbez9gu{JpP&k
z#ZHS|zq)yEL>BCo7fx`~$y`v_{^c1Y{lf%inN49-?y>Io;%nw1GmJtw<=&+psUKzs
z{j0!DCn&V&7l8yG&=CJo=(!bMEqao|{H`Lw{_pkITD2Fsz{uwjkOAwUz7@+Oz4F|7
z)6N8SPq4<W@-_p5>(g<!5?<qd$OzM#iZcw`mAv_tv4~9JdA_WKduFNomwRGF^7@9e
zQB@_W(U5!nk!R}M)1Qxu<+)HORhE<sO)7NstuPvEewGzZz3T=-QiIzws@JFX7Bsc-
zUe~$q&RuiqsH3uEp1v6%E-K!)%aKlx>|7P=DPF2{w4>+3qd1A9GH-*q-80*sUETJ@
zZ%Da4YKzx%ij|L=<s|#lx0XLOri)cEbOUHBvOXhKfX7*K;Yt8zmt4d-Vi}tX)*rs;
z8dS1U^ko~K2iY1h66lINvU69gCwL_;teIvwrpba;1Vr>b{TyRC3^N{$EkZQJH*Ehz
zp*2?8M-tpr&Oj)X+e&zAO_oKQ$YtqVXCyeB(xM)HwA<Qs%>)BE17D6tbMGQwyxy$x
zkzQPKhJ}`<3VE^$KEHajT*)e!Gvw4zgdv_Z0e>R1Yl0X2ilEM!ZiqS;Reu*>RML|I
z3vI|K-ZDJKK__2_e65rYVF@;b(ocw35xe%<w5)h=_O)It%Awi`B1E{73S99S)43ge
zxu7^z20G-!&qhPa4>^oQo})GzNxR1J%+;l>TsmKL^~B0=UxT+7TL(66+SVg%`-v4~
zDUCtjj1A<$Px?cx`=I9FI{7!9pZg7ClKPJPGO3zY(i5)%es=L6=qO-m89UQtY1;{t
z>kB2o_fRMb-58N;)ak|ohyX%on|JQqs&ozV+>Uy_m!Jaf>jYuwQaSy<618o(Ee~5G
zN_`C{PqD&8brS==-kPCvf+e<}JA0mRPa3LVZrqUh^g)%0bO{dnSgJZV6VfQGR{B0T
zZQwLem&kq7#~JTOjeI45;E~I$4iBegvaXMkrp1cfAMyu`EPXuR)3}!2mn7c}NY9G}
z%cjR%3KH;f;%W|j^wB3KEs_?e?<{`&zMe&Ocx%<STUFwuK~JqYaKPOlNh8PBiJh8A
zy9x^|(2V-<om<+@^v~L9T3MRR>wH=hQgywTl*Uaj*j=kEY!f_6_ddP}6yy;Yk84l=
zW^ZV=U4dd4=x|RpS9Z*@58anjjjqlNFmr^eQHkVj?QQ#CFWD^7C<{TWz7!F|*)<ar
z+z1XAX?#KjkI9&6Lrrwn5Ea!R*&W*6x=y`X6rs#WKXkTkAWmpyFz3OQMHq|lw1TU|
z8CDiT-X9|OJE8i%gM^{YSR<Yn)s}rIGX_S8{Nem~wRIVk5PMvOA0djq_7wLDr~O8K
z>CvgpogK~Bj2pJh?Cjc7<G8>4bA`;_kW@^Dn9i~29jc*Au$C64LAHKp7nYDloOO?5
znjlXMLr^z!2|5H6*)wmvgP>qefkBlx5886oXz7gA7^!Os34LNrf=Kyjy)rWWr#Kv!
zFa!Y}jb9J@1iZ)ED`aiaamo&a%8;LrktoAu&E}(s>|`ZOc0g&-5ei4!2UVoF^lrt7
zk28wJJt;8I%Jxpb8>Q^f?_aRcaaM6?K!(_zHxGrU)+%g2^k~@jaqw9fdLFq`)`aCx
z7}4TNIMT$qTvH(hll$cfMLU6~IS`s_6nw!QG*QB}9Wsf9n%H5I7(S4uPou{Us-w;I
zQKFA$U1sw#CB&9V_&k}SB0CzIO&GkAcUDxHKJ36Wghi$H#`JsMAq<2;q@!9a2blUc
zP;A6u0Um{Yp0<mN4_{2jY^Ff{QrN?Tj-eWq80Og^z|z3<_e9Q5HorU<e=+sDg94MR
zpWYE>wvrl6!{r%>K;<}uV&yC>9o_Gv!Q4o#pL6jDcbWF8WywAGA=H6KPbogb5}vX}
zQlrJDh8B*FWLPya68LOr&1P@yHX>bD&uvy^#6z4No`>O3PKEegQZ7NPu*EW|l_~bF
zw>m$9x8`d=#Pl8=UjjXia9@*qoYx3<7v~B9EVxSDg8D((dR13?ylHOlu639`!DC3b
zH1_aQBAvB|G#5G`T<Px7Se;0m>sy%_p~mT*6ZO!gI7N-?$(R$90ak`YVYRBKF9v8D
ziah@)oh+o;Oc^HivQ@?mFIu9bhO8(j@I2Ks)m7qafd<1is?(l=H(zEOQV@Ao%8(ml
z%qxrPk51&|<bMA(!!cH$ggDxd6<EZo#&!DI={D$++Q_b&MC^X*W%xaUbJZo83|~tH
z@ux0iGEN_y=3Z@*zs1ujokFfySmcMa2O%cIE$@Mpg`yDl<M=b{@`*k7?SZOSyOSR|
zD7_#G1$Yt+JK9S4&<UB;QL?V{Fhk-?jxd<m6!oT}Wy3HElPpm<hCTi(_Vfmo97B)B
zCebClbs93Onc)akmVVa3r>^m6y}~WD&4IM!I=+HaH6uS~uL!H*vZFa^D;{v)2I->g
z;yG!{o@u?yI7dHl%<zFc>wF^p-&0|F>_&t)4WBaM*6qo8eJPmptAg+7m#5)v@FW5V
zQi&Mm#LZBgf8+q4Y6%!X;k%oc1h>0&SGyr~@Sb`>Ya>hDV~DV>!3-9mDs1@N?;0YD
zn|S+2s*k7SjKxCyFjjJw7Z1-zgj3nF)7zKkNu|5|zMmW@czA4I)CD-W(o>a+bP39J
zeklb^#+)?so7mZa_3~iW6#K<Qg{ofTjuovQln(IVE-yK7uzQHkm=HANunY;&MTO0N
zv-;U!uZ21UR{};D59<vfG0sFz*K-hr62s^@U^w@!%}7GHJKU%7G2k;99ZF@NMjcIH
zE#XvLb5i#ez0@$JZJzX_)X1^raNV1C?l3F11XDm1zYr$^k%|l*9aOCQ*s8)w<Y<DN
zC}E!b>Ui(mnH~ME>G?uI?V+E@LId=3YOfbxB}p48-T-0V%)+A`pSBFdh+%(W7+UtZ
zhHjUiu@mep_;+PKd?roYA%wf5`xS_UkBibv#Xh99n6yWyc<a*)b9<XbrXmFUi*RbI
z9}Pd~Bkg|2zI{r#>F)aBz@kFw7-`=dvxp!hp1}Opc~U<_KNCRaHWpoqegAoFpNw}L
z>!}#_=5@ce+GC9kp8^z#iE<z=#+p^;FzC_H5Nj5-IK;_GOC&lSDlJu@`s%LC*uK{k
zg3++XhD=ZM^v*}DgA>H@vM%w%Pa$1*K~f55xqw~m#5jd9@usUJZJL9ZQd?=-JvP<E
zZmd-=2LV(`&9K4k%Z1eCs9ThyXGbr>yvg2=`pKc@)CZefFix$`En-QZHAk&LbJS-R
z&Cnmu%Ei#xO)*?;avu(gWXdzHF_gL%f7SEh@*CW`jHkxaSkqBr%46Q0j1LehOFk*A
z!>soR9{QZSwER#chP0FBbn##0ypP`r{%KiL_Tr^4M$#|moNhG9I<jYKhLSeE1d((j
zG|8IM;0@vL#jU6_Oi5xrUb~ESQFG}z2vgGFnO9yY=}bg`X5Cilx5`<AzF0rTxwwWr
zdwA;~lDvh8cV0X*efD82sNq)YlDX`1EFG%JPA;R6msv_TgD;WC2<mnk-?)27a0=VX
z0@QqFh&O7bF2W9AMUvR|YgK`Ug4>Mj6c>{ot_24r+E!M8l_s$D_X)OtMYdm^9_}DI
zl+ZEK+FsuZF@BBemjjKAX*}^nvY77X178CZFAQL;=UHf|6Bt-FP4j?s&>Dh321tin
zahDB538(+!mu<*}-~<C|l|2{?x-+RqjM7s;w$OUEXa>#>;8FO?Cspq^<Ag)9ux~1O
zy8(gRDnAxxbJIPB$|bNX_%P$e#HKQBOi)j#z{nI1FNb1v#6?9K+*z?Aq?gCNRpwMC
z1kaRMt0*|Bnu`XzU1VsQ2+iTySijCJ73^4=a9cuYaVsXO8Azv{4$B;64kvy4&lBf~
zOJKaPeQrkRebn3j7j)mrmZHVNy<6b)q+K*quNHriEz9cT3E0P7F8h1<yVs!mk7$+t
z%xUzR)e=}+qS8mM@Lc>YqLk;et$}MAoxl9DV+c)xaXuBT*ZoHS-|mvkFS8pSIiS_^
zKaHWS)nPO5wZi?f%lx+sfh`q;%RWsXjQ#+_b8F@5ZG-IBJD)1e_;Gq(t9?XeZ^pg0
zPdQo7ifiks@bofPdRmLN{YZMHyFi3*&|Pyi*KFgKWFx6rG}mj>D@EU}8LqBFwQA>U
z70hAx*3b-xK7$7mx+Tr?DCSmJ-HBK8TmA5}tW1fk*r2H~zV6Tao;2>Kd5)}*N8>8+
zPxE))_4VBIkML@K$wA3b;E!`K7Br!cqK~D$kB!M-!f4Ja>A%97yl$Pk)Hjmnx^t8Z
zA4LmiMGI9HBM_R(Rj3K6S{%gcFq|ufuMk|Zd<TinvRyQm!o~`On-uB^=Sx^qI^z;G
z$4rVosgQW;DZFYHs>qb!+O2TfAHj#7R;-VOc-fOB?7OLb9h=9CDGHxaU(qf<e=P^S
z4vACZNe<R1Mc?m60ubHXabH!d<4rJ=B`p{4q5}jthQ24pL7-!9$WWl`A%$l<ir>Fh
zeW@a~2)7#Ct*=RZhCzEp39}hjXSuo};KO?uE1MdMgRhK$4A{>11X-UpD_zL7(ZG~%
z4RiON-Z+6nJnI9nz`_!vBtw_+efWlF;d1m&x#4~lj|Q9K$FG5j3er+#sCD_3b)F4=
zPRj;q{<2;VqS++Lvgy&~@L9KEpdE!yH2_3bZ%fT<!sU@(91}Phs){YCQV(D$u|Cnf
zjxsn}BL`NJenc$D(YPkQ)9V&|oA+jt9=uxi?kA=0qFvPHMY}ng(fCTN)%R$#71o*`
z0@Rss#}lAHlIzIUM(1}lQ!kqLPbLqlC{+vgM>sw^wZK&|@ftB*(AaJZw^zo3!c{xA
zx^U}*e6>G6I)lt*739#xzArx$>B8<knw-j;Z@A}Sr2jO~5`zOfWM&KS=}E$u;?62(
ze+OU5!rl4?Yl<FnQ^n5GHb@5$7w&%cU_Y-11ou16M)l;vW-JT;4QtUUl}9p#MiA^R
zVM%CRx~rrek{o9U9%CfVGS$;*{e>G{by(9NgNz7VtSqYFz{gTTPZvy8Q!`Y>v}yg_
zDARG%aqbr|_1P1Pz7vlnjGoDW4f2BD!Z;1n&pTY7{ud=@ND1)J8oZDNsSBQ}bHwhc
zlArD=5hBR|2AAvy3#icxcPI%m8_;FbyyHp|o!XD0gy+~3w!{=Intmq6i{zhpi`-hK
zslM5Tq^wkGIRUl?h5Gs54;JD4{FQ_yN#+JJt=d~#d008xt$asJu6K7kXN>TF&ue(B
zgJWx8qDg3fj5b@}Wq~%iJ3xj$t~PvZr}{9*UVWH}`u@Xi{}!a9_dSj!VsQiGKH^Mr
zN)5NuhWdls=c>z<tJ4{&C>=}_$6PC$6b#qtk4D}(SoQgPoJ95AA@}UOyfj>erL73K
zVMP*r=u)hAAie6etgM42rOPN%JzbH@ElmXv8NvvL*7p*@eN4=<+<xi>jR#wzb(Q8-
z2erM9BDaRcYCp7GSQ`t<TG83i@mr|u<&WqI&0ltd)MZcA>uX2StTZn)N2D|OXB4Wb
zniOoTM~_*S)l2O(=L6*ysU?6X-qUUP;c>cZIsABWMAavEoH(sISO&TAVL5J299Tqd
z7(>B-WdRClKpe~ak82v7iS<M!nmE^bEgA}ypa4^YCwMK)86%+LK(ggtA1I9{faT)%
zyk;TDSi?4=FoXV$s33%(`AQ)z8ZCe2({ma%mct`nyU$i`(cEKXaOh&3S*36eD@Y~P
zX8~0Q$(11tq$K2PuIV8esctoqMb2C^^7`V#>FKwVrX4Uhue-UMb%Mj<W7rA(_uRb>
z7FnRp{qs6;<zh+>xhqSl*^{X$hXx6GGu51j*x`q>vNY57R{Xf!KM%m|1*{ls^+9HU
z{@>G6zqIkK<k09Pd9LcP|1YNRLVK01TaFJD4LscndzH0kH8%!PFY5AqE#+`<T=>uG
zWe5Oa<eXj;IbE&Fie#7^&O|B(dKqgU2fZdkOJmM-rItyJD0hzfx?MY)o0A(!n|$6~
z2gp4N0>r5ApIekHJtJgU|Ael!I(Cq-0;TAA_o7eA0tRxr)g)D#`n5ne@3wK3@h9Wk
z)@Ry^J8K0>=28SddHNeGNsst(PIi1l{BVtID)S-}9VM!;?<Z>P1!|mSiRigo(oRkb
zKMX)N59}<?bTWUz=!lPBCeHl&Z|Y28nzg&E`tjPY<}b<<DJV`A-)NLJRRD%=uugnp
z`SJR(Q`R*l=z7zFS|6R6Pp1^R?I{%Scec~MU_iGfw^rf*s0oLD>!P)-z4=!nE$^SQ
z=8**_G?tH~Aer(VnkxilsvdTY54Xuq^@|=F_$(Us*&^9Eyd#I`On`p`17-MUfxJv!
z?lNy$EbcCOKeCu9H#CvT*aKM2@{o*#Bpt@=RrO8c>qmuGn8MlrV$;-QUv7%4zJ&Pn
zZELN_R&N>&+$s%_@P$&X!6em|whEJ-ZX>~cvx@IAeG!X&8OxM>9u~(Qw7N!~1H8?+
zQx>KuNPRhDd^MDH9Xx315mv`Nmnf>X_ocVR3v<Y@3mMFoG1kZFHCRs6$DlxAChp05
zMyKg&^gJ+<YQTn(dq2|xzm<OgN(ftq79_AJx!@aqxy#Dm0Pcbe?Mu=tZa^eVPv+|*
z=66X6{v)jzOi<2k2KL_SH1p}q6tW6g0;$X@|0i=qCWGAqQn9ARw?AVe4{vE~tR{W&
zuCW48x>I;fEtvha)&Jl8`EVC`*6xj>ab(t$q@d^!*<j1*FizrXO@a$p4mM$MaGe<%
zWFT}UgKC~vU#T^V(7oT!LIYyor;MmROK%#02r}^xGs63q4H9GuKS*nS$LP|9*OxYG
zc~k@AA0q3{WLbOjJU=f=JG_W%F-!P-tA}c}6hDG={;EBlZ1A9%FYtiSG*SDKx2SL$
za#a_F8YnRK0E<|4758yiKmvSuwmN-yHFrg`WG+?mmNY*wyw#yvpzq<1wE*}iL=%RN
z&}3DiJH;DpYp+KEVnILoX9iuKc1<#}{l=9eqQ~Za$s8VZ+vgh5L-$NuFd<P&Q;a0V
zp7sIe^s}dBtzk13n_d|*d=K?j?jtPLwi?G5>p?SuXv+Br{???Qet7ANPHn7TeUd~Y
z8oMx8VO{p{vbJrZoP1nPe}(9Skbv!-etIZdt0RO?-Dcl@3I9h}#~$Shi+4N@81ZTR
z@IP`tZtPc!0XFE)5YFpX+qPld>{=;l-*<l8a4WJ@1Fg5=3!p+PdQ?BMNpjdvVaRUu
zP|+WQo=`68lJlN?;!6Loc2f2afk$kMnlO_1=WfvZ%fksAQ^iw6GDT|P+R}I27zpdV
z--&}=*|RcyiO?JcnqGebJ|TWWgr-iV{7g%!QhJ&n98e$G>s77(E&2FO)Jm|tZ7asO
zD)A1M4njDj4Cj-tk9KpNLlixiSB%%PX`qLgW^-b-wh-B&i!z)>Qoz;cMBDgrNsR<c
zo>qk>8(DHq2PDVNDwt(u<rCgWm`{u4#z9LTBY#$bNRs3u@mI&i5SByCzxt@{Difm9
zseA{KRon6B`@#u8ie$>(HU0_#={6nGhXHOBZ7oDe3JTJ-<;Z1BL+`zQe7E45(^t&c
zc_{S~il`~2&u8xt3Wf41Y<5c<^Ju}dXw_=@zqHb0FH-xzNS`D3U?|zM6oQozYyn2^
zVj$yjg+xtrf7T;wfFT3#>^YpT?CUPcU7BYl4tf8<w5Id#FXL+b<}E5l4U+#BS${bE
zBBhHjIml9X^6bxvNqWCH>~ytBP|dXRV`aJ3ZpOIa_3jVlJpxLtk%a`%e+9Rh#CjQ#
zJ~q+;g*m|x<U{$E9%L1^+9g_6MTbigZmbXAu2Lk0G-|AS%ph|nl{rx}G<E@`#GBr2
zX|7rT;q9iQfz3&X6z>`f(_tL?1^<#rqJU5+GiVc;diZf`$V=gNT$u4v%?Efr586|&
z=JJ?z&%sO~aRmD=2<9+hV3H?w?PSR8Z}0|`3dfYK2H0v8X`&_0ej^#lvL-F=U+C$1
z0fQ@^xhH2Rrp#`qvz4jckPi(R+7{1+SD;CY?6=lQ9V9&^)D*g?6ud}eV{P!gPnIK5
z;>-a-PH7w^EY2hv`o4VmE5EiOIr|AZo}XKF^yN6e2OEi5T54#Scx3K3|5cKyY?mMs
z3#%_R8Wwp7yFC&POdo-HxH=%pn9>0b3Y+={^{riO3U$k^VIbL{I!D6R7JDWkipt`*
zfh8qvV@^ry*F%-6#h6K()Tl&L05jN+`-~4}dne>{fMoZc#+lp!S(cvqnbyHB#})Cf
z*8n@2%a}#Fv=SImSm-KsQ`4TZ2~Aq9r3Gdj^#u;=wXK%q*j3Y?_M|a%)@QQ>y!;&d
zJn3tvKWEEgjkzrXfx`_59iu8~a$%pB;M>dCz_kG;ynwid=2cv8Bi8zdsQ79L6cuw+
zd7DD5AEhmD(ZWwutF=y5#by>J)DDVM!h!KWX*yG#SDG83glA3f^(Qnsd~RVF9YB<0
z<@WyodGD!e<zoEhP#k`g;>R#=>rh)&GwPt_J_?D|$YFht*LsdoH+g$>c(U8NJ-Lg;
z)+m=~cAZjZCsWzuHmFltc7KeL!1BS8p*}rra4Jz;t$cP)(I?{-Bpm#mNXHNUeF|d~
zH2%2ky~U-=<}d#Nq7y0Jl+Xj#NJ-H<m@<UF_S&$n^NS3i_Xrsh+fx(lKSCR&_u+D5
zeNh?o@Y`a944BbI0!_V>lh@j$N~b049h#CL%K+1EUw+Z3+!<K111H#ZTvU))clK&g
zU7N1;7vT1C@j!vMt^SpgR(Y-5UJJoRIJ6bfTj(Vsz}6+%8>mEIw1gI=UKMK#*Waj0
znVy+}PP8xO;Gj~l2ef-~b0%H#c8B^7U(C6S7HYZy-Xc1fU~y0!X+H4y?YaM-Iv0Jr
zX)T8Z)PD(N8uxEV+uODNXYlV^=*677p`(#km-00v0wnlA;f#K}yXVo46^$_rD~n$B
zd%Meo>6Gd%Np_#Uf^7r*?SqdMuDx-+Ka%2ZI6q^{YIUbLS@LrKwlF{la@UQiy39&c
z4)T17dHFZjL=NP9Sae#JB4hnbZk|0<wa59n+F}LKJuB&k$LyfQh9;;m70o-{j9J@R
zDwxbqFdoHXCaz?`5%-y0QPrB2?dJn12_C;goB|udhi_x!OC2+a7=f$L*PoyhVl(f{
zE^bE&?hhQqOHyP6P{X*MM~E3zn%Zr*ac1c<%Dqq4o8Etw%2zR-m^-m7oqRF2H*&Gx
zXA6zWTq4Ce_lVD*8QWL3W2-Jh9FS9QTdkRU(L7CdIDxEjJfnI%x^0-YG3y-fKPRIp
zT|49KaGSnVs>ODZv*T+mTMx}Lk8s`N`4xaRa&Y*o){J~-wvS&j-8`bl2C+JB^{uXi
zbTzV=D6U$*-B3%6R^N53RHVMlacr*vEWw%ED+Tf7OYcKbq$5x-UR*h`GQ7rO$juB5
zr32nCEJ)7pl(p6ZTVPP~w#%$ueo2c05XlYk_)*A$*}Lm}-ZV}HV<3=0f0+HSTt}h`
zMQVw3ohkG62EU4Eh(+W7Lz}`4;W)IYBn0&fiLq(jR!DS^t1qo91qsyT8>J8mt2(--
zC<&Looog`pL0Vr2l!=YvvN0I&X<X-*#2c{M@Q`6m`qe*T!T&&s9H21MYkkOT87Pp1
zp})ap;>;$cagox22qg}Ot37D331S#^E2-0<p*8<~zjKPpl_b$xA1b0V^Uv#mIhE><
z>Nd`UYW`>o?vYu@Qs;H|^n}7B^r@vW9{Y|rv*`eAemgs;uO&BAVVb7yX7eQ09|KMm
zs&`tO2bq4wyV@s<{G%Y!JY$x(Kn|s?KpV{4g>DY0i=FAT^Q19k=Yeiz#}h+eb6>)v
zzEDR351100?2{K;C>k)<OyT4M*?I>bmky22$mB-DW^SQn4EMu!eFzv`ZdBbj`$q&g
zI4yeoz&-OH`j+1x+2sEb^ZmcO*?;7*|CJ_Q>_fWtTX@1Z%<Mn;=rQH^y+SjTo$@dO
zSLPGNWz-(FJ=m4T7b^GkC5v`mS?hqrSQb-^y{_c@)iDDxjHI0WGuD_J(a1gjPv`z2
z>I3|#mft1IZ?DIt%Ma}~)|y8@d;uZCm00kS`!Yg5ve|O_Hm7K3`g+-y_od8JhLpE8
zn+V&hS=KS4@$0@>tA-YCEyhO$K!9)_%a{GpGP#XnA)xIJrm{HgwOI4U)T=$8bmm~>
zyWLm=aVcKh8Y<iOO<5${py|iV52r#0XR?U#tmO#~(rk(Sb{jp5pEmMssQad7`Pk#E
z*lOj=pD2Oa+KjnhZMROO)Z8hDrxKQIHP;O_p_&vYlSyGnxMb{a=b3*+Qc&y6WQP;I
z;Cj8!I|e#7HA85)ut^t$flU)>S+8L%So7QjE6ZclRmJg|X&5gfO9yf9tfgBjE=~1#
zK&$9*wvY~4@fY~ZVD}H`g$T6eP{h(Em(-58Es<jl-{a-}yk8VAZ_*MKW;FCs8LZ;~
zB$z5=j!YUvP)19s*0c(|dpWn&_A2!qlPazsW|H*mg}Xefp0KeQiGP#Q0ED<ELc@cg
zuy7XzC}9lH{S%WvtO}W&cO&%vpdk|j{nr!-KSHLjArnV&gbUe$u>)^WpqUhM8U-pk
zbry{1QK^v6u{q{<{9ara8Cv-X6gc|uqy0%|5MFXwRfbW`GD(*I!{2Tq0s7m7`);nQ
z^>vcY+|^t^g5(|QNLy^!Wj#`V70tXVh|M#uC*hn$YfnhZu=lC7c`KOGV%+6(cM4;^
z)O;x9HFYTm`!(=VRqJ9hO*|AnKlOc{*DOjjN(3mJne}7kESm%;9Ad?N)dQ)#@vc}l
zS`R@l=>`-sT+;A;@m!eTT|b6E+beJj*^Rtfyfv7~i@+Wr81ta%zf?e3=D|k{it~5e
z#>W9W>1Rri?`^7H^iE}PpCf<`nl@eEDJILPcp{0pl>uA?Nsa6TuI7Lt$)Pj7J&KK+
z0*vK|NP`+TzNLr|d!N9|*t+a8H_7hLSI<T01nH)YBqR}YN6`YJgTLS3+N@cFAVusK
z69kE2aIvfJa3z$K=(i^0ZOx&JVh{aCS+fvh8eBaJ4zu=Eb|J9fx&CQh$v~w!y7pm!
zX;5cu)11x6(7qb(<K~+4^4KlA*I`xd^`Xc02fsJj0E`{n^YZ0_gd>+7rvs{ZZMwm7
zt(Y`&2Wn^EnZ;Y9#fKPJ&B4P0fdPmb)6ix=hFFk(cki!{QJHWQ!kryDDa+a>eq<?^
zTpS{KEQa1EgL}in!%F_!!*>JPY<ju~(!6^h8yj%hrGxdGO{0XFzmh(0rl?5C;gI5~
zC8u3Z^d)f*nazhCa?UTUWV$ZSCdU2M87^w>0*Y8wW^9#}_DijOYTO4)7s)9WrzdNM
z18zI5FC*!zc@O|*TTH}zgU1llg~U{LPPa%LDwgUEm!sXK0)2f)z)0&s1~0Bo^iP__
zB5fUr?F=Q=n({J}c~pXw)#|2V{aQbyFcVX@6}-0l{6OH@ny|HU^5299Yg*8rlwVqz
zx4r7@85y7M7t3{nDp{^N{!2NTJofi=t=4thNiC6ZuA<rvY4f)L=Sr{}@l(_DaQ3b{
z0R4XN=T`-U2XhKD{Vx0FPx_0qZr*cD8U<x_!-S$O=6sr|3I_hT4okYGO}Sn!qq38M
z3#^@NGk2%QJ8++uo<N!NOk~HNzFeR(vd9vQM2HMI;VvT%AW(A&;vO_!8Cf{>-kCRf
z8aY$N&W}-uE+kJ|2R-_XUQJk~8(;#6<+<8uG}Nk<nwlm1kGaa~|E{Z*I~JWu!L!2O
z(TGf2*#yHQIt(;@@7ki=k4q4Y#4!ZAFrtbE5Cau?coKLXFl1^aX2#UgC=dyn{6}Y+
z290E=G3ho#^W)`17)^wii*@Vkpnhg-_4|!D>Hz&_-7H@fiyNB>rov+D=sO+J<zZUa
z`0+JJNS41SVBQeF6)<D!toeXsC?m+qT1+&voZKErcvxt$ASFj{Y|=@p3c3X~X^2VO
z;dqRs0yh38M8Ka&)NLhde##jwJV_h3Kzpq7WoLUc#_o%&g>^-XK!?SRRiz&AqHy6T
zbjhv3zqYfo9Nt`!PZSz6Nzmqk^Qa{$`^=E-G1uJ5q97k~Xd*YhdB(X~?lQ#eJ(kq%
z;x`Elg<UU$439jK4d|4j12ZUo>by33!FFFC>B~;@6I)z^8*bkSU9HN!m_UgFj(o`L
zU4kr6ME`7f4mST;$hu|vZ_X==IlS5QYD|Sm?hBX0pb=WH^pZ?NQ2*{7R#_o2vJb}n
z>PDy2ptt=WvF$DrWnFD%!z6Fx&lK7CJskUz1Cl6TUTE!d&3U$#r0BC8aCAqWsXs-l
zk28B#9h*VC-!acY+r=S6fUhpN(%`R$FMIM=YJG&cl#+e_vnfoyUz!dY`;Rm8y2es`
zU*hSNlMiX?i{S@G={^>;8@sygzY(B>wo0-KH<%Bb4}%8KLX~^9=>6ZqRCzgBJ*+Wz
z2F#df{q5$%2cQ=^cZ9=nHn|(E%ADp$iSB%tBBC46;hJ!KXUPM`QGnahb&~EWsdz?X
zTPa7i<Y55P;%G`&ZJpuBHZKdL$n;d5m8OWT+(I@^u^n97ie=9{V~F^v>_T~_IuEge
z72v@wx+W<qHwn~Q!XG?@+~^W6z1|NF4b<tx2q8r76QDH9yte0p6mVF=fbLUecXtM1
zcx`4pS<H$O{270f+m5EYn;tMSj!ah9HsWwEYkyo)(SEdY!OPiXqq-*?qH{|v|A+E5
zPY}WZ!qSOEqJu1eMHzC-v~N%KM+y@dh^%y~Bb@)CU061t#SR@x+$*Zb`)ch?qXs;*
z*C7*zrB5$|#Vfj_3G6?0Lv3O#Au+MOOuDWj6atb_@nW1>>&k~>VlBlKgEEDj36!x?
zVyA@#^UtD4PY>~JAUsJ6)AHbldgdz_Rt1Sc-H{7Kok1vr8JYE!!CQBZ5rH(^7ly$a
zva==6B;RLYV8wK^70^p?C?%T@yfE3(B1ErM_n5b+k^h6Fn@;mpf?FA(Sq&+gd@TZf
zZU+XJXFttmgqL&;_@4cQ-RB>AJVRg>x>983(PWZoY@^)@xAy7w&-#k7fQnjRZJXi2
z%Si?a#W#p>xa8v{!b{n{@#XS<G@Hwq`XnCy+<&}IxANUfbo`nW_!6BB=pXd>=Xc?N
zFR2xYp4D^B?=QOQdCjd~mRP)7<JOhny)Iqj9KSDR#X|#xfK<OqfILqs8<`jMFtoj&
z;j2u(TVvVf|H)QwK##xUTK%c2zT<kQqkZbGVtdJHHWwv1>VsHHq<^;pIU_;I?Ug>U
z>hpdFh6L{e^lm>Mc1ctEyY7bWLszfMhHm32iIC5RF3s+1+2Y33_g-&UZu}gV$Jy<!
z`!<%b`K+|}`<WnbeBW1N<4A^;=W|{2=lO`T{Ed;P?Gn6<Wfw7~7&}_KGN`zaUh9_J
zIjM_7E`UOBNN|SRX6JL~^#bIEkuRa;4JSJ-HaZ%}r1}{l(lt-@WNbE%T}51e->)D0
zA8g|riK<sV&(ODepe8S~OaNs{i1jYQz2<g+D$yRd>sKx|@Vt8{QZ4^t(IYK6Jm-Kw
zG9d;GhfaIFOkczZ@9w3*O^mGVu<?t&{nPyRPK@_(hBvH-oY#jGWdnd7+mJ8SdQD#I
zqa(8NlluBJw<7B|Lp}{!=fwDOn*644cLeSvaf~G~G4VWD1W(=`4NP@RJ6bn7Hf{ew
z#n(wiPX;;mGaPq34s--OHgsC@tW>fqR`EjeTGH*8DJ6+1>cOu{({FukCG4>kne>>j
zxN*nmi{G>>{1hq$g(y|cPU}!Nh%Nh?7BxaHkR1IMY)7Ua7oGD{<sM#BVs*z=weh(v
zGeH2^(H|b-0tAsOacJt%2-KOIZB*%i&Zh<aCZe(Ali=M5t9AUcZnRZi>v@z&7@2~R
zu@rqnM%_xqxmLhm&11_FB&opdrYk}~O?_|6V>1TzL&m`F`vuhd$Idp2-P?0-n)KHf
z+xN#gh7R95Ti@+8|Bf3Sz{88#_<PP(4}tFm^Txf;CT!4a%fk{oV54UIP3LN0{QcPP
z>*LY-+i{{6yw}^~wbO18zYk*LZHM>$@VU2K5Mr~9Fd<3BpK_X!%Q?f32U!=*-bPiw
zh7Fws#^beZWVJl&tCcanKK2e$;Y;_@s)jilK>I~|HhSyM1I=($mL%r!PEhh=dwT22
znR82@bg3R=)=IqNRA>dtK37)P{^J2CF-fg3&3ROH<{z`5UgO+IZIFjE-xGIAn?j37
z%~kF@i;#9cuGO7TW@c=5wPE_*nk6E{jO#?hV`AYLtA->*1oYz<&L~dQe^?sOoMd_a
zv!%`|%%S^F0ra(x2Y8)H{!K>&A;d?ZfZFfpWrJLZFrm&4b~LH+3_6m}sS{7tN~ukg
z`zpW!Lh5NF#I`<GVN!<Eg3!j6Lc<{9g0BJiuf(O3Pr&`(ae8L2W{+=^g4pNERqy$9
z{S5=x-&YOQm;LqqWnlfC-tU**>o#J?Eo_bI-En6RK?Z)|ySc#)1_;kf#~am~ls|08
zRYVqm`TenQ^xWzFj33zgJ?;JO9(bGqs&98SL%vS~>(3EmbTXXoHHAnupI4T;#pll=
z)1wxZpa+TQ8}&_N#0fk<Pp74emBaqWR^M7**KidSbcDFZMGzxKZe9On79!lec~MUv
zRtJoXYq83DsvhlIpZ%~MY_XOUwu0O&SFx<*`mvpmh4zG<r=+CjFsD7J99vuLxiJIn
zU~sPKii$YEXLUy761-BYL8MP=9j!%{I<69}4WoHzS@wn1lLB{`)Rj|ACsf+uzIV$Q
zi?rK&;P){}8UIt7vHht_`qRUA9AMUR&HQpr%ca=HdRobssl|SXFY9DmLy#iXK+9rn
zXM@uwZz9=qxhTmp?c3K;5XS2q*E>6>?3x_Q9wXCYU`780D0DgqQoS9lS0>tmc2>O8
z>~*}CJat|8BEP@BKaJ`=lLKC^-X9{?Uk&o--h1AkPxv)EOdqfTFNp6b+)u9W>NM}Z
zsQmBz?@3wjFxOaqdhcp_uV-1WC-*+NQe^J#zd3z|GxS>&v!hEKIuPRxcuHpiQi{&s
zsOD8Bw8wZ#`Ysfp@B5fA@p>KV0rR2R&qA=%Z=?uooh#lvDEuych$RFRh;Ylxx~^S}
zM@lf2Y77~v%~Lgdp#_Q!Dyv|HqS3IP^Sx8E6?wm4KuGY?+f+Xc=5H|lzW@9!?s;SQ
zN$&B4%K-*+!J{)3=c}hfAd&U!=<ginaW1P)E~`?O;KrJ|PUueEbqF%sp3|~HyIu_`
z3yv8kq#ty=EZJGDHCN<mkP#GG1|dRlQgrv#=u^Vjc`feCWzs`k|E1pZo+rPJHu5u-
z{)6Ug<F1zV?)yFe^Wgki2gHWs#(7_b)QG6N`*BSx0f9_Jfx5HK&mx+_rgV2&{pzbn
z<rN+e{;W`(vTdvRYRZtWUEN6jL^`uww)>)quW?am*Nc|XvNAe@8jdPTMTIIB5KTW_
zCF><ZN>LdV*>1GSNP(%TQZ$*GCL%VTUwHc;A;WUh<y0X#ZGzj>M}Rrh%s+Hm^Vr0v
ze`NuR^<Ioe0E~7%@}>9&Kb*5Z|AZ)1rxUMp`FGM0CP}avXR{9CIkbo{)hOj^YieeX
z;vPg_f8ugsz`{8Kmhq!nS<>IUYU*A0_gCQi`;YS-kE{Ux=M%@)cb{$ld!M_<#rY04
zzy?KD{R`>NE21ey`*VgZ9H29ae;`Q_Ho3LcfyQ^8k2*r1VTV<10mg~rM61T=n0#8*
z*w*yAsW`HigfURFM02BE0+$=7u~JWsJfpZ-5qL5b#twBgKM3dvU=@t}#bggq6Sbk<
z(Egye!TU?7lOE;zoP7T2KH@J7-@(*m<hUD$3{9nc&s<f<onC?*^l#ah_>zL^$)G)1
zU6eJzf*5Z#@q_81DE?SbNs*t%$b(ZA@eRDxUt^lnt84#dW(#)!apz7BuSZm7@BHmU
z7VN{xw4Be)JN&z%ciY3R-pkxNI`xBerx}05`+nTq)jHkVgXdP^Itu@*&F1@SNk_C>
z^taO1tDm=3t{8t*1?mkAd#lOL(h}?+brBMsRBL2si7V@B9Z}Q7I2B+6g{<7|8bx4=
z^x}U%EM^kYS=G1`NZVZ{;a4EQn?9P*qcHNS0WXywW*`Zs7wJSAtY<;3<5C`(%r~dq
z-0z<UEWLf$PF)~htX_1hyN^yYpJZ?TS~AQqY%KG3JzmuN(D)RvuBBWP&aXU_XJyKH
znkKe#dDFW0BODd-{t~xZ9%f_uvjacNj=qvROjKsd2BJWFbiy3w<?2rohI9QDF9MT)
z);>~Xo-r*gL&l2lnDX&9l0V}OvEzMo>C*IT<W=1}#M@|t+0;4W+d-k*``o1~>-(DK
zJ4y<F^;`G(+oPQCu2|Mv_~S;>`)x<3Z;>9q*88pP>hthD)cZ-{!&OPg>s-Uzf$y7Y
zLzlx9HBW>5+CU_=YeEaA#!B+Ps*a}StJHh9QeytI6&)0E47}J;mt4nZ^d2l79&SR_
zam+IP%<IRIQ8_Xn-e=8!-sex1kKC5|>@bja&O|82bRI>Y;4x=Qz5^e+HGY!J>YZol
z8evvi`{|<@!ndE^^@;By-zP4c`QJ<7;)TEXWhdIss{9}YJ;k^H0V>>rZFbk3o@IzD
zC3XFv<f3<iUa=8QxVEeDKv5io7pzIj0RmYlR{)LD<@Omv&q?)h4eE9qk0Et8&6cKf
z-4_JVaVNN(UuU#&-qG0rG7M$C>kImFit&K^u#2c4{YhO>cXuCM@@YXK|F&!e8eLex
z!bx*o(qiqpDil;6$-v@Vwn=qV99bX4TS}x#6Eh92&F%6b;vWcTHaaVtAK5VawZ)I{
z)q_IgG8SZdo|>rX_tnN^W0{Hlk0PhUyYb*QD05!|De2#)eGKY9zMHXTcx4ETAOp2;
zqTkv#lCWO#p_&P}Jze(xKRyBSFUk2&pX2y{{D4JG*2@kB|LdWgc`dLE32tD`dVSgF
zf4>@LP*YPQ;Pp`Uq|s6yse9pu>}}`vw3c&iTZ(+LE;D;nEBjpYdVImLI&c2DVLP_1
zqfHL0-C=nB5sE&}gPr0ZoAEtwyH_lliSoJ0?RXjPcuDJcOuJw6l%vn*#k}TA4(3e`
zrjxO<9i=Dm=7A+zS93+|Z><=p0Omj07gB4}wkG?WzZ5MefmFy`NWpt#trcNWnLw2L
z)2dOKc7W=VqlVxhi?cIltu{MLA$=!!*?{61f1k5`og;X^B*@Ch_`SUPf@s65`OK@?
z#`g+(IBMRhD=Nv*do;giemCj*@CnCCW@;2zumm`NDFf~(Xr8bip<;=fl_bBkb5pA&
z6<0UFFX@BGmMQoY{D>L<`{TInYI9v%8~nz!9RDkDmiS+9rU~9If*NdAW4T3Y7%Lh7
zPjg=x700%%+c*RXu1RnbAV6@p;7%a86I_G41y68?03AF83l5Dm?(R--w?-RixSf5^
zK4<T9?s)HwH{Or;qgPeeSYuUHSIs%UZ?13l`dOLAZakSY30f*Hvl`sdi13Q=`t~FD
zk)!MFM(x=5S2d~e0)~RUB$&7^Vmb@THIBTIGPo{P#acrMrg^lLu-e<1fzJk;iQQ_J
z2nFuWZIx;Up^(q3L-g*lBf`n#tuc_DJ5OlJySVE8@Ab9#D~z5~4gov1XTJIGvkPTI
z;`CqDX}*T**x9UC$7yEWz&Qnc*mvmN{spSpb;E)E@{B3A$T`l-*@Do7s|(#!?=rwX
zLq-P5QQ6L|$mn^?^$Iibm(grtJ$?QAbJ53h$AG&<@U;(^BvR7<oHyW{B;bq$e7n!w
zNKnhrtW!@quy{Nx{qyhiq}om?Ck`DM`OD}YAS6%GieJY#2w}z5^bDn)6fnP`uzC#=
zzRI$yWWxG*iw|B8o|$NQ`txBO1@IU$dqnX?%8<AO$-8jV*+q9`@|~x3$3b?rOkQuU
zc6v7F2G;lyN7ukbRDWB=cbl?*i5ZkAnwGJLUMee}8Pix)>Skg}078~JkIvmobsZ1_
zRU_y-&-A@;19kM)mxXMz_sSP@b0xh(&+sJ~-r(u_;Uh0v$?#nT5S|Ko4Sb&HoV{pK
zn3Jlvd`<49LyS5DtUX}M3nM>C68_(oWF@yM7W}Oyi!nrBuiG!+weIUka#}s-#v^zd
zKaq=$g5@t|W3$hb4nV78``p+XVe2UQ#w^!FOgu>2f1w^>g{BJEh^<AV+LbZ}k;Vu1
zDkpBmJ5R=Za*K7wUIAOwT5tDDewzUJwghZbzbJb1E4U&6c0fx@3-pEb1MmBRrKP3c
zt%J-}h4@QaV!}K7+Z&x?qY>Ocq|3ir*Pl-+*BrL<>O}GRIL(gyA5^52`I#u6#4Fn>
zdrt?>h?kHpRZoj)n);`4!l7}0mDA2AkK!ofF-B`s`cy$75XjW8n<^N4>Tqf*l6tI{
zMp<`9JXbx3H7^h`$O=)`o#EjhN{$s@??!NS77E}$M5~G(%M1xy$-N4{GK=S8><dL&
z(>ER5y1F?c!t=vVR1LM+1-r^vqJCzz^cCmy2%5*%yjJIm*{ouW;oaisN3wEG&o_5v
zNL3<<?$k|r2Yw_N$grmn;lzzD9LU)nVk*LQE*ttg6BABJelMciVO{O$Je@G21&i;y
zWgr9{^VWDPOC;xb;xWFKkEuZ&`ltS*@=yIoNnpOP%}hZyvsi3op@Vpy@0Cqt??wP@
zHUNeeaEccC*2K~Agktq3Oge9k?^xyWLWMIOtJle|mUxgbSfzm)E&|CSK4~#8+DwNz
z!G&eS`r{faZ2&;s-^;^xKTS9R%B@RuFaiI_qjTB)tD3A}P*IQ{2{UFg8etGFUFEDT
z>#izLik0g{4E%%g9QF)NdDtc|{-Y>t+yqW*XbkEj&AiO@)qTy}2e*HG8b^HlIwgJn
zV+mzz-4_iwD^X^`H=9!3Fi?ptb@ve<+Vad#oELPr6iELWHIlEcQ{o4z_-G#%=bxdM
zi8b;~rjMI{9BWbS{4v1insRE!Ya8?4mPFZ<FPf#6+eZK0%ds*!@Azv}b3v<PLJMAJ
zo|z?qCB3goh;Ugn3P}8zyZ~WYuq}%@v;2^;gW`*Q+rfgern|*YLFS^`X3nuJyy_-r
zca|##KJ0wfsm4z=9oBRk%{RR;2`XfPTLcE4uoFv;^v;s&<{jZtuTigy7ySY#<_y6(
zo@2&x_!D$_1snOSTGGYhN3(kIu9KM0bs1wnWJowU<;b?K9|q2wJ98g#C8Z-^;Ie8t
zN-ajZ&MGNZidy3wZfXV6b#lNk$<OC455{sN0ERwCwYwhV9w#f$p*<TEj?HJgd9fB2
z7KI?a=L16{=`R%3`?OSm^iUgXQ+coGp4;r8pZiuZdT$L}rF@iP>Er;&Z^&5{4ROSZ
z(*1!cB`F=n?$ySHT5>CkTLS>9ZkD2XUDC0>$t{$OnokvT%Iy&cQJroMiUj!Sd-oqA
zLTAvv&C13gPJZjvF|La7G+0ASRHiKmxY@Qd$a^*}IWAjN&v;<RJbvO-N5!@K9KA+&
zFvG)5=dHv_&^SyJ_6aq>6@9B0D~C>kbzrHoetb`Bw&{zxR^vRnfkAE@0~t#r=h?U%
zBTvg%PHo!8_o@EwP#WmxafA<jsn7Yt@PL9^M#QH+J<eERzWl>(iLz5bSHy(-Cvj%l
zg#qFpMDFaeMEq`v^+?a2_fLK;eC&H4`717e1dZyGMBjVH@`U;dbzx!~>+-$bp=4(z
zKwP@IdmmE?H-HMcYpAy@asUDES<(~=K=LEqc$h<l9o`e!DpavoZyI(r$tgfmZr63W
z`pH-!VW><tsdfI6Qs#|i{<Ar`rr|Kp?$$)>XRWH6x-UPuxGU)zb4~2o4+x;x$W0J8
zX5n~!F)RvemO614ptFB>k(*hVMom~<9T~oK2ot#cR#|JTx~sn;Ch<XPN6!sIB4f<%
zJN12>s~m4jTTb$db(*x`7c8j+q7SjEI$qsp$K+qi`=+NgG*{xC^Y)%CBg1q)1=5kF
zU^aX!LuWp?E~i;N#qeUE;9mbx=@DLHTU2zSC(jIf@$zj8diELU%AWl_6OU>tn-2E=
zGZz^b36f7D0C<NfKOVo`C=plbt@7)|m=Uh;`Z#Tq%c0*Wats4vg;k8)d-HNxIIx@a
za1W)%mS_Fw)->$8LRB3T+)+DzXxhihU6Fq>piZUe6K~5hTkg6{WMolAtL?rDt1~I9
z<T6rrx~V#sUg8O9M!)dPlyRUZ-#auA@Of{_;qDdoML_{Tn4041#hOGKjVWw4PQ7_B
zPxAb&T$uiQpBCCV+ewTHjSccJ9ywWperDG57uFKrd4Jj0O+S-s-3!GjyHM_&l5iT&
zk+qZpFi4cYO!MejarJ(0%dyF7wY-P<4g`}s043=sn4~|TM4wl06~2L-XrSPx)aLft
z9lshI&TMw8W%z1P;M_<p_W^~-p13=9wXkSq#y+Fxv^98G<^X4RXxpB}z4k{BHgy<x
z&wkh*hEc9FAXqAe^O7~BN4j>gw5*Vh;<JwGJ!k9BH`cTRWg0p^D86#(rdrC6jBD!r
z(zr=0Z^+3jT(jZ{dz$%5X-e5iLZ;>DyZl86cUV=}0L{FX`o^)4c}CN5CJ)iU%j44v
zz2&OURU7uO+U?Kt*JKzt!0`#q6TaM|{dBb*`{LTR9a-{zvvFC=6a15Rhb%Ik)|MvL
zl?Y<il@IyVAN3-sk0glG(Fn1L(=Ef|7zIKSuo~0$?DeA0BWA`qscoZE{N&zde5^?u
zv>$dJ<;-T+v8~ZgaP-cRV9uI+la<r3t4e3+G!kakrft|V>Xn~gCzSCxsZZi$)TA^4
zL@`LkXDJdIpJ@D6hGpxp(#-$(;<~GAx#4ANnqV(nj*$^SK!qOl1kjh5Bw7lIoPU~&
z@(T#%M8?8I7h@LZycW^&g?@+?cE38Drw)p2xILrzyli?8JPZ9ixK~3AkVY~4CZ@LX
zBv2gTl|}^2MU{%H+DP2kbGu*{bY|Z(t1`9r3cR@T>q)jqotFH@snpvtM98ESzZciU
ze3PVG%4S@*=9gtv2sN*YomfH$*OpcK?Au%=HY=+F7xF@WLXziCx`{S?Uhp?~;ZJGL
zfoS*|{8C|u^Agrqmg2Jol7sy!HC${~9?z5IYfaDRIq>=|qdI9qn{(D4!g^L{4svXQ
z!_JIlPXvUouGTv2Q|wW&x{pRJ$*=|zR<F#^iI2K1mp;U~{19aJ+A^0tQTEzimX0)O
z;N%n4GwnZdeK)Y%FP4oQ7Dr95yL%r6jf#lSd@HhXUK|-=MQ<!ZOGC5GN%Ln@T@ZH*
z^=X~1DpF|8k?OtD1Z8Z`oaA=ilDTnbS&+B}I=IMcji&nuq76CoRSj8wA%^<B21I6;
zH(B~jKAE3ftfd`~D_k<oeNsO$y$h<AxndP91-{dowB~t-WjPzoZwntFnb(6ECU@a`
zR4~db0kjrmtgyyxd9h+J+oq8<I-sH`+E-pusZ`m~CO<zJwD@8osN3Dzn9-ecA-W0n
z6KAQ>f}r~i$l*|j^Cwn^Gkhdh6m4gP+8oKF{N_TI3vW*k1Ef?x5rSacR{j(2?co4R
zM|P;?feNPh4fVa4Y^A-hZ#<E3XWn@|$4OaSM@i5g@Vr;{GtOwyREaDwnU^rLm{Re1
z$b1YoqXvcibiJ1#J>fAAIwcjpl(9fQV@C7=J|bpBvh#+-6B(W|TKqs#{kFERFN}jO
z+~0hw*>iPg%6i3U&owWWF`M3q=J8OK=JRU9UGl6{PPi@Q=i~X?B>#Z*x)NU$)o1q)
z>FwaLYBg(#b5<QWO&~8hfl*b0;pBwiy23}ZlQeUfk5&-paQX4tyPSbU8RlVW9i#Au
z)$*8!`R3|&yZM!)W?XdhW6=T`t3F%DGpqrz!eZmMj`qPx6allQkMq@a-q(_(KJK6k
z`di2{^qlQ`>lN(?W@o!%8JDg#>pKc}By?<$P|OP>DzrdlVH=LGW(ID#IHUH;jatKk
zUx#Ln%IC4krs7}Dg`u|8S&SOT0HVA;6qIT9f#}4=#&#U)yku(mA@2*kzO+CuR_aF>
z=HvMdzAQ2lzF+iM(2aEy%f>LU%0DCfdfCN@#VkYhklIbq{Y32B?DqbP=a}Z?T%CnH
z%u`{mrrf-<y@!q(hQ4BI&*I0vEm~mim2H_9qZw|*FjRMY*7)#|4scn?D3xh`zwCE^
zv+Kdj>myUE>s2~on#rnYS+t#nBL7alW;_ImkyW)F*G`4!NO*<17!#M=+PBL3q~D>h
zk%n)op`_m%Qgb9%AkIy&c~i}>1yHbjpTGL(HE|fb?oLzzpr)R8U$}l@8=Oh`{C;?J
z{&lZ%pJ|Y#`6uO(CNp|nVSg@$Ml<@x!UC@@$Fn{TApLuA1vr1hGhOrO423*P=IJic
zHh5h0t`ipq4fBKJ4Zugi=aw}Vi8@ceHT9AR?atNtfY%K$)x&EYeT<-yu+Om*wpW`J
z3+@MI4R_KRhZ<R7%YcmMc@yP0d4@>edO3IP%SAu_5O^2<fqq{jfHVh6Q3cp_;uGSp
zRne8F|J5)kXyK7k@6LenHnr1BdG^+<g!Q$tiz~Kb!CXAQ&yO1Q54X-0I}JH@w~f?>
zqh}a?jjv5qKB0H5X2}vV1FrlHtiv_XTs^K)50|HXu=l!{QU=!!IcttN_B#U07O_3I
zQRwFJFudW}g5aLI7IWwxR<n!x&ufw-ckL?riv}1%Q=WH)NIwqfS&T@Q+pM7<P;~Cl
z_4q{5qiFkGlv-{y1G(&3klNtHN5jer@T@V@sh9B1H;9+;t^IWCL+e^IP3>!JI&9~A
zokZur0#2rhlgDP%$$vbKs*t#x=2^Fz8W6X@O>lQ|Rmh9Gj*$V$tW1x7`5NzgD@Esi
zd1obs^N7{;cykd2tG62O7xau&EjUO&qhY5^T?a7ByK;gXz4Na-T1QmN50SocMiyoS
z*<-}K-OPbR`ny(wX0*Sd0<svd`_qdAHQcpb)!sOti#v8Dj<^bD=4*YXaP|scj3I+e
z1HQ4$@(NF?Wpg1OKa7tgPCgA7EoPzoE|BdjW6F5^zMD0%#JVVF2un8bW1~0of-+sC
zSjMn2_`OE%mqXp;91|@)w}r}#VM|zER>~f1xa7@@&ogTrYWDRyUcR@<%RWktY70ng
z3u{6j#Qm<V+$Ns8UdFm-PHhdm;{FcvK6o2$4tYf%`2!-R_T+u!_}uKG{hOT8NpQFJ
z%8t`Py~g$BRVrzT8Y=%osT_aX#51D3Yf-39=0p0|-6yI#CeAai$(pFt#X)g{TV=;@
z*w#xGC;I0UG;dSeH&aXLh$i^g>pjiVNAWp44((lUr!S99=QSL7-fE>bKU{dmVtrzq
zv-PHvL!=5EKcxw{Y84aqGyXuS^#0Adz{bZcipdbkLT%ab#0z;R2?F&#AmgZ(0)aZC
zHwEex#MKYBgjs8PCtIr?<~tw%f%L4=<<cAhZ27v^xGyzPl4{tZXf!i@Be^1_<E+Su
zT;>gymBm%PSal%vl=dnouIBS$Cx!0{0cBR<E*}Ikt<XBfjuls3C)UFYOp_8MHO|DC
zQEl`h{bQ?9a>P%>zD?`SG?xtGlS6Q#j_dbH2sgRVv@`N(U=M6-=_U72khC*l8mjOJ
zVxn8u!4r}+S8{7SOY@A>(gF|`L;N-#IGJ|PHziI^*vgKDlu#g*cWg|19ICl|_;NoE
zA>vo23S>tg%;_?Kqhnr+3J3`#)#-@g=5hV9e{3(+$V7&Yjs1SAaR1cQC%G8EomwvI
zsTgv29GTCf7(4nrIu5m3KvzATpoXTQQ*%>KF0-?nTXM1oT}7sUb$qtMK4O7^f~e*^
z4Pl%acA%>98yI!c-<gDUInm@=yj3{C$*;r8;8TeS76)x6X-3%1ON{qHx(PK>4n-0x
zxwFO8j^j;PIC6S~E&c^$oAg4##8Z!pKbJobIP1a6C8WA>?#@2@y(IC`WFX`XR?`-~
z)G(($8JQGZ_b4%k!FsN|Wq!^U5*U{BaAO?}wT)0XE#g9G#x|T@$kiODOgwP|Dp3mL
zJ<WR8cmS)*ljAMGr)3TCo;;ir)1Llu#NKZx@soMe8HpdgfxzAKtfeDmLLS^3smk`r
zvbo$(4=cGpI8NQ_;)S*NPm-V)TJ=8S<H|Maf5+1dzkd^e(6RwK2yg%L@^El6m4!xg
zfoAe&6H2=w^0MEu%*6AzVg{{d+}~Y>o)2Ripx;jDGcTCHImE)6q+pts{<iQ$n5tvj
zqFo7pf_D-AeWynEs{+c$%^)UrvL>O<?gDziX9We25Q%(LPfc*<icVgQk;3$2Xm)pG
zeMz%}b&$Y!mO9=VY}@DpC}e$Pz*R8a_!2pfeQShCOLixM?ZUecs^iVHV3R3R6O)Yr
zhqZ@alE_%>FJovI%Ci~WR#J2^ea9(4E)L6S!;89yHX6|sZ?SBnrm-0cuoWxRmd4&q
ze&nL)L{m;;(u}Auauoc5FKiN>Q<_sHdo?}PAgGc~D41zjk;MC6%eHD>gDI6FflE_$
z+=89%>D%Ojg_Zn0uMy#b5oQj(F)*{&T_yfe5*F!T$u)m$(p1V|F;j0%CX;5mRIt?c
zKga`v?ZLfjz6)~6>*;7E^0Glr`W>s1*QY($s9Urgupe$;3)!1bjL*kGNFe@`WP)eC
z?KFdm;q_92aI-5J+N!f?+#wrHE9KUG&FI1OaPSd;FU1&rGde#h8ML5j%6IhoH46{m
z70V3JmDquqJ-_jIshVL8puSX5u>aW1qki>r+?~Jxf$m#r?xCk%Kv|>d)$kbN=m3{s
z`bW2d@ia(6^7pp_GD5?&O;{}Ox<zaZMF10(ks521h$!cScm}nxwirMc<8%Ge2Q4x}
zfGQPzDXx(y*Q7HpX||VKWhbLgvYCXq@q2(+HrLKWttl=QDw5jD_qg|g3|x@S@{DTB
zRrwYFQb|D~osq<E${IRnAL)w8?$mr&)n14L5RBi8p+3R46Ml&3YGnd|)wtGYy$>sU
zN3w+}7=g1uNvAIt_AAD!ON@BWmRbk>uMVlZsmUn|lFnjR)w{)pOA@X4$3f%O4Dg#g
zn#I2gF#Otom$+%nXovu~S-wKmI=!fDsjPT?SgKf&D5t5_{3E~FjD8`{HO5mQzIo$D
zXq2eDrLb~{aDas|82!$BDW<*S!`%UC3O$??0N-u=lK?Qkw(_|4|2st}YIE-Nt?OtE
z3n>{c!@ez~LV?Ja&ZxCyywmyNTeovK4}*{3&;FS8Fz`|9WcG_7c`wz@d(A_(!DLUw
zH^A{Dl13I<goVa>v^`>$5<wPMpO^-$O}SqtmcKay$PXF?S98(iCI|jz5NV?k|7=8%
zI(kWQ@z{aOmsfU<^2w)Rr1Wq;QN86rr4d@*!y_FT5dpOm59wGIT|=XJ%JSsxZyf$+
zd%E#5FW`wNAfg?)o&X6~q##l&e+ey0a`6l+cBJf?R(M3jah&<>-R-|XnW#F~#C_(l
z^I^#Af5W2!U9c#Ri_z^YY>UAwhn-NdS1ymmjj?5zw@br3C*OHwvVW8gd|kf%Hn_2S
zhT;s^oyudVmYdO7++QXzIh@~{NZlRu*kPVo^Q56M75OTWg3FO~4T?$8te2K=&faKW
zm)Ch4yS&z4>^GstgwSiS!roNfTub2OfteR@6;6G7j(z7&(hK{X`FHe0vo##^&RQ${
zT?N9}2H6GAEG3_Y{r=A@`x9o-N~7ckoL&Mvyz_bAWFiJjB`s@n+yrv;M*Wq298N&0
zN5fGXwGlR8!P#$;lVz(ogQ?=xI3rA;t|Xvlk^|Ot-u&c4i{)*QMDlauEW)Uzl_`p|
zd;)+ge&D>(sd}k|q~wt0`5t#dUK`i06LDH8t)W&!TmGahfT1u>^xXB-x0Z`N8C1NN
zMD!Bt#Yn_506^jKdyN1qGwVWSMHt>JS@^+H8Ur1NR4&it_dkXMsJ_#2C|Py;{(a6w
z)Ufho)783A9yy%OO$31V?5)M2idq<eED#;1r!Mhkr?Oh=6;(euAgAq+DH?k@7v!V&
zu3R4VtppNL?U`+%I{f*jjRL;ah#id)FH$Uo)%Hx>@A1$45h;p!)2Tvc-JHMVI5Y5W
zMK{<t(ldng2rXN~2CeMlt>>22jF(VC?m#|yTSz9;PWG|7Gqil3g)fmeseXm^Ab;<Q
zP*B?uV^z{e!xfSBj$xt6U9{GDyyL`pRr2b9Lc-i!s^(|;%qHn;pEI)2FWj(^$|u$H
zgp9np3;VH~%{PiFO6taaR^skwL*${63l&xGd9Tt9eMi*QMK{^%sH$J78Nyw+<5%yq
z^z5C5DfL27u0bs~_lm5SQs?fM(aV>`NXDbeBxuBV<Mwq+z<_O!MGF1)$=<7;6;3R~
zJjAwpnN^(sc5NAcx2BNZH`3Yuj7TUGnHj-|)bOMQ5^~U5dMYXkfKax7|Fk_;QW99(
zwC|No?P%2i&Z(^L^Zvf@ZLOV_CYKIs2le;ATIW1w@8h4&N>;RxluR0cWC5YbW>hMO
zj>~v>;|4;a8#1c!<022OB6x61#ru!uoD6>KcQZaQXpFAeNWtq66&q{R=p34(eO6Uf
z#pAHl;Lftzjeky7Cb_Y(@s-!nu-@UhMCH1Yva(^b=exYMr+woCT^=?i%gM}IX+xTk
zZU-|?G|EGklD}U>5AHPug9K2#IBEji8yqSxRJSmi%gLj`|2ahNx3dtmrjqJM4|z(O
zE=oZl5|OhD^y~b9D<U?OwTXc)8WP|D9m{mfn{1!Ykhi4<tRW!^8A{gJoZUr#d5O4^
z&Cn$JeY#j?P<KepfibWx-9qd7^t<X-e_pahUTKBk+>#)BsIZ_x3Qie=$8CvuwBT2p
z5(Q8!GF8uyADGTcWq?nu?x}eJd`Wr9(#*rCwe9%D*5%yp9<k``ni>XxZ+Eh9+*y$Q
zgq3)V#7btPQfh18mTlxv(~OMDvO7Vy?|JhE$CtJ2xL*kVVyScIkCA?IaDAyz_T0P|
zCrZPON1ziRuXg}Q0?t*8WWlm88sB8n($k0I$fm@k1jFJxEG#`cmUP??+axt)5{EhU
zTpAi~#t`}^#y598Vn}z&rp-OPpOp1{KobfjPObhD{w0D>l-3+h>j?*icccYNLHcA~
zTcF#QG6w(v!H?XDmD^7oiS4RFRzCr+;s6D`i8Gqy&gP_88As}q^wU|ISzL(hrM$*>
zt@9Zg;~8RlOS;D{d07@Y@xET>xqFS6TSCT?UB1$v2UHGYVJ^mZAL2vb#4#%XoXr`9
z&VMw1aLk*mDEA;4EO)NP1A!!mw+8^YU$<)>u2^MOKgu%W&qf(BW6jy<<I^ETDG@<D
zf4^CbUx2#9eZ)C<awA0TcvOOFW@=B#^)OLGN4BuJxHMf`HBukKGBQ+lv|}jTY%qd?
z42Y~NikL*rlFhK;7<=uECU-g#2xQ5w>)Z6GrJg!)skQ#17~k<%plV;kig=uajS8vL
zs}U~X3(n39WXjS2Y!apR3$u8Smt6APea#YLmF$9&F)}H>S2HiK<L=k3w|xJhrY>0t
ztUa!|A(ZQOq1dOJXMQX3Ga)P`<Mw!jpb&XjnQeAPW0q@90}?W#ukq@$t<6$ak>Y3W
z9rwKEMx7auaGrBazuGX8v}DO-2HZAAm^0GSjP-MUO&?%Aa|w9Hiek*vS0skv$P56Y
zI8k*aKro_!Tx0y4IXDoRP!=7r6VaQ|WO!~1@P=vIj@=Kw$VoeGtWXD1i+nTeYVoPa
z4b_GibD(^IsR->h=Qd|9QQGJY6mG6%$iEE?{;>XN2E{Ebwl_EFHhz*TDl1!<o3rE8
zsGZ&2mMj-4ePuOl?&~G4K-JOFfm^rPvj}LE<}Q}sk#4kfCm-&(K>+s$ba+(%9p3+~
z`D?WQGw%Pr+bhP07iTse8$HoyXHE~T4>q_^KUl3Tlr<%7)QX;*l5(}#>m1~EK>C@;
z(b*ZY-u=Zl6S3^QZ&BTX0o=#*+a+tmy~)e<KX2ss-MGKRFxpQ@t{dF(nu~-Zh=Tdw
zKBNE1B&37!g$F!J>sg~Fq(+FNQ+AClF(IH+;-(1}U=9Q4Fes_0?s5Iax{{s_J91X7
z+bI>)uJeMl1s6QJ?%gofg+5w4Bs)c%w|VBfxNN(u-!B>B;Vp~Yw?5FIjBqu9!ev64
zR9=*EQJDKZ2mG7WBaJmw7Y}LAZQ%K+?B$j49^3sWW8D*hCjm=-u=a7+BBI|e7{olR
zsm5rM!$+7xRmd-FoS9n|rs>kwa6<?@rfr|ACFBKJ6&YGBdaok`*dHn!YoGh>KnlZo
z^}RbF%{Bc1K<X&4t`_)cH95m(u;5UuKXSiN!d9d6c<e}JAJSlVXSjGB;A|(sBZG$L
z<nMm{eRY<t);;OD;2X{9`CTlTCryXSDml}hhk-?7>(1^{Pewz>X_M1qo<|tK^hrnJ
z6A~oQ=oDlI+aF|2syT&Bj$aG98|VJW>)%c<<JZ^s-3>I`vvR%=l!=1>De%&6Zi`^`
zX^*X==Vg<EVJ-BcY1Q*+Sa$88;>EF#r$>KDU2FJ(@^k+W5_K03sjgswfER7u9;4s@
zu!BThSEcxG@1KaF@y^<@g?iJ5I|8JvkU!?<P*b3oB;Q)dv36w`p;^u{NwEoKnbIVe
zH`m6>7%$#S*jFympyZGhDKWA0w5hY0Rvcz8sKvLxAiji(F12h>OYrQw3r$@ghsSqR
zKRjhoL6_KuE~_YJUA8=JQ&n3(I6?b$>5WZK|BO`9wdmA;<I|8opV{%;;_gMs!E$$1
z$&y`2IgS|V&*=s_SwzyWOi`L68q7nw&gOs!Kk);{6Xy%;@ERJY;hR5BYJk9Ft^k04
zv`n8oXM?>aNLO!@QGbf?iggC;K5)j>1wB6zeSD4?jt&p6EDGrhV-YGNSr1Fhe4A2N
zDScJ{o=tcT5YzDQW9lbIM_{iSE92${j#NJ5-JiloL~3H1Fg!`&$<R(gH%h4DjT}r3
zEKTpYTy@}8(4k<be{)G47|ttCX)em;|4<fN#rrrey<$g~D;Rc7k;qtV>olK5>O{Rs
zB!Skn_-t`_Qa$c(E;9d3MT6q8_4pUVvikYeL;c-tM6X4bg>1D<@zHl;p@D)~wGK{s
zkxLamhs)|m=su%B8?e!}cK&I}?a_SEkzP^r_1)pg+*6q+m)-QDen;5Cjy(8yJC=hf
z-AT4uZbGx`12~|Uo0*xAk(L5Z@RsghovKlO>45&q(rer0?05XVX2sdo(q}J>P41oT
z4cwH14d_*NhcrTS8wz`ty$15NIo<i&r5&f$M@5%cQd;)xRtwmY59=Ia2}NM{I8DN~
zlk=?#^AwaNJ~jde6fbP<$TBXyaY$)E!81$EUM_~?U0ui<__oNT1gZ#77snzvmo)bG
z0+43u&A<E>+w_z~kF@EKBrXsULmbX3+2~8jnx28jFZ@p1(PD)lvSvC_K>uyFRX(Tn
z%RXRgU@Y=+>QDB<2fovsHdJF5Gd+`&iji!ab79}PtJmQJkn5{O$KS$~D5Np~Q}XBY
zYLr0~=VVBTDP#<g(YWPZU{e`dIS5KO=f;KN%jITN4xUjMJUdX>0pA{N?*hLDDme{1
zAe)LZRQrQZ)=`5S_b_4zXh79)2Rbt;TIp{e<aH(p-^z6`^u)lCvlVoXX*otCB0>c7
z-k<h2pc`Li<K%R4c2028#%6f=vbw5@6iv6-6YNyGSYtg2uM(=zZ|qPl_5A-n0MwM8
z`ETIkwWiZ!BoM2PddW?&)y<2`qC~O&CQJ5JmOcbkm<ZnsK34J=f9IBiPEWEOxgLqu
z_W8Phj4eBEV-HJ>ctyYBs85b02G6mZ_g)<c2*mCS?jH!7?ka8;KqR)<T^dw}6j^^G
zNtc&q61We$o28DPSRH8SfVMwis30Sj_(g9`WZLbQY+J(+zNb#?g_}ZDR4YNAmUT|u
zZvmv?d{3ifn8Y)It2n<e%egSsIL>6^m#SC!kBOyeKOwc_g=s<^tEKr(H~?)pNB<p4
zxVfVRV=tzrsCI$<=9UXU+p41)H18t-4$rl+qRFVTmNDHcM8jE^OL(`2>=F{%mP%|M
z-<`{z=SsK;0Ni%?wtZ~<dL06t#d&O-fpmPW@B?o_z^&wrH7#TA{Vrn<Fy2G98Y2i_
z0wKKDWJ;<XTeH^!1fLa5K%8)d<`@>Rg@F5z+<O(w8yd&={x=vee`h}BGZHOb<bb!+
zu^T_2*oy<$tr8Rt)!e8=%6|K0aGt36*T-krS~bPGf_gDe00m`k05~?(+OYvWTlVYz
z-EGCxHg&_wE?A}YVgFm9)tCoPTihydnqGbi36S$JyfYP8FM9Ul2r|j@bt5(Y?IY2%
zho21%%PBgR)sIuD`KOm!Pp^fWn>ID{Ry*B_aKP~_CX*h+70-Q<Oz&%h9qn$*bxZ|l
z;Y6WHww2tZ0J6Z*B902UZX8eHc*g|I7zkPPp@!I;gjOz0+zVvsFIuChQYoq2(Y3ia
z)D-J$F?FhypJPRh*#7LYy12ST+&ws8W+!(n*inI99xv;4##&_a9*Eu!PuW4MSG}g<
zqCqme{%JL*rH>MW1RZf+{?`QRmVPHlp8Mm`Cjr*sMMr4xO|N>a!{!`S?kGC=DI^^o
zB`iLjz$m*UJ3BiBK`&b26J20safj?0A+DDJ32!6@Qezb|l~ziJ6Lv}p>9g`Wn+TUy
zaTlqBvJ2nIrizw_jB8WR$*E?D9UxAP$PnS#zru`^A?!E?`%brrJcH+>gY@r+O0ssa
zw~)&wrz`Vk9KnNqmSK2{&_|9gO1HdpJ5R$!(+{8YLNpt-RVa!_bT(<5C5StJ!d0Kd
zZFf~oap128ISo^c0^fBQu{H<&CBB%@kw5U_R6J@XK3-nQ)D!n^Nz&vNwBJQ5q<2&K
zqJw0-_n#ks^s+Zk0C{zrJF9##ys&8*ez362e`BezXAI=r6tyaG8hJlO^9%JG3kTG|
z9{uuG-+qBc-8VQ4KW}o}zM=MOG(cqGUVFK467^#3;%l3Cln-&ut=8pYwaQ|>ve(J=
z{Awj7>c`5HqQ@r^ch~jaIpDc#bsPek^?SQ?=B4UM6e=vnZ+=zHc~fr$RhXjm#F88T
zg~T~vY|{h7+uMb~38a(hdNlO(*eu+a%ULfKHMVW^5=-5Dq`9SS^>loLd+-e=oer6K
zmew7F?v{%TZTK6g?;sMRqOh@~7086noeAx!s$z2ZI<ZA6(BD6NIlK0EAUceWofbyH
z^S>NEvt((i4l2qHxYf8TxmtgdZ-+xdqwD;KPNBle)bx{+&a2fS@Q(yQ8R6Xl)hWhq
z0Y4_*?@S}gW-lQQM#u*dQG&K_X%8;&Ks6>m)>Rv&dh+egGq3)1DhL#Mbszjx#B(!V
z##CViuMhb_w!{2aZkr~?4ocmKD<h~>8{PQXjjA!yPn}PIl`Op@>PX&aC;9cO{&($Y
zlxEMYP*jWG4_Pvg!P9-=(*m}7=_YHG+1)#wa2^4oI43*dEk{m%d9^LuXHFGiMf5>L
z596XaR7SGo1$b5VH*a^n9vm9V%*-@<rWxGd-(On#x+h4J3GP~tc<dKk&(@_x>O8so
z1_l-y;zjwThb(K<EO%{ZZMevLf+CJ@OUNX|evk4;3gEBJUvd6_Q<wj-Tg^Jl>gw!{
zL}NrmN)9}q0EbpXVb~OW4)E_^;TmOEFZZZxivLN-@Ta5!exJV+dVgzv>m72pn1iXQ
z0KASXQ4c_3o8b)Z@katUO<k^3ysCb@fdvKJ9*I8Q5=eg-Z-ut)JQg{*^v}+4mf$T{
zdZe5=_P=CcNRb#lZrpkCB75;$z~<A~#+A+%4hg4{^01MVfEK=M5$R8wb>@(}TR0ei
zMr|vOxCWe`bk5GO6DrWKeVBMm4H#l1hbK+reS7YrOO{VhI&Or{=kZa_ozujrK<a6u
zns@hDynz(OmV<o_XbnNOiEWqZl`fR!Fq6s+)-w><d;_tv_KqfxH^oxh@K;`bQCbk~
zjUP<o#QXE(jOc0GQ!sdI$EVeIq7-&Dx!MN0jEAf|LTi%_7;f46L81@GNOJoZ$K$WP
z^Xm6R;dT{uJe5S#ufewy6uko+xV4;p6uv(=$nY6|V1b_XR@=lPiD3jD*v7?U17<tK
zE`qf&$gbBHG{m~FYTVj(KC%!(OOVH-{c*_VtJTY+4xNXEMYZ9V>z6zCz$}V0bj3qU
zar5j=sBPlFxlpLq#%+odWqD{kH4^U!5PZ)MaY<2MRL?8JGk62e_M(oBMHGCA{I^ti
zA3FTbd`|Sy0-5=IIr96_r49lNz>Qm@`97S-UQm*?>j!gEz~<f1sPJjS{yrPSvD-6p
z=~u|Vve^Q1TAU}td>os7A&IM4_YB(;;BA%G%eLdYm)S5MNfD!mvq>f;25$=P(HG4>
z<{k!>j0Ddii-6W!*_FZAip2zWw}<@}mX`sKXBGYwi}qVu$+uVMJr%WJSieGSDIOUF
zSbytuM9#tC{{U{iI*fg=$HF)`@i!X=)^h;ySlF6Z8}{j2eCjsZeGH+oA1_8@D>hnG
zEFDX01K2(HD^{Dl?>iVL!(`W19?SjQZ)U?6SA5)W)}JbUr3uXvY=y6f;{WUPSFxy`
zppW{oK<jPv(g>UX1*CE{Kwz@<;M5VJ83GO<LPzhuQm_!XA6=dQczGInRd>w;d~qMT
z=W-4zyZK?d`obuD*|aq8s3k!~WZd2`_F&B3(1_!#f3BA|aq7g*Cl+o(e4=^g@X6mf
zK(hz`T5Q<i1GM+Vpt~5s>2iKg+NN%)>2jDG483SQ_p=Q+tGdrS0H{7p`|yAT_}#Hr
z7p@O>>t-Au<nL11L?5mxW4pO-*k%!a4HaQ50*~K(gLd|ocd$G{R48F~zaT)Ydy5s;
zSFJzhcmYiT(D3UHzRQ#LUP?9SDhyt+Y0q~_317zbov6v1Ki-3=d?3)oW<R^s4d~BN
zd}F#<^<X_z;EVKYA+PcC*K5SDoT8D0E0|G!PXOSkdDYcx5%3))M{jvRCLMEEJ*B~S
z=-C)sb`sJyyj*aq*?Ik%G{Xh_?o6Y*)r7%>(*F*^%)LPQyf>y|b#?+q@s|^8|9$~m
zPan2=FRvdDDZ?${>yt=y)T$7%u1*fBSKI@QjIs#(^n;^(ET1_3dV!IMNalROOkEBm
zF@!o^i@un<I2$Vn(OHx3=m585`rXu?@^Zq9x8?n~ANOJ(ZIne6PT>!ykm8V{rH)&o
z^btbR+NgXHZK$9Fghp94uI*Ts7*33iE-a@m0Q*MfGoH$YUK-us0!1!5EnQ4Sk-paZ
zu86ur^}H-+ez5w|R&09N=bx@u1P4@UG(EIe+{2#Mj^B#j2Jjk*IPXnyUYo#f8-bz*
z-M4HEHlm<k_a*wnGiU*g?tW02jIsuSip9?rOjj%mzlvtZcfd<(b;Y9r&`GZS^K(vk
zp3@3CJc@4=`sjXh%bRtgKL_o`3^)t*DJr-1hb?A&pd6igq_gPW+e(d%&ic{fzXtX-
z86+BqPAbHAXvIWl{+Kl!ZZ0~xT$^(X;19wSro3NvF@mndKH$PY;DggKuwE;qmkp*|
z37ZcM@O-=<xnsMRirF5R?hIf33dWTGeP!;<;eKF2eIU%P_hh1U6iPN;)v@ZRzub7(
z6FvI)l&z{Yt$ATKXqc?wNhUaKcgJ9n<KuQl2Sh7~g$y0=U|Y?y%kdN8##|rf6PS?Z
zMoYgs)W%l9SWl_<eJ~L9oR_ev`$lWyj(E{HpVM#l)Y|)!NFTcVGQd{5DWzW6ihkn+
zj}yo;>#Lb10DK23zduf7-G;}}CQc|k25AZV?^oBf!)bU3)J{XM+5+1Fq7E!@NmMCj
zFcrxYH0uNn4Q6V*ju*nF{2~tze;!u;SMpMZM<paw%N{OeU4gGf5_pjr0xZ4i;^4pd
zHYW(Klk{bGIVuc(yjcOm82YSUF9i6DE#DY{&l+M@OQ}IFj?7S)^yiqMn|3j4WtSZm
z+%jW06+ClRl)NBY7fqu6Q`PrpF#JR5_iw@QkFWn!0OpQPK;X0g=8(ixcna=!g7J?@
zfj^r6<+Q<HyRjqxD<k>Wz5jb0@P7yw{-<t#9Q%K9X4j%~_^Lyw8*e2g2UAS5)%q;q
zJQ|A_506FfvzN^<JOXbhR2YH%w+51JXUo}bBqeJ~EiB-DfOktf6T`nTkOzrBWynA0
gP5;cKTEGIDg|w`QaF+$(D|Z9rq?9Gg-x`1VFBpWM5C8xG

literal 0
HcmV?d00001

diff --git a/doc/assistant/archival_walkthrough.mdwn b/doc/assistant/archival_walkthrough.mdwn
new file mode 100644
index 0000000000..925e34944d
--- /dev/null
+++ b/doc/assistant/archival_walkthrough.mdwn
@@ -0,0 +1,32 @@
+Normally, the git-annex assistant makes your files be available
+wherever you use it, and so a copy of each file is stored in each repository.
+That's perfect for files you're using right now, but what about files you're
+not using any more?
+
+You could just delete those files, but it's better to archive them, so
+you can access them later. All you need to get started archiving your old
+files is a USB drive, or an [Amazon Glacier](http://aws.amazon.com/glacier/)
+account.
+
+The webapp makes it easy to make a repository on either a USB drive,
+or on Amazon Glacier. Once the repository is created, be sure to
+put it in either the small archive, or full archive repository group.
+
+[[!img repogroups.png]]
+
+Now when you're done with a file, just move it into a directory named
+"archive". The assistant will notice you put it there, and next time it
+has the opportunity (when you plug in the USB drive, or when it can
+talk to Amazon Glacier over the network), will move the file's
+content to your archive repository.
+
+You'll no longer be able to open the file once it's been archived.
+If you later want to access it, you can just copy or move it out
+of the archive directory, and the assistant will retrieve its
+content from the archive.
+
+Note that retrieving data from Amazon Glacier takes 4 to 5 hours.
+
+### screencast
+
+[[!inline feeds=no template=bare pages=videos/git-annex_assistant_archiving]]
diff --git a/doc/assistant/brokenrepositoryalert.png b/doc/assistant/brokenrepositoryalert.png
new file mode 100644
index 0000000000000000000000000000000000000000..ea001aec048ce5745bf9c586f5238f8b29152071
GIT binary patch
literal 5806
zcmZ{IbyStXxAqH2NJ@7IQiqa~lI}jVAV>&O(ueL8IMR(Ax*L&hk&^B>z@d>;X%2Pq
z_kC;Kd;hq9%*<Z%uC@2<XZAbu%o7FHP{hNg!Ug~UPgzM$8vsy5A8k7<)W^PH5nJhT
zc<QWV=mr4zKmIk86b^jq$4N|xvbsFx3N{%DCGTfNa`DG0N{IX$h^&)?gOwu$kae{(
zhgexMc-lg27!;M&!3M$j<N!d%rYt9|>$P+Q^YtRuTO9~gW*sUlDt;bCq4HZwHO~n9
zjU}O0d)Ef^DxdS%$I#u~du7(Y6<ZhV(uX5a&A`bc0p&n~aPmXuL&$Zr4Y;{w*wCkC
zoPwuPQzKX$Ski{J?wIzr_*j!{bBojib6Df(#<JW3c0E4?xb2Lbi7}mC`vox!nn}gV
z1~G)9gU;wzO5VP1<fb3qXl5AflUL9JRVj#nf0jCAitCx<=#q1gT*1~tQ)2w2Wzd;s
zpyiEKCX3aURT$Jft_tTpsWiq<K0WTV3bwc^XuHRG9cMo%1h+IY=1qo$ALHQKQ!^UW
zCq2&c&z|&>O20HF{6Fm|>i)e-hmU7I9e()3UmId#K2KA6ewn$33~v7QyBHPPA!hyP
z(I#Ee=CSlGF`sc+^KpAh-oABs1&@k|m|R>`R#xU5rmLy(6omotX(_Xab>#5hO`dAQ
z>8ZJ$a~~@{$^jR|??oLW?XPEl2MT6v&>GQzAS!&bc)!?k)blVD=kgcs1)4W=iZPdP
zuV`uuE-9;ve8IhK-)#odbf<^!F`D{5NS7w~x-(5p&G^`0Y15l54Qp3d*NalEJAd9~
zznzh(6pk-OMz87ORLazfZPDf3`A4eh1C9UoQv=U@@BpB4`*fP)-lOvN^!+wmqsA-P
zVU=qVtam*Y>|9*w;|lvRBGDjh_T{K54=G6PGn;vK(%~8}*?M)svvvh05oBTgRBRhz
z9#B^1A_}u>SdyH+uy02Cb&hx5BeO;on3=Um8Xj|#^xcI`B@%T_`6I?9=_Nck^EG!G
zOqX_&sk3>edEPEdIJk^T+RMB$3a-Majd<cI7(~2a2Pg&Z6#uzyp~~etJXBJvCo?PW
zo>mjh(?|0Ps=|m1w@I)Wq+`=3HyWm!<DSF;8u1rI0fL|s)=`zc5?Y4BXjV(~DO_BH
z_p8G304Qe*e}1f7jSM7uOUdSPp_L-E*Jz3Js9QJcys-qfno7__Eh<50RvyAMG>1|f
zT)<IySK3SG^kc^og9qD{kAIw1f3uz9c>nnRcz|9cRyA=LC3pG*T2Ly#^_Hv1fQt$K
zz<5fE0SQ?IEi>I_;S7E98E5WnZ;jwmiNs8O-u~Ic$Jg_YYSTh-x4pgbnFPSj$t+Vf
zr_KG4PBUMZ?V{+>k~`21;}^WU6Zb9Q)tk<`zd;P*_1(Lzhcz5ro#sm(iPo;qyu#U>
zEPNqU^3bZAA<6TNb>OGL?lOPJ-_Q@?-xJRVVY)k?v7mCYz?x`#!#x@lHKajinaMXn
zu<2~e`Y5YJ+}<&J9IeCy;+lOi(&9a&Lm$1U37B0toEYp@G{-qQEcw*J^9(pLr^%D0
zc1+yIE4ls7NprP(-b-H0>@V*ka)T!_z*w>INcw5^PJ^B`n^kzTM?EHA{qLV7lv&88
z3tw@tUZ)$xTU1@>X;tm0FE!$J<^XKDsv~7uC#CJ3X95UqR``0j_xzj(X2y2*i8<zC
z0+23C=>*;B!v?$Drbm*kGH_OW-{o4)w@y#9$*485+p+37c265TAy4*)x97$*n&3xf
z6o8V7O5*UgIu{qA-kGPQ*WtPBoKRYwA|f{(R3#dZXtsrC+}_}gr@<(1x`zlF(KY(;
zZS=;e>e@NaEElg<t>^w;Qm3XFLg^isPwJclHm4O|(Ircs6uNk49K@E4(ko;$h>1IY
zJ;z=-;rp=ky>*mS<{z>XUghAXZ=YKN%<mKta^EONq5Y{tOIB7VzS*M4)t-phid);$
z)KG2YQ{cQRsbTo%)+KsHdXw0K_jdobRkj#ehR`iNOl463-K0SeSSzh)w8j3V8@-TG
zyNXToTt8}$1W{r3Nyy;kG}(S?D(sMgl~1@8a~DMl3AIuQO|>Zsa0|a|lw_yls<~cf
zs%xL%2H0k!x&5OGmYx8Op(!2{@R5{9zY<GDJlf@G18O!mKg{C@YUX|O^Lq9mQv%|S
zhi@{AY4HahPpL?Ei=0mtYAn;mMJPdOn{QHAkbUGh!^7iQ;=?Xk<GYUsGYP4P?XEg)
z8HefIo2#>)nh)uw3p*06vpEQ#LXkiW`#*Xyusz!<?Cei`)>{WN>z8FCqwgJm3YD6l
zeQtl{*0ykGr=D;;QPEm$@*ZdLP#z}?U14-ksPy^o)@6Lvk_ig|*<d3bxA8dzqqrUU
zIrU9EfvtCW=fKu7g;LvV?VG(CJ|DkYmAU+z{?DHKB(ntrO?-4f(0ZRvC8j#yd=aTE
zWEHJsE%zVnl2x4}MBc))Jx!{m@%EB%<S=%LumPzG3~v$+YkPP-G)ANa^62VCD*4iR
z!50^I_<bOnlwypbTkj$MG$CLE?@|=nwCntTpv8$o!_6r&iwCy0CO|2Hv<J?@R2s1T
zdFZ-jW@mfu+KvBB;+8AVfch7KGOydKz>iCiIlJ>~KTy$E$cEgy;qzXA5~J$I&Y_+e
z(cXA?l5z@k<A85&o5bV7PeNF<nZ$O`!4;(U>KoQ2S*-VF_uq_K>~i$~S|K~8pL=Rp
zKIpImkKZMvizA;~aCKr&;xvc~|H!kAx;ry?DxOzf(e%o31#vXtmiuRyLWMQUxJ?AD
z+sOUJW<s01DANX3T{KAvqmx}2uE|Ib;o?3T_>o9ZVgDz0{*7qA(}9OUi>h7D*kO8@
zw%$E&?OeTHYKZssWGwx9?ZChwA(IB$mZjyDHO~XA1ewG-&C^zC+MAMJ+S0VzYClew
zp~jLlq#-DzL$VENxwW5PuB^08V)gA<ov??DebvkM=9elbV(6W4Um|?%^?CeOL&F~B
zb$25)hgsP7%j?<hML3Yy>&Oc9@%F%F(rmeqm~ND>9twwiK8{YOb<t5`&`h%!Pzx91
z`QZDoN1!%j5zhG@pey|@iGNSsS@7G`d~o(>-e~8RAuvIqGfLM1cg=<8%~R+UK_a%W
z>Qrbn*oFH+2KI)&^;<p99r3=QeG~*=PYr*9qXSC%XqIG#o{q&hDv7hXoNQl@mvQ^^
zE!}ev)SAi~bV*4}?FN1l4*lNN&CZ7lU9V5DhQB`E<yB>6SI2GD$Bs4gUy>63ju2~3
zfb@R6T>=S-iAoxxU!a*unyqxQu)F!Jsp$(OEu9vVshv&YHR8RM|6C3Yn7uxF+np}j
z<*#aTR*}6@=t=8OpT%-uK!3t)Z@Tz{ZZ&?NH-_$BU5FxF-TnB6h$6{<zOB4nyDS0_
zz4XWXTy_fg)bnNz0cm$&F@KN@7mk@$wC@t?M!7!bK@nJPS#bqM!=lu40tz!;YH?Tb
z%P2<bZ8)nW7+N4MHO<suZC%lV!alXfF^zgD221W<^=*#!qd4%wWY(o^UNzXew=Qx*
zwjkgai+WX+aDE%oPP$C$1})3$gF%KG2GBH?Daaz^c@s-}LqNMB%xynYYMaEe;=1DA
ztF3*-*Mk#^Np^d(8oWjSfCu1j9(faJ;&X<PE$eqkD?Zf1%U;GdU%m<`qi#Jsf8g1y
z7K^Qc%l}?Hn$e^@{lghp>~UQ1331J5=prR@(-p$Mo%K+?{Eca`9-i@W2JsM9`#{_4
z<m9tnz&$t;@YyWE28#rJHv+LylfqHTyaKI-d=4Ng-x|v?X}J&wWlY}sRPXqxZbRFk
z24fRxsdLq3V>j>1Y^<ez5L%?X6GaDJy55^~wO?P?I^h>CyR)*1$}df>JPiCylW6hV
z*85S#w2Lr*cO$aBr`EAcXuJK?BXr#;%Tq-wpFRf%K>lqhAz@A<+f``pZsIv!lV`m$
za<)&&P|-SvF|!6i(E+fQ)Tdp3PBy=nm8`3kxPO{rWv6k2lF&0z?`0y;YU=@@j0EyE
z_ekU#;@#aF5`x`0RDW3)USvPNXs8rz@knic1}We%HWd02W|Hk$e*?id2LbLp)XlQI
zAoN=P_;UPgpKut8mSVnM!m;k3=Q)_|d`d;RIuPeuv9T@z=FE$x-Wn6;)VNye_FS`2
z_3&bE@~eyYq6_1-E8It6A<$>lXki_39Uikwd{Xf}QgY4sBJvtN6%-YNW>$mY2l8F*
z($8=W{y#TvFkSBxt=tX~WV@Aa1}WKeJlv`47PND@6p-6_zHh!@l`-7B7NWQkZ;92E
z6)^nRrRs5`KI2ojyhTeQ<df%dnTtPfL#1kKF{5O~&a1;<^CDU|N+Fnmk@P3kkUQFn
zFjZd<!yZrSb>Kz3fE;02gtCWxShH49;Z$<zGx<~HMz3{Gi;2;68B=x@Gh6(K7>9JC
zH<>CPwUY;3cCKRntf`MY#T^}NWOg)=Z7hx~noZUzrx4UN{MkgAs+?#@BwsFP4$_hX
zB@2Q`W4^cEI|>|m4lN?FFjF843}LJ9Vw-0<byZIiO<aOG3{^meQ7SWj3iS)*VhNu7
z#S=mwQ1<Xo6qu5`&#o3gi_dx6K(_K}ouw5>EC8Zs;Jyb<{wCA<FCKQGT7GT<n>I5Q
zbF@<UR|N}`K%vj$lI##L@(OD<ktn=bj=c=R4AMHK9JMe#loJ~w%>N(m8KjxTbmyvD
zZIj0DKcWWJr?9N(8Av<*D3zM}8u39P$q@T7kpf1>DX`)DZ}>ND&mmw@M!TVORD--^
z-BzNM(rc2s$3<)X!qWOhT`%P%UnQlDI-om*9|biBnjsruo1{+GDE3w5qaD}gzhWpz
zmGb4V(!NBqnK9{R$`tU*7c#ngbI4#8G3BQwvpE-izhT$<2SxOoLnurM5>^^V$}{m+
ziz7a{`&mU#9#M6ft(~VUolXZFmgTLyHojjJt;H;rs+cHO{-hvLzHm~MX0!)KiUxIl
zl}+nurY0fOznyqIX*J3yxbR7;D;O^YQ>3><&Hi@&)6#}*u-g|)Uc19Z_UIAqe-Oqn
zGj3ZYS!&q}VDb#g_6a|!o=Pc|8!c(>>x4(`D%0fa=Mf3}c@8isX~Zv*0=UFDBcx!j
zZLbGO-{%U<_E@1AlUtcG2_VCC6|w|{f0ZWNO1N(J__%pmqxtN2%UX_iLewgbaS?~s
zP^P99)W4DVv=Cp(sXdm_j#LK~T49OF<nr_vMUuljzMJ}LN+7;ObUd2^vmF)_UwDW@
zzEX+}i4voBUL|3Eq!HT6GhqsKBt?Rzu4;Bkw_ZLGX}*m_fze?-j6&xZhx}8{Nof~m
zXSI~W?p@ShCLB3Fy?H~l^?z7kjXB1@trP4X#1<ZK(dmhUaGq7`lj)MI-&y!8N**9@
z5Iy(SY**=C>r~@Q=igU2Qa;uN%9r2$HhbVF@l$&Zmioj%QH>RX`^(viD<MjFzyEL8
zY5t%Xp(Xee2M^C@S!;^h?hn7MlE~#(qZmR##sxz-i%1Gl*}PhQxlD@9(CQajrL>+*
zd;*cD_qmbn@ngJ^2e{$i$H2B0)2?*{t%>q^*nX~&Yll>{gx-1P>m3Z`{3O_7vPDrF
z^bqD~8LP+W5fxaBCo(ZlVCG@9{2ORrf)Cc%PE_;QbYs_}*ZOL)Hcn)+g*yqUjMCV;
zNap&S<zE{2MKbejiO|FH(q9N3VoU3Ui4pZc*GnUZaW<zY6#~roi(jNzpUG}ID>714
zYYo99+gu$~x9tTRC*1_+ABs=<3Z8+JBACBEUN9zZ>f7~gaUZ99t8U-wVi75Jsw`ld
z#Jw}TK0MwO)cJbcDqC2+odIiRO30JCrT<KlKpuU78%3nJf%&TMMVZ!F5>}!T?)mSw
zM|A+t;FdV>38lafZ|n4&q-(j5N<2%x`!1|Rto8lV>&6U+1N@}`I}0KwxoS0oG|lOE
zUtl59P+X+*Bk!yE@^PH@_=yjNW$}yE$lE6`cR$7Mj(I;A`#n|Q<jak;K0-RWvzA5#
z6A)dLP+dIQbTmqg#<=r_uy|3<x`Cpx;~$}D%3;v;Zj$7MtM1*?^}d&UzpM?+!s*#G
zgx|b=75@WkK99GJQAs9@19L59su7h9I|!|WpqqBEaCXh|JCTe}gL2`Y>+bcsU|iu1
zWJU3Ukb#vUdjI@`Zf(=Z8?96qg#R_jKRR$a&l(#os;}Q>_L@)oRTPN?f<ENM_rv`d
z-nI`h%KW2UKhC7j`$at)wJ%OMw@0WG>8}uu09%CAN}7QXCUu^!6pHZ5J=^*)0G8tD
z-rFi*wIqJ#TKXb4xw|#^JYuBdU2YO8e{F40WZWZm^&I4zP5b?-T@U%|MoBm7)SR}L
zq)skXfe5OFB_032N#XZlEd1L?B_|-V?d`PBSUgN^JH=Y?ogqC}(^{9j^K6<Fjk~G$
z^1kGhraqP6A}th5kceN?w?D@ZG%cP932zws38W*wFP-mHn)4&fulcHgs@1_LXb$Q8
z_?QaZ5N>hq&^7(iF|c-oR7asw)BekYV-v>)OO=dz)>DI(Y?1m-pV_7nVt#Ei4`gD~
zf$_WavL|NnxvnX^cQPo(ZH%%E#_zd~YycfhR(<goysWAwwW}-NuN?2+5_hq4m|lLJ
z3^?s-rA8;v#pe<tqRx_ZTo~#4Nx*M6{qFjL?<g_5nCxL~*@>9rS;1qqE!Z0XLRC7g
zW6c(vI32+Yj)x~G-K-`(jA8*5CdNGit*zk=rthd;aX7vc8A51Kb@$6N-Dae*!@W6*
z8>K)-|5g+gz{}}Vwcy<Dpb>Qs<N4ylml%|Yb`aG*hWnzuoTO#=7_EUQT`J7UROe>-
zsQ0qrmr<Yy_2gCRpJ%Hy9|t=2w=qg$&{Qz6nVtGb4?!)!J6xux{uM*in@#tpv1v{d
zmL?f^wq+m(yS*cknumAfSxLRbT<6vwG-w1F5#YbN7+to?p}$)$#TpR>dbT>>smP6f
z5Ao8A`#bs^lX;hW%k+;RD8sjh(B%UD{XW>d*>9@(+AcfXzeAvR;Fhs(TZyy<nd-lr
zE-JmM2&44gz7<0JdL>>eY@kKnx|if(+FNo?O+O>8tvy%|u2|c%Vc2~P_G;%Fosa(I
zU7+xKz0UWOE!3+CQp(q7NE3CMfg&z3lp$m~vnu<beh{%4JzAA`hG&I24sj|FWY4Cg
z(~XZ|yly1`2vwN-Y6i%0nQKU(_hH-o?Iz%CX|I*ir8(NY7d7G@NZVu}PdfE)pc-(o
z)l|iv?};h6TgJvUurv#|r(dC@yIor%rS!^WWNrOd-0MH_f`>l!UOs0Gl{B{E%ZMlz
zCBCb(Yz*!XMWeL&;l^RrM-y7vroQ9S7XT5#3gnAZ{a}wA=HwcyR$?5f?t;BmdrsdN
z5Z5>JQL~+poi3%-QvX7IGh)3b7*}B9Rsp}Wk6s!XjPsX)bt|Z!iCP-tY>D(g?Cd}C
z<)e!EkE#7HJ8~VA<U-R4#+AmvrrAx>Qr>db+xz6kow^DB6~%zYs4tSHSf-9MnjC&V
z>2$eA7B_nQ{;xVVmTN+Sma>Y2(FvC9%%ehT8DDAg-}-0-*#kk7dk(Dn#9Zi6SO%2k
LHRP&g%tHPPeCZ##

literal 0
HcmV?d00001

diff --git a/doc/assistant/buddylist.png b/doc/assistant/buddylist.png
new file mode 100644
index 0000000000000000000000000000000000000000..40b5a92382f1f8e002d435719e1213f33b760048
GIT binary patch
literal 4347
zcmai&2QVDo*1%UMSQ{jI4-pYjgXkrq1i=z@wIF(w)izcqdZL%rds)5L5QMOL$?B^H
z(V`_R-hTh@&6{~M-^_Ps?z!jQIrp4%XYS1T-5dE@>m}tK#ybE2fKp9WSr-7nGso#*
zQhb~&w=2lQ4P@_CjXVGVa+?3?cz_H9J#LZ2Q%&;)$s#!c-W>@xt4Uq}0F<GotN`|z
z-_HsF>)B;|>n7uf<mOedi!_#h5nm+o*h?izY}CH8q!R3C@;vUB!xD1*iH||L3^moD
z7lDWJQt*>Oop)3}5#=Rrh`jl_8&i^Ed_IW^36WT>yn^wG_i>@@3WG%M7x7Gr>=(<*
z(V~MVl9GP@2UoI(u*0hk^OcLCP0m_Fes<E}BYE}aKz34Hl3;dK7SdpLC_CvI8OQp~
z?$4jOFa;1{{PTCBjBRv;3ge@}|7{jL9mM|ekcwdmzt`2$X!dMdFGiWu?OJVD9<&U_
zY_KgvcVo|go451yo(-UYH)DT{+I;n}>Rb;N$KLVL-l={8^YgpBye!l$Q!mOt;?CxU
zKB0m<TMl;Td|_O@|6vkabT{$3<Ym_u%fVu6z3<7^8*_i?_2n6^1#h+q=)R>{@yC3+
z^rhM0lMoD&b=TkB)`U04{;mQ7BM9Ub6ney0J`j9yXgrv2jJBj-?lqZXDOu&|l0xk-
z(P%I-2NK|vb^gOI&Y=e@-A_NO8m8D7&05t`P*5D*hnRHD`uE_qGu)vB?bvpZz{qLu
ze)0SQyn^zkNR0icmahf99$(CDBp?n9iuB$jurQhp(531+;D0NeUa^9Qho{&dS3T@C
zdJ3b9cTpYoSs$OEv_F@kLzFC3Gp{5ejtBDAGZQA@$WC&Giqo1E0sss)z~>L6)1(YG
zsneQ{m&2H`w8Xv+2$1t0sjD3C#rtyB6B2(8_p~%J=&hZM9;WDrQMnCFF7=ntF;d4R
zXG7AU4Sx#CdZMaDqi;>ksaE$cGpaf7Yf~175h&~m!lxDZlI!@}T~}mXQaKWbWU)s|
zMY=<qT%i(rD^`ZxJ}(68W(BZIXZJ_{`1)%s8`}~IFwP1;bnL>f;pf2ghLHmVOgsKe
zMiFMv_N@k}$0yD(T_;FGXSx{K*1yI*hOXWRQb#KDCAaZYM~2pa+<4<G|F#BSeghna
zLZxMX@Z4)#Z%@?DNDl*0LyS$$16XS2<^qzBCWSL-Lmf$ON^_Kk>Qy=mx3`Up2VSmQ
z!v}N>5;R0V{M}3q3k$0vnQL-g$xcaWa+u*O(tTvAZ{ylskj7~5+D*{X)d(~*cL{WO
zZb34IzZ$mFV>{Cedjq#NKwV=z=M6w#z3=x1k=cMiA8%w&7Xb2-f6v%>ms2Vxt^o9b
zuZS4Dn->1c)#=7AyYPkt23c}TCOMoM=OJQl@Jf`nvGhB3+IeWSQ0mv^IE>2Uq(r>j
zxn~>Z#lif5PO4lA1=oll`thla1jBV%Sy?1NW<h!ig9?3t)Zw>vU%tqv*hEJ~$^Kal
zY4<+7GZSmrQGDYg&?Yd=hQjILBBN$ax^UsEk`}>co~to*Kf(>I@i^)N-r&UG{Fv1I
z1Sm9Lsx7i*>Zk3&E5hfl@PJw3^y%&=c~h9Sh&flZDae=CW3=c(G{;s2b$iS&k^3os
zw^MR&cC;(0$nEKnub!&gPO691{ju`z8OQcp9W`i6#L^TM^WgLt1Ll32kfYW}w1<}6
zh(wl{<4|;cE1#Zi1j~2Cn`ANTp=b|*YxlUdok1zp2ML+tuJGf2IxbdkJ0k<W<k{(I
zuz|sy8Gmn+-GhvKWqVqOUD-zmP2g0ai%Un`^dZ~i>XP(mT8))kECU%?1CsrNeuPN1
z=Fau0!H(8cWxcp|2WJSuz;7wQIsL0G*Zqf(&tZrbqqeESzh+aB;!2pntRMkUng4~x
zMcSf<`|>Y}wLlpWR{D#y?Dlib9mbO9K9@lR<Ux0V5eyIWUOUU^yxo;KrnAP<R(-FY
z4Sj;0a<&e#AB(Ay_#z9R?in7ny21V>4zaYbuuul-@+A`!5=vkFsy|S<%32RZNZsss
zDl;3oHdV*Jwz#wi;?~oFTpCATH@>!DZI1ofmRl}Y?ssGNRGD}xhCRG2<cP=gq-MC~
zJp@`Z<I}2i5n)TQ>Ld<e-Xjh~Tx5=&5}^q~v`oX!&N$@Kw~=ouN7t=c<5@Nl&5+u)
z-+xI`%_%m@N&jM?5^tq#S|^DL8oym?Yps7z4|3z49S~TQb)D!038a|Po9}|Csj2Dc
zwhO8o8XkMxwho?+sj^RUB?_{<*M3@9CACD`_T$s-Gfk4-iw>o&uIgAv9+O-D`Sk2o
z$?nFrc<)8KxwF6Z<a4j!F4P4S%+EHfR@gx45sT;nE#A(*cfEaz5{br#C>WCEtsj!-
zUM>gHk>P?Ksdii$^_;|~8Gg8`$B(u8QIJH4(Pz22g1_InA!$>~>i!d%f4R^0;?^qd
zIRXuGxIyK_n4@6?5Bsm@P6Xt<B7RC!+);ef%xOp_(Rc0RHfZh18_a`l_fwqiS=V4u
zIoW@zK}!lh<$FNcSFpt*iz1zSx1B|ic3FL4CrxsdoAl$J9BBwa{YXk7%#uy=2H3_R
zpJSzx<}pjTzn{gu<b74$T^ZyszxQ-ZxLI~J27<NlsgwWlPRtwmK@y*1DgiR#)7emB
zz(Q&@4GLh~9hpmggRb63c=>W^VJ{u+sE>b`SG!V$6Qt){@4J`(o<GlRF+rvV+&1ss
z3K0PTRAw_~+)LXV>L<-}6dc{gr!_}&%~|H!AFtdzcwP9BEza188%H!p+g3Ydx@Rmq
z+%NP(3e-oBWMYn64XEfBnF_tb8z{jb8YFmuahLlA2z(UiLalW!k5`EZh2*x8)W0>P
z|7a~^C{Fgx4}psn(NOy9;rArDN(7-J8+=7>I_e{vcf{JjBRK?e&+@2d?y|Q*<Y`@^
z@GYm$Ce@+0e<f7LR~1)jKkR<uECv>I>q^o;LBI7=9DUkZ0sMPa)=8RnR#Vb|b(uxN
zg`m7AT+m$cZ+GDcZ~Dgx&oZ-3J*rbZ`(&o_2wg5P>N(97=MQn!UzdcrUPfWt`HNcS
z*c(lpcdG@nNM)>jX^A1t^)9l$5Ev>){rgoebgfKj+Vj?LSirwP?a%tW<=6o4(ATR3
zxNUI9>5IuR)wY9Ob6CnOkPs6_Id2~{nND(ZF?+jI`zmzr`uNv)rI?&Cg9xhH@5RbH
zYIxMu7@^#mW6@ob1~2xHZjyF9z$9-Rnc(o^zp%v0$qjC2`7Cn>0wU}w06H{g91tmh
z8tVTK)Bo%pAc;SsS(K5HxxT)}m8T-ziC8XDV<`!HdwVr)?SK=MxVZDY=h^PeA+oz^
zeu7^`nnkeqA*)V2=97@j_3r9>2>|W=`^#PaOo1~FsIf6S`YqVbK@;UY*?Taqh~kkx
z%$KH)hb%bzqxMsW#ZrO`+wAjmuY*7vqv(ENLH46wi())Lnu=g7fI!gYTa~b8jaUrW
zpm@k=WR~6P6~Crug*EXM;0PN!NEz5|zswgy)<i6*xg6V<Rz=E4NL)+wieP+=v21ti
z*$;<^WH<A>Eo?A~z1PZQV&9n3AxcTjZxoNm78+JJ+rJ$hLC}mo8B8G^A+LC>jSM(H
z*YGoeK<r@ty=|$<DbLMK+i-ggtw`b!_X46<ChqE<eY>WBlyF6B9kco;{HDuoLS{_m
zGXyna`YD^tKP~bT#2wUu;6qs`WYF-~AnqLN3#btV{~B}@jQHkYOyj-DDQdf6P%7Mw
zrKyKab?A@SQAP}BqGFz_&txRAvN5(B4XVZn8Og1DPRVBy`WVyNWc3nWz%9+wASU$C
zjI|aUm{(pvweSr5^Wud)r)X9GIz&KgG0rz)=AKRm>X;Za{+1S~vkW2Ymvf!!7`Q9s
zq}RVu1kWFHA&-SP3+ZodXQ5;bD-+@|^Fgp}yMMFNYA;^Pd~Aa4(qu^g?^A!Ns9p7u
z<F<cvNs`?b{P2W>xYNm*mr+s)7yE-!-xxHaVo+_SX7+AsQ~4Dk-Rd!OKGrpPb=U+C
z^1AhS+8mQy@suRr^TNUxB~pg`b5vp|6B|bbv)2b*I427U8kF2ioGMl^t@APxA6<_1
z48V|1Fk3)ji<kX*Q2tjy%C-yfC!e>jr3()_gxonENmPm}XRcHB=F!vq=Wy6mIq7hH
z_s|lX)Q!|2A)E*+v5C(Y{Zk0kElaXN2M6Q-Lv70exBmZ7o3z?;saaJpytSB8l}Xx#
zrNjGC5gJ|FwE3I3v#HT{+z?u?nL}GIP0N(nARyPFLYMr;#DhA0vvle6Ab589lz-L9
zSZZ3-H5qu8zo~DMY7*0G%u@t@YV}}%b?lF%cO&$r?l1Ryr;$Q4;>LK&!+7!)!E?SC
zsG&?I4VB{O`mcUA70`VbpY@z(dq{yDMaes{;+n$mm6|w7i?sDT>>k<cRp9)r`ha@w
zkjTrZ#VmaLDwqolKqzg(NA4~g8XAC?oXEXbSkLh8@<|51i&bCzna?z+A@-faF0iSK
zD4R$+a|@XOsgbJa;1FG3)J+z8B*Q9{85Yy`<Ezw1Q?PRAcQ&Zb_P;YauIKul1k-*O
zwuVcH&Ds!H$X)K?b-MXWclhPi&F}{`H5{`1TItSNu&UwD%*whRl{&06ZPhIU%R0cM
zC~j$r<tn2mN-er-50DBT?A9W~`iz-q8T}zg&pa(YRJb~UpoQ@VM?}eYhgh{#rm2xW
z#)=UJBiH2YdH%N#up#UNlblqs7W_}-KlvEYd=hEO`{7e*d5=o*xIQFuj0@J;-+kya
zP=mxIQbVy-;lHJwEAP{z>^>K+kw=hFv3|fFf0Ob)XfQ^)x0>=K5)l*QP(9%GW^HW^
zc5xu%0NX0nzdZUL&}Rf@CY~02ga7(ve+J))Wm&lxT-cN8PmDl*%E0hrkA~8ya<McD
zZfUgrN;$2|lREv)enEY|*jfe*r%Epysd+<No)w*wKIMQJCfcBV#FV{Nb3xF<S=LFv
zF(;|TDPE{@O@S9aJM$QM$2i##dlhF#A)fW5BBTn;W<u#ag|3_ET+lrZ`-;jG*Uoyr
zX)M+PR>I-n%uJT7|9rtD{_%PPib+qzxY?=GGD;0{q~hn`@FcKLv@=h!p1bi<<#d3f
ze^aCl`=F#`L#%4K4r98D5iHzjdx{Co*g^(3dljWrG&_|pX2kpW2c><ccl<*l)UDNQ
z^R*SrbUd{42%(euIk64;V=h)h&&wHQ*W^@Q6|Jf?&N*Re#y*LV2VK(UXLnLZ1q2zb
zD^Z9v1%GwM?aGr^_j6b9Wujl;1qPmoZ<0-*(Y|}L$e^I0yOOG9U`7x~&|_;PUBs?!
z!O>Ys_>t%0pgd4{*b*;;q3^q;$h~JID)RSux{Yg*iqKsPfiJF}7uLka45dM>zds{M
z#rBPe<Y_{H#15_ATtX?Nlvd>91MH^2*oFJOee5c-PI{JB2y~AMajkog<-K@@Wp+;v
z*8fd&x!6C_lK5Q%$1KvYk_wI1(Tk|HG_h2AxzvigQjCn9Iyp)7NNQo~z6;iL*=+wi
zN952NJQM{zu_d4KM@F(WSp2J3X`nN5+_SxxDh~%CgbKL2O;|>t04f9$DtvnW|1JEN
eS>L<k+p5F8KG^$^PTa=@K<$N=a+RV*@V@}BU07uR

literal 0
HcmV?d00001

diff --git a/doc/assistant/cloudnudge.png b/doc/assistant/cloudnudge.png
new file mode 100644
index 0000000000000000000000000000000000000000..b6f9a657e027b0556628d5fa1e44e9853b3b2bae
GIT binary patch
literal 7332
zcmaKRbyU?su>Y6NOLv2p6u3xSO1hO6=~Sdsx-X4{v@}SAG#8{>x|NW;fYRL!4`2Mw
zd;k2-+1Z_$opW|}Hs*8Ad{S3c0AW*M0{{S0Qk2zv8h4&3925DePs!BGdK$2t6!lyH
z0EhS=Apz-`6i-SFS0xoWj3pF&QbI_MW;GfB(8wssN@;n{@B8_963=E`h~~$e4}P(G
zPlJ2KZScJb6+=;(2d@ams03%suz#K4AVUphZZYZDu!WmgUF^=NB|2nUCMG5A6aRLn
zw#osSCpzT5Ze%g-{2>V}{O;1BT!0;($kj5(Zd}|m8qBzXhb3$LmMydU^Z6|OI}mpp
z=Obx+n^`hS38=_HrC8|&Fw>nN=LbS&em#X7VgCqnB~8o&DcKjU<q3lmauZXYjLc7_
zNp1$utVM#fdBAF@mtfCM7HoG7L${pIA01z&az1+%8OgNB+}N;y<*lDvz?S&oNB;go
z|M4V$E_WA+B>(7{b1Q~lMQh1dMGMR#fP|#nA=a{BGtd+}cp?S%)c%M57yD23U!o~`
z;HFo2&+6MPCn3*l)-&eD*(RU1(%jxDHq0QM)$^jTK^{*{l+m$Fp^qC^s|RCv3lr)#
z@*B_OV#R77CR<WSzY_yfSi}owDcIY~uFg6{%-BKTNWAd;-l^0tW(C&zB)u~mEMu$c
zrCNCmFs#JzB(PGBhh9R`H>`aNYC7-xWcs>vs<xpwxM>o8KE+U8jsj&BZV%>1e~QkF
zLwg|qsAIdgpT(7>>q2cu_C$K{@UzOIqppIVf#G5@Ou>ugq^O7`W0b7$7i)20gOMX$
ztv)}Mio8V;e^*ztpiuw3@QsoH-Q7oW$+FVpa~=N`i9?^Nq`fvK6JEwClyiXG^H+$v
zk&$4UDd1#w4LU4w#5qvyR8{0pwC3M&ZDuShthp#-ER!q#MG3Dh7zFX-hqqg*(l|Q{
z_QqYW9@pZ>rW8`}8sUn&tSPd2U9y>pc3lF1BhmsEu9wk4*Cp%_)$XB^=^jb2Y4+b7
zMss+!!`3&Cu+>)9MuUx8B&mbi(I+d6AF!Gj1A>>`N0CF<E_I)kp?{4~RnqM`J#dk?
zTxHOEcxd`x;3j@?AYi%QBE`ELr;*sxKiu9s(noUIUYx@c2og5-v^*rO2wQH3UUzPC
z*}HRomY)m@9ZDqu3=hw1f7R=Z0M$ZNwtYic6n0JCt*!YzpIe*GzA5MgP2Q#-R=f;o
zou9YpHzcJCu$tLJ!$-!hx|O{DJ@k7tX}3cB(YmmH_VXME$-3;=r~ww6UkRV<y60SJ
z#=AP~SPA}xg{s(4sW1Kkhon7=1CB3is5<+@IaHP|dR+u!C2G(+`xQ7;XfIOQ;j8xu
zj1hTt@-YS!78ULlQ5+4DD!~lTY)gu;&FhVgjlXrS=|zW7KZA6tCF-v4tBjjNo@j4+
zLU1`K<-~xNtAlv5#IG1(I~cuV;~B=DB50kJzfg2WoMD*JQ@HaPv9k`h8&{uvcg+<b
zXPxRQ;SndcW!T!Dl#VU#`<CPt0E*Qv?RS?CevjX5KdJJ1E@Qk4e5gsTX&b5l05KYw
z!nZw-Y6kCh?_ep%IOJ9P&FskhG#aEI+LrzOIL*2JzZz3d&xxIZfE88O1>qI>@Ox(`
z*ok3y*01gNOn++$r$YG#B$X1eu2en5>!5;j_RuU<OCAbkmc(hBrsb))gzPS!)du?R
z)pqF6pTWJe<DTNB%6`C3MrKv+{fmwETDS8&g%iM#2R_!#+R?OUX+Yk7VbtT1J%;RL
z*7@fPd2-8IvV9qO#R!ViZ~hfq7n8Rbu%L6jD&N`E29_uk@zUn)x106$Wrokk&i&pR
z0nx)c&Cvmxzy8?XDaz0Te}-ChzE`Lkws-%kqQ_yXW@B_v2Q1;Pb(c;sUT7EknR}Z3
z%!8Ea@tu$olv>JYfK`QMMHC~vXL3>3v0?7%ZRs}$Vq|@Bn6Tn^&lsIj-&~;gwXABt
zWFFbyr*dR?SiLv#daF1(fD1{_`O6Gu3)$P#GZ>GSNF23xe0k>8W<BuuX8xj8sEy4W
zl3ss~<0^E=zp+!!1REnZ@xvApr6_9&Yun)@K)WQxD}kQ?#ztgigrS*oaO10Ybw6%3
zrWuhv-6lC>*vvVj7TgDysseCcC;YKZH*j>lL~L!LR9~;|NzfdWJMMq}{0l`lA(J5o
zG%kZfVg9vX5Y?BJei5vg@TzcVV1$I73Z^(onU;3$=Ekq`oMqA<GrT>PM9jV7Tle{C
z&z}!KHkbaoF{3Hp>`c{EA9A(cz2S&OnYDHh5gnr9=6tYkhY_G+==O^82oIySpsYxs
z{}S6o=&j@9p?-9Vdr;4tPV12Rp-!3S53a-rul{Jn^f(JW&fKXblGOo4`N3B3t2asI
z_rcOeb7oK>A)xPv)wNy78k5yebL4hn_0nnie2oO~r9Zl*398Dk#BE>9sP<iYu@l7O
z`i`#?Yb6}gedv;*Nj*Gw1NmY!Xp)R1^-^aZlYtky{AX1Q**819tbz%4_%e-d_@cw3
zjvlbvpBQs-Xmh{*=<YCIKeP)Z=_59wvODj>EAAl`vwbXM)b^b0Ovn!&Zbol*&L&vo
zch<rxEIj_iHw#H%6h^Mm$ixUFhh_f#Hq4^d@xWCe|3ckrr^Uy{XHIVWQ&2=*NTY4T
zyl~(foAb*TbqpCX>V^a0f42umUasesKHfqr@vhT2^~dA(g6IchgR7;&mE2y|*W-8J
zL&auJNMY1Kr=9231HpsWxs$Fc{hbZKPohB(wmheE{fAtB`&K*oS=-JI2<ZGdf{SR=
z;WF?nud_S+H0HIXh5U*^SU?zV72nYh9M=bPd9M^hSSp7MJon&yhuV6H-zuS^`+vF4
z1lk8uH8kE_&-4ZsM4^nT`&@xc15->h>3vEomgcnLV4>E>vySyT=O_5)eb~gpI3K0Z
z71NbFJzCKSr3a1js-V0(qn8p+?feebHdFF)g;deQr#R*}!|f^gyG1k8hBi%R`{6-h
z5A8vBUTVzj*OPo?yLx_io3rf~D}%%)_0l{W>zr?Xv5pH&l|1Xjk>r%ztQc=|Y9_<e
zPD{Aii$sm~=W+4992K6N?G*r}q-WU4sIw)1Qi`og`{Sd*$89pFu7P+S(bjAQ1Y}UU
zE!7mQYQBMwqT5g9t)~TKl&<*>oEtverTaTIIPlxnqs3B;(^a_YeW|JD5v$1^#anr}
zh9hxi3EmRCL;739d_&hhK7Q;*N&b+?LVctqn+l2PIY!+g*?PCd9Ul}T8%i;(G*dGr
z@Dm$IdmpQQAn}aUs=x|BkH`x#AfaWKdKM8=Cym8f6tYVqCaWR;ii9R%1ulxVMOmlh
z+96wN#h&~Hth(m=a4hg@2&{n@nJ)91N}Fa0$5leEH&T;VHfm+lCKo^@oo1S>Nl0S*
zG+h@&{PO+=zM`&PK?Gt@Ao9c_3T1hP)G7I?j$zQUXFT`Xg^<mf7fFq@v4g+e=gck3
z(ff=xx<8=p=jq_!E-Q-q`+Ib3No3Rpk+F&c^kngIvoR6i3b^F7*;55Kx3zveV2)|R
zn>sI{C?g)IN<s79WB<A9X;d?4{!ErUFoBGJrBn{la&OJY*tx5tdck_=n04AfiZrG$
z@xn_}*GG7pTXmvp%cW;S`hn6r&KKr(4J#%a@H9b|HbMSJK`oQc=<W2#IH5$!nf)cF
z3!>hLrD5D3Ca?H-+qOl2YdL@Ymw2s6jpt8N7Z_wNk-`&0Q&K3Ubv=6f?Uh+_4~3RR
zmL?g2iOyW#LHjsHhusN32!s!5dfF}L3*zH(efGrZ#jlk8Jp#aVSJ34hlQmG~H%lOm
zA_?l-RY?Hd@i4$9QRcrIce+dG0>t>sxDlpn{rkaaQ>J|w>y2*@kgRx|VL-d1-O_Vu
zK2*G&#u^88YTYP>&OpOP#9W)cy1&f%tEdzekKS;djKBuTYAISYS+sF`wq;9BKck>(
z$ir?VDyQ#pjf9^QR_EinODqnX%Zj(khvMD-dcYQ*1PAdNM<W(ilHR{GNxeGWv=7F+
z6RKwDE?n}w$Q7nfaRWTv?Q2Ix&W?M<E0D)4Rc2W}wA{}7v=;ucm_3!l*(@poN-7;5
z>RRo$^UCv*Yj{7RSBbXl77w>rmSkHWTmH&fLwWkmX78-I?>3>RhkP0B+-BYNHBcFQ
zSUN9nc$UIW**<Uv%d?29WQRXmC1#SR(Da;mWegIo@9|(22sphx;N0CNm;!9s?QLCn
zpe2me7boB8J%0*{JTE-6m=%80k0>YtuJW3S>8@^qzym{+zHUCMSD<N8t_Qmt4sm&E
z4F&yqUw-nykJMAQ%EgDa3)=U?m5+h1a|y28nqF_jrIZLSyz6k<DO3CA&>m+FsM}+}
zQlRp^EJe?!y|WZ$2xN}msp?+!<he2fnA{azCS0+i-t`R|Q739P-o{2R9l&Pm!NQX}
ziQ%tyX*^frG2Wm5<EwBzI|}tv=mL&hiZ<jC2mtV?AI7uatJUMsmQ^R`b;6(K<9e`1
z7cp;nahZHqkPm7TupEM<&XEVLYcD@}T2;lvNMLS`_u|wA-C^3_v(7KA=sq57F(!k5
zG=HVudRM^1uE(edJVzs!ZB3=5&Hbt-GRtQn$5xQ|uohiZP?vN)YhYlHA_k?lM8W1I
z)|>RgWPCb@ZZWO#x~m4tqquu(?x0tS$X+?yXCSaLCTa(7cz}QR(b#l|LH!czt$`X8
zw?a_o<*lm*oAHMA7UB3Q<Fkkf-a7tvI;S0HBsRlT-?sYtqQV{ra-h5=z(0b!6K*<{
zIU4)0EU4v`5s0TJ@51<uG5%6KUvx}5BzlB#`9-x0p{+5A^GxQ&t%P<C&*^xWMPkb0
zJ_ey|1k#LOd`|f-uoG28_gUK9E>r5YsDc){+oZNZyq#h>n`6?ykV)A!lhEfs8a?on
zOEH7*a90kp3ag?=R#$RuSzL0ADB6zM-Bw$5u{8(?HOXW-d0C9?t=3>5e28ld`WI(H
zKA&Yt$6M-kKc#iQQEV~O4q7uGHu3IZuI)=uWLzD<%ZtJNm>W5+Z?=yPo5O<GDQ15q
zXNX{6f?9bV#KF#S5^br{f%4I22njhtui>vwj*YNw033R=9n&X4*Nlq+Ib<$Tf%Jwe
zqnk5>Yxu(3S8;W6Qpq}VMx<W%lozzfVoNe{$qR!KVd>E+lM^VmAmq@$w&r&ZqCX!!
zIv^bo#_cRt@|J^EUT!9~v$8Gj&yj@%O$nYcMZ)peJ95iKDQhw;D7;O{m*OBEy?Qwc
zec)<<26>QM`WTu1)>uDSk`axkJ7`~6XXeTv@%~n=!ho;}yEk-~Kvr!VLpqV?s(!oh
z3Nsz4qbVyAIkI}2TJ_KBcPpe2Q`&?RWK^$P!+}*Ko_aVvUB?`!EVYifmXLw~Q<w{;
zA!aUmJ^SGNDvSSK!M^Byd}>L6gRMU*7)4f8?L=xzw2*+2=`{&~Hv$PM_plAcI&8_Q
znAo8|4zEg01hKw^h3VIW0Z~4oeoS1<g7MRJV+dMnNZu>&Sg<xKYz+rB0MVCMkCU%!
zW3gd}feezg63`#!hLbDLW(Yd*0j5-n!`S0+)<p(}v-5)Zy%4+yE#Q!z7vz3vfA4*;
z=XJVLYIQ_nTU`XVj1?5Jlhj~>d+xvD(crZp3~~yFP0XT5vA7-;BS%2NCVK~E*86Ok
zg7~mEQ}v9t;xBut+>!+xr$qpC^{Kkrg(2G$Y;Dtz-JqvDf#0~Ha8-6|`FO3V)>C*|
zsS>CKl!35Vhn$bYnvTq14MqZRbvdq>*tnM_&VHIpC|^zQhZHMrwz{5Ui1K^Y{=emG
ziAAn-kP2jfzA`f0hf$XIy7r79dG*N-hFh?-V4B+6B*_Q12I!U&GP9DiK3il+?MwYp
zPI1SBbCpG(OL(LI1Ik1eK}+%u>4*qBS_#<E_ind40II#EI*-c}I`N_g>JaJU7Xuk+
zN8@S~8&!sU6fH*uV&57AAMfL_KWYw6>)<`PfU1Q=!l@|aMQH*>lsnLeY3GQ(?!7Ve
zOV$^&gx6)*)ah?DC^*O|*nao71$7fU#6dU-Z*D>tL+}FM0+jmtrBR{*J$5K3KNEEW
zKvS)mnYF{@%R)<qsOW*AF7Tjq5O|TnM3?F896#-v&|C{>4MBcCKRC<;bHiDLME=QY
z9Ir|>dT$^+F@cL2&t3|tY#$fak)!Aaoj}c57&2FPx>#K?dE!y43Mz5<VQ2{}9IiST
z6OthbHVJGPY|q5R{~5<vLqt+*8bK}wA-uULz9eMrE+U<l9w}>`9z>B?Sb{}uTd)ao
zvkrc|_tF?w8Na$bJgkGdu~7*e2-Xrl^ZjS~{~s9e-)P{U_`lfyzxWS5um?NUIkYm|
z_cvYqyvcsf6$}o3gZcVRJ`Q}%WFV)Xtz_F-mROq#o~c`X8^p~b0_Bw!Gpgm0>BQEo
zns$Kej`>TdRb+k>Ts}(fO8~d|*UAy*u7c%c4l$oAh7iBOv_T^+*5F{`ugbCWYGaGZ
zE4rJu>^{4%tv4x~T&g2tydi15iPRMBXWpqZ`F`<Qb4R(rG0IDkHXrFa<RD3IoM0Re
zSLvr~ql@a@qzdYAJhW%39bGM>Oik#FIc1q0Um7uCisnkZ$k8zz!lU%2;Y9*ZX6@14
z6=&|@{?{s!lP>%;Gabp<*a!f@u}?@quWy!G(K?vc91|b%+27)9xDrZT=MmlhtMFVQ
z{4|z&zSd06yVr3>{MzZ;I15=GDHDf39IBgpXl!R1yG(jF=Yd$FGBpw>Dzm(owD6Pp
zAj4jM^|lgzcmJ5Y*`(ALFCZCLi<4WmxJI$uF3wd{`{DM6Unp#8$Y=6{6g|kmlG_|-
ziQGVRgzW6aR&D3ZcFx-k?z0y>2By1iWX*F8-HTD;=o|h*eX8~iJnb#EVpd>3<Qvh6
z{%B#h^nF@O<s86(^~TCoZ)GbPr*l3`d_i|)f2=z}2O^0Ywxu#Ca`vJcW7&_NNPshs
zwL(u<HUe83akQPm%bKSy(CXabg(i@hOtH-on=Q5(Oe?3bY@A)chm<1F5lS~xOBQf6
zHh*FQS!#H1G!w*$z_$71e_pJX)X{Jj>@hQ{q((0xGgcvT4heWTKe_z!Q2Te%D$D&$
z<g(>Bs?7E&C;}>3H|z7PIR<YZmNg^P`9?A%9=)%9UL)?V-`ji&!>o^Z^Z4C;FcL$p
zt-%-ZIZqgFIgDEUw`=`&+1Th|w~)RS&dqFF19!S@v1NRRkf0*gD!DrUNiUxD*TX{x
zoU&|iQY?6C=8+F^y#1AN?V`n$>-hWZLxbbUe8BgLWwWJ#@B8cZl$FCh*_P2w$y^xA
zrCh4C&U&W?TkSNSEG!$H(?*Vl%0h1EotM16&y##_AGib;E|R8LeDyt6(mWwI2i^{o
zeY;#fuWWF34cvW2`)}v>zSDt;!nG(q*=r&y6Z9i~A1@}T*n@nQ+ZzX`wC?uN2)ZKK
zv~t1I-#ZGREwx^=e8Rj)G)oEmC-nX9q&X^L+I}l(6qkw@d+m5%|60};hBx0IijxhF
zCCpD1WwYuu>s#$L%&Zqc&t2!h(umGjhuWxgBIu?pDSdrj4!gL`QYLX>k^FYc3ze32
zc;Hg-Z|C{7wQz*=W#Lr}JVVX>!2Ugy_WOsjJFVZfV2jiEe<rShTyth8d50|d4#WSc
zxJdi(rfAHz?6%n#Jhp8fsb+A2hs*?pOxa)OfAHXguaAG>5{4TUMM_Zr7K`A@(SsIQ
ze?V5O*1Lq5G~~QSTv^{<2#z%?d>las=;zeek2+d>z`gz64HD^?EpuMmTzV<$zU86=
z!s*<x4rb>sQAMvt(b!*b_&-8YgaZ25u1C?r+KRmaS>Wv#LP;a*?=5tJ_hilayuz0K
z5``AFG=#4P9YZO;4s|1QkO^72>>ee^HyBq}!@m8ri*-i$xrTzoh=62^u65U02$_f_
zr=q&PQS$RqsHD*cvuEZgzaJb0ZgV2&**;6ys6Btk!V(N`Z9ywI&OfE@;7bTL>i&EX
z*jmU=ZX=S7hzl-i4>r;~N>se@Lus9+^laks==TxWbd2#ImGBThJvoiKpmPWjK_{4+
z0-jqvW72Y<jq}IpcRoAh6Oj<E?^u4(&8~enEF$FH<*9~7H;RidqFa5xvdQqXEI2XB
zf-@M;EhG}H(fRhmKz(;QiNqTWEEb)ux!>(gVbY^1NQCG~PFcO^m3As2g-XU@tyDC}
z8>vi(zNmq0zABV3Og#NFyqs10*_g*hlAO(72h6M>a@krZblIQPySqt#SdP66Ww1v`
z4kwg*&D|Ycpg-iB38k!|i)S=&52j-fW@XL9?4FqYa^&D`F2Ck-HPLLjfzB50LC5L!
z;51Gp^{1^IQ%1WBceB?kXL?Q73jWR=I*DHk{Z0S$`Tjo3fNnJK<3>BI)4V2wU=$<n
zrhZO5bB2`LZc*#Lxr)~_@d%JwmEd-H`}^$bzIt1*V)(GtEE&rb0ijdX)pnYosqZx(
zp|drNS=bEAv;5Fqgiq070QRAx!OGe&s;d0Fy|;iE2|x3d-rDu>@_K(4IJ{JDndtmD
zx11u_C-Wma*5HyHlT;KGx}UWYCJ#TXn(&+RUzxeyKPK%+)%oq6f2QoSzPs!<*!$>Z
zt5DmtX7uNJbE`SH@_UuN>ux)>4;jAB9{+*v%ewm>>ap&hGNXkHOwX5j?RMJG#;D$b
zxibhfS}$j^_W~oc`hFG%_WS`I#E8*8t>}Z@NK4-^fC~E)vniPWPUqtKu|oLBIX~q-
zAxmX5prFcAP;BMEA-<Z)owgE@5RuTcZx<n!@e7%lx{@2SJBU76O4Oie3>~y1ROhXV
zlGM#$@aerfpgYPS|0&<y?&r$0TPw7VQ0|hz7^-NX(7k|n;O$LmVlRWvCsn-Se#3y_
z(J3PIxmQ!pB~%MkAQBrunKQxBi|j@u*&Pyf^{^g8h1*Da1Cj)lo5p>WWeq=Vg(Dr9
z1qcL3)D&DF9BBW-o@r);Y<3E+y?ZE41Fg%>dsnr!yvkKqmKzF_sLEi##4*N`Mo{8y
z3l5ibwD{^6i4<&=3l~<6K$cwgAAKo_e9U&+zP}flNQo9|*{@z&ztd{X$pYHf$K4hn
z)x<)do(eskYQ?LF+2!@Sq*hG{AZfl!bqh>%Lv*#4zgoHykDCfk9pXAmdu7t5ZOsU;
zQ*$l=%Z{qwka2Y!#+u;1CXrF(k&{xo3+~%WQ#6Up^FPu0`Kgw77!%|cEn9|3T}0$8
zhao@WO?sJF+zth4ovcpi5O*cDXLQ_N)w{Uu3kcp|vKA4L6^;yzXW!oEq1g!ViEW9l
z#>y%sfFtu5FykT&{W-Foo;E$fFXpx_S~^QcA}5S*%ygEOut(dA>*wlH2vZMSf#99^
z{U5OOe{oaLwt@+%Ts&bb>Ko*s5Vo+3uZN46>v4*GM?}g<xUZ!%6OO-DNzt2;%aySm
zfyGcSIXpX=p6Y1)Th9zb^Pf4&VzKNh(zD_o|K(M7f-psDjA(M;He=4)H-adI<av7O
kmoPCg{je|(pbrxA#GFwoPQxBg6-GcwPF1#2+BE1t0Pg!7ZU6uP

literal 0
HcmV?d00001

diff --git a/doc/assistant/combinerepos.png b/doc/assistant/combinerepos.png
new file mode 100644
index 0000000000000000000000000000000000000000..7beea71bc50461b4df12eaf12c419b8cf80c8c83
GIT binary patch
literal 10677
zcmaKy1y~$Sx1bxB;O-FIHMqOGI|O%!0YdQLE(yUcXmI!74nczjhhzqK39ysz-`#uv
zd-rZV&&+h$>7F{LPStt4Vl>p`(NRfI0RTW(RFKgE09ZBXwF@#V^!rDSKQ8nK#a+SB
z3ji=6e?KrDQ=u8qLL_fRRavABSX_Xd>#FjtEwqT(Th_o^+Reqq#?>2;_O!9|wy~!2
zbMUsOl2=sK&=18R1OO^PQASb+w0fKy>`l7ZeA;^ai?$$Cj+zChD$|wJpBFpH0HIph
z6`r-Tebn+bGIk-C%TY-^Q$3S!tV_97pD#xX%u1`rAIGQ%q^%N}!gj~iwq*FQAnha4
zI>i)AU3VvGmPl$FQCbDL<oK|w=VVsM$fP~(OEm6{UA@8F<ceMJj98%UOb#)NgKH}(
z7Q7_Z-US`GbO;r4m_>#3-#n`iau_sMiXjQj)h)b+=0+zQsVw6psIZ>JFH~vR*x3FA
z!%HSl)GZ*u!sO4~?te6YcqbOWz)z5(;Ju%rA1g!63PKJu`A|B2c*%uElcB_=vgtmZ
zBM1jXV4)#|QGL{{cm)q@R;$mPu`@^Kxu~n(zTw(cFO9Xw-Bl$V{4BC0NSlL31P?FC
zt~uv_0>+|6?9nNTI&et5M9%h@x@1P4C*=7!5Oan9EaH~tnE4i@Ih-A)y-hzUz)6#H
zDNLzEt|v^}GW~r(0<-=FNu#~z{rfyeP=u~)!(>)%9Ov2ScdnM-H=I$91C}|hioD89
zTz<O=qfvM{s48f->s?+>K~tEIZ3limtQJxi!B$(hkMnbX6Kp6Tw%k5h&i?SUKzK?N
z-8ismgb5x#sB)&T9Pa+=b>MUoLuM+UP*L6NCnP#qx?1l~JR_(OBS`9IEf%lp)&OGU
zI5zx#5!fBO^Lg`L3yf21IE2mWW;c_!(dxG8vux^jImORmfOXmr6aOj%FhrD4JzWYU
zDqjraL+$<X8vNUr+ZckDmfBCP9jC4Y4;y+N^rh))mRsWKVGUw9pG%B143`d16=x${
zh{I^-47|ZY2oYH#69I6jus67AB%0Dh)lXvYg(AuA_2U6@G?-ro0m@3j8l)*OjDm>x
zM=OYE=;@iY0~X44aJ#TuHwfp&Ua-4B$mpzULLvomo_qRtX$d@ubXX~pR1*Arcn=F~
ztgPrh72vzdS98tnI^)oCfRVub-C&zl2t^jyYdnsCh~>1&b8ijL)q<>#Q$j(bY}R>O
z9pyQ?-fyB-M#5KB_5%$iyq(xuC@vddU+@(d=+s>*K-m2A<&zF!?LyGg^>Ued{_|36
z&*JK8z{Q?o)PTnTI={8GwG7?#i^$W%<!RU97#{ZK@r23C&857=gBw#-@KMhT=paM?
zEx)Va-Q=m((Pg`Q{`)h14)^PK9w<pHtXgej@#!6lcqQ_zAjnRQmc5g_`P#1t<LWQ;
zsE*2v&0L>Gr=LmUR=6Z5@CJ1?N|H%G!|c4chI-sAUtjs#%ax=FUkNKk&ta{*w(1zM
zQXsKuYUCA3MZW2MZEtovK)%=vc@&aoSbvL<#aKBD2jg}411h|TKK2Vd;Bw5_ioUjv
zBe=g|pU#-@8YTk*F*Xlm`$6B(YVSqy^vyI6#i%+X01f|0AKxe2S7+Jv=ncBCg9k*C
zO+AYD_Nd&YZGK%)XggCO#?R_ox=x+|=kAldaYs}RDlj`v{tyeRWQrx&F|KO+k&v0+
z@Z!q<12>(yLUF0waFjgX$B+u1OwxcBy+w*YxPayQE-xvB^u}B3f)%h|*U{~Iy!B*~
zdE7B4i1Qg?L?u~X=D&KQsdQYTXFRnuy!z4HVQrA-YxO<B_UKRXg(d!@<PPGLbkMb9
zYfA?VV?v0tVls{hwv}k~T{`k~P4xcAr*{euqX|OpZxH}M;Mm)$ovzDuB|u|@tG9w-
zafsE2kln=I)iqOr_O$2G)z<bPlg*fb%?NKL-0o;=ChysP$g0~(Pm6*><hHZ^`^)3^
znLK2f_2XQ`20RHa;wZn6b@)jl05F6B`rdKgX90bI-{|yg(L!JwSnZo?f=ox5E-{ib
zxaa|33-$mnSp_ik{vm#Mnxyt}b;PN`-;IQYoTJ{)x92LzNeSB?(@pn;p}`XBk12tp
zHz9Vmr9jMqrFhgvEdz^{SP*Hg5*eoKpY!oItIe_x5BR|>9PcJup6tu;2QwN#AnKvT
zho|F%S$J%N&?gsO-cCA#c6L6eW4I0B#L@W9&vbZKn5*(CkEE;U0H@fjsZHhqUo*-6
zAlSNPk^iKqW50tNAi9yt72Ny&w&ldW8mHo9Vez)I)Pl=c^-D(q0F-kJ>NIyFB4oKs
z>vmVj&XrBF#26|N-$<$E>*Io525BXFgUV~isTcX1NlG}u7LF=D)t1CJA!AZi*#TZ9
zeVg0mn3bz0m8)h!3XWEBCB|9$!<13O4;UR5t(MKHFuy2UFq@CvHprV*bn04toS%-N
zP7M_nMT&%tms?Dvp&dRVMY%#UIb+pDt901$$pWp<mUMo+(Z16qIb~6)qJ*H?V57a^
zT6!S-KCRT%+IzHgNttQdVSl`pQJy|qxR)-tSxc&K8*x65W>`*J^3p8N8T-?Jm<#(B
z)CVW7bDdmaNHOgr1R6t@Hz~|ot#dbj(=MuH3iWQD-ae)ob?1EgG&(wZ_w%+#-_Wq#
z`}Z8t<zet+R5k_U+WX54;C&m;dkx>G!^!J!eDRP$N{DaIt^dLJP}#}*u6XO8h=5Oa
z9xF@x^$?*tkJxhN)I?|~A;vq5e=d1WK_Wj6%fgRMO(~VP77kXY7Gi~gt*xapS21r!
z`{%v`V{_1N@AR0%T=9i0wY=#rkKYwO=*?7y#F@+2lrK;1m=tRP?tv42K;LuO3!W>f
zx8Ln&$O~w4*`g=3*=FhsL#vzl+TwLRyx6KqXO>ZYqSIE*a{lV=&Io(Hb=KX&hX&r%
zYzpKg7OfJQD=w$me(wH4i^TzOBm*%HeMnC=qd5vtz&=ZGa*N3Cdm>m_YtJ~Z0VJ2v
z>&Pl54e5~TgN1G}3G|xwCSU+>#8Opr^7S6O7Yj*QZAk(cz?2|GAFt*5$bKm!QX~^k
zC13&XB&xDuwDza_q2Q1#og*yZk2k8!e{-e7yO%Kt;ZMh>FYO%>G0<4G){%1m*xq&*
z{-C)uTFpmt$v_x;2ZzJfT-VrGDOejXjxoT#nSZ5ocKUcpEk!7&EV~hT8TCfXaRJ_A
zLX8ms^z7d(eJ>P&S`Ilji)VGQo=cvGwX=OBJ;RC@L6va0<<nMP<)5%*$hT0<;`&%O
zBf$$caEy*q^Jf*aJ*{NzY8DP>rmZQ0P^NFVTub56<}qhSZ>ORhDB7z9rB!cgcY~yO
zr%IG!iSODE&#vFg{Y@V>PhXB2XL|lzOx!8??>x<u>V1tzlRwzA8Hyw4ATw_cQuUjN
z(Oop{eb3Z(UP9O**5jgU_ln7>0s^XnT=i})tw@a<<$(iO*2m%~H@uDQCPpBY!X23K
ztzF{n5NHRr4Fao+{^=Skma1j%Rx;!ECyC{_lnd9dK>)Di!>`P31EjUAA*>*7JZUz$
zs`|aspSTUOY;Lw}u7<013{*B*^OX0CbMi8_`pEBTl0w}cMv#e(flx)E$1(p}oxGza
zO@8loG-9OO_rvDmoAO*5KKZV%KK;eIkr;%q1+TRa+CNteFzV;p<esUp6;<x1P+S)E
zsx5MUbp+Sxu*g#fM9YlWP8V-JgtF+1UL(KOvNM@c3WbTuWNsA_LD{7mW2fM9@uFNo
zRO5juqyO%<N{d>NIuWbff(1iz4Bjr(1nLr2yaT$YY~ez_7iuQxWjlYa@0dTdNf2Th
z7Nsyk@a7CKC75aQ+&50Qg@q>qggNyr<kHg@KQbD_e}PvYG{7v9QA!`9aODB*UF@ky
zeaX_{@zwvBy!Dugi;LUodwc;BAtolC5r26HRTvc(RYXbI$dV?9#Fq%ui~6+uCY{Ys
zir*T1SgK;h{Ovs-GavPBwCccoE8X<=(RXAA@(|a_5{s49jD3#0#M7HlfwTbzaR-*m
zv8};|&a93(Onw<N5DpNctJ8GMywcq>*z!8fhu>D~9UFgjrw1{@#BvR5(79J$XmHQn
zu<?sY^G>3$t8p{9TX!u~npXes1gryZpQn;kYeV4d*KJYEQ@H^%b3P{?CQJU0+S<Y;
zcy~n{6u79sPl}Mv)`*90U@kh3rhD*4B?6Jwi1{2PT3T9K(#kxs>ae_j-ffcNyZ)~j
z?tHt?I1%aYMjm4X)Dj=RRycS8yJTJ<r7Qn^QPn;Hc{v6WCEl?w#8tvf625ts)^+A~
z>nBYK<$9#$GV{!;pqmnx7T5V%A_4n;PHH)c7GxEayyz6X^yCuER$>uPe^2_?^D33?
zEI!|QS(3-B_09bEE40hriEZu-#oeRH#5v5!r&|*{#ae5@1Kf197thq7ae9yZG7<%3
zz*;T`FJwUEXjI2T0-l<(&tdag<gIocI-zGx<^(M~V2$l)h-9|3uJO_@9Osny6^HW2
z*(`~{SWnX^aZ?)vMNbsATZPm^(v2rMqINYl#1{_#CA^CIgD(!Vcj@G;8sO1@S`_FW
zZont~Alug#szB4E%1>3VC7I5N;fNYA(Qrg(SUk<W3gKIHt32KpXDT7kQd^ONFV9HV
zrzQQ(A7{<nj3>jLab3PblUk9X*c(2zKW#Ca?ZgL;m(5J%lfM3`bLoQWWx7$&!B=M1
z_!(9z1Q2a`AGG6&P$JWyof(f48nuQ-(cZX2eP5louXVd(mw&w8emQ_CuEU)1MwJI`
z;Ig=H)2to*WX17y^$c{^hIp{B_X_*%uve@CH}OnG$+QhxP^?B48r!<#`G*!qtO<bV
zELX{Mu-|3HxS_&^_>NpzyzTltgOZ1zT;OC?Q@>%NUpFEGDM2>Lf@5B)MXKtPK;;6-
z0AYEbfR(vDVsd$t?^>Of(<c=)<FgI#EG4H_3|m#P*LB87HkBo(a76)i=#>kCJVoY3
zvp-x0lvIEDe27VT{*6Q{S1E&Uw7DAxXGJ5EA*+yyLqz2#^sf02tQIO$zOyB)4oO03
zutxDT0+0|8xx!sO_e)EW3BymQxhbZah^v+Sx^e<XSEJ@#T#4OeW3M58&wV52HJzCW
z{wEwowJdi!*nbSl4zkyWTQn-Jmz8bjb2yy~0fQeP<}a066?veY7<tN|H}Ai5r~2Hw
zodo=ro;epPND7B6CSjygf^HTy@Vh*Y$HYZmU7e>P<vrabI7K>vPS0Qpl6w6>hjS2p
z6o;3M?B!@P7ZZe$-oT>s@Zp*}PqZ3+?Pk?=?vk6n>Cy@PbF@Fpy5v81XKJhy-9D1v
z5%o;bX@O=9u4ym0d5B_T166E?TX28DxEnc>uXR9fM)>CmKc1Yv3Ex0Ffe8#&wX*ru
zitou!aNCrXb&gRG_31oO)a773VQ9?p$2<=aj>YNEO@}4YSGF=Q;Dn*awTC`e#DI|c
ztd2mrGRovS9eT#*x;K_&zL|b&Y#Cc(uvZ})S`2#o4W@V%_QptUNLm<7NzRh6fM=6n
zF-EOiF$|C(#{)h)u=mm$Wn}k*r&_kRhY(NmlHmIGXSjWjWQh_pLb?Ll9&_cPzLAGY
zi_@1!y%knl%3@GUgZj)pZu0Na*68iIg`(*w-je!YYD$HrpswEg`~ZQ5qb<%W4c23+
zbjq1$+3WRT0ktiSO%Qk65iU8}3)anxS?NNa=gbB+VMzJpz=#@~X=AtVMv3em_3Jge
z?+FYafA-ckLGa%Bc?}%2WwO#|Q?9;sOt+yB^Hu8dKE9daLUsEJ>gobVng*UIeB+yo
zsM?Pyy**_)en9Sd>?<+434JLqEP|9yChCjsO!BT}TRmXL;ZeNt6+JS8PtCPg{#B*P
zQp>W@y=a}%_81i5$sDU(b-B~YGB*w}VKc4@7>r+hJ;Sn6i0Lw;try_y_LX1RJ}ydY
zG}f1Jf9zg#_&xr<0(1&|exN%kHlxnKYa(i@7Nz~#ODkT5;p_7Cl(6$FMFo9Xk#}_s
zmu2-G95s^*iqbWfl4ett5raArQe{!$`U1x(DIQE4o`31}1E|+;i7#XMI@+@BX}@bh
zYMdt9SORaAZ0h}}UhOOp5)g?<Wt?5S9j(RZ_xZeizN$hJu&UwP{=2Tx4xu;ie|azK
z*PEo_sw*iQp4foq!g6{lYS6d%wJ#lu+a|?4k_8*oCVL>QB=5?1S^?njPUNX+B}n?B
zBCt#y`!=4OJw9PXNz*I;(b=u4?djNwW%=_ym<lWUKHNi34W^BV3fQF6O!5t1;~87X
z56UelGsCfb`h$VauX#oR_cp|a)|caB`>QQHxK!k{3Lk_JOkx8?t@;G#;nj<p&J!W;
zUmEd7OQCRm@@OEUWUNe&NLhOPH+uW$W^L~6Ca96r@0P`6MtbDP8tD$If;{K&;XxEh
z2E-Ns9_>vT_Hfn~W}pNCHkj*=PXr<xK8^%TxnO{TVX*th_z=%IeYErX9q`%Bnp^O3
z^Rhwd#o+68Qkf|B;o1Zk`W@W?JgIS9Bt4jOBz;aX+6SH)le!OyBO56v9W9a%8PS{P
z+mzV)J+gvDp;#K&1;9Fhi)J5F;JmGf5~@vbuUmk#9c3&)sWtj84=#%3(qAQ2m6;-`
z(HM*sy6&StRVY36vHb3nR@5ZoH?1fS1%!a;7IfD&u20&FjiTl;=MuKgFu01Dt3gvl
z@U&w#mNHnFZeTxvj^l)NKqzX<lswGO=Q3+S&lU?HvJ3%Ko=T9zkh`h|g2Rx$rGK)j
zn=XwfP$uhtwJF<??5C3Kh8#!0)=x!+?Ae~t(bUxBRMS4Z@0lweOfhh!dhqA|(zo*o
zTva>VDfE|45uBNia+tKazkBy*GK+_(!i`nmJg8Z#V(_18Qvq{j6r5-MSE)~jqbU=#
z;`FC`XPFpKbaq*TG2{K0tl0oP!ioQ1_=cPby%QEZ^uI%!Q5k^$2S)er&AiOPpFAw&
zLWq-o3cvz=KSC(J)loycUq&H}=?Qk0&b>Vsu#XA5z{6)Qxkm@!0WjZjdCkTT2NK`8
zouzQ2cvdI_^i<63I1fExZhX^PvB=1v$I$q-$AfT@Z8-y`uMSCtz-VJ3n`Wr|AGy(c
z1e~`=l&s~9>v^)?c<DANVX^%!qT$=!RSCnebbFdax_?<CPDfR7loTZ+IS{V`QsNyy
zn>O*$yNzJ@qg$ruN&HvRs0f=+MmFm=%&$m3z!qGxHf@)_QYc4}$6%g;^xuKVDl46C
zYvm0Hk1ouONJZ-9Y{Hdboy7V}D-Ucc=4Hh}X%$Vr5R1$js=Gy3^7M)~QfS!Fj@EgZ
z9Yp`Q{|x@ob(tE=oF!2gc`s!@ODt%0@<iDJ{yr0nXlLtEHeJ(@G?TS#XWYeJns6i6
z=YJlH7CMa?oOq@~kR)J}@y{v7u@d4k|JLkl{iBmT9N6F!;{U2CcxCdxH1&UGtN&8y
z|En4I8tt?EJJ?W(yBB0`?UK^c$d@FjQobuemw`6-?f!PJLw1w4kQ6Cfv3mkmgC_g$
zVF<74wqE~jlDm0o4lS4~RpwF|W%W3iB>rH@&CSh;2gR}xT7+GtX-cK<dnpGZCUNj&
zbH##$L`BKnj<Dd{1^oU3nLc^%QD?91egrAxVHnBe6`I_`8Vt#UczAy$%=+Lwx`RH1
zq+-EKvBrmid^_V8I=uWi?#%X>nNq%2?}D8}4$ZAkz+|F>&y)b5<Ju50-{2Ya<V=b0
zwG}p^xo2@GSbfQD_1(&u(9f4$57r&s#G=}kOU!H6=7f+F!PHfL_x7>(ZYS>Q${WCn
z8+t{+3czpEeX@dbGRYkB-qz~^3?M$xc))nr)_m@VNkZ=8{}HPF9a7Gf(R^bzxYBNb
z(#Pu_TK~EGZZhGca=~9#{lRi|Z7qpHlo=-m41u_H9=DVe*d-0<VjEAtz-_UzcD)~#
z^Ll>LaN|lmfU{JzOzBr;$B)2dt64~ZS@6o=@!^Co*ln95gF@B_*rLRr+wj9MfCL`k
z$v1#aWdsd;*h4^<oc{uy$XNIQzF)3#W80PvLSH-_C}b2!k3k~EBR)z<1*|>HJ(A!+
z0IfvB+mTV5X&PvJf@ljHZR_|g7PYDYQTiJ{NA>puO&prM|Ddi0a5hM*L&TOn9`#?4
z;I2j&fU*zO2*cx5@4n!M_-s|DWzW)PD5`tPrC#8S!;o^m(O6Y}tYH@weX6Xgi4}~C
z^ar`9K4!bA<&C^F+-?iCmHEtz^4uIKug!p&-+NIlegCtyjn2_Z*~6<<;-03Auq_?O
z;R6&D-!1tYK>_8nyZ6nq!DJ$e(HE+kFzU$lSu_bCg!oi^bxw3o2MEzSnbpVB0EZFn
zeh&0q;9GY%A<K1FE*b2smneGkVX}<u$79s$!v}ILewtLATC?LNJ$|4x>&k3-{;-fZ
zMeStvl<~C^TyN#r{{^5`xEL)bQNoo@%eOv>YHdTzjz#4y5n80XyB7ZyyZ%a9%aPx+
zW^$LFS*lzO4~C_R5A3qF3L3~$Q_6$xe6uTK{a(!2_dgR7fYR$?YuBxP{R=(Q=+yJ=
z7~|MbnwkgJ`JBC!_tO1}xjc7plHzzpiDV^rA09sB(JNKtPO|+6{=^-~QV(eh^-^PR
zMVVbn>}mOq(rTcpibu=yTX9OE!R+6Csh26(_QEiC8RFvLAP73!^6R<GJvutNLkvc_
zy?;^rMBysZ?z;TJ$1qL!g;>Ck8tcxkNp^jhhXFR!E7Xet_VAg%<<{$zlGG1znhX<u
z`U!ywOMp<okK6skn#w(~c7W*;H?%LSuN`-+^Eq&9Jw{^dl<O_5U6Ikx<v{az1>ZGf
z;@7wo`yOWSNBAN&UN58qUexX<LDN`6Z=%Ub{L0gU7$U8j2L%^ezh<B7-ICn2NDusU
z+1MgO6%}%<J|*Hjn!9Z|ylKHC@?C5e+?kRO(pWsW(76TQwkR6~R6Ug5gr0ojOQ6rD
ztCejGZ1r&KtSnuYQJPBlGAlYH;kSsL6|n63^z#O0phhl@t&sUq!@ONq>2m;j;2Qa2
zH?MQ$TSVcb$j@RN6{oyMF0K1~pHza*k4KO?CZ@E?PkB#V7_Ph5Zm<qD_<IGDMmas1
zc#*kVHxL0m2$B`Rw?+ia`mRyYq$yXF=+(ESyT@?+SR*l^nqub~yw$Vu1XTt?Z$zis
zt^4HpD1o#4Ruz*8p~m@X_ROMfYV=pK^4E`AIpcOrFmDm3dD>0r0gdG;c!VT+!GG!U
zgQ!KrZ0r}afuA?`%^@gZ!I-RA$WUKQ4&8B`Z4W4CvQ~WkYT96p0x^VE^w|ZwR)7+p
z743FEJ1Nu+*||N{bZoPgUD&oiiD}cAc)__lv-Xx%emOX~x$$6%7yog$rTcQ&<37{r
z+jU~QwN2S$GG753(o5+aaN^IvIgLcwbz;86>)|8dbGEMSv$=Zua>6-(G2V;n7xX+Y
zPFe2y9B1qwzR*)x@44Mu4HKenzH$D?YgbL~v+PQ+N&C&`><O5yeae%z{kwC86fJHF
zH&P}V`~K3LMP;I!?y!;T6=Swummsg4OqQ4@hKyDdFGwPh%Q-rAlrNjjAqp?U`Kh<&
zyEv=dz(g<$$@m*QV6Os2S98vaYY~hJSp3+3Ov^)kMv=~wbePv~yh+wJ(J7(_lI26Y
zn*N0aS;2<?B6zp|o8Y1Rr0_kVWUaOz`v?d8qBc1z2XkQ(r1KGHV6EG*vp*NSe`BeG
zW)pd@1OPsvE$+SiJ>T-4!V&OQ5e(r0Z$lX~%^ypR#fJLBR?{@xsrV!bKHiM#74=5)
zgRx|ga@}k@GGbDr!ZF2dlYz<z<*v+~&hJTiZ3&{Hy6FCN{Ubx4DG&!9zKQDIBNY0R
zkrDBdRNcK55Jth`aep4O;e`Q$3^m8o*x$)%oi(i5PwJcH@Rm7jEZ#poyNg2KS_<W=
z)h;hDE!o=Gu$grkP^S!<cOgCB2WUIM{c*P2z$~%$d^|b0(eHiPGx9pD+I$)Md2<Nj
z>zU~D3VvLsyz)tO164LZwWj30Y*j?TScJE$7Nx^UJc_?R3-3|8h)Z0(;rACpyW~Uf
zr6FDVES%=~WCHOTalIdcipzKNZ|J_h-x{7f;IAkXI^pvZ3SKo`Q;V8}c`MVfDmM=D
z^F%ect_wgJ=+M7wb6j({rP=Vy7Typ)E_W3mt7Yqv+?&0Vp7PPxZy&?CqzpbuQ~||1
z+TEF|hOY{~ePv3o+z=<PvbHYY5<0KaSFwH9C>pMZ|J-H728D%O=x^YWIRRgb>b`hJ
zrYbkjkN;rEL?c)%-*3g^{{oCM4Ei*`3YJwrk1|aQ$oOVdO*g24?xy@@<j~DK13>n8
zfU^}}u9;io3Si-FuT!jQa~-3Mk_4KrB<A%PPf^4T{X0d2%$Ca2-mdQ!(rF<TFWa0m
z=4Znzu!;FQIzUykZiQ;*4UW_Kh4aj5(4Vh_0uO5*be%Euc5H0Su;<-9O_E4zO3L~5
zvN_W2@C&?L(9k7ZyzA!u;h$&o2>$17m%!VZnF+WN-COP?f~V{Ez4=Zwz<O{kpYoCZ
zW+~G{g0NPe5j;?U`}hqLIGeT2)jC@KZGDe+=P!(QIooYi`s4JLVf$gR^_X1UKI3gK
z*i3ar`6mDI3E0ZCzf8<9^Sj;f?=b$kC`v%^`}UDW_OE7;Kf5y>Uf={|gt^q76`Zvv
zLeCY@{5=ccAv$|KcpF3hsn@}0(o{WMT+R4h_-G*=nvcroNY}#DcbBtBvu#s2J-^=q
zT|KkHIq2vJ2|<E2dBv#ey<CAZ=7kL7f9@#u7Ie_lwFXB#iyaz$vOf&>N#cIM=KB7#
zlvYsJ3~-1TQ8*RRfZf3o#X6(oKEx*0&1vA}b-}R6vBFS~5v%PgLm@gG{Usw^K_BUb
zp3wzjZ&QI!gf4<5z>5EelyC2IJv!(4ii}(eaG3JL|LVe;<X@U7kGnO-uISCYfR1<Y
z^`ibOLUv~-r@-9={^y(4UeTK$R?vVd_Du|bS>D|>$NoYwrs%oTm|F$pJ>GPPd1jYP
z2q(avPj5fefeq;3Xi{M%$H<DcJP#P-?MP4oMbQZ+<R3H@WX3vfU>OICB&Z6Kqr1{b
zTVKFg@|{03UBx|LUC%v<o0Hx>OLMJ)oM~*%SfJw^;Zu9&!SsAlwfP5};9)d2DC46=
zst*@hsCLtghcSrIJtbi<xqx?-X|tl-AeU>?wCqy3sk1hr1twZmWW3+A<Bzzo`R@Sn
zX-^G%*0rFdUl%4i!~-tnL-)+ACTlE3G_FLB=dYsv@{%s<6@^|yTJ4Hbs?>^V`6-GN
zm9HhXCwS>$cWp7a6RD(x@&QC>0bWybx%H!S-)+l(W^3H%&`L0$XHA!=uN6yhd{nCt
z4!k+ynGtCOo$v7f1W7Yzxc;cK-0qJ=$v<|{kAs0dDWeSDAxsi^%GaXC%nPAK==CRK
z6a?VngBoy`65OAU#F0y_?S(@=l`Yikn%rQlpf<WM?_B0Tg)3yl2RiPWHuN4mY4J?k
zPr*&+i{I>SlCkg34!>nF5&Za(iYzcP5mL{9F-H05k|)QGSa#h*IpU<eKqXnO4Wb}R
za*ovF^3bV3?@dvF+ePcXn*4#RX@i|w3XeFNi($@Yj0p|CmiDyaJ6$x2Vog6nh%b-a
z^ddQa9!qPxMJnhRb-EZ-pm%#C#k1X+i6t?|NLjU_v+x#{J>b$j@pz(5=&Y898X(y)
ztAY#T<VwFAJRtFcO@P^Q{ZDM+%n7cD>Jm)RN%;a9LJaL59wkv~Y%bI+a+5Cd-QWh9
z{dcZ7RLyrPc5`LFH9?M%6f@c#?Myxu;#JDZ%7Kutt!BYb*ZUJ6`T6)N7ad<GS%*=g
zp{6{1Kd_@%A-p>}hMJdAt~!Qj#jCEufJ>CMH1cnJ)ub?68{#Lga)Nd@f@a1SI@+G`
zL)Bl1eluS1I7OXLrFwoHZHFAc1TeebB(&a&mX5Zww4LjVule63yv*hV7aO&>!Qyc}
zMM3=ls{S;X4h>?qz3XX9T*-s^8!l?Q*9<;+P(Gtr(%$}0q1raO$_)~q?2srukJTE=
z6(GRYlIXJG^BCUw-@xNdU6~!H{q&E{TffiOk)<Aojbsn@<g;*FCw>(EZBvsW3g3QA
z0R<fF8=DS@oy6;KH_xAkm6WA)tM~~{-5_wC#J^yMZNVqRxhYlxepVjp*;&M=KtMF{
z>5qBa=?w#@MZYx%z8}O3b&(_>0&hsB$_KKGr?S4`V&#MCV_SSe0z>R}s02KQ!%BvS
zGARBN;bhJqf{!L@n;qLv)NM%1Ta7PCHsWj*Z-+umXlSbbPkPyj<EUxdiQT$v-#UfH
z8{{W-0><kGKdvBULK8-faV)X<m1#^E<Q^K_(mslH=ny#oq^)<iqb|f?VQ8qW7~i#C
z`G7=uvhvjMdQS6>M?Z>n6~2?bhVi{`l!3>uXz7~T8vYMpNz3{0+@RRpD3Nq2^9^nX
z3a~h9>Y`qoCk98F*GLO=nN(7KMOp2frs1k8>v40xh$;4?_t8Q}$B<M8BY}UR+Rta@
zPZsXWN_oa|#>r2|28Hz}F)2a(q0&YFLZ6G+51!h+U2YoiTUvV=OOO?gNoC`ff2bve
z6jQ9PE@Y33J(kpQLiH*3<UM8KdSzHFBDoFms@~7dz`6njmRhf7=dWOF9=#}$TI(pW
z!phV?)j~g-n|sWUS^`Qw=fuv{cgTf?@86*U8tG-#S4TgM+%jhgFiVs1kJ-o5F0(JA
z<0Z3;S1?z=_#}V^6lGdFdA*4#v1K4xSkR|9|4-D@-ld34(ZR)ir%Q&J$)3x8Uojz$
zLG;Se5v%W0m1_07B^)Zxt**2QSMDiALJ=A!P>gDPJ-qyrO6q}cXFGG&#D40;zQ_z%
z?D=kYs{*|0R9jj;7}qH6y>Ll{*rycrGu;PPfG8QZoI1~V*lhuFEuTcu%q=0?isol;
zB_UlzCi~v@y1!Dj%}F>U4hA9Sp*{iyaUD%zOlQLV#WJP3MUg4#7B<-e>bVVxsQ^b<
z*ANuMCR#q3zuVDaTrg3NTA2#{V?M{cf8L@;BpsPFYylP4{SVqUaw=cP{`L2d$F<!z
zMs>sp1@uQJM*uqsG7LTp>K8;(4A_B#FlAj3lxE^sSaZK1VDKF{(eA38jj&P0xwjA!
zb$qg7W=xd{K1dm7PBllV0s(bgeKK9^M6~6hK06UfaV(;V-pkGCbG0&EuZL>i@!?Rt
z-!eJ3<js06d6kud*EPt1s4h0+P~jz%D^hw=l$>uKv={w5`{3b%LZ5RA=PS~r$Tuw{
zWbXU*f2Wsilb^E0U+44WiJTn`rFvtV?zY)RIg31}aQ-KX=_lClr+@pqEPvdZJ06?6
zs?DUvskYnq<P?11c@CfT60gEOx+{+RXR70`o6DYF^FXFf-dgMOIwgdV;lvOquk$x9
z!1VpaLkq7Pr}`sbaUnxNP*Z2eP#j_K!|$><LXP1yY;MvV@!+5Po=h3zai026+?d%h
zyML3RZ+1V%kU#q-0ZN+4VvF`X1<e#*BXh60_hjNkTrXE*StD}0U8rHW{f6?RPkufi
zF)1jEV~3mLf`{U<f9I0_Gwu4<fx~~JoO`KTFK`j*%vv#9D7nz{m4KqGnoNz9McDrW
DQBFmW

literal 0
HcmV?d00001

diff --git a/doc/assistant/comment_1_f2c4857b7b000e005f0c19279db14eaf._comment b/doc/assistant/comment_1_f2c4857b7b000e005f0c19279db14eaf._comment
new file mode 100644
index 0000000000..1ed185e48a
--- /dev/null
+++ b/doc/assistant/comment_1_f2c4857b7b000e005f0c19279db14eaf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkYrMBMTCEFUKskhWGD-1pzcw2ITshsi_8"
+ nickname="Robert"
+ subject="Annex on OS X 10.6"
+ date="2013-06-04T23:10:03Z"
+ content="""
+I really hope they can get annex working on os x 10.6.  This is a great effort.  Thanks 
+"""]]
diff --git a/doc/assistant/comment_2_befa1f48e5a43a7965060491430a6bc4._comment b/doc/assistant/comment_2_befa1f48e5a43a7965060491430a6bc4._comment
new file mode 100644
index 0000000000..cbc955b07a
--- /dev/null
+++ b/doc/assistant/comment_2_befa1f48e5a43a7965060491430a6bc4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9smfyJFgp3f2WjqqZWY6b7vo5eZv7GGQ"
+ nickname="Bryan"
+ subject="Ooh.  Do want on Windows"
+ date="2013-07-03T20:44:05Z"
+ content="""
+Sadly, I didn't know about this when the Kickstarter was underway - I'd be happy to chip in $100 if it means I can get annex assistant on Windows earlier.
+
+"""]]
diff --git a/doc/assistant/comment_3_9bd3b532a5c026a1d664c898f8e335e6._comment b/doc/assistant/comment_3_9bd3b532a5c026a1d664c898f8e335e6._comment
new file mode 100644
index 0000000000..996c6e6067
--- /dev/null
+++ b/doc/assistant/comment_3_9bd3b532a5c026a1d664c898f8e335e6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnov5q9_Cl4Ps5NoYE08yE01NLSvBANnY8"
+ nickname="Eric"
+ subject="Does it not work in Direct Mode?"
+ date="2014-04-26T09:41:20Z"
+ content="""
+Looks great, but I got the impression that Assistant would mirror the files from my computer to my external hard drive, and I can't seem to get it to do that.
+"""]]
diff --git a/doc/assistant/comment_4_c546a24459ca29025f00e424353c40d2._comment b/doc/assistant/comment_4_c546a24459ca29025f00e424353c40d2._comment
new file mode 100644
index 0000000000..82be4c1938
--- /dev/null
+++ b/doc/assistant/comment_4_c546a24459ca29025f00e424353c40d2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlr2Bj0Mzqwzl28cbrotcQUbOFoaPB3B_Y"
+ nickname="Tomasz"
+ subject="how to disable assistant"
+ date="2014-04-28T10:21:59Z"
+ content="""
+assistant daemon now starts at boot and pushes all annexed files to other repos... I'd like to do it on my own. I can stop daemon from webapp, but it starts again on boot -  how Do I disable it from autostarting ?
+"""]]
diff --git a/doc/assistant/comment_5_d17de359cdd46659170d373cd09c0979._comment b/doc/assistant/comment_5_d17de359cdd46659170d373cd09c0979._comment
new file mode 100644
index 0000000000..27d3430215
--- /dev/null
+++ b/doc/assistant/comment_5_d17de359cdd46659170d373cd09c0979._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 5"
+ date="2014-05-16T18:55:22Z"
+ content="""
+If you have a question about using the assistant, please ask it in the [[forum]], not here.
+"""]]
diff --git a/doc/assistant/comment_6_70193bbaa5d60b829d7636748c641104._comment b/doc/assistant/comment_6_70193bbaa5d60b829d7636748c641104._comment
new file mode 100644
index 0000000000..00db92dd4c
--- /dev/null
+++ b/doc/assistant/comment_6_70193bbaa5d60b829d7636748c641104._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmN1fkq65FL5gtBB6qFmEKWiyl20OutvDI"
+ nickname="Niklaas"
+ subject="window manager on 1st machine"
+ date="2015-03-03T21:30:53Z"
+ content="""
+Not related to git-annex, but I was just wondering: What window manager are you using on the first machine? Looks like a tile windows manager but you are using XFCE?!
+"""]]
diff --git a/doc/assistant/comment_7_831a529c92951f70a27721210204e46b._comment b/doc/assistant/comment_7_831a529c92951f70a27721210204e46b._comment
new file mode 100644
index 0000000000..deaf693bb9
--- /dev/null
+++ b/doc/assistant/comment_7_831a529c92951f70a27721210204e46b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://woid.cryptobitch.de/foobar"
+ subject="@niklaas"
+ date="2015-08-17T13:42:26Z"
+ content="""
+Joey Hess is using xmonad.
+"""]]
diff --git a/doc/assistant/connection.png b/doc/assistant/connection.png
new file mode 100644
index 0000000000000000000000000000000000000000..3cd6bef868600e985a116a5c6d95baee5f72d931
GIT binary patch
literal 3181
zcmZXXc{J2*8^?dP7_v0h2W5yXVQks5HN;pN%tMyYSQ8pDW`>B#zGp3C%Ni=lGEvs-
zYo07c%@CRx49ON*UY+MX??3N-o$LOdb8Yuu*XNu&!3tr*$u7(e005^c+z5H1Q73+#
zjq&7mKV4USBB$KUO^kr!KUUOQk$DmU1;8CJ0Kmcf#~Fa!e4&#dYmn)+tE@B3AilE_
z&gMdMC%Ju7qboMSpXpBbEkqXoieThwo8uORxg|!4r@FBXWmrHmo(ik`IKB`_)R0Qb
zQ-0TwRpe<-)Ddr}Qdph<kzgfq^n5j$B5|;S?U=ylj5IdZXVFNWtcFXPEW?l8qaLWf
zUciKX--)YL-k8qml`IR5h$wi{yoeudZ4cF7->!G{_GaVx$e?b;7h~qC3t{AEKr%AO
zKFBgKFw<c`G3!&vWb(vB*{2l+0dr&HSR1))v+|yvo|Kf7%GGlpWIp<k1Ox?rNsa)j
zej1&$>xakho@Y<XVUgdd<>#hT47qP#ddKQlKvpTMsL)VXe>Ukua->X6Ej{{X4Rci8
z7MlH=)_h)E*bslyd1Zo3UVSvTMH`=y8#^hvp|JD{DC2|+DhYL<nB;-m493HC=5SRd
zO@sGLQ5<C~0O8$6h`6Z1X9n^b08nfEwl(Ls6wCNKSWa{CY!WuSXDuKg6bhIcw2=fQ
z!%+d`Sdk=dPloud*r4;8Z!F;&=i2(vK0b^<Ig&<tHNBdcn26@~ZVhTRl#(m3D2Lh}
z61Z0aR7&9GOk;Dr64qs7b4JlEUfxA``{G=iiR9B^bO&_pJa$p7PWV18PXDX>0{TX|
z4>Leub`<RNmbbl4y_Ct++Es_AJ-Ra-y!~d~^V0q@h6#0vwOGX)TQ0^mV6zXNOuM4m
zvSpR49OF}GQ{E%Zc`-8-hOE56nY*EsTyTn&b=vQ>y}XOFbDQ?VR!K!!({WSWKn?VV
zP|=t7cDpm%F8}<bHlagxxT7pZt@K1LLe07YkyMTEf*gmNplqc#m69V6N_o?~{SKqb
zlCznf#ui;bHnk#qMaympCfBaw@;J>YNQWM2Wq%*5!j^q-DnUQ*Ix@p6E#C9VNXTDu
z$xeG44Q-T?vFE+n0}N(0!uz<SZ++u($@!C)VkVZw)8Uffg!Z#DB2ANHmc(A!3i_kW
z5}9Y5c+;7cavABX)>-3iy9I^n<g3<vHaOo^#l(_TK9+0>8sF9jx3<X}@1kj$uYebn
zXF3a9N}<29DZ*j7b)()E<EHD(r9K#B*0{0O;_433Q-jnblPFx<>=u@MrQcny+2qeG
zH37jp@CP0Ccch<A`cz-{y?5{JaTNx-o^|udLw$dwk&k(x`U4qLVcrM+6tyBEoRUrc
zN!4U)gu4s)y2=SK3<=vQ-Ae`_<w--cJ*&#+;)`p@#)J&+3bJj)L=QVGTl>ZHmQ=iU
zNj#NqBzKt+$f#w*cz^REc*rvXNIR`2P^HnyX8eX|Xf&3Tbo$mjd&Wp;Y0-&zTq2Y=
z-$+Je*j0<`wQV^s&Sn5b2gK--&BKC(mY-{TiL?IP!WNRQB)3(-`98r~^9qkp?3~vP
z$onxn9LnNC2TUsj%9g%5PW&c_zX&GgBsG=nqpM6Vthw5&xwf*t5?A}#lg75v8t}e$
z+Ha@Uy|0Bd*PXzttE=l)tEr*!>3BW^vk?2m5IJTe=>ChnglrsxDn)NT9osb2jL6Iv
zd%?a&Y1>;6Igh$TQ!`A&;0+V>WFL)BS1>)NEg%db2$$Wo(-u{^mzRfluT%!*X?(g{
z!Kak6z04q_R1dFQQv+O)_!T5LxHwJv4i$%6CMc1DEMqDVO`fkDtNT*VZWc@@^vtW?
zdjHR5IPP4NHt`<C1BHr#DsJykNBs_0sBa>~&iry3{HgykT--Wb*$j&_?&~&l;rr!m
zx`52hly6sSs|i)K&0xDfyJupv2P>H`QQqDe2BI9cA|X?hCxW6)l}WcWxpki8WV%l8
zKB2XZ1;=|d{$R<z)wd6MyWjts)yaFn{E6kGn}t)mbn=5+F+8->h7S*WMf|P!CQry_
zBPRtmMWbILtNeU?*k|Zl+Evh1n;Hyp<N7h%CQ~(~?`KTGQE+rgTYw^Fw~+IzTRXMv
zbAA>D%`u^SYA)<+(}?LCR$;uZ;i=u}*Bxs|-_~G1u-s>S4@OdRq@D)QBJS>)>q7-q
zyAU-#2QGzY_@UoOWTmX7Qfvgzp@$tHh9enVs*dXSFm<E}_XEKFcCvK{R)wgxT^l?J
zl{!$f1G*vwz`+3PN8}m;901Nxh96eF?2*uMD}r8ygP6;h|BGz<o?&!wuuyjA+Z@X&
zKXn`SN-WI43?jvo28M&8Nq<XR{Bt<6DaQ^40Xd&2|I)bzFXch1f4I4JYwHh(Bh<`J
zP|Fm@0&iZdm`(K>Tb|x*2FkD-i{LdT8kQBX5(vh%vIdINlLX?V{>cNCv2@@=(I~k%
zmj3c8blk3N7;KphvBrz+6DA=p;<!s2r4f^}BQ<%7&&9e-wl)8<cB*0h*=8A^I)6_W
zVI*2zAk?DkV6Sg$e_3m4aXQwcUM*j2pr%04SEx%`pi#tja)kka7h%Pp-WpmqdH4~*
zIa4^SZ`fFHdj^RKmu$zq{ocam_Yq>#D}LXhD>$68RkaT)#Rbxe8)7^6tLpZx$tXu6
znHTALm}Tu7=64uvai=RVx-ZG7l(q4qw#+%E-soETtfH=g@8i1`LVaCDdwMN;eIvH<
zInx7)c}eT2Nm5mPWOSrN`o`BC7zs1Y(O-nu!j4R|n+G%*Y`uMeO;IfS^f{Sx!;+sb
zUJu;;sj?!{>TD~uGeSz+MN;LQ#bCSox@YiE_n-pL_BuF=H1g7d%j%=o@~l+90#B=F
zqKhppX4C!HK4@$1vODnuxut;ovValz_4{Zl!nq}rG|IvQDqA46h58H1ug%`W=u5|d
zLfpQ4jb2#Kt^KW_a-E$wHNN!o)r6yiBgK&mc3=GMWi8;J#m03EHo4T3wQjIi@x_LW
zqRqnJZ7g=!_{)Lo3BW6TX~(J6(r1CtlW9cSi;7UE;<N~lAj;q^DP`AD7sMS)`|N;5
zIGs+v=n}I3DZ%8j-@(wY^!^X}UKnv&l|0(WK@@N0YjH-p0r%IHj-h$QkDYwqqe7!A
zbc})il7DgP6{zt~tQyM?pRO07<|{cI9I$MaXEn>Og0$4ZL%Z!yUr7Lv1k-v$;v@3u
zwC-epz$c*dTHCsVB=-ImHa&lLT{Blt<oYp97O+~I4V)i4OCoGKKB0>Zse6p6Wk-*s
z)`p*Y1$@(8j|h%*W10&%!KR)+cXvn~N~AZL(cUT}6=Jk!H*6Y*6BRIWRqP|}mqS^i
zqdIbgT+c7zWX3a~u|`v(b2RDj?k)NROR2SLI<?ah<JA_Mf?h}u?p?Zoo~D8@q8k3@
z9z44@+1zu{h)7PcNd%uu4i`1G^V$dJ#%)wrUZ@x2-QKNhI;>6hmuHTM;`ZZjWxuQ8
zci4tqXLA7wS6prA$`X-*b!H>QWq2_frkL!G-Clb4pfOxk<eXIa=|TZBe-#fbX4>v6
zJ}%n)+8wXe-<TqDd(R?r`1lvyaHA&I&6Cq>dL$*Z4Ay?}wiCjPmrvKaj$_k#BkXhh
zQHV@iK!)^lRr6-`&ZBM=esm`HaNz!QOej6<sJQijN$?H;q<^Tsd&7fsGe+2gc=njU
zp|Cfw${Z6b>zlKl_=Pe3`BDQ@xa?0H_Z6;#)_qf@w*)azXjpEmVv5TSe-#vbkE3Xk
zVO05cstH4b<PX;YN~k&^sWiz03=kFFHi>7x+{ArIu4cmM1&|Spr_u(1^BoY7Lvl|&
zUGfKG)9=h?4u&|X-8fqbr{^r)4YoT~Qc#mJ@)>^Ie*NRv%^mbN|AmH`d@auoH7G|R
z8CyZ36w5#FG7*=cecj3Qg)jkI>oeEO3lS2F`wsbynEApb{ti+#Z?$AM;PJAY>@1n%
z4Do;s^0o;i;rLz%{y!Ywqm+t}_JW(Bt%oKP+TswYG%y<+RK^TjDxLaTVa-MD(@(sr
zmBlo3mTDEgWuTR1&E?5$#YHWTgK1?wZY9XXsSFk;2g;0-g{fA?f6~-!LZD2k=pe(u
zNokg0NI6Y!uvoN^za!3B;iO+IoJC3gL_Z~g*<3|>B>wke=i82Bp!tR|QxF+pa`G_%
NOs^u0Ucyk3{{i#}?%x0a

literal 0
HcmV?d00001

diff --git a/doc/assistant/controlmenu.png b/doc/assistant/controlmenu.png
new file mode 100644
index 0000000000000000000000000000000000000000..c1dac197b9e31cb9e15e208f657c1038feab2113
GIT binary patch
literal 8863
zcmZ8{WmFtZ(C*@{!JPoXCAd4mgS!P;Y+2kE*I)@Q!AY>-x-4!%f<y4d2@>4hKHhuo
zkNe#|Q&rPdGt<+jyQk-Qx??myD&k;LU;+RD9AzbW?N__|DnaOouUhjZ>G9QIxGEWW
z006iL{|SQISZLa-6U|duT>)(c0f~r?psbbS;?+g&sbJ_S=K=-;ojn0^?m$aVpbedm
zgQq>6qO!WCK`1UM06+&&mY31>g&ze5>gpJ@-f+{pN=Fya(FG-H;|PaW34DqDnC%It
z{6;d#KCRyjt7)u2nWuIQn1z;)jympC7Yl=wYgBj43YS|lF2{8b^^Do=BQy1zs|q@b
zjO!5HX4Vz^&Y2jcKmHzqya?0hFft<${G59-;hNtOd4ODB96pYF<aMNY#M>{{1L^2|
zi|F3zNT2?e8LsEZL<v*mm?xYg6i;qR2O1?Q@!QUyUDDHi!=2;B{;RGi6V@6L(TTjq
z2cpJBOUS5PzgJ@<jFErK#neWTvKx-HUQRSLGk9=X2LOt{&D->1<0GuJHb%{=)G~GE
zn?AR^tHGxu=|Sk;NQ{>M^1?9!RbcR4ht%RO^^&`hbtBjMFv;kQm@S=Fc8B<{o`2tf
z;EPEaB&~3{d7^2`;iIV~QOb>meHsEwJ*&;JIyNYvpn9wSVfhI9GWLFS9OuVzP(o#z
zyu5sL|66DEcj?iF=KEfuFe__Cc#0M$&#xaSnd}yU&R6>_ar!KWSlXgBt0}cNAI5Fp
zpAeB=P^`XqD3A2`e3|d@LU5~u0H3PTU6$Jrx+}Vd14SWoI_xCkP%D{UjZLN)kZ83D
z<28->=WF2duT&omgpJR^Q;qyk^gF&hmUV06cH4P^`->dXn!tyu2bNV-i7!}DJB@S8
zBxQb2#TlfHflo)be{&yAvAXpbg~<jCq~a?%*ijh)>?Df{Rzpa(rphztUo#2J1cF;U
zL9Xv2N%gr>OUKKkAUNHLfkCx1Tcc_W;H>zh*v^KAI-=Pg7o^cs&1g9)F7IV5bei>g
z0rf%TX!T$5WYUCmot(Id@WZJXErR?dQYD2z1S_ny6i9c>i*PR#saQ#WJmuwW!%i3W
zxW~wnFrO4aDC+1!z7`eLQ?#KzoV-MiY7@P#P%MNZ#1OIjz1kA>R3*QB-zAEQ9~}nr
z<n0L#$B5rOLy;umPC&FhTW!i9CmJ|g4rLXI%wXrbyFCJk05jRMglUPFpa6nn13n8{
zsWY17T&NkU-?^m&QK(5sJ}OjG``9HZaU`qshtl_8+lG8MYw@<~3#8|q4LA$_*yMf1
z(`@|<Hh=F|vr<<NIEB}^n{?jC9_%=&)(XCig--r!yks`vHl+a{a4-Et8KM*vzcE#t
zOeTgIpC}n(&ELffuz@=^2U(S=o9>#%*|X-gcgAww<cq6P*q^jtQLm+>u^Y_s3tsa&
zasTqh;ro0b_|>o9z#<Sux?4E$YGiroiO(X4(=F7!c*;H!`UddkvhO^2-0!&by``$b
za{DSb%`pmoV)M0~(MXEHKp%&N+d=gg=rZ6GuWJ;1x6h6jj69<#`wa1WOc}{{oQB0J
zTu+T=WOyBH&SS?NT9lYMw;p;)*y%b*b<LdK4MW*KD7IXzz%4o<cCOy=`##!I#ubWa
zjI8|BCg-yRopi4SD{!tsK;%w+dXuGBw5RRwKeZ$387O~=i9S9D9X)y48byVZ(=_23
zh9Uh+Ivi=uz`qG)-iZth1oA5{gqYj%-<`do_t}WWldb=|q}s~h3|?;`)l(I7G<iPn
zNpPO$3O*At*v%hnaX&gG7~D&E(IUnxxGL;IxV@K(|JK>cs0-rqe17x7V*13kvN$?~
z@&yU2ShIiGewI4MN#yK@EfceDaaoY(UzZHesQmUbq1iZ)@Wz3|S^U0~#r=d_1BImT
zRV4XiwD==|CM`yTkq={|nH0A}T3j-g!83omnTvI|5&o?y@Z8Yh<g0o15)1Zb@$F*H
z!E$4Ja>=B8let(xpW8jUkV2=dhtY$|O&v(S#}_3Mz{|_aW!}DU7$5vJADoLihX}x0
zpgv3l{x;f@1cZf*BYZf;Uu&+wDcA^`lJ;-P7*N#BBY$oU-l%)=VjNU#6AgBoo8;}z
z<GqYf?x{cI6vJ9)8@paW`Rw08w|y0s8Vs+0zB>E{eXT%^<QVli@X>Ty4{7YVYHx1y
zpXSGA8_R{Vh7U+%d5*kXMq~pRa%gaFrpF5*!tKGe_26gs9NMHPsj&TOo{3zLd57bB
zYqXJi?{~UsRKdrleDk|(oIIg16XMg(&07+&OO1fiiDvbrnn}~S>OUVrom3=5^&I|>
zw`UeF_w$d3*Jp#YFW0cHTr!WMH>Mh~eV?dJ!KVO9OMQphQOTJTAG=|&*Mh)rUs!m^
zCCtF}NOO<cAj&+uJ1?F4--{=5_kKR--RAwH7$>+X$!|R4th&cidKpCNJ@yHI5=4pG
z*Af0phM{*tN;L0kIV?2T*ss5{{A>oc*=BL?F0Hvjyo1AcVQQyp_(<X5AGkbhrvT$x
z=6U!s+7q3UF_2q*t9!~4Y>Zs`n}OeA4w?Fz7$xNIU;@$t6qKRFxXJP$T~UW2&4}m&
zcTLSTjGXkiFdqG3=aN?wA&-f6;983-uTmU19@{O+kseK#HC7{ii*yE`s~JfUIh5o0
z#T$LPmI?e!PXalqaWg6^y>^FJV7)l0Bwt(5hy(|akw%5>MaiQsC`Rb(6QcTa7c~Ib
znP=8=XN@5OY^U(@e)>hDyQr5n(#|IW&D|R((fQQOtLtEz<{$Slo6AwbTMD}^{uDGB
zM7*vI9Z@tm`J~VUk%*c}<jTAFc>^LU$-AvL=|F=@!?WzQM_c&5G0f~1P4S|Ik6WCQ
zLFIQ-EMe75eI{r%KyV~;_R~q>rbT@$VZLD@P4?4(?MQv)h+Nz;haXTzzr3sZTI|<`
z6qGkEfcgaJx>plCX8Q0(jBljtERsF%)oqmudN?+v-dp5#=^xRzooXlMz9BOa-k4ZZ
z3%7dGTl!&b2Kq5|GDs`qC21^*D(43`UpO_^+y%;IfG@-Pe@pmr8Ay7}PVzqglvpRo
zDuqrtkh=Pgvc%I$J%^;`eyS#Zox#!bYi=ShV5nA-PjnhrYA<mb%153`yO|S?HSPmn
z?8=3n1Jv^+dIFkgyyx+Ke67DW9e^e(p9XuLOVcMBZyIOv&Zh51@De&Ri+?alJ)f@C
zv^?;_@2pBCjvq@kiaB4Ju07TU&bB)E*e~?7{{58NA<DaZ9J%zWxX(A1^yogFx8BV)
zS+|o6y0EM8d){ESyk2dB7t(Z|JrU^oBp|*loz6BK5bjG!j*xbCifnhixLWfQISwRj
zq9z2+?d<=hfu2&GFFAilLG?HExFYggP$WvhPLlnOk8l`hYcv-)aUjzP`i3%^8iF87
z-pnOS_^A^a+cl~u00T}A@J;TWO`>@e49V=K!axnd{ZN3^Ma>XO)Vysz3^7arcrX<P
zwtsb5tS|Ol>%1eJ6sIR0al-H;JH7F@Vnk1}>gGD6T%&dIGS@)G<`diK&#|+6s(XAh
zP;=q#gAq(*F}>;NAF%`eTEj$EQ{Z~u1#GUF4&4r95@hZA@NXOJd)9UBKugd{@z`>4
zt9u_BG*I}F*x3iY%2K@Y{c+>9;PJ-y7ei69iK}?-;PzQFiK=*o(D!F$4yxn9_ZFju
z<Nivwg|}HGLD{rfFoEa%uro|d=1eHn#W8zI+wXn2gzsZek-uG*+_Th6y*Re#OGdE6
zqd)D#FHG=TVp%Jz&4`Wwr{MZqMyAAx5+XN-E5eI#Eb!YtRV5_=LJtFqJB*>H5baeX
z3_+2RBVMIQmX59^JtSnyIE<Ez?6aFN6#_y^z#7YITt{hfbaYh0{~8+)FU3^#)Lzs3
z2o62zxXCl*Ks_B7J5jS5NE^+Q$X0vbld3Jq%Ia{u+#(<#Kp3;-Z+#>@%?GI^{9dUl
z+|rj8U%Er5hum|^+7|TWhd1oLP-_|fYh$4^uuWIA+MnRjMnVe&I`|d<G@5gU`FMMK
z`}n*ed~+MtZxs_8>vy-E@q~Z8*&k;SaMqtA;t?>#|Mu-$Ha3;FNw;@6u%Cs6zwm$}
zVYsge2WKo_DtO=vd1z?p)?fN>Zx@`JdU|?HV9rA}yzvfUctV6z{6|ssrs-f87mIqE
zA)B;6$jH{|<eZ$GZf<VcWxA(jroBRuZ7c__!p<wL0{+*BwY5CF*~rtMJ3Bk`^78I3
zcH{c3TsC8$bmlf(zp0h1uYclAK%S0ywJAe=?-O65>GCVLJu-9{pd3B?3_LuE8b%3)
z+7>Z$3Pw?rZ@?JnB@|RQrU|9HCwxkQOvWFhEXh7w{>CN@;0Ey?7t_Bf0}UN>^xPmy
zBAv8VGqt3zKMX@V_l@g>j5e-58S{oCuc=mF1r^l+KoT@=k93t#Lk>r%C<NIN>KEW=
zR&d256f%cY;^y$}AP1)v(k>BbsfLw;{%mM1dfj3Dm?Dl+d9}W^K-}ABI5IV3Rd=eK
zbBK!|prfb$%pJ?Cdd@f81Wec6+4`2PI!MJXRTu_Jb()Kxy0|-f7W?90N!UXRQXA~_
z`4XI5$};aql^kCt5_*=EmG!PbPuFm{MDp9k@gH>ZQT}quwtY6PG_GQq1DPrsk@>5F
zRE8r|&EZ42MN{0LV9=UvwOj#JYK|C&G-W8d=6KY>KZFp}Kn%c7#*lNRAajy01?mM>
z2rUT#i>M|-h`@sMb2CDU-j&n`!%k|xP{FWdq&o2jRT-g#kI}Wus#D8=Ov1)IDSAok
zqHIe(2G_>Y6Xk1dAHQ<}e9?R5uR-4C(~|G+Ax@LL*nHyRPEcb`5>*$Mla)3fjXZHk
zSHhS<JW`nP(_BzzQ9e-Yp$dgnrRhcR^$UM>Jx9a@>KLo%SPE{VQ&?Pd8Pj1iN?%EX
zsg~*Pl%2<C(ApWLABlT-7M4px-CSBrx*WPjp05hUV2*;$dJfgJEBo(Tqficxrne9D
zP|Cl)>bZl`_KqX*29QhZI}NB?#)nzRz1c^@0z$IhrPM*g-gvLPJ314+0{E>=Q|ytG
zl~Fph-b8P><O${Ve&=f6-yOt8O>_#7hui9^tgmhStWTs;r`u#B^{@n&K!cRLQh2kF
z*(}7Co0%xb2H}c8Lr?<dX4g7!r!0cj*2yQ)vF1n1AqqL)dab^{zdt8Q+^i!t4UKoz
zMBkg;2OEZu7tTIrWi9VW!Au2LAx5b3!z|&Z#V$XQ3Ti5<U?_s~vxt*IGZb6pO60|8
z0GmT@#6&YMR|juYfSH?evAd67+PJP}XNS!t5VQEh*PWm7f6`sp%WlY4e)ZDEs)A<W
zmuzOaem=@>nK0OrD#wbLl%YlO0oNp$t9&QoYkCsBcRcO}c-WdlW>6*AK)Y(D#9*&H
z&3MJX7$E(9HB7F)@{%n#oBh}wL7`ykvlN*DD1IM%(LYXg^=6waL@3CBd&#7;Q^k%=
zxUr*ev`y`+b?gUmBZDeFR-ye0#iz;&mZOhDX<FYR<i+w#{Wtq!_J*J^qw5u&-12sv
zy{ud@frD)Cl7`&U*LL>5ysWNT<QO?-`)%Ik^->+?ln(R(kFEM&@(ZPdG&5M!v>}08
z?auY_eqJ5<Bj}YiHYeZ>zfwJ>nU<m9`a`cdzml#O{x!4{dSvyp!Sgb&2co6m`}-rE
zJy!9DTz#1dGk1&Fs$Bhapv#Sk&ZAffYjd+uZio4}am_`kbB@l|`PL{HWZoJJZ0WA9
zF(}J&HaUq?VE&kMng%My(-@+~ve#i4D=R}4h2G(+lwT@m!-%QNRSn97GKh$$2H+nG
zukBl|Nl!?p2JS!nea@A<Vd4l0*lO25A9rc_GJ^hh0g1ehE}@7c%mDT2_|K+sxRJ9*
zhCkl>5>^Xicn&5e5zcbmSCZ&+CCi)tUKJyWD8!H)cyX{W9$p+-j6-lYyRT{Htc9Ao
zbnFu=tf4=s&2-LTtzIS${aO8kXqW@YAz-8ni8jP)B~O(_RZ*5<RrGT<g+HXfrK2a*
zESgCr(otr06j5N+6=3SuEMk<uuOpW6fodgT<Y6^GNVBW}i{5T~W)PrXNwz~C6g}1?
zs<j4&Km92MN=CC<&~MSeaf~>m!v$9pc6(zR7nO##8Z%GAL#&NFvIUq_kUESFK*QXl
z;xo12Ubk)HEs~D2NBZK{#!AVW0A3+lnjgFLhvW0mw4H8G^c~S}Y)d2O49RmIQT*ga
z{j_@m<m3SUJ@S*lqInw|$UYjILm}=C1prge+sueyRG=gatRMpXdlh0w&&5<x_XB+=
zYv3ksQ@b9yX^-dtdOnP;`~3&@H>_#;{HxXi)>XqW&7Xge*kKh~g+G^8+n+klGzz&D
z0*hat+3`_KNcm{6ZpDQt8x)(`l;vaXh1w_ao2dBRZ?)LV<gsi{)%ntQzuzUX;b~Q?
zPacnRSI1RV;}so%bt72IG~4Dyy7sbWiThdi%839J>MH&ItVR^`a|wJ2&YWv6A1sv%
z#tJHwITtcb8qM^Rv;r01Y0U3HE-xK_Ey-?-%YwhFnHzz>sLvmdogKG>P0T+AxkXf(
zv^3D6WVpMt;mvNN<I>y5N~IU*_l)=cII24zb}V#qPH&n_SfX*Kjs2OOZEzh&h(xq>
zO?vN!4SDcT8Q$ur^%~jyvnKJ+E;&#wDLV?%vUmcnS%vWUxR<>>_tnS(soTPqqN1X}
zf+jjT)2iGZo?UCaYEBw3Ec;TKC215{nb2TA!AV1PjK+ge&4f!(p(Q!1je1DZ2joP$
znUuAiaF-tRZ}z`g=krRLFZmHei-}qRNMC1DCtinJ%fNZ@wiL3Y_||Id(9n>&y1F05
zck%DEgRS6bbRwGh7b1x7AJYc0uF3~b;1IG3JcU`~9Wyf;Dk>^6vQn{jj6AQO#V_63
z^mR+5LAb*+;eyjoc8*HD6N#)gQIeElW7a!)T0E9gNc-}aVX?#^EL@;QbbZ1&4PsBK
z<;h<7w78YII_q}lk&>aRYp~`>iGSbh3=svh1|pO1rL>{ye+SPM+1m6`Pz^Jm0?(Lm
zUFw!GqBcD~KK>lxf08)65J6z+^o2(d8P`+wGg?$Hspp7+&xp?NqBr72m1)>`totgq
z%WZqfzeRECKg!LdO<?bX)ud~sGFZqDkv=)~4we}e_zyA#NNavC;MB1XPVS&SOFR)Q
z!#~ENN%gWE=*W(3C6tOS8@d>GiLuBQpEroQFnJ|e0;C_$i0@M2`KCGC(P!S-wb##>
zNRq&-8mgHt_e70lbn8Mqy{Y)E#SP8@>Y)aNo6<8?S(!+LA3$qN39->IM$Z`v0WADb
zOeA8|)4WA)3{(NE<isRrzIg?m0$UkE>`&y~(}WNQl(ubgC7Ch8-;n_=wLj2x$rz7)
z8hnL!F8hcx-uMrTwXcxq`}h$e3?JN`(0H7Gt83~Bj&hwwk%26Sp+jwWj^uCHu-}Ql
zzt2joMVZ>pCJDaRcar^s_#!I=igDY{-lW8`ViT0eOk_lpR+cXn>X+)^eV&F{Nv$wi
zw47t?MiCRAxwtS2I>+9@V8oVMNdPwUnCPU<0GZJm-ErDH@!Z2det*gY{PoW$W4>lv
z#ja^;^8GTso_E}&6zXqI>M`RgK+oZd4))7@yewIWRgWtqm49%@?w%gf&~GPRGsM^F
z+#70^-&N-oTaCZ*UNTwPR-P{TnXncc9&y7!%69t~w)ul~(0UlYo+LjqQUB=edZI4V
zPhIf?PspqBz3}o(9TOxK+DiH(14@>#XWXb|`ywkDUsk-452X>FB=k5w8Pv8zDj?UV
zjtI28iGOP8zt7w_)yN&%39)sC;}jliaPET!0<*{ftqk)Bhj((SW=}q*`GE~0Rr(oo
zoimUFH6hP!&I9M=KP3Z*fM4a|wL`0rbq!AE>gJISVh3r?{=A>hzk(f=om#xtBke8X
z5rnT~zg^iZg(7jD^HmMbjHhAvK+jxFqyzg>{zyT8yR4dJi{Jm9pPw5|S!?&tu%*?R
z<3->bFs{JC<Y1PS739F4X?kt+KTS$P9N0y&IrGrQe<8~rH@LW;EOfdmx(X8Uz<0Aa
z28gS$3FCRfZ@*2vkA<f_YH3?I<<1E<S|Pf}nf_>KwR=u4tq`IR3JQQ^(b?E<4^5b>
zafW@y+~-JL=aheR66`l&EIu39@d1EF^`{fOX2>S}jlQR7!1Zbm!dBjaMjY<zZ&L_a
z#ocLgf0W!#ser0as>L?m)<zRdbnVSihM8Ehov6W<?rEN#4V=5nKi~%6iJoBQlMrA#
zDS&IF6;AcJ7o~cSGTFMf_*c|gyt_WZpADR$_b2lfDEP<$eBFr6lTv<9ghc0V8!^n+
zWp?kho9J#>CU9y2_r3|+IB4TIA$-Kg3@px-lFbg(zAF%!=%jeACGJZssk3>eo0{7(
zK-i;bQ{m>Y<?N{cVp8cp1^C4AhDzIn%BZ60vUL6>&x4<z0av!qvFyWuz=dn!Lki9H
z84wH$fL2bgcZK^ruO#z(tbN~USX<1^XlL0=A1ywaR|TNDYSQ;yc56<mJ^zr`6pq#5
zo;bce{IdaS)T3zMKcc<!TBH&5_+arOJvmAq61W@+ze%%bz@1Ety&a*3E4uh`C`3ej
z`V@kRfk+iZ^$?hU*qsz4Fbe}>=w)O!78N}O{dI@b?~dTERH$Z{9n4F<DXF^Msauu%
zmtKl}USD>uBq=q8`<eUnxq4%-KPhH(JwE#y&%yPjQRpaUw0k;^0m0MrrnD-Rfzh41
zW`UUKoc`o^agsU^UuzCn*Udvrd^BSD_v>n-o_mCRwF#5ZD%oNN)TGyHm!WU>m#ndi
z=bEbd<#+yiuOX|ed&u8>T8r2N{Q){g_Z1b$;7X8Gyk2`Jo$cbLMiD_vU|r1WF8Ty`
zquF<IrLo_0P3+V$z}IKOGUchxmJ<-}w^X1>&O_GOT|nZSGn5XL88jBPzZvzseO%!j
z2?P9-1WC2``8`*;UirLR$j#7|`Mw0Ne!gD3lG(Mu)5><9%k2uJ&o)swQ+2d6G4arW
z)t)?>5Im5qE@}NWWj($->B=8V&6&8W^4e_TYC3q0d9gd>wCuahh+R(I>lqR_NWjLs
zh^tL_n@{)(X$M`ehZhAd@6?m*EPCrEs(lxB+c+!7FCtKJb2_pqLnZ9gE(;qh#Hz(c
zES%%>P6xmdb@aEZ>hC@cOje@YSY_PZe-KKOt)M<SMzPF6j?v!5lw*=<CMvbBEIi%#
zjf{n<nBgN$fx@n-D96>q%lbODC~BCyo*G{-ZG<akSmZp>u{s8Tn3QVOVsXXx$wLbR
z{=+1TKB+QY^QBtNgKscJKOj^vMkoFF72oiMZ?SVnl2eA^VyEhOLwUcx*}4L;7w_@O
z()uW-*oXEX1pSRIXU}a<XJO8<#afhnME`i@2zHH_+uci(q-WV29%x9S6%P;fb)LO&
zQ5fiUeysOWWPh?BBeFdD6^8R*TmtEnK!YD6c=7*J1XrVjXh{N;UQQJQ7H;s-(a}K|
z{|OE7OGPzsO)EL`?Kj&TaY*w2o@nvsJ`&B&&H_xiS$Cfq>3o%pKy`-h?(U7ooEAT4
z9X;ILIY^{@4tzrAek}ux@xFcN-)TL=RTD~Bv3s0Dr(vJl+1@6{Mvav1A!Q@N4DU(I
z$Y8FtE-xQ?QP8qg4*IazG@3k|L*>zMvE6?+;X=FH%#;naz9#Py2pf!szLrb{#G`ii
z|GV*BE=qV4GaXYQvLC2iJbW&<s3&@b7UkHGK%ys1Ygvv4plGCN47z+K2pZmkdwPIP
z#74b(Yfg)nqz@D;TRtJL09>COCfoft9n2M5Ew_GVP$ElV&*|&wxm|_a(0?>EV0Qgl
z4TkNVZyD8TjwBMqgp((=`BW$l>D{$~GmDqB<G!RRtg@znPF784!7@P~6!aqPaz8m&
zEazr+aW>5K`Jdx}%cp_cBqiy4_3jSV>KWvb6E2?@`>2<$10?O=0KTce=8t&`dAu56
zuZ82!H9?_~pFg(_hnJMRn`eg;VJg_$+nbnV!}N1@R*qY>J=D42D$)lCd@uc+{|{i?
zW%_iwME(#5urZ)E&C1;{5+ORkUThOk^b-C1?<OFag{w*rG+p88wZFpD4@}}6rZd>1
z+z0$Sa6ABqj(I@=mpD+=7B=k<0>&Sf7ew|^d+;Klyo+Sqn7r92d2L#)VscUKUlQv1
z1bs+>$8)6H1t5MV(w#CLpsxY-lJkXwH!BLjk$lU%2B*BkQ!%?(EsdTz@RFpUeBgSe
zg|&>=z99{I?+wVR{E`KC1PIJR-O3Nk_l*GpP-s>qwvdqaQ;W>0QoW#{;G9(*88)I&
z1|>FXTz_(6B3%K>D{8C2EpbdZ(Wk29$gEfyGcg_l0(dqu3>N_{Ul8dMsGyb`7%hQc
zJ=0n{r_kYsOZFTbqZMHO5WzViifO%lWw-G44Iuc#2h@;c!caSAciHOj$r55tq*NmJ
z?S*{Gn<UFoX5&8q`vy0vk0^g^-vC<UEOH|Ln0)~Jho(>x@iADm9aUn>iin^&KZwe+
zlC4;@3EyJq1^ug3*U&IvA@b{xl#*IYbHhQE3kvEquX%Ot?d`1^w_SLFi$!>-!&-1l
zhOg@%ql>PBAj0#yH)7vF6eB7SStjsIkLlkjA=&S91|&VE(}rg6jg?Dn1oVksGq*un
zrYa=NGd4EF!T+Huz+{nK`%RL0N|HkKxu#|LaW^YF`^d=1^ud*gh{*Tv-vQ0sq_2I(
z$SAWwCCu9=$j!{jE0E62rSPqqawNQ?S_1i5gDDrRC$mQh|I?xy=+q+^Av!Wzwf(Th
z!hz99?kP|f@R!o(m;-LkR`b)W)q@hTEmvXxe?cC%Joo<}J7vuVEz^Aq`f@OSo?-6i
zU^Q3qn##-JaJUVxk*sW(aTUpEJ(m;3tsDS=i1XiG08fM?etXKF(kv{^bDmy1Q$jth
zaDLYqQ~*;Xs^4XQ6_}qx_JrEG#PY9bcAZ~e76H#xqRx7kVYbWHH4@M8PqD7&TSI7m
zG`$f<ufTw~lBw(NEnUTXM8sa>|0Dm`gbi6%DKT1+eI6z1@$9v2h>`yh)8IXxBNB9y
z`MSs-fc?sYX7bsERlcqWc<hX}KrY@X!;q&@KU+Glwv!VRZ?mt&KAon?NlOD1v|g#t
zz`#I3$~!&Qo*5F<*Yj7;D`~1-HlrY$;H-^TQqOU)zx#Nt#!<q8*&T^R+WBxS7WJzq
z@a*8vCJY0808f(I%qA{2HumdR9CUQoz~BSXeeEPaN_T>JlsZEye0(04)%Jh?>`6fw
zMi}psI=M=ei(jc$(R(>^^H#4q)BUwXLymMM#>dBD9&Ag_9-=z^P28Z?D<gW}H~Hc6
zZ#RU8F*@Rq5yQ~zs^XluhTTuAor^mwqx-GWfo1_-neT{S;g&u+6|g1$U2F3}(rXaY
zM$#>J3CHR^^G394x)pLtGu_|Y0b&fUW4|r<!%xtiQMxtfe<XJ*=*|l<zy5DI$ZROh
zCCP#kf0$5Bz)fU$)xzxHZ8eBtG|gVwQkqAh7%{(jRm{S=cCK)JJ^Emi{X0j`OtFci
v&t0!u9f`SxSt2o6Ph-`n`14Ko3tG|FPxCP8c9hqhBmiZFkMh;BpThnJ=lp8l

literal 0
HcmV?d00001

diff --git a/doc/assistant/crashrecovery.png b/doc/assistant/crashrecovery.png
new file mode 100644
index 0000000000000000000000000000000000000000..fce3805d0f065ac0efcf239965b140e86e72eed5
GIT binary patch
literal 6594
zcmZXZbx_<rwD*6wF5Xgnixe&HPH}hFB87!g7H5ksQd->I3KT08cPQ=)6t@C}F76IR
zU!M2g|L$ax%$y`MIg^u5zH<_;rJ)GIrNjjQ0HmxWr}NbBJylO^)Tb7V9#s9*;Xsv)
z-2s5$X@Fo4#dS0&`N@dop{y>CwTwcEN$_H4@)Y`HqVSM6@{o0LcDDQA0m!=9z4frO
z1$#q09Kedo>RN_D1msV1#Fgb_^n4Z%vSE6rbJ+tOE)$8gZ?L%|t40V=xqN!Ms%fnM
zev3wOcxLdciznu&`A+g@t7Uo>O?gb_xGjETR!<dnF7jM-jm^Fk_DbM;MZ?_Xx}PRY
zAQ&E9`d-k60-JXbE{$iBv%(vQjq?%*zn@@y<=0y5?cwcm*`L;%cEr*0Mz{_c26}hf
zr|2PV##qqbFZBPE_lPzL$O<sa>_~V~9L*lCC5?z_4y^RadV=$n%ZN9LBJf$iexWZD
zl8^AoQnRZBk;zt5$8)_s^z7z05@1odT%@lZU>9D^6OO5S_V#c%4Y>}te}f@=8o!dt
zJ?CpZBvc)Y6Z#KRn>&alO&W~*is(x)j$9Wy>XSj5ObtwgLHcAs&$mKF0pzsF&|k9Y
z5}|98g$LuDNw+&6kT3o+WmKljg+QD-xMhiJ=X(1ZS0vq54;X&_Of^3w)^&X_Hx*oN
zwwvM*%Cy1+Dx$C*X5$%+Q=Z8XJuOvH`^2w~sPSt@=7X`R2b2>=#-ziL22GK&qk3;9
z>xNsG8DgbQdM?k%3r^Mh{&fWIr1#1lystNzs$fPb_puct9ybGn^9u@kkSB~xJGgjm
zTt+Qf8sxvu`uh65Lxv4cgcp*S<~Sn0uv-ELTU?S4y@dAFLuM?{Jh+m5%vbBTywCPL
zM2n|9FU>Nib|!Z`n3!J8M1{a9Sg(IH#)fV<v5iT=+BVluD0N)}jCx&u`ZMktgj$8!
zg6_Sm`$gmc!0PifYAHrlEFS*1=RlmOBB_mt0ru<8`Q7_TEWuRCDv=_qItri@rxZhn
z8Bls%u!gl}(lf52t^E>F6C@3{Tj=ga4Qt12jk5Q^qy9p)UAThK#sNGBG!!s<gW)L>
zVxD19!K05DojR>kGcI&u;&s1gykR>%zafg|N1tyGya1)yo~9kux_}T4j1gZiUU8=u
zNJwD?C)ny~Qiw<)m5|5m4D9FlPJAtd>PIDD<$vG}OwulJs;2egC;WIE<hm)(kC3&H
zH&*;<oS?MtY943Tj0~11lTWde*RC_-_=M5SFEPbprLe((#A@_qyc2piF3H)sDx4fC
zbbf`!ba-&k*b12b*|6$x+H2j{;IN|L51jX%u=pz-gof8b?I2M@2aJ}ObygXQ8yX6M
zZN=i$`LH+B2xl%}wKP_~)DD$mL=p6>xE5>Q-Zg|}2$pRFVqh|Ue+SwW1y$mT0ca><
zV|K>_k@6ZZjFgY=OB#f(Ty<Ju_d?oZ1TgGfn4sTzW$2x|U;mHV0ORX<8KYuBWk>Rc
zE)$puf!^se$6$<-Nx!i4p?d2;YMutkIhpzZ?HU!D0=P|@jgHeGqZt+m`MIH7&|)^J
zptX2yPUIGfLu%k$Q`_}a|7K@1`Ip6t`>Hr_U2fy`J?gKsPoFUGUz0z7URPi5E54F4
z8$+UtA{4Tm&Zh%4Fi>#$V>EKy9Vup`$e8bT9%<0jA_cwhZoL%+UbxIJo>?HZys1(h
z(c`Sm@TG-(zP2915g?J3&z!~`3YE0pHc2U5v!#mXMdh)Y)(M?#73qdVC>+M|1@9C*
z*l{(p89ugNvfz?oP!BvKC&#d{3^Ry`j5IO*?T}Ffc{h8r+S>45blFGH&*#(!1h1!R
zP@t51rfi(Hj3#``iGNiO=UcZeKIc{r@!ulF;DUeqgaMz{G2DZqaRWGTrW@LEg)+Tj
z6hMH%d`+sq_nqT>5TgJmX}vk&wBwj9FKa};b?KK0oMBtu3I4vC>GHlV?+*)P3y6y4
zDgmALqQ7_ZFpxhz*1MpBjs=MKE<RHo{n-vvML=fRqj;Y^vl|KU*%ZBM`|@|hcl^AH
z)0SvLC?*iInN6fYn7yDp?e$Y`WP(zFG_y1#-H+$&Wc5$Sx!U^@_;{4U61|D+5VS)V
z<vcP4ZG5XD4*0yBo@9qx%0|_>+SOquz6kUKop=2glPT@11c1G!r@$esurOV`Z&d1?
z=+~^YlKZm?^5ELxCkpJ6)W6bw=pU|69AVpYM<|y213Ki-0i!tM`Ol~Tt4LW0CS<Qe
z1p2;%9OdA<uTKoc^*TI66%8)TM}|R4_gt-yqw;T92gqIJ&jhg~yWPyFEZu#mgLMGU
zl<`IxjJMFpUK#|Bra=LR)I{O{33`$m@xUP2Mw|eU0FeTU%iq0pVts^{fKqWul1X90
z+M+jFH8*y#V&Gb$abx=r+d%DV(dR(9Bp&Zvyn$bAwYfjBvgnJdt>vf-q9Ry5*e4<q
z-oSc9Zmd4Gc_BCDXf={zMEAw@_6~(qNo>K_ybR_i{&Gx@(%QX#pN((lkE^Gk{BKU-
z2%Tq!>BCd9e8162<VUdX__yL;80Q-)Xyl_M(GwfTu~=Jx&If}taO=@wdG~%H`xF1+
zAN$O#OHk=`oG5VQc_q~5Bh-{7Bq(8Ow*1|?<~eNk8HdNwp`T4F>`zzit;LbldE%b%
zJs#k&=q;SKU9wC%7Nz#<xw@}cz`H{1_>pa8jqNfqeQ#xN#92CKG`Q34W=ZS5xJW(T
zzm`UgEskQB!?cqlY#Ien;{=q<^XeSgF#B&C0QfYILx&k-T9++QQO!?!2Nq+bN>c+1
z{B=JAdj=a*yAyjU34(E=c-pINKdqzpgbY#5?WuBdm#*n>0@!kv8fNyvp51swgU@E@
z68%eatAk$`@9NC@*||29voKi2!`$O7IZ*BZ+pC>J*~-?obkUWR+W(*`z?gQ`W@c3V
z{cI$T1GJgECG)0u0RzJAVrTI;q0)Q-sA|7#ty64hoDHCk8?QTp_9uX1+GC)iW#YPC
znLiXS@mu*4Nu3vRZ*i~tYC<>txu_yld`122e)qG_|F)Jmk66wgau0zC=~sod7DRnI
zoNJ*PVdzH9sou~_f}A#@9M>J}OWIthDx37DxKFW-T}xN-YW}80q~|HQ*kq%C7h_Ec
z4#=xYO6Y}l{~#hhhX+fUVh~>ZPIVau#j=#yYRkuJG#E>YZ}SGsG<__rKgrU1jDVau
zazmA>gg=bTw|uOcTX8$T%}5yF3)!*x)A1Ik;yux#SG?yy2Y#E|<n{OzC0m@de%KUz
z+&IvR<-Tm8vGT5NCrZyUu@S;EYGnkZnex&Z(O8hteLL&Pkm<2mC`+|CtZtm{F!18a
zkNTBOGA(3aPm#dsy)fo~-E(^942)cCCcW+$R#9(RvXh$As@+`~zo)(wUw1C&14MTT
zeIs+ZIV~3#&T+KJz51VapnXVO;Y-bdVj}sl+w>rr39-}06tgx-5t|okFy#x}sKLMZ
z!kT-9hT-&P=Zi=vJ0&naB?&<GmFOAdicsdu8zwh$@OR}P;REmLWAs~llZg3Pm!0a9
zD@I1G6jL^xp8K!uRrkY8>C7_((q#N=gj=VmPG5F%A=-}L_YY>Oo>4!Ig`c+ZTasQ1
zR`7+~UryRJQ|u4sGZn^<^^T>JR`}B4ALsubenp9l%q##LU~D=8CY%6V+ZHgHG5WZR
zY1me}_;}?{85acSZ@_$gnEl)<K_`i9k;<w3-s9?1SU>SgecDJT?WzsaQRa;1MH|+U
zHTgX@t2UuYcQ)%7z6w6vPIof6Tn_zBrX9vvn7%Bz(-flp`7pM03-!mQHM`2_O};1j
zw<^`c{<rqX7vGGM2tMsAZ?oW32t&@xuKSF5(v`9Y=Hw&~tDya;ya%T>bLWYiU78iw
zH4X6k9S&X@O86b|XTP=U(r_=$pHn#(LTJm)e!qQf-x3;=x+($k&c2=I5{-?*^lEeM
z`TFk}b}`my<#9h~ZpF1ouAu{K%|kCk$UxiPQYA5#$?Q7%?5APnS4$iH$I|8FoJ;ei
zg}XV1YD~%du)f7c(CMuTA^@!HHI3r%xVQIknW~FApjz(|)5#6HuO2JWF$AT1%L+?O
z-=R=Y<!ng$ynTgi+DO-BUYX^eM&NUOTd~w@rand)G!Ojq&ztbVWBT^GzAyLD3<|f#
zWgjngtlB<w5om8rP5x-;2lKQQtvt=S^d@&$DY@b?-buEMGMsrKgH*lU^EdN)w;@s8
z|8MU|<o@tO%E{jBa;4?s%=PT;#&1FEQSS`No3f%j3oCp`@}JD!-%VpL=3Ja4+NAQ3
zQ5Am?R$)U%z4+-ni~JG!OZ;1;6qG9T4BywQJ;NF57MXc)qIwZB|E#5_6*&1~)in{F
zg${CBUCF)i5Ux=eV@gPQfqz%BXnbLQQv#2`w_|==iG!;UPsDeOBrLLxgqdJD_oytn
z+Ypd&{8se^8kB{SA}Qw*gmH~g&fGxumLz|+D1Ih6^xqGwnwrnYgm;XJ{~y>-^8HD#
z|EK5EFy1wA(z{WHuRVb?KEzc+DfK0+>)1+X;Q3&GwjVBMbhJ4G)fi4{#F>mtFuOlW
z|BIt?Py&rs5KqjgTkKhGv_&5tV1Z4u>Sn{1bv^m&G?yFe*;1Xoz0a~x5Bl@%gLJB+
zLQ-~MFedEb<~}558vf0iNJ+WQzQXiZ(H|OpHZ`c|cgU}?lB?p+?%jni#xirZ)hdlN
zi~rCFlHOX>3h*y3mjXJZ2kCok^XJtYxNoiwRY5;EUnT|%@hztZObH&_Y3GbTk$xhl
z{)E#+N)YSNq3oc%5>aZDTeBVn-CR!<jDHMmF0mrlx*4A;U?Ya^yuTgKBTrc}MfrL$
z?zEEiIMO1Liv(kDA9*f}I@@LDtIBhu_QC>N*f(qaP(N}s<ScF(E~O6@8307LRFs7E
zu1>k5BQq#fo(o(vlC8TMHplynRLb-c#7st+oT3C09qSJ~7~Yw&czv4Z{6|X0ZZ1B*
z`~GJiA{6p+6^?fC7CC-3Fpp2I%dacg=lDjHj+3gt5J#jk@NfBfP8Amv8ofXyjNuZR
zQm$}2R{&Nbp2BZuLJ%r1<S9_%^z%jbV#LMP6cSh-$&;LV9?*zxG{wGUQL&K+-Z|z~
zR%+XnqzxAmZ>9$`2oj1dZ;I+W>K`j*pXnd<35oO%@18mMr+2^5$EA~k_tynB#_6oL
z_4V053f?5jh4?qvQAKu7AtUnF(@wkXnHQ9JR{|@~Mts!<0|AN69th${7ZDV-;cd=)
z#E#AC^D$K+4T($OLYtD#Xt_%sA!SKxmf2ALy{)Xwwxl`4Gi&zm1&0l|@b8M%IfXGB
zFLusz6G<WqVY*g*xy+J`_4m||g&Nx~CyXE1+w1warO-1+9Zjpp@Vc@R6@>yO4Z%iT
z6ve)f(B=v&qyu#+w;I$rgDdUVRL~@<`d4V7sR<IwmvSk%oJX#9b?4?+>M8>je|0y<
z(fY&c4H8W)VZULL*i^nhJKKjrc|NfsR&q!%%S6khH}vkvMT|okvh_!p|09(W<lg!7
z6E1m|Rh{k;1#-4$j0Bkd_imBXIQ=D07-oyhmo+dx9e6iE)~LrACF7B1>~G9M;*8(^
zOTu6wWK>{ryc@Qn#WU>%{&`n@yptDMZz6mBUsNbaOsv$k{p&2PtBZ}J#D9jGnxV<n
zayu7(GjZH`aCu36_u->4pk==CbY2eB;wT68pFx<WIzyPyQlfoYcXQh>6wF5J!vKfT
z?ZsG2Dz2c{WSh2^hmqv_5u@9XZJppL|LU>H{%3(}F{|n}X0?58tFYIPZ{9p$0_}&$
z6h55?a#~Q%sEKFC#<HWtBZ<8k;n2nhF-famh})%xLBg#ac=c)gY=M-yTP$(ZgpD(l
z?-Tp;!L>jF$k6tNio|RfIx>vijPk7ot4}u_=d6LG*P#*VoNGeL*sxkc+>O@B7D7Q*
zjjR_lvP-L}j`7DQ-<Fd>nMG4BZp_is-5Pq@0x=0i)o`_7&5k}FZ+VjhA`T~|yk*mX
zC6BwN%@GLD-a9<<dXMkTf3Zfg)A3TC+T_O5>7E#=Zn+EDQ@8x+oAen^#pMVh2H~|>
zn=D$93w7#_GHB9l{{faRTOwgsB^!<U-A;T*3=hvIe!?v87Fv&t#y1SMI&BfN2<s#{
z1wF(YJy1Y~yDA5KzLwOPG5pjr|3&dPl{|j};~qZx;;36Dg&^ynBveaFQbUFE0@w>M
z*U^{0{MdnpxUblKvCpWUc=?p@;MN?Vms9??F_Gt;K{LSRqok|x3G@lan`7cpQ6Co(
zXQ(lHX%xx@-fDwN%H$^G&y);Z@d(@{@UEWTnD;FIVVx}*l<IUkX7o<>ugYin6JQTG
zI!nJ@#PSOWzr!3)(&C#&wZN#q{C$MK-z1iuKbS40svVloLT9vuld(=qZmchyEoo%H
ziGdpFfkS5$_KYc-#Yga&UqEM>hDNB`B6RV*RsOL`h&O;?q(3nWKM?MRWw=0^C>E%}
zlI92EbCl@z(}GS*@(^fQ%I6AX>$pZEKNwD-a7ugAn0VsOkYN034^C$F1KpF%V@nJP
zZj*KvsUL-i(=wLW+lrI5s7*+1YT}M_y}bX}+pJrX(rbB^Px#>u`2#yj!wWyMgl78v
zV-It{%bE@{YthXTwa24equcAptca0t)(u?G60;~CfdAp$g@Z~m(WU)NtO@0#&))Z9
zjZYsP%+;J*Sj8yPOY!toZ&v?Rt|oVeNIByafyCRjll3lK%8st(r%JTKvcBr%;e(kV
zdYlZ)*xLYzjQJYi$6L#5+}x&ZtX)MBSZzhG#MPrm)!1fqzz4WFf_6V8;D2ay{j&8&
za{pc#HcvNbgwr__-H9q4`kiVq%e9_KbJf<2t``NLRf|b_s?m)Nl?gY8OVjOEJnzLc
zvJzI`cqY`>rQ;a$<6+2Lf2h5n$Lyj~>XaR*`Wq&o=|2%SfMxR2>>}5<g_EHDMj|mt
z78zK%qAzv**OF^1B}rfEJ;w%GHf_bt%vb}#=Zr!}%O=m;(zW6btD;=D^wA7{FVy#=
zm9UJpjsGpBpjVk)Wd3B<G><8FUXC^SD@w742Kbw7Uea+1X|*$75r(i_^M&S=1~Wh6
z^?#M+2xIxupG>$U_?`wkXYoOky}_&T=*F&R7LR7;v5hg!_*SXGWvh#3X5f?{!--ZU
zEXthA68(57)-;B;37<lMkcoNj&Ut_j6n6D!a5h6f2>+@FIRW*xBb!rLkk=1UQcF3=
z3RrdD)w{iw+nNH$%)udH$-()HILJo&ScYZ2-qydO3E|M@2SzOZLnBaUvC8<l*JiZY
zN4G0z)pUreXXfJ+tR`0i={75_dxO@D2k$~Iwr(~QJYMarG%l9y`hvN{w<+er4W!)5
zXEknF{nab&eb~XV?akj>#$c1g%SesFGv8Ah-$XoLtot6qzS7qfiPe(8d{!<LnH!dA
zCak;V2St*ZgozK0;$Ud5Ir$taz6Nr9!9QA}%kIbD<ALND(Zq7hakT(^Hp8m##TKHi
zSBK|oyXPh@0T;QPUk7L|{Bwtl+wOPTbS%b8l3f3VOzQRVJiJfTMOpoFlceSBnjN(l
zg6ZIP16-ub93`QvkcqqeT_pw_mc^>BT0aSFO|D|c&S5q@Ui;^!VZX)JVT;3F-TKi^
zL$mpPJ&D<nO|iot@i&lAVge7%Y6f0$nJMq@($>+aevFYu73f738nil}B{i8Ccansv
zC88mk-yp1^u^RHNDC}M*SfM9g`1**QAO(d&oniiDYs~zy<wY>r2*kOO@Q+Tt3wNm}
z%x>mtI3&GNvUN<$;@_s#Uj}lu!lb~u1h{Fg3BD$Y?fSw#VZ&y-xWoB!4JOev4qidQ
zZ){{~Z<p&Nar%GW$y(+*ojFsjDlgu^NW()ObIA5_iY@DuGDvd+ZYTP>dUls*%?o>?
zI|OKc68hYBmn^hyX^Ma8rzvD^@0)82kWBlx<RYfwCscYehY@$87k$yIyA%D3vwZjF
zd>bou?2eynSC>AT`HK05J1b@|YVYaBdHr0eZ`5(TbACHhD2cu#*Og0Q*xYTNz<6Qv
zL#e5Ie=!xdPj%bnydA_w>k{UsVpOh|#|3X0Z}1X;GT?>a`lDnK$sVPm3)YO6K*#X}
zs?t9b3h&C(MkcfEpD6^Y%wI=5$kB#PX$wAic=7VOd5CTLW3{Ir=;Q?d+LF`mMVJzF
z@t5VCZR1Zy<z2<fa;t7z+y@5jV*xF0<4i%-xS~uh8{#La{9oz5(5iaVjyY0tfn8g+
znuPA9L=W;wCbK*FM*PmW%XDtXdnO#WFF_%TGl|}SQyF{!jix;Nt}tb5OnZWfOY1^$
z$*aZ8&aar^rZV~(?-=x|3<E)D-~fB3o|u}WCiT$r3fUErKUlMWhLz)6wl}^Iq-(A*
zS)-dLF0|v0n9OP6Gb}Ke;8$NE=W)U%h%`!IJY5Od@$4b%<HnCas@LHbOLU>X79hgV
zY+MeGD@xm7Zaz+xp^WE_jAO?6zsdUlP3GS*u%*3|el?HnP9b0P;vy8cNaQCy?zd!Y
zcf(F=xDJHbfIAmQSx*iHcfnsK&HZO3$+0X6M3RqJ%*#B6-q$%oIR8t)q(f*kTHkk8
y1J$$iuDN;jr?>L$gX9n~_WynpaO*$N$?=f<#(w{L>FKitP?pz_t9WA-{Qm%w^{Hh5

literal 0
HcmV?d00001

diff --git a/doc/assistant/dashboard.png b/doc/assistant/dashboard.png
new file mode 100644
index 0000000000000000000000000000000000000000..c71558d7927ab85bfe22be77c89377356582a45c
GIT binary patch
literal 41061
zcmZVl1ALrM)bNdO)TmJ#G)|hvww<Pp8{78AHXGX;+qN3pwrxA_w!i0o{{Q#Aug~s<
z*_m_A4$hqU&Y9o8q<<hG;2;1103@-WB60u#6b=9Yp$`WM4q=TtA_ZUIfj?F40089U
zzh4NOQJ;8lAgsNZ)OXlbC=_TWEOh+(HgFKO{dX06VQWiELo0iLu&tr4y`ce-lc~K4
z(GM}HU&=nnSO5SKKuknX!FlPV%}qsNe)0Z2fOkYxM*tcF%}``lL5v}aVqxG5NfcZ{
zuoxgi+s`!nrsxZ<BthLMu7%u4YG5mlGY*U8pW5v3KPtV@6G@W_otR&dD10GcIgf#O
z0(XtDo?asiAMGH~WG>${w6sF&=G*7n=GyMm?zv8QF(Y~JzQFksfj_~QdSZ$KsL+Do
z&l&pPGind7Farn2&$|CY89kjsiUp*UmFI;OwP0aknYjK&l7y>W{P8c9jrxSqx-h~b
z=&v*~1U1mte}WrnO&pGh15Tv>M*0j>CXM#*6;a&Z|4ViLW!@+Qhzy{p_;t(MIAKKi
zPb&JhDk#MBcJV+t1OG`P_p<!IOb&o>Na###1Vg!atZkwq%>R>dIiYJ*6A7^mDGFx@
zI{|OR_C>VqkCVGLrS~5}2{>bZF0Tkg1{2aiad^d?!!R<xD%dXq5Q?ywQzD4_0(rhi
zR78;5Z~!XK3HJOFoZ7@@AL;PDuEk%JnK8$4MqFQTDJqbSJtTsakOSg=X+Y!jQ;OKQ
zOGY=0o9Ok|FBa6NOqvlQ3Ng_A(hLBO^;jb@PiL9Uvc$ABoYVLN$>PGjZ5w~DNuMpr
zp+aZ*snAHv$S4;nKtVw%DJi{Q^S|3|cEL=K?+)O9x+N*{U^_R%vUy(JJ9QvxR?LzU
zoQ0q`Gl=9+XmHA+);AJ%xNUbVkfh{$tYVdcmaH@6I^w#>sG!d9pi45mbaCbK_D)oS
zG<g|bQ{+bhqQL=5T{tsy>b8&R!?>{7VhKZUR2gOi+K@B-GSqB})ZZ%TGvydQUavgG
zd$hT~Re8~>oNeolUysZT+iE;rQ9PBWba2ficplMS-dCQZG8D>lD7mW_wLaBF$(Ds(
zc9f?)j=y?M)*6X^`|Yw8ZOYU99%81kHd9p{*{QkXZ56>QyPfbHgxA~D&`12u_Uy7s
zWR0(Ze$HsDCX$bHI^cAVsF9|j$z2YicURr~d3gSV^Nq*l;4CXWtb01+pVj1@CWgcP
zjN;`re?<0xYdpfiA@aP(^&$HAANVy!uj04DHmP|;a6-e$%*GZL7XCt6Y<rzPP=F5~
zKG4w8dOd6g9UPdf!f&SBQvYc%c~@|PTT0(#Bb;hkwp_D<%~r=q3n@BvY>j&_E57c+
zmlIGQbZVvk9FiXHay2Y-&+l9!A8}3iUa?VRQo&<)lgm3S5?JP_AC$<V0RXtuD?jZE
zQ?q}Aq<Fn1mWIhW#;?iv_?rAavv&0P{ps$LH+lMv7HZ{IBhaPn1~GkK6R?1guF2Q7
zz2g(QTI{V8S@5dFMgM--@Z&zU1Hs!S?S1R|O}@DV5oPz9C!yT+X;P8T>$x<*yv&3z
z8LROruemo%IkX+X@O-(8i1*ml?ZU%9c0J$Tng2bSCba0T%VE-P-q7erMTu<MFi!Q&
z*UGVtonPsMY7MADwWz;-q)#J2_@f2@ytit(c7fmK%cS4|LWGqB8#q}s)4y2;e%5{p
zVG4d>HJ9!Bu5+5jamuasd!#~oapa>jqeV5(yY()T2OEuNv&r2_hBWVE-W}!-hKOGd
z0DP|NKv4!d0F)w0rk;qM(&K`s-Ny2tKYyk=;*pK}C1F(xaft1Msxbln1S#HDNy$j@
zcwse0TwNS~RYAqd%n*9{<2Lp0eP+mU4kZ4Of>p~dYOQVi%QF~nJ<IB9WsD)AuE`0>
z@IVrB;}0ocFy#x-8;ZUNz9a#Gz{<+XM)${RxgymMMqm26y7Yj+iLS2f@^UL39Rc<>
zMBvMKkUbYWVB+p09Z56y4~DOW=-nv!&GLE{Sw{p_S&YcqLy`@gX7mN~+t^2@3-Q>;
z0`?_B6aoUBBa0<U9!(Wp2A2T@zvjY=V40O<Q^e=ydrbIgV40D=e9_XCOZ>@=nq>Gi
zvdA`%%i=hLi!6D2O~&oDDy}0+ky##odDqvcT;Th{3z7C%f5ML-kmcH(jV_^llqU;O
zC(KQ-<V`$m<OC?rS=UOqhv>YurtjEj+7csdP&)*s^m)COD3n7Iy(?>$61uMxxQ9+w
ze1L_Kgcx&|e<G|KY^PO!V$Rsu_>rfrfX;f?q@3=~#o)f4_Xzk*aNyX+Q&D?aKc^W<
z4S*q1HhRlqiuKqpld5QIVngg4i9heSo0CI%J`P{CYFX!(cY9z3@LgiV!?!b^R?IuL
zoO<qyY+tg^3c0fxv{qSBsWe0~jU}GCsD8$N4q{)s`31CFcd=}ESs?%jWz1TidCq&8
zNvYnitiqpDP@#Mo{YfFR*A!W8H(sIsr(D%pqt>Kby+zy3$b8MixYyFrSmp!03C#;x
zM?DH4u8_xNHXU0H4Sn=pyUwEC(n+G?wWFOU=co}{XO`ac&Qe!u;&VNuPvJ$H##=@X
zwemCI!ey;vYkL^tlG=QF3IGSfg066#(wexm)NL?WT%n(u0`PR`?q=1p)B!D>!7`MT
zR#7)7AN0-@aZv_8%eZn>Bfy-iJXl(;@5aW&^VLK0yoY+X`prYVNszdQg{+Rf40MlP
zrgp^hy~=r`3!Qpq47e>;>-6(+WN>N~TD(S5N_`A1Qb+h6<oiL^_ZKq*!^Li*cKhqy
zvfbXurpwyYl$_I3KSNkYhnK2q@)>QQepLN3w&)I8<<;Th-KuiSsYK*nkrSr~q7toZ
zm+ZHL;|=_GhwA3@;u~rE)SNrpX5AcD97n@^uBgr8Ut4Cn_w+9?Mj`Jjf$`)r3Uum6
z3;mH(e%NIc4y4CsQ~fPpPJ@PvaS86xKQhp1pN#s7Lx|q2JZ0>jKW`5uLLz%uY)CUs
zXB`3Jz8snI^6;3M4+Fj+!{$G^Y=hnh#8GXPmEV*FJlhK^F8SG*36b2Et{>LT;<rJ|
zIQ$`Jdlo2}O64}R!xi;mEdjguac|p^{ktA_I!1n%CcCQ;3z0WlRL3mk<*hO>-n~iX
zV@??e8@53t{sgG5GmadP7r^A~_LTQg!{xOU^6qpk%=)m?a?ZC?|FT9ZpGYQ|Qk9eZ
zH|A}r=mXHfNnZ3A_A%31_^%&E?HFBc*okc{wtHs>VeH?R+`PEi??vpt-Amt`%?s5=
zr@G5zsGuE2KQD22Xck1c+=J#5(%ndmzwcx-Tesdy`xb@8iPIRN^&1*j1VdlES<gT2
zwA<)?-@$D!u&xO^qr1yX#B~UzAvDvK;lt;7KN<`v^*d9R;iFW|6&v3Y>mROzMY&ve
zuVPxj7g$`6C{CoU8%_o!@V@#>7<%5WBa3U4Hy@7B=%P9rZ&p0Xe4ir*l=!OLE&E}p
z23a7W@ZQ&=cn@vM)m^kB2izqvQn6X#8M|iYoS6|STyga;rgwW3>TB+<BXcSdXxGzp
zhLHvK&d|byXF_KsZy`ckT3Tj!J{_*Lx!Kv;zFkIoxnK5T{jeVx9DF?1emCP-#C|ir
z=rJW2F%(>*C8vIO1bS`{0>mo&npF43_6dszxD2$Nb!KBv@Q>JjobK9pi{7%F3`sf?
zExA@+I(ph-IJK=vUaoqR7tARdg|Gc>P2J@q3j8M(PviHhLHUmClJ^$?hSgOMGbc^$
zjA8|2RoU%Z-sZc*cQrO<8q5fY>x|I(pGk*uPIZ$9K%L?YcAO$*cySD_c3#S88pv&m
zXqp(W)PmM<56JCQk5T}@)s59nf4;>P$tgH2C@6&qa0{t6oH<}KIqu6-AZgfw4gA=R
zyS8Rt3Co^PQV$7mzUv^EZJM&6p3tz|x7mA0&Z94d0v^>cufB+Q8XdkkjCoSL$oA07
z*u9C*y^GKd1&+x}ozjhk574xGeq|?jvN@x#V{d=<w93P43NjylW1z8=>HE#ZIm9Hr
zUz%DRp;|Rzso4b%pkf{~NPirV6a~CR*<?#11Blz@bLK&XaXC!ak_XMQAv&Hlkuc@=
z$dIB_&drNn3Dn2GkhSQe+b)KNtOIw_D9g`&Wj8m!DsO(l!z<l}$PC1t86DFvKJ~#<
z4YI9lX&f3gPF8}=u{^Z+Ejfk+$zexSfi~tHTPhk=3F+tON89HgDO+WOySltwke{zV
zVJ7Xsx_`>tQ7Jtw2BI#Bw)2~pz|n)U95v5YmTdcLMrx%D4G-gf`2zRxW2?>fhi(Q}
zc<1zn>gp-Cg!z{(M$3l@Li3w+4u{Tuk0Ima1bp`W+Bo&{2#{Jf!4KEt;(h-01$8ZX
z&3!qL6ZiTy^R#8e((qwm_}>vQ`A8tJSjhV<kTRr8zNyX(BEKh{8e1O4s5twEg>m+|
zNP@kk-uCSUhIZDFz>dd^ssub2Fz0v;arHFXY)Vu6T|knq?tip$^hdC-Z!!I_eQg*Q
zA9>{FIxspg9+=<E>nZq{Q=+GVZs@|g>eqR5INjFPR`*m}TdSa`7(NJMvXeT_D^eKw
zvOIlV0ew(=s0O%B{LZt@9bnC&?wK#SR<PwV@^gX3XI$$r137i+&;mHq*hd=?I$>)I
z$y}Gw@@2)r;bCiP)w-=|rn}u|HhH0yu)*pcmw0utWZd5P%<~>v+Jx<yYFGSAtBFmO
zEJUU#U+aYtN+EA<Xn410>SS1LLkXc#-AicriX~R`=McPjgr-Tl9N{9!iOGT~#av;|
z?9n7M%Of{+^dVW+U-Y7o2SBf<!92Ty%2lC@z2|BhYPJtwBAcur18r1yED!})b5O(7
ziq*!E^TZia$e;zoLd5fiMn+y{D?Ib$ib_jMXA1IbN$xi`h`<$TTmXoBJDgBi0TsOS
zdpRs9O_U<1ai!r_*&Cgkb*L%o3>KMbyzc$~28xI_YI$WCYQR2E$L7(+Tn1&8{>h&{
z71?}Oeh0evT~_KXC3nQWRgb-7yCzZ6ms{tuPlXhxNva7>nlJ$7)zu1iwj@I2Fr^6H
zTwT&aZ)VcfaS?diNc$4``ucjvUv3Ke_jx)`!ti*VYHCt)l+S>L;I#fmF2$=sW3FgG
z<%|=RHwnx>E(R4KY?LC~YLjXnX|6pzx%33rtUU}-;WR~<wkvsa*uBME+7Hd2Uj1sG
zkWOfkLvXwW_<bcmw3mFw%ixW8>xrA%c6`RRbiC_x%3W1~uFc(W0amDV&ktvVb3U}A
z=X_3=vA3wiD&~DiHTFVvmTBclmA<hXnC4Lf|4rpP2%wNLVP0zts0ld3l%!o?YF(Io
zh^?W1g;K^0(Pwk;Ky1u8C^k!OY>@^r_JR;A=-p6TEl-J&key6Yp$17MdSG$0HoMur
zO8zD{oB4||f?4aW$#k<JbD>OcdrNnjn);z7Ur0#%C3)2z<+}tcK%!)j$`Dq68}1^<
zRIfY<TF?ZmFx}%$6%i3pVi>JomWGB#fht~r$i&KO&J7q=eud+RW|-mGYlq<N(<zIu
zy0)v~kgH22->@K$j(=%;_nwZ^uw>LSI!WjSszl@cajJh?;_Ekl<G42H_DjoDt27_>
zbHtQia&e*hQ4nr3CvN$o)!65|;)Fn}?P>i}iUkJy)$Z=L{ALwe-I-0D+9TFd=&a`$
z(l*6@o&^878O5R>GYJU^V7q)UmOOGb(YL5ZzHL4gf<t=Ng1vd<7B{C+ZTEsd910F#
zax(o;WR>po`F4PHcnD$yIN#bsW`Cz~c@#>3W<GPe@Sbd(54VIU9gmSlk^J=l*?kY&
zyQ%C&gqm0lJ`(B8dZ!)RGUGAmo|UwC(4)+86{1Ifm29JV!WhbXm9qnclj`ED`D(On
zZa1l;brIr^1dPyZK6?!e#lb4e;&3wUdIkqXUw8`JlqZMTH)+{%iFnL6KP;CnUv1S8
zhvqLmh;;YCe)ZblXxxAc51pfHIUx9gkX7KOW72Z6Mf>~Ivck@72YcbcnRd?fgL}h(
z9gKzh9-XS5J8k9mmhvhh^=3c42J{V6#8K0Cb`g@4-BSuSs&qa+#rXK8dQC+wzIkJl
zWj-L9f4bEhb#rRTsHt9S(i3>5`IU^Uudh$^l;1Qle}*J`=?@hpC3a*B$#c5;7gfY@
z<O+(0-~yIa>lOJ@84;50N5%WCB4N9E`18MGu;}bG^d47KirV9p02ag8Uay&JWv6j-
zs`<!`PL5)nXsqn>W=hIXfe=BWB9i75FOdNxJ60l>YR=-O&WmN|B6$y}VrZ-cgqU12
zev!O4H#et#m8WA?Q<49&LL&3~HG$`LR2eeRLF2%532k$kIO%IzljP#0Z@V~2`rd8m
ziGns(hp`%6!g8<&=IANF6+*p_^A{<76R2L@_Rc*w(O74oD-ctw_nsD6b8EOO|J9zB
z=t||&*ZMN9_!7_Liam=zF{I|jJP8zL<6-O#q5Wf|0G%eQhQN~(2hJdBR&|T>_s!R|
zu=^Iy=W3@l-pKDwi<4Q1_eA=dW2qIatr+ZeEma%%r<`P~^$utNe<5HmF{{^4j?3jH
zjos&pww(6*=Q5|as7s@+-zE*m<esUO%Nn9wOm=G?=J(ImvmzCR?(dpF`K;@^#WK0M
zh5akVyK&){7GZbn^qMx$yBYY=VJu@A5K_3>%;~Z5y1FKCr**Dr*1=v1W=I-CM1*g4
zlfU70h4Ud~HoCf|U(4N0jGe#Xd<7e{yR7SDEDh4ct@GWs#E}M>daJL5@_CI?lyExG
zSe?e4gxOjSsmq=uTsp{uhKjJy*h|cXb3BFt7f5GUH9q`aW>n=FoVIgeWTK%(@(8{}
zEIjWo*GJZ03*YDM3b?qrQ3&};*_+t7w&xJjIAtFs6}0b%J@4F~dq1ZXU>HZ1dYH+&
z1$XeS%Q|dbFUv0fo0GC<_cIq4RQ2?MrvV1y0$Pr9=S8Hu<n4^Km}mILP+kN~7^8b`
z44*ObDh3N*fxEqdg#jFLMTgSb&a4+T@2vM(&{;nXhBZ%qrQjlq;(ALqK!|>6?s+?j
z*7p#&JY>!q=ZV#%^*2k~&JP%$_@<79sq!2b+IGG@uShekrFb>lJCXPq;$*1~v2$;f
z9&(}X_#E)n<8+^|E*GobL*x8Srk#linUg6iI`ZPquEH+u^fpu*Ylg;i#j>xf_Z08_
zu>Xhs_oB&gMlTG34TZe|85akc<YDF$^s}eim}~8{^E3SgEbWlAAy%*I_fprzi4Q98
z*HK1)W;)KfKg3_!eaACCYn>FI1VWX`3d}zU5s5$}Qz&&x!4YEiW1vDJ1^|tS_kmhP
zHfBm8Kn+HkU-(*-UGOkMA_sdw>Hc6oA?M1%-Csp4iP7bffKdNRV;eOe43h2eq$K=T
zg-8;eaRC?&WglE@{s6%ivj@L#cB&>a=w{u45OcKlRP$rN)s>YWb2K~C@3znYs76M>
zM5ZsUA6I<40O0H+N9K1Jx6Wumkhq;P$V_AiY~LfV1ffrdCJzhs{jvPX%dBWnoAj6Y
zF<OQ3Ed{=!0Niw_{MMpnN)VycAzUBPqPP1@{-FnDXkp%PGPV<ek0o8<f__7}3!|y*
z1*c1_2?Qf1-?3+VH26ncn_>6}D6QU{--{R>hiNtj!X`$691Q$`WK*b*L<Gr_ec|t!
zWj0O-04SpmIeOm67|qy@c3boip7Z7Q4hfw=(lMP*gwD%uwrSxqUX<FxP6(QfF2KZ$
zuToq+&(fD`WyT#UDMKPav(K@xa9q-N_KHXO2K=NV%ImY4$jGWj`OjmaS!bosBx&BD
zF4p(w;g}fA2vJBdH+Jg<w~iw^l@-&uH`{QMd5sGf8;AQy;3v}+Q1xYawL`M&>&-qG
z6jeH1dT^4}-Z!7bzW(qmEelyGYKf*~h=-t_aB_qPOKKTEEnSQx=QeWQ-0ly$WPi?H
z@k-hw<r^z6N_hJWnc7*94*f)r=^<rJ{A$ujo__*+<dXEd0s$t*Hi-{e?`KB$IcG1l
z_Wa6uz0rTJKVdC5@i+BxAvn**@hzgfmp)bJpZ{ph%zU*e41!+Gz#{z%mAC3wDCz0x
zbFjYXP=PB(foDmv;r{KwuM=DegjC(?s;aWb<lu<G@PBrcCl!zE-t0RA{vvL;E}8@d
zn13)EwZYF@I*~suY8Cu9;PkRHXDR<NbvWCC|G4!Te(mCYl#t^;LBD;K{!g$Kq8iBc
zCvnSXu#_JECV2%IGa6dctcZU+-o^#(|B8pQy!#KEuVB`4{Rh4OFQjktV|)JZEmnx3
z$MY5PwEw`mVAwh+`~T!4c-d#{|HIw?CpmPJ{C|I8=l?`N{hyovA@u(%=Ko6azheHc
zB>zk1|4Q;d*+5}}EQa)Lq(zsL68PrgUGujnte`^w{1GgM*&^Wn>IxU&4R`Xf^YM+o
zC$Lk%K}SaHxAY_e#IA@7f8W2@XSh}_4#hbgbvX?I^0%_9ylItT;WeOC-eVRBt*&a?
zzBWn$gCKx1^!LUVQ8GbvcYfucMQH4@^}37s@Hd{~MT_8~eo0y>@@&6P*(&~J!Y-yG
z<!}#V3ijDMQ_IS!tLt>!YV`;3dO`C_!OZeLRMP3K=UXOs7;AQ)ZBtFk69i1@=Q(j8
z{%u?kjs+>rUZ@DCGzWlZ;V>AQ0HK!rGeVwx9xhoX{s*IRIO7muQ|81LJNn}L-Fm@V
z5?<5DbnaQ`a_o)HX2`AR^dxkE|JO<g0Ic)}LtK9v6&V2o8avKLE(%UK)ygxndMu2M
z6mK?w_h%KxPGo8?79|-U-xXi9p|FK3=G0ZVU5t$(2ydjhaXp$_h7Y5EyBRz#p7r60
z!fsu**a><u>(+<)GiKTYwg6~ke0VCxdP*g#eKvo32qI{Npw9!l{hsnsifT(A^FF0B
zqvCgTvOYo8X?NMI<daGOI5^?uBRuJrTZqXUnwpWMg+zXy_%`H)t+4N)=W!!W+sY{C
zNWpUxf7AOp7Zm($usH%tIbN-q{fAnXg%uQ_>a&pF$qO6VA5J-tz`4#exIRy(6uhNh
z3Kvb|Gd2(7(vnphdFcuYVFk=|e^=GW?;YuerTpzI;P%9C>m*JbOQ&7~1Mp`SM~E!q
zg*LrPp=}xk0Gt2<_}-CvyneCO5WvnD;$-Wfu?5*oK#%vw1Bl8c{AIhVTI3&!bAd>Q
zdAtA}*kB){OewhBUe^!b3`?e2#N^p6I43^V$?wBc_?Q6%h1@Tij1c82(0zPx?dut#
z0C90A*!qrUveJ%@%U@sX@hD(>ysLA+EoWwn76mby{axvjM6b2{u>wnxOY$~&-E_6n
zCYIuN1TiUwgO$bbV_Vo+wAGVk|2Bschyqi&D^QnBMM!dA<@hroixB_$m0cChEkf`B
zeglX<6nQ#rpc3C9eYyh28x(^d0QC8^0L)a=O36WsNy)iW^<8^=xpz^u-ZvZ%e&F@~
zN;>6q!m5V88a|BDzL@i77q)0>e|#v$JBNPtr)u3Rw(iuVUKcZGuKR)IuQKXG@^A`i
zygz8$>NmxTW9X)|UtY##<+gXbH(iOa6uX=(2YBZu@~tRjLfhIRY&Arx*!=z}E{==|
z0f&eRAInCt)&wu0B&};^@X5Q>12!(j05>S6sw?;Q$l$p;k`zV+io#N<KuBDmXkZau
z=QXBlZh*+%mhPVU%_>L4;2Tfh$qWTV$L(**qttNxdmIVgFk!pDs&j>M3nJgXC)GR!
z#MI)Qd0=UJxuqMKUDzs(4`);1EA)X#VZ;Lt5S5_R6B&n1$V9`;HE_-V$jnwF$;zx$
z!w*KfVwNPMEt{YT=A;!+hw(l&ckGdn;}ve}NzYn0fPo`!&-=WpKWY`6_-#*X7gwHF
zGHUOyB5acH@$)(Rpt>}c*6a%cqz#3BIu&>5K%2-{1^!96STFQ|v^t0>EtitXUvOEl
zL~RMV`NncjaZ7g?nCiyDSkjP(w^j{dLMNA9m<bD$mrjA?@T2F6h>fPVr^HwEi@sxE
zVi;3`YZAr3uJ}9y!okC<t*rd@F7u)B8ThJUCqGQ%#2%<S!$=i>R9w2|u=jE9X{}V_
zz$$8V0kf^X62P11AZ~EJLXhY>bFun{;CIe&n-o8e{ERC~UzHzYnb=tU%s;-UUQ9zP
zAVWE!fuu06du|=V<mTx5y<o*mY}B|Q)<QC=C<uN&4P4NTkt>w(;=K%E+3LjASV$i~
zs;C`-0<2-ykpaGxoj2SkO719k(dyD8!$hd-SEu)%rNT#fL(-}F2lhrjGk?sHD>9?k
zK0H6SwlYI=Yh1UxZ545*d_46~SAuxBuum09Iitc}La4D5lEL*xx#9zG4?Q6iL{)vQ
z;wm+XL6QIf;7(WKc^!@<zADqV83>VE@&d)QERW??uw(K@DX8L=jR^%-`A92y%ZQ9e
zqz98~aB=mEgMLr`&HEQbr`u7!^nL8WBAN>E)yqi~#X8q^1?}m{RzK6C4A1zd!>U%l
z^L2~(HCe;8;g@ULZ*MobTo?B_&wVz}9=#TqH0I{Vxa?LlTJ2pn;&t?_rc=49XIA&W
z1CL3|nT6_2l~n5qy|Xp&?`{w$p;Picp?&-MQzT79g#s->LWGHzI1fg(TlWxRG+Zks
zlH2)%#0|I^y!x_e8&RziB;vQ3?N=kEhg^v;R_B12YvxMmXK%v>kvj5D`UX^vHtSjc
z_P{e-Co>%#c=vkh|M3Oz-ghaZCq;!Trc)?*v%2p+r*C`r;%ilqElYjKX{|7aTGzn2
zcKtPy`hNFx+rRz-Sb^3q+Kx~}?p=ZQ!hSK_$RC^iaFO_9Z~a5N?Lq9s(_nd6@a*UT
zS>t&S>2;z{>L#NM6o8)E)LdD+ExT!0ApDsiP?u+KysEzb?EJi<ycB$HsIOP5P*^3$
zsTL5oW${M@C{RS#*tKx+ePz?a9}r)IP{l-ltUf{dEx|?_R5mO<<@LzV%c?Bfh#%tq
z-SlehM#I5i!fbTES6@2>_5^SuHLe&(CLCQsv66n5#g(jS(YnXmf-Zffi;oaT@c=~J
z>CYU%5@V$&MlcS0TP!0xL>`C?=WSsG_mxJee|<%L3)$)p2^m@K-%+ek47Le;1b)dn
z+BglpJJvg?s;Cq?&yJ>&v_?@Eo4(6@tE+OssdRDAT83FyZho?QGxZXkYJP|E`TTG;
zGZLme=UI8K(}x&}NkC^BRP5o9xv(3p3|NWFcs+Sg)}$)IN*J-bQ$qxVoOg^3)5%L-
zV`-|lUy&|601jd^Ubh}L=|<dj2PIcaTR2YEGcMQZ&!H`v)u{R3w#GZ$>Hg?8qfFfQ
z%P`NCON}nS8^8OnK3|VJlw7P8kZY?le-;=Hcy%@75g?d7;jAg4W<5IrU(X4(#cOm(
zge=5|d}vDmCp0F=zkk{xONSvl@}gb}+MOkIJ5XrG(m_(q6uDux5_Cw(2&qpjN2fXl
z%M#&o$$rzQWaN{qnZ(>9<$8HapF&|*q+b5Yz7rD79XCR0vP|$>rN%EIsn%0M7A7u_
z8(|3<{RFj`KL8$ZR<*pwme(3<ETZl}=k1`5koGG|^Al&^zm}@&{%_E|Up<No2>5P(
zT~{-u7pPm?uJA*>ARr)MV9iS6%BUlNe^QF@%ZuF6<W<Oa$MG}qXvp(gMu1<qV%tEA
zk`i)eeS53c&Z&;RgW&IRE<(4L$N92^x2GJt6wAz4V`)biG7g^CzJ5|1tka8R{ebE1
zguYg-1Dr%B(N`%;cgH=0wt4Ev{?>Hr`^nKIpStF+SLRKw1OkikSJX+in?v^iwekdQ
zv`3E0l)Tc+N-PNf_ZJ7)ALM|Hy2Fyo%uKnWa;>J~*BULQ3b~@QfUgk3?_rg)TSw?u
z^<00f9hLm#D+P?IzipiIG<Il_e=HUNoP6~sCT#O$p&pZ2Cs~aBL>aQGy;<7~3sD&g
zR0Ab9k!!I}{;<(PbK~pxUB8DDrb3<2#|rUYuNdQb60B8872O(Ye|;oqncxMgX@+Ma
zKvRO05QX_%O}!lTDr<`5EF>2{+=mMYq%!0#d2BD#Fl!Q%Z1u~b=uiJs%;(AlYN-`%
z_sb|tyZC-kQ1S)b?;TE4&0H-I3%@Pa7cR{S`RUto4lem^o|kUfGiDncytMai?iM5@
zsPXq&59mEl*7;wC_0w}D?_RgHLT4zo;oN%y0^WHF!c#s=J>1vb#VJ}LLn^d=sfgf|
z_p&@zTMKyfOrXzra?yYIRo$R8W~a+|jFypIjkfgRiH@?AtI72)2Jx2vrH8$>l#kw-
z5uxM_<KVfLEj$PScnQ*Kan+4($3Y39&*P&vw6x@P8#^gcE?;Z35q4vGwKB`TAMSSr
z7qXc_oseC5u>K#&vCj0L`}qSL*jTWnB0|Bc+w`xYs_yAKifuM6Lh#Y3>7{SSwlq<A
zL`z8+O8o&g;*~;;HKLvX&MAy6N(d%8fi`0rU(blZykPViPtHrJ5a$E;T~nIH<YLtB
zhpL(G!hh`+#hcrK;rP0*WEAXl<Mp!fnVPy}EnN%n)vcxMoXq95XZoU!kD6!&Z8Jhz
zGm^t&_2_l-($ad=h4Fyg^BLK&BRCbSe69>>#-gyPGUZ0ixl<4T&=Q7ehA_a7EAC#U
za<XK?nnUmo4UbQ+C%$&)<7%*GU3bj7?weB#mE-6A&|a3?ZZj=MC=bJ;u<essepkGd
zc$LH-q?^Qf-J|Rowc2Qt(_X$w*Re>BZE4{I6XxkXhygVG@ty`id<ah%!3Gl0A|X0g
zH7Fr4>e$1MyF2Dn^(ed)-s))mHI}v@fCYM6^8=nyv%@$|o)O3UVD^khw%qa9qV4wD
zBkxfvPX9VO*P$-u^`X)U@RgkUDju*wT79Uux~nYR0B__PTsnf`Zw_?~-Tn!(4vNLp
zWkf<rh<t-gp=`+jOs%Nr4vn<^(AG_=ofezM)AFB3^>ojV<dv?l$=q6A4n#??<_~G5
z%FYN<uH_(objElt6;)q9Dr314{GFHT;jR3sk)Jk}Tu#5*qq&rnkdQz`3>}omTU*Gw
z%nS4EyariYDWr)BuXEmjsHsPic5eK+*0ftGS}u~_SI9?pc3DoVmWs!pQr_PBJIo`*
zq%tsg4xjm-x49Du-xN~s1GuKv1}lzU_<-x04{HN&8XGbRC-fcYC%4ev8!j^LN{*Bl
z<Psm{q<pqcpe${1)p2i|XDX?wP@P9o?JC+g#s1EhcchaIzz!ux_WPC{Uix=ws?zcW
zt#5N==P>C;e1QZ6^>^D!gWRwkZu=Wfs`#7c-SfrUeyy$a6sS9SuT{*eNR(0>7Ke6(
z85vhr>0M+OSVu`%31v_6(=qpV86Fh|L!(&(7kTvV8m!lCe(RdR2xw**8J|46eJ5tm
zx2;FOOYimamk#jru_5|{K^J!rl~j@73TzVh+CRrRCrI!V_)k?qd8-o3Z;-77K|EL!
z%M05%88_TR((7jk68hkoY(nTH0FaL;&RUAE$@$Bj)^A@zkAj)39vB*}8WZ}ZKsEAe
zrpTQ%pr4l22*`*Z6ZDH8bm5zIEk)UV)Cja7W6gNJt!ylL<gZ3%(8o}*K)~ZSlYy(y
z6Ynf;E(emKnBFk%{w+pnyt$+K2-_<fLp5~eALwXAY1-~sELdH_4Wfr3+S>m;<{j!y
z^N&;XbRS8tk|7R6|K|+|j?a)=U!Oqb^Vjx7xxBa_ate8vWK;TU^f&TXxl@P_4i8NI
zLlRNkte$V4_Jpb_;NOUXxqCn>C)-qi#-QGz7~ml<fjsMgc*roV+>gap4Dv)kW-L>2
zGPOSq!VEA;eD>C)&}SRR-eRPdr}Vb#ezz_FFWqxppY6u-@^Y}n7j}Lp7E8v-#igbi
z?eTX~Oqj?WpOSnzRZU(!UeCoCJ|6I6Niq>|(0p~@+I988Dg@DvR_}L4cWWJB2kR|P
zeQF{9QxoHSS0b%_(rb3n&m1Oes`lrn2V<<K{L!i=Ozb<~_-%av-xJGrk<0a!SK}d*
zhfxE<xrggjJS#H@A2hIYPYl*ar>Cc}WKy3H0=6-~CJq<KWbn10+o1MDV%#ReNWEgh
zfPE%=@$uY>ea3e@1<kc9?p+Pvu}7_UJnYXzoi0)(=G)imALfhJUnKA!y*g+c)Gm+n
z%(bmGU;6q3T9d)qLh-tu?J(}8)qH*mP^I^{E8Am#rlYV4fmdz5yZyi8<W=68@{a9e
zu2`&<`~dj8W7~9Tj&KN)15u}$JR$&hf1&$Q!=O9Oemtsv;jkqRB%?C>LB-F{&&$h8
zO1cYny1Tu-1>eJ>5VY2~+&8S(=;4mKo;<Axj}rcLz5pp$H%=QDe8qa=8QY2vxE@+!
zf$Byy-_iy-Y}@2tVc3|Lh{u+?#W+o%yq{mT$ENOGjhCsKlT8(lWapb#eE6GeHsJbg
zmBnHb3lsd*B@6(((VSkdc7!$evokPcVl|R-;wD%&eKw;OpRTv2*ziV*h9wi#lb1fc
zV;wY)VHY`DZKwL4@&#V?PP5u4o05|5HljtY^9~6n<ch}Z+Q|oOPD)4&9~~VfYI{C5
zbiAGxWO%yn3`C>wzW}%U!YkUJ%&e@=@JBUcJWsVSG^(G6zL4~La_bgbClGX?rmq35
zX+1N5#{6*%!+i+e%;vo)y^S;PufWa64^~4`pwexn*Q=Z^@#mcV7Z~#H40p&H<<t-s
zs_PFMU1|`(s;Vh`X-$g(zo#na*Mx+1k9&OYegZcOyoSW$Alq_Czygf-9TsM4=U`_D
z#QbL6=Q$J&&IO%q_&`m+eA;C@Wn%(EpM?_@5F!&$N=Fl-syru`BnV2G>zg)6AJ9oP
zG+l2&8S~@h_X<TqFp)eFYXKFtRd>1txe^{*TqD8(L<=B9F4#B7dY(E(2qD^FKn4fl
zSQO`%mfFlV22WaOHIfjTN(Y+w(XJlLRAr@_B7~CcmzbBQ1f-HXJS3Q7air%6Jzd?&
zm6cYP>pk=N^0t?&;S!}XaLZOM*Lb|G@IvYw9v(h8fNRHUMSz5Wb_Afb!}<;i52J!m
z7ktirItf}K0npi-oSf@Wg|&?8+Ms;9#KoJ})yi~>Mp5W?LP+yYS9?w#6bLAvJtr<1
zbA)Wb7q}DquTqHfllwQq&3!Cg?p$@>pe-bmGdoJ`RADl(`OW=%!*Loq@aKd(eia~H
zgWu$Pj&G*lcOq0GZ)Rm%Cj4%mRxlGAfE2n07v^I3c-@UCP5f1LXvoEUzK<QcJvzl}
zNitV9xidG_qYPkmR|gqei2Eu#>ha+NATA+69K3w5pe85Bbc7QxYrx4Jqm)M)V41jU
zF)uQRShKzLsr$~TzgJMJI6~s%vO-cbDWgS25wseD-JLB&m2NqWH&jXe$0n7j(u0Sd
z$~M)>%QTvG6H!~3Pl=Y0^U#1a9-Bq7Cdgk3mSW{_PZZ4Llay;kzrL1+IPLOjk5^X>
z9u~Q=ddezF52ZMWl}v#%@Tr^46oZW><;*ONjYkhYoSJY+Y=-7iJTE{{P!O;aKv`tY
zW*NMaT1_QOC&d;UI{CA$i;9Dd(W;`A2iCilhn&&M`r@P8cL94{WZGY=NXYnH_ODO3
z4eOrI9q-Q_;02L<sZ=FZRa0L7O_chfvH5QX16|B1Y{oAWs?_F(RUg+Cq0*rM>4@u!
z(^LA`@mh9=?v|3G`jSua67S`cVUcBJsmx}2Q-;;H$y|GFA4hQ_4{v5=55p73<^#{m
zC+AyA?3DNNE^hKQlM^SV4Mn9T>MX9wSvRqz;IUb0<GZy#B*bfn51Oo`$*wLgFkx<*
zdFV0W7{=eC=yEf%XnQF?m&?!v6tK75i#d3uuEfFXRWAb!UT;&%!3{y#X;cO`LcC&d
zxB_0rn#mB$wji(x_(ly}R|Kt}vq;qxPOv@xRu(Dnvq4_>f(f1=hN*nN9)Bu++sS)6
zBb^-lV8Wx36D?{eopIX}aQ)or;k5bEepr*vkUxM<F($YEMD!#FUSr3=!07Gm1uJ*(
z0lr!HdT-0i+bwfdD5{>A7_V8_8Oc=$H&3r8VPz*G-BMAq60n^MGCdl|Ccs1O6U7^5
ziWeC6S;;;KCIZdU1AeY2D-nrBa3qk%=jNWRn6r==qp9<e6t)(^2`Ek;+S)|b1dom{
z?Gs?((p%B3w3AWN@EVRr6rV`J))%xB;M$iKO3V9$RA;jY{m;h5%MhsKgi0#&O_l>g
zm5Mu<U;$PAcP4WY)!Q-iCp1zKel!v(Uy8(()Ns(z0Xh<9GRyU^C6R`8mLp5Gyz`QD
zq9nHn)Oy6y;*SiRNE*{YgQi=#=xCt}!4qjKU(ME>QX(QEJf81(uLek>qoV;Iz}`Wy
zu-n_)G9WI8qnV;e{<nn-_vYNpW!HFPA>Rs`9`d7O2rTYlCfJs(VSK=l8TT;WiN*=d
z`yXBN=eR;=?PG@X!s*o`Tz0J5TAJkJ>LK>M3@FzULD6Y)_eHt-PLe&0^)jh!cc{^Z
zy?H`=jQ)--H{jigCQP`|jtFRvJMo$9+e5v-b0FdQg!oUZnn>5)1`D75J>R)1xOI(*
zzY>lx)_0U9g%=b)jyBvnZwp2)Uc$Hk;OSAnPL)d5xh}beuvk4PGq=g<o7KFYw#3Eu
zH3j?1=AT^Y*cgLHQx4HR{FiJ3W^I+C!#ZshoX4}v*SnE$P6=f<p}R3G<8@b6TRYjV
z7UOnXPPh8hWXwhy*%|~x8t~{gE1_(R&wnWAP~W>(^$;(ELTW$1_UWGi7}0in_322L
zkimF;>XUax#knsG;?&d>xIo#hRtnSQ){k)A#g0k!(7t_|Cl!wPDJ`pc$CgK(t5v13
zl@j7?IkZ4jHJ|~>x;tyR{L<svghyRGEDrxEbOQqyl~Ai;RYWvqAlTQp+cV|>vWSI+
z1+vq}x2p$*jbORy)q5Yds^YnhvWl2a?h`)YdFhGIo@Kvp$lggUpbD=1GA6s5`z91~
zuX%@k&rE=cMY5E7wULjRqb~FJa#TdH0(|G7AycC(XAR&}jXb0ZcH@!GZ`(!Wr14$`
z@Zf<<T5fK;Wye-V>7@DI)Po`5U0`nJz|4BiJ-V^6p&!YMiH>f6y(g8v@34Ni;nJR+
z-8DHmxw@)(pTMQwk~DPGTOT3ICm-U$0}vU_u+6QutcsLa+a06eA6@1-r%gVw45uJG
z7W=`<PGGS`-@DWVN95s<o<$aT7^$%xs(;#6M*LPZ%}<4MGi9tPi%I@580Pft4Qex)
zoh>!tdac>z(+x!1<~1ytN6|JjjPzZ7-&XJ4+x|lp9REU3BCj=leW2IIj>kShbH1KQ
zyWg$&;nCpQ+=aFQ{iF6S-Dk2WH~^9R&Rm+y_EAIl_t>_wQEbo(C6aktTJc`H9@GfV
z5V=8f+w{1XDU>tZ1nYkE)AvX~aE87%|8XxH#tHW5pp86O%RGfvvhJC3zSq_O=!6G7
zo6a0gX)pPcwT^EQ94b&KT<s1n+pfy)qEtXh1UhaSn1~5bDe(~9lpxh>_*!Mn@1?rA
zDm}#kH%Vg@Oe`Fv$LwMoAt6HzW$yq12fN6YlIc6&kk@r*t{T7&r%8hUhrtqYV`!1W
zU5X(8=cbSmtWlnff)AnI2ORTP2k4B50F1l<Pl%Lww)?5LS`f@ELX~YT0-k<ZwSZjd
zbb{0n3ZJc9fxRu}-LIPVYsqA$-B=ku*`T@%16({jg(3x7TH21M*@^^u?YEZoSLyqN
zk%dQDZKoEzsD6f7c-@E#V5I6nQk2Ur??=3*sg~n{>)FB9GFrwfX9=v0uU`nXZy8dw
z@S7I?473(v1i$BgZ*!3=sAeVUZ&A8in+Nr#ReJ46hc<vn0abN|^9%k?5PIekfHg-H
zeR=S}aQw^CZCSNGg*8vs)F`ZEo$Z8X6c@Bow0TQR?}vx^v6lmYEWD}et9$=5wCd+J
zlV+frAEp<GZ*6FSwg-x3aLys?=B*VeZL3C}NG<~@an%))TY9o5MB|oZmuXIQWYEwX
zM9B$Jo^2#6AiwED#!b(!taM7n8M?rh_gNhjfvtDgKD9>x9UM|E7g^?|*)mR{uwQ6G
zMJRm8;k}D4I+S<Y`x2Orc6c})6BT}Rkxv_B-0H!?(y8d5KXsw_S+*pktF1^HjSwT>
zIuTj|5G}WsFVES7pIcQ`m6_Q&H5H?qv^$*0&CQJn4e28g6&u@KT`KZ*QUa{>aIbwm
z82Me44d0`?u|gUeCGenWOUp`|#rhVK@bPIU#{Z<itaG~Cub$8pb#$yREj8Da%r7V!
zU6<IEsbYRv7`ji6{^VIJ)oLp^LNli}n~`B7h`YYNZft2ey*>@A5+>Csn(>z29%MIV
zro)%tQ82zFtr;{@CeEz80?}FBv95p=IeTzV>vVAvclI>#N)y}ozDk)sU%GJ3W9{te
z=<XaS0%uqMGwPgjRjz%vTU}~n=a8Iwo<HM^0A15wha3Iz`*VE@?Dy1Y5_lx3)nvM8
z6Qy*2>GU)W%*xB0#-98K2gO~%Wgca(O5*Zgm}z*2q&P#2g<p+fcOIuo+j8QhIC8|A
zp+ejbwLsQ{NpBoVx~7T(m3yS^WaG1gTWLS>x_#QbKd0DQ)hLxj<bgyF-gY)1e-=mN
zL6{WNfi|%Pke=x#mX@9pJ6?9T!6VpN%em1=lCGhlp{{OpY-}tD#Oro<@;wyuFi&Qn
z)S9v)`r?WvD8Wv+WkfbTBDKQ`>7Ma^m5+XYuy<FPyJD`_eTpT&=nh@hCix@p70EkG
z%-bZVbgYC~7x8_0E6r=yidFQ;Am#9z+Q)MBL>36hT2th7iBR<k`ox5RRt@sV?~Tta
z&s%!fPrELpwEs+>^&C6AynTa%M2YcPKCb;azD1Lj#;{*Xs-XlfYo^;lul-gxK{gIU
z86FG<pYAz7<|N~SfjJ!Xws{pq;AZ&prv_^qjQyP<5$5dJ&q(qqKQoCbzSbA&R44;;
ztqiv6dv-*kImngwaH3xX)37<wvIJA_bY*glT!@HR>RH%Na~@`<78KAn`oFTN$brz&
zJCPe67IJrTPm8voV79`KZ5jt8CxzJZ%Os>z|6n$j%lLx&a+XkCbRre>R9F#Q<WuDf
zolQomC`~<90zuN*_1>1aP;oJhjcFF9wUZis3MFZJ{cC&Sgt;70zn9t07OF|O6=b8_
zh$!?(SWjB6PblKW<HZ%VwL2`A*#dQOaB=B18aMX#64KHv%*`wFJ~4UO2<F_+Ut#*(
zN>KC8+At#GrBj+d^o`q4M4xG<T+B@@$_C+(U5gK1HGLQi%U#DKi{R2Y*PbHQ+6oCV
z<E345b5t71QaZn?mw;q@TTC|EIY9t5Jw%Os2in;jlrm6YzTdiD8euUwx=d@XKg)Yy
zTR8Hb=R1YUZl((N%4)MbDBC~KXTXTwR@QwMz9tPC4S6gb>}WlWIo&D6(ilzZWYC#u
z<VQ@V9<)YB<m!=F`7?u!z@mEtYxes*Vect^K7_1FzA*Ny74VdA+LugRO;ZyD_8!-5
zeHv|-NTiETOq`#ehe~2KPsqr~XlQ77iqU#1FQ;qEsY@v;)_WkTw`zosvH?Q2s*os$
zlYMFL(OoS@`oXL$yjX7_<tp}jPk)^$^S56T{$&=G2WQC3Rhq}|DS)X`43}U$r21C<
z`EP4mq!9lBcnw@-WvW;<7g9r{XWm`PSs_M|@~&(s-0D*VJ2@$ga40GcfJ$d}oG^oV
zu1U8Z1U7r?C2VG#AL@lZF>Em>bWNWfwnUk&KoR60u0aCxVK2|_&5;~84O27weXuXi
z`1m*qBI0t3leMlcvG-z)G5_@lv#hM_biNdGv$a-VPC!s7;O!_`qNBC3k@P4;bC|1&
zOHk|mVp4w<h#e^n>SkY(5S_l)E~7QF)S;~{Z^zW?vVXH}f2;ls{2hcCIKu#{hznw^
zRPn~#_=NIXz)o>UzxwwwQo!+1Me5b2;J7=04uXkb&36;!0GriEx3kdZ*+-86fQd-7
zi$*trWimtuc0kyXmh$G#^Q>!WXt<v#l24@9{=i_p)(Y0b%S%gYDk@(hpz~LXxJA^8
zvS}@i>q-$P;TL~<>US_|#i*R_B*)ZiWpB&>-2M4lsi2TTva=Ld8r#L(L(j%R>bwB8
z6eUN&52D^$GLS}`Bk%8j<PEmAw;R0V?h#wwdKI}rU4;QV{DYn5Yiq&tZL)qF@Ki%6
z3#_BmxRtRLeGQZqvCU&K*qMiPzsdyq6P{Z%ea#rTPE=VgD>1T27YkDN;^C?7BL%Ph
zd#zGxc2LpNTLXa%JUlBSUx10Llz;#{z(W=4>Xv5tNpNKTF&#Q(94b69TT~ICm=h@8
z7!tPfocW8RR!x)#b>|WlYV9*Gkt3ub&y!0q%xC(v#)kidI|EjV7;W!Y|3Sh|&>Iz(
zU|7H<0mJ-{d*Oh8jPDHn5|z<%sTNG-QrWE|)Vsi5SK#8q!^baT`ite<D(Qd{Mc5J$
z3??VtCOyJEL?2Z8j38muR8<$3m%#;aa}#!Lx9I5T$ZR||<N1{Q7Zsk7H8?sJr<$9e
zm1BTCZ%kB=iSP2_hSIU`2<}Qh&wlv3!+52d8z%FwlTby#_H*GGfwYQGcug7Zquk$Y
z{oU$JMCK1J&0^@kfSs?WyW8(S)Cu-dL%{d>4`zbV<=@xAZLJAr+>@Unazq>-9W~o*
z_dQr;u$ac=<dAq!{NtSD6N{8vYv6ri;0kh0U1#Y4#{qAA=)Wo{|M$A8i3Q;mH!y!Y
zedinbN8cVjG^NYaETmRq4~IHCJHcl0#zrQWJG<?vwO42Hp^yB7rw{D97{<>tbQ^7k
zBZ3S^00aN0Ft>_}v#4fW?!}Zw*tXWZzXy1M4t#LAV==|&YP(gMiB&%%u*Taw98GOw
zbxq?Eh=j&+f9J{F{^JB@PODDq;db9P5Fos%VU!Vo0Cpw~4yHUV(X7ww(B-HmIH>}(
zOuztdi-UwK-y<W6Tw&9X2A_KHGn<+ola13=n{0QZNq!&`@HE=)4qaSan9oawyF+bY
z9GpY1GwW>%)_k1gL}v!HBf4W{GPiBI+3VN0b4l&f)f_%^-_{){uV*U??<c%TUm$?u
zPW!rC^S($!w0}OBPaJfDfGQxo3S^pc=bD{muZ9R?F!WO1uSVb_n{)Wfc;*Z99;7$&
zrE!^!h`>&FdU|_&P*4DI35maihKiPw@{ftRLg2SROEa!|kLTjr+{)AHwA1R7Q!!!P
zCdl8zY(D0Y0O|Bbi&zbxo=T~JB6Tpkf%I-=;HINvw6J#6z}v~oL6~`vmiqsPHG~33
z3BGKkY$60EF?HDSVyK@(pEPL3ufb3kA0Ho#L%~~Hz&GH>{B)wl#}xmMs?MU*dtroJ
z=7zMq37aiuopyjuJMdM_l_qD(oDNh0W*e2WpM3tu7a&Zm!}f5UHAT0w&cRMpO0ro}
zsXUp#H8D%|gb~!vMb&mW^|*Ag%Ia$7e_kFPKb$?4%4V$K#8zKOqF!v6%3lOOZX!NV
zXj)Xtsv$QOcq^XOv@+X7eJ$tgI$b^@ad0@LNJ5q)tEBqQz>Xn&ed|<r{<QP=N4E@x
z`-VZOWG1o}B!M~YibJ)PLYr_kDylXz`VKOlw!t``0npcA`0G6IPHSo^s*upoSz|u%
zx#RuK4a`y1uL?t4qtx(mu3Ru%Xqj#H4`=oU{=yH-WU-<G(07Z+u*|FMuK>mG1;f39
zV_;JQ7S_KCt-l(Od-`(}>E~~bgm~Pjv|HV!LdaS8DW`mlpD`p6hGL|YMcnt0aIZx0
z0w-0x(t64{Oz?VoRewEbD)?A?89sJ1990&ne}h?_E8+S4$=#5cPgWbHaX~eKa{)v9
z4Dd^7S#?imU(fgv1zCN$K&1CsEy(2u=uBz7u_-gpa8M&rv7PaKh9_yMmmufxbGrql
z`Ucu{$oU+ZY`YK6W9OWCto|qWVN7QWI+NLtZ3T~GyX{~WKuesy+0T7rJBf50FI1zJ
zpzSrGi1!|H{%5hq34_IKmJTfCHpJSt<UrSoDsXSvwe>Qy|KtIBorGYk>~S<-vgvX5
z5m0Y+Ggs!7)5mI7<OLi+m6Z5-!D^TZi}>^l(uR=xIUxby?%{z&qY{;nz{bJRXtOPP
zs{<@)@%;S{1L&4Zc>1w`7yx1hB7%Q(`Niyg6mW2GvZOQ6alc_g2>ibR!2=^4G_bUg
zj+*o*jjytWfV=amV`n4`;J0crG-DMQk4BoE%q%YbKb*Y<P#s;jExOU5!9Br)yE_De
zYjAf9?yd>$?(XjH!Gi{OcMtCD*ZKbQy?gGd_o{B)s$E-px2&~#$sBWxIeS1^m9fb=
z;wn|~bO(ai;w^zJ(K_5)`-;I;?D3mV>2>EP0N<kR8Sx*L><|8seJNDu#epcOo?yka
zOnDn-@8X(YU%}tb=6TJ}`}rrSGMwUB%jnY36YSU_HvHd!w!38^D8^Y-BZG+;yW#m6
zCBSTbk*~mI>H5yl^5LD_y6gFtHPCLn>eUHVS*O;>V9~ocu*x}$fmA36)LSVoK`_@s
zwmg^z;BX4$FF^hZnHTbv*=(aPX9Tsd2B6s7pVS)Nl8|c3%3ap4@6v82(oXn$?po-u
z>E5x?LJg8Ccqao`dG7|7%1Dah^Qsn$(Sf-4+L?n8VV^Q(0C#U6ziF<K@c!IAlijY=
zMOF5M8s&9U6Lb!5kP8IE_pM76l>DQ)*zk`Lli@FCbPyqx^o{KT>y35yUFUTB0k8Si
zWw=R@LbRx0$#4&mA~}<C6%i|I_@0&X+@|*2N6lcQU2C%?i}?hx!c@-lkR}7O(($R^
zLV%Ug|1rZj+GxT$3#9h7o+_vGk5GJOayG4{-5Rw3FAS-g9~31)y)v&HgAo9MwP6=!
zV`RR!)c5n=40h=2jmfX8Ecx#K3EZYXM}PMj(UP{@CXSiIR9qbK#<9lqr>iiNJ6(Oj
z+nW!dgPN$)%};)Qey*sretLd}81EzeADEBw45YsVz`i0(5a_>w!=uuvjhXuxc}?W8
zp_}^~jg=+f9pWGOr|m5r*<a#MNPc*Vc?oJ!;;Yv9bKw3a=jEn~j-S@XszVye)Uk_)
zPBOMc`njvvN%}DfWr*rGKULddj|<gR_?@*YO4z(uKDF5@3;g!{U_-7(un;jS9P}|p
zFyLo}^#7&dBy8#}?H(DBY{uP?@k8Mw-riBm<H@`o5hbg;d#fA+L-(?KBg1|?b7#e|
zfT*%Ig-G<vuwZ0yGIn#0p02j`$zGZLgt45Q#@&LU-CA1#JZerQ3<x*3q7Iw?s$=GM
zU;6U!L-DUq>{~IOYPv~2xl8^I*`|8hbRyk+)dhS1jAl=#sQjA@q*sTd)@AVnuC+L}
zok4a}YMluD!=HfGJLLHzpqA<Tks8}W2eIGxFLdf>8XvR{U1@F!b96At!<+gQYJ{26
zLeI?om3-n?VyhUrFKTfVk~c5AjgF>^PXjzKEPr030^wz6@A$9~0>i@*C$EnscJ2el
z^t68;zBYD<>c37)$vbP0K?a*i;dfm+evm3?N6Uw|Mb7-_Tw=gdoj{ju88asFG;Xk6
z(s%pz>ErgNs*(~8W%9{ix1EA>$v;gOu5FG}baGj7h~iq|Y#82WV!;k<ck42)pI+6+
zw8p)N)#iwF^naAeOjYc-Kdnd+sa)T)PKLI6sb^)k2nfsXGXGP3_(x9wG2%G)?|7Ad
zpN@5{5%251@@eIl24hPabKzfWI#NqYJm)JEzdi=;Q!L(gmXey<!RDquZgrN7UYk>C
zM@L6j7hz9@M*YjnOGjttT=LDdtFv=!dpkku5e=JJPh>FG;~w`jdLhJg1$iGEC=G=7
zj<P5GW4h3-F~0dWv1#sE7+21B5s;-eFqnbRSRe%tjJ~ZcBPIeb505g<9AJFOj?0X=
zHT<zd>(TS>1bV_My7NGlNv8VF;SCBA|2%T?<>4&1SAM54n>ToF*>E0qUijqLa_f`K
z0pme5Zql3W(IyyL!d+%C2LJdV{C}Yd(5nzL3Md>V<_Zocg=*k8nR{sPs6?t}qw}p7
z+!QO3pR`{@a5KoTC*lYhN-WZHR?)-RX7-<<4&9=3tl?~Hdr_)X%%InWq`%(bKAOzf
z+}Nn%yX_uvp5VUyDRfQ_fUST$ad#QDACA1eY(zc1q9yg~dkl9L@)tL=QLIPftnU70
z8y$9|Ynh)CuE*1xU^k^b!JHJ%^JrWLpf@gLPT!VaU0ng5<i5VXaW7H>uXAORcWN$f
zuy^2kSFpY8+WlLPo_`84`an>gLTrP&0#S{FZJX-vq=!E~P-i{N_NrFTSk2h0otwAV
zPdd4sSgva3oV9XGMNZLSuJlfoT(k{RgndC;h{rOcI)Imp!yH*31Ce4bBW2eMECENt
z4KJ8Lbo~5yXoQ%3{pc)^9lz@>aIh-@XU}aI2(9i`-i`X~$3Z)$D)I0kabpirw3!zi
zFTI6H5|1Yr`FpXKS{ROGmtu<Xd3cxL1bIKJNIqNcha?<HKrgieCjtt}#l^*66FbEc
zSR#Xd>ZkB~av)QX1jI<H<K&PK$J;D7d;{RZ>Cq8$s*F)N2|4+0*YkNghc*5`dxeVM
z%b@{R2w25zTNDRAQ5}>H4T(}e986{xe<lt<Wr5-U(*u=HFO2j2_g`Tf1f5ed;1e#_
zE(~}lF~0iUsbnmrk6YB;4Su>kF`^ale!2mG?92~z-~btfHrFs2f%dial@-tUNw#jE
z*QX3_$CsCIpMcfC57~d#!Ma@k)TOu;NNyrT-16u_hb`^q_K>iyB8F@LInI?@gOTXx
z2TC%*LKslf^LD;Ho_oIN_FbwosW+RnF*jFlcRAx~vhMnx<4IxG%$-i??n_a7(EN$E
zg5r<Jx79=CESWBY>dU1wmuMWLa<gfb-NfHc@u5HKtb~O8#PT1PCVlQkXsciDeZluX
zf4pn9-N?$$1|r%fIoa4EECCK?G`?}CZo`|uw?7t#vP&R6k;pq$^>KW6f-6udAmV`u
z8SVktTM#&eS$CAR351k_&14o_z-ne-1(8pfRuVMDTdbB>&65i=18KfC(gYG?qSv2A
zkmZb!^2_D^v=ceB<Lv4Rz-f(2RolgyEkIy^jEtO^m<TYD)@o|W(FDk6HTVYSKjzqK
z{`@{@LYm@?F$``bn)m5ByBV}_kas_Nv};!MxlVs>@h}W(L}5a)UK8iv7f_F^3NSs0
zx<NS&q@8lzvw8j2#fy@hJ9EGxweTY2-`Z{K-tKJevKxbUkfD8z)f`scqT<$fhP#u7
zgHR0D%6=f=!V5~2Dg<JCrS^bv%Cw4~*xWHI+cp^1o2X(!%ZWS39`(grT4Uf?)*TPn
zfOs>aD4ti<RpVqLsVk;3aLnf|9hm)Pf(I|Nj)%6GxUr0fHh7AI2OUw7vr!ont3Xu+
zlNt$o*JSp%0X9v81w!Cq^M`HstIKE-J@}~_%mXwE0IdL)EeB%V)x*5|aJ5A%y-BOt
z{l2y9dYMp3XgNww9S>B)@{O0rQwAb6G1IJztJ~$iurX0D`_Z%b+OnqE_4<6GF;TN}
z*`4(A$>sn*`r;*RY(yH^G5fAvZqn!e{%p~cqEfNh=mIb0>2-D{f6B(EoYlJ7X6Jk&
zE9xgDl;s@G{CQV{dvno+;-mzP>y6pjx%6^Wxa*evHoy1&8!hiTPrPcW=PP~WQqDa)
zjHM+Ks0{42<UPnux!^rMdCOB@cP(LLrdc?#(4oL3I!qs42nh+fys{EaBxuvTa^~`U
zxibU?5???=Lr2i$DQYN`N+w-Y&l}s)Rxch%(3LUag>C4l=vfa}uPbkN{HZmttT$g-
zSGk>Qdr8Yf$p72Kw4<)n#)U_>b5a@_qV9=gwQ~WQpItn>8@;qh{7#?v4JFBC8SrfX
z0^ct0XP-Ymh>VSmLHZg=CQBI^8TsPTg!~>i(Y`PF_pe7R19LfvwFI0D^F?$cR&|re
z@aE}Q4lm^wpoYu~%XBOjPV!9=SVo;zN>(#_h2!3_{qm^q=~(>y(nkAL+8uW(YewuL
ztl+_D&*g0*_2<>?WT!l_>a6Zrx64im$qC2sjdVfZ;O)3<50>;wZ(3~I)s_~@PaJ3Y
z7uxIz_@<@;%`NnA{^McmvC3T<Q#06Lp?$}2X-`qttz4kN8NHp3I^XRdSZRCxf%qjI
zxz<&re|?Pt=|=6F`yAmYSM{8h{ajm{PSj<;W2krS;F<gGQw;To(|6Dy^$s_CFRzy>
zop$x4@ySWo48`cXvW=(H0xmT4x`J}rOj;2bb`!;1><9`CQ;n{<)Nx|DI9d*JW0S%W
zV;YUpzYTq&)m}ClM^4&rBJDWcrhPAoWlAXtD^O@cnx@Wzrk?bA;QMw^P*4CUuhc75
z@AW1$E9dX-?tm##TwJ^z=O_)Wu1Tccc<^*g^!|h14ajfo-39lefqI?!d2IC)3r7D$
zVsT+E;*XeCD)T22v!C})^Q=oGj*kig-97D;>yIe9O@xzKtxRxnCfg`0-Iv39uZ?>T
zV(kIGpO~kzn(m)WH*Pz+4E&K6{4Qn)8|1-@^rjwMP6nt+bg8Lsy*zOv8#5X!K0He3
z0sX-u_n9px@3Ah9JTLM@TWNs3(1|jspF2&0qp4#qA&BYCC9K~l7p@oG*qjVvx+RP4
z!eX=rcRqMn2|h+4VnBvq!qY=hPnFf_>>)&cHMAd9?J!gOS%qz{`-854r<fdST39bM
z!#NEUDgh^iPQliyLJN;E%@+snGRc46aXYUSwNS-dsGiigWCgeoz<0LbCc}X+z1L&4
zbJ06f!IUK@XPZhN>l{;~V=F$?&bw?=+f~mk=S38s*ViZ$6rMVIBm~gr+s9>;u{{)@
zZja5e3khwO@STnloMHF!A^XdMQI0-&e#A*YCw9y`0XHU6-9U!~4<d#~I3&{8d-Wry
z0`>I9v|lP*W_7LmPwC>K|2}c0;kLYHZOs}Ilkfxor^@beXN1D;FWkZrUuiKVar3e5
zd~|JScu;HiVzlw8zsn^yO~<BS<tC{~u**0!3MZ@8)D;!}RwFgb6oSiNK<FcnSm%$8
z`DK4J{V7lw4HXp?7q<ndXiW{1K=$OpHQ-AF61vGyTn}fno;){Nni4h#ogXq0@%`Dm
z%rjr2^NF?#Qq7-%g?)Z?+5I_2ECFXp^pH!&EzOcX4yawcUpE}Bkyl^5WMUNH7WL|M
zua%^iNq+2#Us~n|eCBZ6IcL;4GQDoh$<ePr!tWu_*qeAukzF{Sh*zyXLS##?f(hgr
zWU^~$d`!{iMb+nc#@~vSdrA<!my2B?&ZyJOq`gxuceaw3QkqlgTP!JKhzxP{2|P4Z
zOO!fhQHWlq5kk`W=vRllH#mr1T4*nA+z2~yLYx8Icri+o#`&b4#l^O2avtjNa<ZwY
zAh=Wz;41>A`8y);!w|4=@{y7n0%i&yVKv|yEh;j7dwGl&cq$Qpi}Yl?E8#U!^}emh
z!mtxSU|@B*+b>#g5H%D;9uN&8RMR_b|J`^;zb3(h?HzsSmX1yF`qSvcBT<{)2ahsV
z<fp)odeq?K3yWA)x~eR9cls`5o<gVxCN5h(HNp#jjcUHa$Z({Ol6zBItkFaZy%mBE
zWd{s=avjANxzA>_^5zEfwDK9ghd!4j7CTw1LjFxVd@@gD<Exy{(O%QvoWo+65s;j+
z2rk|D1bidJD_BUIEt~^kYXf-^KTrn-ww_##43Pe4;L@{*t<+Le%O4XypK!)fiMxV=
z{p$3T#6QuS5vuKsjfs<h9YXGmygYm}ZG8gEBBdj`t3@+!y{IyiB03{QvEOM_t8T@y
zG7ydv9v%*OzZrGfZh$OY6X~4Q4Gm6%NY&Cb)F=#JwKW$DF1FrPg1=UfSzEtUP|A5<
zOZJ}n%bXWxRO`h}PQGlWE0l{ikq*)lh`)`O#*IPYV90w@YT$>uM2a)&`m$J@z3W7r
z3u5&$n25iBEHw*$>H0)uesE<=7b{-a+p;^kLAb$(<4+>K|E24#INTa;{c^^gP?U>y
zgD%<l?KZvt?gCxy3(0Sn=8u%?Giqu0jd$KUdCPXDV&=DL5`s#buiqUVd^6C=EIY`z
ze1Qu`_Ap!^c*{JU1!RTEQRo2)HvuHnG4rwel-F@TLbI~V?UK~5q@*MuARrJChlj&`
z7qEBlTN>xLwt|TSoR1U2KEt6NxZuQx`GX`-g;C6L$q^wo>7ahV82*gOSP$(wo`vLr
zMJLhD7LwZ8JUc-8Js~9Jsu&BOt6EM#K%k_gR9;pF1lfSbvIW7Rlv%@LV@N0{2OT!+
zrlQeUj*k*f8LcU|L(%ufJ|Cy+KW`7)_4B!%)IOhZ&_1o&blF>PkJ)zFy|pmme*R88
zzSp4S@7?Y8+i?k=%V<Cw$*Iq^U5fU*-zTpdkXc2{Wu{i5YQPiKxlXGmc+GL0pRWj|
z2T#ayKv;nM4=2nzBNycY(uZcq9&~{O)q+cY+8cI8OgS_M#9rzl`F6nB_zW!5KDTpf
zAZ$AI8esasV>SKb#&=;0xv{0ZUaI72W1T&eFDGn6Up|Kq%rU5_fS40G$l%naU5FSC
z0l^`&97*ek)zA`$f!%G}GmF{U2(QSr!12kWCXq#B7TSc{H<SMT=R=-fnLAaP+6cwN
zv&hA(J7r|zQ8jewNlE($ygh1MdtCxf<q_hU0W$336)_-0+glt%qTi;0O9=4bc{MqT
z1s&d2%zq{hd=fnX#{d|j>M+^c_$u-d))D0#g@zn}4^$bXuCah=_xASoSE1Y*1ia%S
z1^vYh`sl)NsR7Oq_>e3|fC7&L$TOFfMHv5!tqEUPSQwzA1s3wN;Q@pb`sM!?yR=d}
z)ke!;MFlEqGIUmQzwHrS_=1D~DV6amR4Jh7yuH6qA2-F1T+vZb_<g!m|Kt02suI$G
zRZ+_L23#SE%mG8@^l<=J738+CYIl0DQ&C9}qyAR-&nZZ2=*kyPfL)LWGW+$J0s;f4
zAhAex89w6xAkGLksP~E2R_+@r90_o9Sw1g9uwlBcH%uP`O$DGmikouRMJvEe%bYTA
z(5(C$W01iO(1G<!R{s9}Y<^0P{~YRy;&G0dO0$(f1Sq7qydM6HGIqbzXTQ?%@;*Nv
zWLKAz90K}NIJlaXGrH6`FZq`DGKeYILYyinl4L2^ASRl3=m|SB6GDv<9$p0a-Kt#W
z_!m#MlKb|Vzu|4p=f_Ta415vq&8N-&mT4>D$C^#EI-T!BACb@NiJmWzpKYO94+jn!
zD5s9M_v`+6x(ZEV^tRek`8b_tV*7OYIGJn*p6RXIoR?*5+rjZ4w;(04+p08Y0tCf!
z1VviQI#pIP%c4z)QW`Ct7)^L$#{Bu%xaJOXK75Bcy;wDtD&$B#+6<M}JIjn?A{Rc&
z(H6N4HzL8RzBlamN6;v60QBmm_SO3}6iws{e!U0o51>-Gd;k;+_p6RuTU)@YD3*U2
z$+`af<aWKVq0)C$o_3zicTB^~NAnU6!*($0g?>l*x-zl*$vgUev?Z5{LXCXlv&~<F
z*;iI%a6PY*#t+XyZma>RfJt9jU)gU(=WI-ai6;6JPSiFi=P#CPl}~slf1<@FH-eYR
za^d$`HxrS#onqxtcBiv#zqVnp1OR}J^X0Z>KNrOIHoKT;{Oso^OR&;xhEx;F6NaMN
zqy1`4?AQ(M`a6JC$RDk7yU|j2XNMV$rYd8JeW~j}lrt|-^5Thq)M54_jgcsLWH{|k
zz`^VN_k)7x59;R{j@9w?wipgCZXfS-m5#uF{@e?wtjX#b1H+H{qZ~8R^+NX>R?qFp
zf<}_}&6GHhWba%1noa$Z8=tPNt*x|lxNGT;V8L@BBj@FiFF~7jfx&ooJ>7GlXLv^F
zxmGoy+4z|a^^nH=Sel?2@K41Oe}K{WkcKL6Ol9YhHj3x1uloE8%w~Q_6g!cb#@g?Z
z>bm_Mk>}0WLzUyQeCZ*L`a!a?57UMIQMGEpyDvv8g13iEt{P^X0w1UOhs+}=GAx?E
zB!>|wiVj9FosNf&E-U47=IK9DF!6x&Z(v3_k0Plg)(R?DG+P|h3@k#Ms*E?u+N!K>
zi+X1jb&N{Og(tQn<TNr9m0~niG86mE2|DEybgKVfblJ**g*6LhK3oc;&^~>#s=1+9
zZ=>_sLS?+o`8RJjozrb#A+7WkOBs#o!I2it>a%J}+B;l`!^yI%B%Gs3o-kZQCBz%C
z-2AsN(!ihJJ0dhQ=RrN5Lu>eq<?5Z(jQM3&CjPn_$ICELwO9E5TUuMo>=&01`g~ey
zO)S-Rdki`|n-gsZ6*?LP3%vWHf?SLq=M-E?Os&WFRHGW*mR(%$6Jy!O-FNNYf3KFj
zCsfy~=TI+>?vfq5-0@!Ylqm%F^|f=KALRo^_piv3E`V)n)EwWrjEjr&d0yFgn-P4S
zi6r0z(&PDFr*8l&LHhXo)YO*u<M9jzP8edg4UhXz=gy0={Y~2iD;nK;Eg)8*HEl=6
zX^IGZc9BI*qkes7yMTEFK42F&G%$_5)7Q96TN_9%T>eowkt2LBc){0M%XEF_nze2|
z{}ySow2}C776t=jx$f%I<Bnwj1mte~sqY<Y20mC-!L8+2JKeO@V_qwr1S06IQdq{=
zM{iB_ZsRN6I`x+p&(B?L{dE=RJKGEM3D_0x&#seJ(?sA*vddTYPlO-$=}r#Cen#J8
z325}EIn#~SnR;)<i$0a-x7$nUY9}SDZ78M~C}YD#N~OXXkmmA`O0F#<Y+6~?YsO(x
zpf{x{<R*^Zt09KpW2>_9jsW`;IJkz<T7;F+RUvSPt0i414ol6Plqc5Jg<a8HU{Nfb
zsA5>aECGPIN_L4I3siS<Z<nQYv8*{oOfOwsZ3Bec+ivVhtkyJYG+1AhJz41Z$bJo+
z>a;zJ!?X@Z7qTo@3=El9{RFZOuhRjF;4sg)p?YZkl`a$-)}_PAZs=Y2HH}QrwyWBl
z8o^aLXChmR%TLdW4srcORW8?YPcM*if|_OB=<aiQd0XKoz9beZHidF%p_xi0XrfG0
z1#P;9iNp+Jo$KVkI!gyiA{xj4)>-z;X4Ez)_8%?<PWg+b!CPD2r}lCiYh6r2!_YNL
zRtFQAtdBV}M}Q2m%lKEE9{6b?3NwG|(5)8uB~IwR8;GO(hw5ssnCRv3fH6&`DEsAQ
zk1<`qj=byTG&*Z-=Ek7;XpcV_pp~<~B%AqOZHLS15V@qkz5Za#mU6HGJVV`7f-k^M
z11Q~3zl01Q8GWvl2ewe!WhYhHtY07HWhiFge@N0K5}tG5t%iRfq*J^M&*oEE|9j%n
zt3FR%FPECDus$Lel%pWeylO>89?gxJo9%k=kXkZuEI3wbRNl#Z(fa8grQ73<lCeF^
z(<!CCqMU$Q@Npot?*b?@<NNOPt64@b+0|CZ11k=KArGR_^VhU-pZhqz`(ebZQ(HlI
zpy$$iMqANNm}s~hB)u%$5gKTy(j@wL&!y_oB=U?<NEU9S0ge!PWF53?hAh&*|BTh0
zE^MSJ!G^UT+xyZdN_D@@JNnBWtMuQJiqdpC9bw!ZQ|jsQ#AUJ7sAPeot&dI@JT<Nt
z2)$RD!1b8}t#qSZH3Iy;E3r89#r1UU^<1tiZ<Ai^yPZ1>#bb1%KI3VE?H;!nV9}Ro
zziQGC?St$Bk~WEsQ3YhRZU=9jT2~rLYtPGw1HAXo7QF;!uj?kAC-;se5jEfRb_VTZ
z>|}WkdY&>G{drz*tRbU_z_wvqC@59;rS~^$$cLZdjjsTIXZzYjYv|C<n&(BQp6_d;
zaP9*zX#j#L#^llKt1AZWmcQm92v8dlnxwzyq}Suw@VWI(V#u^_IkG!PQG#I0Jb#=a
zKpD?Ah?acailyNSv!iI^1JC<XATab?&7mY~vgi`6KG~imPh=bDwRy=MS7(F<%j-V$
z`M%k`A$iKoi-0v9w**h`L}x(yM@YP<Hlj%rl8s#9UT#;t*>68mN8jXSlJ>x_8#7B)
zBZfbrWB%0w)cbJx1|8_PpnE5dOgwFU$Ga27LwVgOqwQ*g-W)k4Vz7N0*iNKPX4IK)
zx=F4wJr&^{)0m%&#3(J5l?}$GA2)xxnb{ki@siD`b|Q%(`y55C*v(L<nyIZ^)1j#m
zM<UNq?$e4YV_DwD<(f`b{AG9S!Vsc207Q)SzI3J?5RZiffXEGmXY7Kr$z`~%jOL&d
zD$22ihe2!D2fth|vvgqEHT&I>>tc>G;*cZ|bsp<?f5Eg%A>d|88LigSvNJmK;%4UU
zomOodXTM%9+b5f=ELAxK4pP-3sTnV#ZPIObT4wAR*_W?QN{sALtEAI7fJ^`tPm`gb
zY(#<2Mcw-CGq<wXVnen4H6gTK{5gM(fSGlUoS=7l%8nViEkbtiyM^b3>pv|!U%5n!
zM$oAbiU3-vRa;j@#iV`-H|Xg6{B1wowo12igb68nC>@Z>$xskz&O7X?6GUmssb#kt
zLO>U1o8bxBL4~9-17oCQX@=>KGWo=p<Pyg93XkhU?isI9A<E1nR`sL-w&wnewd2Qi
z`eHC?w?~y2$RFmg^YXX;#L`ShaBt#ax$@ZQH@eY@ROYjw4F+qU>qzkZ{4Y-qP6ou%
zUvJTD9G4q>Pe;D4AJ!yv-ugH#-@;8&<0<9ALr>r<cKfbrJm*v<5*#>0D2Go$g%qF|
zv9LB#MIGr%266_H=}GY#kl4pBvHF_CA6|I2Xb5``8+)1H^A{jV&d;EP2TM9b^HnmG
zlwiM-_W(9l{Qq>s*bOJkX2@u$FeHs^e+fw_qADLjOFn%-$FBsQVnN#UAx@f1^mpmB
z>eKj%CA3(xWf#SF=Hq}o2{GS!`J#fB8d8ehk}6wHF^QdCu^DKy*DMoY3I977k7A?J
zvn7dMD;`f*c0UU4__(dQAFflg%vE!Z?p-Y|s)r9a0P%D{j7X(kw{Gzax0H#g={jJr
zo~I(~Wwo$yUbeojsLfgV+JNt99f_E|+`pS>=;Irmnrb95d+lNO*ps)tTnU~q^652p
zv^l8U(w;MCKc9VuVl-t6Vn{N<6TxBXv!pePU9v3K)ljMTwjMvx5`0j*$XFMBNidAi
zp&MlpyPxN7OJF`2P1ECVXx&eATv7pFj`HZe-gNV#jHgavTq)d#zVeeGVvnbCEbHA_
zQvtsD-OqX`-ko)M#N-@nu?+E}v?H`8bxwjql3zNsD@&NlXb=|M-!fM6-JBFvEv?}r
zA}gPz^5W}Y1$N1tMk<*&XvznDf~~Bi+H$HSf(F%1V%yBy$!e`cT5D^+SbSSW*Qos5
zaBy$qA@<lckK_&ua`&(p=u&m}NV@NZaB}WzstVUpp(z~|;<qRV)n=2fl5I9)P3Y{r
z=|(1&9!u$4SyiqbP^P2Cj2HuXEEQ8_4vXQd#WC#XFLdVHeFTF?;L`7yZ9crnKb4q{
zgNNluE*(!$qT4qilmXMYlu$18OCCTa-PR5f0vt1xe)9?p<Yy<Rn@QidYqKo(L9**9
zdHm$jndAxmkKn?h(P*FP;kwh)ltSxZA0Uh?tD@YwaX9sGx}NxT!2Q<Y4(|94qJHUI
zq{}eBB$!oh{xyxAkYD5Z1o#2lB=$&+9-l!|;_FQ9$+o}f>(cQQj25KSCDr(`%p_8L
z#ln}>Y)Vm3$Ai^3`0~(~zyE``y__{=UPm64S+Mu%gg$2yL-MQ7P<9eSV)WK$_$3o9
zso4_;Ra)THWZ@XzoX9ghvnM&eHar~Dnv}7Mz^!+HiG!^Yx`1{31qugRhc65V@G#Nr
zapNHumfd{ch7>oHdaFV%l$o#)tuH_&k<>>1Njr5d>SO;ol!lfv-#|wN8UeN~w%t*u
zkc)DsCrGitc4_BpvNi)doT4!cHORfLK`SQi(|v_%SE1or5VjugxuSYXJA-_B{pZ4@
zed+q}g-WF-nqF?mH?6I8_Nq$_J#B48g7kXLDfD!d&vDt*@uRF3DsfKkLD>`?M6&%F
zf@T`gPp=<n$gI*FS6fif&m|9V0}RZ@hlb@BFLw@Vh~~CPZdtwK-y~{&fhow0A#Fqj
z0h$qO0}1xWj;NB-%wJF92Keos$m@?k;57myc|aWBN$lg%*!TDYSTLXa*2qliKhc>p
zW;lf4WVP(K<nL-Ha?;7W+)WM?ZL>Zu=f8#!vwZ3vI3o`@UfO)dcie$s&R8kV7M2#>
zh3u{?w|$~4AHIuAcHc6h#l+s_CU&smX1T;pD{Zvk>xR5w*8M|#_1k_tBB9n=E9Dc_
zC-27dn;EcT&90vA>qR`yi__8ElVh|XV4X+Xx?TNJ3qP4~pS?I{GFu{9<8s#o43cS=
zpOY1t0^VuYs!mBJjJ2m`rgyBY&u5#q%+W7Kwk{)2)>Q%Wt3FJJZ%+|R*8)xx+kZ`o
zy6n^?X_1TXf+nW&sT!=KKBoI6tL>r}I8|@ic*~Kjrg!z_S)n4f5c_UtW%GP7=axfj
z;o!cpI=bhx9^D6;ZA<7E%**vgd9N3TYa%F&%Ow?GC6`1K!B(DK`!+(^ly3e{iB<TL
zuNiCCB^%&emfoVyq45P`H~F?||64)JuJ>i3+&(WK?(%u~R`s3*`OcO3lHR`2vy`5?
zJOhs_*`LVtl(u+ohY`fID|S-Xhag1Xyr6io+bn_u78`J*5Qq+a6XEx_pC~X7V*!Ow
zORIW%AP@Qw^qxin?3}*u!Cp8=5Dc1jD5zwci^toshdNRW$+VbZ;6~zp`q+AD5D$He
z;ZJ_ZC@~!XM({2o$Jga=b;czHzqMWC_)z2(7n^PM20}oPX@VzWvCR8xP1+qyVvSl|
zZz;m#C6$#li(*X^OvzVOWaD|!1C@-g`bq)HQ433MEl^QO&&ulMEP(y~qFnbp<5lRF
z<s`)<)&oj0HoYcWuU%Q-=K|EYT9>20XDTp6rT?<1GtUNa<1v>A#rtEaA|lL#`n>_W
zF`<^{2{4Y(A@~ehfaqbk51{p1*QS1;5AR-sKUi<;O(V(dZb}wI&@G~kQOhF##}xz@
zJ(O>E9EB9?&PNyt^`C9S4c}&{GTQo}-@Th5{*S-u`yaQC;o;%ygUR5aAcVl1(TWwq
zKBg#wVsmGJqX%4Y7~<sUf2}|qM%~kki{h!4wed9elegy!oX{_9m;o{E=HL7n>S9WJ
zo;O;_n)lv~^n_v3%cA}D(*33SNytRy1OJl$|C0WHeL{cL002w;ck{oy0q(57n*oON
zpUwaH{)GQ}YW|+%|NEH#QW5<B9P?i%{2$l(_n7~^5dU5WBT8OGXqf8gr_;|~A>!{$
z{y{&0%m2NrxQS#V6mhb-0w?$<&0Q7Bea4@^z)2+*o8trC#6Rjug<px|NiVj7#pA3e
zOQ|vI67~uR%{f7!exd$Sr8%}}pc+7f%HU%aWWmc#Q?DHOt0R=(ohA>4nWF<|0IE$f
z(<Fb_0@i4FF_>`D->l0Kg3iTc`u-KlkI7x170T(y6a?rCsuU<Tx(?JZks%C^dNfB(
zhWnAJ=8Zf7)Jt-UL>1}`?aR{4_A$lA&z}iBCZY)3MeqqwW$@;NdmERzxos|Ql;*14
z;|47?I8pnBsM`aNO`!jDa;zx}qS2It@cZiA)TW$!IFGAeORR~M%0|xJ4T{ysGO>Jr
zL?De{mZqWuA`TDia7(1hHLl66$0{r1F=;Pc0fEq&cO^;S9|Pe=dwL2bqhT8S5o0~P
zUq{0%63Ym%5e>;=5;2HU8<F7%n!s;=i}bf+H4|qzSfd9AV49I*&XqyH>vKDo!HPK_
zwIL&~MQPUpj}-%zf_N=;F{BjNMiA~W$t!7X8;P-*Kx-gUzqHPQyZ|~7kBO-6S8GlX
zoS%Bnb_tE7pY^jIhFFoniyh%6o<b&1<2(I?!t(Hp%n(?R6U1Wb$8>G=oo;X+hm<(X
zKdnAoiBt^j$3@Q5)S$_Ll^QV|_C@ELoVy4wsMbsR4G|AS)4V`{sRdCHCzgC#N}#BU
zO0rbP$<Hlg)YJ7H-H8@dAr;23r1FlKkxXOG8X~4)Pr*a60H&nO>eR*!PpFBl%}zdZ
z8V;$I)E&W323kjYd_;Byf|%nq(7F)Rgp-gXO#;H-@Rr3)J}&;ZSgY888R)Q51A=db
zF=0X5?BFibjQ5L?NQvOpix~=p5IRM?D#p@+pi<WPBr-a<kF8n|1R;S%QpeWJC%=_7
zjy4aXiZA<OU?`NLkkY1!=+7mSN$m1P?p)hf^~@2Le;|-sBg(TDVZnBzpa$gZ9F`HM
zEci;)^c5Ise<_3T%4Fonsg0)2KnlOw!yV`|CVYr~e|swy_r!5oBD!>RMrv2%dL;7D
z9Ru@s3UwZqQ5B@Bgp{F)zKZl%Lfhb`KdR2j^%IBnOcoHspT=B3eu{HhJI!Dtn}mNx
zQ$R#4xx+C2*NhnECMy+HYAH4*by!krqU~PT(I9tG+VZf`_n3PSYn9jyG%^Y$hPiR#
zWc-|xDViL+#otBnU?J=B8j?RYwzcJ+u{>OWQ~vExM!RS*-%dsyn`mIM^YS3jh@INC
zyfCGVV|!ii7gS2=XkcV$a<rh#+Z1jcPIQ&rwN;mD*c&|g8AjQ(!M0uhR$obqHnUdw
z=86BLuD}qj2RD2=DY}%Uh-o55i()oUc_~sgQCCSRyviFp$2d7}Lf#mIH0T#de<ju$
zHH@O<-?K<JplE+vi6^*d@hMh`zFe>?i*q)cbZK-o8qMv5j|+eV>XX%O@F)P%q40$<
z!cb(Zd<W`xp(VrkfD&%lQvyN@Ae}sLU(XW*rUw~n2sY?l4vG-Fmu|_g&_?-RRW!dU
z!gFEZbvo>_Co<Qa=_sh@Eb2mg^G8IInoJ3iN%|lZnH_NHDks|nHsKG7S<CAFoR%#t
zC9ps!A1wV_NF@Y*KwX8^C*V5bsiYgIsG=3%AFOWyA?@W8r@Y!>OY4__s!S#SNOKZf
zHOnko&iOMB5)}~+gsczYcX-Qtk4YZ<cnl9!!Jy*8iD|HTUg=_nc*%IW*2wUAw-`)j
z1>EalOmTp<m?immRzx3I$Jeo<qi4zN+#LKRWKY8r0Ym?DJ;Lv@w1HZm@{e&0;g~i{
z-Nku|CW`D9NNXVCDAfMZI>$m7dtpI-G)PZr6GrLik}@ovwaOZGRCJP<k!!^G1=062
zU^GrCKuRW+KS#}?!bQmYzWSZ%(?&lCA65+U3uHe+reNj_1T3r}38{DTo{SlYe&?k*
zMAYxg;bR4)ApaDECTxum`5(H&;#mp&|C*VA`Dr*a!bX%5`0{_YY{`&&L{R=+&Vshw
zDyGk_>^>1jA3W*(XN_Zd^q+0CTmZzv<EGd2)$T8(Svfg50A2MC21Zs!K{WdEFRK+I
zj~zZ>#W9(|eVw#m)x6^A=}AUPI#_z3R;`PSfPfAMjlm=ZBsKoKJlfEW-re7a4;Z$u
z2@q~2^l>>0kdyz1Et2hl#QM*wc^PVuV&4`s@E&(zLVk=2K>FwSVxK@E#zsp#%vf^U
z=NQ5v8#xCY$i*LSX8;1JS!Vr;6yzzFxy|Q$+3cK0lM%88K4paqbYemkKF_kVFcb>~
zbc4+bkL&#pYsc-vN0pU!kS^H}R4Js*cw&gT#$UKAJ2xjU8<EF2b#HI{k3{t09t?gg
zRU||B5eYoJns>ta^qY4v;HfkIAYz{vKvM2?a=hTm546it^IfHJjl|9WxJrl%*M$p5
z*ljmrT7T)*;pgW!HSfiWHd#X}kAW>WWyJSumzm}#SJz%6Qxgd4!fT)IFEjP07+-8J
zW)emWF&{l*S-g{niC)Cw&tq;e;WUFdELOw_$!!aJ=b6G?lgLtjsRE)=c(l#)1uIlO
zy3A-yE-MYh>t+b@QE_&Vwsk4Ubk@;cs~-P|-<6lAMV`4ggC1E*Fa2qP@VaEEOwfCq
z@!g5#isrhlzS9J!+Q!lTpld?p1=aHe2XDPj`=WZWVMTsOp;Pw!T(_gc7w<#fmAm90
zw~b};mINu`^yldwlUX;7JMZqPBbHsF`z_nvtG)fWXlQjH^eP^|)Z5{uH$$1%ygg<P
zR_a55gWJ4xb7{})Ec}24<cG^IFCV=u9yc}8Xac_3>&@2C1Jqw@zC0J6>C9CgYHf~{
znUBiU-JK1&C|Ub9dw6bVS%IpNkQCkg*=lIbZdja$>@`FypFnxV^4BI)OUZg+jO;8O
zg|tm9VimT81sZlx3}$3RoKtK=!gD|~MRi+Q=So0<c|o$Vqe~rIbz6I<vx<w9g+U-$
zp^as!@Dw4fo{D;sLVF#Y-<Ui1q;FtES64|>Sz{-`l;Q5KG#Tq%M8~9<n0iBp1n89K
z7M|GfW?A-|D9E9CSDMuUq?~MJZ9QMH(Zs4jaW{hs3NNav^71T)%|qSY@0W78gY1o+
z9I*Bt?o=-KeqDn0I9a<9p5jw)hxi%eOk7ULfdN^JLea)Z-P+xB*Xy!o$y|h@O7=iX
z>@=*1LANQcbB9NSVm(`S!gfQ+stFzRors66=bI&Szjn|de{HFxGyi$$gQz19+f$z`
zk*PpBQci6ntKu6H<Wz~<L1_z?pGx5i8`q^|Zg=&FfckR}inG&OT33B;UxU>gneJz7
zaiX+zxjV^Sluu$VPRA&;C|pmQeDRjur<OyEP?Re?Y7*G3mF!ybP0npslvR>WdkKQ^
zM=!XwIcH9`2U{rFA70z_7jyb88m}H-!otD|f#6h)I^$imF$q#afI;R+-vI1xLGa@w
z3=E8hh6W$u1wc{y>_l>^R_k^GVpt&74TyP@)XU7X3zK=Dt55=|Uz1=}X2sDDg|Ct<
zs;0SK#r%!#(od|g7Pm<i^HeIycyE@2=r_%B{YZo#9MidyIg+3DIUW?=<otnE$r+@d
zI;c`7&D$OM`JN&Ky^b$AG(n}jnOE+@P(?>!ch12@kyu`>v6*FLepdLvOuMnJlRzTY
z%;0d34~%uJX`yCo-AD`_Q-ZV{R9Pkx%Wg33Om<o?0q6Xsqp)4aRTTq|(ps&NE6qlk
z=Hr%frqm2_2P)(3OpM6apDu~i_^7=FUzIJ^BTFKr=|4PbN0=0id&8x{pQ!ku_=K#y
ztASUgeemB5hmAX}@j)p^_PWo|1~eK0c&e-q-+$8L&kOu9>v`fwebBAmbH2v<^P>l)
zh;wsswmaX=O2bOpQqL}jMDi`fP7cz~a#>!5epw(~0(0?RB97e6f2@`vE;ao`lgz$@
zBkN7Q@R)V^y9m^CL0!sb$q=Zg#9E0>hb>4fG$K^KLdXsiB<B0HyESi#N=d1+dm8GR
zKLR`MOz^&I2AhDW{b7n^YxdXZR^9HfYY@Ysw)|M!5X?KMui;;wHLauieF*CEph4?R
zTx~_u>UniL!rs+xS(f03#etK&KSyHUEYJnn&h11fLF2(^;l5q^ivqYi^;vc|B&rP;
zi~4PE+628u2IjYO=j>l2-ZE&c{IBVkidFCe(R=U|8s})pp?)yhi)st^ONl<eaoUZQ
zEBUZ+%?Hm~I2#%5gkjNUd7ifduXkka=m*^n;yEs-i?yAe_i})$dnoE71Ox;?e%p3j
z!ukOr{ETR5Xh3SJD<vpEx9u8!_s~l(Ubb`H48ir=hJ_rf{jI|C3^FF`1H63)#P235
z2y+#BSP)6=(XUuSm9w&nb4X#uu<+<vD{e(HIcg42JB?)r!J0}Th**w#-Jzi9K_QZX
zI=kK$&jHWx&IU1G5K*Yu=Bx>XIvT$%rea{Ck_i)IOYL^1AUBc(iKw8V!&xRkDOm`b
zJ+lCf?5h%!3)85TE<-ShSvSL@iVp?Czq0MxaWHg0C}if7fK)`PDUf(^d=8JLgSBHm
z#;7ips#vnpI;Xo@J~7;Kp?k6|kJ~yIoy}XXt}V^juj9q}OtsoKa{$`i>vKo%gGL{8
z?i03qy`{_f)CQ@w6WecNu>2tPGe9RiQgr<-u`RN3!)1xMyhGdj)YD@oQllA}66xBo
zp7q&qZzzhpn(Cu~K`pr%{m4YeorI}({a_=*c30YVM0u1qMhmIqSC^v8*or=SY;nWU
zV#<l2;{K{%#}P4&-p3tcE~o10B&vk<6iOx`|8%d~BNkBTq_LP3j;FB?IrB8{_lXF^
z_pm(~tS(eV!Gdgd2%nm?`Al2gkRX{W#7v~k;!e@JRNj@pukmorS8=anm1?5mJxQn1
zI4Pz9O`jr(bBay9+ibhrb+V734FI0}0UsLvBJ-tJBwSOA*UvI)rXwjSN)(0uiqP(0
zI%h{P|H;Af^~Qa=R`yk*Y6Kn{vVO_y@OLht{q26ctp?N_u9!Ez%oDzQK>y)Lr>CHx
zAR+k)Olxi(oEu*C9UZHtfC8oI9g&ya<@P|7rEk1vVRSDw%i{>b9-aZ!sMOut%r0N?
zcRpSMA#V{VkV!tIkd#=`J^ftRJOij5VNb(g7_P5Lm>U!rM)ux(&IxK!m1+`BM3sCb
ztiDCCzBhoRRuZI{js;3Ufbo04bWgE!!lGGehd69XB2w2dUetV_<D8>LcIxP$$l~Xc
zh~OtRhmXdXSXkhcsy|!GZov*JWn1zUnb=y3OT;=dr}`*VKFCzoYR6lt>hYpxoiMvw
z8C11SW|WW2sPkT@-QHg71u7k@bHX;()N&(i01!K$ONPomAM%Rl$=I`-o16|thBs1&
zv!tK??L=Nj`O+8sOoC=R+dohwbS+L{K|VdfNG|Wz+wFI@Gfv-uIug3=e${y%$-1%@
zgvP-L52KSc1f5K%3tA3@xi4Tt>uQr6oisnvdU`)~q)hxktZM#clu}TE74>DD^R+ZI
z1aY=X-AcuGhmW{1S+=e}1V*@@a%`t!q<u=F%aNI4_9QPnJ6rFASMh62nS7JX=>sc;
zr0zohEIV`U=<ag7ltf&glhnbQa&dZRxT{OLs>A_3s-ft1$AnG1CA$Ra2T`I559gWM
z@aY7TiTnA1_dl3uq;@ZsW65O}DZ`HVz0v*NP9;TZj6bLR9(vDnk@+Nj_APL*VLSF{
z2Ti(_5fTO#)(420UTL=V-Ah!PwYaT;n31sYYy(tjdhUCP!9+fbXc^pu&yPQdUN+~{
z^dci8KQ_IEx?BDp5MWu#o`@v{#gd*2ew;Teq@ii1NhpKF#Tp+6)z$5;t8jN+VZb8r
z>ZY{dHzJKwN8UWjqYls1zqhglR7G_akb#Qu#ALLV4Ol!)O=Ro0xfV4MRg;R}_&~QB
z$oYch%=#)#bdofcFhHP!TscfkLc(r0iJ3abV$APEUuDOwnB*;Y_gQmh!kQfJY6E%i
zprN8<LS$K_-ndV!81h_`7kV2tLP3^2_uo*Ki+xYW=Gn=Nt%FT}MJ%O;pL2H|LI?s%
z)-KnnJZ-EtCb-b(iG<hnIwNAUqdq{U4VyIb{Seu;zW4hhNI1|-Z4>h;vaV2c#SBe@
zX)Lh71kXWK`u^r=Ca$Ncf5;H^Hf4ucx$B|>)@2R*+|2;$?;(!sV(TTomy^bT1;U$7
zkOw?ISRxcdCrT2Am?N{CH#CAhF8ZDt_M%9$qxU)T;?T^TX@jNcz51<nFo7JvqlLfQ
zCYh6*+kW_RpvjmongjBR`qcKN^hRCDTGh(y<X6-eji%}+jJ5Mj#pWZPwD;lySe#9E
zBl56APw}+%WF=3}fa`n!NAKlfNYLlFwD`R9UKi}227a$jm&EP3Pp8}Q0O;e|caBL$
z>rj9Y4Im2x9rh^Thb-zH5CBwy*2HoFhY1x``<l)=t%IP?PKtE_C(^paK?A_Z{1U4O
z63ZM(9ZtlmVd80IVuA1zJ-M!h)wn8vTFJFKGjyUqTf>GU-Tf6erG^Wc()5w$2bF`B
zcTxa6%=Y3PLu8o>gisQB;$R@eHg@5(ejP|cD(?ME%nsRHK1o1?wHP4Wa4RrB8D$H*
zxv6vhKy*j~0V4kl@d`!#zf|8gh`XNkL}ONMJk6@z918W!&K!gxcZtIqW{fpV|0uxy
zberdKf_~$_R2rK+J@hKj&IJ2&6?I9HN&Sin#e`XYikk1b$imsw!s|S_7$6Bsp(I0^
zr&1}d{rolk_Il{Uh5rLP?E@s5eqg07v29L$uBFF>&4Z0o!IRu<pj5UxF;Y|*))}v9
zEV37w*cF7jpi0vqUlR4U=eq3P>tM6)%=M4HiiMk=60iYR`PY@-zbQ1E#3=AO&`X#D
zCU}bG2py~FL;D7zP3$@{aYRGq5cV@|Y}!6>U4&A_PCC;ydlnnU32(TsG#OTuE0Jk*
zLH6uiYU3Q)thP+8uV<yD;bUWS?AwjlG+#fy{CJ0QzR|sLIr<p{O!h?HH?it;y6rBN
z0JOb!f&~J$Vn`h3O`xdg)j$%H+g%(u^odX<jEn(Ygl%n4SHhrL#VF^BkVSG3GM4D?
z1raqR9o=2lI7Ez~{-PAW<uC`3qC57%K@u2&Y&#wT?l{cYJmE7nM#C_)nfR>P0TkK?
zL}f*g^IW4)2pfYUT)$Kyjf!Wx=8u@e7N%Tq(1+s@#9Tw2TYM0Rs9N&NXXWxAU0q#y
zz)(gqCY=N~^g2J^SL{431}}Lb`z=|)W^fi3ePsENOs@$9nnV)70x88cHY^v$R%`8l
zUYa1zygz&;cbJEVPLo{#0it(1M_TOuXxn9F{R!u0_P_w%g9%LhcHx4kzHe{eu$b1C
zi(&nGP<L8QwRy``kOf$TG+f6VRMEciHVYT9AO&32@6)4~VWDRrp7B*Eaa{~$F=Q>Q
z6+t`7mA~l$cifz9wM-CVKf}ysXk6r+(a*y=M9vv^j5}Wpjmvvj@MpQ;ipSR&V&{IU
z?;1Z`mE2R=8Sm1YOqmY4zFB6mGtO`H*xzmyTq#N9seaKRlxTpAsh;$@NtGEYQ`}}v
zWtQjLx1=|YRraW;_l;E^A!^bQL)<y)iof-*HymU-%5P)BK}FpRDI_H$b98icJzYe@
zz+l}E_l|llj3VTJ0t5kRG8993v%P_c8cCflXUkdqo<QQuUARpk>W_qsG+E3hGRDQZ
z9Q3md3D0#nF}uC7(ZthIO=MZM=Q4cv@YE}6Wz6Kn(NfQb!Ioo|-PXj9;WOXw^YWvJ
zn~3GJ@x<{p&@}7r>Q>+eLcPN^EhjbS*-Zb1rv@CH-(te)_pla&=hHXyTOdA0Rn*!s
z`I9D%V}_lSQk;bf0!Z;-I-xu01C0v$z{r(<P)uUHZ#hK?oAkD2{FR&ha$M?Av|d!W
z)0?mqEjF#0?t9VSv5XNQq9DSM1DjRP%fe4H#wZhV8767`c6pPj!x{%7_miqwzl-RR
z)v^xV4}GdW{p!KnU$^~k3PVB_v94g`!h93kbgzX3C-2ewNat5z5<UA-6#=SRoG%Fz
z&A0V@^QhPXeV?CH(CxH<N`W?xg3N9+R4Q8F>wPIrL*p7QE`I!W2UP~0XTy<QO-WN9
zuz}WbKD9=sNTDH&9p8T12(Dv)4S7P0=+WLIGf&0*WX#KDxcV42s}J+sE%wn7-mf2v
z7860mTwFX`=tH;gao5{?McbYFzEPCzP)fmUTM-7xFxkH2p2+(YZEuJswy2MbU+m8K
zMaZGWRc=C{!8Kf%fdIvY$M!h68Xg7va_zhwA=z#Nb+1B@*+$OunJm=av19q8*Omut
zBE4PPS2|gDho32Zr3TkrhScSABXy@`D&;_?ML<vv>X|&A0#Iv`2@oj@gn#-TO&6x5
zq+DG&<SIN&OEWq<IjsU%7D#m2hYf@QtzH(8ftBD2ByPsnLgb{9AJi8oLNLDF&Ce!r
znm0%Z`Kd2G3A>AB{BG}kndMTsZ%;e+#*asvl6*ALNF)f;-_jkIPad^smWB|bOOhtz
z_B`zFJ>8X<OA@J6X*^pyLk)qEygD^pl6X3O+jRaGH#=qMAk}tFAeyF(NbN_iam<9w
zj6@tLRO2JR)HTiHR7xBbGCBS$Ni@oULF^=i>*`ie$4cZ+R5p(-?K(-f?XP#stuF-9
zyI)ID2r$4e)+_t167F`P+ta-i-YA0RuhFn_H{2Ml$8@rhn$KMfU#+=V$r?N&ExS!y
z!a5#Lzkhny1>bl}eNCN#-(JA=)m5epl*0PwtkzAg<}j7=Behs)!37#T$X!_dK93U0
z-%h~LDBCH^S>n6r0l&*y(2@U-f&A~WiHZ6(6f&;mtoBh%q*|sBc@H6BBY)0e&GJJH
zUP9QT-8YagUU_*z@CGj>?9q2isOTX~&9=g{dJn^CvnBos2`vgkYs#_O8%gMBg4d<u
z&lPZcC;}|fU0M0u69R6#m~gMww{j@3s;^wki?nOcFrd%G!jHHstiobf=2S!R*=~I6
zz}N@OeefjsWfD-7tCr7QTFL7T1S1!_@ny|f=rov5G5S7^wzah#WO*{Mv0(~*`*uY1
z_9vL=^-w%CG!%#gqTzE5<BSy~12W>~1)_nB^9;ajy^DEj?A3IN>V7yb=X%L>mr9lI
zf3tv4X}_dg?Bfdc^}tC4gg|TJs?+_@;%~q;fcOF_5olEXhfbeKm`bPuHIMmr>C&uY
zI5ikTGq~vCo5Z&OkOcN;#6#Q=Kj<yoeZw0fX4{fQJt-iB0y5M_PvXA^RzT#8hY`~5
zUj^^p$la(M{3oVDduRylI%Z{ZrGg1c`jF0{qO7dU;T@s*mveNw(JXF9)AQ9<pDV7c
z_qW^Oj8cWuf9ppY3+K0HLv%-!QM+;mq`A7&<9-q7wpbL`y1lvS9~g){&h7&E$JJCP
zP3vFBbDBNSaEA4QrPKw!&gUH4aNb2ena0Ljvp-i?W$=UB=`)TG4{<rRA$pi16sSH(
zhOjRGKb2i|R8-%-A8JSy5NVL^?i2)6a_AZ)ML=4@kq&7jC8a^SyHUDBYNWek=#F=|
zzu&v--Mj93>%IAN=Ip)J*?Z64=X~mG-xoDzTZ;|`H+W8M)CCAxCy$SfRoXALVPfQN
z@`Win6Z%zQM;jq6ug%oFS7CE*O#GNME*G$|bM&-+g|;B7s0jlVIij2XYuS2~>H6X4
za8}p-Cv~K9(oP5hY6xC*SxVZjFWjHYK~Lxgfo&Hm(km;wX}!)7p4U}6ExN)&0x+Qk
zPmz01s6A&$BN)v`$AmBw7j-Oe+VT%Q<B*E~qHx>tlWa`<1RVgt8NjL|KVlPHxOZ3f
z*a=^IAMUu@+aI8Y;Zra@K<i5#D~Et5qvbF1S;Vsrh8?!EP0-E-SiC|B*}o@DFuSTC
zC-Uh@><DMn>Kng?p?)%`4zI~bNPH(|b6{KOI4I8d(Jyi)YR-1!@N=cvAgT07*4P$@
zLDQdw1+V`0{Ggzq)YR0&KMT5*W^;ga3J~`LA|6rQQ;8Oj!`1V5*iK!zs$s%;M;3)v
z`a**g)T;u301hNXSt%Saf?hjZdhnKdyrV<yfk3UeDY^Ylt3x6k^OX0SL_pAXTou1D
zLJ{EN*N{<A02}H@UL-6J@D;wKv?N2PAY4Z~hBshY-AgwVS1N~;GC~k(82!Nl+4~aj
z*<bv3Mi4-;_soU1Q1=jo<mKFXXgDo^s8?%VKQ~$N(*hhcA$eUYmNf9Z2h1Pf5?*N#
zsN(&Dkx-F&^{<^!d;#bRb-~Q<zObAz{bXQFNIinWo<dV-)I~B$rJ12w4{SWZy8d?$
zkxM~2VNR`yG%UakXzqRzebn|j-7U9g^+LDk0A~384dt3*)OFrw4T@CHUcXu8Z>q0P
zDf=t<uuRo%ey-bgW|PI2gq>)7V7d9m^JWZ@5lrhhn^R5@(T$CXnURtHx52+J!|h*a
z{{NkR|IZqL|J>%^bOW=N?xe^MN`Z^+ilQB_+!z0M{-v`~pGN7SsiGLbs0bvP4<)<w
zTh+|$0jm%Iz*feO3$;tZXlR(IzL>=Hz=%F9UBS5bKm<&uNjdO`kFf7EP8NBNk8i?7
z+}75{VB{0>m%QMjgKI!YzsCgqtJMahS<HiP2`dX9B*R0B`LJqU4g)20g|~Ajn5AC3
zA_E2%j9;nhxm~$P;$Qbxo&#^DRb|9fxG$NIWcbQ~38hc2n6eh5<fNi9s^VWz6ymqe
z<1-cvQU`dQAPX#&F!Nh>e$DHe=ft%-gD+v9v<>v7Vev@IxIYxodOK%u;}pLs^w^vl
z|L|97YwmT$yTQ<TRHhHhK@ISJ4hBscgv$(DZn${7*K2iOu^yV>_$L<wE-L#3@HHh%
zF|?5tGkdg#Sfp}7YZwVdT7{5Yz>D2N>m@1q3vk#0QXN)YjGJ27C4zcv;#gb^Dn+o9
zQI$7Fn~vlro~e)og&#iE=nn1cN1=F`vfjsm)KD&w63eiM`=rK|A{KSR>#6Q7j#1Tx
zj}-Yv>;%82N2S5Y_9lFgZ+fpt@39#XkJ|jaE-d;3)tGtY2f|ON3Ncf!$#1e(zTFe=
z1fc(_uGjlC0JXy7=qQ|7WKeySVA~my1tp6Cqddnz#eGWl?LddvTe%)zyg;AYONLI)
zNx3O!M}@CS<h$qvL~nhVK0Fx%2WFZ;*&{2Z#NAK%(n4x1F!z1`m7gPi7cF3CEp~t5
zHB(~)gbe6anD+M2CPewE3nUF%3&1BQ?=FYE=BqxaYiSWibYE{~Ma+L*2}`>>$pxy7
zK6(83F%HfTVEZr5wa2Oa;G!yvArC7q<(z|0qp4yzIGWH4yXoVBvq~(ON;NG(RLrC#
z^jkC^wibJ#N(RoFZnc<lzhyal&+-gQ*@}uSCY_|oeRqpC>wLu}i9ws&v1@Bs)tyET
zY{>p}@%z3^NT3sT_O(}!SVCL<f^bdEWjfXnK3qI@E>Z8c`mbFx9XUIED^e~sU(L)k
zMiGSVhQQeZ&I+QTVMxs7I<=0BZP9^q3n6h9l95Nyaxviw-E4J&;v#itqWSg88@1xI
zQ}d^r7L4DBM$VB54`_w7K8k5aUx734Rl<w!93Kl1I8Sw>8+=<fjkzIt@w~w*u2aHO
zjSe3PgCqz^=;@q37*gY063ONu%3GCcz2n3mU&rt}R{c&f=NM<mw`Qz4B~ZfsXv(kW
zeML?VEcNY%N1rR;WCTR%6-CfuTWjmL<tCj#ZiW}&1UE9(UcS-Z#~2T%5UqhB<^gD-
z`Eot!e?Zyi^KN#)c@0n~o|eGQG`j@&rLnv*(Oj;l*~>vjqf9LPh}Rlj*@Vbksl~%n
zDl=%HauBqU@A`=J455TeZ;CX+QmAET2N3iH4e33F6!;4HmRdyoNgygp2AlSll9bG&
z)nqIXz1{>?><V_OPrlx7>mE+_!TdZF71gThnmJ?{6q<ypN7ZvPWtv)bZ_x5rpqW@|
z`^{WB@&cLyWXnil1^t<<>~`=3zPQhlS))2QdaPKV=$|zHe9uq+nrbQ&HA|jLfC=<+
zw}AU`N&S<TyvEH~2dz&&UYqi?TB1pe*mU+h-Z?Lu{skNE1q9WQ1Y`a$oFHFx=oX3>
zxM%^z2XP8D5Hv)Rz_>9IS?`ret2`}GW`U5}EO$ps#SVVQ>1GL^+5Wv~l~tqk+vztk
zDLoIvi*n>v)vUhWP31JPS=UF)t3N`M#ka&~CW%OoSIMbCp`G|o2T;*T0bUHvG&z{E
zB-rF+L&F$5SrBycLGyJ6sy$f4rW&hP(vH65vs{o)zQw{l7+E%f)*3tfcbXNp-oYmO
zlU#BVAc%R&`i0Zxh<Tbvjd6Pbkky%<PIV9SeL@C7Lq+{#T?4#I04CnEvrm)}wI0`>
zv?EUzzdU(3<;^ND>y542+L*5duY2gm<PDi#XjHDrD#^-odlz_My}2ss+vcF6%dWeS
z9gL&pUyd<BDJ!h#s;`zul1x@>0<JvFAk|lEaZ8ESbY`G(ov<qPP)j+2K8n=H#}yTL
zk6@d+?5(kR<4{Y{r(4bYTvF39{++r_BhoKyH|!dZiZ?Ab5~$42w&_4KFQ!&{%J#mA
zm%u5fSFmfz^TUT1z>AWNy^$KbSCu8zR&>`%R5BH~F8!gC**5ykn)H$D@%wCt5>5?Q
zqtxeeII@Mi;|0};u?>Tb{2uYH<iX;kd+W6#W1n^e_V;(Ugb=#}L@8u2tA{TDA1lmY
zhcT)W;&>lRVV5FTINp30*JV9|;ysb7JC$!OlBShEqjPN&{|LySx&PVR81`XB{v32C
z_)bjH-rf@H4^8kGYS{;iBGPQ1{Q`qm4i+eAvGXzM@~HX9FC=RlROoFqUbfKbGFxZa
z)J(6ogR4~QYXyHySykw=MOkTZKrr&&`p6&T#Ny?<)Ys8l1#%4$BLd4Qq`$hzwaQ)H
zbOatI9wrhcu5@pRIp*Z=P<jmYUhPzzDCdxkJ|T2g&J9O%K3<Gk+b^}lVQh}`OurEI
zZ@J$|jkTScm_W!1T1%*mZ>R*=J};^nIN7`F={-*AHEkM!tw`uyZY^>7W1H@c>aa=w
z`ijf?3HIc}rw_Q>O~0nxy@q_`Lb(Md&PBPzJ+9MFhqgI#1dA5){EZWyd))vT;D?*P
zvj7vkPxaCQnHjsc%}kBQQ7_}v)RaM~AeZul0%x;^p<!B7RCzLK9xO!cnsg`BIT(~)
zz#jukEz_Zps_*4NUaW*lYmGqF7lLq2bc)`AAeV5K7c8FlgS<W>gC4Y?aP3XrAAf3<
zr;6{{M##RcQEuAi@j+)f1pTIDXMJjW9T&@RCdc2eb=@~ov)-GOtL3Aopa0bT`I&I!
z5c-7!uVMM^5|giCLmaHd_r)fN(MVj#nW3BhjY(^}v(&m)Btx#e=H;iYLsuqj-~JhK
zAs%MdeAj(tc&-Fj7+-8Ih-rIu!i~4EMn>@V9Rs3I<tG?)lH)~4F{>NfA#nSJb^D_A
zrY+N-dPmG*EpUg^`f_n%19Fcz`Fst;T*?Gx-StrixU>{(*As9L37k>nYZc}tQsZ6b
z3%LBeaQ6S|&!)hC<h4{&HD9migv-+vm)uLHM=|}(_Cu1>B`n7BQ8n%L>YTpo0;dQQ
z&Nt|*hU7g&qsIbJkmx-dR49!l>K5AIu{@Kys(3qYA3+PLrj2SQ+@|6*+&uT!q#Ww3
zGvNGsI*}fe<Vp^NjJH`+;hdqJgSl}WkJkt7S}t?S%F2HHSOt8_hWZGN^m7hjVPRfg
z;I|~HH}UWtC7^7Yl9F@d98d{?4@jkQ3T_GCV$0?OQXtWufeDc_g5B<*DGu|zsD6Vy
zH~bsmY%D&0zT_>ZYo3-?@B*HW$M!{HgCj#=uc?EqB4J90n%6d!LwxMdAL{Z*7f;NW
z`qz@}(oqIlmqO!w;?^BDy2BnBihcdYf(<3qSaTBPtpBY$^=VS4%xEG?+jN>3@PDhi
zeIb&E#34rBf$QSq1&FQ%7tCnMmK6eu+ytyyM#W(I$5IJxk<NGBc{4Y0iWDe&tYoKN
zPHAU$Q<3cI-4~60CY!tvns$^P9d7TAI{KEaS?@~)Y8TMCxE$-8LodbLxg_Zh8N##n
zmmpz$liun3WB%J^|A^6TCw&U`&Mi@PacSsnYv*G%vKUeR5xeKxbp`H>DBf%a4hzlS
zS?gCj*4n^Qi!}Jbexe95%3%QF1tQP9uC^HK-%_rJDQFFG4FHY@=fmY!QL=Q_<j<Zt
zuk}3x+(K$<ZO85jtu56_4k>NSN2W_T;6EK~AV?$b)Wxv_okJZ31c*n?cdOIFzetM#
z*$%z<#Zn2Xv%y}M3qpT8JI<AqfCPFgNQIV!mY(m3>b*4H33m!E8q+#opYb^-?^|}@
z*q+&)nDYpan$+r-b)4&FS6ZKT7BRFXw%^RIk8D%PxKiSsE-DE~7o_ClAUCffiO^HJ
zyzEwxuF5@B1!-`r!fxre5jKpXIi-%#Q|Z)q$LM1rB6o?SJeqAfg=aQx*m^{)IJz6C
z>EXf1>ERLIF{T?uQY$cezIiVR=O)A+@v0y9yGRZ=w)#h>pr3`%t9b{SyRPZ+hzYWr
zy^q-4q$W&`L>W?ard35RJG95FJ!03oU>Y?05J7i3GZZezaC$lzdKQPi0kIj5(!Z!Q
zFD)bbtOcWpPZXtR!;S*dyHr_XFE20cnor|oXmoe?6wV-kUOT`TNEtc<^hj9cK)wWN
zI~Rbe@$&MT52uEOhO#m-ea3gq&6}Xbn{+J#s~0C&@(WBNtL&c8Lv1HWK*Y-9CVd!g
zg@-ci-cBhmbqZyNkwzwU0-0%d4f#^?uuIhQI^6f)3C-;7Rr8m&ET~N5&VD?NYI1pQ
zzB;6FHP7`PY*fT%$C1ZICOQc<68CzGWn_ORnc|p^r@jYT<dYCNIZN1>(J|0IPC5tr
zu&)tSe2(I6I=}nGb*oK+OwaYu`oqgS>#(UQ5>RDjr8g%EAL1tk{PcVDIZt7q<`dc;
zKerkbGG*<(x;s|q`RsfyU@t;V(1qi8>%tWi5FjZU8m&~3$pxhSnqrB~4Z^30rn%rm
zV?9IVbT(?u_Qwetb?n#s1#{!oqwMe2^55N>+1J{jgnnh_Dd#;;X<IfF&0)MM^=<UX
z%@sGuz*Hx$xR=fvbM}B~XN~#qV7nxUp6)qCM9CfG+SKPz2kScvRVUBp=jAb_ZirJV
z8ygz~sRW{krl&w6F(5%Jq#sX?iK%+uPZ(efpq-FZF&Cgd50RmJlySo9s%f@beX{&N
z&I(UE)ta>wkP(m#yA;Wpf1~2u$*pjXV5hZl>Atb5r7Suto`~11BHt7Hy=Ac{)`dhH
zo$|{leP}skn-`H3VL<w!-f0|M=S|*R`c1BdcY*tl7IdBltw=>O>I=8RV3Kp1^LY&m
z3-~(R8J?)Yg~^`wR+}(r#Jjw<Uyndi9nsRA=;Kj-Oz}ro+(I1cTBYs}VFgLX8&b3s
z1ei>i6b`_<kI$@|JUw`%w;C0C7~+!zA$_>V=XS~7#Ni)%)C-0pD5stlE6@B;vbXWI
z`^9H!+#>?BnK5lK?swzwb${m$uTe?490-^S7Ujm|4wCy3A);$OZMdbx5bEB;(tpXn
z*hov~T)X6;9T8J5=Ui{p;NSN4mX$(#<p;Yo<aJ!hLh~qlr5}ZE@lmqjmqeEnS^Vgj
z$JZ%!Uu8fur*1PMSEjepW1|Dj-~~P!YV3{UM{Jh7(dg(fE8b|L7<5ilhg>nmBJ~ot
zy)cS4g}^xmW$2({YJVcBe8Qz19e)1Ac11-6P?avxnAn&YLVTyEkBH&&$$gzA?0#Vn
zB)0+xG~>5k5KzO%{qAz(`WykbtQH%Vz&wToPx2yCB8`CO08ro1y|SY;>+36APWXhz
zO@<E1W}YqiA{0{9Y6hm0g~v~jT2|bst0Ao^wNK`l)g}M=uI|xvq3A*}yFWi)**4v9
z#@wGs_*EB=bHR0UWJ;Q4>3Y^;C48dBr~}!>)zc$!cF)#U2tB_EuJdk1#U*ptSfGtR
z;IoUnt>?;{dJ$&Oc-1spSX%2|08KMo=Ua+CrsN;(1BZ+FrD1qiM#aZp#+Lq8IEPsE
z85iz0anbq{UZ;pF&+D$x+mx)^pcl7x`GL`$pzofa?T>z1Gn<%27(3qQIl3?2UrY4l
zRlKOPzIr)093J}aY*&--gARxqTYA#va(_01b8p)1+}7sLh?8VuJT98#Nu%C;yXBHB
zMEO7|e!oYosooXcW3l%tX>kcmU~+RgTOSgF1rp=x`hpbQLA+8vwUE7tN-k#NW9rp=
zREx7~QAsSoVNo=Q=sM`|unKJXCCDMs*^buJd2ELJSeF?0?H)md%wgNnqCW@|B~ggW
zA9Eo79>4MURQprWZfzKRr`dT&OI}_+!NzYY<HgN^bPA-_>)z8CxwyW*p8mNIub`ly
zurNuBgI~%|%ijFruI_GL9v-ceO)`L1Rwsd+o}EpDMA4ZePi1*c&ubrVu@P1wksGZo
zqH3_kND89Yy3G&5+P%MgA&@oS7}PUI*@g7b_ZT4=d4Gv{#=vt9-wMz`es*1^zvBJ!
zF?qUa2J!&pmsghI!&E4w+8xXjksr&qGb4;s5(9BYz||LKl-$24xx0My#7;~=n;YCi
zw6DbM`rlv^6&@2Btz;0=j;NlUPq}Pu+=`j`h>t&k&}=75B!^%;t~-eT*=(g!-kXRg
z8W8M*O_7C&YbhTM=-fGd{OA!o$suS_DE$4@nx7EsqufPhs5vo%y?Gkf+<5fI(Tj^Z
zXt6<{eF&*Az6*=rg*c-Ma_H$u*>QW++fPfTKS?meZ%eUM&|c}c#$IfjO7AKVX%LfF
zu_uUA-}E1BH2#^_2GX0V=+I;jIjuUWzxzZ2o3RGU_N70z?b?_cnRF_K9Nw%T_O8G#
zKP>V5S&lS$uoq^kAZ!YTm}_j9e4j`n+seGrznib?>H1BU4*&IuFJm2aD4Yovf?Hup
zmKrUBsmmBpk=a8jsl~&}I@=vedz{@L+L`EoEg;d=0%u~<<wDz34{Kw_e<>oeP;Gx&
zyPcZ}k(vw(3A^F84xc?QzBoK<`E=f0+&%~!7k!oL5h`BhKXlGr+&PfQN5)9~Q%BiN
zsCqz#1DN+QmH}S9O?OP{RZP4)W)9`gLeGe5A;X3M@Cu-I)EU7tG}&sGx91D}raVhs
z&1t_KD0wO^$-9*l6)pI_pKhgO20uiP;#M$~!mVm&fYd$2eDifByhw!!SYPnvvZwg?
zH8wMGF)=br1TI}l%F6Bc-i$!cRzT592pv8>9bJ*gN$Z#+kpYz-G))IU0`a*axliwc
zrGajXP$IffBonHWZ<>JNk=cc*0mjjWTU#J2wT){4c<$O1DMBMPr^dTlef3I}4ZzQL
zfPGEX6YXyw)ZYN9nBzn109m@s))!J3y7x8l9Bt6_`Tyjra*<cvCkV#r15nGzpsHpk
zyh-HKe|K74W+x^kWra#&P>-LzAbaTgD|{!rn*zY58}KN76eoRqc1}k%sqmJZM3A^}
zq~m>Yr6#H4@PlOz4-cJ~|3+e6mPb^ufsy;CY3u)k=6aIcp_vPi%X8~UyMTa?+$)Go
JiIkD=e*uHp_9p-U

literal 0
HcmV?d00001

diff --git a/doc/assistant/deleterepository.png b/doc/assistant/deleterepository.png
new file mode 100644
index 0000000000000000000000000000000000000000..20db674caa2470ab4502ea42a4ec44a6320d0aa3
GIT binary patch
literal 22780
zcmbrm1yEc~w>CNi0>L3@a0>*7;7*X>65JuUyL*B|aQ6gvcXxNU!JT0Ut^;@SzTbDx
zd(QXYTj$o@RZ~;dyJyYn?zOw0?&n!MOi^9}6^Q@|005v$Ns1`}0I&7|0GOyZub?F=
zbzdr=Ux@aSnoa-!+R2{}jKlc1L}(#`vy_}T0uYuI8;&<&D;oMkz&mGg4QEk18ygc_
zXMm`q$ya9+V=^}jXLB+MDLF;;Z)kV`02x3^?30T73JB<DPk7+L{J{MFt4)~IpuZ)S
z6v`Z$xvD+Eb{4C{@f(^#F+O-N!@9_rJ`uLJW)v6HR9F#dlryx$!|#{TinEZ9^pwM;
z-iy{KOV0}1!tybKw7<l^ZAV+W`kqCbGNNexQ3|H;bv*v>=zL>Fs*7hB47hWn<|mW*
znOimjRDYn)tw;8)?q;_kOcEmlgMVmfsJYc@H#P<)CZ-H71@uZ{5EBz~Hd|7?Q>065
z@r68;Yd5A4LvK7Ng4UXyZoxo;Na{yP&Go&;#R}b4haGq}ap*5dTUx;_R+Cu*N2{ZP
z_|o}GW$J%yM>IL?e5OmJQ>xMF^vzr*r=Z9wr_|11px1PVAVL4rhIV;7a04G|KF7xY
zJu<YU+8A1i!f;pwYLr0}Y9mym=8t!Om;dG6e=Glo*L`t8f9n5b=I_@0ZRVfl|1|%1
z`TyGdzy9|Bhxz|()jz!dPxF6|#sA)WrG^Mv0Dv~7nS7-|j4z!6hV~U8=QRe;zL;2D
zdjfR0jnAm!hfh`Xj1gavi4*~xt*kEkuoUv_GCI6H61xKdJla3Y+B3)TF3{Z{^#N0^
z=datN{xsKyP^%nw^_*ceEC6_qgRJ-~DF4;IR(!|)5W$4KY<abNcoz3ktoBb?o2|CU
z*M$Xu1obLCa*CW&^T$L69+OWv0AY9~$<O-I1@<ocUBYfM+VvCbuy4|dr9N=0Ddwu!
z%-0QX{YLSJ;3Crq{2A(dVV6#OULQ(YO6+*i4n@lzw%9b}Yq_lS6AoT4q=rz@tk=eG
zaQwdj<)!T?Uc(xF1K9vDY=8&49wz{QG7(8Uq%T9Y05W`l&sS9#5BM6mPk{!n;D){q
zDYfjm?9*XJQYixrs!22&24xXoLNQQAD;&POdpds5;LUe@Q-cD?@wi9uc93Knb^G)u
z3L9{=Cq_$^X(Vye58^Dg=VGy^R)idW@lqX@FDHZg^4Giii|vUVkqVHwfsfY{B>h(U
zYD>F)-Cz)H(v_KNA+!Ds@zF$|>wOKw=qW-g%%R*$gA?A{opz%GnjTg_RjT6bMV`4}
z)@2WA7>etC!0;UriWavO9Ub9=Cwe1I94&xGzlEXfEaQv&$Apfr<yzkJ$vv}r3S=yN
z@%|a#KOv{*uW4-n+OhmcHq{p;`V%}od(Xon06GY_t7(&_$f+{z<woB$0q_#D=bV2Y
zA!w6?Fb~V-x#Wq$<#c3U8R>Oiy0;j|24ooljgFiU;Q{fr)e#W&#~k8?eW&*X+8*(=
zDkegCX<ASGA8wr}K4Hwb89C4%pV@%W^Q%ZDU)9F5{U-4`T1%Cl2FWI)i<S>EP2@Gw
zXG;_4d6F-rf!^dP{K#WwR^vs-hJ|}W9drgG7fcN!oLi6I?;NyiVLg6@P7P2VPECI0
zq}u%)e=zboSJ&is>Cp}ntxFwyT`+ZQT3DO?wa4K5>Ka^Oer{(v7G%KQyqp{pNrjl0
zTg~dRn<m_5=xA(*kHyCf4=MC}w#o!*iP`(uf=f!4Il!Uk*UxDr%zCejmZ%=9RUTZy
zK>it>5+j3w8HZmxLA4>l%s+GByBJv5k7X(`ns>+N=n3L?=7OT|CKj%Axp6e^+rqIy
z7sLWH&&CpG2U?=K3go<Sk~}oF!ATP}fo6adTxR2QbhNz3!g33ncK3?wZ5|srdjDc<
z_=m|#I`_oV@)V^AGzC{zSV@=wpTZgaVeqLBx$eMxHmGb@y!X$L*wWxC?_Y$L);b*#
z9<)DSMJ5%9G70E-vU3nicd|b~zU4#~EmPeZ(WW<nY_qTpO00M-7MI1@@uz28sUYrT
z5JaR+!gR?Ed-lafO|jNc`BL|v9lre&B;YLk9~RWrLNO(WDU!tHo%qMR3<~JN1PVVI
z8%bJIifMATmazdUjCw=cnXI{O@I_#&n#E(qQc?YQ0jzlyYt`;j9XUDabeo6pG&O(`
zYhXJ`cHylhFX(}!G4(Yv=5!|5^^vx@hxvCfMXLHZZ16itRsaXQ2L=EmBfKesqb67`
zf!KjTH_)NW8iW8C%g0st#sCHz)bq5awGMn_Z4;?=Vo`Ow;wfuMg&XjWU6O$%#!|1x
zVpiD<dPnwJt^iW}gsj;z$vz2FlTn0C5kmz?jKN#g(fv)Qt{krfb7)&?gM<*10V2+l
zefb<?`tnPji}@>b{#mUsj>S6fPfx`I^&^W+xfC%&G$Y!YJ~OC26<#h>h1HB?NK4Zs
ztYv=btV@&XyzmGTHIwH^5eK+px(tpRfonw%dWU}s@gxfeH9tu1Z%2nIKCsm|%9!l0
zY)OAg63N;$|LF!FHm7v9fbnGcSd=j%4Rf7o(_0>bOG<ZkWHEKl@*e6%rEzMQv7qsE
z+L%W~1@4pi$eMI{`PcYs3^Fr6`Og}^VgUZZ8PPIuUBw}}<8LjhhlGQwu3m53AJPFt
z6FIac#h9;2`EWEq5ilPR0@3%Af2+wB!*+m{^Bu=DcOAMWU=u?_ZENGiZ@eUC8_PH*
z`WFQl_u~L9%s0Y{Zc=>&oSNv7xW!ZeS`wV=#G}EyyRo!z5{;znt(fiDeq_y(T6E9g
z!P%hiTT`^jvpG00n#Y39_E?WaAM=%(8tHuyqi`iBU?9XkHV3j8Kls(cLc#WpvwMv*
zb(KCK%l-PhpKO;4YsM2gPL^q?1(osjVKs7ZmIFiOe&E`eU#Ab9gsoP&i+uQaG%1LW
z<jzG!yEQzPZCtbe1U{YbpR|ylPtEjP62murO6TP~R-*H0Z7J9XYzoU{cTd9@Fa*m$
zh)>2?{#q66WfC^GI~{l~tcy;5S9f1Y5bi0s-kNk`o!FaHBwu^VlOG4MlU!$-`_=Sb
z&avt*-shlJy2iUt1@z@}+~&4$I!zD%?vim_g0;{=az#ZC;iQuK1qx!=&)CSBS20%N
zUVja};RWv%@@*`@k)mnKD4#kXQ~&Ju9FhM;iKxxQ2pHGvVRWW&z%)0R|L>kyy$kpS
z+K@>2rb*`1T~N?cP<z^Ba}+06sCwq)JQ?NEiQTILvFEYpXg9F+i*L<0AEo1(P9qvl
zWd#hj!1BUP=vL@zORS-dB6rYWdRb5h6>1Hl;77plN+1k8EM(^o|5gRyJTf+u4yf>?
z7w8?rPq|ypI9q;%A9_4N*Qmq7Q-C=XSOH#c!@s;g#!;q|du)ZD?Q}CcKC;Gu`66tk
zzgqmj5(DDK!Dm%R9?&AG{%iJ+r4Zskjzs$$(fvhNKev(bB{&R_VNrXnrkl}%AKEV}
zIs9SKih%=FPAyrmb9~<V`$JTcG7!E`L@F|6E**K57NY((S)c-I%5C4ha*z}6VlqFk
zR4cxF3slNRqUknF@qWA3Nfp4rDFNQG8E;TSnTTqSNsG{DT(q*vC`=oVVa0?uRL0_s
zf7n#5Xb_P$S)Rp{%|Ysl&$LPE$1LMO!eaEnf&|q17cx(IOgzIp)yq&&tfY<L;^Nl0
z#SQN+M00<@@leE8B*%WC_ttbEqlWz`1_S?fIeOJ>b?i}`J4kLOr>hL^4a=J;ygKEQ
z<(z1lt{*6x!D_<!0L^eA50=XS>tyE2^NbL<!1n-_u>0ZIZ|~m4p?vX|8p3|%Kt?O7
zUB;aMU0;<{CSL`<M`_;?r?jbzZrJq`pzKM2ha!hBPOTJ}^nUd80}Kz$*e4dVNeZ!n
zkf>{2I7QncUx!^PCn$h*b04mW2)moowLD8pZRVxl3LRBEa{k1SY!ojFF*?fUsNgO5
z16j>91-;vobG|7PcQF94e!>{0l4{H*keatn866yuL-9Dx4uYt55DJR8aVJ+sI9zPT
zYvY6ygQ5!8)fH<Bzly9sD7ngbS%iv=i85>~zZmD0Mi~?}e_O1v=Acka?YK(P-+50#
zL01((OZIP&|9=3S^>>lbX|q1`bMD5|K9?JKO;b&cQ%L9~($3rH<ryN2JiXt1>6<K$
zBvNOy{cvLK8t;1htI(m=XlQ+%32_bZahC<|B=h=5{r*nlVX##uBQi2__RG`3hTjY1
z{{FtErsgW3(H5wsq49zK&&7t1vT;A*<_h}29qDuFvx)1PxDy=MitD$?d&`N56aTE6
zWOLUYgRS#G6GEl{8~0GIKm<}d*TT@$da1J8(KDo=53Y`FU6mc(9y?kL!4c)mE*ZFO
zh<Ouz-4G45P|z+V*53=O-nY<EQ@dIBIvcKe+6+J!eEQv+Jrvtv#ZG{Hl6dO}Q5(GM
zeCi3J@)v6REq`+^^i-;U@j6U0^7OWQ3JQ5YR7wjCzVZJgt0foLuS=PdKL3QYnh>sw
zQs<SX5S?e&%9OEQG~|@dh%*2WwpHF6NL{T&rw=Zk|8aKu)p^d!@fzxihO(8epJi_0
zc@!}p$o28%Df@*DH{x`yna#)deXFyt@AJm<>4xuPqaUAJywF9vGDPTyzOMnE|4xWd
zmJk0B9&{n8H%@)kf|qSh^)5DWO$fI?>{))1)u}htL^XmRl?M?Da+!Sga}9`T*;%oy
zlD=c0VEo{O`_`{K==kP4M{QWqYr0E?oT0aUNL_De;T-PYJ?@P&t$N8TkGdiN9EMl{
z7%2W78c#<tGp!ADF8uA(IWcD640&P;zft`Rs%q2kH`EBPRp~@Z*FxezWZ2D)N&b#e
z&eKctDeIfTux1)@5DOd@8SZXL-MlGntvTy+TkCr^YEdNGYnkyt6^U?o*jgMs>w%tl
z<`^S?6mxR?<cm}(gIA6yH7HQem0H=|#K=U80FF2GA>=9y*%=N)wK7KP_*o317&8Gy
z;Gs15xcf)d<r<29i!$fKe5K+?aO>G6G`zSv&Lg?j-FFtswVSVz{Dc0w{O&^hG`u%)
zZFREY21wjV0c6jDd2yfCy-6EwzaF50Rx-Jw9oSw2TG^jstqq53Y?d6OuCy}A)YTp`
z3l-Q&2&?a|)Z8AHq8?X$)|Y;$e8n&Yy1=(z8h3xv^UlNyX|HwSc33iVTgn_Cz(QzM
z(C^4t|9Mgz)i4o|8xYSH<`~bdytqu3rh8NX1^T(YY^+jN^W!ZmI=VE$3ef%5^6;;{
z@mDcDu(^;wwQIR|^sMRJ+%D?;Ky!*Lwg7|qK_W)mY0!j>_~I7Ss%St~Sd)tHgLtXP
z;HuE#^zvn%o4q6TuX#kLkTtDb`gAOwW4^7+_eOCGWYi~7_|EkLN8<U0Lj#&qm2q+=
zqLJ<D70s^oW=#t0T6hu^Gro0=m-opo5tM`q26yIG2NBFL-!oEdh30@xzKV0|uMP#)
zwEV!Y+if)~5{f64z!-#qsV%q&aPA0&ND^&T>4=E!2(4bh3Spl|4ZmW7OU}UFTQ%}3
zY~<?QLf#z%z=YdynjlZnb$hacc$3IavOH*#iKxIM$7ATWC_W(Mdw>xZtFFkxVNl*I
zUAne>zJ69>@+;vrQV=Q9*x`Fkqv>(pbcURIHYZ0zGTXGvIoBxTgPHvGh183O{hik?
zMsv`ba%UnmV?1MsR@&%d5f`yIw~dc&!|#gMN@RGo(XcBeWg6SIX;*V*-TOr=%gR7*
zez$I;BO?_$%@l7$^x9tu=T47JPMV#4_VYQh+VDe&$VPzpv_s?OdbIOJ`s?sVQlC?y
zNyy3g;$G%JW@D64!|2_i#4PDX=gUcB=c9t%%VxVSz`E7Ww|PISmHy`9^$(32YoS-0
zACcI`uX}SLnQC1A?)G&Kk`32CxaADFsks^&vu7W!8cY;;^A{ZSxdmK)BQ6Hb!jr#v
zU-S{JNE|Q#Ddma1*JB1}SJ}2-VYIVPIgoHb%i1yC(8xR2>&fjQq%Jb}SCB8S32e`8
z<#1tZ|B0G*AZ*-Y#-;xk_$RDsgO~o<gNyV`$)26~F(1l#-VbixAA=U2HI)xSd&$PA
zrdEJn(tO5sT(Bu5q?XsmmJjl+S0da@T&}lSm?2jUra|}x(pNISiq{lFTKT)fgij5J
z-=?8Vq!G7d(Ac-jqx{UFC76E4xb=IUmh5e6%`ttxITe|@^KqZ5&*z_lGFVQB7p4RK
z2dHjW4VJPBD=iXZymxJ1qYLQ;Wb<2ij7reteyrljBu(|XTl+=It8kFd$76l9!>7!=
zXC98sO+r$S7-vumO-Y;*;0J?Goo;^QIk}X%)U+LC083_(-VE+xL2?-(St|{-^h}96
z-8Tc%Jh$)6BC2)7$SCeTS0}IUoN@60W=^NoMws!PjWf%zWS+xp_@#nw1A6$bl{9fh
z0;*nJMK~BTT~5z&rHea)9-oeekfItMoTEBs<%y|{99s)Z%|)=a^v)A(rY+jGe>GYy
zRxtaXN95+_^0|VVJTCX2p1i@g_#-1Dw!oHptHqhx6WC62BB7`AO??Raqle-&dO*%>
z*vs<^Bma^6?@=$e=gso_7r~qCm$R(A^Iz=%f`PYZFLvm@N8~VF`V(t+-RK+7tCN@4
z5zrXY4na$azMd?wL(d|0s=H#>76Z7}k~OfSJo0Cb>XS>C8{u3k?Cv^pk`{Bk@?W+Q
zaCBgTK*t?XT_(F!31HB8<Y{(NiROA>qp?($+gwpqY{FbuTbxXkLk92%TKwQ%2@iJe
z+AHA@ksB;MIUyK(1!#TaGaK98y%2w63OHbfUt{zEOT+k=D@`>L9g%{$Q!Cii!pST3
zk>vJ*c~AK9xi_><ChBnUvz?o@F16O}ssm{PTyx(Op(PTQ^u~WJ1>&S3fg4pSzj_u;
z#^rXmb2BAT;!Uq)c)7_pr*m*b2^&m-Co;aifukXskWa*NtR@Kq%v_*TzSVeEZy)?D
zQ4XeT`R>GCIKg`zDiS4}M4r<k#qIiGUq?r4erCmbvd*X!yDZaoayp{khMxHvH7lg{
z=*Mcx`Y#|IS{*xj^i4yiD+~*g`3c`T(B06ulk|Im7x%Plg|a^ADfYxUT~mX<mMW)Z
z-4!%M+qfOe0YYs`f6)1yce!6)*|{Rnypl9Ols;gI)=tdl`ZOy9QP!)DW7LGg&l!Dt
z$yUNUNUMMUi_8(?q|f~<y0ecpjX#Z0!wzNk0;JLpGVg?b`ucZG;LDP_>n#)D4paz!
zsBZpVsn-{0LO6R82paV@r{*z?5|uX2LLGO^rAcb+NOKAIrZ$;qi#c=(kCtRuw$OV>
zfG9@3XK8Zma;=4qpw3FkLrmecPWh~+C7e&B_*C+n;i4L4`BICc_iJUOq3>(8IW&_9
zidogs#;MeCL~Q~2X(OofUn_}jLLCjYrc_@kaZ@)gT`>Lp*6(Rx=)D9MF{U$gVizBP
zhmnP+VQiqZN+CI}P2lRgF{IQhNw4Q<FzWS**~Ykz+4)tf1d)n(7{<L8IK3Pnm)=u@
zSdV`Sm^k*&KtX%7$>gCy$t&VwS#|sMn<9(b8>r_;5jQ3EK|v@%`%P=I*-{B!JgusX
z&#%-D&o?tO9x%z8wxIO!jvuSeq0Tq%4+JpWypzk${UKcxfS7OGyHsR^;ym>;u{a&P
ztA=`MjvTl<zmK)`U^!-=&t9I-{-DVo&)32a>65Ces-?iQQ9Iy6ax}0na!j49^Qrpv
zAiACD#4P{sSkk9Wp%PR+I>Ckm@FTbyyj{-#9Rj}i9kwas^@TkD_0Re@KFKI!`4`!O
zb7jg!<}R_XoVRD#LcbIq&vfEsJ9>Jqwdc;)_8JA}ZK&cn)^Wob*~G@c)o0Eel$Brw
zsZ6Mi;*r;n;Q!2l&Xz91iNJSAcQzF}=aNItU79H$wG;E(h2VJvab!5TL4(1MWP_sd
zYyxsg9J1)wnr~H6l#6ZCuD=f`;vmYUoK{HMi|C)SgqNmR6Js{kPMS`WW5l+t8}u6(
z$j>FV%I_u7e0s4Lk6hJ=sobn>Z&y}rND799|H{hlal9EX^NCKLJ1Bn``yu+?DS5Pu
zD5-zL;8QLDkckvPDNZ4pwTW#QM>a~J*&oZ%_%t*!-u#fXC_G;0cfXe$u|RKeyXG`W
z`qWKY=Gw{SUn%fn3#ROBOXOj6diDcB9!mG7)i=C$L!9)V4<G$5QoX<(XL=p}m@-MH
zblAVs$~Yo!M}U+x<R6mJEEm4$v%V)|=xCLdwUdlD#iSfhoDLotcCTem{_RW(CMwpo
zpv;#aR?@+^j%dX4H+2Xzz0cvs-6*IO433lAbKoUjzY*nB&$Rowv8=XR16%tgV^$^b
zNlz|lxGbQc2b<)Qnghpl=OM%zBC21L?i#YAwE4Og$U%bd#H*!NKggDu%7*P)no_ke
zF;q`spr^(_HR07ON0}M4deiA#fAC~sH6ig)$vME6St8d(|M1H*ntb0PasZ!CFNjyu
znb=NUy=zSqXv0G$f<Y#n#_Mk1?{h$+S%baNl(gt|DDd)hnf{x-A@^K?4!qucRhQ8o
zy6lPfeAETBds=MuBOC8@vU#>*9t`e;9^FGH^GP-aM`LGqZs%Ru{lrSc&UqF#)4G<L
z$@Q2WkBtnK+Nc%0u5ifoP~dc2vo#q}Q`0A4_?z#=N*HvJG35O3WLzrhf*cETwuJY#
zud${jg{?+(AX;B*n6$CcR8knMB0d!tx5a-j)y=LF+C3#rXX8pP5|PD?m?W)Au>xp}
zJ+^oF57)qSTDLy`Qa>!%@h|teQ_&sb!<GKwoTgqc0lZiZG861E%B^Z)?3WLt`c)k|
zoxz#k)&Go|8vJNe5k94uFK|XLJPlHh%D2$3Q~(Pez)kr$Kj|dumpS7$u<<9hxz8j-
z3J?(KIxK1hyuTevL%ffuXb4W?dYW3rhz7Mk#x|}mn+^Hm9OBv*__xAr?q9dM0k4a7
z`2<}yqHg<xqNR{!vSWdtI`3rNT2AlHFq3@&ZaP^cDJ0x0?qkd({F<%qE}^v*zDqla
zl#?O^5^H$x%!!Uim?;w$Xt|_fVW<XFgN<A`^ofYX=a4P<F+l`3$=q!1Bc|B`oY>cy
z!rO22&WkEb*Hmh^sYi%~goq@W<8npu5Za?C<&Fle(B{!^z4ne^BtLn0ZhCh%?khs*
z42O=AMU*|@eh%z`NVAF@nx$O|SF{A)rPpdO02pvbjjbzIwA!DKa!oxyC?6K|f5<WP
zd)ch&){6JR)O{hDz4V<U<aX@SbWZ(M;8E6y^MyH&ENA_9E%aPxlxx?#)XFiNKz@K(
zAhJma=)OHOyFL)r|Fb{<n9E_4nMgq=K3C`B*%CsA$2VP6o;1)x7D>4kt?${gK`&|)
zldBh`OUkX{S1sgZJd8Ox_1idX#&n*MUSWrW$dhnefn*k<x!Hbe<`+hIw$<J!TKTlS
z{Bm%5l@oPFqxW*|x4F{VbhAzvd)H3791lF6xbHX1IdxCUr+Z{u{TPGo92V|r)mYDX
zu*%I;+EIG6_9a>&{dXZ8t8I~;<*4sTjb*<}76`<*z@ZZrRy(;`4Ptw2J3;^GrmeHj
zl)<~=*`b3rNnq^)jCy{cLEd2kTHB8D;HlPK5nbM0=fa?}SXFVk@P(UF-bNV?{<7h9
zncG>U9*FyHUc@(RI_h2V#f&RUGK+8JbY8k6&%CIJPu*;>5?fSt+LxAHb;^W$%n)Ed
zpYTM_vtT(Yu9AAI4M@4w_NTL|&llS$l|D5|)GSe2V)0V1POqA8g2nS;l#@@~$x&iI
z%q}mgPUNPXpWX+Nu-t1w_8iUSr}|OlTn?;zuTPI>a_Z(vM7L!XP7E~og$iP~oxU@D
zbzH@*{BVK(U{<>7$&l)XjH;$<<dWXGab`XG@-^upYr=@6^XpLd+rGeI;EWNLPxpY)
zb1WV(|6)y1dpU?rq7||iX0K#cY-^Ere9VZVqB}}2`(w?b3_PVB(3)V!B}m1-c6WF7
zyqSrxd%ONg^GeWW<IL=M0zt6ct?lBbLp{IMp9_rnQn}()L#XfzNz5(y^wtbBVD#l@
zjJ$A=f6m62&{wq|;ksgKMHIDe<aTmS0HH%MFcDSOkT#oIH)vR^EQ}B3z~RG%o=<fT
zY>hH!(W4Zb*EY-HprZSK`tY#Ycz;6gd>lrT)#QEe==tRt=PkhBf(If~QG^{{mxL#}
z?pq5{GB077lM&U0z#Q$(_~i=2i@YtP2;6H#CS*wLnl~+;Yr<~VrZaLdF!d-JiI>Z-
zDD)~vm6MN<C)Z{BNcHY}%yQ63U6E88TpunW7orSaL*U*Mn94t;js4vP8yRDL48YV_
zBM9drV?sL!u(M61Av$XLkir+K&VRMAiNKZAv8!{;>Az@40l)T|zXlm+^zm+BoFW?U
zlwjJ18d3`5wyy8E4yPalv5v4QnAr*>qab;AoSjnN=+ZK#O*iB`T%(#3`(24@Y6-K*
zmRL~FY8P9HlB$>Dx7$kC;RK_mD=X&70hnif3-Q?7Xs;{d*MQ=IZMAK;n}GHq=zKN=
z!W#PU&~3UvU!tj5jxn7XX{O0}SO&vV>rSBA_?~i2$t+qFItXJ<@M2<luY~@lw3TZ>
z1{BcqJ@XTzKZLf+(81ilwE+J*efyhz{$J3*b*I*yLJ>{BZ(5stbFF=|0wkcU?#<#X
zG2h6D+m4<?D_q;Sbkgf1t>x=mx3%)+FKPqJpP^MuFOiWiofdJSXKYxv))D@Vs|ccJ
z<JC}lmSV*p>1UbsAdsMqtI_7wy52owdbU|R)X%yvs-v7OQ{R&}-a?u8e>nF~F8bdL
zdkwJ;GTwc%Z`<LBHr0OJ+$3jNab(SN3@7c%HCz(Vm5sU!K58GK>V(npjkOX9lASjT
zvAV6!-XQ~rBWf`{sa74~YO<WbRp|TChRdBOnN+_?Z$2-=uITK0*XhJY$+06sp;OZJ
zq5{s52ho*0^F=HT*VUX_!;>HXWwd5Tn|msq^@@&AoriZ>kE-3zHGk)kRPDb^-&~$|
zn9aQ8Wvl|I0Fva_yh@d@#bYBIWx6-6TUz+V8r5!Z)ss4>J&=p(yR>=E$SVM}c@@}g
z2ceWMuR{+ynKe6dW$}x%ArIql6+w8t^h=yrpWT<WE9Mfd-PD$IpRBQ$Eqo=#wdHZb
z3RND9@s%p^!qhAv^ukDs6}zviL@Ka9lbb>P&bh-lnEV!pnS?*i$Q@g;tB}&;o?tdT
zQi?;ItP+N(Q{@OIJU6i$anhD#lyN+EAxk_>sB4N-!KkczxJr`!(tVY5LDH7Q_R}Lb
zzLEX57?fTQ*xyKNd+2q$&2o3#sVT&_`Gk;|v_DxFH%yz6`c^;Cg2NS9K|Fg(>r2>m
zt^WB1ve$@fOZ~&|O7Y%|0Ol#@WVOW(72y6Naj^dMoW5wcuHE5v^Xb;8Cs%(2$TD-T
z({B|0bWmEX;3*j9*4ycBdvz+-@6)mz?RWYC459L;C!X}_f!s}Y;w^$aFMm~f+b;HY
zCi_-|p?a%(Hj1>lE&T3$8AkJQDJIVEy*qMyzF&}gYTB8h^n3XE^ImhS;fTeTmG-RZ
z{w(|IiHF@Q*7HDm)hYVw8aYBhbt5<A`LMdp8XG=?a0d9$eq?j0H6W_*ox9WA=5E>&
zUgvi?uI~GsnQW`KaUJ8e0gRsC`>f5Lm2TJZ)(327yV)Hg_?VmRdp55i$X9i>Zkw-T
zLhDv?SoVRpZ*;#aCkGQZ%9PVZ+ma%`cL?p%G;}b&s7=p@2crsi1ot4;o_NM4`aO*`
z3SF0f1EpVpZ0-q6Te8@^<YBzl{Vwadp0`({pN<y6zQ5zU>LmvoWd+QVc=NwMT;a-n
z0UO`lJNd=;1fctEb%O#N?<zN**5}q-fMDHP^cF@p?PEs?vq4aPTYfWYf!BHbvlO87
zAwuTCjFB)-AjmwCPov3snQG&*pr;{-4Xf4l+$6<4N&I}rf7ueql}*dHb`yUlx7Ysd
zt`S+8uVdzBI?K%V$w6Y*i|dlp`;phw?L|*~k`3VN`rNNCsO081$=2ze2i|B;t*t*>
z@9Uh@y1C(Zf}B^%dkxN@KR@-z*rlI<&ph@|OLB!e?{a#gX1;<TBgr#nVQ`T3oYjKf
zyTfcBBipmwvvyqg-|JS&PF|!qH|9tiZ_Af*vkPmt^hQ2!$vcUPge3(Dr1iLmH@qmH
z<)>#u(tamKWw&LFL^RAjoC!S7x1UZvT^&5G>#hgjI3?B_79yF6Pm@n%!pg9fXaol3
zHgnJ@@%{i|U`I-L;C^zbNhC<l!74Z$Q3{Kv=ph-;sIUartHZQGEH%D^PZxUt`+CTe
zM<h5m2C8S9^M#G(;f^%D*Mprcx9O8&8(N<AQBT0@^lZBq^GUX1A=`+jz37Y2h4vO(
z9%K+M=!V=*<pw)P6>P9Iv)1v!PMe!;l%1dh1xp6^efC}1-Zz0Ivt_T`&1No_$y_h}
z>!*R%WZzP{>#6Jo99ye8p$9@Qz@~caGUR3s_RU#sq3`ud`Z5m6jRfgZzzEGvJ0!ww
zHu~uya@i-_=jxk4QQg_&HDMTz+ZCqV{@7I1+f~!vDaeFTr!NP}=A!af;2FQ(6ZW;V
zfahUt62i^Ti|Tx9Y%n_)RZvpIfbx>>_Cc5ezv*2crPmKXtxD>wzDcadtfkwocK6@4
z(R<}()arD6s@(L_s1B}Z#>GGEN9FT$#CJ3uaB0g5SeSyaK6_w9WXMA7vhVkzsbQ!#
z+#%~}H1W!nFn4>=zIl&!*_x-b(C|$nr~w%lc^huPdi_2hB-I_c%w9OF)p<c3Pn0Mz
z-RMje;ti5Pw%~Y86TO((t~5>OR%LHttDn%wn32lo3YA&;vgDcHX2tcdh%)NG3~%U8
zU%ea(j;Cx5?YQqoc+e+or1Nyy!p!<TN2eatr=#zcS9wL7em#%X?g9&>UFB$(xaC#Z
zxH8`gnWi>-KYz_z_dPYsz5}UO7m(!FR?GCut6Mjl^9P+W1HPLcX}b5j<Kpf#n^n$a
zOQ@rH^~>W-AnlP498<2<U?I|9YwhWUR}{qD_aNpvf=yKUZ-%p<fJ42-jq4tl4~1z$
zKG5YtvOV!f+r2heq2k8klaHqis^+@!(74ULl^>+`tljhUVg24vp?O3`M$_*`TD)|v
z`<j9AqCm43Js7%lY56#xO@d!WI-2KbHoULP=_h?=FF<%WblK6qwZ4Pkc3~v0WG2`2
zPTY-Z2_ZkmtoT*n<=KGST4}Z)7aB-!FDl%+^~%)bjKt$sbW#6ta4ri$s7AdOOj5j3
zEHY}jEj8J4Z)JD7REt+kKUL&mF<d6}vM{-T*-#>1{BGMttVx_^Cj7i;O(tw!8r-rJ
zNL%lSG&QC_N*Z(_&=n9(t@jMpjn){s6}}wG4NLBf2$vYWE!#R&&(_-ui%mu0+R$w=
zydBYh{tc$|^L?T8awB{GJea*_^Rulk;o7WHrH<akUO)y}I?0Q4?*y%QFgs4$^ntm<
z>vG=CkBZ}dXkBJe@mJM8aDNi?wAJX6vL<kS>eg}DxIDP=yd~4bc|Wl?-AYoTr*nDU
zIQZG#=He7e+>J+<uEwI-wJTY!>f8$49A$fT`svT_oSc1;UknGcW5qd+(htCHR)myn
zcwM(%5c>ICPpbMDIUNj=`W%Gxy1QL0ChOBR=%`kxxJr*>RPywc^T#Ia&~_w$ugu2Q
zmGfBiz$&;KX>~pek#Mm2c<vbcW$BSG`~GNe(K%WGP55?cN2vWN&GkAPshqBT1WWYN
zVU$mZXrO+$ad5B(eZ9#22@@zJ=<m1A`ux`Z>`D72g^%}rQiU~SnVz8B5kZDwe1bhu
zLeA7@R$Xv-k$77($)vDUX2a*h%K)j5&B)^nIK6UhNw@lT$RVh}_j2f9{cd8t)%R{B
zQWxiz^j_!Yyl;IHvOW1?iiZBYzxWZIU`;=Rq{(@)v&~WTR%1`y62~pULf`A|WUJGC
zdi!4X+{UTLeY0A^&+*-(-=NY*m3e`Yb*7eCYe|_>Jga81EQ(XVIY>}8|Lt}~`dK)*
zGKnZOV--ig=y7;x15A>=23e;0ws^r?rBv~=LRtJq+b}dD<Ae!wOZ2^R<2CgRQae*a
za?jtLr*lCqJDqs;xKk;w>uzydAvJE+>92cV`5h<v^by@|9#-`cz^_<;CgiGmM7pZ(
zsVAUvjG>slt|Z#P-Ttymv*A(g?OpSPtlw8L<|2vS{Nir8`7{AsJah5eTA!Qj^*bN&
zJAcx1bq;4z^-No70^vledF<oqrkzGOIwF~wUcEG36`L`7zo$-w68|;XiIl0bw%6`{
ztgWR_6{<F|O%0&5`nA^O)n@dLWD&a8k?^<XYUam2n_5T&4CVKe`gYHmcBpOfJxmO%
zPrUX5LBKSV150GL1RFmRcbdfJxm^3ze3lBi4kr%~jUE4$zIJCGM#%`t-a6Bog{|cK
zRz(bj;+qYbEz^m525|%mug87DT&Gsjj18Z&ibcI<N6pK-Y##wG_&uFHr9+isZsZVd
zJG4BU$f`qg+v%`6rAp-6k1ybpmzi^*f?p{;Gmbco_OJsj=QkNtEdOZp->yh4-z_r6
zr0l?_Jszsu-XpUeD$(HuAKc>8kIbD26bh<f??U0vU>B9AER!PTw`O|YTn23X{8v9Q
zjh{w{{OPA@*l<Aut^?c69UN_b$#OL>i3A4HJiq6Mm-{0-fy-~FOlvoO`kl91Bl|Rd
zMrTP)$G-8~_viQYT>4%ni{mGYZcy5SnNRTfcam4|>hCu~n_+cHunxPG2PF4b9h3at
zd~%zoLCcg$3=EnJd$7KPF_K$Ms3VQ?w_G$N@0zlD%CW&KwL!eC#hA8`#;jrN5e^L7
zO2oEy7B6RnB!;Jfsm~Ao`lim>pz(R?e#*Q~?Dn7yDO>kI?H841H77#(O`99*UeI)A
z$X`m}zh$rgsZRLAe`^Bv4-R;&q0)*IE+L`Ls@xy%NB5fwy`Kl<)ENJiR;usYt%=<?
z+`rzoxoKrExeZ6YylkxKgjVkQdq0HCH=@{42-1svKU$#5cngep1n;R(Qc!3uo*cO%
zr~I$>Jb%Q=|J)1xQ&s%`QMCN;c8(Ur7m|kvjsfyEPdO>)t`1=jU5a(BlLPGr!>T!q
z)ZVGOa$L9HDL!~T3K-c7Ivr}(6uoozSa}3ZgKr8y3-xKp6M@#HU+e4!9L1LCRg$M<
z$Vs1W_kG=HNXZ-BUJG?tHjVel)SbvgJpRm2*!H03{Q=?3l$ek7L0Lj?_(KRxvprW#
zuiIh#B?9TBjTX60XWV<f--Btv)2<T^Tc8m9u{pJoG2zyOfTQWTeYp5msbbwGsPX}~
zmYr(?^<DBQN9yA8-rBfo)ZN^%7i+z0{8P6=%JtcKpE9tSE9+V;C;8!WAx!VsZvksL
z>e7R6pmv_Ffv*v&X#gN9*~4?&BCTTTsP*F|B`Mh#uPgY)P$|%><|6eM6MZ9kwf#C;
zK@<sQR-A-+4Tu!69V063MSJZli6l4HNA{XrLiM#GK1xnM9xbSD4hp|DMW05otV9)U
zT0SxceuSk7QVXTJL^Q&73?ox#GnR2EAx+L#q)|&5=zmWZLLNjG0#p1`v!7PW`EW4<
z_c~Xfy<smM?}vMs?S6Z@zUV8irx+cc;r<6DDlf~HGVqXUtUXRTvrrlUfccC6Hn@El
z=q4C0Ho=o9)^z4Qx4x|w+n$JatU5lK=vElBK2GSFs4!s_ZX=^+O=z;{io#2h=ox)q
z<vw$F711#ETUz9-8=SQzIBh;Y7Ve%0F}FLoWIhr54?f>NrsDG-oq=}7{`&YtWmBh>
zJ3H+#LAv1np*hBniLrAM68zKb45@_l{&#L>0p_mxi_G<WLE`_RDbQQ<YMmrZkEKKD
zDQlhh>6WEqZNm!cU0>$O;0D$5fhJ6I4FMhy%Uh3lHl=3OWakE=4;p!Ovq~q}@U;(j
z5j31`&eDZeQvXw!Ky{jZatQL6;p66spE?d~7PT#(c5xgRO^Q^8G#UR}g3!m#bl!)5
zjqoTzW7rZ{HjU_n=G3#Y06YEaf9fZa*~DegA#oge;*dkUNJhI$6H2|7^wF&S#4H5q
zT{|o^sXeOXV;Q|$RaedNFU23Xq|*;b<z&R#8E=EdLm<~SdI}+ryKl$<HH)*IogI@D
z6&SzL0<^B5ba=>-j(}~y)bDrO3YKjBR%?tgBRy|}W`PLVLwpuxSghK6Z{*=D@v=)q
z;=46#MQIE@y^H2cOON<YXOOp=)|P-?pNVEx(~wK2bNVfuy^D5~f=<Sy%HQ~r5nSki
zc+zP#TY`<9ZbOwrBGwhh{$leJTnnp;8oh)avz<s-M*RIK2tb|g4@7{zfZRyYnsT!~
zi?_Y3&DHIYjD^BR#`Ih;a$zBw;8u(M3YoA6^XLN(k<IlHkxyYJuk66CtHPp^ZjoVO
z{=zV_De8H$v^DrJL0Y{cjEY}yc#TV`T$?;@7+dSnOfHiWEr2Cn*vjpU_B3X?V}Lwe
z3(~Y3%)7Qn%Nr?kbS?I_zR(gKzy6gWqWgrt<F)4+4KpAmMfCA7Bj2m9IAD_Sg27bj
z>!DLQIpeWJr@6I9x<c_u!N|e49L}Q{6?w<vj$IdhljM1#L^`aBy8DY<TJ_1)hBm@+
zS0ke?mrbS4>IOz$K^AK6$>nSM&qez`)p&&Fsl>?J)48tbvNIMjRx=H>eT^jHtSJCX
zePfXfg_i~f)<+rk2HrD!j<2}=ST}8X9NUzt!ptkM*BB)pCK2Y&9DW;aO4g3%hv@c6
z6;8XfFt!d&>ns`s>WVe4@?xgT2o+U9BOj}_I38`fLbM#MFms@#Kfv$zQ%Y`r^Ekzd
zI1v}}L{jkA4Gq1(h5kVN*F|S%Ra~34ym3*T;|xp3C&?{k|L9#%jbolz%LS2r^V;X7
z{zS^+ib^XsWLHeo&vP8a?{o%Z%58LNekG+1<TuGTX1Wq&@-B%rMIM$mM#@hx5o3?1
zl7q*F^LnNZG;OrhI39wkaVFprfhw2$igVP&aU)Vp^T}=C(zBWoO1J(%db=zy_PvkD
z_grv4%g5*41nCsK1bV9*IFo-;h$JG^r`;D*|5yA5FF`pbAvCW&W1R%7*;I5J!<t?-
zL^AgHvTFR=()kqnUN))g@nEw!wRl#q4_b~{vZwoFd}uxsU(5b<(O;}Gt3xrSL#4mF
zEAy|^yiuYMY}ps5w4Gm)vOETf5LErla@Lb%wb5m<ad}nvhTuDy_nhj*&U@9V^R6Qn
z9E<`S>DOCJD<Rf4J8`J>bL>q06vF-}V&oy@AwLYc>lt7ldSvNPe4a;Nj%RaxuObE-
z8f;5ENHk7=mR-iENY;#W6rEjse(#+>9(kP2IZjcM#v9Fnnx4KgmQ$izcH^&<l5Oew
zuXz+<g1``}g<OqBE2`lWh3Oo3;U_^%MdO~8kVcw{5CIqO%vq+%!L+=c75Px@TMVRS
zI6iW?jZ&LLi+&g9tFAgUy^Zms{z%S~(5Gj+!q|XGwcfDH@_`TG&{1s^_+JflU2Z;n
zdo&_MLsJxK>@g5{jk3Hl@V+$<+B&Ilv0(mg+CHjJNgR&dn!~E7K3RWFQ4yuQZ8)vP
z`yK}M0W}k%O0>gtk2x))go(d#IQ92RjRNFesO$#{)SDybNfePTl~tpq3*9b*^-d$E
zkBy9mYZ!Sl(d-_{(@Q6~rl9PC?_p_deiNB#6p>~)?4Ed`RG1n^%v%hXl3c|l-C^<n
zBvz#q`W$bEq~4Tzda5t$qwd1N=}uT`TDq2etm5daJQmOib1r9%+j}PiNOM71<{iw3
zHfCaV9*4zE%}pCE6a(%}OaU5+jze$)$-{MlN&II&RiKXCE3UH`hE(H3AI;gJ3brjm
zk2<9O4c~;degd@PnM<cVAZ^~CM(lm7{WFs`ZlT|-j<uBbJjXQpSx;EAnNq6-4HKXu
z)SQU*enV28P`!<~q$Qz!Ml~xRCWw?Zj*i9g!;t#wCLKG33FDX#XvAcy#RxSCKMRMb
z^^R#g^bn`NN&m1Mc*KEFRi+OwBj3q_b-`T!)3A^ZR$KI`BtbG+Nei1&GpQQNjMh|m
z3@z|5<rlCjKFQqmDi3$?DhFWJ^Dc?w_t3v|<otO6WwbcWuGHtp;}CV`f0mv79e`z3
zTGhi<6M=RM(<P30NC+xn+1VdBgyuo=wC(AfS9ItZ9DM_ECfaZP36g95+;ax@Mg%pS
zihP?k=%JYuNF%eb2aoL>As-h-6A94*+uLIXFo}7ESk&s|Bz$K3KQZU%Q4Qoi->hTN
zKT#C+fU$7}ysSSQ^L^`kFS+wYU%k1Q`qH=hf6|*R8X#b-R5%J5YeieK4g%V|K8W-W
zy{QxB9vn=Qyq;IGR6N7W(_KdH%ORaFbA*y%NOcebdnE4Ye7OB{(IL-bT(n`rftDlk
z%Q0R~-TaIOUY-Nh)47bot(S>8isM{q3{udq$=cw$GLx(MvA}ufT9sGoE_D^qr&78`
zMBlNsa%nFo{%a<p{^)+G0H&VjpPnh+_)O0sr20P3*^|rea9$9xOpw!;rH(@tXYE4~
z%U{$SL*lB7>rU8ib1qP?d{-tsIK0KlC1Rtg)XK{0jF{sd;>4@$qKxht@q}TVsk*`8
zb!>iO-%J#Bbc#wG^_EqoysdR6qAw{6%B=aa|Aa9`y(s{X>FKEXsLwX%l4NskDIglI
zDQ?V}GNW7!PjndR_U@%{Kep+9Wo{<0q;Iv~H*f6Z$CN*2m}itz)@`SA)vDj-ZHD&K
zvr^c&Pn$}Mv~`msb-i3+l;_h*pN0|!s*Bl*wH0a28l;3Ixdf+>RoWY|v!n1bWzY`)
z0?K=Sb!@y^64S3bPx0FocPsvDHe)-0&Ssuh5rb-$)I}$ziH`s7I>~=`-S%HyH@;u$
zGoZ&K5){xfXP29pmTj3;fIZXdAzFDc?15TMTL`&PY^bV=X^)qsZuIT@M0?r44~i5?
z4sLmXof&;CbS=P0iD>>!`q!qzJ1v;RS0W$F-ZQZxkH)|R0DL~Nh@T~`WcK8IV4;T{
zy^U*?1faZ<)>X!eB|q@~B}MMvlSB`P|1BorekQj^{<1}ruBy#I4acvz4;Sb%?Tmw}
zN*+g(<-UEfH+m#)IN`>z$Z72HsLI9^^b1$shzIjor}Sknc49l=!zT=bw`8vn4L%2}
zYJ3f+LxJ$l=9pgL7}9fKsew$v5BXULYJZ20<R3&}QaNXd6#rEKQN8otGQ0X0lb1M_
zUP&!<*4vv+==os1K2_@NsHbgx@~*60wshWhG|uF;l43X<0pF|n^4>wKNHQfF$Xa86
zVRhwV072oXX@}@+&%rk$(kJ7k@0q}g%lHMYnl;-Ee9wm}A^0!)LQ7+wL28ATCkjT&
z+UZhFPJe2ndwsO-o>2P+rfOW(Oo~B)VL`^=Zm1*BKIT7ONF7+cy84)n;J!3tv(E`J
z_@l$O9gH(Uz=G!diD{GmMSJ}-f%Kn=qENwbxAYU{G-F)^I+@5{ih5FC^0;<gQ2h&Z
z%QaFy9IJ{DQ!7>6sa!I{%SH1iqqW9muVXCRy@c=VGn0B)XIYZfPhjl|z>zCeOJBc$
zJ2?!Rx;nam6+-kKy4@KiRS-rKMf!vW`xYR~<hUS)^vZF4)LZPsWNYkbaK`6d48YKA
zj7Zm&VfwGIRQx=$UGs^w*%;B7!U(sVIqK%|eSwaPunhCz`HO(qh%#!4nbbdwpJl^F
zws=Az#HcX%y8|qsRB+$iA;Odkz;ld#6D{B8jHsE5wNJDkSYJ*9BlCanN~}qu>qt*e
zy`N1o-w4OssLicj*zWQ=R6Sm8Zy=v~mgJUSZXRy#%I2(5P0YD)hMF#h{c|%xNhaY#
z<K1B_J44WC48#nmXh0Z!*_7(0{-^pGY>hEqAv^T!n$5*Ysfr({>6ZEFj6clKk53#4
znvP0Cfmp7W!M8g@pu0RD4o5lMW8T`>eDJ1kr2mw1($#}d{wDOP6`I=ESIcm+xGKN`
z=HJ2R(PndWUGpd?6-x40!#ZD9(45G0(&e_|<=DndYilRT3|*#^u&0Ot^0U9o;NWwn
z0GPAOFi!}Wtw7s1B0$Q<8getu^UJHxW6L_PU~uQ%>&*^(0{@eqqY`);|D*F?Mta08
z5;}MjNI=TSgCKYN50&F>asX%4;UiNTy!6)?=uw<#!%jAo6Ub)MPQM)9oEw}YTWJYY
z8?T05_GsE{NS5l85>M7Cvg3d8p8#%OW@zyfzrW`v@zF&-!TBp@SgB2wX^3-lL$rwH
z`668+aDq>qS1k&siv#2WS3^5IR}Xg?0Dl8!qs*?mywOBjOt`N{*UJpM8;YCOf-`?0
zap50G3~PV`(?#9$0nl|H0pm6ryOa1`PRuDEimhk-1Y;H@*Qo(S<1R<0tx(5V+<nKU
zXVy$HPbs3(Uz^GFR@s%AtIS`!*qC-R<#dO(6o~fXv6Utw4cN>_Mj#YINC2~flTA0F
zt2sO5f2GWF1~-%l?pny|Sc<LDli6x|w>Q4QAcOq^&A}zl#h1@N0sIYEkF2=!>}6e-
z=#XWSRI5|3j|d;$`rY#Xjb7cX#uB$u6JMkofMxX7ob2(=sXH;>kNo7F__4!qnDfdC
zK&P;#M&=IDNZobyb2lD)eePb_3bs}am+oW~IgD11x}!6*J7D7SEMgKiDo901Om06p
zz7>q{KOo$4gyjDa?xmI^Ea=pP(wE1)y5b?NJ`~GSVW&?pFKL{nVPH!5)~upBJuY+l
zg&aTEzXY~ttK;3lr}$V>#6MJd5~?vS>x|Ajo1%;#Try6G3b$Jmv08xjiVFYc+Ll#E
z;XpEBe|DGO2K$+KL8|}&zTThr0$c^mZrKPKJI&w2KV;hAB}v2C%ohX||AqeK2Zof0
zKImI1?}20EG1M61tGuHT6V%IyWGVRfqPgWGWp5gKh=V73M8AiIHWb+0y*J~b5U#-9
z<m@rQeN{b18?aSute;uj9jZkPqCnZ22H|qnf=m9T6<hrwQwgyVSda^^?lF!GhFxx*
zw*T2vH(>emZ=D)e^_@ZuVt*$`yLEJ||FBNG5({)MUFuR#)EKHN2h>w|nc>Q~*KYZ9
z9A=W4^*_W`@tQyX57H&TE5#kh8+3)aCY@$ERN~|Hp`j5uC1XIC1ArssIOMVY;tG)W
zlV8BTV?*1iNY5i)DZ}Num!y)&19ygdyJJXrM{%(~$0~~y%~&l0O_%73R|kBxlm9&o
zA>^|eij4~=VBFP5*x96Wp>Jabntxet`sl+#)$rfNM>Eljx6UM&cc`Mz31rl=;3Sgt
zLu5{p%jmX4_)V4wm@d^?P~8ajoF9vd>h{eHkcRIu$^|vqXd85S!`pf;cCj{XTd8*O
zUR+ch*v#A7Q8m3LC(UtEbKIIXL418zhv+Abu@n4I&|tVYY*|t-mnk9OYh!3FKV<<d
z%vcyBi9n!~X%ApElZnt1ZYi;{akz0q&8U;c=$khV4h=mF_%BExKJ~>w4IThp?ALeR
z!og6(Q2Zs8c@1b{pPMI*(bIcwef)&T`DLEOX>n|o?$%Z;7{$1=kNq#yFfyawV9NEy
zoO9I#hULwN2l3q)xY86&Iffh6(>8<Me!0NC?i9E;rNbzgnA4`Smi2$mScz#rh`)*?
z{&u{uwNw8YjURf;l|j=LcmwhN$6^arwXC*4CTjwX-}q|+{9FT}1$-^a6Ezx|CD7C}
z8$Z63SI~v=|9J)de|y6Np)H=WaQeYYy;bMKd?i$3->)*o3r&`~e11IJs5L`Z{scXK
zHQ#|8t9Pz6+L7v;nv0HXEb99~xcn};Qjv1_aE0)5<eX0y7#Ha4$ZtT)y|XU=O>y)0
ziS55%C()4cVHabUg{<7d3DNNl^awUsJZ~-GLWw8Gl4H-BY{cU4*8s$bRV{j5X*??D
z>V_Z$oQA||T#tI+E$5yppu$3vff~Pj$>d&Y-_M7o@nkD47bM~F9QL|e3M>2^5=9bU
z2+1J%>oKvKqyMUJbS9hk{C%fKb2QZ{07qc*W^$i_nR|mQ1n|xg-w{6sX6W4DL}oaR
zO#;v~(d?+E&3_$tFVs3*Gmb1BY%%l|pgc+vDT)Sj4)V#*ccfxrL#BN*By(PLf(%gD
zxc|A6ciFQXdTDI8fnoLr6VvDLPT3K_!hc-L*;uzM2Ef?jwv`%68bkKvKRo#zhy@?P
zw0~@i`NI`(s^G%TF^3X8Kt8#^l@d9TRT0GsFdFo(XI}A^Xt7CVE>w5oDe*SC7{)7y
z)~)-$x_Qp1rm}9MjG)q#5=0a<fS@#~(oqQl8mhF=Yaj!J-a}AF2t{Nf(yK_3UIL*f
zRHY**H5BQ+h8o%zXV$!#wZ1oNz2EQ8J?oyk%UO4yd-mRU7l{En#xHh$ID8`=d-DX?
zn>1#b2|v^RqRkYNeaAynpLN@7CuEwMVrVR{yzD8foA0oY{VJIXnQF1JAhJgnD>6rQ
z-~pj>TD#J_vJKM`H?Jqp&`~UvRJ#$TSI@C%20_+yAWIgpN;DZwMKgMXt%sV?lVK-K
zOG#P=-RPjv-3I+I2ib4<1u#_22`Hk?@z6p+dK&qvD3CCzgj|{X?gkDr-};n9uldX(
zQXNYs<z|)(*kuAx-gh%^_x>=_&zWf&Db17GusnrFHD&Fk&U?zsepKZ6xh(0G@08{*
zkL5$%seZo2Qri)xdB8_a{u&1-vB4?as7iUY;LBX2y{&B7Br|Z58P~IOFZ2N~cHoJo
z8p8R3TaDya4H&IduO!L~*9|X?ke)4paqVb*t}!dS*~k#L%4ptA%yiB56Xmqp4TOSJ
z(PV1I?-gz#SFZM<-*VBN14tO(6%|^(7hx!#0ciNd?5=c6G#qfN;JYh=_kC?x(|m5S
z!hA>{agp^_TZ2<x-hH*;EXVauUad)pSEqVh0yE{Cr2HJZMBVvvbJ#CQE<huUPUiA$
zv&Q$GVV}~)JHq(2Pa9dZ%UIaJ^~v!)e%dRFLzi^Y!i3Vc`wIqk?e6QLU@iCDQIz!n
z8yG_X4f;d(rLU{MsZ^$9;3};-@9e?wBaWZELy&>Le^#DQRIVUVU3}tL7JNc+fR*tP
zBQzQ`H(n8lA#Tr01o|c8E7ilYs9WL!mHa9K;c^T2cKz5XXA8|6dnlj*4s2H7R;4)!
zIW2vEi>GT>NC>x+L5`)?LND${weGydt*=%Fdnh4ub={QboB^(t<vZT=?8tM^pEFD7
zO1+s7u5VNVG7BU-)B6#DX2#z}$9<g+#z;M51A6-x0LVy1VuX|?BgF*1{69s+DajEO
zw@DcQIp6Z?3;p?>h^Sw(vILy5m8^(Qbt$Zv+f=}Fw=az_!loZWLV%Q9NGFpjJ!+7c
zU{l$E-k!>Boc`gGRuFmECTi>cNBXVh{9@EJbDAY*==wwB!dPBfXW>{%xj}HKRG#fr
z1;sQ4m(!R0(cR{+W9O&K!Aslc9}^Q}R_h(<m%dx;y*ApDB9}muA;%sR7c8ZtqSCrj
zOh8c%vg}ub@P(d~{mCFD(nC*G0{whkGR0+Z5SaOMBwGGg&zyf`?)?>JqI7fl*Nnb@
zMzQ{kZXqmcafVex#TE<k6g21b@me3O?TGLGxDVF?kRm$j8n>CxxX@@Wiu(9hvVSEC
z{$GP;g?+-=FQf*VnjTNkj{+$bR_-oNCvIJ|@jp8O6&9KM$sKeQTae|J_zV*womGzu
zPgv1-&!{;9U^6&qcTC{yP(&%nM}X#7j&Yp0bpLolQ79jnK_nIGtp{Y=idDBZ*RK@S
zO2de46+=Z`DSKnw4)Nj6%L+1H`;UeQsBNFKA1>x!#;2u14+59C@Kqb)j6tt$R5K?c
zIUeAAU;ioEj59+0QPkVKI+FBhO4rySrd{izI^@+aUoQmxuu^%AQ2CJaYw5*uwN~W_
z*I&)<S7dQsajIo8Vf9>jhwx!#VOU%iPVa0S*I#P7RMvEk1**+*MOXJc?4p&J`uu)Z
z;QFa(LOV|a<ngmH9=wJ9X;t;U-#V$DMAyZ)Kap@PM5l76v@RBw8jdOy6>wY*Jsh|i
z5Omi!6DUt^Gtw*vP>GbeT3xK?|B=_}Chf~fKIEy%!`8nWcL6=C_|jQ$j*1C$p<a#s
zDSP<B2ZB}xKL#ZcSvL&;(YjW9W_h-9s1ee@AX>^jHCbe_LpzQcYF<FlgAJ^AclOaY
zchz4EgfWE)0zw6^{h-V8=Y%r&pVS^VK05v3i!Rju=9#5C_9(&61bG*9Dh}EmUzH$9
zZEdXiuS8BO4F=kU!S3$IqC!P9GTv}<exHM6@L#RxJ4=ynwPw{}q6>W;u%fnh$mGOR
z2C#U9JQDIJ4Vg7-=cz_n>P;>p#ORuZwngF+-;052md6SX2C`aL>{$!bBxhUwdUDR7
zMJDm6%GP3G4XoGKXr(1}=bzjR>QDxZQKg1lVPgKi+HqU=r|qHr3Xo>Rjp}*(p;Zgx
z<MsYB8m^iiDPLDc{}Y+0Gc(bQBN#xs^Smj{cIkA_#O@mVoo_%bl1kRPx9svqGWx^j
zqhgo3Z&!8v(Vfat7+PACby@gG?i}Q9=V7h>LXcU$;z`tC_o!=M2amfZ$ewA9czLlz
zk~H7d51KouIbe)9kll|=t9NjOG3$gt#lD1v9w;$UKInzg2h++9?_`X5v_PC;$o?h4
zHlD4t_gy;EK}vSH?_|`EX?Q%6!N|3mN?bu)TYF1h4^>4hhMfM6jEi-PR{K=(ZZHO|
zf;7{xu9UGHrsq|K$-Q-w!!OxZjaeB7+V{-Dp|nywr%CNh5qJ7R!GWMB$B;19RT&WI
zkqc4g#<N(XE+!|0^BoWnZM4cn|5W0Ni71Xp;s*m?w4FEgwq06p(iSZK{)=)g@}*!j
z#B+E#gUpWcsl%^0CvtOh=jlB;`rf~)4+5=g&*TsAjz0TsBQ0Pmj;PY2=YN!*rZnG{
zPwyK(rgi$8PS7nK<&Hv?PQHXfUECJF=1cy^DT3yRA^2TVSg75+$mQ&X2!q+vedb1I
z0Wi--TC8O6FgIv0AV}0<@L~j3bXuUM92Mlbk=UXMNqp~QI=FKhR(EN%x;j9X&89zd
zXV-35WR+d47!pNSe?T1CwQ&gzg&#bi5jiYXD3)5}ST?WFO!2GCe`#%3F2|qn^@B^s
zo8vG8Wezt4s^Xw03|rtdBWBq8#-V=sSEkxX!I;Uepbdf}fn;R_&K&uKEX*D2XIT+*
zS}lqB=AkMFl03K4;ghJvDQkmmd&~DkuxPs=)t0rprmVxqbsv7U{U+2%rn1T?y49sJ
zS>E*t*hzWYP?$e0`6jZswPt%RQQPKu)Z<H-3)j-C?!PvV6fCWU*02ohYU@poPSb`W
zm59|fyqhqrOCC(oF5Wxfq^4+PjmT&HyY5rNys5&#9#NH2E?S_FYpO4PDTlR3Yj92^
znfM`ap-@9hNdy!(uMf`a&0gh*9)o~G-mk-<x*rBbgi$|Yji^kJq5WutPE1q)%E;<)
zsMWCB<IV<{F&C0Q8#1{kn5PDP!>P-Fc{PPjWYc#z!~WXFXx}2s0F{0~ie5+p>Ps^y
zS(I!Bz^TJyFs9B6_%N~SY>L*-$HS-<aMpY0)$T!ZRCAH`5SEgh^uZ-&)PQU64yrDF
z*0RdW??@rGZjEnH(W|a%d1nv$8(5uRF#4u$!p6vH?M&lZnhRdw!Jzxv&h&JiQqAdF
z%brWTjpIH0n4W^%ksacUxK^5pOn#=2jGNWPTV(*lW5I}tUG9RFJD9-J1~;?FZ(TFa
z2KEyEk+4+TN;BTiMcT8b(x4E`n94L)@>>OD+^hM6#8pw1g^7|XlRJT1I9{KwHik7h
z7iYK*Xd14A5hj1;Z0`nVB5Y!aSv?!_`OvK9E5Hq%-pm~NYQ{6T{d};hp|`Zr)#?&2
zmydF0xw|I&HRH?2gN(`C)U5`vNMZ7HMLnW2k4SzrxR@b9)!Ly}BxN@VW}i5zO<~4o
z3(O^NN^YEv!?V?S5rj3e6`M?dx-P=_&~!KX<EX%g;{<fU$BF}g%-lxRkYwAj^2_am
zj)bhyCMtZeYIA3r+)Welh3mxR6!sP5A!$ExKB^0{qhUcu*+`!#8)+g^5H3u|9@3Zo
zT@L?3IQytfoIYz3j-9o)9d3!YuBhV-#}7;=#jSb9i_5NJ*XB%QpERuxU&pGoZxFuK
zOpu`&BNk;9r1Wz>YD|RX%E>Utk?pbzGrI#m0fD{Wi-|dVXMyOH12dsg4vCuU!h^Sd
z7_h4cAC5f*ADTV#@S*Zj{L~Z3{L$Cjz^r0E=c!EDXH&yUCzV9Ft^(OS_EUWWd!E)-
z1y=P5eQ|QC_~=!f;}$ay2;^SUeg%{5N_<+|mWB)otz#wR-qEuCHWOSrXWdOSpkfR8
zsjz~%BRoBh)-;1QU&YUlRy@Y4gBeuxOTjJ`jy}=_In5Zxm^ZX&7n})k4eN|H9#kNm
z=h}!Y-jb5v<`^&%FwiI%;!8Z?HIZXXtjlfg@E_8kC&<UojhVQ9`MNz<j8r@sVUX)1
zlD%~x6Z{{ys_qgXJjwi!%c`GfzleuF3HANP`28?lc3<OtpWe7w`Ih*~no<c^^T7}<
zGpz-|{j57-K7l#h!f(YB84MNl4kLqYzwFagPsrmAvD(@m5L36n<>9L$WAo*~#!b_0
zn1`#l7>Bt$CF&$)YtgXzpIXq(^xEU%G`ppaQcDNJTbTkC;@8Zl5YQ<^Zr=dD1m85i
zZToTGS1*cxH(TlZmO1c??Oc4p(}m#$0&*Y)$~Ht`A+pHVaLbY&M8?7!iD_O%2Ri5g
zXwC4l*wY2i3Q73aL0G%$dnChM+<i}tV83N7XQ!FH8RKYcRt=suCtnw9uaxedW7lgA
z%sst@6GN8YbKDb)krT4tE8FbLlc3@q_-5?ffp51fM;hsu{ZQP%-y29lY}|w%Su7Z8
zwcps=)p=)V$)PJTRr_&BkL9yeOzoJ*a`<5G;{;O>Q)vu~R~;8Gel^cIRo=>|FFt=V
zFhdYG-?9)VA6-0REi5g%KHAP0=Pp9q00pM+gPzs65EOuKuO|+$Fw}}o7b`2=vnD@=
zScl%e6Ro=o^EgsSCg%$=hN?XocJy*~@wHZMUK)(J>eX9#lWeQp7gAd|g^i3^nXcDt
z1?nPp>q^|eZvc@}qzYj&?y1DHRUyCLunRV%caB`fSIj+&=e_*Qjrx}wD0@KCbZ?|0
zn1izdtu>%<ax~l_a_?+wnePne+B|Nse^fyjjrUG}ev{#z-Q=v;Sdg?lGEwi$%J4zj
za`-qZX)k~Fp3)_)G2iJnA6iEk11`ecbj7%?Z`{AP14p6(#s+}qsZ1!z7$d4Ese_tU
zHt?~!oReA6m@f8E)sRMVt=>7u#?b&FPgugJbr(~|slH0GP~zH{-k1+q3l(et*oo0`
zZz<c@*l>vq!LXwCC&5<NHYO#r8esLWj=Fq4`v^1bsF$1=)ZSsp2RHXK!5t?TSKRZV
zJjA=47R!Z~!eH$I&jk5^5D+xcsDOz+;sNMMP6tQe($o5^UpG`ItAvK``X61tkvLq)
zMEC3#UTp4R*a;t(-U8m)Znn40??(XlXO#cWl>M9X-osYQ#nkN_9&9>sB*7BnuJH;)
zbKd>-mW#ox3B#rEI=0{4Bi;<yK6|+C(-u2e424%B(JI>#BUgXdt~=tVJZfRZDD<(c
zJtsZzwZM0`a3KNyf-IMJw=R=Nq%gt7@wT#s9=ReXTlNOTc>U6EcS(fuDa1i<+>Hq>
zN6w(q54a?kLBcgU4URpC7U-G9l*=Z9q8_O3|6v)25@yFd(t-j~Pk9yf7dC?US%5B8
zs?lv}D!+VXy8`{1v~e>;7aW^fJv^q0c06f9)pOOa`bwSy1AmCI!(9j}K?&fVGQh1e
z%XC6rvgW{o2nJMN@UF}hJ@`Gyy<yXu4@-Ro`l8dLIf^Z)e0gXD7!eb2`{+Z7mFZ;_
zM5^M+QvXyG-dDFkCZt+x@(j_h%;aRW{X?Vc=0n?a!V4$Ow)c|BYaD{cyL-;`13A8r
z$th!)p|@v^b??H0#4TE2Tlf;vEM`>k<U><w^LCKp%;#Ji^rqWwOG|v==570(ycSx)
z!<Y~hMmm~}d@AqFf9+xK)@}P2518h!0*bDke!fDfL@T4Tue}1LTrd{^0E%@708qFC
z0AL_xiemo%IsXShsNg>Vej>hj+1XF%pbviB#SWkt>dAKhMEslbe<S`cl>gxP2kXBP
z|7A&k1N{G>`~t-V?ShH-UIYLZ<(Q^2&1~JIZ^%mm0O=cQucN&&D&HiMx<6y7008p&
zr0#6EvD1j{wI}Fqj2h3Ci;Fcqlom#SQ;Ya+7`hqLCXmZbk=jFxX1);0ptKnTaey0_
UZvK9oB1(X|iYB<|vE{4(09u5ohX4Qo

literal 0
HcmV?d00001

diff --git a/doc/assistant/downloadnotification.png b/doc/assistant/downloadnotification.png
new file mode 100644
index 0000000000000000000000000000000000000000..32b04f122d02a8a0ed5a792c14e2df81de28f9da
GIT binary patch
literal 4513
zcmV;S5nk?zP)<h;3K|Lk000e1NJLTq00F81001!v0ssI21Uq__00009a7bBm000XU
z000XU0RWnu7ytkO2XskIMF-vk785ix%&01)000p{Nkl<Zc-rlqdpy+H|Ht2-8N&=S
zE`>r7F|}bw+hwEsZrE0=wpJ^u6<us<Tb3?XQD{XMUA`qsTU$z^NTIFOcG1l?6G|>g
za=#4Cm>Dx>KEFR$EHfIq{2p<h4}X~B^EvNxUgv#YbI#{u=7Zrl4hRGSG58=L2@nXx
z;6$NkQAtTjYHDgxQBg%jg+L%c8X*vfj}bDNJbd_YI-PE3XJ=?=*z*9aZSz}KSEs3|
z$>nlGLql_ObCGZe1Y#h;U@-jr{Ae_q6#D~!^73+DUtcbli<Ckj5Cab?l^Px%uBWHh
z-Tt^-u7`&QkH<qAArOcG?0_*bG0MuyZ7<tzeT0UFBJV>W5Ca=7mm3li((#f203{_Q
z=z1Rlffx+r<m8l=mUh}-YHBJH1%W^e5-wf3)M<YO1qDbE1OhQg=x{s&09033BSjDh
z#2}%ns;ble_<TN61c5*d5;`0YedrB=Knzll{UHztWPb<*0)gxgfj}UT{r$fY5fNcy
zWApa)XlQ68Cnu|_s=mWI-(Sl=ObZbM7?eWtqagpGfq{XaefAjuaK(5rUzGNo^XR}C
zURC->)Z5~dI~uCr&1d_Rb!?~lxO}5e8?Hon)gr!B#=W=i0;e>wTa?|qcc-SNUb}X!
ztA@e*j^F<?v8_Z+-|XapP=P?;<mB|0E$kNS9b#ke^ocGdGU|6%4=-_jaa_`sw(=2n
zF0;S2pQAxmBY>l$W7kt?Mvn70eQ&Et5r`!TPfM-@c=st{U|?W*d3khn^!rYUo`E7F
zBC@ly<Kp5z(kb0b`VBlRe%#<Vb&{zHi7&y^>-fo`Cpa&zychcefYg+f*qCTC0UJ*x
zIe$0KCn|7lm|FRr_>V=bL#+CDQjhj$-y8^7_9`LZSYSaRzjcHXae>*887?!nguXdS
zQ(2ykt!;<>+1lDPmE|dEjefT+e7B4lOMmv@8UTzLGv>na&h(mGnWh_-dP8@d!+O8}
zthmR{J{;=&c%Qfb-6};4CJm*ag~msh<R1n4@%t{H6i2nRYLkc_OXp4xbzi;sz1g1x
zK!}4-jNfPy-iTpt#*h20a{1{_0)Rw8nQjy4zsN{M3=o&kxgH!S7L<Nz$*^1M?d`b?
z032ObEMH{rvf?LBb%`FGaUj@x(V}HS93mql({5F0&D5VmD=k)-u<y4xcFu+Ft&~<d
z0MM7N|K4_*8AVhpCdb~a%s$|aO9TL*s5)*zh`)m_F^>;%G1t4kv1eptWMpIj$c(F~
zZvI`!#(Beud3-!BCUcLsovW+s>({TlGzatZa>>3B8+IzM?e$Y$Yw-OVxS!B1%Fk=R
z9c`$)W|f2I@~MSIuQqKx1^}7&p3JqLqHbW`Sek<ol&!zC$~b+{-qln77RJWL?%lhW
z#bN<~rl#hxW5=AGomVcm?G}qb(*E2#c*%qz>O}Fyiq;ET!duu(05Dk;v|_%Q5vjRa
zOo_Yq_|~rNZya|zeN5^f2QdQKWVB8}VM#}M;y?8OFiB11@ZaNCF8%gi^4Z;)<!vtu
zUcJ?~sL2|AsU2K2cdFUk6#?shXkVlcr=N}r^YL&luI<kk_x4Fc`Gu9$BYEaR2eJ~i
z_w@VEu*#S|vYH{QT&hY&R8mCD9>2qPi!%QJfQ9SBzt(=S(*I!Ve;=+985w!`uR?8G
zE4$&!*&N})4ZAc<KVR=LQ&&kL`gTR;E-%2vZHHytuh*TXF-<A|iNcH{VdvR-i2#sX
z*Zv=Tl_J9VYE$>7zI}Ir!rSC!%HNMdzFDq4Qop9G)Hl?B#LJZRo6jp?Sg4<?Y0$5G
zH>_Z>^496nlr{BvbuTR#3|>{9g@wh<^b!k(#goS@;lDz-&LI8bz4nAq;$$^;yI-)^
zl4Jl$SG$o~IRIGY{&7Cxz&2j%c$(sdUH(VDb-A8!6aaj-Z5Wn+#{H*DY6^s)t*d3V
zUs_yz!*)M4=E>zp(^VC)ApaFomVO3CbWL*1jfZd4XV3n`k%rT{?LJy0_>DiW+S=Hj
zjn1){{-vP!L4GCIz7H*w$Qf(ZmZ0&?*MeLVYDMBr3nu>>wlQFptCoRL_#*la_r>?v
zEi@u#sjk#Z`%TSFH*ehx7?G-=w0-{p0)a#!5)Pj}+0f9icI8@GXJJIeN#pbnv&MLz
zj32K;%6ct29TwmCG@-v)CUf+qcJS)8tnb}dX&X<dDar<bIo8(CAKmPq_w`9btx<Hj
zg_YT(zKl5b#zd8xeqE6@eR^qz)N-jRJ?Dy|cLW7&IpmrDWTdH?^XE!F9#O5*9xSxP
zLGO@{+Ye2`?JMU8?DSQ<6&>ule*}fJ_3)nhX>)RJwqIUbGE-^2mrt}%VoQ(TyCY_W
z$3H^$3jmlrYxd$F*J_c7!hb6Lz5V+3_VzaRSKY`5fFU%pwt>kML-o+3$?R6VRwM~K
zdhv@-hN%rVsN=O(6y;f1Fo<N0afWK~XD(P+SO9>91%t(8cGQz_`EI390svPYmFTM}
zs%vWg*KVX&4gkmhsmtTF0>C4V@Z7~aQyHTHKwIBrilJKQ@hdzDUMUnupOU#4?ip9x
zz+|F6b;rr8d<kAHlpHyo*7GbaRWblnv)gCX#OX8l#3#1>$f;X;dWQ9vQ!pac#@04H
zJ*}4`dsn6xH1v$-GW3EDC6x=sLL7q6-#4YT7|=ga6IY7}l;Tlq2qbNe7|*Eh%@^`=
z@>~|W95{F~`_?s=g)V2}FJDPK<Fe4D7w-cA8kMX_z*gD~y|-@3iUr@Qo!j=m&?RI|
z<9=RekTLqQI@lnTJiPIzwT(3Z07kN&Gb<zG4VR~9eLe5sxulMtQN||y&`^G1d&y_{
zM_isneIrt*Pw&m>SuRT@0Jy@c%}t2(+p*FAM~CRpZ7-TzrLUrrGH<h61QPtzt*7Hu
ziQ8hYvRm;Sj_^Tt0mDeQ^RTo#RYC~>q!+MX7eARXZDRZ0>t^QurQiLrd=WwU{=6-_
zKiuk%qCN}&1e^w)p*kXwsJuzoR$fxg1pu8Pl%^_RvX~5p1?M%VB=_;%f0)}nd<lx`
z=Ho`6JIv~+hs|%-rA3Sb0EI+s>=H#sgCeVP&57<`ds<JR63BQXg-EV`Q4Ih(LzH=3
zUd_K+msB;$YJbnT+8PvIv!GreZYzIT+uZXk!RtBzAgd39CN==%-}!t0gIi<F8J+=w
za_Ux4#cM9SH+|8XNuw0^-+F91VWRvkY?Lp=NKG1!OEw&g=qPC=a<ypK!)HzDTiy40
z&Qj9eliH||v?rCFbE5aEKK=C5oSfSLU}k2XnfT^=5h6Yp$0e6iZrx_L0Kksa+_O%#
zRujftPcQ06j>#H*MUs-#4weF>rKNd=M4djON*_O2hgh4L^`!R@%#75O-#a&kUctZh
zL&Ksnd4=sIpXDEM9XS%UyUWj-<?Y>m1IpRixw*Mn>h$S7@p_hP$xx~7E2Z{bd~s?4
z=?U{?T27tJRTQVC?H9gC($XSo61J~)c_Il#vD2U`8#_OnTgeva4r%|&QjQqsh{eSM
z@zY%i`;Iv#j4-Ns_54HF-}o8xTG%Bo%W8}XKq8S8)pUhT6#zgTW(WZMhDrcnF<EZE
ze9z%<nJi{SV++(5&vJCen#v2x<h?-4XIDzCoT520D!~4n?+@OEjba>Z<~rJZISl}K
z>`D?<1tZaL5eERs8and#h|jJft0)u6L&bu608r7=?|Do~X|<rP@UxlrsVDLQfGfti
zVlho9mQf`xV*!}v?HinV@gz^u=Le07MFNc2zPD1Ks7sB-Z+ImE?B^BR#r)cCr^m4B
zV^*J6CM2$&Iy!3muEnmGTDc8U1I5P20)U#*kY+2o!*X{GB{e#Ig9pH`KEIZimCMvn
zC}CF=y~aBqs=&di6s(`0E0;C;Vv>Ta4rUkD;1!Q2%=lu8rRCp$UKPCQQLc@xcs{Rl
zVIq+9Q$sn0mDQs@%JSw!?UoXmnVFfHnVoAF8PliF10-7|z=%I=+S>5o?6^;-jGgmC
z{-4L+#%)x!jR4xO<Esuc<mKM)zE;3A06>+<t9fsmUjkr?7*SPGZ92n!|1yV3=c2+T
z0EMMBO(l2dxoyUX>I9OegPULV)4xiqngHN&Uhy!h@C%z6%ttH$U^1C5PBttiOa73u
zD%YVj697xB)D+`DP#iXC?ssj+7nRoVUfj2|U)eSQ)9u~+604f~^5L8%8!-Zfpg8QS
z#Ve)W|2h4?@a6L-k8|ElqK?N1%0#lEims#73I(t0lr>FzmS4Y}o4m^T{HdgV<UwUg
zj*-PzZN0O!UnMnGVOf1`Zu<OnAw;qf01!x;YIHA*sGzKCs-okJVPu{JKgao82?R8W
z%+;}*lbf$^1n1SWB~EVP5yzjiZZC6kb8~X*^gc`hBdTB+82~V%3Px0EE530#-pbxV
zQEf6{3gf==)l?Hby??uZNiS>kWp(i1cbD|97dXwFG$tecYQN`OpEQ(T*j^^fyG_(y
z(hmS+O`mtA5&%qfT0dL+m0!f!Bca><J?)hBCbgY1e3r{d`*nQ{G{<2MdFWICZ1n84
zWA&A?Z{5HMgpqc?DN-k5L=8o?8S{S%;+8#lURw3OHox}vcJ}smxVTxwFXB8ub9mLG
z^eSH4TTJlgaQ{Ht#b+Y{B%Eh)fm_?Jw(`VyQSM`dQAYWtH2}b5F|EIGPGm9V4=Stj
z=VcAK@tY1t{hY;9wh&ya%Q^$&XSN+5wk3RX$U@6+PEbX~EtjGJev?1e&VaCuAx>`R
zVsU<M=CR!{J^~kux*c}mVU=LbvW-5|Y4hC)io?aiGR}*X6JAoTJKQ{f*nQ(q3!TpA
z7ZmT<)OlT2faAxi`uYETXAZ>#>|FZE>_4b2PwJA60_>C;Yjfb?;58P`zpoXLMv#Ri
zuZu6P2oRgl$~JGb!e~(<j6&kwO$=Vc=81cWWoc!Zm30RIEG;c>-@ei9uQt|SczJoX
z{eCei4glJ2J|0iGAEM$P7qt?Ud|KIm9rN{i-q6z5ZsNG4_tcWw!M0W0)oXXZcVGP~
zFDt+Dt!_HYuOVZkyu$X<qdrXvc@kAt`t>q>-jzz~=3o8n#MrTRb)y*1$g4Mt-|M&4
zC&<$i7qh=JAEK?T6_C=mC<W(YkA|4wnqEqR$0q~Um9T{b3_@)(smqoTlyt={<?Ote
zEx+8A^y#)5j^hpv4uFuxsIe3GY+t|7$yJOaF+M0EVY{C_zI)<SzyGBa+jHdf^;2Of
zH<&0<2LO?gkx5BOT{rJ<Npf;BpwImFglb?#Qn3I4qLP8#vb8x`X~_FNBp61fj<g$1
zAN}&#qkdOnJZ0fX<@#$kStwBv?`-os7_c%dTlJeKo3vRSXE!oqHtoMXu=_hyYiP*6
zkZy%pe`o!E==b*>rQm4+{S$h(LR}SIaZCC0%Ud!Z7WOaJ;WP2tgxb@)f;w(1eV9JJ
z4`F+$WUwXbdwH)#n_mP1G1x$xUjza%s6qCJKp>F)ArJ@zvOfd@fk5_$Kp+sv{tyTR
z0@)t|fj}VpLm&`{kJkPu6!a(t1OhQw=x{s&0O;uGAVm-e#2}%=@dyB5Y;24aK_C!=
z1QQdJPW!XBw?~Q~5Qss-ym|9F?a#o#z|71HiGn~N20RP~!@!{Z!BQBG;{d?p@!Z|r
zo12@FItT<}phBb3qN1XxRBGqy4*-;vl_Me|I!X};1Y+QM-_D&oySiMv{ngjk>*?u5
zMMW_f3?vf*ff!(zo14eP#OUeibuDb){C4H#%a<uBDTRfFm6erzJ|78(Kp;Lw$Yipf
zo}RI>v7@77H{+9Oe+UEuF&ID}dP5)(gOvXR_N0s`Y&bT<00000NkvXXu0mjfA?vr^

literal 0
HcmV?d00001

diff --git a/doc/assistant/downloadupgrade.png b/doc/assistant/downloadupgrade.png
new file mode 100644
index 0000000000000000000000000000000000000000..157eaddc7b7b9eb7737969d3ad1127f37f58cf7f
GIT binary patch
literal 9071
zcmaiabwE{3*Y7^GNGqKpN{4ipbW3-Lhdh+Tp*ezdDP2l;gLF#?cnIn4<`B|-;d$PB
z@Av-o{jp=sUVCQEtTk(9t>1*IsmNkul3@Y>fGsa4r49f{(1&+p45WwqU|jCX!{dpg
zoSriPJbm_ffq;}Wl7~Wc7kOoA^!ca6grrp2Avi$*Km*82NocyyAinvj8EiIew$XUw
zsJKA#es-xNGNLH)o2>eyIOQ`2bqg&&$4c(-*ptguwVx0PQXYQ5LJ%cUcI~0eyS2l4
zl=2;gh^Kg8BlIK4$98p_RB{T5YZxtiD1T&b^^h~V(WN@-8y50zO3_{i`|85@F(T$Z
zi>8YicU>Mew|#eR-SkO6ez_Z~DhiUoLy^EErAbYJ(O~$~$bp~uKRh)P9tjL}y+?v3
z{?-2={)<Dja}AQ&_*>#cf}q3E^mMG|p{}lcb#Oq`54ZJ*^eoQ{_9&<;e;!^;hW5|B
zq@1$Hn(p>LlzMl*Up0@;t=?>3%a`kG-0kn3LjuH63+U;C3vC}n2vJ?tO$au-^d|{Y
zwc}YK2wz3s#1f3Uihq#jBCZHBG>hDKUn_d6+rKXEZJ)f{P6ngtVgyVFR*I!*fDv3^
zsoe%-AMXQlH#ex#7q8AzlL+yp5!DCR08L#gX>LX*DeXx=e&fCYLQHvJZX)X@A{vi<
zl?y20Y3n=I^+xjexc$76A&kE51`ODI>lfzc9x*m|4Fpb9l#s-~q?7W_B0$lAyksV(
zOh8phA!$m{`t^4o^ZoZtcEf$wKzl(zA%Z{Op)GYpiCxUfwLTXH0Q!VVxe7iSPyaIG
zr!N}w&P5Gb48bFzQ^6jhfV{s-WKrXLWi8w<Z5Eg7T#q9a^1BG~K3<^^Qan}{r2^6y
zPe~IFUy5tUTObOt&qW5@0TPllfosfSR@IqAQY*I7%6hsj0E7XkAzKE|@cR$~ZP|5|
zuG|2Cm4Td7P^gY3vT1C_vmPxnfx$94-PZ>acS%zH(S!L812_cnYm_qE3NV}8@o>Fr
zd-2fxer!J{OhK=J3pW+ZkRgN#yJSN!9F8px-hl{eJ;}H~sW&}9a-36}5;ZldV$Ys%
z!_kUc_d<!_u6t>U?%4dJqGbp(qp~UjR}N4RS}b4~muok@?}n8ki`QgUfZKO4kQDQ3
z=s_d`7xaUo(7)Wk7L&?p5-82yK6q#lAU5#|WM)cayiZAvS$s6o?TRNu0}8O#%!b)t
zpvv~$3R&D-w9KVsjl3*xVE7wn%Y!tgn?4A|^KqUZCkdO#44WBm_;kq-eW}vpIO27m
zHveh?#SV;O%c$A?>3@o|{8N-x7CXKs5!Kd=X-Tg(v)1IR&b(^3shO-v9EkISD?QGI
z712T#nEq<aY_wO9z9ftRPWZ+iB>)Jck<kg%-kVi(f-ZJ;>npl&F}BKSVRc|<+)C+u
ztJJY%`m>|tfJ;tdwSFM=QTg&c?^8>>6C@7n?$HOoa8MS@dLQ(!j^R3br51f5RUw1{
z&y1oZyqeJcpA%1MG4!`JIox653oT5DOw3@Q7!nws;q5i!G#BC#V&_6U&SO#&5^1|!
z8&9od$854ljMHgM?yxNt9!Dy*ylS9pM998yx2iX|G!Q_qkmqA44RFg2@<F7zeo1r}
zk`%@}1gNOdgbd%lP<*F#o<cOoOm&Q1s&(fz6!$pizhs`1q+Xj780ZSAX@J$7U?dQc
ztCOIJP*!Qlw|u*S)A+FP^y4(jKnE$Lnd?1m(hiLxJObdPc^WyPNi~_^K?<ontqIEX
zGD<6kC>12Hd|r1Gwnbwuu2pCB;me*c#>Ea38>-1<JLy!QrKf#}f>G+T`W|2l2`5tY
z>Ps=kS9Jc0xxbSd5cRx=x=_9<S+sih7G(RqJ<~>ENAqxY@Djr_U>FqmQ#Zy+rh09f
zXeu@z*5HJ~{xNF8{dF#<khbQev>#S#(-Ni3Vb(ds{5VlHWng!x7R!R+->Gi#?0ce7
zLs8{qM|3UioeDZT4Iy7VndabEHXt~D%T=kY_MmDVr)|n}g^rF2hGPog(tyOx5Xql5
zs&2*=Xp!iDN5M)7kA77MCA>W<%xonSq1U+M{zs`89)FVG@RmTeEW<1D%Taq|bJf~Q
zHH($BkXb$D9RI=+p+zoL7Kto;HdBMn$St?tA#GduNI-@<S9i}2+FNIQW(@)&5>9d<
zEQi0HZYJ%h^8V^@5+!9;Fi#3kf4bX0L*nFMKD{*%U$JtF`?pxC{Ut5KC-V$*bH1Z1
zki_S(K#Nl!4K`v>If<8@7`oN;I_~JNxGr3GX>p`pmc@4#<u086xEL?3f1Nz93@^_=
zi@}%vN9Cauvi!3$<WxNp5=@GZcJ&{E?(17+@dtX&FKg(lZ|(Qj@cw><oPR!c<?Fn^
zKdWnd;*S?9#cAekB$*_N87P^nE^@IHusxe!r~X*axxss4A|g8ZnM!ln*L&=2YzxgE
z8l~EnKQBz~uXKXUJ~}&(KGzQ$cogJ3)s!RYMJSwG$ZZb;EnwS0m8<8Wxa*c`Kq2Nw
zeSOl4>u@K|4<<1=C-k|K<y8{sfTPUEI3=F>1nXtieI{CeHV&*QP5{r6=7}kP#g(7o
z0U<q&{E`Cb%7st@q6sEXw@2l`yQbNt@ZV>JlEIa7rJSrsbEki%8(}NxnTScTxBHL3
z=%$Zq#_-e;i}!0xvx};8<<{3k(>NEOo|8UavQAZnDTLbht`P~V=4`eg=<Sdk{J<Hk
zi)zxF+O*%6H!NLPn%D+*we>`|Q%jy%qRXm8`)r(=GLja>VH|GP9!`*Kv6hGMb3t}@
zpziG)1)NL+g25d&v6Ja`WzLO~#ozkH>;@+m`F<fQk7EO5O%Ty1;x8l(&nGBq^Vbs^
zcY=HuM5p+sM4JP(cq1xczbF~ve)UE3sJasgpdR5jW4r;}h6IPoXn$4%U#g+;>mKsN
zd1fJ#AQln-gx|t6!fhYQ50$0%S*Aa%w`LIo&%>I)7$$E|(3ZA(MzCZ2WZy9)5V5n0
zUarOdp7*+zPxGpz;d;@`Hc)*1i60fE!v?VPru~JHu^GAJE+$yQOOJb5m_sAQo<ozA
z+nJbwjD<b{JnRuzsONr_w+QVYu_tFdRRIY2DKi>`K4N+TXoks<Y5t1FDg2m5b@C$V
zEYe&We(VgDIw$od)xQqPF`uw`#%zMu$y`rpx6t!JS-n$OG%W1VN<N!;WV_e%1OO#n
z+bET%v^ApxwOmO$X<eFIpf>w_(ABGrPVjaU^!FX7_C@VhdQ}4|N1&Drt3OUU3XmT}
zrpe?+*^*G@&K#Y$_DVw5J4(<-xX*R8P(REY{7r4pOQT*p{@v_QLGRqBga$_5`_|uS
z>^Gzh=}qYbLVoL$I(hyQ@|iQfy{0z=#U4M!oIa)FkcAy{t7;-8c^&kF^EZ=c5~of>
zO3q_kcWf{simKS;!QH6~inUN=Oz}*3Q#Kdn;Bpx3aBeJjfQ=evj*ZP2#?QCz)YyDH
z`x2(@vDyChPn!2_SKvT32o&buWzpMOV+bCKo&s@T3SXD%!%%<Ti++>{qxm{=X<{h9
zM>5ZE^QGfvL3q1;x!3uxBCih%`TT1p_jh&!gM%ug_06{hQ9+$%ZHxDZow%}E0zyL9
z0l1=5Ena+`9GvQ&2j+SsUbRPiA+z)uKk&3R^qr687@m`xMTkyfw(|>2U$`){i*;^O
zLv>ls809e}a-{+#^epy~^NFR8)<#Pe2uH8=H{E4}eK4`q^!iEQ$hKvXL=N`Nt}est
zI2mezjjsdpJ_6!i#c!8-qja7pq?V4rdkl8$R3v=rC+3<~goXItm|52x#o+nthwdo2
zz8eK}mBSS53W!22D5zY}B^g+yq`h1PBV!eCJna(R1)~EBPv1=&caZ)Dc<0m#rMx2r
z-O{beAR-8yhYpOll*{>hRrrj(T&lp~u^gmngTSx!WrOAkH1h`YG~#g<4)%7aPe}V?
z8?##mdbXJ8qU~z*PFzpJ6}o?%a-Y<kq5E&8CMhkpWS=Eg{;8wH5ds4Ge!W7hlpFwR
zq5=&T<$cc`)<@!W33hQ_{r0I@-M~-8O(Vc|6||dId;h#fe_VZ&dGmACLQ|Nn6Rg8(
z1@RK6sik?tx1i+6WC40Jd7WS7e9*#m7L~zvt8YxTSu6Azs^)=}I9ELrM$B$>(XFTo
zU>rA-UsEN<Pjww~i{22noE5(Sf|*+5n&-#X2g-K8iUfc6fUUBbkYG<4$rgoeSf-UN
zb?9AaSKC7|CsAwmlV65N8J>;Uo<YBtj+ivDE~qmou~Wq|PC!mnQ94pV`!DPcEtanS
zpzA5NzN><)7IYL(`j^$olpDEkPA4kxw!mX~T%D;u85tTH>gu}Ro=*DR9jEj0@#$!3
zfx%#-ddKBpv76=4XY@9<wgOSJaS`el{^u)8p`-g-Sa=5k*-l-oxk*E7W+8Wp!og`u
zUXyX(qA4peQ1?_a`ygezHB~GF$ar+l=E3lMH2(Hg7X`b7g`$14%NpS3SvGy6Awe80
zfw;Mr?G770?fo{gusZitU@{J_qYYj^(ONhvW6KBf+%rl&z|)=vO)~QYY8Z|f9(LKE
zs9Z=5(6qH}%xi!pR~Bm-uT?9-$ZBs4J}zS&u^nW95=b24`eP-;m$P}IMQ&e!eWH2Y
z=bNvF<?f!o#%D11{fjIUnsBo$L8E8tb^k=k!37HLl2U4A$g;9beWaZY?{deAqihpy
z|KMOk88M`|mvLf*J%T0_5uhT0&avxq@WJwXC(|ZpzAa|ES-=bM^u!)d^2$-MEZ+Nh
zd`aik5Q9G;@n7Z#=goQh>`V?{%k}%c!D(u(d|<;}$HMP*o!co)<<sp-5DWp2qkH=o
zmX_~<P>NSykXdM&VQGdmd=vOUMTjGw8jWnSb^QAM7OLYKa4s%2+<I~0CM^mR5-$u&
zjsnDo#Sl$_VV1Zh#sdNeuV$M-H2wiQA!olP+c#u;Ljd76H|m>-yRKRt`wh@<jce{%
z!a9+5EeS!S8{a!vp%T}MF;8$zIVmpE48`ZpEcALRBtSlfBxr<b114k(-{+icUI@Uo
zz6G(j15n&(=4>}$CI|E*0Tm{4U1#F+bn>9YOTi6}zZ^-<*LppFU}0%FIX*5;_=X@9
z3kPR^rp8toHNK7-C)oMpN8jt&MI3BwyV+XAxQ+>YaL_{UOjhg)A7*m*H?awNAnJSL
zo@WtpErS5!f>n9y#>FK~COIzd;!{tXMTW0V%txphm37js%fI-?Y<+s3c8J!i;)X5g
z<JvcA2yq>4Ac`jlxFtrejgkm%Vv4M}4bXnV;mS+RTd>!>v{!Y4YXA=-%MKEmn?U>+
zGx(h_X#B%v8kE<V-}@y!3zBUQYA?*Rh^!qOL`NVJ78qOJXyx)6hPO%x0prWHd9_UP
zlIdWQvbz&<`U&FOPEm1>`qGBdFwhmNc8B%$uGp-oTFr9MjJRq;xPjnoQAzC+=zZTC
zsGMs(>rwgmx~)ofE0qZbR={$jTd``KnqCpN3oeWmX^FD#<oLx~L~=iEnJpookwcpt
zP;PBSUZhbr+7g>4z&|p{&x>Y+81Dc3+g%tq@wDr&DxJ3F>{hgO8*wZuEe$dowyg|G
zOX$G&a_~?Tl-;lL2G9IsXNu*cprj*r9hEPah|Uy+<D$*cz`e%1Vh3Iy{DuY$cH#RS
zukyAV>9w`@X3JLh<I8#XKMd0RT=(u<Jebe7RJPa4{XqRmXkPhZ7ah5?O_ip1Ln+Ne
z2ZIIuXrJ+(ADT3B_=ptDu!-0Ue!dA%gCyRtF~k8E(6T)imI+7v&&cv$XXu6+yr;Kg
z&nT`^kSa{>PBRAv17wR7jD;<zNm10QTuMCF$Yp7P#DG){9AK&p$<$l&r5|$LYfp9J
z#nd)IY;iqzhP<lw&!;hXnAXR%p0Q61caqAgGTO-xsZp9IZ~Bp3ttRTcE1GEIyf$aF
zfZ1`AnYnfw7r}FOzsqpROpHLu7&`dSP;lq6aznm+rWy+y+x}vkN%>^c{C-JE3HAL&
z?~_aKwXd?R7v1dk+D7UHEC)EimR(`QPHbc8&RXbmCfl`ydtHLjl?YF3o1b(1`!SLP
zT^ADHm7vgocTa&vqSdFo80z}Al=}eSmk7psQ_Uv2fxf}yv+iCqFTymY>kZp?hbrp%
z_E$-0VRo$B+m9zQswSThZWeKqnfEK$)f2I)0^+LS^66GRoBO=0DHi6KJAXl2;p8K=
zNju+&gbr-m>Vov4sx?VimmHe$(zai29BAX1OiZ4@=vp`kfG|+>DCy1*T_$*E(yBot
zgrUSew?WDNy(9ANAMJMuJ4lKPEvsh%8a|Qc=2Q=+B<>uRteQ>(8ZOdg97xbEFI8`L
z*+P_X(&@Q*d_IYuTl;?&RQj%a%*tAB1>%)BIX2eHxkni-elQ4c&6+uCx=->_Z`*{9
zI=4l9Xb~1U&+(03727B)aN8S%-*u2rE{s|E9i9%gTwRNG-YpOGnlst9HmpvGS^Hfz
zT_z%0m#=;om7vfdEw;Xl;N5eJns@puTZB^-9<9rMxbr@n|NOh<*`UtDs>Pz-)OA}n
zh~#dQjtM*9bT4=05T%v+6HV8Gg}&JI0cwQ)ys<Z$24R^qc>j}C3I*J8W|_VMNYSD~
zpZ`W)f4w|YG5}6(JDJUo%GK73^h`gGR#`fOEG3*B#cb=PL)dhH-?AH-?O)Z$J?SBn
z5vi|#4Gs?W_lMo7&}XDt7-|=fySccWoSmttsK}i1Ff%KbPx>8rEzUMU%YW~mlO;wz
zgxbn`X=cNm)-wuG*4RoaIH~Ykl_zRQ`Y<B_QthHh@Vl<u!?f`U8C4Yf=kzzMnamWX
zygEO=ldQjjnR)7C6~~tr<~Oyu4zo=m+&)z{VMP>I=aYe1nZqlW^`)NXs&Z!s=_O9D
zwaSr%-eJr;zb&oH&l<#I@BZsITIf(x@XeArV&=^?mV<}c@O~M$d42Ibx=V`UaqLi=
zMDL%bsftg&Z>)~NDVh^4k7jWC@=a)bvfe7cTW3qH{*ijup|<HS%UD*$U4f6W$MM#0
zFBjsRO1-0uJi1499ad4dgwJ|9*5Lw69It)FOiDa`X6|!*hYnA?M~L09Rfoh17oB}Q
z?=IhC!<Nrq^+JiL;g`<xeJdlGLhQZgR~_aa(Hkp$^w78)QE$Jj>fp0Y>7R!JPFnTO
zC>$c0$vjq=A05{h{ThsXO#P^?k6(SA$!*040c=#YE!7j`-kXax>22OdNE(Ok-I-a<
zCr|ZmRw}oPk3S8xr8Kx~hxR8b)$~5c+=F+B=30!Q4()x**PeD-Y;E~2wzAQ5Lus0>
zEp!{D@j7v9$*V``!1>PRDn{cNew!+kpln>Veemi**H;&-(a?hhpTnh&hwTn-D0zvC
z;QT_1m)PCK>cfHswqYUv7EXMtQ6hsY{x|R1s;>$_RE(mxk2&vGyhz9PG)Nb!gm_(s
zSB+0HeNr1DpI_4c9@xEPY6~G}q|=?{;qhS{(9S1T93r*5%X?ycs8`CiC}(@URq-;u
z-@cjXBfLIux*nU5?#0%oKqN?fc&L|X!QfHLf8Lh0MpUU`UV18F4P=!_9{)fEJprza
zkN{hsV7u-0nWMa!zl|0G@o=TK9QMj8RwworqEmDB0c#M7B?aR|&%sipUJ&Q)%S7cm
z>~-ZniU39qZ0tjXrSj|Y+A1T9>PBRb-UZM5@k7M%fuh)L{*d3MWwjXgqUe3A%iXjv
z!1w9kW*2gjThaO}Ahd-_%K~|L!(y?&xs|gYiIKY)FQ7yc-{Dn7`vS%1fXTT@hj?vG
zw(zmCq(V(v0?hD^ru(u%gl(Ic-(}-xgjegw-#^j~R==-zVI$1M@TQ0M$Eh^$X2Caa
z95<hc7at<yo3aPb0<^lWdpU!C0Ol*dZe)x6*A9_iomtona&GwO%ND{Yrkg7tBKv2{
zLu)j<7Lj0LVq!wf?#tuNp>INo@$rQ7{11^2U)v>oQ}n!HGu=-#z+5kWkjCAxc44Ea
zmPjsU{13AOE&upHVfa^*Ru*ycmMVLVNXM-G_kP}u)`OqCS6lcS8|zt?YPlvRsu~~S
zuug!9hHQCvrwToTJE_rYk6x8K-R;}x*+ybb2^Li}-$auIQvUC}1clMKPsM(qeYKrO
zuWn;x-M;$cv{t)@M*<Va;EHdUKM*Z;h)2-gx^Nrvi7wLM3fRKR^MVv8oy2+jxPoQs
zd_Ge{Sc{8KXM3}Ji6~!#9O+E}Kp3lgIR0g~IV<^IBAw9ReG#5HL$Q?+N-<G2ddJY^
zQ>OBtcmWc;<3=Ipe{5lxcoZ%0b!BXfCq702%ykuRJd-ZG$Rr1daJQ45D8pplxC3R<
zNrC|9CztYSxu483ET%R}V_P7M?<}%Sdv_B>f3Yq_6;_$BO&wk3;;OaBGh{=PnT+qw
zS`8CWiTv<dzfIYiExXz8BR|cY71z$wax1?(DrTE4*{s9L1}dC~=9|*;Jd87EplZhe
zY)uZqiFrn9A)>OpBX#nY8&xns$t{t>FAnCDd-c)_HAGTLDwbMP*%QWdWd*McLhCKR
z%)sN&q6o3boYKRfX*~SJh3?-m3%C)HeW1%UjXrA}DqX1Ki!3B!hY3wu01R&XotD9J
zbXjT)3%=I~D}G*P=H0KdRPPv`b8&IiIV@69P<S79pffWwbMYkbXz@k5HLwhR8J~WI
zB%0^mXYIIMNQjYEK&^$`8N1$-8~mlHUea;aW=B?_9hqk=7o$EU-PY*nL-$pIjn$6W
zHow3MBh|Jk2yK|M%zmGhpk)<q<R(5nHmQ-n*)<5VoD7|q82RMfU1H%eU9yA5x5zVM
zGx?LMrAU+1Mnl`CvxZ}WH^PmdRpkYkE6=*NtT1zc$7yE0ni7Gu1cLqC$;<PyE?C1@
zd42X^5yiH<f_t@AX2Jlhb6lDERMd(5YgCg^HKkt(c=a|0BD>J?kRJiMDk~={E7#;t
z2?Mlh=ul8Pisera$6HQP1~qpp)AuV-W$cWQ@EA&fghi;&Ol~D*O&2RyUSr-Vb%X6m
zlea^EeF6;%z@W7gA3)_C?*`uyGilykuPdAIS$_&d5f&T!?%p<*cMZ;)T=_FO{4F{f
zKwYq2&fiy!YCW-XX;_8wMTs_az7a6U=^HpHY|t!k5V+?N@<YXcf*L#!Azevm_O&f6
z=4H@@mK=+E>I#Q|ri<|h_WFfDB&B7po<E;s2utSp9rJ<q8=-~cgRTUM>jYlkw;w?X
zqV0m@bzh)cq|xSAI>gOD1{15uLxy4DMQraIyBd>lhUZ}-ue0BPO`dnrN4i$G>LEnu
z!~9wADZ>Z+KkW=>zHD^mu@H0`?e6YQOQQ&s#HX}<h)*`x)*$`5yf)sGWk$GSH;2L0
zzV!}^t^51-3E<h8nY{dbC}Jj8yO@hV!LEQM1<&{xJK9qc2~*J)9{=)Gm0s3u|H{xH
zy|_;G3!TKbET7chc1El-upvUVZ6-lmtr+h2R4z_MU>WU{coPGoyk((9N9?FZWP1*#
zyfMvri_Z*hHM7VZBq?M&Cls)K1v~f{>G@Ph?z}w}FI#FBSDhBG<V*gZ`Ai^=39Kg#
zHPHKKi>SOV?Y+b^bQnVaT*}N^1FGfc!%Syw6se)t<q<R(r4OMhM>fsiny5`;3ZIJP
z(`1^^knQZ*F);3G7)-0yE7=Eda}|uV=Cu<g53<poJ-r<NW@q$ZL-dsAXCTqbP|nhY
zmnh8|8f2xu;Hce$nx-E$<J@RG1Y-L^C@qDX@%?AS{xNt+U7v9$aj+wjN)M0Jim>3=
z*fMa>=sBKiqsPE@fQtuJyqI|=DPo**>Zr3WZixC9vReMYbz)td>(!K{!QJI_%h3H$
zYP8A|zkajb@3-FXdrslOqW42$*GrgG?x(w6oTXK`z@qz3=JcPx7#aN?$VcnT6cZOK
zl_Ez}DpEE&F^K^?9}y7Urx`Sx`+9wvsVnjmaZeSsJvMkMo%-GiT(=gc<L+ipJ5>gj
zoTa|%aO|t{*3chD3~ioKX;cpkRLnR8uGq`$hBfyK<39WLCQ6ES1n%EqDj^}kPZ8CR
zNWuM6a=D+sh5Z{HhvMSyyv?CTzwH*`u(`et+S=Q@=~MOnJ6`TvlanLW>b{Es<j>5o
zhk<az0!(XI`0vL?hsKeU($Y|tFle2qo`dQz@P{kpJgnDHZzKvxq=q;&X!(g|a%J8V
z=g2FrP0A#LKGW!;2@)BeU^`04!9F$3PCLVdFwhtj$M0#E@bTl?-wanl&-L{RBga?l
ziC_tVXi0c4<e`&!4igW_eqgv#uGP{48M}tenn>o(<npTLBYp=+koVMy&D`(!3T$_7
zEPAIq;@D!z9`${{pp=6<6<wY8y3y0_@`QH@|3wdUO&VntelcYpEgha>B`?zS^(7SU
ztD4WJ(Wsr?;MCQllkS<Do9At=aArXw>#Tkgm2jqNwuh!bK+dvc#YSPa_KKBG^!6dD
zy4zOun`!Zi^!nMkd?-upg92Nvf7m(AH@Y$tgznAMFw@gpDqmMuSKH1cdPHX3kP|t~
z)gNtTN9P?A6^$|3+Lf&2dt<Y9&vcG|k(^i%4d=>XVR6;H{v{AHB$&Fgpy6A2*T7E9
zS)tO5?RZ{#_#_@~IKCfg3Z5PXJ$dVJN9`l(lMwtxqhot}n@8)=crQP@ihQFdlKerB
zavER_LwtT0I9uzuy%Vv4V2<vdtls#X%y$V0h_}1tluTR8aM^jb8K-zcw=TZOjoqDc
z0*0b><P@X(Uipv5`DjZ4L<UiA+ruCD99m2AG<8ry3lY@ONfA_ra2#@{J$s9nZp}N;
zLY|TebP9#4<^cdQ(&JfxrGm{nqD7i#6Sqy&4FTCy?Zd-!;`TClPpY&>*GTdGQ8+3K
zup}U__UBuq+X+!RGxkJrW+x)H?|h=?toCZ-vK{K5*+%os+n>M16^RqLruI2`x3Ra_
z>``4`@4m{_^DazxxKa|L_3;06%^2IWoY>XHqhGAqv1ng64%wJ(s~1X6pk}kRcH3>?
zVfF(rA8}v4hg{2<XN!l2M?*tHGRZ*R<?YOARYis4@di9A%T>5IA-<t}{MiExBc<?w
z3OsvAC@**&u(Ggx_*t)C+Um60lV>mphtIe9waH}5`>~`-f(<C|?h&|t?p~BSpli1r
zq1SgNLwici88PY#jJa`tSii`KO*SqJeU}~ItmgR>9=6*kYE)rJX|Qm1A6@*X@uRZI
zdyv#(ytIn^1G{=7_)l6|nj^okm>9KBfcnPs-RfU|D<OT;xSZT!k$>HCF&`nKgtsv{
z--Mv*LM-N&k-tdebsyl|_XGX%o~pGs*~O5&SG*o!uz%YxjU!0St0Iq`D)z(HzzTRQ
zbSciuDP-(P7+9%l^4)-^bs^QCt=QYRJizj$viua<Oz~ql=Yk0>#G(HlkC?_%VCiOM
zc#uwkkxh{)wea2lC$FR5HabniQy5zBVp7PyJ&3W3j}uJoeJEiQ92o&-B>D$lBYigw
zkJk+|P<tE_b;C1i9dNurGG({=oc})pDdv5Z`^?SLJ@rw~@T{%L{`+Mcl#}n>&9dK!
zTK0oBAa7{D%Fz*IZi02H3}x>Pw%^uuwKvrf-Lu%Q*-F{=yzex_oOr<0AdEkk9o^h`
z<stg!{{jD=UVTP-#QFYr@bAAk{zLpXJoqnG_#XiAzu5mTfcP(mLHIpxj>>YJy+vlp
R!(kafURp(}Ow!c<{{Z2%e{ui-

literal 0
HcmV?d00001

diff --git a/doc/assistant/encryptdrive.png b/doc/assistant/encryptdrive.png
new file mode 100644
index 0000000000000000000000000000000000000000..1cb041dda701b2718500bf06cc72e7d5e093dd90
GIT binary patch
literal 42725
zcmd42byQr<w<dfVcaq>v0zn!L?h*nd1b24}?(T#T9D>uhySo$IgKOjN?lR>4-Fv?~
zbMLH~_5C$#o$k}8y1Kf~uDxs5^VD;KWTnN?Q3z2006_op`I9^Vz#;<x=m!$aOG%rL
z`t!>P+2*sFJpf>I{e6LA=`e_13K1Q?NQojskzZjmkUlv-q`edoIEbn`h*(=%8d*62
zB6dc44n~IL&fgqN$;H1&$*TBb-~j+R@a2=RqRae23%>>7!u<84pm<<|bx;Fpt}g<i
zW<n3!%Q;wgw;#I~o0_p!tBcVu$KYKzqds0wz!zT%OJdr3X4-Nc<YO2o-#Tph1O!6U
z^o{^m6w?*j^m@eI<N${&4WAD>tY}Zc>zaZM%&hzCck1S)iE6Cp@q*6}Sa8Cx{vN<e
znIViHInv895cc=okDP|{-9I1F7k~a!{_(xH!tC|2_w&8Z^WBX1(>WOn);~WM<neyo
z*Ll8gdpVx=+hRf<jSlS1o^MCJpRT>1<163&(_E^~j|;))b3yONqJxsEQ(l@6|1`g*
zHr@ba$MA(&-CegmO9j3Dr^!(+{=b*}qE;7W-j5;0Vt+f?#VYo8;dX!4Fj(^cyUsAV
zLH=*M>t{#tPx=4$e*T}X@L#O||8#Hv-9`S-o&3MA`F}fnKYQ1#M<s}8vkLK#$$KN}
zAcTXGN;hNKZjv29I)XBy!3wa`P5`8?y?F7O>&aiIw>MR&ntKqAb-i8-NYW>3^K{ov
zl)}(0#QOOmz}-o~Ah7^tnXqT}KAtIWZ^stSKc;|^;#RRn)_)SA%r`Y~IJ3fqxOoZ{
zi7oHNEgxuh92zSY(xx1<)`r{c1w#yS2AaApYmj{<SJxQA9!!@!z<ytH)>rPUEQ)w@
z0seVQHo71S4T#kJ0r$)jo<zh;lzBNkUD4N^Q42g#J`EblcL&nak46vkk|{GQ4_aC!
z$ASR$rsWokDtxY<NHAM)$D?u+eqZg)dZeXgL@v&YpAUqk5@W=g3-Zt@a*-zE0J5+}
zFn|dhnw?{Nq3#<ljASp#3M&W<7b>}LEC}I5H>~y0A6+8gsI3`&rRQrmppBXEgGVB7
z9QN^}am}z|0M6lx;A!7`Od<4Q<Q~JYtWWU80{u5ETbmXJa0c+q$N(3AeIhak*}CTX
zADna-%K0y$7t+V8;aPRo9q+qtO8Tx?d~8_EHL}zKUM3H_EHbPYdx{DI{%UoO7m%0*
znShA~aJp|N-1QcnmGKQtFSz0(WfEhxIl~E|Dtfv55W+P_z16_)Y;DM0Nmi%kiPTvp
za{G>(l0*uKnULMO?O|-$c-Q>wh8zYU99}y1w%MsA-(llzdz`MH9ZlV|$N6ljdhsgW
z7=2B9JK@o4ETWa@OG;W~Lql$Bc?@dqZ(4ZXuJ|TLl1E1(owCd*k5)A^2bI;AzYa0>
zujl?1AKLFssN<|)()|$!un^;l-*#P?#*gn$a6XQ(&hmp_?lteG2L_Y94%c^GAh5ha
z)-aep6-Dcsl!*+EDdwD=6<b>+t=d~L#p>y={}^i&t^KiN9UE{?DylV=c#GthzPQsH
zu+G!)v8Kl?ag^xE0jo*~>(H$=H2eC1S$|cMGhT@>aV1w!2_8V#6>CZ?neNP}yxuR|
zUPtDF1x{uxIkG?UHK+XYQA@Ac#T}J50fMKl)Jxilid&4^awk&2VnvYc_CJ=O;ack2
zdq#PSPBef9Z=VZQ>+UNgyo3n|hH89<u8DT@N`O&0S<;qo6b78|Tj+XATaT=WHx^QK
zjD;rHrRyKSyIQ<x{wfj?C~2I_)C16Y=ItUbjE!sU!*E)#!BU0aH!b~&1bA8S^o(lB
ze!6sA^wE;W<R}k3DPX2^&52p*xZ;K*$L~HDYLScKfgXL60TCrBW%U6mTTwO)it;|2
zUfBN=N3vEIlyWW!&v%UD!=5q9=7KTP_tMSMA_YBf7Vb@r2Zb&uYisROu-GJKf})m=
z1ntys?O;uOM`@^k$Nv!*39rF~wUj7XcX9Q)pR~kMf1`;&ykk7p3>W!Tr#{ZD;q~Cw
zAk-W)b9NcV=Q`?_9{YjqsHu-(qZ5G_di7($UgC{XIlaTQ;w@eirU@-mg}j=Jb0$g8
zYZOtQps3TSj9!B=+kB2!=%jT_qa%gP-$mA@snx`_v^1&3=GB&?OgXE4T^`JyEes?%
z=w8h7Q(EI)HfY{5J*Hn>GZliytaBK5>H?IjTdk8Xz@?|S->&*k^=%f>Up{$ODJ`OH
z%52*wcObO?4x14Ie}8;Zq-M7(yEB#km#ff@H<_>v>}X|kv~#Nn1|tBa1kxuA;ty)T
z?xNAL@%W5tvprW$oBERd382YGzd-ji1!nW0EVD;j@;0yQ;MMW8K^D61=9I2W5NLvn
zls3`&YR%himZN!o=jXrh!NazDMVnVMX_q((kMD=K@-)+^2(WfKIY09IPZD_Zy)qb8
zrn*yAK3?lRhDx=ExF+dVO3vYo64ISZ=evO!DJuCCI<YFI8G#_^SKgzVM9#}tWuA8`
z=9A4?2`)R^nwR=0?V?wi@kCmirD?4G)4S!s=hQA<l;*RN5;ZP>5jF3!<UI_L6giGe
z@P6&7XSu}g`PGqY3o=l34&mKrgdL`RN&hiK{G!1M0+rS8mWUscl@+!VG><iSe+@au
zAGsxS)^!q73D`XO!d9=(YuaHF%kpQ^c{%~)8de_*eK<jVI@!GL+nT9kA`fSoRnPL>
z<G-7qiGj16GuV>r6jMY32O%t>yGNq!UtyfQZxbvLIy;Wt)rD4K%yLn4_Di?#%P>pa
zlD%#hO(&bznMi{4vlCz<hc!$69U1v@6!217jGGqPK|<ge$5PV*VKawEBRyoGU9^Hv
zpw6J?=ALs^p9nB+St5xDJo~#GdYP{2Cj>gJKS1eA*-s2Gwl>YK$A8YT*#Oo3WH-Y<
zeBqmLVe=r49841cN@B5N2i(fLw0+Vbyp$}4Sz`nZX6Gix88Wl(<4?SyMprr4XM6y;
zqJ=l3@o*o{MY(znZk>M>Bb{K0a>H~ti|K4?C3u(@H?Q-JFRtm-LVm0rLI|wxu4F|#
zx8vd50i)Br4#tIpG5<{bz5&tbr_PkF&&Nv`77dbY@h=JPB`{-bC2t>p1gW)OO6cWF
z<M+f|xbQ^@5ek7*DjDg83$b}e*>|^zS$}^jfII3qbZR1Xn${v>W*ZfRjkjERQ(p{Q
z5XTX#4*4479=O6VLFklOX-2HKqFc*5IA;&shE$u{PD(Vm<$Vns`$jZk!q}^26*DLz
zQ%TH>$l$$_MfB~T(SHmzZS1wB^4%Y7R>fEWN`k4UR-IJe{eiudY;6n>V~jqu!rR2%
zDED;;V88qB`VpTixwS^K*h2y*TfT9Taa(p2b`$p%*bm-6wS_5KgMf`bn(+D^WP#yF
z)i%IbNnlGd7c!FhZK$bx>|rkLCS5@Ag7ok+8ZjcQc$WV^Nh}SsWNEQb2PR)h;s?Qk
zW2yX{XU(vA2A0FVju&M1XS?1A1Fk|8u1)NqaV0cx_tW)FUOS-*yxx|vl2nf79`bqD
zP$w4~?#-Rw;DF{dVR3hlI=yl}H3#TZmC`6&XB=n}4Br`=B{R49xFHsv$m}3grD|Oz
zw)+k`EG{}WN8M@B+n`)9L`3f&RECkve8ozx9M>SNvpdoKVxZCBwqMATx;0D=Pqf)<
zEnztpe3;o9efx*th1Yn{6z}nZvbn|g0JM1Gojoiq<mW|+yWZ`_mu<nphkE}HkgboX
z=8IXjDEHQDW%1X~t+YyZ#JVt_K!N5xBTI2>N{m%GO>n$vp_i6%;}y~FQDKP2DOwPn
zPlC>A`9#e@-%^fwIOAKRgc}=YAMdZWb((dYuX}4Btj3mav&R0e=^Mr(d}8G8Afyq!
z=sTcKZ*F_K-9O{Wzr}y@zySWZC@U-0t|z_bDMOUZW#Xmtfo2{k#f}yXC>@{^>Wtl}
z2U!#6@mPNx|C##aZUYV6KsmMijF<l&=RU2lT>bZ}PNnRHp8-yCLBa#+QN^UznUKJG
zoV`YVt;>i}Ci8yp%u}2i!`*X86<<@C>P|@mMw*TjFG+I{En@?S#OE{Rf-NJsVqJ)Q
zK`b*U)A2#Xw|igkB~I58PbXTIk-&m#f<LF)xj8Y%5g}5O-pCuneKWifB_f>L=s)9V
z1zL{IT;x~RE>Uz+c7AE)S$JJ`5V=~169YS~<ZqJZRLF>PAvr9@_Y&Mh2;~H{qhc_Y
zD?5;b{qMQpV$!miDm9v{L>{`@s-o8ne~yrgYs&7XarPKhzhl+4rJmLKZ2rmNc0f)?
z8*aX4CcDy(*RRu}!T>OeR)q{c-EX;*X4<d(h77mQabi{>LN3j>Iegtz9uAcv0&@RC
zqk%9l%`La>3x!yfDo^u{bXM;#Vs?k}SCvZsKLY2DwC!(-n;SWr=o?82Y_6Zx@-+0`
z9|yAUm!4L;#C@y*0I`LKO8Z{+$iUlLzGJ^TC&qwUhl16yYxZAq8>pjF25GBd${=4R
zjf@?Aen=UIgz48mC$H$;?wg&z^?abU=3BJ0fXED-a_wza{s`=tm$Uz1CjRyJ3HY$#
zTT4Ie`H{-)`4QLxTHMW|e~|*;c^YYtKHZ=)QUWiWz~l0=HvUNlX?wWcP7{G74R2u<
zN{Y!lzx5?!6ucN}TXX{6$QteNr5kSa6ptz8FPN`CH>)1-eQtHNsnjL$0v@_Uj^g=S
zJ?|0HVI~Ox{DxC&lwUq9um&q!JKQvaG6J<HicXPqLq3FmnyoZ@JD7*3Qt5tB!PXP8
z+oOdR9BR3$pws9aPuVA|8iq~STD9S0`CHE8{R2N`;8LWoAMCTp{EEuj+%QK#Le_$U
zP$GUw%uTVEc!U$?Gq(CPdLoD`kD)8i?fz<SY0-7_avWm&7getnyaWWrYY(yl&A6hO
zW3_4CIu+sz9;279{;my8a)x*Z|A5eVs>Ub~;v~=T!c3!>{<i7CY1%SIVcY!&u01_k
z2X)aG_x8=ppLJ0PnOFP^2UBf}T@1ha+s^+U%Kx8n+CS)PEl+GfXh5<eg*^BBQph75
z0ynU9O6=z9<wSAWzh&moCO*igE{+NB9|PO#Tg9(QcC6hDoSZIj#xA7g;<B~y!Ee0$
ztZsWtnmaWTVjelb@4Ccrcl?dnJ6^k$$e$3M<{o?Tu72-%r{b=&djYm_eT>H~z1<31
z{vPsHZ=~V;6jT+Qd2n@qD|@|edg?EBFY|jjHIX-iM36(^=}FNpYsi+;EAA)&>WRMf
zrG=04?vNw<K*46ev*=k%|8hI$M)ioM5aT|NV0O&38mZVVt}O)e5EOAeK5{*^79`HQ
zDJGcB`<NGOATr>y-l678sEPw{v67?V7WzzqNRtUxe$Z9YtvvfaB99=AuxZK_`qf=(
zg_4*B3lDTxCF<7+gOa<w*Am6}5R?(3+lfH1su-bR$>U+WMl1BP%BKjb1OOL>Zi0n~
z6Fl2}DfggaJPXToJ6C~NQ(XIiF503{w|NsS4c)|+VkvQ)eKDVNjBo%tqUOsSSSWoR
z+oT-)J&!<iW>XC-8DkO6=V<f;2Z2(W@PIF8cntBGBeeub)A@rWyu2q3VXwBEtP!Ho
zXt-*D;DORkruL7DV7lIRt}<<{WIV{9(GZM@FciQAQ5BSo!3=t%`mL)Otr%t+uGg0}
z9Q8ADF<SZQs+;G;iW`{Nor>O9se|&CQPFe^M_c&wCL^J)BQvsQ?+AjAiiWNkfs0K~
z)Ybihp6+{Kg&yid(0D!me7@Zj{Zwa?8{w~#<o7bj@F~W0<#8xEEK2CJITN7)Ex`Aq
zN%~E{ejD&i0(*M%4zBSuCdl{0mDd>44tr}#&HCfU^P^5lu9g$G<l2aw_j&*0ifC@L
z<DK|PY}$;zx%CHJa2(N!oY#9olj-nmgauC$rrLR6>G2JxdZ@La>e`?e5N^G!`11ux
zhE=IHAXIg>cS+fLv(nf6DDwzE%rW;VaskH-Dc0!5OQYgCSz()~^x|bySxof-5Lw6j
z#b!tIP-H|Yx!7tl?>bsV6SQNzUX3hg%_x+%+|KR9q}MAJALkAo&ujNfi5fIbIh9rj
znF(!Zc^u;|{iR7KDj=8iAC%P^IP&Z^N36Y(I<aQ(T`9lRhoE6ua&5RlK$*^7zu!uX
zWP^XSV})j>&bE@suqo2a6dGsLtX)@{(YnbOO&8*3)V!J9kVHk<<D|5DCc9@0R9n1d
zTiMq=S<77C7h`Bm36DqpMc@-f7h;w5jp0w4(&vED3fYQDAJAs^`}3jk)!B>BIV3Us
zywegX<#m*;QsYKof*v|Xc9#bHND3!A7+qV}0J7%fwwhhEz;Q8<d7$q{He%kgq)Sy~
z3wtV+UTqaQZ?F;*XNUPpwV7tCBYs!wCr;Pbcgc*^1mx=M;VBX8)`S;FZ$dRU^>cLJ
zIz{~pv(FCO6t`_KSm%we8LTm5dBhLZa65dz=qOKb3=vz`7sO-2Ey}NH2Z@nb;D$N&
zcdOM-V#`v%n(5fD%8DcS<4PCxY?090*tgN!UfvFWsT=_f(iu;TkL45Gdp~`@o_V^$
z+8xM1N}n^%_%-Id!(n4GHYEI82mQy4z%1}tMMuXvPgh5aUsa-uW$C+MJG`Yi8CN(R
zOp+TUL?zUhNf|_apB6EJJf;Hj_SEkn9J_dLt;2>y17oUpUH|QzjN8Ry>5<*jiIhWJ
zs+4_nw|8v~6-b?kfZ=qxwEN`}E9t;4|6}g(+**mUmdGXEI&4CIMcjS2oCu8XDQ*Sp
z%reVTq}hC$suU)DJci*@E{MM%>B(Jvf@@oU`dWcTWt&UQe5ih!hr_$dRhyHiMVy!T
z)fu9}LIG2teX|j$eH*H~R%yA+_l6|*^Nso5gD#Qq%z_MmQ<#!+#&CfqZRp0F!KQ8V
zqk}jBRb%?Epfa%m!t=q)c8xE;t!#8o7qynMqxBEIiH(KLep&K5DM(_Z{0+H0wCOyP
z;F~STLp52IqIEdCTKDt2^E1k@vK61$UQ>omwprhwe9!qTzY@iZVU-qpc{IE^1rJ1>
z%yiB9roof!bBeD)ZJ=9%cBePZ_vT<b(y<rw)I=GIm;Aen;knT4v&5p=1usks4s^HQ
z(3i!9m=yg<ipQlFi9hEQ$#K&Nbc?n;rW)W&ADn^E+ts#i!xVLMG)J)jB<bQ!vBN6S
zWg=uUm(b)UIhSXi7;9(Ljq}T?N3C0puyt$1M+1r}7=R*Ov?;cwIMpJV3<1s0@=FVD
z#Uu1{D&mC@Kg2qBiP(dS-M21(_ucva)st%jI^ZURNWN@ARq1HSad}_Izz$C}_=l$1
z+dk6T5nah*N?~rxV|Aqy4;F4ek}<%=lywX+_EqMQf2w8c361cEz5a4~kh*%z*U5ds
z`P0$J)$)h^>8y4o=<`+))P0CLh-yW{juB~Avl4W^THLBqgr1PH_6wPjH1)j<YF|!t
zOG}PqA#(HC;v#vKE8kbDpD-SD?|h<NlJ=X5H&^tc63sWdc!P{UH_CXTu+t`7!kWMO
z0VDT{lH$@)8%ENnx7`${;FWVmceE4y6%8#5nBKAM<gk0GjLN%w_EO8#V%R06h+g2d
z(TXi;=Riu619VUihllxGh)U?bG0r2Ww#i|=IzVc$+0gVd`MA810jcWXh=RUS&BpOb
ze0@*lSn|q1hA%joblVR|TYw>7=o+t_y-#GErY<}_{VA0m^9B8Oo+23d?MlIR{-iYH
z=K~J{m7xl8aoZHvw5SuJtsmgu%NPU(rIJ+2V;X7Y{t}k9jXj?lRw{}%C9)|k4qw`;
zID*r@!vrV?EbE?Ej8<L=)yje*L&V=1wcng=t`-QM_Pd{n@*XqPzK-Z>92U#G<w$pC
z{2^0^m8SheCTnVSQ01wscO)&@f}zUVig%U&c6|5a_F^e)#%B*OL#EQ;;K{Dj+JycM
zwwp<7z=o}&5nji+9T795Rhd|LEf(3|c0{FzAtnr2Dn`CRER+;u9{WAAA*%{I2e-Jt
z#%A&JdW-BA@*pN@&D1&$NA0StS6)jqV8%wP3x3z@!2}yJ^`D2;PGzqW;4p-a*S>P7
zAn1NT0gT}oZJzXYe)~Q)W-gc^?HWg)W=m-vTLks4{~2y5{?Yoo=crlt1BfPOAFLFK
zRVG^slThby9qjZK%$H)jp)QTb2$~Hu`m6*vQJ{k6KHipiDDW%f7c-iKS>%;YE#A(J
zF=~LFhYM3g_bZ8^<@5}rNYm}d?mReV(x&!qDog3=sRf1!rkx+ZwO>kyaNBWSZoXR$
z5|0|T0CZQH#J?5oZkc=yxU=e&R5g&KipEvBZhn_2`O(0E*BG!ME9LYhD1FKLvuM4*
z<bntcW`M1uVnM+{dQa7(@?J*qpdw4YoM!izT_rY0<Q<jn513A_mQ=vD|MQH7B`{`)
z(S8-zZ8QV|Fhf-8DuP{dcjjPxTuR~E>uTsnYyeHx<o-IsrIA7{iLrj+h)=MDy70^h
zsl#P<Mc+0Ch6}1y7t}8=3}@9bEOVph{BD$$@E8v1)#I-`+BFfZCwC>AJ1sQr8B}oj
zz^IZjdXut0N~TVnIF_glF|$lud#9wH7d2`tjFU~3UN8+MUtTn;W<yA4%C1m-s;ebM
zw_7v|A{T$E10}hVU2}gAp~~)H?!x|lnO<Y-`-zk$rBQafHTDHqmIU<Q)jd&4&G0~z
z^{<piG+-+!80NZ5R!wV!Fr~3&n&)}44AX(B?rP-PpUC94p~{B~ap6}=on@Gs7MC<h
z!#~lrx0xvMBZ!08t|i^YT|{aI>o|gMm}ZSTCk<<A+t;;@+L3hLOj9_)SFwR+dRym?
z=LxcE7CY-iug37j4S|G+`a~8#V#*54n}1rYmz+A#DEZ!>u$%gfo$wpzJf!G{t@Q4U
z?q|rL8>*1Udb+b*$YlYLK5qeQqi*%)Q{5EXrkbArePfy=HYz)tI;U23-sEp6wf}@Z
z3TTrEBE7RVwG>$OxL##;RXqQx0-23HKltw8&X)`!FbM|BD3VptF?n5wyX3Lr6W{aV
z&X_z@#Y%<ejb!(FYF(`)7-Xu`u&I1j75K`h>DV}4T98J-*<NQV@6~;YNO`K)&uzl)
zPqnI{W+8JeD)-Yhn9GB)m<$mTM0S{1a)OH3(5uD%^`W#tmfh^mbB=iFT2Msq+??a-
zzSl}~VdA+P3@IySxQI!?@Zs+pr(nrVHTah~L{Fl-moUrjS0C*B6wb`ygB|y`Z>X3B
z&abxLN=>;Oxp-d}&muI2`0|X#t=XwFU>hdPb|=L;r?yHdO@CD?P&1qSI(4<FmZ>eq
z-260_k?SMDo6j~GDnu|Q6GsF^E+H-9i8dp)27owNmxf+t6FB^BX#YjSc1et6?$DJ=
zZilWx7$G%2z+3<V2%*qTSanG=n`S_$Q0eHab=dT*l~PG@4{FP0U(V^M_fl<RF*}0g
z2w}}p4<kFCjx&R*IqKRMV}VT_jGps6^NCyA?BN2fxj-}5+!#GSbawUXd(Gu<hpCg#
zzL`6?SuUSFAwe^Qhy8{FtF92q+-k9=!}+<@^REDzQ`gb_Nl(J*l)185AI9D;cH%&l
zKh4fdk~PCli}awB*=sL$H~P`moz1&YsB<SX?G}<$wi}!=MzAn!RuaRZ+JxFq7ci-)
z1veUO*?xfDbjZp>N(>Zi=qx2Dhe*&GRl1cv%Qzb<Kt+vyunrH|B)m@e8p#~pTKT<Y
zuwUO(%hDH_rH`OcMb|Am?Kbm`r_3Qj)f7g$JR_hRR&>o&=T9WueO{Ymh8i$yRT17D
zB^t9Sf5qc>4us<FlXOo&7yz?P&25vnY0XUC3>=(3cBQ=QpJOFY$cP#qudh{Kf~-oJ
z+Q;tgf=+SOYoW6=$i4TnVHh3kO4TW_XF2@IHD;kXfX+QX-b9@s#xkE%<6djo{Hk^G
zSuXQ4I@Xl4dzVKIl%}g{Gj75Dd{Nm%?`Q0>b^~qps2I^Py9V7L#$Lf+n`QOw{$n$h
z?AJlLpyBySmyq%bS7ku)k*M~p)!);ReBHE*K9O@OY)Tqb1cfDkgH};A8p$|2RTi~!
z+9&LBQUU2mlQIP?%qd8Zics-t=gX#6ju@(c!bQwYmHn-_9j%*B4M}3uZ!4bGFMBC8
z_1Me~l?@_@CIaUF6wouvA%s}=$)-_s*m(PXlXh?bN`Ey)GJ4I+O!7DFi`i)_p6(TP
z=fwJ3@VL=fp8dNP00({afE@4ZhVSjIQch66@k^R<rVxGM(c@O91W#3sd;8kY`}<6Q
zqa`|JcCqRr`BheHHW5|XvbpAZJJJE_2$6kv%jtZ|HgIWrN^X3PlFWycAkmRxTvB2(
zbT8=|^28a%Rt6m@M{aW$Wfhn?3%)l?A7F)8-XMggPQ{KamE~>@4#K*#t*C318p;C~
z=X6-HN>=B%r3V?5qfkTH+6-t_GLm6*Z^k9RkXg^DorLSs#ojZGT=tKky^y~fAL#I%
zKFSWuY-JEfP9_DFekeiRY+p_m0Y4j0HRJ%?GfdzA{dA86=RbxC3p))PHm9t@4ppqF
z*Q|bcShlP;uK(s;x2y%LrI0!-n=cQr!y~4n_WHa)vN4s(1<Q?c57=ty!z||d<^Dlt
zyM#|{+l`&X%|4Qo0y7;0>BtfrcEU`KrSxGfY{ypnm@+1*At%=A9eYK{XDz%SMaQT@
z(rrLp2nS%ZFRN9=O`z!<D6CH;U{=KPacWi34aP#7888A@zXm6Xh?b82iXnPT9}?c;
zW?$qh<lwAT4unV5LG$?XT|Z~0fMw{ed$^<~aZI0|t9@7dbDCD`1$|gJHFSOnBJ`#v
zgoSu(%4qbGPC2Djh=<tqytNohJxv-9K|}eCwN&*6U0{%6^9>Jdm4U4ZLtAoORe(NI
zC&L2TqS=N4WsGY})K>dIGuQs5g)1706DilZg4|08F=DCk@JW6jpW-AyP(*L-7O5MY
zWZ#an*2Bsb;vtZsE_zix;!l$1s2KXzDE6OtqUp02e~G91wWR*|&LG3g8y@%$mhFX3
zt5+qbA;`HZ-bdm;Gr7C>><gy?g97Io;-qvEQXU}{jqAK85YBM>E!9RNTX$#TiuxiK
zT+b@CyE7u#t@O=HbB!6j0~U83SK=SM^LoEbsJXsM#}^pN%0FC>;o}Ps@C$qaRJFC`
zS9d-<qqdJBeuzwB>aE&T2U#NXWc94sFgS|GiTWH5299Qg7{7(WP0V&hXoQD#``WK$
zaGs*Ited)jU7SvW>~0tpA(RLoYhRR&(&zn}Fa-hbykC#6E{8o(2r+Q;tOt#7CY?@M
zJd&hiAOVt9a$*o+x^^zXHp2y5q`&Kl4zTX|jtEV%IqvwdGP=5d&)$WrrLyp$%kk=Y
zFoe05rC?AQU69WE_Iy+@kg0+LBA7`<(0%Ee!akqE^0;3kUZ?2O2$$-g*re9WrC#h#
zdh5!WOe6ZH?XpbP^>hv1$9lOn%o0T?NLYV`TeaRdjykxvT_V)LC(7UV3zIe@Op^8T
z6TWvG#Y9N57<&3ZJ3tbc_{E8oJwWp^X!>Qxz7TC^hrK=ov}rCHx;P9ye*59>CGPCO
zD&g;_M_c;RSNycw+(@a&d)pJnqY?L-;;^>9h>pp+Zl(>qhEM-3Ys75FY-<qO12V?o
zBL}@lz$mxt`@F(6%T;skFTqRWt~}-OKI>(PM?)jPQEu%v+NJ#X8oD^REYO;=W4hT;
ziZIDL4ufEIp+KmmHAD=T2t-1z0)JTc+CDN!PG)ijvA+<fi1-bwWsWq?W3+$9UZe3L
zKGx%6qvS_{eBcy~sA$;NJrzk1ls3IJ9eALuqhYPRk4?Y#y)E{-h9mY-4G_m4ucmMA
zTICo=iyZ}%<mj~Mt>GMu@2$n%W#&F(8iw`Sz88Lla?rLQgGbcrzaOwTsu+^T9Q25f
zwaYpXw!>YsKqA3vsu%$~2DV<-cFoS(wOVpb9I>ve)hZg)Epgew|I--XvJpl$5({_A
zXX8C<%QEXS?&o49Yvn-nbo;dunJu(+xHG^O(?g)o#I&{+x7Kk>h{rYV%ZC#sz2PJ0
zQm)je-TB3c0|`HJ!wOr>JD$S4tZs#bt}U7+Qmn>2Cn7tv`qp#)-~pn>Iv)_uU#j>N
zl{S?e(<DsX=B4vpFLhIIKHaT<-2XQj)n7jLNc{gNA6rl6)q1V}l>k^Fk$8Sq6uYS)
ze69#}HCK>SsemcKz*w;m6hnHncx^W-mpu<%woMRJoT(dsbo%WPPm_~zYIw7|^mudB
zjS9SoToi7ed$SP==mql;t_1QcC)i5q&tVhSPA^(&QV{9D1r#{?6}s7ze{7SVI*-#@
z2f5sa8U;I>v&+qYHKh$Od;cuWL%D1kJ&a(F;7=X=S@EaNxC#5dRYHMy_Q@ccJG^Uj
z+|J+3)cRD9!9$QmFp`#3VR_9`(05WtPAx^3E3ssKvjeXv(R<O>LC_#F0UR6yeRTM7
zD^l-LDBE_wSgIY+B*_)A%c2iX6}Rdl-)z^gIhQMzX0hrS=IkYmlvuHR!WzAxrYEo=
z<|2{>6~Xdxoe%dS=b-%+yd0pIUTGaz`ow~KShYjOq9%|M5P0*2UI<&QI&O8_a*E0J
zLZCenlrdq!2cdNuL|UO2>4{qAom3QL(GRT=r1Sr>a!FCBMc22NLQJwaL|Gt)I>>`i
zjMmeB$(Q-ZLPmk0NZKjQ&9ey&4pMxN4F=zrf(jJP*nnpC7ZD$ZtD|E6Xwpil<<c$p
zmyZ3NlIsRtJ0z)Zaj7+7J|KF;9_-OEqaKnxG9+pzcx6Ou{}=^A=)g1)*>^DFShXD6
z2vo)}A>xykH?Zv0qkwVw!r8<!LckJvX*Q%&MqQ&RMC^pK-kUmSt<|nePSK~T^rYO^
z#f>CiHBuNFT<CG750X=Q;~xRyLVJ&%6R)vR^NN}}d{mr4^b?x4H({*i;y^FHd)p4)
z1>y3@{Ha$Z_?zI96>NKHIMYXyxxy$AN5<Y&gX_Ms$lBF&#j#yNcZx6S@BY8MWApg}
z8H`}7z6o)Q#sw<Ru(B=#j)YMmVfoiQ0#tVpavXH#RKEy)1<GWb)qQi-IgB4oC~3vi
z6rA_5Us4IxX}4Nej~eK3YWXS_YKvRg#WAA4NjSs-`|0>0(%$U!(4ko~atH|3RC6Gb
zG6xlOL`0i;te&p7MGXcxDZrP4vOw{f3MOiTk(7GHmGY}I4mW%XtT4$^G)*m5OSSO2
z;Ol}3XCH`ew6o6WRu)c)2{QaBF3XfD^HTE?>Pn||ZN*++!E*FK-Fnauluh+1`fB9|
zZDj^g8M7(%sdv@NFp%VL!dK)9H^itoU(xYpwKZ8r=}E4_*-$u=d+0f*o$wRtX^*Ub
z<is6F1y-a;gf4hTv)SEVGMUT-CiZM|E`hh4F-V%uvhLNz3HJNp-f~3;3$r<5pFa7&
zb@qOMo?`#FofV#pn)`L*bWczgF(&(b(`3-N`_Xo3r@>;rgO2kW+&#435L%Bly2{Ni
zydrTor?|D{W(baEG7Bw`%<%sDMUW0j({^A#jyUjLq~!}`*?%8FtP{@C6TeioHzkS<
z^xBG&D_94v<A|(;xZEKF|B#U+)ydOYOto1|dLxf+tnXug!9+B6lSt|KvEOYai?KPX
z)iuIv*S-U6Xkd1Y-31j3Z!w^GX-S#SD{o$Q!l+MP_|KFczC1F#t0jy+rZ#6z#r&J_
z#k{n=%;)r<>$*2?xG{JJ7n#CTt%S5X_}Y!F#CrFp*Y!(noX*6W81d25Qrqzq+wob|
zj`o+uNw>trbg`PN6^~v^=vF2RL+&)GUSKW`&JhS6%dmus&ay>nV8VpcMYpX3_SRxq
zor3)Ce)W+;*6~ijqg8o-lT1ctrAZiu`Lp&5JzKFylfN7dPS_YmOslVH`9#ujcw(h)
z&3)5Va+or8%I%PuzG78Bav!0o6V4dQ)DmU4`L2-a`y?diS5T?g0ImOmql4lC-#oge
zp+@DpN~uDszoR*w+|-7C$A0;uj3T@8GVUl{*b(w{H1bDw+<H;$u*Ul!wDStNnW$T7
z)>Qp`8D1@#QKCB1<_YP)lh(_Q8c;sWYu61XcciLbG=eg=4ronV*J2md-tsbx)cj{2
zu(9qx7(*a4$_3}dHJ%^A1?{ASk;8Z0^o>t11&6OZ)l`wjKz5RkICd=ERe33W+3*WB
zxbT$&==X?)C7!unCgG#^SNVx^HLt8ZW5V@9|2Zn89GZ3Q*#2j}55Y?9$GMp4)?-mA
zJO~vAMjOw^rjkn;-0<7r{=X21wR1aPDluGC_(@^A%pEhwx)>HY<(7j&8)ayjR4$5{
z>+7zc%Xy+F5mzp_@ZfG1ae+CixVY}6Q3tu*a!dCbHZGdVI;6MoRmokIfJaeCCTO2E
znVgXpDeKSfFD2%-MHI2KV!IA7UPo2t?dHfYr39|V*b+_-q$$-ETsg|^qdevz@vPEb
zs0kl8G%txUW;;v+b7?_}D`Nd0``R=fFr+Jkf&5q$OWkkZGN5%i@LXC~O%8f>giRD(
z`Y^IIGl<tqnz2&<#<CH7CTOZaA=jXRwc#~R|3DSZIhHI*mGPmGgmnPNnyuxikJ1KE
zcm9whsbJPs->|4v_?NAN*r^Xay4PXOz_xiOyf)K?FJDB9hn2OCh&L(x{bvM*Mx2ve
zYY0hx<(mI_b$-@wE}Un&RF_1qD(CDUgJ~>0c<ri)huv{hfqZ<ArAL(~hDWCz{4?D`
zUdc0m&Fe_55p5C`#^02F+%L^tdg8`^AV%W2lzwg$8Qw|N<-aBO_(S7n*6G2v=eFqC
z6a6w(=-;`nPy4G3|8$3of9<@H$d_kal>}G{MB^}odr%dzkEp?!hS|3;_)HtKLvv80
z|45xR^@er`&+?W6`E`KqwNzzQ5U5?V3LW5MKEBEx5zz>vLt>2t<8|LXd?gbsSR1Cr
zcJ{u0XOtvQAr>)mm3sGEH;YxX<jq3(`=a+>M$-*~&t6ouo6}3TUN-CWg3h?Fwskcs
z&ubZc;uZ3!^|sU8_BoCq`Nt)eUTvX;S;YdQw2z8{G;YdC;P2Q&EQXd<!m_W#8Wdm=
zm&2K=Pf>iB4%lr9#p)_AvHebjvvvy5&&Tqcf^v9AU9MTQ7WJ3vFISXU*GM~z;5Nme
zuT7KfH&EbT_u-&SbHDbn9Eqc&<kbj055ITsQk!Dd<auPiLPm<{O%%j58vhcwZONEo
z0ZSU8Ak{6t<)m-p-_vm8C}^WSHRQ?<ibzE4&8WZmSbC%wu*?IuzZ>XMDko_e(w$$M
z0Clgi*1A9G+q2hY3+h7;c8@S*pH|*+D4o_4Wzz`PHQr~;(lB}@@JQ1buU9$*JM5w$
zg%`nL&8HUsTJW0{T>DXFuLy0q#8KsuM&*kysflbyjo?O%di7qZW%VE<0Fq{aj~KOz
zd=`7Hh7w)T>F>)}uriFvOY)wTY@Rlip;EvYT`*+HVV}38(thc^0nZ0E^=gfOF;Qld
zcg{aXnLr-1uX(@ns%B;WIaUntO$sS%!Y!_WKc!?%J7Ypzzn!R1>8)|A-jgh}ZO&Nl
zJ?dE~D9b-qFqF8=Bf_2;mI(6|w)KuGhQBM;Dq0k<%8@5`DXnt{5r6+Jj`6zL=<Kf#
z&XIfE$vH%HY9=Bko#rMp=B9C`F8y?Whxjw?`}R3MdmwZgfo1G7QMoz;P^|owsIQB{
zvi)1z{x<eN&JoXq1TAK}X_QunNks!F#vZyEDE}Vop;yf6*|W@NfnuxZQ0#3gL){{&
zoM(5h9{9tBF`bV(_e_oa+l98e^B<0M%lw1%*`wHZDTOxwg&&&zRi$jwrb{CDLJWWO
zH1bR%pC}ZBrq^55DwE=4U*q(<Rpl(t2Y8&-+77ODJlZYPS8dLnxei!*^3^YU2Yt43
zpwp0fi<IVt4P9qW>k}FJJBD=$oT)2+@9(c#hM68FZ){X-O|8Uhx*gWXH&9v7{mro1
zMHQ=aYZh6Ak!(;#l%$vdtc`n|QJHJ0o6nr;23jn>S-+``;MB))4|}V3JeEEj*l4io
zW0nd!a;M3^k%Yh=VlSI*?s+lZD|RU+1VU$A-+NRP^-rrbpS7XIMD0p;c;lk$`kYB)
zP9uGDN*0QR$N`AAX6n*)Q9%ggT8fNUpq*`%9`L@J7AW-eGky)1*{LBV8a{s!U7doC
z+HxRwN7`@aEXkrLC_?uh|0g@L^R<DRn&^W)`!n->CtHodPn~m(3w4&OdN{h*RsmI)
z>Qp?o|FT7!47O*Uo<LM!!f9?2qv9~pwc*vS*rNZ-l7wP(5Av3yi5l{GejD1tFzx!m
zePr%XU#EZ@=Q)BX*xcP3=F24GfK7r*JU>RXrYOW$Bg`Z8J4+eoII(IXo=Hn8!{{(k
zza-z#NR7qa?*oTKu1g&8_sw%_7x3e&eUNLTls|V4JP(zvQ7sZuQZa35I5U#1#L|>l
z-7~aEaoo$KPX4Bj+9^I$B+I_b&9=#`z2gia3r*`kyS2Kjb|Ay!@ymfZ@{D|4|CReF
zuKX`7iE|n>&pxfP6-8O8_O^tdcf8LAqEIN9C-JezhuhTkaen$T-6pZ6j1QypBC6Oh
zj(zM`88Mao>DoTpP<VGr&4Zn~)6JmcK(=muaiZ2`F!Y-0o^RU1?gKufclDQnER8ug
z6ycknau<(*w_UTXhoO0sTiLt%&12Y_PWv6ao8QkrGg2J&RozWnpwoP1KI3G{F9Vd2
zji0uZ3J8$vy(+#hK8rNFoWiu%SucZyv|vU%hM>g((M7XBAsX5rTYS%0&wz{p-3?|Q
z!wqn_6I*po7x{;i#gh;lv1@4yv&;urM2Ykv@((+%2|mQI2Aon;K44hH1nv_bxEOq{
z_JOb{wT5!dHa<iOPMbl`N$iw35PpO2_14mF&w;y-xwh;aZ2=~M5(6~_@}99Jj!w43
z7Q{UmD3?)uWAtdnU0l;q$^XG+M27T?NfSgyr*AV)P%q<%q;&MG=dA50*QVON5|GB`
z56~;k&C(ch8OSK*)1twbnlq{kk-x+mF=z~xbp*+8X;h7ZIo-%#wAqP%<fPF(GuL5u
zuEr(zN`dOT`mPk|tP9?}^I2n3uev%n#k?sdUcsHR%?<N1P23(%*P1&L6yso$z^Y$Y
z#?y<u>hk~C5JkAv2M2e0V`0f)u|MSNa7G`kzf$x&33{w)i^SH5?B^o8lR9rmwX{x+
zwC1ZT6p+ymSe=cd6GGvHCE-i{?Qy4sWTMAdNs$+=)yvWFug8&Ia?n4QFB;_6|9p_O
z`t;vdxQ1!LyMO(%x!um2s-e>*^G0!?W$;nP_MSq{R}m4>rq%?1DFRCib3Vjwoz3G2
z)9reF{q!GzPPSPTcRdmR`*W7?4K!aEd`<tHAe=*NZ1*fU_u(uCdgpl-`H>zsG=`8T
ze8T(YapD}pN=DyEYW*3^`Gkd;wji>c^!SABUETU3zu6Q^`pvi|+)pgNX0n^Q8M1t7
zulv}7cTDjRyfJ+&&YV0neR{SMGWDP+kRk6;ZsXba_7;jJpB(|aL^evnsUK;#!r;T4
z&<C+Sf6PJ1e&a%vP5d7)o2S%Q=>=wIJ{L*J=W0CV`ZSbL0BFT%RKA=r2<6215Qit~
z8EhXE)t2ZHKS)C?zFRw+n>3O#g29T5jj>PDIu|{dc8Ya{&1*M!5}=DP@8Zf-gqK&U
zSWAcgfR+qpPgA+u{277Oe-JDe>>%jqH>KQcw_UNIkoxes!G%NNfP==T>PChSOq`*8
zv)jy3>KxnGb?abDm$hp{L_pvU7Vq;9SSx?*t#_OyK^YrAR9xD{Z*Jv%3buxoFPJn1
zT+A5(fcPvf5nJ~Fr5O2WzA7bcef#|-)+EW+kohg*?@KQ#C!=NBK6)%lg9s}-tfpc=
zXH><txec)}ge#rf_+}={)H>)V0o)Mr5&j~p-f?A<uZ*N20azN;K`WIyf6P62&3o_r
z3$q_@n$Ud|Z`er$Mkhl76RZKNGDw}Jqy7OjQ|HgOS{U;JS+K&Cj~36c>MW|z&JcF-
zn+2|rSaW7xG|5HmYtByjue*LI{}YtXn^DZdU6$@0gzrad?~4_!8>_|z&=i97ScNV|
zFbQemQ4e!bG-1VH8AbC(D!rIlrj~*#5EPH&Q>yHRfhL|-q!gnfF@)Lgg$vtTB^u~K
z3(vi+gL=5m2#jac{v9D9XMg2O4>!R8zQKzGs^0x$Cc{J$3X{+PeDtbf=?8Nm*D;2n
zVltTDk@(No-Ze>1bDPXTyyCEghlorpn<W#1eq|5MxEk&uFS?{fAmWT}jH}9tl704Q
z-=$&-;p8a3eoWuvzT=I~6|9YB?*hp?*S)c7dnbX(rh!v1(RL?%?3%Lj#9M2YW*uT{
z8K3BoNOw$8`1`Nrp^cY42vF%>@vnIb@Cu>Y%OvjIb&&;P{-;|tXn??jF_C#<5NK=R
z^pi+{U5Od4I-M6&QCuc<jaiA=YjrwbsgY`C#&=YbvULfpy>3@jn#bSt$#^NL`{~Ij
z*NrI}g0zH%zpgDD!p7Ebar5O-A!&XQgbXZd4t_Q|6Ak+iOM78WyK91u(28WZcWBeB
zkL2-MMi3NP+S)qDhxsAza3^Gahi0hZMT(R?t^%yc!i^7KdF3mflQhZ*vWq@<ybt$Z
zwIWUZF8~ya(f#NL3eIxW{e^<o1sS$=(f|o!eCKAi<HYS|-|Z%iB~+8Y$XEbzD(JON
zSPT;yla@|+xo5Sz=JE0Axs?s?g7K2b>4ic^MT6~9^A4N4PEb@RXzE_{6_;{@%Q`==
zDR+suj)l0+@8tVSV+rtkcv8m@-lSGI^NV5pFw?zCD@Rnm4KU0Km(?T`>kY;2G?klh
z<K3MbFAisEW19!K$+<bm?TCvD+_Uz4UGNPjV#4TiEGTR|UJ7FRN*1n?;eeFW^*L&N
zP_E}@++De)@uwZkG56yv?Gg85eff2*J*bSU|Fzlowr<lmaHU+2Byc%gWS`zz#j=rn
zUpG9Y#e0kSIvC}OY=4@_`9$_7u5X%dupDBTW8#?JVSI=Eoo%tvB%CU9KLk_2*4#aa
z$8TX3TD@d<5~Q)fTeNP!V`%YNGCAGqgGqSov)HwJ(kzY#HFcGIWT>`gY}zaicC$kI
zn^9U$7+r|-MzE65UTTZZ^x<03qS2%A*9tSpu{MS!tZ`nwp<f81&woJRPp~f#R*IZZ
z>Y~nCOHCWHs>xRyZvp(eH8Z*YLXX;B*GNNHF3^d*Hf|`V@^27aS7EjJb&~6Ip}BCo
zpO4QBJb5yG;TwunnDSO|Fif0eIRpCQ?&tqiup@O8O>jOF==U;Y?+JrcKxxi%20q)3
zQU8ex*sqBB!VZd{0jm)2TNzQ+=B@<ne91(<iAzR>;fS|r_uwibqx)gfKLKO6yAdf?
z#>W}{KTD5ZC<8E;i>jCv@8bJk*8EAiqEg8+p&IN-7<BCVG7U(s^|Hj~&p}p7;c*%X
z`a`>$>1Zv_)*qC3_($MD0(J00wLv*X71yj<#Sw>|YjBSH-1cj;ZR=g7E4<u^Q*d7}
zH(#QsqX`jwDrrZNH@F02mILFXUhoGYE)I9zQ$yWn!ss}*PQ#jU))+M&I8e6V-fr%O
zBi8_9R(oqL{e|Hz=3|>?WhlUyRU&<%q{2erzVEW&5E6SijH=a-K~R33(iB4sLYIyD
z5bRWS6)-S{{uz(e5BtV*)Vn@+srJ|_DB|f7PnJ2|tu32341X|XanPz5rVn=jSPUmH
z4ej3;{v$;d{RbZ!POuql04)hkn%-!R9F7I4hQjy|_@X9z&+@qODx=j+0Z<DTuPiw}
z(m<;bBlZg%4yQcp5M-eY%`}<^t#`MKS>M2uUAJBJN?E(F2CfbwA`#I=*{{exa;sbE
z1s5bZ6;>yr185$cQsqfjUISp>Z+?w~$pw5@$F}+^bCpTtz5_v8+W)duszQ~Tln+N*
ze=x4NK=c&hHa$#rPs0+fkokT{#?l{nS!;BQ-3J9S;$FX@`AuW@^wK$UNdeL5Z)QJ=
zl=K%W3~MNN2^=hv8b$Px{5Q3&4pWX1IY-XyO+dC7weNYY7hom@g2$Uo`D~25P6G&G
z3$MTCJsd#{^KcLVdy*Cx-KE1XDS@?wDzA*ml^BCBZ{r18%dRVMdK)ze*h~6dGgxU+
zXFTV`f-k#PfV|%5aJX!VaLzf^b+G50gS+P=yClrAPSKPy-NWI3F${6aD^eP4cq_9I
zTJb>!$qzUa(y<~UQp0@^E@7zAh$89zHCIKEg_=}ke)8WSb$<y`O3pRVdNPFy%}=3H
z+47Mfz{0*(^X=T6ezG&)Z-WBj*^+(jhek54GPAAbRG;1<|8<13h^C*X({EK}1iS3R
z^xtXFi`8@=EERd~&m+c`K)Y=w?u>RXI%iFG_()Bj_+q|Llcd%)I8>s$@JZ+AyYL>>
z)l@XwHH}B<f=RENYmDTPh3*F!oa2M}^Tx6TMvn38&dQs*+9?9pF2>H*ZOz4(*OPB;
zu<rRsm=%IfwO}r}Pd!=*^quGI;~oD3f2%q*(9l9Lrv~v^9Z>BCNESL$kBF7j$-%1w
zl6#D<(Ppt4gJc42a3^}=nyek~+k0}qNwCt0WpUIuZLOiE;eL-kk&>hOcP#+L*rA{W
zsKez+K&s4CDAsGtGz=&%o>n_rSy^3?z|h{)?q@z#&*D#%1bwDbP|t!IuT3c?$MM#1
zm?D-FtA4pU3j)@gc@sxq<yjJ07DOj>8#_u<W*v*foW;fY#!VYXx#A-hcG;DzN2%Wg
zn`Ie+6)u=YT8^W<5Usd{q2ES4ih~}dS%<y{X`SvJUn42LJh}D`qp1YlFf)onw?-XM
zEs5iZ3=*IBnP9v>xhkGQPS@;n@{0R9x6~7~GmHz=*p;4FMYcWK)s77Im3UkarAG=V
z=%`rNUWJTJ<cR#Q@LtM!x$pO$M!Lnzy;jUF0s{?4Yr+M;ke>`F>YiI?LjE&*P*LZp
z->rwOl-gJ$Fr>`uBhdi(u$L~iEn--~;m91s6*6G!H+A#iiYu!*4I!n=55O|37dtz2
zt%v5ihuR0!w*=(w9p1WRaG~3cvGilB1I1(f)hZ~vfkeA?V&DAS%DK<SsIHoZm<O=#
zKec{Mm$$muC`U>b6C?^Usku{w#RL#Y)gKSOuoaDsj`S^WUl*4GJuZ}?>cllJ{}NN+
zu&0cK&;h@C-?IJs3&i&ikI(mwq5qPB5aKnBh1S}e4VLOhkDl=l&ggrHzQ+|DygYvV
zUtoXJ{L9XZ^OCb&o|?v(5BRaNdJkl55XGvfpZ`9q<53ay%lYsx$+2&+)fu|@e}a!7
z2IpPDA~Z#OmgbN2j3q#$B3o$BjOGD3Cfk-utT7`5)HnzI{Q8bN-pEB*gfC9`{SPq~
zf?KrqL$y|cST>kQl(exMw}>bYovdBbb<MX{))@uG{CN?+_bA;Rba0g~SpwHc0e@Q*
zXix>l;hT5_f^bQ#vX=?r#RV6WUDL4cDVL#cKjczpsn5uL?<P))Um~Q+y)r1<a|ybj
zpMqDloeX8XiY4?aY8>o}#lXbMaJZEE0aEg}KK*mZVr#c~UsoIy=dsBg6^y52qU%I|
zRJ<9FGcpvDqz*kLxfv$v<+i7XR@S%hhN~_r@rAU`(R<!{euVya+(B8C)h#ZE9!hrf
zsY4}-@IK${siRC1b&G+Q^l<4H1jS9f|CY0`*PtRb-d5-E)N{J3<F8mNM-d%@iLZRi
zW@P@TflKf4;pF}6;8^Xv0p@)?&bn!1Z2EqX^!3NPgR>lyZ)`JvN)B6)Ddn1II`y=*
zuDD9mlurK>-_gh%MzNK9ddwg;k(?Aa)!XoKQ5uaqzjix6KLR)SQA2F8kV8F2Y89%!
zu*7~By*sB^Xz5U2r#ue1H<j4yxhKgR;EwIcUD*kQu>Q>|_`k9kWI{{5VyLfzDDG-~
zC4kWbjVktZ`i{QkX4)1Q#rFxf5a%OfO5Me~H9}b<Kz9Q{`wy?WmnkYN-G^{TFw1WD
zps3LK;R0FKnv_K$#eb#@3SPq+Ap{AJcEWAo;}ccIZ|iPYr2<h^JzXtXO&e(W<4h!k
zLb1Le9*iuqU-`_61fj%Yn0|IR;+xI+*f2yH)@|N$NR*c)VO9lzBQhT%t8>*KxshL|
zqfM)yXn)<5c>fQ|-U29&XKnjl++BlPa1HJRcXyZI?hZ?U;1=8h!QI_mgIjQScZYZL
zKj%E(v8TTGt=g*Dnwjk$>FK%qcU^sN^;8576Ts*B&elc+AiYpg=b*wR9ChLTLC)zt
z##YNTW3>OYFZNhs@rP56fG{<(?V<begN(s;j%f}Jo=~&BM!;v|66jmPLg~bEIo{8!
z3mKj<7|(sA+%00<Ed$zSF2)+{gmT11g7{ABX};>sQ`<BDFd?iv82pn7;Y&uLl#gJ_
z%(7q^f54zm-alCvVs>}Ryf;&St59mgru_~J8H#!nFK9++_1rh*>0DiMD`yO>-}-4H
zbgX~(-Sh|jUOB_QyT60lNVXC`vS?|WuXixAE2J2L+)3XIC>sKAb$xwRIV;TcaII{3
zKqb7jTc>kBX)Nf6^Hdk&G5&AgZNQOo?XMk-%zo*8<93>9zcN{NR<1*3tH!uTSygGJ
zLo8xu`_Lt)c`t-Y=!6LPMKCa4KSIYEYWX;IT1>zI393jh`}XhDBHlT-^SkAr31R=4
z)#d+pD%jS$`T6Vi67Bihy9SV8Y40KMA+YJg3ZkC`hs24%7q8xxp}Nnu95MyA1q`)N
z^)3vmGW+n(K>Q6mZ7gjBT4pHKgZatje6?wv?!^tZ)zxp_I!zimtW)gOtg7BMNf?qH
z{uDv6#8jIa{*%X#2e~Lt6~|r%=l9QES<Y+wJPX|B@=XtG5o5Rj;CQOO(w8zrf^2}a
z0M7JYPf#!$55n(XkF|D2yr)}1ku(7g^UViquT7?lp8&is#6Ri+t09qjR3eNCD`oZc
zZp+Qg;l=XjPnSQG=036-bw`hbb2z`1ZNr{l1G#7SeOPUY2<xldgCe}M;r5BH&Lji_
zhX^trI==tRca`x|Q$&N_PEuLVJ9ZP&T_`wN`B0nN%wdG*rQeiW3mnVnyx4#}cOEA=
za_&gwsEpSB&D+z@HyL!D8tkYL1!V%s(7%Hd;-i6&F6#$92sePJtv~k@nQaOg7aEKi
zT2WYWng)li3<*FDN9NN%1UF#g#sg-PlmY;78zN>~D1NHy?Sd^5l2E~~!3Jda!M+J7
zWZTaAX;ooYAs(obFv!wF%!4OEi3NTK%si!7We-x*%B5iBdtyesXm<1X6mu8dc(_FG
zuwh4{CE%)R7dZ?-YZLYBM^`}PqpkKU^%>C*qV^dbvVjXBhIZj~*Pt;Km;~R~2?zIL
zRrgTNqDHUUw($06q;TlHnt0LBPj8`PRe&Z-$W*W3nn?WU*R1U|ln|0jIe-4(lV^;W
zO|5t})E>0Xa$_Gi!DnWSD?_47&>S}tmZqkbwzcbYYxX`Tu94i}+S#I*n!9+kY&`4c
z%6_Zra=uVe3{G-<R;*h{=+X>kqg9S2)1Q9)!b`+kHph8@$N~2Ir!LJEtrclTO-w3c
z!=2aZkf;v8)q7|8sx+whWjZ`32`@7W?c_Jry=ww13&uEd;|;qD%I`jU5}c)kd}-~5
zId|rj?*<=bH|@(Ara2FgI0QgN!d;a>yw=QDd_QB1AVhD5E!iq79>9-6O7z0m4bluE
zRkI6s>AkCBBl{G2nEF=m3f+pEy(1h^qbW7o2yUpwv62A`XUP@;=(1c$y0>Pa6bBcQ
z)l!vq)K)5g7sA%tM=b<%_@p{Ef+r@QR+7Wr<gO>@o7Jscy$@u*!OzLigNUrwU&!O+
zVHK^~p$k65$Ac*R5KYEt!u^eeNTv`2z)hyER!~A?ZLAw-U*iyb?;;#LDx=i%trrz~
zI<$2e(Jg!^r@(aS<`#t;yf3<rOH@oX(6NS<i&4zkB!l<LW}u}`cy-ON=C>{S&(iFY
zl={?V-V=^iIa(L2*(4=PPx=VkN3}YDPU&?k9yEjeWL24R*i1y4?_r$1HZ@m@uTDuW
zL5{g4eE=#I!sd@OMafhZ)|+p`Vdm|d7bFH{oGD)$Q&d=kghx0(%fVT??jsw-wKz-Y
z-|h*GjX=lO*J&*_&-^S|5(rItDu_Mn<F46gI2tF!6hi`s4r!IL#+qv==5hb_E2wt9
z<F<cwS+BWfkHgbh2P0osqrm(Z4<MTv_9mvu8t>QLw7BX1IGWnr-Opjaa%fwl(tL$F
z-KqJ=tGy9yiK<VnbjPDGD>ja~CC-I3g=JsfCD+fMn$UAM*KSRp@qg=r3YB+u{!?y+
z`LA{WSsF$fuA?R-uFlZ{o0dyW%}T=_=;NoQWz;yv{1Z21e6tZHh)w)UNs=D|uC?O*
z_}$x2v}Rg*mhdTd)|J)@-AXJR+GRKG1gw63WD}VaGCLFQUty!uzriN;e_KsOB!uso
zd22bF+O7lXj^wbTFQNrio7yoMY`74^iY9)!g)gRaK)jNNZ-v)s=HwK!1a6~;;BPO+
znRCzI@@UuiQmLt~ZVUN(s+jthxID|36tye|tRfKtsNn;<fCz~U<SuH?@;bGj+uE9z
zIaU^kY?JpxH?{CU&zo*D8o*OM+Hn$^`3>PGsYHWSqT>)tv*{$|L|R5eJ}@I}#tIq9
za+1ELE!#naCqG*$KMrD&upzj>SY;Xd%?;waZXzX8col}5cj-KI0(PZRL^k%%I%a=J
z3(Ezlg*dD-8tFnzwvocS<)3p9zZHv=;eJX5>ay-us7y@40^x%dKj)Sxg88`}$I=tU
z)Vm)L2s!@LX839)oPT%sLkJ4l*;sqlMHA6aUF|2CLMR`pRRk6w%_Wd^Myp(@6=3q7
z*ZK?k6}C#6&<}!9eBqRkpIoSzl2ak{Qxw6F6`o|2UY{j>2=`14n-#zX)NeBU(g>>}
z%|tI@V}ao`_86>0EKD{Ik`omnJ7TTPG@dUQ6MYZOX(Er(QDtK{bI=Vx9KhwhIvL>6
z$V{gaEmnp%G=xlJFX@_i>!#6gbgI{mhfYMzhoS`#F1>x|yP%Kyh{{;uZ3S?`T7-Dk
zIW>!yOf%t3Ujd58b57RsSM@{f(AI3Df4o-cFNC83R2&w?F+}i1t=r>)$1*ektHFk_
zYmvHu!!_K|esX5`K>FfNHVs-!By5Hup!LwSKG|HE6wZj%y;@;k;So^bV`|_143&SE
z%_3?DHwy!;{R%U9o{D-EIUrrW8bEON;ixPj3{Ux!i*}~&?t*;j9N9+|QUrrd%-mzJ
zTqvL_J!C9np4I&V6!K33F_v#Jy%~p^c<car6>y<MhB?kL3#u@k4~$IxXdI4bpKBLs
z%<Ps{4vEQ!xW)Q&#WOb1V(_`$cC@1Fb;-a<a$cn}=xwhG>27{g-z~%yfH7+ku)_YW
zmAN#>=_WzLBI84=PG|If0}J3%p$!ts`0yJXcIWbxRoH6J3NjjvluH+&*sQ-#X9h;%
z+()R<*<l4X+*5p;WM95!pkgrX%T?Q|o(R`WnVw`1Wo*Fqs0tr?`?~4SZz?YvF-_B2
zU)m;P&dOR$ul&2%wy=~HYNurGwY)xZPO@-VYv190GPI_NEyrm^?^#~22d;HT)kiF2
zz$t~5L1r5f5GKi0yAf%Sno_ZWoX&Nhy?BDj%4vIcvmec7r*v7w!l1Nbx3d&y&N)x|
zHTOQSF6?>z?bk4WJnoPDYRDe3Wc(>07we$Kr(!_vFvX}USgiR-6lJD;1Q*?YhC+=M
z&vC&cs#c$<(a2{H=V--wtwMGl7;k83m}RIyh`Ca$FJi9y^En;nR#x}R52^h}+Vw%u
zVn)pVi#9I$`KmXK^T+ktw`R?s*CAllX~;XTf?AIsnUi`m9&s~c0ijvW__Wt8Dj66v
zdrZ^giTD%PC;eaOH-$|%+t#Ud;%o_=fc1DG1dC1|fb`8aPBQX$+_O<ks1UK$ZtG8Z
z1bEyD+#zOLHi$sej1Ggy8G-uW71?sU*Fl71w5Dpg2t^A-(K2NuSb))o{Az*fue03M
zMV9ZVz!rElB|J>wA+2M2S9u)ajQrVKVrbk<d8T3Yd@(6k6BqtDt19uTy%e$PKW!^D
zdR#TX5E8h`Gs7IIliJkIwpx`6dg!8M)1%(1zxoi}cQm_fYk}->djXPrg`%bI4aVPu
znz)>DGi;jind=%`z*1%5g(%}&zycfQkao<nM)$e%ojw90l+Fd)wUBP<WFpy@w=C0X
z<G`wPB0I9MXM`Mz?NqeJ!avP((}PRzvH?QU&zVdR-#CLs$wZRy>Bo$TU~Mwm#X4|G
zM=jo=a*8{7^)qvG)vaw9Q(9<Y2!|Gma@Draw8=)H4eL_?RpXnsqoc<%M<&>g_@hSS
zzvz(=0G1Ab6y#$w?4V1!-pz2WZ)3Wrn5-PO$hUu*&NwmWkIZUhHW)*8VrY`2k%GK8
zd4DrY_S=d4>Wo1l@Xef|s665DthA{TLexC7PzwO+6lm#EhjO99I!(S-u^$1(T(IhJ
zH(qL&Cd?i?HMfLhjdRj+_k`Duz$2xkdu?>Y4sc;Wa=7bR%0K0RPQEKBKXmV%)JG_o
zSkizXVK42{sQcI%zMWWe)B`S5W^4OZ5200kVF@yHE*Q$$SV{UDdRJ8ix@=Z$Wz8zd
zg&t*1uigreb9O>R?02O_p3qs@V78+){IiN{b||6nj&`_leUpW|ULb4f<U(w2=&~lV
zvzeJCtX9d_Fu-JWZ>wv&qaYD8d)v0gw_dDT`1InZUuK0V)t0r0&ky7b;yDxL11`}r
zwNBeFQLea4j1Xmd4o5EKtzgu1);`PqTC{+H3T<ZJ69*ZIR!d})Z_l`rBo0;C9qe=y
z>L@n{HMI!=3^nv~U4FE@I#{aKS0YHw`Sq`I<;RU$%0U&GnVz8+NHEcrJYNP%xSPco
zbKrH{>o{=d6K_-u8R}?rHQUt~!V7H!$X=`RizOCVo8(b`venk%CEhwb7REIu?In_y
zHy9M2E-aE@?$}jQ-x|askwM^w7qpW_ed6S}W4l?N$Jgwlq#d(YrJXL~LX5FhG7>wy
zqm`11P@0}Q|4ti0=hRXc-hFm=Yr5CqtIMNs>K=}a8C&}6_?$?)V&0*QedCNrK^kSg
z;g-!Mb>Wa9Hg7N4mf@;%H06J;=1>w@;!Rb3wL~SMt~ro`sx#-{BJIti=MzO6cVa4d
z2wed&hth58m^_Qgj9Kn`9a)qPW+UDV52M_A)HT~YOLPd0*xa$TYt_A0EIEyC?)atP
z2bH$^qBdpS{Nstq<JB#K-TAL?HF%NC&giVyH*=Id{as(5=F14Hm{Diqv*xP6IiS(K
zuKKT_p<%t8zokO;ek~x$7mnzmgTYY7RM4R^H0cJX!JO_^WBr1FpsC4BuWXqICXP*y
z|1+V0q=1rm{IE97N(K-4%zFDSB?=0_!oEv~OYjW_V=M>w1wK|W8w{GcHXHDvKi}D*
zbCbuyU4!E`MaTOtZz|MMwXVWfY12?hC023M05MFv&&Y<&+04dL6HsNAWbE79_h~d~
zAL1nt2Bi;ibmL-go|OPuqmP(l<*$|&Wyv}(_$C=4@%I<_Usr@cFquIIdSjzIaLUUO
zJSm$|mLAtlAJn^qGJ_H9>eM38a+1lW_Ei*f7MLwyF(fExvKF|~jVh~}@^b9xscs*f
ztnSrmPDi{DcUPr9&nL_lNY>o5X~dIIWxPW=k#E8GKqcURL|dR&rO;{IV~m8+`v8&A
zkhJ86pQ)!G>s}pYvb(wR^R0Kc!bxlsuZq!D1c5}cf`$@Jo&**48ge)ao4zLa3OZJ<
z)Ri2lqN_chlI(XW7h}JgrtyQU_;kS)|AyWoy^6Y(wvj|ak}Sg^KnVL4m630VpS|ZX
zIt~f|7aYMsXb46Zfrgz;RwhS^I&MCcL)`O-sAVq-ssa)`0F{?hnxumCukS)6&1eBa
zf2|*m`m+)AUDEFFI|@0G|Fr@Z@;g4--!{gsg#K;sfF1F_?F~!8N%p@MHBKvqFn}I2
z$SNRk=GH19Au-&9E-Wc8zjyr@78V8vx8nu;Qyk7`yPaFF!GVDwVIyT_^be}SqMAwk
zo>vrE6Z@AQefWQB3LOw``gZ5l4hIKE!9wOBqLiRWEh{N`;nn^>+a)R6^v@3t4n8L9
zZe4l|g`zhxLZPFJOGw0j|2{PP*LmjrpvM-s+i`0h)<oX|<sOUo{Oc4Qs)X!>J^6?}
zS&D|Tsxn$Ve}Di?a_=V>UFWITZSME!qg(p@og|1|^$;c0nh?UBNM7_*{*(|GXQam;
z7#NVx67U^kUx?kL=-YX?+y*hK=nl3q_yK5XL|WU=X`O#T24o_>N>N8+7!x>xru}+Q
z(dMIT2+5ClGy}79YU@^R1&XRxs~wr$-zT23Wveg2mvpwzcFXWQ1Y*B`M|XVg=dyR%
z=n8;<K_(FN%P>m8w`<z0XgzB=u4o+!I3)|<m3LvU_kB&ups#MJ097jJp&!20H91{!
zdWMog1U-@I3>_!smgW3O`Btt43?|9mK3?h|HUO8ekV9X{+d3n_HwlR^tGS8j#2D9X
zdmw5snh?Q;+i7Pgj$GpIWU<zIfibOsypH=;;++^XYUdb8w<lIR)k*R=aNRGrFP*C5
z-}iByKN-I2F3B%~?&GqLhtL>epgamZAp|vE0%BEQJs994SP%eV0N3)zFzDK7BP+g@
zviQ@nkc5laFw0jZ!P*AiK!e~1lGQ=$Lp<c1`&X90B!y=1=p_?OTW-dJ-0+&Ot`Ce8
zLir&l(S{6$T8eDc!$G;ir_&%X@*0i)_4~krrECn8YqxgSr)-sgVsczuJU3iiu#c5T
ziZGr!1lociqQ5}8kss<8y4BT0M&)PkY>lr0IX)rD-JLQfPX!!9#{iI+8<XU8ld_r(
zInM4>vCOaWqX|1&;PR80oOrQvRXxBVpBw~AI^{y~+hcymh2nBM`8^PYzq~{yi<Pia
zjdY_7U~@fsw!G7kIg{@&dd)aqf3T1n9#5XYF#kbk%CS1retmoXs}Y>Q(fDYl1-KPn
zE@%1(-Oeb{&h5~)^xtrUb!I}FnQ0Umm7LlXpX*z3$An?=Z)YLNKo<U)^}2OK9Eb#6
z3ngqi%SUy)YSbr`T+n;dK;#}M_Y2(Vr<_(vo~e$A0+jr0S;;geQ?dfJ&B4)h!<hyS
ztux!(h`6nWhKhpN{Tp1hwr}9LAqJ3eB$2GrxMr|uNnD08C){bNe)m;7A}kJos)C)U
zoT07?%6G;aHSkTkJ<Lg%z9*KJQ>?|vThecsYjMPN>2orESJIqzwQ5_lJf6zC2Osw2
z>XO>@s%f<d8O~?540f%qn*RVWf1#XHZq3>n@i=lNwUdlbTer8qzHew*(a468w=I<I
zQ>mn1KN`@;u1|6~B1fEcagmu@g*teq>nwZNq;|%A`e1W<yA%gE3~)Ocy+jg~&ud0v
zOmz$*kdXU^CSJ#~^oGt7WUNKVPC_m*PLE9A{qRC_d=|zLibI7n#rxI3|MfOBOo@cw
z>-Ba)gyYJijT~4|Xqo7C->A*w_e{)G21;aIYy$JO#3yL#9vG7&+tmgWX?z1K9s|f#
z(usPz9W$bnZx5Ubb&58*;otBeFpdE&BZ<<ruQA0@jBX@T>?D9n8CPNOR{cLC4VJu>
zun>|5HuI-Cw`LR4=$6&Rl}O4wWn0aH8YGxvzm%HR34Je}Iif<KMg)H)KTCtIZLd>W
zY<3n^tM`RvxRn#eBmbl((+L&HegJ!Fb54vGR~p2Y^54nDiZNAmg70xeYh$aE>6q=+
zUIV3cbA{|giYqB-W_AKMyNG>C25<o%8Re?qE0D$`0<?zu#(-LbBc&{VY-BtW8H7-}
zhl!f&qJ-I$29loG<*+l$=o`zq8_Syw)YX66vYu4jC!ST5F%dh|_D7YBXBK4Ce19eP
z#Sn|v$C(Dvn~u)8Ox~*!&cPEl`ItwlFNjM$>M~gt%{k>CcE=JKqK7MJtWcS`R^+rx
ziyGwSnrGYtO;Ay%9V8P^UquWvRm61#cVcORZ*E)+zj-et9@lRPn=Z>o)Z{b`8rc-b
zoOWr(VStA;HrGeZBt7EOI7ZWJ)|{VrQ*)*_nGRq$5wMdl4OMrFB9hu6af5#{-ud;=
zh3>a+7we2FW#<C6ee1<v&E>EGXpD7V^Q3CS0-lJSfj-_9c;2qAOIX2z-W89g22+O$
zYiCXVuSr<8nfH}~ubbT$4La%xzQ0vkZB4Hmu+)g}RK=|8+fQ7n0_EuLPu8!K715~H
zPW4;uM#CG<>W}%T-hPqJJ8!N22wAYznwqa_Ik^_(1igADEGHVUO#SUjXxm$Jom><5
zZ>Zvp75p`uTkfuBUKr>`1QyquY)y4uM{cv;?KzV_VN5raS!^rPi)ynm`PTUBjE$7Y
z(JkYtCuevxb~idsj9fWDk+H?}GDb6p-T?$n*pW4Lr4!+Sv<9xfH_g5wk-C0?vJRi7
zfr@g9A^@IMApx~>-M|LkhI?BUvx&jfi{}7Kye`PuO^W5%pFav)8oj|zuB~CH&;#$(
z%aN!V^mDO4^G`M8^Y>_}|41|;r~`}ir!*dlE7vw9aFVtAP&Zslxu7wE0MD7H0*|Lg
z%0KYa)?z_Pl${VeFiTCXXb1y@ah8msfRvf<dGoAn;Mu~Ys*^>us=%yO9ts5hZE$W3
z_hx4c$>QIc1LrINLT!E^QZQ{IY8u-R`%ibP6(EI1zEq&`(U@DkHamC<(o-y&Mycw|
z+|Tx0b4cpBojo|Ef;b2*If&v*u2^0t;f)K9#s<fwPyXZ|GibR(_IQBKqmfiQTvnjI
zVebtcU3dj=0CA`|j`bQsMwAOWZbuv;V{_AJo!CAEErlmM$>Y(f^78U>3zRi_@A>V+
zSI{hmxAJp!`t@a}gVwnTfm`E;jG1Rd{RfZ58Vwz6Ti;EbR%9`2*98?pi0sAI=k!ul
zQsE!oP7C<!C7K<LyHWOPZ8gW9$kmm6^~d%0YE0|PThxAUIIRQ#j|h(t+>>^;_p^2;
zuA~ZqrDtiOlb`JqF)KAsHT`hswI1DWqo7LYOMm!yEzl8+K;|*Lzal7o*GUrmhZg_~
zAs%~72LA`2%V9jz&bh54X6H?W9;3l^E+A$QL5ZXd)YUNRvBlr>+#S~eg%astvXzGb
z0s4hV#qo646J39>6e9qrOerk=O`g|NbHS=!a#(dp6aXzN0;n-XH&9Aq0}-l4bWn@%
zGtjAqiUf-!)v<wKHmnJv%PJjm19Pi|1FqUQLEy>#;I)WA7*hK(c)~(tyL|}<yc$5N
ze?FQHcB`VS8gLnb?LzZFN+p2+=C?!28nna~uWIPcX=1(`j;)yhWX*KC!~xC9QXZK$
zT0!27BN;9i{XDBXp~o&f7yTm{H-|^ehIN40@L<4nu<GesOZiy(wi8Jqv2fU#t(|S5
z>F7(8YFjIF<F5x1#<R4`6Q*v`zH%czFz)h-Z6p+73dWpUaW*+t#J~eOdE9SsG*|8X
z+#WTXrO8n&!1I0lbDi|k9m|M8iu<8?cWvTJufTl@AKQh>_S+?~vy5{CUvJY{^$%et
zfEt{bsF)a-`-$yKeed-pT{lYGG6g3TorWiSycnt+&B}%6D^hFcX4$r(az$NVw!)F^
z57%=(56I0Pmnnv)DE>M%Tb6Ty0Hpb+l~IY&rILZcL9iA7^Tv-6E7QbZD(sxRxD(+d
zuf5u*FcIRgr}P2xn`7&O57{>`f~sHEz1Rx*vdagzhb3>IF)zG4r!oj;7^4-#xE{1u
zjil7g@DL42z$vuQ%l#DFQ^6=J)q+)bj>~oHTRQ8Ls__olxQ_|Wi1C!Llb?=wbO9iY
z$KdPFRX~&<q{KMoGe^5{?6XS`_!2GZH44f?`M)r{&x00cM9uX`?KLrEpme`Fts|{2
z9IWvpWWkx*Ek4$_Z)s28&w5i=>q}&Z*ca=3tgA|!Q`-jt4-GJpSmNk-)R|5cU^NL=
zuW#SV$BkfTx;3An3AILL4iAqvMqPt2+J}lg2!~E#`cD7n&Sp4_Mhfn1ReqRwLnrw2
z3}eL39BF$@O}xggP&0~>#jV=GWGhmW5s%Hxn80(p`rszKI|86l5gxX;x3@3_F!JB(
zWd`_(Py`<+2<AuJYhpac&45d;ow-8Qz)U^7hiS1;O`@26jAM-NseK3(mRpz|gWGY1
zSNN5!%k%eNH7`Sr&Ji@d8tD_yk2Svc+<Wj9gA3rxqypIt+|jT=H)>4Al-E6h{avc*
zvCI8H<IMX8dB_isPX?z<h>gnmH+x_suXdDIIzD*3e>)X`7a<wH7uwe=n#b%~O<K&~
zx?R6i%{~eLh978{=rpd6nsZpT?UOy=-+*nthbu>kWyqHLC6yL%CEGlecWsMizB_5|
z?tbiDP~g@Xm8Dfyp(bOYhzWh23?<FE4{Ms~s-5dxWp3zDrN_*r*j^&8uIfI|hfOnR
zx?NeOzE8BaZg{Y;Tf~X~>}n@eKAzc*e97ye-FE}(J8K(vZKR_qS>IyQ7d9f-k1U}m
zK*PYeOZm*&FiCy=wW(Z*W;#(!bczh$_xlO|*S%#*zv<j8-vpP(de8!L63z8ujQeqX
zeoEUhjfCFgP(wce78lAINi~#0o$G0_I&ZWRW`mF){HP!{&6>F5J?z%Kon+MWtzX1C
zeG~$&@1Qv5dy+1%7cG(L*TP9MI&3LzNT%WnycfSyIqbWnan2a~x5f5}&T3LFmb4O~
zFYb=N`w8LDWa_mEl__+V-5~ADv^%8==j@`%Ii>%GDbF?R&0KieDZJIRNifjzdUg#z
z@QOtMs^nY!O$aWaj2lNOO-}0^j7LJ)1JNbgg2vRpSmWOqmJg6h6pKTX$S_*}UO!sS
zVH}ILmPiY3AZ0rx23OSh`5g`n=&D_qw2W0J5=T|LU(AE3^;E)syVRR0R?CkpJ8H6l
zu;Er68J`mjz|E?@Bvr_T+Oo-%&&pjZn>hr1ee8=>PzWhThOvgUSg)O_Cg5Vo@d8D<
zhl`;17dz*tZItFFYk6n?u%DZC;7(_5YQmz}<Ju=F)QQqz6i0-*VWK&zv?6J;vc3dY
zKfDH?7p><t{GMj5f4!pcZ_vrLKAzqCX`J%k&U-Uy6t4QX?=+|=3`}VUXpd+cT>kK)
z6P0`_cc(n@J;A=mH#qdRxu`A-G#3@_D_C#2nv78JP-u63DIfH|-H;*8CyJ49d`0(u
z%A63m!@Z7b#adv33*~uQqFYn3C-iKVzq!@nPJnZCW$W+B7prrZxQvc(Pvm@Sz27e;
z>{T(?M#~ZMxK45Fj|{3>Y&Lo|(s65;Zv4%9!Nkd{Ab0?D=IRK8j2eSd(b&y~c>Eke
z&HAMoKwkj1t`Ol#QpG~4+>8$FKQOo+)%-j7B~u?CPHF`c@h-)W9nJ%M`BaS0Y@xF%
zWY@s=gUCGB7Pce#7zBCiD?yOANwu-K%uMXVF#$GMz7rm>cP#7G(NLR6CUFSxn?by@
z8bf_BOu3xL#+g@c2`oaUSba<uCX5~*IA;vr#S_xVz*Nap95Wa&^R;(*Wl4S%6nYkO
z$9?c0>Njw1c}8gbHUmGzy`t7^i1@}79=l=zwlA(<=?)rLqs@?qiPo45MpN%k<)^cE
z`ringilE?fAg_4)J3HUiOLbseh{W*S;P=|%pC7+Q9gc?(`*ImCUv!c;EY0e^&kPda
z6LVpbZT^%X^4dB;;j~!uxX8EmKv|H@6GiKPdnn%Y=3HB7E#6JDZV)Zv77*xgyKV0z
z9$2csj{&`<YJx;^U^oOO?>)|u?(G+c%4MtSsKdo#vF(@uYfDcd+7-XEJ<FSr-R-P1
zVwn&$NOD?@m)Of!hO*BcA(}x}PrBw28&1Q6^RQ!CkR|(LZjCEyaVq@b4)6SIFceU8
zc?q%=+pWB!9uBn>0bwi6n@JVogI@V+m0Nd(b!FvLYj(V7$7~`zjh~fxshd!28fgxg
zkf=y(+SHUlm%^B2jQwG^O&t>HM-ezfO%1q$iA9Y?J5*p6IFRrRd@{YEU>!-sn;}KO
z+5ibSTSnb}(GS3#vE%aIpEp_j7Z5H#Dx_9HfXX(@2?n01EWk>5_3!wanFvN60U5*r
zco}r|>_OSkHTr2lo!oW__uRnY8Pf`$JRQltgT^jyAH$=X&Q&Sn_=-h<kHRTvJeVv=
z5nkJ&U%7C6+uPgACRbQkXl`y!mpC%Cwt2bc&UE$B022ysx825uzG{|}lyo!8rz3DT
zjOIMi&i#Ss>|VS$JzlGF0sqClPaQ<Wh@+`8ue|JKQ?3#pf`WoDq@;*jF_hcZDk-Bu
zk%e>UZqZ@9+ev0-x&gssuZ#jkWYlBOy4$j?edp_)Qj!Ejhx$|kTpaeA9-AfFshqU*
zlOerh-<Zs%cclUzF+TqGr3W-LH(Q&&eHAz#5mO#00yJLHt6HvXyBgUzFSgY(;6BK^
zJ1>TnBGxo~9C?x@1$kDy7Hb#)$V3@!hu9tY1!4>9t5t1HZna(`6k~R*Gc%J+)qgPf
z$S{+dU5bYgN5OAKy5%K9RGlZ9Ds1hHpXv+6VpC^4s%K~T2UDg@8tV4r*Y=(T?uMNL
zyasCRpV7=?2$sHeF_bKf+f`0qmW#v5HRp|NO=mEcdsemT(PuB+sp)7Xu%}2Mwjlnt
zMHQ|np-Yq^|DZl&eQs|hXPQYPJT*RE?tH)kO>Oz1;n0hsN`!ihe(pwfzPJBDw4ZhB
z*xDuOO+cz5r`dQ!By$F@-itif{$RxL7j|gS$jboIVaKnu<$%i~9N;qO5gxGr6D~^j
zZe(5li7U9QzWwG}ZBN$`IRhe^bHF57oJDbmBE(p%tLTt4PlaJnZB0ZKB=cQ)1OyLk
z)*^RITa-Hch@rhB+wUHK)Rp(xedw1@`UJfIbDm^>{A_2t-!4;m@sS#YF&o$Yp406+
zxLsF4bouKu{CTvFwy1Zr9uDd!y;kEraSc6JH3z#dUxbum#iRkU^qNBQ-Ccl`E3d>0
zhNaa+IsU!*AN-a^FuJ^kCSXFca*yIde8!o;C@6$H#SK5rE@VyI(8J;M1of@~Az=kK
zJcXF4IwX(~`Ei6Q1e^lX0tohtp87#=3>+I95h3ks%9gg7@sA?P{Jq~MV1$3C_{TU{
z3KHtr9N5P2mPXweoyZ+VPR!Xfl0`JuF5CpTF<xj4Q3s$<Y`f9)hd6DX(Zz)2@LyLA
zdKq-pc>R!iAwDfJ3T{Kl)RCQirf5b30dCCv$6YsFr_~l$g*|_6=H~CQu@29trth!o
z%jOq`8bPhK&a}21ZgQNQY52G^Es3TyB{hWjSCVai81!(|xUb#KVPRH5!S|0(N`)P=
zZC~Kq>_N{*R1}mrALt45O?u+!A6K(u3z;@E!Qn&>**+?*{4u%`%F<<NU2J>qHj=(n
zGGmGE2%^dkM*HGYee4LJtoq&<F;L7L9J|m-py2LWf}iL-<K|N%sE7qEvl**Z*bU6&
zB=)_yzCZjM8-O$AUCm^MUE*wJxRBABW2is~fP*3pWBtR+o2NX%V+PZocgcgGMsma=
zz$1?LA-O$S1VP(kR}T0<bUlOH`CHDAWq23VXwC5Oa39Ja!o6Wg+V&hbxc!leYWehT
zdoU&ov=<^RX$GtLxX;Vw;QPa%;P?3WeYds07(7B`@I^-2`7)Ya<8vRV9V-0b^L=9b
zpdkzkV$U5fSEH3JN3;T2S+TJ~(|<v3`W^EJh{L$^c(l+fex;s%Z>X;A$2SF8S&Fc~
z*m#q3E>z80=-~F_xF-neJM4&e+jCR>Vf#j;`{F52jwpXq1A<cHgmnL|0{lNp1SwDm
z`yc$)TZvcg?hg*AKP+4)?d*IJ$U66iA-{zFoA|(H;L*NTUCr`SF(n~E6#AAg#B?#9
zO5y6!=SqO~&k<yV&<9z&S1zQ3&I~;l0V+HPBpV0|gM0dN|0!Wy1Y7vi=B*b<ZD4BN
z0f`SH;x|2#!x;Z61W4MkF*V06pHiB58g06@VqjqGi`0znmXwvTrOJXr1}#_DdLa@L
z<Ui*xoN>`}ZXFpJsjJBm858sVy#C&?mu5ZWpf3dC@IJ%eKVHWXB_<|5qLUMUO0{{u
zJMG(ahA;sDc=mmcdf?{4m;nI11l;WX8l1B<^KMem1znSrk_v0`4fus02c}OAVGd)G
zx|>SL#RC8SVH*>7!{)~+*LdarVzIl79~O`h2IU8i9@p~;#A<>5ezwTLmq&oIWwP!`
zLa}LG8!qaY6w?a(#8(km$eu;>0DAp9557w#4jzZUq=IN-!ExqaNSrGU3wrLWt_yk;
znB#A;!S-x*byls<6T_)yqgLhbObZ)Y0?UpW1{3Kjm8;2Ch-A(k-guFvNi!9tHWuzW
zdBNYoi*;qqrvQeIIVO|(2J31GE%Is_Fxnig`o;@<2*|0uo8%xRN5c;D{Fb}dW~J%!
zceP0XgG4mJ9|7S9zqi}zlGsdK!Ir`+OV5Bzhd0M8;VZ&-dp;ODo?D5|0CP1k>_{bE
zL);s=q(An?VRBw;2!J%7e~1UjAGS`c_BcwGq1}Y(@U>o+!L%FqbJ*v6xpGS=69@*F
zBCd&!xbU9VbVLV`!I2)MHGHvRA`n~Y{qzgB^_E9kuMtZ~EyU|B6N6C;95&FFWj1+M
z#|fbUM=dV^8etxhIlB*DTQvdN`Rv<>SE}!FLr!MqXQY3aC6Q*FZG=Q5LLtbx`{3un
z0Fq#dL}l!tO6XhkLKhmrlunqL!KDS}gjh(xtszIB%n0h2c@nIWlFHL^P(Us6T3kRF
zJr@9q`Ieg;O>}g0Jd}nBmxY*+7JolHxsQKUii(*}IPrNr;dP$jU*$D;ANQd{{iGim
zU;dY?(N~4bxY)xv6BA(KRnTeK+06(|-8`8?uReWMzVaOkJYaMe{_R7I0JqY7kpo@V
ze;OEv71`;mF}W>E!uJf7TGE~b0`rY0z)1N;3dK(Bwtm^Mai|{2C14n%eN%0wnMPWE
zeT0!f(=azPH)vH?(Alw`#d;fAVpjt=QSMdm^>Sm_);~dKc2fd)6X?YB#TbI#>V{|4
zRP2XKtm(fi1FQ+{ijNLM;<1LrIMmdtE3CZTv{X#$jaOUVGS(O^*PyfbtTm+Ellzgw
zbRpFo=h+C38(rKrdb1bd(C8oWq*@B5l8NM8LuV=&&KI<0BO!q)HAM+qbvfEXkl3K$
zD~RT$yk6`Hy1jb<26P0U^>6d^9HEIu|5H#v;b4~ND;ZH`H<gPV72Kw-_^n-BE8WU7
zD=l6`4cl@A5+384L)YY9o{lR+sKm+QsAGxR-=2<1^ZAI*VY3e{;olmiTfL3-_xTMm
zb0wI)AYuJJ+&e~ggiK|3h_6G)8{MFa#{|hC6M~65j!@AS%^eu56Etki^5VWymxU=T
zd8@SaUS@}7F<bfx^c;A1sRrcw_ZQQ!Yc!Nc<_Ky28S)@~%!6R%1krKNxpXk*-uC0s
zJI<<R5T4K2+xtW4bth81o5fC-8)LTjZz%D&u?)-qE5-jOE#T((Z(4xa4_vXsagCPN
znhu|?F>KBf9``h-5$U^_o70LIElgYRiHg-5St*TO$?Ce69Qk<4LaP00=!tM=T7230
zX*1J(`H&K;XA<qBbV_9*XSr5W>p5r|DBx*14P9gTceVx^UUxjzv0GC)Ic%W>MsWCf
zixwA%w^V|_hN`(~D(wmjYjIC!(+G0E!KYhGr%AQ3@P<8s%d0K*i26$Y71IBzAw1~H
z8KE8!J1(%LoaRS?WC!w+l2eh-ZvBKF|7QLKufkhG&|&b3Q=VF}VY03$JH>a9qopjY
z7Kx`UuP7p*@hiw1tyqN|kd*g>?CF_^YSXWz!UhSau$GBGeylAmwb(9mtWW%Ztp8oo
z4C1{8r`cER-+BHcK8UFAZ@TKJ*Rhu|KEF)Jf&P@pd8yV`Y%wdnMEd-!NLO!{`*k?)
zW`<b3qT=<1&3`n!M&XXrPG?cQ)9H2pefjj#qanHd>`Rs9?vGdRw@+d};VePLJ+>VG
zvoJsag86BK+n}PB3GXY{YjVo3-);*9`3{yJhTm-2=}I}uZLBr*oVHe>*9Z9NMtiYB
zC;5<DxxSHqA?3hgbB-4gkp>g;4jBi-#3`90D-s2n9Erh}mc7Tdbsgy@*GlTa^82l4
z$%?3?b(UNKvv~Cg%y$Yu495QQO_oRh2>n3zf}l?6<qq)rCJs=g4gzueVEBt#oscgq
z5yFmlS~~L!2?r&=%dbx7c-bwvZ<-yW|J4op*l=%EUkvXW9eQQThs0rN;`&1y5-N(2
zHjZ0uKp_s~Y8pzCk`;L)C=w}!srspyk1iY!-7HSnY4ZA1Hf=GTjh<5{1eGnqi+UDY
z&})2ATLO>eDZB%xq*Df%%u9DNP*txgpw3jDq|UNhsPjSSLXvb+OJk$90300P0Ti`U
zD$$KZcs{CHl8r~6&E^d^YG`mb&L<p{F&uB4kQah%R>oPJctk|Vd7=}1*T3XAS7#?D
zg=Sp5yjtw@mHL)#0c{2^jw6DV3!M2k0)aRJ`VA*@Nn$z%5B(J)9V7pDr2guEC-s0c
zuOo8+o432abE4IV>U>b$Zl^z3m$Sl|*R~GU=zT-mWqG)U8~?cmy(}K^KNN->`|WR3
zD0)vj2#?-61pQ2}#>t}#FVtPzm%^B^_CzxkGB{&*?a>egr0Y`S_pCB$(1u+$n-<2O
zQq?Q<3ENC>kLE4~N;u@8o_zC-BbZ`_v6lgeDfEDZPiP=-=+f|Ysd}lHbb&CoYx``{
z+|q@AHx^e51mH6?K*k#`rNf0(rM0r9q?+1IDHQqG_2cXK3au%txw;E>21qhk@0Y<)
z27ot8-a=5;Py0)h>6B_zDo1=xl9#enryWbN0BOTt8lc!9W9brQd#f)@wT=Cq$mJjm
zYea`ENANjk&q`%*mb%lr@MdVp0fV!gm14El&~aG|>1}jJGgOAzw7f@pwFG!kVmT)z
zE9mXcqh5sEQ0TB|&7t%7Q*2|*h(LqaBMq{+1JLjQ`U3Qaz^`!<M3=VaxRj!y=jCG`
zOZ{-#E)NBFAj9YX3EqDM^$ZKgzK^l>&AOEOJL=RG0%<C{mywTF0zM(SZ62~!cOjh&
zT9<W4pMlWUzGu6+rnYJzbPPD_ykGt<W_O74NrRKSUEf}O3m16OZvxuXEe$0DqV$#R
z_O^_?@f`D1%^?grubfeX+oh;vNL~M_D1dPVbNat;1WpsbD8~67Pi0&I8;D}4$fxiX
zyN-8*Iq$=wEO7>7`w7%T5CEce?<f1uy=c2WTTabO%ggoJwneBRxn*Ut<?1+?n6mdD
zV^`oG-imZ9ud!+YvD{mC3W2--X@E^IfpghNGG-3^jL^&70#Wr}=zQt9oFIW1X;GTH
zi$(cU337D}xm^9X=T)%lBLX8#g;ZPed}DujQ|9Fcdn}mbB?ijWflm3*YMt);&gQ-a
zdm*(=)x(wOOi9xNLskj0c59A*Q3Rs$I%CrUyAalJr-Z^JhgkS6&yNm>Q4tcOXkGFC
z+*kx|&TyDG$uEt|V0>>6+X{lOY;rRo%o5Ny#F>Rz{nPCHY=f02h7-Gq*yZ%QW6WSL
zinK1S5dFrp{7b4-TUQjhBmDaI<&er_)WWLmvG?aPkG`sVDEfAtq>+26_`C~#B83v*
zId9$*hqw%h&$Q3#T*WgXR5;Yh$#fSLmvA1~1r3LQ0HgdSD+d0k+Zna>TfD<{!1-k5
z%KZUh?5m4YgG~uITDtSHYm(sR)kQA~FF~|LzIOS%A+w8{+qcBu-Jfbb{Um0za4xGW
z|AXa!r<)u4X+F2QNAR<(R^HkL`3?~gxd8zhrbJ_IDEz1?LRb+tP9?!?T6OmLw5O(`
zXQhHI(Tu}hBaLn!(g7kT?4@T{Tw4*nOA|>1*<I<I|45(B5snP`I!|8LK&2I~P2Jaj
zvk}Wl*-lWRAwil{9kpmbf0Q>>`<yE&A1FjZf3Y&e%M#W7`EL{->_IsP37_NTD!CJp
zLc9YWE%;@S%>BZ0ZTk|sP`V>uKE)^gr^8LHiBz%yN*Ave<g6Si`+|VaJI3+3*XN|`
zmxz#gj${~$m>*Bnmc#YAg#zFQK)k6Fc<oB^f5!gN6j4O4C%GW(Px$()bL#lE<bP%P
z7NBU!F-B6?{si-1A$_0B=|LEp1k`B(I@Rx-%xAM~fB}hHtIel*c?7D8PA%t+_Fsp>
zp|uGuZ?8vVk@AJfUn-^3R~JKDdAlmI3B&nP`4#4jhNd;jix-H_Zq|9Wso@37h2=#m
zuv692)1NY2^4+3zlM9p;d|TdDxI?mfcuo@(C<US9S%W&h46V)0!V7(;1P9EQoKBkI
za6tROG)9<aU@|~<J*Y-4R0B|%;~jZk^+KlV{9%Rkf~6@T0rQrbkA@0VSH4I<5{Ofk
zR<lU;%!XcSql7uAC}A2<MBg>mqZL7jk*`b>_i(<Bf`TIWbdcK}7AH!kM4Lz|_fq)I
z^oIK~;eC|3aqTs<e%M&Sce91@hqn74UmEZ~C`%R(ZY$|__WkhNuZ`g!@Y%NOzm)-R
zo|;<F2f_X0p;6bI%Jrl3%zw~+-F)EiVdGkA)qS<jioH+%d3E>TkG<F=x9ipO*NP?Y
zqw;(G3i;MYyY&IWeqQ-I^|godwX8xnL<QeNnNaY}F_R@MXHjEh>u>Zp!2TVBdn*<c
zNRDsL%*Z`DhX*HTq&U``^1t|T!9ZT-Z6zUE4e%=5+W^mqr^Jr~X|`aSR`mmWUyDnf
zCIft;ypleTuV((cS(~^vw3HX#)w4&<Rg7>e{0VQ_MZ)|?26@uRnD{$wDx%nD0~Mr<
z_A0kqJ35vy1Te)r#^3cVBj_s90pgok$g+Ro{5K`!1A@YmZn=}BUI5v+<YPxYMeeIJ
zN5R{fB`93Tzn=;B0TiQKRs|IFs$iqfE&S%8z$!foKf01M76q{z>PSLfH^}K+Lkjfa
zXhPncjLu}c`Ion;=eq89aIx+=AAi1^p_nYZ4)<-}_H^xvW;2;F(JMABXCEJ*(<5(x
z!N_{+b7Ep*lrL~0q9`^#+2@yQ_-E@iQ;m))&aVo@&Ne<9icQi1oy1-{KdGYM90K>E
zU<_Km-8*Er!cG%`R<7gPEqfT8+snEOyd3ntVeMKU6I(SK2kzBx@vJnLI|_Hu>jqrx
zUH)c2rKAW@_=gu@C6o!eE5)sM5kW{#6A)ToE>~r3v~Z-I4ybOaGDIdfS2IE*v8yZ&
z(t~MjDE*1PLAQ|bG_jrmZvj6iB(7o2S*BNYymV}R!+1aukMT*m8J6ZlVtJtCn5txO
zt!iRx>slTAs~zr=b@z?dvlSrE46BbmT#6?+oWM&?FKA^qgG-`VEBACVpdOr>L7kl?
zIDP)MlCIW8#;TNaCp6jKz`$5r!`KQ({k&)fvcR`y&Khu_jpq}V(6EdP3JtF#^q@6c
zH)apD-60f95PDr@h84ka=heO*I^U@^;6rvCespW1E6@WC4}H#sVg?&GzZAn$BF_G0
zLRU$mEH75k7&>(Mj)ey6Sc}@h&db4ZSLy#scTtd&a&YU_t}n>Pcj7I{z{{&stSWwo
z9CP2{tz<#8ce#@B3*5s#p@lmYv=@k&U$_ek_k`u;#jL{7=$~s~41yH;Kp9{3==NIY
z>j-jxkHfH_Y8JpBxV!4Mylmg;o3J|tti%HL_4T0)#>;!Qb5b@z*ox!@yW_}dgUS+o
z^nn@0P+6l}eQOPp0^$D1kI_w@G(P9IQrjjbCLmi-7fHysg<~Xj;NW&JTZ|<Rr(5gm
z2wkPDbefY!W5L4O`fS<=k4g}TSm=PAaIo?ty`r}UK-uJEyeRK}YwoyOwKem`yFqUS
z1By|PYUh@z%QB|!s%MXmG;rYdCHcXZ1!J2R&AD1BU9A30!`Ab6@4ebu8ng0bgGypp
z1_v3X30WezT54;kt(jwRT|QJTlLYCiY0$<`vxFCn)|ig^sJLA3XE@kH+8YJTCALG^
z#FylN*R8;5YEA-!z@eCdsYcWT6llW-*}TSxiqoHLW^N@7Llo1rN)C(5LL$OWHIwuj
zeDEP}N{-4y(p{?X8BnF*)!9pCikMfuPEYP=3D>O>CKF^z=o!Zjr_*3sm;1p>Yz^2O
z^)~YfI*=-V0gm0%3BAf85h=JIbrP2s=uwDhKqluni}f_Ue<Soz<K51x9XT5bA0O=3
zCt&j<yKlQ&cbA_!be28Or|Ep)q(Qgjv~m4yFWp{VuW`pdv?`yw+c(&Kkbyz8+5(@P
zmid3kyd)@p=dZ6upH*NpzMO)fJIL5>V1Rg;X$+R9j3z+UT@J*ksx}P3gx{oVsc)rA
z_xe@N@69zogNsWtqJ45f7Ja7K^=XqIWQXTwi_QV%3cKFSaEKRa(9}wp!#6GX#%@K+
zK!;BTClp|+S(sX_`RkP<Q%hA-FNskm<{(2A&k`61H9D}X2>}uQHRCIm1BlA|6JaZH
zW^qyr2?yNmTG3MriT79086%2b+xCsnYqH8zcZ|^2+IR|d33^-rxF6AAS%;#&hgvsn
zYJTVirAW?`+Au#%d;NpvpBi4?-4o46c1GmTc*B3YHeFO%DdqP!JD#1SaVXQ?SdyZV
zr0p+*36F=AHe+pAji$J?1pIpWbQU~7pimTy<LDwGcBTI-=dkMs)P7JpLCwb~VV&T%
z{uT8C_8G6hu3{KXPK$5yrpoMO!J=w-o5D1G5Le9hqAKi@-gvRtGL5MAlO54pe?NK;
zQ}c6<!hSNkD}VTb#tUjOGAbAca3eGNjQ!d1D~xT{^sm~>wVB}O>0u@&c8yfj6A$%g
zA7Vl>=`i-xmuyb9h-!k{Ojw|~Y#HiLIe1#zNbHR?zi{3{Y!sShI`2<*nbFk$6gD$8
zB?pXt&4~pMHDmec_F2V~%f0B`p}AC7sR_DFW_c1EHo-c4_(QZ%%BH8S(Td9R&5VMI
zipqq)8U{K#nS58!3T3))jZ+e9jD?%yh67hc$J5b;w-o}&2-pw>kax7R6x07<5umwa
zxQO<%u1YvJZn}?qA4?s3m!UV>FEgmVI@?xQ%gxA6EIO9HlM=N_YvVZT#O)a>4j=8S
zGkKh3ouV^2IRXG3z9;z0RG%^7R>n0dc2y0o5ttQ`#vU3hj+9*;>bNW)k^Rpf#yHFo
z*bMMmI~}pHDhN|#;avMK!Qj&-QE`fr(@Mf$GCGpe(6N>6AVI|ZZ)(Knd+_D~(?t-E
z-+}?(w8;V&e1dQUCuOtjID_efBc%^=7X*1?L7Q7w{azj}L83(LXMT`GvG;3`*#9NQ
z|Am~J+Y@Z!ubBdyJ*ELGDl)RNm=XO{@)=dy<%J4al-piwH6E8+qfDJIqXutI#>QlS
zpL5`p`#2JXj*kA|<7Z`cG^b$@1@-Rp5X`3>pvyr@`e&*^5BFxPdxDJ*m%nL;F|sM6
zj*@z|QpHq|pUK7y2KfgqsKMwqpWqASEzds+(PuAA54X%6@qJG_%(n(dkk0d&oNhTO
zt>KHdT*t#jRC_v4`Zv9-s_k{`3*z?e5}gwNaf7SGDW-2ce#)({{+-$A7o$3rL-t;u
z;#%Ols*`zI)88+y!dTz0Hu_-R*=dG&@7(5+vfOn9@vr&ZW_F>N)UKfnz#J4l@9NmU
zqX0+aJwAcG2iWUgy;89!>$-<jD%I()EjMg7uPNM8Em{}%g`ev=YHU|x#EY^1ezSP2
z1t~V-LW5}r*jPAgV@6_Z++cLzH*GJa=f3*|Z&&Mlt?#b^Dt0^p_g%@@mHuZ`G}FAz
zgwKii>;@T5P{grOA^Poa+F)U8Q0e%j(}VnfW@|XO{eH`&D^Od1y7M=!^uDylw{GZk
z>g7zPAbjf4Tk|<7wD-wT@;6;=?|k!q(redCW2w~8dzqe!s_*oBvjkN7?~ZR$&c(c4
zHtrL>%2gGeWsaFXeLVF)dV5czD5v(l^`D;;SblA*Jm_{6^x3+E`4H21?tE|m<8`^W
zIWfe|KhAGo8ZhOxc%bclZoOXA^yyI{tJVK0w`K05!h*nk`Ue{rMa8PNmMf$6^$3jD
z!a@smhas)TyO5Z7<E!n#ucAbN>w@pDIvD=76vG@m`j=TSb*0*of$mPcZj(1whHHlV
z7|X6ACKN2;;^2;8Al9y%;V~ev{uW=q-t@k!u&NK(J}GQLLRq7Kox0^LTd8O}zX{6)
z9PuJPy1#sJsu_H`FYQRPe=<K%VH#CWaCJF+RrxgD`6}+Yu3@j~x~@ESDbg7+TibZC
z&qPP8`@BbP@P3y6l0dPB5;V)ZyRKP0&i#h6d@PbB*r?^G=k)c9(pGKE8i;gn)%b&F
z?|5spdCcrK>i3|;-OBD0HzqM^=*s)1N_+g=3aNZMd<fe#>Btc!;Re&7xIAnAiubT9
zH#*N>b#}=Q49UeY$$c?jV2q=eZWDB!GC^5=3CVp6SuSiP1VHH~^<BT_QdX?wYIT1M
z;iTEGq0mQ10fbj-`Iy7I`a1R8Gj1m8J}*pE{-5Tq`>Uy?YX?z55TYU=ARry3Dbl2c
zs}uo2>AeexlmG&u2N94WQiV(RQsmO5mjFTOAiYFN2rcvwS_mX0`QrP2f5G?DH*1}}
z);a5(S!ed_nc3@^XU}d)S*Qg_>YeDeT>h1h0#<fV^y?V^H;gB(#fH~o$cpk&iuLYx
zJLRn^uxpIx%(-N<$?Wsq`2qzKMA;v~leV-2`)3!4yfHxKrXL`pWyfL_WuvNjsIwvV
z+0loJf>090?Zq=2IC*N=9mXFTgDv74E}#Up1x71hMENl!(9j2c0uO&Vb6nh2xoA!*
z!u2ZTQ8pFwNF(lHAaL7hYHy~^Y3F%b>=$0b$|OAZP9u}m+FoyX3zqP!WW{%Nk-W6D
zv;fbibWMhkjaw%k%Oz$$&`RU|$wegi!t<rH&CKAG3HLUM#m`I|Uz_lkDLX_H={olR
zZDqK1!Nq-wQc_swQ6?C1Kh%h`ApGD5n5n=I@vl(AEq0-0G!rTu5+%(mo4_U{YPPsv
zz;e{41S2wrSFR^}5Q()UD6u_k!6sAqsQRUTr5H@CeN;qb4A8P)PJhjmU{?JiC3F{(
z_%aa&;&KIHyaHpWATEcTB}Culx>~&b5jx;04K&I}t1=X6q6@go`-J<Y6c(}{yaK1#
z*jnA@7aYZGXU}9e+g62wU(V;Fs+C0v8WU?i%z7;s`=_AA)D+$`{Q1Cr)M<`MD^nlJ
zq#fpZG2L7MUB2nnfAx4_6aj76VOC73d>Y3Plqd6N82EX(*P(Lzz;^QIWhMVW^H&dV
z%`SC1ADukZU(jqfTz*f)iq9xt9PdbxH<Pf?hv73r?O^Zc<gP=ku9Q`3KpAEIXry8I
z=dO6`#RI^vYyC53#Zh)O@P_8X?_cp{T+KqS%tFCN7QU#l3~L_$M@G_N*8sEr557nH
z=N)-o|M<j#?%wlOeitcdcx`y^DU^J=e40~}eWbH;)(jpv;R@dsy4dR@?!#S=*Yr16
z&1-~{L_zre@{iC?$pfQ%2ShocxXjdaK^8&eqBpjRQVXs}(=zw#3x9*27kv0YnZz2V
zc0~L)2JP>4P=R^vaaCFgXz}b<CwJT+0?;Cen->g3DW2$dE|(_{H4j&BgyC|)WJFHe
z5(H~eW}Vt4i}K!{LFAtQL_53`dX)+A&QsvA6?rW1g*=I1CL`Q|uCHH69A0Y27Qdq4
zKk@=VfCD(T-9H(!t!H7EFl$rp{V4B&>L~)Q4L_6x6i|*ouoNVH(-lBqL-d-@%4=MT
zsm!FJ%+8o{VmJ|Nh6<L(@7%A!7VMt_5QlJT+?qhXM#2+1q3m2^RqTQcVvz7wfkpwD
z(8|4AAhV<3y$10jLET=n%CWEKbN;7K#dW%1up>IS#ew~jfENM;5bs!tcLxtHG&U|`
z2!JjHVhxKHgc?T|isNm;e$LoXfkTfe4B_pctd8{TV1&t<un-EkfEIvlX{r)hjdNW{
z1671Bo!NG0Oc;I0uQhVbrNz#A1?w%)b>YV3wcvM7TJl6b+96E|dmSacWxBU$x|BA!
z-vz0-0s{N3mmX2pwsvOl<ffIG2_xv?r@YYWYH~&MVv~%@L-*D9A90_;d^YMqourDy
z8P7f~D6U?est^hR=Y)r!U_0obWR;b_A-~Yvc)T<c!wWxm&p5Ae-76kG>>KSTAB&+n
zF}h}wE8qFEa|eZ4D9hZ(pF_yll73APXpe*I$?+U-0n#w&oaqScV%?1~2RN02cE>pp
z)xs6uow^vItm6X%1JQ4&$yPadc_A=lQBl!r>oF@Th2lK46N^lu#tr_QQy0BW=qzOm
z#22x*9LGT<mBxQB5qH;zJ5R6eS{xn=@WLnf>_GuSP?Nwlq?YaAKevJad#=h^S)f*j
z?ZlY<etrgEIDQRQQ0p!OCz1!{^$k;dft45CHM|LD`~B=7zZuV9;`)KR)7~|md#tF|
zo!*@qXqb;9`Z0yLcr4X27MdEmZKyFvD^+t^Q@_78nW@_J*gW#3_-=3AgQ-{eckQ)O
zhF*k2tnCoYAUW!*Jgt!6wX;aBDAWLPE)7K(^e1ON)Y$7qD+-Va9Y)L+w<%|jFn-On
zXFCum1^bc`;xYZhF88zqi)`N9t~}9*o2WETf1#1aLJlvoS&*+GOn6Shmd-AUNKUS*
zD^i4`8I&z<a^EULf6+Z*!yG`g4Gwx%v_iX9pAacbi9(Q;3rVvcIyys7NB?Z9EnwIf
zqP4ZxC0EXwhwG>;l=b8D^)O?q$2OSg5|D1PNO01d8{_RH3a<`Ev)vJtXK>=PhJ|!2
zMMYgsy<;Q#>bB5r2C4%+useJ$iZQyV1J31G-IAn?(`!*Mryq<$>~eE+cdV!CD)Rt2
zCMfU@A~61_^B6$3y$&?zS*TMPR-7v7kj#1y%h0pLPpYNSaAj(`rRQn3#_F@C#md_A
z&l=6sOwmsLm0D=}=JNc%wf3v2gH@b9w;r~gTtB^Ct@3w@C+G7%bgrW%kA5Iqeg}xh
zJcHC52`W4bXIc{<OBy>Sh4Y>S5z#>bScaQ7Z&DFxJQBiN`Z;z#^cz@tPDv4J<vggY
ziqre02{DlKZM9a;gs^80%es!<{Y*QNSA$6cd*6ti+uAP@We`c+Z!?lR&J$7s#FkB2
zX*ADEaE9hj<!BLSc&RUali}L$<>BCH4JQ#IuP_EGV)@Ogt+SLM`@g(yF4P4+iin>o
zr2*(aXC8}wcl4lb#;bq%IQQ0s#H~Hsy%1`Opg&9?{oEE`biAN89tEYO3h8EuTm0lr
zS%40?w1eqVRcbJ@jk7UqW6|{=1VXsZnZl2%6d1<t-$c6LXFu4a3VO~rY#*VA^M%-@
zY^i6<uTojvc+7%GykkVz)g|C}@1>&VqSkJx`n0_22M5kTXyu3IMjGj2xmfLpfTP?f
zn(;)b?T^#fCX9UtR_A)>-(msx=J?+53F>7}CWp|dJq(<={x6+x0l|)*{@M>{@ZJq|
z`o82ZL_Q^e+IW(D2q)=Mlp5V>4M%v$bamW~>ny!0N<+vl%F}>n<IiI8NQ0f|H<8m<
z|BA3b5@WSL=pSRelo!n*quK-1ReH@)=oaq)oT%w~rl&5GP-pNrm3#4HV2#?G968VO
zii%^qFBB5yMi>YfG&YD`iqXde{UZa#?lwao77!h}m(oxjGfW3h>_{Y08w+X<-|5$L
z%5owGcHk-%uR+;T7qCfYgT?M{1!n^1XDhQzz(YA1wwn5Y>ums!!P=d)lN?B*vq0;@
zys=w7zE5pmNB60w0Y}5Ph}v#9<b<PtgYH#8@Q)O?+5Q@-96wgxmtIzNIt{fcR>QOM
zCUSEj0(_7Xj^x^Rg>{QIQ`U3i^A(viX-x=gd$vTY(itgAk|l%r<6o!GJ<(0&-<rtk
z+;=TpJb(77M3`ovF&0AeEd!B-IN6dW5U@wR?e2EjVV1_sQh(!@4EY6aD`0`BodtiN
z{qATbVTf4^q^@A<vcocKrc0`$ELUs_`G<09zoj_q&iKHLfb_yu-MOx8dMk3O#*#a=
zUpCE#v|BY`FP?sP$c&m~E%`w(@jHn!T?diXZ%?b7EcH+a{t2_D>ll^jb6N>eRt!2S
z9+Tuu+~7|}nxjdLlWovY+fC(%pH>p?bkYaHIq<C43;MsC(Q~N+uiKy9jgcbgG22{@
zdGs~oXx{zoB{l$WzbqaDI$F@E3J9NES;qaNL7wRgjaoVGT9538{_HB2Fq^KTp9H{>
zrF&+-8!Z2MELl6KdPqzYCPsgL9+uXD4AFMAE;JSM18_%tWtI3SHf@s8&B~!9AJQaV
z?SZ}juN?2vLZ(F>j8+zHLIa#PHR@~|a(K-4ZN{W@#)O&;?HyMzhB!>?@!%`%o7Rm7
zReOGHdyjaRLL};6LlElDt))TFY`gb=$T<1um9<stJggD(NLBQl+R3C^HZ`~P>2qZ1
zEapw!&btx+5blk__P)-hY+pd+JwL#ys@a!DEi=<h9AU}5?^iY(T`^A$EuPn7yUk^2
z+HHcSfw{0{Bir0C&(h2jAvNN@h4E6o<9(pi9!?SRFPMK7*lwu**aT5xYG!tA!(S=8
zc+_Y`Mm0S=#4X%8K~fARYDNEOkN@dO!jIV4{WuS5y!)53Tm>Kg6XU75dRG$uQt~ZK
zu!7EMXo)&(+Qce@J^Z(MQ<w(s6fMLnm+=YXjl(C7RWH=FS4)>3fT8~y-qvWX_OP=(
z`&gbD>HIPNolg30!3$$J*}+GD4ppt?Wnp_Zc&M^qHvOgM_dzqo>(y;%$jV^&wXrIN
z;EOF@5!pBG^BHLWofXd6|5WRMQAF?XDl;9IeG?tRy&S!3+2}BQ)Ye@gXH7Y1Xgf$-
zThKL2S8gt>mKLGxV8v#lwaoSoz-kf5?k%&}sTJy(Gj0xVt+b@>C5{C9;Ywatd+hGy
zm`_f)TmHSnYL=`Ro}$Z|vd${;!rfP1n0}jIr%n&x!5&OY{%veCF5v5+?G+ru#$lO`
zE}{LmF1iig+v0*FT;{Xs`8@aqIBOa5KC*p=jayvt_PUD=?OWz~mvO128?vQdWB>HI
ztNj&V8N(JmCv5LvvfCq44Ff#0bO}(N)G)7;_@G8joie8%G9_zY;=IcKS~x*Si6_hQ
zcIDt@?}7PSjtBi*_Pex4z7lNQ(*0b}1A8ZhM4--&_?VO%Yv%q^$0O}r$Jn3S>^CPm
zRKe3oWL2jE6=BJG?0R8Gcj3<kz@tzFC+L6*BOTu73I~U)z3_^-rQqdK;%FHcZ%`0w
z0X5%xVy<VmQ~^RF=+s!Mo`|gc-mK5yRvO3KkCqr|DSsK`4#CYsd^;b?uhMeR1;gvl
zAhMsoNOja<=_7=sD3{evYe^{UtS4>{+}r0T<$-`RoGx+c+;n2nNfsMgu{F?X*3Y?N
z#?)0I1t%;OY3L@+<c9cd*4UD(+Pv3vH&rQ<?<<{T!-8r^eyFc)L?N}Ji8GllDE>YX
zcfPgVp=WIwJalh)&x4M7L1^aYI3#O?KB!p+>zJ2(a)M;_xL*N$_)Bh~*41gw3U;eO
ze*lxba4Sj<5LTUK?B#~Nlw1f=t9w>gx)nmx(4^#5Y{&Oje=dJkjxIv5gH0{cR8*<c
z-5uwG<u>Yr$Z+|`>NQx1NJq`Q)$s6bGuUjb4Hq8~?4^AJInfJZu$<}RV%lkDOk1UC
z2vBtK&Q_j!BfHQnGw9|VBFEKR_E9u9{N~Loen2ExFuqVwo1Pq%E~u?qF%9t?wR^H1
zHfDRCWIR^R<j#Ap(;((Qkx4yReE|~yL)H}RmMu9<Yr!U`;Gy>$)eSVKB??HL+8~Ia
z3x)+gXh+uBn2Mlp-9*&bJ*X7p;O4&aeP<B*NFA0Mo}6nmgQb#EH$MTMXDLZ5D()af
zv2Uq7Ukos~obltTRyGqTo$(!6#L8frDYTp>aPvd{&Ml*h#hcy0L@s8$GB$vA3!&Pu
zbuy(53glNor|6a`DOZ`?7V`PLFa>C~T7$zZ1BSw*6`VVdHTweZZA5m+KE98mO3i}Y
zVvSF#bM=>FA91X8p9hV{K#Dvgm-ot02H;&x`s(YRA^BIW;2VH=`QOtxX@H>JJLD_)
z)9Ktc6-mH&yi<i<c+Pg8*)_H7-bq6%VO&Gpp>Qi4R<fJ@q^2t*>Ff~ov@C=v=1{-l
z?V5^~f!zty=(<dqNAEe4O?A8Sk76eG|C+zYsOHM}wx50}i&}87V#LOV%h+zMnDf(R
z*Yvt148F6_T}B`uMHhyCR}^2U9(;xU+IYWuIXiisD3fn@ciTyTRpU{w#{T(E-O>gv
z;barj&%FG@xv%AUV>X|hp+S1f-_LOjRg%}))~4U?tPIU|@Tn!!lwN$@6i}dQ^c9z!
zqGEYcVtOAt+kTa3CHW<0g9XJ(bxVKZ9WD-gJm%J~US3r3gMTBYchYaA87<5&JbvGF
z8sOwB3^1xIt3rO0oRE6a(JCJ=L#b=n3k1LR%`f@oc!Q6AYrry8;7UCZdjtjSTqUx8
z-xz6}%w00HT6*1RDVMXSm#Fqj=iPUC%XCl$9R4LwJ9bLWMAl+*GSq91Sx$ZG&)g6-
z_YOXhE-fv60XeiyO-WgSvr_>h8{oC>9YptpB+i!OrQa*C|IvegxyifExJKy{JF-=E
zSinqzR7WBiXiLJhHoBVy?YDFAoDE<CfWXkpvH2aB0(y+}R2H)l;hje#c2(iWXd5tl
zpd7ui-d*ypmREDgS&b7TtHxk1%BNxPeHFNUYv6ojqo95Joi+CA8J0&M{`44>bbtH4
zr%hOL$b1{Y@P#ITQLisfsO-KxzW>`!AbW(3M%M0HN_DjMewI(!z#SDp(cTNzN2fx5
z-{L0|PsIF2?)UW2Bnxc@7Q1~|<nSZEU?e@QuR>qCH|L=jlm6>$&_QpXw?aUd1h~PW
zguMF6BsMPRke<46IB#IOthPvAb^Hp-<;$+KQ&-0a%Sq>qT>bE)ewfO_XOpm8Kc^Bi
z{vO$gU<aeI*brzd-Dt2KBFt7qxo&k4Z084ThoCzONEh3P(Afv^sbt*P6BZuIOq1s%
zNJ^JN*i=pv%Un`j<q5>D?!x>iCj-AHqUq520{idrmo~297NWFxk`$USO4X3g+4d@@
z1u?$zUQol{1(y<%7MlkRbG>*rJRQv%#9EO5fZRvPBQ&=>L&oAc4F70P)fw)RoM>qD
zLb5CT`|OoFiQ0fqeS+-v&9iM04Y#L8NVNtiz>?_ak?4kInO`l&snmQf6SFdMBePCY
zb}1;+Hj*ZRwaw+tRVRiB9xWw6D?Efa$&Efo^EEY_*M-nc*xD^le5~|9!M<?kRqZ6?
zk1_&Iw2h#5LJA*Iaf*%^SY(^Gi?rYKB=$)L9Zr}v23O+1Y_LV0{gAtJR3kAnHV*6;
zz}g!d7~EVZkd`<0<n027c1UOobVn9pHEWZCL+^{otN8D<W?x}!O8@+^G){s_!bfZ<
zpS#G<R@=x@=P~VTn|`4AlcJ4+yf)}ehThK4&GKPrdlh&pY4luv@R*RbSrBwM$--5S
z3L-RK$#zxw$oL9FeRv*C3dzY=#3h{e7lf_M)hZ1kGC)ShC5dz3P0Y`=1^g$3JVBni
z$aoWEksj&Ato&=Y+^eb{`NS#S1o-hguHFK2dnA6+eL)`x)hXtQnC|2ym3|{SvE;nD
zI_@bJGrfqi4jtzy8jT%5;-)0N<hj$_+I8m|Hv*Po?1S8<?s>%E9%B*4vd@NxY-xMs
zxGSGh%9;pB_6TxxD_@g*j$f>vcr`}N+BY~AOBA=*#cY*n!ADGCyb*JC!9zcq*Q;qx
zX6GL$RC!x^Hkw2%rNTC@Qod0ggdWLX64jVw#j2I-|Izjp8Qpz(hJY&EO%@g-8yn>G
ze+m*Q5%2i)=~Eq@_&JZ$EE>+7M~3NjX(3@rC880PqB`4$IvOc67A#}CV5md!x1G2o
zn_(y9J~a0+b@?bSEu3cs0ImvXtN&#@@kZHwrbv*fL#PMjNZtr_e%<qKQ37S<y`5si
z|8@V$y<PWrJPO7N%K^02aoXZFPKmr;bN$ugV=Mgp{Fh8a0?E&3R&rH?8g0EPABIat
zAF32^!uJ08=`N|~QB2&$Cw~6)>5WWw9@ymHde!`^El5cU)kR07mx?d@8pW41PGr=L
z?^!rn|2-FM{apJn+!nlAe}9r;$g=#cya%M`Egha`R4pQ@ik|QnTdT$unC|s+S<e_k
z#t*@FwgzuIWIKvhmScX7wl&|-%!?Be&P%qkGO%*9%S7?31;l2>1!YvRA!UfNL89OO
z<tSI-(00_auyJw@+iVl2yY6EVZG{ktx^si(`D51x89#}}*F=%V-#8`t^tok^fO|8^
zu=!L@5PG?^pD{1wRK~RF#OwR8T21vm_oOE(w)CZke5P?-qlJ4Hxl2b!O?fj}M$939
zh6uIORNYT^W-1hs5<xO%MH7Ku-lu~OoFhG3=k2C&rthY8K=L_WsYxD0O$j$h2QR*w
z9vd6m&l9qTgrIPX&Ff))lshY7;*{>_>W!)I_KdW0_H87Fk!`=x0uYK)?~)hsEYddj
zjL8l-F81S|e!E4Z&87AwyHcYV!DqLV1<$IFP`@eO9nzP(?x|fC{Av^fxI>aGUNPRM
z3w9n*tBi=+#*2Nmm+f|Y2^<&s>$d$3;e8WkxqGvuUX#SU#zd_S@Q_726<?SteMu)S
zi(aniW>k}Uv9r;jpGJ9r`>N?vDa03}Vh)dueYgv9KYg5)!r+5Q8I#NhGn(>39GA@G
zr=7zVTz%2+Bj^|c-%wV=bFNgeZT!qZ)VNL2v<)J@2X<|iZ@jyrcS|_m@Ce=#6W*jp
zx799*bNt$m?5?R~B3lP5kQhYGN4)1*4sN`sQ-9k$XPH*d@Im&zx%)F<=h%UM1y%n+
zyfP=>U(QMK7h2>bDgzUcgEE{W^L@xmGAOFCulnA%eX@q~gd5*Jcky4@FomUrN2@wt
z>_W7X_qMQA_mzH&ecLln`$6qADqPZZwS`VbIwB=So8@7A;otlpS<xG>qjRh<ngk6<
z^ro)|A|gEOua*2yQGhhD!TJX3vhss622$FW_f^dE@$pg4gQRqJs^;l$Lg7>d#Zww^
z=kn#ySg{kNB?SCOS1_#n<Qtjxo+banqM|S_-_o(D`|E2~WvhF8>^BYQ>je#|)R5~;
zOxG?^p0q0s)ZJxe?e)3GU#K+h5s1}F)MR00Mf)k%Shq^c$n>NIi*Rvr63*6=C{${m
zx`u|&64i+Id#oQZ?#mnU8oq0_Hmk8EQTL^5?BJuv!Ts4(;D{Z5)_Z=uNj<1cQ(gTb
z&&`_?u0p>_n)Q5KL8~bQ1J>o^6^O?z#G7f*=C7=7dv$enh>Kjd5T46Th7)Hw?BQqj
zT7UxK65;1>d-f~89~Rgu#Lr*I#r}iu9(6)+l%tCOcaq;l;LmUU|CIkXm9-(~MEN7%
z$5A`n#UH?sA8@HMHa>nenF>fwh_i8Xt0a2d=H?zL`_u63Dyn$;>++RRwd0KuCuQng
zp#{gMjgcI7N7}>%40DrLU|`^zH_r`je-@xtFcN7@{Z<9t@r(lOa9v5b9Pu0ipcZWn
Lef8?6_L2Vs7HqTg

literal 0
HcmV?d00001

diff --git a/doc/assistant/example.png b/doc/assistant/example.png
new file mode 100644
index 0000000000000000000000000000000000000000..bfcb9afa66bbd6143e96ad47dde8f67c041deb5b
GIT binary patch
literal 110994
zcmZU)bzB?I*9N*cEfg)T1zJjRcP$imcZcHc5=vWK3KVyDcMX){?k*+8-8JN<-`{&b
z_m8{DX0x+9vomLp%{kA6t0+modP({c0DxDrGLmWlfDHeOsDq9OKe)Lfxx)|0*5Zod
z08kr?@nnhuKSyv=la>Ig#>w~LC)DOLYKj2h`wjqtz5&1kyeMc706f?L;J^d`1X2Ki
z$T_1;RS13o)l6Pm5`g{t<a8D%z)M~@%jmknk23%5pN8y2;MD<HNpTJD<)bwpf6QGN
za5ix?O3BaTMUzYyEF*#L(nlio8&^}BqVs)Uvs7b)aRXEn>@f9F{=RAN&9c)Jo`<At
z!*7BH2^sV^ags`{^|GGUUNIX~=@nxqN6X~jb}j>bd=#^Mc3O9qmVB(TQs0IsJrW6_
zPq>gzoHLDFl22S>N5wAF2UDX<Nd71Y!@;Fd)h9xG^9@G={YB1b_T;6|gd6!t3AZgl
zei47jAHJr_ktj-a8eE3F_i{7@@)mS&-$>E~Q!lrvp#Q5>f;;?Vn+4&rB`_>T$A0B+
z>kOWx{G!ESqn}J7Tx5Ir6I5J4DR{k*n7*WD*Q!H9D^pjA@g4rKH{VF#geVw(wxyVG
zi3-u0(@-YkwZDmyB_DC+LqSjNu{$Mp(GOhpJF<@$osYqjcVYRj(xiFcDg_W@&fVZ@
z^0|45^Ia{|2nVJJQV?a>?mhoZ{$-?`<IXyM-0N^8;NO^X2f~LEII|!+pFT3$Ws|PP
zn(HQ+^2PMkgDhSIQ-@p~%QD*Oe(H5I_<xD8W_^JL4Ahe9ao1>@cyFl0nEOyFLw-o1
z2j{%E9Sm9z-;H-7()jUH#|uA5b%wMt!fDv;@3$~I2KKjc;b%&S|3;=_heHXR2@P<N
zYE@?7@EiDXioupayDU8&A+$j#xM*S@4Y>z@=LnbM$K^~1HBtn<=EKFNdqZfs-nBkI
zCmH)%9LJ2E+gArhCVFCB$bl=1_YEE3ayQ%%$(`4lPogi>V2~gAQ0L~xP#YD$iM03M
zn_zw`1Z?ufOig}yUJv-_SA%KJcUc_s)`ISbO40k~xRuXG6$C1stSp4UJLMFb<i&7t
zjq(!rq;|Xt^n<g;++!?p96DL7J^VV+XARZFh}ZHmYQHZ#ZbA_?Y#X;_<LI{ktoKay
zJj)$$hfu$-EvRG+{r5tyEbz0mdTKF0mcNT78*<C&o&{wgW9a~KtGV#rq`O5icC7WC
zcoMan8~kzMDF(#oyi5>+kT%m{G=qO=KNS}l&KMK(eb)KZ&wQ!RfC2M$bKcmbqzw!U
zcj&87O$d{ui7&{bLFH(OFejOORv>0zsV=cs6Cj`9WMYhy3I5u~ZrfH_{vShK{l+H-
z&d3LBxw_f^1bqCy@hFQ}T|kmmiE_Oiah3A*(UV-*dq?XaRlig)hBAu3<<wQmm$`%_
zYdevP3;JZN>q_q~(-2sd3%kvaRu1~E54~Oa`n$f`P+9Q&;)r3)kx1Uvz8SL!g7Lge
z1Sb~5OYFlTc3UlV*n76ONk0>ld1<9%b{#4z1zQB{K5ObPQ2rB;y`gt(C}9vCt&g{-
z1ax?~n6zxb<m_z3am9PYiZ7&l#7EarZVdV!2fs)FVjhz)44VyH0i7>lG%^x$wq<td
zdPNE0#UY<CXGBX^`F{0YRGz%n#>TF*Gi}$2H-G%?Vj%G=TU9k~dH2@~3HLwMVAQKq
zrziX=I$1fot(<X@=F1Vj(x}(rGI9pGnnP@uQmTsM$-A8$LXi=XeQLV;%?SS(b`pQ|
z3=60Zc-B^&Na0G__360{j4-qp`#^(m^m!gb5;}WP{5l5rEf4&w%s~EFx@|;Vm#>Ql
z6wuU0DyonCO!4M0yJLgmKz;b$f?#}JV%}g%XrP}1=7biRJvZo_2$a$C1fuG5KYhG7
z9)030-%;M5DYm{vkVg$kG`LeDbKA@@-M#VW1B1X_J;IQUbfsitJwYpziJWz^ci7up
zw^44$K@(lD<4mb~50K--*|8;+lg(kk0;(j<RQ3SAIcNn2#b!r-LxVnbEBf1h<)-&L
z_?e>%TMP$TRxKfqhRZh1{4ksDjjW50l+>jwk^0Z{az-WOf1}5-eUZ-~CN#l8nyNEf
zX-6M}|GdQd7D2PoBWLHm(Mx_y{#ttO@CCFPrLQ*hid)wiiwQr}Kb@<oxWR9c`xS4t
zw>`n2oGDMm(@<TCULF{Vt(3V2+W%!u0QCxN9XBa=NM9$%#eK;3vNmqN`<Og#MBg9S
zBC>z_(~c-(9p*9oq?l2pMh1g=pTjb{YL1`!3Pa0x#-Cg_#}kTY;%}F*qSw0A*=DS>
zD82sPX%;o%0Nybo&U>-eSy_wok5#Xn$$0};7faQP3Jh9F>mkJ{6rzO&tpX0qv*LgL
z^c#MsMvtKR+UAKD>76tc<OxtG{Y>VzCd2`pg--YX#QdM4OkyJkoZ*^(ANT98pj}1i
z2`jdk>~AquK+@7^D*R6L=BdFCHsN;z>#&|sZdd*dQ%%)I76YVI@oLX+hNlzSvnWK$
zolZMBY0B!lP&fC=3O2OBWrlvo)%A|Ts4c?^A_8YOzhu|d;*uq=PRb{agyJm%%Wp$G
z&l2Kjg67NxIVqkT4MwIzstx#h^gkS!(~}6Xl??pGrOhb3DcJiS_Xe~!ia**A89D1U
zxd#cwM(R#fKYzJP`O(+A>AK5~j5Jz6z<2fc-rnr2U1{mUyHC=}8GKo$T)}ZtG`O-6
zza$WexhpeiCDqKN6b<3qrEBt#g=_08I~u`%mg3EoSagvY-28E1<`)gblJ=hqS#NoP
zWP#uUz8C^kn$W<`9q&q<*0v9vj<rnXJ30~{8eI+nI)rZdJ~IOII}EdG(2uQ~)5V3h
zWd~6=r|Z!Pdpilc3SV%?AI{_D-@j*QKVfpKZ;d-PEq`Y@x#*Y{xYW0Vwmq#xhbJG<
zG3~49>g$wNfDj6k4WVS)4s->{ofW3K1sa@17nwr)`$+Ag(f*$6&rmdaMcde9n8z%a
zVR1!$Q!Q$cfMsSHkB_X;W4=j#=qsV@_#Td^umZTnqMQDew>AEpnHI-Aa7nRhz*&D9
z|Ffks9pOLC6mB5|sOXQBjA#1mgdpG}0SwrrG4$`_QBF2bU92ave9Z631eGX;M@HJU
z4M<m+y{Gc}l+1Dx<?I;k^wl(0y)UoHk_V-b0Zhu>R}h|^NdxJ9=)y4FyDb0HLn$k{
zik4)QwKfDX57naR$mG<@lQo6Znv;Xw7uNG_gMi6VN?b=csjivXY<J_ShPGv9grMg+
zh_TD}_v8M#I8NR_E-o^PjG@E^La`{S-m_*yr!j;kUP`@_i9cE%l9oUiDPaiL5Cq;c
zGG5+X#LJ~$s)5kZ(6Yv+pUcGbc~Sq<Yzf6vuc@;vb)tR$ZU$QIz&_WKDvh~%$w%NP
zz;5=}J{~N7xpF4q;P;)JfynuIgqOvjs99Mmo^^l5#GlH79^M^fLbbQo2IpI@F1+Bc
zFF+ssclJJ`jr!)$<72;womF{-KzdBmwmF3j@V@2D+{%-^AxQWwDW&kA%7y1+${URw
zKm5Rvn`}usJPM)L$^QGU8nY>bgQ{_H`FVN$bjEG|Taq+y@KTq*<qZZ3f7OXjvp#gH
zQNb(!m6vCg^o2TuoPs|C<v$LcWx73u`xO&)aED1TI_9r;3`8LtT2Gyz%FShHWT0kf
z@G$Lnn*5W1U;ZfLttWnQ)Y8LR)31t*Dhhu<a&FGU(^HX8TS>@gcoQm$*dI9Qv=^GT
z%vEgaMB#0oms*K>b@G9-&T+VVNO=3=?-%)ic25UWbH%KyD{vq*u&?7r5Ecq)sZ})>
z>g+)Kj-8_^2M~*jl$lGPZss@^Q6f#QBd5IPep0yb2v3X-!^1~@lQb+RH<C$CaeVYw
zkr@elb8E{WE>&@>8j<$jfVe5xEe<4(@doP3+HA?<S6a96lcs8z><+Mk+O>)7>|P)^
z?<$QCP(52ik`FEM7#I=}djY9V*m}G0$44RPs6_<c90RwO)>ei70yEPX*<}{l{gys{
z$akJntg)3c65B|pYZCUy(L!~rEY;@$T677fq>^i+K3YO~F4D$SMV+L|a&;DiS}of6
z;fiBPx)(syr!jVSm1f8Jd9AVc{ToCHg*-QW82|ZKC8Y<&4shagkcMapbDl74`ouuS
zMqzQf^2De>_dsuXLh)_vN)w}exp*mRp}=`Ju18~?@q~&T9U{QU$ZoC5evo+W2m0(i
zQ8b_HqtD&j1#_U}Fm?44c|-%UcITpvf7?7CQ8mOOMwZ5Xe1LmAmR!qKQsHlD)LfZ`
zJ4;G*3T>Cug%jlnoVJL<aQ`v)51(r<fG?>qk-MrXUeQiV=J)Fv=cIRoU^})6q>1x_
zFh0=E>iVLwCEk9g-z{HE!pOFAG${%6ijI2INVc>*9Rtt_MBA(_RQr&9z$<1dXg`oU
z@z}D(I>kfM%eGCRSw0Wd&c&6jv~T1^$obP)&y@d%fBs??9amPi!0g2d`oEW$`z{{{
z+U5I{uf=HRca5DS`*vsI89}VltWZs@)U;5oY-92)rz;l?`-Ez0N<V+<>S(=ptgkXj
zOa0s6+}QWc+@eo&^B(pn9E{}!4do7o5%eiCbnzn&hyor$UT?n^(3we;1$@?_qj_8B
z`5?*tZ`>;BIY7`<$=q<7V<2ThfAkigTP)0Wd#%$3hoeN9^*FdLkE=MZp_1`Cr697n
z%<nB(RoWB6bw;M@H|RL>>73V8|MVYvBTk{#9K-ObPpg2CuvJTPDA~woAPrXM{|y-z
z`3+vUfY$+^=kIP~Eb{V__q86*Hir`bt0ygawpokhdk1DSm(vCrCs~emJfY<hPJ31!
z@;brVV1wJ~tqz9d|54{AtR>T>vT`KopNaW~<0~o2tc>_yGjFa6x)Ff?N+pib=jKtw
z2vy&|PEKHL@L>4w=I0^b&{sc3w&64h#X<v=Lq>*(;3c0A)u{h94NWjq>SALu)6h@e
z%I!tyPM~YRjzRdZCS{T*#~;LO1n)iXEXMNpyWUlm7{UKtQK?4-=3age`2%aVYu4+X
zn`59-8}g<c&k`&yXjQi!Z+c+GpJhnA9Ui`j#BjSfwc4@T{ky@;z^Y!RAvD35IIORm
z+FXA+J3rSbL>ppS=jzsnr>o_N)%%%JP5*zxvdDdh4SXmsqf<-&$ymy$-I4BmL@X;y
zsWzmPEiCA=^|PX)Vt*!kr3)gRWS1!(6tA^SKoBNVW-W6njua|N!2ZtlZ%gji?1O3k
zAM<R@bsU^-r<fERH1BJqm7doKcM9|N^_O&^k0G~M$AUShIb_XFjGASkvj+c(DY|Z+
z%><yKp{c7oRBhNU;;`JXxY&8Q%lb4SO*NVh-Rga>yU~TDoF&BXd9(=k*gJ054{o)=
zf?ng~YLX3fW783?S=6XER3GAGW^MHf)oiPWBm40D{2teH14u&neI8n(qbv0kwY9Vw
z=~%x@#OdqsJ(S9XOX?XKG9<4^#gLL^JO3US8ChRHF>N6Jk6p>s%I9{+jVrWDrCw>L
z_+b52tIe!zDJw&Er*{!zeb=|<_sZGXnJq!j!NEaF>U$=9qsZcGtb2zEd?+ik;8?L+
zs8UYlu$;&;&i1joxZMEp+C4;tYSeKS<6DpVKX3LRK?an=Vq;+@*V3mQ?Pkv%KChQX
zcM0LOD=N2z+io?=_lJjHM$kynsL{mXA@{gssFnWZn;#zbo$StCzGF_URaeu}QZ?k~
zaTO8|l2Db3|0$trX~#$<>bMn`ADY-Oy;k|LyaBJ5t=;RC2P>P;g(gt%A46TeH<WF^
z5!d4#UJo}X0XBV1zGyI<1kBxMhAHvqya9+eNjABut+tez$vIuJOaw|xOGTkqGsi2<
z2tm6(qM~5y>;N7ip^nPKg~3?RhG5n}(tNEDfW7J1CrV**>5g5jH42Ya#M3c{53wmE
zs5Q9*Dyq6~6PFCYSyh6M8|RRivoq&ty%$>8mV}cfamoP~`)SP^dL%?dyr#dt-QC^A
zit06+ZLh%e*uW&_LCbAz0*N1(>~qv~i>E#psM%O*N_i@II#fy&<_WfVoSmJydb(<r
zYLE{MTW|m-T#9ybnX6Ai5_F`Twi%y#-zPTWg*P-+&G#=C6@4<bv=k0BxS|?>aGtL2
zua>Hh=!X~CWQ7tLc^eVsX?!p@Gs7b1yStj<LluKF=VZRRy8g%yx?;6+@)0{UK&Z!A
z3rh?0vqpDV(84S>AQ`2nOPexy3WhyH;Jwz@_u8BMLMNMKSzcDgW54M9cykPIIk&Q0
z$LV*IzL(&G--F<V5Vnwe&6`K>MT7B9ujkL>%kL-VhriPeWwr-~E8l&ED0In(<dy8t
z6vdEmrdg&tZ`n?zHryPE3U^K|fi`N`qCeR<Il+GDY0=RbWeNL@En{c<9+bAUv<wao
z!l~D2CvtzvyYZR0Nmlk;C_5pWw+3d?s8=~v!VvK!c>imIXd+VfSN_-Z^ho)g%#{})
za$&DO88UQ;K?etNz$BLo6AC~+u+|bVqIJUNzbBJcq**2qF6j%|x&G?%SiRBmDZDQt
z?LfeCZ7)uh$JIwpuPk-V=1qvHcNQ8D9WwPi^L+mcW8!oJl+)Js@aCA}pXPgmL=&vS
zcsTo^P_I;j@$j={rd;XY16%F}R4zHA{J-3Cle1siVk*_xJGwhgqN1WQ1-%6L_%JC1
zu6nUWS37(zmmBQ{Vki!ej{L9orZ9*oBfZ@F3llev_gISt$9WxJ6KWAAG1ygEyd#${
zT+OtjSgqP={-tl>{(N`&t+6pWGqba^^Xs{&prBv4WSaK{*VJ$R3+yf=6(e1S#AO3z
z<!k{<Tj&xjCZ(o^?Nh$Hr|sAZdA|(q`S5BhRlrrY*SgQ?WbQ}&cM38xVaClj_1jLJ
ztrk;uX2W@YG=NHZg`0<G{`<1FHn^}B8FWgP{}e|2+Gyvr+QIFq(D1br38-Nz7k=F3
zt19JH=OR^HjwX8}?2GFDs-nEylsGA`<Pwz0$k<M_-fX-aeH9TA@f`5TcxcOIE8yS#
zqv23{0t(dzuLsb@6Rt^2#n5=?FGO|SZDFvp3%*kh?4Jz?>gD|8Aj9`){WkOGPcG+8
zF+e4GV@-s^K7denXsK(d)pef=JY*2^dV}%ynA9+vNWX9TJ~2YAwL%rL@b|fkW9z%I
z-LK-2iAv$tk$%Bx>T0x4Y%Eb<epiD#^xl?jO9>Z5#BoaN``sV~T`-11Vu}cGC_3-j
z@%uygZpa5dl(U{L#%sJ$JC7HSDf_}YmQxYn9&RA&_IV;Zd1o{g0x@S{gB%$1Mrc4n
zkd4FcpEG_fr7>m-w1w(#yii<bm7;HM#r8viM|riXjXHg=ZAY57eI9Odogmc=HZ`Pw
z8L_jk)e`CgH+QJ~&w3tD!A>8n)aA=B$9Ok>YT<~5A(+gnLwnJ_r9>>vGGX4RPW9b&
z4xDNvh&XldJp95=j}{Cuc_1hS4^XrkNqT?R-JrO+U>Y7?(Wpo7=c+PvsJw`*_MCSb
zE#=dyb)5sh{rQJ|QG=_ep9qud<f-Vvr+=MlVq?7XW4+t%`1MUyb&g4nN$<-O@gA`r
z!ltv2wnJTP8wkjDbSdrI+;~jICOPLK92@vdHWod<$h6g+!RZH>2W9#o`wcI}wc60D
zlM;UQKF>^)l_puJIxN4qBh_S;FPH$=!iO`BKj#JI^ed6^{;2lsQl8gGyJLd(wj;DD
zao?r!I9v5ws!<;6x3h73covS&6Uzw?w<hHZWqMu72aueFCY)&|XU}a(x#UdHgBQ*!
zinRJZ*koCwte@6_V1ca$>u_7JRBw%si~wL^Va*gNLVQHn+0VPbAR(c0UGm1^;o$+)
z92|8%>4%Z61_)hQcD_2yR5<<@RW!Dsn@Y`(2qv3O{ItP>S#7?h#mOEcZc}N`NA=d@
zS=??zDb!(mFCgg;zedq8fd*^XKCk0mHuQFXCe%^`{xtBwKqxl3>&?-At!i9>%x~A#
z++Hxe#Q$b>KO8cko}{Q(R$3aTI|6#L8MvJ2%u$<LTpBJXcv<_~_A!QPr{k(FtxCUT
zGZE&0_uPKkQ5`@@{pQVcz48LM)qbC>nzhy$Q$<yk<Td%Px+odRq@+Yb0>Yc4b;D+@
z$|5^ETkn`{pR8S<m|gD}`0o_g9}=KZFW_8mcn~*Vcvbjygl#Yo9Apl9hXZte^u<M<
zDz>hkwOfF|!l>B&kt>TLPYK+yU)I()K0^2Y{P~JzM^C{WdlL_Sj?pfkBja_PWf|x{
z@%!_AmqE@%+W6jL<8j5p>jC*tB7%6~%BkA$81jKod{*Ch!~4&13au=~YKDfUbt7(5
zV1xT9_xR=!6;Py{u>hOdh%CmsGnu&G%}VWpon{pMCx_#1$&xa%K$vppC8W9*Bl!lR
zJ2sC*MBmvaG}yQE(3!@pKVQ8k(iT$BlG(DSiES4jl#TbyvX;!YfB$g*-F?3jzgZ`=
zKVPe-8{Spqkl0F-V+Uhzw^jrH`ihfwSYQ)}J*IdV^9HLvKE?*waAcYQ9U2f+&?217
z{e~6hm(mzEsK$L9sGY#$WcsP!$j2wXz1?qQX3DxFHc)veJn-4ZSQ#7VfcRIq#_MM<
z&@zTo#~(XJku2Za$!fH0pZ&R_ey)<t=;%2=#$DTF)+_;EC?)G%ro)Fc69@(>>B5wT
zC@ZC~Fil$7Vx2A+2>xP{cZqQ#j^S1Qol4EaqxAdZFAaVaJBu=U9W~k>SHvI}YVnBZ
z+ql#$6H{6Y!u6K4;Kwx$>&5!ZAnm`GPAGnFjYcBZI<5Pkc#+ea;Zk-x1t%G5Zh!6B
z<@=Pt1Ua)Z2P&B}B*&e|-uQTZB{o`&SUM}$W(#8sPuJkrAJs*!`yHxQAh(=|@bF2n
znNQ5N_olZApG5DRi|yOb2k0T2{EE@><rRMpK4-l_R?>6Y=weQkla3~p;(A7;;I^Gj
z<+P57jI^`0wRdnxpS{p~`}XbFqFjmr7Wqcs3?)ErUx2WFJ!9%mUO|U<;QZ-2?+s;T
zJoZQ(e*OU5b6gr-LY_cUWK8sERFqp<1#;@j<Y=0d{uwHdw38#S*XcTwd^;b1A4N1M
za6Zy{Jj3Utl?X06k2CoFR1tztTam2vZ{K!a{Tf+m2Jw1a(8<eDH`WQKyPx#JD#F8;
zM4UGP07t%JJR5wrL~ra5gL)yMUKPtsm17VEo@K)x!M7rO?t7be=lF1~(4_-5-9L;>
z?rhay3OrMcs*7-?m!@yjQ;h$+)?vV_tqnCIAjWa#`csov^vUl51R|dN*)yA&k-?td
z-`3Kip{*T9SDLp^D~;XW%I9@nO%;ZZJXJ4!8@1AWOSMSF{VsxTXtjN5-H0L-i^Ox=
zb~q>y$}}+&<f&3ZM*1PK%w{HQu2R_bFS_DPFjA0aSBMv?|EdMq>Om;YNT?u_plJ=k
zEfiaDeKqNGji!s$GL=^gk~(~nFQ|^TJgT0!yY7CmZ{>sB^9ukb=7VJvaPWY=Mdz^n
z;lho0FGPU4ufsu__4-v18>^xK>nVD{;yP-c{XwMgpfVw-I53`U!Vc?5P~c<<#YNPi
zGrP-#TH1O?TlvhB0Cy9fs$_{cG&wBoB)qu2HO{VfFVgjB`8d_h?<P|lDOb4M;sOD~
zpiaj|cXyE34ZqV)VYDiQZhGTP1nML(4?1w6bSiR2M6X7qkUhD=U{TOYQC2GK!+)8`
zTdW_64xBj=JI?LArFguSK;1pW;D@}sO?<>Az~pN5@j0041Q(b0iA?3nU6LS(%~Od|
zblK9*{Z$~NI$AWx1ZH=#_?vd^Q5Tk8$h}i0-<hp!cL_7`h|(XmAe12BT9+2QHR{wa
zx${}r#ya`#mVHP&$^LD6g1OYiv+=r-0I55OB_{inF<gt`ed=n9u0kKO+ns!}8meN3
zI=EP&X%zZ7INHfJmUv-mJp}J)_v3M4|95=M*GEr^W*unEPe0OZO)&(6N=Z`>UJ&Ab
zpa+Q2((Y%8Z;?mHbZgG~=U%U#27hTJxUKtepDJzyurVz@LcT`Tm5mOs>(<0YW3cKd
zLSxrQCa!Vq*?S_0sgRkRKB=>#tjym*Fh6Ava7dV~LXRB&22;I<1g;nK7P<H+1h}F+
z#(qDxay90yYB6s<32q;C4R%;pwe=SNF>@xDhWcvcoP6M%9Gf(0@(goi0a1OVREk@!
zDleqE;*ZU%i6v4a8_iM;Wbreh)1xCH(_hGIuR{(F4q96HvUcC%$$EHrT%rP%VVgSC
zn=_2t2?BbcBs~}IW}ZfgUc`(KWf-otwrd@q^<-x%Vfp$y<5>)~b5x+`+N*2cK<IU{
zbyg}l5fKsTa(hF;`y4wWfSAkq46Z5i^6~;79gOd~djK|*?wo>xf|8PwfJZYlEOHCe
z7oJZo5J>ENe}DgY+VyJtY30+xlXe&E&*ODAh=h#n@#&Ja<N7AuiAk5KXb{A#bGCC)
zDC$pic~}irNWlr<dfuzsb^<}ib{2>_AG(=rZ4cke8E9+6({XO6J0Zv@`_+xj^|8bp
zS6{+Yv~>)Qc6N$XG}K?iC*&kve^pEt04L?%Vll)v_qZX8+D9{Z6!dS?Ma7YVAKIf|
zVIlKSniFyTXIMjBJbVUEnpEkX<#b>G&%bB!*X*yECM@iQ7G{QZ4tZqplqHL=lJQGr
z2COy^F}+88>J(fZWq!FJ2nLxTt9wFSbL5j*ppUl;&#kAR$CJP7rsUk0M!u8)deH7J
z*7_6FsCB19Lhb(7h&tJ;Sf7)f@1oFPX&YEun)hJQz@8FTw3Yq~)E!GJZx5`=PA4r7
z)@xAvg!Dva@vFV3Y4C$8GC<Cko#rlNvzHPc{5Jc>{T5s8=GkuuN3}O{a+(4a+*ARn
zRNEduHfDKA@&XVA-MZ=8r1peVv-mYuG{o1{R?0oGoU|?LYLK0~gW9X|bu{n2{Hn$c
z8Z6?!F{#vUIIPyV>k<!?L?Ow4<5_qg(M-|yygL1sqO!CF%mHv9h_Mwl5jSU`G6&XQ
zt_fJJgj6Sa93UZ|Un|R+!y4V=6MjO(d(IUMOU1)HdwT@~&G?$C8RrgLZGI+JrxJ1w
z22;yI+Hih0o{OY$H}1|??q&tH#hx7e6d%A**ce}{E-MIT0l)J&FmgXep19mj<c{I-
z=pUmYo*6S_(Gjfl^QuZdk6D8X0zsuo>|yT~@2qaZOemrsTepz~!KDH(QAr!vEFrdk
zLN#i>XHswxdIFrt`a|)gsRAj)XzQGvv6!AN>SRlQSqSM`Hm(un8STiA9U2DMaS>uX
zc`P-#Db*xu;+T)JQK^L0LyaN-WLA#J5iYdRD_Upot)F}v$}JTFx>3mHbFz~)%bA7j
zFUYM8C@=jcb6`4)j=_)1hNEN}tE0R{-?M$yp}Oq@$(4FV(3zff(${?zgIVSzNk}me
z-K>T!TgDG0pUOJ4rL`6=EE_u{hGyh`w6>8Jyh|9ex3~YCHa<2M9T_=etf`{XT~{GP
z#{t`!l>WNuO^xoPw01vJ!1M{#H9d>$*@)C)W}pxW;Y=f0i}6pdANt}dAog(~npk9O
z#i@BLOBkM3F}5D_b)3i&&J?&$OiFC$6U^lIyI8WR_dH#n1H*z^T96Xx6&2(JINf$G
z1-(v=7OFRTK7tjq1^VLgI?kRjHtg>o`iP7ko-UP*eO-8f(NtmU%N@mf>j~Z4p=BR8
zV+7z;uj9k%!b+3B*WGO|q(52|ZhF;~qy2Z+2pHFWNAjSOKrb8en=KzB1y%BmX=$fu
zenEk4BEmrjhkCa<e0<o^3jJu`k}g|OY;&{1J7M>;?wp>l0Rj(Js~!7)_ZH(T$WDMW
zt9c$=7&OoHg;srawf$Ah!YSzPPhs*dsdC$NP)hJ)Kn!9dDV<`3iQH{*F@NN#F?H(G
zlLaL;%Ujr)muOeZ-G-31*IxSKAW`zob;Eso&dnw-nQ?&K3vt`(muJa=us=;Lw|Q@b
zft;%M!t4pgT)ZlxE<IuZ+ys7VcD&ssI#~nR?lo9T7#t309Bl~3W{j}X8yxBs^>@C&
zZ>DMULlV;_DmR{mCrprKMR-s7ds0Z1G>TOU{FJgdb7$sUeJ?>^|HJF7)Yk6@ZOi7y
z3*ZaQS5=k-?l$L!5V4*yr`^{cM_VgXX^26%xtR&EDWfv>yQn~~pC@8a%=}O7-I&xR
zDe{3<kBj3!bSMBW!VO(qR;m*YBB07TahniNnziAvrPm+(XvN~)s}M<I(Q}#MVpy?6
z-V<QaonsEX;ZOqWdo6Tv5`tQx4H;lb)K^WlUHy2o$47_|t9=uCo*0`lPrYOoW31yD
z=|=}&`4Y>h{1-f3slqfm(q97|`PDOxYhsE%IIjL843rUETq12gt6cF)UqcwZLdLNB
zUC-UWjSN7<I3EX1h<Hom6i>~>gC9FpsWA%BPpF=xy6ePV^3+9^H-3kzYbydc_Uy-h
z7FuZf(GW(`Rqqniw5?W~n(I+wT>G=7{qU)r)nD07PB@SoFp1ieCJ!7@+H1Jr2zbA2
z3OVcIDQhV;wEAQHTLUzI>_WjV>-b*Clrg@XFJ#v{3qsdWBw3(T(ja`aH&&9PG&bcy
zUTpf><F`U?JI-3W7uf&a6)tDa&NU~mQiLW>*E{v;@H`G?hnCx3%pAg9Mog>cr>Dz_
zWfX1g1uIeP&C&Pbl1B_CuSZa~*H|{a(XozhR)_p@U0rV0)X?&{Cpa6i5h5jNBtDb=
zxDjyL8k$j6%}@VX(TWh1pZ`%;N=ip(5qkxk4xJtmg*HI$ca2x;ceUZs$mzPebMt|d
zWhnUU%U8(OjdD~L04OVGoPlA-=-5>Ln_@>lhbDA%5cPBg{TFLs`p}b+dgJ+$L~8tc
z(zzPbkJ=RmB2Fj%Nx9rncag8iz)xo8{!de;y&-Tfn(Lx8u3W29=lryp4lmNtBwRLL
zYle<t%V&MQUn^H-QRl@iW#gv=UuI@-PWRM$t#&nzpnmJyeI&63mS>{z%+B=efx3$5
z%2$BtI}X_}nFu){pO@a_&E^AL0lvI8*(7W!h;%JY40jZfr~w&*@2<Q3@H*w#8hu2M
zWuGo@j3BR81CUO)tq>;wafFH28)L3c{vNO|xC;B0<}IKXK`xy_q5?Tp<)!5n6)Hm(
z0m2SIPImDaLuy4$&GgI)VUY4Y^if^Y&?uc>!SBX{zg#PT^%R`#j{<1A&#l9bDaeGI
z4Bp@nzs5^(5p>#XDQzPk;g0FTx^5<wcXfn1r>27cGD}Acwgo^Gri}ryy#VFQj-mUU
ztq{ML$iT?u>+aZ%X9HVzG?ViSZ3hYi^kCvSc&zKnJwD5$euSYc&nLV&c5Rf1G@9fh
zG9n6z(T=-6y<FVvZ5h?qeL`f;12edA;;A4F0%9*4Na@IXMslWNb;@6qilYPW@$mrl
zn=otChd`gUwB7sZ)s=qcBFhw%36h0vd$poTk(Y?H4-~z6j&>O$K-7UPukDgIpu%`k
zsfdbZo$Plj7o9G}R%CMAFkq&n9<Z%<bF@&LZbJfr`>dy1+t#+R=yOvw+4@Rn__(j}
z=yasj33we%A+Bi;KVF_hCb<LZ!acu82?)`D;(M?2P0rVTEe)`!iA<jzENZL8>47>D
ze?Ht))7L~0Li>j9T~$;zJ-^;sCuh1km~=bA;)?|I5MEw2aaYMW_~f38cPl(3{VZtF
z$Z<f4bq&sz?!j&;#r`QSdTMfSiqF^68(A8K`GMumgLaYBvnmVmv8}B?XRF9F^?Noh
z+zd7kc$5u~K<!3;`;&~+cDrDX*yu!S$kIh{^)+G|Gf%(gkB+eXDKz0KMQ|JC2U)B&
zhbK~!l9QW#uMbMqi*F9*4j--$!O$ChE32Z)%HzSfot;S$j?Msw*jj*Q?`b3xDUMPJ
z&vty@k4XM!pes8dD$t!vaA}(!8k9*vAwM$G`)~z)4m~x>;`ADbIcDwT+FdXPU0+`_
zu(E=z%(wuBtSk2bJ-Yj&*&%=pvSgE#+&!*@1w<0E0KkuM1Tn#FyQS$uAjfo(wQKck
zJK2~**w=k;G8c{$Am?|T6+C_N>jT4>8;{^|kOI6^2~`LBW^-c2+Y@2@7z*4c3YHj%
zQkICY|6-Vpy7l(@7{Bk|vy$RZIw{{3J{%HE(}Jl%5?7oA1lu6`>{x%>+0N-{d4}ZE
zHO8s&DHnHl@<lKRO?%<@Oz}Gf@3w}9zh)PGXFDRJRmS$88wG)<n}uJZqa+EwX94N`
zqHP_pVq$PuX=jIn`x{MN`AS3U@NKA{`w8^{*THHv>_zr-c7d_T50t3G9ms3}dXZdy
zl?Zcui+WvEMp2si%lGACz_Zb^>F~0ltsNu&(9f5JWmj#ZZ*_cFHA_{7$k!0=Mnb`Y
zx^vr&sl9!#jLW~GT~i2^RD1fsBXY`c^>%ZO(*LE<r`cW@YUwMzea~rMfOYMlUljMS
zIM1(!4E!|`MH52|lKf!m!%)ujw$k9l(rDH}CZdv0u~Np?74v?J@s}4s{(Ez_R(ikk
zlEP1@uynklOWW~q=aBjh1dF_C3~U1727p;jko?i3j|UbTmU|5@nG*|rIOln&cT*bm
z@k_@!A~m)m&$-O<@XSX^c8^vs&P!>96!EaIJ0ur(-LhGJWbY*F@=if7Zgd2R(b~j<
z-(=oZXVa!+M4(`5WPJrT3~F>pTgtM_ZF{rI0FDw>kfvpP-MCP(LIjLE=hT@o!uj^l
zY?UdP-KVL)#dCR(x2k~8{pE>?Hi(bIktEoaD+cbM27h^X@P2ZFnSQY**n>;m<tw4%
zaHvMkcND=(B*CEjEEAt-3nj|nZ7%o-auot>F+FRyqwR~x$Z%Ir5x+Rb@O=9UT5n8P
z7yh)`nIyyS<<Zo<^_>(x{j|cu(hFvOrxUko_T_6(>J>ACY%&n;vO>tn)lX&JGm-Cd
z%X#^QV{g|=AV^#x3Gy9_^&KZiNy}!BdJXp~IbHuFDP0Hw(W+$<=o9i|{WIl4G$J~#
zX5r3nq1+vB?vXN`Pkro--3y6~TtdAJL8>mK1QV0w6Bj=x?ZkwIg|k7=_wc>7rp9@#
z&4V;LgicmpU%%Br3FkLFsdKX0dU-XYd}y_pRt$<Z_B)2P?q=0ne7sbPv~fnD7E{9g
z1D*#j6o8wf(Yuu#J5O!r%cd$X>BLrqkSn&g{%YuHt@Bo#dToFnFEUy;pl8Rc{Fi}i
zm-5o5F}HGZYX*jTg(1OQn2+~F#*TLv<@wUFSR@>DEGL_TarxSv?Pi+l<Ie~=U(*kl
z+^p%NqN_?vJw05m&#v0M_g%9mjiUXqL4UUTHa95|5WaZ1ayV2tz?B4XNFh_;(tF^i
z=Fi9bdwza?$|ykq*d5Q#770j7w}YBM=8w~*A+bWjf&Q|(KFQ;Tm6es)<U*4dTDIO8
zIM!B`Ij{~6`sW41d+vk#{1ASb-^IgrGgSrw_lFpr4y@7wfrvm=R@UQ8eM21R?)kCR
z$!TH3|LnJ@$isWHX*wXt3HynI#Y}3^u4>4W(=+>_l>|2m0}1ehoOtfj9B)v4IIMuX
z*aJ!dVcX&ir?*$DOLPcIJQ|Ay+Pwat7FzNS42nm^z`3E2Hf;m{%~O9b*{RsWaUdw#
zK*W4XZG`NyKRW%(muN>9$A>qN??kAdt<$}ZkKC>#7KfsZoy~6byK*^XPyj?~ri1%z
zSUc}v1bE3K%JCztMpo4RZaz~Z1_V7WI)MWzg*x3HWhXX7nUQaQSR1){{Q$bv-Hf0I
z$&yq%GkP^u9^`lZjGJbPq-bf&9hWISg1pb9H0s57(Hz;hKt}mqQb*v7VKkS;mOl~M
zO8^yoSIyc?f9C>D#;c;u3M}#iY;d;zyj!|BmO|UHPNSd0LZS!rb!$YX4olRq?7Z;A
zRNp^c)Hm?E<s}%b@Qd=Xv?l`gsEIImB3(vbeiu7#U@>l+wLYU;%O2M%P}P4S$vJn|
z|7BbAn+wG$!3O@(E<N@MIDlC*cL(cak%d-@wc2|?BZs|5Ag#1T93xp<_u&nJy{USp
z?hlt}WIu`4K5h<8r5-W$Y*L7!y(w+_LH~d8pCW<Y-?}r;%~0%#-fTh{KZO9Fi2F}X
zHJ}6ZrW6w@HV>Sd4wA8CN$E2P)1433Nnp{k%9)JWz3EJgkQE0<iFd;Cn71*8rorcA
zO`c<QCo%A0SJ%Pw&m&t>phX}_wGMNP{ezZzU+plS2gS%)BXa%@ahmxY`NWq}hQok|
ztMjWXA>XULM!N-gkjH{U*TiJAL^b~z?z#T``&ZcS#=^p)<9c47Fa|*{Q>{0vq@X($
ziLz};o`Z2#3^)_R>%Q#hTs?4RZ!Wv8^OM0wz;EWP(#5N8sE9HR#{e0oJYICbpieVT
z+JsLRBdkV7Sv*>J*1Mq>b^vB?;7#AdD`Q6yQjq)L=9^G#DpKwbu5*I0K<n+{cbQN-
z3Q-T+t3eq-LBW{a4D!qgLq4y!+iJ<<nSw2?F68>UnjUYNE6YI(B_-#rUZ-ckoaP+8
z@;fDBvbh3-CfL=?0qn7+uI?%F)!}Z})pRpF4t&=$U};&%H1c_at>L`<RW&^L>oYR%
zVJFg=o?LHpsV#35aQ1N&aQ<)}yKagk@kktq1<zy$KAjg!MH(@(R<o@S4-L6o?!f*f
zAF)qwm!D0$R-U$JedNh46p63@p-E&8kA`NNlc3!f1{CF5b)*Evxw_Hu=4y|GTFdK@
zpUCAq{I4c#`6x|#7741sZL9vlT#E9A*G|9NT(^g@MV|m5F)<N7!7y&JC$U)~+ihg(
zK&pYRREJ2V_|^aVnO#?Phk}5ed0et9xDw!8`&ttDjBRno_FJgObL(ZYsIjrS|Adwq
zpNNaQi$RU8<3?@(6Dy~bs>2yhjR=wTZv6CgmuUbP>bcV4Q|({B4aOkqXggl1?DV^?
zWBXnd@d&-W&US*c#9)s2SL{9ta^VlI+hxrghK*$;)-V7Ek37TqXs>?8YIcqRBl0Ec
z4L0@xp+7C8f2dv-p5)4+q+}Hq9T*>H0kbI=s)hH(L(u~LZ12vBcJiQxMj@sRV46`j
z%!#jhA3?3Az43kW?yP@JiC<w0_1dPLoA>rdfzZ0Wnd>Gyq?{UraN+bU2{7|Mp`^9q
zD~cf~)sg5!920+~_<q=ipx5<7@QgEguNxC!I>ltUwj>H%9n9JN`u0LPmJ*H|><WZF
zz@5HiR%6He06;rG8H;;DQ41Ad;n~_nJSzM-xTK_~rGWr&G3NjNyFDR#x>4V*Js@LO
zTk>%LtI4yewb_;1_7(7Vb?A8~-w7NGE0SGm?D^Oo@@jX>wYq?diOGJYsq%8C^I~is
zCL(&+_qLk#VdC+$QSK`#`m5vgloWXSpauyokWAQjbXd~~d^;{UCiu8OxIQ%XCs`P*
zKrH$N(lRPY5`#4!AmJB^O*~jf-plq<YHqIKH5{*+I%*4#y!hSh{jt2ln?Rdp!vrSS
zNI&H-U5yb^dQ*Cbm=b^Lt-+jdA$@gu-yglq>t*{@e_dsHBDTIhKeh2cXc2b022-U)
z&~}&}p$2C479aP>oXbJk2NdZVaz$sRiF%;{1aUx$=U!U{PP13QKf<}X%E`+Mf}Wpp
z#FM(bx-<ikh=FkhFX-K3<zM@$6L)IKJaj=tDrGWY%hSk3jZoLC`pVPRb9tXJ!8q&g
zS2`=uJ$I>XoZSMCHD*wh4VR~-8U8cMy_f!QpirVhQmPL#SHo@5m@%`j!};!^Xn^HO
z$Hj%Kw6t`dF4+4+n5Ay?C%22g;rwnpC!%L7>a?F&K#yb1>;CmEC4*yQnoNYe`!TUf
zr$)I8POEq411abDd6}68uje#xPY6o6ZG)*LX>g^~lw!tPTU!T|pZ0elGmLZvvf*%`
zv<rDY9HwEdvy%_2$bHWaV87x;hEwtKsf{~3tPjtSua|8(dAX_J`lsCX097@6qt+RH
z_kSofJwut#GCgJNiJF?o%5X$0oO*(M%Mk_fc^5Q@=l~YqrjHR5ZY&l4S`<@*c@P|>
zb#=I)d@C;=8~-)&u0C9(XkN)sku5?l;#)YYqEOx8U~T6M<KKZx42z<d%f}bf7ezaB
zN!SQ>46nKIO1XIHn-h$SF+fo691!dtV~05dT+`A*&BmsZTQb!(TC7>aq^+mL6KF7-
zY+OafX?2vwP1V_EV!CrY8WdDjXldzK<v2zLN3$I7|LI}3w?Cqkrr)hHY;(W5adCIf
z(=1zVTb`b-yClMz)nE+%iYUA$3<q6UYH={8D!|qgNXQ4~=H~bpSBeeg8|xExiFVEn
zpw%y}tt{C|cjhbg0|Nu$PLEGjpwxV(pr@y6Asm%tIoCmo00-CCTa8)hYO$d>@cj?k
zcZI&VxTuh2IW-~H_<L_E9|;k$qoadzf|DGJ51xc7gnXgGHn=~033z**w|Ow<lfY3s
z#`@(!dQ#;?)6*gK^$C|k8<qNE4i1KY_f$1CHL0F9{79qw7Y6FT6V*h^(wVU;D>v#v
zt5K>oG&MV0-DTmJv}}=1pDZ_b_s>Q~%k3|18<)q&t3W#7`1tsS+1Uho<+9IdKrmh$
zUg__-r6tz)I`0z7J`;%J(5Okq(MhQ$Wn{XM7i*LX+}}exE<tm15h2FA+X&uhexX4u
zhA|Y6`DJBtWWO%q#xLQk`RRJ@2Lk2<?t8+N7>y4eE-vhs`ry}6x_lwx|KTTT?j9bR
zgyKRaAHUY)l}hH%m(1D1Gj7=1+Mo6FUeLl9w#mfL8tpgN#qU3Zh|z;5vzpr4+JK-&
z4|(I_vViakg?IUtHe>`2PS(4JkbG0(7|X_XNy#utI)<Y6wK`03G8P=A8Xp?{Eg0~^
zD=aubqTm=KBO&zB-h&yz*_s%!&z!bHXW@Az18#Sb|Co6et5ygNm?M~*_ndEvaRo}s
zO3boX5xPZ#Zrqpp`-`?^NvLJjSdvG!D|xVA{s)m1cG1Z~2?8raDfqdk%M+6IDwPzK
z=1@gMmUnnx|0f_g520^@O!!{)+VFrn!V3oDlw%E={T*y%!+CxL&1Z0K;2j@g{U3G|
zJ3O<}&_|Jfq`ui{EzoL`4ys8f?(2T``4Dlw{wg_0bw%y}4=epV6m?=pG{f7`+?v<$
z%R4bY5;BcV<Z((iJFkiS|G`pU!dKS)*C7?b;Qy@?dGl=<_u!W?sM&+$e?66mMaLy1
zoS(N8bEt+Vp0>k<#K|crR@%`2)0ve!qowA6^W7j-U*FrJEqEMSAn@otkmH@zEM)WT
znWSdr9};|zY9}<skaZ%<MwWcK7vkbW%V7Hvo~W&iJd+u+sB2>R-?F-Lm)o-pk>h=|
zPlptwuJAU!(SSzj#p8cq=qqJ2tDRUE1%HhH>((*)I)d0SuBYEW#8{&~{MP?yp9{*N
zGV^>90-*r#=`!JyR<GqY^1a+{$5{Anxgeh7CGckXmou!OnxV^nr7Yg2Kde4b@Bgbi
zkoDXMf;<A=XksaXuf=;kwpftRZeAXeK5oF8JaSdad;YJP4-n44ua5v6np@)#C*}#L
zy*zjsBu5<(MAtYI7zjI83qTH6uCB^lMG%{Qp+mZeI8(|G*ubaZ?}I7<lf$oXGlML@
zjG_EM+D8YvlMrWh8=A5lHMzwKt4z8-1ToK*E22?Xif8(X9?sKHZPXN?_IU(7S-s2S
zvsX1Kf89b5KX;<iBW(8K#gCKjo!|oX!-==Ff`C3Ifc@5mlRMt~ivX3_8qQ?hsz;+3
zdLxCg@y1v>Z#~n9ONI`UQLR}Y+=Er<=V_s;5=Pv^LW#W!LuM9{<NbbqE(d1NAzXY3
z^nGLss&b&}iA%V$x!S(&hL%THKhE2kqELCTK3My1PJC(HMF93Et>s`MRr3~7jwlBF
zf#ydA&ZVy#v>zTj_^^PBW)K-vg32obF^IwKLF2VH`35T=P~*AB`KG45yuAS#_&~g1
z$6F>3TgR>lrW=y2jw&y=#M^p4dDh4QQ}q6*YL@@gANNru*)Gr_fI$%R1^Ie;f+32O
zMAa|$V}&+>+m>$@1B$1b!@ikIt)0&$(!-(3*#|N^RLef04#$_Uj||2L0hy>JMTG+#
zoe+^oO#|<0l5j~c5qsHxMEpLa=S8~W7M9%JkcN7oReF6aiZAZc&hX-gi1OG0#JCyO
zz6$U7Z%2o1^QAM{IC^ssVo+#Y3j<3gVrVRxFUPa{{&D&84~FU}yP-^WLuMQahwZ;Z
z3G?&wc;S*nb#A*#@FkK;ba-oB0e%Owr4P*t#T^`2DKu-@%aGU;vDshd5(y1=@7K8c
z2N<D6Il320jgaVXoc7y|I|YsihP0wrw8fGlo)150MUQ8X$Iy;89`3+<UDtX#J<>~&
z%k?*cD1*6n;N4$_xirwL9?@+z4&PBuBekHAp*JT0&^<dnBzi<43c>~GU^Uuf!6tV1
znBf`32YTt}1IE^lfEet}7vW!@D3W4267I-)*-ikHkI?~TAN#V~XUdmq#4|tL5T8EH
z{@@G^<N*@`GNDy7#W$`M<1)($-F0m4TZ36s@Q@@!USu@^l!WSLG?E{Q)@=fc3Wz{I
z-8fss2S!?_%x~oO0P?7k@`anW^r@VMml?-`#iK(S24SVf%p`ysQI5QLK<l678sxv7
z2n}C|+`|DGF%fb=%tejtGLYJ^GV%pL{Q|L6bn-q&X$pgDSVn~MH3KzvC3u|`UR_Wn
z12a%1deqC$u3BW`lR#2GEF;O-n)&-1Xn=o6%hP?kBR(26#h1#@EoAwfcX8MSg1`%V
z5kP)ePzr4+V=*9P_x^8o!l|{iC-4I?9UG78i#)|G>)9Qk|FS?HTKIYzMTWn|<61jl
z5G&K*2(K?NXWZdu3kr&zEbkuS;+z0|sh^3-Rwd&yju((cgs_hy#@j_>seuQvJ($b8
zKGl8mjmg}}Ng3yNrG7IPY4nYWL_D21j?e@?a$G_}uS-UtzgJMN=+PXsRQPEROY$T-
zrV2}Jd4H`1H7G=I4z;;DeSB5*;R~APSELFT{^-~YiGRHELk(wsV1!=a;g)JfLCbjh
z#cV4f1>1MhvaYyS@-*IytSHm3g4#jsM*6gCw=udDLV|k9JC{P$E9ud<)qmKH$&4-h
zVEWkIdv@|UnmwECveZOhFCe^9<+fli0QLIdB~Ywv+?ofd)X>hvcZS69hV>$@+N2!i
z=(7?2(MRYe7jP?YzyflvMk{R)@<UL4*JL}W=wa1hmc%+h<w5%-iW2AVp*JdJ2amrB
zm2}Wdcyg5nBGA3h_>ms<73u4=yOl<_dk>L)Pz)y7rMa&*;Hr?KEvxrb_!R1aeN}@f
zhM-cm{;d1pxgUDU>;paCH3Pcso{Fo%yrUacbl_z_NO5u9O(zy0Uf;}QKzwAW9j|%Z
zdERS&AG$IB4zIyvMBmLo`~W(aG{T^7T!o!+zohT<$hbF7)zwvd^-Bx*fvgzl2a(RL
zN@bYK<YjqMiR+SQqYX!HGQP95Uft%;FI4xVO2XDTTkl^mEJ&pa;A{JyNP)Lb3o|hL
zl_>xK+y$^yJ87QPA8}sC-0Z&=+S*FSPpW&1mxjpz9O%XG8Cl)05Bdo|pH__v3$?ML
z{oqK!;G&zhrfsc7dB~~#IwpXZeDXCfbhtEPMm7SM_6fAoK>`$wQ-QrMtsJ)6w)c|h
zjan0_<`bWeR}2o7aG{}|u0KDNkqo$5*Bv-QN!VEiLxM|LL;FryUio#2xL{z+2W!RM
z`SHJd_P6;PX&O#FHHH|E_DS-a;QW`7{f&vz$m*02;V#_QcDW_~DYs*|5=AcLUVjJU
z;0q4G>cvW!z3}DO&_i09xc6LKTyNh>f$$+tAJ<e*M0|=xAfN7+HFq^u3<X|ScNR0B
zQm%o)`4pPkJ$%pCyOnLLzpaQ?M*rhfsAZ2UDHXpWMfC~qcT(30O)&Ygv(nq2N1T@f
zuybkO-zozFI|yhBJt5OPb%C-6I$k}!&x!i?(6)H;{pXct!5~e50ko4Cel8lwdD2(Y
zsUL+3SfH6O0<)9OCbze@6T@w0wlGqv%f|Bo;Ta6luIngp6F~it7+$Pwjd|cCtrk<9
z5D^qC9#BBH?R`>BbL^E6$TC0A_Wv;VR#9~XUA$)>+@0VW9D-|b5(w_@B)A3*&cOr0
z-6goY1cF6y3-0djF1M5Ko4I$*+?QEv)~q=%JkY1QPIuL=s{h{mx3_+WA#7H8^~Qgn
zOTY3$>>T)w0dUIoH@u2TQ^VuN%Q<Z@Q5!&rI(kh7UmMf_tBN6pZv_Ac#Zu|{+X<G>
zOeJQZ=jlbo;odq5K(vYRT^j>P-P}-yDw2^Zod^NHvU}Z^iUwjhUNQn!u3M{WMA60;
zrI7YHU)zC_k$OLS5527G)r3rfvm$w<#WNM#jrM7X@x9kir6HoWbI+-SKTmo~zRWEq
zoWre|>uZGvB)pw|>+gC(94avNalFrFcBU;}kv^`rQamwxG6UWhtNXbGOLOg~C*{*U
z9oMV#4oZu(DY3ffum!-yaAw{$q_gOF_%zDPW;^Mp!z)ru_TS#GKvQY-snsX++{Mun
zic{!2856sDB;ZG5)Qdv0!WKrDcBA(ixRHgBa&fvXpItkV^6lM{F?#nuW8Ag3@Za7G
z3;8|AY5(edirPJ8)T*UMxIBUJTSql-F*9NWK$m#@?{h3N))M|UL7pns-et$J-fh3(
zoAtX@Tw%k**oVg~-OEP>78dQg>()Fi`r_WclFivM($FXaW~cosCv?YNndfDSToVy&
z?7X#4MgJYIe-xv|ks5fyzxMa{gIPT_uKQE%KKE(iFK}?aKGU;JrQcT$2Xs?>Jp3{G
z`D6B1(Kt-=;E>y&Cnp=r&VcbA(sH@aa#7L*{Ov$qDB9ek^SS7qdDIxDQ1KocYSQ>k
zuhpKrYX>7knDaAx3(chbWg8IEypi7{bOU9aQSN>>oI4`)(tE~2wepu~WXe^9UXkMO
zrb?HSQ^%6wk_xkWBbmF6wk#5?{z3wo^Jm$8Vr;klCOcqdee>zvn2DWaL`P9X^zGaY
zEs;QrgYbIQE8wI6Ag!yfxRaka$1iy|PU6S6yRE7>(5${ql<>UjOZdbn-*&mIecuL4
zSpcF)_V$h$5;gUN>Jx63jWjJFVjR6>_eyA(ADt34<HgkSI}J)-*L|v#uV}~xfNoKW
zQUXoW@#=9VZGP9Ai)sr&*v>E`C1&!;p_&2OdV`;5TDVWHaTpqMZ=!#T%l>qRR8DTM
z)7gp|IkB+v+8Zx)xRCf>Sm}E*{yH3xy*==?)@ve_V+>AsMgL*D+4_yt^;K5giMA|b
zzJox+<AjzuCk%9?5xfE(AS6F{Z8ltUp(?%X%jBf^g^2;4f#(ky%=g19(%};2H&#x=
z_21TUNq#69HEZOC=ru7JM#2ESW)Ps3*ogl8Q^RZ<Tag5MI4aSS_{+g$Dn@}Kb#&mP
z=O=HGW}tb)R0UNE7QjQLwKwTXd&SPcz+47H^F&1CVyryvj1CL!s5DJ1&E*#GlQJSX
zr{$p3Mg@~{ew}-JdkghA`rKb>FeTE+5Wh7hlwx^70;iZxQmD6du8?HhFW#=`^}ZLS
zyMsT{+dRaE698r=wifnYzv^IpwXYd<UvZO^urR1HhqoxM;iprbVeGQO?fTu?5(TI9
zoD6?kk#v|-%?G$)p8X12m>M$17FH5i(dgE$vkNhJ6YgMe3L34JSSo$rDrdjLfpDac
zK^AvED}FWs(l!KwwJj4Dj9<DqmMMLc!m3`aYd*f(g)A%RNNxU2B5AT;JmQmdJO%gf
zdShRnV(B7qQ{YrAT&_3V*JeQ@CicauSmfsf#SOVTqVe2<NK2=%kp+y{^ykwLfte}a
z>q?4LW%sp1{J}8r&Om!g?e?p+Pc;Z?%P!34r1v%iC}j8Nl72#IQg!=6SUWg}XO|`<
z%U)h79R^wIo}xdB>b7jXZQL)1`-)1N93FNENz1Zf5)4Zb@|tM$N3;MjbH*K<YS_`N
zaiftA(J`z+=_Ua{nq;gaOG&gE1#|DJer8I%0xRV!6Ffr^5x`JocHyv|FfIhJN8<8n
z=MXo(Dldf3+ht4U)<0ypCgL&GwxG9afFtAz<0~;%cz1X2rA9NG+wlb*s3w>BE<I1*
zu*p(Hv?orBU2ZNY`b0U=NEmXv8cJd4b;y%s_WON}+f|1f{s<^u#nbdTW^`>|tbOX(
zOLDb|h?ahteO!QElZ(>e-*f#tl448aUS9eIiQB0=Lblgecr!kagb+kB^~+@V0c6bA
z`6S%I2{3a7Hiq_vM{x7%wJ*ro6?hVYLw)R6r`5RLjS%~U6WrdpXTGMOcdvfj{a8p$
zdHMd^^kyC{%L$MrB0_uXQP^%7QASC)JTaZ*TPAWMH{SdpDJdy5f{1_sBc`H)o%PtH
z49;*s3|3kujHj#;7O?qN7MxD&*VIF4s$I<th94%yRe?B_dN->!PR+mx)@Ud7X&%xo
z=}*Q3`xeG>-@i)1X<1~!ghvo_-1w#L=Gaf6zD}3o^qh*@-;TC=o_U%Lio<-@liB~Z
zK)fybw-s#D7W%^NS)c#ehdTP3;{|sX&Ko=D-ETn>R^bz6T+pLmZMsMJ<-JO=p75~h
z>3v8?9Wgk7Wtdz{3%9}EWNR=F7-oHeL70)~okInM8>?BBVM(iZGufAwu_0)K(fdqA
z>!evhxoH^rQwB&%K>C#4r_vSvVV>&@A8mJsV;g=vtSR3Z)A;bnK`q_+VEPV$=<#6O
z>64%2pH~1SZB%(nK)stSe_T3a*f(qHpgFi6$Mv3QdL#)N>x-W`aN^Z0aw_U3Cb?a7
zNsG;SYQC@g$4~$qhIe+#x(znn{@z-gpTwZv{Xqh)?e<SV=Ya}wno~VCL(%45x&*qo
zI{ZEkT*2;Ee1)j7EcwUI`sUn0va54^YnvA3Bhk*NSN(h(Z^WAD&q<~}U0o0LHv@%4
zr04MKdJhd|QO37lzI=gnc6C8Up7a!dHEA`_1_LWAYk7}#fqs~FUo4-w8wSt4>3p8E
zldcpE4J+Q>7imqibET&%El}pO3*rL{J^}T9;hC*bY1g(zr)utCdWlL^F#~<6(CW=*
zP|z1ebysb5yb(U<P?6@M-kv~jp&K?NALgS&Mz?v<dv%h7OrmSgsSE>lk}VbpLoD1Y
z(9u|P+%ml2EC2fT@L^i;P1bGDJ2riQl`C}UmiyTAF^Brtd!afwJ78e&531;pAcY0p
zOCQ=)`cRvuG_HI9299OolI;-;l9l)P{HaYS8+Kj-p(AJ%6r~0lSw4&Ow%lw-d$_zU
zLia6|mlt|t6B2eFQCiY?4)}!Zlm}0`g>#Mj3`<O-exsD@3ZURq*8Jq<y5ri8h&xA-
zqq#BqW!nR4z0?@$D?flbg=PR7XkTbF?RuYHqV)(HSZ{R~bh-W8pv^O~ly#6@3uo1O
zY8r-WLeqRO1<bpI2jIkaSf6b~^XI6#et#jjTt_9BiHJ7XoYmSLMNajeK7$subw`gP
zM5PHx;P8tmO<YP(0$RoPGBrb_1r+YelSVICio)Kste(n>&K(ZM<(iPW$JX7N?qjBy
zs7wZ@qI1Awqy(Uw>Bk|GUvY7bzeC$k_o?&6XFIy+47qgrG%`HQ)u0y{eH(D9;BAL|
z48vuV7P7ewCIx*754T@v{u4KRjyaVN5d&v%OsZ$@wwf<hVD@XrAnJmsHdyI+l~kvk
z3>w3i6Zn$K$@br~SiiBlqPt-d>A46`&aqjFZKFVS0g|x-Ha*W8+Tic*S57WX(Dt8R
z+xQ$TYJBWYAFJ`o2b9bqy^n~P*LB}KgcR@BvIpys0}++lc15*gUH7Q!r!L<Rynulw
zR9+3we{)tmXur4%<IDEFvN}joDzj=$z!YskgI#k|3_EDUZyXHsxxf5=ZT?Mjo8G%P
zJ=)Je6vU#1!R?&?<Pz0$KUf@gxhtyjD>i64ZNn6uKfC(zLG8O-R9oxEyl)W~V-b%#
zZIRjS$pU8JWfYJ@6i<gztI~vr*ViuvjY!FLg@sZ~Ez{%bdZH&m^o!Sn?M6OivWv>C
zfe87Yjn6jMFSvYkLZbgP2>FkaMvxn8$45xOW4-^Z1*U?Z^+%rZZ%02$?vsNqaD-eR
z4xHnq#v@#pPSreCgl#-WmGo3Oqba~(_LWRMRacI5)oMD_EA!|c^Svkeq2BNeoD3K+
zq{v}+ww+C66NR?uDw{_QrwcrRgX4*}P$9kh{QFT`cFV`CZAoesGqX)_??~)G<xayP
zw2=8aiQ7%p;BtV<P5$=s!zCgjf9vzNB7_7?%!Ut4_T=-ZuZ*`C9y<fA^I*%31%jzj
z!DG!kHQ0p040I3ck9#$^h4Jvq;dMSnq(>;hTbL<y#QoJYm_i3dMkDDHBv(b#6m8i)
z1;<s-_`c?E<fxP9N2i&O{G5q>GI>O{(!<$q8qDtQdpD8`#cx&isRIH6=33C~-k_W;
zs2#a=J<4h`>iC|o#qP(lu^~XwNqB+Iv4U}k@y`$=fb#WB<+)m*O;=%5<>T%A%WfHX
z!MNBz!bGjZwA^-TPLCr&gZ_`-g*`D@ic%>$W~;Ijl6*hkHUOj3iKJ)hP1Z%jXpF93
z<z!h6pAMZ|$rv-ARO^`yZVpE*8k!!<AzK~%-(#E}&3dSe(}iGz3Ww}C4GlYT5PH?2
zPp5BS*!3~EJ3Zjt<tU|5Lh&gfJFg%Fj0s~ObqxH7MGP@Q@vm{g1uOX{2RvHx8y<9m
z3&rU`niaNS7UHqVEzU6|TmV73QxSz8pS{JgxpRrnJx=WNODGvKix~3!&Qj@1C@%6Q
zi#m6ZOOgbgU9;_X%F8I1f&rP9w4()QYX|dl%zFqF?t~5koN1rXQHAozV*%bWIgoJe
zYS@o7RG}5iOrdso<39p;0v+CTp-H@!qe@3O4p~dJq6SBXwLg}pDiUZ>Fh2pth%2%Z
zcI$zGg2=ph6P%GS=?W)*-*~Awe#8JH;p~mO*#h1Y%|;DfJm?bIEkq|_5imyKO)!=L
zSC0b7lFz;5J-+Yxxg*!TVm4l9EMBjQpZIf%1Ct1nk6r2<JY5HOWPdcd<)5#TNuqEI
zzK8%I2D2+(OCtu4I+^dXyXFUBC*ie4fDWqy&Ce$1l;X0Gp@nB#l2P9YA}I9>OMnq7
zhzwk28Yche1?o-#l{Cu0BtVO9q3EkxY`*tAF-Fc-ySw$E9&!tMCZcI!p_+WcV_JLj
z@rC({F00EOM&Gq3+UH0?b-%7au4v!rz-uP!ep>xq3%kkjZNwh^8Ph<#;S=wlzXr_*
zHOBRXi<i9e6Ye#j2Laqzp8#dAswb1H`O<q1B4}&G60V>`DNuSrT@2KcJWVL|^Z$C#
zt<VJm3062I{-98(OXrW%Ej~5f*lKa=$r42^fZF@xI@yEgb>734K$C0q(bv`Z9T~Rg
z^{Ph^*prB5yC!?z(1LMJoDslm(P0DpahK<QjjrEDMPH!D^sG6gz6?_KnmCY285%r7
zey;Qw8+g940ktX&inhD*y`>x0#rq-jLc;EnqhE)xeDR$7b5_pvT!)SSybnkX%Ypzt
zi}$rftj+saba)onP1~QS+y4+NSa;ihH7@|#<#B$f;dONN*Q;T@{l7vyET=yK%B{hR
z|8Q@IFF>!uKhH-oS=axhdniIA{x_}&H@IUU=L)G+81!ER&As~mKYcA=i(WzhM~kkv
zU`~QAy1VROPsU$Zn>176)3M)kosfu`g~jxgnbf}<A_-I9p#7gb5e(qp#aPzwJ_7$6
z7Y-@#k0C-e5d|jh{l_ul28Rgzr=f<I{J{U_NBsYz$sp@}7|I}W5y|(D0YYoY!~b9^
z6%erRsRhz_7|GJW2IVCH!dj?BW&*GW8c_Av3@6HTaiA>?!_&ca|3D1uMYpif^vQl4
z-8as52CzXv(vmAyw5Lsp4eVr#9u*K|=)#L1LR8)XRTdYVF__l-#Od+2r1`yu?C+85
zmu@|s2IBv<^YYIiL`*!h<!yl@-ESJ1dRKfboX#_E@l0Jh91mSN-MFYF4?FF39+YB6
z>E2?0HYd6R?OLb%9@P;JI|C~&G!#skuu$Fm1mW^cnZNI22itNBpe)neln<AI8F~8i
zA)E%uLN!C9%z70N+djwDyL?t3jnS9xsaQlH5?t#Sd+ORU(?dr9;Kc}FMkz1hPHgI>
zVvzvK*g$SHD8g%!2{X#r0B%5xHNk^%R3N8NoEpBQDoo}bN)9T}54r$|@_m7^`(RQ2
z@f-lz5jhfN+>$zG_JA1Q5aPlFKwV-?UL@5A!qdJ32ZnN)%@zRN0;(SKdPrrkD)=Q|
z{a6{)$N0lKwo|pm_IVBh)bs@p991#D624HBkau#TDxSnzfvA~-Uc0kzSMq6vyR<Kp
zV4-z&rbAtAv-2;0b>o{S_}9VFy`90({Z@EtORXFGo!3fjp%0BgEwBQP`hoKO(?^eA
z){nU`KF&U8jWfTvT}_ApXg1f|kogc6T?E!Yb4aapQ%a`c&F<L1iwNz?)`zOh^$B+D
z9mwo1$}#rJchCE)e2u#IBa=YqUH%sY9ieJ678ZfO6G@j$1TI4P9DX8WoVA#i9Nola
zZBJle9R&h(5&*;aTL;?dR~lDw;sb6lfONqn{j%BK3FZs$m>ggS5`(^%78I1$$Cq3l
zE?g=o*-lhv+O@So3;=q7s4_v;AcJ1(!$x5$>W}&o2p&zPQMI=g6##{!1jKwQSw3j#
zE4cqa%sx)Eq^BbqypjoFH_)zKn#e>nr?+GH?hMIn_BcF?2S#DV(7|YZp<*%?=Kps2
z33U4=snGD=X%Q<GRW3D_Kh=JkNw^~c;ALtqE!rTsOG1SATV2{Gk#Nw>R!%&=_1x2g
zBupIISR=B#o412O6`^7{0C4X_c{v(&hvv{d@+T`w4u<$E8Jr9zPiKGuQ9)nLWmtLi
zWR_WIN5}Pg9>+1o;x5PP2Y|mQWQf8Rw><pGrEo;acJj%}#O>0otVGAJ*!X5UR73>3
z?rcSIorQb`W9Yx##W)5iO|b)~A%B2b01Oc(AC6^SHc}ULu$Yg!!`)0AFjqQ-1E6MX
zJ~cGr=vXA_>|PpqWplVmuk?haF@O(0HsZ{_TvZsr030<k`+3O_vB4;Vy*tY<#9w7-
z2exeT4re?pb!PAYY1WDE03MS*Cjtw=s<)OytxkOHAdYyAMVsJpSH8szwQgJ$HfYf3
zyHsn<=m*rK`Zrv%QGY$YNk2g={X)k6A}Re2nXS=eRZY`A?eNnx>5aa1l$%NOv4XNG
ztXMw9Bgh7(p(`4)&)7Oxy&liNA+N;*fHBTJHEHSoQPx2;Opd6elnhP3@vd)(2?dbO
z(h`cnC~XR?*&#N{v$ygoa1Uu0EENT_JnoD?7Hs@jtV1=K{=L(*zjjyWt>4^WVMC1o
zvJIqD;Bw*pyy+vKanhvGM98MfvE|77-4Kmg0W$=vyKf7ke=g4xNb;4n^LVujI`p;G
zC^$Vf(|iU90K6=<pWlLrrKK^T8`4H8?4tUw%_GC6QIM<I1=lqKSgb;){(H|2Y;@o+
zVg<&CBs@#|Zrof*Q_+K!5n>(ZJW=g@SgNy+N!;;`b7-gShR1w7c}eum3w>H1d^?Sx
zqKoaen)$fNK4j&1H02aXOf2mDl0Z|Nxm^>ZO`5LS`RuM_-RD#{%geaGuKiw|XwWy~
z2qIzDJVbVXQGC;Bva!L-5@~O{$Bdg7%y?Rtp2)Xi8Hl4PX@W<WN3SNPl*zFL%Jp)w
zT(AM?L|fuMUCKe=`B(oE0LV$xAUC+fEK%JNZ|Petm^?n#7QqJE`E_2zHqUZ>H3^8Q
z;F?H)bZ);BMcjq0G#L-KEm=@%EobO$&jyjt(zZU6JOXnXP9ydRe`to=TTGK&nbSL@
z($LFrQCIbyth$E{V(Q+YS6iz|l>aXJ^TNV{=*wKL>wiWHoyQI=2x<e52#Q-36zz8p
zSCRX3>44Bk&+#&IT`ipqr}Y?j)cO%7faj5nGtQb2R;tZxqa4D|{wCz+iy&NMHR1kK
zGCaV%)p+*JY29=mT8U6{-$IrQ82^57ENqm0<YJ^!L&mwSogHF~W*tW~4<gUH#m++h
zsr4dD9~CImJPZ$uhVwuI;DXRb_?s{R7!+LLH}!0FMgEEiF@fs#Cvw_-$Q*%%<&{Q?
z3k3#9J1-17*cqr_nS{D&{9^fONws?E(6403v%fWzQ7_^CymE!r5%b%ZwIud@J7NX`
z2y8jLo+#^BaxigwQJYVutMBx8$HCL{#t)rA9E<k1WOm#2RmFvk(uljsBW7#+-SQH?
zO-C^U^Q-=W0*0U1y?h--c1#=GtASENqUv0xz0rxRMw#mXkb+|@OZ?sn$_i76utRMu
z3uqhnL;qwOS3nBkQmCP?50_&{?%s*)V*+%1CZ+z2CCkcQW^LrC^{iyN4mz+dDjRho
zEv6$69wv)Xa$*FFaLpx)qt)tj+~MuL>V*)rlu;s31xE{?YYw6XSO8S{Fjhtb17c3j
zKm0o;aWLgN!tgZ00Hp$Yjg6MoPx`@(3WLu&j}X%yD7A>!cEInz<Z^N@i*3%IT6*?|
z6h+dy@Zs)~XM1+(>-GMt@%w(NpSI-cAhr<W`7M6QGi&8v%yF7_cM>E+Zd(U;pU%p2
zU$*!9!|~8~*O1C$`hy@P?dKoVVef8WnN?$MAPMBPLV~C|V;Hagv+ksAtH?uMyIC4Z
z>g)z=mW8~VGAa{!d>8PR=_Np;ntF8#WOkJD12@SOuaf4jcFleAoc+8&#o3Xj>cVif
zHdzXW_SJX2@9Vvj*ntvCGzHpn#=3r0kA8_jSr*S&&r%g4J5LFHyy5~pI`iIo4mqcg
z^uZXT$uupnbAHzBD#%LY@U>)c-g(EmB#oG2qgu30{pV6gxuN7wK0#K=tLt6dxtHhW
zOIh)JFTFf2h(-nZTHP&vXdE_-i=6jV+#5|PXd<I0Z$olUJazL_c}6AqohiLK$1hUj
zca!lnJ8P*L_pm>-e6jOEm*uzn{4O(YK3kQ_Ub?iM)sx@}p4dWq2WmY3ZaI4{5ldiD
zzs`L6EDWgT&HZ>2q`(^ZLWyYOo6V2yV8?;$O|i3yAtxxe-9Z|;!?2-MjD*h3{U14z
zlfa;Zkkr#S@-ODmCE31Qh3VeQ>3Z=U+Htw8UktIf5gpP0Wc<{!k31>M)~a)#ec0R{
z6U%%Mmzb>#!lVH%9nK-ksm#lK8t&UrWHTa1fZf6)fQ#nfJE7fwMt+*szmeZC`lbU`
z*+9o}Cpo(n;d(Ud5fqNkAI7<|o_VjX?P@wY&Ud8(D1W`LVHGhuh5&+oZOSQ5FyU1}
zV!@d3zzWVva<_!NAq3FxXKhAaSv~f^U8yBjgf{WNUom3wc72Trux7O0Nz%bS{?w-q
zebU~#7)rGsHDD<c`xu{D<Upnd6Lc-OIw}xp*IbSP09UGKg}=5`#d!ezUe<PGP5QHb
zU`0xNRsqY5Pd_l)yZwphqy@f>#p#mdt>_jXJ+mK+^BJMwFIuP3N~RlDk;UeqeWe$4
zF}_ot1#Nz-9sXkLHy$Dv?c;_)JP)|l3_r#_Ztmxhj?0GtT`KsQ_Se)0k9jNi=20|4
z=s!B$0!(kT9LOV5@!z{+w7DwOdvA?c4aeJ1qS?~(D=oGA?Aty{8x8I8n(Q0yoH|CD
zx)TRY&PYkj^u#w&Ja~s^vnqm%$77qG-OHwc^9?j4rNEC3=caupRfcyS+iT*ih1NBe
zL$W6Za9EmjL|Ln?y=MpVeA0Oz<>tC-|E(p(iNfI)K!9h+6&gv-A4~0!SRI{RO%Akp
zkM)*?rLMZXXx5KQ%}dLfM=>eM={H&pWE<Bt{n@-@BXeBt(iS~!^t1%_FYaz!TM`V8
z4pvvkPi#M$S|HlQ38BUmYyieeQnbL}-oXkr?frLdWqFi@e&cx5U|GPuq%IR-<$&mC
z@1hW?(=k4bn6-%+7&2R;r3!GTnoSN5V}PpB9KR2-Vc1u_(Sffj)^{8g*+;?>2G|lw
zR@$uCD^*NKMpCpaFxoFxY!w13>$?ZJF|4T`oBW95VQh^kGINWwDU{^IQC488dFBcz
zJvDiSQ70&qq1oy;iAlbyGp*%%-Cs3OczS8ED0#daqVSAeQ@m9MQ%F70DiBKGybFxI
ztw|4&V{Lxa?y?`Ua0n1?S?YhW6t$8*IDq+WJL<LHPCJ`wjkOLw%~k*Z?&rP01<mVS
z(X-yO(P8b8tmw!&%Rtg1vtiR&r0*MQ!^dl{mK)d&EY9I`ghP*#h_)Ejl$1{mV8sG_
zHn@4U(Tck3;Dd6R@HiG)KAr`orm!#de*}DqyhPc5{VGF2=lzrQbzV-UtCxz*;CgFg
zTH^(NiHS_{_GbNlFg$IlS@<wy(FGQYXinAp^8ReqIXH9@C-P5v)CJ!sk5N>DA@Bj^
zen!lU^n^ib$6ChiRJ&VAHj`~=o3Q03u%n0(q0F=|e2Fym15@myVf5{RJkRHn6U4^A
z+y4xeN#P4dG2mlW^-AYaHpbK0`D$CMT=*AmVst<m@3Lq0@qJkR@k(ywd#=eTc^L{u
z!I5}<l355~&#NyUeK1)P5sWKi1;kPLM$w(Wqy=(v_W>8o2@x!KKy2E|(%-@YRyY%~
zB7gRZSq~AD(Z$7Caj2J7?Tz%iq8E*WE%CuU2`gM~H#e!dujKp3y8p$lN*vDT5dsN`
z3xdu2J#B*R3LR-{b6o~3FL2>b-z_}l-TS&;pB?>ar5LDf=?#ruxUue8F5rvzXB{;)
zL;#q#?~o;Y^z#!c#w$q+{45;2#+z6l1V6z;7b5CQTeYSRn=cIXS%p5==^+BWgYqMT
zgWQJmv*IZErhbLgqvOZ`%%eW0g*uGb=g=;XMzEkjVk+jKV$tVBpp#ps(p5_LkutwB
z$0O3#Wc{Bukn47&lED-%ty-a3$D*enb3NJfOi$ex_ak61eV0tA?FEZp&s?|Ev!vM6
zs!8$)-V(pofg@dOOoA$T?zz;GUzRI0dvcch^Fgkcd8asA_T8q(8*kD4ifQ`g8uLW6
zVevQA-o!n4Gp1uP<jWNPRl|QWy>1{IBwD$7q1TJw&qOkXAvw{Z`y3yuYny6{hzqvJ
zv2+t+A6Ii_yI6?JFb}YoL=US-o(Z&eaV8qx`AN$S>vnX^Tx?+!62Orl3OD}H&HBf8
zS3bu=a9FJ$&Hg<}_8SNF<+7}j-0Rcr9PF1L{N{W&kI#XX)kVh>wb+;4iXWXE*F6mH
z_l;j`0KsUM+F0=`Z+HfyEcV27YM(|MNb-B8$GvPQ=$hZcatmpeb?76;3_uY;G0-na
zrAgBrxA3)=!nBOOkM>;ynIFvO#*yeTHdR*G0v0&gE@Cm*7}-E!<jfMO5)H@(CnZAh
zhhVvaJk$vQWK9B@i~v*~;TNDm$IDk4V0a5pj0ov8i1ai?Y;9x>&V4KS_yd-L{huyV
z`wPsM6*gJ0Tt5MMmVq(rVHOm>0jLRKtTYWy7#K$;rQl3T|3WUGlL%zG)8puHqcdK*
z^<~AUeyTXwirVM>wc0f@&D)ptxQ#l{Zxnt}TKZv0ROjI6u)|GX&d=*c#j`l_{H+%l
z*!)isswk6zg}&o}m%euHcweLaocIhFuYxHeH!hBuQ-3D2;IcziHl9q9ak-pvnRxO)
zpCS1$t|5DcJ^i%%N5Q4Kz&!hv!9JJnTVyeyaE^zWim%-dCF~4@xo@nrRTG~0?*w_K
zQ5pnROwNIm&Tg?tGc&UWSM0ws)<o3J{k>>_{z(P_RXq7nDAr%aYDdKruj9Xx8J4H~
z|Dt0R0aT`piLx371{LZ|>6rmw4p3lV;M@1R%r5^#JzWDXM1XolAd7(K3Bndc&P+NY
zr&kqP%c7^E0{WIFe~e$()^hUk@x}ehwh=3C8-K#U^k2^3iCyPcoPVr0lA04m4yb<E
zJlK($9uz+O@amNrkA9u+TeRGF(DhqY&2^JW>*=|H{(g{jtD6;-m<Y0OQae#3*M3@~
zzTWkHG3WQnR0d_JH(1fmyba3}#*ws0_%b>=dKpAhrt#Rg9nQI4A1$V(rGc4Cu)shq
zCbNTvN4ka{yUoDBcnIyY1$Nk58ksnnTQD$-o{rA?*>-nUG>=`s^YN0<W{V6u>_qhQ
zoR$ea@(pmI9fz}GLc7b7+@KjCTQK&};I}xUD|&KW0Z)(pim=9e|M!=QC5-S51slG^
zHVQ6jlxj*(0zgc`36)Ei-TZbcA2EM4Vz1n&+FECj3iahUK*1ud{f*@fIcMu633_g5
z<hDnwbV6)w4cP1YdhSDM==LqxZ7};Zo<`t9H(Jy>`B=q|&qLQZ$$||szhCk$$via0
z)A}blM5Vp;DtPXWB#|uuO^m}#wLc{i7<nJx2PV!bE64CkaH$&BFncYcQr)52&5V!2
z@;nnk?cFpN4|G=p7$lz2sAG4=3gm#%BBg9|+blHDPo9YYP#!{Z?yZ_&a_YqQ5Jyj7
zCtYx)-#``NcPUqqUb}RiX*hzrk%>Z{^HEJeTjXn%VT5fCs@NX#N)bVEHYK`?(;KO|
z@}H`-jp%-b0lE+zix@ZD(x^&8K5+vC90BP!dvEY$C^2DQ6Xlrbz2>3H`<P0Ny|D_Y
z`UmhVy+vX7zU<#b?Y0#rL>{9*C~C!~M*0fo<nE3YfG^bRb~Bk?F@qsi`foyRH;Drv
z21aiL@vcEj;6vcUVftS{A%zGGp?8V$w91X06M&hP-(zCja!23D1W?@)gJ0FWYiGvW
zUP^3=Aw{bK$%Bzap!E9q8Vwc?IYFP~V{JS2UvIZwo7i~Re&RMwPSSfqslU{D_mAM+
z@g%L-wA!BT_R)UIXNw3^QbO1HYqZOog2j8rt-co#{yutt`C3Cj`Rg5gszIG+TFHSj
z^Upp*qz1emM<6C6BO~SS$Nh9o(!e<0w8yvFcCFCtgQi(eWho|;!kmE3)EdXU+i)5@
zsFY29>0y!4?eIQLu`8tBq4{l}_tQM;w46fjZ7-FCuiq<!7(y<yEAaaFg@c84>+sGj
z8l7v{a!@e6KSz!rT3fXg_+|kI;F0P!dajki|CygsGEh#dUs5lSjh`ydZZQ=HSqQiU
z$#j)d2&{y4`INqowPEv9@)>#3i^#x!GJQgciTFijzyW7h0FeV{w^AumdK@0f_|!c`
z?$%75g_4X+ABg>Y-Ycu}^zv%`_N}0(Xn^=cip#c+&4P6yj;x`;csFT2QD;_?=W8)~
zYUd~bppi9D)fG!|TRCq<4(M<-Zj8)$Z+9=J&Y^4k{w>#JIy{q+nVD9BuG6#`<<{l$
z5FwL(?w~&$K9^#peN@_yKJW0>j&-K`5n)0-Ri=pHrPpp#s)`=U3;RA6*^cMD@Y#}Y
zV54k{aVn`srZQ`DXM;0w*_pmg6`$rr{oNX))6>({nP_F4=IX7+i<Fug8<V7ISXo)S
zasAO=8~POg$<l495(*6lXPV(tfiG2Sgq@TU?l6Wh9H`|NOV;E1j*X2CXN!VaTRo23
zBiS9Em!;A))_a7;K5nKPON6_7hXYg7M%!~2U3bmZJh&LYe+5@W-M)|KJ<&%$h#SoK
z$k440mucX*T_}&lm$<mqkd8yGsl<;LPgrCAIA<3i(9&B_LcUtEJq+m_a;8^%{9&*$
zHqumu02QFfNbqa-Im=B6kQ7X=(n{$!yS+=RO%zoU!BcBwFz+knw==FK=CwczUm%I+
zI6rUL{{)C_Y!3j&Te%g(zF7hATuX3(x#H)DNWtlDVIa4#thgA&QoI|<63)xZ`%99}
z+6Ku=J`XpiU_6K)2y%rJ=Wa(q#YUd24TGQ(AXs2xrd`l)+cV47Gzt5a!2qhYOlk*q
zi*}NTmf9*u+*WSYw(=|a@so4t$#i)5=tl=49PZtzcQ50PUbh%O1a}Y=T%2Tcu(?b6
z3oR9IFs~gSU0tLLv$;1#kAwtybM4B%?o*FKGi+vWwsaSpSVb{FDH}MT8$wmwUG3n`
zor(JeHv6{;ZZ>z<8dBviC6jx&^opb+-h_am$7Z70KvLUjH%V376|p#$qvPM|8$5*G
z#4bX1Ij31^9J2&~CJTzURZE9k*P_l`L>65NnJ3{1PYzPU=d1TJAUr&pT$tBx?$`Ol
zSIIB+h@*uf$_=)@LD{6#)Ix}5`)}TlY#!*BTm}8I=i2?PHg3NEei-dKKK)BhVwy@L
z=dTfUx6t9uU**Wx@o$<^P3rQTG*f#ys68blezeDYW<(APi;cwvDBq$0%3Gx5sqFNo
z{Rte{*nQY#3Y)d=+iC1pyrV>c)Dtg7nkk;f22bprkWz7YU7b@|6%Nr+{?0)dzyy-D
z&xJy9i1Dr%|3qjRG}?c`-BLf<Bc4zZ2t#D#<iHHGi_6Q&WtyIDH!06<F_In`amDSx
z2Z*t%R?*|G8EoJ}^ipXC-dcHNqkZ+895g!kzH*Eyhvru3H;(bC%z$57EriLx_@AD<
z25(c{{5elZ*1RcSjZpdyl3m^gXHaO66ZcEnX|eKT4z~yxQ0HLe@Rl-LT;4z8X<oP@
zC3JQAyX6uP%Hb><bmq&~oyUt?8ikS(%z2Io-@c_*v9`80G$bE64@5wR0d+tSrq_G!
z?dW(Kj7s2neWajrt%MONNRD(^;*ST2ssH?5!H~Co%yM8AFbfegG&Gcz4L?$Ha5x?v
z9c{E9peF&nY1Z%v(egaU$V`U<ZR%|K2*#7;gpATwPzl$W#}ro8b8HtI;Z0Sw*-7B0
zuV8M%T7H|5Ou$lMP;dY$@`=@T^I^m_y=tMw>a>t%8{QGSk)uva^34oqm%exWw5@J>
zOzw#qAI9+(H9Vm7P2EnX3y#mxEp`HsP$H+NFLLO3)NCzp9Rq{m25P~$GjQz9^~Sz@
zKF@yMaj5k%pO*2{Y&~Ym6gOufT}OIq=kgR}UC3(1Xny=;&4;#I8u@|&S3Ga`Tp4~v
z5dyqL@>xago<_i^Cuj~*L1Vw4r#`&!C!Ok+f9<a`yZ=-!q$H;vxlIf=7Y=kP(UsP+
zoH7BTsYn2fqlCK+rHs?kcaPxU;IObTkSP1G5w8T6b)wJqmcaTIL-l5BB-`QReqZyt
z|E|4pNU*R1yC86Kb%g*N5&~ef75sl5WtD>El^$LM|H#regpIjS$GUX#t|U!7>CG&$
zqJRlZF$@>0yoQ2VRRYl#Zj#O^^#GHsGYJoE@v%ynd3&m?>rh-ZA=Q`Dp=P6j?{QFG
zuw*rJ$+!d6rne%|*O*cv9{stL0@hzyGc--*Hht?QL~YLDacABd=+e~-NGL%c9v*^%
z;0}WhVqd-k8Kug2k}B%9w&m(fk)J=ae-@o@ck8Zm+a?M{-z|N-ugo+$A~8|Im$9qm
zLaCLp>59KZfGf6)k?}A2{ybVO5F}d=*Jqlj(I8>dS5W1WBvSw^pcD?vGpQgBJak{D
z{83^0pmC~Kx%&g8sizL=YN#QKX(ze+c&PJi)xJrpYiz_oL3!<VpzY*z2HHvF0Ohht
z(jIt3#QC{7PWe1Ru5L0+faMs$9QlG9cNW4O0RhvLPY*gYR=5D92AHgES44#nlN-&u
zun6cXE=|qAOG*(+M~}TTwlv}{0ZJM{9wK0Ba5m$+6@+0;?Za{n`saztOZ03f`)MZS
zU)l3D{e0fxsc<i;Urtvol45g+i=Og0Pcf}&1(&QZUq|!-M(nwi#%I<YGnV{tt&I@=
zH{#{ILIS)9c&B|FWx}3sxqn?wR^qdytkA&|^^rqNprg3O&CNHV6uviG=?<(0EgP$=
zR4=|D2Yil<T>R!-6dgSRg}|cuA{wt=wMv$xV#`}a`22w{_M<(`2YL$pUc7@BNbf67
zFZy{qvCzMeLA3lrTb132{`NM(wwQ6zPm0pFN^uy2fGaPDoBdI9&B4Qbtk2CYs-~3>
zR@RgN6<}Z}^V{G%^~Nri#bq=9bna43<7mX!dcIvJuHkv{9y{m7xUVpn<qM8sF!)@d
zK($1@6bglckwjAy6Fby9NNz&7i()Vuzat3-vH#kH-Ia!C&7e<zjX=w^D=u8Fs8=oH
zkBDS~3jOca--?WE^&1yH^zZ%d=1_QBOdw*i^)1M55kXQe*{9w8vJpDtGdsLGFf}q!
zY4F|YbnmxQ$4s;B2y&Tdwi#U)a_p*{Tj$iyXQ`5rXX~juJ71gY#6BPT?;Vrsu1T-b
zMQyrtEj)B)`Xx>FKI_!I|3s$<fxeBtoiD5$fkMrUCbw~JpYC*=c@HD9skPa=6mZtu
zf|ax{dapPoDn8T5H0Tc19)O#CtxA0vu!xuM6PPaey{%2F%Fyn^hY#*#ChpVz$hZD}
zNiS4tle-Zuf0|!ZQ+RP4zy18-4b5X8;pG4`wGZ84pR@4<_Dew$N!-sJE)mQ5KA+yO
zY2Kh;1=XVkzON#gcI?ht>zt@1NpQL1XXDzn{d_^(Oh2DFh8A(akAMg3$0X1(K_)$)
zM<z7w^NA0>oKOCocjhhoX+f-Syzc<2LKza-EOu|`)w<<jh+D|Wk6_dWze<o~Mfn+@
zS(ET>vr_Ro@=-}LwIJp~mY=T`;-ZAJXPUCxjtQmizACN6vn|M+xw^XQUY%<K7MmSk
z^6*?9Ew%!qH6MCnVq!Ww#nd{GG&MBLPTVN~8m6O;JT<>>0A)IY1=L>EzaaqosOqc9
z@Gp48CZ#0LsBbcFQi+8&BMon|(Urvlv+Mt`AraCQe^!cItl{Ti;pqMt7tO0+5hgZu
z7c5^W4ueG<tO`XVMv%z`S<nP*hVq47npHF0V#Mess;l6FDq+#1q+jiD-&K)CN8v2C
zbDEe2iun|xV0fh6d?Sd5hCsnd0Zx8;g|v;WEjs>4_F#W%gat;VNkdcR#4J%G?%gQ6
zKcu2|L3yS3m_~bSMeNEY*Jx1tL}PCa`zenSo?e>T2rm_azJ5Pf9tJ7iPIQEY++4!K
za|Kf|1ooH!YA6ZXTjfg|T%wQcHQyZ9?lz~R!*m1I`44xE!1FGcL*38-4}kEdjyg0!
zkh*%vh~MdfKwW%~I<yZ?04h1}$IEHl?nqvYsxq#OLRX<v7SNE_elCGPuO5BCFZV=K
zbhz%n09<y*%)l%pUS3`}aU>CBN`AmynwOTjpSQw*?A&*~=u5h>+pjgWZ75Ir*1P(p
zFt_D)R93@<xmtyt$vV*!y+$WDq;?`K;n@0)o`3QPy23bVj|>e?syxDrhqPwRUm@v?
zs{1KAhVch_&b$s2tNmXE3oy`}-&ohZ|JtL<CWQJ16aK1RGZajL*3Aa{hcR*v(j7KE
zM3|WRACj;0NWqXT9P~ilk9%2f1B>ea_yi_#HHZEAuAr;U7L?`kj_3py$@Z|WP!@`Z
zppJH<QjyIs@j7v4Tvsn10hrl9YQPAf?2aOvpDMr_{ZY3O>KL~;QRmmCaB@J=;H-kV
zjk+K%sDm_uG5Tf;DqNwkst3iYm3F2$#Ls!o6aA;qL=*mdc4cKYAd*EY&q{`xII^(5
zexj=@x56gyucP}4)u9da#fQCp@8Dpht*x!6H-GRJgf4;;7bFqasr?g{tf|1jAX7#V
zAMx&8Pg2p}FH%i}d_?*C7nEEMrO%H6JjNpi^-Z)Y`+X)#8YndlhNgXGBbi>Dw5Fz}
z-ZbpL>ppjMJiqKMNQH&UZnnvqg{e~$;5J6rYhcx)jX0aR2ESL`Gv1s!c>6!K9P2H-
zoVc`B)vyf8j|kYF^4LMrOtHxm3wHYf|I|of!!!?skrQj7`*+a-0a&YeJb!(YRIoQM
zD1%r)b6Z+gmMCjhrv@@=oIZZ+oQ6_^|1U;g1*4n3RR7<F9h&(T@R{&-p9=w4aDS%Y
z#Sbxh9OsUT9y!OJWUzvygW?6}P#4CLbn?r~2mAX=H+QvlbU+;mxm=kh4J}t~zU2xj
zSF_tO<7z@wM8x-eYshA*d=|8WpjiYd?I6n)9bg#{DgUmqX{Tw|RsM=ii6rSETapGR
z7F2FFmi?YHQ&Nf_>k2HMBYu2@Tu*;M`x^zY;m_sAAH}6@sj7-9#lnXcwp3uC-C_K%
znCL{Bdlo_1TOuMNwvLCh*5mejuu9C)a>w%*ws!4$%RkIj-*E^C5MPkWq`i87-qu*^
z{;ON?1%ht7fHlrx@H4ot(r@>^1+Acw_v!COyLpiO^Xc|%^WwtAAjn+1hI!sN7u}24
zlQIJ)h+M5coRx)PZ)d+E{ngJ}Tl*^mB{s|w`MIeATuPiUaQ%e?K-`g4_g3FE0e+4&
z{B2IEpal#tT7pazJb)KQiHR5kg9l`ytBL|6jg=e{#i>XE3@j}AV0<K4iOkUVb~6l@
zUX~^f<lBA+&pp6sg&tpSB)_q>zlr}>Xf3=kv;@+h>r1PKobZaBM{IV|$gg1Iy6TjJ
z2PkJX{mpFesh1jARf>=rs3N1@SqzPX^pa;_fW_fpXr~b}%Bw!ZK;il|*+yN~JU0c9
ziwg)tz=4m5NxsnL#V4sUSN2rZ@$~v9J9v=BL_z|SuvuR0+nJ1>x)2{TO4YP#w<&61
zBozCKn@^W#nKKDa^v|7PK;05%4{GS{ESP)Q)YX}f7KW#m5G{0g_op(6B^6A>!7|E2
zF;@}>PEJnm|9;lMsPx=ht>c}E6tIq3(jTCejujDlIe^<g0ZMFI;%-C<bcY!{HlRi#
zXfYHpwqafnjpfO5Fk4rYpTF@4N_&@+T40@-#f62j@o_Wshz_FvH^hm8r`IjJH$?Hg
z+sn-v_zfK6)e9PlB#q0T=k%*h?$L`&IO7#nq^`ysxbhnDSQg@R5`3TE;n%4-TiEs)
zwb15qcJ#*mYS>Jzp%oP*GumH3sju@{SXjtcWt52nfrIHHJ}sc>eoGA=VmY#qOh-@m
z-b7wajQMN|u)MWxzdmETM4dIW<?>AX=(a;;SqA~-O*nCeQhYdZ!c3+~h%@R=S?2-_
zgN@;xf|L>bo%I*$bfsLP^m+#oUotb!RMnEf7T3_iNu8#nVs$2F=CY{vB|C$9DgG$j
zu(wuLR-m%6%^$Vie7-$m)aI!{gTwOyO&P1h&F(5e(&lRc`ZXN2s1X9dg=yz{b-wU_
z(K^)hw8*F?<ni(G1>FvIz|tlzF5G|XEuKGsZzY;S)ECqj9NKR~C_i^=nNU&Z>hf|J
zul`s$SQU?d+E}oYWV~wJcF+LCWHrsg+bUWsb^vtd{!F?djHF2943}En*443~uV1?|
z7wHj3_|^R0jv2foi0C-E{+dAk#I*%q#Sqg&lISh@u(+7zTel5=e04e-6XQUaDMO#y
zAKL}W7zF5;pI__e%9*&PF6Mi5F$zC`vVvaR4cIK$L_F98Yf{st?>#-Z-v^aOe(xK0
z;QLuW^FY!ouk}d2zgbWLlxu5i!&$;M>^Iyy?sH=6!aN^p*?@9wyqhr>zr%pmx_Y9&
z2doSB`XM~Z5EF)QS*5mHxxuCF?U92qh2v{Y{A5+dhlfuk&1tT60bYw_34tM!Uj!pO
zd*R2*=bwbZroiNfoqgX2SU~gp7%l+xLx&Nql+GEED)HsFSEnxe#N+b)rWNPTpCT^M
zfS5kh%$6Hr`{R*6hAhY!7)O8ddcbkyo@G>T8G8lHO(2%y_3cj=NqRTD{vpZ64vG+1
zREWT5;p95!f;n8A)}ed?C580GDc5&MJeVWrpj|@7#GJO|M*F$bVGK1%0aa;mH8V0Y
zdQ<=*!xs4#X!VX6cpEMvy%YeQtLt30AuoIH<4#4t4At<Q<vxNST)(ku%;28!V@NA%
z3JI6pBBQi-!52rFi1p)+o{VfO0tVO)s$s;jGqkmy1(j^0-dmN;++6($w@uaY-SYHt
zT9`e+I<Lh^vtwDwMA9f!j0la?lEBlyhURn;UcR4OP?RX>%5}yux8iysUWo>$ps;Xj
zbMsV4)N+&(tf1z*(&;ZW0&@M0nm^`(l{xTSpEpLqv+rmYu{3zl<{6w1k0aW$F;T)D
z1R)w{XR4~IE`Fel85$DO=&C0&Oa2EC^D<MPF956N@Ku?WKaX_p$^I^SzW$wl{0jL1
zJ16q?a5bAvlXLN1Iq}xEH*2fyc8O6{Mui?H5%e2;Cx8zJ0K_@t{s(|9N6h=279buS
z5OcNbt;R_41`rtd0E;{^BVhlIoeonh7s8f@_=Q`nC~yL`lPCvcXZ~(Lg)0OG?CDOK
zOp&i(qE7q!;RV4KbaYf$V3gr8q~-09CE?6Y0qj`T4@o;e>9~vCjXYtn24=RRNc8+{
zM^x9BhqP<M4)}q%<X5cD{zz)r)_~?vcx*rd0)u*JgKGh{#1M$nyEtrGwoZ1{y7S1g
z&}l3#-f5UNBoT1h@OwI^cvNT{Ie5K0Vts8;z||WO{DHJ<`ID4GPw>3+G^FWS@i2ty
za+%+s6Pr6t1XBYz0tK6(QG#}3Z@U#SFMm10-#}f*t1(52UK6{)eB6}8wxf~$^ZK`w
z?v>&>6-dB?=~t!!oGO@;_%MJHi$16cA&zEyC|yfi8&t?aI(fH}$Sqjz)#t2_9!?yM
zh|~1x;TEAOD?*Sw<p{xCduAMtA)2`f3@Qg?-ioW&!2%8r4!~#><ODo{3x$K*Uspux
zSP<QnwapkVEBCG4ambH(pbRO%m`F44&knUwxhb$><h%L4#MzQ>J3aH+42(qN=*X^M
zZU1gM94a=8ziAkL>$6?m<*bzXxTFXZk9e{CiOOJ*DT|D!w|(5jIDA~u+hdQFL8nYP
z^vvXC7Je%l0v+37^iUBBLx@?3>qJnLCrL3zTDaUj#u0<&Ko6W3QNp+I5Qj!T3Lay3
z%i}&BzIb0@M+T;Pzn#wQqa~R~0pB8GF&M0tkLxWI&&@xR-u!Iv1{hiz9hQS9?t?kL
zmNcInE@e)U<ypLgCwsj0Vwbh}O-jH1Rpc(~l;2o~_gb;?Xry)a6U9$KKzELhA^mP#
zB9>#GuVT5e&mmsOwkC{W7))V?e4_`@UEK7vh^Z#LZ*Omrk&)++XF))ii=$&ML-^O?
znHlX8bz*F66D+?*pTh`?!(lEAk}-|@YXiZK1->6yOmTCj7I>!dQvvk*=t#<cDC1$&
zJf3q+oRJb`Y2*8t%B+K@;^d5WS>k0O&G_<}sp?-bl5Qi9Ir8$<yGz%a^v8qC)Ll7K
z8%hg7Mi9&C-C42qpjjx3g`FK49-a%Bd=8FH@Pvp1m#bMO5QU0?(b&*nmLm1Z9DMzN
z_7eIa&W;sbEvzLWY(i4f+N@uhJKhMm2UXE`Kek=-h@)|}c*ZwNgcI*Qv`wxuBpz#R
zW#!x)r2u>v+rI6bAu2z}VfG$@(`&}{OLO;+#nuuaCN9$xu{bKzYYEc)HAK{;`ttK{
z0-c+!2_qmT;bOl~o)%4eM`WwQXrRU0i-`nK%zAQFYg83-r{b|(<(nN`Cb)uhRuy5A
zX~FPVE(wIzAec2KhaXEXsG^)fRu(cZ1Xo=4j_iP5FpLsb-S;Q{V==*UP&caI4`|2_
z8svI-HPZ9@VP?~nYV15<B}(~qfTUe$z0#v~GzLT*GPezJ8G#eEch8z8<0cBRTFN`D
zd(1yyHu~;;DZn6Y`@Ne0<voPb_y$hq;0)<ArnG)m%fpw(N^XhbTd?F2SW+MqTywWT
zPaios`TH8ME*MBa1GlbsH#ca6?42vxO&{+UzfKGy6>@jC@4!qvldk@MA^EI*xJLL)
zAA7Z5Qd!B$!cwl+WY3fcdNSeR;4Z-GmW71~5r#w5GpF({u*mB8e1`1rs*8}#ivp*g
z^#0^E!z$~$J1n+lCnsy3kZ#X)Z4O}aX=rG|LMs-wDlnIjP<9J_B2-B{u5Py9D+Xt@
zcwJ2dlL|_sG{}0IUr5`GguN8J|DF9&w#CE5v#5*l(^#hPy^C!MF<0T2Y#!uo;D~_;
z_}uD20%RSoZBqvuI=}cL13;VS1%MOV9w(sLi5O$CebIsa!9W=U7;!xvhi)xc{d|w;
z?)FXZfdE)wX<lS@Ici8ahV0oVZO#aMDq(HSjl`Whc`dsbU}yrDM!g&TiU9xQU?TZ}
zq@zbwG_xrvd=6vNbklm|>9N&~TBcTwphK{!E>U)KF+)hyZ#k)Gxy9w076h_o3(w-2
z0PMZ+I0O|sZPw#^DIe{SfVb@(zEc?rg6l;ry5HO<os|9xTHksSCcmU7qDt)4h{fgW
zR+#HtfeH+>Rwa!Lr>N*NSjKT_X{k)Bs<Ebq<9ihQ_x;YGhfYzsFATGC>-+RW!#gIT
zSMQg?uzEtI@8UW3lC|F6$<M`acNV{ta^nrB!}8lD?2x%X3Nb7{Avr*{B0~6W$XB@@
zA^h9F#Eg$&_rTH6d~6nLm*=BWqhJ9M;jAMX1HzNKlW&P&OyfI2_saVtdlYSllr6jJ
zFyl43mydLhNd#${*sp6}#ze2f=g@!oe<VA(<H14~IlRuDQ3ayz@6H{5zjw4#cm;rl
zK+C(nT<;oqtn&kQ=tGazz0602)%v;pjM~A8IsEm5AFG$uS7CTaCZbWF2)B;oepH-?
z`N?Da`{Zu=akGQRPIC0JQXLRz>^r46ar#O#93tiwZqEh})Hv1%x}t@TD3+E<vuXY;
zYx6RcNhH8u=w%+l+_@V39Rh)J5Y#yoFUO(-Si^=0>>jFY+7oWQi~obYw~neZ`r1V|
zjS`9=AT833bhiT1-6`GDjRGPq(jeX4-6h@K(%l^!&cfe!?)mN=cZ_q#xPRP#?mHa1
zg&k|Z?^^4f^Ld^*p9&Fqp|TQhXrp&fI=ACV|6udp%Ffc1n1$&4SDS^}h=hdvq=9Nc
zWBmsy^KG_T+M=vB$B79&`9xHyBd`uNZK>?Jc$x-If24Y|b2#A~+zGr<V1RNXLYx)2
z_A(p(0WCr4-@b)`fc^}dpud6H7#YxHteN>~!giuSp+UH|IV4JVlSMR+;*7h0Hwjj>
z9+kb;F9fwc7Ekxlm9~XjB%4ei4h8UQjD8JiEJZ>T5k~7rH5DvWPEqu~Q^r>i$J+?;
zg7j&08OxT_i{JZv#lk}1T*N(uhkV3#4E`l#FkOr;oQOivJP{mZO69FY*`_NlC=HT+
zCqFLdLoERDHZ6+2^gD5m5$t9u%c(xE<|iIg_D=h+0Gc;wDv8<M{PJMGVfLmnC|j9T
z=;bB4lg;B+sP!UTWjGRR(BQhdFR2n9)-HAOU+mK%=bxjt)ShZb56ebG+>V#35ZBt2
zl-_%BO1*wIhj_JJR0r;#SaRA`U*(7C;m7bMb_C6J>+}#(;p;WvU}N`0_!>IlemA&u
zN*?YpARM7<7cWZDDR%gUX)|QAS5W_v(th1?<*O^ZpU9U{)0^Y&A3S%cHm`Q)e2_^j
zEFa|^D>Ep4q(9o+J=Nb2G~$VKS6)F~28@i1VQUHJxPqb`D2JI4-}Ucr_0e+fk|D`1
zyWt~|j8s&)?pKFEi~(?nRI`LN&OlMp$llbI@^2>;X-XN42S4bIs1@$w)UQ(X$GtCt
z9?IJSqy83XIP^y<Bn2HtaWf5|<qhrz68-5qhC617NNp>(?pawnCMkEa^4l2<#hhkr
zIcYGGJKN@tOH7=Hdx!79OD~YYM{Y4wQSZNb!P>SjSKy9iwb0gKHJMN|U3kmNm;)$b
zB+9#uBgV;OD1ORYLMYVqgWYbS{#OPsxVU{3h~5UTctd_luy#mef5~hOk0X(pP5oa`
z$+cKlcXl|q{F`un8JfJlkNw{Li>g)X*<zBD$|+$BrQ`ODfJ0+Sg{JsyQ%kw^W4=Cu
zOgWUW=xY>l-@vnNY%~ar7hgEV0mSDp8SyAB2ZAdtmQF6sJS*lw$$7hQk@T(vI#qUO
z|7`~u`vPO1VuBZ5=q3Ey*nW_%xtwpyCvO2itb|)wIZ)4-kw{C09gIeyt>ywzFUw6N
z7Syxw4m~0|`q|Ezi+h}*Az<g{P?}R!^zj^<WE!1;R={g7@~Sykexk8?x2ly0CR-<x
zl<0h{N->t7J8{=**Al}_%ylS<Z}*|#<nE>}=~EM5xrwNV&x6+S?Z&JKQennHbG?ho
zK#VGnz}?u7hx*nFlVOdDtG?eUXv9+>TS9er>ek;)L<y2<^M&byVMX-c`TIuR<I3E0
z>m_9SaCU?9T7%1FRx$MSV8lx2WKe*gH;!HnckQRiE&BEPW>#GA#*t$IrqtHtmN7og
zYrY3y@xkL{**^~Sk)K5Qelyx49c*awz7=^94|iF~F2;J~NWOD5q%M&}7hb}*$k;<$
zSX_v{KRS57uubDbiWo(w7BLcG9!J#?_4V|RDw21T#N`r`VfCfC#B;QfWB8(nFNCey
zh^!#O-}X|JU^-@iQ-&;3)%HR<mb`IQYpO&1A=GMcrjX)My^r4nCaFqjd>T-Hz(f_=
z>bK_RnxQh$ImEWJr8(5gw~L7lre^m0F0^Zs=iT3X;Nu4`Io%6_W~jd!ivNM5*tfTP
zC6pofRs=e#CfE5>Poliho=@&&%j5GM<MVJt4&LKLtxKkIaWUEt^MRjSr#f`;FpC;g
z^S!?pwOFE!4CWet`$|Z?jSPYC`F&3Vk7iy{VY_V&L&t<O21P=R&GrJePhZJ&i^|K-
ze{poAr=ltaH$D#$VMSBcg#3IOV&atQVzeiycCLhSleNMyws_cK-&}S{;N8b<`CsB>
zfXx5|6~Jc(WjcZX+x)yHX#^_|!V{93hV5oBlzp(bJRK;P2s|#pVd={K?~7R>FDw6-
zdpyr+Cumu@JqomK=6j@1z-%rdXkOzDU-u-x`)|^`cItn4GU&Yd-)c$CHnB)xMK`?%
zP}11D?FhswH&Hm0X_Orus}%Aqot^{y7&N`U#*=#*PgR;RI^=gDU*BF3nE_WA%*a~c
z8fVpqmCpxD8qfZ3lzITr^#=_WL$+K^uhXRbh{(g%Di>w%j548-B*?sZ76J)e5Zj82
z6;2hQ*zv~tq5_|vkf5KO>J1IE)pIt7G11ZL>grXzgtWA@2e_@Kp|IOZKhe#N>w`pp
zeq_~P3YRhO`2-X6`DXx3&mj3-YiqZk-7MWRv!X_aLk>pa_Dbhb*JL2!1B8VNaP`ZP
zN&1fZW_5cT7x<6^6<mxF=+g$P%+>RIE_?2qx+dt{PIn^^d?@+|R7k}|MSvtW^%s4E
zAb0u!rM890aL^m&XM;AS^Y+Bl#>Z_8d79|W66hX97oV-u@4sZ}>uidKuYPlov!4~(
z0i9D(AO@sVuk*ABhcO|%P<*M<Npbd$**6n1EAh-Cw$StJjH5wp;FY)v6`QtB_}evD
zM%=RdvnI_AFa0@zoo^H5n8XXB*c(Ragr+_(u*nLwV&1-pUz|GlN~Fj;94wj+EVKc#
zot>3sW&?Z7+v0v@ZDC>Yi_ByouFY;i1P=m$z1Z4DE17=M{}<}Ml_nxTjR0{n01<;&
zKQ_S*C7MB8tF(mfy|GuvGKWwEyhFZD2pI&z{bu_!1kYzm6A=<uXP@o#78HaQhkJW#
zY6w(p6s&$PQO|=K9n92<Aavk#5lWhBr6vkea%5(I5>1m<iH+S!$HSK8d<g+noMb+*
zm<I;xtKSf;f1>`3a}e;i-%^MiG_ez4!^4s=hQ+V))e*~tbf}hSHS;2xVqORz5DC2m
zD+m}1N=r*8v6u`2f*0Uv>^4hU3JSj>Bi~^M`vX0nyifkCI8X};VC=@0UwM|uD?WL!
z+0T8(H8nGc%U54>G!+f}QB{5(Es7vT?vrnKNHHd_44W~60HAAeWf6LZui2Q>w6be)
zxm>v4_0=!`w)q09XzfOq6Oj0nmzV2!Loe#=w}^OMej2HN*T=K@pV;-u<9?I7mZIv^
z<0Ht7MPbFMVyRwX31QJ;7a`o5dN}x0udWqM^$!5+-wU2qHT_MD+kqb}id8IQ!Pf<o
zW*@hCgA9WYkgXyj@aACWf*j#9<%)!&G@prm6KsEW1GN)It_$pu);_{1aWYA%n$~bn
zGAy6wazC<f6!IN1W}?4^jf2rPn;O9IMQuXzAvwgkjPaI`kPs4rxw8Y#-B*>8{LK9L
zf-+jhg<4Zel{|*BLeYKms;M(^WcIOHkRRbo2~jT{{|XjqXyXtQqq2>?kCL12>PGq$
zn+4mW6-BjISFo7bUc6moW+E#@^0l7YYiTMe2W8Qn;u_0{P$i%!D5iAHJGxOk;#6Pj
zH2oYtcSc<>zpt>e$V^fkvpN8mHza(io`#){MKg&aoN1<f(_Gj?X>LWs@QO|)J#Twv
zYJFA1tX8zl&6{SSBgAmbdjp%0JzG*9B^L(9M?oyf3iIjRI+e00NW3!0*w`40w!c;N
zEyX1|l4;QNAZw~bMH7{AyJj-V8bqD8ArapLmsUV>goK6~S@1*86_JpTp3JiM?=20n
zmUZSeXY%xF6<rddOtg9UC_0<$>76y1Tws}Y<2XvPY?8}v7A@Sj>NBy-TTK;6yQSjU
z-UynAbcDUw-Fvg2#Q5vG6nyDb(jN2U8lv6_jKygUR!GNE-My7-js0WJuz=Kpwd+|X
z=@q-cAF+x9R{_pCwQ)t=teHgbJD#ehs2qv-qy5*J-bF#_=YPV!IWan9(?!&Voz)k7
znM!fv+)olP&Xk?&@JUJ{jP1WTK7NS|4~YQ=0463^!`=@S6&2%)i;MSZk-h#~-15)W
zI2Gq**i|jw@{DkfCJtkdO^43j9rEd##SCJIK=@!te%yT{+>VWo22;4W;pw<rsIv!#
z0@W22dxwXIIlq*<6<`Yc_~A*ItEA%{9L${RzkIr#S|?CRtwqaImbVv>!XYCJTvq(4
zfrEdcUr(|lE}Z`m7I&g;<s6YZ!P8h-iz{ekCzQv!piRa^FgQT1Q_b|7embTH0~ccx
zJ?CY7y7-Vv_Mt?HMitL)$9acilfZqKRnK~fMqHA$Wq*D_5EUkv2H6LagU{xhn0WXo
z>BylMtdVi&x^-d!p(~#{5+pYuN<pM9Nb~Fw^^{FC=DHK3=M#O$tI6at*tBSNr85!A
zC>iBnf&x~5y(5D4y4}eEd*{x0PDO@yl1$F{4%jRBAAuc+z~enw(*)?<>s&r`C6oH{
zt($|2ukC%Yx18O%X0^ZAabH1YAq>!wFTGv8{k?}N=KH2jngkq^Z{7M<zo}HOR5#w<
z_DJXiXBXc~K8Aj-4Y!u}I?K6;{YF`=CE)n6XuC3gi$`XfAXa>BN|ujbzdaEcKy9mQ
zwN?(K)VrQd+}6P`r`&%Y`I+vZ)9AIE^*3<-6z?{}LsJI|9tTg$N}H8d$^_PaWW^f<
zM2Nu6Iwk}(ArTiBcL6G9?~4LmJ5Hbp{@va#9JxNe-fl=cI6Tpp)eLd6j4!|R543Fi
zM2FiNZ9GcA%=CpHigR~W*LZC2n$|1t1}pgT3c)?m8?-!bYik3X4R?|?ASm{6OdnH#
zjtnA50qb*Z*w6w0Jhy=KbAoGwo6#yqUnXf!I(bA1$zZM}hWdVcV`JpoawFF-u1XWa
zYa&_7eVH$*HHZ3#f)i-{B^eTF`-b`h!+#+BR8?`NqnDx){@Z^18?FfrQ^o(&-NS>1
zJzLu^_swYauF39Stgm|DRP)wiW4rWy`ii&~@X^#oW!%1Ki96`1sC1S`g-lz;Gnqzq
z_6Erwmdl&98hmVrCCgKGBtibP?NCpd>_W=R+gMN#tdF~f284{%w6yp<PK6~UC3ca!
z%rdmJ`N?=JPIf=%>rw+D*s@M{wZb<_KUEK}=z~Q%3ul(Zr>W7^2-g3)NG>0{(4Q^R
zP%;v&<KGYRF~>gEMsU^ixdy>y$_78GJB^F-L+dveHm#{kxL7NBHpRQy_uMXv&tlUE
zYcW~s=1<0T(0GjNW$aoNWw`>9O>Q&pUFhw1Tut)egiY#=e-rPpT>UjPF;Ugfa68+S
zPLjdFz<?3V8Rxs0P~=W3PD@+4zd2(u9{79Wh7_=gLqwO9m*WC?xt3~UM1{M(^>i_P
z5;<&i>K%HI?En>)mX`L8uzz%@-NgG3_T2pZV7LOfw!S{Szw+*8r-y4kJI^II(nL>u
z_N8|^re~tnBx9#BaK5E|CWiy0+g1xE9=T{gw~3K+D>le`#-j*}&Bq}3V=lQcUlD%>
z!9y|+J?Y{+_Hzo@Y36;_CwE|xCj^ryEL*`fvIMRalJtsQY1Ac3u2e#w=lz5<e~5l=
z7<2mAdFYYQCaKmjICucy30h6|g`Mdg2aTfY=H>_0mfK126(5fS1aLXH%FRz#?^Q|$
zvZELB2S*K=N1Zo9$`ZpDW`YmHOO{>Fc6tkEu#k8le=<tueQ;htKF4?+)Av<G%hsvY
z`j0|7p;gIA{BlKvh9bjJ#8~cUnnQUvNuFDHQg-EVB#xyGivk-pFnPX&KGZVrJm-j>
z*J>RC2bI0u-Ssawnl?=ra~37Dv$H^TX+eO#wUd*wRBM;fn?ZSo@?we+4*&d2vceR-
z6$qMPO1U7R4@d}-5M+awOtb9ztqoL=nFN<H_pQ8Kra<H>a^_&fY%(d*d`$mIY@;b|
zgzw@~-@9bYm5T()%xLIUB-<6xcXA3dEhSB9=$&3fz<8(#E-G<#76+|`9efvu%}rBT
z2smxvp?i)@E4kbe>vz%Nr<0gpJ+UCVEU8I2%1RA`SNc+=4urNq0L$~%9ncwI!{#Ll
z?_L8nI?v!?&#d08X&n}7t$2jlc~+#KtwnBZz4A0-Xmo4C6;m$yMqA0LcJ$R(hK&GT
zPovfTAi(1H(2xugQb5eSGaccE^*mFr5DBE-ndyMNvh%lsWD1JT&O6%?r)0031-a$f
z*~7mi`<50+oKVH$tDK6#7_Rh3WdHWm)KqWio-WWj4fCF%26T*?vVt2DXjBYrSKh0`
zTY9a)Y(E<5VWOxeytWsVMIV`%5Y2e>`gOL`5+d-BLpOH)t_a+gguoJb(+r?#X5H3l
zZ*#bqZ1D<%h|qx!AKWT+xbb(vL6VF1f)tvj3XJH;@=-C6p8ozYjan%R*gKpCI(9}z
zd>>9hm0!`QlRK*eA#WYo^bUo+RMJs%;MN1P0!v<~xq1`C^nOM{$LUG`?9BES9htFz
z&Odwn^t|H(1)b8|p}3WDptB$@a{F^MG&JwK`DJtv*nv6=zzVs$yQ2q0Mn^jWUf~%g
z#XvHjX2B$0zYV{FqOP0tAJ(jfiIf1ZPpe%phBX@;o$!HHxX+_%lWChqzht;==-yS)
zN0%gSFOVb5CGbD=eY;=tGMGl0HW*>eT6Mqq$YHfD|D$VXD3tajqr+dr2g!&}lTko5
ze2C%(K`gbiN}$h^@Aq($Vrm8Tl`ym?sW<@Xax1T?iI0wsj)|!hL;w{PEF>g)AhH84
zA&4+=*o?fiu`t9n__x@W`X^ul4?!01S}3vk?^rI61dJjmGQ3AHA>VMZP<beAISJNg
zBd@-BmB#%nwY$jXGl+OkXZ9)XL$#aZ6!Xpd4tc}gW~1@;_T1y5H=J0sEX<hAw#s%(
zE3H3f8cE3rclqj>B&#VIY#d>yD9Fhvvn5#0V5=#8O3L-mb+oGF>d2}2x#UR)`{aK#
z#%6UUUe9`Os1O{!!zLmsM_K{$QRfS9WnoF-FZrx2vh_yqWOh|gGzu#hBN~4X9Q$h`
zI*`8%hu30I%@{SUngg|1nVDn^vF>|QMSyYzRR%z$5%PxR&pChlLa*$`V#2RwrD1!u
zJ1vN2&HI^+codG|?;!^m?~_B)7>|A=lwSKL7KeOb_x=?hhj3#xI@U#LA<TGB78;dW
z*w=Z`G<;ilpQ<mJcgmAYayV<pe%|<o?J(~JmQG`FPP#{Wn%nM?K=S-1La}0T&gY{B
zwpbF6vzrqNX*!x^Y;x`U(ZP}O6ydEqp8^Cs?@|^IkdF*_EmWAi2<VtCGYkk6WQ<|p
z4K^{in#jxvTi~u49GAoGi8k&fV8*gN+)^PI;^kISRc)xPjhn7$fOuXlI%j2Nv9Yl|
zA+N&1!r4;s23C|K^EEb!bVqO`syjF^a8&ZXFZ_^4;Fa<)-fr7Z7|d3ta%(3<V=%sm
z%%P0K%~v*DOqb3Hqoc?8`0+f6Kq+&I@gsw>2%O(DxlCcdp8U~=2J<3U`cyd)RCtYq
zrsYS@I37zPHIXCByAqm3?XFm1vK1T?Ywk^@sOaZv#g(HNRjcRe(v;!9xyj1P<a}K!
zsp;wYJZ}L`alX<K0GcjBq~e%X;!Tp(8(qo*0s^|s{9<t@SdLfUMm6=0%sL!uL09)=
zF7`4D1+7hvRzIzsk|WZ80M2OvbbZcC*DJpTk&&83lnn<EtouJjN-xMkmYI)*!||sM
z`rdFtWKZN?cytT?87Gcrv8@_g(5fqY{PU|5I<mMpi2fKQnI%YK`{fI4>xwPigK@l$
z3k2LeW&RSty(y_-Dy1Dv=Sml7gkH{n_iriXLfE!<eM=63A7v~ghwMLiIv+0FfS9o5
z@xdMP@bCbnE5t0uU_UFXebs6J%T(LhyIRl*(=g87M;9tME~(U4$w$4zW5qz`B|2N#
zkef&HF;j)6vkhNyRVCm@p|Zxuq*pbc5`JRg2sdEAQqjl#GxT&67ZiLdQgL>6KD+U_
z<byyxf`9A}_I-lYzumP9)<y)n#{o+Ei|ItIH=8_dafHE*HK7^uxXffD(d^rCWDvvw
zXP9(&AClYPD)?3(nVkN?!O0y5W@hGU@5X?)FjNX6q&^ebg79b$^l7m96LJ<L7#D~m
z23crSjh#$C`vsp%z1f#nM6nGNqJ*QiIgZBk`-)vZhM4Fs387ktXXdo!{B4r#YMj|L
zVn01fi6&e07PcKeJNyHk%A8O8Csa6Qku$i%J{j!vQ5fdV+OcT%^brO@a0(IYE2m-q
zFhbuVe<J~CqA?ZN(Y;P)48yA`D;*pi7sG!Q7Z+z|Qvl=Wh(k1hwF<oqXE@*XC%HvP
z8Fsd_%PS~o0J*hKG+52XAgJ-+_in}e_g*B2kzXkx7x{bnL&hI+-s~{E^h0nVXfDX;
zHk9G_&9w(xvSD{vlQ-WJf-Cg$T@M7)CnoGqOc*hOM+9HMlA~<M2ZwrVBljde)xW#j
z%wx?@PlFc<Aw`UX+|Q`I`y0$jpdl<6qQFVO1EYIxs5uBFg9zLocZgs4g6~4|<KqvY
zl0)~6hM|Cj$cS7$1j?fa7&@mYPJG`Ye*5o3J8gw)j-Ne!a}wlLjBl@i-1gttUHnq5
z1fQk1I5;^~S64eZIH0Qef=a1^0$M9L$){m-A`3r*2%V!8soagr3UG0AFKr!b=P9|l
zxY*V$L>#^Z-zP*S2M)~V4|5o+5g82)iB0!2#P2TOfq7Yx5%@Ozc@*TOXp0<8bXZu}
zRY~{gXv84QhkB7I`B>qX@5g}gsECZSb4^kb$a{EzCI{%*mgnYnx3;c;6KOah4?86#
zFeZ%FD00d@#ByNoXtVlUZ#C-h2z?_oOw51^2Yn)afkg3ryyeTN_cX_%p3fbcKQO<G
zhm`J6+$~3h!7=a3Ip^=0?|FK3<9oqYX&j)5g?|2B(<;Pt{{VJ{ndYnEhu`=(mbrLd
zk9V@W+3SAi`w^GlNQjIbxWTZrm6a!fH!A2DKSL~(B;$O4ZI>q3v+)Ip+GiIR`9z=j
z><eb_+I{|RR9;iu|JYq55Dm4FS-{*+-2>Xoz3uH0Q&uoWihvFbWO$I$gF{G22#zTF
zphsyRD)z%pAHIZjwK!y^f~ZKPf5ld*hz332DPz9U<B2;;YewC47vz#c&tnwvylM73
zDo!JmLWm2xyEsnP^3=;~QqD0~)^5okF|UGDY8<>+*0oWrnw*>pue69MtEgxI@d3~m
zB3&aZYs2TJGVI={Jy*t<h~5uaa%;-0-)bS3iv=2_jA*%7wNV=hqAEEYm@32uS7k@J
z-n+h+@XT>wy#Ze=AQg{}i7D2sIRwTuK<*BTnt%x$aX~@B!NCDN+b&{;un9^WI|Krk
zopnVrKBhR1w#gnh?=$*>cHCI2!q7KBo;L9`i9UvR2YwvZ;j+qFOx6SiH##j{a5-Y0
zuZc-XL)Cg+R#(D+gb6ic(p)x)`(ibi@lSWRZi^T6shr~iMCsrs$=r^T1(WYl$7}q1
z{Y_Gj;tiC#@maSm5y#URecp^j8xImN_k;{!LcZ&}@al+}Z3v7B+~53Be)#&Kp{RgC
zhui%;k>XCJDBvAlPMwqJKw#CC7E>p>;{o3(kq=?w@^1L`($z3zrc9q3BKYir9yxni
zS!A~5;q<1;__*5&dXx%tZOY^(Tg+c8_4D@r7<vJwHF0wbf16Ev=pF|*4-X+BA((04
z{AZWe+<%gkeE$6TOgKOQ8~5xXn5!8z#X)HO11dSa@60PO(TQ{O6@%eKgQ_ITkY~$j
z-7My26<>;{S_h@nIBxB<YnN$)myDrL3qQeJblNe`1-0X&6I|5tRw>E+CDIk8&J+7H
z{;zP90_Is1o@LPBLOc;kgyaYAO8AqJ|8FrS%EEBs8qFo%yq>1PaJx}U_oWvy3{&S5
zs??X8%MUVEj2mVOn>_9aJKo!`vpAfvD&5mqi~>6ye@|;iS3FE~=pWrPzw;a;Lfqfq
zuhl9BcWpruNU6uo7apDlpyNsb%M>IUn=g{27<i`x6<XWl=bXyxG*D*0{s~<2sQ%e(
zJ+S0_bR$_|8HNk{edn1V*m2(GeE#?ty`h}v?XuUmarAJ1H{C*8@Lv4kA~FNXB0j8V
zdEjQl$#}>ntV)VYZ3Z1OaP{G8s3El(H5+EPUysIzfoa+IW~oQdJ-l&D!N}c)&>mAt
z42QcIZu+iv0pVgJdGml`BQE+8qv8t;B$p8fy4Sk&?g+RPee|tk(IX!(W{ZUjXAFXY
zP`M`~QlY^bd+ub=7;nH%nU)k_8=jW7ZhWDXxwN;n-QM3X%+KB3-*>RJJwA&KtKO*C
z7i=jk+y}TA*eAfTHI&rgaZ?UX!)yk<CRWYc$QE;bCvG3dhUcPpVRVBsC5vC^n3Xpe
zUPZYD#A4&X<<c=wMSpJyhVQZxR~8lXjAIbz{`E7zg|XU1w*JeSm)&kzX9u1=bo11#
zLBYP=iE%(?_}M23Z$31^iDr06LHUb7vvb*(B7cB!I4J682Jw~CdCB;W1Gl!8*2314
z&Gc3ZF@T*rR^oV(er{B8(><SQbj>%g9$CG&W~6NR#2~ZP{P?Uji&%r9j?<NE7OEIZ
zIA|Tbmd!0HtFATD$G#Aws!Pn(YcV<zt-I3_fqFGc-)Hks`Jiyz8NHWtnEN`3{mi3#
zCt>ZC*}`pJH>H#d%TWv(Uoc8s%#9+4O|pgn2gzn+3M!sL)DXa_ny`57G<8J0qip&M
zTEOFz+dOKt^ay^N7jSr?n?Sdl;&J-ysWUPe8CfH6%>@uZ2`7OJI6$9xiBq#LD`nA}
zCgvLox)7dfDfPQ{(dxhC*r<O&@)Cyo{QKH72+!;&NLC9bcOAHi!d0Di`ZOCJTVgin
z3D7_Gn>N(fqqgH{;6fNB5)TkoM+EIQGGnzMkew9lYIctX$3@~c`{EWmX6U$~J*n<}
z`Z1pgf6S2A>H5uc_agJIZ^$?;IIXNvNuF!Lcn+q7BHD>t1Dg6rM9(&jXXD{?Cr)wc
zS-Nv*9olT#&h~G2R(loSpyA1%PuNlLFRQHmjkq!}9!5(lI}hkf$26%h6iz|)G?yN{
z7|X~BH-qrMtiLI0I!dW4w)!x9;0n3epp;E!JaEiL@)bP!XhIspijxH0UZ$yGuu{zx
zXQOoUZ=(8ggi+0iK{*^NT%f^h^5G*-c}tVIT(tW+D7*f^@j&0XE}#<<x5>4yIx5!&
zX7aUkZvMzt0OmbKNcE_ITa1Eq5;q$sCnr6<bk4ZdY`H%awrRRf@L5577AZt7s3YTa
z%AZaXn?5qSM*-4ffU~)ggc?ELAK9Ogj=j6_f8c!EZ0pgJN!(c541&F7i`eIhy(X_!
zi9d~rlf2N%3e(lWM)Ctl;fIzAc;=}8AB7|AM@n3AdCETUcJWX)w!mJhfBqO*?%%QU
z<9E_4#cKb7IOCU_b^Oo%cAmgpEFTJY2z*OBUV-tkPc766PDoII#A0Plx1GhaLb;D^
z&`vR^f8%%y1^eoHprz(+i_TS{4=nA!h9+W4KDKzJLFA4%0$IfZJlBnNIyZfvZzi5m
z!u-B|e|Ls{Oge?rz;C!(5#0K~y}YJyKo9AfrY-I`2u>(~<eR^qZflsdf5E>QJ3m_U
zGklhB2<r_kYYeZ;<rH&P%a(o1NzlVVAol&mxx{hnWfr8u|7`WKsOzC(dDH&xynp|V
ze^%VJH1T&#ZcC7r<4@b*@=sBj&s;z<UPh8D!f6VTJ5DoN%Wy|w>n2uODk{(I*7}qy
zLCWMY#Kg#bKwT~?yJU7O4vf#qH&e9MUF3>NsX47?G;y7zW@>g8ql;c{Y2X=(iw!Co
z9&V>w9<IC}Yd{T#{?i_a`#rCu<Z-gZ>tf0MD4z8nemKvc7N6w)sKK`Jfz2nH<&T%g
z8u|$I<buae=r$`xkzgN!8{TXUr^5^Rsb0TkBA;C3(bv_EoCfpb&Z22waBcIQ^yC~f
z`?=JOP}x<9a`1}@2Ctm5a4||Ahyqf>JXFyO|0nkhOx!B#Sk6J3Pya@-Zi@~@B*5Nl
zmfQ-esxCl;{M0lcpu-h#4II`Brl;Gz_wBwH{jG@5#xc4Ck!1`403P~-*)bwFU3=wy
z#l`{6+&lCd7>9-mWG`BqA^au7J4@7NMDmBn8;%Kcx0b%ed8<2t<z?4A_eLx&Oze{v
zyDpVFtM{+-bM>0^zB9&aF`asyw=ujc?<V%bFJqtAQ6UyPGeN%4l)$R3FgoJ=J#jp_
z)PnTXX`t!(%d+@*dk5|psG5kaCe9f{Ebg<kw`m^6CJrEh-qIb@5E|gjM|5j&lXc~D
zDQQ$yG1H=aLr9A`#}fA*E9Cc1#-Q4mU2nqU!~*K3&cWDwUC5*LP7})emK;~OQa0Oi
zyOx16jK~0p(<CF$S%5a&$mpmYG~WPg2v&Hw`S}$85^aCurwoOT{0WR5*Q&%-970-2
z<j5bpqWV>0@l`Tk-@d|6BsodT_ZNqC#DK?uGLeVzRO6FAOZ~3FJSI;DaxkFm+}PMC
z!z>52B}a#cLu)4>0##9o5hP(+j$t0!80vdHw1qp(LCY<`ukOV#s=C=;fD<CGG)Yq{
z9PE2R#JR21Aq2@r;GOoW{iEOFqG`Qc<`C6j)j@{z6|%k5RyjZN%3hM%lffk`yj5u4
z^)~5?h^L83gRgICMG@iObJ@D3lp%J_%^wf%u%7#V`}P1r=IE#>-m?K<`uj0s)WO*q
zgw>P1y}h3?N^ks;QXgZ#O4DhXsSLpUgO6F+*haU#<#59&A>HEwjgA?IGMabucMtVE
zuEadII9xmj*NWeIw~1TnFdj}9&SR&Vu$s5S5BLjOwp-i0H{fhn-s&l=w^-yiC@t$A
z>1|4dva;IY2%1LqP*vSZLfT;APa&zwC=jIZWG<I;)W7p1ZxLG2N44Q?anxqMv<*{k
z8zYTBD2n+aeln3VsZGC~JF;e9eExGrqupXPM640(W52-lr`<bBh44Nr)|LVqd}deV
z+=ms!yGbUy@)W_=tFu^cPEL^0O(-oldT;omyYGe3v!EI_`y3_DG+Br5I(&)SJeQGh
zdws6!U7nje!H4v@+@BrK4e4X_W>&tW0;US_h-%(C`#Rhv!@3E1pDnjwvRcBmn`{-M
zdBq3rboi5><0B)-H7(Esz{-JQ+w;rI>YAD@TTY+}=?)`IWYTX3k%Tmni}n9Q;MHRE
zg~y`k76bLj)cJ`j_B!zuW`j;Gwr@7|>*aod@(ZiNm%-yn_^PWP15m0UFC?Le)~EIt
z+m^p{<=`c??lKmpJ8l-Z5V#Y+FoulL|0SZENy!1?ozl|M*4Ea4aLy2@E{|t10pjvE
z@Th8y$Awym9t+mnnx+0-PjC~Q!;$yPH{g=fuEo$6)0kt`OeC2*<|K5i)Yfu8UcO*N
zl0ngnMLLf#wtk-W{58D4<UWp@U*jo5zMFN{aQw-7!*qEI6)((>_AG^h%UbIZcIUk4
zOIYTK*MCo269-iO6waa+zf5>;JNvOXOb}_JNV~L@(LJ~GkyXxPh2>*JNi1ZI586+=
zA&CYWF6vS>mH1>PL+gctAGM+gw)+S?9-Xf;@>`f)At%3Frl#4iWhRF2woY8U9>(y4
z@N5F7J@<$_P+yR95`>-X_qw;4A`bn57AU^>boE;)$OGq)w{wa<<oR;KSCO*!D5rcI
zwV8gMMP?q3R%&DX)y9gJn{Vp|67FL%uh&HbS!qAMJ=KYMHLUXCKuWub;b3OR=pCWb
zH<!4TFLj_-TEQf!(I+D(x2szKYdtzP7L<DNlam__#4%@IVQk8H(Hu=h-DkTccg$_U
z&eTV@F$`<fy0U+^4F7rZ8P(JE<Ah%q@q&X9Yxzy&Kqp;~O>hhYzdEMd3Z+>l{0B{k
z(tXb<lMN&^Mak&p6L`Dfu!^*;!CX68&(z~pN50n^m}rxV-j62>?2NWaU--z~my7D)
zR}zQAIm`^?Z>p(wR>Q5o$3U^Tmys6axlztxz9p?xxSknbt^xRhlVB)}kVgvMt;}IX
zombH!gM!a-eX7nX`Fp!yG3%$zA8C4=uOPBE;p>Yni%IueiIY{_Nkfx^<aS%^PUklK
z(xg}83;Ey2ChfCpKbf!uok0k?ZsSoa7Lvxr9w@O?p%jD8WrwvX-UAnXhHTNqf!bn6
zUK(VV$bp*N@kLnE1olo?MjjgLJ7=G_?G?&C{wP1$BQ8$f9@B8?*y}74wiTP5&WD3F
zgn<{&*}^u0#8EKMe*cBUq%F{UNBk492w9GP0|zR1!$$(EWZJ@6I&;ZF@q)CSxjirv
z8e-wXyCmw}@^u%VX6B>XvgehynHhD%Z>aAJe&lD*;@=zf@g2a|AML*t;ZomhrsGx5
z`x+N6=+qp(Tbaw*LG7X(r}UY@hKdmd3n4|)nneSyl;-Xy+6}TZ!6)5pIY!Kk?w6%3
zDjL|)++%j+KLQ9q)(KJ^es1pD<CP9qS62vyR9vYS^cEm3?k+BIkNnM;dM&Q$mC0Xm
zUZm~Uc$!37h&AN|s8LLL-+5o|Q6svFa1BM`)T_@KR3f(8_N3n%PxuwTYX5p9=eP%m
zSIip2-?r9CTh1XlIBpB2#?HT+9Qr>a{iP<_g<EJ&+(Z0ZLI0H*{ikg5zIk4q*v9;y
zlh1q)-PZ_V=dSMJ+lPn7ECV>Y9`YnFOT!bv%DAzK@kbf%i+3~meyr8=d958%%o_Z3
z$>W@0+y=(^b|#k_FB_)km8@E19wwvyLM$RP58h41c-x)G`e*6rVoli-y8gmh!#-!Q
zOd`LaVrb&_t}o1KcZr1e<T?~EK2qj6YLPQ7v9f+$qQ-M1A!1~%pC&h-i&cW0az^Ik
zZ?E#%qn*b^XM=<7l__Gq)bEq19z1h~0Ga17Owy~5Tponl-F3&eGZ&~@%W|%p;W=2?
zNjt&KUo=EP>CV1DvO=v?Xc9aA2F}p_V{W^fz3v`DF!S5*uP>#Y*8YSR6c&EIf>zel
z5QEBPXXh(EdN`(87fQJilR9fHOPOd+59hfL!KZ&V1iu<pO|6sr^d`W5jb`fvC0C>X
zi37!`fSz&(Jq9Mt9i5#yQie^I;q(rcgs4h}!>jiRH^{$!y4_vU-VdqKVP;4~&7`xQ
zG@xQ+a0Cso*ZY{3pZ&?CJ7sqkc`jZ=#Y&B@fL@a9-?J|tf3dmQ7YgNA*8Gl(`yFMV
zqhqbOodSm_cw%3Q>-@L6h`yd`f|z}0YR8+I&l^F13_iB;H7>;y9!@V6T3DGSy&^EZ
z8``!?O%@8k4%50mPSu_6qZ&O~d{CsMsbg8vdehCHTAzvNHZ_eGJO33AQ5#UthkWMr
zDpO3gXz-_Uy*{It43lgG%H|j(J}<Xn`zCES4M<DEi{=H<;M`M1EN0)peeYxVi-ZWF
zIE8?JF8K<u1`_f6HlNOI$c`KblB?f~p#0rkb5LT456hjzz`>!KGv3wNIn#XNeRpXU
ziS}?P8G-i-CR2on3BaYeU*3p+rS|1hGKXPc-u_Iof!6%x8`Fre>YU!$<-84}$EC^U
z#lb-~N|it?4!R;NB*Rnw@B%H5&PcW8aoh4xdZo5%_|J!stTF~c<{hMtc*uDQ3>on6
zdcvXEYjfcBuD>vJIQ)PKd4RdTmepBhne|5@mc(>VjYFk`)1I?{S&M!64|I;o@?xN8
z6u~ylwbwHZ{5G8LQq9WhAdcBk%2~V?2LPJZ%gucH?SB6Y>VF{xGzsre{<l~^CZN~T
zTS5py<?jp##RLA~=mzj_!Z=_s|1(s0X311a2)uqYKrQt%wf_rqH(2cq?9lTE$a`tu
z@%=lpfABl5jOlX#q5pdwuQ2NIGYFCsoO=q65Gp=Eb$EyL4r>fuES6ezQa*;fLOmj5
z#`*`~M;Q1#^GO_OsB22LVN56R!A%0OokhKpwQxzBLhkquXd9TJkjKr<{h{8z6AIL&
z070U|dQOe>G!`NuKr6U#N^c)d<xdQnCmClp2)@MrYj<re%=jWl$bCaaRW(+n;Nldo
zGUOYsx`w7Ez%I6vP{ANO-}SWOz_@eWxwhG4LMeZ&07ks3y1KruZgf2*05L**Vqt*}
zJ9y_U1bnBHT%iUChG+};?99<ekq;&&TjJo8z}vio{3Ep-xCzN2FWxu^1770C$A9Nl
z_nZah8b}<JXkK?PdGIffkB=`c=@d+U0bGMqO6k+<z$h}F{d@gk0)z?G9&pM46a=DX
zP(if0$qqQO$J>&}g!e|0U@c3t68q2ard7$&LIg<=$le{~i7Cke-T@|>fb@;eQaj1~
zj(h=wKgnlgv@%rxXm<s+%qDz)^jyTN`%A4D-<b@3bYvl3yb+3Iz#utH?HnFX0WiM>
zdYSTY{?r(&IwQk(c<T``6+odeUu{K8O%0PeX+AhtwX1>RP_NQ2sflu{=_=q5gC4!v
z*7Y~JZAGYkwN52En^3cff&bRl<NT{(e@p>wc<A}0$=6?t{c9O7ATwBry;GJ6v7A`n
zQEwGF$Y128rB!^9%}0e2Qh#S{WWVL1ir~<S!ItKI3G?>HNBE~1sXId?nhXSloq?Eu
zU@-g>0%E=)AS2=9<s~2>P@<W%C}{%G%jYFYc@N`HQVPm#IoOWYffBnW8_?s;m?V)*
zSKHb0d%wUAU;i$9LgEzp@{{fM{qx)x;TxSq5(~;e{lTysEr)Y40Ums<hnK@AEb^<*
zERp;)2qOsNh>^O@m-$PRsvsB=U54mb<S{N`q;&fMQV>>TKzo-^=wFYVd$1=)tt2L=
znsB2srm52FewWSwGvNl^9c#?zzBCO?i<amPeV0n}t$u>eU{m_`L#nRIK)o?GaU`Zb
z-+Sz#;J3*tGFe%z8m;>S8jfS<nQ8~M8@YIUmD}^BzjdqUw#!*Bi)6*=Q}{I>!z2Y?
zcK#LlM_u9jidShsM?Vt7fQ2x!<4|ETtW#ku4Ip5Zf(=_vprrs^&49!%bFw?dQ{(D9
zTULN?Jg2%sa@tisXWY}ma?~K}WOT~De&~Hhf<3o(PVref_#-oIMwUO~m^{9N#b;o2
zqq^r<q`U2qv<$0~FtN)$yyH;i8C?S&TwJtejuk4??u~J2n<(oZ-PKR5#T8eDub+9l
zFLmnoTU}Ut%y#p!<6ZrNM45Rgc5;o9Di`vEbs{kEM9pOi-!~S?O~d;9ldw{}1_T04
zxf3~^<fk7pDxY_blJjXRoEVoAUM4BHb9beV7}z@&@p`Ij0aNF5BRlghGnKJx<D4`C
z;-)GpHfH|Y(iJ%a4|bp5wNjAy;DN(%_Sax0a`WFFmrWLoW)kyH8dGM{NiJczb2{E+
zXQwL}F273WfT4j%N0TRRlCvw9ODjDaJ&~q?DG*>|md$I+o*B^af92!a9U5{ZquuPN
zxWBR(yqdU9{hdMWN3=Tpp>>zS^uQXNpmKbb`)IbGm|0bhVrUYJ_0mLVa%}d}+1LcW
zEK1JUFGqX2Wc6Sf4Ib)E!W!&Jog@_x{NytWFLk`TDfd7PF3-(Px)lCzB#1BmZNO^y
zqD!EkS7l{X$BJJ-z~cs^cRaJ<2f*HfVE5sEOTeC!ph)GZPw!OjMgJMcuUAv+-ku#y
zD7jU;Yb}K{36-l!b1XJ*2Gk2#M;s0rZJ@l&UR}!%<)mdh!K$-;eqDh<;m(vrE|g|=
zL91(6P^Q|;;7830F8!0`2b;l7nXWfUGFK|6@y2MYs=r4b*Av-B*^+q54qGs>9}ha~
zAE(%~S*ZlBRKB#Yw!CQ=%^6cDxb6z9GP$HIx}Minv9zY=(H|sFl2N@g8!MnySXI40
zC`z%h;=aPxbTtqw5A496FSqV|RQ=Fi5m-N@0oc(!OGy{@vfe&cS_?{U8ndfx=~=O7
zWi+mhg5<G*fB!eozD8^HVg;pkom~s(h1%-MQY@K<rI((pMlzj|zEizcHIHMsmzF7S
zE^Acq{Lfz9Dkh#qThqxhr6;JrZ45eEsh!8A-+*JBv*nkS*^>N6rFdSMWX}1snUmW=
zjA39Njp1@%ru}QNFOaUT(^oDyIQ=kGLF-0iw$2ec-heWgN>`(SapO)No411t%(Lpt
z%=lC>9<4c6L$QThuSZ0ChP*Ht)KwhcjU>36e4ek|kijn{poL>h|Nijs+bcUYBMD}o
zzF(`aj+mUCzrIc0%o$7nKhGFtUm1&LwBZ}J7P?SR7QczP9hMe$y5y%BgYj>J+%D``
zv32211|&&Nj)|>pX-y4aowfD!^h`~2fpj^bqt5fLS|V~TShxMLSB@iTd?M%dR`X}t
zafNUl?T5QZkH^0e^>V&q!O@615*8Lq4~OY%NQoTH&_wMz%Z+I(@q&k8@FWtT%qq$B
z>{20;<coSd4~ttvYVo+eGRynuz`f}GKuy$ox@Hra^cUfrb#`=qJ&DgO#s7hS^SW(V
z*!f;}?yc|Xi|c;FFk)7xj@mJUf=_q^w-3EfA3nL^Eh)`o{xoT>#*#~ZKb&8J0qk)!
z-$`mDHgoB%mUdMa;s-z2Z3j(98f^{lIn?K$>FUHEXC`7U&(&496g&Sx{6N^x{nE+O
zb+g@XBOr0T0p=gHz5&zo4_Gh%^$g!=lypBNM(HZ#@~m(7S2}EDhv>6zC;UBDn`CXR
zCLRV}4ZkR5eOL0yYQ`2n<(1L&rEm;b$j?AJ6o9-RX=Vj}_qd{QjA;xhQu>GDi_wlN
z8YNsCQvW%XFY7P2{{rdR=vpbL27g1q|I!U&-+UH!qkA60!?1Ty`xPj9oj+EJodqj=
z4x-7(*erV=-l|=swx8hYF@qUVPDiKVSL?sRP7369G(-Jxa&)o%pXDj=q-3(#_9)bN
zDmMRX3&EQtN@D-7EhOP;dUvPd{HW*t90Q*D$A1JN_5ZZx^hB$+oFF`$x!9XNJ3Srx
z%~b(<tmfwCN++^|UT#1MfdcxYg-gue51(#{$!uFgN#B1NFu6&w`u!S><WUmZPy$rb
zQdgPV>U9Ba>}6_ZdL6pnIDIWJgI5)#Y-R55;Sc6k>we6O5of#^kEtd1`+N8{kJeM*
zCy_CH507DsE_Dq&Jwy=FZikHdT!~DR$`8xyDZ0xpS4LH_hrts4tS!)uXl2BWeq(7|
zLp)TGtSXg)n88!xaYC%SYsMEGn)c5G&t}xmPIVLNO-CDhau~%P!rP>rbpz<D*=p@T
znkw+9B=_0!Ay#)N5y$YLQ@sEOVyDn4K`vcD9-oB~cyczj(F>sOhH+hqf7rL#8o!DH
z%~(JF2;>kJf{b}SYPQsf_8+b7x9SFMF9qkeMNv01xL>L{C?s-lj(AYCiA)i*6Em?@
zX|DG<=e6r<e&o38v0`GKIpp017N7E!0>;ug#9GiDt#ss#G!*>UFgFP~{%V%<Sjp-{
zOXk;UMmBtCHNZS8Ru2jPBVHG}DKBsT!bUn2ZoR7u|B5``l!+^PsxYy8*`Q@0snSVd
zfXA9GpO4$>nw@uR`rE6D2Ms>Ym<Pi6f47MLEclsPeGv45GD&n|{=!Lfklkr(FFx6y
zYidrKvjud3&O;HspFQWzzqHi*4YR3^m9Set9-`5>*;<caJ^sw>IdG?xU2e~2ju~XZ
zq}VKT-v8NBou@E$`#muoKDy&j%8}n_n7I`ek$FJjt>zu_q8ZV2+pSUcOJS2M6>9X9
zhBTf9paXcjXPjpp%;xb+pqC}O4OTqR%JDK~#_nxlZ==<mgTqp5(c#34KV<^D4!b2S
z&8Mex0vbGaQ@fK{4G3@XVVs@yGL+uTB0}_E$tO`2R#R0>Q8S4e7|OK=<YSXQn-Kex
z_*TRGFw<HAc_C|;0^#pxOX8Qg%0YLv8eMkXP9kJ56Ssp>UyYWs<n#2EcYmBW&PksH
zhrPa_fGA+Rq>3b7dWRl~5Jd7UkyfA)=_`i9sGy~dH1AH+nUYeRsNdYLI5BpkBC)?q
z^~MLHxyn_r5u%GqW*M$7sqX1>n#u{<*{A3z4lVO}`#Bd6m;HYv>aKD%F09svj#B?!
z3$z4S(U(wRlSr_pe0(6GAI2vqqyN(eer`^qdJ@P}p!fH<-<gqV`-eH){fi%uFS5FI
zbRSpt26bd<`oT8F-KtZR54dIXjjL^GE;=Q=>y%}q<r!NSo!hTjJC7C<nW_W1UqUq0
zi^g{*`por0X61vW{}l7yw|ok3YCfG=(k8wau$MTaVAse~p5#uFDSBUR-Ik>`d}`?J
z;xS+L*i^rJ-2WJ9G$=d2=(=Dp)il25xFt~NeEQ<Fvc_(eE_u(<eJ)6WBaIqgdiHd}
zB?kiaBUV>Z+D(RgKP!ws9q4SUWTum!PsXNSwPXB)V$icA_O%Ixh+{qHyIGD#llO?r
z4Jyqj`QxV@aJqN6OwMlwXyw0;!<=@GbxzOrE$&_B%1{QF$s9#xs<usM_LlpXxxWuG
z%rJlvr4NxAqyj490jV;8K_8kovFn)yvC?AC_VA+quwpGEfJs!La~dRFg{VuYyjRKz
zW?=!gClLMjvny~&?VsOA77pDjX;c^gx+>AdF7;G6q|UE?$3nX0JR+Oon)~b<F4I4G
zR%sIChiLlp<HObC3Gw5~;URh|P;w1#-QC_cU#|uWJl+gDK8c}{gs#sja<;_iLkKbq
zAJcI@czRt{%H-hlP@j(F3G67Pcqc`hm711~2{t{pFNX|=jct(9!r>Ma@EBRK9<i`o
z?iK#$SvQm^@nw7;JuO+|u`mXQA3QS;&m?rA#j95~S1d54Q@dk%Qc1gKpW?kQQG+U1
z#_%<llsq50yC+i~|FE3lc?|r4x&;(D<V=V5xRyU24LZMjmtmR08NB5-d6?9jRj?Mb
z)kQx%pEVO#$>?9Ci~CwfE?`DYJv{Y96vdN^f%@%9sf(j<QLahCPngKf6NwY*)7;vb
z-%-E(!DGvf1$whRg$cX<v*(%5Y@gSBMmCPl_NSLP=_T)9HLzD9zWm@3j*ov;!cP(w
z%vZ;NfZ|N_eiZZr%U&Oj?rn#Niup~RY%v7CSH`bmalEJ}wIJm9`J`T^5L>AKHC9Tm
zU+_z%Bu3N1fEl*BNbN8o>$*@{QgR6Ohi0-WRw=^0E&gCex&h0lOq2|RBR3j)c8=w&
zC4&~a6w!XlF5&JYJZ0L5H`Qkr3<9O&IL2$|q1Uu{$gBF_GAeGqD1IY>0ID1G{Tu4<
z@Ba?DD_(v|RrB-n8ye<2It=@wr~zs=ZeFFuFs;V<(Bk~yw#?wo0qriZa<SMeF!Ofb
z_$)Sm$FqFVCL5{awiDUXcu^vI1u0cC`|BWfwj8;Hx3_+NU7}lfoxLifGsHuDbTd2r
z>fwSB3N;j|D<$%l;6EI{Kf)_fZ;?>P+d+VoBsa^S0W$RWj8R!H$DoU&Ntmp(erV)Y
z`*NY~V{PP#ykQ7!QRVHdeXn<m)A3)n5U6*<G~>B*`Q})n|KO?b(Ou=_{rdXZb#Tl5
zATNg@6cOCp4%Yrm-mb@bl^r#O6Q$@mqJQx8gho*-(luw+Vaw&hkO)GcjV~v6#tK7R
zT;q7P1!P5vceRg9wThK81})KiT<syxQ&rINQm>Rd%u}V%07Dg(dr?3W8ja7Slz@Z!
z5d2l}9S6;%oH@znRUWHc`r*ZFt)*Q5EjC5zoSmVv2Z^W;MXF>d@}6{|SnK!K;NEo(
zBbbMWM<V4z`kJ(mLluUc#xIa$w>yv3tk{|+Fl5$q<=c+7?U|Rl{n&k`+FtEJt_IIe
zhrJh?S|i?__iaf3X3nq%>a%Zpu6GADI6w`5c6)j06qzu*;SZK+=OVc4fJw&w%Ex^b
zAI<oLep<;i6^3YQEs=d-_f4%vAuHhIuLWNc54N&_U(3&Y?;&DdJ4H(sf+OZfT^xbD
z#^bealHile_=?XIXtR<F6DfJ7A}=owFzm;v*52H)^iPmtvysBD_{-nqeL)IxSwBiq
z(!-Ukb$<QvPPg2Sba!tLP>XaFkj?+4HYS5pk9J8J3>@t(i&|9HFQYDd`|bc405!Jc
z|5Fz0Je>rpQs4o~R2)VW&UJ$t#15pCK-bwO2_X_n&+xXtJ=gs{xKI+?{Kaa&b6wRN
zW2LL+t%|O$faC6j7X?JjTpa!<`b5^9rA&y7<is%>?>kaJz{?*}!{Gj95Tqvzr6&}4
zeog8wBT!>a@<U%NXHTVide$BRe4cMkBvCBd&t>oHt(B0aVV1}B-hkoM<nkYP4R+p7
z<CefpQUSo2)PL98ib(x8y{#TOgncUHl{2{q>US0w{YxKoXEt%lC;+Fqu)fiQZQW*d
zI7-0<V1kn`r&#DKpMV$KY5zg0nvg?)f;hIn>T*?W6-JB-E36U){05#GRu15ePy?VO
zo-Wq52c_V)wzy`xKkl*s7@d};4~pLYokJi4hWxwqE4G}Z5j`Cp8TIuVSqh<*Je^R|
zSAi73CgfG%Z5_ft6p>fz-<y8xSb4Jd5rs|QdGImBJs;mr`8U!ucpu!XT%JkCstf++
zHMEk^N%JZWEVf^EORxbEv+m)DVNW9y;)M@c=TF|ZQmT)aRLi_nNy=AtgystuOu_<@
zsep%flk}vDs;0nLF~)zM-Ws9?3qUU}g0Ot$t`%D;4pn*GsYm8zxFTO0O;6Xjgyo#H
zkBQF|h(R6Cf5ei-Di&VX4{jzVIY4V1esmq-6#5^O6vp`TE1=x0)v^{dGukbNs?vIw
zR_v|)0lK*Z&&L6v%xv^L@8qC#c4qsHr?m%^cO1NfN8=;!&|~|PIA@1J7h7=p^3(G{
z%_*oE9M(0D!w~&1NZ3bT5&~lWH{bR9Q9F)Z8v9Q3CjiU6aq8^-0Nq=TR(^w`i)7$c
z#|JbgaIww54z5m#Wjz;{9G13S;NqUA!azn4veR>#QFi+UV;?ZjJcmbt0&q{@a=RwI
z2x*gI;<X-DcJ#oN@nEzb4a7)*EYSUX|Ax$QqTV%Un+<H}!++%0hmk94@P*?$0JH>0
zrACoV4iE|$#TGYK-91{EH4m=XR)$m;6!d3GQ2h_$-U6zsZtojin?|}zLIgn?Ny#m#
z7=Uz_gf!B<0VN~_>F)0C1_|lz-bi-}d<&oFocFwS-+RCNjeEy{F@O!5IoF(P&42u&
z{)YnWl1u13U&T%Fd!x~?IiQsnc$u8QXmx%-z}qENY(nDuQ21)#?s{JscHki1*&4dw
z`mx7|WRNE1X7_wit^5hk>ZTyG(ICHbD%s3NCRe8R=p=;(=dh9J89Gp1eD}CI=Ok<9
zXW(oN$Fq)3Pb}D3R$HjZb7zWGWr>h&i{iS3WY?YW-p7h#{CBmLxF~9obSR&d^BZk$
ze3uP^(|nUaMY8)nGsn<=hy-h2<{slA?j5wL)okCqV=%-3G0)Eh>9fo+VmW_G9n+8c
zH04@+=wlf4I13)!dTv$~eO(}YXjlbefa(}CZo8@hHZAr>?CPWKXvo+iV<X#xPk1Ss
zJ_M|?{VpE$Hwn?_$?QDC=4ru&bDmA<JS)|<6Xq%+r=PZ_i>G@DbP{sWHAT(V&l0jy
z7B+M~kT@45m49;m_Q8ISWSW;Q0Mb%)WoUehgoIqO4Z$??{%bw_y*MADL&ddL7w+aA
zFM`jTt{QU68n!^p%T0zk<litaacl^CfuXpR!s{zDU07T`M(8DazIS|;KS95dV3xcF
zw3LR8t%_XEXwxP{ImOG<{@ico5ky?sgZQ)qItAPmd~s%oCHl^DD9Iseb6-zKe0`Ii
zEOPU9|2#;hhxVT==-rU;1XCDsl-ES_y)is8vz!j2LxG;+@J$Whb@X^3Ko$pedN%-`
zaX#r8P@EGi<olz>EXN?&3Ei}7@NI!RdvW1h#nts%(83V_!CVf%pFXlyzX!VZ(CQM*
zC{?!*m9AsAyw=5Od2KRiglv1`bCx`)+RNCdA>hCgmw4sDOS=9gPD2B}*}bTZ0F+c`
zOlwjA#c`eqELUe)GlhMO{6XI`Y>rP>KUK};omM`2g$b|+7`t2e>`Q?1PE?_AID2Di
z&S8{OaD~~QO@WKU(f$o62+}C3$;*+Sd+(Sxo@k2gx4N?RdsejJAwMfji%PfLUgdH<
zV%0rq=W=sud_kA}WXIGBc-R`Uua&JS;3>94w(=NOPPaMog}^#-WxQBLGS(C^%q8oG
z`@+7lOoy0-`1tU=FVy}Xbzq}Xf4FPheaSpIbKD6fslei;4{(*@m*NNEAvRc{-SM0I
zd~)u8jSY!INC76)C>-v1Hz6$mLM1{#$U|N2Z=-0B6RXqUyd76S@yqGr?d2xX6NfV{
z7bOwdD9?DvY3Gp@mym0jckC!_Xp{#D-US^D?T$fK^U89g;)lm`qgU}Gr#+`>-e?Kk
z>w^HEM>wK2v7cgDc=RACPpEanZ*4|47cKX5zq!yUnZWSB$HFN?nxzG!I<}K_Ipr(9
z**oP`nk|m-<e{J1*raZ9T@*!33Ea-H)8a7hAxJei9sL+JpcZ%ALss0|=CVv+GsvpT
z41W{nb`=;V_v-_YI?_XJBfjw_&Rov0U?M|Te)jA0QqQZk9IonitAP=K@%BP~dH+^}
zn9I1cb<RAwH&Eo;>lUS7^l(;}bAr;z;Wn2d>5B%{s*yCh`<om52*T$F+1J2NCh|Z^
zWXqdqW54T4zHN04^=u^6nWS^iSB2~cH3!SBnft>oDFI%BI9*(=%w$MMEZ^C4T^$H{
zm?%`#$CSIEXm8e*dF9$^Vo(85j!gsvXGVp`HQCMta)T|%2b{fN=^6jAm|xxVACKKK
z8vmRL-lXaa9@o2H25<Wtnn0D~j161oWoseOdwtm&<Y#<nsQ%D!uBCG0JM)m+6{2mV
zje5iq9jrvw+Z9P%iF`g*1F#9N2M8mtayAMsSx(IT+mujzf4yx1FbO>Ns<xv4`d>8u
zsoq^He=o`*+6%CM@Yno>#O_blzg`H%Z7)Mpbyw3_67Ytj^PdaP0a;{#lO-%WQ(Wkv
z3nHdq!Q%Z(IMab+9QN4heR_ML9COeI)$h9Gt;axzV?OsbLVn&Psw-MSE!II-ti8jB
zbiLA0EZw-DV4P3wZSwcOY45Y91HcmwwTK-s_ULB$#>D-sZNV1LHK*}x4D9Y}E$pFi
zjDE&ChIh`m_D+dc7iYss+#R)cm;FP~9F;a3#&O^BO>~tRAPTNouwGA6Bv0}S*lI*e
zpwwOzLxz-GD>moGSGqRtNe`z|g^c{Cd&rTqZzeZt2Q7Sc8^&c;*%~}ifQs<~CLf$L
z%{K(R13I_{`wQC+hnM;5yOw90F~4RWa#|sG4NzeXmrQjRB@e)pZ*v;v)2+H$d8p(5
zIgx&FB9mUx9<`LP_dYxMSku`f4lIX+b%Q7+qI`?a1Jv-B3H7kwz41!Mw$(-7AvIde
zccZZyA{ZW`(zNE|OC4YK`!Mn+J5Gj;-mI_hgd%Yss|>JNnat~`UkQ2wQ)>JJR%hYc
z$xp~$6B8PeTo=TM8o1n6NAC_AOZPkXsAqC=HqT)%Eq&98Kgq%P(fp}=>x4pMl621U
zL?f)fF40y^{&syGD^N<3o8|0qGj@mk*G$Z>7nh6L+=}YvA`-)YZw}vBJr^99$F@6U
zWAI?ESo=_3{wz+i9HKet((ou8;|m6`TtK$kmtADME}OuN7SpKjlN@G2Bx3c6nQK}x
z9xuCCu|TziChX4rbErXt4xL8rjdQG^b!zd4TP(@Bv`PYGTvVCRq+b6RgUS)_yC~DF
zFEx#BNt`vptorr|t-CLC!@q@uo2c#>l)gXR3a4?TO1SAx{L$E}435(7pQDVxQ$=d{
z;4;Kl8Eo!s)G;%rkZG9wJN3piuJNi&@1fel)WhvXSGbzVQ61aq`hq9`H4K!QqV>Es
zITH<OS{_mSp<Jg?wlLJ{6p#P`Kdl@%c$xOS7rX*{M;sq&8I#V197d2MectL5ndz$<
z$JF31IQa%IQbNEz7Q~Dsj>nPZ{?ptBZziLdB!G1Fv4phjbIX|vw;pB&)9;1R`3%HH
z#fb{bE9VF>@I*4Pdh6qXEdWbW+s6!><#3)jW?$1TdMO%Tx_tSP0vpY_@vc(qBVr?t
z<~8`RV@^BW2%6`OWfUb((_4@>J|r*%eJ_OEUnqUthu$T5Kd<@cg^0s@3H){N8M@LK
zvFLYwwUQ-)^SznAdo{BETN?oQtMV-$NUpM)`g6vgV$&Gq6^G(_aQSH0j+M4np}rAx
z664r)EUv)bM#MS5ClxidHn(biN*LldEpaK2hgB}ZmQcO2#4s%qN%F-D1D217zL6s3
zLn;)PQsgUz)r969_RYcf&q*!calim*tw+m-oIAh2OI@ZuOBw_Q*q{aZTNP65YfsU0
z>*6Q`3>s63Vo(lF9_t=I-xTV$Ig68m?i4A_>=6#y%vmU<_o;qVc%7d9V^S)UN(z#M
zN`o|Ns%f!@xP6ABGKeG_x{X(3Ccx=-e=pYV{Un%Vu|WOY`}OF3bv>%BNjfK!e9txg
zlknh*bg8kVfrZnr4TKitPJ)jlJ(h2k@b8~(heI5iAdf*<3q;&8iMn)(SYC3OpHdGx
z6oh3U4{8ESBbS=er5=nzo*Ur=$vbBRS+y4uVzcTB+Nwq0yM(H{;;x|0wUH|CTmq7w
z*1JjV9Dblq_x08lV0Lai`mkv?eJbM&Q#3NM)J8uwM9a$dw0ox6hBTmgAa0nd=TOh1
zTFvkP=YhMC_^7&?2VR=LJU&*Sd%tijo=AIpH&@PPFPZ4wR6UZde;Q}qG&g&xsJ<Ut
zP}+;Ly|qc%s8UJJnFa-^8R|d5krYvT1aMKN&{AI$A~T6>8zqD%pe)KG^u*<7E0>Nd
zWiwjJ0?!jRspeO|H3LdaUmOjjacO_~qNUlbd_Ki<j9FZB#KTuYr+;=UEAQ4&qRnsk
z)As7nZg9=1(cZ!1cldPqxo6v&_EW{WfrYwFba&g=k>D|1ZqRPmJsp3Z{PQ%IrGVs$
zP3<5EiyG6CA({Q?Dy<}uS)Z<SHd>Z9f;{&AHoiF_xwGS)B_k1Zi?U24`5+i0P7pl&
z4!!LS^U3G={5-wY53%8_EW#&xsxXs``9IWEeY;k$3V>*$JgmCIXuX|%KwsI^vfAc{
z8r>uv4|73*eGxx}5+J&^_!&DLv$Ex~%JSD@jd57RTl@Oi0#k|1h65*!<7tj%d{W6#
zsw=HYPKM2gQ3<LUj&z&s95d4N3RgurOi-VY|EeJFPxbGT8%?#uK0<4z#`>g`92#(J
zRQAQ)_<HUrI>6-##-SwcX9!cyYY0@=X)_gNE2Rh-@TUnwkP<%@v4Ak1gd;qq;k1=O
zwr6b#IqJlH3GpgTiWQb+WlNYxjd>%R_oWV7PMijk;a)j&wpb_s*UH6JFM7Bxmy2>0
zTUqfX`rOnuScA|+Z_=lGq7V+fjW_NH)~Wjm)RpRuJkRi9jxhf9AK%i}#??A4fcJrH
z04y)#nJ_(jaghvqFiMmDkG2Hbst)n8{)*jFg}2!ew%8=!6%k=9fc&f1l8<^CeVG(q
zV;lGMaofuPVPElx_6W=9A$z3&@6QDEaz8@h(TKRXGM%2+>`!xjq<jD?mOzXsmf7yT
zXtP<*S*brc1gXt^6~apkhPJXS4r1=wEo}<b!RD$y1f~l`1oB3{kH>%7Qf&nQ`rf<<
zXA8X};p@=n=o!OO7D`_W*2Z1G@}Qx7hicgnjZ7vAInc=wmSI8*h3pmdjVOTwF951g
zP|(}|5o2(+a$md&ia*b#_bM5I^rz1IK7|STt;7RlIZc(s(roi)eKUzR&e_|=@y(ar
zNq?R^t_DcjNK&{soOxAMV>>go*JV1w@kw@Dq_Bc9MTaHUkeOPp^QnP3gO!{_K!*F}
zylst@##=X2rK$XEZQ=N)vvzYQX-E#@2sX6=vO}g(srbb~B6U+-d=uAs%z2v%gwV`d
zcTx|y9-x|WJPUh~x@=$}ALVgEU1EKmTd<p5wnTwU!&xq)<UCV#=g9LHr`QMiUgoJ)
z0`aqX&>|}V<m%P!FQrG;;VEw`JzW)31OX)TQ1ysv45;=i`%jBi5DJ3#>GKeYK$=(6
zHO2}_rK+zIJ<O)&_2_9GIcd;d`D+&eIy>6rv?%q2t!VAt?PO}^kDflVB&*M&(c9hD
zIOc{bD{E_hs=&J2H@z>~fT<G(*b~+dQ)AvPe=*eb7~KM<K1%q5-A4wQ2KOp*$->Bj
zk8Q_7kWaPFk7(QZF;YjXTomM`b`$fvC~{mPMl64Uc&aYHu`}<vl@Zg%cZ)JPgg{!x
z)+7Wt3NPc2zr~qi{1Z8*N9er*Fs~17DO-<`60WH%fl*9Ah_7XI<PnwAs_s-~S4yy?
z?i6l0<r|(Qw4|}k68txhov2__iiIEPVGcRP<WDQckk3qtan5j6Z7G(5xwdzF@Pkou
z;#-NxwE1`yhn+~j$z09(;SlC1N!G9V9f#+qj6p5REmB;qG#twhPe(H583_0w_MPN}
z@XANUbO614lWGm8CT?T>V3nA={8<KW0B3QDI+i74US!n`b;;j%Ap@AY?SQ1%nkFFO
zlCoSPZ|Db_>!9RL>e-9}XbfZTTu;#g#)SRJBxd_h4RGe0l9F^z=Itx}9t+UUDWx7O
zi*wJbQef2Aiw>!u74wM{+t_VXu?1j$I@Cb~OeI@$9oci{jOus?-7UG0Rv~sbb|QBt
z((AiaU6Cw2k+sr;#5+^JqrR|}6cY|9mrG-bOxbe2o#OX=5!C2fJlhE`j;gMoPB+Lh
zv+ZagA{D%D{VJsrA$0v_@6;jmaIS008LtgJ(3g!IhyKZ`gXCFKjh3@8-?cjgkA`C=
z4^H(m>J^f-Xup7F+S49!4RkpbWJRUb1LjWYnKLA|S$7pIL!)AL4$lXAD|a^(pc*v|
zn!X}fC}^=?%G9w$O&O!PHWfe1t)P4@^kuIcvNQP8G3mJbIX;|?ruoQde0r{s*$}Xt
z?7g$wh#K@>9Q=l+!NYH}e0|im#lz`dL8jpR{QB{W{@;=1eH7~F(NVVp)WCzUWr6O>
z{mGodce8zG@bbqS4M<D>J{m;;>dKg{w5mtG#DJr)KKN1m)@2NNO{Z4P{wlc84AYYD
ziuI+@{6K91<K5AbZ__G#m^!#Q>9Wp#E9%l~HL#fXp-{b`-fmiIU{^Y{7Xp&{9CuU4
z``S8ap@lL*v3xX!Tc4rpUGoUY@7L@Z**@k8L<MYNVud9{MH?Eh?9oZZ<F_=;x#P}l
z3txMY|9xGay)gq$*uUcI-eL~kY!Oit85XO7&WZMg-4wL7ay6hJbR1`s+m?&+ZAYy)
zY?_((0)1L}`S?lovxv8qWHwhaonMhL5H1&`FZg*cCCef&`3P+SC*Bc4A2JHNFg@1C
z1_+szirLUV!CR+2=K|*P&FNuR+sL@00W<kkzpE9wSUYytkAqrwKjP)DVp>YeL<XIB
z1^PNI^w}hxiRr4RY_7BW36bLn8wwv=VOwAt8J{xBl%r(j(K*{28rrK-IwT3;(_#fg
z*F{TNX!5ZmLha)VeIbu*^S{a>pyfoo7MuEcJq{A(Y0)IItdJ<^(*Med-%06G4E>|1
z#r1e1D~XBqdJSh+Wprme8f*2(QP+m5r>8i<qb0+Hyd3uPTL{3Uq1Z-zIV)X$XLEuT
zoh4RPmg;ke{~YlE|M}vMt_%6`T%`=4@8KtJIN5^%H!zy(+aYX3B#F%2=dT;!sG(eC
z;6Xzhk9Mz!w#X;@GVIhknxv&Sl=s7dSoC?quoM5XYx$j3-|Np?6?t^@JeNR9u_9m3
zb@9h)^)nZqBkmur!gz0|<r0Z|2wa1vTo$L>lx)l&2^*3S{*p^nemF}=UCTr7GGF?+
zUHrpe56a;lv>k-C|NRKw`NqQPQSo^*%fJdlZ<9N_)0KDLh?uzHXs}o&$A>iB8|i(-
z$tLZKj;|(-&kd^IKIs*O4(t9h4Zo{A*b0Yx2!gX>MAwLt3y($9JuO;+X>~q;5;PcE
z#?;Ulkigc~19FcrZWM`<OE^nwFyq3toO}BlwA@l;JUbkfM&40iMN7VXMzWXR_ew}D
zID8#d0!rqZ!s_IzIf6^}*Y>r0hJX&O-y*KLQu}cR?N{vxB3evh8?cHgyNk$Jyleyj
zYjc%(!mnK#W4H#q+mz6LMIGu#zl~5DKjj+uq(*&2l|{=sr~H8dFXX>?RVBMFskejx
z6<ub4i|zf6Exi)l-0H(cf+(ZTb%`7R?2tLve9GBbs|R0J^?2oPAzx8oMOj?eqR&Nb
z7W(k^90S^yq*h<h>}cccz6rBv8?M`V^HxJEHlmu}bUO7ju8Eu+0;9}>4hZk~S#I<z
zBtcQ3?=C4Bg==<^;qLV@e4?sVrUt5RDJ{MX2um-&?nIW%g`YHR)#;mXTOV!sNm{(}
zS7ogYyu0E3`zUVxXJ#@i%ks<g!mkm|1uMtE-Odx3FIP*=rpwqewcHFk^;Om-$JBTq
zH~0enJfwV*8$sW(aAfFd(rV3Yo>X+{NLG}T^f!<EgnyTL@Ku%745#0oT(SeeeR%9~
z$$wrd?5h9l!GRF)C`Q>JFf~d_Bq=-$q=KL)QB6J`3aRHHPlqUV-YR_2#_%XN@}B1U
zmKxlJ2s?CjxORSt;1+|cT1hXN>E#~^K#%|={z$5P#qO`jRWosu-7>h9f^Sl>4fys6
zA@99@y-OgjtVQ(GpEom5VIIp*_42ox8Iqd3GWa_N__8bmOvP`LE8Qqv4l|$G^d;-%
z-#Jwoe4%4?+CTuJ2jBu{{rt(Iwmku$93T3qrW<XlMd4F+78MzTBn^YN?kS6Nz03@a
z5`*8hL>`|xjmZ6Ln$xAck<^ctyu7?hrf9bwlq_0Lj?Z2=x+o#)v^EJAB=%@G57jt?
zZ_*={@t;_4cvCZBV3p4nw$=&DJIQTwQN&I39tGk`3Rw^HJD=sa>;51g%)e?}nT9_S
zCkaM<5Nkr?hXnO+vGaV3PJ=g>S=i|U(Y+q1$C5pfLO!3!6a6bTb&?}ZLTZUlL|Evw
zSFB@;DPId1D!mGz=NvY}PP&}gzK{e?i#TmKuMBH!>D%&<djtaqoQQ}WY$!G64JP}!
z8diEI=UT%3r>{jN4-dg=<9D9HU)`gxjRqI)&?8(k<$ejcZl^I!^<MpAzx`!i#l_}u
z!7?wv?qA4V=e29bxDU2%La;_Djja|uc_*{WO0+lYKeTf3x^dJbx;6dS4s3HM^8eOh
zsUtG|#<W6u)vhq!xV^AZ#j=!INByZi-ZYNdKdK3OU(!c^p$rwIl}^boO~@|47G|eh
zw^?rYdA*qa7AlO`(w2H(dlX)3=W4hljvk9*NSH%0C9OGLGR&F_G#28d{5!GvOuz2?
z3Cm|zy#~XDN8`A)V>dtugBe}Qlbh|-U1gUWvg5}>F8=nu4C&*L_b2OGc?1V-gtRYq
z2K%>XXWzngJ=xeFhJZ3hQV+mD@;+~IBD`lPAT1#NqfFTG^1mw|K0crY`4abkwW8Nq
z(qyNL@z#$TRP1^0v`H3)1e-sj0w(c<WLs+Ymr*!=0xh<PLadZ4UVPZTTBevYsz|<A
zoU^Tph#^a_g0Y!fxxL{K|F`3D%2i^893w`V7zNOOjTScpQAPm^t{TfF=eU_?Si`sy
ze`yB!p@9up_yA?3%=qvyCt<IjNzmRuhyv8#9)fHzSflg;;v@--tJxsxB@sE9-hQpW
z@R+vi7O3CPX61+&^RdnM@>qXY*l;Ixc5?JMu&KW2%vwVFb3K#Yf~kKNg_*&0sTbu@
zRn*OP@Sxel#M;8wv_6`@Cjpqcy!F;R22*ux(NEjtS<F@^Kua`nQ1nLLxn4TCcP3pD
zUPR2tyAK9{>;EW1!dg*X*|N|n;OzdTj{ElY7r)1k9Qa)A`t2-2VyY1gj6-KkD)<t5
zgl#wKX4++kNXvD-hHSkmak1q8+CWY*n_F8Wrj?+@_IYvdLlAkZqqD!eD@@o60>VIw
z!-d=J5Q>Q%$N%p^-X6<CIG=0Jscb}n{Ufj$33(`VWEMeX54lvaR8I6T*e3Ux4fenY
zSF5&VWA1HkXwVzp4DPD0P1f76f?v3L*i<ghb9sVzt$&@o2?%^IEG)FNv=ryQl%8yt
zV+1WCfByWbUwR?$gvRmzc?7q91~=Sm`BHynm20H#KidZ<^O+r`RqiI63;E7O_RAzh
z${F=oD&^&m_6q25pU#%69;bvj3D%$6hKd}N+3~a7x(j;(6da2aMay@AK}yB{Q1aZj
zGNDCk2vQ*WZ)%>rb{yKY#(*|0Jf8B6tU*$}GCH(>pF^>3bzxZ0T3+ocBz+sxXO`3B
zy$?*zeOlUex+?Bluy1*{=6WP%4ttfd5x;AHC0^QcKo??w40dEgbK90o&Kk@#Bk{?7
z%K7NUIgD%Mkm8AyE(s0wBg}lUm8{^w=!Q>eQqwNAF8X?BGtY_GJlKIvpyBh`1otL9
z1#vU>bO5NuiZB+w6Wd$=dQwhCku<q@MttOQ*SEsrk+w5??w!q^!^GN<ti9>JG&6~j
ztcq92XS`F@BXK!Q7R+P&``pt`-c7qm;&_I>9Q9#Z>({QF4D`Hb{vRf=t>U85mWIAy
z+zdxn@zfS%xWIGE@xL`xM-8G%fVG-$nNpQ<lP}UybO0~XF!gWpP{adCTqHnh&_wZ*
zYKCm6X{s`SfQHcTCig-~{|OEtr-C2@#e9(x>#$w;203`n;LF>G8^@2r<_aef(A-d?
ze%uqJeEPz$)BRjx-l4bPjuh1)7kPx~;dBH^_NyN5{#yC%`}A7$)m7pm1^{$BjK57a
zX^_O?G%8<!bi6q|#cQ)N8e)zX;3YMUbvXE}>$2$8V7>6wC;7v*qBbE48&HH@LsEbv
z1a>)v_Wq?<3tow%@@_ZUs?XP<>`gP)%l*kdDk7XExLC^EQja9Nv5gx%M!GJVko0bp
zvj&)QEqzpJ@hswEO>))|7xX2N4%%1JB=pdw#1Cd>3<8b{^1=lwJ}z}g`}3tmA-`1K
z=Of>lm@uO63ymy&w(!nB*!sb264JTJ8Ap6_jKSu&x@W@1lMrX33pbXC=aM^b{Gc<d
z#cA9;w=F#aF^2q=)A7%6zB7Ig`&w%Hx`vMTXHK-TMy$aO6|?yY2Q}J(l==5!I|Fhg
ze4m@FowWu#_u|fXXwhO-oHB%^<+4ZOAeh81hbW8Zid~i{h8S3?J#$OWcdc3?*c8p%
zrXlqVHQ?Zhkph-3PbN6AhR)_cb{`;Ht}sN;&W7cBDbF(ZKOl`(tI<qnn?p<&f|N9d
z;?e`+(tmel$2?8`H6$z?#&DJq%PZRO9Z<D0LC%5*-JngmVG9h}Bs6B>;ntf)`o24S
z*gdbzQx_D;Tgff(^+aR6-`*;z#^|FUjiU1R=(_oNoqrauDNR4dEI&oRT;7UZ`eh@G
zu<JM~(l&e{Hhn0S60e5^ozoKMt{5hD&skG@j!eH<%gP%5f*w@|^Z*^pggx-~ch6QP
z>+>1(qe+7&xg=j7zWrLp+rr0B3Jqw2#0%x576_^p*f9;f(o!OivJSGKT}(`HDtoYm
z_#TE6oR?B})v~R09a${VL9M@Q*j>D!G=~D90T(9uy**~}8YePaezY~xF=WrubL~d!
z5Dm!z$j}(^T4m!_1%tpPE-+@4&9EmRXQ)R#l@(sFUN6H9;A$4I^vx)_$;9na;hWV*
zO1g|><EN7o_$hVTe+>%SO6={J`fhNg%}}tQq&sJ3sI8{8HPImcYOBRCx82zb6XdEl
zxZeJvN7Hw@xVU3G^%&wsP;IbzJo+h<_KsOH@G(hPodZ(8XB=FhvTCzD{DG2cN&W{1
z7Fbq(bQ4pKi_tDS()lwag*D?yZ8JojhZK|X0HOPtl0hQACXV>e6_U&>52H26lI`J6
zpcw?x;ud!pD}^zkCoVnZTfmVY7D`O5@^)yB!FezBoG{h{dk6%{50~$YFk2Zro;&}#
zc?C>85^3iEok0kmywP3X-Py66t65%O?}Q&)aD(wriC%WLnc}I+x^(eWH!J8@a=SVm
zLKI%H6pI093M6kcPT+ij4{Cl|iJ13j<0eUdX`*4)i_sT35(A%5RiNJFt3K*|#Xihs
z7(M7OoW!lDT`WW<pykl`o{A>2G_sa~tIgQy!U=^)>-j32dbV3wytSmUQP<^4nxUQk
z%~C(Is3I}BQMHDTy=&S*%8)THcVXl@$)m5NKZlo|UokT;5?o0$6({+n-)V_)OAM2C
zf-F1L5e1;6xx{+AL83G!xx&goeZ@<FXyhx~2R0cbntJOOh00cm(VJ_ZzgJXFKPBrN
z$9=A6pb6vNLlaD4XMT!|i$5Vqyy$p_3sjQR+ix}WhgUTe#y`uK{bDHd!3KE$E((I?
zdD;#tFu#PU6P1-Q<#Tbp?`xalk20dZ-*HZ;43u9JnQicCiY1i7!c~Wq!<*nxP1DZ-
zk8I1Hjr4KjO7G5<2`g*A*C^R;S>EC}n||@TPPlWc76T`9%{<O{Wb2@m1q-+2WW4fl
zn9NUB#jq*-TT)~g`ThP=?Z$`ytWd>)W=g#)P5Ur;G?tJzMF`~di!|h?VBw;gi<Z54
zVuPP56OeF1YgqdGw0Bedrt}I{@>rqtoCL)2A-}+lLch7xuWGRyBTo3S?23x`<F2Bn
z4(r7r%c$7(xN$5`GO=`VQk>2Nqt?ao@4?%Bl5z+KD2ottlJRr6dD+NwP#m$6c3+(W
zmQ5mJ$)Yk^)bw**>eNXe?}ka7RT0acRyH>;buX*RN?Q4I99sE<;_;lXqJssOJKM&d
zcwb#plhI*^7EY_&DWbg=uR$Xn5UjD<9eQ`O?+G$9bgInB{Ms);3Z{<hZsmGkbg@>w
zG9CW(kf&^-yEWN=k^JN?|EJ{V<L3Y2<Yy;Vs`xx2@m2Hr4VNJA8<4>7d^fF`48k>1
z_rs9~rw&?|9F8t&i`gH{*3wGh*SlYS;L4RJ489a~<vcYnn!IdtX|35z?wrCN9+EIn
zRPg3Fi{f@oSEs@K4!C7XCA!r>$$$eryZt!fue=>ry^Nzs08~S1!7DF)0Tm&g03eL~
z4xnLdQ;zgZ71Q9Q%_AQ^!n66EIR3mIJHvQ4suN=3LogIY$4_Ikh~^|tr%Ft%T4hu1
zICvb@9_tKjSjx(1WhGM(uo7fuH@VO}e=J+ZF_824*^i$B42WS`iU_)%;VfY~`1Inj
zEIk@2cj}6tcNeO)p4du<sP(PjBf~Ok{BiN<^4lg1({c)!mMsfeXv>f2&DTnpBqAyw
znyhX+x{D;xqjEUDe!sPqq#cMGjW3@c5{B(`g)@q<07B$jY?13)=OF3Gp{Pj&Ls(MC
zNw0M-XO{w6D!k#CQpkYNx8bA*rW};O>|7daV4*;(oi`ld2Y_^eg_P;pY0M-<Co%A3
z?A^R<(_>qQo3-BIOh*8DvlT#_`vs8aBH{on<9mD|1{5oa#;Z#YrfKqBVxLHQ3`7b*
z19KPDfBnAmZka!*NZm>{RM6R(CzMDZKDcyyT8+M0Giyib5iG_zuAr`w4P3ywte4&!
zQ31cYf}dzn?C(46+RincJ35~-KypAKD9^k7JCGe*2yV+lWzZX1Gk=^)#O<QAn`%4s
z6U7yo@A9FOj{E8Ox5v^uySs~S$8QA%1wp9fq_!(oi|Fkkj+NCu=yNkO<T*&`!9f;+
zw3KOo^=eCq&CQA9_E9jY8TEnN2VnyA7^;~ihJtgAv5pq1gJrS>x7qxkq|{Wmj>9|T
zMpc41zI?J5Xa}ONA8*ILWY^vg`o-^gh%-{-pquvXUEk=YXDww52Ek`Mv#5oMHm#xj
z=`<WEOLh}|;weM|XAYe@!MwCmMcRbZwh=IIwq72!Wt~DBPLVeFUJmMNoNZJbQrcn3
z(N4$M(GB#-FiTFIWn_%IiM&7mP)W4&JmFh3c_NTfP=N$h^<Q_bqopxSH`f|qb5^6&
zASmI;Wr9bJ2RQdN9Mg(jG%Z8+^yKxz8QT$H;Y{?fV0rhf^MVJqIHHld&j@*S&|BWs
z6z5qYCWnGFqXN@Pl+xvQdi6M^fi9stQED2B8k1QNTpBzGT38KYj`Ei0Yx9aa22AXH
z7!v@!$Rl(w?%M*)HA#y|lzOH&k;~v+AEryy<>RB-0^XJy2K~}@TbilD&2G$`nX@SR
zYE`_;x}(T3_f+U@Z+TG+&HPyit@|<Ifs1~xT~}kelkLr_&A#TW;3R#f9HLYN{&S<=
zf*xRKBK+2C<-+2Y(Cf+i^U`gk<ff{U3s|P|y$0r`_@0FyDap?&_|4K<+4JLWQ`Qft
z<f}$sS3leXeHkT{6wXe6V%xNgzQ@A>7FTWFt~LvrHm!JLv<yEc1!_X#X7sHSf$wha
zJ)L~2v?JcRT<Szauh&&{h!oAbL~nF7Y4-CyMQ)T@$1eNCJe&C0S2=>H1WQb~$wlP8
zM;4o#Mbw#!r=`(^tDlVaw2RBD2olMSjR`nARr4rQVDrSi&L;u{Op74aCms*aLw29@
zKE%!jg<flGWBb-Y8KIBdamgN60eYl`%C3`#e9XGy{eNT+-^Fo1rK8IzC<tm_ZaD0s
z@O=^ist5|$Z>4kfR=0u>pj2L~zFNdR<%WZ2)B7V?yd*81Z>G|Y0&Ye>=A0~_VuxIV
z8v2%C8Xt2$;NXwKN1pz${pMo?#dv)Lv6Lz`JZn#rcmo?4`J7{q?D{qTJCITY(t-{;
zoA9^!Oc3bYNav%bqwy0-ao<PAM#`%s$Y(>fW7&IG+O$L6?WyMsQF@@~A`DOfDJ~Ju
zj5(4A;Ev-VvxjoXDaj30*$yU6eYZO?cunaw?1_arAtls^eSCR<jT0EL8#2DQZ?!#Z
z7BQDKShhN|W6)DiD6bK&^hp7+%Nb!1G+p7hrk-t>#sV!`><{yneo}d#?2iW?TlMfk
zm*G$Es^0Ow?)?h)P)a{I{$$@GIu0$L?d7kYiyP=n{_e?#0i1cb9Iv8}SbQs@)=?=I
z(u$~0E!Ij}R|bt))?_jSlN?=--MEe{Ei|_9t4&u@$HFN!vR+b8d5Rz%qP4hPu1^Ad
zzk7hQW4BnivD(E&IXSQ-c2<D|b3FK6FeuaDW4M)-uM|vqS4%tgK?%l5KS>Vx-A%^{
z+bWhzlY6)8J_AI=3#u1Nqeim_g}k5OCMJPbta)Bi2WApeMmov9|6LE5SQXT>x<9LE
zV}x+{xi1Z+SwKjR+pp`h`k<a0n-m?Ok|0Q?y>ndN$&N`*28l%bcYCwd`)yw^3OM}Q
zV@2GrtUQh>sHv&d5n*`K$o@1`c5N9|D0O<m2BWwEXu|C$G7b=ENg=Bb_g8#iX}j5i
zzNK^=zjNy%JnJHj$v#$7KG9ZJ<(17ivnxJ!4*<M_#^>d}U$bn$%O=m^n&umwAqS!k
z61$0eGZ>DUUY`{_Pf#(sc5v1aN67J8OGH8OyL5Yr9Cq@2Dtl6@_H95w_}lGIGT+g1
zdS~sXxVHu9qGQK0`t1@|0ASo8L0MT*n8#>mg{Io}1py>OX!qOEdEb#5W((qI?W*_I
zPppV3W!J}A+5EaTVLq!*8<Y5o^Vb6t!0!#ipd!=MQ5;s09$JqV=Y+pZJ|v%^w9PP}
zI3UCU^dI`t)`7w^*sMHCe6vd{!mmckTdQbwuvy)b)G$-F%KOcbFGc#agW^~}Vn#R}
zSpORJ<aa^6tbcI3V5|hCo~Zz6w$x~cQY+V?V>6wa;2{vRM%Tk4rDV|UsroH}yC-{V
z(WK`62;@z;4097(Noth)fLyLgE*ro6Hys-1R_b#xP#2@VWs-J>0Pukwnk+bo`?z^_
zaFYl7`AN&k4e>3y8K~+m?eB|P&hb~OTUc4yOSNh7h;rWpAkTw#b2qlK-g~*C0ZOcb
zboK~x%I^_q`1_?0QhG%iP@z!LYpE*roNXGkFfls&?q`l(0<;`frvqAj2G3r9-}&si
zzvN$6))1c1URJYEXk{9Ry|&vE^c5qTWqUqubVkv&DWW*5&_#z(hX&dq*3%%IGrClC
zkl4UuVV^g{^o=efx99=b>vugjYAn&h*i)OE_`vq4{5GLOkRNn>Orbl5v4~(b=6Va*
zXlDd`82ctp-_xCzMmRFHR)59a`AU@J?nhov;IT&Ivv}oC`MlDhof0~+fm(sxQ~OMo
z@6f|HJd}LULwht&+CWXll;rZ_?9^<0Sby(%ey4K$-OP_7)SQWs+Gt&TBu;(J+V{v%
za*iH3h14;?X{H+wN+g##)(b$E+7Z+9p4K}Hy6Lf86+PhivW;XxVNg@uW?!}p`>ugu
z0-?s6fta*bKl!!GhBTSG_MYg14S%w}AbO-2f@XK60V$fF7-;S;nQ9WZ`t(E9sU!&i
z1zwJw8t%1@L8&?45A6d3d!QaWQD7%%a-6{cq}(g+`{Z#etx=j!X)f}r)vu`R2cd=~
z#-X$b@*_ayV}Cu+Z8;cWuB@vnxUfFkMz#Pv)#jvt>BE4|Or?DNM)4?CpD7AlG{s8D
z(L=y`B(y4B*`nWx-fGax8yGh2nKQ)Y&y_g}kHF~V{=xh}uxe+o2u0#Y@6j_EYzC>0
z!or_|=)elBsj2lO{UtH(6K3WgEWL9CjW!mCrR{)N+XqJr!zmdaGX=L-A5XhjAtO0T
zKr<Z|BB1kdZqW9TMipmyfv&8S4a}*M&NTMT(&w4H-UcDt9z*=kl<J8|>HhW6jokl*
zc?@L7|9gj_wg`N+ZdJ^zm;JXn(~?6~<#SMyPuRS1yb3GgAreB0E9x;|8S@%9l<unl
zJ?vHZf);=6yQY~c)3<Lq1*_n7CkqdA8J{kHWq2Ej<|UGk@a7<fa6(lnr9nAk+!W%3
zH05H+a%UVMqsDg^OB0z#2@5P%(xY19)OIPa>vs*u+575&1*Hdy`ZDVK&ND^9ge9dp
z87tV(-2Y>xI$QKLsD@mwa0gOknwv#KyFtY&b1N%Rw~GT%k%*X0(`2?$8Upqa+ISbB
z^GEiv3(%`C9`ryl$?H%0XV7MsNNS>LWT-A(1PTDafL9VP6xCkwwBVrcaK(N}Y#w+w
zEsp?GIEdnQfV?O*H`YGPYUmf(??>GEPD3Pz1-!H6+cS!{3X0kw+)>z|XP;3ZDlx{P
z&e1o17?6%1zH+s?l~-v~ytZ!sGv~p8(-$o>LC0}ogT*(R$kv-}Ukq(1`W}D?C=i0=
zmWc@@L=^?sn=!XDM;s%pyq3W~)-HbF<W54(XpmmPnVSqZFfiA3Sa@f6SR`4jg51#L
zhr{S40N`F1%^1_N5YZUMo+J&NZ#?D^Oe%|hOGU9Y!dnG*nCZ1So9!^DHq<sdd{{p<
zIx)Gi>ah}vQB<6;U6^zEv0G(kmBIxdHekeGGi|c&vK+@UA}*immi>n0IPfXZLOD8Z
zJ=)p{!9EE$@Foqe_}BqxN;dM1wI?TnR?kYxNeDw?52-|&jjO4pv_4^_9-kuGwdVo0
ziDlV{qRJQ|%uNVv7fpjd+OSsbacuP_v(xj|h}4{Uz@-xuk$DoK{z+lcdL#qZwI%f{
z1K_gAGQ1%N4jzHNZI_T5>8o-SPzVWB`vgz0KUM~mq1_Y(3;-yg2huIuKBHG#&c|_o
z904uKkr7_JfB#-mveO_`cw=|>tt`Ot1|6ms?OycQDG6q~*bc(LAuu?Kle$0$qSZr8
ziV@O^QZ!5o{VJbal!vVm<dn*14IYCgL>T{Q>MUfAG+_9uAZ?cVwZzQ=Rtajx)SpdM
z$Dbn&lb(KN$Rx_nddfqd$#+d};^Em@VYK^Aob0Ju4x3j5Ka0nzRIG%OM!rN0KR<M=
zT4_JSzKQgaEs15&OSI9z9Zh1i{hfxOw7TAvI$rt|uL!=3Wm`U}42excq?Y0NGL<&j
z$PBpBcqDWbrL<VV$-FlzjKeX1kBoqlk!j&hZy>3ltPY<)pfS2o=Ibas1BV))xlpqR
zuLK=f5AmMl>izz}3AKN|j7dPwZc^D-y!gov-T={pf!@441pwx#I@Oi)SykNBE}D-y
z5N7bPv`0<P(7ZU+Ybu%=RE8$0;{4EZ4I}?q7b|#~+n}Lv6u;$+ZI--!vp$RW>+ncg
zl+w*3VO?2xoiF)R?Kk8u(J}IYSNjIs<%=OI`Feomg!=Bk*IV4uXgtKY%YL_DH(vFl
z`u@C2|CUo3IP6HnGad;qH#f!LB7!j&JF2|%WeB@*JG@9LX1w1;n$D_3tQH?K03oMF
zu6Jr0Pd>Xm$YB4R7b8cYXUhOVx~LCyBQB?SMPXL1yz%MUF7<Bi6dmwu*W>#QLOGct
zd)wQ6^hh0w25uOD9p)BqZ*LFK+{wt$&|<2jb$pzt1r+aH1UV4!Bv&?W?(g^jkl<xs
zdEW*d3Z2|U0M43@&8*!a{KtYu0g9>L@XnF~r^I(Fvq9$eHrOMB#Xd2Q5oMoPQ0Stn
za~BqF-mKp?#gVp?sL2<D7y6pimGVYWQcMXmYV_TncENc<2IeN{zrA3)H3Ojkkrp5X
zJM-nLH6GAZalJq%Hy~!gbzv(}p3cVbbf*NV0)o8FhC4pOB%_~$k4ZYF>d))6+-^;s
z>*Iw5K&Y2=zlK+7Idy@_rXU7@Sy4U3h9l4I8;5Og8zy~mV<LxWXqp2F0Nz835UvK~
z_=;km+dhF|kgzer)OjQTL0Tn{PwRilfho7{9zF2&;($nXN=zD=aZC;}1nuyvZaLx=
ztb~abMx*1NTw-xJPCfLg?y^`{CO#)uRLV<5>Odf6hgJ>uc0|ZPb5UFnTxGE->VKZ8
zGm-u%{_Zt5Akt^S&Y5Gp)G3}bJa}CD{>x5&QB?F3K~+;jP31o(Kgk;?UaqG00WXXP
zy>-Es&T#0v?EIXZgQKG|)-I0zP|;g7C|G)$on35l2mQB1&ZZ26sP>DlD9Fk8@{-?j
z?VaMnuCA_9QfMd;(qloGYyDkY`(gVhN~d37n~#y_N7GE0JCj8>zHI8XIdE-zoCyDI
z6Vg$O@uRpw&7RkBTZRlaTX`g!Si4@nbZ$%6ri}GY^P;Jt#O3W9YKtyK?Sb2uxLls=
zJ4e0~H<_8u$EYyxv>p9qqGRJXgLh|TH<vs9&)FePeCJ&Kzjq&c4zd^VHn?sKYD}_}
zD1XGP$GB~M+|2t+o+Qk3-Dvz5UsVxj&HQFHO{~2jye#c^Umpdru<kHN15s+z5%ndH
zY)tadi=eJeY2Y&%R?bh<EMmXBk*4^{fc}mvt`<WIU)4Fwa&~+uZ3)XLwfOt;!u6|B
zjsvQnu@4_~v{3G?p24iHDD=vv-!T^Ns~8yD8XNRgjj}!s%zCc+(NHrAVZ+st9BD6C
zi4p4t-P>tsbMOrnTeO*wKVQS0SxFV7bACaR1164x6zccpSLjsp>t>3q<mjO!5LQQ)
zbUn^2!qlr>Zo&)ORuAQq_>^i5p-JE|aJw8kE%+T^iwr4OF+U(ED{O<mwKRMZZ_2fD
z68V(~gBa<kIrPBB{Akn)CEQaSui9i+0@C3H>f}G8-2kBft||GfAfr<T<5nXtmU!jt
z$hm9jtipfX2BrFOri|28i==pQ*vF~sT}QL%y@y*SU}i6UHW2#2I@31W5`#3z9Bjj{
z=oxSN4m-Nzkq*mBE!~cU|9X+T-&~CXaB%5cY~=>gho=R2t$r4<6?e^wj|Lm!{=eoO
zmC?|Gg?W-P*kZ6#$|Nf@ByZ0csyk{bPiix*Ly?C5g|@LNojE{d8>#Z_vsbxBagyU%
zj9K~-+orqjca^n}BCephD3Hamqv*b1M`0?Z$F0hy^@I4T8|D1iVTVR?wUuG#RtYyf
zm{J2l>mwER3tWl2O*rM%wY<m}dRKZ2+V8AOwBcceka%7Zoul3Wa>MQQt$;7nW^l!t
zi$)*?gtV!<zikI8yQIBf1r)XAzvyEcq4svQum6W8rG?^*)W5@oogxSmtW&3$0KlkA
z+0le=<o31mJ5*+J9D%CEYDuA#j-ert-<-B6hj0MpKxj7K&C^)gvSOJ<<TSwJQg(B#
z<8RjMy_F63fS)4(Eu~ua3XJ4d^5Q|$1&#oxg1h_YgLtx&-pmjzU-c|Xp+`Yy<7}d?
z{S5lAYwj*q^07z;em{3wCzxQeXuoPfY`7}uv->w12r45v;3213;h4NKx_^o7Lllgf
zcsr=WaNqFt!v~`WyZzB!csvX>NRF|=lO6}jq201H|MyYPp@{63DEDtf6XYd?j=DU{
zvxYBY3i$8sc_wR!V&Z*qQoR>MiIZ0OUEe+iK%iCF_`#p98iI-GM?1n_)xDQu)1@Lq
z7E!=9qGTs)P_T?}5P}IRkTqTtS4lPJs6s6J>IcXQAw{1%{UVaiNe+BvW|u-z@AdZO
zCI5q76q*X67HtAOuhP@S&!NM^!>MwNn0?=<U3|Ae3W&7k|1k<kM(UBvde6|WvhBzt
zAotCpp0uaox~tgT%k}YN>yv8v|9eyrR5o&;H=Z2cPiDMzj4Sy!h6MrJ?=gOWkdRPb
ze!ddZ_zg4ni|kQnS67`Tx650lSekzj<f(>)q5F}`uK>5{r%PIz(wW=d&tE5@QRXL;
zQxP<7EX5W#hUg&4?UNIbq$m4|sL&Ruhc%RM2C3-jkxZ733p@N2YG0Apu|<4MYqWny
z*x8M-{Y7CyD4SZAJyzKDj^WK-q*&(mPGR85c{%)Ur*o{lRvV77jl7!XNo<h*Y5&^T
z!8~S<-}U&myjCRg%c<BRJw{ULvQO*o+OZ_4uUlm+8ARuBebi(0K3$j`ur%v(4!9CR
zrYJKBa&RD?@H|ehQnR&+Kq#(!c20+*8-5JjafY*&Nml)sXg6kN-)MEUS!?$L<qSX7
z4h)<-uz{Mt613l5(vg-uJ$>}(kx%{*$EK%*)E#LOiI>*<ZH)WkvGp(43iKRfK$Tw+
zhnuqm)y>J5Z*e7jrj7SIV2Q|sIp=)vOkuBcn~NvYx7C7G6Qp-e=W&zj<JA5eYAS|(
z-kl~*ugC#p<c!V1K_2(nKJ^_uUJ&tmnxe&u3gwF6b=42zX<7}O*ut%GDnt$mOo1Ii
z7fD+6l{4S~RE0gi69zz}Ic~>Gn`HEsRq1>)K|80Ho;p4EfAqm@Y^JWX%N9`fPlXmL
zgCL!d3X+cb+IuNj5(q&DBBJ0`_vURZoyLbi^KXTI<HVfgOP^{V?;>zs+=p*BD|$EX
z^nblLY#s;_(qJHwWRo3dd!PCK?E}q&jWob&jKF>2RrsLfw(0MSnp4*KNQwZFf4GCu
zSQQ^QHN2rd7QRl)Z{mjK0tygr)#oRTx9bW|W~Q38XId3u@+addND2_f>oHC&ITaWu
zr*Ua*th@rXd5xA{ZaIz^H|dve5qx?BG*YXOwbaXhj0yDzF$jqGVg38@oa>tK|N9V*
z^6-B*gqxYG!PrlR02ZeqKds2Fbq71S^;Ul)bDr%rT9PC;t1s*sg@%A=Exco8-JKoq
z;VUgmStvhKKG{{!!mu$&CTchA1g)Lu#au!)59hK1M5FFk<bH>OA|0B(k0CYK4JUoO
zz<2TwIu<`fBC8AnvWMJxVK=px1GcyP(kpYwYbpx`0`c|snV2oR>X*p_b4O|i*U$0w
z@=+Mr+;p^68=qu_@)|I)8++3E$2Na*a2DUb9T{1?M1;POcPJhFddZaq_jH}Ub#v%Q
zhz1(sugQ#V9YUJnBq|gO!pHDJGh$UU%QyY()rkBc0P~6P7Q#{ST!Fw%*8~qrHN_1v
zUAZM(Q~A56vvYeIDhv5KCFStz6)lMYpd%{k7Du0(N|S10QRV)gBc3Mzc|R{g-(Q>w
zx03P*{mIL<I*lvoX*)cDMu;^<r(j2o<N*oLrpDD3Evq%yo6N6*%i-FIBKl~S$!%dx
z*{Cd+_whTOT-8$D7c_U*Xw=<LnqO8uyYr>B9G(e4@JGy)mNk^<hro`oH-e$x!u&pZ
zrA0S?Fz2pbYR-)N_{fqy*%;GOHc*w)*jn&?-iHhvP41a-kflK>w#Rxf2gv5%;=KR&
zBev1t-gi5J!dFs1AQ3~@W2sKwT0GWBA}i%RRs1;3;AzqvXH?u|PAVP6$J>2%zTiiK
zpxvdz0zz+?|F1CXL!O-=>`6(x2X>`zW_XW=qWJmWb47#NOzcczRuuL#n(oy04n-Yr
z>}>ec4_gjP1}gvcKE3{cbi4dNg%>j#qbbQg*eS*nf{1IpZ<0=bW7I}7j|>`_J865)
zYW&!~VegB3etRui$0)+ClIFaNf8%Cn_R}Ke+{;Xd-A!MzLVID#A|l`jM~?epriN+O
zYk19!u})2akgNXB5e8pYavWNm6Jg%JmfQtufrn%x8U#fcx<@Vfv;ObK7cmPKw!MQ?
z#{pCLd!kJjrtM$2Jh8PeKNoIH=(#UJv=M5~l?AJ+7YQG9x0|Q^MkEYw?s#M5w<}Wa
z<3J@}*g8*EU=qZe;AFDhT|Cl$buIJP12%n{m{W)YGcnFDY&jWWOv&SN%_*7Tl$!ju
zbr1X3pBTgRL=1#l=jGRS6$YKBV-lU*mV!~mv>7?12E^?Y_`>=3s`Bul_Z-ug%}N6#
zy&<PwmgPvQ)Qn7)dgk1d?Tjb0me1TBN<S2$o|EmjDc~Qqk8?>O?ABm_5ysh8Ae02)
zjPnB<Hz9Y}c01W??N<qje?0}HIwoFPxyf#V3d$RwY7zNU!3S#%KHv~ilUH&(D@xti
z)-mAm7h0r@ePqakY8TE<)VTUjxQO?PgCY40yBK}(^K<yzC^GLD>ebJ}hEMprBz;Zp
zvO9-=qKsD+It|*+&!9{O%+4XVy}jotO*sYqu=Hlo;OqO<N$5LeVk+3x3XaM%Ob}_!
zdCy{n7gy;Bqn%3TtVO~Xyck!!0=sTQA8hw6dVy9mmyVs`KeUtm7|GLP7QeU_oszu#
ze4~DM(sJ|9gQBt%HysA{zY3MN*VedU<*$N1`5He6V;4kj_*caSg?59q$%jJ6m6L~o
zz?PQ5ivG#y5M1W75=OWqapEBp%g%~GRb6*cEZ=;}&;Jo`O?#u5{GX5lCQbiOum;0a
z!H2fmbA8HRX;<|>h(8P-9uSE=|68E@-u4j`D+S_|xQPWH%w0Wo`xkwOCn-q~-DNr9
zp+9}*7bY1$-6&*$YEXiHPsl0u>G{fOY~1_yr7Ezld2wLQ!$+#WK95X{t=6%0CPCF7
zy(fY@oTFz=;Z6r$*1tg3kKLwz{^1|Lz+}D`*Is?3aP|0de`Fs#H)#C7{ll%43i%Js
z^89bf8L+wk{{E2v6V2j=g20HszwCI7^hYQB{)PWu!{J|ky#pWsuy;TO73mpg?-EI{
zKN8wb{gEAv;lU3n62v#a+~<WjHllT)BPX-IUSl-#lZ~5s2Ib#YvRVfy6aDQU#Xvpj
zOiSf$?#J`U-X%b2yCZ>%GyhxCkJA70Mu5{l#MA%!A=(O6ie$@QQ}_>q#dQ0pG<;0T
z=&v^q(jWeX5eH?Q{(#55NgslXlql$^$fP7K-7UvR4bq}PK_yTDNsiG?;uG*UG96@E
zrh=Zn`Qt9m&RAbQ{b%6wZ|M~*v436<AJDYd%)-Ln)|MizN3@R0SFH9WovEcIabRa?
zoA|%JX?eNrX4WmvM}!suQAHav!~4}Z_mjZ}Xw{lOk4FxTy&y#KmzuG<zmBACzIHG$
zb8PV`GrhdMpMv=)l2UB&;Z2rv0D!GkGeoWRQ6r*HCeJZRfElmH)$Gy@isUsWqb!GE
zPswe1fQ;)8$t5B~<_19cA3(DyoEF|r>+Yh6QHg*H#nlDf#q#jEoB>!Jz8r!+8p2y_
zs1|bY12>AqvNbBRwhld!|Ha%}hQ-lE?V1Gyf+e_nf@^S>Ai;vWO9BLU*90fH26uON
z3+};#H16&Wed>L`IcL5jqu2bHpAFSjwYygB+O^ibo`(!}2;#xy*M(<yIzji(4;T~=
z@@@6nO#c|wwl+TRoeG2SWB4y{g-8x$?fqR3pI2DKUriz}TOFR!qMEfvm!-^+W5;?^
z@71Lf9s>Ai>c-PDc7N;D)$wFh%1~2N4(583c87TWX{H7kI(Yu%4_RC+`+8r^rry7V
zRE;5Tv=p~SI!0=GiRFkYsH{=2d&Eax37Z*Z!d4iPzK<^D`J@(K&`-vr^|}_dkjqnL
z=R0N~rZTI#HBwS<!8J#5xj+>iduv6-8)F*ApLWQye6N(q%M6eHV|3_i5r1h7_WL;y
zDG?s!7KYsSAM}5wqcaCueTk<vHp|=sjS4{hvGToVdam!qFcU=Kn2Q;LE=}@l%{o&b
zR;+#vh<K}1E*OfI?+K1?|DZt#0Igi#3S`3EtxUl1@n3<4Rvm>%xBpiFAQ+h<R1?E=
zwBIKM$P$RXFkTrcCc)ApzPm}+Heo~)BKr}N;d$VFGQdqYya=qW83I%f2v!$aK{Y2|
ztEY;2Xq?r|HGi`<gnGF;Yz)!+p-I6Aag_WxIDo6vIM(RE#PAKNPa^5`(6A>0$bq%o
za(Wujb!3vEm@I6K)W~!&ykJW1@NK*~@Jd8QCwl&-WIAJSOAJs<P0wgL6iN6in)|;3
zHBr{CzUx(for970!?q4<Yil?@*qSZYnuA@A6H36J{l!y8U!n5#tLmvLb$<cz^evy!
zbp`CEJ_9I_tlYRmBBT78S(ao7#njG7b!}3W73>AM=Xq~?-XF1ZeGsI4uTg&q9Vz6I
ztWdoGnEj+-;zVD1Ai6zIMKlsqikrhXi(zeP#_E>?P*?NwpUUbWsj1!-Q<~V)Am{NQ
z-4wJ1y$n0r$Ng?L2->d9!|?Td5FoV$GmN11=9P+qptHi4lNU-ryS$;cmYtpb^3)gl
zI9INd#H7=|ZYOlV6$gSu$6)=*pw*>Zin1o#mz?GZCIF1`s$uZfqY{J%9#K#l$7Qj9
z-b+7n6;P2DsZf;fiSFcx12rgkGZxo#?xFJXQqnr9>9I<>Z(=~<F?gxX$SSypnpkCk
z!l?brxwjb_jAE&ha^d(0qxr~E3tjDls%C*W?rZYxuLOQ)8p7eoaUrjY)F>EAYxvmT
z*E2H00*Wc#Zs1j1BS~|jb*bo;_G`mb`zT}lQAheA1J1q}gF0w*XjqD6T7<aXapXqR
zUD~?40xr0;=dao8^TQkL(p_eO_}E(W4C&IIff^2xt|^WAen~T8A-#lqnNJ?-q85yP
zJrXM-cgq@aIqxXpsp{QBf4;?2t!yAQnyc=0XJ?v&Q!I{ADWhGe7vL<U=Yj|5Ytc^W
zzrppwEJZQKNvDYyDZis>m(pVNZD)HxCna_HN`LdRk>TqBil%z~LJ)z=XbfE1r8cR%
z$~&pRja*DT;@q14wt(jBvobHFB)ogBxKxq+U@%bwr$ti%Kly3xP<DPt);~PsC!2vm
zi|HTYmUlDc1lN~+R$BSp`3!I7g&ucnI}u|9m_{a`on{)Zmk;A+TmL0+o%ujRqy7Eq
zLeN>R)2Ii5o16Q}HVWEG4OqFH&uSQu@H+Iath_{UuT+6^vYnmVas50%EbOy9GGe(<
zW5RW{s$xc_3p$=7md2BZw^NO+6yYL*4@rY!B^okjMFaq3XIf38a^9S$vJG>9LU-y3
zu2}~~x8J+=UI7wRRKV}w9>Gp*H>3fGlP5p!qC<FI#t+i;UQgA!jBEgP-ALbLF^Qv_
zY+toeU^4zhV_a%lYTYfpvoj_2YhH>|PTJq?7atMdFRmn&8Xt^f3}-(GL3OAd9|FGO
zB>;ajDN(kP#D^5AWiN2|PJhz=b~#;Qj%$8DP-bEu3M-<lD;|Ovt7de_rlhK#002_F
zi8-L<J33HfXp+%^ryir#jPm9GL#`0R@YhfY!Zb|P7}H|S-x93PG;VMG;D8S$n{QIu
z)5q3${b-244Iut#GMIUjZ?NlKJ{1OizpSROh%>Sx#N8scs-sTFyuCeNr0Wef&719r
z?KvvM9uzPb_^L0zwHJ4bkWe6`XQ^+J_n1=wL~<uTW0nN!Qn^)lD<i&Nl!!~INNjpM
zv_+_=l~IMI%Tj=0HrbK(BtCq;z$PdE9Di=h?1!$<O|_l}65q?uW~(Y-u3bVBEI-~q
zfn2Ogp*#*QF6h(EOikV2-Thtgt7l|~^|OnM3uvG|l_w1*gG@|Jh~MsB&l^Zi41)f$
zL*Q5P=|uhk2&}69CzNloOC6&@kj|VlGipXq%NpMEt=U%oCmMj3fe8j3*Z4l80#Ry#
zRwt=eR$qN!?iJ(bl3{lfXX6#N)3y-w4qG=rPfgWdl*3g(R-O!!;TP4+eZkV-%RLHI
zzfc3mG+?W+PD)Fbx^~|SGV_*dmw&WsQu%u#c9gU7zSU$7cXqBGoXDlb0a(ftpd^9t
zMp3E~QjjJX3V7{mw@(_w`S;LgAp__g^b)IwHGBXOUeKY0ngf@|_oHT3t+F!pnVo!D
zV-+icFD-avO$|)F=C;LLuBoLPOO~D}{5Ytt$O>^6Wen6(jqSNos{-(C86B+Y_NTNf
zx=^=e{`s46XKA__zsWrD$YeH4HlVIP&o_(5CskM?OWIxjh%fsTRU6?anx=(w>-Jcj
z@Yae;$bYrAPG$Ekn-g`(VznvYk^cm$h=t=D;22mSg?I?e6z)yU@;&2WhM)c+8kR7~
zs678g^bqd5Kn36N#K*C?n?c$6a1cvRPR}z_xD^Xa%YK_zCd0}pBAhb+t#1C}0-FgI
zZ6L8~uh6{$H&HuKfK>Hq0owNv3@a+4r>cs9U0-stIKQK}r-zWG#Hru1aR;q+J++sE
z+(NqyXpneeFhzcdy!)n#YM7lLQ4haFxErM2$G0zWEYVWGcQZS#Ht()QV^dm}x>(Ut
z(PA^aD8piGonJmyS@DOyZcde6Nv4Do8@?JLMx1<|^8VRg6ct@m<Xm}WVt~|}SYD{n
zaYJ6{bmHD?Jk$|dRy3RYrXOxm2yCm!B082P$3`Y1BATx>fG(J2Zf|Yn<>lQ?jQh@5
z-oKZO^a71Zp*M}4B%o`w!sv%la5lS}QBmj{7(mO=?;yhl(5K!{+&LwEKd5Ig{d)B@
zn0#GY%c%rpX{X$OGxuqpL<Jf^2_-#7vg{*w<wk8f1jExiN4=GJlLOT+MoJ&O-9NS?
z@%13$J8%%yWM~D`meZIRs}_z6p-{RIA)cD&*O2%@UJO49M#JLE%9fX2Ue;bTQ20q6
zROv&H3o0m2C!dtrd+B78c5c*T(eQ{Eam8XPh9)b<9HMS@_{p4;{uWFdZ?`~}G%8q4
zn6=I6_O-verjcW|S^A6fIIaJd0<`rm%bMv>au=*u7fp`^)h>8GzyBihcGl8X?R@C=
zsFX7zJR*8ckLV9RFAa@@g7s3_ZIqWI10e9&J*3y8CQB`T#AlRxsdSt%z(3D$k#2b}
zS??KNvVAMjaVGKJsW5T$?L;!a#ihsdg@iPHixifFTJm_E>1uh1Ax2C|$^D{%%;wN#
z?an*VZ(#%@$INVn*R1*b;q|#WJh_!&2jgj-(o5CMvN7(|a@mQsI1gXSskRrjgkS+R
z?8js)r=Cf$qEc^GiuOxP6-ns`>Q!$xZ;A61G-gzbT<*Gxb;SIUZl2`B?R7Xj5By*p
zzMmp3=%dYoM#ASbA$U6q8WQdO$$mjOt$%IXxb(%?xIdEQaXZQ2;uZ@Oq6R^jjg5^X
z7f(gS=*){pkGA>Z7idFTLt0fGrvtNRr!4u`wGe!Jal0!;bKeZZKMWDW2Dh5iliYG@
z!+$2_DtGXJygSdY(U82?K=tE8#jA!1m6RQ(xlBD>(>el~&zya!b9*BZr58yybFe_3
z->gG}Htx3fek07aUPkJ|G$Ek>aB$3CSCZah;r-&T<Aeb1*#`BRjB1^htQXrE&E%SK
zHsU2xxlL&w*;xjr4Xg3#afju}T=*<1|9)D{kA{!JJseXcaz<%zifG|V`qp|hM1&VZ
z3FDWdxSvM9d7Ld~N+s!&A%HBhLNe)INy^-u04Kh-m`GOFc6RqoXucNfT`c9V1V$vE
z3B7R?8Y?RH9`JMAXkxhZnY$Cj(VE|gMQiUfCTBrDZ=sE~9_%tRtY2}gPnv+};Pw{q
zP7}kgC|bYevrE<%)9s*l>HC&SI?wW=Ss1OVN1rt@trMbl)=f2AoF|1PF$r_Rv5xk@
zg@gDDI5qRd<~_RPc|yP8u$Gc`GI}zpSLhTtjW_K{yP&?JyjdlZ0Nmx%dk@e<*3+}K
z+mOfgBu$t3l&*4Q8#&J_Tk&q3{}i-B0|^G9Y7ufb==1Hi!+jdB<I~q$gNrC>VK~2n
zId-{n;VNS-^!LXGNCBv{Nh9Vq#b}r{7~PXe`r3Fet#u8x30A7~fGo)>RRZjXy=y?3
z!v_`^Ibpg7W>P|d<tV7xEd8LW(qN>qH9=^Ld+Gc#f4!pZ4$U%yGTXr$KJRl}>+wFx
z)tLnAsck&dojitGZV#6mj#+(15~IesvJvcBMmAGgn(bU6Kg)K_k}91;Cg)GdY}Z!p
z7=D^UIh#GT5+e>5BjxC&naeHi`Z*ISePr5UkK&8tE(+Pl_d=oXBvfo^XYp*Nm{&r6
zX8*8W$V1XoHnoA288i#BPv;G5FC2cPl7={*H;$9ATiQBWtuOG3ZvLhd`(P2krTYh4
za4WSWPI{<B@X><RtB7kkok#kepXYdoj@W=aut-`_DdfoXG*93oC=&6$?)KCV-C-M%
zH&vo{xG9ktkKrx4eR_rAM*Jhq&t5h^|J>qJy1=w@>E2IHrF-uZ$=qQA%tp}jVKnK=
zo@)KPWFnJD&<9AEAfBJ_U0uDR@YGK^f!yi$`j1gx*jCAT9_%|{b>X^fFVWzfd5C55
z9s0uwKv%4jYu5Ca5mz2!(d;wuC1Uk*LKw}@2)r}<5d(i892_JjCW7`E!2tnZO-%0T
zI>~~)1P{!BGynQToDuv2+e%yVtuP~e7>2}W!}4}U7{7dn_RldJ?oA!O5|+3VI_>yf
zC)Y$Uw90HiJV8qZfFQuqUbAq3x~=14OIr`Sag?SDwBoTaRC0`uDd(A*iB$labIOIx
zbO=CkYhyYuccWnfv#(0AHkSe~D^b}@&V0G9mPM7AM!^DU*RrQ`&|DV7A6u=&81_#2
zMl4|KVBA`4Uf4vt{*xsw6C=ZDW-NcF*CQ@aOvnVy_R;b2X~yYV#$n%~8!@ssYu5bn
zS*Omhx}%2LHAXvu7Z3dq1qBG%ri1apTRd786*Kqw*sLw2kepm@l3&EGe&_^IF=fbJ
z5U|y$rYmHbm>Nau{IL5{HPIY`SF-4GEO2pOg8?KeDDGgBz6b~z-*@k{1xr3KiTpLK
zm&p?>BR%1rj~$Sd)x@=9-qn8iqboWHpd=2=Y8*u<$g-*tcQ$Fz))O-%&~3K41`SZv
zCbYPX$;l0rMiP>gXw^Q%vuToQ7${+8CK{KNokOsV>|{%+#QS00Ty3XGLdp6m3)2L$
zlIUYSE!q&J=Dyt|bfmH=9ai?Z+P@KzRWZr`u<RW-ZDaj|r>WA6F`ACg3--H6mwnpE
zc8Z|q%}lWh7A7XZL;P0Q_BG0xAOKc}dxFvaQDWbl%)Pw4)JoLr@N!pEoBfk5mLNmL
z1pBEI4j4BntoC(?_=4ZP{VS&cI5_pLQ-rbN$5#ZZvURltILS_COE*T-BmmS0LXotT
zzvgTx!oKO5HD3?_^WmI`C)ghj#}<0`uzE)AId)jS3^TAZfS;4`iMEjE3AUR3K3}cP
z_NZ4bpRfTc{yl-@#b`c*1FZSM@;z^<Q=bAhz6!GXx$F}4xZW0|fmsf|>VB;oj3}}F
z6Sctp-@nxmfavjz(+Xx=6}rxBgIc3*LbsZ(!-OHeYvXpGWE+2_cB6>D?Nf4T$*u3Y
zPTzAg*f-kLH+zkZzWH<=<i%=;Z~!ABWPH-X9ID26QKRPl(1B-DuIJ+!?J^o&XLpDm
za-Z%P1kV(MrlsuGMrS%$hVPp+milSfH6h~{yOL3fV53*&X2bwLtY5<?sdvv?VLWcS
z{1l6-CO!*mDGzp-0HW9up}fp*s^~wmkx0!JQzw58oVG9MzlcAipNxD!=N59D?|@^=
zmM$3bs|sID&Th9p4W_91P5<+QXgSI1e0;H&#HU<=XL&?#)K>wL3}enTVwkx=_?$fR
zN@-M4kwt7odfNWw0_I6~WnC}6zmb==@#m!H6`~AI;H^=WL`5>sn4tHhu34<)tvj_f
z`NTdRav*>oBrPM8BJBIZ)VTZ(8<{r}3-Q%c9yv7dQM#)WmXVkD{<ah9t)w&w@{G6`
z7%=24ET{QN`YA%*9@^T3@Bo<H47f|`F#dA?5MkO1DO(HfZ=G1*Z!vqB8-sV3D4G<b
zpJyB&o26%Rb~gRCMQ5S4tBXfd{&QO@o##FGm*W2Pug)&-uv?wsO|ECRuhrQNgH>VF
z9(tF<+fZEzaoxPjUDO^tAFRQJAE^t&*89ADE%%?woJxXR6HD>pTK7Ns!!CcKUVBJw
zhaELDI4qAKwUiOvWEf;7&@;H3O6~{2`Y*f+^w`L0R>6eGm7ETm9H}Q2c9|tw;0?OY
zVB-)R$^lt_zB#ZbnYxSS>aUbB!Zp~AYHQ`Oo=Lvp-+JFmw|GP>XJgTs33tGGXu9!h
z$+<B0CPR=Zb~Ll%=15<N;-T?0?Qz$;$7}cCuaA-TQ(0plOQ$hcb!^}?3-z20pGpm5
zO`-0D{Ljow7cu4hdm@Zf_ObNC`(P}aRd=@Eld3f#uz+Yq$_zf2N5$M*TJaAp!93B)
zgld@ra){zTv(yzfUHgN{`T1u@^AX@OzW?Y_Dd?*TYu4sRXA$*ki{hoHcOJIiT)FGz
z5VBu>CQuh){xRX1mV9Y;PDIgl<T)kUa(vnWBf=;ifSA!c5YgWh-}>m$@9_q>V-^~z
zi4wRNyxO0>ZzOO-c!5h6+7gZsA-Cg84-E|k$@430d<=|k=spzE<4*$^KDZXCnGO3d
z4ElVf+>)`V=cJY_G>}2!>N50yqgbN|Lxr1liRyeR2-=Up*`2L@#8Nc#FWapCg)3tF
zUDxZJE}1GlX?(aBzx%=MEE4|1f+37y@Ml!`!^d?2XTPBx`CL<eCZ)ZVwG)Bz>v0|9
z^Yp(es`YP7MaF-7!qiOYdL=S56(fvtWo`D}6nC$T?L=w!<*-b9wJc80nKxU*2Tv0l
zOGsT3Qrx$Js(AA&SEa0&2F-1aa$VfS#*=idG#@h^)a<?;YNCHeY(8kPT8K?u%A`rv
z!{u75*ARB2Rq5*wZ^xYFRPAVJyvcT-e&DFtaA*d7RgAxU@nl&w{i22Yy&XEz`V<rt
zBr?1^kBky1I-%lshu<^t^bROg$ds3tf7>QFAD;xesuaxRi75N%-M@LRLf=3``PRnl
z1K}?aYAvBZ<y7-4)2R{RYx3$>?TlL5qJyD2<d-AIaW=R1Bfxsp)JuxOoP;8{TDWw+
zer|Vi|0|zTbU8NJ(BHr=Co5zzoa*kM7p%LoM4$Co%P)xZ5YG@%@h3o6hZ(9u1v>z{
z$xf4W#E|R|MVJHA!DpvC)X{PtM{~Q0Ni;|Z04qPe;mE?@p0Q?uH~%^fp?jxe)_e=X
z1PSoqP7#3aTgL)5{GrHce}s9x9m0i3G0$|mz@{N#fl6dQfi2Im*3K<YN$5EdfA^x!
zZU@-|v-O`mBwzrFq?nzlpXBo?+dnbie<OWM(K|mj#ZbALej$XRCn^CG`Nu$J9gf5h
z72zuNQ-x9kmyS1N{|;<f732p%$#_qda))0(5_I9_4Go?;ZGY+(7EGDMqKm?Qg6VQz
zw-6faY<%Q-vsTjOje`25Qf(a!AxbMg{IurI!a9b7e)sX7H$avykL5sqRwsptCNi1$
z?Q0OgJ%=>Xl;K)}M`D=v^Z7IU@F6fAT@>;D90NIU{7_v=YA`?Z`{8dj6ad`5=R>0D
z&t0ammGR8K4VTxu^U&L#q?bqaK2P5tCWicfCSGp8_-u~dBDYvwWw;)8vdE?|ke~Tq
z*ds#ZCq;-V!jhyYK?RmoZ_nSRwZ6B<p$!cUYin!Z7&QuD0>H!Wmo_yufq3ZLocg?T
zetrGySGG4Kd{-8koeWzC%S$^v@|2irYU-WM)&pYAj#!wI?!F!!6<aK1nPJd<vQy<C
zj-~UtZriA%N_V@G-Ae?!2y_Wp65IN<5^@=YTP7exRb+s+UJCvde5~O?TIK~mS_%<a
z6-m&C-u7;4xQ~7W%LE}gFwOI<X|J>?2pxalVzdZvL-}BUV?CWd8b?iXRF}qK$jqx%
zI-~EjFb!V}1y7$Y7d~JSkD-4OooUWJ;^n*j=*%CXx3pT^Qc*alHwa)N2j=#NZ#_Qu
z)4vBo#o5?CZYN`iBT@uJTO#*-U`uA?<7+7>=r^v`_4uyWq{|#AYJYdOO@@~^^fmWW
zMC{Pl`F(bg#{*<|;3)zpMk*k3#rGOx^FjEzy?N+jUf9O%VxJ~fnYqJmw|qi&wh;oo
z8$<^TV}#5<v+tfrH|lgOKECKkYUfA>r46Mx`2LC30ot0bw;w_KQTHm0$o_@K;<c`E
zu`xT2ani!D_Va2H%p>>bRdW>R%Y&o=2mjfTuP`YeN7$;{(Tb5$j*924Rb`cU;n4W!
z3?VX#AwYZl#CP{OeV6s<1*xZn%<6IB*|r_J?k@S~84EK9lWfa1L+GNV6^0}sL->3r
zqh>g+VNi2DnE*?<2aEL8*@mw{2ecuzHE*kwoj(ZTtFv{ONuu3yb_y8sF1H(*MYSn=
zoy9Lu{KU#g=G)&nTSs%#-sWu?I3dAhF4^}X6!cP`-^LbnIjt(9a6tW#t;plGW!G_w
zW_UNauF-Mpd$P<MWb`D=_3PiDUN=}E!o{5{)J5%~O_0e~4uwfo&P+-1*bj6vcT9>P
zYiGa!z-#a_hVnMJXWJoE{GC|eWM}2Gq{^mykP&fOE~viG{~W^}F;YnF_JRr{%9ql7
z8HW~eepwLNYCq9kGB>f}VYkBsMDm=ePc!Y`LNt}ke9kw8hX!6Qn0+4Ogv;A8zEiGA
zo=+DFob5B1sF1m{iHE>d?iC7MeC7F>e%k3pX}U7A&waw{)bu<JQ7NQ`b32@lQlJsy
zy5HH_5DWfZ!#wc#P)ODou7l6~^J&-2RuFO?o7Xr>@@B8-s*gqc3wuV3EP=X>g(h@p
zQJ6{qaV-Q=T1-N>`mnV*9U3Lq!FpfLazkW4=uIyKfwUV<c&jIKT~4?T^$g4H_$D4}
z2|XE?3P|FO8}E9uxC%#*3YGFtmPa#yW&>Wn8=e!H^#zLzUaz~1t3$-!wd{%@QhY@R
zopy)^v>0(;OxnK_1w8K`jwc|3bEkQcuw&UnE7IZ;%vn3safdp{=&R9`iMwp9O8Y8R
zm^wLE@9kCWMGN~#A>}|#NGI?50+dVWZ#DGAp1Z$BN;aD10bgO+#hwU;2KXTJ3NR<p
z)A8AyUSuC3+cFLe-W+f^bWPi!dFSn3aK68fRL!_y`<c0NZ*h=if}<jx0FPPp8jcr_
z=ui37<LQ{RIGo)9g4(04@Hs@)_4`hLp&4~=4I+{2Wz0e2UAhp_9C2E_&(Xb7H<k@a
zy0+lM$5VB8GChUDNd;#ig-O2+jc2g+SDG?*{e7^n@5bZY+#J@xXAL$4J09XEPh=$U
zj{ZnXOFL*<t9Ps(J#q@3@0)A0jOU(~{@Pt#`Q1OiiguxG=Uyu8Kr!Q$tEEqBTFRai
zAHPC1qD^%gYRtXn;R14R%}2mk?1y&y%|MOFK$_F(aTnHA9?svJPe`4RBm8b#JN>b}
zj6k^G5<v8xvrDT6q0ZyZc#Rm1b<A;kXW$8);4IZJGqe2dLX|ta@3pa(+FwtDyilPG
zk6ky^Ovv=ddw~d_lGY20j>nAC=O{vUWzdf4vtl}rsfD$5c{y(}A?L<$-S_?%a5$(A
zS1Nb8PE@dd+zrP(*WT^Z`(EadPOvwFS(62b4wO!UnwW3AIk0K>?WI+T7`VxUJZTO@
zy4bxTk=6EJ(jojIYP_gJ=(on;5cY#+BAJXb5$@QI!);urb&R-ocu7b8L8z3AU9;Kq
z+#YStR~MIaKWa1n0$tMo{JP#}X|1B7&-h}sDwJ)yd>YH5c`GV1b>8=?u#hYhBKG}7
zA$Q`SqE6FfbiXACBX{}oMdID$;H%l&0_{My8~TPY@P4P*@^Ga}<QgApcKvGy59p+h
zSyaO!Mj>u`LZ2@DnD=R-9`AKt%k7qO=WH`*%2)_P4>O`<?xT!12FQ3-fh7&ew>Z7M
zQDlDopMKY@dcLO?dVhD;Ien&fRISmmbon-u_H%~z829Gc0OV)1<m!dqwGNZBZO7G)
zjWB2O`+i|+hOsU@o+k?Op61vL<sb=4U)MT-$-vwFOl(3v^NpwXfDY4aB_&@+3d`di
zWsWBwAGC1N%(+8;vI`mM&HBKLpr`n|$)bRm`6Hb!@QHygT7jam@m3`KoyYcK;atVj
z;ZO=+(g+R)L5I~fX2<QRqw}D+NyvF2gGQ1!ajUOy>xU*@`onH%?hCT94$GT{Tj9v^
z6<@xs#I$|k<H2=7ir!t9ETn!&^Vx*$sm}u*mH^SMLdyN{<Hg_k+f3X~g$lzPadPd4
zFTN)WBnHoFPXU=?f3N8@R8Ai5g;!TewyKI~o~9J?Z&wqplWq;ruo@!UEE@<5gga}Y
z`v%{<3(~yi+wgANuzc?r?weYbo+J2MD}(A+8_rlVeel5(to`7zoY$vExWijSD*ygT
zb^aOq&8TpqB}&hSI=@hK(Luvco&LfypP?ClRGkY1enp^uU|pRQc6<ol%~&z4*YvHu
zfcCHano&7j-Q=)K6hj9W{8Ek2O7GmLf2jUtW|qBfCUN`Wvc~^5H0LJ~Fb-SD8vu8%
zzYdx>EPfZqK;_DFB8t87I_L~UcuUbmi!lyYPpmB7q0%tZuFpV<z{R-N`*NL-<128-
zAoP7AXx8BaKRUG&%irrAZ$*egZt%oGOJ>fYXlXesFJJrWLb*Bv^hg^Fysvf}Jo5Aj
z`rt&c(tb51%biaRAA4~)Y+E4?_(kGpoqY9nRB=?6xmD}z&AiT3O^5pUhU8vz@V`4O
z6iz2*ud;Nkv~z|F17CZ<C{|Vk?ArHK0J}gw?kB@eHu>yu6(DQHH}lCt*?}o(`9vfh
zy&4W0p|^hUZ<Gush(EU;iXaN7?#Xy-Xf(B05|qP`2cWYJPM)qsVMg>~fqMl%hA0By
z><xz1Ah{^GJQZ}{OV?;c`sed(ul@3@4Q%t%w;XN?L1X;>eWxj%KmW`L@^6FveO~#-
z(*opqlFG$(pd`X3Ps<aAC?bIs&p)rmSEzr;sE`4~a~ej*BMa{D|K5iV2fKs-0&EJY
zT!p=Sp-OK^r3=G<1T@n#D)3GW`^E*O57<iCcH%oePCQ%7)@c3byuhV(qK`aGSmIk(
zJ`!A=+%c2R#bA*Tw0EC~2{4J6NPOyv{vC;f^*)r)?{8I1HNJcOlES}xM%;(<Km-0`
zFaC(|z`wf-Kz#=mQT~^s|M&m@uQtpnh5U1w0?;ou*BzQ$taLZ=gZ69Ab0xvw^q;*p
z3xLV}KomSiTv<!YLlJBt5$`K-)mv3n6&)S@5fkpeUIpeT(C84f3nL=pM-Ob(t(Y!U
zV89OhPTSVp+}sWpb#T#+kXpF@+tzSNBeToP!~_JqB5}UDBnUZn$)D%`{slA3uY2SG
z@Cy8M@WJiLxj8O773gaYV2wyvad(?=8Van{Z3pC+$2cxj-cX=#_=jLfzLG>s=tpyt
zOT+}C&EaIMN`u--+1`-1hS3CrBOoA$Tl`422dsH$)qCwf5C9zY8Rizx-*HBM;P1~0
zy%P1ZYfjrqd?2SF!XWlGr%Dg(TPyVKG@N1sQqf3J^U5L=$~g8c)jMxPmDL^WD>YFE
zyGlGlkPi$?gCPj4DC%#EJfyz-AVDALDuKD#ph?8Mo7oRJFl2{e)O2p-(lnfOl|=)p
z)Zk1--f~T9z*B2}?qGMJUnzC>8fJcj`?H(glivdO2$7sVy3!9Ev|kRe*79cpSbJ^B
z#E{5}+WyH;Hy8g?SD1;grX>q2K)ckDZ`dO*{Ol>n0fT4CFg349p+Rqg($92xgae1n
z%Qj;yCtvWncBT|XU!&1mOFBl$0IifnnN=BQa8#XPw|#GRp}dqqTdM}rRj4EtlRz;m
z&<v}jau;=fm&ZSWu~5>8Q@NmO9H1F)RnGC{nyacL@+O6To@J%3mK5?Xtp$RD%)KvX
zTD0}6l~ymgzIr6a#vn~a+eX4RJI3|$E?$q25n%@Tt4XBdw#}>3s~KOHTNwz~t<p%o
zl*Y%@RJsvO2;CjH;5dvQb2?XEhSxxe$;pM9`j@Y`%A_J$={DMszFv}c^-#d!n(mtj
z6b;!DLG1co8eAmoIth1_#ZUY;$mrFNj%!L5LEsEZOo0q|bT=Py+$dDoqrPvNp|ePg
z&Dl^EY}>illp#<2KHH^^q}gR!=4o5u>Jids$j;Y4!yhq_$w^Sw6%vmPc(@`6xm9)R
zcGfO4GO_3jH!9aU@n`0LJsvjUkMP4+gfafhl+VeT%7t&hQ8}#HmRxCjyWws*Tn+%7
z<UzBVWwr8*I`uxms7eG7`hy*-?H`id1V_M3)qKK1*@V<(Vc9Y&;N05Cq*FUYdmAHd
z;B-pZP68+oj|Js$Zl4yrNamZmW2&BxuddmsvGDz-X`jzve$x;?pNfoZp`My#vTf~3
zc0J{8DbpUcSjIk6=_}gk9>~P%`Ap@#IgdRKiy?>e{_BTDwXD>H)FtoE^6Z+g29Pb!
z4T*Qaw;~}$eeG@b?Fv}P*62B#TFUKsVhg>VJ#VHDSo^E>Dc(>K-6N$#!Ch3vn45GB
zmlQu(agDM#{bu|{`El_M;NSC_U)^`QG4Hb`hXGdmc6q>#Bb&RkbuW+aB4^LHs{{T0
zVSUEJ3v>W^fMIu@$wTBDfaPQr+M8$M(CpUNvK%qOHLFuqePp;kY68@~Mq9LMprK}p
zlZk1xe>rLUaX~nkH#nwL>d<gO;^E(cDN?dyY~Tf<Nrm}q^=E#`DbS<zBosc7^VA$U
zVUZYc=YIoCWiG@ND-CPTXep|y>Zxc}tz?0EBC01VH3iGaw94vM<0(b)HGlS*^4&*d
z${(!nQyu2aoQjKDbADJO@NXrT;t3|J<y120)tbvj1a-Pr-Az6@EcFtkUWVa)K8Up(
zxp~K*mGM0K)Te^n;PsVJSFNi2+x|l&ux7O|%-LsrjoMn>G|xWDZMBeRFLVo6^;c2X
zW~#E;)w`ON0Szc|wbfFwfZsZxX*9J=P$mdB#kOT&PfD^X%BX3cr>`U%L6MsfTHejn
z2Pe1zPQWDuTPSFv)hf66y;IcLc`-B|k0DHWvz4Twy#?+(87*|#n>%&It{^y`2adRi
zM@TE-$k`yCU(p_f+m2s26oyBGP0yEb`ROCMh@oc?bF@PG(?2JW$HhALgN_xg<9h#b
z`!p#^?M|QP03<9Mkk1vmZiYhwQzDW&I!i>hZRZE2mCX8WJpBBrM!(R6?$(-jGg@y~
zJV98AC2r^`eznlQ-A4%!k&3$db0#+RB*HmT;~`?zu%vE7$5{%)+SXrjuVB=-0S}MR
zN(hvFf>3WBhRKDhB*M~8AHsa&z-x8Ve!-;diKlh3xA+w4<}7!fBDWMaXW<BFQoxrn
z{FNIn(iMRrNNwktjBZt*w5MB9E`s}TK7?~v3vv8X@XcgtPPo?G<hwlY`+-A|I@)~~
zJ8htK<O<N&&6dMHWUv45O@mhR)?_kItMx>>oC_J^dA{v|<%h#dP|QZVYeC8+p4{Cu
z^PFwHRFc3MU7_FZH0Iy_8m!te|JHxgkhl2r1isApRwc6$I|2CB^sVo~okWsJOkV#}
zI+NJ!>AtWomUuR3Qi~14)2#>W`boWt!M6KRD}uek`|KX_buEPg8O{s_h(SGD9&Gq-
z34eDaba;_m`bL*X98&}qNZXD;c&xRKK$j**-aq}0A<CRko_*nW;@3yf$u5|aH}k6x
zEz>jNkHK=oFM20WOD2qSHrYi;90ulUVSGcaB$}7z3atAlkMfB`4pj{fiSP{EX?u-(
zP57MI4@tK(7q|<1wF6g5NGIJ{)Nw1nO8{3yMWrGYXO5$dzPLc`_Y8O1h~%6><%k5{
zH<}WvzpcH&Y`e>!bos)O?UJ&xr@h=LYK4razh9yxK7D#umE?5|Y9mbcb$CBE*gy!e
zv9ErkupqvI4HdswcAS85yBy=jLGC+RsD1uVkum38lT4O&L;A51&coy+tejVH>^r-8
zhHkZShGzKny~Nzq6BB&PH5d~gR1aXjDSJol5Bs(09_RL1%Aj69kzR-6^lzwLChphZ
zw1lgkhd4RMQ>)~TUNHiHh{ga1c7D0j<kC<XUt9B}3cK3`;3>fKO9YNFYr}RKV@dTw
zOak+48Dx~@0MeqqG@Y~PQA*;cO$V2y{t2dtwY5+?*=5&uN{92(U{of)yg7jV)VvD*
z11vDLyVD%CsE9`H`l*G#I6pwxGxW)I+GMPHOto;SV08FWgJ3tUe*Z33b-y+tQc(8Y
z=io@;*3PkBq&V@LHggR83hj#;^QGUEA$;R>^NE)=`+);C!|wNYwOBouH%r|Mm(&5&
z5IzK;Om1m~tKD8dt#|RVVB~#}YsSYBqd97W=5g-!s>@cvT`HBHW7!iTB=fu9zsW3!
z|Jd-wvCC)V<^z7wrKSe%5^;Q&1$B2dVPCFKP%zsDAc9LKnchl7f~?0Uufzh8GD)OT
z|B05z8#T?DWIFTn2V^Y6y%kLVNe=bn=K7KS>;4&YM+Nn3d?0TnUiW3)QVYpk1ksRz
zp;Tr(O~?01<W{Vy3AM|HSH+%#XZ*P~M?H!QAMM*CK9JRD!?Eg*_p{I1+WNHpb_EOz
zQtzwDVwFM}O3asB{oTDsIs<Zauw!vDSF*66fDjcS$SA}2#a$s0EIfyk@VlH{T|8%j
z10i+qFKk6st<+<EpSvqLUS^P99tsQ0PK`>+UXDbV0#&mFhsVbEh$a(pEweJLz(h%)
zv%5-Su}Vas1pM_j{5AC+>U+b%NvlB*Q<9vzjQCKcbiPN%=)czFZG{QLE`ZCUKm4@_
zvLPc=eZ~01#PCuOKw8}6@jQQA=Chw-9RBNkbR&Gl;daB=zt5O<ij#M-9&BRrvE0o)
z!CZ3EcGPY3d>rO17?ogPqS9kHi^LND;c6X?7|g7Tk0erRnZe0zV#LvUtg}?sUMNEv
zZ2tB0P`1Z$Ila(*hIf5IOf?3`3c(S+-`x^FDYj0%eu=TQf%h{L=4rNUvKR^o(W9|)
z6e@vSy6t*MbT~3Wi(I0V>z_IX@jAW*oXo^7tn)fbTI*LDbkIsm;F*h7&`&4N9kt?M
zFuqe(<1~1bH5YLAnbQ?Vlw<wU43XHW6Dr_HuXa(zHoH<&f+SyZn?nw380*zcxrFq0
zPGPgdjD_POY<N7#P0Mbqu3;QQ=qbXUGb`g;^-I^dt=^`peQSTrFmy$dX+H65{-=t}
z31qwi$${l&M<On(zm2x5PxqH9%F1hvzGQ3f)<Ai~mvuB>O;8J^+yC`_FKW-S+h#=P
zBjj{rbJP3{0KQYrGwP(4cbqsqh45r64xZZc5U-|MB=lgHZP5$wOXOb63(h%R$*Cl;
zIXO+2-opcQFQf!tx%Xj2jygIRz8_!47r6htHp5FIunxjhkvj(!ksUTmp7K-c0f5f1
zKCL`a!d*CI8ezuO-NsbG5^&ouZJhX1;&M=OeUD}{N$`Z0<XRCDIJR-`xs;N?*>%u%
zMJqehr<#a4IOE6GCECiN$ru!N9NRpt<k`pdz#PcvR;Otjv{<B5m2Wvy-z>glqOj5w
zLWu;-1jy{F64;`VurcsnTy7}=7bhX(p4WCm<;3K$^9@f~+kpd;m(3aJ=rNStWnZPw
zJWm|-d5jp62@)y0)4n!*{rqDh_b|h93CVLv)GW4$m1&IE+42x`%>@JaoN%>Y2R;LY
zU!!-20pfvIQzkWVRJP5MCpsjP-f|0;66J3Pe?V^Gu3uk$QJGqPf6IjxU>xG5YdX!5
z;_Zo2J4?6yx@4-(anhfok`qY4aaQvbRuzgyBp0Q(IeyILNRuy|-oJ8{A$j{<WKA%U
z1sk~&#JI$Q-;Sm6UVeW~iqGftO~GA{S)+0ru4?HRWCMnVh75e}seFaIw;iY`DN%{I
zMonws;o<Miy)x169-KJgfEQ*3a+Quja#h!o6^rT&9#g{PEU-8LR(4u#73#oR$9%ea
z1fjk2(vI*;ReJf?TxA%|gFEJ8Y`>3{ucLF$u>egM+o9K4bDy^q0IO@m|EDkzi%?2!
zVeyUeK4NRVsb0Y^lNeSpUOKXC7~R7@<v@tGZ84}uQ*3q^0rXyA09*;FFxY}E!=5M5
zAJQYHEGfcNX4UgTFMpJmX{KBnJaHB?PUC2mIj)10z1OLaHzJzw>Hj9mrTn2X*_j)A
zNLXTLmn$htXeU*Toe{+IJzQq3z2O?b%}9UG!JNkSD)-a39(cJ)v5sQC<oL41+DhD>
zV2d6|XdESM)9z6#r_<4^tmE~E1NQmfzUk}pa5Frjp3t|56dIAywOZn3;g<Uj)f)iD
z{5~?Ze6w$j6eAoDPs&4v^58;>xRrQg7_;$x3|`l_NW@h$wqrOyy-Kyg+-+CWdqg01
z)8uupy`=1I21Y-GWOXxe7StHsy9$|q+59!ijTq^ZRw<G(wJF_o3wQ6%e|&t5;BPb>
zPp71$^m2LA(hrK8v_GD-N=Qh64(i_jtl+y}lMQZP@H+1NApvyz{_*5R3>1~EmB6KT
z<V#N{ePzkNT#fUJ3o`_%X$IGh6P?N+6t0Q{!Sl=M5D%7ki61hm!1me)T^uM_iPP56
z>3qEDJ&Wn-6h8L`O&RR$?4ClJ7*_FRw>^^I^<CO|L&N46Ga5Zu{UC?ju!?zK0a|t^
zJs4CseGik`S%TrlqZLI9_}&HHX269-UtQlkEj3?iY&=L8rm8GoUQZbnP<DNa`#%GT
zG9aERvjp1y6(XG`TA#+B_#pB?bSZ!18$D>e`7B|1c3oB32Va?!r;B49AkU%>xHEJ0
zkkfUp%#{D`fy^u<Q~#~o*xN+z<Xt_zBQyCN9xi}Bq5}KGT({617&P_t!=c_QgN<Eh
zL`KQ1Y;M1$a8zBi)_tYHSVi6-BR?6-$7uZ7DAN&xMYaBT(S7UE<UPQcnKeo$@Z|2*
zd*MIkjuv&L<5x9iks#%%DY)!dK@}C1SjD)eJ6?a4-5d}NgUc9ITKSjgA1;W;$G%e0
zf>)hhrQiJ&HA>c$!TCHTH6>Dmgp*IT*7Tarq)MQoBZpFmsZUjFvz6}mTB5paNH}~n
zuP<(=f<_h9akiFm_9^i@a;@A2jR%`y@$$~Mt9_gRlUzc=Z@XJL`PO=*jkS)9Y9V;Q
z>vm$@jy7SKfZg=zX;=94UzBXOH3`JXpm)Vk)E-Jo$`J9K|Ded2bQ%JJg2sQb_9)zY
z3$7f_%pw7IoQrA+v$i%%=ZYuG0li8qnL@4CtLTvcI%V%03Nvb`lZ9eDSF~}du$GS3
zJF9&bFq?RGH0R4=aCfU8*M6_x4Ogr2TG?=o?llrv2(uWK@|juHG<iiHBX!pbqtQTt
zob|FIiGtJB;12^25Dh2vsa&q>x6_Z0YQ5^ps)Xq+4o&~`?e6~YDV~HKkW#_5-oitV
zx70Ws#@j<a#0gBjqx*=Pg#hGXInG}!I2IO#$<8M`GnnlV&EDS|cMVSP#F{bd#b8OP
z?2b=p<umx?bp2AU3Nu*bvOjru+Td(X?>F`u&2)E*P{y^Ao&$vR*+9JM=84!T_1l(~
zaCxF0qtRuz|9^)gk$ebYchq=w=e=c0buw4Zl~kGB++DO1&4Ms0A_xphj_S=*RfkFF
zH<T!>-u^DHAF)N7iX@1|wIP9J?Q|Tk%A&fUkVTH-?n6z+**vXrpO(6>n8I?TrvF^O
zn|SKjcJ3w#YSki2=Vj_*ypFP@5l<}{Wg*g4A(Mv%jK1mgNJ}@p!t@worO=RD1V#8N
zboEWbr8=j*2@p2=%}y3wMW{K3I0(=a&-vNw8jqhph^uRwV0<d7-+WAAOQ;<D7GJoE
zlpXcm@9bNC^T}5!W9+tpBMe9n+@EFkpHrA$P=n6RLs|81JZ;_P0G@zu+-B1aj@v5<
z$8>2@$gb;m_znaSa&$Z5U592LQ221w`xcTb8TD!46$Lc#me5dKQWA|!=n16Nz`yFZ
zx-gB@FsPRmm6Q<jITeX!gEo>)#xQ`ekt`)<cJ8f#cW={+g0HPj&C_)hQHIw;XdZSw
z%{kJVMw9?j7Rg`FtGx5v-Ap&drSt56E8*WGZ?Wvv&?5ki>6OKn>_xWIl}CPME<ekF
z!9xU5Ntuw?Zncl`s3$tWiM{LiOf|{O7d@aUPJ}`Hi~OB{{P-(L_JA1lzH?tv4sIbs
zepD_3L|9kMw<rPKc#;o-a-wH_@eL(EZ*c`~39Qr%vARg$et56a?kPL(&bcgZ=DtDd
zcndwiLJsVae7oxj1%jf8efm71QU=x4UeBLuAvWq~Q1SoYvQ#E#thSPy?b9l2?6UPJ
zTl^MbVd2-*fZ{if=44rxm9~@Zv0*mD$NsVe2|_sEnJO_M(X^bg@yV@%8&CU?`Lfi|
zFE;b(GK-!!by94;4}FJI7f6$x-n+}fr$jsa8Ur^d(;H^(Og{HGwV?@&X+EsgF4M`e
zCNYBB9xmEXX^lj&^kb_bf78rQbSH$<>>kJCFd_?LCBXc*!)#uE)udy+iwMP!>X~+S
zcFqzZ_Z0LH+>hlM{ioq*A6;BZl4ai@2*AOAFZ}$|2nXDhTtDFMuIz+KsaPeF=(eAx
z!2R@U8F}w_t?;W~-U`}a(FMW{gan45cgNi|P2wjxxEf4o{s%$#gn9;cIY^SaZzby3
zfLICf0MaX1ALVH1?`O(21DM3Lv?s910S5<1@a1k30|Nt4uhf5@l4X(06cS`&ihu=x
z&(OE^2cO+P5D^#}PcZrh_kekJP~0VZV{a9FY^ODc8vUxWTZk2Alxe?5P<Vi6ftorF
zta+f!Uo2^;H$m%&S6a<H1F87rTud*n?h&OCK<vQhGA<w>Dzg4{wUH!a!u!DYiNY^m
zTenNwPdlCSs64(7CYRCOzJAl($G<&gAaK9Y>Er0zKgN&7^?Q=%kqd|TuX_;zNKb64
zR&xu@spv78-F9BSj9=orKm&|Qg_xI?@85PUysyM26EJZZ+z2o$kZ<Ajx`V6igzgm9
zn}Ek7ZFTigoF4ETrdL>e_a)HG^t03(1-Cz~($%az0(1uMmkJr4C=(q|L_VI+Bb~{@
z=1(`zZyeT(GZn^=Lnj|92}S-#)Z&%hOK+;sk{#5Vr0}=n-8{kssFpebmKr)%V7~oJ
zqP@=O;3qPy>PDc|D)Pfb`O{o@*lxDmWDmS075D~wU=<DH6*U99#}xf@eLpKvlW+DN
z)|Xd@o8A1lU0?m-{YcnYvCB?_FK1w=Q~4uOj_bs;J^foR>*n}vlW;xU!b%#tQ3tgs
zZxpSPN?M<^-u$u_83;XA@o!HZBdZVV%Wq?IRnRHiZonaycMQRy7_$u6x|E4?G4PzO
z?3eP|zF6UcS+xt1C_Kt|<vpy{on8Lr;|GeZlBF6G*^0{f6McgJ8x-1e-umkwnH~ql
zIyTKF4_Et7md!2W2&c^;k%j=>?m1<Ee_|07^nP%1aJX=8;kpJ<%@#UNy6AWV4If7;
zAI<-cT5!94G5Ozsg;r;Z<q?4Aax!);B=z2#Ul`*3Kam<d#;*ggPCd^04JjhqE>erZ
zY1MF-hKz7?SB}JWGs9o4JhT0JZB(aC1(s){OGmCTZ`JjSMEZSS6qJ(eaisO`SmCAa
zrl0iC<9|dx<a|zQhwGAkJ7h`KZP=i-RudQNQkfTBg_ZGg-djU<xD!4zgsJB<dc#!?
zDm@Phb1!u3A5W==0?+cUIvUp&xL|G5<>Y+Ny4!<G^r2VR1E<qq1a%!|`Yf~A7&S3o
zWP)er^bTmd3q0l06~G}0_GLP|dZEHZ>O{x_-%V<%@4`6!;W_m2I!{PcGWFEd3Lk5u
zon>*QUMEfbI@q*N)%))eJ<mtEGvC3`Jzsx*&PN9UjFOQamnrdd+sFpahIDi73ni76
zQ6fsgt&0_P7)T~$U;0m>uKCP0&DJ8O_rAmx5lZ+(nr=<y*I_}65QMvfE_<rSgMNjK
z<tSOJN>|`+-S=focMsp`R`_f+{|r#kUy1VhTG2ZpEB2gh2Cb?%KjKZA=H;M1xEHn+
zSe-!?p+|X!q^wdGQoEo%W;~w`0OY8ABn~6bD$8iMcXc<T7q6Q&*Vpf=mmf$93tT8W
zpgUWCBYm^Y8G-oubS)t&-b9I~F{Fu?#`BK`bf;vlUl@PZy}HkdI`6f{YkZ!$-cIf>
zETriLAr{u=wwyyFuGcjAWS%~%X8}5rh3Zj0=v}mvebf+NTlsf{ek$BWi@uLTeYy~$
z)wr_MxJ|9_HeMs=!2J1=`?>!HuAH=ZSoAbifLEgE{=~E6Rv28+fy+9!kIoyvib4CC
zhMg@nUu1Lw)&ImJs`<PyQfwU@n0Jif#1Zy<T4oQ#dgFE)ffd@n!cNuEIg6^x-7=5&
zJqFMV1=b?0`Q^P0PM!D+v~Mf3va(R-Pyi6n+4j{+ar0l?l_T>ZH+a?SG3NdazM);|
zw=Fk6vkS}@u@-q9TX^FI@|Rro%I6ijdmC59Mr&bbd;LBa;nDvYJ2}0|+5fx9?V3o!
zXa3Xb)N9-ucU#3v3f+&ED+Hy?;w>T`jEJ#hpkPDx(z*ePaRO`MA>pTRhlxkfp6xxB
zDwqJl8U8EF?78-hxgF7=T&shY^~cUSx~La~vHju!LU)QaNu`RthWMP1E%XPb-_VZg
zg=B1~dERMM)soM|vUXw73biLdGC=UUaFu!`YlrM*QBW4`%X)X*?kF1O$afbW!lyZc
z<&`OPY|QDEDd6fJNnLQB%AzsZU(?-lWaxx|diZmryh71-tT3OAK6ElO!>0{2%z4?Y
zDU$XjE{qT6Aq=mqJTAX+Auoc=?c*<5zxinOxwSm|v2jjp_TAr6!|f9s(B!#C4HuJ;
z&Ej+6E>oCzjuO)QN1c^~HK@1F79VFq%S!+{<_Bb;0;RpOvB`-wY%jqwGfd;nCZ4OL
zco5VkqV;yQ&;*zDoS-`xnjTbX9MygS$#8utAokq?n+(7PXjOD9;SOQz8#Rqz0`(~@
zH&s#1Y?Y^OrTGsD;sY9&CS;jyJaQi}6Q6-mj7_q*1k*JX;urMjbzSL3*kwA3Z~@OF
z=Q=O7^FI00s3_tG^oGh3w07pG4yx#q?a4+jjc0XPNGeNvbLuLV2+<(b<o^*Xnt;FP
z(5x%=B}ZN0vh{!GG-8#XZeP47&N_UjMm1KF20A*RbszY=l@lv_PmUK{$5w7$2C8Qt
z6@r&z*`Eu2lyB;eYb%OfA<zlI*3Ht+u*@?@#8&xU+fM6s1EJ>+F3=ZKqpK$AliQ5Q
zR>$?s)s^Qf7V2eRjX8rAU%}6R`7SCJEPlN_jlUH7W?xq<#$5z0`P?rTdT#x$+}bo1
zb7Mu|VWYI1AUd5f{`)*#3tQ|ltS1cJeQfn7#=Q<OXhAD!<hpX&0ig$wvBki{bA7ry
z4+%jG6?fRrcV@M71r`?<2?+`NBik_*G+S_WLkIkFHnU}&X%16UQ{t4p${w!OjSlU3
zkF?e}g6%4c%~wL(8x`Qpc*R4}f9iw7gS0aPtM=bsV@iDZ8$DGXQ%^klHUJ4S;tNv;
zw`zZ)b@!i{l=PCzye)1Z95XvbEDUkajl+U7IGVIz+qrVFwVw24X>E7Zppf~QHR~VZ
z015130p$Qoi;Jr@8Nv3l+uvZh0qmV;@f>1HwwftYVr6Ch2P>T%81U221^|6D{WoVy
zmAy+plDMt(@3v-b`mT4U;QSnS$5~OupvM1zA6!pFt-pW&en^>|Zfw&pnDOL$p0_<E
zn_u$;+%g<xyo-JAW^-pAJCPZ2e@aodTvU=#gQrr#7bDecpVnu*zB-H3L?-F`Fc3j%
zYwvv*Gd9|+54P7N=Bt3b#@A?MWaOF!D~(p1t&7}lH&GAqFHrF72)qw;Pf9reSkwn`
zhUkw0{{k`p`~yQ94y>l(2W7+m7xvyds*Xp`_ADF{EVv{%A;AMdf(J+-xCHkEcXv5J
z2=49yg1fuB2loR6cXyj2zk7T2?Y{5zyqWIRv)-Gv_#<T1q3TrCIaT%Ddw;gX<FBmO
zFTmxv|Hb72x=IL;lcY8#%z4P~Ig_QHQ8vvMl7UMi*H)df0)D8n({l_saA77fV_Ox~
zYHi-WntR{>tVCVyx)za4m1};>R@pR|J@(F+6qcM1%w6h=npW6eX5t8%JX$M2a~$_&
z#`wdBmQo$cuWycxt5g5H9CH+@0{PKw`uELs7S31yv;6aJjlGv){h?qz>f?r6aV4MP
z*@DY?N478jAZ`6)n%N5fOlxLtzRnrK=<)crh(lK3VLd<7HqN4v$C833mP>3rJp0PT
zKeip~cOyi98Bf67@i)H*GNCXyMSgsrper-&pY6B*$_0g$>S6w@d$k*M&)Ut@biF|x
z(_0Y<{o7%)b^<#xK$@{KeGKTH^nB$Cx!!DTZPn4y0YmxTREVI&@z*gR0q1TY*OHyx
zp6rQ3tvZ++P<(|0C+lcqV*>^-mFY>Qv2D%%WobmlSg@Mq9Se&!<mE#R7pm|wOMF3T
zsVrkG#&@v$?JvVmSbs)gq1h4$>oEjcINW~>^|O5kH;XYi6CTi=g<#F)=@k1)!1WZ_
z*Mp~fSigk;_a+=T(PPSwVS4en=N<6yyi@P*z-cI8%IC-&R>sa(I{Kqn<qk?CrqbKl
z_~i{5T>dsWZH{*#i9K-#z4E&s+vLG0_5$>9`H0hjsmfwY^4XMm-h=QZ+7k=2+MXX4
z8F+yfMYK4Wchen3DyA=|88C0&z0w+7$=@6W!?guv)fxJ&AwW9p)sx3F=+)!J0em;V
zrDx6=5Qy!sw-$HOP->Xf!kfCD)XKe9V>XXBC?=5U2~Wc_v1ZXr$kgOrudCbZ7Yhiw
zc2?dC3kc5>(63T`ckrQj$Xr8Xq%UF*kuO*<pa3;@y%*Onq0M8Un`Xf&q(`x_&~Y#e
zi?ZX3u1O|gezm89UB%SrTKA)@<g-n@<?%gDnVL@)EJD=X^B=bQ3WE1B=&#FeGduMZ
z%W<t=>l=0uIuVoa9N{=|gchfZdv`)qJqre&<;@3cN2gp5?`!7Ht@9bz;%w0x+OX;o
z=5r(Pf5Ws+E{kW>45(i+CYQ54T{JD3xREkq^$gyb99+@n-jX`VZPTy2td&6ye~t{p
zX?cd(d6BUPWB=>LV=Mvo{i3F*-4+bwVFMYI*^y!BsXugPIy(-Yltw-7f6qd!63C$P
z1yudu6f>|@-!>@Mfhd&Ughko&+3VN9={~CK@HC>$-H>&8MT6tryx8FAo@-1*C0*<u
z*zzra;HOg^H92lNtL-|{K>PJbzo}^<aHH^bH7qa=AyE8UI>c3KI&uAiMOe=^KPRy~
z`YFkRZV8-ByQWfJIUnU<YMC`FFun(^G97%GF)#AcZKToU)E*Fh%|RS68P%LU`yx64
zL3^bv8o`;43<;-Xaz||NB(_k!;VL6V%2MR==f&(;W^2r`v;6z_gT^Oi1r2-q8Jb)c
zlDQYMiFV(w&!jimi%Y2Wi<=W3v>BQH-}_kz25FH0e?QBA=x3n^5S&>dgiK8-DMSjI
zPF0uwxd_fDzf*>p7fbXayRPOjTD}Nb)qZMThn{tI74QH#&_+GUT--1)VVzK@Ag0Hh
zAlpzlpsrb#=G>=$>qyV^miNXo73AxH-}X~r&!pTX0pCGca8}4K-nQ=SdwI=*SNA~&
z_S5Iv=p6=pRMr;@rq1p0Byzt|Er0yJ)Kw^(a+BQ`=(Li)uDBWFdCf|i&}pHzo5MM4
zdE4%g&6||hAXM*gU^2Fzd*f_SIfc&EZAB4ocz1mUR$12EozLBjZ=h2FprIX9szFyv
zSAKC*o#WB(-Cfh~I-sk?8^rJLLtPG%`8}E>UY^Lir=p)<KPH=aM}^ukKApf#(D!e{
zl+Ku|)n<+tAa)!Q)vxpW;0EI35bPQQB}8_KLB(|J)KV%>en=D}{TNZ-9W}ZV4?~qt
zpYF^heD`~Tt<!|vj7~Lw5JuYvr=&=m<8_8L41%ud`EOyNebo=$nU3OV=q(*IN(ICA
z!@=?C(PnB716k1sTx&tki{VDnf6lcU!R#`Q!8uy_u*((<kGK8MNYh@3{Sc|YS4UGh
z`wGXQU!{lxMman(oYvdAXnjO5iZDnV2Ke%!uCdAW8M`pKym!PGfdbJBo9~sp>faiP
zOg~lPFFaN5+|TB-cufn#Y&8;acES~+`aP*3h)eBz-r|@?%}YPQRt?B2SWB;ZU<f80
znd0>lya8z3w7EXP>}_Ea!a*E@1t<uYYQxRork)(mxJ|CHDiPPP`%yvQ0nUD6v~z<w
zBJv0UoY6%%%5UnlYC>x;3owB~?gq}npK{*>lJZ>;r8U=>y;0aapH!vztrt^KPeV!7
zB>mdVAe7{?qygbL=u|b8!6>K5Fo1xUA#0`Rxb%r|z7FF-?ixech(YL92G+dyd&!rL
zJ_<1Vm_O2GvbPPVI|FH+R(@1Gti%*BMpb*pa=lv`kn?Ts+P2Gi?+16XRBXS3iptf9
z2&rTW&lOnK7Z?;Itj%<_%?47(0^M%T%@*p|UcK7%!Pmq@hR5<>1x-(IhwF(Jv^W7X
z<pwveo28Ll?!cS3Fp|O>T~>b1Jzg(!q|?56Ts51YysIq#AMv)#U4>dt6)jXa9yLmD
ze*QH97nZeJq%jxzPaG~H>N>BNhczi47Hm}tOj#$ks$Q2L-zs#yGce<7qEfgv&HOqX
zfjpMBGQ4lWYSl&+&TF9x|2;pZ!F0BY86`c$rmu3X!PI%VG|^g<?|!%Au;I?$^1J~h
z?NfCK3}7-=RV`_egilj?-mrD-x14P7%Q~*ISE=Ykl4<wWeAuaX-0~*k=A$4{Q^}z(
z5mH6s&}vZRh9T%1T+N$N(j56Y)bN_2so=MA<Bb>mftACs{fvRu_(y4pdhS*koi+oc
z(X5V(*K18~xOjH@VyX>IZSVwj)g9VzgB4uN_pF^8-`LI0M=J1wumKM0SdU9pML{A=
z*y+B$ya?8fNmBk_cbJTfa3yL(pP!?J`~%u%vygc3VyW|s6=;WZIcNlp4^1MZZnoRw
zxmf<+9&)DMUAy<;Bg2F6#?#G_+}vD5Z%>`LjZ_b4q}~7sSLhCT!PDr<|Ho6Fa<s(=
zH({bQ(6f0J&bp&yV3H09RK7hK8NId6AOuY9x}58k`2=T9ewtUxp|(JeHtHH)_mAgx
zwWWJqAA31t+kSt>ylTj<%Ug~vt18{skt3Dth9|nqjtLzT)8hu}?^?Z_$q<-hVpNqj
zHVoFxgn-a-oyPl}aE8g~7H!Bhz@{zXNlskv>Ey<H^1mtLW=AttFSn4T{OE|q10VT+
zz_!VpKT}0$*0Gr`5Zqa~fUg&q>9a!`aO3^zSpaiLh55v1V<>s9M5i6JGp!G&rba}-
zHs9R<_%NZ*-yLIkT(;NQ?SNzD9vXdu^)6zI+l2#nd{R=-bRqy=Fz$ZHUhR;Wa9wBR
ziV<?vZB5+5LU24nQOgof0Wy27#psrEC$X`H&g=5P{vdWC|J*FcF(S8GD~0>fK~(^P
zQ=&Sg*q`1&+F=B@UC+Z&p3Md{oKDOc7%FhvO<dn1Rd1r+`}T7yb+qXpL8F`XGg`M9
zOKLhkH?2b(8W?s0ub%^sL?FJXQ*dUhT}osRcW$#Dr)+8DOCzCihIwmDk?hnumRT&X
z(+Y^B0c5agljZdqcx`(MR(pmcMPPdBDY*_N+NrCpA;{`;$KEmcB&35I&h~=B5%A>^
z)U5}#{Z7l@3U&3BBj9Z!W+L98@P!t+6q(WNQa?@pl-^bGc4NG-P#iM%0bo`bonjS1
zt{r$T08a;ti90GD+lwC6utrjAVJCdSrdNzx$wl_mei37w^jE0lC!5guISI@Fayk3q
zh^&#_IkmV#sn`56(OJoXBtM-BVR8y`@@H?-jy;8eXL45gFWhjKaLA;;0H7<WpQ)M0
zcJmkS#r#PN90uwOu5pj$M*Fcndlw0bf$7q(pvOi0-rcKzjfhoWLR~#+!5rhslVk8A
z4;om6!DHsO?vYo!XG%>R{iH>%+u>6tfa=T(!3j<UTFP9+`G87&3gBYpL8bBuivmtr
zhO*knbaUu7+l3Uvc;XexML<-Lv$vF1!-qthqY(}}y+qq9pZIrMeY?Ra$-I)4_~Ihd
zg={-4o%Df0gngf`axj)unPO;nC!NKUWwRuB)hyu2VnUbrM+pmoN&P-OdKQ+o$jKiS
zU9*M2|2eLdc4pKEKN8>e5h&E0nIKCd9t+gXM4>6*h$CFI!epulGz&7LuGn(HAj5lI
zEP7}$#tz4``tAb|@L3mDCs&<G{-+~J(Sg=TLg$Gh6Jm+W-A5oG3Kh`%UPK3h85S=#
zt>O~8idi5QD}-=z)8M!4clP(u1>2P4<j%~5(E%})<GJDiFaq2AW(Grp49c1Pi=Xpi
z2IZv&5a}v6?dX(Zh<1NP8&w%xKtKO4;AjeO<V&C1m#b9EWeu{&?jk}$I_pzJa`70H
z3yKSRHGV4U4Iy+~x4{BmoWvlDKJ47pzhn}$WQt;j<@NPVR9<ffO>k*kM9qj9g47E|
z)4r|#^0zi^Oarz2yEcr!ee$X_xI<l=OyMDG*ir9%eECB|mEB9;9V~~tKgFz4Da10u
z$oF*_s$4x9!HPjh>aUIAdmD?%(&Dvdb%yJ*GA1X1+s(9(E5^_*rq{=Lki2ZwYnsWZ
zX(K;&l$Y_**LbpkFBA0<T@%%jof$`K;>z)XV1CpXCA<`1*%<zPvGt_tC+}Nv`qN|~
zcq)^(H)4yD@i}Kx%k?#gKQeR6<OuegdX1{t-#?$9V#U)2{v#|ADgRmO{}@VC-0hP5
zI5K;{5x8p%#iNCoA;CQX*rVtIv)9`jofVSe%aI}Pwcz~ZvAKhP9iB{Gz2?>j!m{YW
z+$`CvsiMhfreC;|bWb>r<h|$x&;U`I^}5)Jbtzfg*do>)#i0R?ypxkoNO-Ch)v$UU
z1x;AiP;zRyn9{AV=bKDz+~x|i-}4`!W;>&wAJabrL%nQK`<e=d^z`a_0I;=twZAQ=
z&to)QYYa`WK1;C11_UA(a$7)W$o6>P*|lEXBW;H5%Y_(+mHvJJ&>T8n(6LZAv3|_P
z%0VzeeB22k%s~RK{AzdVs1!?k`W4T%ZZvBu?XULU&%O~FZ7UQaTXz^D#H$eI)BUu3
zlodx_{^eGK-Gb=#qJs06Az`1~^Z8@95Dt<9WMGzv-2XI^?)Q?_-Zw+}=qo*MlkN6T
zpf+S?!uc8{RzQ&H-OJUyPxV6iW6}NjLC>}v>X_OE<}U{{ZqR$ay^Mbe*T&**@cq21
zk@S1dlYII%<Vt&2E%~ftT*BbvQ*QFpH<*|tg>R>lQ9lKFUBvOGyEp;~F8Z>nUxHeh
z`54}0^}8RS4HE&r%+nN85=rYRO@>9Ry%{&Rj3q5o0O%MGSpl<Spiw+qDmfu6?9p6y
z>BOxJIe_sC33;s020g?dLrIcTQ-{lTkJtM1^YXr<zsUPcyM_MfChcfG#U<{avUoeU
zr;ot@7V3sBJ;i%cZO+(3Cm2j3SF3MjUZiN0o6jmlDJ|R2wNb}uq(LvT-9cDOD9*M|
zm0ymXHeE>f3d}YXS0})5|9p}&O0%xNs#h~s(z0VxnLoNXW-&&%b5^28PD(C0+@}_m
z=f7R*1kIxA>(iQ-P14fMnG&K^(jC?aU(uBMrMFOWaeH0xS*4eiTZ{vTVBqDeacum-
z<cLjkIq2x?r$65A1fWhji{b_h>`nyA)#F?a$nC*ig(Rd?d~HMlaEK($L4XEFv5QlA
z8R~S?8xy_ot`<_Z-LO#1Y{PP!x3#%<?&vxH);Uo(Tkdl8ZF8~7W<T`;?Ibz>>y3}m
zQ8^T^`8HstLkv%<IZnBLOQN@|C&ikVo56i(4((I)x`nXm&|8P14N|EZw~bz85&2#U
zaB^B}EcbPK69mirz-(3ChQ|NjXV8!vM{}*!SXsD!Nw|<2E`%`h+z3HtE`Ivh&MmsZ
zL6rTFpYiyI5(itoc6g)*9w)h{$smK|G0-`2b+WN&-OnJH7Pi6(BC4dH9Bb92!r#)h
zL_|hDGRp8l=LA@@_UN2AK0XGyDw*J@KRYv1762fGJicP0{L_Fp8oNNRAVQQfWQcXV
z@gj(r1HA?GAWI4)qp?5^!c~Dr1nW0EFUBLJ#0|**pJ@K}Qrd7q?8<d)S>ob(Fy&~Q
zoTYBYB@X3R8H%MfQA+FkMmrVrRbK5z=%o}tor1$$HNi4S6N~E!0{>!=)ADkO7`=2e
zY9aE6bS*7sg&jTe%Wvv-YE`DaXJ@kubnS=@=i5jadU?}vrAp~_-}|P{C;8r5sHT2Y
z1V0~OUoSQ>@eU2zL(cu;-M#}+u>N1dKj`C4_4GJ62FvGeV=<bGaSk8iM!;Al4K?-I
z)>_9@$UjhMz#*?XdkU~*%<)ZK(Ja`^Afdv7Z7{*9-P*3%f(6tvT-2&|`v#NkaEWDR
zwDaebSk_W{G0_fNfNr<bea*EOv*U4m&4@K14F{a80EvTLW%RHv53vqcp73B_;iIP*
z=ZQ~BHgFUfc<W2}7Yv646$S{Ve<tY1KO5`8{5~gv(;nsQ9))n;Il;oF6ZGjkyO3BG
zhU4>0{F{WUH346S2tY2rEVdwJz`3Hn0>0~9`hSETJm0J=YGtLD0`JuREokQF*yvn-
zmPhh&6PAYR2e_%={WHlHDgh8P)1$ZYH~o<@64W0{0Fh0m%tKFfW<<DaJ<8QG6x}Ua
zPyjoo?2>LG{n4huI0cE}x1`oG`Mb&x>kEoK?gzlP@8~fOr6A20oK#~9GKPX2mzC~N
z5n*9bst9qW!a&cb|4J_lRc^!sbF6;+;1k4Gf|p^w*pG>1{+EAAOt8ak%s~<_14BZJ
z{s>r}2B=~EYapn=7lX8Em%3lKOg7_VuWs4SDd7*dKhvi&WqOKmKMzX+aNR69AeJIz
zg&yzeLs1d%1~ua|Ey!m>G?g?nHr`%i_%*ggO4aD`xOP%7%IqQesPC~LgI4Vs)2gO*
zqDOcIx}+%>ZU)nkkHS<&YTF-a=J9R)qq@Qdd^`2iAxLNz1(##aSOg`UI=H{y|6hUX
zKT^m)j}-r+&;~WGK**!A_D4w)c6d~k{_QFrXD9EHhw>NT!Tqyp{F`$hOjN78S0IA_
z|K{;F&qr{1!u;`t*0`XUcKz&+SQbX|DRXpvT|Z=H^H>DjwvuH|DKbpa%+dS>OzSIf
zKJLd4N-lpzy^+advHyg_|9cdpzn@0`TC5Vbtt9?yH@bt#X{Fd;ljrTs8tm?;e_uG(
zw|}k9a@ni%i;<bx3%@p`oKTYI&!6Mr;bCF1h<^E3*=Hzp-;xtVQz4~W#`fD?pBniH
zzQObX+2PgI)q$PAJ$c_xA^trntq0a-B_t+NQc@xr9*5?)3*azD_7V{jgD6k!8kEO}
z*2lwB%LB^3i00c55D*!@g0$VB{uSJ;)lp?JKp+e4RcRs7xpU83$gXj9;^We{h!x(T
zDWT;Itb7=K-18m=I&Utw7MbEIP+Qi$k>FmNtYFijT_;Q&xTQx$tIyNn!LgL&k)(TZ
zO>gT|zaQ|5hRY)vjnhWzU@0+%G+z2=!t>d2rE^V708bSc3eoVCPZvfn&ch3dnBlBT
z{2P;=9jqU%*&3B7qbknK$(C!20J5I02;in8euliT^=)ru4iflPy)mNY3@mvN9-WZ@
zt{PX85Ksjn>qsrzQ+vX`dpg!UC4_CMQ$^txjBA}KSEW7AGOYRLM;N6L!{n-N-&^s<
zx+Ocix!7nN!n3oIS#n%T1<wJ~N^5AKX7WN^U3xV29GWYU4~`0<++ZXfCY#SgT&Q&2
z$@B0+XEiXmNd3{Tvu9F_RnY<z%nXZjt?zzIa_@}rwryQy{M%^s$S~oNIf<53EMg!`
zC9Fz3<>y-BR$AWZq=iPg>Or@0>(`?Szt;8pSQH(exPzY&E<IL_1{{ah3BjM6o6X?Y
z^hNThJ}mK6VPbcy{b({&-Um!f+oWMqyu*aGT-qiNI1rfw6VWFc9@%3vV7mkORqcwO
zx>8eDSGU~md$NT9+X_BLkrETr;RW95HbdbcTB`$SR5Kn`xN=~gbNGK<XgbvPu5~x4
zRZ-P!a5vA?-?HZu@12eAw<m&m^8>b{L`}@ZnB9!I$xt)8)R9$dali9qGD-~wFcv_~
zFI6^3R<1I>LnlmUsZ$sqoasXdHD{TI$<ZmMn@~v&Uzb*?B?PwZE!3*?BW3p~m4-=^
zC-4{QKUyF`qO8l)3?;8z@)l%sRd|z^LJmJ2RA!5NGpwCud3hyFtm~;b%`J#D+CmfL
z4l>wxP|tQ!f0=3Oh!1FbP(OI0(*KvLN}Al8&%6DF)9rR97p%HpfW5FTsn_%1!9e!~
zW!u7%l0%U3@AliDrmVc2@VgU8*iCiWuLXk`7WcPTEb#+>ndouAOZchb{}vJI{$UZd
zD*PFkvt5IArWCo7HOjBcd0u88#HTI@fI~DjcB7=>JAj@YCpPiaWM4zebf6Covb~@-
z8KnwSd)-?&qnh~{F@vyku5VzCnm8}pv@5jxSa7Ty<Kiki7Q6~rp+R0y_=GN>FwPln
zBQH?8x^DBYbq4$%zBKnWE8Z7yT^FKoSRBmaNZKN&9s-bPL!=d{T^8`y&_6%F_$gh_
zKN!h!lBRN7)fp0yf!59M>M+}$+s9qua?!+YmQq*jpy=}NHH4#X($Gf@VfYe+@&1E`
z0G4xr^Wnd12;jJ|qpM5b;2$)Et+Zv|pI4s7F?wf^Y18V$c{yW6xG#>u8Yii30i92u
zpxUzm%E5J#T~oM;SlRRlGFek_zYH1ew<>N4zWtX=Oe+*G2WRc1jVone?Z=D_i~RfW
zbj1d1!JZCISAJ{EXP1#ih{CS>_DM`S7J!XksLWrylB3tt+n-aemvhZ~=WF8i3TGa{
zj{=~ndAjr*)1NE?R>~63uZ=sKA0r%9omE(8i5?(}fJuojV7Dv;QWp#~_-raYO}s^6
zMFB{8!-%#=RpB!V6k+l^US`3b%rdsmB)?viaIQLJi9|&am0vE~6hFHToWqm%F}EnB
zrqI;?RPVwf`1>Ym)c$<a6Qf^^Y*@7TY$oFSc0iWj$k-RIeOl6dfeNDa;}lgW1+m+C
z93O2fFTuF(sG2hF5;_d+6T7^S?-~t`WilqZ2wG2Jz*|>b@{D1Ud_S?8Lg_z*UB*~(
zdc5k&N-zTJa&vLuaXKObKG)KM>6Fmh;gJiiCJ?L1`5a6#NJ&bv5ul>Bn@*R&yx_h0
zD+GHk!h`V267)ZeX4s{gt|JX{i>m+t^QTY3?>}cZiu~GxXvWunF$t;gReuRybrc7%
z155dudsGveGX<*M`{aP{V!QyzH+`c)7#5rFR^ce=pO&(iky6^G++Yl4(WnxP4W}gu
zFA5peHI9l;K>(aH2nEdbv$uF{*krd381_bS_nWXFsg@Q6rGoTbRY}nw*x0$tMl%yC
z6R)D{)uxPHR6p-*Wc)*LdhW(*ofoYN_y`DG&+}Z!5^uw-4v9L@R7M>dFoi#u*A<9X
z#c$irMX5O5)2<|yv%k=apmnPnEj9S`ZR^*O!9{gEr%psq3I_u$NWa%)H&cs)m+gMH
zHfycP-gr1I`HqRy!~TmS)Sa8t1^VsRPql6UQfV|dm&Gv@7^&<6wRP$^9AY(mH!!<O
zH+7YTZ|`2c(V%Nw<JRj&Nsgwad?^$RH!Epi-PLPT@h2IuOIK_tX8?`D(^9l5fV#c+
zx~Qo)sNXGTGR~mMT1eK;VO}nWGm-~S6zj#NCxKk7)C`(hI<Tk<YG0TWx<JIQ{kukJ
z9GBUCZypI8WIQpVpWl^%jvNgc##B#Fp*P-UCzN#49T`6sW}3l(HUzP|)<bc8djxR>
z#*7pWfd3VI{-`Vj2M6y=6+i5j4_jMX%gM>z8f@@ySKfjFTE4r}F^`+M#ebzNxNhfW
zg8^D3X{JRC@Mdl++`zT2U*K#OmzBlYeRbe^VkY4gAj2@|TJg4d-VhN`OD=^n#)Qh8
z^W>@(;=moA#!jtCs$@yA;o;$q$KsDC{$LG)kc*U)@5I~rjXKM{{AjnmTQ2aW+Ve0)
zk#-JddJh9{9PTxwv|_xDi=Us)g7}tCE_*6_@3AEzH4x;{q=`<g8cylgcHa~xht`Rk
zjv0NhUfAEGn~Gz>FRX~NEo|YI!bE{qzNdIzXQ@L46c#y6&PVx->{eNrm7k~3Iz7({
ze?#rNU0I!Xx$1I0k?^tWqv&A~nqg2<BzA3fmD%KtNK-8?kaD-QTC|);jZI;nTrzl-
zV?Vr-yn}l+RC${*%PTf<d_$pinf|O!UR>XIW8g)lQ=|J;Iu)+QPn6m`2?N#g14ZEy
zKT(AV*FC1pqtz=Fn`h*2JA>Bj@#Dv?<3??}W@TlQMwC9-84NA{v}0;28&`~<xpa(g
ze)^3z;7)?QZh6x)u5`A10%?Fe@7t?$k0!Z&=R&W=l6R(xX=nQ`UJKN(*6QHa!E_vu
z4LD)Jfd>{0$*!dd`R;>KF_@VAn+9>d^dD*vTA>%SIM0b@+zfVnJ`S_rRbh@A5Jflh
zm1JdDB;-Y<Wh812G6AAT7d>S4pD=(g7iStMrm5L)2h|Gr>uUxKS)<~N12_stVu_X3
zm=+2U08yCyHPcG^z8j-N_8(3CHmokHa4q6mjc(r+E9I36hdnF<hn75Qc$nECK7*qN
zw<(B$oie2|_SYr<&CzG|Ylrv9wN&V2UbrxRPqs4qb&<rN)}iy&T<JFnWm5sFFTxP&
z50JJoHoLQaf{|#mm&l!%uj>syjTxTrF$^eXN0H`;jh$b*#{IMGv!psWrLg64kz68-
z+aMiTvE-bcn?plvueI4&wRZZGc_v$X>eJ=`bus`|TQCFb58ff)95ge<_HPWtuh7&#
zL=;mN;uF<(0MI{=*`oZHq;pmO(>yc$lKU-xzT*3=06}{klYY_hLAAzpXs(YlD}TOb
zc!aFQudTppLmNiE>#QQvNXBMnRvL|Xx1+1Xe<m9p41arZ0E=sH(wI5)N<J&4kOLO8
zU&L1YU%CvKMCMN1us#H2L1pro=6`B5Ji`}4m@E5)UH5ZfzD}jt+C@L>Q*>q7R1D33
zQkTJLL=&7~kKW5wQ@m$%E2?$s1)KsMc6DC<^82auSp5KcNLEuej&;?`XT&3g>4D1b
zjtI;Nlx-LB5;uT0$QU{{yaFQ#u#i>985pbik<mtjZ&nW77mhk-nsCfqyuT|SIA5Ni
zd1a7p(6z7ux9kthGQRC;pJ@$1ZQTVVaFdR0HM{z@ljA&j08!<<54R^En-ff_f`#k_
zAd1MyXr{r*MpRT(Q85PW9kJ?}dU-(bL;T>eZw3qbKQnk7%VlG3-b$-+pCwmmnqvKh
zT{-tdv081}xVCSRL^*H$MOGeb1)_$hdw*F_(v@9ZGC-!}U`||j-^>5B(l>Pc--nNr
zBYG=7JjL6gGqJ|cRfxBNDQzkNAj&CNOAcv+Lkw@D*72kA*G{71XH*pfxV~0OP4Vhg
zVI>TnRN*FCUmw#CCLKPt*~hp^3Uo}%Gn*QsOl2a5(Y}J$lUiOLUZIR3H63zs{J9AG
z%}g<0c(#3eImL#-$+hB}9?XVyQ6|P9^*7WKZ6|fNPUvL?j(q1)po@=Of2mwN%aDtK
zqdJRPZs64XxNXCB&PZAUTfX#b??*w2`pD>YRv*!#<TJ$T3ROW}ddR?4`K4Q(7lRST
zAl6g24NRC`u$^SoLH?!jo!up45saZxUIEVcdJF5>LP<=d#{n_R2VZG2Ok~awn_6|S
zw<3kh&R9?o76dvkZ|rHqG$E03aXEvGDe(S^h}YTH-5unZ_s237|CJ1t%YDuh2)QEo
z;qvDoj}jxucpPN-Jkg$Og}_44*7|<uURf4v;u@^e!)pJU0)CHoNKwAMy|r`i3n2u4
zz7AwReu~^znQyoD)Yj)LpiT0&Q0A!&95Cu%YjU+)EC0DOb7!C~n)M`j`xfjCST%Uw
z%NkqMgYq-iW@DpZ6qjFCTjI5HCzDwsr$e~IT-{sT$63goYgBTi$*YCNykE-7HGKdu
zI&)&v5NXEeD3h&OFvT=x#+=7d@T^{`&j0`DNbrA#Hh`7_08L%@PJisg*8#z6I~)mn
z_T^rrL<fAn**hs$Y8?2hxM?3Ta@ET@Ih67%#wX&_!n1Sql5I4SDi~uZ?S2Q%2W1jD
zL`=;1%j{0#MolQiPN@w-UdSPQ-omzFJ!Y9VQeHZ%oK@I5*s9(NI&+>b3=0j*GFW2}
zn-D&m=CP2+(pzKNe>KF!GQL9|O;@&2)MLd&vsq@Yyl7P49a<)*M?JjzYC%SuIq`>#
zwE9~IvGfA*qJL6LpxNNG(4QEs*K!`LLKpZJ@jge#*Yz9chs5NJUdg?Swy(u19N69S
zMcmO97rRE`y7#t~1{eR`Sz1R@o6n!OqgJ{akNl0G+`QGWb%(ncF#3y;c%x<>7ihp2
zath%?Dn9eKU77O>Q>>FFK#RkXN{riTxJZ_C>QHk`KkFfB&nfwX5ttAFyKyBX)N8FX
zvs=K3%Dwc%0m=Ol0>G<-IGlzxit#^fA3$Al`T3`P096{P^5@C5ay$X0GO6@bDe#h*
z9@q`@Pt$he_sm9To|!iqH_fJgvOqkaoLvcZ5_eW^&5ypi@l!JMCJZY-)J&Yuq@IAx
zAlfEP^RZ3W&)mx9E35a>*<4iEshX>`F2D6vem2_hQIxOvt<gm#$DMIdhZ5s~8TKKX
zud;35{$m6X_xUUr9z3>SQ5^_KSiN@M+mF_P({wrW_GM8p9hjz*)eu@UaWNrH;3$-)
zqyv5bd3m(#>{S=XX6!L~&!%sh8~QB_4UvDkx)+wnygKDU@C$u&JHP~M2?|21tE(+@
zHj=Mton5XM_|d4=Zb;oF9@Uay8ldJeV4<M)buRwpo|<I2KD0#L?X@%q^*8lJummAG
zk$Z=h{YP1=V)bJpF_N5U$rC2zW^<ttoOtBEadSsI1j$WsTR$$OmtX`QlECT@unua<
z2qX(w@AJ<+@d#&~@?haZ`=c=70JpD<v~t)%tp~GuLlK2HCNivbKv(Etk<&eX+*-yD
z(G`{hY23!|z=h2fz{JKL+em_m^;jQ>_oQo1OIxl(2Y`l$<!&@I{?n+JFZEw}#6Frk
z{-_6t&qj_cLN)i;F$J$P?rq!g*KUgJ>3Tx@%(fg}eL*rd3<l|#Y`<CNg~enRnSV&~
z=<`@3<Pq@dYsZd1e>mU7<qVJ(=Og(=yFYp#l~-e*cbV?G2)-88kU_WP3jB9LD$?N-
z6mVrz<^8OIyKzT7YsQ$1;^#P<TW>Fl0~j-}KEW-eH8(lbhNK5hr6kPk$bwj_yu9tw
zuaR}d(hgk7BBAb)Nl88Y98(XnVXYru)i7q$Mwt96td{)YBBonnQ)?Q0X8IF$YJ=X=
z+7671=-b?g_>iOLL!NOFT8Zn@b03i?Eox=hZ-u<zcRx)uj_qf&UOl|jITE6vaDBN$
z4H#NjfTJY$>tv<TL~bab{jDR!ANymd`x5kq(SuSQGS<qB3dfnmhzuVDv}9_&e2(7T
ze19gV{L7=ikJM#1Hq@mXkjg$;d~l*3zb^(+T~4=0T3VEg2(|XMD*3Ch>Wr~t2>1kD
zYhS=W;O5vy1WGs`8I?{(SY!>AWgKnWLkw_i?sYj*ZKqY+BFwWzA(!2pyCGkr+a4Md
zUX?xVC=K(eomHI+_0W*lqO9AH&6YrKjoz%CNHw2Us!Dx^EGR^U!NV-l!aTP)ZGL-R
z)4$a~`Bm_uHW@T#@;@&!b+zgCpFLPBeX=I)K_MxLqJ%mw6bpO02RgV^8lv=6Kx#c+
z;0!uNc+aE?=*RqyfA8#M;_yx*#9oRD2gQdXTwuv7&@<46Yj*BM8(H`g)<>Ny=tGp6
z=G7Mb{@w+L1s&$bK<e=0UMOE`ewYw$bX}A-CH1)PYpz;4QV)O;rGX~9_>S2%O{lmO
zHQqNgPK1!bP-Id>^SlzHMa6ousT71MSXZ97^I_DoTSfjC$F(B6b5I2L$xQQfm9vXP
z-IzPJLz>ESr|27g-KFtVbM0SeR-BB?fb0IjXr%u0J+Bk}>>};YpE>2SYP>qMmwt1O
zI4Dp`yW9Ns-ot-6ge5Etx|6NK;`BQ243}LFa7nrEUqG_5vQqC)X&e@|zHT4*CnS`w
z+wk9PjW1Jve9m*Z25oeK`S=Ql_gE%m!uaks@VLt+n1hPO#o*`}06yb1-*oq<Pia=a
z#%b?fq{VxZs0p=(nwo1?QtTT<7XOw>Z(jzOIcTz{q8{$1nlC$IpKe%IDDM?0!-HoM
zem7@p^XIlLTTTszn3yF@#pmP0SD!O8Qy0h{hNUfj{|dT!Ij!no;k<YD!<W<<v&E#?
zOo^5FfY?Ha)jgpnx!_9L$Y@*IJ^jU@jbssN%7b`SC3n8`TvMJ=<urKL4v(57HRTX&
z=4-4r_M3{M3!$G%FaQRbyd$x{m5s!asish|%`$HZyUj8&=gP&&5!0clD(lU7S$#T#
z`ir|r5d!kYu!HVg7pCUyWWI~1rueFTP-#pph;x=W&MJ;L8BT2yy1pZ9h$|nJy|Az$
zGe!H0-<b8m+%D&~H3h>Kg*^7R^~*;A%<-ol)TzllPJISMcWFY+nl+aTjYxbvB?t8f
z(v@6ZFeR`cgx)Q5Kw|iICd%W^#U>W`v15Az2ELMLUB@a<l4BMb6q*${&$psc=sb$u
zS1QT&I?kg#E|(1_6m9~*o7YzUigCl7=NUwA1aooTC9`#hR;n;i`o3P%(V>VvX{-In
zx3-1`Bn;0bsLjzAnibj)O%Bb>&YA7)RoNE}Le0%eRn+z*H<(UuJo6H)s-p;AekOhP
zgOD>+WZzI;_2GV9jT`D};(L6%NLt&7w&8h_Q-l{aF7Yd<evQ^0VU?(Z8MU1`3ENk?
z%GL66o-lA>$m;PA56y6jaBq}US*0qba$B~2SxJ)ch;}<2nw2bOLABZF=mq0yP~z&$
z#Wnu^>iYXP8~a*Peb+AK6O+xe^-8lAmX$BA4EED=S>3txdcAVXo1M>fTGlsSF)n0Q
zUj@|8KE$BZj;c$6QU^7sBJa;Llgc()%vtF;CRaUTjXUoJa$&&%Cj&JzZ?fw|i#%eY
zA<*u3(4fL<K$EQ(+PKzQTFp~)Hi2=OoJxPScB^JV7#SxgdsI10#J_ks*9*3S&ELh{
zHQW#et#nBrMwMUoZrpLy+}&=qx$NI=F<^IRFEl!>zo@d&vXfpZM`IegoY5VON*vR_
zT@FzjCWI3BMb7Ma21(Y==$Bt{=B!5=_2xb}u3yB;xri@ho47|<&FwYckF5qxj_J8K
zW%LIcRih+qcSt6QlUW9I4lT*}z8xT>utEM7l6EBbMosPf2*a-O+`j%P`dW$Oj!z6A
z&S$?{Gjh2H&i4`%6Mcn0hDc9^$WUK?T7;T2K|Ov?tCYz0zR8OsP!Q`lJi?`6Tx~9L
z;BvE-ssC7EAf3Wh{ncRLDKSp<PngT)xv$yMDMY;P^CdKRZZ}t+@*?@^7ByH*KhArX
zEsv9T7x}Jq)z#;-Q{5)_SEIy0Pfh}e-9}on<kEn&-?bTRP%CY|M2(ma<GL;%W%*XO
zyElJo_4Om|T3VT<@0hGd(}!2u9Te{kb86OCF_4;a_e8Fib#$b8t_I49k5d|KER2)j
zr08qP*L*N0+x-#vP2RIE3F{SFwogT-UTSDMDo;;vJ**OSGBYkUywIBDBw{GUQpCZd
z2=Ax*67Kg5d3N@lTD`Xor<4Y!Y7H66&bAg)@#@%cg^kBb%F}*k?YM`zD^EW?UbDkU
zy@eZJkB8d;wXVDyH$RP?x^G3>bom}9<PKATofw_|2#VP|TNlPyjLgerAuHSd{fJqq
z#SdHKj)Fav9qvWT1N+UdeFNGly%Ps$_|Ot437qnk>CG)Hih0a}c-(sOhEPxfZQJaA
z-^kmYp>bq|oTd2GmmkKju2LPqHal$}1h!Als;KZzTo$))oV%YMKHO04CSx?YX&2QC
zo$ad)=S_TtH9EwY4_g^-xVWDte-F!ZJx|>2QGH)r+yJEx9%i3E>Ozth^#%$S+_dkp
zr5i7r-@#e&x$t0Sqrsj#xLhDz)e*SY?7ZldCYin3=Wf=t@_hCU@pI%D;`{9M6y?iq
z;#B9Wz+8@|%jK!&yR*?)hdR=ZsXOkv0d;MHnt=@sbYJ-nE^2Zq_VEe*HC46gI8G5m
zWCJtozz+NR!PZ);)>aBx83;nL%QC5uLbVEm;z@2f|1$)XZ-Ni)Z(%)47M6*~L%9~$
z4a+K+wWrDE-?EqPo(z9TN8uZFxSG2Sm$II7Y`U<xK3+1)khSX{92|^U>LE9cQ04hm
zoO0f8gS3?KaPjaRjksz(G=FbT{r2z~yUUGF%w$Z=Q?n{C1glsB2kEy*62PK=8tD_%
zsB`MG9<#L)se7#aHDgI8IJ2shmzs~(N%-@Z23O^u^l$j;78Snv`abB-q)tUkjSzpk
zb%RiE#ZYhIy@eb6rGzr2AaOM)?}3hi(HyXms-8%|%!qH(*Z1-DZ?A6@G#f#IPwJ`3
z_a})zE~ez&_tvZ$IsDXpSY40Dwm=UI(j$1bvj6^K*~7BpIp?*I^Y*JQu*OZN<@W3O
zTi?dyMVmuXX=v<Oc2cTd>a|B=ovza{MqPVXxisHd>q;|&ehbbTpY>vpf`jzcp2<6v
zkjaCqjunggl^qWz5ACjFAO1wB?d8JoBp<uUbpUm|ysB}3{ZuE!>8O(T;eL+vDs(o{
z*q!UDDa#(-nrx%F_+EM|m%)T20RJf=GmGbvj|wHFZmVmrNL8V$cGm%ElI!rN1w85Y
zCdYdY4Cuq+L&G&S+`8=+zXz+`WK{jb;l+$Ybu#0Q{7T{EQ~v&>p#v+fB!~HTuUmGN
zjy;ra7Fo!Z5@aaQ6r{Oa(i*8YH>ktu(k<dZqb0NR>1KGw$4=_t?rC3<-0lz(wuA@L
z4a;P<#5?>;x=h=oaV-p{<&ELh`Nn0Rsm@uK@?Q>O?{0jf$O{12rP8CazK;%Xf3FgO
zJ+|(%mg3zh{zDH2fg}eRI@`p2_bV9=!>^hSisla%AMy=0S|tOs=1UEsh1dhW(D@tR
zn@ViF2kToiMR_B#LP?p$!x`4*xHozySxV<{mvgHqdrkWQ4sK)lZYdIl`E@UhhE?(2
z5#z6w-HXM2{;k{Q*Br2y&AA-W38ou65_g=9cS~5vATgE+m3TRauOn*ba4@?lPdc6n
zis_c&@Tona^L@k!2PcAH?%RPc?-pI}lVqN6vH)-Bf}7uQ^H@1sUNXyuDZj$G)H0ui
zn#X=Gv(BZo<K$+1&qe;)wqjo4;f|wl@*^398(5aYPju%7z+wW+n&TK>QdF$K55Iqa
z*MD_Pe=qOiwv!+p9vFyXzT{^bl3Xq>dOpUF&&Hrb{$QmH6;{lO*E`?#2{xdnLqr!5
z$rsTd{?k_xHxnK!8@YL3t<;r^L<aUj(RdlE-v>|7Q7~|sVYBmx9Y{cnkc$g<e?aW*
zeyEFmwlG4f|CKv&5+>`?tku%bCH{@F6!j)Sdi}!5$zL)k3%N8<Fns?meyq?`+0oB<
zmAM~-pDH-W#1MD3@SIHc2F<EWN47Nx0@Kb}O9o@`ee8mNg!D9#<Dqo3o_#%bOQ)LN
zNwlNOy~ezKI0hdcNu0L%l{iT%`F72zV^*Le`#G9NNzUbDapLZ~a*|8!c?ov8wcg`4
zR(VqQ)xzwDuuhDp3-_T9P#QeoQa){eg2AU*xy*~HT%GM<@4~{-Bvogq7=OK~;-pbw
zggEfN+N!^v?w%#hB@;u}fRBA8wfT1M-FunU8}7y4o&?<2cw_+X;v`s!O3HA=8+PP>
z+*-XTy<h=eV%m0J$m1PzhX&u+El2hOv+kVdOU4Uz4$w*AvP4^v6ld$JthNO=L!SBI
zgX2YkGHgM_Z~YU;cOx-lB2t}0LBx?*I5;?<tMmo-3wjiDBeQ2u;O*?}@bVQX!aF)T
zKzboNJ9~<WX@Gwd=XCXTxO)8<AC2eTRm_>`WsShL`WrKXEQX!3lTsviYP<lLTb(^?
zvvmzmHt5k&K2ylBdfP+g(v(NdP7ybWyJ1S|b8(N_TbnzWxx>los=F}*uY~#-*URig
zsoAW-Cc2%mxiV_m3>a6g>!Z-~h0|>s+%Xd8RevQrY7hUrx%1Hb>x=69)7y@HYFqxW
z?YUHX&FJ6R3TGnyAr&1GO)7TR8?1}aqgyk1(!)iPR0MY=2m2a1MqNOlN88bK+~JIW
zzTorO0rxg`tTL8$<oVB9P2A_L6;-oBUy}-iwH>(9f3~GPlg!Gq_otU5p~iW#;u{K9
zKnCmE$P9~rY<_40Z(}VGEVn-=L(ojj%2T<_s;Xx`q?3gUyxQC|62w>C1Ai9TDv%Mp
z@OG{ypAH7}Xfp@3PaU{de?<0?sBww#&&c&JpBds%lS<~wBzZIMx-59hyr#$R;CTWM
zNDgkq@>EvLe2MN~+hD*8F|jD0nNwBUvroikgdCv*_vLE`vC73VuVBe=P+0aQ(4zeY
zW7vm96cc&5gy*+yy$*cS`1=8Zj|9(&jNdBG?VYQcH$VM~)%OisWHAmZce`4mbw71{
zgrp+)I_^i9j7pA#ZO37y^T1~QB}14AT03(P#K<l{x8M~c<18KpDjG@=k6p^cTRs-U
zZ)DTd+DVMeZDh#s5*U$?$*7Q9$q`@K_ig;{GB-EA_h_*uvj<u=G*kovpSH49_wG{A
zO)h|?qg<lzI-}o9IOgr!J%tvbXJg^XWz6{U)*qVHsvEbdSj%!3pgHJgQCHK_=Gp}7
zMICXmdf^wDoj_b1&dF~iNj^G-?}*e7rux164m88=n|sNm1=9_5EjiOeCG@7e)S8Fo
zpTFzu6A&KNE5-({z`uVF>?ei|WHa4tPoq^snWY$E4tEBkPWh`V-^L613ZGRTZQ=o^
z3CWl&nCenU;Pd3VUn$rTXJq~s^env52EU}dX1#%m>T0bT%e1vNguqU$7cX95VI40x
zWc#9(_vo?!`I;VI8zjIT&fsV@{9qkp;gtQr<l(wD=z$3K!H=C+Kb-a$M5vH5)FeK*
zINu{i|BQt$UwiQHz}_DYEwkBJKjoXn$TGP`+80B>?0#ZSl&XHd#=&3f@)n|H07YJ+
z=?!T1?I&%Z#%q!8>bl=suz?}z@y2$E=V;2<OjhA<MiQ8eIvOszULNLmCFZdWN<F`%
zFL^=njB_|uu%eoB^VnU4*GlYXP-LV;!@<vG`40n@YC8z;l_e6V`?|VP-x&}&chfJ2
z8R{5*^Ij1y==oB~wab3`902*m?*y?wE;?JNb31H$8}QzMCwH3Y_#Lk-^w$18Tn!vq
znAqHoG#vP$SY+{v8GIm$yec>JJvkIlRKVbkvpmBCTIhhB+(KLg|Mc%4(OwWyWBG$$
z-R<$LAOYn0lzH{sApcuuB%rzHPO_N##zQ`C!Q6&RNL}jVGkjt^dM<-XZVg5N^%vCG
zBAQDBP%o*rxl==;$MWCa-udm@>3VmzyrSjt%%7Vkns*jU>GI5H>D#XoziR8M)S!gA
zsn1rMWCY7`-(;1J=*Xsigq$TZ#y%w<4burP060yIY+z6=)7au{IKi0?V~x5LjC0b~
z{b*V4Z5RJOp{L9J>Y2aIBEE=6>1|fXeU3rvW@mJUTvoJ>E+9BE+xCqmDBlLp0rhYp
zt*qOAPRnh>o3nH&@OZSac>j<p%nu&;hD!OYwjal9S-mKQHko_lUP+OciWG~Sz)flP
zu;}Smd%S)3Gc60?vh#sABAU0e+(Y>H;36saa>WCguA9X4Q@q;ZLctc8!%&GQDAot2
zU%iAZJuO0!(NSh+;nU>4qm&%MreUVwv(#{2Xm~<Gz>}Daz>}FuidQ&V(O`OkDi+17
z4PNklzt2;~8c@>h{BjgVF2ot~6b+5n<K7h{4J#|h@vt1v*S_QfYBXLVV$y0)4o=Nq
z4UaKq2i6J}>)Gzzj(I=iBpxpF<0IOA<`ic{*$ne!E0>E<QYH4_#3y_)u_ixhMM3~8
z(3V`?#*42-vC1T-?X%zaO`x9j7c^v}Zu>?wX);~I<y~yrD*pol<ow(r(0)ke(uIHT
zNM%W8?UjuNgE~61V9j%b9g_?k%HnB<Rb+omWZ}Uyp|x=Gv&j|HSM&@FloS?kIsDAn
z4U%j{4J~upw>WRw<Hxdh+Vn>EsmCW%z;T76rR5<Qf<S;>zBt>EO1}5B;#{_F-2&9p
ze~{@|m;kpa2Bh5eDcwtna>LE_^%KUpPkb&OjNku?d$V@nAtSF4opj=N9fJDM+AVNG
z4{KkOq)iYDAtd3akWG$@ilf5xCkTgVq4}E!LP7~cFR!$U&#Kf7t8CC?;iS;DlFd_G
zTqJ_%MHz9Wn?JOQdcinM+okWDdW3>QH;u)q6m<I;Qp~8SZGOE3+0y3S#JmLThXb_r
z@HV7KUw4g$yPoh2M*I*DgSr4Mm|Da)AhI9xrLhBN5-f5&S*d6TYN)O^0cv!BkauSi
zHY2_|q#cSVjlrdz)dzR{Q?1<_egWy8mso56ild!*Z=;#-wsS;x(2Q3vxAN22>c)x+
zc{?+%%i^Zy=UB5YC5_vz%WpkherhRNHy23z&BZQ><r{<ZXT9edsivt;2cHk_ID!bU
z__sz1^YOU$7Fki@vezy{sLf*5Q)ZVMSwBTuUAAzrpS=IBLu;4ly<+i#i|XxRmw0B{
zUePamaq!a7-8_wZS*rEvuN!W>cFw&*^}Dp`NeiO;#RHR5pHUejM`2-QWo2Q<4)CN*
zPfrIUO}L=rHe7Vq-bFcXK;PskdJJG$_3+Dm*#xkB7t(OIku$QTRB+M!b+7?nTHp0@
zSPRKz!ZFP~u<)up<(N}ddM@F<+u&jSu37XuRsZ*ocG8MfJEXwukb5o@w{`pFDV-&=
zmh0!|5w;sm#eBDyOGu=ow@aO%$F$xs)}V&#@I1%2AHizNm(LZYMTxYb11z?SV!0J_
z7m@OhYTPPn4`vhkd~~c+8lEBI;k-1~Q^DOyKDtfoy=?elZCS{`Bj;k~2C2ltV<rTn
zdGdwnZQ1N^>(({fni~6-HS5|-#w<|+Dx4=wX?HO5Fa!zKLU&gu*%;d*#x#gX;xD0*
zYYFdGh^}-F=VAQ({ItEPzr49|yZf|E_zWWIq+6d{J_kNLR&@<I0E`;-jhU5&$!J(!
z&&JgVV7$yf1sOLjH7w~;=oaL!WCcQ%r<#v77_-+JoHkg+HJ{rF!cuW!G%5^l>!GHz
z{=5oZWU6lUuPO|^+wcvyGSMVpeVOJ_8AeL?T}K!;D8SNvp#uQ{B~dNjp8Pvqo35No
zm?!}W9zBl#rAPV@`&0GJorh#`G5+MYM(GYk`;DtpJ1_SeZkpQ7Msq#p*~NzLH_oI~
z;zB+NV2_U7D_)*>EJSvG>e_AA`;Oy6Q2dDnXrSrK$iSGF&%~IIy=wbD8;>o2V=M5W
zdUN?TarD9ELQ8}@-vlAUSK{t$M`u}L<K4SWb|WMR*Go>5y&V;s6v-}9TEXnXyD1wt
z;|7RMS?v8C$Hm<;&2mu$O7jt8?bI&F1gAhn4;1q_Y&#052@}g-(LUQK?w&vSDMO|!
z90by+M0%+UewLPwY}tZBdfv97yeKj;AtB1r&G)eQi)O;9^PQ(dKb~4)6wY0fX)Sf}
z7hLapV-Ts%Dh+y2Nzl{Y%6T{uo8ETS+@7_670O!=z2SiLY;MM0xWa4qZU@xwNATT-
z9k3_y;Pah$4u54TsH%@!-$XioT8(&BSBEoh(B#&AT5LL6a9jPczqq5kAIdlz&$beq
z!e7aeAH(HKdSh+TR>;3+;*#RzbjL(G9~R-@``-CtvHD?R*x{{!I%ZM{8#-F;9r0K1
ztKCoSM;7J@j!cjqKV)EY4}CDMA~nveY_bZwb!d#SXrXgv$!lyGm_p}#)B;}NFvr^9
zG?@ToIDyg4ZfzB3&F$vRlJwyKj2%9sRkRs|2d2eg(S3vearBxLa$e4#g!jbPhw}qP
zTFaI#+l+>!;#}hj?(KB**cxpi=aEokrpH>Ug*o(oBm184YlJck&ArRV<H3#xm)())
zfSR}0tnGs%Re|L1j+6IUTD*7T5e##ipMG=@FUl+QsV}OTZK(Ma$Qv3Ea3VaXjPebj
z6!Zq4*lN`k^FM4GKSNe`bDI|bWOQW{%6OuV)O7pBBR04g!wm%p3~=s~tGQEf_traH
z&bslufw?6G26jKgViFUdJn&ib=UrtH%WJvVnMg;&a$c+z?IMvNZ?E`?=7hbz9Spvd
zoMN*~VFxZ7cE|R)Vd&$3Dzj`I@apYW9`);obPP<v@BmBIH*f<|$b_72+D3;Z-%h&u
z_!Yi_DfwtRzQy_#i+1^Jc;AnRNJzflzt8U3e{2CKHEM;EKggD+SE=sb{K%{M)vjk!
zk6&}iG)#Zr&+2B}-U@dECtV;VcKXg{SxZgxc<lSLzNKP*HI#x=txJ!T=b<!<7tobl
zI(Byb2ZLK)_@9{zpHJ;|$dE=eb4Ad6>!_3;`qZEvEG<edi>N<&7bNAryPoxuLiioe
zPfuT<VbUah@pp7=JG89rvAjfLR$nZuPvXC|%qq;4CEWkb$!%bP-LkgCS=2bOWy_38
ziGvJ}x?)4$+}QX6B0z?U^1H_V<}l7ro?rR@3UURF`uUF>948GHv%a3b>SG~7^zFB`
znj0(f|C;ohMPZSVy*B#NSJ`&a)2w}m!{Kl`UV8rdUQ2K|FY}AQY^}|w>s<2aSfN1Z
zbh&JHM{0anFe`KcjThQ0j@2JIezM<%2TLTOqi?J}aqJe>@vn2C-`~CH(fJSYv#lO|
zH0Qqp(ZAl=^tkv!wM`JJxiMH0&^$jfh%gL*P!=~1Z9mjtJ$E6P0n_eqh6D*>BP79M
zVXNKIeBnZb>%3U#=*OV)tMBZ-0$KXx{OQxr%)9>!`On{3KI2l}2|x%L>==d-1r15Q
z%VABk)Eso2IqEbYJanu?IsS=TCun6dnLr>Ai^UGkarB5`c)U_{RUd{<u31i}v)$Hi
zwVbz{H(M>%9~#aHA-Qnjf<z+mesP2!E|<&cusa;>E+?FJdwW}JkPDoHv$wVI&+Zcn
zg^WM|_~_j7zw9SYoVf32H-CE2XgFHsa5#iQVLRuDkw#3Pn0D;=x7~Azd={jdF)d_F
z!q;yX4b4a&m8cf`eQIeSt86ce8^+$SV&(Dx6W^GcdU<QN+bpL~wn{=HgCtUskQp&l
zQrBcVb=LB2&8f5Jn)>?|U;q${#sByF<^OmV;Rp6aJo>x&_s;h8(gXs*{G5k(NJE$Z
z^Ka+xoce#umx}{_f-D&%Iwp`HIuy4l9mmgIs6H!f<%G(J5LPUxYit!dta4FnsK_Ds
zvGkQA6pFun^4X=ALkJ;^P$W@|ayhv6c8jZZ#BdcWtorzeZ@wyNwj`w77!o42SS;Us
zb2KbW8WknK+KnARfh>vqQMQMFkyrPf0D9WrMSFXDOG|5;%|0}G`U~rdhsDJoKi-ml
z`_wZ({17G!3keAh<Qe+M4}aR)#++}g3wMS&EN#x_b6op{AHMz6ddetnKl{b!pPxE)
z^61ecH;nc1QZtcAG&U*m|F?JlJW&Ku0KnhdnOSzn-8)Y>xhuS2+~W=k6}in}z!+PL
zGciO9I|~Y<A+a!0@frLI#@3I3G$g3enu5lV82<!}an}Ry_K%fD7a<Eb9LT+2wbh&1
z-Dcj*yqV>fOINR4yLW3U48kxBq9{TQ*T47>ZoODsn4Cx!QS6w@o~{h%hs)o6KTYnU
z@IURco9N-}168f;PaFrE{^zac2G_;&#rN$nY_-}-BAbSB|MA?~+MROQNzBnA;`H>*
z)eGlKrIKOLeWE1kkFDg8lW?&Qs`=3S5rO8}kuOBdMfB^`gkzEb5JHGT$OST<aa;h1
z!}d^rQOo4Ndj7lBl>nJ(nq}u~Hk(a3l}r9F#lm2R5rhzyr3t}xT{IduzIk44{1Rha
z2w|E=nt5BdHhw~`7^cx|mTb!g0DvKYF#y;cvp92w5K+*YsJkQ8%0DBFR!4FtPrZ5j
zdVM2#Ak9GkK)vQ}f6d(%vk=j;?KCg1yar%<z%G;-JbTnQ=q9>TEJ1q8U!|)6ItQIY
zrVjuT=YG-XpAbTJfXJi`01(GaW>8~hE?+nkL%K>x(&HFoQc5W$02KC~Q8>;y$LaKn
zr($7nPsxme-E7Kh0Ms^dcV;%tuzT|Q?G(ZG@9C5IE_^7`gDO?ZDhVM(5kzGC_v2yr
zhLD4TM{U;^Ata>_A3wcXUOMbvkYlBOd8+dTaY6_oN8C?G0=^JR-|_qa000hjMObuW
zZ*6U5Zgc>6cVu;KaE=A({Qv*}C3HntbYx+4WjbSWWnpw>05UK!Gc7PQEig4yF*G_c
zGdeUiEig1XFfb@~m`?xz03~!qSaf7zbY(hiZ)9m^c>ppnF*7YNG%YYSR53I<F*7<e
aH7zhSIxsL<D<Ja#0000<MNUMnLSTZhe1@O^

literal 0
HcmV?d00001

diff --git a/doc/assistant/fsckconfig.png b/doc/assistant/fsckconfig.png
new file mode 100644
index 0000000000000000000000000000000000000000..81ae755cfdab3fd77fab040e2c65bbbbab5224da
GIT binary patch
literal 59050
zcmcG#WmH^Svo_igAUFvL1lI(DYaloY5ZqlFf;)}7MQ{%u+}&whLvRc3bZ~9F8;9Fu
z@BN*7-m}jg<No;8pa*NN)vM>4HEY(adY-BfB?U<wOcG200DvPcC9VPhJlX;Pkh#&3
z5m%1hjV>epVc1J)I{^T=KOa6w@l3d+h>MS%rR60aFJWR4kkaowf0cr`MC>e~<tzrW
zwKcVK28cPD8akVrP`Oz;TTn?#%PVPq!hHb%PywXH->JFJ?=J}{(ag1r+?}5<=Yf{2
z>7%8PG0?<lLSB9ot<-`Ue6B!Y>J0C+$kZrPh$ksTBFaS40rRW#e<CVuXI%83^Pekr
zK$d3jM0rLRje;*l)d2Oe*qy$6q~x)iPwMc&6;i<o*hsxg9rf6L#C;JZa)0wo{NXtJ
ze2b+j`f&CWDDd>*aF|i}m!|k4_}Rl<oKi~uJB@^m`^${`%l7+g5xU@qV|(FZ#_x8<
z@BZA6mk1l`cO`j!4wn6<R;H2sh6ZtDgAO5gP{`ey$X(7xVwq;2T8X;dT*$+tZHf1{
zkb7H5bp65n{dN0&O7g=4G*^-H=j&z7uKI(2UgyjQeAs_U&iU|a;%ww@&_5@Cztq!z
zZ~il)zwiDp&HwN5{(bkK;r~bT|3b(AyybuN^dHUtrQ`pQ$3MUI9|HLMxBj{N@6G>z
zBmTSNv2)lX)g$IywcEgLBhEIl_ep*aQ)zwKo8fmi=iaVTgst<;q|YN0nfM6`dYAuY
zb8qd<S`?VH*`RHE(Jmk9vZ8)wUx@mP{aeIy*=<}T5fN^WufVR-BNV1<{c7-Xr9iy^
z3;(Y0s$;_vKQy{gxA6V^UbKxw`kDK0Uc)KvXDbgnmA>%%U_NZ8&uBdxKJAZGiHxQu
zs~LbfB5QnH7BL*Y?R|dxgA|%2$M4b!rF&58TNhVoVhpS-3=@Fe*qe~Bh^zc0nxQWP
zm-Wcyuqm_=rr4_-^wHL%yA`_;pdCmhS_#O{7nx=aBos%-1&C5OVgOKN3rg%>_DN*A
zzKePKncxY<9U(u=EmWrrJy-37X70K4gbSxc-z(8Tc5JPTC$441?}Lcenb$c1!F8LT
zIdh$F%@SqZo?B^n<myCYLZKV>h2|fM$tO`d%ZpSW#?)YanC$G;=%Tz(u00*aD|qe&
ziUOjyoDbiAYrnp#LLu8vYg_P{1rMs2vH3VV#EUgzj`=$<>4ADAW*DiEqfI?*IZ--n
zxXOLsG8qK2DO7Nx0_^90>t9LNinKYhK`2ZVo)y`E)sO&TPbs#deatBGL*^f?g5HBk
z%df40O@!L%*g`G8+60MzthsP*oNU>j+|a3h)eEpCYU^OC0oB0c#58C9)!MKP(hLet
zqf07@R$NFW^LeTG0c7H=PW@2;Z&ka|{hqaFX$x}h!YBZ-uI6?o==_wG9bKa8N?4&x
zv=wy9uOX;wb8XP6s6rhua+&6Dpjz+*F+r_Q9$i{aYMHQjI^cZtwla09bNK?}(_O|$
zC)#H%Sg7-8&uNcfsSpPp06wBu0$ybr0qW>&BLncjy*C$YQGjr<z%=cxMg1mBQY9oA
zK;S35YuW6j$C*j|S{OdeNC+K4Qm1<Samaso&82hSqY$$rk<Ebng|=M-h1YY$d9#0N
zXbTQ7&Pq`k06+!k#_|-5R3hd2`H<eI6=uU<R1tP5cDbLgJXw{ZNrUKSARSrF9^LIn
z^?LXCE`|6av+t(O0dbu7pTfSAKEnq(vK{0dJpZ!4tPcz-*`RdfsDis5=3{=GCB3TL
z#Rt1!B8EJ6K7L|3`RS$&ZbGNqyyE2MZtL>HZeGOed?EkTaFBILpLM!!A1%de&*pZ`
z>u`h^yP~*bpjVGC)`FRJNqq*-F%nh-i#jaGHYaj@^cqQ${&@ZoO;E^uzN5{C`|Zu`
zz-5r(A;13~V<b%h`J-u-muC*=E5}(;&EV#4=j^rsu*a5S6ynd&;Ssv;kaT@w(+^g2
z{5^2m!O?}>na##c*RNSYf5lhc!u%+|U3CmA0T(*O1Ks;#!<zjio^?J4k!5>2PC2lg
zQXroc3v|k*K__H%rF%YM>1|te`!2p0RPte!ADU9RK`+OF(7>hnOIZpi^3TBLs#A9Y
zz;9sEoP8+8(-Pd3f`FYXgS8COK@FsZvzxl!^`{)x-Q&9{*9DkhYe#$4V)Z~A$sXfx
z^m4P`&wo!f8G6(2VY`G&%0AT;`^j46d(N%l_o0egWP`U0)N^yA#?mKFQ^d3%du=u{
zgo3OgmsHuf{;21peTE+x>B%P!(5>Um+0?Bna%1Yql(5K0r#S)hX6xYy8ze9lxK?v!
z1;9X{z1Ua`U=JTT1j!|xIsch3ERN_Iu;w8scwU${Np8!Em#&vW_zOBD>Gm1mH{+>G
z*5xs%C5mk&YN5;v;NKjSLt>D1LLhnpRp@ZBa9Swk8SOpKK`sqlIaA85^BS41uUSjb
zgT}_$h3R<-@wvp}Y-3#Wt1A9z$Z_4kATu-Eo2Ua|FD0H_FU@4Y0WaAq^zKjr^*bdx
zsB8KeDup^$(?q!m@LhhrtC{Yru=B3ETibT+ZLvQK%3-EFCacaRF|V5Hdy{aJb30S*
zcS?g_z70P2KW=lLPONpw*$OmdB=86aX!wu25X|%oyad@aIOzWN;W9h1$=p%DTMnC4
zJE*VeEGpBXI=Rij3<xc+r2O{L&ONE-(omtqqB2|^Yo@5;Ri6a<=DPZAMmQsoBB#nM
z;+>UcMR`}5U$F=d5$nc>Tx_|>0=GW`tmlo^>?2}<VNr($*c7x6MuSM<UQu5I4KULv
zGP?y5Jx-2h+1moB+1RnE9*bkSx4QVG%<gH%5E^iJei<VT_w9bojv2lTJBvR8k{-Y=
zk<>of>|%DfT#@*9a&Fd!Dwb-$Kq#W~+nfcS8oW%DpEN5y%ExC4)DOFq8QKZh^}2AY
z_=uom*z|`L=$7?|<0cK^@@Z3qMujF(GU`X7YPCa5K(3KKchn>W9l<G>6fH+$>v$s|
z=Hx6;sl%!`crV3~l|pi*1=EK7Rg@2@4<j;wh;y|Znaa5hW5u%K4i{&w97UAzg~Y@y
zZ>FpzIx>}@w_hV<@5b2zP@LE=o3f<eoWHbpD%5Ib`_9UuA{`;8S^MutPUE`6K=BHu
zwZz97qs;}bf5gSh8(jguz7g&KP{EINM*QrSDIg#4@Pswk@2jc_%i1fgoFZrJOv;6Y
z1&>zhmUgCG&g9%#@8HABBAPZTuG67-!V`DCw_nNvntcfxqZaj}7Byt1gtK??O%tPC
zF|-qtW(ewrg*BREWDO>xl!urV%OBr2p6uyetQcxMP2gbjFFBhza}lZ+uHV~vV~thq
z<>f*?V*DAMxol_#ZAfGNS+33KtrWsl`w48uRVX>KvLY45KxaLOV@p)N!`@LD`Ct@w
z`l4~(Wt8Xs#s+$PS0oCJ4K0v-p+bkeqaqWO69g85MEeaC>}`9UTo@wtGqU1+0k7fa
zeFlpV2lig6<R*n?-VpoG7~KD~WUl_=jXiEE+|~l0@Lb>Oc2|PbKNHp<5Rw!QJlXoG
ze}vXhOk)nZ(kmI=dZbiL<9mkTe;n`ib28(*3rf-AG6gO#2hDtoEWlCy<v~U4P8Q{Z
zf7+J#>4r@f@bcp^mF@)*nhaV8CXqj~l3$Fog}0-ZOXr<?NVnq+eAAx1aPqEq{FXMt
zSXN-6?Mj`n?Ed?f{@|gi1mBq}&J-ztrvtFQYhZ1hJU^f8^4*gO`S(_%)GIfn4)i2{
zJcG8rjs>Y==cmXYkplfIV43>EhoEa{HoWq%1oP2Uub(_h2d76vJ39@}hU>|_SA-RG
zVTc1<%_Xp+w1dU+W)EAXthJT=K;y^Fs8iu4Ak|JjIjx37AOJCh?PiNhHrYp4<eX1F
z;bFm_L9|x|y%ME222j;r5s4>}6CTdCjPBaBz4lxXsWumAdn*Ik_-0UoA1GHDanHS{
zQ_1Ul89crvkm7sDiN)0095glr+~m|`K=OB({pfZHd21&5mHv6>(ABs?-{<#DMo*Z`
z1OQ001}*`Tqo9%403#B0VllHXT|xqfXDP4%AA_m6VUKDxxy0g*O4C^=5GOo5xU7-<
z^r}K+s?EWnZ_A<ZJfQBo3u@8y@-i+j&1ykjyrMu5fX1tF$++K?5d4?5m1Qri0E<L_
zqEY%rJ@^C_8;hMuqyhW6NgpQ)5+M>xMSgznwS3*|?Kx+3qH-f-Q|J4Ag({we)rqJy
zGK$uBQWX?TPAakI+~l$w=dfY`?MH%N4t`gcoNYBO=p8)5mxfO7j13AW7mcIS<`+&^
zUQ#*TdljI+bNXXGeY{vIz<4+1Y3XZ4zbXbRM3&S5rTeK0Z-<7^|LomM;QNm7U$hLU
zeV1YGwu5$+9zu)N4<S@5U=ci#^II=huc`SSP-tpt8ZzVda0B6ov&m|lX~^&qp=beB
zWtTC0U&lU7pXqNG=wzjJB6UBxFqZ5?-~%D5u%?%AMfyFs_t0b;ZD&V)IQhqE|6js`
ze>{FSC|hKlC%pK|Js6|}&5Q+67u>gfIWq0JR5}V_foclLM0iGC@g?ZLzws>b`D8gs
zfIo^Ww6!IWZ&&FFeI>b|YvWhu)R}oW9~M0kJsw@-KY0<f(XZ4VnWZ*$vgdwZmpiu=
z+!Cei6SOKX0H3V@iCK$eU{7z`kWk+a_MG<2O-#D4>baK|L`~FD=WZ3=lPY%T)A&h?
zDX89DJ(?Ccx@xrW8ysrssCfjqboKvsS*FTc8GD|bZ)FgAJ{{s0;M8egG^5XIP~N>o
z_@zQI!5~9i|M5iUjH598Xe;H8T)K$ye$K8P*P)WoBeL(BXsVuV*}_3MbP8{|=KRZ>
z52TV(lr_ht4sf0~>2F`yr5hgc20EXf(9Q5_5$aDyH+!V}!*E-KS?3{~Tx>`CfJXNt
zR|-d8rEeZx{nx;PzhC1M;x#_buonCX11Z`jC$Amj9r~CbR(ZHuKnzl4rINMw!jM!*
z8lXos?`{dM6h@IZxRunrKD`@3w$EB2Pnho}4GkK6FZ0L)5IxU&8a=Mrh@7i7fjKL-
zuA`&eJd(Td=38WEiTISGb6Gb+(m=-r>h~BbjE`GtOa-?u5;TY%(Nstr^EYl2>d<TC
z`!y}GPNL%jB@0j(YY!a0zJ8@z#a10%&fgM1p9j!(>j(vEC<d1ZRfP_FH>efu*en$V
zM$#&YnZKL<Wsl*Qe_4T-xA&$w^Atx3YOHH2STBBOuX&BWZ>qf=Hx=34yjf@5zGtOY
zpOsDj`yeN;EU}rHlb_Hw0?U0SIoku@Qd`9t?@M}Ou-$mbwxlIDfrz@64JmD0MpGPv
zJZ0V)4Wv~9xOFWy%;E+PuQg9@ndjG;p~*27t((d80sT7G%WQ7AGVus>>Kuf3QK6-^
z3u2htHuu)JX5EoS0sWUqo+rRrt5zBg+lD&(mtD#QO<p*CiqIZAsAw0D)(Y#z<g=Wm
zi9?<stO1ceIk<lwp04(C?l<R)mc5$KQ!_jUtauu@@^@wac!RN7OKb*K?YMU>ZA}~=
zj_zqpcym7&ox4^B5?5j^%BhIc^1t~_QR+q7-5=*w4Q$L*jgu!B^a|-mfjZ|^*M}=U
zIok!KMzQs-#eX)b4UXU8C7k$aR_5OOdm&pzuqk2n#CFwa>$Q3<!2Ubda-P2hUajOZ
zg&_x9z>Bp8zgX*YH%+Hc;#P<2#UB|5(PHhlz=>%kDNo2*U}y#v6?SsuAId|=e;phu
z#MhPHI{6r%7R;`=l-qD)xTzxLOx?c~jKeRSYzlfho-Wtj)_?~-$`A{@ziJ|0!Y>=S
z_8l&7#R1*GgQUG}zI!6(d^$C{C#DpC!6zU-m3y6A-CK4o%DAENVd{;|<6lt=603mR
ztHQSz;v*m;NT2oEfGL=^=@g-xPXQ}4Ok9-0-{o1TUA*R$MrWtT*H|pagppyaSTfqS
zY|AY5p||CY%1{O<yBarIsY5MyPrhl)Se*s$8*vXL%@hV9x$Mn|P$OMuoIi>&Fcv#G
zxjAQf1RgZ_`q5X<W}%u<_XcQQ>zN9jkmPHP=6qb$T4FP2L3o&d6A>}R3t@S0=h=^i
zRMkZqF>$X=51LWc#|x9IN1AIygL-|5+(J(4Zk9{%&A@7~_M;eccl0#tTIRV)xEbkz
zphlT^ZO@wj@L&c8f8~w31%wvGHqy?4J@#utl0OU9*TFl9c$<*{CyA1K89}$#3m=|_
zm<W^eLA)U?)@;7G6{)fyxH<h0%VDM7k|A_`<S9Qq`AJkB?Rn6kpRkrlfPnKp7goQV
z2VcVpc%H=dx6QfPiRArUxx_Zd$z}m}ny!PFM=d^AW4-IG8MSKM*83Ho<Gy_zCCs*0
zjPW_v3>3KJQlIeJ97?cXmY)>0o-W~)d2AD9ZR?<?LIdgi_AjPg-+p6J+?Na2jX=gU
z6;}|s?uzMvYY%pnGY0>Bbv=EYR3xigUZOR}G{+O!N=U8QBlEh&Sg_iYaPk>KK}Z8w
zHTJ>+m2x_zb{Y8`{EB4_3S?YCYaR+hAHl5F3VrhR`i0#IifN@k<(JEV85lFD9xV9#
z7d?67=##VBbWih?D?Gb~={Q1GF1@EsTue9(K>jxH9!rXtlet{M7DIfOR-|G#8|$6p
zgjx&APo9aWd8KtPG)K#1+O2KWCKz)C|KD0s{kK;1Yk^|X=jXGniOyQY3kP2+3=oc%
zb~ziKnz1U7x2eNQUDL*P9qPil<Ij+_LY~`@_O^MxiXmSMnc^z(X?tu8JL@q{h8=}=
z!eg17ZFs3E2E}RK!FKLTW9#=ADuN_F_=qx2{cTZl8Up*rAx=mY(H^YH6|d?irtiF-
z{c6B<f01uqb`*?`nyMMlJkN%w$krl@Rf0Q4yP5_(Vj2Fh_5vo7Mh{`WxHWSZx4AC8
zTbfGPYUqsrT3OpJWO#6)^A)rr549)730e?nKVfT4CVwhO!vmyq`k3FEsfq$fL@)Ve
zydDv!<KUT&&D`q2OVc3E9FG1ekJqa}I{vqAwu*@7%&KPIZk^^?61(A#@=^ZQ_IV1A
zUUZ2L7lU|N8<tfFa0#aEL)RdVQabzHAx$rlKQh^&UF2hc<o<F(Rq~E{^Y4ck`0OU7
z>zcXfWu^6=PIcDu3%sl=@7VsZ-g@}A#2MfAidIV*q!Qj54r-uR)}0Ms0`}01faerz
zgP9qBzK$h|)gdzrj^Bp8Nx3S3Gx;pql-Vf_DY{L%)iHbrsCX7>8?n~7^|a7hTWP?`
z%K^4n93{;XVdZHk;ZbOTt#xhTvB<W27#EqgAZ3cA**`l$A0zXy*bA7S4&>&<Do)gZ
z0CI|tBO_V;t35R`8sfm=+_0*7y?(W`oA)!`=ObtbU)<J<k62KU&)vX^_vYVQfC4&)
zG&#al@m9auc(>hIf9dP3ne41J`ZvS393Llj9~`cF?86fMhj8fQoy%A2Ur^^+i3odf
zq_Iq9V6QVO=-w{9MzTkbIMnR<%p?i_1us@r<4+y5vlG#)Q*v0Kgsgmb6sYA^0<Fs{
zT0Yl_8Bt%1?3G%C$H<juQ+U(Da@<(#$kL=GHwQAdl)^Dy^M4%)QVOZ04FVu>MhB&S
zO05e`E;c&UdQ;aubM)1I(Qf29Bd}{?oFB^KgFdxK+{ha0cv*MX19}H<`oO<0823m6
z%2~2J%V{8McfF>&5`j0ti41m2NC*^2UDGVG2F#_D4(<(`)d0#>XK)Kt4?V}bW~Ud{
znm%Nfo4)hXm~vX^+E*o(U=))u?(kfgvMzAeZcrn%j}I5}!7r-K3o`t*fS<JvKb2M>
zJLew)wBS08?2q_H7Ma6BWVNr)l!;4*<FzJiyR;DUKC`?!H$8D>8SkRW;iP&q{c9mz
zM%BSKHZN)mS)cmUJ23a8%z{MOPpP*^4fThU!^&M0r@bb*&qb`X;S~$p2dAl(sR4}2
zOy{@CEB5(;^h6r5g?S#Hv>>7EUybf-s^qc3R`tKZl&#js!^5H%CZ*3?E7kDt#%kUA
znY8GgB?^zS6?wd#OD|<oVN}~h$5YN;Fe|pQ40E8X<E&U(rbV_rp@0aGz%Iu7zYgA)
zC&@4L_>iBL;#cY<Vl){yTT=|ljHVK7#cYm@kK4}_8rxPNJTuk8Ay1*OF_ymWGZ#Cj
z<t(>1JBBuUPzNBb(oA)xP|0p1)D+GTMFY;t=J=Qf-K|pP4#&wu)q7>Em?6$+yJJXn
zRww@2Megh@M}(bLsz`@@BDOBa!r9H}iaO0mkxS>*2z)1pQ==Kz7<dZYo{)NW#oad*
zc2?O}h%E)xjii99>4aLRGW!U=u%EfpW6l}bSO2l&H3LsPxy8?_Tf-v*iETGn5K+Zb
zyS~;>i@e&;hy7l?Q_v$i-ow&l6>F%dxrt+IP!G|QWx}pjd;ar^OH-Q>S!~q)Y-FD%
z^2LXf8rqp|)SYrNjMnA1>F%Cit3I+@LWr>VdL+=1QKWcdV-;;=ov=+ie!UU2E!)e>
z6VBkR<JmY-?8Sq7mzeWEIw%`dGveaLHPdF?CHd6EUt-+_)i@quPgVGd-Nn<45ooBp
zNu$Amy->DVGtAt&rtO(OclMJZGg>#oSY`ZeXk1`ukH42i;+^HiPgFhId_f2N9osO^
zrmF_=bvEOfysUwD{9bDJ+1~_+8;g(OoIK;+m+l6MoaB4v*0036d@_7)Ni2o19fc&g
zK}63V=k}0z&Z%0ml$%zco$9dz&`vOkEBxqO9mnomjFYw2ITts)M1u_YSQ^9TCB|8w
zvMM`bzyfA1oHlDT@toR^_rAg(O``@~SQ(q!3PrBwMM67{N&@*~q|?tAt>XJg8Nf!f
zn?vT`qQXFQd^S#Jx7!2eZKVJYanTOUcAyj?e@pa?*w?X?f$3V?=}?Skf;7y@u?6*c
z41qS|7EZ2sieh`7)<uJMSBxz(y>Qlpeb#_CQXIe2o8(^c<aCd{O>){1?<I*tEYJrv
zOzC>6_>vs12_S=OR=JOF+6zL4#`)6^6<NA%b{owmCh|pl7hQ>CNl2!+(c*$0B$+(V
zU$FA*#b0aqk0d?yX!vhVrT9EaC=KR)PZ!GXOYcrM>w)J3(>s<euoSZE`nVk(5naZr
zx!x<0>nrYYPonktFpDMj*LYG9Z_erp#?>C|B;=2sTy;xkT1$y(tc=qUyX4B1y@bzr
z@7rGFeuKGQqI?5+(vgJp&lykyvx!D2hR9L(u&Uh5?rzuvy|Fh2y^UB}ZZ7U?tw2L9
zPT%ED1y<t4q=+N3_;0bcg6R8tselQpofhv6fuz;abC2TKyuw;`7$V*?Evj;jwI+Fc
z0T^CEC{ho)5$z=f?I>kS!6ubsgBMXJ#~V848*81^Db2Slt>PABv8<n?S(O!@i`-Yg
zh&8O_zN;yt;PfDopT2v!6*Yoqyv%$0U{{-ZY%D-UfQH+)*6sL(iVNH*m5x^DWGkCB
zRjw^BSSPbNt>oC=h+=X4W=uL_K8`rHW?fcBR_p=xZ^>o?nmNqbC`ERum1Ts4O^8Q-
z{)lFc5#bkVaNm9Uh8fFBTmAJiM?K?hd6ja+<b#&O6m8`vl<4FCHV;h;+26~T6N2G>
z6xwpV6$5pzGFlCzP!ogmLSmTu_2o)#A#(-HrcEQy@!~TzLPU<vE|+Bw1xMGXgxR=x
zR82*Tr!s9pnTTyn<F9S(BNg^K0Vi_h=?HP7ps$aoDT6+eiUhkX{IcV*`S0U3OqLfP
zrw*^uHh<p))yFhcr50iujd60d?-t!!&RgOpxGtBA2d&F>?k5A!>ombD92HAYGL#&w
zX85L<v+&|K2*uBlh4=|-KGo`me6i)$<cxXUvx%N*BX<6;CFkuPp200KDopu8(;EXp
z^;t>Ep_<}@M`uBnQQATmJ%wsf%dHI!wT(p5Ns8alGEI($f?CLFW}X@@4Q=)qy)@*L
zQA4e=!D6;;`sr?E$Ki0}m1!)c!)cic@gS8Z8hk<Uu2$}_qG<@&rE0fi(aSnLrBVTu
zL-ws-eQX_ve2_IbnZhT)f&cSvLCL5vwJ3?qSoV~+(>{pg`G-s^^N6~c3Gm7YM=#$8
zXayNyzk;lz&}k^^*G>-OqoN>j2H3^f?yk<o&jhK(WE<nt6nF1E#a{GDFms^^xY0fF
zUEcU13F(xSDZ({r2r4Q=L?Q^EQ$@RDigSAH<>$b<Z3?tj)~5}YvQpd$rz0bE1_xBg
zBJ!gjjE`{&bTqv52XuDTbVYECdoCk%Ub%hlCz?Ix8}=N@-4!!ZyO#3G?=P_>n5ufP
z`tc;(2RLyfs3c*3*?sJ<em9p}84>49@dE$}0~8rf6XI+@*sn9bZ*h}n5}#PyPDP~y
z0a{<DOMY{4nsm@~lqzYUapI>MO&rGK(nD;rP09bs1)%t7!cQND|M4jm;Y6&{7+bra
z1xQvS5c}=dWm-*;#Bf<S=0}tdDDsV-!7>}$Bw;fH*{W)uv^Jiq1h1u^pv<BKixT(s
z+w=HY<ryDG+Fl;_Qnq_vs$9pS*WN4oN3Jk{%QqTW`X^_{M<qL3bI*c)_!%9NR4%is
zf;Pnhx{ymnb&CBWG`(=hB{Nmbg`R^-C0kd($y!*V7Hvz*g^@534rQ6OON|c_fyy1h
z{%5yJlfuYeT7+u(qJz<U{DpB>K(Cx8TmmT4IXk$Sl~achn$Iz9i=>&%;7PCC+gr%S
zpcD8GBrD$gHP>`DV1#ld-rwd_&#oeOE3ede##s);lB~nHV`w<ZdE4H(4s8nE1)5Ag
z&Q-zDfuk{QAw#>tatU|oSo$P6V;3`X;CAo!o0Gk7OuVbGcTbduD4@W2!4gtm0j^Wd
zsSz@^S0oItOk<t)`m5r%n=$qPC^tBy3PUU}jy`Em+||hvE4RBr5!?PKW96lt&^OL*
zwm^S@umw(XEyqx~K`i*^<u}(GF4=%FL8peyx@MBwJ=mwZz-LZ_sNU?;we3)q50h@*
zWw)0GrU1utP+oFUWFl0e)jA=88sLib!yn~_<*(k}{ngvp#4#o@f^4A4Mp^*hV{yHI
z0PW6x{5u8z4_x>6U2#7!usQCk`E2x=?v;|BrqBt?y7T?%&H2us6pMp-Bxc3Hwl3w3
z{d$pK2o%l$KTpW`#CCtCJ`0?onC^S_V$AxXyG5`c8!u!n^Raad$d3vEll}Q(*r{@<
z?@@ZI-_@AG`w9dciNGW8mNuyK1lmzpA&hrB%739vXwejYOODi%(DJyp0RpN#s;v|R
zeMk-Aq2ynB(qZc)SikhhLO2@BRx`d&yU#MSu!v>&m4IFjO&;KK1vgg>*WG;3J=*GR
z(;{`OBfKh8rf%=W!aCms0_Y4*UkyTv&>bNA2`{fU&Cza2IUy~(vlT6bJ_`#0yO&1C
z2C}?oV7KMCrnsA|Odg_F@uJs6Rn_K6`YKS-y05qNbsJDANIZXgvau2aZXT>K&J$p6
zkMwGxfP5y1K0V%WZ&8U3C#>SU?J@d3TT1@w;`C~_XT2W*t_Yeub)1mZM-L`nULO$S
z;oxoMV4A;WM5-k#<RfZKLjR!1_|3*X8EYA)-MOm@lAUPN$Nv$VHN2f*;j*lm2=pRd
zzJTJzq64~Hp6iFN-Tg>ff&jreveow0gu1idj~v#8ujdTDRLw!<m6iHkp^E<pi%GS4
zm=nKd;I&Nd$A!0W?XP;oOj&)A$3J(IQI+J<hRFNNhmAAjhn}xDg28w_4RZt*3>1+j
zgU<w>t!d==zbB5F7`?N9S?Lp4hs9^*_Q<@MH&*0o)RhGpu&7T__EYYl4A`#S_k5#K
z$=yJZvzZW}w?s`83(Ydlz&O@26KXN4yj{m6Uyu*(<&2TCKb@_>7ajaW@}=K^qRfv1
zeh4C!c=_$pdENW872&E!$kE8;EKjOCuKLcTw<*N$FV82C`&+zuJmM-AD<Z5%q$<$#
zy5qT4sO0o*ihw`5)Uni0!B$#KtGST^1&vj@!|C$TuX~?c2r(S1ACwGcqf`-1oRX{$
z#-eyyqain{C^5=r)h;5~dc?|7$}b)j?B?28&rKR(Q2XNiu>9bvRQQ=54YG#KaDzg*
zEMt&UDBw4~A%ZJD6C~F1Jhc<I578oeij0766k_r4;3H^eh&X>1{jH<=1tIdM>t@XW
z0T@6BcXInk@Y1aFkhhE0Xu%wISiWl;Hp-ja;@%=f=ivc8zos|{_20YOX00mv*kRf9
zoF4S-DWLwiFYj2s!%$_^l^YRAw-;>~{)wdD&OIpaoolme#su8nYtc@AixIrAqt^{$
zdoMHP>kT*J*R^0fctRzLb`s4MJ)yy&I^}eR2wq*aC=Z&Tw8_^1K*Rp#JWdTdAbqo0
z=y7zvdTQO(JJb&9?ec-YLdr&0kJdPbKK+^C9=Zxvd7JL_lZ|-|J$>Mj^RVltb-xe9
z9uTqfU|DEd(O{UwH5V5;wbDPkgu$3!w^o1L2JAlsa!@7x0kbHYBGTtC-zDHwkK|~^
zKLY%^;dfbh18YT7LY4awTg-`+Lt((5Y<~$MsIgpVP@G&eDe)h3Sb=Gb@LGDgQ;NP?
zaPu#smiVi;?DoNOU_$6;i?()P&#$9fgFxiog(pomlE$4M$J;mv9mB&AnLg2Wbo2rT
z!32!#+>ez|0-d`n`26#~yk`{S7RqDH7$wzBal9;8d+gOV#YO%!k&8E^)NSj6zvZ(i
z8l7al4JlP3brOln!#WWcBAH||IZ0k$gW8OnQI;%G_-@p$vs!7IHH$Zh_rF@Kdl9v)
zR+n#!P^F~bPYwH1xeurIbcc-UPTNn(>iANS`(6gw;sTG|FfyOz3@4B33klkOO5Mp~
zOk6rscaM*R0vG3i8c;UyV3pMDwt?r?6Ui;Hsy=<FHKlsBZS7l<YzfvhixKvFMMi}7
zjzK=o_>#yEJUG)de$Ku`r&oIr{I!(ykPk*M5rVb3FO50BJqlQklAND@bq;aNzPL<m
zO~U>nG13db*6!h|vM<}5_!6jCjXRgSk2H`7_@7=hzld!SndsUl5)bpuQ9R?mUZu7n
z`sp8o#|P?Qgi1o{U$i=2-_Czw$&XZUOqjBK;g1@{$8Z%^L<_TtQXEb_OrxUw;>_^J
zOYXtE^iz2tHJyovm`t!A9G&`@uT|a-^hx2L$TMnut3n}`xFde<q#>k(A;naLEL^80
z>2ORl9$rFPj6vmW#$Z$3kCqd!dQ_dlLe?OUCQ3@ISDxw8IG9&Q41;L&?iKSyY;9Q3
za>N=u?^Dd@je+If?xdl_dF~Rm*ouBha6#{r>J84T5jS;Y3qd90W6J_Qt$B}TeDZHx
zs5R!UOAFxQz||<2JJbmOs5uR@pWL>UMRuj@Gsv=^dGh?0Nw%%^cW0fdN<V!6r__^c
zkXT5TW4@7NILj~ur3(+X{4vfc3Nb#Z=Ku1?2J!e=IvHs2;!J}5TcKYf!6F#`68_Rz
z-vpJuQK462Jo&^K9lKKML*5)7ik;*C6lv$$0J(1<nzXHDL*oM~J2EW}Qf_X3g}hp0
z34TY{C!NqoeSOhLVSt*zIzfbYv~{X%&&F`;aG$r&LPDwC%mSfr;TYB?uDe#uDmH0`
z7Z@T<U(4|4KQOVuIz$mYpCDk>sNA?X`H?dEUXAQSx(oI22i1O5V}1XL`11PVAAh5R
z<sl<;OmxK>>PKryjQsIM$Dsl}VugFIT<Baw5@VZP5RL54Gd4M-2V43N>-Ue}@P8%k
z?>=6t=v^@!M6goRQ<_)2B{e2maJzs~aci#_CD|5`YFAclFzhWO^yRIB{>NFFWABO`
zk>I(z9uN1nF7V_H`}wu+8B$sc+kN;D@LHA<Cql%L<b;Ll{Pyi&#hOov?1-?20I}x^
z#`NS-AYp58(siObi#p87279DKDddt5Kijn-vT+x}91AjTZ^J3O^&TIu^@YV8IO9wr
zkGJ--eS|5=<Rp||rUNrsTp)BmKn`&|G50oMa>m0EP6iWz>6(I@yI40sy<)2-?1w9Z
z&vBP%`CTkEb_5SRT)yQr(%6ItrE|Xb(dDS?wfa=2j)~!UgX{HXx4D*V7pd+U{-XCn
z@zq<N^c)O`FmyELNqpCm;3>0iYE;|&<u*8kMZWnmP}Ro%MRd8mFGfl4@Ux~(0oPAG
zlS|$+WWuUm8K4-;(nf~^YvPVUks#Om3(nVJH&k{Rp5?oFP?akqDg*0wq#N^QJdw7V
z^B>d4gl58rwl2O0*Y@@B^h9qg2AoBn@P(0fH|i-EN0j1DE_d`}K+$a)_)NVVz<|mJ
zQ4%jI)|J{h7=60Iyw0t(uheq4Pdxvb?Y%<1+SKGxBqAhNmR$#)!nMj4S0u0)rY=nZ
z@tb?Y#VYFZ47Mz@wl>bzvb}cWT9r;>{Ab1mk$pT7irw=Ah@ERZn#+IEBb>T|p87j|
zSOS2*J#ex@o9>;=hQC`~_~RmliFdL>z$P)trmHr83rY-F7z%=r+>9J&*8r-=ea~sI
zH>C#dXpvc^y*B4hMfRV5n%A~}UN`T|R>I!mMT{|TCNoHrzr&p4hr26$y)EFvIPyJ+
zwr+81aryeY?w0Qs-vXJs2GMvG?j8{u3zr(7GRZmiqb47#ftL3+^KJ}Z4iWz2!qg4-
zEbR|cdsc-2I*q+iI=6OjOK(T*X3`rE9~a}3^&@^wit3QYod@nv^U}vyNG1wt{lxU*
z<##5j4+TZ*2C&D8ISa$1Er|xbGHzPF<mc`}ZKzBD1}FP!w+F7UTQ4)K*vN>5f@wY1
zFiZ(kPIsuyR@B0PBrN3PSuRaKT4LjGU<N^H+x+4Ga5@PzG4<Qz_4di~LJ0v1PMyuq
zpFlq)1iE?4>4rV0)$G@mWqKLQhHzrT?LsuRd<1H&L0zQnw}$v&?)IQkMvbY;a(#+Y
zvhO##NCtaMgp9^wb(8bev^wOl*^}hoau#cAFJcR4<pBfuYM6{~#EU3NQU8NetnIt}
z7w!?KzjQs9x}a!Pmt-dC2{blO7cfvk4YN!jI8|}yh`g>hb@Ourm(t^`Rh}RGN+>ti
z7Ojo?3ic}p+1x!BXc>u*pj)wH{8)QMxrLbSgQnuz3W`vy8K1&{dos?O8BLt9E+6`Y
zr#{Wq$Jg|t(S!BYs#(JmVq=2HR5zZcn_ZGM(hl7g2X?I`^5^j~rtW*>7&_)M6Eyjj
z(c2kcnns0%Qu*V}A|(3c**vJJT-_&j#3x!?!QU6Qe0%v8@Z&99i&B~5PxAz^=gkTo
zv$+q5(cG^m<2(XpYoRI#Yl&q{80v;5+sm6paiIS|=P96*Uym%CFQvrvg<Kty?kRi9
z-JNzCJvV}$b5SOIc`-9JJ&SDK40iMQV7|xXdn8q^?y{t$&f&u8_7YM?fq2&V)aC%a
zTP<j?5kVm`WduR5DO=1B*?g{7q;84f(2X&pp|8KH?)O`t@TUt9gd#TN-(6W>WFc+m
z7p>P9w|O9u22Bf)dv9-Tt<)>W?iMik$IEQ)U3uUuO5C(Ru6069waTeiU$Kn(IsH8%
zb8_OxWE+Gx`{aYU7pZ)9bWKEF1uNx(ql>ot22Y695{hVEri@tJRn?d}YD|O496vm*
zRZ~&+?Y9UoS29ZBi_zr;*GSqQ-ppi0=FBeDM7$Wfy$B-{Ftr8_d<3(uE_|GsZBQeJ
z$O9}cZsl4ymWR^21|>KPO(19cywuaIs@5znrSKYECUuL{#LvIkP@b8}-zy#;Cj$rU
z2~YOlpX(2<9=Y?ghe%^5o@xV<hh|8rQd*IyHfp3jX1xtcjY&Z1mGc(bMQVZd%Q2aj
z`P^(qB#%Ru`DVN33W8M42TL(}c7f5Sb`?P)sEQwpDNS_`a~qVCuF1D-WYtoxOXlg@
z60qxsl;XuLZI(nq8JXUO>k;WdOatrt<?qYHF&joaJ~8AO`nx(K^+#quFadD?)8R|t
z48)D4+0A#uVE!Zu9U#c6+Q5AZW1m#{#ZV{Q31gM3*K~3BTmjDO*#`pzUEk?_kLaN#
zEuW^}3)<@El@)kq2C%;@)du<WzZFtMOQ=JpMFz|Sf7JJ^c>#pDvJ|5DsTcd6gnkA9
z(gTaXj~u5_OpMdO`UEJNjG4UK`qy^`#4{;AoSe)b8jQ`}P*fufEfgGmbY<>f>9@cD
zXD?s0195t6W3-gizjE1t**Zh%;y*LujEzSDdT#G9tj}3b56kBRt`n`r!-pFPA^Ve8
zoFuYnoAoyulQP|AW^IAx*8<v;kCes`ws=`{RRsz!a0^Os+2JF60;NUjm>oJR1s1ka
znWy_Xxi?fpwUsD)fGLo1G8pmk6D#Si)nD83T``Rc9;K0TbV4S?gL>wv6n<B9umO(z
z^qzuJ9-V<=JP?pJYfsM7;3qdOeydYuP>mv}VC2K{T!#-hl6Ol>+oGk!OT{ANnnigI
z)j}l0YRG;KTU|P?d>UsPE{(;~{QO|Pz2?e1^w5#04(o$v_d0jvV;(xWCAPAvls!dO
z3HkQJt0bGOYC}KoQ_}&c6oqRP#F!VX89$;P36+rAxO!bb=oEviIL*~KP+aCKj-dFW
zy0^%qVj7^dl8vFBM?GW7&L$(mW}JMBpXZ=YhM++cCq#eGLQ8s#g?QXx{bx&*Xiij*
z{x{iGmqI4$d5o7lgnChYbtA~M-|2k3Na+{LySE8*X~enKjjl?#YoOcn^1G<<B-wdU
zfCdt@Vi{XpB!BGZ)S7@f#sNGwKa;kEg#D=aX7cH6E;+(@fV0N{^WN^xQkL88j`0L{
zBnm*d0P0Wy;-y4zgqozS!-sYDQ}?;14i+R5BgZ9!g}qVx^3xk>qxxjX4GKU3J<#OD
zMcmW}S#8)#nf1#;%_)bc6K|!?Mmi}*gj>`2)y*ObCX}z<K)}D=oHXM+DoGHBO*g%R
z2n%tXB2XPluv-PIip0z5t$Kry)!-g_wd@gyn~xj;dq|XZ<5VuglXqFgM|w9aJN4L$
z>XHJK%G-L2i%&wN#lgBqDJh?h`n4E54U1mh<X9el)2viDJ3<JM;B<N#^BMc@ab7G&
z;ysWfr7q%He0cbfx`a{vzZk(^3k}sNs9#LEQ`)M%ZssQAJ%+3an%!bO-{l2b?9c*m
zg4Cg$3@JjPxpqp?DB3*SzKe(D9<{tYxf!t%d;nlN=U|hkr`tBr?`oF2j5f=q6jL3i
zBw~5fO}hbwJWOnY)o`+^PSanng+a}%H61Zah#BIq=Q~tVTvOE`l{Zxns&9+Q)KTx1
zklUjg<9qD&_WI0qSFL}lX2gx<EW#URNM#|T1}Y;xgHEV&jRLRTl>JDpe~^i9Gm@Qv
z?A{&E#h>ku^_ildkE#yVD;8S3wr|17+Us~D$|z>zXJ!+fmrXT&N+m1tQL2@uIe0A~
z=4QXo#o=8OljQpf-bi{+_wdcW=K3F7r#;j8dUrb)o#`N$oZ^G^Hd3G3DIB%a!DBr*
z{2B1n545y%>?uMoGB0#DxE?UtoZFi69FvhpT$j>PUY40iZl1U2eWb(F&j6(H;q`Un
z9+D5u%mf+6)rDwB&O+hpKCrV%a!8e>Ro?erD`IwM@}8@d3YV4f%D3ESpVeEqunV4X
zbX5-9eKwp;Xbe`z?sB!JOeiXdgRUKERLB@Uo#2)_dt7wAKQW`a#hY}vv_o=v#aWtE
zsIPObIVUX5_ObsK7wvAMko4JfEz=nv8S=m|xei3}dClmx0XQ(wU;{zIxpDQMrk9ZX
ziM{n`4*Xsw{xW<*YC950JAh|k&tv1X$<-eew87PHn3A*bwI4HD5(TC7Xd%EPYkt9)
z`$Ksi0c-P4$q^&@LUTh+Gk=;vJSIF^J-+zA@p`5p@?CN_px(y7&a6b!zUv&=O?B%t
zqxAH6)b|Pe)*>7E1+%gw_D<R#-#l)lQpZ*;$e@kRt9*1}G62PyF0CnG)ZM{Fq`WHI
z6t_l=bk6Xc57C}Y8$3YP!9nSQmzO7qHeHH;zXI@fzryG^cX;Jjyh>|HL_)O>+48Qs
zi{2ko_YQ6k-&rd<B^`3JB~>D)HSh{l$Dhh`S-QKO5VgzT?}4W!=pD>^Q3Fzht;egr
zg`!ZVd*M8U_UyT`>ro1Ltm$t61%4|xM<|y>xr2_3MDnj&65pD{RzH4S0=@U1;2M*X
z8@a>W!S8m5e>`|SYxu<LzX$rT(eUO1vurPpOE^G9rcLPWQdnbw+2ogdm*dxz1|Jao
z-k`VOTN9@}cR8`JKe9#s4ZntGYudFNXm<X!-N-k)Da2a((ziIGGfZ^N+G|N*x6ccN
z>!cn8oezMWReS&1Z}`zt9ORnN-#3Z#Dc{@->dOUo(rg(6dJ4=&&UbTwBOfBOXGS@-
z;~s6h;%_f7d&wYsZATu?a>G;##!R4!j(6KP?3+GZ5EmkAD_=3ES~fkIurK5HDP&HO
zz!wK(xQ_urT@JtoQm4oruhlXq@R(ZN*2<DFzFNs{L$D?JOa3qWEBh0@fAmr(dz|<9
zjk(q<<=wKqD?hErX4hxYE(mvSU*(Py?F=({Y&vF(Qag+VU6NyKpV@zBY6^@<UX5ws
zn(Nu*J-&!n&%uOQT>5PFGG9X9?Y98=5E#R&Fl+wxrIgDeq16nYI>Ikw)OxM=!#Qg4
z{|0*$=cjFcwA_NqI7^K@A4;Ed0o|Tc>^W|9Ehr7W?q<q1b-(JW?JcEf`47Sj8l~we
zXB?(Rd+2SErvW&c?|%8)O+WzN>iBL+drD<0u(!pv-swp=>;8O7Me4pV51?W3)4GSZ
z<=t^g0k^BF*Sq+@*XKE_rOHLNW=_T&-zv#o6@S*MLrvfT8VSCsPkMVN#QrZV8iXF9
z_ybOLqcw7kd^w}P$a5HlU_<hIDg$rZPkFwvC$KSown$z!a7jjFGO(1$7(1OY>!rPT
zoOjQ=L*|rfJb5>O)PeYf^Y@aGj0?}7TIHDLjq|j;i9m@^f5ZCVs#y)EO*`G1XV7Qx
zPdQChTrOX73@c{^g;e+u6~2^db>U4T<#b;t=;h0Ml9B)%Ffg0Bdnh%nIrhy{@wj|f
zkc$i1q(wr#JQhf@GgUJoLJdck8nnkG#}r<iI`PWu?W=!GlswX(jiQAT+<msLcQ$xP
zIo~xh5RDX+siiJY@w)#BAPf*+!tjSg%iQp+)g>nAKo3U`4YFv_6(IXwvP*<Nk9+=$
zCcbZqbfJnMBkHr4^bX#XpV6Xz<yNU{nGAw;(`ma?9-IXzp*SK4xIOy3Cf8UM#6I;J
z7IRgqTq6IOs)J4xWkB@67hfojgzzKk_<8cqp@}l4sO1RUCxPLOq_I#_lbFz?x$Sq)
zB1*rT<H1BWut*3F#J)f{{7pF{OG!{dK*`!FRU+5Dp7f1F%h<BYrLQ;UaQ)Q8vab>%
z#F+_b+B=$li(jibRUK@}H(1DqOinxL0{2)gQWes?{eH+8VN2X0B<Ee`GsB`RQ?@r7
z{ccfsijXFLw)Rj3EoRJu>;iZlb~4D;&f4fmt51pYw0nPSS-roeX{DZvt2J6hg@>;`
zolG~REv1r^GL`v^{7pKu!T#zKJjvhiOCXtq9!^qW`^SlO@0)_;*+jPXTieF~H>ghn
zqcPhz&JET-BpALuE1yJ+$Br%Ty;B)rj4Wv$FC1O&F+G;g7V!E6Q4`1J?a<c;OJocw
zL3#$8v7TS>E5}hBwYipTu-+<f1-+zlyPpmZ*>V3|i;d)d6Xo!;|2^b5m9aJRp1H64
z)1QZA)n@YZOlR+x6$cxwAFwSNl1kupJ3H+IA|}p8_V1Ow|54|9#=8WTEt)3Pp}65p
zIr70PV~YJEjNhgmwOzK`7z+`*{lZCs=DdiHsPmL}g(C8QuOeoSdm#gJk@b`mi;p9M
z+;xug``R7gB)GRp{laEDr1`Z`$LAc6z88DuQ_mOV`_vyFeeJxN+>w4LW$}V6Ekcem
zgzi)izJR5A7kF<4?2N&R%*#ZVywmR6Ddv6S^>UV!YwaF^$3;~uyb!B4??fB#n$DY_
zRfs_$YGL$E`-r71`-nwV{0gz~UP$FuIHF21^j+pJK-Ur2jUC&dOX$1S`Eo<v7k=Sn
z{;788`*nOHx@pI<(Ofv^BvC4Or8~cLYAKWt?6p6~A)A2FNf&|_Mi^|1>UPQ#l*d>q
z^Lx#x3qBcb^}JV{k1w`jUQnrA)7oA6HSgKtb?aCVlW#pedCiN(u#~3;jp-B97${H?
zl<3<@P;=8qnk@0ehRO8$BdVf2c|@>{emM%q%nLL!CJj_~zFhQxnr`jVi3g3ZCDMx_
z>UIGLgoJ6y@X}>*4W_5BC%gz}(IPEjqnlo>dapoIho09_+r7Vlh7!TSO_ANGBX3y$
z+%K3+^k@q<711BtwWsINN3))v*z)9wKudpokd2X@r?E!u^_w08X4)%P)3tL&f2u^#
zO#b_nf}m^<6wwRVz)(<>*)tNnC9v3hlvcu%bZpxXZsOLhpHzgOrDE86-x%Q&(AwCn
ziRGv{j?XrdNJ?n`7g;Bn@ef%yJ6`zT;Tlgd&d2m#GmR(Fz#&xbJYZFEVC6qq<BAUK
zXU-PnLggxc!fj+xnwa0lXf*O6T5``)Y`NY~lw!2$8!RR9hwBmKWi3I{81ts@8r!Na
zRre8S6VLar%|-rWyM99mA^(ru@YiL4Hq;Usb-XOXJEy)QgYU_#ul~seFnEJagg|(=
z-XQ9{f@tR&%zKYlz90|<+pV`WL%lz&4n0L$qA1@kp#BzFAWwt6S+<*p<SJ}Nt~XB^
zL*~3}(uc{jl0vPc-WBOYAmk2eL0;L#?M!0+8i}Y=a9W1KjtYKb$YmkEdtK@!fX_EZ
z(LVQ*jze$69O>_DUo`)?QMwJo8tJd;VU+w7V=poJ7PPK*PgV?fN(O&0)k~{|9qr;;
z)4RQIRZanaC|b`wF7Ht`#8)PP<(Gep`UHGPIUdAi_VcJc@tAG9@AQJ-jn`8~3brkh
z3KpOLfcbpgwbU%y75<XZ6;=>X<kJokH)TJww*U&2tKI(#h{9r=DRikxAiny|bZ^!T
zuHQQ8LcrveH?UiEzTfJw<^IZWz<|Off}V`O;SA~(1!<0g7+k@>c%jA<h_)67Dbe3U
zyjUIuBCz;oIPOhzNwaXtC`w|mKY=b+dF<Y|gwG030eUp0?<b%if(l+N=LM(-Z9hF8
zVZBH&%Q?n^a=cbA;joEc1+>(B(q=*={US%|5wrz}{=Pd<Us2G!sUV9Sa={d(i>0Uz
zH!bG^jPn+0Msl<+WjTx2FQmvJ=qBdmrjsjgAnh4TOCu<!X8JWO^^BeI0VwERdxO_M
zXx-ipW0+p?I2ry70R>9_tQ*~h0DblY0(Nx1W?iFCk>;ro0QfS{%U^!YyM<!Z{IX@=
z7OGvQIMlk|@!+gH+gu9%jbFu1gOaekpGNm4@{{YDub=HNSC%(CT&-3w1ZfaX^8*s#
zrxfpAE;D6YvCU!l<0~-3#nVsS$G3<VO0D*P<U@vx(uXK+M{}HKG%LO>5lkz&Km_AO
z^HHPva^_e*AuBtE&HqJQUah)C8swEDnSiQUD|l0e|HQPZBfh3KKcGzm>Qn?sqOAGt
zGWv-*)?dpNB6bf8k32t=hh^)P1ACcGF{@|ZjGrXQm9N%LvDxDTB)bCVjd^!unq|~a
zY?&JzP4H|h_}_pv4zpnJ29;a8-Zikk-L({*=8o+&qL96eMD{YZt{10vDV0I3smJ)g
z=kOkgY35ntWg+4vgaID4rK+$FiW{boP~m+o^_iLU>N=~E@kx3Z)_LOkKnKvJR)j;4
zZ$BX|?da<TFeeh+ioCumpT)TcWByQ2^<rYCao9t$ozsjL3vJMX$H(;iqNa%HG--y>
zHA>0*PT3IogHW3@=gLVtli5U_L&j{8GF^aB#&T_m8n}gMSUpISiN51=0-dm16w?%l
zkn-LLUm5B#4ZwNh!Z78nlvPZf{x8Y1lR@P&6BKvZrX7fKc!!zgcmEkFn%oytVj@ya
zpIlRPaRrsJ`8NM+Fjz9%OY7OPJlY@S8g<X<v2x0~6RNbP(OQ3Y<-I&RA2%pME;4&s
zmhR#ijHE)GT|{ZASz63b4x5wT>+HTwYhYjXD-yE%6AnWj#pKbjPwHYf$-JSg#U?^X
z{e?pd`?n18MpjlSw+*RnSkLj#*pz&Szu%e8Q<V==C)DDbteAFIb+V$VAbap*_e|sf
zYlDXU<cui&jZN$Eqe?!qWASlAw@3D~2HmUDDP2<#TF+jf^;p`D^F9qwc)4;fLdl~-
z|EmR>(onvqY{j76JidOOvDXVXc!0u!#vfW&I}JRTXxgWZ9=ZH2Q)SAxgAvefw_jSu
zc5pyy2yf}2pseFNO<oUXQc|?}lO#&^1+F6hc$hAN$Nb!Vy_9P91B&5KOyVDk0lPi1
zDgO^^ZvhoY(>-|4;1Jv$5;PFp9YXK`!QCB#TW}}1OK^wa65O5O?(RCc%dnF?@4Nrq
zeb1h6_w3g*edcu6ba&P5TXO4nt7^`qQ}TTXBSiE99bM1uF5CYJblDS0{_%*^vR%KD
z9sfkZ!t+F*FN6IL1a4}_=T#}C_*$^FWFAR|{~rd?&0Pp;X~?FU$9IMB>6fakIZ}gx
z^uLJs-*%)s5zfC2JD+{E#x}OA{qHP0Mznf+SXP_6-^QiB6qh8${f~B@{<l+7SNYLT
zcZQcBV19z9hg~zCqx|UgpQQfJ1{+7_Uk^=_1R>Gpk%0hF&W1<zsVVjwARFx~NfN}j
z0SYoU`Zi@WvQM(xApzo&xQMI1<P>@_vtqb)e<yqeEwOB~Q50F;r|*QIcII=%zUKWc
z;y-OFQXLj{wNk#5D22M(kGmE9_dxCe;(h$O4hKLLWX~I8`Tp@G4+$RR{VAC*hCiBV
z^r=>$-7$~Qk+rS48CS5H3e%N(dEuG*v|~+yqm5+i?yqg-3cd!_P7{9swd#bT4yO1o
zvbCIoctDyZOXol4PhC*`Cxdi6ws&`j0ydjGo-a;o2b#4X&N;E!q%XqE2{OUVAeKAA
zo}ag|M*rc*xQ&s_iARBWB{c;|_>lP!qvi!W@kcI>0ScL7f2Y0qubE9gt+-`VilFOb
zkwck~)ATGp8#E`tBriDSQPYdIztTm2UuK9Ngr<UUTnzmwGSTg~*TLo3Dl&mbu64ak
z&=!bt7$2`dw@8Vsi%Yd~5+9(N_EJ?yE2n<;C#((q{LPGnj}c=dnXTx~*Z=xJ+nAgH
zHow=q1F`;fCw$(ib^UAGEOp3;TZ9N&MK`RsB`N?TIzuKrkVyvQ2NZ?C_uG&;Ei8R7
zfga1mhxp^7)?Z|uhp%U**b9JptQ3$MG4r=MI~d0W^r<cWe>NbPzF5zX0Y(4#jtSlS
z5#)5F>FLrSp^vhCf3xD(rkzLpr&x`=*W`Nv<(nY*>iBkQw<<Fo4Pl`|nlF!x--3|;
z;OR+U(9&xV!JonQ5QN?MPji2(A_MZ|KhvB1ZT<f*hwo08{!S9~uh9R^VMvS1pL_m0
z^xubD6)zf6#dtc7^V05oVHJvApC_+O(*8WG<+h#fqnxO;=or-09iqsX;EFb6a+7J1
zN5%j6??J(Xfj$LOG84t%m3ATjhe75yR1G>VBQP*l8$<(;@ueCI0u`(6ZuNO9p7GK)
znL_nxcu820$mIGlXIIt@7oTq}D{1Y$nw_m|=a$sNw^M)5`>j6q&7{AS95K}h=|MQM
z*dqsCbxO4PeUc&&X9?#VUbM>zTCo;NdIM<%M*7^(g-J7qT64naH}U81-7K(V**rgy
zEdzQ9c=zuHQV3A548I-v9zUgwgVPs1Km(AS<M?Fp7ftH~6BD1g3}^n=K^!wNu_TK`
zDtC-{5LSOfJ`})L*-zDAvs|}utjc@5LTNGu#yQv!N986mI}v(OKj9Yy{?fyfkDh)+
z$%m4J^<6pvE30m`%-OVb^;0SWC-j@RKD2|Jt8sfDFT~5RXA7iCY#wpBX2}u!$q`t&
z2@<S8C^%xpbmI}-2rN0#i0D}4F7oek+31D$paJMDv^?9LKqK7k<$RM+#l^UlTDrP9
zDx-$VK`nryPSO|6DfLR6W(?W4IX1c3Hvkv_C4*eT5H8NH>b#XUzuQet4MHY2w~L09
z5`8ZtJqiLcg61JAfRG`!nU<$OpJaSh?d)@j3Zg-AO@;?7fBkn2)yzyLwHBan<xduf
zA2bc>WOy<a4tAZn6iq1P42!=V+7w^<P<rmjk$YtL4>huP;Txd=D3?h@UnMPz=bP`5
zH2rg5Mm&19mUZ#0R6h!>h3w|?PAc#8?jrfm2f-{JXob6m{Y|^S?o;QNFPa2|jBL#(
z;<*7{k@nQfG!eF?n&jom^tx)?68f9vn!4C2^3sY(0sL-5;;gK1-$v`v#RUR{Rp=?P
z>mDib;1IKGKgA{`r7GeR*HGn|PUdxKv92KFy!ke<Lqc0wqOE_vgfn|dZBM>z0`EJs
zLu@Un8<WL{_(gS=e0(J~c7Q)-hvpOy&a8a@D!Z&kB(|P{O6x3#dN+P+r<)vjLaV@D
zSWt)!w`^k<&`MjOjNZsdAqkj`H2$cG=`_zH?ymNAo~9Jsf^jTHklG@|Ve{R^O|=&)
zHnJVom+-uwC;D$v-9cQ4yP<_R?U{QQP){{au<%TF4bPknjr`2KCIx6{0H|IVCf?j^
zc3JAl${DzF?J>zPQP1Qvb69{LDZn?sRDu+{_Gb;ZjYvp>o0f(G2{EzRRB#FPYNjx$
z2mk;B(^Lv|)7`{Jmn>1lgboBqs$T%m8(C-aU6xT8X^W9Hsu>qZe&olUpJNTqy4>2W
zhl2))sui#SF(@X*p-*m;8pmF4^-s8fI9HR6bP04A5p-i_R@%F|2B?s4pDKUJ^q$VG
z(H&{|_gPL1rKrWImw(}?p%fbl3Nb5v?gUg?azxKCr`6X%UeT8=lXpFLsA~CQmbViA
z&4GZr=uMl18;17G$6IuOU|9<?`kN7}hDrV1P--910AT0(z$%#W$fNqjjbbkR-LZ7s
z)@9$|aY1{l&C}fT1Cq$!$W$>)j>p(fS{{9as$4VSw7*}pbp{m276f|pal`=1o5uuj
zT$(+h0B64BVkRk++~Vbm-yUI8%sxvYN-?BPD}OniQ^Y+fM~FbBT)|^TL05Mpt;V;`
z>naC8&9&Ve@D!c(-EK!N(9&_1Wb4u-)MEq7PU>wjAaZ~anXu|8ZghJpDH-w%FdR{2
zhih1bd5U&$MSQP~_DL_<IKUrD1~W<0UsT4CH6UMW1h$u-R{L-keN&}ex7d0%pNc6S
zhc&YR%bcSV>slfp!*>Rd!xT27$>$};$J}>&9I5_Z8c!3Q5|@%%%%mV0Q@3mNh5=GG
z_>=$EH~DfJgNTgE^q%g_L6rgkpp}`TQ=C>m{kfK-TzVpKCeJ-PU*4|W4c#L{|Mtjz
z@?)sFo&S##+QARDI5H~?Zn^nkfT?g_bXNpiti(uO>eREt<?IqxBw+E0bHIa*U|DXq
zuEN}`TEi?)8`GSy&sxY$Zq3IPwa4?qp(!j(84(?W7F*!?j>Nwu5eg&oiNX85MQpLA
z8<hENK)rw2^28U+B+VJa=fj-vw5%FRoLZcT7`=2Q8?!-?oK08@s(edmb9!N&lA+KM
z`K3u&Qat%`I(T-R6K<$ZA#U1V*+W9y3x<U#3J)j+)t|SCq~o>uUvAJSH|bq=l7vMO
z&FKh-FcpntJXZBPs5bdn!?SZ>YH{-E7&@}AxbjwA<j%rCm&UU`T!wkHrrVz*Dut`w
z32-pt)k+h2y}5TS`BTpNBWuF#q7p!n3-oi9=h|u5C#E$c2`_&PsolbP>(>4@cwIbL
zx&X0QEYrlK9BQ10UNPGdWo_rAgV8p?OH7LXvU^JUA(fS+OQ|KOG6rs8tno`dBVBPP
zY)OqPT$Kq_U#qmQzK>pbLua^Ls5CtmjtVc3y$QBV5_N`aSuJ5EffQG5<0BoB7!V`W
zuO6cQ8zHc|QZYD5+IzVQ^$4DOpDKS!N!R^ybXWV3=G}_n5f%p<f~h&}7>A^48d844
zurV0@uXJ#;%l=w#sI5iLoht>VN|H-$U~Gv00BhDp1>$1f!+gWYCimkR)~NtF#DolL
z1;hDLV<G^!avh^vBO~ZAB>`l)GCSbs{1Iu;8iQ&yp|K?pzy<Y5Cq98PMrYfaYuPYh
zQR*Yq3J_b9nY7MOe*ZdG9lwg`u$~rE*up%tuDy<X<!?;LQ4zAn$#`{J0&)|rR1#xD
z6CJmZ3~?KceEuoj$-S<ZnieQt#!5^~B0I5y_A5Rmll;xiFo$S%<!!GDF~WclMDi-8
zKRFymBu3ZI3IrX+<bM3m?Ik-L;9Y=!^8tc?_I%X8?uy_J`X?O0UzhJ+q2vd36#sGZ
z|Kk!=L@*cKU(KMV4a>DiZQ|5j@#H2({od2G9mV&<bfr7#dcG~&^6fz#ntK#6kAH?8
z)(-&>m&&V5K`(b&=e~TYcss@oZDGDp^%<0~+zOqRJ#N|N<BAq;;<4FMHF)O%2X120
z=z-l_rNHcY!TVTA$^}H|Fl|P%?x-;`E=_>`czb}XY;yS^LXZ)jAQ%BKQzEym-Pz>p
zf>~Wi#4a0+&tkaJXdg9^ACAYwDsvJwov-V7I7O9OXx~R7Qt3t8`Pmd1o|gFXQR#m0
zwkkR4RtIh$Y7BM;Wd_BV{QhcOs7ad<A}x1N0BKlmXO$Ovj~~K!PLErX+5r+Y4~xT0
zFL(id>dk*1DN58VqJTZUjLLd|I-B3V{stm*!2`UdYOEMtBO{}Tru+a85H}wBOr+NG
zVAR|=_bKEBwDbu0ZzunPCd`e3+{UhI9Cju$t&pg3PB8n<pB!~KTd=YXC<z-Q4X`##
zuSXNwsYyvr8OKM}HfO~brVGAZadg4BmKSN8a8sPU8|Or}ozp&8Mj)iBdwHQyld<ls
zZsBPb;lo5-$QNAu6QQ+n^POTU0|mtJ@VKPiA*>`n@mD|W7TTtHlcnEQ!x3xTykFon
z?_@d>D+O4;kWqp-pf?L?xdN#^FdqC$t%Y(!{vEGF!31<e-iV`UJbBq_9AKmeStO+|
z%yfZj(9#9bkdoVID9jU1f-<jbQCwD5QI3s@f`}yEOIukbe7|nIljNdpxsSBu`&37g
z`*Z!LU+)^V&Qtx>tV>8P<CiFS-XMs$p*L#iWhj)6RW`Mt8jPQecXyGLIE^`3q&NTo
z${1<#L;xjyJRzj1*nF(1KoTRp-9mW#u~OAwAAYL&Al;97g3FuX#dXO*M<}sFklK}8
z@Z-{ZIvSnHGcw71P11&<J|Qc&WG0ntKdPK6BNp&cHOfVCrOoQS`;y9ocmR=4jW)H6
z_sz6J3bN)nZ#SLCT@;^VS_YkU$y%3N*9R%KU9-w6*7^LBns&rmhk%H_;vA@QsNcK;
zPAl+|StRrJTm-1`7?j7tr3W>a*6HLQ25qkMr%B`X=EgrV6lxkL+oV5%*{qCQFYx*x
z@$Ju3IZ>Dc&o$9bco#Ez{fzeT5tspXp4GiRT<@xFXEKI(@ZL@1W!hFgT_^e2NeF;V
zXB_!b)K;cpv)XPQJbDD3y3z9`kcYfLuwn)6^mzrCqyPXKl#wTUel$y6&WG}BNfcwH
zZ-EN}w6Fl-JX+b$DnC~}#Ui_o6@@pT0meESat;dNN$MCN3Zxj9hrka~4CQypL%s)(
z3dR?%FJ=JR5)vmfbAVlQT44rq@hE#S91VtS^yI*SrA1MTh-<J*GakVF5$Ry2HXcDg
z!eX#_FI`pz4Xk&>9L76c;KCux88D5Xit9WSj{>l+olan6X+ExvXXBPNG=!K0J;pH)
zu<56TgKQg4mAi9mKMN$}fU8o3yu&OO(0HBuefzR9oNux`FQslVW-vo{Ao&vhc;A$g
zDhXQHP5ID&6;qLcN%pgn<%%avWY^$ipa(=tKFA@XUNbV#%%9!X6;jrD)Y~|_*=)kS
z8qri1o(iN>0|B(_^`JD1O8!`G*R#`}-uiNI<!_tvVVejGt6BAUdG&Psw(gE>Vc9s@
zO$<Zwoa|3Ms%KNXgK^OC_=7kYVCo^Ve@u(*1}Oq~)E!Ed+5>VIjbip;rCuxcEW)D~
zsXo{n%eb>aE96jA?E4CK*Wt2gZmm+Oi41mgzPwi@K>7#sc3mQQpdG^?(Y_c3iuDG2
zLAapnq>B{??+^jGK*k%~?*Rh-pOmDeOjX)c55(Dn#bsbH-+TBshW3dMPT6U>=a$nC
z%a2*S73dKaYvM^fz9T)T`I5V!uPB4Z;DEPSM6`n^l-{5pZcYejFD_{o1f>j>l;C-i
zvTBwab)>iI{UjUBtLw<DjdL{*6qrIuEwtvlu&?ej!gLkbV-uI?9=mK7EzZiv;V+f9
zs)SaAhCvIKhc^H2LWP`VCCQ82;{^zY{+ZJT3~qrA`AWooi%PI8`-rH&8in$BgN5k=
zKD(a`{MitW=TuRaGPB@~A3Pr9LIvnNF9rZWG|2NkeDh9Av&`Bs8*9;!@~&}iE$g>c
zYSO)P^C3ULHJ6Q}p=-T^IW5MNYG0X!<-ww9cde$AVR3hDDsIJ-nw9NWzR3fxx3sQ<
zeRAD9XE9S#qc4qLfd&?WTKr)$FQ7f`#fp{t=kWEN<LyckzD5@i{Dlepd_|B|U4*f!
zrweGVHR7HXkX=doVhLJ`xUZ?4t0<@h8!GNiR<<{??B?)%WNdNK`L#8ie<v8iL@(<u
zU!=+$XWYZ375~d|TgXE7tEpiH>1s0@51*)Ny-JeT%>m7vW+qP7%kbO^+SYJc9Vdlg
z%fokTjSCYk6SCSl$T#>&Y_;Xn#l^)*rt#Vm_sj=wCRl)fgE2tZ+f<|=i``D9enmbh
zUSkA7x#8n`4B|$r<>0uJ3jW)vy!aQ1x&9Sbl~m&2pH2llkHlWzW8!_A^cl+R8L$n#
zt*^5j(c|1H)q2~owqD7c7BVJ1QZ}Rl|A=RbHJNdw)01SJu&!8g!AovJHQff~8rxTl
zk*K>H7l%_z)$*R7>3zfOl37|%RjI083mie|FA>+sLW>EVVa*ILP^!tOS?z__;abG(
zVz!m(4x6f(UdyBgII`ciVQ6hQ5!9T!U|BZ#X}NM0Kt#p;abdbi-=2Gc;zz>r5@rS-
z<N;Lt^elBN#{N}Q*2hvdrc!M_VLrMpHmm8D8HXWh^WBV#jH}reH`SH;-JbNt<wKgz
z<_AzF)@-s3gxf^3TmYxw<74K0G?$Ygn}zJ8^!woK=NyF&CVXffnYPTes-#d`!RM|H
z(e2!1&*!eV#=Wz3Ya6)3Zf<j1IDolr5@Upw4V<~)^ZGgSVQ%y*5h>j0kaw*&TEtWb
zZiF8S6B1e`n<r#WQH5q&xwh8~*QA}cI@;pRD-M)bovWlx&9kJ^j`ena#pZ);&@ja^
zQG5F!L}L%?mSyODTYRgMn%^m7c0w0_nlZmWd0%St8I>AZI1~SK(x5zZEDlX-E_AD*
z=QsLGUOer(p>*xUb>8CMo!InTTGO{({4l;5cxL0?T0<y_ramRcTQXc{yzD&JejHPx
z@uGLut9_EBwgHvt(4^WF1+<oGlc!|V-vt}RAA5Etm>NKw@2^^pwt-i@{g*c;-ioRM
z41ccN7Bt{PHnCZ*e_g_=jCN;WX^1d31h+l)*ZENLH;OMk*IxJdi+<MK{usi-zXqqr
zCv@FOSX?)kdE`ri*S237%Q@y_y?pCHWPQMSef4KEa*u1`Og6ZyX95B`JrfmmSAXDd
z5p_aaRLPsj8tv1<Kf#@UeLr~NIIqokBJ1I`OjBx-H-6NXvR-l6A5DS+*dB-ybd}{&
z#}-UiI0PufE3`rL&My03YDt-(6E!DSv2tkMJ3`UrLa|f5$7FpckK{5Ai&aj_VY!gP
zN0Y^8A5nPdNaM}pw!fp07pyVkDNgh<-)`?cQv0YEHN~#;I$V8aR2WIfGNKM1E7$uI
z|J&uM8v5yo$FI4dJaOb-3jP#<|1MQA+*ng8IeouKQbpdBiI`C%Xie2;DyN&r1>eIU
zkhAx8zow<m8&(^q-N_{-y`bM8csgo*Qkdz}i=M<Plx>gSTN40nF%9sRC)qj3yeOm=
z*6l|f!I0u!p{7(xG*5!SClZFQI9PReRbK~h&I;t_JMJ7O2RahVXM6XARBEap>eBCb
z+C1B*6}m>0hI+8YG89P#d2Oh(&aNk07N1P1g;Z<o*GGD-iLM^4^!NZ@<~!y)Do*&?
z-;3Lwv3-u~BlMa1cw79PQj92cA-(b1_SbAQEVebJp`)?JIxAEfE7<Y8t9L+})B8#P
zvOgmF=|UI1*MK0MMu_*KE|oX4bJ#GK4-L@lnN$mvFP?-h90QQ$wWU^s@B9W9{4m*=
zpNfOQ02On65dO<7>l~M7dTq`B2Ws1n>p<GpM@bB?ub#d(J$(DnD2rJr=;7%Wsr7W7
zkXf2<(9zyLrAYv|ol4%Hs#O0@AthtxY196dPzcO^EHjlI3FOPzF#d>7ar^b-0yYiD
z!B}{k^OPa;`+S*SEmkAlfD0J2rR~YVvjn|{NjQ%f>4I=v217>oTEiKnjWG&9r;c!y
znwK?yJ;8wM-J*pzk?vyKlloXc3X8?#t_xl+TdTzcyUzWf3m=trX>F7HvMSi7W!}^B
zQ&FWn?H7ctp_gw|ZzugWeoc)v=~qY!3jQiBjh6j!+i71gWp?`&QUS_GE<Hd_qPcy8
zC+2hcdi(rv(p)lbiK(0Q!J%+q9FOb~xy+)a;Rcg9Fmnucxo5L*B_>Nlqtcl|mc45a
zhGiZr!yq?Q3^y~leAcid<E!9<^{>w5ZMk8q{vk5d(OcZ9@&Qwi^#{?L9J9hvv#qwi
zEz#W|Khj@5_owh@zPmW0UTC6~pnRT-H?7irX|GD<Heh9E+sA>@ZPYi<hJcM(S=$G6
z6yeO<#2ArdAOL*(yC<x&{WkrV@WsoWkH@(IVBuxE>3KFEp@ctRd0W&<^zjT%?K|`G
zv6RC~8=hF{*4)UX4~JzzzuL!_6*qE3blAeqr!q?cJMVw{0$9Dc771kzKg<)ml755p
zs9bSi+}rzWK-e(Z2zn1)8cKy2oI)WQL!;}?Ii8DN8h2tHQlYd9na_4&0gC}2I|P=5
z=;?(T%-ggC$7#Bay(athKDR_=o2Rlx6h_8b1NzRCncaNO&Y4g9oOV%+Dr8|k51j!v
zqVY{fOg<<bj1<sHbB8UPF03yCJBh?6*$1rfWv7W#3xn$TTwcz82XXqLrboDSk&g@B
zsd0x{wbc3SqU2em3K^<@ALU$doT{=XI0QePHT)QUTxg0(h5NW6XGsXqcF(67zn8zY
z^BWvry&E65>BTo1R3+E;{o0m7IJ{|h@?fhBsG4p%drJuru_QW4Clq;?=o2O{aHyr2
z6D6ab+2C4`;n<~JYBqYc)^gDyKV5rye<7iVl0!R`yGK-K4=y9<+wB{l+PT;^6V3dV
zsG|lia|bDZDnOjlb}>~&j$OBQl++*$>F^h?PyAozKWMBa*P$zxQh$3_zSQj&<uYfO
z*Kp@qKmU4BbTDTG5N;sN%jhFUHISr2n@yi2nap@Rc}4+5O+OU<bV2<N@E!cPKR%}C
zlh9ts?<hdtOW<zk2xny8VdK=oJOZoE55$$Xvv%vRyY4;l=@UwPal;0D=1yul45&P+
z#gY=`0fX;sqsBEqE3A_|Ui8(mV2fD*=RSQkA>EtZ`MivCbI^Kg)?fkv6hr5>PkD@e
z$b8#SM@SQqPb+;^SXD^?Watcx)eg(0j@Yw&y3s|4X}bkea<jkV;{5#KGx|N8e|=p=
zO|9lGNgSq;?AkO_46V#9ibifya&ls9+zB!OT@K}o%3gC5;xwz3BGQenM+o2M`$);K
zun|eT07*lzpD}5Tk_OxQ!&wbpXsl0;Mcmasl}y|i*tV^g<n4wXuX)B&z9*pKRGe*I
zLtoMKX*Rr9C-=4#511YqXP1}afNRIAjIB1ZX~*gL{PM$O@K-Ag1yAykv6Y`Q7|^nN
zf^StmyK270+u~BIV|d-GNpym|y|uM~_I3|c{T#?iBdO3VhgtJUp{B=L?hBe{Obaz{
z9T;xosH6pE!#JYV{h|BdLWxnQo!Q}JXW1}}4{`RAJvKV4^=JBOWi}(ULQG$A^;<eN
z<IstL`E}WRZ77?$bT%2sF6Gi9aAHHTXtuyh&mw2nOb2UtBQE>8dLfNZud`Y7aEE8P
zJ*iNvP+4h`!*X3RVsb~Vo;7oSnpI0ACNa&)q;?f6@gs(^2jgc~`fb0o)>=5<@lUBE
zZ)IXl<!v+DOKRA&I?3Inn%qhfH9sVL1y%U)A1~D&4xIVH`PTMcCa)7S+2Jr3cVwyP
zka4(aoJjYxtj66;-mr1x@td*~*ayY?EOw9tlH!6ECf<0M(J=5AXZ@xu42C*?01VUA
ze&u*B9!#_KqIP%m@QsdvmxXvbApsnzFV^1;SjZFqoQ=B5?1cvax~61p{ld|GVOAf!
zYsI~TnH*4KPJ165exRF69_mE$*X;6lWeL}(!*8tac!<Pkb!V^4lTz-5Dk1fRd8snc
zM@J}9mUOS?Ml!Z=$$ar4Ati||LDsA*<F8Riz<9)Yj5)xO5_|rgPrY_&T;Ey=Sn0-^
zRvccWNxiwYW1KJc9=m)#RIWSUf1W0L8Q1Pt`9N^7N^Q%{s`@awC|f{XoYybk{%tQ`
zBgIh#UNEP2wgft>Q7&V+_YL(JuUGy~e=!MJ`Ad4}B*K31CH-Dk^vt{mKwKfYqy8J-
zAJr*;@kU$WcBpApXSPp@<Xj*a%M!|3EJk!8F`MIYu}}e*CM6cl!URi5s1uqDe~$l9
zCUB0Zok+Hv!ReCP!E$N5YigdD#as2DyG{ca+V0`%3bLk{Wir%JCTyZBs~PfwZ9M3R
zzKxcNicnNfBdqe&F$Vg~*3|rDM@T5t(vGUZPqnJU@|~X{(DMX0L4M@sII?suBT^h)
zPoE9@k(EG%9Nzu!A0YklnksG+w6+S%<%t{I2IG7F1)I!K8)1n#vG$Rrxt7X;n`_~@
z6coGEsrm`E<uqON`BDYBDzS+iTVJlI)yslZ9PXMiE^JPEtW<@XIdK7`Iz+=n!(4@`
zWW4Ohz`<*bggeO}g8r!-wz@Yt6#cAbqv;yWXZr+fX17a(XcZH3s|PMVw<TzGVJoxB
zjy$v4x`|J4wwK$VpZf;o2bvNEJ|>D<VEFnfCfmQa+zUX%wtXBQfhXHg#1>PCC-WRB
zJ^?*A?dF$I&Mp%@IqJ3eJzNPO)z2&Wuz#7eG9K1yb;-JOay}$Hx*Ix*<2b#_ETk>z
zIE58~bdzSqK3o!dil+WXhw6+6Y|D-8=n&|;farZ&PqM{XL(n!%7KRCS`qG-I3KQ!p
zS7|#~J9Q4z4DTMdKFuLDgL&_Ria7V*XzyOiXwNq>@mnx9nOjWkLHSuFK4Z>1pI*tQ
zCNO0lx^4|H4ajE<kKOESZIrvgYoiS_A({%3foUlo&bP!K-1NAeweK{EE0`XdvTIwd
z^U|03ap66j)4hab8FgM=eM3#HI5SvOHQ&&6#ltJP>iAxSzsstf4E9EpbzkPj#l&dD
z31*LdYx8NpSm#8czW>emQ&B~Lts$y5zSlZ^==dQ;)|I@DgtyB^CslOEFeX*N$61CF
z_NS$1e=mkNE^4p^0N)?Jot-zI^PT)!=*at)W<p{S{5_2{B{#4#VsA%a!!-r0)><>%
zoWm*h7h?>pwp%rnuG;;5#?lNF!4%<m`};mD?UzLt;kdxNW)$lN)o%Siaoe)Pm$36w
zCtphW2<eTUxR*Ynp!}B_iF|7RmO*nK_{rHjC@o8h=);`hhegs=h@vd=ivmBV3;J&f
zn;mWPegjt@_P2VsPd9koZ?B_hvZ$O?V-=2}d;B;U1Q8HEH7yHWdU9U8&gJ`XT<jtN
zxH&EgxZ+4ncV3&eg637tqBl97%23l5Pw^fsHBKuApr6SeHX^re+wTx4u&R%CIo{`n
zW`TqTumo|)Ok3W?zlzscjF=L_ibFLrcy8*iC4E<GGi~cnDT89r?x;B`aK+N0_O5?T
zH}4`ElxK^5abQB&s<Qh$Q(I5~%hwl3ArTeQXJ}O{)X;@&_GX^Ymzrb+k$G+KV~LpG
z7$wP9^{X?Vw$pve^uDoKnCwZvPQ<_uo4<Gu0Oy7{xl?{@zTdI5;TyA|tK%(ZZ`n<6
zj%LZc?+r3g(_88%@==-#v(f{9J+2MXC0gE|EVhk#KVDm0ou~oFAa3=(7iGU?03EUC
zYEas?xk$S^JNS2XTF+Wk+ndorSzoibY}X*&>TuiIRX-)I0nXMNyU1hu12g7N#iyl}
zNJsp01N>&XjS90W*5oerxge5yX?*N!d&cXi1(dL)5(hlRX<GE}(xU!-t={t};Yr^K
zM5^P1@bmH&I{D8)5WthlVKoO?UdQd>(j@k0+VnsgfH4LDaK-90LjxkhbPB-K0@B|a
z-~u&$^=g?j=9|EMJG;;;tE;xlvz9jt)kZwTV+AtFU%3uraQ9qQO0%SXh^UvxGT4G1
z`8%mFsjE)h$j-!QvDfSeNPNjrp&@(($qK|pKoq?(E#b=&>op3$;h55jtH^-lL~Y;Y
z>b6j{+`tqG0SbZf3Y|EeiEo6V`364y`dCP4C=UF*3niPTYOQBPJ;e^PQ2jQ~c_6sz
z?PPKNd4RZX5^$H2Vxb05+fuDBDOWMtYFrkq^g<tn4G&|7(tiwLl(sUmG;UXd%<on_
ztf!-2jhj~@Z(>myT5tPpSrsvaL($OlSnV;662Walkh$4l^3u0UJY@i%DiUhX&2~RJ
z-^ODZ5+OI@qsLg5RVg78ap(~zs8l#SUpGdb-UzoAkloY#(tgtqFJvB(Wch{)j+)(a
zooF*sum;0fvWE!zci6UD?<e*nJzV!F?&>X*y^$>~hhe7j$eQhnrn~ZQ1PnTQ#CKi0
zHE7q`2%mKaU7-xfEDt>p8)*1VE6Fz-oBe(`)dhU*u7B-NxCkJHP*}2|_y^L{a&7e*
zM~&k-PKPSK(||D(vV$hO=tVUtt_~QO3{nV5x?X~3LH%}gh5p7?et={jDp=HlG23Q^
zebp`<THf7Bw`H52*_|&WAfTi9V9~SRZln8c#24=Rbt?NmG-nm^fwTi%V1&ZX^L`3x
z+}~5&J|9|a(k%Z$G-I&oZ_H^}Y72=Vpoj-{%HFP%`o_P$zMk*2ar^dp3y<K_1}Z@d
zx7Q=P3)B=|x2|Th*?L!D;qV+xV0U%@^jmvIa&sCCE9T4s#bT$x{s>ZmRHN*|Leulx
zqw~$4BDst(UB0b@X|i!Ei3uG$cH-Ms7Z?#@U|8<L_lA}3eRv3-BDS*`H%LGQe+Xpc
z+w%R9J|FepIT&~IeALs@Khzq%cT%MCU%U+>yuVEU4`+iU?H>sDU!f3@{p%W-|2p~q
zbji+MPah*hjv_H4Fk%YqvTXDH;b~~!dp7O3U03Ykrz5l$;=s*#$_$Vex5#)bg+vvW
z4b(5Q@l)ru=^}Zwf{GvP7MTAC8zUUTrDp1^=821>Tvwg(AbigK<|zAA9U_YDi$-my
zus?5H2s0Fh&p<eKcvo~`@?l&24d7(awW|2AhJzr-?xcHw4Ct$wC@SQ~f8GhrF6+om
z3;|~+PY`&=QwyS$ogNz-dl&l~Bh~3*OUyLXt2YE=yFZd>X4M0N+e`^_3;#mEi7fmH
zyWhw15MAie)m(B-(Lxnd(7#tCg<!QwIm3nW4CBJLQyqV1x6@|CgUA_@HZ*s-gW~HT
zfhW|Z?Wpf<wN4P`M@kw`{OmH}(@mpZ8{aS|2g%*!Q7zR3*kUNRW{94+A0evF`v$at
zC|Oxu&C;(u)z#*5J#vnS3)(3M8B08^(nRt70is#r2>y;hkyYUjt{fG0Xe({xf7p`<
zbc`$j20atN@0G5K+PVgQH{`DS%-(!x?xzgg<O@8TSQML>D>;m=IBFV;rz7t@NI@|?
zArr|n*87_0Wi7ng2~P<l0+-PB$RtDPW+|nv+`W~XZ_;!bXp%jd)eLb+`U~5JiKCW>
zzj)-|6;r=`U=vetI+pjclu!O56MvIXA51O(C1I|_*k{h1hyBoQH@GUW57tXHzI4KU
z;lm|VEh+Tn*ZJQv!lclRPHZ|ZMhg;#$%(h@GIC!n^;Uw?fEtw@<}Z-?sPA{q$JeNA
zg&I8fscBB+vPAM@4<okks=qUXmG88(m%RUcf4-R!HY9$rX}p!)x7yH}{Zsf{FFnng
zs3nOP&XsmIz}O7l4h{|D6n_2v)iBNy0FWe46s7}8s#0^rAOW1`>vDO?6Z>5`PJ(pH
zySJ9anYwT6^=^3+N!IS`oQ#$XNIIJrye62^%$d}{kCV$mw%+NP=Y9QL4aB3LvwisV
z6&!S&P*-|Et^bB|O>c7{&{G&%<|8m0R?)zUq{_vp=`*zlPn*onqJWl>@nEIT<KWTG
z+*0}D!d(0=tHxz%R?@KXg!^q_)5+ev>ggvS;6oy(%GpM%eo}tQrPZ#E>Mqb%S!IsP
zPt_)-nwvv8TLqvoKQ3S8@_l()(6C}&Z2w15Mfg|~2|rtDj{&Q{F^M^ja0$eUO)}<k
zpRz!cay&N6!Bt{7D$O|I{2=x8vxpNb_;j4K*{k`fjnj5trm|m91^r3+bZkG%R;ca@
zLh35rPexT<7Y17mv*_+mW|No3L83IsBJRD}D{qy)C?B=3YSL{20q5k*{Su;&_)0`W
zQ%GSm!kj@8A*%t9)gal!rh1iwmPXZP@LL&SVFUrfbBVi@cy;EXIFo|80E=Y#-*Gcj
z?morH2uVeTR}0_6)1ypN`GR{0ilX28Y@)}TU$TGy(N1mx{1w>0X=h&J*V82DSY)>(
zH#K(Wz@0ue6Q!BT7c^}jT<9nIIoHA_S(7)_kyGV`!DW>>%>BbIi>gPe`6bf#`!}+0
zG%nS+Ni0+8x9q?lrzwlJDM#DpzsNC+W^`|&mv<!X?at{wEx$hWMWu0u%{`ATKFIbY
zTM6EGG>Btt@6~87i#ryj8{7#GxTUuCzZIWaX?eOhK)$`F{y(I6_02)1H=NOf;~h?P
zyCyEid%;7c(bPhlXA18-V(JZ?FAMPi*`CYwwuNn%pSD)oTF|hT>mNJbwOBB=u=Mw<
zrUdqdPSQWWL7Jgl#3p?UhlwQ3{`H1YC-Vc3oo}o*#-?rVb9Hze8!9ogcUpq|hOnHX
zSU4&qS4sck7i$&2D$ZHUQr7-bN&S%7+8=Wu>~|*ZIFQk^sgAJhvxh!ie2Ybl`emhs
zhZuF%d&y1~pVDXBiCt-hg?NlxwZfxWvVLBLi<4;%+-slW4F?c5Qye1zgjw!8rRO)^
z9a)|IENE0xuS4FN$Zr_^e`J0pG=p$*1J0?(BX9XNTrNpd`A0W>*D_-|96}Ct6bWP`
z=jaL3vZnvUWNp@TZTOJeqAI19>S^(Fyd~<}+(Q=8jgYtTbuL<ZT`zhU_=~3lUi~qY
zCo6h)Mn?k{L9Y`<b@RYtpg(+15wKRY1v7Y@gOVh8QxMPtoS9ey^sEA#d2rUiULYZ0
z*?LN`o-nz=zEAXPLKU6Gu>V*hM?B#&TF-gYgf}ukzY!mhtz*(iy4F-UT@k$b4shq)
ziU-qGcMJZcJ6+pbIW4;nY{beaZbAWrgBAnX>3NF6LI>rC8Sau`Z3Y?dl9G1zj!7Cv
zAifO8_wU^X`*h~QW^htcB1JZ9U;_&tzLM7K2|k-lL8_q|9VrM=cli-I9yShklNp1M
zKx{Ek@-9o<l4GKl$(adtQgO#>I^(D*Wn^*6)YqGaG)GL=-TwVo)uzGxq%2f#d!r%I
zUpn7`oyidY0Nwerg}d7pvfkvEGmxvZWsq+BZV?0@$|fgy)wwXtUP9LEiXn|hX*LbZ
z6?SD1pnh6H$*$eM<jlHOC&{Wg7!wAMx62hl>nz9P0q=4qbohoB%15PEX3G{VPyDO~
z>QBG%9Ybp@CiRwC4RC55W5u5r7iD51z!>#M7<AKQc~0f#$8NM@0}$5YfPjY-*hKFs
z2pM${(vUM{q4=_jRPf1eBk3!VbX-C+^PVnV{O@X(;?Oq&l#J-xLXVA`9k6$#f;YLZ
z*r9J)4}?s{H@Bh7+pNn8uaZ$7j#Ph_-`&xVQ0M-_WGi);^@GU%lT(rVd=(YJZbO1)
zE2^Z%pi^b1j<LPvrvkO6d}CPaK^vrTnIUV~Cu*p?+YS})1p4JficvM6wAW=n*?z0#
z_}zw~=*2iKN1w(u;91{U$MdoZfLY2U)j*>fr1V=0U+`fkzCV;49U;^G=sgiu*OFb8
z1oQibIx1c!a~T(zZ>oltO@lB7GD~yuD<g64uh_4xCo9c7v%J3+jaA>Y7<<g*?G`cc
z#s8Yd8m=Fz(ei#=*qUfCFGf=}QvxLeeJyPt^qpP8RrR2>sG65XJo84CeG+Xgg&<tG
z%JeT6o-2cJVblszfx7tmJB`^mto4mEv<)3S@@&T>cfmRX1}vZ5fryjcYK8DOY`6ou
z4>m7}^iC^S)z@Td=Bb6RjhJ_zP7>+ay><uWdvv2b3eTsjk`L(zPSz)8%ku*z*eYS6
z+<U?+;KyTYb2Roi`US8&E`}2l`rK;F;>Nsg$C~8VV+kq<{Dc_28>|<t?8mWfv~HKk
z_S=uv|EZEARROL*0|sZYpOn7vilILz&li<cSAP(HhV$iT`SBq>OaC3c9J?6&x4!#x
z)g9-Ga?3=XCb|x1#n9h2@+NnCHAfaXK3YV2$5^+A^*W!QFF5a)9&+I4B!L?dIf3#G
zXSV6DOD~}peDd;wvpGy%KipeUTy)a~Xx?YGD5t&@Pvs|_l|;jjV6n}cAzu_^C8(?u
zJ$4cv+Gm}UXt}Z!w}iR8GV@&9T5bFMAa3?~I#r+u&LCqe2PfwNzWjGQSLXgoI^WqT
z_U>k!XK>N>WG$|?>7w)`ps6L(<6w;}imO_SkLEo%90KkbAdBy8FFA&ymBn%jVZDlg
z(OkUAr3y|eS;++j*XoP5WB>qWy@CWaF6!WWxN~8`6D5u51)ia<b|Al&^p@rOODZ&f
z`<+VCWtaJ#4z}11o#{w2K0*KlM|z#6jsbE04@sn@wb&3pgpy`)j;6fSCp>w2&T;N?
zj(Wb_$Q6JFr&6qnFadiV_1FNY^~AOJgwXnuD4-AUfDd%_0WBxkVtoSxzdYhn2<wXi
z9{#BHJ9+A>SvYj0;{57Nj)ReZv^oq+b_zWU01OOPzwaw?W5AWEx8HtU^V(h#!UWfI
zwm(=Leuw@30rf?PB7<<?GoOw}MDEY&x}koS=~KePUdbAj?wZk+iWPU0_RyCPtF6Zq
z2@{Z4izbV>YE~74N_6{M&gJPiL}F_#Ds;)?zMN{lBN-F2pI=|tnpkmE!^$V`n7?z}
zj=w{K>78U@J5E4KEj&&L%iA`EoRBy(Jxfb@zK=@xV#8{%9{F{ZjDH(4`3Fj-b|_ni
zVXQnM#~WAolhvJ{DWM5`Nf+(im7eYxRTaAZVvmZEOh5dXgt3rtkrjYOEvOrJ1qv7>
zViP<afGGCL+v!T~{~IQ$ey#k$JMX2ZnEKFaI*{V$1yE^fh(iWt?`9Ej(HNTnm)x_d
zoHa?=E+}^JIZ~7R={^Va)p5l0<{>&rup81<na(m9RLGIZ@8fm2`Yw+$-u*yXX{B__
zp2EP>SIxc2^u3rpclucrmsIjm;LPL&nzQE*2SM~s5Aey+ktpdJP`be3_Sp?^u5vSI
zru!r@JLiw2umCMX(@<wG_}Rm1Dc}v1L|p^0LB>kr%l5uJ-*rlRzYk@w{GRTP6MLB1
zK|YE8J{K4>w0C^GvZMqF@cjII+VSdr1+Kjb?EfDar}G;(gYjV5I;P)iT>Xvc8Johw
z(@qfU2?Xh*o!UFH)_Q310&r##P97d(Az}MBItb}XNjj0=m(`lRJD3IApV?D%dEg2a
z0(8xET-h|5rPn~cKtNWk@Gqsd2NsgfOsKsu&^?j<pNHRS$4FA{u~HiudvLEL5M8p-
zAJ^IBhf*)3lkd6bvVCT+{@p!YRi}B<5I;^GxGKs%x#LzXFQIK;6mH9UEqG<7rbgDh
zyq{w<5H*_V(@_nBl~`rY_G)1&)WNrgjrTDMdiR?T>s7{;UsO4%Ku!E=^N$O^%mO8@
z*CNf;=i;Na>u9wB65RVfKxb*%+T~k9-?FT23Ak9{>Fae;@B4E#J=s*OZ}(4U;M<KJ
zcG)xVg*Mny@zXF3Y{S6!x!{Ge-@R51<)kccvsgKQ5WAj<O_nrrIR5xBXBmNT<LH|6
z@*Ly`I3uWxzezlOxzHZ#*lWBxkm_2aZ%7Y6?D(gA#o{6pGI6V>r0hEg1}*{ulW&Nh
zWB3WqKe<Z<oS|uQoPQFgi=aV%G&9-V$1Qgq-hcS?gNae|+3gFF?{SC$yKGAo;atBa
z21e8tVI_g%oI%X>R<wR)27YA5F+y0O0lsY7`~t9(jAev&Fuxv%kkN!KhA3gbjJ#V5
z#4hk0O?dYB4lkx~Wj0F7$mE?wZDlnc$PY#mQ`qOQuJF|Div5LXfpzATYcNxHCd>vI
zRc{qZBO#k<JEb|VkRkJ<qT}oOO9#dNG7QN^uZ>%Sfws1`ogFivx35oQ#DoOWxhIUU
zA|(s$E3=;XoxjCH$8tAeUg<?ZUGB{yQsA4Ia_IbOV$^}mS8-SXU&d4B8vFkSg3hmb
zfdJ%$h}dF0DLQOTKL()y{e#`r?+{(`$Fe{=+PcqZ6SH%f8jroD0Vey+_KcDRiXOLh
z%cN1g`2rs;sym`X;Ez(NhM#J1KU&Vh$mgq+j!d7F^#x~O&n2B0rbNl{9e!5A9_3K)
zc8jRaU5X|XBD(A?rLOO;A7yXI`iCBCRJeXyu&uOFG4IGYana+$)4zaG=kKc9C77SW
z`t^$Qs(ibz0ASu!-z!9GFPWC3L=oLP^LgF7FYCj;S<NBS(<TyCNWj&X?N!|~(3Ksl
z)lrBZv+{A#f&;|xk{{8x?T>5`IB1pHcT0xlUfUo&X?8?n>32&qiYZ`;JJ!9pGeP`!
zJ$x{U31f+fsBx(gJfTIFHPtjU%P&!-LaV9I4)G)tsGfp9C=3q|4@pY7zyT17;C|9M
zuC4@Hq;R|sa<3HV%{WgGrxX)2%?}r$WT}o*^(NgZYpK|a!gP6FgV`A2tm%KH;gWQ4
z=1OfE^XDAZxQ!QhG85mMr*>N`28``+aM&k@v=+kIan{pp=rK7;AoxxLc{u>z5YsF9
zJhY3;CnC}}-fln%!*^y-WO$$9_X#`+EjfFR0uu{SsQJj4m>$4~W_hxfC-*P@)%_#U
z9e5vPG6i-?N=2{!?F+y(R{NOnwfsdW_wuhB5Huk4(^Q_1y=xj)KCKQ7qDC(5;wC4}
z&&m?Vn}y~b=xw7lpWXH`ctBALwQifI!S((7WJW!F9+%56X<Kq1>-c4NwrQB?%<kxa
z4hv&Lnvh>ZhLAPhU0>X|V!coHO?$~qkt%uM$g7rfMRJ}`!;h?EL|iR&zmU*&y={CR
zo+sSDz<TH*UZ*koxUJpz3Vs5)`Pcnl(a=$-ulM&)EW=8sZiwOzsd7{mb*3~l(FAU*
zi+K;<g8JQ_SB=s~d_pXuM~$^4UmJ8C2p{mWrS7ldwqF-!y!jSECCqN`;(rh#b?!rd
z$eO58DUJ5IDj)x3YlC)<ahZL1@Jj}$KSl}G+TjL;Lf0+Xuf^X(#HrqV$Y6&76_d@k
z9zFMa{9J4dIF-Szhl&M-^1iJ!R-!(g<{s;J($$Dh{mRJyuQ+s(yLeQEzrp2oz{$!P
z1di6}bBr`=s2;aBs*s4p%K}%#w5#gqw9l(kd(8H#7rI6M1*4DoQYEF|PA@K_-<NNF
zdl;zLY6`xU4EDL3L~e$7N>8Rlg9jwt$5UI32KL!Z4@?^Kw3jP&uiYK`TF5v$((J)I
zGy6JJ7%69S?4#c-PW2@4Ew8~hEgzffns1LCj3P(7o0yR3_7sICa6EwGlWKG)LgS2_
zf3~^P=~LbT#_}Nu?Yyi_?L0p~kjeWRG}rUkvlNL3(Bk^)<bK_*Mm<mXP73gYTH{-d
z16%EoJjsG*<r!8~(b?Lnj>od(O}IK<qId;TX_<o_kkRpa{e2&mg!ub1Srqkl#v0!a
zOAQTWLKx}kQ6l5l6esHWiY>Q+VWD6miKt|s6S_<@wq)P-%Zy0YlrNPFYghVTGS=}R
z8xhePmvnziYwie&Mne;GW9{vdpM;6>jd!^Rza^VOsqz2#H=ZL|C>EQm7@I_L&v^DS
z%yrW>dGHlujCsYr-ta%7zuf5hD$MLwmM==3X*kMA3ubK!jOW7ufX)wE9$%>;>vW2H
zc38j_*p)9j?Fqe-VDEb`S<tiyRC>*R*AzRoENM!&WUL(W3gCLMrv`8B6m72zk>(8L
z)FKEA7Y{dLb6j=7hjG1_K}f3I`>@=fgJ^<#%D1<k%?^qxaYvxY7iV2QEmN>(v_I%(
zh72X)hH&u`w{mq~Ku4!J__3{~**Nm4wdj4=Q6;2e)V4Y^Gj4B%TaTe;4FsH1M!ZHK
z4Ysg$o-C;W+!jS5jnT<EhpQOg{SN1HmibI?rPre1ZQ|Q9#nrbWTm3tJ9M*P}@7qSz
zbDaL%)n+t4B~4AuLFEgcKvs*}{QXcCOtcVOHfwxsOkc>iq^u(dMh)MuSvIOZ+St!p
zNoTT49A>iD*>69m#Nu(?n`sR=A8(pYY0zaO<+<5@eMhFDaCawZ20)`}WX!ZTm{ew>
zp)qQU{@~3h^csGVC=`jN3$t?k*o`Oj;C(u$FlJ2}j^}nb)_&K{4_@t9<}n`Ol;z_>
zB^>zp4yvIWlEU7|1OB>jfgx3no!M~!K%dnyw%M5x;OVk*Q&}`NbbHis9OKPxQcHi)
z?FcSD{ymOL+_-b$s*&3}sl1vi{i|}6X<@!b-&N%c5(I}LAZu54T)>`|_+ncrQHZ}o
zxQw)T>nHCdzSJ-$7@KIh`8c?bYyC$)=Xc_fb<{jp55Mo$Uf+RrLi?0W{U_M1mA@{p
z1GqK0eZZbX0v7&#f4DtVwQwz45C9!3`yz2hLh>_v7p;Ysynl%21+V-DV(8H`5|>as
zr+QhRdX0d~RM=sa{`KdGM2vcACo?vhCFWq%s0^1HEk84pYO5(!InO32fSj!7;pmRU
zk9(gA?c1fJG8X<(uU9<I_=K`=H{mO*@-Q&`k0Q?(T<bmwv2Ij!CmF_*z2mo8+o74>
z6lJeAHiZ{Mu$>I%i(Ri@-Hd0g=B&~!SSl|bXMZNI%WlX%e|>GTk8VqOX2){-1)=gb
zD1~WQnwpwbN}stMc7E4dOn*gS2bw#P+d<{L-P`B<vH8_~RkZ=+fA!6dv`<Cl<%!<r
zaXI!xIb0*c-06Ii@74P$%Nx)kGw)MvAlh740u+Xx$PeHH_VWP&!pri`@EvqN(;B^R
z48=D-5@F|CgZFy~{k}1BuOl`eH_JFDd(TDa)u!qkYLGYqzVY~#p!5dc{&dQAy#_KK
z2%pRdWq3Z{Uo8GIyW@R2oGy~Bfh?UM;Z+eH^!rKsTIhER%sCOF57mb({%KbS2ZxBK
zB?fSL+{O7ow|xD08kg-<zEprcqx!VLZCysZ7`&Yvysli5(hZ(zm;n31w)O!@H4!$0
z$}VGmp#nK-VlYg&+lvj&sO<Nkt~$ZOJvxKv_7uXNu1ca`rlXIL!48$$P4BRgtlw|}
zwaI~iQ)=Jw%pyv3z#aMolwEM328=n-d$QX}cmEMDJ{ir<)wRP~t#lUB4BxfmPG;1>
z4E;(H;w|~+s-<LhoN|P`Z0>hbgNqmG1|}kwdSOfS9pv6;joYZg=->Uu&E(fbTIRgt
ztJ|tJkv4{4v%6^7y<qSi@hh)<TF>sVRK}X?sm-FZC%&h!Mi%4#azZ7-+Y1f`t<;0G
zrz1PSAPyssky1E-ARud)od}>W8ur|sp(LuOr9W~rk8%Fl$^6zP@hTaKX4N@kI>WkR
zT7VSyyGyxqZca>b+3jbJPf<`mhG4(zw51*!+UB<tg{I9^)vHE^ZrePy-iol}l^rra
zEsYI!!=CRz$!f`&Fpl659df*9X}_WOlEMt+w<E*nv#{YEfuHaHky;uk@Mvm?Y#Sd<
z3HR1_B2I&icgPbU2ytG9R`OZWTx(~}GOMG){o_8;k_lkWv8qUOWI}K#6|P)mY<{v;
zZt1QnP#TZFdw!rXyGGD7=4R~%V`lzff1Xb?xSOnnpZwMOMp2h+l%xDYmlV|GdE|DP
zDFoh$z!#S%=cYi0pIcjceQqJqhfvmG6L<+;Vr!A1V^13NEjQ~IVDuur<cc95!H-r&
zVLNTxVg^FO*GTs(6#s2@3j};F2uE!5*>lwE#$X5S!febuVV-VI^{eD%?$xZ4+WC&Q
zH{@&!9%$c!-Tgtyc0<gmqK-dvj#E~HT^vf{MHk*lpiXvtf>4}Tk?msS2af#ZA$zi!
zX<!c!2?E;8qcfb)RSqZJKv9*Q2Ox4(RPa%**%d*L-<$8uA2%1glY2vbv4FGN^(tuB
zOc?*b+zBNDbX-Ajh=7l~CS<f+P_&T$G*GlQ9^a)DKcQ#C9CY~9Mjq1R&u8p@?iaYe
zx?SO`i*-9S1tE8w96I&YLpJ;*m^9rW;@phhiQtSKJMJh`wiId<7p&E_wXt0X+i_4T
z1iy(!K0dmi!2CDb-ZHF?ZQB-|xLbe#!JVMNU4lEoT@!)@cZUQG?!i5{y9a{1J4}MR
zyS^ez_Fm`Qd%k_%``#a>P_txIAFWz%T?X7%ZxlJ|vM^eN6cJG^s!^G0s?)uf01y_Y
z#sBPdI_=g6ve}<ymM|UM9?K5XYf>s8Xl~*0xIQjW&dZt!=ej-b@zxanD}K69j${4n
z3@Y%a;bVO7v3k#!YfX4vr%s6WzqSd5di17tYk{|8-4yu$v1IZ;uCn}B>E-|8Cstq8
zmXmXQ^ABIX^#7yQGh@cff@E($>Z@+-Vn~kOM1(P_=-D5|qJV8!e;+6vM$m@%AX4|4
zy+wMLogGyZ>(7Evy*maWMYVF7Jq9L*+SLg_@CTW0YbsH{B8dY6X9dus^BykmfG^)^
z=Zh7A@~a3G3f<nRB*f#htZw4{QH{C)b!cGK{5?ammBLuYcAQ13{1rULLY-;?Wo&%)
zq=l{r48z+ouS?1bzgPY1iDIf@kSIG8BwA2iuk_6jk39xqri`Uv#2B>3rO3>YWkX38
zznl}*u;kHHHR`RAZB7ODlDVuJs2zk|Xl3G$VZGR;LexSNnq~az*n`b&+wghCkrXKG
z|0AR$L@EBqRhKQ<D#l}*EkcrcKyRe^0(s2oBn8X`Z}qU$Y2kGeFerR>#aT!h`qC&k
z3e0GSKA*#Q9eO~%Vvkg77UW`Q`0(%&vm)T@edj~RO7VpUQLHKl&A3y}hdtec91o=w
z9b5_@Ldvh*)swLu2B3EXA!KJ#QqqQz)CzNw;#3stCo*Eu=nG;yibo1z3z@oU*cC!g
z9!gNl`R#wy-fq|MvdrIS@n=>Vf#6Y4`V_R%2(eH}48{?qX+_kEk(}T_@aUM7zkX3i
z7d6QlVWyB`W8SjcthA@tNKKxeqq9~l62=W=Pv9|Wy;v_r-1o49*THN2K?o8eSZ(r<
zDAH^Fvt2?&K`IWR;=3fO7{6IYL{M))<z(kW^LFt?E8qJMr=`e~27lf{-}c6`7AtQ>
z{t>28322b7K$crno4I!|v#M)WpZ;QlVK>lx02nL*XmlY+Hoz{Fehn+{(g(lZ)Ar!M
zpaj|#h?*$*XgtA_?mASxRRq7FSNozi-2A!I+`q75A*;7BI;Y;l_SEe)0FWRAG;G}8
znHB4`29c#T7D!*6VFLXywYb;T0vJyRnP_@7&=G$?`KW;)$|er5D@rXX982Ej_AA89
z2xZ5UNKubV^E!Ya>0r>+)|JU+!a}Yogo=in7P5@85qBMh&15isNULc6k-Pz9Jiwt~
zQ%=b-GH@fRwhAAG#Jnq8n^BE*fe{6Pd@v(lk(?JT<-~hZgoNeDOGii3c2#os33&05
zz>^4RSD8jpzNH>D_n|ItI$$LA-}7C$$fwaYeH*C}`3);BPEXneCVQIf_g&4HIlPX9
z>B{vQ!}EPKa{83pTw2dXOG$#|v(j|KmS4E&dET~JtR9Qk^@*b5b-vkL#qvb`^%4nF
zB~AC$x#c_6hC7zrD4{~1<BBndUn=@_w|36@*;^$rN+>JFP5H&>&X5LQ==n*RX~{#-
zvOpqM+{YC8oqrgVNLqVcnQjS9$+(L+Tree{L0cA%i>g_dx!7yaH3I@TN)sA|GNXh<
z)$9f)wT-hTYI2G=J)1!R(h|nBfAUV<I6iV^U7REKn<Pv?*=&?HB(QaXDUFO|7(>m{
zb;juN=js<qH4xR<8H}nMqMOtQ+qE>CbEMtsBpOj^uM&{7C@~|vlmBQ|Vwe2pdU_s7
zdKZeEZ15`T81yng94j`q--Fc1SN+8Yf69ag(^v+`bnY=a^JpbJW_+nn9m*dR&5W&X
zjCnriogfFxM;%LVL@65kH#HGZVD8dMn@gjG(Akj2g=P5!bqa}m?Mn>3t!r=1%E5Lu
zG|TmnOAKErSn5!hgxY74en}#2DmNlUtC2_wOY&DchR6kIRJn=$D+UGz)MX<W1S3d#
zE94o-e92>WD+>ryvbT~xygtH6`)BH(C>*24Am92>L-2u6g!qeWIHZA20GyDaCKJ6i
zx~MM9t^<?upn43FZ9_#0pYc(H7$67a8FN1L{@6N$tNXk9zAkyj3-0od+XMfZi|b$b
z{;#t9{~7)Ntycek|C8Q#ej&O(Btfb7_j^0~@@ef}xbMCzG`M&3$CMMJ<Bzh*O`OY>
z#y;m65$t;aEMzH@+io4+sYA}-cP^s)?fFjTBz6oHch<z^Sy`Uoe69OxeOpE;Dvjz?
zzk0g&$5HM>Q)=s^)EqOnP+8lvA|h{U#T$ha++`aAnBV(zUGar8P1>~K!bN>YlQ3YN
zIUzWDZ<`GRy4>fTophK>0+Pv`eyv4-gi89~rV9b}ULS!Yi2CvQ@A70Adi8AyKDoKQ
zVXVteZRU20{%(egVzV{m<<$y$Q+MpLRCs3t)b@{BIGfUZ9bb?}hNB`l#qz4;-_OnU
zOla6x1QH8@;<ZojxzI`HrH~IQW9m9=YVR}O6OoS62>}m9!i0s+DpA;=|B`SN-rD<B
zCJiXlPZe$4Qt%P9R&4p*Qz2cv7rnc?8`oY6?rPq)gm7klOrA$bADmR<^aDd2*x$(n
zd;^ND6GnB7IjnBg$$%|1kc5;6m9h46DukrB<o&z!nPm{r_K4D_mQ{WskeFR-L`D%y
zZlVRbM#3%K{6(~&GL~4~<7D2Y140d(ri7V==_$0BS&8(eNm#tdSv#omD3C%2P)0sR
zCHU~c+U&$P?RS@#oeOVCsUFF76FS>)rDzk>&Me<@AZyHy0G0WZ{dbzdL-TLS)jk*R
zg$)sCk?tY%rQzTN@InpMr0^`xElbAWJXbbeVTJM4P|(vF+A5A$>bQ2WjBX1?8sSi0
zHOelyCK791km=wwmCY3FA9t5M-Cf-Y?t+w_tgZFuC-C$NuP?H_v71k9=abW)?!s2H
z@t1QLW3^*t!{%oN+2@hx{_H6bBca$-p+gnZlCn%$d-0(`HvWD$Z-WJ|I<2LKvFXN<
z>B33VOrdJM^ZR9Pw{~mT`cJ>l3m!3{4}Z28$U=cKA+BwEQdF?qj6_Buw49x{dSJJ%
zJX4&jZd1TFX1>V(l$08!tB2(#_bk^c=sFpjeK2pK^^gIg<LSlCI)?oLgH%)nupl33
zC4`(8J|B#gpa5Rue6hdlqw)$oRgU9U^EIuQ^g%pEP<hfimHB|3ZArRjW|ZwgqyK&J
zwLKe<y;U<&BFM^|S|H2k`WdLtWHYNBc5q#jP_@@{GsG3+k3YqwyC9p=6Pdti>etWe
zOMkulLT&<Us#HJIWJY*GYs!0K#zUDt2)pb1z2#D}bI<pE^zKsqGqF2sK_|-tgs)k{
z<?cS8GOF3xGzD!e4*trM`m2e-wiB}#kQ}o%(&k-g@!_V{5-jV!F&0(;yyV&~Olu!j
zE^O4Z*3A`+f8Qlc!MT6hU-H(8*=iAdRF7R`2$r7A5T>jCGH;MD3lk?Rr(k^7&yBzE
z+A3Snl(#XyWR&%oU{X_CY?3zFkktjXF*A<amVF^-VZ3A(_40LXSdk&CCZ$Cmj}emA
zyDzM^Eh0l#5kl~!2(#mb2YWZiQF=PSI$Zkdhl>pj^==#TlIuY+f(`-f?_MrEZS#d8
zF`;#fdRSDiby%SDGJ2Ojq~w5sCZXKHqAZ3TchO!wqtjkJeh5bqL5U<$l2pw{k&=w^
zE>C5Ot6$iUWL?0oqa=BJBR!iaa0oG%ox47ryh^t~bLZ~Rds_j8qleFNM(FXyPc+;v
z4OthhtGoz2Iz6h^F_OisLk-?Lci&G~-oy1u#bRoiIm97MU~JjC3h}krEH8oD2%nKp
zYjDUMI>HImXJzu&VI|iSbZ2ZaIlFTg@V7tkpYPQ4zH`rX+bzEhp83_dx00|JK1Rzu
zBkyq0Ks8fyH0NykR%))WD+XlnBEICCvswzy;x3EzLe&vg=LDKybX2r90?0(4xB9YR
zMt(@|&EEPcL)<qGG@n_+(xvjFMVQR`Ps_!*MF9^19-9Rs!@TPJ5TrRA^C-lf%Yy7P
z1TGKv#mRXo{S2)Nl3LqWch1H0QT*QW6U^YJ`|aAT^jU7}8OC7IRojO)6X$Pk%y);2
z>iDuf{ZB_dUTuQ)Q}yOOORi^Vi6cLpshEy7bG+#gEH_4&l3MIr-*|r{@B#MVdKcln
ze|2{^Lf~HU{a5FWCZ_`TMO^gf`ouHJ7s23%txZC~hk-=RIt8G#Y)N7msqRp(Cfnmq
z`LTW{`tfXv&WW$`z&r0+m)HBYd+6z`W#jdO*Gbun;6cH&ZYFw(u=C_V*{~aMD)GK0
z@yD&L5mX}IvmP`)>)U~a<sH`CyjCTfyI5B+!GI-m>+Muoz;d|f$!b^I!-4frBVm2;
z*P1{G0!IGWvwfqJ$$`LWD_$?B%Vsm`1Zx^hrFcjeKJSB5<0O&5u96YPAg5>*zKadK
zA9O$Iysz>&WjF>C$t6}(?RPnFkLVjAO^!B7jlKE2fl~cc_sf(QUC;Lj0>eFx8{f^1
z*v;VQDvln!=u1I6li5D~w7Se&f1J-xoCUy(Ii1$<%{#BBOjUNXDyme1n`y2om6Iy|
zVdd4yYANcY*V-JGZ~J<Eo4`jA$1cCh7;5e;O-#(cr|M}b&2A}_fy;}|?~<wE5xgp_
zXOeVb@Cz|1ej44!uu{o>dv~{9%3HJ3R`=ERp>+I6T^2nS*s3Q<*FU)ka~<l2pIY0y
z>1@<>@favw!QKDq-<E{>)PFhLwZpn5@4Z75CdknC*rz+jqJt9Q>grn7dTV|x$*5Jm
zt=@L4sv$c&Ms#E6*ZR3*$0Uupb+!48eXY%Ddu7+e%Q8gIFN4Fq@Zv;nT+^<0nLnG|
zMGm-`4}QU!927sSO@mwBe9Bs{IWR0i<_%H$80MDh@Z{<}!4%$hkSZYKwmWdORC=vr
zxWaQ2)_fDT$$FfsndW?UaYj5><<<ij=<DE&^N>U0$E)x_?{X2+K=6@Z`PtOjL%!C<
zJ-Nd2^?g9^jI5L(D!;ea?8Vvr368~XM0z5-^=$!DyufO@-NKZ|UB*C@e7GB0Vtswn
zW-oDxmxcOGSY&5r8?lh^?)m|YSyj%KI-4G@<cnMu+GUY|Ap3)aJ>!L)CL9!$32KPf
zq-%SrrMyQTZh_^6A4Lv+e6zf&O$}sMpkHWPEB`pf%IgeA8`f<y%wKM7zEO%Ih#B}0
z{)zdO!luBzX!x7jhRbfZGmAR@d~oyag)3U}t5;ALW%`}Os|mZDWtVpk))2mu6TVvt
zyF?H7^HXq7UIX|KP~2a%6?8h=l@rhC)Owcc8oM3%isKT(ThdAf;A6kAf&+KG-9MG@
ze7Qq|sU^BKTcfilnzYt?=ud%57aZlfxecby8#yR{nmf93o_+GLyIt&?QSdl$JsUJ0
zI82(eEGx;^T&nl>Y}xBd!m&W}^xRog*B2z5U%0_8@?J>B;Dclj<nz?mF9ObaP`9XP
zPmgfzesp)LNF?GI`1^jOh6${SU~uzj4r&T>f2=p1s(j$p(>oU}IWh6|c~3;}BA#iX
zjl5fmg<Q#4J^d&^6vhYt1$L@utHtUk!OeF0t<;dTWzyKGV)oX`v&l-{bl?L@>T>O9
z?~guWGmG-(>PiY5m%QA;uh-Kw?9F6l#eGX{Yv(_kXr0`;1!f+TAKJLx1|Dwv<0Pyb
zp8UVGDbkeQ^~7p7rZ@pn#|?*O?v0oJtBvK~ezYFooJh=#=i;lkvGQk6oTvl;-zf*)
zi!kpr8a#?mgdA<R@_R28g40t&+8ZwC!8-R_Gek4$rF?hk8|>~8v{bq{<Ugm5>&;cS
zp&`^tb+~tR?s^l*&#{YVcevGS>71X!?a^k6J$G$p@hR9?E?p}pu0zj;`+1!YX6Kln
zW`mr&d)0(lBQ|&%vd8f29nP0)ZUdY2QS_+gzTog@?_9@T*T+n3@jTsb$s{mxKiwt(
zpX7rhkVHRvZs~yrTHD-C2hF0&65+y+j;8!|1-(_hx2L$#0Q2#39RAW~ZQ9(wHO6$r
z<7yV`eP;FbDWT|U#^nBqXD-=s!qK<?c5$vw`{}ay*O98!6Ean>2HqYqhHdFXrHfCj
znQ(PU7aF5HkoFp4;^}(q9C0(-r)#`Q-<(pbqjSg5!w>R#*|YO7wKD-t0KO2l0VDNT
zIM*`GSDM?-M*HJliMw13O%%1VI;%B51?1L!;`O*(ZtpE)O68^VGHCnZ9p2*Tbnw1z
zF#3ktoBPafW2-%-y<?`0&04KlKZd*HlY&c#b+hN=a`MN3gBKM$)0lbcOMA&1PXj12
zo(ptfz0IqU31cGOj}5MRmnUmItd2Zw;HSX%){7UZWo>o_3Il`IJ4cCYEkVSV?slaD
zCUaOPWUB!e9LwG!(>eoHPz+w42S4p|@>X~gGk5eGtc&YHHL6X=vcy94TsPtjxG%$z
zph58WWwAed<fr*6NQ_^M$B)pp+^v6IDQfn3+n<AGciQWp*%J{4KJspS+<G5Mpm}4n
z6066vH=tcknL}`~9#P3oLcV@1?qQLV%;Rk)V<v8OINlW!&ZNiAB2wMgL4J@oaI~Wk
zJ!_>gZ@qXv%wn+IEL(JOy}xkCWmq*dFbMsIh3bv`gWIJgt1(w*vUQD?fW3R|(8qzv
z9pQz_$F=>nh@nKh2z){Bg)uPlr1!%~pmp$G{CQhUCWiVE97ygQS^ekQYFCH|7zv|I
zmTliO!h>5_zg@zKpIO1?tplS5{ieT15cxSurOWvCmQ={vd1=X+5|!aJe@Fzs3493g
zoU|!%w_R$e(++&oc386pOovrCl#lC)*LAiY>yt(2h5dThvH4?*lj}^MOt!2$&a%M6
z4QESax8Pm(-PH#wBFiffhY3vAU%3F+SCcMFY2JiS)Q_i?E;Bf=ETYAsQ;Zn4lU}Yl
z%1kK--`E)VSG#{4(HdUUJQYZ!V~_;>FiWR;w*v)9{^UxUNk{joD<UO1pzD`<p-e*7
z163>hV7*rs_$Zy(b+xNq62zL<2{Yi;20psFLKFY4&_YBS<y!*!sN>ytlpuS4Cs8|#
zCfnj=^oFJUg6s{DKsKH$1N=mnV9*|8R(+0O`|{>7nNhbfHm=}i?pM0!5>xBrt@f4I
z&H@k$al6~^!c(R`;J%FLsmrB;_j+1yRZE#NSM{U@fAa`oEUsgvQb4ZdS}PN@zK^>&
z2${GgMY;5#UyD;MQrp<rfT6-6Kg8Z+s+NL$o?+X?)}ew6;-qdQy`*je!<cGhQK2U?
z3goDVA__ZEdCvPW-jjkp60Pk0$lAo<v-#?{KpZ)@&9qA6Z|W~NX2NNRvzy`f!ILlG
z?@XTLFoCCiS@PB5(*uhFSw$*W)LE)Kwd^;*gx<+Zqk}xW9-BP_z2lj7tgWAVS{fn(
zYNyaB`uq)YM9F~0cvbUg_nSD=bxiVCq>Q6=xOk<}JwOjVu;YxbZ{OsPDxtxMtZpyv
zkHp~Cg=>i||2d=CMD#NhmQ%hHl-4npk7CyrTv~MR+vJBm9um9tQFVC&N@GqQWfJaf
zzo>W6m)x2JdSBMa9JM@;=DmdCc8$@b#b)oG$!wR+{!9_wg$v$HpJMzsh3385ok;oX
zGaRbdAcI}+I|axieKZ2WBe>&)ssz|*5C&cL2%XKOXs6<xaT34v*vU^pZ4U)w8xq(t
z7*hUQBITpG3uvmLS3v{>cWWK5Ws_h|*x{iDvX6=j=34B*({oMKL+%u-6s9?4-@>m_
z1u0Wm2Am(U(1}@DhPU|1<K(W=TrEBfN5!aOToJai>+SEw%O_G^IzpYaKho=7z0<jO
z_!0Ox0kTSb=`Ha1eR(E%q~EI9OiRZA#3n}dVDhwH?|t7dcowi0xG<vE$#6og=d#)B
z?NvfwEC#-*`@-<*iYW0?$as@sV$F7Us3y7RQEbt-fE)z07$llVa14|U4>8g0sKz=e
zMvC;F6})<(w8VczWA*LKYJ|74Q(J)D+8zVF6RDKBmEF#y2CT_F@|w}*`^IE{5Ap0p
zQ*?QoP!=cFlRruXa*BJaGSKd<7ON}5bAqYW_@<|8r!JR<BFad3V!1FjJ)-SqKRBNC
zgwsnLkK-_Ougyh`Hu-Rm7cUgty48DbZIwpMMLMG*O%eSKuM|-xo?f%r#Wv$j{PiqT
z&-~Y|kEOSBsb?SMI$kd<p?Q4c40QPw`^IeAUm4@@HTR`jR!dWzApib22E%FmPUYDN
zXDauYoto3y&_wQ7X=FuNVy1fUXvnYGGIjOc6PD5#=9wC>+t~%8^GJ5Luk(3nCBBth
z!=tsetIt(gjGV_&`jI~Ib+#3WNM}DyeQE0U*G9leV)8zYO1+yOspShtV&F19blDs;
zNn_~=QqZoJePgW=8eg42H&5pTOKVaXU;AXc<-b;g9f7)Jc$|jyt6eoh<r8m!GE?9X
zshD;I7diRf#rGDkk&2n*%i-Q$#8Lrd-C$fAg;vtFqY{O?yKq9@`zC|o6~O-!ujRT4
z&~AKs6rY{O!$VRaSa#p(u%JdgN{y<pDHjYWvv>&Z_Wsm;lHPm~qYq2QKJP!mcZOf%
zMnYwE8hW+3w4={ZaNCzy5>N+zx5WA0HmaiEN&0NGV|@=!d-A^I!mMp;b`L1zU`R`B
zD7P^m=#VMPx^e#T!Q1+5R^1Y4e*wgF?FO$bi0_dsy$&q`YgdE^EJi*h@(W(E48Isj
zhqam}q6gXIc;AExK4PUMfIWWY)iGR;=dCg@rn>HKSk{l8p0=iD_F(4?jxE1hkO{-l
zN=u@yEl#=!#jN_tgf}*0Ig;WYSnN2nMbQ&&DfrkE;mvK>0sWRN(SG4z<neZnyKae5
zG#Eji6|TRI>H6L`UC{mRAf)3|q2c6`Q~OHxI^jZe;FrODqGmdi5(iVX230j5oNS^^
zEv0xs(bkDO_-+|sj6E)Bi8M?-Kj>U&4+e@pCfkqti3mb{ho$|wED}X4aeonCo3Yf4
zVxq0*^%2}#qNs&1La>Ht^YP;}XC8;ijs6Aa6Y4jQf;{edN2Tl`x6MSb=_Jxm7SIIa
zMKfEx#m8Q3yOWC&K}CHx%gyJzv8Jzw=^Tu==g6`-e%5jG)#S-;GXu`od!*H_)}|FQ
z!Dcsg;>pW|c0J|@ksh+e&ooYFM!vJ*(l#cUdB<gA0z7Y)X34jY=~sn^mJkOsQ*9~?
z3D=L7z<;XJRXn%(lbU*HP?!Bpu$O|SZP)zLXBRiUxq#7Yn2F=lp8(gdF_{X7$$UcN
zK5o;I5b)Z-cSUK^^Z2D8v7Gw7<>(ia(MoA!LHjp@o8jg=r^o7(070$1ryg(6fngNT
zt@9Db##|!=Z(i)c+wCzR)W2PS7kDb&nm^859(fpck0pRpzcaY3KOu=SwjI$4F7aD-
z4@fMBB{!6laH2Q7ORm@x^Wc;r43bj!J{igmBzjoQCVWyOIJyGUOWv{w+zs2Qy6NbY
zFEMR;zrV6NL-DR&uJ_<x9fsRY06$C}9W4rSFS{#y={1&B?cPbWUOn(;6DF4Ttgs9P
zX-hQsij*zY*2JVS6AN%#%oU;xkhk<l@t+*%LxHRiu+q#m;4@b6ods&d?k|v-n%yVb
z_$!=Fu({pIm$#TV!;IOo<Jg&N8Qng}?9}qJ`U?)bmE)fJ+TNtnaq<C0ya}&4SGA$g
zKDjz<wa$s3HAqz@l(2;EzpLILzVRP$K1vbT%bivp*Gzx<sF&gOxP?PFd(!O**2N-+
zt>^x>b%tcMFy{B9>EN#M=*>hk+fZfebY@X?c81~XMWX$7c{3?pK1#RwruCk?wT{Em
z%WUbANp!&Gf)CbYuE(M6Qj$sH7@MBa^>{3<yC7zGh|XPuoYC!E@vPLuUS!12;KTme
z2iKFruX#?x0_Q!kfyABmJspkc6>*V+xEDMPe1cbSylArFZ7#}>rw(9k@KZZoQPCsA
zs-xYnEvuyqvPX+wCO<1Z4_hVLp1y!fOSSlR*;zI8^p2-)8_ihtyl$52@sN;OdAjMQ
z;yekS%~$8Ht*E?X8wGa%cA(8EZsp`k(R$bQ`@0<tz73|f{Qwuj<pj`UP+W=ybt8{I
z*x_ig0a!0!M)!vqkU>aAQvc#?14)E95|JStQvT~V#GJr;!825hv`EK;b{7mTF9;;q
zs~W8m`>o-yv6zV;n#A9wnC;8Ey)bsKk59Y8p^iGiKG%J=2W9t1#H+}A#3)OzY!fo7
z1ny1Oo=Ts}#C`~>TRt3I9t4=mL2)6aTpA+Ud|`V-@oCTH1kIgCsqPUN_m$L;*{XxQ
zrwjk836_^+UWguBo<~m27J}{~%ie(;w`jz-z7DVFnaJLk3myn`LUBsj61nsQBJW%`
zCsE6%^bQV+=FBi33y-{fLpMI{)Asaml-UGzJ#p;6hXjW+(~RU0EcucQ{9%(^Nn0Dg
zv6TPQ3K7qTXSS}XshNH=X!2(MH6eWjy<h6!0U786JQpLX$2jLZJg&3s7WU!bZ?woo
z_czv0$HTlw#f+~*E8bj%ijFhfVp2rU*?u9ukCY@JYLjLRjvzWq2#H=;djJyhk8URL
zM+Bd|y_*_79zc<w@rrr3iLy`+Ki!J;S)Kq6{*}z?!z0_<)yq5ZVZtI+cfXAs-z%pB
z8ENUpqayv#lV>%hM+{ylz^BSbxf9Y5pjn}zo@qL!;KSJO2II27W;0JkV!W;#jAyy|
zD&s~4LN|E0PscHSWpS<=VXs5+cuFROdkrBo1nMJ~+4}CS1ML!G>B8TB4}E!=esX=$
z)yw|$63!oMM88w_go_Iovx0@i+WP47hWtoDT9h~n$bZl~vp;}%{nPpy7oF!D62l1O
z$1r$#9I_)i1Jhn2thKs*+29Z2Df*u?UpadCogQY_Jx!dLH;>$v?tfo|YenzHTfCjy
zdl2%oTd_4y@&3h0%t2_n?J<+=(c}F2A@SGMNUZd|m!R-1s~lP4E6(bp2wHtFldrq&
zN9)j6(yhzsb*ss|uM~RIycvd_TlIOmc-N{pJ#7!a{7j#b^Bs)L7rxDYHOMDMmPmlJ
zJc4$QyXHu6Bg{nfbLss{aZM;esBgBp>b&~rDJZCm5-pzY)yi%sIr;wOG2C3GS|p<R
zp|{gPUa>}t5js0p)OwulM^`cwQ0y#ig7)LkZD6KgqBHI}p@!X)1RaDrPm?Zh@lTYV
zHf1CI0hbTO4jFuo9nk)hZ8dyq0T!#a>k!1h^{@7h>UM?Mz%+#R-q|fFv58gtGJ^OJ
zru3Bfliosi@k_%GbREYLrx9+cgSgFUvPAR|&GJ^@>wexCRj|i7SmI;Q+1*6o5%xh6
zo>toKl>+{!t5*+nhfs@U4>LGf)AwyxzE_|X14-FV>ERkoUH?@V_-?Y}HY&mOz_3=w
zvR%UT!Zu>%HRiKZd#@YT8E)y;3vLosH`lvO6#)*_SIeuGG56`NLKoo*jupfww)Jnn
zUPtn>dfZ2(bNKq+ZFsGXPpy!*&<&`2S8Kf%8#mBar}&BO-AqQSPHz)Wk1jTt;ulNj
zoH{u7?nS+ZZo9?U)IF|UaoOk#`%(+))%=HDPDb*9J>P0B64Ybw9}6Z+uUr}!?XR@6
ztGOnLJ&qa20`cngLzW&TCE{QG>NmM|NW%KY^<*P)^i!YOI&7`R^wV-1KuQ6udfpk%
znn0%qK|+th<qfMn5WJJ{B9l1i+@m1waY#Ma&(zL4W1`KX`<ni`q1lW=z%FVK?s((r
zdR3zp|6=Dh-TOwc)#V~$euumZ_=!ZDyxyx6tEX>Iw*JUt*j)`y!=!-5v36Y2;hui?
z5R#{GC5rToo7FZHobCn`r>4L0&D-la4;Im*zQH}<>2o{~C8(LmZ;QOX#^Cp=R7l%1
zR)+96umE3w;7heQAy2y(qAiO_&)-{*)0kmwppXwvunQx=kT_81&70`^ViQ-TRl)~P
zTre`+aI^IIS`|)jHS^k(sh?G47q|`{Ddxvd@q@=53zy7w$!xmQr!Bbzzzy!Jd#br(
zkP$s+X60yg+Mi8#ArMeH+hU?0(EhO|#0-5DdSm-k^MjOktY<Ig?0G{oEI}L`h2uA)
zd3bQ6qUrL@fyfxTGUkN|XC%NvP!b2CqQokTvYjJhi?W~}jzQ_X)vvu6ZI*(*t$c^>
z90?&1jOD{VvG)m1M<`1PsaG*DntTZ?X2WGpO@<gboN_l*gNDb!aJxAVmou@s$b}NH
zyAhO*3bIAeE{X?pG4R3qu%QBP_lSF0t@I4?Uxh}bTjgsByw~!6({LXzM#r(F-LMmm
z@2HQcHr#vP|5eU4pir!c({oLHN!>(tFCxkpSm`DkSQ!UvDY?XbkJEd$Qu}K2*WF>u
z+CkNk=jPzTZi5+U^31B`;(oz8-IIwP)~Afv{B`Rj_%gYFi8JkJa<~cG$IWU!%!CKb
z&+A~)gsrcCjkjk_kMHb#)}7fD%jY_CajJj#@X)xVjP`UN>~8ITwSULV^1MXZq`asf
z?<S3x4cFln&X$#R*xhQ1Ca9Qtd2|TatCe2TMJGPSd&u47$IHMoQ{Kl$t7QUEqibC)
zp*KI9>*l_cAkTdrIK77{IZ*rnuJ(Qvu7~=eozuCB-LMu*s2CYoacG9;Swik^r&wv5
zVMLD2lLo^ck5|kb-Axnz5WQe1Xmh!B1`hG)b;%E6($r(px}aR)Ibh(N<TpW-V+2{J
zdK3QukDxNR-P|oUXElv~>}kp!_f5jZ0|xH-HbEYj>06s&jimcJkgZxl8@N^-xmO~6
z)n*YSZvj3q8Oi#ffec*lTBf$Zt=wnf1rK@i@@<@au5Awevf!JEj_S-7TH@xRhmcgJ
zR4#I9lS10B;sZjWq7Ig8h<IeL;Hbe|hkcLYMJjhro1VKz^eCZSgw!ei&J1?VJLh7-
z2=DoAR~MX(=OO~Z;SY<iO*Sjb48E!*w7k*aKAYSF3$`3zX$0-_`XG(t<8<``JML8E
z#lS$_x6reVDf!s)agT*F?M^J?H1~Zi)AGL8&Nl{eWE<LV>j0QfO`O2VTt}Y+{!G(U
zqKWx5xKLmU8NBdA6m-#MRr(lS`Ed%RuGMySY+k2|j6ob0SkcHLm118zY9y7n=Zml?
z1|GgXuhYK5SnV=yU~;a_odL0q2P0hdiD?tO!a1%dpB57&=(}mnz{}Fsja0bW$7xQo
z1|C$q*Tp!Q_@N1qi6`g~cVdH~KZlg6rQaLZs|}{NmD5{8C~%OGCGj|#Z$|)bg6P`X
zfmbvCJ?ah-a(Hic4>Xkdw1rjk_I=xvWjNPL?G@C+&s9&Kjn(pM_GBYt5;C&J@6VQ}
z?yp~5<UJGEcA?+*Y$*T$j8V5UdDln7{UTR&T%ja_23DF4P8X-lvJl1*#TUgNy)a~T
zE#^xCZqCpz9bOFG13p4H?cMO%+gKlkn9-JE3Vq3;n;&zuAz|2emnZozFve<tkfSJ@
zo*T)$53rsM{1`{IST)2dF#V~}I%{c8Kn8F4W}@0&H#G|D*UV+<TNhgr6AT9qCczE(
zdUiPl9b`(8I0=7(TLDrYW)UJ#j3fpHF#ni1>Bv?V6ES<Wu^b%y4X9Sh3t<dhut8QJ
z^reNbC|1rcvIcFIxv&d*Yu!hWZZZ`RMhYZeG8OFyc>M?Gl-QJPJL^O(kbCyZRWoJq
zlj<+=zc9C-)+&jp+b><(O<a!8mu}Acl6sn)EuV%h49M}vw~*>CH+hE{%DApA+kIKM
z#jJy4zWvjjbk9(y6SY*u=BBVq3d!tSq%zS{5DMib@O|V1m!dM1X#4=>Kir8a=>zwG
zm&T4#A@9B=h-crDF;|Ne=W|~bqI9j5WtAn}l|~&rk;Qip8#dx`UxT?rF_8p$byZRZ
z9cxolBo&UyWL=ql2UYB_mZTL%*qFL917#;iG3&?Mk{SstJ5q7tKjvhXg<eQY6Gczn
zml}$mnGenoqvnn;L$H08%%?u?kaa_2t>-)1nO;Dhs1>oxl%dJ##ikZ6oIk)0eYdl}
ztYxRFbF|(c##%StU8fnRyhL4Yc*w7+qfyU|A$JaTqxm%PKEl||QAs<vwrK&5MD6*Y
zrSx8};)1$;aq_h%uxPGs#zEWX^Wq{umwcwIMi}TqaWNx{(Lvi))sCBucck+N!yV0)
zqwA27$)StuqR#S0%7OC+G|MSB??Q(u2H-9cPa*p3NN3fAqCJn=1F{**#^KB|sQ$h@
z1(2q^YOqQ?e9*BY)Vn;|P=VaM?5Q2qLS<}>_rk^${dXVC_-lW*RK}in8p<elhPMd2
z5oNpsxk`DCxCUB6LyxiU9+2c_<w-<Re?1&Fn3|q{X{=ZyA4emSknJG1F91NZuBHyD
zi0B%LREx^=r$Il;f}vT%PaqNyun5-&mV!wwQfXOS%lOvT<(#PiCOJ*@qnZOSqBGrM
zi6siGW`A^hW_@Lk7F<MbNd>7BpruuZ$7{LJUsBnZS8|$31y@Q%sIjp_B5a#|9fJcv
zgD&KGmY^bjJuGFXqN-tYmWheS+JK{Vbn|R!SFBeeCWpn<qRpNuKpFXE+rmNbY9$p_
zaVR<d3d!d%r#Y+A*KhZ}GR!edx<D*Z9c1>i*RS2q$}n@xRNAaE2MbGRo^v$4<K8i#
z5jv5xq+DpjUZA1W^{h0-)bkk)Dk*@#`uP^%bDd<MD~fh^&rB~mOH`Ne3)KZdlQ`O#
z1;g36WJHS)@ptdG|KK;|i+8G;+m>8VJ$YBX4pM@qfu$4s@fuPn2^0t)_J;4*v0WfM
zaU|)FP2Z2@<5a@1IY>58j2N%<iv>LR3Q?O?;_G~<@i8#uQhC_VB>-MIb}b3r5&wCB
znawo(B_?t{y|oi%zKq&t7&A8rq8GP#68;y$&;FhE-pKwHJwzeWj7qjYtd1mnK6tw@
zQoTy;HOY-K7#K;i=Wlj%F=n4fHQxmdkF0UmwK#jmqu1{bgv0Q}jq4IuNMN|mo}H-3
zoxLW-JOyy-nW>!bOhS#po<j#rqX%}+p<DWJkx|w6K~*qF^MSa0Io#ckdpMeYG8Zo~
z261H2c{o=P8o8Si1*M`dKp_OGx_v_DHF5%0&f7*@Yjh%eg=S?DlQ}$}99ytItf{#g
zP*}TI?qq@j4I_G0Yb2t0VFeS=C6ozKUNRXOlj}Bps;Bd$ZQ-mYBI&oitn`VdV6Ftd
zVNS**K^+YP9pvED5ZFD%AOADJO<P|{OW0XYGc&RnX`Q}zgoXXGV<tI0JwBxc(kBmS
zDq*@UBK`KQv}D;;68^l7o^f<FZ`nH}RYS`HQgP1bxr+5X<Xl`DCg!Tx#_H<Tg<l6R
zsQiU(sPcIT0aPM%lK3p0iQZuZ$vfX-8ofb(XP7Hfa9Cakv0Yx*5Nq!5aZN1}!@3A;
z%a^LAZ{$`!uQFq*hy(0uwuTaglpDX%p|KFr?3bH}h;~M0=JLLl()Xf5)BP!EXU=cU
zo-oOkMRaawGu9>iS&>ND4qt$C0vK4MQ_XCXjGYIM2JlDD2?tc7W>TR6F<YW$8P8}W
zEA%#8i#kwE5FLm{Rh{3K-zS=1L~W{pB$BjQr*;h<FeIF%(zK{0q{4Uevz=*7^uEi7
zlj$0jS!Zni4PJethcL-R?(`EyG4s;ZOG^Tv-$&n;{`H$^=w(>RDQ7Hh$v|aHSm2|e
zI76v5@z)i<0S;a%49XZ8pHAF63^c9dMLO&6I5nXdkSlG~sV^CBP5Izz+5`YrWGDU$
zVt9m9>MMUySh|>fcQg(HN7pz3NhtP;rni3(58a6m+^UpHnq(v$Gblo-g>P<S)56vA
z)C=TQMMLp87!_i#`o`Tp1-cu*-U-H-&XtT&;jrhA9`BgPUef(crs?1eQTdHO_G=o^
z+ccU+-Y=@!7TU35Q#`6!$hzU<?C*DAfi)zt+p$>yIEkK=F&^rc)rg)CCG3U;L1rjf
z$Wg^emtbdg`i*_u+1r!TvRrq3&68T1S;3&3hrfLIqN(8}QOJ@`a*p1M>_CLqS`so0
zd@tQ&xHaaIt8+x>awO=IUim_wvxUv0{5jdQRNpx`mykDAHoIm^?cnQZWKHa86G$(u
z>>dX({}^3t(95g65-ytwmrREhDv>`5&?=HgTcT?_e&lH?t!!=>&KzKB_Wm$zz+G29
zIvcCh&}}3$6sW>Jn)?h`hy7s(2Y4`r#{LSWRbBhPFOK}=?jch!o!2=W&OeBZg`>50
zvz0f?@&KYyi~>~fWlx&V=O<Jg!Ra=$8X5~!GXKBON@LR?RL)Nvw-sj;=KSkBL`fnH
zVzoo`Ur;R2vwWk-YV)GKJ`NC8KPZLQLgvFFB&K{5`cGdTe;_Bz0`!T1$6mlIV-tAc
zTkg1GhaC1Ty9*kMb|6_7VK+L?m7EpsJ)5u#iq8iUZt3B2yIX^AR5>i)lp$!KRpP}D
zexLa>^VG#YHJ=U`PVnyk+a$u+Apd@!%{L7ncRFZmW#oYgz|u2MOQ(&?{laN}&P_^K
zPb%A$c0%w0peuBj2Wy#Be*oS@2AmP69|Z{pIw=o{DQs;J2RyA1E)nKpEbNK3kWP-v
z`m_r4ZfF-;JW9OpFU<9yR09%h5JLMtWoSy2ev^^?@;{JBf8yOzbjn}flEl50jCiE~
zi%LW-%zwzQx}-9uZL(L3ug@%G;4EI!gnA1x)>1P2PNhZL*O2+0Dd-a&`}&81w3=p|
znWyRb)G72Aq>Xi0_|oQ1bn8Or_#J-ok!W#C7)je^OUtHq7q>5zJ}fo(Ya$Mb04Op<
zB_cwsgovmloYtvlFOob^BpdCtg>9ZmTg<>Nx{nQ*bWbR_QdD$p#UQmnRW(*ucdU?>
zWhNO5u{|+k*P$9>+hLXvf!1FbJ_KRk^eRg#zG^=(jxo3K=Q3=@&*e>}LhMt;@71YM
z{TRu!8Z%T3+UdY9Qrr4wSN=(>42Zt;EvT0Rd^C&G`(b*X9I?Tsp#?DY)%?_;Qay&t
z!)StZ)ahsf{g@>fp`s~GdNq(!k!o^o2rlNk$n5F9%qg@^?UL!@_A=#%<0a5&LdLW<
z$L{T5QFZIR92ixF$no;!Mxle<I-?@m#fN`TDFY8TF;UU;Uw~kM5eCKduI{^;LG1p2
zf=1m%_#i}Led9NCFKTPeb2k^WD0}OPeb6N1k=m!BqW>L;*2d}noVc{40|m5E{VyOe
zTCG64D*j`6=ML38Ez*vKWJa?2p`xzo^d&t`_3H7_X<Xg@G-M<}X{ESJpvaQ_Uad^K
z;8$m3X(a)tL+*!gAW1QW2oeRXrPTJ+y6IY)kV3~oQM^WiTnhoyGQf_yiPd}2$G9Yw
znBv&+Sq-JkS)Fk4LGV7(CG3f^v^8o$FEGWEbIZy&&1&9j2a%~>YV564RI_t*Zo~St
z?CrL^d>=5Pl*85(iIp!aImV-9{;Og(d9Z!SJtjVuCi&b{Oqo2=C++*d;j^JgeEC06
zsZyQl)4y^7{_nI(n%pc?F#l|TW15{d_ocBOL=Fmb((y)_jym|;y2W7(r7<=?QT`wU
zJ=-g}*K+Z(pCKjhV4au-^-c0+B3&mCkyHe>V)l|akNWXS)B(Cd3>OSOLVLIY6mUKo
zQLLznlN$D`B@9aov{42!2uVU6$yEpfqWtwpiHHg}*rToOit6Mcaf$iTuYqKn#9yI7
zK|adRK5P)E7_UgpF+n_H=eLn0Vs4Vgf77csRdRmFk~k}{I%I6Eif-(O|5tkT(rX|P
zY{+jU`zE8Zc`h!4Q8N*T!CQkC;8(J_7)I<6B&xU^L1^&dE9|6+Ukb2%goTWEXr3+q
z*2U(xv)G(eBMs5_JQ<(KlEc(E{PTN7mEVfb1s}%`R*hO%i(eIC++Qxpx8vf<fc1=@
z;fu{+A?dc%i5H}xAYoiFHZcW}QM6QHDffWOs`3)Qr$wDuO#V-k%$|NGU?7la5Gm%b
zEEIH!PH0Y7l3KA~IG@&7w!kVVpNSm@Y0MOPYEWQR3lk-S^j<q3z`r24ezJrdpf89d
z2UWVm@u>x+X0Icw{AOeV&Hxca3*Va$Hsz}?kqh9luvYqB$!lU9j9)l!_j5j#9Ubep
z$0#<{gpK<W${+Rz-~`IY?`jUX+df#AENP;UVr03?RAlCStTQ^EW-LUOlaR3B7+qdY
z`#xRkTy1gAO-RTXCr(^(A@otfq^fUpG%)t_=U4;Iy0}+}r&Y3HEyov|TX~cwWkI#>
z3VWC0F-0>8kz{+r41-FhL|@}4ESD^-OzmCcq{a`Mg&9=*YjOijNBjXI`Q_Qi4*T-O
z@w=L;BH-v1753^_E73rkd@h_AgUy&Qbf(D1LL{Z9D$iaDq0$_#BvxyT-9>fB_d#_}
zmMKu{4HSSYR4f2`l7jLkawkl9QyD>w2{JL?zs|b-lb9*bwU};??-bJJ`0t^hSTZ|-
z{|S;IQ4<EIm)M{BOG~$h^xJAKgM=A7T^Roq4X`JSju`t+b_^K$PT1#kLDgERT}Chl
zby_u=jX}&1Fx=*;1X>S5%~R$><9i}8dAZb$Zl35%rB+ALgDUFI#4Cq~7rD9A;ueHI
z6iuuZOQoqL4qrH$)_!i5O(hU(?9?MR+F$-BkcLN98T<o0Nv7?AHM4IG>V*NZ>$e}u
z_GbAa7h-g$CM+PJ38H8zO<N6@nTkY{6f|mLwm0Z_B~rbR>hEft*|#AiEUhK6fKk9A
zg(?~MIyIiWGM3Htd>Z1~=R*Vfpx|T*0m$!LD%`v4YuYb;@#QtDbnII%8Qyk3jM-7m
zT@iia+C8Q9jD$5e;=}pVk`bdfRN^F!gMHxjIYEwv9ox!oJX)!Gxjd>E%v37kS<MRZ
z)9-l~>13pcPY%8p0-b5?Eu_C93Q0>#E87>*$`NNf0?SXIpTnPujxD)1q{97o*o}y{
zx3CPU%-713j?ElUZ2UO6B@8@1AZ(r=A73aglr*cDG2?SM-Un7d_<-^!wPN~mlq~#d
zm<_8nfm+oVHGD&<VDW68-EDa(1-QuQwB^n1X;T$uEx5?YEXV4}j`tOuiA;58pv%&t
zE3HsG0hy@rePN~0lolx&=~y|p>Z}3`Ng)O0{XY)tH&UaJ!Ue440^YJE%^Fa8W`)em
z1-T8{N!2+tg6|3@_V!T1JK}C}0amDl*CKD}f*P?`Lw=T5Fz)#-H!l}LQbEQYwUABK
zZGYMx2`NlmSvrO?Hv=@@8Z`tnfZ=@gUx1k0<gMW&kBIK)!DKa!j8pD(otb7=b@|Ze
z(_t$N#-t9IlDzlw-X6)KapNN*dQJAKZ}xgV>FzM7wgztdWfUj}l@Z|tgo>tO2Z&}G
z{JqGZE;Z(dK4z0!s&|QCoN4pF8z2Rd8K50v^RxP(VhE6k_zXdXdAQjB1kUCNYiv*C
zGu95XJ!E-sB*YHnqK}MUH)p?naOUn08Dm!@mr4u_&wjZiHYwV;fN5ZKkUp=R-H1kk
z5rjn(s4?KRI~XLcXWc&h6Oi91;YM*7eKatwCM3`cJjB%suXite^9h}pff_VqkPG<^
zKA)a&qX7^ox@?vlXZ%s-Fis}&?HY8@{eVOsy8>ijfg^xl(!x-j0UM3w&2|Q3uC1*}
zpw3|&5V0r~uo<xdk4RDS;|An!JdU&@fSdek0-!eAz%x}mKh~t<y+7X>x!Ga1q|6`w
zisxt5c+}<hV_SX>E2T`>?kse_wY@NJdty1QznH`rR0Y29i%9q&bV77CC~Z-EXlxSX
z2m~wXFV~zTj7ofV7POF#-K%f|umhkJ5Q(q@q)#Nrv1MK+>qh&j5azJ&y%C&;XCy6Y
z4(f&OK6EoWOG>7K<h~z3Px1WDw?_aD@!LgI`~QsK!l<Hcdq_T|n>@<znLJu<Zp`}T
z=-zmI=hHxCGZfg>ZjzapXlxl<-@TyB>20(}s=`VN1iA1e%LN1o076QRA75t6W&lTm
zdLqTaFx{lEs)n|C(5wjXjER6~!v`d=_I4iSqCy&gKdP#JDCK;O^_lhU)Q&0C=uSEB
z3l&6v^p}{kV~1if^d@s?bh^@xfh{OPfh|M1Ds=1F3hy}`b^v*AJnJGLpjJq3Th_Il
zz?7`15%NcOBZt}C?f&l9!+W`ISg=r<Ta|@WVrgMkg*xWq(tpEd4<DjGod@-(m+sC|
z;R<jTQsHHNhmaXlyYw&VKuuGHL*rth2sFKld+VdSaH}P17V&z5@#09QERJ?q##EQL
z;vs{;|Na|;{lve!&(N>Bv)-$lMKo{x4-j7Yavm8JWZL{2f_^jD*Y6I`{u2;>Z^ovH
z8ft0gnt=fFk0@jL_6b2-yGF_0YV5^_MKqu@^??8A8<5mx3mkrUW3x0dtksu02sg<;
zeQMSJ!KX%ui=sJ-$-S6Gz3NvQ#}ph~#l%1tRZ#D=oa+xS#->fkXC^+FGp7MJZ+ZO-
za`8eJwHC7I3#SWS7;oFfmg3Dk52!9jX(VZuZDfuftp&%&j_Apc`)@cv=%6?)3zkF`
z^AdDQs!$FYeSPb3bHUD4%!0oqz}3tDfyeeP=TK7iQ}Jt!O~O-T<e7OqU)Q;>O=)US
z_uIE)OEuk{Iq{oTX5-OW_d>by08i#ZRNsBy2@;VpKIf_V#m!ebBW^~)a2o+-?C3Su
z-6)<rnKek~Q*HPmhsk@R@wS^n-#(rGb<y^Tknw*}1sDELs^Hk~6Htu0e()lKA$t{q
zqCl)?4<;O|y#y_hz3`cA?;<Dq@yk~l)%6^=$mG~7oJgi=?vq2#L7@wc(PL&Wh9K+!
z*$Nf}iJXs!pLkID`@A4M;ukrRXqxNeq#bY{;LBYz@Q`c&4K}6Gdc*){o5RBb?>V%A
z__F~}(1?SDW{s?Gf_RG~LJ?q9;yIgMOj6RFWo@9zV4nyaLPj!w(<c{QW>&?$O(vz`
z`aI(Y4aZ6Y^7rW<SNzK~JUcd~id7LMKcf8+Rm>`i7dQCpy+uL~&%T7~M?W8CwLhoJ
zxne#&hcJ%=@wc!1zuuqpE7|+?8@=yp_2hH=!`2k@iGr5UqkTk${I-2E@Mg*8N%BF4
zF0wYtuR7ZxY@=2oejvn7src1#lxJgprmCam%xT3u7Vfn{MLPTo&pgQi(berlJ3i<)
zCsin2P@11TU+1Z}wBoGA!Y65j5OT1l<EUTy#q9e~8~5sydl-J(-QII}gWvZWc&Rhd
zxRt#bZ5t)5i{*fPlYkEumo~iFvVmWhknBe9F49=*{PgN){AqW~25j90wH2CC9pG6$
zs}G(mgvG2ig<k;)4hUCly2S{Sa$%~ZhI4>YQJcu$=DveBWcDRI&|~Yfi+?B|&sA}r
zT>v@EF6c<t2n%?eF1#na#i@Mn<Ot)lQtc+vGFOu$tFAgWTZC|E{>JqVkpmC`&o|4!
zTJEBxIO1j@f8h45sCk8R!uqvCdHniy(mo?dt7O=y0<v7YWS(BP^PA6Sf*N_$5-*Zv
z^O}!47lt=<GDGd&hP(kh|AsV(3+J=%6ZKLj)v^u_FClPq834>JLZ5k-GLIo0Es`KN
z1oU5lQuP*0P3!T?=MNf;{eiG%G&Us2Gro3M$5~LcX-V^&`pbAh=k><Rc0!SxXL48j
zy07)h;HP4O`py@&cbHAUUVlr-G1BqMs$_ALK*NP4&}0E(w!+SisiRxmu8LUaw|98K
zrvjQ<5eGJ9^pyO}9$ZA158ub6{&s>3OKKSUv&>Uz6$2P0c9IkqfSooX{&wsC6JB=L
zo={AYV@k+SbF8s1CxT?=_D?_8_OEem?8d@c(%tJVrMF%-Rl0?pN!dQXeHp04S#QH<
zg#4yjMZ8RT!98=vLLx^YWb)&D?{iF`;&rZFSXX=!T7h}S(tnrOJ^}Y^+nfTB*!U1d
z*<RwO2{ivhU6Yajm%28xvWpXuyYz{JXWU7Z4=di4hDzGlv_ZrVtry+kOo&y(43iXU
z9Ht&30X~e$Tw7h|A5;7<Esb*Z6k~5pqWd3OnuN|IkrtkoJn>)|Lct`m8tw0Coo@*^
zpU*xema5*6R<6&wf{yl|J_vQ7`1OZcz{=Seugz4*8mS!KR==%=(9MSaN=Qucu%cf2
z*9`X+pCp7E0xvY?R@=%H^xd~O8ks1Et~_X42nt~Wu>m5JKhz!pl>bH05-oV&uZM%J
zjnRp~@uK5BOsC<*7C>$6YcrR+oIt~)Tg>!%xY_UjJX!WGOG`JqrTFpg@6<ExmiA3R
zAObXo0?KmN1_G3*5eWNrC6fjV7K_(Q`qr;Gg!U0SftPxIk%rXPoGd@8)WvLd15YdS
z%UkR(mWNAi-Q~H>w$=^pmJbL%E#1=s#I!O){JNf*z&Y4uG%)0bJ!@?41DsY&oEI9G
z0elgL+)G5A+qi$a@(kSn?_&YmnAw^zl-hN*bG32q#oEvj>@MjN|3yOsog1S;^p+Gz
zO3EXr3ZTV94FNC#GR@~~ijM_+&R6d2?Y-qGhz;m}4^T}`*RpQ(+C;ln^qNIw6UelN
zC!`DUhgFSvl>;!V5$z^<xT|k{U5ciX*smQ6A;jhi8s)&&qn~IwO{}%w+iAmn??&R_
zzts4yPF)jc+SKIvV`XTbbt8zm5|s^Z<?o0<u$$>#Pzp1TIPk!&_?1c=Y)atb+sF<@
z{Nmt0qAi(yFeIFK4Sm6fDV^U@Yuev6bDxp^8%@c1e`KD)4H6*HWb~UB9mM<B1&aNr
z_~LnulmC^_-T$0VC=+xVeVcZMI%!>EsrXWLPbHYefm?b;bT<wjK8t#Oi0t1&n!SHt
z)$iDb)NXF&$N#6UD-VaVd&4h2ONmz5l4Q?TvSiI?NfeWvFbE-I$ujmOp)8RZObCfd
zW1H;zo@Gdu%*d_<gRyVfe=q9$>btJr{4q1vT<>+>cg}g9bKmE_pX(e;9zivSW_n8s
zfb0&Ym<OqbCLGne*I-+?vbxHXE8)w~R^g3x*wZgF{^IChf4NmV{;%mjHMTnCnp1Ke
zz=eM#I%SfpVmP5&n>M;>#EM@3#s}uy{UB#&J@A<L_$n$1FJAQa3<+u6)sAI<+dH+o
zN~QWm-7k{K+!hlF&6JRR(y}`6?t3}6N^=FLn!O-Ufm{l2qdI+d0(-TWyS2(Lgz{4A
zGS0mt$z$A#A=lR>*={)x_8*$#S{@Q|Bb^_OLulUt?93uxb{~%D|7S3IT>ml{YKryX
z#eY|R-3W@CCtuNEO8?;}Hv(y{saPF53uGK|e%eLTm_z}%JzXGUCWoE3{jTM*dCwg-
zq{rrI*H{|AxbGEQ2J6XQFUHUW=WfPZem)`fyXYp_{GBYZUY+v9kJ}i)>X=AyXviwB
z9Mgs9#6r;3YykliEUI}8iTSCv{Yue&wGI6KQ*E<;AN44xg~h`Dz4{?uJ(btoDkV@I
zjcaO-G3NY5X2hso(*f_nB8otoryS$2_H9f1AJ9h5rl|BhsAo<f@vj>b%sE9Ny!*<D
z@_}nfJ*ZAcxncCC8T!L}dHK`WW84rUAFmA-xUgnO&pPekr)GC#*vmRZvB2>=6kIy3
zu^4apz7-Tl!PLpR@Ft8E;$88Bj|a3tVeJnK!1p8wE6B(LX_f>PJ6z^8tcGruY@Xjy
zC{GhQVV-4Q^fm(IC8PmFsJBjVHOl}%Y(G!_+*l{(`AeE(jzTPL6bc-SCV#A%w%_yp
zR2iu#y%MCQ!rj8E6)fJ7SU-Ee?>0qb5^!3GeTn1QJJfNesz=^$&M6WJAJSyW?p7aA
zkh{4?-g3v~f40Gca{(yQXS-Yi8A0hBKrjSJwn6h<LwjuO21)b^pkA~oDD=<O!d9;<
zX#<IK<W}sW2ER)>knc-OhZtfj%Y{LG?$`(Ni2<%v#EX3O6|v~VJ3rNKlk-XkWj80E
z>D?u{_<z}Phnre^xh5;2%sc}kTXSB=fv%TIr_`OUncg)harNN()T5_rM?2FMlr8hW
zOf}liRdRmi$)-+N(rPnRz|w%A_`)YFP)9lRgx8Ehy``OG(zB={Q-<Sy4fNoN2)|M6
zt$pg$8XFDOq(X#rub&D$#xYG$Nc*J@w{SuZpUo6~U|9A4EW2^TcQ2G&0q0BpMo9Xp
zZqE}kH=-8}u?aR0S3TkmOTsElz+jAG(J^{Zqo1N;ogahcKkVRC!Fw%Q1|qVm93_<5
zWBKG?#~`zTFO1_@3vThgU;ART54b6O8g31i5whtb15}Biw0rV|Qrq9ACma;|7OF#4
z>1AmJE=W^AI26x={7>L9sOu6N2kc?9%ND~P0g_U4x%lh-M_PxI;oqb!``^Tc>(Y(&
zLm%+vj93aw-k%$!Rv^I~FH5X>p(#VMl!r^n>Kq(IdyRaMqH)7g0=Hgu1y6Vw|8AUT
zw{F9U1P63z(6-<&$zY-0YK}G*S!e*9@DY4Mw^~w@Q4~B^RiMaWB<X_vPGWduqh<6!
zxIdQsRd%_sn}C`1ev!pBuu_XXzJ|mBc+9?a>*#{_N0HkW8YbTvnAHbNOC&P2bDuX#
zF@dYcxpw1(J0-Z!MB3hSf3S5OL;wFktA#Ph)&HAK7Uo|^f4Afx<DSgoyUzNaEf;4v
zf(xq~BfL(N{Y6Ct{lFv0Do7-PJ}r>cm<ElvDIOpzDk-^dZS$m=9dxViqvc~cL_V(=
zzIyWqC^sxI!n{fOx3QWJ1iIlKTNmA4T@caXRgDqOXXHB;Pt6&9t>V@a2-NB>x~go|
zC)bwfe9j(bA9!zr6Z@V}8SY~b)9qr92st>)V@G|5pndv%N;<r+t-(S7>KmvCP}OQ2
z3H+z3sG;XKx%CE2(um&Nyol{CJrCr!Z2igeQqSRBE~q#-<QQZXVO+T0_7a-CxiH9a
zi$~g?-WMRjwvSIRb+x->sb>^`YdNfpp!XkY>cr9(_vv4byJ*dAu;fkX>pqk+f*DNF
z+GEpq-KKA51z3^xYjj<EH+}_(wKHN<ospaMDaA4yTBrP>5d=4_^9b>4NlbNzziHm9
zt(FP3;~ZVPwmV492qz2K;o?J(A2oT=a0VV@WM>-8(}d>ek*;vjN0Cp;>C_>+j>a=_
zJsn}OOXhuuJ!|)O_B(Ccp&wA3*QpqS@r!$WvXp1;jDam#9My@Wg<2%t1`0{EPDtz8
z)am)Xmr{@SlpcynFPHY_s?SO8SXV!y)`#n@2F01q(#e+LO2KWzve@d_&akAWBnzmA
z2XFJ5)|+>U@H4F#R0hR7uVuqO@bfwo@#gAC`AV1%tU&5CTR>F>yPBqh2+WH$9m$AL
zwX}4_xVTt2b+WVhGTB30)AlwO4N15}22D)|?Cg`4dyu>^*}b#LuH?YNLti)?-h2rt
z3!A)Nm9Vk2EO5NPCvA9IXS8rsJV&PGzG>sEegcItovK-7M!0SXUTC;B3sq&?E<{(R
zi&QTOJ$L0}QF3#OHa@-&U1Q%V4Ys?qO%L5(SzgATU+Sa+$^vWPKxy4LUwv|MnJX#B
zk6JixLLS$*G2FQ<TAjJWGZSYg^K1*;rt_uyu8{ON88Bv<rbGn*z^ez~*}s4So_;Lq
zZBh;y0O-yF@^-i|u?X;IJ(<A0<0Y^b{Ybc00k;}MzY1o_pA<8#(oa3#(wD?ck8KCr
z(31hS&G6HA6K~@3ZX!&L6K~?DwL3m^d=%mqE$^4Y-_`T%FbNPx-c4-FfuJ8utasp?
zPGi1$d-KPX3$yOuQIIU~c=xx5aaE5f><xMz6&o*6d4md%z41o<Vr!ePzq4#*_a<3y
zFJVf}?Mi{D8Qa!<uT|7UhI`gaAFcw?01b(=%m9!D2iPy!2GdgNAnX!38lSHaF14t#
zSR^dQ-1vA&yzzBJX9`_vXl3}KdHIm1hqoKoi8T`x9RMr{+ydldPae&)?n`Mc$!Yvd
z%*fEObKvQd_3j}$(R=5v_9e-nb)1w;KYrR8+3U|}??3FD<KydInnOErUz4)7MigeK
zHHSGxzM49wT4ifFh6-V8R->@N)P9a^^St-{Z%F{aE{XV@%$YWb!_v}HfC(mEv_e(m
z?3DRLk2tKso*|ip#E(!vbozJ)S{}I{xS>C9V{9Hwp|2Nu66PNnbsah!&6QcgSW@*2
zj=Ci#A%VKY%ec0--Ch4AzrTE9M06)gY{%d}1pv6U0zb@G6%9CM=Jpy!`@FN=-l|3{
z#}u$l#m|){nOvlh8$s<&#Z#GN(b1urL%B6}{dQ$F?0xyc5dni@Aq}B3h@MmM_3o9L
zLJCWwj~Cl`XH3YvZH#KGlBy9s7&l<y?;B?Rv+kIA<cGsRxEaMuOf?7p>m1d{4N7NL
z(qpq|Oj6G2!?;Q`XwR-?LEg49;sb!U17yBjYxSC#tj#FW@G?JM1LqhpfF!AkoR`v+
zLR7E&$A^<%>rOd`apEITDa65oh$u+Y8Ut3{UFxxE?DV|#VH%qjr+iEm6I*BB+r$R!
zX=dHZVl%>pxy{;|A$0eIW3uq3{TR1O{}E`anjgwA`%H}!`fWmae>qy2M^Ywpph>ji
zeqL>&nvjMyAyZp?dCOzjT}UIt%76=(2Yx<S&DJqZ_%f)RRh9x(w<>#l5N95#S2lEe
z%ywmrHcQ7IK2+^-te1`LE4Z!J(lo5(^r|Jj5x(7gW6jE~!pG%GvYnU>6zecf-NGrb
z3`R7mnGmv#$^C>R-m|i<kzVUqniiQ{mOF2NW4-nc&dp|6$qhE~twIzZ$DE@xKExRl
z=QVfXV9FYn>>BZsI~VqSnNqE3XQ!@F>r)Ze`0~abuCI}!QaR0v>#3V^-Ay(f38nf{
z@;x-|k<nr<`cn~TY0zS(>{3(yTUT+H__ffcG4o5_Jy}Cx$q|_|Vhtfd{5Y|W=N4}2
zczz`?FD5cy0zklDq-~lpg0i9#CKulVZ@QH1f7L;dx5UZ-p3~z7Yh@<b?!8CUR^z^5
ziX@QsQ4p3L#-6piGgwIv^~{mb3gL62iuJ{$fz$o*?o6!7q}VK-(3<ll34Z~1iYa~|
zr<QN7li$DJD8p1WueEMo_W|}+vdd%93yzv*@bWE)a1p2VUT=-?L=E!xKZq4k7WpHe
zUOw5D?+mM~)%MkKA7!=OIXlCE$-@Ca9XmOjDBu`k5a*!A!C9~fX{TXDM83=4fXpcR
zL~=O=5Y27UYf5*AZ)eX}NiKx=$jId=&O2^isP^Kh8Q8io*TLK-fQqTm!%0O`DS_L?
z>0h=rK~8TT0}h^Ahvpfi^CJVdisCLZ&-^kGb>`S+wrTy%*3l?1P-MeZJ~7XmY`&M1
z=zkgZd#-llXmRQJ`Q^G&<?l)-qv_=%#YNmc(opAQ9pm)W$f9T7EPn_DUJvgC59c(b
z1SA)?pGaOc^Y<U;FqSSd_M7%us|<CY{G4N7Hhjs|Jo^jL9;F-8R#Ji9GAK@DbSOuY
zp&n@C2wh&ctKXqI-mGu!UD;dN)J0vrwwD5FiAeSL-^DBKg7XPuS0DY@*|KxoWrb%w
zqLR6n>d-wyyc^QBEZ)#J>qVnh4(gf?s0xb3scth3cd5q9l`RLEI_7bCbIBfi%TMsH
z{Xhidjg&}3G{6tnF$Y~Bm1%42O^iDdPrlztb*c*wyjDYFKn!W8+@DGUM;qi3rm-;m
zpv+b2)DW4LwV3Iq^%TsY3P!k+Z_7MWS8q5Lrlzd|*UB<E$<L;a7(OQxH86Da09s7a
z{EMpPix(U&>foFNxwSjgCJPsqAO1f?F@j7&Sk!q6;=Y~6e;6VSX<tMpCF|sRaumen
z=Apx4N#R`m#pp2I+>gTtLt3XNAz6T?MmD!?Pb@C@r;B?LX|AznmS{p=N5sT!On;UH
zrz|nv+@E=9xrE736`8Eu^2PR*EIs}PUa~#r3Adb4v|6@|ZqZw!qR%l^qb4}wSc!`Z
zL6;6XE3d%SkS#!rY0VbK<?LtW25wjW<&(3)mGgoq)~Jmbh0mV`TKqn9qW%CZ)2FhG
z|7NDM2zYe!DVgi!Wt4Q7&Toj`zGZ>v3ZLJgX``JtMcw{t`NWTm?os|88p^%`dx(`W
z!2;%n@F6=G2h9pyZ0ol|d)4{QK}35Vdujj_>Nmq?cI5cxkn{-TgGtgSxuuIE<7;Xq
zEaRGg`=?I6A2#E!!BouC{jiND1BNs}P${DvUJvqdGSCwt-M<>8K4N^OPZ#_u(K(q_
zef;al%d{#NW{h#%5ZVf=SHive2f|^?y)RqAU@*$ZMTcSas!%oG@REm!6jEd)It4=2
z%)>}v!6gLsGwK;+kIJ#ICf$ld()#%962}@plT2J)UwF`6PFtLsuyWg8oc8CEDz1Jv
z?oeg#H|1ecA}-NDmVK#_#)T8?E4&T(${`O-^4x7qN)Wj|@3vA$z=#ohMt3*+*aNn;
z5JGGNh~D|0n%p$_x_WoKF^e;XCk{qeZbc9u@~<!QiXR0T4+fTPTrn!&$K21-N9)rM
z^RC@vUxv)rU99~vH92V}_dS&ka3%wf*l}#BtBhYFa5|&zHkGdAS$RbHWTdRUxib0E
zW+Q_(dHQ4P#5Jj6(`owmnX2WK2Ov_0!PR!|rJz{-Hj4Yu@&s`6UpzgaA>zNe!DF%4
zs7?krXA|xB>6yGci35c6{p<qY4=LMR$sT1xVfOIJq?fYbkARwrrgEO5dC>m=M?o3N

literal 0
HcmV?d00001

diff --git a/doc/assistant/genkey.png b/doc/assistant/genkey.png
new file mode 100644
index 0000000000000000000000000000000000000000..6c1e509715b3c49b63ebcaf73246885bbeaf7901
GIT binary patch
literal 27854
zcmb@u1yo(jwk^7FcPDsocXtv9?ykYz-3jjQ5Fog_YtZ2C?(XhyvG+aqp8ei$=fBqe
zpQ|A?nX~4oQB|`>@1qx?ax!8Fu(+@Q002S!+ZP1@0Mr`*0Qn3J3Ow^!BHbVO15#g7
z><i%i<CEQ97!N!HWBX0r0RVtQ`}hI@q-9_OPeM70OMiu0g+W23K?%s!)&&5F0ODVS
zlw6li+GV9a-M75IHz2Tp@FMGTL}u1C74q#p9|tzXwfg0L#yg}r096BLm-E8N^$6s^
z#-IJB+SKW=jd$1uDW+=2?uuq2ulBM<3;R@jQL2>d0hjLT@Mo+4{wLZrd4bspGB$-P
zys<ajCxeqqSKGHZeg<M}WB#oDYtNtikDfmtM;2J9gT7}25+xvh5JCSS`uVB8+x{2j
zl+BZL=OM>y!TQbfqmKnEE<&a+GPn?OFHP>zedjx$y5GmeI@(A1$_zrlKgb=C0m~tc
z9JeL2<~5)nr`nh)&ryN5famLc)SNvd`BA}tDkZqX{M(iP7bS(io{jwXm0MQX)YoF@
zeeLah%us(B5H^!8Q#kn7Q!mZs6xaSTQ8mqd5d6asq2lC^Hc;OFW#oS<{oR0nUHSiB
z`oC!EKi%-3nrefqZ1V&47iAp9hlA%sB=Voi^K=IDBvVs>=DYSav&XyZNP~J?6*m%f
z7EGH7Av-%e|Lyro+GiD2)mqxpNmCsoP;b6s4uQ_FUrp`pR@G{6k6G`JKJVx6(m8^E
zbymmw+q2L6y$@1w4;vd>a|BJ;mgHzh$vFS>30r}VJbD(N$6e+7Q|0>=!@DrbU-w|H
zSl@H3dn#&brVlsSXdaD@w;nn!88VNKkH>EVyE0_{n~RGJDe9ytYbDWhM*{;^=r77J
zedg4c>8!Ue^dAk<VeomH&Wal}B<E;9Y0$YX;h4@JId5-oFE1~zuV=I80(R8pl9{=A
zNoA#K>1;FExunKJ$Cxt1fybAR;rOYCMpEi%epy_i{iB#3@2)GYqR@HENBZF{4r-2K
zUDfqJzyG>4-FLlVM)QIf;fm>_)&irI<g}j$qhCJ;!=*&d-{bSYy5he^7DE6v^Y7|l
zBx4Rv8XS>gX>SYBTq0s<iFSsV_lM|rXh{F}JDc~r<j$8q^ZK{TXdfjlWxyQqmsn72
z%rX#0f<iM#AH@1B!eL9P^^R9aDylCrVF@W`xyU4duCzSMpFHM}H>f&j-QO<tIIE0(
z6D@g7;!6eI{?wF7`GMu)Hyj<qr)#B+{I=Cg&nwGG;9&g*{X^lLi7eg)#IUAvYUUHd
z%I!0z>eeQw0@VSwnw04=%coWbKP&It>9f_qYKG3SED@2aHaBxv7K6L|MAu74hBEhk
z3L9Fn7|=3uN8Oe`>^$~R214_{T+ECR^d`(i3!iD`SX1U7XJZCXpvkvjSPv)WtxTP@
zlBK@o*gs)lmoJo5GFjT2F$YHprQ^(PB35|)npqTWenSPnguKMn$%-+sv9WP*xPE(m
z9-sB=8E;Uzk}gx5;A3a^p?KCs>jL>s1hMf8C+hHcLnA*)omP#d3!_2?8?g)`L<kz}
zt5Jd^@)@XI)#>v93G%Ph(0e_NeSe+C{r)L#-(>+QBNemXrp~d3Y#PzoiB)0fNMqpG
z!~ro|!{v{8H&lr^Nw4j>^Y-s+YvU%utgJH@NMOF0fEY$FmUU?n8xUj!cc=ktQf6sE
z04g2)%eqc5|8`W0%SHI7?*RBN5IcY>Lqk1JTOX|F+v9#}B%#kstkE_yNmq{Y6>+Y(
zdi_-umBss(MQ8B+PJ-Coiy+|4P-?Gp#_GsUb)z?9B!i)5x7K|KvZN|Z>BV*sl?P@k
z#o=tFIVcFSUZZ@-U!@)OWtYKcu*{uhc{kZ0c4K1Ug&V*qja7+s$7aDrTX7{>!9*&|
z(ak91{zU%Le8}$D*N!Yv)|WH=t5tjXZ5I6I6aWsAyFUQHPII(=@BJ~%L@2=|n5Dez
zZ3bC(`3<$7B8V?H{+PFIxDkY(o1@_XDR9mYU5fh#Aw{~O)OXF>o7U0Qiq-4+&e8_x
z#da^v9F<9~;P<5=4Lp45gLLdpUT&Odu&!A`8%ga<x?<U4hxEZg3%#@$YEO#UHXm|$
zzybC>pnGb^6dQUa<<LO`;M(Q~4#>W)oEH9}n}*jC-@OvKNMJ(aJKMYn^s4Ez`O<`C
z({2j5NgF16<8TX4eFx`x2VNVPO!(#|=JbXm`Sac<>8X;$z(~|*EZt{1CpOok;6tgc
z%*<Ag{h?%-E+;E*V}V<O$xw*ZR0jkdnLIs$6npMr@R9*GES;A8>F@fR11rtLz1dz?
zbVgN<O@&mqsJ%7}w;JVhQg@>($8?(Ba~!RR0Mq7;3};po^0*4;F#)^7B_jcY21uR}
zujgbA?N@{FR7+n>(lc6ma{98U7He;~xj!|F;jT-!P4k;Ab_3u6AhdMkZzbs`_U_T7
z#7>K?*fv8W7Nsm_IW(!CA&KfyqsMjNbaxpVdD@88?B@|3lBKRI$*3o(F=20Xb;OO1
zD(cH3-0v9RMeK)?CdHnX_C^vDog5=LlPWNDI5RZ|sgDmB;i$e-)jB-NWT63)=4z5~
z8`B;Vs#swF*TXpk6o8R2ljNXe$WixAnfXS4jj=KVE;kohZoY5}x-NXuD%ahy#sc4J
zuc|K7IF)i*%Y+4iya)3tr%s1cua;|708!g{aW41eMX}N!qt3PjP=m*#xM>Y`IRrlc
zTFFM_fj>uK)w8gIA*=26NuZ1qi((FxLP}lL@Ai{~?+*h4?~miZDBm8(eN^moUFhr5
z7O@FV{$%AsE=A6FI?=f<w`(u<X?1zfvEZaK=)4{yd0%&-`)VFTk3L^RkSnC@L(+S3
z#8UyfI2!GhV1}jk9~%86*GB=i<Huc&fF!?T7OV>IcxmEVnr0(8Yw?748xUrV#}~hm
z1gisr&YMgDeVo|Fln8!>>8GRK#IL5KV<4f^*%$84&Kw6^x%3wM7aDEZ*ug2W;znri
zZ<7;8xB$^o>4(#b>$_AP5B(b5=#;jr($OBD*Rk~(FRJDH#m6mXiLw%2%b}%r=nEm>
z2QGH;L>%6rN@=f`_m@tv0Tm*4OJN~oBrItCfH~+iI8hU4@@?OgzG!C0m~)y4%vNL5
z5g)b1<w=G$)8X|#C#LDwy)o@O>%|d$XEx@^fpla`0^}zX5Itk-KKlnPpOr<c*&fg8
z(_wYMf^HkW(2r@e<HgP|ryXY!epnB-JfBdBRzLw|g@|<iunlBX`LjdjoXaug)4zhP
zn;aZ3!?cd*%4L~A#&>WhPO&*8%G>P|7ux#Nttkvl#mm=0Y+Wv4iO}&zpXg!_IvWs8
z{d%W7UrG)oTCIe~pnEb;-LZqqMXr-U$^yEX!zFP_sgcra?o?&=gdOi>7=RNsBbnMk
zKMJDpwLcR*J2TC>(LM|`5p1aiO4VALo}M0o8$^$(2{gO7e7ScLT>=<%MT62@EOctA
zU!+cr&^4}T9iF|Wjpl<Aq3bXp&l*pGna*Juf7(SY+w*5Asw+@QUcGyiI}+W>mVii@
zGWXdH#YBV3o>khTp&7c}{0#T=krCc%tYZ!qz2OdlLFW^MUT223(yq~(Kkw?}yjfmA
z->@#|#VF*ml|3^{>XhXU;_i7e4!hB5Wrlz0dIV;{-B|2ctaAl3#omLvH@+_>3=P`S
zJGSbhAU^hqRx_I$1tLH0R>WRnBBO7Ib<2_zumy>~57HDa*#MJ&N~)V*FYqY5rcV(y
zt~w`UDbqTJWh#uwY~4s+tncgdPiDV#sa;};EL=f=`|frPV<}cd&-0~%(jzw7L99#d
z`s=~#rC-++1BgumM+!496U+I~Q==HhNU<CG*xSwsBPal($qw2DXRgUGpqLC`U77aH
ztkYt5&12uG;Xn0JHRf42ORnRAfziC)eh-ux;lXJRX!ZNDH8zsxF~L&ED7P$~F}D&6
z%|ORMU#FpO2bgfuNC(C(`8s5E4Yz@Nl>oKW_PPBAL-Mp@!UB-*CohDE;|+UCyzqKQ
z%P_X0g1*S0oK+H)HOl0_I}={@F1l`U!iBJ(x5BZ!@BEbT0E7q*{c~!D^-@R5W#i>M
zFaVn5%9UnM)6UlyHBGVf(d}8b`u=%gz{5gI%uoTIKUeFQxzFwnTAv6G4Vs);K0Wu;
zqx%-jC5=pKX$M8uz{e*??}mImJCIINBXt>^yQt|A<pL%A&ZT%_J?PP8e~%t@(2KV&
zbN>L=uNi+wBYB)z3gTsv)h&2>_$eb(D@|7`Yyb_Q!QF~9cYRYt`-79Dv)P1G7w-%V
z9>9CO*}5k51#APWOuq8>x^5Hi0rsCUdp{-`%#q=WF09<&Z#hN7rH+2`u>mW5zftJB
zMtw4qMG@)9402$4_o%A`6)iN4KOZ=JW^X*mOkk*#%aV!)k;G0yrhO#D7<;v-b~d>S
zNN(HAX3#8TX>}MoySVk{n&vTYVnIPPtab5dq|+R6C)RYayE=RGlGc_?ZT24A7qzq=
zJRf^m);FVxFOgJJc3VggTTXav-Etvj=kT$*!r){IM!`O-6|{h~?c;;FfCY2PUIsN)
z?Y`{m`wH;#@_H;(NhM5^g%Ktmc#Flw*w6@}_vTA_oD0U$^X07axv%fz-TGOb3Mjk6
zK5`-MfX;>pF^rGd+?qX(a^}k;P?W1G1cd>#Se`v(x&frSxYMvDJxEyLvi<!`9`E+G
z*?Z3c6CjXXKF`j6F*O>av|^PJcP8{}4S??=V&-1OY6yW(JIU|_9Y<Ww{L5!ENR0^a
zY3d&jt08t0OP4%aYOvXB8^r@~whhy8h{k$kL;4o@or8{zSdFyucAVIeR6ELHEyb2{
zSe>Faaye)lJL2y>C|Hm3c)uF!mImyGmuuK9B-D5I)K)R4^Z7G@T_%NJUeGE~;UHl;
zC{bYkaU7*((7}PY7|lQ1BXC(19A!MX2}-s$93$|Chg?AIhS_=$j-GK1m2$+<Of&I(
zo9!La=Oh48m^jj_!{(-IkWsvUqpMdzR9u&8s=Osr!944o?=t<~fXK;%Uv9ZZQt7&w
z?2=f63WIGIt?Qgt)lg&1h}0CU={Pcvh`+T-=8x0W2Xl_lNO<hB6~S(8nuw|(TH4{f
zy`{?H;>l0?z+-&;@MYid-3`ZK@Hk#}5<)@p_nQi$u69-jb8`wb11P)(&%i+W=(89D
z*HZAs=#wWAfv&$wq1E|ygr+^34@<Bl%g@1KxX{_Jc?zaAj@(a{r}-6w8UWw#8PjO-
z6@YHZ3AXyk1!lL#1#$(Iaz^0Vw9YkU6z&kJ2l)1tc6BY3et*MVpAQl61CSK>gTkL+
zHWY#x7))S!Wq#{r(ACU3+|lH!(8>nw>eAca&Hn^g;(lIWCKf{mFL%#J_6_mn^hIBo
zA~Znptpe~vBnhE;9Dv9)f7PL{M?dE(34li-8WI`EaeH5H0^q|buE{epRx@J4$Y(3V
z3wtKYURZ{Q8Z<AgUh8_Ms-v%U;3w22w(;jv&bDGBV|M+Tz=ddFuB99+Wzv)O1z;O#
zj<b$3nwp?MknnOsKDy<pHG-C^;IT{m`T^Aq3f?s$j1&NVLB)k6VaG~=IXuF))Ndr9
zMut{|qk_dNqB{<n^0XK1&qAILiw3lw>h>)t)d4=JXOj|XKOfP+WB<qe{cSlLKspJ|
z&kSoZID-<T)7N#ux)nu2(BcentZ5JeJb!K9Z*BfL{j;eZeL1JE(!ntqn*F`dXhS8Q
zA)fuOUg50$)BVo1&gyc92%f>W4@!U&*E-!u>fY*4XNnrqsyJCT8)Nz0cN5L%P_pe9
zv~Y2z5&QzMVsOX3vCD9;a!2)4qMukT8!w;8V84J9K}7k9A5~Bb$&8?&66IwZOh^@)
z^lBn#+mh?hi+24{xm$AD;@JNJ7YHlVCO2aU`u~CL`0-Ef!}a1RYqPDoTFCluPNRbx
z_tU3Agb&<n1J$x2^+AIC6WacV(%)nb5NZA!weufKe}V6Rkw8Fn{DG*2UW^rNz`L0P
zkdZy|M`25$mOU?AZxWCQUhtI1XpXiWTsM_VUYUD4PC|z6z0dZgHy}zbaYc8JSyUG{
zeBL%cSNht+bw<Q7REYsY4GG$VtNTTKZGMwvld-kvgB2Q!C6=Qxt7Q-4=&!P;`vWI@
zwW)+Al_r~%_9y!TYh8dp_uZvR&qg6$iztZ>Uf$SkFfyKg{k(=f9L)N<A%qx^@7G9#
zZa!3v7sHf~pdMd}??V<TS+DbHYL40#`SxwHQZLinD+d2;lE_033$mVPnBpK41rP-Q
za<s$=y06|kU4AnVW+=dvhP%vnK@ooez>mNu#4@amo^2*eW|ZM4`Q-hSU{CY8YU;!X
zh1@G(5jb5RdC=gcAIK9X6A5M;Qe<0q1PzdrpNEyoRF!Pf?1v_MCEJ7$hZ&mTuMrdO
zQ~iugRoM^`xJv@-_AB9QB|6vqez4FWJvsyVL(kh5ix;i^uR3N0p4vIVqLZV2y;S8A
zd6-W@_8@Mg4&v<cjGw-x)0E8M_Vv@&D^5kHE>I%AT}^tZ^?<^}K_=rX68DMdG&2Yr
zfl2ktp|Vq9EhM<pY^2#V7_1zc?YD5=;B2}y=w#UMNY@Ut`1?oEua9gH>8l5Gw}^iB
z8y?fCtR2RHX_81n-#EcVaMO;WC-hyo3MllMS=&xOaO(YG4M59vxC94wi$iTGz}REJ
zaOc_u4DD59OvlFXtR~k&iKG^DP(VSJ?9-@#+sJx@{bCkBUqNs>=DY%I;s{|FoJ^|#
z(RXegJ?&R|=tmPq6xGgjtc4$lP?kVrvI>0?klc(Sh)yfLVB6&SBl2e}x;{fG<O=y@
zjZW@f-!BII5$^j=geE`9)o7usM7lvu*iQDRxkFF01}>QVgsZT1-st?&?di1INcN{b
zfk~y!FP9MA%veQHa|$00#z_m8JNH~6*~M8|Yt5EPRCe%e(<(yIU!gs<es#@x!WuPn
z;sz3Dv|q{D!+12w-NRXFV~ETyYQTgJV+2|lNWJK6ihd9zB3MeaW1zy9BWY;b7n<P_
zTFT(BbX@7&jcBf{I=s1sFZ+=3V5^{Bh;sATJS|=x%Zw`w#?dCBrffd7?7sl|c|#u_
zII#9!E>Yf#EC>Y0l~s*#Cb=i#eG15_)>#gbTx6WQx9`gu%JWFM6=>hT@g-WaDw&5S
zwGLvXYhEup(P5!er}ALjE)Q6%lRrUfhD#4rhiK3T?Y%;!jk|AKv7cQq-pIOxCWW4H
z`8e)8rI={<L&s?k%Wpt%u?&@H`-vfrg^{<1tGL`}2$*JGNIg*_f~AIB1(f4+yq-Kb
z4eZ2GOeylaN4vw)%m#V}(KFa7&NGZW=6+@|AmA@mgPkWi&E$C9^eYx0N5C;6b#W&L
z7DC6;y?uHW?pnJ2*z$1cj70R-;m$s%NdD#Byk=67|MqUt7n9xGMztOV;^a<kXCg|x
zD~t!>srjoQ>I3=3E^oz$li91o!YuErK?)#WNJmEpWNa=MYfbt->sPCNVM<*jIKv)$
zQ=?7g!^a$MhguKS6j<@N&~`~DQ{7!l`k*2;wHtPF%PyA1<<ZYW2MHS+y#LG&S?$<J
z4%yVIomr86m48|GFMrYCBHg7qFE-50pBYvrJa{Q_*a;>i2!&0oQ==V(;$U#n6t!NH
zJUgdlUyVkJ>siJBl_Gzz78n(^j1&j)i~DYQ>AW=~HoR5EFqIiKp-4Mc4Doh%E!S}1
zI?yjJL;<@U7BVV;=c?7V$aDYCdO=H{$9&&TdqyWM=CBW+MA)wfJ(@-G(uke0hBnb?
z!^kaBBXeav`a$w56EJZH@u0e!UJ^5@;!LAe3bRIqNt)uEyx8l;-NKHMpg3ZmyinCK
zlwJ75_3#=$x^bX;1l}IDlai9==H_JiA9to@1-!(ItBxML)_f-~CmBsFM>7r$Wv9n{
zelC6koc&hEEc*bZV`b7>dtdH+<H&9o6{K@u&Uf@vIP%dcm1zYaQaCXMOJn296m&W)
zffG8hc{7<$+epv&H<b!%*Fm;G0;8t|bd_xqvvzCjZORh~oQ`5L4d-!S{<uEv3{CYq
zCIAlj`WtFhk@$gHAAJ)0t0U#ca_g~MQ2Yy3w9anAk#N+dS!GXaS?#!Hy?1&kR8kpE
z`YkQs^FV=NV(d!lkj2fnB}@+Yyx&E=T5-}lHwmoChTkL`$jn9*Fe~5(4-#jpwwMy5
z<A`-r8N%@GNJSD6PLgG~K>)bro_^cO?xR+#!?p7*8LA+2L#OLX0)i&#sQ?pj@IzS=
zN_sAC=V9B!Wts3;5!RcpHW2&JpoB(Tp9vG+Mr70<cilCvL`l0~J@Yn#bd4lH89i*+
zFJDqD4qDcG)1D+!tzCQfaJdBxs@=ULd*;b(5{?2Ev{lwKUcW$ExS@#BQwilPCAw?T
z^pcdVk@k}K-nn&WD<llK1!^C#lsUW8e$QF$#IEOYH%Y3!&g>FX8za4VtS9|wb$t+W
zt4AIn$@~T)y;KV=ZZ8hnY_NeeQhlg9QJ%z|jE&a7HV{nccT8n3R$mn7ubhPF(d6!N
zpJ-6mamyqI+n2LjM4liDFyUT-08_xrkE$cYh0~ze^hKD)+;o@-^=duDsPZW7Sjo*@
z3DHrkl>$MeJ;q}&_>eIGzyO8B`(pQe?Rdn>1vD8&6Z+{j4kB-t=FBYAZ4DVg2ePwj
zOVRPYvMdgeQC?Q6ZR4y<=<tA|NpI9rVN7p+b{7#vuEF5Q=AZyc2>qnBf%OYcW<Fas
z2Svj1x(hC!lv3&W8v&OZX5DT1NJ|$(*@`V&{ViW|Ack1NuLI?m*FQDdDcET{SXxOl
z-DJ4}5e5D{KR^T?0%O*#Osj_|KQ}9yGz5XtU%=5^*NVYzYyoGD2-)-x&krxb|I158
z8EU_3<ABp;lNd$;Qk4^V2=Q^qQ~o3*E-0=h^s4$XZUM3Z1D(^mRHrl)|7U80G-PCL
zctnia{zy>AAy+z;gQMZfCN4`F=rzjN#QvBU0q48c_^+zGX)a#VtQkAI;fHUZ&fpOt
zjeq#-YIkz)Trd__`Q*@4Rt3C(6fPfLr5Iz4>T=mxh?C@t52~&y4vO-Kwux9*`e`#q
zapp*iC-Qm{w`9aMw^*01kx6-U+;JAtkx2!AU+zk*e!MhGH`M&R%|4IKvCPsrmfEt~
zQzII4puzvB6O)|%#cG#eFw`l6X9aN#JtZ2ubyd-S91U{lvxLx1_ZkZieqGYV9kFE6
zf$&@L`m9j&IIA1Y7@L#skQX70P)}9mI$F@8+bnS|@SPLBy<NdnY35w*v;sq}vtk?y
zNHSIOLl{n{AuJ}Rz4~zI;m5G+?!LP=m~OO5wqM^IOA6HyN4O^YhTFDMR0n)<CrY=W
zMp1sJ90X7jF4#c+l~+=3NcIu&`0sQ9#-C6S3(x>`NBA_Pb^Q=f6cBE_6QnCBRW0DV
zOcE3tM$cCTlZl8nI}^gU6%^GskdIPJ*xON=vA{P;X$NWl*+w#g%<K`?gL<(Du!2%^
z@04^8f$3PXp{1@f_@iZ*cZthv8bnPyrRsT00Gv19np%90nq8R6XE**@SRKY_R^=?#
zvl@knx~sPv`jL@_5Hjp@iPX)|bIXIA9ab1dI3Z%&xWN0%-RUwh$WqU#1odZpQc#7|
zhZPrz-}&QP0Q%XYHiX0!nqWgT2+Vla<f|yGPm1=1$Z)Tl;i1coV9aO3NN+Whni8oI
z;Nt$n(Z!z9JHeh1Xf{;3k{XpW0dnkBMw~8pnUEDS+M~r+F)d!LaCTT8W<?-MLdp=P
z%uwB%jDXrj_!D7t0EUv(8#RaGMpMBWN0#sE9FyLRCif5ib;Ba3@BOdrG=or&wiBCb
zbuz1U^`C_BN*U#3jEy~?alPnX;|%-xP#SKUJT%sC<XpK#-s*XNMSaJP+*=VN+$~(o
z>iLeh(y_X_JD+83X;WBL3x&~TDyN!T!q-<Ulfm_^ov<TI?fr4Ep$M`GZDTA$^mg!N
zMiXLdw~Cu_H~j`DK=Zryc$3M-smjzGni`Y|ZYoZ8n+JT)2Bq5Clqj7|h*$c6cIF9F
zh<`Hsj&AK|XW#Z;nUD9@Xh?)*Hn1cBB@>mF@u@?KP<$u-<ImTrTGa!`Nc!V5f^1ds
z3o<sM-hB5U{v}IVAR4zFBW9|AtRJ!dhgPcg>Hv=f8-|yLnsYm7u)sfSZJhm)9ZBB!
z7CKWgKBrN7*rK_Uo{p}w=`IL3?`VkUAS2=;uY*hGk+^a&X1uFw80@aK#Y~Mw%E}hU
zkwHt;vv(B_q)%|p57P+s6zhCqrE97}G^Hn{#RIy7&JryHyzuB(8U=l-6O_BF9EN{7
zAEOo&v$}K?o-H#mvcI$9isl;Oc(v2dPNe8cy;pR^DuZmWQtxT6R^C5Sgr3Hq6QF0$
zRK?b2{7Vb)S9&~*(}?%kmG6!-5iqqN17?PyfG`_6y&qA;|A43Bg%H2IXP%<#r=&5G
zEb@2yT7swmiO$4=ZRLDzRVq`aVCwMnMuwS;oKRp9<zhH@`W!z`2VtstoYx|TK1t&5
zdzgy=A+6%dPSShtGqs~V5DH~sT%#pjDxq4+xU>uzu652f4j%iC-Z`gq1r2sS=}_5I
zcrBup<dU6a&=>-RjPH?o3^GuC(aI%SOV=FoOc)1>Dw?~iZjtyt2$zprcsEOK;u^~A
zXA*8ZM(JmLW2g+cPReY)qq_6e*WiZ%50<a<y6jhQyd7AJZg?nx!3(QO`Dn_;10(TS
zfRJa475M64CVAHoRtDJ4e!@4{Y|&-G;(NMYmZJ(wW@tA^eC>IiCd9{c5HIm5Aik&^
zUIH30M>Irt_tL<}fB8s)|9={Q*B}Z<)X{!Ft#PvNQ}+JK-#L)Um7wUtdaqyXQ)cyc
z6CEt@%7+`;OJG?5qC8qG($`Sx^scu2a(I6HuIABw4k*!RKigrFZGWVYcwFwLelUWD
zh&GBAR)hT2SEz#=ww6K{0003X`&D@!XhXzB!Vc#rN616>4WWmQ&R_^XOT)P>r#2*k
z<j5&iGj|_tt+HMGZX1Zja?+AmUReG5eBxf{qo&fM;Ki%;P=%P25qsU5tHwk&1!)X<
zMf$Ct>@Qq7+$V15N=t|s;b|4f{PYb%(9A!9PR_I%%!;%}M4XU}?(=C{SO(<^M5kv}
zhdgRl@JxK7%G!3Yu8Q{WCK{yzSG}Y(<elCi`%NY1H0nA*vtVjGmt8&ubZr3gFiUIR
zaF}ya*x-H!nGVKM8ui``S5Y&%d0bi$b^D-e3t|yS&3x9UH1EO+9|3JI>f#dVU*!3F
zwp*(j+fbrjs~r)z*?VQ1Gdkr=p-XiVr6p`_7Thjd8)w!Cat<#FHgBN{);!$%j`uAm
zeEhPVd<`dyNa?$&zlFq-ZH#S^t9xvsu+&sL;e@@*#I#<mb@T#FC)Q0I93Nl2*okZ8
zYUDx2Dkfv*cMquDKRH-(>3wo^eB^!2^`v~3vlp+9s+c^;Se`w0a&9I8Q6=55KeO4#
zxZw2gLTeX!Ig+9>A{X7?f?4n|-Zxgw=g|>fW_l*^bz3g03(9|1(`u4~B0_D_n!w);
zql#r;=1HnmxRigh*8Ao2XYn|4MBCXha;Q%ng^3{QI(H*CwSs$mxi+U;41ZtDz!S%d
z6ijf52x6aEf;K7G&^6&SH_wRlQyi<MIz@jH1<=Ghg7q(zpD`V2!p3_F`L3pRc-Q{M
zm(fz$)Hp5>qV(31_LvGJ>@AF&C$};;OOLa@!X86BN`v31&SO#cO+K)&95<q5uaun>
zf%r1>=4G5b$i58ozEoi(VTRYc|8#+(6o%f*1>bh?xe;vJa0x%JL-&o}+lkoznD@il
zGa;_`y>}0nmGYUrL%{_M0zYRV-}AG>K0mX!ZIne3zbT30#zX#E%*@@yE}8YwQy>ry
z8XAxEm^iyLc<j-gopHUl^__OwAAF_63oqK$H(kqGM$5SEU$(>xw}@Z+TH5L{Mp!4~
zO72DW$*4M^3x0l{Z=YdeLf{ZajT{JNCu5Hde%_AAh*#6VxOUG)rF%QSv>4bAq8%Q#
z9hwYO^6)M0pH$}A(oL<oO%oENq}{Ag=1Yw$WBK|uAI|v^97ZKiIJ;WoKHFR;PE<J(
zhQnbU0J=UMo&fJ&g<6%bNI^B@;wdA&i{48e`v)-I*~-J_8wird&)FsNm9w>@>MMi9
z0traM>M20v8yGtNj01>MhLtm{<|XaPwfvYui!piMhq>)W;zOc+9KMec5?)5P>|yln
z=SX@R<qf)d>ixPdSSPIh16~qm=kn)|f|dA~utcv8oXHCt)8QpeU16I@Vnjj>L2OG?
z(@A6WYK_zlLPL^$s^iGFzMa@QIy8dHy_#Csdfcj#*Ze9-jnSN&5r7l*jG3*l@`L)W
z)+TkfOyH6N1iweU=Mxa!dR~cJSXf9(4i6Cec;20;UxujBCT&?s{u@wS9z2;u4BuVz
zKkqFkJmY()XdP7`+8=-#+&n{+UqSsUFSXV>F=_WK#H?vSLlw5wE;bmI;W;Qum*f#0
z*N3}D8uH8a8xB?VJ@YA+)jsUYd~P0P7*a!=)oub;o}m1Iq*;2Ynu5q8|Bza76Hg))
zc@lfn$Yg^T!uy?`B)<%4YRhAfZYM7C*UQS!U|1b3PxG-L^62kRvt2WzghNMv`}nDJ
zMc;l?z9Kp<iRv&dm*>)10lm*d|7xJToG@X)B!_B9JpS?lXxf!L9naa&Q~pkXoHeJ(
zlM}<ZuF<LbT#k{LgnBgkH%a~`x8h}H`)eJAIiq}5hN!{MW}580I@BiPKVKiVqct@&
zG&D5@9(Uqp1zvB+^1B;%hQDr4>jb-~n`AYbzp|?$(aHc|y7)MUe_;6DDsAQpEk~9O
z%wVZsq_t@MR%f8~!u*_GY_z2YAm>Y`oUagPxRgrH0N>#=El*HGOXeD-TN#@yGXcTo
zV$WZ|&F7{swyItV#2vbm@0aLXEtX<R`0&n5M^L$_4A41;XH`+|TJ*#<O{jM3ZD(hl
zo2Vp`G_j@Ib2U%jAO#oc@dovoH{~1t<(FzI*3C>U`0Iihlx;<O!^Al9?aLS264w=~
zXg<8JmZBVrKRbt(6x}A0rW(q`V6pLUf>DEP5I`_xaL6Rhyz{6^f28>Ea26D+0@VBj
z9()C}zSmD1z`&ip^%bp7^3-O8VrN<zgJz&0hY3gn^!@=)SDTMPglW5vq=jigO^tBr
zB4t8Wjc!L5qm`;K)vI?~hW^5zVhROP1Cn0d8<e;zbD2ZvrSPH~xwIxbxuv^X;0ja-
zjE!`z<cmq{rJ+Wn_;5ePQ<l?ii&z2Fxe<L~Jt9JcWV8<G^9fY{#MS2xL4KfSfv>3g
zE?GQsG^v5q_+v(8IlQL20SF*nC+&;9*9H|i$KGfbM>OSmb$et5v~97qy%yWp-rcE8
zU;LAQGn73bT7yZ!OJBj!OPX)SO%jSKviowkq;{oX!0l};94#d3i))W+&8(c_;7ix(
z9GH()0MeG8RE)JZuvDy@fWI2z(&04Wg9&B9y$C!0KE%Bl3{|$b;n{%dM80Z8pi|*8
z!VX8i^w*V}vJ;QW`wl~ce<0V*EGA!;QODdfzv4_`i&Gt#z0N>L;d^rr$K&xtZWGAu
z;SO+gzSnBTI69Hv;T!}MMbu!@AV$Y|CDcdQ&nM8~u<6>SgYu>Hlp!$^abNRZQqf5-
zZO_SdL3n>R@@}Xp@*Yz^fbQYiU{@=H{hx`jVQHj&>R$W&l+qKuU{3|?dwM1#{IAPH
z1q{H**pd6+kmPD-9+Rij#5RlcT9||MYH|U~vuHnl1ye2+BjF~zmvwMn-M=uUrggNz
z%BHhzL6>Lm!s$=k1dF=f=W@}0s|qIT1{3d07N^!=qh5j}qIP^%_~$3S?<tw8_{>9|
zPOnEXJw18dZ-Eu4_zd-THI#G6S1LpELNz>M3T0)i#gYD}|HQoHGJu8gXlbl=vbxq<
zFXx)_)?5TZ6O-kW#0H?gLfu5&5H!24au+na3^;0Xl?WZaX^8q+B$VtpA|fqOIBBgg
z^G^lw`1|{%Ze;&>NMH}lV-@eCkBV;XZ!1{ro3o=xd2op0c?5+e2QRiNu<BzxIllj*
z=X~;9+O|8)Rd@1@>KJA4t)<*Onep^-X*;9g8@2jSG%AxDx>e%HvJJ?<dA=X0tr$?o
z8*a3@0fFlR(W^MYWIEPrgA73e>d0Bgk~JF$)5`EB(iQK+3;G2jMGf2NQ=(gEqG4;F
zJ`nm^o9N)-qh^nyks0{)zK!<jLr9pVck1f&fQG^CAIp_k3}MjFl)G+UIR6`lbvR$A
zk3u8HeCokMYqWt1!}!Bt^VZPDZ`4Y)xC={5jzf^&FYN6qp&{BlW|WDI+65@5)faSK
zx4ybmA3~3tlAvm!CQ8J?;$3PU8qiknOvpqgZDi5FcrGpD1Gf65iRL&~p?_RmValkF
zN3xIfr%jTpQ3j7oMNW=TxypVgYmCA<Tp-fbW_C}tX=aO=hobJq&rkzoF$%p#CwT1J
zq^Rt14jgms6uV?<uI-=Dn(ixn<pUMbiGjiP!@y*d)sVYU@qOd-6S$_V9)5<Iq49?F
zXlspXXee_TqSPa~7v!dj+C0k{P7Ku|@7WP=#rbr7o6;~cxU@P$==xcSi#kBlv3gfp
zWKW+~o__#(Ly^&*u{|HZjFWfGeHfY5XtLxUA^(+=){*j@AE~^ohQWY9lNvF)ag7;R
zg$?J;9?AciRdXfATlZ*3ftL4$SO!0!L5X<>d=BDC!{dh@lb96w$W^H**w7xN-3JNV
zf%zxYb1gXx!WfLp2LcDEQ2HxgThcC%^dx<sJt?90mk+h9c3#YyUjgDD&oMWwUjP6#
z<R1?x8*Y$#+!Bot&?-3PRm~K4gPc?b?bxK^^wn~$AHhD(PDad}u^urcRq%75n}~oa
zy2Ww3JqCsQMv<-=t-E4NJCKgWiMSpnlm*%LZfzov1_)1REe}7$VBK{*|0+cGYr!DO
z0BAL|7`MCo%x<xLxE!!@MCS^UKL1HStFh&DhNBCaoy3GA+yJAha%7d?4at~afwum+
z+)36&4Ncf|>8zX*MAz3uA{3Bj@(|QkE_rioFSvsT0IBbHJ`Lq^ZmWrbISxg$TMxoS
z+4g~RopZKz%Ymlp=`km}1D5V{%XUtuiws$@c~er`#l^oP?fKuJ96r^p(TT%vH-}7o
zD|JmtUYIl=85Dt?lUva}dY%^1-8z&rdd}0gk<ZWu|CUQ4{yViZ+1CA6Y6o$5^&n$<
z^|<E#f%o-pp~gfYoe(u~8K(+?yT$Y8n>_yx-6Gq+Aiz~3`bXQoRk>7Ao%J`ywX)qR
z<AzXqTb*9^@KqEHD$N_Z=aodStV>X20pyC6mId|2JnLdh_${~}e?J>7BP+gKO1A%=
zc*?FPYaH8t&~u<pX|-#O^W~UYbekTJ(sgl93d1T6jzc0GdF$Pq^K{l84ji!_&l6bT
znthC1uU%>&xgHbuUbG=>HA+4BWC^j+ev;bQ)Vlw2joJ7fmTZ7huLVE)jKrGt5hSl{
zVx0f)fi-5x(8)h@FYSi&YP4jGJ-1HdkCLGzKml{uB1Qw!oP_KntL@c}IN)+Y6qfTf
zs-hY<a+b5)MhdKYVNZx1LhWpa3NoX>ljd@v|FU%>W5K7D8Q?Mgw)`74XJu4%plY`F
z_ma^|&%Du>-ID7vc5CMdS#_3o`Ze{eOART!2=?Ql^5LoBRa3nwew@bDwk4Ax(&?_D
zG#@QS;sstJ&ZqMQ-_1?_tagi*aS&T%5*?pEY%KBzVA`7dTXGh<y2-P+H7)W$PU?Ls
zZQY8=?%;?ys0{5&+rhEXsEm{<449Fo+*_>8v-Wu&jF&D-ai@dx^+^KHHUiI61k^=5
z(8MfYu8o$KmVZZY=oXM9=!sTm;^xQQizo*`-r3AWWxn&e@W$IG@Rm}jW*X=j$9lj^
z!ZO;?`l=WViq%FSK8e8eGzJ0SOwKa?71Sj_2>w508Z11QjxXqsPp(zU*Y}S6`lzVP
z-!ndIwx3)xNV_*Ar~uQ}0i=VOtj-XOY~Ri=mU-$C3R%JzGWh@@6@2oim3Dq<b*@F$
z^`eKLDO~QNHV4W^{yT5r{GMZk0&xrOi}4^rCMj?of$~5(jPrP4F3#4*k?!g}!sfVY
zqc5GRYI|(Sg0{g-ST)4X%B$~ykeOAj*4~l7d3>hN<rOq56HP{2_l%Y6EOtIpQ=333
zNYQ&%^JGkPZATX_HGdWJ_qe~fIm8^8;g#e?@$2sw5#O4D+P@PxdTGP!^l0yi+8p#n
zzC<F%1#}XXwSYOde%~oL5nlXnR=!rz#JUx&DPlo*;+#Rbe{rZ~>DKuEmMNI9+6b^0
zWlhd#-1mcvvw_>0OtGvqH9W1AFE=-I4o-U%wb)zVG)~u6T>&mR;*Bw_#!Xuyq1k}w
zz`;*9gq~B|pFdDL9vuSjO@jrf001c}S)k(w(Q^n_Wm)1T_t;m-HwMgv@Ms{^2pr|9
z#8*^dumOpI%GqATaj9h$dPGFJWq0e_mZs(gAh~Y#?)t_yd*VD0;_`=X;VBt&RK|2U
zPl7<d>(F@&*HV|hLL-AL%<vevfLj|bT{{7gKSCP0ta20Y2@_v~qYbU!?2MoKFRIFW
zi+g8(TX1WRmlJceFc>lTN`~R$G)f0SS@B(q%tt`ZCv;aNP91Hqe{41Y0dUGI)@Gu*
zWbwICpUh@iaxUnqA_=;-BtCLvO1xa%XZ@@YproSA6y%n#No;xAewymSt|AxwCNz-E
zb>46CMpJ6P{I9Tq_<4+EF<JAgDue;7src77+m6nM(Qyc;WVbp8z~50s-qcZdz$(@|
z@dlNX&s~MDtGpQLSB!I|DK>HW8*X9XCI-;448F!kR}oD*{#E64{-+pu6J6W~M=?*^
z^L-8Js}&FTqM6PL0rxoc`X`5e#d^TsEOAEswF4*oMtd9IBkwATPwV+{BJuyegsW19
z{Le~nQ8=Lfv9?VDqk$+aB_7$V8jUlrp23&<TYj0)>R=er4dn$i){)ToNRv;cEc3ZN
zn^_<!qvyLj0X+gB;truR;p<n=?nY|(DOb`@@ZIHA6(%bza@BbM3Iu$w=z($+yNw&3
z+d~(bny-Ya{C!17>)Q$>6rjo_BD%krydQLgzWa-JzD-v$mrs;5e!0WwD%9K2b4Mf|
z233R51^;*{uEi+Zh=}-Wl&kE@`(;Gl>i$%*7(cA9JL1Cyh69z5!&5Tiz@0r?jZhwY
z@D%AaKsoq_3?@9UVMRe*n*F1S5LK9eY)bl1`)~e(PUZ!2QHc9eQ>L8>n)qTESy=D}
z`u0K38m=1%bH6K>kPe;DPRns!eNv{EXnq;O_432_JjMI09F4_b+ZIzBvMor0`TTf3
ziA8dRU9fhr@}qry_PF}~A*20g*9KANk+RzC8cRCPI`MdR?y<&i`SGIX?48Hzso6vh
zrJpaN`Cs|6$P?K#I{Xzh+Ef3nUJeL(-=<9Mjj(Ydeh6n4s2CYbQq*O@6imqAE38?_
zc#JnJ6HLf1*65aEh^${GF#V|=C9WGjZ|`NSH)iu{Y;3ntV9~&K?g~`zAjg*RFtPxM
zoLwgQTh|T=={W;++gc&{p@~6>zyY8E$N|ViJE{VlyZgz+D~V=Bo`XG+puV<PFZOTl
zBuY&yx_qR%YV>m~G!(VLy7cQsb(1@^IB^W>ek!Q_v9z>>7!Ojd!DaZ=F>ZP~Ai_mO
zlRdD>wqYd7;TA^pb$BUXhrWaet0lE3eKxZyF6AUMkX7hL!Qh#4mB&LOPJ0TSAL`E?
z)%AJ$ivH7b?S1#Rz}Efy{_j26_pY<)o3pj?d-euJ65p(ID_+kk7(lCRmgsx++x@}#
z{Z{A8YvE3hkDydyT!#1E#o$u=vyYGC`+0TbpLU=}u;vxszAI*-s37vWOWhw(ke4m`
z;UPRdTLQHwo#W(RFvE_=?xH}jYZ*XO8u7WwvamD5DfG@$Gt)=M5@WlJOe*IWcf-K7
z9%n(m>}Q<mB)1RjA2tpo@#W)EYu02>{zEHsw)N=s+w2|+anQvv67zU)9YN{_iOZus
zws|<JLjF;dEK+4I4oX5iu}rYE8;@GKsZ8ZBx^rOhIQ;;BOVtE63Nt17Z}L<p4vnP3
zn}eZ>xgNcQT77tu4L8%F^==durU_OmVBu<HBRhAPgM~9h?OSX;1ZS(Lh)#0uu&Sfm
zH<CMv$K#?fe6uz@Vgl?SW1lUy8ZgqStsb%NvqJ}jg8M0i{$TN5Z@0XPDOT?bodT(C
zsB^XqFRZT0NnHZcFPEA3vfdYO4R@<q?9(rmo!|Dgzh4(Vr+0>FX~&B%&)j@d_5sqs
ziu?Jl6T=J(w)0@b;1?@zIsfDj^XJTa9Hs$4!PGU<t(KFKa|7ay;hpQ}OrVaW?73yS
zR>@X^-_b2Jy~P{I&EcowTwgGU3qQs|L`J!xUS8VJk34RFev_Z~{OvyWui$JnxifBI
z-r+@1_TK|I1xHksiK4v8Aq~_T_DY~<!&4Okht2Eby6eAr>`VK&>X}bD<ZhVyxp862
z5BE*938)fr9!EAVa;j7$2`iIXl#_12X!2Np2zR0e$z<~iyS}Uq|8xrna-jk?cF&cr
z80zVL3ZN`ny7w8K*;R%oiC6RTe+^y&B=~%tErg9P2Dwr4W^9ZZC14jj>Jkv9Y>T-X
z2r@;04RL0KF1gB0R>q^_oT>h}`Z&<-%TfFdd@ln7HW`)ex(<}Ab`Ad5n`xkeBd@-`
zK0kkVJ6eF><F3s03qi<M{yBjYywCh97yp{u=ACQf!$I&!&Id!N^1-=9$Khj2+G!8J
z$%LOwj@-4=$)oq>Dbf9dQ52W2AnpUoU)nO!zh3@Kd9kxN4t^1hN3zyAYKT~AOHMfY
zR{hiJ+4%t|kE!8HWKFY|lt?O*D)l6VqnSMFBmmy(S(Ru>bEQ%3=HnTIcXo!{7g2Ff
z@94PVEq6dFUYMX<pFndxs$lu+pUkE7ukyG#Z&DP^xaz`QU04jB?vKfynVCr<)W%;@
zS}L2tdD;0^oL^sm8xL$e&;vkr6nL;a()c{rj`Nq!{wygkf7RWW@t%9yG|8%ed7B=8
ztCY=0)Aerv9(P$9wZZSjx6>sCF8uo7E86ZIr8KmT<rO_FSmroREyh0psJ@{FASpK|
z*FJ!iUL#Bl)CgG*{57LYueFlfWi7rcPDvPf9aKR@({7$->^*4+i|$DwAIk3!bI5v|
zO216Z*AdG_D=az4A`4dH@+J5SRpJ5@O=tg$G3;tP6`eCU3a53I)~?tn!%E^0k5xWE
zcT<*}9paFz4n_6#uuX!X0UT2eqm-4KVD$e)^-<1Fd2y8oj+)$jGOWv`Vg)MdIotlG
z=C@(l=&V^@9RYR!B}EPC)mC58E$%x4fRaUxeJNWB@I6Lc_JhqqkB*j>+;KUrqbYWw
zlPn)YA4SCmRUc)8ENYX#$GmU=6?5q|T)s8e#dz`Yg$yJjYL!{*sbN}w2N}U@GJV<R
zZVf2LVVa+C>I`MOrIL&JJG3o|V?Ytdm2M_WOy-RPHgUL->;ff;1*Yu_i1;;P^n#Yi
zz6q^LrH$D`i)ORpj<T|xB<g<=k5~NQs;TvoeL6-4d1d+-MBh0?O>*3_IO*F;%S&E2
zR{Ez`Pk}ko)21h(Zddb46(1S#)oqtbm+rI9WBf0Uke<ksU1{SL7R@o*=KoNL;CoS5
zL8Ab5AXnV~P6JLmB#v0Hns;olL%1^rs}t%8vOWtDo6sDa&!?}>58!$C4*9UF{aaML
ztSFuf+>>z?M^+#AL|th3oy;l_)cXRCxN~_zpN^B%Z0#Q^7D?IxNv^Ltvo-akOfHTr
ze{DqgT|HY(Gj4FIP_4R%9jhXB`O$%A#m;FHq1!!(g>HA=BC}A^6vvV0=O9QNKNJ7d
z%>sIFWcCE??y<d_ix&C5ce3zuIu6XS@NlBri{fu9E`F^9QgevTOYVECIo1PBA|(y^
zrrW-i6}tHLU#wmwze0qWBk1C{71Z9Y;M(UtPt|FO>`Lr$9DNXGpBr)}N{sSOe>vFN
zlIbQam+Xrc@aaMUa=wVwEQ853I?U-k+uPOm-k!by*Bju#C6gc!q8Y5Tm%voX#`qER
zUGsfwp>2`<j8-l?z>UfBQwoBC>jF7dl@gts@~*bJxd%`R1ADvZz6a$6$ypGVD6e<Q
zo2M_^+&M(;9B}!Ilc3^ue9BP<59{ZPqtC0)S$L~3+l6%|ZdVkgSMk#qIw-+~v9%qP
zIG9<JEU!Cir_s)w_QuA>=4Q9|x7S?Qzoj8+kj9vgl8MmB7<&5O6Ec$B)S5*;L9AfJ
z0BBEgK;!DqU_%Olvg?r{Hl+qb?_7W|D0X(@S9oYRQxiC4?Y+q{@zR7wd~J*fs%$ch
z$DYTx<wl!f4r(*jz@!A)VlA5g;oVfz<FsSukFLiBI=!BqzxiT9&5fxREVKbsu*gq3
z9*{s}i=PwX>W50G&xaJ2<%viHgX1PiY)<tVum*nW`y{GLZGLn(vlnrQDxilEH*zmG
znqT4cdj0)%9WY|d;(OsEMpVGh>!Q$8Rb>8fm^}Kk@N@XTv;aGEA|hZthfc!!4yT*7
zM;fnC`!X2eyNX-xhLHveLAB?Ahuz<~2C42aZlKPZ1HSS$htN-+@i}vWIQO4QXCpjF
zED!DO>pEiS4HeE&9Jl;EIS*`UH43elmLhH9>!~DQe*K!!ESzK{^m3$UxLt$NWAB90
z^KuCGK`+I0VN;$x_pv1>+u9Evble(*Imwd?YzcBGw2(E;BYRJi5^(!d%L9Y*P1&OK
z&zucmDVSo1c$QET#@ua$2jrSzdD@4*1MZ}Il0VPj7^cjhC2|B_Da~bF%|bB&^$P@R
z+qBvM+s^q%xNp5YA-Ae#^X*(H7ZM;ExSq*H9Ad)kQKCGNkmUIkP*8nnD8ZXr{H=7Y
z(NPEOFEGH}prJewn5$Evh1qqc>*VuXCM_?4EVjGS?0|rPU|z40I52D)qS9_dQEquy
zsYZZSPJPfVZ-drQYg7Bt@~z0gwfVoq7XKl%|EE~~{~tm8f7S92v3$t7-cfl;$<y2O
z`QK{&<K5@;&dQRKrFR>w!$KS7BjsYHW~-p@p8SN(86O+|+g*7Hl8jiEWw$S%-$Odu
z8dy!nGTi8Z%d|ZD*F*`7&@Xp)cT3C5gO?wu$6|A;^L71w{eGPVzEnY|zVY?ovfmlE
zCB968OgK>!_FPa3lt-=@Fe<d`2wI|DR6-2v3&3!wa>Q&T8|v(zNzW}QITCok7Qn*9
z9LwOkZe4$kBJusO!|0{+`Wov!+UjiXU9l9i#NxP@@Ahf@a_5ZR*Cf4l@KoEX9aHdW
zv8Viip*p3izB+R)jA@p~Tr^!>bnQK>-h@|IGuPWupaDgeJ;NM81Y2EhdSfTGu;QAu
z7RE9X)uNHE=}`jw?*p}}Z40AxZufV0%$>k*Q-^g#(5<bl5_3c5PN~N`KZq`P85DiD
zn^pn?;i(gkCUeDZpIiVZr{6WdmHxD1&nS~Oli886^kvPa;&fZ2fM669eJ^Qyg{XJt
z*pkJSofRRYGC^8^D7mr*Pe4tlN@XC0Py*xeeX<odGzz0C!Y0a>O3h#u)nI}#V^&!T
zY)W32FlXp1!l8l)D@{IDH3Pa^iCXy$Aqwv$-W4|Dj1<eKTQ#&eNL2ewjusQFOQklA
zyIiz<$vbID+Im*S!u%612RoVvkN9e_Xwm&F+C9MlVd(-|WQMa1NAn|T>|B-8Z3gVO
zi#B&vPB(?p3T|QsOy3mDpOzP?Er6c{73s2`2J!Oeb_kJ+QI^)wt$L*~ofP$jb8PH}
z8f6v6Y)(t&^+$`fO5BxS-K^kZuoB%Hnr|(|ddw}3WB{&rtj!dpN3u#ROOSxj(SgBC
zK9%J^jA<sa@n*!oGmDJt5rX^Ks%nGF2bci2g*WCHB}zuP%GOMP!<pL1a+8u0G^g7o
zJ`^4pZxb;<_WUtRyCMj@hp=MlY*AN9t@QEjQ{-qsQ#@}z4@BZq%s{CuE4yiQUeB8K
z)nGjM!qQU9(oXG+wS8$vLt3#FrG?<*A1cBArK=_Cli}g(8G@>G3LHTEen<vB^YRsQ
zVt`gqVS03<%biTdjKdQ5&-FF0rw7&n`}2;*_Ck%$djUWMVHz;fL8HzK9L<^|IAdJl
zF+rf-m_J~^{XTs2)|!Tf0OUieU^ki|MenWaAu}NL!*s*T3bD^JYas#AHM_DFG8y18
z61)}ek^8u*Tudxn=B#PJLrOnMw%x<S12<B%W8v<u!4pRwy<WrW_t-!*Vb;{#uH*Cn
zD(bAGqI{x<zmy;?5=w(09n!H2h$0QLbR*qJ!%|B~N=OO<OLwO<(w$35gLEt{xxDN5
z_j})W{&}7=XYQPP=AM~5^Lg%b$GsFH+_Z2VLk^f)yw4pqZ{82F{4p(@Q__%ioQo|f
zEEKNV;K5L!D#WX)*JfTGElc&$uAy<N{?eXC+tUjo_nNl1aavO_&EZHKVm&`)nh>Gm
z>(f}Gmr*9ES!hWG=%KwIu~D^WzJl-9jh&$O-M^zNC2a*>Z2S$7m?`=_zcjg~8;s0L
zn;c?INVpnXP@jq<ljpF=znGri-d54m&@OFk>T6c|1G>GjI`S#RC5tODYB1)r`n2bU
zVkZ=ZD;Hx|p+yx=z~Y(NJhl4z)1uHx>+fkJlhM%xfZytniUP_`m5gh}i@h=0Iz6ru
z6?>rGT+v_Kt1##Ng=B?X8+*8&s)j>PrgZM)p1T17#u{d~eGhGcr^kV+?Ql4jkeO=s
z<nATJL0J$=8M+V-T3TKJx!3S2Bou?z_X@Q1F|45%3DE=&er9~t-xh0|s@1gnZR&q3
zMP1%;&C)rl87-p!k$H%ppVT;N_tERO)&PLr-HCD+yN*}b92z!JF7>NQDcI&`b92~%
zT((}}jKXLz6+mUiE=izd$rP~B@mhdVIrliRAr!5um-k0?SZ6yMUxlbQyIEu~NUyx;
zQ)Uk>A0==7Z{JuL&|N{ln_50BT1Ps6a@W1k_Irs&#x-x6%8`u<8-JG4A5x!^#QLpz
z5ZKr#vyh3I&Lsgob?6<p{+W4(UU{+2pPccKXi{||>(ZKpP_5vR`)9FE#{k4G6;&x3
z;I_}0&c4@7RRv}@kdaumG}!mRG5WtS|JYm*P;?R9Au%7>E3^voB$4tpE8U+dTpZzA
zxd)-V*%C{Dvq1@DLDPvnX~<qcP>_ro72beRRa^UtjVWM<t>P+$<xPejfyt|e)Up|2
z0l1@sW1%oD4AN*Vz0_@~R|?X<v-c4uZ*eM1sp!p^W${;l!^G9GiZsJ+ubHmQTRyCQ
zuJJe@<hOU6Js3|UX(0<ZtJ}^94NWUtY&m72LQuj14S%zy;I2EijkHernWrpug*8?T
z`agUG2{dip!9AAET0UAGy-t$eBy+Ih6t&kZ%H<^aWE}BYLkb76jdlbG)T)>1i0Fd>
zMa?uY<j`&Fo2AeO_bu+2JNA<<T+VFJKhDj~lxR%22<lVq9~A=oX~i;1N-g-_3~3be
z75-sQiYzT&nW!2kQMGF-ql|cuPASB{$@GO3`un;4YgF!}t9H8<hl~S{AVW@DEoUC%
zn!lHi$k_OVjhq!`aH5VgH!BA_lT5D%iH}*#SA0r~Pl6`d--g)EUg$Kh6g2k7W0}ah
zGs7kTQ1;0;Rc@^h-oXVnQ8xl7z_%p6bGcI4CY)ubV$7HV%KF+$wr}tnTa;PiO45@s
zq(bQ&#s{de)~0vxlG49UoQ}4elbXM+Fx2#hQm1|E$ms)!R8S1Qu&}KGF5B6aM=Gnh
zX=V~n)@-xrtuJi2602!jxG)h7=VMEe%ShAX<#`xxW?p`l3M_`qQ+1KlXN(=G)wE{h
zo3bH#qPhiYo2VHu)0K)2#vuyXtWiz1EzMFtAGQG_N6Y|F<8O``(x;uid-f!7*Qs&8
z`l8l9^q<joNsiEFyNYESbeaR~XIjW@_>XDv+tg-%O$?v=zW>x=4tG4vqE<$q4H%-%
zA7`7LlB_IcWN>*i2f5&Ib|1DdWYU=K4SQ?Kg+(7??aOqR%>P~Su@(KB{s5NS565qt
z@dGLpNN+9{lAME_+!>Lx5h)`w(XN!U>9O229t`Rt;Z$x83c;9HA#tW^Ng_F<E~E0D
z`FynnPvV&RJc^iY*oZZ{kL5zM?MiYr=a!E7iS-|{4A>kyoek1ULr{ObyVmq@p~*qh
z6F3*yG>9DvWoa25HNJuw!H{-d*u^uE^zZN1795LGaMiS=o-)LRXv#!jFfe76M(&yC
zHV4PZWLiyxuzpI%C@p!9v%^UdpCdYq#ljXj;2dA0!Vsda88JL-O43-}_BtXFfAz<e
z(y%KEOUX96Mk|a`;y2gk1F5zxSh13ZGkV(ft91{^1fS5q|5{}So;(-xtYsh^*z;bb
z)U*K@z2D_pqAyJOvgwT@g%fzaG_?Jm$1rdYG7nNvob?cEM1?h>Vk`4oi^Dht_?xL2
zdWvStkXiit?6v+3vheuV)`HR@4>o}m=+K{(Wm-gP8<Yo2?pg<*YPN|7u*N@eWf3Fg
zCJbd~>qFE`lL>Y>v$aWkcjvE>NQnk$4lA~HTQ&k3u7-<co{3HGn)OuW)wwxM=agNq
zR$*tB;AZC+sH*D$ADcPaAEB4TUVyZaY7Lyjh$8L7y^x|W>2>U7IKHIzgebctcg;)G
z>v(hQ>|}i7a#K#Squ_W_n0{E-;x7lDd)qYi4xz&1;xL@MMm^<F;fQga7($AiO0MtP
zK6D6>z|Q(Eyqyr}koKj-G4&OcV=H>JMxLzpPjbb$=eE>c|7##UTXU@ex%Y~0bBXB*
zu#zpURv?#@tuQK8Uuhiloh)DHL1p|R+yyMcB}a|(_V4<gSfk~M?Xj=z-Pp*nxLJkO
zT$F&e#PIykupqhiH%o1qYHPQ$NtaKyUrIo9>RCDhM!{jx7{4{JXf29^f2-_VG1s(4
z=TD6!zUOZlo^g{O&QLw-OkHT(`ffKqK4e(#^0MU`iIs@pPH6B#-s>W^xi9R#toTZF
z7;sPHQR`iTeT1|G9=yAHT_@{=PjJ?!4=P}0c1LC9!mK!3KU_bfOTArw=%O;min(25
z24vyIEvXD949QoXJ}6Afn%(_53z(dWBkp1VurQ8vjaark{o4C6>RTf#51v&ThM)b-
z(b&VxW65HTy^x!fVYLel6~u}^;l$<P)`h=%+WLE~?igz?H=B^U3klN<uS0E*+H{?H
zTT%G<{W+sFYyx`12-x=tA^zNjO!tGKAcVk$2FXd+c_x`*P<XZHt-w1NA!p1r-dts(
zX3VCBA&py~nnHGtmCc)s#f$m@m7xijrwmqwGMe;&BE(h0kdOD|Fok9%YxGVUDl&T{
zSvYA^3&;b1vF<eyHxYM&4(;?zNLGJyM~&OB*laTv4PNHkY0W!`{OMAa>ou<>vP-@8
zHZd4i$;yc+;@{wl=&p=`7qr^KtS#L|JNd&O4ZyH^gpb)>1&MfCI1Y%?>i}7!pcLtt
z{{Ee?Y?~M1)BcBrtd@35G6qW4>1uUm@*7|O9rW{Ah)VML&Am!el1#C3k+SqOOyI8e
zBo7?n!dz~m+7dE$B(FV%d+ILgxFgy?9*!Fzz3UqmUbb~(vk1)}5m)hvlh&G5ICoB&
zXp%&@QEg@zNQY;iw5QWGEDC7zlKLB(*u*@|;9&u&O{#xi$WHG0Zw_EbzZF3g!Aqjd
zD5eM>l%HIc(j^{PYd;0qt=mA1C<bOFxtzHCNW6Yb|56tF!PX02z^hJoOOc4&+7L4w
zd<g*d#~?2ZsG#xurV)pEthTh!#wsoQTMtBg)2@f<7N1)*`jyvvG{KZtAw^BpSciMz
z=-!6Ia8vfiyEG*RvZH1j^k}5P7|V~QTFaKZ-002(oMIc_y3x4&ByIS2)}5RKcaBdq
zJ_+!*QB=KMUAezp#5~{SUf15y^#-R;1Fl!%iGw=r0uUEz51hEbftA<by8r7?z^qn<
zsmoiIqaFxZyg-g;;5lyqEpxS^k&GZf1kcXh$Hb=m`KGW|JrH0e;nQyB<lYV%TO6Hf
zFDpY<6UiU9UOH=Bj0O!456|y%44-XnSp*Hv^gZNxOL{}TOO7hC2+uXQnilAldhFcv
zwJjKumekwYFB906XPVi~IC4{#XPs72K}s)eebjuLh3RA&i!%$qm8bZq6gxW!g~e;E
zay2#IxPUW7M2Zs|9dW~x`hsWplFn?nzNFIF{x^r_z*`&6tP;zrREA)Y7Dz?AUa=Ej
zl`+bB^mjG9CLN%-TyD}+D};hz<}def(=d%}h$x6%y=4pvQ%YE%0xt=}C7F?KV$=X|
zF(lr?i(Oj*%10X$A<2NWUpo5EV5z{Yg)8$Xya=DgRYij-kXV{2@N*6y<!D6F0Aosi
zubX2mZd+?S_S&czQ#$tfnDtoj31CebhoL~Df%VWiEW~wnADwt6L@OMV-hfcfq`jiA
z4vf|5HqR0$e?REvYp~1plCqNkf&t|qt8>3q1Cpw$0Q`k0<2ntLnuUn1lTa38zbLR4
z&sfYg_ZC;Qz;D|VsBKASOHz)!DS9V8oKY{V_<`?<2N9A~s@MfxZu2eO%8L~*zFiD(
zu}l2V83Q)7A#2_s@gU)s9=~ge)xGPpW))ZhT)Mq!$ULr6r#<HrR^UsLTtAzdQb#SP
z_u$UdnL8G`v+f|+IE!Y}^^VwY3VKXFG}XPdm&!e(h6}kC5mH%h0e8p^7{{5fyw?M@
zektqQwo+`suVi=$bn!=yViY=kU_l&6hXhKZ5}vo?O0qEF0ODEb!|G7uh)7kotsd<K
zM<q2@M9GvNtK(qu=`P&fpKF?TD?c$Uwfe@ftSQuH0mS=7)y#M_ubLopa&yWFS2PE4
z%@3?9FhJD?e&kwY>ud`}z9i8#Fjj6ZxU*L4B(v*12s*7T7N|*k&)%pVTyc3~O%g(A
z{IMh-BCq7)rp%$65K*x`hpAa_q8w2{CY&Z`cS_tSF84}PwA54oY}150c7!*jGIK9i
z-v13HP=d=zGGQ9B{?uhLoprnCOXtfJD?z~qY^r*^T1hWku~uTERWc(rGnP<$ap8nP
zuT$ROxZ#<x$$dtAkJmx+XA0=%xu&TF_AjRT-t?o)O8Uv!S$r=#g@_-!Mh6Hg9~c)-
zpC<K+Yg5kqf5tuf_WPcnWAu=_ky})Vg&R{Mz}-k)*uvL0`P3@FTkddKAEaU6?A0;4
z{+l7-FN>fNjzTfwE{8RU;b|b5h*qr)C50#R<qmv*IE4q5#SvjAc-9OzV${Y3jz146
zAC5c+galL0J$1mvwZ_x}ppGM=aQ~s7bNi~~jWCI$)r&Jg3Oe+C)n0+_z%5kqEn1+I
z3I)MubUEOx6aP;rmDF~CP+ER3lcOgBjfRnIk^!pJiGfy?N3T<yhE6C$9JE7ElD8D2
zFF~O`z+q=U8a(h0eVbIk;M>qtoZ@<DoXDZ7O3gWO>L6aHYuw=MJxC@{cRngfKx=Vt
z$ueat8kL{G`FuRr+S0QrG5!Z1?P3d&3oCTpZ2h#q2ZKl3DXQgE-fzYO-tnR0RTi`7
zFL&SyLb8P|5R{?UWD2?pt;gvZ+aXH8!ju~DC<J5n9PN`-b*m<mC;UWZ&!G_mW;xu;
z1HJ(6*F%M(+A8`yye4Ao<rw9fKf*G?bogmBOvtamOrXfc!<yD_`4{GN5|Nf3DT-`O
zu*^13y6qEC1w`0?F5(jfUe`1FuyWyg9ES5a>!tO%Mn2l-t&H_414%IhnnuXb&g~(p
zKyhm#*>(?CAMW#!<rgnr_+xQ~`Uw>2_%Zuf4dujZ<0V!q9x=N-Ad@@+*WhxL=W$L6
z3|yBag*+av4PTtc{DHV@ru#Ny(mxk6voJBajzz)BB}wz^i8Z6UdiUriS`3Wt0R9UX
zYKn&!)cmyXZsSu#pQ7rFDF;@}b}xbB=fH;ZkvLK}(73B%%BDyG!ILLX8utCzau7hp
z_&;~;2hE>e@IB`{R2|FVDT30d^78UlP2A~CQb1WF56NDIy0Luvr&8dT6>X!tn!u!W
zlM9p{CMMY_1ZDXD%A<Rg59@z#_?#DfDDi(C40rxdk><hpui&-)PmBN8<R0Xe!b2eg
zi_1%_snmU#nHGyNgEjo?_?kYO0x*7VFBL$MkVlX6ofb80FB-I7a~|`x(%>)v$Nkka
zQTnWdDj~V$mgJtR+7}jDW+*|g{%lVgzn3d1gDb4Zp`YgMg(#x1pa$HY&d$I5S>sS5
z2<!j|<o3AFS*W$02lK5Ij(61VqP0NIPrS~*551;ptfb$&Vh_~_rLog57z{?y-BURq
z$;i;4Q6^6}0_6fKtA$))um!~Nn|n4d9O{!>MY*y~$3vLSgSj2D_;Hpy4Q{G1OLb=U
zmzIj#%3#TwZVkA$r;pb;)A8sJr9J&n(<)4sA59VnqV&YZgR#7Cy)S#Hk7-P8@kg#@
zdx~YK6snJ(2ho2d&Hu<+r8#MgZpZr~c0`g76Zr6=GPA4Ki8d76ybF8rJos&`=;`(C
z(O$nun6YmbZM9TPF{@wV?p0xOSl3oL`*}d^CRanIw&g=rwlGdmf4^+M^DJ9~!(s!7
zGP<I&a<g*ziKP;w(><X_H`dQ3*vEt>l9NV0sb?eo$@SsMkaR%Kefl3T1t1(V+zIZx
zcgzm4_PZnDA67Bz#CC6RWkbb-**J9!%d7>>0phEp`Yeuw|4zGP5lZ96V1H}WmmmBc
z#82}zS%Yg9mqeGVMHD>;jk^fDM@!X&t*X<Rp1la;nqKdT3W-MB>&sebt1wuG8l70`
zkJ;CN@W<|G$Ke|0pJBu{W5grR1*oTAjUg0tGx(pMvn@}4ko#rVas1~O(4qVFbDz7M
z{I4VcU(Dez2#lg(wYkY!Tbp4S&ugWt#|P!&YX^3Uz?7-WSxdi^xw4w2y5A8kl3`T+
z-oC!AZEexI9`_xuMci3V_hGBmX!CY;cG{i+rZ98rr`HAehw~gK-Lnr~&!()=*xA4j
zU^L=+!&=FD;8XgvwLhiaM&h5J1#bQv9WOC&#mr(+`ZoPCYs_SpX4H@kQ{dO=+*vDR
zA3N`%&0!aOdT5yd&s%=OwR0Hoh|?iPgJR^~^Qq%L<*CZPa*W9`!P>UkrJvp~+clz9
zF2c}#FM9w|Y?P~dz_43y=Oukkzmv~HGV&EmWwLQh$*lR&PF!!9>T8FxK<*gF`?bkq
z@;N1JneFwMndwGa1<R>hBop}zxu5;f7$`aXoR$PwVrT{cOdF(l@fuA7d}@jsd+Q&b
zjfhVp?T<Ma)4@h@cG}RYS3jSB4iS?d`waQ3y5rLtYUa~(EsF<5wyyaE_JQ3uRK#LI
zB^qPgf@h^FD=G_BgE@;Llkp!SX2gbE!ZMss((%^zYcq55y(pF`a|y2>kp*yn1(Uyh
zZM|J#IE5O?TW6R47luDB%_<;PwF~}BWHOWIt*p0WmbIwERjMLRb>Q&$+@fPG(upu9
zh#L*cN`)J3sY9jiB!)d0_!~e}(-xD5M~szCpn_E&Fq@<3x;HD0XYORwl+)mqnd_Z(
zJZsOLjsP#FXFq>7PcN5}g*GrApT7u3$MBgU8v0V^lbqg}a$G^a+WsEzV;}~!GgU&U
zAk$pKX$)t=&i%va!jXH7_7owGL;&)BYdB?8GQjTvHUw}V4Ga6m@p9$|Kj1;j3jTfB
zh$9G$@A4&3lx^1F#Ln>M9V+!#uW@Y4)6r9fXHu0jshq_|9c=qkS&|vbEmpfPE)Oos
zXy*A{UrN9EYF!ya%n1m=c@pU1pX<8Y*t~5Gc|~NA8$U+EV2(x{8(+;~xKsk15|vkX
z@A)8Q<H<HtiHH7@p!_&*%l$S<k)YFe!X}3LjWLflF5t<-o;e&uBn~;+pVNdCO?IZP
z2wP2XBn_XLn}d|}C=6sv4UX|7?El86za=FR<b0X*KwCYqn;!OEbs4?tcPvPe(+HL{
zh?fp@Z~_K9n#pV?cD1X_#<|tI6;`+s*|N>bH1<DYAUg)ClxOzue&0m@%3j?cdor!>
z%=$7ZPmk`r<it&ES^k^F&DE8MU&f-q=zLP@huv+-jIw0A=t=_5DMx>VU`NA}yj|P%
zci@t6J0V1pGH^Mz%kA8*`?xW)olsv=Z`{YUv|{ykl91KL*THMr==?70?tww)E1DaX
zx@6CE<EdNgd@An;IHfVRn(OA>UEkcVYb0%Zo27jiC177SmyRg9GI%l;dw)#JHN>X&
zq3!a*VdCy|cig9xZT|1J1jd^g{(+=rF>|x!;`5I<0Q@j@q9QE?=4Ud`>J``kp}~Vr
z=c#T_LW8UE;3X`~&+>PcewpBA>2QDPT)H3JpGw1$D%MemIoBHLP_~T!fx)Z$1Tc2i
z`fC%l*`LH#yfm3TzJS*OUfdoR#AvZ6F_U7!RU!eQX8d@HlcbtLkrq#%1V9rw8^$uy
zHOx&<L^$jKuN$cH|L%~4LyQI~Fi9~Dw9Wyy)7>oJv2Rpu+(gnbrP}OCG1HR;rH=GX
z%hq($KN)vdgBV*}3;1D&A;V+p!y9-hDS}@Dz9ql{n#CU7O!gDX7QH5?+!^h6K8$16
z*KOuh%bh)PP7G}wHESuX$2RR7a;F@G>zB@ic7M9)E6ib?B)2#;5&(pd3kl1@{+{kI
z+&W4GSn0S{E+9R$F`;UW!qeO;6?F?sc9#(CMnE7Lx^MOM;ETT>uH5p-51wJ!EfLl6
zsqz-?w&)>`-GHf{K1b(2!0TsjXBOaFH?D6xGFPr&Ba6r+UILChA+DE)d8YW-ua7Q=
zcZ8+z1pyC^t3qQcLw#NXf18(YHEBD|`uQ9s4&r%#_>8WsZ4&}=0PWpUN|*R9ZN#oV
zPo>7olQ+{C(Z2I!B(gU+c(yE$Celgz!w=jwHH|aS_=l3HF}VSTIiOBG5%;XDNRUyg
zN`YQ=L)ygG{xw%`L1(;+9Z)4^o&Yu=J?QfuJ}hx6g7Xiz1nlv!k4;zHug4isG<0lK
zm#JS(W3dpE5|OXDOkg{hZeCrVT_Gorj#ee1A<|ND164BkNSDQz4QR!$ytP`FES|hs
zLdyzA2k6pMJQ|#}DCldBY~agN`hP;mnM&9^H<|EF`_k8|?AL~QZ^1Ihe|XHae{~)6
zNW$gNWPNA@Kb@7YI6&@5^NgQQK3nVU{lXeKsncq}4a>~TxyU2Jlk}rvp}ElF2<_pg
zdJ6*p@P+@~5umnA+z#Y{geCj9CMSs4zUY#ceAKPUlBeEMiR><{w5>)z!C6L5NVFLy
ziL%-8$tIZ|%dTQ)5#vhjZ1l&5Q$h!q+KSbm78vA2(+!`w2GZC93S9qg8zhLZr??Qk
z6Q(rqeLFl(n`k;Yarvd)J+!%7%Knnmr47>v2e9FaA4}UBa{3Ctd;PNrE#e99_&Mr}
zSh0qfsHo`G7Q*dGPS|XB$UQIug@fzEg%y}xCkU5Bd2HaGBNlO$$zaP@2V6Df8AZ|J
z#%!Z#tm&Dmiy8gjGN|gKM2jpk=Jo-w%z6yrECA*wPt3SX&%sv&Ap*}8e`pf&rS{HB
z2i=-)d{c83a8C(*5mYGqTR7t}??dhcH;}*ek#bfqnR6^IZ=K?baQ*upBJV~-Z^|~w
zTKYBFLr?<Z1LYYm&Eu9H2~jzT|1U9l_h5K49sfl|tox7A?U@;}@$(<f6ex0fYPL~$
zu&jt~SMNf)xRc62?_3(P^dYq8IUr3A0-nqu$n#xJyT~SY-6)A0c@AKdt@*AAxk@6o
zUX2y`%&;~I!)x)gwd-TbETgIPcfW);h7=Z$5e#3V!}Y*X)ibpNmy0JSC&UZF<eR7S
zHDxU=5Bg@b)?R<U%yXfrqgia-uy;4Lo8_i+afNQ}o6e+jo5piDq|E4y``fk_>hXu(
z9zD)bgK06IFxxFY5Ql$!nx$A;Mt<&h-=`yvEg*OK3cY65L28_Zw3_=G1><M^BHeU%
zyv9z&Qlyp-x`VtPj%IDi2^|3w!sU0|<B&auvdWL5G3OT-=8IRBOIUH^JDw$FeeYu&
zk&8{rZJxDyS?#s#q`&W&Ic5^Htk45i=yZ~X2FI5=^Ao2!mnQ=_6{(JJSv)E7Rp(e>
z+&mI<;9_UECtE(;m>H}PmGiJC4SHDp;_C7j{-S?{BtT`U-2Y>Ro2xk=I}3W&FZL|(
zsy<7fl2aQ-i&QmMUu<k}VWF`Z^fL*R`Z6b&IU{V0%iX`;lMycteh;q;G~vq_gs4Fl
zd_wm|(K3H6&S9+|7kroOAPhX7AB!VfOz~(8&<es3I6;G+Ea*hOk!ED+pN9xrDy0Cp
z$0Es|h619SEAysar9XFTZ+3p!!Y%pd-+V1!`DSD4=IZUC=1G60$JP1xN(FhF)Appe
zY&P59z)Ek1;J!QAFCbfZ_+#ccii)g!ZU5n{oxGKCFe>@%yW1w6G{+YLU7pl#a_MP)
z{iCp7{%G&EflU*30$m1^aZQ3dS8m}Gb+Qg>Z?t|z6lIIQw=NJ$Vc85-DXdvA5NKwD
zGnHFM>*FZf!Q<;pHEQlA2rSDDL_lPrgn5QZ68v!*peO^LH>o+4fb?F4^|2{EmgCJ;
z{P{}3t&2&%ycJ&yTTeo0coQc+s~#<s9|oGM7h9#>IoeM1s@Cv$H=jG(^{(2$H#?zF
zSlHXXu0yB@5iVu83Gf=9TLRa3ynDujcG9-|jERIA+LDeDM=F^6#G_FlK~!{TwuOci
zkabpiZ2u!yTg^tyToYqWObD<q9{o6X2=o9C6^g%$4>d0JG=KXxgyC7PhlDQJ2ku{-
zfLMMG?3yuFt<z>mvZo;gTxzR>=3-u!&MDuGeH!+kk7Y16G%U|WXz|2vm6n!<oMcJ(
z(@8o!>RZX2nw>Z4@pz`>_akZx16gNzJX~@mIau<mgA)|IbHzBb&#t@e#}d!>Y)|!C
zntbiAV<pS{l4s#1m$t*)627oyA{h-HaFOQ0OiWV1y~M%%7u&XGM(w6nIvk=^mRK6n
zu?kq}4kP0a{6lR?);XT?Lnc7ra<C-U$C7lwl-ER<aHw!5{w-AF_dL6osKN{`J;5TE
z*K@B;=SHkJUvKy1j4`PuFnZ#o38p8e6W?K-6+^+<xG*+u8jg_-0XYgPZsqTY?2V4*
z)yRJ$Sj18CoP9!H!h&7vAug?gwZ^&K;)C%D?-&PZj)HRoDK)kx*lg*oJ+uGlp^_es
z(yBcH7q_1NN2?2xq=H->3AF3IDxv@}I(PfdxheL7e*^9b=}A6lS4I?(Ss0bqJ&7_A
z^^Zu9^s|%UX+kPgDp7FhvdAV3g)$w;**@#^g?}&sTk%qJ^TCx}<B9GBIbt>)9UU!e
z7u>|$sl#@>b(7r<RSgj6C?D4Eu%He=J<A&rbK~r)PEL{BT)5D>l$NycFV7kGZqmb}
zi8aTg8k~PQ!Pyl)BKCi+F#LL5Kfi5SY=hp`#NkuN`3z_LXx2TuXvPmWQ0jGQl^^oP
z78W?aulq*~_rp=wArb8lLY|O0Ppo&0Q3s{+b8d8;xIazHy$pHt=77l@1Ff!p{QD|9
zMC1Tj5w-C%L9-dGsh1P)!A)(HZsm8f3G{B)L13;KMajQ4I3}cL+t#|Q$?B<N7J~{-
z$8|<tK}$j`X0993YhQ<J(;&Qd+K(UnZIsKJ^2vtutIJ)G6PaE7G`lWad3lNp0#zK^
zxGZ7z8H$riTV*Q_gR#L)K)!B+c1S_&>ziKdlaspEhxCFKvzt{VHrD%%4UZ`*9)uO4
zd9@cr@0&V)+A(VJSlN5_BhfggI+2t1rwE56@^eeZ&5iPDN`@~QmJaRaxvtFOv^?e3
zW<9BJqhgiHW!;p0M0s)XNP))Gc_GWTI@P4Rp+X?Fh*23Fc0lP;Z!l%nW_PKCL_8u9
zen&!g?L3hi;%kCc=>4`r%9|S%dC2q)-<z|o)ww$r!~xhR!hr1rs7f62V9c!t#$@n1
z-cj_ST>}H+2K4<tOkq>w0vLZGeV**$U;l^lOaf#rP`f&os6|y6c&xJwAotU<9+osk
zjg@Y76k&ew#8qK7nUi$219Y~2HeE<{;_^pv(y|@T3(bp=Z{hK)IZ(0MCEqnZZ{H6r
z&ZZ`VK7a`%1}Ng97cnWf^`CXXNJ^9Q$jvg=vqFV^dL*`tXLXu?$V8XiM<y75cA2hU
zjBN{$T(!KoIn3#eA=xvvoSQ=Gq&a3>PCQd<VC(uUGl455V*RHop$xXbL(xV?8=wR{
zak*^xNd<#zJIFrR{SiajhaR?HF`_&98S2UT5xmL>tZV*X`1f!uuQ0wku3!_>V}mf6
zC3g;zt`|CzNZV|$_B+)<kI$1cm6yy+VA4b+OsQvtta>f(tj(Mr-XjWoN|@Vw-~HP^
zD7zo2BQ2uyt&Zk*Dbknd#^9!cK2ZxY?@I7`BU23(<>hL|Vl3ezW;AZ`m**|`Z5{sY
z*HmgZzA{kihU04zX>JK)8Q~z~m7f2s^Js%fj_x@@+nnz2dY0)=Q40QOIelg#Fm<lZ
zSZ#c9t18~D_$OXfm7vQ$;DQpmuACKgJWj%z&+c6xcli(7&IS1TyaM<ZYjtqn@2zr+
z69PXwtJwfUGa9@-60luH(wq+Qn~2y_Zr^SkJJpZfi62}75q{~He85+H3rJl=e`h*6
zRB7cvU^e^Yo%Q{CH*Y9~Soht`iI3+Q=k@5UcR<>G(W`6hzUoysU*n0DCdnbpNwH9@
z<wlRtzonm!Bzbp{mItjJ6I2gKG`vm(RwCGv69o}N%cZVp-&O8-XYN#Q_H{_^LNa%n
zkNb@-|1m({6HOk55HP!ZJmRk6z|o&Jew`<sNyeBDP5kvg$mi9O?FkBx%K7=|V}&13
zSgo`44=Q@CW_z|>Szz3XN4EdR3lZWMHE0<q+84O~5VRcd>7VF7^!Tp^g(QtoYWyqY
zkeB};;R~JJ|Ip<BZ?cZ~C5~(}QeeAFn=uBJZ;D*W|Kp#bL?jTj6X5uh3(q(5xIxgp
zf4zOOv*_C3?p_Qe?m9ng-2K<z%6W<KZ(B>}zkV{tmV*BTJ*gpclPT+dsfW=UjxRz-
zEnTa100Ubt6ciMP*tjSykp3ryg@p)5YOC&pJ85FfkhsS1_UI3<B3l5ytHzw<U!()s
z?vq9=1Dn_KI*Omt!Lg`2F{Fv(_Xaq9IQEzWf~8-~m!t%)N3Sz{?mXaOsE%o=4k(DO
z(mz*y`1_PbkY*8u7-5~$jpWeMfX4@pv=ilV$_4&_^`{cdfcFyc_mbLR?{eJm$|(iN
i;A$3e=p!Lga@xjehRJ2E5_R(!Kwd`WeTB41(EkAu9}yM+

literal 0
HcmV?d00001

diff --git a/doc/assistant/iaitem.png b/doc/assistant/iaitem.png
new file mode 100644
index 0000000000000000000000000000000000000000..2fcc1b4c8d120a4cfa081a8641de73977e6ca6dc
GIT binary patch
literal 34868
zcmce-Wmufc+9lk0f_s7o2n2U`cXxLQ?(Xgq+}+*Xf;$QB65QQwn(QO{<b3ZpGk@ly
zX|67yo~pZS-D|B1k&zOHgT{mg003~JA_8&%0O&6O0OaR8P+&<`koXPo2c(|3umIro
z?JKLjFcw(y-daS}4gi2bdHV(dq@;ZW7DCyJN(w@)fMbGDgLfL=2m=700HOlC3eJm1
z?Ox{UyUDwck`_2$eu~Q5vf)4a@$JgRn!#h%b_LU`(6*!L`gfNvu*ct2^ih3YG5M?^
zl2K05MF1_@6@L|EfEq_7fq`{^@N?mt|NHdx$qdSLK8BiKtM3_kia~@9boL5<<&ck$
z#+dLko@eWK#vMLFk%n@QvvTBls?=m6z;2%Hd1T(+Uw7<oxWNzY;&OY!`hI%n`zd&H
zV0RD#oEH(CS0<Sc_zrv-LchHue#x8)pvL8NwSRqiPEW_Vfcaf2tPqyQ_53T0I)lxj
z<VkvB8!vlhVWHXS6qhyZcZIpTmzl5bF8MW1Q@gbjT!eT?Z<U@4G<m&x-Ve3Y1)N;}
ze$06uVmbdFlG^WPM3O2L{Kvz=<4ONN8}-jW`?IlsmjC155&w7P|LE)g^tk`2{LgCt
z8M8mj|7^w|kNa2i{wV*mcmJo&h$r0w{T<ID34Gw-zVpqZ3wRrpcVzOvKYoG_nUaoY
z<YRH_N=0KVn$K{amHQPe`~~<+1DBKY&4Gp7<KtufLYyVgu-!;jxF(^6{-cWkn1!BX
zcBeRorl)=^+hgfvH06>Jn<gQ$>AaF)@+`ez1V$(Uf4t0K;0R)KE08G;CF{4R{>sEg
zsNA7aD<F<|9*$XtfS-@<1WjO^?`lRtZ5y%JRMeCS7>lodDc+RvC!Kq%NjKNlkAKt$
zd1K%U!Q1=`(AOw<rw&tkesxm1r#6|f=-+a5%oyhTe%--aEr;WqIZekr)kS3H=64Jq
zR2A6uu6+<KzASWe9EqZ<7iSoXWJ;8<1}IecFAjb2r&RtPVXJWGPG_(bki_2PSQRqF
zOW+OPlTi;z@s*@v$q1=Rv?5VeuyxiMc>DxD3B*wk`<OGZGP3a7G|9K_DBEU9_#Sf;
z5IiVLVf_v$e1OPcX1m_L8uocKJD9&8^O&QtZffsE)kG`$TA(V_p@>&A;yvU`#qx{)
z{WwlP%`y`_PpLesv9L06kl!H&d{y$H<T$JKqODH@Qjl41`XZz^dE=>d+F$^4H3xc2
zb#(@S?nkkX*&OqHA)vl{<FivBnM3C?Q-^FDT&x>ZCUm8n2KnLs9n<u6Rmy?nbFNIP
zm;swm%NnN57YK>vmRu2Olj@ih1q>V6>xwofC_n=!xup{cbb^m8nAsew!=b>wp}GpS
zk|(+bzbJfD;B!cXVmiFv+$}@fq7y6b#McQ%cH{7igiv#Mw0CR90?_GJj5EpUwTQn)
zV&$`2*AL<f;D9STo)ju@4R7>>C!EFnIU7P}2~UNTLSF9Br(?hVD8PcylZlQ_`(d?N
z&aeCVedI`cI8lRQPb~8Z6Mz;_ntc^KY|(5_M1D55Uq71B)i~R5+meWK-3rN}T8!yk
zZeg`{)n5RfSbQ5Avtdv)?*X=ZadW)likK5?6&Ymvh-Un)0}DEzT0j`GlG=9)eb`{?
zGTQ>Di*!<6sjP{3Mp#3k-8_l<wwaj@Z~$US+1yUkPMd1OyeI?{FcBrWI!~go8mrhr
z19dPu8xb)R!9qoplQs+RCdz5t!~n3>*5~A3VCg)Di+sCOriY)fxA!1Vng*ja_}%s1
zkj*5|Ppb2wWqtI3t1-$5j`0Q+5cALU#beeTW4_eUZkHA~n9VknmTd|Id3s>7lNjLl
zH`!Qr4=cvJ=zeA{J`0$F`VO!wP3X)w!(p}%ibZCS<Mm_Xnn@`m8TOBJsPK(=76Vq}
zTT9_<X+s^bqZ7uJ!4Hwe-%{slG%deW<6gxNhELbCpjRTSB+2I#wyDTUnuawMx%xn?
z2|)r<9)zhSw4ufg4^mb}u8G=xH4MKjso6T|5}1)U`^_x-jF~E(@W|d^d_&&tL<<+R
zUtui#YeXLj_HK8n5SY|oya3-*U))n?u2pWj77QDTHug-ZkmRa;P$NCfN-_CwmZdyj
zY(nbyD!L*Qlo+u!DKBi(YW=1f)8v_3sP|{7F=lJO#A4+491E-4eaAtd&ve^I*j^or
zng@sJCOoESjHuRd4LIyHXf*j*qLlaV9=yz?=|8H6`w4j-?2KNOhltbr<!c=jA8iRS
zDj27N_$%4Mzb`KX{gGy2Qa0(ceMC<{G(G_sf6fPXpf_aQdG!hjw7D_RfijTAzezP}
zzlF_!&L<wOl|J6%qodocYvtSpARI1VdQi#yQ$R5<T$Ze+E8&-BHzFE_GXQKnIHn52
zuNG{LiMvUi8H7e@i;*GiAq`D=>>CBOC?fI7V%PEupSZ9U<6gm;u+zY1-Z2mw(Ky}$
zAwexullqmmR?LN9zkC3CM=JP_8g+Uc|9r-lisk$M-|Yh~8O9n6_<p;@jM4d%3`b9L
zJ$h_&h9wwjTOGiFA-4^oP#>h>F*y_PQ?4&h=E%0@*a|TygB)Je%C18};E9t>LzQ-m
zxnIz(DMnGwyk98G1WrO?8D&ALWuDL2wMd{LWl^JQIFzBuSj8qhn+0%tFOn$!#`CFj
z!pl+LiqWV`6TtioVtkXMSjcCD<sBV-uEuXlu0~d*=Vw|hmt}QJ&a-H=8;;4e`t#fX
zN4;>;xIrJ#|3Ub>83<$p{Mq_JW|>Mp(g&P&twhlQkaxwDS}Op2P<Vj$RkmIq!-Y(`
z#X<*`8ccwk1R%@I^rvmmb{Bu>JK)I3_nf;i3C_b-5P@V#(R*I1-RSn5r_ygSS7u9r
z=@=4*OcMjzX`Ph0+V=QNS?l)5zA04m*6+dgfwo)T-`p2MxE_MJTic!@6rahuGSqvb
z6&nKjcN&(l&byj0$R7p`vh)qE$9%T(oVYLI!^X_y)O!VKlkA)fa`2^1pAWVhzEz(_
zYT!7R8rhYVD*>_x7ftV|pfh4vd7y9|1%Ahgm7@E5>H^%U9lH9BXwOrp9Xgix(VPjO
zs=*1w0Z`y~j%P11F(9_ascbGo$>bKo)9&szqiS}ORXM<Zv{J#H*h(DX5Q!H+u4rtR
zi?H&-JHX(5vZ_?11_)mce$KKeu`+dldso0%>^R`rUrf;;5xYo071}-mnFc|#uX>2p
z(hgE)bTHYlNLka6<lQpwc%y5q7}i`3EgmKO*1`<T$Q4OEFB!l%NYz4FzM}6~3sN}X
zEC{?7hbh)E-|OV0n_#kAv)$!uFB>OKNFBhNw%<mh50c~=GwQ<XnuJZB;0NvGuM?Bl
z>imKIB-}ZC+z_)Xi*ZZ8&{RxWLNxW6gLqiw{YtbJr*N(2jSGB?m5R;AdPo2y?xtNX
zRV5{kYI7@&Fb;x;-4bvm_{1t^b@QP0CH#){482LS=V|yreN1F|0X;0HzI@_L^(}tB
z-AqfhPf$TIdowzS^{lC^vi|-zfxN{!AWC8Rj@_Dx8~(0&f<5VOG6)<45eeW;e#avm
z#|yB>uH*6dq0PGM$)tnpZjI^+?LcLZ1r-+zsO!S8=NKqtT4JkNGgtT89jBDFYw*qk
zphfksBrd^{!NY|HlCL@xsVyz<t=sPGu6)!-{Kx{&R<TFOkONIJEiY6SM?52>(a%l#
zsUN`8gXW>=DYz|YXi4`O1F+}(je0e)5w#}wl$&7Y?Ud_%pYv1*6?IGf8IL|8=uxj)
zMUJPlR@KZ@HCa2Y1qUjN-D$&h;e*3(3|l=xx6QyR$XeR}GE=Ynsg|q0q~~B|*~CNG
zi<&j)4UfTNFG?1Jf_zk$vRHnHUmY3l?P`&p-Q2onV3l=R^&3V%^D%qCdxIky1HdMD
z2YfQ1ewXr-$?p|N&wK@;6xIe6dwW{Y`2U38{~L=+Cj|L!bslNo65cn}`UQbj+36JE
zWDM~&U3s&>-r|-mMX{Kom9tFC-b`tUVl})+XQc|M#=9{YM7qa^z=zGt=vE9)_<^Ea
z;BLGh+wSFcFS{WQSi2vIGELN|J{>m>(heGgJO4h>*m;?V=W%v9&6}Lyu&8U@Y|*y0
zzThi}px73te7n55&;24BTbDz;o&Tg=PAMi-xlCNmvBu2kZnF^_dkoNUstUx8$D0M~
z0K&vWpMXLuG-TzMXyqjS#8>-7QonTVp;wp>o#0iOHMM$cAzhUSOKkV}t1mRqBh((A
zCz&UBaVDyTIFML|P!p(DaINr)FGBg3$Kvz@+@^B5(*<pDuch^ZLwjgTum~>T17!~T
zi%4IVUNqkxn~eA5BlDyY#Et0spp+f)rMert;i<4qg4N6DRQrBpg);=oIjMi#FD4!O
zXnA1#d6-$!agu<~@#K+v^*etyPgzoz#@fUg4JD~qN$Vh@8%NXY`p!VqtA5x+yEHC$
z(`)ipFd+K7l$wA@GUhHmpmRi&<htt=m7Nj<9V85(9-ouAXpy{vs3-WC9Khbg_i<rO
z&`9<jQq|aj&_t+SDuhS!;5dEQmJq3;gxFw)r_Q0yq4&HdeFJW2AHF|~Yse7w47iSL
z)w^ht8?evX35{!g8VV^!nsus%(_5ScG~mFxR2c<0%!QgJ_hueCLs?FmrFy}Onfkf|
z&Roeji?kb$1bK<SJ8m17kL>q^M&)a2nw#4!myR9KnbHfCw2IIdvkdn)a;z7R%_Obc
z-&FK}6enGPEb?TG&J3xq{3y3u>yuEGABa{UU?iJ2Y>$}EJCGE6OIersbdZZz&h-?{
zd3#WdGtlWGJ9P&Q;BY^Cc^qowW`kIN)ONLhX+tlZ5E0$e5F4*MJK@Bq{))-yb<UjG
zkGH`tp6Ras>h3jiDF^D75F=lC$^Fn8q#l*=c*tG(0gWhMdLOZ`?RBG2`&I7wK9TG8
zntG=5b)y|-%^BaV!$4qJ`gKOy>$ubDLD6zIi1KMf`z0q_y#qK?DWA1pN3`265A#pc
z`;#?;INay&$17hqZ#!=2$k-)=AABvnK4*jIC=6J@V_C)Br3>P>(6OS2nts%o`9g`3
zOZt&`slSq9+*S?DzkH+N8##0PI+lv5U6a21)s6)^uKHC!vPAywrelzzMN6LbRdpC)
z<WCr`i4~O+se!&$9Ha5Aw6?vL8U~0Co5su8`BbXi$yN?>Mc6i3h2X^_aDXoT5hj9=
zOV+sQJX4gEj~U6dsqLq#^!{zB&f-1;JaY<W4)V@D$z3O5Y^lQ><^<$}(UvBQ?)UYq
zt!wOdyHXoBRxgHnhLgJyUjo=_nT)XT0%kR8WYf%&L&5urdu-Apr5)MJRbNR$Qo2|~
zqilxx*4x&vmnGjh&^Jotm;yuuE6|;r1TAn!$+&GUBTMaU^-R#+`8}^T#)p39t8<iG
zb@r0T*^IVUOoP+jh7u2LOL-B;w!YHYjZnk`h%SPtBd>1N+gB;845T}eFm^OWe2Cm!
z;outHlPV{EZ2jPrJzR#~z9JKgFSjC|Dms=cc3GMxLXu@xlT!DCQMD)AP`ovp@0uuf
z3Axl~RAN;AIuzf*)2Zg`U3j~&c7+!lxkUD;<$&tk{4x3I%D2gEcSzY}+peo8U-s8y
z<x%SO<N2NngcqXuJ817l?z@Or80{x5@#o8~s2BX_p*4@?moaK_QRk=)-eN@e(}}uM
zjn`A)F5|L|Y5=}!;C#p3bh+lS&G7}errm}RiP|p19@ifADZNiIxL(KCzEHUnI&~QI
zmS#`8X+J!3sXre(7wlSbzZ}A|Hv0P{PORrrx7)KnEWxb(*gDAGv*Lc36sOMozI3YW
zxR}H~?l7trp=Nysm9tUpW7gO^g4(%+Gkw*_N(r#M>lRHM;G+F7#VkClG|I&P8C%1T
z3>iK}&5f}1ds2t!nB9j$WpyK~dHVyI&$K(LZAQM`Kb5BteIs^?dBLJ|zS{N9a665V
zCLNP^2#TKyoCv9`3k^??*`2itprU-xa|C_oygb4dG^Pt$wHNiys#zT>%yH48Ha8n4
z`z9X)?u&_Y2)-FclhSp9i7_XX7fp<{i)&@l$gLZUc8d~R!oDn6kl?9U_wiT*wbj0z
z8(;s=Nb-WWrkszDl15-o@DA%k^LO#V73_Z}){=t*#Jb_GV%l7fCPUQ@Uvk6{yRlgJ
zm``X5^nAx!B4(c;TrU}amCF_BqdjdwMiE#cPx%bowy`X%woW@mh<HMt>KWRqcM=ZA
zXGHYeOT?#`EZZ%$B0l$PYR*~2R8Y}6@;kN+8Prd=mt(?yJJ6bx7=A_DRc7_k8JuN=
z>oTf^Xy;G3;l011Yo@HnG$(07l0SZ%Nvp@I^ip+_AL+eEPyoI}U^7+STZRP~#4DFr
z$(nN^`!Za9MG~w!o_AvtsaoLPbFX`&c<#~cF4xLO+^-9{%F^!vDOzsJ_nT11Yh_Y{
zhlO^xNo3GRkFkkbUd8AhVu2(rn|7zQw_Nutqlr#uGGAZmgkBF%ahD&D?i000@N7;p
z>0h^>U@9|s-Sk(Ww5NtkzxACDXeT}H&jwg=fJ%WxRlGcPY<gMA?A4v97Jd^qY%Gvu
zn%#-FFQ&#$Rik4r0pYP?j<Anh@<BHf|7!TtoS&r0b=DLC0<2(m^~bPUSUpTvL&;DL
zoleyP#m<gHb)SOK)v9MHFC2haT|X5I(9&w2(cvQQ1f7P7=>B4TTE;I%ONtLbS2~dz
zdmo|k(ffOU|09!Hn6e-t6u?Mp+!{&UwM>W-uvgv>V%63tmvLHuN{iqiAzFW1-fwJ$
ziRG+9vFLF5RZ%wfBB>j3-ia|zE_c2M&IQ4E|Dft#h$`h6-Wx1wqH&V(+7j+15i>t0
z4H+emL^|f^hZu5}fTwh0vro`MPCHG&xvxHkaw3+xjm*z7^n4?Jf!0KZ*o)4XCe*d_
zkcz%ZDSl+Wnm&Lu$C#X~l%_6!e&7txd&P3#Nd#7U-kb_anVG&q36?$i2{^3aN}G1f
zS89xauda*CvzCK<#PJFW1=t@8KG;o6wP{$>y}V0&-H~5!J{s|Iw=aOimm#j&&zFa)
zn0Tyq>)Ky+y1*M{ebzdfx><ST3Lx|ZZ*wJP{&iT0rfR<tR!G%(*B#W^a(gh>QH9od
zJMuxh>8wv4I-bG&K4GP!K2J%<L1Nbb7#4G;`B$6ln1wMQtG>^DfgS=Mb5%qlydlbA
zls(|9Ga(nfDdc)m2i;LbQIPLg+r&v#x3lQ|Uf@dgh22=*_A=y>>ks|92+IHu6Th*d
z?L5?2<QR+7lS?~nC~uJSD^>+7XI3E#%V<c(M5XB6`<sZG<0+n=6Ug9irBtSJxbm2w
zl+=}haY1$;nuS)&X{`i7;R<d9J||5ljYYV_y{t)N!$=m1HFblNd|T@RYvoo`bJjT4
zD8(<0&ss(l)kXt`->d!{4k{63Wh?bQie<n1yJ1*6U$R_}Y1UwuDV^kjJLZoQDRjSt
zC20-lFIj5o^25`Eb8RWWT{$U@ZN}+5ez)12!i)JX7$>7^7lAj^$@6^SRsV6=tTPd2
z;C_wkBIu?087qg-^W^(8)I{eU#~J$(N7w#`_@YgklAV_q?bo%+4(n^<C69h;a%EfR
z!4cQ?a!I&r4i;Uz+){1Za5gk?3)=%B07ZQWo1&wVT}y%Yz*r_D#?1Oe3TQ?ni>AC|
z!&2SPg!lU4$?oJK*&7wjw^TD+t~YS5jVp{lY}$(#j$3{*ddLgWvK}xT&k3_~Jyt~f
zD7sp!B)caB1CM$@!XlX^p}~jt7-O)@;{a&3(+Kzm_;Ho^wO-Bw3UCb~MzTrE)0T~6
zJIqvfn9Jjveaz?1C>Gq&j7ED<1)|Ot^Gc@Ds9r>=kk`_1E1IT7TDO&~rFO`HfUHBw
zFpsJnx|vGIU-Z>C60vo48Sg`mT=0=rfZ;3>Hbq%rQvbH7T&q7Me?eKdQ|Ym>?e(zt
zlq)^K{csh(*ZIWJq?yW$`?RCK+}Y^mGr4jbNYb`>c{yba+3C*qnq0s;R-Bp1b-A7~
zm{{iiT>9k3{rK+o)WU+;&9h9Q)N9RohkK>;vGf+@bzf`c7HfjUX;DaxG5d1qu8N3}
z`VQ0^GQ@ii(Rgg-kQYIYT!b>{L%~E!YwfPO`Ru(;+0Z0t*3cv!UfYsh{f=b>TvI^2
zD51KIsR!-e4ZSOR7;pL{V{2f69$Ts5EoDHQo?Ke}{7kkey*g8^p`^|ywq_D7Z1ek1
zWh9As8fn60-qXV^Yx&HoPIKtbMmosd(8w=Y#=JStb*s}<`Q;tWoNY7^x<u7<Obd-N
z<!b_*O8oBxW{QHxmJucP6Ez7NH`!8~tC?O;sUx9y>faLw)RhW`mmB^N(<XG32^@UX
zrlK;$tPx=7$8dvdOBTM#T<ID(jF9*~)7~<}<4TO%l;1*ZMnMxfO^580<-~h&EX+tA
zzM~=Tj88swdI^a->N`vy>?n_FTQHftJW_1czWn&IpXl{Oip%+O7Le%a{6eH^@{6zI
zxx7-v>*0K4@G0+*$i&C^CRcg`@t*7Sne5U--^6G6cA(_e^SbJ}{)1RxlIgwPt~9sH
z<BFTQ#>%bwbbK9KY$wW9yH(L^&qPD#?HBFAH8i<jbw&e6U0XS!_fu+ik1|duc>9Mi
zqboHa_hUWF--&`OCKW3$Aimp(^3VCx-wqm^)!sMkYM9l&_s(CiU$U#HH@r3ZQBlk_
z;X95qzvG~^YcHAmVZRIHSo4^<K<N=j^S)D*l$fY@qbj16p`-)wG0ddAou3J*FVN^Q
zu<bfn(`}A`vNQOac=y5^fsd}j3@3eXsE(~La2clMo=2#hd+Aib;FiikQ@(DfdTBMm
zO8evnH^{>_{MHFFwr%{tUI~j)HfjbDRF*N1BaM3<q_o{>vG&KL)kLBQFgJN%$%vJa
zmQqZ<oFPt{u8u1ej40QY`6*pFZ4iu{`}vs~Wo;z=C0Si?>PuV8%&KBaGLxIKGoz^q
z^I%X-$qbJzu^6U0>r~$OEejP~)T2X(OyJyJOWM2E+s^JQ7V2i9rx#{FjQWnDjb78B
zHuyeKhvnZQNOP*n($aur^DSNim$jO0!P)kgt_i0z#JirUuhH?ugr94`00mPqpoR}*
z(}mW-6nH0D8}|F{c~D)m@LHUdzx*lJ6WN_1oR94x7@;S=_;|SoS7!PY@F)ltf&|mO
zgJr{2`vlSZQ3AW0@8o^i6NuyMFo<i#-l~OeYPUWh750t3h|r+SO&kda*C6beKF%i(
zxDY^#MIr#uLPGAbe9d3!cFgRFrsJ5vvTC#09Zx6mlOeAC0fq#L0tG+<A;#T47F@{y
z{DLJzy_a#B1}+H;;F5^GuofK`fcWTK6vn(3|Jb?65?UhbtAJJfS9ps`^TW$cWfIgn
ze{6Kv?Y6|_4;%6=OecioPT$+USBE{QVeRt<=Lb_}jT=@5D^4caBqt&doW4IY*Z=`b
zOg(zk(Cx}mPvaV5LCZpGSY&%RS$2`u3gWvTfQ}b)h#5xpEds@-=v4{|R8A49yiKVe
z5UV#&=EEh-K=quPnQvAyF7;9JD~u`i=s9M}&ThsL5q<)3x>}wb%||g6cS*KQA*MOE
zKl2;sL2fH>s(56n5ZfKp??n+f{b;`NmC@PsCz}wI2JebH4H#9nm0e^5m*nhEOX%}B
zMBQ}&Sde}b=7@P}?7%x;TenvOtIr@m>;xNSq_OR%els$`DDnmFk!imb(B5-@U~Av_
zmj9N~GS~z<rCTNwB~DXufCPXPCOZNt=$le$13H3=&gn~)xYREw<@kUgJLHzR{4&IS
zOX2b4MP;GwajPBMd8fSY1f}rgenVk&RcpfdTRo9ZXbjX8{$a>}WbimSsvF__>bYAk
z?RhnvsP)>|;^lQ-dg`@V>h-WTAJlm_=HqNmaCT@+lbtD9`u?qftZFK#eBkDGx7)5H
z=s}39?0(=X;1r;!Pjrl7s8^Jy1m5L-<zRg0I;yfUSolW%L}=ub&F;O^6)~i;LsqXx
zjmBE?P_I{`x7vJ<VRu7#GmIEsUR%o4N0zX8c1vIgQ}^wlZ%l`WPN9MMQC@W{<h*6i
z<4Y6}#&(VSiFp`q9~GYi5T+m|<E|mRVI7CrLo=2a;$^ZndVc9_YloT=>Am&S#+Nlx
zJ0Vl$Ka*hwR>XO!P20k?X}uZ*CTLmhAIDLj835r2O=G&75$%9}sz{c!4{aH(@3W=K
zXV4vesxTZQpmI56j2X>Sg$uhF0X$^LA5&om95A``Pk)9T#J(E-wC#gVjVF2kpE>$^
zM82We)5hrB1nSG)y4Tax!;{T~ob7?bi?G+N_2ExDujk!s=ezai+gK|vd+4s)&a1sA
z7fPv2kTcPX%}(eQ7%#^Mkh2Gv<WsN9{KU?uzRtT;>CLFK^nB@#a<7igZI|MXfZ$<}
zAI))TCL1fI2;2q}?XIQ+=T=%jK4+K|{L>4-V2XOv_k5-Od^PvtR;a!0=sDj#lJ0)D
zaD2<{x|=HxSoE?ge10N#J{SB=t$AK}oqG6~z2p}u<tw28XBrT$vVcvMQr0q?vpJB&
ze7vO4qW{jsj@g1}s-5!F8bGrXX@^s*l#7o2<nz_pe0{N83s7oOCF5t}S``wM!mpd?
zJ<wieH;+vW2zv=WOK5elhU{uvsx?acno45?Nc;i-AGuzLRw|1|CVIAXl9^iDsRJ}^
zz<klfeeBf;+46ciIxp2`QFJaid+>_g*mzwZ_qvV0#0IoIf46$lzWa5nc903>d4;eq
z{c^H-W95m#BmH&v-pV~+QyFUg7=hc3`;Ob|VpscVHPd9R`DG1?z4Kz2wE1`R&TxDD
zw5@kLpF{5<+Hl<FufKPKV`W#J&d40JQ$KrVmcKZ1OkFnOy*fbUNxAajbza7_RBq?*
z`ZRZbh{=w6?0hEhjwwvMq!z3vt4;wf;VioC^#vtHRV7GRrqsUWHcLmn+kt}1&d^ED
zLk3&YDhKam^Rltlxw%z+M)ap?g^rQ#;gw?6>~An&H1qS$YeI*g0Kbz4I5k|r6(=Pa
zzLR1onp{raA9+`wL59oKyFwzX_Uq>%@ygCP_KpYgo6OgvpQVN10Le<ulc#gP8!OPR
z_0E|#Pd2~w$F9xGzyYr_dVupY10aoCKHCaE$F}C_EH#t4{T-n4^=C5o9gl!?afjV&
z+CBBIw(~XYBGw_-U5e7pXZ4o5UuM*xU3i|G0baM`!q4#+c^ak2Z#x1|>W9Z2xQf@c
z65vEN-|=t^LhGNz%VYX?3PLo&yG0gx0Zj<zl$p870)P!JwChw!g{<RfTuNLj)FUEf
zDzO8_npt)f${X9&E_&S4D%g<F{NB6<!ao1}y{sVdrUBwtl=Zz87evO$aWBWPW<)C2
z%UvZ`)9uT%d?tr0)$1H`-UB)T;lPz%MYOAGw@Psb9!O=z(6z^N-SW^KVcU&d#ikiG
z=j}INj^ZLT;QqjCIQ(6IN=ThJoYv@~{BvMn>&_~9Ib>i^TiM*w;<U_!9|{w5%gw5@
zI69_7%FSUecBaSac-IBO>MT9}H%{u$Igbiu&H{f&{VuU{oj3RO2wqEPeY=+vbXFEG
zJI^GKFHRjP9;#Q)eZ}$~AGBREMpEutzY8}*AFn-Mp*)={FLpZapuy`Pyd1K>lI4U8
ztnr}^edB34-Njw@I(rJ60PE}-2TSvmz1S+2M>wh7)pp12@^gbNgtl6G%ha8%Gr7zq
zfQA=y8*J`<JBKdHG6~FuQ2E0!-bOdIz6N(hC4hOJA_`k)1cJKUr7tz$YxKKd(ZxgC
zSv}<-;xY4u(F8^xpS>-;hJcD8Oqg)O`f!0ydzwX}v>`};0B*qs<Cm@Nka@drozKS0
zkCZ2C;+8LFyI$gz9>-xhxv8Bu0g12sxtCE~oUeOR$~mtWmpUgO%6pEcpH4k4Jfxbe
zPnk2HdcJg-Jl!-lo31nCZN6|OcLa!x6o)IUReHsHof_k9ytJ2(8B9dk`GsbfKP--H
zAaM6TyEVP;KfazF7E~TveoHHPJj;x6c1F1Md>mgRyGJ_Z{5=yFC0W5+3LZFM*qn4y
z=Ty_D7VO6OYd!c^U3)9q%}g9e;U%a_lDNwm8xb6s&%bqabS+b2Sy#wN=za+5VLF*C
zdH~g-D5$@IU#PKg#ZC+ycxKZk=`pj{l=2tMlw|#qn=~Dqh}|Hn+&=sPe1Hf}6Gh6-
z#cc{B+~ZbU(~G?AV$+R!^PHNsV*h$A^IrS%);rX4Ov2-Ed-Ybj^J!E1eD6Gny6vjx
zvN=ep<M|=6?9_^x<6$c{G2`{6(erhw@Z{C1k?Z;O<q2l(WmdV2`}xk$z;p6CMq!OF
zZ!4}y7C4Jf6-GX=dp!&-ovtqZI_Ox-8OI=Sw7s~dehRvkZofdd#r@U1MP8DB*_`U+
z^+I|4dhWF3byq8mXR9H9Nq(2vnIJ=WTl2#-W%bSRlKy7QO5<EyUFG63wV*SnFJfUp
zU+xQ`t6KS@m<tQ)7a4>u0zwOk5>!=n3vTA}0VJ4~hG!sqomBm^HwzfTM-~C_q+wi3
zQdII1U~p9XSa>FU5}9sL)_2*R-|b0l&iG!Qa#MI<GOS%7Natp+yBk1da&_Zn@Pb8y
zdp5_q?GXOPwzeL!qEaE4+iF9HRS-|MP?dm6w7A}!FSYG}HpiAdo7l|L^;}`+ZB#Ax
z2n5Hz;jfBc|2pJliWR=({=<7TjQX(8`x{36KXi8~;`<Z58osvR4GpBD`qM<S(M(Bs
z4-HF<VA+DBD<+yi;ne73`Nq<Ht;bm)R@o}DJIeFl2X7|88z79N4g-|^F#KhTC@r6C
z+dS2ITWQgDM&u0?q3Xpe<`V@Gyr_oYs&UUWEwQu_D6oHvOx0*mX$T(%E?+;W+J9w>
z3n!62#%Fiuhabg%OtODeg^J``>b-DZn?CCc=tjy6ZWl%>IG{i7ZOZu+DU7`~wDDth
z*!^XDcDQ@XIv6?(C^VU9rwqL=k$Aq>(Z`D+zwt1ecbK0YLfAm?|Fz5Z<n!aVq=uw!
zQzg*+@bnshj*|gTL^v#OHyGI!?Wec-z8p+A>-a2M*m_hgu>vi!$p>Xfx6JBGA6kG7
z$FDogR=4Ght`kqw;p6uoTiuGPoQFqH>480c+CEwGm3-5gepP_Zv(2-8QgBs9LPF}E
z<*#P(xAsw?^=a+^YDc27aw~#?B#3E?8WHcMj89F&s}&S%1pp%6f&%_=#kxWtbqG?U
z-LT@J(-Lsh#$`#X-l^p6tp)`zBJ0NwQU}hZT)v*FDJWLWpSUQwQ?R-Y1>3qP;2WgU
zIpVb8_ni{-(S5GQDkv{eSg}J51B4uWNuO`JU`@D{hJdS$$pt`9N>sb@IdjJ2PFJcU
zQejp%DCV~`%S3p^NfTitL(`Y{mZIsY9l0QJ_O;2{P6)nBbo?MnuL>NZbDdx0tt4oA
z^d<V3W(?~Ph;YuEn5APy710QCxGcV^?sTjkzZj$hD;_wU^o!YWKAbw%6^;1;KA8t<
zZhj|0m{x^b+WARp4JU{E21|vgQQy&)j*SobbU9)svOgD~$9h!BimlK0Aq8Ff&e<{J
zPme9rg@ndT7TO2v5oCK;44F>y%^AQ2B~Ts*a$3L$3H$@PvT-dO*Io2$VKi!3Vr4eD
z49u{yRx`kO&f#~@TJLV{O;X~<rziY@oE3J8_J+4qNJ@0Q6*KE3!hM-TizqiHZ10Jn
zB}UmUUyUhKn(c&js{;Q=>81FmxKJD~l|hcGY}a>8IXeDfdV&9ty3}vlkQG5bD-nCF
zI?EN&o9Q>4%Nm%mK*UO!YTRRwJPJ$oXwoyf7cAM#GCDpEyE%mpRAjCGCH;J$u^UOl
zlWq2|5znY;mdW=*l_GL^8=fDfH@NN7$P@?nbew(dvcGnpMmA1?Ab(cSih^i5*}-PX
zAH}p586mOP=JmY1i6s7qTk#U-GVR>t#q5*VM0|ee{iki8o{T;q491E5E_6Aa<s(c}
z$N1|YnI7T4)eIu$2%sEt<8L0>^sqZBwRH4#kFUtXM5u>XXx$W(Vp=B!*Zdcepr`{i
zMvgxZjlp3Gq)zRE?<&6dqmI^6H<E{?^dQTkO&@CL=YEdWWLDNja{xzF-ViSQGR=}*
z2p0V6Jkx>;E{L*WA)G{I!{}<&{&cp8-e|4!m_IW4(|^I|=0&*|ibQQ+pQT6cPTf)(
z6*CiO{V~e9^wMv=cM6FG7R#<HZJ46rtt}NxpBRCQgKp4Yf`NRvaSCBLnooe<U=(MU
z&8S?6lI0HU=h=K$y?Q&eBE-5Hqe_7=95#A8`TNGk+fdbwyjV<St^sJLoqUEgC%4&f
z6bqDohMqh(PeOV0bg_ea>M`@Wc6>YPtP(}RdyS%5Zs@|8Hi>}bgj-WcYZp+Ss$~h%
ziNrn9?FhJ#N3lN?pc)gUpFKo2%U<r}RATv9WRTasFWoa8-|{-jXR<1i5U`+6%5eHA
z3h1`?_Kq8k=)W77eFdtJRAtNQDJYoDGyuPdh+B&~crw(<Bs9G(+c&YK?p7s2jTN}L
zhzF8%cpz$q<);UJ_BRLv$#6~qN&|~BTsc;ZTy9hIT|Ig~D^i8GS7P!@dv>szzc#P~
z;B~mx#O9`3q0<}6O>4?vKbkXzHM^`FQ8>l@0n_n+krY=CZ<Dv+m9eOBuIxbK8in0-
zqxQo@=9kGwx(^D}{yKvtRa@_+%X6DG*^*m$6d=YjyHpZcM{aTAFa9lYT$5$k(`^D5
zU*7`srz*_M*6cZ;{4zDwQSF$Ur!07V(HNg!<ftgi@}cB9s=N3zwY+Wt#GCE_r^bbK
znBWsF!Z+yL@ijl@CJ@!l#E22zd9!_(g92?JWmCPU=Eu|;`-+#_*EV%sE`==`BieXU
z;UM00w@mdU&n1ke$0zIo5FH*4kBT>Kf`&N+K_S!H8smp#NAjz^9~HJn!#vzJVSx{1
z26@|{V%^~KU@PNJxk%Rc>5O3TSj^hyZ^}h^`VYfZ%sIHwOqX1(J<yx^w!(}j@GC_-
z4KS<I=p~elN`m)d(X@F!P=Jaf=hs~2cdGf|>?-`wNMndS304co>f)vlN&_WnFo5vZ
zY;y&>ebX2XBaLlY#2Fg6qM2rt0-+8v;}dRdx#RfJ0MqAOYcfS5c`*^7CO{m;J0ePy
z6t^pW6?Y-j$6!VxLLY$3)#Z>IXqa99EfZ2Lti2k~0zn^LKKUZAc&bhtZ~M-iXrikD
zUiy>My9aQ;Qk>d3xR#Y6ybrz=%#=60)kumI^+Uy2AV8jjo=moIW!0f)X_tZN9(`x&
zcxpJl&Lo!-rT-)Sy%I8ikEY#e{MdX8r-zCuiUXOAuxPlV>Wi+B7kBPR&{0T1wMZb)
z5u#ezSYMo-0rkb)(*9bx(IM_P+n-I-3tgv3XIU=$n}F|K3dIhk2MQwAR0{ie0rJIc
z$uWEf$<c!uACP~Va!!z5LVhx+EEGh@_>hMoZh_XQOmNv%u=JfmjL~IX#`t__oAe%i
zu@=3Rjlsld#HgX{J*>c&4`v!`jlcxqhFYfOaTPHjmi~>Dc7LIlbOghzWTvY&<Xc<D
z)k^ZMic!HxJ(7QLz+tlEr^(lLj9895G~W^0mTF~NM^_?_Fz+kA?#n{4iEDP_+~YNc
zDBeEnzEZVwQiT5&?IrMCj?Hx;_f9e3Xs||#n4f8~<bC>De-LG{%l8ie1`+U*q9OF%
zZ_uCWYfds}Qy1fRqhf5#MnJ}z6VAF><VHm9JXX7O%ih}}_j09Y0|RiFX?h%!pvpRB
zFFC97>2QYUN2^TgF1d5ARwqW1f0eI4_nvCB2z}zJ0Vg8D+`8zHf7ylGhUr;X_P8D}
zN%%aj$X44bx%;0i^BZZN67)Bs`E1$qiWFP#^yd44lAE%!iLUM`bfpmRFpa@?#l9J$
zU0uVFxL_-tQWY(=yHDr&7nghrO=hb$r;usPy9;lA$yRFDvK%T7zm!+1wGHFD853CX
zzED+xXsEh(i(EA1z>mnW%=`+-D|bsHDqzu7GjM(7Co>eO)pyjfmF;^nDR1^DY7L3H
zx`x=XTtF>Wn?tp*r9im*^m&tQY0qEM<wYb)9e;pqd=__?XfAl|)rcl{mYFq8<#>KA
z<r7^_IQUO#W0Eu&#Yf={g<<13e+i=G+07;fj+422J`AngLt6rhizI%*i4nJ+gEUNA
z>b)H>jQSVzPLyx$__L{LttPW6(zVYnO$B#i6foO|-cQTL-@$@d!ldaYI6a?O-0Irf
zJ(lBOVDb@o;?qdoN&i6^8|DwadrKqSd~*K9TdTvGR$OHefFZ-er3IrP^Q7@YFxa9^
zlW=5$=77R-O!u)zT}Xjd4ONY0{kjPxuO<MJ)+{{QI)cDcOh05;IR;q~Li|8wXm7hg
z0j=iZBuF>dJ<vcH>7zYIT`N94sXQY=S1;l4r?@^T(U;&zb=m>42_^KEUst02#enjv
znc1ICyW?(*mG9*UL&bE8uVHXb*qtg8VHAKn=LK-*REUwyp(8g^<8pEC>e}Yhc7&;_
z*)?pFMLrp<u(WDB?@woU5|}D8LYPC>E;i)lip=pU9|j9z3zJ49i$D1M`|d@K#xa&<
z<9oQVV;;6&2u-=W2}V>nV?X}IICFS;XG|oJ#?Ak}V!;7-m*YEuHl0s^Vg25t)~;@*
zj4LO54#OUMdg~tS`U%TQqr=WP5IObjUPW-B|4{`C;F(^7frBxFd%uzFpVus$cZTC8
zzWsIOf+gdhmpT6HF32!#?l3jIXNd$=UAl#@pg<%ky7Xs)i8Auv%rohh?b2N>dS}~E
zBD<4U3Ghz9Z--p=)m^mCuTH(%LWD4`O(Yk{sTd&5HH?bHl+k{-EorGe>_I>IPy8Q`
zjfV_0zzIz3UVk$^I}+H!kPrvn`6+CX&_(k0c_W6)?pUNjDL~Od@;o&;WzV>@=How!
zM3Lb~3*rlOF(IhT97TL=Q2mq^vYb9N{6V??Yhrge4dC6zwSucmrzLOGo=QIgt7Hx$
z0d$H5x{F_Vke<!E4cphPD<qRoL~Sux+hDTd;M+JEi}4AIk7h&1SPQMJM*au{lt8K~
z!z6N(`ZIzy_Wo(3YrDG6P=+TV-DqnxsQAqlCZ;(Gz`uxk??xCI6CmWUyi;}FzxwM?
zn1P0sG)d_A*!xc^7?^tz(NuFZ>_reIiA@X~!<R1F?`J9Cw6gsA*uH+b9Fc!uuhF)o
zyCX3^6jnhlF29cDG_#25Hnpwcnn?YmTcYrph6y9`kiorwHFqL&{Keq#4a?R#wc>km
z0F6xBK|tRY{4PZ0t|eblYO`UCnNnHR;!zs*JM%)D<|!*v+65>q7|z(4!a5)Svrx;j
zkHMG(Bs5Z!8x;TH7F&-XdDPVSnK=~yXcliG3Z%ZU2j~nb;jGG<w_EHOV?JgcOx8uH
zSEecxhS(_2IbZ?8n>RHE%4Uinpu9d|;$k&9mS#za1^};l43x>E97g~^ac^tJb?uS>
z6c2>m>L;_`C$%G^ky&Wk7wO!33gm+bLTD#`F;4jux1<CjnlnhlVLF5JrxI4YG^<N}
zH`hL=RCE1O)7|5PMJms%{j`~UX*rQ%lVj1H1fr1vKpf4OSXKS1owD%NP5;!9|9f>D
zp3;;~HssWm4vKcRYH_zwp@k!ZJ^pkDLoVrKz(g4r5nP_Xvb}yE&om-$hF@IIGu0m~
zGWM|L+Thw4>9g7O?*OE6Wtd*ur(!uLQ7*#Bf23v^|IN-8A4!75M%269velG(n+;Oh
zyH(C()+CMx#J9@Z@ezK2)TydI?}z~QcOwtnvNVN)91JpbOwUq_nH@oC=Kt5-l55b^
zW$J!Xz&irw-BD=xX^ZN~>_(Ut+6$A=i((VXEo!Eye7Q_x<A}O@<Ox|=6bxhI;%!71
z2}riBwON?z4J;MFyjLwT_puvKsWZ*Qfy?UMucQQ0I1Yfd;eaZvdWT`76=gA+isq0X
zRu9-qM4hQD%6jzD>e_hM%I+=;JOJ$1zTI|@=zDt!ZHybCY5wm<tHw?$x^4E}C79FA
zf%m0tq9e_44cA!%U$Iu8A15JGWz}0Gzd_cuVo?OvbPj*o4APj9uU1X&o*^LASdBmf
zlT`=L$L>hy-K?mNFtuc_U30IXd|PM1Q(t8FH}I(suN#;cr!Uw2$0C4sqRcDho#~M2
zyZNpo4X`;KFmE==$7|Wh3Cj;ORg~MH7K>j;{Av3oI^uhOSkEoHCBn-n%C@u|SNKF8
zN{(61MO5sk>PfyKo)p5*CHG~Ob$Bd>WANT;0m`rfV@Rk@&gr4~Oso!sK%azw=7zNH
z`vta${1R(Vi@%0^5aF}cpERh!tNl<{gjyZuz}5T@4ml)%F{Pu!*U8a@F>_UvkHJz@
zWFMUWPN+Inm4xci7Rk35&HYf2Fs^3^HCNwDDXZ>!11aFXt7ILBf+2Wu%;Y@3dDl3G
zA}#00P@f`J-yC>uvlA@@*Jw3fQ`R;bkJ;sRb%FzCuvkQ;=rbrzMV8K%y1Yt1LZCf;
zwUu;tD=HPI7A!W5Y)9H`?3jN=(mk(|n#O4)!HQ;aktQvpgROzZd2G*mzF!klQ5z86
zS2w$guYT_w1KRp`{xc}sRMZXr>#1ocZT;fu9<qaE)aK+_llCr*p>ssVNJv$yxxGz%
z-m^?zNVkz2B>dP7oXa6n>rF+z9++WwUnDt1&d$3~wx^gLru`D-d*Ah@ylk^>lktqk
z|J2-jDN~X2p`fQOYzw`15|U?$fs+&PZ+IYK4-MmnpecqUi~$abgFqP#ss~G4Q3L`u
z3z6guK=l3y1_m_VBm0Fyga38-{}{wcC?Pr~1ept_c5vGdo%Z|k{?m9D7$p2RO{`1g
zyy@r*eo?G|F)>(!R_PHXa~avD>1y{+rjc23J+;U{4ib$sOrC_YhTXqtBL_(~CSe;1
zX#95;dSeT-BwQSky7|l<zB=cdT)9@Niobjc0_t2Gn})+Cw!`NeQ0YFOoh45-m^JB!
zHr|xh;{t4Q0$AWhy{>Q6gKs4hxc`?TF7SN)o4ETAt@odY_rFBnKgxkhQZQ1t+v_}A
z^kQOBXq9BupzeEag|QLI!CN+!75JISFDLDVGiYdvih3jXhSNxHJgcF(498jhB}(HV
z@7CVS&_Up9j1Y+q*Tu4w7fFBsZShaGg|EL~R%KJQPkzh`N?As-XlkDmb{`7@si}^{
zS;BAwQR0{=X*O&NI}c7`@}=w04dKV|gSOjEiB4Vb?&M_^iL{0rSwHqfG0_ee`V|cY
zB~k`4E7jZfE^+U>sMX5~XH^{`9)hfGH=JL0b@L`W`p%+|$%oDZ788wrzbcZAb}c_v
zN<=o9p%YE~6FM9V->LUh^jQ1yK}!O6|Kf&L)BquiqukS2v21>V(~V7OK}F`0^DUo`
zp1mQmTsTaTOzQAfWf6W~Uwd~=>V<H8x-a<ez_Ra};k`cD%M_$%UHcEm$&I?7WJ-oD
zSdN+2!0Qk+8mWNmY%js+AXVq60Mwz>q5M}+{)H`?tib2V_LSSGl`mp`0}I`%F)^cj
z$AH36Nx(d@zeqAT1o4MdoxnYGz2uGiTQ~wgF)X4AgXDo;90IGbB;&0Wt*v$v6>t%e
zCQXV0w_Rqmd$P=A7laWAsiD0ZpXgd~u^u_Q&{$p{%o_Tl(K8Z%5eKr6&w-=i!F(#^
zaj#`0<j`0!y56D^Q2Qhb8^>a*B_#BHqm^mZviT?)H6Dx`ENA!RG2C*OEzY(fBos!@
zA@0pCYO|V-w8nq4#|sh($7!ewOw$l*3^m5nonfqB(axBiYF#*vp3X5`Lx-pS)BSxb
zt*&p?k|ut7p|Q~$^_Mq0aAMx=3Ide5r{Y{E4(gyR(Bg6rwJ8vop-2!n9y0-viGT-h
zBX`UX08PmzQ&0r+jnVC)(aAFDatFCP>wgIBV(O@x$=EQ0jIdP)u?ZovXF>q|55m~F
zAKWuqs}<5C!<^VhO>61r_<e?mh~xH%4OzT<FXn-Uavd^Gyhipi)2aM!scoTr0%e#u
zbJ<iVkYHDdX?)uT8k>p1R?f!Qs}-c6sg}Kne1EoDD$7)BJ`1Xw7H5e|mz>Sm6)Cfm
zJpW2DCaYT0LGX%;y#Qt8Y95hAqWtV6Ru{$iB3T<qG>nsf`_6|I$s}QuF*e>xo)g_1
zs5uhjhF;^mhZ@ew!)k$-G<D6IEVhOvsqY{Y7O_u0;<dZD$x#^h9@fN*W-@1>9*iy~
zS-7LB+1206T-4|pi6v{(>c^Lv+aBldH2HHuae0Yf3d8;!QY@%y+90|h+AUUby6@va
zh6bJ>#FW5H*81zhq~-in!w-U=^@4iu+n1TR{$_q(ZR|;p%@uESRv70Ylh63La7YC<
zk~gL9P@K$)Gr>!<r0gD+uo_~XYW?Q8)>Oy^`~|C=u6oG+=>_;V#6tMfhHVU7noNtU
zgI28(|Aqb<-8(C`^8W?8Hnu1(T32`_y;7$@*8{23>|Ksf>;OuCxWF6T>gDxpL*8$z
zhvfu<eN57_NN(4iD(3&zn`C^RQtT@m>n3Iy(d4=_>L-Vb;t(88>6zGM%!GQBQen8R
zHltpUevSR~U8H+^zg^CrHafI;;`lv=FndK3AFzf2cKR>7<g$zgpvpE^d;(zjhKX^3
zIXmVGxk7yy3SU`Z7?TR1Qk@m@<wW%cM}ynkI|ry^UrjT@_EQPX$c<9*k>M+N(cVKz
zmbZVK(UDlo+hN^y64EGz9Jwm;>B(^-+PE2ZQzxcmMl~*oyO;Z3Vrm#`Ld`gkf5m!s
zuO7pl6D(DM9FPx7{f(MYTCjD5dgl+zw``cem)vRO7Lc=lna(LcZLCLF#HQ~eSu6fE
zg!hM*ay&G3xQ?x`^x`X;Owwy@`Rou<aPPRhnw(~3Q$+u=6C(f~G7@}bPO=mJ1fsl2
z_sehv6f3n-go&W)P)S4mi*2C_jJAS&d1nFo^5Q!}jDWr4f^XwCk0+U~kL8ezfF$z>
zi#~)61%~Ece_H`KsH(panC(XoYL*H<F>o$Kf}F(Lh@|QU9J&4{xTUf%0M}BRE-dQi
zC$YZiM$F816Z3W5>aTNSxfdNVe8kqn^kQU)IgX+xB&Je|rV44i0rO4{rDFLpz0o0V
zT3p(suj*x#+3|w4aM|kzs->K$ut{oe{N!eovsBXwf}A_qk;SVi7uhAFadg^bDvIUi
zV!w(wuz^bk=2G~6i%eF9n2qQ{aJTrYQ*vKgevVmn-Bh%Hv^i}Tigc|)oIKXBa9m1w
zj`-Jv3iwp3t(=7u0E_p%JGrL(=?OPju>`Be4RU~R?bulX^8!p#UD}e4I)ZC>!_V?6
zYKtn2`g}nvAXV70M2Gt1!2WNO!bCiR>HGy{tB09rdDp=_uX<fNZ!TM*bZ*MhIBIyS
zTZg+N32pPQrkp_bf=XC7!h>ub`qNtWG8(OzM8XmSMcmjL!G8MCVF3%N+&5=5_7ua9
zs?;w+6``Mt_hL=|7BUOnm=s<?(0Y!WLb(8pYVuCKm&S%9YPW(<0zFtEAwO@bBV7s+
z;jDU%g~sX)WphET@I-+73w3PuU!kJ;D^!I$LqsU)$oDxpC2*E3O|W~!YolH?!XMzN
z)Q<u$kn-uY`w8p_PiK=F349>s-3X8+Oh<QwJYO+H42OSa8->6g*eM$SryIG<g%brC
zyAtBlXXp&uk~eyEECcFe(x9Jz55Lyzp@oHM(eC&6saTrN0ZuWs3yN1;3X0RkDyFgW
z%%D2OlGDYgH}X0)Pffo9|J(em6I(Wbx<s&>JZxzkLQ=>G&?zprtrRnBVkVhqW6ACQ
z%xe8A0>QUTB?{L!T1+c}OkV_$;`JRW{fy@%W%GhHja_I4?Y#V?8Y>I;QbxM&5;n!S
zP5mBv$W5JOTEK)W*tppJElN0LrpgV&Hf4@JY(@7YID-MaY;4OfEn&#86^^4?%zKV7
zdrgS;?IzU-p%E&imx5NG=36bDAJh7Y*Sg(XJzAKEGL<3^8-MI{u2LceLu$6{oE(|_
z%~YH(n>RkosH*Q{lb7)A9eBH2rX{yobt!+WQG>bBNJ<xvy=`^d>7RaP0ATv?U-&;K
zGfBCc63;)Lb9;p4k3^yT2MU^Gg7ENJDVU|M;pCuFnwmCj%dk)g{yuF;M^1x?YeCHt
z$fqWjC<Q=qyhEqBRSns+%-?xib(xIMiulKwoOz)5roT5zh5WaD(!y7?s4np%w6Q?n
zlU23qu3t5=IE**3_=x+NW!Q|GMILk;XE}4d@;8J@RUnR$+YyH-U5uAh#V&;z&>dYP
zBb9OXs#R=h9bD`~{`t}Pi1F+`Dr*tWy=`@{_kjC;h$P@YJkjUTN}qx3E6@0L=N0i-
zF@*kY(Nr9@+EVMHl|=asd+#adAHLb$6A(7+2Af2onGXPc+VXm*!2~?=wZ;WncADlQ
zy_dS#Wv=O!Ug3uaP`gHRrQPXhxBu1LTLr}NJzJwgumnjUIKe$ZgFC^42MF%&?oJ@M
zyGtNga2VW!ySog*eQ=lC<agx%opaB5x!=R>r=Fhfp5C?huBx?a^&UYE;=aNQle>)I
zdZ}CXH~)cW;NNCRG;CDJH0~+2l5jGZ?WEeK4r0-GyUG6O?|v)UB!$1iHodJj)&RQ*
z$b{1waMUg1>thv&Xzf1#X-c=(_{mFtcu5A(p@XpeFZ=7uoE(4Wf9d=`rNxqO8$c4x
z@$Xu$>3_MBh#baFe3?oQl|`FYGe?lX(@u~K2>D?v_I2oK#`w%?v|+{=10+?w`>c-+
zQ&Tsov^s0dH;prxU91gVVGyB`+GJ52@Z1eAwKj^2%)KT^dfoeNR40W82a8JO$8X6*
z$CM<XFg{y${LD?8-Oe9q{h2PzTmHiQ{oXLXDju=qa>Z;^NUANPoV6j7Ez{%v+U`hu
z`SSAP_<POc8{16(Oxng2oLBW?o<)mNDnFes0Xp^@A_@W73+elnM}zQhFx;;f{3?-%
zlSBViK@76|M<ik&e2__Z@XkorHwIR!RA<K)(%{gdSy}SwwJ3H1O|*}itM<yq@5G#C
zQB=l{lJU**3X%h^bdWkYc?}Uh^36-371#9$9+x8#Jh<HoNwef(46M+hq|*dX-vJ%v
zA(}n}p#cUw)WPAR9k}-yq9)Ptf0O`v7FW{vd+d8gZg>$VY&I?n1Em$QJUXS=6a_QJ
ztV$#m_LR#U2Tido|BN;TwE|mvtPdrI5=n0FH|tJoEW!k}wlEMVaPhmgVxCRJ3jbG{
zTs+iXfCA`+UkqTT@Cg1VEWAk$9D+9D^UUs9vhngz2?%Ob;rJKW<nWg|^YPp~VTv7_
zsfPt)DCMW~3oblmvqZy{?`G`t_r(2`2WQg9WfjuP?dL*AcgP>)<R7zgRnfY>*~U66
z{(~g>SpK-BO7o*=7_vvpvC0)|jmka>c%geDB<ZY$*#5S;eSXy%?u0JkeHMAa-+epY
zAOB@-oqrb#55#v09t>{1iTJBODVnL2srVc-_b@1+@FY+jLd|{zgK(0Z{4})nRuE0j
zE+zIU-?L&zFRJE0ge6Bz@PU97K!B+-Wb>xA=ua4Ofb3%1J>Qdn0fEt4NMu^nvLIDI
zMubNMbJWb!^TJIEgurWZ^ZtO4IEXJ%04+3Y{}@pyh+Fap={rPfXV*S*PUBLkS)e>>
zXZz?g!#U7}LFlrM7Q4~k)54x2e&F+WeTdgAzd`MP<sM9PTSq!@6;2gS*{do(07Prr
zRy(oFyR!TbP@_677hz(PTOso@W_eug$WZ<%c#h^->tP5Liw!2F{4L-A$ybyVla}QB
ztm3ZVLnHhjzJdfYDkjEK$8-Isu)80hLrdfa?tQB?KtlC?5o<oN7jFT%2NHUWt)Jss
zh{T+tWsQP$1z9KZUjWwi`p#Cg8!u+A#<cjhevrFaRf6R=AbOO>2*Ai92{!Rxzc#v=
z*TK#FKiF8(|0>-8{m*iUn{R(L8n;h%E>Ctc%U6%>I+$D^L@3SJim=T^OXrl9Se=u=
zb$Tm3W%(`x>fN%M#b9BrZrKT*)utDB+O{q`E;&lqvR0)Fp%;ncsEhb*ga>7M#p4<k
zb^7Ss$fc<2u;zaDLaTS;B;PkEx`=B?%D4T+JzTfX+_FZu<6zx9Mo8t0(bzOhe(}af
z&pin8&WABiR&6C=W>{7PioTK=oM81^h^{NteOU4Aqq@4^vK-RZ)}6b{A3Br4v#P;z
zn@^~bL?7#BrQR?W#NOsZZ#Q4rh|w$_D}i6N@q4}*%9#sx26*l_dtwpbqs)pr$GsH1
z3{u3_3{oB_zyt#;)zuwj0|tgN5@y^1?g<;WQf2-^20Jp0NZzv|@v4Z|p3aV0gc8H@
zYotCw9ezWs{??--2*vc$7}GyT**^U^xeCA5fD=H>bVRsnZ*9h8Xa336Ua40@YNI!D
z%a;bPL}wX+hs-kjq(^Nyo>RkbU?)36{CZ2m>t}7bZc<KL)=LemkjjcFOZgYUimbbn
z=T-Ibt65h^EN<S|OBT`l*jpQqe{4G@nwMJANW+}V<$5NXOInOfV{s*-1+GQ9m^U@n
zxz|e}=}KH}%yv+*JP>G8G$1Hv;@r#}<RLj+YZY)dV-06J6`6s0vY>*ZWGp4?U1hHq
zd4wgCFdwTJeJ|;g<*sF2GDU3z%AVbi;F-jDJKMOX<UAK1$97|3V8o<6V}e~m$G|ej
zDuG4m@m8TxidgZ+yVyOY1o}=q2^$+ffffh<E$D#pBO4AT<tDa=4BRJeo70{lKdkQ5
z8W<{7qaanh(v=ElXUNrx>{8Ro^>6VPn)@e7w!?uR4!0g|X+-npW3|90Ve0M=d9xks
zo03%RkkokW&n5m)5<V9SE^$cEJrTld%&*-PmP{fqY1mTf;YHu?vpr^_`-G9Wt=<f-
za#c*^On`a=g{WA&y3(SQP0uTh<4$NcjN|0_7`ru%EQ3=@qhASXuf1}9e|s0w$6)yu
z+h(S_h$I`_JQLqyETtxSJlYi227iUWVfTqjxSG5FYpYJ&R7RKK5+p}9w!cEwoI>z%
z6=NLjqwN#P`~}wnzS@<E9<+=zCBJ$YL;4I(F@L4Dt?J6<F4QO$4iDwkFDl(UkHv8a
zo}<O#I6@P9EgpLud+m*B-11qY+<>H34$>=T!(D2QIT&5FDsQ<4yqtY-Tj|fK_}G%O
z0X2Q|&pP=j1?{}>6LC{{TL_Sla~YyTNg`K23EIX*4|^~DV6m;MT;Y34%a~EwLe)53
z`u^$Q_uYZ*#T!kpGw(}7Hn`!ao=x|nWTFa-y9MbL60W1&rg+*5Uh;1^9s4&(OgLBV
zw|wkiZY!g1c~C;nFSEv<k_K451EIO<8ArdoY5X)p+Xc`E+274jzkF4d3fIxBZNq2Q
zwztjK?kB~c&>wa|nTN%v;?@-#8@kc$?nD0S5iu*+mE8zrW|z%W^A!yaL^fs!eE?0E
z;`tuE={j9{J!HrWC$dTJ@<b^V-|tF8T6EVaSCYdMbeB}BPKnvGXAv%HcUvN+7{aGa
zT=3Qtk*lF#-7sKmt>Eja4AAz<5A&#+m0;9;7Uxu~-5ysp35C?xcEv9!VhBFmYQ&Mu
z{uqtCA00pY0V>9voupGIoxAf8^V9hba<F?-0x>YiRIV<gA+A-Qw3D({*1udMM9?VR
zb)D>?8&={g5M&Tt%?h6Di4_i@6i-uP|0vy@|8GrA?XMEb%OBSyDwPE%M+{3w7+2Bt
z#lR&~p;t=def}LEQf~N)dDbL24DDSxOV+q*jq4e0r959bs|>qA$LaT<H8717j8Y#|
ztFII0PXgfY;yCUF&7<wd)fs81V9`o1UdBP9Um<ZgcAx)Jx3bpsFJvgH_-R6c(^kFb
zo+$4w^P<#$_+nvpJ9E?50n<-|a$JG7P#-3Ere}rk7O!84&hM$=r6BRUN+iMHR4whV
zG->&fil5kJw6wu8!KsI32!0ex!CArK=Nb9~BW~5X<c4UL7rk*R+KY;eEvw#{16@Bi
z9(WW{?W(1mp`WD}Y_Z52#sT-jT90z<@*^QEg0eyhl$;p-vv6oKIEZzP)aWL4p_xx5
zre~WkUqs5vA1&!Et%DZpcwaOotwm@s2K~2{3Q|&Ky@*i8&!aZM6O_`4*DhPE!&UeO
z=p|ScM9haPOfuC&E@Y3IvvB29fAZM^YD1ejD}QHyF#9y+bR=pob6+MbBJJfyWQkP~
zk00g?X_tUuI+};E;3~ml%Y*-DuC*F-UiXp+F%z<Vz88sFs$JJP$HXIutn2LO9CWfV
zt$orUk2qx4#LMyPD<cb~s>__@01PGF=B&bw6n(vby9{_7-=UD?Ojj{po28*G2JXs#
z^eU2kZ9d*c;>vCL`h2)(mxp|;VsrRAnAJ=6n?k1gYkA8ry9yH*+7Ymp<r?aZl_jI|
zPKrtf`u0^<HWNP$6_u=n^erL0Ek$r7AGz#&yr&1ihW&Qsl9St5B7IWfXy3QyHZ=Wv
zfM&-catQ7Q>@_Xx{NA{q%2}2V*rczb$<PyS2eaHmU&G9FLAZBNZgvBja-HLOFh5Qz
z<Lfds4{#x<QcexA6R0b`&~Q+kYA(_AT8+6@gA0KjwFzv6-M^Yk#wq7gWi`-l#{VSL
ze5*Si?xr5`1fOL`C^bGRC*rxV#pdR*p<kqxCn2rFu3;=IL(j-CsWW|cWYh6*kpR>9
zGagm6sfIRgNi_YhO&CucWJKyRqsz(|W|gI+20?gn{WBgKrll_{x68QSjgbh!<-isG
z#7C??oS+dRb=7gffe8yX?PzM*uG>2G8+yCn(X#)LQBwB;l?;v~-^Tk&<OK!P#SaF1
zpk>)c2y{WFF47mU(&SD#iGcfyx}WW&?saApd)OCbm5;rkIQNYh@z=!snzX;SSmt%b
z-d?xI4XyH2ct=HeN6Gon`Y1`E56KCZzDx_I!TZWrt%$60)qJOM4Du@dREk>3Omq9F
zc^yfSOnl!Sgo=);VBg@07XKbLe%R2WP;#^|IpabyRIK{~_lw1v`}77kN&-A}4yj^3
z%6bmm?oHn2aP)h{(4<N+ykHAv|9vJ$?DXKk*O@Y}64kzgx{zjXT{tx3Y$obF9(`UC
zy=z_-5`n;JpOcc2<p?U~FZGB%?|lm~LIO0!mD0cmGW`@G5fKqO#b97l%|`={4`Kp`
zbH4dPg?L12YH9#=$H=au{d;SxA3uH=^hTn-d9$s62AqY@I+DS|;k5U))g3j!9b8s+
zbkqdhQa~Hm?F!=;j-T8$j9|w69u#zzj`ttGWglT#kpfz*13M^Y*>sBq*UV;i8Sg#5
zwE)q+(QmXq+^NXTMYTPjtXQv-Q(2s@Y4e`o$}p{i5zOL<C2(%CvgP++C+g^8HX5^F
zRVmX*R<vREruERNW9rRaD15ILr>&3Dv_%1=C?&vLur@QhoX81v8tlF$<c-`_chcsx
zng>4>Q(xB7Eqk<r50JsyC}Z4p_vtDdC$l5kN_YFzDb+{dL*RqArqBC6ir7wXPiR2L
zH70^L5?~#a*PA`U!zZ-iJ)!*al|=e70_dtFsW4Iy<C=;T(wQq_I1qu0joNV91hV=0
zySEo{d8c7$!$hx!eRt9}IHT)b4Axd6?9#%n3OUNv48YUGYd@rCvu}pFeY_zjC$RFP
zbPX0qQMr!>>E;(YqN4`*gqJJ+73=o9H?Pa%uv@lY@f>`j=3W>ZM{ty^fu@x<Ng;9{
zOf35o!TNe-X>)tbCVM%t?{0v&%Uq4wVOpCsnoLnv4-O|Xx<*&|oHPZSmhV{QAbgVI
z6cf%l>&y#>JM|MfW83e2F%F%JhGOH8;^Tsi24swjnK|$#Vm}Pa9PRV#d)?%3rp$*S
z(P6<ql2xQiDJrsHA2P_u1k^NnRuT*_sHWCg?;cqVPL^(2!T7C|<jd@eUUsKBT#WmD
z^)5!mLuMvb2Ymt?)AfOGxzdVb1j&VSkjg1U2b1y+=Nhttn6><Mh#NSsvaBIo9~~cU
zd0CKrLWomtJ9!$3n+zG<_lGb%G(uOn{cG7lDPkIN7*WucvAKoaH1pk+twszJm4oWC
zIgi?-bz|ry|GcKw%9F(za0Nw^&M<B|)N{I0o>t&mDX7WwMB00EA35bNRpo$h_Sy`Z
zf(u!;T5zdtpx+2lNge+K@{NqlD`(@V3;6uHwQh>Xi~VePi~6$WUSG$-!OP_XV7PF>
z4_50TTRI0kS6!`%Ltcr<GA6KaUUK0n#c3)k&YCCvOH0_NT^2_YT$!$=4Gr`Z_36Oe
zvPP1Mc=d6Q6W*{gRm|b4jSmS~N<H>$v!R>IL&PVB5MHzgPpz><Bb)_=QgnG%dB(CZ
zv~Rft(v;^WYUdoo_o)I(@&RdPLvJ&%1TJ6<<7}Wj`c=)Z`I@a<(B808&3H8y^AE^;
z=~xkM6#L1Sd<)xSOYyxf^koQmQ4G9z<l>yv)8NDR6l7<RrS3ROeAJw~Q?3j`b~1n|
z(c;$A{Mki0=pu68sKox%>k{E=>v<Y8sD0>F-O$*K&%KpG=_29$#v3KV<RF;fMEBZ?
z+?rTz*6>Ou^G49(j4sdq=zF|@Rtx2V8+17ZWOQvMZqzC8n1kBht5f5}WM9vG&)(nB
zMCmi<M(X{WMe2x~XM2SDX`;mi!gni1G0Fefv5D>g^)&9+ig2K!E8RmvJD<4TZ74a*
zeX=@AM(0mS_*3@~W%>OEObFZ({JhJ2U#n~X78Oo-%}en^M1r~ure(gX%=gNP<eW^z
z>@~x)m54a37v`bWn!}#tKz<oIDS{>aF+_jsG)@BKi+ywOJ(R7|-OG=vRm{NmDZ8Ng
zoG&5AII13F$7_nCO{}1}kS=O^hqhQ+y_6w&UPifn1U99tUsTt8G%L>qlJdv$Y0`li
zbl1AW#IPIsy2i`IeKyV}gcjz436#vUWK)}D93V#+*-M4I{)BRF^*mDthmMOn^O_I^
z0w=f^4KO;#tTo;`Eb=(j7Rl$f#3p4rc^4A@AP9VeUF0s#BfeF`lXQb&1kI|22-pqX
zp<V(XU=Sb~+r7UK$6td-Gv?SH8To`y=W}gDn5`!J(2?J@Dg=oSMa85T#2*u%JO0?!
zJh}<yb1;$=NFh$6@hJEc>u$esS8y1$%=01n@0i3NH~l3TpxV^*Llo}&0;d1Vm#^EM
z)XB@XzX#ZKz23-6e2FHKJ^!&2OM0<_-=IJ(#yUJHfg*1gt!_YPOi^TJiy)8ALFUp}
zG=z@5U&lK`SxYtcO|bZIjah#~hxDki*(Y3|!Lgc#L&-EwGSBb(nDD;TI(I`C?P|Ig
zX{DcD`ciEl>)Oi@dcX5US9o(X$j)|O3tIMnCv392OM5s{mfPEf3=&$L&6#w{oXfZ;
z%O*eoy?K2`Ku;l_#>uuOuu@Y7zhcu^bs1!EN7xh3IAZ<Foae*qCO@>%+fj?CR`h-_
zqd=KtStIX}T+&<NHutR`FGV6QaL&&+?hYA;?LUy7C2`rgcQw|vj)-mZ$Q-&=f9=?y
z&`+_CQ?(dYR!Z0Fbf2w*-<_XPuO?H5{oY~xO&We2MG*DV2Qs-2BYx8G!D#Qa@cvtN
z3|MD!K^4z8@xJ6>$Z4OW4}O}r|K9FHiYR-hK0{5PzP^$W+8M@h9#4Kz4R8D|zUTIc
zt)lS$(jAcR({S?wE8B_=pbO!SHO#!%_Th7snZJcjFD*GcZv>Yj_cXO?X<aHgIHW1O
z-(UOycla9Rjc^cQC)o?Af<tdbRK^dSR7N7FK=UKq87NbxCj|S!_Uqbp#UI&|(Yw~;
zHgQO>$U=ePVMtU2?*h8~5=pDU{qK7HlD6!EfZLNNyDs;qL!Br*pCH36MDYN2<j!|;
zb*zC%d-8SgadD>E_ZoYNS$akR^2L))M_ki=*^~PpXv0DAlW)yw!z|ers}x-t)o;c0
z*PMjhA`!4Y<{vB^kg3>CrV43@YNxB}eMw*?`S58hiC;aKt%UJ2<W2Fsj&}t6k3!o5
zD*jb0;@P`=)xmdCGnk2samsY-Ky+M9Q43unKg8K<6S||+G-vZM{Z?`Z|H$Lg-{ZN&
zi<6Yks>;ul34I6}&MUqxUOu|?uDVbWh5s1nvd2KV!sC8qTi^P&Aj-X9<Zd*!ARL)v
z*30Y9Py?1t?RnEAx-Zp-dx1!>Y0htPIDE0Xp3n0$@;Gnp?7DjCKhdabP+sl4i;=zy
zs~gFB0N)61=auHFM_t~tC@}AsZ4%Z!q$yXPKMd9zo+Y_Gil`Y+2Q+-l^&64^7!ax=
zPNWv)^+)A`>8}J>Ad0-wp%r?$Ve3T7?Ruiqh?37z{l((~ZBxmO;vw;wQcV3fMLe6M
zjPyE+ARyt+)-A_7DvjsFi#@B`On}WX^v-a0R$_7Fj(DPA(S)YOHZFmCz)WUm#xme`
z;gqsGX*_|0#|8`{PAcA3=!8I$)=h)VNiT7f17Cb;3;AZTd=#|lCl5PHbz}Jl2DdLo
z9)tUGT7h?#=hjV&QpRxyYYl`$xR)6nu|+M!cNG*=o{$u@^6zGER$?>>f3Y}+@0!dm
zzY9?m$MRvLv)d~Kb=nU4eEH!qdvdLjB!KI4_omgMsjNiC9+-8z;5UVi;zGm_7x^px
zL|#vmY+cBS0Iv69JlB8@F5{0}MP`S!sTk;7#l}kTD&WL1Nwu_=uUzZE;H6j=Rv^iq
zh;c`Ej^dH0Aji&@_)d_#RHqj9vSG|;tlQAPXPpB4a%wI+QDU=BX(|yq$}~)~ST&&Y
zR&iA4J@N~EIGQpuHU7JUYPD+P6GUAaPUnNUpAvB|SPNlOxtZ|meN?kN*zmt865=8*
zLC&HMY1_vm`9FnxME-XzfQxH0WW`Ik*rU^7vAV^Ey`MpQ@gee$f9txPIBy*2x*isX
z_Xs&=DPy}r=5P!Js)Y*Cb3L@<%q9vnUi~`i+I&fa2MifI#1Za~4B)41sCk-uZ3|1C
z4zo%fmCwg}LpeNrPU`VGQHG>94a`QiZr*}o{$y0NJ}F`s!<i&{DZiNm0wa4}GHz7S
zYWd5O1wymd#r#X8^|1IV=sX-+6h5)y_yt?1*GTn>!zkX|Wg?Ig)xw6Qa-^V*N3bWg
z?V63Pz54VYd3_giz%AC>w-Z}uq~?zMW)>F6sHmIVXyYW^w28v;3PmNw#SYvVnxPsR
zrlvb{m7f0cWcc8x!YyJ740QDIPpfx`{mnbV06>7n{0j^IK?}fL{{t=jgCY{&1LypA
z6hZd)_&=xb<gZgxypgxEvI1600d^s$npx2VL_{NbB*1B`rs+H`)_YS$o)`E?7pB0F
zSayL7=aJ-e1mk!G(iBYg;~UYu1fT~O%fCSuR^W+{MOZ{wbQ?|@y48ycQQ0wc@0{~3
zSS|?la<c^AJ|mnP<#}_L`24bdRWOgi_{hX2fCVPrrTHv2@<McT8|;^Vr@P0UXr!Dr
z25=FbmH&ev)?*}}+k%iD9{#}A-wh;Y;Bw4&PHEK~Q?9(GF`V6GGs5Sl<f$<4M5-Ne
zDr>8L;IU(nxNp&L5Sd5n=&>rp4bb7m5Gl}G8V6rIAi{upmo=2n^3VP79|A=l42$k_
zdYd&_u-rZYHXe*m+y04b^aU5gu+|O9QZ}^&620&Jicv;pSQXsF%7!(QnpyS3bMkcP
zKomYP)bHqniG04BhI3EOa;#RZkqVfz!rH7TZ+x#(P9veAKRWTNnYF#n)yeR|yBLDl
z%`eUXPwOP*Vxy61&1Qp)c5cjOCCOODxRPERh5hqX!>Ug;`qlUgP!5}cVE%N^ddf2h
zToPFT51l)SIb15Fy%(-XVXZp4j`Sm252ssRq3^*9jLjh|)78_Hkg{*(t>ZM2yK)Nv
z7y+aZz)%!T6dPqP0Hl*kratY#|Fh>iu2cGpDpi@>`3=Tu8xi}@7VKX|H>_u%%M;Bx
zoK1a1By(3krA0eZc}td}6SC1r_>2Oi3zde;*ofi3*p&T>$OJf2-t3Uz9cAV*2uC-Q
zjlJ0cEl-qsNnTB5fXBqd5Yn(Z=)a|Sp>e|=9J0zU3*V2}o2aG~MkWeYNtJ*=M-#ny
z6RJhiA|1w|vm&^(5%2fhVpF`xV};HCQkEFSv(%<*7OV)@Z`=o@Ad2tJFN1l$t%!S_
zSvWR^4xFk+v{nuLoZfR~{ip9FL9sb8n59)zza%ZD=kbv1OlMwHz`7MtzJNnFbsn;1
za|V^gy|E)Iz{>F$5&!IbLW(cLR)}Wd!T}EU{gS4S2GhX-n1$JAA@Bl^XE@Z+pt*$N
zy-ZNO(xYD{Srz*>jZun46$h=PVWq_5={|VxcdX|pUh^^;sgccb>E}^u{h`u14y_60
z3yrUl{LD>@%I6J<Znfwl5W2pB91{vVvf+nd<Co@HhOt_=6*H-&zc@PsFUo9?C#p+p
zj73YtJ^(*Y)~2mgJRD(xHcg3@cpkp7=AwLq?5_Tf7IrK)D<Px7`T?OKJC!;`K$fz)
z&scRR4_i&TBvi#S80Zz2F{q51qA7=sRL})lNszQ?3i`+8B=-N30({}3|501jr(8|X
z<5Xbtp`YOsCf(){djghNscd;n$3@=XMB;Bx+;Eh>2P<uKhhQNnNx<g3fb-hT4N&d8
z^*ev4NPXCxHN^-;axq_X>kbMAc-_r>jbyVvS|&02a=0<H1j|0V43+j!aD20+($|Jc
ziTtT|3Yr~1!3pyzJaCm<4D<!mg3xZleujnf^eHx;FvwI>Ybj?a7!}_ICqr4WKA&0s
z*&xgUv1f{5&f-{!b$vOGfvDg7THJfn-%<}sjX)Arz~%<&e?#(?x8<0bD-8zvcq#SI
z;^M)Y>4^zurXW+8R1r`xdiHV1;J1FFB%VFdIld#DkMp-nr2C7aaOT}Bm&WLOtvGT^
z=;cGP=sv>c=%hHeZzLnt;LI(*4E{V_{9rzKWs+<hZ>8o`Q+zvbk~N&l7A61!RR0FO
zR5GbuP9!<s<bVj$${cY2pAlqh&qn%h00}l-O?uy1PvbvZ#W70@FXBK7^b~eCvk{u&
zS(FE`pXmH9$@i}d9|OGw!o$o=k5m07K=uR#2HFz_n?|pRW|2x3eVv(}=E{&|=q{ya
zWpzB5tJFj!!!H5CgU&5L6g`KBBw&U3|EuAlH<ECj427`TczBKMFUcg$ijRt;N5hmN
ztqJ$+`TeC;RB&*<J^QJ#PgC>r{h}mfK>YBJ7=}y9&-&cv<-e;R$Ni46Nn%#tl^uvv
z0BytnT(de_A_<Fh@S;^WXNh%SC*mhC)KM99l9J*`yil|S=%R%dBZ0_Zys}|$k7XL(
zG=LQYLO|BK@2=@#b0%}QC-~AetCt=vjYI_I*GjVLn>o_11`R4~>Pxq;mfuMH(e_hl
zfMVCI*vM~j`^Gv^VAAbnMjF4gtC;?TjaZ2gEu6eG`q>ZrU_QP!3hi+@+i!Ldrq=|7
z<_zVynDQp?q$10)L4t6Istf1BqiHSHL?o^tmTXN-O@)g#0i=swsa?0_#b#P!z6s;9
zUeVl^wQ6em<fOr5?Pkh;;?WA2wbT5=@lu%B%){nNBs?>=p%Ad<yy>uNv{{Yba*niA
zckMx569>JPK`}ilQ*1H4qF*Kd17FDMLQdJc!{PxejmbJ28OZdloy07Muswr+s&;vj
z$JqWwtJU?o^s}R36LL(inSpDcF%A56h1vJtB7(f0gs^_%WdglN>N>Anf4w2jyv9W6
zg-0E@WG+3$1f^N$zkBvx!nyhEnbxX2(vNkv8WO%SnhCNJhs0OQ*0Y;CykuD}wOI!T
z2lwJxN88+s0!IhDvmE0oBbQM;Jfr6_+7Pol=*Z<L<yG@Zgq&D;A3=sW&4=4+$hVrT
z151JV`T3Rk`J+nuhRI9sEi$eHUvdIpZO;?Y(e3kY9G!EkPGS=>{ASm2@l+~pE4qHE
zP?<tHMwNZkJCC*hw}8^Uzn)_hJYE#R)1sJ%Y0~{F0`1)tzTKZd66exMrLT#-=I04Y
zRHe$>NDQ)H<q}DiiR(N~q<|(J&SOGWq24E_$nR#!El~(?w6(A7PoEfg&)XhtmTIj)
z3#pIlwHNK8OBWj$E*H*iU(U8mn=D3X*R5?HJN7nl9f(1_H@QCEZjg|$0S_^b(Wm)X
zrfEyi_LH*b@gd^~j~IllO0CXtCiyP&bm2l2#Y0~*sned<>zoc!*>Z2gC{U@ZJl}C<
ztBOOH{1R~>97k*MSCE32%K|&|QG(7*M%YHh9pN7kCh_y8qolOCvbBo=%r^V|Fs1(5
z3@~Mfy1d15z2p|KvTgI!TNuBWtUQf2?oOa_W|&W4p<@{=rD`*AJtKd5Nfhf@?$X8z
z3SzXVREx=22d$2NBp6>wD$W;?8@Ge;KH-@YUsW7t&x2YEdE`0V2X@9gWv{@z70@qd
zumVzJGK^2z2-odcbc<Tf`jS-)^dr}@5e7ObM<$an@rV4X9DHh5s_EmdIaZKXN(&R1
z>%+`-yWM@_uaS>;A!kol0&np1J)l}2<!{vH2eA^N)a5cqdsVQ1GNUr<!(kKEAWuq5
zCm7p0-WPd`7?~bpH7(nDPY=3D8?vxNqV{tSk+!<bxG2at431V6Vx)j$5e}fE8qrjs
zDO|e^-29iwDh*bHOOXW6+->y_@fWfljQ127RuJf<FG0Q6zcPne26k(j$8>l7YTPFp
zpP}i?5!E0^L${?+5j?eT566SB5SQW!$ec+yU4%ouMyGo&AO;1cZJKzw1mj$KBj7iX
zqu1VF7Mrar3lB;%k1KMIA#L|bBeEbLf$3%jqf~p5Z8)o;9=iQC;8>Da_XwA|?Wq47
zZ|Eal!I92h%~crnihVk9L&0$4o{GAW#@W-s{lmG5_a<8{v4DFUaQOoy?rBY_<aF-n
zym}Jk5JTX+ivC*l>0Is!7zNOURZ1eD|Czs<uCei)&FoaOdmtG6MfKcfmEDGPj5ur>
z>@T8wP0a_+rfx+X%o1#fq=xQM<u{o{QY52b?NtYUOk7o4SP9AN{SZq#ikymvs_dK0
z#>amsFnbZcaXXstX*2Qw#csJM*V1CEsfqeY=Uij=PzQ_4VXvy9GFvYXES)*np6OF=
zd(kpwSI4ts?bcARnZrgK_UNkr^-m0*UeMDfHL#%U{hUKv`O(vAjETbsh`Y*VRGar{
zcao3&Q1AubN_~tL040J-wrkrm5R!pm4jW}lqETl}crC^WC>4zQl3{dfxogp?O^OYc
z(LuBm3a3>{@|!(WDGD~9?cn1kCQhqdL=u#HN;E^5(oEihXjSN?WEkTI)z>DJhtSp)
z6$irx&tp9tC(TSuj(QQapzjKk<NKSEaM(zUmAoZ^+3%CWZ1ua4kPzuk;PLUss2lt$
zmse-un_kYte#P-3Ax_)z%g8C?N5{FoMHocx)MddFKT1pRgk2>b?k<w~MnPK|^Np1F
z!P6b|Oe56$VXa4G^kGJWN1-<;^1A=`#H^1+3-9Up)V5d9HeSpEpl@q$_>97H{1Wl{
z6&3)$fJPSf-E@k9KET`<?Q5xMX`+M7;X~_o(nMMSZ0$fUsb50p3{^)D#>kd0zmk5T
zt6d^=VO$0jlPZ3(p}xoW@i;IpjwW0t{%EDA=?LZfXo2ySEp_Q-REA{a#;?!XBroCh
z^Ov6r1RmcTFQkuUVwXKd;rsY3BbIlYKi-IJKGplL=Xby1I1J9<sk<?#ZWuVps1ZP9
zvQEA2`lEFvz<t&A=c-pmu}Pii`tY&gOsu!-SMR{Ps*fWc(A=Zid#|9|$LlxZkpz6N
zA$anW^EWLZ*vsY1Wi#J~&##-Z&;gt`82|0lq#{uvJoF_9EBo|4vi|b4zjTh2=4dX`
zr#*&6{)j9cAhQ}88PM5sDx(}J$ldr{c4mp>3;kvCv<=<Qa<z7r^FOj66L4J%QPHN)
zI@TeM(5V1*GBo-j$8JHrmC9I^*n%R`szsnkBR={a@7jEH+<yL2J6Wb2+-~%Xycxy1
z-zMGs_A89McUZG(zykWzypfW0Mff$57_Ww;sNv5+zK%-Xrbo-0#bqKbidssSJsXDD
z&eyy`WMqvuLQ8F78tUrx1hC)KzAJnJi+36BEA}p-0m)F)mG&-&M+?f7PR~XR?kmvs
zHS-bi{KMGxYfj&OJx({gNq0Zx)e_iT-&cAq5~<&?5jXU{xEnrBz*r!Pz3E)mdwch=
z^lk8yG%f?I2|@BqUBouiz17_jYr7^z5TWaL|EYp3Z*Gejx<^Cw@pkH@LACrZE-B1L
z1DIu<Uu^fL-UCC3_46R6_BmdotGs`3Fal>H@V{dJmOD<4jkN>$SI)QatLM_;xbLcm
z4UzyUfFgqtX#NHJ2mh}H$Nx?t{5^eKrdRGW6@JbVG0)!0b$-D2@2*y8&y~bi|8NNZ
zN?aIpc6NGMV9H|>z7FdAQ=hW_3K<y#j+BlrJOSzXlD2;<RYFu48!z_88yg#&pskB_
z(s*3<KNX6aZ-g6NPxQsb5do3|$T7Wvq<4l!SkTqA9?De>l$i@A-zN>)ENl|V<%&hz
z-tLzR3kj(fJ?E!nu_U2ubqcxlSNxW^J~wFcPuEHO-gDA?ZC@;G#u$yOAzEn5jv3#y
z3U>tF-sdV@V**#jThv+WMOqjvHa5SDWis&2pL6|ej|1!X@cAi5muOEhWg1?qb9(vu
z1W{llE$(>Hi`~l+9xQn^=uO@s@FAqlFc>J))$pu1e8~HUdw2n&LmT$(z9R@xg{?$D
zgBdqyipp)T<?DqhzG7%Ro9Z+^a@e9O9O7SZP*xkYJdWhOaz2irJRG1$v4?ilo%2u>
zjU#Z4tZuvVy|T&I?ZK-LyzVOyg!HA9(faJ~ag(3ybhkM<Y3(+i)|JsZ0sX&odva<^
zvRFl{PM}%`o~qyyqqO)iJj9}rGxaOK>t2&)4P;0+Agxif+%QQNI!vpePpWScf~9{J
z8b4?1Ri;wA)0MClE99h*sIp|f@>M}~T31o*ueuH?g0yf*xf<$PHvc}#C#2IG37y5~
zyouOtO1c1s=lk6~+YvwcnyKg<=SvJNNUCg>$AUK;ItvWUni;1$I`(TlbGZ@omx?5r
zFMi*FyVQbBNWu|&-0Com8(V{1b4(U5b{zZ1Gxu0Tv%sKZ$}R`Ao);KDaYXLnUOGfI
z*a-Ev@(X&fk>v~X!nh7;+4HVU#-m7%{N{1}5Ny&6p=E51auy%)xi)qm2};~S{2CF)
zzOjA@b?3jmZz~%dx*p%6FR&JW7(Ml2-)jZ_!G)R(P;V3`MmHgS0&2gZrqll=ZC>8~
zd_ZG9*3(uc`gt*3O;yQo+)QVl?5EYpyz*um{YPbEu$k3GQ1jZn=w%{U|6zrmo|fHY
z3(tRujw^GYY9;~8a=}{}ZsqYNFcZgX{SxOCDRa?z20X2^UY!81p@Oqj;_Weu%vCzQ
z2xG~3JqV9jmFaPJkW^YKUJG?6Wi+|?c36C-5#>nT@4?XK?jbnhfXJ(nbI~W*8OAkA
z$Z6_|UOKH!uLY^C1zt(;3@!zc)Nb*`K^7Kx)bGsJFQ?Vuiy@pA3oASdMc_3x#rcJj
z^zGNpt?W|w3Tym7s`C$l@8?>%XSH3%JW_t%N+LL94hm>A@If13y-wji%7kQpW!%-Z
zeUY`d(|E0u2`o)5dXompNO|ad=!T9A%{4XD*LkTtZ#BVdiVj;x@A)qbR|1F2&%Qp-
z>>Gq`Bv5vYAZQ?peUl>e6_XKF=w^Q05j$<7*;_*<io(=y34Dt(-YXw1x|xR~Ta&y&
zKQT>=imYDw&1ajL+miGRJ@z>8jVN0~yl*QDX7=Esd}3@MkIwsXYB7NjYy#VBi}add
zI^0vD`P8dT#Wwmm$``J4$8^5L5B!Ywzw4Vh4oU^+T@5W(=Cd|7F(139Tk=s6JBd9E
zEiz38XX{$!-5|fjYqykE>V8???LV7RObn@jtRRcu4z7I{W15<*KwJ#zX#8m5@zSi6
z)LU`on?p-M5(Ti3(V?%|*57N3XIpC@P$AQ<>yDcD`OTAOsEaxty?3NVt+5>#ubVIP
z)SK9#;F$_94>jKtSD8r;nt3T^*9^AM;&4FU<-48KG)Nr9`gn(ND6n%|o|I|obLWqt
zZG_}okoo25)6B)hx*c(P#c9qPbS-M_^H+(4eNy!3B*CAm4FY+H=wU$}CK|Dl?HfN6
zwg?0E;#Z^u<k`}kF_qcpa+;4!UZu}NT+6)trkk{RN=MXrsH<$6_of<3=P}6PJx>>F
z9`SW>F|KTtW~Ri6#tWyj3RPf}KY-fPUxHk3>nxxct>0bU^VL0#HEgyDwnx*^##;`}
z-RifbSE?glaWbEL6dys(VvII_^{F(HBV`D~WbfCov6E->tf@~LmzNM6mAT1dUcqIw
zw1(T7bf(_c_m|S?0(|=o4x_hpeSSAA)MC18<dZs{>*=$?v0e|9p7xJJA?V3fy0^$S
zIxm@sAZG6HlpZ%y)8*cbxA(3PC~sS-H*d%E3c^O2>$20TS{J9w+bgkf-jeESMLcw>
z+qU}7F#czmYhWBTmWg2g3z6W6*>q82+CdgGgZ;tfn4trI$xb4xbV-E4lkR>FH(qP5
zG=8_+qM6S_C!svPpJ6~p829Y5{rv+zx!lYJ3iR>xs(IaBavsLXUs@h6W~B=b4G6uY
z>R-jIU}?RpI1D&a#K9p@ysrtL9pQ?;T95-dI9)`cjJiiS3w>Xm7G<_d6CY$Rf=|JH
z4@yQOz0SmsJJ@IZK|9JB#VaT~NxNf%9b4qboAx&Q8&%F=UD$rRM%9DL5$x!d|F;E3
zFNS}>$sZe>XVwD%`tdZ+*?Vu-{`XS?rwRSAepPJ-^IFU1t#DvcId5Rqx7BnFLC};K
zgyW0OIZ0d&%ODgSw!F)XQf_WG2i(zIe=dUWyeF<=nC3>w^a;Amua+~kBb*HOSp#<q
zx>JmRf8;y$(LQ$1Vx}xOKAuxzv^aW)6UivYdnME^|6Sm+30x6u=lil3&nLoIHhgIn
z*P^_b*NB+MA!l|zi)q|jIT)9^HuH$ls($V^4~<LE^5Jc?tFZR?V;<T^L9i76hj|t5
zAL5x6#i_=&VGdSBw~UIO#7?66tY^O;uZy{)5>=&x9?z-e&rY9C%%8@IA<1Xg=~0(0
zdEwI)(xf^2T^@?}yRG3lGNTe&1_%{o^pxddPxlH2dqk89_AROKOP7)L3=j3>f3bj#
zyZ7+PLOm7>c79%ds$c(s3Gb|R2i%|jX@P!-azwS)5j7zXW$Ord`LX}f4@diI*7YuI
z@i5=-jv#;90P;w%zN}?8^Ky0RI%qc1OFT@HfEN_rG4IdM1GVPjKZ*(Ngm=(Q)n(vR
zsu+ZPf!Dp2z5rI6=l9BA*uU>gZknckjq}_37r*M(Ysq{<;(}6!MYyJ-M$5@-&QhrM
zuQy2@*4*;7RtK0h|BU_;e$Q-bIZxk{^TAQNGD@sl4-XFAz_z|nHrmG)^|srht4t3o
z&Dl_ba&Z_>CI+{QNgwasv7bNLXm2j9MY^irLxR%<9JA7yhQi8Z`rxybvt7elC8hwP
z)6b<Ev>1!-RU$o)k%CkFr6q+HRQaOBTt+yQDtRb&z2UVYXej*qZc&W}vU4fJmnJfh
z_xZsjyqnF-$eG<y{ChU+tO0ksyKk=|J4?|q)>Jm@@w>|hSeviKIvAGavL5=wZZycr
z4-_-K+#7R8j@SP9X`L<K@M-Y3+)}3@^~iF1UJq8hT9}q|I~tK{R&FAH5|PZGDIWGS
z$)cxmHCXHT6#{@;z0$I5!-WFiCK}%JiwQw(1jTAb#|=f~mhQuI)DZ2v1vBY;v&5^<
z6nD2$sw|i9%XvHGCRu3a_stcwy658$CQ!Ab8p*3SX%=|fB+|=4`rnVv$TANn!2_w+
z1S!3_&y#4DuIu40CoeBx@S~&W<-7?%XWILCbgg({6u<ns_>nq?<3+aY_s;bdOh^w%
zHjH!slcDO>aCMouT*z|EFVXL?itykU1)@Wkw;NZMZrGgUWN(vqs(Iv`S21{w!ajYM
zdv|48e3(3saV~?rDz%y(T<JI3l%L%Mr6wc04;QH_x3L}15w&T($ydo-E!f41PZw<~
ziX`M=H=Cd+|L~`{yj7v-E606(D#xhp&KJS9VLI%=440MuC?X0nM*D_zBP5CV_vff;
zV4D45j<eR~kJq${@sgXU5S0Yfld8uwHV%$zV5aB}0Jwnk79p=Km4gZK5_Os6^uZP`
zE&%`o^3i~p(97Smd>sW1&<#S?P|3)}!dEK=0SD7p9vvNBTU&d4Yzt7!zy`3(QygVq
zXhzbxF!1o);%EbDRmxa7IONhfW8_f(=I`;6Mp{}Kle-%VOAA86!T>Vb*Z7I#2Y`+f
zfXf5d)GQC309r$c+jfQ@$#D-R8PXo{baOzWsp+W~?7YqWtc;x5Z~TB@iW6*gGX3#S
zBK`=FfW-f$iuo6U{G){gSRkOd`A-$|Uy)4XF2a(@t!Ard$|#_x93N)2-}s#PUN9s)
zeB%#5A3L(t)YZKi`gQ_@RdjUJFaKyP|K+~_Q!(|Q<NqSb951!RP15b#+uJ)`$o|Gi
zLD6LaATcAPWj{7av*CtPpNGB9Nt_0J|3O#`ag*H~ZziP?$$((%2cNWtC(31@D1nB+
z>UnL;Ps`Dv^JMpD9M%b!bX@^OQpFO=$93_;qsNvqcqb5-BrBTk83CdJ_-L(GnS)cz
z_B}#*as@40vB~LoB=qG4BP7OK6nWHbOI)Cuz$D;b%FgftefbpN*p+14@s8VZKO(6x
zz!1KD6B)fODfJ}SZ`=|!V7n>SHYT}^!kJ`|xvZ3TOGUN6At)_U$NwmJ`ehn#XaC!s
z^%IT3M5mo(zqr6aGN$yGs+7C^=>lp5qE0qXi7gb~BwdrFvc|xZdJiv*I8o|1`p+<}
z&NgN3{O;mhI$)1wa1w&IOie^4Jcr9EY@E}UjbWR^@s=ux1y0WZjU8d+3+K0rapWW1
zNG7+dI#P0UD)GL)l_NcSPWbQrc}*_RMjOWRbeOF*uhFA*5C}0wLPYRu%8~&RQKvJs
zjORLy9-C9xqsfu_gylN39Aa4s$EP;RCn+;?6$W%@rSuOCW#8GhXg%a3bOi|S*$&?e
zp}+<|gCpfu^W@Vqz55oH+~s9T{}vrkIxdkPQs>Y5AgY$T-`6gv7{snSM4TskavL#v
z*EGUT(0aX2tkVmDtV<4m^M}!b*Tj7JO;SBSyF;$-hqGf3UQ>H|xNV^@;f!wB>JKfi
zYqLqa&)QzKR8uzw5ng?f9zD|6?9h4CpJ>TFsY{|Fwd73y6#OOT<L=7%+s@<r+f7C)
zc&_<+sGR#%zzNh?+H>_sGNPu(=uSongz>qO;y9Qob8?2oL3uiWx45|7RF+=J$0Yg(
z>1cx1L^+Frw(wy%1LwIhUJMeBIa=SHDcD786RnC`PJ0_;eenEc;}32L+HJhGEN-g2
zCV#&|<`-z$cd0?fZ|zfKYHgCjRUp*C!I_eD7XQzd?1)rq=iQ!}BtB3Nf`1(8*)-<n
zSxOxy2xK}!t*MT8-L|ER5C6P37z+t9AaC>Ozua{zfHLv68NU#eb)KA?siLn@k=!5f
z<^;Ikyq364QDQRuDp%ygG5$2N&E5J%NO7AVlbf2C_ypZeQ19pqS4W|_D<6ou!>j28
z930-MWfkU~793DJBc$5f^%Z4lk_HZ}EI}1)yEhMrq8nwFsJ^s^s+>I_J}<zezUjVg
z=8Z;Plhozu5S}YTW<QSf%e2~Q>xKzHx6tANwiqmBOZsx^)a2n(*3j%y<<#L7<8uS8
zMm~D?u+p#0`S5zh0p2gQq!*6Z>2TSg$~#N&-|Zgboq?=nTaKbv=XE~%CkBM}=*NO-
z8woO3ZvuVwS>E-I0KjN#y!YG!{Hk9ybiWt_MD|T<zo+5FFQ&A+@x5}7$s6aZ*<vW}
z&+WAoPq^cT7UcFtqKgO%1)NpBg;)c6E&;+PKNgX9EPEW~Y`=GXa9g`Y+VwnSE5z(e
zDgOOI65lJ7J6y>|hBrIDcQVM>UtDvFgJxjfm_4{<JGgfBT}ma1(~$9MlT-RDFy>{z
z_z|XgpUo#o9pYm9RlK~)J<Radj)lEEwcPaq%)=8Tj$+eBp}%3O*^1^0HgeMM{~TmL
zF_+Rw0PJV$X>J;hj~W7AXB@5DLox7!kIy=bxVEyFcN=P1c~x76k9#D6tSTK2@k3Hb
zaJ@lCr=*KZfA%ar*o*xZZZQb*<2wfR{z#oUHMH$8G7gfFBa?zw7}i^xrM=7rJKD|i
zBX2jyd1QIuE(h{Z*YqM1+csx8q%EudI?YGv;bE%#64Y5g9=Aykes=MJE5K@!Dy`xL
zy0bbZM>b(mV1D;Et6gOr0*on6o4HA3H9B4}LBkhGjj@7JIOFV4)TqO%ho?gJa6b&L
zrq(64ll>^|#ukOyNC7suowWw~`N0g9V@+NRYxgrp3BO!-HPwBOi*L@$)$;Zm_mfxP
zBmypCU0e>&s(XJ!V9;Kt@C(bUs3aXUyg~C0f(i@Zhtx4ji4ze8_AxcP;313Y`^dfP
z&mLUM?9-15T3R#!S;=jA1nC*$(!IXV>ugf<wSs78a={K6*+G6Z7K|PFxMX&EJ5sDP
zEjet5PBD3^tlm=7{y4N)gc5I<+@g)6c0>^wrZBe;#A8huA)(@1=`1=|0kK`9S^5t>
zSQyL3x*k4LkSs@oa4`PIuefpt|0g_(zux!fNAgaFV<&5-CULwDfCU6xhsA&n_wM$h
ztPt)p)<D`fgcLLro-)sjR!f8=zvqH&=`}ab+tbOQ9;6>hwS<r0#-adZ=K7&#jm(=|
z=)LWh>WYArNZlhc_S1w(pS{4v5h^|=W&SJz`uN2<P;=Hf1_E~3>;KPz`=0>2!Mw`v
zZtLs$nH&huUi*KG#lS;8zXI_;Fp~d!I`BV*^S{{xkoEx2{!jMs|D)Udn+o9nN}CbH
zQ<yF1m>3YB%}GnKAHBj%$;+E=@vIDkAoX)oJWC`VA|`h&EiCqTc2@O)^TvliTFzA*
vA0Lm6jd>6J^Wuqr-59{>|ErN4k*}Zlv%leV+OO_`fK5VFR-{Zw*YE!Uj)S7m

literal 0
HcmV?d00001

diff --git a/doc/assistant/inotify_max_limit_alert.png b/doc/assistant/inotify_max_limit_alert.png
new file mode 100644
index 0000000000000000000000000000000000000000..d8d334152e80428d509b036baf8a2d9eba70f4db
GIT binary patch
literal 12583
zcmb`ubyOYQ*XMcB1b0Y~5D4z>F2UX1-QBrpg1ZEFcXuujAh^3r;NpI98J_1i^R9lU
zXS)CCTC1u~+1cw<9owJ%t#Czo2^2(pL;wJQA|)xN{Jw|0uYDh(-?v{Xu_)hn2#%6k
zE&u@PF#v#u3Dx9Or~ZEOgR7LB_=k1aPiTw`e<o4=-%ovZ71wkXb+EHDvv&oEI-41}
znwfs}uyVEhDj_AOs1b;Y2LOBpNQnundaj)M`N<MkW$y=%RvQ}c7_JBzuWU8)Zn^4^
z7!C509mGAFpxOZ|TMIfQ4jy;0qi1;bVrwfb-LC&wIw-If%to<Im%AMuBy}8)5p@)D
zlkDyOSdTlYC7t?B#}$Qz?8=UgNg1$OOaxPml-edZLcCYrGD0!P7UDf;t+wGU=zp#w
zs1Jg4EAWGYAP~1w#mgv>0@Ognd5~JE;)_n`zlkLlOPn*O(O46k?I1`gk1S0y<pNS;
zI{y>3-|~+a-rG}STYA;nl2W09iA$PhTI0H<mR{&+`GyixlVdD~9gQrV0S<}4?<%z=
zVUhQod_cTP2{o{K-8WsrD;dlAU^Twce@q>1(x{fcR*C%g1eIup4^HnE=UdB@hrx3%
z5n^aX1?}d;9q`qn+N4fXw!l88;=Wqx>z$vdt5apJrNQ7;1KO9Yr{kPS0Z&y$#oTGj
z{AsFyx0}l+;^&{hRF73HG{BTRg!;_6vW9Oug>d;9BE^RPLX7wJ+WY$t92}gW_ucs0
z?KOyjmX@B1>i#_E^>$;)wA+V$Wtn$nxk6ywVnl_!!Hy31X<}jX-Im|w2M=LkC_u%$
z^Hu*{N{YH?u>H$*z}H=TO*C{^fEd{##@CM%ND~>7A2iXp7}24?IL|I9gfKDN4TQE{
zr-q|8&K^(!*F`kjls-7CpXxMiuSUz#p3oAgXIUEzSZ3Q=J>`$j_x6SoDP?%F?EU=K
zkInRXoIS0q(hN%1av((u7<8RPcxVfpX<76n`?s=hO~LZ1ZQZBCl@^cc5^B3Pqb6Ow
z<XEjuFF$Jcl06K$4i8%;r@0Jk{QAZ8y(fF$8rnD5c~9W*1m;}xrykD=sv`l?n}Q0R
z1V|`y5ZB83N3hLF16KB@p9REO8h(~K=Wdp4Y*k3GxKOHEv=(QAAK^jFX}91j($v{!
zJ0|SU$UfXLkpsprFu>;;!KaR(e-{V@lJGKU%8|YhdRX6+i538K=R=;&jD<o^&p;4;
zGCUb}ovH@DtYvFVtfLt{tGE0R`E>tdptHNIvWfp;k~?#XEgQl40u>eNBaD&I83XGQ
zD;|_?2{A#22w`9O(+TWSc@@R%tB~R4Sr@`ao8A1vxvihFRoT6M7gm6J#Y@9EG4IPR
zNA!0UMa3ScH3Hyk1e1kRs2?{M%vZKQCmzjw2=IZDT%HCN^%~vN`<^ue_NFHk@Ip*U
zJ3(rTOQTl8F3r{*MT9-hAw76l>nLMzP)m06>N?3soV*|B)h1`z#_Q?iX5Uj_O&$4T
ztStGvT@}H{tI;%xSa8kT*~0nj<z1a-Wp3`)9MHGr%yQ+aa(c&;ix(Zm>l>YQ<^-?F
z0Ikc$UT)3OMt;tzCl}jI9DPhLSve?d0pU$clJ@hr_R%6txANJOuVZV#9$wDT`a28a
z{ezvhGvKO0>FeL~*U`<l-^n^4;;?}Q11?p_0zu95Dltd+El7su1TFB7hc}gIa^Q~*
zTQnxW&HB>DrStWp7{^k}*YN39j_HTlaRMrS^zb_2c@y^(m+R4lqjK;+Ul$g4adFW_
zE8n*7VWJmi4><q23$lKzJJ2Js^D~|crt#<U11-H$01D<GEDtaP5)el<beYiw#5Pfx
zkrk0cFg_2jm-FwNY(9SIn_Xu<Py;PvY;oC}ktgW7td>_DA0N|oq>O6ix!cGt0v;oZ
z!zNX%U7)F|YA5p|ShNwTKj~SB{9at+zdKBCiGqAwKZNKKe-Mk@r<rj}?pq)Eky2xC
zXiKH(`&Z3S5|Vw27Ljj_3KCLMW!a0XqWKeip*zXg@COTZ)0rwS56)O908Xw~k_0}4
z3vhYN^Z}*E8DJ<+SN39ilrwB|D6TC(aTns(HyzWpmY5fl1HCdB>tFOZ#flJmEpwXk
zxh@vEbj~&VMh`_%M5?;1vEDr0k-iIEUjgD;1Dp1{CQ~yy1nQ)Yt<1j`sm|^C4%ft*
z;i~klnStd?!430l-8Z>EGIMVCXBi-uYloe@yJix;DgXv5z9A!=wl%kd#nq0LewewC
znnkjUjrMY-b@;;mOz8Op$c1Nf`?GvOR#yQLUgF|v$*Q;zbtq<;3(P;qdY(s*Y1uN%
zXmhxY^;+{3A1F<BZYAFPjNtR8YdkC>3meQugt1_xAQq^-G|Y#?exwl$3kfAPK+n2@
zE+wiZ7jY|P?oC<v&+DLiBxh(sn2~sQ4bSf14*?&ke6CsrCZ-}Rs^K{kslLE+qLmZ&
zsg#I0`M+L&2zFn9X~&(yXs0M;nvbv@XWi<{mCdEg*WwVR70T4a<@7;0@g!vx#8(TD
z=X1@s4t;^1G}FY2enTba`ulftIJGVOCbe^EX6Ph(@^^f_@k<aS*@JCx*Ew9ulZT;m
zi-*I7^3!h6JY;^0Y1a#yK~qn|j>{Pl!0Y4XKGZOlelr&|zem^D1a;x6@0s_yG?(=?
zN5$r8YqT0^qB$psCD3Q*u=T?Dm=OtU^vv?&b}rf;7q^3UPc*ijAzhGXQp0V^9LUzS
zZ|l;Z!q=@sv`LqI%1Ouf_V{6n7jwWzQ{KX38R^t+tcoP&x21){_$qFCdc3=wrcphP
z@i;9Op2hin_g=)EGSb4JN#ox799>2k4uCFlxEhJE<pp}G=J5|@wLzuVu4~>hl-QZO
zzjrG{;};fMR;@NY80VI@yD{THGKNO*Ri_Q7E_`T|l0)T%KQg7ce&JSp^uyQ|duTtI
z2w}0vADK=2MYhIGf*aYNy8A7w>?o%j+xM7n8;&7vSrwLc7RQqt$Fb)YKQ(=Ec(TW|
zN*C!rTZ=Y)0Vw!plZ)Er39x&y26LvKmW<J#vI<MEFmuy~YVzf$k7%z#jUnsnF|{N&
zH8QF;j+4on!8_Eu5zoqj&(^hI4E^`?Uh!mY*f2UMDw&oM>&z!}C1zcl^PBvdUe~(v
z*sSFS)d5qD_RCwkSJ8lvW8QsC^b_6yx(B{d_z!YeKjby5N)7nB5x?L?1EGpkUU*U8
z*7_pdn)cZAU01xa6Ls^^=iMfp`B7J8Z33zU{9ou(Tc2)!O3=kSkLcLwg*lcfH@7!t
zk}vGOTA>BhSnwCQr`Em(2x{&&rp}h~Da){}?pN*|>Rxxl{dB3yyqcS<9Dnj1-f{2P
zs}%>9?ui1v)4U=TC!cHA_su;<sa~gdH~T*NdKKP<*;PHBau~hZYC|b%yBG&L!D!wv
z52o)2I1u(gv#M&l1aZ0cS&P3!=;)u*Ef%OVz2bXIOl*2Fr^6sOq6P@p>|$euGEGqj
zhb;2lJ~Akvw54jP(5;&*O<dtqx)i}^>fEfiEM`gjjLM@oBYR(|Cdq;W7(1Q-{Q>ON
zG+Lc;(6Aklp*eOd(f)M1apG7Mufyy-%p-HNV5F3k6NzMr(D7}eZr3oRA0ikQ4afRm
zHOJn7NwB3O6>^pc=w1m&-akEy8wfs(RVI!cv$@%;8{$*GK{GaPzPLd-v3fpq!J(k%
z6r6@2wb_!x^UG*djosEI4OpV{W7<WbSX-*F?TlK!^`@W+X9Tc2BIWN~YHW|aj5nJ{
z8Wlgg`TTO>%S7GifVBMCa9AEHrC6KRJSOhewRAr#5Z2&&_F(v}Ioe@WoTqY-+5<Y&
zcJoW{M8(zUaX~nd>~WEDaH1wNk5wzESeWtvh<-YTiZIC&(86nJFaA-TywopuAUh#G
zX<;aV`^TGg87RW)J{=X`HH-JVrG0l`{Lk+(GxxKr^|QY#iy=j;1V{LF`@^(34PyhC
z_JxB}9mr*>KI&CT3z?bt1mINDB96r*i_XUV!kwvs3UWwf!0#Gf_Xc3ebY3M2ebo7{
z4x4~Wq6UseDzcF|q1I}9&sjf{4ZlzXjmA&0oyXm0$)j5K9=;7B&K>tmJBGhIcB2N?
zPxaZllGl*FB{Y^3Y^G=OZlB?Q>N1HS$K_5&p*Q(5dr(!&5pQhG#qVpT+ig>*A7}mj
z<#5_4vBRck{U;cIGOUYNly;ar!Y|rcz@iC;s$pf3$|7{Un#pz8y6A;eTVS^7o8aC?
z=Czk#Mzi2YLxlU3;A|14VlgWe=fy}uwt)CPn%c3vB+@-o36bm!lkV~#Et|<JpLft<
zqOftbl4h(Rk?lP>en*}wvd{`#jsfuzlZbq*Q3lP@9Tba5ZRv|#2c?Z-rqdDVk-F9>
z^qmx_?_G`(C@e*W`0`eGV*=blyhfB$Ii>b9BV!yM(vY<tr1y6d3e^VyQzYOz58`xs
z8LvpXc*7IXatp~AZqsu@DN^lg3zq{|2a%o@L|8n%BxH5)EbPWOT|D24u>HC%iejOr
z^w^*JAtll_4az4RtnMgqDYslWyL4bUI3=L5^OX=Kft6i13ZNX$I4sQca@02z;D$T~
z3)g-L5X9BTl8v?rat$!qS<FPM<Yc#qwBGU+xh#j33X{UYt1Bb(z)JQEWUmeJ(w509
zJk0X(<LoWVp+84`Lydy;)1;3?U#4=u#HaK)wy^2gTA3C<b(S<(6hHaWu|Y$*Sh8co
z_tdwpdO?K&G$FCE?z*~=>k0g})d%X)qow6h*}IYgJ^n;JJoOS@F?O-w7RnBRuGQtb
z5!b?7Aqt)|cfGFFhvgYf-*hl}4ZxF!QS$uzKR5aNwKP~*<^P^_3S8QR`K~wTOUjfd
zzuoa0L@eh+ds3G52By8aUUQnJfg^KHj@t>YB1J%0RuwT;_idUbrZkj$Iwg5v&{&EU
zG#^x3T*i5QA^XI@Ttd{Qw#Zv@#<Z3F5vyqJE6D)mtMxBnLL54&F>Zhm(|!J|e)Z3$
zvsRH*nXzI;MZKI8)HnSP2d>Fwq=?=YGF$R1H00mf5QRd=F)ki@;6(Ez)w*a2wRfdN
zaGGJIO5b12^$P!tuyzU=2}vP#H6$c{0G=FGDo?+onrEVVS#VmKJwKcC7~Hn2^kyfV
zE`Xc%A-6|pL=scGOz=*3v@Q4$S-I{r_vz*UZ8-fnm1%@{pCWs(dpPh|_7+F*n_Nw`
z2TS%7^*M!0@D4U{VG7j)IRbSs3y%m^4hahju;iyBZ=FZ?&fSr0xjFdk!lB^QG)_wS
zp**A_$=Cu3z2qLfO;{=-)-XK5AR(^)?|k5oW@d%9rwCqK`;=R@Hjh_!Rz+itc~y6K
zXZ{?6ZKf5-a1MLU)TdY(YOX-oXaq9*xVW9f{)M=ZFpmNkBBK@Pc1>1ZM-N$_ddP00
zhAFN&e%;g%u{V57b2hayHDDF~VJ}B^TzqLeW@R5u=+stv))K^dL@?zTuhw2(f7k>b
zPY~y5;qZS^&a0?u7tsTr<G;b9Zz+nL-fO1Q)sB%28lj1sTMh(>qZS>Fb-6tATI87W
z1EgE>Tqt8N8}?PFg%CoO@!=;#=_&#{T_|1l<?&ZBf}2Hm-1d%AR@E1%q`JHjk#a=V
zY0_8~oK;rsrraYk)v8~!j1{SwQ$m=ZV3pniJWYiP&vPR^Rfo$$Apux^__8!HY)3fp
zmPM-SQ)R9KxUk7XOfCI|%>L!qgUcp6WqQT|j*cu%l3%FWN`&lb`6-R2I(MG)Np^mT
z9ZRQyL~U2@u1Tq>^=~8#A42F%^TT-5#6l^JFYo!trYxYPqNVaG(W%`kWUsV+<&8Q*
z2V0-hOLqH^qN~gDywb0Ty!Ys<+N34`+gr8~xv3%+Mcm@S&G>;qpFRcP>|f2*#{M{;
zqID2Qp-f^upL^g%U@?&r@fo4Q5}zw0rQySfyhe|2DHNj(t?v)#E9g}JHD}*R$AsmY
zuCw|+Q=$0agM*BYI#K-5o4SR3gqlTP3mLgbcF4$nn|D5y`8wv#0sXU#*h*r)EVfcf
zMCpYX-Gr#vMgnFP_Q;5^mVV@tJ!bO6iZedD{F5<LrEP%Xm9+|NSJH~~BsIIfFfwug
zM6zC`H!98J`4N^SiX8e>N{J$Zs##3clN48jN%p=Z(@)FzypUgQP@oG{2%}18()7Rb
z7@0$YW3DYM8<wZG@W*}5&;;dkU<!|gQ#F$nT!^WrjbOGVtuq;)bpBw7t-B6_nw$@y
zgX?m(l2JmYn=XSjlIOl|s1=A8NxK!pb|Jkg4MSAu-+>Mr*7=;VL59AfcXJa!q;=zZ
zF!qOYG~fiTi(@8b$&;Iz2@si`@z1EqbNegnGwZqT+XQ-{Lg2rd9IM7-XAfyB4u41{
zbug>?Ry0?Je5E~%L~VsE)N`NGvC2Q8NrSb<@)?GuIj98vW~7_`Fn2gSFtGlE?6_|U
zDg_UD#zTi_HTZfYikxaD`|G!TvOOi?@7v*;e6Po8x%zgJ64KQwpZA&)@RVmX-y9~g
z?+<*#U_y}xExzqE841@!H<Ev0^J1<AL}KDwWhtwoj?%ivcTaMNy*c==-zz=IH~NYi
z8*b(~|2o>-ByVnT&SBvogTE!B`MGBRvR0`TrQ#(RKy|bKIMBnvd(B!8tS7OpSPG)a
zM)_N9K%NVWK)Ho&kko%qLM{;9I>*YhSFyzKdV1K2{;Bie@I;u$g2hWtHG-5vAhb2<
z{i5RcYH%tEZtnXeH%n530GnDox$6{p46f@1`1JCvK72&{*J}pGQ(3SC;q31gQO7?e
z&vz^H5~ZY|V+Sj2KBpf%&;;SXN*z<F7@AxR)>ThFy>XZti(q>3jr`3n!A(`pBdvL&
zv;i2O_zI*bFNevLDaLcY70c4j5`{(G|LovgSFCSMY6s?%PQGU4AD+|*vh#d$GjRGK
zOP_09^qFNknS+j@=q#sHaj^KZBF+#TfYy_`C2oeyks8@LH^Kj?UKj3(drz4*Q1s5k
z=>4o#sr?+;cv8532DK(3;&}OkRD~uOgQ%UT=iAh5Io~#@oh4{g-%>=r2h*rD3IKL;
z18G!kX`J<dSWWST^=e-uC8NhS?)eC*X%`qZ4ZI{w_^Jiaa8_+zDXhPleXdf#XHyJ~
zINjS6vn!-4fJg<ymn+tFEl~dF&<yLJtLHNyv&Q%&vkGN1lX$P_Ze0?~TtuABy~mK!
z=p?g7fwX^ZzSpDn%c^05;=bxYweqpGd)yq&<tY~T-SQM9ypE)~g!hTrSoFrvv7YkR
zUoViwxu1E)vvmm1So!Fx9Mg|Ni1?)<1K;BfUZpU;qQFyQ@?+IMhb+REf=_9hFCTS6
zBP>=y->d>d|6X7}(}+~IpRBB)D29prDsf0}^{Ul(B&8U@Qg*p6?9ubRJn0LzBYx9A
zd21_Sy`J7x@wH5hP)nuCFw^OPLR9*AEo>I~=u^@@>C^6A+&(Gsa`^`%>-a)XkkOg}
z7eD<_;Qa99Qtyp@sg+YA*pGD`EYacpt6D*GbH0CbJL-I-Mx47P6)2JV{fya2#l^*1
znIz-_rhd8@6Qc^Y?&!Wgyjfo*LbPT3m$wb(cvaI_V*UlsXldw9X_&~zZ^u<d%W)BF
zsb4-QVuv#6&=ADKQ$7uaTx=X^xo6Yc*crHILv9B^KsPk4J~wdRAvfhyHG{Swm5r4F
zQw!ghn2syYO~ulES#cYm!n4YjH;SACg7#)Zua?TDm*WVJL~c$Z?k)pwpEW>t_lAwv
zrWEpasu<1G7w&+pUzX%iYImhi`40uxzB)*YuiTnUw0J-53z#8|3mgs}4st4S)t1KK
zM~X)YLV9_6@oel^e^-6iEWbGsqb<QpV$}bgkNXD-8#N~7+FZiyo2IzGX+8x06c#-~
z3~0DnQlx0Tc{gCl=f5uFz=;F(a=8A$^XYYiAVvhSah%01l6wjO2#vO=80VqC-?_|m
z=}yDT5L}Wdn9?7(@f`%O>0jUVrl?4UNn(iJ7b(yL$O3q&r=>qtFwj|6TuA`S(En2o
z?3-$|wB9d{*JFmU8<0G8bJm|!<H`Ri0EVS@i>)KW!*>9zIls{_Tnm0cif^`AaBwk#
z6CgA=kvuut5@-5#dP092=u2v5ubp;}d@@9Hoi?$Sw8r^u;ujkpZ0*k&G15z(Q*$E0
z*y;)WBH7E}PDwIt)1?oFHAV(3;M;VNOxc`2F>&8ysi09aw`em*sB$w;N#OUg@f&ec
z<0zng?}Kzz;GllV`t0YBuj*NiRRNGzp!bla4e4NB1+J=n1s<pB%k59{Umtvn77p-U
z0FFcEkGuT{o6!b8P{ub~(mCe*j8nmWND?}W5mb{K=}kTwzVpNSyf!E-IU=bGnVN?7
z_;i$beo=MB+*`-oim`C!rH%V)`Qv@P2=~E|@e~on$U{{Q7?g%_wzvbXX`1{Ov0+}H
z;Fk?ZeBZVJuJ99qH03zY>}4F-csO1|)C4A9r_OLQRa6#o3|5|yD0&4Ez3`6PNRd2;
zeTA<b&9+P?v0R5YIkE~6owy1om`-1Wq>mpsa|FJLmDX~1{!T@8>Q$uLv2|ZR?nGqx
zbn!rlf;#jE>Tf)MvYa)}v_GrZ6Nx+^@`VU~F^wg|%*cCV^KNtoSF70HY?s%Bvl@rl
zzUoEoD?}X~<#wZkxv{10B|wS^RTnl%U{KsW05}?QF^Wm>ReKNfXAHIqV?EbeRYMjk
zvH^=u3~h5a{6WZ!ZU#=%ln~6I_S?mtNP`P8N_*cn$mR3ky>AXRs$sJ#N12+~lQ^%Q
z#HI(d=Ev{;hMeIGo2HyhaFIGXTmgvQZ)~`4{898?=MdzBj0vLV!XGU{4qAHYjBM%+
zd0r!mP3tc{S0mu$i5<)eo0`DS((gUO@wR~?i)YIK&V??^Vi*3!8a8^BtY$mPZ>gY2
z9X%D%oK!Lm;pHZ1!}$Xq>x0?89pdXNW=P6&xA@Ug9mSsu957a~PmZ3snRuFdF>eG-
z<}0u0h~7SeMUh)gwJh2=v(hzzMZNand}ij+TVdxVa)5G%P5B#^3#n}8oOyH|H8&Su
zvYZ2p-0dc?ZJtE154Ixg7Hg3b&ijeRW!jLpj)fn#ORqDw-(X4}z`Dpt<eD;V{%1FQ
z!+160avli$VCM0KgVpfCBSu@uqLCvs?X2&coKbPj(n_P<3-4vB2GHBJw#3mgplBq4
z<oP?V&jW&xRz`$mBMW=xmu}~(?$g3X+qU&>qTe#%T&{)cUx`&}L}kRIQ0Tv}c^Ew5
zMW@tvzmlM6>N)t&dmR3vhmK$hJ^yFGTvCy2yPInYI8r}giFZt~M|KJ~2C^OaPFR0X
zG;b0t%*5f~UEV)#IbKaq__x*C;tc!e>(2xht7N}s_iYENttc<gW%@HH4H#U+8bXGs
zJ>JytzbVO#%0yp+S|nVG`TaK!#C-AUi;K#qavK&pIyo1<$RpQ&Uz8btcw}>8g;W%h
zJlCT&Qj%*+!8{McRgDTn5YLz#g>qYRB_Y-)&-^7K&u7D{kJ0`WJ+YAgwS3FiJ4D!u
zP{;_okFLztnT@OLMU2kro<q-faI)A;k^_4O9WF}M`V4zd7L~<eMjtV>jr)=nN01)m
zbP)D)wbA9z9EkRk?m&aw$nRYCb!Q603pRXU61CJ|z<hF33$$t{&%cITdi0DUag?fB
zOGKitO|_ca8cXt6q^@~|nZ8<?7xN9;{=3sCxuAlh4ftI5K`moof4Ke&oc?rikL+*R
z-%(r7kh6RCE)0UDt@X3BF-XZ<s#z*$Dp%8?Y11jSQc4Bz=Uy=(hK)o@4mKFRXz|-O
zYw{hO_~m3R6$bG_awriO{RvY_jnW}IY1&^LA8kyvKgDm5RjN$sYF6Vx!weNrZZ{TT
z?1t6AdU*%w#EcsNv9x%_{FT`}eU83!B1Nv7Nu8<=MQS5>iL>n`V*UuDBfa9|rKO-p
zIEOdq|89d-Ct_x=QlD#yZd{zg*ufBHX;i1xClp=?3K_>(h{Mcc+BuNowi7YVH1uFU
zS8xQ6Zz`kzV*!)Z(`DIzWNk(OOO`u7s5CiFLyQa=11mf(A!P=9{zMU(rJ2XlLan99
z_A%5uD+%{IA(c{A-~LA#yl|-g=|tz1kbbViK>63~t%j{lKARH08K3@U^_OPMX__sx
z1+LRQHk#PE;*Fla;#CQqq*YP&xXjF_8tj+9wcq>c|H77qD*DFp4{8&Q3N_!<sTzgJ
zX36QOh(a)ro!%Nh2qpYKR>NSZW)Kny_?0@vNtopyq2oZ5_jHvC^_1FGFyaW>YS!GT
zM2iuUpAvRC5bpNxH;v(Dl!rL&OH0R#MKD^VG!=P1Dr<jo$_?|S4u!%tOCjLjvy9pt
z##$?TrB`UgyiQD5%e55aS~MSSBAxk_)GF6U{7)8!3k{nKnR20|_KCH*uIPo0Olg55
z35;-QV;Nr&n$;8>EvgkLYJ4YH@MK!!@kP&_6D-9MiAq_y@%VEBiL?l1vb;?(n^=qv
zIZRy}!ou^rxW80<*Qm-n2mD}K_??)deBA;po-@{{WU>#IESAxX<N8RhzBo74gqa~j
zf+qDyyOHVoB$EDMMb=C9MCs)pq=R_m@Vf61#%Wyf3ca2kwP$gDqj{V@yASG`I3(Fz
zyc_gu@R38Yn@m1|x)8I-d08B;0cD!l0WrLun;-{wfXWQ(ZhU{jPoT-=H{*xAN$)v0
zA&oP`GqLX1L?4o!M)s~cPCvKS!kVm?mmXp8CI1H-inoxO^XKW73*Go*iDEw<K);xC
zi=3Ll#=Y_O=pOVR1IwG_Zow!*SAR4iSL*w%*Os69{^66~E19fBdtKbkF9Lxyl{F5l
z3KAi3;la7n1Yf)#Z7El8LV4Qw`gn3!4@1YtH!ii0@c~ipuBwD~U(G3E^y_mkc+^%M
zfJ$|t3QUZePwEAnSm%71dNTk3dh$P7fWO}U%WoMC(cyLlWQCPP-2Td8qEQN_Dtwf1
zO0*<3VUnLnDH71Q$O_2;N``5Xp!s1n$-f)}WN-t)U-LqRe{7KL$P8bNNv4Gtl%Pj5
zH}@mE>e)XZQ0m;mw%k9nFg_>xVGD()3J-haDob~gLl^#lkH}Z=^A2m*>K7wTfM8Q>
z%-nA?DSxKHUWxO4#+MSF{@U6BuYR!ddwhHZ25#8EyuPh47SV&R5I8t9{Vn3>C0_S-
zJQ#na`3m8z^=_1=bO_q3D3qTaIr=<BaQ4x&t=nLsvB@Ew9=5mK;zQ9Yi>(Dhs0Ht<
zOZ974_;%g37@2ZiM&0M9U>#91=~D}@-6|@}i!#MJ>f`e&5=?~c_wbEKfsM6gcCqhI
zeJ>dsd*z(`2;cF|_uDZ^VaH&z_7`r=p2~)M^&uGLL%YxP^FlQ72QnCL31WRR%Dv?`
z>{8N!0HLA=cj9Q{lJ!%BidaSQFJK3q>pvzk=g4>W=IxW`S;z2-`n$TBCZ429ZR1j7
z!6=yFA=;h*&lvr8$6tduH==XmUyDvjCjYln&wKe~iNkC4I>8uE1vTvv5t;p^_FH5&
zYL*s?Rt;&+YxLu6!EXwW#efbpDU?Fzj@=CMB+8qjFfSSc?LofcX&oawk#Dnej^6hp
zTmexQ`B1w$XZCkoCS|skO2m1HaJE6+3a?>eVmEL5C*iRZKe-gO;!0Id;Qyu?Bny(p
zBbT!+cO}1jXb+FJP^ezym}UigB_dfMPOF#k;OoFh3E-#@*~o(;KjQ>_!s9pv7<X6e
zZ{}&polIpFOAgC=jyI3buQLUWG=*druuj0yVceSTq~z&ib*q5_hN02`#r@rpZH^BW
zrrooYmW@y2Hsx9GMLFXoS)uSH3!<VK@&%<#HE9F~f_7@T8UhR1Z#;^i<KZ7)qjFN6
zWoh~he|Ux>5QIG{^jn4(_K!i~KIAA?213eJ{4v}7f!xb?AQZPM_628{Q1I;`X=riJ
zl3+R-C)CCB@5x4)JJ3-MoyVZytBL)q3fGOH6J0B4B`=%>&4*#Eow#9^GfExF)f|xh
zcHOYk_rT~7J>k<$m4DuVRFDX|qw{=EpUv*?0{B2LT6H9BmkI@&QJZWj=hG)u@aQ`D
zZNL|xK<hPE-`bkTl&Yeq&>YWuH1To&&1dV9|MOdFmk(Yexx5m5@wZo$os+EW`gCG%
zUZB!zJrX{DD`j?!!DqBL#fnJAHuLivJ_}D4r)vYy=MF2n&EMA98bfrpBKK(~S1Z?O
zg0#h;>{j;l1qo&28IhfJ%L@*dQy~8>9rpBC|9N%tBD?5C+I|Dt!#Sf%i~%9Cy0-G_
z{D-RBI6(noncy8W?A(!0Td|VW30QX0&GM=hnC9s9nqk<?MyVDes4hqjLOIUnZ4^lb
z<d|5=kxVa6L}gYW{v==A^QMYxkN3ufij9z6DmgQ-UrCSGiE56W3$2)?sI3iS3$ZGf
z;iJiVkHJ}I-VPW(=Z!{ikZY%^RA8p1hN#*|e>{#agn9>Kd+Cy9rQdGi-x&xeI&$|x
zW9qR{6>s(?-euO0wL1`GdZ<&~;LE0(Y^tl$#|TOS2?gdJV#&WWTGPd1$IjMj&iiH`
zg@4%#airl0ofOosCEc8P8^cDRc+Zz`&VufKW#t`a6iMt<E?(GfW=GJ8PjC`SFuocK
zebq2SmmR@2R$u|rzE>!MI7^#vmxx7=3K_SAUiI3xR^K6q<GMMjb6wo5C*h9*Fua%$
zKMvNDvQi(Fx{w5bnmVmNLK{tiVM360a%E(RO8*Q>D}uYJQ>97lavF2PmRxr3TccG6
z>~{&v9agdL`{y_4?pCUA{??jwPq%E(;O$<&v+BV2ZTk<Gl!(7&lz|k<WJ+qB-R#^R
zee3K@-hZ$wR3hvs+fx!M{>K<o@h6Qk(s>kzc89T!8m8?C+}(JO^~J6$NQnq~u~NTs
zwJF-KbT1fGij{<MI!j~VOWAa9={wanw1!fvSd!Qi>syCGu`|hbzQgfYTC22AL#pEj
zUn_7`3RmKb^GRyp{!=3qVswk>R$vpflY`2!;z@Dej*XQ>zKsJO#`-AU+nY4U5E<tA
zcQ8+1Bb;lUx%<}HuUpgOKTC3AKRS;!FuZ*Gd)07rNonYd3=)UcM)KvpmZ?#f@?cOK
z^LZv0C&>D;l%a^dP{I-X#SHg2Xa1Al4TXZIRa8+aS5x*xnZXBi_}pwRzk)7Kx9MAN
z+XFpHXnc67;emEFS+jBh<29m@Q{r(J9cE%DX=Ba%QRQFm?aj&K;lIh4gQ_#BtUOSs
z`Zi%?J!U}HR)zHkQ@xwwYoPF$sdAmqvya)%j^|?0bhUo*G1h{I7LNo)O+oK!q8_Mw
z)y>WA(b<~U?7u~J@^v4qVY6e9wt@hjPL=Z?mjm8I{HBW~9=yEjX{aBek*a@~u4kAz
zwOm7^L)9J;6Q8!W9)aKZNIiH3&9t(PXgj7s*Z4B_v;%eje>_0_j?}#b2xd=NTM%28
z8APG0;;!pyg`#`>WFqI%!-;Ab_?f1PJCA3C0pgI)f#Zc`v0L}IS(C8heNK7ryA_nD
zSXjP+gIX1c1n=98m?7$xL=-W;SR>t)zegxzA30Em%w|{#K{H@r<Gq{Cr6qjjO*N`y
zFO5vp<Nc4-NR#CML^?GD{wvaXM9z!X=AV<YsOjt#T`$r9rC``&(&ON-4IA8w;Z^j5
z{xfIIAzOKlt;1hNfv;EpF$AD<E>r8c&>m<G?R$7e-OXv`70}A7K;`7jKsox+7-2C1
zYJo|U8bG}|UrS9nM5J`~L=?dZ#K55r)o?p&>|IXEn<yXnm#^Xf%h!yx2n6CG5!~3y
zP?@LA!1|>(7X@%r)N=NYP6GBf8YPa=W_K8D)1E8gum20iwu6AzeGGypxZAg^btry%
zw$wnIg&-Vvq~G&qUg|wGQGsu-&JSjW_$h3qm7l`-C;`hujNzK<(BH8QIHnhD(r)sx
z_iDak)@vs!_Aam}L|8>J8>fc1>pBa%YF)I8?dXtxW+F+XBkv_AGMX`^e*2#Qo8YDE
zzkp3FBzw5KB60z3M0*8qj6U|~ZZ+QqCw4iv%Jj;YGT!4;&@koWk7|0&jdwQp*1ofD
zIw2<^59ZzY!WmFgbEm!G5djT%B@9UPoO7Fgp7sJ{ParYQ5ofex!Qxd`S8xz=!+mXL
zWAWL&b}X#a1R4765k+6NGU;v=oJH=(PF&m3>pp=Edn>744UKkmhi09&;TG%CczZv+
zKV1X=^YbK@k?6_E-ZIG~i_MG*l6tC&jor2T-2xljVFZPHwL?Cze|l$5`LERFfdp85
zv7h13|0HR-*C%dVCYGz=UhV%W_x~+Z>Ah}8ZFxm>vEsm6nK7oe=B{BHBQ*ezi2XDT
zK~Rq;PP6P1=7kC&ohDwov!YH~x$|TGMETHp<F0}+m9vpm6TE%iwM|thv`VMa@(Tt9
zpt$7Oyiz$E#Q0^B8=T=)_YmyIhIpzbJ8AI&zj^c7uXYa`6ATo~R(ULh9vWhl(oz@s
zuBthuz8CwdEX7EZ_?#>`BrPL+{uuZ91d4MK`Sw7M*xC&DPHgZ~-KeP^LwJ(L2$1En
zy>LgTuNQ-P*wYsWJC^Amkj1A%@<5y;nU<kW@jgb>kN6hLz!K6Yq%m7Dd^AKO3K!dP
zTN&r^|Du=GC7rhO!6ja@ai|upNB?)X>BK2JFcne2lnfq<tWO=xHbvEx)-5^2b`QqQ
zteL~NJaJp$&k~O7gQHkQl-xl>RH83kQ)jd<eLO{zVM4o?u9{|igxZQ5zxfl6)lC3G
zCP)W4u-lbB^)pO9;l?yq<0xf!vD@5L-<KzLxsPOD{}-vl>a5O&f$-HF|BL7_Lbak=
z)Xv$am{w(B!eg+iNLLh8-5NNT&h?0?3C~P08bNtv!FjAiXkH8{gkJ1y9ADdUkZ%3B
z`&B{y412z+M{ldspxMsmhuu07#&uRzk@ZSj$6iu`&k{7C!m)Zxl3@L${O4rVA!!&w
z=M;stu!YX*McePGW^QeNLn~=)QO_@mM0J_4Be*j3?s#ghIvFH_VXk&`E~}U^6Qj;s
zDf~i;)G<yuMH`8CU~88)jU2P68?<nX!7qLwI=gt3W3}b`iKS>8@hBY|AdX}gj#zNl
zojvlYovolDW)ut_R8g!`Jki$Xl~{#soN$12SoDE-xG-jY1Rbi!v26*=@6@rB-H58l
z&n7H-8?_9nEH$)=_v$IKEJ6Q=869SorUJ`BZGwl6F4QEs%X$UWq#V@f$h-W63H?Cs
zU+)!6KCGtbUIox(Z;!!$Y^=Ti)7cp}pRm~?NyNMG_fz+dZ=dUV!)RqC)$E9?gi`1%
z&_c3pw39)@YQ2JXR@6my?s+h+Qr(-KvgA>a+JO%ydvX3PoEyVZ-nwCMDT$CUTdJ5d
zjpFGXw00CnZ1hhF!;cf8yZn;dENing)4l|4Fl<O*ilt_^`5)#sL~-zbQMkcf-H|qD
zeIZI(_gWeY*xTf`hRT{=!8UJ4ie(E;>o&HTZHAop8|c5QQ+l)e@}N>^WZ<C)PfzwJ
z0cH>6Hlj!_1$QK@wdI25K>qGT%YPItd)j`hQu(b(9>|R3H~ErPaWxeL8?KuNQ_2`7
zqLCPP>x-}A1x1xLKuH+&#S8<89*=os0IBTu)3HJ{>MgeN8NVBSZaYr9?)v@0UlbLi
z#U2_pb9>)N)Bh#AQ~4hPL~K1n>hUL(2`;E?SywlA*r;fgGbtm*`!_D(G_OHG*a`{x
zwx^nzPvP3y`qoizUHs{+r<YIPDR(;J*y+_m;j@}H_PXkB9gPFn+x4v{Gze#PC&8hv
z<kXYYG7sc&n(E5mlQLUX2S-8|MMx^%1)!<M-Vg7hns<`NJ@_eprKob0+((&W@;D*F
z0l}<COqQiBMy4vEAt#I+b+h=m;(oaidH9D2VSYfo^mtZ&=CJU-+=@&d6DOs=`#t3l
z=RkyKs~oR~>`Mox*P_L$wB{ynqF@A0yhNPl^GU#?+R6O`Zw>lO0u7y1i^a>)bJs5T
zypwdZy14xcSM=pZ`oF8+|C=5j;()NARQn~e45rXH!-OAKhjGe&3B>Lry$I4%($gJq
z_c(LVV7u{eL#_v316ud~)HONwdaDvi;H=JpkQ(v51=Un<+5S=3Kl+#bzhw6RW#~;k
jPXywCL(@$BDwq?hCoK)pn}7eK0U#wVFIFvL81#Pu`f=P!

literal 0
HcmV?d00001

diff --git a/doc/assistant/konquerormenu.png b/doc/assistant/konquerormenu.png
new file mode 100644
index 0000000000000000000000000000000000000000..747bcdd0da8f03fa51374a3b97c5d7849a4bfade
GIT binary patch
literal 27159
zcmce-Ra9I})GgY$1qdG85?q1@cM0z9?(R--hv3$@ySoH;cXx-z9s2V9XPk2%?s>k|
zV|S0Ly~pmVRaL8&%o#2(D~^nahX?=wkbg^vC;|WwwVxL=JmhD~YqCe&=MRFtgoYCU
zfYSfp1(8IHg8$hF=lokn6mAm^3xkv#B75QGvkBK(RNYzF&c?>X))^q|Xky@OVoc&@
z;cQMK{#!;~EdT`v03ZSU77<i-Up>!qQ=cEkAL{<yG#iO&kw-$MKd@Qr_23%;^nCF3
z+&o#CtTN;F0wF$JZmgVX^lS=3h?Yi>xmf+(B1Rg6Y{v}Vq8>lm+4*fsIbzIwJHef>
z??Vkd5+wNw4-Ejwl=%ygd<~;Ohlhro5rGU4AW4__yd#2v01X*nPWD;<D)asG$-MB-
zx&UkZ{|^uUufIJed0ItGOisqe!z+`g>he}ItX-a)n_FH^)jnjT<l;&<S@Et{z%(&1
zFtD_gw2X58?4oGjT(O*wj}_L!=H+^;PP46!V_G*slBCJ^_!_z~cxW*(F}&xww|=N?
zmK-V?Hnt>l!+7T)E|*ixh0Q;I{z!;Fsj?|Bq(HeplE&v+09a+5(z1|wP$TlFCFkH8
zH~#KDM@^30raJ?VG-7D2j4D^~cgA)+K8y_WOjr8nF#$0Cd8}%Gjy$e-3Uw$j6~rYZ
zr3<JLF-2!svpdO+*ArM9E9a==JUCgA2!=E?6JoCDt@1)}s`J^@l%00URmytm2moAj
z>@&e5iJ~$Y({yvJ$g}*Bm{PQ~F($YH{zVoOE*@ELt3fPG=(q^MLP?4vP>><HcRJ*~
zM`&1BNe=bJREYLYPDY$DvyHPZAgwfd;OIFDra*j*JTt38sWRtE%8mySCKfK?)HLhV
zHD=brmy&Z1F<8v0>l~_>Bix8x58&M9PXtjBN5{INLwb5T)}?Lrr!G0WSvX}}a|@HC
z%tVoyhSE~%(%ZbOIw~Wh{1bT4?k-h&5t~?^tlYF_Bxa8i=D@9Y5j}#=Sp1cYRi02O
zq94ZCZHMc&G)n^!cYIz0lvzZsJ8&tCJmpy+Yne_otTh;Bs17o~f6oKBM-}lGK1h5I
zl55@?WPDyRLXI72!i-y5PId-QqarOGWja58%_F10BV&c%RK<M5RhKIK^|v?`Li%!p
ztV((jwSOKJk$mYwgDWJ=G+p=r8SrR<ZVZZG%z;3h<;&EqKJy{QZzU>CMI}X67Ifyc
zC=-oB#ovLpd($>M8^KoTRYxW~q6*5UN8d3K7Rpufow*>(Rh7~RNu8i&5JZKp^fi*<
zrW^={9KQ7VPo>L$C(QkBzPmTAmTBr4v`3v@rm>PWmZ>$btzRpl-X)WzdlBMnu^48;
zN!s_MdfoE+6ik66s(>l8aC80ry`E|<LLf)6wBL}a@26y;;^(&OxpTSgPPM;Q=*^eR
zlLWBF79fa<x{Cy<ZU`s<v1sd7xc|sg6&%Ws@uW1~T9hBEL-e`3dv?JiPc(d|jws^g
z<@sF04?~kQNlqI0$p=*Fo*1_=Xg@pBCprdkk$d~s&-+h$Mxb857Z-NM#Nhml5-N0b
zs9A_=G}`5lvq;Pv=<gRX0?M<}CrKz<vb`(g$qjia=%UGy_hTCZk6<7J5)u*u1EET*
z$OJ1DSC&_A2;d?jVq=THg&4AM3l%Z1s?SM*=x}E&MIx9v*%@LCzI|>!E3@JgcmxE5
z0`f#?8D$z3gZQ*LD(%4>>HLsYYS9pE8r*@*N^b5&yPPzYMB2oic&41s1=Y~}+c7#4
zu~wr0mPd3>D8L^s$g+{iuF33?A=xB4IvTVSqs{OLngi_(#THaWASOv-5fV<Eb$q0;
zxlUTI8EPh4rnfwe_D)XfXxIZVB~7HAS?^3Jyvx&<3vAia^S-4oj>}Q2SO)m#x`ccI
z1PLkB2|d$2TnF9ojwUs#(Wq47FU(4lLz3Kvi`vzfEaXr{>_J09Ox+TUm1(fEvo}?A
z_Sq>Ft*ot0WpTeMDgKR=;#5=<6>Y?0qw=3Thqr7@AMswJ-g}o9=ndm5pk~0cBR=Qr
zUFlV*R9vXi$vFBIZ8H2n8}oYR*8aF7Ri`}S=t7({{q_6QEvw8@+3s(J21$z8NZ$>&
z#i<NR`l~Ya%gH_YkX+7~rRDGi+V%ueVTC5FT=}*3eQQr^$IrQxmX*A&JTW)38mi6I
zu7XAl5D+*mD}hHvn!A7p0)eEYD_nnyiz%VRlE!%>BJ6HUFEzHbWNl@0b8}f`tS%(o
z+-A`b|EZlq36(0YX=*L2Yb__$CQ>H?_9c@#qmy)SrM&QIWe|sIhuDd%cVBh1mHUZb
zA=$K&YFV3WnHh~Ns+7xyStV!kJc>$9RUY|txYL^~o+d8c$ZRPoDDd!ctF;>)ueSf8
z67wjRFBIfOxSm^o>hI5DVNv@0pi!!<siC2vsrmVBp*WxUauQ_LXG6i~N5~7l_MT8Z
zOe<0TTtx8P3KMnJ`FjxdY1wC`8tiX26}ChnXhB`RXIptmjioD>`S|`@4O$jk@T9^a
zdDgUFptfZk_s8*#E-VpMT$!wcGWVVW;ZPk3Qc|Dd^TIL;$wEw4T3UV`dpD2PS$`@S
zTOuZUPr_TvxU(GQJm&7r4;P=5`_)PbaVpOA<6V6zr9@NNxLk|my;1I!vm(IPpF(h2
zXLU`gd!8=c?vJBQ-C$ddjg*656Xlirv)G*JD5ms{l?)c&@EkhJaun!~29eF4e^63N
zeMb*5_!e?~eNFnI7V(vvn>!+p)#=aYu|uHNWUaA*2|(Ahwz09XFyb6FP!`bciJ|0P
zU1{F?6|>}F6?!#cMFub;FFnjFDk!wNbSWCd1$F%>ETT><>mN>KYe&gQOTXq}l*Iu*
zA7!VMu`QM5Dpo$+KU}%c3RgMABai`lM2xwLPb@vsGY=M~(9ppQn-dcgtE*glWw`ii
zCGr8vYG`Chrp`fkcTq7pJ_xMz^fHBth3l%sF+9e$hA2dvpw1K>E$ltK{46Y`QsvJT
zW-=NVa}{lsC(tvDiI|@E3y1^%4M3JFP^D~%7b-!e-g$OhLu%B{YC(n;37|?G9jew{
zC{_Obx}J9Q?3_lXKXjN(ul0BA?cnDZ3}WJJ@>**RFAg`38+OCmNwpG8#0he&iS=Ls
z5_#&RbjBPQ$bUP1p~X+&&B^+5bt>2#eXLk?;)VLsPsL~>E>DGt&tdzip>vwS)iyWx
zrwirC`0Rga6Y;!a4bAO49>}qy%TZ&F{4^SBRc_Pq*+FM}YT??VkULV}Se*$<gQ_=V
zrJoWDp37p7+(U9JCnkQy%y~+U-ysZkdR%|=O-g4a=MaG0ajJ|PJNo^@8!BBwDKWlQ
zIp4>z@b6US_L4i?j=Jnb9l=z+C01(?G-U3+71^hvZ`34@Nw>fh7@C8da-tim%hW9W
zo)RZOf>|i|;DS9izC1iHVQKlDEm@K^HiJ!0?H8fOzK1Tg92gZb#j*B#b677>XQT=l
za;CpJXushu(ODy18c2~qSzKr(HUTMiMZ<S`wGgQ#m*tuLb?UZ5@tU}W@&1wU6`5-3
zNK!>`iopr2Cu;K*{)gYW^c-0L03fPl$wrHgcp1d!g@;jfIR85NPKb|2^m=S^^e};S
zW4O@oJlvNf2~8eQ0C~)u4!R7CxF28nHB1f=P=tues-iux9zAHL-Il%WD4_5D5&};X
z)|<}0bjcrfNBY@Ia4dx>G?u<cND;Wz#cF6J;eEB~y+9%{^&4*5Hzb%(14cu|f!An<
z4`xf}X024qG@knKFz@aVYm)<CbE@OIcbCUP_rZE^!~-HlmlGl}`)n;{?!9oc?|yVQ
zM~eGqQ>_aZ(S|2|VX+E!-9oqFmGaY^JyfHE$ba@n^;ag-t??-QBeUknC1XgIBhpdZ
z3PX-LJ@C9T8^Od+?3RB0Zrc5_*c+t$u-sRGRW7GvS@Es|v*J{OLF(#1%q!K@A{WOC
z1t`TaM*>K+A||xu^aFZ|1DIg}x&iYfsq7=Bi6P**YB0pVpdMf)Ap`*zekUjt0s>B_
z5Np*`-LeRo1Sx<Et;m<&0d1HSsx?-^4^|Aa6jjl-r-9SI;tMs7!K%8S#ftlI-@kHF
z7r4E+=Ia*Hc6d`-f#kAc!H+K$kh7Bd!=V`e*|*$b`@bUc%s=h4&HiDs3!^+mit>HU
znX0H~`VRMzX*M2Snx}c1qWo&44|fL_Q5-2!Kq`w5VdZAihv2JK|APTHl;YO+NGtWu
zH-{5*jBH}S)rmn$G1&bnnb808elKHULkzby_VnZEoGrnI=M>`Y7OI~1QTNOC`<PdE
ztVZpnHM@*<v$t28pwi;K)1vm@s`pHB3R#V2@3ASXRZF_YGz_att`g4#x(%PTsVz6_
zp2%Xr(_P9D1=yXcrJ^+mZ#hu2=B1WGC*$9i+xhy|={`dxjrCr5Fy$0~vwW?$RC5@R
zHid~D`KBZ;xrmcqeBz^CesKNW$bMVHB0_Su^<~X9l4II*vmg+yi?d5toFbj0K_e!C
zHZk<$X>K9+<(0z@+==UadhWvhdp&n=SZ>53V2uNNZie0xrHl6-Ze;`4yO(;HXjX!;
z*y;6~Lv{4nV&{e|sB6|>B2jP20zH-?4J;*;%?0<kz*%Fb=v{3jg#(CtWp8(3f%m6-
z`8dY)tEH|6taqRllq}E<p~Y%@u{U}71WZm?YCpb+SMx4tTJ8ax?pLvXZtuDtkM9!d
zw3)YA3(S#wmBYZs_)gPF4Asps9Mju0Ut9bOd~D)veQj52Z&uT-@tv&mw)}ozxR~8#
z(T`+x6zjRtdIN;2l)Kb0WOo4N!4$Zmg=MKbD_Id#$6L|dCLH-79r`?_zU?U01*e6}
z5BGP1Tb$PfH7q5UJY@$I{1@<j)0=89B2I7!(d9fOw_L4B%Aap}25I{KYO=R`VbMbP
zw+VaWS4fU5@2g+^?elx#WCjqJJu@CRcAZH-J+pN>?8nAH4Q6wC?nn2(4u%Itzx#E1
z+$QVAZaETMXAuCK3^y?4xE(SlSqfm3+Mkn69IYE4jw=tu!Pfi30DIuW`*u^gQ+DL$
z?1#gC@u)Orp*ys!f)~|Nxyf)U4{iUJU5cv)XfC5LKrPwYYNh{_#(y;bJ2@Bc6=j(O
zNxFJNox}`owoyILlv77|xU%JU)iUK1N0_Nw-c{D?a<%vUovZ<eyBF*`{)A34N_SCe
zdqzzr-?`wbd`fWLWBQ>QF>S8tKh?h`=G`*FeU7*&Qh05W<Vp}d)dop6b9#YNyzX~z
zJwHMrm+r0B-Nq-p;`38p_jwAIRj)4#ORN{&mC(TGirg2L_jR-D2T{_(gl6HUt-wfS
zQ0p;$WnW;@8V(UcjFW_d6yVgym$CckRsO&Pz1wwrCK?mjAIdPP@i&O<s|+3Fr<D(2
zne+C(8nMQ-a6BkYpo}OdIBhlz$PW#B_?qkS!yy)zkN(W}O_aN8sXe?_$#Y*uA-D)&
zTy59e596P})W`K20@S`2(sa_YDmE>r2?f`OFshA>{3;$eT4>q3@3UHq(Ma-8m|sGz
zzPDJ{$OxG6lQ&yg<0e~z1sL1?xt|g`mLg#Gj2uZ+vcYRp$79moO~_g7yse5QxDEIG
z>2!wwb9Fhl%GBoPYs?+Pr{*T>SzCL(+~CG5KIMFMEwU2<9^r<RZXYi<#DFI&ts?Tj
zaleJS5^P&5G*TN`mdi#VuCy%WS$21DlrEX<UutwmYyQIPsnW1IbxX_pZMRyna>v=-
zOx!6Xo$JzEHD@Yo&Smd<IT0%Rjj8%kfH4w6wz3^6jLXY-)Ae9p_*wdP0mN(w>KG9=
zi-r8!qVM%j?kb?-O>|FX^6#Rx;d$3UXjjLe=9i}*rXTyHEM7=s%JTg@ob3<ji$F5M
zD0xTL+P)Hxt$qaOY6De*b|3c3?V<@a8*FWMMPEraS9d+1MdGtllaEv*<<wfP+my-o
zVhte30U8ra&u*sbH*Rdw`x_oeXKDK}Mh4>Uc)sFn7Pjv_{kZfhLaf^L;+zl6n9`U+
zeHCA&^8&Kms`|qU3Y5*BZv|r}%x%QXqB}Wjgq8E}k5>EjT}m}QXm(7n-Akl<a3+A%
z_TIFio{@hXu7fk<qeJ!Q!VTc)W-t9}9;o@Pt;A<L;kQVhdE7p%-lMAD{FtuAh3EFx
zR^>R`jgNyT>cK!CSC2mICfvX!WH-0t!}%)DZwh9~Z0`qeqk5B-zd9RALlr_))_T@#
zm99+f@X-Lo_%lV@6UZIb_c8WEFA{R+CrmqUW!Fb)*~@cA6|sq<E{O!?z`=Qbzr}QS
zgA2Q2oC@n~vWBua^1xhV9B;GclkBY!opm12{#};v`j-Qa#8mF?EI{a>C*6zHOAS(n
zDlvX@RV3kwPLLg1AfE|$RQlu63+{#Z<oi?v#l8QzsNi|O;wAs}7ANl+>IFih_eF!t
z<GSz4wU^s$1p>^`>A`J(F`YXn)$b42T|eruo?Z`^-(K|a_~$rxFCV%oKsVR4@%Q_q
zssbVSpx)j(p^G{aP=M2Gyc4M-zz7mh_Nyep38gcbU0*s^_74}tQ^il%MCe{-{eo>}
zd0#+w*~--QNjnR3*ytY_sEkYpky37DP_FEE9L2t511#cut%7|84MZz+=|uUv5)wZ|
z6V~rlUp-E|;seA_O=?bl+JU2iq~!XD1>tzy4n46dG%5{&^Cnv%J)yDAtnus&YXw?o
zgNht1qUI6Ldg4GoPsggbAGt8DjpZ&SYEvqvjPaD^sa~L{z^QH-4@ZKY%JHS7_fQva
z=Y#XTp%FlVY7@)R!^`X4o)u+mLQ$C@<UAAEf&dj!qJzPim(9x6&OfhmSXa`$W*O#c
zZcg#!JF|>Xc08b^>dw=dog{__(Tic{tjAh7;L?`g$#W*0#-C1>!y5l!t?(!_0u@uM
z37FkEXA2&TPtwI|l1S#O#QxAe7+UTLYSfaOTD>>Fj?pyZV7!imrjp=gX8z5q*}7Kb
z%NjTj1z9d>JBeikY^vOmU8M=Q^4p&5X4)W2`S}V${?h7cvb@s8TYNB_6T`XCeV^z@
zgBo^g`4pX%5wN}VycRBpY0uUOJ0Fi=v6?NNNfUc5nO(=qPIU0ENE^w=?1Q;N{s2uw
zCH2+lVC{?@I%I@}(D&MmkJ?&@C`_8JXzG&r_GkdI)Oqr)$VB9AIDA2UdwvK1Ku0@9
z*JHIZA$oXRHjTjUSoE-Ch1l<Sy*ToqLVN4G$cqO1iPcsHs}H0gW0j26rX|Y6uYv_Y
zBr|_)+aXqpvzOtTZ*5@AeY7S+*>bLNrsIbz89<!7y#L7^Cgol!)N}zfp!p(m&go^_
z2QlaO)4}d7oOV56t+6V@d2f`Vl0;IQ^xl7duXB0h-{LCU0Te)!!3)#<?7h5(e9nzH
zyNjEZYJF|v*+ArOFLbJ0^%_9My~Q5PyVKM1PC4(lR4(r)9!Pk<arQm{T*3G9XMNud
z?x%b*rS2nfG8FUmdzTn&6i)Ui3{zjsf8SzT%F0|g-@Nz3XR}skmgV&0M)Oa|x-T!W
zzMjNac5E=x1Fk(R1*4Y5L~GN0Ec?C8mj`p%XW$*MSN_WNp}M_gbQx0*6UZniR>T2!
z5fXwS{Qru#b?)t{F{QVPN}BH*ki$nxJwI;VwoP#H$12Kzj9s5ofmuTX1L9&`GhXYB
zb<t#$GZSh<JB?Q^=MHR&933m`#n#o;LcgRl{O~J_;zSqr)T6F!{{0B50Ij+C&UUbX
zjSFfJ0{S%R4=G`6&aFrz+wPfL1+zwf=wUR1D7jWOx;+X1PUJPA+o`*rfF!W|DO0vC
zPL<8URSZRc;vO}KuXME9vSGbX*-Dg0R!1heXg&fdHtIX}ZZlF?##L~R`cut0LvwHt
zKA^s{3tMTg*JU+f9&CCT?`O#Bcpmd!#_5pHt(k~4A(~%*@prFW)~80oM#zz%(r)li
zjQpAsI9wT~k|Y!OMjGWpKux17q|Ic-b^-f+0TF-M|8p*icIGa#)21uIt*RJR)lZF@
zAq(yvy4~?=(UUq=>Vm#+I}0Rdh%pbN32_ZjKWIjbj;vh`oxL9>T4)t;^G$M<lIB}#
zdexjemb?DCvZ;q?G22fv$n|ahTGbG@Vw-8SHaE^RU0K`s@tq7&05LM?=-)^&3V|0r
zM+5i~gmL$=@@o~|Rk6`c5fDOD>>aCsy@>6JMCH}ABLD`HYgG}gI8Frk@|wtT_#Tdl
z!Q{(tzP<Yl+2Znju{Mn9XQb<E$J|*?=D$X~Xgq9=!Y|~t(#2*edVX@F7D9K=xmyk`
z8_v4TXgmg+o?fou7pbz$o({y(lhIU-@1K^xX{+5`cCb_bvAt|!7oEhkviRboe*>QD
z?_QkpFW@O4ifJ-MBc>xAy-|K*+U>Hcw@nOhZqY6efWpguF0ZlM+1_F)eg!XUYSxmQ
zoI>r5Lax1-F1#u~I=H_uD=x`4q|_l$G?Lx}j7~2O32taK6S}yr9#(TuJ?7>ALcD09
zZp$2hg9Q*l#B#Qgzw2C1%=Lk<L4MoQZUGaqaIE}YNA|A*U}BVEvdLrVxDnF!!1=Rn
zzQeCx!?xu2dNl|ul=I4Qyh5W`RC=cii^(nOSL1>`e0vaXZXYQ2FB7%v1D|f3Zv4H~
z;2%h8jRYcg>^w8z7VobNCgNOa@6IR1s9oVfd>FS$0w3Mh&gkG00nr0KvU|PZOTY?9
zYn`%SLtquzJ{wW@XRlxHkW@mu8oqnY<W-JNlT9#XyfcCI-@{@oIob25_Pe<=DgMqb
z<Mo=iZF+o)plr4z>}m=;PsKOCEV)dc!m8lX>C^}UmeQ95xSe)aaSPworrY)Te~o!s
zs*Q<$-fp(95njQ*fu0+|%}V=gi}w#6c87fd%zu4YBfD|Xo*qUroW<uJXF$xZPcMes
zy$UYq7DqbxQ|{aaS;O=F9M3StWxAbZAI{1yzGp3W6N-CAgD8uaR-<4;M~$gv&MgUm
z(va$kLzq<ZE$`V-qk2oiUsb@Dmn{xVfB>jKOOP2#oq5VnajBdVkBH^rJo%QxXMjoq
z6B_Y&q5UYJ6T`}x09HQsa(%~N+|72$RtaMJ5yZW2)ni!(5Ir#2!STg+-!AI>bo%C5
z%Co%<++lmcY3zYQpzj>F$SrKYu2jW_y0yB!VF1Vaz$BY_snFa?ym?l}hZ}itO8ul6
zUu_H~YmNu+OBUBz@fc`<F?rn)b5qg~E%#5`6`br2)9scVO7lk}20(y0Qk_lF<Ep1F
z&1;WEZyD(Lt8TYcf+@He(K@pmtfJ7*KzPaH-EwPxVM%i5UdZcsu`+nVNe&TZ&9QSN
z9cexPZYm5J3Yp66G8c7##4We>WxIFvSxL{8sLd=a7_HNI<XSEg`-u@=z!c!WspU1#
zY~l*N>2ZCw%;pEyH=nH}NrRZL(dU}b_-Qu#7>Tlw+rN?-eMTQbfhZ&%>zPgkf7FFP
zlA1h42$QRYRGmC`yaLLOu=f5FXs5OG!gu_TwQA!zmIum0L6fuHQHjeV(rdEcqy%4!
zhurjpZLtGlS)V^0({7U7sg}UL9;4aB`?(Z`V=gBx2qdv5@a=0KhV?^Y-AjkO4g7n1
zna2p{nfH0WejgrY9~p&su!Ua3B+d#FfbL2)y15lv<uRv}=W^`60EgpQ3^J8BUyel_
z)_-msgmb4k=Ybbj4EE`S0DMvC8PCUGd+6eMKED~U@m(wRqQ1w@_gDC8Euwt?z{^0u
zyKb8*ca;^oS9Hn6UCr-5Cyw&$dTv0Thp0HuCT`2X+d-G_>kHzp&=LEZ%J^kUfQsSo
zogdcXzYZtCrb~0+kuPFXf}Jo1(iu+iwl2Q!>+`^pF4MCpq<P%Qaknq$NxAgGXdk$1
z695RI(l>>uc}rRR;H{ePXdNi}fVXMeG{odV?0xLy24yejUihOK{2t7(T&sLH?jOs4
zB;?_?-<X1-J3X7Pc(IUYpe5@~2{9wVMD?wry(`j_JbycQr9PMKa^<d-e;vJ9y}C%S
z`|f|oA((d)4KYj>sISRDzEA^x7m^9a<Z<FeU~?UrAIbN!<xIx%*0f_nB!bBec1yD;
zaXjilY{qjD6$r+20dLeEx3-8OftX?F%fh9aUS@7gc5vYb`sJz_4@`uxm#4?9_zUM`
z=RIuzMu>x$qu<~w1R=^$x3oL=@exS$H`mdeU?IGF)*GYSOoDKq<laD!71oZWptqi_
zV&m}i07J~5h=0O*-FQ96wOMP&GVcL+tQ8zatEsXH$&rY33&?FT@Tn{&{T)nzX0J&U
zn-`q_hK!Llam)OUXnX9!fL0$NYC&mPI#W{=nr{r=Ol9AA!vys*=q=9l?>_LTitOVc
z0C38ye{H#;Qp!b?^K<CuWmC-5fPLOSSHyR08WwZ?ot*S6I5()OeVr&sF+sp|d-+xu
zKR&y)Jd!}5XJax8vX|REt-FHR+xiHYBcXmHW*Xh8?TBXmO*r8r_){EuDF_-u)Y$xM
z<gl-Po*s5v3rCTr(!a1<URB)}Gd!Wh8fLC}uygZ6vrjyvtFte1a@Kr4!<YINP><&o
zT57SER{{i)_MGlLI*?uzR+-0_JMT{ebCk@(>QCSPNt(^dK?Dt7#Rmt%U*>%w#yV1}
z8|WOXO((CFPpd!tniQsN{Nt29By%WQ`6=xWr2DoaB3`;c#nj7Qz*wodAtbDRKsmL!
zX}Ze`4D~4-irgHj$u{|bOV*tn0dN@5BaRq3?n&$Z4_*}Ix?U&Km25y@7q+MT&uua-
zX=1orVcj4pf(c2ZKi!^iO8eSW2YdaK$wTTzD^F~6O_!I!Sp6-vHNE)tFwG=V_S;f3
zQVv~U9qgYn$$-_DUh2pI%hp+^<CM*ooYj6IlSM@Zd;WFF|BVF*ipcYhAkCd#XFWSl
z&p33s^rc9{Aob6-$c?m=$qx?)IwRplNAY*-2kizxnfnXRQm6XC9Uu+s_I1$zmHpSD
zWSZ<=zz<=bIuG}~P#FWsic)hqRSu|)lc)fLz@lG(L;Dj)fX~D9q9Hc>aAIn@-|&Vf
zInePy8}jj-&i$~LIJY0x+3oRal3V!O^`ZRkle1BmXdrG~5QokNm!0;i_fZ)KDl{_G
zq=!r8u^$%`j6bvC+6>biD!;SI)BFj>n7bU!NK8z`tgJGnHxHkW+W=mp%^4Trx_yIS
zyDN>s><9+OY+XAV%eKe(yq)3HXz~f#Nt3uMoDbq_9;og7;^O=wlF2r6bKCU?6q!e1
zoNnh~c62)01KFK4^QoQPiqY7ULQ+&O5a?lih9H3D*6NmE;lQs))K<9rs@yb{=SP%u
zyh;@Z?uYzK<J<{@+Tyi^sI>7XG`@YP@aGFQ4^erY#;PZ8ESqCE2g0(W!Gmme#w#Uw
z`H8l=G1=H&oJvqTOcel+j2x^JsAN`LQD!wiOYoUI`^<a*7G<-O=Ix#j5P<w#(+Rvm
zM;vZ6D~$??uDktur_1UQ8-=pJC7b@}?a`nsX@PI(pKi*rMTfeU8Zja_Z@&cyJb7c)
zxXzgyZt+!Gr5oSzRZ>)Oy8pNu`F$a-)AZxLaVD<;qne)E-tymXYQ`;g7q{s}D~oG8
zsNxI0Pf7lnoF|PKx=q#n<q^R}k*ZYS7@<6Si2yCET&^Nc{-?2{e*Mvcjfn?$Va)h}
zgdul-i!@?dwu4@H;AXNmUV&qFX7=BS!_%4;XP10(BHWMhJ04gnmX33Co><;?UvcA$
zpY{StEJLoo&*2Uy#6KKpgUM80*0eHf=s?r)=#rbAUO3>(PFr?vEqpC4tyx;WP`hEK
zU!-!U^CQ#!AWF|u%RJMC<@(pkfh_!3g6fy6)6vVLN^IyvU75G2M+{nSBw)8UY|mJL
z5B6V{zk1gmL}NCj%ns!hG~c9TqIzig#e)0ArtRb#U9(=2I_sYyRB4iS7_)t_>Ygfp
ze+j4hFW95Y0>}k<^YGM>8Ct3x!PtUW?JFNoc`ce$)~YpE$_kdmbV1gBgO}Pt^0#3M
z`G4UZEcfBH3$J;KcCzr$xcI&je*1-ZjSC#Q>#EOsJB`TSPppjP5UJWWz6m;GGI&5u
z$arqF&hkP{VazJuHQI(r1e=`)XhK0<o>K++V~d|dd<&y2v}?X3+T15~LD>EbYGnBl
zm<?<jqj#}PMFf@V90cG<294~H2(cj?|J5ZGwWhSx=?tN|f784J4)weC^sSFrL^<{2
z*Q%^wK|;XjCZU7g=uDlpJ#&kM+*j(ODUV>ZJrAJeeXH!aWgk;KQ5pF(=&a8nx<ej>
zn+PC{G#WxOy0@yv@yBdZO*%p}N{(rR>`-W7r(K?dt;;dDssEV8{G$EQORt{Gc3t1?
z#(<8v>oKlj=;RzpB;$R5>e8M*q4<~Y_r#_>O}yepak5?OAcM_;W2<`R1TC3KPlku*
z6aV`Q@mFd1^OaS!p4|GGSKn`6?Wa{Vb8U)57XfvY`dB~9zN|`$OU;q^!Ky-7{P=0&
zOxH3P#~aFpW(XIy?qp>pr45~q^V8|;S391Z!O1NjKkZx}`DB&{ff&OA?cm=!^1D%b
z)JA}9ED7X4776RKJiSX^fvQFSZ-ykt>09fEBuS#PWQbM`I5bN=2($k-wH?}iVedHw
zLjwAMt595GAAwPSF{V}`uB`!vBuNs<{caZ53$UWsIZs#K%TA>0e)Hypgf-Ue9C_U8
zh-;L9whTHs4e+E1kVmBY*F}nm*$m>}Nu~pL^M()){v<24DCDEiRgxK9V0V3wDY8f}
zD%GBD_`v)1X-O_$avGr$bUr9s#YeYoRakCsiitnS{66<Gd=`><32wX<?>yJ`m<m{=
ze57N_XmOi?wD~}LTy3%5Si88pq$OOGes<BhBtNu2&UQ039w1Whqs?=CD`@_PhXV$%
zGJLEgssRvpce~e~8n*v=tpV5HH%d3wXc^V{DaQ=bH$No-%aw8VO#7U!Uh{}yAwhd8
z<qVFMlg{^tL=!!U7t*=2)s0(*dM8Z#h#CKzwpGpPD4fv3dNul2?>t0Z=Yq7g!!^;k
zuM}?eZOqh-SX*{_CPI_H|Iu0fqZSVFuZOeIS`Ami6hn5@`BdQ@cHdO>Npwatz+C4I
zs^v2mkgYe@fpj|*pN+ln`<$+IM#j-&OrCvPQDQSmfF$wsS)?@SqB>!968NIXG1Fgk
z9&~MUD2w`vDi=kgzAPNLBI$4*K=6x4z13$Ye*0G_W+QaY<{1y~oE8GKQ20XspK(f6
zN2jI;j|}pev55hp42j>Q4KVaUr@~F&E)o&?*#XE0-1gKSKTdI2$ivPBn0mN*q0B-)
zMNc<T3+MRL_zpXPx_Fh<xt7(irJqu;((6bGA;=Du4Rb2j9Vwpo`$Bz4tTx>&FhH%h
zh31=hUN}r0M(2h$Fr<4jO?~D-!<`B+*r7N9w82l2W5;oD!?2dMdli5FKmg>*G=^-w
zE;vb`v$PNy`M&RCXgqmzhQA=$=v3NPA4Y5cE&TH84vJsLjf#rulE;v8`Wz`wTvE4r
z$Ee0^x=hqY^HbcVoF{F-)dX5=<=G*B{^bC!SK4}Z+Zjjs;2Z>1Zxb;d+x=65;|Wcf
zc+%3w(Mtxqw&Z#L+l7do+mRBbp<{>C@x`U%@u0`*vcr181CiUqhs$?%ooHKnnwGa^
zj|pNqKos%9<i|^uQ@fD{(L|@TR<k3RP1`RIh@O#>eIw=cY86oY*e#`Yn`~?9Nr~}^
z^3lu!uWdmFeBe<X)WSKV&iITh>P9xV77_hsVKlpWx6E8(4`0P82dB5A!*3A~GJH%Q
z=^y#3_L`J4@)0jzS6`g~VBNl9G3}4$*mMbnth#WSp6zy55i(*mUW;zk$_wS^(^86!
zlFzw33Wk?USicR?TTl0OSJrypYz{dR0jvkc7hyKIW76Ta=TGA?WNWL5_|*KoWoV78
zaoJ-QvQslIp<ov!+j!5Gm4Z!Gw%q8L(|G83I{a0(FAph_POtH`(~VG%iT=O<N8@w;
zGy;+eTgsFsLyD%gK4(6xJY}kxh;>o{0I-|GWS~HgrjXAY{pTdI!1egGmDMcTO1w-2
zE6A9SiJyCBW<Y}o><ZeoW<=-m^5k?aNh=UbS*;Q}ya4ICG&&h4(y<y%ow?GT%b)n%
zB2KlehJHlEyt{Shitv)Z;K@cFU8wDQsD6UHwvRl6)8=U#{}bpxfXWYz%|oZe`liH^
zQI1%nqA#hP?Gx%Mi*&JE_jb2ivA@6`Rq^`w`&(zN$lMB$lZi*q-ewD3=6o}28wbCa
zGYBT_Mt^bfBY7e9C`i($dumro%&x}5xuXEgZ;_`GP(n7{us7_^R7|hq(B8ppaV4l)
zXk>pI2PV%Z2kI)wpb8aBmFq2ma573l0RmK*5iCr15r)9Glv=nO6jXsOK?-k%h<q!v
zhT~fdKnb~8vuoO{p}EBBw2T>$<MaTFyFw%?66q>+C-Pjxj^l{Z%?TFa%F)T!bC1lw
zp#<(m)d!>lf0)Fa8{8@0cf(``Nutz9v~o0f;6_X)%pdWchEi{<q#bZaae6R!)}EyK
z=;_UtiXNtOwj?snC(MZ(!o>Vvp}9$aw=+Whx<HOef4XF4UOO`Oo>4?h?e_Gb576Rn
zJY#PvQ>vUqsgv7<JCjqxSMapl8#@;XZBT-9^cC4rVZWDm$Mi?e_(<Ca5x$m({>4uB
z^(J)L>Dm3x>5sSM_IRd9Kbco1pJx01GJE5)6M}wUXR@}k1-lq#xl6vC$R58GGx!GA
zC}xQIRTBLke*?2@j?60Rc~5bwZSjl0lQ6?XW?iSyoosNtjC0mAH`r3`vj>s8+)MGh
zK)Pb9YA(g~c)`8z;}Ic|@Q@^`!RqYf@sI>CRJ8t4!Uc%b9sfjxmuKv;1z|*Jrt{i>
zW^|t@5r6GY?=J6b2Sg&3Xa&_*L$WKy@SmL0-#&etHdaxnXEJVuY7pZ_e=GstsFUe-
z02N!_{4?dL8xDmR+7zj-EFMdMJS!{9NSaUzGgu#Hp&z`+i1MWc>Gk3WrvMED9_%Ms
z<5xpgj}e*irv-_Hm4JjkRbY4`MVd89AFRI>mE|t=kcN+f#}(7y3rWiHpOy8{^kWcz
znZug$gAxb$iB$Q9wI7=s7SNAtNSyP%-<M(ZY4Wq<n7JRAU2PWyc*3j7>Z}XJ&+T&w
zl7kjlf!Q_=oD#ew4xv3<b7xpErEmfPwSW4NcOBCnN^_kjVim(i1$V3PLlAnIzpk2%
z36p&7iklzvCjhjl7i0>a{t#fX8z4J@&I#FN`U?(uBZ|X{xE<Jg0vX|~5uoB-y{%q^
ztF1liD%=cBW;10=;B&vR);CB06dbvc`&$7<`63zFLcz?G&DZ`~M=1BUx~fW_FBy6e
z;J3S}y=g~97?KsmR!-`AbGub<Oy9yPPnM0cMSl9zVivkLWgE2Wuv$@cdC^9M*KG(U
zlrp-nKdHy_h~`X2zpqfc2XWBZ#;+xO1FV$+)hq>WlhoI$n9uZhrMf75L$a2~)eK$S
zHwLCz0rX`Ws)WqmgY#A>O^a*=<Df3IW>>HebyDSlEvMV@F+_?16)!5K(c`5^ti|oF
z?%d)OLzc7ErjgkDJ`~(7wW7B-&s5(g-<YVYwKai^lB=t00n1l-K%O7>nxl0fMYOfd
zkv2$az!_8<dLcF+MiA)L9603@cXIz7w&xFoF)E2)VU%B&+aUkO(Iu&C9?>Nj-zB{E
z5Z6oou5fLB280WUaaBEUzk+Gcrl<j2J+ak?rX0m@78$WDEmc!yvc%tFLGZNpTicj4
zzyjjN4IaCs_6DPMsA@9T6q`I&9Gr%{`OLZ;Zj;l}MAMiT@zlaC8(&s#r}y{eblROM
zvI4GD5**Qrz_G)t?Jvto86u5qEvImd7>MTUlgr_3P+ti!jkRAx=eRvB365BSv%@C3
zO>TnN(VWgNR|i3N#S<K|tL!z{wHQvwnG@?{uI6(a!Ux6$m@IVW80_@_lM^WnwZmY}
zB3<R??C%PnB>zvG04(cSd#YOp6}8YxB(*HR;!9w*xO2>&R)e_<$ku)$eF1{U^R7TN
zQZ*Enn1naxsu9(KrEd+J13@m(+9%xt8cpCXKgW^n3<4ez1^COlN>|Phcdu9FRvWwx
zCEMwJt@Wc`a4sw>HGwq0UB##E@ntZT)}lgsK-q3Vbhj76zM&q)>rE`9@^6OHaCu3`
zEHWo9l=M2@`{vZaa)gZztgFwdJdWKIR)Id&`Z|O5uVRPxtS9QyKN(tra^X_`JOr7L
zhGy_OHy#VyU>7w??}TF;DUYVK97y*1d3}jY68m9Eg&_enm_05Sy48C>u+3^g?L)>P
z{!%rE`SMr&Ks)|7>aoU#7)mC9HS4z_&%qKi>Bbu`Es8Gb@K$-z=k?Zvd~09##?BEU
zwcy4r_G7JfljrFr+y{N>H#i%1MvkK+G`m}grC+#6$uF=>x{nnZ#jfX%n&W`4D=OJc
zy^q(IJ(Z06aHv4S^+xs|<6wG4Bcr|PxHxQjO<vDC5u@)RAwl2p@sFAb8U1SS`{Qi)
zv>1uk4R2p;$#>;G5<xmy&fY?~tFvYeY3mu|dgva8gFmm*@-_M1`|k{HQ@W_1_^Nf<
z7h4qa>B2ic?D|5GmGXd{GHhKRL(unUY})5B(^$T9vCC6wyy^**HELsb+t*L_0@voN
zr(K<=G3pA2RjLYI+3r4eJ-xo_cV72D^2Y}eJ`}oqZ+2b21O6v|&SzP#(j?_egq9%w
z5+VbZc5LZ7U%H7jRn?l2Tcq9<aQvGYpDz7PmHMK(6QB6|ZO;cB@#v6VrEax%S7Dh(
z{maRmUy759%v)mO=iFtMpMBP?24_4-B7e<ofqQ_55H6_DuJ2}Q>zRA+AC^fj`I8P?
zuyKw|67`vTYC@$$`dXtKriu)Zj>AMG2a5lqhc3Gxp59~Bmg8Fis8@`rQ&}$6lCgSi
zI2}P?J{Rlt65Yj9mf{fP)Ae@3^Ua!p9U8AQj<%JO!P-N!LAtgEslDG{dM?@hUhfn+
zuGcj?y<R?wj-Zks>6w<!B6n-|1>lu2|D_JXVcRK}d>8vXiL}{427psZ2Q63>*ty)P
zkyNy38bh8$VW5Vt8Y$rEWgkR)zF*p{)oe?Ni3m}mTvl%eK3U#r@8HnjYC9?~%U4Bt
zoRekfudOiy^lbHMxh0F&pXyoZ%imnInKnW|udfIO`N!G)H_SKQ4l~(`*0Y>bnL6jk
zi;GWpx%D0HOor!*%ttDlXy^eMV#@8Z-Di0-ke3$wZeiooT+@2QTiWEYGCUSRU(GOj
zPBfTOt}0KF?Mw(E0QLh){Joev)OvNH?WiSZy?RACvr8a>C(t5(e{orUgi6(tXz-m(
z9~skSjU_|$SYZL4uygcX&KCK+9`1$}jHn_sn_XQt+MdNx{&VIQ(;7cfiohAa{KX2C
zwg&RyC9mlpc_Bf6nhMu#DB!<6He8^#cRjKg-9?GsRi(4TP0#gF9XG46h`-+ESjr-u
zE7aQKEsSVSS<2hnkD+zSQ1Jr$Sz+aMsO8bS(}vCX6j;1J(!n^;TKM=eD#f3ru+X7m
zb#ahlOJ;LqM^{Yy%5&a*)7C;#+a3dPHTkY7?LS}@H#4VZeD@Z^h2EtK0P|;a`8%@2
z9~iNEt`(ecxaI8>hR*@f1TU3S4NZa(JdM&0{Y_S+QmXI41|<F)?XFL3R^vaPy(=zt
z7eN17?<ri9?%on@u6o<Op3GJ6Q7qwuAe(=*c)5pmxsUF@+<QwdQjmLha;*EL3#&t1
zK5vfrJbqK)X|{_S%|8;#$?0{!zwzkwEs*_@Tj>FW8bOyVg&%!Ap7}fxGP)wd+_BJR
zS{&xYV~LL1!`=2K1&25UIBFpAt9AA<L99rlL6n~;<}m25hzrS%4Y-3nR3fh_URVOB
zw}JU7p%a>~YvYY`VvH!iy%eB{J6x%f{)F)yV#rlye8^<>JWP~-c`s0=X$CD<$`4Ov
za`OAWxd#iu3eY82X}8wNWF#Bb8c+9pki|=Yn)>{R_^KbjqV7SUOmNQ_DtYX0u;AOd
ztX$y$Fq&1}nxm>0iup6pyTP%-T#q<scSjjfnLNW<5kZhmg=7{i+Lpt2wdHsdn`<K~
zkR<Md5x7P#bljRr%nu|<dWq>zl^9rrpOJVu$22;gT`d3GqbY_DBM5&zN;zboYqGlm
zq-Mke@W;{JDjRJk!M!))T-BdDnVv;mB*sJ?zuyIt(apD&tj=CIfS#5Cr_lGhHK(Im
zXBIOhFxxMFt@_^=JG5=c>jo2>h%Lgb@$xxMiRBaf?k~lU2KtlzK9RAatZ6<uS&^m<
zJo))nvF-JbjGQm;6(a>V{7`|n;aiAn9M!Yj*-x((t%HMu-O}kl?Wd=o+(0oze4hak
zz_9U6)rQx~%If8Em&eE~|J>}X=@j!*#UXF#PfkpN%mI5W(<m!<66s(nPCA&Y<XuV0
z!LJl)L;23boHwb#^3zR;`4gFPBa7~i6?l>zX%UEu%O_E7MhjueIY5U1L{oFV_~q~)
z(L=G>QQw&E-d`UTW@bLmr5SiKK&f(_=|Xm&c#H@5!{`1~g~NI|b4b?Oe0krINe}`n
zxP)pv{cJ{GEH|FXLLo?~p^(6aB6Rtrv-ME6BKu4ytqw8~D~^UTJvEC)#hc=TCoQi;
zqg&3+ZR#PQzP){|B)(6p;U(ti`EsKTb7W_ox5Gtk1j-yTAS$c7s+Q%G)Mj)v<xipV
zNoM<BOgBN)A5MJNN{X}Zuc%)p5alr~=Syr2Y-JhvKfNQYba&8ZU~Zq-VZ6cZpvy!C
z2YE{N)xD55CWZ{1q&rd1YY=pLk;Nx2H+>cW_{qlhzL-siCdmVC?tu!L%?<xdUKyCD
z%l?+_asvTP$17$;YSrKFR#+y~d@w~-Dm4ej$9t?6gClqaNWSGgL88VrNwU^{O_!Ks
z?OX5m>vlTIBz;+Ju*lch>~c{`pon(NNWZ~Zn`Bt^*b!Y(PAW;hXt(X-Ip?aPpbwE>
zW{S)Wxx-D)36PP{`jM{wjT;RUhGeG?E@YC#hzc3-lbLzfop;jO7|qQ0ieDfa^_Y3;
zpR~|cjPl)@`-8Ul1@AM4@f1Md6lPWEh-mZwMD!2=igrCEh~|}qqvZE^QK$aNaf51j
zKbPYg0^s6yaM<hLg9NhRmAe1n$38cxd{PPNS!Gzh2rDHnn$8cC6{Z=CJFPX2HLaqg
z)zxL!7yaQ<|Gm5DIx63IS2H%}$KySQBJlWfJ#lE8AGOZ*cvWgte*UZf$JjIQeovEb
z{r7L$H?Eico+^%xHtAVw+SoR}kJkaeOkP_9kyYK&9(mze&rp~g2fz-9Tb1(4e=CLf
z&sAERLLHkzzCZ3uNxUd>8hd`O&3{<kqR5YBDDjkW@Q+-%tiab(f@KcsuBF;Sq=v^U
zg~tpP<n^`V;V$ZMA2~Wb_#U6>uphKgJrtJXV>*5e7<WK@1Cc{dNu&_GzZCmDpZN2J
zS~%7KxDHpCFD)&+YYeP{6%Dx+junS1stEnE<E7!N#S?fi#?H#jPIndAJcg(heApfP
zSJ}QXUjRcIA4r~+ATE}@;uV$`RwrY?uZcHb!D_aw;#|KuN2{oGUas0!%O$<JUPkK{
zN#b-V-5M&<eSCL;l>fonPL!Ih0-##e*kDZ!_Kd$uR#Tjo5mjbMk1LOKu%V%Ai3+vI
zXLmm}TbQde7#*)otKg-j-z!0-M5XfHkNwsw1o$WR#yRAtFdjGM@8!^seca(Qb^bvU
zP1m9BwHF?hxv%py<TF7sEaX7ZG(ZugS}-!x*~xc?R;X0{L<jji#l?LlJ`(@Z=-;h>
zySc%!J5MC?P^zc$^1+~BSfx9$W2X3L5-<3ZK4qpzs|_v^Pe<c!ujw@z<LxYgU9Iei
zADU<w^z{?g{>ea~Ns^?(H0AMxH7C6NNlN<f-@jaGT>OaM#R>e5PTHf*zN_reskOHc
zn;rnWD?j+!ZsomoNDN%^T&kNA-){CkC<a$E1JQ0OQ@Ld#vZ!vlsm<=mh)?+Kr<-NI
zEiUnFD)TqivaM|$w5-98^Y5f$h9_jPAq5CLaV)YHGemy`1}AZi;w)9vD%Fb=%ON`4
zpX+San%eeE#CiY{Qc_yAhOMz~CQ?#k>t4fsdT--;T#wnN9$iCd^2*+wqU{uHGqx_Z
zFA=vskM=hOEiX<`6sEjf6^!m(GfkVzK(^n3v^JP-+W{S@f=>jIW&N*m9iI1Ff`Osb
zNu%RaZ^uEX2#Vp(6Q@b4$=JTWGPmw86-#<N{{L^nv2ugAgSgxMMFbWXiI`m7;&HSX
z%vX|7ayx3F)A{-KEKI%a0Pi)+uCL(m!d}^Nc5Z>WPm$th%MCbM0#{os0z0#80%7lO
zzKVRi!a?o%vq)?zfH*(NBn5Ql+wcF_Q_xM}MiZp#{9o^(2{1R5^)7R-)@zomG_AKb
ziYVK?P}ywEBo!P-lMqPZ2}C@`UAnWWJqj*ZKUTq@AEq_>q!0I3Lm)ZbK5RA8&QoOL
z$e8qP5Vm6Ybu{!z`kyM!&i+RtE{y6$afOHORf7-zRCizD3;SgEe=$(A$&|`VMMb#-
z)u>fyf`#bf!$gJBbCV<sOKTGihIKv_b|NIVLhhm6mLHz?nX6DQ9K?h?kFunRqhy3+
zVIFRPh#@8hh8y`)m-I-y7+`yBi-01o{P!n9T+Grq`Rc<*;y6++n{ULpE-^7NmY9EV
zXsFxs{`7iph{JA^$6;4w`1a^9*+haIunpo)R)%a%5BkgF8WZiyZ9koJRa29bqqS7M
zB_SpE`H_;7<6vW}uc;}~ZoQG?m!UGU8oKS6oz7C#hq1V~4zGig_oJ&C77UL5U9g1x
zv|a}jUv;IT<&A01B+~Si3j*DdEu6v^g>LMoqD}1HlC4Y)Do3>*5~2?Zv5@)4kEEjG
z{(^!lwdyQF!Y>;Zv?^bxp3V?c$0>)bZ!#GIh4iQ+sU77FcxTL>qa?eK>!Z}jS-R25
z6G<YcD%fTINf$gcJWV$cov}C*7;O=e5Km&ryg@3{;S&>6Vn$#|25VO-Q(-BVij*oN
zeH)ZtLxdz!iuTfjzcSC-*(KdS2MS9kIA>0cCXz!!Pzt~3q#C1M{C#1J@)nf(_kY+Z
zqx<Y|j-Gj;0q}5X=00N4SNEGa8nT`6!}XliW_zTlaMdC6gi)&R8dQBbVSzo6ii`p!
zm6XFk;Vk%CD3Qy8B_CvH2z-W%ZI1%#R!WD_+E-$gOCH|?!SMbcw_b}KYghs1dAd}e
zT;7NyYRNNVID#QXOqj{-qfIDrWW8?NtL#eH0QA6=YOQvs=@LRKN>g*gOL*w;inIA-
zrKQYGs+w{8hJ0CX_J{Vg+o`O2^nw2ifuuE>Pe<-9gp9y^#^+X{{v5=;s4?Wx`F|y&
z06Mri%$EL2$?+x8nx#MNk(4{WH<`Pl*ZM3^`p<KW?Bc01`e}2m_8-B`@^-;8GqP?J
zMj3awWsy?MEi$gK8n{RS<PYbn;IjowJurS`+$m(Hn`i({sU~ZXq6D`*vVLDhwflS#
zn2#1d`b&dqnR1{)=LQW)t0X8?Pdo{0%o)R9Z|3#2pib+5V*wP;h%2R2|8E=-&;LEH
zeH*1?u4)iFAHDn4W)r2GpPS|5!zj|?lt$6WLtnpe^&sfd*E6MW5sIAXalw{vR~J8}
z(yKjd)2Fa6ow~b<+-HxrKe0E_R|Z9IBGqW5S?7~{Qj#CQQ>|E9w-{$bH|+4q%3vM1
z`uW5V^CJ*QE@rLC?PHoXiN9!j$!1u4$uZ_h{`Cv~x|a^vbPE{_pNpkT%nqlU?X1t>
z|NrHC=;aJyPqV$>gxSZzwN0LZf88jVP(&#5Ko*zqCY~)Y8-D?iNGn<$wCk<^U4tK8
zJnPCSbzL*5Z&#~D2b6I4H~%ZcoaN|}?XVVgsEa!A{%;W(V$+S)(PaRE4Dk|F@&Zi?
z%wtXjLo=*d&BYD5yr)gia}D5J>QJG||EI5WjE^gd`t<~j+a!%`+qP}9v2CMqV>L-*
zb7HHp)7WNXYl3%r@B8K67xQ6%n3>->Tj%Vxp1sz8Guc%Zf|57kpc(k(Ejv8@?v#WV
z6itcV35bC+9r+E=z2oEo=e>n^G`IlR0b1K5y?1_6{QcmXTb~G6x)vt>ulPp^1!;hJ
z(8ST{UQ6|@k;_WJ_`yrkhFB@PMCD4R8&TztC<#4y@A$V<2}~l$@-B;KwpEOLb=v~n
zYRz(W{9)@5wZB6~J3MiwIuQNDN-Azi$_y|c^OjR_oMeG66Fa19%QONvC1s*&$Ku4s
zK_vY!4!Vn;3K79sErd8cAJRjd77qSUl6ZXc3ss*jws5$K(>b#89Y3B6PW>!Lju|M`
z6q~G%O{@o;qLe~(9~X<j(b%UAg>Q&DpinN87bQFQL+5bHBq`dhzALJOv7BO!EDwpD
zRd6Sg=4n<g*l>*3BlQ=R6n6)HYz_@c;w@zCd8h4Rhfgi#Uo?JGAbNDvrAW8rRe%mr
zL6m}8=CD<GV^m}R+lAZl&a(#ES%gQ9#RZm`6wBDLY^VQxPL7y3W1v?PLA~8STb0xH
zr9C3F{!jmleLDN|dC&I$zfZ>b2Fwkx6KFU0=R?N2P-Pnny$c3rr^IY~8)lS5`aU>)
zgz+5FGVpRYqMSzyv$KfZbI0v*r^-squ@Ae*hVgT9hFf4KN|WYUQ@|=W2BCKPK2ELb
zS4}5^fzyB@fKN@}Z#XFm_S`Xx*+B0n+o39gg6ef1GCbtpC20L$w2L-AjL+2qmKWpN
z;?p<K{0ULNAYpJsKn?#lxg82GQHOe(@yNCE{NU8WwZK8Mt~FdIKc%M+wY4orENWc_
zR)yLt<5PxQ?}<uti&u;O^Jx9<>C%BA!d4G~R_nPEu=h&-l?FYU%drrwyP;Z~GP>`Q
z5whpqCc3k&{BU2XWtdZgd3eaf$+f?4z-8bF4GAF9URRQWLOYgZ&;XFI`kCzzhjd8C
z+dkpv9N#YY<dYsyvmx@Ql8Jn>g`kyl=D5|ugwr5ajH);BGD|BWj=O~a2%IW4ledku
zUXI$PpLoWI+4RsT8<#RcPQg_85gQv57j;{;e{gY;lbQMQ;!Zxv47M=xl`GU~F~+-m
zFn%j{#w7b6$mSFgpvW?aqsfggx7q1{>dnu=svXlg&oKo!Vfqltv}vXbvRC{HbDwRr
znrdtRbl4Mu4e0L}(?|aQ1V>D+P0Y;Ht8G&I93;r&g{hkoxMsl0B>#gF2?BD|r5&K!
zGEf&OiVhq0Mud6i)FuO$l^?~`*pws&zz|YIYDK52B#zdQc(t>a&4;WyH+wT_ZDOZi
zsd>-3$g`F(bi@Zx%P**#t8};>k`VwU9g03p&os+_&SVlnV^Vy#?cW$rG*|e3=BZJr
zH<2^G%uePm!OjxH=SetUrUP!8+E&DbjuSo>F0RkfR9CaTOE}BSlOJrt&#Cj(kL|<d
zeA}r9uy5d_)CM;<^g{4>djFma=HRi!$l$Edf_juTDEfV-JjEbt(BVJ>|8L>(`C`yw
zreUF_-;sHN@-5<$eyf1TP^15nv;nHZ1StnYwQ8}frlzJ=jiL9`mB?JlWQ9g`372KD
zY-)|c+?Ee(H#SFc7P5PFhvXM*xBH7rK937WcNe}3uKl+yaLVPcEt|_P(*DWx_nd(&
zUW)NbJ4}!sfe3Ob>McGzX3yHDOdtGTq^J+}-_yL8Y6RothhiJwf$q8siaC-MQC22j
z*j2PLIjt+ysgd9dIQ0n8xb%HY1~!G&rl$amRoO!K=12Ly;o8_Ua%uP<jaI=QA%Mwh
z-+?a9u9k-~^RY9y&fDFkI@|Ym2w`ykqv6~`^F8}Fo`Ah@I(XN#Se*^w<UlW{%1u3=
zC00`p!q&iV%7M*;cZ7Jpnrx;X1g#$@OEYwe&qvPOqSjKLvNMf5fKvKg($13?AKToA
zqNGSl%>IGcEk*$Aa|iS9h?QYaVkNChAA(1`n|Ea6l}^Kjs!xCuq>4>rp16r~l?B<3
z%uYzaHNDbEgSpKJVON@hf2;NE**1%wN1`riruH3Ddt>Mx%8TK>#mNb-l4imB9lw6p
zsr$O)2uLWXVlm@+kUfZ2b48N_W%>qMj6uz){$#I7qMuTz=Ju$$TO+cNt01cF&y#S6
z%l+7G!cnt_M|k+OcdP8&#A+iamd^)|k6i@iaOTU=&WXV#+<L;}$NKX<^7ic&eXa`&
z9a3YyxhT9uyra0Fz{&A`a9~lRUdug|k=o7Tb-FUE?exGhH#zx!e+05drTY2SB`lU@
zy12jJ(-jFh`2hI0%dTghXpHXc4}o^2y^}8M*O#=jj3LML(UP~HkKxE>2S?bz7ekk3
z^WEn7m_UXzoqcESz^%GxMl@MuC9W?QERQ0&90F8c>tH%fdO+HnWJBU%g4txF0mc$J
z`LJU=^9`ESCociz)wToAkCzR;lkLyGh{q=arVHSfyyCxERvn_&5ldU5iH(2%8l5Az
z?q7`ExE7WO+k|Y?Y-mfI$XZk{82a_p5`;Lq(<Knwzv0HtLX%MWc*|?}e(&=!y*ATx
zQIQ|{sofii0Zo?Nhw1uRf2Z|LUPV}fJfJ!1pKwt@6bwm29r!Krzv&b0$Wdop+8K5E
z<>>2zw>9?%n^Y^J_WkL=NkZT)&O}-2*i30gesCNf|A^mzkv(F8I;dtC!#f?Np!!FQ
z^5uOTy)Turq-@cNOl7BZ4&VY66^p)WApU!SUDLdOKGzQOyi)w(t7bx8IN-G~#hX}=
zz_x4m3%o1^3P$5^c?w`Gyo-1KX+z1XbC&K1Zp1U*3;LLtG1L6je3pcoqO>DKDxm$L
z6kWQ#?+uTV9&|@sWEgg`@bNpwU-^QKA-W3{T#fre3!NO)+mxV!Fj_bbT6YM}UGr&9
z{NpWGv+)IRnh4JyVCmW4p$}QiCg)WIbBHhr#6Sm*q;!dcl(C{eVFXfsvgSx<vFSa_
zJ|@yF*VXCB4t3uCEvVO2fiEAqG~n*6<BrI2%vtFYpowd@xO)%p&r*{C5*~EOfaAd4
z-;nWN7;B%egARuu@g0bcKl&kb25<;`6~3$x6dA%kvUC&`iFn|Ze}pKE2tH|uJiyUt
z<@uFM>8aI(Xqlapn2H3aR04E&3oNKaG7ZcdE|D&pJ7fO(1G|@y9VVU2*g813s%EFx
z&jQc0z4a%aiH42l=Go^c+BjoenqsucrDRHN(^bb*?94}TddziNFkHx&C@mwtppN-B
z!dKIcp?>R+Zbpf&$%xB%eq)(qUzkWq*nji8`#Jo0`y3#cdwHE<xb+CSeVaI{CY{UK
zefPEKlr#IO;gvhm^-wBm=tY3zX_ANU*^S+4wr?ctOiK)q?UfS=NM%d(76ZW5CkCRf
ziw9ASq8XKIcN!IJv)=6eo=y=eA}+;3XHN>mf&5$i5;hVa5mZ`x>9xHny2&#e0}KX|
zcDue;Cllm`S#3a8qT+V-ZKRuK;@+w24+e@Ut35uy@9D-kB)qjQs<|G59G3-#9V15!
z^^R9Kp7My(soYK;`+V*RVM+-A=$4e#Z|06jRKV}{O9KAK?dP((2I2==^v7LP{2w|s
zHptl#Xp2fq%&$5xPIHnD`WKJBY@yvjR{{GsiiJxMUiVi+^*C9trZBD8-r=Psk*~5d
zrR1~EJtBlRndXplmaUH2g0(&4^2~VYqi5iF%p-wEM$?hDtLkouNvf$WeUF`fw`Hd0
z)iI}|SpF_d?1=Cqq45JZ>y($6^u4v=@|}D~qJ!FwQ~qDAzty@LVnXmp_XPzzdKqrU
zxMG))JgG|D8g|NQ0J4PV-0d&gXa473yZ@BD^(bcfXH3dh<b<9XCh#+waj-hRuyBFK
zv!z}sY5PH!vsEmoi$nM`nrUmEa+Z%sJjyrp>1aM1N#vnt15AYZK}@el{AxI&!hqU&
z<riW@>N1NT^e30TIb<LjIRRdaxHGIb&uFs&n^lDv2Vb%msq?JdJwLa88<qE!>dF#<
z##3}mo@4Ew@r!4X9GgiuY7R&aXec{Qymx)fJ<qqVbOdphX3qDrkN}6F$-i=nSGPHU
zRu`W9vh*;sAo+c*_FTj?4`vK5+s9Bv-O6t?rG4Z)QBond?L0c3^Xg7JY?9b=LbN^K
z#t0j-{Oq?|Iv#m`eQD!$$!hSu+NaZ;^c4TWPvBzx{iDD;Alh*Rb!*{vtNo|M`Dr_s
z$yn37Mg$~*1%^I|!epfG4^eysjQh>z;Q`$(zS#pLI_K<f|LEyMrz=<SA)66Nql1|q
zn@SdpyN!tyl5DX)gS`-GrV&LuxK6t5>(x724C?DPAdWmb*X&Ng=~`#sP%QeV*74n)
zj>C#so~<Tj|KAKsj7F@ByLyyCnsUQl@iz^6(16oN!z=hkoIEt-ygBv<^ff)k-4FUF
zMxqrBDIDS4C`n2^+6bM7M)n^3CXd$BDz+Jw>16{(A_3z=*2}Tf%CtDdu{YVt8zuPY
zEDab+U&Wh8kJXnsa^__ebh|AK4*PSKl0L-CKk7}CT#KFuWki|OP{-$+8)i@in%o|9
ziR7+aA~T<_W7_NA6M#=JjIIyZx;m3fl5aq?TOmmmR%nT#WavUW!ifa;FRZ>I&SZO&
z_pkHxN%0pa7DB-7>y`6sSy(M?nhU<murHGB=vXQ2b>Ecxd{duOELlN91RR*T!^$T6
zsmwQq-IMZ4bE@{kX5;Z5z|~IbQxdtB81lm712HFE=_E>f?t<6=pI=nwx_4LEPL+Ch
zU&6lvAg(%F`O$&-anV+VJbK~w4%Vw2PR_W{&#(oi8-8Cd?ujf9`S-?ROXs+-X}bjn
zCn2%zXUCLA?|Q~z^)li>T!J?>Y4^=JlNe1S4u*Fxb+R#+m0e96nJEOi8t}qe*$6U&
zT;vQruP~X%&J~=SH;adP3o1*7jT3a{P(QQ=>!(F5n5Z4T_xBED%yD_~K_h!^op;Q*
zjO}{ZAPxF28KjHJie!Rg1NJRzJ-E#{TxW6klc$wwR1c_GuptGNGA5t7EQ}g95_Nkb
zYTfxptJYTRo{GivA|{qqJz`{;2v%*ZEU0LdpXh@Z7Lfpt){yM?18utJ+5M%JEoWr1
zZ++9WLO5ZitFqanj`nxcbqwXda)Lv3b?pA$J*DI-1GVVxD-NTCeFj2RHWap*w|V_<
zrtH-^<?%i3k+Ycvf{JVXu-H1jldV+?ET#u?Ju&^ZBiVbPmDh9?V_#Ko4c7R{?cXx=
zx)-Xj#;$3K;BrBUgv-$2z0##@Kz6}N&<wl`{5JW$H!D`j?pVuyD=|uXFX}V&!rk(^
z=X0zhfla`k(!vq^*h+lLmY`~&f0w&#FPCQ_0s;a~x#ht^_T6bpYA`T2tPP>Q09r?7
zx^G<*rVE_GK|+Jl?ea;8EF`y%%Wtsn{fnAJ#$t^to7S7dyGz#Rj~_biOrA5}Gjprk
z!Uj!%SGo9S8aUYd#ywVl30)CyX*U*%uHL5}vzO0!Yxl0P2ndOu1SmluXH0v#GqkS3
zv{#7aBYDHNQw^V1x{v38Zx1pTlNb@DN@ea?BON4^4{Ci~hqr8`PdGdIhIEyhorCtL
z#ogved_$B}%)T4^-sj_IVK#U(W_|vvtwy5nP4~a%q9>oOy2(ZqU%!I4T3Hn_xI_!r
z_0PWxH?0Maje)&am}HU>f2bUkt!4>V!!tg4tT9&SaCddzul1Ju6=?R&IhMjt>VX4K
z3Ay3TbdUMF?T*pzU(l{LyN+8({hFWLi<Z<IqL#hq$y7VG53?x4?FAsiV`A{M>^8N-
zL3Y-dJC5~stvmoJJw(twWikV-I;|tWcXFtn6WaSi{o~XE7ou<s{BSwjuXIQ3CcikJ
zu!ub8VxHNZC{3|7=bSLuAG-dUo@+dsGVkM<l3Pj$xFm%ddzs`18wnJyb_SSM1Ki>?
zb$B#9_P<k`QfcGv;IW$+m4$>V@)C1~ehQ&>h#nS?o`q$y&ni8?#~u0$WRH~+&9`1g
z!h8{<Mh}?5LTR*(nK+nFjoI=;;{*6PHS~@{6{5?EQa9ucga^TwAaFDE8t=8Ogqc{V
ztrQ@1Ztt-mi{?S$Z848GHH3<!^Oe(hwr$^hD}y1R$)|xNbV{6*lEdV!9dOXHGYs=2
zOHCs664jrID5k^?Lg7w_Rr_4VN}Do`LE47GAIz<jY$4HkKvsv+HJ>+GrQH2B=>!Pv
zH6WG<sMg2_lJ<M6`&s=hn!tnHjs?(!Z8Lux`CZ&OrZoVo>g8n+LOFIkAktYSm%N0y
zz(q>0f9Nn?zt%a@9pe_t@wX#f>h)P$H~qcx&%n@1BCn$d1ORJ<2`|z#MQ7+F2&Q+S
zW9S0N@oVcbj{vEiUsfUCar&q@t?P>M;rGm&>4Vc$?n;3ISy)k&QT*kv2lWFHw|lwm
zGQN6__JsoPz4-S_21l%@%i;4+mZ!Dq&6{@&4KgTEKshwL`&!5O{&zHvZULI7Jx=L9
zEz2(E9sSxk*7mtG++Ewb0VUafLSvidE@6Ku>TqyeCA3Ha<=1}&r@U3Ue+aPx`FXOi
z+&LPwwTXcWR~_urC+b#xlG5XEVP?P0uMlm(I+(<8vjg!W8-s)+V`|rp&$+e7#ruCc
zEESXS<whodedC~`Q!4gAg@XfM>=ka_{4CgFwaRzv&5Q1^mRjdma`T10#Y`4ef!S`x
zF(^C02JAr_KtqNQZz5*qQfIaQ5a<O+#(G5m__<-)3fn8KD31;pjarI@ZGrj@dL+O-
zc%dq^GkAZD6&6N;UWp<K=8Y5BHr{yNHz?lKq5;$xbZiza{rr9!1!%?LQWR2luf6zz
z9QmJrmL(V_v>GyT`xw2pyUWif3}5={IIWNUwZVlyXifz-Hk^;sG!<x}83PCXuTKJ)
z-SK<@y+3C>K$ggOySxW8eD~Qy3}C+!?S}P%Akz6ZSM7XMbB$XBr6`I>9DH$r@ka4q
zQa6Pk>+{`GM3{eSq;g|^+g?;Y)LxLfdJktx5Rb%!mS}LSL5oO>ScKV~2tEK}f{6$S
z(rb8ZOlFaTqO7+l@OJI8e`#xc0uG_V6<MB-tWm;+oDH0mgO;HHl52VwYgRTkvxq@5
zTZVW)OA5~!Di<rfp+mmo+Mz*{D1;hVg8Iw%mZ1vBa;Ap?pP3;9QF37sCvQR*Ng+iP
znxlaDx|UgI1Gqwr00T<5gYQ9yfT8+D3XM+zWl2UdLHmDEp=#$*9N8e`c$ylqkAa4T
zL$>t_DBuafK^+MVxXxVO_x%cOy{jeGln4;?IfDoxK7qg6Y~xJ0ltD40TC}yW|1l=h
zA+{ld!eLg>Rc^*-wUh?Dr5y2Vn+H2!ROgC%h*&QLXyUOlAaOL#ZuH&hVNNqXm4UTJ
zvzHR^*H%^c3%uH~_Z<%J3;DsIDfiFAfOYlu&*J_TA)yM&ZdJR_!>RaHwcgDd<Mh%G
zkhSe=vlSgf)qF1$x{5s3o`Bf_-2wznHEL(#{lfjv(B1_YdRoA<24h7Vg~7yf_%z1o
z+)yRDMHKglPz57~&r@l&dyv7kLtix8C=Dmu84V<p&eqmjzxi4eMcouvIctgO$t6GV
z8*l=HfPSY<hYLM9U2<_SPG-(!WfL}ADu^Z3>g$TYV9hULe3IGn3jD4q7qlwr%Xe=g
zYOxKR#1*YYcmAh@-p;ZXs=8=+<V8^~7jk<KJ<|;@4`c7HdPW<gN4E9YL)FW1i`i5Z
zP`w)1fbwl@H;jzvAbnevD1pU#xt+Rg7S5Wez(L{O<eP4y(EHCn@l!g*{#M%DKrm}7
z&x9qhMjMGHAOq|K(9K1)RW*e_RWSVamEDk%KAxNGwH;c<SVKm4^1jqi*`=qu$`*pW
zcf^inSBcwVF$p>;{%I87L;bZF@q4Lj>!eyz(PaMu9VqhE3Sgquj^Gn6aECzDku!;O
z^4J>t?a^{ni-N&U;3wz$uj)$88)D$|j=*)85*qrxSeuF^Y<m8N+<dCsw1BlA3%BTq
z|AnCZshwu7<#hx=Ft3WMce7&UEiZK5SNsza-%0he`>SeC<gfMD7Y_%H>&6r8%m#+6
zd?7zPpTAqA<)s-3rdO&9!YL=TH<XwW(Sj5;ZW!3ji$kS*UlG1@W275fF6h<If73E{
z27#DfA*UI)=IB^l7N?=mj~<_$M?^RFsqml}fe0RS{CsZv#sC(n3;MI{>b0dW$}{J-
z9lhM33DnFYnUOsEN=(=FGaDMcjkNCE#1UoK4gqa@07e}ag|nNsk8w*xQuzLs?3uL;
z78ze%!0eB(M$ZE=W>QlWe1X4~s~Qf^mThFjAz27PbDh~5d`&dL72DXqTE~}JB>lB+
zJvys~3rN8s$ApK7fc587osrrbZdle^gGpY8JKuzqEr{M^H3~V*CSIKIA77!*qV;&T
zR!SG<+aw*Et9gFuh#E+ZY>x&q`G>}L8f80^nIA<Es1`+3OuoGH2N(}~K2!9OrL$a@
zrtJpe=)@^1@H5N~_=q_(%5_M{cu*F}_YHQ(RC*WGpaW|ePK@zl1ZgMEJ{Zm!#?-%c
z*VP^S^Q%@x#os&^#GWM~06&=@wx|prX9#hN!UaLFYhWVd8U|9a%hDP+4#o-Qq(3PN
zze%beT=bVVVJi)Et|AfZu6)kS^Krk-q(d^!Z?HyeOyTCuX&+U=V>-e_+>mse!{>Q2
z)4oa^%s24I8ux6FMmt4AzT7;qwz+<+gA$f8H?18jRQal^)9#5wZ?8AU8C=O}W`PxR
zFBf6X<vA5~EZLXjnLre-<01HXKl=H)^Nd~Pq&DdZYw5(N>*a1o|ML|WE*s;SWJ>`S
zyKQ!vu&9g8`6gfC8gdi&`p<6rB_NL*n;zWu;O`=#G+k;ZH#0BYqNw|{w+JSs+@m{v
zYZKkR?AcB(B=a<%$_L@pO*G6}y^Nbpv#4L@e>cxpJJN5G_m6*=L=Ca9M%(9Zu$*n2
zP8By?zD>q~D%<uV%SMW3*O%zC)84{yjgL5CKv@|VUDL2I5t~duDc8B&cb_H&r^6(G
zWgs}zIxWW~vw#Br_jk}G6zI|M`WD0_;J>ljR4~C15P(o|T<`qY<ONOjtRd4Brzr3p
z{D{JIF)lnr>02yudJa8$SJ?j?4CB>7o_0)~SpNEGHI@;IXYt@aY^UeWK2QT3nqk8V
z!}#30=M3+`S>nl<+M--8;{E(yO7y{E1{`e6X{)Giyv?y3_-+IU=XEp95kmLq5eA&K
zUVG>?9E&_`OrL>b+T#Hz7`{!bTXodL0s?Qn?{8$;zW|ZYGuC%jY-|lS71u86StqGx
zZ-~N88HV6`QYgi+*S(WMEB5RfA$iS99wfq`=|iwaC#o$v(;Y?nn*mM#!m#|UsNX%z
zzT@))mbo03uK{!Tx#>4Vi(w89dUi~wqN<t$vlmtSDpiZpA%!K?C!R?oC5hyMI9NWK
z)ZXG>;!serF+d~>;6ORR&#WxDiT(^Wi{sPN7KaU8k?J*gtcW;VXDdhkAR+<~t%qBM
z&%ZIw_9MB#7#~T08u=u;p2FsmO-|P%Og#l;4=0rw8;4a!dR4nNbGW6=wP%gzjeUBO
zem!VxWFO3IJsmmM*o%=r`XHv?A>E<o{iy1lQ8}|t1RF~#@qd<<V4ZgQK1G#NkE)v)
z+%OAVS^K8KN<elxtUCLCEFs_%4CY{3??#9shM^8f6@i086$_<^mU}+_1Va_zm(CPo
z;6;(H#<{gUFMWnl^S&#C@Juqn;O31M06)3N1$6;h;5C|fGnBAo0h5J|ZEk4^>odJ3
zUlQDQYv2mBVGPkA9!!5+7BZgZbU@dmhSlz&5dk`Vq$G+s1$m{s9G^DA;HhYneRM?w
z07|2b`Kk!cv8VU=nmtDv#fT|)<hPH`B`}jckr>XUw%deH#qbU%<Y`O=KfS_#c#5?G
z9|wte^Fn^XAf9NGOyQL^0jD5=I5M+xIVZ5soYJ7jHy4oM?fj>aRN*y=H-{K51DYQ$
zF~g5Z!HwkxNlAf3fgEl(M(Y2pGnEuOh@DRV8Ur?A#KA`1oN*ORh#mSSRPyJzZ{8M$
z`0NV3{z0?&R=SWu+YGIbfS@@X*;R~~jZZyrHraVaVwut?;%|9{IcKjC(P@I{E=0Ko
z+nC-5S(0|)9cXGvmnQpdZXVMKP!!W(2DHQw78XCnl;d=4g9so4bv0_EjwqiJ(>DKU
zu)PuyVN^PvzYM!S5kOMpn+4bA1mcuyp<ot_c<8p;C!#aSp-bqOzeEO-Cj%zrac*2k
zu;myigRF8jHi5%a{M!&D0a-ov*FKJ*Vg=ObAn<tu_W#ZZ2re+0bI_Gv=Y#Kk4dY9<
z)3$H1!m>6A6~0D?_V(@RjY1R;9h~aMOnoh=sS?_^y=FiYt~8$_6nmrS=)~g1{u|9O
zEQD-y%hNb>0|q^gA5PbVO_Sa9FXJ~9rh^OVao2<gmMvv9z^u(W>Y_V}n_Xqy&|KPs
zL77s0dNK4AhAog_6I?;uN}H(^Fh>AlU0U{Jp`r9x$vL&r?`PvqWV6B@_iRV|X&TiW
zqH#qj<tpdG5r1klA4B=3Qv5CXC7V8nbph$r<tF=-+01j$<U$&FAX5~<AWc(QyZ*7u
z236c3DJ7-RbvVw5QW1Ka#ri8Cel!`)alNc0Q!=a1au<hty%eKlm$?}2q#7aD5EV<V
z12UE~NdTk5_9T&Vk?N@}@Pa4*wI@4(gz7i&srTz);T10e5RyN!EuEP4W$a84Z$PA1
z;(c(;{?O=qkZmY;Thkb_3gE(h-w67n>5eD=iD=&d@Yqb9M=at;s~|5A&FsF)uEKgf
z6r0WGK~6zIQ)6x-M6qrw_>T~v5}r_are=4Om4v_71?8enO~WBSn||v-RU_}{)2i9F
z6u)A72nT8}Z+)Y+HW47bU;nLM{jRs(AvnwF>-BEjrhT1bpl2cEo6vI9JNek6koMHc
zm`3vTXlZbStwY#6`o3@W7w90)YpSapD%}FBUi>hB0!-2eGi2xpj*xWEzwHH@w099}
zy~+hu^>i*GXYE^b`L5I+DD{`95}~?>4)CMH7el5^)NK?V9Bezy%<vq9Tx0gO+Qrwo
z)fKy*_hnXjICUOwy9pFLXHxX6$a)OAZ|xuZ4gcOzEqjO_Y=~HR8=U3C^o9!w?H_6f
z&ZzcjFXe`Y9s%n;Fa$&u?RDGk>dyCT%XRIBUbEq)0FSP};Ux`<1h$}srPQ9A2B%qe
zM1-casmA!xFz+1xKofkn5X~snZ%T`7(9>e@v*Mz$D`?J4il0twvF$YI?1y;e2N{Dn
zsH7fjlQYJ1>lxnB@4sG;GM_9U@_E?ZKBoVS-jxq?Q#bv!YL%^OHTkVCAylqr7x?&4
zgs>+HWAlTp`_QxP5P-z<C#`<6kDqTV`*`x8U->g{ZodVYLW+XO>Onu(=8)ZpgyA~3
z-0xnYdaPmtl{v0Ywb#AH?un;Wcc~CahIWv>l4wav*8BlD=R%vi!=o$8Ga{o|2EI&h
zm~Eo<T80e&4ISMCTt#l!x-PCiw1uX+gT*yDOC3lB^C@w0yybH`!IK&sp+C5FG@2ay
z<3~mHvN${xJFVZSdBAj2>K`KmN%t?t6VJb}6f>!_#7KOj<?aJMSme*f(@uyGHrN89
zXo9G`nHP?vUo;>VVKT@0kdy>5HYXQvA4Z)F<7Y~$S2%cH`aS!q9cK8jWdYE=w<dL4
zEOdXi29I93I;I~@BNQ_o<G|7<rIAVz($Es7k>FD@7I34$Twr7(@Q!d?7(4Kxl2Rch
zI3WwwkJ<XYF6M<{aPAX58)B$rMqF0bsBz18O+ANIjfICp0I`?edjmNfZR|8_a1@~f
zpMUmSc-uKbWM(_9tfm)h@DCM(>W8VFxdpuk)Z&00%P39@H%4r{S2fzlQmAyc;b}sz
zL&XeAStYxa76p_A6?YMub4i;;O^cg{fS`xblBAe7ojh>5uQYdiOJm2z_se-Zc9NH@
zt8Cr6ohw@@G60g(4U%Dd9y>$i$L{u^M)H`0S#lqUk8Y9+nt4oKNU&%8JjlqgGUIK&
zX)K=WV7}fXJFD%)^EQ3W?#Xgu*1s)=GV(_0)iFf#q$FUF>IjZg&;na}Om6ybBDg~L
zL>Xc-MNzrAd1YEP4tuGzn<du{d!Yq}klLKK%IX~oWcnAeE}bV^`uuCXUN@AmExxMB
zHG_;n?O*Y!6rI;5JhOOJ+M+{=foWiLmOR8~FR=N8z|ZQ*k#-msCh{g;_nc5LM##hI
z&T7lifHU>ukVa$-tO%`uBCcQz7uLu00vY0AuhRL;haqx0A`y3<PLSyax>bjokbeq|
zGz^jCkHP1H#6f+MB*fonkwk8F-UmvZTz>2H-=kpW$M`Kr4L>zS2f^x_-OeP1eWAbh
z(-OQ=LN!De)53tMx{;}!#W=7>6AxqJ89Yj8AQrMF74bXYm9FC*@dOh9Fq-+Fir37t
z8!@a9Vz6PYA1)sFNsHL)&08YD<SUAJwur6p$k5;jn(hz)w*evCLy@R{HGO5Gkujc-
z@!r)ZT1FVmE^;%VjX`b3fQ+_R4Z)dmM9uehP|9)$sQ1rCALP|Vuo3jsqcLZ-_B({E
zE8ttmfcku62sdSLYQf2N;S*}Kp|B3#uc;t}d*Xl4#B87kebMYem(x!^*Ssf9$B78N
zy@Q+0`kcwvl-rxauH)jb*pj{0?1^f*POvidb$UNqHSNz>mkP_b1B_kQiwivgfyof~
z3tpc+54A^B@$<avffMWaK*T{gfk-h=&oA(vv51f;=M6R&r*&P(XQu>hmo4dqUx1Hk
z=vf|f1#6p;?<%0fBW|LNTHTaDkJAck<a6FIi7&jEhlLz`Cb6Ci77{u2;Pyt1(-R~M
zTioYb68W*xx$XZ=NP|dJyWmz!M+Kv$+@MZw!0S4el)pz43m((xd%~ZMn-Bzb8%*@%
zpnrXhM|#PTTb#XVeG$$PO7TqewO!9pIaqdbEEL@HU_xRkw%_iOV%#gjR?ZS$k>8<n
zK0!j~##LF3LmPIHhNhn9($G5`1s;F_U(vlN7gPxXW(^>5WUANJ|Gm-Qw0Jb|o#5)x
zgfNFVMvZuv99|2C>f%(4nGGKd&~DZMqcyD;Sti;2(4C%4FV%3l_B3O6nKqoLeDOZw
zHdyO^a|5;2QoT+(lekKo``ei7-vc%7Hg$L@gC|a;sy#k<=sKMh-P%2{(iM8tj!?y`
z^WB@x$s8BnE1n&}8&RKV!!It3{~RdVj2SRigkPlLsOPCR5YbUWh^Ql0Hz;_RC=eXs
z9`-mMJ7{dfDsoKPu+TQrbZJ?*Q~uGx$kr&|f(v24M*G7o>WKy|lKJFpg`M94A5!)S
zOp6o^9RJN%_z>a|&l)jmA1)CTq8O$C#xEi$(9cuQ|A5;6Q{)DJKn+sB>mwQ`B>})6
N83{%48d2kr{{X9Qyu|<j

literal 0
HcmV?d00001

diff --git a/doc/assistant/local_pairing_walkthrough.mdwn b/doc/assistant/local_pairing_walkthrough.mdwn
new file mode 100644
index 0000000000..c0a760ef57
--- /dev/null
+++ b/doc/assistant/local_pairing_walkthrough.mdwn
@@ -0,0 +1,90 @@
+So you have two computers in the same building, and you want them to share
+the same synchronised folder, communicating directly with each other.
+
+This is incredibly easy to set up with the git annex assistant.
+
+Let's say the two computers are your computer and your friend's computer.
+We'll start on your computer, where you open up your git annex dashboard.
+
+[[!img addrepository.png alt="Add another repository button"]]
+
+`*click*`
+
+[[!img pairing.png alt="Pair with another computer"]]
+
+`*click*`
+
+Now the hard bit. You have to think up a secret phrase, and type it in,
+(and perhaps get the spelling correct).
+
+[[!img secret.png alt="Enter secret phrase"]]
+
+Now your computer is in pairing mode. When your friend looks at her git
+annex dashboard, she sees something like this.
+
+[[!img pairrequest.png alt="Pair request"]]
+
+`*click*`
+
+[[!img secretempty.png alt="Enter same secret phrase"]]
+
+Now it's up to you to let her know what the secret is. As soon as she
+enters it, both your computers will be paired, and will begin to sync their
+git-annex folders. Just like that you can share files.
+
+----
+
+## Requirements
+
+For local pairing to work, you must have sshd (ssh server daemon) installed and working on all machines involved. That means you must allow at least local connections to sshd. On most Linux distributions, sshd is packaged in either openssh (openSUSE) or openssh-server (Debian). 
+
+It is highly recommended that you disable root login, disable password login to sshd and just enable key based authentication instead. No one will be able to login without your key.
+
+To disable root, after installing sshd, edit the sshd config (usually /etc/ssh/sshd_config file) and disable root login by adding:
+
+    PermitRootLogin no
+
+Restart sshd. See man sshd_config for details.
+
+To disable password login and enable key based authentication, edit the sshd config (just like above) by uncommenting and changing the following options:
+
+    ChallengeResponseAuthentication no
+    PasswordAuthentication no
+    UsePAM no
+    
+    PubkeyAuthentication yes
+
+Restart sshd. See man sshd_config for details.
+
+You can also restrict login to your local network only (not allow internet users from trying to log into your computer). Edit the hosts.deny file (usually /etc/hosts.deny) by adding the following:
+
+    sshd : ALL EXCEPT LOCAL
+
+Do note that restricting login to your local network may or may not block git-annex. Also note that this will not work on Mac OSX because Apple decided to disable this feature and replace it with a crippled version made by Apple.
+
+## Tips
+
+Something to keep in mind, especially if pairing doesn't seem to be
+working, is that the two computers need to be on the same network for this
+pairing process to work. Sometimes a building will have more than one
+network inside it, and you'll need to connect them both to the same one.
+Make sure the wireless network name is the same, or that they're both
+plugged into the same router.
+
+Also, the file sharing set up by this pairing only works when both
+computers are on the same network. If you go on a trip, any files you
+edit will not be visible to your friend until you get back. 
+
+To get around this, you'll often also want to set up
+[[tor_pairing|share_with_a_friend_walkthrough]] too, 
+which they can use to exchange files while away.
+
+And also, you can pair with as many other computers as you like, not just
+one!
+
+## What does pairing actually do behind the scenes?
+
+It ensures that both repositories have correctly configured 
+[[remotes|walkthrough/adding_a_remote]] pointing to each other.
+If you have already configured this manually, you do not need to
+perform pairing.
diff --git a/doc/assistant/local_pairing_walkthrough/addrepository.png b/doc/assistant/local_pairing_walkthrough/addrepository.png
new file mode 100644
index 0000000000000000000000000000000000000000..b82efdbea23cf86359f3f5ff5f794701479dc898
GIT binary patch
literal 2259
zcmV;^2rT!BP)<h;3K|Lk000e1NJLTq00682001Hg0ssI2P3fg400006VoOIv0RI60
z0RN!9r;`8x010qNS#tmY3ljhU3ljkVnw%H_000McNliru+zAU5B{kMojO+ja2w+J>
zK~#9!?OT0J8|NAS`Qy0rM~n#&UqbjuQWh`W3Y2O<r6r`(GLrp)*O85^O6#uLg0^U5
zOWHY0TY1y60gY6&tty#BM_P55Zc|{(T3eF}<c|!hWk9kdCMn^g37BAmZNSDpbKW1=
za5g>%Pmrqe{q+3dd*0{c_dNIB`@Uz4XnK0u>kpiKf4t|ed)V!PfaJgqmArJj>g=Iy
zvJ|Q4o^9&U#sMdxgjg!HCb_W4r~~uYYYQaz_dN5_Gz&?J(37NtNV34<{<KeedBhEg
z9IViiq=baJJmQw#aeAPX3*AUs+;MxP2m(Q&6-kUBq+lWJ1xXDS!b%{l1j0%nfE6Zz
zfd6+pkU}a)zyk#MO;iZD6VR_a9$KQ$I_)6D2qLr?tXcMz(wz<Y`%39JHk}Rm3F+5I
z#IlE!Xv3uQ7xd~{HdaEDAVH~pa<lfft@g?EI5y=-OusJjn`1j4PNI#Ix|eUQu4SV|
zoan?M6*Ap+iT;oGblb(GB5Jm#K&%Q)VXQ^J+C~MI<UHA`&@-{@z9LeHl@KezhL1I3
zr9O*_P88c$684pFaw)+AVnrxv!~(N=C}so|$1LRmY(p-JD0&uF6{8lu2rI-=d1#B)
za!(UJ7*;%<X}#gFxM02EsCYcHqjM}Yut|07*bbd$VZ<voc6dVfAda4c)I5#;h^At*
z4?vfjYBJefx9<VCa3;Uzttms5qEN+J1C+7VIeB#y0Az~F@9xs)`6!^}F4^{nJMhl6
zp2(!-=sZK4uej<>UI3}PbBrs#Gm}@x06-?IJi1H2V-aARh6&4Cw-N9GxNv57%{x<d
zRf;?ryZ^<AT{(J)C&C8}`8Ds@jg@j*#<ovV=gtjd*3HKjKyJw{gHEQEGW}l4*y?cI
zybGZ7_5A%myb@gtPlRP+kI2|LkOyDA4X-yuT1H-Yb*KK7tFFKX91Lqp(whEp3qdqp
znyS%#uH(bdB>35p?COD`x}G^TV5-ajGM2*f>A7gHrWP#LmK%NmwWSK(_qAmw?*Y)s
zp)U2b|9-5?i<)B6eDn)NCr1JNxH?Dg_@wdenFYXbAT{r3cKx}VO%21<zujDCxMf4A
zqV{OtF#yNDnWMLjHMP0{)a_T%Rk`O|Z!P7b9`m%nKGyDyZb;M+UxW$*EsxEcUK@2X
zsQt1s?`ZC+H?H%s1<>=X+SD-6I2q9INikP#E&C;a&@L8L3tt2-F+<gsZ+~@LTgT86
z=gJbA9vF8q8}K~=sZvyAOZ9^(5EG_BQ6nuSl?tDG9)O{MDr}h_^#VZuMMqCr?owDj
zJr~CM(e8j0QY9cZUxxGW3MIpPj$StabY1c}zk_g0dBthxfExg;X1DpwBlRr0{QzL`
zuY`^1YkWdk{wvAgoC-kKC6W2`rt|NH?CUPhbUR`f&K-&q!FXY&+X(>um*;zQ)G2<p
z0BD!XRIKg&aH^xvS<*MU(w0@V@I~MfTevvYcsi@??@|N;fW&Y>ZD<%<)174@1rk^Z
zbj9hwg6WJVtXR;Mrngz<0jPmdPbg5Y9m`?)^j!34G|xRlSET#Z1WO^prq>nv<l^XQ
z0s~?FfGbE7oS2;8e7-F&Z&_f104P8!pIvt8u`lu!&K-&qp*w6g=nASI#I~mXWAnF^
zwwE&7y>#8X4&1sMT|#grBVWDC#4Pq8b!V!iEW7v8@a_UyJ#6o`ul2qrwi4*~s_TAz
zz3Y=uVso}c|NNtEA1v(%0g_DddHn!V(-oY(pHII6^NH=$U;o>3-DmRva#?xZ9`0ii
zHEjWaVMwLS=k@|1RWdM4Z2Q>0zQ$LEoi0BB5F!xNvYC&+4-rHB5ti3QQbn$?;$eGk
zM$z)de5rKKP?Xa3qc0Zy;BGYS<q!Pza)}xLW;6Y~Kzq&Eq^FH%``3C~*+kwB$TUSE
zGka=i(c;IF)DJCcJuWg$0T$M4_QJippiF}@qx$J>%WnaEdajhq8Qp~D++1qMrYv<u
zCg4L_MvPa9@MX_O<K<=9Ak&~s*Hz^8^o@rN7;=jSWLjL`3ELApEL6IMO1JIRmVa+s
zltB!M9EuY`|8y3V86eZjzmnH~Z8ARFH&5lz#XGwtsnt_-Ar_)@acbeOH-eaHC_qm*
zTTbpQoUpfzF0TE~CU7v+6;X{H<59*<@7r`m%C>*b8=CK#f9kUyN~b)2>t9Atl(S^X
zr;j)oHd}j+ZM6{^wcXj+JZ_#>^%*mZj@yCRNaN6D?Vs$X7Z}^2OfbQ`q4A1lSLh_z
zZ0&z(s}u6FpUm+2)|_{=zrfgxnIJ@kc88&PDr`2(--n1H{s<_&HljaGL!P3Ya8&=!
z9-l2bZucMAW_?yedlp)n2cu|kYvGL$Nz4Z{c1#*-)U|I<ByiXdLWIL+$TQYryqmxX
z17Flp5y&Gj$N)etpe5i0dKr9;fF*o1<<oOfLO=~z8H@rNppbxNl`;2H184~V=x4%P
zemD+dCE{MD0)+&qaJtn7QCK|`GeWSXSfsyFK!A?a$6>o<Yy$?E7`c{f;ft`E*uMR_
zU0)}tlOOxm{=Vn2i%_-JNg&_>Pt^Hh(Q{Wmwe<4T)Esr!iOuFWub=vlABju?Y3OeU
z0@eYupJFHfbv82(izDydF#g-0;N*n}-!MZatOV<TI2+2t$?gRDSMApihSx6qvS{64
z@qae63%@K9ApFKqz|u+}OoF7J1Y)5H0>oLHh5tfKYJ4eQA%6a;EnoveFOv0C7&uUn
zCO&>pvz>H^y!S<{U+78lK*ah*o{22!#PNd~(e(7RpILnE&o?{!Ci{kFgzh8>igu;#
hFVeht`12`*<bMLVqw{Fbq(uM#002ovPDHLkV1ggbSP%dJ

literal 0
HcmV?d00001

diff --git a/doc/assistant/local_pairing_walkthrough/comment_1_b33deed054d3aa8cfa6c9e3958643f16._comment b/doc/assistant/local_pairing_walkthrough/comment_1_b33deed054d3aa8cfa6c9e3958643f16._comment
new file mode 100644
index 0000000000..52bdc7f4ea
--- /dev/null
+++ b/doc/assistant/local_pairing_walkthrough/comment_1_b33deed054d3aa8cfa6c9e3958643f16._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~mattharrison"
+ ip="69.193.72.98"
+ subject="Pairing"
+ date="2012-10-29T17:56:06Z"
+ content="""
+Is there a way to do this pairing with one machine being a desktop machine and one a headless machine?
+"""]]
diff --git a/doc/assistant/local_pairing_walkthrough/comment_2_39f1162b4d43b61e957e7497df4b9e2b._comment b/doc/assistant/local_pairing_walkthrough/comment_2_39f1162b4d43b61e957e7497df4b9e2b._comment
new file mode 100644
index 0000000000..32d56c907c
--- /dev/null
+++ b/doc/assistant/local_pairing_walkthrough/comment_2_39f1162b4d43b61e957e7497df4b9e2b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.194"
+ subject="easy peasy"
+ date="2012-10-29T19:09:43Z"
+ content="""
+A headless machine is probably a server. On the same page that has the \"local computer\" link, there's a \"remote server\" link that'll get you set up.
+"""]]
diff --git a/doc/assistant/local_pairing_walkthrough/comment_3_588869692b290483f58f3a7aa2bfb55f._comment b/doc/assistant/local_pairing_walkthrough/comment_3_588869692b290483f58f3a7aa2bfb55f._comment
new file mode 100644
index 0000000000..6edaadb753
--- /dev/null
+++ b/doc/assistant/local_pairing_walkthrough/comment_3_588869692b290483f58f3a7aa2bfb55f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://openid.fmarier.org/"
+ nickname="fmarier"
+ subject="Ports to open on the firewall?"
+ date="2013-05-04T03:56:55Z"
+ content="""
+I'm trying to get local pairing working between two local machines (same switch, both connected via cat5 cables) and they're not seeing each other, though I can happily ssh from one box to the other.
+
+In order to eliminate possible sources of problems, I tried these insecure settings:
+
+* add a `-A INPUT -j ACCEPT` to the top of my firewall rules
+* use `password` as the shared secret
+
+but I still can't get past \"pairing in progress\" when pairing with a \"Local computer\".
+
+Is there any way to get information as to where the two machines are failing to see one another?
+"""]]
diff --git a/doc/assistant/local_pairing_walkthrough/comment_4_f6bf82c263fefe38701709d9dbd974cc._comment b/doc/assistant/local_pairing_walkthrough/comment_4_f6bf82c263fefe38701709d9dbd974cc._comment
new file mode 100644
index 0000000000..6a9637481d
--- /dev/null
+++ b/doc/assistant/local_pairing_walkthrough/comment_4_f6bf82c263fefe38701709d9dbd974cc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-05-04T16:39:23Z"
+ content="""
+Local pairing uses UDP port 55556. This is sent to multicast address 224.0.0.251 (same used by Avahi).
+
+(You also need TCP port 22 open for ssh.)
+"""]]
diff --git a/doc/assistant/local_pairing_walkthrough/comment_5_bada601ea4b7104f162a3e00def4be2b._comment b/doc/assistant/local_pairing_walkthrough/comment_5_bada601ea4b7104f162a3e00def4be2b._comment
new file mode 100644
index 0000000000..989e80d8ab
--- /dev/null
+++ b/doc/assistant/local_pairing_walkthrough/comment_5_bada601ea4b7104f162a3e00def4be2b._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://openid.fmarier.org/"
+ nickname="fmarier"
+ subject="Still stuck at &quot;pairing in progress&quot;"
+ date="2013-05-05T00:26:16Z"
+ content="""
+I hadn't thought of ssh. So here's what I've got now:
+
+* both laptop and desktop have `-A INPUT -d 224.0.0.251/32 -p udp --dport 55556 -j ACCEPT`
+* `git annex webapp` is running as user `francois` on both machines
+* laptop has `openssh-server` running on port 22 and its firewall allows desktop to connect
+* desktop has `openssh-server` running on port 22 and its firewall allows the whole internal network to connect
+* laptop's ssh pubkey is in francois' `~/.ssh/authorized_keys` on desktop and ssh'ing works
+* deskop's ssh pubkey is **not** in francois' `~/.ssh/authorized_keys` on laptop (is that required?)
+* (as mentioned before) both desktop and laptop are on the same switch and connected over CAT5
+* I'm using `password` as a pairing key just to rule out any typos there
+
+I don't see anything in the git-annex log on both of these machines. There's just a bunch of key generation stuff and then the last line is \"Pairing in progress\".
+"""]]
diff --git a/doc/assistant/local_pairing_walkthrough/comment_6_01ba0f9bfa0ed066c4b73d2d6028eecc._comment b/doc/assistant/local_pairing_walkthrough/comment_6_01ba0f9bfa0ed066c4b73d2d6028eecc._comment
new file mode 100644
index 0000000000..1b2f66bd99
--- /dev/null
+++ b/doc/assistant/local_pairing_walkthrough/comment_6_01ba0f9bfa0ed066c4b73d2d6028eecc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 6"
+ date="2013-05-06T15:14:06Z"
+ content="""
+It's quite possible that your router doesn't handle multicast traffic to 224.0.0.251. The best way to check is to a) see if avahi/zeroconf works, since it's sending similar traffic and b) run tcpdump on both machines and see if the packets being sent on port 55556 by one are seen by the other.
+"""]]
diff --git a/doc/assistant/local_pairing_walkthrough/comment_7_17d44229e4fa46c50815672b96a9735a._comment b/doc/assistant/local_pairing_walkthrough/comment_7_17d44229e4fa46c50815672b96a9735a._comment
new file mode 100644
index 0000000000..84a921eab2
--- /dev/null
+++ b/doc/assistant/local_pairing_walkthrough/comment_7_17d44229e4fa46c50815672b96a9735a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://openid.fmarier.org/"
+ nickname="fmarier"
+ subject="Make sure your network is correctly set up in the first place!"
+ date="2013-05-12T08:37:38Z"
+ content="""
+It turns out that my internal network had badly broken IPv6 configs between the boxes. That was interfering with the multicast packets but not with anything else since all of my other internal traffic is over IPv4.
+
+Getting rid of these static IPv6 addresses has solved my problem. Local pairing is now working as advertised :)
+"""]]
diff --git a/doc/assistant/local_pairing_walkthrough/comment_8_b9d4c29cf2cca0427808df6af08fb789._comment b/doc/assistant/local_pairing_walkthrough/comment_8_b9d4c29cf2cca0427808df6af08fb789._comment
new file mode 100644
index 0000000000..31a0f96742
--- /dev/null
+++ b/doc/assistant/local_pairing_walkthrough/comment_8_b9d4c29cf2cca0427808df6af08fb789._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 8"
+ date="2013-05-13T17:22:17Z"
+ content="""
+I don't understand how IPv6 could affect local pairing. The assistant does not currently do pairing over ipv6 due to a limitation in the multicast library it's using. 
+"""]]
diff --git a/doc/assistant/local_pairing_walkthrough/comment_9_bf313e490076a4676a632e3ec6129189._comment b/doc/assistant/local_pairing_walkthrough/comment_9_bf313e490076a4676a632e3ec6129189._comment
new file mode 100644
index 0000000000..5ab4638b68
--- /dev/null
+++ b/doc/assistant/local_pairing_walkthrough/comment_9_bf313e490076a4676a632e3ec6129189._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lhunath@3b4ff15f4600f3276d1776a490b734fca0f5c245"
+ nickname="lhunath"
+ avatar="http://cdn.libravatar.org/avatar/6388e539b56b3875cc9aceb9f404b3ad"
+ subject="Diagnosing local pairing issues."
+ date="2018-07-30T18:54:56Z"
+ content="""
+In my situation, a local pairing is initiated on machine A, machine B sees the request, prompts for the pass-phrase, both machines proceed with the actual sync process, but nothing actually happens.  The last message in B's log is \"Pairing with [A] in progress\" and machine A says \"main: Pairing in progress\".  How do I diagnose this issue?
+"""]]
diff --git a/doc/assistant/local_pairing_walkthrough/pairing.png b/doc/assistant/local_pairing_walkthrough/pairing.png
new file mode 100644
index 0000000000000000000000000000000000000000..dfbbf0641a38ebdb9f94bea11f6f23a1df0e668d
GIT binary patch
literal 6771
zcmYj$1z1!;*Z-wULRz|6kP=X0>28qjQbM{B1Vp;KOIoD_>E0!z5u|GucWI<s1^%o5
z@BO}a?sI46Irq%`&N(yl%<nljR!2*j5T6Dg002T&6$M=YK=VfR&2Z6CHIdFKH>$z5
zRaaI3?*Bf;-5=6X5<CwT6O<YO+20op$Sa^m32}T>H5GAI@d(H{A9UK;+XDa%psFCN
z|9bhrB3OrZyYLRLKH|kOl^fx;Z8|Z=#Gsyii)+G4=bR>In0Mp~qMWc?s82}5Ym0@{
z=rsqWh~Db%db!^8*bg74P9ZdZM2eP2+V>(>iF7n^&U&yTVzC|XPDSA-*;mR->UT&B
zo^u%E<E*)!qn=JuM#{_I33tY|m$$*)M|W%oYTsVS;i6$+VDxvfglC4nd-u+l5*r(P
z-h`T(+StLy8dVA--@RkjOtsr6?({#>($pNZZLk~5vU7020OW>W3O1ZR5fEToGbz7B
zwNpz=0VjyTk&%(o(o%Y`pTzC?%wxkE>j~5xvIHEp@J6Nx+lEEPyW?mPc#sffJSrM_
z8kLU1d8w%lt}888e-Kp8^EGIpZ&uAqkpN&)y{I54P);HIxiLqhviJV>$i3&La>-?K
za<XN~<(u?<*OJS#{0Wr(LrL`UgSLBh<n+n!_u{df$Jm|6D%g!LJLAnk*ik;aJkyTn
zYyR-3xf=e5t50$@h@#7SdO`vNe;uxM0>`brx2`@u!mO-FSkZPc5UgIm)6JO7HxV@q
zu_n)3Fu{}+^*<~adHD-U9HL`k(QQ9L^PHTRQ7Q=KEd0-wh*6z+d*H=h6d|qtb~{=O
z2?YRr`GUsNW)>3%<fdHc*e=A&=>s{~!=W{s*!&XCW-~;r;zTKEChaE;CX}HrK<JJU
z;7>+Wbj!k#t9BmtRx|xdVaQ6_yD`}#fzFkPxoC$CBK#XRRKEd^A9*R5Kk?|%BP=W|
zJ3Bl7BN)mlRA(%US14CwW@e@o#Idh|Yw=1t;5K|805Y9R>TK8c67x5Vl=;mAZ_7@E
z9uBuciUiejn=!2)0g&qn;*MzeBiS;R4YOjm7xtT%L(JglL-m<FKWaH)!zC}Sw~?Q2
zm!hwF{crR!xflA1-b=6~z+rIT+i}<H=>?l_jmh$p+`Gebl&`m!2&1(kf<$bZu`b;$
zEIXR@o%p^hr@@RwH*v&YB{y&CS|J!h7k3=q_rhq!DBgXis89aJwX9p3usxMbaMjI7
zLkVfkexaUa^U6P~rl#g%e<3+BvHN1)?Cl>UV={xJsk!-|!lNMN4)!Lm&CzD(1&+<#
z`R0aNcMEA^pq>usaEArdzHr%bAg+ZSKLx0}gKE!jPdtH83MPDI?RZA}w<hfup1{Z7
zN3mr_hN#1d{`}9(;Lh73YM9<FTWzhQSy@DCVdgXr(3*ODm?;gnL_0QsYYMOW-pn@d
zYF8QoL394}iA8Ov%i4y6$>h-GhvJgmbbw6P*@qtR`&#_W5Tp%asI_M)kuG#3mk<b@
z=C7mjRa6+p96s#iZF-+WXX(rP78y7azxj-`L+LK)jo9y#hyAx6g{Xt|bFl#f5EK+d
zosnE22dTU37ZE8w={s-WzhN(uC9`Jl%dajHi*Ssa1CU2nL8S+Sob&Fm*M!zq@aF64
zdol(b5Z9X;<mPwA!)t8FXz=?%Y1^*jbWO&dKa0`)ls)%ycVpk&fY4wnUn#!lHPihm
z9#zLblBm?*BSbJDKT>z6l|@FiiLuDciCzETj7(Nd(4twxKjnA$Ue}i>z*1VSuKQUa
z+O6(8ubJ<oS43if-&&CrRx8E+20#AVgWS|@v3!*E$AL0JM^RDH-Tepxft;T=E$pMV
zXoK<iOF;@s%K7>Eyb1f=PqNxan2Nx0u(Z1~5g@aBbvDXx8L}Ps8W#Yh+E~ybV7P@z
z7U8$xe#A;wz{NPEc3Kr4OK@OSJpGEqUhA1SXnx0LAo}g!;V!&m!R6Y49ZDfp9c9Rs
zyQdZO@QaUb^xTcJw2TQFXprOBv1q2E;v+A)xFh|V>Tw(A%pW~FJV1TW&8gMxo{_7o
ztE8kP>J-Ng+TPsU!0#?w-@m=PK_C#uJe3_H3ei4VZWa`bEUpQhJ*HXdCF1+Q`UP3P
zbZ-nGi1r0d<GT?aYflWyAdo+$-I#V`hBjH!xN3db+No`ZW5x3iHdr!UnpXK*qL94o
zK|}8T;O{0H9At7J5s|BkY|E;us*b=5Cwu#?<z{Eb;PdJ6@$uc=T~xhcZf6hmIiJ5C
z*fVGcJe-4Adc3#nLSNaOR{t!B2Fl;CoOH7N=8pr8XB_TN+WYL7@TH~BdzA`anamKd
zis7cGFNujY`Z1MogfXeSjcW5{Eu}s9%`cT!=*rwvFfq^7AM9PI=*HJz{4-UVVX4J+
zMNeC@IpAz-d|YFfvpuiB96rXy2mm@?Jb8g8|F=ZxF9aUB9o^9ZJ?&3I9=+E4p$1$-
z?y+!1qNO|am%KjJxf<VaAye$mm8YMSTm`L;ZSbmXkUO6Xqz#skWm^kANPls_7|i!O
z)9ez5(IR3b-{XbP+XbrYMYEE}Osg5ncEll;kGf6pkeLFOcvcM+BOdS&+O#}^5cbGB
zcHDcy9G^2^MyvYAqIYM-i+7#;XzQq(c1%j@E<T5<rxSX1Seqw=*mnq%2ao_oK4X@p
zsa1}@>xR;j*@6*95W2l_J1I-*sQi09H>fUZ|Eo|+6X&hG^$+-(v>W*W;n!o5cRw<9
zKNlo^@#_Qhc_{zF7TT&#f)IvAW{+<-?)vOw=L*OBi}S({S~!iUg&%$P_O^L1dU5Y%
zn>$!NZ5ZtUJ~mhTP5i8p^KO45QQK`5T>$!P?(^cjRI3!M{8GYccdenK^J;l_n7%$o
zy`|0_PIFIsynLD12^+gR-MY?x%;4q1Kb%}@^&Z#P?90n!(ZAc=8hcm!N9KEq`(Fdp
zs|CQAU=jbK9^JjT_ea}qgQl45AuWuszOF0(n&3J~4p<KX3C8fpde_4{$BpIl^XAMk
zva)W%+%cZyt%Ic=wJ}zV{<P3n43AoZX+)GVsC1&yqRIfE!Xzb`UJO%!E^-dAGr^;x
zD!;u!bpYT)X}vgsnuCO)Q<E~UbB2IEHkY<$FA)F)My7YWXg)wvLUKX4DAg3=DOxNW
z`x?N58y{WfIb{ZiQa+(h7FP9BgpKuU67X2KL0j%*pBfYr8h%@oj$##SpBp7~tc_%-
zsTW&IZm>Ji`ydc;0u&i34YT-1KK^o#|1c7PnA=8T>gfiy%Ma9H5;_thMta_K;9jLI
zn*R1d>Mz6C+k#__`{nmAO}N5p+llq}pxm|e$uGY<`48$uJ30|NhjFa#3-fW?$umTC
zqIss6r;x0*#4qrSv)r-8o2P=x!*j+{%<(P)Hd*QB0;lCWlaqa#R_hR<3kr8o`1=`C
z&5I0^(?WJ&eMjo&j+FUr_GS8If8rZ6@`Fo>m|LczY=2R4`Zz6#lAR%z7_>pZd!EEt
zYJdcZG3d?7Z=PvMI9xUW<ep)k)g_p`vmyD77S+&z*3k^y&|}latR(lAjHJFWQQ3`u
z7qOmsWZ_BBI0pcs4=;w4d{a-D%U8LuW|Nt3UV19y=Qk2?jHu#`^RcOX<hJ>h!A`>*
ze9l2hna{MF*#KKRTB~mcXI4wfv~mP1%@|k5es~ZJeVmx$weUs8xG5g1oG=NwaS%h2
z`abG*!m@K>1f1s@)b>GjdAA^7ZqPgA^UNR^fuoEm@{O5X7B@2bk5&=^@eO;rTaN@?
zEb)0q7u}FpfCGpcA<DP7d$LI92BZAxQ(ejuIP`*2PSSO*E8f4!;7o3c3NAJ~=h7PR
z`pxiyLPMp7xiiyrPyDu=g{IdARI3&Igup?J>hx)+Ym&WLz=q3*DxcGqFEpT^(uVz=
zuZJ3F7$R|E6%7fQzbf%FNk+}44bpSDjxwYdk|!bi9zqQ!nVBO<<m46&CL>wVTd*S<
zUHOtfsLR9{%OkW9n1g4ve(KQ2V^2HvRp#X^4(;>TM!;QuQi!W64!M9)Ot7R|BGzX?
zx$#0rH2$Bqa-SP<L)fmL4~Y1TLl<6`-zGUF4>2CbGWi?TR~Gbh!seD|$a0%sc)t$2
z<BQNSG7}nF>RiryC<le|<@d7^OFU*uLjFM~Wg~zwSYZYP%FS)=r5EhbAMsck`D#|f
zsbrH3dlyW24_v$!B`xG(P!-MQ67!eq7_paPN#5TS+&Jx^o&_J8hfs<wvdR5Xo&D9*
zdsTHOzk(m?BM)Aki8jU6(8(nvTFL}I_{1I$)}8QjN@sCBo~vt=EW|BgeoJMA>|2l-
zUeKSJC6mK_HLFuye~qb1U4X|xtTdLFi0pFcmwdQ!8A&&ncNBJxl}rou<}`&6<SP{p
zj(`ihW}x7kycZU-vV2eEWZAAGV;K3L40%H9i<^)K=dI7g9?H2zuWeqm)B8o}IH%97
z>~d<6qQ2wGfoyKMIH|9azEOVjgvNxD;45K<*gJ>~sg@Ap53BGA9=}ugT{V2dBbr2u
zPk>vZqX60#{^n%BQldjl`Ujfw&9ctq<=W~l)@&kk<V)WL)xTZ|x89gaYW)SOzRA%x
zh#oFpSX(AjiqVy??L&|$d`g%UUNU#+_9J(ampiTr1<iv97(~LhwVFby{GODY?fWQS
z*}N(nMvoK%i(nDa1zl`J#+Gs=K3Ci)HKy`kZkc0rsi9Ivr{W-DtXsV0@5S=mczJXa
zPPo$ahjJ4=C1Nt+b+!PWPKGmDXsLO;MgbU$De|jHT4NM3+p>|O)_Cd5LM#B^n^*5^
zPn{OJ@O+CIgazHa5P@2w{5M~)gl$ubTt=Ip3fA}8OHSP}UN8|oC^!@C-it3Id>8eL
zb|0elsl?DGy^tyHsrCx=SC$N{4mn?N+3}TookrLAxb30sVH;LgeLP;_<d;P98TB{t
z$Bw5<?Y@-Mc>0G^7tb>YbZif#Pn{SXcpGGxhprd{DAa0ndD9|oj>HfH_3W)GbhL(l
z-b_6pV@)x`wFP+01?Oimp8lk5n*$~0QLECiqZ<$4A+Q#@Iwmo;R^@U?W$B)6MNsDZ
zjb>2msy^FXrg=0>VOqE4#d=H6D#mVxKQ}fz5A&<v9EO&Lx0`qS5spO8<uF;0)Etb1
z9oz#>^-`UW=$9;dkq38C<dhO_5k+9%>B^BK6JY^e^X}e{W$1V4^vb}g^+sEWZ<YVu
z>5fchEk59K8E2GCwD{BDy7SXRJ?w6GZulcd_lVfTcV&tBqyB1Of}*BE@RHy|$5%D3
zs-rYgDUR@|!ZGB5z%;!m%=oz6*B*^L;rx!2qXQ?YX?+f~<?IE%bj#o4+gqbu{B2fs
za7_~EvXSxWNqJU{lIvV!!D+d%>t&V^yxwr>BzrH8=R))1%@r|3<+CASGroEb69$th
zxPE_*b}eyL|L9%cB|$w`vtEW{L>joFe%IT5SalWd`^<KGjp&VDwe-*P%h_YTP3XXL
zW;D-Dx7})MP*|InzlzSA6CW&R7q?8TRhnsVNRT$}$($<@Y;b|@>|4-}LpoBI7JKlK
z+i7IN1`7tGO4DbG_EJ&vM*fZZ_A%FqLirQYHgNbe*g<`}q=l>-2YoxuodANq5H-U}
zz8MZ{2FsXyOv5yRN-}fv%h;r26D>d84Z?e!7-SpNTEThk+3zq-A`v<ChA5gyb`6qO
z3=P&Q^LcOjy1JL3;DgI84lCmY8c+LJCH;0X-t|b$?8j{(2L#gL=xKZ$kq$)Z#Pc*2
zT?yr@S;<uPm%p(JsXdMckm0yDSmoS%DaAd-iX)LyB&{f;tyJ0^ML<lOrJ1CR<S8;$
z*m9tV6lqV~Cvux4wuc!RzAsdmP2yPRY*aPXf>;sY6~lgTSB7u(IM!!oPfpJ;kFkL{
zEuSZBB!0RHj<wyGtj33?l*fI1G}Q5Zr3f?lvZUzioH?7rkB#$I!$=~!ng&W!h9*4I
z;?-@cnnoV(Uy7%So>Ao7CXVk)alFDPLH_>|7vJd<6j8k4A909chnpmvDf3{aD*syV
z896LUUl><sKXNur$0=>3-Yzo6Wl27V2B)t{a(>RuR;$E#L)2d&u3oV44q}ixEdP*m
zZ3n|sCd3RHV2q0qI}gFNP^8hTa6I#L98%RVj1N;_)th^!wf@Cp<7pmOd6!m<*w>lq
zVk;XJp{e_QiGBm9a+G-UYY^M_M2q`B?)P`v!VHv1x<@`8aXyu5C8%izRW-6y`emC!
zhcwtcOhiv<yzoEOk=1gK?2_ylQGX{EFI0pY*eoDQQdC8XDo^X#22*8As#P4S$i*3>
z4GT<15W;k(l*1W}v6y@W%9ipP%$vTYCKb6p9=|A}Di%z_sEr~it0Vb{)ph9}k^cvl
zI#%chF)KA;bQYH2rg9o4A6NPUiC)f_IJ1!|pP*82UrN-J&2vy+8+Vg2uS{|@J6F;J
zd<#W!y^5(D(S(6dm|Fd^oR-X!g@!C=DkxAJzWoSuc13Y+6sT~7mP783Dr!Ry1IO=?
zJ16yQ&{SE)U%C}LC!TCnoUu{zW9aPmEL+)K*lAUnF!AZnq$t4p@<T!>kI~>AI^W%0
zG1Lha`Qqb$-pc-eRNWXo#eUfqnWWsP8}`r4EStWz<!UHAzi7u#YqZ?{0m01C6B8?W
zo%VNqnj3$^1(M(y@pw74!~H#%J92U;Rlh)ihNu+Fc3c5H8;j*Lb7jh@_!CR^+z>^?
zjDxYDk;kpj!kLc=FXn}vbYF{S(gRi>idX8HazBtN+*-W&q^syp?0bvl+k}!go|^t$
z><5Ob#izRht7Z~y_r6+hIg;3A`=Jn-f$$ZR@9$$@s7`qZ2-HuaNNozkRTL_t_CG1L
z|6{fPooM?f{SVpwUtN{T#+X~YWFIA`AG|ucY7B4XleWIfzK1OIiZ-)jNhlu?v_cq!
zmukwn+pX;urfHWgJoQ7$y`SjK6q^*6zij-{MI_k;dFQbA7?#u7iA9QlPLN_0y?8>U
zrMM%TKA~2XM&NI`ze6b2K|Dr0_*hshM<E3>N&qkadS&pZ7Vjr|1oT8_Bu%7^U-4s-
zmU0-u>2aty!|w2sYqPD^YK`1S6(I@0v&R4Gjfl&EmJ>wy2b)-YXvz172YOyc1P|CT
zHF!8YVd<x(WlI^W;u_LRH8)16WF^0yK4vdoqf*KVOHuDv`{>EF<fGZl@LVj_!f239
zS=uhM+QIlKUaD}gXcB>6phRq%h=SFqPUfCOn{AT7>~3>5iZ)t*7^;}s$3-z!ZM|`5
zWL(UTK?|eKihdB<J}xI0?%{65%opwP?xn9NU7cj3<_8&QWbv=e<>PiD>y|S5#5F{g
zY9e*gSiTwA>i?+U5Rupy;Tg8~Z054n#dc7(qQJzvTf(sr#?fnKt~w)Ock#$&Fn3bM
zem)Zo3MgaGF4L`>rh#qLgH3OHaJ`=Tf12c@HF$zU#a$YMPdG`ZglB9ds@g8gRcJ38
z)82X${BU-5%V@LiL5{Hol15j7-)Dj&_=F>ERJUWqexfstydmwi{-)n{O0W8<ndO0g
z-r!tijOwET`rApwM&YTv@;^hkCsWv61pXT0@QgdHlKA<lk~*LACv*8nmQv}vOF9a^
ze$y1*9<LZW!qP$@fqkl@glfA9i`m}9s*QA%p#KU$IX_H6*F+5!g8-v67DLkH(V69?
z`JZyQ%}+ZeYYRc1d>)VZ<#fN=D_gmPPEPSdpNLW4sF-_3fo#IZ&ewIp8R1AY>ogHl
zFEIsXhM?<NjY>0oZv&he3h$U=5NH>thO?j?v%*K|=U6+HT4R@1wEwsDF4`-(1s63N
zdbwZ!=d>T~{a1Bf-^3}f!1{ThJ|zlQf-Afcqa#qBO-dPADuy}us5F9*Z$>_C8Lc+F
zdG(tn9}X~%7>HqS^|0NbE76=H_tqUKz`$mzCa<uTF6tEZle!^Ea8`NPMO_4E8_55z
z`OFzDqdexUA}Q{%iN7pQj_7^1HYa{tnlCp&P68D(7t+D%dvAsiU!J^v0khg7iCv(+
zE?96UPYQ3Ld7CL40|*%0e9v&tuHkdl!U(mh0BwP)Gc#tyuzBRGeZC%SQ<zCh!f?sf
zFzD$=0!8YW70>00tbQ7*=pr;<f%2dBs_71>A)cE6qSY6}?(p>*!#M|RbJw_>4CvDI
z0S{eIHB1k_=v-a>YyU2^yW~@mSNWLU0?DF@(Z#|tE0zx9y)kS`$Ex#9o14)(-8RBW
zqPe*n04C>`MNaps#GPoNF!K95yH?L&qmof4gB5mq)Sn0CGez;Vw#G`ExAMxeYeJkD
zX6CQ`p6zGR+QXbS0Z2<?r_+}I^6b2eCU0}+ujax@c5B;Xx^9#^V2PrrBt(aU7Is{r
zHQ$0IbwtBJfOa3jtB@18BehkuH6J6$V_wqxOGDY>?xjvx#&*15`@p-edRZlTthVAo
z{ZNbFgQ(#}JZ_-{UTR4LYNTafR;t9&75&UIM@<Wd8n09=UHfB}R5jy7!2^tgJ9~ue
zkMqhN3q+_dlDrI5(FK!hGV+elc9;`AFLW@R+;TayK3=r`xb5<xv1>Uox}+i}oPc7Q
zB10E9hdL-I+*BNSX?MV^2Kky9m3CU1XT=<pg{;!EjNU~BAFifrn#r~WTKil+jwPx0
zYbpCMP=1%Gx$(Emy)oR%dyuw2KwF%6b}nn9PZx6gLHGRf4uh(#>ej$)Jp>wF%$8YM
z$WCAG#{uxgF!hm=-L~KB$Dy;3n=xHUjqb?mq}c|_KX~xqjQDFQD&P4pgMqQngOb!V
m3ZTlr8{ogB4?ZF9(f)u(dq&zh1yC7iKvhvop-#>^?Ee8;is~r<

literal 0
HcmV?d00001

diff --git a/doc/assistant/local_pairing_walkthrough/pairrequest.png b/doc/assistant/local_pairing_walkthrough/pairrequest.png
new file mode 100644
index 0000000000000000000000000000000000000000..8d3f603bf47c7b849188d6cb4bada0a2d774c57a
GIT binary patch
literal 5383
zcmYjV2T&7Aw+^95FH!{oK@^eRs~|`bkzS27L2Br|L_h(#N|)XON{IwQZ&F2s&|7FB
z1kg~Vgx&%|9`}F$%zLx@ot-^1-_Evk&Yt~XWS~Pw%}EUa0O)j|YMNZP2iGv81YS#d
z!^>+4pm5OB(F73xEkzx$v}+BO&(jzF000g1zaRnR=5t&tZv^P-Yu#9&qG1u?!e}VD
z0{|@Px|-@{A@g_}PotN!IT0~c0jXy)yd<wkf#fes_`1hA^5(#|o0B{zr}8S@w!P$c
zs<twNkby4Erp;~o*bt=&gRFw|92?k+-T45@EBl2{a!rmPhWpMRxNmULk__B=47^(-
zz{SVM7jO@sEKK#rnxvL$4X4tRTx_}ih_{-@w!nYKzdFRLnTw1}kA_Krj4Wp6|KJb&
zh=SKEHdwU9`lbSyL|$u}GNFxA2U4eo8=4fXJ2F48Lb|C*K5%uvqaa<7#AyEg>Z<;e
zHa=xk608vu#V>i+iZ(tmhEjb!J8-SBF~@g5RKS5Oo)p3}%va%5=OkeD?oPw~f9ro?
zl~iN++%;_40ETk$RVujL<hl6y69;ST`BjsYocwaQbAr+HPPa!<o3bm9^l?So3uonm
z(N3r`+u_{aI5y7f&^Q@}^^#9Uf-jEF?Nq;_PEM?lNXs%8kBHiaKh?I3I$E{66bcey
zMg#sVjDp#cQ6&72dx3``$Nxyadq#E$nELq53kmF_7%y^&t{{ox9_9!JtV`7#ehhH4
zup8sfo1UNb7krY7!0#5+pfw%#;m<d412bODm{q@N3vS|Z*Hud?VUsjE!tX~AtR5E`
zakxb^`#X8G9N{`@VOFtzpTjxvz^`Y&zL|9zi!=yaXdegoFF}0gL7`Qok4J7G{4q&A
z<H1+Y>%X+Nt!>M0rAU3vb^MChFdX?v?C3_%<&y_3cCR1SL#?@mZtBl@1h=Z@)u8#c
z_{&A&#@5w%K!+jiNiPd$rp=6jZ&S*eiN`zM8AJ(w{&(z5z89!1_K3*7RX_5H)`sV6
zr-MLk1}osp#&;8>7T&5eHv|L}NUU_yKPq{e|2|Ks_FQa&Sv7(E^?#oiyR>l^KZ(dd
ze&-+s*<)`NBUPO=eb7rBz~iFD+;rNt?!e*^Oxa?Z=_679lOLSOGPm`))$SA6j5pe}
zQdp#_eSyn}?rcMFfAB|_N$f52$M!il?2oSAh(erQp4Pt+mo7mk|JcwemF<y;B$#p+
zjs+_fcxCBfW-E+?+pNX1Py@JqP;OqrsWv}9uvNhhuPaA?xJQs4x!%Y1F&V>&33#>I
zteG*^CbEjkqIe+bBb>{=67YRa819w59rdR2V9<3j>38$Nh9|!xNu<ZighRv+%5K!y
zlw5E)3R<@2;lC=BQFR!kl>tM3+~jH<#bm(DGNzjY3ZP^gg?}NdQNu`;y*gAkrx!g3
zwNx5-GtklC0et$sak$noT{Ik@-RxxJ0`?I%m#2MXbImn}<s$Cp`rrjTMOCxeUuqUx
zYgc&eRZ}eQRSjRdy;AeAv!{b+!c7s-bhYts4_xs9N{yEtomr&0szmM;2r6t+_4Br?
zKdH)cX`OdO>Cx7Uid7b^+W558&+3=`J}L3y=qX!so2)8q3+${cz!PuIzzwbrkkg&<
zS}<J@2wnS&ge&A$CmEP9Y?8PJh6O@QZjW>=!bkhlGW#&|;_?<2!4?IcsHUZ_T?^mj
z#lN}v<a@&4<(8ttA`gYDB<}}@;82nua*cJ3U(^<rv>f14i}ug5^oT(nar}78<U+iW
zErHVcc!Y+o(pb?x9d?h!GyEgs7Q6UPwq~MaX;Gz>k%{$$jEQusR13SHd!nwEQ}2BH
zI$U*!es*+Gppye&&$*rS#-TJ)7NCoYVC(GW^}NmGA$)!7=4!kgwdx&>eOjy6>Dx}M
z3NA{YruI8Go(H8QuL{KI7^e?ykR{KCY(PNok7Bv)968?G6t-Z!kR^}uT~Ny*p%EHP
ziI)T_eI*8NE(#>WnqvIf`GJb%6XJuYFR~S0@IXLSMchY=YM@c|47&;wW-6dfuC}Jg
zBW(qo$090c19|qILvA;qYN;MSX87Pst*}~e7pfz+TubIeueS%KEi%@Ys;VTAg`YP|
zvpPbx*3SQ22PkZ_ackak=u9}6dMyuc>k#GYIWo!3veqnCk-u8&7;u{>S?0hiM@+Z0
zt+)~0>xobMG<CH$*WT$KtCxd!E5^hiAaK~U2<+OrMN8bSE!yd%sEoLuA7jLl!LKWw
zr;WzZH)F`{&7Eh8%Es_P@x_h~xE>ysIRMqjjXR$Sa%#9*{|=z00-#u$<Z-G<DZDXI
zJ|9n7T+Pk~90zge(!P2A=zMLf)|Ukk{>VeC&MZy6@WG4K7YZR<S-oVplb^aSALeJb
zA3M}>%zYBHSg*=30u=F#4^1l2-~Rh@Z9BHq`R0g=gpD%&6T4n5ga>%PFXT#Qx~zK%
z53-!_NT@)uQBIfUS@7Y@$qlxq8ZvsG1WVUDZHMK4c~CCmQq(0b>$!^i+?Y}(-(@vl
zyq&PT-?R-uJID!RFr5T!WaU}!tLCA`Anf}9H#y|3!e($BmcOW&+ai8RBBs=d0Q}5h
zAefH>tVlwlCAuZXy&3xk9nM6YaIRO`rVk|GjLeutxV(Xe_7+!eW1F1H`URWc90CaP
zkX6f`R_8mTZ@YIySKEB&kbbYsx#V%v+N;rH^uRn~`}H?W?WVBUiC&Y}Lf-w5KRZqT
z@OVHZZAS#4yUh>9Y(o!u*_05y#>QyHis(tFnKZ@ZbRXXRDDNi&ma3ke^FcTeHe7IP
zQF%a2&05UT5B?e{>;(KgzUt>YsT64bzV6t<wzIOsyrA`AkAF-~&OI;h)b%0S%V;{A
zs&<<#5|)08Y3mM~y(wuZQ@q1%i=kY)t;Lo(Zoz;7`9}rxAAT=jO9IDkKR>A9laqXb
z4SWgB^Q{l`DbsK1ACFYl{WQ5KrI07ReDb;0lk1J0y0HY9F-<YgN~mor^xME-)zwcy
zlOK(y;idZRO8DcS#x+6(&nUmL1sE|q$C&R1r>hEQ!m5Y=k^BoVw#p2d8j?)qpE!*?
zI8=j{d%1aWa*nrHSEV;(d<!Kg+X@Y(uU>bH(inMzyg%`_-AM_c+jOwV*zG^ybjmnR
zF990~vUm&azb;R#iy^x97?wcI>#Q?N%_^>hs*MU>KA@0#;Gt(YjnK<9Hl-Q&<bsyB
zF9^BK>dp*IOs~iao*nNBRb%%SCWPSvonmfSQ^ufk0}c9J9Ei^ff8Q5$6Ce7`%l{Ww
zAY8sHV*u@EL~sr;z@o)O9Zq-p>1Ib`yZ@MBv%d`aOEgCc;_XJlRnxw+X=wk!SNLGL
zMzEjCBGM$z2_susf{4)1SuNtp38geK^@ejEQk@kWvrAlShXmh!VGC#HT3CcSEScVa
z>8&Z8`9@Q{cwp4qw=vXnI4%Hpw8EX}%j9~7^0q0~%MZlHp+hHlWAVWPqKD8Vu<>lq
zP2m>utL?1!&;v2(rfbO)eVw=BH))TA=gEnei5dX>@RaSiWe~u<uYTAlEb&T~w2#3x
zr<|N>OBmMj@<crH0!t%EzilREPh^0(A$g^!mAc&3cPSFbyX-_sng2SpOi3<hFXY}-
z&T4SZ!3VWP*GaiRBXBE%{Uf3EfBda|RKpIK5f5r1u!cL%n`$d%tg^gZy-z@IQ9H}1
z8O;wW;=YmRQ}^|K&Am5yS(Ncg#(%32b)LG(gsNfhu5kR%w@$eV?7|3_<RA(ucXwVn
zy(|IhPmFD><B~N%hsQT3%UH*ye4;SHS4?7;%n<bk=&ZfkPaUpNt?gi?ZbB7=Z{i=H
zFsS;`%zq!0g$(t~<0Gf`Y(@|s#!fL+kUz~Io>_Y~D1>0VijA2mRF3!g8h+`7>io;j
zule4P120%~s2k_v<LkF><}6Y<pRIQ~ym3>3LdQp^yDw#cKYuyz5EF%ZBmuuV@Oqc?
zUCnRhX-c{G0*^eHsabv6BwY9KRi19ec1ACT+;;$AKRrv_Pir+4WeZGx&dKnW<8kjU
zXMM~J^Ks8ChC(W)EPF);Kp$Op&fv)#nC;}drdFX7%(@0p@crWJ_-a%}%;hSi;#bqX
zCq6_hgIO;*$!`+WW8|(ld~`{wLTzj0W4&e{jACV(Iq|>>xgY;zFbO(c4pa|-D6kVH
ze_H8Oa3%B-HadfV3D#+W95U09Eyu=jT5L{LkS?&JIz6D**D#O7N$hm|>kMRW)``<R
zLXI!%{)f8*Jxrt$Yktl;DE}OU;&g|4o!d;mP;iy|=JXmu^g2#+6|}N!>tTLbYcx)&
zn#n0Y&y(}Sn0kOLt$h{Gcnl4&(y(|U$0lJ?H2mWwW?$aVpy@is=UG~rSy+Rgn<z%F
zuiC8zFeJjeMDq5|XzXHq;Nef4P$C+!{j<C1L4W3tuIW_<%N~WOSW~?bhtmr15Q>`|
z^5)x=-1p-^?vik5;?QFI3Q(ys)xYkVak5?)ov&^&xWU6YZS+E}TP9>`i!6V0(FiRQ
zZ^S1>Do_jGl6V$sz-}Pg2<xmWKG{qOl2Tgm<Wp~5N4NMSjkv7ji{N1Q3ss}?cj67C
zJEmN@wXs|xdC;}3cdXjVmGxbP0ZO8QS{-t3hck(84FC)C<BW0Y|ImlYMhCRNdyymC
zH5#$E|Ci3jckSV_!$7N}zYek&Nvd13GW6FK;{+~62hTTlZYJtKHx6$6p*ppwib3+#
zfZXTeyqbdiJzg<OpCC_JUoqmbQH;*|M&wReoF{xvmckYPuJ~v<-(#Cu=-F8NUy1?t
zTj$<A*8@x{b||};J*x8%>6bpfm-+8;<=43x@cC`@!GyQWKLr(dJP|uPNy)t}_NrlO
z@!sxxS#OAsvVm)s_or&#vUXpCi?vQbPFL4XD2RPj^3GJhB6^Yz8mcR|0)&o;!J6`v
zEv$`?2kLqTx~U-9q~yG?R(UJA#F{U!MM;H$W<z-E)^(v+nXF8uJG|1204eJGkGUQc
z&`dru#7(LqPL%pNlwK^gzh<Ft5C8S^Z2@I59@_Wl0X+Y}3kXrCRy9C`-ArL|JtYeK
z9a24Q-y<jb^%k(05{u>(zcBaiE<U8e&%?0sxRlX*QF;sPn?DpOM)&;<<RnC(Q(}8t
z{avv+3rs5p3XgcvVbJ{tpiShb^{0L|>FC@`WOnm<u{N**omfRvczWZclZAvmiy?do
zl&!qN%Nm1<_Za#U)V8IZD0pQUuIFgG{nje)mj7PtHeFqd_&*C|@$Y9ugOT*M7I&pM
zbB-Jseu^$**v)o3_=yK_1&#RLq&T(apf;>p+Z^dD8EY&4$RB?SZMOLg^XzueApfOz
z+5M#~^oau+3bmDP*X|OnqbM$<z;w0YPBwJ+Wq4;>)=le}n=v!j$**3@%uY_oWAfXd
zqH_TEdA9-_UCuVB>TCoWpuV2iy^7m&DmwGb%hMZo4QJ@*kNc3anD=(89*PT6JqeWk
z{IAbFY=9nWVR51`?cd{NUq5*x77uq-K{V=G6fmEM)XSvw5^`NEU<y`p1y};$arBq&
zIg;?F`cbzE2RqU!m!oUbhg*j4#4~Dap(_#M1P<j7t$HUDqD<jdS=n>EJ7e=uiTz)f
z{Y$qkdpt-|2u|o<1^nN>Pq@dc_>H=n&;eb~oJKpP&ztSo=$=5%R-$ylfXCJUC?9dV
z=??#7^<TjVHUwRg0@x#={(t_y>6POnJNk8qgM-}x0ia3Dg=Lw;@9}TGj399a&0!J*
zj6llBv_*)2HoR2p++sJ@c|0ROd3t<QpaP$tMG@1oEbIEf)xC!KMxAfW?p+pb^<)t$
zYc&C}KLbFY2Z>)V3bIgE#lNS`s~b=M<xDTaLZ%%T#C~7~P7Q_4m|^LGcF8V@yX~KH
ziN;HAv71j1<~)$kYZmH{pT|$Uzq@^xE+q97S$cY-GZ>N(NPwzH5orw_lRZ0b?*AJ5
zLL8w2lslH8#s;h9H<!G*MBPzmoR%^PjfprAs^#Dw33x#;**bEvvhMTo*c$j_KW`|Q
zr`6R2Z8R&VxPJ<*?YLjMx|=O4*I+BX8}3#{!VF>tjot4Mx>}`=3L()h6|M?Q%xOOf
zSw2cO6<kgtD*;MlMo%AxsX}DK&U6L>o6LIM?uMzTK_;C2NXHY}?sg2v-!Q{@0pPyD
z?Y!LPxF~M~9vJoXanFp*w*mf`@i2qgnY54s?}DecZ<&_fG}8Cxy<u+Br3@+JM+ZeH
za|RwX<F<r`e!0Y2b{00Dq{Pk0=wm#CKmueO-pL6_jwctlNRc?9Hdl~qv;L$czXrIj
z30mCP*la!PZV8d4W|Fz6YYcoH5WjshGFHma!tYLjEYHPy!c-$V@o&p4Z8;%(PuAoB
z^6(Gqy)l>L)1*4>RhRdls-2^4YcDI%gJZOxv4p`M(&DYcF<^(oMW$f?eD3S57xsNa
zk`fmWv!iCTv0IUM%i*`ke9k&jTm4{ure7A62nN$OhK*{0&6%Y_r)4D|K?A560TO&G
zKqn#<%7FPiNHP<0*3kxIkQ&tg;8(ogI2gW|>)f>;GWhYdA#hbVLtMaGSs4&#|DGgm
zNKy~T5Q)kfS{-~8!uoq7qW(;aItv)t?;;(mU44%^#gv0${_m!W9v>@-_UXRH;#KAd
zi#92^ill@komR#gOUNoLWn_?%x{afHKRs^#O=zJyjY;JB@Ugy~^c%1p^*58nKQ0r1
z+!SihG*{d+LL#56d6c`9NAT5Z(?AW54-BrO49ynB6+2!8?+o)|C=pbM^|+a=?L!U*
zjV&hwFi*04-jHNGtyoGpWoCF&5-Uw#CL2Q9^b3_>CV(emXbiVczZ?3=MRqTH;GR#U
zSaQxvPF&}OiPFH#(4&`Kb*e8IUlDAg>m0wg%#rQ~IR9n{TFY2T)sYh;SJ~_tgzUth
zE0T56>YE%p{9I70OkjLxuZuuXQC?5vKUmA0(cnq82H&+3@o8n!*BX8f4z2884v-MA
zC!^t^wGU9ND}KjIHh@#fMxk$mwn}383`g!*jsH`2hBp4Ol43Wsmb$)pGez_+3CU;K
f|BvpvZX&5;H8D;Zo+y3&WeL#LGSIBjuz&YIyUnj5

literal 0
HcmV?d00001

diff --git a/doc/assistant/local_pairing_walkthrough/secret.png b/doc/assistant/local_pairing_walkthrough/secret.png
new file mode 100644
index 0000000000000000000000000000000000000000..1eb8051222869ffe4f9336e991c0de46fad3d52b
GIT binary patch
literal 5132
zcmZu#byU<%+x{WVN=ga{JS^St&{C31%Yrm4-Am_Eu7q@#q%;!i(k&n%t&~!N(k-<p
z`QrPX@B8aJb0+S4?l?1Zo$Jg@jIOpSG0|fp004*~YD#(lfF*rDwkCLR-xjH@(cgD?
z)*7lxz}??c)K!souOakMGxi1m(4)T<3wV=9d#}XzfoLh?FA;($xkyI0x%&a&Q4T~&
zK|f&OAU{kuUG>e-hZ~a9;)zOmN)-ndusQ{pzO{>SG_9SYg<3Nv<NZEFLNp~CMpw^P
znx6M55ayQPsi;S1O{lL+BO3JDKSJLs-oqcZ`>!0k|I2-@;#6fbGNHK2_&({evzz0I
zhaUyU1jC=N|CvcYztp@q#Vnp(gtT9UROI^l`@dp-4MEBq$djcJ$h|`z_q0ui(az!v
zMTxD?AZfWUw}ct<>m!mav;X2V6~mCf9(X&Zdk<#Ua(U`Zu?-|bs(}_S68jA^YQ8N>
zs~DlZOc5Xt6fZQ9BLlR~@^Q_5UBKOX?`0&};04b}+E4?jkZ1lvi(;+DD*!lnFFjuh
zVUejEvZPsufZj9Q+tn=f3Be-gi9jt**{?49BPK7x@CY8pEA$pou5x(bV&kyK3)Zs@
zTpIPhfNzZTu^6)$!<vN~B26V4JQl+<qv|6_Ul~o%*%0C3uBqcTc<?_c1_pb3a(Xxi
z6XgbldA6`$s8OG(ON3~(&W%Q&c{+|{|7x;)2)Gu!;mdV+9_K}x14@kH)Z5SAAd-L5
z@upVLbe<+ZcBZg;b5dV-gKVv0Epg-9UCz%i`{#m(96ck;ahczXenA=;P9!ovy8dAF
zuK^oc7iY^szjzKgH+z7hGf11oY1Gi&2~Q=~bF7TEJxM&7-g^vgRFHbeS!%|fi;f8g
z+JAfYNK;PIz3Y6AQkS=eA<w3i<GR#nWs9IkV*9)tUmk(D(x(md+?pFyL$5Ioc`bSy
zVmvNl%c9U>(pD8>%PWs$+F1oiWI4YJaWy|mB~K;a?j#LcE&swMA{)FL5-_}Cw6U}3
z+YyR{7V?Zwxj%jOIPaU^hB>-R>xx_4Z2}^ho>u?C>m%Nd*G4}z+A%Kl-{EF3ypX|w
z-#lUlsPe5uQ%y<AKaQ82=ygzI-bKy;KE%FKW1J2t6Z1>Yyrl5L!HTKT|K#IGIe6~8
zeC7-+sCqipsr;GIn-rIJaUa+<T-4a3bT6BGZt&%GlTg|5?Nc$1EhAkFI%1m{(#Ij1
zm2kuuS^=Kt!dOJo5;^9*yA_5ZX=P~X2h`NG$b8}TYFg)fUq!&I{f_cJBNW6{gt`i5
zoQvHpqV?<m8LL~2d7ehr%Ut;))-0K*i}uIMnZZjwvoyg$rA^BWWOdG#`A;fhA=u1K
za||;~`wG7=8-EoSFI=-yd8Ln{Dm|2*E_&*GB<y<oBTCF3j<AM{Jt$TY-W5Mo*D>`w
zQ;VKoYO)`P0*OzKUbeZ6zo}>>oCn^C9mZBw(pISf3ofyVOdqWLMud&5%vXY&tGCUP
z#JGz>?EKm*6Bvh+OiO}yk=N6}uD4tqk7><HD~}NTOH7bA+*ngb(aB&(ytW)xTOZ=v
z&JR1z^`c_rlL$~GvTO)~&-XU8sjAc^a3x*PA{2<mN!}UP9h#FzkV0wLKeS9^lv~hV
z)8%>TiW#|LZ#%x!%|WAx7tgtH^L=r}dMjMTsW&!C8N71KI8le?bf$VE(u;Umecw_W
zyBg{^-IrxQwvTsd&5|HYeP4zycXv{Tm^OvBp2ADsI)23PaYaAeYxXNd=Xagz7g*(o
zYK*)sCN@PRC_hn`Wm%`D%b35+K%9%ub#_#bf$23g<lMBzESx_xxh2TD`z3nS4XI)>
zXI1S64rafq+UaL7p2J)_<6hND<tw1ZJ|8VO@a`Ek&lDNjZ-Yo4n+Lb^QH0kgmbJe%
zW?<lx2~x?TYB6-5v18<uIqd!K{+0SSV1Yx@1+p*^UUt_OGT}&Js7_GtNY`aSQ&7kc
zCsitQlQ&&6MFJfZ(~cN@`Uw94cH2$&Wj&iQ)2|42)qT<38L_Kw<j*%-UXNtILr=~8
z0*__qjf?`mot@P6<g@*Wb_=O>*Q%sUGYsh*a?9M176D3MbTUzj(e8DN+l0mOANCYv
zuKN?kkx1?jxOr-j?vppjjR{CeF9lklckJyUCqoE$H|B?5NJ1X$6yY$C&%_?qxpnEn
zCON=P%2r4QA5XLh67xq_ahp0=+#TlDAMcmZ(;dfI8yMwNu1O-?Y*aDoTrcL6o2JZM
zI@fy%VB@<3Xl`3xl5VWh`6TJF5^jp8_EqltpVUn#tDmV%6<?k*KDmxxXOK@P0E94b
zsEPHMH5E`3D9*z(*l0ALT-D(@5W3rt1-AwB#Tr<h$4N~#DFhr*In)tU$3K04w>WV)
zQvRv$CMU-MY25(mhasB4(5cshxWiKzVj4Xxz?Y^j?E1EknLL55jfB)4yw^A5k;|rs
z1LSW9O=YF}f@WWvQMFm!jVs8Z`lG7I>8l|=&bB05sH}CBIJaaIAGBKVB<5he$C4kl
z$dJ>?E#~J0t*JfQYF>ZTw|BW@jz5XJKDVoH0NL?;t&R=DYvd-!gvof&a0XvN+0yM-
zqXJX#S%F%j_oU#wBvmMQ()dt{>UW*09IGT#qF9d~_raej)-neZEt4(!$dcFsq8EX6
z#C;vs%FLn<tE}D}+G^RQ@e6E;Bkq@%4cwG_kr(5biOX$OUNVyd#rX@*jFKG-_x;lb
z_&~3efX7YS*Zvt9J5!$+CKTz3uZZ?cgB0^Q^n~StIVxI(9KFx=d;^{B9~6rOb4Q`T
zIA-yqiLGE|1G<hA|C_qi*GtF@L0<(b-t)$GO+Bn)Td#uUoSR}6Xdd~)1|08b)isH@
z^&Gm?Dsz3OvI0L?6uz8|N1Z?=@x*UVes1}gx>Ncv2XP)YXjUbWn6LTS3;I$cly{*P
zp3n&uGbcd+Tcfn62Pb8A5VN7a3o|5nfx#f@yLP2$@?(6C!d1z*jx<bj%&uTn%Ol-{
z6ZPh;e1c)wOfp7r@#$5TMP@=Z@(qQbiWua}hJ#egW~bSSag@%$uZ*dsDVj87iFIb=
zq+2l6soMenGyl3~LGDnyk1-9eAQ|2r-CRV8Q=$wg|8Gyevc1!$RAOWErQ36H85g>|
zPKjURO?B8*9V$c#_k-C)^$o_85-(OA9!|JN3~jmSR2JQA_DjOV+MUVr1h0;>HJX&4
zA0H3ubj{%XFh}QtwA`Pzh)SKa0fRTu1|SOCD`eU5?#T7_OqSH-jJ}~pyUY<bL7;sg
zG{n=<QO)YdMH{}lnOWQTgNWjW$8QWKxag~sc3#}nquYhobG|*dfNUZAFP`zt639UR
z$dGYf{p-rF8NvlN$$Bqub4~nAhT7&Iqx>sO@7luDWRU)X9bGeZW}|FZ(P|~8fBuit
z9@gT&N$?xYQgKP|NQ3v+ax0Y_SF_v#eO*CCQ`40?qQps~wO#^=3yS3@0w=nqDGk^?
zZ_b*c%(>m%LavrtYnGIBLOUgxLc<%+UA|8U5b2)ts#|t^su>OKXfEPq5#lT9(Jhzp
z^t)YXs&qRG_yJ|y^zHfy&DTSBv!CtK0eo*g=i7KPU4Wi%#32^G+p{8uvn<v1mSHj`
z#6_3&K8}bK&gJ-tU{*vMo_z3i=7LEsc**`tp>s!jSQunLdx&mrZS7GD6P$}5t^gaX
zi#Gr%)5s;-IILBbfBz_n`_kFhXVXP%kR7V!3z?OU5?MYUh<=7Zeb<jx`G8T!oD`+R
z{-7c;stN9il?7?qFQw?t|3eAJX$8Ave8$EBe*7dWA$(1S=4UG_E`D}MW|;~wKkE;4
z@`x%2Z6}*Gkcx{**m)xMT^TG&Q|hH1@!@LO0{;Y1W{IVGw?txjXd@{C)Rjm-bF-*K
z_@K{Hon_O#Gl&Zht~Gu8lMgU`(EX;1%2e~|w9XzWXoPx<6VY!%U4pu!IrNtr!SBS4
zYQTGWrDSg->^gM<9BQc>8Ga2x$po8(spOclAI9J!$YbHdgrp=?ZLM2+k(c`B{*dSX
z&(7ya0;SmI2cwqend_>JibOlj>uUzQHow=HQtmH}!kw49VCm4J^(?WoU?@uXq7h%I
zW<p*4p}!pEKLgh3?p%0SQsnJ#y>N@Le2QI4EICP13P+#*`o;V6vlBPa<9)I;+edya
zk!YT$8rM9$#aw}+j)nhC((S7q^})~;5t$n(0pGqT*nG(-*OU3?Nm{qK%em^GppOeF
z>rw_%UEgo1_gR((KC*eqf<L*`=kRT}^w@6tgReU}EQCDo99>*MAP}O_X5ZaSDDw|b
zk-j{PRwMo<CXismIj!dAb;3^zHBE`6W-~^iOv#pJs}G<e%f&w?Z}Wr*9uiUTdNSz>
zE?QT*M$DohXxT{PiT!Fh9!E*fpWU2u&8rgF@_SFUKGlRXz%q!+sf~viK?Wcp7M~^b
z7*wPTIc!DE8sABKz$6{CE+dUsV^&`@iL@X*|9UNjsMQzg|NW&hvNaIfnS7d(jOy2;
zY*-dQmtRf3b&vA~^#oo`9tMY*y=YX-M+YeDQN~rm3Vi?-<R^e5d20m^b8YEt9u&dI
za0$YZo@Ky9n}J0RKG?7?8q*Kp!B_mFd2oLdCJuAp9opN8>DB0nD_?!KgvBequU&?l
z_R_*ijrv-sam9Sxr3uF7=<LUCLIq2|2}KwOawmbty2E(ouZAerwiy>ql6q*d9Zp1y
z4?{s5dizFwya2o41j{FE!;Xx>_x;&#(%j@-n3j-M{fuAL&^9Q?!TX00<x|8qjS%~j
z5sTas2>SVcqFQWzcCrSU&6CkfoGt|gvNS?HUWH_9LL~D51&%^28^OIuR%(P~Rzv?+
z{CT_TfAn4E9WFAPS1@f@sY#w}hKHR1NvZLFR)4+kMI5e7=D*(mUoiG3CRV|npB8nr
z^R+nf#dGhYr)gIg-tM3f-M>c-!@5Pv_=ATZiQGxDJmt3*+reNh3GG~<Z8lvO4}PE6
zYeIDf;*R!ewL*fNzVSNam41Uff|Xo^eiarB8JX*O@BxwFeoGu_yi29?*yPr^Z)^v8
zc|xeS4~|8@2Qs<LaH&16>MC%!{Dfh+HPEa3DPFEjN{wXeBj{wnzqKzSR{jNOx3R&9
z+G;_;c7@e#X#21<2)jkqj^T9Uk(}h&#B?j3SAkr^mW#+r@aB4RAV-Unh)Buxt5<ec
z_$Zklq9_zsbl7gQlZq3=RW$Q}cDKdxr@~2b$DhuVSzXg+7N65G2a)e)MXYdf40fM}
z5j4Q;-aqK`A!uOMWE$ffLmFUNWx9;?y3^sDC-WX&@AGf__-;F=-&96l7Q!0{8ageQ
z6=Fk5DLeX60ta(8Lx<cX-v?9g+8sEZUs5r3QdB-KhDUE652dq^TQRvNR4xjk0v4ex
zDM_Pk+J~==(9XTXjHh`}so=ST_<-xS&pORcaV;_;R}S8`C8lzVw`_d_Z{v=427VN}
zPKVa74Oh^}anaw1ddq&h9OGDQ)Da+&YZJLY<=A|aSiY;4(R24PWAyF(d>l0<u0eYl
zw}w;h7Y)#H%I{~9_0B@qF|knmy4%?MXW!PI>j@%Ms($RNM(E0Z-qa5f?U?0Lc*YSt
z@y}1aVbH1FeSS|2g%m?OEwOjUsK5Bd&0gd?8f;q|NWJ~AKi@`2F7c_m9O@ok_61KQ
z2Z9(z-7eqB?L~WcuquzQRCizEAC$+2?}a&EEj$1!F0o*X9bvLEtE3<33dM_$nDD#o
zW|!g3lj6f%`Sa%f9bY0)w~Ibj8F~}KsZ1>-_z4{DqAQ99B{MC(_L{^ONnCBy!KAfK
zGLr)5VtQ-?sn#5J@r*g4tEBnA6)Pz9IP4-<>VjA|k8Z2R+uAIR$S@NcFNLPB%86&?
zPx%fNXcJl_!g<(b$8(t`N$iL(r0FWK#@R_$_n7#;i$Y@A24t;c&q+!5+z$Y}I_y7R
zuP^Oeop(;p+G?ZeNBK$46yg_ePJgI-^E?a-ySqi)+)gXQV2z<mQa(0~msfE&7p3zG
z+<LqTHWf<}m}>oj`t^#pp$~V53hvyLCTE!r{y9?YVK5>OJy%(1O18Nc;w{9_wp$~c
z#H3Fs4z(H)Ut_OX7dqa&RTT?5e)X1hG9@A3&|M&gI64fbcis8L>>g(M`W^zr3%W}t
z=l$mbrw=}ifp|&VnyY@tx(Wz%TrV#+SSi0yMtn4#?jCy~-~>nAP4cX4;Pnu#CVqUy
zTGpVJ8rq4mv(TMI9UjO|vD0_`_Vn7GcdT@*y)?MX3RLivYeX3Gb}1Y)-}8HdXtznN
zh<HJ7yktRIBp?(Dd=?DfON8^i?<cLm2Vgl&m*FUUS1ui5SR|7+aVx~BLu3ES6mxmU
zd#XtKdE544b!h&rL&;s5mBt~acWLFqRqY1FH|^gT(B9l3_x%s&3$pEUo!ETd*pTH8
zYYy2urhr(t)_}siuU$_yPUD7x(nlQNIVT!YAe2cbrytXQQT8^c;;Q#_hvsMnl1B19
zQ8Ebe__MRhsUv?O^F1JBM6QqbalAkh%SWRdkM6lhBo8*WM^Bk_O&k|Gp&gsAi8H2)
z(X<-i&#ovJ`!%gNjc1dD?yxlOIlTRZ2R@qQW2z;kPyUvlxK9(NB9v*pZ)<J7&rnvx
zcbT+#*EJ<m#(zztgR{~3Yyb3%cO~)Da9sr*|G`%_JmFQ%9Dt)K5R0A(CPWVY4@3Vi
j_x>g9zufz4<PLiwBXS86k!E}UZwEk>wUz3g!I1v}Js!wi

literal 0
HcmV?d00001

diff --git a/doc/assistant/local_pairing_walkthrough/secretempty.png b/doc/assistant/local_pairing_walkthrough/secretempty.png
new file mode 100644
index 0000000000000000000000000000000000000000..491878784504437ef073cce23cfdc9050f1d67e1
GIT binary patch
literal 9575
zcmaKS1ymf(w)Nod5JG@Kf_s7v?h=B#ySqzpm*5HR65L%U1a}GU?vkKE=O6Oj_1|~j
zd+V)PUEQmvs=KS|oU`}YRgsGFQW&UjPyqk{hK#hhG5`Q;3BCS`3=1tyfC;~#Cq!de
zDRBVg<(J!8oCLjt;wY`<0sx@ly&N!r^vu`Ln@FxQauP@@C}{XB9HK>LwEzG)Kt^0d
z)pO}I%h#6pFl!wwCbKQakx}7E9FY++N;5-4<A}pun);1qQd&Ze)sV8;943Q#PSofS
zRZF4}g9(PQw3G@yk+3L6lgs)LGe3Q}pY#+~m#j?AxHaHQE^eZ-U97dz5~w~U-Yd@$
zrIFQij<1gA$%HPdaBwrau+hw42s>nx-vPXT%YW&!@3luE6)~_)9)c|@?R9VfD~e1J
z@<Rq%DDt3CgkYo6LJQGNDriBM2`!LAFHtIzNIX9fUq+VxQCSXBsLxqEaNUs7N?9ey
z8<{BISP$G<kugw@ITI2f9B<tY4!s|c+6r7vN&G6d85Q4YA0&0Yug7%{)7EyoK0|w0
zwpiVEvPxbs!hX9Vvpx<E-gUhli%#1<4E$Yev7^iEdQtHE`<d*}xY1XJKM5S&N86^C
zM+FCNaW2OsEptAP$93VsAMLVRx3$VtbQ|Ua5hLWZXoImU<Hdww^X;V4U+>TXA|$^n
z@;1B1r|YQWg5s0B_Dt*#x!?iUK8Ei|PQSnf03-H^X^_aZVVo>5D3BT{32%gPmM_?A
zi;|*a0!nQ)zMw9pEvrZB04+l-8M1T^!&p>9FJ$TG6gZqq29=81bxEA@<6%(papF;D
z7?WITgWS!8i+sD{2i*4*Cj&ux?_j+!;>oo?c;vx`zWS{*%UM}5h4xjyVfg(Hwzy3o
zqY|cQgRS0$+U!AsF1eb)vs!9dg6?(yO^FVb*I`1<C}No-Je^jS0I8|<rQotS^X<Un
zzR&ZuWqvnPWjo*J`zEEv#GdNwYpksF8zw2dYeI+J7Ma-5u{Z_RzRv*Lu#)<DX6=>3
zl|97AE=!&%OZ@qjQ_0}V$K;Wng_Rl)cL9p|MGU0@!(vP4GQ6#5k2BMWxY;<bB8%}H
zzC#^Z=zOlvlh{GFD<hT85r#}x%VaD!Mt@C?ksTC0e(1;BT8QkXOo;Z*O|@G@&mlP>
z6L`m0iyJ$yQ&{t<M5V4}*fG?7(wj%g;b%49r#O7g-wPMQ8TDg}R@0W<k6|pzmfZ~a
zbVZsMluxEon9}go_9^eD={di;svfe?O6?`nn5Punx9AoVCSl61%n6|mrE9PjytY60
zi1>c8W6h)Qko@D+tZ}C6>W&o1nAszbWd7RI&GFz7Wxdy#XDyd7sdxp0X1-|*;VDz2
zBy7E`%*rfAzv9YREw<0>JgqBF#{n*%1T5re?Rd3RXle<|cB8$%SlWE$U0e1>AQ8<}
zBgH>br2WA0OA>z<8`m+06ds2AQ@YC}=gPJKB$)5bkZf$oE{7t)Tj8OjlT&h)?!DZ>
zAFe41tg)jlRR%Z%7Hu8MwpQvG+WO%Gti&v%Jk<t6vYcF=ZrxssPEQ|>N53NM?*>L%
zF8RvV>-}`DgR~vr6MWV`PnTrcn82U$Shj5C-)-?T>-O>*#be-U9rqb!^yTyzoAbTg
z5;}CP;^a$C-e<RhW0bXdH6T9=pPQn{R2PP%KB8%@DQ|43{YuI_bG{m0XW|ooJ+)rm
zZc))95Ufv<<D>`1J<b{8ao;a%eAw&Tb1!yB+q*j13Vl@}s!y*y6n&M{K>|Q`_*ysZ
zy~eJ;q_peW`c7eR-F=albGOZ}&&R9(?ah5Zf0{SO#PEFr(f&1~(fnQaW;2p`o*z1B
z#Jbe?=+X<wnEWy&nv23YwCM*qPWs?!N26~J@?=`6Yh7uKJNq4?oR8`fa*TFY#zlnX
zbt0_H`R{-zFvtk!Rj_%J3<2Uy4RqW`*UE03-c*ExEUXaRVE2SgI_|q!AS)H8{J>~y
z_ubbR+ybqkgqlpmGUFFd>4bU;8WZhaEoa=#nx^Y*TziH%z+GnMHaq<nW_GhjS)P>c
zxJjrwXYxGPn!9v9GQdt=Wnrp1JEw!|{DAbdDGG4%O6lnI>YiVWi#uS5IJ)=~YkBKp
z*0)J@TnyCYs`2bui2Qt{gv0tf58m?KP=b{5YEAn-N}Er)B$=ycCNzMWmdauWD%tjY
z&-nS~1wZ!{tDrYK#|JHZb@`it7pL=d4Tc04AExB>>xxuKR!<2)WtlAdZ3_-K&Gw|!
z4Xz8`@^Kcpe7wy^yA9bl#x?Dob`RTYuNC!jCT=uqN!)qaGLmC&<fE4k*sij(GY|OI
z=PEb<V=Qe{?`j&UTk2-a>kxwiy-j4<UN<zh1~JNpS2C;3zeJk$jz?Mj3xx0jTbe57
zcJBc_Im!U8c8(_Zo3owV8%uReYT}YM9O30`=y1C75#C0fqN9e)lO~^1C#cJ+uythL
zSvKSAQ#x3lA$zuMHMe75Mn`D%p04O7YnpFY{lvuzndX-3{?#^?dB#U+NFduRUOV0F
zYwDmKDdViWs`eFG+$_Aabb4?JNEgl}+om5@F;o@C*wEqXaT;N!6GWn}GBiEXU{Ek=
ztVSo~HI%%>AYqVDFns8&jzeim4hupC877Jn_hs~VVIiu{@7D{ce}lPew&A*LqSQw3
zK4@#oxkR1)r9;43*)Y|pQ%SC#VdrIqAZ*EL>cJygP5~H^WmM0oJo@Y8w<+KoYJ=$+
zMb}PF#=BB=o1v)+k`G*pZf}K)ZcfbOOPP6cm<JJaQ+iLR$4-Du1PRSkO1BHPBk3M%
zEoUB_te|_+{LR$#Wz7^Jmt|VGp_skXpx$9^Q3e77ERJRn+=z?&{&B71cb{H*HK5iq
z+%EYmr;0GfC<N-u82Zz?_b(QqNieLy68W%I;@n1pn>X2DVMQ<%LO0@8XCC=rB<$uZ
zxNKtfCLYX_yn2w|qEwcCH>SGcpf=MmEje%B_@jAhY%Va8ZfC*T^{JxZw8DeLnZE`X
zc-pA0S0Lpac=CKP-?h_+Duu3MPgdy|UsV`b)&}VF1;&)Gk*LzrZsmVbw*uk79m&42
zNMQT9ihpRU9qC4!=rplmBgSqmRpBv_NmvwguZ9G|RH{yM%AcNd<|XY4RB^Xxha82J
zL%h`zMy`a5nygy#by<fZHHi?uT7f0=+AGFc=o$Bo^~SmRJ1mK;iE4of<WblOngUK+
z1ssO+zFi;I_qe=CO3LY4U!pVpP1#lcGq=o8TmME!b=A~Lp_E<$h)1Yhf8KI2T}xH%
zU!AEopBz6G&{};DEUoz#dGzK$=`-_J0wo<kzZi2JDxP&yh3Xs0py(KL8zMif$oy6r
z{EUzB6u>xp^wL(+CZe88nhcxeK4)}G*h#}C3DFUna(3ps#ZM`C@1zj{wUf$y&7fCL
zEuK6F8L0}|ZF0)vCaa_dr1Y;_Ly*cE<$4IT_1|mPcZ4_^+E;5U7EJ1?Tcmu+a7kd<
z*V6+#t!1`a#o{l$ZmdRBUEKFLT|SYF3w=dA+7xA7x!XK!qfI~Cn7(LzeMeZCtPW5g
zG0O3uvTZ#7CK<N_yZE$gu$!AT72n^Jp!nTXZk-pNu=*=)N|BW4DdPRXK=Oy^5<?BU
z<5JA?5QQ#(f=KGS=UE%PuDPG2)GB&MX|aDMDEx>cLkCwJI~NnOryD&y1q4B^D3R2?
zk9p;KKYO@m$TbEQiSYz`eWaPh_YnKXi?}&wiR0k+`{Ol*O_w~}x;m1%X+?iZGnL?7
zs;B(i*0XopwO3)e!ox*)YvY;wX8C>n@>bO(GOu&lc7HDur65)EPQ1lZyYe)gSyQfL
z-tM2)^qp3a>gJ0jztP6M?2%?77bFBfRifm4<}D!keJ&$=s*+RvJzxv7V^2>tX)xi?
zCP{GMu>NZdb>GupIB>00XUy*Co2$c>)2@V$QMns+x@~Rq$^Rdt)!fcbz~NEXyF-cI
z@Lo}4s|7v{@1l;;gc@<U(=*sdWW=-%qT)H1h#Rh-tvfSmI0j-rz$|IR%f(BlVTmY3
zYg5394kPzkOilKtEK(T{@su$(ANQlr1MAqg4iU<u3r<a7J3h<PA89~`PLj`WmUxkV
z$}BxRAoZJ%b+s0*txWSp87U-8HwyvD-kcNN%$eK`k8uGoqy2Ck8~0Y62p>=)vl2M@
z6<4@0Zn;u+qbNmI2htJQ+{}9o$Z~Y%b#(40sxUvFGQD4hOJ{D0k<9BWi`V-=J)~4v
z#Ne(9(yKCYEg4|9$jn~GE^1j^<+DzC46Fh|MwwG2375p+$__5Qk}Y@Q=Vx8)^FOg>
z{vPG*-Jg>fTJUQHADAuc{_23bQ;AhkOqEib<X1c9IbzEuk|x+1=rPu0er#`jCCw7Q
zYViCOeF>pzOh3i!HR1S`UU^EejpV0?2$THn7Waz_$sf2Fs<Q~1ZM>g&29bYz@?TPr
z+X!vL2Rzi>2cudJN0nx=A&Q#;*rEqNh2g=>nMMRSNhwN8!m>qygjN&uyuVF$OkWCy
znF16&23E6y*_t08H}3l?5FR(meO-i77h8cU<WRN}wU`{!l=Y^Hj%bGNhiV5woj|UU
z&@i290jgKgm!yu=EH%C|)0B}y&gl369_(ZzMzt;A8%3)e)`MDO&<<zd@Kk}+`ATa6
zO@gynw3>@WUf-j-n;fIHYs@s7I#B>RyqVjr?f7pNo0m@O=|7ucE+Hh1+*aq83NXo9
zH-9k>#M4{jYyQ@dltO|c%cV#_Xb75J>=B`n;>j_^m5rP<p5NF?5OMHWzCpBsEKoP_
z>UkN+(c`AY!-X?sUcr?HIrttcR|~A{IEsG3#*+J#Jimk(t}A!-@$~03oPI{M=zCXB
zK9|tR6-b*F6Zd-xq<HhT09C1ngX7?A>Q4V!p!4*CwXMhP5>?wSeYz7ObRZ>|j@tzZ
zBxrWto!@cYm?$%&kTb!hAD`mOza(jvc?D?D)Blp8B|+1)JV#t;CH!%LK`~5KJn@5f
zqR3vnp_kCij6eiQYUs@0wKS@uEEHRG5RW?ZEQ7EdnV0S()@OgyQpHC#W@w@Zl->MT
zjVDQtL>}%g9xH}vk6;I0S`Mq2l>i|FoTbMYxas1vqlRF}l?|h4kODN5i9p?lnJy=z
zU+8RfkO2`Qn6`vUsiaOj-;H@tK>(0)e#A)>p>(5KcM$uOu^{xrFa9K4zCDMl#>C7L
z+RV_z93Z|jzWCDKy~B$Y0oWN_neIJtRwYY0zA~ORid?>zqR@iL<P-FCI=)8x&tzxO
zIY=J!CN4WQOA}?_m|1y2V1{06#zTDMcWAAa15dhT&GCF@aMdR8{Elp=V}jyUN~gtr
zn0+Tkg!AL`_tNeuo20}%l<x~Rz81x6)5j7RXuE?ekAJR|N0GmqNAP}H&F{-%)eqgu
z{8ut$@K5qWN7=p=keY=WZ{h;yXTXtZ$q{99=3da9c5|fu?{ud|3RiSc1b6%^#+6ro
zc({3{<U4$+^}&VEFe?=u?tpg+bbconwQs`^ai-w;*AV7Y2YjD-oizwk<~M(jB%`sb
zquhzepnn{hOCTx+`Wdht5dpKDU?P}wNw4zVO#7{{34<d;yR+Mg@6_L1O;f&^kQDV!
z;>7Q0M-34z=Mqz)e5L(`IQ%NHDbyrb1MiI9qFg5VT{DSRdW(}212`hcX@#4$3Mh2c
z<yET`qtXGLBw5NjmA+*2_HSkn2W}}^=;FIofq|ux;O;#{Y_0Uu%VW}QLOpNz{EGmK
zRDncnQOra~Sj$7p^M(k(2`+kPF)i)=c(WUvqu$B7pH4(bGN#VNp_4}*NnA_j0D35z
zi+g)q8sPg@Q+8K^s)D?(j{9|Nd%8Hl&fUuP^kj7ime>?iM+eGN?PzSsUzcz<!3T@z
zWH7eWxh^c_OHS4}df9E;g;PZVCigf(NuT&GSzk-}R*LWK;x5S#mV467?lgKyom)1m
z!5cP5C_5C-?-SLv!g%^dpIQuL(UgdE#m2V3Wjy%;H9(#uFlf+<-9a|D5Bqaf`M_UZ
znJ>7>E|V8S30h*7ST|ZUmqClBIL@-qJMgwqPgJR#3$m)@TE3V@4VbhZJaY_D7Xu`x
zs8?|5$e<CY^TB3U{W)dneWWx_7In~Kpp9+9i&Epq*7wkA%FZ5!DW(P@OU&kOtTw()
zwySm1yt`KrMFv^2%Lg}9zV=pHc@-v3$8oBqEx|!C?3|^`FID<y1cDl73%IY~pz+<j
zx-mcgE{^YP%h~2PH|0LZhY12|qQu>3%WCuR9sx7#v@XYq=bx(fsHMPS93&$n;7pz+
zc{=sq7={%iIccTC!p?7>>^DvASFdpmGNq9zkmPuF#dW`2rJ3Z)3*2B}v1*5DOIAox
zMNo=UsVihIuru!P^j4-6_M<tlG^Q4s>X|sMY0O*NPZv~8k!0rRRogV!j_GqUHAtr(
z+DEx^Rra>w4YgSOYRpUXQDUN%Z<H_jhc!CLSC3S+XGYY%cmoXHxU^%}P_~~fAsRDR
z>QA)1wb^Up{jsz~LsKjFYNiqgei9Ufk8=$l5D2RYqOF>=eV--DiwFW{ofq~EICM_a
z6q(U><LS~f#A}D(iMD<p^ee*rW+5%+rR4zr!|WK@9YRUq(g7T=D-$N`hK^L>egwAa
zCc$FcofJSPUNZsm`7+%@2~$thSSI$PLB<tGK1U9Tqk(EKJV8^~hsEzf2Tzd5O%k-V
z-ig4aaT_DU3MDzOaAkYeTJuM~GdCrFwVbwYgssu8WSlaM?lj|TX$ej7{`U6SC1PFD
znBqORu7mr@XoqE{w+kglOs}Y!{NRUO+w))EK4ls>m*G|Ja#-t%CZwQQClljWIApl8
z&V%fyV~a$+1~`-<@o;S0wkMsA{p|DDIXZ;YCJ(!QpS+Jh3>+xNS&Z`tG*f(Vs&Dt0
zVY!3T6L?P3VaWwC2Jfvren7fzW9n&f{C2M0NutZXv@At}M>>EeYa4xyn9dwt31AAZ
z6t1uI`b3)$7OH%18E3J^)~<<EL9{#`i;q2S>=cU?bBq4zxYlRaTxU^!P-eG|C~QJL
z>-Qhxt!E6SC?dY`o95D~wm41<!=up%u%KXbRddr-jvndj5!1T#b12AA!~vlk+d_~;
z!24=Eix0<8E)0I>lu2zOIzTG~zBjN2JtHEZ<7qbfWV<7-FKFjMV`>JNTm)~3PtgZU
z+t%S>FL&CYh8R@W*2uZvQWy#_7FI<B)Fb=i7~n_aB?dA(eAy1kDy_qN<MBEdku!?T
z%KI}E#7r16$!ZbS@8^p2KeY^PhR{&}p;B0NBL-$``U2MroQYi|Ta$G!8U8PT%Y{zy
zcgTHIZGvAQHZ=JiRQik`(D<u>=Euacyr`r9l0W|qu1FEuZ5tc;bXsKa_ra=D;dS2F
z?buMrrPX2$ZLnsDN(BDGrvr(8kVXmltjZ8Yj(k{Es3?Mx=P2lvh(bp%5g4zGuf|6Z
zDn?qWEl2<pkbeL#qKI#FEcp3C1}d`-z23>ClctxZ7yY25d{oPO9`gN;rnH6|MiCx{
zSD03qmX23s5{8#$8CP`E$M{<YYP@nynlcvw|3{;@p>ovBMW`)`vJ71qcz`T`h;U2*
zFR8WLhZw*Cyq@>_541R<oBRjcx*ufde|&=lA$Z{t(;JznEUJdcQ9sor#erm6J7utE
zq%t^Rt>KHRBo|ciaj@O6@sSnbNzIb5QTLPBw(*stF4&+gQHX?|v(7wF%ycxGA$ZDb
zoeOi_Xo<gK2)U@0^qSOM(>g_=EM>o2O%8D6G8Ti+rTjy|nDdNv-v55_4R82K_IelC
zYa2op=jUE8sc7vcO+O<q8uf!rm`8Z2RM@w_)X+rb?(~7ajAoHh@X2<}VO_z_mLUUG
zdDz|mEmWq)dLNW4yebwg=LZQnfy;=>EqQ3@t`vd(lM^pfoO_nHy7G?b&rLH}4ic}2
zMyrg9kML;D_A*h1ZLPkA_}Y>WV-9{|v<Z6aX{DsH3sc9)6w8h-lOk_s0Cc*NZy!AU
zY3L4F(aVKY`s^hKMY5dwp{xigU}0^aIea+!l_$Ey7wj8GsDa#3iT-@9$_`AbhokL$
zX1CaRc<vm79JSUu=V$Q=4t7D^V+Vk||NVQ+#v%Q{HDe{a%4O_G4`I+9`&5Tji4U1G
zo5#1*!F1L=ngp@vP0m3W;c+=iF-*~}98fc=Z5Fz{)cA;Q7ZxZ!i$S1Z)vGRd7iyT8
zuyGIU<L!07nV&kSKrp3atN5<5-{7`jARC(G<_$#oRlk)EDgiqW&DF7<Nhq}i^VXKf
zNNkSIle?BT6C?W$i|#b7yd5=NfiASZPbo2oNfZLDK5jK&$e$h47MRWPDf^)<)d{IR
z{&{ngx{kRit9Kx&%lC0eEO#`?J&}?HukFqok58Wf#?9frYmTb+Y_d}~`r)R>Eao66
z%^T;rMU*<1UT?ko{>vt^2<9D5jm+WY&+MVQJqqX;T#h|;4Ow09^!7IH9R3cQDowCC
zl-c}%>o>LA;a6ms*feDifb!F8oiY?dH@LN$O1Hfa3vPZ}N49&9riIsoqXe~(i^195
ztTZeIn)y$~y7Sc)9=br142`!}x|*+~Slg=%w2o8Xq<(~|p-{feKHiykn>yr>_PeTg
z>p9-+$MSM}VKW%h(4LximXWwOV38UtyY(0mz_g;*?pF(q`#hXqhBhlk%o7#aA|>Df
z8L0*b^eL4xL48)BZN2sJ;#K=Z!)D@G2Sba!EEO^Jcd#Ja`t3iVt_R*?vdf}zeY*|I
zaUmy9M?*o$crV2K41;omtK05<uO6cRAQ!*mR@9RlKn9A?w4z@E8)M8lFA#GHVZNsq
zh0^%mi*-{WSWQO*&=XUs6BH5NE10sU5eKJyqkYwbQjl4BpE7~<5%F5UMT#n?eICZf
zL&E$o`B(o;(nh7d1k(w$<nE87Wv9S6OQTSFFPuyv)g(VhffH;RKoZh&xoFf)6^be+
zE<Qv>Yb@-W=8lO8US06-F`A8zsLbZA%yvBzi&c`9Zn{r4_Ju1h_M6m8Ao?3kfwvZ!
z0(e6kvx2=2Z~ge#K$;HjCHrGix{3b1G_0>v!h(B}j)wYs?DG1C#D5)W&hLy@pwhs6
zju_kRLmyuiHm2a=p7UJL|CaUc^0!|B7^8U;jL1>qrGJzb!TMQiw}>K`6}{lw%gcDS
zSJ31?Utz_K5l=9|A`>gz#*wH@cwDuGhf{B__^4XD-guPJu6B0z1ZzlmjV<xjeeJ%{
zw(O>=^nI%*uvVHeej=LkMqwg54ZUYYV6Brqr(*jw$)cUF{hl9Vx~;LfKud6XmXq6U
zBoeB0B-Qt$K-x@QuM8&Hf}zMFA_83<i))Q^f&v2+!UR7hB8i)E0OYi=fafF9<^tR3
zgP>3T?lcL3@tKz&uMVaPJkC~7hD#=*lCu={cvvrU(Q#@btb%8AAKuR;IGBozG%5v*
zeYs!@Maq!2-|!`Rt{LC<WWn3q8A{@ISThZ$QTr(bi5<!GRu}gr%`O$G#N_0C-UCt~
zIrgIngBy2gvEU3BoCFo3F5E}YK2q+TQ4Np2t?auTBH1^~mPxd8R9Q^ca0mCm#GDNH
zHjtNqLq8&e7Jl5}us`4Q4R|UB1CSMG3^vS75(Ffb;DrMK&)@kd`ZjI)E@~s=inNx0
z0wm}-ws&}$7n3sBDcYNz{-V)FoJ|zDFl}yFJxm?e4DuujHas#c=L-_x1>_?KU}D41
zIO@KApv;8UDi%cCVC;ulI`HxE8=$Z_!;LeD3Ki_@pJY$*>4(Gmx{nC%ku|*AG>X0O
zTX7Q(zejMasH!rmGAi&Jz84-AS3-R4pY|n9N{Na1Rg-wvN>=_a;`}ObwTO+pBF#m)
zFK8kn0i#TBrh)@)@gL}g5S1^Cjn7h@@V?qd1o~w`if?lz6_2b#c(W+yglF>9X=jk5
zVhy&a3Xvaqheed-MX+6kV*pA>q>69p+<57t5|wiSsN5onAMTUxXKCEH<Cjvb-O`>!
zVE@F>LPI=~e-xkutH=!sIka?*yoLCM)5|>YsI;XOQX+uq_Q07?t*m(cJOcPAniqtz
zm@c*VR&@=6LOtMvH<+11Z8Z+%aIF9j9wv(1_Q?nP0sp0%`80~~BuW%)*1e+3F;k91
zVp*HYy%Fs+mSDnjD8t`HSK@PMlf>&Rm_VUKNd~FKGv&jx9(i#nQLsu4z*V**%SS^l
zef<o8{qO6w|0XQ|=m!5|T^9&i29sQMBauy#LcLA8^~c?c%f!^nbp)4g88!6$Kd8??
zPx`w|{D12Yf0c^AZ;VGRDMG{Kh{`v87TQG)ioa8U$`kU+!tWt_{*cXK1;3}CVE>#o
z#k>3coF|W1LLGy9s@){)y13@U-=4Yxysih>t4;x$u^k>W9#|97t`eA7xE?D8yvFzN
z0wPdbOUyj{b}jVG|M<(qwNHMukqjPks=;$e6>@^7TP9Ev0*UXf#~-K6{;QY_WjGn*
zEfmtC)}lx#@oZB;xq=J}J-Gxc{%<H3gnn;m60~#Bhw9~iQI1$z$tuEHm(5YdilQ#%
zZ3vRrpv&nT*1d*SJt2PF&4n8=j|7KKrMy~WGku<>ZN@~Uox&vbEj7*CeI#I#Xg`R8
zya11UqC#oWlKRHi^Jhw0L6}4pP5=P@;AJnsuWz);@@fw#{61uj*MMJarSd<U#9(IT
z;5fe{0{!BLu<0pSWzN1RjXAO>!2_&?5NFKxlWfFr8?Qb8WH%Y<+|6tl;Wkbrr)D^p
zCS(5~qNQiZeB=M!&g(%z;I1F+FC*}0(?kD$dS2h>IA)^bI*Zlk(8gd8?P*10EXl#g
zZ<CMJr}{iP$LFv<4IO;dNC@HOmf3SKx+<FBBwqL4W>0b;dET+e(NN&(GQHPdmqlCm
zGP;Oi<<b^x{uyQ>e~AUY6qV`0B+7>9uWvT5{TWT^y4k{#GGHh^gPPAK6#*KpYtF*6
zEDXKd9CG2W;Q_}(6{q!#Tj1mMs*eASuKt0->V&`_1rJu=+qGzyJTl*UnxxGlg+7N}
znxV(Wxy>=cwd+o=^WB`s)fsM~%IuEou{S;bci@z+PZPgxR>?YV9_5Mk*EKWl&pH#s
z<XX`UAYKc%d!4d5e&=6#Ukoq~n`IVgy2*6S=3vwt53(m-&|X{laD9)p-gygSkFbkm
zQCGJF59s-HeqRypf3xlXCu4&T!t<vbSEk9+WwX-|SLo?{sC}H5^C|}N>sH9m6S<KL
zqJ)k0Z01J~&^Pcr*T<#CZ~=QB?3Ui1`vw@SdF_9FTf`s_-8%ubt|_8o8VAg${D4eb
z(vqlaqrAzg=v)6Q*20BmA-7|=o{TP`jpypdL|Ysm4VYi$g%_jh2YU5~kELNLLN^;}
z##|lcCk>7k^b>&FMAU$sC%^gz4rOS!pe~f<xR%W6My+<WW6+@jc>+uOb#na<Q`3bm
z_-N=u8r2h-F-du^Hj&7H_o>MIs$%|E`#JZ!jT^WAzkk8>&T)fva}QM0!iq3SafKd*
zp9{OPp|<bU@QY|4hEV==-{%c&o||*sgz2AQLO<P0ncH&=*6l#`#0vIGcQ{PWh9x1$
z2;?@_`=aka=<#@+b4~FX-i{SO?0I%~VK*okE3y92_9Q`K?RkBGwmX;gg6CAAFOM+r
z9R_rwd#3IOu}P5Y^XHqL;`8Tn$sRH?AIQTkN0RO3(YZhOds`nOvJO8`Sy-3fCAa^>
zDWQpfh2CTNI@4U&<z=3N@9r{~bv~?OTbA43tNgOw1CsW9rUUL4dNPfSx<tZ8rg%Ux
zV034*$S9quhnS;~`Rl(Ouhm}h)4Vcux9m=u(|#TB8rw&cyeBJ-@h3$3;4x>tq>oQa
z2H;ch3M(K-K>Y15XJ&h$itk~gzw=mAyPgM-7XJL|&f#Ktz8s75rLEY_5_*1q0yiAH
z>dL)@4w)uL_hjtxIB!_~ONq@<)*JfE(4RSMKGzCsrR98&_RgjZTsW&t6q!GvL3Gfs
zyJ#txF*|O)r$giUk?_G{q8xJ9nF2ZLv<NV;-_QsB6R*5RLoaW_A5!nyzsCtx^s@hT
zszoTcjboAXH#Xz@M039E+PUyL+jcuw<Uup?6UoPe_8o~^kz|HwKjYMVGY(7$94-RS
z{F!+~!7|%?TEBrTT7aOT&#@ocZtU47>x^9kvfK%|F6ZgYyO^CgM(VmNuGY*cW`sV7
z$8B?736mu%e}|NRxBgcLoG9|<=Ojf2XhMV2WAV?%p#Kgu|791^1q24dqV!P?6+Q;K
QB?=%TAunDfY8dqY0Cmw+jsO4v

literal 0
HcmV?d00001

diff --git a/doc/assistant/logs.png b/doc/assistant/logs.png
new file mode 100644
index 0000000000000000000000000000000000000000..8e9e5b1ec80be50269f9c79c06e374009cfa521f
GIT binary patch
literal 33631
zcmb5V1ymf(x-LApOK^wa79hB5fZ)O1-QC@T2MBHfg1gJ$8r<F8-Te;v_PJ;8bMJrG
z`fI_=RCjfCS9NtgQg4TSlNCpT$Abp|07w#FzbF6z;5h&Q7!NEsXiM0pQ#I%d&hD$a
zBLIMW^!^WKKjNPN+6dz$AtMU20)~S22~6(Ze;l+4*GW{(NyOIL+StYkAmU)G?__L5
z;%e?>Mj|dD^G($s85;l~0Z4oiQgT~7&hS=JRBe81Z^@{oFsEa}tkNszBw?YohG2m*
z31K>cJY${5^Psa6kC^da%=&dFJlERuq}c~dWO6lcR(dQMoJn28GNLt;N;jVz#j%00
zsxZ>%q!G@G8W+QHmq*ta^Z&6%4EJ$6>U>jbX|G1Byqn)s;AvsZr#kEE*wF#){0~`-
z9|>##$@eo-e<Sb!(9ipFG^;v|0eDCuR7jx(-uF+`pCjo1k1WP69O%GJ9u(`v_hLP+
z9K&O^*-)^l#YP&D6SLq#sIEj<4ROB)=vL{I+He_@Rj7<@Ty*_?)F{^}D>jgM*2?wl
zH7Ot2jjs&J!054<8__VB52>F`j5bz2CYhGPa4^TfHA&LJ3!!qL@Mpc90?$@G&sysR
zDs<alYqDO3UE^)Vut@C`zBTde(*f4ha!z1sG#^bcY-}R!?li&AAm~5Nw*3Oy*i_!t
zbMk0X>N&BRS&;<YA%Tn7#Ni<auI1}}?z2Z>l773RNXvTLs?CxjdR!l~R^_*L!q|P0
zx(!Rxg{HTebE+?q-4oukBwf0gXPkZB3cayiem)WkAZaV8t*>wXxeU50hG06CQoEw~
zJH`e7+}2SFXP9V+`;j;I+Ec-dsmVR-rYjZBEgS(f)EA?}t<MPVbG9V+id%fxZ}<Ex
zx4}tyGxqDR?J>Ozo3(Q5&h{?#h?a1NE$nBuNWSn7yER2BJ`ujR_MZqi8iD+;k>EPR
zn+-GlknOKBk5BCtX|ge^)8|x_tE*N%hyw!JE~-yJnw<VMn<=hqEm$=%ad9zh=yhmx
zhh85U4ij8`k$&)Qh<<2cw{BQO@bi)VKvx+26Ku0wlvP5jZLvK@Z<6P++=))GIbraT
zTA~k-_L_FODA?cy$n9)R$bj^RGZW37VDvJ2vbCUSs8wQ47q;zF{UrlF_O9sYkp}2c
zXtnasLV>UbCPn(=5HY+!+7{ibz6ZwkwxrO0A3U<*XQ3@({=3FnaJ_{;>wfJq8o6#Q
zI(vpOi`7;}Uw_#f(WAk_!#&e7k<a&U9$Vp3;z;BKcNM6bN4t2iKv}voLGr!!z{ZHx
z;4Ui@%Z>DhK9GQ`5jpnKq()aQqqq$#cWln%pQCO7?hvYjFHnNLoI5S*y1MKWnJmY>
z!E(E$&)2M*o0dj2v#Ew4s}c)QuOXqKqSfiiz&^Kh=*TsM+vu|sqkRB!-iIH)j9q3)
zAx1|MzIe{{=**({KK#B1Lnn2*iE4bL0Sv7~h+483id6V=d7Xt)y<xB}L#=1MQ2^Vj
zCue(Ho@1Km?mN|hTy-z;x9u5Ra+XM-p&VGz_Gqy)m@s91!?oA4yU0?OWs|DbZ)Mk#
z{F|-B;0*t;*`?z3p66qt4q!OODCUKC^L4%ANqmp(CEL67E>Io$;}$lG_d@BE&np|i
z&djr&hqZ9Yoh!qM0CHiM&G%*cd_U%l+y1^RY^%6|*9`xCYcopoq@oB!AXJp^0gJcC
z;N2##KCaC%!pa%~5&WzhM=wiS&6@Aql&(ooidez-4@6NWER7NTM5!?-Ts!@)-h8y2
z&V}66=OJWdzMBtJZ+msBTnMu^vV3iCpXOi%E~9!M0rX@ahuI*ZVxk}yY=t7#i6kV=
zp0+Fj;D$t=#}~w6=hCX6HngpA&6Zu6af}6L(sx6uXL>N~@X1V{s}jRu6}%i)!MvR>
z+S@SXKG$-@_7O>9c^AKpLk<-@qQuAfa{HV>01mFAuvgvaa$csl;<6T{RPx^npI)wt
z4Xakp3IsBD8=;-rh#>8<U%dgoe9ws&zBGO4koGlhI|-^PWg0WP=yxh>Y6b*vTC)tM
zJ{N9}mpax@__nY6bSGpnZ(S;lE<2l_Z;tkK%QEMlcUfXqSe`yUcXvI#J}!L08w3-<
za?{k%@7x6bV7+a)DsG@8^qigz=ylyl61YFUGPI4#;IHELzW5n&6=V$V>(qXadn=iS
zqSymT##j9mU~!1EF=0j&7#zC0)orEN+S~qHxA9nB{5<^OVC=O0cZ2A7JCV<jH|MYj
ze(#YArS&j^TFY*l-~IQjvieX7e<oVDLeK9I=aKiBp8SRU72K3&{E1gR4z?~=TKfac
z=}@Wy_wn~tzdxL=_7i)$2^QG*+?SS?&d#b}zdetE{>)9UrWR`(AXneUH_yrNj^=Vd
zN9~m!DV{w^b$AOI&RLt@WI5f`%+h_*-KD%(tI+@>?^(W^B}NoUzmbgC$YSTe=ycN^
z&Cn>DWfTYd6_HnQ3z{6z6(1Vbd^B?>?#p-E$jevKH#vQd5*n5*7m*Vgk$t`2{;Wsg
zbT3pb@9j2dlmYI$lScdB^7niNn(WHynqLU%On~OT*mlPA%&*C<j5~z=BUw0)>T{s!
z0Q`Qvd-Nl6Mn>S9>CSXS%?Pt$CjvN(02~Y3oBB(WOeDt!aos&8SqtunHnHu;KK5aJ
z;<`NknvF6QZM`2e%zbil8qb|aXA8rVy&gEDj`qaf*QcfkP{VRlK2Dz;x$Y(oJW4P-
zCPRtarrlR(&wW?j`a6Q7)N{GVV6fjTy8bY@T&e6&FuzT4CBJR8GmNR@`|MO8Y0nYX
z`|M@70*;rPSV%}ZR2(*Y!rq>I-_B~gpKC1`H4?p4&u<FY7cySU*N-BSUbYpEp6Ugj
z+KIrxLmOlDsA32<#r!(5E5uJPYdHj^P=rt$=o925B{drDHk|MeQCfFQ0g11-RP}~F
zl`jiV0(0&0FA@72zB;c9`?;p8FPeI5x+Z+l_?@l@V(m@*?jMn^t7>n3t?dPF3qSdN
z98HXn?Pe}&m%d+*fMINKwcCnW@I*f~jXYm7TNRG9PF|rLVl1y+Yv3GlDzcxD^Cddp
zp<1ETCG%{3t*P*r3*i*HqY{99+>V0+^wIlE3}I)KKjfB;?gYnO_ivG%Hjj1}I%>wa
zI5J+F;Ub*xu>`7*L1sO_{EC3w`zla_BhYH)Gi>l;uArrO;){apP#;(6nev;;_vt~m
z&R+-&Q0fn^R_^}+kh^7Is}^|Ly^k8O2gX6*tu7`G9te(#%6<?&&m7R<XM2E+4j0ha
z&E<Z%-RAw2UkVyt9z(`u<xBA#uO8dm^ZOhs5i<dHn%Ql(tHI6XFv(-YFZyOSE*n*E
z97~>8fqYrw3=i&O{m!uPeaX&N!`va?*VirE5>@1A+Qh9}m2c}gm*`mvUz~PWK3Cu;
zLFv9ZJqL70oD1^P&wXGOjXXDDm3wqU{u~{c7^9(L{B}D7k(Ec)@2vz}Gj}2)G9xAu
zXhhZ`M%lb$)WG6ib~GQ)eBI-3>iW$!Z_XOC-bUpEoUp(Z(yLSjx>H~4rF@p^$Z@)`
z>nFx8F!j1HG1VI<_w{@_X(&@UlJmKYf4h%)OHLV+-dcU;o1oj(WN5f{$a1WFu{_x8
zY8tu|TWSwLyNb_RsiY6{+7Gi#;yEEQH`Be3r?OE?q<<bj4-9bu{+h6C>1}WOP<c%}
z*@HeQ&KR@&R)e2NQHuk5Qd!h0^*Rk>_*|~GQScUrQH*^bN8*O0UTL^_rc~}@#>&2=
zmquthR0~-1myfk2)yJd~J-HhRdYwl3<#D*7tfbv8kJb2YTAF7>*Jq|!*b`N+KYN~)
zc`&<AGmkZ#CucoBhZsxz-XE|`0($j)r-|JC9kYkJ^~LjSE<2DgW~a32Xs{sTWw|Hu
zyXbyFC-Dcq<r%Jz4{e=ta<>uuCP|KA0x%)sr|xFAvJSplVp@Ol4qbVCom9_W>~T-a
zR^9h9aQp8MjIUz&(Iy@wBBWl%mNeps!uVbiFmrYLZaH3R&y!GowO<&;muXC8y^(q!
zP8`t@HMurkwZ;=K!6V5Wn!bHLSu|@o=oX7ytgwGo@O*AMc4FV}uX}spDienk8s<8h
zElaDG_4EWT#knmEkseSt5VKmOWoo_L++fBm^Kj3X*H!rY%TQ%L?c@fwOSaiM6^eLz
z-7<oR+|b4!fj0FYuje=Ys*o|&*{Z3pzfY<qZW?Q4XMH#4bL)xdJayBlXd85JwXZLT
zRZG3LZ5IVRv7_fpWCT7*`vO|q41=(9-N*Y49g}EymY&-Md}-S*dO}BoEh7|t-W=|x
zcXwB=az%Bso)!CpR$iZzZn)4~l+I_e@Y|o=IvpQ|Voq(Z42)2MiRjULJV^~##WhYU
zXC5!!Sotr8`itB3^z`?}uOQIS(4I>l^-!Td-7iw~!gK|k=RsBRI#sD*Kw|AXH@7mO
zz#?@0f)d%H5b6jNssto`a$|x`>Z22f{)lrwDLnK+2-R^cl-OtA?Ja|2aBy(d=gE2x
zZE0{fI(NCLtF;3qfQi=~DH2iGj44E%3Uf5hy`vRWjVisKH$&OzVN+zUwx(?YAHyia
zWPl%(5W4enu<c57ox@lr%*#9V*p(r^+m&VeRH@drNj&!S(DEX_T7Un!i~$l%xFI!~
z$(50b5jKfF^JI4<nIW;tSzqtO^#ehF1J&?f9Wp%M?0l5T=V@ac!_oKZpVEGxHAn9B
zc44MCcXL*@bAWyLE_^gQb~FiWW?Rqyc<WWX?L@I)S9oV_X?0BINew)`7f1`wdfImU
zlXIbovv#G~`HvRj$cW&uagGU*ujUpMfD!+{h@^j1Q9$Fucs}2|i2BAZ_g)Ip`0B5e
z8b*xhWoBo`LPHb&M`U@;89Wy&m-yTP*P<dL|5bXe2<L4(UaswWQp(@oAMkpz_G&Hb
z@c65;l8Kq&z1C%}&pr#)#t2yS<7TWvLPCGfdg}DN%z*?8OQI<s+3;C4mfsE87Vv)Z
zsqiC6{VFvh<`k*OhS>Oc7It<O4Gla30^Y5m9zO(Zh93zaDYwhsp;<ONF)=}>T8@Z_
z_-&f1MV~#5*lpdPD$}j2Urg50@(705>pYP7xkFP61qH=--5(|(Ai&DE`8)jn$q9uB
zsQZVNBO64oE81Tl(`?(^&pTnxn)Zl7^#3sT$OLRPzHc95Y{!6wWS2vLg|&;m2BRN}
zO96HFE^Xh^<-JrA0|hzx@aqFjz&T7r@8s%go7qIp`ue(`{jq*#ecXFNroNb{DDQ`z
zBz=ATyA@aBl;B2VEuf3FogL_G#GngzioU+~AOPLLrpOCJLqoCL3y^Z8tU+yv1D>@l
znXxYNj&J<<+hMz$^Gmbp&BSuc1~?)1(HGH|ddwh--jn|OG8#vKon6f2qYWSXT8;G_
z4=G=;`+JpexAmg4232Yxxe9B4RP~_ahyF{(6SRj*dY=%OZ-l<du46gb`d&5-^Vk}W
zPd%{l(*o~G8Wn6n^3#6wfa|_#{7A{nVMqvc?t~e0%I4NqO?CBe1sdFx^EctC1-LR5
zy1!$^5q&FTZUOf@bJ~czyE}ZaaK)T%o7aLB`_YX@uyAZrk|}$dH#=MBZ-~d%thonG
zPO16&rk?_;c&m}Ik84FWGB(P|uD25K@8ixfOKRkoJ7}DknihDvo0^&m3Hir_SR*M1
z<K{g!)7oOfvq-+sr&A0X^b!na(IMIPeJwa;E$LgKZ0Locd4H^iy?q3<r!DFnBW=y!
zlYR8HMctz260Nd!yH$f^9yDcpOZo|*1m;&(^>|)Dk-Gx&AUg!T8lT$BHUpww8dxBi
z^^A*FfCS7e6T_Mz9of7|2d8=)oK;N(X*^r{a#9U-eRsoarugAvQJM<nQsK(B=X8*D
zpt-`x@}ZV%nwyQy-0ul?#`xYt?LDW*Q*r%FkoRyqH9o!$43I6jQd?cipGZqm9qcu2
z+<CEH3?rG5S8Xe<G*Zr!FSyp`l+bW&x;)tIDlNWL7JcFN#MAhxZdJG>UtL^Hu4q#j
zzXb6^zF=^aaj;auc&`Q;$?tMA1dIi~#sbgc_~UFV=3`pP)nzzyN%7U?xNSQc^#J{>
z>R<$O>#11doiVy{QkLpZ^*pcU`QH`S+3i$e@jT9R@YI9!?CjK1D#{5J8nzZCx7lG;
z*<Y$8b&{1qB`ez(Z01vy^G?|>#=W%SW#Y&#3wHD}Dtr(x3ot1YIi%)tm_Rd!{S*3Q
zbTslE@9M+6d}nZK>fCQAD0#oqU%$kZx2RQB3b`GJDEgIY1OK>Yv*bx$2`;2nL(g=W
zC|51F`P%hGN(O#$(CVe*QOL2X#cb1(FT$kzjYON#sHH9sMPivnAZXLwxznUx&wZ;B
z9;TAO^V1?$c=4A)1V(WZEtp@Z7)vqK!X$J8$5!JVl%R5UDSCnwzEa<axMV_-_x_px
zK!(RSJZJZYu}JZDV=;@XYw#r-acb$>1ogc4m)T#;HsuV;sp$=<T2`Cc4~>*^Map6m
zH6AxXADq|{AZQ-IS4#=UBtcWuFvil{o|u@J&2l4X&It_(d3=17&ERI!=29q9B1a4R
zLVBlIe|dfFgfdd@`%yyT;c(FW=w?b+n=2zT&Y;z&(}hx${BiRUsbuD{Hvu2HiU=XY
zyh*=KqrGy~tl8(KHaFlaXn*sJMcrzp24V1lY|dnc1$W6w(~RnwMn%@^W{GPajqGK`
z@;Rp+u{Rfd|IBS(yZA=5Y^%BR#^8IkGdK7k+W2W<xmnZVW%K(@A2zZK@9pV`8M{ns
zTeCcgOoN8C%9C(n=IZ54l)3vvkzxU;5g{QV!zNcz_#B|d(PJTaXGgyeTXalJ=Z8yU
zfP{oZJ@2Z$6&XMOYPYOUpoO1i<(9c8n(Z#u{-H(B13Z9$1mhe4OGbGq6cap3KbfSe
zV#XsQY~#@MO>c;oiis!e@|Fz{Q-<Nr#(S=|&dgDjyDmfg-T<)gZi@S7>a7=`7GM&0
zLZDKt+w-&0@TjRPEfDAwVqGaeT+)A+%x6Olr7V)?&0|{nRfJ(O=**UYY8;W{R^$5V
z@66GVRa#2ls&fVm(8MkAkO4l(L@`O~J@NFKDPWq0Ukw3>Iw~p2<WPHWdCqP<>C=BT
z*7|hbx{~KmgGD|jlz0^nn?516z<yk^1>F0fu=2Jy69iEEIeXArOY+`gj^4VSlWv0f
z%>+`V=D#Xh_NF58`u||#ay=A^KZdeK%PWkRQ8teX7A+}GlQOZY4H$X2yuqCzwKrBa
z?EKK1-iY;gVr_i+nm5_l$l0F->d?_5FD<R~Cn<->5eo?2pTvx)2zpOR#EeYmqJ1W8
ze&?K3ZL-MmyOAE7A+7yg63kmh@cP<Vc;6JE=>4h|)4C!Qs>i1P=uf7*%d}Bbcs|n#
z_uwfpnYYx1OC>Qo=NXu7I^|jCF+P|R#CZ4S?Hv|xGnq%GqPgqLINjWd(|KpWQ%33J
zsZ~lJi^N~vU{XeD^_bU-7jakpQErZx;l&>b8+P;mEL%*^z|NRt+=sB+Qx^al@cR&A
zsF0so($B_YqTiDPfhlu}2}yBr@!*!~-qz-3aWOA%aJd3L`9c#za9oR5f(DgbZ;i3>
z<)oy3l#9DMTr${_I%tsm{E4xRsS<<${lz#<(T<<7qFf^hhEt%zRDgk&P5}ch$k{^V
zr&1Nqn96;H_-z@Z0<%_uWc)$Z%x*QQyZO&bS!-1KKPnha>CWA%x@kj~J9z=A^f$)-
z--@ZvHGLah4@K$ru`rbQ%8tKi4YZLGr~cB@&8(JGlNTUSBVX|u7j3JN;pNCG)e-VJ
zmC8G;4t!v-`xrmqbaSX2q8||WHw6TMLqI@4!@wK_f}Z}*q57{|F#<X@CL_a;i#je#
z6B8d%VL`yyYf#mYv{GNC)*;ff-Q}~+9I?ae35AS$F>WPXte2DEna$#Xg;<#$>hmjJ
zloo{>y=RLpBL>MYHuy&<b-^wn{jlF3PdYL^y${GeSG?)YCWCFuqB2FG=bA{Af`X#1
zwsv3roNDNf{SXX!BXUoO%WAW#DT2~E^|Gtjf693fcR8`5tjzm<BlIr@E;s3CHi}dR
zKWHxINthl^V`7^30%P_H#6|@D`kCZn)<1xtHi#!jb6M9%WyKgaD6PcN6l1GZ=pCy9
zNVFEbAJ;#fRtYK&I6gX%yz>dzfJXK2Pz}xfN~<y-q;w0(-ihZK{l7S5*FP@&zjD9c
z;Q++_{yC0>`Y+jq{8!!o%3WB8tOkHsslB)!ds?1C(SlX|%fQ~1Gj|5@$z!Jucz?i#
ze*@rr%Xy!Y5Yhmkx749|syeb1{8o(im)|Z|kyB8F^%{tSNZiZs0XH)ft8onePr7;Z
z!^O1fd8I=`EOpAV3#$4mQ73}xrO7!aVh1N|5&!$}rr~1_xgAkV!p%VUrKC^<J%eoi
zsfrRV-KKP?5*WrAov@iej#ooVD;BpL5UgwZl%6yy8BF?r2%xIfX7ghMY^?V#6(525
zL3t7Z+=c)R4dpc>>z`nj*jF<?l!EbY^yCK=;evlqYpqcO_<@yvXrUI|Coe-vha3JP
zb5`8U)?j(5>L>7d6%N5oA@gtl*$-7e;A+8}G1?a(1c7Tlqmj_jb^W9`<*4Fej-X>Z
z6GVlYRg04^<b6SQlV`$>V2)_8Otnx+2-nmYjKGH;rXDVi-Ic1j4Bodbr%O0O6wY3E
z@E4{<#azg>Ux^;1C7T}-6&(s%7#!F@r%35_U!W=GR?K6-d>NVPy<`#7m;CwBHVf?o
zDL^!(*VveOXDDN1pMJ4by^<FNU^zX5L30fuEZ_K1RlN`01e}Ter&8;(dkRtvI!@-N
zq42Mtz}DrJQAYaNxSW<*&sK+a`eXb!d@?%mw&mysqd8#P3gk1{PeA0ot&Tp<ig;W(
zmGxo&TfhtiB^c_*b!Yggn-Ok+M@D_D;i8iU;L*gofQe7IV+sOLeLDcQ%}$_|nf5<n
zolsi|k34RRHgof9SoK7mClTIAA(jyc^#Qc5)H9^PwL*DVG)jyMXN2h+=hYvT9kgar
zfI#7g)UxxPaLF>YkJjG~dUgiGX*D+<38Mm5#Ep<>w{{N|@&?R#I+g!6#$B?EIXrWw
zL>ZY7gf}1_u(pIF_m|LVN*lW;!b7RwG^zJOTq^H)xD!1(1IQQD@yhW0#LBdPW-k4j
z1s^x7i#w(lU)tdXpdyfLgZUL-D7d##D*}v7lsaP_#Ordv?ehUkz4A$%W84@Lip)@e
zZ?3xv?hI*g+U^XR1w3bk=T<h7`GB1T(v=4=O^NOlshtO!6mV(>QH>W0%?&}f@Gn4q
zN5MP{N6{JhJq9hMoB8Ez2_Yeu1WANst0J#FN!=feFZ?`ke^r4koxC3@OU{N~{$|Ey
zW1#aORQRO<6u`W>@gfqeRLHaMo08HmzA3obakoAa8Ej8<W9UBDw~r2k-ofCS^~ad{
zkYgW(VpSEBm2>};v=7TH6UM}>gMCLk=WJ*T`oP=I5^4-X7ZGW^5S)?V{$RhCz%O=E
z)g%%>O|8@Zj@z|)mw!Qf&6FzJ^PTUnY0R^qZ$hqzxuL>+9MP@4WUC?g9s}4^U>$^C
zt;VSO(H|i-M@@&Cghsp}qQbef)*0~~hEkx81F7q(Wa#5}aJ9-1I6@idOu;{?hydS~
z$gx{|w-3VgzBx>uLTO)U4viF*H4OD9iVt_u&IsMjPNh3{y&fJTEn*w1i>ubZZ+f1R
z{hd&}G-()>oRxMv)sW(m`<kVcgExkZ>J{TkkHbA$$>|XMzNFqLwCcnqoGfO3sDj3n
z#sk<NG&R$5N#o__f5}v3gD~El%#+qG!b#=SHrG6migx(l06W~4R7p+oBppRSIg&EB
z9iecnkx)^=WWG%*Tf-+g6DG?4e%Dg|6K&h}Wd929o`wWBQFr}d2FaB_l~DwY%Z;U9
ztCol)^Wvsc!!gV~-~nOedAoT(tp@H@kM+i;-){c2-H1wt94VPIb0qByNkOrx9}a<M
zE6J}bOr6Y&Z2TvBat%5oz!zt#xR90`WwllomVT8dN1ZJ~l2_<GZMh)u`VYhmEzV4n
zQ>h>kxXV*;Ug-34i1X|06siU-p!N(`YLuyzI9pi_8&pO9ix=Eo^b=R8*O+KHnA`?)
z1712Pu;^ik0y&A&73WN_ig;1_-+}OkTP?ZYwhtc+BEpVjRZ(VdD-4ytX<S=aK|w)E
zDk2kVtq9c*jHw#+lCrh7BCr<_YS&i-K3d$&;X3hKMo~wN&8}JYp|$ywuBPVGc{d6R
zB09m}gn@y9gY)&>yy!VGHL2(aLk0VC&MQEcG<fB8On{srVvDhUS()l6Q&lixn<VTC
zcl%|j>>KQp;Z;04)iU&^jPl(sI-3l)Vu5Uvh-T#zXAD8a-zn^STG&3;T~d~^D=zrP
z?&0z@bv6HAu-l}pe!A||TsHL2kJ~eU^ZN%Ehd*y>zNUN9LfsFH|Fv{r1OER5=0EV6
zj6QAQtgoM~Mn5_@Nc-uNa>)z;12hYTB;#IV@q!?k2fSuM>)W^Sg#|djvAr~D$_&|p
zsRNg@RcrP%K5>tDo6ThX4s`G--&md{=+(=nQmaWJl6<(lzmP4h7jZ!vTlo7oIRgW-
zAV_@c^V|RVuUG((5MQvmo&C*}i{bTT+s&lcD;%gK--T`>Q=)5Jm9wq4LZHGhOwGqR
zMZ8S*7v;TR<V$AiaeU9$du&^kR8^n8UjVK<PN6-$(IZk**}Wz7-80CB@jLOf6us&}
z$SBR}c2O@-N0=lj&CMiy9t7xc@xup@CI4AmFgZ^Qw1$8zPoScBB=p1Oja|(f7fluK
zoi{mG=sX1TYd{3dUv2eACr#sb;B`iT2g#Ow$+STG$7~|U!@~po{P~j;n-(LS=4?>z
znLQG)832V_VZQ@f?MN$$*fEXl`bjOa%1=T11rUiuq0H#2W753^8DctAO{yUEpYZxJ
zvQweV>XM2@zljS!*z>^vO6{i+)}C=e;h{9b=2ki#Pl^6vVF`UXfnVisE7Ek&AG@Me
zIm4UPXa_@#_-eNf@)OK}1Z4<4Mr_Pa=q7Yvm15d5vBCl*7{T}s3C6to`DMxyvA?Sa
z_qF2f{E0e2RIBj?CrXSz%XX<Gi-<DgMb}qkY3T3#v^hv9S@#tLWJRLzGg1llT{k><
zP{5c!cp&9FlP8JpSL*EmXhMQX+A{&8R!)T(T>Z&b2+dv+zGDGc&z^|15UQ^g+EG}*
zH4ZLjY0z@e%43#(?r4EA*TLX145?O3_xUTyl_m;VjU=K=+>FH~e@4~AGpZ_C^un75
zN>VYXswi=3DC3bcu)z(!hgqC*N>j#H{M4q$f`zP)Tnp|h#RD)MEi^6<AxI9o6f6!N
zjcO?*R0;2IIxgfCjO{@Hpt}^w7jK4YYFK&=TGhbxxNIjA1?8QazMBG;QfPOXU8JuS
z$YnmjFW;i1k7u@PY15#=qcX}A`7R`}#)N}W)1o3kp_+>2S&QUNRe3jT4O1w)hkx_C
z*OGr7lyZ<OgZ(QHU8yfFE<9S>YHFtVvd@l>S<^;95{w9cmz@CeThTNIy{+_!taFea
z%dbBr8~**^NnD;G+AfvVh1Faw-#+b@T<)l&CNzH4{LNTVI_{Dhw7l)0--FT6$|Xp>
z-ZXtpJ(6nxuuA&C+h8b87wWZFfVph>ui?j8U0r?c(W+47<O4YtqEJ*zah-|o4F-T6
zV%|9#`!0%<>^98*FS!Y2S&3=PXckW`nqgHeX-QA7p}ca8w;LgKgl*+3P8yEZQK;Kw
z!A+*879UIX-QbBQKW<m(v%q@I3$#wqj}s1nmjlk*KgilZT%?4Dja@Kzgn)oxt((!X
za}gXI?9s~4z#vPT@My-c{js6NDpYF+Hr@U}A-`M+Q6{~-w(OchQ~%)+K3<GrlXWRq
zDMO8w=$B}z5L7(0-)Gr;)LG+fFgE25aGa8roQE&Qrd?Y-kKA0+sVs+h;@RTnM3`xD
zqBIMp79goP+Cr)OGfoCs<nIjJ5D5~9AT`yhla-Xzzjp;T-zI~NjjgJzypuQ4lkb}N
z!<7=)BBY){kpwZXr9#dag$6>Q0H}p<QqQ~qZ}&l3ebE;`y;vup_tLs<%(15KZ=*)p
z1j?G<zey@8Nwt_rXqVChuH4<7XPSBUbU;tx(S?<IN=vPRTCTQ^3b;v!%D#N6X>WS-
zxto@f%5Q2k*rVwX>LLTzRi(1;aNr<`_cx@7rQ4zov}{~e^%-P;bHArS`{jOO-xiaR
z)D$?Sk{Ki<B(dBHBj(=zep6%Phd*1+`4T8SRUPhFITt)LVjUf%1m9hoT~|5{{6sjn
zG|WO;vooO}==ZXT_l;r)9Z!0js#&b*IR$$}YT%+xA(!*qm4=%TZ2O@*{s{j`bA$71
zNL|yku(Txhx!3<s8Tya3dk2DD_Ti~_=N1$UH7fj%X8TW-_0O0GdHTs9Hy2dwKk?>2
zbN?>azMoN8)Zqz&kXJz=Zc8rU@4kzZJ}dUUogEqs_&wo&4BaPD4aV!hneJ&s6%-t*
za2al29+M^Bq$fsw_T^Naf3Bq=31qpCj*f!tj=iqN#zxRj(ET5?jzmiBD%dIc8LX~M
zQS#H--95ivaw(-NQbFKJ8H<iL@xLo+*qLmF+s((#Y-QtKPKmSiW?aK!d!9R_r12U$
zwll@^aw(j#(2T4oFLz-8ebkG3!~pLubHa;_6LQFAnviHO(q<Nyw=Pq6>J>czdYy+L
zsF)Qwv;tjgEn$-0q(56E)g7VU%@!H~P6s<gJvaTlNx=x9Al&NeUcI4Qy8)H=rpu*c
z`nVpb2f4&+p4&D16yz1-%|&-ynkHA)76CcdxrYQ0u=Xgh(J63cZDn%hnr2Wh1N`zj
z<BL)D&H`PxwA6Ij<Qx0-rL}ywZ`rQw2A5L-F3Ly}u}_4VnHgZc+R(PU-nL@u;I~52
z5X}k2sgwV=4hR73j|5EpK{PqY=4QeKWwFYni10+XnuPl42R*3>vMB!fNd=u{COt8b
zzGc--O<-hoo>s<EMHW<3sP`h}$8%;Ag@5t;hGFwZIWeWH_x~XvU5qf3FeJ2^UHS|e
z{|{sfE~{-;^Xa3O4rAUvQ6v?H{6$^USo-DhatJ!HRZFQBQP6nC&rz2F{wgS?UZt%r
z$7=OxZ{#*MZMJB^<uNj68@IP%bXF!5nFs$jrrC{76DFNT)#mLX(<gbG$1$zyH_%{d
z`($xnF{4Gp8+yt*k}c!K?e(<L@EznN^JksSSG{}qxH0|q_V!-<?YX(#tuv$pw_w_N
z67ey}6l#2WXq*{ktY69dm3ez((TsBy!%_CO{tffK{hRG9fAt@#uNW4rLNU4Ab{1^>
zs5XjVDt`)moWqhQ_}~NhD(;oroH4pK&sJ5ELZ17tV;S{83%#0RHJi2O!sTqG2n>+X
ztnvF>t5G|#eIKH60q09&xT?$V!W?<?KMn^&qWa==YZ~(GXU?t3qeVh?+JKHP5V7&q
zjv*+NAC^V+V5O_i9?M|uWluVt{kJ;KJA1$*<-Av*9GJ481n|D6Xw~5F5}n8QLp|m`
ztaYk)ehIY4zJc<4+|5_<jAvqki&r2mhXEw3kqrC1yfzPuFlJgTii4_R2_#1P62OBH
z?Kou1nLH*d6$<y##1H7;Ws-VE-AO!`5xE@BpE23yXG~}v&dB0Fkn+9%Y;h;+EjRm9
z@xYKXy8deAc|i_n&y;nu**!`ey3iPZc5puQZ7VC<{2?3L^ono7r>T>qF#@NClo}ou
z1`xR}_T)6D;4i4hoZ_W)?p9yTTOt{sQ!<Bu7&RoH`DydZn??Yvr?9RP2^KsFmUy1M
zPA|hAn4jD8p`hohgLB?jYQYxPyw{zJj1ZP2r5ze!uuVtN2Rg<9FbS7LF-?lW;i<y9
zh)GBM>BXIt2fQ+sIBlk)qv66@Ya;HOd8vP=3G)d5gIdH$*(K^8%q9W5Ud=@Hed_J7
zQ8HFFmzL2-zy|dB;y$7IY(@Y$qv<ruVAF`JjhFgFcxL!^zwHbd5#N9XT|R7ORn(Z?
z+011cLVq9(Lr}PA3Bq;(mVIl(z+q+K$y!K>#iCnLInYvXwVXSc(q8g;3uS6+PxZBd
zN5VZA{2CE!!^0#oJ*s{7wv&_aFj1fz1E7A8@pclvo(&JOFFUOBoRQ(nUT64@{-ddk
zKz{&mI7bWk-FipF`Lk3dXavE%$}88UqP~a<av92=p4oNY5?t%9YID(0yY;(F#P;vJ
z$&9?Gk?wNOf?Xk-C&!zz?x}Gwoa3^jqeI|miXqq+7HtIyr{O+_E0VP|YK}BHxoYo~
ztkGI<rYz5$`PJE5p)Wa>&a%gG>E6+1+uadf85xVaZA@89xl6vqMI3l~aox@2Y2?pF
z;stF~mf=O$T<Kx;1F=7BBriqeRDn^x1ibg>2b53!`dFu|y-tny(I|@Z{Dfh3RL@r;
zXQR8GIWKk)r<>UVXI!(OPVajB^TLOl<})BQ&&!LJ<MEKoHYRHu92p)yd319MvJv+G
zvNF=xKO%I3vAFt!!^cJ}OAI0lzjRf!NGoO+M&Y3V9ci<|Nb{#)uw-ts*emG4^;EBU
z2b%_YTBCTirikHN;uv!6l%_~grif32J+DqDRY{_cmxJ)u1rmQ`npZ<fD?(t15VUqF
z>DTGkS{Yq~O|4KDYwwnvo8<)Bi(Kw1IWIa&24Hkn#=d6K&7>~P0B}Ogp;8~kZs%OZ
z6WeLMb0=NB0ne36K5Ddns`Y1a95Hrjw-RfGyh$n=UKab;bin*PK^$UlxVYSAgmvf)
z3lyRmoqegFK^Fzt4~HCdp=f!bPTEYaa%g!#yAvw)u@>`o6mn0IlqSQHt>@d;z2*jj
zA1(3=RLaLTz1iAN+IIrDwcyR!u^FCAo(;$GE%IFC%ExU?@-@JN{g7_$#jg^5{t&Hs
zF!f1UHbl3T30*-K#<tROp*5i{Wh-lWvh<kk9)iz@VA=);A&Z&$sxA+xJ6%o`OQVkh
zWw$!FcNds2%sPB_+>c>0p}=N2;*80od`_N(5%1p7h}1nPxs#n9P=Cnq*y#z7xyzP=
ze9Pw)`ZZH;lmcLpPxnUoRIHp)iwEEmVhQC&rl=UW(sh5n+buGnARd{O!t*e@#&&aS
z4!=~;EhlijW7S6GLCawmY1aGNE%A2t4fE=r@*!)O@GK-m?_x?$&NX&;a1i{Ll1HPy
z6<w{eU9dHT8W_puN8Rt<4-tnvBZ|(w;CeF9jHbA=Mvxu1JZog{%okwQ4z>>Q|K%F(
z+3{T~XldBaYklG>ALP?HRbl~=ZQh0rJ)iEjm9y89wOuFW`=?=oVE3iK3Wm3IPLIYm
znE7h+GJ3S?uT~3{9<ZEFPMhfb;634aT%Z4}%W3;AwUsU1T0_}wcA@%N<LcvjQL`J7
zkl&mKe~E#AM5T_G2=%+AEX#H9jCX<kA(1yVqm@X84?TJ~&5+|@R9$N?C$&Y^X|BlS
zz7m3+$OJmvAr7oi)1zg9(|%<!N-7zVe>>i?&8HN%BN3@2FV;;T4xMu3;<*Sszoh#$
z(JY9ZhTX_0<Rc5>P8u`dSheBt-|y+{_I8gTUdX4T-vFHo+uQ!5{B(6<_PfrBxf$<{
zd?aRd^50tqF+_YDV@41BN17XRM|A+5d6I;Xk5teDT-7wnH)b5R{4HXXX?Z*khIRrn
zpYxDM?_Jn^DHoU2_db+G_v}7Xh5F6Km;;`LIZwt(6C^>4KGz=JpfCr}sy$f@BR&1}
z(G3W)Psi54sQ(XF%}bWArlW8PEPhuyVd|BF%m9ftnHBKgLLxPcm*?NjvTEz#|BDN^
zr^k0|5E)Ms<g9KcD1%uE=(7MBa{sPl1a>@??mdT=trnA>^H*J=R+<n13b{bNQ?MU+
zBPUR)W6oT<J_VG0_v*fzR|L%%-Pq01SXA4k+GvStJ`VjY2XrJ7n$-g2AYY5hXg&$8
zP9y4vnZ#n;fdzv^<T8(KQL|14y?3XIg060iI~_Ax>uMlIOhXi$App^{A-f@Uuh|1Y
zPBA|wsfb?tRKVfAN<MVg$^=QT-`t4=wu}}6G0x#|Me)Q}wsjj*&)5(5897jz%k_1*
z^sQ#=*8(N`=h@o=Yn{|3pw78rwO7_n*?H5ggmo`mRcL|2Ozw)wdbf{kvjBAevO8P;
zR$m*{V$26;!{JA>>nO?f+$&wH<O5+1Wo6}W-+s*<U0q(@d+`I7H0?Lv*XN3P*~3(S
zVyo=uOh+Lu{kiCh8Vbh%_HI#Sa6Fv!AEeRE(a~a`<K?m^`Pr@!zRi(6&0^EwmMi8B
zc-5Cm>uAuFPB1XifwAbd=V|}Dl*;s0ATMIWq?x?N0H8@oj!4lg#3>Q~<xz2Q0WDqO
zcAb8OR*vwadpk4AN0;nLm;+L|pk=;5J)!y>Guj7IVtBbC%wTt2&ic`GbL|(pe)}~h
zfR(S#NaR{Fm<poI>u=G^6!RIF^PUJE*^^~ut)=RmdaY*g0j{FwZEQZ9iF?#PFmdF}
zCq=D{$U0x<(UO634Yw40Rlx$@Be;U}@dwCBX~3~d!?>o-h-L(lI2lbZUIDDWdrKo*
zHtRu7r|(gSX{Xoj@hw3IC;XHG`KRU_V|z?7X>EqX($#NM+->)l8B|@LdD`|yvr=w+
zU9@;dJ`>glw&}N14&AA*!2@fNu0)(;T+;kep12Ntd<spEW=5aBKeGy~%s13M<HlmD
z%vwMtY7^q7T?h~EU6quS%vd;!h=_=bhYFH>m6Sw_=q0*x!(R~AdF&jPvZ5UF?<a|d
z>5sn!$`J=G*}G?+d)1@)eTOOP$sFJ7z53F>Q{Vd9vJ<d#_J<3kDZ~48gb1LNwcBDx
zurE<}8oN;SbQO(3D>#Yb=eKOi@a}DYnZEiESq`ftwA!eMZ*gOdAR-AH_)M`CL>eJ-
zj~vCC{jvN8O<fMtSp@4Fd!fT>;rUkVf%)`WDpumXnCQzw=Pde2S(&(qW}0j1LP}$m
zK{L29v;9y}s|>eus@0Kth6m)2fgYAAuPAa6SGT14Hl2F5CJ9e)SZ%VVytRGfj**1I
zDNmQgtV1~UDhU;ah@C)vO6}$q-hrtM6{^Mqj|nI5OBGoxmY0p;X{1KY-EJ0^#<y<!
zRduCIX<(7fF;46Zo&g~~evKM^;>1L({O~CYb%LaKkFzVOA8cmm-e3<nN<Xh4s}9Rd
zkwnYXg@ZU06`Zi({%mj!B<S@GZQyzpcBsuQD8x6%k9u`l#F5KIb)LA4dU!1T$M}Bi
zM&_6DBx3e9ma)3Pu-n9(2kmx_z_p~<l=(Co?^YU#5;b5++fG!}6jm}pH%gSOa!H+e
zb(uvSJ1aLESBL=1NK(*8Zi$@Pj5uqyl9|Q%X|~TCFAp)_^paUnn4g&dyQ`;7alp4}
zC;;Zt?=XEp2hu9@z^iPDxA1T)q5ztoyB#V(c=v(Dbt*%>-PDjj<cWaRKCtyx7&OS{
z7HBY#;d;L-YHGH(83M6^E9AtP`JJZwGp9Te9Ai<0Wbhf-eC*H>P`PVPk(axU1P}p@
zhK-_fi&W%N0H=&PfnAeRo5dUHi-ip1n$ije+LZ?-8V<M5X!CKyFykC(%q;$BDYbc~
zM(0}Ij&qe?C^M>d0Y=s7nfmEG^{sU%B`<Dh7Ky_#GJx?V=h@r6rbMnMzLJjs!OeT5
z7RTmAO|peI^STM=(br*ZTU7+V{h%+tyEf1)M<`P0y`!|wbsRkK1?le;f{s^!eWIyM
z#2<J5g!19M7LnhuLUv2;8Mt6`%$<|T;yIi6>U`%54iKYhMqR65%Bm59rss13g;Mm7
zm+&`R7P#OX&PRdT5T;&&FElmbkSyn#wF;-_GufO1_cJ`+f4miV3z4lLaT&=5Ln0B~
z(~`G@(qQl!9tm0C8UAqsFubSJ`O5^^I*nW#M$p@g5qf61S9KaM3ng4eJk(u^0>Dt*
z(Cy`MetnxOlU*Ma19Y=W?7sN)-adKXQn;0Vra~2BA1J>s^_^KwX`RE52{JZnFkj|~
zS7TN^u4hY7&R}wk@n;`c)Z4}$RXCOFU0TYZSNabv$7G9&Ie-tB8|sZypk^agWJ-q8
zEW3>+)+ySyT>}M>M6OVd09w{>=%U!0$ojWww{*{32?PUHoTa=i4F^pIgb?KsjM~i-
zw>k8aX+Me%m)z~8OlS-Soew=Snql;_H&>SG-ClQReu5j`f5)`7n$3vDH0@zZuG+2S
z>meVQp3!j=PTXp7r&?7gU-G?ws4jQc?@q8a@~{AQ#Td@TMNI}Jo_bT&-jt28ePp-3
zsgL?(>Aae6q`_@9UvJz%T7N&jFmKqr0XdLwZQg&#qG1`sue<nqDB&uv$Q{xi_mZI!
z4WUBvQ^0pCVl1g-!m}9xw<>M+&m`$f3h-d8RJT0yLwD`jlB+>Q`Q8I1@_yKIwMSOZ
zhC&-C$N@BsRt%|4PS(8zJ$^ZI)Ci&|ov(&ia@C*bg#bRBZ-7*37O}-!i$}04q1MHT
z)zkxy2hl_}pYKAYC^mTgQKoMHn~KKuksTrmp@4JKH=&E*Mlx6&0)ljzC(0V{+~F+6
zKtU83<m7(6Fk<1BnXFnPFl~Zif_ucA6dIe7N38jg>`)QbK%Bm{kX6<SU*o4&^pjAz
z=hdBjlc&aFxX94@QHs@QzS|*x%RL<A?<S}NDZV#779`uPcdzRcu&+meU)cK_9e^st
zdp}&Wy$(QFWJw{7sjo)dOZqG&3l8)EVzWO#%RQn2?w#t&W2)1esf$Lr4L+e2%jRKK
z8>Qu7(e-D7(23ov4-n})9rikynUglFUT*BC+k2rNl8TMrZ#F^|xzpZ=MQq9NDm8%W
zbUf@Xwm*y~_TLjzf2;GZVQ-Bkbq8ug^5WtmC;~cJKN%F93QE6z{p#rGSTMQb&#ZD4
zz}(#_p;-+Idbo(9?7L<2cq4MZ_{7ww=$93?yX$D-d=);EcY2gtQ+#TjA=N?%OhU96
zga$UFaV+Y>SOPP+7-x@o)L-Vn1j$hkSnc?K47*{m<r(KwER2~u|A_=MFxeJ;9Xqbo
zS}}I=kxdkMHyIejq;3seS{6ruC}VvY&(GiF%;B-C6r00QOt0Py_YJ>X;mm`gzyLu2
zI9K_ek8M0@w?S8%^Ff`NB0J)q_eGb^DGm8!C!aPEnz0@#c@4WY?7D9}QNXg}>e9^E
zPX)c?W(hwhG<1iy$LkQD>v}l2ZDKh}?+;*_Hkr$DDqbrspfcfnTCM)X!g7h_yf`A{
zvu}_kOE`36w|*Byk#B=)D}|7IcD?L>pIOSIPiq^2;#<<X_-+c{R*d{t#MArA<{nPs
zk8bn^-eFy*wb}wEfu!^u07;_IeA!77L^BtnJz#6Ygvnlf!?W7vNokdV`1RI<E!ce%
z8Re?hTp)>jEnh1TERm_<!q}!KU1rugYtU$SNuN4^<eB`3wBUOH&A-BF?h}R5Zb8`w
z;t9=Qz@m?K+cS!Tt@HI8>x1iz+Z7Wx;?TD4Ae;fJ7stHi`UnIMt7hHq7ubJZjRo^V
zK)P$cBzE+z+%-kehM#-3+6Y^I0PwH!!o+;?X>tB61OGROx5vuf=&+my=!&@K*+AJl
z%MJ~gy{PspgS+#+)W`N)BeZ`^==ufx;Ds$_+i{763c1>f&c%JkUpbfVaChX_J8_yV
z@dU~Kk$_%S;4^BExE<>J(fW#<yTIRt(JmI2`P#RY{yC%rva8(FGnU1zqvygWVkE)=
zb0G5inlG^Nw*4C5rhkROoXvS1Vv{WYyozex<a7McOT*|3e~W*9`nt7C@pgadUP&M0
z+F*0FnGWIGx_#gp;D!?PW}`fuo6W&*bfz$Ur}gA1;P;fXcczX>f!J16N3+>scvmov
z?|=H$Z0bE0S5{vm?KX*iyzYhXEt{BA@{;(m6KLI<L?4fK!Iy%N#q3fNT`Ms2l1IvN
zI9cg@P-mF}rw?F8?^1=1F{b<iP)k9rzh119>Q;&ICj3FKwqX5@&;r}nW}d8S4fz`%
z`&;%HVt;h)Sr{{)WW4yoGe&Y6z%NTo(V^y842$wRPcp96BE<blsOoL0?zt{3IKAMv
zSCliK*FSzz8R<BygJfXDRag8E<m=muo`Zhz)*@VRv8i%xgK~{y<9t7|?AmwZD;&^H
z1r|)MXD1X9-09@BUd(W^yxd+^WFqDu04k#>?$>1{dm;MwcHh!bW#Yf;uVPb_U;=)g
zwTde;BLHu@mUlk=h!2L_lr^E0TZBkGngzb{|Ge)$cg%X>y9nK2LT1x(mFYi&K`yN`
zeU9xk0TkbM#v5#S=<E;Tm>k7c+?M*nwu~oy9#$+U_c(g=S<lr6+;2b5zib7&g6)Nr
z0h}PPQib5J6vrhMKZ^imo*$j3vb%5UxNZH@>7`L!`QKmftJ>>cEjtj<v3>TiT<qfW
zeM~E$&Gn4-@-a*nwF3kQgR$x~<eX`27=Gq>l&*MLsWx2)Wl&c4S(<c7IT4ybFIkss
z6Sp0$dg{H=@B<86#(@hPwx{iKf{u3?C|4`%j{v|`M`O#t0%AD=0Sw4|osDr-b?IK-
zQ%VVZpieeiI+K?zpM~(LE)jG@$AOl<Y?O@WVdL=M2$X<y{eT0$bssjSW5)+_Z@atC
z0$u;xU#&46*2#0P3UTzdfgQeAU&?xZ5FB<o$#>H>QJwUvZ)+-=S(U;`hCIV^L1f1&
zw`It>;cZ^(c`@;K49jg}EQ8$yjt#S)fDzmW08_b^f!w!6dQ(??>7Ky|D-f#ji7hMB
zNy(_U&((e!$}oQMClKxEjQmAU1RVooAwGA7=gFsz#H~2Zp(^~erPha@hZ7GWHc#lj
zsxZ=YzIazILxQ8ZcT<Qyq214Vwyj#KYtEwt2qdWoagsTP?1@W(JL?NIo(+~`p98-~
z_dpf7>2x6gSHSD19(_*}3_UfMU_OME&u~>qIou+preusA55Iev60H?@{}l_sv#zDs
z>Nt0hUvAz0CXzfgCg4ags6uz2?PlM92&w@H-6=kYXMP<Q1p^4#YOJ0KuYCBZS#Ql-
ztGHr_tehzgt;gRW-teZRXv^9`9_lQ?E^$A=$o<8In68{}b|zxJ_N%N0?TUKy8ZY9G
z=b3x#?g}1(qzYZvZm`t?B~SC6ma46s)%-bkFJ*bb%l=U-Un?J+e)rL!R7&!&`9hgb
z8MvUqN!ZEQOat<No38L<`k6qrij@+ZLpUf`p>)4t>m69B%o6u&GxWPOD0GS~_Wx<Q
za@LZ5KSN+ys)gwQFGh)a%f$5-oEnnlzN+KH<-AFdWH*?{VIXL=mwrlk+5Gil(KcUd
z(GD*-<HGhPUvt>fPxxg2F_kF6YNMSh2qCnBU)Q!h*!S0j-SJ!m1NpLV_5mGzdkp0T
z5O;TsXpy4gB$bgy8~72uW8)<iy$*=ETwaU)6QHxucGMFbJ3R?8S)1Jb#I~pi+?h|P
zs+&x!J$ZVH0~vVtZpKeUCmV{Pd&E%#^PE4a`F`_!T$x0Ab<^5_jyYsFS5)QccLN{>
zssOs@eaxuU?Mb3yK=$RtOy(l7r;|jVSctxc|Btp0`E5MS&oezt04CjOUR{r3Mvaz(
z4tD7Il6hz8a&PA~cpqU(ztj9&d}P;;D%GMF1`R1oIy#fg$NNKpth%$62kfj}MGr+l
zI!~uP*<;3&_%mW@HL{h~GC9|B7vCcHvm?!fl&R`8Yr0Iht)bO#_2sXafCYR>;`Z4l
z@3W@;PcY=M!$;z2E?M8Mj~CmkNZreKCvs&pTK5t4x+p!DazPg87v{S7I?!#w2SEzV
zult@-OWQda<V!BkMQfP4xw5R5)w^$Yx@XjQ{b$*}PAjQ31-Y?MetkkxqnXh$YAA7p
z!aDf1J`USMd7X_+;f`CvgZwBHg!j)3YR;Xmdq$JTE7`-h2+mKMIUnMF&;N+U4H;(o
zX*&q0)V0<fkki5eulz(tABfT$f*AChsO`tTh{k1VdOFV6?n>hfjE<w55r7d_wf=gk
z>`CG5>Tg2u**``)JAaJgclHSi#QfB%SgD|Ky#Sn#&CMwDwL+8;L9A$+?4?BD(L{Xu
zCC`slCIC=2QEW4qLOPkXKaULCysb=MgdW{AL_dNYOz;ZTVOEmR_fX@>#DoL-D}MW?
z1jtPEOqSDW*Z>^@O&p$X1UO90<jNAqPP-S`Y_7vk0$GfIs4PWM*NCs*oW>JNmymg1
zuV(8}3XLZ?nkr{$tX$Q;4axSn-NDzDnhuQa?9mq*QyK93`3_;~+=tFL1d?S+>Uue^
z)5>hRvZN)QdFsQebvXs%gEvwj!u+x|dUo1Z_+O>HWmH|s8ZEkkAOQj-1P`7-aCdiy
z;O?^V9o!`WLV~+Xkl^l4f(LiE;BFh&w@7!N?mq9lJMI{df14#$^;NA^bIxy8EmZw2
zZmpDvN@pnzqpP2UP)}(YxhkJG<V>Up-|I_=Kv5k%&Cs}l-HD&0IM(3Z-CZV#n7C2)
zlKnMBdg`=|Ex!wlprujK{!q3*E@)t1w<gURc^Vl;@=-loxCuI*!mkk|Ab3g=1wrrp
z!i4D~-xOn%<P0S~uB%}(jCN1ibqh(vEC#$X(QaGOLl1Z5Z`*Z$$pn_(-SEW!Bv~3@
zZ2gy{GqipjPN_F<XSrFjG8>0gy*`R1IViPG*^1;kaAMTu^2^2$V&0Kf5M;`{@XOxe
zLepE8nZs4l#Za=sA~+m;rL%^rfL0ZTf$|mNs`O?5D};A&`sMqS(9qK(^Mp#)rOC1%
zV9z@)md2~_+PmBO)NV<B7D_E(Z7XH8Pny?hB?B2u`&<6Z(s3{K_S<bfo<4;$|Dx&F
zH1VA$KN!mvNNdX3=xC2agRU$6iYb${wZlKvupeqvve+315PzhEPhyKgUHGLtd+k0m
zxkj=7l*BQ#V`!@By@NTe88t9qehE~T&84!3KN0c-8-5Uv>wllivg-lOr3d9rQ!L>6
zg)qK$Sco3FFgqGjHT%@;El91nM}XiwQF|Hm)9eO9mw<=}L(<X0(exU1MCwI#2|VMY
zkfCA`GSnYOut$i)DHVn&yvcK61;OQBvU3+kGC0^zOJ%zSyE`ZIIq-zHY<}W*dh~ZD
zF+y&xO~{tgHqyo>xYJc}Vh=nEVhEaWpIS?8z-<vcJti&Q)v4qwaI6M>mQQdUl%eR`
z#_Os#p3}Z5<CfUaE-Z0wOgV5?=c1>TdkGY1Wlr;iQGgvr5Hh8Cv!yj&S^nukcFMLA
zY`ZzKE{zQ0FmJWp;?GU~q_shD6Tb&ol0MJ9*x00t1=Zy(qCvNRjLn6!2h1vg4_25!
zNeR^r&shoS0<Rn|wo^eHl*Lfe;(HCuhH%4o#r(H`x6;~gHRd(f3uv6Jz<kgZAoJ$9
zdIcq?R4-cgvKPT+?xG(`K=|BuCju|vMk<~;zlqM?1?8ddcYaN3ybRJ};U%!T9CF+@
zqkN6;do@pkJ3hbY=19RUg}l614(JsQIOxsZrzsCwu|;arEhdk?`TmfZ#pI<jn?74H
z>*I{d@@~iWr%`fqqhS-^s!1ZRma4mnXxIP2_N9xs&@?{0yT1)(;MXq^KisA_>9Exz
zmq~VwOM~f%lGWW0pfur9<}YJ|tcKZfS(Fn@_Kv<n_bz>(pZGtx_-pd6#ddKEVVR2-
z%-QS7%_NNE8uz)bxaz^5TR|3@?Zquq0(aGOYicWW>kW5-=?uF`IP5xC;yK|-2X7o$
z!qePmPFKXQ&dmd~YE=pezsN^7)yb<jV2YUeR9T+Ak0WV;fAZu>NE|=l(iF`hvBi7U
zoyt42{(}G!5$sV~^<VrM74%*Z2ayGl-_N{jw|z#=j1e^o&k@ec><F)ex#Uo}_-~Tl
z9eSmIx1$bv+=1s|Y4N6mqGI1IZ7G?9Aw!+vT`MB>Q<*aZMOVdhgu>Uf6M_YlBgygt
z;Zf35S#)d++A9rjq9V(15(1*(&3>5}R!UYfO72&&x>5a%AD#cPlkA$qz*XE)?YkYd
z9pFYTME6<!h2$GoYWPEij=Sheq>w92!DSzg)T^7fu@yf2tqy~SDVUos_o69TxI+R}
zz9kC%H?p83l+ZTC+SW+cs9VbXv%XG=@8E~C))pe{xzD3pC<52&XX}&2XUQzFKNL0*
z9p)(O3*2APMpGOq=yu)+yspZ2P8g}jSJQuTe1CMX(CBiwcn8>CflX2FT$a3mg{DhV
zQKyf)X!zVs`P@P7pAn);%)ffLE`7KT2UhO;9OL+8jF=xRHhWwgEGP)voerk*s4s6o
zK2JVe-Y%8i-TLST-$Sy{w0G*RXrwBye2O_9w$u9`^1aHe?l>NXqGLA&9{O6Zn2B;I
z#4!9blON9KAP+}@0-o2~xjtv=K4O^eD`uDXH-|pZ<fU7nY64e375H!VDs4G@F0f5n
z&(O{9&jkb?mVEl|2Pz+2vk<92-QTp{J>1Xv_?+K>AD}0glC2K{dbi-^+=o6)1~#gX
zBnVe)Aw$4T<{+(i0}yX$u>S1|rNGq}aS;g-jH!UvQa-n<#6CB3OZPy5KuGpk+vI(<
zmp8mx?-^R*l3F!%=dN5fj(2O->yrtPZX3Zs8#W*ITVLI_KhS-+D?Sjo8|Z4i3xB{|
zNEgTGsJHUDIM8+JzWzy>K40&!3B<_fdMw?(e!lg#ueFIM%j21EP*|OY2f-_~`>XVa
z`X2@cxEsJ(3;XZxudr!nA6j34Zoi37>}RXDB-6k&`7cTNiW_bM{8L!3>fsl#lLyc0
zV_SgO@$_8^+#bOV#$DvseJ(t?sK9A;*pvr<xvw1J-z}P6YW7ekvRzF3y;S#NZlKRw
z_r7&?qxAuZaO;Ejdtn8Pco%58=gH69bZ?*w(w*m<ZbiVx_i=lVyJF2p@m~P-0!nC4
z<#FM^I~@a}^V8#7MZ`R>-MXB-^IC-jq*eXlC*{dQ>NbD<<AUHqz%e{u4+RF-LG3P3
zkO!zD1vs0Kyszb{7x=}}Og1IQ<C4!AwA!IDm-+hnU%iFbgrr;^E68)ndmB8JS7G6Y
zg0_!jo0?L?<zRmMw3CoSq0(*T+6=ld*s{9HL;CZvaym0l3RhQ6*Sy?k8l%H0OR^@M
zAfsc8kCtsY*XzOf(*>)`wT&;k4p1*(yb3G)zGV=f*Jgi8m>(svf{t?ZuEY6)u>Ip&
zf~oawo<Y6)M4+Y%KusThmoV?28}H?*KO}=OHMMw6^1Ip&W9}d8a?IFKe_wVe<|2zR
z^}}@G7I>5Z>mTvMWw*fHwt`9$aL<lzKfTh2N`afo3r|#+{6Z_B8tR1;-uKY-N?MN#
zdOFlcrG^*<c<^+ArI!nb-W+UfXZ#-5Jn@S6cZa}6Md|maV1XOFD_6jWx01C2#Ps+6
zX24*&zrSepNr$>oaXbVH+zRE6DVhQy!62sOPCY>Pxok(=-FP_76&T?K;`s40Ve|Cx
zs?fqE?{RH8(uzpH{O?6q5s&M&f#ZMt!dUyg)!E12?F5!!J@zJW*fu#C$KFyTC^ueu
zD{4oCEWp(sCFo#hpC6{<=?T>XIloy+DPEpi6+{z?Nt&i(w`6bp=7`^Ud~L%=MJ-N=
zTIApfS-cc*X^;xb$iC$I9YX^Rm`5q!EYlKNkE^38eYU1XE7BuEdx20S)DKsEe=ncm
zQ6St?xQjO4&6Qodk3yA})>wEPi7F%cE*?gVMRkr}qbJ(b`#Y1%u5;nVn{k{y+Ol~B
zHEh4t7X#t(viIiU3Ku~VEPewXu)RMgz~PxgaW87i8(q<PcF>b|1={6lMJ$E0;8^&|
z-}S&OpL43(A=h)f@fJJKsXEUf?c~Kp>39KRWB~!I#Vdv!xNvDoh<ORp-Ns2yzSqGj
z_BUm|E8qGwLm&46JAn(y&3v=8;}o74$NQv~!A8|w&KM5o!+>8Z)QIQHp+p!ponPX*
z?)}a66&uKWP5Hz77TXk#qxngSQwPwnWPCVtxv0hF{+#WZ$y(kxGcKD`d^dA-8567F
zgdLiqI#PWle!dFpaM`}T{v4%JJeOSei;*nv`iNcI#2~Y<3NJygvIxo^&st-1to5Q2
zT7(~3gTX7+go5N3o&svi+6d%*jdvGkP^-;@Y}GygB{!Q*G-uEgoWoFgM;odpx1*qu
zogrF_BD#QD{noT1Fs|!L&^}egtz-Y0Kyt|QgdIF|CbQ3P1YubOiXsBTC^b+>5@#Cv
zz!P)naw!oJPzvdTg@_LmsB2@O1o8Y}N)U<}z7bvs%&?xZi(O)vd)@xs&VuRUmFA#!
z_cRJ8RVRPqd{dh!6_mDK|Ccs5P&==SGhk_N=w6q1W=E}~S<S)u($runDyB2{a}RZ&
zTwEoz`IuR1`-jYg>)9;dZqpeBsR-BbAxrLEM8pXOg>%MljY9*LOcc=2Xh+6`)ll)8
z13jOwsUF;l8(0BBV!#dF=3;)(z%*-Jdi9jp)(3hnZJj>hS8Z3{p1p7;E9dH=P6eOk
zG+DV@C2tyL^<jCm4>AdQZG4l6*Lo8`p4dYcx6Hl*;@2N+-zfY(N2p4oHRa}<I+?GN
zUykp2y8fP{lwV%#r3lfK_Ixl7Le{p?&dC;Iqy<*&yh!b;I;(^KzSmArKoLKb*(<Cb
zQb$pV&(9p#Vy|^NBTSbd*|j;RRbk|EdBDyHyJ%1XZL+||kRBdX+2w^WqI;Oc5ZipC
zL=)t~n^us*|8j9zwEtX*JRVte5aA=~*4&`k9Kl)&%NJ4Ik7hS#w`IaaOnI@sI^{L^
zde<w-;Ao1fikK*09g<?0S2n@3I}Y6U$CKPFro=fd$0ifs@wwtjtMzMnLM!K?Ry*|c
zGm7D5%?izp{X7Dtv<Sk<;aMY5XjnsW3OxHMwCN&RNcC<3Oi>&e^{rPyEX>=hmLw-@
z-@Kmra@=+`+{BLM4Pg;{&>-UvHx%w1X*QDNdT)13<g#e>HdoI)L)D4<;#Ivc8?MJm
zr=|esS8w=i7WmvHHg@Pwb6TFtgV_o&O0@xPIn=(Qp9UE#Sf0s*HffF6+P>sUl1w=Q
zt#tSnK9DU{az+=Ers0Bp0~b`Lr5&tvW1D?yM|IlE9h~yR^ch3ox?AAk@)fF|{`tl%
zc_B(Y9@S09(R&s6{4nL`oe{-qV_j-F-$ktU64mpS5hJ8TH+6SAmydlt%0k%w?x*%w
zm4x+aOCY_`ef&l9YIN(c{2-fR1(|PFhh65ZCr&M@o5sKL7}g*{#;o{(e9S@NHKUk_
zpplZ?)%7+6U)R@m)|xJj`#<keUe3ALR5d1NNms_Oa9*TYv1aX<o7a;fO0p<9e@Tse
zgZbvQ_S#OxTOz5Kw7c}ReD&#8qL?&u=Y~6w9aoH59b^F@*3`J3CqDLdIR`6IglFb+
zjaHS@JpMbk7<`FNO<GcKpd;pv<OeBl)7ya#x)Mql{?YYHIY6U!I=i#-E{5Amv&S8r
zDjzuEY~;l*oHq^s_S4>z10_XyLf@s$gvquVgB@(NJbjoqEqKhyU1t1lIx}~(mZNRI
z61dB4bV#6nZHAvvKY1z_9NK8gYT@eCw5htgX@EmUq@l1u4*L^7y6niz&a7*K<v+Sf
zH=Y!ZPg;32Pv9sC-EC)?D7Odd6<yHg^`_7r=Z7mR>N1(2#2wjdWks4z2U(3}rEYX3
z&hW67m_=i?FD6;MA9I54rk0zbReODQ*C#C;x=k>>EfMo5d=N8W+ewnrO4-o7*|?fL
z6k{5ahpsa-NWJ;$YM+@nng|9<@G|>7_CxNi<16e--BuIf!MzyRzHfsOs<1k?gG_8W
zVd61SPmcEbeUOUvNiu|j(NJy=8YZ#>W=zlckxN2UE@osUe1~kcI@p|X;t%swXZam#
zmMi3}44pOO9!mHv_yemk?4i=D2P@9J=Q*RS(hH&1E;JZ4TTOTb$&Oct#@;pw@7&O`
zxwDOSKsnWd9x^-bk)UR0&kb!~slHREJ4{o(W-&j~Z<XWV+>$!UQ!Vj^OX+uX#LqT!
zrbOniIKO=8A>3o!(OceZ3Ca!cz1k|^vps|gE+jMWtg5IGn?MT*>s6Ekb7Plx&f}xq
zdPP}x*5*Tav$qzuRQF~P23}F9yd!?QCS%sZ!mvk$k-I%z6HU#Y`DI+q%PA>Xzd~1z
zVBjiRr*PtlBV}w*hG~lS`w&-?m`_H?3MngNBd}zBRL@vnyo+}?+fjqYB&~-Ue#?e&
z)RNU_C4~<@MFmBtS)7H|AdZ`kl{Plkc}f(Io@XS+qnPM0WVa|#aFoiDxaMgKyw}Ll
zK<bp(FDD1*@lMyoKk+!JYryv;gCJ8Q$EIUUkYXvf;;S^7!-0kc&A&oRhKKuiJH%s0
zl0kyJk@^qyUHvpB6$tw=?|4*Ab1XC7vVsNzJU!V6!`AjQhTF!k$h+|U#TQCAo>n7k
ztV*6?GCH8q6`?;1E}xuzkIpKT60{SvTb_h@<@ILQc-6>g#cps3XJA8#KGy=B*8S5<
zuYe-+4UD<iaV%uFkNth65+7jvN4&$HD-d3528#GtI(gvuTs?D{Ik#jd7&~)s9@Hkf
zrjby5ia%(bauliPy7Gzl6}K%zwqY*l`3r$9T82rMw;>1=a^_#D`mn!*GJj3hxub3f
zw%W>51?xS*Rm?j-7f=<qdO@J-o64JBpxtA$>@JX3DETRZwAnW#0|SmV?;DJ@N0ySU
zF;RU4sisgPMD=BwPu$p<SD1Z|ymo2Mn#!kd{2PkfO2lmC$`|{ggVy<K?t0&p`kQ9D
zu+IH3DysJ?pFvJC6N$HM5rS+bDT*m2o+Hhy-udIROrTsT34v>LzRsACeTe3|anKIf
z?!65OrJ-oYsOY|V9vn(wxY1>w8RvySsx5$Qg*tiAqIy3i<n<Uv(sYjtt3*bBS|414
zfeXswtbtOOdHww!k)W0jV)~>sNnHKsLQb8+YUx*-i=uRx{t<M!9+>!-Uv1|IqARm$
z{J&KeZ}l0BTJ09AHN)4=&BP2_v&*^f*Gc4Tj;MLA#00)n3zI|K@4*j;%l$E}dWIUW
zkmn<8?V%z0iPQw;=jW00Win`-j0=v}ypBXM)42U(vqTl@v7(<M%@|P|l}%F&<X&S7
zSGw_fmT!hq%uIfnSxq~(OJ|_eYjKu7C|;j#$%wVA=t9iE*{>#f^J|7V|JzNobY}!}
z&4Bvi1g^$HAH%1durwDFTJmv;uP0&zg~k~Xa>*O7Hf8jr6E7}xe~~2X^p0zi<JgD4
zZ6Hll$DqbeHIf{xB|_~E`ANHbvfRTnDSOr?%x>(YV{(A)X3R*useTS!2wo#X$3Z2j
zkNFikKN;uXpUAxw$I$@!oZ~jR$4{dm1^`=oyjIHByE8gr2L#3zdf*FdezkIx;jBfr
zkh0SOU=fw(NdNPii+mdFitGOLKojtM#-Lh->3fLYDsT-&=!jz~n*iFCM^?E`8Q9RK
zNRuTu&~~HzwG=rqUVw!5@fT%aF@(1|V-G$$3$K-T-2qXugA<>haDo)(PV~*KLOYC?
zJykmawy^fRq*LGb2lX-CQ@iaj_dEcuun)y?L@}CIAfyvZY=WIka_?>wGO<EuTDOx~
z0U*$0vmR|$>1Jq}wwasT?WwE*uSI5t_gPS}gBK2D`dscQ_p_YFNfU$sE+MyXGK#tz
zD*gzYCqKp=+T3^-1ZWD-jo&FoR`@QDmbUV01UftWCxR?N48l{%RlWV_m}uCkN|Miw
zj;r2Ozm`((FQQ;8ZFS|Jm91{;+Fs)S(!%L#p``c@P#-*Q&M1bx8*Mb2`@Wf&3<}V+
z2%>C@07G}cKy(LTKS6y$f|6Au+wVo}P-N!y8y26mcT)(^?1>RbWCYxM2-BtWJcmUt
z8K|H6ZE%FIrkM&P>(U&Z->%&qp%d(&f&MiIjElVy^;GqPJ4A+PBna5Yy5PXb9Hsu9
z1YZMV<Am7P*RbDT`Q0WS0Ak2ui<bx4N7a$^!o%pmu6OhVp<Urq13qiKLn^sYDqG|I
zyZ$s1GW<bS87?Wy;|4c{t#XHJ%bF7<g1L3KgPD&73}uH4+T~>@w~)Zueu=)`QZ>*^
zZP%N)q#xZAx;k7J2gUOyG-MnPisa#}OPeli1VF@;I6f#3eff+hzF(`H`qN)mMs8y@
zAnC`=5StUu)JU9d1y=K>?L9r)yj6hPVQcp=ocqQJG0O!@<ivO}<~XV?{M5MaJM9Lw
zEi$d&Oz)B3{>}S(9yvDfk4M@J9R5vr0Y#uF8K)291fx$kikC!~_k$~}Q*G$ujv!C$
zU`j3;ue3Ha?OWSw9mV5ZZVq<$tw57R@VxYW-qIgCJUrFL+7MLX9&b9|Fw?XpXU>|T
zJ}=aCu=q?A&D0_zz<k1DDY(6sAf!2i`?1i^bDYUwVMGE4SuCRkqiAgMO`oHiS7Tb!
z*s=@4e~{D2<iPSe!tmyN)=;HVPc0OX<15nN1sHJ<BN6RPqQ8ox!WKRrA;aQ${I@5k
zZ3`J*3ww4oV=M}#FG4kIPKwIb@9MMY93ncQ>+iW`x$f{uS<SPwEDXg1TcXRTW1vjH
zJYKAWIpw|NiDmvJ!IT76>^W3+NbWm_Ck^B8V|2tfUQmiE21+wuH-xR`rwN|FDYg!=
z<22pl3IBIodvPEbLtz}Aw^@f9vjC;OkmdLZMn2zTe2G(&OU*LpB7>45cs|H1XmI3T
z_Zl4)SkH&46ePZ_rUb&VLhb++2IwmNW&L731W%aAs2*Z_m(wBAb0%AX1u*!1ELbK1
zaYDAwZeJ(U8(d+(x;m-RU)H@Z0%b_c1pyIv^{G2oKB@?$TJW;1*{y06cQzJKT+!xc
z(RR5xwAxgkb=du;qTJT2g#3NbipTfAJ9|IBlB0(U{NhW)lY#TyE5jZ0HKh-de=uG(
zq-!^jFjp#4M-t-=?<X2o2Q~D`u649%=P4FTRiJ?#-OR}fU}X8gYVDP0twQEgZWxg3
zbJ%h<i9y1>o`*gGP$oylh`*j4;&Foq2L{)kKW_nRJ6HSdqD*(;<$I?N@-J1UUcX4v
z%8MwCZz>qE<<y9*x%E1YRl6s&8kWm)D&Z}a9?OwnO=dVAh?p6t%dd<JC~}$HcGR$;
zoP^ewdbW5?QC-Mx85oD<3m0iyj~Y$YG(M@DPcbf_%z$zFC$fBl16r2LZ>cq9vM}5z
z>h^JojnjIB#nDMGf!;oTUhnpF_+n9Eb#4K<1DPAr)kOh_015g8Iaai`-Nq1Vxh&Q#
z<pE{mXj_=b^%w;Fr+G4Q^4_vq2)<H7I>q1I>BtrR$bd(HpPB>RoP_o3gp2nkYAoX1
zd6a<yk-EB{f}S_a_yFR^z=kupK+~Xrcb-+#ca+8W#Kj|a9;DBB;6F!PhN--?3~`pW
zj=5<^;WFRH!449J8-5r4c-uwd5-*4zxJHGBue1vC5B#x2*j%I`mk}4|lm8EpLU{Gw
zeSF{_)3pYV087n^A+GQ_XZ=!c(WO_aJE=bPRzLQiAzs@k4hs;j>E@FGreWM0N2>Ku
zb0U8|$A_Oa3$!&9e|Z6}dK=xZ-M-#w&bH%tEWS;1R~W^=2!UKc*9YV6dl#z|7B*c1
zf(LVD@D5w>(&RL^POjRipktIX(V7CRe8(?iGgTRAO<2?d{|x*6kyNGIac!4tT6$U<
z5n&E3N!{r#1Nvk}Dj!aex%99FBVXCMH?^>zgWKPaF)C=yKTUmKJZ}o5=a0tsG&Lx~
zmkYrS2C94fR=iMcn)7asas&sFK~Bq3<?%s$zHUEb&g$J{OY|Ko>%^VD!am8rY$<PJ
z9lu!*Mxn4g22NVr5TNH^fPM4ap+8V(fRfA%mvMX%NGJ6Sv?|PhPd+y|`f%gw`2^tw
zaBl7MhR<=2ue<;K#`Of*>b1bNY~s5DdqsJfBLw9K=UN6FirC)xpK3gRa-7w872CPo
zt0dj>^u7q44p7qecvM>un9#?s8??WL6(N(BmXNCv=aRvZc8)o?u<=J3K7G2w%-Am*
zyAxDX$j|`OJ#XXcf^cnF$uO;HQ2*?08fK9w+=>B8y`%D;tv`702^n<&$7bIUQA)Y6
zSTImg?)eTxCou!)9-1qtP0CZiUc~~hpZ4%%X{wK7ob4oEkW-&ykigZ}3iFx^WS-q8
zk*JYb1wFT^b!WC$vBV2WYUndg)SAXUpc?Pu64fPL8??+;8WC)-@$s@rm(<;0C6o~j
zzg};i`W3>c9NLh%kNHx!7R3T<y$TTd42Bf0Vr?L6X@}j&o_z);ZnY0B-roE3$5lb8
zM?9tb^FPphmsj|((hgZMQNc8iBGVMH<z|}mGaXk(gylV4vg0QPKV(H{{g^<r8N#H9
zzH_Sx&3nl&TFGu^<zc9i=kf_Y<fj=D8-LP(ea#3JDKwsDEOUOLfgE@)d~M+|RQ8mP
z(Sc802o)KN?gi9<7DEQ~z5lC2OnV}?KW`PZoh4hvvE3R_R_8qf53&sXM!0upoV0S8
zyQ>A?OSNRs<IN5AUoJ4b`YDQC{-pLf;?b2o5xYM8;z1tlNW<Wx5VbBHI<cI^5O_m<
zW=EZgds4T!qSwTTD~F?u2+Bz5sS1*=tg;>A8<%zZ-GkhT{N3{$I?<ZXh!aKhx#+H~
zGq7b}uR?9;G|PFKbkCT+Z)=e8tlHUfk3tH5-L39(xh+S@z>{4y*vWSbENX#s_CV}u
zMfe)zo6OngyUw|GaUT4#(|8rr9)S`xGWj{<_g3KH91>m`uf^{U+JN$uX8&*HX$Q9}
zS*76WyHAXCecH@W0momj`4WmO5|t|ReZ}vq6??g_C7ZgzY;@L+g*SH_l9%sqk~8p>
zX&Ve{fZgk9E}!fDa5%K#b&=(&LekX6lA1c0376TWFNEW2?MtGLG06b5or78H^acrF
zN+9n{`V^Se6tKgIrHDFX$!25S8J41}O}JnC=}pX|vP1NZ4Lum2MYVutwxnf?JFI?4
zoX0-Zr@}wp(Yu`>Pz{MI$FtFj5D3u?`0RB!uvJX3NHAUQ&)W5<fMZEAV@-X|&*0+S
zFXoy16uagP?D1^@IbarC9wO2;H0L_M)Rl;gklU%}ZLY5)Yl;|Nb+E*pne5%#wr5GR
zq_FfKHaj*2h3ADC7GmeG_U8DIDqF)o(|j3BL4(dtSh`YPkcBC)m}jo|Pt3Ee9KHrd
z8SOC)R2q3!nfeI1dQ%8-r#R(1ioiJC6K@i7t7v4XpfNRz+~_}16@9MX*5gz83pe*=
zH+ytFiUjJYGauhHrRZr&cRk!yyps=QcX+2;^eC?wH?|pl-<aYt9#ARe?{{9$RF?Db
zY2KAX`7N%*YkQEbPnzK!OKV9s!&ge7`@+bA16(zhMd%Aff+PCeRhEYWmD!`8T<+x@
zh$JHhw2Kogv`0Q~Ylm(9DTTHsEKlX7v*RBFicfZsHxv>m;C`9Ev1D#`kc_)Ui?Tki
zI5!fvvr8W=f`Sg_yJ(SaGsM2~3WMjH#F6zZ)L+=I2qj)Xd%3_k2W*6nHGgLpg=KYR
z&dJeCv@*zt4HwBXZTPiU^}T-Qn8doL;{=g_zIm+A)*^#Cac*YAM~*v7iG%sSgpqks
zXUa@P%1yJiAEJln#YXW9;0@88c57l<?z8uB!RN{HW92rKs@9^I`Nh{etT?Sv2yKF*
zhm85~34drDPCu(rhpPj5g<bKq1WmZUeGrG;Q5uq6uuQ{ecgL0Ej<x4b#juwTq==Q}
zt884$F&(WL*dvlfMGj;t-mh)W;^$%G*Y*?RXmfsiq0?MnT5`YoIVX}4kPnp)W<v^X
z(1pCP#3~~{1YszA@8_y2<7cJq(z0sj8-8L(T|i?vmC^%Y*CZyu!5q!bdGH#sreC*D
zI{%&tmK?bljf+ae%%hp*&)$kbzIqvgX8<y+x-jZc4)mV<HJq-su-K{Z-L5MHH?kEX
zT%E}_081uH6ynMEf`+{yWbrk7FJQkSC>HPD4`AJUNg}+0c$e9>GQ6dJ<bPtAVN1Kg
zj9>NoNC~Q$g?h*O^?3k(R_Y6a1%14?$do;N{`ghO!uzL|Hk3#!cbgI#RYRh%ln&>c
zHOOPtlKjT2K|dM&_l~_gj8+G4dI$T@XxIKJEZkWoEO<-)4_!gxd=+^oS^u!Eb#~kO
z?wpqL)cfr>^Bi|4vAIC31(KoWFIp5xq}uWqpI-f;EUb=WwY}hRcth7=<bcHtC;|4=
z80b|TexWsi0VcS@H4!1WHs};#j*`u_h!_(uEw`TwSH>ET3Gq~Pt$w#)WcRi+pLg-A
z&#Jo0kSLM6Q0LhQOq*9k_O<O&<3$zeA)*{|`GFNcPPYRHCuy(5NKC>nFmdw2q#oOC
zoIW72h}++N6?@loTgdz7%(cz{^z$1kWUZzqWxu7OIl^|^dsB0B?nM0J*$C@U(gNwl
zXaDi;{CQ=X0299Cz7a2D+JW7@w1Ms{Zud85C5HarAZGJGzh)-xOkmll>pO0mRj?dH
z6h@n0sLxi2;SX)tvs#4Y>=s?w^(<|cGE55drUe+_=6^#4Zl1jFdHqi&uLF4zx48Dw
zpL}Pb20&K$aD^UM@SmP~{YwV0TAfxuQcBFBS>q}dJrJVyG;;Z|4h{5sYD{f)eq}ek
znELJ|T6qt10>?jO4)aqE3S=>kd0<T2!f@Cv-9A!Y@8+jf0z!jlv~cN-CHUWi8JRcr
zH_%Wtu}5OQjv2Vm%YVD(#M;m%SLQHhy3T4CdAja@9QE9+K#{o0D>Kt7aNOuRb7Ca@
z4JqRCqR~-t5W@hzpcnwa?9@J73);+9^F4%PgyjL!J^txttHRrOuznmuuvb-+h+YS8
z7A+SRDU1W^3G7DoX5uy`wbpp*!ORd@$BKoFrBqZ&f~K6Mp3kwTXcplg^UKHq+|uFA
z2Bd4CR71n<zE<SfN|x!mIt?g@uE|SgV0i;WRJ1+OjEYi<PLJd8DW7vxDFyHXR^Q#=
z8AEG~n{Dq#Ve=ynM))2ap+YMJz^-5QSIN`Kxwffa&5p=35l>MC9b7+NzRd_W2Vma+
zM@qFLaDM|!;Sk>~d&;$gnM6+)TkJC>PWehyz)==?nobk$lENdr>KRyK3<7@)<9q8^
z75D`)^P{UN1WWyQ@)TB0rvk&<v4%X>lH!_FQxqVUw)fl=0j5Z9pVz%J07}QH#+k1^
zNO9$+e#8F!I6JjO<DmKDw?{ar5`x$JL&NUJk_)lSGox^^&cW<fpT*LIh)j1LKBOx}
zu_*wp-|~+4%akv#ww1&B7X+16Bu*S-KhjT*zB6wQ{XSlq1NF<e!JZS_C9h^6`SVVm
z61JS8pFcdKFP$2RfiYGgTRII#VO{^f@dO$uREHYl=Ts;ZA#Dy>NML97Y|l{IB|Uln
ze!0;u3Jt-bX{2XzVHds1VZW;P=XY=E(MPb53ZTTKVT`jHbp`ln%JZ{LDC%&J?H;AH
zrwrI^*Y?3{|2BwMW|51Bss>tFkr;3GA5vMV_-n8~W$ZY-b~2IbhVe13pV6(^8Qd}P
z<+iX~FiIO;;37pd@&7p`t0;0(<tF-f{bEn8kKu4))lHW9B|KJ%7ed(guX*0u$I*XV
z_Q&>C{ZBf)&~M;L9JCduAzMbZ!=5bFTrURtD`&rQ4)PcHIcQ(wLj9r6>Yt-45C2JO
zC%@BP-GaqfO3j210cIL7Vz?41+Evl=9%D#r3Uj0b>5uyM53pqTg~rY_=tiT@TuSfu
z)5ZQdkGdQPVFh5KQRClOEJELxXm3;|zWxs8aFRdeqdiJaSrepRiy7_yHli4JnbSG%
zz-xX|_rhMAPz!)p^)4LT_N_zZU%RhA<{Rf23Ac|2M5n&*!kAs-?hc*O>=T~cHK*Vx
zq8nPQ9JzYM3Y9J!#0`#RQY6B@jOg1LCR?i@!n%C^$FLYWqn{-R20j^<EIszt>FJyA
z*`}a`(|+?`qA9N^P*KwI^=#atTRcXZ;YH(=@y%a<r4OyAQ-M8gmZ+*3Jb7wRLQ`x}
zT;TsHzx0#ardR$P`L%N`Z28B*<nnT<_y_)tDe*Oj;eHySQqycZLoKkX*(eKLNX2L1
z3A-Gg_xxwdAsB2F`gR<5KW2K%n?XU5^A#zjzLf`iZ0SBYIpcEARV*}Y4#i@cO3=R}
z{MoY%nBo?hOiTh*aR@Bv_(}h~|5K{M#`Bu!$ZWb=y4DtuFN+G1^_<K{J~tiRXZ&tg
za@_;LAo2ot7Td2e6fYl{bcl>!EZqwNQ^Bc7G_A)cah`YTCdW&R*&lTq-UKxO_p1=y
zGeHhx8X`c?4v*f{UJYt{e(F^bdvlYJ2;EYBn^gQN8ErO_jR;ZRuYBZ#lbKBQD0HRu
zpSr&NC=eQ+)1%@>*pVoWzTPMsh)S<bKRFKbYZ}hR8%g85buvK8|1u3PZK3p=fg5A<
zhWv9X6xVpHny0z#{jXp?$V-K0N{djBuG*U`do<s^P4wJ;g>(}Iv%BG{=Fge$pNMHR
zfKz`q{n*ECdNIX(BmhXrbz7bdF~<kVzh+*g22B8#iJZnaM6EPRztZSUo1V5;35+LW
zbWyMhd&!66>A%JA?+qN4{1@r(`DL9(2N89@ew~~Q6)`3>%n_!NqyJ6Y9UPxu-71iG
z2IR^lO4|L{^x<wJdla%Z>d$XB3I%04XyKl}4T@+j;{NMxKU5Qg70}-EbQ32z2*hCY
zo<IX_?5<Vz*|OM{Z#hr5Da?;=`aW)DX!}>r-@m%MtQlkCXVAlT($DpgCB1M=f<}<N
zdjV4)Gl=Yvkm!||sPQ+uU){+>9v8#KlQj$xd!+e9hgV+Ese=s&&k)PRwr9}X<raH_
z@}GL`mo!75p7u~;+LI^l2df^&x1t@WaPG>Ft|hg`t40-(EW;zFYgf-AH9$r6G#D1E
z0`B?WV(Ooo;0oM(sBp<$_+^3{anc8)ot1p8Uv$(veF<)GPN$3K2vdrOJB5BEw)x5W
zny4kT-vC#Qu3Qr;DSG+g<u!f>@4H<O{1~DrYX7E&O;N9uUUV-X$>Y;`-Oz9o4dIUs
zsHiN;-vAQ56Ko4uW(XEjKeWv5p*Uk}*un+n?of~Ta!w1=FT89d_=U&w;j{EFwj=(e
z{5<b<ueO^RQay?0!cw%4b!fILehp-0Ze<P!Jn}0yky+Ax24-&Y4=s8v9>tLg@NEE@
zd?bg-!$UBF<huO59WTD6)<PO5q9e1E`V7X$b&2}M+q#bERcum3#<7GCio~h0p0Qfr
zOii7C88-z`x#(%0{-TFlKN8EtBg7RNadJ^8&P<u?HNx1tO028c51ohJX?%d-h0q=X
zCXu1iR2R!)Bg$Jqh;%7~BdK#$=sa5a-;{rt=s%Rd3bL*I5}6A$PsG6)<EFf#zNRRX
z3&IN69}ndeI6%ix_>n*w2YT9nJG@gzXGUER?8b=w`3=axY?w<{h!zfD{un32gW&{r
zC%$O?j=2h;j!Mo=_fH{8n84V=%qh{3fU`p*o<b|VDA~c~E+Fn16`cSio~Z#iKE!;4
ze;Q4qJTJ7EYtj>s8}&J(zR(&ywIxSehOYBkw;(qyD8gqtrGlp{QhQ_Z3x7!Hqg|*1
z1W%M{&91q#+0~FSi9QDnP*Wd$CL0_JX&!lrz((DV`0@YbGI4F(A%_5gcJ5l8cg$W=
zX}{^7tHAk7qy2NL<naxqEJT>>sYlJfYgn*ISx-a9bpAwpzW8gTSE+!i`e7EYiVA5+
zDIIVz0h(@&{>(W7*QP9)V*J+`Z$5z{Zrk9*pdG7lSfY4Sfj2@ceEfwLhH!rY1@Bg_
z7yR@0W_9KN^y>`c4a7u$xQoe-1gt&O;ha{9;GcKMOQU$2i~EfXOE#QBJJL?$|26OT
zZrSaZxgVCGtv~;$6h~123{nbjfAynz4}u{=Wi&eBNi{J`ecdE}`r^hSw6$A$tAck?
z0WE%;jaGLqeeNbsYrIND7OtEH1geC&WI?3b#W|tH(~*@{g;{r#W&X@xwwn5~sx}N2
zjdP>{HZp;u+s$+_V=hqwRfs!^8ics64kMFx$3R?)v)<4+KNO{{*^N{h*qN8FvtHHc
zR4@`rnb7W{ARZSv@jaL8Y5NzP2*<ET<eC2=Z`boq{C*e7kT*(F`w>Lo^|>=Udw*F`
z{DwD(w{f8d$k!4o-8M|hip|5qRXbIOoxkRubuIR^X|QU#m2JCX{Z<SlS+dGc`>)%8
zOv=o&t{uYqSGkTvx&KbDP|E3+hc*4;K-%X<Uy)nVBbiiUDcLW)__6a&lt~6t6;WvZ
zV8)XJ++D~PhRL)$GhyTObc1TYw^T{HbpK3EUlRT-H#|!28L@l$Vx=s#Lk&_6;CpiF
zjG)tK>$3<IPcoz_kqdWDA^@8m7U;1h7vY{y%K8y@{iQjyIR^lm!v%d7FG~5f{u8yV
zlEmyzi?nLU3Uyd_ajgOSHVmWhHf;-_C^Xu#Spcq!=J1cHQi(%m+_0X`V@4OaR)U<?
zc_VmXA=m&8`H#cn%~Yb!pAL`5k=H(c$KPFrT?0S1GV|#qS;-61XEfTjT!Doq5pG7^
zsIM)j#raB^vL^JG9W#KexN?xoZOf&CBfluC7iIm+Et6w5Qr@~4TVRaQNh_y92mt;%
zHxR~ubP4rVyw8Brm~}9!bWrGeotF|`GP`=tk3Qb~J1}QL?5(qrJQw4?EZ)>L+`Zw5
zT=-%>{<9v>O>(5stMIb_B9SZdnsE*>Sf0->I$Z9*-5OGGh9u{qxLQCq0K~YRcp#M+
z2Qzy!YV04M@gE>{)<0gnk#Bf+S<K>qJ2rdo|N0Sp^~+myW2e5Vfb8+$=Khr$8x2rW
zFCt$$P$N+rb_2ePw0*MFeLI_dR-!@Zm&btd@e*miNkcA>+|A={6{FMrcqKxHV(qS+
za51d&8X;)qX#!Uu_GI9vP7N!YI>aQB$Bs9w+Yt3e@423?ONgLgyE_avbD)YJt3t%)
z0}KN3H8K4ug1RH;q++=$J-G(`AULF~W*qV~?$b)N!29u?bNc%ef&*my&*I>h1z5#^
z>y7jT43RH4%Ie*cGs;5UvTYc#bez|dY?p^2d+j|uMNNwq>QTMp#p)3C;=?;XXX(7q
zJ4+Et?Qx3_?QQV?OoMRR0WXUVJZkis{Wm|-cuPtU(t9AVav!gE-szJ(vCFze@_;5v
zE}IPA&#M_WwDcvF+jRoM!MUq|QMuiwmnnF|9oycROR<mNFQS+@fDOT_7I9||0Z`C0
z8;p837w@zvP)YlU5j3E8iq6#e5bx&Id&}HPmZ{2=;hQg!e=vDsHAg?*3ku6b5`Sy1
z1p@nJzXltKY?!h-lFVLzY!ycEfNIZc5|h4sLEhm-6Si3*>?lK|8DVClD!v5HQPQ);
zgWf`_@lkSrGn(!kKWCHB?hj)I*0(DWLFiqJA}kUG7Y(+RXKQa^Nj;j<aZ|}FLuvL9
zNlmO~zyynHpChn-VlZdpL@>QH@--tVGzL09>mR`JokO68!iT(4v~}3TI&P#Dzl8q_
zS>uiB|8H629hh>KxsIds*qUA<y34#_Fo`(u)+=n!h^}K*6X{c=R_{^KO!LfO?$874
zt6|D`<|aeZs?IYC!)-ZvA<oQ2o8;1_LZ-5YczuI};Y}BKzoKKt_R5XG-Gg%W0yp?W
zK30d%4W`3-{}e99U1$KX`pP6)CXw4}ZBRQ^IOTVaSE|Oz=)4Z>IltNWCB8Iu2YCL;
ze>PXYn&YTalAF9FIW@BWhC1G8<n)#fk=oQ^bcf{g?lQ$eaw}kfpDX3~a6V^KpJux3
zFr^CT`dobDHh9XA^f$!Bmksw=lJQFM3z1*=N(jZ;-}1L_bN%^<YS3r-6-TN?ESbDU
zcD9D1{&XSieSsH*%lkZ>K{-hMjyO-Qv1aq(dE4^|J0MMUe|zzC{ba9i)Sx^(u5}Z@
zBQA6H=aoq1uCq~EQQ0(RYSBqk`n<$9xX#J>FTr!?ai292$lkqV8j_7`Fe1!{K!d)q
zY7k1l1#iPn2+fNxLjRUPB=o~Qn~H8N;RVYBY9aY}^R`c(kG#*(?3Gdqo*M8F4o~IS
zD)OEmhseYMK$l}@gGWT`+IP+PQ__z>QMhF>N$R+2{-!?<1E1vKP*~s=8d!!CLElQG
z;d=Ay{F}FSg(wEI<MaPR{`(SRz6t4gO@h7Z5UC)N(o;8oJ6D}pDfGjXqPcpMLI9G&
z*8?)RM@r!32%V61<WbtTBRUZ{-azv?;PI@wVXd_?rNpQ|iReYp^AiiQ(_>EevzDNq
zkc}Y{d-M-%Zv@ygs_7g#ED*VvQdL*P%<CafRuJe4Sz$m0i`82JU8KB-MAXS3jtVd{
zBpkkoTMzIzIwbL%+vTfO>QCQ3AEX@`Ctd57lj_4jIH6iwjJdpDEt&{ap~v{fRqG!7
z$+Triwv#h(1FA&(XC_^N97r<9I_xhEfYFs3Zsx70IL3fvnE|3;&A7%h-s{nFnEw((
z&_Vx1Lx6jEmeBss%*<@JD8$1r#epI+PiEM<H4Tv@X6%b#(bLKy<E`|JnxOL%a`mZy
zTP(zD8<rqp{^+%>c<!QB<c;O&Z;$Cx6N>>Scr}zJwJPaFLwIG0Y1*3$8bCz>@@I!F
zi!JQ5+4dho5*!N4%zGGRe*jI2g}Paoof+8Z957nA@MR%J0i6&xurZeSacsl~FNu(g
z$DW8vZL0d=W%%pSxU&F1*RG1RkZQ=Tw7Bth;^XgyN`jCH9#SAP0{ob4Nc)_okKm+Y
z@yX%SRdalp`aaE&@rcR#kDOIiUNtAjk9NNyQ8|Y|0Cwi1ih{Oe%Xprnz!#NH7t&-u
zN#N}_TmmIoJl%&kDn6*<rs}OUg9v9mZC(MymkV1Gdrn@U32!qO$;4g`sDvmprK_`K
zxM+;c!19GYW?3QZ`YXw#l@<oDNikaAa%NWNEcH*EHI`lOqMmY9DkIazuknmTb;mB0
z7E{o@3d_fw>vHRHDwIO0?A!5rslyel{D?C~oLW2nf))Lm;SUGa{!DAM?5#sg#Q`=y
zs&Kc}IqIwf+7;O+A9WO-T}SSs8qD3R7!~<K8ZipTGNx`7(n&gYi*l=Q50by@`wDy0
zfWP#~ZU~c>#pswM;HJ5mZ+fy-?HAqV`rgeZ+G=`;-qrkXt3cRrwhdwe506;IUwMl&
zHx#If{%A$RD{s~@EzmG^{*ZjAomI<1v0%|xsF}6(=z44TRka~$Xy?A`p4>N!n67n+
zazP5C;Y>rU?9u*Rky6vw?%05MX`7Xd$clkKymLbl@bF_(Ml5~$u<`pAj9}L4xiG#n
zG6v}}7{=-MObsGQ^G$>Ul~ug6j)Bp2shahMl>C`DSP$N4dh~G;K*d1+vVxwRBxl(2
zWAKg_6LV%z)h>ZRu=!G=LMpV%wEinuosnN?uzT24BdA#<NY~c1KQU0e3_$prksApN
zzux-uX1CNCrD9aulQtWUSdF=#hO+k)*6Y)b!(m0oobT~@F=y-AyfK7p;=F2p$<<JH
z{7VXX!}pgMbHisV?k(dvzq`Wy_cUs=TEjuT&b|?ef)|B#x}e+<1mq7auHu7Cknl!P
zdT^1M1ji!LKdI10WYDXnieV;jQ4gkh_MUo`a^^=cU^$wh{58@bPP8v8EXGo@WXxc`
zgKWbY@IyV1-+{8uu5^EpSn>8B6<z&m&_>%lZfp}`uaC*E6sI4@{<oH|U$s!@dH<f#
zP}X#SUjS_m<rcj3QQKV~rxvxV{c6(hR{~R_sV>ngH;L)D^|f)vH=ooBe&Q4V;j#FS
z`VabF)<|lg2^eDI+SyGnGfXxjII&KslvSjKo68~wGzee)ZiD(@^%93ZHipjiSv=zI
z@L+FL%CL8!%oAkTqS^EHP&Qwj3^>5#w}=&>`jx(|=c@-z3#JW6F4=2?Fd@C~O*Mo?
z1dTQN7kl9Umy@qo_R%3Ir@+tSHte|Gid-ey&y4XQ^Rt_oxun<}qM}VCS+5y&7Z+`M
zd(=A`>y-Qb=&fMCc#4MnIN)=pJs#dmx7Ceqpg%PkjYhEviqD@vu?#55M`<<LE@Hax
zrQCx`qr8dxW&d(y?9c+@FNY7!LK9L<2UL9>g7VB4hg6Eu{1~S3EAc`<=5rQQ+#TxQ
zCq4V^&Uk<0$qVB93O@RAlMbA~b#er}L8iJM(BETc?OL5pZG(V6DKUA`5@Can{||2x
BL013(

literal 0
HcmV?d00001

diff --git a/doc/assistant/makerepo.png b/doc/assistant/makerepo.png
new file mode 100644
index 0000000000000000000000000000000000000000..e8f1b26216e590daa30575385662b2df77605281
GIT binary patch
literal 32061
zcmbrlbyOTrw=Uc`!3pl}mf)@fgy0@L!GpVNf_re+;K5;#!4gOa?(WVoxH})e^S*c8
zyYBa%`_Gv*Q{8J<JypBAs;leS^-QFiiaaJ7DH;F(m<sPe8UO&V1ORYLsPHeA$_Uf<
zFNar7@AO;&03Gk29~_XGP5fd+aZ^y1MOi{6dyR`X6MEwd0Mvj2NJ`6V;b7U>kZd=H
z=}9$)q*>0HmajZn`MVokVj)-xip<CHUh|#pIOcn@DgN5!IZwWe8Lyf@Vm&J))hH__
zKYgPgAwl=t2b^afb<Lr6Z1q*vvn~P&2Zf9&KCx2{zroDPYV|4nLQqph1!9u>Ct?NE
zgb;cs)2z|^?KBfpUY^l&zuk=65gwkzYRL79uM`O6#<B1V2M2e&$p%)em`035OS|zd
zE+Qg=PKcJakd3DQEuv8S(;W;$nqOea3E`_GNLSFfnx3}M)|0+(Fhz^}iu~UIg%^}{
z(WwgqL8MrCgkT~aEv@N4$%6H7<7)PCpnF4<uI2MfKCV#%U90?+_`~0oa1wD^+O|S@
zm){&7Y{q)x>psbUg=*<u8fNP!@EnKw%HRPS(N9Nx;y$Atp2~ikWEgupKL=AlZcXu9
z)$)<#A9^<`gCY_Qf?t1b;m5`VK2qYS6}Iihi8#pS3haZ6Kv>B@^aoLtY!jbS5CXgD
zX-cCDT{oF`M^^SL1_8LmAS8A<;H}W<%vL@0{Qa;u(g#CNVlMc!*A@hy-{K~1%qA2$
z7^J41T^Sf13ER4S8&$#`Z%fQ}vW>0Yk;#OaMWgTf*BCu#K?4KI${iN@-}N+w&5Q!+
zH-7{iv>a+4hdP=a7SZxQjdl=m8s0paSSh;vx)Oo$c6mZ9eZSkme!+t~+*F=mdF|9s
zI~cVeG&IgKW=4BQI36~yvkCIrcCl`MnMUr<7NB?KW(N@uJUX~sW*XS;vpW2atNKQ~
z)lic>q?-4Wtc!(3&#z3O%jxkjZv0jIw;|U>KJ3FMrT*KrfH(YIEhFU3%*HJz5F#YZ
zTD8~DvXLj21>wiPTWVV_jn~_#xD49@7u_XR<}k_oa*9tBYq<LEW>w@*VT7DzAyqXg
z$(*qdD}I`nN1k2!7s9g6;nbkk>(}F%?^o_ut}WA9yEda^uUED2Y`U+ihyu@|2RK|a
zQK&e%7TXZKj#_sCzx~ep@3TZjjyb+7x}RFGyQfT^l*i6%YD|U<6E#d`FZx&gO|~*j
z7Dqd8CQUf++NYbjv~-rwf5DD@&YOt1jN5O@?~fp#7H6^?=Iggv7NbWWrSFgaE^m8w
zxIg-SaeYp_H!A;=ceg<#{v?9#D0*2H=)K^od9q7&KZoMj4*Tl5Vq#?IcWzX$`mnNm
zZK&3My!teaZix6^-16xciet$2ec<)td8>w@D5VLTlo3u$UzR*%0ZT{pqFA-V`T1vS
z>F#^NfF%C4gkR1^3#gXpwWx;gV`MoUo;#kOumi7R?>n!FRw)CY0vDcsf&Jz=`ehTY
z;42wRo($DDeqU*Bj;cJw@-j@`xz2EuPE1Vr`ONtqwI3HeTi<o<zBhZef*$O;nk@6&
zFS+*DR~v|fAT53y8x^xe5;nKL*cwJ_^iw0Oi--E^eUGM(0l$$vrEtPP4$}>y-R+-w
zmg1$zJ4v5S1Dv6kHcf5k23+kI9Xwq(Q15o?jnduI4ys!)Twa@Mns{~0!$oVLkNxQ^
z?a0Fx18}`mFtEEUa&#NvfMOi5a@%3jb!v+%kxpddv*N8wa@4YG4CE#d`vuhBU2)&$
zP@zzFoo{M4+oOw1Kwm||Fjg_co^Kj2Wv;IzPL@%`pOZ$#9!j6V&AY06{XLf(p-4?$
z&?j_s8$+dD*>)}e(_iiz3}3y<_cuaezyb5~lxNqEC*Sk8!0OG-N0)i@Q^oBKhMwQ(
zvyo{Pc$>A+)8#IjHNO?7qfb2}(~i=@LS71>rya$cu=W+AQpXL*OMK{bdTD^63*z_a
zJ#A0-$2pn`a@<p&r%EdBBf!a-^JE<q9li1Ei-zG`aP;Za(5XN(7yA-vpsR0%j$^0$
z;Ka>wl>rd3F-+xi?7L#v!WZC-;`x!5m9c-hyp^PTboXmHi^St^bQn8SKJZ!<-1V@+
z=9rwn#hAPl^?H~MofW8{805@&+9;m=PV`Lx1PrbY-5qsMwNZ4d`YU=a=U#WfO9ooe
zZa;i=rTk>FTzbU$4F(f;7x>lLAGi=?CH1_hYmj?;H>*FIn<pCY*a?3=n|trED1i4(
z+y5-S<gheP;zoY*iX$`pdt{Ns{mh}sgUQUUuzW7n#KTVkAp60AE=cY^4esFFPcieb
zP2_nkP}IIzeAfGZ_vv}ugppDFG|RDgK)IdpL|5WIb-gP`@bN(k5IH)2q#E^uiHuSm
z_+LRpC`HlM{;u+OUL*VM-abEsrut6K=2<PzIKpB*tyc)L(*xGys(w}pEN48;K#u)t
z3!1Kys!Vz@sgy7#SE^c@Ev|RF&Q5&|Jh)PqX_W2ut(7=vJ67hsnh%U_Hgv_WXnO3I
zf+MYCi`4#DZ8>l*B2z#3uwU*BKIh)tj$Pd9vO_McA}w$EI=q1zV`i4trYq0m`|iWD
z&_jb!``@97N-&{jCn+E2f&@=(5is11{XvPMfkSf1Ge4N1dsrY%fhQXh)R3flxKw=m
z%M5!dW)7PvFUr2RC)j;@e>CvYs$62URP5b3lYe-Ogbf*Gz>cCXRm<(W*}Owxg#0Vy
z-s8;1V^Q0?y{ehMyz+YyjFs!~z{B(B-~NH9)O;E+k+VKem7_=4x)qk^2l3PD(RX;2
zlLN|en<r4RT86t}M~M@Rprr8a8o$E=$EO4BL6yUDyyu&FY>$P`izbN+|5L7``<}G4
z8k*6z?bN=>6r$s|OV@+DxsgU~YyL-l*Tj@gk3BUSyV}>QHv=^)kCS4at9Si5c@N{B
z&jdlINqJtY=n`&_-Q)5JyVcuMs^`b(iF7XQgbSam<5Je=8;9$NL%)Ud4iG3K$uRD^
zx6wA<F#<_6_tWjB{KRu3CKi0l(+CRX<0E!5NBhMDcHmxo1UmW$M2AI4AOhL>ywUY{
z8$Eb{%TdvHmguKg*YDxxwdSthHFRW}8<^ebH61C=k`LDQx4T_;2k5)&WC2$qqiN52
zE<VrQ^F$+?2lKjq$M8W`y~WR(;;uD!>pNB^g7Laf8wX5JPO-ulf!8mk5G0>v?w^G2
zIu#d>By7XGsDRwj#<K?)SS8w^y6e9BI{U6KQGm!H=Qb^oOY9`qs(I;y%c<eULeOz>
zM8w+YS4fP&6Dr`;d?gkr@bDhgYkQ>IS$i!upPTTC6aKIJr|byk8u~Q9G9#Z>vFDVP
zuryuOhYJMHG`P{ZJfEkOEh*iWfK5^txVgK@uBUtS`Mi|&r?~wrN0y$}yj7RM<=Itr
z|EJKG=hAfb?z-v>!U@`$2<OrmfxvmKKNxhU5{-1Z%PcHvNDuh)oEY_6<YBkxI)@}b
z^`X}==<HP9-3318#rs)@2O5aCw$8O}A74eq{{`prJeS7PlQvy09a6PjTO21}SZ&1$
z)^4{GuV&8dM-ZccLA^JS85=%abz=q2P1#a(^j)ySqB<)?T{N!+g|SP4rQ`3e%XZT0
z&CwYYa8e`z9tH<@H3pZyxA_md@7y}Dle23s5#l(!9z~gSX+(=&@0BuWfli7@#H2rq
z1l~{WdYU{#RReD#yY3izXJ<${TXzG@8~rY!T@T#v-#eX7{Ejx@O6_!nF+d$wVFs&J
zttUH*29E6%UL9jwt?rPsUt~WIo3%JahPaHIi?@Ewcy@7Za+g*?OrR~-5DD+YD)g@N
z@w_KuBCd~vIzWpToI$n0)6cNWDGnI;gYmTDwZE3Yd2`^U4gEJ>lLYi@|Eoc+$K${y
z4Ht?aMFaB>qTz|K;O4|iAK2>wC#Wd6M74J#^d>bC=CmAlA<f0{N0%?^pZ6bjZu?z5
zRrheSKQ*7M@3s872~;t9@QL9!z>apdmA81@dED7Zv)R_Zbx#tsxDu#pGvG13EYh{)
zbzh1{q;ec^vTgughf;}OMnz;$<#t%G9R)Zcbo!oWeGLq_S?idUaI=vrGx0hmn)ao*
zSMk&H8GOEIuGCj$N4@+rgZEV0Wi)2<{FpYn^oa6oD^<37+xINQaoX{)f)dYxdU+k#
z#B&ZTTvvhT#lWGX9rF`d?d>NkT=3n$8q|)BaP}v64ON%V8Xr@!+vPD@Oz<?9*KTKf
zuOosFo9Tt8kM|_5W=vc6zh2g$ydLEZHF;>=r_1xVt$Ub>_v3%q7)@d_tZ|$ay?80K
z@FB^A@XE!{ciJF&`(<h^OQ*kfy>96KB`<Nho|r`$<TQKf8F+M*Wirx~8LA6s*L4YJ
zH*1l#J#8Y6B6%MvPrVchJ8tcHkUjijpnq~FLK))J=aaeqG><O0`xtWi`0LOT)iY)3
zqWkL(ibU<<m!p(Yz^<#~?&tL}>N8ApwCfBRxMp+AK9_i0yZ3y_@yS`gzdGLytoPjI
zK?yv2+@*A%i(Tz#eiksf&%Drip1lhf7rT8i`?oJ#T}nVzIZy2tCPpoNPls!o^B&H+
z{GT&cYkZDWHC;tIpBU~pkDs1+x}L`lW}T0q(`*lSv(FC)p2rWJ%hnJ5c@km|?tSyB
z2sh8-*Tu(yu&ZN<^Lr={kw!DE|G~Ax)AXorz`>U8=<|hHmnRQk=vDXdEZ%${FMcy0
z-+r~kqpEN`BD(!>VAQqp*q5?%eVZ!;Q`*|JdU}!&Wj}Z-y4HQjv#LEQ<UNI+GI>4+
z`(0CY<cYk&-S)^)NfY7_^PBZJe54X@eoUQ{{&BEvBAn|3J+DFmM4xUp0W9(x(V#x6
z=Q!T;uM3AMCHJE#2N5044iDeyHqjh8f9_JX`7a()-5i?E&xATfKJTtR@9JVMP*B}$
z$(u2VjBv0oX@EKWbJ*VNsc-DFG~4$alW7|?QK33&Cx80X*Glv_`m~So6#6?car8Mn
z+;I_n(##ZivoCF`H|@cD=zX&-@V@h0U{(HV(F+|N{TA^QYmFZcy_@UzMGcFh(si`r
zs^w!)?FI3>{mXqKB0`61R$q(7)Wp2hrKg%MFa64Cc$^??bl@aA{S$7#KRjX3uIv(`
zAN6gjN;m(SxAXjv_Y6n4{i4hAy=KbV(#C+J(IVCXvy>BVbJ|+5?2^tGq_yeBlfhsL
zh6wfz!v*4JLMTn)mPYxJR-zwjXhhi<eKY19Cs*VFKp3n`RHs&d*sZJYOmlT3@PyWV
z$N)@m$x3U}`dgS+Z;pVs>Y$j^?de`6viff>wZot=B`yp1$jZ`WAnLUp3SqEoKZ3=p
z*C>+&1du93hVH@W*3MS$QTpa}%E!gyhZC>0rsqfOlCRI(qZMLQzBj7X-PK7V{kXVB
zuec?QyzhJRx^8!}0<Ur+|F)*RE}d)k2f8b{p3y2bzR~Bo?jx;jOB4RPMRraq!taco
z$>kAgHEU9m(*oB|X?=^vE8u&CnuVwPl`cyG23l4ZdR=w(Iv*REY5U`QudlG?n_V7>
zKV;ut-`-Q+DOq^Wcc})r9_W5kb_;!n|J$=-&lm9kFeW_xl|o7`h12qkGp?Pn1%|_3
zZ8CbSyAE$&1qa!S5RTgWPCsu#iI%?&yJK%rD7om0GYZkR=_h5Iqtq6?TsJ(9Uhl7+
zXsjgiBywD%X_rUt8(24th?sUDrVB#_q$~c^&W(%v_T|EHjqJf^g?I$v{})kjH&l={
z9i^d-+j<EAr2muflXB^5e4BHP*kgU?f+1Dyd_)-M78y~!(<3M&2?EU?yo)2s`FFJ7
zU$E)~de3$EK;`g=h-&58;gJz;w3i@*ecYBq`>C8<@QZc$+tROJ@J0W?EfY7tGQDJ1
zZOEg()bdXV;lEA(%b))?`5!?4tIq!c{y#wXT;}vI5?`LYmrrzbGzRU<Ef;5CU|0m(
zzkCgF2aP?U6UEYLtzM_5yrdRBFA<Msp6Pz`dJY3L2%tB#{oYcLmewbWgOgLPXk0pt
zRj~i`H3Kegho-l~r%&tkOhU++5fLl6X=44(#PT4}@!H3uvzO68TUd$o()s`D<p1jF
z|CIbw0{6d5{uAJT+x|P$|E}(Tm;Fy?|4;mX0{maL{{j9#K*y06+g>d&OJC3%qv=c5
zJuFlAN}e^n{$hCx`4sWARqrGD7ow!=!h#?&Z?V#j!Dl9&Jnf#wX~b$B{Eptmz3B}(
zp)VP%c$On)xNV{2!n0KF?r;+e>Rweou;fhtXtbJa|K0JO&oZBQx!P9N7S_=cONXGx
z)j?C>8-Mxu?|L%+NK=Ot@%`WW6{K(^-R!>&Zj<+Os52wh7)D1>btg|Y(Dn;0Q97Qv
z4{g8YGVvHVeBaJCyOXyLcnQeJM~_h1?fLcLwO*rDFN#p&Sqc^^JF8X?sHM!^iscgY
zNykeh-}O*M(g}Cj(eIvCeLyJovLs(&qs`G}d^QSprz`ZFvut5PF>4w>Bvvh{qc&&#
z>@&6-&6PK~d%7RfzvyD>#gDI8^-0zvgcv9c0;D?j#aBt`@*6Euf>`gfr6On~5fM>c
zB$Ga+_AV2VAW{Gku9AoeGR&&OaO2pZG}Yd=Ou9BekbH6wR(rSbk@9ks!5gBb##Bh}
z131e{`EM%APIJgq22uB-Qp3BTW@0pd)CKvLhb>@8v03l%34kgNE1Qe<5DGQuX!hWe
zQ&azJI#Vu3@GB-(PQX$p(npJU=+C11k_6#XSt~ba1c3O#Vjjk7y^(vrj2Y@ES31th
zWoR^tSwc#oKDt@7LW$$xZXLdJz>pb5&J}&?bfud8c!g398<kh2&zCs3Qn9sHw4~ub
z@P&~oY?Db9+3*#iI{3e3E^`1aeeb>#X#V5c+@2jZd=<HJm3Gtuout=M@6#)JX5z0p
zaV21z(9@GBQiAd9ua`OR$e0uYX&)Cp23(FhQ{sqE9ui;szytZZJyRdb%S4tSyJ~{?
zeP;&BX0eeIm{y}Z+RZ~qK0AGP6q7W8#1S$q@;L=cvrFH^7F0n-k8w2NY(Vm_vf%O#
zb!JBvhaEqDP+%9ApgmH)w%Ka`Y4HQoh{V&}lO!TARRTt!@BzM1zv;)dFQhL`EKo8c
zLHC05GIYo(P|3_~qq4HG$s~6|NI&(_*o3d)`UXEZmBOm$;^bV?{8+|ApQ9!d>GfBL
ztPU&^2M*=ip=+(g&4oH1J0k-5_+zw`&dAa-2v0LS!>MMa)MbhCRXhlX@)VJ~zR5x4
zr|CTSwQ=DU_F@!$nHFv46i8AwlGMy2^C<c#(m{kLzI3(Mt*UGXPZ>Npc&0XmMSb2r
zW1N#5%iiqOLMy#ZQpaZ!>Q0XhC)w5#yz8oz-<ysAxp<#=#I{nIQ*%gY;{d)|Gds!1
z_07svf3LeO2LO6Viu-V>G`gN7Uoch^=i#-}yFw|CNFa%Lny`rN3%kkJX0nd?J(S%S
z_NJNdFfT*OZ-y-B)A!ji7bX3ZA<5D2_%`0!wv|Ezc^}wy^z{c2$j2>jv$G3Woh47b
z(i{f8MJM_Y-e)OABFx)SBfrh|61W{xu+e+Fx4=aaIlu}-QN30o7r@Mw)3ZRdrgDmw
zQXRqHRkReea396X!RyPaDlM=F-tb0ej0c-Xp<XfZfb^72iZ0zodrx;XnYJ&#0@==P
zRP`ke<Rx(z;~x(8=KOlrpy1Q>i6~^ixm(z+a28iJj~GEt?oe^QY;Na5nG%*I3f>s)
zO_tuz6WSb7Zerp#EC)|7h>I`ri~q18-=`df5gJstS$v`rrm+z8R`$KWak{^$U7Et`
zCiyxnoS4ZWwy=yaIdG-<;viX=inK9iH+D=eDce8eDnuphPfw(}*Kvz(b{;&AM=W{D
z9sYnmwr9#<Lcr_pQk4jP^~6ek#$58#8@dV180#^jNQ9tz>6+Knx=bp!yNTGPUVgy@
zgA1zj-;;L!fKw5Ke=^I2t61CF!r{P?^ZUl3W!KGrpVk)Or{W*5v9O-VFLf1A3!NaX
zG~gKCsgGBd|9*b<XVNH)5Hp6Gx7_J0NX2LwqnoTJ#^3Mvz-G|QM58KGI)SyVLiUKr
zgY)Lm4gub>`18cij=3FTMB<Q?!1tO_m4R(_k)T$BlGIPpB`R<Y@I4&cQTsdXBbN2E
z9JY}GVgoio6`eB+!bto0d$!dnEA_)e)wvQ_sC>hHFs&x;12&?}MGu9^QX|=s?A<Wy
zx6F-~ITQT@k(~h`v5t<&cRKu3;5~CimQ;l}>jnm)4i$vt_b55}qbS`;N|rtyxIyAV
zhUabBP!=3!zP;B1L*&)Hw3bFVg^G7pGYoP8n#Ly8>tA^4e*A89`#M(k?NXUi=+0bs
zcdfHmeR@6FxRF1@{B!hRkdg9qq_#3dr>3hw_$@Ktp4MkPcQ!`GyzhFBuJtT!Pb^2h
zC#1?d`xn9LHm4g5i!B$}z!=XQ_YFvQ6{OobggqX*rzB*l6VA5ma6Vzi&gU~MY&8-n
zb8%1^T94fQUE=8`*TWG5c+W=KmU#hX;O@sQwp*q@)IwF$A(n1X0Vv}Yi+Ng>s<$Mo
zG)SwJRe_*ESi^UJFG;;m2@LTBPv$GI<>@rxfQWvgr$$w}A3NCe4jP}eD+uV~-6#W1
z`8zzeHPd{WY<`PEdHWZ`q8eok{zNKj>&yR_`-)BPDWBX2XKQ^zL*I*qB+`n-YH&(s
zlR0C?Uf<)!aL7`l<XA#m<x`YC><-;JqNW60<;E3NQBo(i5a?Ej`FX8Ih4U3doRwTa
zS<L-#W!yTdBf@YkVk>QoLyQw2%8g4Eur7h_U2M3*L9rx#o68DI9<dReK|P;+z2>Fx
z-YL5%?epRib3Z$kzrGt`yjDH1ywi5`+dP<<xfP_8=yLw*m`XLEIg6ATA!I49o~?}a
zb~Jl5tc;E5Ks!p$a|2ZHhhE^vo#+?pNrW%dvuA*OV`O4>-N2jANI+g+ytSIJzmCqH
zMZZjip#i}u#7xp_CGV~R&rCaPRQFPeoaKSHmDkyes0e4GdMlDs5;>Vs;z5g%Vy4&n
zLjs40Pvp4MnZ^7cxstLS^9JWj6G~=vj2ehTMqVR1F>w-ic6&)fd8-b~SD>z;;OX$V
z@YXJ(*0%T9xUFtK!!6npqSko;@zKX_1_314j-V{oe&`@U5P3w%#>vp!YrIRvcxN(J
zOsp=lpizIu1i`>m*kD@Rl*K^Q2W!G0@%^-Nx6k2b*lNg9-!{#rEZ$c&+BvP1vI@{+
zZ=Nq>=G1flB{=hE$^-JJ_N4;^g7R03$7hRcX!cYMO|*6P1Q;o*iiGBWbUj(PxU;|h
zfXfU><yqw%4qwG=yPcgu$N7uokb&{FhsAjw^f?@LRnKcLQ|2G`VXLHYJ|ZYsdDZWp
zL%f7EJjHI2h8ySY3-cCm0ehDZ{QS9Irpj$JOy%#zWIrqVSu}uc<~ex$wKvKRGmL$n
zM1%#VAK%?a_UVthUGKcFo9?%u08fEdV}>!6`qp$9Iiqwk*eB5Y()n)r2qRs{&1OJ3
zFm|$}%h~blZJFxgw=;LJnrSBKb#Q!1+InLSYst6I?uufcGY-Eg#^NX=(|53+x?B&n
z3xM2yKzwz4=v&(Ct!ov0P=AvIcQo^K<f6btiUUQvaqX*DlN6Ufx}tn<Sf7}x5(L7w
z@Y0XA!sB$85*m0j0HGk7N*+;H)Nz)f_}Gg}q0RJ&Zd>bq^~U0UL}s`TOiL5>g{6Vk
zA2lk%EIdu;85`ivNP*3xh{{0hoj#nLpAQk0*LBWN{+J2#xAsHt9K?pd$x%njG*sb@
zvxFRyX#^%Qe1lh28bP-A#TEZr>+fJ*Gfl!_?bg`lFrUoI_Ij86$^lgROEVn#hf1<G
zV^S=|#*)Qhs<#7bUezqCn5v%6`1B`EqOp}(8V<p=n4$SJmG|xafuKfr&8C?T#j4K{
zI{RVSAV$gRY59kvi`%pu=gN@%E2-V_D;(+g%a$f5c>p@zT)#h})4(}9-zHrK6%}5d
zrBvV~ga59YtPQ@(NTPDlcx6p>AlTN0@vUD)9&}in3RkX?|KnKHN3uz(d30uy99Y<2
z4%o#B@~G_kwLpXtHkvtW@+_RQkzCHSwHJv1342&5C;}dst8Bz~z(=DEpGjb;_B#tD
z{&B&N02bD;P59kIklOT&T2YQ*8&!9~3{4LCeQrxkmu13eSj5OYB>c5lLmjMk%4DDS
zOGDMD&=^|2Yqxis>GrS??Si3#N@=2$gEW1*U<<J>B`yY^Ww?a*ynOjYxz0-aafN2A
zwdz7ub<3y_8G4}>a!RL*uCi{G>Fp1aT<5(q?f&V(v}v6zeVfIL!MHnjRw?(xyqduO
zr3E<a4k}{#=!yJ=vbTsiMapa}vvNU+b$I~e+v%q$Kc=1KY>WkAc9i=R=QM=VJ-c%F
z{wxKg8HukyvCK-Zl2<Kd{vLCsNEO#CXir)s^L_Yc1*xCrDAH*d;mSRWkNr&-JkOmn
zF*P=;!HM_gP>j@Bc{nOvJNbB!VD1Z8TAfT9|Nh>RwhS?!Kf_=mxAfpmngstOp{uHF
z&{GkQ(N{)P__JGXp2Fevh3D}p0>6!k9NMPZGbZ4RBz4B7xg?m*1s^qH!t=Kbi}?)&
zoURK)rQ^eQu1Z1|u?1X2>B0+&rwqk@9knOCb2}A&_3pfmu-hq#`=}n*@pquH(o}+?
zpLfVmnDoF%uD{E$$9DCijVtYUrq@l<8wG*5=|s3F$^FC0RX@JK8~29cz{RKQmQJJN
zxDZOYVKVQ@YYG@87O~}3-oNdV*g`KdYmrZVAT(Q@ihT6P1Cj~&O5;7>z6U9}+|K>-
z8c(rAwX{VY5tO_4`7W;uQhom09dh9iYe6If0+IKRPY>Y9-LC|I$lpC^VZ%pqJu#<b
zwW)X#d*jBv$RHSn+M-$uiHWnYl|^u`s5uLj;N0EalM05JHQxxow4mhThMA5+OAC@r
zy}Ceoq2AjP=Q@9)t3QxR_9!NS8nOINLjE01`F}<)_H6!Oe=Wr|0;q{Ubg)%^)|Ksv
zuHN!75Ws%xHtd1XwsZYB=s4+Dl{TeVkBb4kkjYnTbMp<lmNm=y`$#m%)j=H=dVDSd
zhxPVpu^6)BDTb=B!rZ#LfJ!cQBE;=)O!4PV9!M8agY|(ORpBL-a9uNOnq1y)cF_2A
zB48jjK<sud2^m;vZV-=mgBQH|3hz_pNf&VBZP{x>mKV@>ok}o$V*C_la-`<9dW8gc
zfjyr?Gesr#d2B#ZSF)x>={_w@;<6Jfi=m%S%$fbNts#IZsI!qJL$!}uQq6387CxK?
z8NmHQ3Y8dVZv)`IP;QXpD2SvCigpndL#?)O5G3&vq{iSgx~l6O+gWBMowk#wVfZvY
zb|WN?rj{g#MprxGE=_e2H{YumtoXQpcx(5#&Ps*sp%g}<MNmo_x?AQHVd*X8w$f-w
zy_eLKByLFL6tz4+s4OB4+q(|!0kEw7aRB18WxreZae{UDWE@@+R`$K5reSr5qfUJ_
z=EO8Bns7DakGr6e98UR~50z@pST~;eZn2M*>C0E#hww@+v*cfEuaZG184W_n2Ry;t
z5e<wKHjumgH}tEd8KlIX$Wyc*)ex2J88bQ&f|#Si_eBT>CcxGHbRA&HMkP{G%PcC%
z40i8*3XfLgHVR4_j3%^(9nw~ZRq7CozRbEmDnM9+6&(4GV?*a#)A?j2Sd5&-vhSbv
zx)$DQZP*k_ocTK!_0`Qugd`p*K5An80L@AT%e@4Te>f+a_h)&NXtVCOc+8=K21T;V
z>rI;tc8{Ol8t~Q229&Sc&PruBA5u|Wq7?8|fLtN1&Hl`!2HrVL1{C#RF--vl0&}&W
zOFAiz#0|z?qMxWv+J341Tpjz);Yg}PvBoVo&4WjLNEQ7~*~^aIosZU_Rn~31xJ@?n
zNFHJvOX@o7bm!(9_&k;Te1a#D(C^aZ8Qa+=j9(papU^{4{Zi9MjpSo8CCZ;YQU<$?
z!^e>}aAinc^My0K6iE2DZX?^f7`MmNdgw;D6GWpOmF9yG*JBge1Moz_#~#mM<xo}K
z>M5}`bTDR?3Ke#S?_E1Fl<Ga@wB;2zjw*I~FI<&0Ocm=@iP&LW*)awnh11@x#4K)}
zrFogdn<t*@8vt<2HYurNu7NxQOL;iKSedF+*Tf>%s&XYN7nYFf?cocb%j6gsK7Rd_
z6Brt4<{pl1F4#Gwe7GzjL_I?srb-$f9*#JfJ7S)L<P{8k*Y4R(WJkuEBTo7DnmlKi
zO&sc?MQ5;;mI>CO*s+q!3V*=T_CGvvs`YPyI1Z2uI*Gk8qi|{Rza+N*Gb6f{r!hU7
zOD?zTbRDVI`Dthd7Dl^AQY|JVT3qeebhle7=PIvlKUFFq<&#siMB8Q^r4$yiBFcRj
zPOLO|wyxf1*ZVQGf5zJJsI#pCC3k)jT3enq%oKmGY*d9uGyAUVBGvYL;B3Nb_3;lO
zAwyReuZ6J{JItYXB7^!AW}y$B3FM*GsGlF3RerPv64Wgkmly>pIB4=5tW0ZgP7RDT
zECSs}Snnp~tIXi?tK8FMk)qM;hhuR+n!C|9eIy^7NzdXfOQ{kIoLvj9{)qrETG9b+
zHUv%F7rbQZ`t~`~H4U#wW?8;t8e_t{WgyoVmD<tdH_e->|NJ3s;3|VitZYjM_;ZWr
zApK!#O|q<#1OKf_t->n(lMO6n4qFmjrJ$p^YX14nGeeUHF3qkN0uF5Xvk0swy2s2}
zcw^Xnjf#pD5E|g^IV^!vyOAYzZFa{mG+m7NQ?iqKne1=7H*1SaZY;@h^T$nDsypUm
zax)_Udu6^RG&g>dpbDB&4IkUTRdS!TRV(XMf`yUpGHu~7<~wfPVhTMI_|TO@-Ae5a
zA1fpN{oH5i$BH{|O3~o~y@`{hVhupWG+YE{M751O5Hz`|Y68~pa+{>RerTI=P}70y
zmT03I&v22w*h>ocMK+jO3^SdDChz~4eIKX;<pr|EpXGj+w*1|dDD9(qr%e{rs-G4J
zy=@fxy=|bQ7OP@#QIROd^tQpcQi1RLSlN!I!;=wjjzZ0s_Ft9_Tt=0R^VBszrYoat
z9cQZ6&Jf1R2>@QS0>`s=eNLwDri5CK_mboXETkeRBdT3~B2eRVRiJNoeBIKt_IbAo
zUcPcUfNy7N)?=>E{t{{mjCIU1c5uN<T9|u#>h_0x*+Cf_bN4EQ1U|PwT-y5#U&&}T
z4UNJ5fPHE$oMo97nnr`lGJ`*zvT&Z=j<OJ>RdnfScRNPzPF~p|v83vj<!duwX-8S`
zly2y#X`Qn)M{u&n`rERnezrAnTVa?a?mfvi<2SXj$BVLmaUTZ-kaf|93XBYfu04F%
zO&42>W|jT>+ug0;WrX^nDPuzy!HdRmFJm(f$cJ9wO5yN3J^3St9$nyOu^r?%`E(Rn
z81Js{82e9tyVN>!`Ekzud$;~IwQ(p?q@%0WxuJJaxyQnSgndH>HnCyctNb71=6)j0
zJ5!q-{z<_T13HR%vXw!A7nz6g5rsJdy1%@~VzWKb+V+60)aMM+AY+X8&5{`K7$+nl
zdu_YeGXtW1F#OFPOU==b7<*LiL;)W$9EXGllYw6AjoUB1(cIhH5u@Ac$dWOPg}9g_
zMD^A*_FP8BYJx2zZ#aj^u@EH7+tbSkKR8ISap_7LS%8%x!DYioV>(%U^@RgQ^SZ8l
zaE0iFsy;%zLg;HB(pqJ|>XTq>JP6+@bc*~9BlMZ~Sd3jjO5fra${9!OK6at^8GTTC
zF1k1B2%iz^dSpB7h;NKu7eX4dOn^iEt$2Pk5J@R|oUsz&UieE5q5D`t^zzNIYYC%+
zmmeoeu?`CLo~j=tcGP|}aQ@3e_0;|(IvRZ%t8k1W&;2qmB`kxh&e6CeEs#;%|2pC)
z&&(la0nMRaR@1=nw65;hekB~@BPC$!^`z#%yLpeNs{4Mm@p}?O7-KH<wD4ZxN#rjw
zq0jCAav4%$M3`?nBpi49HsrAAu_KQ7U?J6gBv5Wql%j9QnyOIqT(bj6)`rafh-n+Z
z=;m1n-%A!0aIu+6Iu=%(1`0dzP*p7|&K)G}8?b1sWybj5@*<XTKs+4%{9JU3thINR
zfde`O)I8i>IXf$tmDh&G;a?Vv&E`{BQP0iHHmlvk#`*cbt`Yz8fLtO1Nfx^Qx;jYX
z#f?JqG`fXFmC84(*4F!dG)#yGg3J9L&MzxNGk*tat!dT{hMG5U>8@^c!UVZc${d!Y
zKah>~s<D8?XDkh;0wEEPQ^=vk0uq1tu(xV8_c2sa6N9y2-e*YoO@q~QBQVa@pw*Zm
zGE`wVSj`tG-PgHr)l%WO;E)AI$!D$<T9^i3$)oCv=nF%pbFQFh;dIsfnZh2b&DXTA
zja+m1?ENQYW;#$FU1Se#pbG?*d^RCrKi4DS<UbzApdxD7V}32skFCW$)yt*V(JA8I
z1(yxEk~O8fAKm_Z6+R5HB3;P*Q@wm-6leF=P(8e9p;J_BDpllB2Jh<CF(nFq*Z{a^
z??|3K(}Z}E>qDd@!+`lfYFvky2V&_%*)*76Kc<4#$EYByCSMsDditVTxVW+FC|39j
zSz7XU4{dYFXg=QR?M`=$@4>FBFX$*@IK`x^GP3s<TX<wLTo{L@k4$;Y2@31LD5#bp
ztFC7XgZf6yt2qv`HO!4;OZU3t|GIaP%I8SKpABgfpk%5#swQF#7>J;VAdL@K+A8xi
z8TL;WD8k)b?^m}Fni4K){^p2y!V6|S?0lKZoQBs5k`GDO2_}bKFqB%|GppjDMgsYS
zss4InJ{t}CK71}ULW{5%cO05KkQ8DgJie)$l|O=-&(#6;%nz9(@a~+AhN5n-#ItrQ
z2sOyKTNLLt4MO9ueXdK^{MqfUTeM|!;DD(Oh0$-OpGl|mfc$WHSyy+EFp3%nhX&Ax
z<EBQtNgN+6b=_&5tlA?$B52!r(q3}#z4ZvL)RHn8YbQxsnpRk9Z4ejhR}Z86J5^9S
zYO>;@b(i`(-_d6FNxT(&7rEYpF@hX%cO}|p;&3Diu1Wp5#_7~VFBA~6Rw39jgeay0
z6c4Z>(}g=&4IeZ@m}WlPtsuR%BqN3!P#Ug^8M^bO{uTVKb3Euro2vj1xo2?YD|r{)
z;2KdEX8I`H(CXI8a)mxB?S30$(C%MD>xF6p1X^>r(9V+isZYtTFoxTFKO&-5+6uSr
z+i1t2yud%x_tAS2BviNVx(<ebJ{p4%ae!igGC`mg#b&lmRblC6B6``eUFoFn8-3YU
z9_NexXD{@>WjPb}Gc}j5{~<VY2>gzF)tzBOG8hD!R#zSiz5Ju$KfmH2ls`VKjpP7v
zr-O0mp2HzW`!?^Uc=%@=FGIJ#<cpqdow_%=&BsZ)@of<CTD{>hZHiSbjk7lPNHX=V
z$qCakmTfwusuz(dlkl0yPpK*`X7fNSv|X`$=RymL9~RmSbz7E0mTGnhL4o^1S{aC}
zhyl<d^11jSEKM{~Lv0c<z7Vnn;<BT@ZS>Qo1z{uF>laM0c=+gjiU>fx+ghlfl6QlH
zM-=N7qE39I7xS(|cR}4IAsi(|!!4wWkXECusTpNw#%hI8%YJrmJ;#wj0x@b%-u=na
znQl+N+#2715Z0K%38lI7Uw;#XpihMegt0#wE-2YZB8?+NXjr`i^Ipf*;=W8Zl2vhG
zsN)S4)a5)dU8JN41&816xwUg0Rzqab2!c0z>H4MOPN1}<c)K{bd!>AgjUNi(3)SMx
z82!z1CCGnr;F?g0@!>SH6iSZ&IvL_Rmvw6DgvIs5njts@5_8{>4ey_&u1}4ST#AW{
zy%ECGLii%JF3^-|9v0_B+!33jT!o1|*xAc+HJ3gt{P{CKN!DwmRy#8@89bxSBsAHX
zyNE)smnsX`?O_W76SnA}!8ozjJ5*w<1>sWr097q?NsgOg!ln`^bAC|7f21Z_%)Q==
zPp9gEIQn1FcEEfAFsA+eW^5tDbu@wpOh(z;&Yx3nInBtw%NT-%Ly%;Si<X<@s#<O5
zk=l43ALCd8XYnM|{?<E|H)ZnA%)RPPAfLqV$X%)$X`tIi{bt4ZW<i4RoA8O58NhA7
zQ9Nv}6}jW#>Ugilo7w_mY0?r9|7I^gm%frHpU*8PgCBY%#$UDOAS9F<V{p^EG6Pg#
zVUr>52<qqAK11J2(b)QIq+hiCixhlc*{3`~S`1SzjSn9Z^EZyUz-GWE=J7S?i~nPD
z(Zht<!}JeL@Q|PKWb7G0@`AI%Sf-=V8?8OvI*DoPbQgUi!Ivp$H~jx27Ah|YxdI%&
z0kpmtktWu@m_>sMk0Gy#(wk%gw9tei@h{X~!5M0PfB8%IMLvt?tUJX1$0dID9ufd&
z{89MzF~y6Y$S;1%4~fZJrAgyv*YRQBmTFx#F@=u{E&0<Xv-J$;{Qsy!;E~`~^;hYz
zgb`k0G4!|D9-`O=6b&>T3N(YQ#WOaU0*4bYpP8hh>08h5<TM&&mrx49OP~2#Tgyi8
zzsG9Rvsl<Di{X&_lI*(T83m5vIyyTgM?E&R`9d1hF;BM`l=ot0kNv_IDv0kd?Tv<<
zdg;^T6BX}2d3~)t5P)JrJe!iyUwFg;KTr!nn7B}feE_U&mo3zP7QQeCGelyNoWJT(
z1^pA>gY|;Jggii{y>MNHCKzXI!LF|CqfS9pD-C>1oC@$pYr3r+jyjVVV<@a*IJSCT
z%_VB@3>iba>2`_<%i4BGnRLps&4g!5r>L=_boxW7WDdOla1#)AFz8SXO)A(kq>R$!
zM+x#Dwrqe`CMC{f7y9zX$A%WZk#Bm6b!^@os0hm*;M+`qU=c<$z`u}<^7$RZN!)Hz
z@K$SaJ)gba@N8YKVHM|hIt%n~rrs$0=E6sLq^|JRFHA;zPM4E;NEzu6m2BEz2370I
zniop2a93?yX^{Q0ekr}{>sSb@W)uq){+7NqQ!1C&GFkNP6=2#Aoy^q(ruP955lFX5
z80dzc?taj2QpuX@X(9z)wp@BQlXZ$!+YO2*0jIkMz{aN1RB~(=4(GyqLsC=I$nSF$
z8}ihY&bD5jjsFb9BIoOUoVfRQL&A`~;5}9%Q9$~%U3&ctNn;vWEy>POP9=>hNTmwM
zS4Z_vk{1rc{y`GH<o<?)k6C;1@M_A=BMY<GCP_WX%DkSBWBI>E1(N%BKk4MyzAihS
zj7oReV|*Bt12$jfb45Zou#flH!E|>=H;|c2NEbiSNCS4*`NLM9JrwqT5E1%ZTkXuP
zHm!*`3KKAEirqY90`%1wA-UDc&@yLSY?D<}cORcwQ<t&C%TO{ys;0j|yyBqi(SQ?i
zw@<k50M0~<MVgcFHClP{)Br)0;cWbOnF3lN*SmB&d2*LoDP*k-_PGAwxIJ?7?T8VP
z_JWE#e!Ufg_uu*$YA%0R4eRXAe>;1n&d<i5q?2+TpY=Xonc<I5nEO@g<$(?>oV}4f
z!aW&WBW6>DS3zR>7H4zGq<o0!(W?mW5hjGG6uGoMdt^h(=7I@~Zne)&-UpW5e49GD
zBo<_9R7zqiivlFfRd!7mdW~qPLCv46>ShCeHwVgmVCOsP4<-p;wia5;1oy#37hBSS
zr{wHUJuREa>NBv!g;RYv#766bJBr7wwUF^V>)8;Bm?gSpaNhPCaTZ(bd$H#eedX3W
zBhBCYnvYz+LXT4<B~=1XE!P96Wj_2c&3Ij>wgCCr3j!qF?VIeo;hb0a$ZQs?P}D4@
zu$A<SSyI87g|H+CYZt=qI?e_axR+IZXZ{CjO1z>^QY8QmCW`BDdwbnruIA{=2*4oK
z%V=A0@FeCyIq;BwInDoO|IU1-;rIDx_fM5Z@)1GY)b>0`=gYm7RAzd*j(VyIMV*~b
z3Kq(2po>dvOtO9I$<q%YSl@B=kfaqa+zI40wg_m~>W*spcwa2p47aO~r6c{?8z^)4
zfsUfd44--Clt%(K6`0N+EvHCPE`%w74izF4OS{qyN#&-_y*qYDDnk`0RS<Hm6u(P_
zR;+{l!fXtu(CEn$zv-A@Qtw^AL+N`_a>O4Wk1}D|a_bEpNs1oS2|d0|`dy#P(WGu5
znx{k5xNsTru6(-Kkuh&E*Q%$ONpB+0N>9~MPd-7`Ah1TF`pBlitx@m6xwxuJz*+s}
z&vTHH_b>C;Hm?RI^}a~($<#t=GlX68ce*?Ixf$xB{Jk&5+qotVA;P-YVQRs!+GPg{
z;A1^6lWr54+Tsrx)CHVIWeiL>o5AYk3CK2DftKE<CZWM(0#*{B%$!+MCz~{fQ(GsQ
z$<YB{J<sh74KGMYUZ7BOJ>zIRgZpzn%gEx4A^1-{dXT?4u+EcCMMgI2-tu{_i7a7J
zJ{(7UlN9EPP*5@Bw^7R&-47&VUSPvn5GDnP8Q2toy#lH@KQ_T$si$~*+VDiW(t&wS
z3q3<FFH#G?lDoxX3CWaPspMezAXONMgk=}x+v0csyc>CWn~Q4Tap_jO*E+zmDC>{J
z_R`o)`&4IXdvt|4l;4(xSi;`Ix`%QfC*eU|LmK0jM{joTs?od$*Z;*Q-q>V$>cvE6
z#F7?#a`H0m#+?(PgNM^L=*chFX>e2hrDpG}GFMrtRL*k8+Tf~DR?WX_l*iYZThUZm
zRU;314p9^lrkKoFz#^0Hv+39@^1b#|5&zsz5mmC_^0Hs{OMHEKGw7Gvya(~}V}vXZ
zp_VS^`BhFfG4c7K^G$&^f1_t(@-9)hp*xWOI=||(vx@3xTboHL1!ht16j}RILs<X#
z{ug15bsGH%)0x&?6ee>1<J`~Iwxkdbh^G+ujK_3b?YEBNzsv9O?@=C#35KiOBU_sE
zE>wJFo`as}6i)Z=uK3#E?Q^-T!&E`|32?%2oNt}07%eW7-@K3o`1drkX?llCt$5w@
z4OY9s38*Cb1Ui8k1k$uXS!l|tGd?0b?bNS{S+T0zM2L8$ZD(eq3fvf40-Sm`lQeMQ
z9U_hRKwH@FB1YSr{hI(c+>gJnJpv~mk+(8xM1mWtdA7RYt<B|Id4BLNG|U<aw@?)y
zB*`X8Bj-6I02Et|K7G8bhl>3AbCtT`!G?Ph!Pb0`9f6upwANqbJ87voM#Sq_Nbi~P
zJ&{~S>Nxr2-%JJn3$o;xK$C4?o}s~G@5v|RaDMN^&B+vyZpVLSBN(_zOLwQaa2-9u
z!u!J83%Q>m9)D=03Dp{>F48^7Zkj%T+6`MBI9GV`*@94qq9XwKeEgXwS*pTHqT_!w
zs!8PC*kAEpNJY&5lT`c<)SG8@?hX8+7;h0lZ~!;zd&!?GYV_kNUNpqS7!J0DYy<y?
z)UR1^A5HiNW%w!uNDvuLExF)5W`|y7nSE$}U^q6F?t0zk3vHQ*HnSQvCgY%Wux(51
z-*$=Hs%L0<dNK~@VSFq`+>#`(^X{`FZwN?g>Zq!D5psDm+3*L}7Vz}cZQ87L?C67*
zX55D7Knk1(B=d{Vh<Ceim*L8UIV!<r5uZ(_#CW5|Lg?TFVK-|mIr-e3!|vxpg6+D_
z)@(Jcgt*OoFE0Y4UMI)v7PsQ2Hvig66$bj%a-IRdF#r4OKR8Y|!QX;4@8jr`3^%Ys
zFuq_#NM9g)2vFcbdkcWz;JyeC#){#hO2+`S)ZzJXA&mk?0C^mAo1wbpEJ>Axxn-~E
zWs3=rR6}3|aKwUI3VmM0dxL{RrLw<gJmv`%Y6|#eKA>fK537|fU<rksZ6n<#UVDZb
z>bB3W=DfCjm-0G<7#{R;kCR+Q!T?+x>c0)68I*x=U%2bWC-EUw=Vg+A)+FCSoU09*
ziv9XGE|5Iz7C`)iVnVA^b5G)IfOjbL;xukrBxD(na*u*zdYV*ep+}AcP{+rfo<&gm
zoI=s_HTS6lT#g#lBau+uAF;6%F=*p?xABwMytr)U*PLl0bTReNQGN8`LzkKG7B+%2
z^L80eGBi^p|J{~4lrh|M+S}!9KsBJ)T->lm-R&r}$EuBD(^wS%E^N|C*$CXjeW`qT
z$)gYixrJCzrG4-;+>I+`f6wyUNB<QG%Zq5cqmaSU1(-wC5j5}X6^D_AvsKIPefz#l
z>HzwDS2^S+1CkpLoAG=ov_L+86UE*eD-~+kkxDrq^H#Bus_2W#&OO%!vV$8dQyS7*
zE^Q&+&dnt!Ce;@-NqK_!V%0&*fuH7kA6x8hA%L2fLDtZggKHxAwp1#VwL!<iL3MNw
z$r1Lzn!q8rzaW=qMjoVZ<g>Pgt#dF==dS}WbBH}`VVe&*XT3V^xA>@<Yp2i7N8*W+
zWUTId7bN#ik>U&WVMnmjlo^?gCny+=+F6Fn>)(>V+5bxt*e|y9UlP28i*Q1K_DMnh
zhfm4wNq>>r9-J4Rd{}SrFUW(7nsKrD2#GCG4(tpXc_oAQ<h8+7B@#4Vv_cnr1XU9y
z$to7CYSBu8$igb@ZK4r>pA1EIh{d6@2BB`yG*ey8oJv)yj1fm?2*s;qEoNSg4pEE4
zFuUJO*jfuQa(G$hTWJWNCh0bTGaJCpkIO8r$e@kXx}&c;j)qYL4=Xr-P%M3S7GhCU
zI4$CC|0PmP(qN#L7u~@?`mtGHW1!ksXPLqImK|?*#O+vOKdyAcB+9Fo1ohM3Rcl9k
z67nxU+9T|90+H&GN|((kJ!23~kT>qXh)Xr`ri*N*rxL2elwZipH*!kftpYW6tdD<%
zjjQ{wT~<eOL|(M2(v@n1`tg|;Q6KOv33~Hkbw)Y3fJMrsd>rxA7anS1EDC8>3txr*
zr3DybLs7{SW-Yq_4jxTNoQB{NW*Y^XXW(k}M?vKBaE+O)>=b=)Eg)d;hiW$UwKAhh
zFs5{8vAN2=H+~M^iwuyj@d^%j-&ECu`NA$gHVlXM8JP8ZkCb2zdN7V26-Nr`H$E*e
zf>HBR2FFFM-&XiZITtn%;W7pN$&5;^Hnkk#nWC#c@v@=|;$C}YTbf^v36Uce>4O6-
zs=k(T2+wcBRG<Z%GUbKdwc}b?-A5QBSO;($03-6EMVoNBLPz{zW*i`?r<~`VCRHj)
zjkcK1#obCJX+aW~1C}m<8+%TXr)a<h_Wwvl%Q6w+pqe!X(u<2=<qvCpQgQeK4|b;^
z_)AEhgmxJpfb>ld$f>$)N<}C~yxSY`fxeqsuxcXa6-{=fPaC$pebbV>4wPvj1yXWS
zhW{uzjZjx-`>KZoTxs%uMzOWC70Snp;da{#`2!{daJxS>D5A&RUNTq0Rov;@!tl#9
z^J`jld<OY>vV_UMQ#}?-6tj4zCaR0eS{ZrJ*6pBa4%W(QmImnsucx}my1R<64~!Sa
zR@jr{*ks1fmfKjoFgM=j!^9F*NL04as9G~I{=%IK@OBMkB2k#TvU1v+(zesn%CmF_
z(G*T8w`eIhjGA_Cs3;6Dp-touzxZWAmGnBMz2ej@tw0u`2t%1QTQpx&R{-JU&l@vU
zE#m<v0NFDwgW%1;*!Q37)yvFPVf8-=!T5Dm=oOOSHB`x17WKQvo>tz2tJc?ioZ6Y`
z>k(;elLVd?Mg5Hja&0}^-;C4Ur6R_+Y}FSmO54Suh1#PZ70Dx_#$A45zeQ7LR~2my
zQnNdhK4)hry2L-cy1}dB*X1&@L-63!z80#2MFs5t3@N@OjjB9+Q4JE7kK6u$WeGj2
zT_02~Z+p=4ib3PeR3QS$KrsQPk@DT(a?S*w06S#AbJ1{G=oR3QXVNxltymH=!>H+V
zlu~Rjf8RKm-eS!BGVxhr9ab&d<4p0XS!1$Jk27JX!9^8%WWci}@Cgz|JNu9W*-xm2
z=M#TN#Zp@C)jrq%mF%TQfmUdf2QkYb6|6l<L;N0g<LUo|c0lel<bk)B)e_FG<%U6m
z0vn{H$Jcbk2AMRfFWour6LrOe{VaS~9}c_FpB8TZ`LcE;(EQGXA5~Vxd6?N?Q^k|U
zXEh=*#R_*QMj>w?CQ0wiR;}fGb0YqG`&eZVEZb`8jiAj2&grA-2TxzvOh<XM?k`$0
z`2ysZe^3_wzuMjcD2}HK^j)0b79hBV;O-vWA-KD{yAwQwkl^kFcXxMpmc`w5ad`Xx
zzE^c`-TPgw_olXbwnt9Q>F$|6zd5ISGIe-jWe@Mn`Rcw+pXt2*Fc(5975TY&h!fJD
zN6p5M+ReT*zhn)NZ^5>d!*xYP--hS`Fqc(e*hRoVgI6N}NyffIq7l{O3CP9$8(*J?
zV4}L_MLv<4J&V|*waATFiA5VYBUNE6`UY;aIX5u=rRxn3Z>`j;)}*xnMZvhm$~Y*u
z6N6}_Vl=8)vQ}-%*5wprCgvKZnn^?BN3gr?h*IDz#DXX__MPh0_{Jj;$mzY3Y5zjE
z08MJN%Khg6M005V`q+6l>mn$Cgv3FY076pM5t-tMR$0ek^zMty(cin`kvCxhzsoJR
zBY(Y43$w6L6F2X1W-3fH$bN#2%tXBl(-88cO|G$GjjsPzMH9Z%K}^SNo3qHAtsJ3G
z8PF7HJ<N85JK>SL_5x1G;+mCvuQ%s8i<a1KR~(Hq;b0iX8EdlPvCrziyuF12&7bd}
z8O|SE4!tscUkeh3NAV&D-|M1fGi>*>y(8^fupO5xL+5_-%z-hEqjx5sH{%M8lu<M(
zXZ0=q0^m9I$Zs)sr$%nIYYZqWk*s7*U3{^qVl$Uu;6N53y&Ib)u?;_j8YQDCh@)5d
zQZ-0q&u(J|!P-eYwx{v3gddBlZmD|2F|YvG1OL+NLPDy4f)#ZkPSxe`C67?}C+`Tp
z<D+vDB_X>FlrB!_TMslMA^n<b?CoS%v4{hK=z0bAi~G--pZ)&=WGk3<Jz)@^^a=by
zwUy^edMBzH1?QB}(7o=p%9-Do3GTigc5Efpuqs*Q5qJM(H==F-2B%>ZOOKRDUAJT$
z3+2jmFn{}l17yb*V#S!gcO?7g8;m(BpjcSQ@nSIgS?Jr+bdWnm$YRuRuBvU7f??va
zwcwno+(}CMaX`UqziEYKtFPvG6=vSZqY|U=Cqw@b5~kLKA4oKOoW~1avbddrQge9D
ztBN17pXzZ7vpUDX!{(R`APk6(e2XAKLP$Gx2TmKQ=BY{;U7RtrW=Yst9en4k;F+;k
z`YxxL=tb8+_o$p_I-d42`>Q{i*fgp*qVxpo#>?k^6?}T^Um!@}_8|zKg`Q<OFKIoN
zF%}JZc@a+CNFfPcb=z;)dGII=j;!kM4DG`skI8Sj-%yb80<#FQ_vp?3al+w`nBtZg
zLfDzS^IgTNPh?E8^y#Y}RUKoT|6R!BYZrJ@xHal#{C?vqE?7f0dI5Eoi$0=aE%sw0
zZcD>#c?T#Fj1!N#YCp{j#rc5>?@vbxNXIP{XmlaS)nxmpB6ncg<X~|hORSA+g?`T0
zoGUU*hquioa2OP`rf|xkAzKkH`|=A>8aA$a|BdxG<Jhcpt)0o`4R3~c0O!TC(8Y}a
z`-b<%rwJ5^Y0~~kE-p-lq-11LNqYrERCxINMo;vwDwx92E8VeQDuB%usEDW(Mq{1H
z3A?j*8Q9ROr_-)(M&p*CsBUdoyB&T0wg^$)N{!EPR;=av7`1M9e;W#Qo3m9^*0mfN
zOlyi84E`<);Se=7FxXr~5j7~u-y%W$j>Z)ywa8<|1CpwCa8q{kdEy8;jy#7pz@JeD
z-!oDUT^a<IzUV0=5Xy%yi<iO-qA?R;-ZpafEXDl7hDvX;RkG_;H_nhMcV#2Hk(Ey^
z*D`?W-p9vwm}5<qcYC0&HTLeXDYnfxvE_;01X!$p4T?HK-n>?5sNk0`WG{}85%yOo
zI4XBM>?Y|pMEM&;M)tR$pmb|jsKbf8Y=X<iu`2Y^*Q^_+IuSQiaUn1VO@udxsi#u)
z0B~wo>l4oRJ!vc$aoYP_FR7z|>bX+&S}%Rh(ebCkDF8r%qq#^#bY7W$@+-kWmOD?N
zLIE#6VUO27V`d@O83<klFQc#OJbUzCa9P*JqBkr-(?BVDXo)jT?xiY5F(x?jvMe@f
zh9L$$?DcG4Ga|&DN_$a9#_=oTjd^TYWF1+MZ!9|*H3<a(^ZA1W`GFYqN{*jW9W+!H
zoSMIpZqT|!yMy5)`K300E$~jy5WSZbIBw!7>?SeZYE{*r(wLShoeS|b+mG*G`%1kS
zlLDl1lr=O`I2smeYj;7^XOtxb+%&CfLw2Cb;lpXI<p>j6oV4hQR>=;#r(bHeYQD|b
z5Mx1lnxFdHFlxGvXM&72k0ctbeyAzYpqY7ZoEPI=QS$08W-@X7v{ntu6*BwE?eE{G
zZHgmXPsi{JAL15}x`tF4!bDYD)R(jvK?zTmF0}0l4&vUr=}Z(KwegCWrZ#PU+S<Cq
ze}fXSW;vH`&aPe80%y!&k&vK3+aqMeMxaXj-bfo9B@Dk2r%~^X#0&AaI{=hz=$noS
z?&_F8_R7`KrftA8iz@r!6IV(s(HfjWoy3}16Xn0ycJss2KINSqmVW}RmI?7=?P*oV
z%IIt-%ol3C2l;$q`ZFnwIMmSl6L9wUU}%ZHvh%V+2W6)RwDa!T9qaPwU6qj>kt}0E
zw`W{VdkwG5cYPr^z<@0XqI)xvM@!knNCi0}UOLtI?*C33EyCNKaZihf8x-pyD@#33
zKz`(Mz#_q;;PpIrlVpziVYR+kbV6_Ltw<QtmIkwSr8CNFdIh!q&_uv>cGmJ(tUBvv
z34Q5Wq9DsQl`TQW(~SVTqnlK%Jl^uvHlSv5FzCl5l&DhW1{Fi=DX)`BsN~lO$Fz|d
zc_zl%)2yAGiTYR^Wy@8I$x{rwQc>C*<AV)3A^l>WZH}{Bua|tNc~3669VJ$9b9qf+
zk&8W-0oJFP_6mh1&C%-&E?iGedL20^nsYV2&nid>7B&7!`!(7eJY8CrrXrFDKeErF
z4K@DG{^`Y}auFAD>pr~mggLafUtds$N&S6;;@&Wn74w(f{xcq?XXG#BP0_4en5$c$
zNl9U$Y>4>JVdR*BcFXygoQ{pq+_ZD7ZbIK%N$03s=kzR+D7iIqw6int5AW?GgqBL<
z^rRwZ*eIfS(i(nDpQZ<5v9}-~=@wc1S8a9kMV->4GksF>k7M@TrYe~Tp8*kAiL+*Q
zoXILrn7lRejsoPhW)uNmLO5<Z==$^i41hk}>%qI!7!oI#dGe-eq3ycue29V!UWRp^
ziq?aAj3Gk|Y1Sl<r$h`Plir0Sh>(kgB>$64ysm~5lT#&5HeUYgfUPAf!@IPoQ&Yi^
z{@EoQ%5>&cU+py)uT8KP7lf2Q@Rq?{&OY4%(6acGZ@qJe^A$*Ws*KDAJ#hQ3`3LQG
zEMt9SRvMQ}T#{iADW%&BGsr#V3eHgv{as4(I%}W+RJ2)+zL)j5-O|1Jj#9WiLGh15
zI!h}H_Ghm02PebZx3xIZ975Lfa-)s$+IwS>@!tLo@@%^fQS)pCR@xFBck?}Ng!SN5
z2|~o68)zb}&%Zb9h@cPPM1ye3k*wE|1<U*=;i`=|YwEsL8zo9#-I}6h0Qq)_qSWI<
z)W1w!S}bL<N0-~B*F+E^gnY0ZvX*3&kI`miftt)Nawg>oR3wQZWM(_&u%E1b$5KWa
z?xF5Lw}Q?fEvN2LM9Uy7r|Y@t-6gBJ0`Q<~DHPof_m<634`eVPsAwYsJ{yg>j3;rp
zoA%uTa+jNVxVtB^08zVOH&DxB5hd+s9;fru-uRVG1~#fpL0%tD`s}H@be83UpWmHq
zXV3kS|G?Zt;zX@=L=M*heVaG{(?xu&yMt};z~}IGS+wcVcKDdDr6q9(En^GoW}bCW
zG#~NVk7eiE&_dNC8>Y4jV^M2=Z$B*(gFV{jbWt4Si+jWUD}GJr_<n$EE;{R=+(HaW
z=DMd_7zI5qIR7aJd!*0NLvdRui*4YS@!R68tPDD@t;eFWdDj#=Yih<U5dKC~1-j+$
z^PGZ~$r5t{Hj>uC#!3JcuSWbtbAG;J&z<Q*a;fK_xnfwYigDAwoYD=cg4Fm`=O;?M
z$8Pr2D}h_#1uWY$n#lx&{MZrJwzh;sx2OE>l60|zSR!Ld@UCan71o+|F4I8UGZK~s
z{L%?lTm8lL^`CEpolx<&()ms`G`a)|f@cnKQ)NkE6B7*?p7jUcr%rBc%#Bq~NE+Qj
zjbf%&H>-Wt$Ug!;pRlGS6z;<WF~r!(7~%n%KiKLU#tk8;H-xaCvo@X{A%<Dv*7m#b
z=T>S!<rlK;<cOW;H-a%W0Z3k4sp{tYeYqIG`WD)Br|~nl%AV~{Z1??cSq2j(=n6;N
zKTXpcb=6NVf13I`za#uSFTcxkF)U7+$Z>w$6`73J(U^|?!miqp;Oghl+fvtfA)-}$
zBv5oFu-HS;cu^A}Ifb-AVsB%MAMMl-5&I>sxs31_J|t91m#u!v1l9?blJP8GXw0~8
zgz~HDO)#rlgFBVFvAK$?-?6ojyHj5$XwHzcA?}GGGyIR#%i#WEd}?b{{_reUlDQPb
zI-NBp)~qLC&k~>zvPl|1WWkYCO*ULz)Alc)D_PS59%SO5MiCzkB6u#M*1PiAAJiOA
zPNFSVcaYP^eHbhzYLHHs0S6vEON9`aCilTiCSweU#Q8J)<)kK2F=z8oGjQ-kQ%YXW
z?4ulzZJW!~VxwbD9$AjpOAgxp=1?c2j_|XZAAJ8fvp7Aot6YLkWbAo*0p78Cj!H@J
zXs|!KT;@P+HO++l(9W{b9I8~E<cjPt%aG-Hd~NsyJO(8FEsGtMELBf7mAx#;wp-3z
zb!_<rLZf4!Of#(x?f8zTcn*txlBMzA4e=o)656&2VuuQ<(AJ_zalyx!4eRY+EXWHf
z9dIXw6?Jw_>7Jh3#{j2iFBliK2-s=$40u`Mq~nJ{ZHU~&pWnvBl{~BPs^=XzX^m96
zRq8$?y4~F(Z-C?Apg4}reQ48cOTXzY2o{aZ;!ZSH@Q-SB;GhEQ0d{@syh9_YCB;c$
ze8$2vgC|_YCFy1Mm?DMjX>z&A79{TD@O2}4Nckv9#F7AzhSa#}m-2v|#z8Zc?!Q5W
z7OEJBBdeygQjF^szh9~AXi=Ka7LOdIGQnik17@;WE1Jjpl)b&QLBDLr4b9iK32uhu
zc$OkHbxWqc?4ann5t>!ws{z78SR6U!-;eO4h=1^fC(=~fRaUH%^}&DAvAqTG*-@^T
z#dv|RJH!ACoRay_ZKGPLGa3F4+10C1r=_d}<}Asgwp`{0v@2}%pB1$tf{1$KXEuL4
zOHe#|slVuAcBOK%EesAOof|v!jwqls-o^gq;!NY5{ZTnKwCXJ$okV}3ZLqqQu13Ky
z5w+<Q2lZFQC#>O`?(-5FN{e7kos<l3uW42mUqefge36ioPd1gUsax9etanKQ9LA(M
znfAiOOe39wbz?qmqh^`Ob5<!%5D=T+4E=*UXN@EMLLnerQn2m%QY)Ox66iQhvnn@Q
zp^-j_|GaL|kXImDC1X&!a6}&gze(s$KfloV%@dX-og3wjG%~rlH%KviX*;e+4N3$v
zFuk=%jqCNmZJq$_0tv?a6t<bH`$HA{om6dfvzLC;5dRqyV34k%gA%yr5j$C0rdrm@
zj_ScDa+PqokMr{f{DHWT!N+%vHOGmz(k3)bVtd=KuwPrwFMl2nG<uN4Q^dDfvKDt;
zQ4znf065O-Yir~f0dyf(yTJM8s;-iXO2_8BsueA$iWb?@3WS1{dWNwb&Y_k0iG{`^
z80W!nL*V*m%o;HdGY!zu;&=2nCj$~}NA{5b-04*LpXZCy-{o{l_n>#cH95J9Y)h6p
z3bbUOJX(Jo9~&3T<&`Usk$uzXmtA8L$y?ZU|718C{YtAm_(bhP=wrV=^D9H_L$X}|
zzzGt0I{1ey`Iu1CpX1Tm;g*5~44q*iqED!k)za+jOLO~2>Q{~fuSG`2*7fyE_E1Jg
zf7Q*J(hp3}1SljZJg4$99d9ST+}D*PEqGd+AOCr-sO*-0pB|QuGc&U?REQaD52Qum
z3Ixu^`kX`UE9xYo>Z15ad8YT-aGo!=p1uZ|#gGqtXn>gIYHe$MlHGeGiyHV)R`m5u
zO%sUC8GWOpHb>i1HkZnBCqYfkd5iNlDkI&{l<AAilKNcg1+_oe(&ZBVs8EbK?ao<m
zQ^Zya{E5@NS>vbkt2vqbxK5IAW^hV0%&bD?GL~f$#fAm8;mKAb5Y9i4?4jHFgPv`0
zyyQ3y%Z1;TnF!vmuovw6G9lLwegr02&jY%{{L0m!f{@_=IXrJS@=-*_fxS(gTE;>e
z=2otg-ZdzrviS=$j%&oVtEZ)<jD^<yrLu<R_D!MbPO*=SKn?(18Rr=cNHl6BuMNie
z7#|<Tse0yb5)=S0MXR|Li)=g$x?ByOY&U(Fd~^Uy9P1d~FE!DgPb65IHr}77A9d0?
zo|?33zrpjnq%IJCw^hf<%KqeV-XTb><L^I@Dn|Ol^HG$)WvBoFrnXB<tKOBymdS-$
z&4)Q~q9CKv*%tH;TX$X}^rcjEa^&9QGPRHmRGhE$0}Jahe2&`CIVtVZu|*(1hdz&E
zSwB!dYQ*k3eCynv;L23>N$#qZ&K}kY>?Q?>)j<`>*MM{$cjB<q>elBX1>Y?ZOA2eS
zotp9;bB{;WZ2&?_cC?Oe%SrwTdvppW`i^Ul6yvbN>?k57i~9s<&Y=T%)<y4o7YhPl
zw8_=Q?I;>T#v-4X5$t$fppMCn&I~{3y5?VZ3?<eiMpIhQ_4>Jx{4IsiiM4G_gt6)w
zMyFs|sk8XzskMZalSwsPP`e9Ibn0^=Kr~+p6MwwKK&UY)PN#eI<a-q!RC+}laZryM
zc2ygyvQ8WSW?ir4*~K9sp{N4rQfCAHI{;DjYrcq#x9UCO?nj>nhS!WZ#-wCV-3Y2{
zmoOXvj*9f|-WMODf$Qs9ei!fjf;E8A+WPltqwbaYodiTzGKbzYOOWgi7of4y19sA7
zM}M&{{xrXw-9EE2CTe}XbG(V-OF{oP0Q}sdULU!Glj5_4kU{4C`j+dR8_FZ9FTuQu
zmD%6YiVOVfXFWlH!Rj)G@A<5#E`OZ#jLV*&j06+mxZfh(a@u()=xp-L9St`_%7(59
z|0K4Cu<zLO=w2MB0xf;P_(qg^hS;j!%Ed-F-<waaEI;4(KrRbQ`(aqdzo?Zx`@mLr
z|J#tq81b_Q7jTpCHb+OjZb6Osxv@0?<kno*1v&>E?E<QLYmchG8je~Rt4p+gi)l)o
z^<~Imw{yCUwdY73NR-tzCpd0WS0^Zv<47FLg=#DvO_6w@t5s~N4_xHZ(MeZ#m(njK
zk<zlSJ}rYx0Ty?AcUtaB%5RSq*X#u%mb|;{-wJ4RH*15T10@aG_vxN#ORkhN6JERB
z0-vNBf#h=<THxFg)Gg&wb6K>%LE>~9-$<1{bd-9GxyhQ5LK=?*o0)^^KRpkyK47Q0
z(L>4ETj4BxxlfjXdg7P8s&3oCCaVMNUbj|j@PVm4TD(pYLoxzKTk~?7Bp2a0hzH=s
z>lBos5MY6Z;Kj3rsjggW?TC%zXt>rs<MnLAB?c;RJTTU!IFjrLc=Z7sOlGD7UWf{U
zqBEbBnICuo%C#d(VzQR%zduFg<2tfuzBcA7oW16QV2WiW)F%<VcxhHrrF143We&{Z
zyFdGXek-1)ME<KK9gM*;8Vtu_w{M48f*b_HJz7JQV?w?odcy4h9X*xF|3}pU*|3Gz
z=?H=TmgYB>cDPvo=8sRm*=lbtZMb|7^}3vc(nE=)i8gs6$a0LgGMt(g8?yQR<pt0W
zl3`Y)j@QYG5jdFBn=mkthw6tJt?9+`f!s@p_=ITZv&=wgIQV;bNkMadG{m@{x3Opr
z6}F7u)H9FQnmGDuzM~jel`}@@T_3;lA2xjO)Y&~em)*{y+!gNzF0Ae(YH-@kF<UBe
zpdJkp^-XMrAE#Ap_AY{%L`?pc=+|y(VZk$_l|F&^o}hqIP!qe6-s8Il&`#%TJ%!fm
znpvxau+Xyl{yXp;CfZUqA!1@n%^Sw5&IV{IRr2{|tn-?3D}@9<3yoNu<0f{ccOx@K
zyn<b6Q;JQ<^Od29SbE42tAjGaOhzJhD7jO};wk?HsOM<$`5PmcuwOCm8K_(!D+nb+
zlCQsp|JnARG7NI@*#4<=f(u6~_@EBK%g^al_rHM`ms+?5{IbuVM_e9RALLG!V0fA@
zr*Oc*Hz5n_D~icEa+Z%<>m(1vt~<YFuKD|<Qbmzxi3?weLjzE<LLeinFw@*U++*4i
zonb#xrf!&e-nY70xXA=)Q8_YmbMMd1>kmn#Lrwv8baZWWFzhs8I5`B#@z|pM8$q#1
zQ@)f7SL+x-IPq7AIut{9u&ZuF24#(Xfzg7DAcR&eoBBc)`X{w|Lexc1y#vUd3=o;e
zWe+ibAv==G{Bv44d<K6E({IW6QyeFU>eBBzy^rpBO3<4EMx0kOQO{rfs#7I#>ZTDU
znF-R=KF^^Y3<euTAAMUzb(#2Ha3oEqs*1qDDkHu|!}g*Lo*L!8swrst^2#AMA8uF2
zXRdmqNFFa86)v<`f`AyDNckw}b3}j#{@DT?n&nJ<mrya!6&3q6Tqu7TRcG&xkW*Q*
zQDqM0&~97Z;W%8j3#b^kt;R1%^8pY=bPy62V9j3uXMsYeA4HI*aPw>Jq%3K=Iqffq
zKS%-E>svHSG|tzv8C*Ja2>@18nJ^K_TwKGl(I>i|%fK^5N7iQ6Oe8{ZgJ_ZsI!d$N
znSuv5VUS8NYksA8$B9#<Du=zp?7xArsiC0(70m~nDKJ<6SqzU{Grgkk94Uc*bH(ge
z;u&9t+dLxdbZudeUYm^V>PP;r^RosI^b{MEg?*pge)F@lvqQ&ILJY}b2#y{gIIP(?
zHt}{~Ihn$9-o}oEqK0YJU}o}BCQ@+t49^H{-qJ#8(BI(OpsLu9V{P>dJG)!8e&1<^
zsB3m@BDYgniCe}^#p~sxv2?_hB1J7v8Y(WY@Covo?ubg}V9?FJs6LQ-!{kj#5ZBpP
zCBwduP_t4yvxqicUxq4dR*FvS&=djiZyZhh7koaRsKp|P+Kuf~`!|d(dr>*>)Y;pE
zzbfsNu*<yRt$=XpIA9qyi^w<aO87UG?btZew1d)}&dbmEF&3@);;i}O+^fUSd{1*{
z>Hu1}l-<hs3i<)ou9kN-ip4Ib_Sv2$)e(s@6U8PMX{_0N&BhxJHJli@ltGmE*4CtV
z+GvD|Bp(RU(SPKYRZtcNOQo+8gj4998Sjixo*##|25)Z8;FjQgjjb8mf;x~}CWaA&
zSfq<IiROnC904A_p`g-oRucYgR*psRv%bE)%<HJx>EHIXbD}J!8vY2W=tPfV{u(ni
z1ExPUy@%p2)AK^db#4TTBv*v#x>71ATz!!Rh_UGB<%CuTZmW}~3z?b3<;K2Z3>>t{
zDMfNxNyJbYZ_*L&dNV%bUf0qpOSIf6hSdEadJCJ;AnMhO*;ooli3`t=Q<!2lebG)5
zA51jWD7LjBp`{`yLCHnf{BIF5n=z<_Fj;0xlhB9AbQ3!2Xw{zd#ukO`h~YgKLD>NS
zAZq^S8v!w=4#*z~Ld2OsbemSX`ZvGac7kEr=2ZZPN9T9YNvjpqaPml6HjS{sm0557
zvO51Y^C6^PR(@hccK4u1O0(DXOsMgpC1|vUS`P1^<vt-rhPIj?yH(*>Qp;~H^_7R|
zHscC|Y69_f?ERf1fo)8Y|I~KKJ3|V~V3BDM4qu1+_Z0v4)R~TMiDxXL+-HDjC2L@!
zbBygcDf5;drGfq4cp0<AOHQorY(_x!Hsvv|@f}P9C-om_NjL`1^bnD$)9FYIC^f$P
z791aI4Z?9|?CtZ9?40@{1E3V=2MQP*QaMRqi`5YdSZxdU)}sA*(NC10NuIDZ_=EHz
z^oX*rVl`33pl`{R8q)oDPN?Imc?=U)UUDv@rwH_~wi%^&Y(84q!Mwt&f3gKi^8)j)
znF2}^47SiV=?d|>e*yn!RmoOFpG}pj036~1171%!Y8GBpXpzY>9Qb8;0ZK~5qLXae
zhuug16A_*O7AqVY+9n-)c6wh8dRe+#0*OJUa6J-$O(DeG{9#YLY`BqX0xp@;42RnI
zOBm!hPYgA_j~btfrHMa%M2}|!DFXs5(flahE){(wBdhs89ergSg)5G~l&H;EI2A+&
zMl2qV;8Tnlw1IzOQME1Z1oBcV_sS^}g>EaqUDQJX+^$kA?ADa^qfH7YxcK#B62p&o
zJH<Vk!jMqEF72uq*_NIV#?0$z+4mOG1mXkIJaod?rO_bd7q9(M&b($$F08svV&6K5
zq3y#)(V+jUg1x(c-$(z6K_sgQbrpL-GIOZRk=;WFRE6e(LLDX+2U27L8%8@^{Rc__
zSxlEHFNj{LAx%Yu?bPkl!a|>7vbc6`($~E5$i!y-An|k=-dfV~hsf{KGzE1T7w89@
zP7+0)vR@n^`bDOvG39JGnzO&S{Zp-Au$ie?lD1%+RguCz1I1@7ALFqjRI|D^Olv(P
zH3E5XF!*Vjr@$OhVOi=Wk&tm#@83#NB!_^%aqhDDwt>_N<yyHMgj%xA>sGW|_>B&j
zD&+lLx)we{#(fifI*R{+a#m(NlX4HUY%<N?3MA4fb8cERzd)eUMOi>z{-0sraTsU|
z*H^ry7C)5?YdX%1fizK&^jiU2mbLQ=w*%WzIK;c}q1#~HG-ezFp#JkyRBS9!E-ZZV
z6}18veOD?yZ5uCDnc*Asw385H%(Czgo0aME9qnPfcML$#_HT*C`Qqf(IJ;kW?gXe4
z5q%=MN~adT*ghpBN|u@8BWl}ws3+EN$W6o#V<SLM!Z~o<A!T)ra_%E=ZxP&RYS;qQ
zG;E9HN=x05`PFJLCmMOdUn!I*`GN%)N9eKHQqs6`Rw5YsE?o)b7Qws5ecPOg3I+Wq
zQ{otiaDFS?m5hn93F=(w#6c4l$uwp4wD;Y&ZNQMQaI*OH7y~GO+Oj&1`#6cU4h7NN
z)>T0FPPD!}ngS1yYpF#COs#R-9Pu3;JKq5yd$(<X)aY-nG^Xm?+}(^)ZB+<(iQi6j
zm8lyc3~y_)?vGQjP))Kg<xmIsk#GZ;SZX{?`*K?w6LgPD>oL1m=7^y<Y&ao=2YHAt
zVq=PEHe8x2ap$>II5gfw6d{Mfd;l<UU_$1zAD;W+$M$ti?JB5<a_;g#IO+6kWGH;V
zmM&d7icHfQ@E}kl<>b9XZNAdnV@3p)gmyUj^~H`Q)dd9FCnfN)!;jKSnkO8SrL#?M
zl@iU@0PI&#=d?Gqp<{O-F8i$NoEk5y)iHr}d^0caD2(ddn_yT{Y_=`^WdXS}`G_b?
zIboLSoIepW1S=3x6;T=izcd}vSB5x{5)!!G<3tQ{HOFf0T;~?;MWQN-VS?)_*B6bu
z4YkuPYzA=0#@Z^xu)JGDkpM`vRM*$of<H~Xy|qVAs2(55L6PISO;ED7o(O&#59P1K
z#6h$5ocl=Tg_uEY#UFFOI<%jN$MJ9MRSEpR+Pmg^r9b}otm}JSN8VKAB9m)J@i}C&
z{$o%@8F6r3%Hi3W>)w3xNDds;nLTk(zuEL|Yuf}r2eZB1@If%oSkj)Wg2TQuKSOoZ
zjM{xham7SK)!bk8YEBSB8!!`iLd3umH?QWvx=3jG`c!K+)R{TK^#CvUS7X7BQ+=p&
zL0gBI7{qUQoiN-hrFbmCClP({THp_@{L1v26`8kST*qf;Fih176N{^m_sZ7?FSW5O
z`6qQ^dQ*NRob5>Zq~;C0K6B=Qu6C{9d+eD|$S(39@UHfXH(=Pfnu4;F$()<`{M50@
z*OQO8yR6!d&u%(-kgKF(V`jR*u9|oB3>;azs@yeEQw-Om%q3W~MwTs)!L81bV-2EN
zFKYfXFhr3B3Auyih0|#-$xxwDEnxe;{vY8l$vVd<clHe51*O!@2QK~Qoa<tGn!Rs-
z$i-WvE(XS8V~1mu9M)=i`GyWUC>aJ}ctsoiOuH*UFv#^_QUMTvrXn&h=`;Rw`X>%;
z0A2F(ksi!`5>+o$me-gp*W*4NaHa_SHgg`VT9}7A$tc4eP30Gq9Qr%cdu@8{cfla`
z>#q}|xmc@KTVVu%tjD=&rpY&K6j#^HS$+XiS+XvOR*)W1VvT0qf=f}6JL$)VBy+@l
zOe;*hy)@Ay$>f>v{w-v8Z1yktCjfb;OBk0Nx6U@8fasrz=A;k2f;rwTk!$U#LiLQ~
z>7xGy(>5p#IteA~aoB?)J~ykD>nw`@n!x5F|K*FjHv3Q!8o0-+i-AbPh#JA20KyhV
z?<kWL*Az$GJ`YWzXRj_;?13{?V=%i<^1X=0ocV|uqD3*y$@?#l9-3BB)haneQWC;{
z&rSVU!2zNyN-ph&5zUsy_}5Sno&vG=4*u%J9MQ&{<IRGNgIw9Uh4&8B<>n5>(2YP!
zMqudIHF|6wc!4Pv6aclywU~+&29=9vRqs{gwZK#;LY}~PbR$5PMtRb~E$U`ZkR?72
zixD9F>sR?_8i=b={M>=hI*wK^!7@*P6psDl9$aP&5<5R%9wUD|41T8w1{Zu7oIKP6
zGz)<F5Q2CR(G#@%aVfnDS1&kI;zbX%Bu)8|*PA{4O}P?dd#;mx{hG9o(C`v)G(WBf
z!sLxl{iKxn)5bAjqt^6Yq+v+YM-;BcckP9+2F_@(qpnp2*avO^*n8gL7OrDfxI=g>
zDBXB$^5lJZcq|fdehCMfIIJiSyi13WB8%5G>)pCUAoX)PS*-9Tp266|++z(3kxtmk
z`|;{yt@rx-O^zWOJA3!tqjM`OTCzBA#)^Yr?`sn!BU!c~rTv4+5uOm^XHAF_w2|Tz
zOI3!39X{^gX8hpkY1YnYNTW<#keVFWn|}sA2#DbsL@rxnOug?+Jxo>l{*vMty_tiS
z`cSL9ma&~J=(}~-_0~5fOhfJnkv5{&;<6WvK$4Q(tC0QkhP6bDY82*&I0Y?DPQ(BP
z03%j1c$#0+!C7?%=%?09OG|*w=Q0Ido%hSzX`!@>-*xMNpCtE>9K?D}MHhZ?3P4Ks
zDxDm1cZjwG;6N5!Too|J9E*S|AUulgLl-l7ye>X<{>w9|ICWK6{tV5TC!}yqh`RAv
zB0~-^+vdLOiH>9Pk|A9Jrh*VCGd_JQV#t^zmvtc9hpA{W=lqk-%iZPsQ#YO4v1l1I
zl1kJU8Wn<Bxh?ti9rum&>$JSXw=b@Kr#i@)+1Rd1VL>#ZG~LMbNjb%^3@nf~8@0Ag
zI&^sNB%W56W2Fbon>$I8q40!hW>#Nt+gtIYSE0wm)v8I!&*pM*!Q`iir<C4x`Amc+
z{Crxs<)rnXN)ewS<nOc9wzUr323CxV^^N)ctT?s%@I9=dg~IcS+6=QiVWQOi1PNO8
zLCxn=o0saTZoG~Jsa*9Lg^)LCbbw>cU_jK64WN6$_MyNJQ&1jK11og_uTL#$$!b<j
z*<-qPO#Yr5CxJj0ONpOtw;=y2RhNx#zbi>5Fk5<dlscU*UmTf~K5P7b50JTNBAM%Y
ziSg>8>i(?Q4j(6+dTGC{M(aH$4*4I2Zu+N1*GTc*VejhV)r~FMt)su#gnOSOr8b#Y
zlEhoBYYImGd_%wCzTxJBVU*i<UiNu;SB<n0NMM58uO=c(inzn=RadBH_;TnrY6BON
zQ_9VCNX#ueAiWU-z!cnu2v&{E<Z|6yhkr)wo_r&^xCJ$hynDJ)f1z{X+f0nL?ex3-
zqSeAD6pPFu{LBlw-FjY>SlbMK4x(>n4oS5Au5%UoOjY?r#@H8)=me8o8T3f?5To_#
z>)P-YLEtLZ@I&@T`kH5CEYODF+n$G~yxjg`hadKRn6oLI6Y*zy6W2~4HwI#eHrzV8
z_J`<mn4n9zHN6jhM9m@3_~kD+L7E=uTi7nJ#RfF`4NFryZ!{VOB>|7r%O{&cP=1jJ
zSObn&$&OpW&jb6m|1=G~%Hh51KVOuhiJNN;$+y-KbOk7doz3}NCm(mui=p)R-#g|u
zo*%<5j}c-v0-q$#N{8NXMaDMjJ1^xI&<(nN3>R8vJ?0~z-W?%1pS_5T<=!Nd>fLug
z6B3@(*x09-qWj<7;Tg_X8r;u63kSYF*g7r+wuPBn@)19g7v5)PjzlqQLYGx;cs;PA
zcig0-hY6Faj4t|lVgLFN;n?DGHU>;Q5fb7Ztgt)3eh9>q<!Rm!xqM1m{j%6De5Le`
z+hf0eEu7`E9jxo9XRz|dC^ee-z<}4qFr<(rbeC>Ryl03jPN5D8^uHU)9AYM6+ql>f
ze!I@i_IH8-XyD+UuD@%xsy7iWX^`;U&W+FlysXX+3<A#Y$6_cC94qaFz$fT0OHl1E
z$A2vEU-EYLT*6>OrRd|{AC7H9HC5G^Mc+NM1a2>a10UGIvds@;&u^&o+Z5c7J;F^#
z9wc7Rp+Js5l(;G8uh=1wS<zR{z;}6ObCaKaU+)RyverRf6DuLrH@!z1xdJb5k4+9j
z&ET&ef*N<WY?&JcA3;gBQ;qfYU9@(aol&HE<)wV{D(z*3XPn8>TlZbQYc(Fp=WUEX
z8`=~}-=P2>Vi2;M{4RW}LVe#KY%NLr)+uQ8Op5z6vqr8=nz}sS9*)UxES+|+^13JF
zBC;wDU#=3DxA>#yfEu)KdoQ_;DD;yrLxhIjUi(Gf=SU&kUF%lMk3i&zbrj0z*D2wr
zUSHFpF4h;w%5dXlWxi?EaN9X*XdwN;>8@2l>48ZPw^LU8{sV5+Uk7mK^<-<HZ_~{f
zLGERuCEd8=`_lvWy7%#!VOQ;0Tv%`RxsL0}@R8WWBqz){cVi-ASg+g7Lm4)}!1`%H
zX`?-@l`o>0YMHp@DbumNZgA(>HI~icayPuRA-YD6)ae!*I>f>SnJ<<dA7x7LUhhr8
zf8y?z{VuMBIUJ$$Lhn^@Xeise1{1I;z@AePU7;>?GXb()x$n`}Djsl^vOE^Lxiv+X
z&GEOpbH%Lbbv=(^WR@gh5bD|=kv`Gf@Rwaatyu{4JwFOwtkQp(pSz12!0o}}|11=e
zN|fzEeJ{45W_fvhz={5Ps=360{@$~bTbAypI_H{@{66!zUkIczxEs8Hc)J8#<qa`A
zx?JD0X#zMN`ll|kVF9OpZVNks_t_VEJ5%pt4cwh~L+@_KO|BE4{2H(TLLM8VQJzbF
zmv58jC!(Q8$DP~F=bcg6e0`>aamc!zmxrZ8_nr5X5j^ktgu<Zr)GA3R5$D&?^-<>6
z)A!EjKGL|rb$86L>@<?MDIR0^PxR8-#NA`UZC8^Ddi=f(E#SH*!xuz)4b$tv+^)CR
zOoYJHuY-q!*pS|A$vOiv;`#aYk^2rbI7Ag>+^{>#*C#P~DQ#E6<~O(%a0R^UB}MOi
z?YIb>@+N;VGV{<k9vrZsYyUv>x|(W&BNa3jFZEp%*Xyc89RVx><|vPL6ev^OR#e*m
z{Wh_Z^LV-^1{8k&Vpv1$(^>l1&uj|31h5n-pE<teyOXvxs66l+yv91d;em#}EWPLm
zeY!%@9Mgar>MCi0D~DaICM^(n>bgenf_AcU9T|IXnY|))48-VaVAI#XztioG-dJmI
zU|YYV+ssUF3i@~f$<Y}!-vAvuYL5PNE+QyxsCCWqMw2C%i(H}8mce)(@S$%`l(lbP
zFGP^Og?a|~-^m3&u?$vqdM8eu8bB<VF_O@p>9w_XG6jVyluCGwp@sd|Y<{LHA2a)x
zi=;-^GS62f(5m`C^DTJeMgKh0Z(A;c;dDrovX|V2)nK?Kj`Ur8f#m)^PN=aG$><N?
z=kr5(rnIdzqCB2A`t#|#&6}y$qa9NC?1zuss(4=cZ}G^2;GK)BCed%8tu9zkiC^_M
z#E!B4<(IdbW276;J!WdnaL(6>$$@@lm)M&j%^lEo(QV+cPYc)`J#&HY(>so!xZ!d8
zRN9luW`EP#AYIH?z~(l4=`a!#i#C;h&-b86<%i>k*qx0lVJ2E{?=yR;K0H$YBfKav
z0N@-cS_5!jSf15ve)E2H_x9Q<)#b9ESiIE!QgM^2Non2kI|Xm-J}qP8!jmsEW(hLK
zxn(I9(~-VGUBFT(%z{%jOcf0J=5N8`MUq*E1eE%U7#`t08{e|CW@WFQt2FGBRS)6)
z$nuU&FMEgLe&WnQ^Y$#90W+M4w>!_Fcaw$Oz*mr&C~uzD4RDP4htT}N`)<XT`fkQc
zbi|E-JHbwH1@J)WN9Nl_oJlR>w+v6iPB7k6ou&|%hC#*iD&Fi}7)?Om*7SQCPp59^
zWr6bVR;HZi7%As7(^lcfI^+v|Jfxwwn^K3q?5)+IEU)dU!Szl$9FKaxuixGt(lwFB
zcg#;xbY(!~E~XOBw3Yr0`gi?x!9o}F1Q&&lT`#+(hK6ssp3x*H62FESSv1Nxcev;h
zZL%sNs(9D^jr<cmS~tTEvLAJB1_lS4)^(oC_vNOR0u`F`cjLeF#f?9*+&r$}W!w1r
z`tNM;b%LL41XR%hdJk<IUAMQ$%;nHo0b7q30q<BLc>iuHKk>S*cEc~Xew~Q5-vc%E
zNU0Mq-jeU90>$3`I9AShuLtg&I=*i-sYPwPE!{L#Wd_^>eM!D1ct0Y%&3)|2Zr2HT
z`vfn18+jW>WAIEI7ua?Af*gk!SX7BD@bUJ2mmfX*tqfT8awBdx78uZVe{~}4-SF~Y
zDZKo;`dq^})$aTDn3vuDbol5qa<#NBL(<E=@oGJH@w&^OEu$;g!y-QO(l-MNjNA{7
zxjmINxiWI`4|8V0Z*P-)Sogi~f11nA(tVp(RZ<W>p(6GL&sTBdJ4ihO1zb<KdNGBF
zjNk5g-i~7KW4f+GVb=Gn9l)hqx<t{z!Y0nB&E3YtF*hH8@_~xlh?`hW@qKhgsQhyS
zl;xN7yzLXYKL)&d!4R8R$o&|n@WF(glk@J5RR7}B3y8{---X}DH#$2l8fofQQLl1M
z`Fq{fGvqc~mr;K^kZ6W`Ipx~zZl%cR5Ih0)$C5&i#%#i@m7KRIl{P?owIezXLhP<R
z!&jo4jesl2@my^^5y6}i_-(NpR2-GGA<%WDUp$Iwdu2B*n^ZNGmapNds{-EQ7Jgdp
zm8CJuTkIUBYcd5syWW-(LyO4B$bbo%H*8&21bS@uK`^|%6xv&W^4R3^=)m;miQ9vO
zuoV9u<`QHs_0WDPmOpZV3Jy<=VpKGGDv#+`Q*U10+f7k{Z}1PO$%{z^I)6Se7FQ5v
zHcZrKUX0VaxjGeJOio0pXRol0S3dMj5tq{23q38GaoD0`i=R(pD<PVYZ`L(mnH{<8
zpves@wJuin%xhf$BLYVDoCyBm!x$u(@Gf68{dx^=DNd$Q%F*!`FEStQs5NZnw_`Lp
z={oZl9Y6Iykl5CEU8Erv5&`^hTBAdCe(^Lhr-UIKmVqhx{qx^uykj6#!QaCWOFD)#
z*c6`y!2a5&Kg&xoApbKi<e&$+N-_32ffo79#0BarMN`ULGjtG?p)@-$h51i;sBcEH
zDN|Ph9iRMI_eWvBQY4#vmynpTs?RZc>q0cc4~Lp!p)pb(p3aStrgiaii#`bZI7Wlr
z#+uA#zV%QalEteC@u`{I9WMlQy+gQ;hHlim8U@=I_%p`|0=7&!JGk*7C5R8SS=rE}
zaHJC3Vzf~L#(6|S?bizj^Selpt`Cl0v$FmD?U~uI^JOc7bn*a&IP$ue5e_b%rcdHi
z&h3eCt73`RI2P{<TQqG}Dl~f-G>L$cr5N%+YlOzx<5)yjGdLie2^ZsrN2c{4+w1oi
zf$p1>Xb3Mm-26v;)+kE)CJPDsg}DqvQ60Vv+eBtjkEGF!+=j*pVrGa0m5DRpz`?<V
zg@rxpxsjcJK8*T;T;bB|@;OEHl0G^mgtqf<5OXxe=#2nAKw#>!o~^-85rur51|QxJ
zDpV96Lh|IQ%4$K-IYC><kOH(?tobEmiLb(A67Xx-e60<T1Nh<8L<G~B6PX%)Jpi}q
zE#5N}ebn#oo%wWWq>Ry~HHL%B0=J2bPhI515le}P)zW6m_GNq*kOhU*jfc}uYD>G8
zCK>@5?bKz7ztv0FmlK33)Q|J?yo~CfW9`_6lun3XNN6w&K;t)&pa2=$#4*M%WRWYk
zy`R|yFAl78fB*AtL^Ly<w^hM5O<5KqDjT=v9a+^!76H=pwgC$rp6*>?<GrB8Ar9&_
zK~JlHBCV6?+%%c~@my0#K@v#w{l|U%KhFHGyxjlxfB&zf{9FG2*jN4^_WXY;@_$d)
z|D&t?-xK+NQGEA}!yj>eF=0XKg*4u3@9$S$`o-vv^uuG24gFH0l>`ZO!xefhzo}jS
zwSg^G7xFG<JDMm6^6lfQ>gr!>3Xu9-V?{znzG%DX)U#z3n3}5U8u`~!QbOw@2&wOy
zzt@c>1JRHA4C!6}3Sj8Rim0soCz9d+w_>m9e|(>wc&XitMB9XX`Wzr5p(tJ{Y83MS
E06v>uYXATM

literal 0
HcmV?d00001

diff --git a/doc/assistant/menu.png b/doc/assistant/menu.png
new file mode 100644
index 0000000000000000000000000000000000000000..29a7c9d0f842a7b6fc58d571b5caefd8f8ac8c64
GIT binary patch
literal 22921
zcmaI81ymecqApwz+(U4;;I6?nNN^7jAV_d`cXtWy?ry;$xVyUrclW<J=gxa`X72mf
zq8F^DiV|w?{b>iw$%rAs;lKd^fG8m@q5uG3-k=u?3^?eWubh;Kpl`5N;%c@40RQ3b
z1qLLiVu9X-wv&+l48074i%Ni4g1RsV07QU<h@g_w;!&F6w-1t-y|O~EFx2x)p@@P4
zf>hop$=?OR@+c2_0>G)+k91o@bUS^}-z(A1Q^8Ra1rb3Q>tf=5Z)Zo#^N-qoj>6JQ
zmfuf(jYLjaSV$T<`NQbykYNZDh;&q2iG#rAN1Wuc>692CN~jg=(C+Qr$RSRKYPey~
z**T#reqlXU@A3i2JQ|_Oqu=tw4UXWNDl=7$EZo(DuEn2Jbl%9$dk3{=f3kXeB-p-Q
zNeRr?>Dr9aEaZqGfqOLtj8664axNVlU>g|bX^%BAd}Dbv_iyORyxaD*p|dZ~xVgQ%
zoz4k#gyT~UUM75D$Av7KLp43)ArVj0Y^b(h{=uMpf4?!|Yk105$o$x?a-YjibzM3?
zm?g7v&##`iU%|iG)YsdjUS(Mvox|K6vLvTJ(w2r!7oSmGua#RMr?%hnEduSb`O%k1
zJY2YN!CLNJpz?DPWeFT`i|XqZiP4RRX!PY()(X#W{ZnDq)?tE{2OCzRw$T@v=HJg}
zZ~{>-1<pO0Bc{hXWxVP35XPTS&QXX+bllw81WI045hd^8XV~ma>ZSr+zj^ok_KjqM
z5nQ*iQ!+e+joww9FJ&%b|32~Brr6hdFU8(G+9b>fMU0pb6jb<`Ku`Iqv<6kz-}BYb
z4L^{9TXjIU#B}f58sm(|*R%9-JK*joX8p7-V^Y&_3fCR)F;L*5GwmXlqf;L*S>xzz
zYO-$w*VV^~#Fiq)bc0~cUQtd7;ng^_^_8}MV?D~-7fDG;rCny3FOE6L>|o1Mn99>O
zoC9U+6v-I8f0J0i&-u~Ip}i$%q=Vp<Gn~iOBCzUsp71>IoN2u4I%4Bt$X1H;W26*D
zcljPPpsbw{nNHZuPj6uhzrd|s(mOv-UJ#yz+3vUy<v`1+QjoX&z_Je*r<M&zh%`k9
z0qeL9Ok`(gQfv0jPv&en@!MoBgZ=$VEv`qEjO>(DqrdQtO^?hiD;jmGsK8f<v3#S*
zhZ=(@#R}wsb;ht3;~waCWLdN&+cj>@qje&Fx=&_d^cB@9dF+P7*AK@bV;SH_f2{c8
z-@9P6Qo5$T_V-Jv7Ubap!vqq1^#RSwGq9)jI=9*=E}jPC{8!2t^WHy8-82<7w;afT
zM9YGL)|TqpyH=YNq^G}*oe!I$jPpKCX{62Zcw8O;ptjsZwtrzSZ(l75zQ$}}R%&L$
zidd}6{oGld@YHJ<pE^Zz`xMk(w{(vjmzi2q3b8yrIdwFB{{E`p4~-3#>DfiWY7f@i
zy%6~Pk#dK22vB@aO%3y9kl!(o7189*4kxAvDPI3O3nyVkDx&h-IH$vt->-+oXQ;`2
zyBA3B*;+*MLmcNu>?E{Q&F6&2-XRg9n1QfJ^NBg0<3Bsysgl8*2@d$&4(ud2UMbXk
zRd(}bFD2~K)rQKL@MeW#b^ZO$m-{!?C!h94sDN>1*5<hQt~&=pz#?_6Pfb~=$ZY&1
z6ek!4XtWmde3Dc$($qYM1#0{MIM=$O6IuWQT1PUU*<x>szc`sNLP_+@vA-iQAaf&}
z6my)(`cl~PiApm<Bu0+-VSA8!0h&C$joIe<J_Px*y|sAq^Sgwa_t8i<q)vooP&btN
zMZ6<2n{j?4HEud>&d0yxON(FcIJV)m|DZW1CURmgA!msB5uzrs)r=fRwp7KCQh|B-
zC%urW&GE9&df%+hZR0!B$!X3-60)u)n9P^3Eg8H1tP@Tw2wte|FnNs<cq(I8hG8pL
zOJjB1nbVk{X@E*VTXE28@f5gK0ZmNOsb{ixpZZ8EnmqM>${r`55_l-7R8hcCsY~$p
zk$OOuGR?TXp0vKZwg+2R)S8cX?u$(d2#C70^fHB3WB^bWUM>@*`3_?S(V_1+J=3sK
z&-XU)ty4e)6))Yag>z<pHgC*~;ZW3(1h-lx2Ub!)s=eL9l#fu~vWWX$pwe>ZvA^HQ
zkfP5gMU`{s_n2U=<z?6LSq!R>7@|4K<(a>@0=h-}=89f{vZ_!l!+uGON?-w?FFucV
z<}F#~jfyP-&PM3F9V}31`^$xxnwtE_YY+NTTOZNDm|*t?lLNW8=5zdu@xp++=FcC3
z!(9nl?n?ekvLmB&4dZjFAHh0!#0K}TiF9l`py}(NzUW7Bg$n}fo13+|we}Px6PoH)
zORqb&DAs=INR#7xTN!drGloY$yPdL2i~9o^NR}7^G0J`ve?nK%Z-gh|*!4pGhLU?y
z6sMgQ?Sfm!wo5U3xe*uSibV2pDDWotFg#+J5Js1vEyzrJsQ*ZCRvKdqA6S;)?4m+z
z<n$quHo=4N)Zr(O$dfb}!{;;F?uKnudW30?2xg}{Ec{+iyKH*q6HPZX7TpN;UU~>6
zS8$?*XE>R0PbYwN@(_cC2*zic0?QW#q7%!Hm2tlGLSyM0MYJ?x*m7Sq^vYM`F#}}*
zbC<+mw8JN`!*|H$S~X!csc~*<n!>vyvD~SVd|HY~8Q~uqHW=D*#5kwNi~?o^Qj98y
zY5y3u$bjbMx}FpN6ZjCbS#8;&5k5SdEtA5N(HI3P_DA@nAqHh`1zj_<pK);`YHiU;
zGiqbxv6s;!{ez=9iCC}FTN4zjt3#`Vu_?dy6(jHZ?{J<T+67~$P<0T5Anw1}d7j24
zP`u;$bjnprhAO1#T2ia9UD{gbSzfk4>-w%FdtP7_#%E1cD)sj3X!=6eu)(XI$n#G}
zF5|osbo)`(YHQ>7bLf;E0fU)S?H<nt;(y=}lBDuM%e8{VsIOU}ZN;9(k8>KJe{e9J
z*HlzR1p`1^ZU1aJ(|Y=<Bp5b<1B}<ZAl7|7Fk`*z>7hf7h*Y@dw(or>y7Z#p@jR}W
zP+xux>E+YRG0kQNcVYnEF<Uo;l-@R6OwV^<@Hua|l35#P?_khaZu^8y=aT*EL;zyI
z<?FOqj;k0XcC_h-CYf+aT&uG6p(|M7t>Z>Zo-=)V)RsO4SJ&QxeSFC_Hr?O3jeV%)
zWv6IXBpySfEQbzXztpHISgfi?6f%tyanq#e%D5<JZJQOj_n&eC+$=Oh^N9$kJzR55
zvJ&EKBhONf1gs<@^PjUcExp|ncm9yd{`8c8h~F&YoKz20rN2K^q$DpvvIGNg=yHZS
zvaoBzw4TGKjInW-6Y|LnC~7GR0xiM3ZV@n8CF$Nr_@W5z36Kcp{i?GS-2?MdW{6Y$
zL5t!0c*80Chh&{M{yZDBKJXgG-O6bKm9q!KW-GJO?H_=zrj9O8qKl;=S1F28{Yh#I
z&I_Cm0Rc7;MpKHr$5YKoNeii1-5(B}5Rw~Br+Fg22IA`Cg@JVl#N|rP<owu$Z)oA*
zIny;jJGSV(1V0{v_N27@=;@wzVxB&w{N<G<bHajFoiQWcdTVLPkfB7WZboSdiIG9d
zRp_$n*~wLcn=-z|Ra#lnZ;MDIDqS7wb7VRb&DsE^9hz1NrSLj!Kfw6aOa?BH!Zv!H
zH=js&-R$#2BjigjtO&_iVbDnNruN5?KWmCY+s_^p5@e_g^Kd{|7y=86aneGAK`9bM
zurB@&%6CSPz!y0cINjqAbyV1sKdq#?42T&w&xub5hl)~RQwkr_TMSQGRF<9@Xr5ib
zd%7V2J8mk`wV?U)QnJVOuA6;_zKR|WVLEwf4;nYJ3D&(e;kw7DeL;9~CK`A!uO3=w
zv=e3di_gjCuamA)5^6;uW#5!RSUGa?<qXoH+Ix28cSVsZee6I0AV7|r&V{Ek(-df+
ziXKHdI}o%04P1>iI`7}w^`lkcSC(iQq$xaQq+e-g2r<Dfd{`Xo#{%pS28dmelI5fT
zFL{Rsx~y((MK+z-6I_y#J$q%AY1EnRPyO@rMz2j)qs*t#eu{*eqol#uB@R!24Pz6d
ztNUJEWbCcaAz_4k2FtP~YIa01CeKDQ(hP`RdP}V<^@_;Jk3}_vEks7O)`^%4)pe}6
zH^+tRwY-CiI_CUef0nS?ES;}i5|Dz2X%HN7>Q2a^J7o84@-N-TSBs2zLshJ{9?l5D
z0ti>rm#YH^Riw7FUr-M5T#VfZm+31M7FJ*FPU}fzYEM7SVTk;u$%oUNI^5fsnDlgq
z>$zKVjN76j2L#yiX!$?X#|c4sB~H&SJ*mVHpT4hAOkfghb+H4y{^WlwmM9a2_5D1{
z)|f_6G@ic%VdxszsA2K>c=;F0uQRQiJvEO;DolYE&v|)<gLX`%I2xOGulU6V4I)l>
z-ApWc%Fi6ewV@?r-qEvMMEX28T-J}p%1pN~E)gL~e0}Wod%EZ@2a^e6bC_idU#)I?
z<r0ix-v_!}bF4NwB$;SSI$~~Z#isefKMW4kI~;x6v;Bj>YT(K;Z9)_tjdR1;C58%`
z(05z0+&sy$GBb(p#C7-hi6;1^)}#Hdtva!4Ie4OM8Q2#Mhjx6yx(cidoKbGYeOPeA
zWNwk%BFVrvedELM2HeTy=`6K=F$ew8E7>Stl5vF<;I8EmjuIvGJ&T6$A!`4O_*(nd
zPuHACzuyk|gt4bHE7Gy6D^A*K!8GDcB<}75LhUGFg5vMGqNHYU*0ak_d+%vzUEs6H
z*gTDSRIDuSm8u7T9EmPO=nOo51)-5ZiUtH0hY7Z&vmMi(F5dDEU5UbPuA-*m=3dFl
zBCNY(W}Cy+bl&Yu1T^%&OivRCQtgiAxFMl%BiiX=<(xH@%C!p#8{63dtkV%s##lOE
zLzq56aTfp2{9A{g+!h+YV5I2rKmq>phxp+E3+nVEt2<>yc|%25e52Nd3p^oJhCwyX
z_Mfu^Sndg7HPz!3l=lH5G2oVdIpMb-ZwHUNt_9!SIunaYsaW^&jx{aDl9g3|hafaH
zbqR>BpsF?_H$>v=ZS+|3kek(#kE(^&|7dDmDUzS2YDwP28%4o`Cbkdhn@_r6z5s}X
z$$AZ~cYXDk_@G>VtulS{bdI2^Fz8tlqsN_$_}F()`%}Y{9G@s$(ZYdjGF$`#SgQ;r
z_6{_BDBrTwUaQppJf<cC6<@=u{1A3r&c3OQ?VnBp$wBOm6fxSzZecYsc>oV2%S+mz
z^8V2OMVhsX!Iv<%-<ln1Rc|H!Tz>JMQ9X9OR7G49tvPq>8967PTfKMbQGEQ62*et=
z{8@(T*GCe3eV=OAE18;}{HZu2!-nnb)d#^kj-t2qOn>btQ?$(auXqaXJtqmij;pF=
zQbCgB5~d|9Z8{t|oOg8$r9G#Ok&A_*EmJn^6Y22xsb4{RS&(HDsD&0>Y+#p-Q0rA;
zDWfLa=UssTX*VGil4`V~aS*LY3I$A**Xkq$$xt$_Er?eR<L%pbkY))+;OAmeMQ_l5
zmzD;MqwJEE+ujX=mznr;xQJAHIvSpfkiIW_nFKpVTBmMt(aO&Dv@0s@c(<T#JWvSk
zC1ejPyF>cDmOM+1b2G9O!nY?rb58Jp6{^v7v`2WV!}(@gaK+I@cfXQ~8yy7twQ(>c
zewuetO*6ADwK|}0Ex9+wb8(EGZlPf)Q{&b?{<iKJ3+JYG%ZqDo8PlIocgTPeD1CDB
zy*sFKGsLeePXkveFTS%9u4)bb1kbAGKRbh-q5redmsI^qYv`PYhTmX!^5n4;v+QDm
zB;~bQ4ar3*l&#Gp!-CMVgaZs1TuoItU`Ar7cL@@_ws9v#4Dm15LknJ>=x!$_UW5ur
z-KlhrXYu8zz~?X-fh~{8vo!o1x>HbEhPh9rq{79JK-vSmLH-BQa#yp`67<J>98PNC
zQh`TVHQs!e9}Q2e)wmm5ygmdAyQOg+$iQ75B+iWe^PS)p+m7TcxhAw1sbyd~TTQcs
zs>8gKXzn1iN1vLsPby5&N4b&-kwWb<sFDX3c@=cv<RjEQ0bLL$jvU8xvFRR<yBpz{
zM^2js6Giwm(B`qfqw4E@@1MV2OS6oO40F+Ns|$0XVWwq@Y<hgyri}-|26l%38A1?*
z6k&XBb;X4Zw(`AxNMgQ+ff$(ia~#yI=g*4aFzQ%-Z#`~FnRP!s_B7;4)nieN$AeaH
zHK73I>m3N*>B>}P^>h3rp?qbK&xM$~%4SIdHV*&x56gnt#!h>*E{8dN_qVH5zLL^X
z1Y}4bCUMrypX0xU^gXU?cAvg_d}Ngkp;MTmEd_yHOhWsbYz2d_NeqZ~_U4O*G<0+;
z=Gl*Zkr`*dKPMxwB_X30`C(9rtnOG2Rd~#XX^d9*{UOdY#wZ$-kr;lTSX^mrd%F7k
zaVVY;4zYYj3r55lF)-M|pcv<DO)T5wN+aoznCU9U5J0ILay<I&MJ;My@qP-9o)D@&
zNRPgx(1oOfn|bG@sAl30SNMP)Dp*PAH5^4vV2V~DW5vO1UCCei(eL`Opyo%cr}^zB
zyLmP`k9tk&O>$=pMaNYe9c*%0g+3VISGKA$QV8YM@jfke(`x{usxc|}q>o#TeH*NR
zbbFzc`YDOn9?ka?3}x2Pi%<~lUl)LpUK~YPFsU>apM-6HdV>Gu%a^)E$-@ZE-YeCl
zrl^}>7D#qn2mU9hv+x>+!6yF%OsHYP5<#Ml;JSR^XuyMmx+L+54k3RJpA-Frx@2Cq
z;&r9vn~cs;TO3U}&*jl=;)0N?ZFdO==fEbMvP-hmIV&?si<5vHJY2I{Y6f3r+LP28
zcFmlqio5#{o!#xpBB#|(w5MxbKJloFgxhvrWU%jGfGjMX#il^SgPM~XxO#v=!=w$?
z+Q~aWHiM2wSx1pqnH2v>$me#}0RRWmEX=i9=wHardmS#%q0QKzY693Dl$!(qliPN!
zR*5xccs|XM7Vhq=f(6RvKNO=kLo0Rr(+3lxn{YeowF_Kj+E<J27Hzv@rSOYfBT<xd
zB&T{a*DSk#M)9U(rkuz>4=@~Yz1Ugfk%3!(F^c}{f$~CC$0NC3ASs|WbCF8n`kZ|0
zYXae1SpMLlb0v3JX;e=tD9XfgyD;&gYSN6)FFV0)3kmo(M3a1w-_l?Y?K0pxTI~0P
z44jqvO$d4m{EYs=RN@bhSldiZNh7Vs8Bh~U;&wC{adlvRUp34DhQkSMpkc98`$!t=
z&#xIKNHTt0{__Jr<o6JP#^&;3*Ml!!aZmoxZgia-5>EG>tvnVYTe09PjcHwKUwNyq
z+edf3a>i!a-T}KCCZk=q?Dv=3&1TkV*Vhj-q4b(dL;ZF7%x&ncPW-L|V7r~<E6w8Q
z%djGo-}R)ig)qB1djX)j+LzMB+FJFKX-PXp<X50tWIZec0!~9<CdW|w*&zefMD1nj
zHOz&D54~{j_o39&zAi#>K?cb|jcEqO>EPO0UbuCJ8~YJ!&A~eWWk-ZZxUjr9Dq2-n
z#bb-%h(A+%=g_dG-d5T%%%vWmqlcHC{=FC7kJHG@3};!q@=4#PJW6-~Z3#;WZ5O-)
zCSjrsZt7XsvP_FvZ?&DF_{-X6(r+v!<mm*y=Ee<I#-6o};L8Bwv0zR0>M!a~3C??R
zZ31Z;wTUAhC;n1BnKMh+%FCF)0uzzM2lCGkw$VJ)MJQDi=iJU&wFk?!<5UROtcm7_
zHnWa=X63Rjn5Nv}3lSO9#v2xGg;l6RSNNGHU3=#{%w4@S!wrjJy$B4XAtC~?4|<|R
zyGQRwKdtfj5M3km68+DV_lA*jPdYh~aA`;~$gHHYP;w{wh*GyIH+*e7h^0B9Hm<{o
z#8<rT|K0%+fxYDDhF#UMI@mk9Ic;M-$T}YVbc$?Rb#6Sm8bvU-2~#+kliPiHti~KE
z&*e%fsz|@HDeU$rj3Y;E!&?xf$WHV1_}}`Jw{fAbPbdmP0cb(%vd4@r)4=HBT<}tX
z0#vlL`;$54j%E3IeYW{Ej!D(@g3(!Ms75!s1zc;T>k9ZNwTrd4cjve+RFl<r1fi&m
z0gt<H!hf;W4Q2FG0&d!{G=dKapW%OIw686hB3jPWohYIza8!u@+G`<cyVzoh_W#fu
z`N@_qLHYVUkS&v5YiDgv8mLOtOO(r0X{`vPjFhLe?Fqy{pP*Srp72(2IN<0QwVKaR
z1L6aNb8Itg7GmID_YN-D4AhdLjW7B&|IP<PX^-;BN?3I5emB;1WE1i`d-$Z#q^srr
z(L>ofECEx0zP0$enAv8im%&v<zx(MZ>&MyCxuU_2D=>aEN5RfA==`VKQCSN3TW3^?
z1<NN<QbPH)T0OXi-xilyiq?%GlfH-Hv8m)BgeKUf-tJ2C1W5u?l<398?CaA}oca7m
zOt5OstM<mp@?}bEIFamKiyiQ{8$CBf3_jk*he&visEw1P>`t60yZr(KoU6FeXQUQO
zY`UaHhxvd^&(RUd_5$JjAevmG+WYx{7US#qV2iEu-N5ND2q8g1>f1~zpU1dpHUgi|
z`j*G@4Dv<uLwggs_+>*d)kt{Iv(KLVNeo%hl0Je&(8e~M;^)eB-mHC~BZW&oSqq2O
zp1n`!ZgfG_#hi(8ZQI0%Iqb-7+r^V5BMumE$nlxFp)?I-l>Ja+>^<{B?A;=b)LNTv
zZehr47n=6EziKXl3P%yv;GR9dw4jdc=>ao+S99NhY;-%sy@+sho-x&5v+IDh6afi<
z9+H)5(vmR>vy-f0{Vq?0c&p(4A{50K$Xy1s^ogk0kBDDFSS-XAaa@;{OfA0BI?g7D
zk;Ch%UTv-MQn?!UPmkaQ4vGj}3Gsf#B55(HlHToMe}sf<{Idp6|5A+t@cl@|-DMYy
z_iE?M#po5>CCSE169x0?VzhBP2@FA&1&I6|WV^aM$^)5!ew54-9{FE>9O&77nMuu}
zBU@7b^A29lI*T8YBai!*Bo_sltPEJ68byTSr$-btzTf5^<q<1#*y7EiYOl7XNfHyb
zF4#UOK|dW6v+*P8)_ft&jxAoeEyw4A13JE^Mh4+==oxbg7NP$<n?s|&CpVxL@xF(*
z=PrWz88jS2{SNTTF8%HoSDgUGEvdUQZ2i@>(C(y#h7{h@Ufev~mw8K1<BCnT*_o4R
zS3!3)PqQx~Ej$S7`=P=}jRl$qO$!XrVNkhO;U_5~<4?)snPnC1M_a_Ga5Kp$tDH7s
z9Yhpvk7vhDGTG^YbDA^LK>)92B3lzX9S-G+A5ocF88^HvCoXq;eoM$FuJudAiCSdi
z9-fpz6>iLE@1G1?0M>P0Qn^?QXWhAYh!g33E`6snTQW?lGuzoGqVSWZp4;5_5Jj?o
z0k*#x9?b6?0^Z^ORXPkR8IA?}GW%|}G-dHGMhAP;k)b1=Z-QtwG3&VXgpSdQUYJ>w
zM>GE3^VG9rav+B}^b1(#lk|bQsiNM8Q+xJ&^w){*nMm%+{78fL)a4XFt_R9B&^XM}
zpUt%@D-fH+$K{G~sdb#UX_5S>sQ@SVF1#n*vpmz1s&KmXSKMdlY$NZit<@)JmIXY+
z*!DT%bp9F%;hZssl5?)j(`UzaArJN8p;@S2-k)IKPr_!JByS8C4^EogT-$DcKSz_~
zPu{CU;UxaP(~cxajl6)cO1zStU;RGzBjs%_CAr?yxoO;cS*2l+g>otcc{JlO;xP8d
zWs_gzh1$XWB5m<Z*duk1us6-LH03FEZgZot;TqT-o$*3@*zxd~t;W4W22CQ6th?H#
z9-rJf=@{GEn6bWJ7llA(cLz_N@fgI$PDJTogw}u;T*7hU!(P#ksNU_br-obC6CwbF
z+B_1TJ;`iRn1I2;K_1$K<SH60qBxB^run_&CESa3NKTsaU1Lc{`GDgd=zL)=B#~L7
z4_ZuD3dnMk|9IqcBjZFH9A%G}H&|`>os;%zn5EPmk;=EFi6hsP27Y!Iv8T(@2Kz7j
ziNrB-ME?sZ3z~&_LVKCPbWEy<EOrth_x{l~<DB*3@Q+v2pxj@VyNChYwQ&?7XcVXt
z#o*jWOb+=iVLYI*7<{f)^|nxyHK8WENodE_a`8YC`L;8Ap0?-x+_vJqoUPqa2jtHF
z<ftdqGeZCXHh7`EiR#%+R|h?>2Tta(+SIH^n?ys#YVh&AP{4eiVdt}J>%;!mr$Xlm
zDW2iKWXLmmi9J=X;t#8bv?IKw`8-IR>5o@pE}y^4=KjPEF_i|&M(NNV)c<_c2KNf;
z-<ueXAQDZbY%$;4CyFR1;-kR;6lyN7>8`GoB>={;Xp#-q=XeEF;OorQT*eT0gE=CA
z5EbWdvPzBpol)SV0BpajJ8l0+`Go!Vv7LFz#Z!B-okih>brf-u`lu4cK$J^m#`9Fp
zqQhZJ{EF%KKeERj?=EdDqYeguy$u3Yx>H4g(lICZGr9RdWI}e!MIs6c)g||Ho?(47
zE-Rj4A!GuNr#sl7bH=U0%b!^Yndm`hjE_ZD7a|Sr@TrUS^62|Ivx-BRdlM`MJKWg*
z5&Yr4-M2$y|LvfyQhW32fNv!*3&WPdZfzc6y+?m&f3<IZEIUTYStZg+rA)FhnotjL
zEyy9E*^l3C_!$ENd1T=7>Cz1E7UGYauO6=ce5_0ohyr83+*(RF=DOXkaE-qydOF9~
z$axQ(H64YI)qXB{ibuA^LIBKMsG>}m`Bg95OZH-EE~}AJN4_+%UFOz3$H$0Kg}Wnc
z{^H0`Q`JL(WraqrdEr%RMouEA{f=4#n&H0=$B1ocp?}oQRf7B<-aYVfrx$-m`(q`=
zBr9b(+h5Gu=N(wz`+Vzt2AP0k2OEb?7!#3@51zsC(F?w%DYU)Zz^_;vQ4zBH)kjOJ
zkDUB6_fLWU$^u-MA1qpi5WMpWP}k7q__Dg=4p?1I@+ruMYH6y!>u5+wDIPij_nND%
zN^-VN1zUWbZh|CO9)uMDUFM#(<A_H%5e1#37vij@l;+9}UIc1V>SGOS`Y*C?n<lp#
zH&uGHEl${C_K0bzyfuMIBQJeH4^*dilV4P64pNQvw<bv}q|g?kn*xx`hwNON6>|y|
zLv-Ky+eTgE1|<6iE>s<_2Dh@~CO?KVv1TO>pF6YTtJlYmGw@>=JVfei-p+r8UUb!t
zb=>|xH>CLR;oP_PQ30`p+Ovf<lSGUxvT_aIdZ{PaRPr}E#VFMUBa<z2Jt3d$m8E&s
zA(ra1cWOIyBd0qzbs`=7El$h2PwP|!Zma*{rOW9|GTjK%{XQ;Y)sV#QiwXPD8arL4
zKI+1--jeF8`?7ZUVOZF9*e$C19RvS|rWjZILWvDK#KRthf$0x@T~1>-V`=Sf4||<w
zT}uJs-+sMLQjK6#JGQBeR8>jKggPlnB_A3kMMaAe#pp&HhdawTf8Y9DTruWv3Ysrc
zU72PRcBivgd}8QrW2|m(Y-6nsaJbqYWu$ORZ$n0HKtfjQFG-MfVULJ^nnr<vFvlJ5
zW;%8xVH^4J*S;g%r}wXPkH4GnU3=_v%d={3tZH%VKvEYvJRaTFR1F}YD0vH_Loayx
zD_ySvq5l3!m4RxclcC4zyfw8c$2JV9<)!7$7fEf4BRktYltfP(_|L2Mwi;N{wuD-G
z1c`5virYpkSn6UJGA)}3Zpx2Wv@Y`bGh%VEy;BX=Awgj;hW8#XtOTATAph_)`9^Jm
zYCJ}}s>Ku-(EESIu=q4f-WCqP33&z*FfAM9)@ZPwI)wmc7t_E;J>!?7Y4VVPy;@Z_
z%|TtJ;vky~!~<rNBLahxG_i@rhzRX)0)uM-Lgh)X#!h4cRU^|E2?Sl`Dx1YIE}m~S
z0jEhO*WCQg!irPl=n1KhE3D~$WO%`9;F)j$+|0)ozd|1bFhCy=XZAbQ00T*4%kNKh
znBIGJ>T*yLx?M2}zr^I#YrgVWlgje&DAx2k7R{z#gFr}(3IS&<XYY!}H=7g3DJRqz
ztJ=L*K<=K2JHa6%0VS@(atHqNAEHA7(4R;q1Hq*W{M|1x(F{H(M_OB|n(7AU{67E`
z2c*a7UT(+j-*wOYdFOs6Hh1Y_XgaD6+sETI1`ZtigGjhzXEqtAQOnUlDs5)I+rVP(
z;RRgCwN3hX7lLsyD<m=t=wE+=hBSf&IuOpjedwtKDU3n}t3Q^XFVUN!2{JdCV2X$l
z29zQMO2IA?>UCh=m={Qu4zhC_M$|MhFwt)^3M;z2%ymM^tAXdWH$GI?1}J~I3Tp}%
ztXq%+W}3}M>-$4Qq6rj7h`s-C?gp=~?pTl+bFIAz41&Jy^*}l(MwaqrR5k`O$0EKm
zeI;>kq(qBV4r~B`@c4-z>*EOOq7^T_`?X<+Cz3t)POz@Nd1Qac{;!D!i0^|1fC$xr
zPk0LW!3%y5+9EIFhj+~cgCM!stNfz7n})>Bfy=##x1i+bi>g4*%GX*VB0i&m{^&6+
zl_HapB65)0p^%_z|Jzk_{u$G6H3Rz!**y*{^BB1N9Vf_2sDbFX;;<+QEJ|P?lVJIZ
zbQ#30ENl=sJ@nw$t5Dnw6&-}VZ)T@-VC;JLoG_gih#hI;qd-Hs!SKGI2IR;V<dO3@
zkF6S()<0^iJX}MB1PA|mAZhLVU!1DfBxtP3<x4>j6?G3WQz^*bH6V=W|1z9rd!rk`
zOt6EKHOe#WwD%wAwtN2wbjzZ6v!27kzy$iD@Tzw+VS6CD_bx<Se3=GM>OcOxGc6`J
zn{*e}M{g~Ec)R^-Am9FyDJb=99XYjEgq$G-*8Y!9Z&pG`%iIRc5UeqalvH4nOlU#y
z^-i{2*l9~it^&xyGWpVYSw8tw2#SeM3v>m#3K}UX6{(gcCSpm`Ka}Ju2=H^S0AU<%
zwj#{Xb~|g?z4OHWSduxuf|@2zS>fW=k!>lbGiVt-s(}UQE!0S8o7e>W?c|=kg`Ygb
zD1NU^Wdm+e9c~El1#~)0l4b#lm=E`0h9N!~Q&D&xbH-AioEJ(*)pBkag;8`&n4u&R
zBL#n>L3*yUl1H_W4HmJ+*38WF4x{8cTneK8(Tif-@P+_!NB`J_k!>Xq==Isk)c(+B
zd*g?XLHs9$b>2}jNVDxay~XSi1*l}4()R4Oj|{i3(_K>{75fnsm(Lb0qsLTK)^J}&
zCcH{&P(ZKe<8r+>jyL+jC6QP<E`MDo0Qi#|E$X_mc_{-Sc<>=i5XJ}eB%(m*q4=Dw
zJ115Zhc-yzY*#*+vEhP76SO3AWl}1a>SzE+^2Ou!5c)>SQ^RD3{}#mZ1P^_2sXOfd
zR+fkP)Yp#+0B!ZyXN;uYH8<Zx>{RiK{YEe;@`j?tov_}A3HE2mX};LKh$l46YREh;
zUaZ1cS-;JlP+l?FOR`C?EJq{ulPFYB2$fmPR(HOjb9zC@7#R9GI)psRzQa)4FdaVT
z(pTz6h>d-GwB1j`!Ht>}RnJ1olKXwTI;x|~=?XO1rNco3YTnF2^M;bcOnw2DUv&T7
zi;y#k+%aCcR!~TYgtblWMx1KenU<mPi4NP2b^rNtf#tay@im6;d};O4(zlfXawyRg
zhX7yFUNw~#*~cOF`;S{Z$r{O*>sgilq4CUEVO)pSfq}uB{LKdQvIal-wiz6)t>Mm)
z6((v<CVd`bc*PJteI)*Pr9ST?O`tqO`=m)cso13+p2l~wyTBf(!0STYuT=eAv)9$3
zH)SHnqr5x&-MOV=+z8{EGw~nY^IZn}BDEFnw9S!K&M6NYxg&YbowigV(rb1T)6q!$
z@px5fafBeKPI2CFUozLkqJIy)p;#Kn|5|ka<$i<(UxA6)aHih&?;!~pScWw!#&h8*
zhfgJX$SlA-N0*X?S!P35?m@MimQJDKEitd>uZo~6GGP>|BJQ_YH|>XD0k7GEHD5>#
z>*b20?&9}WRlE2af8m23O}JwhP?E>V9A0~qab3MLA^bx??^N}tTU}5HGV`deCv%`=
zOuPP(@4RcPBv^WK1A%uqid+JO8X$OvkHXVLvD7U!>OxdIM-);TXz4>aXS4YMJJR>p
z{pz)5C$FoVq*p*kal&8;Ge+onSE;bmW?=ohVfd-^aW^ymRjo;+kd#$UVPqDF)1L0%
zmyGX#h`^-F;o#Ha#1^=a>g5wMeI^O16A>iP0+`n!?M4Z=kYbIJe&@}?D||E@yVZqH
z@pYjJOFMaTfte*IfRKB+TvMaP3iPOwM6K(PdqGIDfGixK@F_7(vbjPy|0!E6E0{33
zvJ3ldD8+DHFn$p5$y<nS5FSfjSjnZ~HshIUK4wUFbI-Wbp-F1Yipo6MI@Ok6V8tK(
zdl{qs>xLFYo^Gk#zhk5be~aa;#fqZj@)>_+f`JB&#5bA^8i@*^e*t5Oa<*Q%>0$Hv
z3+p2?J9Aa<hY7rOKFpK`Qq;)LIlVu=m*7~&e)ep2d77sXrC~TzgPB2%K>7pvO8sH5
zQz9XZ2TjjKy`%Ng`h?PHjWW58a>MAF_RF362g<^9-&%me%O9MA<fZ_b|3_j*9<IWt
z5=u^A@!R|iZfn6H;;klY$fL@0K}%&GhVQ`ikJahUQ)6hSk&7YZXi<J7Arvq-a)zm^
z8}3hOhdL_fCskd)=QDFZZ8_wYRW-D>{t4)@$&oU#9J^y})f;FKl}cp2{rbD^It^T=
z+j7C#U<FB1#{VDgC7Xi|OVVaCxL1GK<z@+8jGN{s!jd*VLSB9c&u`0r{sNfcZvYcl
zn5+oAgESVhisoS>>9;kC0;ZHL!M8pJN;s#)JpG-+<O7@rQm_s;?$$8OxV)ZI&XShE
z18}c86+?r=dW(lNphLZRYKtSoSsK;|_{e&_H<|94(~ggL6ZiU}saUaAe)mMxVG;4S
zphQFZhW~oidKmac7@@2=u`4TG6K*zVZ*Z6pVd_w?O)7Sve5Ss~`YVbK4E9f}MS>F;
zpl23B<fSSzcPROVz=5l>WfKX5xGoTbrIz6ZCHGBHJA+*2oVVe4el<OWzwHl)13d4u
zOxA#4YI|y_Z|j5IR_W#dGU(BqME#T<8}{>c2)4Rz#wMp{uy76Mv?>Jd!hUvZbsuf=
zR~pMP1<RMqy8liiPEyZ7uzHcC=&GPOOW)wPQ`w1E#6K+^$kQ>~thzP1r(RZpV#-ew
zAP<IG_qObt^-hvud*3j|VhX8N>wtt7mtcy3*9TK+u=&_$3rah-<V|CJ5vOynObj%K
znos;`H8Tg>*+q+=jj>N<Kk{H$KmbZE$uMS=<2D~N6xxHC<Vxm5GlE}Fc&~Rf)K;#3
zSqAJ&IlRq1ne#a^OF5<Zvp2q<8^4e?;3NNRd#{6-X{DG2&9HK>)Tz!yZr&4#7@0ri
zQbaw997(|AS|J#>Kv6$PQ72Jkcy73qyMEAPa<K3;;N?H$fam`5M;PQpJvu;ZyWC|t
znl|>dT^iCZfdiN~rB=z!(F3{zbw(d*mz`VJHb}T?WZ~7;>S}o611qt1svcDc7Ck91
zMsc->J{XBC2eibe95{!pG{iKdKCUk$^ZJNd)4$VTlWN5>0p7#rYDt#%?CQea69VgM
zusOcq-jt+6x+<3{*hY@Zaw^HyHVC)91bhz0VlLP9cmVy1Cr#FSSX}lG>1|HUTm6tN
z4)0qqAK6+sOx51ply+egFy+W}_v<CP&DFM;f%x$tKg5)G&dBgj!lTMc?Bt4Mco4)f
zMN_GE_R9WYEvNv`sAqn`s(K!D5_hVx9?=i@P4?}&WxvLFcgy3psc;&ASlm6r*RSz&
z=)%#iR=*O0dh7FD#Jf%{4CEh}wE=K(kx3^Sxh5OR#&!LO_ZkLDOv$UxAzxaoDXEJh
z3OGfgxH1E5C&k?-zS~a1kbr^EH%e~$UwHdp#zth*EeQM5E$`}b?{aTd8BM?4lXLdN
z$u6m7f~Um{(4-I2qgW+!Zy9sUlPoM9P0;MW$kVEd-26-OlB@<V0L8JvJLW3ZK#*fp
zojkT^#gfQS4abw&`Z+sLEfxowI0%?@O+;6~?4jSceeEjTkBC3N;d@h-DkS*qj<dCB
z?&}IB0p@Od;&A>XKaYtn1W+PmrOH}S0KYwxvNbU2AM^^O_aM?<U8xVe14TUbByJ-W
z?qVhOFnNa=p@KW2r0grn-ldcvHruc(fzprj=N~o?OmA_;3#P!<K?2TQxyvs43vVi}
zcd~hn)+Z-QGf;{jL3E`RoE~%>yz{=E?(bDYS^msc!oicbkl@iU9pPDK7^)T||2j3j
zD5HNtB{zDKrV=FO<T5;viQWF1p`H4ZUaWY7R?oavt?ye<;~uBGikg~Q+V!0wfq}ZH
z0f(ZcO58Fypgv7t!Kk28tV^RBhX!=yu$I4zVtvu~+)4{zox<AQ+(dhijR<`F+>pWi
zYB;Zf-d#Y(Ijl+0r(1;x9f*KumziD7^;aHJFoY9V#DKM(LIl$gQfAk_)0D+6bxW?s
z8BK2t#qjbV<ae)q{p9523VD;~(_PW1%ksZK1DX8}Nx`xFERs$-xxo~8$+K{`OXBr$
zA*24W@nPpn&G2!gXXTEj;Z{7fYs6PPi`^Es66Au)gyN^Cv%OB+5FV-F)Ue~gG13q-
z=|PWZQ8-lw72jK3Ly}P`hZK9djgAR-!JRZII14R&Mghxdap=R&dQP?dRIF+3u`>{%
zAEi^!IzdDY&MnG&T-QnmMe#hdngSwjM?b&^9D-7lb%r-@smbLlZphT2*LZiGm55eQ
z5+512(dso%F_}*P)U7O8PcJ1EL-6&&o6F3==;EWh^5ntU&#A**9v7#;_K{sX6-U(f
zfLj+mhzO+aH<!z&Qh=D~YPG-rLe}{A&gH?n?tmi9sp-j`RB(v*`6@ia|Cu(n(0Wdp
zb+TnY+D@q<UVk!NA2PBLyYNf@%rKbFGx(37u@9mO2$^C!yh3K(8bUn_Yww6Ujy_yZ
zEmRK>R%qr9$kB}b(fpRG5>|hr&(<UfZ}CW?7&A$vGYTam%5rCg;`zK3d7&|6wWJ!2
zeza%oaBv6XqAwJJ6P)P5OZDkWWQ$9~z+k$y*^!cpE#D6Y$tS956dKIy-^0jK5-(`*
z=<2GfPg=>s`l5>e2qKeKO33F`3pO*DkdXk}z4+$e3QTf+HO0?Xd(pj6ay@zl0hEJj
zO`_@We~azuZagT>U2j2$&;4XjOR>`&r2mCIl41C5Z%Mw>Ozqd)IwYw^d<N+wjG3-Z
ze)~(%Ap!28Nl#mmXv84O($~?c+9JhxI!&d%DLfK!e7P=8<J>l*N={>lXt$M34XuC6
zG!wls{tbCt0)wX*fj3Ry2?yi(+GH-eQC*VZE;9Q0kizC)zX9Lp9sWNtuIo(_$M{b=
z_!(Yga=GKk#_5?LvjGRRMY_h_H?4x(5We3Fzlmq&{V5q}j-={`)>K$bBxJG+!otEJ
z4w*r4ZBk(27gc7&n*6p)Vq?(|m8ox3LgLNE;N<4*pg9-N@ip`X7!MbjCN-U?zEq>l
zuZ*Zr%^)Ne%^i<y2lrvx8`EKF|52WSh4Oe0X-7zwaayxlG(@C5S`5m`-9Z?%#ZAe!
z)~+A-thD@4R8)+}#+MC%Kq7#9Jlp8{BaOSgy?v11hfhGx?OHNcnbE?3Q<z#EFV4Ue
zv7OLO3nm8%_#eb5$mv#>_}jZZ1))6<kHq7QLYv<vHC<euJ=bm@9p%hMQwb-m4z{}m
z)tLO1u3Jm1MW-%9yH7~*YW})1{+)N&Xu=gN^Fq&o{<sY(iDWb>i~{y&Zxcc%))fUB
z<|?<<^-PsC!SPNI@O??%`o-q-`cVeVt3Y;m1e%b?Ks5Y1Xk8nM&#@}9F-vkpDqIRP
zoXOrJ9SvERb}*R*ajNU6e<`bG<ft^z(th44-%%sxlOb~i**K`QART=#dB~i5FBj`l
z<u`=s7=YJ~<s74WadmInoYh6Z+X5+~CT2Jnjyr2?d<_Y_{D^4A`q^5K#p-;0Kjgss
zGs)~OveQKSUSU4Fbisfgw=^*6?_$+?px+ZV+mVh6EE#0sHiNv^7YvjV!JCAY-0>6R
zM6CI1IVg}FVHZb1uGKl52lIyEb*J?a4kqUQ*4{mt;nF^Rl)Wf-oEc9rc<}un1qHM%
zBO+*HXu*DMh1iD8CSK)cq-2~HGwRTDFo1ehd*QhKk??d!!CaDUtV#Z^?2H5eQaZES
ze-GyYps@b>r@cA6B~Hs!!ku6HsRU;iZK-)f`Cl0hM<>nZB|onoTKVnxmFfQp5b|k?
zY=1oyBmvz*y0?_S@_1KiFer!cmdre_q6EbcVE?sBzcC9ZtpD!Kj1}l@dG^Hwf}-$t
zT=<dfpzYsx{#{tHiXZzd0&1*mGQDNC>;pqX6-D$}fuCqA9)nLAI+n`7-NSVXaT0D=
z;$Knv7M=eeCLy?}QjvurnHCOpSvu;J$%q1y8(?%Ti*PfpBh>Esn3)$B2F??%72gu?
z$JlK@PJ>`^Uu;+H>D(Q)Gwd}SUJ?&()NiR^i&9j{zS(KL*S<f;u1M80W@n?Pr*WSO
z8%pRM=I+V%?A-!Y$c(?5Eu(dmYp@vnllkBOa6ipz0=}2cBrP<RrFc+)!s#bhcO#KT
z%tM`60D_W4lM=7G!%O7)^~&V1-uSR)&L3+(Z>QcAWcxjx`ab2MM>LdRFWtknf)n21
zPYrrBq8g6XI4gOOw_L<1!N9Uyzk%|(s!9|w;DrE41Uxb~AOODCq!!e|*a9?woKLmF
zUDhW-9ij+d6I56N15fTU@RCM;fg)FAmcQw}Z0c?ojr_kY>$PiBqx#)P?|_Hh<(4Z~
zE`7KPJb!O2UlRn-{@_#8Ku6iLt@((-0`6Dz9-Ea)5pr@+Lbcp7(S)DYN!Exfy$l4;
z;O!6iatoMWcbF}lD|dr>HXKGZY95|c6a%%?$JiTc2%36E-y+lesVqIt>BJ*`O_z+I
zCC%N6K~_{W;DcIAy+4CB)>}WJ7t~KMRs$`fp?0*2bK`0lc8gv4+ARFCh_hV?f-eCN
zSBxnvLdZa=OVRM(vClv1RyEVTiaqb%xW8ztb0XDCYU9tSM5UiSotz0!pvRWTQ)0zA
z@jPD{1(uxL6Bb0SKOsG^q4ErWnxZxuOemFZqHiJQU<!`-p(}vQl3V2S7PJ|bAPv82
z>QRFK-yZTss95{(7IK^<G|{IaDl}uxe30*)g}<*k2(l|c`Mw~HN2^Gh%CB|j(mi$G
zw&*QDE64V25MSek%#AnG#`z6R4mBSdSjT3r9VhC31J1p#w8#anZr9p0`WK_d=*C}c
z>VhA8i9}FI+0<zojPK8OFaa2lY_(?xI1$tg3>ft@hW4m=PdT%}=ge~BAlB4<OKu%X
z;rO&^o?V_Lyu`e+dNNIUfR-*KNA{ZyvO8dM5AL%AMN3v?STtcYy#>jV&Og(M=xX4b
z=+VEMsV}~>D+}h)z6_(lwlq6$OIj;Grt@zz|Chu14m8j3+5EFy_*?ov;WH{1dST<g
zEoTUQXJ-FzVjXNMvK{b52Y(vSns>7OuCr}Ta~Xuq{7)lH!H;vvcK==9&LxA37oWHF
z)<kz^%zNDgC5_c}Kygnl53vcoBdP2#AtvMX>DJxX0_riE|Eya9z<*|tMOgQ~?7suJ
zj?uLfs=tO&XQ#IOD*rhBQ%jZdjUe@Oo^IB^Zibk1RD>*fzez-@P!n!uY|Hjb#tdLa
z6yHd6pdlQTw>!;#`wZel2tw}0SFG7wlWXL#JdWh@(e-AuoM|iwrVn6~2&}j!`oERA
zP&P*8k?7QitX78J%3E*reJAzDN0ehLGO;J?*Rk(aAN7OD{yv5N49+~*=3l|46c3`^
z5r!WZpb6_`8@N5_v>IYV1cLqWQRbDSp=)5_sZFQ(3)jnAwVNLEOdF~rwfbdBmmR9>
zFCs=_K*RLIKYYyJb)mEWs2-|bzEZb`BEEiArL+(pU>4QE<cL0I{4c2-l|I^I>@&eI
zIc;I-fVJF<m{5XBo{}<`mk%D;ax*1ZNB%hc7t8VywN`upWM$+F8+>bgUm$d6<5q2J
zC8*80FdLBu?>?Hk@dFwxsCGzkh>&27`P7MdY8=Jp1<~sG`$3OHds;HLQ4f`o<k*t?
z_mi?9nD*_6R%|uyF*ErSodvw#D1BYDR|0a)4(5lZgbxl%j2ajxY)+m1@jJWy%Y=q&
zqaheWvT7O(lZu6<c3SjeAw>%^_dNlg`7~%0;@g&LT7vT3PUA(73`@Zh=B*=^AF(e8
zn7Hk+KTMa11@;fcfqw*ucG5$65~aV&sexd@7mRr+&gqlUa<yb?_g)88-1CYsp)u7T
zGh1|K3d|%y7soQkD^bdm){i!k+rRvLt%LjCHDWg-*@yt^NvRTNESIa!x}8>UveeCR
zI!KoCN%1J~`f$Eh%}}~j)nF`^5pb&0Tl^yRQyJ3BHCV7s3|=<^YJD6X`42;p4l>LC
z8i;o^UC=b_-t)6HH1Ct<^|*LyIuij<M(3YvH8!U#TLy3)E~HmctlF@pA*Vq2%I$e_
zr~>NUCA{>2vFb0v-uFC-*H#R@o%w77z1b{ZrP%74Q&U|m3pH;CKCIl(S(z+}#%1c1
zt+k>9dkzX{{qyg4lyV2SUu-S{@}-4u7?)aR31%1d?mB$$o2T_<nx1x^Eysj`uORpC
z9O`^V?|zgE5STE!tU`32I-vWo(rar1XLyuJei0#!3!?c}cvtZ0)h<%kgBJJ3`W(Oe
zTp@U?$JA(^2~w3m^e$PfDs7vU_1#mZcKIgvbF=IGrEpG12QHM)ut+v9(BI<ti?zhR
zP1w;|4RtRLQwa^0y9)hcmN%(<GhmUQe2D6t7|2oMM$;UB=x=z7qKJ@Dh6%ihpOaBm
z7hf?PV_xya<F|;m?v4!49N7&fACul{&ITh!n7cv!l&gJWNvc|dH#jEKxG$rzrTI_8
zZw-_WhSQ8WwcrltHQz@2f`TY9F%3s0!D7sZfA@X5oNNb4ZYXb`3-FKDH=0p=L)o?o
zXbs41%#k9S=i*8a4T1txb^`Z?7U=2ud8fAL6U)8?h07uanZF`eEFX#M3oVX@4M+Jz
z4+()Ihni{+nuxOqUfEVnn+7`>;e4ulU>`TaEU=$CYQd=Z64E$6;#6qh>YqW6EYEHL
z$o+?D*TY8tgYC`SavW=X+j}gXr?9oRXfbV&3!%mS_@XhWa6%D6^Zn<=L{J$RpHMJT
zN?e}w{Zs`7WMD|Tj}YkKwvmE$F7Bk^J`?mZ(C;|%Tjf{zrsclJfpQVv;ihU~jv|c_
zJh(O4Uw-&HXitla0R5mw!^vb!HO{14hZ_nB4rX80c_emyM8p>n!DyVZ-lM;x0gbl-
z|4bjCxx!OvvVpL;m<v;Gy<jWWq<Dn}sO|EW=>H!d>2Gl;vmGR(xPxLWr=&B>4;x)>
z)^YOPK}0a1>L7$M6w@B4EUXaPseiz1d9Z$4`wran-+MLJo0}LsG%%BHh4&3gyuG78
z6QXx%J!zj|{vSnp;uxj-1{aGBTj#V@ng<v|_&_B+On-;g^X0b#zW9w#34$8mpFEEj
z8{V~X!t+9nEVG#q7>){gm;J+^kEF;aP$P6Qx=j9&x>LG61PUQorY~=}U7aV}+?l2R
zLcFK&{T$_j3k^%EGb%(tW&rC&4Nxj2`~;WDQqI7_#XZ)>9Q{|lm4#-hD3ZPs8`N@S
zQ914q_G8_%j$)h~Rud0hg$LpYYix~g?fcPqn66<K<aV_t8U{C2fvC7RUf0>M(o$N0
zvc)rWwb*s-waDiVg3!EVPA)WWRMeNLB9JxHS`PHN4%(w?PXF$pUs;4kWL!&_a%T4m
z_#Ty-g>ddG`^VJe-4M6$0!PE8w0e5X;!<athkPH2XIO7pR-DI!SceaZ?FoHtsweOH
z^R?Rt)vV@}?PWD#D`Py5eO;Yfc7);kE7wWVBcZ^1{8E$R$}%%EEsZF}yx4i|SNU2~
zl9J4Mt_as9&#a;A|B^IZuH_-U)R20C@0njF^A13Kw=7T(K?tYg6O6GP7H;hAV;Whs
zxV|0@z{t!zJe>Q(U@f_d3x$mQ?ysa1Kq-j*=NiS>2<4QL@2y}W;_G9UY2R>WdJs3H
zUrh`|4FnV*1uEB_WGyH|g7#w8y#WKBZ7sAOctMx)2}$TB>i^vl6hFiNw~ip|+kpg-
zYskStkP`$ZKeuB2CzwRZrRpZ?ol|{R`*6Ba`Lq3uVI~au_7`~QN4dKeAI_+wZ*KhF
zm*=|UUji4F8n0z7ut5<!)B25}IXIp^n8_C1@twWG(b*3qV+ECJKiFpSw^rTAQ|RR8
zHRTOPd+9<kN)2khND@#~aN4={iJqi1A7<M;3q7CYmdP3C1?^%9CaeB?4wyK;{oB`(
zJ5Z5OX^^P8D6$<f?`eeXe`wgC+K@hT-6P_EeTc<n1LutBbID0Jiv}j0TIFxO6@%+|
z8(@9^gY9J}bYzme9xn;7u4l2Qz@kVx^;u6UErX(`s{&yL1)@mO<PN{*f64srl%dM8
zR3}LV`d0}`Soa=_Yv@_Jx{e@*O21$DL+`0EQuvWGIQ{=?<1C}1YTGtENGlSG#Lyw#
zB8Y%=Nhr;LbUA>+&>$^{G|~;yIlz!ZheLM?Bi+K#o!>n1z3X}7*Z#HlzSr7ouXSJN
zeVm7YfIx?>+xZ}cnOUCcD-QR1p#o;+k@nGxpIr}m^!2^B{)?m-qbO#;8`JClFT_{k
z8ihR(&JMb0$ZtTu4#2md#=9bC2|l=z*sK&>!&8?p8_Z!7D$#QPa37WNCB)y5$Py6E
zAgSw-E%?P|kQyvDkee2TCV_P8N1|0u9ILSwS<Y2dxbNS;kEo#+cyey7sP_7QcqOom
zh$7f=DnWT9qe_tP3g`x+gHSE*AA$>J`!WFs-`~{F&9T`yFobP-{<c(LF_QS*G}jax
zpXwRv)SFmtW@t*SVX|b-RqEGE|Ah@FIvgkb<7}sM+mFuNJg2nOZb)FblK}97){6A8
zIY94^B>2*ay(?mQ2%Z?Jq^W7av0rDZ^xV7uZ==MWJ#bDtSl@obPp%ss!&r26*KXQo
zxE={~_qa?~np-nvd+^Ii4i?G@4d=|2oI79w4$a&+ij%8#wKe`ZW74t6!0wloaK6Gn
zqp0_SwD$IwT~*Jv4B4(EZ!}q3h&dOngM{z5J~3Lo4%9o=MSrB{PPqqs5B?l^h~qzg
z`sdJtaN&1qzy5&yjO7FF@OXKvwFvDb|KI(1f^5gIH2>j~hnlEh>^*$djXRIb0~hL+
zop(=_`KsadFXUw9F(s8oQ3V5cl&9<S--G|1vhA@=`&aQ&uG0UJ4ViqIn;_827B2WH
zQP|#uO@N)<GngMoX?W(VBJLGQQ<M(oCsNo%h7~L16|E;&9QkX=bCXQ;ZoC;8gWje(
z%+gw-h}XepLfjRz63o$6!v7Xsm$Uy9xf8Q(^%YswlG<>YcLj{7N?Glqe`s<ji95yg
z|A#cylq~t3Dg}t~mTm5he+fH+?G^FS$JHe~S8WG;jUIcfM9<Lu)>Onnpxx}0=GHgZ
zx(vs>xU0U4rM9%4myM*|6&mtbGMPZxzCqer`-%}Su5RUbAuRLkQy>>(Ngf4y$HQn#
zOo*(sTDG+jEHR>nG9m#3AgC{&=r8l^JtZJotv~Cn${)|vqYxEm;Rz#Slkjb=n+6(H
z{UNC7dXtH=9E^|%k3!A`8~=u_9_EkUmknq$nlbp@W!-G9(-IXP?&|8e8lOrNqN0dQ
z{zj?6=Lk|<G&S;Ia8chuKyF8+#)UJ8b*q+9Oo<P{RM4)jJiExfRhFgx&|gdIlB(;u
zbwL?RcZz`eWapHs0hf*QnLN9{DSsencj9pxBcSaeAi+^}i11uLz&=J&HGL^Vq|?{S
zxo#KrF})oW8F^jFnsNC-d|dd@o^9;y!zBe+aB`rtftPDbOHfM-2R>k3L_@8d9Er%5
zJF0~fRZ)nC9H|HJ0?(Y??2po*8kfcx5w7N=0e<IMPni^6eFEhbm*oS=ozf-h3jgJ^
z0W4Y--Hboo_}iHS?J<mDy*D|u^gF1qFe&baT-UC#*JZKf<x(@x&g}!~y<vjO;Fi9o
zOK2Rr&M|Iu;KCk;C}iyGeK4)k>tSJ$Uox&i2(XG`rZYGS<K?XA{9^~3`Y2}Al!akV
z=g;}_u?Gh%M!-`ir5KlO#f%8GGCZ!7aqeekmX?sRzbgJIvvPLV7qm6~n2m)6Krc|&
zga0HHCK2JZKzNx*-Rg&Wq)N{bw$p(?fD!Mv)pT+is~2wtGpq_Cqp}oOa?zan)^u!u
zjITw}+E<BP77DIYW%cKrlIr+<9?2udJ|KUZu21~A@cck#&m<+qIxuCjcuzyGSrew8
zD7!WD8O(htJpGEdf?`3ki5KY05&gd`0g@IU)h(h}69^k8eJAskPD_8AeR~o<fh;T&
zk$_|nmFE^}%w)}xKSv*=IIcv#K7Yw*YeShb_qyNItC0vGJmiGQ!}63LhoRMP+f;tD
zYtPi`&`ChiqM^)Q0lUg_$>=lry9&2i$O^gD7-nPj<}(|8h|&|kpJFtBuBYV)8uOYT
z15nJqHq`i9^FAd&cAX4CA~bv$bg^EuB41g2`xwM9QFIlZAtA5yA2e;;2&^Z?Ta;6u
zOTzL)vsEqp=9{pNBlA;y<64hDbEacH+lq=}iN}`O7>h<`(R-r-NjVtqD(B?}1Go%|
zsOA3<Uisnqp@UYN#J_}Bw73wHSASOH|JWNBll+xFU3-h#t=Cc6(inzwMTE0(e~(#U
zwvT()iW47!7qIvOul7pC@WSKVN8i!)RDHWA?z^)6n(-^<?>>WUR3unnPkzPRq_?@D
zQ3{ZyW=vgU8szGzQ6wIqmgdO@@0n5S9_e*UFJ%Dz;7gnk(#N4%2M4jSckc|V6s&{j
zA}tdzC#&dMF%mY<JId{}wAxs`(a_1JC}Tt)mX=qCf%ZKm42}zB(ySQlA2wdGS!#t+
zM9(1C2h_N}A|m(3uDhhNe*`jWdtD!I+P*#Bq^vsZE;;@?0e{-Dmy*Wd+eYV^G+B$%
zae|$o+j!<*|5`&1QnO||tEjy{A4Wk3$XdRMpSx|mJ1`;ywAwm;xyEQ+Gi5Ppd}=p{
z_&4(Mci;Bf)GfT$s%qz9DKnMd4U~v-Y_ss9F%{jCzFnA44wlp2g<QKO%uq|3;K&Ps
z0x_gQ2-HDw74E+Tlo4Ll&=gS00|w9j{v5c4VJ4NHzGu0zjh^dvu`oI5pvpVgJ{hSA
z$6`Ph9ziGHHfa8;yM2^6i3C^6UBY*8KxD()dfsXM>Uth^6+7n|JbNoM{~-BOOoqWc
z(b#Zrw@*?t+3wD=vahs_Ky$q;^NgE4L#A)_VqUxq%zOj8t%h;5;(%@^Gkz7@O=V~-
z)^K$6dsykl15qj&#O&I_T1eiD%wbH^6F#aKdJ?gLTBzMjr^;efJNW8uis++()AN4v
z{m!!sI4ysHD-^@eW_{=~<Xt9Zu$nv#Z;7wB&EXP%5rDYW`-~JHAFyX9S^-8`S1o`>
zORrgOOl_uyRM^9f;-B%7EpU}e4ffs@!Ex8Jm(<RH@!T}XqdD?c3{!Gr3$F*hn4vu$
zZp2N<fCB#;7V9Ke^Mc@Hze(2;Ia?k%EoqOgFXKf_6XQ(rOJNvs9itvO834Z@^wYv8
zWkA2@oUL0SHsiqrpI7J`+ZxYlFBlja#RjlSYYoakPN<s$2~gf_W?h_n8Zh1anvdNP
z8$dZp%B5LGg}&9eEuV-ICkl6FeXqZ}v>#cw>pTx<0z)!1yr^j53=CIjebH$4bMl-!
zRjK#7!3}FZ#2}@^#PT|^Sd&)mBvm>Af+_j|^Qd%MbSyBMV!IHMfsapVkLZe|Jq$fN
zq6)YtX3#X{Q^Hr#8BB0Q;V(YWfcLYL;3(-;-3!7F6TW)hFYP7`oYlmHOJCYd_=prf
zOLtsmiaWu)$%%lE_9m5ss18WBbXVlt#1eqcrvtrGGRsJ}gPCWn-OYS0IhnWLLx!D?
z)ey?$p_hTqc0T=MVF;Q_&f42;rfWfS+UXVwz}vIc`P$w#DF})%YnJtKB**KKd$#^M
z;G~9iq-$J4vpW|cJh`ek!s*mEWoh5oe}!Hpag09TJ?JyV7Y3!6?81*@)G@`Hin^8?
zy@6GUGn_+93rl_6=DjCh8srn!+^1=)TMNWGrbF`gcQEo(!Ee1GA-BjIT~26Ykyt$b
zK}?J35XUgj0=1XST7bucr;kFkIG%(dVvr+(A8wzq#Iie~fcuUXD4=-NRd-*B3t1>5
zI7ZfwXIk%&cbkx$IM&?zCeEFgC;!uX;%+|SSIFJtlaJ8EzKvcs5~UQ0h2E)2O3jT=
zgv#%^&3*$NsBr<Y1*%mZ>yfIdfw43Q)iUs0y8sypsnR}PB^D6?k0Elymg>SKm}k&O
zi0|zrrD!gc0uJe9@j08J+9l})IGD(EbupfKZ;t~22VVk8!O6zjq~Aw~mmO_jUL&F9
z_!?xTkrh>`AlR$Cy);8fA)@VU^W~PF`Fx#V+3p{d^(HBC$H5)(VX>cCgismwWj5Dz
zyEZ@zJ__I&9VuN;QL-q~UKS?H@x;?&5=5u0<C}GGsu5U>;_~b&#XdXHrVUcpj$9#@
z1~@F8Eyzbvnpg5ob8@`y@7LncUKkm{G0f31C@(8dY=k>ecSF)JPu#ahIkitbi;@z)
z$_mQe7sg^R5gD>G9VBREsB@lNy)|p-6t%n+u$jNI9UIU8*c<Yp{`d%1hTRy6A|os_
zc;U?}>SZu*+x#>)Qo-I^lWYnP%5$cEUjJr@d|3X&8S2a@`MXXqHOF`a4b7d?GC{I}
zpG<L=*ccG2?zy6-OJ~!b-_a+|0H!NUNkh;@SzqxyW;SV+Q8Q%McaofkqeB|SJ9o>V
zm+B;+Zob?LY08qa&&#{Gyv*q7H+P>xB1K<bvVSps0f^in0kF!lQSY%K{grE)6eKtI
zEDIzfxd=oVgak(nq?FP?86{&twix2^+}L-eYh1L|MUQ7qyY?492OHg<NsL9Mv!%h!
zoGPmD0D_5OuS6VCvbQSnfmi_Rn4f85-JZSWR2!}7gQH#9C;i>n;Y!$k>AVq0qos0l
zf@fYsZx-O66R`EGhyc+APFB?)Zp9gUJdzvxFKi#a@%&i`9Dlk@|9&j%i+T4NCXTzj
z{5?qoZ|iSc8!ucUn~5!PF>%@UcC*mhjG5#YVzM^e@>N|@!BNzply8+@Td)n*@UuOX
zeJ!7S&Zx;q>Hzw}w#%S^2ch0zd&tqyd$!3y6t#I|uym0allchlPWH<L!}+75x|ZLg
z_W>;USb$RO=pv_CG21n&VL~-6R<XO`Z>l9^J{)lB>{DGO146T%1LiCDldmJ<VMkFd
zR>NG~WdZ5>+}|~Vk)^=#yh}4Eo;v?1mK1%UO_(yH221D<Mtx=hU_^u<cWf_hpZmy-
z>o#o@Z$eTMMKK{a2m9&4k+w$>#g{xe#&232rXb3Gh~n4JyWzMX>jh+Rmu!D}Z^eFA
z7<peN!O<Z52wvv&?*YuuY4|B0UoR?#_&qI+oTYiaLWEQ*uDhc9M0}UOIAM+xf~Bu5
zc_rR!C*U+@cdt@=eYURkdIA|z3woZf3?`Nu&kYOPPq2T#NEs%-pa%jy+1V)Jrx0su
zrkzTv?wrQ0DU&*RI6HxOK;;~9KS;V{ypqdYz(7Sl2Vu63fkEtM`}S9%k`U+I!6-~9
z5+;TLAXV)miilH2)HI0R2{#9+_xzC0zy)AoG5T$~<C~qVfhkj`(MC7O_)vLOLO$03
zmS0<oG}J#et~v;DaQZ1`#^OkqYT|eFBz&z~gH=`3Gbwj&7784%5$sVK($;;9)qdo~
zt^}+@;i-7)2aV7f)Oo0;Q2Z3$F$KT1j=+5m9*MV|eos<%{MOT*4V)s6H&+Tx=(XVL
z*W*f<HE?mW9Vz;3Ji`S)HiJ+pJSFWu!aE4;Q&{662LrjqqygyWmsMBKJ|2J=upFYM
z#M<cEo9*KZiXmOjHsargo3amw_qaqU?$Rx;-|cKujTt4U!@tGg9HyNvL*<&gOTV4i
zwg23qeFMv9Rqc5tDKcZUQOPXgu<VcDC=5;KbGz`?j__!Dt~kakU1gan!eGRa81>2J
z5^lbb*)P7lu|f6H5~f*hWY{87YCcB23=WWF9z_l>%*@~eK2A;^wB4H~4Z<@Yn|gqH
z$2tdW8G09#{20PK+`%jCQvT!QrIud*A)j8Ei5%JuhK1+%OxQKx>ZAHlzM-X&2Pg-l
zP51SnukT=XkftzQIFsVVMzT}BMb`%<J<9OV@<%pj8)Q4KyEA4CGAp>Hvl%cS_eY!$
zMEM=k9`D$PQtq){wHcESr%N1eRr0=haz;?uYBR7>CKbBxpeiFX$cycR4-rV_@;PP`
zv{}umU@45fGJ`^)kCL^x65f>+XBC414!ZTv$fnHrQzP;lB)X-D)Z(HFs{`Y|veEaH
zoP53aGQS*F>py-Z`-YWYT9rvsuwW1CVJO9g{%wz_eF5u9a)z_KJ2z`c^OkyaOHD+h
zrd~8}(~A}lfi`r@2^-)pbzV`kgE?h~=T;#1^>ho;uy2RdHg8D58GRJuxSJNb!`p=O
zkTm9}_*Z~P1?FV0cO@*$@<Zm9-b2S&srp8EZpKdgxS*WAdv4|aNyIunzmYW752oCr
zGJMF|0aMsk3J}W;KZ4OJt4K}r*i<J|#QsGiyr%Izu3Dkn`Y*9=r%Wr$86D0Hr=6Eu
zKLIK5T#54d7_43<i&}@9n|BtE?qf`BCCjIu;$shShHc?MqW5R*C-6WHnc3oZ+60mK
zc=#k?2%<9s*V$i9T9oHQF?A?05Y%yB0B+j8Odqi(E8^QJ8OFxgrl|w6pQ2LXsAPB@
z!bGo9H%gBY^|nTX#%yF8oU;3BMXGP}pfC9H+0Cy__KzkeSwn%VUNuqSaW70y+MO+L
ai4fAvg`YF$c+eVUfRdb=EL7Sg;Qs)RDV5j&

literal 0
HcmV?d00001

diff --git a/doc/assistant/nautilusmenu.png b/doc/assistant/nautilusmenu.png
new file mode 100644
index 0000000000000000000000000000000000000000..d7926e34f2bf0c72b4efe304a3986cb590f7ca16
GIT binary patch
literal 59867
zcmZsC1yo$i*5<(-LeSs=f(LhZ0wK6-2*HB8ySux)ySuwI?oMzE?l7JE=G}j0&8*dZ
zy1Q1NQ&rpdu5Sm+$w;6e;voV6fFk)tQ~>}WZ2<tH7akHk()9<a8vKD^^+g>#h}!q}
z4G~X^iVq%yvy=QL2Dc7{jX^=We&XT}9{OM>re-H%X>M*{VF!rV80gs<{3LNSu`?!-
zko+d6>Wzv603?8<sF0G=@=3a*7N!LLU}k$etRum+D+aU)soJ}$&>v7(SpADXLMaAP
zawwSgzJ&z`2UFnblLs?Z-+ezP#Nr_hAra#yAXp_Fj9+tqTh!;H-uM0v>_2f?TUt0e
z7<uqqjg3uA_{w9#z(YfN3zDS3V~;@o^DW9ijN~17P+jH!`Z-0iSbjIHOk?08uHhj>
zFZ2$`;=wANFb{zQPT3`6+=wDU92C?s(~wHqf;Yt3f(P5%d%q9-^l)1&qq5-1sorBE
zEW>_2o*83Bvi)kwupv&6s++_>Pkn23_xtK0;6zqFPMY2|Dos>AFSM4HM*oW(H29Vf
zXmj5LHV%e`Qr}3a^1LrC;i4S&UegW9R3SMBw~99dSLaLWAJU(p)aeqGXxuv-`J%{!
z^^)YMu5WI?wmB2VYm!qzf}bMh)9`JyWXhNknM^V!A>o7n<b!584-2^v1gs#$5H0P4
zTZbs=RD^(1V@yWmm$v(Oa>-!P?afU&6$&93WP}hwA5x*{Ec2Nf1<c`~?t{E5-5aX6
ztIjz+09x`pZh=B^5>)<l2+!TwPXmJ}as+@5dvs~3K312~TW}~STo3of3&I;(j0F6Q
zFO%%X>XI>#Kn$t3kI%EPzwnfoKEiuo_7@w5&C}WG*jOQVbZm06tYi%G*}TZz7Oy)7
z$-fkIcq$`@0oWVnmlH7fuDj~;lY~NX2I*>SnGd^BfGo-k10y3y!RsL=0<aV*(d>GQ
zJlWXPxZ0t0Glt2hkjOQQ`H)6seUT$K)~qih?}t}cQp=N5VylDj*TZGWOdU6b0x~T{
zJ=vI<_iUO0ubrl|Cb-~%lz-<}`An<McYubermo5Kt+3^_{a(#0XPRZ&7{Mf&33<nc
zD{PTfI_ON%WtLR@zca0z)*glNV`5=a$Cm`KX2FXaBKN+x(Au(U2HtsIlhmRS+U(5N
zN1f@7iMX-~fVuU*iQNd2QsKz*s%fZ(G|Xt62$v)LqWo64=5fs_rfMjuPMz3Wd_@;i
zqd+idU)cNc-z5e-l`T8QgocDDqnHSyGq7hJG$^=d*@XTjKl+zRjy%v~oBK}#b4j=#
z(zFOwI2)=32gD}TF)?SyBhr!Qx&QOeHjvb>4F%YerZ1~iuu3<r!^^Ok61q?!{Xeq*
z^QXVu<R}73$$vL7=ynpx(v%vzMM|CXwAi2kfL=xo6EZRnchImkL7{=TWfmEDdO5Hn
z)Scd`e|V7!=^JZNhh@vM)2ZlT9P3@9eNq=U&$lLUbg<Dc2+qy%|F66>tQooU=UJMV
z%W$Mt;S`qY309)#v@;}q+s4Z-P0MYMjrC=j$$$h}`uoaI!bd*8#{`QSSYB5;3}8-8
zM*++@%tZDgh)<Y^`3lsLgSiXUdFj}P^u;jsX$01s1jS0f^z^(DasR!oz+f)EZ+axn
zf<YPWUJ>`Z+*;DKx%$+{n9G{4iS)Neb1Qv)eO)t>`O~9`46Q9KIhX&lR1@{#Um!66
z#Z*up^Hc1|=m<F+Dgom&Rkob5o}S*XUm^d;JjR*IMte#5@mxx1Bb}2W(-x-q3d`RS
zMM<-j=*d`9_N)0EsqTB;PNl~kPnOv|PN1<v`weSREUm!2{)dp)<Ct|Q*Xm3_Nl}$r
zu1VKr47uccX!-po1>At8Wp#aA@i)Wu39X-`HMO+{)mF&8b_<c>e}&*5E}-0k??i+$
z)ijlEg@q4*;QNTuYp0=TM;kJoY^vhA{Nbi2;g&dZ(5QAviymiCKKQ??bAUf-lwWUh
zFsh7vx||#$EjHJqD)D85XU<XVW`qoE>i%PJIta?_%SpuKmE^63EOaW`6jb;)TKBZf
z)8(?LMiz&L<|o$Y2e9?^K*W%8O6ti?O?hha`HYN2|C&ynRFQvG=&%+W8!M>)6F=e0
zy<3NOqrWu$R~IW{FPkdI@37>3`9G4C_VzI*vz&;?DdjN_w@*Sw@c(6Kkiq!y@a@fE
z-;e4%1?nBg4*rA0Xn*1C%*eMJe1r&88EM(}qN=WqN?Vbgi~q-N5{_zojK6$v3l_~e
zM%eO?_QUCnA*YW1LO?(;GD^#wVaR+j^!sw4UlD97{Zana-ocvp<lcI?SHIJyMD8rj
z!G;&UXDyeH#r1P1RpZn}R!_jc@~y8f=>rY8>`IDYx_FRC78LT$VSpM4HFG5*b}yWy
zc@h1$<(^-wa|aiK;IP>LOWz~!xe+`$Xb1o=Ts(K`-P|P6dt3p8>x?iQ7#E!nLQ#ag
zJWehSf3A-<4|mncGR%1zAiG|DT`>`12+_)!fRm-hT5;Z@s*nGbhw>ZsL+Ql0uQfHy
z8M{AKRa8QxMbo+M9jYA5rmB9hfAMjOdCZ$|0=}QQUU{yxp#u>_k;MFF&;S9Cb<*fA
zWLH_TZQrLKYff@{|MCt0s5XWi*yPk9rEhlMrwGvFB|;mtcFyPBT8@{9R9rM;kJ#ai
zIOnOtuMDubcXD=ivA;fAtk#z}kC5hNokl$5VcFQV;nJet@9}4$lqJk>+(>??s1w#8
zBT`!Y*Wx8SmO+0;1K6y4euj(pZdqBZ$w-5JAE1z#SGCks8Tpps&eNoY3byXBwD3Mo
z&z$uRywdnm^ogB(_Im;=Z=~MaR?Tkwp3>Kx&C)UqTE+NiG-m($U!H_`i_T5Xv#oU@
z(&))vq*o6J&WMc`TMQs0uaI9-cGs%;+M*>AqK(@{PlMxTF?W!f?dJevSx#GzsBw;x
z%G8~Zm@`aZuio=oV?}?-e{>hDB6OwR%%=GKc;Nv=v{^<rPY(_~*3W0{D=j<=Q4bfn
zgY`RlKUIpAjV3ao0o26Nor^fB-Q+9E-X{qwE-fXC=>G;4hG3Vp=G9Y@9j{V4$G`3|
zOpSIubh5i!Y%Tzi5ND^$K@=}#e{rc!p9lp+i%7_0+TSk<0ZmR1W}WL$&06#{jsM*$
zTa*fyZ*V@;OBR?^#N2I>9<UQ`N$zzhMT5nW#C#r)tiCx#co$kSO<h}7Tm%-stK_d&
zFNXAT528j9aDMgqf*sd?oa;(;*|olv27<Ug!C+)2w{U6BQ}&(SGr8Tt=2UmBZ)qu#
zSTx)AhYwsSqr1o-SP6`_mXp-)ql9{!wI+s!rr5TH{%fX`(8_IKF>XogWa=GNs4%Z5
zu2n;F04hYrG8JB_d>doYIPu(UeJH?1@*o>sUMfH41E9ApWPtmx9uCyJZ{eEw%_H<~
zEUadk)^`%$ts^?aNr?vQbMx8LL`#Lcy!wAFn=yV}+1}osLUG*S&eXB&^f-aGdDi^M
z1OaN`t>*RNW&Sl@BCvUMvfku0Ha;%@ubdYVRn4=#9o?R;z`($?yWB7{F){slSFGgn
z`uwoH{Ucj$2zulvGc9dthx-#dRR-9LEG;fV!@y+EGyQ9%d<^obXvoOOK7alO4xV;x
zpdz=g9(ajB0|NuY!PdP<pbS1*Iyxnqcx7c}*a3YrGcyyD!?UyX4tLl85e5z7auZhE
zUPdG&B>Kcsl~T!=Jh;1TB4Tj{@|baKM1RugAcU<8r-p_Gyzqh!4DX3vhoTI+i7hKp
zQgoWS|H^?mnY#)=BB_u&b<hG^W}Dk!X2!0mN)(cl<a89<9PnG3_n@BZzh<a`a5O{^
z959O_!LgnFjhnp%6R^Mm^}C=1#Eu{RAqlo@d@k33S5{Wmf*akx(aqbp%$uo45Wh83
z{eJb*$$%^kz3j@fYgKt>lxbKk<ToczyT;G%RVlC32c_-~FN0Gn+N}<2H3mqwvzy(%
zOvs^c`fL~qac&U3jC=9aYx?+7;kIlat&deYUS8h=_jX%j3>|Mb4`^{mV{L-E5DO`T
zulb4X8ZMm(wu@F3Z96;@8YDk=_#w|;r%r=Q3cpMiVAV<5ELzEoM|}99NB(`Mf%n!1
zt#<mUlT;{GWs+ieD?mi%{5V8!ajn%cI_n#)aqMp^b3ArmlbhgGQI>|Q*wN#Huu{v{
zIuB;q=K~Hm$-(?WRr-_lalcfBVjXvW-HZL(Sh$4wiN|K!eVKIb_~-|RhMYi?^-cuY
zgQ$2UiVB{aGUnq1X$seVts?6R3L!0pAUq3r(d`>r-$1d(uJ=+bWb7p?RbUgyNyD2r
zvu)Xkd{}<!{qnL~=D4G9x5jn$c@sJ5Ud;I7_VfM>@ZCJ3t{r_)qHDNhnog^s`q%#S
ztb&;B{?^3}(mqj%w7|<sI*%i_<5^hADh1~CoNW^V9qss5Z=gg3!4lP|6f93_i?mwv
zQ>ya~3d2|ulm0;1hghSs_1lF7vkuw``;+;(<DOtPUpTZ|griH-RqwD`e6#0AdC}%p
zfAf=&jd^$Oz=UKjYydn3FV6sr>65QO|EtiEe&@Ni-hv}Kz{$;Ru~hSkmzMyrv9U=@
zOB)#(*>nG+8E%U{GUiE%qUOL_Dc7q$>)m=Vi>klk4Mg25_dTD}ugW*r>VH)YJ0Pz8
ztkY=_9~Ug&AL7)z)M)f1G1~FV`%~ONXZy_t<vC1Ka?%IQ!moMQ;+%wM$0RA2VyhA?
zKY&dYLlaewP@g~!v$od5TkqEgi{~5xnouG_%X#FueXU!Bl&ibBTz76xj<$7A-;z~v
zq{m-etC+dnm0$LJTRAd@v1M={r}-KO+%a)Cs}J{K;<tNoWXiIk!qpf3OlH8|@dF@p
zx=acmhJ3+T$`Byyp!BUXSt+WM)@<g&dxsx}1X*BVRS%swMiC9`t1T^Uh0Hxm$-Y{a
z($bx!pPTc}jzoS)iO=YJ_5LG5mx{OT=FlQ3F_P;)nTc{pWJpLJt-r@=AYMK81{@Sn
zwoEKe&$rNk>6qt0=jnCrw!`$+rWE{Cb;?!Q{LTT(C!Qfcqiz-ro5SwrKF<`c%pqqC
z%8AzpG}(`E%FW|s2ei9Zp;cu|pO^uw+Bwu2;<ftrP=v@=T-@F<b(Ysfo2cnH^H=k$
zGWFW)ljiHSXd*WPU=R5yO)HOTY?$c}CQPxT2Vbnq&mFi7aWgV(0*&|1l4jSNk8`9E
z_>oZ#k}iRAhAFkxA5ew)qOZ>u@RifyMZeN#|M2Ium{Aq^Q4oT)y_-3f{IX?JEu0pY
z01a#-egf2z{v^MAmUh}kJgsrl+gT48O>~b}7K)R2<t;O<-J8C+3B~v(@tJS|1-u9H
z1KPd6dl3Fg2}EHTPU?z?4-V{(8lG|5X%;Xu25jCI6s(D#Jlo7~Jt-^xfIV26nfEI-
zcd%9iNXixPok9Ya@^J$O@2}yj5W%m5UxZy#Nk+lL73(Us5k~eY$CU5vU%J%eJUu>?
z5TFN%&%Bp9ShC%Jyg5b#aOl$tIgFi1kpMZVOo4HEseZR;n0E6CLl^`u+Y@NYhR<tu
z)U;PqYlb7F&J%MVG6^1!BbAFr%qfI)`2vr3>MQUGHuov)P8{3@Wo=(XfUdCcWCX4s
z9%~C;diI(x>a~X7@B}u?{dGhCz%oz_?;%iy=WrV#9q}dxyGyV~abynIN~f6;yy`dg
zMivvRz9VjL+*b+wvpK!pti|%gE&JPe+lgTZyMzxt2wPJaBCClRWOsg3ABuxR6;h!~
z+zR;Ca!k0mxGt-wBrQJiw%9H)RKWpXYR<9am0cW;<YyA(9sm-R)FyUW3j)r!I^m3)
zgj#q29ufF%_oZ<O3CI2ZrV+fK_d;lC0xuz4tD^2IQer0LnAC896j?TF3@l+dRM}$P
zmGAj$ds|Lw%?Y_!T<PxJ$c#skt&z9C;zRA%`rg8@Lmq+hlN|;DW6@uH+;^?6zc2tG
zpTFwtg&Q<CKG@xSUUpu1r#N~B0NHLTcKQ_g^2)r;<dT{~(KhH2pX={cA$$}Pl-(&u
zqW7{i-g_Glf4W|tBiz&ZC{~k}&eMTHz(}E+5KA_GaebTTh%4YaT&epitM1{gg!6iB
zUFMoez1C(<?c>zcp{l$jub`bpwO+k<+HJ_+%k$LAp=g0j#Ifa6OiHhdoyeeRD?kV&
zWOm?PJuHBCPV<+OsRK0wFCFpyOrdy886@!7gJJzlwA9ola>${94Z3%XmSa=u6f&V!
z8R?S_%d6!(DttxysHaVl3k>S1MuYp2XBf9W&va(rTos9T2Cf?t-!6AXd<n&u)ovU@
zn|C@3I&9N<8n$F}Q7CR%=$s+FZ<?|q;fk4Lau!#bEBiz@^@edAGLtU0vVUsMzzSRx
zP{m9ZC83GM6fujDyvDw7@qBwdI52k62U~JB5AC-@a_ip^7*AZ{!f(2^duO2=$N+i3
zU3e;$jYiL2YlH2RA?5jC?85EVcmjR`fl5)(SI-tiF5n%>X44-$haQf?5p%z+Z!x|0
zXh0U$Lu&A{<yxMWz~$zM2XYqoAa&X}3LfLsTqETOy{M+Y^D(TqlkN9hIwy19rkagP
zkS27nJh{-{bk$GF`e}?k+P}To+%-<%Z}>n*3kX^`Saf=MutECv`c&#R>yR;Wvp=Tl
zc9?v1RyA6_A&;Fjo~0R&jpLCHDo&2i*G!yQ=^#fy0hhAG?u@M27dr2fBGz;+u~W$H
zk27FWUq=#X;D04?dCu=c5yH8LpP4}CSbwVflnJBUT>e##6>n8*mI!72_4H>Wy}a|%
zAs|OeRwETx&qCbGC`-wL|B+(28UJZ3(`6gf@n>Oj=@?Sr)wTaV!qDs_uy331T>8bN
zK(_D6RBn$<1J#%n*ZZ+7$k2~uSV|qHJzY6x_4Y1edGySbHKmcFKgHg-P(|f1JWT8U
zApl|qry}*}tLGa{-@r@YT<AvRDW6L~bi3nEB|B-)m9gCZ!MOC+qDcBTlNRL#6F{)Y
z2IR(RKK`)%-iL2Ip5+vD9#$p{LBdSK?NDT@^Bmj$URL)eUs<5jh>#aXG5{Qfg>Q~u
zf;8mhy!4V@AI89uSWsxFDfXz8+-{6Qy?E}tF;&Qq+NHt?qS6b!+9gaeYRve&^=iMg
zS&6&L--@KVYKJD5fF}y*WcJgk@m0$GNbyB$h0Z;>*-my*v4AR8A!HX0i;=rX#N&<2
zcKj2Eg+zrLr31R$GER#pXBk23+hjehX^Y##N*s&;M3(bt5XDY@e~In>#M|=~$dq<3
zXs_Z-$N$kHAi=r5e7I&BHH;CN#jtij4MD*(b2g{KyxRvRoHL4?x>>qF#dP*pIg4+F
z_nN8OfmOYRNYo>psfYR}fKwgO4$2z&q%7>J&*t%Xb`hSE2niT~Q%iY(?I&(kOG~cd
z`^a(@T5RE#2J-n<`$!?>RD4%QJ2aNT*yTS6>4m_@!;h{SkBOP(0ym}97Ba{r>dux&
zgk$*@OdsAs1C>5fpVL~j8vzSS7kFzWo|l5RS>FgIH1gv;=Izh^>QqXP3=NZ|0u{hy
zo|5WVq4*o=SOx6>zq^M@ICuW7ptL%f5Kv0^?d89FB^OdeNBvICc!A2gn$^$)e3_t$
z$={9F$K|*Da$@_yR?z%D#v^`ND$8AUEGQhpORKnA6bm;e`2N#s_R@9%m2kvX569=P
z<!!E(>up>%%M#ZM<Eb2)57!lAEpu6JrZ(C-4<)aqtq0==wU7X6my!49z<N^+#tDPW
zuk$TD?bT*SR!I6EL1PkKe9Ysiq(8@io=V+8x|^%&dVG#qg*Z>0)`>65!@F3o35ISn
zRHY8ig_*MH<qR2nzU0*L;<*Z@O25L<Q`_8s!#&*C*Wd^Qb`Ww86w-CIj1A6d$tn@@
z5r&z$gNWA)@SWaHA{1bVW)*o#%jx#fuN2iM$g<;OyOvSlE;pBSQFR3bJ!8&ZS1K(T
zOYYFe!_PR0<m0Uw2i9bVFfPXiG>|Sq1UbF&G5ESL8p+n2B6ML%m!*YmZ<k`%5;|w|
z>|_q-Jo36smc7yhOILQ>g@3xafUKa)jmDEyF57{x$BlRo1*M_6xjTn5g@>nUX#~i<
z<nIvxat|!@Un3mbE06Fnts5a`m!&DZ`ZwvWCg*LP^NT;6GK2bEECO)ONDcP9aUCtQ
zqq%gi<2wxux~aL_CQ8dK_aDo|H5<y1izNg;Ds9ew@_B8kyi+CSiyw+JFwIn!ZrW_K
zzp*g{aj)Ti!)3kQm;^EJ#t>)3hrPT!)RFLAuwvY*KoZy5=!PojhE99X8}#QhA8&Hq
zwqvi{Y5l}$m}Ix}{x;-Rx_MXbI>vI&Eg@2L&B3!*es5vFx)i8ch@t!;ub}K;87CCS
z1Bb~dzS6g$v}L~%Dx@bC_<7mA>o{HVh)g&?+&jSUWVTvUoHBw5kSM`yKV>TV;mth-
zEexl1Z(Zf-ztThv#~I8JCl)-S<@6?2v>g&;$`>i5y0wH-ce;!m)_CSAp7YYvJabSO
z+PU|)q2zA#r+Po!PS>&y#cS?Vl*qt2*smkEunt{lrSlwD<C!njoGmtWgd%{}l6H7p
zPGe>opYDGRQgjlYEUv^M0ls4oqu3GauD9&AU(7kg)rW)O&auzm93rSAoc}Bxcck^6
zlu>5v;nk7O%II10+@+mjvae)6&C;y$?nv5<td*i2g4+E8@7^n%>3(hY{HCCxMeiA`
z|B(EmjZMtU<1A4myKqSO66nV;z+KK?<KY2aE3&^7>iSLUXpflNL%BcaGhAEwJy7-e
zthT)k#O?q2{Ai`Wb8x%pT$s(+gL9iLCe_CF%D*ts^Q|m23JUNYcXBTaKge8vavJ$5
z@e#*2bAza>>En!|3{EFUfQ}7A>+6s8hN+$H@hCTzpYAWP%{H#_r6oe?98e;@1faP_
zTX&UQ$vl(h`d{~9jso`%-xTs)min*^XafX0k-HXwKPLw{;kF(E8sa1B^9uE=<+1qx
zA&oOufg$OF!}6br)AHo>o4y(8xY5~~nwk(qCb=XBm-jHZfE=b+G}z_EU`obdQqvDn
zC$_iIa*dDLEmt1`Gsi@pwZAL5n{mHaTVxR?+Pm1xdZipw54^QzF6~`7nG_EX!IGr-
z4mM-)lIc)Banl&z9er>va7&}_WOo@Y*1UN&xxu+=2(Jij+|Y;B;&teYdK^FPPmX+?
zYO!&>%N!}Iur*f-ZJek-ezLdKivP#~1-0W8fsjoILOGTnoSSc~)#X#^Eik`RFXt>1
z{Ag5DfAQc>>)F}Q{RFxLNZb>qKVDM4X3VDUPE*EQS9ZL~y-DGa@<h@E`za+%>l(nA
zT#JkBn7q$Z{;B5yJMd!%T!k6kxeRj}fF$!q&?WhekI=-+pE%mPM1Va(&oEvo_pS(A
zypB(russejpYF|DNNk|WMnjj$6C;VubUu&auD^{>WT9Vk=cw_Kx8nu(OfKcoTHe5V
z>!_Bnr&Bq8m+e7$ZojL7A9v99F64ZQIGNRXvFg=cr#vG)HByD~{efOja>MT{Py)lj
z-Tbp%GBv_)i8Ih*5(?O6-7i#j7x{L;CT4~fd(L`it`om(v1hTi&VSD7#mAHVMipNH
z#~1e5<q;G@V_gAy-nb!{CHrwX7t0fm`0zD%{{w<B8AYxJ?$qtU^i;O{`5|o~+RH|U
z2!T*m%?W2QJ9EvM;{F6|!pvjHLuywXll#ofNWlssUbH2f>GH(OS;jJ}l~rEFU}Fen
z;+K;!lP5H>rtii5ohw3eBQ-VVN2MhWG#qnXN-Pok{P+3{61ZQeGK0@wKs3g_tUE5J
zrKfwn#kNLa<L<eiX#u)7<B*lR(ujU{7Q1<z_C)RLLq>zRqUSoRlAR*Z)~o{`+z-H2
z=9FO0a_*JbeAG#3;Jgy*00u~JKgGwCMVWu8vtE<MPp*`dlr#nH8yFg<XH=dSWo3x?
zx}duAaTV~igbLPC$)qi^8uxS)m+6PIHPg&w^Egz5mK45y|ISrjnbe6eNxzPlXvtQ(
zr0WresO_*zT&j?pAwygN0T1ORT76f<^z@|~E;B|YIf8l8)lj7J*XrOgPI&U|xRi&n
zRiZmi1#ZkA+d+2ZB>N+zrw_urWFG{&n2on)X3`!j8Ya@4$BU6PIGUP^+ASC%FJOJ<
zQN-K4tK_i%IsBdSdrkzW`%6#LrcLZ?x$iTygd1@ny-O0=6a3htsw+R*8?!bw3+8si
zLuXBW@54vHLlOUbV~(==JcS+V+@*8w`%u9)`8rY@!%8mg&jLm|o%-Dayhibcr!Svv
zCYF_g)kOS~{ush7NAjh<>KdpoRA}!{r1RJx%_g`xpvmegF@0R8(l}(+*)>VM>$q8p
z9L|@;!eh{%cv?3kdsF*)c85MmKeimIQA_|^P-;DAQaX{04L(T_JGY1pK41&PFm%GR
zmWfj~5A$Td?QC`mA^lyHAVl)+oA6#R@k;>1Vbk?>%FbGAvXvsuTq$V({Mqbj7z!vK
z@n15PR;_KyF@<7vV!dBtxmf$rKi|9t1x-MP9aguQnN*@J(QCCYr+J%sxMv{o)?)Yo
ziQL=w;SSim2%piyc%pgV#mMl*trnu?EKnw+V}b)ESAbWZ1GyKs@JqdX{KoyKv5EDe
z#o?iYJBWy1&hIfgy*>P|c?5*-upx!?NAw1l5oxDU`Cj#1rVBvk|HT3XQE&K!TBc5-
zQ<Z~)10Ma&3bv62BT}2)4z|xNUMp4oK7i7~{eznVbF^fL)TG{?GsB!aChX=aCa=@l
z`Bm+12rrN5k5WcFjgjih8YUtrEVeW$L@{-Ub(LLkH=6@3decSx(GKis%j=%inSnHJ
zca7POg+s-{gVU;4sCzn~w~a(uS!=;wfR&23spJ{)MO{GI_)K7;Q`S9HM4|dcyv#Ax
zu~o}Kj8xNv*+je#evbp{1@X|)!|zBD+J~Z1DxJ&a;m_ovq@&Lrj_TRxC=jQ2=E@7)
zi>b(qFuS7lgqzjf0LxMjf{3QVMEktmT*>5hdOMM--6Lx8H(#w;w)nS6>|g3!xU16q
z4j(V`B<kY33>8$P<)@eRCI$E9A_}xX^zE{l{N>TRx*e+5!<YSqGU<?BGljB&fq^p;
z?IAdMwa12I8|wCt+bZ~|r5UZCFS^!xd<E#Mc5Bj{@6Xtf8g+)Lq!udPztVX4C-srO
zgU9<A@xnlHViUag=jhNuOGUue<M-s5(HXC^i6loAIlH9w1bsAwS8Dk@0%%Hmr8Vi#
z0mzd*<SDb@>)X<CncoeuLMm)?ktxkv_UG9eNUuWlr-=~~lQU4ha(+f?EF^ZO)Z&w-
zZ<+{%pp(-*I7(y4<eO=heUtZv%iy++E~4ReJVe!3&m`2Y8|$yD9m*5oxg!?P(IHi2
zMnAgqi6eTusrp3esKrmTSh4Q^apo$Ymmf4EW%|U^nhYhV;o;w)t20^|wUxZH{toRM
zd>_6K0vZSVo(BHbwJJJVqB0IG->0>%m__n_b>l;5pr!};(RAowvB_;|j4;q*ROwB*
z;HB|!+Vhs1R_`TnR{S`}q9Rjp_6EvG{`JAYrJ_*iZrJlo?N9uA3sZmf=??FTYco-2
z;s(jSoW`ij-pSz%Wp6K>LlqNjApKjJx{$gntSgV8NE^wVm4K3qrx7SgxpbQ$@(=5r
z>cr`4yt0&7b;F!iiZdD@>Oh1t?j67_AWZVEg*8}Ukb-&w!oxy%&|=W>8H`ZS*Y_5V
zfP3rI%0Ig){MsmN+P8E=a2fI+5g)BD!-8>M5I~K>>5~_QDISqsc~ZIEVO`in53{AJ
ze?|qUMk8oL=nsMmb<exPm|y3c2%+Etpt`!ew?<V5P>Rl~j_&ax%R94OiW~%>0Xbzi
zbHU7FeNXOsl2vt2nwE!V4Y;u9hhF)-mMA%X%{!qm%|&v7JJ?23J5Yom3Et{wmZm%o
zN9zFy6|?1sZpSwrovCl?4l$%7bC<5WCiWoY5w5navk<-O22zI4dJ&PNvYL(?+Dvr&
ze*!3m(-t!6*AUCmjTUU-PjgU#Urj}^dF5GOn&Af%G@eTVA?nc*$uo?BY7zi<Tdiss
z#=OcvImB$>lc)KvW6-$mCcGO@rzPtxXtpuX5!MTXlKpi1jjAq!Z6`U&^~L$fJF(-H
zK6S2M*0Xwut#1Pc=;?(sq-7nGW8ASct}fM=TiBSB&s@L({a@vo;|9~=-4adWYZR8<
znatFE(EJ)J6sMiXeq^z&Uyfj`!$(ia1S0MWS27Ftwc6ajH7KfpL_2p8iEm12IB4db
zXL{>NxwX=1*jv0j*{5~QnuFyoa)WsJ)*PXO=d&GsnK~L+kET*C#SRf;_vwe=;Z$;4
z9nTg!+B)$xZP3S2&j;(>Zd5Y!GMCo=)r*CRJ84W;p1b%YcwV}Po-+)V>!u>p19xE_
zY`1-e$i@@%z=lXEM72WCHwqlga{N`Tw(4WpNFsb5dPBRhMW%Yskg$*prk7K6GSbu|
zt#3qnvHM;btHvc-=380zzUY=D2TXdj;xR4uSCds49_cMkPYh_s3AQ%sSLvp`^S;qg
z8LqMGZ+8@EvKy|dbqqz(M<IfiZ)7;<fY(M(y$WBz<Q7@3{_Uy2qTk^!Ex&+T+Z_&~
zjE;RYGm{c{d)r*0*)Jx!J7AwQRKw2Hywsdwn8C*XbzS@Nk<7%VhT(b6wr@F<sq@AD
zYN9yL_4i#MoSW5tA1E~S&`vM=BQ;2B)K>AZQWc}3{tCW1B}&lqn^fCJII!~v05|ks
zGa$*y?HMt7QG;^EANyx71%!|1tM#qLGFKtZQ@<~=wpW=$ZIOo48qz}+lEwbIbK||K
z?>2TDL=n9kx_8~=6bGOgNz?VnZ@jgGL+d=?B1=K1`QFsF{>X&(tVH4)>srY%D>$!e
zHsVif*mJW+=+4+1Nxt286j#Xx-hIF#<e6n-cpcUWF06c<F3H@eMa@vyiA(PZDA(b%
z_>(j&SlruUmsx)Vnn~q<aD77u?(N4_B`kLPE#F}520jbi|Gx9Qvm9`~<s6*f*svcY
zCKeMHlZ`mksM|j{FUCsuKe3z#RoY{_A3mD(DnpUY#*SS;rQ2*1pT@ely)F&uiNGCY
z@EmS;>aRcX)4%?y3(7#a=+ty^$n8BI9eeCK#z&!u<1!LRdF_4ZAwcPj40d^l+)xj^
z?rbz%dQ7LRP_{W)3i%|G{^(JU-y3dfly1TM%Vhd2*_MNRR84Rk&5YyMOr;r_ER>kr
z3pfgbKB^_vfa5BTJlh>E6uq5CN#pI(?PcMyKSX`8|K_$kd#|m^;P$@ZLT+|8vou5z
zVly<kw&SD3iwoby$P0cWnQ8|{D?HVysg(eMO2nGy!E!vCcE_{%h)<@S>Ou|z0!nj=
z6(KMkYvEn5I@aaIbBJ{WM&C8L+-MjZN8&wscG|Q=HeRWYQVM)|HUN`r%6r3Hx?#ia
z^0D{H$8lknKlIh^15tLyPmi}sx9jX&j`!@y?o(xuT@&f8t|%YoN0on1)xSlgGuUY!
zk4f`w+1I!|UcU{Kb$o3~j&u9GCn{WEL<OWBuzSugnMw{X@V7eYZ=tk8Sqm&A+Dn66
zy7QVf2`PzM(wm;<$5DEQ@+~_-&$kNb=<v`rWkD^&45iROA&&0+08>>h^8|)zJEnAa
zxYc$w@ZHTTKiN|5xjM8znR*3-d8Z@kXkhSxZjrUrGRH5`<($6#?F0cz%ZUz1nylTy
zuvV575(<wE2)J%?Ipqe($+eIW5ZHg{b*!~)G&yLK(Y7V0sjt+`5BDXLi7(;VGTyt{
zMJ^jLk!v%A%Xu;vcCroi!Ut*~IVocaaM|6S1r>b(aJiUmK(DcR;yuqAJS;bX3k8gP
z&I{pb<GP?*7DFgOOGOJuB!0kccBLQ{0S<6Ux!h~xJ8%*n8O2jZlPL)D)Mg(J>8;tX
z@z7!3?K&l}zQuqN6D4_93Bf+%GavMC1uS32DBzz8*y7BF7F~F<F8ER#^3%k57dHTe
z|NcqKBiy9I?;08aXuTaeTG8>LfMx~#hi%DTVV_Pq70kS~uV0$x1ssTgYxuK_s3@;m
z#uy`_)n?z1s%Jk6v@`qt220$rMW%12;jgYKW{O?j@J=?`amLnQ10R5{pe^?WHw(9|
z4XBr#jS7ap``k0h4jbKfsAI2K`qJ{}v;lOdOGQbmzGoBOGc_vj32TTm+RR&#%9Z(g
zv}242sQ23-8TpEWcQ#Z*dQ^~G=o?*r{?NNp;AC$Id7il@U()64a+}+ku*(aH+iix_
zdWWUfx+O@&`-G(VeIY2;WieT;`BA6C?s0isBD3rm7WnwFyA;RrXSJGlcek4gq3I`m
zFE;ZQ<lri%;k+R2*1Ou#k^$&npwUlkJPv1ubf%|cv&1_17@Dfe@g+6)!PRqD6hXXi
zhhB~i<4f*mS)DKu-Djto4uqW90>{uQGBo)mC9I*AXJEwTssun%XCv+p>21uFHMOaN
zfXZmu?^wDs!N1C#UNl0&W+1lEq1N`NHHfR!jj*mghtHEx4l@IqBo>XnGgf8J=%7l5
zi2b%(e<$JFoKgY!B!=eQ##<UGUKNdvvDy%Erv-~WS{27GAc&*85cgyLuy;^IMC537
zV`xk!#j_M)#^8%z_?Nwx&_H7Bl1^SXgSolX>;2r$h>Z4B?KGG6j(>L6dCM-dCjM4q
z*B~AZ36xxpDsT6lNPR^3O}7t8041Dk>o91^Fy11Qfr?ECXZGSiRE&;M;`4cf&IUQ;
z(vE#0w#CPmN5Nyh;){-QocsROP)Uy2qv;697IETK5C-utJ^=z?tnD1#_BEnBhrc=G
zZqI#-`qQsgI43a=iu~?y!0T!aPF>fYMFuNN)arJ<8nK9hhJN>k#5?uEs$FgO*84j(
zf*b9kf{#1c*&ja^8;nE|bziHZ!fN}p7A8<1yAE-i?NM%+QzKp=xt*6crjTpHiZ4$7
zJX>t$p>mVXYaJR)`sPUi$HN1IvRbVlnK3qtp+l+ps%D+k*w;B2C<InyQG%w+zVVf{
zmZy_)bf`p+waT}kgO?PD^A6TyMz3#gZf{0=_cGqOP%YAn4C&2>Ach;G!!x-2D>Q-J
z#@bIK)jS!7U+YSfK?2WacfJZrDer;`VA}0xw4NJH8SBUTgEgpc3@Ao^iU?Y+k;rBK
z1KId%r~W~3)ZtF9ZZ=3hcRtBeusRy%NQ0BxBG5lLkH1#_U66{*V{9N5#ygarc3-rb
zvNsf(cxFDb&z&TRB=Epw`fsg$b}<Mqhg5P&{>Z_7{8&s$6NnP}tj9<>5<6>aTN}F`
zM&z|S@LW@FVE9;`vTAerVh#VebS-1!_3fp3U-g6k!*<LMG)GzfOv|BHOtInLHE_d{
zm|`uQt#}?e4+1$7)<GPJ_DH$%6eM`vn?fS^s=K74k0rnNc3tfM$QQ?BN;-Z$T>m7u
zY(XO?kGW=0zV7tO$3vSN>q!#YA0w3yx~qVTA!kCyK=kie_Xy^wY!puh8|oY^c{R1g
zlG0TbGj%pRlmI<)$?18_&1SLkS55O@$@1S3839B=9rfY;t55HP9flfP^dH^c-S=0L
zOG=Tyhl2~OVMb^<{QDqv`O>-amJ##*g!r5<1FuX4^81}faHXI(l|YDhU}#{HRQ?at
zI4Rn*)z;Yfc<^BuP^Cs^WV9gTkq!;{QD2t{IXCkVoPt5;JdnWW{D(p@VDK}!7$gkL
zgFm8w4#ePl@-@02!WJ9t>B$dDls3#PSJaX*-D@rf6M;FW^pM_8Vn5?Ad$x0E@}&x$
zrK{EGysNu<#>PZRMAfeYH0M>ccN<>$X(b`N!prL$YNaA?nb%Ye({OcgDJCX{p@DF5
zDB!xU_T)qw2qNMN=-q<!lFH|`GS-!mafm$oh<od1Z{YJ6?lZ}(r*?iSLC=1+nD+b}
zwaHlPz~FQ^Wjy<7JBH`ZA{lYFVV<2Ta6>KWp{u-Z#C$v<J`Z>0zu;?7h#qb(aq2iM
zz^{9Zy)rcP7fuL7?92tEK>{`3!eDimI)|59OJf~zl)TU@jnyHttOu0o6O-#%5{C_-
zv*+L8`AizK;)Ue=o*wCj3e;}0W3MFHSf58VxJ*Sz9k-ZMwlF0^sqmOU{0F$*KKB>6
zO`h-%aJy7eQw6yf3=h=THA#B67A*g{5F$UC!ie~ZLqs8;qS!%ewST&g{#Ug3V2VTJ
zZm`qiU2~gbZmBNXV1##36j@4dQ^_12P{dveE%Xi=e4trSls7p#+A3S=0f%~ug^MID
zmLsmaa!_5p^Fw?vjBw`2roO3(oV-kS`)1V8(9m+v-G9gFYpKmf5`XE0m!-T=v_kQ(
zFPZV*>1YG=5I8EVnzVo*0hg$yK-6aIV~sC&jC(?IU!BuriZO0ab5~&<@#n<4214Ug
zPR49{Q|>V3ehEmRle~K?w$3-=Vl=!t^et-_AP!DpiTae~aK19UkNfaw=W@-tq&s_G
z@AQmaQExNNUrG3Zki}%%Z)%DxTBm%xCWrsn^sF{!&Rr#|%)HFYxn6wmRs~LB?#-l;
zm``S^z6^{zrw>%zS0^{fuN(M05?wA_P$XC6`oI&y$q6i8E;SH-t_!9ZK?FS~r)bMd
zT9rBbS>CH<<lg14;is*ns`3wm<d^SnkJ7BqnOX4MOzvPQRTZ6ESao-P%8);ZUvDqn
zw7I@2_&2d0Ue3X(#(pdREE0g0u=;qswKitsV>zba($dg~lo^C5u&o?cDqaqo1@A)w
z|82mxtn{LhUyH|b$H=;U5YE-ve)1i8X#WUk^zQgz<^ap71KwO;_7`=C-1nvnd;@h&
z>hg9_i8gFbQIXnQ6hH07kIeY9jH87nvEeZe^lGs)uEIB)^PLG3oUUzWNaNB>xWG3$
z!zcS>=B_wj99lN!n4Ca&;(VIkAJ|T{>OhqBd5wixWM+{|xaS~_kpa$ayPfg3&S0YS
zr`wo#-tXeRSlel(9JVde8ix8~^07+Z!r^8J+gRbH8s!DLT%a!#9X1DhuCzwc&`jos
zc{iCBM9l4xrIE3Lsr%JC5??~Pn6x~Vls|E>%jo=ZWS>&@8rQ|<+U`BQ=A>c4d+w&}
z6p$W%z4p`;(6yibPu4IOw6&gMaO{}Tq%vG>M4NzYfAlnGvFruTCI(UM$3s19RJRXH
zJL-=1@5+1&4-hE-zZnhMsB-R8_}a?@@P>W`Y%WAnKF1zApPgf+;b<a{)U2dZw0C||
zocU)x{eBYSVv)oLaTssLnX@}rAaT?qgI3qQRg__7Y`H6_mGI?j+LfW$_0RvGjOwR)
zw1K&3=8bdW?8tHqYF|<W^>+q(bfGDM=^vjytu54-U6akJ{8VT1%GjaU=urN1(q}GQ
zt?E|_)zX@3m!hPckeaSKZ)&64!eH9(T4Cubp!>1aVnN)Zqho**2}m>dOHP<@J}j1b
zZD`>sQZuBJGN9oXz3Aa`;-Q4V`S8AvR#?DjTpG*=#*4LhmQtG1k&sW3mWAWmT(+ly
z_!48`f2@v+R7y8@`y)~~?5jD=y7TX=4e)*)r773n-Fxg_*TrGDi2KUgr3#qN<D`D$
zOdO53&E2PueBydck37uu;4E8he4B*hooAptlTl}UQR^XJ7E?>#(j7~)S7$xCJ7zg;
zx_3<l=|*bT-OPR>Ry-@j_i#7btBUm&GU34R<j!66yv2|ykGSt?#My(M=&&;WQ5=xQ
zz2nKC_11aG_eS)x2w&)x!c$|JGT0~LDXXf;sMp<sZ`t{_Hi2<%VY*Gb6M6O+Hn{A3
zo?g@lo58aXYq=XtM_W^da#|a+?Ele=hW<TA8Azj@z^?%`GG#=gMyK+%whSQoUh4w0
zB2v{JfR_+Q-{IuqUbIOu%wkl%l+!|&$<(>diigklCi#7=G>+Ev<ohoQE2573?S5B3
zyWCQyDGxzLkOxT(3cPj$aq}WLW2_fP0bDr<UW`wlFcB^h`*&Jp$IHfRh;{?St~r}t
zMc=w#X7R?q?hH%1ThW(qU!F}t5@2jDUOF?)&|6v_^n1=~@>s0S#BuDO3JuB<2YX07
z&HNvE654i2j1S~j%_r{O;*!f#gk;LfZ}vMoK$VG#?%R0Vtg9m*kE1JXAN@so{CQ_R
zV}98E$z3j?7+dOPvn)}X6g5wyeH%hV^5(q}(f}xAZS<M@rCf+eoD=w6z|WaX%KtD(
zPK$~JfHNKgC8yPx6H4p}Lg4!^Ge3+-7+?pAuJQ3N{D9NJ#<af7t~`|P*mKD!pQ@^^
z=6i}4CJW<ZPps-1T)EW~I|P6mFf}kY6r{UhYeO(-60UiIG-`&7bX^s<YNkq;u<Ya#
z14iuDM47L8QA*R8cuzR+udJ80=syz>OGJbGbnr^{eXrYW-z@O19ni2r(8(C0J7Y9T
zpznAu>yzi$6`9p$3f(N$%K6LF^EGu%*UQO$)=0U4V6OASN&Lx==HTGy@M?#?#hKUL
z+ACDT5Z&jk_byMj<EEt1lCS=jjqV+9!d&XZ%!#I$5jqiL6DpA9Sgb$v0TR_;bjJvw
zQQAR9xAmySeFH`P6xxp_I}JzXAdA#^?Oxs=zUHR73M$cKqU2U(4Nd$q3~hVIKMniH
z6GnGhlCMg?=2HVdu|_|qK>%8GnF2oc{{SND*LlEgM)gMq&KfUL=ymmU)bCloV&Tmi
z%{gac^)jM4R-PDrs1K)&*qM;A7)#~)OnI6jRebWQ5-Y=JMJ5oUplnE>`b8?-j60<P
z<HL%hB+p&rLRKSV1Yxn8a5TZ{(9Ngv*QZA9wsdQ6S?8nd8io2w2}<Dm)wj7zX)i%w
zGR{aoY6AV{r@j{2YcB6*36nli4Q0?kit=*J58&+8V(J`a?T^W--^0$ckNcw5e8r8c
zK6b<(WUIiVdMzDhC;eSD>Ui{c|E6jbK<PJMu`P#mVLs;%(ceMn(POI4uQL$mW~sGL
zt3sYg1iou4jVIhzIZVA@<}Em*;6SfE*t02xvgjKV>H2GyGTU=3jd!o_SPS-$Y=miz
z@|C1YM%1+wfhZiKg;+Jpcm-wUlzt9J2te|T>{0D;p(afNAWJgWyXz>wE11?c1Jvgi
zR*l?WG3Tb2)6Vqu7$)8gc<Cfanua9*?V&QIBRow{BS=f8rvr!XN`_ou+=sek#ioNv
z(=S!hVqQetiS4Jw8_mt%KTv_SK#4WZ_?T(~4jGjwUQm~JuNi^Pd(GCYAeKNI#w8)2
znRQy5ilHPZz`?thID<3F;~0qr-!+lQa*aD$TKOf&H)PYLk@%87GL$UT$GA=%=G0at
zY<!>{a+T7ZckkTN0ToZ+Uii6r5iN(0$MrjAfL@aL%Vo1oIxnFZQTyF<lhta>cwT|o
zpsemfb82*QI_n#@AR$P-me!v<sx}SDYRpG&FKz7t|Bp6abk4u&YI^mr&nt_ma#&x8
z%vtYVFnhTMJ=9&O7EYB`d5q4*K^ffF(uwpG7VdVDH+OX$7blK3$0OY=Do|ns52p5f
z!S+=LoZpWduMEqceM#puJJf&UV(uQ6oo=2z91ET-3X-M%`Rz-4mZ$8_Z>Lt;Q6FXS
zQpsI@t;zAf+s{BW|7|}D%rh3SZYjkT{@iIpfGR-~uc4+^=a*-@RQ4*;4zwK^&uy1^
z__{;rSZS`%?(wZvg8Kr=0icR;&o1R1#Jg<#gYECz%;wBjY(FmLyt0R)NK*RBd~VC}
zyR6v(Cm8#rHnZo3^E;X6?{<SEvPBucz`knBKrxBYE3@I5(Q(>x0~+}|LW}6<7g+ki
zA5P=yFujHzmp4zD7R$J}n47hFE9`5TZENMNpmjVZt3#6Plah-sE8gcl@nqp&XB(P8
z6z(oJ;52xkq%giM!muM2WT}^^weiwDVA@H*|7+N=->$y-^{m91Md0z}9vyo{fdfmx
z^1)*wZ=CY&M0?_fDWwe)Ri=ccI`#Fz<2I~a044(Vdopat(_kiO1u@--;f#$MVN_Sg
zU{!xA0cu_4dEV8uzK*7`d)#OKDb8snqLU&lQ%gk$QTlydy9$tX&`m7GasLpj;*|7U
zmD84^TDeX^5x`FuCzYSbpxaPikAlo<tWIhznVl!SddZimyWF1bzMp}b0Wl;)l9C3_
zA@5F?_+3u?mIYq$a2g*|*)F9%6d<wu`U(*_sN3YUe)56EPF38MI?_TH_u`fk?ObP|
znuE5KEH}qU+Eddpu2p$wy}K}5nf|Dj9pz_zEvHw&jXHHmjO4C?K@1ceDy~PI993Oa
z6(bv)*xV<`izE1O7z2a+y}g^;FElhG&b<7!R*gg>in1S;5Sw!3grgrpDIgKp{x%cC
z`crfqoQ1#XXglfKRkD79%AOn_)tm63a%=f%>n~sGcfo!N&0&+t#6o;`TaW*5x8V6s
z1NJXuOtN>Cfs;{00%h8Y^71lM29Y^-8~|1Hm)S-~OA(@mbf;O5em{nC<tr&h+R>`W
z#>z0krIqEwjZV+f3Y!(dOf0CZ5X4ZF<gB-6wU|7<<M~&FUPetGQ{>)*jj@&FP-#&I
zhXy+A2t74l*aC1fh<lx*t?BvRJh^<oX!D?`xpVIo%j?FAIW<>#`-u6Cy9%;bPuKE1
z-VA-KpPnEHVt_Fnm2S;C-!7%IUbANwNpsngmnd`G(6(92r341tQ$muGI<K?a@W@YV
zj*1VyinKZukSfa8mzPIGu`kR8G`Un${_Q<!ONdaU?R-^X=Sa#a%Gvf=ZPRkjFMG64
zN~s(?@PibS9}pLBaJX$?Z@@)zeO-;u85!y8|I{Bs<L`X|4<n3&!$B!Q3AIs^vk#m5
z-p8r8*b<Bm$PSz>{D4w!BcEA+f%!juh`u^=IaE><iJ$nI&;+>_c^LJ(wiT+SX|Api
zjOBRIVq&R6?5rKc?)bp#VkP#4Loo*@qO`STTwF^X{OM|cJGSR0NXm#^Uf{Cj4)%9E
zU&MWKeKBSf8EEMK+#Rn@I=QvKytmY`^cw>on-mq1tW!-Z#G3lmJv+9dfA$6oE<{#U
z)gR>&t)J@n;{Hk_|I{QZu99(JEp?xzV)8^ut*xx67%GRHQil7;Vn^|DWYv@NB!7MQ
zOR3pFjdG888XWcc0HG-80KKuFp9Y|hUdzEX4``t#*E%B#<b9l7c5WiO88R?OuT*ZJ
zr~V2e*f;q2{d!Xj!0q3Mi}~rYtjKp^wo=XJ@>`84a<DH~jtaH^oS4VOE!=7HTO=5Q
zI&QA6X&*mo5x(^8Dd9)jG$VeC>%5v?Cdm+L24Pa8X00u={mxReD?V@{&}8&;)_A!|
zMOm3JWCIOwy*&;4fKiH%)^hkDv6A{<EC70t>fn;bB1cy=sJ|4y7Z5}zkJnUqAW=-C
ztN>RwD0;`>Eb^5tN>6I1RTLHIhet-75@NO0)v1}$!T5@$?)7SM-Gn6)gl);ASneGN
zujcddH}flTfYXK7<Gu<VusZ3}qfbNvY7HmQ6NBt`ggE%XT6=w6i*&vMDqBOM?_k5T
z4{qw)oe%ee<3g(;r%GH`TQqY3>x$-@t;&1AihzNJz9rLcVY(+~aECfx>YtWJEP)Lf
zkB-+mqSjlp$PXB!YN9?Q?QOi-%gN#{;&_B;=IZ%a(~gE6Py4#55S!qRN2&Oj(OsZx
zMbS`2Noms5hvgzGmB`!Jrv#2{Y&m)KH?xnNDLjf0xb%S{CU0Y6@H>i%>=le*kBcD_
z`*36Ev*Yx4McSG1SuBKJDV%yW;<;N^oQ)Qg6zgrMK(VaCqS@-gpeLw<P>Vj$;znsy
zgx4cYgNLYKg(h)yBZK=Y^VBn1(7H*BKU09hB~6Q>5T{}`d|$cZZF;WswxQwdbme$y
z|00$WtU-Jt!t#g0b$YYEzyVLHGB_9aAx98aR8lzD-6dRS(4xb}ku2$Bw$GKdHh7~j
zI<Jsf*Os$rG#m|iEUU~0Nf|$t5uFkKMQ47;-8;we+PN?1;egnbbUBK>Rs#1w8uub2
zx!Pa%)aBm&(_;CzI)b%}MInrlUlYRK4*m+phdBqWkcTQOQ^!O58yFb0HgPUAi)grT
zr}io<QOi#W*V&Jjzybqh{O(cpcl%`Wwy-tOvuEx+4+Oar>5wzF{o9ng;r#w4cWN0y
z5|+B_ty6QAf%=18?6KbF3}W^g^D2m?_3A3-x{A3|n{!1<G+>6VwZhtR5v-xr`Zh4!
zA6(>0L@Fo{<>%!wUN9QNkAoXFB}0B&{V&emGOCVl+ZJ6wkf6bWTX1)GcY?dSyL*DW
zTX1)G_ux)&cXti;>f3vtbI-f&wD;q!R=-wbQB|{M%`s*lz4y^7go=uo;&t#UiI6+9
zUi`TZrymLtQ@K>}aBqL%ot2mxwV(6t1)*S?YcRAa`hS2K<NpRTF3<SYl=lNu)S#g;
zyl~ALcjK$;YBIC)huc=_zG-Hf*u+y|+-o5GthlH*{4>2S+o*ZId!CYUljB-`=#j1R
zl7SAYDJXbpyDm{Ki%6N8ol+$ZiO!=qxvC8S*<ar*`*uP*wyqVO)R(dTx(Tlf{ee96
z9e0ABqM^Rgz<1R5K}NQx2MmG)g;Cx-3oQ@O?^A-p^O)l6t8v?&H%2u`1ZA|iEZ&OK
zLu4*@Pj>gV4?Omc4B!J&l6i#U;#|$eRUs`Vd$|H3wfUTUwpOKEy^Ty+o-UrH(RXGG
z#?%P3W!V~=;Ia5x#NgvkU$RN~zmz)=C$FsbueDuT_q2fQ0eHv^NqR7$FM|pP`I&?;
zk6?;V<~xU|1b{DHb7+;3Tt5`GXc@!Xp6TY!Yd@PAnbX@TP1%Da_+PY&=8HB%k!kuB
z70fc|Wsw2+dTa&2c_hI>5rch}4o6pfD=d7Mgmvm|U*miyNB14q*VZftoH)0^L;4~8
zdjo<E{0%U_a$3({Cy0Z#9Q%T<e34~MG=hHrUe-v9MvO)d2*&00{WPSppsEUrO-R=&
zR187FRHmXE9hqQd`-+W{&f?_unwQ;Npte^&EC6=6{^LO><)eq~ro!$cZiX>|Ob!!|
z7e(bX^sBxGD=0QC!)ITAr=8kNRYf%kT^fH=F1_9HU<HXiIu&PodqJU66=&-%unn(U
zdY`4n&s+^%a-GAq;o(03(=@ZIras06K1Uu72ED4K?dAG`*I}g5^cS1XYY|j7Q(N(j
zqz9IlzazAr#lh3UJ}$xJ1aIZ3IP*T1c6^g<E{AbXJ(F9_$)WDn*`Xt0;)@TBE^+%N
zMW$u_8`zUf9Oy2;pJ&k;U5{4U(e?bSPU}&e$&&^R0chDY<Kd~4m_GUw@H)_SBHijL
zhalnuBJ`HFHhDBafF2i@52$+qjjzMks;IOeBrKMUvHi$MTpi*pH6jK=!s`WDkHU@u
z3csryBFI5fLkA0A-ya={%iVVF3W8PIWbIk0OUs*=g$n!HE7)9nr=4#LJ`R-EvjJYH
zayoCLXAw`RX(gj#4Txi93J^UT2;#-QuU|!fb_iWRT_`bI)mMnO8X)r`R`K_q<r4&P
zG?z4#Nk7tA!!!TZ0Lm?_JBD0b5#y~KAoc4de6X(PR*&)T_`Vz98IT}4IakFXP0I2T
zdTq*)sZq+~4Q`np(``&=xD)j<V`;d0u%5x0`EL||A9^#{>2>e%coYWu5oCh0I9AzY
zRrd4v$_;!}Gau!#%;(g_<CG`_4x^0zcM&uC`+r2tPNq8+4SV1}dgj*OM*ox(@d`;v
z!vdLPi_an34|xv5r{VY=Z&8&$Nr9gT=)dP)75b<;zMGxC$m+e$y$Iet_L{!-61e0Z
z7KhxQbpKsV0{9Xjd3pJzdbf{N_UgCG)paDLI{vrKg(<bnyGOV6>ml(HNAcHUA5~UR
zq_5qP8{FcQI$P;hT1%OtjfItlrncv~%uY*?0w`zZ3w>q&9xQsu*tSzc<|owL8R_qt
z>7JJtX`OcuITqRW?%tvgwP$e6;fZKJKC=|84EIGYrwz?$3T6a>`3Dnv+y|<Spn)n@
zx&4fy2PKR|(M<pop-isjjJAA6rv}$1c2*vArcQ?@gVYe8YIUHhW0_+@>KuieaQR7)
zA;DcTejcyG#P#4d>TVz(fXZoBMHCXN*zb$t7e+=to7I2M<itZ++g%%sc>9YeA<^P^
z_q2_8aj}Ss`sVF@W^JvzVIV8pnnM1;QWmo<{AIH`BP-bvJPL|fGumVjwDz{1w~5oX
zJ=gO2cIX-MrKYt)=k)P64emD97UGJ^tgfPXZPYjm6=`8r563r<{21(Md3hQw^b`m<
z4$8$;z2A>mV~&u#G~pQi%|_Jf2mnD_xcv`ODCMazR7N?QRmq}^r}V?wW)||ovl+?y
z=m2<`pbd`NCZCWTzSGnGwKZ+3q#JjhwqEH+8kY&8c}<z@{_W|i9X_3|L|s)(kap%e
z4n|CC>vMT=-^S#mvau)Uc9~G_mi-c-Jm2us?-u#?83FMtCJqjYux}bT2$wbz?1y<}
zvI>NM?Q)Bn|4Tv4(Cgd8q~I>JUMN4ti(rG98B!!rkDDv`1ERmqS)1&OG`e^``z?1k
zO^K$Fmg!z_@hjS{EZGcv{#v<CaiZAY5hKZnupqRqZx61g3AnwLw6I9rwxaBp^-evS
z-?jOnj*U;ai%cl$?(da8t%~Jc{eQoryS8F=H)U7CwP&Ufl}@7;XQ4HM{c0K&O}-}u
zmI&Q8=Tfz5U0~ye7$Q+PdwV#w%ds(X`AkcZFfy6Vzu9cJ2{q_+JWGm!k)qc69&W{6
z$M=zUqk#xY4U?((Xx_OyP9TvC=fLgVA(cc&2kD<3ZFTI_yLNgVhYbyne+5wua_Sp|
zotTSQiR7z7fTDqymb#>W&t$jRr`v4@I-eWLL+C!<%(4;N-_zodhQe{JQW!&#%`e75
z`&@Xar(PCQ^;WP*XX`429I;^YZ{PUuuCdUxHvX`28JeF(dP`lK$yzFXpZD7D12SHs
zq?Ka~`m6OM{B9Nn*%T@aRvl@DUqovYJ;L1Vc+a_P!D50qm%|2h#5VcrinY$bBS~3E
zfTeY0Ha(BcUx3g&p6ZeR)V?|ISq)9p#Mro?urO@UuvOc3OTn8jduSK158&Wr%$nL>
zt~Uz`3X&?UD=QoAagU6OqNSx>UkC6cJG)_qpq2u8MY071N?s2xx4{pt=O@k7bckTy
zv2htG9~!+bnTfuM_eU2A>k1DG%2;E-PhdR+={(uTn9*6nCoTc>!^a3iluJhA)u&QV
z-3JO@>-jl^*Xt3||Lkt>UD(ievx5vJEixRR-NBFs;6HcBJ^X7Q{i$UCd2O}8`JUZs
zFR2cLOcqqcnvZtn{`w5J=~vcJgw1rOp>Xx&`1(%7oYHiXJKGc&{#($CkKb+EQn*}u
z-pt0D8q`liL(`&NrCCWP8Sk3~d*2e}MHFY<Bu{}BCL#k9GgRN$Sm?7p@9}LqZSxc8
z?oJ;ugcv0ZyRz1OF{^6V2#!vt&F7I$Od$XYK}u2<;T#_x^TD5Fd~nAINYK#s4~~y_
zkJFmGvhl}8!PT$!A2-Lbw})^p`Av{lm!wr3h%IjE4W~*2#G~!6FR~m>+@>~se*ES4
zI>cKPxq-ZDJ|+SykU|wjE|gSJIQzLIP#CU5nU&S4HV^1!y!hXK?DL?DDkw~WQ!IHw
zB8n;(NK}If5stjStHU4*!N5rAcV&mR*Vi-GGrw%4r>$oWA$@q&FG;ASC%l7$G*kzs
z#QhU)Z*P@VPBYwSsi@FElF8A2qPn<ggM>5fTd(8v-}~md9uvg_=DDi!N-<f?ryt9K
zO`r*I&bSfda4(~z7KK$sMGCa*gWS1eDk>_)oyDfQJZEg3r@lk_)N^G%->2!fY$JzV
z@}!g$xFDgnDn!7h<;tB0D7Ska?7fW4wZr3SqG3_;HXgsZU@hjG(*JE{xMCOd;EFOS
zJ#DbePGAL%>vXSeT1`cay}@EFtaOcm$WV$SZ?xWC)>uP6>gt*pIPFi+6fZ)vB`hg@
z-VS8@VDY0N5IMG5o}fT-d9(G;Qgt203327fUdOOH_HDRJ4T!{l;hB<#U@h>}W|Y4u
zMQ)Zl`W<k55vM+8MQSt)*z}S+sw&9%mGE}&6t9~?M>RT%g>9MH^bSCu)T+%><8*YC
zl9Dp>Y)1v_a{D?Kl8;+{@~q$XGTTf8kYU2U)c5MN{TjYkiIo?AXGj$1@Oix(kx-km
zSYlXrJxAFXEdO4GD{Co}mHOo)n=66S_)1@R;(>tQ$CBL}vy2hgG{=fll)(C8YATVD
z78k9zJE{y*o4K4USv<<Q{?U}CQ9=!P^V+amSHQ-THJtu46m7w8@$Fwf6iB}Js;#fT
zz5nO))_eF)IBfjZSbn!y74I%TvLHse$I?a&um*%SEUv8WFUm8ixto>p<G7hhLvV5G
zMa&Egx8gQ5O|5@{rx_PY@UKWy)4NhT40|e-Jba-yTwPdrc)H%rs}DvZh&EVC%GVMl
z(r|ENfJdeMMB!^ITp9;x7X%13X=wF~*saHZy<cV91}q|R-tbsv2&R3hDne&x=`Kib
z9~Y}W>SA&niqhppx414u*UF!ps^G=*MFwr<1XLwDu|`6Ff`a0jD$%}TV_=Z)Hx@Wf
z!5FBzb3%q0m<n=dhWsI5wD4<Ouknw``-*fzq-RY@Ct7K@i<*VLs}Oy+e_TW}??+{K
z0<2Eb&t>YFK5edGJ#9(cruup~SXgj>$}TOvPRR^Tx8|QKM?d5u!txV-KSaDrOhiV3
zgS6${_uNae_3qcIkF-HG4GlbZ?T1p#sI)fKaVJv8Gu&bJyu6*mWz`yrN=l6I)D#pY
znJNA$&NKB9jOnGL@+-zwy1$SGGj6OCl=MuX5^_!YOoL>c#oUnoh0ffR*Wxgk4nD7y
zKkhzo^JL9u;pz4`shC;AXsmDeib6nD)K+H~p<QM%)NQ1a|4e>+<T9Sj;G8RxMTMk_
zt@+IC{f>dz;ySezT0f+rI_U$i@-QFQcd}JSK4tW-AIl!X=X~cFI+1}Skjz-knV<1(
zMYcV;vkoG2=ixBv$QM73pf27>_i_1&g@w{CvPlS^pgWe*2DzkN!A*9eov2rU&{E&r
zIGhTMC~hE-qn5WfW`2o(uI}I<#UAph<IQ4d!x(SDSnm0>>N<yrG8<3BlZ~k;HbV&>
z1f`kuU938jw{yXbtM=_@e*!5azu)Gys@3AzFw(1D&d2yV$fZiQ#qmL17zztyicqhe
zFgPJ2Yg0`=_csCSb2Z|+lzU3!Kqx>HsX?DSs~le<M;c3%JqC}K9hdoWBBtU=uBT%W
zy#WP}ADf;KCIa~*7BCxt8F|%@THj;QXG@(_?Pa*>@W98{gr!0G`u9|zE7<p_aj34i
zNA(f}8cfR$Tj#Ug5Ii3A?KPl}7&DQ{bu%;B&oY{{zU%(mWL<VBPs!MbW|2g!L-iTN
zVS>(NdadV(9~{Rkdq%@T102?@v?bnu=v#%fj1WF>^gPEIjVPDtX4Ir&bb~H@f%n!N
zaZksHU4Oi6n8XTaxy;BT?+YtUbqNujJMB39k|(d-r^`&E4QP-uMJjCiud!HdDEI{H
z`?t3@@)!axhwV$LJ-~WFGPmBIFJ<Y#fr;dxuw*V1yzel(N*?{*Dx+&m&`quH=38%_
z-c;w&$uu{;7ox1FxS^P5xThUox4;hY@_mVF{?0FD^fAsz4U$RiJbB$%Upu4rPub)@
z%Z!(8c5_X6b7t!K+i#X^-R|w@^Ig}MgN~wt!b2&wMaj@OSu><B(F?FiXhZsyo!afa
z8!x6^nY+KWh#Ue2x(bi*I*=MKFAl4EC;T|)3!o0y1M~M!iNBvmI!wXvX;F)9!N*9Z
zh^tMqOlj>ICAOGPQlKJ7m;47<^+w{CG5Rnb`+LZPu~I>S-ai4~_IFseY?a`*#xcwI
z^TSSD=Hu(*pSNG#h9RQHZERXrzcWyE{RR#eqK_NBKf>4b8nNJ;e>`leYoj#f*Vly!
z87;KHaI{$67FHRpTER11d7E_QS9Ro75pewG$tl?_mouwn>8waWD(@+oa*Vo%MyIHQ
z|ATd=o4`kp5HY7%#76PBH$U$cL$L1gMEJM&t>onqpg1|5$~hZ5E4$C1UzL=^Wb+dX
z0?LTcuX(lI&<)@GoD{r7-;Z7%y^E$QsNcIF+Qkr^gzkgQO+r=o#0ibXH`MmTPoX|I
zMyaVlguKkM<JZ(sAdcwf#p#2jlzggx{*`Laqvk@xUPJHK0IN?AO_y(by$RSqsy3>$
z5N$1FUC6Ij3bo0)e<Fd<U`d&HP#ECLI(oPeoY3(8@e37^p8n^3JUKZf+aqt7aJ4*Y
zRJ)=E`3vPn<FcakOMLq{83^<i6%`eR>yd<Qtux=ejuAcH7oz^^(v%-<(<28v2Lvea
z8AFHLtA`us+dF$Z3&`Qg$zvn_tL20jAcR-e9rzVA3f1@WBN{48ktOuo1sh=ogMDTI
z;ReTGB7)Gp-z&LiIHKVka6zZDrAinO5R|2b8{CY2erAiy;_SHW%%%$X7)f@pk+-dB
zEVeWNCz(xLurJIB4)G&%d>i&kp$z`RCEBy!*RJbKYPN4`{PkR2QQ?Px`Cy(b!wjaw
zPEq9HFWR-rncOTDxZiD_a#<|B6D}2z7IKf*-ENmZ%$xoEUW~-wLoULzho>4Ul9Q9A
zlWEdeEEJ`ya>$(J#3MCENN!3L@`p*7!bJKQP@;E*azUUcboBSGdeOK?yd}~<b+Cuk
z>-<Y**Bh-11Ml|ezpqT#guW5W$%JlZKsXGN^c-q6;<!D1VT^Tgb-2gPOLC@t;hLH)
z+R^OMB|uokdifs0kMO=bkW@12U@sL}xmy6&OpwNQRcZHW$1KkK@G`FZtXA`VYIC=}
zT)rlAsxD+QqiNBuc5V%CB0jsux?@#pyQc8R;TpnGqL*lgQZuvIurpaSTno<MCc9`M
z*$gI+>(TuIHuM*;#^_yeIx#U#A*KQ{nF#wkpi&7Qv{%(D#lh675wXD`E(BnZsU#GM
zrkBQ{Sp~Y?uDdIZr-06{+&k`be<-7ss+<^bn7VR-B>ZwIS&7~!7UPfUAV^usyYz1|
zP(2g+bot;su3tf`9{YDEmp!i9l$oykXZ_se=O3_6X-(BM+`V&uwk6{UX`60#Yi<uG
zaaLmlOwoz>VKAz=8RpHl`R8QX8HUTyW{ddF)y~%1p0;E!7TxoNpQkRCaY8)q@LD`<
z^<K^n#lz-4?OSZ$W@gY-*o=GPVcJYh_(}wFx3^^RHJHCpm~p=h@^yNe@IJST`5qq!
zU3-|UlBeM?Q^KQgH02YxRceQP?~#s5y=3X@n_Zi?jn0%^$X^xtS^O~Z;gqUW&F56L
z?!9%ejpumLK~cS8qE+{I*zbD8%9q<<!KvvnvJ!OlkdqzKm{ht9B8N-2iZGL|fTV(w
zGLC#=l*F9r=VSHN*K<nuJy<v_g5P!`l?lAL(YwI2v9noN?QYgt=sz*2N*qP*PCl@j
z$CeXXZ7_lK=e#|1f_x&U%f352zwj-d)fHjWaw~0dFk`}ue1#>t#@Rh#^9V+&%^WK?
zzi1=NDu4|VD&CeGh?%P1f};xjIm&oisin|tE2==LTyhyybmvV6Ix3}<U}~$~zHSXs
zm0ie*cQ!BZp)S((PWzSq`h$aOVzm?^^Al*7c3wrMvRb>le1s6e6$=9e1s3F=k`32+
zvVR=iz$&CGA?yBlU^SwA2)6S>DfrjzF%|No?w>!opZpPg-?ajF5qUixw$A5LCezJ4
z>A^b`Kc97s-nM*sc<Mz=kNQY&)2H{B=W#&De4y#%%Z+$-+MwA+-$3Ta-rBv@3Y%*Z
zpEBCP_uBAIG@eg^+4OB4pgmie6NeUycCJu(UolzjS{@ou_fzUgTrz_Wh@pG=%lCU%
zV0=71X2<X{%jdbnec2T&sUQ)*DKuyfLrn9{@o-}Ij~l@_r(UOfd*W!EBdsjVHp$%(
zCM0J~g)s=~b3;i%J+o(mMPf;d42Xi>+jCl1E2MP##|RITa&;bw7+N>W?gJAst4dLD
z2o&}1MpKz@wsDF8us%Sux6qv~h}OSh29Hi-M+X+{DF(QrMLsDo<QPmx|2&6-cd1`M
z6{UE+OB5>Vl&M;lLxF3$uD(V5+IF7>2NJ@C28lMINdFi#W;kYniV`cH!-R)I1=;)0
z<cme&vxW=h3i;5pFsd|wa#+;*q`r?Vld^D42qX!f{W_wA=t((~;zz>!Qy%3Y?h-_=
zF$mh?-MIBuPptX&;d0ll_q1Y!XA|2cHVk+CTnL&L%)F2K)+eAPylrJGse?CqR`4_z
z6aSM<hFL!ri-hBh|40LjcN^f$ywjrwyA~vX^o6=F2pq>8nV1Gpi}me~SGLK8!9!ll
z3~igeE0XSCcI!cew?=Er#ic*GKMacm!2H2R8+0v`43C%{Qi&4a2h3bI72B<W9gL#0
zMW15*<0<66#rbfmnb*jzWQts-V_glQZ%kfZ!DG$mS-t_WfkOgqF5S3Dmx6>vI?V5Z
z($%<>i?f0A_9#>l3NW8LM<yaQt;&k}<XvavJv<!gf(<x1IThvX_<mWzvTUzd3UWHv
zIDq$bLdS%$r#&)RdT>S~-Do;3T8wW#@*~eAzhCdD%iMg$Tc`jKV#I~)ZVtvqPYLJG
zpD+<Xs+oH{-nYKx;E>Qq7J#vfgoGyD{SLFunq9<!w})?M{y7YY!<A%sc4kbo`#>ac
z;O8F~TU$BVV$rV$2hu6@fZO4Km6ZFvA4gcA3mZdZXegRruB6lt*~mL}F5bNAjEuIW
zy5MJ13ulVMq?COhgA&(I{y!VsKs^g3+6v74_jo;+Gi>dPfF#hoDgx`S&5M<W=iBVy
zdQ_^E5aAv;B)ScVVnPy<)uk3JGKYmcps+|uErjXXiYPelFzTvGHOPCv0i5XiZ#Go9
zV=X=zB!oW-zTVra3<BmJb%cz5+-LC`s;z^RnTX$k=9$z=v&D?&>#U^eU5HfUZKL$H
z_0-WG7=NzCzll|LkILR=ROoKkyZki0glwFveZ0$RGp4LvPm_GUyhaV<wPvktbm=xm
zr>3gCOQfP-C<vgcCF*o6(3VD3?3XOD76WrT&P_Uh^19Lb$bikAONAutKfW>02>4j>
zyByYo1mDKUX!>@uFQ9Z^ummWI%(~iJ1tP@2{bTXqys&MT9~f2ZBd|bEv>6v={owxn
z8@%6|SD{0+aX7UJXGmky)(JuCujSmeRR##_*=R2^Qgruu{UkBJICv?JhQ(Hq{codj
zd0EXq?y((CZd8m-*-JK@K3i8-0EbAsnb1_VF0#C$rp&iElCEhIpE85q-{)GdL#Z=E
z>ECrk6pmDN?^wvL^s8oAiffJL+mLv#4|z5x#2pL<uW2LhDs&?6s7(&mHZeMRD^kz#
zcIYbolGK}Q_b9%tt&ZIq>-Qu~k&-79h>T(ri955;npmcZ>G85QYPrzgo}X{=&@H!Z
zZnbeG(#S$E!O*YsNf=o8eZL4dwq6{TvwJw+@JZpFHxcmA@UVD*hK#DJD<-V1kMJqq
zR(-VT=2|OOXE0ii`UsZ8`MA0MR90si<;+q-V&!^&;xp^D^vN2*2S0?EhMr_55iEy<
zyY*&`tSsZQcXLy3k3>2A0-YUJ&oJu^Cnfu4T0Ab2GJeF1eH<6Lt9xT^--vCg*UeSl
z^SZ4-sPeu0pqc=T<HLw6WHJZGLfO@c20<B&kg>C*j=M<jZ9CCJJZYd>)TQ-P*%_5D
z_aU*6CtV$b)4{kAIX&E%6aI%6S6nr}h4u$FasgV!h7+mcC7kT+_v{Tl_ASr(vsELn
zyO+xJ<u5ox%;j)uSR7HmL5SIFzBCrzNYw0b>7Ow;d_!Vv&@xS)$9CQmj68om;(dtE
z<n3Zau~M}+;O_=+NawoNxYV4K1SYZyMH51dYjxXLO`m_rJ;99f!971~#IV!owoF(o
z5EQk+<{^@@Gvf+ix>0Va7%un3<$Gc_EgqjEH&|kKv*3e1?PImtEpCIS={8YJPI}hc
z;IhB)&{2F<HTG+*Jv%)#)`=i8&0KXmI(D_+r}wty0VQH=(2x13+F3S^L4jn@ZR9))
z>nnB&Fhunbw}j}@BPT4~(xJz}<1IT!9vEgxJ(q-ht8#eq#gN(+_py&D&OZ6?{TCMi
z8v&8OHVt$C<K=N-)Tuk)@fWNEc`g%nPz)BXiAgeDyJL%a(WYE7@PNk41W7e&OI58c
zH>W4aG|hPBY}FdDr>J)w>iHR1+rR~MXK_ICvuqV-`Gv~-2ooPD`7F~K;nF$S-n$YK
z?GcIE#s(r&a;Y<0IK6&)9qtZ&@C2%rSPGPo<&WB7q21FW-{K@lBB!c*z=nc2<WI5c
zRS{XZDLwTtkr=uT8tT8@&uG|zE?0_|N}1nb^x$h+#9GK8+N_e>^W0LtIEHS<M(;^C
z7t?S|EuRFyNnw={<2Apx8@1?0A(AHJ%NOaBpU7vyYI1u_^mjgh!R}{E9j~j%6pIiP
z57!xcaccQ&gh00DPbNFPf6AFw!4tP_J>XL(07Vn%@Vm@Z61z&Ly^g~Ug0;I<<Cdv@
zw?r9Z8@0Q?bXvrH9~)iiGv1kft3MEffeW6yM#;(x*wjm5MLS(w6+wEz*u3?sTmwmr
zs@4PYVJ+^-uH98LSwwh#wwzegzKl8)Iu+mPnWIq)s)5YFQFAo3My?dJuQw5M6xKQ*
z3W;c&>0{cJx^M>Nf=TsSTbrJrUId3$nvv_x&TH{KS}ir+Qz+jdUPerHsEV1QFJbS}
z4W?%CQJqX50+x0<vruUo(gLM(NX4g=mQ}%Zr7qGpSt^k96Ms4Fs6+=AfeC!Cms50%
zb6GmM^wTfbyL-tSK3B6OK!2u+S7$grloGiUN=VG-k6aqg8Q6KSC4M1fjfxdFbymu9
zScmQr-%$v|ld{34bhP3JEa$%IwR#IS$QI9`qV8CV$eYApyxI}=^sHb3F*Of~1Ds<a
zi4YW+1y|K<je5>P#>Y*w;^Slo*#k?NLhqmx+UB{m19?;`<@bJx>(8m8WZ+PzHi;zM
zc2OB^YCApYJU_#F;mh3@gw7eVIAJyY&!P@SsK2ZnaPGGTvx4%~$Mh_;=Uz$`MDmC4
zw0bjxD%_~kF#WwpydV*)@Qf&(cthQs8I17c?~mMfWE^Mj<qo$&csQ5SpzLp@ji)_U
z&+noa%uUv&cjq>!o`*kx8H+wyYQ#?S+UVuC$QK-s@ffdI<2jXNzbWmLJ5r@~N#MH6
zwX{@p?Q(GW6d@~iNk;_isY7VQz#uqqkazgpZxvOc<9GbSxZi)+bE5>&waZ!v#bUJD
zL4~vF%oo|hr?K~5zf4u0iz5Co4|sK^cbufF>f)Oligd93ku(=S_TcpFOYdk$@NTus
z5v7$O`;4^<*<fqWN>69=TrJ`DE2STa591$t6u$|0J$j-n{zwdh%Cu5mv(sM6Z(Q|b
z_9YjxeRA1;)}^|432~lH$$)Un`RKQxO^3Hqza(rvV$GMehCP;G@RLSh7d{X}d>3_{
z@m}BPvCG7G{t(@M@u~HLMmX3sARUecCsIHFE)_v+n0S*P=hcZQmkdyG0{W^XEmdyr
zcEF%G82@iCDWFFOz8j&ja`K9(-#{zl9f(+}+NP3wl}}*se!7B$`#N7!bh=ob!r1=X
zqfQw3>p-*)77c6I<v`K)tpyGFhtiR`n5RLfK<orjBC8onuwW_=J0w;IDEEE`N5^j+
zgM}$@JkdPA8EEc3K5ekT1bIh4bwx!@)EW(4nf8y2Sp4G}P1Nc2sM~Ct8Cfh%sVnCy
zW+;SvE$sNy+$z-eou9orSv35kBkts##As&Z)|ja^Ezn0zN<kg*5h8^kP0y6iN=*$N
zitfYtzN>B9$w0_rFs{K+6r%XK>MisNwfnjD9(rSZpDg9Ny{$Tvt0v;k(^h^zRHjEQ
zOMkrA%NTyl9gj5MGiBej<TP*Z$kcrAr95e4N8+C>f6i1XZ-<F|8NipEJ#MB|7Q0Mu
zN+a54zlwgMHs{3ewm<C|m7LlrhUkg*hm>Z!7<s<aoaotko0GWBRSJjgW|Ghc3Qhb~
zPP51CLvS*W=jm-$hirQPd^Q09__LZrJx2DW#p?Ow1fHv_>j2R|SnuoL+|k(al2Ply
z0{UW1hF&$VIl$6l&i5tQ>G~k<?*3-+Rwc=n@MvacR$gAtzQZ(F@6`khWD|F_`#C&C
z#=TLndsdrbyZe67_W-fz<-59A_@~oE5(nA<W!k(6MPV6|-x>!6a3Hn%Bd-&=q1oA+
zMM~a;cZ{|VqZtX--`g+6vzNMAO;^g`&4$%pi($ovVEJEWyfg3l0t>QtAI{bAJ08~@
zE8nHT^nYZ1i;E`Gsi~M-7ySjHCAdzOQRQ4VlO#E!$7DKnx#|W1>PZ$hTd;+}E*b^-
zZ`r_EBe1<=eN=QhOtqb~<|YZJf^4vl0TOUSP-5sJrI=aqn=1!NTWZyJ%H@MUCdOOL
zk>g~)gbOy{TGPC3-`It9Fi6GO`yctt&~Lv&JBe}9qRYXJ9TX&e<;}1kFU*GC+D8<A
z>6RF$mI;IK4;_{$oO~lD{uXNULL`i(@?6a|lJ;=oqk3TS{X4tD4uEZIXkg-RH0Q89
zmJP6}<7pq<@{kd~RlIHEMC)3CK7m?_cb{N}HWQ>_9}4y&KZ-5ND4);g_;9l6{8EN!
z$6EB{wHsK~6|e0tdyO7&#=SJuUvqLWj{y@Lfi^VuP?h!#Ez#nlBo&fY$jFOR-e;9d
zxaGn_W+`vG_<W&gRjc4R(%Vg*w_hDoL^KPd4z%pMw8*~u^ZX0p&a7NcgPltyX5?BL
zyv6)aL({I9AbZEzkC#y_eIuE`RcA#N`5Es!Ho?EgQRNwKDJeG|=-BHoL5NEYXG(&M
z^nPwqGlATH$(x{*n>CX>>8U+ur_%+U6>eOZS!U~?J{mX0;x<HoSe`VcUwsvKKY4zv
zCKZ!`P55L$opHI(WR%S_uT+G!3?CX9xrb4_>6g&RrSBjj@(Cm&CdS2~TwN}o;>B@X
zk-@tVD+uMU(ND8m*OFFRD#<wY9yNxvzLziY8y<776UTHReV8BmF|EctZ*%qVyVcN0
z9`-aOZhC4OxNbZZ<n14m#b{yoy7mUEA77&izLOLCgbT26-X_a9E-LCL)Nb;eUmjjn
z+uqL<#X*%bWr#nt-IuLYKECR$aWfBtwl=k-*W2{$hgrX^ZCDusDQOYC=ue?TpL}aA
zr3oIMz3xlLncu?PV1&(~&>+ij_!$LOQBPZiv^z9xWzN9QN8<&W?s|Bg`>jfL0sJAS
z2=YZ>Jq#+p%YtkV?Ydv(?sa$b_D)UB3rs4{Y30I;@d4TE@bK_Uvz-PaE|YDG(LiPU
z&${svuj&C>E1iq&g8V}D*1LT0q)(uXy6`sK&yu|}kBd2XhBMXmDpM;C)={jlcHYN~
zLy?8X?IL=Vyq+rO9IQOcKqw*`5~!SI%=ngBks~l?tm<lzbhNiqXZa`}d|v+26|8wS
zP@RNGszOO(#paUCc6v~n6msb!>G{~^qCA%1gNm!#!GrNKtQ+we<V?y6+HxrCE<SW{
z#FDyiS+|hi|3bFqiQim7@;>T_1CnTMGFK5dktQ9iI&VAE#E(@PfB7G`O4>0fJEI(m
zxbD3NdHgVP{_Q)jUESuFZbP}X5(Qx@+SAI_xVUXZ#AuyWYX7Q<5xi3e+5C;)ZTF@m
z7gTazMWO>kb>fJLEDqAdPRd14-%d1>d{Y8!b^C5AX3xeeo7=fwHL^a?Pp*tZ<_W;B
zc@<yZ_DEE$Mlz<VlN#FR6FqtGK#tUCT7vh%A8d}(!Sn{#ZaQ45y3tK-d3n(z?P`zZ
z^INACuZsEju65Ds#wECYpPY>pLyPtc2HadW#yC>0I%02gw|0xprB5{jBz~voK8TJi
zPF!`mc_%fuY}&M!qhxtf{m;q)M9&tOYW6J_`OlwtczB?mnHeH|r)hcUwB)5qM|5)P
zZ{k8N{=^h7G>#;9nP~r8nSml}I3cs<n^KRo;9s;K=Kg5A`yAaMjARgKlD_8|Qsk;Q
z0qo=a+QK|q+>L-*k{gN8`x$6K^wC1hL%s#x>-X}Kvag4#YHVL0;3h**WyrKL+Y!;R
zc-}hrHiS>nf#tO!n2&pivGr5voA)a{HKNUHl$yJ^dR(hpt6RzsB`<8NKPpq3dYl9i
zNkN3#3#36mf8?Cq{t@o>o0^bc6djqFnEvE5;%}mqec0HI-#`lFRYv0w;apuO&R?bH
z#yp>EU?X8cqiFHxJw&ZinSWE=K7pX2hm7eq1=+?<{%7@r={_24QY^3no?s>Vk6>rN
zxAzV|NPq+7FMifO_9+sTyfIc8^HL|7k1qDt;zF591s-@pn!n>!fg0AN)Pt_WGnC*n
zAWB3o$Dbl94p_{(gkNGys7T7B<m3=RulR2+8%gvC6Sa?Jm45@WEgAm&r5`0<Q-Wo@
z$;pwF!c&#U%v`~;<`mvUf9Fu%*bJtiqkCBM$WFhv&uKzbu#i#p+L?Z5O>oMjr#cxo
zteZe8oc!F0LQ$C2-R(#d<pNdFW;N?_vLolY&?HW!y}<g{G}ckU(V4m7#wEZnkC><d
zAi;xyau4O`wHlAb56mqrT8&5IB@@VUN5x+&(sR+Pa54yRMyW$V{@E82F#nXhY+_Z9
zjw_moi8yb($+_ozUN6_ZuDUld5FDz#uVP=eH7*tAQe{lX(+_2{@M4CTS(~fy<j4{>
zhq^_72F3=dQihe(PEW|=?1@&jnqMq$9rL|A=y@cEYka`9$_3)Cb-X?Wz}sqSJE^OJ
zC{UC)sKyTHjj1Uit=B*xO#g3K6Q2oBE{@-?mi0gF6bEz+k1!hHRuGUWIidiqqUg2)
zwL`B^w0g^aqB>c=_H-Svy^U8+$zt^#l7V_QlopFy;E@Nn3x2ztZV=N|egd|*|2I0W
zPRvcpB=$;yDPKFPBW7WJt_`G(K-0KD?LHEN$qQREp-Hfw0IL)<87K`G<tnaF`c$67
zz>R{Mlqn%y9{wIzT}~f5P)oFf_iHW-@jEi|@lH^LSZ7GuNgYT(Ap7I%c8l=$EME7Q
zyTaRpw2cT*bxAc$ywg9~sj&v~&8Rzl^DTz$?$11Cv#FTJn=e7dWCOuNhxnST8Ua$X
zxp5Dbsh-y+mbN$0yljQdb4RziDIkylrssBDdO9`8n0zqXHxaGD;1^iHIAO2Bhu{?K
z(Pz68jl_Z~ZTa^9oFrTnT2%CwNDZkX!gI<APoeX-l%wnCC^=^NN^OpLk?&ZbF5?uC
zfBR_*oWXWW4$Hg3(~I}RQk*N$s-f{q|M0Dtd&~u|t@EXW(fMzMr%?+?q2pHR5r8H@
zxI%-b40*$EeXm|;A3W9oxpT@?$HJ9(J34mL#h}a$E+DwV4brzdg6J83FS0ty%-a0R
z4#0T^XDzO1D4-e^gki!C=NH1DLRzl{MaO?eg~e2Kn7XRpOD@Wr#i`f%x(8pZ&2l{?
z>&YoAHk+DailfUUE~_yju8RsJ&xpxvdzPjom{P@iV^5%lwOP|CXBU&BGWS$?4I-qN
z8un>N#F)R$P?4g;QUEqMrpPm+b@6(YPIO~ZWUjl96QiN9VhAAugg~>v2KiJHYZYiw
z;RE&vCj(H(cU%5smadSb^q`4AINa|3A-3@7w)Uvb*C*=2gnI!eUWKjFoW{drE3YN!
zrC%$ltF*4m3n_Y=iNT55LWZ{odX?HdoUQ(c$gh;GIkS(0ujQ0PwH_tgK#kD~(r0Q#
zJLeAqGK|1x{kQ4V|F>%g;lDev{FjLb;fZK;w;3({q0ehZYE~TC7Z{Mhs|ronDhDDc
zX;mmUR<M{E6IMt&R1Lg^B<BPveehywCMQ4_8eSM~n)nL>;m(5#Np2;mz;QLu<Sj9=
zq^QhxZK47Bu*j_F@W2?ymC=v^vu<F>p`)dMgN+VqC<yPKn+Qvo(0IsU80No!Df{wk
zp|V`k0}=@X#fK!X9Kzis`}2@P#u2}Yjq)YA-}74kS~#Fo;m9~yav?;6WrR1XUoQG>
zI+evQ=olfu0)t--FKJE<DqUkU(0KOd3pM~Q-CT2qCU9x9%oRgca?2lV3q)F22oIGH
z?BN{WbIVecd5N#jtK=zYC@7}?{F#`d7XS|yU<s9ij3iN>6r^gFRaeEu2*(zlmoxlO
znYdB=sDy?10t1N|46vah<o4{tbvr%o_s7g~<zYZ1D3W^JN=WtiG+(vmmoS5okuZTR
z-x-VpQT(*(jIa<@GlIHm?w4vbO<bl~W`LsyF^LWXmXnv~sk4?+tw%=cgCeb+ns_Hk
zf%b4=LH=%^)$$p5mI1#jB!sktkv;?W#bS!S1De*AuCF^3k>L&ftC%MlVRuLquapov
zf&e1a<&l<?0|zbEUMN!`fJVnWF#3g*loHN8?|W-bSP3D)Nt%KGM@t<)y})cLO4SVP
zXNl-6hbzWu=$b2X@hIT?MJ}C`D9}Lq45<Tj38e!0Ga!E%vWO`!m>F$U@EQBDaFPbr
z24cllo8CIua<VrtXardVg+<BPZaV_Ft*4=>FcDOgiAV#?C^2+awjUHCuavwe$i!cw
zYW}$gFp2%9D8}-oGhtP+uQ6&Hv51KR^W&Joyq<skrSidglB`lh971D@>G2<rP3S$%
zH}mj|o#KV6Xja@_jTAgvr^7`v&r6JOY7+WbELXJMd9q4dUC!;9(q8%AX%*Q+|B5zN
zN|~RY5;Zy`t+M^D=qp1++xm6RDsY$8yc8vm9;)`H*7|ng)8WpHv3EFAq8!$Wws#2d
z;I0?9HDO90<sz>(mt7ua5QZiqH4=wJ_tU|5y=}>&a8?JBljMrKBV$OLQYQ3<RTW{E
zTEIZlT<kE*Dvmgb)2bY%Hmks7iPE6%mYf_NrL&WOmb$Wm4nLy)BN}0Cy8YVt0{ud>
z!QJf0!l@m^=$(eZXs6g4_W3&9iLfg5)020(>n<X}H>f%Q6v+~9h_5oyJJeWF)`nX;
z%{SmS`Z&HS?)A%PK~dpElnbkM$#C9&AXdVIR4|p=D-$RFC$g-=%8gS>wi146yti3R
zm|oyAwW$XtT$D!ni#YbL6A?nP6H>5;^T$yRhgkE9)YRsk37PTBF$HEI8gxHv*8Mio
zkFrMrf&M8di}Xtxd^{;{0bT%E#dC+Y+)fFhHM>&BNmgcyvyx^T<IZVEnCO3|=KdIL
z5~R->ULOCthxY$>Rrw2hxr=04qV|_iY&U7GglSdaLfZc|G(kyvln_~&Nvk!8%72<i
zlJF?X8V~`JrlrM1M%EN0h?f;oQjDFAhmZaB$QS`2@Bo2{Ym&%Z^ah&stqR2Oe`==R
zQ#JKkeHV?wXY^AXh=_9GCjLU``qJH<?D_XIrMg-Gqp%rj35>#jPEH%G;eb2OI$vYS
z2z7mK$5#H{;Y|qw!S{zIn=)a!@RE}!jEFEdmmnplQE7tYf2G4(p0Fa4nx#x1u|WJ8
zHK~@pO9b1Jb`AT*2NDp!w=`N)(Akz&Wdym$JZiIA?7cQV+g*zLZCk~-G?X@jW`Wq-
z^=H^dPDtx96`j?bnxH;>g`S*Rt-&@~29KgPrX1*8a5hWJx$ktIOqMY67Y|;fI;=Uv
zik)%R==d(Q%hB<~a15KBUpilyv$})k5>B|07=%{P2?1&nD;ymA?gPyr)-Z9w3Il@r
zb!rIJd7+B{7Zd92;ARwm(ye$5+&-(h70Qa{P=$@^ep4x<)qP@DTM^ZaO<$Lf4g!Q>
zRBTz6)1RWPT7i!JJ7+HE=|33v#UTG9#;}E8TZ;)9aP=C8m#-g;rgzr|N*D@gZAlos
zQJ;BItym^3&M+G<gulOXPPyGGXsbJTkA35{!XWkmoVT3(^zI&N44d3S+Z)~i^uH}G
zKh)liek$Py*mu5^40T`mWbiwN*-Gk^$dawsrS{)WAK?CV6?;z*-Pj+V{<)<{ARvC0
zrXoyZpG74qYt4<=$O>s4r#7CKt+5$v<lfYqfN&k_Zn5Wo0F5XB4VPRo>Zv-4T*N@i
z{7+4}Xh3BZ(yySTWJRRL-`P#K3sgTuKfXe}lTmyxuBCCwR6Td9`&aSfJ>v4YQ`Htk
zVp6^=9utNBU$u{#JAWp~cF`evY%68CL(fQ@w#UaP9c#P_E~=6E_J76PDqY#n*>Ip(
z?VekhcW0Y#Qxd2k{r5kKGqLP;46_P06E#hupKYSfmx@$u1A6uzDX&Yny2&H6<MmRZ
z^Q248gup=2U{ETVl-F74$TxaxexgC5Z!bvl%F2n1+=wAgAMZW@FPoa0T4M(YoL~12
zn@X^q0Q$;(8lP!o{lNQCYOaqC##zS68V2PTV5#-IXt=C^q?H#!u9Vr&W3)n*l~wkj
z12<QPh8?;#l#}%J?H!E3FyW7wFfA`FrKF~AmP!kYf|sJPy=1FHQX~jH0R4Bwbf{$?
znrBtcwN!jh*HzwkH4!gk!h|LzWh*XF?>ST}Ry~)$O8;1;EQiYGW!*3W2ijc9Q`EV&
z?7=|etg>`XzT)}SjvPs%=V=I_tiTHV>z!u=@lZ3TPuT$-M}>0b3BO2Wd>&$uk=8=(
zXV^)#<W?aSCAG1kMG1>ENPYS{<2aNwhCvc6-sK+M0F|d9h_Vt6#J>HeAB@yc{zf^a
zg<&dHU_T86I%0zj3_B_FFoGfwMl53{uk4zrK4y;L0bWM_%&;*@EsRJ$a1H<daTp`@
z3>(5*i<C&a>!{SIlnR1g5~0JT@;bT-bqqk}68lNg@F!9uZZxTsnNsf(YL_D`DKqYY
zwX&e0<z)Tr*QI4d5P0-1tV~gIQ?#lVZDgPd|EHeo*VnbP3~O5~wcpN5G_FI@P<VG-
z!%s;naNg{gKc21wv$)smH@Ci0<c6viInJauUK^X5>>V7WI<p%wU@~od1%!}{wRT|k
zI(RxWfg-lLwv5F~;{$nu#{<6yw_0lQeaT7efaC!lp8-v>B;%*DZF)^bY3WE28LtEh
zN=QHQb7nQ%j*&52x{ayf``$4z?>b^$oTsX3aBG^0@Ejv6o7cnZ=XkA8d4gzYXoR1W
zlwwD1P?H-&`wbW{zX_t>+m@N3bgiSq1_6x-+uGWKf<&|VNyBC-=_oC<xt^aPC6>N~
zLiHZr#s!X20*~PH7}Xb8fF{h#iP0GHw7H^>31o?Fn66(tJCn1L7LJ@_Ylyxe{8XPt
zlq})-_tgshkS8grYmmPW6WSgc_^vq1iSFI!QURSQhf&zS@7Q0ZePxfMM~p{e4I@JQ
zPmZ&XT;PZUEjh_04-Q6D;?1Wg54lYwxJUjYl=3D|phFEfV>`ABE7OVPd}X-;dp`DY
z1}q;K&{r#S*RfTEO9Tg^r*)c{bylzsNa19-i9aW8GE)C1RmpgblPKuR>uYALu3m3(
zq`MoRxU#}ZJKm$BKnn+0<}i>ykv<ckpzx7&01khAf;@Qe{RgjH*+9co^9C#SD&;F`
zswebCJ6%#C;OlNNt{XZkAXXa~sQqFPWJkJ;bvpF3FM{C&mn`Xs0Vb2pxe<`+frgD8
z<!mR%)TRKBwz*>felKX)o7siF+!%_$=D0HqE%_4`{k_>%Y`x9xbfeSDZTBM28HPhN
zBh9zof`uwdtkdaG)qQ}~(5q<ES`N8bjElB_s_5kj2Rm(p&rbv`{$)EYH?Fib$fn-3
z&Ehs0`-dr<o7Ga302hn`hK-Vt)<`OP>6#dk+mr^R2;jw(Kqj+&`>afLKR9LvWX)jy
zfk@YAu*>rUuiEAeQDTMi6nP_n?cvqCkI=cZh!Y|yDd}ACb0*JQ^A~%nsNebwYdW1$
z;nJZ&)Pr*toQ=6FgAX#p&qNn|0~gD&w`IXiYYi;~+K~u8tHh9ju|It_egC<L!GA7-
zO<yDI9WG6V?QFI&C&xckmw~;WFkysVmlxU}i2#+)TPA1LT!iI%2n38pKh^rY5im%L
z=0FE*z)k>dIh;oq%Ygt5{i{N$a$NVz*B13Zn9!$NPH~){zyFEy+y<8$4uYv}J&n06
zYpAeutyu9pIM`JzLkwy+G!79=7h<UEV`u80dO5|2nR|6e0XMUfm;8Ctpe1c~7CJeJ
zEN|+ZH_6cyRZ5glt;&vMNB^DuJCYm79$0$umyb`AkPhJ@WvDOSYA@9$Hk1mD!&%g{
zaweqAtuX7q0jVa9mB~=Z)FG-9<UsnGX%X+R@y#haz16s282i+V+oe@8vE{){_>I=g
zHb|gw=E#{VW~dz<?}A|<OsueR$<#ES!OX3hndtDK;`n}Rg%mPDP!%sJMh&lX*{Q4h
zBUnK6<V|P;caalJ@I~8<4kL4n-lKWc$Ft*n^k`GN1QXN)#sBdlwHwWIJy#UxhY;zz
z(|IH^z}r)TK>KI1yki>9K>Da4fL-sq&X&{LjPZ<c$V%F`6>u9>A*~=2U?0FZypJQ(
zNRY0ktelFOt`JuGw=Da~m=~lh`}be-GRpZAc<=g4bJ*?LZ_jA#3nA;xPCqTeFY^+`
zqKq43=dVGlEjdTy%eT9oJOfCyIMZFl-_SvSDd)^&fwG}O$C13`-^vkTGW1rwj=I{}
zK9m0)RM2J5ljxSgT#1td8ZEuG`3=*KjSQDiD~aIb(n^<f1Ss3CV%Eb3fe1axwK8hT
zb6Hl{A!ty-?qs1)e853~u^$9P0QT{kpL2**Az06qK|Vtd1H2PH>xI};H^_d|S|sVe
zxBwqBcp<%Vv`r8uGlB{;-ot+&PV+Wyn<8txJRhr$<o{;!f3Iw}FP2xAQl#B>x^FuU
z0}w;Ka9QY;-qJrrVR~?kkvw*RZugnJYI4+Huvt4Kuq#GY^%WUF6x-K-PKVKETxqP*
zljK_o{+S<NX{fI;weL=vN;0d~JA@jP&P~7in6EXK6EPmf?Dk<FN4mJSyWZYR3(Aow
z-V^!`)XX&J*+n}$Qqt0*e=pug(Be&|$=GJH0ZWezi<06;$n>yOm6#`WVr7CNDvrtS
zbXRhA_UW0=IqLXxVZ<JkK{Uq=0!h#L!}m!yBPpt{OejzO^T4A`Y{pQi4vkcSje1{d
z<4Hb+g9OQ}x>@r|9MIkuIc;eWU<40=^;;J9?_P^>wO&1Ye`5s^CI{jl@Ad6oi%hMG
z9yd@_ivie)FQeaH>HEa0<Vc}45zN~?^Kj}f{}fN|C%>K}3a-(f8l3i`D4l-IqqExE
z+0WrW6_ENLxH@@%s><HJ8L^A@s>^37TwTzs%&}s&E;y-nfMeK;cwwfI8gW{gh0m+v
z<VH!Cc>il5#Yt8n1j-1W7(lI+ebllVUa@o;ONR0|F(n06maa>)p~Y(R>uQ4xN>f>Y
zVU)lw-LFnx&h5PxN6hx8+&*>Mq2;TsO}k)ZOzn-c?R)N*lx<Wb-OqWHS{eT<L1Nz5
z@AxT<dFXov^0{uiXDOIbie}oki9cV>cY&cx23E4)gl1V&^x7?3M@JIHbJSE+md^PD
zS~|E?Nu#^hfYRfZbRV_$Hz~+@_L9l>^+~J%6&ab)c8x>h7p@1NI3bAeZteIvVzEi!
zvuFcTQpE3ysA8pJxyOt3)6MSgyu7@~VtbAZpaUOM+FJj(6q>rWHZC3>ulaNiRH4)5
zMrSl0_csG!LhMhqCtUIJ9-m6r7WhpE9bN$;WLQ{OYild8XftIE>N6ZU1HN46+|DJw
zR%F0;%*+WxyGcn&BdO6pfBtN1^Gu=B`KPDr?+PHzFj7^Sko!Mrq>&dGW>HZQ5c~i-
zd7uyxV=I!&6T{zwZ<J_k>6HZqBpYE1v$FsZ&&A}EA<`<C|G)SwR7qt81%ZKIf0%!H
zdwCQ`p-O?E2WHw&6G#w1XD3Ubyug;<5j!^pj6ZfJgp21?l$8qxs@M1OoMStH<UvSJ
zkKn&k9TJo<v3yoZMWFj~7y|e;gg#RmkRYG|34(^*(Zatf?*N4Qk2?vWCdJ<U>0<M*
z2tYOk0kX0>CGf5iX(=Q%G0}DoAzI<M{uo?(B$x#!MVt9`XOoUu-?iH9>LPA}$5r^d
z|FEqON96yfW(q)`8mDY1SZ@GLzz*SO8`YD!a-nR&Oa^$bw>HMA^4KmL!Q^|#MLm>B
zQg;GgYNM7jlJ&JhE1pC8V!(Hpqm-xjokecx7y0g@Dpw}|Q4V*RQ)V`i6($l4JUrSt
z6cm(YD*TsoDgJ+G57;ER6XDLCo<<)#+{)wyc3J@@ItK+_RcbH2qt00UCSphX7z~cr
zO^4n0Zi>0(iVR+)nyJ!5R}s{r%<zJOf*^)Lx6^X=Fy_MxRe2oVX$wXN=h-FSID*o&
zS_P0l9Bd3O(*5l%dUht^BqT^$dQ7<6tBQqrX7&NQv?>w5GXZ9CZZ0A+lB7xL|58oC
zp}2qgnPVbV^8cltN=`XR%2Sh8yqtQay*bje((LTAv8bf{ZpT16*ya06vBSP^*wZKr
zM$^>9z}<cG=j>X!o9zW5IJ(4AAQs;T9Q-H$|JF;LNEx`;r%m0aM&8vwgxGO-R)T#Q
z&RWb+kdqFYi{%p~)T|2(HgTGjioloSIGCM+xVqVE{{CX^-S(=3-%PXXE9fw@p#NNL
zy4@j};JfTLAG)48rL!l!+0?L*NIv%KKUyf}`^CwuCWV6khp@i@iev5CM&Tv|Nbm%A
z3+^5uxCM82cXx*n2oAyB-JReN+#Q0uyE~lD-p}*>?_ckC>QGZfF*Q9icXQA5wbr@>
zg%?ZV?DCe|{psWA*k2t~dwY9qBDF~*t6>y`?kvO5FB)rO^Wrcy!%r=oj@0X`?eT=i
z!F<TIlJ8md<r6=>(^&VUPr!QI(nFu|rCa;cJ&bx5tw@<zL8q}&^4$B<GZx!dc6Bh1
zeq|+LA>~$GYI%(a$fn*W{W;#;!Hd;C!oa<${-xQA>h7Yfe8RCaEb>}nGnDU+823>@
zqUvJP6zYG8osyf`{zZw{*h$G)DI@z<m-kDsxt$+qW8x{Z(6Q0MTYWORV%tH2W>#5M
z;A=QN_fBF}tYyL;b)INN^dTp`nAcu2=h117PwfY<#YuIAbefWYBnXX)-SD;6?s8bD
z8hr%>tY{tPUWS2$ozqiZH-o}mM;%go|GDhkakbCw7lPRM<bwLzA)L#Ugq|<^gGhx@
z0}AAQt)ZbIZlSc?Y?dQ4!+%7-29s<BWYA^(j|nND`@g51O5P>6`d0<n(ex<SagwUF
zereYb9c40ORweNb%75QqjT;TMcElx|t=@ZJ?deUbj;zct%P5Fh0-hSf#qGyKkBf^g
zJAOUkft26fX&*^yra4jbmrC$>X1vCqx}UajaF{hLOgZkHy7d5{Wn&|~@#E!zS#}9;
zzfben8o{`$A;9^bg(A20g!`-F#b&oAfE-&8Fy;dCs_PjKopfut*&m5M%+L2+Uu6j|
zigGN@)8FjRP#+Gg3f-mPl{~pGB&IBIsHqB-;fBMB3!jhSYczBfMdsN>LU~z*wlBRn
zdY3iV#gzrS{mGv2RpEJ8M9uY9fRk5C;Qv#h)i0_fK3US$O19L$37v-llZSEY`uG8O
zLrmaa{@7Y~uoyp^Jfg4WACXEZr=-~%23|)$6~hJ>N5{mFkZL-kM;^88wpX0YJ)v>Y
z5Kq<3t26JUo;{E#f2(1u*nU(wdMO^!{e@8bx`Rll$HhsVLcy}*zu@cN%%*d|S>M_V
zK#r;Ga2*U%|2q-otp>e|=1EEcD+LeW&)ROg@aL297!#xw9<TitxBOe;4(bABXYFk_
z&37J8x<5vGU!}AvG5FpA>>i`H?a!adPR<vaWiWVV+AwQnVvlYNGNfcgxWl|+4p@f9
zEcT;c-EloH^j~v!OHO{`>$LNA|BS|a!#~bMswmf|k~XSu=B`FhpzJ4?@qd}6(hwXj
ziBFdtD9Y=QVxQL-DL{056F&Y*{_hS_NPnss#27iwaB7Nt^@${~kP{OYSXW6sz;HDV
z)|vw;{5)MtT?FlWrGo&#gSf*D69{F+UVXHGw83fo^l9~dIp~`qZ){<7d1w8-DL%qA
z`G-up$A|mV*9Zdg-co7n6^DFxpyRoqB3~x`=5B<V75Y7}L#Jgmu5C0CO)6h4$PRq_
ziw%rQ*s|RDYAK`oNI7~}99m8%jZPb%jwKLLkJH|_l6-7O*T-~Qd3SmMy+d7q_AVS8
z*7+;VTNwNYd_qi~KDn7M2XF=amX9`npHVU=CF5xQ!x>)RUy6hgQ}K7{8z4o5Zu=a9
z&)xa2hda%o3?VItRi*HVXmsnb2d~>%u1ID{!(qI?hOB>ZjyO>gg{&kh#q8rQ*L5oo
z@e$_GaMFK)Wp%D>^o!ZvutJSMHeFK5PsVo~UQb6oDb*Ohd1m98N67Cu1hSo@Erh4z
zuaA+eM=~tcoUWZvE>NQ2eaP|DP?28eL5nL64~yu3r)r+Bf28CX&|^(dTOK8591%p~
zpTdY5V`<-JwR=NjDWIIm+rYdcVd5E$HT=+fY^oj#f*p-)wfJ&N59Sn!NARANoL9hL
zCO-hk?Kbft^FUeW3OEm=O`0u8Tc~b(?wpHg>96~^^AH|Rso3m5x2HJ1aCue7eFSMK
zWi@<^-fVd|RMGruxFlRNM^B!LtMbC*+K)L0_mowGlWe0kAJDxs(w;1D)(+>2-<c5&
z=h}VppP}2p-=SNcR7<C!iOKHa-=9YkW~&qSMC5mknG-e)Gt~8<h~;0A+vF_<6A6i+
zh6WcGmxh)W9;=#QQ3;WE$c7aW%a{tg2b)Yr^BZ86=4!F>If|kM$~__GYb#w8_zE$6
z{n&weu&B|^(A4Ywh7(z*b}X}lriCJ9+2=2tLdU=JqsVJbyf~RJMYZX7hwkyXSvVOA
zVNoY#(RLb%!X0fdP@YFvLyf$i?t-;WSGq+iv|EMNX{VY~g>swuq9LwmQQi=tIP8q=
z!k)=!^6ZZ-E<a1>wFX(%{u!i8|COm4QCygX9k=H3)EB(4EodgZ|Bxbr@`ia;=rywh
z%^v0|^}=O!wR|UjCmwE>YzIcF(XY1@0A$j?oLHIsfD6fJmpq!85<p#HY8?_2YJ$sc
zdO}xISI1vkYbw>i7`ZWs>J=h1^n>pp^h1wxbQZB;3jc_fpeASu!6$ojA8mrc%$6pl
zaz1XDw+c)0+YL&FUCpdewuodpk@(a=MnwvzEWabaB(c);b(8@eOU~{b{(Y-jyn|0`
zV-u|4yl~F)T>q+uJsPWG&hOiY$P#Oef9Z3W;UCXA^U6b@d?&*ehr*^6ld$ozOT#=C
z%?p&Z@2)ai>k$>QAY<GN3$=yCB(?7IbGO<?chVE5hQ0|KMeCMgZ|>BVU)Nh&@jBMk
zd1)D$BKkN;nW>$MEGrol7cnmMkZvQfvMVT!@0>x26esTl?u@uEdKEN~1b=n$`!r$m
z!OnC>Y_wM8w1$bEBs>_LKYq6;f!ZGL6#30yF>Cw74fnR4IV9BWp6B%P<M59U>(uPL
zbL|%#H7x>mBWgcytHvQx;=QOScD7HYDU)qQU%O`kIZop9t1HJ8hT%>7)jBa!C@uy2
zFA=eI9kBO^;SX9bo91UH7xFw60y!SMlxWRYkr>Vs0~|}1Gp&&{c*^$7E3=88&hWn&
zw|BNA1oR-mhOkph-#8UJ9A)KI6qv5rdVW*bi8(iNQwh%7c$bTsSx?ZUzMyT7l{~Pj
zsh~a!;SaNA@8FMUgT2l{n~;K2={`#@0cqdZ$QaBx;{NK@4laIr`%MvDyKwhJPkR%)
zH6{JqY^#q?bKW?@?if(TMT;kBKj~qTXFY#V(7w2>rOBv7me%PhK<NI0^~xlR`FwSF
zQKWG7hXwvdih$~Z=VsTo6=IMDz|0?1ts6gnI!?&W71~I`y*-*dJc9EXl_xU@gda=~
zuTj?>VNuWVE_nTX?!5m$_-l}qXon59O(lq-Z*BiH!we1ceBN4U@Xs&-RWsTPb)afy
zvLHs#ndZy+n!{|LYVf^0qbt74bA-dMtP<#wXG0BA<KYvzZX!yk!Z{=@a1)S$n}8R`
zlZ(pyY>f!8-IZpknppDup9`0RbV8qu1Iw?^ccX~n^x6rEg)^^nPuC>C?p)9rPg&4t
z?(O)`%!?+);1ni*c%_v-`EpwI8M%3Ru_}vZy5@M8E!0b)bK#AoySlGx!bJ+r;=4xi
zX{;KS&n${L-tB*v*qGi&OC8)^y(Hq^lYFQmv!CRmDE6fODSf)n5iyOQeX{TfNe#R3
z4WGWdoR%66BV`4fhQs8|cHA}=RIe&cgsbC=&m^2|1wm8O;JD<=PV!{+0p-Cy<-zl5
zMyLh`{fxn(X1F)U+=!rz96eE+Tl<*RM;p<PKlk2<g{%^Tu^qCYYKEH4DI{OOac_r&
z{%eDbb;SpMwF;cbA!_N!I8s(=aZi=q)-Z?nV{jY<usqfaZHgN|0>l>rji8_ew6|Sm
zda#0ND~+)W<l0w#QeB%tuG&{7MN4n-YX;6&iLmG!cAHBobC>nF^I!7>LCY<<>_RBh
z8qh{e&I?0@4h_=mE4f2|s-4U{DF6GxQ~;x=2%t-x4`Y;4-O27`O0rJ&dy0xu6-hRW
zoeVW9T{wcjI{GOltP<xEe+WA5l>NzR(9={0(Y`5A?)pp0WqB0RlkG7K)Z9Y>El)U0
zrCd&=7gefi?|vI;$x~p0x)>eqPxmvQG-@IScjz!~!Gfye-sG0X+z)N?bNIva%O<v5
zRi6t~e6G%0<lfZ#ZGOx1cVq8Y_atkilhF-sY4ONQ`%%y2Z)nb0Dl;r+g)hGF%k|EY
z57CM<eY55NS^0(g{Hc5EHaN{a@@JLN;pB}|TvpQ42<tgYCmaSHXp;01=i~&%0vCbP
z{`c5e#bmC665xBs(p+vkf2sAQn)wj~d?<n!_4FGFUfE3HN+Y|^A3Um^B|*T4(Kz;}
zI%%SzL254z=9&fm{o;gLqq8d*WGMJd!nSu;?RFZ1g?=y#$15yvCa)OylX5a8h)q~u
zK$Bz?R+Vi=_mN=Ezdr10l@Q<ia%Wu+h3<IzN_njyjye*ar=~A2LX23#APu7AB-t^I
zQ@V&Dnp?_di8JUktsV=cE#1cOuTCG$KY4L74a$klFquAZrM<moiq}+Dv2qJvU+oae
zR1eV>uV8qH^M)ymkmhmEdj(R|a_YOX$HMSF{L&tP_03%{dA?3jI2;Trm|meixuvNQ
zZ21=8E0=Uoj^Fn&Ka%Y&pr)=IQlFq2Xwulbxg;3S7zm%LkpHE;=xKzA-hKp1-T%EG
zuqBK*LB@Xw4LX{Fn>e<1{8Z4}w;^YCml)R1G)WSlTaE51woX57{LOP;-Jb>P=x<r`
zYddd7zyo|i4;ibEe?<f!+2}tUn>(Iv6=Uo7`~91BuY^Mny7@&3WT8?-DV3%eOPp|n
zJWBW-LpCEdOhywd`?3DdPE?=cO2lWkp(r;n#y*%!q6d@;7rezR-fHFkL^^e9=lUr$
zB?}rYU;E~S%hX!W!qiax(PXM-?7aPz|4k&w0JfTEHH>NgUXsOjczsLWL#?^~qw9y|
zqKnCdDr&VqEVH?Yi+<J<nHfEnR_LIgQQGLd`2)){+K+}U!IxSUkx+7F@7k-ed=7)I
zSeHE1R*H?|*^6rjXVTw?7vE4DcKS=dKe6|07cfcCA!wMen`T{k;%uLNRhE%Qpbc|G
z#6#S&Zw!8KSLXxHmB1`2esN^bS)*-{H5YfPly3dt{8ptw<rnB9<0Q2M5=Pw_!eiu>
z84m?l-duOA!JVe$wk9vt?SaMs?+Zks9OVxNbBD+E$~2gEe#Z<NW!K|!);J#@=@o||
zI@+JrL;0-UCt|(AAKZMa<&&8Z4%h1^L{jRFcWTne<dAi5tLFOh@%B@XEEZL$0*4x`
zfteZBuPGZR7bPRA9*t0~SWIOuL`DW$dU_12xjP6TVF=BN1i8!~`=m7!u|da4F5$8Q
zn)J<eW1wZ!k7@!D1uYLN1T_)?tpuILE_JI@%gN{GnPW8R&nvvT(;H<nbGJB?5#{1U
zjYZ6>mdCti)y*`=N(9wS=y6CxRMHRrKJZqc69+l@b9+T91Y57rFDY^*D6|n#n?p6p
zyTKx#QnY<@$DI(5D!DP~!NejO#7Lp^+`*9a{yjzM_}`@q*DF+<tYxLd1GKu1IySj7
zDUc=@bCs3Uh4@>c;Cl}0Sg>wCNY((QIFdU;K)0sg#%Fx*9n7J@`Em)ai3w;oibpxt
zIm0<^4Z+!W39k1axl6@vd(;+Jb+okCdHP!1qleWP>=d=w#G0tb+@VXEn$hE!haS$N
zUfYI*agdJR`YsXU1BH}KLZUOM`;EfapM`2~lQCnpTlOV>W{$h9QfTb|#MwIgx+Ml1
zb8l}*Iov`Tvs8!r$MA?<=JAo^Y2kzU@N=8zi|W;FPmL&R#H>axNZAY&$!{1V_z<w=
z?P_dlXl|{y=-Du&sxmeXmtYt+ym|f!aikgRmajKoifE!$rPaE<STUCc#*m4O`1jn{
z?%uh??~s;`4#J5h-|mDTtD9M+Nv6LoD$0l~grZ#U5w0uACjMEVyuAd_k=a_ya%jJ;
zMnAHpenqY^Oa4gqxzyE-?&fDJIts8SZVq&8D*7x9Y;G~dPUn(mixa8U6xGzKvCEWw
z@jR87Y@U-RX768@Bf)JQkjI2%h0+)NDXlCURT*+tqEdknF4;;h3E}&Qgg>hD3ln(w
zgY?!{sRWXk*apJ4dH1a#$rR`|KBQPoR}WG@L!HM0Q&m`NtvDWH|D_mtBX;5TH8p=&
z95YxAYTEjhiHeoZCV+6Oeckj-9ChL=*()S;#Uv|V?eu=-^W|#8l9;tW*rU}0IW96U
z4d?iS$-!hTHw)O+&>zu^1-VOSwohfURX)cru&?lv$|r#TR5P-<Y|w(_|BoKdLolnX
zqBzayc6-26r4jYSN!>nO_#-Xsz4`h+5T!wMZ06vPiyu5iSYXeDo=-O#m<r<?jM4|$
z5$q!^byn`pY;}?QzAxex5?I;fhFIGwnyUWvxwrE{kBO9gof264XFvyz)g~rDqEgX0
z<YV&U6>|d*yV1K0(5=}+Mk|B3KAwY|wOr#C-_DE_<W|bSWt?sq>RB1g9(I^|Sl@JE
z&(o@TZMENRv9_l%9C9pr^v*U_BZ~$<`P_^$mj~yCc9~2G3Y;qO37JhEg@k;g5SK%x
z4v{}vwm4O3y;<pbSU|%G`S#BF2%(aYicpI4Q|x!c+viF~p=4hK+jN4t=A^XYqtW>!
zW@fG=UXhmxhD?L#$gT$uyhS!ADf$FwJo13RWsgQZZ$1qV>QF?w*;%>E2QjbXk~9ea
zBTHJE<|fre&?JOVN})e=etn{6wDdZ$-Z=>gi6nC7FE41GJ*HTv({5>Xb<Aa(qvB@{
zhi}XXNG*U8v&%oxNGe#J(atKZTJngaHH0!ZWhhZpEh(RWDqqPcrAjS}``N<(IKCM-
zXSq>LP#k;lMCTNZZuK_(dRP)>3=c}L$|P+%;5$VIGDg(8VDHHC^Qk?5CvD5o&@6{w
z3Yh#fD+!lrj`m4_#=CVni-jJQeu!d#vr5m=#^}<UO?l*Se6FN!W!y!0+x%Bzq$o!F
z%7)5giTle2DNt)MhYqCk`j{;*h`SH|{!K$hh7K$=SU>`|IRw*W{A^GTID1YPS6IL=
z40ry~mS!vFA|@op5tGRetsgKlxOtwh1`x{^TP9*4bbWtZ`rr0o*<=rV-5pC~w^|(%
zNPq-}-n>!Se0JgW^gNx(F|nrZLrjC{W^Y})rhXnCfmf!%$9i<#4Th{K8OmlWZCBiK
zV!V>OLR3-Nt*lpoBq8YT=2mrloVXHQ*!8c6;9F=;<mb}w4HWL{S>d@pdhg@hXuR8`
zWyk69o1o3RC#h0zy0#4MfG9gyjvS);^g#u;?}wXX5@rmWSEnH;%S8_r8+-7pkW~q&
zjveCCrip7Ip%Ie^!ne_mCi~##RaI*<xQ&N!uyQ!3t6Wg2tW~3yx1!@zY>Vn^<RSA?
z^K#L;eGCO9_lu(86W86S<zdb1qcM?0oP0V^>3(gF5@XJV1^(-v(ej^?(&NT<J#1Pu
zqTSk4>JbCVC9|k&IFh%Dj^VuQmqv#U!%Q5?oC_pj5r3BEAujlQ7f^A&#Uw@#9jE}?
z44asB9^>zzo*P->v!W*sVuq#Gk-i<~`h7zCl5AFJGH2|Q^ca1hkC<NLb+W@^g+5fG
zu}eiVZOd3<oiFuXtoT`JduIn6r#rE-0u&S!Q3)zhX`g8+DLd^nH8fzlDvyqE?cblf
zU@`qUJZk(Zpy_%sJx}Bh6UR$^UbSvx?>u%ZSD@gC8EfSrn&uN99rL6eDPeIsd1}dU
zUyh2z<1#R00RV=iZ5;S%n6<-mLBd9Ix-z=AefPt639M4$Dha|?bc;5w^eAj-0E6$m
z7VF~R6hvkyvBT4z_FVQVz=tT6;D@2nra^_CPbJ4_BgL`rBKp?#YA!m*pt8H9>oIlm
zC=7nfJDDLDn9sjE*M!n=%ZvDNxvK@gs1pf6?M8?mn)K^V$BP36Ix0O5zLsgmJ`u-A
z@8EG6T~K^Hrj!VbfBm9hZC0>s!?Ptm8v)O8PqZhdEcok|z><MrHxbKmEMYgXu<F;b
zh-Wla>CCugV8Ag)&qDVMX7O;WikaJ)yQPFYn)LDoad?r$uIe92V<b*Y-lhx$K+=VA
z>4DR!gH*>Y?VKe(T|86^qESQL-7Du<T-+_1+Q4u?!hNRYuoBzaJip{Te$EV15OVw4
zL^f$bvy3q&0{(@bZTB|u<1x-tNnwjkrICe4mh2tb2~?c;@p#c;V@-jhV=Zmz(T09H
zDY*~+7e}G1Rt^2CKf}MF0eu~ABL?#*&wvSUKjrv%=6o4DoNJlPR@0N$l`o#Q*AvH!
z3I!u!ZueU+tuPRq<lU{&rN5CkH{#3GGkENVM^|<>j(^cIi!Qm^o*w5cKKGS*ov{c6
ziv+j5>Td0I#EWmEK#ILNpB;h2ZEi>ynRf7P7z@(VhWrAN8AwB=bDTRcwS|WIqS1&8
zEG@y@J%-<$*^<cQt*Sd%4m4^&xiSjpeO1h!lRrJ$2NRYqUJ@K6=o51B&*Z2tHMk^m
zo@-%O(cZm9S9WGE*Rh%%2Dohy;(6O_7&sJr>_Bt)n3Y(^LI8ByjuX$5FJi$C2Y*qZ
z!UlZP!>m^C>TAmzNH0{ea@@k+*`A0B@Wy#~a6ero|3pU0&dyfNz#i%Isx2z&YUF4B
zUoJq(m+PBlE;t7V;H#Jz_!2TI4aN-*$CXawrTYd;UIlhWD}uJu*8y+z%&b33<Y56@
z1#M73c@qTii&K@x5Sypbj`Yd>dyI(>DK-@F8CyiLgI?$)*RIy$NNA2KbU`8ZrE2$&
z!KRF;R;7HNzU{+ZmcnjVzXBYm8Qr_v&CouY#+#;s(<l?9zzH<gafR=NeZEQ$(Q#K5
zTMz(fV>;Qs@mV@cHaACOOB07jW|fp>YsiA-5xRh^Aekyf`7VV^&)PtY00;{Y1J*YC
zB7yPz@a3U|irj*9ZjXula6G_MT=K0iI_*K_S3SPd`W)iyK4~0UoIeYSDs@U@Bo_H=
z*|=2<o8t#q?#?Iq&{P0lUq?>+?tlS5hCmJs!V!J2O?J_gx9qs5j@&s8fDFfMuT4wT
zji!QA9arbJFVmhPd@M${v*8PaZ79o#3@1-4b41#8A1nhG<BaV3J|QGrB?J}V%E<nv
z9z!-PQ{)?mVpcS1ztZid)TH`x-d53ful%)%v83G3+Ed$eQ;Gm+a&dSE*N%_(JU(A!
z(%x1MVL&dK#uWU;X;Wl6oqG{tZKc%|*qfiKx*4dZ{Nw3$FYYh#$HDRW^J|TURVzRd
zQjda&dlj3Gx3|q<dg{)K@@TE>KG|WwAL@y|vbx|_m3n5tSQA&>)1UIg^vWjY7^hNq
zW-GwMd454H<@B?2X&{Yxu$n`-^Jc`a&tr!@+p7te)As4WZ8^|U;<<SqQ?Ys9nk4j-
zZ-r8Kj?~GGrF}B?o)WFno>*Qb1QvPu`t)t9$+ME8_gHdV+;W~pq%kz~x?V!bW4y$v
zcd*!ii;ZY;Nl6xy5DUc1k%#g;fAJo5bxkL@i*L~OJ(R)H@lK<+R0?o%VioPP{_x=^
zs}0;zMFq8e322{*#i@&VPamk4yO}FrRJ~pemynxjFZe|GHRHOW+VNa~xki~)h=H9w
zh4+*|Q5HPlx+2#kuKaDhKwxGT)thjz$)m2GOoZVt$3ckP?(>JL`J-wRbm9dXi>@%?
zKhdpDHx;=sq&~VNctgY)A$;k7#UlqCmSs<nIBE?csnl=W{!ZQtQyk(R<_4uP&_4X<
zj&`3iqPKqkKHht}ofw%H<EjMbpCSEtVqKNo<t*64o+2UQK}37=_YiZVzs2>ri-&TS
zY}6Se5jTl24LYRnk$XE;q}aK^1!kWeddz_S!1{N^qYWHZ_>B}<Ff3wd9UB|_@NhpT
zf#sc0+An;!>)YvZ<B>2~gy%e|lOHng_pyrF%Lc4kpsl*oue%Cvi>b_wX-5vvm#^se
zIp)>KMx@kel&v;U-geS&^!4^2zg-#bK%QZIn|<^7cF*736lKjo|66fLvf9u?%i_Z#
z{6Y}7g}J)<5c<w<CJ4V6uTRw_kl%C1gkJD9C!c=?X?s4Wrd}1*#nA=`te?AXSCv5Y
z+5HU)Ee}ZA-XuqoYZWFu_|7LA0zNaq+UOHtf)*^ag`SyfmREz!^y*#L>?r;XfcFI`
zsOXHVRPXQat8uCo$N9>2_n)3TwX~L7T09jyk%Ksi%zWh#thO@AZY$18-}*^}6V=5G
zzqXBDB)mSd!t;fN{*zHVNq^xQFs8#JBmVFS&6<UQ!P06zxocfKJX{a+{u=}s=YpTw
z0Y1-1?oZQOFHq@deecEcNC`=vCB($U@Y<+*Au>x#C9yA#dTP46BbkCXgM$g|aBWuW
z{f~y+E{MRMh7)#8HueIl``5yOXOO<~83IUF$Bs@%;kYI|mJlPSZA+{9DlPVjoPF&u
zkY->Y7+~mdAWRztL!f1CU-WIo#qEDM;~BAIqlNx+YCw-?1S?Jh<>@UpyRi@yc|l|E
z0UAomG7A`SWzG<h90)LefsD6$-X0zr5&&Z<j#^+McEFJ0CJ$vr!IW=!axstWuF6k`
zxxC1k<ymycoJ!ZL4HZ!DHo6MlPJWlqgM;>`V`U3w5xSv$mO0|{8W?PGIBl!R$;r;v
zhoqb=Ej@}zYv%TLRZ&yJsv`-?*i*wXKoDlBBExW-T~JopKN2(+$>$?1m4FeaVPy`~
zn}|G_z=8)rmn_0?!N4!>519tdqmv0YyoXNi{QRA19=E$s%s#g(X~##FhwGZ5@?A0!
zTHXv*3_4+p_LyD6Gmp6MANK=jkl)di9#Q>JD4KS$(ax%emMbY<cxOS89n9L;Uo*R)
zcsGZLiVR9O2(@-;F9|&nKDE8b*gxGY<ESz3?rt;fT~Rp<j17U;K(y&-pQSSG$dKgA
zv8Qj}TEKXTiAaK!<V3^WEs(<HEmtK=0RWI*&(1eDGpnBa$Q5p`6+Sm<Sf<^%%ao|N
zp~HKZaIi@OhCCi968K=iSz1YE<=v_g;LFy?KV2kdt;vcy(VeWhrFOXB7yU%W!OSe7
znt&L4w}^;3uTmV5VPRaPF)}vh@pyCH>~fln#WFQ9VX@kVa&HLQ)B9Dj92grS1m_lD
zv<%Q9VCfn4=0o__e4KLQV;(4buVC}UY}_?cYRPC7M&vcz>125=4Xo|(=oXgfsrNtD
z+~=bkxx6g0$>ls#0LWY1i<`{%ve|_QFe#j?t@hfm(-o(}{}gIQEr|vYG0xrRlzftP
zN(b#G?BP}+$@oI7N_C7gvO*{p_CHO)JyqP|lUtr80<Ax({ZV)IMLUU5Cb~By*p1Y}
z*xvh<JyET<Y)6E*rJ}reomH0*Kuw4}3k~@$;P>^@%h|e@xVX5PnN$hnv=a-5JD$JE
z+X#($xs~zoqCG;ix0>k4t}0otFFzm_;19aJ*a;BR?6w~8I`)9d^J>Dor5-iO!O=>L
zocw#O@EeFsNdj)}9_OX9P!fCLUlp$x>dIASJTV_7MKqr>bg&@0@~zxh+%KA9^a}U+
z6>mFO;;}<a^`+=8O0W0$)}ui!&Cj?bg$Bgwxm7X=PT8wuPFYmg?Se$L17)|CZ>g!c
z7St)#)zwEwmH-VcHz_qW7dyQQA;tE&tH?-lQeCmxyRThq0(<F{T&rp6u5BzP5ga9s
zBhwMIUM@!eg7%jV5VS-2a{Dcp-7s$Iv@z6~!2z3r*OtAxKu0BA8QV^*v5Db3*T%Wk
zEnz$?Vws+;qG{o&z_*CpkIOh>!I20)F(}?0qG{3)zF?7X?E(v$A8OBJLYaFZD=E&1
z$P0duDjg6`zy84~`xe6dpjg$76?%Tt2C@C+@+b)tV1Or~9Wkyc_K=azlNV!ty+ew(
zS#I9twmo~iJ^xHJIy539C9!#aDIqS-03Q>xSy)(D%fJ}!ZEKTRU}7cDtS={MoY)2L
zknZ}jQJL$_{6*R#jZ$g6kKrJeM{o#%MqYBHPmI27^yd}IJPSM!@-}-~vaRKfs0{x{
z>+%Zul+u`*5KPIypCN`ORu0_4psNv;JS$%~QuZKvquum>x0DHtxOw~0Fz$YvTHOKP
zz|$|-E{2#L+8AD+VoNisIP*-KPg-Oz{uq)4QzSMkpz0`xAqgHmrswBoVNtO{ks{&`
zxYd_GB{%&FRZ``F^bPwf-YMIEDyY%U;C^zM;T|t|CX`qcuASTJK?G#I1BBHE>h94+
zwR9+u<9Eoa6q6zNybm;(D5tLoi*w}u&%4rrDfSfCkrE6zV$)ltQ|a<uBH6MSyFbjj
z^HZI*cjtU~Xo8-6K?S0?$@W*qd54B4pF2WALyO&<hg|Tp<SA$Jy2b{dY)wmxPHp4G
zZQjt|dm3mh6c}n9;+ILWI4vN-CZ8U@t{Nw&CaEU=e05F;=@AH1zt%vYR={&p=sP2!
z_IRv-67bwUTUb~UwouTTQRa>;P1<O`0Q?g0)VT%6Mwh4gpa7<9>8+j>wv-k)K%6;d
z^(fJl%??JQ3jkIuaVjk5m4@sn%(Gs8vo%)zpQX*=qTC}v%&Rpz9q`#TYJyQ>hD-xq
zG-4CP^R#uD(fuFNq<7C<i;Ih|+g5l+N9!Ur{WYKfA{DE_M>7sDnfGoMfT<*!$=pm9
zBpw2=raDfX5pdh!tW87yq&jSwXUTZ6L!|Ch0>$8K^<y^jb{@mK(gLC@mD?U)^X&el
zP7m;iC@0wUaV{yt0E8!;fBX4IV;xOZH73yeAZEY=QK|HpjvEGhwthv>K*#h@#v}g;
zs^~P|b3jBLxNEv^kAm3C$!?Lpv92_9i$)S)vl$v{^V5B`;hzk61H6HRZ*$H!^iVeJ
zKm0Wp02P3UsI|SlZIJ{j-<v&d%Rv%BTAG&C#;&0c_~p+Z_u)JN#dGJ^>z!G9P2j@9
zLbm=Z8ZMXJT_j6m_(W#7yNh73{Rh5f@B_ww<|gdscE3B8QSsaWf|KOr<ml*+#k%i=
zwC=fC6_u3g){oE@uI`?ttT$Or4bl<f)j0C=%irjbZ@2FYi$##)QHn7@z`|;3f6$@%
z7`ND_`Bx4^O<A1!*~zl-*7hIqjrr<2NQP`L3q-_Xfu9-IK{&@rS?aYO7dcYv`R=&k
z*Z&kv`f*0jLkzdCN8c`vc^xy*%*;X;QzTtMPF^lbWqfuvTec80aNvX>95gb2Uz{an
zIvkR`M0Tt;fQSmsr<<9T=O=apbTSZP<mx3#+Jqble_*m0p`zy^Y2%1~>NBhcGtT@w
zGv(#NLDU8He~v#<JHJ@YIDFcqq7)YofenGxL3m~5znH&&Q1o1O13~LF3J4~KLAhRI
z-GL-qd0ppQenVs9-2A+=(0iRZV-?L3S`^r~{QXt)>I<Ce$?BL;)IRU|kloxk)aKPl
z^GNF?!I+zWf$7|Zin6KIUmt`{lZb}njXMu>(;8!ux{9oz1-3>ttRk}_VV~@O0IH$E
zY}jyE>Jd$iay$)sNqi(!dk_K2BdqWE%tV~@*R8FcGdE8OheOUh6dVjeWLIWLLB&<%
zpoPspb>zia;j#2dSYSrrPT_#nLOScVLv(<f1#AFF)y{3YoZ)}LOd8r&PuAe}L@g^Q
zp~ovS@gAtGt}U|QL^qC)%=jX7jqX>70^-fWKsI@K`DnSA#Vc+LqR2k|s$4Xsg=WeO
zvAY|Rh)wVjph5@=Dj<W0Onhn`18s&r?Jp*s|BFdK2FoH?<^GFF^)*2q*VRblG=BA~
zGISS1mFm(`w`!9+EjM%B%6{fxAm8+RdqFNmK^zhgI#Pe3rt8f^t7Ai_dL@qV`Ff`+
z$k`{2i?zlPG+-z`MM+87h-q&fH5Uc@@1X|6Ac8h{%i4JDKiSVItIwz=CrteFjyhN1
zn<BYi7^RXN;apsBk1O01dVW5wq((i1m6<wGngMwP(9sBI0$#fN9lwGap`^7Kw8{HM
zmn+hjn-Ynk=nNf-Q3?JT%n25a-Cj+>*BeHQ7>mD>tp!9>wY__&doi&Lo`O#p7#P(3
z)V0=DIVCwNSq7xs9X%Vj=cgr-FaViUYLm+<9q_IdeX^ng2GB%k9@b?52pM!erJW-z
zIeBj*($kXm8A(1LAD8VGkYQjL7Gc&;Sk5cVHPHvk$(D(*AdJ4vuxw#P4OdH1jS2l?
zp@c^PI@VIfB`3w*Q|$yK7h}f^puT%6+#@`JbfTtSTVGpAd~A0xY<KD>n78vG^gNzc
z3Zjdl1Mo-6_z13(`4ZO60Fn&%OA8WUz1&2E42ucR354OJ$*QV;&678py8n6T<6&_4
z!{dkDIeUBMEYo3DsfFJ9=lsu)T?q~Bysd4~wl+4m!9<11B+1Z<RCWKqFJL1Wami#D
zUra{J+^?Uqr}kwsxV@jYh=A^PAHf_s+Tk*AEg=1z1zU<!jR-w-wKcRNHKG;?q<e#c
zjkUe=uFuGh(EdI82)GQtf^>weH7Qd@BQ<?~FZ&xf=gON(n)SB<qyR;~t48dNkYeKR
zOkF%~6FiL>0wpt{m@J0^y70U};^co$(=oUY#9#(<-9o`q$=<zla57mukH_ofEwJJf
z<nv0DKB^lvVW<OHYdP~VrhnSNX0^3Q7t|EN!ohAgUcBL_yvIdFN1fbvELwS%nJ*3L
z5JtsTa8_Xm6X+BcsQ<>PovW32OZ2KxYc7FNsHNP}Jw?P^kM|&(NY`z}arJ(b(+b@t
zw@OOR!PiulCHubst&XK8cM}Ym>BoY!CvC_RwxEi8*x0Utb&##zal5_I+IGw}Mvs4Q
zvjh(VaQgF0yDa^}I+^YY;5T`aXJ)TC!SnJ=&d*{^$;s4T(CBK($Yf|`(~)d+$dy^^
zMMpuT;W9Mq&Elp&E&qeDixK~4^%AUqz9A>*DsoJp5Sk0-lxO+0npm0t#fnPOQft*a
zKX1GS2M32oXf{{6XLWZfVqO5>p6-@tDNzd4l{OqP>8s|(8}fG>7c+2x?W1+Bfr<&V
z|2fJ?*lsICAlZ21Rv(=|x>r*@3+02Fx3#ezzh7WrNM0*R%**n&#ND*;BHpvHb(*E9
z_et6C0rz6MCy88dC<h*cnJ8|?n{GvoycZAW7)UktTL_W|jl5L&R~>sf7o*+~6boho
z(GhJYjw;34LKo&p1Pq9r=!q5&Q_?_VEwn#>5(4N}4hmL`!Nk9AHD1y!D~2({0phV0
z=^geLteSOW<@!Xn-YA}(HO_i>a=^8Yd2Kb5ydvPjeLA~H`dEwosFV)*Jb^Dy9!KuK
z6`i_crY$azYf){~=*p2;8w2)SE<pW|))#;Q6P|=52X=ocyiK@(8OU_0Xv5US3~anU
z_Mv@(1;D$vxArbjMp98ccy6sI00y+{q`?u@!9bBTkp_7-RMby!7at`YP}Bwkzg3^M
z)XD_=Tr!oJW_dKguA>5ge)3rE+n5g+ue&ND9hGJp_~Gd-Cx)0<de5CQuh62)DtZx`
zc7(cTyl>_jn+fP1RW)~ZS-xH#G$NM!_nYDfga``A(CW)ex8WZ0EOAg3!$~Zo0<$_)
zoDP(Zh$-R#4c5$Uxxni)5@apbbnv4!4=(3s|23D{xed&5(7YY<f>>G{J=yOX34rie
zOLCj9TW4GCKd0q3a=hPrfxiu!+~>1!mTaL;qw_Ot+GydKXz$O1Pqn6clfP>Nvh<k0
zbx`MS?(g*Ijz3-<h~~+XQYsXJ5zht;d+FBN;CJf8$AZay8pO1oPN+swtg*|LRGId6
z%JaeLt7aVg&2OPo86i+mt5To1E5INo#qDBy&>;Q)GDx6Nd*K-zD{J7ChzOB7G`RgF
zQ)^S70G&3;|8qX4dFC0kn-KE+(X_`*2{3f4OU?hL+d8mfTKdl@p&DfsH&Pm2eaE6Z
zyPBesyz+6=)A(r!gM&p2THEs8x=1y#Sg5CkbsNYW{GTTQBV5g5!Y}$>E*5oCI*ueE
zHa6<#K;&C~0Qs%1Y91(n^D7B${`!en0TQs6Fjc{D0h?lJz|Z_k60(AcBuBD>op-BJ
z-^)s&fF2IY%wpwrMSJBB{sRp1Ki`Qb9#X#H1EcMWApqaD=ufFbnU$)JO6c2%qUKe6
zpQLh=l2ecD<jFF=%&Hj2z`Qqu!W2oHG%>w53Pn}8v=haNBYLd3)pBqAG_xpLHf(du
z5PmaNnym66XrZ+IN3YU<>Zm$4WAvf;U$skM%A%vN+IAX$KO}mnmLMl+gTm5ybeh(#
z*8N!1Tj~fMPO0MX{gh1Ky0~w`%!_$zuP})Xttk=L$t#ObH94hQ-V7SJF9OHaCDyV9
zp~DhxaBD=|JN1X!L~lg9f?)3g`qNk<oCE$}TG++#LL;*}0-MEIL1eRA#A6R$ii(P^
zU+`lFKHX+~YUZe}_Y>#hn%Z}iZ!lfoaNEL90CY{qTfFzd0`AE)cuI8@t7ftd%tV7o
zyg7ZC@xzZFCQ{BZ9^X=jg(K)WT1+xHINaFJS}5NA$*S<Af=_r>Em&f*H{Y0oJ$+m~
zhReh27)7fwMS1dja`%0ngyy4i(D;IoLcw!p=6&1Ct5yC$Qg8s)y^TweDh<uU6Ko%T
z|6%01{QPDdv7m37jGP`hPZ@3@;@SNM8^3q{K%r08gMpAjqFnd6h~j@s)<;Zi?3G4`
zzRpg5ZSA&r9kB7oZnFY5WM`F~(cXYv5bXlTlch!jQ`0;D2EOMNONKi1nofXWfj_~C
z)%<rDHPmB#Xuv*vM0okolNFsaW=DF?Vc&hmviTttpImL4?OLXZ7X760k|az9CXJU}
zk>(GqAEPNnD(gp)P_!3nu09sKJ@&sNdxn(<(MfFZvs(w*@p<n#(^pf(P~UH*y>Zr(
zPbgS^l@%rgjyz-IlB1msQKxOgOy5K`m-{pX*4Nj@L0{ZIJ<Ncu)8wo-HiS|qtCq5*
zAIjQ^-)&44$egaWj|~h^Qc)FeH>iSBmx1ZY$;r8d!L#3B1;Nb3^!5$EnVA{w6c`f>
zmRe+FWWBw;bxHaC1254T2?|6EhQTw5jgJz{>2r>q>h&<nkBzjU_X^ubJ3Jk$Hnl%~
z;Fv2T^Gcs3ZBk(eu9jti)d-sT9>|M0P!!zW0z+M<li6*whp<Bmjbc)wqGTh<Zt2-g
z4X|tUG4sI$J6#6wdS;88AkC;$q<1wUHEF6zrvj>+>QTz_@<=}h7Z1HN)UJmF8kNJP
z3&4b@r=V~~STqbcHT8N{skGn#%zzMc*6e|`wY70o^Z&NoVBOr@*ivYz5mdMNjcO)L
zS=25Wk|d3cwy`%<*cw^V2pYX(q<KWyq<ed^u{UH3S-`*kq9b@vsr4U7^4P~odYy>i
z?aB+wZM*7{oxc-j;{PG2J$#M1&ty!;ZxG^K#ZQP2%<lq~Yyb4sk>72p`9OL@pwI_s
z-aoH`2{A!|B0muEK#iXFtILP>!5T6sf<N4uI_)RYX}GCWsZ>F{H4d2?71rF`cxhu&
zI69Ht_mnDhP_76L2QwpCyI%{miC(k=2xOuQ)S>AV>RdiWdi8}he{`36C^KW;aok(l
zJlT$!jB1gg=W;w*-`i5ZZ+6NP&<5p|H??L{JL6e`?VJf72DH!?w!c`4IeyrU4ykHB
zoG)Jf(s2=l@6v8@o%khQL8!O-a-$xv8HgLFPd)Z!T$-BQnbvL4TDa0VvQr7&9#kqa
z!ozV?Dq}}uxxjTX&?RWxH;0dAa*VN$GAqj)$);58H>WMK;f=X#jB&g5yr%Bbmm{a+
zIkft$t#|usadrJx)@n@V_OjAakoIw%wfYn9aGW5`;X}G*++7-))!^kqw?r-%n6#{1
zRwG@914D&X-)39nspx(_iALHrI~mF9^H(=#E^;}m{zcqp6lK^wWA|~%ap%m2jkvMi
zYlpT;BB!~iyHcvjIL5g#b^a_Vff(6FW?M`1&bFVJ(apIa##(37yunD8{jkYqm1n=t
z>+z;2#U;+W^u8HkK6C%})nr<4KV>^I`$Bxo5WT<(&W1C6rl56!%E8D3u~pzMpPL*H
z`o7d@f?023c-z!(<iMOmzw^L9Eii&>%Vvf@y_~N{-NE#*$<+GU2GdQQGpG5eJ?8v<
zQ3*S=%OSJR)0NiNJP)FBq=H!^ferxpVQ9g&9`9?nnPnVVR*n_=I*7&}<1#MHc-=eB
zdC!lHMXg(>uS62?#yOrd)o?nVbZ%Z!?*=3oEorjg))~F~PUG(G{^7%iEjw{>*g!q7
zt|NJ#<MByiaK13+nDJiLG=Af&8s)mu+=!J>_FG<6FHbquF70V>6OAqnRn0O!o+H7*
z-8HR&F_?G7r7BARj?F3z(PV%o(gA5Iw;)9RBti?{PIvBiuX6U?nr}}z^BlL@$y)ZX
zVwPSS8YaeaN<c=2XnOqUo-&;wfVn<Tx&iqtVTlSLZ+v_H@eT6LQ=Zt+DD>i=KS$cz
z++&lP5+0Q$$pQ}};o#X;*sXBNXxjVzZfX|Soy+avLV3`qo2~t{K;XNo?XA&9DO*Lt
zm4jD5y@R6R+b1r8yz6mJcvW7qmQk9dlckqt#)M&<i~Z*jen{@erki+ZCdx#Kb{-5m
zEqvyY9l35+=g^3F_a%jy+{(wMvkt#!6wFvb_RV~nWT&TU6{psyLASCD)<>d-hIUC@
z6a~2HO5zu)j~knYJi!pfD^FWr$B*XdrDc*?2Il4x;FG53wwt1DOlQA%k&ReL^^ef`
z6R((%^|kEXo#w1{Ya&@SYJRXgk(h|o)OcupO{(1|y_QiB3BznS4x>z1=?639=<&UF
zZ18s;mJ{RPz>zb>pGrn=kK1F7+Me@=B0*e@h6u7jjbbsq&fv)(GWstDaw^cPF8D{N
zk4ENQEEGgkjh^h*%~Sp#l9$drI|0_&>M1xDt}&~@^g3S^s*d3B&UrYbjEs_DRp*zP
zH8Ezov^o=u#95|*ux}rMak;oX@}+h=gE1eA{>`orb=Vgku2))n9=2D8D?Jh_U%1KM
zyekRiFz3VIhK2&5YnkWM$oofz<tN5VrO-JtRx>=J?GHj+uFK%T>E1ahsjxzYa&x<J
zH}9$!$&1wvjRG42KsV~NS#H$F)1p&s+KGC3WY8O;^rEDP{cvc1=*4*J0%P5*h<UHg
zbk+oZRt<Vy9$^|r`uj~a^O93XU;q+YF}d&QoNfI+EN)M+<b_hO5PmO$mKd~4Q4Kby
zZ5>r95XH+bwkvOCP|(qU-rH)mM72p>gya|%MPjmiOBwDvCWlC9kFD}W<DrA|m;Z7B
zmOVUQwuUEaUPor{y)68(EZyL9T#*iD72*c+bxT@Hd&HCFCMqm4zNKb!0<l}-RK7~L
z_;3OO-0@|uD#XP`u;`q)<!ZZ!FzhQ*$W1r3B}DnfskvjF*?NF17?^~f!Q_f5qQ+oJ
zY%cTR-A8RRHClr<>CqmB;s!Su3nvQ;r$aXES;wE^@`x+FlH6zN@`qyaxB+Z6@TikE
zqZO-hUzXU0%}#2Vt0vOw{s6ME_NzXfJzX#_7GZgVN>ebvOM=W+Uxc=x|KvRcIUUa?
zoJEp=hk<ZUJwEv>Ld#RJW30;<w!Zm*L@w?2UTmPHESU;cSD`{aJa#T=UzTnsN^|fu
z!Z$$zmTkro+?ed*Rr&XuVuGkuzlpOELj%<@EoxZRMRa)C3mZ9reg#H1wlZJ2>s%ox
z4Jmi`D~%>s<I~O;T=BHq?A%GU@2VHm@o2lsNeQV<5NJVyCMsDssD5|(WqS7S<lei{
ztQqwyW?a0qwn$TBugUNPj&D;_!P?kQE~D}m$bRwINGhOBUD!32(x*6_-hcBuq1oM%
z_Se-;eNBDtJcrMvfu7u?EhH3xi~<1Kc#9D!JewIx7TDfy>KfQ~*9+QQRZh`LqJV6^
z-k_#CVyLo|hw3#U6$8V#$=9*<DHTfDDl%PJH#Vik+Hh>;mCq&mjRD;Rsv*}Fy`|rS
zkT3lxpa6kk@@`M2KSmvA{mdp%_Y-_U+S;n;q#1h4c^YZuthzTFWqqfuOT2Aix8FNL
zh4KjQicE^bhUKT%e2N6<dh436*QOFY-?SXsX*|$cZW8>6Vt2h9uBW<WVpp81J$5;2
z-!CK;CNyNMvh%d_LIMCeXYV0Hv(KVR?Q55K7r)9H%lU6RuDv6So^}C3bk9*wRKB3^
z0jH;1<TRvb#86ahGS~9&ZS5%!oCcr&7Y`8NJMHW$-;RHqcL{C>9BnVK=KpZpn!pla
z&4{MEpB_^)tJTz8TSiEqii{D9)=KmBkE)U3yg<CsbjOJT%EitTSBV)WDiA1@=;M62
z6J3f-_}%3e{yDYh=!mT{*mYJSp^MYmDT8%a2e*&Q+3EDp40n4b0FWUb2pzT$3_KPJ
zx{U4r*e*EY&@JvQRT%8zG#~ry?5yp`+xNo7<%F~M$L9E<BmyNuyA*fItveR4z~RB!
zC5g+f+VXSCH>sI*%&G$tGG^o1?}80ZCbx&Y)@v88o98pzbq<@;L&HV?oIAA^hp9n0
z+Apj#&Dd_d4GV+_1Yb-ZmqyGMXyR2GMge3er#}80L^nJiR<a*CjDM`9E11GwKKBi0
zdbEA%6AJIKV&9nJ#n`MxJ*->{`oGcffJ~7BM|s^SAFE%EK;_PO3L{SV<g}#9CT+zO
zbRhKL;aDb9U8A}I86MV?jwRY+oC?L3J^j~CHcaZ|p^4-`ehA$WRF~d63Zs}fn*8KL
z*tqN4P0QErG0KUEr}okx5zbqpgyRuULG2%Ne_d&;V_<+IY8te6?c%s^0RAl5&-S=V
zMn-Oke|Z*Q%{lfUXy`SN&R{PRz!y4eY*(?O`0nWBh`~;o&w&0U_UbC)n2Vaas2@5+
z$Y`Ep9%KS2ZK0dZoHTI1>(-Grw=d3d>N)<p=wkhPw$cUb2N{T{+UnpW_!aB?7V`?p
zL)l5Hj#*FiCB2}aFsPz5_c#4UXpa$b)mIwyU?Jjfgdwgyt!a-dO(;q6Kg)CS!i%xq
z$T2rTH=Vnkhf^DMuNuha65nc2Qlmh0s5DTahxX{>(xb!~8T(|(QY_=*GXG6*g~M6)
zazns&e;8IX)cFSqU*CGnG67LeC7<bf?KHzeWneN|JnyRm+zz*<V;4TLF3^v6PyYsQ
zgTv<TqK{)L@h_t|=eTQlo+sa~a<;EV4)7ibABnx0zaAak>KYh0T<uLf%x|C8PK@1_
zCP))JyKM3Re_EXc$Ip???kZy9Q`ihf^J%%f1@)9h`{{M{$6vbYWcU@8q4|Qq>RI*s
zrv7Bv#@q6|vYBclxMgEbFv*ddwl)5+&P(LJyEVM|{J>~n%S)Ph)VSU2>DcWXGREsS
z{X*h-qcj%0YmPz)f$8+1pm(KI8yg3e^ox-}X{_e3E2s0zA~k3~I<w@`V&~-y)Z@^4
zSSCG)NRJudbL1$j&=MQ+=RxNy1=x1ch7%-@*+0M7<I#-)WQ@n&-z{-0Pjg~JtmTZ<
z=T2%25K*y-j@uV;qDc7LyE|3$mQZfia3~6TYFN@i7BSdpzG4svoJMmDT$u`|tzs|$
z*m~=$m(rRV%G2r-%hJ0YbY<)dbUZXPTJ0G;8Scl={y6Xm4L;~~@yq(Ewm+wn21ld9
zZYeoTzikx*t7ma&XkA*XQ8V5%XM*8!LT>_@#ftIpA^QMa0zs7}m)>4t-Py6FtrKO-
z0v1F6=<M(6lF&M@z2W!$bx+%lr~9!gffBFw;!LfUic;Jd^(^caPDqifXFa3dP{DdB
zP9p`ldl)Uuakq`NmQRmMX6BF5sUCB#r>2wBMWp(~?UG-f1~3X*IZPVnypd=Gno#6W
zZcFX#Y-nhP-?eN>c@{USU0y)URz$}?&N`j1LPz5K8LNtHHaL|~Xc5-gwiPpK=#*|v
zYrf^$+f+-wL<JC2+gaVF3HM#@&1|?huH0|)a=q15`m?de)Z1PeprewKj3!%z`w+FX
zTSI6mC~_zE09j?S@0>5acbnnY`dMFlRI5=g9wdadF$4*OPi>u?l6RQ*gI0n<$M7?}
z9}HpUtXB3eyqMX(qdo?vHu+fa?`mNzdo{!v_ds@3`*zH@zAhsXta@DUB`pqC37P<M
z%0%;XV=~DpSf#38m~PHTQDBT!aNCvR1pXJD`Nn-q{l(rClVYN>!l%3b!*aImZgWAx
z1OwnJdg=98G-#JJxP#jp$7nn`JJs83yju-Xqro;ee)Sm-myBzQg6`R|v$>HpVZewA
zX>u)h^_QyF?C)=)TwE51mD^YIN6*~XxjC%|Ta(zBcTpWZUMA&UwY3sRr1`Mn8+pCn
zjk9{+$2yXStX6w{p~@6d_iMA%mwtZ_Jw?28QZy`LD(nladn52EyxvQ$y@>YM37*Wu
zqR41TjeMl;Gl_kDQ8BEBR}`lxwsx9;rdHOQN{Ws={VB;f_nXSFut$NwxgADb%G=UR
zjXC6_$Eh!emnIeN9PU>KCpV1#>;oo}75I>$JsbS3k4U#SB}MH-=u2Kne*!Pv#dzmd
zmeb~3uSUH7pSI3AsI72Y`=Kq+Qmld(DHPWt!AYSM3Pp+pcXx_=C{P@V6)Oaa1PSgE
zylAkZf#Me2-EYo0_nhy3ckZ67zq0q9+4E-4<Xyk#S&!SYEE5}<qJgK3PutSLpXQ~k
z(A9KJMZ-6TcvTjTzkSLO&TG!AYnsjI8$JjtF};UosAZpL_l&GrdjD%pg&C3BaWfS6
zKAyJvuJ(uAWO~)H(d>QMndzA|veiS+raPL4%M0COa>H!!-M#zQJuyC0Q?7M3a~|D;
zG*wEXTHA3;kl#M3<%NJ)N?NKrCd+eQS~rmop_0=;kMT=OR^h(=KC71Z`X{L`0punn
zd3MHR&Zq7g%V{ek;gbEn(OT-H*k_O2{nLk|{4cYmDh2F#boBB5cl$D~S1dby<#-k~
zs~T4CrUm7)jtfMTrrf^G<nEohY4|e58N^`Qzut(ZUAvU<Prh7>ud7S8qhIk6Ra_zv
zOK)F)dUP|t)~$OAFHI!h+NhYbLRLMvYxcd9_oDSDBid}hW|qIr=rqgC+-h3?dAt}5
zSPs$9$TZ0SDWDap=IfAoO?l2UCqriz@;27m*{Ed*G~`Om(Vwg6!cHd6pIl(;B;e?|
zkOBYcT2A$<y%L$JJ(Mibtcm{j{pG%OXc{J8QJYOS$37h$x0G<zcoTGOFt7|GC7Y*p
z|I^%0NB0fn>=8JdCN~l{_}6><?kx+aua&KRrR7ZZa(aJV2auom`i_6t#ug<awzYgC
z459WpA&hAhviRY1Z_MyJhl@tExi!R54z|`vBjGQ>E9STgZ%+u6=iP3Q61iPL=<Xj+
zDxIprOm$q5$i5&cL)bbDLZ3JXyj!tv%jIP)caZKO!yX_iGo48JG1TmBi2no|K!=nn
zmG-PZFA<I`S|1|Voc?r`d~n7|VIUm2Wf9b8;(v*;OUyR=^&sJ=MJdU6coB?@u+<ds
z8+b{Ds1MQQ{$0Yun9Np)mzSea!=vJs%3PP&ba1B;Z<M;$s_efcCh;F%1J&3)90$i&
z<9RRt(+X}qyS=X2-=EF`Ddwj9jM4m9iv$1E4sSrl-lDF#9F5JlZw>1(UK2qEk3c#v
zUn5K~^Ki_3i$zgqEKccW2?`vC1!z{+I?nfjM*A{}3%D%5a~71CrZLz`W4?CqYijb3
z6Hg`tG$*Fc@xvi{FHC7O{SVhV@~n06Bd`*@y?>uDoJ*KP!Wf5<NLZJ7lCPYcwN=-t
zaQ<UJ6o1h?Ca=>ujn}sG9j7oCiSFLqr9<t;kq*cnr%NSx4gGho`}lm+O09>0-$Dh8
zuDm(vr+)H_{P%qaUpI4bH@>g{d_ro`TJ91~B0to_5S6w`tZChOZCwox9?nx0MEj_f
zJf)q#4&1|bgXUi*yf+kgfj$Z`SK>GXJuRTi^J3*piMqON9Kdj9>xQ`Rk;h8Ed_Pv3
z4fi%ps6bA(A;LRllHvSEx`{}T!>>2fkyGlr8Tc5OO7dgQ%H%TYLALNaf8{!Gf-H^#
zyXP&-Rn^BT56z;VRaWb0VNc&n%A)%`g*ewY?BPA)AL|WamR$gh-W<nh5{VgS&VmLj
z7@{D-!Pq8x((Nn&I{0Y{I9R683nTh#Z23&bF{o%#$p7%`&3GN44V)aNv<hp&K8U4p
znQ>dUB3Hp`C2mOQz8rG2sj$H*7050Bm4FWX0&4Lbh_@~CxgzvBGa}bld3c%FnqEC4
z>Jv3rv$ed9Wg)+C5%Y%v(Y;SJ_&bt?vZ<0jXHsTVO~wXXoamFR(`&}3yY1^wRz<Wa
z#uRA{=Q>0HW!M0*u?7VruYR#LREN~MJ(WEz@=OoWAc53{IIG>VJ^r1G?0d^U6~7xt
zlA_)c#g-l(H4GeCX3CX=JhC$X#X(SKlb0T=!2%9T2uZ+mN^)yuWxjt>HEGv|MRWWu
zQk>adev{91|I}OTpUYxDu!UaTMX&n3-r2ja-FJ7PbUnYkCU~0EDD1_|JUPyK;bh(5
zm?;e9HBO~7j5jsz#s$QxO(e1*s0j$@@3ZL%-S^C%0;mV8dHm9FpBX1hN$FoTRJJm6
z=F8`6Ia!T@tZ$Io>U<U?SVsJm6YW{H(yMOf<`XS`a}kjj&d$!=-GlF?xWc<kRJ5mu
zdFB5jK?;m??(B&AH!%3<{#C@~!nZH^3qWkIV;RE>=Jc*>fg|JAAQr2ZvVsc&Kv*z^
za9I-ZGFxeAN%7z(f1MBCCvw}AeRWc*gW5jTtJ^iH<^rZJUy`h9-Z@`{qZ-dLL_GaA
z>@-cMzs#=-a?aLP4t0W97n_Ig%S~=U3v=^&DrK-=(rwByw+?wne+RK)f$<!DES!Re
z80u}6#-AirRl^%EXhrMo`w7P9DUK}Roet+l#(<hX|4AxN?7P-$ITPY$m61d=sK4Gb
zpZs(bGaR`+Qzt9#AP-flSR37KIC1)$4ql<wph2kR_bgJ)HHH{3WTLg-(<|*SRDEo3
zyV2>~B<X*k`_}{U+)3oka&<t~>e>Q#d{RQ!fYzt!+~dvNNGBB<gCsATYhLK&(4bpl
zF47@8{u~oeY>sZ8e;3C1{`Vct?GTMPDP+F};dARBr!5@GmJ?@?AP>Vxdd|1kA@_H4
zFPOg@)Vsdr-IB>Cgr1%f5K;?kX<+_j-@ME*`iG7Rlp>T{Q<7YBTkg{IRUG#|F{6e;
zaIBp<uLPX``krJ+$aP);iVf%qB!!xD+01!4Q9bo3BIKJxxjhF9RE!83wKu*`rRKC}
zCZsi3Qcq-ULJGQ*x7*s!A)?LG?y6KD{sV)^`e@uwU^cjJ`(mGcR^fgxb|0&>oDe-8
z!EK=@yx2i!T9b!;0_o4+`e_SZYczK2-)dYnB$0^Y0wm{a;s<oW-FCLt1;)D#yP0>M
z(_|Hk$4T1rGEhH`G{K*nFYwwbo0;#m{V(T_&H@8j^nU2ZQ~O%ho=)FWm&i7N(QW9U
z4~3Rk2bTB8F%bRH9v^ZFh}Bq2_Q^58bD+=Z+~m@)DHNPftXVem{GoyTB4c1+fu$^2
zMHB+--LB*Mf3Mwi<6M&)!bcDnQ15lDMAQ?3cbd!<TB5_LLb)|HK@BJk&d^j<PZuf}
zlfGkO-nXaIlGAi54Xu9VJ3-R}n6x((^FgoCt-k{(v^$TZ6}im5L8<bUbdKNj`Zeom
zJHO3oh~NC>qFcDiYhEXzA6RSmw%WaX^g7GDkEHUWGNvDE#{>Axs*eBLwc4$zITSPg
zmo)s|<K|;$^tO^X^bk=8g4|&IR)ypHDd@$!X0V477c}A4ic>j8Lg1y5)mjSmxYm8}
z@S_w~s)E5^(#5+E{=m>?p&p-U?>u8pOb=3D2;~3ilet`jHUM1WWF=#FL|qx!N*<pL
z<n3HqcwMIQS>h1BnsU3dKPJt&Vt*<9#qacrJ7Bw~HO)wCD#PG6m)$ry8?!tKTVsY$
zLszrx#N1${ptASbbe(!T>DTO0r_G6SmFS|4JOnwiS&5qG#B=`VA-yE8T8kQA8K-4a
zqgLO@mWl(370ACNV1)s>{?)`GCJ|+*WBVx&yo)a7+aOiE6q5mpZEbze2tXxoUbtX8
zUUJw9AU0_kHli9AMv^#Z>g=Y!V~k1D3SG{3abY6>Bhx&!{uv5PLn11`RHMwy&Bl?|
zciZ57xue?WxHKL}dZJ(Q;T^+P8sM!>tn9*9#`)$Q|79?^kly3uBD^mlzp$V{<D@>j
z^4G0T4S$WdFd`j6T-=t(=V&gIb<;sz`5%MTdquJ3<UsXR%4a|zu*zbP@~z1uwg?=4
zi`!dbPgc;Sj_<5bOx)Nuw0CBv2SieM>Q;G8KsH-w8XBD@_>z>A_!03tfMhRClWFrO
zImOM<iWdoz*D!~F#)kMOTb49e&ssw8qG66(HIp#Y{;M^C-Y$Xn#hb0GpdnPvM=<)X
zihl>=K*D?|rCw{M%zdDPQ0E~@lCSP@Zfn?TenTPv6whO>)zDVbniDTAf~c6lLzr0!
z{!~^#@<Xz~yjTBZVi)~lMTTvipI&Rm7Gk_1as(Y_ZWE&KZ)T5VHLUnEYRngT!9IQJ
z_4_GKno?z1%v1pvX>lYm*UzvkXi?m@CO?vrG+1|Kb4K9o_lCIKn>!(sTUQ*7ucAlQ
zQvLE|T>u+9OCXnA+u)S>?;7u!I1?yO6g@AK8twm9Yq#DJZTRy)7#2a4=vY!$2Z%lh
zh&_1GwE}t9TKuE~qls&T&^&DN?Y@xXzk4(qJq1bjq%|0=+3o!eO)?x}9eTE$@Zu;?
z#^B-CwhB`sC_dR?0_@rG`~p!637L>P$7NiWk%(#ct3oMM=JI+m0oO`vGr#RpyT^x@
zbT=h0^-!gG6;W7img?{BGrTF5!jqpy>qO9SY6;5^x_@>Hf9!1d>Sxoc9ehgX`*WTN
z>+z$fs~XQS+)#X0e{SxI>w4eJS88i3y4|*J4(JGLwN?8NeS$)uc3M4;wV&uG=!i7r
zE9EyJc<>M*{RLdFxclpyebJ>G>3YxXQzYy+&>uL!*PaHcnW(8|K151G6xLS;b|&Z`
z58*s8=x!GhCXw?1=gc}0a(K1~4K--?4WX2L6u5ebmt45*AWp_YG2;12+}o4(X(8|5
zEEhrd0jk3beG!12mYDryt8OKz<+DH~<ea4gzTVpr$WMwb;<~Z8|BnMS>d#q72Q)@c
z*V^mM<IMm7fj6@3cKMEBgZsbUi4r%dBCew-OC!d)AGYPCvgvOdQ&60n(*Xb*o14@k
zuDyMIPXHM8;>qdh@zK$bA3yBu>~7{x<};N*YNLgb2c46AF4eE@tc8L(I6PmjZdEL6
zW17)0sJg5{qx`xS)>llPrjX-U?n(u&OYsh}bPt56ZZuKJmeb*<#KBiM8tLw4DsOdK
zK1>ch;;gl&s<B=Xsl35@r+39_mOIw*=SL@RgG59}3G;W`a}HEedq1zHSM{_$@TxD7
z@%k(iQR8FN*{^=2-rge%=WG<a`eAGNxyxZV6SUsc%jP9f2o(q=1Z2QDlov<=JWa|o
zaypZiM0>QnUKA8A3-f;6yVs}X@jKZ&AjslU&NJg{&H4-O>x3k_t)U>FxP`m94F|Z%
zRR2A4kc!MfW<v<y&Avo2!^U`2uf2X{x*!bqoW7@I)}na8_X~ISD2g%M)w<MdNnHGB
zDB4Bk+10KX)}qeFCFU&7fkE^zR8GcrV$^jcaC#z_c(ZD0ytMoP^Ie@@bN7gKmDOz9
zPwt$?11$R!S44~iwb$(=wD<dpM(xC!SUuI<qQUA8C-cNc6ji<^E+@JCIwdW^(=uNI
zPKBTB)><Wvt^!*_1pQb6KzRk1GKyr!`6;JU%J*5*-`DtZM}$Ox?JCcR_C5^Fd1xdm
zwYsr}iPb>*#MFR_0U?DRlcJE@CcEWMN3-S5aMPaeiID2rS`B`u2zEAx#}AkfuxfQI
zerv*>cFMu%8Dbh3M5*L*3O9w*<+zu_4+vjO3Kdk%DE&=fB9=w}C|4g~P~IziElWn0
zT&R{G-{V*|(8F^zIK^RIxuru*<d1&x#pF+SBq^m`An~&aLm7Wv&Y8BsOZpo>xm2ff
z0H7C%q<?Ipr#yx>=wBd7CW#D}DB?P`EB&|_7*m#k8S$sNU({HTnSg!B9LqU8nqHuR
zF%L@`ul7u9f)<cu#E+gOsbw3@ZvTOAnt8qxG`*d#$~^e?NK$W*v-uL1!f|tdyYJu8
zv7R&V!~Q|c<1cbo82K%#%#b+-<bQ_`z^D|=e6d&dXyv6JN$z;XmUdy-bE|^)Wi0Y@
zW2}ZWv9uCJ3wN;QoVouHnbAubh%<*IF&8!G%P4B4J#AUy&e}wmMnnwVO10wxWTC}x
zwW7KCwmk^foOT>elPE%_0^R#=#WJq`7R)g>pB(l$P|NAeV6aPS8KXmAU)Kbm-sj!e
z-VfxGMp|(UcJ^egk_iqHm3vUA=<i9T#|k?Cw1NFRH2NZ^^jI<smY>J5Fp*PJyBhK#
zm{VPAo6sPM(zQJhyC`O^Lft$ZdvkTA0;5k|a177nq0)o8Q+c_Mf93MV#{=M7SsuMr
zj!jDiyV29m&s}#KQg5)ywqp$EsduN-R8}UqZn|6qfWPcKzM-zs-a1^->T~Amgk?(3
zgcu?@Qcf*w+1_bhg~A!uYDRw3Jq=s%DR3bIGo=M$pOyP+)6MgYfTO=pv-7+X`6>RL
z8^ugM+gijG^Z<~7W|QYE>0qFZUn=nt;e7mr+G7uIXy4OfvOZ*tItdA6oG2Jm|5O2I
zd)<|b>F{$l0f(bKCkLfUX6s#KqQ_Twd8UAk%&hn7P(5|k*_Ef<l|v;IWgojRb4xkz
z<<UU+i)OfF(zd1fVZMR}vr{SMx2cOhvh*m#Y7C)QOHXKkALeHwZ<gxHke6af%csHd
z5d+Zg8Ydz~H&}TUb`dht(qR{y9)=cNT4Kjnr`rJHXU`<R)3q)Ts(Y(%sYtsuB5+jS
z`xk!I(eJuu1M!JqV$7Fvf&$MT0*C`|ald0fQb))EsDqfDG#wj))9^p9TU}MF81>jC
zee}h76crIMcz<!g3y_A2$Fq!+i{GSiF5FX0GNPv3?jyYX|B!;(t2FZGWFYFdY%bmZ
zBAYt&oQ!oT{l<m<BtYKDn-<FPn(}RGk#o9xPhSauZ}@zJ?K=?dddoxokjyDBp4NI_
zcynWa!7HwbAgZM;P{#zuu?J!mmX*=vnY!@G`jZQV_|MqXc}`-~c)_oNI!s1>q{d63
z|FAN4IPZeRDH_zo!S3?4(m-%PM2*=PPC;cY2etd%TJlNmHyl+*Sf%2`Ccj+vgi<kF
zKK+IngTRvCkXi{V4CwyF4Liz*U7}`5wABHNiAi7&iYL~=5lFlc!!8N?D8{7t2m|dR
zUELzxx{-3G4`oR62DZbh$_q6nhW=wCnUPxc`F{4lY2EUazlO8;(1L2!DzT1P<Gy3*
zUDLi;<1C#(w?SMu&GD@IiVj*=JG?kL)qAlfcQS!P7|-5<f+cq$-EhoYRQQ9m^lWsK
z@mPuM{rnKhah5b065e>+l$23(l%pC$4<DNoh^5qV=_=;<rO~>@{YgJF6%+eRBj){t
z%mP&JEGB8jlim8BK=@~+^|0pOL)E&qB=pa{$chXv@v9vJK>4_dhcj)3$36yoU}D^p
z%QD%Zs_jK33-wOzKkpMQTC6%VYD9Kx8yT~+^;Om1aP={Pj^H-v#qFW%H_iI#u(8}D
zJqIU?(YEPza`rn9mK)@Bx#<cML1_;Y`R7EMbaiLK$A@Rw$KxW`O<`G`dh^#oYZ|dC
zd%VYE&xPP3B=iN(g#n-GY`zrLL7+-6SeXP=-|tx*Aa9jf<782&72cQCit@+DPLid$
z`!_Y|MgQ-e-~j*Yov3w8i?a~{{c29EKMCTG?Or9uKnnUN1|fDgY>B-<;Z1b+a39Ce
zRVA=8c#P86Ku0m-RK`qNx;`Pn<*B0ZpBhl3F>99b-+6^PI56O7EV6*c169p#;WmDn
zx;ZvU%;(nRzI<@^>-Kl|g%gWbiF1}o&nTR83;=k7B_}PZj+;hV$KQ0utG}G}@F5X3
z(cpJ+4<MVx4yxu;CI0T{K>0#0xXKb}GOPo2*PVNAT{<YRMO^8@8bG$vaq?7hrYNfW
zA0#-u(0g2Wfbr|W$Y8F?*QaCq20|LGGli1Qd)-+Rs8ND5&coCi?={f&@Nq&8qZ++2
zE(mI%iHed^(r52$#D3R=sFh$+`BP!3{GbPftxR%6vz)Cb30XZ%bXg@3{Ru=_TV<RI
zZt$n}j`a-aS6UsiJ>V|fHm|O*%d=X8K(@^Q04Z0SNHds>TehY^uk&p&2WCvbNLN|i
z#jU&Ugk*XV&TAkLJ5p5mIQ158T(aAL5sznOvU0I}MFRk2@7yHyRW@j7(6jscGlPsV
zPlqArUhri3uL+-2%J#CU5q}{_Q|c!oOFKJ{07FAck(xNC#TIRBMRaFX5e20l=j%Jy
z2zCqXt*e1pC8wUhi9Ot)1EPY$dOW^SnxP6V<YW5I;CdeMrJaLSk0&9!jJ7!;XAWw`
z*5bcVA6LHb&2biyaxawMEeQ0`tatVBYYfZV)Io1{_BLK^Oxcc-%$K{R-4)8xvkP+1
zU-k|a_85^3?@E_>0p7)JG$pQxnION93Hu=s15lxc<?(<l_-^mudz`ZQ<u!5V0kBH)
z6+7<ktk5a13q0rAJ9*Eq@l;>J*^=s+%<Ykw+4Pd-eW_uw)bH7n36YB-eIZ*$E+qEX
z-^0$p`D;~_9*4~L)0CUqx}2V=lBUD7Ae{o<C%>XvSI2WOzU=Ssp*S?HN}2U;3zaw*
z2o}{)TeTa{(!i1?)t=v%$6O)1_nQqI8RA=VrRa%Y6K>7;_=^Ll38qA8_^1(Q0r!{+
zF4`y={W+)D=Jy6YhS7aXR`|7PV@3Em58GVHewUP~;p!bFq9~M2Hw&w$NMaE%7^*xo
zr3;>BttJ%@se;vFwxcT3>Xe~H0!;NrcL8C?bPPiRW1ojh2k&^#8AmUSjeV3VfKCD-
zY<z2A9hxQ@-4<#=f*?!D09L<q&!2A3SH&@+0a3w{rav8OYRyG)=PpGAm6!4IW?OdP
zPztZy<*Aidd_jAcN3UK8kk-wGDc|cwjj85pippfE{B_-q%Q2c7fl~m4goT-t!{BLn
zH2;&$gNnkoygmGpE&jPC8o!i=@c~g3YZP~J#ydQ}a>AVn`tV-z<Mx!O)-`=J-5M1p
z1tv@f5q8JySu!YkDZE>Ro@7@91Wdpdjo$17tv6*e4u+?)jrXY1iI0uOs|D&9hSc6#
z#a~3>kxL99>LOjBEfXyX40OZ<X?Z2mA+D1U^4XS#tpa~#WeW7{H^)k>=rB)O$K=Dz
z2Vd(?R;K5ub`T8$;JOHm<K3TGnY$RGU$8AYRcO6{-q(mLlFZ>`%bIRHOq)QGu9?8u
z?3s6dq6ox;6^Y*T2VV>-Kk#0qRH{f}b4rjNOrk+#AGl4O_;9V9FL0>F*(&_Pgv~w(
zu)3fl5&j4Nrn@`&S3+m>v(2RbXclu!L@6C59;(OdT*chQN}ZF*z9QUtuV}77AyzU?
zEH_H0H=t%TcA#FDJjAIX-aa0Z4ba2BZCPO8L}}5`V6Ns@1m+(^O}n}fiWjQ$``wj}
zCLAxjeEM8L7X<VgzT#-e4Kn!)v+7e)V9$@9a=vwO8da0XG(10fET#8NrD4Kr5|i0`
zd3BW?iW{x{EE<Q3D$S4TA!)U$O72*QjnmT?TrHxDD3v%E@)r%&q<kZ+9J7x)`*53A
zTa9{~vQq*}a+0m2nB*7t@&G42!3;rpmS*oMYWR>-Ko;kg{r}MZAuX*$T{nndzLcg(
z_6^rD%YqN6x@u}d++BG?jHjokbDy|#QSl(mT?iCo#@dZz(AQ^bi7UK`gThhlrUQ@P
z(gJd?{G8#pjSU0Ev6bbEBSS-fMeKzAfIj}p&6U~Yg-#x2M;VsZrLf!kvpvq-LZPoK
z7ye`}Zs<G{<FFBYTHas>`j-K(^*=Hat95ip>p#lk4tOG&f+KDwL)QE1d7@bd9q+?a
zMq>H{*m!m*7v;CW&ZfkW86~3kpX;iIG>Am^uD#R<CDM;WX=R-jMos0C4mAaR7ijH7
zDu-=!9OZ|2KIxkW+b$jSzLQp^$bG7M>V0>y#C6=*N$w{vdDT1crtSxBBl?opCeaO5
zHlF^&yrFKz!eTFcZ_hz4{^o)2d|<JnaLu{J>^%4J-pTLvF4ZSaU_PZn;d=N&-3@c-
z%PKWB^6}ZFB`8VUC-YdP!mXOt>VdZsD1P8dDpwP<HTk;lVf6EfGx!<quvuNvE+kEV
z>G)nI6xU}Sk*=8NgaaKktDh)e#^`JXR~`UygB}Z5<X7?(l>Gi(N$*^UKgtSjeja@_
zhfZ-xgUx@xnhdBIiE(UziT$yPO|Yo3pxw8tZY9@Y;qH6tIk+CKT?Cfbj!>|4&>s1$
zJs<US>J>iycnTERfk~Ps>c<<rww++trXiEM(TZ9zIDD7$ZO#ESx4}_ZP|4!^(N53#
z@9?Je`K-r6vf6^o1B1NrS1*ybEj%XfTTg>@gvB`6`G;G#7=6TO_g-mzX+Ggn8c>$7
zE*1J2t5VKqOLZQBOUa0gbg>0BY*BKv=*L3MBNyTpAcb0I1Ky-9wFae6ZXUq@{PUil
zP2J^#+YdT?pE-MKX;@|WPxKe@t%@jVt8!B+>aN(ML`-$B=7k7mS!t}sV^12<{6+hY
zFs#jQo_`m>3&~{MFeca}(mduHvA5|Cyg!g1H}T3Zt9$1MUeHqTCH?Bb!F}-`AlyLg
z^9>>kCGJBAP0dW>-x3mQs(JwESf+Hk%h)25s`n>YC@GWBa-IBGpMZ%>`8IgzfS7Qf
zsBO2K)*4U#v;2ksi}D>AgbE)3*vAajF8}ZPiaGb+1>j%@{C{PnjRp930s8R(|0zrs
lHsF6&Tjc}5zYE~+4^UaAJVbunqy}IPxerRxrBX(L{{_72$bSF;

literal 0
HcmV?d00001

diff --git a/doc/assistant/osx-app.png b/doc/assistant/osx-app.png
new file mode 100644
index 0000000000000000000000000000000000000000..386fb832db9262552409a42b494ea432dbc531f1
GIT binary patch
literal 2604
zcmV+{3e)w8P)<h;3K|Lk000e1NJLTq00372003eL0ssI2svX!R00009a7bBm000XU
z000XU0RWnu7ytkO2XskIMF-po7Z3s^4B~DU000TgNkl<Zc-rlpe^4Cd8OOix-tHZD
z=N%kyKsbITcL_<FG$YH58XIG#no_ZqNisu1CrvDRC7Rf#v<`}mv9_m921jCKz*s6q
zOQxaGCL=U9DPwi8Ayi7x5WOIHcL{nR$sM=%Yk%|)aE$SeK!t=K`}}$D?tA-u-uHRl
z@3Xt_5=oLU=Z%sP$P{D>ml-`qTPPHAxm;eaHyjSnXeSwl(dl$1lS!#mMm&H-%Z{N?
z=**cjJkQUb0jKH3ix)=(5j7%QF4t^A0D$Ltm&-M=yx{eEXJ7nBb1Eu@nVt(K<dnQd
z$P{D>G6k7}OhKj~Q;;dh6l4lA1(||OL8c&6__jt*Vqb(1ilQV)ltfJ-UI`MBBmkl$
zisH1Rpw(z!VgC7|_k$DJ4_UMsn1Y911cVc~?S0j0D#H%dk6jmB(~g24fw&m`=YD@5
zK3mF|r)Vk+1ii0>KD>o7-A97cF)wH+b!l>898}rL)TxW%L`7^e(bt%MrlDe{X?9dA
zRJF<Xs0cH46ov)=M%}`tF$*Y)nx+(pMD8@)bnN2EfEb(#1QMiA0_T5|x`}{H)0I+!
z1OiEt5^4PuO#}k+-tY%r-Zy>q!pQi<G5YV`VEKcyekv&Zb@0Rw<8E50$(+Wj>B~o+
zMkc<{aBE-S{N!G1ND9+XP-OC@$fWj2Mq@RO)+H$uvOeDZAMcs*#E~=(Y2g#N;*V|S
zn6w;C_KZ=`CRNhm)Q!14&%8f;=BjaY)l}yb{P*=d8?VqVP^ZtZI^v#$)o-M2xzYaA
ztL|n&iY#^gLZJG>q32u&FY=xUxfTG>8*mkTv|C51p38nvMJZ=qHT9!}+qxE3R1N&&
z``wTHclhk(zKxgwaohQWzc~N0UkHA4j(icmRDGc_`|NKEV{d$6{>~UmH3O=th_+N?
zd1sOB(7=f=cu#Hr;l=9AL?%v>q@JJ)Aj3QdLV>87FTQ7F;si-tp|u#8*dgB2F??1-
z#r$iy`$O}ii?#D-OidZh7>e1Lv=%_J&!A`YZw$0}#K0q;z5t>CC@^sVxwmHzz(WlG
zK4aUEz}=rxzzM;E_*HipZkl10^;K<&)(l`<>V_V_QxpZ7QgCAE3HRS2h0Et{jHR_9
zDSUVQtrm5945hNfWX#C>3*#483)Jb4W^4uE6}cw{k3ke3NL_DICeDVtEE6z6L?{G8
zXd(Qpp&$TW6OteXAxTg&P$=dE1-`xgl65E4Dnh6dg&H7X;ozVoNM0`X`KOrMR?UsM
z;1BQ}?@%yNp!^UOPy!>$sh<Rcb0s3^yxe4mW0>;~b6kv4dEv8u0s;b25Si~R)z6i@
zpwaXW4%XJcJTEmhFE6k9zyXS)D2n2Fe*3m<Y;y87zMSiGC!XWDKfUx)Z%<EBLIM#*
zi2VGF42F=jc`5U=v#<U2TptR3eSLPjea)IR8#Zi^B*}Zpd)Hle6&4ou_4f7j^vo3s
z9LEWQV6j*ziptK;wpy)OSy>i~g%IL!H~?JZy(`y;f>x_lC=^{?UEy#zIXQXl+O_fV
z@tvKW;c!@^(EuQXT+8dZKG`udGjq|RMXjx^fk0r%k|i`vJDtwf*4EhA*qof4xw2BK
z)#@!<w$#?vo;r1^t*wm^B1w|LU??sw&dki5*%SyN<Dbdt>FMR=<y~D}eSLl5aM)-x
zE?>Spc_M4%Bu33-Qs6jlq8Z+3G$tk{j=1FW`Ocj?H-6uOlczE#lLF84LqkKDfhNDd
zAXAVj$P{D>G6k7}OhKj~Q;;dh6l4lA1(||OVag~l3^V(@jpkHT3Ob!`_ECuDR8$Hk
zlZmG3*@S?mX_Ltmv5AcF6iEJ3k(?dpo?Sii{eJ(zz<|f&357zFwOi{NjW9(il}f!{
zpO~1aR;$N2a;%6DMbYVWy4~(sFxp0=F)b}E+V+~L6hu+9+wHUI+f_Q9&TKYE1Q9ha
zIGxV%Bj|1@Vy#EG=}p1w^*Wu-31mmV-#?*1NL~4O^@A%^fZ%9m*~jd`X$r#acKiMQ
z@lqHV7>L$Uu)ob_Wm%TBR=!wSX5DwZ7r+-E9sk?={SbPeDXajRDt^iq*^Wm;;qGX(
zvLjY@<n+jMO|IEi*4T0Sh^>faS*xwFKL`N5&6Q>Qn%kQ9u`J87j~(wF-96Czc6|}c
zvMgKKcv=7;^zJKSA8Y6sX?48)B5SSh7chR;B2(~qJW&|fpDZYCOe$+=I$DzHeXXUv
z(;Wc7U+ipp^PEqSRIqCkU@rbu-Q$G|qb)xHPx#Kg2b!7=mFKtYe*VNr9EAs4Y$aQd
zCT`ikx2(O<cI+b$0Nyv$Qdd!05!_o>ZOv_Z_|I(u;OTByzq6{i?(oqAPoA`G{Y$q8
zimY`HZEf09Qs3c$r>$^jjkP2{CCdA=5nZFBsm6%EbDx}Qf_eY1i_Cgp-2=Ohy>|36
zg+@cOa9JjB*0OwAjtYR_b~r8xqyNG4{0#}|DF#*gs-kot7~~dMa`Ew(|L8^Tj{P;8
zR{&hOdC##A&Tn3(2mHXML;v2HrNF#`)itlWeGod{+yk?9aY~E|=I;TocbqTE(Wl(}
z^S##2?IriWYqn!u<-K{vF$D2=DJYf7Kp+rFUNAsx%;-rG=A6J^-V%K8x%InSzG}@c
zZ}{ChbAMaou2Ne&U<QzT=SWld5^ld`;plO(Uu86yGm{hmz=ym5L&N7j3)pLl@@q!>
z9IX-+Hy4-Y)|9l{&DFK5#(0l9qKJ-6L9f?Groe{*j20Ea&p&MkZvW;1I*eY0=I%YG
z?!Gdnx_6b@vYtFt^MfqMk+Q;9FB_$CeN<Cx%mPsUZq2%{Z=4ZY>z--{0Q<q$JMuQK
zh<3hSuODw-7<s?so2JQFu^R1Le_7dlys>QM`a0l>N>!7P3ACK-bOeRy>ox%J+>pKb
zXba$rxIy$%)Uy>U3U;8~w!gWX3kE&z-fqVb0C(FTx7XSCzIE!YYHLeXNqtAu1umj%
zktwLvYNIhyXlZhuI9$C+cedi;W9;7Q9l1zNjT?1sWEvZD%JWfGTDWpsV`TZDO3mMt
z+gMSw>W(5WyVY#3%C{cjfGh5Pq%ri@x&@%rAyx@Mzie~E)7H9*pR8KBa!vmF{U-;(
zbw6ENv#Ij%%?23q?ya`wR+T(`nv1L;BTDIsYDa<NpwTD*V5p6~qqMBy?IN@0%303^
zp`umMw>bnk4^(=U0zr<0N~8Ke_Cp9kk55o(Cvff<+Hs<Fgr}ZeQ-$38)o5yI$LjL8
z_N+6^;yNN)P06_(=Un~6eqL?NUS>{FOk>X{r>2zevd9!<3NnScYyShK5ea($<)3W;
O0000<MNUMnLSTYCum>6d

literal 0
HcmV?d00001

diff --git a/doc/assistant/preferences.png b/doc/assistant/preferences.png
new file mode 100644
index 0000000000000000000000000000000000000000..74fb814183c30006f71383fd22a3661a3989babd
GIT binary patch
literal 22815
zcmcG$1ymeew=LROAV_ct1b2tv?(W(^Bf(vQ2M>WDL4&(PaCaxTJ2XykcemH%JO4fZ
zIp^Is?zm&T8c+?ps<+o(bI-X}g(xdZp&;TT0ssIM8EJ7<004R$0D!7QfQF=GC2r0_
zKHfS=YdZk|?+#vnp+1j%je{h@JIg3Yz%RqVU}M1~(<cx>lHNN@XgQ17+uEAiIRnHT
zO%0t*O-S4<oh?YDWE7NvU*F*Z03-kzaS?U*g~MfE^^_ZLuE+Y@&pe#Km`qMdOS=7c
zb4YqW9LqJEzRh|XmBtlt@D$JV<d<e8WeKc}_NSFzLDj+3z)zabr?E2rDOscXPSpT*
zs3PF2m$>LimU8|vk5kEXE~9)vz)`koLuN^_*l03-5fm^UDTn(f$hYTY?rfm(ytS>p
zoOx0zq3x%7v^1<Z<fyOvpa_MIj?QXAN=8Oz)GrE2L)H$49C%e||114F!|T0Vsw-7I
zUF)ZD^uX<%9Ug5+lC!|(_O{(p1FMjb0coV{UGZj_ZlmMXzJ?+t<jZ>YZp$unz2O9G
zX&N5JG#}ov=|f7%CfL}YDPDJQ=O7(|WX0|Mn$K^VZX#Jyq?>X`p%dY`Xr8B-Vz220
zpZ-Uc#Bd-rCHtpJ|5TL}2~rsPzomCa1->@nZ~DKt?4R_1Z`uEMi~kR@|EJi0viZNu
z{-5gnZ)*QPv;Uv1`rnP$Kk2bspAj`_00T%e{v@I_Th5RUW;Gd594Aen6GkJ!f=a%!
z8RGIOD|VU;|Adzet(8Hr0S)P2qyC?9V$BOCQ!{Ymmda++I6zL}>2f(xAFqx1s1zzv
zftZ9Q6Y<}H&`#FpWssAOM>|(^7d>@XARmd}u=Ve)xUL&b&G<od$nPi$By+s_Td;Oz
z-IP=UG|pQ!pMe!`jC8eY9xP|@H8BU^#|hb6GFU>ifXz1m(leqk)Stvrkm~iw4Gh=|
z5i)#+0w53J>dNI5nnDeWp2PTMj+~|^p#H=KC?jOyp?%yO7+*3fj`HeQ`diX6cab#3
z&%GtcQ7Ys|$mc4K+S{w@7T*9pxh}v5wFzV1*GnN|wa|#^m!CWC@z_wE<1_spdfbOo
zhXsv$j`g$E!qzt|Nf~syVxnpFIv6WJkn5pv7h&4&Q)-U!--^hXK75DXAiVCBNx%gl
zQ?lr|hUURzZiIEX_iYx^?l9!C)C97;N2;H#5uT>pRIy^hIU2cadLu=6T;cl;P!srT
z95;5BQ}_wtMJG6T_YDmLL(7I}{91`I&=%x;YiukOV$Q@sQ;{gUsMrj}h(<(k07D@)
z*T&gQ49J87xI;M~(@mV5z*HFbk&<v&yeHsmvgxd4Pgdr9kxpxCTYNA1mIeM63Jc1+
zkI~4|l)d0$zHOFmg(cfuyaVQwIr_V6Fo|8bB>52Mj?*QP9p8}@`!GFJ*MvviPR^5f
zb!OojF$OyNa!J&dz-23gNZ(|8N5keZFBm5rc$!&AMQcoBQvEQr_&r(aM(fQ3;5Id<
za_1aF?e|*9_fE`le5jiAYgqGMsG2mv<lA1gN8bd-hImQL!S5-a0!`al+fxFbZ@w#=
zz^=jHD@AnMr8h{X<ebT>d^zeEUsv;nTO<Iao^9y1GvY*;Oz0-qvg1$K2zh1SsgFUf
zO5~dX)C@1(P|nLCPq|(8&8U8ScjP-6KU@TfmxA2cN#&$OHssjZ={h`d02<UM2X}Ul
z!O4n(k4+M}hLNRT$dJP#6x9h!SSU_v!(UFS;N~VRjKDvWzh5JA_#vX>Tf5w>zXf12
z*<Yq*#gOl0^H^IK7llFz8yE8H9*MWP?|ZG2YrDBD5JzlVPBe<w;-kqD&{>&Bmuoi5
zA>GYE)=*^a*-qz4>hG{vzp|F~&1SWc_y5$4<aiEZy194kMc8ReG|qm@#Pw65mpD=6
z&R^C@BG6NTjGm6I4jo8eX9)#>&;yMu-^gF7*0jqfIBpp*%BF-M+!>lo?}g^H1Lb_k
zr)pXehbI>*N2hob`<7<=8T9(hRtaLPHlV`>3r9y)l(K7AQtj0ZEd6ovJxEtHJQGxi
zohz=%GM9j~cUSXDRog}9cFh1;pZzWPvMaQ?X=>6j|A=KR1JT%uEFfeLL!O|PMZ+El
ztm!^}_tz9?BmI_5S7KXc<IZp{eiPi@T$5^pSmv4IxbZXoNw`YX2_6N%)78j%9NSfa
zWE1+4sAHpNV6<=}>$o(I@$nmE?f=fer6EEp>I7I&tQAAE7w_bVS12t)AQkfa)InW@
z+ipd<8$bdOJ*<zavQk`V=TM#^b2oIkW#J$^4GZh=q(gSTR!aSA5|Fj+%6?8dj!nM@
zQ2GSrvp4B!_-{gsBf!0Hv$s`%o73VfEjpSg;#X`wj^+jY9Gg*JX4uYAR&ze>R*oNO
z<lPq_Dqn;@7(bi*GudQRyQnqQaDWA{4;~7D%&2^bQ3S;B)IB*j93Yqlp?}CA<e9Fi
zZnSpWkUm(uqG{-@dS8ss9SAmr9SwJ_SA>Z%beAozvM&SC)qi0{?`<f>{_2Dffy=Fv
zQ*i#H&M6JD_MKEMnZ$XF1Q(9j+w*PoI3Ec^p*>vv9{+}-5r3fK5N^t*KEuj^y8_}v
zdm!ThEa;t~x|>hw+KMTpOog9bMu#*`VM?8ETnSs(odQWhAl7XtIkr@w8t|bWpLbAE
zAtU+pJ{3WZW_<G?%mu}xTC&jH^>t!vbHZqsSXtap2dwT~27M*7jh-+mU1-wK6>)kK
z?r__!vgk*@iGMSE2bEbt(?0#FY<9+Wt1mSqc-O4ysJ&tpUDvA#dycdk^;FgmR>e<K
z`boK5^mCxUwI#b6Sbndv$WJs=tN$`5Sk@Sp1gcu~Pzqh5e+M$wO^Pek?W_<ZF777U
z-*r^~e`C(GO&+zyo3ehk*=YCNWondU1z>kmibL$I#S=NU27`WxI9X*uG6I$lvp-E5
z9Z{}08C@J*T`XCc-Yb471y(?d<B*~M!Xb;cn8pY>mHDno*dVSBAdCJGCyO2O3y1vE
z8>UyhGkbpNFAa-?&LFOi6x}a+$?Z`NN4H{}g<VDkK#xP@5spCQDUyzmjf2@dRrm`&
ztkFYApc%wj+R>6C*A}3=kP;)i{Sy&x>(ENM0h&-ebidU5HAscvzwkusVn^kK`o#Ku
zMS@uK>>0t|43J6{-67<{Nnao^|LVGkz6-Vz#8{l}I%0@DvQjO~25C8J^lM0*J84`*
z2LljzlqE7n#p8ba1wxGfM3FdI@UcN-9l(-E<n7C4O6n>sxg7e)q;E*o4}V<LV_Xei
z=a&{5@l}e@&2G01jMqZrdg%e#55O)YNO?ZnL#6lPo$#v(Ljzg0&9|eEg$4nxUKWBt
z?17<9(Et^s3C|DhvJqw0(-<Po%yO{ncl|wXIC$mb9(QXGj?8V<Xz7u|QWa?0I`)5u
zVoSXUAv*)Li(hC)ey-C?96QA44a$<2-0Lu*kWHA!B5dD5Czi?e`v)SBp`WJs{2iOw
zNw#1*N50jX)mBd~=559gm{Pd$bhb0-6P_sbtCLsWyijQC3Z6|7(Uo)<573#rKt`t|
z^j7mTrXdt8=k8}2CXy%**~T?bO0Vb(98u=-%xrAa(YD}AeBiF9wcaZp)G37^n0H5n
zJT-2)F6Fk5<ARp?zI)Rv=v)3LGd$7H7x35d@$o`@KfR;l%Z1t}HLD6=2CnUxR9;6I
z7BJ=aW%n24=h%HU^V!`vM}XUj$zyQIT+tohjeIwNJx0qx1x>{K+^G!{K{S;5o`eU=
zz%hLqam%T<C|Uj&V=|3t$(NC~yUTcB`y*F5JsbxvNh`E8LMw*CZA|+UW?*$?_c(os
zn}WVUSR@W6rF6)h!Pm>8jjj}g))wx0xhQ=orq2@?=*zqf30vPk1_J=-+eLq<wC>^G
zyc0Y_@QdE({5_8cSZ$o`go;$6V?b}!z=_dm7oxqyJH|W1D`iB(iAi?lN>MN+cijuw
zxkTWWO6E%yEY;uOaH|t59n#9u9ktLXc)po=v@RDoTcSm<lKz^{%nk|~{Y4t%t5@TC
zxP&Zk#!b-l$+u~vP;UPG*7)Y>v~Zw~_yxA(!q;bWJ>!vL3S6)MyzZpb>P1>}_w|vB
z=pp%eC8!;}bpPi@kdnZcb$#92s;i-Oc-IdP9_EXYZK#H9x%CUrB^NO54}JDQ6X#bu
zjK0;TPMv{lgsr1o#N(?sy`%Bp8g59-AU18qv@vHU`4UrYCH8?PT#5>5ArkoR>el)}
z$2KdsnQUWud1Y`RUMe7<yAVwhw%YO+ys&S=i2ke*{(fbGc9888BKF{Rm}c$89&y98
zDH{{D-}{8AJX*D4IPl|vQS~1%weRgCT+Yn=%-QAvu_s5W*AT^Ta72Nay?3p3A1W`C
zcV15EL&hHs0dEnYPsv7?;sI&~uc!T2hjqba>vC?Wmg~VG+~cXF=MxWr@3|Y{jbO!H
zpOCx9pPTEGTamu*lOx~bAfathN{D%OELbd(q+$GA=HS`mZY=SsVVPv+N_%5Z1Xw<z
zw_?d*F&WC9c!f;{2vhvBIIIfyVZ_XG`m=tPC^+@32)Q@3Fyt*jEkZ`@OQ7iUf$jMf
z*NyMG@psR&z&>Q{bni#|cSK&?CjGu!na|-r*7Jr9=I^4i01s|n!*};7fJ@2Wo4J^N
zQ+w=q;ft^U_XYqo%XX9d>4hPTzToZMX%g@m6_*Zug3;d|d6``#1O85eHYA>0i5-P|
zCg^DEk3(D!tlnXG*6-3O6c;C}etsw1V&i%}QDLd43V;ao<NC)yL{q2U;*a=4@F||f
zfWFx3{E_Ua7Y`&DR4fF5kG+#fyg9M^R*;a-;Ac{21H2HooQf@ds16u7QT8y__yf<3
z1Md%$^yMwjwS6TaJj^hytNa84K75ZVOzN*sq#O4D&*V$yO5#tQ!p{VYE<`dy{KtGt
z>dS7NI8}I&#3%J>UZRW4`}-f~w6$jDpjBX`qs*}BV+Y<BtQOhDu#4O@UWkO-6?=dm
z=hWJ;nkcYr-syQT4prMO8{Ztgw5{K8+IJC@`#hz{O%ZyC(YOmEwnEv2O7hradtFY_
zo3Ap=SJ_ra=^o{ey_8b6e_|sc^@^sC3*N=)<oa%RT8a(t{|;8tJcyuKN=&1cgLWs9
z!xg@d&v~*zgYEDuXS%)y!?f0cPILa+&@CY&<rbA;&4}L_hE#F$OullK%_uh%4O?u+
zAu;5Pq`henGd@(wtPny>(XjIywN-F7y#7PPPKE+Ao#*uk>hnbB!ze!MSGF<eo3+U#
zi+g(GG15)<tHzZF!J<eBvn}7t-^7BY2BG*TzbX0rQ1@N2!dwK9`(Q@P=9<$tlPSsm
z=*9CXYhOM9MbW$#^fdbDk$cYOZhoB9sk_ZCDq1y5?TD8Scu<^`=%Yy4IsyCqYNb$f
zv0<$kT?k9@kA5xF<7ns{V9~{nB`IqJPE0Q!3hJ7w4!6I<X*b!*nfMk#ER^c*y0h`X
z7b(!VHN5E^De$HNCq}5q;kwx1VbH+!d2PjiT&n&0wy&#P`^B;3U?8pkCGnuGFJ0(%
z8qVg<YA7LxC;WR5Z-!JcD^6$ZiGAJk)|8%7GSN#fFv4Z|rel7d;0_h9{misXhb$Wu
zAiLg7zO%i}EppJ0uG<n$nknwbd#8SQG1d_l!1Fc`x(>0>oU#KuKtGllp#$EX63eKt
z#3rzc2eTLvx{Sn`OuQ#KPQvdlu)h{gH%*Er%#9+<-LXmjhHCo@&lmXf-vb~`(U-e#
zNN}Kvy_H8`??T4d%NeRpwnR4AWDMF}qKoQNieJ4S5(W{*sVo92_L>kS766p}gv#@L
z(YVv3zkF@dH<z79vF7r&of^<Vxt1N^iOY7f()vIxboUnbl(FB+cSyJDR1ga8u7Mu+
z3s3*ZI@dMk@--q7(wBrSD!DL5EJa)Fs1_&Zy%N7%cgj{pluQ{U+DZD@ktD6SM7<IE
z9}!#WvP4YEbdwy0?gw#|{tmn0{*gZ5^T1fLDsw3Qn)xwL+(=?N02-2%k(*l^tLyqo
z5W`4hk6J(ga>~~cXxu~F^CG#t(C6>i=&d`fCRqnh&d}JIq7?TjF7%!#PvJpK(x`#I
z8_EHwC8s4-ea~e_f~1S8l$4Y$vGrxr;&8t*p?xu;Utx+>hFpAv`upQ58v5XsJ2Xuv
zO|Td}?Nv9X(y7tPpkXE5wefn<e39{*=p|8)67s~Ak7Ni0GpUd!C{Z{QZWcx5_{+k@
zh1#ROa#K3Bki0hmbl8q}VWM-CCa-sftbjrs!v9{4+f5Of05RM((y1uxd6}nAi5~p<
z!*_A>qv%mr<5Chy^J<$MeOYmg_A!c0Pv{lqIoOhtjcn}m`(se~#Oxq3Iha`-u^UC4
zJzHn{H9L}Sk}*rgRpT|IP1uGLJLadLqZem}iaV+owWJ0Ef}x2fMuT?9FVJVaU?Dsj
zU0!Aq%@>|RG)S$Abg>;Zq92!}eH7WXL?UGKL<8KkgI5;us>ZLdzRKneLOE)nIYz;3
z7LncY1dEd)Mep|UL!cGntlA~a#l%zHL~U#W=IYntKYf9JVbZ-RE7~$kT#l*)1VnCb
zeImusMQ9>}<6ZNnN6_|v7yP{hqnf{2)w+aH-%H^Nmb8&{cdoJSK*3RrMlXRr+aEFb
zs6M<6B{nCtl{i<mlt(wjjd^ALpp~x7t@eQHqWHw*IwonvK%u1$8}*2{<eK3HxqOPO
zk^J)mquvQ_uhwIf69uF%5@251m1>SGeK!nxIXC~5mAur>rN_&ZSOMv>-CgruX0<>q
z4Tr*2k2fCnN0>7(A#o*nz_W$2oA%D_(W@ph0>?^HU@d9g7q~AxMY<Y?`9ll#^Af($
z$igRC5pg)$20^a1rE&siUrT_2#dx0AF@-FsdkJQFVorpMb2Xl8yn0kyg$+b8V^M*-
z9?KRgP;?~JQgJz=`VsrSkznSyxrlb|^o$=ZA81dK*_h!gedkiY@Tls)J9jj@DC4<s
zG}|a}y*ifd-yUe*9vtdq_RH%w9i`HwkznhNVCKUikXYfEGfK#9u`Zi`*%q#>3vgxT
zyC`dn<Ev&zYt+ODmHv{D7NWtZ>&Tvw#^ws7*8I6dZ?M8)t{=hN2y@&rG}>aF9;+=|
z!uVP|b)p05q$I9D?X*Utoq2Mq^>G6K^De~;biXoZ=}w_uDCPFfn~R;a*RH@mcYNeA
zG*^reYU)s@BiV(ekXDpt8yIrH`H7jR;C)3bKWKT(CN)LP?*mKdM`57p2rVK#nn%Ve
zD6QC0uq4Zl{nL8Sy^vAZ5o*$zKXOxtmvS*+b2y64l7zm5g|jK_n`|mmo}n3Q(tAv(
zPrOrk(fKh!Z?;xs1^d?7oO(BAv{6|$enAN*hv>KM9p)SHo+&Dg(>meOneKmNG`4&r
zLQPR`V_tRiXd7XVJb{9!oBa|l?k|*aPDJ!;zl3O|9P!O|0J$fKH-isO1ci3o#*T;I
zSu&PND!DlyX5nM)+>#l3C_RAxW#(EbG8_tFH0&Mw&6o&iRT+_l>y8|<EKz2VS9WDC
zICz!U9yLz+;Uy*=+gRAwxfIp!fBgi~aM~CLL-OB02%}cKC%L<siNgWbNzo^iGA^|G
zUCb9A%P3Vy)4LZlzNzg@E@V6V$_^Z;!AN~iXmOAhBYQn#aqmIRI~LIsbe-0Y4|A$E
zwD)q*C=>>)Vuyj+k#_2fRchAz2N1)o@y+paubs&SQf9kF_T<i<B$Spm7MUg#9@gmX
zdmS5sCpdt$?3{S;Z@df#+RMwZFcgvDRjH_-m!edcW(8Ssd+V(fi3QuRI|$4pa}`T;
z$1t0*%DrgMYKWZF$VUj(d`bngrn8nuG!GP0M${0L^gPqFtRmb7u*df?B(c)oXQ*qD
zc@*QAo8>l*uyD>U@(SYiX0?*fZctiv#^~2sx>bYKIgJw1-4%%$F^B`F5~hj4ngCe;
z-4)LUfjVeCLKIuZAM_P2ZZW3241VB=vad0M($5Q<A+na)mTpdBX{;RPmxAJ5!kX%a
zUd~nT|NJo?V;_zc>{rY`oRLXzv^;+4e+m)%F|f2aYsLrg+~_ACdmm4n`RCU+ww$Mt
zC#P{v_SiBDI>3Oy66+sU9Z-B*6^OI_@Z&q~NEBwlu4x9rE@`%$R$J;Ff6;Fe1%(w%
zi(ghuNp;@8)WA^Q2d$u1POrJ}u9V~G?thFNDum`|Dv(pV_NiqV7dTbg(wtHrGx_qP
z)RW~N--GuWB(Zxybe#waqxSgz$jd-ggf*70e(R&+U_I2T7=)OZ>?ogOVKtZq-J%!-
zD)wy;E=0RG3-84g@ZWOxJju2CtW;oQJJHPvvKXBN@=UV<JzMgAmyIXg3Y&oTAUWeL
zhI<Qmvn>{M$%wJt)WWc!5-OCK6aw|?DywiHRnbbiiY*mNw&3|lTSr{}VgGFIx)v;&
zWR-%rUh|0)<;nzqSslTfC}&+f@)OU>qyTt_EzcPg_r;NJ;YNzU!?*H{)`uz=2*`j;
zgIw9fO08@}7%3a$CP?0qt;4)F2a&C*D8?N*T<N=KiHpsiK{+8$%P^R)-4L16l2`A^
zl05HjQuXPx8Dy{14g7ufuJ{K>m1%(}9{O;8R(dz?_>&%|r?!=^2?#0^2d=)(YjzK?
zmI~>Wex5A=%Yk!4tw${apspvx>L5+s!icUWajGg7(-KBoCGc!wz)ZUROO$0ISU%sz
zD1VXhY(f5IY`r^+78$a|mbR%iXA|C1S;Tqy1^?89tq^G6(!2=LUObon6B*cFF4kze
zlzfUXwPYAc<?4nyrs0NDcT<ZZ3wBP2nEpZedFrt5qOgQp-=QA@2>m*>SUFgsJ`J*3
z(v$-}Wt?*Y_vpp7Mw&t_?PXCmcAjQs^#X$hsFKp0tIVh9*#%WC>ldNqdGqT|iqf3r
zp(+-SdZp-cB=D_}vB^rX@$I>5--3^4u4-#`zhV1NS)F=xX}f6D#hqRFSjUx#h9?(I
zKY4gS^*?&9<*2Q2R;xovRcqtBq()MWV%wGD*_R+7*AwJ62^NdmqL_IHA_NYU>m3&P
z2F9p0%|}IXoBUSQ2B%ZI(pvW7V6w$67|#NOEefZ3M#pG%nFEt#4juBr(kF|uJ3@=t
zi6i2s4IivC?&ROAmY9Bwdzn}3wx*XON<MeM(rmUt-%_D}Q87;r%`BeVW;&_CX9sU7
z8T2L*88TplQ1`pPx5eA=j&Xet))cSe)5S|zq84z%AZa)#`8lB_IKKpf<IYdzu*Ct8
zW@=#pu!;kfb+Fe1s{4;^JObk+y`6le(l(vG_)De#;%-@dGr+Ze>8xXfD%L|5wN8y|
z+Fam5cyN+_3R|l>s~2ZWsh_J(US?q?_P_RPRTkM>{g?_cidTl7joiAXtRnS7YG>}K
zYzjU`Kp-#ApjiCTmwXwy!vdSaQY$DwNvy6=y+KE_kE4=0tD3wo#adtAQ`22+X>AOf
z4@Ma=#xx%KYj0$9R22)f20IE2`c5b1|8Y2Q7F$lm|ITnxz`P+J$ugn88-T3@4dJ9r
zVV6ezB+Ugd9t=0jewRYks~K2X{O2wWAD~PEX9nj|iIoV4I9W81;4dgLE&cU<qom1L
zzNQufH07JV0lV7K3XK3s;4wEi9K-vw=4XHTn`F=!mNtAiZ#cs0W%~YM6Jp>qy!SEo
zsGXsP0g^ZhiAd;?Ny&6W_z`bpE-}#!p<U52U$d`E4k$zeD`D@hNKU3xTZAFrKcsZX
znf4%Qz=xYY<wc{kV@6?Ghi<s2r&eJbe{K<fN2(6eNZHp$cDX;gw;yd{F8HVb6BM2=
zO;h*K--r;4qfqSp*{PrNj$YEa?L}MW#@uktDV!uByB|}xOvbB65>Co`G<kuX`R`Rl
znp-D%CPUU5oEp@cTR&d0=6A2*9|=1w@i@wEqe~w{wkmN{YBz<nF%z&I7DW|l$sd#H
zs^16N*tY#l(>&TG=MIV%$wX_LFm0xLLC}F1FjrERV?4pe>_$dfuD3b1Z^9C|b(Tx(
zEdEsX9<R9vDdN{#eHR!n^Kb?aDeDrXMICy!HJw2_gr|!-EO9JpTxN=7$qkLjm;45g
z_0nzo=FvN7VAkd*jaBv3%5M+OfxN^E#Xvoe{WvORQg@NOQ|jv2NF1|Gvt_imAHbWC
zX<ik{B7v&eKy4!ew6}ipQ{DOY4x-x9a|#B^ZcLV{#7wXVQUZRlBr7Ue=R__8AUjLF
zm|hsqBfY779l1vdnL{e`xSmN?RmV@O0oA!UcZ+JtQ3CX!tV&U?1Ot7$aVVC3m*>ax
zK}0=S&_JIlVlBsEd7;puz&Q8O>`eSo)$|<SN4Hw}ENrK5wJzdLnLb8MHIjCSLs%X&
z>qYz(bNWJB0Zl!T;gAh4Di+Z^-@-gx%#}1wEhF1qXkSvny#vTQhfPiUE<H#7^KFuB
zr;57wr&aOd*4)9#Om?!nBwD#WhwJLf&^v=Y#9^asRchOCwhYUkYEE>hYM(!{4LkHw
z;+HdeTY#@!8=>gts)vbPwq24p9B%*R3y=pC11&Di7%JUIefeG}XVCke$Piyg31_zc
zzGt5^aMYl{9<_<~wmR5(gFA0tupu^<WDQZ2n#@Pd3+GgB95MJr(+M`gb*zz6+E3As
z4Z(XM+!<WGhYjr@BX<HtO+;OXEu<(vteyghMMMCk_eAHrN!E4UejfK8jxj*4lupFw
zVJAx$h`tO?(&wziAYO}8MzB#x+<gDm2?H@OS3EF_k?$@k0y|XB59F`duf^HAQ^iq0
zk)N<oY1}tIpC~6Pa!%2&Uw)YsGDm!J8fs>ochNqH-Eb(Lr?jwOuJ5Y6$AkU7kUuF2
zgN<>*-L^_>D8C+ztei!(CA4ok7e{|YN-yA>Z_4n1z(!6QTaiHd(4G&{&Cif9=@)fI
z;&C44;j(0og4TDj46hy3rE^rQsyFV-s;taOh5z%hZ5gsLY(jyBiiDLBjSe<a>_c3R
zD5nZ(2z&qPx-j8MXR>|`VGzlhP+0zYH~b&F4E#^g{eR~&V3*CW2(`?DgoKp9q}Swi
z_p!i#)@~|aA%)9+bYT5}>D5i);Ak>W4pe6YZum@I;Qz7F<IB5_BwU~UoAxAHC6x(p
zKA{_JK>NLrV7TOO8FGjxLCq+WLEEr<V7$wp0rP8t=RBM9(+I)|!oVB#kX;<d?Z6Bs
zf^xw8&27SH%c+_o?rU|kQ^eMvGBtK6UQ2`=ui8HVK!7xz3Jc*K$)p_f^I-|CiyXpx
z*wpE!#z4hE+8#(*35~nbJo<*yqLBMd*pF=D&BiG6KP=4D#UsvX>Bb+-x8*Ox9B3>;
zFen!__v0AxJV;09`49m}NZU=n*Z0c)13n?{5~jX^K8xMERr#|VeEa#*E@%@X#Zd^$
zax2m>HIj@_aBY3tg!OtmwmynnuVhBb^A)Vcl(BJ|#Itd>UxW7P%}=>35&&$PAM8NV
z{ClSi?Lr`cg3Euj=DB=^D`Vw+KjCHDrHn_1>2FOR^>M!RY`@uYsBbHxyt3;qtIIJq
zrtMQ`PGLmp{R)*qac6xXOKSLu8!%u10_y03iGD!$MuKh9Mcoe;4!S300soB$|DkEh
z85cgEN1Z;!EP*80C+(C#pE*<5y3P4RS$AT=2L6-%hcBBvVxkQn7ZzO|nP}LxoRblY
zZA2h00bHO`K3h&DQht{s7o)=W9nvl-q`XXx`gfzX@7}q4sTzjtmR2QB-#;C2jFl4d
zalypsI#BG$(sam>K$vaq?~Up;@Zp_FPPBVdj(uvR^ZdQ%f8ndsP40;K$MjuvhQ39Q
zg!CWq{2m)2M3Ieo&2HSuldGoH3AKseJq}H04MDywMd+P2`1>+8HSM0CvX`vz_dmzh
zU%H|~v-}699iCkl;0G>i&#%mJ(wNdAeB%9ZBJbJ4c2?PcU3AuOBJyxHm__7kYf#Ks
z6LHa!Bo`hW?4Dp6Ze@-9M5qV9c;&~NGTcLkjGdg8wkyvaQOtSpLn2mve;@vFB6fn-
zK0{)%L&YdQ`6jJgXBhlx7Waot++smXALz1&Om?`bS77CvpFRNM7FBn4@tl<dnt|5!
zW=ukqJYqel52Y!cJ|akzdmn65zKvK94C9K|)YQZq)O$le_eM`BT6(iPX3QihW=i69
zt_hQWvex)k-3~ICtFqa)h$77;WHwbs0)$GCwj^Re^X>=1Az-YbCgg3(V?jd_J!IE$
zr0{}qX5J2AEfwJaEHHRsdi1p;_$S!c)QRg7e*D(J!E}CT<lp60DO3l0Juvz)kQ2NT
z^-{kWu=zgpP9{xkn!H8JT{{dd`srWouf+go{?)&yrmLt8Cm3JYKUWv@6)O>Yx<{3y
z(!I$G)*Fo@Di!S#5pIhYCQx6)YN^*XO==P~^5Gqq#!Z^(t1lB5{!JA_PF?S~(5_-I
zVyIUH6Ko$LwJm*7ABP8G=jS;Kpo+H5ZyT9L89ZCIPc7XO`*s>d3jY-ysMTe|(=TDx
zWfs@h`Up3EDq;JrCxMEuN*8@J^Ixs|&f|Ce2ya@sN59};>31hp{W=~gRQK0tRK^*%
zjO7P5hxjxYRO}omG!=O}2|}Z*#|%Y+jbqyqGJ58E40u)3E;Uv)Ij-ee>XxN3^bzi(
zWoDn<r;le6OKi90d5RfON=KgjH|Mk$u#mbS=Fu@@<lE1uw8Epoo1&)b6<5_o0bXh=
zh1sjecX1Gf4Ha-}ahbW%hw5~Ojvmbr*M(Ep*x1PDr23(AI<0h+<dO^^?FWMPQ-xxp
ztwZ5tZ9n{6(;z1bRl#9c5DL+sY2>Bl?Rl;K+P-mN+MTcf<t}|3us@&cAszvN+@8FV
z?Oto>EI)OYvb3yjp~3TcLdN4JHKv-r;!4Ve1Jnz}iF0df>sc#9)oK^U%jQK0b;jLv
zf#4Ni`vqSrd-hFYSC{CD>42sOO{Rf7ItDa!D@lyOHMfp#!nH{`6noc41u1Np9_>x}
zNa{%>N&8>BALrs%inT_%?v*%<u~Z!>v7|$EZWS2C-98?hHf}(CUj}6|7ip{vTV7Y#
zW91~fO|<1f6{HPp$Q%<Dub29}@<JRAuq7mJN<9_-rq+zQ`W#n-y-JTD)dSx(jyX03
zAJaT`LjdI6-5sz@_a8%ob?EshXRd!+xcXw2j|};~gb+fj<rI}7?nK(R)ge)?(XOtp
zJh_BdTT+-=yI5m6wLOyJ<mg_UxZC>u^#%h)#R$oqb$&GT39EE*Za8O5X||};D6{yn
z_s%7m3)rUmtt1rYs!rBcZk3z^-cNkT(zeco)GRA6hx7xE{l&lT@`K%&ALPDNOXe>9
zX7J4O(z84J;qt?P1k$*A=^6~~x#{NeM#~$Br`O2WGpem62+3z^a25KoJoz8f0)U9K
z+Mdm43m&L0x+m#<d>`!D)xK*4-v~W``~RbaG5zZVM@GyxoI!!%D&XMUmKn+subvvD
z2sg3}CzA|DysC5-l&gRe>T8!VxYXZ2I>RudNE%5R0kp}SC;-(-#;+E2xil7Uep<6S
z@hkla573rY{KUE56T_xyo6jdOiR?dmiJS9t?DOq#>X|zSz$t?#D@IN%0AjMh>dopY
zo9U;w=*|r97)yUnqnjpU=J`*&W9GciyTt!P{<9V0$;L>!EB~dF@Z{wWWej}^cV3~`
z_s5>W{Ozp*IZoD6^<ItWI-l$tJbxJ;<LU(7vYIMOpt$8$ZY^2!d0bPn53QO<V%>Ct
z!5eMegxoCJFf!L4toock;>f2eZHUQYsbr7$%dem(Jcewohi<#JAik5SBsvDmt53&u
z<sZ0BXr6-s-y}~%76vA$Uv|jN015_PUMcQpo~1%5cs^O;&a2g>&>d@QpYrbLSD%fJ
z%!%1ZfdN<+_oBZ~UIu`ih>ewfNl6nc_FgxE=t_I=OsPJ5UJ42dHASA#$0xowtAe1b
zF9SR7b!X+iUgurDU?tlJVu{8ZFW8POX8y8=wMD%V%(CbLq35&kF7LdMG-U3`r(bsi
z>xPjJchR=Qmv#)C-AYdy8y!8X9^aVX5EXjldIFEgIXEU1B^M<+c+N-c(;g=RR~7m7
zbo4{R@wcotYQOlLUAMp7w^*}h(!Y3rUP;rJ`4bF)g}zu_(R%>*(M312a#CkJ4EEB$
z<m<95tXt$b386e5?wPBaU7cKeJw^Atm2b!Cd~KG`L!dcxtWE0kvB5j9YkCej=7yJj
zu=|VB%Z6nRZ>`P!Jm!z!o8U7%rY$2zQ1xMIfjm%MHCvY!tU=oB<F%t>>-+TBUtRu1
z|MmgH_R|K82Vi1P;jqG?Cr+R9Dbxf%(1!l)SXYj~>f;KM&~w5hS>!FcSbkZ)!63w?
zwfw4p`O3ZABtaw|$gdxAPLterd)tT9y6pQ@jT>Y@gT8G4@+a@adoioUagvYorSqlm
z6fJs7d_e!HR+mKQhdeREmL5)1R_e}^*>6>^PfW}%iVr!jP~l%p7wE)<KT-#4Df!55
z2g~pMPHwY%vySe4pd{#~qHoEFe}Zjyt_Sl!NFyS^e`A<j4Jg8(B3InA`;6^QjtLd_
zOo|!V&G(8w>?aiqtSlKS@tYo7!+#>;O?GvH1Kc;;T)$Fd|Ik+kbqnsc*hddJ@cTyL
zHk2Xc(3zS@OfKNCp|_uUx122pr>zXZ{!?$o<}Wtd6*6Y_0$vBD?$|K0a(RBvI0Y<-
zt%$E<^zyZ*YBsNG&sd2TBc-F}N3G2WSUzF6D2kr4na*TRX(M{T|9T@%OyGH;O%p_O
zW(Jzfi=|KTk@$EeRTr1H+wSRJ)>K{5T5hYXx@&cxCx4iAs0!47qpg4DPC1y9h}gN!
z8lUkBrBa%yZ3We2ovH-n_Y%*=#N#n3J+I~*zXn5?ZChqoENcE_2+7hdbom`$ED*su
zus7u~%z`DUm%0~9UY<8hQteOSE60>qCfZG;HYu0-rn*fO7Vr>T-zaN9+GRDXAn&>H
z{`ytG*P(NXxF{svE<dogoPei?EtpxmqPU^BzgSN4DX?@NTr`WPTeIMl%Za!c(j+J^
zbv_gB*Ol=SujFCXlvj`kBs$9D57I}ubh_stR?~Sh_KrQ2YBV8oSQR1DCSg9btIt-b
zb9x`rN@Pzm&sK4m^X$iV%jZo30}t<$=$G_aSG3Ua?6{;|yl3UrqAic|ZWQW-5KG0G
zgYt|HMAGKR=d#CVF6ENu#RBun9;q7-T|(4|;QSVPs2&|hO!p0C6}N(d8K`B~Sq-sq
zgUjH3`jhM`plMm?fBi7Nv4N@XXVwb+Bo2@nGgP6<Y4dErjLJ{7lXLO>Q+R5GtX`r>
zhx@XsEc(6s)S_4ikcl3632#+;pyhiLK>aIDlPJn%8WjnRqJx+Tq*t3nC-Xk@-`TGC
zLnJe{;;K0^!I`{dQy(3+R-0?%gjOv?j&h6XkYdp~_4}fzqo4nsx$>3xEpw7$;~NWl
z3o~Km+y!aJZS~-G6HV;M$HgkAI4#bHxR{@6ccf%PA*$~3T0L-(os#q7RQ!A0n1ai=
zN+5;ZPH^3Hg$-?*<YkDd;7+g-1MN&MKg+h9NCt^jZbz776a}2w*Su3{#8E_}N-TNV
zFe^I&H4{SieReXhDbFI{$F_gLLiXkbt2jFCChaPXWhzVmW2c>O_{*9u*KpM-8rqeG
z@9s4pzZ{nIG5J<%3hdA`Qr6R%G^zhLp9a^L<RJ2?j4ho3sd0D}n1Qz<?M-0NZ`Co)
zS*O~3B03>)6CM@B$hXB!!ZpvY^pbKMM=eZiL}oQi=UHa)kXcGeN#RI-W~Y|n0TD}V
zL7T6NmXSlaD+%}U2Odgd3fpq$2xl_LKgZK{<zWTQl1il9$N0x|9xNPY=W&NMR#L>B
zJYmStfv4eSJWW3xV^|i<I^08YW|pl$hP4Y8p^lWFp_R>Ogup_OGj5fIw?sAFOYVO%
zPqchfh?sGPhlLU!bs6%Kfvi@6s(X;}lk3B8{<cBLYq?bP{#rQ2lI~+^E5k$1lI+Ac
z?Blnf@tH*(q0E+PY^K?wg!`&FO1s8J9m#8f;hMzi44S~c0Bl_npEx8j9FH-UgK3Fb
z%!ei<)Wh1713H?j%Oscmo|ur6+}OMiiD8S>Pb^8Q#Ii*U@e$EKVIHVbDQo*zA#NC@
zd1cm<?w`tAtryg-3x5>wg%+V6rdZS_sB7b^?%T{8sQJ!&W`15MEoNLaEi701f=oB$
ztZZF);GjV?Z(UBzAgbr-I@3Fdk6J&&#mfd%jTcP9mYmwNEVVpKdtg9h;wv^q%o|3T
zokbt{dLObknS43g{lE;;bUl145z7?sI09Az4i-hVzV?UD(|_fkWS>G3RPByT1rYBv
z|IoK*U6~kq7aNq=sX-)@ksi-qEmUj_=_O^ilVAVPeB@GzhiJF1sOZ{?v4_T8q0DIQ
zgIi61AnTa|3%TJt8rV9jrA`;vgu2?^NMrcU&o{e;R8n9kfsgh2%NP{G)E(~w^yNzt
zI~djyGO^KKECwS8`FeYMbukcsK2%(K$oc<ej)-XMOf}l<2S)Ay<*~f%fmR!)lpTyc
zD|Sld6sF>p2~K|W2x-B$@3;JiMvD%E|MZF6uqyemc9R)eZH@=KUyG~C<D9hHXoD-M
z-)XNytgKV~RNT)*eY&Y4=@V5O6ge6!6MTgaKo9Vt6zQVu;HnCO3}&LKQ;2}NR!mY;
z@`#I!ygHslK2<C*LSC^aDA<Nd_Ikhk5A;BpfKH)&J1b;wXa@t|HomEnP~$v{SGC|+
z*+R(oE<BuYtE9|A6P3_uRAB)r*AJ+tV_f<%p>2*Rv61e0GYCQ7`<0;iO`9bxe0HzV
z4-_p<oFQ3@CXu1Rn7hzf;%)fPyC9^>0cMrM10%#0dil-&&p{ji%08Q*2Y%q~z}wsS
zNeZ{RyeX$%HUEgKy-zLahn_Chs_9W0VN640d*E4jOS{uREeZQM>!VkXh$fA6vE?W7
zt8j&8CC(!vJaD~I^81kd8>0RGs_&PnXR#2+$l1J@pzE>*V153ra8>GnhP+Swf94Zc
zkPLA@7#~3o5r4kRc=_Vx^=NLX?{(Ib@$$G6Elr^Y&d*mX+ZTjjfiv-pW#^WwV0wsX
z*R>%v4kZmB86nw~_b_DS`3l)USdDI0O#w(m97P-%O#wzXE*SRv6s`UlAzP@tId8WG
ztL4j8L;EjTN-e?N)6WdGNB|LYE2lkMi4$Jfv?#M!Ok<d6fs~n4YB#~DfZW))Ax=WR
zE!iWsS0YI}uR9EvtklLUE%)aLt*0f1NAdV?d26%A<PZd5I}oTh0S;KMzXdzNi%(3<
zOiO#$O)Yq~&Q5&SFV(ePF|>8xFC|C@y0%wR{O|(pbMuuE#D$n2Su9~JQR%nR?s2{9
z>%GE(KOXnecB%6cnVj)~=(-_;7<?^q(rX0cm(MKdqtx;Abn?7t-Hy=f6nYaZtO}lb
zabNh=cH26ep@7`3OxAP))`S8;?eufCyPQkm`tY4OTYjPCwEB5`KOA=LbFs+G@0n$?
zaq0HrxK?dY2sPeXd>x&f+?||bD*>0<XX4qQAaAR~$(kqBxdgA%e!aZPtT*qzTIc6^
zxwwjd_ia!rP&cpc{{^Ss%ZE&S?N1*u8&%_F<|Ew`h#leN=C+u8)0AxB9RB#!C&Yw!
zV+%ua_hF3l`6^OL|Cafo(Do&V<|aL|pK4H(2E^H>2m$|hdAnp{ib-<S77h*-`T108
z+JPL^HY4J0vEc+<=S)b;CKneM5)u+f13p*91{@q5Py4|3`_mwymWqm~!jg$euiL0)
za1+<A1&05-ZwLSgVuVTziYWTQQCc^inpf`l%e?H`-6=>w$BHiCA1Z73y+GVgqZAH&
zrAvg_4cpe33FN<0=MT$YefnmEbyo$KeX|0GtaStr9yWgkT;{5&#n8d&-&#}gdHJT8
zYWL)b<D50~P4}dCHhNDB-*Hs5@=JTkW8jYZ=z}~SYrRYBqC|}z?L_XuHrxDp7gd-)
z^*N_nP~0ye`Z1A{oZE?m4P6sF)nI9U7Ln8!Is2PW`Ql(i)1lru8KdST$9#ii=PFa|
zS@~-Y%;f>RswEtM1YW<jkBzfcQx1$NTEJ-tSH0qKFkflh{<y{5evx+4a@I?LXpgK-
z47NJtW6eBR<TA2a=E8IM0HaI?@Dm9DO#i#0DF;U|e2>UVYpyOUD;Az58ZeW2#uQJO
zc3zj1hsd2gGWl!6Yo9RZUy>)C*kEC9^0$cF=fN<6FiyS7=^7g&58r)cd^eRDizz`j
z6^%5~Jxl$%(#EbM?2T~juj{Vg)aT4Kq{HNd{&~2(&rLmPQc#3zwIN_ur_d?&MoR5a
zZDpGdB9RtrbFm(c#L|GWY{0j?BAh&1Wk5u56{0oOLvqNm$(K}r&}xZOc5`EMR;gie
zXGv7)jdI^}de#g_v^Ti62IF1Os`t%uckJ=;@ef>P=-UmU=Z)r*Hogy|x5|tFjh<h0
zv#`U-==E*2mcYpMPeyP41s4^-aLOe(RePXHJZnlOSm%EsM>#?yWd=lmEJwCz?Zil&
zR0bQ(6-((J!vi@0WxK0x+W};5DEk>)#~_t%f$va+x;WIcPWR(&(^C>g+z$q!9Y=Ce
z9D&$&b}K01N}2%7d@|m<9xKw^#6%{wx=WXztmZg5F^tWJ$piUjuQ*YTpf=+oVQ%4Q
zLylB#9BLxUnW2%I|M^J-UR;0#P#yJ%7V2ko$49A(CQ2GmI`N`FM?WH*{0$Otr#E~O
zpo}<x5<E~^(z`X3kl}p|?j!QFady6(0UE%a4k-DYPe>8#9dD1aX4Sk=F8+#d`^kJE
zM%C#ciR>U#r2u_BWks!(2-DzyxwKA={)0*V1@jgax3h8%=6+v3!=_Q&2Ied72nUJS
z1H`xL=s4_*n@7p_g8ICJQi>i%kH=#13cOqy$p_m?uu`$RjcB=%uo&{OrN3&6=rO>>
zE6699)?sfASJ`M<e-Hk+P9Rp_ww60(U8}CZ-FkNO9YaX&y}+?8VFuF1_zL=}jqo|o
z_Ztq*BSD^)a+PF4rNU9SvRZ5VzN}Vi&l|#b+@5NKZ&Ld_Za9b+JkRG>^8Iq?b#fsN
zEY<b35JIRswKxLUcGG&&dO0b#dN=Ckb3c^<eG6GM9%ssZT)_U}%cSNfkmwpxhfzao
zCK}crgR<XTh#kPHsUkve*d3OS2w0L3UT?mD(rT-!CpI=EV1g5-SMEdUu_nmsR{4L)
zpR}Hsq&n3i0fwwm{n<gXlMif8Wxg1_g2g`2-;<nVnr%%Md1vPdKb(xqY-o;Dz%N)R
zg1Z}#&8ssm!qn2TN`|pN|09SlXsF{LP1P>ar;(>2MDPXiLH@+Xn4%w!QYh=w-Wjes
zbhMVdF3(t95bciIx?XqUQO=$#B#p;6ORMZF?;calx4(;BzOTPrYA-^GOX937n}*0l
zH9CxbT&rGAhK5<0nQLc##H$dRt_seL1H`wq4MD8$4pVlMOY3TST=nq&f=wv)|E_UL
z?O5%hq`50L#&+L$8}-%3H@yRHeQmwI?<AY9Em#q>tf-5ycsH#ipD>%7pkPm*LPYh!
ze1e$P-DKRrx=;<qC4PY%#z(r-bfM_DgqViE!mXwfiRvI)OB3Af4!=2SCbWZyNe0q1
zTRE@i`|%2tckyTott^6-B<6C@I`lo~Y6@pn3!)PBvux@%1<f<qTGf+8wYNCPL2T`{
zfi%&whQBwKmOfDL<`W!SA;w!A$T#^kBM~X3UD3P-W`>1_L!9s;H{cECD>rWU*m|;A
z2%_+B4!!JH%^6;f^EV{zElnxex0tXF0&-<_F`T;?D14QFx*l2mnB#ZYm%ki&?#>79
zAA+m5wzdH29{Ys}`W|mPGG6X7gf7R$&X9#(?#6^}8plk-RsiL&07~fTA0ZfP@o0pB
z|AMz~J)k1iCKV#OQ)y{Kz!;G^j5yGssTEkHrpPbnKS&`IA9;{ucQy3_CPcr)ZZ^!E
z|9$(J^C=ntM7s~Lx!?58-?N2EjAnV|o$*yXjEr*jAQQ-G>#YoPO8N){Vh6k`r5cHF
zj~F%37{)u7;$YXQYRYS#ht$1147JH2y7DAbAoN69PDO<>XPT$B-RGan>s<|-f_q6Z
zfKEO0xcFu9>=x9|aRhWT2Nkp|ZOxqbicvbHieW&&@YonV)*K+YMjt`TLo}557u40C
z0tpkR{9Fn%IsSNC)}pIaL%T_R5}ua*NnUFWS@30D)t=!acgiz@Rwz)l%G3&J!u+Ww
zB9EGCHr|Kxfd`l#by>9s&Nh~31|egaN7I-9In}f>Qy~LuB<leg+3G`C63D7pU*os<
zetfq?Dn0nwer|o%Z?TYxgQ3k2D|f9#mnYBm+nl}FR+XcpBa?1Jh3Qbd`}EJ<u0W(g
z(jmsYr_7aV17--!Hg)61{5*ojYSI`ZAGR2tKX^;e2+XrITC!u}AZhR4*`3@SB&0qH
zsh3_O2+aT3bTy`2+sETY=e@WFQ96nQBzRj@ia#I8fRzgiFXImRvk9@YT*Bo0I3=u9
zt;Po_&GK4WmiC<WTijLhRP$1sT#u4T5Hg-G3+xl*$R!QhE?^3~ImBMYr7)#VN0U8J
zfxM)c+eW~9ntxYEg1r-a+#5>UK4+d#$3Y&k|CB*24YpL5we9%|kBHJRYX=DE;O~7@
z!4>WK&kk-`+y&Ls@iJRiS2^Be8u_+Hgu4#|R-*9`%lDv`aj#DLM$8@n!2A08UVwZM
zEkp~+?tfSl7pI6^w70h$?a_;&rJYa+1jxcQ;9O7~v&Sx{;?>8$t{(A_(A?4=@{9KW
zNZqz*Ri~b>QTw}`9e+dL|6Q;CPeJ%!LH++0YyMX#{*Orc|0#R_&scLvM?s4D_v~MV
zjQ{%1fd88PZtK>9>0PYbH|x?bM;s8X0VTSRHj{t~Bjj<Y{qgk;0FF*hYKnos*A-GY
zpE`*jAzsq5%(u8>@NGBLcl|>KVZbimGp{vIgQd&e@x_;7O<lPJBJcglm;0uEIkCSH
zXal#mx8G0&-Cv$=hSHxP7KDS9RYgT5+Gqc0Bzx)t^mNiDbl<KxX1}`fC<uUeTaAg5
z>#AirKZk-!?5lN)u73-t@N;7}{+&NB&|{qtT@Mx9BOei#7CsvfZ=)sK?24@=yrSoR
zgUE?>>JJIXlJ+tVwo8SmG1=MKfyjc7>!{2O4E;Fl_Vn(PgrP4dY~_J%x;lWhdA0;2
znUesU7l$*Ypl!$pdIIyqs>aN_J3ni{<1>Avpv%BXJI0adQPkK=nQUVQaP{qiqTb_F
zR-<u&kJDADn^DNimFoptJD3m4{b)wc_dYfQ81p(_tqC%rWYNJkg=1J-?Y9w#3FXio
zka=~hIchE#6%^n}am4&|vo~_%{pBV|arFgiQSNIt3Xj^!;%zb)>{<^JDg3#93mWuk
zG8g+*Tet*4y!Q2KIzsBK&)Sf|{kZm#_o|O2Q?mPR#>#!9ZOTZq(B+XF!Ha>u^lK!J
zHMVo^Ge`nOo2o23y;j{FG@S!^yF+_1<TQlSf;3;Ye3`vd5775Is?V7J+4QiPWMFXM
zOJg*O;`3r0-DV&M7|wIc@Mc6<>oG96^V(}=e!i#kt1fRfW@_~W`$Rl$FWd+<4zxh6
z`dV!C+m}gTjy>KyP6Tl#b9J7}9D9>Ogt96#h?+#W!1wdk9-G4?sUg&3R(1WV)O-um
z<y%ty@>33w8RmAPIE&d<ZduCl?QO5piih*=k=V;A=;ZMYz<`d{y_cYuW3Q*4Y}MoT
z7<W~tgJbW#{jD73(1}PRtj%H+%%{ct)E>9=)5RX~rw4VfH4?I>vlZ(_`+~1^Sveo6
zDX3uyDYyU#d43g%f-siv{1LL)^<e<gOqqbL+1zeCVhUzh#>{AIi#G@&<FvTZwr~)*
z_-*)e$*3x<9@-V{h5`%H0BRNjjpBilBe+J~DdWps$l!Po!Nvvg@QWnN&e0G17hj;`
z!;kZ+ZzuQ55^itrI=VW)yzQt%>1ZV|@VaXc<+6Y5euK5ze%9mr#JuD=SBIh<cn)N4
z_ngZ|fqbN(%@&un(J$AExId)1-F1jS9v4$WyiL1Bt|L3UUu^GEFGbGhW?x;ZVGtlb
zylzS!{t`N!AY;~FD6?8#tUkkL7g$}OIeqGQO)3p6hX{5zZf~8|Uh89<Ae{vFkKAkv
zt4l)gwqjy?RT7gRo|@vL-FdCYYne;#*Gsc})N#|Z7B;PzN~we~gtePaVeD>=&^l=g
z)^^nhJ=jTugH#df_3wLoKPsrldpDFFLnDJYYhU<JgFwe^^hbw%LKG_(#Lq&Hn*!D8
zZa$Yfn`{Q|fQ|&&)f?QG&4+5CNx-e@z~twm?s79Q3H0r45aNgOmb)aSl@0f;(nw#L
zy7ZcxC5|nh3)K2$?`?zCbr^Wa`$cZ_mwf2!qfO~x7fUAGv!yCN*dL^YQPnMoI>omQ
zW~DbSY>W_IyKnzX8QFs<BZbZFLuSm@tSDFWLnZ%DDc2qib=U7lPf{Uo54k2O5+*!U
z?o`TcNC*vv+;YFuxD8T>ga(uQ<Q8%t%wRAf$#pcY(-?9e_dA)voT>GmXPwr0&pB(I
z_n+U|zt7rx|MquZ*8Y5c-|yaS=%eK7pPr2R_JCZ+{t64Uc97(N55~Za+;+hZTUF6<
zvl=Fm>D~XkyX8SnsoPY|)LjQ+^ipr*%BmRMLdFv`7WXICk>GN0i|jeRN0D1gJ-Wex
z1jf!v6K8tKKlZO>0G7v4of+7#mMHPEVfKVGO@eeDed=)Gg!K~n2ctkp8@707VA09;
zuyBn;(;d&F|HIEsYKCDd<J5WS^H1)441M$|LBNIWpHUoD$qmiiS&Z42C$Ei-2M#@O
zX9R6rEgl@=$PY#MGu#u7Z?1bKrxwh?=1buCc;w!mYK|ngp)G;Lf)LN`k9EsRmuMSI
zyPSq1{vPL%)-7dWL;Y!=gTpt7fV{eT1sBRGGPgqQv37vtJh4LUAF4lku8iUW@Jl1B
zM79uHZ$qB>Ng-Si9jyYmIvyT&uz1++yrgQSk(;&Fy-&&B3$B>V3k0oI9r7K~I8y{F
zg+1FMKk|8B7E=DX50&oM)-79czk75XfqnuAANDWB1-Ehz>WV849SgTL)DDYaXA<0L
zJ9hlkdUUrD68_BA@a4!m%ey(}h)SRvx<U_6iCz~p0%F}F7dTTKgb*o7NxqY<k=HEH
zU$UFLCL?^l`0%W!&17ATp<A%!Yl(!ViiH6!G;-ZPqGt|*tvRIwC+ZzTkNj=gFlucA
z*M8mn(37}R?ed#^6Et}HpTQ&B25-4ccWQ490{+Y=)>Q8s^^3ja7niAad&5?y9e$D7
zabSs!Iu@HJo_MS}qT$hLk)Quzx=&Z3FUfXwcW2$7Z-2!zfJ>o&t96aI7{X9Z%?=|&
z;Z@(&%g;3`bGUoBTxZ;y!v;1Lot4zQtMNXL5gn>klXs~m{*5yuI@Hiff~ii^U_lat
z)zpgZGU`VBQckd;3&=J#B?-PD_$q}9!E2c(NY$<Owf7-jk}aFz**_2AhtyBgJ=c!%
za!WZ?<HHiu9C`T?H+Yhm)18V*=f0uFC@fF$=yBEZz@?|H*bFl>P}3fIDt$IV&yCiy
z(h)P9L6}4MdqnzUDocx+M#kd(Wk{0QW$VymDR#_kGAFm#ddAdGBtA|RK6fk_7vHh9
z-LrM5hF8hkm`mH3tcNP~C>FSp+7?E7190nECk>Ql34B=Vz>9LUIdY_hkyO@M8#fNI
zgWWA^pGK>$o?hd@W;Yg_{HK7xlGpZxMK;?hNTIMPAlzP2;|jE)U7OSaR%(tJXlVRl
zJr8V{_Abo30_!~JoICf5+g<W%y6{o~Hpw$^bwofi1^xXQb5>N3HR}6OZF#c$+CwF{
zBhb3vd4dQ+jNzUdcS$M}xTO(80?yiXO_o*PpG~M7blBTPyY|_(d$N@^+H7pr?s@73
zI%q8(C<aaEmE$omX^sjXE|1_sf<Jk4OyE-7%9GYk2={#{E#;^S)+JTuS@*|{m;jlv
zsjD7uq>A6afAUckx!066@?u;pXd-x%JukjHSf7t@S7V4^V{FW}vg;D75v<=1nvRpv
z7&9smcZ}9jmXLGMU2xy>lNVXG(kt#s&X0-OO;5MghGT&A${Qx}_S1Q0h^DE4tp)$A
zY){%V6YUQD0$wps9?qw3qbVy}FH{ZRBrpNO<%+PL9(c69A`RF*0oiI%-gx3a+aKeL
zaGa3&>YZ+9VADFFcme>>MhG3R@Ec8bmLPuJc#ker+vU2Vl4S>AbUG6Npq^~c_o<kX
zI27t+T(G6h&A2rS&I|w~0vQPrR>tEu_*a?#3%-T=XC=RKCpz2`g4x+!mKFv8R2?xS
z9mLvgBcngV7~!@QMI>JSRzjwH)IY!Td&!I7{|f(X(XR@Bhchp+76M>EUN$s6et?UU
zbKr;;uFwSG;APmd-SLP>#eCRVgIR5YRUN1G(t<);$s?~j`PJ{j@$<^wQ!kv;5BI~_
z+g>Il$g@57Vp=CR&&RBjA29+g)YXGBdOw2{!b2Vy?hUja#`=0m^i^J2Lsm;Sx(z<o
ziHV6hqz5c5E{cGGA>GGAI6~B{)z$A54(Oo1)41493?N5+>xg~D6m~m1gAkd$h_jb9
z*^>V_qApbko?+oJ2fz#FJ6oZO6y@j={^VPz?byrNCvX$$;cCJ&d$hnIK!}(KD^**D
z_u;F-)-;OXwU$Jt?RjBdHlGw`Kxag#_(f&~)+T=s7RK4sT&9cQTc|`JV`SjW3Omxq
zs@mMIAP5B=7Y`%fX+Dy_Wi*E`43l;(7WBYapRSHky^rwOkJpKEn=W`Uu9QvPOZK|a
zc`V$%<s;WhHL#N>f3C;tzP?PsZBc#A@owv(3;R=X%Ypdxs!e3#;9#lXj(4DR7}z4P
zk!9Mp9H}ZkAAxXQa-q`eS9DMhn=rd&5s=^y#_Vke(HpBJW@UuRlHh4C4`j2?VPDp-
zM*d-3BOev(nBaxm^`1OyomoTC?HB}?J15l84gJ5^np9i&vJ)=0i)J@&o}GVaoHa-Y
zio7y*FPTl826ceLf#!ZGc8kj!1Do-f*X|E2LzdhovTeS+%(=HPoJl{(-KoU(33&&Q
zPF!dg)ip}mvqyo?qdt8ozVAZo5}f;P$HgNZnO!TtSpPa5XcBBi^<Qn#sh8HrYZvV<
z?%~&nJL@gV7u*D<l&@BsM`@siYRibC7EvKcUAQ~kUb()Y5d|5uS+(0V`GSzh8u<3|
zYwinsrdz1T05MQhfwLa@<)#E?uraU%8q}K8zndqgIp23)wq;fQo6}4)xUlV9hFQX4
zCt0YZQ|#5oYI@bH3lgd>-gA8dNh$p`dE;MTi$xXh(E~FU_iLoMn#eQRH?^6FKnW{3
z^t-_f->>hGrNvdRDJmLYLkjcjS+&%fQ6HA_45LYmEQ&WBv0`fy8m5<_!ENPG4jq2@
zO<DR|skbJIo`Y-B`+7zrRd7OuuEk&O>%7=7>%2F#^uop(m9F~N!%WNuxDet>w<%;H
zF~Y}*ii&fw)^ySyD%Z*m^P3m0kQ^#X#VmK(n3ci(I!cv2tOHh(@O2IiJW`q0sZ<t`
z{WBgA95v0Q!kdPQ^F0bp5iwZ_3fymitPXZV&dIBW;G!UU$p8xb!K1s|fha$E3FUQO
zyKj<*)pp(tNUHQT)T8*dGlcF7GWyyaLF=+4ahxM7_=TB(G;8<LS);DLbG;&}U$(be
z;nIoQ7z1l1c!cJ=4d>u}J<ksX`shR%M;ULli5>Vg&ev%%?dv&!YroL-Z(F4uTU63G
zx*RPsTgFaz8k|%!20xuuR=t<-_QpBEtBoGol*gx^G+2@n>a54i{M_A~^hcjdH-~Bu
zyrQwLN(yZ4Hs>NOa<iKrUsnc^>6vNcN67fcGDA)ftEO>_Lz2E6tGww1+Gf9Ds=te)
z$=o`0r55jgJrrxRL(R%bNl>GP?2JW6jbog5<eoU`w>)2(=&ExJn*5BBH9Z)iijkyu
z@2Xxnx&!zw!AkW;-8}$yk3j`|I6~kwyEcE5I}1B`bIs|Gj%@1l$D+^h(57L-KXMah
z(nM>E>U!jsa`SNqJ0)NqQSP^agSpGz=u#TXin|wLHBQ`IDZt^a;0kyiE)w=w4+dGS
zUfsP6-f+ZACFIM<xw$9iUt^yXdacyx|6INVI#kj>KuIH0w;i)wvnrcg$h?`M-ybkK
zqpF;9Cz5X(Iv8{s<bpa1Qs}zoe(dz|W6y5omprl(Z+B+L_Ldoxb;?NCU&w?zA6+t7
zAsvu#_U}Kl$QFvym&b=w=(J+&dR0wMlrGYo)4Y18Emj`{EB_wsET0bT+xL4)8vVk;
zxo-%#2=3=7NBLElnw#@k8ZP*{@65(+agozQy>;sI39NWLGEJey<1^S|Ui_fw3Us`v
z;8|*^_o+bq!>jK^oVT(rYi!k(j+ZNUSwOhWN9RYz=aQB{IA`}~9*!sP23=oVht%HI
zsh#UAp32{hdN-JUm;4&CL3<u4$EiwJYpnCOTt%u-Et2J<a;+OGm6l4*C`H9DQMJ3W
zJC4>zcQwWb`)$zpq(6n&PB^So5~LN&S{^@GFpWgJB(6f%BZS+M<7oq=j!iH(WAp6$
zX3r-Z>bK(95z_mlzGf=5*4b-mw;jj7c(j(ls=jjrykfkTmLDE_CN=VDn9sMDY_D*X
zTa+a?-=pVR>5Cz#Pha>a{Ix9jTh|7mKHVNq7#7rYv?)umxNY3DZW0g9<#)vj(1a#L
zxKs?^I#l%5e?r@h-{bVXFAp}7mEGe~51w5PCYh$nO4`RI`HiHHK%lDX*U0Cj_r^0q
z`EDwILzJ~p?R@I&L$6ND>cHh_9MJB`)B4&d07Wze!3@g=lIaqiXiFsQ8C+As*?w33
z^<G_x#!^RJNp*s#Iv;OwsUdvgrUa4aL8q91pd3V$Wif<F{2h$tg9>;W{prjEwDU(P
zsgHdNjHpyzsZ={)Tl|`*N_+<+LcnkR_bD?t5X^Np@a*U20IgU_--F>%8($pXjoZxw
zbYM3-1~|IDTxddCJ3Z{laUpo+J1eGX9Xq1IQQy(~D0F;jg!$D@p`)nd`lxG`S^}Xt
zQ^ot67ztS<4YTca&$#1CDF2bRK~+s_S#ee#NhVi6!=rvKu@lWs7`SA>qW0w28=9$@
zPWpq{KH|Fnl7&b`s3FQJu0zOT)5t+bCdY4~G6s~uvs&JT8_M2#XyTMH)@$u%wXELo
zbd)#Dcyi0ykN7pl<0;GsCNG!yQX$MB8fw`Ww%{}wF?glKzoR7jlD<_)<%|$sF=)VR
z<Wx1K;JM*y>&SD9&fZjB9F#n;b<+dX8AkHt9papq2E+OIQ2`s*Sl_Cy`aLX^PE#jB
z+gl?^r(>UJCn@WVHe?=Vw7Z(Q%j!X?@Ui~%ebC$lhT-zt!AJ^r$|0nk1Z2}nfPlWz
z)RXk-qT+=$3?4;vYkcv?+-cCoL@yGJUqxl}36FWQO-epNbHy_(r(ogf4IO3v8=rI8
zO3>F`US21cPiYQ?2A7g5aMz*PyHBv_7uZSn!X1bsrSA5OR-Q+{_dfqCc&UU(as{pG
zrt^n;QYB-dDc2>t3|@KuSWLQ+2az%x<jK9G<k6K#U{h2oop9|+yu$whaV8_(mIAAg
zC7~&GA*0D=y7Kqq{Xr@3qja4$Q&-x2u;k+6;^!y4b9gAOYRC$tP|m=D2zVVP)*V6V
zj4&QtAL`i4-xUE<Phm)^LEBDn=8NE<Y+&PGFPeL}LxHxQ*%ssOOkSp!89XRcbRL16
zVPlZRzVOu4)FKSL%~=H06AnV8rt(_JGgc-wFTcf<qm!WgIeWVD5%7<z;N_>v75ohH
zbZDrjr#GHi({8Yw^oIAmz1N+-(HQnrmxH;!z$C4>m-K@zd=eZ^-R~g4)Fw8jI|c}Z
zx-JHDx~;xb(la@Hd*0&*@{n$3)k{<`4h=c#Pmz;O&sMWEvbCLhYaI%<ww^$8C<qHr
zHg5GzOR$Eo9SHK%zwp6|qoKZ92J~YXNYTk_+w=j_LO9d5>d_myk7mI8(tzzttJBB-
zJ$mja-5stLgv57%P69r1Fq!>Eu76Vge?hMQ2hROF{8KahBJO`{hF=W*e}R8j7=P#f
z9sak4$KNvL|Dh`WyM<n8QIMM(Q0ycCu$^{t<*fM6DKmfO@3&G@S4+$Dg&YjvSzVn%
z$<Q})-d`<`Wi|tF6BDDOqXa^0F=GUqgm2y)_P}USQZ9%x)YZqm_^`kJ<-p!bI8^_f
XI?HWBfZb!rAb`%j`*+LlJdXGe+cvkr

literal 0
HcmV?d00001

diff --git a/doc/assistant/quickstart.mdwn b/doc/assistant/quickstart.mdwn
new file mode 100644
index 0000000000..0472ba48b6
--- /dev/null
+++ b/doc/assistant/quickstart.mdwn
@@ -0,0 +1,30 @@
+## first run
+
+To get started with the git-annex assistant, just pick it from
+your system's list of applications.
+
+[[!img assistant/menu.png]]
+[[!img assistant/osx-app.png]]
+
+It'll prompt you to set up a folder:
+
+[[!img assistant/makerepo.png]]
+
+Then any changes you make to its folder will automatically be committed to
+git, and synced to repositories on other computers. You can use the
+interface to add repositories and control the git-annex assistant.
+
+[[!img assistant/running.png]]
+
+## starting on boot
+
+The git-annex assistant will automatically be started when you log in to
+desktop environments like Mac OS X, Gnome, XFCE, and KDE, and the menu item
+shown above can be used to open the webapp. On other systems, you may need
+to start it by hand.
+
+To start the webapp, run `git annex webapp` at the command line.
+
+To start the assistant without opening the webapp, 
+you can run the command "git annex assistant --autostart". This is a
+good thing to configure your system to run automatically when you log in.
diff --git a/doc/assistant/release_notes.mdwn b/doc/assistant/release_notes.mdwn
new file mode 100644
index 0000000000..6c7c432de4
--- /dev/null
+++ b/doc/assistant/release_notes.mdwn
@@ -0,0 +1,422 @@
+## version 6.20170101
+
+XMPP support has been removed from the assistant in this release.
+
+If your repositories used XMPP to keep in sync, that will no longer
+work, and you should enable some other remote to keep them in sync.
+A ssh server is one way, or use the new Tor pairing feature.
+
+## version 5.20140421
+
+This release begins to deprecate XMPP support. In particular, if you use
+the assistant with a ssh remote that has this version of git-annex
+installed, you don't need XMPP any longer to get immediate syncing of
+changes.
+
+## version 5.20140411
+
+This release fixes a bug that could cause the assistant to use a *lot* of
+CPU, when monthly fscking was set up.
+
+Automatic upgrading was broken on OSX for previous versions. This has been
+fixed, but you'll need to manually upgrade to this version to get it going
+again. Workaround: Remove the wget bundled inside the git-annex dmg.
+
+## version 5.20140221
+
+The Windows port of the assistant and webapp is now considered to be beta
+quality. There are important missing features (notably Jabber), documented
+on [[todo/windows_support]], but the webapp is broadly usable on Windows
+now.
+
+## version 5.20131221
+
+There is now a arm [[install/linux_standalone]] build of git-annex,
+including the assistant and webapp,
+which can be installed on a variety of systems including Raspberry Pi,
+Synology NAS, and Google Chromebooks. Details in
+[[this forum thread|forum/new_linux_arm_tarball_build]].
+
+## version 5.20131213
+
+The assistant can now be used on Windows! However, it has known problems,
+described in [[todo/windows_support]], and should be considered an
+alpha-level preview.
+
+## version 5.20131127
+
+Starting with this version, when git-annex is installed from a build on
+this website, it will detect when new versions are available, and allow
+easily upgrading. Automatic upgrades can also be configured if desired,
+or automatic upgrade checking can be disabled in the preferences page.
+
+git-annex builds from distributions, like Debian will not automatically
+upgrade; use the distribution's package manager for that. However, the
+git-annex webapp will also detect when a distribution has upgraded
+git-annex and offer to restart the assistant.
+
+## version 4.20131024
+
+This version fixes several different bugs that could cause the webapp to
+refuse to create a repository. Several other bugs are also fixed, including
+a bug that caused it to not add files on Android.
+
+New in this release is the ability to use the webapp to set up scheduled
+consistency checks of your repositories. Many problems with repositories 
+are now automatically corrected, and it can even repair damaged git
+repositories.
+
+This is a recommended upgrade.
+
+## version 4.20131002
+
+Now you can use the webapp to set up an encrypted git repository on a
+remote ssh server, or on rsync.net, and use it as a live cloud backup. Or,
+use the webapp to make an encrypted git repository on a removable drive,
+and store it offsite as a secure backup.
+
+## version 4.20130920
+
+This release is the first to support fully encrypted git repositories
+stored on removable drives. This can be set up easily using the webapp.
+
+## version 4.20130909
+
+This release fixes a crash that could occur when using XMPP with the
+assitant. It has only been seen on OS X so far. The bug is not believed to
+be explitable, but upgrading is still recommended.
+
+## version 4.20130802
+
+This release fixes several bugs, including a reversion introduced in the last
+version that broke direct mode on Windows, Android, and other crippled
+filesystems. It contains a workaround for a bug in recent git pre-releases
+that broke handling of filenames containing spaces.
+It is a highly recommended upgrade.
+
+The webapp can now detect repositories that did not finish getting properly set
+up, and can recover from one common bug that broke local pairing and remote
+ssh server setups on systems using `ssh-agent`.
+
+## version 4.20130723
+
+This release fixes some bugs. Notably it fixes a bug that could result in data
+loss when adding a tarball of a git-annex repository to your git-annex
+repository.
+
+Rsync.net have committed to support git-annex and offer a special
+discounted rate for git-annex users.
+<http://www.rsync.net/products/git-annex-pricing.html>
+
+## version 4.20130709
+
+This release is mostly bug fixes.
+
+One of the bugs involved setting up rsync remotes on servers other than
+rsync.net. The wrong `.ssh/authorized_keys` line was deployed to the
+remote server. If you set up a rsync remote with a past release, and it does
+not work, you will need to manually edit the `.ssh/authorized_keys` file,
+and remove the `command=` forced command.
+
+## version 4.20130621, 4.20130627
+
+These releases mostly consist of bug fixes.
+
+## version 4.20130601
+
+This is a bugfix release, featuring significant XMPP improvements and
+more robustness thanks to automated fuzz testing. Recommended upgrade.
+
+This version changes its XMPP protocol, so it will fail to sync with older
+git-annex versions over XMPP.
+
+## version 4.20130521
+
+This is a bugfix release. Recommended upgrade.
+
+## version 4.20130516
+
+This version contains numerous bug fixes, and improvements.
+
+This is the first release with a fully usable Android app. No command-line
+typing needed to set up syncing to your Android phone or tablet!
+A few of the more advanced features may not work (or not work reliably)
+on Android. The Android app is still beta quality.
+
+This is also the first release with a Windows port! The Windows port
+is in an alpha quality state, and is missing many features.
+It does not yet include the assistant.
+
+## version 4.20130501
+
+This version contains numerous bug fixes, and improvements.
+
+## version 4.20130417
+
+This version contains numerous bug fixes, and improvements.
+
+One bug that was fixed can affect users of gnome-keyring who
+have set up remote repositories on ssh servers using the webapp.
+The gnome-keyring may load the restricted key that is set up
+for that, and make it be used for regular logins to the server;
+with the result that you'll get an error message about "git-annex-shell"
+when sshing to the server. 
+
+If you experience this problem you can fix it by
+moving `.ssh/key.git-annex*` to `.ssh/git-annex/` (creating
+that directory first), and edit `.ssh/config` to reflect the new
+location of the key. You will also need to restart gnome-keyring.
+
+Another change relates to files in `archive/` directories. Client repositories
+now sync these files between themselves like any other files, until
+the files reach an archive repository. Only then are they removed from
+the client repositories. So you need to ensure you have at least one
+archive repository if you want to use the `archive/` directory feature.
+
+## version 4.20130323, 4.20130405
+
+These versions continue fixing bugs and adding features.
+
+## version 4.20130314
+
+This version makes a great many improvements and bugfixes, and is
+a recommended upgrade.
+
+If you have already used the webapp to locally pair two computers,
+a bug caused the paired repository to not be given an appropriate cost.
+To fix this, go into the Repositories page in the webapp, and drag the
+repository for the locally paired computer to come before any repositories
+that it's more expensive to transfer data to.
+
+## version 4.20130227
+
+This release fixes a bug with globbing that broke preferred content expressions.
+So, it is a recommended upgrade from the previous release, which introduced
+that bug.
+
+In this release, the assistant is fully working on Android, although
+it must be set up using the command line.
+
+Repositories can now be placed on filesystems that lack support for symbolic
+links; FAT support is complete.
+
+## version 3.20130216
+
+This adds a port to Android. Only usable at the command line so far;
+beta qualitty.
+
+Also a bugfix release, and improves support for FAT.
+
+The following are known limitations of this release of the git-annex
+assistant:
+
+* No Android app yet.
+* On BSD operating systems (but not on OS X), the assistant uses kqueue to
+  watch files. Kqueue has to open every directory it watches, so too many
+  directories will run it out of the max number of open files (typically
+  1024), and fail. See [[this_bug|bugs/Issue_on_OSX_with_some_system_limits]]
+  for a workaround.
+* Also on systems with kqueue, modifications to existing files in direct
+  mode will not be noticed.
+
+## version 3.20130107, 3.20130114, 3.20130124, 3.20130207
+
+These are bugfix releases.
+
+## version 3.20130102
+
+This release makes several significant improvements to the git-annex
+assistant, which is still in beta.
+
+The main improvement is direct mode. This allows you to directly edit files
+in the repository, and the assistant will automatically commit and sync
+your changes. Direct mode is the default for new repositories created
+by the assistant. To convert your existing repository to use direct mode,
+manually run `git annex direct` inside the repository.
+
+## version 3.20121211
+
+This release of the git-annex assistant (which is still in beta)
+consists of mostly bugfixes, user interface improvements, and improvements
+to existing features.
+
+In general, anything you can configure with the assistant's web app
+will work. Some examples of use cases supported by this release include:
+
+* Using Box.com's 5 gigabytes of free storage space as a cloud transfer
+  point between between repositories that cannot directly contact
+  one-another. (Many other cloud providers are also supported, from Rsync.net
+  to Amazon S3, to your own ssh server.)
+* Archiving or backing up files to Amazon Glacier. See [[archival_walkthrough]].
+* [[Sharing repositories with friends|share_with_a_friend_walkthrough]]
+  contacted through a Jabber server (such as Google Talk).
+* [[Pairing|local_pairing_walkthrough]] two computers that are on the same local
+  network (or VPN) and automatically keeping the files in the annex in
+  sync as changes are made to them.
+* Cloning your repository to removable drives, USB keys, etc. The assistant
+  will notice when the drive is mounted and keep it in sync.
+  Such a drive can be stored as an offline backup, or transported between
+  computers to keep them in sync.
+
+The following are known limitations of this release of the git-annex
+assistant:
+
+* The Max OSX standalone app may not work on all versions of Max OSX.
+  Please test!
+* On Mac OSX and BSD operating systems, the assistant uses kqueue to watch
+  files. Kqueue has to open every directory it watches, so too many
+  directories will run it out of the max number of open files (typically
+  1024), and fail. See [[bugs/Issue_on_OSX_with_some_system_limits]]
+  for a workaround.
+
+## version 3.20121126
+
+This adds several features to the git-annex assistant, which is still in beta.
+
+In general, anything you can configure with the assistant's web app
+will work. Some examples of use cases supported by this release include:
+
+* Using Box.com's 5 gigabytes of free storage space as a cloud transfer
+  point between between repositories that cannot directly contact
+  one-another. (Many other cloud providers are also supported, from Rsync.net
+  to Amazon S3, to your own ssh server.)
+* Archiving or backing up files to Amazon Glacier.
+* [[Sharing repositories with friends|share_with_a_friend_walkthrough]]
+  contacted through a Jabber server (such as Google Talk).
+* [[Pairing|local_pairing_walkthrough]] two computers that are on the same local
+  network (or VPN) and automatically keeping the files in the annex in
+  sync as changes are made to them.
+* Cloning your repository to removable drives, USB keys, etc. The assistant
+  will notice when the drive is mounted and keep it in sync.
+  Such a drive can be stored as an offline backup, or transported between
+  computers to keep them in sync.
+
+The following are known limitations of this release of the git-annex
+assistant:
+
+* The Max OSX standalone app does not work on all versions of Max OSX.
+* On Mac OSX and BSD operating systems, the assistant uses kqueue to watch
+  files. Kqueue has to open every directory it watches, so too many
+  directories will run it out of the max number of open files (typically
+  1024), and fail. See [[bugs/Issue_on_OSX_with_some_system_limits]]
+  for a workaround.
+* Retrieval of files from Amazon Glacier is not fully automated; the
+  assistant does not automatically retry in the 4 to 5 hours period 
+  when Glacier makes the files available.
+
+## version 3.20121112
+
+This is a major upgrade of the git-annex assistant, which is still in beta.
+
+In general, anything you can configure with the assistant's web app
+will work. Some examples of use cases supported by this release include:
+
+* [[Sharing repositories with friends|share_with_a_friend_walkthrough]]
+  contacted through a Jabber server (such as Google Talk).
+* Setting up cloud repositories, that are used as backups, archives,
+  or transfer points between repositories that cannot directly contact
+  one-another.
+* [[Pairing|local_pairing_walkthrough]] two computers that are on the same local
+  network (or VPN) and automatically keeping the files in the annex in
+  sync as changes are made to them.
+* Cloning your repository to removable drives, USB keys, etc. The assistant
+  will notice when the drive is mounted and keep it in sync.
+  Such a drive can be stored as an offline backup, or transported between
+  computers to keep them in sync.
+
+The following upgrade notes apply if you're upgrading from a previous version:
+
+* For best results, edit the configuration of repositories you set
+  up with older versions, and place them in a repository group.
+  This lets the assistant know how you want to use the repository; for backup,
+  archival, as a transfer point for clients, etc. Go to Configuration -&gt;
+  Manage Repositories, and click in the "configure" link to edit a repository's
+  configuration.
+* If you set up a cloud repository with an older version, and have multiple
+  clients using it, you are recommended to configure an Jabber account,
+  so that clients can use it to communicate when sending data to the
+  cloud repository. Configure Jabber by opening the webapp, and going to
+  Configuration -&gt; Configure jabber account
+* When setting up local pairing, the assistant did not limit the paired
+  computer to accessing a single git repository. This new version does,
+  by setting GIT_ANNEX_SHELL_DIRECTORY in `~/.ssh/authorized_keys`.
+
+The following are known limitations of this release of the git-annex
+assistant:
+
+* On Mac OSX and BSD operating systems, the assistant uses kqueue to watch
+  files. Kqueue has to open every directory it watches, so too many
+  directories will run it out of the max number of open files (typically
+  1024), and fail. See [[bugs/Issue_on_OSX_with_some_system_limits]]
+  for a workaround.
+
+## version 3.20121009
+
+This is a maintenance release of the git-annex assistant, which is still in
+beta.
+
+In general, anything you can configure with the assistant's web app
+will work. Some examples of use cases supported by this release include:
+
+* [[Pairing|local_pairing_walkthrough]] two computers that are on the same local
+  network (or VPN) and automatically keeping the files in the annex in
+  sync as changes are made to them.
+* Cloning your repository to removable drives, USB keys, etc. The assistant
+  will notice when the drive is mounted and keep it in sync.
+  Such a drive can be stored as an offline backup, or transported between
+  computers to keep them in sync.
+* Cloning your repository to a remote server, running ssh, and uploading
+  changes made to your files to the server. There is special support
+  for using the rsync.net cloud provider this way, or any shell account
+  on a typical unix server, such as a Linode VPS can be used.
+
+The following are known limitations of this release of the git-annex
+assistant:
+
+* On Mac OSX and BSD operating systems, the assistant uses kqueue to watch
+  files. Kqueue has to open every directory it watches, so too many
+  directories will run it out of the max number of open files (typically
+  1024), and fail. See [[bugs/Issue_on_OSX_with_some_system_limits]]
+  for a workaround.
+* In order to ensure that all multiple repositories are kept in sync,
+  each computer with a repository must be running the git-annex assistant.
+* The assistant does not yet always manage to keep repositories in sync
+  when some are hidden from others behind firewalls.
+
+## version 3.20120924
+
+This is the first beta release of the git-annex assistant.
+
+In general, anything you can configure with the assistant's web app
+will work. Some examples of use cases supported by this release include:
+
+* [[Pairing|local_pairing_walkthrough]] two computers that are on the same local
+  network (or VPN) and automatically keeping the files in the annex in
+  sync as changes are made to them.
+* Cloning your repository to removable drives, USB keys, etc. The assistant
+  will notice when the drive is mounted and keep it in sync.
+  Such a drive can be stored as an offline backup, or transported between
+  computers to keep them in sync.
+* Cloning your repository to a remote server, running ssh, and uploading
+  changes made to your files to the server. There is special support
+  for using the rsync.net cloud provider this way, or any shell account
+  on a typical unix server, such as a Linode VPS can be used.
+
+The following are known limitations of this release of the git-annex
+assistant:
+
+* On Mac OSX and BSD operating systems, the assistant uses kqueue to watch
+  files. Kqueue has to open every directory it watches, so too many
+  directories will run it out of the max number of open files (typically
+  1024), and fail. See [[bugs/Issue_on_OSX_with_some_system_limits]]
+  for a workaround.
+* In order to ensure that all multiple repositories are kept in sync,
+  each computer with a repository must be running the git-annex assistant.
+* The assistant does not yet always manage to keep repositories in sync
+  when some are hidden from others behind firewalls.
+* If a file is checked into git as a normal file and gets modified
+  (or merged, etc), it will be converted into an annexed file. So you
+  should not mix use of the assistant with normal git files in the same
+  repository yet.
+* If you `git annex unlock` a file, it will immediately be re-locked.
+  See [[bugs/watcher_commits_unlocked_files]].
diff --git a/doc/assistant/release_notes/comment_1_bd8f376c9d0c1d5ed07fb013907a60ee._comment b/doc/assistant/release_notes/comment_1_bd8f376c9d0c1d5ed07fb013907a60ee._comment
new file mode 100644
index 0000000000..04cdf4039d
--- /dev/null
+++ b/doc/assistant/release_notes/comment_1_bd8f376c9d0c1d5ed07fb013907a60ee._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://wiggy.net/"
+ nickname="Wichert"
+ subject="OSX 10.8's gatekeeper does not like git-annex"
+ date="2012-11-13T14:47:52Z"
+ content="""
+Trying to run this release on OSX results in an error message from Gatekeeper:
+
+> \"git-annex\" can't be opened because it is from an unidentified developer.
+> 
+> Your security preferences allow installation of only apps from the Mac App Store and identified developers.
+
+It would be nice if the binary could be signed to make Gatekeeper happy. Until then a note in the installation instructions might be useful.
+"""]]
diff --git a/doc/assistant/release_notes/comment_2_75e0774ad042717fbd059a8a9ec2db1e._comment b/doc/assistant/release_notes/comment_2_75e0774ad042717fbd059a8a9ec2db1e._comment
new file mode 100644
index 0000000000..9033b1af6d
--- /dev/null
+++ b/doc/assistant/release_notes/comment_2_75e0774ad042717fbd059a8a9ec2db1e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://wiggy.net/"
+ nickname="Wichert"
+ subject="git-annex not runnable on OSX 10.8"
+ date="2012-11-13T14:49:35Z"
+ content="""
+After telling Gatekeeper that I really want to run git-annex it still fails:
+
+[fog;~]-131> open Applications/git-annex.app 
+LSOpenURLsWithRole() failed with error -10810 for the file /Users/wichert/Applications/git-annex.app.
+
+"""]]
diff --git a/doc/assistant/release_notes/comment_3_b3bfd8e547e20c51f7c32c6c9424e936._comment b/doc/assistant/release_notes/comment_3_b3bfd8e547e20c51f7c32c6c9424e936._comment
new file mode 100644
index 0000000000..73377c714f
--- /dev/null
+++ b/doc/assistant/release_notes/comment_3_b3bfd8e547e20c51f7c32c6c9424e936._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.11.120"
+ subject="comment 3"
+ date="2012-11-13T17:11:51Z"
+ content="""
+This has been previously reported: [[bugs/OSX_git-annex.app_error:__LSOpenURLsWithRole()]]
+
+No clue what that error is supposed to mean. 
+"""]]
diff --git a/doc/assistant/release_notes/comment_4_c6caa2b521b456bb4ce594d64919cffe._comment b/doc/assistant/release_notes/comment_4_c6caa2b521b456bb4ce594d64919cffe._comment
new file mode 100644
index 0000000000..1ebaf504f8
--- /dev/null
+++ b/doc/assistant/release_notes/comment_4_c6caa2b521b456bb4ce594d64919cffe._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 4"
+ date="2012-11-16T13:02:40Z"
+ content="""
+sadly i only have a 10.7 machine to create the builds, so I have no experience with 10.8. I haven't had a 10.6 machine in a while to create the builds. Anyone else want to work together in setting up another 10.6 or 10.8 builder for others?
+"""]]
diff --git a/doc/assistant/release_notes/comment_5_e9faf88a8eeb9aa8714c8c0514792815._comment b/doc/assistant/release_notes/comment_5_e9faf88a8eeb9aa8714c8c0514792815._comment
new file mode 100644
index 0000000000..b3f9e1d5cf
--- /dev/null
+++ b/doc/assistant/release_notes/comment_5_e9faf88a8eeb9aa8714c8c0514792815._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="cscsordas@57324e38725d7f92862b3df34b6db7817456dea5"
+ nickname="cscsordas"
+ avatar="http://cdn.libravatar.org/avatar/5e54a8f6cd253a8bbb5faf02e3390a1e"
+ subject="7.20190129-2~bpo9+1"
+ date="2019-09-13T17:52:05Z"
+ content="""
+The Debian package should depend on xdg-utils:
+
+    Launching web browser on file:///tmp/webapp1804289383846930886.html
+    git-annex: xdg-open: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
+    WebApp crashed: xdg-open: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
+"""]]
diff --git a/doc/assistant/release_notes/comment_6_53c2b479dbb53236000b4b3caad8ed04._comment b/doc/assistant/release_notes/comment_6_53c2b479dbb53236000b4b3caad8ed04._comment
new file mode 100644
index 0000000000..578f4697f0
--- /dev/null
+++ b/doc/assistant/release_notes/comment_6_53c2b479dbb53236000b4b3caad8ed04._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2019-09-16T17:45:26Z"
+ content="""
+@cscsordas, please don't post problems on random pages of this website,
+there is a bug tracker that you can use.
+
+I do not think that git-annex needs to depend on xdg-open, any more than
+it needs to depend on a web browser. Current behavior seems ok to me,
+the user can open the url that it displays themselves, or can work out
+how to install xdg-open.
+"""]]
diff --git a/doc/assistant/remote_sharing_walkthrough.mdwn b/doc/assistant/remote_sharing_walkthrough.mdwn
new file mode 100644
index 0000000000..ec8f39d531
--- /dev/null
+++ b/doc/assistant/remote_sharing_walkthrough.mdwn
@@ -0,0 +1,12 @@
+So you have two computers that are not in the same place, and you want them
+to share the same synchronised folder, communicating directly with each other.
+
+[[!inline feeds=no template=bare pages=videos/git-annex_assistant_remote_sharing]]
+
+You can add even more computers using the same method shown here.
+
+----
+
+If you have a laptop that is sometimes near another computer, you can
+speed up file transfers when it is by also connecting it using the
+[[local_pairing_walkthrough]].
diff --git a/doc/assistant/repairrepository.png b/doc/assistant/repairrepository.png
new file mode 100644
index 0000000000000000000000000000000000000000..d49ea9d95539b62e1b9363e4d6fb47866c7228e6
GIT binary patch
literal 31791
zcmc$_WpEtX7NuK~Y%$rgm@SK$nJs2!W@ctv%(9p*iy2GI%*@OT7PIt9-S^JizTGo#
zCgMfB9}e4DnI|jroUB}H?Qe(3N{b-CV!;9c00c47ukru@xC{UQ76=Uv+Hz8KF%S9+
z##U6#0RTYke)|I!Pl<>P+6d(+CM5*50*m$u_oKLEwghMsrlXLmqo9qIm65e0K+xVu
z&(X+`z{Skblt4sGN>;@W5gh;^0Em6%S9D!GZt<}sT5vkMPfu2MS}Gby+BptpWNCmD
z<<#P*!h%i?3V!_fp;y+mJh_LdGC3~-jdg00=8Kz%C07Xa7qF;p2r|N-SL27mU!DmM
z34fqvLBfq1jwJJ$yY>*|eY+Kf$b$EOw)_As+U%dwz5PTs8YLfP@=DONrbKlpB2)b6
zIc{1}bjp33<}g;OaI0K+m`vMx2mX#9`Q7=~OR5H60_bl)Ek%$)8_+W(5SD(Cc|RQF
zXZpObHw1z{s^{anU3Sp9A5>{<Y*fed%DZVzCx8|a5!q(=MgYC}&Hnykr`-Fxc;vB|
zG8wcv?hyJLK``8iNv78<L!wgk3TdXNfc0n4Mj8(4DK+M$i58Bx17Us|ab%k?z<_op
z#UFHj`#MIPpb!52UE)qahd_U;!UcW6FI!9W_P;-O<6npbeLz6A^Z|6x|KV<b8T)@d
z+Fy42>)8K!(*MnFe;ND#-wWav^CaP#;h_9PjK>$A*`y_K+!-{*o@|R%xwkjd*U*ON
zXD!25FJJ577!0M;2<uaG&;KZZ#OqeFd?Vs>zM2g>&i{1zLb|2ad(~M=^OmQ~FNH$_
z<&#8lXbUD!WhZD9j#3WRLr;T)CnpcjuK22zEf>fE>J_Yjq<ec{z1JnS)zIDN*9TQM
znj2H0h$zSn?MmxaPMfA1{5e^z6xg&Zn89473LBa<)s4$b^HOC}x<gI3ca7Y&8{!M6
zl|*<jt;AQoo!BR^FIY&t9bKOZSWaF)A%(f#nLTrrKm(9?drXA5o=ONiHuWm`r*8>s
z$S>9CpI$!jpd9AJ@A&+xKY*m<v8nXGO9nitSKiAbi0zZm7S&p734sYvAuP`lQv;JL
zYbqA#m~B+&3oR28_<A6q?bd(xJZXnRoY1&;f9ht7w$N(fkF^gYhdxJ3y>R~wL9fk<
zjlAh`K;@sb9iN;7;}$FiZ5J%2*jW-#qug^yKgX^!n<)=Fbf*(sm-!sml1M&aGcDdL
zgfN<Dra1U|;e`NT4?Yk4ZJMo-TCreJDNf$4j+7ROQ@o7*m6AqF5_s8hJ&&-q8@QLZ
zkO7gMKz8G{i;wtvY?6uZ{W1*P!+%*vQd05047hk{d)<o%J*Z)0nU9E<7ISCXhxgP@
z<mYS4Tu+y0ygqw2y!Q=v$1cg)OKU1E<Cn~U%$K7_pL^D`*KN>`*szY<o%`#hihC>K
zdeqBi3;t`SWnpE4(Mw&MCokn@6bo;~<?)eMqMwe*%SNWk%gY9B_g>AIm-nL!t(ngw
z@qJ!u>D~JMUeN1i%g9`Y+lIx;P9E>WcGT;Ij`Hj6Yr|gE$IEm68y$7#FNLY$1r+!`
z+mCiHJ!_|!&!^{VUx@Ddy5gO(0_sM5lVD{0y8=pnPFB3%`x%J+8%)wn&t&7}dC@6j
zGH(xPb~}81z4Mi0t<+#@G+8g9F45#RrqH$^8m&=Evt#!#R`Xr3>$ju#{KpK%)w2hB
z!WNV#iId$94vX9l2J97yD2?c=EX<bT2kh5}SK(*srtC4J#cX-5U0IWhdjR82<Nb=@
zkW{^}8GY<2mV?>Fcl0PB)MaNz4bAgC^g@)GtPNhe2ndroq0F=?N{$IPCPp91<@5*}
zYFd*-_nO>TPE4<SSg5Z|lLUhlvTH};aprXmyyx2RBu(DOhj7+3on(ZpFE`y<0DsuY
zeZMrqioa;{)Cq%%Nxz>_m4;}~8CBOpOmOKxoaM2s!gq4<dTK{cGXmyqSxZZ;T#Pl}
z)AY@nv?JnzR!Da&W1WQX>?PJvh2PLo$pG%a!3yn*$4it#qW7NC2$IgD@f|1a^S%vF
z>GA9LOkSws-D`Z$%c|?t*-Y+O_B*A6@utt#FUNDVs%`fVNUfMtEqD08&Ju5s&bHS!
zbZXmfq#iBSJa6lC8t<oqMkL&*hr(ahv2)+cT%NT62ppnczrWt}Ks~Q{K0~c_-!l9B
zUW>l(`{p?{qI{+4eba*8w03_s19zYKWN_Y+*t+O&uSUEJu@mThr>-T)&^QoGaXAsh
z>)!Nx=&a@H!KGaBrcxbf;E+{Aqo|I>F|UP-WcRylf%S}j6&Qm+g05lJP@%A}OsQ|)
z((gKFnR+Y#+{*XU^OY7w10Ts@_&CMtQhT<A1(;-o36Z=qGjM|UavJJ%xmtEo#w*+U
zE@8s3+?P*ve7J0Z<&4=z{2-aFb9+;-qs4foIX^`wHQY9NMG1h4bcMKt<rK@(fiD_B
zeHj>!`nb!z@}%yIiEs}w0-E&!suZ#NYJuv`45dm%9ytXbbPaqp)UZ?LrCshj77^u`
zFkn4r(t<V?(l=^m)*6P51u-0EbK<REkb6T+6gximtv4Qt&Q>m^7Pk*`rzeZ2?vYJ=
z;;h7a4$rTxF7p-<Cql(=av}4CHddleq_!pYHpnu=%hIY^K7H)fVC@HvCGL=C3xR;L
zhGn0J$Eeq<wN^tPJiyDd3oYqgM#?jHHuo5Kz4QG7`lI61>$R<dPTBSMwJq<v)G_e8
z)7#dImhJNIxr$%bGg~i*<0XvbczMy3B!(E)+QJ840iFY!M{Tda_ICCFnjWAryfYuG
z+g=lSUuWlxQmoB-GM`4_HZpg-?`$GdU;1QTwwqpK1uns!)^CRpFxzh9ePW-SG*%41
zg56y`-v+IrYCqM{+L#}9hP)r9vVG$9jVLYXVm=yY1Pr?ipI~XiOOGY@Z9gutu(17n
z4_MX1TBb;Fh7^?R+b_|A1E6KVARuu6CP_J>u@QpOx`Z$X&@I)F7i)x&csW1vjo@VK
zDZp+;J0zI^R8<Q^pb`^F_oxi=+>xd~8+`NX7-8&FIiLy`+&%AbgBmB0Dw>CRQp-})
zJ4&i<c)I9~oY}!<tRUV|o3o|ENup<EX{`sExQr}b!vn&SFYyt%Rc~soDihTAhFBLT
zLBG^3F0NOR@kSVcifR9#IBVFh-En8`Mtb&jGKsKLlH;2J<0<KN)tyy>4F86ejvM!s
zlWMGKKnbLi`by>^B9Q8S3W<lcO_k?W8|)=fV&?fKvFOt4QDRtz_pZ6|-d^P(sMfgX
zYBP-XX`A%b@eWC?`L&o5S*n!gV_clutx9Iw%Y~pPN!&}z%SBh_(_xn96m@BZ&(YxP
zZ3knfw`Pig*UQxHd6$iroGA~$Lk5^N_GzDl=y0k_XXWYqvG=U)DwFx7JZ<wppe-wf
z^})@HLCaKQXgE=&Xoi`zd;5ErcWdJ}Ey`MJOad*sgTWw-_I9$#?qQ1~)NzUs$y6~F
zZjsAF!`cWl1`-SmI%Gfi?l0Z-2~v2#A3rOSKKcymZZzy(oI7@m?h$m0zgl|IWSG;p
zNE^XDGp{yH*z7wt&vEFq%8|bgT>*<+$nY=*Y@!Iz^`jZ-@?qCQi<HB7Vhnno_}w}f
zDAh+E814R8`0dNm(ALdHF7WgMC5|ul+H<9l-{Bynf7%^;Ltkl{$Bgp6Ge>`Rr{R6n
z8=0UiRbRPt(Rpq2o=v}B5LtUMJHJlkdG2WQdKsMa-g;-m1L1vTY-Qnkb~$t*Raf(C
z@8dAX4e0?=x!0}uZf5A(EZ6I|s!#@mfw%kS^IVMN9Vy{M^8)KyX|;z7W?t(qyrD|Q
z&RNGriVjvLtXMi9h{m30Acf^$IcOa)4QIHRLSphQTD%le|FIu7oXlB_2R)}E3EXF}
zU6gH>_hXqPmC#Su>7~V2W@oboY3y=`R?lqtm&5~$%&`p}Ry;@-rhwoUR%<6U%#-#I
zh<bZ}2zTmQS0?@1wb9(oMjmVr;Yg)Zgw0NqreSL`yLm0u(0t_~8DdnSoG3-8Cc+k@
z`ocTLyJP6Yrj%QshlPpwt>;W{=XYF0Yh?!vFL`H!v_5BpGX6R~zt78kuB=(^y4KkE
zG1nJj@UJx8$_{UqP9m(WdXCyIu_=AhTY8IMhSqjOUS+eJe+_@tQD-%iYrBn@(`mly
z<9s#fyLpLUds1&AY5YpqSFzI&K(_6BnqXr0e$knK`1^+WSFukh7rG6x=99aN#m?E<
zx_J8>l`w=+q=RD^ErC2}@DPxlFV{yS*QjWm_>H(04!WNV%dxOyc-h*7bDwD!=D5Ou
z^j^lQnf(zkJ)Z3z4#rmNRNxpasmx4HU6w9^iD*`*BMx?!P{bi&i6`Cb!u4Z7-IG0w
zTVVqzZ0s$bu<8wSvCC`9HrKPQGgI-Y44tiw{Q9ez$rl}C-lwuw&${Ep1teyjw#mGm
zpiIpM$NQ$ljOWw2jOV!LO{0yl^^if&$0L<i&?;!nzJEB696SFls$VwK8|t$*b)CJJ
zl=*V3^ExEhdzm^$UQQMeZq4xPW$jF>6<qSR&GWMS_2AX*nw{&lSrUbtLxBWy27gVx
z|4TM^V@fVHA(S!#L8AF<kS9e1VeH}**5DX(&Q{E9k7J&sxr_w`Zx9Uq``&TwSQhp&
zV1^U8f?WKlqdv;F$AD6HEhFWW5a7#_XF$*B_l#l^DR&WzDixHrBnYgzqehRi*~O%A
z>vWyBb#-Jx-$Td2-L(%y?$8{<8|kO~$!0ms#X6)J5rpOv`jnKw?a=3}_=8MmREI#z
z;rzF@_FmPwF&gky6XJo}Z>$G9Q^ft*#mB+!%&Ym8((`G879{<Au2gnzGv*PNGoM$2
zGVxyEcu;t_J<rBoPKlcQVr|?X$}igP?s+%1kj~FV+9Y?pw*tzYWp^9OkPu(r<NH9b
zL$wV(=kJST;<W~i@pOuu^}XKsEZ-m9?xZGEZNlolj@mqt-47u7JO)Hkh!bXmw4(g4
zjOW?hj5Ut~5#G_Q>L{a>{Wkhfn(!e|63F_S9h1HK1+Trb_ca9v5`j<1&M|5$s*7gW
z@LsHewP<rOF#PkV3Vt)Xzl`XQ#`kCKp_7p>nv(nDd_FHL$Fd|&O}bmZ%ho?c^w*-V
zZUo{~Ax7fOO~4cqZ@X~P@f&?|<^qivwOzZW3LmmR8JsMe&6KR4pTZARuD3qj#DRqr
zAohrX%TEwi=B8#y9^k13YSz-@U%n&S4AHP$Du{bEdUzPUGbiEldt&ilk({3@JxZLD
za+{~)Yg?(sSU##-;=E`Pc$<fMSBEBDGAmp>>rn|R+Yxpg_yChb+B}ig8K=vw#FzEH
zdvu=H<HRwS*S@pFIn-B0pZh4@`(FIh=GV<V{MJ5A_j3>0*TPl?@@7rirsn(2v*J>p
z#}^lG5=}_&d#=Y!s0<q#S|#J{M_M%(@9WPzFX!tv;htfbFUQzEcd<y?pLibtV}`AH
zDbL<@o>TJ5fQq)KV;z!n(#G-{$3#b=!oV+13ZD<he2R~D_srLH_PEQn3)@1ARwZoJ
zYfu8>HCCg=q0v>Pq8xh6$Z28OS5C=a8)-h0+jDFcAkB~-U|S2tu?9h1;Vrl9L^$rn
zz8}?fj5zgp8j-e5na=3C*NE+~rcYMV2+S|FVvaGdOwW*w7+r(?s(7Cc-esQVva(y%
zZoyc+m7&XebJ}87h)QhG8Es?Cg*;Ir9ErhF?ojV(%z}fB8CBA9QV>s~Ai4OC{YagB
zxv_aA=O(;t8P;FvzW+nlE|XxkwL~>pV*0J_%j~vrT@u%HQo8oh<~VRSFIRJVyzyT@
z%d<P!NMEOqCTP}W4KT0OcbtyCSnBR9km;T!rfg=mSK_*UH{E^9Pkvn$%aU>JHuehr
zmOSz}29N%zXYRDb`htuPzSim=xOeFNf_w%>3%*u5aL0RJ@-PREkczpUh-8O(cSC$7
z8fT-HmjmHDsF2d;8cekqY(8&kCUn>Ka_J-La~{R(sWxgRg}Q@nUYIH%mkD0^zzxtB
z*y`GW`V8v}JI*NeC{%#4kJ%mNQJv-9WemyoX`+h{t~=o3a&zR1P_S<xf0qTcy7}j|
zUvU}b%@>2ukGB#J6#yL@b#Z^y%de&@5BdHunCr5DF1|kB_ZNH*^`+`&3_a>8<Fk#B
z0r7X4U`+7pG*Q7&662gxpD6)Ykd`#wUSC{aPvVW`sI{i$TM{A$A9Y9$#g%07@h%$4
zVXy&9#Th*XzstHUmj0APfC9xLxU`dCicA>%W>VGHhpn^M4OU~HBZm7eiG0UeVqT`-
zz1S|AyEUuk5M7@W)wPy6YwAsopHNPH2uX5&5lzW$8UDWUP3T;wA8=0WCr6LreHcRW
z2{8c%+B}JfJ4L}={dR%FX<eG~!$4m>fDBFXj+okDsFZ1bU8~0&_@;zJ9VJ)fk@mA;
zC19HrbmQr?J5eusw*01l5D)?mwsHkd4}SY-zJpNIaS-IfbKv|VUFwd_JlS8`0VPY_
zu}FXBH~+f`O6+ql7+-L@kAzz=IVc6NBY+^g3!aCmasL$Pc(}2hxYh<5Nyede$V%ou
zfAce)9iwLk>GJod)9KT0(e>TU?vd-lxmgt(Dg0$jes7J|)ov%7d?_bQA<6XWsDSpn
z&BTNQz^fuv9k<X{EJ1Mf=4J~!6}}EG66|R_J!FMMv)whkbbWGvql;JmQlZ^&l9MGq
zoZMFmS{j~yhm4A)hVGQ!oWoO>Rn2^*ggkHqIEy`3?ilf1_tqK}dU{`{-J82oR^@tR
z6Z>&8V(3lsv?Un79^2P~rEV}^%*wz8jBd8>?+GZ((B~=SG4uN8vcd6a6g|sjCZ610
zTc;}?weJ}%_T-I8tT*fp+;=mi9ETBPXimc#T*LBW%tl9%W05zJW1TV^X-cQ#XGJy4
zHI$g4Dr+L$pR6nhTN6hGg87FXmqV+Fr@mT_O`9l_JOKo7*i74WiilG73iSuOL%e8I
zbnUbjT!ukGVMa;A3cn@kz;7Ojd#z%WxfZw`^vtm2-(T4@`(Y^%G;9&g>%rE}^M`vh
z4JmL2^8)Y?9QJL^r)wLU+waOfygJmBHC`U#k|h4^s$s*Xz>M$8Z1@nM8-h)U6o=uo
zj7PF&PBd?6*i}|f4yuJ%1f1&%g}n)>9aHPSjm)TU@`wK|7yxjw=C3faCO~+wXL)R#
zJkaXyxFnJ!vOkt|L7o#-F}7h1nE{ff)ryBYE+Ruxv${T$SO-!ohgnH3$x$-n#S$fm
zA}(lINxE8r;tDS>P&VOmG+*OjoV0Vo@TlSJPrz`bkVU^nFu!F(16RnIG5$NvX8xBC
zb-#%|r+RfdBn4=NsnmuYAFG$t4mK%M!udiq6~_{m`8ao!8UJ9n>pp55Dk~Z>0N7Vv
z$0$u4Yg8Z18!F=@r>M&X%oz9Sl{43(<Fbu9pMO1$uCu2?)Q`b1Sgbh!%MtMFDe2;{
zVW^r9*)xc(n@lrH@*7#K<7!dlfHKiPiq#wCXwuz^?hjP}lM&MJA&AFM!rz}N!Z5sq
zwzOP&2J2fU@ofPI*YnHNVq|G1W34;MT>c1ohKN)EcGn{D&7fyCAJwm4o20fLSOMO*
z3lfJa$Ek2wd0Wai#pR*sgn8`+vd^07s;xZ8mu7x54wBd#LXxHE2&>H4LAGRg(05)I
z&dJa6xE<`88|^hKtVk8U$cXQzN8J*@01|D?&D9R6Z_lobM(vVJt_T#u$Rlg*FT}YL
z!7%{c5hl>WmY$8<1P`L3xzfPtz89Vf05?`qwxP>LXW%?<IhTzc3xVh&Cg8}bS0@AR
zO8F6}g|81rkD?)Ew(GS+8>dROTnfErQwg>Xdi~of7Gb~(;bvDmQ;S~+3JM}MhfESa
zertNbb42SUyu4fY++k77Tv`3ijZBYnE@M+&*5uHqBecND<=!{QkgL!pm0H#4cLBvq
zY2$fTfO@8}!<nA^Taiw2y25R*CVm15qMy`-?K?s{KSSAuM?7?01VV!UCF0b&@`tL&
zT#in?&DCJ-vxs+BENlF16~$Q1CS;_0-qm^w)soq91i@1d9j8l1a3UO~jcz_%TKlYu
zGKbI2JjpbQhzs{P{;CI=5o0|HYJfj2ndd?8kLcl0<!U@WhWOJxC&27?{^Aw&N7NX+
z;974KK<%ys-T+k4v!_z7Ix{>xMlc_w{zrYyA(ANboaFmPO;S96uGr#cmr<=tFgm3(
zSuVOCYk2%L-2`(NTXVQT`GJ_&52H0z_H2zTJn5rWG6d*q+L3XH#QGk_*<#7Rt2PcF
zqDpI)X=gqFmdpGWqLbFrQxL*V=_PVQrMryags^ho@pCyjZ~`=o8DBp9EED6$3Cm6q
ze2K9&^8O6oldTQF8MmnH$^KCN>`a3?cfBBPvfK4}+8mM3khW>JY@no*pRlFe2#jyo
z1SFpmoI%zu??9cIAV<E~Z=R<LoG4Ta!Kbiq7Mp<{PZIyS9`1<m+Dzu}j*Tz-JiSJ~
z;{Xe2S7CR2v(jK^lLXfrQSBlTq#u$q#GWl${}mtj$92@eyFVtSR+}w3rPm7UMdl*;
ze|UFZW6T-sMmM4paQra<rz;^g_RUaj39du}+3Bc9+y82OQevI()<gG=V>nw&i7m@%
z^1_gX=-}lierA>baB4JH`WT=oB;CIia=|EEo)z`J%h#{M=eaRXO=R?E#9kivmdjpO
zc&lfAs7WPD-WdE5N&|gX5|XRUXbH1%Q>1#KF1I!{j_h}xO7yQDZkuF=Rln4IJf-Xy
zHa?0vzq=TC79HehOZY9*8S~DB&Dl63kc=PMr1QPTz_GlUeX`@_3tl>TY`8KD<A7;Y
znP=~DgZX5R%P>{sD~xg8lWKGF9v+>_R#s2?XPeoCvCb846~@9ZfQSh+o$JqSVVZ1s
zNy~a^e5@B6Pi3SP-li_|;yX%Mf+Ro{GY;G+MQ^BExN7N@3N#2DDk`P{C(Nl+jv52V
zo5SI!X-ABPm96OveS$+wwwj7dNhXhJ&B|<L3LigNPP0kyc;-n%t`2N>88S_@gGgjS
zu(rX|Mk`$pk(R7>{ha{jd&@?RTr=g2w}RA|Ge;|Haxlx;**{nfH}JhT;s1we*zPRM
zjZqp?-U(l`siTIxeK?uPf02B?Nw-Bt7Fp@?JC0zrJ_(oH`|NeeXh5>HzuYfsX(%|w
z%j(0$EU*@lRodfZD1hwTqo~WAR8W-50LzI7-PA8)zhpxd_|?&@Te2Y6EZ5OtsoO65
z@@2pXS`6UQtHQVevt37cY}}b)t@V1&Bu1K(5WRL%6JJYf6>`#J{xVs{xN#xs^p&Qz
zF=Mtq-56ki<`f6q(=Xnc#tu8Y)7}|GdB-nm*P+ZXqP!$+>)F0hl$q9UHX;2<+1gEz
zf>2YJnR^s9KexHajJ1$Eo3ajEPl?CAyMldWyrAg;$3NaA+qb3d0o~?1;!uAnu7%;C
zVXB%2hG-ZB1>YE;JzOjC5MMdO&1+-|y$iw}>2&o%xbboT+=Q-C_?G)+GK+9+*p=Xy
zS_BTgrS_if{jen)3j>~-#}XJ*b74*+yMdex>RuvON9Fqr&~Gushims5IJRk3;g(tX
z<o_@L2RZSJZG5IupL^Uz?gw{6Bu!h|oJ4}Z`LJ6!G)zmf@5nS-hGpck#{wWZC$uj2
zL+y7!!Xd|XH;lHG?3v;dY*bq#`0vG$!g#`nSq8}Ucoppioy)pOkg(<>W}o>1hA2b_
zlFuhnZ6``&`iib~F9?P)5Oz)+>yterh$z|g-}DG!^;u#<azD$(9AINLagWP;BSBCj
zqszLLFhJnI>SF9;RPf=6hSAXn!_4#%`SnVD5XFNd7lZt%C;P}`F7EHz3|?3fzZ;lR
zsPtk;(w{mz{$bNDOtQs{12TDqbE~6^m32?G=WVv)5_1)c!qQIwCB2u0?fsph8lS4>
z0tIf*+T13GF;V0vVh#%I7+jk+kk)+beRo8K=f$p|#ezFQen$<jIcqG>;dgk7z(Mms
z-&#E?-EawfDw{nd=zVBV3qc1=pE`bra)9KK_S%=G<-<T|)65b7zSw!W{%Bl+doKe5
zQ3(38DkKHuVc@mGW;61c<U7PtK?ev&Es!!+NIL;^3jx+KEApe;0W;_U$WdyqDFp`q
zqj)=5y;8mX>8;Eg67;8h{{Oms%1JCx^6Xv6U_$)LWS?=Y&8Cu=QMZd;Jd|+^;1rag
zoWaMBN{=Uzk%8wTT#yci(BG1#Ur?0xM~0%aTUnAH?jEtduKS89)~&eI2)u|NH@lCO
z&AuVZYY7_b$lWV->(jf;z1T5*>=!6w@s>s>MHS)ZdG=6_@u~crP=(7yG;}Zdj69gn
zRW2>SR<Ps}eHBgxF`pQ1u%=n?w0b5Rlv~L6uYpf8v^M|E0^Fm>7T*vVzYf_RxLLIN
zWI^61{yHIoYgi1F#w2}=(s|8L+SVxv&b5T{V<oxW0(#VTWwm6Vu8b?6jNW-`u17E@
zdP5;^@-Y*o5ONpNq9!y_q5e^d#ORhJy>LL@Lf+yl%bk`U5)7}itSgGb2yz`4J_#%~
zAVf5bBpt7sjKdcY9`JnT(o}c;z<`|UUVYr6n4Zf}OF)GFkwH&kNeXoUAys~5qO*pp
z`-?wY_ZI>(1jvBE{-Bm-a0Cg%T&Y59D`$HsZS!0{FG1=+XOU4$&CljPNV>5S6LUJn
zDDc#Kb85t$(8z6yr}XX|Z4bZ?%ug9fe-)!?F!R)QdZ?63*$5d^chUG#pGb9oG)^tX
zNgK$$?g7>IMyk#FhUtcuBw`-|9&b|xiO`c_gR0E3M7nS|(y)M5h`NU=r~*MklFRTK
zC1^`Y$|0VAQ`fsffsunA+NsWCnmRhtIhQLOEGJyn=*Wy4A-46=sESy%>p0W45InwS
z%1yI}Ph~#bNu#h7C@!WhOWY_O4K8Oxq81)xZzqN|%UbG2wJd9OhGX8_oGetyH}RYk
z7z%OJ?xF9&MvR};K9w390Tm`AcG|V2_qAP@zF5HdZ_At7(Z;J3E^H!rC<XthC_EuS
zh;?o((M48YwK)Vrnq{oJ^CLG6AC@?|CrvB@f|Erp?YwA*c6w+c$<^<h2TmX?q7ecg
zs%vrxPr9_V{Q@Tx7cCE!#Yicye#C(zAk0usRWcs^i2ApmvEV>UOljQ7bi34wEX53$
z+W4{~lbocuuf1dC!~svf#O;hB75H1fu_}2H(S+T?c9<bf6z4ebDq-WIXVu$zTqRO#
ztf=2(&Jw3q;M}tPOru&t>d@gIe8O(yRDpqm-s=P9&B*(a^M#+Ko^38-wk7iqHJ_0e
zhPu(}(3H2)FyrFZ-imdmpducdzu<YhUDH2%kr8v1@|(KEJl63ut?I&LQwH9RWKUZ~
zo-f2wFR~=HJea#B)o?6`Ath|6zx!_w*c+Ja{0DjjSB6uRx^ga)t{(Q3iq(fO{)fG=
zw;Fy&huME<JZou0=;t=mSc_wP(q&u@EmL4A!4{WxBjbEfmfT{&1u_np(5~WnGfsV{
zhgZ%~&!=gjLSIrsplUsDEdft{ir%{3KV^#bqeqA;Dy?pza2!$@I>vqD2*o==)A6j_
zu{>VNAg#PlO#U7VYmqmd(PBdt=SJPYW5RFC5?!Vn(aplD$O4fR(`T?dN8py??Kuzy
z!3=^!0=iBDG(AObfUMH=g9Rz-?+0pgy~k2IW><MX#;?qyh$cC9amK*`XLJbGs7C&@
zHpi-3t@IFZ?VXGz7Hk-Z!_!C}C~$z?6k8igpR?clxRgV50NqM61?9Tt2-u;eUdYs?
zmHAK(&1yt$i1reb>9UTV^{X_u615Z9Fbxmqxe~20Kt&S!>&EzZqw;2^d%+IbX?hNe
zxnJA8<KyEHHUhn?mkxz?{p`bx04l2K?C(QEu?`9Lh)2~+P?7od47E%!4Ikj89}cV2
zJ?B+}aQkX8AnWMZm75kiYj#Tae_D9+Apmx<rjFsPGuSh1E9nrE`=Iu4t2zjdB8ouw
zueB81s!3^eK)m@&uCJtJ=5Vr8_VB;zX)57=)YEqLfg4}WWD1iM%YJm$a^MC!uASO-
z>oVp45Chy#JHv8>C4lKpFp$fU;v9pEl5CM=H^{GcI^^P;*G6o+HtOy<AnWJ)u<)SE
z7%d%6DYyQ$>SXnfg34xhX5^%ID!^ONDXS`Tj&$n%{jU6i0IyD|efHYVuPMV>pt9JD
z!3tm+O`%_{VcK|7Y3xHYM>6%at4#5@*|k8;If>6;kdz>+n)<am^?+kX4kcw50Cnmw
zK4|g%_Y&5kKr(m_xA%*m&kTvRIsCv$9gIP)|6esPdbYQkm-2VHVmiDWefb7)*d>l<
zx}1iUM48M53^)%dh)CQ0Ql2GUr?wHa#d(aI<lA2pFB47i&*Az5BECLfG#lDK`fbYD
zEU8=VJbEI&HlEYfXOn+DZm}yK8Z?EH*2##c;~!xFO3;hImh74rnOY>68RiV&P|U)W
zQ0GNg+nconN|sWZ$Nz9q*8p7+!cvx*2w<)%`ah~!A+X>0XR)2M3dxR*P-PkF4Y>;Y
zCDJKv8BAuWjlo;cG`O(nmu&Xr?X)sWbBnP%#d<S;&=;x_2Uw+hW60M&UeIG+T~6I^
zd|&C;c3)LW?^<|}iXGDSpr}nmTOn<ZK5#A>@zWbq*30NwOyXfIk=gF`*XLPpVXtPf
z4cs|8_`?>JAABW*a;z)=vfB}tuh5TA7E9t%p!}0;dz1_EQ)7X47uUEGcs?`i!72M*
z#lg2|s3GQK1UD`@@7{gpt4du^-SVbf=S;M$hA{L>rNq}ZA;t~F+xRhBu~?WM1}>b!
z(^4-kr{;4-i1uuYJ*woDI^YM^{BS$9g?BGY0Xg4Y^R`x!@N1kd%@ep%D37ufY3I#@
z|L`}v>+noy3h-aKA%f7HGeV4`M(aIGVcrTrrIyA&Ch*d;Mr;onQp8S_(0zVsh=Zm;
z-V7cHK6NhoJV1BTuc@A|M^QAHEWKU>N!Ym9X2~8@A$K6jyoy3;BMp6uZk*nzM-9oQ
zs%rY<C|x{(;cM25)h9Nd<X!p7>d@iQPi(9vDQ>4=4$OG!%j6fv)E<LV!HSX@B|b)r
z?w`7%t5%5GO;0^2?M#6SSU0yw^Q+=GSR<sKv$MN@^E1UyKT+f*`p+mnd6;-Iqh#=T
zV|QAU93RYHXIkBJAT49S(gb#YCx)g!*EKVspY|~j)wYWDvb1o+O-A-#@f=184}QD6
z!zTI~peh<!9(Zv_qsLaM&b}=V%?h-zL<_mGa$SPpY{x`ox-!u_VnXLWm@Z+=*{q4u
z9b^W=Z5PHE^4IQj4<<!ny*>y%^m|e3$B3TjV48>|81h6aqhR^xT-5#9D`LTyAKMYR
z=?N<oXNE@T;FEaK!I_M9BoJ3iR$(12-c8R}`5y+7xa3|3Yn*=QiBcv<5gKP7r2m{S
zwr*yrxlUbGXG)0xCjLfnA#m3?p?$4Qoz9qu*YK;Lz-QN=Pct^1wlcGRUK~EIC!LRI
z@vu>k>o?JAJ?Hz{f_DOr$ebWo4vd!~rPXOVs4*plrL1cvj7O%aNWt3+o%&^+>x}vj
zWro^GLqr6meeQaXA?$-uQn<8^eXNz+JIWE@(^Ax>9l2umWgYkjCGY(93amY?I<=Ka
z4~E*GLj_pr<S^t6X@m4OjD?&qsoKOX%K719C+ul$%$Ub$v1&jg*G9|5|5Zsu_Oo&?
za)2Ifw(rzQ#zpzj=a|p=jFAuPNK7upX|eHcV!~jBckJnm#r7p!*zb>@NkUNM(>pI-
z;zGrGo{MWrQQ*7s{Y+Z#Hp3>%1+r`jnb7=lpcRUj%Iqqy92Jt2WN%IFjjEk}1e4)y
z$-aTA25d0z<v)J~VFW*PVqo~X_*TT%$%j}i@q)<!Ae&gD+%%f}4@HIA$!(-~$$h<_
z?>7bR>Fww<J)IaXP8WxXY!4{Qo9$m;p5^J$)-lCg2Il1_HAA8k^oZ7^sAtH^NyCs+
zC5He(;24k`kW|r7lb<ESKUXpYk|BAJzaLyh$<qI6f?ST7ia<CwIWXArCEHi=DQ!L(
zXkV+s9VWM-6~gKYbaa(?dslb9D6P&81a6=Nisv@|UWjB9Ty@=w97>zju+mlCmM;$T
z2tvCJPv?!Q?R)_|SUEGkLLXD4s}=Z!C=ho0D>@o-n5V(7;*IlQ(%+K>ZEPi+(8!7M
zj<9*w<wMZZG*2OXVt&TT?=sRKE2K_eD)n$g61bJ$`<UN?*8Hzx1%hd2Qj%v)*YERh
zyUsGt*Obvb+Nj$ZpRx^SVPFIZ?LNS_GwPC&WCl0j{!y6N92j#R`=J0rVS`EW{@)4O
zBlvTG{*xRl#kIgW?T*ma-t_*|!=&RINXs3VOyjth;Bp9b0w60ym8^uMZeS4?on-8U
z^`fR`7fg(%Urx6&fw<p6=P2B*Z2o$clGIxOmDGDYwWgbtxt`ftk3d>173<NLWN}U;
zjX&sIC%UNb7(uG{lD`0i36R!DKhU}fx^E}dpy`8?8z}^u?bH?2Z>VquhN5g?<D>Y%
zui@PFtFCg586#Z=YnG^*C;Un7<3|$oQ-!kbP4V<U3N-&J@&^%?9G5-;IH0lwTeL!L
zCdgrau-jOLr8e$F*{~&~EMT(iU@zE!^lS)U$4AOGmOKBSWFNRb4Ff8o(Ud?`AiE<Q
zv-uKEJK%RS%SlE<Yik;a<8!iHWM>?{a9Xn*-uckX%zk;p2_V`<%CmO$!X7G7M{4(R
zus7YIW)2EDS_L^2Fpv?Mse}6u3a|jyMo&O2Gqm7i?uc<EaJ643uQN+PeV@hdeQI%e
zuT;$Z=7V;^P?#2uLd}I+>=M-M8=|Bt@<K~ai}%%eSH*xG0T9b!;l!@GN>~lLwr^GG
zU;aTqSMAdG?S8v`pv)B#f}C%A3H5T|?*j1A)bdnOq<C4d;HD0T5-BK97F8@B11eOy
zr`;#kwW{r)gEswq*XooLPo{COg~m)tddv_8w!eE3#4oZIUJH<*qIwv!p)nVGMveq5
zI)k|?3#~R8Z&jd%nnVTEG4WgB2~K_6X!W0mO`d-+OsXEGnP>Y_wW-*yz`l)?a{+M)
z;iZoH-4f3)!m5dPJ!#1@nnbCD=ru9!)+6y<UudZeC3sAWq@|sO-g|~eP$)yTBvw_4
z>Qrxx>kjFwHddhZJ*?w^{ZjQ{XA@YCQU0X8I$zo7X#k1l8(^aPC$N>6k6v5ZF*(QO
z8f0c$JiolD^qnv{Sgj_|kYTlyo&-fKwg+!5N{bl-TRbJju_BT^H9#Vnz{tLO9`@f_
z*HGQmbl;Cvj>AyLR%LBvw3E#c4?oR?Ni3FPw(u3~7#FX_zz7o(K*eG;cu1oZvnT_?
z<jERzZ%_W9s2Wq|#*ShS1ePeAd7ucDA569!&J}A@KHXoiM$CM~-=a%;xY36J6h6l-
zm`ml#13p&zcNm%%mj>*m1Z1|qBmaSf_;`QFnrzX7^%tP3Mp})Yc(B+VG(|B_H_-Nk
zkPU<A#kn`26li=|`Uer;i1Jt>P8iX9r6;0|!FR&%LPciAC~BYA;~M7ZfJp&KOJit(
zr3vTjRNb0fF*gxdi{?XVF);F<{-Bmrp$n(Y32LKC+Jp5I$%qB?=-&_igJv{*JDqH8
zY?j0)dw7kE@n8YOeQTB6rAij4U4MM}ZJ=dkF)1F5)Ahb9q84}KwsgVxOqa!i0}KDa
zR*V+%rEWczoRI*YOk5_tJAxM#1|+C2;b<=Ph>|MrtJ~it9>LoZ-;}clMUoyM42D5{
zVfc-fVR0z=19Isb-n`4yHAdtxS2UsXCz6BkLG|@(!-5rYg6wijwoR+FFT5$Il{14+
zp4K*E{CiA%o$&D!nnF%<(tl>d#=QHe)PG#$PY^$1OaBFria!_xm0*Wuy<iKL<~eW>
z0{x$80I3dS7|<bwoFEY7PtZdHm)V>N6J_C7hb};u4&&p(uL;ArBw^(xZa<inlvcxj
zBt7)x8IUNc)qk{xx1ug1Lituf`6hwBN|7-AJ>iv0k*q|FZ)0ptfsr9-L(pSIxp6#t
z*tz|#Jt2VHO|<>3)R2REF{E>l+D4SvAFd>?uVJ%B5pSwsHKK`yk@FPB+2Cw76|G6^
z1XHU46}tE$hA42vEKqnQVV9zmWhf~;koxLE1p#nZ4Eb};kg29bX{jvE7851S`Zmr-
z3q9l$d%E2;l+Vxjd5Zt5xK@r*Do-_ku$pEKl;&zjIfDgZ4He8$wBfh6`gehz>e00S
zDHr78c#!1)ioUJ8mEj<%kmN1y53QI17zPA=#^CGnjV+k0P~(5M2`)*M^sshuG6-j5
zCg9cvjS9j2y&f86YB5b+Jnx!r9PdbZh1OT^r$IZo8-W*9g)->YNypQgfrIo#scu``
z+i9gk#B<$0{uwno#+~dxzBQEmA64+*nn?bspW`2TP5x=Oe>JFZor6L~Zo<JK40~l3
zZBresPX-z{W)emjMW<|PCLvJBTaHD98RM3u-C&jE`>`WipgMPZx6@hANfPK?duU@O
zC~cIT#DUEo1;e~sb6)z<09At1D6>{^S8PAB+FqSfB^WA;v#wd8yp)&ZT=-dN;WYd_
zoNABpdhe&_;N{^L|L=`nP-0{K48G4{%k(!R0fRP}g3<<ClZxw-+gv2mDMVv$?`EUS
z(@dv29=#gJo;y?IQ`Do~mcB2m1#M(Y>DSYdpv>`Tmgc`RN8p?v@@6~#<u#$d>lU%6
znbp@KaVtzif?ka=fVc&fzQgsOuVag*weVeFj3it@JO(kn+^U2LVK;%X^nP)IN)vTS
ztgYz6OyT6$X1i)Vvw|w}ou`CdrX%0o?0@x7@I@!g7OA#`It{@CAMjPoX7VpYZ(W!0
z%zm3Jsf#~KTUMHrb{B=w*msFHFvzFB=krCDfT(j4lNiX9?<5v1n?B`l!Gf|1RQg^s
zg_N0Kj<Pq93zt*eFqRfvrfxZNIj!t^b_hHu?JqH!e_xT?5~A8^=@4(g@IN8`BuryB
z5Atz)P-g*IDw;dfa8_5L+|n)p()YhQ5X|E#6w0N??#coZP!5_y4MJIQC`wy2asNAJ
zY@H<h?}QRD`T31oxII&WQn4qmsZSg%p0+#>Y^m)z+>c=p*H@x;RPF8_spv7Uj4+c~
zFV36g?zsL&;G8_8c63FT4IJS7TUP^1lFmY$y>~UcR0erYfHjIrMZ-f86vO{QY^=PO
z!0XV6WwdF7pwoZRJq(<ys~j%620XEn1}U$~J4ARb?wWtC>O;L2{myG-;WX~z2KI8K
ztz(-plQ4qLAT}25vRnFyL&;sjp^)cf691g`;b}_`hZc^u*~%J?2GgE7Tcax{orV&_
zKjGF0vMKIuHb{UlDN8fDOqf3g9E})(xTE&Uw@Jh!>PXIlGht=VB@>Exp&3ds=Wm!k
z@q?EipIbcd-x&LNn}TChdZ0FylGu!5A@N%t*!9h0q|r@=xs3&LgQ2N7R}dtYwg?ed
znLz-5Zxc&Z$F}~Cp!eA%s2#xRMEiBIMQcfGOkdgCr)#m_kU+z>9CW@y<2exeJ8Ye;
z&mau!u56H1*EqthO&?Zqa)|z~j)G|Oqv$uDfuFI-c&T}=xq-Gajd<tD*rBMgXSS~k
z=a0>aPUTX#9vHs7(Xbl32$Z0>)T8kp2w=pzfJ(^~LoF5>sg%2lQ(lZ6fO_Pk03z}A
z=ls%-N-^NnI{R^G7r;HaE|aW|dyU)2V3tnbTBo5UzOXc+eX^&zpqHzOc`!=RVLlVT
zN?r=j3Y`eo@R=*iK03eDVd}+&>u7!OyI0wcZsHH;hmEP9Ec^>)h}3X?GcXMortnrL
zl4FfE@OdU$*czNWzr~5O4rUVa-9Q>C2v||^n?urLLEmie4UuQwWvM_zt8?q!#X<~p
zp(vg2g_KY-HZNk@T_Ma*HKC#k1lmR-(%5{J_!FmCx8gQ1rq46M0p*Qbf*wI44$8Bg
zdcIxXq>h@864q#!HY3(&r3Jy<vQy|Q0lLOnM$)In=0_S69rR6F2ykKSsk5!?)<?(y
zFXtvfIJhNug^OSL@t3J1g~)G2#SV|tWw@JZfqj4Lx^{(`70xgfj`}cS@*GOgTW<!l
z?ToG{i9X=RfNNcElH?b#?pp&Dgx*-qC9$jei^#I;e92Pj$FjCHtcX)3^^o415*7`O
zo=+4+Q))YwP)Si9eajT~+k&GU$82~jfma_a4G{azjfXmDh)*N~qdI*_GkPtd+W$F$
zOps>!R{*&qah4Jtnh*CMqVW3T<Zy9nF_SLiK@s6laqNPCkbPTLWBBZwe!L+3Pb|WO
z4eyKmqmjmRZ&VKjlQ<0NZ>0dkM%~GH1QXv-R0c#a-QA-E9BdX&r`Atz+(n-k>`!HU
z2nfi}(SAw(7;{wv*$Hy_6-k9Qv<ZOdMVaK%Sw#vZbrsem=_+aBnXN(2#@S2;Aje6Q
zpZBG9BY;pvy&#Mixy1PUH@#d*(3<+u)F(%)$+CSYT$j6|o0#Z4xRFh_9+H3FitEc$
zO^<ey0*SLRuHjYNap;{&T~kSa%y=f0{haMW`KYlQNz~5!(Kr$*l<&Nt?q;)++Psz`
z$sjo!Yv4LamVNt@{pqN;Ydta#x$?HRl!h`JH+q3~>2oB<pBHLHA8DqgCG1e!3OhtL
zsW5o|CRy{ut(^WMS>2GN<mesB^~~wv=<716;WenYI@E$2TtA;+Gp7+u=RV~%XImh|
z7tWZiotx)LOr?gNouh$b#(Wla2?=tmz<36uZ4QYP$PIhKe1hG0sNdv4f6VQqr3u6S
zUjAhlR8vgLRdX>%Q1x{xNn*>5q9rYL<B|@NGw1AXdz$Baevl$A=6OknYK)9>oWUOi
zTghGfJFd=W>;sZy9;3?zQ};!10(ew&%{qgG=>%jBtu@yAc<?IOg2~Z+C_5(M+Jg9S
zfnX4zddl_g18ms2dhPrSN|b-2yCYXn8J?Cssp9_O2JjfOTNT(RGdlsAyi?AwnMPc%
zu)2AdY)+QqVuv2X_?UgFo;0!k^!OSFtoUw)iXQ{?`wiymNRY|J&krdZg?kvg<~pX_
z^A0o9ELEU1lj$IRvau~WAQ^Rdm|w))@W;gAnWADYC9Tr+zNAwSD6CvLcWU{oU~aPv
z<5-<fmLv6=`!1kU2omZ=_Ov1;Tw%0((Kqa6o_RyL`r>J{0pbP)69@;cITxJuI!R84
zfk2FPUA-)^+7}C>fF8g;e4y<Y^YwCYy5A~-8wI1fY{`4M?oWmjlnO`hyi86Q&yI61
z&&Q>?)@*h;l_aG>i&7q|G9RX)I>Grt0pa}0m=hrEu%;2xH5qZP{s3iZLyQ=)+gkh4
zax_bq;7i^q-@Fh_nmU%+wWU)|moS}r5zW7|#wtYCz;9uM=ejTgl3c2bs_@rqWNXHM
zSKbo9VEHg-5fNda_ncszv?w)Un}@rOT97a(vh4SdUK{zE_k^-hi)iK`R`N!j6ML{G
zILEQ+45qbW3u=TN_4^YXhZeS*)5*ocM07?%b<$kKEZ<;<5q{9ZqDL{0BT*<JWRvRs
zT5C#&0l<I{1pR{vQwD8Mp4+=>KfciETPvff+Lfl3CZf6IbG(x5PUt{f+!2*g8rwEU
zg0pj1(9ihc*`$a(mv6$U4d<{!vo`J)6Q(S)+6S!5V`MgqQs!g(gQa|`@lhbeLYk53
zu(n^tER81ouQ>IEK+x2$bh47=i$Fzz`gU{oG)ifSd*q{w2&m78*QV&U1(o6Mr5BG!
zDW?oY!Y1O>XqeJFNp;E7=@>H)3%CD)Vz9@Q7qNj(y75#xpj($TTtwY9HCu}q;{yCk
z)+l?~-4=IwG*ZaG_49W9l-eeTGn2{|GTXv&ZHpEc>tZAv>T}A>8>8)nm^d~ZXh5_T
z1FXXZP8x<Xm(^e+XzcHlV*!4vAn=tBm_}Drs?hZ2cxdWHF$II}*{{~`4Qn4(V4H-k
z#8YI;!X-__G*s}}Nf8<na0!V{rn~YJC&!5XC$Oyv9U(+O-Z^~;X`@NS&7(p>qL?XX
zz4~uQqM)4H{qMlh32i-<iTzLi@*-OZ3qXKyYI+7r^}SD0t+A8~k<;h7KQ!E40VW$q
z<$ewJ^<xhyPZ0}6PA!SG7X^KZV6tFY`f<i!{M-8GOUm6ERg8CtLe4T&{r_eGu0YP_
zvAR*`zaVU^Z`EJY3SU<&4R&0HFk%nhB!PU1WNG9BA|ImYoJPK<Do{zdsG8ttKp{|5
zg8f38ZRB^1StJ{ZBE?L=n6nN?F3Rb9dA4JupKHdvt!)CMq#&+$_>G`Wcj!nUaI~(A
zB-}%JcdjVt&=i?P3~kQ?YW%mh7WsqFaJ~4yA~*2Rr5_Ods^fll*9(LcIM~mjOu<F@
z>`j__;Vc(d^yC|8%GN4?^sKFupk%sory3!N->yxVGVh{2O_}LEdq6dsQ(!3<cqMvj
zimNxn)1_;~tU}}M*9RB#;2iyYi}b3MfbP}?+4~kIRJL6I>P=~a_yujt`Q!!dW)!wQ
zj1`|Rzi#k7b}}){x7;#?kJO^x4mSiH-v4r6BfW4Mhc148ff|HdzTgHRTy@2irwD=X
zc0Ho}1d2j&^e_8R|3oIPn+A+=#;yYHv^n4iA?c@t6<dmwU@puh$i_bo6&N@ZefJ!Z
zq{&QM=~vZ^WNBok(iAN-5Veq($Ab!OE~;pd*D_qZ_8zc-y0*3)|AIshLx@Pf@cZC0
z4^08qJttiz2VN1cEJAc&=g6<>vIp(ulYS}5bE&%sMMf@%iuq6GdC_d3!ENo~dBO}Q
zCR`~z`9c!;KqB@uL#d7=&Adhy_kRM$Rwx9!pA|M_|D)j;4Bq!200o|R!T-fZ>l{S8
zA}=KCMC>pDBo9kwc68lD%<|f7UwM50!X;A@74gr6`u_lzH<utE{|FIOEO;ubyGUOL
zN#~0JOQnsQ!W_5ug}hLsg&`ufFNU@-BwABlM-s$aaHTpA!&f&yPlKAE<wfCENXm2_
zfG=Ol|I<O~O-d)C!V3&N9(dM8N^wRpe_;HZS*bmUow{Gi9WWZ@IjR`A4*r-aidn#=
zd88gQ+cpb994i#D;<IuDH(I4WRY|F!Q1`@W(>hdnEw6Dct-vMWTo$)0#WHDHswJwp
ztzC#`Q?`1bYD)K|?MMeHuln0yH}2w!^VnD0)0Id0@9KF@pj7+Yzd>btKy+AXR7t4u
zT8dO3N%dy`^mHgi2@5CSOC()`YeA}7wRw^wUaa<Ov$>K5CWLK869?wzg9-YvIY}~#
zNb^h6anT|dWc!)cM;yvpo>J(qHw=|Mr2+Ac$*uo`pFn_clS3$)Eko@upw9LEWPo-e
zI=x!gQh;k~;+*J=u{3x-M`Gl-q*4({m>puGwB2ICf~b+@%Cdf2x*)Tl`CoiQ&FS--
z4Vc=HwO{02$ZaydDLcpM%rYccCpX*tr)0LI?ep4=j5W-6mmsL=3+`Xtr1FpyNOO(K
zIoE&E8)O~?f6&!8UD_6wv>di+C!25G$vap)Xk-(d2<KEY4Gbx)Z>tt9;57d5eD^Rt
zGT^z<14m*Cd;hj<VOo+YIrFz94_lE~rc~&_+mrZV!lVufN5_QfZ&(9PCQrEFs9pvb
zNG{;vYHDYsRfmJk{|#i&B;QAhTCJ>thXA0ZvKTqB)@VOe8167XG5o?(EEN(ysfA@~
z2Uyp6Id4ZaHOdksIh8M$ea&mOKB1+`VXlm1mvBCR<E789M&AF~Z5;MPP~Z<zJAt^g
zD{?Cj;k!l>PVowrg}#pMWqi~_)xQ9S>sZp)E0&{1PM4>2*?T_u&Dg0Ri)-z$k{3`I
z4Y{}UCn_FU#W1nrzrwRXpitz3wW(I*u)~}f>VQ=WyFxj$H8R7A3kRgKK3UMJb_U@Y
z`nyj-f=CH1450&c(zhpg?~Plre*C4Ac2GHTQL^!{U~6W;GE2UAO%`?XADn}!iyYD0
z!y2eAZ|+hA0AvWA?GN9XM&mnOmdLLxe$EaFpw;Ou9xG`0qucjk;#i$ss-?WlYEiyT
zO?%y_o$nn3s7Yf>oyASD4h!=_vg~4&-DQNdatA^zL`E9F4ECCpHQ5rlkHW4zj31|x
zQ}t`6<cv)A$Qn|@u`GO7-cCAODa&KW<B7>2D?zb#T*qK5!dp<ICxeb=bvd#Wrtr-j
zlxd=dfZV|YP{v70F48E{+<XRKU?+NP?{_&i(s#}jf$ml8y2g@lXFg#}Owg0TGW|oo
zN#VUXeCo`cZ<8_5{_RR&rWz=>$-y<Hw3sQ~7IjneYD@7DM01rPD!mNf3x8_D%9u^U
zK+219Uk-56mDD5H$k~{XtEZT5yVvXn`wOcO!7X$~hbvqnnKosrw6A@S$2+51z?$P6
zXLf|%l$mzM%`3K0mSNquh?6v{Li8)zK=u0k3`7}t<`lokBJP(B$IkX%CF^;8W+nM_
z33fJ;%zXbl{*w~}kW=L+R^c#=6G~2A_}*4%!idu!jj@LrX@67whe<AwR$Qznm~EW+
z##he7e$!bp{;>hY0?!)y)oOwYti#SGu4eyFb6*)2$F^;Yli<Of5G+7&f=dYQ?%ojG
z9U6C+;1DdhySqbhcXxMf<aM&oxp$v)-o4-Z`F{3SRozu{tzI?89AnNkvAfFC{N+Rn
zJdGqoj*_qM-xlJ18z5Py-U7U~YL6+$Qnnfx**?iKvdqwfljk#Qg#{9-Z4qnPEHgwB
zB0z`!SU0BLFVieGCi;8HCUqlELNe2X(+TpK-FHMa6DJ(m+X@O^s5W_J(Uvl~Ooj@;
z_z?#lyOe@|^BvTRp8ef$txe&RGeBkeT-bo+`b>dc+W<d2<6>f)Kag5`tPX3IpE6~_
z8x_o3oh&dmvnZbsZY5vWEH?i`u(RWJZS?`Z-ZtI&g;r84q>qa&x<@Dl$_a7Re?Tk5
zFtXv%Uk6c2H1o`VS$tnRScjtSohv)Ju~d<$o!R#hNDEX2d^ukE6w(Fa&ZeA2UsJ?l
z`(OhF7E!~zbq;7FK!s^$j=vc+4!jcKm%7A+nz&&Q^n1@!dhGWUv6EMLC_(cccMmsw
zXMD|PzM#kZePJ6(vBzu-?Ws|BoKaW5WNmkMH_u69-j%ckE32dPNYH)lTN_eOOMum~
zvDMMQann3E(cK+cErb>IsWXj(QC7)>?Zn%hgdE`+qdI@cnYLhoF1CPOlb$`edjI?D
z<({AG8&zK`B@ZL(9EYREKAb|=_lWXNt;Q4O22=%TI{0dSrHR&ZF<tJ@mg(;I2)OGs
zj-XM#O9JYlYvlkwD2IpqaQQX&!LogRq;<iH;Eq1^<kk$B&zRwC#u=d^4sAB5#u+r!
zZE}{JF&tT?G;n}Cki@jYd%_y44lO*!c`Q;}4Ll6*FPDO4!(%Hv*e9;pRxAJ>hf`%r
z(dFT(OnI8xfGSm*g_knYxwbB;IlWS5SZic!t-Z`MP6$qJV5X}(x%9LR4xH47Ziq=Z
z=Z>yvD%>9ku;0p4<Y9ZpF={SDl>AipG|XACAR#2Q8#{#ZL5?rW1!7u(-Kzs{g*W<B
zroTm<SXer2PU5M4i3!b74oqk}RnFH0XI4nKMMT|rAx9kaV)YfdMAr&JZi1TJpjlLj
z0)oQTrUeNMFl4O9U|Su)aS#`V-^npYNxn@Ss6SkIug6XR8!PzJ8R1G@sx4<{gjHim
zv^W#;v!TVshH_Lu*NKNyD~5qF+%BfOp|*jUvwA;wq$CM_nTM{Op1C>gl`2=-Drh&5
z!^gU(&&QD%DN{chl#yZ3AF18!L{}XKd;JZycGe{al45+|jTm&MekS$=!A>W1W4Yej
zP#VshWjlfDUL>@u)=eEI_Bodv*N=Ft%x|t35qNVFFhajaDHqamvSpX~_+Y=WXRN|<
zkGsc(pXFpkazIjh58LB{n>;D#@?IfRtVHyEw(~ZJS{gRqEsm#Fl2asn;~e=KCdDjw
zqkBSRMdl8==>td9tXVhh?AFe$>St_(`YUq`6N{*ePw*zV6@%x4^k=ojij$KtwP%QN
z5<4$tPM3q>Bw+an6=(BjC%BYp$otNsI6;J#bU>0p`<SH{zm$#f)Axykiyg<I^<eGS
zf=5lA6BOR2v?ZwrX&!9jN<|+SHOGEK**_Nr8eAV&P~}`Q(0C(9s85~lvs6VX!w@e3
zxer|VeO(OST<Li~4RM&%paZHQzE}WPm2V2TLAWD^=wMAHif(5na<-lf>;)k9C|LY0
zvnc)5(yQpNmR_~L54|b+)A>tarYw$T4$=j;$k}SLe}7u%O&;ML#i9~HYfAP=xeqEo
zz2DBnz~IW|CKF+n(g~kakv6<u{`o{`5lHrdBv27Hfd>i`PC62VZdoK9vZxTOd!@~@
zh5vYYtP^FS-*@_+#W{WEJ9(#QM?j~j_x38kHqW{V8fu8g?QX?PP_Y$YV9H)!M59*w
zlDDOKM=6UU3L-#2b45K^g+v13#tE3(r&D`)`-sSoaAio9+;~-jUEEg~O|>5()BqO=
zA12*OV_IiEU3c}hxaur^suwy8PT<aoxvZu$z~}o7xgso1c=AoQs}J=XdYE%zyB@35
zhI6}5kn}Ko^jVAkatn^;xb6*I!sbpIpLFW7mk|Xd{Zrn)pZvr^)-T!_AgNt!gQ0F2
z9f1515r6vutK1^%69c($yu^A(0H8x%yGOyqDG&Z(le~nt0)hlfhJaeQcR}q3m9PM|
zMN}1M(@9iS<Vf;}r7^Rreja<<I^OwbAy64%T9ZY)-2w*-)<J`vkqXfTkf!+)e!Wed
zple7a;rB<i!2p_{q|W<T#5xD8!aV7BP7n<PJ;(PFpK`~mnfk@3itC}*w|vI$kL|w3
zZyqTP2P$VUqeSLqI%haUxb>@9It2jeiEW)4M08s701t+G180&w4RFZSrzT@s+RVLE
zIBhq`*BO^!FSlltij?E4_*}rr9C(8J^j03oDL{7=$f$t`OIGFixMF=s+Zl+qFh!IX
zXPsHw1qTo-0?{RVQsRr=S?}_E=HZxRJ5ZOg3q@3oSfUgc&JKKEO)U?N;78fNE_Lp)
zH8c^YFk)4+5U&Aj45(^}#-w;pinq7i`m*dW8&FK?9R&hCzc~0Rn$0_aOe2aMS;?~M
zI-uN{*RMzOINL^ZWYmJV@k;3k(3ymFiHQk0Ik_9rC8-@ON<4C6XO<){a~KDFPlmWZ
z+{uqtLS$&zjky`Tl`&N+U4lOu^*no+%Sm9yB}POUZ8wwKA=6{2L`>;CXdKwl!VYfu
z)Hfco5i_yXHW;raQ3zmLB!p@t-OZE2*%lUD9jE2~F*m<LrJcQMUji=aL7vEBIgPPy
z$@}RX#J4*$$~kfbuB*h__1N(5=jAehU%wSnEHx+<t(AZa!Q`<=bgJ*SeUXrwL)X!%
zvd9ST9+C{9tPT}sW?lL`k}6_s!NvA{y*V&2FV3^Juz;DfOiPW|b=Y&qH!wy)n?rNc
zN!liodP$xR6((UT>*4`X@mpej)&jVI%I(xwIv^f~f7^B!73bn-4|=5$MJRa+UH-;}
z{i8h#9Sua)PkF)UG{K*6Z)BLnL7&&f_eG2>@F^3zyoXrwe#~fag`F1exRR1e$U&Lg
zag=G<r12!Aj%sM85T6$g@6pfCNRbaZH!dg6o7NWQ?{@Sh<^|#4A198|s>AqRR2X|+
zSC#tyL`E91!qox?;Hj;me~UP+GI3j6KN@x^(YdE+oG^2~@**H)gEI*nqR$xNIge@3
zbL_N8tBwIO)u(>H<T<PtioQva^@Ubq8GOTl-a2ZE!85NDTrv1%TAC{gkg)&kRZcww
z%Q+FveeI8;Yh4$Z;8(gdL*Ig~F{fELEnn+bo6lQa5wfb!!`mK{rq<4w<OR<YmVlyo
zcEAL$$ENAmDIT_EVI<2~V^JFck@Q2e<~HIMR}BK2xBJ%7?KwSWb4t$Wb9k3(HDVFH
zp{vJLs!D=BL<e9>q||T6vZXCE8}vgvEZj_2wBK<qv<8PFA^0<`$Nc++<ARlRO%f3q
zR<k!%QrzG0mnSDy3;(o3YF=tt^_kc-qnbi|D-S@I>b=NFMdf-N<;2H>$P*D+adung
zcJ~B@YYFO6?fK<{`ZQ)B^k~EgOoi*xrzjTG(klbv>Jy{ZE4QwOZrki{Mc}-9bL`5U
zwK5#UhdB9MtU3-3#?vNKKbOdi6-4McetGGkKdHj)C317Kvs-V;6^+#W-0+_2`((0~
zXTyjSGY9+l;lM4>#<bUpBy&?}>_l(EII&0$C)^CIUGSj6lR%QpR>cfcXcRBh5K8(<
z8d1LKn&T`Ugm_OVxpX6LlQkSAoq;5ZQCmnaw6Of{)*%<WDf*g841xZhps~$rc2AX)
zji3gr^`pLOO7gX9D|5EIW%Rd2>M6Zc`9u(?K!+eQo_>L}UA9+fFb*v;7ZEs8VjYf&
zt0<^PR#_vT$Qw$nM%DEFL#+c_0-t+Pl}E2Zc1TTQ#{ye**3Tc+lrsl~SN3_yEMbu>
z^q%{1&KtQbS_8>I5sH&4lLzWUIY)9*XU;@?t!Ruv3BmGfo8nwsiowgm+G8Q0Z+!}W
zA;&~(+5jdWPJ|5bYq6LO(%9S%@!8>wR9YS<zRs-X@x*vlQ*Y5XNIeW2=Lh>lU7m`{
z1+DBuC=pSj(}e`bv!9ei73@K!9x5VB8k0uQa+R*)hraE-VBfTb@(9AruLzNNfdun>
z9&mr8T!6d|$Ie}0(#K?UHj0Qs(u!1XiI4R(AB*hPj|~A*=kp_*QnSCn1wRFPm4zIs
z)SamSLTs`hbKJnlE7rP5B?tBJO~EAT1<#pXsOD-ZdVVcfR!xfyy$(bE)bKz@QA^e^
z@fjJ+j48b7sG0^OQFTTnT$^GlStHTJnI<%MW$Q`?SRBjQwi7bU$mA<MC(gp_PeyL|
zTWJxrgTz*3JGN=~$)<GX%J6)!l)%&hdvQ*k0f)Lkqs!l8R?L)X2TYe_E^z~$VPYcJ
zx{^{$<oP!N-im*zjO~DOTvyOj=9a6WwNWOKj~)~oyhotGfh>l{#U5uFFV?HB&==fm
zRO~m_5H)jZtPzw~4M?47s;Hid**_^9IV3P+Sy+0;*sANKRZ2FYRKz?pd(>(!Qw&qV
z0#}p9Jb6KCMx|gU8WdJoGyPyry-tommKKq=nCJn3f>@ZEWA@$SAlC*uvI4ZnU@)Lm
zlO-ZZiM2;P!ULe~evbt5$hK(q;`<@?FESt(@}yU8{OJQtv#YOP<D}jqa~Z_=i&Y31
z&x`BDa~TLooUfD3&@8G)4Cz=?WY4rR2~CVEB@M=`yH~0~nx3u>8aA*ZUu%8r+&66e
zbSV@29Yy&toOz{Wy$hOyC}b?MsEkEgf9-xVa5X1ale@?X{i9}sFjWIZ4%A>kVxI@k
zA*=f`d`ITDiE&oGgBjeB#)l7@z@WLUt!$i5I?{tE83$?Z0CerFt)CcTbb~dUfHQ~X
zwWw*RhTMj=!tvyxB|^)iB$5o_Wq7NQD7U;;TDz8yRYE_LTaw~*RDXs4o^ICOKW^<;
z^=7;7ub*<p%$%q90~)|{ZrGA&)t0244U)d6TzWVH1peHGb9@P-!QHe+<q-^u)(C|U
zTz-Br!<zX~i7+w|JeKyhcew|kY%uzVz8KljY+u8L8Xfzu830IZxS<OJ5~HvE5J_u0
z0@7l;V`oqGIqAb%2`J{W-17uworfG07X#pJxzPO}hn<!hoEI$W71e(x4<n8E{?Eh$
zLdr<gW_4}OatM_xdvSr+v2RN?4=NQYb=tuJRpVDY(cd@@(@en9LfeFn>=#~w66o2_
z308@<T1Lj^*%*nV4N##<<fY6t*N){}E8yj)Mrd(?@cT%pdkkKLnct@+2)s14xu3_x
zoLg@{Duxk+OB~=<<IPY64PAq0MUH<<=Lxo@m)l|ZQ2zFlsmjzi-;9+!;%>fF>|%u3
z-s5~SWVvq?`E<glzIkn^9Z4^XN`nVzeLWheg7e0rz=3Wh+Xm>rh)A+zJjc!CWTYq4
zDLVT(&neNdWy_^(f(9mC4rLL4<rl5-uCJMOL*!mZ#Sx8PS+@1`&+i*m`_1xkD+b9Z
z(kvx;&y$(rbW_r%I6@!BKe>t&S?yza*8Ih<3P16_N3j5RH-3@Gp8~Eeqp4oQ9(6_8
z>ZL*d=^3N&B|Inw(wiJ@OV3cU-3T3i))ibg>mwm#5C@Nniz`1vvBbg*X@XnOOEk!8
zu9pehrFGl9HL0`xDaJ~rNVq^fWaQ63e+Tz{J_ZZvFSR7sZL$P(tk!5W3eqedfH}{k
zH@XQXyNIVAq>#(`S5q=k`3=#|@OYE<KC%(P!OR!|muB`I!l82M%u3$AYQjwY4$5w-
z=9alK8FBv)f(T;g>#mGQ`2K+*nM3Y0c7XTii^F2#TYr(fQh?Q)Ch8O4Ou`VcS;lJw
zetIeHe!pe&>x8P6lru$|J7+LC0YsfoO5%W|Dn*Ksk-`ie+}vGPm^lD*{O=t->*0-3
zS8{MloIqW$@(pM>$WF-cns6<~nzeBnzgf<_BnBOIIPh!H{7<O)@ubfv1{pCPHf!a<
z=L?{mDziDSlf?j!4PTQ9UZyyRVy7ByJ67g6wLe#y+x%uyIybgh+85MQ&zoP9;Gws5
z+rP^F;Y-1bMJpJXe=2KZg8m{>Gk>}v|HZIil>cg>Z1$&}v(m{ehE_p>HaBLQ{UEC7
zuFifyKl#Fdv~Q-_-IsSjf#&NnB7`&koi(DPhyBPBI*um+QrX@zSi>kP&8$>Z(tDt_
z)H@jE=BS976sHrp29Ly5Qf{X0g^=2SApZA;MHT$S3^Q~NSEMjrsFBpZF4M(CB%?aR
zb{oDC=IdR#stpSX$=c?<bVDlB+jAW_R(r5{at&zF>Mt~~d{FdAd>?9-?X^0R>>RO{
zwoATheSo6$H^kKvC&ST+r059f=$DKT5-;(0$Kh$&t_w$n9+c2$IBNLe1c}wvT0w+n
zE3f{2y}L_AoV&T(Ux=_pO!SS2V9#_*D!_vZfBs{`4#L8RwCJCJ?hl<YEO6iaxy--R
z{IVsVo}f70<NI|ctxkmy6Rez@HqU#z@aQzE*zHGV8JoUCp5I_I^X7c8BYG_{*cKVz
zXl0^IerXgM31TlX2wqfXRHm#)0Rb7q{H)s7$J*|5g2Mj18VF2>#!6BK`k$XYy|_B5
zKU*|C*NDt;rEISA9pK+YRxTbl4Qlah9@|8;xJ5|Ae%-1bdaE2-uE<27;_-`v1Hq|T
z-LQ+jjZm6;=2#?EyRg<cf|`&R0EhTlvY#VBKECdT2rKN%Z;oU>M~<XY8UOh<<FeE`
z^EGY_P&@BdgC}a#uL__JNRQyGGwAIP@L=F?nSYn>%r<i2Na@(cwLEBI3D9RaYtWL7
zFF>m%XSs9K2Swcb{)9OHH^SBCV5#;NtCnK>-<e6k0VzH*lcK#<0xTG*Eag%1$xVB>
zcuWH$XYlK}skt2bcrPR7lzuY&DEZ{X4F%g7!w&Z?5Wg@t#77)#6YHjQCR7gBv1((z
zlJ~SWqT9s16HgQ)7bc_B<i2oGZQfz!@s#nh$`gi#7#z2lW3|Rlt2~$&^F71IPf>WB
zp@jF|LFVviS^aFF*m)L))C_;<&@Wwv*NWh&+p}dGIXVwnLMM%Sue59bTZ;L<-K=#g
zd0ewNjWJd0pP2Y*sh6y!CC-GoSdAm-XW?w+Y_<l4pAbTNBW&~17KazbltoAEc*O8L
ztJJ3e$V6i)&f;1JY;EIE0xbt1ZVJ(PaS520D5;5`3lit6!7wZG(j>fNQHvDmk4G$~
zidrbw8n-|-+;d=axN5WM+8XWob@J}E_36BYOmeCl5&2efFa8r$r^`GGzuN-kyIZM#
zWH5QDBEq?KS<Ys;MaKdp#0`7A4TW0&ch;3ln<8FVKu4;|#>CiGMvz=-G}X<U_hVMW
zEhn4Q=&(p^O&qqaL#ccULj$GGDkHm_Hp{V9xn+6~OB0{a)j&?AAQth|$My6&cT}bJ
z$ySNUjRIWQ4#Zfn4Z1NZ)+49*K&i-m(V)r=A$oGVj35_lA2!=IK@2WC{b@YkCR4t~
zQk51tD<hhhyQ<H@8|9PU6-AKDW`89hy4E<%Metv=Vs+Z!pPVO8{V&c_p^H1*Ui3p)
zGN|zGT8;i$lWUP1+-VgN(a|||j+;?K>m&zxbmIn=Xl3tM!!YH6i>s_z1%@nIa9EEM
zpT&F-yG?9$ajK1o)_`6G(3VJ&e&@{R(qvttj0{1U%4S9shXOPzFWqwp0mpB$RZgt&
zBgD{A>RQcji6{Z8IFvYiP=%DAG;C_?dV9OWRWizfl_o_49q*uHS4z7+4QUj)hO27Q
zSCZBV<lU1QOI=6EX;1+ucyQ_9ZRxnx=4x*}tQ@u_&(AhL9kK8Y5mMj+*wtV}J==44
z<c#GDawOCp#jbx%CQ0SPi=;%*Fj5s(sZOqvzh<K9v=~5SJt82hWc605Hswr!OB|Mx
z^)I(qiG}p`frKUw_KWgH^|ph5hJYXl_`OGf`NDva{vm<mL(hzPcje?a3UFlJ{h>IC
z4)iq@<WQVFNC}0NFkw2%#I&YsupvE@BHFVWM!*fnkP1X6EzV22cbK^rr*D8w3W(Zb
zkGSN>!zjuF(gT~<a-!%5p%c*tX5zl$aBR&(W~N%=RqkeV+>jaTrFng6VWqfUolGBz
z%sfZ-z<NjXC@TJfS-*VkL~#*&E*Uiu6X)XFrg~`2=&Drj=An#c`fZ<xkzMzpO=ws}
z4-7dRF{R3ZaMsq8!YNkK?jg4@UVIIedbL_STP;?uleeWGI+=KMRWH?a<&;9W-ul^F
zKomjA2LL2L{2u0Hd{Q!%$u>dq7Mi?J@N+E7e0qoZnd{JItgZxz^ZCHLmDA#+nt5?{
zQF%aS0Fan0jW-eft>~%4>P#MT1Y45>mvLc?GFyK|o<OsZWGA>3_Z9!LsC|xL$pTku
z42pLqGTSU$RoPlX)K0N);fn@0IL`<ZV6e-Rlvcu~)o(8zIHF^Bsf8|QcxGKP8?avN
z7Un_SU{ZbijqUNrXr^aQ?>CNLzWN>Bn!K*eUPKz?G_b;grEqgTvOe-yYRY&5e$He<
z(Ob<0WLgL%5}xxUNffZEaR14BRw%F(Cg`P6r<KD42^Gx|OGb=tkZY5VPhLW7m)7G`
zf(HFYi$|QwrOWZ1ZgudlSR!tVsx)-28;H_%gg#KS00^;2QwHON1!LtgG+8U>UpAzM
zH5}0$`oM$(gc}7z;IP2pruJ_vW_9Me(MdZWyOai8JNltIU@}xl*pJIY(h`pLbD)a@
z=N%I^%D{#2_<CB<$Do=s-;a)cP@*p9F`@ciUlK4A(>_AC#rOy!HmAR(WOJ4baHx@-
z6f9&>i3~(i{I+Yqkdu7KHHCQ_!C<v7z37Y4G=3!MG_T8jFd~U!8RcV%k4J!iOV+5Q
zts*I84MJeXLq0jb{(w7(@GdqhEz?ZZU3q48<L3VFBFsY(dD0SB%NC!fC6rdMZfX+2
zUGfqab2E|#HnQ|qtWLzlkBmsgI-4*Vux<nU9g!gd<T7n~-@s69KT0r+kCBm{ajkw5
zxroHKILpM(7uJBfj81YR1ytR>|6o$Fj7IIC<p5PkF}O%^+B~o^8+rO5PO{0Dld$PS
z>fGKAnC~sGMpP2J{VGg<D+7L!i_v*&hJw-%(i*vp&7}vl+|HA)Iaaip@T;Wgg2SIW
zn7#k0$^1+f%$iG_p47dJL2{&w8N*jDI%T@+Aa4kMD!~p*|7y>=X>Z(ju-vnWBFo?#
z6BnE$bpkVDh&__J6k%q3H;osin~Y$=Y@skU!E5r)g8H^{<>!g4Y?|#u+z<W{GyKK;
zMY@Obprql*^_KSXrG%wPCa%e&w<dYeVD2)>`6wb?!aqGjkkokiMLVntxcx`qv0|jj
zH5fKhN-T(F<&gcq5Er{A8g{k3zAdsnw=^Bt1O~6}4|!j^?l!xxY6xaVZz@@!bzn)v
z3+U3iRq*t2W_1d_7U6`V;9&QH^H^?BhYNZ{6=jtU%_TdKF-r29U%xK!CWuF|cAG6S
zAg4@YWs_Q&RqL%OW2mX!SfEv;hP~8Ep5IU?hk%!x2Ulg6fnZ_Y8YZ@l>szhyp<%Pi
z{aREMltyDmpN>F@xk+Ax`uxDvxX2u#9z!!Kr!;6yP0i%?$%E@vcJ`jP?o+%dC0BZ2
zM^?O;<U!P5T;Y?a#19w%VYtP_)D1_)sL!8z5$gAS-2?B3I|qy+^dWi4ie$#u?U+aK
zaZO^dbSB;j_<b`Azg&leCd>UgeAm@I6mq@}3ATA%ICWM?nlLDl8j0(J5F*dLqm{9^
zo9g^|oQ~&f&F5gI1i9YAO4ChfqPuhYz*aDx5Te?ZW3~8)%L>aN!RVyoy+aC?sx0tC
z`gI@;!GpFy{D!$&qa^#kq#|qQ;-}S5Sv=n-J!o{f<w0>i3XSc>L;}Z(%rjQyYTW@1
zCKcu!^UUkKn&%`sf5?UhD2qYfo;-wC?F2<$?#*UaMbK`c4i}b~x3aU;EoMfhqn{tw
zBl?q-(D!-2@m3-M9;Dl89_8QMVNLI=965;}5S%XnYcM_8x+f+czgfcO#QzI{pw|j+
zc~3@Cgwu>06hx>Hxq2-tR||Y|J^@dve6D-}qJRIK{{&<m4G=k9lf$8u(l0O%ouPM{
zwYmif%CLZ$2322A^qxSlwg)*BfB_hFLL36__CF)~0ToeDTeHNevf4?0`uCYG7DYrP
za1frzTDTuI)tRbW&%2Tl8T!%JzpigVBx*`yeoWWiAQKLIb7j8Xy*}r!1Xe}@kTfw`
z_4cyYyT2&xqcPEaLs2<uNV@&$-QhnTS%Mx}o%3;H9E%+zmU7KGWE6dwf)vK~98ig6
z&-j*4Yx3YhZYWB*val<SV)+aT4pV`$=qnK73xYe0R)a%@QjAecM;s*%)cr40DKu`Q
zj8@KJ*UkC$fx(5}$@(k<gA=l}625BR4;e^E4;~@7bD8?HL?`&QCp;b38T+~`YL+Uj
znk5O?K?}g$?SUC<D5MMx0<$CHv{b{H2#94}zFDT5B8^@s_vN*-yL^lv3f*~2vgS&q
z*~wTGX}WxD|E+2;;IvNi)v_`%7FK20&*MvuLJoRQai{LybH#G$6P+5?B**Xd)CO~?
zm2LqR5upJ`l{X~ZPNc7Zm!i^NvdUOt@o38EB%MYSlaWN+w}<nC3m3niz}Nr<uPxC*
zMIIsk6djBC`Yb9UocK-}Om8HxswZ~k%uXKWLpcY^VX^!31jUgdvbpq6>?_>hy|oH<
z`ipv|zmKA`XbyY-e4#<3$mb<N_3txI#3;hl%?GfRJjU7DV3uSRu}a#ufVMB>&v1)J
z$~H%O$wni6VpPiu)k0V)gEi*wtWh*qJI0UUwo)p!8wo#0x$#slNKXC6|Lsg12F-SO
z*{V%>F-Q-PV3lA%Du>m1ahirLI8ccP;XQg|8-h@FF+_t4>i~O!@+a@w+yk8qgfcu(
z{7|@go_VBrU|x06)cHN<NF&}-{7`RVFXHKHqtFrs(6ms{-PBDlOTf$Ym)p+e_ml5S
zv8^WYlOHzqY9qr;8IZ&V$@P&{c0RtNB}HInO%Q`#|FO%msJi_?zo`DLncTm`0-)#4
z%gbTVYNyW0#)2l-o0v!2_v<7@txCIUREup)OQ%ZPE|N-O*Wgd6x<<b<Y7RqGy1H<l
ztfUvLF&ibNROvRB5Tsr(uC$$e7Td{B4*dpbN;tRk^Z}h;D*PNQ0pu=|2Co2KOYaSi
zIMdWM1<x4M)7J(pe*A}&@Gh3D`rP1j<w_b((2&A#0{=ry#n&lx^$=XT+jFym!SU~=
zjO-*1*J<{w%n(u$;Z0}P4bJy1g;dpd1uHsLCGaGu4M8~bZIXKtP-pcSKTy+83CxwD
zy$ACmG~jnk-Z@lg^!L^z!sJ9Rmiz*@6wpu-j@S{=04^3^YFAX-VV-`+p8RhSLRMA=
z<wyOs7<WTU+k^C<CN<Ri*NXs(-2nduEaZ=Lugr@}3`o1WS7SeOyQhI}!=&lk08^uX
z(uZAxKlDNA7}j?l>vpYPN$T+!z30%k5;HRQ<dM8VZnr;AHZU71u>fvsVrLw|d*5u@
zuvR2n9)dOt%Wonn)_`q$jNZt@fINX-u9VKxWYZo+>PUMJKB7yqQ3zm~O%HsdSW)9Z
zK?j90yWWuG#AH@o1Sdbk2CWCiyeHS+M`<E+RPxZk8bW!Dn<IHlnMq?+BiZqR1f2uv
zfkE`L?R+gjG$dKO6w+>y0GDyyhvWXueMLfqg^GlofW}DPjvBreGYd3++o-xU+{0Gl
zd*X5+cW3Mg<@)L6UKyXOo`Is?g_L5oz6lQ`Ut@}xvj$!3s{MNGM*O@<Jt>vw$Zmge
zXs=P$;bzS8+EIih8@Ou6hd5X*7vNtnX}UlG9*Z#fROQdXMRj;W#Oq?tT(qaa4SG}3
z-d(0t=1(L<jt$0|v#nt%4jrq6b+_txmgXn=#zIl(EX^9whP8V?Cro8cu--;)JaFlV
zd`JAL%Ho)^YvQ7AT`4L!bckJ?PzrcL@7Yp55t8FD8ucr*k(o7Lh-eD5=}?`^oGO-^
z%MAPUIO&M&W_jAd1<u-A-0}tPefR!)%`<aad!XDsx+-blnKwZ{or3~~#YOJT?sVKX
zT2jrp%_i|u^4!xOi>I7F<jl8V%BfD+@rEU*_qiBvNmK<biMeX!ix_E;fW7=9WwQ{R
zCmu4!a{QB<%!J=M8TC3!(|Oc2Q`G+jsGpdrqW5Hfj-?j+8#WF<$60fP^W#Tj-A{$U
zy_V+lk~3!9-q{bo5M#V!B7V!Zj|7ll;H=?=t1~sUFqx0q{@y_tGm0BUzc>1$@ztw9
zLUIJW4B%kZhN%o<)Cxvia<>|h3hxU0Nu*U)?fhL2NJaf{tYD;S3eJlE8{Wo>)j~Rw
zpW3whgmp_7sAv?cqoO)ltOhnbfH@73PE=Hs4otm&4nNn#=aV06ZD!NItwdEb1-<iC
z-{%=|ksy%Zx+MVFz4PB=4gS-N<h^~psGcn`!@EnI1f$9|T1vEX70cJ-Ax75=EqLnb
zg{)!bq$LFu|6+Efy>CRuppy5o(CCB6uaj%-K|(z+Tt431ngU;ObZ{D)pnIGa2?E7v
zK-6R2abs~^mGwxpEmR?W{GtN<hFHH3zD=d~jpvgMQKD&qQ6Muh7QX~x!KwQkRRh+&
zyf3-HjR}`z6akjxnaNN06IM#x&H1A)PrsDF#-7-e$WsAHqq&P1`&OB9sG-DmeMmhE
zrr~V$HA9F@Yi5X%zJ#Y-hySo3X--cTLH^AJ<gvk$=ajwJ$me9#QM^v}wl>#(z6qL6
znVUYZmE-*g_cgC*mYTSHbhiAkSaKVp#>WOpg*V_lw=oaoH#4S@ij-SPKT1d8q5sI}
zmmjNz1ZsC#*h2dY51Ow1Pq?~(Z3N<<@SCz4M@3-lJXl*V<Js9YnD$Y_ey|^mIQ_uw
zPY_7Rgj~;;*08sH7~#nf^X|{S{=-N#pgaQo4#jtEB>WG?yg{j%-UUMytuGSW)4R=j
zKYE4Y$!4X7#W>r-)IZiq%8Bj5LM3Z|$~4~ANauv<)n}NXrBcD_rk_3Yg%g9x0)Q+C
zP>`UBps~dunTSR55?Cdnn6hlCb|ZzX(fx6EUbWlC!0BNg)=-^9L9`yea;KV2RDoat
z3=^1({V#V;Fr-M*neSj$mfrPbqsDXjy2NGv$r=BZW&ST$&i|5H{%zjz{gZ*d;HVf=
zc^Yip`*a6?5zT3{{^gV%TvM&w46krl_R>9;mtY;ZMR>E^A1puA_H@K=Y~`L}Ml65^
z+LiEVZ^3diH$U1WV1GU5KH~UV&ae!<ywUbJglw$ql7Ij{3mE<Utg_#J|I*Ac3_!fT
zx_Bitdffz_O$L8>18A?vFk-fDY4*uKEF8O)a9&=_d=K6(aK<WeVR7--sxlfdSF)nE
zR+uFjT=QSMWO)jGS2%R5;0!(ojAGH)F&wPx>zn+3Kgr7JRZKW2L=fIK7}6Wab81=7
zXNT*2`b$B6^-}C2whQQNdzQUoyC=qbx}30>s;aR*lzxcv$H9cUeNE#UXgSUcymjeD
z%$SErciCbC)wX+rT3zrvGM;a*bd#U52$6T_+V5t@{Kj6a`%0x-UaDoao|e3tfc7|T
znHQ~VpkbUecA-0~qt@z>bx_9r;#$uta1Z(qYL61AExukpy;++k*L`kdu)TXTelrxL
z%W*+H^eV9>_WbrUD89*UdBX?9;eZ>I-q9Lm6E!B&M^xCK2I8<o`yww1(SZZe|2jNN
z?#SEZnY-%#X#aY8WR1NdfxRL+yERHgsBeSXplXw<mUm~q#Xm?hh$m-LoHzv<CUt1F
zxer*I)?}8D#5YE62m+?|HhF`61a+0mGK3xP;0BT$RPC}|{)*|62MupM=<5n_%(}ul
z9~^F-huIaJ*O&hJu8ilz{B-^E*0tAggQrsN47XXwOGRnfRo5fI0NV2@5|Qsgs2ewH
zuTRsz#zyhe8`9V9=)7E57@YW2{j9bQH$|<Vm;CTpP`sK}9S`ky^Vd+@@@-l#vzrf^
zgTPt^e8$=3Gq_)Vx|EgY=5hS|;}Qvk%js3F8)OU5{li1&88-g8wU%(b8)vI(;we=r
zd}YA*zMu?c_mldUUPRgUSMUd$R&?OmE<8lKr;P2zwEZF1k7xcu5>Iw&6Do-A_Ls)Q
zDBkC%Sm!dY0-M&Rms?b;P|LXAb0FBGtIdt}`Wb;=Ro4S_Q|?|=D!6toIo5t>`217~
z-GI7wEDfP+zasXson2h#H}-V07zYY;+jyK|@WQ^cy`vvSYGU)^y15|$?>`2BoSrfE
z;>)`43L9H<<BnNyyx=#HeY!%`eb^$P@^t9F$t|hD@h<n+g<hMpX7ym_x}lJstzd3#
zh+=@CfWvHzodRtuO1I~=-i&hZMC2dyzivi(-v64jPVzeM4!g}5BILNq-J3?N++JRs
z(dGYWM0L7#^IFn&rCLdS7qO=c>IdH=Izg@{_%FV{dMdE88gj*LZPE1dAWGj2c~efk
z`V=wtGP>6GdV6O@zdX7|)%bExRlZi-3@ms#<lj`$)L9%_Yr9Ij8#>*tdq_WGfjET_
zUG+G7xZ5;-y_DJgB8p-D(oOY&WVZdG4@32}+0H~W<!H&d?TT;pp6#`-e9l-S^Z<)B
zQ;30$-|eNf#{BmAvX9E)ILym)kDFwD#2UQW4(ctfCWOsq<6|B*pR4gvFaJxWf7)S0
z#$!qbYTI4e8SpIib%P3RP3-r2aJtn{kFm$Q?!30(_K-$*Q_sf%LaZ-;VeiIKwc3q>
zU40V1>BY#fa<khK)Al6uW?yU7&B;wF_qc)cHa@gHs+NU)-MD?cy*2h$^(-g7s!wsP
z7t+|qj#QeYwfIu012M<`t}$^f-TVpZJWVs1j)b?G?&Qt+Z6CIG`%-k()y{?g8HfE5
z#mo^2TjPrx(VX=^W)66zMcwX`xwP6k&~>?O?I~@(yRY|2^lEYxm3PCrd9?Oodx$s#
zy&RmT3Bv2%7ctl0ohD45Y&``*c%x3-EvIqwzha^{o{3!IyzZBBleqf}!prq<qZ%Ha
zckXWFr$d}d9$~R%3R&a9Mm*%l2dzq463Y`o-CLU8p;pT-KkFghAX%+pRbNF}5hbUz
z8I-*aF6`du?cv-!v-h&iI%P<s!BpnE<fJdPPB@+Or$52+ly*!Z^e6H;ANBLEwh?Wk
z&}MXb@Vt&j5sBZ*p3<JvjzQI<dOa2%BTKvpDAj$N$Syo-_t+Q-OK@X!OpcoKIv*|7
zedv9lN^g2$_`F;0PC57D|DY(x<Jk42by=F49D#NHbvtJM8DVMdv6GwO<<K5{Y*RG@
zcm#iD$VR!=Wcso>#_oPPwT3?~HvgdNk)cfR+3U`K)7kUZ0)rzY;(8hU+G?r?HYh!M
zH5VS_l&3ZGU5i6Vv#;@SKj`N@&(N~3KD8R(Jd?CMnH@%0-O#n2BCn0DHoU&1K4(nd
zc|qjZ1MKM#b9V2_psim#iq7~8`(B?YA?9>*bPl%H9uKK9_V}+ya_vTRo(3O>bf2X#
z#v1dy5*F0Ntu+S9Yl5pEPRiP)S|=kCb?>*Y>OE&~^6QzG7+!9g%CDxJlbY7omIo}}
z)m>>`uzPML*Ar%_ST8p|s#=R%#_j)OIZ<Cb&5q)GR60XQe~NRc9s}Dc4k6Y@mIj^^
z@29*QiM^Z&f_!j}Y~kOm_FV;?2XGCqiD-Jfq*6B~a3b76slRQ6!*d*zb_aqQ7iV8z
zR7GEooOMh3OMN3I-6WOX9AYh5aroyoO~M1)o!*R1Z`>?3Aj)&2LNgHhHlYkkx7ac)
zDcEFxBxwVk<|a_3yZDN{1HX$SE^kh5m1}{8cD11Sg_M_G=rnfXFpJ0Y6=w#;-<r9X
z61N7lexmL5vWph6$%H*P(R7Pi1J^}Qb}Rf#6zx%l^0y6`_zlU#a}V*+f4x2>jOSaY
ziE3;(e;;*9hK5Js(bl~qR&M6)zCxB&Km#|HHme6cby}N^y&T{t$yyNcNb%m;>bNeq
zhjE|1oLYONpMqug-zVKU<wq7J`5}8<dd+=!J;VNuI|M+(XA9S}x(f0i!P-2#uwnaC
zyLRA@+D881Ag_fO(C<mkzOeUdt!nc<x0((NUPwvY-ho?XgO`r~CkO;a6Mu6v|C<Q^
z-$?0SPy3he{@=XO|I;n}%a8ucxBa^h;BU9^|K|gt6+6MB66e@}BaQ|l>a<HJcM^>x
z%)<R`8waI5KDrf}^)n)MGh$ML5f|Xq?*4qEsj2Dm1ir4W4uRj=%4)UE1N8C?!u-7{
zHGstSe7zHVQKtfx+#k>R=7e8ctoR?)_qTESN67d*U-*-8;?Mecr!&Djdqao|%LtWy
H)${#7gPJzo

literal 0
HcmV?d00001

diff --git a/doc/assistant/repogroups.png b/doc/assistant/repogroups.png
new file mode 100644
index 0000000000000000000000000000000000000000..06300ce66a1a6dabdbbbb1bf91ca1abfd303189c
GIT binary patch
literal 15636
zcmZvD19%<py6;+X8Yhiyn~iNXwr$&X8rzL++fKvANy9d_le_xg=ia;bIcJ_{;hR~r
zKF+-F4-=^<FM;q0=Mw+`K#-CYRRREjE}-v&Fkql}{B~bo&<Cu8q^2_ffOzuv1$3Ma
zOabkLc9D`3gWiNDK&HSEh6xx1?ZS2u({K^7x3x93a{-7rnHsv7nh?2Lx>yiNNXaRx
z2O?qu07L*OQ6UwNwKHFT9W?djcLb(j*<>jhC3w}cP#QH6+j)#-RQFijRkaR#%T5<<
z`e-$qVtS2X44dK5mO|RLAapm#^(yJ+Tj))OWd)Dc-<@HbVbzz_bu`UJaMqEMi=xv3
z85+I*WFfC@Nf{vk;Kj|T56KMQ!<VD2FU}WaN7!4#(U?FmFtDIrln~(n(3S`XDoHcI
zz`#(o6M?q;{h)vVCVu2!*BAHpv#&>s4^#{=z@T<kb4jz!$X`qZ{m!p69dGNbo!cL5
z;&h^pLNLfKzi%sZJ>d`19DALfX3H;(hXzu5-`L|vJ016+xC{5v39S+Rmfz2?lXWP@
zSkv<JiCjcS0bfXD%l3l~*|-Z|g96kTjw4v$z_i-)N&lAr7UQTIiSkq6{@>xa_X)aG
zYq5(w%{h6bx6qE)<J@!nu)I_MW4<f>tCwfxlFIn=r>kgd9R}#<HwAASb3InR^3&b9
ziF(+oB5S&CTyF;6_KO#7_dJx|T5kn^{A!&!6#P-{-Vg(Y(J&wPs6Y6xBJQPEc`Ni6
zId!GD&(TS#okoM^VGcbwbg4y)2<t}%1d%tw!QGZ%V#oWveC{uWiY15O+P!VU{K$82
zQO6^lwV1w!T%l?VA`%s6@h9&;#RKyLKa#8IUuFZ;Zw{|}-QLS%Kb=1D?XP$kc%z*~
z2AOT)`=#wpU?$s!UP^Ty^kAL(l-6$=>5knJGKJ9f;z9!e4ttAIy1&j@ThGt6mhA}Y
zYOMW^y<N65KpkmU^>jP4!~r;~=E!^At=Ydj9TH6U0e0j*A$)=qaLwat74$q@-ZUS2
z@uPdL9nJ`rLDP^Bp~Xxu|0b1{*KIsorN}}i%953Qi}d<{qty<N?+F0tDIyc0E?;Qm
z33@EtKNk}+%y$9uw%vM1AlDsTeO|9dhmEcl%ayA~DRVsrI$v2rdvyc}A8R22Omo(}
zfXC1q(p;#wi<}QwfWc||bq>*M0yXIJs9CsE9}v)S9F-C~{*fwkh5?`hKlu35E5qMy
zt{QW1E|kZq`??lX>-Vb#I#@*Dbu(vlKZznV<jjlY+K)-`*8Zk&_y?x?@atY+zQVg}
z`6hKY7iXZ`ex2l%#isz;l^N*p5NL($eN?b%I!?Qd0K(W&0Z;qwv~69W^7->YRMn{2
z^%?Cze&D?=WNfs|GG)jnOvhTsLr(Ctz<u~;?(3<H0;Oy_3fo*qwMJGGmi24f8A&?J
zOZmnT=FT5_(`ihhn@UDGO%27@p|iFk$Z)?}H=paHZvA%$$bh<av^?M6t0C0#RZv>3
z=$xC*NUoAHRaBZuf`psBlgoDvnEpKR@EwNFB{mBm<ou}jPouW#1Lx0qnEI~=_{2g&
zLY%ky)U-$~w_3t>avmh!PhiY`dtpzny$=`fWyP(80o3kvQy%Y;tIAMsT8=e~8E3`*
z7pt!M%`2!*)&oh5HIi}g*hbeWVxI{z)atAd{lAs|_P9&^kQ<wP!~WfeXV*_I{R{c!
zN&TbSc)flYa(1?5)I5K0mOS>MN<YcM?PmB^ZZ+)V?clJ>^EJO<miI^_)Durr0X}l1
zw?(IEBlB{xg1l??!)GqATBJ#4%X4%=r^C_s?fK5q((*nsEiLWHFK%=-nvVr{-K$}n
zE1K&rFL0gg*FLqzZP$*30wTQVt{mm>&O_9M7Cw2&k{CjKu)f=IcU?}s9z?<8@6)rQ
z+8@q`_`B}x*o=dO?hs;7`XA<$cXyxP-x`NT&FXa(&hZ`DOtF7n#aDh8_3<B*>u@Sq
zd$<r_wiT1|^t?(koQ6iqD<*bN&(9Auz94wD8;MG^C8ssZ<#N~=5>!M6V6|Q692UN&
zTwnh>VD;njd8EU?s=S-sMsXUwDNfPO&Bnm_3=!e2SM6~}kk&kVM~H;a#c`Lx>3+KQ
z^^t7VZD*n8grSOQ?&Gb#uC!I9%Lz%Sx!3)&6Ps3AT1IV(_o}}?Dfuq@{o?(i(C01A
z_5|~RkUPKo^Jj>@gXK5EyzZB$#OrzXhOJqCi(Yuaxx1QPzuPxH#+385=IYD(%OXPd
zcaP2UG`MwIi3i`?z0KLQ)1UVfzTN(O9;Z>HNjbRl=DBaLAG!@UydSgivs-rp4{&%H
ztQroniNU424dkq|1Xk?^ACv7R@iQ|%vKWXrko-Y$^+x!bNbpH|)U=Fx{AZm=G!OS3
z_4qLyCld$#(1h6n{ypqHH%GH+lLuRV+Mhk4zdTH&l+c3v|3T0rhz0@*jR!COwENsn
zG=oFgJh@Em4!GH_zldxnUHCI@`5rF!W`9sF1TTJ*3XP8<C}60qIzjE-ZX9&ghL98I
zPw&{ejo(rz5%c3<yfu4kIrf@WHy=cg{v`#E##iSxS+Xq}4g~~w1ROO96wY!yh<~Tc
zAWf%BFOnplZMmH%qKbePE@6<&zzsAkY=4kYN~_gzx0&RHtN$&t?Z>m18!?wZSN<?o
zdY{)T+j%iba{l5;XK4BpHzAQbjclwvT4`XmCA;+=6_r|j3MEuNH-RkA>uMho2SQiC
zzll>gfhBDy;%6Q$iC27XF9C!gR-`V!<LytRG~v?s(@=p|eqZjxoitMIj@D*Q;d+la
zBA09Uc9O!@rNg3FSd5QKNQ~x*%&Z`&HU2kLWnP@<FVDj!K#bykwE|YmNqYVF3;$}A
z{5aox@)8Xe($DA7$~O2T7EEeYq?4hBl3XUT&_&ax=C^+;YqiWbt!ujvCm-fSe>w#o
z2)-O#K<twYJYyPphCFqnrS(Q*y~4dpS^3w8k(mCnSKDxO%s3W0oE{_V-)E;@h~vY&
zLDHP_{&3&5j=sReEux-met5^d9oRHXqF7e{aVdrsKN^f@S&=sq!Iaj!j`P!;X?9*g
zm)|>|=p|tKr|uiZ$%oNydb27Fl7`MY%inwF#?8C>w(cn?{xE?%@e`2@Kw<0gdlUKJ
zDXui#xsU|yfTqoZ3#!Zy4hc|^N3f5E5%=TmGlGZct-YRaO+k<2?8SpFVz2g9=h3_w
zs)*m0hUQykHjKC%0DzYSuc%yz5IRFPg)!3OWnph|@+QJLQ^7y|{^teBsT;4hLwuqL
z?Ntytiv7o(=m+TNR*6Dy-n~ZHH)yJKM)`VIydt46&@e_4yZjwQV*v_EN`c3nU;y9*
z#VhUzHk+=0nO#r&_R@BLPXE$19GXDK<^!%t_tIB6C>AWHOP=ugaKiIa+5JPoz{!E_
zeW9FIfc_JH*M$~T6hHqqAEVO?9i5Z(<@b{n-Mm&P9*(QmZq&wdWFrL%<}1IWfyXIG
zr4ND$O6ETkg2?d~mk<3?$U}{rwjRVjEIuO_dj7UOeFe53J0I6}Kl385?ciGwjA}YL
z-Tj&#s4`maksc(%v);S!T$@jxgb-6jo=hHNw!0HP8XchFC<p+H=x~fw5$=Odp(8N-
zGjPAIq+(j0SR6nlKMUk|cTyEHU*3}~N)L?9-ip?XFH9F_DfNmiZOva8Em$r_`ts$X
z!O^z%+smC1PkkQJHLg<DoVF*ODLX||mV%1(MVNPG2y(phjTE#O3;oOK9}XlRc?lRl
zA4X?{0}XZ&yv|s}c@arZ&_znA5X7^xY6d_{)69S1*L!ajYx?JK#waG!s9^keVSZE~
z0j9SfTa>_C<6PcHb0rs+zu^zt3!Rl>A0LKi_pe!)XtV6Em)tNfHW^%BAOgNgF_Ou9
z-GBIHUm*b;=vY0i8Ya=vP&pR&IhA?!tfoq8bbVcV9j6=CF+;bSXfbV`-xe5G%HN&!
zpXr`)50<@1N-ci7wDQ0s<@tTw!uc!v3taptPwQ1v!)s@y{7_fUp-0M<5=B<IK!@8g
zj(OnB?sB$jbFBE5KZ~zy%?SR-sQ2VaB(?tcgF^3RE8`58>+~LQGPHKF^pKDHE$DtM
zG(t?-kpQr8k>|IY#MqPb@VMx#@8f9rr%0K(uV~iq+H9#^|G;D>o`{5m$zgS12&0ul
zfPE3Kb*nwxXUNz;1*iV^Tjs|+ilx|(wk-WqjC|w3&5T5x`tp`%I{XARHvB!H!QI*t
zreK)yQJkOq)7F>U)(X-ix^(EQ%Y?hc-MOQFizKXm)3?Oz>{H9-dXnVc6WE?f$lkX|
zrX&4KS+@^fYNf?4X_J>1d}hpp<x(ybLQ`=rf#vpU<{J)$)#(B$mhVLc1lV$4Sh}Rt
z8M?+F%*+UCt32<D{gC-@)HNrKgoEugY;H&*%)L4K_pXX3)9|;yUPV<9hD>WT{Sji0
zABAi9xQH#7^>}S$<ZrW{l({p|lecUcx}H9C4JTw+XJVYH*Z;woo8DZ%kFNUj7E-fP
zU2{U3Lp73ic?!0^RtJynhGILb{nlgHU`6w$C@9G85&)Cs*Lyj(oEE1CllSCdR~Rt5
zcSW(?>9YDGDoTAR^;`K(+7YjV4DtmO!P_L|;i-rH0<Axg$Y$-;lyPK_cgvMa`*(w>
zewudHhm9xb^rL|g_q{NxtH^fOgYB&>O7u$)yQ}?14Tokkfvx+#J?9geo}AY6Eo~c8
z$cKZK-k!#$KTBzXLtVG})1N-pJY%?Gs?_1n^6cToI!zwVcTdECA&zjA8I$1tFTX|!
z{e9SZoQ2CX?)-1=*JcS<-#eUVaAJ!Jo{(@qI9hk6!;4<6o~~Dl?R_}R2esp6yI~98
z!ljEf===^>kP58t4qrmgJ-8bDDGxsOT;Ey=)z1YuA6k3cHuF+{N0;)iHY<RNaKoGu
zO(+y=teCUCzBu+0FYe<-OM87+)r@af>)#^0^L$KA2TXPtCresv8803=$bM~6uJBV5
z2YGa55w9Ji<|wWgB7C7uU|{2h8grcFxhS;#F|>*SRCx-DlbnSF@;M7hBx@qiO+e!R
zKsmr{auSko5zT<?kKe|a&iS&ZFA?AUG%8TkMg#%lcl=xXH5&RW-pE_47$D&Kx%R6f
zGBR?PnBCf2t{Q{dzCa^D>=O_e$kWp0AF{xT2>}5SvI|ZQ`V8rlWhhB4Jc`niMI`JB
z5bE~KN|O`E7x9aQZrOvS%0<I_PXa%j<Ty+4Tp6kos4g`H5)gOl?**N4fkhpOO4O-#
zF2)_k<(f#r-%OX-e%!Z8S0XJ}DrA~V9z{6_p1eCgE>4B}qlmSBuCB?wo?|R@0Kl(p
z+IOqgR4F%O4b6KOQ2-6*F{*hkl`mI#qG_#9mP*GxA7-(*x_0jdkM5?!|144b7J&^i
zND78L;&1IyeLnAh_EMF})1ZlVQo~`lj9xzLUaMStj&oZRxu%-vK1nUaJ5bP=y#F;3
zT#=;V^J_{w7zoH$Xsm2|%<(1UwCE_2{LWee0d8>q<MnrSqWk^Q(n{sJ?7|_rs5}^l
znzNSw#nf_ld(OCg%KhYC>v$5$SzP*>+x|rX+5vOi#x90VA)BeB!gT&>S3$09SVs3R
zy9wg-``ISvDu;N|lgM389+|E3H;o0ck?3A^40|U7xLA&m7;WBN=deI};edkjZd%Lx
zv%yu246TaF^`b^vE31iARJn;~2G&8#l!>^Xr%@GAr;l#M4bu<+02Y&5*~@20c6QU%
z`kcGFO|!37hIVuqS=!C+M-5mTE#g1P_BuDVJN~3p|C(yZ>}J<aO{|{iSg6S{3ix9~
z%tCu_^X;lY7hKS_?D=yjyJ~2;N_Rs!5&$$0f7a}z?8M|$g$irrSFHembe<C{o?=f`
z?*}zoDatHsTs%A%LpW<Y^Xv00Y<Kq+&WBap2OrIK{JdN$hlvaaxSFp{7Q~XW(czh)
znLz{0pw#Fju%IiyqJ)m8Lqt<+b8iF#)z-ajD9Lc9Z<R#0%belRPL4ApkwrUTukbrN
zPpg(P*eP2M6Fa?7A12xN?}?jQIj%E?Mq*Y$Fr#9LWXz^)^Bdg5#;Nw(J<=2dKmu~r
z2x|PQ0wyVx(T5FJ=^&V+QF7X$XO3=cK%;ymTFG|`7ze*>60x$zT&ZvA^}6d`9Z1oM
ztUNI3nd=!ljmqdvR!p23T7OhDq_yy7hJ#9}nA1(kz=sX0G$c~tL}EhfT;n;?$|3Q&
zsI)_1AE!b~sBlPO5KFN;Q@&tJulMdzucHSg{M>m%o7?DQZ#t`0;cz{!u04wh%@Kxy
zoz+Fk4M@Psr@{dUe!V3k3>vbCDg^F~($P=V)LNHK)p8^z4r{I|Odoo~gjzd~#uZ|e
zz;Z4(XDv@Y^64+TikF&4a%o*+k(X(rB~kBC|4lU`iIc0nn|yOwnOb1bnA!~>BEO1%
z0`RX}n%FF7W$njx0`hu4Gv(D(+fgjQ(V!YbB)3@POqAA8ugj%y%wq`|v`h{k!kK=M
z_K7u=>Lv3*PVr?<BuW=ooep!2D7LY?cSJoVvPCvDHHc*we*F>YiQ2P*u@j$0Y=$k1
zuv)a58abD6mq1LnR%P<aV~#ws-2xLYAH`9Dvj%VGoaeSOX}ujR;M`x7RCq_TWSO+O
zShQN-QdSV|DGvuLZGPKkH!{w}O#K-Swxd+6m>Eo3A%l-4#8vKuy&?&!@wZEo7GrXx
z<4Xo5g4v){iZr7<>K-7yli$Pk3{fr~79dRJ(w&UADxB5n5Gf;v=0-(Z$rEB(e*Qv>
zh_S=akrkRbAc?wQ$pdPOzIL#dgttIL4@-zBt~3;?0-`gNp;3(vKtDBQNlh=KF%it<
zHSu%`3(t#oZ?b`9U0Oz+un>UK$;I;}%29rHW-28Ov$hI+zAK6y)<x#4yogokB&+U^
zf!oK|UrXT;$Dyn3t1eQGe(h~mzF;#$$jj^~Ib=$hwKmI1SHC@%k1BjL%}QFD*h&*d
zhQ>8Lr9dPkK~f?Eb@hzCE&>20Cp&{@{fCfw%eO<jSvs@@^5$avd9ZSTbjl{!>({a@
z%`(OxmX`J82VZCd6+772a~Hk%8u(dV;yIFIWO%>KV250ROYZ&>t)yoWa$dIR%iqk_
z&jU>$yA^Lb{>2Y*ED;;ej|lHwlIN!nnEnm->tLs1`34umMJ}f30H%?35{NkWi<aq1
z86KtrHa<q$K*D1)6y&)U7$6X68x4vVc5eS-5AVlKO|15(ed%AeJ<i*wZT;$}RKbG!
zG4(%_h2dj(Lp+BS>F=sbqv=V38}9E;gKwf#B&=|*a0E?7A^7=;|JDQx8prgeU7!jZ
zCIA8@FIyfG2+AWXz6T;pju+P&8apNtuvO0xVfJdKme7u?PkvYNMN81FCvI`}_jENb
zMFEg-f1$Nckp;-E75c>TqFa~QE`cj0YJRJX7zk{aP}bF3uPOo%8Dp9sFhpN$W$Twh
z=W~}vl&z5!HFwIS$ZdW`>1Lv}Z<hrGNNMlSCBXOjiyNL>QPEeQ<PSy4po=`{t!LQf
zP|U^j*hpE9*-KXcBx}^Y>s+SEx)VK3?CL80^(Zg!tIl_38J#Cx3nLhJL&xEPyMOn=
z;;^LvCb^jVp1%$8az1}jl0Lfsg{@OMWttlYO*-w+ly+kn4&L^Kwi1^oCLl&XG3P|(
z>%nmYkei#KD2AQ;j$zrmFe;!$4A8bT#*;i~tf&f+?iJ8k0+jrzXv*FhDa6#@eojC$
z34ouTfTAg`tEdqCQTp5E=?9ajWZ)|1D9e`)<%J@us&X&Zly{}o(@vKFN^)p`LpTg_
z-CJZU)R%G*E_Y@pX&gEg6h)^%<2t-tDRf{V!Oqu(zM~HB#u_n36|&JQ$9|ho;h6SU
zPE2A*4a{_nT+sda#yAmuz)%X>LCpyZHn=JXp0x5iGyFD+U7<Nc4HiwfxuTdu<>)A%
z70#oM`vo21ju*p>m?Us5H19ij8|{~v5TP<Buyd~gNovcT!AtyI3VDWm?@Y`Jm|Qjl
zpPJ55m;t?Ug;f^36?wjXg?XSN7@qykAZJAXFnP8DmJm6@wy#86WQ&;WC)f>D6khAU
zwZy}rg?PCtr;Xcil`pqVzzOmk6y7sY;m@(l{szqIHMSil3DqtVi>pW(bM=sJh|*$?
z;ylqijZ#J+tA?;ZP6bKGfiq|!To!77H98cQ`#rMcIxsY~=pj6~MQw0B?5O^k_95B@
zkPVQy^kqKI;T{^Jv4kIV54l26(GCI8=sNjpB!5#RpF<F-{y(|)M}c;aW${a$?*g(2
zfxFVkF)^zsMhD<PDzp#UFGNHhKzqL<7U4A*7*dGdzdK^aCWcGk=X7(F7w3;0z;6%D
z%IvqAIY>$OLJN`P*Kx4c?lHTw6F}S50B)x?)QKyC?F(n`-#u5?he+}r85|E5Ze41(
z{gz3v;)9Dyw*zL)R-=>H*w~CVc6Gfixf!K-nn34xvlVMblfPS+PE+snj%D|t^g7T%
zZ7Xi&+n2L*PQ9_QF^}EY2dLP3W(h&8g#Cd+_&(tICn&QrwO|QIz`{6^v^2ZpDx?DQ
zij*>b1;3b~oT?#>YOPI!6nS4Wj(9-IED5;cn#efV#Kh6nwa_>aXt>`ZHW(t;4}bx!
zqA-qbP2z#SLEG+ama1I1%7$qk5b#gn|DqiL{;kQ(Jdqs|L@HOWoYK@5DZyP6c}d9Q
zQ!Am0av_7lc}tvlQi`03pg6_I_{wRrHwvLb({7bdsHy-lk5C_UP_jycXeBG<(9;wi
z&@d(`x-$rfxL{?V1jy&9<aC=4ki|%Bd%%w+pxqXO(y(AX)_QD-x@~2H0LdnaaM9O*
z!H#X!en7=i-*-R&EaoA4$-L`uN-+W?<g$Am>zu=hg^Ol=6#S#`I<77p;@*+HB@6__
zc3wM|oLu@f;AL|j)J@RIWdOmMI1Ct6HFPuBrGpeLaMsxVIQexR967a9FBtwGhc(vy
zzhN_bi;0nuUz2n$kDHo)&Rl1w(8?^5i19``YTs$2!>ie=pp<7sf&r?u5T=JK)oUtk
zvT`!Iztv1L+Oyu6YHB8)Pk>HYS;9$boYxIOfo#Bpn-|jk4P6QZM<C&r`p%%&-r-S3
zdT1a0I!i-Au3K0;t)ElRQrbo8XW5ZO5X9LO4lq7=S(;5VH63Y5tI=!c?p>ym!&P#+
z9Kr+k<H~Z4L$>X}6~+cI1qmj?frKPr552IUprC=sn5gquI41-NXa!pw{JjGHOKieJ
zIfi_Jx;wPZJtn4)Na)k}#KRQxm@aDnz5BlQ?JG8^eQrC%qcgDay(w3GmR=m!nCdh@
zoVRXQ&Z+(b1Kc9|n*Ca(s-Q&`Nm9y8sHWL$cCMwjp`(5fX6%uCwH=flfhV<4>C-1E
z-N}i%4MSm9Z|YXq{3!uNU`@|SQ!s$6nzE>fZeuQnG^_K1pl|#9Fr6~31enI&$S(>$
z3#}X>2ERrdP57mj-mZ@N1(?5~H>FjY;?g7VRIAcv8LeLC`nu|18Op-h9XjXGE54*b
zhkj;4hCOx7zlr5@Q);0rjVI1m{dFs{Ukf+aO4S0@=I^1=d76Cawu>rhD;y_OfU%#$
zn(dRQ5SLd6!s})mG^c<H=ctH=#V{Xhw9)3!^`AgzBshey)uqx^)e4*CAL*co&Zv!I
zYU4oQ=wniZIU4>5Hl>SDT<nUU%;i`<us}Y@_dUkZc^?8UUj|L<O}vMq*+w}L00?$-
z?$N3@4Zd^!(E;^T!WIDZU5IOL)~R8SPpj+AYd7foS#YlWd2un>bkuEm#ho<@)!_f9
z{f4IR9Lm>06`2jE$B3quuJKu#BWiKxQA%*tpTND{8KV2UQK<yAkaKs1;EY5=@beod
z^Q&vlQuoysRnW=){7J5c+Ts00%3m_)X<?zpp-3I7stOs!FGu-6DC?cN67XO;OFswb
zU`LVqY?RY62mxSnE#oPde=*O|AdUnC{8_%G{$yoE<Fwbwr*BP{R<})fZ1f+=Jt)^>
z-!ze)umQ$JCoZ3ESP?oHCX&P<K~26cphEZv2}{$gRxf32${Lal(OJ`;WXLD+n?2p1
zRhp3C?R-@VO`rFqsckA}xCBKnVc)E+sk!VQLV_pkog8Xzlc2dX=CTmF+)G3^vX(Gl
z(_H<GF8^To)v1(qbu^R5wsaD}?S^L|XqNUL&;d6astALxjL}RtTCYqpZf`GW^;0Mo
zNdCJ*Rx0^o4^9{Gje;an_-FNRCe0hELiUApZnjO~P*Dg#-w<^<ED0Xw5G5?Azg1~<
zge_t-yVzBc*mMrYsN{9Du!57Xx^n$f4Xr^Yi1rYlzF~wATJktuYW@WBciQ-qNydQi
zM$Dh|fujO6T6?xd-mqlH8P<5xDyeKy;;I#wdtkGCnPi&v#1g)5dWm+~*k|Az0^m^5
z^WsVC#shZmU4h~JCQvB3?+W69#UBm2k-zC$J|AEy1X$rc<FRe2zmfY1B$bS5X_rEn
z&zE5KQq-S<FpU3fDx+oR&3hp-!Er<k4B^<7`E1fHE#?Y$py`MzxLm11lf&Mc?$fc1
z1+}=nPU6lKh02w?qjoquPS>i2MNCGO^8-F04GdBe&d8yC2YRi__$aF`czRJPc-29v
zcs@F5sO=^q-sLvGXJ-JSKyP!=lm%D5f*tt`h46r#cgE8Kuq!931i8BPQ)q%5j3{wz
zJZ=P0i2?o5r`ppK_T}p6!$(t1P21CSM*7pYE13pXV~4cJLC_toB_*|nUld5<=IG}1
zS-o*XYqycr`QTuf_9TF<)@b^FN!?}p>qMI?7}!q6A8)&emmpUTRZsYMsJ?Y;2wqT8
zzX@ujr>0_PE9Ew#!W7FW?@65*NT_{<9F0rwrN0)aELEB(FE-7I`UU{t1^x8`EIn0L
z0*MNfSe*;Bkaa9yc-=hU;Sea4GcwlZ=d;Ce&?wCh$YD3cd4Yth$Nh%|RLsr=B`$k^
zxDAcWtau9?dv$z2m5+WwLL%yl6s(A-QPs|?kNEE7m?KV%4!@^$bB>zpkO&8a`wkh%
z<R}tFh6&2k#gYEe`eR^-)(eXyK4O1??#+Gp51S8wH4I{q1;7^NA5VZD>FIgYb;>nU
zIFet}`19!3d&m995Ye$b-`%8Z*(Z9xsM76Yu~)CRMx8TwRz*Yiv{bVR(hCOq>D$IV
zJ+WX?gx={_LkW+4=3Ns8-8p{}%7-D*gJ8K7vv+u^=zB{B-4%`LFvzeh!=$~z;9i_!
zK~34W6^k{aKfU7d2L_%}#_6p6l`!!?RCiRJU~}s)uhi3~GUWk+IWI4PNbXHoLTycj
z4l@bjlY=rwr1h2bgno}GEe6xZ^$9yxFQw3*aJ?;&eX>pyICHy><WT|A{`*BpA7$Nr
z7`_@w4whnu!Y}nwNZXv3qdvtHHfHzE@w_a?EKIp?Cp}1&3h4lV8Q@&!^|m7Ur}k-g
z_@-{X={qHQ&g|jT^U0xr?=oCpHIj<0mtbf0A78H-+F3?DCfCHLjVs*?pZnqAlNP*Q
z)A#Tv_RM#|9dNj|!Lu?C5hF4{B?o=)?Q^f+&C3(v;R@G#6kN3I<xIZJVJ3y|-P5o@
zGz_!;vC4b<d1K=W5U``>&bb-n%(kC_Fv}1DfScITxLfK$f9U{(!0v1}*Bw7W?=cUm
z=d}#jw=4(teMg6Mj<cXgD&>-=DXm<SMM}3FWyYh!#E}o+Iyue<=d|S_Q>!r)V1IIF
zKyf3alSuRbuwTDDCOoggs<-{BVRM)`cJKa?p4w=;Nt|?A|CERf2!KRxWsKr&q4r;g
z^Y%7>JN#WWW}LNb>uqR%5i<-&W(Ww8^**dm-|AK4OKChi5TW>;^a=K46MbvQh@wRL
z8CSh(z4Z6dB&#3&mzSp~*L6L97u)^?I5W*8G78yG0%|)yc>sWblOqL7Muk+dFfhR5
zf{}guYxVucKBNL;uIv2`=5^)!<=dI2!YnHMfk)aDi<{35kgx+Ez3OEj-q-G=17|wG
z8(FFrft%C+*m5|hl;6{ElW?0`od4#QuN4RYOvyd$7<Buu+K}HbH@<XOP@y5$ACHUn
zxNSGQ`i7I9_be!PCl1SQ^-yhiDt*~Zo$b=q+4j1cS|7fvelzCOU|`E`Wg^IN-G_=z
z!8P2$G5l%pB_02Ar3$NkUs%6WR3R>HI#D#hzL)p%bYu`@ZLomLM+nDN$Uf_JyC1r`
zxn1gA7clnW2lUN18}IShTQjE9t@PM`F?%7M1VdX6Y1wJojVPHkXh$5d^S4-AVqDBQ
zda3o@cG+2t4exCRCA#vsh=fk(n`W2U_ltc^8N%=o+Z;)3Ioz&L(K<|Le|AMEXY_jJ
z=6`xwu2u02g2f}T?dV)U46<TjWPJ9#bJ#0yd@E6tTQ45dbPofzWmWCLnWAD4M>F{p
z{ARhu)n=!BKQW}1(RLVx9pUx|v%LmznCG+!8ADP|v1r7Zy|L4ZJ7}ByuGqSJV*R-3
zqs1lI)j#Kc-8EmbT|P)Um^al<&lU)WKc~j%eg4UJg|h6QyVvkxWMS04XdkNrL)hr=
zR_IZ_UF^Pob`*0jaj8K@h;^Qga(z~MWPv<M8IqB;HP)2lkV+Wfg9ScgX%cQe_b0*C
z(jjF;m|2`ta};xAXqbO}$~jAA&*Iv_aXApzxT?mv*&dfpqVYWwo%Bg?#iga%OI@2C
zCMV_9<Lk(;)L6onhHYWvhTL4^XP51$ROhsTbLw?6$UzIEme{F2a&8kX4W>4q9M+pX
z^8u3v9y%$*ZvE_TsJ=e(y>{JoD@1*Wz$s|dOTRci_=Wso(a;T440s0p(E$qMraNNt
zDY^TrP-fW1^y6>Z1AsR8y1Maqx(3*$abpCEtVWRyqIx58c>MorUMu~lcD_yrxvx&&
ziH4kh7xqI4bEP!Sm)LtFba#iz{9J^jcD4f&yNg30wMzNd-k<J6Mw`pQ!Q~{}X8GFl
zPxQ!~UT{0@-kbY13Oen2cnbjDy4SYGd(}2PwPF012TC74(`BQedieOjwdKq^z~4U*
z{LXo;Be`#3QY!qmHShf@D-fJ@xdVTzlyn{g4@unbKye#-KN%z@#T*36NhBkNUek2`
zPP=_}s8$%7TNIN?ow$)&%zn%9hD2<RJ#R+y2R4A}EkQxR=J(O%W@+)mWob8hZPzu7
z@A-xI$p`Ya&G@tV%xjOShn%d$y&r?;dxAiU9N6OO?1SHy9WcN&NYC2-hlH8z$<KAu
z22DkoT>sb2D5(JMho`{h3;KYo^+M)7a5%0b)x%48oOnD%%I@38&THhGcKgZ?pI6?b
zEC5FKt8eEP-}{Kn39jIgHZD?Mx(?Ut*U2FC*>eSEpF2xyXjjfS;7)w!frdPRxHOZw
z<#`blsm+(Y&xT_Lu|rjth-H7tD#JFxW-$;>DS}Sc`5O%(zL_%++RlnN3JD7C#L-_6
z3eo-*IGX;Vm^RJC==NIE58PS4R_u3F31yid&SLZw;Yfqfi^+s%@tFL%#@2*sJt$aU
z7+8y0txwgYA7N?UA|GMa@JHqW{aM@X#~>P9$ZR+)q+XT&=&uk0sR%Qg9q+3HLDWBC
zvS`+#>93_QX;-l;e(CST+-f^hy8y13qb!<S%(0KugWLa}3$g62v;KblXGES9AnM|z
zwndWxNN*B*vdT!VuqSDt<rq6|c}rP}#TOSGVH}@n?mj>Re=fndw${E2NH)RPrzv!>
zj?YT`6U9btYEKOTz+$tnvi@ejni*v2o<@_^K~3UisJ7*lVQ?uA=AAT%b;bN(Q88(q
z<@y<5a{8-k!xR?mUeJ?=LH@Ao2qd)}Snro>1Q%ri0{EwEluR4rMndL`Jy)Zsj0gV>
zKTSOq&l<CD9M*)*&vzh7XSXHqva3S<B*TuO;ALTuv$(^3%3N%a1CgBYYtv6w!>I_%
zvtlPW`&siudV(*m2ocamXx`c(ls07(vBO5rl^o+Rgm#X)cN1!kW}4Gmne;N_YNnf(
ztN;MGiaA_@X1#fEjJ;KPja~dqO<6g$wlo{{iS0#CQ3tzkR8VGS)W+la^Rr#2ig<{q
z^q=*P>Aq)f2PGPm3@w@z{Q6aNRrJ-XGwFk!^H|39rqMHeX5-<}4NdiR>gme0&Q>cK
z?p2-joo791F6O+^VM;^*_z0qFUSWO-NT_I8I4lv;)?KF`uP!U6kz8D&)<zIa*0MPB
zx{yy>8INCez|BlSP?0uNRShguSdemt8$-6WFxkkAAp3M;y$Sqx$P?fNJX`rfL=aH`
z-9b<rn0~O{TALW@5FjCiZY0h5_)F&>a06g+x9%8EPF@AW!z8a>ZFhBOG5VFf2!Rp@
z_bVwR`Nytn=KvXX0Z%zJ;F!lXgiXrgeEB$}+!7Y7hlrRw<#hSa6mTq@h}pQa<<5l=
zgWR2IQhut{Hd+A>B;jZzWD*THCXh+lxGq#J{0RXe60mH-Qc09QU@Tq#32FAQka-Le
z0@*<5ZNN@0d^}SDwK`*DvEVm`mcHHbIiztfB5;@An{tOW&5-}udR@QV=1*OB4bL)v
zw(!YY>R)Mu=s|C4mwhvC1)D)Ws`R8oE?}`a@X>`?zEyd|&Qv~Z-c6WS3_JiDi_mXs
ze&F=EBW&W;ij-P2JH>V#u@3D9mhAxKkz_)})fv{<{7xN3@JcFV#3uG5kaMFilB}PZ
z2=NOFDz-)vSER5;?e9}?s~p7yhLz+>o@XYx);scxO=L!_7gv}F&PI0<%Cv$3+RXKw
zC7+I#jtp7GGRYVe#WfI^e~=P0N=^U^xLGjb)grJ~alJLrqESPM1sDAGFA*gu;4nDa
zM4_9?`%}6%TMBuKwB~BGV;kpC7cONU7gNT7g|;9SX)H=ec-mOJs>d{hVO~NqeSJOj
z&^|NE9EDG0P?dUlnOy-dtvuM6SBi9T;~@sxQ6N)&{Ni*g{eLJFqvV}CCfVtqqe3Az
z7YgUGfW@U#49=9)Yh_jztm)IfYr2fJzO|E6h8>YS)+x>S1K%w+tb}TnayT;N_%iXW
zqj9{zzQwnn1g|Wg&)ud2h(d(N4#uUYIycJ{@OU%0Etx>bO2x}D5ephX8Uj(wnh8$c
z)y5=Lrq1b_F%_0%g<xXll}k1^)|VCW{Zm7CeQ>f2gdkZ$5`HZH_v|O~i>joB%2l2O
zbp{U?EiD@<&lzc=WCpod%4WQ^2#k`^Bg|TUQBlUJnduUlsGG@Q(@&+fc#REf6SU51
zO8-#a*ujl6UVc?NHgp#;)3FEZbSD3S(k?G;e_&np8~;U8{~tY>?`=U%Ofow8?)Dkb
zuqtb7WiCh>|JtwWA_L`rc{v%hjEs7k(BD1Ltx+$T3GMznpG!@IxK5&BvLgqfB<51R
z_8cQdmJ)r!_NlzDGw|{}<O(`sU-+FB4gdm1VCEp11SU}jL~+6FoBwrA|I0cZ11tRe
z^78dFD5QkJKFFeyAj2sBjW2%-zmoO`u#)c;K0`>uhcl+^7!Y5U_9Khf<4G)dr>~PR
z&fpKuzrzLtB6lx~QN@L9`s3?PI6TB~%lTrIoUV$Sw#)gt(l?u<2;HBj*T3b0hg<oA
zn|DKIeFywdT&XGzouArZQ`E1yrD6>5ebRcbLq``ECIAwMKuw4AL)9q3o?~cqIACZ?
zg7ZhgU*by)6+H%&7hB{==ZY_`wBSU7kZhNVbw60h7doRB%Wu`RX3iT4<EhESmMGg{
zhlgRkWSBocjqDDeo~ypf8dNVoh}-v5P!lnhRZvgHohzoQJ=BfEMZ6Z2F_B!u%wY+$
zqn$b=NE_foA{xQ<M8Gq}GrCZfBdX>V)|FH+rBtYM+%Z3$Qyb~vxf=+>J6k9^UCpv&
zH5=e*O`Xf3_a0gK+S4xMlS48k26qMIeMaw!BhC^k!RoN4V7i~=_@omy4xIo*+Jm!=
zh(xD`CCMgCt3p0mzcr&U$_@|s!N?irM`+zde+^azxhFe(s;6@0UA6qsVYK;GDImHF
zKyX4S26<sLX7!CZ%ue3(cx4l8rWmf&!;79}$Iyq5b4U_i@f-|}!)W7Qf7U~*p1;rH
z<3NQKj@dX^@u+!=m%sG<Uab+1auZ(|^uTPwe4K&`W^TT!knig>x^Imq3jj=T;9BrV
zaXCv4weiTm*jvoCj0u=&z>V;sH+HIAHU9o0Sb6uRU5`k9h$#kXZ#>5E15h-v3r3JA
zZP2`v@)PWVde>G&tM+RSTe@6n)}mK|Yz!;%4IXnX9^v6!eoFLq&&iDr(~Qa#V)-xg
zCFcOu6YtX2zJ7dnqxY{Wmn>nYPz5TQj0TkD5FBteMsV8uJ+iR&N2vd<H%5Yq8`VYp
z==s7wRnWfL&zg~)TH(+2GXz8tfFbg4ks*u2YHtZ#|FKV!F#D@!{ENOF;PL{A8BB?S
zy+acJq)8C}BvE#U`z*qy7o@s!0y-~)X`%+;sB;E54Td8?Sax_YK4)0Tn4o+h>YN}<
z{{Dbac^`<d{SRt2AnilM75%a9u!kiOeGlAOUBuE-7n)pN=g%b~{<#)HpNubfk=e~i
z>LTX~8N4N2)7j6TM6??_mm*FN6TX?csDY|Q2Fb&O@R`%Y@VWCFD(sIyjs>pRoV(^`
zyFY}Az)xj0kP_oCeKeM+m+OVNoOT|(8FJ-)8z4~v-8^;aw0gB6*+z9ahXcIj+JAJN
zy{TP6c4z4}%*+%#MM*<dHUD_QWj?r4gRu#xYmt)(ZQ)nvN!H8hnRidsS)77`ix+sg
z_d!qE1mG2b?2pXkIiagc+GmE7Ru8Uthg1fD^bvMSjWI}K!~Pf#l`99tYxelQ&}6_s
zdnBt6m$<Y@v&J2K$WHqjfK``po@m_)i#g#DVos@14J}{u)`IF>=Ik>srLkDraka22
zS2m=!WLUE8iK3~q_#D&l2p(LzRc-~bD7(kx2C5E#o*$qfS(AveMH2<F(-Ohg?x99g
z$AFq5hu@+eFgl>+NpoRjan6V4!QQ<<Xv=8>s=#NCGeRq!VnbuaPK$95<k48c&dDWr
z$~gvA;;~4D<$DEPR!UK;!VYFrQXhw}@&*oQ13<2a+>&AMHW!W!dFNa6>uPVxmSC!o
zjlfXZ{@_j-4Xw?p3F4eyHKS<4$|E|>`PyQ6kfRpN_zT=eDpOQbYn4R)N7?ZZZ{!R4
z3<*l#8Z`#iFC;|;U*#p3<ctxHzg@AXAX6WQ`2h9fxMhshfkj^S)39*Rx#d^On1Fd@
zvyydGQT0G?XEzE(P)rR{thM{Yl7T?El-V!e{T1p`Y8w#$@1lPen#Dm6V<L<({X5`p
zkyAA`Aj6W*7+Uq?(&+E>T-Fwjwdu42{x`*578uJes~+g=>?RlrBN~|j$6k!9z5<KJ
zs=NmqdnOB77C!TwfWjdcDO=0%CPA8jvk$|R7d>ebh>%C{MdfYKz?qkL;_;L{Lr?qu
zQ<-kB5#26XyFtB1i~o1AL^!{2q0TS8`~?oyR-dmwd$OSfl3|WO9QGs;Ceykm7Q+>N
zD;+D!f<4CUAca+4KU^xtPgl&$O-t#M$R&wabP~EmdxXWkKNka)?BxG1hX)EyoZe1>
zYB^crl}-L!-7g7Q+w2IhBh$Ei(6jw`7Y2?dKLc?Ro&>I)@cafec%8Ae#|OTi@ENcp
zgw-A~8H!T!@vsOFU=GG?QH?pq2stq~f38*@Ux;{KQzJ#m%S}te8CB%B?`(6cR^>Q}
z{7LTVsqm%8d!-(>$p~LB?BZby+iJbw?mDb~nau&%<VT1h%V`Vb<b&3r7tqNX;0p`T
zv>Q05lCXtXR=a#;f`~Qt;f-W^BvqV4%Pu_9<Q&XlJqX1M59^@^F>&iQ6)1rX^o86i
zzEK026$2_2daH{^yR!cwX>W`s*W{z0IJATNKg@h529&2E0p!4sWRTQ)k>Dsqwfn?o
zfm)MDOC<q8atD2!wh$Jy7Ct*ddw7Hje9z>Hxe5jg(*X|m;&FSMoUG?&s<ANH`$7L1
zXB5mQl+EBA{A3%1$6P3sho6sc|EnelIq=cLxo2MuCe3EZeA)c9&je7z!4rY@YcQ8;
zbB}_MpSVWDQ;wLxhY6(OJFu%TVWRP%F^A&;UWY6ihw%wmmpc5jyRsuucVB<!d_4iE
zF%rULLd`e^FJE**Cy8kTCLk*0`m=R;EAbvnVgZ(r_>9>?`2o&8;v9->)?|Et%<3G?
z()J8Mt^U3*yvo8ot;LV@Wx-a<sYZh^a!a!r5ziAUq$JRIBmeHjuHR${BY=f@u!-8o
z=lM7(21?}bP=G<=?Xk`W4sb~%_VZ6d4%7e#Y93LT)=B<798D=dz3yb_-m?;8avnw9
zB^>8;QVI20;Baxe*KWJRQK)DG3XgWCK&{=y^-1~>&=NE<nj{DefAlzad<^_WAl2rJ
zWnR0_rJ+g+W^o`aN*TF0Oq+FQ;^U=PSbFVAqIT{?aVzuXA<DInF79l5tDyNz_U<~c
z(30sVo>ngsEQPFgzEyWpF8KFU!v9;xLfCLPXfTX@EK&)=@u|)eLZWB{M;B?oAoi8u
zFb7?VI|csEB*c%gy?}w)!zjwf>1Sx~+q;^RBqEX}iYc~&sE865OwY%%UW!0wRAb;A
zpS?#xrhppJVh8)j-U7PD1O>55$I1J4R)QX2!L}#Pu(ejjh-FE|S^Cg%!_s4L@q-;h
z0Dk#Ae$tcRd=#?Pr-jI`KghAU;%84~=S*;c5WVluCvhL|NB$j2<jgUaey(@P;eIHg
zJU%7OVkd~NpI`50eod@--B~(qy(RT-B{!x$J~5Wafq~3AU1p4_bgh02URMeN)9M@Z
z?fxg)#TNuswd&2ck;M&VQhoboCL?{j2(^U#wf6ifwH#7}(#R0FO`Y3bl{%WGR?HE_
z58`qlQ<1a!;Bu_Js(;m4JA0y)0MCt~xm}!qFzbJJLQZGK4*oYQV#7@aDm>tL;gp8K
z&wP6nA+v@W^><8QZ*OW5{Cm662pIrAlT)wi`_TtWT-c>cPi^bj_Pd(pUBB0z)D8S^
z9Tdb3dIi{fW(pmxRVBgo!|XqH1~z;f7&*M<+}p%l;uI_d!Nwx`!N%^5<t4p&9Vs7j
zruBp4BH$+f(`(5+8tuEN73GvHU`W3nO^Z|^Z*&#OYL5^$iq`ksz?`x0?0tmXA8vfH
zq_?!3LvxlkYM(?Ywq~AIZY%Ll!2Okg_4na4soa?^(oF3AOUqcbPi`{R5VvbM=)tu=
zitb7|_p{vf!op5f{e<HEJUaD(&0U)lLVAj-%BlF91$5Qtjz1tAXzekjzJKqjUWczb
zsQs=&5~SreGxu%4KWxBL-)LaX3R%7oIj;Xoa74u6)Zqk?#L!TGudYJ2E)GW}0{k$j
zv}YtKu3zqcYPi`)kL)W<Cp$icHNRAo8IE!|NS^x^;Zxa9*uw$<&>fsH;4#goAbs!B
zO(!FFp}YeCd`siLQNU)<@o@jr6P;Dzx)71o(5{CL2giQc@yI5qLB$Z+DP-w4T+|8S
z+F^iK_+b<=j&*{yVKb|vGkGM28d|5funN7%T|lB+L#^(9YnW+QK%xu*s`4S21z<pH
z@4mY;0<E+aH%c+Q;JQg6_-9Sfrvs~WojBFeTw){o7#r@$Hv-l`mDK<Vkq5iB!y%~-
zON-C(YlZ<nySpbsI^3XY698Cf%w(7Z7u*wwD~bxKS*!GQQ`l228{*p?O^USnG=0y~
z&Wk!Wz-oG^AVu4ghk!nwy@K0|i5|T&VgwjqP0fYtNLy&mnEjB4*@wvq<Wsttg<Jh3
z?!URu4p4FG#|@1IEHkI)uai*tf@`=X(2U*xmHtow38M0DY;ND2$^jnA!2(Vb07YvZ
z?RJdo$>E&li8Vw+CAOJ<79Fg>ZiifJ(6~JvmZbfTw074US7UlQVHg6s_B-qENsJl<
z)##+(A{Zb`qW@^N`YX~ROC9{;jvY|DoNk9A%sVsg=kb1HYwF4wd`PVme%EOKsj-Ef
zg*$m<f~_Swd!)!U%S>@vjp{(Sacjl?Yi<*xeU!C3vDzS_x)T|C5pwnu?qk~zW-JMZ
zL>&O&b=Lr`XdetrIN$IzgiBm#)BrC~*9l~>3j`lg0=32Nug`8oYt+EUK3Y)`^t~$-
zv~t=1d35&?@;Ku^pXS}zhiP{^!-@KfTDAWE<{y9Fzib#m{#PGB)ZEuidB;IFkir0v
M5|bCL5jF_=Kh-V{uK)l5

literal 0
HcmV?d00001

diff --git a/doc/assistant/repoinfo.png b/doc/assistant/repoinfo.png
new file mode 100644
index 0000000000000000000000000000000000000000..d43ffc9f99bd49b7b801d32c81128fe8aa0c20ae
GIT binary patch
literal 7603
zcmbVxWl-Ef^X3l^1PQ?*K!5}%cyI~s?jAfyaEGu70fM``1cJK<776aM!2*j0XMsg`
zkt6T>>8|Ro>VF?*rh2NUp6+?Zx+g+IO&$-25(fYPJVgZ=t;hD^v7|gfeXPkbItm^e
zY*z(C4*+;d^sk@*nc3uzomifVs<K!s*v|n#Sljn=7ywXfDayRl@m)H~kx-$Bc053@
z(rRY8@c5=ILi%SE7-IMg*ctUB*@j)dYdqz?8Dbn^l%gZHKp|}%E{xC^BHbS+0Aqao
z43%jHVNyEf_w=@5@VP!^KAw6JiDV;>m*8b+?Vz=}`dL4W-<JUw-4SxJorpdWefVw9
zCs}Zta7#;xilZwLDg{w5(74cM*1048ABiIsr*Tkc$w0LQ3svoHX}n?_R4#UMF+3Qw
z4;+IW9ayc+v*@n1m;>z}McX~xAtwfQU{Ea42P!+|UsyL&q?0oVSyFh#crmECE>LLp
zpN{D)PkZoiTW~NxSG)H2?k}Vzs=SWpz?d<)IyM~5<0}1BL^>Gmgm-hoj&+|Eu4kuh
z?7$-GB7ej1pOFy=W%aDi)0U}?dV+8M4TEpS41<Ekv7cb|hP?0I1-!3KdTT9kd$(x{
z=lyAlSyw~485D>Ba(=GmWvbT3i)AH~0p$&SVDBC&_9{-2$l@KPX<mRdd(`2Ji}$`m
zc+c>6c}I5IXTssu(q+~IIK4lTqE9KL=>z<AB=-T}b-GZ-E*^n1y~Oql-(|MEs}*Il
zH90}N6Lf(+9x^CezV^%C9cBXV{q};|PP$ndEEe3X(Q33ha=_O$i)}GL4;xy?MiNOZ
z_=9+1A$Q(DLW06^D{|VkeX6`EU#r_Pom<#+irvRXzs$sUc2QU#3&^3=LyE*){2-dT
zSBBpsufF%hRl4FQ9fNlY<SIP<1SWqb2oqGfg^ohYlTYs8%{~#x`U@Du!I&4kdlSgq
zaJC1V^4J(fCz$Dfi)NsTQ^bTR2XDw0y}dM@i|-e-I?D#ttYSznVsY`Rmx#<7binOu
zl=~^C!t}5!R0SLfP*^nwW%R^1Z&-vc_c{*vFM{k<-(EPp09y564QBWsG3t9qeeA`o
z8>&+3uV&|!xhTW-%%n3<Iwp^^U?8l<_=x1{M#Yq#-)(;|eNY!|%?WNUEl;mc4%l`4
z0iT2^w|0-h8Pu&VGjOcv3;4T`JNpw#NSjJp80TXB-IeH;gQ|OAuCoKmfPLM{mdo_l
zB9p0IRX}0$w0Q|L-?)CnjA<HLaQ4#oj_au_aJHDLPhp7gJ#WZP=1X?zC>-3jd~G_9
z@?uH71SL6Xz0-b2kYDmRYdlMkY@=_$*=<mX!Lf+@j+h!rEPlG>(F-1+_BlR2)ZQJ-
ziJ80clSi~S#b5o^X`uvMjpey>$oESeu6H}db&dZ3OOm1q$A{pKZ$5=(&8?mDrAARy
zl3k&5{j#O+_{OmhzFwd1E8_A#)u@)i8PHTm6Ualhh;Zf|nHxZwG}E~|-hkU{tVn0s
zZ5x3zik@Lh@uxs~U1p3`SQSJrv#G7ds{NRH&IWPMB+O#9%RWxhm{nAQ@^w~ej2#tT
z!Bm$LKc)DJWpClxCh{LMB3D-*gN<_tct9C9&Mg%U8DlthST!kmvTAk=u~dM<>IxO+
zWTJSuVa*rYzQ#0hObuq7oE7V+9K6Y};i>tT8JtEEUWcro8G)mVR4<6r&n0WaoW%FJ
zZ7N<Zc}L)Icu`PWfSXzE!m$fOhSTaLAyD5I04!mQ9=;mYPn)&WdS@pf>;mL3A%@kI
zC>+peO8W&ZDM341L@4UM6GOz<LmWW<YO1Hxx6^;KeO?BJRfEwbxxs7a)Equ}ewT72
zt53Lry|*0Rq<cZT{OmxE+&9Mtj>DaHV`;qdl{=W82|)`Au<EIt(Z$dF(b@L<-%alH
zMYr4F=7&<2d9mRUTV5zsjwW->QC6>r?T-ggNqQhtz&lY6jFqLEZxu(=g?#-W#zNMM
z+_My!_Rp+5rGQSJ4&IkQpdF}TcRN)xP34|o8Tam!*>kL)2f>(24pCPF3WM1wDCyIf
z;dv_W?!5LG3685H!kwNjE|*l0)FQgn_@0&B2h^%OY}MhcSVoPK)l+m9Orrze7x@GV
z`Xe%i6e*;&N{H57MWM&lNJ!CBWZw49vesQ3^n$0$8D`WKx$pP#n%f(4lQkc$HUH5a
zKur^`r38V9QAndLf6&e_^RfmNX_1<-&Gqt>FQb{WHBd^|^h9eh-6o*KOpXSQ7jq=d
z9vm`|d7%nU>S5)!D#4u|v<xbnvlPU0#s#Q20N7Znxet9nT~bowkiH021rv8jCi?H+
zt0j3Zf2&)3gmrp0@PXF#rG9w6YpAISi8xgm2%Ex`F5L+Jx8-ub=Xz>A!<Rfp<zAS*
z(hfIDs>QY-{EyAQ4j$1)36C{#a~~Or)|iWi%}}i?Mj1MobI~<MOotmHt=E<thzzLC
z7`8<*sQPU#z{ctAuH`=pbC!)%#X`~wN6EpOZUa5`vDS=ob>9dA*EPz4Lf94_0TfES
z0F1w-gK`Ob8}`{#d8M{3EH;LCuEVk5+sUC;ofGu%5V}C@FQ_)}GcT3kL=7aT#;C6Q
z1uGr2Rx>~cCRWFD8J0RIp806rRKp))k={N>zS;NRr?{p#j8H`RP(r<jPoC21gBOMs
zHM<&~oVxuY*ih~NnQ!#qFUjX$v%OPM6Zlt_%tJhGrL(`uD8{1ImAGNwkntHjbn~|!
z9ek?NGA#6?+r{Qg^C#bwT593wFs&bd^XJ|O3sm{Pm*pR%f7C2`)V!E-kSx$7=b$Nl
zU)`~B7R1-4d+NYyTH^ua|8}U-%X8M7o8*U1dkKE_ZxiZ!%a3qFgrC#G^_~B2-tvPm
z8d5S|>cNxV`j#cZlaAedO$Jdo%0tVITJ{&`*fQevLow6lcV&tMJg=i}1ErxU<X0}8
zLS|>{`UxN=z`{B-iwe~hT@<BHauhcZyZTCC69xs(gIEbtdxqrEL^WQoVH;o?$(;w_
z+dl_1c+!(D8c^r_K%Y}T+eY8p$Qey!ABBDd&<h1hguKTLV!W@NLehk8D(Nz=nGNZp
zN%9r*t-rd&;mWGd9m{+g`FeF!{$Mv<^GSs;5EJiXFsyy<i<I3BDICOecN-G6X82?h
zRuh&fX{Xz9<UW(GaRH9rLq@W{PY=(KZS-UIvQ6vsiIU3jzCTWx%rd%+QBMFpW2PA6
z*5Q48vy7Ze2Sd~f_DeN>AXtdYKjDOy=Slr<;sfkEW2#1izw8a#T%Jf=6r)bDnWou*
z4AlMLFOzi>2(uWF!ffdCe!fv>;i(R``s)#deRWT@72IPlf5xfPt=~i0L)Oh@5zSyq
zcoJ$YuK!$EC*qaF3$8iz+0n*X#e6I-BT0tUT)rO9q-!s;dNl0kp&p`T_?HZuDPJ{5
zj4f|rH}OiAFyS6ZKJSNb5NEvhqQC=|B5Ly|rG<M^n>m<&%4PYlPSG_8rSSFiboMFI
zT#%yah?)n@vBtL7vy~9C1DG($pYbihNeH;t5oU-X8eS2h5a9^IXt9M%I1gT9p1Ry9
zS3L*$_5akXx%1?U=d>NtNYM|x_r?K<=GxKE-;}2Ua=MU>`dUnN`4%J_Om~DLZPJ^N
z#l5Lq4YGtQsMr+fW?1pN++Wv`cgxl`)O`1}pL227xw-^{yeP6kkfU<CPrz5R=2eVV
ziRZTVu&LmNiIJ6IWWU34x<vADOYV&MNt}=Is;AaLZJ^jTyZDZ3rz;I+H<t?b5M+7U
zT9ydWj>s!j4Y?2<{aka-(&Cm7WKUT|Nung#h4J8*g!fCu+)C&u65ftTZ?n*;JW?7e
zw(LOs47~m@)JZ4(yFwc%PF!>|qiq=rThO;UbWE;uYMTud!T@lUB%2rUOAS^|SsH?T
zwdEJ6F6<zPO>JA`NqcO=kd2F{$no+MZYnEt)jEU6QGT<5H)?ZiLPg0ex(_z=1l`*P
zO%5k+v6_ZQcQ7-PRX&uom7kSgmOrAC7W#R?R^I0G8Xq+nSiWyqHj<=67KgdNSwa8p
zq(1yP=51CGsUC?*mL8Bc%szV+V^73(raYu64ZPVHW?ggtxWHHYVa>hr?Pqut3SFl2
zUmFq=QZY~<(IuWE%%)if7W+mQD;qyc70t0FFDi;kvu1!>DTC*Ntc?|f(OFB}{05)B
z1CD_YGGp61z*(X3vqUT1kqvRp@6Z2yX3Ba~9A?dfy&V`F`BgTgx#9iPq!c?rHm;a7
zP~VRQL>W~l`Fd&^W5mNsREWht2;%{&0xZezFZXOXm*u-=<K7Kv&SFb-jYSA^#cGZu
zuUvR*&0gpf&f?BF?pc4*@q+TlW@iOp@qiX>M+c+>zjseiDsFNkry2!K@8rkI7w(IS
z&$=TD_mn^CxuAf8nIOn2F)oQ@D;H+6OnZk$HHpq#5h||;mE=wG?<$+Td0k$Y%Jt$n
zm4>PHr>?>ojX^wrX9Pf&<CckmBj<e!HL>^iGX6D|$!8UM;viIDJrqkOu!`rpgc4YH
zG@T}u9MPg4FUvQrEv~-;@|3=NMg1;N87ihbXGqV|>~eDA#o++Z$}$X|Jfzo0Y%?9(
zyLx^Jz`3a5SMn3t*FQK198BJ|;<eJY#>`TXqUf~J12ev&2B%?Hy*!<ZPL~c(`@e#9
z2Frt5$?^3ko)Tn^Tmg;#eWL><0!Dx<2Hl>x`EaPjA;}l4q)YgO1!gx1{O;Jx`(C&x
zS)lkH<A4z~=Z79c>?f+cg2x`9f0PB{2_lr;td1A#!lHbNpRvj=hnEbyJ$*h0S4ONS
z#tqBhr=U}o>D=Oi`kSZ4Y8+5b`gy0b6X{0@!ts35zL^&#N^*D+;+GgJ>@_pRB#hT#
z+b5keJ1EX2miZD-ExpJpG`nMe1aCZsHt)mOm<0B$Kd@ote1NnBffJ58J1Xsz3u*)s
zWc=91-<6tq1vCdx{Qjl=GLvI;@gSTeE6CHU@{jl*?C%<*u3URBsNN=>kPjZ>*c6@S
zpsAHP<e0_SM!tA!J;xP$z2p0;r76uuQt&ro;sbnv@A=Vd^Ecx>+et}T3eD|F43fH=
zMq+jB<2;3CVs^=AVd*bR(NI{3!T=*o%3iR!A%<;N@PmHMJEjBbQOQBkl~XUR^yt5w
zin%vM0^8T)5=gSU92FNRIGF4RN3t!8+vPj~oLqpZ@%rU+A%bw8L&Z*X4YYFfZb>;A
zmYU*dt&+1p&{h$9*X;Mk%n37XC>r~i<$B|&MJa*5;Fl-;I;;}l{nYYXh9wd}jNyh^
zmi1jc&NJ0Ui8-_T*8pCA0+-l+O0wpNPB}E#<<rn=fbr_<K}-cU3Lz}w)R<up#HkQp
z`A$I;YsYR*qUe0Ggy|j4WW9dbQycC1Ha-+%U1v_ru`EVN@ul~?wrYNXSDSijfBnnJ
zS(bvI<6aW1=&C%~c!Bgd=zwR)hw(hq4sGU|%1=1k0wMR+Y5%{$HjeJY^5@CBTT~fv
z;pB(7VdD)SgtI=LsDOd8E$Sr{jFlVdc1!$8HZPcI_V}UUcC&>-@mMtX=R}upxe~bh
z`%LnK0{AO5TM_bLf>&9(p(l*{;C`oD?ms*?xt~Hu#WBra4*;0etbGB#&+xy3D9BCM
zX5K1(%jJj)tD}SqMKE`cO~o(LKS5#BCW--Zit<KC_hjQ-j6%AN@O~uo=1zGFCr;?v
zNz#l7v(tv<Kkt2I2yx`+lGCkmZ7J86Y%kZZpL0N4FjsfDSW=hw7uA+HD8tRrM62+4
z_YtL*lH3TuJ^Vn7Lm1pX#Fr0Q>v7QAm%tGMCsLsRB{1mVlWAU?>97*1a&9_71Cltc
zD>SZz0=kN_6SJ?o)Lje=41}wgljsuY-x;T`CWA5LzX)OYbZ*Xd<H(Kh&qr+UH-5l-
zA+aX<f~5F?Qnz#Kz)sg)Q9gUrUN5z4U@him^5E<#DDga(H+Uh-g=i<@V!zSe{qgAM
zwOe1eoeWjzVqbd36GI`#qr}O@=L?y{xS}^4FJG~<EAFeXq~ncXC4D^x&cRr3-KQ;m
zk@DWdDj?R-a=nQPrTDm_x2{GLqP)63YE9WK9}X%15=1(Xz`nof0iQx&GuGm$dm@<1
z)j%E`uhRC0g#M=9UOIZ#m+uj1uEmKh{0i02d;9vj=)Nt}{w#^S_2xzEji}9kVA_m%
z9rgGPuJ-vKX%sPGCrGB_J@DcrDA=F|jx7lSZPoh2yQneMUcpn8|LejgUuxuxOql=t
z9X#ZYk2_pVoMK_8k4+*XCz3|ndtO9Mh_&ozRgKm^a|?K^%V`yaIyQuU;)PvR!**(<
zfBTUiMO99teVeRJrhYV()1IB=dju}FviHO4h4k{Cb#!@MugJtJwQb%!aKQ`6WYs=@
zNuPvP*kO{QO{=gHDdqR9z%tJQ=52!cFJVVTwAj5e_oDOZxA_GMh6GKl)T+y4e^;$=
zZ%)*BB4%sPZVKFW9_Q|WBHRvhG~NsO0*2i^1;uhyb~^Pm^rC1mLS^E3nf)`k2Z7CF
zGtKD2PW@;N3P{9z3$IP^$K>s&d~P-0yqsSw+7EHbMgA$}W@q>nUYO@8bO(^FL~Uc~
zXG-7GsSU^v+e04K8Dr$})_CfH{i6)U(sz%9Kc!Tb{Xj2Goyu>JX){*cJucmm{v@^x
zYgjQ*8JbJ3e<z_8yZ>(oiTt!*25E#H;-|=*wZGhq^X|dPkAL!cGJX&~8fE#=;nP61
z_|~0_?j%Er@rh(-t<WCdP?~JOJF7BgRqG$LX<lk=YbS$`5spwSO);ZeF#ptz<1k+p
zlBx1Df9=kH5!(2CCS_f;1in}C=^*^(>2BXQ{vvZ%n{1x1!7HwZ&FnS*wmx;TU3teB
zIzTgDPt{Q1#G0Y1TcDL57xX4%VRuXFl{u;NH@E-#bVpO)T`<|zVuly~G@SdOVSBik
z@l-VkX;tsi7GsE}>^WJXbCFn<Ckw=am^2#FF>uhoDu_or0w(6u)$}OP`PO-oQOQwJ
zvEx13l?FQhX7;6gcw$Um%*=I|T+p%1LN^ZeNE#DS&MyJo!uR!d;#R-ApRd4Kbvv#1
z?YKjZVxs@_6%>5J4T+(M_+oiilteHs_(-5LJLMyRF$hsUm9{hM=SkNkN=ZNKV7~Wd
zx}A)yQI`z-bDxavnxK}?p}((?J`bDu*nEw)X)b<##e6f!D<trE&)g!*z*1{s!IgH}
z!dkB_Dp>mp`wn>{@(i}AM&%#r1Y15YL%hC8s_<9UAyq9oZO}xpT+Ew^M*IsUvOxdS
zBl^tSZ`{14(TD>KHD@P9A;%5t>yr+ZdRO}OOg<YKFoUJRPI~tVY;us7g1IS=*rR64
ziQ82#kU*6X<gZCv+v0~nle%_C=`QD!B>H#n!@Ec0ju5Wi&+hyBp|qcAvorNoTzU8p
zJ{ea^ROw<A1Gw9C6`zSgYWTdUJZFaVvY=#&{@KMSPLQZl-YShq_!A5=fAM(t)QT^Y
zpLKr4ZD1uq627ddmkMO$^c4Y;-8=1gh!#4rOKt>=mY)R>RWM_<ToW<9pynt4Y*!*T
zL-e`lb}y!DDu%xx_$xvr<s}er^ro)K=VYC}u1TIX<Kq<0a86DL0oia4HD9FY`!B}t
z;y>~0d@+8X%T+mmp6|UwP=j?f&pFZjC#E-J2y)GRVdFRn{$$qnls53>5_z({R=wDJ
z?|=42=;!?h;;w9Gzenw^N?Jbm-o?|kkd{Oo<ox6v?UxiC4cnb5X5i$j(1PNeI~l;*
z78R0%t}gfKi->!&%0t=8KP&8v&ANP72~!?IT6}5FZ=nxNBy}MKt4k{x!FL;@2s5S>
zhz9yrsoWo;h*{MEm|8Jo*3<{xhbgh@TMic(t{Y8+9hq2a#q6I#7`r>mA+G!^oMsgA
z!GAUBTW$lc17-ks&MtMX@&MIS@6?|42(0c^H#0Y1%TD1c5zG4@3gQj+uX-{F#_MM7
z{noq0*80w-nSkbsN&jWnUew@5h-ZJLeyQqUgaEVkO@|Ae8Fv;qm!~?Z+tBPkzSZJ3
zs+qsaL@$#mQmmRCj8(bX)zrFUqMuIgv1@yTP`jNL2DpY=;;pM5?(<5u2s>OD%=k0G
zx$ez<Lxz@osAt*?`w<KK;P?fCVqCKdRf*}ZY841@5RwtD6?q;6aTIt{cd~%Hn5c0_
z=VgAeH1yovj7o8v25|al!1>$|1j}aHh}bAuL46WYojDTveQZ^W!Ofn2nS1g_%9!+u
zl>mEL?FU*l@jrV#zbsStRvW!w%gt8ec?ss0I5gTR2g+5)3w#`PC+r`}>qX?{Q7o2=
z*Bi5jLvqT!J(gdcQF%@m$spCYD$F|GNA#~J+QNTb&COVvSiWY!v>3NFv0QJUbSF?v
zcrv6GGk1cehG^399W*w<r(XQKfX(D-l;_)ZBE-Tq$^+Qys#Lhx`7#ZI=p;ME2)ci~
zFEny|?IGTA&XN}0XTfiu`**}E(DNDRk3V~|Z{PbET3icSe_v@ToUh&dgA;sji<-~z
zNhr=*$V{Y>^2plLGIv=>I8qHQO_k!L8IA5W17ZAhQ86O#D3=2-$i-9X!;p-VT0byV
zs}gWlmO%MQ0!t)9OF5`ajr;n#9y{kTM2qTo^<5htMj+Y;H@V4iC#%yHih6(8Di+NQ
zSK|U2OIH7qb>|=D1YTTDtvZZZM4E32sC`6q)H;m(l}3|~j!+p7swG6u4-&HRey!oI
z466}?yEf?a;DY9ZD=tkk@hC}~W|juFGzlp%y2&;)zYA%63s;p(GBCxRF8YOJijkM&
zXZpj#(^rrhNxsg8E24aT4~moEpDYqVlyBciy27@sQ!|>nETl?pw`U!i3a5W8A63s|
zMdCvayjqs2W8{oE+J5yeVK~xJpysi>lFB(80X(Bf8A-V4ibiinKNS%FnR#J6YdG=K
z%nV%5C-5?pGk{Q>h%Y``K4~qVBq3tLKrM87XzMvPA(QQ2#n&j}Aw626{40_2Sw;iY
ziD@9prePY4$k>h3W6`HpV|GeJeVZ#c>GF!_E(cqg)i$?1IZ@M?T7+yR)jf8R5w(b%
z5C0Z4FFx(X7*mnbj?ifUkv*{)SAllXJ@_8MmXVw+%ad_?Py@Ec_i1hJ^MfDz3!Bsn
znk;wb^b~seh;@3D4P3sjIV}mg2<!X%SHZbCW=hSZts{5oY2StrsZf!K*nP3B50mlR
zbGsX&-y{=BMPe?_K91Kk6E|)igQhDhY$<rLq5L}&Y6TBJdYlt-=!;(7y8Z0h^DGCc
zhQkHTu-4_#=-+xz-yac9G<W2#MpZ!GOs8%Tj+O~{x76P^P8_>O%37G&I^-%_-!;x!
zY1PGUHdx@iBvRjv@(p#;%X!sz7D!vRgSfv#u1?@+F!lKjIY_2RVvk)^VUA{SBGblQ
z%n9W6zr~@eqQ2&x>H>p#rk_cwv$9ph#_qj%@XQQ;Wsg^#8#?=nFmcIyMw}|+bCLgY
z;p5hO2SO!aSY{c%YZN<c4E8;=x|BGtw*MuZ!1<gR(`q?NGMJ!9n_(OKWmg050GZ0J
z=Z^=BcqR9Kw>K#h#v9m1u{&p2SQNAC`W<c?o<U`IE3#Q~HU?v+CUQ!M;7Bnt#7g`(
zg9pDIy!I=k1blIk?Wb`TyWi2Ve>uKh2X#XyvzE>By6l#es#f;M2F}6>)=TQTo0g+h
z*r#L8XS)=&L^QqMs#F-SfpbXnHBo$I`mX!-QR@}5B2VguWXind|C+q}KXQ5hFL4{T
c`GA&kW-0*xjq&yI!xd1JRg<ZfviS1909q3DH2?qr

literal 0
HcmV?d00001

diff --git a/doc/assistant/repositories.png b/doc/assistant/repositories.png
new file mode 100644
index 0000000000000000000000000000000000000000..2853683dca0090d5daa9df3e2a1faf4e59e24ffc
GIT binary patch
literal 63405
zcmYhi1ymGm*gifqNU6Ni0t&*b5=%F$f`pV!cMH;83xXihpmZq+DBZa%NJ}h@bhoh7
z0=sPd#`pXF=l|`VJv(vcd1juu^SZA)>Zy(z{T22r007WysH;2&08(4<_lTMlJhI`D
zg$Mu0?H+1B1c0h|TAT$1xKHBoT<sB1KFqlT?(kTtKi38Te|`W62?qcycqn8W0K6ao
zuxkzga%lj-;+oa`OaVMWX{o8E0ucXx^Wa6v;1L>EbpsFZU;V$IYQLircsZb<^6;ha
z?4N8uV<tPo1yr`rmG1*3<Lbj*lG%6D_BU#^|6Hr3pL(}&WuJN8+oFM@p7xLP7leuH
z`Tf%tTIc)qCcndeqrj6+w6&y)A<m(*Nv|pHFF$-rb5G^YO5b|M5;xN$b^co`Pv?|S
zsTJPGgC~J;TYk1m3gSow#<ezqU>c@}8Cv{fD(ta*4!1Sjf8suH3(!%9b(o9k3-X8c
zn~S+L$WoJ&iVjs~M?Og6(@5^OAKCFT42y%X(eWoAdC$c(DqDydXh~%bbtuT>2uekE
zSc|d7%)R}GH1vTMhtpP(MzTi5`1Q_=%DVg9zpLHe_B|2N{qx^-Z0uYZtjb<*F3hW1
zIn?h2yq=DE&zs}@1D>nnlvaBOW-@YW8CsNzUv9pH9`)gm0=&~>RGIuC(XON#ik~6)
z{j%zK4qadOpcyV!|3}dec!D7^95xwRs*0l3es5iIIVP(4qxO(IpY#tjw=~>Q$%%@3
zSUF)+tLoo^|A<|q?qZ~fY!Dx_7Gpo{>Kh?5lFEot%?BTy?OCfzBWYO2?`8{0Q88<Y
zZH?p|@652jw-wg;tgzpDf@yZh@pZ&oeMd1i4fj7i4NjPag2gU?7orW2)0K3LlNCEW
z)MB<rFYnWaghpwQMz3@zzz$mG_W4(*I?N%zozAAT_jWTkwmwPgJ24JC7|-K9l@r<-
zrW2z~?zRl5l+DqSFnr8&wSfbhppnF%|IlS3R{hTHH|?^{fwE54zSSWV_lCT<bK)1L
zjmUQMUu^(a@5FAp1uBNf7Buy54cV}!Lt<=y6SmDEtXy1wB2kD2eA#(yngBRDBn`+D
zh>$Kd+uPsRZ!W&Jua4M_SY3TwA1RO-R+w|^>W4WRyx9SNa(|w{YhjaGi?<*8t<MQb
z)}b^pfL2cK^<{CZ^WMTmkAWbh&^iA1#ASMw5l#C#hK;11{J~e*WG0^3GgrsC9V0XE
zO>lleX2)^tNcYJW>uGquH7St9_nlF?PA+?os4wW<{tmPEIx>S!F3i-YMNygOD)bF!
zxK@701N(d~zXXYNdsB<*5YAh41#Z-yON%nRB{Kev&8yKhWoB7#6^%`9mB?WCW5t#8
z#1mBA!+~?&O?9*B*|Nlj^Rk^dHEts=Pvmi4Kz(>=u;V%2A5EuZWO^Cd5ST(v(w=h3
z<tj}u__gQ&N!MbIhMTm`Jh0bRC3{MHvr?gasc|QTlSzX;MwKDb<NSwtSX|?RGq^O|
zk`j!zpcWKQhxK2rw-DObyMyhx#b_oXMb;V$_d8pl<=#5ypi+VoD1do{LkZMz$}$Z_
zp(Pd8-LCJCPH2&moPY)AUJ&L8^f)46<A#Iv`i=$u1c`rm6sbo%d^1XS*Z-|iJKvK;
z{&yW+{CeK^?CZMFd(#x}MB#9_-sWI>ti@VRh8Qayb2M8-h48)akX^LXU$v`Nl=-nY
zjlszt+>=Z!h;KN@HQ@*xZx{zpm|J2%+5JZ%Ukg;<38wRMgKldvbtdh;)5CL;n10g3
zJ2AAOP0xA*9*7&wZ}A?S_&pF0$d7Bdn${McNCB{pcP{msWbW>9bbY-fS&kkI-$w80
zE!Et$5nuGdaZk()t(+4ZWP~2#CJJM9KNE1b#w1o1Op27AwO$eel%<raz41}XNRswx
zIIp9gOUn#F6xepo@pBa-9O&u&88Rm`*V0F#)ql4=FMleZr24%)K=E#{(W8q(yQP3z
z?<6wB8BGZ5Fz(sbvz*u}jw!F3ctrq6h=pPMI~}LW7;fB|k2b>}BOq8;boWx5TN$cH
zHyGO+AcZSkhvv%u%aGZLBH~a8okrAA86#iFWSD_mr@g0k_TF?wF5#f%EKX;4tI1<)
zPA9j`&!b&QAi8_iRpGUek>v!_#Mftn^}R!(Bw-y88aRKFapP0-kyx#0mcK@k#z`%m
zPx3@f?axeI7@x*$#S>N5JP!7pjSh=sR!_5iXKWH`1O8Z=3OGeCnXs{$vbUux!j!hP
z$oz$Rdt;lpfCm|>N-j#tDF_l^*Bf`2$VkvsFn}p|E6LsZ(Pkq(-pL3M+-)8FOq6I2
z&Hq$vr64Xxn2=9x9L6-P#&TGwcXD@$HT$ho7lUgeeJS{WwYVZH7;(!?K!AAiJ0fes
ztl|S^f$3b>)jHndqD8!pXxMt-0OWnHx9uGV4pSK{y6tv=$`d_ICoE{=`zhy`#Px=)
zZ%xRy+3N_j;``0SY<Vbs>1ccD*52~Mn$W|XQkTe6J#7f=<!A{kn6S55jeuh!M-l>x
z{VPR;+j#+=hPOwf5oE06Z#Z@A(zaSR;ykq}LU|sPjT$$5(sarIBj271nzcC*aDHd9
zY;=^--HUZ5S(mmnz4qqSzd_H_ecTwl*3;VLA@F53Y$!+C=YSr4HG?Yr0gp4ScfMAV
z1p8?Y*WmIEpLDHLT9yRBDUPag28hW_t(ce$JU$@8@q|R5CFt=%3-R3BWJo|-#Eiro
z$Q;`A{hi9a<MJ;)>R<29=4!>&P+Aut?L%ncd3A2la1P;zn`vKRQ;r~Tfe$))pCics
z;4IE20`v21oTXSnq}%z#9Ec=|e@_v#;Mae9MhX9?zk=gZk$5yf)tVmj)Wv%Y$t6^V
zxef$hcByVu7n>=vKJ&9NSaiwBE6b=|YOPh+&iU+^n?N;RLnJD0sjveDJqlg6KqkqK
zuA;GfDGkt;3>$aO^7uFSekO_TeD_?H{P7ZZu-mxR3MqO9lS->TekjKsKdHc|Mz3s?
zC5LV);ySYwD>aInf=qig4g6Zp+ZagAmiHmdH=UHcE^pQRw_vE}udA8*al^+CqLKfQ
zk&gxtWE}RIMECE27J|o|#6Ld@TvwL*{|v*(HO9!biI0D3ZzWT-n^$S`^Cl0S&NbSi
zex{~*Y{hxzNV3PuB`1bjD4lGQMUy<R<l-_6+fV(2nDwz-MEx?;UopaU*ZoODxKd3s
z_?KPIl)%0WPfZhj=ISqt*Jz0v#7jr?5}ikkAR<#4F0D4m#E*v$`M^Y^tU_1=e%a*)
zuY9DGkmg>($$VC_zy03vpfHa3590P&`WGnCi#Jt+I4eOEsZdd3#+-F`5N9w<lPsvg
z>-%oE-(FjameU_RZ=Q$J0jbzXR0h&2_7?;5MSXU2s{?xV6|A@shC&26JN5sTu<QLI
zJ!5*B>|-DOqL&mpm+Ds=(NykuPljlm)Nfs_ucaVSywT#!I2he+UHzLY<01O+u(F{c
zAfEeQ1w}<a1@1Caq^0hh830;<mD_8N_%)JL!#eVKxq`NXnKUvuOVMG8dD4k=QUlb5
zALD<pb099fuoa9jQ$Nh{hNIpkilI&Z?p?n)s;j)bi>8al%qP1StC)&!hiP=c@8iDP
zzUy_)KWkYzT2NEd(l|maAJ91E_6Ymyd+V%-J6@5*T&*iCSwG-|yifmEzdt`B+%u1A
zHDLP{h@mFO>HFQ6)!YHgBq`I^XIHgCe&3nTnJ~j2A&I<9_^w0=pmD~7`Q1B`<-+6A
zc;X}A@W`yV=?5@IO~(w-oqD@(36qBC`3Og3vu)KOv@hP8s+9}k<7Js|O<e}d+&f6g
z)bZ4Q@3A%PbN3%m#H_{Aix8K?)?z}2wFy!Jb)_Ah=Pra}m7-DeV5xykbGTl)u#x{X
z-^)yOcS38^){WGseJWr~ljG*2pTrkSncW}|Fk_;ro=n3T`EUMWfp~^6+N3NM2Ddh$
zmI_e1-wtzpX?<Z8f12E^v|o8mKgV>D?mC^n(XG~_{N@KGzOt@OCST6YYCMGjW7ac+
zL3o>$6bbNa%_UpUnBsh<R!M&Y{)G^0r`^K=@VTA5Kx3`|7XfE35!1xeHK^KfQtRQa
z=J(<E3LKY*N2aLy=5tOBvXJAS(^_3N$>m$w(`GZxYXU$eiJ4dS4V;+)dxC20Dx7h#
z3{Ff`%%Iio)O!*lA-rMlbJ15()idOSKF)@EqWQeEjOK-;v-dJ2K!06)o*K<8^ba-Z
z>oQ}%LO2{@_Bb;g`@o~yL{r8I!tOc2t?0y1`20JyWfHdm7K2GtRWxk57W!b`zb6t5
zgNmmW8*TEFi>d*0iFZW;MitX$h}ojHS?&h;v%=jgxoZPk7yK&F8mEq=McM^A2uX;c
z;^3L<nqwk10{OkE8mM$wxDsDhq2dzvE7)9bl}eLTuQV+@z=;xfvY;o<!EFNfK5tGC
z;`lbi?fF*W{QIBfUS%o|Gav+E+s&=C;!(XyFYsuyGCdy3WTt=NW9VS}I1x7QOC*+>
z5UpvU`x|B`5<rB14fzd5oJ@S|_~@tfW0<Si*`>S`bz3uYtt_?${l#dy+^?W@?<kk(
zJx^FnvLl|>)K*_A>mkgrQg7WF<~_?D#|G2I1H9~uH}D%@AJa~kne6QiczntQ6>_FD
zwnUE&EjMN#{Bd~G7j4?K`c6tNl&&Xhrbe3*U)%UME-x3a$FOK5`CD3V7w(o#SK~3k
zl<*FJ69Y$PLF0q{Aq&9M%L_#u=Qg`^Y!jfevS4MUYqzz-6NqJ|ErhDx{NGNShaVOP
z2G)KW=uMMcpgnXIF9ux-&MV*xldD`{00GlHL+0i6lcTv6_%wDso1;@d?_4gO9<2qK
zn@*hA?I-a2c8dvAP0^5%k=Y^dLtGB_y%|Cu;2K#uY@WAR4IiO%q*HY>v;YR~KtF$v
zVv)TRa=}*3%I&hRtBJvqG27-Udc+RVY=7&u-8v_JCZM%dVScvfQJv^sTjgX!i_X<?
z8nm28M{AR@2xC}IrIXXoO>;YBE;m=spifGT?a*y)%2Ow1P;x8>$6@M!{Uqh1%Zr2k
z2hV9)Wm>sKNmvCT>>A8H!4S&;0}Rac?!{i6<Fpn(Q+#j0@)xSqQhf%xM(;A%fdZ_d
zKG*mDk&f{tz35|BI?A~){PGn2D=#w+SyM3S>oBiWl%Y&g2-+N6eNT(W;S>}XE+*Wq
zRW##rh5qJl4Zum5LGq}24BhaC`xST7Ro_Z_O1ts<%t8!3kSS`5c8FAeNJnDg$B*X}
z(JVV??Bsd);7P99RXM4!{*_8LK01as6{bzDEek61wse%8Xb!UUiq`T`aZwTBWE)fe
zG;A@Lg|@WtvSx<)xsLquqb6TX`AK=gYmn`1Z9fF}39#hcI=T)Bo9$L=(3l}2<XD?V
zmxA(%-tzAo*UZJz6>@Y(OrkS&y{mt7GE(-Ki;;x%Te~R;oP_d&S?j!i8el%M=gAw^
z@iW9EUI8?7TKuOUsYQn%taNdaz2*CJ%tI&Rv2^UG_7vRYq(}I$vT+8-ax){DX;c;U
z=+6*8)v(3>E^cy5ckl}S<fcF6-SYKsgSW!sUFNsfu$U$1{HxUDKNVShTxP27TJPwd
zt5oQ-+e?7i25-iP4{5iG%h4viO~h8%pSif`hB;1h(ok2%o+h31GYM55@Y2=ZD5Is2
zzgwh7YZULb!1E7yjNd7GUHf1ZqMDC+9gOof0uNn1E$x&(@=Z1%9$!*iNnc`Y`^;??
z>C(LL`tP-hOTXfmM1r@yjYQY-5->rQ`~Lq(f?08PU;Mf#tADEOT0((_*IILwr(>x9
z-znzZv}`|VY<vE?4<}=f<&GDizUr!=VEa=HzBm$4r{}d6k&7w~p`cX|l}_2uNmxlt
z>{zjYKePi^L6tYN`}pj5)Bn=fGVOH<e7?jQl1_56dFiX`B_tizF|y#{S59oDWoda&
z%ThHX{#*}yw$Mh3#+zbw<fDFsd9u|=MFp9g*-It|O|36|r?vE_#!HN=EWi1>Ee~Z%
z$4$O`KOYnypE^C!9e34mGIo#Pv02Vw5^0g+B*g)o`s3T%hYq4mQvHSZ=$a$z-|Cs@
zWjo<F4{mh482xtVL%HUHQKw39aE;4i>*(PUGKB_pe5?{3#e0>y>-_rpqfP3Eo>}r7
zM<Wa(BB+&>j&D9fj+Y0gbngcV9Mj#jERJ=&ZEZETxfi@n@jlaKrsCZeX2jS%zOX9H
z;-w5{oQ|4(9WP}V7oeaZ11hUwgExq=*k7RRl$4CK;~M=u%<nZzun%=FE=F=ExXPp%
z1||2Nd{(H<FFgC5^q$sk=r}uy{cn0~>nUe);@0FJZXVa>%B$UevVMWBq@u*OSL<<U
z_*W_%7}WG5k;o<xtXT>`!BK6O&PS_vbQN!C(nEsR8=q0|l8-LVRGAzXr>34S=Vc6?
zH3nkDmRzRj40=w^+5$1FVEjl)HECRqT8mda%B@a{-E%9CN3N4Eva%kYZN8tcF)ZSB
zUTp2Ktx3~jjtmoJrAzLY5EHW$V}rN0c1ka)Z4`aoS>Jx~-MQH1AVJ}md5EfbyJeMR
z28nR$`8Kb7{41EuqZq+7X;|~Ud%V11Qi`IY&;I>KCzY9;)GgAZdjGVoo~ItgnLG*r
zd^D=&*D~6|2E@C6I**70bPw1=Cc+}WY@V2@{0SUxYL8|S2|gK;7HPX!l}ELDY-$DA
z+xOM}p80*c@qG$KM@a^xY4I~k1)OZg?oF4aFV1f7K5sShKFxH|0i{w2HXL;RHc_d$
z)2@1@^Igd;50w(dad35R*L4lt*Q?-kaagRhT{y)$SoE*np(mEjT@PM*haq`65oqb7
zrLlwPJXq*kb6@x@C83~DI=OnWnV4t+H;uRWJrv6E(YbphLAB)0CNh)zYGnd6vSRX$
zHh+FmkpRGY8qseMT(u<@)*s`$eGR?{5fkfLF<0(XR$5dF3u6amOpQAVw_cNRVq!9I
zkWoMC=j>dLMoKRQo}?mhHma(WA2X=C;v+l0+#*Z18GECVoLKOPzaNs2Q_~ugH~lV@
zreKj%ES++pZ#kS4nJv%4%DRn0!Oj<az~7DoO**V^5w*A1V%|ZT+^>?fUTRP?Rc<mj
zH+MOO(9HFdvt@U*TKV}NT-_%By7+EOw%8tBXc_TrE*U|DiD-+yX_m0^Rw==kuMK+l
z=Pxc=9UY&D>`s-L?n&N6u{azZpBi&CH@B_SESlcQ+!vK8-o(0EohzUpdn6l*yIC12
zCt3R-H-^rgM|V8^;c-K@K|)Z1*FY+lplUnL?*xZO`ec{j3z{*$;>rEwKpmDJ*rs=m
z1o4ZB-~++bErDj#!*@Kjvla|gj;M?Bue*5EtZt2>f<)NvO5#c+_xwTUTDHBTWV)>@
z`&(ycXA6rjkG`bI-T+PKaA?2zwrYge?6rly56;$UtZY+pF|3i1r{N5zyamDG6Y(Lz
zte%}cBxRx2TK^vYnW-sxT}B!baL}{`Zd0DSL`h}6d3%CJ-_daQ_0|9K^z`&JOWx;T
zdo({MCnu0Fe_yX$$Lg)Gza<h%jD}j{Ei{&|L!k)Jt})Ql>rDqLJg#Dj7mKW$9p7J4
ztPUz_Xo#0JHQgyAqU<=P%C~g<9)0%+Y=ujg8WH>LxS^H%w;qO=n=kj28U*WhEAR&F
znSH%H$lN%7!lcaG>47=<?Nkq1i_Q+6ENsL`TzF|~rrg}3o41-u!IB^pfUw8DY?VmY
zIyhs5n=VZ)a<Ny-*?0e1S$P=N(PvwO!2K}z*34XQVP$lg&LQnQ-?FlpxbhGlM?F_t
zx8L$&$P8BJw&2eYDXx4YEi*F{ly7m$y5*f6zmrXE<acegYHAAzYw{x5Ru{K)IUZ(4
znrxG7O6)PyrH4eS+fo<$K{hR1I#dB3jaB1~B}bk3tIIdI`e>tLIoR1{T`RkcdkQ4k
zB-zptYn5!xp*6Yxa4VJ>alSM0w?{cMF4@FclRnt`UNKu?@AKp!_sLshhwpbUOErfK
zkM~%(hA#*1v$3)1m=d+3RrM~$a|tR2?%%%Hci^E^JzeKd)L0`f;|B;cr7HoMSRW{-
zm`m6M99t#EBmeg^hpx`HaS8G}uw=0aJe#p&5i%qP;$|0=ij2A|a&eVEnzj4&TN7IO
z7Ou$!pn2o8zIt`E!Q}4g%-tw!8Tt0(d4Sqt;K>kygU;L+Xjf*O=cvCsVaP8k_H%;c
zyLP-bp94hnA@tEM^+<e3Xa^6v;2E?)GVUs$L)P+}o1i}KJX1RAVgev8iwZ6-+?wRs
z61_j5XNSwUbphzLC>0RxLtutn2pA-cw4I1U5}jtMH@f;?%&{ma+`vqwX%%uzUv6QL
z!S|%jmODswb#;|;iI3M(N1wG6-u8Z%AX_?FpY0If*=wcr`l$NgL|3}J(?D=)C+@67
zuL665PZcrQ-QSRu5Sw2d^)r}Zsx<FdxUc69H(@7&;q9WMUd2+Q=zvcOk9nv7)%f-B
z)v<4F1V@}Kt|diqrq#`Azqglb{;cu=4`^7{PVl*Y{wQd4G}nCn5OVsPp9CmM#$G<f
zqxR-v2KXO@`*3&(s;T!EU}^7~Ai<^qmJ-HPGSrzsa64=<)+b#qyL@9kimE}8vy$gQ
z{xfmbcJub$+$k|&>U}vVV0(HM4vKgX&XJr`nWMhxhR!(7dG)2ucq#q|^q;pgV%?24
z$V`_uSvaZPCwds}b*4u3K9`?hfYjrdDj=`0Zm*2^iMZMw3yi!(A2eV`a`6YjF8pin
zrl<iWB~t{_H|5^gu^-xJTAd-21VE((Rz5vGbvZEAhhg0@bEpH2i#pzPU}SNzP0XqH
zpPQI%6`%F-c#12e!14+Utk+%6<ee(71JHAdtgO_3uD^77d8uA_|JHcu9qE{wMyR&-
zmY-*F1n~%KCU!_o*%^x}oQJf>l`ul@##t|2%-z!bnD5<y-0^oCD;B}!*-W48l;DEe
zTBI%-5E}?jWG7t;htll1uG)zA<2_-OJ!$}lvuj}%)PFE;4|MfWhrQ*~R%N2$zfQ*=
z(IH_u78??rW?`Pdk6-?<vzh0R#zRjxmtgSXg~#s860rP`K4@EESeJy{deLjt;9OQ(
zirvn)0`jK!VpTg=yESuyv3L2$W8*Is6&2C`%I4-gz{SPIQz`%y5mH9Rc#(J*T+x#K
z(PmNZBpQuYd%}Hmbaab)Kb8aU4+nFof${MdWv_LgHP-Bb{`Boz$7CgJTD)}X$5gnU
zKeU9nZW>57-CKknOb<9<_^edDH;<_i&<$z{M(>L6-vp&|?k2nlzBUMYyPMu9c)9+F
z2m05?jr-lvDaNf6L4|N3`yH|F?t@qNmAzHeMT}*p{jux2EvT7l*;X)I3S(3fyeio0
z{z?{R+Kyb!y^p<Is)yn#@7L(Qk}gN4E2<TZSLv5(riu(_%BNa*jh540`B9F4DlVf=
zF<8~UGo1Flq(y%9%S{4-@CFS;caL4~s@i4T!kmCAqiO?IG)j~Yb`*RL@QjN~TvgfK
zmL{zQ`n9e{K}IO3-)>i7EJxArgelx{Dx#KCK7-R*`}`7d`FItv5mT9q4Xm#?fcR+e
z0mk^%&#5^$&Cf?GH%17rM+XLcl#Y6)M#4<)Q+kGd|CuZ@CGC4rTAO%cGrWdub2ew}
zA6SeryOykcf2II&hE;YXHUyPL_GaY@I}@!u29lA4UhCU<y;jopKeBiZ7cD9+M#?ZU
zAX@aK(c}HjpuwUEU_Qnu85ls=`mXCQ&IVLYjN6(&0mG-L!|VVO^X;BGTIv3@SF|L{
zgcg?l3P=oHajWgoz6~khaC`W?_*?WQY5PdGh*EGv)p)HF!|CJwR+!GABH2E--s_y_
zKUXEQXy;bBw+63JhWz>S$F5$mVu#K)E-U!9<x$oMmF6!Ulif+qyLfNHyG6TPL*h{h
zvE>$T*pO|BPT<Se;|_=V*PC>VaG06WQbCT`nVA_~m$tpN8lMHYbB_JquP+1I+{7*4
zqPvi*&D>G5?MD9GpY4zlElTi4hVh)3l)=oK*GYi0h{T>R6^s5S(FA~b+;OP1?Je>S
zDPYqd!0ipR6S;7tA&G=X7l#<6eRj3}BM7xq-iy;dCcvEa02#2qbQgi2G|uTY27trq
zKq_Mr$tesr*Co&|S(nwzB3MrfwJ>meIQ^!s0)94&3O<(yz}nH}If{r!!H5S`MP>9r
z$N(|uGOR*NEBjbur&;z3qa5nn`H=gu&6$3S{I8uiZYfm#Caq7W8A3!Ra&P%XhdxH}
zzB>LXKs;Z$%dNG9@5=W<GDNvfKpmpzd>&^CuTR*rYx%o}^E_~oNaRnBk^sR)F}i|9
zYj)Dk1dU!!PSFKcJ{N|h@Ei%ZUV56B_g;B`a*D{>Sy`693_vaTqTp-JFD}pUN2}e@
z&O<5YKv=&uVGByc?7P5>Uca82oRpN1u$Exg&6cZsGkLG!YsHJSy1LxpGlNcL#<x}w
z)>v&b>~Y}V6j>)|tfJ<4$;(^N?ArSNe*Wtv>l(#0t=B`ny;Bk4$AN*s@~_W}*<-zG
zsu5d5**;BMW7x?O5tFvlu7kA1#FY>Vl8?^sqi>xwKdIAiwYIkQ9sVObjV-4TGV$J+
zt-Cpw8W%$cMynMK4L<0F^NZs~$LZ2wR9OCZ#1m<Dy3_z+N^-#~G&GpTa_95%UjCP&
zG7^Kf0d$OvZZf~SHCdE<p+;#N@|vyaw!2eSsL7I(&7pDo2`8z`&7sU!z4!FWsSWwA
z{<fwyY?~h+uff@4&i3d0j29`oF$Tdk<>+(WXO}No4`l1kc6d?QP=OrO=Vw@()BO19
z+Os#8!=-UDu7_RkS8vqN@ttnR06duWt`o3g;CnWigup3@oU}uoRNw-*p`Dz=_}N$T
z-9Fh-{a-%gMyYZUES3B2o!5Y;yIR2EFckJYSf-x%NAsnN@LfM25Enj=^Uld9D$ROT
z4M2>D#`ELA$TTc@zw>4>QEk#kPRT<Z_Z!}JzbB=xbqbyRF)Ii;h5<%k9<FDC-27xf
zNPoyoo6?Waj>k0@XJRDF$C%;w1Mkx4Aav)5Bbc^)FlMz}HZ6)gHfqALyv-o^4Kf;W
z9a{-?fa8V}8(`R0jHAiq^L`QToN4*S`gIqW#+4w5_xbM6pPRj0MlOn^BPA6CIM!*t
zBAE>Gx(>(LZom<1JAm@PNS&hq%qL8Vy)8wSNzc9A^q-U+aaX{xmh8jk0c7py4aPPe
z6VLIhhMvn$cTM)d%IRWd&CP}V)|Rm|Rk9FUTylc|SBu?JRQ1v~CmXSJovdno_ZN0J
zJworf8l9N_d@>k-S}st!q|6xa*G<6?c$@Va<TFHSH{P8Wbk*E}Gqa}#<3ZQt9Rf1y
zNM8P8LkNi!2r11$pFhV<7mQGmEcZd<im|VxC~|cJa`spL=-4bAB)2!qkS*`nHE?3>
z*mQ~CB0NrtpmY24y)_;`lV7BouuJ^|_lNA4qwm$l)q^3Q^Y{&imIOs^E&?>HztKWC
zVCaQzC7e`fC%C4SEyGcDN-%lUTq3j|jA&Ad+zzqYVI405-hTMTb-RKwG2_~EdD0w@
zEyDrpDt%ymXM71nH^&AiYwVEhv8s&H(^a=ZL5wL-33}_+3KqQwW)T5rU`5e!`q$_C
zB<3glsgHWX!{5JE@-B_&whSWp@dASxlF=C+%1H$c@wz_e-R<pnl9>-mdCLvCCfrx&
z4BCQ8XqjU`RZ8!Ky+Mk9b3ttEudNMiU@tFWCuPQ0uO500=+SNp0U@A9_9C$EM_;>R
zhs*?x8~Yy92HIhQeF}$iQA^&<UU5rKz%nx3<9MQhc2gt)c0X6%M;M?ho;0iLGrM?P
zO%<8n_G2A;sFQ<zE$lLbDb}ob&PoSn)^wD~d>UZh%|BJXhRhisFIjhM`sn;P2w%i8
zwMNKilyK6owofb)cx`a>@FGP>lbOof+jB5oF<^GzE!&D-KuW1mLt%*)Ak^B`OxJYo
zDs2?y)`ly%E+yZ$B>}5up{%sP2Wj3Hgjx3-w}vN0@ahO#*IaZm1n{-K1N9%Vp14+<
zwB@omiaCJ>HQV|1RY(izr!txcI5uuo30!bl!JJeTZ$2h{nZ1oU<aSX^#>vB@WJ^c0
zuBq&QUi8|PbK6EE2%CB(ih*0t(h-=mxw^gS7w0m(m1&Tv5iJON=;QlLtb=D~XUogl
zfa_TxvbBX&dD9$dw{90?UX$<s{9coVCg?YC_@M7A5%WNo&Jp6m1(ce}F#@EGT+%ck
zK+7hW5|o{_-*&yx=^4;N3XJZy#ObAv3$fpo5@v*KL47o&6;6*hTwXxEAbMV5hq-(7
zz{SV+z;dsx;C0F@J!8=ft+NO>ma^>%`^Kkdv$)E~^Ay*BQ;z|pocAxwDDKER)CRCk
z4$J~aec+_~qh{&J=dFM6NL0Y;(MZ!~15HnbW}M`?vEATJDRxSh#-oo91Ch4@{S_2C
zZrC_fSMhv;4_oQgqFW{7z*!ntV|+Xq%|WhYc0cmoV&FbzsQ{vHtfutw^%4aT4WFS+
z6;i5bTwUAJorB)I(SZ8MWY~hYqj?nbO`w0Qc|6<YW~>ITZsQYGG<tdw*{H>3A(p_O
zB$2M*NqIxrEFk%EH0!;;P|UVg*N6UMak@CjSqyCU&(>Ch9Wv*935Lkex7r$37dVmA
z<{!7qos^W4dh#t^*tl_|>_-nIPRC9r80Y)!S>ls#AY2QUs6O{w52T8qc6Y_tW1TfT
z$m92z;PTCd%{{%nk?aPBgeT*Bo_<uOnmA0&ty@02I*m06JNx@}!TYlj#HqIn?o03d
zXv<Cav!z`+as+aN_dfg~911-gNQF%=ni4T~??OTX{=xzYEqd89lZKZ^Ro&6d6+ZjA
zHvoOk%HopCpL#-Of3qw~O44@s6_cA=!$G4L7!cdgqoklOo&+5%cD{zjSXl3i3~~eO
z?d216x)Le>?KyP1?F!nwiuz`UrKm>II@T4ey2i8MyY6J0F8Mc?seR8<bUe$D1aluf
zJJvG&wo_k^wQo5CAkisuk8Jr5)<!f<P^zVE#e+vXG@8XlANqoOxAEuIi^FzYU@kqS
z3oDo9Atjpvw9z7azXb_xM(AI@vO|gKP6<q+5J^6Lrk|we{z%e3aJlVp$HjPk+<kv;
zDYuE>M`)mZ6SmhZ0+C%K)a$QVUHaT7TTYaG2g<gzg3KWL1Vnim7sR=N*T@d`EsVDr
zoBn}3BcSDv?jQenVWz0@c@>Lcq@M@I$m#eK3OhnG=M4f4(-#$ThdokJ0oKyMHfx%I
zeOcXJM;IBo*C2T^)i&DPwAIaXgn|y>)fh9?^gmn<iIc161QM8I|KZB7rcSD{k8&B*
zb+}D6CqXLc0+@5CdA5s&jxIt%E7Vq9f{zS{eUaMm`4fsGL~vrqvAg*V_zPxDz<j(=
zJ2w^Hk3O;;G-~o4{vAtb4))H=m1RBm%EeDNM1+4@8nhJ`&T=Gv-MJ5#>n~t6##Vwx
ztUN!x{odX{2rgK1{*<0YXpLNZR;b<560Ln?x<Ox7v_%=p2sr(75qPjOGZ!%4`P&hd
z|0>g;6rc=ekU81GZk2M7#eEEWtCw|g($oTB23%QVdZnodXvCW&KB0<q%5pO^xq@S!
zSE|X^wD`kD3#4~Ng=*ryBgE`^CbjS%G@zCeF$o17o*O-q9Q`29q@|-%UR)fw7Ax(I
zT72s_Y9DJ@77T)XYO1QiN6}`3xlrW7Y+JzOuNP%YV9HZlTMNalFe-4N`Vx6Twfgo5
zH6>(`?5M&KqZ+opLe*sK?Bx|3#{-rjZp0`mC<F!ug1~twf-4ZaqsZvQr2FWCoYA{!
zaq)bWV|Q=wV9uZTj)K<zQz|)0bWU7s@=Zc-{pDkh>9VCpXS}{G_rX+UWtqi6)Ba9W
znc=nCH;)tUbPo(TzO~<;9eD~get!+a^$Q>sGyBjhISALO)UCON1@x#Iw-Pg(tX+L>
z^gT#ik!t?g28Nvu8*pG?a(N^=`<Yye|3xQ^c)uAo$JAmaV!B(dbhe_*=;Sd;JLsWp
zuO45m#*Vp&<(NjK!0!4je{sa)m$EL-X6ux8@!KGRCk?{lxF(N1;$_oItUe587TtQs
zY5eVCmUWqZuO<}c+<5*16+)G%Nz6SzrXs`noh!BSqGz_K<eu14^pbuTzn+SWyKv5~
zFx>1X4H5Z8xB@vMV>9fR8`3*zO(6u;K`|8psgxOVEm5EEw|54_SzO$k^SK3VPY`X~
znJX3b(oWwbKkPp<q<LWKc$u&d2iDx-Y!Ev)b>fT&OQb@cUap>5%W$?`TjiW?&SA^m
z0jABib93m-;z9@>*lh8vuU@lgZw7Y*XJA?@b}5p(aV5pSniZ(DpZS=<_=Eb@{T@b&
zF?IGy+VJ~I<;5e6riaVI@cFa!-mGuNF4DF#BGksuh!*b?pH@R2PJj2mS4BLQjaKDg
z7N-4yUGDsnv!+BVO%md~>^LlVLR&y9u&3wb+Xa~jI(l~;nmrK1Keh<TFYk?14A=^E
zai9J=&5-beB#f9Px+2IZk{tXY>d4r0x7<&O8$<1Q&+%a4hD&x%WiQo<I28SAr|Qo9
z%8U~wV2mqg3!wlwW32c@*VLf{1H@Sja{w9Vt7&nlPrxUK@q-tF2eJa@D&k-FiNoW>
zgG9$NUiPxBKNQpcpU;$@duIPIs}F9mxLEymqBvI&fD8P6hJP^$>u!?)wQIz1OvYYp
z(b|of#9<e|smx9MHZ?BBs&y7Jy#7$klmEG$#G6>kvVMrl&k^)PMF)sOd!FP@T|p=$
zQ8h{XJTWRhURP@{$E6Lk*_W8Kgg<ByY@rf}WJKIxZM5!<yLq6L^sUkLAqk+xKR!Jz
zEjfvszbzw^_T)SMVtl(e%B;5OoobM{)3|EX`pVfE17+9>3T5`nzzcWbM%QVJ%o(z*
zdh&$OX%4B6dVKIC=fdP)WUqkJcp-8Z3MVR!f(3?;(I%SAv}-w-87RTv;*g9HGqgVI
zB0agA5f3F`YNC{k4`w{FYXXB>T3Vo`gu|o0Y-h#6EU1gKl}Em(+WK;ye>rg;==ho9
z(q@A29=d24T0crjX+bg2Trr%P3|j2XoP(LzKv-v-QuaQ+lrE=z|5Mh(R_|pH01TN0
zW7d<aPBt?-Pi8!BPD=K21)Pp5O`<mjUi$_Fz@8p;3{K`mmzr+lwfg&Q9D_qUb5s|_
ziRB_>A?8YFbF(h*=Yn~~_<Y0;X3lkIhSeI{E)0L>rU*?1RD5rPF0#aF>9{+fvr>~`
z-cX5pb`}x8v(C@=$$`TW4`MU1ymB&YuOb&=XzJyFasRUzu(DY>y+jz@C@GOhg8ZDj
z_+4}K@`Ilf(&|n({kwR=JT2`bZkR=AF2<C&FTGT{R6Q^ol3k^XYq?<Rh=jeiyww6@
zrhgz(1BZwCe<lS2MW#~hf-%#phF^B_gL~%R#w!NvCiKp3o3)*(eg=LCTRMI{BXpJR
zW~2710xywfmwPSI3UpX6d3`Pck{*ZJj-^a=`{EX3+Y3b3;nuA~t_(P48Y-PDr&PH+
zhkK{#?}WCZAt*TkmC~i?(&-}ZAfE7OJ&h%Uz1-tmabX#uZXf*KBtpbIRsmbG)Vw_b
z=Xj)4{;Z6K{XFN}vRO71zr(-lHTTg*^GEy|eZ@_PpP&p!;}nx2NeD@Z3k=)0XH(MJ
z7kA@YEoI}}Gmd+UP@m>k`QooQh0m--VP|6lakJS{MbX_`7nMgQNCXzi$fDeRN555c
z7bC0m$G}tRxx^B6$`*_9nAI2gp;*f$=+^Mpy9dPq@;>Vk5ho3Zh6^?jrq<kQklkgQ
zgEmf*18EVl5!doVA#Am(@L6m29f62gO7{;IBk6SEV62wN50N88IFEjPJQb!#%b)CE
zZ|^$!<5hBWD&X3r*1vY7o@CtW>*nGjg0^AL9Fj`c0zJ?pz4P_1F)^89F3y+8lU#a$
z5`NY%;FGCUSb-q0cUBtI*ov~ojE(sqvvzz5sWi?}Hd%WL`%jeWR8I_)@%Zy-GG=nR
zVycvdI^+CNT-mnQ&e_ej@}Qj+VfLZrNXgz{!n{b+Up29_#b8aEJ$Lf0xRnUMh1)Jg
zh)S2ZlSuAQ7g%hD`gqn1ZgXu&KsT@^aHbk_vYD>clSxJ<FgN>J(4;EpGM`1nD-qZw
z@lsZXd-i%a)c!+UBH9pFbfsNPp@(k>HEwP&5n;l38~)xa#Hf9q?OL1n;p7(6bq0Ld
z;pZ%<S@XP!>$dr?6J*P6%n4R^Y9-VDe8BT~V<X(|8gLk|3|qh(f6Oi7fN?ZYIB?ol
zwvyyEz*oZ7f)F3(6lr1)g1co*CiHIJ!W~5YZa$kTQEk+;>VzQ+@dN4^5wXqJ@=YDb
zm{jo}`hPb+^h*vHlK2VPRZq^5*wyBHuo{;dj1H75%gV?wd^d71uOS}0H?9la+iAiL
ziX(sL-XmN-+%nQ4%AzDiL`3pOK`fuR9LAXP=@STSCGmy5d-v$kBOO=}b^!sO^ZAAh
zUi&EPv4y*R(u96-5MHx&k(xq?{FpIu`}=gciBS#zDN7WxNw{m0t)Wd}5sU>SbAzk3
zYlV1t^72o#Mm~OS@qP?DTB7U^V{HDnOGu}_PU&PEZp@u4zW=rcZ)?`-d(>&gt%~vw
zybkg=9--P=&enEw6{_rfeGAS%x}U%;O5UNIQBE%QPRA!FOyuNUity>_>4u{7>enUc
z!{t_DM*!o8d9E4`I?5zIdP=f7_k<2}9*vQmC`23f%@g-4URMA*N=2H2j^f-dQsoa0
zTTKOKx+Wi(lw`bhrjKMhCEU4;&bt<SokM#ZEL0SqzPi9ta4R_UN{A4m(m)#ePDV$k
zxfmTsx*@N!Bl%BqWx0`go?6O$jRDAxHb0qz7%8NEbj*rBd1t*pIp9oz2H?{moFj;D
zot*yaz{{7P8XC?Ewa*FY3hkhvAdg<%MlXupwLVbXHTbTBWj4FvECL}oiBFrKDZ;|$
zv5n(Y={1FW%dRpfEXXaayGRbaczTB<uSN3+OZW-n%G_<(lrBH-?ZS}*#l<@t8<H>r
zE?K}xH&@96saP&Ny4<675A+jv7!?kmX`{*JxD2mW=B@qlG3H(ZtGn8x^lDiM*Oek&
z5o|g9Z3?OsJQ(Cz`sRFX^soLxrk7yDP6(gHAT@09gtb^UYBy`Y*9_rp^1E<IHNW2+
zVlP2fG^^tq;1}TU55GKsy^ahQti4pResl`f-W?#@^!`B|nK0f^zEBB}N))zeE|I{W
zZ0gb%urJA@aW7EEpUtT2{DaBZB#(*W<68~EA9gn6_o9}p7cIYi_#WbCE=_MPAsP{r
zCz)WFtYIfX&*8Nj`jD4Zo4nJSPlMM%j3kW2i5Wk?38s7&to6P}t1Bys$H&#0slxBy
zzt5JNG<^B;bUj&@lAIi@abquz)}DV4poNk=*wl20BvuquR3Hip!n-Yp&NAz?Yd@1W
zdhWQtdi9D}N2n1P&cUIgOrQa{qVG_OkQZh-*va94fWx&*`cqv8v%9q5x})YX+usIK
z%T1ept+>i?GQ{`Rl$NevDUZ;~AC-YXATl!lv?>%Icm8;5IXd=jKqp6T1)1xC$D+aa
zU8O&MW*j}%o!d#oA?RsYt_){GVWn98-#xL)VPSMU0%eX18Ffo_4G46~pJxtyusDRO
zqU-+bjcn6ia|lRl$n4G$&xC=vE^=4thOj|3zr=*l%EZzWN_Z%rM%d^f6gFs4qX?+8
z-t=Ur^H1V4>&KWeGRECm081FLs$hRd+D~@d<yn6Uuqqy@y*>NX#<mM&x>NRp#aalP
z#+Zv#YLr{KG2$mc8A7A=AgO?=cWv~8y5X%<k#j-QR`u^M+fIh%LC#DrjNk`WxXX+h
zf^kQ^L>vfR{P|r4)+-|-kOCH5VI3b}5w`x*J@k7d%WJTyH<4;-f}6vQ*}YHVgN$DX
z<l!nnkpC37<1u|%p=%|?cG^`D{P}p+kqTsiy%9^l&cp<^J-n4@mh*R$v<8dljPWsa
z3=F$o*!L$}u*H$XQMKNSnyq>GJzrnz@S(Fqv==&nj>Suej@sV7cu()Uf~eC@(u4dC
z2^pC_Yf*u+Xddc^4?_CQ1w~*!XPktO8v`sNhGKIr3|}T0=o!)HC2b0XjyyxK@8k13
z3KG3?WAy1U`0awEGB1O6v9q%?xW=|F+Zm1CK%biOYj1uIA2w?=AK@6zQM~`pm6m2?
zGXF^wt%*rnTWezCH4%}D@3@Xo(^t2zQiGJ+qo|LuIbRb%e6JNfMFih@FbGqFb+~VY
zjPt`o-}OYb*X723-~uKlCQ@<vn)CmW4y6H@Ma*y=M%-DrT|Pk2u<h{A&alIjrI<sc
zBm(>Di3{om3<hJAvhwYV4N@`=PTd(;J8Ja6<7pnLT@4?#2a!kC2n*K8&J``Ugmv}l
z>TjAwnyI7q6MJa6?BVI@bJIX8Gcz+IM@MDluoND!`YLX~86%#GWGQc+8)q87ZV2{-
zS&PmHGG`8X-^oeWD!f*9Cj8}4y&p08hF<mxup>PnVvjinqf={h^N=UEG<Y=J<Cgw-
z?M=O@>#7xjfX!J~ldXocWI?9R{n;0wdIqh$XR+0htm~trTHE&W&(@&=1moEZ{31SP
zoZ##@=(->)i*usVi#A}Z3tcCKjx4R7WJ74Y+p?<BxEv(WtY}}@M;WxWg=(g3(^G<U
zLrI!sun9(=%c(vxk}9(E2z+039zhQufwp*Kr|IRt#;vZmXe6S?%gq|5rqs-zek?p^
zWB^HK7fP0V+CX00m$NhU=I|y-dwVR&8eO>7-`WoOmu!`eoh7LiorodZnwdY}T?XGW
zg6$zkz6z=5ydWQoI$Tn9j2bY55$dcPtXE8Ez2r<vS|`<YkoWw@yFJS|<G}}~?&7lm
zI?cy8w6MyTwE9j{VeyI=PyC%>X563qLgY7|&Br@_0-5+%KgcH-%o_wrV`B=A=4U+O
zBT>~#-IkT)Ckupimk3ucG<Vnj<NVRU`_SN)vcCiSgV99cvF+}l^i3E(r~~aNv6MV`
zmYdxSwVA{&&+Xp^uB87Z(miOT_D}sg19iA&Uc&!wRK~;5=>2+<zeK?gC=$9Pz9M0Y
z|JmW4UEu%@SE_VD2+ZS?9Rb%Af8a|!qQ?Jsu#3bK5rZA%s+DnnnCgGSUmQI*B?wEt
z%SvF34|-Qf1m^)ciqXkiRcEr#{&K!Sw&R`u$lw2G!;;ff$-{p9f6rUe-7_6i)&AR-
z2TlR8x_Ng$pZ|Yv9vJCX&-|zM6AAbrJXZmLS9v<y?m_<l(jH0wKmOzYzX2ckJ7-sX
z2CV;y$zar@zqC%C;E7Tilbt8^$z}W79fJQ2B^>%cr>_2=jYS(BX_aIQKuhHM0CwO}
zhYvJzh|%z@13){Kpf4_+0k{DG5oG2Ka}{%{t118N=2d>{&Qf{Y^8LLWd)0re#kxio
zF-h{2rW*C4H?*`XT?20b-xP6*fb)8<T^U?L))h8XFNf$uhDNk*>{q2AA2}`AiJAW<
z>niJoC-isn@JL>6543E&ZLa)<TkdnZ2hUd^x)w12U!T{Mt==I~5eT6Sp-LOM*EXhT
zTdN^TTqj|E!-bfQAIsXf74j4)1|aS4wqII>tN>4V{;{R;9=plzqDm5e9RQdBYN78`
zC2OT#{a21Rru=&iwp-nMFp@fdWO#2j?o6ovl@={hN{uAv8$7`6RS(L!I7+v?f=%kf
zcMr$e;cs1}0cpNM)fC&fG(7s4Z056e7(A?f>)k(F;da)cFmf+3w@%94cCoW+om<rE
zGu0#jDJh0cmIiaT3C{knJ-hT1kCY;WY4E=-g?^Pr6oJAjkse1eoXhWxQdduIl|b_E
zi8r({T^OsY_fU+!w;Ic4XAFP-?32F1+}sQ;5JDBgr=)V#<iTS>N44wHP6_cJyUOrh
zf=h{JXOf#;Lo~7fNn1CEOX~{OCmp1W0maX*ilE{E*1;so$F?k~c0HR@-ej)lsgo+y
zq5z<+ws}zW=GDuyt07XrRkvG+QdXQYiFv0zV9!PmNZp;#6{h<6etuR*378stZfQjs
z#HH<MyS_Nv;r1h+l&7YY6cSqZ6{1vRa6`pr8F=|mA$F~*oYgG(=B4{90kEZ*bQ|y|
z$%EXbix;VMv+j&g32}Q^^X=P6_php>f%+bP_wlC0zfzOudf!@SlQ)_A7W4IFdZ6i5
z_Q#~I`B`UxI;vl)S2N_-SLK)L)Csox70DD&YJfb8tG}W@&OetZ4&&FcR(<UE+AAvB
z?-wn@vrxW&50(jX22ZuP0M301zt4k(d8EkSW&*Scwj?18dFrn>z8*DgJ|+Kd^Io+3
zPCE@*@Jk(!H27O84%)K#@43RS<2;rGJjcCw|El83?PQ#=xV#3Pu`yNU<pU0|$r-70
z-Do&vDkJi>EX^u4m$g8e?q`X<g$Xh?2hmZ|52rqox>1k4YWd%de_~Qjd!;8e_vx2L
zlFA{E-9$a5Ur}@qBWbSO)nDEMZdVvy^KpJxzyEJcowOh)hmRKC6YidMq4XuQoZ~+u
z#ge}6lm3X#vbyHUxX*K_Rdr4H>y<ArzU4E#BUc!Jk>mwPEO`A4BX{1|k%E?l|H&4y
z0=n#*v;2$f9v1^O^+T4k;XRRE*0rAt$sRnJ<U#D(v!2_>go~)(C)e8ks8+5Q#{@pB
z$46DrH<SO&>8~Ip^D&Qb8HJHpU@Bg4+PZE8+?Z8(d-XO|E4?eg32;x0!U|Tpq||!0
zzC|6CzM=jFP(LGiN&oYO+N+JrvH7xgn)|&smTor5n*7g@Ki5H8KPM*{5XoKe!izLS
zb*7&w{Ota$;EvQI>R8e>noIc%i;T+R;gaE%L-M@*Dbr;VTlp8Cwq3e$y-sA#A<;dT
z$}o#{bA<lC0@jg^@^Xv{6aYot!l>+lfsDn5R`<|d_W#x@z}7l;1`>tg{fYgmH8LUb
zkIh^GnREgcVVpvP|NJV_y+~71_~RD_nQuEQ&FmI0Y<JE+%`ODoNUs-v?8s;nR#^DZ
zwqA&wrNur_+uicv`oa8%uERy#PuBrjopO&(iDS;~3b*g>g`GqFZ2wItFxbalLql_o
zzK%Zc$AaFZktw>`kF`6MpDzvimM&V$UO0#ic+TKMd2_MoN)(yS-R=3{aR=S!?$#d4
z;>B-XF!)4p1{;t-sDUsNH&HezS&vMLjXBf$7}5MSCSwUgF+_VYixj8|(3H&|d-PRo
zn|?Ji<Oe<AEx<(|l3$(jfo4NDI`iOvZiXezvabO4kaaMul~;C#>MK>|uQ|$B?exnZ
zc|DR2mq#P>9W<^T-CHydk`2)bRbyHIFm4$@74QnwP!d*3;WEZZ`IkZe`d2m;YERO0
z3X^MCj&=2asTZM4zH-7)@LAc1?2zp7cbdd63M{cpxy(6zB74FWfA;su0cz?iF>!-Y
z*TxKQq`q*KF`|UOy~m(;Bc$c_QYdQeIw)PY|3{Ogk_~>fKN{a2{OsBsb&nmOcvwbF
z^)PM!QiuM5010sQLnt&P3!)qLMMXAM;fptEUNQh$pnFU2&>6rJfPy42#9W?cIF<^a
z2uT8ftLAI3zt%K-{1rt)ZqDQSP^rwUHcDsS)0ywDYx~zW5S@#XJfmg2_171x4a8Is
z{x-^hPBDRdg?ZebMd&|6AHi+XS8IBH<F8|-p2m#6A3WqfI-CA$kkYPfoBZcE|BrWE
zSqz(@Wf7it4*P2xLS1{tzG>R2R|nkk*!=T%1oBk|D#f(FZu9>-{6bc-%TW8~1z`Xf
z%wzkszVk^J7`>vxbk!Xg8q|xev&9IFy4!iu{GHU9pIeN^&)a5ou}kP~1IR82VG~p4
zO|{{lx(-BLi!4(6T5X)uBp%@7ZK?8Xb2tmTuKqM-{;S;WPYzY$Z5<LM3F-PJ4xblp
z7yZ2(W-&}cQwz__oTuKJ5kgG7Q~*y%0@*Dpp3>oeL+weQ#@)H94X~FaCYVH2W&JuG
zeEv*_lJcsaEu2_G`hg$lzL=kK|KP?e^fgLMW85&Iu|Ywg7*brRQ23nrxp5BnOIAe7
zho=+zHV2Rv^TY=?8r+6nx0!ssSvE8j*0J*1Fe7BUQZh+(AiPd)*dWIKx=m4G(Ll&k
zQt%DoD$@e{1V25tTk{!tF8A>`C|#a*?6%mAjr9LV+*?Q0@on9Lg+p+M;NjpN2p%lK
z-QC^YA-GF$hv4oG!QF$q1$TlbK*+C)+;{KyzV}{tkJ0~h#vr2(<4~v0uG)L8HRoJ&
z9~Ay6PFP;v3(rqj);Quq__-IJRQ&sPFZ_)-AtOifczA6ZA{0Cj){-e+7hJE0NAiVO
z5fT+khU~h#e``(dsU68<hVeYQru6s@$cVi?Ypx9%+`sy*(WNtS9FB`&ibQ~y=u6u@
z!q`#3@Aq@FF&hs2bnxwr@C;)=i(=d-y;N*@NV#yRwZwz69#-sql@ld!;DKjZo`<i>
zSd@`YZq)Zn=6o|EnHIa1p*;!i_?BAZP(pKBIUQdmh_@?x3o^${TfU0FJZv274{>y9
zE~Dub`V^SSqqS!{jlbdPiwyKX;pR|QC8>U2sfU46F}fj7ax%(iFpYhyL0e@N9*a^C
z%k=$L!A`h}TU?8-0{@VBj45Ar?_0kXOrKU}CRFZ+&2@T|n?u8Q_5H$iY*&4o#S<Hr
zm=8Q(f4U|WCYc?S3<axlx+^<5Ih$4`@JpsMc2ibrBH#tx;9`w>ELHY@-RG_z>hP(q
zhj4nkSMz&w(VE_k#vj;BIuQ>;k-zs-NOpu2D-}y66q%^;{Qahk=rD#_a&~S|7-Q>a
z(1u!Qp~BHBN_q=EU%mfMBzD0p!UoH~@h}2zqoB9Aqm7S648PZMEP`U}bZy9KC^*7%
z>a9YfTlo+2JXs@CXLmV%(%zsmj}E2HbBTC}l9s+UGSJl2gjI$ENLgnNPzWctt%L<$
z513N*^(73vDH5SYyAKoIR&cUf^J>_=LL`L@L}h;!i!yy!@4POY-bwhK+jrEN4JQl-
z2wC8~!hn4;2I6!Q60rqn4><P2le62A8e5erB#neC$h-JW-7CliBpCsKUxNJdtaIc2
z%d%0NPBvA4CPE7M-zDw{`%h>P!V^GER}ih;NFROX`DVbwux)rBAwmidh>&s~X($GN
z%%b$>Aq+n_Sd0$l2ae82P;h>*Td&2=!#x-S)B3MEu_8*l3wVH3B`24Hz7KHxht)hK
zjDlGR7$gi9F;kdE0AMRCo7d_&Kur6MZlvmb9?^D(r3z2o3KvEq>ac|7<Qna|EX&7l
ziu~nyLXRPn8z~GT(@*LDjwB=w<T(h!q)yYa<@7Ks23!Sy?1uI~l|W<e@$zh~FH;#s
zMZ+}!a$$ZP8q$-Ho$|v%3Co6MdLvLIE$QUw=fqigQcvV@SS3|4dx!%D!J$Je(jBNI
zF|K#0s78`lu2~76ILIrsBA<+NlkB&6NSdTLaQAMC5HitBBm1d<v}%1*RUU8|yn-=&
zg>Dv6TxXAWIU;`*_>rw+_SQi+rdB{V=TpxH%I{nS(USA5+@4yCHb!iYcavf4F#Y-2
zBbd^K4{c!s@ducYFtU%g3_s?B>PE+Ybyi*1M(3t=3@kq`{x};k*eo5YZNB!+Eh|gK
zmE9(y5z_2N2TvmUu&XryC3_vq%Adrm1}|!gEKQk<B^3qy%4PgwROO~}z~x`a$k%~4
zK$83b<enuVz~)tTyqKQEjDCJAerUckFKp=ht58%Hq4n8ONz6x!S6)M}XdCXMInCOk
zOI&ZX#Opa7O`K?PEgEWbh&lC5@V@G+0FFb0N^Bk_q#P%LSA#|kYLd|%&D#bxpR`>B
z@W}~+(i|M!l{64J@8{X6nfRF4^)<8@WTXNMChy_3V?{0Dyc>|AYqf-xUOU_{F^R0b
z`smjk$x_FEDl07=D?4#;qv9ckRgFD7l#)6xK4;}vriL`xmA^UPK};&-BsSZ1>q~_t
zYpZIR#&O(y3-b~$cnBbpa@8i-Y!`>;8|`fo1nfPJ8c4b1{^%Go?kSx8%XHB97c!N!
zvCs;(E1soAgZ!b&04)-R(e44t+Str|V+xsE_3){wrAjCoYT>XM-Vg&^zC_P2A&c+}
zGtths+_GkvB8>-)SHV4)4jIze(yg-l53xFwz$zl(kAbpR5W!g;69IPw86us9_Rj*)
zglOTPfo#}d<6AAAGF9jyl-&A|+eQ9(kH*$~1qTG*K+wtn<F?~!h{#$*y*=T^#QJIP
z!@*~$be#g)k#iLkp<5QIgb%tb1T1nFd%HYvY(^EWid*Op2z&gVJYfpQtX<R+fy3J?
z-;LRQv79p=iOM~KrFzjNM<PC>9<)_o#RiPTZqdk$hoe6Wyav&SPcFG}JlP6C#|kLx
zk$@~LA}hvfku`t=YXNuwB7Etu{pFw$b6K8zduI&r!6o2AX#G{X;2B}VT+iOcpIE6Y
zgLN3Crv~>~FR4V>L22-D|F9p{@IPvC_E-PL7lOUf%~*6=9loOe?NIC^1R<VmiqVUZ
ziS!1Tm+T^(kNDOA>`w)!ajFmn_P-9mq)i2wf&Dmqe!ruZ51Wr9bS$#-GtUW8ebMhF
zfWY>sh)~ZczKM#JkER{l$}Ww^m(iN~i6m?7`Fj(Lkk`LDbB`Soe)*PV{T`TDvwexI
zKK5W_otUV!ie-*2Pol#zIZh9=Zy;OD^oZuOYkGZxDWu^>P2q0=O`uDY8uyuGE)@=-
zWuYy{F_&a8ZQ7{>3oSV;no?r$V%W_}s^U4jqBEpMY|kOQmHg0OmE0a|#ri*5+nQgt
zdgWp+81ktV<6b0)@h-jO8&CavABxFKxLG*40}*(zx^!GKHzd{*jQlDqWyV+1ElE$_
z?f<kUXL^Gv1Oq&iT!T5zGl@#aOra>`r}Yq%ma%e*6r+8dxkTU_k2rcX`YL<Z1h76&
zpj67Zo=c>Rw1|<}Oo0aLc>g2$&6L@ifW2@W(T6TDhFfB$g9J%y+)?SoN_GNad{yOW
zbE^Fpvd2s*BV+I{!T<C0(SV2JCVCQx7_l1t(OOM69gUy66qrX%O%42cw4v$KohhZL
z-P;h&SabrW8&ha5ncpBbDqy@|WNZ&{>3GqK(uL(2QNJi=*G@yTE<7%~;2CSU!9XcP
zFFCdJ>!y}7@8gULIxsnT=Y(isSB(IKbactm-jj82R>*47*C`ia|9FNH!r0zg;X8uN
zc<ytci_p<fw=0QRn^+5JSUa-=E+d)RA%=hWD?Kr;aj_)RQO23&#_e;1_YUw-sfqUv
zQw#Br&-T|2S(a1vLk=YvOjSLa&xD`=iR)Q_yt+7!rEx`UO~&g_F8!{AOp#17M0&K+
z>CHNB3_nV+B~RN5oDi*Z12T9>5Sa$vFz-Q?r8FuWs+G3u!oHogb3|17Picj2_7*aY
z8jN<h<}m(XVAk~J=HajJ>f&LfF6;WEV8XAWrY8Aj7ZCe$Wc0n!l+I&$*)N-hw<fDG
zjg{hCUi@8?_=mxnzoDFGy_hOIgdZacPFrl(*jC$K)UZ|%{yKs9^@H2Pc;;8>w=U3f
z$_^;;9bcI~xio3hNcT~v?ro<*hflGx*{mGOv_`#790=UlzuKq!stt!^Y6SHX2Y*J=
zg~;R=K&XoNImGekI<SY42?yauADsSdI<cwaeIZ2h&}xM6w~@1_D~$2I3kkuDSVIHy
zDyuGOC6L2rWE;wKGtS3jA1k4v5rWNpM5iIVHN<&>2O}eh5!~YUPH!<LC#wjNJP&?@
zZf4fPynqz^xzxq|0|L}rV^abHSfLs;1boD#L!7-uH>=?Gh~TfKnEw^8F9%3pY7Mz`
zk&!cdDM>oi2|CIC%eZVzBp`a4ma)6wp=$Pb94B<@0t0rUdkRMpk|)r+Q=G3Oz>GE|
z<R6t0=|rI+vvIL&^(s3F4v-U4@T=+5Cs^I8*oF^Q;IYKkts(XnZ3RyEzmF9wQE_q4
zuW(KhPtyj_03v8<3>0zyQ+_}pSXfAgI#Qmp^M`<Tf6cvp>&^Y^h~hw>u3Lk-JQ>H<
z0p>HX_8%ab+}kq6J6ju0j${uiUCC+jzNh@JP@B@2)!9~_A)}-Ig)+`ngglvm1h@0j
z!MPBE1wdxQ*ZU{2EFrG+#6;dwlG>ay#B*xt=ouN!V?H`qyO8)Ur^>@9-gioj@dt;b
zSmM0iABZvDSXNCgjoh#si|ZCA+EYm2^fSn!FD)RR&g~x~h$X@ZYhILwzon(u)_4t-
zte^$k<DM`l8Uu!MRC2m;v>G@^anmmC*_Sn^nf*cW;JcY&ZU=i^N8)2!H)KTLVGSNN
zzcH|L1rAE1ikuF$wczJYFxZPM+PAKR%c78BN-8WhkQc`Nrj7sskmUXpP8pdpjXHBQ
zMh*E`3^_H~SMBVb2|=LDg3PMP84Vbol(7I8I`JxjCB&g3bsijvO(6%nzoMgWlYG$f
z2G}Ri?T`0AlhT+Dlob6<6ZC{!-0Isn>#vP};w8<0oLjWg(sHsf;`~z5$DZJj&CS`|
zQ7Dk1)++t_e~<5|2JR!2uU=w10f<5-GOTcXQi(8bxuGM1nid0qU;}cRA^0c~*izsZ
z(5p5y8d3MtZ*iD&Iz<(l77@e9;Jy2xKzy@Ph8U{#n<3fuI@Q85OD4fAozF|-vy8Kh
z51B*WTo!lCiE3SUY^Ehm;wqgyD@$5(00KEq&?hh$_OW?=ueN{~=*)3owzPeFi9*2t
z60WI@Lc{TC+^?^)0tv2|h??dEW(NE0-DO{<X7sMwNY;rsb+{!>Ua^pWzz;mD!s1tJ
ztdG$z(G|l?VWeXhv3nn#p{nE+*j*0Whe>Pl#_mHL7&gN%DJ{DH?@{gl9q0c4^*4dO
zrz)7T2QZ92351{l$A{#IRYb6^4F_jE1P2(KA%pG-mSe|`&{it#?@LJ;H4$osku_DC
zv9roUYr+I$3L97)YUZS?txe04goVHj;H&VC$^awTQkkqUeN21)+W*Ycp3J$I^e27D
zj?n-gh+m3qD{*CtI2<nMv45;=FJdk)fqx9vY(6sh!?RKVU-YJe35T4NKErzYhd|%L
z%z)iEa8N%0AeSs$4w#@ft%P7?1Fr#6gFZ*|DpM>HfWAVQ04f+-XkUn0Mm4+*2c7^e
z7gmJrB%{hDY$#I^$b$uXU;z>7lim|<Yu)-lpSGq=N4$1Lp51|1_E}HenZGFI77I1u
z+f1wRG7m!9(WC0g1*rL@lt|--s+(JNYJ3u_3$*}Rj5p3o=OHp_z0kr!V<|WwXtZZO
z?sUSQIKIz|CS*b&o~4XJFKT))-elYJU8piG$~+mMCRk8p5scGa;aKKF^kJ58l=Be7
z`z5|SGBF}KB0qY*ASA3D)i$4ZmT}N)hx?-qgJf!u-N_&SVx4s<L__N8Ax<?-F*#j(
z3(1EW0@)2b5~+CQWC1Sdc`7(mYK!-7_h9=X6nO+X=0|)5%+nukH`wz(Qc}R2Bn6ZI
z&SZgq(WTp|axj+gxUf3wFUGjV@{(=mYdE=hIJcnr`xRCnl-Xhe^!)zH8Y?EF(=04o
z*=c;dD5yxg?wl1a^Pf{v@YLTf*BbW21KUpIyy1SWG3e8hMdlJgTKkdZdU;e-EYvbt
zYTzw89$9}@sT!+<&P4@2>Wr{3!2hFQo&H_K&X$G@u(qUw`Zwxcl>dUd8!=+d5gw#q
zl;Z%wS3HyD<n%BIx%sRMWS?CJe`TC4r&iFW!a%tIoq$3bPUtYc#<;zu<w`BZ%t;*=
z8o<O9l2}1(T?eq{Wlp^?2H|T{AY)KR?NY?RBj4OCe?W;HlV8@RjQ|M0kz_>|fhYlS
zKTjU{PMAC+O$z#_ODmsU-@@gXQJVCjG@_j3M&c)`>SEy}iWlvvyK*99S1P}v&nyf2
zKVtSaCY+9M*y+a_%B6waj%^HFn7|#hi<(45qtEw&9a0DDwWCOi+k{W2CQ!4Cz%&%j
zXt@rDz!GsJc~d28aVsphVbA9=OSFcTa|7eNJGMJ#r)1;)V7vCez~B0V47JH(N|F-7
z%*;&6KhQ$9mSt4(LF+y>6S4T>KgjunO<t}!c0?*s?D2zK)<bhegLGYo5mVJW^eQJT
zT3n+ObIG7{nS$uXGz+MYk1#-zhLouF8*W)1w&1pT3y9mmUhp175=>9otul+Ws5w44
z+@9AcH1kC$JJi1UE+MKVY*^W8_<gz6_~dYpemE3q!(~GPoV=|!=>uP7WF>K3KkP|}
z;0n=F3Ag(aqaC>vHC->CeFFRd0^gBW!qB8ZFrw{cE4G;fEb}b_0461nkbGwqgrdMl
z7QjW@<uev3$Nj(pmScl^S2Pqx!LiecYnCxJ4MfFXbIpv+R%G{s(c4w2IVkcXt2ljE
zj%aTVu|E7lT)7`j-{${bPgZ_BShYKfe|H;EnOAqqv@dVJwLM-e@p7G3)F)yj<qGZb
z2YOgVb|toh3D2(OvqWl)&Qk1<Kg)e23f34Woeyv>elrkZ8yo#i8oQfVg^9)1e@Y6s
zQ598WK~Z(cK+8q0E$SUl@|fey<ndc9aMiznT}Ml&+D|E|p}4O53K5olre$K9EEb^-
zL+8Z>ERwSMg)O@C7u2SM35!ww5(Qdi77c}8mFR1D!}_uPW5K+p2WBEhGN&4u;!&IJ
zAGS4rqV4>vKhydIJj*P2V@NCCS7WDO<e`LwZQWg_P}E|-+R4rQ9rgl;8{OjKg7P+e
zz#ltKou=R*f!Ky|q9PFrWT&k5JEymx0O8h$4HI8Q&fBGVyz_>54#UtgZ0ZOi)p(?g
zjL>|WOcyN&MHJT_y1yAp=3D8OlKG3xiV+v%gpyMctN$17-~twv_FKT83`zBui<<g-
zQS6TPNt*haa_^n`sb-8$udv`-A)w%M<T{|3L*ToRGp@g#zN)+D!gw~+8-I9fMQpP)
z-v1-h@R6G?If-~>eHx{FHK{+FB1~TmK!NTt5YmweJuTP8PgrB5-MX(gjV2`d0uGpX
zh~@PG4iLVfJw}*}hqd1$@d>eX6)<q$nE|-zts~NO_FGSjy<e!Cf$SLXf{EF3VUYFt
z9GSA36&abLR3cTu0bs;Dg_$G)>d+XAcuDb!aWFcV$pPeu;6fMh`H%BEsx$;oai`V<
zk!`6}0HHdGfr;M(!k2dVvCo3elHy0fDnPauPHy5S<EZJ>T7V>_jFq60wuG1V${$8h
zs<E5#ZPH=>)ze%bOyU?hc{P4tI|T~#4s_y})9f3Is>pFVe}8U3XArXqu2`<!>BxGy
zE))AN1+qo6u057($&vCs?Yxi(T1dca@mlo*1JrAP0v;ORG0ZVEdY<eDpJ-L>srCeD
zFcAKWfY_ZZp0sxaO^QJcCdfe~9(N>S8+B6qV+jcZWaP_of!MorAR-A32>HioM@((f
z)6>9X_y_dBJv4rrp_bE7kB$Djg2rk~6UsP&5(S((T``20T&E?7Q2+VwQ8*bzi$j#<
z0QWSr7C85=-ou1UtOeb**MKhqe(Cv(9Gp|EhfukK`4BiU12#>;8vt^TSYT@Oe|KOf
z{||*^Laza6gs{1(mn}EEd-eNScLT%=2SG>Xo}B&7vNGf^cn>e1(5ebD@?{>LI|C6d
zTc5O<Q_)dS5JURHNWG5I&2z49ZyP6N2ZPu&dhR=54v!*lzCj83uJRhNAIm@6)o&@h
zmYJfGQ5ARrNbM*t;8@{<t|qy*AXHSKfh9^ms7-SI^ZViA;sWdj16{kQopna?b^=1+
z2nJXTZTw8&JlgB7_L%%v1x1m!kGJOwXXGGxP_{uK;0SGzt$U}I%^idNe|j~b`e(Vx
zTHV$4-CvO`sH%D}|Ke+w*w*{|^BS-Y|HCuP;GA2!ODT^ab(9q)6p9rkR-PCLf(LqX
z3E!L6^ER^xpcuTCo$)s`IHNfdXIH=|AUxuf&MOSq)Wn^BZIc=y@GVV0XddJDGBR>(
zXKfE$gYNu`GAEpHpi|LIUw<nCn+DikP}j$O72?(T=g0T{e?a>QD=Vw6=leBqv_`r{
z>KYAz>DSxmQIGDMe90R{-lIN4xxd<P7IrCVLJf-0J0Lr+K1}ko9DdQ>?)TX5<zewH
zh34#Ncix<YI+y-Z{=EFdYF?z93K_gdh2Y;M?|z7+z<BJ5BI;1HLxVOLPSsPSU8pZf
zMZ$lC61rPb*LyfytwxQ~^O@GJI7w91@zIAf2-dwJ|74y^<9Eh%mW+(AU!~fFF8teQ
zDCf&Ms?8G{O=quLTjQm=&(9X*!Z=hGfg@|l#n&=P`ZWS?e-=ertD`7n$97*o@&L<!
z_|_v<s!v`Rs{xc<y%A6-MT}-{V)79*j&9Pziz-s9C_85&v2j9L3-BtCtPc6(4j`s@
zmVC#qdVeZF1Z4o_!HHsNN`^{rrmI_P(nUk`8ZZdwzxqCjMoAPM%0Q;e$2Ra9;3Poh
zvaas<=LQaN$iJIy{}u{<eT2|ZWFoPQy79~<r1$DSh>}iD?oYcljt~Gp>+Tic$IciJ
zP<vRAhhD9SE^_y7Dg3bjf9ubK#t2Tgdnb_(5NgdFKkZ=oEr`K}*wLg`wz-9fc`%C#
ziooFZ(-UPA)kflE;cq1s9X>e^#a-`lV{IC<ucd#B5cU`lt$XnKlkv`)0A&d5U4Nn!
zj|C^v-rnBos#cX65gwkH_Qxzgxhy}s8|%ZRE-s)aeAx>>`OgkMJ>YR2A5zq<@ne}1
z8OcAj>#Tv9*2lqfeU||$*AS6YdSaMNhbtq>&l3jVj0lwSYf`!u!T>sM_ho@_{e1+$
zUS9zQAPBcALSwBtM}7}%7ZH4~(}yGVHWa>?g9bbfA6s?5{pPHy4IdLIsB<?F38K^E
zDS+~qMTbrPW3@jfD|}CgBb|cN?cjb~Gj#rLcfbb!?q!)UDh8v<@%Qg_?w5LPIszOV
zDvFAZXUl9sy`cRRspnoi0+~--^T-iODg|&|m(5^OF@df3dL9DM3bg;?0+;|mMW2{U
z?s<*Anv4idc{oo;kd-VmN}mh5=ZVMzd6`^q81)y*>v=I?nLjFG^2)Zg8oug&JnA*{
zcAbL2U9@Y}$w`Gci+aW6iH(OJgFH8VxpBA|`V10kF*nag@Fb_L$jh~!442irZjq4R
zlWvKhveM4;^}q#6XoADe&jbq#>-r$mJ|!jP)1QY!-fS>y-wOaGfG1@orI+$&Q3{uD
z^~>A5>d&upD%5|g#bh#j6Z-%YMb)o|adEUdWpH>|ouQ7P`0=8@j5p9E`Lzn`ZoT{Q
z=@1-v^z;u!m%OXW1@HihKPsyUrIZEUzRSgD<)Cv^?AI1XYi7*PBb)IncE^9G!o>G`
zacYQUwN}%~XTRUOF+|`4Fg_l25GBLVto*upYGcOjp=kHyeP&qi91&pl;Dj(AWPh>8
zh%s?xqS)Kh?<#FJ`5jG%tkRx`MUSuM&%iq%?cFf{(gA+OZ#1r+HFK2(e6gNk^Ch2#
z<=5|!fHt-pe2cLAE-qLgw-YJn)BMUK%Ty#6OYTQQ0X>e_y6gluz2Ou)<Mu2zXxZA&
z`?yQ*olNd=7+$@EnYoZPWMl>De?VW8l?HQVP_lDa)cnl|p85W=YyO}6)c4*4U=!cB
z#laA=Y|pZtA*t5yNZUxYZi5}?ikr+Cb>=raeV?an><P5irbXXBMQ^pI@iuwlVQ2RH
zKAmj?J;oKkj7?ct$i+69J3ZhCdaj{&NA5oyR?JO~Biis)Z@F}w!kXHKgT{N-@KNeW
zR$A=?Ur?)`ZGLb&=+tP4o5|PZzXUNhT^X|&%}n5!ThFQYMEN<jnHkvba_NJGhXFdU
zPCAbR;-J2G4hO9DWaxGqwf%}8bb&kmtdDxPc`JnYeb<lJr`J430_%FLysq~mXBrNs
z2X6b1(YcMZk<P%|9<whdlUM={?m7cXJ-^-w-1Hjc4+yl~T<j8jF?cXyNa<`}_@-B&
z95n2q%7LKmgAdg;?ECx6dK*^HQUD7FUE_b22Gk(PXqj|g5ttQuvLffgm2v?<_=@rA
zSr%&#uGQWEykL7^Y;08&3!uUGsnG{+J6P8Y_%#b?`A^z7YYK8!Hex*$LD@muxEVxX
z2ifK}Dy#9dY*7!!uQ2~zW`n=}H!uYy^k0C-g#$=CSlqC@Oa^kD|48|EV%H*(Uv6@^
z_UP!M8@_Y?U-csB!#*oc+AL2@O4=;>P}$`;i*AN1!~sQtP^%T2Y>{Cm7_MfXP@=m5
zi6MU1Z*)HYoQ>ywq?`o4Wd=5vIJNis8}EkbgTrv+VDwH0*Jiz!!(cRD*4kRg5cBe-
zE!-PBvP7ixjA9v07aymOimOw<L7l--P01{FOQB4S<3mKc9E3)U*iC+Y!hr2x=TCU=
z=4vWA(}<Tea3LE@D;3MFg4LOML|bPf5zU=N;K<FBFM&q_N)y_s$S%^F(-eoi3XIK5
zp0OOvh9*ukD2~2PS2+#m9}Q1iV$Q{`Q8ei5)$?^0ylYd^qU(>6zJ|GWMoSx}x^^Ud
z`J%K#SfD-u8j%O%`ihUA;TVDIg_2-Vl|nPn=d5O&;$_E>6>^!@kl}!`sQi<!G8<ht
z(PtaE)+SUkViTI&6uYqm%&=bAuhso#mLM<}3#0Vgk5x`cL?6eF1wr+M`h@b4om*cg
z>Co1UzSay8%k)YCt(2TkBLQL$+z)EFMCy15Lfj6rJXhPv^xTVG)pyvbQf*rpji|N@
zyt{lkZCYpa`nxU|yCdbrNKSGtirm$-eBYUM@$FP=g3t_>)F+!b{zMXO*^~TCA9cme
zJ??QkKiY;56w>(6E~ysCQBgT~tt^|Mt98Q`yE`AyTvE*~l>~`oh{dw}T3$8)!Q50$
ziKmZ{#+7UzQ<^k=eEoSKJmI6GxY0)w{ivq=jzWIoVeF4c?{(jE$GRt*nnbf?vX)nu
zym9URm_Z&no)|eF<H-q66Y*oHBN(EXMd^xU=pldiM@4e|lVsYXN;)>a1+Jo*hW6>m
zGx(0+C%+7w(8N_z(6-7}Ux{F|WO4OLnxR)jfA<f68AKSTMgPr7#dtlBwI$pW4nL!m
zZ+RMI0U~K7S+6Lo{IN=P*CQ<k*4BIFQv|Il){=6n`KXO<9TNBEQi<%Veo5P{G;3ci
znse(pvG=%|Dfj2}(ym2cWHhXtP=(i~7pshqJy!1{pOqv-C03QQ-*r(pl|&}KeM{fy
zGR0drwk}O_nDryyK}GStkEVlpy-IHtO=wNsaouS!V*cE;IeXgjOS+DF-g!@oo69F*
zicdc}{yd&;=w{#lGnFM^cyoETr0>pW66w%U@%dhjb@BKnA>Rm%Q>|jOH7LdtNin5C
z($jUp>TN+a4gEycje(MijGl2*M)YU}!&G=fikp=54)<m$RTJ8n*1V(x|D}q4c7{yV
zMMTtCeGC1ufo}F{9xw4QJKCZuc*dQSXzqyr4DR%EkgKbe5>B#9d37{o^nU1-q6}75
zcOw?#fT*bn$NfUt=zL^#8fzHTtN>L-J_9vlIh$%>we*{XnBBJ)M3T0YWz_<z#Q4ct
zW|R~Ra<A3bHL9o^B8i5fYgGr8A`EAP!BdVk)t15@o?9Cmo>)9d>0Z!ar)21SnC5Jh
zwQp3B78CW>i{hoG?{6>nE^jcZKk*{wK3%6j<e}-HC00%9bWpEGcCT3Kf|<TwxKhuW
zFHYsXWKTS$kL9gpz{lA^_%;zL^Tb#GOotikUe*MWbSrCmQ-QWxL@nvGE-N0q`~JOa
zVRKzYiPp)l3wdp~Gob_*dU>gPoW#{?Wv$m0jBGh-B(b~azFG+o@A*~ML*{9^`j+9m
zr<Y&+#8)SqkRX@5Hc*@WL%G0N%o}fzCn}v_f?sAkUrv+_EAfQGB#Gx9&nE5#L0TwF
zNb72UPC-G+4~A6~(b0%jd1HBL*%*%zy8Axqy|32#6lGLobdc%bQ=&uy<K~wP$6A}d
zdy*wFwewRWLC2zb2vJ{CC|bW`IkZ;gb*c8X68hp@Jes3jG6Rq0#+Tguv*52zx~<xs
z_ay$!HCig#`i|9G*wizs#I6P>Jr8gpzj{IJ+XeI*NBeSg+4DOn+k_An<C+z~xULnh
zaG^j40HQDK>}sJ<V!-W*1I^p>ajg+rW{IiPo1ZCBZS}t<Bzop-#vhHR7T`eX3i-An
zZwa$ZsRi`UXEq=_F5KCKg$8D3eLW*S?l1*5Qpi(I*v_^@tQ1C_z<W3dY5<u+kM`&@
zZc=k-35|W?Lgrz@zyc1axP&QEB~eX}=&kp%#^eQ{Oh5nAidXwUmmH2(v^Q)n;_K`z
zqBm5ywsiODtzp^dyWl9)Dwte)pk+2Ajapt>?ICD6zGSM(sgtNxUGWb`>QwMj$kzqy
zEhyqU)w~T{t~}&wZBzYqMTBC9n?RA@rH*_i@H_bj<!>B){#ZamePl7{yJ~9<7W=DD
z>9e~;Bl>k^%0rw3xWHmWjy_;a+9w}`HDb0_>ZPZ3G!)WJI_i13npwY-I@J|F({<2{
zXaDI4wK(3NEL$XH=THh{1_vkI7C>n(D6Nyh6!|>Kt>tG4#pFlOpp<;NbDxLd8aOkv
zM#IYhwlC4+$W?6X+EK%lLk%!UDVN<Wrl;7@@)V8up=K^^KEaZnZArpf@Y1hwKzY>u
z<I;4AvnNwep<`!(W|7o`4NxFV__(KxL?T~Dy$Xio=l8@?ljS_bVX*Ql2PXvgNkxG=
zah1OE8GGYkw(B+$Gc9c2s}}Q#A!^7We$(9&B&ZlZY5$dGC1b+?wY-5wBPc}8$T;Xv
z4=|jOD};+M^7xk$)wiAh*?;3fNFhbuLTPGKM^%=(y5bw=2rq>L*2&)f+v)j{adsGy
z0XdyCiTIUOqz(N4A)J{Vl~nkjg)f|{5XtdW)59PU_zbUn%6}Bh>{P@!U9Idda`^=@
z9~ttx>v;sziA+p^JH_H+G0mI_B#ae{J%ot0F?M0)IUTK&LN7Kzhmo1r0TDlnjRyDP
z&rb*JJ8UoN4Ggr`tIb^S!4g{5H}9^0PiTzm$6>GxBs3(<HDn5F%AZ!As)q$-O)*D~
zs?NKp*7zbg%&Uvnw4MPv{7ggKEEgRxb3_qcs~@Mo-_x@5CM{*CH}iGtq-huRdz8oR
zMWb9DN#2mHjuMWhkMbLOCX0|y@(@@%FFtb9Q3^0+(=gU3{eaGIu>FTV)ntG8f{C^)
zqL_)#EzW_Jvs)rfyL<=KgugnMA!Rs~(DfA(nYs8ahbYCDb}#|wC0fuQrD#p#qEFwe
zjP@Z<!^ZgNBi2M=5!EoY*^MVXKPA#qgt76s^vUo=hvrP5uaBlnMsx|i`V}<n6%_*I
z1fSXPo@tS(8j|}Gv``5v1p~{h5z$@DYbfFnp#(JpZ?ezhBNEaq7%7XP#l=wK`-Q?q
z2_wFAwwef(*(x48DM@`Pc;dEua)Rl(^Myo#&3WhE#y(<VUQz;K3Oj_Ji+zrMh%#fN
zQ;Z`iAuD{ReGA_iOKzh2LL&3a>MSeuGSP&#)Oidip^!ws-r%aKXGQ%C1~Z03lC;H<
zf$;v2yYK!&%dBlbi*z9?rBvFDg?Ee{VpX=GqzL9!pS>mO6{VZ!WcwCk<tlTTth1M^
zU1<v)eeyebPeS~nbRE6HIIp>9T~!>w?X0isTh1+pWB$Z85sX!7Ig>Eom?Xf5P!+YN
zj+or7D6REPK2NFCFP5X(+IB5}Mwm+BhKEG8wfPb!c5MpEZJsOZC$_qjY&C^MduZ`_
zOo~-r4Fa$EXhb#IAy2kG4z^lS!N763-V>U^mO7F6p-j_PKlwBrbqbo39uPwNP2gbt
zh`!2#&1oZHV@a3QPK+P%Z;r99A3t5tM5^AI_iE&9WO~hZq{<?kZ&(wA$ilfcJ^Jt7
znJJD0QyaNlk5?(t^ay!;?d;MWK|<{FcmF!+57NZ$u?;Uwqg{whW8x@NOlphXMmGGX
z;Z{H7*E>^=pejcO*&@pFf62Z7lZ5|29P~ZMNivC9J#f9(a0?@QUn|iy$nbu)+}WhR
zahVgB!hQa2+Q*7h&0ba@6zWu0tvJ%q;B_Q7zESO(?7-cldx29|*zelT59E~&d?wU(
zl9JKfHV<4(Vk6FOG~&ed0x#MbH7;3tou9GPGXbb`MnqLZ+6r!~qw*6jRBMwt<286K
z_JZ?YpB27U_z6~Zdbw&fM%{dC(>C$`!&7zAek!8JcwR5**!f4dGV78~(B={Y(Hg|!
zo&3R^c3iN6{S|ozfMbmGF>&DsCh<Px@f7=WIiwzT9I7bf4VXqty@m=VMtt}+6Y-L6
zQ+2j|L;&+@jq_i|#<(+3!J<S(OKQ?On#2Ix6lOk>f7&u<gG1k_!$4(b+-LTLMJF$7
zx-+pu19l~vBbCP4(%jyV6e=xiKJUp$i>T=O=Z%Ux?Tgrd2FKoi+h9W0Z9Aomc?dQH
zIY)R@0uF%Mn!$3YAk>f*#oy4zHWt3ZSuIHPYkeq`bm(gkcTs>jIu2e=euvWKt7^{a
z)Ysf_oOm#13FLdq{L;`3P;JROpKyx+r2^8Sj?V**l!3_@d;yIcLtQ~DobRie7Qva+
zi5Ad`oj&n(!olW@3@)!SRdkp}9A`9t7fBQ~IgL1eHt9<av7(9YqJX)V5fz{^n5u<V
zc|*3DV-#OZyOrA904kZ36$KvEZT*xbZEV0wNz#V#c5R(9_kWQVc~^wTj%97orDLv)
zW!Om5ftsa>D=jp8`Qyv5JzF}VTNvP9lI16w+L$BSZ(E&Qw&nr(KKj?3=KYwavU00a
zfmzuR8L>_@DRWxV*_O$sW*5qsyTk8|Der9Q#xj0`5-1+NpH^Cv^hwE<Jbdifl#$o&
zG*%hcBr69-;|C>6<t}jqjv8eOGkA3l>;9uYD&G94S319(8h%ExjhEe?hfOv4RV?4N
z<miSmH~M+^W_deoFYK_dq2G0B`M|?Z_TG(!T;TunNzJG9C%)fl$7~q^%jWHVs;;-d
zyfsPE#-}5lyOP5evXi1uuecb?|GCDBS#vYh=l9wz#~cW&rd9DejlQ=v-=ZlSdr05g
zV&Tt1$%XR&gXRgYkblt1hplGcBs{$%@HH=%F6_o*lr>wDCw`Y-|8{M50ThLELR)@~
z@kMB`^Acaw@{0O<=bRngXWWU0C2e<?1;N7PEejp}fx$~=&bOSFieWmM?owMV_rAK-
zcM6XwVwby#<&~>Y>;<!tb6k?TdKESMiC2E#L<B-&zR~sTiUkuHJzYn!te7%KMMA<D
zUstQQO<=-}($YfDAeW&yle3f`8!_gPA5u>tlQF%iA)H|1Z7iyx(ihxpIw-mOw_YfG
z#!bm;yi0eit=5tq!fi1bkj&PQvu2V^c)y^@rs?{Aw_<#Vp8*$(UNLajv*ht)-o(mP
zUPmQ`@<zvIMY+JX#8tthQc*6Z@<IBv?%Lko#U+7~i|P1>l=J`%mz4Mj4PRrgpJg7F
z-%q*I40*eh*f?u}w)m$%g!GQeGY>T1PB)1t$oSsXn{m)|%!(wKEV=7im)p7UFeBGA
zew^R%us5k3Np$5BtG?Al&SP4ur1_qlV(jH)lHc5LnV2%>$<16)Q5Ogqjof+WX0D>$
zlus~Gmkxn2_bZwg%NCy7<DET46o|=?;J$I4K0p5-HzaH^_8t%4n*`dC!O@x~aWr@W
zRxxm&ESa|Nin%ETGRoYfX5w0Mani6MJgg|Ej@CX8kxbC4_=p+%^L9Rdb*MVWs%)dP
z;J@;EN8XA)hYoq`(PIT<*Eq-8N)JCQ$%MftWp=a_Sqtsu(vlLd`Kb@ort+V)h&VH1
z7M--L7nnTD5KbQ}3*+5}xno<_%6h0IORft|<k`y3dG|fOP%ddNwkw`RX%JA1u77fx
zR9}4%SNV*ab#bns0FLi?I;Jzc^ijs0l=RXhQQ@D1^vv>}nInx78cC<%`7L6?Hp@|@
zn#T2`u3s7(F`J5_ji%txvA-_ZPXoW;`}AL*@Fh=1B5t*&c<uRC1teAF^fY&SD`68L
z%DaV<o(pA;N(m5jGpfDhcf9mR5*faJ4F+5C#GLub7^`;jbGF1TwMdmD=S<A^ys$fJ
zJD`GQqW)}G-w+xk^AJ4=07TEUyG9X^3pSEd$G8T7+N;@r3(=<B$Tt2{3N*yCTP36U
z^ET=Utmz?#sJ!7#N+A1!bT>JP<VlFVT1<4up~Bj$hL`jnn$)Z=@nz(&=k_c|>HRSH
z)G=*J-W0Tw^XN})X)_;;?XXiq$rmskd5z0y1ovTYQweko3|HF>=$&6}++B>a1VNW6
zGrXT9WJCeZ=(={0P?&^T;;pCL>Yj=+h-eVy&pk$W3NqA1AK|tS3mJjRy;yHT3X}d-
z)Tr|Aj#l3rr9&@W8$KG}w^~>^I&tYTwENi^eSP5rwg~<Ti;M0!g&}+|Lsg(Bwf3)(
z(h9iW7~(;z`u8}+n!cq-v_nQ@&Qmntr<kb$wt1P(z2wxlhg0_*JfNpBg=lT2ivFAW
zZ5H>?Ukr&K3d5<#;V|Qe!9Q|ugys}iijjJPo^@+uK3F6X$mc4`vBGWXP-N7-ax~zH
zX~NQU6#k?bQ0pJ2eP2TZu!<DqD(5wph99&@-F#R@)KLS?ZZ|b&_l^$UMcg~7eO#M6
zZ&Lua>j3gh`yUzG?AZ6x-!}G-BLaG1;hn?RKQ-$AIy(6^NSY(W(XnYZ+J0EVp#P|%
zIoW;IViI3a-}u{z!u#6_PiD<M&(f*U8qaZ}2&qtQYZ-0o=cphyjO~0-D2RxM>?!w(
z_w+kj?IlfO$I;nW)MT5jUY*9peZ4TD^*otxO7LKn;iO4zVU>Yy4j(EiFD<8zh&A{_
zYOde)UEiaN=Oa{R!&q*qjiDv1iijm9K$f)6NeC?hscL$7?fJ><Y=9k;^*^<M?#f&Q
z8P1|w7pT0yds~5|;G%54|F6oV0mh*Yd)%@r2H$8@bM$y+GPe=|*oLJ&{TWbP+(!FF
zPSi{&TvPPF)iu-co)?Yk<fbJzZ!)c8?!LJ77zm==tNVGmE%J9^M_8*({Iurj-f-~U
zU%9!vOg}uPJ$M>F(Aj`_o}NYS359Yl^^W-FvmY<|RY0Y`M^@aF<Z4W<JN0!~)+t;M
zV|!L(c94K&b=Fbok#ATgB~?5?9xt{>YL_BGnT_MJ*>70~4q6vDXfZ)(X7_d?*1Bh|
zpaOCnB0@cB!N^0&)1Ze%rkTu?T5L)sPf@~vU_2~Icx8Eg^lPMiIUkUiYM4n*Ng>WG
z4c}t0A58p_7QMXeMZ|MONO&yzdzpiZhT>ZU-gtltmL@&E6jglnGG1azw%Tiq?yqX3
z874g9H&kRal|1AWpWJQDEEPnoLb1n5G^3tA7%0iPnNa~0QVh$PvICdZRj5)hc4?xL
zU_tZyV)b@5_gD0c_!ts`G5XamrL-}-aE9v92>+6{T0%0}*OpO7Om-GABzL+)`#-}m
zlmE2V9eVX_<p&p-R}Qls?5abM-E=d)KG>Hx={pEDMoanJ1%y~jH)Z}~|6`mAS(FHR
z32&<r2h-WG$ivb{RM0=7nXw8lm-L&R)}GE~;%7$vC%@e#-dt;NeX}ehj^I`q#Ecl^
z1|<5f^kQkXb}HHVj=nc`&PV$SI_6;>e?I?;YKzd|!ByAP*m<$|$vZ|!2FZOZiIdmE
za!WKJMyuZ3ibt2Hmgj<ERE%lmLP$L-rO=G<HYTOMu3VRoQ@Sr69KsYxS$aVAa`F47
z?xIr(Y59$^`rz79l>|tWZ;8XY8@%Q2kqjyk{uz@y*zs|zA)UaaRWHhyA`&|_RjWQz
zO``7Fc+j?4uT}9teJ@&hOf_okb)A-T)+EJWTq1b!=H;dKGdGf}SG}en^;r8z_(Gkp
zrnr{Q44+YsCx_$O%1_DDu{yinl!#Ze)V%F@jLWy!PWfVm?~Bhl8%ZWs`3@Ho+&W`j
zd<sBn9Mw+tAHz6^=huRJ^u&Rz;y<DEq<Km|K43ZR7zcS$t?*=fn7El7F*So-&;uzc
zeMk)(%r_YB)XZ)~pmP32fJNcEXZUpc{kvgi(zg>L#gQyJ4zQI11As;e2KQg4AxDJS
zoF9-2qz-f&N?~dl=O4(9h}wV;_|^5IxtxgB3}*N-<cA9FCTLH{y!p#6)iazA8;1oG
z(R=zp|3wEN)C&9Weue*U2f=I7gmDni_9j})SYG}!$l2fBfqO1iQ$4F?%AW`LhiqAO
zzI@QHtM7Uvg*!Xy`o4ExKtq%@`|eK1-Is1jGLP+m)>dvZGP1RGcCv4!*<7!*wd`z*
z+N1?BvT3XT?l(m8lXL>yMET(0ps=tI+(je{GHN=WLWdLCABO(V0arJ;<ql^$$V5z^
zxxT9!f!b?n?V~m{k(`lPf_Y(2?4ZD|3($8YT}CVck~#U}$+G49Q}=}89K0M=Wo6?;
z&p;0`mzTZ^1i;W4I$RBOH^{g;mLlJKVHR}R7vqT$$|I;>JP(42!xt5iQjDc@irJ8+
z<(<bk&6OoptFowJOh24@^fPic=KH#Xy`VdC{hbI6OEvm}zK<M|3HII3&E4JIY8B7F
zc0a#p2)cf5dY8y$d)>~6>tcVPmBum+Tk}%I=m}d+BRBM+NNbrsvY*`2)>^5U5spqH
z%AtahK?H*HJ3uo4J*Zq5M+^z)dRD_iW!zgQ;xcN`S0JJ9&^bYgD(qer3PH))2;LhP
z?qQN2t#F^_>W2qCdMdId;hU9!P(56Uer`-psw9(4@qv^tpcr*;R~g_KOBk5#&(5Yt
z-232z#T?EE3j~tW5-Bz0qnoCbyC_V%gb6yl2y)5rFG6I{!ut1}Kwl4A+w)@COpy;C
zz|q_Q{f5A8!IlpHxTqWmx`LubKtyQ4^H#x}jYW`ymk8LSLco&thWZ6e>r||Mn~WJ@
zg!P{|TMU)6vj6$#V9L%@%TBHh^qiH5rCcC@cLEfSdG8n8Pk-eqm)$43m9_@;AY@A=
zQjW8H<~k${Zcfcq#ekk(S+5NG@PKIvXTX({@|k3Np5@_a^OhtTPM+ilb{iUTpI&r9
zz%wLwfb8=iYjnMEy5=e;0c=m(pzdFjk15B?UdAuq(9zLBv(|qem%2AS53@nt%7-wt
z(S4^tatKyLlnC006%;w7%)u`kMV<-P|3kgkiHfi#Xd`rwKZKJ46^uIyQ+E5S?<~lb
z5VVm<h{OhRo3#&hLMVCURFn~CUln=|0_5t#7NHNVdEV2!@<K|zpc#RL5(R*>Aoqj$
z4iqi!`|}DYsK5aUm3z;)SNWADBs~<GZLaZp{FD{#CVtsAuO=g3D8J+3PDRkB$Oqhd
zXLW52+_J^m%1YqRFXMt4M1ZB^M;~aGt&8*Kk`&gzg8;-r`FUNQpyGaJ7%OSlpaE~+
z1oQjX4ndE*4GTvm%-+IGb~e|%C;2WBi@ktDn4mz4P+n?mNsB%)yqFd>9Bd~DyHSo5
z*kU>-JRZ=YjsT4Lwuy`D7jce%9UlD_7y9^hf$^`D2)FfFw-{`&rl&6l|JBqio!*V7
zFhzxj_c*Sbyk$$bi`IP3BkS4vV#kdBc^Vi(4x<K0g=m4o5;Cg`IDaAVMP?NJ*}hDv
zR!;-3TkT-A;6W`n#<Twe_A?3g>LNS^U<Su&$Td%Pe*U7(aeo80jr))9Ux3{9x19Hj
z5oo(bcN6lA#6WAnFM}2xy^L7#;gNA^D1RaXvFyViA6&{gMSYpKzGS9*B#{xM>FS{Y
zlbyVP1by_rwbsv~7AU~tB!I@vr10gAeU+<VeDBi89Y$v2TV8OoZy>4iocDoaVOr52
zDbOFk7qth$d!O(L?zaL`*oV&AJ^3~gaJECU?SdP#S(ZF-r#~4#OTKxRr-Jpx%VkS>
zG;B2xty2b-fD(JQ6lEtZc=ZF_70Z$lKo1bhv!?FB_Zpbn8dbmI?m>dqHFx^ho`_Tw
zyT`3~&KnViBOIo80SoxEmTA5flqf%`T+L)aA4_g=6al=dq#U5&-349K(8;YM;vj{j
z8$VTg$D2e-2LWzCI6v*j?`=9x$jjnq_PXUmG2gb(PfIf`6Ni%G{PWsM*#%@DiX4nY
z9Ex1IqM@+y<iYatSz+?loug=un@FD7=#KLB581qLAap#@2&xbDW~5vBeWc<}S*4^b
zV>4`kkcOJ%hfkPCD(kgJjj(LVX-SE7EV8Aic3|=yF&-h9m4ixuqdgl}*w>t&ua{lT
zMUDt0OmZeQm+=Pl9|lVr*Y}egi@ZpTvSC1Woe*oogiD=f{e(&v0g4_t6}N{505@aF
zkHRVfLO*_Sxx)$(K>--S0Si&07F0qA7=ciL3sz6R5O?{Ttc#5=lsvI2+EGp}9WSzK
z3rkB&Dj^sQUcGu~AxVD#h5~FtG-|{#MS?m|UgR{`opjzo`#Ug!AX50@aistL7&Nfr
zr2DeKHMLDU_fRFc+^dNKl<?t3&Jgn{g7brNVKJYWWbU=GFd{jzY>S$#^=L3Bc=g~S
zZ!AVO@#lvSy4=f>KaBh;-OfNW6?oz21w|A_TwrdualjX!CR$qzNMAk_Lr`lSJ$;^9
z?VzfXdNs^?mQO?Tl~(g`#+aGLTz&jvb}dorq?sYR${rqaFkR!dhG2T>HVWsLq57FM
zj-&RNjS1HU_8Ei=;!mub8~0C}jq`ii4!cc#=W*$+R8(v`4n_mt2mUt7=NGJN9)$NN
zvX3jV3bM`RyU)tWjiY^Y@8g_FSxuXH)1r~vB;(E(U8G2DlbvoY;5l`%7ye;!NWQE_
z?mi)%w>tAZw(s`TcZA&y+wMzQY1vIAF1>$4g&+goS1P4h)yT^J-tTOEd2!NgXKY7I
z{$0#78=Appr{`I#rA>>u2%1nDGFDYncIUiiTM-Tg!s`CYd8784O~{LxK!~npo3rJu
zcFHn-W2!xApax^hO`y{k5GdR<>p!__f&u`kwSX>Lsx|z)n+-`gIh&xTsa1yh1fE61
zb(^G_3qxa8!!OQ0xOB&)Dbs3|x-g37|Hdn8PtKhVXANAC9oxHj|0FnWey<9dez=f;
zmMv*|n>jRj#hkWQ0Tpf*_3=sCLuui3Z?;Rh=IyZT@v@wjImw+KLe47jn*I~J`<C-j
zU*Qu{)n_wzVx6`Y^jTR4;uhkHCadvpT|>{FN|J%JcHJN6)l)^OsH1aavA%;0v1C5C
zvsn|TYH(s<24uABeh8NM(%Qc8V{v5P<NQIOr=%x$EKN9;SG$)3@g@EENZdeCBt+M=
zj8kpKs-;D9O<A3oN(yTbS3IIoci~{*znJd*j~Pw7v9D&w<gvbk#5msg*D)pKVQ-Mo
z{Hby&pFD7$8eAryyrPo5zue9_(ltcMmJd-}k0-!fSrXA6<rKBBb=C`*vQ5isxR0zf
z)#7MhqvekMS=J<J$X#|0ibv<~sY1T{T2<+iP3O?djg6E}CqQgTW~pa6<5spxRmMC{
zPhOwWyUcpgEB%x%M9OdFFO%3vGoQm)OqEgB6e|xxv!@JRbk{<<$F<fKEwGCO>GoKi
z+*Rw#=Wp-*zBEWL-<`N#9B2C^^Vmy?yUp@SuLU+@o!L?!SNl2*U3lLz%QS!CE~kp(
z<50hFxp_RTad&rJ{fE!_F?h0jN#D;`i9&fz!iq@J)%7W!TTuo+nG`=cer8#{gj$)Q
z-Kfvzk^~%ClFAC@&!h1JrY`T);vkxe9c05rxPwoU31?PiaRa6ruX1J+xMR7jB$=ov
zYCvGlZ2s<J$V&5@Dz~TV#8ezy=h`|Dts}9SkPgqsYS<|x#69<9I!U8V^{F$^k5dzf
z-7PCfkv{I|apd1M&;{W|2D{Pl#N~>HnwTI-MK;eEP#Zv9Q_W2|rAVcXpVu_$3CG)F
z==AdFTJDd&d*w<VDaEU*F7^T#hR{-vcA?*@m=BsP+{HnTbJ0jtD}7-U8>3&_+ecGc
zViAAiTX^|;72Z4f^&r7|NV2IH-gya*8pEPiQ*x$~IJ3s;sbNWKt@gs{z#QKLz4K;L
z?3v46r7tpXg3y-skp9zN^u|vM-82_LM-AzMi)H<`xvA(d5R?-Mq@|EcB9G)znlX)i
zWC98HuM)NeY8w`QmpzUh753{}2%e@f2n|>g2{JK>)cdL>Lz0pS{AtN?>WdPy8@}Mv
ztCR@gxfrqvQ2Xk;g!$bgRSP8JQ?(dg%cAr<jy2*{v0L67og>eVwbZR|A`=g<JvBlk
z?@OBuTl*bMcO~TINy==`PRde3c`EmieBJc|uvb};%xTVO60LDg4E!ALdZR(e48+OK
z1>f31Vs=~GsaWm|bhj*C*^=;<Ydpa_DY0X7Btni=a+1#IsGD?4&i<IW)%C9-*Zs^^
z3-le-s<^0ko>L5o!`AHsl{VP&mwOcxp33b;C9a>I@LV7PT`jGi=kkwT;-`Hok4U~u
zn)E9dW7%$?_A2p#nZ0`Gw`ey8%y|Amz;#w2XnGYhJ(DxuceN%YCf%2a{1%MX9m>iY
z1o5rs0LIwrV{BlfgSb}+KQK<6xSOuPHwe0`gh7Enn$0PTPzuGGDNW9b8NR|=51c7;
zUYKW}q5S>BWNVF^k}1>c-lDKV=c;oxQ^!wV>1D>+IFFmE!}7Yj&AOgS_5SxZR8I5%
zpmb#)#BopUV0hwF6m{aVSPn0l@SRPs(&PR4)}@Cf!&>k~PQP}-K1Gt0%uLCO<3j&$
z1M%*j>F9Sxku9Hitjw<O=f#k+TkJ=zdZ*!ovCdAgd1m(0%$NUe{E&x1fljWmu97r9
zJlIQs=%A>q$P615(t#8uC&~x9Pq6019jOBj;@CX7iqP_4$;7%&V%ZEwGV+DMnJ&i3
zhYlK`<apJN_4`*nF`7KU3yl~e&6~A)uxv`hDKoSpxm5LkvG$fxaWzfb=m0^21a}P@
z+}%ll;1*niJHg!{KyY`r;O-iNdvFGKclU2|KmNSmS?@Y$ogd5$Gh4cMS65Znb#)aj
z^uHtgOIU0Fin&qomVdne;W#dYE<#41vO+V0Y)1A?y^V$0)kGq8VPWhKyzOyI?2kI*
zDVYNp$GJ($=76Q2I)#f(s`H;@_A=5P=yyN+p{JT9FFz2`#{%S+*_fqxci!ase8f0m
zh54=txSs(Nq#%J0LsWEV|8rAoo_4vA>Zhik{7iHj3`1{ZWG>c*fjky8%p{*CG*T;~
zcYt(iEfgc|BxN3|QHeuBN@R><h;XQ>v0M;?_dw1HGluGvSUwGW;T#+tGq=WaF||wv
zIl<L0^-aO{3%lA*=D#=79OWD8%lP)h{*ezu@j>ZKgpQk*o4*A&?kZw`T%l)zEec^=
za%euaq<Em)@roN#o$5_9!w8<ndsz=>#j2UG=43*j&~%mHrnWS#SIO6eS>aYqz9>iw
zNavvc%;>vpY$AQ)8JQpfK(yuqz)+7|7%zDqhHkvA-NP)LQdBTcV>{3@&=t|q4*M{`
z!)jGTL?05AuNc|mK1EKH0M4zOj#2o7NhVPjt;ZM+O#kO*B1H^k0xH085ttEpvgyo}
z$A7+-5-n1n<}bh1|MmJr#1k}?-?eu%Q_05QQO@hmSeN@vRWpQqV3&;n5S75lW`m;e
zUI9f6RV?5#5;w$_3cN*zQm7gWX{uTF_>?<zWuy-(P7Mllu;E7lkFCL>$cmuWa87qA
z9y3ugMgz>_AYa9X^l3K2sdrprL3fra<~S0a;&c8(P4NR|oY+Ejt%#*ZVZ5Ghm4Rzl
z%z3f<I(ZT4!1E6UPBZPw+Qe9?x%7R<?Z4ZnhQmB7VU4%79FsZ^tPU%=j$bF9y00{<
zwVI~hT$vdf7rwCZWNa?vP!u_@dgjj4B@@P1XZY)RS`JhY%Gl)b9%%7eJu}2uPQ`FI
zhdPxVS;A4Zb1|ASu0(Hz8+a41#)%!YFmJhpCQMCC1N(aU$>+J+;mQJML`^-N*Utku
zq`TCqeppsFO@G*ia=a>9$5BW-a`3imeF~2_h~kK@_dTSTymr#SJkm({L?uFS)n+Sl
z=;2KMt6jhBqP9`~y~YAJ8CzeuY6We^a+PXwY=Og&Y)sxs+clc0m9+ynvEQuigxl`5
zQ#~3JJZ+eA&<!Hnh}O*E-=dN5(KI#2iKr)qTDh8HBX=;mgP|vz{GM-ee2x2Wh!LH=
z$a1h+wHxbt*x-{JGASXCqFMOaP)Rz4xS;e;9$`}6uXr;p-h~HioI0(k^nXhAUh+CV
zrM+|SMx5RRF4B%Iwk&r1c;9qE{|N+s{EN>Dhb{b%BpCn9hVef?d=oT8li7G)8jv1s
z#kCuBlha7Vkg*b+wsjvH&Ep+K%E-A+KF}+ds;`~B!D}!-f7elt8oUs+@SfFHN)p(&
zJ=C#a_41}bwqR<Q%Lp|!GimRK>v`JJ0BTS{xwTz9Q<VpARV|EM6^lu~O9Qzk_`p3}
zlif8)cNVVOs{1I48aB9uy7sY#Cl>@{!(dJjV&lf4q5dmzmJ}HekU}HJz(c=8nUq-;
z<Ifu*u2D-4OdnvYT7ZX^u{!|v_r~{xD+%jrSz92-+aJyi^1V99J%4wQgSH`1o~}Z~
zmC@Awl>C1cmzEKPVxKd+r+pzT^Pp<?C+J0}<VdP#F<V%or*}F!043gMFHW%4L-ygD
zSy#Z2q@=Skv^iTh9ae^$E>-b5Ih6frNUT$4bL*=E|9oR2+w_MA$df?eoVZc5VjBnW
zHs!Q!<331W0M6!wQ*y)gKYZ6lTlI&3XO9k<g8!Y<$x@-F7Tv5%DudFqB_X=s+bU4U
zL5)aN#}9yb;PyPGRyqFqsVo`e&?0RkT-=z(FVT4=bkiXW7E0)1gwkkhz_&#kp%x26
z=Xqa?Vj9b<!^lfyrXQxjUr=RZfU++SV0`p%trcz2!1cZqzIx2YRe;AlMYIHPS8KPE
zmBsTF=hJW&m7<NP7nBps4NUx|jmv;+fzcisD>qV~fNN$n^QBtrSut4|P1Ls>XqYZI
z(>$T{on`Dl0Y5&WMK`wr(ZDb6M{O@nJ16!tjkU{7$1Kx8ZTaAt^fx6b4aX(d0uv3h
zE+zN(AKE+(+#YJNs{V~{y46jMtqJSf$ZBg5J})8jQstiL`k^69B@Ia6H63dIZVO8x
zWW-;7FeIcrP92;6Kl5_LCuIo!9OOb%qE@09P-H3j+1>VlSJ}FrB$>=oM9!_d@jr5U
zg_k9Kjh&ClsE7(4G*ol4)$sC1*PbcRc+RmV3h)U0#M16!U0$jjLq#3C<s87SdDOi>
z_8T04CaS~_V&j}0dY{$QL<GV(zvsxF%QV5F9gu>0C402X3t13}dPoR_S#KTnuRh8$
zD|2u+yw^oFGbp@j>~x*xj+5JQH<6CWlUB)ttJy=HftggHv}$Q7?@@RFueu2Wp|JF|
z7#4LCX)o*YzaA*R>cdTqR609DnR9u|;m=nwv{pZ8H$Ne>k^!r2okR}YxdbhisuKA;
zJQ$oazZLa=3ww7*u_wwyCEGLyNGCFcGZYJZQsrYVnkd(D{!9${eE!Uj(q2w&&w7i|
z&~L4Ug%ML6PFG)~#Kq12&0oE<$4MklAB>IR@5!qV)zI?(56@ANf0U+W*cj?>F!L|w
zHU?UyJ_;}<GXB-&mq@U2UcBmz3lps``M?yHnWB!Pd0HI#fWP`%!1v|QPw#Ii-+7Bz
zPh-K@x7{f*-9);w?v6Y?2+))N@jL?SJ&$bLh&9jvzG`JiSX!m68A9_hOQ0t{w_TrW
zx@K0HgnJ3gy9CS=IZ}yg7jN_4Uo3VWnwR0$HtWOGvl@RBr8w?ncH_Q|t~Vf@f8&T|
z3mX56Av&De1v_XDZ)d^FE>iLp-w*?vd}rv+eW*uE-NTrC)eIHQHsWy0kR&BllNIf}
z)6BRA;x$_dnW^KS6iH1j&V93=J|?l;|IhGhv4s2GH5c1l@nL{n+Lv_NbNY6KpDNdx
zdhF8J3rmjl5#U*!(9oyxm=6FIwPd|ktm{*_l;*f&B4J%LnX^`@JvgPdL6QcQP;wx0
zEZ}~7JD?R2|LqqA0(-T^s~KSuFQ7n-;RHSLFa;ZY7!~<FCP=F=|L&jUPk0(?iYHSc
zl{$=@J|XIr_E^cV|H4$`z9UrX5S3ffDBJme>^q4x$efRM)6hQde9tBsMm7Gys)HXu
z!~J?>M4LRc2*P|p*zA~FB9&_W_PPT=&Uesi-u_~=&2{>2W;Y#jij%W;=+MytAj<Z#
z;f}IFVzN_>wb0tm^9sPo1%W!@MgjnBJ2XSXH`fshH}3GI-VE|o&l~^kKi%4BrE*<Q
zK&z(jsSlF;r$<P|?f)Nn&wM1m{5v%>iw@T3zf!0u{XHFuq*eEXaY3L;;=!qZ7kKa$
zHq}uv^yc89aa&p2{wzTb`kaT_6qHIa@%aI4C$)!xRKNOjUn_A88Lc7S#18;jYp1l2
zYLAYavF@+yQc3oK4uV{p5ZTzz&jI@7;nZh)cWyH+u-{*kba!d(pV;h56Wi+u!b5fT
ztmi-leXE+=j$HFWk+8687t6@RO+ERW=DUSp3W*9?prQb>pv_3Fla*9&P1KeeQgO$!
ztWR$KIg3`V5`~De^b$$>AD}462gte-bbA(^UzJQU!XgNtAbI*-Cm18tYHPxX$Od#Q
zjjb&U?oO&btex<=U8*}DCwD&~Uzf)eC&$_Vk-Y75=gu(=DPxmR@j6_l?2|0iXDT~u
zyePKU_R<m)1Hagu9QosMpLndCw5su+eXch^T`=VoPPHT{_xn+ERQ!qS=5s`w{(7)F
z>~@Ah|5E27*x!x@P2zp=OjkUlB0FgVyv!ZQ2~ruqyA1D?hiL%PR;Z~jcuKhYE#VmM
zXXx4iVMG65s2{9wk<)m__s@Ss*c3~q{gS^LKR!&wJ?*;Qweiaxh<E(V%wE4|^(t?K
zNV%l)iQAy$J#jUSPF)#Z!7J7c8c#Atz~3Lc)%^YgKV=bKtYBN}tDO;Su`{<Qm|&pU
zz{xSwYU5z+_Nj-#RA&B@QD|PNGKa+$ib<_H?PT6`%hHJFy@u+i$*kSD!^81N-VpZ~
zkCV7j!=|<lIyhF_ugaoh%ECz@2%+wpJL`V8tDVh;tNI=`V<RC$Pwd+~cZGA4yeI5J
z8lzJb3rh7YUU!R&=YdVrMMJ-l3X1tV5GCFw(w|7q6^$7$w<9I63#iK@rn}vR+Tw0Z
zcgsYj-n7={jo5fRu?(pg-B*`d6OJD8O~=%~V+{|J+GbwZgjZLob4#olQ7GWe;kUPa
zpFy#$Xh=qVupzDWS-F2Su)1(ioLG2qVDsvB3{@EA9j`@6{_;BFp1PcKc+WS})G9Fl
zukbxvLSm!?DSW=GItthp1=p5FbP;EJT+54qxxxCu>faoj1-2(6sKSewt@ryS^*hf3
zHP8FgC1&h4FviCPak!gb_4N3@;Oh$o!$$sYAZI)d7+=!jBI-drju2Fv`unMy@hmqN
z-G^TlykH;C%3}Gxd1KpB1sreNagO@2+$<BIcDKP=J&U5e5k@J_ij(;N^xprV4C6;a
zz-_nL8;);bVG;64q;L`w17nkxylDtRDdR@Sj|9$-i~L+FS--v2VQ<2sqOI3<F`ia6
zOl+fOOyFU<!t1I#1bwgV=J5Hq4|VS-!e}@D2e+N=cMG1cr^-utQC|S{>pJeID+u28
zU0-wjW<nNxJO#=zx5UTC_w@9Pj*jMv-)L>eACKfsXT?mb@hy#4ff|21r2?muoKtkT
zCx?9M+PTnfaXM;$ICcm2T2fI`Mi2{nZS;m`J{_6>g};n7Oc?GWx8!-!$2rF+J?O1)
zNq?{U3vsoj=t2^|>3DM*Gf3hh+w=48cLa?v${Sncm=*Qy`}_NRsYFog<2g`|@eEvN
z0R;sGR5Q8<w$%av@Y7+<nDM*4lsy@86gaD}1-Yw{@@c6QeXWKHE4{Bs1*B6hnz*@*
zzv+o_Yad{+W^z7E<<=L>sjVRFx)6oSvF~5uH57_jf1zVBCB}mb%=s{pyZj4}#@*ia
z<LgMdM(GanIUOd6<+{E+-56A<@ev6+9nNiUQ;uDLx?hYHBS@k?Y(Z@ZiR317%%?+T
zf1*ZNS3z5=&*0Fd@X2RBQ5|IjBG9Nv+J|qi4qA<-tq`H!39+HtzN708+kYOsL&<^;
z(_-UW9u3EXL6`&oe#iLQ@sp^PK=n4AmpwV4GF3F$%Kc0OP?YoAMlVv~<lfB#P=#W^
zFosayySVCkZ<{rI1N4L5aiSpUYO#r$cwq{mvjYW_cI@F1BuUs-R6wLF#6v^FTWmw%
zQ#b8uUAw#p)Jx`XkNzD&|9UUEXy73O*sJsPp?bu|vinIJkmMxuag%CcVF4)1<__S5
z8Lr#7^Y01NK;x$DmiY@-(HxFEbQC<5(?*4(WYPN_)zDcr-|6*YWER0H#|jp2LDAO{
zp}d@eCQb4Gyva?Zw4{_&$HUSIP-_Gb2SF)vwEX;h-P<ng_Vf6P;10n7f(iCX1RsbW
z$?2I%hw_S@pbt?C>J1=#Az=v8WEuEeEO~fx{G7M1<I*idenOlK=XVMq;oc7mE3fq#
zAv|_J635($76f?Qq|9PfY0?sKP7SNfek1z`sue9*%!QvXV;}V#&0?%EXTt;e2<&|L
zOZ4TIZC+4ypX@Jp{~&wc{?-q_Ju}8NEVF5zd&V>w6R{nWT2~T^M=D>;#Y<tR_s)Ny
z=s@*?83*-jr`XvH9Kn<QHDa;OgKwe|NNRSZI9d=n7Q|JJBtCF7Gp%X{mkZk%;+qp-
zeoxCy8&LR&@CSv>Eqp*_Qp{$94469Bl;UrM8%1;c`J%SEEH#vj$0&#tgplKyTq9%J
zY$RWMoBTi3)3tp<5n5nNl9^00zf@8x$B)-pXboR`hYhqw_@|#D<^T0v-<z5hQUFc>
zuBqW-(eV0EsciA0{^Txyxjwc0Y`Y|a(2o~($GSF|B)BD^Rms@0-M#X<v?gav{ST{}
z=XYJa*8FRUn<AB73!A3=1cGkhtUo%;-|Q*uGgwD|WGozx${@l4qhm#K61V5@?i&)e
zrGdb~>8gv7w>@veLVXJ(8^~)67eu`1s_RC6uvat}wBtk$0wrSf`0iX=a;Dc0u?e0a
zmr2z29|@0)NevH8wZ|<tTa4*UKgKjpvQv?fH{LkNjLxU8se2B@#b#GoH_A>Z{pzn(
zkBS6!pjPUJX?P;pG4z9BLd53h2RI(o^YY^-t+-Cl<>BJG{K(<_=A@RX?cXa*6%bd9
z_s}4W>*^{_9$+4D`VpNZi@A$t?$mmcjn`K}>`aEQa)NwTz6mTfRzX<4fwizm$Mp2C
ztDE~g#&unYPZp~)yJtPNS5tMjRMyf(c0^y;qK!$v7QN|8PW<+^_y9P%ecw%h?``M8
zVI-wq1x|24ZgLrj)PP}Z4-2@_O&CAcWkHcFt4^td3fp&au(nxoq8MM{QTgOjv`{mO
z?dS1@!_r;!Kx3XE#&FkBw)!u%qLd5OcQKUWDjS_eVn$?bCZo-=&OzefbUDuLFrgYx
z#7>td`R0APdeL66A}bn^nZ)EfJu=EsFGJ^RgY${J!jPi#45sC<t!R4rL4+6*I8ws*
zavI`^7ShVBGTS56L6zLG#T6xXEhaOC9DxOYw(!tt;rs?>D!Eu`;JVg_e-;%BqXaOB
zE6eN*cNfS{a!;R>OT`XXm$q1#>nr^{$h4nTSBj4qEeetO#b2jkq~9|r3miQAdhjg!
z<h(ouT-R1(XZ4}9R`5_Ayq})Y{OHhuQmV*gx4E{mMasVPMop1*S<Up-n6xE)*%K?>
zka6?sZb}Lmqndj`!^A$4!D-ZL=1Wt}Ur!;omc+*J_2R2soGJT7D85bUyZJ?<#+s86
zVyS6PsP^$2=Tntj58HS_er#r!EK42KLu8tAThJ0H-LSr@I<7`W+;Mj&oE`0P*C+9+
zIs?2$z0ld->OY$*&8?D5t7l5(($Nn9_lJZI;Vk*q_&jxKiG9&~^gW!&OB1E@Y$XYt
zae}sXI@&txPzgFmtaQ7&RwRO7Wiu|PL_2>XXRMo&ZV_<Aav1PsD=w#rA?lq<$%b8_
zjM@?Q`cUG=o~#jGrc7Okk*et0f$e-;Q!9~Na`awlh*8gV6Cpk@)-hxy%!Sc8!$T#h
zrOj}acEvSd%0Ed(+M8N0pAuVu!6;YhYeGQhHla^N;<R<`zy6{Y^+wnOrJvSl`>Bf$
z<|k*)vgzDUcEpiHPTtIGXbljCZN~9C?+?b(M@nWjDeib}SM+ehqZ|&+5S9@1bpkMm
z$fXp9I$(z5K(le?i4lhI=DcMLO&^6m5Yv8A8RGluvg2p#!o<l;!YWhGEBbi7o5P40
zGY^jGx1A*LKs9q--C~`Y`R-BK%)`-L%l5p@&6y7-c^_(qD<6urx8Mxzg_k)(dZmv@
zF;znQZeq|M4-Z>gvRQXZjcSAkArgZu{~Dh+?<r2=2FBczs$sISK&DJ$nczEFbIW$M
zIi9Zu2sob_l?ov$DWKoCGu5-zqtF^k!Gl2e_g^E$OoaSki4#zX5LkK0h(kddqO`RG
z8TenDGFZx{?_E<H9DGeYeS?==-IyAwz8d0X5+V_YGVwrlR0R<9^OOkFL8e3S!G2d>
zlhVPP4C*Fr5o}e6=xkpvePf|F<6ue7h4CjL4i`t%jIZ;w>YHpbr<v<!8W~_mT+h88
zcP#s`cIpfa5b+IabPDU|C}+fflz_uNV&eRkC(aT#41iDz%|G!#wx|l$P43yoTaveT
z)t|sI-A)-Zf!`7H2$r!UqYuo-g2w+LJ)KqoT{ST8n?S1MSd14PZCRF4L-=O^iv#r(
z$KyRl{@Y<TfmCzPDx<G?ug7J--x3<&(Nr@}zi~H6YsjA|*&Xs?ll-29B?d-KMZ9&&
z%u<LD60lVX?J>UqNR2dBk`ru!(L%iXu{EARK?vk}zNt~vr<quiV9QO<1og@JeREvS
zj58=WTzm~)+8(#WA$1Fz$%CBIg<q6(b#-L^zUHZQ)or%fb+q$+Yvs=D2VrCzU$wtF
zrm`xzWL0LLgmDJwtE%o3e0FQ1Q+H}kr<YB)HRQ9bbZs{8k+djjxVF4mHLSCw#cMWi
z^X!et{#o8X15Paf!YJy~j@At&O$%I`j23pn=p(0k&cUTMSJuw<xvIa#)tn3c7!|qI
z*{YNImA3FyQ%ia*2+r{d-)W^OqeH0sa$61Qz<^TYtq6oFdU8lc4)+BXX0-cnk=|j~
zE?efjYv(g`9~_Nt)6e1*N-aZs^ZvKj_0S?ngb#$l`XOq{o{vokH}+6|)CZP}h_1#R
ziW)ND?lPQ7G{fV3ps9&FB1mNdZ}Y}7Dw!t87Y>=sf9iUYud<Ws1l72nbciSozSl&l
zt=j-W@5ZVBFkxhV>J%e+reI)TDoH&m;m&o;Zxk+En3dO%cnU_mm79!&mZ{Kceh`F`
znnsNK4Q9?~ET2RsjUAMa*ht5*7`GK&X0lB%U`_?Mu0v7r#9{+fnYcUOjJ<AZTJ|4$
zf0(h_d)XKf`TZ&%DdQd-^Ks6m<zK5H`*UP^WWXzccD5MI>o~T-VkYVKhebpT3o`r|
z)iD4za|PT#+E-2C$#^j%tQ*XUu(XWO5!5A<DWgI3Mwo!-e{(1P+s*i!d*Nb#T`k!E
zz;{77G*)t)OwFB8D$P#VZ#SK=Xuj)N{JIc&)wJ6!uoh!HwD)P4{QlD>xB0*Pe>MnC
zyDap&9nn7|47-kU(Yk@=Xkp%2H@Qh!v%{VNvuxd8Y?*p;k6;y#VXoI>X6@J6;PbYV
z>;#U4;MJx-2ss0445Bs9>n$IwPwe!sF@Iz~xrGB7ZLY#OnrYI(%b=N<>&^X4W6XcJ
z3ZVV(2VX1_uSh3jm~MgOx(Bs8k8;`eZVg}FCwRd$@nW}7+Dd5SqLWvAt~c4-*0KTI
zti}zX^$g@cz?U1C&1yyv_XkquZq81bb8zowW`O>{SXfj=OMe*s(R=#2<-nn#B!_}8
zhOch@pT^y1*h?;&IdR7!v@K`My_X1q=Ix4TdAu&(MVgsqk!h%OJ;W);L+)Fk@1$#{
z3D4?f=Jk;fI2FW@Oy7zX!kt_heb}UKKX<BXpOo%iD9>K34QNL*b7fk;A%*~X{l0V9
z5JRj^&j*ZsbxjWQu9cI@rNk9D(>hGrO}ns#zi_N~+u4~DA+ok1PbMmjbiQbqnGqP2
z8!XpC>C^>_hDd1b_$r^+5a=Q2<=dsDV?q=Ddgc|bg>BvydX-V@U-<PJL7vi@9YehI
zDozf!BJ4y5l@*MZgK^&Vo+*2W6}T6o1pcx%(!wtA^D_|<?PcEqOrf%g5uy{k2Pw}v
zU&4u3eK}^X{FJ3ifY3CluWnYY6a1NeZ*TWnldqmxw{v}OZ*JrpG>>unIGZ3Zf?h~!
zI%f*JLztyW5r5J7A=Y;`_GtrwA{_?b4EZL<Iqc%S<J05)^Y3NbZRq4BpPgvpcLD)f
z(fQaP+emWBh`^4mQig;sGm~;vWUt?rY^17M7;rm$z8^5s{Ue@kh{1+ZyvnkAqPw~z
z)m9iKVRoZv5TkV3wrP^G^cvx8Ysgkuy-}nj#AtQ{5J7uh5xZ;E>K{fmn44Cy7o<ul
z$wrBy`Kh)SI{7>IRLzS>ek2Y+X%g+E{uy=i;;H(rE0=<ao~uR@IN<W=C2Yd;7z5YC
zm+3$Y8P)->LtXuy(euMd1!Mk``&PW_xfeYz)D*sg4V&c@-uLaH)O5KANP1AcPl5(9
z)OXk!w3dZCJjVeAYBV2Vz$Rn$w*p|!%F(6WeGM5_Sw(w3TB($9W3Z(KBubA-dlsLj
zH*^U`R6OND;GtUX&o6zJM^?p^8hq`EX{#nCJ4;CEgXyf%S2=k;5PIXxZ_UQS-VPRg
zt}pCr1=bOZ2Ak<Dcdp1vGaw8M5K`~1Qp-xwzs#&kT=tp)s+h?tX9CMY@zn)~%^u{~
zJtS(&#iibOzDT2G2}~871I#G_j*84{E25(ldP1dZJ?Msa!yd(O#wGF9plS*X$bMx9
z*XPkSZ5h^&0%nzYD+x--&V??fK&nl7pHvP|QZ_L+ZNoK$nrX8U;mnp{BW~$n{Zutw
z%kn=+?1@yA;l9S@cddSJ{$&lbhgHVrBX$iDQsG<>+fjZ@!6jPJ)76bWv@wq^D5kpI
z7r+4~^(nqgQAj1F6dNrj0VBDXTNeSahEVjP1^czKSS2G1e+-JG#njqs3YgGL#VzgX
z$3nHfkqLBDHbp0NDTa!08kN}H%XVCmzbfaGn&FgD71g1}voK<z{<(3mI`s_i;#Ilv
ztJN!|Ew#2kc1X-vrWpDU+a{wrKCXOl#Oj17>L^-2qr={1q<OG(ye(GoJ+ksxwyGDr
zU&g<{&!tYkAQ+_F5>aVhJLDEkY7{bgWNEwqYH|HXCY4hG>YNci>^R_85F7EPYA=~A
zG$Y`4{95yyN&UJ>1R03rY0~;0qorBPj$a*Gw3^?@vq2T{5@zs1TNRl2&H}&+wBLCc
z24x*0D@oWlPXIE&b=Nm0{XtvU%h^QF%r&GBtCPi@Mv3k$SU)l?t&3GNU*nUDp0AwO
zm*Y$`<zmX3EE4+3P-&?yp@5)h-}hxomUdo-ow#~X?MtD}$?2jBAW7VBcJ=u#=L1wb
z+uK}38kp#DMIQiP-1R-6QGdH$O{-dsJ$V{GO_!)nnlB>`A5s~iHTb%PvgVoaFR^0*
z^|1uy1k5s15BM7i{78b`Ls}J$m$8jQ7C!zqZ1D9x+kShPlI;P6*KA2X7%gWnURtC&
zRK)>v%m>(}0Ce(AHoRo=|G)2UeTQXKbz3a<2hP#0d(GB`XAR;@R@cEm>w^9BhT(46
zePD5z0zWUDDm?1v*id8u=IsNP`_A?h(!BTX`AodjgA9sG>e1Mm_VXmr!m8iTipG`(
z)vj(n2;ZyXeN_CbMbt_{k?ORCAbixg#ytvfFU#JXf)eFkpuR^yxuaOH*6kQQ{%V@u
zKTm%Ls3z(MiR6oREO+EY5Qtvy6DeC;%q}<a{*U%A$A{3wmyYhSy3%`8(tNilC{PZ1
zVLsNXrssCa@1${WDM*@~zu*KzA||c#=jNSW2qEfqR{n_Rwu-_@Q^_^VOJfd09XAQl
z-zU&UE+EfmaNpg$HyLMFXqZI|`85aXfF!X%jIRy-@L8Tyd@sj^31)K{^Ae;~;KT!j
zCG2W4<K`zgQ$ZlLmhWXo&}6^*EnBd8{GGEK2`UArlkPw2w8ACu8O_6e+ga%K)3neW
zxA<znzICjE@ddQ%$|f)kmsR=s<eJR|pLa%o_uX;WzFBJ8l17L~g{Wgwf}?v@ti+e)
z>#C@i93AAbO~j~0f(a!HU3CeJ>g{?Rm3f$cZOpit54cT<;mjtwV~3I$+oWIIQdqzS
z_y!{z0uh=}XiWPG+DewCCy?;f0Sp!|($i3dF))cI?2RKkZ)>^48v|f|)|t-F2s3@J
ztx~6AFk?@Qk+=Gj&~V?0<4mB!D=tAw7JEea>`IQNhw#-x4}pfa#&{k|I=Oida2Vu=
zycD-JNYzd0b-p@47r_7a>nVZ0M2u?XNP0Y8YLms$G{2Lq5v1|@&@<!b&GU6z=lmVM
zynHXy00g+sG^cHWm|k+bb<Sfb+4v>FFwVQgyuHfEh3x{rV_b!Ivm^LJ%C-r@ARXv7
zJU^87Er@+)KaE4^I3~T8vLxDlepPI=cI*eGJ#BtXIKLU;HtfP^1~vsIWXQa!!%wOy
zObbS5r=jn%+1>@$mN3q|nlM;lLU5h6-X%&aUu_*t!s1gK37b<jVH&mH?p!XzD~Jf#
zlf(3T75Gbm#vz9fHEJu;59C~=iWdxdh%E=Fq+x+YsoV7h8M;ii1f9zmn3M7#IUF@1
zB#vpICZjxg`O8>&vd-Ctnr`H6kE*E!Kj#*0bsc2Va@S|w%rECEkis(g?hbj5`Y4^B
zog;6xwX|j(tp`=LCf}~E<2Bmq7AVJWiJATY-98!UBXJ&JAC=W7lr+4jG7~HKvxAS?
zkri63F(z}@RZ3g-aiNh2kF|5=3R%Tb8-<qlyKzmRY<7p6e;=^J2i;#E1mO@lfS5R)
zp|4dVF0v94(7FxR`8iXrwZO*weCF~Ul%<HlG0tSalfZ4<R@&<Xy8^V*Ol=(`olmF*
z*VTl`QBlON{Ym^-SrV8mExUc?QF6g|cd_12?s#;VJhkj<-I4y2dpmEfRb}cR;-NuI
zNqEYHCF5`S**)yy7CGDBF)7bNo<0=z;B|Oo2}KVWPi>iel+6<>U>*tV7SU|`*^@St
zUDlEBTwG?6^UG{g%LqX~-({TvpC|Bn-^_8I24S^G>bb0@nqpF1<)M7&o$FiIk!UtB
zgGEv3wByL-wXCal8+~;;vVakHp+5<n2>(M9(}5vE7<!xM##&t!iAwKBxO83NF{zri
zKlRlb6^BvsY<GmZmgD))2znGL&r7;Gt?ulMS8a<<_Y^Rz&ihT{DWwT1<_CxJeIgiD
zaD}WGW24_eUsP3hEdFYEG#cd~BYVNlbal5!<%qy21x&pYzaq)Xb2YGO1k?*@+ySXa
z6P*}!LXe+B|AR)gc6U`N!TwcAOw~lj4M6>oT+%S&$1mcv!>{A#_uX}|hcrD%B`O+W
zPJ%#YlD=m2PG5B1g_O+aeAiIz@ihV85v+fqV#>3dNoQc702<en*&9pTt`%N4BN7|5
zSTiuY^0%_uDHMh6Ca&4$`a0O)jb-poQuZy)j%f!Nna60p;IGF5IKJgu!xIzWF1*Fx
zZ7@(4A3z5j=|r&ATF2;rc0<wsp!lef=ds3F1z;;)!8a@B@=)>Nr9-?W;)C7oG<-t(
zXe4ta|8Uvp&4afDDQ{kvKN>o<(An1&HriMf*Y_k+^yl*@3XSba@I!%Ww}{LOiDo}%
zCQm*c<H~bGvd7NnTzW~%GSDh#m$Wac2Z|mDDTxJo?IE*T>(wk|XSALexw#zNVcw$S
z?0tLB;x}igzsSI020uw$6J|?fDGkY_9@~M9cv(ln!M!v~=_Nfq)Rkfp6BCp&gdW?g
zH#A-(_L5w)mT+wO(Y%x{D;-Jn$xD!2)kt|hiyrM|>`tSSnPYjfD$)n5W}A@SYA)&W
zrmoQO^ON@4c=%qgF4$@guK&BN(Mzh7q`T~SdM=BUofuaKXRqs_9D8#{z5D2(?wH^|
z=LiAnoA(tEzu;C}3UEWzL83nIK0j|EdyX`DsRlxH#$sLtGl0gS0)1?(t*O6Pq?rj%
zA!o6%f3j&|T2#q_@}bJ~P%KT2eZ*q2`ofhg2!GIgpT4DTBRSpN{BaTrltrKNHjGI<
z&j`GFDLeX(!d{UXg}yBG`}e5Nd8IMzEaAe|8?8@lQ7Cl*@FO90W_v$>+}H1RHR80f
zW0=jI(_6#&s6*L&V_<a{e44B+R8KOitVT!%+e`L4NBE((pVbnojYA@$K!d`kmrjZp
z2B<xV|0bcgJ{S8X72u4AhpE0ZPA?j(C%>(tFLxuI(tsN>gf!gr=Qtwcu1x(!k_{20
z!7oXtj6?~WDlO-jaqP=MJcE^kXH^>oEuZso2U>37Zoh1`ze@!JEK-&~v7smBRIxnJ
zx<}7lT<B)uWcR)qG90UC1~0Kky}-ewtY8K#zz^y)EHh@wH){B`_48-semx|a5b3ar
zvpZcmxUQ`31L%|w2ZlyRTy+HNcF7-M$#d=pJ%*+RfBp46mZcTMs%ysAB+AGKib7P{
z8rr~ocB`v=w-G5>{+#T+F8%p&>YFhi<wrOpY?iv6IAC_h<0loYEniqYm&xnVMhm^S
zu$$AMg^vp$)*G~w6(4;|0k;k%O5>^1=Eh#beo`ZiN(6VYP7Uec6D{HGEQJ$%s^=qO
zeB*h<OfnpL!vB%EW+x<Ob<`d|Ia2;yC>VRiEr=9`o7goi^D@KJ3{Ge#kXlOOo{$|H
zzk3D+`S8Q~?dAn}jxvC1FLaW@;Nar01myV{=*8IlK!8&4;*?L$Ryt;+80nJsw{MOr
z(9RF=*fE7tTl-}&OAWmSo6N!v%$si5<l35HjAZJIk<MWOrENk<OSC^xZC*YLe)V%$
zIF`JY{(#yE=1tLb|9Tw}7};|u*MR{&0}?uMm~_{9{pnG@oyq+qZ#Y1#CX1P@3fi-3
zT3b~+!JZXZ;lcU!`@2&a?c)?U4-P@OWd&F(p#t9JUGBH9ST~A;Z#oqV0I-4NozHpT
z{8MWJu-Nk>5%7^8eEkwm`M=*cpKc>b;KU;cn!KLw_xJaKGWJBkmexp*O|qi<-%dfV
zXIo?5<x4X&0?C3qT%N9GSG*pMoPj-)8^kZS*zKo*&CSiRRB{D3%k9-S7t92LwhjEb
z?npq!!pC2~IRGW+$K`P@r3c(1IX(TUm$My0sASq}9X(S`M~4UpM@>y_cYmM9%OjF4
z^rm4VGLre{%Urb5m?s+5aY`cM8!uclcYCtav8I(?+1GX9#ildk#na8o&7B8;OAC5E
z4(UFhBYT}fosk|fdYy$13|t;z7RJ8RPL9iNY<8UYwcnm}Ig9;{Vc@H;(0hQdyx=%K
z!l|zSE$|YSe|><juYl~l#<c7Mfov^xA=cgNmO8Jo>J4J5+y|Hm=GuQ8(atT$ymNJ3
zTiV;4qy6h)&TTp;-0cXy+|718*O9<gv|Vcm3k&lR{RNsbzML}(KCU4%>b5`TGkQ|n
z_seNffYujWj&5e3uYwX663`hTLF*^28}1v(f<GW<ZTC?<j+#0I&USNkTN>LNACGUI
z$8zL6TS1-Oj4!w8oG+J;CNK9EnH?{2Hw}^LeCKVGksdpJCyyTJg+#raB|l_$d-z$)
zpB}yG+W9hXhdA2r1`G<@FR2Lx-`BlwN9tKySkwKk<8|;Pb+V>Jb(W)UK}QRrclNBZ
zsII`LU0^Q*NE|X3Fvj6xxzpz8Apt8VF91xcsiJc2PyD#r(D8HxWDKt6f3SyNze_%S
z!|{x{8fn&jzr*<a)egN=VzuA!ayLMb`7F|9_bgJHvE$%jq-EvK1p>6vp_>fTes}wu
zD#8G-(_Q5D%6Ylj3$2mo$>i%<xbli176|U~TreX;D!5&m!5TST%{4pclez!-snkVD
zrt5|0D$Y0k`?kiD@Um0?6Ta&z@xpA(8>x)%*Oi4Kf0wLex3>1y*2g}<=d+uRm#1%B
zkDXA+mzS4te&3$%9ZRNZct7!phC+pczU8f7c$3Y@SwnU@cX)J}y1b#1<@=rsYQJtg
zesSHH>+Z1ef(6x6J^S|!#EuEN=}Ll$iC<E)O^BYCA7?I8r7A@0JwZO$JI|1-9cc`%
zhnr_F0=0|R?js25hlzyGBQLnnr@9#rB|CynD;6Cc*ETkf&pnwH4+7V_fDGtf+Rbq*
zP`=K_)y+hfNFx4wxtB}1(9qCqc~d*P^FqO=y{m&+2#==&-Itb*2j2PjyoIJG5M6?4
z&v_?jo45<P-WRhcbT8RQL4S7S#0~^qAKzZ|*=m{aMaaE`KYP=^>@ohC(_Npf0KMcp
zj5+lPvIt&wzf}{+rT1WUd_lLdf(NzV+=c}CD3!|z02z+v*CtaTeNOQ^UY17*M?+RF
zK(a^O+fz$dQGZbZEc$uzaS*?^x3{02oe7bAI|A3qd90&jVq($_EjQY3>?$M&g>);`
zVpFZ$=^}W$tfdPIT)Ldw&W99>>$*H-=Le1~3zpsJxV_+e-!Bcl+`jRt;4gZy8S+lK
zUGaV%a)<P(@ZA1dR7+JW4#7uha`kaxfy?U=qa4&1wWV0xb=vR^?X!-i*UtU>5g5Q5
zv4yS4RK+!|17qvBtOa80M5zpJOXbP_5qODaWO!WbY2eVkT~tnMB<@5HX7t(y6A!Vq
z3-YfMY22MeA233JbZ&2-UXTEMo^xY?lgQ&1V#vQKbI(XNV{^sb=4{3LWp2QL5z&h8
znrY*qBENGK`J??)@%b;<T2+pQc6W`7q_s8lzV1@j%-WBS>4Ir4r(S6;IDqEuhD~Z!
zDmXL{;9hyK-~W{>N=&bI7a2b5)qd}{6$@&=xE~xN)AVl2XvG@ji;}iPhS;8nl%^{^
z_jy7fRxp^jki&XDxU>=Eygz=sO4#|x?5|dFE-{NO@bYJw)9Ye=w<WWyg~|uL6Ft*o
z^UL%T$j6}bO73pi74h~?Q0Y~#-wN4FtuU9w>yUV!T|`2Fu^9m+#^KYEBzR_n{Cvem
z<br^_8Xej8m?@aCe^*B(K(}oA2;M+8iluzIJ>MbnxD1J*?Gtz$t%4<foLccZNj9`b
z_eM*xzjYowemTUJtVr|Nq&F>$^yE4n=&0knQK;Ih+14j;{|1fRdexcRV88*0bue!d
z07os7{y|^x*_==2LYadB4cP{Fq##0tE`UypHkc$~o{bLngLLm?{)i)V)rrpM8Nt8Y
zae(-236KYn6o}rfPH;Sb$k3N057yuCIpY#=JfH+BaRBrp9nY)jsrm^;mWCuRRwjD{
zVi+0s@ykzQ;iyan2OZyC4#g)+I-{`#ZRDd8s25|_e$+;ue*?+&i;Aew0itvEYjac*
zF44>T$O3zIrE6f!>(^;r<dX9@-`BW|ZB1j1V!@fgO#`>2EGV<3=8*KS?$8+td^$mT
zRr$wXtoP7s{yO#~%6o9rUr1UJD@0<@oO}@}?{Ii%bxGmk;f7NQU?9A)odY75>4m&q
z1h6Dn>eYhNIHAK(aQ0~z(m|4MuM6>z7Y-hQQ}o<>eAG_Cn%74*1t@@JULOZy`(mN$
z))`Ptf*qY^@H;ynLEDMj24Z_sPF(<3$)!Prk8{f()VKtm%b27Vfb%k|;P4uw#v@*w
z590x-6`xo(<xKX*{CBPg7hP$2$BbeJj4-Bxi}B0Rm(GG_x>Xq1%~e%X5~T(T2sc;*
z`;q4H8LBi>u;vFHOlqK$fqu??T&9j?uhLK1<SL&sT;qDz$=4un%o0NQA0dB<stNT!
zIF}r}wD;sOx30QUQtolE|3xlvv$X8Ib0E7#0+tqOa-7zdApBpyz#1l^D|%M+99%^n
zEmyk0_kNLw*O3sNVu<DNEiU}71|c<q(~VW+@4}jB((swZR0`<0MUm3X->h0)i=$Vn
zB7W*p0Ifw|CrmDt|42Cfe6LQ{!M4tCKjYZU%QtcC!Q(1GLu)wuJ*&^X;E&Fq9d4@?
zxY~SD6e2U{qiIsj<Za6^lQffi{R=V>@Hfip$v3umA1Drt*-f<bAX}B?huSwJwM@F|
z+JqWOu$3qpELBGOK^YO&9X$s47tnMW84-pNX-i#E1qE)yi81KOhr4j9ynOM9-~I!B
zpqnnt@>#n)MB{t~5Vqjw{U8fkmUu_qEDhRi>qng1HEBAGA79cL*+#}FAI9)ypm|_~
zd?VDEG=BdA`OMFQg1UegA0})yCJlIpsCa5ASq1&)TBl~vl+5*hI1FgHa+>eZ0DP~#
zyvOECNZ9UbQRq0gqs=lx853VEqR8gnkaLW{ZqWYo_v{=?#t$D(%ev#g`d=F1`)6y<
z^Z<q!c;RT~Lo|{GM34JiHra^c`?v<=W3LC7F+JyKkU^)I3%!C$%%cWzs`lAb4G>e9
zt}$4YG|wvOHI%S^48+;F`c9{9g=H)K#isgxOhaFwf?^HNGPbxzt*iz@&}Uu<DAE9l
zldQd0D)GhCF9XkuyfTV%MZ*l?_6hXp)iG@>Ri{B~W$<hZ^6e}w>P3YchQz_gZ%_ea
z7!Kyp(cn_RfCh1c=liDhipI02_0=Tuq%Igs>!yLGuuW-Be5A+hf>lbCOZO*|yGsy7
zzf>cAA0nhqpB$e&%0u_v_2bj$jbzu4ZNK$Fz?^(9zD%tIyBj)x*U6=1It3w}ZA-m6
zi(SJzkMa+G0sVlG!LQ?i(50SfyvL%E+@+_b(a)M!^YYGCZMMH?l}&0=o+b%=IuA=n
z%(1o_rtS|hp{(k#XVENE9^p$UP&PqcPEPF;`Vw_2nnO>%6sM>R81`H=jq;El-Nb6e
z^$E27aiZ#RbYg^{{)|=%r!HmV@%OyfKYXWHg+<c}TdJ4U|IDh*Cn`x98x_<bt`^Ta
ze|xJMo-xYw){msRDia&Fl8%=}Kt-zy@&f}k5iTyZ0WHOmh5(kagP0dtnpKHONkzxP
z!mQQdOqDF?zX%7r;Av$=lyw9HDFcKmk@`>4)&GK0WE)00OZVnJfBTR_PtAJh^@8sx
z6hbjKn{7f*frwbjJvZx%7RsDl7-v`zE%l|{^j0n44{o<fWQ_vnd@2nmhc2CEdSw+f
zBI#n$<ekN^Ljtms`&E6po?K}DVhTkQI=~4TpC2nhl%~T^(xx_62leC|J<nstn%xYS
z_J0|<(*OWyLQ`rM<sr$RoGha%CiV+-q!6J0;2cP}vw$qBF4IrG(qo;4w$5qg;+r$b
zN#j9{XkFY%ul)@%iPoaTEGjRyCQd4=Re`Jo)9}C;m(?2<j8QAKeRwMx9JYy(&&WX^
zR!hc#dwMlcM->>y`e8-FFnYb1V?!RgmuU)iciJ>MX76w!$r*2Et=>+MPRc-M_4w`x
zup!-6hJw_wMnm<T)jdX_ITj}bI!%=Xb4P$)0Ab;|<$`ZwU&o{5p9cx5g#KXX0@mmS
z5g}>U@!#JMW`nWjG~6er=1b#0ru{LN*(MKaS?*DuRgIXv#_XC;rd}~NDx4*0qoLKW
zixXux4h@9Xqc@pl+cu{yk)<rr`BGd{H?8T;@!_B)4qzQv{H%Nq%cQk8bc%(W@7c1O
z0sp=-X>y(UHPdKe0X1LO|D}L;s1N)wld>pFxaz<QcAx3&Q^fWK<R}>9VUdxw-`}Vc
z#MgP&LM24{m89!;e<#Ua=6)=VR3F1xFr-@+`9@CGT)2@FBes|iQ%B)N`QzN?W4{k;
zCyWP!A<5tX9qkaJG1pHL$^9ir<b>!O&)Js$Vi#14u+&-ju)yF81&h04(a(R8N|#9$
zwl(JFP6S$U%zqAMyuh+%_WUrVnf9LlV6VIi=QyImqlK!GnZJA^_p7Iwe_?yQVW#t^
z*G7AOE3^cTWs`Qo$H75fK)iCOj|<Y;;``>DECbkfh)o@-Wap)=PlSf$Eogv|b|(3M
z%O3a#n}GCW#R%T-+h%_>KBskQSs4Y|+jLn~dHJY{R}<~mc+k&i^yBUv$om8=`tbT}
zRm-)Q@xlR?^PwuhUq+{r?T=jJeuZ8vb(-J#<J>a+9qq7Df?NHC0d+|Q`RXo4KPqlV
zlZks>mFRL4L>wJieg8`2b-T9mbnHw^OA9Or($mw$BaL;ow=`uJaus&#PTv$<Q)csq
zh3i%3x~55eYRH=HQYoi*z7bJ{1bJ}H=?J3DNs{Z)i{|eTAYuktF}%7VEdwVy#-!1w
zcOJ9l+ASyT4;erKs*sS7jlRegz<W0le3(zQX-}RPWFbBk|0R5~A`*ab$Z;xsN&q?~
zaIv*8(otN-1Z6-Gzae$+lYEv~OYDUG#R$<F#t`re*0-|MVtM<zcQ3%ZB<f?4x76hB
z3f`V6c4{vV81G4Q^6e8H`~vo>LRI!F8`SpXmFfGx)2R!tZX&~>^eh$^<!ihxTQkbu
zbY7Tx6f0EBa;22=A8m|h4Jg&rVI5zO?z4S!CFH3m0udA8+U&sv_`ad*sdUxAHJ|`J
zD1|Fxw%OZ*KmshLH%N4)q6$C7tz@dI+Ofy;9h&&r+v|M;*^_?AZ^-<JVW~xdmUqtX
z7?x*33mdM#xg{-a6m}Z(V9qMpzhc5eO!vIk{{Xg|n-qJEJ$L~ucYv5YY07re@!~~?
z723A}{JXHYxamsdbGy=ZYVfQsbl{{min!PJsO5=|%=8!Mx@w9@O=34XSZpCEAqPwk
zeCp*BIQh))lTd%R7v=I`Z@^L8)x^U`77uFNR2g6<iJPcp+kP6ng9Zsv=VXWSXM3eL
zls41n)2<V!eU5{CZ%u(}ePDKxUnp(*BTB6*ER(*Zgj2Z^0ZVRebYX%QR#RWdm9&!i
zgcy=dbo+M(`>T72(tpxbs#EcDSt#fU$hVE>fhIP<?6%$bKDl@K@O0(^WIM`tTu#c=
zo)@VaFgKL9WT_xWNk;z6i=(wvKk5b2!Z12EbagY5vMf8XI!Li|mYL$d#|Pc2qUn3i
zO54mzSL6=BWsUD+{e%C#Q{Z8##OOn`LZq#5(DWtN`+dq@%KR1t{Mfs)>5P4xVgV&C
z9gEdiRsSKJIM$!u&3Dqd#BMWdX1s^$uk_@1zQ8>B8$Epf;iN+_`g2%BguulxD?kqi
zqDiiQqlYKgjy_j0gH#Zp1WfC8L2r6{^9dJcSP}=K=oXxYNPE_P$sZ;ADuw&jFiIQ@
z;Z|B0knKEusCBCUktqAC%o1X^^ee3cm#Q|5kLE&5#J+=?qRd<FS-xos$KSv2QxLL6
z#K(SIJBXWB=c<FhLgZ_XWA$+zXxwDWywaU*U4WH5v@lTp5tzFj4?T=t3b}u@TAa#i
zYcGLSyqkqZ2??B8df(F|sF&wE5VMYOL<Hg7j7bs?Gw)_CG~Jr%0c{)^;pewlm9O=g
z;79UkT$*qHF5+xrF|hm|dJZH{;;CX96axt(Bz&Dtjr%Dr5FxibX06K2Vu#5m;w&AZ
z;}OlJ+<wsHfDnOVe9`I5X%ywPVL?#<?fs3g3y>@h2;bOrJRG-x1TM3Y2cAjo4XAOz
zkXhQo1CrI&)U|bWRcxB_`U<%gPV^9+e>6)XM;bU8K|*w(bfeOxJzf90qGoWvFKm(>
z2u$i^5xDU^Wqu#e+7QmCzCTY)>IZ5|x~7JG<4EthWP`viY<(7LYHMBiTHVjWmLJo*
zy}p5Et#1G)0ObbGwc|<L<7(_ruJ~(!ER=n{uhx2UgA6o>XOd3ldgSoa#L(%dftyFE
zhW21UJ&xx4jy5uQB(|Q<0cn^cOTU_&UhsTQ?}#2;^>#wkEj%ZCt}D3Qv3|Jgpk+c9
zTYlTxnpOMy8*-M&!wej}#|{$8E)up}m)sYj-5Hx>{6YOiSHsa_C*W0&lL2cj$j?$y
zb~a3%YA7I01J=aC@<8x#&Bx~|l45O8o(*IS<HBP41|fg;8{PeHDGoR{_r{L*Uoyva
z9Lon|<SiY(b~d1B`!Dx%OmWd5+MTlsQkvPTg4uh2dK-SVK+<TdU);7$43)8VF5@>2
zwlffd>``$xp?F<aA`^+ToCq&t`0;@%5fyP`0k$7#FxjvqNv0+qV))`Sz`z3qxa{KK
zIN#@eNL<X&T1SPx^tmK5Ng1w<RCFQf4y_pSkCt%PCKBOu$x6ze-2&pji@g7nsc)_P
zSI{?@H?vid@_*Y1H0L~scw$*xXDg3B!Ep+9&h&6EK<Dk8`z`NKQ>si&<*8fGn-Qnm
z5~#T$VhpnREz&Gw5l<4#58#r$ko4{5EdW<vc`dy*Q`qp31S`*KyY56_AOjQXfz|&a
z%~s`-pgVe@)O01IU`PR5v*L+i;f!uel}5gyKX4dStXuw|>K1F9NfO-J&ue7;&EG_$
z>!SSYLQ;jtx5|pfmV7cgv&5xd_3{{9G-t1E!|B7?AHgjO{yUxa?)8zQQCgf@i862?
zl9=|db#u04dL1}*_juKK!>~r9@9tJ3l%?j~k5S{ZKaUc5d70!|<`42`4C2#aS1oBb
z=2wk`z34bTwhGoJ#1&Br;A)Uh{yIU*eGD@sBqeMqOq;GS%!*-<_Ro}!RBZ0m>kTjt
z&3lAg)+7tZWK@rOBs$vbvZpJ1Dz%??6h--@1Lryc*5l>mNxa9w4(Pd+b#*N67(8T}
zy;4oy7($nf5B<GUx=m@ZwEu-_sM?HXJv4X6Ql(+Op63tEOeI|l-=UM{LCWyV)*2=B
z021#6OCa0<E4KOYJNu<TyqZb@s_EUI=KAXOzZRopN`DWJI&g3eJ5DGdQ93!UYsJ<b
zr%l(ox^mT+6nrQmRd-hrPaRdaLfUSYO?9;|P|CKOouq?dL~cpF7PIu+)+!tU>y`7G
zuvf?(^>WZZC-3tRrsvF;43%(ikd;uhb1j;&va25?1TDRrjOaaNt*-ejEi=<R9b%8f
z`w@?PreJW;D`e>t_ULn=_kBgCLEvpMfb@DSebt}k+@SWYwlgFvYW10?Q>tmlwPC68
ztE7hOx?h)u8Y*WT1ttPqs*LgEy)ls#?TRBqO8}f7%A2+S3n@)D8Q`(YdJc7)#Jm7%
zB;Y@3{rU3q8YU$NnaOh)8V@Ec9kv<=mdAg3Mw>=bXd2XhSC{761N#HM$(5-bdAJWs
z%1R7jOl<uu-b({cFy|?}Uvg9ox3~2*non+wQ4^n?n%XAfRZnnqmXWc9cYLxx=CLpy
zlU7g^t-e-MufI6IpDGw<tI|-NE|yO|XDj)Ii(2w;dlpjC2ZwJ>id$L@oU}we4C`uV
z=J%V8DLJ6~n*PLz1>#0CpgGTeF%Jf^1*p$6Rz=zU0_xN9vD5vv!J(=5{dAIytTA~!
zc4gO;+QH%wYpx$j*mb6X`hw{TH^2_u5i4^%ZcR{WKhSb|3qYNV`*GAyex^*EY)SZv
z-lqlCd*{ZBrD|sS^U76r{26!Q2Kw`_<i9R057oW%0$^;k^nFSVRdPsW{!eLV0oBI3
zzWY#$RH*>P3dLQ62PsgXc#8)q8r+H&hqkyED_)AbyA~%wHckpfi@OKyo%HN|_U=Ca
zbI(2hyH?hkWMzGmjI5b?-{<!{U*KO+#F!&Xwxme_7F>?}0~U<dQG(rqZ5b4WBT{$`
zs`LWc^%U#awG&3>LIe9dvBWe97r=Y{#7G*)Cr*%82n)`w(E7&uJTi<muIG%(iV1M9
zEP{a}CC56_>td@GPRR`%e{P(3p<sY%y%z9|S$>6pAbsMx6`EV*b-X+Hy{d9wcct7x
z_TKwQQ+VHxs!bB%ma-1~7*KA~Cf0AL(P%>iq5dc*C{&QHN-WL_c8w!2)*hls=geDe
zOdAH&*3aD$vg-HBu_{N;h&Y5w<08EU8s2I`RXVNt?+DUSPN*Qoq3+X{-xS$%L?MPl
zXY1NbU+T-%mU;Q94bf$IJ4G-tj1Q?;ru1{WWHv*Yz^j>`@l9wbUuK$>Xtg|JDkO~9
zp`}M5k*+QhIV1uJQL3+6Z<YZSKBPfA+2j4KPB(YvO{Fv(iangTdfg>+quBVk(FZ&m
zI<AU0-oB8TVXO$`ak%o`*TVb2&KDs=QuR+NkxAX+XLXIbgABOO9Vqz;?6cBp+;0t~
zVa6Srz;ovo#C#xx+V$$(rbL1Xdxuq^F`>eLFZJQ-b$IVclh_HX6(=XJVc*{#U9<Xj
zH<v9W?t5rA)v%r$!{Bp!Y%t*sJPr?*WVsBXLSN`eS=8K%XWGgplhMBWQ5lUs6<zRL
zOj(vM&3A<@838Y9KkzO_GqnCNsxD65Ehc8dwOD`_SDe6Alv8_Z?(o>I%;#2_%roqj
zh7<<bZ3?Jy{;~&apu)i2N`P)8U^?oI^NS+vpfe5d=TgIu(^|QlAzHD{J7UtLVup%6
zFRPQ{8`Vku$c>#?w|sE^FbSJ)LBi?-sW~G{)pusuaq?e?N_?gh1G~)H{C<8_U(VY{
z7;ev`j2mDtHE50p^Ay!XnkOqchQlX~TPJeJeDTkeZ^i4-G)R16480E65t6qKm@H#b
zw99%8t6U*&EV0#>oj7%brTe3*8frCoed=1w7@F1uk1;FMllq+P;d0D=a3?m=oWn)M
zw>{B~gIom&$Agr1(?)8)p}p%FiwXm;^!A_qw&q;T@6;8wSNdgnEnh9S(4j%M|63QO
zH#GWIqFG|FTTMgVP{BNPA;jsMyor(mv^Q^Dp7O3sQvuYJj2Lg@X2Dc4acbU!B&mPe
z7vh;Ka>^N8-GA{Y6sRTyeCaJmEEQJOtU0|L-_m~=_w{Skm#0;smiFs~MKfP3zP*bc
z6Bz5Y$a`H?r`6a+*)lZW+6m<WE3e41Jur&C_56yf<FCGiS597K=4_LNR*N7v);R7k
zriJ!=Xe(UBs4C{jtdH>4tyZmpW3#?7^@Opk#>)LyEA|c+B}A)tVgO-xY}4VOgyY_P
zI%aT!@X4DFH)>3YVmK|iHVE;g2eJ7o!Ga*_I4TZIE2lm39ux>N5b>1g_vp<26U7W_
ztxSb~Hr|T*b_A|aZu&CJ)h&S;!#N2O_psklMxt`^7Jacqi2IWFdPmy^-3c9~%x)(l
zDbGLg@-OrYQ0Eb|z;;KYl?M9zv-&_U;65rV8u^iql$-*hTywWeG1B@vWtLDq#l?Lf
zCZ(`kKbSFmJ$_tdyl(#iRUjTqrQWjjLNEQ6gF_Qe{DD~O_6-~Phz*pPrry`Nyb{)-
zC7ug9|N1{&4J+BVw6w0jp86Eyn)FF@c<do2@Br4@+WPUwZW7V@lNKdX8~Vyh+=c2W
z4dB`(P1kYvFe{t<u`!!y{tBJ{S@FlJhPLN#Q6TXoZ?t0no{0g5Zdd&G%Y85O1m$Sa
z9tfcZX85Iw`fbe-3kxe?3k!Jm7n`>K&u;9I8p2^;&TFSlIsmB(v}Eo9Lx2^Y0(R{s
zJO1jL8e)G})O>*VNyBVWVId0}o3pbsxp4goSIK3b)S7e?VKtY6YXJ^cT>Eh%dIkG*
z|Ah^^)t=$V)|}MzVd`?Va0-eRXgbJ&T2vlRySu?nN1rDxe{p!ql0hqBrObr`62kHF
zk`~XG2R7`UETFvCH8*>$4by_yTQ16n%o?4yz5<6}qohSdK;ZOv%2xDzvm!yF-oy=q
z=E3fuEs9i0S7*{frg}F@tie{_fHhcL*upY6?5N3S0Cr-_8k)9Yj~_FEi5ubMSQ)XQ
z05CI^O?G_CO{M`|<AygzH7l2jL^!0d%7h}ia!8Kc!ZLclj)>g7lPJWaZ8>kVQ>cg;
zKap;<f#=SKezu1s0yS%yQ8zb9KTxt#gmf<Kp@5IPe0;8{I8UzlqU{6e1A~-Nmp<9Q
z(ToG;$`*Ss4A6^UvsFW-T)h?60-K7;x~ajw>Y5YB2(8oA#sW_dNtNlbb@_*gJE=8z
zMHp_NimO!tYiUWjlDC@v7&uQ7H7)Q8X%3%1%h-~Td$~mjyfY$CbIH6aUHRFw%IN*i
zg@5neGSM-!KTO?TW+9JL)yu9L2k}0Q4!PUFyLpeUt?prgR7r@V+rgxgpK_2J9_CoN
zdya9YLeW#g_#l1Z3GETc?T=@*RIoC}+r>88rlKIWU@n((p{8=D$%j8r%QfKWxdPxw
zim-d!Vl9v$4onDhNH2QY3rw^Q?4(q{@NJsvD&>reLkMccoNp_Nr1c<&k%Ok;ggyf#
z)jk;7y3XrDwN=J57Dc8?z}&k57ocFPqProKDw}Ou*L)h<axvw>-}1Wc2s(mmi(rCx
zx;o2?<O7V++SZep-W?W|d+&#bhtbgjdKU|icu4vI+y(6ozd9<Zsjj~H_6a1@GP?$N
z0R{CI*(=QC$6n@^7`!0-C*?ICN*JLJ5XI$Czi-Y?9=D$gyoG%nWK{3?^v*{5voDer
zUE{vza{bZs?B4rs3h#@l*{frq?RINUg5oT)kDZHla|SVrx@?uDf|jrv)~NH_<R%mq
z&rA7(%tAiIJGVzambfBNFxRDO{B35Qf{krFb_^3DdT0#CFgwf&S{3L2EuH<h>PhzX
zkl?RUQZb$AOGk%T&-s?<LV<TUKoiX4d21Hl7d6>nzY>hbX#@F)M@tmejPvPQ{Rplw
zO|M;{-Fuw^$9@D75nA>zC)28Kn5x5{AN0<uM$U{tES~vF;*UZ2a9Wi|=61{ry?X~i
zFMVL7zyA=%?-euhfcBP;oaZp11%i2MdZ9?6mPt;$Y{(B|R^0K98}-zS#as@MhkJ<k
z9XjcnfH7ZIgSM2WM@f47+!0kMc}R^U#;3gI<d8$@?tto6OV%+Pjk?d1y6*O|K%*B|
zJe3-`Ek>R^H=~!b3Zjm_s&D+=k?t-P3tqE_Cmhm|YtCVO()63;?nT1UdjKaGNWmXF
zo}M)w*8`ZaqGf=&@*3b$`%HHumZMHO%VIc@$OkqWtU#Jt^z#~m{M6q9oDRUlOAOb~
zAN`l*X^#AB=Hl=EI#G=Qa!a{|s&bq9?FZaP*?6Mwg?ntE9jd3K^6X@6IKeH3G_j8}
zn^tfawkdaF%)RpgPdebYF4Z`^Gd{jAM}4khRYDX=&}^&3KS*pUIam}pBvz;_I&EqD
za%79neuFC8Usdxi(M(dO*g^@J3=GHiN8`imWwwAIM+VrHw1F4T^1+mwc4AX6wn*)X
z?G^`WZUEwq681Jb5c4S^Esh>#2}%-ma95QyRy006O=-$FQMbLm`6xqO?_Dyjz5RFQ
zku8}z7O`~=_+w;wp$e32e&sTqhm#9g^*s6OHwnndX4BBX!dhxz-cT+FmLWx|oQ0Cj
zbpO`3S;#kiwv5PmxhpNzfp8+zwcSdTDb%D~i;F6+7BqYzJJFDt8~-Fw!bG$MA%7Ja
zCFWW+zjn|Y-zCUQV#$O|=WK?&7?8duF~G}aVSF@CQUb}Ys!X%lOicu-{4|RhZLIdS
z=5_7Y34kt!18d44H!~2r)dfb>{F9Shq@0Pj=fASC-_!&Fj<pi{%C?OVr+I9btYVK7
zg*W}joS?-ciCBz~(Fah0{aDDZoYBm3YSG88d6PQ?*6xYNXPrdMpvg1~{MmVWRs^I<
zBAa@~#G4z#z4K|oVD7|wuBzuLUvb^A1+yi}+NkKJ=c@5Fzdj2S?w@)7c@n9=>vs9=
zivUb1>wff+r4mtvHrugdgO#wbL8_jEpd5zdiR70Oft0K+3w99n9YN$)no7tS^0hj5
zee(Er^K*+@?yHX{CfdN>%8ZIBq)NbwT#HvNp<6&O%L4AkYvQS;EX*CI?@^(p0%dQ~
z2Xqz{#~}6D*}TC0Tkx?Ok1qIOlDO`Kys1R&6I?p&cEJDs1UCenk)7|KNd{a?)2jy5
zCq%(zjFrcOnM@62YCI|E5eh4+Ee(o=mE~3|OGkMM>E?!2#rbL$V>&weP-nVSo1j86
zBpkoUiT7mHaAn#=VXWBFkaC3G+)^<|*;vrtwfpLgGb>}xdj9lw!q4%JbzL+=lRUr=
z@ehPC1#p551$dY=*^aH&lM^TLr&S7g<D52Q3Y@K?dH7+*CLZNS8sne6oF_x)hf&Nd
zU?}VGb6Jg-%h!4i<?=PgEdi8}r=)Qo4!37Gn6>rtWZar%E@><WJR15oKp8ulK-$Oi
zNGg6Y?`-MF7}-~j_-TscTQrFyxc=pD{`b=>uCmSiNmt?2eC~?P_4Sy0Y0y_GrCH6~
zf2mo+5kz#BGTG>@ri&wx9_$>UH9ey>K2?r$vZzT)rWUBmOil~|Eb=TJrVB}6<*<cZ
z!0rw==&R(-=}L}cw*_tq9bouPZ05{9z_V4AoAwwv-+<K#i&F_{yY?ddofWg#y_&>E
z<z+9nzHx=)U@U6Pwe7*Kx8Dm^szDjy7(lJMa5cbNP?s~LJ^QwG(@G*on~4>JsAB-D
z!M1qnnwEv<Z6b0_IU08Q`tydASBl=w9iNZJYE<9$*GmSCevlU^k5zW>7)r2RL>w}c
zmMdnxaHdI$i^-)L82L7j*BKhrMAG>ZhMl4s^EPLlXSs4Z7ZXI6QK(;f4SB|F`BD^8
z-j2r)G4EjmE%ARRr3H?FC{AsB-ut)+KjM_ASzJslkd=&BAbTil7;DE(<cGISDLfu5
zZL7C0{15YRJTFV7Gr&*2yu%Ao`&*rvYoftUEC6M4*%JGQbDfU0Kl8i_6R0ZXnPkTq
za~**HNfXxp=$1CUl@-Q2T$gpn#4gQeXBk*9r7;Ut>pCIm?Pl}KgS5xAcY%L6La7Ua
zdu>giPZEln?`qhR*%kv6ZzsQRK9!5gBUxY`WsPe-5H9Te5NG$7a#A_=S2ue|>@UJ`
zUfDDCa4T4FoAO5EEa_q+Yt>9;wtNfdsS42zKnE6>s+rOo&%=k3F^U`06cFC{s}|h(
z^2~6g?K$96$IweFKet$BCO!Z7)(U&J<LY!kkr(4L6^ufyOV$~~c#k<xqxtCW=@5_|
z1Uio8LM9(6)>P2y7nP9NE?O0<=V+Q&sNa1pl~l!5<ef6LMZ#1py0{Wd`iV0r7N`P4
z3W`g}O17BaSAYdRrx#R9>*)!oPF>Tsv~|XGW{rxaX7>m{myk+&8^LBIf+N@AXRu#F
zwr(nJQLP02)QCSSgp4wx9rJh-X-msc9PLG5+9gmfP!0Ou1TwkmxB|-06YeAOULyCC
zNu%H-ED*i*GerE@VEE>)>P2jP0$j6~4Fqjbc7tidyqo3kbr?jQcqNFvx&jhnJORAg
z-Ntzz)cp?jfiE)iGX9Mf21`W_7uu*U%nk!w1mGwAzy%pNX<4;DxF;z4mU{(FImdC$
z*$ZUN1u{shCg#y9;QmqM3BieX4^pvG?vuPTaqbbxy%YY%!7YDNqdF+=+d`#~hQP?2
z)j@1U%Ui<O3TlWBiMJmtTSUG5)>D%O8n@UcI@|^I$O*568oLnl1!u#P>wMYWP9EHa
z?AE)Z6LG6|*`fj6D|JN?X_#1>^1EiN59DfD83FhIZ5hC<N4@&pivS(BH2uu%fF1p~
z`~oWrjl}%-OUaoME}(%4WF`T#=IH6_HUWhRCZ5o4RD=hOn)l>3x_s#<qH2j@T<%0a
ze4>M-&?!>e4Le>J07?yn5xvmRaM}OfdpI+taqK1HzesO`IQIt_Wu|b^HyZ@#l9A%c
z|Bj@#*&=PnYzeJws=JReJ)ZlFe*U47^g7`Js7KGVL3-S_y~Xa9izW6Sb2y^+*oV=m
z_s8U9`3<3zi<}gHXA=4!v7*PF-jABWBr_xC=S%=f?QUtigyyF8A=M*}63PQ)UIevK
zB<K5W4I?s?8ukpb0kg!NrY~dq2a1ec&*8<iwbe%2BI3YL2SQ>m2DpG}ltj^!)(~Ew
zubOzp%)k)Xy$B$%N<WtLu9gA-g=h&8-*TA64!e6ARB-*N2WiRW)z_A*UHd8fg-&CH
zGb%nke%9^Busdp0rqOJi1o1&w$<_OOvX^?+b$R}gH(BTFMvt?o7M-9LlqfHSV0e7N
z)p~k_FgB?6{uOK$V%zk{3$H60wH!@xHo6k*yGXcWn}e~Lyoi03(4Wl^hJx&%W>D=B
zpIe=h-LC7oZ<i<uo#lQ`;d=(r^V+6n55HQAn0m80gwqzKF#F@^#-g6^b^V2S?~8#X
zZ?~)7maAp(Nx>toA$j_4;K;c!{J-(l3DJM@)&GuxRwC=>_BnYkCwhe#K3c48zU=0^
za$IXN(y$|&sQJNl+D&me(GAi`{1GwOcuEeMqnT;=3c0*uIS3f^?Bc(}T8gDlq6L#Q
zcNX#9!;4M=DPEJN%aEqO2nzC6tv<*#GktTYWV=UkE&Qu!URt=7BFojOrT5W2pB>gK
z7zt`QhkQV;$DjlUeGV}LTh;VR@71d-v>V`j_J<cgnb({zj+>hs5H00(SwChG`<N<q
ztJ7B!#IL+}+H!xR<y15SbcJy6KDy}Mc1Kh3TVb;;r~{`onrPy*)2YFfM%%f7TO&K^
zZD#=P{`13+<CTrxc~S32t)~5*vmW9nO{Ya`eDSX?PW7&(efa~fZcxj3ZfyS$)O^15
zP^z7p|Mfyy%4V#?8<Y{nMvd3^j@Lw|q)j7lw!Ce<wutqU(gJB(Jyu8czQxD?1Te#C
zTiDk!q$93IL@!4c77Q8i6O)rKfFLwCfFlR#0q5$E?VT${=bi!NjJwY+UXJLRyO8TX
zUlSt;w`K2q2jewB?C+dRi(SktehmmWddd=SP9a{NOm?-h0rEP`+%8)z^^np=(Pi_M
zVDeWjzQ~VMiR$?`P<M_ADx&agFi0eYA1-v!dYHy{KjO#52`4!!fa~&x6Yu6tz`YD`
zsrw=&!1Q6Bo}P<~i@s0ifRMU0R0lm16O(2fdWN#046X@+&WfgA7;RK)H*B^|=83E1
zNy>&hHi^=6IJD2>_Jq$lIc9_o1H*%aT(?8N8VW6~$<50Vx1Fq$mc5+Wri%!rT;eN%
zt>Ovxm^GYiK1_s$7yj8TpR?frwXaVI#L<`0gv}K-Y^|bW0MAA<+L^KCrw{Tfng+eU
zhX925UQz!e5f=jbZJgaX%&*Kz+Oxt%u6?_^K}LpDbxKXdcp`;O`zuAQ(>p9mLJw*W
z=|OlR7e0T%tu?bg)8Es(=&KTqGxzXz>kzKopQWDABP3WdTA3jCHq$35xug@^YnlB?
z@F#A%J~c%HL=fNq8=(CPbs_COi|P-_*zvl#lL}G<DS7Nisi>V4a4-4|dRCr<%_b*$
z?F6kY)qp_2^lz(*i=1<3IUYMg*cTUR6zX}akdl%Mq4J~njow>1eVDy`l;2@1E963O
zp+e8C*_vX|kKJ0YiLdVj<j}k5#`N%pua^D^_P3BU@7upMzgfesuEFpCrhXXoN<W16
zO3%D?KAQ}{OuNuVI8elrGU$2L{roOQ6uL`D-r6hOH$J>0l-l^=9O}RsE?oN-XU1)A
zNGI6&H01Q*kK;K#rA6PGT@d-{B;v>EqG6K-B)aj%@g#v6#@0kC$}XQvj}m<^dfWq~
zSK36a23bGdCsHKCwZimS;#aO=WVc?7Sb$Ev7NX(f(1r?LaL(P3fsvt3c^A+`c2+J!
z7)NRC9Z;I!-Nl*gWan%YwVh0{2>Z`<Zq1Kr=v4`yoFp7+l)O?Xa7DA)DnA3^rssjU
z$~7^-Yw~Yyu9J^Ec1u}-JGOI0OAIjv#dQEY5)j-!2-uqQmGK16U^eGEowA)AR?~n1
z#AiM9<s<nc-W|4{Ip6R1lt(+Ze9E%&>gWOa_+R2(#QX+cxg!i9Z(ab*=1C|!Q{9xX
zf&!A&Ph~;@#xX{xALLRlF^Ztf%nh2tFp^Vou#I$qI||~|`roSNOmli;*I3?Cr+YSb
zAL+2(J9sW(Irq-p*(&ZTuWDrn1{g8DWL`11To+-Oh2!{sd}c*+dB|6=iw<>}VYU`g
zc=^pPC7GSrDB48cl)q=?MZG0C4l;g;eAMOndj!*0OXd2U`&oz^#Pe_)e{s9=quFzf
zx=r}Yk6eC}`*OV`r=l0__KLmg!EF_3(#tx$5Sob3m1;~Y_V5N_0m#}*Evl7@>pIT&
zO=4iCl%D+T>#@00K?gSPE7*4myG@E|DO+|`DRhXtV=gG3LSDvhWU%=|bNp*9@9)3o
zQL}!v{ph`d*u90f92IpVr6LaLU4T@ro6C7?!vWCb1O=gS)*O6=Y$e(Le5F<<bzeG)
z6_YK?$5Sd2dD-!D%yrTPCd?~%KW+>_`!`gI%!}@VAtT5+j)~r{kqU1-ev!Tnm)6Zj
z1PY42=uDV{Z3i4>!(z^;AnM#1^P-m-?HxDw)PVjOs=mFW*tSb0+k~`MXw#;AoF}0O
z(XPNZ;S!Lb``FrP2Um~WMph-pd^i;v9i1S~tAp(OxMpRB6785P+`%>#F8)n)Eq(#m
zedShVVeEHZzM>WDC4-vwj%<M{5r<;A+qFd&PPJm`A7Ds8W3Q<iu;wjMN{JTMv}a5D
z)*h@-q<pZvP&)jjTt(mI=3eK#gSta>m5oz=bnI>DY^Z6m6clVs&^sXhb@!<MO>_c5
z%boE@rX-rqp0Ck}*rXL#(m0<3i|r|<=){M}6vrc+_)SjQuqj1V=|N<nO@*}+Ra3+n
zkx3HCLiqm_!J?Q@l!4&M&QG8_SdNjHOqLmQ5y-a?G^OM9OB~4aasljo@r&0G<>1$p
zY{YE3e1+fVT>c_fCwA2{)wr8@TBw+j=oa^)!i}KgLp(fHjJ6WI^C{u^iNy&)3hBj`
z*%j%s|I#PO9DRf=V+8l9g(Fnjf#kV?&_qizWtED%o4;54YQ!^-r%$pU&+`gMCeX<U
z$HxBS2;AG^Mv@SkN_EbC%qOuwR&wC2DCB@44T0Ref{jE#X(wBe0=IPL%NM#^I2o#}
z>JjEotK5uboDU!B6fBTA*6*#e$|RRj&r>+nmtjV$=4a>)9=}T9j^NTTs+MFZU~nMh
z3ef&{qIfbw`*^aij>ec?_woy^yF9G;{kUL~yJMMyO+_|5Wn9|xHbJ(3twU`UBbW{M
z5+UC2r)JsyEV_#B=%nf|QaJ0mc%QQ!TX8p_aDNL;;_~nNQ|pHMA~s&bNV)uypw6zq
zTG{}yJ(;V0y>{CCq58QWYJaIVG)mUUrH_9?bZE&2Xwnpnz20t1jSecr<cs!&+4}A%
z&nE<zCuBZx&}h)9El(^XfAqJuhTXtborYpDBf=3`xwyYHrjQVsxIuVcun>~cwmf<^
zK;aIwy4v`b=-5V7kuOXYvm9gd<rC=QbO~rnx<^=gb;97_RPv@!Xb;(pfY8X;SD?+Q
zlF~mUFr;ew5coq?=?-tCda4>L9w))&sHWOfT<v<vRT8QbG}Tr4<I9RiyI&Ys1VRGP
z2`4+eFdsMS^)UZ1t@htMTq_RD^*&*>68@&VVbr?Ys`a*C!%7ANv-OkF17d|gl=Fws
zE|ObBWs&{<^7DUy^+hSNF5WdGh_%6R&C2GpIN4G*s8hL-iixTwEBUOP;%-I7!M4Am
z8m3cktBJkcY*rhX00x$UW{U&6=w&OY6xuHwHgiUJ-Ncks@SDK-3e8FktUh`2bzR>l
z1peykR#jTs*d46fWz}@jP%&$lYIuwtF{3?0fZ$U3Cgmr<q8|7G{5GzR#33=t{6qPp
zv2lA-myqZPyL3%kTffV-gE{J}R^^%kp(*_5QNp~j@z1LLa`xxouJT!*nV5{h@){Hp
zetDGJ%0N^0qA`Hc5_I#X54O=^-Z$Ee5{hFpM{Jrmy9O{~P<!|B;k=Q7l<9Y)s6K09
zlD|su=90bpygfH2=$QH1^57Pijs4p7trg8rJGO;{i5y`=RA64LUt<1_Fku3<J9RI3
zWn@g^>=^GD$lVn8Ft9SWqEzpR!~bsUd<K6h3{&R**{dlF>@$KK(Uz^hlKWV5`!#7;
zSPq?Kh5E8mIC2)6WnRREBgY$o3Oh9I_^xim3m#?oKx{LLK^v#97m!*N!@*IytgnY7
z%Od6EE!*=rNg(c7oQ#IMU7kqx9}Gg~WmB%m&-;d4?|BgNKja}@D4tL~lR6Haz?ZtV
z1wa7Du32N#fp}#yHknzaqaU(4m378U$nsl>{Let1^-pg=ts?Kg`h^(il>J5V=jx#M
zjC#!6`G;nIxL1dbK2>6S4V8ygU<u{(%H(aJ!p>or=71{Aj~@MT+5&ai^4Okb<_4LM
z%X)oE*ejfdUDYeTv&zW}8a{rhP$r%w#5EY7ugeQ5s4R-CVyI<ViTWeZFuiZQa*V;&
zUr-Y1ukm**Kszh3&S$zT!9k`+vHt9x+!CkSKcf$Mh3VFf7({u1$w?a$09e3MP+OOE
zu?y@4qBN4QG~J)HtKHD;7hLRlqp6|!Z5f}r=y%D!fqC+;qI`oT^NY#fT)Ifb%L<q;
zpM60y{!@qb3>(g+H{`6hdi0;VJ>R^-V6c2wXqPjETo@&m?rO(Q%CTH2OiwQupEBJf
z3SI}4u_p6<mFAv^*pCJk<zbksRhq+Oy#jW&r`f1f1^xnkW%!8Io+_?}BG_sie%$3Z
zUMw4X=}<`4$r$Za*EP0mu}2bcAr*l6$aJJKbn47K5$CWh#Ik-kae&uP7CH}j*?>f$
z%xey;Nsqa+k!}9X;F(h6SQ7!w;iiIL35Yphe_BehNjCJb6Ujj%x~$4dL4`|J5nVdg
zYKhkv6S_^dX({>E*71s2x>f6~{|sC-O}u`@8IwW+bnR_Fk#*?8MQq}VZ?(zm0QvA6
z?i(6d26SvJvZ+LYayF@Qmdgv`I`>SDXEf5LAnI@(oqIb6C2~?hnVx->lu5fVbf|oR
zI{|CgNI=eaInQ3Q2FtGHj-@LS2i=?}0mH4g_3mz;hX&hc%P1>>VN3zcIm8Q%-D)RF
z6-?Gk3`z-wh&{y0avXbKk)kfS4Tl;JjOhUu+e&^PKDk~?U-?=@8xwmH_YDX80Hs7k
z`3!4UwAQc$eGN%`Mc*4<N%I~zO5wg0)k482t8SA4TFQpqI5i5LgzlKaio9GC*%!nT
z$h=-c&4tpQjlDF8VM`x<TIFE>5xLI5)}vIJrcUDFiqvhA5MLYAY|!N2GUk~mW_$bf
zlju9ttJUHjSBErA&ll|RQY2lcM0~61bc~cfWrcjU&9j3#VPkhq<wW*G5Zzn&vbe1D
zush@9%X84y*8E+)u$t3J8eHhUY=Y}7qLE;FxP6(IBKnZPE+8ZN9NDTcPZ%VO>w>aq
zZ11NIl>h&2nEh`XZU61K&b@YCAE4-XayJ?X&&V&Q|JmSM!0i8_tCx{Ib>b=EXb^|~
zUR8_{Xc+!a%ZMN7?%j2e$1GnAl+lwvaNwtMcrDW1k+;bIAA#32QOiAjw`Kpa3g`Ra
ztj!1>#-Dsg2YGqZw9hZG*n3}=hNMM5H~;=$-XY?fQH7hfa>J-*+f_L|4<N}4H^7<$
zt(ueF-7DC+hT2oQYH^u?4vwz?1NXDoMQ+Xgz$r#L%i1(4<bXgRdPhl3M<ZKnYnY8A
z$cx>;#s>E0i89R2*1_D-*4`ZE@Pze=gqgjqwYigZ+H8kBFoYI8#Mr<QCTL_20~R1I
z4o)ss4gppUZdFbmK`^Hv7!14@<ls=mdF}qo0Bc)ga}(EpKR{Hg7YI}Ufn+2VpB0Pi
Gzx_W1TM6C(

literal 0
HcmV?d00001

diff --git a/doc/assistant/rsync.net.encryption.png b/doc/assistant/rsync.net.encryption.png
new file mode 100644
index 0000000000000000000000000000000000000000..ec751d10d253ecd1a8abfb70afc79220844d96bc
GIT binary patch
literal 40504
zcmcG$1yo$Ywk_H?1ef5JK!D)x7Cgb--QC?oa1ZXm-9m5=!7aEn5?s4+Y4kTa=e&F0
zx#y4Z#+S|L0qp8swQJR?B{gSNq>_R(`YYmB0002}ql|<K006fS0KiNl!$R*U-dN&6
zf1x<ZXuARc7{6XVFewZeB+#2kZXe|(kycTNaWNP-?-}!;w}{*%wcNxV?d{DS+yLS(
z=EiR3W|W@RZdR1iALW%agE0sI07}3|i4SUC%g3vZa;8TCEY~M%dv#4NT6|GC1iUQA
z9jqw>ov-Ipoai?yUulxXf32?waX%T*BrfCpZ9^&4ml{Mb`c6)rusF<uV+PiSt-`3r
zMuDN>wRaO|3~^N@aXH&3vm%2+`0j|uw@t~5HWTMUOQW<L{>G*;o%84C6xTh+C(?zT
zkCqVa?!6nq$@BRBpHIhq;h2<fp;tjW$h9OW0($L(@9Q@UzcW5>i9BtIJkE%)eUNy$
z*5fH2_ochfNV=zHW(seQEo0M0WWK7=r=;`#t>9#xz|ik3Des}^?Ceg~{8KSbrN`fb
z_?`BXE>*^%Bh(wi$3smyd~E17C0(SIv_JsvsLA=;=$1;=Fr=LQZ%a1-RL_?u-{OP+
z{{QRe-|s|(3cNgtUGGHu-%A-+B429ww^EZ0g}=}Kvs9}E_wTd+toWa$|El=kO8>3d
zf0q6~Y4%?)_5WS7|9a*BT^9e=+yC6G#DA8>|50y?K!b802xRI<(5HsYuwF!odJ`tr
z8b=9u`$f3t_7Q<<w1MjBd_30kgdeO!ngD_8p}i?23r~R#Oh7`YZ=+I8EfA)jzylX?
z)gsCFRl(MM88G;wCdKn$DX|~?01)*ov)QY|fhq=Oqf_nsWF!Y+RS7l{`PcP1&f)l$
z2F$N$7K9Ep1wH&G-b02r{_)Lbr`mH0``NV=v+TX?t#SV%jCj<2bof%9!&f(q+oY7@
z`*4h(<VQ4t0IWCZFv`Xxd<fc~DaGoz1v9>6BLSvfr8{(diqdqTH(-C$Uobdz2nriN
zPvA%}M}~!Wy|4|QWp39D(EFT?0JRZt@Tin@T+5uk=mIzr$R47fv*7`~Q-1OMxL$?+
zfP;}Tl-;b_3UuL_s*tGOBRjo!9P(i=y_cz-6!yDS^6gflTY3COA?&Bsb*6Bz93o+m
zOX83A4e9pUC&cdwWOI2cm>8<}xe=3m9WKdoM+$-Q9kY0_6=&LrICHOE(9GIVdis}P
z)dqR?)=tvM*WV@6(NEECv<DvJrAsQ#?5Z7#3#0*pg?%-{#Yb)T>|Okg$be3NlJyP;
zG~eruzC-V&^AqfvnyQ52Ulx8hx16DVC?=R;j81XrkrUp<6!bN^eX&w%6lpBYI7o?F
z-;)^tK}&$N!Ub+NgssA53X)9A+NNKrJE4Q|FzHockTjO9%E`B9Z-Y`C*SS^;bK$#g
z``6s>1!^y7D+iHEBhdi7)r7g;jLTgW)j806rQw!mZsuC6ePK^$?;@^udwCo?K3dHF
zRS=ozUZXPKZQKVnqN6$QB^5=(M#5->-23>^y{U1)giA)>cy!}sfvHcaP9jq7xH@<6
z>mKhnS2Q}L5%yh+2d^1-IBurFKaV#g%d^KW#MZM4$K)L9Jx=hO_vn1!MdJqak{03z
zCrx%>9eNIw(e6p%=AwfpY?)!&(3r*$CZhqrQPY)2a!OuhJ<SkMxnA3xzN$X(5hMX-
zUQp~PJ+TeGN}hOCUbwaSXZUU;*U3FUG46Pk8d=O+I-`mdxO$lf>jg-@JXThOwOvk|
zPMovMI>R9cAW(XyitR(Pa?&0Ps=w~tE=;Dan|%WOMvAZuot;wNI6GL;6aZq~bA>oA
zdtHo`p)){dm2xE*vezP8Px5?D>%v}la+8)vda9=I#d0h0le@XQBH6J#*>SHRnh}KV
zoqld|bEKVP3J)9F<Tx34j0{W|wg<>gt84UDD$iFGOR4DG3%=hu>Mzvnv#sS(bj-dc
z_t5%nis+QcFuY`TbvCna4GA0Ms9H=}9u0VqCfRA9-Wk4dnOid@Gw|*7x*X|zA{N5@
z)U%>YpBLel-reI-r00$?0b(NW$`n{RaAkqzWiaM(`X=IAv8BrBK(QD0P)iVRFiv{B
zzho+lk{ngsU!ClKcC|TGIrYc(5*=;`ru}~791$X6R<GB1gDwwmI7tS+#880oO6miy
zf-HJ@to0Nv@ct@A8T!qAjPL5;=#VHP9js`cv6n@_cNfX44`nKUCgfs$M$+gMV;xwe
zWJRfQuKagku|6&RwiQ#>$#S_Of$8Dj$&9Lji^#PcS&$-?qHo;V$~ddFg9W6C|C*I>
zyXQy4CUo<iT(g6X$jjyJ<OU>MoT<S8e5w_)HYKN>qFyzNhi{x8_}^Uq>JW$j^Bq-a
zX3LSA0Ore2$5K$P0*+TM15f-rUolQ%m|pIkOqs$#E4gK~yN1#d_{9O*)R9MQcTjyX
zd@A7Rb~b7hx#!(aPLU=)0t761wJ<x8ho+95UtcCIVE{8RmJW<@<Y%WpPh~jx<VhBi
zi29A+LA~2u?`tqmtx%a>!fyfA{S5Do20cRnxnk-wJ+}BRUJ+W5af6=lDzSj#9RTo@
zHX|vTdhsZR^A-LZg$qQzztRIo6XbQ=bZ8(Qems>`>d?8i;j&63#OLl)3ZplmIJ$F~
z0Hpdc-D@SN-o?i5)hRvs4TKK(!|BYnYK(}Esni0fyK`IJTWP}3Wztxfs)T{T&rdnF
zCM5gb+%}ks!@Jw%5IAJ9#E7ZAQwo>;jvj^dd)6q=F^w^392I7NE|DBGATWjo)#oY9
zGN;<kQ_2>iVF?}>!X(Qi6WA8!)>oP-^XL0It;b2Vxg%!ufiXaqAr(O^V0=wU0*k(*
zQsr`7znee!$F)aB-`neSB-xCHMM(@7{Lk-wbRdibjYnp)+ci-V{X)A@IW(tdW78zh
zqzM8H8;m*<mn%^h#vCiAAyNw}5bD<4W9zcf_*|i;<eq>n_j{=iT)`!o<D_kYUegX8
zePb`K>@n!o&9W`#orR$487|%=$Ga~)nw<=_BqHZ01sk<+mBo&CpxukB{W*P(->Aqo
zf!pszYq*)|UPBz>Z^o~+QDg=b?3qurAJ9bOy?+~9U)V&J_}WcsDkRl)67b0+<0#|d
ziZUY<u`e15_-d~l-!LAG<yvfmj?Xl37u`YTVNfTrkEGVJa7e($FA}&<0axd*Ll_0h
z%+@6MdP%Ir2sovv5ml;rfbC6ksW&IrzwtRn#7=nkygw8h>w`x38X&Xu!>YoM@}qE$
zo!$76N5>Kv<`eA{ZsoW}mmm;i4e`0mHE=CYF9#MT%NvH8I;=@RE_NAMI_&&>+C)UU
zsLfa@MmLWI^InA~@-f2Lwoi4s5LHw8R{yRa1i!=T^rzbe$Uv&BI_|!>zsL9hfJbhM
zYn$HrD?4k*gX-Z}%gihfr)pPcn-6@sii)nicnV2ty6P9`PjZgf%6sY@lVaqqmNu}l
z|H>{~@B5$G70+Y%4UH;$?<Q;VK9Po#P}N7UVz$9#53p=nrgX<&q8&Z&=8W*UR~F)U
zZ(i>E#A`O&V>C-CYd;zC6Lkg{Uw(5a{B_uHI#WNMH?Cd0U4$S&zBQV*wNuKjNgI1*
zrYIuhdn^T8*^8O#ShP8qGG>9>KovbIl68N#bf``icvUXJ#It5&VMgu@l|D3F0wDKH
zcOVI20`!uxma5b&92|Er5yXSti^LNYrZ<*C2cv^o^1{<<ZI&uA{nHdu-{i<d_FUUw
zl?l@AnF0`nQarAk*M^1xMM-{kd|rf_XaiekfT0wuHGjCCQ=^vkvSz9!EdZn$&{5ds
zf)Y^Y%lHm9L80i@#;IK|<l0ACeNr?FiJl8=Y=nEDFGCASS^_DRI5fz6TM2|%q0j<H
zhq^=Erb%?WMh1;gmuBQA$psXR=G;$v#f!v;x?}B_^WaL~71^bfT1Y?a1cG>KSUBeX
z8WNj6+S~DR-TLFiz$%rdnpk48B=%EItWmOiXZNc+Npm2QDvP0){oA0W>P1K*g{C2D
zGR!s-E=K#tr4w0?5{pKccN&sZUO?;^2>|gMrVI?tjmfT8H5)k!AtZ#BPQ7c|+RefL
zJW;>h&`=l^Pi1gtAhu_s-4kHZm$nCt7R@JMH4I!UHg>Xj3>_?(SEGJ!FC2)t4Y-6s
zqzpCKTNz#4y-+FFLgz|Nc~m4&;zu$<@Cj0b_<l7a*VoN+BZS!>&V6E=Zjcs2QM2s^
zpH=?R3|66_giTS*V2iiw&IS{tWZBf8(PSu-YP@6x_IYDGr8fR>J4G{iWSI=v<ZxQ6
za`wj`KT~#Pd)8o(=2A#;Eb)F~_mLO6-WYx#esjptyH}dyx;Q~bkrK5OZIEQV*dS~l
z5;Fszz$e0`149_xm}ba?lwIsqr1bR_V&xJ@JL^YGe*xVmfSES_mk~oz1AlUF$QF#R
z5VP-$fjr|x)&2O;FH|9uUbR-nz0l^snKsW35|)wzf_EsLQd;5Uiu|SaI)OF^^^s{u
z0*+1biBWq&*-OHl8@ZmuxZx9GG`i?>);PP@+)W{oCY#jibb&DHhVkPEWDSbfn$P(7
z@(rbdG0<?s5Ekk3_=f&=VK012k2{wE#(%fV_@<+_+i=#ZqIe+7Ov+j7B{kA<XPImn
zEUKhe+QEcv5IwXZ3HN$5eydGM1;;J{V*%q{n;M*q_A!jEhhEJf1>qGt8f-;MI((7Y
z5cDrbSa?ci@zmFw-o7{nhCoCkGU6resjI{zYf4%e*fB0&_yi<&b~B>SfCfO$LX6s7
z^wB&Hdr_E@IVDq}lR7hxg_Pp84lz}Z@2t!>oqL;jO;ux2^I1-VX^XAH3}uqPgT@tW
zxpHE@5ui9^I4SJyY5-tu4mcf}_#BHu4INUOZl`Cqq-lQ@w1k<#4VS4UQ}=c)H}>F{
z{4U3MW6ghb5*DI&c6fp}&f&@doAeVNnnpmg#BSTK1?>s4`O-oCeEeGhvy<PG{?>Ph
zSL@sz+Sc%Z^zA`bf+hhfqB8x5EwvZ*De%>937jbUo8heb{~skx0sEotc$MAxuJ`e;
zEoah2G`@JcYPEkQg5bD3+(#$D-5rbzwQWI;onl>o^W{WnwXBcixAq=Kbc4gV^|OYD
zYX*hysjE0Fa>!a~#pf+(+S7?3?3Y)n&p*@do2R;$jn$8iW9`8*Pmac6>!sSX{c6vv
zM+jb?VU09jPmG^Dy9ONnf1g}MwafMfR(U!>lV*ETf$zGCrIe*d<id_E`SOz%x~Rc5
z;V1r``5e0!idGYiIm65ryAU<33jy##twUi*V_(Jm((>O%OvBa-wR!HT{T>~E8T#HB
zu=KQZR5d30VP14!a0NVt5M|zzKR`-z?F$r3o#LfGOHYe3`u*0JGJImPY1@bt+=egW
z-G--BCr{ceEk`TT8plNWl(kCvL1A{K5~9C0C!1|`Mc`*G<GjOxbY6U@D$m34%-#Bc
z$NXABZOEAtSm%#3UH<cgu9%S0@G*=Z9kL6?V=pJ_IAm?iAwp4MMDR10Z?U;BTvJ|U
zajNkpUdTH<GFCsfTjhSOJ#=;_xS+Z&^;}mGTExv9%V+&HuZ?nthC|}H%GP**+f3Y_
z(nfapu=^s*^GJ8TVbFs%e!jjq7SYkI1A_hWq=iSHeH_2*XTG8>41I~d>9AYJ011+&
z^Y0_wnVgL#%@uv&7+Xe<*tNONA|K7kmKCr7?-be9);+18a0>;AzPEqf!>@yJG1i0H
zrG~^%r?P~vK4b%*EiLx%BHgH)S_3oLc6Z1NmE3^magf&$*Gshdde{w$Kbf0HIqa2z
z#{=!3$a_m&W!F1k;Q0buSq}~Q7V+gD0UCK@^2ekZG3jJyjvc<G99Hk^UoQ*F@1oPx
z^B!_(b+7>PO9V2KXD#tvx||z^RsAdK7hYvC1-9~bbAIpkPaV0@>7TuwF0#5X=rrSN
zF-+JdFMYpdkd4Pk4j5I$-%FEfhAYi5yuOAiY|5WZD`!0rRqLsn`vJi^VwawtjyLJD
zu<Q=HR6g%vCA?nR$MHYv;pItVW;4@=7pye_+TCZdxCt{GOHM5biD(w}til%D!aC(<
zyA`F{<(^w4;S*|_;f?tXuYiCA7OKIc_WCNKpuS}1$y<r6+70<n_F3~`>P$rg&dQ@7
ztJ@wp5#ML|S5gJ^6McsiHEMgBcI$9xydfcmbABvLE^}`d9KYt7RDl>|rJr*FO@T?$
zTZ_|DA&q1dm*_k~Zx2X4W5@9WN^CdQ1ux54L{oz24cK$4o%KU%7Bh2A1Hu`=HRJ;@
zlq@JV(W`V7*EL}IIv-6}y{>rZ+{tx5>5?!LarBU1j`gk-a9;WO@y5;W*?W<$3gm6j
zJu-H}WM@&KSdIAAc%jYTa`65x#oeEUQZ7^j4&YbIGqSghNFzj?HOEfWPj`2IKpiBp
zxk)NRGYKPeV5SD<Ad>uXTe;XOTEg1B=lwWR*Th4>R;)<B;9y~TKk2cv`H;JJ#Zc7|
z&=hSaw{fQ&JFXC|waD`7Noev&b9f^~^xL${otY=tJ`c1LcYjrhJ2^Thx)U>M4HH~v
zW&k9C@YK4%ffubW?>s3j>$Au0@tie&u2|GSTMK};)&*^?MA3tUqZ~VBfYtpg(UeKW
zfRb>AkN5X`L9;J`lhEG$S@-pzG&5~?7rN>QC>EKUGp;_W+T;dkJnGWsrhz*(`+RE^
z1X<Ejd@7pcEBh+&RaUo%`O4MP@&+hl-_BadR5pMI0@MvEQ_*9Ce>-|>GM}8u4Uz+M
z1&Ie!xrwVlExA-*C!7}+<@SDxEG%R$i`ueeD9pFye$cd)R}2%-bN0MoH7KcH<nr;X
zaWR@DOgq^l%Z>>3UHI63?>Im^2#ATl_wbAl?wHU-6jxrKT`WRi#=hY0<zrL!A8BXn
z-l+GAaf&+CuH)WV5gCPXibzRv!vA2~z>j%+{Yx87^ey%Y7beXF4q$Vy9_hN5n_rNZ
zP1q4v?=1}zVIDC$Ie8kzx-hTDq}(J>GA*Lk4mx?+356Z}TCXi~4?c;d`o+!2)t`Uu
z+h6>#VEbA27ixTeJDcHZz|hf^_8**$vlxl^+Q0>9s&(Nb^a&>3o<ick<b8H%R-sz8
z!pj?TXED%qNRa)u<Q`#tY;pI)kNVO(RekjZZLZSRY1HO@_RU0W67td8QSV3K5B@5f
zH*-QYIY~N=5M?wK)36`>M>g-fHQtf%BZ+1C`gC+icgG1e33>mBXR7AbS~x3_rq0=_
z>CDItt?lOO|EvF1&O#wIQ<+bu0lo}i2l9bhI3;W8=Q9b=;<@r#Z=_a>=gbc9F`0L}
zDGSg7DoM8Hg>V<$s69$LEPD9skJmlkY3_Nzz?xB_^TF^rVB@|k#=msfCFGCIfsx6j
z&2jK#&wzKr7ibV5wRc<EsxzRNvP<=<P~xjhr1!F4I;1u7vRm>}*+{OwwwS2=l5P|C
zHBznDxSCoTaLhGmRa$-C0-Os>eZAuc`7ZfBF>!Swpg2fAQZB!^j5DnKD5KooZ*e|P
z<~6ZzMR%_T5hBfIuqC8<G65ZBXgL(W$=X!w>i5LQ>g5MI#Bw%qog8<bo66H=UE*)-
zY2%BB<iK>n<-t@8OVgRZ%C{yr`P0!Hh92!l?z@>a;sw5ao9agYv4uQ{fEQu+6Q6W3
z+2bH?qv@!$Hxg}I7WjY*taAEi=qL-TNDE@bDQvQej>tnE3pdV?{MHDsHr}8l6PWOI
zcvbY6l;~r^4!O4ba~roS#v%bXM?%A1#?K<)m0$}ZABl);wOpeslfHen6!sjPJc^b-
zK7LJ2SaPt5^|!N~<*fG>)$oMsYuJ_bguyUrwB)h8ordN~&PNH-Y8YB{<;P-7^wq|P
z9u~7YWuWpWMBT>ko4TtMV+ir%p%I>x;9O_aRB8U^e+UCb?Yxk%XaLRHeSR)S-QNAH
zr;L?<JV=gw+*CHaq5c5-<6eucV~OQPa~%Mv&km|~&IzfR*8vXtJ!W)=gr6Out1V9j
z3I@kHL)QMGAo6$AZmCC1cKu21Dcw9QBQhyyX|(wP3q^5=K9qZJ)D((`rmrZL!&B1=
zn~Fbl`^$Wx6b*6{W}m+G$;nz`G^sCTAxF8o)V7zpywt`W%okJ48=qGA@J?3y1E>D#
zL}ByEVTQr_8Y;3paJF@6T;ij5gcK-NklfSCc=mt{)6w2%*RT>XCKta@g{;KEvSiN!
zRr_1BFQ456jfrEMh|p4CYEEhtB<Oi~dW~uoxbjJ+db`Lw!G@zKN&ChhLn-aL%vLsM
zF!h?hax0?9b)}JerukGL)6OSVZttQscAlSi_bBERIybVK3L8AXu95q*ocxjSobm5a
zlfoeX5^iA-^SF6;u{;n^&nDRH;e^%owEf;4u|X(DuzF3tpK1=+d+~F*#eMp-v{Z{k
zI_`+!TD~g>K%-rVG;-M<6R>EHDYj8Ix3-&CQ;Iuv1RO4#(`dE&eiGc5&ChH&et@@u
z_pbEYskI3|PkSO=Wg(67d8{ITrBJLThXFF?X8!nA!MOItlNv!?@1fOu`dH&b7mKPm
z5+>>be~leB8>;X-3pbUZ6_y^$-~}29j(3m16&0B~*8*CZMxyESD%<PF2qv>aS;NM%
zz<B=V*+4sM$Nk258U8_iUk)ME?wR2d%V9U+JfKZ=r)k&P*!pmv*NjKzCAi{zg2ugi
zL^lv=@1_n1^#(jL&{yhx6f>yddiq)Q*I40`>Tqf-&$C!p{#0ZibP*n!GH;t1@px&t
z$`B^UrM=0aq!{jcgjmQ(#cL~s1HLWLziUnqvHrd!9}?HwAUEaE3|9vPS!Qg0Gp*~4
zqku1TIk%Oel{q1I2wzzn8O-w@p#2=Iv{P=!+j?c^2~paRi0B%(X{9Z}Xcm_VPZ0Si
zjjv&u;>rN%GnlkEbz3}AN7G_P66AJwpV;S5B38CWSJmX;5ah>RK^sofO)xp%neVl*
z@=}9f8Uu$mVyz1|kM`ORP8rV~-{chajdso(KLXu2iZTbU_9PTv^k+_c;qo54@w;=w
z!s?xh+#_V6y%=m7y@u%Mp?CjRm3U?vPJy~XOiURVo>LySOr#gOhA*CM?FU)x+Er#a
zPX65a)V<M>mg1A+J=sIjU9QU=-fFk3`RDv(UzhJ^3juFWz5Lh-U$O83)L8CSTlQVg
zm7m!Sgs-H1E+Riq3G;HecXj9l*qE3fcvG6J#U{hEIbMxd@%B3%FI^0+@pKK!+D@j0
zbn^ONp{5O3xZk^=En~77`5Ga;d=N=P8uyeDlN}iJ%a%E;(sg`@BM8q2C3~$-t9?mR
z3<Z41N_NU~N`vd(P`pPmnHOZ^I<c`6b!})9(g4Q^$c?sMmAdvC@FlXf(h#iLV7J+u
z;GJTu^Aee+>#!i{VM$y-J(cCVKg)7962)wCt3zY%1Oxi1OFt)61BWO>Q43lf{VZ3^
zRgTLi)E2rbni_0?5gZJYaM&{eKahqp^i=~qO`~mqKiFP8op4PCZke1>bsXJzf`%p8
zg!;me=#1U$)g9?_S_memui3Y`hofx4%)wL-;;N&T>;JN3&45bJE5-~D&nds(jqU5l
z>FZNb?OEYxB_OLy2fu&-WA}C9NW9qj-tyOafsBQREi2aoUJW5|Q_|N<;g}RQCj_rT
z1<0NC!sL~n7)ViMMx2l%KBg$bRIXViBf7BP!D|Jzs6krFMz(O^VKiXgCLpP>lfnY1
z&4)AtQ)=tAnIIL;8@r(I%cnm~nY-&q8;}>_cfiO&+Cc;TF;Q7_pn9-_SQuJ5Lb@6^
z;MBv@n}gn8_kt`56N(DmfOB+u8Z%}w4D8eS$K*^2n9cD3aKBl~O2jNHjtrooLBIWo
z{ia3k>zm4!m&l7yWos*nZ)!hODk1hoMN8|Y@RF8zMH@S3c-iTMfdk~gte2pxi3A#S
z{X<B0C9WII%>dgIZhiKgzY#&|J0T(m-~QE|z7{Eg<<9nG<pg7_-z<~?SKJkyVvbj2
z9S1d$U5bby8*2n$w`Li(_eB0pgk;&M0arsRp1&-8WbDI!(?+5`Bl#2Vnb5X9{(Kyi
zd*!~lr}&mAq9hV@aM#Bf2$Wgo_#*sK?^a}`kC#AT>L$o?rJTx{2-XPqFpywuo%`!G
zTD~F<!4oEgb)sKk*1bdRWlc0<-vA$+$MOCzjO$79|34&bARF}|YW0BIk?LoAhvD_-
zmvsS-JpbF%{Of>xr52H1%Qt(Jqge3Bh&?L)Cf6I{0Fsk6cW290`wQ;3b_%JM6e3T^
z_n^;$Mbr{|gJa|`%ilLcMy#_!=UewniFVw_BC$m{f-Ze*|Kb8@%e;#as>@(KuFveS
z4Z`l>Lu~6By%1Q*Tx)xz0yVpyod#Il%QvcY$DX}_0&QDh^9}NQpSfomgi8SaH>BcC
zYZ}}Yh3XwmvLq6~1Jc@2bul44_GdB~@sSV5mDyQoEWxnw97YvODnWk$-xD~3kb7St
z9|jk_*`bWUvO5IIK*7#;$TrnGZ%P3$pI>987<gTj+jwqMQ+{yb#FSDHOQpQlzxh#2
zu1~APqz14aYQ2k@3w?#{LjIZP=iG_ZHs>}PJQaMF#(A;U_U&cI3MF95+tjZ%AT=Z#
z#>rIl3Q-X{e7}A^dcd#g0SNV0NSd-FVE9lHhs<gGT5^7*jV_+1Qv_YC3TUSiNIewf
zTUy(@tas;(^%{pQbkh-hy|0umht1aTT9`L-Q)@cze~6yi>M<6Ct0yoOuI#^2DPK;#
za7^n%vK%HIL%gLyl#A!agB>5-${HPvROv!iWszF(e@r^UvKbk97zWNYTH(O{@wnvO
z<DpyzP~LMlwGzpvo=Xz?ZZzHS?;48!ND1L2_OZ|y@JtKgLt*LiFC~h}#+W1r8=6Hs
zrElaCDJxdEP|d;D9FH-CzuGn(-2ly~VGJ0=c#T0@394sPYuIu=yo|NI4YoW`hlFnQ
z=rCq}Z<QXftRf!HBRfkARAv>}M5;Rj>$^jx#Ja@4CKy!=NNzvC2VL-oyzm;@Sin16
zU`&c9G&=IzaQO+g9(ZK-gybn&wTVV3kc`#S?s-zt9F8VbiolQn`zfB{(x51+d^+TO
zb?U>#c68@qDyEN<@^@H(3ZRKV`c8kw-QHp=zcjiR#|MTZ;o!sB)m`$GK_Ic$(Vii>
zJ{|yyX_y5S1e*2mbt>DB+YdOGU}BBlXSUMYXj*p1K>;+$_X%*XaK$awKfN0w@0nU~
z&1?V&ovd|EBh!!pb51E>0abu1nc^TD78`5M0x}z6>;V2|efS`x9pM^zG(JCu*!+nq
zCVS>Mq9DT#0ayvqyYmehm~?G{Q(igZ;lNv`>qFu^7{JMz{cK#Q8{`@?>$6)CFFFD^
z?##xv&n@YFVQ#Ey$1b$2k1D3rw^;%NFQh&5<ft_QQv>f^-;gw+ddH%E_}X;P+NX(0
zqXFn>rQ0Rrm}^gLkOQR>-OrBoPONMwocu-$3hA>lwe5YBK_Se|(i1#IAD2%JGNPMq
zS(=iB>6slxd7c`m3&a!>2Y!?WA=3UFk~qDBKAGo>-4k$J@X&J8uW2jI@YLu09DH)N
z3?KA3b3`dCTHxrn>tuO$n&QFQ8$t)@`#rX@F)`Mw;Nc|3BqHxygm2>{q5?k_PXL8R
z(V4)2klwNnY--JY@O>e$32}pfBHT0BAcIPv@w7tMbJ;m6{PUF5mB*aJDJ$G1#`qZN
zKY(3}S3O_{EydFpYj`u%*`YQda&oR~U+%Qc>gka#OXXuc(7)evUHDEUMxj5AQ63!_
zTjxt^+I!dDpQT$f21P>vb#mw;BC9c_cmW95?L#m_HI7mMA^?`6S#p39vBU;r>z`&m
zpVBaUu#jTjfs~hQ^p*lDK#Mk8b&xKZJ|4JjCdleb%JQ-J(|vIpc&vqNV7K>|Dj$GB
zwU3($a5?UUKl<p{DZP-du!_v(kqcAD3qB^;aLL%5ASm!D>oaiVZ1M2(6Fl&8^T9!2
z-M&U1|9aA4Gga<p?Q_Wp_orW-Vw5E&*RpFGTM#<nP<{!}9M+?w<cH_Epa_xT@URxY
zE2*9cG>39faHJyudn6(EP}8q>))&{Sd|Z|@G3}4ZWWR&OtVru-nE#B+Altk1X!V9T
z7T>49@;bKxl7h`!Qc1$gn1Xy4%fnoVi2&O>gF{bHgB(kNXxdD81+Q9hfDCB=c!g=7
zb-mB8b|yvDpLHfce62)sST^_?9kHPP;-k#ej4FV9(y4N|R<&bk@I1DSVqo_3%d|Dw
z2&nv?;EGj+AAwILDD}bPGS6#ofmSMh0(FM0nRzei^Aw`!2n_(x`APQ*R`R(QN1}St
z`fO>tS7^`K;~a{<MM_MthmTfD*LJnWDOX3K<yZjF?r*}5r9OPRA3S7n#=b<HflJ=D
zQ(;{K3>|#&sgw7iw(3%vFnl!-07%&CiN!1~_c!iFzDS^T^+}GgD|xlghN&TYsPWZs
zK@#p0!uu>N`RgNsYr;!}7o+UvxYBLAvd(;~*_|!xASBKYe*mu{HxyP~3gtuCf;%2%
zj9?(h=ZRY&bAUf4X)G|A0`F}AtwMGLUucVJiyE@~HDn`+&ycxpPoYx}4@M8qy<cg~
zW`NLT*m38N-p*9Vxo4;i{EVeLfOpM6>WS(5#_!$l%jE9YGN91<M=lxKr6eeuBs$m<
zCKe>!X#fZwrvo$(&ZwLhZ{wfSy0fqW!(m7rQ|}4+*7OjK8Zlk%p@v|JcK0dAS;Tch
za&osoy0xqD+eXFMI6(B|_pQku$T2S?PMSyg=>hu^?H=#x+YE;=wq6Vqc?mgb4N4F|
zD_n|3^X_O=X=bq>;<G}*MWs{Ij}BMpW5O!vM8F)ECnSOsjCc2&Ct_vkC+>5!<9Z|B
z*zf(tspW%R>o+cK%y1dGNI~c8=7-0L%cu)$W<MS0*+sDlNi(Mx*UWjUZ_v$L_C(_s
zK(jdy!jw0c5M_!ugHG4g+mA*jevij?_l&NBZ2?ze7el|O7r3E1Uhnigv@7(u?@NZ>
z?^@oV$A&qy&($l)%Lz{RRI6<-d$bsDb6lG3ik?b43J*qRN4X?Mq8S{>DH&ku#85Q>
zUoCyOeVZl`Uq8rpoTJ>*6cDgGMJgA%cqYjfZD3m4*U7o11at&Z;a+eY1-LTfP7+mt
zz4Jb#V!|O=7JN7hCGM4LyPI?cmj5=cpzA$O*SdtyV=1KO39DG5s#bbw;_OPB)h|&t
zf5GZHcH*A#kmU;iEd#ZbFCA$$HLROWN%rZ_*z%G_ozhoS|M|95imT}IGy&<X!E!e=
zEGSfz;~{iNa0&lc-{MzBC!LWfVTg!u07L~r!Y~7wmZmsPS8u2rn;TCwM92iux6LAg
z<dqy6j&bN@u;8^2=4v;S{|Qa$HE5gKy2lp<XTygCxu9ewPcifqT#A8==wSdBFf=b1
zRf<TiWOZUmzJ>vvIDFO5D}){Ntd9wskY5M5fj{8osu4QlY$DgGAv==?X~DuN)Mmjk
zXaJ3?jBnS-(6N{zo4w@&-!wXPqc<8JiR-7ymuk||jHJz6YDsr3W#Fg#L1+2f)zJI+
z47|I5AuJXjL}gfVwAw1cP1?>Eyr}U@s4tVjqhGWf{?;-N%Wo$x)TEb=7a_5vv<_6}
zWxP~SAn<wNA5_HE(Vvg5G@*Y3U9jmt*oyxm_x%sXVY5V3<FyxU`@TumY)bOlI5uQo
zc{nX$i^6-(Z<*+c6N=t<9LiPNAL8;VoGU#Ko1LV7Zl&^9LoGbe?HN4e(wxUEc1km;
zcn(^^?%s^H$otaX_<YDbdo7u>cU{==;NVfQr9%Ht&<S0UI!kJ?U){Bxs3x|d#87|S
z^gLh^zVX&wE`-}c2Nbd5Q|oB`>*OJLXG<}6Vl7!@Bz<jKDS#sUn}=`d9ljINS8u~L
z6L9AJ&3HMFRGU}a+L7bR%I$!6%{l$aQLF=k)0$IATP`sE{Jeds978DYm9UnGi|$eP
zvW@K<*3SA;GGhYG@#>1$h9*P(*%S+rO*y4#!%0pn(~`NkA&B(hGHt^bk+u>dhZA{7
zVax#&`p%6LvQ4|EjU$Zbn~a+srm#?79_eL~^WU|+r|0jsVI|;x8wT`568@=LdW*^j
z2l!0HT7FEA$p@z$Mk!hcJHFfLhXPHvzC0a9A`iVszCN14*;Ge!DJYQ_>eX}qg!N`|
z<mOF(ElI~(C>&OD6H7N8MlUpsZ3XyQouA)<)eH^t3{sGf6i4?*5q~T@qJ13P=OG!d
zQ9$HFk<pQN7pb>ll1;#QZ#0-$#`yUtKO(P$eMSZCGtuW_+sa)ZkB?YnI=yMl62vYT
zN{4BOS`5FO$Vzp()o^P}-~5=ZTK<OYA5^>)HJ>f%1DlFFqOBfdc*FUd4duvEr*CX(
zCN9@}u})rqYR%4to2&&Rt-(gny;D`>XBv`@dl4t*hiY=0SsKMb$B~Lb^;n^KL>9fB
z4zPo)v>gP8PT#X>b$DqTOO1#BJA6H6ooJMyq9jQC(@beHZN-Rg&=W!dEgVzl#@fng
zESzLgMtLp|KG-u)b+!#v^phRPF}L`<lbdZvHxtj^005<cLJ6QXCED9w{yeE%a8Bv$
zV4^&$i@Dm+{{Vk^G=_Nc3zA?Euz&4k#2*+O8<1uQN*JfQb#pk#;t8VMV<C`wWIzHI
zlvDH^CbdT9P$emAvIb?xGJX;NFR<(4EsL@HuWlSY0;ZI*A~zH7pWSYk6Lj=;hBacT
zd5jY*u?|QI9Nott$PEEQFW1y&%d)h~#=+q<OBYwv$SO?T0~B|e9(uagreC*xt-7Uo
zpdNGD27X`bOSYs$BHW0^@Zj|A(j|84_|Pn&A#vwVz=yBC*(EW)&MI|Ymt#p7xRvuR
z+)UNNn3|K}_I_JceB$^cui5UYk6qdYXHp%iGY^kPK6R3;^KyPRyj|Ly9@+X0ZOf7M
zRljmx?`HM2ESIbeo7$G$ewxoucP98ow}b519Wa54N^PIk=@^=I?Y_;;Ys<vkAUH#M
z%SPuG-AqJzTH`Ib${ao)pK4nodi$Ay2%enmOt^&&7Y%*J*v_Q!t~uy57j+b#;?=XF
z_^cy5TPB}7v7S5^S4r$!g}%mEG+?=cg|#ePdlbD!<?&=@>j2!>zwqYI$vzDKMuJNd
z_`Qun&YU`=Fa2V|H_b8xnh7l&qbnS}2Srv~;(rSa=G689b#BaqimyfU**NAd27W%O
z)^{)fAAHHFFvQQ~jNHv9b#DZ6)SpwgfoEviW|S_OarWd6$Fn@&iDh;vszr#u6T+LF
zBa?Pq)gbz@7%+g(&dofT%}5P^r<q?QGy--F{ojK#vu9`u2_@In_^p2|;zmZhQf3Hx
zrr#C2vD4o$5lQCsn!NyL=6fT#gY-1)=MABuWa5k4m&H{fXEV49>Ko)DLc@ZD+)))k
zI9?`7tW-N&-w-MIG`RYi{lZGm&|7UrOIH%fIWT~i$;7zZ>gL2d2045)xbo8Gxc-wO
z_iUIV6}3=dEnB93HrhebYJao;S{e)5+qYA0f=(^xBZZc^Zs}T$sgip?POicNw~e=I
zsr+ksCZx%I3?0)$9cnU{mx{?Av{78M_>QJ?fs94x=@+#%BpysP)*#06ey5sgmg+A@
zTF6$NOC%R>nnVb=+ZMP5rLxVpLwj6iURSe4U&2?V&JAohSQB&Rd@1Nx<C(z=46m7r
zt1&P8A@57IW`;bARMWRpRj-BTn?~Zqfbm1;ULNy<J?YDo-*X(Xd71LL`1Pa}oUbw7
z;cM>sRK@2!31wk#D80qfa`5S?&4_c<+`}lYPfLoI%Tb(gz2b8B7xijy^a?V5&K;zd
zz=bUBv_`93v=*JI%|tG@uwJoX?F-yC--YQmr@4}Gs8TsHu85F<56-0V0d){k)A0TQ
zbOqO99tUMCK+jG+_3Fi|?t5T*Gm7S3vILp}Z(e-$z1p>x6Crc~6LN<Dm<Z_Q<Y*$&
z^V`TqJneB%%<k92_x%@6hmpn;K<;ZqF-tLa-COT#VZO`^>$C*#3`ONI82SAB`oLCh
zz@7Vw4sA}4!)r!sJHs`*p(Ca}+C8F3@-d-v^=rZxEN<^dJ6sQk(0sZ9NJxWgJZ$;Y
zI(*jcl1r)~I?4E+m7lxeX$T&mP+a1`0=3m?ivC==09Q`IwG?$#f%Z&95hzG#jSGM-
z>z52PHSZa;lr%QXa)z}9SkrbKh*{MxRT$A7X6an$D1ig4Og4W8&U11QH^?aVL}|Ob
zaieD{h@Dknm+tO-AqMSd=tlv6@N6#kTA}HMk7}FN(_K##3jZDnkG2T^#*M*+K}H2!
z%lf|TtnM2R{<yBLdR;F*Ccm)8bSP*tdN6djsq4JEgBre=GF)C?Qo)U>*vVnL76218
zYOOaeuV;6kHSsRCG*e-AAhbL%cwg{kpepML8Z*ihn<=UkPhD5^n?^8WXi`!f3DYBx
za(C8+#kr{|Z8iB5jR+`35vLPy6SnZ#^3OO71l0+f3@3jX>ju76FZ;3epU}R$kjT<k
z2D(jmo_FNB+__@_FV15@`PY=@qurd*hB6MN`lk0ICv5g9N~<+b4OMh|EDYV}BSQ|B
z-5#C*Ui*@POPiB3{>t(1`P_cXZ@9?(p>}rDOs41+hV45U7%RKOYn)0Ek>)lV8%xcZ
zKSCHs?g*wF@7P02{HKUQz+ZT@kwIL(LKMs{eN9KvA8ZW^5{Y89i)f7+t324z-4uS7
za4t`AeCNkZ@sa8n#wx@7m&6rJzr6-J`XC=ZD9!Zq?4+)l&3*QKe<j&&4q^Wx*lc^z
zo$eX2nwjlG%@MkhiA_P)bd(`Wtay-J24cd>k*$qQR0l>ckIfE|Otu8_XEIl&yk0+i
zGGg|!W0vTEbH0hutrM(Rm-$5F30LoGM*Shx*K8b7Ht1u=TD7u-dnP~9F=`gk(9(sR
z@ifSXTrVU$Hm_Kt<oGV+Jxt}~&$&D!^KV+j03!|*q1|A!huPh88q?B}56zOZ%U$Pi
zr|LygMm;-`(o_m3noDLY{M*=B?nv~3TZNs{`xF1rZNJMoX{c`J!xM&b?|lr9oXg7t
z>T_{5R9c_%z~O)5zboKC>_l;F!dkX%sz4^R<*xLPl(OKofclxa@5{rSzxhzIrmdtW
zhYkhR4vCyWMx2QMGBc%YzfE+*zfE9rt@^1t?8s{{-E!;X`jgA0-0h;?_qa9Flukel
z1!@_&G`FnBpvvf`Fnf(3F;ToA^~CiPPj`$2^@ai~E28t@>C)_3+e3$b7w(Bx*7xd&
z^+yM3BNO@^Nc=543~bRwBK8%Hui1Nsh!hHZ^Y^Hi8rSC7(L(-bGG(QcHXH?|lbO62
zuYK<9@Rb8uMQa^T5a2^0hc4~wQt@`oCm$~tw{or9{K?`6$#e+aeFpn<vvMH|^6iBR
z3*=cAg|TQy`B1~2gC>-4juop93Z2M5rW0A!;bKAv<oF}_d&ZBeku+rOM;YT6j4V)a
zcDPa1lANMN=EU3Tpt*)+l+MAVCLmO~?xYN##eS2*&IPwuOP0>JYgm@#4!e#Pu7viT
zS2yVqWBS+)^zZDkEcA(WH!~!u)@FK#j<Bd?PQ0rwy_BC-ptY|g+J73V*aaaSUQn2n
z?i2x94TC0OYvm&>@DyYbCQ)s-=0Bp66K&uaD_Hq^f5@9lRFJ6joQbr`ySl^sKIecb
zUEl$P19$*Klz43#fx53s{(_1gQ7w10e4!&N?wEY>imDK=ecoIOkL64U!@yT779CjR
zzr?c!C9^IneCEM%E{JX?^&h#HN1Rl33YR*Ejq3QPhi7cs6L52G#4Jq&#uS@1<Yjx;
zk$H)@w8+Nqr%llAW(r!c`0eJ6nij^8iZ-!@GOYQdf52&s+R$Fsg0Ej><AagXCaq@+
z^-*Aaf}Bq$I++<dNu^7gYE7&o`gcvE(0SLscrKd<wd%rJI)++kRKC+W!{vKOg<VLE
z7xdUdvm9xhxzl{g?X1?iW1^nY8dQ$@&;W4dq^&mZq@=Img%<l2gXKmiJOv{-WcrM~
z2zQ%msaa$lZFrw;^dP|`q^}UScRazb72!RNp#zy+SeP_z#Uutl;v~Cd`zl6{Lvx;a
z6cmR{{d^Xq2oLv$55iT1Yt}bhZP`AW(rVirvF}^gO2#P=R@qHGx7Za2K=T#K>YXvJ
z)wJ|Xo_s!7EA-%={ek^;;>B(`Daw&KgePFU3H%zzSTzwQa1uK4t0^hZpfY(y?5QZL
zvLxjX=I5z%RTrNdCxLD9ESqHleYV+4*+3mU0<rLMj93Ly2QU@cXScVsaP7Su|4X73
zhfYW7h<BQvz>5!)Llq7)^AWc2g=|i%f^-K*`WG4HCs@#0m>Z=ayVM8EY4J9sn!1Ag
zjc&h~yA=a=ScyyLHTRm{yyMTy_L)!a6Yy`*&(MS{y0E_emsQJATu$Zq{RuLgEVXtj
z{;08aA5cCf+8~WcOhI6&k&E=U<k1Q<fup_T0X*PAtC0%5v%4zu5$i%@eJn~9Z7^3T
z{@8!Z*3NasJcH?2@G2ZlrG+x{e!z1;e<6^4lkf+HNzZi;#>)qd7ZJpSu;refTI!LD
z_%qC}h&n?1;@51)(cKELj>U&CH{*OC*d=W0kVS~l(YIi^%h_I-Z2&@cWE2~>D{HLH
z*(hOIARLdQ?Q3)nx8`epa${a(pk=37*e+;KF>p&>)X=H%>iBW($F~?gquK4`ZaX*I
zSV-1kZ1ZSMX);7X06!)8<g#WB75)_=BHsO+iViWsXPq{;iGgA1$5AiHEXBb%?JKGK
zKV!3ybDNnl&K${Qm`d}jU8iPlbhlbC3<&twk3$hlo=xHxKi(eg@a@24YA9%0w33uo
zofdN<1;24(sys_@k8pn^>-&JSx_ukB?6D|=<GPkh27c6$?r84;x^8%qDhNxhy+3B5
zDFzC$B6YgFwe*O)U(Lde|Lew~mUDS=*{k%o_aA$z=S-y7qjqBN88#9T`TxSDq^Aap
z?k4pse2aXV!DpNaNiaQ(WdYKL#6urn)=(lu$z_I}kSpvBMs`l#ia(EccP0e4z=tD4
zk;>H1<qkB^<&(w*R*PUY@hlr4kHs+vd~Tt3*R)aC^}4+<6)N{DOYwI9MzkXoMSD(x
zY_wP$_U$bBg9FLE$hjq#>LN6vI#hjKuBdwzw5N@}a40gsAo32D`-7(8tVtQrvC)vJ
zSknG)8v7lDYt)(v@(F7^U{pcV5~y@PJIX`kr!@v$+ca}6Pqm|^G+8_TY7{7Db0Q<B
zog-H}(%%xbZC>Z~=KL$p@w$OG#l<}4psk8cw>b<0#Zh;b#9)c>KTSe>jhG)&{Pi93
z0|nnj;~3#nT5M5Gem?11nz}$N{TsOQzOC+3-4{G<N(_W%vR5@8Yd`v)I0@0h6f2xc
z<Nh~j^QYhMn-V<}mp5)af7(;jH{WF1JUr|fPV%ZgI$*+MFKvT&ttYs;w;S0w#&j#8
zOG1210WC)xAF1J{IO~PRo8j-e(4F3_i1ol_YY9rstZwT<Y}l|k!s2~{3%nNv!CB6y
zN$45P9;Y$)n3{TF0KLFIqN$r5g~x!4HE0GH6o}l-wfiO$%z`4LukU1H#-GmP?^XV?
zp9XuX6B=w=s=O>4MSz9>xp(v5w!r@HyG^0nKCix-_)rwx^Cm-=qoDtuyn=jB(wvOD
zeNFC%Q)4aSE%K>vnfK)0ppEBW-;im{T=n5c;9K>8+xvtG&1Tdb9hu;3Wcyf79IUlS
z_Wajn3Btd=yhP}I4puxobYV{G_FMk9c(@=xl=m2%*<aIG-VDObxvWQ4avZ5VaHa&~
zF+AHP;Q81#jflmG$H8fjQ!p{V=}%Em+j~Px+5d(XaImZD&NTYU@(xP<U0CVF-ivkM
zhQxmHVIii{Tp4v2{Ny<b7tFcs)zEN7k8)r~rw(V^c=FOC3Sj(+>nY?<fSudURqr`&
zDGzF|n!gETv>#HO_y}rH>sp{M8Azj%%xcz4G^aw{P<r$3ia!QnaxB55{U2)<fH7f|
zov3tw9FJE0T<d5n7lS$X#I37Ut$DN_<B=9izk=}vtp>}NXKCJDWrSusuGpP-0N?>G
z{5ZfBk#WKcmw08mHhb^EhgTBqCZpe%n)x>kQEDRb2i4n$LrW`VyKm>|3=sS{6hsxm
zE&Ddaq}bE@f8M4q-C7lQ9A(Xw>#!tKIW9(v4IF}*AMBj1cbu*68B=%&LpRGNjn2B1
zA|!;~tP+p3wO3!~NWc1vIIR6IuIiwM=jLq>IHOkBUFX-&fGP0$1tB&@KV0x!iV#bX
zn_VEYom;KFR}Amy5Nfb_e`+Ox{;h#ycD&$a*BUD-pzi$p_vrtSs(+0Ii2ze_7<|bq
z(}#v8@$o&-jFV=NjJOiUM05f<&DfBKwy}A=j`Y!Q4LUSz`FQ@s<w#NJzXqQ*Xie<a
zXn<m!4RVhsLSy=DNeq$_hDIhIDp~sVlU&=F#TpIDBn_Gg`eWu+g&2$-I4t#-U9&>f
z$X%c2-1}<!=ddDu#M-!$-92?d0`YjzQU3L_(|#KKlyz1N2iV%`THUGF%th(Z@?Yi<
zx*mcBaOasG*J%Z?5=PyX%y-}eoR+@){`D*LS<aLK0~?U7`R+TY!boU5WvxZ>0|1aV
z_|<Kar_1C1&!SKRyFJ0^J&q+!$VSiC8Kj<eHb>l=iOnd&Y$ss~-J9~}V<@W=bC(=K
z?;Dw$?cM20>`YE7<<DW;1<kq|3|Yrx>=6kJIq|?Yol4Oi4lMlW3Neby@Bn7)lJa^G
zsFeUcv|Z|@FJ%85xx0Pv5f?bk@ut4Hx94A60M*R|pablmrYx0`jcuS32vI?IXM{*q
zK0l*n2pw2cTSnBRy9{hMHhN3$1;stlmJ))h^bbBoc~$&rG=I}S@+{b7Cz$bG#QeV{
zamv$nOQ1uM(I}TLztHC7p_jZ%%Ii!mzsa_*=}DsETQ>o5Vsr0SorWXkl3Zkr7&S3U
zYjOTVz}?H{`B}-E%b0dNLEiH_8u<5!qJRPEs`lPL1BK4tR94>S5-`I`owbc{N7@^-
zcl-w?qB}4-XwGuu(A$iNE)}unr{aI*LfaNhB>%>6ysz>+uvmzB`>Fa;jNyEKHAaH&
zeSE2nn1eN4cV5>E1pN3L_2%;9KI4M!Vic|CRtmd<RE1fKAj(xc4VU3E93N)Bi)1XL
zIS{qyfARqf!>WD!eOV~!l5_HRcFOFne>+m(yg|mI%!!Y&f{t&CIBKE7iI<n{499bu
zc978b<ku3=oe93W2cb6G{DD;!ovs{Tp(%liSQ~%xH0b8<c?6-p^6v=+kuk^ZTEguc
z<E2c~kdP)d^|qjBwh1e6W>__PRkbTCN_rXn&3okefDil4qG6}Jsya4{MStV-Cf<$(
z^}=j~I~e#$)Nq!nflAhy`o|I`0s8^2jSqr9y!C#_>t-gW_-jb>V}rWe*adPTuC+mT
zzWLa#7V6odR<H^3Yq#(NB#G38h?RwB#X2Ylesr(lY->+c&<c{I(V<4-jt;!e1zz&H
z<#fzBTg-lI^E@tiD3Sst<7#a+iWlOBXWh$$Q|1f}_c$mG=5bu>`~}|{<NY7~c*t@k
zpO}i0+`L*B_*ZWEp=^CttglIi;`|@DvsZkY+WoxL-7!85jwUE1#G9=@`EgJe4l<UC
z6EmUq)Gag+36fp=WDW5B58j<y!P#q@`{^jX_ap$Haq-CC^hLNuo|sK>wt4)>Qls+2
z2djOc1Yf&P<!GAnGU4Lo_*w$~dua_XX9GyPKTotEiNC+uE~?*f#`Y2vCPE8MBLy7R
z$kwdn_|105q$xfouK5)h{lJ`%%VDXd2W{W&#HY>YvLN|7-yIUv9Qlt|31Ujf-A|EI
zT6)MsR%7M8{s;NZ(AxO_j%X(wo4U%)_R1@qEXuk(_CJKXP)Ab+lBII#w*wI7<r!+N
zHcP#gEOd9WL8x3Xtg}hi3H-~wL-@cM-<|DAFHw+~fDx|3RL6aX@rSfy?M1VMGym(z
zfU}4#cDv8#6pWulRl>wY<=W25L)|@RL=~j+0H|1L^m)Zvl@9mNAgt_uKi!22Fa|4k
zIF-tS3*C-oy87RFYM(Vm9X-={3a6WEd1kNG3HFL(V2uEGp)?!suf>?4udC)k+ei7$
zQ1qdK<sXDJ{nq#OyBC}(RLY<JF$})`wZNAnIHo{sglIQiPS0<?ny9ef*|G8S5<DCx
z?vNuGFt6|hy}0BY0<egM3b-pzB+`sBlcuTkM12ke(9!e-+PyMauYpJMh*7MdqZ9m2
z5iffbXr0Qw|8D}EzbAnF+bJGx2ZJ|k`-jb)^Zp=)Rn<KIYwfG<mv_62!~;VacM0aL
z(8EhUy^C9?Ei5gS#`=<*`+u?a7Ep0LOTXw4G-x2f-GjSpf=h7s5G=U6C%6T72+rU(
zxD(vnEx227nKzLC`Of+7ci+0}y>-{x!(#T{Emd7rUHz-B9-@R7e<Jha`m-ks;le|Y
z&4akUJ~8~s+Y2=CDO%gpWqF74%S+PFigmKu2HunR8Hm3B^YEuY$P4@=a3Kt7B6s&m
zm-b@WWwo;TUd8Kr*+uBKUp@)`IRGereHhLM#=DH|C8dIVS8{|%bej)2!*oeVl|b|P
z4M<)U6WEJZ;yCtK^h++dBcjU@+wn9Sg&X+kF_p{a>6{6CE+KS>?yC>JoBj6fTO0Vk
z4Sc(kIg1_K_Rw~g3jQrl7ZK%Hc!08EUd`)u4gMYGGqcR>+Vd=3lEVd8!@%dBpRRY^
zU!P3w{h8JGdGyh}trohk7P^fUx@~H^Z#u6AF}Xe6`>4!HZjcl1yML=&D3L4AxTpL4
zP^@oD3K=r=<ysFnVE7g8_4)jt=bk|7tXn*ik&%g^cswHppXonN>#Js#TCFqT$^BVz
z-E8uK*Yr2|h5g8pYILTHr>_Bs{rCoj=@x12@m_zu2?=oX8|t)sIwA4L#T!x2Gh#h~
z^PQW{z>}Dp-`6TGf0ii~eqmp=DF})!pT?X#5$MmwUq_O)R;(^v@{Bovu8U`%Sp8OO
zHkx2;r-3I=%S~-hi$V|JCkF4yGp29gDyney*1_LMZw<ayxx{yDr99^r-iac*SUvON
zuzJ+{vRFSp>}K_@bd?ncx$RQB?Q*g0aWT{9$*of3p<mwnyc=78_aQX%a1ngvv-ot-
z79Robuz4D8%Xs{@`qTo(13W#Af=9tUVDQ7y$y0CJ1sC|-$JKAOmdoe$kEcnYC;h7@
ztn<|;_0cEtL7%5p=$m^XFfsT#!smXr?IC>?^J%*+>0aLZUjG5z_cpr0=Mo<L0KQQ}
z^}P28<-6P3%6uw!;B$L`h%eX_5uL8Z$lK_6XY{GMvBk&bwg7xFq4$)i{{YE+0jGoi
zxX*&OhlLRHjMj!pTW<(GudgqncAj>3mwmWc>nd)l!FyZ!_-C`=t%d5<2k^WHxUgsB
zV&$4I_H*X1LnE>M#)JtA8Ub`&!sXicQi`$JcW{)1(T+73IYemYY-6#0_|PGr?R_bH
zm48Y3vir{=bNqmbRwXG7KAGme?mNb%Le-KJ-3X0WOS>~)__?Vu5Run}0gT|PY{Be$
z6!~bG+fr8x!v=kGTcTNAv)ZzH?X|Kqdv9hz{%8Z<D<`^@3zd++c$=Bd#&73#ik9hx
z)m|KOa(mb7eR@&Xc0a3U8-Dc&|9GEgLXF^00=WjZM4te$$n!`<o~Io`;0qz2%W3sY
zx9#NXHt-|yO*?#s*VVkbzSm_A@uQi8gF^>N_m^#LUhzz031V=?^%=I1Ah?e`(duCz
zy8wKwTZZON3~q8kc^ckufb|k<0whJYtTx_ovvIRI9?e^BkWcCqxjc2P^!hxF4Hf9h
zo8o6~oWfkJ!M8-oeEM^<d5*@^P!bjecKV&(9TVp47P*+(;^K3~B+m$b5Nevv(f8Oq
zXtv!)D<2XB*Ix4zBOV<dJ~01j*;#!eQgxaZI=|VUInl-@2CwIhOB5u!I6IeQp1eB!
zd966@mEyDXcEci8|Mu$f8}T2(r^CmxUg|bRwx(v-*Dt&Xo>Zt$q(6W<<<GQ1_eL6?
zuQp{%4nN;#&hw6PDjiHY_g?Ard9cVF;S{`GLdtYGRV(osIoppN6)ew1@|CZd(bn{A
z)VuG@Fe3&pkVj3~shMoBC1gI>>g#!SDw-NoQr}%&gpAHvl+vfwHX8cn84V6wFK0d`
z@4U^d!YfOellMM~_6MGT$KYpMFOYptJg+@`{`jGp$ny|7sbOVSr)GEw!nXGTgaweq
zneQh@TTXdQ)8o5M2|%k)z1T+o9@BT;#o<Hq4?uqlRHF0SgcXV2`yDRtqx}dW&kOsD
z0>K*P#n-;jf~!v`aL8yBH!hgSlnb!!Ue||*hnrLBNA{~ipS+F+M=kAacF+cFSG7lt
z^~2<TL0>OBSeu&ewAN+N=>^AGc2{2rJ7=s41U=x)1Myd{J)#(+91ok%(MAQpz?ta7
z%M;gwhV=Awj}xBWFdz$)tsbXbeRlS|3|{cF=pp!Xp9OgISLtnAUX5QJI-K5@4lOp^
z@D>-366N{41EhL*K4fpt+>4w0{F;5VBALJ66M7u*8C6@~7kXSEFPs7JvkK89easF+
z$n@IOUKo8UozDFn{m?6Pt6V7~N^R)M*k6Gs_(<NZEBd*evctUH#+S$TqE)S{wXc<~
z!S1n}3%u?2={SLR^zr-WlZ^)McIl}8^Sw;wqWhaa@<vSL|ES1zjlc#Y_(HbH1EI-t
zEmlNE|88H-(t9WGQaxMw0(@C6c&`6^iV2bTpS<?nlV-f#Nmm~Pui7)N6R<%%m}#X6
z-?jJ7c9V&S>5Xtrn8M-10k+Qtxfd^(_^70_4x!Km<H?^+j9Ll2{kUGxT5+LdumQeX
zG_(qKMo-thUnCBOG0{UDMTN*-cj7V_>R>3b&Au&<#mD>t*tYCOQ?d6Lb5(b;YB6=v
z>?&;X=pk6Oe*Z8c<A-vxb9r(bJaqUcobSUMm=AA68`2i^<%XZel%VGEk6@R<gF#Ol
ziK=hapMLjq6+A7DY7Q?x9n$I7gI5kYno4uf1X>@QkJ}#8roDFA-p==21qof<q8}}`
zIc>nIU98LN)8KrnK{{pZFm9O5Jbc&{$xM0TxZ25=*L9mMz9b~R9@PW?IF%j`c`Dgi
z9|d=JE@o=5dHyD4*6BFJs0tZ+G8G^OFPXNDoQAk~o7dm4E`pytGH>BpJ=a@q6Hb=z
z$J?If)V&e9sM~HTEjQo=`6eKzz8ns;4uN~Sz_(%FrftA85!f{mnRZ^HCeFAUO0pOb
zGGRUh+vopOkuI3*)m(xIpb;x@+I)-Y{xnEv=;Gn{xa>4K>2O`(dTHb0Hniyh<_7Fq
z=nL*6Faxthv7=!+{1kZo&}N7&<8&(+bX`SO4u(gAyJ3L)y4K6TGEBft$1&b^y5_fP
zd<u<v!st$tS06TYD74)H)u!z^f8_$+I(c$l^Emk<aCN3bXj5HUR`!HORAQh(bc0RQ
z=Ap1%f_L)8mPvYuQJO4z%#1zTrtz<!>8Tg06us52r^X103E;EC5xk_%TvVFnKMxS{
z8eM@tj)=%?vD*l9G1xD$1KR#I;M^zy_hC$}h2v&@33X9Ezt7s3Z}edq!0qeTCw;3a
zRI&YaEk{-=^>1I;@(%lWN0LSq>V)3?Y3F(m-|%n4$D9R69!nu_Kdo~){pH^qkF*L?
zjFB`RhhqXSX<Ku*$<!55>Azb0W@{6(!yI&1AoRGWy?Qsp)p{0T)TZ1;SKb^WOXah{
z<^ApWpZ3xMJ0FLV*^s+b)YZY8)IzsgOg>Uqd>l&-qXKOZS73x08Tev)5k59!2x_j<
z#!@n|J?f3poOQC9o`e5(`VBV+<U#pq;nY70sYgAAZSv1E7|i1r${=H|urBv3<B;oL
z<U;-r_$&DT?dJck$bZ!H|E);5=?%jv>8Un6z6hXQqCG%T1kx6Dx<l?Of0E!>z3N`i
z7D0X95ul@GBS@^kng9w1(3J>(ACzLceDJ!={alLeYbb=Th%OL5{4T2majx#Da)p25
zt&!#KaH$tBue{Kb!S=mmUlJVQu2m?Y5<rLfkmkCpi2Gdq@Pu^x{G>f7u(D#e=yRF?
zgR+d@!@PS?7ceNE@}D;&AsqN6^$lrTuL28@W!5;EJDO?9JToLQc`Fj8$TS@dY5iws
zI^=JC#2>vYV|`h{uTVdrYUpEyicO-?b?CX3=l=5@?gVNyPL(qq|IeU#=nNUa^Z@U(
z%>3nf9m-$_{0s-213f`uC3kgDrLFK6W|}?7zQliqXNd<dWszTbnLOoP4#!!@>BN+|
z$PR}R5@g(7hUM2;_H@z7r%_!yH`O$z;eGZ}hf=kpm42-WGzb~M^`U3&<xZE2Rf34F
z9Dz3fgfC(t`U8jgkDT5w&$no4<3nGV`7*({1@Jur-o6M0gl&Mrf3$`Kfp+Qdoc}M{
zpGEuMPyY_bi)8-$=Krq9f7J6|js8bH|38ZOBVNZMV8dY3-%ru#alG{W*Fh><Q&Ust
zh9j>R>i{2(#$aVMD=ec@C4UPxBOs~St=hHlTfw^+05LooGcpe0&sK&&0~}^NVf{(~
zCPTzCX$ZgHWh(&@wMNo^8UNvI$dx0^Okvv8{xc$|TFIYU7>{RO-5iYp#Lw}I*ItLI
zN1mE4oa~rbXivF^+BQS!0KlPGqVReh;NV!nzOqyb|7#>9ZOM?XTh7bW&Jh_A0%5<r
zQd-LaK=%MD;F&`G<X_R_ba}%jpY%xpPz^c?+IQOzm&LZftZf)f8HBI-Lpr#<bY!%y
zpflFi*c#H}F>!yr>}H$QqUXW(${?a4b?gD_hC<_;MSpagu;Kf@GRE249^2kucbtHB
zfXZh+!ut3$LS)%LryN(&6OFVPDq~7U!AB8Bmd2DTiOw8XqcoVpkvR1?8Lqbp6gXJn
zcJevsJopghc@ahLSv%d#cUC)Y-aq@hi;Bdz?`*;&VaW^tsSN`YLa#a1`}6#}TIVm#
zF!s&a=bbo?-um(`DwY=Q<9<yizM|mS9m38zkk`Z?Sq#drCiFV4G$1jr;Q(FXz@_L|
za@_T%sxQ-JanG68aHF{IaQN<7*&Bx~9183`4BJPV2BzvDGkag~wx0v%gsYK+E%Z}?
z<FDKKc+s_@cy+%BCL;N6ZGQr0{m_cl(#<Hv4|{vC=sPgxHmp}(YJ&dhvlC?;Dy(T;
zNi3qHDmPF=X5|e*)U<-7L$;MO$HH8>B!K6J!N$e(J)%f#aWN7gvytUcdm)%2OSxlS
zt=K9JhMCP>WI+7r@n2>#;GU)3Kbv}46A2LbnG-6P?YOmax*pEJZ}-kU-_)E+doi!G
zm9FgY)7r&cWO>=I-Z`3T2a3f?+Vph^?Ab}Up96+2dip-JMD@nRzX4cl&3<Nh6`b7m
z)s|m=x@@WS004{QzSO+M$>o*KR@s~$Lhcu9y|3uM1#f#&xzSZ(PR}Hftw&fYw$>62
zVI4o&vcGo3`*a&5o*NjWl@2+wi`VzAHUnMaxC4_8$+V59BlQwFZnx-WKK>Jrh;2`J
z8_HbS#QS%`jpp(<aE$_rDzna4E}8&}kF9iX@o`n48;2b|oeUi`50q00+`r;0y8fLy
z0`4n+-bh{h!w<|R<#Wm>hIYr8GBohk;xrq>16;8l7k!U^8^|<qypb-6`sDVCwwi60
z4*EMsslaU7w69nM&GfC~of`eSsZ{(g>k4?npbnD}q4tP+V0A&SVz+_wKwFC-s0IV4
z(z&5bzA=SS`0xu<b$?B(JDojUb}0+&tcWlO0=eU&0@fNd?C}-$%%|>EOQ#f+ir-?i
z#>0#m@||j+B259-(D(s4Ml~^kb8y)JUtS5HhF1g>PF>3aP04=8zkj)wZC=ygu?dUl
zd$dSlA{5M0=kx3NwDo^xvyfT%$IV8(ZtBk;Vmk)-W_75A5do0X6Gl{X*&43aObFTy
zit_>kri)NCdyt6Gi1#a#uUjv3JJu0gd(_m`7l$JbET90FoK2@DXOeBpxo`k4Q<3XC
zmG>!d2J`siN`E#R8b+F18!=u7l{)X3xQaNmwyr4oc(JuplAXCC3zq`rTwA6T?u#w>
zDtJlfB?d2Spb=O05mt93_lo#MR9MDREK(1G@IYILBou!%Rz*o7iuNl*ia9(QQCFm2
zNy^IJLJ4|ka-;ex8j!!(V~E8)p;8*HKS}Jn(*bICv9fNJG!*_~+q-TnshGD$ab5CT
zGvTXmzvBfowXC;ydu-r<=zU`_ZA$wQNH8MKfu&}6*o2qcT9ZyB1gO*-XO_n0Mz{CH
z%7asd)9svz3x?Ai@T>clv{S0+&EcdtaJ+B}p)hY)Z{DHp7O~oW89;M7p7Bwutg{sa
zC;qy1!KSnlefBvZuEzcHug-*e-)IKY+bOJ^GAMu`Ohu;+3A%I1=d9wo-q~`A2jy}0
zB1flNJTCSAe6sKb1Yeo&*Kmm<<t9Zcf!b$g-0uJeK(=J_DPP(eB3TDqfRjmV%obfk
zP6>~V^okbRJ%7TL-G_kTrWD2m4!qHB95poGMZ^SSgsoQyl?`QQdqxID9s?X4H41gt
z!!gtCwH99yEZ5nX|J6r3MDG5!w3NsAVSk^{0ZlgFwcj}PpkE88?cE<-g0#2qOoE_&
zJ!k>#CQP1Jizh_F15t54PR`syH?85(xVbZkjY+Z~zyqD&&jpnnV}MBMS2j;NjF4<C
zYA1MI$M<ggM+|^`HBO9H)Z7QG5>1Q?ypwqQ9t9|b5mYiKXqJ<Q@As$(V>XJ{a}lb6
zVSW_;Y>ZjcIBkRe97z6HR7Rg`-~A)Azu(ywJ#k|Wc>DIRENtT<M+#tG3vgh;*ZMWy
z$t53@QXPHI=ge4wDI%!tY%54x9xLONC%tw_Rz(@9eZYqyam%}Jgqtm}(F)KVa@vk)
zzr1u6SGVZL+5;st9;8A6Kqlkx*OWmq1)xe3j<Lj*B(vlQJd=VVU-lm`fcUbnqWuVg
zaHj0ce6=ZmO679>a!24wR-m9Xe)?2clrS*gsW?JT#7j-nEJi649W4)MnJ4xrvN0zH
zDjNP<O0hui&*)M?tPH5toc#68>u1Z-;)<m+JgN8T?t762zV5p20<U$`OK;G_w=Le%
zSquICtWs>TsIA4&0ME1U-ot6azlWSTgM%o>l3Mk4TGO&YsddJa5Cj;yoH3LN4J=Zv
zSkbxV<67a~=UP68%kF1x7s)GT)jE_@E{;~rF3up5U@GYUu5RNORN28X#l6sBJVDS7
zjV%4>Rly4NtDtrt*XLqvJ9Jh6lPJ@HduYLS^}HwMM2*#-)+xTBWBiMv*<WIUmD`h-
zmvz_ec+&-+KEm_#E6?wgR%0V%wlG@Hznb9JXm39hTGw^Ng=dUIEZ292Wfk5@>is;D
zcvEk?{>m4Ez4rK0pkck4$>x8v-T{pV=N>|dGk-Xm=MVo8Ui*8@JLEhgCs-p&7_<bx
zNS;&jVoHe(-}h)l%*+bVpNR;VfIEmVzBSA=B%M&c$;0zzNRkc)I5=1E(bedG{iD}n
zc}nS!rAB0QaJTs4LRHkH3T{e9+5yH2<p}n1Zs8Y;e-WZwpGltA*Z!?VRW%6Nw)L}7
zZZz%3s(-3k_CKy4#125XXkSq#gVm`YLt5J&mQtFk1pTX>0HSyv={TYFPk%N3O%VOk
zo?`MqR?M^e{Om!0Nu$L4=h=U(DE<#Clk&yRbfkn?xiqtCB6;l#?KKf2!rybal4ig~
zBM{#qGIifIgovPdc=@0&OOc-5@SQ;<a;EDeu#{k^mQRf1axIBo67Rau?Nj*51!$^?
zo_;U>*ldZ?wL{U-@_f{|6t-3LC1^vAjY7!EvsO-8THkGI>d;Hzh_XcE{jL?)XX{D0
zVZDj<S+EUy-GTa#Fii?%#!#X>1Y6j@MuW1H{$o#1JbaQmf?VJK^|<+p(`K<-Le8ZC
z{?Va!Yi~A6GoV8Z${v|*C_m|+>KFNWX84N)cA3o;$+{|?!kc2Wzu!Kfejg<qgU&O9
z7;w4xAK*H-Q-vE&TpfhD0WJ-N(+;&)o(P@@l9KYOjwsk#Q9T{79lfYS-9ha(gr3Uy
z11+Gfj{!;{&8w<pvWT8IItZRPYoS!MI_0~i(9!c-O&8H0fmgF2#&b<lY?zyt0#U;?
zG&$-#0lV}~p`YRLtv)2>ygblS3_4o04beQd9q(<Y-_#PFa_K3lvtnR5_7jITsx|0Q
z8<V@`N!{#w+p1!a98ktNNGeO4=NpiEzV=ZgA`h}-Q-sA*?&P9SRg8l}a>S=$gUNlH
zSdV-zCHuKnB?C87z2~i>cfiw-A6ginNS2|@@wW-o5?gs1d2c<t3gV#QI_Ato1Y$Am
zz?xc2bER9(qMD|d^NlwRiS;OH&H8c-H!TytGnuwJ*}|0Z$5lYl5xhYQnmN$IHnA4x
z+rt8Af6C>C;NS8BOstk>HjE-h$e1u2@~^A78X{H(1&fExPbQ!}hh`5h@;1_>d-Jum
z9rt_CeW92=-70(v-DX-c){3Yz*`Yl<h1M>5a?-?mDbh=MOTG9#^2k0LKCMmtcGpS&
zT|6~ZJDkLN9p%dbh11GDCp1;V-Gu&06@Sj`V8tB??njDlBVXnzng`Y-fxhv0kJY!M
z@D)ZK^@qIuBK;M-v+zpyixq-sKe`-|RnG;lueN5J*)GoHDN4ZPBa;H@6CC&?!y_pv
zkP9v0R?+Z&O-q3uZDKH@o3MitT#R;ooC>A5+^_m^YvL<G#dOb!m|`_<lbU|YB03H_
znyj%e0YPGApeXxtd{^Nmaf>YH{D18QIG2t+pKi9qgb5BO2hNM6C@HaZBdt5h(cpj5
zWn>aZ9n#KE#iUUnkXn787wRABAL?$EZ=-gE<FF7P=qvjhW4PU3O15$}Ar?1Mw}-Fr
zVc?M`+J8rSbu3mM3ORED&&)Z3ez<A@50I01zp!0qF&%pK0T&+Y$YXbkHuH7V^0s!`
zC}pR_UIJ;>(K$QN6JK>gSL)WTZ%Jm1&_xV+^dj7%qm{p9ocXsi6P8Z}$9{@twSF~&
zEEm0O`FuHwe0LZ;dP`3Oe{#!~{-QN}1q2E>Qtbk*X=Iq_AQ8&Ql5uAqwPpk^_U`py
z9S%+cFgm&;-MpK8AeBZ$Z$-LM__wltx0CRkc|Ez5_Qh?1xpK{fw<V`RzG<e8rJ_Dv
z*G9Br1v*5}-5GdX3A$~?$J+q$ES~>Kd0Z&uQ>rM-w~?i`u<E!J_D&cRXZ~6P)U-4j
z<BFHPW|~VVP<@N!<?Uo?)vDpas?_Ztwk*iOR%@W25qZso9K0tg-p6kb7o$-hu0knc
za=Gw;7mx`q)Rf$l7VrENf|i1$BNJ?29$OXNJdx|k!K4ifMYbUs#GV&!5{gasCCC2D
zW_z=7qo&`hydQrel#1SfJ%#MP)OgUWcn*IqS0sAH8Y06EJxIyY?On{wMlc#)=O+48
zqFN1Qrc{aGYkM<8^(Msf)tX^6pnUvTOs?Ncp~p|`o=A|$IQtOCy0!b(vs%_vxk@{}
zSZZsrFy>f#AWCFg4`S`<I%lRA3gH1clS@@q3{|OAZ1VFOflz>AUE<11y5^oCqWa#p
z8VuX3a2^XBKmwll;w0-9E<v56@#qX6L4-%$kV&GNl>oUe6_)RGUxmOCQKm=VZ<Y7q
zU#eF74qF0D6=zNMtdslNm}*@>edX#V5Y|`I`6Xn8h%*2*P^IJb)hAZoY3y4#Zp*>W
za1une9v(E-&N!1pw-0<=oM+`*<gz}Z9m@z;A+l+o=h+@3_ZV25aUKMbRxy4hjmMGn
zT(4@R<*5q51i$NJ%%XF9o%g0OVTk4y6ucm*mmAZnrRm$pJ@HwVCI@#sU@ouwJ(oCY
zQY!%$o6Jp=eOzJo+GO*12fpPf$c{~04WW<wn;Be!ydmPF+E)|q1l$vZ$J^%qcPj{5
zm-)8bDy79pHs6QUB+S@cS5yi-iQ_cw`&%&wZPec!_8MInU+2e0Nd%mc<sI2`{Fn6K
zJWK!eghs^vQu^x<SLNy2fF(j8KB1&5E`_XY!0h+zJ-A74sA+?e*AkQWqo+8Ropgjf
zqECx9hdrY2G1LX4L!h9Eg8k6Gq3zAvir-ZHP^4?qOP<eb49fXhO-d~UjgU7`K4?-p
zFInMfPItX-o>r%6Zr=epH^jz6+=@GcQKsm$)Tk>%1@K)Oi;O&%6*`1oM^7D50?Un!
zCac)Km&TbPS^3-|x+*$cQrZ*b4~VwQ?MhM-XUj&4M$cKo`2ajs*)_rZDT?WDiqYKV
zbs;|M+Lp|q&WUUKX1F~sCg}-*t?O*aRbqFP%Hh%77FyVd&9HKwEE>T#VlA-WQmqwj
zfWE<KHFQfI<FMEKf+3{SHG1NTR3Ph>x{$eQVzezn;|8Nt|1LhRT_ocSr9g3G&8i}P
z)#V(H*B97XBLKr7f)M;WYcYSeK0pp(>%$`z(cB2c<RIu!u%4h=lZ~+O>#Lpy@l$Sy
zJ<AuaFhf@FL*tZi=`<1I4MSvch-9CF%_y3a0)uS6EU*>|WB{{nh8Un?^z+;)&vw%=
z*HQJDySt3iLE4)^i8BUWD!M#@n1nUb5l4BzOx%%_)vyAyVRe1E<ki4}fJc+SczC{0
z3xZ=jU1~U6u!Wdl2#Z7-Zsg}4zK=e&Qz>xyzt`TTo;fxRFC5`QXChdMO7MOfxc-n#
z$yWEto3g{ZnRB(vs+<z!B`IInJ{_eots<(t?rq9krLkKS0-Cj?XskbqTXb?W%c}IZ
z@TJX=VYWObq#mX8H4ot_PDk1>m>c+hhKdFsF5<+fEPxaU1#Mjo1g2rij4*z}tbeBg
zdJuDN8s;0bw5z!@$v=D?ymvWAEu@51iKkJ;ym^NM60VGY4O|l5+AlhcrgY4+B`714
zPt*>piJ%Zu!g?2PCN&U^YC2HG=KG3eATl}!Ns6XE)Wbwez&Xd=w*G$Mdlb+vj#9f}
zL_rRN&(nlE1NWrwVZP9`u9%&)txoz2bCF^m%XjsbJ=zFGpFc8!_O~+P^OXypQH%+B
zHC}x~&V{n}Q$<wAZ%p;0!nVngZ}8yc1PH{b-i)d^NAws(20-6-X>k8!NfM==O5-}n
zF2=(00COW%=XsKinz)xtkCjQ};HhCX+Pe9?BI9a;q5Z~#r8#==yS*;zwao+0bY0Q~
z>B-c7?Ks&S8-#8Q1>7NHsl16~m}+vob9Jg*d+7M$VnlJQY1I(BtNj?!+!+16SpBfL
zh)q!?3~tP?&*bNvBC-lgvBWj%1NBwu$tfs(UR@}(MsKAkuNoVUqJ2U}zWbp;Ctu5&
z{=w~EOfY+#H(<SefQmii2gIH=&tfwt4d8!RkBQQGnox93<6O;I(1S4GWz=mli(b<%
z*^oy$jY9Bo$z?zt)&+_>KHflm{zAK$$qy~)v9YD?<nwcFwl)8UnW2fex~zsz4@4ps
zsl7*A<WYXwBAwXDdr8E4ij2rAPD}gD^&GhmA^2$WZf+`jH%aPygs6M-c@-e1vLSc$
z3o;Pa1zPx3D0qbknw|SlIpY$p*N@3h>l~(P@~rYUUbDP3uljjno93!3m1Q8?hOO(7
zSh~oF82GMY{nOq_wWBY)F$T9lOP%;C(qCJ|()+6k=#^07GuMnnl{SkpVT0qy3B}hj
zjeKJa-#fO&v=zNK#e+;|fxOK&o3lu3MVh6@X*frzu-IxuuR_zZvMHQzhHUxSR>tof
z(i^PFTdi1=0ZFp?5jW214P_<h?-+0UHY$zc2+N1BgKO1ktkkomj9;cMcH5eUL~abZ
zyBt<fo|bvo;(SK5b)9|_PT{K<UW<Z3HU6?G4(y<w#vp-djm)Qf(Eo(fOAB#OtDWl|
zjzbp<q;J`fQ^!C~SK9GNlbozmM^^{ikGO%KaMJ|Hv1YIjcdwZE_u}-*vmq9@E(O%p
zA42DqVJ=88tF;JkrL?gaZV9kuC#dhr-A}9keO0Vf{55bIq<2tf76zgwSM~TZ%v`2x
zcU!EyUbCPwJK4a)uhm=@^O2TI;YmSF-5)rJqbaA(x>0j=jTX*`_wZx|$|`e!$vKYM
zpu6V9#qSTMI4ZusP{Sfoid2d2w2(0ur`rAX3o?sU&?Gp&YfM(~`*8!u+uf>27Yi3q
z9#pd6cNCKRS$;NG@iW4EJGk|%^M4qfVOuD2&o<<gk2!@mnhL-fP4(4sNC%d9DV)Vv
zM7<}nz=XSpC~4lu{6hwjkBgXQO6#0OxlI@-1S{$x<U9WgJ7kjVebZT2=fJGlL_=Em
zA{+w`AcQXcwWc&H>U!$mhPe7W8cszRg`8T$TNrMPMIp!YGdD9bGO`8<tf*TOZvUk;
zLxF+w?eS-#hY!He-ZmB?e$2HDEKjT303>YdmFDF1NZ4?AFj;}HhZ1jp<^=N?G%2bH
z@I?GQWiAGENMlf;%E!1=J!uHfHW%Cqai*9N&Y0OKd(@Ae&Yw;9lseLODZOxRoN`&G
zSiHj0drZe}!#I3$)~^y-sau$R1)XSrZZq|8Fx16pR^MZZxPIv9=6{1FnjG^+;Wu)p
zNPyH~A#0c2pli2?>fxxShw<zPfv4__V4+bz>+1sg+khj=Z;v;YtxBZI^9iIWjI^gP
zl#7L(FCNt$t(~L_?KF^fDWvH&_9mHMWQVYB=1$R?M|bri4p1Vb>=>(eP`p=^r*}vk
z;F)91K1YZ}4*SNKf8aX=J@ZI#$bFa1O4NE7^=-O#*co$M|E^iK0a6H*oA$+q9Ov#H
z1z8O3@7sqWE=wVZug?s8AN56+z6mlZmlZd4S5}R)D2~`cU;*4HR?-h|{uCm=00fZG
zPhaOFJx##hRXRze(7&MXf1*zRL<Rm2@xwNvb$@DYId3G--FkX(?)%soryy*~G&=BI
zjk`=Y0c*lZqtFu7x0uZ4jEjsoWJKfGP$0SfLdccU_=9W!pW-$gmZIm^SAQ3;k}Axq
zC&rmK&Amfj9;rHpQvLUHn6vG9-8qC;N#SbF`{+*_BEraPbS|79?w56Dt-?y6Gkls_
z)S1=wlBtD@jVZFbu#bWwwwj2VCH52xSnncZ+X&4a_~BUJpCKkE@tz;LWVfiW3n{P5
z#q|#PYD>k)z)E<jHwH0{UhC-*w6Y(xOhlgwA=?@cZ)s$_ORu}0II~~<RM~SZhjzDP
zIXEf7cgTWUy3{=HF`o$L@^rI%8kn2$<hm&xNc%L`>V`)yvwK^Izpj%?Em1sxF+Og4
zqtSZM;qjfwi8kj%<96{gXYU3{*Y>*MeqZ(KKTNo1apNK$XffS7&m^F14{8s(I##_P
zt4nSmX+ODKeue$2R`mGoAsQJ+xymYoZPvHCMv;SY?s}4&q#<)dt|c$MPr0TI-qs71
z{8oBNNOcVQnp1&Z$DL=lKV&aWJ}5Y@ASg4`7YQp)T+7rSM(82L=}3pi6p$3bqv|jt
z>TrB7MM%K;^y^Q+K7Gx{$hb9VlrsLNo$n!sZi;@&uVF-xn|BWfrdkuN2?k?teNd1l
z_bVG{9PcE05vehWq<K=!n(T=aCdAK-x5Q^!X=Y_aEh^Q}7zg}+lBvffG9QF`YW%7f
zUa=D0j*(Z+W+dJ33DAm{Gu+bpu*CH)T)#ww2Amjb42&PpruHdXQ-Im)!{DkBCE|X+
z14WnUXbDtt+Z=a6<P;RkD5uC7u;e0RBn9!%E?UgUh)OpAbLh+8V=DiiFF$;s2YpDa
zbRaa}NO1H{j?kVNL#$rv-&~S<=YDf;09Lpt@et@xl^6WFUH4G@_M+oEs;?$~-6gkM
zx<gGr$8X#(m)mKV82_x$-S?l1O#VI;XIHf{$SD;$DjAP%`XzLzDeK@FFNR--Qp@J<
zvEH0$bccG=eD=OzoJGpCSk8hNK51oeWs}pL>Ar-sxJ8Bul-3a<3?6WbP3f<jV>m?7
z1wSaco;-38UtHdK?r|4PRPN1Sr8nBa7=)fo$*nZM{%N46W-*Tx@lmW&+|&+`HzSTM
zFwR}TS{xhc-D_KJ`mmRp_v;5={3+T^^WJ-PE46|nfy;mp(w+$C`-*GQ+09t2<Z(n<
zeVnLu+><GHioA)c#bMO=6_$*n?%szEVE1J`Z?`%y*(#OA_?Q^VLdnb}cgEz-WIB?i
zz)Qa$mY3Mo;J<?t2F_yULN`R=0<J^ZS<{ZUhD+YIN?FKCBWg<{0j5|5oY_Ega(t(R
z^L4}PAC0n{yrS%BT*iNa4~z)4Yf8IPEc*SQA9K?slsW~}Wjh@5Y<Bw#0D<yWDC|w*
z2_~9WD8A!^URDmXp#6_qgCrXmV%GH8)9-@Dsb+&s{ijpyj|q{`>KX#eR#mFEG(Svn
zDG`vzQ%slSqUJs5(<X$e7yaVprCM0{0u6m~m>*ZUNiH+hZ+tH7m)7aj&t2<S)XeZA
zLX;Vqy7jU*eXh}QGLlx2(pPxNFnK0)QiP!`9~EUWjoL!bt8d_RpGH*Ydl+b{W!n?j
zYy9aYT$WDg55CrWrCD1-U<DL|DUNEBHWTe6YmFqmYJL2S&|*!B7mT1)#*93PePN3J
z1zQ-de?}yt1JUdFuE#VWD8Wf!kE_*4Eq{wi8|OZjTNu+c7rM@2(oWqyHsnPd&Eq5q
zvR&vkos1!GXXQofL`}J>g`YC+NGqQ>_mj`E(u%E0hh03TZ5g-|3UFsX_F}{$j0}2q
zsxqJSfu1ZqDzkrCgGU`b+D&HXIA{5q8>2r+u^7qyFSx|JPXqfPH^1skhyHLigS%IE
zOJ|N?e=j#Jj@q%E*`67DI6SBS0hd_kIm<8M9O;E}={w9>gbH~L5?lXI7(}mOL8kLO
zL^fXf&)fD-EIA^bxBv*kqe;A?u+|kY@T0Y4sSlFDxQ9QfG)|j0?JxEklWd0{17mx<
zXdb{0)PND@_Oy5#EXoOGTPf)~Yc_4EN!&J2FY1RMX0AHSswkps=4GYNaA0wEfnr{3
zNf&$<C>s+uzMg+ru-{#&Q=#N`fb8LrfeVU2ixlK&MsTtw-RSO#iK17ePV9$<wYR2~
zyk`ZTbBe9f%-zJfdiS43pOMid{#YQ0KjdJ2T~sxdHAeTYXKI`DqWTY<?(vHlkiUq5
zWB-d7yt+h{*jVAay)@dU!5?G>7=RAQYrO%^9?Ay5^6}(iO=t^zR0;iKZ)bIx+Vb(Q
z)|&GpoFip0TJBVMAOIvdn2U4PDpOpW5zY7(somUYF2gx$RKUnCMYFQ0KuqV5_yFIz
z4wn%h-?5~l&urKLrM=aHp%f-f;L8XeoNr#>_*IRp8(c4gt`aoXkcH9aJJt57fyNxu
zA;m60h1OI~f30?PS&U&{+PN$A$Ouaik>-}`;(~PpC+f<lk&qN@4eyqZlh_KgGYi&6
z01ZtuzEpvXR&)zKK(A3-^n8;~cXrwE#4_u;ih+yZHZfsy$CVB~S0d`4Z`E}}BUcgH
zP49|y538G--w<Smeuo~vsFh15dbR`B2j;5BU9dU*`fAojTc48SBGnX22SgK^FM_4t
zZ~nibCF&niV(dd+aV1Qci+p2vlLX=|-=4zIshba?t?-X)%#AT>cr8JdfTTt%R8_j%
zK-~Z|hV|0z6hZ&eFPcyoJGcpT`-^O!^Y4)EJr8NCCq%gw`;9Eh%*vys6fkp91N5?(
z^HGyCjX8JiUCIVHt#Ol$U#T@%I>XlH@EyA#gxRgas(`FWT_pC!;W6~!UcZF~a9RwD
z`)?_0H=xOFG!H9P&#I?-B+>_ew`I5D-0U#|yd~!-mt0j~KVqgj*M~ObqWT!kdR(Lj
zD%9TYNu)<oS4&sdd1yBtjR-2Y?O1>Kq5;`p)KSy60{7(;cS@P?*X&SQ5)64R1jofC
z0}MuGY2;+(b?yE@fjp=;dQ<@q?g9Bs$cojUg+REMkewe?aLBGCaDvE!xu#vXu+BSm
z|AJdI#}_ZYRa<nO)!2iu1utvBy}*^o!C5AkGI`kFBBcxDA%w+>x|L{ye+Px;ZK;x0
z>6Du&#XCdR*>ZR;fG8(9Rw@HV2w)DuI%#MdQH6oLc`PEYW?{}iGb+D>vWoaD(AthO
z49H3sOqO?*Bh8&nr)o`T0SxH-H~)*2l2zPNvril?J*D~e1wD<L3zv+FZOfy__oH)B
z70VS0ySlbb_fYOQX_Om=SfPq_I4S?KUd^B&8hvNiP<NubNamgpM5-MXG0s)wr&TQQ
z?o^vV{cZG*td$YOl}@Z!s3}BRT43ul(8DM44D=+Z%K$%vig}tSN3^pE)Vk7otGRm`
zEbxM=HY{L~)T;Yba@iHdLUuneC+eL>$Asgs7Sy7lzHgRAyuBPiCYcWl6Ww0!`1Fe>
zaHrVS*!kq>N|Y_-=?~dho@fiasVVDLVGCeAv&Vryo5uUmotb&dIg*}0&^bxurs4tO
z=cws@W_>nci0K8Jks20wNul55Eqf-9I4$Z-kv++3&<Xe0Reze}t_N7t=c(o-04Ju!
zKOTq|lVj-2&dmR@3{ZO`CVeCkZ!4-^w8T3^ijm@~zsFCKsX;-gO{Th%zspC6pNTP=
zh(?UdM9Vc#yJTTh<4ytm#v>|A$SO2wIaVi?Y}`jrSTSI%Y{&<R9la9ALek}^yh@1>
z#jZ=YZ(>AaV1HGyXtm;J5|%T~#b$h>&&VPBj08D}k*V-u_jIW2qv_z3pc`nk_q7)W
zE)N9C9(_q<Vq`}(Hr{A}>Dpewy3l!5DELtfv$LT6aF3MoVbK<sWmE1o{3Z{jPnzDk
zJKB|WmR79S5g`#OPSCzizB?8&G~AMjva(c@>3;);g0<wVomJusoY#pI)}+mQR=)08
z<2fY6tiO5xXB|;TSJ6mHtT;|BYRS#MXQFyhHRZ>ub{-4Pbm0U}XYq<-d{1FHMI$B>
z6Hv8y*qPjR+03Z~R_&-ZBS(rmZ@Nq&2=iuTJhy6qOokIp<-1W)^IN{YkkuRM2ogfU
z7(Es5D%JfTlpyyS;07vh%qE=IeH>81B-xiirk0ibH;gT9Yj1iK^O^+?_oXdPvM~QO
z=cu8|s^LgbvvTpGxD0Sj5qGGv&)r+JzuXx^#9^f*tV~Pe@Nt7aToeNv-@L|y6P@;9
zl8ziZoUH*3@nx4^UuI|kG~Ty81WYHAK=vJ2cVX^|sy5lLkl7gMNVV=e{-Z573A6lK
zxLmT`U`Rk`cV0FMgtu^MrqVU=5nE5i@Y+JoD=|bsh@FLbSH$p>!7m+i8Bu@M>SE;W
z33K&_MGdXo+5jnqkAb0zyIschjWK-~t?JRiYEq>{po>kGBw0b9b|Zc?$miq|7MV)f
zSWESNbGVw-Wy18O8SSPnN**44PiQI0EtaC}5v8Lm!YW^tN<Mei>*#*y_&CXlmr3&V
z$_*{v2U^d~=0e#-h2tO6HSXVm8<9LQOK`f|BdVH?gMIYa6<ausCBZ*CA5qUVt|3vj
zuqhN<3zk(|P!{Rp2ml53KF+kIWBol(aA~Q7@l03}HV~BLV^C8UzPegfSL?Q<CwPui
z&q3iCog8_)-a?^gwMND!S=x`XwTn-9Rbb5@{vA!{4G>?)%+=X;W`-w8VD*1uV5L)#
z-*?e-6MN0V*QjQKjeg;;Edv`Q@bnl}VD#$;kLv1DEo(gfkEr?`0eng;#eR1vfJ}z)
z2;vLKHC*Wuq@~(hiuz4kWFWKt>@+S>B0e(8ZR;rGargM&5EYz4X)&6IM71*ga7pOM
zh^eW~9zD=mY8K<k-rO98#m30#>Y;lnb5?SI#Kf_|IY3b7$rzDbCRn9L`m3tBA|{`F
z2Cu`ixaXn~D-?6GEdJRMuY;~JP)f<QTZ>~)(`-b3*xhkE@PQl!Q{#iQZnk;icvd)=
zZvAwIhAWGZUWwvD7`88WVDX(7BxAMMa$RYid_yc$=Oam~eUM7_G^<h&>tmb@Y$QeX
zhr}iaRjg%uRvCCp%}RYW(KH0P-5geUqTDYY;*HDRM}|KUCHG6x85h0PSgWAg#|;wp
zQ-v%!EP`U+s^9TXdvce7YSE6-sv1_sn#;RN2#?d6eqRBVo{+n!9IetHXAXg3B43uf
zGR#ZleJ0&)3%%}+IC6@%=wzTusa3ii4CZndjLZ&jE4Kw(%t8AelMd=SdYC&h)x4h$
zbc$8!$`kzEWN2ySqq?}mA;6goq(NYHO{1l<6}C($sY6jqr3ub#S^dK_&{oT;=wNS&
zfG8eY&$(q{R6%VT$Qx8v|5!A&&zYmfLw&fdQ(haL1%djwPDYt62i6X8D=S(JB<g(D
zr3z}6uc`5>%;9UPO#%gUV|!+vp8UqezOA;Ea!xr#8aRR_s#Mb7&d*OG7hAN<*o-Hr
z+~?oen+LQl4t*Ooi@@{P>6;d?lIbHc|C4=H<#p5UA=@xG5K+<z3KJ{NRm;Otjl2lH
zk7*dG@z>gLdkcVk6fDZvr2Z7e6H80q_#bS=+kCZ!Q}Yx^zv|NXFu)}`&4|4>@uV*;
z7E}`%9GFKg(_Ah~^dnvFAx^fa`O~<IJ(nO2%O*A>rXZ_c?k~#kRq>$NV5-6ar67#*
z_p_vQgUGD-HHRaVAC2+r!k_0-`YVh0#bYBo6BieC*EG3;sJ5{WWv8TTI6pR_gnNZG
zCRUP&GZ1a%k)Ec?f7*0>PJ-8GmwdvzZPmoZfjqxyH~0?Uc0GI79kU|^Wk<x17U;MA
z6QEh^nhS-g(Dhy^%yuOvbb;w@or%IE-j*in7>mK%tbEkbVd|Z@U{VKKzVbjnA_Tkl
zPbmq8!@-eMIqioP^C21?i3Z0=?S7vP4BB7OkPLJUNiMWNlFboLLRz}Xhef)727WNJ
z`GJJZxYX>XZ0*bf3S*>pJ?&pF5!ww?)us3rHy&^le_K(=fy7A1RTVm`M^JjM6|WWd
zaVPqm(t9*9>05c2hm>((OlO!LQ{Ds28-e#C#%e##BMd=<LDg|5AJm>X99JnyE|Xub
zLiA&g%&Ewzi2r<-uK`~lHiL=yp7ja%ixSaDxqensOd1v_(xCp{rLSw#6o{gwlI%(Q
zAe;%_3m{dbjBBzR^oSnn(VZCUoTapKNmB%>6lB?|!~7e{GtVLV&PwEcQ%NLK(_;eP
zMTVZ7sU@#<A4DKN5zaqv75K-tX52j+<o@b=0fpP0($?3?y)#7O(05R+id=YysDrP8
zh;pq*p-9&b1=Dr^h4hUFs-TWU7k@kcxlpHtVtIh)SUN()CS$HB%m7^D6t!SzfT5I<
zjxU!<ol(jqkVk%egxmfl=|OAdVt!H|<jUOsG-{1Lu&OF-F$e$<`b&v^Q2F_4yhZ-!
zR4%G<+{61Hg(O<?HEL09r*RbW`bGR4oC0d=BGDi7)^s;7{{th;{=a|`uEN%@*%5@2
zIQ+9GkdHL?y6U7Bxm)6RAqJJ_QaA2Fa&~2LlNY4tk^Oh)AOwqyU)RWJCKMS)u0NRx
z{ri^LY^$4l`jzP7%O=i3TOpd<_Mnb{_8_RTQwm}z;#U}<i*@Y*zm5f|+Jk;I2G?kl
zxc>A<J3<R%Kxe6c^9CBgsM1{fm{mXK&W_56AgCry(M`7{vW6B)L0j54g%PT>pqsTB
zN~v;;Njap*o-?!{)+Dn}L1w-xg8LqVPBHu78m@(H(zq^AduY^#<RywcQ}pZTzo2kp
zpRC&?A#PATk$S-mEl0H#TmH}^xxuIT*w^3+Q<mW~RV=F|&bg7@qr3%p&lT6W$=#&f
zYSjWz6f`oxd$5g{g;;hMkOZ>Rj*8{rHD2&w(t&JcXM;=w(AalDDOjdl5U>Rr--^)O
zG$QiQ5eOO=lV=|R4(;dWtg<W};QHK|biBF{xfC30YG~2a*0lg>9_cy*fk;#2poygN
z*&Uf)p7_X5b+x-w5#;mnq0-vSpz!QCNA>q^ni#a#h`0{HBN`+R5Zt{?o}EF?N>q7T
zoOA!3W8zeQ9@3-8aP{#ejJm+><{xxC$zD-y4@-l!^ksUDk#=Hz9K43z^yT1u6>}5F
zQM?m;_U8!cY(5%+AzKN5xn%VrPYJUojW1*n$4Npd;%&sGJLWf6#N#~tNX0q_Ph4S3
zEAP|59y=?Y?oQ(1fF(NeN$2D%QQOKd8Fk_Gb10VFBQD6uLqJchu($1n7J&{U^9Psw
zYx+^J1!`0~B$JGuKMlR`p~DubX8m<hGPyRLqax|K0l%z=kQuW&KnAm{ezrv}^(SiL
zMt-+hX@jw;pRgg2Ca<`)IjIuevR3NJMG<}v6`>YY+8Uou&g`69X`YPqf<MssT^=Op
z(LWfk(4a2ql$cT}><Z|*XdVX{sDJ6k4?S^8oRq?|CN?F|E>tFt@C$6=f%05AT{F{<
zU(fCa8K`vapfoLaX}WQ;?xsrP1!7t9Ql)&%v~c{$QC{bqwfi;m6U#}FCC>}qzQiJD
zw0@j)$i><>twO)QK)=lJcK*KZ-}@sD?}AH-&yW5Gh!Dr17L#0HN#6zVRUH#6Y5{nt
z%j6IN!sQ$W2b^o|%#D}F*|rNm12h=+$Bh<CH4}%Vhv@+t8t*f;%=2XEpiD=Tsso`6
zfS+q12{RcTb~1@^HL%Kq@1><&C}R@ovh2%$>@#wF@jC@r>Xt%&=EX_r#MY>ZAjHq|
zXhZ-?mVs{f0E6h*BB!hrwA=@%s2X#w{Rc8|S2rFceMz^7v?I&3<6<#rhh{nbd`c>S
zKeAejDlusyQr2n!c&nT(@a_{|_-osaL!l-X^w3|`1^>A+5AnnXUcI6hx4H^YQvi$o
z-h<olzMWh$ptV?+&QH+%`t7UF{>utGAyF;(MW)GaNh#yb5P`?%Y>1V3)7i_$PGovJ
zL?M197z-7tD7Ukhki8IkJ+U_N3_;I9kYK)^kme0kMvP<^crNrEoQ(3{u%@iOS|#t}
zz7ijuZrMzow>#%^-n$$9;%U@K{8O?&;Vog+H}mDop9t0?*x-ajT;bv4!7TM^<5KPZ
zDOS2^#C*t7G%iLh>qW(GKT|-ugX_>Y^!__gm^wU{3eAQjq!LNofOX6DUrd5z+3+-X
zbwO<?qz|f$`hRZsU9>b`;M0U<gsr_%)B#?Z?{sqGL^qD~8D<qz&FED}@BXe;ww~R}
z3J_0r&O4=H_Atz?9nh+;0#b6cJG>4YUIuP8z$oaBY{rE0e(Xmh&ni)uv{QGqPeqP9
zpu{1CRS9YBZXl$hdKn^T2QuRLGt2y5EtDg7_M*?mSx8LV@<8Nm4I=^l9$&P<I*XB1
zr*T!Juoj=RfPSB4z3))^UG2c2u0ELG$rwk{hyufIemDs5Y6B&M((()qN{~oA>Lybd
zWI-f?i?-iKvmZ<$l>41kkF=q%DJyo-=%;7-<7~9=fB{zAK|^_ltf;?41;HJM=JVFk
zpPjnsMZDHdI7@g+Pro993Yz(g96g7S+Gl1OSP#U8!ltx_gqRmn?_Vncojv~7IQR(W
z<o_B=-&~A0aCR&mVtfu~Cm^DFJT&_ouD(RqmAOGv()iDLSbE+Ta5_I$Q#4b~Ioa!I
zGPT4NB`Dn}F=#IkX*NyXAux$i^73dwV^(gyHriVMazR(Er!8Y@&Cz&Q;qq<?&+tNq
ztvHD5?CaBCBDl-a`Xr1O!~-F|_j0pPR|U<tYSUkxcm9OSPXW~Fr6xzV_P?bw3sTT}
zK{Hn$v}?mun*MiQH%+Z+?&8rbBV3Vh?#RMkRev2c=oPL7T4);Ip&d>Ti(Q@#Fa?d;
zDM2mKs^}<t4&%B>p8)TG=t|{_*IlaG9`HJP%2#zYHKXbGc@ejM%Jf&Q9j#I=x32+z
z)m#j6&{o#RXEkTbQE&wwZ|!c@;uPK}O!L@vAF1c5{o^P1M~p433NbgDo!-|?2R4qN
zhc}{`8d^#-{dm!##a|&0P*eaGlKy}De`#P;Tq6FTUw#VA$rK5|QMfVtM*1}t5{l`H
zE`D2j;yQS(kA!wxiaS*!?v?=Uh&(4+2<&pW=<h6NXWAuN?>O;#433jjsGVRS`YH@N
z#T+yF8ZAIshDQ3cOTe>j!YKc7!pIBh^zE^<qy0TH1%I>cdgpK|SM_;?Z!`^Fa!}|8
zly5&sG-#PCV_;wMwCp59eSG(Fv5u+Zf{49KdNE2X=Q}DSMYjuPVrQO6gQD3*2r?|!
z<=kJ0n$&vUBE2M)My?LO`~hSG!ke4n*wsoGFln@rBEbA}gZLa$O*7ezyiX5=&i0TG
zA3N!ND}f-;`tjL8D0uCz68KyZ<bs%Y?}WIQ+mI){#Q)BQ`@fVc_nTx#E_>`&--F?1
zUj6ro?e<Xe1Ndcbd5-JGsPc_oB+EilV1GOwW2vgDLefxGRTXdliSh<CxlXq>HQncP
zwMgZR|2R8lY`f`ZdOps=&${JriqI0e+zQ(<A0MBM+n{!zy-Rvs^A-c-YcBi?eZhQP
z{T?dY)9U(p?q@f1zcW0JNd^A;eM?YsbA&E;7E^C+&>1!K`0OORSC+G0*y6g3bqsJ0
z-VklrK4>{y6j~#{Kl;QN+Eay2t57)C^`Z8Kdk~-trs<UuP=y}remu(iT~x1I#_IC&
z<8--qynt9>n>Hj3^P=1oZs~S5H8<t_rL4%um$Jbd{rw(2x=-RK$!w<1E-v~WM<B=^
z{JX~|pT}7ruf4p)Df7$wmFreCpPMf696Lxx|KWT!ytwOLQ$SAh?bBktuX<*$&&?5E
zQB`7Vs`j{|ysi-fs^`1#uP5&jW@0>sgF0{kGyWt7Pyognq6ine56ryGcP)dp?FAi0
zzIY)#%4-{IZp^aI!qGA}Z*ZzN73Q5G>47SYwR7~{8*yp8uWSt*eXrIo(NDh`xcIDi
zNe!)a84L*{dt$tiby4uU55<%YX8-w0IY;HA;tc~ywUEtvr<*OQUH|`6*p-Jhk!<_m
zjH0s6l@VDphzQCOt_lf4z$+q(Y%UNKA)+G69uWct5>yr!mO(aI0wMw;LQr->2%v(<
zCb9%VFd$3V31ou=lG||an|FOP-+ld0^>?bfs`^*meNKJnoL@ECM`-{cK2#sKZk%TT
z>5%P3+*H@Q(>{KfjP|W$ejj0SaxyFU`y=mIEO&0udOs@)T6fQV5E42nv54gn0X~Rt
z%qZwM(Zu_0cvzMH?|_4*%5Mk7RG3{$=HtGd&V$od{DUkkO*ueP^~xlaygD~XV;DY?
zW7K>-!X7^ldS6hvE#27i-=4fP@|%Ic-iwhEiBP{SQ(@210hqGN+J4V6DsfI;?{c+i
zcR8$LBY1l7RlqB}!O@)(pZ>~d-kK_9=AVOmbqfUqO20NN?e1UCS&6_kFk&r@V&hI9
zbq>5FfHi3SLOdqhjk2<V|KOZ84j(<UVKM_5#Y?HLi?AVH9}YLqbYKEbY%5_)hp}$)
z@+8dF<w<2q-APs*-cVzQyDhK=IW2v{K<4ZJlb(D)W7KqG+-cy0z*e8oqM#U~d4m@c
zcBuB7JzLMV_UULiZM^%hl#{I-zTBo}p~RUR$=pjHcKL;lDHRnJEs{mT%F0U2B8e9Z
zh|WMr>^w-=w1=5s5J=rEZIcNXCmU(3r5Z0S^Uy)A-$GW!jUl2d9*l`~X^3dHv&~Fa
z8H@8^(9y2Kh0Zp**}%$jC)vYtMSxEg1rpY?{e;YqcpQ#90_@7MJdCSlZM1`}#r<Om
zW+Y?)chCn{v&E^dLIxfus%L%{msgd`sC`9fKb{01EBVWy;no!LYKuN#CW8PYxniDs
zxe?xVxMZtfnSJv8!y%HBH~%cKZ6990qr)hrKx&tSZ+?&Qj9$I>rU^cnv-f_^pJTC2
zBd<y%C|cf_8K8#JrDB(;nLZ(RJFq^zc#L5fT&gO*Csy}J*tMe<y(CJ+m&+my@1M@K
z>A0%?puX^WEv~WBq&VGaidA&Yi}i7*oGJa?pQFJckQ~?}rQG2&OOsyGnAqN?KAo5Q
zHdz6_-!w`9GUTjSGerb`s3{0SURz#RSisN)-{P_CTmp$p^&*ghfZyfyL#sTTh&R}B
zYZ+8pN^HVi<f~4FjXEQhYmY$L4NM6-pD@^rz^)XxrhLm0Z^rW5gN5%H`O&pz%akx2
zjVSnRhXxMh>P0%3C!CWf4$H9XSK5(ME`0uYUNm-TZ5NQb++*JLGWZUXKWT?t32_ad
z+a4yPGY5=FI9H=t68dKGUL;U>^E^aJr02nz!^6V}*R=)uW$Y`UhFr7uMH^z0=o7j`
zmWf5)4n$sh<{Pr&(PiVIL=L(2{EBCH{UM2j7XwEaHu=nxvd3V`ulxHVp-rIU8I7#`
z+WXp@#{U#AtDrQnqH@;Fee`xZWo+o<1LOSy&H1}T#ofDY;muT?CrYQ!%DhEaT#r`#
zo1_7;+;et%2Kv@<HzGEMR4_c|tc&noMeQqa-BEtWNcob}#h4*ZT&r-6!;y|YFQY9%
zBpoQN6$R?utB{IT=cVKWs{{Hcr;FvY-PFNDL^)Z9D_MET;bjFAo>JG`x*gubFqiUE
zwk-c`_xqN$_hHz41~oW0CBdaSW_(kF)s;x_TrO5tRf$%!MXLab0*)z;V{Uv(_{C6<
z{fP=-u&9l^)^^yVvksWfgi|l8`Ly+qJg#VdNjZ9YKtLxSdC%^UcEK19txSzWvBI}I
zI0I|yNCqnv-e|ItkX*x{bF)O6a#R5Com;bU0!*(CE8e8OmLph1X0DFrz1?8YL8IxS
zRXb4d7r`^Df?sXf09j9T-9|b(a{W7-PHN-iB&U%vlo7g#Y3jcxk6?qH7~;ubKN++B
z#j%s+Gq)!!MI~ePA$tGP?~H_7dK49{XP3%>Z}PgF>lKy68Z5k8?6-FcZwI^+PW{|)
z(*ON+!_@LOeXly}zgW@U82slt>XfAW-#wp1@3iQVzP9DEzM#w3I%4nA&JQUHmYy@4
ze#@*e55RFLXF%~S>-XO0WLmKmG}46ncB2&@?h94oN`&PaDnph`oVC(@^`}|UQqAf9
zM|2@>ZhiF=DhnCV+GatAcWY$ZsZB%S!!Ng&g)j%9mm9!_v7t^z0cEKeJBh|J(C;Xs
ze!unI;dAttLV)zj8O1B=)LbTjITQvG_oBiTNphw?e_L}K=_H(IAlasTX@dt$ifU^-
zYlkI1YdCDd9K6<v7A~?lT#tIeuo=HWyvze1SF0Grt0Pqg>QxYlm@KjIyFv0q*_{b0
zZfJQsQ(n_rLGZjUQzZ^zHq5UJ@Oyk81u|KuNgU2D>M0{G`u7Iu0_@Fb`D0e=s<Y^$
zv0QP*nc4T8?9MYz`V}{ktC6P$UzA=gF_5zU*r;hZHXW2vF?4vF=`YlWad*<KE>*IT
zhi)f)sxz*B1Z!c2{t5}pxoMFucG5Vs{hNtNDZa4yn0FfLdcNZso%mrd#7`BD7_E^i
zSjqmqYUU)kSyIaI;+q?3)(7D3JBh!Yw=&ww4#K=pu)*E^W$Iv!ze4LK?Lx4N{K7K*
zU;v<_HxxySnQ&=lW~Pd~J`eDPB^qYT=R~VM{&+RbdRw?F0iw4q8u!~DImSTJ(OsRL
zwzigoL8`$U)Iut23r6FRy2WBfP*9NKe`g?)IH{LnX1oO?y%H*b?$I~-eT1G&eiy7P
zUA>qU02p;V5=Xg;G9Z`=7OgcCTu4jNey+a4-sm7tV~HC{)7oU&1I}{gdpL7J$@|B7
zj<+OF8oWLd#e5BQ$@}|E{PPsnpJUR+UT?&!pV)Wcymu?=W#N|8Ek!BhPrg+l;_13^
z00(#y31>v_1QxD+3nW`H2aN*b0S&PWsd>PrR4u+2M56g&oVP=tm^kzNc7#^^v#ZCA
z?<pb-d}veF)P|D}Ev^Ly?1;d<Y5qrqO|e3Z<k~&yCyF#>SftNyR#o~gI{Rmj%wp|D
zBN|HApX}S_@wE_UKK;_=-O~p1(f;~{c=31&vg>{_5^Jh9N@6X*d6}%Q;~2Y6W8P?#
zyAlOziO^l?jgz6=28~Fl&{*0!I&X@L!-T603<eVqHp4PU8sp;PHVFUBuyxO$k9<7?
zDK0EjFtJ;U?fG=&?5V)W6R3y0h*$J2Qwkp+J$N)*%Uu(Wyew*aV%KSvfAqzNa#-M%
z>$~u35v^5ZX0HBQSOkoHXZ%D}BWK@tbCt8*<tz4<mCXL{I2X}C46eliqDgc#@fW0!
zdu0NW)jB)q2?^RoZ@hg^J3978$R5=GoROaBo?K=*(dH96`-KZmbuTCxLa$Gj+d}jR
zSwgJWtw6)5{NuE=VHwnTM<=rD_s5@K4-EySI(j%_Thx4wD+Jf$27gV=j`>W#N&RxS
z{Cj;SCW=dHExJL$2M?#{926u4T7GozTels|(9tV0DSk_JLMTQu=hSBr@VdF_Sc{zN
zzQRq&uE@D~6F;*#oWA~k*MJTKlroRa_8zMA>3(4W#;&++&mj=}glnq^*N_R#?9fA3
zkV)*(;dP;VTR{Bjf}ZI+trgHp4XDZ>v1W8ZejC`3(Oi>(t#t34%P0erI4!9?mQVc*
z*2~AKMw$|5dc>W#83NEUXopHBx-W*c0({dqG3?ZknFDwuKY$NzTD=u+W0%yKnR<X$
z%1%>ntw0)OUA{<TyK1S}<G5eVvoZ?Q3pnGwuV-Gv#p4_u9isq1wRy_0OAamuY_!o^
zoxaKgcNUeW(Z~zQo<7?P@j1l2fR?XPHmE&NxUZk$=pfy-`X$QcJdNvpYF-lG;ghj2
zOf6lPOvjV6)cW)a>Gd@S%At`9_<7x;{*s%jlll6+IxF0$=3xT~zEAhc)oX_WYO2F#
zxg9nY^ujK)aDyt{TeL57i$ikfh~L99Txnk}1Pndx;cK_ilywPNCN<b~YI26Tr{Dh~
zet2Q}&fTvsPZuEw-`=^m4f&A))rPk%$kj?W^r1>YY4!*Ng+f8t+kX+goLwNZ&^3z`
z(oya6Ss3d{vT+K%jNgc~L@@%*E*~Drm2K*vAmGd)ru96fOoRA%krqS=Sd1*H7xlWN
zJyinVt;60Ln?%$bR4>am@ltfLp*F3*66Oc8wbFPa-%U6)(p*XQ8>`Dp)VOtI?L>|N
z%T~E+suhD>`uc03*&5_5zau(Jbrb&Vj4E|?go{HBy#19HK~n8P5+X`JxAq{qme+fm
z=?o6JebIdEL#cp4Xz$Pk`#beNZBe~gS>n#`Ps!5ic5&oAXt|-8jvgkynLrTwC*Zsf
zLtFbaq&Qu=u9VBY!(Vr494&wpl5q<UGs3LC-HobeH_beaD&agq7~010RJGCs!_i*R
zvp0M!_9`^pPsaw#Sa4?L30?<geBp8$`4C#LXzuCSPu2du(~r%8Mtd$Kd736YbFE|6
zL<XE$uJW&LvYbqLbF>zF-h3>~4lxdHP;-_B#k`PM6ti}5anaDwc+V|({+m(<J(Sgf
zriVfCwsvWU^6KhBXL<`sBvP6sWP;0IEWDT8Zk4H(oeT@K=5oYQry`ksH@{d~iuj$`
zNLNl3!N3f|d!%*Vd5B8ocfs}@uU;NsLTz9CP+$wT580lh9U=OVqs2&4o86&yCxS_b
zSwCq?%528TMw_Fw9^0y<6`S$CKIrP`Nf^Bo6tr7j-UHl_G(VzLXpi51Rz%TUICjo0
z$kt=%yKJ<*f|L%JX;=i0D7o<Ph5hcx6WfQ?>cG)6!nTlQM4#$$gz^j7d`q|GhZ*oY
zXSVevioRmTWTW-rpG~2G4}BK~sHJLY{GKxf*gFX!%I79;KaxGjuewz&CaE^}<Zzdb
z6v9GXB~wjeOqQE}JP4gOy3OCeO)R|YD)XmjdX*ztr{~iQ4qt1IX`NiDudlcE?6TqJ
zdad5?6YNhdcEz-`C(br`d4aus!e+`SCYLywC`()I>VT+o#B)Ba7_hBlvG-+cz;yTs
zR;^MQwDLlnXYFJnGsL~2oPWa2)3(*@oZIBhHCw;(8Kbc{NzH&=8rAWS^H>O#?T?<;
z4jJ}O*d|10_+DD#&)Oj$>WYJY=CO`c<HU9><W9xHPN-ct@e_q1S>-vk=4S-buWekv
zI@E$MTXWeH(R~hXJ%`6v+i%RjUO-;x{_GaQRuE{<+?EU!L`!SW;TtiJzOg>6ER9KR
z0W}PwMmwsJL4)o9O<PNx3Tpyy4irNGx9iK(iS5-tfihL(zr|qWEFvQ##if;3rgGy$
zaSSUrx6z4Iq^gA@6u6>zU#Q#s!Ndd~R(Nwjzi;;azIhNRyWoi%B8~P*3sCvYt!@Yf
z5J;9L1_CvzfIvT^L7-#);{Q7NL%MPD|428hH(L1PrazkcYw1SypRfHv`a`!rbnwSu
zevtn71pmF;@G>wBfYZw!1R7CRJd`LSxiHoe4?PD0`Age8(;w}503dr-PC*9*f@$j2
zj6X$<HB0G1re<fAE>nAYSW7Kn9+#^K1FDUi<5Y~@nj+NB3raUSg%JiEw*3c`|1*&A
bUj$~7EPQmMqs(3qaGbWVJyCM}%Kd)=yn_n{

literal 0
HcmV?d00001

diff --git a/doc/assistant/rsync.net.png b/doc/assistant/rsync.net.png
new file mode 100644
index 0000000000000000000000000000000000000000..0e09407035f9ce421ad58654b731348636b4e68f
GIT binary patch
literal 61465
zcmXtf2RK{r`+iVVt+rZwv|mM+J!@7KZS899S+(~Jkpxw=wYtz+(JIjzu}6p?Mb#F>
zj!~Ns5iyg0KELbw%atoR$9a=;-aO}d?)!f3_pQ09A?F3b3jhFs^YNpHPXPc%5Bl@L
zc}Du4<<Q(S`pY>_T@zgZpemjH)RmdO%@F$3@ByG=KzN<Lan0?~QxgCHBnbe-z6Jn}
z>APar0Dy2g0ARxf08sw|0PqFnA}uuO|6qAxWcUz3`|nYJf`6j#VGDX>8%lqD^nXu-
z9$#(xaKPh-y3Zn~w(_DJt{5KEbVA8N9Nj4nqVcR={Dt%Fk+G~^ze|=F9)IQ!|MW-F
z=W?+1W2=cWq-|J?uIh_cp_#HTW%4Y_x+do0H(p6z<dnQ%pzE#)xT?t#C*T4~qn^oQ
z<oY^e1toq`lCut;S!<C;NzW+Q=Z>@eg0z{ZVdn~Qn*v&eSoxHE*DqWo9w@BR<}Pn?
z|6<U@U6tg1=;+49^XEF45;xV(DR5xc$m-JN-|TB^?GR%dWTaua;(~la|4L<(gG}eD
zg^aLF=ZhNKyW@pc@9tl_D9Z29-7J7|(rYNm5$xt-|9a(?h{}!MV+pj9a7oSLlI-l{
z!Q6fgs#{M&DOi<Tbh%?ONVM+hImWo%HkZ`sh_@(6iW6e2#Qrnqpb2dE#i=mL6fVV6
zbB<Lm(U$FOTm-gyH9z=LWJnZPLC@&gMW~{hp!)_{Jrx<%S1IL`0xQI>huKLtWj$WI
znCR-1tx5v*Z?k7KObE*)y*8$Qi+wv`J!N<^+%6Sqt9<L}FC6{wawmj1@#8$lU0z>@
z$P%P&5!QzvMYSl^yLRzBH%oJ&G0F*U(U8K%E+C|BjKIkoPrsGD87WsdTvNbg&s{P+
z3g8pv=zTRIT<bNz!nXU(Q*pjB(l4s>$Z*!U1Hqcyxfs&4WWX(ZxB!1A6fP_?s5CS>
z;=?)H5$3@xkleoz6y@+Y!Nj2S9OHt8o5o9p6esxD+M0)L-$P7n&Fo?I<L;1!*!bqu
z3qWpQD%@UNusXCAa8W9{D}L`^T)9sR4ui=maw~jWR(Uqt{-P>Ulkl0X@Go!+M|7MJ
z=1T5lDX>sYNatT!*;r{QS;<_{0B%-TS%pN&IJ~>7C4TXI`sL~CmI$1$^2U1xNJkRq
zuy<W1sfvRYw5H|~9f^-!DI-j2SsCe9O2ulPnFJOG-1ICM!q~G0?E^?Tj*3kSFmDGL
zDeo~@o-ysL?M0QE@W9$7J&M>pCrf<Cf`u?wjw?SVK1W(<yX7WV(zIfm^V;_Fkb~UJ
z&c(eF!&x=@&vMdv@G^^j*}v=;i_JXtK|&33_gu2a><r+H5M;&Hl57o)Le9cFtDl?|
z)zD6kd(+W<+K$%6jOFfO#x;U@>0kOA5FA3Pq~J#1<KtKNcoMnY!cx(u;aHD8F46s$
zy9H9>Nv{c!5wD6DW(rmA<6LVdg}Er}CGvLR$xiTu1$|cG{O<%O_`fv)gHo);6=j>f
z*O^v28y=U=zs4)8JdmW{GfIMMb#9oXN${_Sh0m%EHD!{QSP1+J^9?VYk4d9VpFkYB
zqi*vs_yFY2L6Lk%d%%2%tuQYPZt+XK6kGLbX-Ud7^50<F9R%!T1)js%s%Q33^my#{
zS<DWV<Z#qPF+1I7Pz}N0N5twl{f0)qw+1g2NB!;3QTC~GmvgJK5$1~C`eTmD9QRI1
zj&0Q3sCY1(@Py2<L|9qbnbs=|h#F;~M=aXe@AZEXi!Cuscs$|9Ti9?(AxfJtUvn=O
zZif@{yR|L<(}F*IT5F^J<cGnx&j)Lq^>DjxhBi+Uct)etQn$UTq=XI7Y6e~YdPzJ{
z`yS}%%ZCP2KgBH(9{GjlbgS0O<PNWOcGwy5mH~cCEw4g{G+e`D!1=*cOl7f;CIPtF
zI;nYA>DVbs6maY``Oj6HLbY)#?}~#sCz|AHszw~QLRgL8a$aS%Hb_k37NOt|--5_w
zE^L3*q%eEq-Q7w4>+`6+us>$jLI6M?Wv4IivI=-@=q(~e&^CIpxwa2-3xW2!y+_pu
ztT3M47-Ez-ae|?*1<aMQJIg#eX$~)f5&j}=o%S&}yvW%>w~%Mdxuvy(ng`$1fK>2N
zLUJPP>eW5xfxKoQVoqHu3G?k{{*9aFa0?+P!On#}!WhoCZfYQc4FF19pKZ>{3?MwP
zWsJKYdCex#xT|t6$*OzsYnNO~Km19yZHcvV+<2&fcEv2}pi|zY{peBM&8N~MS8~zx
zO^4=Q_rn4*`B(9ZX&SEpghUkkE1AO1`d(){&qTjdV%78lZY%0wj6%+iPSo^vXQJlO
z)`2?E<G7Hu2Inp1jJgj4YfdrLx>t{V*`Gj9WAt@e_a)%}hD^Q9a7TgY6S(T!xbM}U
zF;r~ZDjpQ@EVk}{lPBn0>i(zzHeWle<ym<nW9)E4%YG7ip^h7>d7>rjj`wV4w-2w+
z3y4Fl*cAG!TW2;qYJwGF*>&>3(qc62;Ek<GHzShSsP;X{h=W>;p;6thoWx(;V6w^9
zmhFLb!BOwW&!-CrkF7JmUYdfv6Bz4}>baq5sH3IrvsdD4r#qXck?1kmH(6?JR%PSx
z{CW8D#&e8wP|$lc8WwKKo7}k&w5lmm^lc23M@&;o!dQ-ug;$u>b}WUQfgwHncj;68
z%qCSqzyLnhxI1CSv4y}*LxUNZf^La6I>d$}kdm}Ns?j<<Q?&KDGZ<m^<gpd?Lm=Tf
z4sbW9$>E)+W9!jC)!>S0u9!AB5d7?HnHzvYwtC^G+!Il&(7XFW3V(4KO!M1B>Y0O@
zpUZ6RwelGBUT79)6jebdyPL7IW2-9uovhW@8}@ML+qYy|ma6^NZ>VzlmIzVEomib-
zEr$92)gP*_7B5Tb<XI}ZEd5$7o4!fAMcWELtNppuam<zw-@z?%c%khG21TC7*B%v4
zv?c55W28(}Ue;&*H}hX=6xL<i<MTNLR4DL#vtp_;Lz|Y<PHdtP6o>Z=Gr`P8eG_eQ
z5zA`5WSJ(adA{J^;fF3!y)MpmcN}ApCo~`ke>n1xn=5C~Lu-5Ug=ND6Q*;%B%Dik?
zpq~%J{f3D=M$V`g=0QQ``Ux%HAIPw=t>Y1}em{Dh?_GYxa<Ez@kY~lD_vfF*yJp9)
zIm`u~U!1g<9{ssNF9#QTuhxK2rbeakhbc-eA7(xN`~%$OvPR&ln*0L2CyY?EjsvoP
zYvf}%b{Hg*JP4$aSd*CLz@i9!-=iDRi%3OiAf(E#V6_{Mx1)fw@82_CS3h0u-w{0E
zy#nSF(Q2=RL=FC;74x0WJX}|sqdZgHQ5LecJ8mR$2vs;(p^*NWgX(7?CgOrSooR2C
zf7~G(qbu7Jw}DQ=YB3)+W+?`2YAP%plas6l#<^Roe;MQ;Q`nOO2>;2*-Y*T4b}f{#
zwSd_^ub|3Sk-ZDz-iqIo6S&_&-)u%I?Thjbfnw{#0}~Uuoq4+5`&M>443X@hWv8@F
zQ)sM+UtH<aeoqeQn|Xb9g3ea-%w%GJHfu#DQGTd{iiZ<C9f~_$tHM%50p(-&YShMv
zOCSAIaxkvx!s=_IN4}b^car*7f}&FYCKeY<sy3Kv`ivCAlarH@qLU3U3wucOTslf3
zBt=~R<jS9CRa!Krn4ewX$&bndp6v>F?Q<me4(rmEzvXsx?9ggA%xD_a=i%Yx@+pmY
z82{<<X5gDhb5+&mCM28M*3?0#s=pJV-Iak~6~$c)cedR84NhBcu{RIe+U9m*4chDw
znA9;+U4f$8yP4Z+e|~D-C0qyM+q9uGxo*xjDR6SO{SK<Bm6jU=tqs`Tdi+VPB5wP@
zXOpseWv#An%QXq0v_a00MozIy%|bv8Hv_&@E91*oSoc|7WM_p}b1)1mtRM$k=pr6}
z*4@ps%COa6^ZQGk-Q4NQok0JV%7vxpG0r-qb$Owuf*Z18gFPDL9_M<s>R4FgxBAN<
z!L0$U{PvZJ)W`I6e8(E`<iUdpzk?>yDj5WUX`}pClv>7J{=Sx%8gLl(uJhx{>U<G=
zi`t((RlsmI9JSA}w6l5#ZKwZ0GVcB%*_-bXf8wyWw<=$NIqkjyBI)d65q8ZxuXQ8B
zzul}e4wJN-K+Vn9URv}p=*x#DeG6<*T5k&u4tJ9u^0}K3St~Y1R!+_$k1bm(Yr8Um
z862#dl9}ImKTwVpk^=rgjDIJk2oQfeHtfFQ=G_br2Nbqa{NqmnvD`RG<y4z56oN70
z3r>aBxySJLJ0kRoFilztI%OW_qc{AMra=si@ivY)h}-?}(I*^HnxFxwojE(2_~4d!
zdN9(z?ib2C2n*ROo|ZkDOwCHp_KAoa<}9!)ZlZ-HV|ij#v$QNEjX>Mwu^&F&U`R{!
z6;ERM*^+qmR5oE)SpgJI+IG-8F6Uw0kmc35xwheRf?`k&9OoxEAFN}Wtr7Vj-@mWk
z+tUCNruzIM?}xh3?!RNt%T#fY2)ad`Z3d2Qm}=&Er!_RF7GmE6RWF}^?F>7(ZV4ar
zUhDbrl(nWB5T@SP7^Ezi`u!k6Z#z#%Q-d})n=Sg;llw0z!;_bp`P^I!IF(r|HZf6B
z2Enr#b0JM6J=-fcLqzMvwZIu2m;g_M$4IU<_qhWRwMzE>rRw)hz|fF|lp)taF0sqE
zGR}hL|CYQ9)Q0Mq)wyGQ0dw}GMcP1P7WgPG>gN`OwOB{hY@=Oht4sM*8sti)%BDBI
zqIT1$CtLQbRBid=udl_92Xa0C?ELkZG**Sz^j`{|tV(v8IfnV`%n2$Te<g`0rU|L|
z9rIbgpdA(yKg|bM)ujIwTItJQw&BW3pk)yUPCDISQ3SGnj175^Ca~i!dbgCe4*C@T
z>R?9lGMio!m+~xn3k#?0x?(i7w6=Qa2+~2uQ1JG!x0iuuuKw!N3RPd9A&H5*nU8Lc
z`YJo#F{Ohs$KvfJXAX?lX#cNhAn*r*yuMIA=GBkC<7;|<$3<239kWAIh%`A54M#Wh
zBrJv=g1zeILvSr;xFJ_@kM6GErmbR+)Y3aUdlH^_`4jkSK1tapA5HiVO8Q4Q&BvUC
zFP)75b;Ky4QDu0<Z#fPVY{r<XRgp(yG-aOX$cfJjuu#^Pm;0kz7JeTBIg>bg-kLLS
zp_+F8+G(qokh@@O+O54X5^1}AjeL+V513yx5XdiM-<oWWL1=4epOze%GG%)!VVPOE
zu$=uPL#_@gLb0WH5SFm2#ygIRP`|ap`p1-O(W~h0o<&ho<lFJ-uME&uM(cd5LKVow
zYa^m;&$5Y$W7NP%Z*TIjZ_f<9xF2T7%g|i;>DAq9OuA}No3m?|k*RrAT%~RCKHN<W
zO!)WHEQZ>dAJa;kE4Odh2ceRZx_`hWS-Ch^*c$?7iDc6H=&Dpii~5>{&<~-Zkr~a$
z>PQQ@g&1elK}mS<1v<i54wg!1AMBAGx2U+Ql0(lMQJ*ti2Qo6=MpF(B4kCirf8W97
z<k<7K$=OL<q{lnw((f`SxTWeH2=nO4ChY;S(XPC3`6}eM+3r!UM_uONs>0oyIXURl
zkQmuuu~Y+|<9`=*#B}PiSE?tjbh^u%-?sPhl>t5w?+Cn9ZdF=RYDQf}3n}}xmd5tW
zbER=|E3emP4?r)a7!jjBCzJHg)43jXp+il=2;2Xw(jwmR@bgk6TLE(8mHw08Z{#or
zp|g3u;Xu*w!t?1Oek#)#48%N!$SuKl&*5G7V$Fmfz)vM9Wc@Ew_J7oQ6T?z4HWXH~
z_ZF(PY8>+ff!iei<Gr-NfO%1MQ#5b@I}AB(S@$Ti(wm#7lUk&h1G4C+MQ~{Yg0l6K
zCz`U4^;YKMrP9MSzVk)Z<W>Q7(R<h}LhMgzX|we1LDcAzOXtr$Sasn{%T)pWiA^95
zatIGu!?7D->eUxN?7o)^D<|>YKG@O$A3s<wv`V6vICa+2#TTm7H2FCC#(A`09*E`j
zfA3!7WpBK^OuziN`71Lge7c8Mz5M(%&#*m)<;?U$Cp-@S42z07M$z0UuU_{N+Sg&G
zTw?c*Eqrz9gX{0n4`j12)AErPRlo5vLMk!!n#HI4*EG{kO^e(Ap!$-yFl#&GxAu+U
zPUdF+eOq^0MT)|h5~Og&1L9WLkYtF+N8J?NarG)5_6i)IYq7Up-CiG4yw;Y0e~XI%
zKC%q0ss8!6u&B<i+zP%Fq83mQz^Dr3(?%B+6&<f|^5)E92l2DpQ2cW7m=D4caX=<E
zJ4BT`?`S&^^s27@cd<}rbrA*o(T(K2caJSBBQ-ZVI!R-=Qr7)Vnw(NIl+@K0cim#K
zl|mR3(f+9Ta`zLVqJkn@Z#x^(V7ef_$0?$oI|y6|X#yw-nn2D_z8TiPDy*?~$3NHL
zJGTj$xo1(kZBhhy1#jK)ld-yBHz`mw`_62s#=-1x0rbq#@lWq>wsVZ%>_?j3PnKCZ
zmozGoe|lF`1elooWjKq6-iskzPw3MKe^)ZMn3?HeW`_8xxbkubuc4{5rJV!;Zd~C=
zR`wW;eD~eUZgym(Y|IC+8~Hga3%BdKU{`)H0W_SQWmYP01tO@>4Ie+hvX-dOzd!ij
zEvhQbkal-dqI{-4%wXbB(a}*++8oLM(Pu>^6I#$7JkdkBnVcw8n3Tl6ygpElKyzXn
z_V^RK7qkRarlzN-tL`Vd9&Aqosi#p@YP$)1D?%*%=umanR~~i9)5Qe1n@1xOc`Jj{
zK?Z?DB9j_$dLw<9{&FO81cx*G>38wGrkkfu!z#&f<dQfuf#AqvW9_`NvLgSl$2{8#
z-)!Bz95Ug@rBAfIo9ToI3<wzC45v@aCATi2J)!U3xJC#iz!8J;mRGd7tE4g>sy5Tr
z1&V8P>)N+XLTgWy1#s<>V$2imP@ua0eQRe(oiiHB{fn1=`+c$8>um~0b1Z`1?W;=z
z663gp!<V+D+j}g|Ds(Z7wJx<TO7q_7!p;ieR<GRRGBPrBXs4uiSMNmZ%sE<FX@{-7
zXZ`N!I{bE|X0^^v8h~;dTngz<`H;phdf-wXy!>|z1@okj5a3N7D@^h_J$y8o;!SYm
z6qC&5{Ms)q?an8wDI%`e*_%C;{Rs{|&n-lCnfCslxp3rG^XZ>AL<XuBrv<6W6NV>G
z4pbHX5M|W$Ec%(9oo#1lkS2_snfWp7bqJ=Sj*+FfieJxCrKNphbZGfn(Ugm1FK=(U
zS|%eS1E>}B$0;FNocdqXz_pbf3x`!yOK-kI_&jZDZn~3^N}o!_;=$9EwM$1CcXZFh
zCf2~1M9vi*MFoXS8Al|D>~mR}?KPhJNyd}jl{I@iepH(LYvaTscZU{-@S)oKy)1?D
ziN^Jr0ag(=E5CpL9*A$%*4B<^<<^d&&M>ikjj_+!SYH>oc(H&kUM3Rv_5@Y@Ci-(!
zfm^43!>?Aw3Y0+<f;2Dd`1ssPkeYfPVLFiA6ebgOf{1AvELk6YH@T9TN#gsPpZ0ZO
zWt>+wJqD(u8TMr}z7g%kW6hW4s;9@ECW4A0v1IjH-WEDXcy&aS1=I8_^xV1!RFYi3
z_~J^tQ{MgXwk!PB<X}oPlS($rn-8|pIy*ZBga29I4nZFsCw<bXob&^5a#8?ZwRv1$
zL8#W2#gA>6=*7bxpE_hw(cABb%X|YdUu$UKqkA&xxDr1vpMY$IBX1ygx*|GvY*TDe
zVTw~o<#bht)&wGNU`k)n)0=js?OkNk+W_z4oSgL)$?#B1qtKd)$3+&{Atl9Z4+AWR
z3D26OBP2P~HT>r8NRiRyx98eEnQ2F@k4X5hn!V-yoPXAd#eQ=AQe0eIYK?G0Ls8$q
z|4&0>y0f#$kQ<+!J;mz9$;U^nb~mEduLQ<Hm{2HGG=)(9R2c%fv7_A?q50R($NQc&
z6nc!UnVFeMC04I^v;z$>NvRiSD6gJ&H#RpVaElT9hg%*Gn~^srOIuq9dV5b2R{0<;
zZYRHqOQ>8Z_Vur(o`xi`tX_YwMnj8J#Uh<j`|PCG94cGV=pgT@(XVq(b9Ahkcim}&
zd^~W#ooYZbiaHv){w<y*QAzn$ot;QluNHBM8@MwkC?s=M)KW%|x@U(aE0RTtR_P*I
zge+2#&K25C5$#vsOOjr;(I>LZ2{rYC!>6OOb9oLGEkkJ#?z!>0^F{cPkeVk|M&tm;
z;}Uvzgk3ulQJY`>VnXjQ^%D%XIBs+y)^+r%^BLt&lZUc{_%SFYkH(tu>&V$YLZEle
zejnL2))Q#q!0Q;Zo|9fZIJ|iM^cUO-l({PK(o8Zoxkx7ySKIgQYmm-($-VG@q(W;!
zwYV6N|KG0Km<swCwQs{%pB5^%kOnkZOnlNH{BjHFF5%#cuoO}@!oDG(KU<mWa*VQg
z7{jNgS`(ltH1|l)ja&6B&lAo;WX}pW;fk&E#Z@>qj~`X@>EMIEf8Tp&*APiu)P@`b
zDhb=Z)B`?CXn3fieW4<F-)2zGPD?1;Bhg9^%ORcI>BXOCF!tToN-?D(zOb&fm3mAT
z8q}f)19WtBR8@hN=e8A+&;v`vlBUpA(_A&;N`KDd$B(~${R*HG(_<bQ806o&1yOhT
z8y^C5LLe+>h@?xcaxv6Q>7C}r#{IS7rIQYx!QcH&VpSrq`-(F&o&Q3=%KO(h+qU%S
zP|L#(A8{px5*|eP`<I(>!{!;7W*i)!_nR#9$ynhV=M=BG1U-7w*8h_zYl2k`9J{@-
z(V~e0kvW3C9ZLI<$A0~q1_qEXlGnue)eLU;_iJe013f`Fp$IcgvxP~6-<f6Iq5BK}
z*1Q7E;N!!iW3!()M1NtuC;k4D`+NfCI3RnE6`4nG7kwPw<WHo-(7`nUEsPwfyqJfg
z;GM1gJj5ep|8qWrmXMH;&D~0yKPM_#%p78ZT`#H(UMJ>h0jYmf4ZlknlzNA6mkXIa
zNd#Tc<c2_kUcCGV>5}$UP*4ypYfE}^h&OAvq3BS0E4`qzxA0IHU^w73S+$xhapwo%
zUC2THI0xjYoGrj_e3@4S00iP1tYuZM+zUV5BsK8A>t(D2;^OAy**~&SWYnzB^vCB8
zt*QS-*52OU`zkD<=6ceALr#-R1l~!D!Pu6_+r1FNCZw!jS1EdWf&G&t?N;N_L1f~#
z@t?4g9;T`>gx_l!7X|CQ0i(*@!BWjgK7xw>32<uTgQabmsiyQeTaCSihP%_Kalq_2
zO|i&^a-h=7u(9I7Yu&vT4q^eZ*l8J+299I<hm@*n?;0R1R5o{RkxhIIdaF6U8m0-~
zlGZ96^C5%suIvAgZGE^f$u)YWG1wWB5xO?y3J^>+fMefv#<BCZw0Qs*7odE6e5nT0
z4S~)80)ddo31DDg&=lSI-LnXXYsbDn+8#cgZrJJjYyt!VtxN4UHV9ryg4Wj7e0*7n
ziHRpy2qnHM4Yj#v%Y2h5lY{_9y_Oc+P?A@>YN0_Q`^@ZMW`@?i$P&Nf+zUrVA4jm_
z5A=Hf%DztIiaGdtxX13ULvzrK7`^GK)aYcdD5rMgmzj(ESY7p=GYjW=q+OKBWrdeh
z&nB09uX+w<yyk)`gc$#(BbrZAX6s|6K$C6G7<9fY`pfP@OoO(T`#Z%_GdkjY_~4QW
zR+tO^3pp}~%W@xw=&^7ft5aMGpL(DF;vZL|=vI6OS78G2$xcr<)6>&R!gyPha>qc1
z2H}RgvDfric$2TH|LaM<di8{RD+aXj-)B{C_`v2CiA$27Kj#ZbXUxIH`)!e7KfR~t
z7O#a?Y{&TalxoDhNOfF;hB;Dc=i(F@MxnGpbe~c0u!+E%JrS|ubAup4e6U`FgMf|M
z9oh`yrGC47e)OA!T%JugKAL^+^RxY^u4E>dbD(9lQ|Kn%jPoRB855~F{2=%UAETxm
zNEAio69o><Vj*V^ABA8nIo&TT0KdUYjiCjtTOSQ$0HD;33GX8@n&x0?Kcie*=L?s=
zr>CT^Z){~5%*SSt;Pfb`5uvu%?U1MFQ576MoV?*G%>yX3?nS8nIX+}Ge-4E;H0*xY
ze)M`exJL3#eq?p4=1wW%N#K291IIL|eC8gAv2Ci(mrtKXtm*Jv^U+MGW#{*ApMVf2
zyYLz!cF^>Mb;jYe<4sFHO%_b{k;#gt^nDvlcNpDc^yCUWT04}$0D4=x=-E<+AFH$T
zl-7<plT2f`c+R)HeJ{!a-ymCIlFm-ymz#SprQJen$iN&)OAP)#WJ@w;b}8pCv^;AR
zUpmpyy61<JLrf2|AsFSns(0p@0kptg3cz>F_mat8p^A|E$ix1pq)l1VT&gg@ADfrD
zu91cQy4L0T)z>NasQqoU)~GtD4A}oA%V}{J47fP}Jv;iQkj<wSYE#oAufnq};M!qR
zrGF=c-N^5@+ctBKsM5~=>XU6I!8>uGD=T};!GJ@h{G<Xt8_gX5KyUBIW@a&)<qd!}
z^6}{CXagQP{eUZWW2c(yw8Rsuy3&&<<O6Jrlw}<(Y#>K4fjF^cR(ge4MGz`~SaE30
z#?GJ+S6c9V-MhZp)*1eia7&;rahQFIlZ`NkI>B&DJ$?EyDk8r|O!<kr&$DLiC^9?-
zQC7A!>chrs<EIimn6DMsdbF|%i-9ixy_)f)2)q8o$VlSyWB7N3-b7OqUQ`RT^%MTx
z_O6xdFq;{-8J(@3Q2EZ(Z^uv<6XxUM=?FqdkPzIYsge_VV`sPWx}Mg|EW_yNOs+(-
ze?Y(<iCo(1r2Idn+F!^GI&P(d^$md`(nejWX`*rGZ1ZAC+scaM2lKGagK}M_S3Uu=
z*$4Zv^j*%*=p5C+L@wwER!{Ek-7tLImX1`#h<Du>?oRZ<mg37l?^{k!Jy-h(l^2SB
zz3p9AR{nYOowM!pd$ngXud?9Qqm4w0cXv)*9TW;pO{G%}3LQ1vOF~}|P%AM*IPp%h
zFtgH&9QXqrPnqd#U*By6KPN12hi?w#os^wHy^v1oe(ms+e^)K26{R{F#J-dXanHc|
z85#DxV}!J)OpMZyQSZEZInzZ_|5tYzVL-C#&Xee9w>@;d?VBl_?D`D(jovcQQ=cpw
z4MmysBykDjaf-;}2{<5N2n1+WT!j+RM?jgg&Y>LO_LPvYu;#Bi(#xH`)~8YWcSdiV
zx-!I00|~*i%w*>2kO8dL#IKUcLQU3s)cD?b1_>yz@QLY^VWtUw1=Lhy3uyDuU0a7X
zI8An!Ce;}O#`cm?@hnxgLn^aJ^Pj$Z8(H^VB9b`-$tlHEDoe>DhgaX8%{1Y2%jeF#
z$2;7+;Nd%5Z*0{&cZx$MD$2bP+<BU`$syY5YSLtl;kk3?zC0UI8l_S;jbaY5LRv?;
zh?rjh8QW2>(H7e0A~OnOfv<(%wEgkvX78$bu8=g+e?7;#Ot@ze$zXoY3~DmInjf*2
zL_0?7P{im0)%ZI{WKj7`A?<HgKEu!ibY;6~(yT&*bY$P#T{Y>)nyTO(l0NQ_|E%iz
z>tpAo&sS(_L6MC@N$%gGhQu<TG~ETTn&wKY+bKae?wYu5CpqWExORqA38}7jC&voM
z_CI7bXpE$`=-)AToHX&QYl?kbw3a~P)%Tm4nQ=&bD%~(Z=u?*u4Sx0Q#b*7qW^38<
z=P1M0`lsM^Q&L6xTr_0uB>)z1vQNls=4H+*cj#Kar>>JjiC~&@3MlKcS5Nz|!M*+s
zrwB@1`fhof;9Vyp-S8}z<!Yh1d}_b3k)i__(q9y;CLDVYNI0!@H7$2Qg{^-yg)fEg
zX{m7VtK`fU8m3!2Md^PtZ)|M*-A!*pDoWkBajxyluxUaHmw-k@-vY*v-hC%7B>-Al
zS~z?I_!EOef#`_x>Og#(3_I}O<;S}PmY$~3Q6LJ(d9Q$g%Wpv~7tw1qWg-CtLOx?$
zdivlXJZ598#*_F{jOmmSu+Om;wb#wFsJ+-B*19v>oc>8L5)_p$d(sI{8kAifc-N8u
z0KIuAQ3Pi?WrC`oeL^5)V~-OP#mvt3r#`AiUKulw)|)3-JOv%YVW$1r3!^5?yzF-6
znVl~bIWS8hVqMLfp!52;z`5Ov=PR6=?aX)m58r&yF6R;CJ$JCawAex0=w-U};X~YF
zE1#^xMYaTP2eH+A;H{Lfy|tS$)_|Sg>A{XOqd_NK4ftF^1@F_AI43~k-TmcIK#8J<
zOw7*bT;)TV*{3`nZb4`df(-zx2huDY-Snz6>7lw6JDx6S;JaA4kFaa83pud>_UmQ?
z&<a+>_6x-TU16qwxlPcZ=`{VomZIUB96_O8P$%lfrt>dz8Xk=|dcv_Bbu6Gj10U~K
zUJ~c<R1#71tG$=ana3rZqtN~$D=SNf_}dGR^$&M;OcD9tB9lwae5Y$3+726i9|k2j
z06rz|A9XXNB7c6^Sz&Pb4bTB-F}FnfBo43J2&dJV$T*g+3ys31U`#GAyl9{9b%j}`
zvixY*N<F&sYfbX`9II_2ObNU*{u2V81*8a12+=zQV{m7)qcOoer@-<r1%quG&Z5ny
zQApZ^_N&;RvD<aaSzD@qf4o)gTvvYiaB@(GlPmp{I4Uq{6jML$VBNC0%Z<Bw7cZG-
zB{0ueu;`Pj)`*x$Wxocp88S<9l^u?|RA%pLCg3Y;6Fr1H%GBSQp2;1gh>6i0w#=RR
zqWys%OQcQ!{A)|d9F>S1zRONQt&MD?xq#U2g%%*GBzF7TxGx=UuaPzFqO*#6P*Q3)
zHp;zq70azvH^XbKCi~v4)+R^H&CL;s#1qO6I%uJz%vMpPY;$yzY?!{n$IJWor6Qf^
z&)&*A0>3M+lQPRc-NkV4%%Mtgn-B;@hkCd)KR<uRx?(L1DKpV7$Q^g0IH(=^Z&Um~
zsQIC29i*>^6{2NOH^lh31r!>6J46zURaJ49Fo_~3GBFPS4gu)csi_<&lz~X%-8$S~
zV!QMq{#E>7Ru-SI&Qz)App?XAfF6s{z~_8A`M66E7hRYsx&R0s)V8j0q!LHjV4~Vg
z#|O+8XArc6ckg!C(@##0k~jpP;fLOzY&WnaJJYpPYs6n>#z8tF6jqN6$~0ctp0WI<
z$z^C#dQVsdBgY8Tb#p6hF5ONrsx=5bn32T=&RhhsVLIqsBiGSYNiMRjN9;mrh4p5b
zIxtRSeyx=`sdFW$iMcy1ewcDK8Dpqf#u}ch%M9e^U!^n+A-_HD+%vD%Y_agn-##Vk
z@o4)T5f}Tf@eQat@6cAeXf?dcUCQ;@OkVpbCOsqC1b9FmwAnZqj9rhNk=jEzdRT5(
zNO#OgBkXP4_A8xeYWG!d<(!+-zRSD$Q|gT2^}E9aXg<zoBVOwau%^r@v0BmkMQzah
z$^3TVF9cH|Yci(+q6{syyWwhCoRf6Y`EG-Vg)!f+Ih65|M>sNxGS|80aB6W2a;C@z
zD&?ix#-_RYi5dy+-W*Ew$Fj72@lk5?%_#CH(T>X>l&uZsTHeTM4`yl`Q^pqT582)s
z@BKva8TnWU%;x5uz48YiLo~Z%BW$f<HyLnc@NQR%sMhh}ssJNUHPiWx&A%7lj<$WX
z>S5!p)tZn0xI0$dq_wUY0+eoA*9Xt$dSg7kGl@_5B}lvbMYd1HkK0@cb_or=BIxQI
zxFqqWzrM!CKMTa+M%fzl6|u@e_NURHpl+YfM_s?%HBSnSlji~ooWAiFAbZ^i8~f^O
zWV<}4LhP>n#F3v#>eF7OO67i#NsZ}rpPU`UWLBE}>-Fo`16zn)S<X;$JFA%H$yQCV
zQ0j`3lG4^}b3;>8RL@5VDiykRBVOWqk>_BjT5iT2YwC7j3|(tI+{c>9IwD`5M=kxY
zJHo2KBuw4E?{g1bTHi#Z5Bb!Y!WGZCiKed-2o=L#RPtOVGy9^HzG1j-Bx`6lqiTbN
zIEMYg9s=KJN<6{^K5J@jmi<CYD(t>cD@bSQZ)_&}hQ%?QcOY~vEZD7E=1mNAu`yWG
zlvRk2ul418!P`qq`QZQk9_zdsTUxqV`ArYrZ7g!n?~6fc|Jh2;>n!I>jqLxjWa;vt
zb92P9%Yb#wOT~u|0;NjlEoJD~3Sd+^rg`+z>!{O6rDmOc?1qP^hW)9$+H0+E2HNNr
zGrJdP$k%E#F?8LJ*Y}`r;sd55M&?MMty}}xN|g-ku5hHC>|@h`1kIpbm+kFoz=c)~
zy79$(NnG5~(Xl&Cv>z_|Z!=V*xAH9(dbsio+aJhqx;yDS`$~$kPvlp2pCT46lldYT
z0D7BtGR{5+!mBZ=e-fDHPX_Uu)i04mL!Hb;^f&G0X~X9s`+SI>47)QArzDq-Ly!v^
z{=E_akV$-flQ5ud=6LxUPC8chVq`Pv;o^0mOdg=X`@QPS)AOe(tPxQ?0z1_BGp*E1
zIJ32ZJyCNAfj{<FDD#XcQ*>n0)aNKT^1+aAEPE1jf!R=-uXRA_PChfhpxbMc@tCs=
z3DzrY;V3xHD%2bX#Mw((sj=>h*hr&`E%AV$qT06iUQUI~bj;@1YK1@soZdX==<GKY
z-t+?yYZYF;x0jlK_R8;eaUr6)CfoC<8Kn(3(@Ji##|Mn5CawO$l>pQxOQ=x76AIL@
zRsBV_lq&ADB2nz7*X0mf!0kbri(epmKF1m%k7NO;%H)N-Uu!$BV((g>Vp67c{=Orn
zF0C~H@kT2rr_X&pBNF(bAvhc7F?~zB$n6lhq5%l#nH~`34JotT@8+YnfSNkR1{cc8
z^aEAfUW9IXL$vyDdKDX#ms<H&3{O2tw7T^<d)n?;rrcsETfMy4snmNY#9!;>B7s0X
zB@u^*hv`<D-jy#qF|_H0&CQdIQbfdcC&otb(QSZA&i4BH5nVDpN{=~R8ZI<M(ZSEH
zrYL-bZn24=5Fu4W`V5CwX{B~;2HuTvo5kZE7d@@B>t7B@c<>F4rd2pb@3E(a>xOhw
z9?*#hJ$4|q^V4igQY?p*7P}}3^O+s)WT&~zBiOA^`FqeWJJ4p_P|yw8o%CeqaK7_0
z&mH#n_FE#hr`i$RT?4seKYNU0bnqQw7u>NPw=+0fwOh5K$=dX`<t0qV6yD#%G+$jg
za`(M%{DTUIPtDD2gqsAPI(3<>C9pnl^UB#Vndj|m=M`bVF6J!{X{Db+Ql9f`d=|X0
zDW2px_$BzH;(uyh1vxp>akAW+nw$3?dj&S=H$QpRk(u%k{H^<Y9y5$7@;fW7e+GN@
z{gb2*zVQzz#Brs&#v{f41NE<l?u%6W2^^2p{%^SBr_)K?_s^<M`LP`}>cR7i@z<H6
z86t1Hp1h{I>D}r?FV{K$d&bO4GED72N#e?<D<Vgn*ZGyAA9>0`hl3*WM0BEYhTR|$
z5Ji$Pv8$DL-d__3qaLkZ`ViW8^@}pCDNhW7-JEY$J=DvG(C^;*zP&y6MEhF+P-Dpd
z_@p5_g)`7&J)lkNaE%*G__xqO-^f092xx)y1Zp#56iOGRV$7U&u`$Lmfq`QAR*GQ3
zBx}an(qTq1)qx*bnf{ZG7fT@4%&HkdeK4xmOn9|Z2nc)fToAgpWeuKb0+e0Vi0&az
z>#-hxtIj0u3ld+Ym&|5t#(oH`52OYH;86yPIi@N;&ko<WhyyV!0y{Nde6{6n?rwe(
zPcNbw4YD_m0>7{iFz!<3nN3V4GFm-L*dfI*qDswwe4!F|f!*EjMQ{8>y^(fQh>k|x
zWL;BJlbYt-$+WDDgW6OOY|3NWw(Sp`4}82cC{fXu5NGM1jk3&RZL5-{Sm$a?KiWi}
z;tgel4|-!B%m1*a(*;f+z_Dary)FFtW}URUNxTytY&iP^t8hCrbKG|fBvS6VKQtMW
zSYZa!=D<{zWgc#jK^aeOeR!lE&5nIYCJTv*igIAybS~1VuwcINQb-dBHHX10?Pd5n
z^7!%;RqOur+a+CM9P+VS>5sNT;OKH3=?E+<E6bZqp7f0F{VQ|V{`d*}clB+V{7^|}
zJ-4M{H)bBmhh&a5TfDj0s7_;5Rq$pKEmKRYAKN6QrEcU_xHta+6Ju<1`y%~r_#71l
zvVQ(tL>(*_agZyTM<=ZNhs0Z-+~~dua*ET9Eh45z?8(5Xu<(_CJF9TqCf#wFb-LHv
z#=r!Ff(+cpuCjQQ1gb@p-B;OOHyzs>mV%X?O>0mHx2Sbd*hQVw1+*Ase*ih!4BS}@
zv%~nz>`Uilq4xgL{Lcn;aA^DIknJ<tbTxQV!SjZg?BRbsWfgSR`g~6>7v(a*?*vWB
zH?bjXkG%CQG;LqYwh>kZsP?9ds6|Ehh~;lTNX>)f@90{*C;gl{>G`>os1;-%uKPJb
z;T-#gbO_LUIYOi`aAde&-6YwmaNIkajI3EuC9nmo=h&)e5Bt)^^+5o_^u%bf`nk%o
z@V$?vRt<gG?ryr+2D~T=iUJLP*B@`zKHlN&hJAqo-H@fFrKWHak@!_JYL71IPx#Rx
zU_1+_pu)>PO^cz?4Fr^9==3q>>i?XFKmL1tiLwp+_Gh(b@PPk&@q)xpx*_5MyAbl<
z*tyjNwdTcfEJhsE@mm}Z<<XKydJg9E$z*a0@+)`_DB@#)cRluAN+pE7`{+C%V|Vzm
zZ5CB_%J;3IvbuV2ej$Fa@9p-3mUD7pyYn+Gh*fPq{OBmSW~J+kg`0#KhYZ>VT2}dI
zdb-(qFh9m-_ahv>O3oRRmX_8Ot)sQIKIV~%sOK%W>Xl2eDphW|_o#GCfx|2H7}cMX
zg|3>ZWRJBfb#3zs&z5O%d9&O0IP%Pl`#CiZb9Fyq=`N%uSLd`T%Y$}7S^HwP&_*bg
zw9`uvcZQAE%PcVX%-yn3$+&J);J)8bt6A<e{ll$c%|=?igls<SRc6`X6@JW{=~RgG
z6+m&hw9l1x?}H%pjs^Hs6TpE1Q)Yn)2?=ytx{S;~f4~3!n#B&vI_%`YAAi6ekk`H&
z^dl?F+Sr&w-{OBC)&}x4{#)_@(uUEFl3+;*3FPeI<nK3Qs?cqg=21VN>iGg3nnTF=
zpR^uLFnTZ>cZ;A&J9PjgmaK1VZ0zhfKMgsUX{wfjg&kbw%!_=~*^5>582O=R*qVRk
z?AiUnSoW*|_8F}^cS;F00tfG%TU&y3VWeerWEAMRl@-1BPx9MRbWF|yfFa<A4|Zmw
zfxRAo=oXmMzxv;R>2#JtZ*$Srbh<&gtLu2gd7!Zg+0@ubm~EB{`}2OzD*a8^8-r42
z{&K6rF|WD7iNCS*DgV#RP&npIUzSlg9AIq5isA3@%yM=!S~KYTknn&P1bYBIyIx!h
z$Av!bL5CF0KKR<rtDPQW#-5j7H1bWqw|0$OYl{C-D72BGzP9g^>C`Q!Za`nxz%0{!
za2x;b-34tJJ$2+{XQK}nNxy#ms&ebj%*;Qd^Rm_c99)g(U}fbHT|WQ&GB29>a_m2J
z*(qMCIRM{ULl<SalEn89-sP*MG0+EwhJ+AikfG~+MIUzt`l9YdEWr2}Z)#a&tNGpo
z?1;{hfrQQGr;;02fFAwX7SA1@+glo0T+z3nC%i=5?R#%)=%zL77!G$Q<CoMcR!F#<
zl)BGiEQ78@ktZ1R=E{WxI*CgnwXM`~gws1nYSh^(y1MuL&oaHguW5Dr`K^q*a*h?g
zkrS1q<z<Zsu%@0$P0}BD)i>&RxuBh1jSbyO)W000-yuqG;Tw|B+kE`|Dq&vm*FqH;
zwSv+ZIlH_Au^8vU<vjpPdAw=46@3|w4vwZHnyygfTW6PN+U-$eOQCQndd^w@XB3&{
z5K-AT*c*)|lkX-n%W>?hClYxtOn`qGSYR00hxE7;T_djqc8z{jNqA=M%$IyZ@2R-a
zx$oRuhkI{kRCIK@kg5zlZ7V8<PStwr>gsl<iR`=r(OFrizDlNq5ylYkr?=1F+s7kx
zqJ}EBx$Buk(jGj+@$HbsH19(z9t0Z_0p&l&N_cp(;PAko<v+(Z$%xkDcaLt2uIGxN
z)PxkC|0*tC@hE!w^P4j2>?~bOBVui6LG;0}OAn7pf4_swAQn3*QEfUt*6cax*1fkg
zgWBv^<vzbvirvU~B9Vh3ggDas-t>e4Dkmh%9$e7ZVqsxTJ~?**rN5EM`~1@ey(=eW
zDr&Bx#FhDa|H7KBrRC=02K~{os!^Bw9D!3+R*s5}Itw9`!QtKXbdxf7D0%&8xz{fB
zfZpe(L#5^rlYzBV4H@UA#r5^!nVGGP4Ui6>@INbwxch*40zp)j_Vwh7f}hPqnh5OA
z@}9g~SBjA8K#=m_60z6}CVKgD$l>n7%F4>)Pm)?3XXGKKi>%4qTWaQeZfvpI?I_v2
z=EGRu;Z6H&LHab|TWpt>mM}}z+0XJ02a>Q91uZR2&2x0Cf{!xY_Z6-#l7v~H7gKG0
zi%|&I$E~reN-k~jzl`8mZzaL(Vl6E#!_?1nt&o$f8qahQjq&eRHEoO4_pZS9wucL0
zFDsMT(fYF;FRCVlRkAR26VSkKMU)eMW@H5Ij5Y&q`+0f2v}528l-<#7Z;y(?kK%Ab
zPx)Es)xISGlf>=oZK1Qv*GIQkJ-}Uj`|ys{jj0)Bm$q1(Q}p)2bN|R5j!w8zZDO%E
zKzL3sij;EQ=lJM+on81RWGJv(Jy`Zr=L;hJ++p0Bl?=-WE50NQU8|sbKYUc{qLZh3
zu{D7%1qP*Kn_(<jm9}&P8ePAO(iGLVkddJe+Bs!soAj$MP410_p8ZBeD^?QIDlTD?
zZ0j%G)zjxbcok2Nd8D|y0e8W-iuQi2$+dlexwADQ`uugCSSJL%(T6nOtvY<shM+qz
zmP48-G}i!MHQ}@*`X3fAPG6^V?$teY1J;7W$l$&jdDID|*!y_P%rm?%J}P-Geo+^7
zFaQ4>W-=X&Mx{6}ayHEf0>dmD=W89oN>yf>Ak**vbSx=crJM-5|K~tkkpFEoAKpx;
zPaA&j@as+L7q`}A%;Nsu&c1jIH=8G(sux+Sq@t2fUH?}&PPbuP^iu@?TRUk|e11Sm
zpv*y?gL}J3Hy(&Bz$~+j3^a))Ip^QMe@u6soqP4^ee_ql#qItzHD<Q||Az7}y^|uF
z@PDU>*DM<v8bHfs^PG2FE*#GtN_;x`mQVYvo<85{cFc@%LwRaPdJM7gN$8*DD1X^>
zG<qk++l*mefn%xmrFfNW>I4Pv3uq(85e5na0<9O$)d#E>lrm)_Z~i{sSh()^bS7(p
zq2L(cGqf7lHNZy!C=2fgoAcZUE~oaT6(q)KGtI}H-zm|toIiKpnrW!(^+_0Sw-|DY
z)$cw2!v8*aQBRL#TMz%IZvptv06-el5sL7iMUE)|r-|nQ2JkN}q&tqq(eX=cYX!}-
z<9ec($F;gg7{eXapXFJ%y_`<MC*4DRYo-R3HtN*JoKE)2YVR25SIqRDdY@=xx+ZKb
zo6S$<uScwxO=KB%wQ4GO3^&GA$p(SDB23<VddvNAq2lWPm-kd30^hWm%%B<-cWXKw
z<N3r>A_XcHc+ztN0LurH;~F**%_E#b+<J}7b8$>=Sp$3P_yhlzld$o|i2(3<O+PRg
z>=d<pRgVs8Jo>)4m)m%%h@>a#xPA9tS`fBeF^`iMcZv*H=`Adl6~x7?h|Q1FzFB$B
zhW1Izk(MpYw1ozVTv3r1zWALCoyc{&fxx4f@<pmz<Y5lil0<BlGnhKR5U38$h!axN
zzRwc|G`5z=IDhVTI~xb_619!(+-QW%Q_Z$ZjN7tV91qmAV{<IZmcjr9ZA9jwi1lu^
z*93JJ(1**cxpR4_^V^)@CWu%Pld84>=e{V>Z)+8XTPJ*OcvoA*)-5)lBXyuME(!o3
z1>>KfQolwsZ5(hCS-N?UEc5wajdO}i7^Diwf<vtHdO#E~3lu-N#ur-u#8k@kaPeUw
zLW+ufx&OLBBCr7!9t9}TE+~!bE$_+)9G@#$0NjVMc>VSKTXEF-*m90#7j}y#ADVn_
z_Z&oUlz(Y$2>iuss#r2s+h6#HpwSUygKicBK-pNOaZsm(t-!37hw%D^V`buvhl{~Y
zHy<kOp4^e}5Dgo!U11V&1CqtomX1*Ffj4UZ3nJR4Gwt1*H<gc^t6#n~DD3I$Q!3(5
zGfei=fgFGGMhJ+`pO<EJwd(eO2W^U|1R?{sKhQFq;j@SQI@LgYur_lOOOF-Q@Fae8
zF}BWXa7eFj@NzvUt%-T&@H{(dM@w9Vf*n`<C|*VPg5TYCt1T~*RB48As-XaoXblJ8
zUfHG?{~t7@ysn@hI~$&CS+f1mNW4~O8{h4^=Au2W4#&K;{p&fOqV_gWFFxDyv-8n@
zimS6n3->j8q(XMkI%f$|vqxV@dvCHgvc<T@Y<S6Hx88DXZcd(`4~ehbdi0@!z!xNU
zwrq<BLn6Y$0>!i;hTEZgIg0yav8`gJ`N;jW{HwerOkwEJ#^<6(9}7!!1gB|9HD==(
zVhW=Y!j}~z&O>f&+Ig0ToAlmiFCq4th1ZzNMQly%wBBW!=jErn{bRY&Ri<}NtL8(n
z%YlH%*T!N33wQph%v!LUtz->n;00bs>fDPOy=lgUTT1$#jdV`A&Gt$vO>AfSoa=Cw
z{(hb_AV`yiBZvGfkb>O2z3^4<2#GX0xSdVjD^qkI!`zsW)oJM>3MfFWUJGrs-YL=T
zu1Qmg3_UXH#z&F*TMPhRzxe`T`$Z{;hXo+BsP#gi;mKdKIj&=`9_RI5Rt7(vqhX!7
z{>M+YIH9mwpqVq(Z++Y`7?6Lo*txY3g~&f$i!{Foc(QkzV~;2F>%cOhXNbUFCsE;Z
z^VsTir}GyS&a3(d(m$o!IX99hK<&k(pBP7a_Gnn%$REoZ(_If-o$ZMxA?)2-!C=td
zm@4c8IvaO;=3b{?J?`7vk~l~Le(ThGL(Bl$y=$zCd+aHIM16bX8hyGSM{wwiiu$b@
zeKj?lJCv(Dx<jt-tD<MIX&y3Y;lU<qY;0`0-e1wIskm-`_Dz<jqi<c)a7{p*YfV03
z(-v5+YqPhktK^t;=7x>xdV;x)K3U1>^#PbKfuVI8@G0|eb@*ZGHD!GL&$+TJPl$C`
z@YYSU+I)#Ea;^%y*L9uA-Hk_tODE-NXG>*)t@kvbErC4XcU(|I+|)KwW!tT?yh+l;
z&Uv#saXj^X5IHwiR_Bx-X%IByaTYwT`c=#r68yWB8)2LMafy3Y<UXr;qFz~yOTp=$
zEC*&nW7d|x+v$74rJH0j+?k(D#)*b)%YLT4hr=?3XPT@jyRr@<CVgCQ`Nf96!~}a<
zEoH$5`1^OJ)&HjqZa>b-O9GsJZra)VAXe5p@P_x`%sX(hJGxhU?#?ZZ-O+s_pg`}U
zm}273oYvF*taJ)XZcjdORL*d{E!JX5{2AVH;4d<_PW8Kt&P(uTuES-Q_OkOb%Q}|<
z%Q^}w9i)-=)05ig7L&@4oj+I{5y1_oWgpWi$gA6V%42G8DKnq1&9<W?#CFIxkNpk~
z>(jl`_?(a}p$I|_3fs;4^|Cnlw(R!IrhSN<`jpzqrAt~7^UDbO$!W~*;VxMe3O^go
zN_U<5=&U`*eoY<pBd`aT6+sY@Zb_7pcQ=NWN5M^Wgy=~RQ=^K1{Bc<VD!(v!E9z}v
ztDA77>Hcr$_>hodO(XPC-*|%?;MB1GN?VKp8sK7Fnj6zn^U`MEWA3d%YWQx|+wv}c
zH!Fm9^mi$zXY|tc+LOWWtQ5X8U7aqaxk(}@iWTWFUGwbG;phl-ZVkA-_~S)hXCcse
zrZob^wvpZ2F~_97d6&f9AXG0addk&i_VpzDQA;h|)c}m4>t<1;mC2ctVM8%n$zaB5
zDxkKZDXz*aHOqm9+*(3?+{C8{2MV`LX{h9R-WMB$$uu}pu=gD|**d3oykg#G2Tngj
z$cil`WXXKZlh`^Cwj|9y0E@qPuIwpNi{!?QhNDyRUABr;nk!6BY$&cd?wsX!&LRWv
zW0YyF5Qf8jE{>As@rRqxzqPqnch4us_~?f1z<Jx;{>9qL3f|e6UOgsnR>mM}<kC<N
z*~N#{M<JB(ealPpkq>pQT2N+j=m#yYmzH&0<B$Js{cS3IQShMmttDjTk?~i7#HM2A
zKG|erN=0}Ez?9I_Tv6CYWc`2ay;W2kUDPewxJz(%_W+Gc6C}8MBf*{E5?mA9-Q5Z9
z?he7Bk>J4-G-yue`|bR4&eMIk<Bt2l7@MZ5i(0k!t~J+OYp(LDqk41L`_tuyve>-J
zYBPXlUX5J(TxsC+jap*<*GA6e<}Wasc?VOu+huHd?WF@5aDqIRv!YIOX3J+1X;=X+
z^#!imB0S9lO@83vpI{AC@u$ZQWn|^JDwi(4;q)K19Uji#U4d3J69;K<``)F6qbg&k
z)?)`4U!5WFxgxI3%F`Qc-R)ch3-L_Htn03A9kG^<d6l`HQf?dm(ty~!cKtF-06O~5
zXY&Ae+UX53WA=z26HE)ZZN8&-WQRPsA-QrQ&h2k3z$(7Z3_mDqj{nHcc5Zy>>N>UX
z1qjH&_5HfzHXnQ%GZKOxwbFX1l)W8<`RDhK)dLxTY!ZELF;XCjFB_JH4Zvw6)rk@R
zbgqm59X-LItNO$0?qnMH@v|)6l0}Y7YM4{Fi7gu@%sU?v5)!C)d2CcF7!woY(!MdE
zS0D90v!(HmS(l9YI%$Bl@weKdY?+$hcQ$utVK8N66j?KaNO&xrN7!h+q<o4<6%Q>+
zw;$Y7>sDO#+52{Q7rpq%W@jsSk?R=m7Bi|mqYYO!C03fPDAAP8+<hcZVJBy>hy<Es
z{5`(+Nf1uXWW5U%oW11`X)kkmrox(WO<)qHvLeEy$1B`vkw-%+69$*5o=Vx#;!The
zU<%&uS0lj0Fp4Me6Uje5J$(*s+JvjEsAz}oxP+g+R&|!^S?rzr#a>uM{<gN}&Yj{g
z{_6Tne$f`{G$?Zyzyf1%ghj+<F#(`V5!P||6?8ZuR5Zn4IC|W3;bnWFDhZ2({i_P&
z*y`d(=!0>ufTzjeanVDHq5j!A#l#@tI^v**;pLAnav{DCsIJp-7lK?q?>;VV6r?Tf
zlwHm4bvR#*<~I-DDj6nWf@o`a*3z&RzX<`{n`YbwTJ;ht+MslMxVn;Icd+_)sW074
z4)>{OZr_0n3G`=ufo&6ei)@=^zcp3VwR;aHmDzG~v@7W*R&kfvQv|z>a`<d80seM`
zO1aP4m>)AA?e{ThZ2w1Pp{O}MXvRIytcaQG%KdhLvAVixf|o7WW0X6n>?m$gViZQC
zeWWp{+pH1ST8oUI(olo(A|#VCvD6{!q<=<lfFuOrH(5Cx;<Bc8W=Dr;y=V4mhw}QU
zQ7eDb#qRLrx1EK^zGDbK)gSX%C6qj}>f#{d8D7Nf7ySabz`!0qyUG|HaSs(wK9vIP
zh-H~Mm{Aqrc<#>O*+*9y2M2b5<YHHz7mBc2W5{R4MRd|=%)rQk5AMTOJ<cb+#!aOF
z(9Ie1izB7j(|NO<t#$u#<Bj{sa!H4hT54izK*_>4%j1!lYl=4^9A~{}f<Y!Tp69h+
z^<uJn25B6PIzPx}u#>LG-)~<pDd~INJnT(|4>eW>UJLTW2`ueMP|QyGd$07yfvX(W
zEw8)W-N--Vz@98iHNX8<!~V@u`rN{HO(ZDRalh>$U*Vqnfboh!tWo4ryi_;<59-)r
z*x8aW#lg7kSxi^~=H}%3Z6}KOH@!BC?(6Q3@jx0BaQ3MW)~C-W#ovsxyCjS5(~~fB
z8IL<m?-chBaer*7`gz^M49?nIo7cVuDFM@RJP82dCU8QS^r0{Q3S2t}2TQ%Z=k8_D
zOaodau+j4>*;nwIp1bX+NlwQbGR(GjqobwQOqB;giQm#xGH76s$W(ru=vQ6zU0Oo;
z78}#nI*y3g^TR@2!Kb3}6`enH?d?`>oi^NsMLgXX&xrv`82T#i%~Ve5Wsi4C!i}F!
zmSeJNo{-RqsCspO+#Ju;d)LJDp+u+W3-yX~xnw@CBWU22S5%k~jX)qz{<|eM5E@${
z-!Ul&=vR!+!$2VB7EOSX)iV$F$>g7B>)Q$$gJNfhr#0aXUuAxW;ob#=CEFE4EZnVi
z3zy+m%l^+}CcKqjxbkVCo3gRf<A6iC(`uKT<U?63@yf8*7RR&}dM7eUcnpl@Pa;&R
zPg``Y5(~Aih-8k)_hAF|-^B`c@)2)Qa^_Xp`HPuqQ}0mn5N%brf7(P=m0+@Pzjp^y
zU<+X^=JyPSd)7oyI(XlIjTrQ^wEsMce&g@oS0(thwAXx<UcAL_D$&hrD!q-)(BEFC
zY-md?!2b8M=gwQRiNphkij$Kqjrs3y%}jTV9kLFdYxy~Q-LRd#nBTO;Y=wtyUM*v6
z^qSrg@p}CXyS7s5zIk42ghtdak{k0KeiCsZK(BAckdC6Q>l5=Kzp~PHcPK(--4vSD
zXqe;;_LmX0KLpNDNyk^W+80vSYmAmE&1AD>3kdZ&%-O4ke1EG+Bqr{=&b227@xKiH
z<l(gFx}SDRGYA*0Lbgf>S$8i3Zn!PF3pd26;X*dI464wM7?mTF({lJ<4{y%rsQjLO
z8`bb_(Ovv>ThW6&$}+(348(TXsemqMZH{u**Vmuo()cvUVz@s}D8LO^tVF5=T@r|u
zVpVg(G_|gYz3B*ts2Vr1Rrf@|ETr2V3HC@NnEeL9L449{FL;FnC%QadpL%wZW&#38
z<{mI9#LA5&caDsmMUciVF@=5|djJRb4|8+dt$+S;#Qe4?29ev-6u%yI0{B{s;+I8v
z8prb!!M)a-g>j0I7O8jY1U&fxb;SOJ735ha?+*14GQ_GWl3dhkXV1QLX+dmxn!&Bj
zI#0`aMBUbf$gOeb;+9?FpPHQ3$(m_2X>0`otha3>Wgz$&<07}`-!gb;@dpu?$b=DV
zz=Vjrc{w&@J?8RT#z&KXexVz0{_qhxKX1K8@0{OKR`^pcA@(OD|AZ6A__3{d2&HkJ
z@yx;ZCXT<gw3j_V&f{T|cZ#24u>G>@X1G&s$#(75^N$IifIaT-87TZ%yS+F^+)nz~
z>l2)JuQhYc^En_jscFB8Gtn~kVJf+iCsNOJRx0GtHqM{pV^(3Cll#2LxJ|h8mfn@w
z)8TNm-5jPZlL%sSeIZ)A@pK;l#loM|V5eS9$dzI9aM0aL>oAX13)4G#8h1&XTIb)U
zN2_P>CHzY;#^<`c&gG_wp;cO)OL!D7+R&BXg5~RTvNmB~b<|{`0oSUaBFhjh7;uyB
zS5KrGV0u#+(L?TTIC{j9#LzOCY2*HC>RyePr$hAdo%qw}&sm;Yp*oh)>FMs{cao>%
z+n6ez%NHK|pZM^3My^+NJ};qPzqD?TPDMZ5z#`<3+<%^aN;|Bh!+}aE`E779di-#h
zrK&x-3o9xc6@8k3)^fm9>;5`BoX&&$Ld=GqE}&MUb@_T}64ikF)PWI6ywHc=&Oa7~
zl>%KaN5n#I???PK^x#VK?&dcGf6MtTN=P;v^n4s_9@v;)Xnk`%;MQ7I@`M(nv7dzK
z-4T~@1I<4x;87@jY*8*h1%%C9ZHoH|%)tVM+F*Lf_I|9TnRyi>x4JvLtJQNL<$H9>
z=bJ<UA$z%~mf7(ySsNy_D@vC5=C8ACk~MdP#Bu|ENJ?O2mqEH!hvGTPOg{09!dE)H
zjkSS%3L&|h`H3jFxUz(6v~jCG_&vP@!1O@?0Z?WWUC(0rffoVj6dsPnl|JCSu6sha
z$x)URsW*58>3LZF9AcXjgLjlO4D-na@Vyk%Pv6f(w)#~o_2i|ceyy85mKiQLFn-~J
zE40R}5sfIj7S8c>{gBAvaq}?fql#!&MvYHwGs2W`P4g-~tG4}C*V_1XbckzOJHxUC
zq-hrmm53z<qjF}|Zz^bVY6s9mwwQk4?Avh)N${SI>66G3MqjIRH}n;Fyj?N&Jk&x2
zKtp82lfKRg^o}7SODmzO{6FUQ84T`hpM5SZbXV8E*O7oT5uN%ze|x;!4N@Z2d*<~@
z4&i%$cksPMFMhA-u4el@V)C(NZt!ryli|0rcWKZiuG^F1r`_eaNs6>GHv8IHI&6QR
z=VO)Gp8Kt%d(Kh0-L#QMJ}vTf&vjnX`>dT9{w*glb0Ph=q@+(n_k_hOGlX!@J+$vW
zY7zB%o1$6@33N<w#T6;l2(n*g`L8SRFRD8PeEe*SO@XMeB_{SeXU{i3ldn4$TKfC^
z$^7HP?Jj*FrP#(wzT{?+<1OvzHzwC|PAdaN>l`a_%%%(A5f*u(&i19$+ns`+r*Yhr
z;4vm>9j{v?|CZO_!&GeQpX9B1qs@oLFV~GNFZ*IaKUd#TJU~OMIrR4B8Xx;O1;JbW
zc59@8+Z#i`zeTsmh6SwKlXTb=VA%i$sA^YStuH6^3;)&|Q=2Et{Z^8A<ble{c*Uzh
z#Uh{|D@({^gl^*%i{m1Penz@~mBywJwCBrU|9i$~Ou?mptxz^MP5pZ`d>K^{R6Gni
z%npv`hE~@Gft*k;ju*<t6}tca_ER{tuslcDQz$R*6q<+vl{$l-16x1}y7(v13@vs3
z_nPPb&kr`<*8u)8aa>|z<AL%a9rZuYq1VoQp-h*N4+zvNCSzx!gG##nm-zU<1<Iw%
zE-g;nI-v3?HQG<*K*oPeiNTR}dU!ap<3wSEpF{fh@8RKyIGq0&zpY@&mXw6VO=xql
zs?e2s;S<7}fB6Tnuz<?$9Oj9?pi~f4n$C*CHk)QL;BW0Y^zq^R+jIQ?2mkM}#zm3#
zcb(51e2%K>W!!G*d7!#*H&WQ0R@r;33^#gJXch#eX8z#R%>?my__UI@_l)@usy|;h
zS53hcu&S?tKh#+7<H4IXrg1Tj3m9OiWB}WbJ8B+AcL#s96caGX1!b>ES;!Qx>WONm
zd$@Y2*a<_6iO`!YT9@~sMDx;Wur@d#QCo6Ku8D~OVARU)+jetjk|@UorGNRVLuw7Z
z_L_3}rN^o>O^2>R*uoE!_HM-a@boRhc#U}`FBiY>1TpqRV3<(y0fq<wO>C+<S}uSa
z3J5OtJrOY94u%9f7_}vBoGm+RW{jnLAK}1Bg=01S%Llzky*v52W&r2`t|sJTh-p43
zOwZO%)~z9E#L!K6hY$U<n3n`<03_A(yZK?g4C0c*!fFR=BLqX3#f*b`+LoH+eoSC~
zm3~TSim3|-1sN1kv)E#09_6@Kj(>LmZbb{m^nDLq1KgX!<^+WMM7t#dEcKOChH!WU
zXHn4#+_Oaj4WHg0R#XZ}MZQVuTGaothpu-W4JT}4M4@DM8*L7NF*TV_O&(ZW5~L?V
z{SxJdrLd05(ih)&ICfI49n{bqVN*4a?+&Qj`9NV|hFz{nrU%VzYbr*Z1F?m&aWHZD
zcke|k-y-o7qp{Wtx4z45*F>=2(5_p;=047xAg^*kvpr}AU?0Yn|BeT&A%cENtiSQ@
zmq@^7_QA{yFV0G<uCAPi50#;FM0PC=Djy$LQQ%~PtC2_-Hzf#<EUj(CWK_;XiyTOt
zYI-(><{n91#LI0C;%HFC!|DpsuDPXrATj|*&rem!DjMBLxO}R?A;mlpB(P(l$Dy$?
zGrf4cc_%1!p_`6PLIp8j=0R29o_C4T0<wJBc!N8V#K0hdx2fN1NDFo&?X0Qe+_vl-
zO5h>;&0&KJ-L?iK%X~ghot=>Z0=Wd$TADr}six)Re5ByUrx)b>C}M$JRiZ^bJPu)_
zb4%~{%}p(g7C!*G4=h!5PQt+m1{T6D>6?7oZ@^#(B1!7gqRg(eV|7&0^H_J;Lmr~c
zS6Ny*pG^L$Q!0ncCt%&SNGA_(lg-433)rt2Jb%7vK6S;o_Z$ZJRkrZ)bo&-@1KIo~
zL5dqa!6D^?^9`m6bU1*Task~E7;HRtsOeObt9=E#HR1Zm^OcvD&sTLjq?6vTDKx0g
zGuuowET*kMNd~N-%C3A6u!zlj_)Z0ckW90<50k~Sf2cJ_+KRsz5mP@@psT^WDA9fr
zqTx;r64V@1;oM}NAqX3W32dNoA72j^;z5zl{E~Qk+JXe4bGC<0M6*tO%mavh+G4@w
z-_2NT^EWlFg~c!C!3P=|7Tv)3aw0%UGl{fx0rPBZ^|Hy2Xsz+5t*@wHOX}i5bUrnk
zc-AlAW*<A%Gkr;U%M0ctkYv|QoL)-T(@SL?{Al64OW1d5K*4p3eNMf974=)uCru=h
zx#1CU=^o!v7RgK>)#Q4w+Ksw;URSfT)SB;Mk^;2dx~Nn#B*?i$APN6kY85$W7(gIn
zlx^0v+gx8Zxn2ng0NJ>M!(-2bN^>wuR(#+zv)u(s4#2nMd!HuVcYhpnsw1Fp*W)5p
zByE`v(AQC$ijsRaf2!OB3**@-Yw4O^_1wRhX~WC`gd3tQ1siA=uxFpmwCOK>jL8~N
zK?$gW!X9qc=4kdUg^~};=PvV}P*Qs5Tg>|mgtfJBj0{D~->qFA_ydFe)|}-M!VRVA
zN3QkNeT$_4-v+*DAsipR6Po%ES6uQ|{SDo(`Qax(pPS^Zre0NFSb_-+GJy;|p}9a}
zqXhy6eND1L1rCV-GN63PO|{d8Jbr@939b)KNjGIRlL`I=@Wr#2Eh;AQ!hjAB9)$@t
z5P+OEoU@*mYpjabiVi?URffU-JPO~Er`x>JcUFiqI5N*9m;WV^Vna%>{>NBt6YSnk
zR=ra6;>eI)Ysv64+Oh$2%MhC;NQ>NVL)#BP*-&OugMdB_sBd8Gpq&)s1*)?9!8oWs
zgBgu>n#Y_lWlY=c!@t^r4{}g^36-CfEPM)Av}kcI9*9cR462R6EaboPnzL@WR@h6#
z3-<|fuc>Eb0s%lc*4`m?gXnk2Xm~KlczU@scHod8I?#uSLja1Qc6JMQt5i}6cl8?=
z)JDAtb-+czP6RV)A-D=PLWym=l>p>YE1&M8dg9N;Cr?yoU$ldgEugnp;dgxCuDYCz
z3>zG&GXCw;+KwVzmA;bY>XHfFDM-JneV(AUY|b(W$Gb+uWjY=a!A+u?F7RE|y~#4=
zehoO>uoS)YP?*o<vl|n1tH{0~hx(qfZY%M6dg)*bkyh*FCgpqL@}>O3Iw}F~8Ic57
z3{||ECPwIeXg>%~f#C3#)X1ik6(*Uul@DNF$wd*&hPc|_FUW!$m9#p*nx9w_IpCws
zPTePIG(tSmE?9$~WyvR8wZ=qs)5`T(71l68Buq|Nk*ecSk!V-+CKEycY#BNBv}3W=
zGA*HG?O5z<gUZ;EwPj@crJZ73B*%uM_oFfw(H25K7!Ut-9#VfZl(h6v_BgeawSfpG
zAWp!XP0lEDhbrb`X9@u(NZP4Dh2?CGc#9_CGp5XSL(X^PHCQPlj%y@`DqnN>XEWrZ
z&4f`k<=<U(6|!hLfU`R6Pn8E(_2Gw0E99k%+d};VJSD<J%$Nfm5VT4eRZUIz?i|=A
z*qJId$^oHL!(Xyv<3&8{Wwa0iwKdfXL36_Z1l18nUZIC&(p)ZC4MwCo4^LEjWPnl#
z2Mm1v#^o%^Ok@eZMe^9x<;5!j4x1373X%EhkGU~rTWggb(TmZ)t4r)ScQPOuzrD;B
zCh(}&WBVzb9{&`}QNQ!j@8>hje%kUoH5e);wgJ_`pGmw-S7>5#jq!i)kS0|Yf_C<O
zru?{I9{%1y!qFCjDNUUXVtF@J*$lWF2hu~Lhp%<MuD5(}e%#QSU&rDLPixU$Bw*hy
z90c5JTy;DL!@9Xxs^Hj68K}n>u&s5u$XsO#R`GHE>5Ff3k!jeOm9sH<Qy-4O;!~46
zLr7R=Ijg|o<?XFyTPm$=F>c9pMcKCcJjKg&9pyp#LNUKiS*$i<mo}iHUNFUJdrnk(
zgBfFwtHCOi{4wt77j(k4sdQM3u}uMM<uPJXrBSI$q5~3OLuDobL=<!I*tosO-(gnM
z!M7t_w~+nR*-Fp!g2u63!WLZJ<^FsLA{?_--39?Ocgq}~@?QqMmi_vSc8b{~Oz6hw
zAEqzVE%f*T$$rgmHZ#qC7{BtHBqSxI44abW#Yf4<#-oN)H9~5ODjI~%u0{hrzaz$m
zr2_6PPF7*2!b+3m%3I<Ytv?>oMd6mdBSN6^Zhekfy;WEy%z<^$dW~$;b_k;m|6^?A
z{xin=lrnu)dp_!A`-@?oqp!h`Awln0e2<e_lf=Nt#yY?0N*UoIY#^8A4$Yox206*v
zz%)V457qy8*s0V!!a4|{um#+D(Zd`WY$J87!a67*0tQsM4b*!ksxA?xx6Xd38?@-e
z)|nm*AtsPB2Vnwnb`A6S!1xje*t8mzV9C@{x_4bf$Te4ajF2|^w{Kxyqxz#*P<8ED
zJKfLo1Cxur+TK@SXJ%@nXDaJ4;B(G|{^`;W)uASPy&j6<(MW9;CLA4+CgvL`GS@`X
zYEno*R8`>Nr#4TCBvkwC^qUh?Wh;XYtwo~?&ZZx>dNXsEqVdfD@d2{dFB<GbvQ7)1
z;KjC78>0!t-?MP<PQBh7n38@htg}hN9L|(oZL2lt!b1*ol99T)tH6;EMo}Z(q0ov|
zZ5wSHwKwPmGPk)q*uIx>EK70!J2e^&$seHNZz2Y|=z{`zowc<y4^voiyUQgwCdmgK
zI3!Fqn|AtBdNPtIUzp(m^i9qMVGrsmNW_s41=bcE$CN@q4U<M?GHgV8A$(-ys&_bU
zw~x`5f7Wybysgb|jgk8rEm(KnXJ%b2%4$1)6Lp9=ZisHaQiGty10|brFIL}rv|obd
zkqsk>wKZL(^_=#A@JEiKmHnoj=8xDKsh6VMyrJ*P9Ckrx$;=w)q~6}%KoC9#HMTvy
z1d8Uj@Rc>{FAeoy#&Z*Dnj6+ok*>&_CUc>0i(r@n)gQixSYp3He14JcpENX*q$j=w
z4>-0zkM@UPB-eD~G$wO_Ey&H|g`RD45_^T(6*<0YncApJ1@f{4j53D1Ia?=-=D-Dk
zCN5MMNgX#iI$e?<RL5FNF5$jY;F&qkoYw^*N(D}9G3Ef%U@E)OvK?gK^EtCEO98My
zFlOb`qTIP92_0b~U6thA|K09a-6rE71T?Tyb=_>~^O^OG>15Q}-wIl9sh4fB-qaPO
zOr+GGo<?sg;4;v0bQ?npKG1fBVRsTF-yOm+FdH?<v^BbU233|88x)25090_At!-8p
z`$l(bah22#x{$4tu@RyEz$9HS#AL$kMv0%1x`!4T#MrztI^0viP*n&)gbz#~Fmre0
z*|=@;KE1dP2@wv9;~DaV59Wbpr){DmwT@B<n#5I^_A+d;s%KLDJ)M2?iW>JXF30xw
z`$r2F9=4zP|1#)s7+d6P{$q#e7N=jvVe+WIOsn%f!S0HS<QCxiD&*1uyo&}!KmTl_
z%)<8Z$h{!pwsQQM(SB`oYP`8SdqE+h875;Tj{Sl>SLwj;H9PCp`j*?TeDZ<Q<7Isg
z-_UUpZt9_L->pY*6Tv6vp`Y}j)oyTR-twA*j3MrEe}VkCmbwvJw?02@=i~Tw_vrL-
z(%H@*{fqPWHED*+<UJNVqW-g`@2hkxmPYnQT9#(~uO~ayu(*yw5*NY_-3ZUz50M=A
zx9c#3qs9*n>&9utAKcz|*p0z+W!ODu^^Yo0jFBt&d90i%$*dDtXX%f6e6nWW-UB$e
zf;+SwQrAL9v<oZRLV|^?vmn#>c3I+`cHm4rOIKPq;vc4;b)tazQ4)l3DcYSsJQmne
zA>pl?OcH5<956yWWMvBLZak*%W1C;YX+|1==LhQ=rKLI89dtTIOGeeM2;{_bMikOj
z=3x#B`mb(<GH6+=*0Iy_H4cumx0XUp3pKRH5Z9QPN_O622gM)Xh5?(kJP=?k`>?&{
zNnf!xpPTP@U9^vB+m^2K>+{E`-~l@!ouYGXVF4lgTU0PRaJ@_6rLwy>TdX`_+wG|J
zPkLc~EKE(+SM|szqTWkQ?*hx~xEp$ME2a`}yDosJAHikU%fmIy_v;wx#hYN!*4G!`
z?G=w@`^>Whqhc}06v^1PF5uR5ZyqIp7Z{KX_W4Qi5xc~XRsQ=@)o1Agv@?9oDlCFU
ze~&1PI-{!vrCc%qNAqvcAUg?<=T;Wkev7Hdw!sV(*JoW_0T!X)F@^bSVVFd4rF6tw
z*op(YjT8&L_T#l-;45H2N~=LCgNm)cNvA-{*8VDd6U>wVKQXaXKTdjQ@eW&-l|_42
zL3zznH8gUdskz+(HjpuCQBGqyq~Vnz9b<XQFeROrmZzvoW*pLFj9TI#$aiZj$|(4j
z`7lYb{oQyJp3eAk35X8ig9<Vpy`bGPo_54=@Vd0z+u*v;#REZimg?**`k2I#ugERN
zbplpOwk9d7#`$_pt20*JHKE|uRxWoX#|&|dA^0VkuL?m_QyUTluP&uBc3HZ>QI8S=
zzSh%EuH-n9^UGu#PE51VsBqm839BdAw!C;?{;;$b(vA?UodLZeG<A);GvkE<XcCd7
zUWFu^{pwDT8TAH@_&{pOj1r{IRTRFz^sw4n5NLCh+tfZD!OYXZJ#m1Vn_j7(OvD_i
zc+y5I=r^`1E@Xd?n#B%u8>_voYMI%{2zm5W=Eux{nm!~J=KbXTPuqL}cF|AvS@zK~
zZ$~qCEs;2W9r|mRc-NM5cv6r&dRygHM3Fi?tMBwj-8<gmesXsHBJ(2sdUM>9fG3u?
zFpIBA8So9O@9^@%{Qd^~cAEXE)T1BEv-i_TgNF}-_~Xuu)s`4%tS4OEg}uf(mgiyI
z<?X!vA3q4^SKYbE*-HG<_R<5=sKS=BSllR=C_8N{->aS_Z!@J&_`r_}(YyeVhojz3
z=E3FVM`3MgSa}LOHG^bI<|I7A!`$GyHZC0@U_o0shysrTM^(_~`2A2sgA{Y%)S2lp
z(y@k)0FYgy7}gMvtle1}+QP$y+kUdX;tw;%d?ejBaN-8D`BCy>aS5Y+ybyL`O0E%h
zD)+~brhKV-23oTP?Xi|(yeXzH+l}KtCuE-xcu;9prlU|aU@9^MLACCZ)nQplIk~x~
zy}W$PnXn#K_{*ghLti1NRdU1gd^Y4O)(*H)hpSbK1BZ78z3ifUnyVeF?j|fG6~_>H
z;K-+Qy>T+1+WPYK((vZ_-vb+)3C<(4WrT+pwMipr<*_klDsQ9Y$<0g#F|o+dc2XZ&
zC5egi@^0na281+R@!mwi<3(z!9wNT4HGabYQkJlAS>LTmkR$h?JHjIN;iy|-wQp%!
zOjXK0(_sj3Kgoa1S%{H5j6~=@ao6?yJu~BMFHVWY*;nGe!mhKT`+#w*I!pYr5&850
z<7HR;{)#ZNEkWO@J&@x?abf%LHxc(AhicFXB47_u<E58he$`hgiS&T`OI(}(#^uv*
zh-RN<{~t!3fQM**>?QaQ8y^naIrR_YMg=$kiXPTyLMC2ruP$=gY~0+1Y~15QgN5vJ
zCdmU_7IZNZ_Td)c<>~3c&r`C*s4h|OOn1>-T#GeuQLmy3O$p#u6O4PDtGHEF(Ww+=
z7&)19ItF4{O4sNnyuJ)^Mx)xjur-JZ-rX2C39u-_10>!i9%N{tV1}9FYdNeD5-@?>
zip!-kgO^(?GmTJA^S>|C$pr!c!2~00vr4Uwsm(t<e9#U~J!KH103b3>C8IjNEt7lK
ze^xB-s6@#jU+d9hc41}BQ?$@;&KOR^E=YX}n@=+Pims-E#$edBx!$-d?H&#cYJOwG
z6=Ci6UbHhAlciCG*}pAWp+ALT4bk+FLPBOx1i(UD+hibBO7bwY<Sot{K<GHE8CdkJ
zjaF~vNB$C@;fJp}0@gMwk0}u|6pOu99nNFfQwVK8BY&-BgR_VS!?Ln$R!Rj$^H^=~
zwzs)*I$BM;0NuU}K6T({kx0(16wJF`uUn(;yiozHJwJnrEa$;VMK3t6FCP^ttwv?}
z(6;7xZaGgL$Or&HrwETAS31YFI-w$|CK1MW@%VW}AzYJ!*m4%j2{+Xm%`ozr?;(j?
zK=}@CGxlVQuoB>@`tI@+B(=DjiLGWmnFc|%OkzFJKC%!n2TGZ^Sox}W`a@B}d?bnT
zJ1AE4Wl(<-F_KB^{X0!iexKI{#22AGBp9X!f!<@LD>iJ!27BXi>FmQBt+F7q?23BH
zJfZT%4d_bw3M*A3Bs<;1aa8=(p<`rybD2a25pDj3mNm*1w!|4o-`@P1KtS2qVnv1&
znW3}JEX3Oo=5+cz4`4B*VV#_gA5&*RYt+Qi(>;BUPgmo>uTwi{gnEQY{C6+BL$%UB
z(G3<A_Pon~6@@N{(x7q2@|Y{7*A|Z#Ud*<Uh_y5WaBkj&c**UyuNKd>)6%bDF~And
zagI~|Rk3b+L;fqf-gYd!tA6GphodiGjxXf&r1~A%MPj?ZQLPAI?zrIe$08(BQInui
zSzYF{1^#liez(&p_2gFjCoP7YctN0uDia_XzXXlFmy7L<TC#u$BdsAe4F;|RHqG?7
zY}wGx$YAafWvi$(6|{3vCZeH@3ht@9+qp8D$NuU<o_4Yt4GKVC4JCK39vcLG;W4Rk
z0p{rQ2iQ^?!E-s<%c{Wuz(gjuFuN;L_DV~dwq{cWDnNcvFiAUI;i7E>)9)l--8Bp1
z*)5ER&xQAu7d)|({nep!WPY;+7#(HYChRJwuIshj;^6!XTx||{8|ydR@f?#H8?#~5
zHvNo7I9$e&*D5MPBkFKJ5c4Ed*;r(BvO#UOg5Y6)p{PKvP-l0f{LkF|6{&}N-M#jl
z;7{r2LpVpG{_6XErX~`+=T@m0=hGW#B^!Nxv~}g;b6y3u>PB!DBOB%Zd~+*wv%p@S
zlA>cr5MXkbqI#OrdX9pH^Em!dsg#s)A;#Z=zvs`gX6k~=CB>pgTBV~=Zta)~MiH6@
zY{Nb_*osLDWhJ7~B6vV{n9o8R^Ltz-S(J!cL%Kuz)t4VkfH&XNATE<drl#nf?+OVc
zQPoQ(Xw?tin9N)yE~=c_&_JOwUp?b!?rVDnB!4W3yO&OwU6$lXS5{TZU?=ug^>78R
zR?e`YNGm+Pb}E>ATSCIQO)<BTAkvq~1(n-#b#WusNu!e>W#1B%fi;{kP#r^^5EU)F
z5yIlCUce@$<l!g-X120zGJ{rkuU0Gyt~`An!Mo5!lNPgWXyk?ng(UT~9Fs6k(?p?9
zX~C1rDTwLPr%LPBvNu?f9SNJfSFnQobp`gKH45oz!USj>mOix$FbK7U{HooHHJ=Rk
z06QH0sB^fE)n7mMUn&UCX+FOUx)7eQ=ig~BB|K_oFz!vd<&n7u1SY`XMxG%085=A7
z%FSC{(EKni`}L+ssbVkeZa>|>miV$;Ag%khaYR1y-d7X+njw7YcUzbh5}Y;S%_cDN
z>rWw!&|&rG(QSrLMDt}TXTV=oLY(EUg!*LhHI2MzE1cu2)XKB9xL?c?`Ske(OqWs*
zD)Nwz?X^JW8<o;K!MpSdE-e>n8All;_}*N!yh1cMAh%FAW0@a|<+6jdLqipI3sM90
zg84SyAjJWej1t&7ek};cW-XcUV_Fy^xn3@Ug+q#$?SxQ<8Fduyp2iAt1L6KM>d;#`
zxzcb>z1s-k{maXU7BCmHiMvan0ILq|PeM-RcLg!RQG8)p`mOdAY(OQZsR<bAC3%8c
z74CI*2Ah|w8}eO;H4-(|v3WYYGGXH)rL1)RQKP?(+tK5&9E#02%o^vBwUoq8gd9`m
zO2Su&$pVl-3$maJ7#d=<pIUv>%)3=B`B{iB7B^>ZY@%JSC3PlTA5u36H>%!N^Nfex
z%H??fSXdH)c22<CJmc}c0bB&<x#||QX=Kt_!e_s0-pl=Rb|&%S6F$rpecgU~a*{p!
ztoopB*PdC5AW#+71pHM^&<YU$P_EZ<IlG<dF5_wDuR<v7G8Lc=o7R+yqex7KSB*4d
zTY!k@V&eZ`SdB1OTJSc(k#tsTt{g5DRG0I{h!}&OsuUZ*1Q2vEW3%R{Yx6^-rz(?Z
zm9HDqP=rwE>6by0%{2ZnYn1LE91zd5b3<^|;WWRc$}kndfZn+qr~+h}Ivwf>9CI~b
zG`|6`rJ6fEEw(tWpJx`W7s?K&>-8#{c_FoBleXpgESWg4FcTB2-U?S&n1Xy?QJ_9g
z?Ru^rx-GmK_8N=btU#=AL5Pu6g0-XMC{k=QQ`Uom%e=M)Gv>txXpPx=Q|QR9Y0Vbt
z{bwG-Z}m#q$2#PXC6W-a7UZyZM?3*P`;i)sHL4e~GTDys;t23OR^r!e7Aqe+D>FW8
zB{AOXEyUfIH$QZL5MUOuW%qBiH);@4E=7-ygsWkhnUUi}+iV|S>r@&7IxwN7Tor0n
zT@PxsFiHuv+TTln41WIf@}h2hQl9dNO`j!U>Bl5ndSb`n4A6RaX$;>_0aLZiZk$KE
zm0AU(h0DuHPv5~)5@8qJRZmq$0Q)DjCdz-<3nj2EU--(0*uuXmjFBrD%_{GKN(A{#
zNe71lFP!)tDt4AqybzpoOoS;3EY+8j$I4BP6$OKz@l-`qPZn2~B?WPW`_Vt^PynzU
z=H|O3xN#GBLkOD*+XIpe|M2L~sQ*@artv=w)*PG<&AQ^UTjCxGgx8<?s-D<)ev`+L
zclZD5Us=_o#*&nT-FYMN?r=}yNc>X|G&EVH-GM8=zIYeJ-+zOVx;_7X-|C`k<)GWJ
z+Sx}5NwCTGXz4<iBxuf$iu$_#1LWj3hh2Sr4K^-Vy(;GOI{X5^ZpVk&(Nui2Pww6y
zSD4P220I2@vvoQpZQ$SW7lJ=eLCKl?D452Nq~GWPptOwXZ_NKd<1>Hhq4aHEYty&G
zR&V>Qla0+X`h~~=cr~a@_NQ`b`x8~`tRGa4NEAe;>DJRzi=$xHYy0@fBkfbzZP@MT
zH(Vh8_%k4#bmEu`SzK_bH9JjMKicwLliqUS5nd~^*(PrFf&=ebe%HMH*TD$W!RV3}
zgms3#Gg{|$%SJcF@Q0yN#C3*i2_uM65pT0J;-tDqnH;bM6?RSng6_bR&r@-~W*9XU
zo~Lx^X#2IL!iL?$mKwVQY4a8(z(P;k@so#hjCdfIS_+#Q1F{03&hnyisF*l|_y8!s
zRr;dN#EQDGe3*&?$W>HlRMNwmxRR6xzF#)Cn5eQgiO;uHGmQpyp!fa7!Ba+mtRLGy
zDZ7}ePcde=ge4L(*Cy5|1j(LIkxw)XECSmtUU{)`HA%ZU5Q4eTM5SS1{&!?r)mZqy
zK~sUTc`Du%K7RMj8FuU@K2^Q;PZG8hxi7HmEubXK6;kio>U9j^6-jJ+md?Y2#o`<v
zbmMs~rUa6#E|Yr#dAgtm7k4Pq_RGMApO1`Ox=z%%BgZQ+6NVHshyz(0E49a?(BmhU
z%a{-nDqI)HtWAeD@FJ*f>@Xb#lC4}cPOh>&?%Z0A=om|<#wM83SiMXuq4!$M#62$2
z(VS%sU#pjhOPPdE(2D|+Th6S8{nk<AL8%*X7XbW|$@Duwe7>32F1+=ygh+hQYM$_{
ztDSjb?^60iKJ#`d%8{pa#rJjs0I;@wWoo_qF1ke}|D>JVSEYjmDD6i3KLsiLl6_9U
ziyBc4cL8(%=sWHmMIq@{n&w(1XY|<K_6M)eI@ZH1EBJSeC&BfV5KvmTNt+$c_#}mF
zXh$EdtZYGU{a#vQ3;=ruK+c%^I@KwugRsnL@%c2j?1JROnqRP-^|K*Dq<?!KYy!<|
z<-QgkIz%KO0>)<8Sq&PWUtUlEk(&8Y!L<CfU$6lnWtqn}&V_7hs8l?iy1yhI7x7cK
zRg8M-nQSL71nQYu+brEj7%vrIsstq$W;IBP@#P9z>Do2MW|%AF6jWBJ+~afq2NY^s
zP!{;EKRWogXcqccuZA*L?N2fi`yJkIO<1UaJV;}}6;)7yHi>b1r!e=-Z(t!5f4a|m
z!GvYIL13rd$0o*RW*_N<OmZr!X-pHC<s;yeMVJcPn8ei?m^r3I5loy-YTaz#IjaSU
zFd5M0yUYu<G%C$U4ivT)hr(oJJOFJnP)KP~5`JOwzODN&*cbfX8j*jzr8ph3@Q_<H
zg%NAeOQRT=9Xzq$Gz_LqA}fZtX_&jnpIoJRh9AxKWs)~5v^qNd3{EQ&>hhSTcZ|&=
zL;_D{vZ7s7XIvnD$Bs#@dM4)aE7J&E8-n)3`>%0`(#<VN-V@HNGL`$7;-3lG{<Zm!
zzoYyC%YL5skla@VQ-f1?+20qA1vB9cS-qWEo3jDKR4bpTc195wKo3Qf7ruw**SlW)
zfYTYirB^4b*WX5*(|6mgFIP}7{R{x0^^`rBbRR}}16qvi1(SVf?}sVsfRv=J)y$3_
z-*G-(SZQS*MV`1E2`)%L+fqb9L!pEYa;Qak;mpD|=%zgD9>afetY7C<?DJI&I3+09
z6kx(F<Slm$oe6~}p*!CmCh46U#>T!hj1|XL8Ij>Lzy{_MjbBYw!hb&23%j}%rVWt>
zP{pP(aO#qNR8UFp7M;wU(UaB!Lt6&H0+98I8bwyF;9}5@#v2lkWJc&=@jzA<2b>1I
zqxEkTg;dcjh!t9-In@JkU?!@o2SV8+4hNtfGU^o%tp(E<J8DD(=h$?DvJ%r6XJn+_
zS#b_IsYaK8%Tm`ZN?&0tFHF3KX0v<VH@sJcJq5x`zHL&O=0+>X856zxhAU3$h%7Wt
z&VUxJbV;>onPkzg`KzJX#x4ymp20DPWVN65+ZM@z*bD|B9DR56xm<4{v&XdfNdRkd
zD(kC_OOXNMuQw}kPkxjEb~XW|tnnQ%eQo`ke=cJpC=D0L;&zd)V5qnTI-OLy-TS94
zy~CsN6uZ4f<6r;mpK#`V!z#=KM3YX5+)GbB{~{VinA!q8EZg@w8?ZM`19-f#AOC!4
zt#36jG&|rgmK3$Rab@L;4usa`%6MXABu-S*9_y9a!X@+0?((Jm(nJN6FHkwi@j)x2
zt@GtA_7-3wz<kv+OmEm{Be2bf8Aqt9LuMJnnkTUE)GA}=PkE6Eh-b6<X)0&VVpH04
z4_6oT5a63)Tj*MP+OUb)Wbfmu*=A6ZN0yTJmml9lF)kTte{l$JpnTfcgbNQ{L-GU^
z(@7C5zb=(%6cw}bEWgv!*41z1pm&_^a*&&d9GI_EVpeB7KU+=juaP-b#SLMWsws{4
zz)Mw}w8qF|^H_A%7o~Ti*)&ShFqLv`f$4j-hP(o;vXMsX-j2m=en_R*%5+rz8yzt4
z<(gRzVs+=axV1H&_}aW^{xMYvND|n$ETZ11>ZkB|rMLXZRTr?>N54Mu9%JBg6LR~~
z{gJf&Rw#83oSb!d<6B$477#G#cCr=u3-*Qvw=wkMJ=BO*Iu`RN85)CdVXz=QwGO8W
z8=X!brde@EpGXiM0KkjUF|VKe->|aAm?nvGVpHLih<FWCkrWP~sSroR1nF3Wx~4o|
zsvlr29p>%dY4xd7sB>Y0L>{__>S<UuT0_O4H!~Cx2L>8j9HOGO=L_CUx$CwuiMc;?
zo$tIkw&^5v+_0k7qbX!^_EMJVppqhC2&R(COiECW7>wB&LJ@`xO<6mPI9EsX<Ed))
zeOQ{n%pK-sF9LqgKXStqR^osp$VXVr&Cv_1m!ObODYx=Ax3#qctZfSWZP1cDdRhl<
zY}7m3e!+ks=(Sa@kqzI9!$~OvAB`HjMc8d)(DIP-d%m&#bZ%2PeDrR=0)WasE1MZ!
zwUdQ?(#$&=PNqbdI~ka*g)HpRucRK8U8&f-@Eb2pi5R&1zD3FSYf!_t;7XiYT&qd=
zu!Km5iE6SwN}%BK+J8r~)z|j_2^W)UZ2kuV9l^YQ{?G7MK$Py2nw%pdl=mWIo?0iu
zX&+M#33am|NPfU{BltYIFKAaV_L-)P%Js7nbHiAlf%IHL(|(ASsh)ZMwG058{SEWb
z8=I=-$>F!(`uSvJ{|CG+q!k8aD8je;$V*%!sq`#qhU!@zMnef))5{QSfp1;YkSG2l
zwB#x@WSNv=v1aG7!cam-$H1wuX;{KG$#>Y&=yumgiEnKisITXBcNZ^a6l+H|zj8XK
z(weWWZB(Q89M+h(gL{uh_E<rnB+tA2QEcr4&upI<h1I0(w_+&`$-6j*#KDkI|0{6P
z@yNJak?~s0WiRl2w`rpjsTl`EJ^e7$`ARPjEP8N!$v_N@l7TcoKlJ5*@moiZH8Uvg
z{b3&L*`d944BuzGscK<Ud6AN}s)D82(`H8{#N*UUY;^CP+O4XIh|pLmjR;k60WDkw
zriW^AlQt048Yk9EX6G6*Vvo`}@D>l#)fngYNOrM<X;D%2GDCM;z+j6Vx%a775_(|z
z+{^~$Ljk`vbv@fm)$|m&$jTHpgFL*o%<i1rzZd>@WLtK<TO7JH4zpWr5YuPeC4drk
zysY#F@b(u9DUXK~dklXV$&-wA863h8do-lG$J%E1T^3*7|A4m3s_KARlW3f1D)zw4
zDf1>wpk8)zd@5P|i%YBw9$s#GXrVVjb2_BaPIR>Au)rfraiPLy*hE2t2962P9;Kna
z(7<P(5>%)?GtI4t26n29yR>?`3|cn2xf_fAWv|piWKI(Bp92cXb1aQH>S~26n7>*k
zNc9aW#`pZ3r$^xXwhKRrc($3$WsDF+3Oglp){<OWIFcOIe<vFK6NUIAy^(?<Aj>+t
zDMze+W$5ckSN@D4Q@U8a&Qz=WYscd!tb2M~Q3kbX+#YLz*TOQ4VHre4rb^NqKR@<i
zAAeI7Y~;;&$LEM+ZW4KrA~ir2;6kE4F`@%b3Cu>^%v@l==RE;XV=JyH^G4)wTgV$3
z<(j0mgM5wwcu+1HAfXAF=CTu=v<Aeh#=7zOs_6d3!P{lPbei%Pq|XkhO{uDhNi8f2
z&Q4{U?zxB3Y>~pX1EnqDQm*1cRnVLyNd&EL$=JxM+9NaI#5B*bLIPJGkAkDsg^lMj
z=_H%{(D34=N%{O}86t!U<!fn5BkeBk?@+iO7-W!6G4Y@cxwx)96lV=m(Ekl1*`Dfi
zo;u&6=~AJf-$IEkyYS*^q|-IOz0QC*o*S49QPvc7(nfRl!GOWDg8@wd9r>Fq%Mtv)
znR2hRn1+vJo~lrZpi^uymUcRi`O*=+E4n`3M6@VSH)^tV_xGB(3mpr5O1oDDu63Ea
zXDbpD;Unp5W#=Rr5p=jNG$?Cd|9BfZ_1SPTueYsTs*n<IA0g)z(ufhzbD++hv>`?J
zJmT#|on&z4o;s&o>WQ_b8?S*D6fm$X9mi)RR3_I~={~t~^riK{7PJIEtsob1p@<QO
z#c|JBC<)8>IO+=#_%S*{P{-oqWu<)KMa~%nszV~S@WAw0D7c&NL>uOX2VsZ3-$G^t
zzMWFj2yA=7bK@T{Wx3rkNq0MdgKPiU8{iB-V1`9(A;z&96}2g3B&Pi+Tp<U*{<->N
z1L&XQg#u0Qr$Z77`bqVp7Axa#u6fW;R>{9DCI6`s_<v~d?Of6ls!l8^IruV3{r4jM
zZ#M<Zp}KuJ%B?1Y;m``u?VpWBIH+^OfrW-7hW72hkRO2Vb&hS*>y${18&+_XNI`DS
zPrW#x2ickh@*h2ZU!VBS>$T463p&H0&7Nm18?UdgXR`%e&sOW9Qd<pc_M>Wzbc}Wf
z(ff(nY}Z36Jc;al6x8IWARUpqjzdd9v!Ky_HbeV-rD<V1P~-ExStRrjotbId7f3<}
zRgu#z?Bc$-Ev?|v&-Y;!QDT@ABHv3zYd<f2Ts_2!ggUR#CR*wh&%gKLEV$P+R77ug
zK2zHAk`P24<jZ;}OKAP*I?Fb=9)bn~-phU#vIlp+N-W{`S|#xic#%!b1MO|M^x!g&
zdMP!MVSoAX5x?$w^iZ}~*oFV;Xlk~JTbES^KC79W6vl;cW2KJX)jeWBo+ZAqOO_ga
zwW`+@_BaE~t*(|Y9Fvfeia(w45JXvg%$H+jiQJzkP7b9JRAS9;4=i+;Qk$a(U;tF1
zjJx5yW9AA?03_531u$pf!60f2B7}65R=ri;Etsccgp%%Jjan2wk6_0IbvH}I@LGT&
z`eKucRtri0D_K#&l1$in)?&P4`S3g*RHfmot<Ol46$tF_mb{&tNS^f$`r4vFh)4J^
z*^qD0ez-$Ap}8R;!Fu4p*QJCJHDh0OK5{Z)?@lVr_t6Rlz~!OF*u7i|6(G3+037?}
zq$D(T69#ElFtwY7)te1@j+aH;o*dA6S4Cu%h$qO18zr@boez&eJ$_lZ(QcEoKcHgw
z?FKyoe_pk!w8_PMR~Hssp?W>U#KcJqN+%0tSc6>4gVVdgWX@jEn()qEip~<s<{PM^
zT1+-9?vCr>Ij7Xfj!KmV*Dkj6Gor8^)&GUA{+IB>)s-TSqWH>xCd=1rNu-@;G8YF}
z>U%+r*3PQn^Z!Q6Q@eXB=b*A4S;`d^|6&bxIJCj7{=d@nT)>u`7R>T-mFbD<O06pz
zxc!D(W^8HLz=lFD2M5Ot!1r-F_xa@8d{}lgivN@tfDE>rEw*t@!qu=ew@9AE7kR7I
z%=A_rF9RMBnV1c<L#-Mzl{hafCNhIN*K!z5XJA7|E^!cFpT=T>_Fb^n;Fia0ACS`k
z95Ql~Ob8uR`2P7hjJ2X_SzWI)mkKQ+<xg7Z;epsZod}Lc$i2-opTL(lDsGc+;Xt6N
zD6oPwwTB_V&s&tzj>&z^!0X%^bG2An7jrrH{jg+tPVRvPs5)X`<cJxcsxCfWA66L5
zmpF_inQM;1g@#ky?=bi87&9BP7d1<G>BVYUN0ZwNgv71|sJC0DQ7oa!L*raiqm%*9
zL%1qKLqksO2GH&|U%q^S_91<_@BL%g>X<W4BiN465Jn0!X5NrJr9~dD2!mi@?(4tI
z_zguSD6G8`|1Uk<urTlXk~YF1t<iT;J+R&s{o5UE0$ekF)cbcvyssg(`X)Mf%>CMQ
zKoewZiTNR$*C@$IdK!X5ivftw0c*EeK0H0)nuFC*E%Amf*XWw^M(OnE^7kd)3`;*G
zaLYNHTreX?p}Cf5;6_HF?n~^@z#Kd;s_Luh-lQgTQStEfGO+WQNYVvnN8ixyO6e8i
zfh;}hcSCL}So!qu4E}4F<72DcJPm$wdw;^IPAE#ehH6H3i<g}_PGI%TO>kYZH)$~f
zeI$^WIICqqV(Bj0W?&$2?YQN|no~Rwm?~fEG>^x%L0@R2+N=r6o;NH<(a%i8c~-@+
zi0uyMOKEj%YbU#&vHyBr#w*L3DD_d!r7S*2Lp>=qw@%`u?=Y1hzJ**u`O~yPeRZ^b
z)^g+L>2={V3V?D&yc+(SX3>iBV$1XOu-AG!vzGS+DT~!ghHZw+za&tlcUtyu8q#k`
zcY`~<pn?|@q1`-jJXa3u*&mc!(KFW8))<wuy$(`zCMG7JeGZRKPFV0zX=!PpeLS>u
zb%}_HZ4#iwUQS|F;()EhigegFVl5VZHJJ#ySUbHY)zo@(@C^+D)0_OM2^PiGL}aQe
z)gFH<^Eza}(69M@1iL+9bpd}9P2Iqln`$UkEtd#@0l>3I>*Z!SR)11ZCo18Z`YCIM
zodp9h!2`&G<9xHcry?RFn8#+LlMAR?ndlgLsQBMQ^C+l#nOH2H%c{Groi)=7>Z53N
zrokTtc0KpgK5kT^<Ke*}Cw&`NkT0vPW7B0skDD>(h)9x_kx7<j5aePG{0~Zd0dm%8
zVXT`E_?A$JV}nYj?J)ay1+ErQvR^?o=7}``(4-1EIa=3SBs*M$!tWKZeRRL6i6>x>
zpwGywGd$hh63KzzJ?r119DJ=UAi^$7_2`C=qFJleo8yDN&c5dPfP@4Xp1|fP{Z_Em
z202-=n}zavrQ1Q_6h;GR;y8A{PxXF}4UNn*a9ePb+Z-x8N!}Om=gD}1Wer-qNwhq7
z0c|g|Sgs~QF)I>a(*FjO-9gm}lrTv5p%dx}iD$;hpQmqV*g%h9D{0_Tpic-xPz9X)
zMfE-!bzdqM@+G4gU05|ipwp$VLu{q;ERC_nRymazs`DZ~o*#s!c>d4KxwI9sotBuc
zRE0k7DX%OzQArICKvJ$ArcbE2(O}{(6JhPG97@G1_7>4(@+<={uz0EXFjXBUsOAo(
zNT_^0_wD&NeDQU4s3H5DU<;{qp=3qoVzT?|NW{cvn{uRbUtvMZoHYq&jaC%<Z3k!<
zlXY0bpP6!Rk(L`Hrq^@MD1u<~Z%?33R(aw}h}-SenR?1k+&^TfliBxS*WoA0jmR?#
z?2?E5AxOe0;{0XSTdC(J5;gCW4KlLsT-=@`G0`{-@bWr*x9)y^xoO%&<G<i3y$WqA
z48}o#%g4w6o-u30gkeReuV%?H`ugicnbnR-0syd30w*k0aUX|HRqO=4gUPREGHhGy
zF#qgLM-z$j`N+H&?Oidndf{EMAn|dsz=qq28_vR)E<-c#S7(R@d?5g;tv<(>$~Puu
z@%EI?!cABEe=+vX;dN|%|L{&@+qR8{jcwbu-85*D#<p$SPGcL5ZKqND+db#TIX%yP
zz3*Rh?R^c`%&hrnt*_xk*#c}cftJ})ftw{O`w@zQAwqeRtxP-Tjj_2y9~wmg2~}L&
z2MOJJo6krpSN-hspVc-1`#O&GcFLBEwl-_)Mc~}0?9PMSrhIFS{2>?HTSV}yEvhQz
zI_+j7NtOO8IpdQ0%kL9V&9f$7(hOvqb(q(vkJ4DU(36OeQ<CVuN`t9hD6NLpTQ!Ij
zAc+@LYB6FCi9q6#+DY8y#jV3p-R5#Cr8F{=ImI$Jdn=gA(If<wj7&}}Z%5eeIHdBL
z)1y5p?4g-7p;Q0Uwg&k9X)zmSapajWuQ}}ly=wqTUVhVllK9|&%c9@EIXtJgaSU74
z0u-z$cq!1!F1-n1GWV1`p<D!i&nU0HR~$SOL=B?p6oQ{JPaufw7{s$EoT{(fLg6}s
zFr>Q1YUaHPXR#FRcC*%xt(?Nj9+QVrxL077vS|2$Oc(^8Kh;kEDGK+Z<-EvFIWE)e
zU+s3$Z~ahdK1Rf0?OsPR#K|d<46aNaOY(Do-dfG}a~{^CqYRhl!Lf<BYZ>S(!f{gm
zxSXPf3U;$Yu4o?JCp|+&O_vNXrU|*_l%gEJmLSLWB}{r*oA{dFZP^X(NJ*`3UY{=>
z+D$+*TE_-Gc#J@XtC5jV!_6g-kywuWJsguVcUpt&e_70;6{~e73zQcz-QAR{dIZi-
z%K0RSW`SbjBJV<?VlKv@GI7u?3lm9U{V??~vOG*YF%lYq$_8+%nb&`~(2;e2cec5i
zN>vxWX8-0tN0m33%Q%n2TTDei{Oa$hl^Yn-ktigT$)KA}#VN>md4)kVxZan$#=0FQ
z*l#+t!#hqt)Lj)U+OaOo+n%kiCxOejave6hg{{<P?e8c-HuB8zt*ToYul*3T8joRN
zH)yolg|z;l`S3|2IhvYsiZ}D5<bkK>5+9?VY4WhDyxe;p#yw362P9#Co(g_`8md4+
z2KUk_or8{QL{dAkkh8`4^OGF7f+(l}(!#~00(d0102CMx@rnSvf~YV+qQs4B%z_Gp
zIS3#CGOX>MI0GQc#oK2d(kYs-9rD6KnV@CK1>0k@D0cx~<xWolhHCmxw&fwAfX=dW
z>^VGV(AC@giC2V#vuU)&(P_U7j<V}3IMb=tNh*6gDoFTR&5xrA)WC#yu$X3u>%nqu
zRk?7rCasw*pOzwrv7VORhMP6yN`vp0Z~6V7VcigvZsFJzW}oZFh7#h<v*cV=((!ZJ
ziO}4PNZvjpeu$CHHp<+XpErqhYRI{2CS+-ks#Bn5)N17B=QZ^fDnLDzgu)k+0Zs(4
zt`HpaG+fqf+<De8aWh>isZ9PzoHoq|^muQZ`I*;D|4UN8U1i*R{ISudLbMZm5#K2|
zc~!`9mN7-&E-1F?YGFz+04h%)styvIxisFzU6`v2`<ixsqq0)G#dnzM7Fi%`&u0rM
zo?FuW{e1pHce{4<73b}m@9>|cup!_5d(88HX9@lHKcda>sra4H6>C@J>;>oEk@yQ1
zjKc35TlXn_Eq9CE3GE8I^C~O&tm_}_PP!Owb0Q30yPo@(&Oh9fz0v?j8nyo6;pV2Z
zo9wUCQCc@7=ccdn+Pd1A{@|FK8hy33EO)*X&Qf-<DTjRQ^tPT_t>{c|o02%3xHpJU
za5h<syDvZFz8^i3J6b$p@jka2yE-+P>OibY{$X}hMLhS!NXCEgY6Tw(j75&%Nb{ur
zNFmj1;N&AMzQ;cry^Fvb$(!_HZh&>MD7P(N;xB3Y*QtI0)n!@&W$rss#U34?ugkpT
zUp`3DF{=g+nCeD&nD_AOyn8PUl#IpToGFr$h5igspLg2{Cj+O?h(d9JK0*<&R4ZHl
zBpSB(3N!ZF<h$4aT|2He6KjVNnP)5WZF;bhHHL$ZNVFE!s8U5pmeR(Qx_5L-%s6Q!
z&PF~SM?1+e??KJPkfhaDMpKT$uP!5k<|kI__S%rHL!P17Qb{+TvD&iadutrsINEBf
z?3FH3x{tQ4vTN5Be8tNy<*W~9XETPTksPP!D<_@gw)Blh#2n+M^4n=qQTdZt{tOI?
zC2C-aqDmCDwhtJmdNclfkqq@SRS(z^H$2>qE0bFd-DjnSq~FwTea&5V)v<puk>US1
zq6t(^;DG<bM+V*!S+$~$FboLjG7R#sPz7p)d&+8PMU@l4a*DjE1#)S11S&*+?0<5h
zMpZOwmXC0{nrbO+6wTw=5Jmx3`AdZYND$@n<PC2sXonS&^c5&Cux#P~Ng)dgua=rE
zP)VTtJAvG@D3e%@Sx|Jgg4k*ctKr+<n^g&z-zzpVRa>C(j0JI8c}5Fa_5Io#RXJX3
zd9~mihZ=A6VI+Yzp+mwk(MC6HTYAimT`^&=LQ`3T90S%0lY9^hHM8VfK;alhVRcqB
zJI%>w+o$mNXUy*fi!)mO;*{&1VhU+7KVI$-4T;I=W+@l<0W&nSRF<z{29QyJ90d|~
z4$uAz`UHu0ru!$$d+;wT#83t3=;epx#b-PzIM%19cuh6uYUXDvEBXCNyE2P^ax=T-
zR)PQn<xAZ^nQv*6S4dFn8I8>lxGu-9BjCWRF$}+}vFx7Lv#&ivms_5j&Zk>5O$3q4
zXt6OriuiToOx@Ndes<0PL$qn@Tf_IXePF}XB{Fi_9qdlve(cAp^BwfevjD(Kt7(vR
zQg=5$NY72As3LG;uTas}LH2Ui51#r~)by03Zy}tDNmSr5sk#;4iF{7NWPxt5f|gnW
z7!eO2-;%GTjS?I9*(6Pc>{y6?GrAfpe^K_@EUR2lWw<V8QC@6XSEb4v@Rl{stL0l2
zUIWP<>28F+7tQ!LUCKyI1r5ugcZ<qO4>sULl~i<I(o$G4sj2$$NvSoty2B0Tw9Ym-
zuL%&AqH#y`k{4)o&Qeyhv#1;r_!j?+Kbu=O8<dG8V57BrN;=spoT*5ziBof*4v?T9
z<!uc|(vnnsu!&8~QbcOC)00Vok(d|<al*&aY$7i-5EFdOlI@Ga0}=TDqKYQ@vd!Ga
zQ<DVv9QfvTofQ#huNCrnsEesy)j;FfukM>L9q=6k2AYrRkar$!Xfl}x*~G1?n>FrW
z%+D+xQbpTs+*%RjbvRgEM)e=&Yb2VNUN>=p5*r0wWNZk4NCpFI?K!ALR6DMZD#$QS
z9Ov^goUvCX6EC-KE14VyHnt*0stLWV_@}3@m7@ZJ%zjMRnH>c#CotmZrs$(fml1Fn
zAby;BX&nZ(9m2NGVP#Dh@nBGZ9$(9k$2;GmaE+oS#OO09$E31wv6G<`0GWx2-41UA
zkQfe16^=_gRQ-E}9*%ouo~Nj*m@Wpis1I;<ad>E?npv8OTMF?&x<>!f_YOQH3N2AW
zIivbp+MqP1txg-Gr)@hTxcg!#U<XqyXvIs}OHFZMku2Z$^B=)wcY{497$)y(?Jo@B
z|BJ^JIlnixZCk+hc6&am+2?dVRs5&V`|!tWKy5q)d<_B`d^!=l!ab`Ux_q@7#whT!
zT5QaY5`a%W@`1~(ue!@_3^g)#rsbzW#?o=_xGdK)4gtyAaY8zY-ziJdEv_q00sTl3
z6$}7grBn!CUFGrTn)lD6rpepMTUvP!{LtoFzpo@X=n+P<r3UU$uEH(&TjS82+Wy$6
z=A_pZ<WaVDRg&HkZNw?au}K5taqIPdb^Z<LCCI&{lB!82ka1JF`}Hx({`KT6?OP50
zEVL!Y!cCzf#AS3;lsU5iwO5wf2Sg;IPwU=}y@VvhAF}iFov(L%vL8LO9z8GnUpB&D
z81guD^~(1!Fo<PQ6mF#NT^G2vsj2vj17Z||wKh~uQ((QyT_<W|?7Kz{O7_WliIi<%
zD#NCLpx=UOyF3qJN}_5qj;=@&r9_TLb}Vt)n>e!Zl{qJuV`!)lfdmjK<&hBQM^jlw
zL0deE9hK*b6WK<3K}^=?e_Cs(eY>^oXl=ydz~{AIBuov3P>$!D#LWW+$*|_ljea<r
z(*L3Pt4%trM;uPQT4EI=8nIIXGHw97OMpg$iTL2?j&ejEB||SvVN^1n8j~i0#3-jJ
z%<Sg-UTzAU({gm)n3T?q)kK>2wEabfvMH8){u=ter^`Ixk1VuhY4U3xz@l|npy{-;
z%0U5x=3J)q0E}!=(T6fI67(240$|T0@)4u-*}3rTNNT*~AZZa6HB-&D)BIyctEos^
z-N#z$39dr1VYb#T6lag5z19d5N7<xIIE;72x+4;m`$SSUQHmod%u(tf5(7!;!@n+`
zO)5%x$@?3_r)s%!ux|B3*LF@<pMyI})NRAW-KjVq1~!M*4QpHL+DE((y4CJnj12_d
z(h?(F{>$-7VjfV7lhAoHajbCGSlKLcI(_JiDqr#r?5RgzLs#BaQKI*sNU{<#4Gf_Y
zFe(J4VD^L(sDE6oG6hK=MfGp1+1?0NE8MJ-)|nx%qUzuye&ITfdf;dX`e;X1gxrmC
zg|}ucQT<(YaoqD<0t_krt~J?rQdQL)CIesSBTlX4RG_<T1PgAN&vhE@r2m*=<B9^k
zu4b18pexjIpi@Eyk}`VXC{2Bfmidc0*%yjT>=C21`J;4Db9@Pzp?9AjChG^i8LuI?
z3K8<aPQ084cmlt(?dbg+a6)yYq+QN{47E%ZHe*Zw>Vxd_8QHI^m-C|CkS$e;Ma@QI
zKf<iEUf5yl#$uXk*Q&FA3Ry9|uKEW!DcPE?(P#*K?<$udnU>mqxoJBXwbu?xg~EwP
zXnE|po8|%kRl=pJS>~3w&!$B5TSkB^g=+9YSCiL=<&|Unb`!Dk{5c=B^E92U1&Y&J
zAx8}9-5BN4qq~6GkkR=W^Q4QC_AwiG8Z-h%PCLE1lNts-BI7!4FCFuR-T3g)v`$?$
zuw=WE25p`U(6SNCPT*f&;pnVi3ir)P&Cn22w78>Mr*PV}z8fXhlVRSfiu$x{I28_k
z9{8wY+XR2uF0`($8N$h{V=pUhH!guOSMY7th;WZG`*GsdDt<w$;gR$U?-OF3)N|9k
zV8Sw2>$lYz{v0LmkKrE^+rEYQNw2a2FUx$hRZ2uo&jyLG&J-syc<iDLq7y{mv)*G;
zJFw;*)pVJhlzgmVB5PXVBtozMSot`}MCAk~9;<HB;+az|)JTi840bKCMkZ>KD@J${
zZ@bAvR0UT`tu&`vcxDS2Z34HRk(EhuczSmu)e?Qt?L*DP4=ghYfE5A_5rW99{saph
z047Jxgq;>d1WTjMb|z{^AOS=GKH1rrs6BuGnGSE)DlbAAP&TmM+n=edd?_(DB{p6%
z?+6cRS_=&MiTWg##k{HJ+68ot=1*?}D_&-&rAZ|ovZJvwL5OJnC<(o1=&Y~ZY9@!z
zYj{m4<IUMN0XInj@e7VGBQ5IQs%^+J>ZfsLlg`8s0#z?j9X>s~9bnAnPoqwXiiv0+
zK*PWdK<6Qr4>4#!b5ohm_S}xGm97z*K}|LYQW}z0i0p8x9jSxX?4~aoV>eC0r{sP~
zp9r-wX4PQfJa!E_og}=}>s-DeaTQv(pbwE1Ac+YXzq^-TT9b3fN}7Wag{q~f&>yAS
z3|e6kUU<L0dsQ~%6TW4{{>8Q_cwvlASnd9f=(^`B^04!EtDO7mDx7DsAsX>OQE(N@
zC1I&5DT2abRlXg50VYRirErWtq*co+Wel}Y2)ln33n7?_pOtks!jX+c0a7?v7?M%^
zZO+?pAQ4mm(IT`|DwrS=7%}W`%kVm%SIVCY7I-abv-<2ZNWhhxsFxBv3oHSNso4(9
z<jocpq1bd7CBOpq_$zcRs|(@8!2NNAImxCjfrxvZs(-DC@moVp!#-(_vYk!f+PFO8
z{N$D2`0J=@a@d<=^N!L#;dsYsB3zcflW2Ok)G}!x*>Kzo8brflXfc@AYbLS|1j4XR
zkmFGF2pJF)#U77ghDu42{yGZZzE>i&$+t-pxX_@1h2yg4LfI2zbqGGxSSscDs~L`P
z=vBKH;=`F+gsbDinSu4KaJSQ^@JV4%4DI+KA5xTR1!v$&f~l)3yaYE02oQNz?EIT%
z?ANPN9g~oQI22}}lf?QdkTm0I;F%L3RjV7jx)M9X#L<%_*2jhWngK*1bp;X12eHBg
zOc21-HajH^dN{i-$C?ty2^WVkUh8y)+H*kdr^nX#;#j5z8ShDU7r0^?u#cEK&m39(
zGAPjcmAy0N``h<Z@SJNyaB2X8<gw~T{10WfUv@s*Jzm$oZVcjheXF9i3SY?sWn#vT
zh;GC2j!qZ1`9a}3Hn^+pqOJx!3CI8zxm0@0Xi6-KXYns|9d%8yQ>(Z>f{L3=-|{Uv
zaN(Y7dSP-Z7tSv5>@C7SE5Cz|rkrLrl2pAoVzEpB<glv~%GlQ)riMm!6jmP07$^k0
za0r5f;bvuaIoi-EPC$ZKOxWbydKoh|;0Z8-0-K)78TfHL;q(LLU-vPbw!^IoaPqV_
z92=hb<SwzYyKtL@@vG@G!<;S04YRe4n<l_{B_lP{KW&zawYtQ-!6uR^OfV)|iz;Or
z^aqJ@@=$U`f%f=W#JQOPp9>EGs@;TCp<<DBEBr=8H$qjDPlJYP!Lt2nOmklEYP)_c
z*1ETWG&D6Xdn065EwyK0YDIUd%GCVpvs;72S*a65^OtY(ngt><@WHhf#^z^E&#g_{
zUA56`#|<f#lDli!nRBCuT~^70nlJ5xh-9f+<axnEZY<4h8kR=1x|{H?M<6RQ_80U%
zT-j%Y$?ljiwHGd*wO=ByIzmxL+sKM}(|N`PProH%rdLJ)zCg7rRGSH@^;;{s`~70p
z1|OY{oy+r`g{~tHDS6JBG@}bgIdfVYSNNlwn$(!NQlrn4Fw_g4aHn3p)>T!Lw#S#m
z5j+cUwdf)zCDz_^n|EF3br0DqxzT@vTzHIhc@XWs-jVUg3m}5Z<Neiv!Zzob3Iqzq
zGh~=*0Mit<YK<{VD~F-_AAA!~W8>eL8%bTV0%gEMgQ1D~dI0QS&gc*O;d<hN8xk1=
zkp{R0wPg;KQ|vkE4yE@FxBwDhD6!a&M|Xy6mU23B58}P}xvc19I5#BnaHi$rPjSGb
zo>46&XwqzYZ15m<l^It|<Y;xW0nf$=woX;aY;7=~SE1j(>H_#~h9uUiDpAk}q5vDd
zyx?PY3i+=;UtkJlfU5_@fdBto4yrxrQUKdk5N+^fQsrUD*Obk~w;)0CS4SjmqBo=W
zUCV8{kM7qR!+}*S(7(<l6w=W!3B30>EHSXh5`1(lXd;Iz9UNm(5gudwZQQ>c<U4#*
z+A^F?@OOPg=Ycb=%T~1#XyQK57ABr$PYz~GtsfaFr}j9*w6%{Bpq#U8H8Z1CF~E-}
zZiV34s7G=B&*>G{hFZ(5VPg5`P0g3v3xS`vA+q*0+bA_Fk&8L6><L3(hkib%kbV>c
z?mGz`ecxMZoh;!{)yzk@=g|6Wy66M=TUWV&9(1`iz`-Y<U6&d7^4eFtd-J)VIrVg&
z;MTj<g~YRD#qJk+XD4rAR<g;xSX0{+&iwDrlgb|6v~K&lTkZfVD|XSl%2ZtRDGTKi
zcNVtZ)HBhN1>5JxzBTeDy1r@T%zI!?kp(*$w??zZpqFq9x&}!DO2T9TE^G<12WAlk
z1mhhRfG7(CYYLO<!LgM$V<{hDh23~;(~JyFQMK-|u*tB72np2&D~!_Hx(|YZRB*aY
zAt^&h$qLe+t2Xy<y>~c?9kP2@0<F>D8!0QV#xQ1Rm^3OY2ZeUI(vG;oEeVcM=Q|A|
zxIl{JlI?eiu25kXxH8tXi=wrHv8;{*d&OS*H0G^CN|^_8habb84$}Ns2fr4UP)O&K
zBB2*%qU^ig<rsYO@;%w?X2H3+As@Y?QC2U<lPb}m8z^m%7=N~>bHTTEe|*xU8!u&}
z`+ysAv#4cS=0xJLQ}H53rk8t=XN!?PI}Hm6UGZ}s#ys$csW%feclIlXVDhl&F|xj)
zTY66gzbMlU{dEPAD>}>FuUZy!0=~<lIjeiP-l6Bi5v)3Mj|%H1lMQG!xI=;E*7y0F
zO*&6P<$)?VFA5UHqLS@=TMX3d)5%h7L@&s5|B|*aeVh6-R|LHe&yy;Os^INoAJ6!i
z3~JLRWkq&EVLo$P5i|*=I(zR96Ho1sMDbpNIK0LoKpUPyAl_?M$f920)`|>XOLL*1
z7)DRAV@IfhOw;6>g{LmLK}GC4As9%|kyXj5FEqopfv?&zAMy<9AR~H0LV_wbre)jL
zr@^2j-RCNJEPHprO5$<t&0xFIcQ)2VpsNVfFez%iLRm57Znr@=e8LKmVL<K=q9wG%
z!Rq4O=QSbx!2hm`JKy%_t=rn5G%xD0(AS*dR8AwUdqSKVmsARh1FUrW%UL62RC8m4
z+jIOhtJ@lp;($-68P?#FXavc5X(m(=VR3SyH$1B(38tfaeqNs~S1+w?W+2|W!pgYo
z)!6k^F*90?EEd7u^eTH3R+PM^)vX=wtUNv5oIxian1vYu)oZSzw#?ct01ArF*NW=K
zmyQ5dNwS+$MtRCC;l62>bFQW7S~Oaa&7hX9$U~-Mm#4Be1T9?7tpG}<OP6N2=v)JA
z5eL<R!{rFaJ)wH7W7x0H-wx$YoUEeS*VP;QA-^<ALbO}IdOhRFXsPyIun<-=^l{}|
zV%4fSrQ8J@$*B*`WCSibU4OqXdP`j>kW8*|WtFT+)#|U+^XZM7&7mE|CtyBS0Z{mC
z_ZUo#NWY`L9VSM^0)0PKnueMfHkihcUa7WBUo4u*cmNYUw!gHBK)CQEd@b1g@?GQ8
zr4c-Me?PC$?fWNf1_E_~s@eb;D2y;q4I40U_T*^?T~JO&xB-gfoNc4TYEa%Up1RUK
z?!D7C6Bg|`*4tbjx_y;<aA6stq(uu0Wb2BZ*A1=|Xt+35mE4>r+_ovugTZH&#S==I
zQgmMqCK`Fo!@$K9Wm(X~L?w$wp73pvM_EkYF{MW69fn8J1FM$WTQxcOmA0-NI%B7K
zcj|SI)O~b2`wu{Hp-2A*9H>@#gR`wPb3gPD*2c>~k?;UcBaaLVkSE&Vw3pCbDbscV
zokDCJZZiD~5^>l*%M6X`EL6M(C@d^Eb-o2OSh84Jzqd*RC>YP)$%x$6rABH0&|hs!
zQp;B(C-WUB+utb#$IFC<{MKjHpu?MGka9$bUw1XSDn>B;TB&@5!F(9r+Q*8D?<uW4
zk>8sGcWe^?GmMC6TP44TMO)(MV0e73T+$jCJXTgE3^)w(U*1Du(=noWXTfLl0EfrI
zrVT(aAeeF~-!+<16D6%V8i<YA+%PIRFk~u8^UH0zyEeL(8=OXu&}w2O|0=2#4;Q4U
zctWjcCaxU_M7i9RqsZ!Ytvxbi+Z@<{6xm>g=FGtWb>j~DQ@Sce25{+zpy@smV8jn^
z2*f~uO_NgBw^jdlIbyI7Y_SM;k)}0BX=jARsbLde>A~Z^qj=CLpo!;Y4Jh{|lbx11
z%YB(Glgd}6XD?H88Zk;Fub3+d<XIZ`tZLy^KU9TQBX*n<9s<GpzI_4v*=@~1_2Jne
zS9>6X@gR&$A=52WjVv|+hkzU#*eC|uFgxa^`P~E{5$jAyw^=FMC{-NuH&rzKI@8*f
z)=@zpZ&e|L=^35<$Vh5RPRaJvZv~za+s}6MGOLzTjdn>YLla(6j6V(H^Ti}skM8+*
zLcHy@hL(9L(<1^JdCN|4I#5x);h%RXW5dc0<~a09-vPe%9E3FuPp>W-U2=VF)4O!i
zv*3GB)5`g)T(YV`f}TM~fPrT5JK%Hft_CV7)FaM2h{z!%>pbCKxC$Wv;Zyrov_}kz
zrvnu7zMEjDDHavgYF7eA4_?;EfgYJCj^(cNAC`SoK&sUG==&xyO*PL8H;+dP2Ck6a
zt0{ow_NflYmsWTJNEzWoIw>tYkk#KeH|V7tHCUbU?e0#{liom<6hMue7ao35b)`9z
z33b#|R&$hES4!ANt*6G3Evo-vQSa#~*xCBD)xtk(!Gdnv-khs?+<c0n?h;B1V=q7a
zN$yiOJdUYOrTYUHiIuW2eKy82#!YK%irA}EkF!m6u5GEC=|sj-ln9_!GF$t*yE>(p
z&b4KG61WYGJlIKxeff!uf4y*sJSoR<>Q&MK>Gg&W>TZa4Yzl%bx3$Z};5xZcCg)Oo
znBjdvDk9d-E_5_ziI9xc(^sn~>w3@gi*aNB06S!tE-d!vgC0#tl)2iToKDuUk7|32
zh}TyNHC%`&Pu+Ovtibl@?OPa-XK2NN(QG>ap_}t23C2tfH4|=R)N>x>a^NcCz%4Uv
z5;{hvVg!WMq{)f0QG1?16XP{o8{Meo>r}IV9Jw}Dl~KeSK8*<E=Pp)S%%0X|qmOIX
zYCc=kvLSFKhRHEvg_p?S`<NX+uQ&)eTi=2Y$s`xDD=&XDZQ?<PiN?fxUv25CkxU@V
zp^48|Rey3lB5FFZ!9W`z<SwU$pLtPlwY2xHnnN>s-}Rf_xdTE8h5j7_jr9q=+BjZP
zb(zTJw%2JQ0V2w+qHDgb#?^-(bpp(%U_81wnO(62FI?d1GG%ZRKDPHCYwG8C+(zgY
z!Tk{EFC(<kcjJSj5SW{xxb?@;fw26Ai2td>K1)5lV(firG~P`?_9d_~@0|~6rq3Y_
zGM6XwVRF9FR~Q;14GphXDC?}^+^x@P)`UH+qamL1(^q+{v5+$K_(SXFk-GFBYZ>-L
z4X#5;FJFlq=<=0&sYxl+4(3s98PL$nxyUh&Eof`bfu&P#tQqO(Y#REw0<qaLR3u~e
z*B>W;qyR|Z;1rw{MoO|}|D#8|nc{`807|x<>`=!4&`gq0(NlCOyR9*z9N87WQUg?t
zF1EHOOH1AN%4wEge!RUD7ZoY#o2F;WW(f$M4scIIh?3CrBZ$DzU~-rXkXeJlej_>h
z2(3QgM>UolQ>tL)Q4sO&CSR^k1IPqnrNaoJCs=XnJX(%xoUNp`CLpYFdw?~7H&EF+
zj$~w>>VrQkiD8ODiXIG5mnAOOx)h7zYiQ&i&BxniVg9<r(PNAF9EF6M06uQ+G*3xA
zjv&VI7j5614&?)g7$`ClR-d=I`=&X3h=r4V^nDR?-+C@ZTN?;z2+GbXhi^~2-^vqG
zrBWaJb*;yI+&^iu9`hoXS~qZ5IZ2It8Ne`jQ!>M59Jhn|4>39alxe5p)6a)c?X}(v
z#h~WAY^EKbJd(JdH~I$LUfKAV9bE@91`*nbeOlGb5)9iTC%C;jTC+H*o>L&Roud(l
zmg6=rEO7O4^9d1aPuPf7Ks_}*2!4c(Mxe3iEy=ixPQURz`krur2E6GjDe5m$(~_+)
zN(N*(P@2Clc|)j`JuuhNJ2F+9t}5ZU$kOLG`aFNK=!fD<NNCemhApLj^UKwVCy+)_
zvWh<4j(>eiU72l~Jq4SXX5R;qNd>aPq^P<FJboY>;pkfuiJI5DGX1K>_0YQ|G1n6-
zoYmngt#67jOMvS3%_=~RtSZSo5UZAUH#6#oaGf4;yH*`MU0Dj86pB)r^b%=D=37_m
z@%8vn>#?JGxBY~-raEd93!=g3xXmK>#^o@Yo_=o4$3+pjCZqkyKMuk@?R4$2(LJx8
z`uS8d5mr-nI&4t2$eQ{2WgU7f<mq+fWh>8yJe-E&OI%>W$?QFpy{vZo*tx7de~d$G
zXIj&P>ybIW?DA-W@u&%xH2l+$%oid+O$;LnIPAgeai*3}T-$JXA?6&}V;6D~DkQ9b
z5R12C0qqxO8d#bn+wd9(;z11uOI35rQpy)jVG`XGs)>`GQ3-uo%v+NUFU3jD;GjKN
z>^Q9%sfA4mNQV5~o1gTF!jmT@uQ~Kg;=EN!?HG56u)#Yc8)-HEzz_!7$h#_rlQt5m
zgJ+Q%<xr4B^URuT<?`v;_1Qeo%woe>)L4x}vq}~vQy6bbKw#&EMdC<>YS^O^5gv+l
zr6{FtOCTyHvB*>BC{dQ*+g8sEENO<)=K-Ccz5e<3vVPTO*DF8zL7SQx)({c!veW7w
zJuu@qord#SPqe(OLC69qC)?~rcF?UDR?V1c;5$9zP=AN_Xf#B0l*kCnkUrZq5Ghs%
zxWTqtjR2#+id&&eu9!4QhF8;mgNu8b7<LLc6)0i<8=o@)$bQqaw2BstMu`aS5LQ7I
zUD3Oj7xhRv#hiFkn@7YBjB|&`;IMh;&1*SiTkHo=(1#e0IR^Zn_A)0qGjlovhT*gX
zoym4+<{EQ+qwsF%7<Ptl2>`&A21vN37DRO^#YarDL)>Uk0_!SiU7T!IFH%D$DQV!!
zLRJhv&k|YZz_LXMllqV-g<Z-nEqpsT;pa7Di;9wOChVk|ksd`fiZ3jXq-3cN^d=ji
z>P{%#Yn6!nz{zUMWE}vqsY(?9l3i6x%DEdoKTqq)(1>J6Q2Uhr3Z&8I8|iFE<?NhZ
zjl3N{T0zWTGz3TSTtr*@Nhva6dI}ivu+F$VC5cR7MpIo{KdS0NR>I>s^rEJ?w`m6t
z0q*e9nWJ<p)M$NrHM(EcB{Thuu+8Em_F$W(sNC40-Bs*)Z8L$uI#{b50U=cm*G#CE
z*!$Fy72xp?k#4L(O9nf7?EF0(A%|tWpHCkw)Ov92?#L+#AuJz-;jj#fP0^x5#rwwc
z@4=i*(H+{>$GTrlDx*jK(y&?#1l=1A{Pi8w7$cs*2bP-)IM-+Vk&1)BzP9?2$zep3
z;Xn~M1x1nZWN1`A1Q#fMN$y>!gi#JI`)Fv|XG(6!18W2hE01G6G74!9QOeA%ag@_o
zr2JPU3PAqIUUn8!%J$>L8GGY*A3a^;FTP%1EwsAGbN2n#mp;3?q_Rl?rqjw1Va}hI
zIE)sYuIG2+CIdg)ZEt|@d%Qy)@)WK_0nF34`5%7K0uI;>dk#J(kgZ=anEnE<CO8-d
zldMqDIjAtvZ=k>qB5ZrSJ6LExCAZ1RkyLW<8PH(HG40t|+YDA7L=Pkcn(Q<L04pt7
zz7HVkqjv>FK?Ly}1%(SG6JEXF-`oud%3Jv<SuMaPVxwrG{oB@qjbe3<tSpxj3kpPv
zMT;vNT!R`Kag|SVPTYhy4aL87_+!i~OomECJXAFq>)OM^HKL!3QvA^XTC&mF@pUq(
zkz(JFACXYDd+wKODm|~RTG*L!TL}2<<|G?tsgljgmc2sFCY=ZOTe+*HYGBmzGJ-_s
zi^i-I*M*)346(UZFA=D{JG?gLjF<(rO*R<>w^71WZvjbqwV6H{Gove9BaV0g2$A@A
zxG54)m?{*|C9}SQ)*>AJF~^dEV80#!rH2hp$b;G@Mo0REj6~>hF}gTdUHbF3xP*k0
zhLk>XO-O<CraZL~@_Muw0t-QSbvF{J8I3VQP#mkLyw2f*lKw%n#W3&nG$6g6r{a>+
zy>xB=-pO5w@~W4)biOlxp9)>i^87-fF(hK_(-;7WQop3#E@h#UYjCY8rwQvfXs%e>
zz-#s!&Q_~i*dIkNFR}VyyPHS@Fo3hMqYqTC6N%VW1)$VkouJ7T$l1|#(TOh`?*tEH
z-?+MNy_u`}Ypt7XO9b<(S1U+f%PrwyAUaFQei9dj)RO3L<VTi#5;Ukw*mH<Yb^Xcv
z(?B6ge*B%^j1A7C=pDQm;2C1K<uZ82gr=m>z?p!o$aJ(LO9if+a^hnT5}~|DhXA^f
zUaIZm-`zzGEqkt+-7xvJMmhs!PZEVq^Fg5hNb}~VyA#IXD7t+Py)sp)*V49uca1>&
zA+lwOpZHb!gC+~D^+AUl*}D+g=k+ls;C&d1c{%U7e-84vUPgLf+|Yu;tjQTCT}Vd0
zRHn@Jo#HF<BMCEp2CrJawH&PiS<e6)of8QSvxLYS5sT&?*GK4oUs95KD&U`nnS^g^
zLrLBx?(rFqdg$;-I6Qbd4Qxft@r#((*&&(@ODPN6W8=bY@1)%2GI_m8e_`}DU9)!O
z+$)b>$J;cuFYJ{ve>D}Ei3h`AG1V*N3eIP12WL6=RA{(64e0V%T<`W*Nc6wgjk{Tk
z|MZhOzox%YJ#nLbSEXda@Vm!2=M>0GVHa{&Q<V=2#I+^_=dn@c0o5mDG-J?O%+4kQ
zs=6~yGZINojXkxz<l(Y}*mG*Zu9_<IUry=Oy?7<Y#TU%hYFd{CFlQ8QM9476@^HfL
zNw_uZs0j9iSf$r*1DQ-a23;OLj2I0WLI7|We3eaW`I7qKpamub!3X>$1lggv9EnB&
zIl*JCi7aC^04hH%hT{ALBbFdo8j2y%Ut0C7EjTp|ue_Pnn6=(;?F}DrMk5=p00LAt
z5igCU1^<9x>9cQ{Pi0p*)2>t)4MrD<QMAndp8El@bh!}&XYp!vM|ZKTw&7ap8eH17
zaH60xHUZ(O(MH~_u%BoT*_37rXu0bLyy&bK?Zc0O<_S<u22&h<E*y92O#VY#e#HLG
z2>aa_`~7!#oop%{m6w9jE&8MPCJu_VQ0b52Yc1!+wL)oJ@#MtGQ}HLOuGT-jGlOHI
zPCmn;f`S9ui{`yx$XWQp$8derfwmSzU3)bt{1$Y?I|@@&xVIa*ywhBnf2+<5(rv!n
z)s%=@0DGKKc2hGB%?TTMDs$M)zF+%M>C-ViG3eN=?W#h)-1*?rX-Vz6rN%p*9zVf!
zms;9JFnagcikgIc`xI|laNBm{2Yz*stD|fNfe*GsXk?H|?}TDNT!R!dT-gt{$e;mb
zAT%2w<ZJeIE^b#7B|yL{lByiKnx$y(g=FTPWoz0VVLcswK#xvrS71959p)^5v82Ks
zDJ<-h$oPV2C;i1pUo>4qg@EM;G%QTbPce1UB87NAL)I8j=m7)y3}XV@!QiW5L4h@_
zK@qwq465`LW8UD%b!@7pU$^UwSO*WO{|(n*N8_p8W+ki>tB9)V4YaZ6>KkgMMI}g1
z*K*c3!lM)=iA4&imojBo@GNmSKd>h%CqQ|hKLk!L&cgi;c)Ut6cF(?Kh)?nKEEVBS
z{!7_4@4n&uD+r4JCjFb#`!9L8<v*B>3SJG+PudAM<J$-#1Hzx9h_<AS!cV)<%Rs!>
z$<#;9E-`*jh{yT72=?6yBm116*TDOf1@r#9PJFKhI-rupswu_O_KSvofG(5^eO`B<
zJuBhgj7uQ4168VG*s-Ok2-Ud!{N<T$u?YGxQX`L~URFer@SOyhe1`5rqN3$dBGyoa
ze^MQ-XqJ@c5C10ZakpZL2BN>(nT5eT&Em1aLcf~Zk5x3{{2u~zY5Y}|L12NHf*GC}
zTKoN2*!kK);o&imR}6~cd2WDieJ9sdOkIg3WtyP(&itGl-Ni~?=FAZ406kY<P-|R5
zaCX;}!n>NZ3lPc@jMnGkO}dqGtKCrlSQLkPrJY(QpZau)c-`~ekJiQs&$bGD%eB3#
zgx)M1p=ZE^>BEWDnXZ=QHWwKj{altaJbr&^oZqF8&gR!cJLE0L*0<p8ehOQZ8hH;8
z{j!g<`!}kt_zfHmJ>c>N8^?Co1fWduB7J|8jz6OxPmqt3a`?t~@9$inxkCUUqEbHM
zqzvwOnn8~{dYC~^vGp0$<abi`d#Nm*oiL{_;xgRmev<l}Ov}zUN`KrJG&lO9Kkkcn
z)C86|16z4wmqEp*&qV>kEU*mYLxHjeYVC%3oB?ZNuyN;eg)L^-Gg6O1SGCvvcfnN#
z!Ni+4XRUd+T8rxzollkLSBjbZXoN29(TC9y7Q%wIgF<-<&dkRD(3=%A10TUi_q?bb
zQz}!2_^A2hfzt3F7%+rJ+>BtC;ZgPcs@KpquJ;0`yDJ6N6$Jr|Nn`Ym&h-oql*4-}
z{P46B4vUv(lie*Le#tvnX-dWE-6vY*2iW?R8m{V2XDXu)ZVjH6&gu1Y?<<N#NC|EB
zJ_G9#^kzE~*jck@-$L{%g`@xShiBrt<r~c@xJ?$>s0`Ke@?D>_<%wpO%q&#$1Vg(p
zzL_w^J(cB;%~u5Yf0@w1mpqV|a{}b-I&o}*7_g<j&Z&cZ_hI#xrT?@E2l#mxF=GNT
z&0)m1+QaUU3&G$qpU@IZUSGpl%WyMFe#bZ(kk@6{HWYIOhpX|Jg3h8tzkQBwF*|F;
zR&FrNcP;s%V51ZEpf_J7lnC=iifq}ZH6a42)d0^M3_se0oNf>u01w`X4jU>oK^|di
z{XQ+xV#|=-vO_(8b^|pcMroHRUt`9zOnPj7Bq{ZaI|cWAo~25jX3#-ZQiuI5eu@^j
zY;|lB8=o{jk28JoF@Y08WLvP9D~7nS>klNUJ3Y3({c=GQs+aO{n`du|YD)COvJSj9
zWpdbX2RAt<JV-x~8I#GZs(+@;2xBD$5`TPFi*M}Q=p(U8l-_TYvNLpiqLppa`ElU<
zKQSoC^nXR&SoeHaa3A!AZmOi%{I`pkx}owzK6(t)hHs*}e>78`B6JGvxiGUn`gv!G
zZV(OnvpC5tSfkXth2xUBFq;-CvnV{<LAGRzDp~b%pm1FA8~|(;B*B6M#Wr!S+Xj_X
zPcjhG)$KMb>g{2#2#&_K_JCu}+2s|PQP5q0L#d#EXXr+_w{fJ9h4i&R;dq*{@#xdQ
zw87!92D`c~gx_BT-W&Vq=D+*$<YbL;<VJYa?_xrNlEZ1y=st{5TZ7bmr=yWt&Z<O;
zjN6^R*J}>nET5z4y<G78#vrGg9d`Vq3wn`xMnk`H%YWePezA((AxY;AwG?`AXRIkb
z(QvMYV!R<sprX3l^(@nls|w@3DS_f$Cnyqcq2!Ch{-+p2^(?7?AF;@mD|FW2zziL|
zS~r`mXeRYW#$bPj5~$zcVNxgA4&OEu^~}$eu*3sCPZsCWUjaP|XVFhHDViX1wPth5
z15exaZgRF?NnkS@Pq}ZFB*Gu{PEyP6kXDs=6=3VXHD*lYRMbVlJw%ccfYtmi`!ZBZ
zeip-4Kh5-s3R#_3puG~$_zN1XeJ!u<gtsNm#tpR`s0QO5dcavVDKGs40N+YQn$5K^
z=Gim7n|_Zq<nunFsBoe9RC2J!YjzwG?)o}#2v&voKvxiRWxwvOx+3*<H5Q79<Jg&T
z?Ni<mdUlhwW>3+LNRAv&K}h*v2Yp$n#3hQvcZG<&Pcg>o1OY#&aV%H<7N?_I3xE5d
ztD{{T6JuRrZ-nQ_h%%QeX&zanx#}H2Fq}8QNjKw7o06{TTGX>bJW!0BekTJZS7n;1
zOxu(C#X%}Ni=2}mISa3Y$-dE51ETF5GcWYYM6W!rGx-F*)USAnG~pJQoLly<R9wjB
z<>2<HdMQ{mvcz+uLC@4<!ca`*ejfKs<N`(`o&t=E#%5`jW!oF`eFX|1zGFPmxVEE%
zsF!v8Jw1m5bBFv2^_R%nFoQiC4nzAX&K(2*-s_w8MVnYY@m#^sC%ImVcp716eQiF%
zv$MM>U6$~B@<ma%)|MY*DHTx!OPcrJ_wwq@?32-Z$=7C1j$E=;+bJ+T8b`e7R4Fb_
zOu;(oi$X0fk#wo!u5weV!=m!>+HZnjpTx;#0~@WH8<ruTMh<;$J626}yD&ZWVkqBA
ziXDWRfqguQd{kiVU-jr^odItl0;CA})Z3CH-iazkZ##y$f2i2gT-COvbM=9>#^V=o
zR_!(r=#V{2cJ(}b;zQ$GoKKy}UPW;sApY5uHhfLMGWYVI&Vz!2BGo)XiL{?-tFHh6
zP@&`KKNBC2s)Eh{;_CV-)b5WzN|y6v;X+uh{DQ|Uu^{u{09Gyg=^!iUF#JVOtVC~c
zl{tz*@cnS14bYB6eL1@Y&nTxP?K%oSdCjmffW>0c*L2-HAq3SAiH~fVWx>2LT`Uy|
zrM{OPabh%<E07ERL|bLZRi!z(Aq(LWjA{xXRxD{XxP5zhl$Vt)j2K0wH9v!Sp~3kQ
z6ec+}*YV6^%Fy4(TtzX;37#W0j?cT!#eR>lH$k1i$+sV^d%{~JnH~e^gVSR0^=!4c
zEX*neGxi(om;C~a{S_-BP@$2pQ{&>}v-5X$*SzjV^H0(~0rg}Z<%8AV^<-ov8&mt_
z*7MSYR>N=A-H&oE5AV}a7rvU+m^jRy!YpO-Z*+RqBBI1kqQ<s~S?8POqsI;cxxkHX
ziY{o^b%#5_N7W$>ZS1VU(WuI^^P6TLQo{5O#0}+p_(#r;6UR-G7L5tR^h(2f7D6T~
zx=sqad!x}TdY?pWlP!N71T^SJf8b_L&AML9uOIF{5q2bNK_3FxA@_q<q$=QD5?dK;
zwloc3>k>P4FPiKtemoYtqvz1v8j@UqBF;z4{8E&S-g5rTywv@3nOan_3EtRI@7OEo
zNvwQc$HCfIdN~TWNoFF`GGztpre21yzi(v}FG%eiI(`ARgIjH{$1)0Z`iFU_7){DL
zZOqK()%xG?u9p+9<-~vHzN#N2DStOjt>O5Q9BJT@fOBHX%^o8Au5cWf3rCH3<l)dt
zPNdCVS*?<JY>6**E7ID?LZRLL6y@QY&0~nooXwxAt|zvgY}=RiUH`+9DP|H)Ad!jE
zBz1gHZveP&;!y9e7$3t1OVc`2r&PYMRW9{jxJb~zK_mP-P468#dZmej_h__`ej-{^
zB4sohOg<UU9NteM`ya>o&7?;$A2k&2@@rUc6B5p2@<_>ZCBGVnghpwlnf7a1wC0nH
z9*!boIp!j1CGnFsRN%aWc~46h(;txQQP)givvos0jL>alhe<F*Vu!}8N#*4%I}Fe3
zZ%NKQO-sPY9B5o*0XW3gGs#28Mce5u*3mabYG*l04G~Gr3yyBml<BC#1)yyE`AlP0
z8Tpl(br~*0bQ$FLdQ9_JAc`!gz8a;QRy$wa%(xfDe3I<$9BPjl0Hy;o6_;kU)0fzg
zAO21NApLrO&mvmZNF|Um<2oQb_3<hgF47&@AOxTE%GrmH<lAx~5ba^#eNXH+mhRq;
zqBP*=bhzt-DxN1|Uh;L=I?_hnD%bqj^z+K^ymIW}bDbO3@LCAbt>QrHlT<)?(($j>
zDuVV~ZurKEoGGt@rGi}F4^c?$JHKiTgNs0LQm>ItvHspDG;BB7C2w>{c%!#hK&A5F
zaIJzuZ!MO8hlDsG*7r0SeXV(dkna+ZjS&6sL?v(XZkiAm(4@e?blmeqoNY%v#3sT2
zB>IhkH;St_+rDd{0y$!X7c~h|&Pl7%s3UNQkN+#!ueQd-BKRWal}9c8Z6woU3m7h2
zaklx&>6EKkc?WL%cHvCv3Sc^R`aRdN&yMHbT5a_O5y3hh&TZ-Y{T;!6=|0YF$i(KJ
zeXEDgm96yWDk^u6fdXZal)E6%&wP}Ou7DItlI_1L!zsNqiWk2#5k5PtniX$7Uj0kc
zo~@Oqs@i>g+yq|C(iuqeB6u@drmc1uQKqdqb~iBd*Vr^K@~OnOtkg%v>C^zJQ5T7s
z*fxf$6lbwDCZoA`sHk(yhay9Ypn$*0z~66hCdqoutl)>d?mH50{t@{^#)Qqac_Mh+
zYdF*q9&#u<{TCVP;uKSm1BO1A(jQ<M%toQR^XxEPTseXcq|<e<Iz1^&UK#l+VIZ|0
zJfNe!2?Cgv+5Euald~*{nt1oqSTND<;ph0$%<6k{5OI?@(C)xUqHcq=$N?pPrZmvl
z?j}WsHfBpa03|0@ts9?+U$p5VO}cYv>sk7b0S%EFjXJ!IFvYCfIo_>?;>nWvV1UZj
z=bUnhr<G&ep|2<lACdeP$04|@-#_%}jDfd*$q?oPxFpqnJ;`{o{6z>*Ay{9#Qag(<
zx~Iym&#vUBuw>6q_hbagZ(|%n8XTZkS0h*Fp_*`?5qOlamw|bXdWJ|X+49n%LmHdq
zS*!V?%~krM4j?1BNoq<H|15|-y8<JwLlVex)2deA?%a_}k01w4#+xND6hbbKEy&f@
zaYQ4aT@lc*7T(r2{n0WWHeY=l?AVe#Wc-?j`@-nY2GU;&72^c}BMc1@c<1h468QA^
zE-h<Qa?T-YYC^R3XKkufonXV?!N&_6REz4m#>Oij`1j1Sr2SVL4(nLMNptD$h`9Mn
zl9i>Ct4Y$+09cfTeUA~qj^ir6E-VoUx@6qnbkN(syEtI8<#pFmxus-uo<Ut=66Lys
z5R1X!uQq5d#+1r#Rd!cmDdJW?U6PbZQS=cw8fI(;2EI!K%5?8kB}3X6;bk4C-j-oY
z(rSD)AUS>%dJvuT;32OHgH3<bB({X1pukdf)&m{iJ!C*;27tl#QI`@2n765-o~wXM
z4`w$kx(74zd8;(ObO9Ck%V?FLt!FjzoqCCdRN9+)nGGDR-x3u|FpbrJ5r&VUqpmc0
ziaCs9gC<v9@ws%Z6Yz?w9@}(*0<;?Rr|QX5H^-CbaY<Q@(0S;X!T!Mv>I#!m1Y`_`
zJjoN%;(4?P19IsBPCalUWLV)4Jn;~kZaiWGVh8Z%wn1Sk?N8R);hl$9$6lRdp1JqS
z+Csu~lxXT9DQknenS#Twjf$#9TF{6M9oIA;E|9`g^FZiKzOTx%?erGtWT)``RU0mb
z`As~wptaHX>tGahiKc)F&zKa5oZX}!g)P6U&jBc5|3LQ$0wla#9)=rMr!{acYm6eO
z+an!nV)d5mm^1IOK#p)DcDr!J;!7K%{wg^0!=pJC`Neq-JBH*qFv|k|t}mmPolYQM
zBJIqDc)y{VE5b4FTmL11Y%Vr=6EX%(4ES4?gt5Snj!TG+78L5|h2HpiU)7}0^s8z~
zTf|WV3ZVtpF1hnM_^*C8{MR>aCLO7X0~nbPRTD3MsaR!i?J1XCG%l^XV5t9As^HPF
z)#52z-fu-^v-CS8mGiA{u*?6ij{USYe)4~6*v`EW9j@SzT!i#VUx|yAW{$y)krPYv
zr{KPxP3AO>nJG8|KAv;5&pEq{!`VIAuZiVv*R@v(+5@I@mOA&Vtl4k|ywNno*?-G^
z9P<bZO`<8(0UW=eVN)y0(wy|)C(-f|kR9Y()!Qy-U^o5%NnG94-YcI!R|8{tYzRC@
zSMK`z02t1l9pVJiY|u3AbVg3IHoD4yZE9sXLz}%I{SDM&(RGHs6C1FJ<jS&~@>3R2
zGR{h%!f@ab8s&{a!c0og<2oBGEyo57QI2@8rY<WbTw~1D!@>H!E1A$@2?bSz0I+8a
z!(;s;ei73iY6l!&B4$BOF&+af#H1pC7s7PZ@(S<4N;o(QLgohrDjjYl5F!}A$ORIJ
z-2m==VkV8mi*c$oZMotKmYG^yKoo!w%c>NRR)A1vY9?_G7zf3XOX@TlE#BLsj_2D6
zAXcH`-*bKN+)17yMAxo~r!KDH&4&yBl8(SrTqHN<-kwulkIbeYRTfaC_W>hSZ5EW?
zx8vq(=d^18Gbt6TcF6LvkWHRpzWW-5N!=%HnPkUN9qj*e<cfw7Z0v7gjZo%)M=>~7
zw|1r*NI1|>lUc^x4BZM#o`b#d^zK{ik##B#Y9<zIyix~}c5tV>4|~;JBN{8syTBBH
zIgG>+aCli-qwt#jDwbHilkH!~Sd3OU0bdY;poCh3WAl%_A_8%8QV9S(^E@O`sJRX-
z*HY95eDq$N;+J&qn4SAS;qf1G{y$*za#;5mnaRy@arQ=+Py5wl$H3>ID108b^VR!l
z;k);2f)aw%@ksl?X@$HW&Q`j7Uc_jHDtO#4H#$9Ui=-O6ssUsnPG5eMkcm72=WL_a
zw?l5S-;^7J22(`)uW?YG<KX*%ezrW>him(lVvl2)eXA*=PupOr$Ih;yFRliWLkko*
z_69;KmG)3#PGBZ3FM^=fz5zcyVh{2|`oxc$^bhIqBk3qXX9xSzolUvPo4mIZxqI!^
z_6-|(8Q5;N4KQGW74Qix>XY{*<jw|y1`Nd!K#*-vpBnvRm{$YIK+`n<018Y~IE|S*
zuafvEw(BUDpc@$o5;Z|U)LWAb5t`_pFxR-V>ig+xs|9zamunbm1Fkx+4<22svE*0G
zU8=ute$>sIcJ1@E{W<+Z`9XVXIg@e&W0s?}!n`Zav#CJU^zz_z#Li4JFhC9b{<bQ3
z1=2sAaR0kMaBNIaR*EjB1|1XE7Tn;1mT80MaG&aXK!`3jFy@&jqu4LLMn|Ey#K+Cq
zSrY=x*DoSBmU$f;4*n1Z)y4lBTF+eb^nf7S=!qr3>(RHH7D`q&uhTGL1dKV9rX?}V
z4GiEJ1Cz%%095ncl}aQ;IfUiU%#CvBwr+63rMi)d!c#oK40_`{UFYsyZ_g9j;XIEj
z8(s(GyF0s6UC*O6_v8AYiSBk??mOC18<%ir>-C5d-1=@EF2K3>6UW}&uBu&lgY?WJ
zZg>y=7|oJ8TRi95|33Zw-2e>Xd87N~HjTf}bEYqMT6N`{sd)T#=-3a@wN#%VsVuJ*
z!<W;aP<EKh_%GSqdQauI#d?k%R~0`Z-}CqFoSSFA-PpyW1KN*$C!V}mM)+Q4QQP6F
z_eK~iqIs4W*5q|wEFQbW?b%l<mY?>p562lXnD1^1?Orh5&Nmuo{3VeFfL+x1LT>=q
z&)JA}idV1n<JS?t4UP-$WSTQBj{n!&cSkkVtnUV?iUJmjq6Ab#x`0Rr1r-$qq$&tV
zM_N=m2?S6?RE!^p2nYcYk=~005}G2tC?wQ?KmZ{LEf7-g#_#*iJ?D4US$EyF&b@z4
zGCMPCX0m5L&->2%yt{QD;w;iY3$H&+Hr?eVM&bctcj_v_x2IW!SL^0qeElw?we+oj
z;d;US{){_iFVv9+pZoPy?`|n#Uo24a%pMN^!GV1N?R|~)9$(xX8o54iM*CGHu|<{h
zi!fWjojX!gHj31DXD^J9HG5Bn*gOO;598}axb73}R`hhkiFQIw#UYP?O85D$mYVz)
zB*SHOAVY^km$uN0gl&{xoaTqty>8IKPQqqaO9}VHX<{kznUnBNrBAbQ2ycVB;C)R!
zTO|=xZes5>r45x{hE=J7bLm2jj+6b7PFtr4we1&vc@&*q4N?9%(P23A$6<C-<5$aI
zcG5&jZv)49NCZbyH0H?YRY0)P39j$FBMcZOTwM{iIVaBfsUy-v{Q8=`G(dO%DJU6`
zN1bowFtis5sXkl~CbqZW<3@bFYxl=FLep_=&a{_`Sl_-MTt~T!0gtk)$j6^C>OH<w
zU&IxcrlOs6-w*ZS(2NaMUSPdoU@7PfY-mC7PPji(MXcdt1a0K*%Dx#6Dl@Vb$ezCl
zyn+#VckEE|_!@gK7KAJA$|*(D$6qxmPK%~(5=#!<9Q4}Tdp%-X)>2aFj97vR1sUcY
zA{}T(4A&<%r3xBotJitT#D!qK%S&RiSXK*p_^^0lL0!%K;-z*C16>d-l`|@$YD@Kk
zu8=t}@tt@WcmohY67-6zAWY!AdY|-nyxrxOn<%4BiPFris$19lgP+G26F4O4XA1=~
z#6q@D>{dTmdK)LV8>gdpRFkJ$dAK-^S9|$fyAPREbz@OZ`B-SjQyC{51UDZ#(-yG2
ziPA_idh{gQK#wyRdMY$vDmDW2#1YMPccELqxyHos_JKRnw^Z|FvJHdRD_Zp_p`{ab
z_L8#1N#Nyr`Pe1L#@TRz<<V+Er|_@!Rv1-$^z-xAz9t!Jm6oyEqn7L;wplLwsa~t`
zl>3?&gv9xByREYiHimz4i`RMyL|JLwy{9$!KRIm|kw;9d;f{Ob-9b66wi2*^@`UNY
z!_lv+a%XtX$)J+C_D<bevmsR8o9Df}Gy|@XQRapSYO%VvY5XYpXuWzL2)cfK_k@H1
zLVxu~wT9Cd2?x36qtrsF_!^L$1oLMG!k;+KoYMhMjIJ)s<fp~N)&=x9!#zXDA&#LH
z7Iup*FEhu#L|ARN5q-!otIzXYsFNie@~;{aIvwtkW1tpK;1b)k-Tbw#q9TVy;PoN`
zGJGxvFKnq|xq}+DW*<nZ9NW<RK_OU8|Fh;=+fq~oax=O-?NniS1&8gKFah&#_jYAn
z#&??uEaIxP&xjofEFCU*W(;B9J=D=ut<mS!=~&$uE;AMWaFw?afo2|rNm<tcSuQOh
zaW8mIfF9js{~D8u2wx2V*EU>}#RVfv7CG5IS9tVSFq<D(_u^ZyW*G%%e>sk>OW~^L
zj4dj`vB_2zc^c@=U*h#uE-|{aI@Y5mpN^2ecT}5EH>vHz=ubWc4a?)TVpPNa?Gm+_
zT;-`6NOkYd^nmcm!fewbK$PqZo*Hs=vU0D`N=rfe1_jpl6*wgE?|4t^rS2_@|5{EJ
zLwSkpM+J@#O$?08TdnZhnLv+y4+#!$S4!pfAruU#YJMwhM4xtYuL&+1w3|Tg#a+hZ
ztX0+*0+jEzr{)fN`r^ZhJrkwqfV_uWwx~D@_wb1n{HOlKK(k%_WawJLo{7lDe(5yx
zG0#ku(PPU*SvFCR9>=ryKrAFK7(U&YZe*!p35H@SJ?EAD7v@azt(~TJFTQ;7MCK^O
z)jZF{w$strL7PQ0QPv`sK6nn+TOAzySzN~0SPf7<c3(SWIdctPFkX$Jk4QrT?Tc$P
z-j$}=EW!cB>N~$J(nOLI)Y;iNM|kog*KJmdZ*a%aGksZvSIqZIx1VsI=lB7nQI+h@
zntL4U296WcJl`rMa8WGqombEDjF^zSmR{$)u>ozs7QL3-ZOjAv2AX;xKrWwq{v~~H
zNK{5sW|7jQd)F4b0<kXS3l*ozwu)-H8MxZr3RT=flMWu$oU*ek_feS7PG`JKj28T;
zq!nY9S&n)2$D4e(BDUUbxbgah?U8m_y-LMv+r*9=Y_5JmIJLE10_qE>cAu)B&o=*7
zs;jN-4Jfgk!=~+1*u!AJDfu)pMHPI~R~ZK(!3I@VHY`!+BIHm`KqRb$*s!wuV2eVz
za2TP~7x56+IN%LLTQ~xjYL0IhT?KT&AUze69Yx;`O?zr_^X3C!krIYu>cHcT&=7!^
zi5GKU@D28Iek0@#T+x6`Dm3t#>V^Wjd0nwe;rvP$4n<p>lIk=P)catOZ=)P1$@jB4
zO2lJF4QMFx`nM|Zzh7?H1slFLGhl82B(W-~!$z_?sl!Nc0N>9g1*jVhUys#7$Rm}W
z^i868F<&_en93HRC%x*yz6)23;8q9T!x*dWua#^0fZyfKamAeecWGpIa!bq?6N&Tw
z(GHv_*_;&tocc7Ou6n=*SgRtgaE52>pCJ#@4r@`({*ICJZRuFj@}y<hQYwj=Y^E<`
zM<wN_YT(x~TLb-Ho~IHz1eF|)G%}_$91!G&pe*|NxfDU)stdr%=U%W)m7lE-+|B=p
zyV)b4u&pWPyh5R!(3M%I%nHe-9p!bDdvYJ4>$>`#64@UGW#5y3YENTo;9hK5da>tn
z??Fi3o(vfVHnWCo;EthCq~_y8EMoDnnbi>FcGuR!bmV=2Iyd!y&s)|I#F^Di-f1rf
zl;XF*3vvO(`2Rr(_kmWYW~21PESIbXJlfB^wgWNac+zeJCFuumBr1JxVE3Q5jeGFZ
zcdswH(a6$If=5U&bEVGXc)Xmts9&YnYaXA1kGWlERaDw>FlZc4Q`<;ruza(rZFf%N
zCQ0v(beS1u-OM;;Psr9Na-#J?lm1K&TpRsX?r2qdFbBTRPlD#PT1wH8*V4_$Z|CJa
z7uUN6tdX>lZK{u1U-@DG&<{Y!^Y&(WWQeM@CMl5q%lG5DOhk|k0;+2rsvdu}WCX@?
z3ts=f<XhLuz6-CnNR%7^-Jc&#N9eMKu1oPsZa+dWWF*3VF6Fm481{g}7>mI7SB&P2
z)Pd_a07<QCOo=KsllxLcYars|i0_$&R$%u1P<3q&XE~)?-@ADn8wL_f#)pau3G32<
z|KK-YZneL?(bW@uDUj#vG5eB{%>3P&d+g$a>W}<`mFS`Rfkb<?^8Q<+TP9~=bGb6h
zHBBYhNp!+kDGpQ5!D$5OowZN9mk4*&3M!s3rcX$@BW(Mib_%DwP#h;Ypm}ke?NQrb
z>aWjvOWU57Prg`*F^@BSfnxmeI4vHl;43}6*qP7}HsXv7Z@~JGXXI>R*`4~rb?N~v
zn;+I?%WIk~bD*p?G`<Wf7b+jxS!31!Xo1@Zk1Yt-^37!kF)+%Y-Z!c*C>d(m?%|F*
zTeMrPSVm}R333dYCl1Q;((;=L72Zk8Qe7L}++{t?f2ugqXqh%`GeWc(x~CsfqP0w3
zCNX>Y&1^h6aVS$#2PscZe(P|Ez5#31<Y#eS<l3r}xZ0L#t~a1#_BCB_B<xWM77Tmm
z-yQafuWV#scU)mdMHLV9Urt?xhZoYfJEV@K+wk%jJtA44o)4Y9J(RSsE~X<OYL`ms
zJDbAgvxt8JSM@TVeEuZ}`dNBP#ue679_yem;v-nuuHaP=$V!*imXUf8sLn|}7#e6T
zcpQ+j`|<(SuwfCwJI`hIi<FuBII79ky86X2zblx*`k{eE{lefIN-N$;L5p8qQMvB-
zU)e$<ZlXJViC3QQzoSqruS@zxT38N{qjDGLHojcc(P?x|>5fsaL|oE#kotEBBrQ62
zy;|>?fS>~kANHxe@w9N-*9hAUTDkaZhvtF$ZWW!w=1zD{ezxAGR=(lf3Tprkt!(;g
zpj)Jl(#Eo~vVlDiB|=mf4{(SGHGcTUnPYoSMKaA^>syw5U2>|!+lZqsQ=olunnKR~
z58eag;MYm+Lqu-ml)~oZQxVvQ<Q)BG#R-i@ZdhB{L0s!@?0AZj*%0gy&Y@nlEquKd
z%vvdLml*R><a60)e)`awJmTfcG^9vqVEO%=7z~9Mc*s~=aSj=J!kZZ%c3FL%)6VuD
zi5+Pl-6%hBMNjRdjT*fU*nO2|7kf!DhfZUF+w9_DfRX)21i2|ECr6rWL=D&pZ9PJT
zkVya(?Z9J?fF8@}X$3IxbPb4z{<+J4p;U=OVTzHE;5h({Zc2nNNF`sZ4%Y&nDS|vz
zXZ`_we?#DZx5QQ)d=H~7=G8**A2Y7k?8?u$E)o8e_2d+v>}mG{@5j**(7sGP0EO^g
zm!1aAlO|9Az<x;Z;WIo!%SjZP1I|`I!aiTZp(At@WrQx?1R4PYf2`o;9L#iX-q_D;
zy6<!V`e&fLusBcNh}RhK*VhQWR>fwVxWW0Uh%;+8F+8Zd-<{yC^9HRws}*@KRyJVc
zX(N4hJK@~Rozwvr_$!xsgR+27Ey8+x^$FMcz!Q3U`sbk16zi_VH@Vjo_)b=o7`p;q
zi#I2p_Qb>vwmZY!Boz40fSQip5_;QJ@a}+SlJvpb6x%(h-NE~oJ#0GEqoN!6H%S%u
zn+-vA`-1n?WfX7)D>?xg8rn`hu^=$dw>LMn7PTzC@xGMq4*O|XFdh&p8PpH=lGN13
z!50)jZI6;NGMI6_roq9-(XUU8EGHjS7QhK=xqdeV<vjY%{~S<r987;+d8=vN#f+U@
znJEgzjR)2=p*<bR24_GboFEaP6f!Fsf2M<V)LXwn@9%;DUWfh+@VjfmqfWu&YYEy;
zVXfP1@%H*D7o|vdP`=DJ%sCBZdrYhj`P5-gHX*%35C%#FQ<w3uBo+T0-e&-t*#n56
z(u0$FL)6o>(V0pOX>BL5zWVS3O?BUig_Wtj$c>@fdZbk=?v$lF6+_u#65`tJptE~J
zIK6;lvD?K*LT*qg=e}<zaWwjk2PxT4HDk?Uttrz})}YGlyLI)B9i_U8T74(U4YM%X
zYi4giFlvdO-_qZ%xo+9WdffPaj096WeUnPdS7XUQ6Y`c>GAQMYu$;tJl0kWcHjM{I
zv^B=#m@*<SRe?Q}F1|BdJLyEjIfou?PC?LQ;Xt;>a1%FgTB^qV6BOb`!gk4%QGZ3e
zx(8?0H0XSLG$+h9hf{HsM`Bo{m>hoAENj4R4>fPcfX?ZtI?{t=nnK9vSxaH8LOmj~
zqV5i>Ma}H6+yL`O3G$kVX>6o-MA~7w5{iDKrZ7XOsnU!{TN&Wg2aIFb#?H6Vg+Bn+
zae9{?D*$t~?f9opatft3N)B$){~N8WrjNg(IojWsee<`?%+GaBY@ZS$hjZEcjPJc;
zjtK-59!jCua%v=@MAtjzIiloks47#m;W6P)x487}V8<y$<WXFhZ)iE>u8f280j~1x
z?AKvP=jM*pM(rH8W0$(_iMJOviQOW^XYM)aGGz^%dW??Kk`+|iSBDhzd94T?g9UYB
zPNMv#U#UkDyshIqNbg36n6_VKLTsisp~~#ri@W~WhD=+#ypW)VfCWiz(Bktp7x@Qw
z@_P_sL_Em+3Vb3L$8|JDX4X#G*N>k3^{?n;<vcX`qzs?ImoTa`vG~lptpNm>p0C=Y
z+XDM%%(3bG+(%xVs`Y6ptGB)l0ux8@jr0nR$UBh-L%C`rq}AE)OY+w$0`M+V{1@g?
zy=owTniHL4uZ-h}XcXxqyPB@D^Drxn0`e1a1_6E;(8=a6KX~mgAKBYw3k41eylSiV
z3aojTDtFqZ7MozEe9Ld~@LmR9Xj;8D_u7jHqYS-+uA)7}Hv)7}=_c*HTvE@#ozwkp
zKLqYHsWdt#do--b^hNr31$xe9$T)_R;xA=T>@9oMPEExZ$(bEGssJ|F8sx|eXeY_C
zi#r|YC?vN@X88Ih|M29ssgaaSojKjPA2Q9>o!?`DClMzum^`VsT`ejia?Wmg?ZjJF
zwG{8C&&wff$!|bpqksh<j(h|-{N>)cU-6jeay$Q4G2$I3;V|IU=S~FVxKQN{-d{=?
z%SzVkVCI6c({`tAg~_D*ClI=OTHt<?GdRv?FMUwX{UtX)$2d=9=MI!bbCBn3pfNeg
zBMGx{28?M}gkB8*Ds4xy%umnSO8gbz(y&t81z!^Ew<gr*%shi9+ZuBpnhY-LQJk(A
z^i((R*=@r5x{iK2_%?|0SuXSX^NILe-&*BDe0Mp(+Z~!pHjGUhj{HTPI8A{(E!Ia1
zH0<{6<PHK|OBK}At`7&Y`rJCP5Dz3Z`ZGO?;p=D5o&m__UnSDUoB~h*cuNRw2Vg6W
z_$wcu2CksP);*?OUH|r+zYh^PaB=?*r08z+8_6YmQyv0PAh8!P+kh@5-2jLB|I_m3
z8=chtQ!jzrE&UY{fU~MSOD4BJc4z2>`0x11g)ZtNVQU?i3(L@dCya@)_?=qj+j|Ak
z-?pMl@d^;wTzTquZW<Sp9OgW9&WfMey3g)+_L_g!bpj?VFth($-%nPJKR%8MQC>GF
z7sl22*%JUCKm~AC@$?~Zl2FT@o|j>F8L%c0@XrJFLR-lOv_S|H`dwmX24Vj5<Wt|B
z#bjU?l#%pw@JyvHn!0j%2}twCB3Zswj?f%hgVKKW`Bf=#mB#~yGhYDEXK$_N&E^>m
z@!~z@QdTP&kiI9ZWx)l*BuQ0ZtQX@M3i0^xCXE-;C!daA-C36M&wsVlgYALIInJmd
zTT9vbSK?v%mhnz9mtu=9uRVFCGS8yC4IVfW%#;Q017q7%u0Nt9-3*_ui|50?vstU}
zrPtWZIV9|=;kS+bL(ilk-!Lz<wunw&FZqnCUl7`n!?tZ({c`hu?AB3p&6j?(#;>oq
z)p=}wMO?{gw5C&Js1>)V#qdbq-vp^~7DxE$Mpi0XPmjS5%b(Js49%~k!=Lye4;Fm(
z`wYt`)NHV|BBnK(YKXY6&%cQlAU$p0XuYo&u6MZ|nt4z5rr>;-Lf>u^rA~5v7BTS%
zf-f|uf6~l$zb@CRq#<yqGjG`e7gF5*3I0)6?36}gXJ8nF6mULsA{P<@>s|9qBU9Kf
z=lag#nmsibUGs+u_FUg8L{rCvL6K&)^Qhqo2*qF%THkIV%yOA}AltDB$1lMfRu^~L
znL78#3E=61h#4sX<SxMo0+c<y3e+sY8C!wS$xh<ZbOAmXzP?J{ByayD!^_PhotcKH
zhu!-JZ}ba)2Y#%~LemtN{A+{ACr}2M58Wpaj4<*f&~-0zixfev6+U2k<@0HjPjii|
zI;%9&I$PtSajN9gvjDMt@Jwk0$jUIGrUMTmeBIqnhbqOfzcTtPVvX6J6#hTJ$OjE<
z!&w3{J;YOE<K4C~2+wjdc=|;w>L3!~MC+wv>hI4ahIvj>3bSUrF{OUS%IV;M2B%vA
z`e9^*NaSi<HL?|wHL?B;Ji+<`Tbsnz%(TtVWR9c13NU(2@p0v9(<X3+c{Zbk78^YG
z_QZ$uEcqA0)S6$SndAlxna#T2&4|tQX)k5_cfr}Khui7AEII-cF~$E+le&DAEE@g@
zaNfK>y+IX}G95@FKpvY|u{Ze5CMGd#WpHBzvlr~hzFJTgK=#~f{7jTV!boZCY|J)4
z3*P5V-@*WRj8uqNW=<+kvW1l#JTc)?h5QdXMm8eZ$Vsz3*bT<iJZ}|(#iSssf5_@K
zBlAW@Hiy=}#BIH+*J1m>C^!W7tmqHrD*3*5h7)afR*7V`<>`0~9iFI>S#o7J+?njj
zURYMfvxQ5T^G>XcnM(ZYU_*awjGvk}Uw96cdZ2Ci3E+|H&6CdU_DfCd#k^ytKZ13y
zE##sKAWjS|5BB~h)24un6!~$wLRsF=6qiMj^KzxIL~Lx`tnVbIa>E7Fl9macJWRJm
zP}m-0*iD<@Nae%>w{Td`=xsC56y2~!bXc^yFe~h`M)|31oh=aKWEi>fb_?EYl5-_;
zZL;^h={KTXncwAo7a)9Gpue`^AL#UIYN4?{`?J%yBaLW0M9QFQ{!ze2lB_br)VGb1
zR~eU%&664P@D;Mf{Kgju8)Cp3a(MF0kJ|0YeG+bW-`xE4@!MIE&OK!I@?<6o!}v)i
zjs|Rz@a*NxP$%S1XMvEz`mHnA-8ZFE5SNw{&zOJcXcaVIbWE5@O!jhMOhsAY`75;&
zy@#G@OJRJXYf>SxjZ)4)3a>!rq*sP(jvwcHMlhj{34ONF(AjDH_5=iDuD3ano?kl7
zF0rd7my-=Pu5=j}L{O~@R_wf3y|z9jx*zIR>FQroesFJfN5&fKBjL{vZS%$?azje@
z3^xQ)=4Axfq+B*FAbPBPaVFj1C3{+*ast65g|Kyt-3Zeb*|e5m_nlq%VfTx0Va?c^
z?A&w%bdp@dDyi=Ud&YI@kQ05T-M@jZCMzR}Pm1xY9QwA!GtqVOsY}20DXEvUEzA6P
z_H1{C_%yt*e*LqtHMla}wguoq_B0Zku`-&iJWkcHE<gZVvzsm}1%D99vcN+88D02E
zx{5fIXp`yImpa16(opb~VkF0iPfhB~M)a#$g^JNVL%QpaoLDzbykHYe(YT@+2oj0<
zk;Ah7(#pc7yphjC<R3wAo4HW9iJhv(=QUJpk5U)d;xwlp^!v3TC+kl#DE66|PIzhx
zrg3ZD0CM=V;^Jc`LXhJ4Ig^B45I*jmo5NTBo@L(eFk&%~MC9Aa18CBY(TJfyIB~0C
zi{2RC<?X#L=NGVAbEAFdV;O78yP&ahoS|aWoW3bK=JJf^eQBm2K@(+e{?IXEI&DlC
zPPHDwGn$o!joIa8k&dD|(PWc?KO*jU*?v8$GO;Ip97>TNbEHk%8a&eZ{4rM-HiM<c
ze}Jm3Ric!9QAL-dHMpo$PYlECNu0#{>eGfwJMjH0wn!q@PztlQu<&UUNlvy@+Yr<M
zV6x@+V25t%y1&`arWg#9=wFoWS%@(R8>U8LhLJZ?Y8$D|gtf2j2J|`2-0SbTB&e^i
z0z^hraCo99J98xcc_=(*NNC3A7<k+a(zW)L^DK?4{1gCPk4I|!#7TPQA(bV*&kW!i
z&%-O~QM}<YIv3oG061}<-+ZPMm{A^^e{)s5c-IAArJdpUj@1yyiq#$R{G;gOjd67e
zHgR>OzVz4Aq`o5M9|P8>{%kxK);cdQF{(#H;(?7852;dWi<pB`6D!zo8ng5s_+1=^
z&*jFBSG>Y+tfrOy(<F}lCFRxVgEZU`w-SZL14)u=z||`kJk0<uw|C>Y{NMELzgk|p
zjdtBkGCQ~B(F_o&wnuypfB67_sR9*`75;yfoewd;^9SCNH)P*8^0@Ik)}rkV;fp9M
z;hlG0A1vkn<n;$IWhYr6sA=<>yYuvfn{L2$fX@I`9J3zA%?JJr-YCBq{8FJi>(7$|
zmsG2d3f(EdGVho&VSEIWzi40TpJk1bwKbx%^y+VVi>p7&Tr$v)AfPT4X6Ua^e1tRG
z#{kkK<FwJz(sJ3}c&87G(}(tKC&MYLyP~@A^uG0VaQskyL3q`o6I&&U4Zg*7;BD*P
zbq5d#q#k(bR-h}y&(GaI5EQBG?C<X$DtW=pP10G?A|TA)RmtByQ1YSseMrE)K*+-|
zNkvH`uZIx7dqI95a&t<64y1QFaB~iH*LHpA4iq5OGb*ZzXS5X0oV8L>*H%-}R#68&
nYo9p-Su@i8mj-?iw|gF8|G9xgDLo2k0J?g~^kRwO-I)Icyl$(5

literal 0
HcmV?d00001

diff --git a/doc/assistant/running.png b/doc/assistant/running.png
new file mode 100644
index 0000000000000000000000000000000000000000..8c3b0eaf248eb8f1d544659d91e822cc01da0f40
GIT binary patch
literal 24664
zcmd43by!@@(l0tVK||0GG!WdKpuyc;2X}Y30KtPZXmEFTcMI-rfx%seL*Bj5y=UM1
zopZlG?>sY4ukKY{t5;QZt*T%5nlJ@9aa1IHBme+_Dk&kN1OPyr0sv69h|q5>c{jrJ
zZ^b)%2~8&e02%Y|4+@Z)j`!Ax;4CRCim;0K=>z6RSW~A10DuG_De_IlefhZE&t7=}
z^!kd{lZ^GwE>Ec3H&O)Wqh)@SXb^Uh>W@VDSlGSLL~Hw*E{?@kt1A%Dw2C!ot<2y<
zS_ZzU;UeR01II9exg}+UBqk54D?V+NQnsU(vC{7QUDOXUd#O^zu~Z#3+h@e;aV9TG
z*5*}N3ru5k?RUHf9+_9^SF27Fi7taacWVfNB#40|ADBaR1mDAcd!NAa?ybRaIfaLx
zUrz7usULmR@jCAZ^j{wrG)>L~o_hrpaxr1Qk;BlBeR%62;#e!Am6EZi0C?;En=bxu
z7xN^^e;t{E-Y8(dQUB9wYgEv{G#U@>KPl$h=93+)`NmtDdDOe+xSDd52-#a}bMn`}
z$XO$;b%qD9Pw$D<{TRu8-Y(N;bh_FcYv#_Yx9bsjkJNAT0qn?ojstzQ=>)aVH45*(
zYIw{O$`8-P&yUb%-9PO&20w5h;jeffVkq5;+$IC)a=EVvQTYt#eXa|I<4+0eectR3
zmejprCFUjVx&j|A@bcv31b2DgR{%Pk2?okg38Dh)q19)wdNO5>c4sBYIhuntE9Sh<
zQDLm{rTi&FCgC%kACoUUG$HP-AA2x0c2mv=u&mIvn61t|+YPHV$Uj8I#B4YW5*|!u
z-FdcGzp#41ML4<qK4`2vEL<lnz`@(9KtyxnlnnS4Z|D2tvSzFGQdJ)GE~-iT;(Fu>
z*Tm4>-uRTV^TF6>D%Io4{#oD^vulJt2F9M?aVdnjd@Pd_S8ysRks(z2)mCM4LjRY$
zHONr$w#@)gQ7xL4qO1Q5;j$;>#Yz-7y@-6-U)$Kn*=N9h?85YO#fCX+4+1y9s=s)g
zdyOKgGhny4`=7M@&S|Vt_wC(zAbN@2F0mW7^K+p3sej<t*`)D9`mBD*+rnf_Uqi2V
z$O51)&e~cY;icyhRL_=2x+~72$wFB;G273gH10M}H=KEP8FfLY&iZ=CNxb>^TF`*6
zc%S=}r0aKg(2zq<8}sU&8rpD%TmG8$%0Je>UWXjRZ7h{sOst-D^ws6YZ+sP$b2->7
z$1F-~`c6|*vsA6z6Y_9i60m7)WAk!7Bj0QkKYX3s`TXS?@<zz~l{v)`mC*Wv`s*u>
zTPQWWSP|_&*C*$92>e`oPllTm)bE`yWziMa1H~hdH=g<#ZO=3d?29j(*&~>|D;lL4
z(+9nr+ii#2!ipt17OXR;I_9H~%NYTGtWNOYa>5gQ&k*Ey8S$&z{08nn`UeKCV#9%3
z_O0OM2?z0Npw162k!p3??KH)_Y1Qd{%=<%Hea~MuI<6vM)uA%&4+pjrKOY3gck)63
zPeMXZY2%1}u2^{3?DvAuk(^(>4?Bo;9_|SN(`OcHh=Y-YXE9Ov4-=!7n-8i2shsG@
ztcuyXTCT@Yg_$)qNzsCSaWE17231Kv<r<)eQ23ft(+Ze2-~hMit3gMWuj8fuv6B7O
zSYw7&$pPK(K^WM~R^1S&F}D{dDKRwTK)%|qv7#3+K;MR(`>Eh)%t~#B+N%SD@e%98
zJKQ6A*a*aKZNLV57xtx$Cmb&`;GV!ghSSet%I%&{{AOoo$4C5$qU4HEm#b?unngW@
zEx`Vsvbb9`aB~ET(Q2t@OxcP2To**n`>wxW+Q!jo54mh$b=9O0e)5qRnM?k%CSXdk
z6n}~xWNrEbTUq7UbxV8Wah|ra?Sp4QULLu-j;5x^c3+sJylz*e7LQOM4j_;|laD$Q
z*Pjw4%j=@X-(w3|t{AhDhdgq<N+Noel|>{M?oHYIlf6iyYPY#9n4ML9Y<@!4IYW{A
zRGsm?>|ywGXy*|0^F3n$9nhc6i>#bHCDZ%3PQu<6k21)oTIJBM0i2Rh6+>8_nt_`8
zFSN<ff7pF5huJq%&$8wD2bNI{?(PBFf>7Glvh#Ef1}M6e2$eMe`?>oi^gZyrx7o#J
zahO*{`a{M;33}HYYjUP`fLHPl--tf-v)6SgjNe{IZdp1ofUFCn8_df<Rod$_6mRdn
z#~LTfd0gvzzaVL-b>WAI&`DPxZxbmiYD!IixQeahS9W(q#&!+Wn~@|m0P;eI&h6z_
zkNv%FMa>;)K6NiW*q`NAG+q~(`Bx$IWHkfH(Yic`#1u)8s_dN4X`sfYtwKM%XOrem
zR%`bMO2*+zq1%}QKhN<?X@Jaa%YpvWVTtHGYj4fMh;I*?Yk$d~-=GCO0oTVt`SF#@
zwfM;AP{#J#Z6OVPkHcfE(1yS#^+h?K^KKGk03F>Ut@nCjm+;m!c8oy6xSQ?;;$+7H
z*vSWe^CFH??jxi38AN7G_gp)-_h#7ZQ@A74(5oc#d2M&%7x_gr0zjAceMTUv70!7D
z<kpSMYM#!o@DSjiQ!Y;+VBhs>{fW!BZ8xkoX_R)?Y2yK8(@|%i?|Incv7lqrvvG(}
ziSAov+Up3>!AdN9-lSg`Ie_koSGJ~MjoOp`PE7FP{vuGx3rEq!)(F(xN@b6z5H|N7
z9MXFsPoju54bgHKcd_Bf8v`#?K6!V%-p9P+;o+sQnoT6@`*L$|aPad(_LB7{K&*p?
z)gm}y1loaHSaCCX;e*6_afdBzpV>NRg2Czlx*;EDlkU%3t6+8UU^7qpvXj~IKWOiA
zIj^}&GGj^cX_+W=90-FtTW{?ioaFmBI{)Zr-ERgtz1?g}bnrlh^0C6$P~;KS#Bg@1
z4zV^?y<bMXPKP}Iopk1XMpir82K)KG0Hjjh`?sh4ON=_vD~NtM@Jh8SR1jT@CJ_zI
z7n-CdZSbgbis#0dk||f6$k%r6>CCJ~IEzVh!{gq-V_~Y%TiKmK_WV))RtUpi8tpZ=
zulbw!GJA$QSY>c>y?MkmFc~%T`bdMre{7igsg@QJu2Y8I#Y^tu@?gm9|1J4FFSYyh
zThTRrEV?>Zp&ay#0Zt8_uhe{f@3$+I>|l@Y<=a~wlj+&jSu^__KPJj(p|AgR-IK+C
zqqU>FI&6fRI#pAsr~l-9D_>vvLe8pjPFXW?>LOpu$UpZSN8x_i?<MD2;iU!9TB2o4
zewb|2$v-LPYPdag;lpO^(7`CoL14MqnOg8`zO?{Uw&_s#mFGCE&0tFxws5yNJM0gV
zMomCh2-aa2bv9a``;3C^=n1_$f1UfD?#6j&kUbyQ=Gr~*yMw3LSpdY1?FgGY^E&_>
zgx#V!+J4*?exAqq)ZpYKSVN$LM0@wnm#ZqnvFBm19n@l#>H70J#}(LaoU`NR-jmxO
zS+|gDYe9D*P&7`3&IZSrvHLuqc7gc_56hG>15X}z`7g82PRUyBEYbfM8M8Ew=~)Z7
z0vVSfoyYAo7+0^T<eyJPMMZJ(!=2yjU21CT&R~rAh6*wy;+%Z&j!28F^Ri>_rg2xD
zU!%FepXWgyY}`@NI9AzN-*rDqIX~7axkhSm9YQ2N_vZ7A;KhEUUpe7oV|fr9Y^QX(
z+cL3iC|0%$$Qg^ds2KkkIMSyb7<;Mg{6f^6P;dOsKX^&08a(YXKX~&Z$tR)s{M+g1
zI5e|2Fj1QLwYoFsOGKqk^N0GsHl-*Z!X0qa?Q-OEBMi4muOOhZ`Sqs5&JxV^4#)Jt
z2?}WJ9Qnk>yB(%89^p&SB7RZ}g-4`KqVv$_a~IxsCAQzw8=<y}S*@2kHaF%0IRAr=
zolffxum=e&__-LP5O-`mZL;PA_`P>_hZdcEQKuZSyV(|hm2>qnz&TBd^C6zvG2lar
zl)a9Rt?aI^ugm^;Fl(GA4rF#){W)wle0SIrRq4a#j%v1XFFY9mk-M9PsVSt9L)Qz+
zf4Hu$tx-2rhuutE;Ky%+2P~g4=-oXZ(k=kGT_1~a3+tG8(Cs}3a`fUDG1?!%qYSRz
zO=p*^COPp?+?4X#x^!jpv9CP1Z;!d;LBOU`*NKkHXdkH4`>7^^kod5cq1jDWA+)I4
z`SSRnV#)y!qTk`yPYHVl&eFc{TQKnUUd51gj|<OV`!njehYO#v<3t`5#0g<mKW#hC
z`jEl>)NJMaEdS!Stn%}temoOvZ&?cJy?2MvV05{DCj|0zCeK0_A*BW%!vg^;E!wPh
zw@ZuIc@MR6P<({+rc-i+Jq-*(o%1C#&^=KOE;*@ze=RPvCZ3TF9{z{#fv(uR5F-GQ
zQF`&%r2A_aK27-g&Jly2xne(#DjKBr9qXG3xJ5-v(;p-=v@RI%HCiuSA}3w_z3a~e
zxAIFNtai)uboyOSl-P8gHPJCwc-imCdNZqw)_CP!qj*0a!Unk*&$vByyxco&TbV^`
zhz|smm6ffouKwaj3ngoc;hzg$`oXTD7w2{)btSyL0uKZ|Zi$~_N9po=G~69mA@Bno
zmKrRMzY}-fmR93UqO0SST@oXzZ&{wPskM+i5k>0lN0*oCS9ogDPS%C+4?=c}=__B1
z=gzCmyu?OQ^}mL&LV`6J8iVQIzxh=4it2CgKwX>cIB!3Wl(bwmEV>DoV_Kc!Qf1!^
zyRqK1&fjh?ma|(yX{W6k`b88B^PM`x0>@1?(N<yX&boKVP9~+uL^>VjneoZyI?~$J
z<eS4LOBxfHm0E0B2={%&eqB3xj-Gl(K2DexLeG%9PW=Y!rP@jUw+!j@>S2Ej6o1ZK
zQJGH$O1M3*rS&<#@E>c2L_ch$b$S}wG#r4u5X7&ZJSTTXiqobDKZx1=aZurlM^~J{
zzH-OIW^`J#w${0V(vf9giFZ~RgSf0AZ1x0ybAgbFohQ*@++`j{(rig2N5S!Pd&zpA
z`V^uA`lOS%81%z8#&f??UK;0NdUp+XfR_vRT{}+f{Ij!30Xp+C)cT*p7(tQHSNq1^
z<AZt#U35*f!<wcWlQF^Ru>SRTzL;Ir`gc4PF)*9sxC6L}&vVs^2df^RdF-Hg@K+;n
zdJnD($;F<}TfD^iUl5%x&RY=H@1J=!2H9M^O;4^={qBc|aVpsbyqYcNs#(=FjVt+g
z^f6xc&cluN{O%c?_BZBDIxm)o2Twh|WH!M`FIfeR1?G22Y_9%z-R%jBSENO<VmJN9
z;dO#ktC0CS<Q{6X%{p;J9rYGYI153K!aF@n{J?m1&q%lJK?ukOkzw8jTFZrW4eA-;
z{Gim&fVp>%WU^eMth<Z8etv%50~={n-Rn2>;baCH7PI(eCkQw`ESz+1^YhmzKGoA5
zx(t#4{PJbY^Q+my%=RNg2Y0wLCR)!rybh=Hjf{+ViO{<U-BvLK=yE4|$l4ALd7iB{
z{;;3Br_k=oWnTT5bc0BawWc#_pU+}yuiw8;Z<PO7A^gB;HROQBhk2V}uO9hr;uBG;
z)lw5!$h$gVNawu(ixD?XKE%btn9k|CMzH0xlk>einNf8d(qI<!LNbG{Wjk<_ocwq{
zZ1vM2Y-Sy>{NQ;-X^w1OI?M6n{FZ&>Tl(m-pi8|s+UEr#>-B^F*=+vq?jp@?BQ0-L
zx+BaF!mekF#CzoDtkK5n*W&rB*AlAAJWPO(sV5%{G1-X=&Du5e4Bn3wb;{_3oLk?8
zn&FNUYG!-DN=_ykeUW0asy+{u_VYeYG-G`QCyI579&ETfoIf!9IroNRiaaKUc7IqL
zjo@I*1T|J{OD*wL4dAvtF0s%pRy{6d>G7}aWGVPw4;<Bq(Jh_}YUbYLa&D_&jhsJZ
zp7F2zfcr$`4tbz{ygmNd3sc&6l`H^d%8j#1JLbpn8jB6t+PQ-CKg9TJc96ef92~q*
zhuxs)e>kw{qD$VZMDqAftXbtun6f9WRvD#5<J8o-(!345t5J=A4uryun&^TmsL&8f
z+HjgIJeY(tdU|el8cp8Vu}g0AW*WskDF4)K9aSjl%-UO?vQ%0F9RPfJ{F}Y3CbI-R
zT#hn!!ZNY2#AWUpfS0DQV|2Ia-A3w`mJyobkD|~g^dUpo>(lx%yNrQX6fU9Pr_vNA
zH7vf$0W}bGOT3xgd+rTkVjqTvvbIG{KZ`%GOD=YnWo7zpeoLHl<UiM`CeId5qSL#6
zFcDw1&Gbc~OQ=lTn(5_B?tlXeJ&1r&P*L+!88I2he0@)4)`Q$ON<GhwDc!GvX?Ls7
zh@A{8eqdCZh!ZsVl8#V46ka{st=FDs4p#Vj+CsMXN{z|zu7C_#lsa2ZvWNW>9W#C!
z-jmbbiI?F){eS)(xmcZnLOs+`ll|eO)%Zw8c{g5=5s<5@d}m*}VC1!v%UWEAQ*3Pt
z{T%i;0LF&S)i?F~g<rj(&o(-qN91`n?hnt0a#$H(uCLoN-FW=&7v22AUfxVUujg?j
z1~&?YsMM2#id+S_IR(zGPyW<+^DF{CIy%`omSN>yoPAM`0j`xFW*{zghupYh2M<~M
z9#W2vGiqfmWcoZ{M>3>`+f8z7I2>$^TV182j~qltO}OFlKmUG(By0)qkjd9f@HU(8
zK38s_HEizvoK7|(On)hQsum}*uh2MU!Tagf*jbq2?UgIW&eGuBXYaWEjZI`zoDx;Q
zQ)}nro<8Kay+_5(67kxT*j2N9D^J#1k!S9n&iRB2mNcIU!^fxd#lBC*2LkQan_>@|
z0HZ9%kKFB+S1_MZ{H||@xl%>gS^L5@zsbo>yuo4zR}b#IM9J(y)J_xW+-IGyz9L~o
zvN%NQA?Qy;GtpnKc5|j;A-2N5Lfc<*5!ASepBemSJvt5+Wsm;#IBv<DvW>>U!)&bX
zI&Yr2tS_Z+r!<P_pN^d=<q)Vs?4{fhGer>(wu-Cr(`3-`RSJ7;c$~RXevR`hdr)dq
z4Sl$JSP($9of0|O4}(uyWbQIzD`l1Mc(TG_@;3i%zR>Ov5Wx6CSjw~O=<(bhK+H!n
z(RR?<n-aQ(TyQE+ymkrgudeTd-F15+5959__X>YL#0T2&6lCw&@v4ZaBR+~|nK!;9
z@}aYnX)<=7<(zbY^xA@tye|y*EDws#>}OiDbGU>i`#O<G^oO1x=*APG8<zo%=5J1{
zz{xJ_)5pDwOvu4tU*@QQ-Pw+zJO6oQ8gUb^`u)c1nQq_WJpmzM)XvZPvA*TNMAX+6
zfl|CkXfsVZ*i!@hI5+@zuTRhi99N;C;U7k)K<uE{pFB`>a5$`0HBBEHa}+>2`JgV)
zk1NGgcfD<04$_~)LFjn525j4Hqny>zZQnVoE8g=)^KOO_KkpYIcf?kI+3<O6&3*N_
z*9Guyrtt#q<Iy9?!tb+^J@8-%_{R`%F6@U77+sb)4=2d6rGxr;b#6tudxv$#da0O>
zBMx$kOySE(awdgx*q7qWzs0>n^l0L5#>Tm5vU`yI3gS>~74G?i%1Wv<S;Q$0FP29u
zWW=I$e0#E@?{hO}{F${RH^=frrQf(VLx;L1dF$#dL@{nH3W09B8>2C8kXU284}gw2
z-o56!#F>wa{~=GtwjPqkOZ;|ETVL(gZ*fNgs@3&h<SRUFQImwndU=6Z@sU||Rq%+y
zLN-Js``rkyKQL)%WZa)i5%YvG(0PG<2d|#=2W7E8al3<<F$S$Jl=sKp0ub&K-j~g|
zhZ--jgG<p&feeVt262e^xA%Rrz^B_nVaiXOX;FLf43|2Pn-#yR=&><`E?8<O$R*{&
zh7Q{s!Z>c@U>2TiN9{YyYW?!SxSmmrAx3?rrh-J5`s^+IzK=fb*T(FTscWI!`M|MJ
zjeO@rdFzHjW*ubGVl1O^yZa1=b0TYcCWdYT55gep0aFzdd-iU-;Ob#frsDLBX%yu}
z%#2)!D7>Td4{=B0omr+mgP7<7qu-;zfxL#e*?A`NXiaU2I5UcHFVY*dtVDhF1`w$|
z^SJx}K;UPBkCa)b&5Z4Pg3AF(h>5|wz`P;I#uCp9eoc)oA;YR~;BnuvDO$7tUko}f
z)nqz?x0V12@P=onn*4>TVe@7Fg56Dfzk80YL!tkY{TraJmHF3EBfm);a?in<lli{v
z8*VKk{eBnvZx;#6BuTL2Kj8Em>086E1j)Z>c_WTi%9p<wd0x{_rQZwK`YBlAAA0N%
zgVSG{6o0{Qa+s6<_3Hob`7fM3Q0X5Mg%R>MCWuo1Ld*ZN_Al(5>VMDT|C`}|u=qC^
z|9@ckA7lD2NBAEM|0UFakK*4V{;$U5Z35y+?9r>dv-5jOn>-*B_^T3q2Y24}g^t_$
z$jHdLFRRS_{F!>goi8VLoVKgKINk(JVoP?~b~RDyb7FOvDC=Y}557_A_$w`29^2KX
zts74}i;?G*4TzX8<=;l}X*mOn0-5E`e@K+yYS#mFf3@)673%-t2L3A+|5IoGdx`vq
zqW`_T^4}FI$$wW%|G%=FF{J%C<gV0bgvhvbrrh+Od5TzoMpU^fSARHI;O-Wx+vsvE
zv?-3$;QhTje!mXGLZm}?v<tW?$cK+_tKD$kIqZ+zJ<@)siWa$Kt}V>UI{=!nT`xmB
zoGoLYw@UjO=DdAl86h>$6kaI%rzz<0H?hZv&5EK5UulcTtGZ5SomQTo>7pC}pjU2n
zjDH^E@{(Cr@*@OXI3cv^O=SW-g#2X9;e0pgN$H*6G)x~S?z34czu@m@V%57Yj0D;|
zTeinyN?<W#q0^w<gogzh17PM+s{H*DD?8fVFHZ_iZGFzU+_iZh?EPKf8Z?Xnm^7&V
zeqcBN0q_LSB>`|4X_Var@W569YXBBM(tla72(mr+@&Npya(`gqo__DzMJt2Z451;#
zJ0zd!$*|6}7WyOUuPBpXLhtWYV}yCnWE%mi6D!!8q8EkYud@94n{)q{Ce}g!SQ*R8
zloLEFGI}xI?`b>mR;X;^DTLi(?^s#uFcKxHV-{O|rrd}zk4%wX>U2$^U<5ysna7{f
z9riuU!cf?FpTEGh*(ppvKC#T)v8>@pE87%y@0|;N{@%buTUgg|+RRcoiVT!jNAD$Z
z6wmX!>@{xd7i?UbpZ{G>T=TWtlN3X!e3Mp6igX?tsOfqTf(qzkF;KlyEX=NGoilHM
z@t1;^?S~iZ;ComJ6i&Pn$>?a`I0k@&>5!MVb*f#_NdUhUR`!`1ps5%}RBid*AJ4SA
zXn(yC29T$QpQtWN@O*AGTZ}*$7ypWibM_M%KrU32=<Oj1Cvrq(3sh`1AOvVu*n<N&
zU&8g+<`UJN2H9nAatL1kc$^2DmBBC=11DGbP~y8n9klySj>}ma?m*U%z*HfFiG6&;
zXQR^=e?>k%T{+>5jyd!2{W*mdWvdAC9NKxzkd;+)%R>&Wt!ts50npScX-KdoG!=yU
zYl>E9oNt3=R61&qQ!!_qOHzRW=r<jlaDqfGn1<6|o@7x?GT_nu*Uo}Nou${lML@U!
zYXd^67ULpyaGzqc>d#JchpGOmg;|$SowGv480Guihv`+mVdo^aZSN8&Ryf<|CC}UE
z^P`@*gt`Lc<<Ur%xJDIQt47DcXW!&Ja8vuVYPp-oi+l^pdlPYTM)wK<2vX$ArKP6H
z!uz{#@V_=pPNuysQKGz3A0k!8nNTQ)PVHB|f=BRW^>(2dfJKwx4K}*tPfoCoHgSy(
zgsZ=+Y}7f`^I-)yezvze{90ElUR_2JR94innC`WzCm?oLb`ttoOXS}>t5iu04e<5#
zXyz!PHjuN&N3&gV@kRu&06uP>IBCYXd0l#e-G~kGs%gra`~%o&7g*VVAMI`SOo{x9
zC*NaPopKhxP{*GT*n2=_vt=24cw&-^NYPtUTQRwV7Q`X>^TvbN&4x+M*3LGNgi?iX
zB`n0oOEwcv54D~zu|a~SCC9Pa$jn5!69I7V54%p9J2%%f+EiGiR9*iOkUM{S_X!Ho
zGb)>U=6CtQ?5L_`3i&o^AHlqRlS49*Aj4*qie%YT12_f-cmuEcHUofU`^9yVH2)|=
zCquANFgJ8iFsJ?zc0!VDVn-{M30TlaJc+(qZ;iUw+{wfG-~~#;w1HsI3l}UsnciH$
z1mB3?9f9uik6Leoi9&r*a%&GsIOma(X=zu|-oC-9Qh*n|IyNFuf;Qj!QIMMG&D7Bj
z0!IUps2Zt1>90L|aj8abnG6W2U_<tEOWR2J|J(~OlzmASN<s~*;I(?xVGj89-avSq
z0igG**q3qh`-+mfSNf;<(Yx7Q#5hM?U1dtn>0Nc=5`N!bHSOHe%Ba64Ba%Yqi$t*=
zXe#sy$9poE@gD(#DVz={Tnt)G-xOmDWu`+Fwfihi%l0o#)V@iAr$%l~eSNw8D@fDL
zEs$o)TZTW&?>?UoW{cRw>N!K%>mRQT<fo%(Zms9e4WgUh5{rse;1==Px}@?znIk6(
z!UJZy-fNguSvO8~5t`R88~>HNyz+s<x0fm1L3EWmPH{`sqJ+=F&_LkO=vVsgE3tNF
z1tWvFk-}$SnnYujEncU(T-gA{Ryx}@?}<NXdVP8byEU|vjfd6o^4&((mQ&Xq+$OSS
zpUXY&+>82aT+iHQAg>!XS$uNnD~dbC#$mwO<eP(rCR~H8cNkbnCI%`ZE97EfB_;GR
z<{MKG(i+7C*r>tX2MhZ8G<&uqf<=oMFBtco?^cA*uAytj_q=95*8}pER8(xXC&1&y
zYp!|Y0_3VmU}wWWeMM9oL)gd1$NLO6s$sQAv{23~2DVmz%!@vqLksE++h*we%mY7$
zKBGUi?wQv6>oN-YG~+kVeGK-ZAJJ8ez@mB?%}(--@Ei98B6fwuDFOC<Z8wmUpk6yv
z0%!yziN$PU8=^5+L2+^0hSc*BRjoqEyJWdlK7u#}X=Pm1SG^L8IESLR{tdTi6V0jR
zU)YfXwEStfYqNU<YIly~kbWi>?$1`GJY!c+M7+4#x>73A_DK#1|0a0Yk6V)pkOGub
zg{wi6=$Bqi(%rNN7|dAIv;h1Wm52K!X|ibExgdi>F1$>B8mGsLr56%1DI1(W6Mxz0
z;2bl*oh-C@v=v@hia&!~96xnFZ680K`)pO#?IfH<_@+T#W^~PN-cGsc7QS9O;Chn{
z>%akGZbpXh<lHj&9!`l7))#7{H{dGM`Mh?nW*&cHfon77v-rG>Zu7=KZA?}T_d%*@
z#NMQEEkeN^>@J$|`huH!dW-d)v&c=FW@tuGqk$$)P3jz<iFyIn(=u%ciX_P#j*TA5
zt>ai#64cc}gwP5kM$KL*FF2<eu<(nj^&P8ap{11-^)V|>6GLlFts1c-EPf1c3$B)p
z$MkCK!$>AdpvU_FUifK^phTf9x0)quHH!#BoLU6H_k8f4uGa&DdphoT4nh9X*q2$9
zV4c(wbYbSy7wH^0q%eIbX623gP^kOEuLAi>7UIe4y9;epdB4<1!IvxSRqRYL)+cB1
zze~>&OX~nKVy}W(`b8#j(V--tkUzls%V{sVwPE;oEEG-Kz}Zh(Z;#RczPFN5dQg!p
z(#9v>OP}3&Gk(cW8&Lx2T<2AnV1om%3Ht4Wb;{<5W>y#?MwA2V=0f>V6?7Opc;8$%
zCR(-+7a497-RCY@kR5@F=SAnc7Xb<PxdVsvqX)9Ir(egAu}JPJo+ac$dA_!R5pP|1
z;1ZI>q+Q5aP3mb}IXu&4^Wh!Y64;j{KY<$)(VFHPO=gPja9<#s$jPDt;bW}V8cC?Z
zS^<2oflmguoE<PP=3BIR4tjVBn;o*2N~;6zjy~UoQKNj@&&1wec?Bi)jz*hUes`zS
z31bW;Mcf^wAMlQ@a^%kfI`l&zLhsnpE=7-0e>YMF{(#$bS^?o8`|}53_|xfA1IRt3
zygD;iCJ30c0f;6@6D<kecq0lxst*ycit32d_P(Arv6jwo?CA7(yhKR6)L13E<(n{>
z{K5ivh9wXY`zV!oC0-FVTpu4%nxUV&UMD^w0i;!EOor`x#4R*wZI{KLWlPm5mR@$a
zD5JQtJc+Z?(K`XQ{*5HNl4tPtW`F3jUN73X?pE9`KhID5k?i!sY~Xe!Z<2b!RUWKa
zb;BjuQJv|>o+QVQpZAqI`Q1SZ-8QoBkIc-Ts-5@H9a%jf1qKuAjhDyVy)VHm0B<6-
zN?nUT^8(K<wEO3gFPv&tYF8e$ltvTLXC^EGxJuB2)R;G-Fe_mLHeNRYibBxmQ2X=V
zQywJS?Riz*QbEz1)}iPzfhTaY!=oD|A94>B4lrsL%0dTGP&A=R2}8k8w_f;8b?j4=
zsSh+p3te455z1DKIbep=_nlr>o^Hg1JGH=dEp32=hmylf1M{7Ay(#R@Unv3Poxj%?
zOzwI-rs(3NP+)`sZ~h~EF;)%_U1CBUKck|wIz}5csnpr0fFJNN&O2X)>BNUdb<I}H
zOp<Y;5P33q1I2s)#+|kAif?*#jHlCq^9?a}$}*{3e_zwV&H}tE^I+r2xklCD;%0K+
zVdOl$hJVKWnmvxa!A_liKlUeCQn!8c9=z=3!~5z>3E1^ryMuthn4BB$mX4rj4v7G6
zrSoBDePxDXg<~kBZ43b0LRpf_PN73rjhQ&?y}6~3dA*7=NsiM6i#;JIyr$BKaN8VF
zZ&F?cKx_1wY06?um#ws}4Nv1aY!k1bk&BONEsD$~nDTg@z{~>GNHnoKfInhpc^%5D
z6}QN4ia4A(0gDQIfB{gYiBb?i3K;SJa`$?nmhx1NOWz$e)>i!ZGYf9=J)m)h^gZ0M
zp)3G~iF5<?WkggRUVr;$5vqxhBY;ceH_lHQkjD9}W!hs4Am!S#SZ04iWY$tSIy7$z
zo2C_?6<}xQRw+YqaLX)gC8PHs7}12GFm}@9F5T*<G$Bd(CfW9@l^UUo9F)b3<1YW8
z*Qd$$kI#`N!P$owBby!_yDK1!Ni6jVd^w(uSf7pdB~V)=_vXds)kBCM`$frAhJ%@}
zLq)W2Sd0JxO8Y5Hn+BGr{3+*eJ_LZ8A7O12D4pdCOS4ZGVwd5uisj2jGz)k|DR#>*
zA^I_7T@ZL^_G$|9hXSM(UlnMP$Kz@|wE%{W;j6vd^@ZnA5WCJ{^k-Zf=T3J!U=<V;
z?HU(P)^65ZcRAHcOVPeO2-;Q9)@q&LAe2O(CQI+-E5(Y|duS{20KAU-8#i4|%~miN
z{UhmuRRDsqWYG5v?$?AmpYQC93-*NlB8GM!(rL@~ZG&5|0AQxGRTcUne}(k=m)}#B
z*3QETa4?UqfTWHcDI09JX~W%h%MhJnkcNlyKHE3MrfV_bq_wQb`rs0*9nwTNB`ER-
zd@udvDYjn<nLm__YDTV_o6~!9aB1tH4hWhP*91Nu<l!F7^ta3zQdHf02-CgvP>usS
z_^CD5?sxo+_Iec|6a#}<+^R7+;lfEGnv?nk;^o{|j>Pnv7u%><e$DpypbdEMxAGA@
zx-e0az#YGlGOmB-2UB$e#I>^ZZ(Xn{v9V<T!q{zK{{0FTn(+|s6^^L6_Bm#<z25$l
zhLf<eF72kk@K@9s+gPy!KdbC=14e5b`@7|@uE(niYv*GP(OR$W#)m~#CwG9&gG3bz
zCs);?=DRg;Yp69Peq32mEWLS+@R_KcGJQJb<|#J5C5+g?AWgrG88p{ACoGA2HX=i-
z<YfZjYosecvw0-U41(o@XN_TVVcJQXx@=$-bR}YDWFr8)?xESZR*hy@8!)upDY*f<
z{Q~MLW8PV!>o+Rmwkh|KG*-PA%vv*I(}FrTfpcVjbFg{gYNaqtyQ1RKxBvrNgJ>#~
zy)PcYtKG37VvAavr!Kdr=9aY^Bd1xBPSX)rho9M~*WUf`h`;)BelYop=y1A_EBj8I
z*-UYu{<pZ~Q`cFcD6QhHW5-T<O6c$_MJCB2V_BiV)1~j;+8wP)Awq|7XO$rbbG))?
zwHVYeJV1>xv-sFIy9m;3NtRnIrJ+D|B|vAlGN;?%U^iB;Wy9@OWn#C1EZX`;#vv_*
z#PQf^s?cb%P^X=z8eYrR3UFSk&d<9E&UuV02;l#<5+AXR1UQYzsF(Et{3Kn`Ri*>v
zq0oR!0i^y%?Vj^VvkL&J5l%8P^e(;jQtO>{-0-8u<Gl_I>M7Mer(d7_48?L3ux0M0
zKrvl<(j7ve5_B?ck=*wt7OqeqeHeJvr?uV&rksTUAQ#2n19y&0<xgPjCZ554CxyFl
z1-#!^KUSCZRds3~5D;||tr(%eKtD9bPfYNN-ol~jv6NBr(6ykxTb<$iejv51PgUYq
zu};Idkr><EY4VRD6CO0e-ah-ktlZH>dD;XR_a7AA;C%#m!I8oELGE8_ZzC;=Z&qj>
z{oGCmq9*-<KB>vwzm-m;_qen^`Y9*}#v^lX7xuX5adV}zAx_<ljc+*UNz{*TFOU-#
zRGOILl^qu}M3WC04SJMov%17dPd%7oF8%Ae9~NaRPy(b0u5Rv1%1fjQEQ)Gpz}4vI
z{XIe_>*bDBOsSfSPf?#WRkoOEWRE!D7xnW?My<~57FGx;+%?a?e3ZJG{}8N(Qe`dN
z-W|*f_+(jv6)@cGNo`bC#L2;d3Wa*}m}=@$x3?sTUEC+Lm+d24ZW`0PaI_7X7gP(;
z$zRE%8V_qURQ@%>>H1)%Rr369q4+XUw;V!~Q1bj{?fIh66<o_36~vAyA#H+5<fRJA
z%ITPwjxwGT@+B(MQ`o_LE$L!QQ>QpVgO&v6U%PR?sa0jG)T<Jmt_bDV#p)xX-z}iv
z*<`Z>yGsD&oM8n!#1<C%U$_xF)XF7<J<4_L9qgRcl{w1_NP!YLbX3%3N?~IsG|6jF
z{wA6s21>K^jQOrI1KfuL9$%s2X~@*!`Mf1vO`X}15^9vq&K_m##_y-MGMox2o%Y(n
zefyY&&<nVtv~^UV(run@h~Q0Ht>46bZpK0TeumRQRIB6bBvR*S8L>8>VgAu4h@0<a
zhl5$8hQ-SwO{?D?oh0aOXD!Q`f8rj*oYN7n%62g1^J@>`T_crjz`~1AXATf1M1x5X
z2lI@Pw)QU-1*dVO00wseDUJ~QHeL@It?Xq(*o`Fc#~$SSgGf6a5N)**NMRz%2@E5p
zkrSl@8U^{4;Tuw1NZ(b{gy(7t5f9j5AOOu?@TDlF<t87f>qUG1ga=_(A>b>1SZOqM
z-434B*vJXPN59B;AG*FC{rE@$s0qy3U(=pZ<6mTp6O4zm2|GI~5?N0-?(KJw^K{_v
zpGYGw^mEc`Gwff}k9iO(LBH=oVEhS1w;2FM!2iQTaHyMHfZUBe$^KQV8XeRosUO%3
z6?uOiwQ}x7arhFo1j=B^0A~0jMDlV~*5GM1oLC}sCGU3nn4=>G=2$txd$<fb>Ao-k
z61`RyXhmkH{cs`2y$c?jv1A>F)J_zPW0{MZR`qBo&D9pQ<l?z7WX2~0N${^(3e>Aj
zpumt{e~>^dp8)goYu$UJC?GM}hs(1;PAYBRFQDPtu@KDY)Aq!!_kfQ-p%z~@3@0{m
zRS4J0aTJ~~v2>v<v%IFccR!x{#i=xKR3@{`{)QcAF_RuK4oHfy{u|gC`dc9ayK#l%
zvh>T!l-~V$0KHvq4^$JxP>TH#C9fn3J5`B$PdZR(-&zVpVB3YUxPlANM4{6BfTbI&
zgM#-tmtRO>B)$G$xO2f5lL^v6jQ@Ly<G;e+{}aCcziP^%?4sOgd>-1`Y>C^AWA7S&
z<*c-PD_l70Or~9ofRyCkHi4EqYFW>zOxEFppuL#+pm;JZ(zw<Y2wj;_d;91=#pGxv
zL<<+Jz2nr}N{CEV6{&wb+eVt7ceNj_$e1LEp4%y~JRC>Q*2Z^lv|c4K)gD0+Gaj9I
zye7x$Y-V&{C3avEou0R(!4B3+fS)=2o>p!zB{oj;*vV3{s5U*K#%>iu^y7`m5IthH
z_Q!wm&>cBOA7j5!<I%v>&|aLu*KkUprUtyhw15N&i@m;g^C<JM^UzJX(rCVsCD@I;
z*tb}Roqm`3MQ&oMKu1wUIzxJ(tUnpGb`PO>I7h9S(Gj|Kg7`j@@U#k7lKfAt3wzX^
z1`F@pCYl~?fuuOJs)9e^`54ykuxj&}vJL1ZJ-Fol^x*tv)k17WRRgw;<rvDm^VDgn
zNF!(M@G~5VBs_XYU@Ms;YxG3<?M#9<P_}qWDJp5Hd-bE;R<zl22=C&BOqy2de3BI9
z<M()*H6_g}SKO|ui3lD}wKM){^7jXTBCm>?wudH(zT-uO_R2!a=Kg#+;T?lq-Cbi=
zkw|eeH=0sc;a{5+t=U3NF&J9a(b0r9gbc0PRG3ZS(&V3SZ2h4Wo@89+PIG#reAFoQ
zdo(!JE$}w&l{@E#li!u4SxLb;>Jq^9(4>~3fd7=)@EtqWex#|^Rn{GmsK2lQv6;4l
zT5^uo%Dv!}L<Q4L4w9BrIX5tapVf?uAdUg`T)*t;;%5}_fP@)5Jj=&wZb{!i(yY^A
zSl!vLBU|O;^>1+yr~kHBFD4Pk-9UGUbiAD>w5?xW6G}9f&@L}sn{PR2&%BqaX_z>D
z#0e6H7Nl;lq7DD(;o#YgGr97Yr;Zw@KDDC-EmEAsNJvm()Ms6vYL1RjBfaGZW0&#F
zoCdMnIchBC%&2~$Vq2wFF6)UF8$y69?*cq<V`T)7&sM4eIq~C)K>X?_iWz$9XzZh?
z$$kg-YanvJ4gcc2c^y}<VSt%(HB+{_u$Op;T!KBUbmdmu#fP`KO1D}gbCLFR$sv!V
zSuOEPJZZ)h3doFp4TB>s0BG#ZF{>5%{7s6M(gigM?Z#KssrK{_)DlD(RYp`>S9o?W
z8Dg%r<f%QfEHYLh+>(os@+fRl4jsD1<kmSAwA@=}zCe011*5i>d9+-S5!&rjXMV@V
zMi5;os3Dp?vgoNzBQLT0l*TTOer<WTz^?IO`9rvbe>QJa_aY&$(Ge@kFni8$XSww?
z&<uI>_-h`YXO|9F_CNYqG~m*i@9`{&K8hylI?Xkqw@>++!#g%eh4zc%mx2CPX2@gj
zyO;MXML{cCq?;4T1j~wRYX_o2U%(~kx0ZKS(L_|d&cD=K{mgRtPJj``DO=|aXc)?V
z5^mT2xkm~;G@D$CjpcJ44xMsonEDS~$&YPC)>W;gXcjR<?@#$umZ)oP8f1`2i`|`m
zH8;D)EbkQjX@QXEIK+9884tX>;o2gkT@)&Q>r#St7)|tZmUwxdv;of3hc5n22`pq9
zo~X%@$>vGiMv5$$uc5J}L!5UXXO)77t+%Bw$4zUM%31F|I$}Q*&*!YDe=&oeoP^#@
zrfRe)VU&BDPp&==sy+^AFoIuzBG{ikX_wv=Ni~<IPH*2R0e)Ixr)ep+yVQDa=Tde+
zJB-;`F4&bUcIu%3Xv$}Eilydo$}1!`w3<5>^?xs}6wauMHQQJTz8dxyxXOFKnR?Tq
zL}P*Bof_O5dox(<{Bj#q_K|J!2$<j2YXrpx-U1@*B^N&w)fFp84FE-|fi2mW0R>0j
zrSL=Bbn&5j0sdOF^&wPAVpXDdu4%qb9_?yK6}Js>aRItM4yM&EbCj^yPj^&s?-FCq
zo}c5!SLIbpVc)A;TUwT_=C0$H{RsP%g^9}PQxUP3C5i4a^;eoj&^xf&R1bT;uY!PY
z{R8s_BWoqoToj?rv|ETtuDxHb|JpJcQvS609~j_aV-Xv^bSIqu)bBzC8fBb*e<<X|
zCPIqhu5H=3m9V4fAxfMm<UMXva35n_$)4fsm_`?>N6zmU3tC`9O9G37{kakob;NX$
z<0Ap|{IJdUCRtat+>x+0dYM;a897OV___Re1dc3?c(qeD&EsKQgkN%N`HE3Bi@L$2
zVm5Rt-<Lm0OB(2f6=#om<e)^O!J~1r<^v;2Qape~B=$u9Vx&>+MvH3NOP@FD3#F(f
z#2)S^7HCYmcc7aWt>q8gTnndMs-H2XR6q_wd@a332rGHd<%l;ivsiziB}1HhFz8M~
zr2l+LHJK1o@d(d|a;=K?Z7tQwWw0wp0JGg_x~WqsCG9n6XyK#0RJDFg8V4%Voxq7e
zQ#g;aI=@E&+m5kOZ^DU;C5VLi^VZKBAFEh2^3YLe25?xu8Y*#ee+h0E)YTNXU+;$|
zveQGlE!dkjj*JVL#T6f3YmES-9iZ2{O6w4|@CFq~_5N5WB(zq<zWVOPV`{rpT|Rd-
zUgAgy-$0S;?R^j-OlyK?r}g6eRTsCkT=)kKt6UK)wM)gY%<ZHIt^`XSW;D=(lK>`A
z$rRSHxGO%^<kWU_C~oh^&)6@lZp5x8#>2{fHI}92bE8(5Zq!JyKs+Y<J6vp0!V^Qp
zA>f*v*k%^E$`+xklN(8<1gi`)(wruzPD^%WB8ui@KRPI?r6jkwC_Q9&3LE~uKlGLf
z`ddqX;Z%N#O7KilWSk=un$381;{G*vLkr(T$kBl%T6t%&&3KDZNADrM&D@B{T>Z-J
z*$L3mS<;;=^NNzQ8godZv`{V$9EXo%I3&Y78;{gr|9W1lgmg$QR>k%y`d9GMpCPR9
z2DEmeOk_dQNgMF*QLJ#b-MZV>BhFE&d=17xEkKyZWrzpxyQ2n*Vuaan0>@R~C>%#E
zzjQ&099#~A;9E-s^P)%4TiQr2^#vD|sd>L)z&1vQS~mMB-@uVBxYjZ8gH>bPx6Lf=
zu!v#YEV1OvT1T6tFt?ZSM>5RY0mZm_CZH1@mUMPJtEbnHG2Jrp56QyvFX8W34A@-;
zTAVuNT2x7g%9mPeTVSHszmE*M`I=+$(0OLdfW!`@W?U>Vg-xZhGmWccZ(|fGCgrLB
zttjSJWeWZMhPtk`Paa?NK^tawR9Hv=q~M&%(_!_!LgiqljWu0lH^%gg2~0+|hU%f8
zRSjqWZ^?k>TC`KWMXhBtSMj+Ldm~9JqfcHJB&+bZ+udYQHo<991=0Z;`(UY&l}{_1
z=0U9s^Ubxk;^KyiQ%TK8F3TZmM%fJY3%_?j={Y^i<6p{AZOZmkn^5hYHPDjkXB))l
z@n+W9bns#FZLPeNY5yV*EvWV78JH0T4hh~a+7abO2!COPdYAc2lhiPi=^{T83YUH)
zj-)zHqL6Y_TNo<~bBmLRPTOW(>JN!$<)zkvD+Ky)^HN~C<ba{NA&E@ZCRKLN;=24=
zCz+$#xB%-&5?=eaKvg|~#n&=w2D#(8;dU~}UuT3-`?h_fldUtmz*pObmUsZhuB3Oc
z$y=1?a<>@?aH#|Lvv5pVL@LFbz(hIQ*loNaL{3t=Fd2i(q#wIgH4sgCsUcd}4$Psh
zdQ!$iX9d3gVf=vIs<`sLc+RxmIkeDYw1OkMwfD<U6C2z0vJZnr43C3cNHQFLIZblZ
z6@<&JCfc-F>?{38)0VPAii#P(Vk55oD-=F<V)yV5FmtO0yGS|Mcw8lgpk>$gjv^Ao
z#a+_4Bq-8}UAzgfR3cbTFQQ$WCgxo8>ZeG(M{+^6v9Qn=IPBI&cIOCmFsnalSc~^U
zUlZ|-G_D0zgNx6E9Gl(JT(_HRi%9r$$t5Ji<>FJR82$R;l2=uO3z*-7U~h*<pw#dz
zDMT*2cBUVZJnc?hR)qb-O-<O&n>4>a|MB6D9y8A-(ghv^k#$?gCrgU9o_7pHdbZoO
zg1NGX4RSS~G3eGpq>uA8M+x6{xLRO2HS6g6tjHYqtt{f;06yy%89}j*wg++@aw!R&
zb6xM|vEu-Lz`+dRAp$6YsH+~a!N~8Sxn+3Eh3q0MMW16Fun^U-ira#NKmBBSPiY{n
zLYZz}Y%|-s!PCNMKr7-KY3YcM6naEw@ZJo8y2c%!AxiaoyZd|YwDL0lQlU*I?8N%p
zwzYHx$+v6~N)X2}(<L>l?AZHELH4p6XJbXDm=1m#&w#)+4vZ1I{^QzyRvJ8C4n92G
zVtAKx)4|nFmvkxF!tn9I;n9%}6q`+?4=mF_ZRd{mGXxQQwe2JBp0;WtZ+C7b!$P7q
z`Ot{d*ljbFtO`ah(QYis-;Kf5bFUXN8J{xmM%=8cW5WxbonvoFzs_@+Z4VbJmrHa?
z^9+&(VIB3!NP(P&9Yh{KZa2&Ez;4IQE8&X(0BLS^m9|VjzFvD*5lLnnJ2?ciyl{Rn
zQC%@<yqobM3jWI6`?jkqmY)I#g~aTSwhn16M%M^**nFs&r2AM393PTPs)^D+o4Ke=
z3c3g!3I4lVkMhLo^s}1gKA0B5m^E+w-CyRhQoRFe`1$R5Tjk4`5Q5mt1KQ=Mzwc+8
z5%t^2J<shYW!xwyFd-jip-sNMj;$~v19xhst2vr?^Y!+#hVuRH8v=w{_O9$pYLR(9
zpbP3PAA*&69&7(l@Jpk84(+X)BoQE4A}1js9bkNOP`1y|jiX61@|DsGdXb#>;{~&&
zwumL3Xw*=+Aq~#BUDBTkP>#U6z?8(XU4c=(Cmj>j@waR_cWr#*uHnOfkpl=6w_Xh&
zrSgf|M2VFuQyKDpiU?L(%j~K=sri3pDyJW;z{eGK%v|Jv1jE*boRnBxn8oUBPkniG
zf5OQ+RFA415J$aQIep>)26lm^LZE&Cp5>qt2_1J|*)`~>WKA^m(^HvThYpawf*N~>
z(wAr9(DW$0#I5lZTLK&ETT+I$rPaE(Joyi5r<#3CVzOn!nvnm<Fg`QL)~p?hr5M_#
zH8<q7?7PeBDyD2$YNNNVT8BtkFQ_E5D4jUpzrDvU1!Bd>MMfno^FAXD1^@^`dQIrd
zEbkOEBAJ(#YBG4zYQOf47y^9sR5%u$tk5jJMD~Y`=(>0X(<|Mm0UFkmY-~QuzVK(H
zRC6uW9EH4$8E`wRUIPHc8-M>7pt=N0Q1|AWn?r4b!br^@wq=y4lc&^xpDz8|oOd^N
z8tTvc9dx#6pR`p{O0sF=9cH8R1*tA*Zr<{M(nS{uS|RbYrFDhYr{5wYSnrq;3Yqa*
z7Z6zDizk`L7k<EA7>AS>-wv8bNaEw8sk{DQyLoc{oN|0T5wiTfLEGek!l=?ys9Mj<
zHd}(J*j3w3`sQ7j?JH3>Aj31QINRqA>SXps@_nDRX~>xg&Y!w|!y-7qZ|6L1<?4E=
z?jqPl2D7@qQSn+g&y_TXT{0^TlvMtrPId9&k4&D8<qF1%<vRAz);=tCYir(ZMiYX|
z(<#JR=rUY`EH$l`PMR{;Q!|1Dlsp+|MT3%%58@}^k;uzbTI-uskm>>K{YbfMm}+XJ
zw9{^%D2Tp!J~@B25dsa@^^>EnT&In4CQ5aGETW;7H22CD%U$>s)OhF>g<sCGYIpJ|
ztL^fYc^3M3O3LM_q@X|R?{rD8F51Nuur;e`alY)5!?v0p$)Jev`OHUUf*I7RW8Kgi
zn9oKkg!C2-m%hd^Rrbv)?DHzZizC2<@=i@c_y4s+jbaT;%3Q%`skt}2u0JC8r6gA@
zapvHCm7Hzwq)kmNzN*~c0g6)X2V_G(^i|GVVTGkx`vi=byL6ub0P_a;_EvM@_SI_1
zO8dB@03=h-=YL7}wXcrEc=ig~#e}e%xXlPE#%-I@zMr%)9B<&0k`$Jwr2l6Ae-&^J
zDpEujF{$=S^(*mwgxglf7oh&}pMk8}&+lW#%b&62o7gC_Pu@U&(&5^aNXPmKLzeI>
zc0-EPM$q9M<v(ub-Sf7v7hV9#5&Qg!F>KBz^G}SXIOc~qm`$g_{~|u@CpIt&my$o(
z#geF;?%LHZwODCZ%wJn|s8UpSVG{+N?$Qhcz_6G!^wlSpQ3dLLIu-LbN3HeCBi{`R
zC*M>ure`{J$MU~MaA9Y7i({Cr4rmd2R9BsIpfAcHdNrUM&6+NJ5-WqQeI}|TAxg9B
zTUe)Z_nc{Eo_BE5rEEW>81R9P<2F%iM9oSx5>lol2i$Za#wG8iusBBh2J+@+L6Ik^
zLaK#RM{M;jpVEUz(y0thM&4JKy=pTk-%>I?M6gvyzx(TfwR6{Wrk8&YXz2y70K`N0
zfSS@aUgt-#YJ6^C^>6Ww<%~7W!33@?orR6H5hKy}l`cJA_q^(I`}o(F1og)H#jmbi
z9?++H+Gh0n1z{Yb3C;BM_IGbDTV*Z}Q~lJ-|AzNVq0q*h9p}h-cxYD|X)MFV{;p?!
z+O>)YMDza)!K4RVgEjoiRtE~y!b+Hqpvx-q+S;p8qdA(qY%+MjuK%OCs|<>(>Cyuv
z5Q0naV8Jy3f?JRvg9UeY7~BaGBoGJ|bZ`k47~DO$h5$ha2Dcg9ot^jHs@?r+Yv1qh
z{yDe0ZuhCDZ_9bQ>#1`+l%gfxT*ndh2{S!2f6r4(YJJKSllQ+F&3SKF(Z5oT(mUr^
zM{S_DPkQ5?JyDB@A*$ZY*4Ef3U`W&wl%l0C;+(uIUdE^cNThf8IsFDy5BW%j*H#+)
zicM+ycN}sHf^<FE)uM=c&oznGB4x$HBk;c%nu%aA1mW(LkECe09ko-8>Ki)AmxtxR
zq9M)jzMG5KsOLsXojChTHIU@-^nG(ryLxN=JIq{(?<u+i$eAI3Kt@BOT97ufc>{-9
zo8Oz9KI=ort~Lc=hOY3>ws<1^{QR1LsI(_qL(v?D!T5vVk3%SPdVu(Fd91S8Zd5v+
zf~e>0gr&Zk^%ku73Vz9M|4nKXa>BClhQBh3j&>obNo2-4w8E6h*gUGdue%#Zo-FbW
z=m8tTIP>N&t#X(YUEwI-syb7jnxIoCG@rX{hE%iBNeehcgG70fB$P^p0jT><5<{Ae
zsFSAUvg0iL_?J$+RtZ;MJ$jP_J)W0#`S0?73U&)eE%TN~{-^f)-|C3}{mt&bxcC>f
zcdrLes^M!&Gvx=g_X@wRTAL&FKhZh~{MW~A$$H=JLiSoO_?c-D+npEr9+N|>#gg!W
zDKZY9e=3pjo~Yv&uJ0b*bEqB5gp%Z`$=8k!Nl$);mu$<D$44ima*s|VOSXx>oN$81
z<|9X{D*AUrP79F!#yPM+gMGBCgC9By4jA1?BIjY)3>RPjiI{{&n0jx%TyFL6l%t(3
zWSe)~>4@oXg#w|K*uDbGF}@p{^Cazm$XSt>&wsr4Gvw1aMsXWzOQF!^IXvWz87zP$
zp2uRJGd#;id1>iJAvM3E`U;5IHHZSht?~kxG6V~zr~fTICVNdNnN%0xip5k2l3JoN
zjR24+k<i9~iYUup0LWzNBV^in%{Z~io_2-Qqi_YIyh3}jD?EiWgW_U<E%kcxclgcC
z#hT_~S}tZj1+}p(PoTWi>0DJXS~->}3JTf$cXbWBtT~Mz8)si<4@%GKd&LC$Sk}UH
z0p4}6pCNDM%DjiS@J-CDPmH%(x{N=l_EHSW3K$sI(e2rnw-;8OiXd5Vj;L~^p@rE$
zN^8%&8k;BnOoHmVcf)DXo~oDdzj&spb?oQn_O!sBat+K?oTsvE&)4^7Y*+L{vGbvT
zNS7boNJxXAPWe*LP>$u+!+p``8kJCtu7k@pVTR!>g=u<1>pxUtmLi7p^J12s?~+g;
zQI#cgIG^aXY-&jH(&IcRIAC<70QoRA_Un^x&m;e^^81Cr*T|?jVQbfP3S$-w+_ex$
zo`Hm=XUMq}eVG1FounkG@+@;iFZS5?GbLIfa7T*exbmAQCfiaG+X)(sT&Qjd8w9L&
zpI=(hMgh3eyM>7h$86y@qA!dnp|D=!;{<bKWq++Vouqkq^Oxqee}SUs_2Nsf2<VKS
z&W!B|J*f+dbbxjp2w@M)c@^()f8F|jNJWKWUknj{t%U5$^fa_HsVXh$O7}DvElDHu
zH3fIj`TMU+wnNmL>wRm$<*P31Tw=k7U6iwQ3EoU4Pe0YT_+nA8A<ms>NvnDg69_TN
z@?<DpJqEMaW03zP%^%CaZIrv1_z2T{!av_yFcxB<-5~Y@;ucONXX#2=XXRFTk?Cf=
z%N@8<f<vFkan#&Pi$j^lDvjSlW`}=j;YNA0FT9_(uAM8kQETFPu_-NCLNvqe6WN~d
z5%{2PJPhJV$#*A`-SyqR1-}vX%|5(5y${S`&iR<Lt&lXyj0TEm+@<6M(4z4L7fdZo
z`TWYB*RQ@zqb+g&j(78QI^6cE?jBSW7*FDx`_ZnPiw)%U0vjjT$w9UDXU7kSbx@X+
z{8&Kl1g79XD)IIxBT#7OJ9YEwo@~b--xhS~SAdD%DYaH^zH&AhWnEfAEj#=X)Hd$x
z{$TTgjh>m$uvf~rUI2jQ0%swfTY6*uHRrMfTASYd%gqRXo?+Ew0qO;pGvaUc0FJH%
zqT(fXL(tNe-*~cJomTNMCEn&s(WiRpXe^*T@*Vr<`ZaYp(sBmI4oY~`8O;Sl_awP`
zjprNH5au{KS)?M}B5vOv`p0^~A%kQ7Me$iogdzo8$}93Qop)x<pQ|!o`L}i^o3m(=
z&bh`QA0YkK)Ugz=O!Z=#zZo{iGZKfy!Uie<{$j`Yz1x*ATri0tR$iS^9sT{x>q!Ed
z?GLfN;Z!z|ot?CiopcskC9z~9nw-6g_{z=`21XTD#t6^yaHat6lY%kDaE_<JLu>dL
zUtyd3pS@;@vQ%!5GNhHjwYCE-Zinlwi1SJ(r;>dy$>bEh2kkFTR!xOgm>StO;cZbH
z0KQ7lQcgxvS#OGF(%#~RzLQH<;Zr!JN~`$j_6uiNR^F(VxlKz|Men^`!-EH~>KmgI
znXvv?zgl%xxp(JosuL%RT7hKDHwdL+jJ>_^_U!1{EdSw{`W8zbFg;KDZYIeXE4Xb9
z(psC;thhIdKl8%bOQ4~Yw_JR;p=tZ4|5U46@>)8BrsJ5bezTH+)#xOU=B%pUsh{iH
zBp!hbZf*xN+H=l$z3R8#%7ilvdFHjZdppes9W1fGHqKO}GSwAv5xR+7XT}?Hn3nLx
zMiCD(eX*Qw3}L_WiYZN@UAP>S$}erJ_shIfr-=0`z%LO}lsN^BufrvW+SFet`zGpK
z)lO+R003U&LqO?>TjJxJQIA9W7Hs8OM51GAsi1r{fisI(18%|XJs*1^Uj9?bhW8$j
zsTt5&tGAW3*XLf`V*}nc{klXboM*}?=IzB<_$>1eK3!$NMVoQ`n_}&P>F@S#lz0%r
zc#4?}-6m=LmS~1^X_*8Bo|7wp-_^9xG>k=xSVzjE-7*foqx22mCX7)|dZ*pC1vRUo
zwi-P+uU@P;m#k~L0(bVqx2$3!YESn_R^H*egS7fDugO4J$;oevE{F=pFwR4Si+wKa
zO~8EDPAPo*F=J~AYNha@4A!=B&Wqf>_icG+bLH8K%{HONM;{kmb`htYk0SzKf8Whu
zSCSOIZl`j_B)qi@7&>?#z-qedkvnA?k!KL<1bTkLZ^g8EkiDByHW)$cL8`DDF-UL1
z8rcv#+(7g>K#a^qiG=ce;`ke(jU}U;>`psNm(XX;LJr2MiP?GU8c9BBHA-ys<=UFK
z2BF?0aw`p$;Aem;Cb{_}P4!yH(sRuj{`R*StQzz`&tHTOZP#|>c@)_-vdy7|(TS}L
zI)G=6<Zr$U%Ec^LC^NTG8KKX$0)TkGry_`6WMS;TW%q2gL1u2iIM^SgKLnM|Yg-)=
ze?w&f(9J3Hejv}PTEq5Uv{`M+&@+Db&Rw|}?X_23@iwuCmj`Nmp`~>p8;y$qQ_(21
zv~kO%=R&XllGQic&=qk)$E~tjiqA?3YgLyhRbc;QcyhL)|5D`-_52PqGGewl2;eNn
z|LHp+10#GD&U}cDTG7p0lIL1!0rVu5RC6^3J3oK%^9skHiQyDa%&q{~V##6^RKOpo
zQ5Ej-6*iLP42%vJSSfKyb|$qHpH(GSnn+~a28RjSSR8)y+V~8MMrHeL{dRT`Actty
zj$vBze95a?>_3NrC1&q_8N^dfE+)V|_^sW)9YIq&v0?-nap5_8a}#W4TT^4C`ZX&C
z7T)i5d3sjfR^mivT$k?Q{UW`Ce|G7)UPxMaEC*R_7|a$&Mz@{}2Pbh{3}@E1rW>AE
z5g=P^vaAU<`B6>Y_&wiAdGcpyW%GERLOMYto}d@OrL<*2hA1-*UPsYHX+nWaO|_l&
zB?_zSXA`%`c7e860%yj=YCi~B!M=b65v7+|2b8TI3z--@EUNBp0;fb8TkGA2KqfTK
zhFGz;{)UN4<-_jFJgGH`2tT))8uWHKQ-_zfOCJoDN%KwJ4RFx)sTt}*a43y1?k0M+
zdn**@^g%Cg?H!DE4L?-n(MC~zrUV&(x~&Mm8D=}1>6uyZ_Zz72+)Q3x^zs`YDp9`d
zDJ{G>5;B+-M>aG{mcwh6IJ5Oc^uQA--n2I0p=0PfT$<)SZP3<&QjZT5kCLNZcv<vX
zkh)69kTq{h=RrL296{zfR{I?V!Tx!Ize&ymBo#APQ>e@jaV`gO+DV@lOuYb93A)_K
z^8&Qey{yzXUT%V7FRcTu3z)kzug+;Y9k9G|XYa*8U`H+2rNAr%e+N?m#M*$s6eS+J
zB$%4TO%bnQ+R<Hb@8~)!*O^31-~Shi8j6CXQEtxBvkR#7RO+E%Kz(ZiRTWz>aqf7)
zv2?PYdc6rLJave{Nl;AxOZAs7L^3GF-Or~Y7`(_{1QKiNq&4~yFHy}<E#3V?Hra@+
zLFbx}q^536Lagosxk^qQSoR*#y0U|wi()Am=N}|LulAvyk)74F4h6$V(euL|h&2IY
zP8GM&Qvkktt@lY>QVE)woUjN}L!mYJ)Nb>Dc=z5$nAKI0LvOg6>3A@?gY>C5_tWyA
zYc0V=3C!xeI{T6IuP!2rH$UZTV>%yrvqW@MTF2i7vyrosgP-a#3Mn2|zK2gH>y*LM
z9meyDdr)=NYia}>ytf!U-)`vMjsj#p5I;fb+B*5h7V!K=xSXd@D~q7zf;{z*TUW0@
z$n!uxqrG@(gDjXHGkwp~z%6RZrpZKR?enMnWa10})grjoSxeeGG;e$nCE}TE6bE~w
zkNam8F$>;8ugE(6#UEaktP=Te$kR>tL!}^-aJH!8HV|+(k*Z$JZx6CiV02M2LtTad
zJ`B~IWriq|8)!fOnU5p5Gx?d;zMYfPEl4EVT`^oAsFBzMvr#Y6(l^p_6_%;<{<4E`
zQk|4>@aTq{efgWX&@>ZX<_9N9S{uK!afcu{LbwE8g~UGJHf8w5LsNnK<_|1~{z(Vp
zGWOXQKs<d@P-rvI!^G>T{j`C!DiS}~lI{o(?C)@S+wE4hi6)t|bMtdAxB4lAm2{_V
zPs|v$uBeu67^{F5I#k9lLcX-`GO_8|SyUCeK4-c3amxD5U}biTewS@1j^7SEe-5fn
zFBji`5m}|o=?<uhR105Z{4N(Rzn)pWK_2(^i=0!F|AYqwQq0a~k78RhJG;;Mo-h5?
z{j>Z5vy^MiN7AXYx|JbzKkN(oYQKT9u_bLlp%#t<&$qck_t#ea)$5UwQq}b+=7-Hw
z6(3orHa2-oerYLzWn}X9SbtDe&51RheosnDJ)&aMV47I}+9?0~6*T(muxME!1`kT9
z5T)YD%y%A(Uq)>y3aS7Y{ku39?iP6S7ll{B%$7M6ZTAt8k+vinTcTc61Oy4hs@L^O
zhg8BfLwsU-=H}*i+4ux+tQ6PCGD@zKuSs>vAH72#?|&H{H*ZF92dQhF$kubj+Nedc
zEaZ&j%s7C1)~-%HjY3@&drvA>gsevs1f4n!lM-lqYj`7BXpKiQH#~$pFGn&$-?)uN
zhZ21pg~*jVzJCAEZUWnw_o0ufDE30130&tg-?j*m7G>@mhB_}=3E&fG6ftx*!UjUF
zsaAv#mov9}Pw35uGr?24y-x)DGN+hUJcNA_9DhMo$N*GYj#*I!AS)z^53O*x$By%S
ziA>`G^L$}VL_P~5nXR`4W5tn`KOe^m5d=E-jt$HOm~vdPVZHGZ__{ekQyrl-kx0$2
z!9*Ynow_YBUk!TtP{`qlz{~b$1->-TnxPRTojG9%5Rh1<)8cc8n=yj#g23k(1b^Wq
zGLvZNOiP-vfIY0O;UjDbU?(M_7o_61E^O)T1D}Fgc-lE@A87x=AERg8Mo$-{=eXLr
zJZi$vZM-T#M2O$|TTCn@X>)2;@0m^8c)4qyf5+z1#}k4GT}Ja{7r#I_x3*rB(t*i`
z6_AA(wEyN$VHi=QRug*`k8jq4dKV$dO*zvjKE$6W+{B0TS2)T7VR_h47s*phk<YbC
z^nO=91Le?#uZ2t+K_f<KO7{-DDIK?E#+O)FB!R6*MAtNw&Ele}kFWsmA-a@X-K2EG
ztMiR|g#rNf<%Z|sB00PnGxs=VJ4$7V%U`zI?`PN$-E1eXZSzMoz($mg@iZ|PO)}bm
zbDzK+^ze=O?a(rp7IW@7&iOo0+PQ-l+jPRc^kxVINf~Je(5m`a6%@Vpq)ID6B-dx&
zyzGCE!q;(JntubuF#b?3pEej^F+45vm>QCF^Z?tAqBz(w$*xpM6Fg<Uh7MG&!j?=Y
zP<69QS^b6Rl((ArIA%MiB+e#i0Cn1;sRlQnf($~ER&X4xy2EgegX#~x$;iDhIOCk}
zB5bhOTO#@y_5d<6N?@~59!B<I&FQRGRAzW!K<myXGVg}OLDF@5NK#DazR+(o;1l>P
zCrV0F6i&n9EVyz+F3?Wci4etcTz!MIC}8zg0A+)j_RZ-7IB54RcEL{gRV}5&efOm^
zfaTiHepS-Mv)%Iv%k5<T3rcmEs8hL!4`@9@0pm<()TMFf>tjPZpyOWAKCiIxz{VSe
z>S|5ud^Y9rDvQ0MWh18}Xv^ggZ1#wI?9Zx;>0l-J(ANI267vqD!G>MOQMUtO!i^D4
z(iI-_<@~MDbPxr*649@~{dJQoI)E(-GLv13DdQEocFJQlPV)!_4B^^$r&y$a4>gd+
zwG#pSHDCWEvHE5cbV^oVfSbD6QMZQRmA#rl>|DlqWbHN>Y8T|!@W-lUGL&H8;ibu-
z{s9~RoSVrFoN{|$4ZrxwR#toD&%2@cVTxOB7#ctty0ap%I5HwG7PK#c>$QXinBqRj
z4zSqFAQI$8m5dhDbL;}0mnAR!n2X!PLLpl)|8-z^wEpN(8MG3BxTby7$v6bkDgJ(3
z^b33j;4-Q+(PdtKA*v66w@ROvO>t#+-aB2cL@x<2wOZ*Lge0#}&JEr+mU)X$x$xs!
zSV%g~rxK3*@MnzSK(1ZnX7J+Im-)Nt=uZhZ0^h{2-k<Q23fwiml%#iA@3>vMH190l
zSQ!a0(oMe;Sk|mmCL~&C+DNPU)kk;PAT2&J&Ew&l;*BFT&2zOyS!oKT=Dwec?7@`8
z{m!^}>g1LeB&ypJVDkJ!x9_+;4UQ0zO;p2<oX&WKPI@D^81fi)G!<xg9~wl&#N>cI
zW9)3od9QMP4&}BkGIZ>`C><{$s$3RYK1^ys`+JMcvQo^pA>Lx3_CeIF7Ttnw_IRtq
zE5(<Oux6X*t9_bZ3v;0ACVf8wcRVo=-`(?mP<l9BrWS}zkN6b!1oAM>JnM>{PAEim
zJRCOR-vd}9W$0Rc))u$|k}JD3qHJSF4dy_1bvv{#_<3tK4Eza<)M?pXJjPmME_hD3
z50#Eum)pyUt4)RwV$0_Enhnt0^<0Q!!i<-@&JMu{Z_DrG7>Eabh=hj%yvi*_L1v<#
z8%!(yp?bm9dA9zTgrH&|W43?l0I!dk?KR3&gtxYhL$2DpYRh$<R9_%&!^dF()h&^e
zu_0$DX?xj6rep3@)B<_Kwe0(=08(?*w61VGCp(GM5T6&s(WjklYf_h-<IiKS3Wp+f
z!WS>%wn)V%2s@h?1FMBZlnt6jox{79e;!@)%3y|@1fWMTM(Ws^=)3Mp19xm49>ulV
zZ{|;{qxoSUD*GdYjKo2hFc|BnX%k9~42-y-%lYXP5uAYayKk5Tt|`}p*5K>1jp?z*
zJM9V)n_nh{j<)rwSxvqdA_Ya294UCwMc$PbT0b1dOh*E;gv?rwAaNP%--s~K%TyPI
zMcR%8tbitSz8Fmco>rGR&>*kkz{H-r<U%s{iY70I{UN%`dvRu^R7G*|$ZL~1E1U+<
zgzC+>qg$Fcr>x;9{L@1XQKMMd5*7?k!}z%|s`%sTdAIso!Z1GIV}IjeSS-m{XX{yv
zRZ+|kd^KU6S>gn%r;+m=FpXl4MeRPjaPPc#U*g(=%w6sm&li>j^UPoJF#U3EgoRj7
zW}5Daca|DQLd{9>no9t7fd*+m8vEMO1Q~z>V{+~FGefGLbiq2G4j8^;b0z6|{Ij%v
z7c_Zv?SVY2h2f4MCNw)&fQ#Lzd+DSGE~?hX?KZusC)Gwayr^=;<_3rYbeRd{w?<%)
zyQ--gQPb<s4qN9sa7Y@#8lJG5`I&MDxHg-`C_UVl6-;`g-e!qN3}*^BQ{%bOr>hjI
zzp=XcKDw{2!8G>TpzPLBX#yjz{3c8`TAdJQSy|YB<D`P?%~za#?*mO<E5Z+a8cdy*
zQoJpf&-_njZ&NC|uFj`u;6blGw<Fh%?2AgPN$eS?_LFD+>YeLwS{J(ouzQgbGQfVN
zhVha!a;_!niOA(3L%+}nk{^DFWKFD9ih|=x%Je1;B`F}O6!PS(CHhwGuV9eZ*W2ro
zf=r#Kq=eo23E9Rbr6e9F*8Sslg=)!mEm347s|KOb%$mldNQkd1)w+;SAJvG0!Jrdu
z{*Iq;&}+P|qn)c$C>M52FTMDLkm`#3c=Ag>sb2X<`gd)2<3S1dG$Xil`N3C|wGT1_
zKAZmi+69{e?b-)4?!8#0KNin6vbc+}c(#B@_}CGRo(XRgv#VH(wgYKkSJE=I2|PI`
zz<`f<jP&`ot3fd`GDz$S|6q_kLe}|b^Uogse*14c{O$k$mz%R-R$hMolmO(Qs^&*(
z=!UWK($Rg&Qu(i<22<kDrrU)G0fCs_hFh}|Q?w(LtaystwGTJK!pFzw<Ht-3Ng0{A
z=DE4Ku&}Vm)6G!ioTATf4)q=-BtQn2e=-CQG-{j@*N35twaC8$02E|ZWGbXgL;eE_
C`?4ee

literal 0
HcmV?d00001

diff --git a/doc/assistant/share_with_a_friend_walkthrough.mdwn b/doc/assistant/share_with_a_friend_walkthrough.mdwn
new file mode 100644
index 0000000000..a5a6d68170
--- /dev/null
+++ b/doc/assistant/share_with_a_friend_walkthrough.mdwn
@@ -0,0 +1,40 @@
+Want to share all the files in your repository securely with a friend?
+
+This connects to your friend's repository using
+[Tor](https://torproject.org/). Both you and your friend will need to
+install [Tor](https://torproject.org/) and
+[Magic Wormhole](https://github.com/warner/magic-wormhole), and then both
+follow these steps to connect your repositories.
+
+Important: You and your friend need git-annex version 6.20180705. Older
+versions of git-annex unfortunately had a bug that prevents this process
+from working correctly.
+
+Start by opening up your git annex webapp.
+
+[[!img local_pairing_walkthrough/addrepository.png alt="Add another repository button"]]
+
+`*click*`
+
+[[!img pairing.png alt="Share with a friend"]]
+
+`*click*`
+
+[[!img enabletor.png alt="Enabling tor hidden service"]]
+
+You will probably be prompted to enter a password, to configure Tor.
+(Depending on how your system is configured, this may be the root password,
+or your user account's password.)
+
+[[!img wormholepairing.png alt="Pairing with a friend form"]]
+
+A pairing code will be generated. Tell it to your friend. Ask them
+for their pairing code, and enter it in the form.
+
+Once you've exchanged pairing codes, your repositories will be connected
+over Tor. They will begin to sync files back and forth, which can take a
+while since Tor is not super-fast.
+
+---
+
+See [[tips/peer_to_peer_network_with_tor]] for more details.
diff --git a/doc/assistant/share_with_a_friend_walkthrough/enabletor.png b/doc/assistant/share_with_a_friend_walkthrough/enabletor.png
new file mode 100644
index 0000000000000000000000000000000000000000..6dd2856831e3d3ccbff700de1bdee246af474e55
GIT binary patch
literal 39694
zcmagE1yGzp(?7UCa19CWPVnFk!Cito!QI`R;O-vW-QC?;T!XvoBDZ<p|M%5Z-Cf;Q
z?X$D<^ho#g^mPBG!xZGikr8ka00028q=d*%003$PT)u*X1V5FoSK+`v@OBa!jsO74
zz`rj<5-kcIxDwV$QdSgp8wn2s0U2i8{WG|Vz+73~N!Zrf+StYk{1*Tab};_sWNbw2
zYVKr4EG{XlV8mby3jh!UBt?EGyRDvWxTb2WxeHufwz_((Wp#C$M>Lc*QD`I^kFqmk
zHd)EAkYhuVz>|~1K*EQ-5)1w&L4!jRf~P<M!cRiDjwe^zlrLMfuWpXttz_{#UUGE{
zn7FcOHPX;ZKY-ltj?!8k57r$w9S^5?Ol^NrP*4y@kSkY7;bQ`j;5Ae+fJ3RV`{V!;
zBbD!?4&jmrYWIUKriO+qX-#=%<S2f%nRLa6rK)x+7&D02fFTjF_;{H`0Nn@oA#N3}
zF&BwQG9qHGF)6*|H%d!P4dQOhUW_T(fMbZM*jQr}%0oS6WxODo@$W+gVSlwt%A!WK
zlhLJd7fwzrG8Bo<EKU8y`sq{yH<h?jS)W(sBxN9oIS;jI^*{BXr5HPxtpt>3o<c|Z
z=}Sn}jbU4wnMqKhL%l)avjfl#;zRZWxvuAW(6Chfr0FO}=ZrF;)i|**nUIBl#@ETD
zYmRpyD`1crBE;_Z^^uSKgcP!4XsLk|GN^4c9uGqE_Vzx+NO1BnQ2G^#!H{!(ceb2P
z)7-s#F|>Z|Zzvv+7b(_1HWofn&cS=PH4R4sAW<IDfKSa1V=^>U%AXL0kNxEpS<eiJ
z$2O@$U}ESvt<subS9rM%ecYFp5@N!Hh>(NPB~$;_L-C!I9IJ-{6EZiPIV5$!AmRQ{
z4*_bs57DT{Fd#_~Dh(B$;S*f|7ob-}(BK=>w~wkU9@{XnFP@K$kg?0eBHweFF|(Hw
zRff`B>v(pdH?ARZhK9Llp^3xdyj%~Sm&3SnaFIf8w^-oRL_39XIk@<S<?j*p&%}$m
zy7<#1kWf$@e?hbi{H<r_y4|Bp$ynX{3Z(un8t?EWBdrXUcpOKCjg?ioc)s=h9RSdX
zW}!42mVqNtLqQJKpWVvR267UNTZCIN8yfI31n|89Cv|%V?X+kC`IFkKGn}g{akxZ|
zs>_|mgn<1h-Iy!D@8CZFF8@~A#iJ+;SyA>%Mbsg6?g)M2Gy>}sayGr5lLilq6y(N7
z=JMh5csAUEdhQPeWn@?8F!~|@v2q?qA{&nmWuRP1z@PyyD-*e~*sY}GIRYL_(p}bx
zA3Ag@n)YP{eYNwj_$m~cG~p`Ju!IFE_U}TeKUqLp)#6U$@4f<n%KSdXzw9{7eyoH`
zupXYq6i7^PBr6uu<(XnS;fTo-M}ZsGq#2OJsZ-kZtLL9`kv}Ev2_hy?-k|p0HLa@1
zwbSI@J_8r@%gG%9nU+y1vV<vg(ybz^+n0|K1A_dVx9k9FE!{Xd_^R1eYaEI!f(wZf
zA=7e=3kSj9nF7=h8pO>D83!TOTDXHfm%jD3)GRCGaS}SG^Jst`4aHGeS2i{?<Teqe
z6VBETCmS<ce(^20$09S%lsRm?@}bnGmO@#9x({ERx}~mKE78t18k~z){dtionj~ie
z{!QmQH~<4znN4eZUNj<weVgn<>Q5obhO-sq?V)B{oC~v40ejw$DmL4ekV6N0&m7nq
zpTm2@&uqmUz+_RS*(d23WQ|jf#Y#&Tj6uMpU60E_aOdwVh~;!^iVG<v`{2d8j?X<^
zdZ3f)ZiX*0%>>J^ek>V}Lp*q=jW9aQoF)R!xuQ6mIhRu}SxYg&j^Cnc^Bf}0Bed3>
z^I?4_r&!)u&@V(gq3hPn32ZK%SynC{f<oF6>fL+q7Sl~kYr(RGURapHksPyiz%?|^
zALeQuMgCO8-a3W>ytXsr-JV|BE~UlD41EE0G^#qrO(~F{ZrA{zDoeE~#X%-Qa2g1=
zvL;z%wOxL;aZBd9^f;$#42~mV4c!6>Q_88bQwO+w4ZJD1=#YNVz28VCV!sB2im4PR
z>Q<vXP><RJc&QE$8zmXp*2q?BCAedM3EIb1R+N>E&tRWhj$+L~$ie?<n!`Pfeu(@A
zNmxCvrRP}&tQ>%f_(mLbX054cJ-#1sUMez2JWANyY^0)cdYmZ{3Nhdjn#`spBCK<H
z`~`jd$EjI~vn4uNAemu`DbzQlDKjDGNKrnNwHA56Rb8x$5qXlTG5kISik6bjbSZUD
zT7|969kno3ejKaegh~9a5P2{_-*L_Qy{WdTV3xYNM8}<bM^4=9c`Sm@CF4@2fX$p$
zg7!3hsssqH$Km(4%=msvyQG*cYsaQ}u(P9dUs=Xz2-6GzzzZC<l)TGEc{B|k2tu1W
zX>0qdoLf$t@x_^9a6*>|6*l=!X^8c}@<h8BrGqz3<xq*wiGqrd-KzCG>OQQ=ln613
zR+d&;t>ZcS!`n?g%n7O_w$@7}>|;gG<xHA8qM*6sT&Me{62XNK&-=mHHOM@L&FTFm
z%!__$>vr*Kz?QYv;1th>;W5YO_1G<7tD{J$s@<{SR>sG$GEoHmkFSHEG<jSCWz(yJ
zB%STUC*7y5DL#9Z5H$7PReJI0;6GeZ$vW*#U9VGG+0VvU!c*OkM(aP*@FQFZc>%=b
ze-gtuznBIA2I?l8ZS<1Ow%$aji&!hD%~#zYZGG4(L_BWF&8!|ixqR3jz8BO>w1Ki+
zUl*I1m+x;3(2q)sv6$4042m-eA}AeyQty>oqackUohVz2R*{x>^Epud6S4*FT2fh1
zH>{w&u}&5l)&)<(m|e>FUkfWU>$K&)aPmDnmzZDv+h{*X(7n4VhT^4*$@+x>$`Gr*
zUxY@CM`SQ_EaoHc4Y;JGvbZB%oRG!pA!7q~omcn`MGXzA;PcJIh`)sce5E3zZi6kS
z3V)i)p^~=%J^^Hj74!xz_!_H`aDwC0X-p)awLJ5=AOQYGc1e{L3%l6AVKJ3@PQH~h
z#6uAj!~9u!H8FsHV5?$PRY`hm4uue5Uf){U)mh|KT|v9JEVC|QyK*yqw0i(Ptzrt&
zr8RmsJQoM%kssEfsY0xzY@f1A35zMQV{n+YD)!CBsz?@-7u7T%$l#;rN{Yy#QgHVC
zluGcPP%*-dl(D%kJu2M^qUm8S!^Wv(sI<QRF5wWhbaKkY!dV0fhcu+Bkxv*i&%x9r
z2t`@sFr2@UR{`jOCYNm-=AQF5;T(bp0+E$RpkGs<q*RVr#WH=3oKA7E)zWc!ZQUX~
znug%)^nL0I?_w**i#b1@!WwyS<(p6YDkz_tavw!k?QniNKrN0F3U!n@f?8{0Aw8qP
zUVTOAezGJkt_-jS!CaJI$NUbXtGW7Efw#0NIZS(K0ptRDcA{&>q5|A|olLXUE<r5E
zqQ$hBxYzdNE!ew9KTTEpSP$rFrR8})d_!Rz0GcS#9px3az_Ay#hx@$<V^DkcxfDV!
z$At8Y7%nY-ZxzMXecSqlgqeb$_-?6GHq$Ep@pX^#_`Y(3wUI*t9zi8tDc7!P>>f?b
z;MN*DD_AZlgX#2&&1*YE_*%rR@^D5iBXB`n=kf3)dn(e6SR*yxYIW(F`-=+x1}21+
zBHV$7!pDKn2b~8~*rGd+B;!Pi>AR%mW!gv3k^1TQ{rc+d>xlI$Xhb|2>L8)ob)yaQ
zXd@cK@5cz1dbxsO<5dL?8^6YtcS-T{exKaozN97E0`)nqYabSq80It7+$Rkh>Uq+=
zfnA*#BXa|pIomMR<z;;)a+2|V#Mrq@V=G^okF^=*l)B3%1a!GDW%v4gG?2ebLZZpa
zu<8ItE6V1xkd;}JRR;&8^VC;$zDeRnsg}=w|77@OR`t`L+J;G^Yx-rsj_ZXLJtB`z
z-Ep*N`HtlM-xPCLygGdMtvXLsb<z6(qcoQ(wTN@o`pBl8*V@?;KquKOg4%KIC}h83
zTIoYnp-TB6=hjfBt(bk>%7{p@Ew3IiJQ8Raag*8lJoC11HKcFUyqagJV%aHc31@cH
zT(D$Y)I^7l_3@CpyP#y*z^KE!AeSe9mbv&bX_T3z&5#{$3TM-6GO`vC|6AqCFJPk!
zyy&-|es)afPOUJ*uS)mR%X_%vX$5g?xLKH_*wR=w4yp-*0xJbL0&*rI@h&4lXg6i1
z%Z@%gN(P<kCY=nJQCL2C#+-GBj(+)m6&Aco@)X(eBKUyA_@RxXYs|DL?S5s!kyyZy
zQR&tB@p=QR+D;#Ftte(qx|9ANb77TV5M+TN#zs*U2b=&Dr+a8M%p{eyNc*jAeR94n
z4L#}ZPKV0bGNbtCTsDU4MRD#x@7YX9lAyP?sAn7d+(MS4#-K6l5N`QdHx(V%jDdu_
zS83>9p~^MKw6PFzm+7R~0GzTAdq8+9LW=@1UM|DBA8(_6MruiDef_;1e1bSMUEJOi
zCpZWx5%hh$Bl!XtFWxZEgQA=&kw)w!Sm9dJ!!CdJ`F=n<0auAOI*Q;dWJDEF8h~XI
zWJN=^muU(Nh>L6Baj{~)KeyOgOOb#lQJ)0y6W7<5e=*RcNwf9C1jh)PM}DJ?j@F;2
z<tl}~sq<h3=p0=*T%R#uxiuN791q0M!gLl8B}NI!?prDm%K}T`D1%~y%6@6X#rbl#
z8cTWPeU*96nXH7yGI;NXM-zf;Rh~L+IpLbO<R0><H7Y5KEee$`i8b*BPCmV7XjTC&
zRVzv}JserlaF3%PY7!Uds+&rCr=E`7RCj~~Et&G0(rS-YCIzBgry!XZtVok^IF+7$
znvmY}tX(zq=AT3|FQm?vm*vZ}d9f@8ls}XG`h>-lv=T8H*NZ|Dq*`5jx;(n$Ml%f2
z+aUUktPTg^-=F{*?llPap<Z0jR{qP1N)b>$4|YOlw9d58jnPBVxa$)R<HP?16cg8R
zC$M1Q08-K7H!Y?I#iwWeG)mRkvjRp&JuDfp0IAzE=@k}q9R)dcBFUj1(HxbnRrkuF
ziFny#ajn175>I7C@)f=`#SaZUK`>FaRJByFUwG~Z_~ugOE9OzsU#u#>Vq*s}X=-O*
zZ4Vd=CORQ$BKAPQFqm6kSlQ`6Py?9K?)E8P50doBdm+r|_VrE4Mpc3x*`L2i{>?o6
za<`|RcxZs>s>AGp9SL96=s~mVujE)|aH1ofqK-(?N-${H&v#rKW)5QAE-R&XX#3Ok
z?q#j1^jQs*Mot{GXr@;GB_neir*bxX9BH3}tFo0k<LYo}Dk)N*n?%_Uo`JkmLpDm@
zXSo#(O&hv@p;kT!O^9K3Vbh&RjXsE)PMBpeB59o5nG!LmXCaZWL9<g%r7q%imdqi|
z>Tu<@Byp4su8ddIg4d^v>W>U%i|Wc*M?;i6m2zjLZRU4&vgvK5t;tLrT-@@;*4k9x
zng#>WmJa^!UNC14UXF;8)hA;;sWWC#qD^f-JHHZP--`l%YhzlV4+2k);8<V6SJ8im
zJ)1<0_Jx-z#leBCdA=l2OPxALb?P@St$N=X<)A_r^A75mn36^??aApjq=w4C8`M5q
zqp5>toTOHVO}pap$phoM-^%G&87U#YlbY&d6GDlGl4L2cXTFvq=V`0^ab&6)W5elE
zOP6~+2Oc_a_N!W=UiZ-5nY_oY2ET*HRtUYV8>{)xq5Q(~^fH3dV%My6!W>6_{&vuB
z<KXJ^88(jfC#SiQFW2FX_Y69`oLuerxF=VOwkq<^adMdSwl|oiI{slsDUMUmD+6k>
zgGo+;O09}~-Uu+atFp8z6jTEPa`XhZr#h2m=GuD>4pme+Oo$|ZHNMYzn4O2vx5vX!
z@E=%fs+vf5T?w6LmXCDrXNKJjW;U7Ca7Wg8P%>pRq&}wze=e?PX67Ej#)4!QmeZR{
zMG`a0?^Uvhf$_M>(57Qj{;9Z<Hvd~@^~`0}skLh}jI934?yvfMse6iCqkEfXjp_cd
z(XewXA$E6VS=`KVQtr2D7O*lT(*Sje`xz!G!RKMcwb_iKCauO8@cR9=aI>P2E&W-E
zvg!aJI0s*~H!Qs4pk@?p`=hg<AozPZ(~tw&_QV-AZM$Ds12lq&Fj=-#Mr#8J|MHYN
z3KH735Uh0^-4FndVf{WzE|A-)$kU0pd5(2PLDAc*LYZ7FnY-CULUZzFl?_vHr0kC@
zXg6?nQIMS;Ah^@F1YA@<j!I5ET0nYqc94b^#`McBPR4q!r!Wy^KXK$@n>l%;0x(6g
z7$KadP{w%aW5>WSN5P0{?9L$O!K}W7QWj~p!wMnuI?4vJP-#RS$5!*9$(15<=s&ap
z?(U$|%j$<3qa$f1zWb6|>8sxeAlwf=C3LSk?=}{z>FOmgVT_g;z-3<e<k9*n4^_RL
z^8lAUZ7pTYHlodjN5$n`gDKZ0LesE$@Mu2+Vq{(DNfQGQMaqN&<TD{&Ub_|vGQM1{
zE2jKp{W<L4`wrwy8MXDHlDqF19kT5%rb$w)fGURUWccp>1gj=iL<1YEDl&d6Z{6u4
z>Z_E`g{P*OGu~F^pUSCQSiFDNMDKOD;SxLwB04`DD^Z|Y?KmvF;Gn*4wkeghI3G0J
zpr3Ad6s>ct5-RyoHNfE0W&puZoEaWfkZ7KBDq&R7HBi)y%Um0TwrkjHRVk;EjCCBe
z-CLCx7e+Sr64KXbVPf3KN0o+@W|zx@FDZ-9w)ZH0a^K<Ot|+(vk}B|-?bi*K(7<JN
zDZ1>qY-X+hgF1Wu+*BIajM$s>EkBzqE48xSy77MP9jq~{F;EfKrn$hCEmXpZ04{7x
zSmsHa0F#q30ivR!va+)0=jXF#U;TdcFIH&nN}GFx8fKQ$u`m=uIWDfN@6*wgp2B_G
zQP5r-q0n{2fvjsSXm97iMuN2C#J|74udFmRsI4~*V`F2(K?>O&j$thF%g$?^Mbt93
zRTd$GuX4!xp`~oZ8h-8H<U$g(snOiFnS^a4z`_aBLuWWx7V`aTa~3DPETNP%LxvT5
zglJ9&rzngz`UDaJ+FyzAdYn#}E2$ZlAn2i|mHmD6IYBdKdMD`_02w~u3``VwGVuOK
zTg>9b;436|31J$%|7Vr<`>A&C^HBLl`SnlY)7y!;kR%v`=$w?B`*E?*e>$!>FwW3r
zkl_8P#akoM#4YOVRpCXEkg)fu4HW!Ka|&^LNPY}6QKB&(O+~6KQ;Z1O%__Bh3AMLu
zY=A}=f=gprV|ewQVs-)tG=mOD=I13<4psEE@IxYAZZ-5rHtMu)F3cfZS4^?v0<!xe
zCB;Cc6PKmq-U9vK_fFFUCtd#f2_vlBS?g6l*t1aXAEV31)18pMu(9m*^jp;(g!O*;
z{`-y;u>e|gP27@i)}xp}MXZ-RS^9eKHzO0+BZwR-!qpgnX@kjsM)->W)9z80td;`g
z66gNH`l1GnaW$DBLen#&%{Zx!P3?xe^ZRQuT`D$^Ys@kE<=rnPu=|bg(d)1L1vUM*
zW}ZyePhexCn;?`obG<v<eVcW8w%N(!i&5(CXxY3bd#%ZuXFM^{bAy$Lar1(FYPd7|
zP{j}6hCvk8);~G1L}Fq-!oiNk_&xpcMGTS-2{$BDP)N|AruLNvAULgW@*92+!J_87
zgq4BAMJ9C7YQ8BGlZ2ouF+~r=_m!JSK_MAhs}y2{BKT3`gz<g5ca}xz#@XqYbDaxT
zo6cH$<+<+L$;S=Q0m!TajwGl<j`wLhP!F`ag!vRuH1NV((l_81S^GLjOD?Ukd!l(L
zxOBXupBW&`Kq9Jm@H(LTj^yc&IBT_1w~y-k1ci)A5)`|X)PB)++T#y(yT9mk^VhvZ
zTM<jv0=<^p?~lPPbF*9&DztE-O2SgnbKOZtjQ5%0S5hH3l4_2}E#D7+DA)tfq*iT)
z@L5teHTBA9(mW1;eybHF`Y~a646Rcvck6(%O4hCGm2q~hE^+NaCMpVwCLJa&-M=nq
z4Gj&!dnBHG^7&jQjEy8wJx5P9OTOY(t()ZE8rYt>@EBT6<^MPu(g}*a9j`zBDFm(`
z$$Z4hA3y&rgejGe^??p1z2W{yF2J!A8VSDq0hS6H^S!7fxW6D~EATLT=w9?c4P@c+
z?$ZA`h@bR=og&#t)JoJ&ry_38znJO$YqHmkcFVz@^M*dD{>7p3oz91^BI_S@cvt$j
zTFM}WY*{do_QI0EI|RjIkT&!;y2AQ@Q%Q=6uBF^78?9%&?Og;{z@=SEyHD-28p@6U
z@4ovq`oPaK+WnhEChJ#7p{kxw+yY#DhjjNp4_jDHa_sN0jhFv*<7GCK9!twNT0{))
zf<$c)i*?@2Y%U$mVY3}oRFRqvOrslWLN%@AtGoExFYpQl{Todx{kuDoE8!vUhrpq>
z3ixx2`c+g>MWr10bN!!c@Oy7V5smCS)X`b8;%X#QNX8p;efXh3lLTdougXIFldy>|
z%bars{J$bxs}VJr(SO4Sp<DiYq6z&!D&WAp|A#^WEYE)wBS{BmS%x>wKDnn0=r<mY
zQ+NXtE#flo5Q9<Rm#0dU35s8hPl}jKFHy)O(_fp-*)s|g|1ASp?+_^=ax4B%IYPGL
z_zLyEqcZ$3s4Sxq_5Uvw_>Fnn|DlqORab)h&$w`T1OKf<lLAk_n#cfY#q{tUc0ayi
zXTO-xSO4~9ii~kmZF|DM6V*z0tM2fbD@WJDYx6z(oU?mECwsno!}YTJ<Jgm-s7J*#
zEHoSK=A|$X4SZAtZYJ<;fo7;6%pWeFr};X^^=q|XX~dMz#{O2`Qk6qswAU^7&Sv@|
z95PsKK&aiK-*IG&c|9P1FwsxL<jlS?^0sT4vNBkwV9gE(Y8<TyS#p{Bmruo`@cmb=
z8k&mHIvSjd8^<fWju#21GSyNE=~cGxee-&@><p6oLYCOC^?EXV1eV@5MvsqDw$BlN
zFq$!wTgyOh_kU{syC~ZCn+;`0WWJglhC2ga8Hj=%aMLY`HF6vL#7R;FZ8G`$EB#Of
zaUeO3823B`vn}~FsEd2^V`+&QGcHp(P!Tutcu<;P>=@f1{NRMmgSTf`f7}qe!o}up
zaOOL7hP)Nz7RT^9{O#Rv`-rOYyeOqTa>JFvbNl-9GwZm2058bOa6&;d@6#u}AsOe}
zP}Sf$NW%2lgEa5VBcZQj$Mrg?yQaOZ2!g?@@Xntm0J3DMhE>Uo*h6U!3Ou<l5b$+a
z4#>Fz(?D4msqaiWnCU<kt*XpVkHW5q#FGS=c2|Vd{eaw3KV`no$=hbI9{kfoZ6B-m
zyOVv>=(p)Z0g!+7tM$VZQMLyqMzoZ1cAV!$d*0avBNR8l%j;?{hTrQ>U0)xrEW8fA
z>+NCa<<aZ&YT2>meb4cw*V`x+Y@ec{&eWy*wCXfL4%9*FR{_V8`#gECn@+v=rGrWi
z#v%wnqW_k_Tct0L7b^vErA}e{?R)oY%=DXB{`|*ej4yY)kNM(mAJh*Kx62(OALGk+
zee%AuL4$FV!xw=M&(T(AP1dfvrR)6etxl?QL}?y@Yb=fpK6!&mm^PoA!<hFA8DjD=
zsVBb24Nl+zj`ydY&>Xh|JU#Dgvv@>v+4_emkN{_Xog=1TS>vv$-g;xXr&$mVvU<Ce
z=UPsu_|_|gA3bv<OCgUI7(PAB#>2j6krXS%J6&9{eY!I|tZfSrRM}|o)_<Jdx}Fv2
zy4Z}ta5)|JeHN^qzK)6M_>p`7hd5{2=KH*Tp+oT2k0dBd(R9&azS8+om&y*_c;I~=
ztLBd_FzHE@-Xw9DICjyux6^l4E@0MvajV7Oyh6WQtH*mig4KN$d#Yxfv4x!LP5qeH
z+3aT9)_8KBR5te5?Y2j?1sXFAA#|HJ_0dh;;=Lu>@(}BC9rV03j^z9B?S7s-^tmH=
zk22;F;A{WRg3`)w3gvcpS1fS1eH(_+c=>AN?)>bVW#xTA_Q5+rMyYo1K1{OsUWm$n
zHDaf6to4!K_G@J{x+>K7b~^)A;HvcFCC*6eJ23T3&1a$Mg~;ahu96{YAl&g5=&}v_
z@c>$1E8n`|(#Utecogv6i}+yqC;GkJ%8yIoj|R(%u7fO8<ppJar;huT7%xSP&n=cU
zEs!J8?|X)izLy2%PgAxF-R<VA*<NRHp}zNdAFq#>Tvn5|Ix^U%ptq&2*KML9?MJWr
zUqA;Ymm=S%oqonHJN|N7B;`uB$6LeUr+j%G*UL90-<jW!M9<gu9|r;+F?5sP??zDG
z_Q;6dH^(*mCv&vkn@)`+x#u=JKkPuLmpaOLV2cN~$Rp+3V1K^j)lGUQK7D_@`)Wo<
zNq+6*;(6AzX%z?1u}^f__Bey;^DvU#z4dAXs4{Nc@_ovmYzx!=_L96N@D5y7^L=CF
z@U59V(%@I=S2}LodSB72WM=_X+P-Xuz8AdZbUlMYH=nR(S~2JQpmDE`<b9gfrZ;aV
z89#s~)i4s9wbvi+MA%OcZ?aXlG5zwsH|?A2SvlTUO0H~2esooDharr7H}aRdw==#Q
z&L3(;;aT6-u4e*yc;~oWmSPUreL=89nl=DGVcXZWnDw^_<qT7|zr_NcCP5#w-9FFn
z*2d2aUaKI%4_E%W_0DBT#<!O|TO!$xH%ozb-*PonxUbzEw}wQmmlM9PplSa5jb;YQ
z$ojXZ=Zm2XcApRbsAt1$6;@=gn&S>t4l)JCv*p%DQ$3tZpIOyruI{6iVM1BN$tfP&
z98k(=|Hu8g;cmwJ0c?)%bejPTfQ!>3>HZK1BLoMbV-thsz@^dDQUBVz5&Y3X^sf8M
z-_y2xh@T6jZQN7WHkZ)p|EiRNV(Fya57KZ!mFE8?&-=b9>u=8>*K~)mXt$)*RQ;U=
zhADR?sJYV_bo_hneJo70$<80<)n|HK6gWw=dNyg=Lb<*BXoIeK3q7#oI!!dsV=3Tc
z8c3+`NBGp9g}g&kwfsN105FerTj%_$>SxxjR(Es;RBu(y)|Tut_@;F$6lxp`GL7yb
zAD%m@jdjn}%}H73eeLXdxrm2!R}oYwU)5UqJ<b({U+pn{wZjE`vhD^dIZ|_c-2F_y
zM8NM_Nv<IXujyK^x#nfVFf%KVWo@09e6l#qvYilmoY;+#<2@W5&UV|Jwd+TYdf>tX
zcZq6o#+C!xb#@7PP0okHWjkE@Cp56<B*ajhQC1MMS*DdM*l4&K%p87qqo997v&75$
zI%4Yjwxe!ZO&M1YZ)U)YNDM{`yv7@ygNyTb(v7ooAkPEyhN2=Yb|8_D@S`hMI+|+k
z_bCq^xEYC2&I5OboX0DmTXR)}l(LHN3+3QY*sp~QC1(vRv=lAqy-wIIL&(OwPIWrn
zWq)DO$i|od<KC`rn6YjZ*5%doS7RsscU^wM@vl6ShlIl#E<Sriz7K=89Uyta&7bdE
zOO=h48+E;2^ErZREl<EnxCP|<!KorVB2R<qwRaknQRdgN3pKI$M<1tRmu#4ZyWr&N
zO2>&?@0OAOF_*OCXO>=eBsZwhuXm?8PcdqdJcQbyizo_|EU`fS!|%LLY6w`t`?3<4
z{A^?p#L&Bg9K_K1afK!w79ti?EM!>8AtYNh$Fi~}dAqSiH`bjUC94hd)47Jw*4ZS`
zyOB>aViOG`knlElbk(J=1E>gy$_L$YR_TL5_D$WJCmPq?AFmU6%lYD3KJPc5=ktAA
zs@<nS-EUhHKbuFu93{fEyiH}H`g*&5#F>_}cRgPZ6Mk`+&EjdASn?y6sSh<ABV7}O
z13TeggsO12p5MMZ&X4JNy&wD;<-O^-N-OrmdDhGY8C$vcFDUsgjRPE2S#`aj&W!JS
zvoVQzoShNl@DV_el&9|UnmjbPZyWU6_7VxMLp#@ku3C!j2@Q!$X?BSmFm1)o{#39+
zUAdztnpXZNNiT7RL|UJN7oAHrDIl6L>d$$sS_v|^fwEhmmBy{NN6=}`X7_!iGge1i
zR<rH<elvcIz{4`^l8wh}YkuQWw{fuJra%&Bd4@Po%nx{BmSNGm<Uix!u!e?v2<$*}
zg^hZmVZLi6#%bGY6tzn{-98h}(NDiSL`STjd+a@u+C!rG3Dy}e+4`2(a#U-$!lR#B
zHf?UqaUAemy^VU-6zjeMm;SaQN(NPT?pN~V$sF$LK{5LQn6qNuEKP}>H|V83nb#XR
zx?7F)z1*gosoG<C@2-}<wBAzN?GjubN70DCgILfY{N$0SiFSGq8Jr>%2A5d`<NZ(l
zOwvA{!+${B6`W($w~2)|?SydfcY%_=#C(_$54mo(I{No<oIUMs{&sl9$_e}}XT>%0
z!@T>7q5RwaKzC^tYR(qA&<HTb1ndK+OfQ#GwfTBE4fWl$^H;kv@*H~N+4yYj==nTc
z!(OzTuZ<aj4{XEp_CYy)6I};wUy!SS(+AJy`UJKQ2=v7hH1X(lz{0RWVfNa-Rqyzy
z<SB5ED)0vKd{j|RY0f-*oy)e!Z;!9N&CYYX^lrZNx!9NYK6cHq;AyJJD{9Zb?A=1K
zEW2?309~lhJ#9T^bMQSbyu<R}UKMY;m(&&g*%vuXc~r*LR*7J|D!%OSncnFJ-TC_5
zR?BzpzD&xB<@XBUa(WclDs=DcZnfP*rYDY<=6Ii)x~!XNbXlYUO^{!NyPurPjXIm2
z56-b#+jv|zpQHFbZh^LZq$_2vR$8rsqmSK|w~nCq6MtLZ55wXumyLT_nRw4t&s9hY
z-&Y`!t~%b(ZrbDf$~2x@<;z&iR^t;z(0^hGBl`k_qb7mH04hzBuABbT#`1MPZG;UM
ziTMxA>Q>CvuyPUK*M8eqt<l?Oo#_$S{0SAMx1#R10hoDH0sJ6senoYLU>nez@9mUc
zr^EEL?@ht)AooGfX77thqRxIEjUMEUhkA~^jOROiWOd^d{<jUrx3%VMpRH;X>Fw2|
zOVGIO#p~o&x2WM&c00&{%W17RebvlZ@BJN0?`_AL$mbU-sJn)G^Q6OaJmtgd%^{;f
z!SJBu0pB`%b{K>Gm}Tp&*!S(A>G9(w_EVL$&lYUA{UMp&6G}t6C?+*<r(Mr;IK|hy
zKPB5E+PfN73S~-DXCAa=|5!B0Zq8jao7D<}WyJS|4t<H0>TBz(d5L*Hn6}weC~Cg~
zLI7N>G_EhJnlo{Tww#t!V|-qSFpEM9wL@)vZ@p394aNm7Jfb@};UtCjUotLN+m;!o
z`||J>tQZ%SvzEX*Y6$@CQ3*&Y67Sv1$YiTfBG^scejJvTm6e?=Kt+k&&IqGsEolyY
zik@%`O+eOM#unp}qiqp`67PMz{0{vs8jtEQgQdqD+7O=sew<AL9)IdrFpM#}Up<>T
zd8R7bK6Q#BV-DY6`Vo8WUR>n$IedAnc>v&-KPI$Lt|XM}RQFqQmSyu6=$_HbVCMqW
zv4O@kBRvIX^{WVHI0fC(*UcHPi=hdZDfa0jLtT+vQ3x!vxgN3|1r+oeMNdL#PNtFB
zYN5||5+(CJyzU9vq9L`hkdbysWfF+$6s%)4wK(o4&y_Y~z4-Bv&bSM5zRpuMC4wp8
ziWuk$r9TQ;&(%kvSDCa>mJ@=beg!`8CZh>eVP1M}fxe2y8H2O=B;$(+CE`W?1A*v8
z54^CE-ZMwiQpul5<G(!%_#EMRzTeymyw3A1&V-2kGtu*T#6f6v>RTUAOI77z?3GrZ
z>|V`IyLkzlsyw!IniW;S;rXXrL$F;iy4KZrbp7ZAiSlxN3PyY+D7;*M0isse&*$8L
z1ONX7@`wBFzO|UXwaI_M_TNa(iQxY${{LS<;D6(PipD!N=$#+G2ku0f$yrj7WA&u-
zc(2b`;%4JsknzUxQo7sdKjZjr@A>!kx-nBIGdPL$BinX9-ea!OnsPEYS3?s6*g-|M
z;zYizgzy};D<@S|c{+GtY~co1reYeOd-wD>+heT92${}A^@Ocmt->fd<k=R%GwIqs
zvgGPUt&`+rl+RNxk}`NNXckJ6`J}PBe_8i?zkQe|!6|PpIcZTin};bd@`eom7X}d0
zX0`S+7-py*9pE0BEry(c8)d7N7$rvM{~Vp<(%rIukk|{tZKbBGUyvNMDRS*>o0JfJ
zr4mmNVy@V<_bk;R>!d_^Z1r2#CF!>x_4LkV!MqCPNMpX2TlM}=zx4y$)4B$Ft>?+F
zyE0;Ts6%hn9ZZ?<mm8iIAU<aqLvQ4un-|$}2go8d&v!mF*)qr`(sAxX%fkx+EVMOR
zBTfeQYUmz_AMFg_S?)P!sN><BI3>tCSv@11O26Q(J@9d-D|^2|Q8-Tma-#tn5)4c%
zxdGzD@qS3H9l1sLZl6ezM`Eq?lewbF(^O+12?Iv_j!C!<kE{Jg1S5rw0DfsC7}I>y
z?fQt7eXwybj)2AIE%Xox2u%q&rVZZNzuTXGf65Iuf@J~FEc^h((qg6iVeW3nSup?v
zsf_a;Wa(1Y^@{?gihA<>Ad5ox01bz0^X~K-dstX&v{sye5-32ZGGr0sk<(W%BtU^f
zO+d{RlL*oT!svI`YEejD&d;=;1Gs_u^m}zHr@GpgOw%m|Btv;cz0g4rH8WlD;MlYE
zC;BN4c1_jL=JlWK!#T3N>v(Pe=gY$EYpEK8?XvI9$hHD$8oEcl@$QE0Xz_x@_JD#`
zF=MQ3G4VKclcY)`p>#jY$Y5|%PUSEGHkZAT8E2AQzrLVoTB*^bhe=s>@{fWL^v+^0
zvOGKGNh1JEd0JAEhW6wVli_`&3FCU-mv;FHe&E@emXtxSQs@h;!6>;CccR;U(rHyv
z#XXB~eo$XA>chS0E_@!aXLnAyQn!~r3fA`)(hqOznjy+&6UjW+ITy5_4-WyToq0k;
z?T*#k^qOaPRbd1Cb}KuS@Lf{i>~lnjgmGJM3&)76vz(0lB00^5>8RB<l0(*{wr2<6
zd|Dp0qHB3Lz>649k)=Q5cQDB9#Oiq=Xim?<P#RxD!6!J!E7h*AwP`e*(gk^Vo1&cI
z9Rg;qe}b-d9=yIMOg8OQd4f$lOIyk2WSUZO$S#=U{GERs2LUE1Tlk9pw3(Q7HVl)4
zVZ5rA0bD=bfYIEr!`LyI%*-T#`!Z&()n_9$QyH=Xbit+@EB;>iY&VyWu%4C~L7KoR
zB$dxUwyw92R{e|9ZCeS_>sy_>vcs3R)5tnIB@rW|W`2;1Pc;l%gg$QC;U!d>PQP$F
z8*Gbs#@3ULh|Zkk?hUA48Ih}Qw7cF~3pD}1Ho5m=PI;GUywj_E^W9>}G9~3EQTbs&
zx^H_asTxVR?h&fNo{~Lj?l7w~eZl>Cq=boC2Z!8x*sjEQZx4B?_(d7e@~by?NVYIA
z`&5+KulAy1k@-kFO;0!972t<^x(Zr|^EblOG^5F7A;#dF-(|cIaGnn_v)^s%8(j+a
z<jyIKc!jL(Gzf(f9NQ;|gwe_G>KkaYT;TY_ESMPcaxzW1*kQ<urmE4{Zq%hqg<SPx
z`kr?oz>3bQG9s07O0glWh~km-T%hgu=H%hsXm0`m$&^*Bl~B1T!}zf9PgY%aJGXP>
zr9O2b9@&3eJ6yV=mqm&j-tRavIAS{U2u^Z8iNl70aekaRBBmVhXJgof;PJ5GBHoz;
zxR^SrnG6*o=BUF+z{@>n$>~yJvm34P{A0SM%i<Z&w!+RFfD{aDdV}>C^1K6~TDNo>
zoiOfxlWyE?JGf!CtW7e9fQA!s1Jx#P&ZZ#4##ps<Iy|sJ99r%4O=X%Po}Qf8tSB4+
zC6NO2)2iO4QHlbrspQzU?AVu%z4r&zUUAH_fEhNG<;*A80rvJUg)FeBL>e+8r<V9Y
zV05<J@lmf$=%n5FLs8fk6A}O>nuwb-_G>)Q^BfO1W#x{U^xLdM1J#_b{*rVcPsAE>
z_CD6uJVn$iZ*8YgD3ssQDZv@<`R%i+9D^duuD@COu@x!L#pCk{mEK5XDCxK0QJCs>
zv#!-LDeF!2wTog8q4#CB$<5W5kXHwnADtPG!+wQhKC((0rGqAzxC{=Nu%uE;VNE|i
zzMa#8wKJDC`X7|6rfon^+F5PnfUnPf*uYg2YtUjdoQxs2A=0*;m`909a6TfW+vvQ;
zW^5|IUq-XkX4|^6oliE*4GApIud`o;ATcbn*=>@QO`y6;YTN&7oq@v7zltfrhWxlX
zhIc!@#GZ1p+^|qEM*&=~I|=(ZwR{X!6@Lr)o7OslPtTi@Yq4<?BHOqa7N3OS;l9z<
zgyrgd2g=|m)n^8<5pb<uU`4X&`u5*94teeC;?Zt2{T&sDjU(VX)NJre{=t!Eg^_(%
zR7A?y812wowy4|f98533repC-g#*a<UciWR=C+@dENg3(9#^0vD4)W5<JbmPX0UJ}
z5+HY4Mkvx2KN0WUeiKSuT8MnOe|r7(8$T7(Z;ONGQ+Os}KJVpmGPAzHmu_~a)W?pA
z!8;oWOVva(65>yXLQHlc=%LC!!t)o!u%7*K#<ev=d%16v;4_-Jc-;9Ldz?@c&xibg
zmSN@enQyHQAbwU$gN?qnDMckqHvT4U{z`$kF#W8`xlo@pEWmd>+(FgU{wD^6uiX$r
zgcL1a)=MA7_?f1s1_jp930}5lNzTZ*@)gqpNr|@t2>+*Em~=kE6J*?qPTEGFBTZ>l
zwv^M2hOJ>CUXPpVWTDb?aK12^q>5SOgQW#Qa1u{LiLJIv+zt@|E;v>Ec;Zwo5fi0V
zw66?^4Dj%RXCr8T%4RU%J9MHz4ekFkpMHkJK<YpHik`Cto7*vPdgZpOkqrk+sd{(|
zapl3-`(q;Fcmr}OI^wq=fj>8#bB#K#)0!~@TKIrju_PFnn>b{iR2LT`Yxiwr{NRKN
z;`-W~TIF<~OwWGaP*BomnG;7I^@$X6rudbh-G^hCF%TOTO}5AsAEa^NJW&z~fk82K
z1%QmJ4HzuL<vu<=Li#ipR-o_|4h~?54;V^t#8=^M4?a}BsGFSNkJ21UMI%j8X%GXz
zi3~xsY@obVtd8?VvtVKQ`nn<c%^x>Rq@z_b*y9`jl)I8JnozN5ANgNqKecpj?p(~2
zOdnF0Lv7>Tf2T}IY*89D($DQbd<1fh11=t+0dCUZ+n3JNO?n9xVJhz|9e;hwxIHdt
zZ99koWeDQ9v01qU@LqCH`f~a;66#8(K%*{Xg)TWhK53jUYB9|`0?2fGVq2>WBS>!O
zJ}WT2m214Wkfzqhz&vT+3X`D-OB~0Y(IC3^c)`Pqw!^&VU{cG{i4u?GC*B^1Kz)MG
zaghODW9Ac+_cxvNGme}NQhVmCEQ_59He6>coDUIA2z{1m#TX6RQO(NuN%A?aCDBJG
zNiu<AS})EH-Dx}5h^<3Q7&msz-{kk~@^L>N+&TfbQPGQ)g6xFR<c>0no*NGl9~JaP
zu87#D%iWhFf{Ej?Qok4sxGVLM0?G~FBtn&^%>T2n9b;jQ`2$@qi`EI|OfpEKbL)pi
zqjM9=JXA)2LSXdJ<k~@bx7#8Kef+kg@iq;>_~vh~)cWK4jz4G0hNZ2og~M0#v}{>?
z{M)&%+4t;L+y3w1g=|RWpq>H5rg1M3f5XD@MKLb}IfjTrENDPEK=A3zjqK9kqf{>;
z4!!23Dk%NxW~35H10yXl{dC6@{Jz*i*D)_Ge!v}ebB5kGD~2Kjii<UGBjPFJrIYjf
z`$1I=Gicbu%-a;b8&uSpDD!`pY_!C+>`cnzSWmiHy-0xFUJDI6e(RB<p#$|)d;u*I
zCeEXX^1i>{+N~!i+P{V`?DHopn=;8Z+NtU>G=0Yn#1UlwF22v3GP17>SRJj=E+}WX
zk><vi%g{BX9xM2x*gc&h5Zg9@C^)X~>e(->Q)))+yWO~Sd!k3-VK+mh7CflqaY_?9
z(2BN=pXtx?+bO^$<=?eoUjc1*n2Re;Pr#0mjhEZ?B|;3!RNHku+%pWsS1w8h98AeQ
zfSdJdTC0u=-PdsK1Dn<G4M3lN&p_op0_ZPM+sIf1J|Q4aU!vq%!~bMgh^dIaZjDh=
zysB-4@z`#}Z~PR)Z~79C;NE{!_fiB+N~#0$>RHU2UjSe``j_GJ<V`nyiqQpU`UJ$)
z#CL|>*(2<825>kOTh3q0!00+IrY85BMO^Pw4qxDiXq)XrJB-*cOK(#j#fpUKhutR`
zn)2+9vcM@wVh(l$MK>wcs*k<Aao=cFNm2L&*|<dX3wL+T)kH+sMps><ePfJ5nI>`v
zgMxcF1-lZM7}rc*=$@ZHEm=lV3dq!S_EJ1JZ<J>91HJtvglwHL@u=!lV}=oHdM~2w
zc*n^rm+DK1*z1M>f|CrBueDQ1#2g11-x-9h8H<lAME|)GY_aNEtY+%IWT`s?`W@bn
zUo5t%7a&T=M(%HVW@l;z&ODti&s>f7{|b9X?}_OKa3eX3Tobro2dB)@L}u@^B`kH>
zC8`FPhXjOehndEnLla>fNB4}&cP^j@ZTh6OA2W?)4_OB5!|I($+@JY#11`So7HjD(
zv!&PS811_RDz_N~>d!?C!wzY=lB^**iwtPBKk}_$NU@Brcerd6o{XqqJr@$9*oI+6
zA_vcFFmzCCmIkJE$kEQ@f`rT&^qV~CRz<zBC!b62-sR$sVNm^Gd-_w#mLB4zm?rJ0
zKXc#XJG^cC#2uq#dF;4}e`+IL)d6RnkRZ-$V^nrjEwU$fS>G-DV}<t7lNIZvV@5?f
zp(tY5_Y(8iq~9mEvC(?2h7fH4RsYx;BIV<J-j%6auvzz-To8?+)h_yLoRO~so5TN^
z&T_?ajx@QKdMVw4Lrvc;m&Yru-Tkd?l}h+pVSA700UQ9lG~x!$!7+=!-Dhw=2*5B=
z>O2+P6g4KvN83gt<NKWbuD-*_QH(Hy@xh2a$H23(xWi^pVXPYZr<5%bk#(D8MZ*wo
zou)C5Gm<s!9XoM^fNW8{-nI@Gjit2ci*2`uW)M9L6HH*C+5SU2qh!i|CdeVuj>6|j
zqdey^Q-V>8<W)AL;I0#fO>i7DNBAFmtn$Tj6j~#=<9B<bWMOQjzGJ2k6;yLoO><&b
zY3C%?<Fmmi=U0eM-8u{`Pd+xF<3wRnM&S(s2O*c@5*Kff69Q#^X@$XCdi+TM-r{Ia
zWroGW8i9Y+rvDSC@(}(Y#dsM9P%FASHMl~sj<GHnK<rL(O00ne!feGA0+?1~s#O@T
zZPgqoNQ*W!SM%V6mH`vp7b{AufMPrVN=sw+&uRGef>j~Bj;cUX!{MejGQL9LEN`e;
zraFX3v8=WEW$oG_uG5o6#7C!{30p~0-|X5>hY+Y(oXkzik6faj1&BrW&AHW@94PAR
zWX3u~6_mFdt*wRGIRP|y(j*L_Wuy7A+slo0S!kP0b?@8~&gBh`uS8fh>a~+PI!#q$
z%MNr<-(W|@{^NQZZPJ}3<h<_1R}qiIp)oPJP2Y!Je8$k|q3GrPND@%ik0c`@2Ji(Y
z^^Tb6Qt!=*6CsE8Yc<<cmX<2|p^1wLg43rC-f>9$zWZatLRq0#AR)oo4?tTXxtQ0|
z-`N*H<D(-~Pj>cby{N$D%Jkjw?D;``jt=s}tdVA7ioDD8F}YM!vL9W$^x5TtBE*8T
zKl1zOelbM}{RbaGU%y6rM(0R<qRA;vU~5^It3NK~@~a<>`|1Ji7dS@%bsQ5&j@8kH
zgs8beFp<nx#g1NqQcwSqlIE+yi9cEZ;`gD!ma*PooOSY+ZQews-7<^4bvk7g6*k<-
zKvaGS9tH5WsTR(8zbnT0ze7(Adn}6#@Ku9JbUFifIY^x3oS2<1$WvJ}EV-$9ZZE4@
z=$VHreOzh{Jz8Z4ZedVD0le1dyo;U(tN?ipph26}ubL4==fw&AWX4`~?WvI*TdV5K
z9rau#Kn0TO^J`mdOh#NUwVu%>CT<ETO!=qY9<CNYKsbduG-s}y?rM8QMdU-}zk?z2
zHB|dsq71v!UwBvRC?i*Y9OAE^5uG~c7BOU4WEH)Y_=10j1pf2q6V($O$KkJ?Ec+H+
z#tMUf#Au`RM*g;gSy5>=mrhH9iTEEfJvl7<zZ>P!i?~@!>lirqQ86(jN#H~~%Ff|-
zFZW}qP?@;m9Wb2s@76m7IK@-dE~QnKU_X39TEXyVWZv%IV0&d`ivMq!C;wXgZz_t=
zzm%i@PVEc04Y>IKsQ6z1?f*Z;MteVu4fV%)#?!F3U!C3cJR|Rx`(7cU=Y2e__Qo-m
z%k=Y8S?}BS&aIF6F_h=?k`G&(^5^!69O8e|y%(!5Xl(9uGihiiicf+N^Zrxz^H9f?
zrQzXuOq{no%Hz3Dw{s6c?eLJval*%|k+bnIvDc!qd&*vyQ75EF_q|asia}+7;g;(6
ze>i;kiQo_vPH@lBr3e=!bZm+u&>2Ql+U>(5g5-q{AcsvgFMB<pM5zg*T8BOAnb`gT
z2P1ooUoC}M0s)BK@OwB57sccSNW^YzEBgI#kh4sa@DnFi+dB>52B>~2#Rd#;x<TID
z0qHSeV+6^2oMJPfWq<YtqG?Eo>Mx4k8|<LSRZzp51np&RPH9+glXR!omHDm00)FBw
zFKC){D1Rc<<D^4$HVttX+p*HeGFvvnxV5H9;dCN};zt-oG)Yyj=7uxzXMGdjuCR8<
zt4*c0f<%@3^lNq4x(gfOH?<p5EXhg_9e_t|0CT<V0Q3o?2|wgmOR)=icN<+FCXz*5
z75PWg%;rC1+gcIE2B?Rz495Zd;@~H$;@(&~py%4$n!}08AW?26>#}<DXl>!wYjM8(
z*14kH?L+1V29(sT;@MLO?^cjRi!5#Ev+m1=Mp(SbRP!R27LBB<+Pz6>$AV!|FE5DV
zDMl64%0rYqB-z<)R(a`niDa8Ey?t)iE`tlkBSTT%e#wgp1M8yJ0CzcN@SzT;Mb$Qn
zA`TVK@~($&yvFmE^%yE`b@w~~L4wEby7p%I$%9B2tp*>R&Mqf!{xFSPEJSC8f<N?(
zPOcR3-|A=4Y|Uuu*sP)ECznE+`g><29K2Xl&Mu&9c2Jr}+2hQn+)5wP+j@5y>F|@G
z+gK)F^O-P~p>dP3PBUDUS{w4DO`SuDY;DyS73&U=0pr0udR{MP=TWYSYI3LZXVwn>
zwVbt}pg{z#6g(6j4F*lMtZVIhf_U>CS<)5Pn%%t~w?7ieBDEBYcJnTkgS83+6Q$72
zRqg^mg6TQ1|007E@{1~;^@vB`v3TT>qp2$5$*qdi?}svs@++B8tQi|yX=uzY|3zZj
z7Xuy$P-hMfiKpD6Iu`ddo^hE<c5Q{Wch7-ZmsJ4;{df6vUidl$KMsqsfJ+(1q7y!i
z?JP&D9rYfa-*J_4JWpylxOuc2%ORZb`Q4T;E!NuxjpCylqW4~M9MzWC<ZL5n_m9Rb
zR71T~T?@B3xO1J0LcPa{0gHUh77Th}w*q^HPfz|>tD?s*?YuU^+_c<6*UaFg&siwg
z7g^^F+a@hmK7#kEjdqug(foQf#`OqjU0i;9eZ8DUi#L~ISrkzRd3>)2_H)VMy3+&8
zKuh6-Z~R6LnwC{-fU6iF&;R5C2x{4BzeT24X*&_{i>qTE$>l+d{i3NsWTmt9m))NW
znaVX?jLLWv_*l*=tc3A=mIlR$l(Q!)ubMQNKCrj;s6TOX^9W_ryE3jBg_93Dw!7E@
z2^qBNt^Kjf(w^o)Z8E196(x0u{(_uZW8|QK&!=3kdyra7kU6>L^r)seym#v^=aQZq
zjTV&eXZ|+3=>*36qM5h)oVzA{+<Yh`5c#=TRR0is8uCS)k~hGDgk3@V(t%E6(-37C
zx!Wg&lf`;*pTZ%sUlH|24?M=UgUQ_Wp9Hga^`Ue$_M?DeFv^(YUCgf25(6rT+0q^B
zUv$0ahk&{`g6A)F;xLDtxWEcy%+TROyv8<KZ+<;lCBv=Klq6;4#S`zmW#lD~>E;9>
zNdgNTjiz6q5N<Lk0A(gSfHZ}7?z4LBag*hE1K_0k?c*%VRr{;y`>+5@z4waoua!cq
z&ln0ndZi+D45baw6K?0G67|Bv!YBr{!&{XTq}xRtDZdw`dyHy0xO|C1#tVo0^V^RU
z5^)Y|nfVrE_-lomr#&}p^w#HkZo}K8Yx@6U?5(5X_?LC>!7WID;1b*&g1fuBy9IX-
z?hxGF-CYKEcPF^J`z619&b|BGyWh3m|7P_JOi$Ohs=J=&)74Gfb(?PcDa)4)3G!sJ
z2?#iNlZFtoD5h5Hx^fI=jv||vHvl&F+82m}j86K(CRN;e=3P`J)a~`e#nvATJZsyt
zIM|?he^xjbS880r02L4gyRr#*j<~;kr$^x4f-W}e$Ygw4$FNwO%xt2=V{jc}b-x2N
z@H4(uW&4VKn_u9iI5?~<_EnjfIUf%mKa(Pol#VJ@0H@#=XKRSxH00^svI1{0n-H;k
zd4c@93mji*NDE^M21Hdx{dRH4YAH#mNA0O4qY}VDefhq>-UmA6<rptMwBQtTs94Ow
zV=|S~X==)O5>Lui)u`p;kcSBhmM!o2jfd!APAW<|@*{iHWXCen3^)TKBP*;_XnD#F
z!=z;di|*Pnn7IgZYp<nd0FAXX^yF@R{SqBHwF;DRDdcX=DrZ$G((p9nXtWfBOO>%_
z!iIS@^CKidF3|A`A=4$L$6vtQD*l*TSkV7SYjFUo=w@5|lpe<!gT;+T@b11y9C*g^
zcHr=%WrK~HQ({hEavHmDy|}!+)RA~sI^tgh(fd^fIcP;bNkvyVn#{-}bh_*o#Xd}j
z#1|l<zsW|a6tii~($s(*siP=R5=&(udb(`i?($f38G<DIld#})97QB+dCv;`%B&Ll
z^X(vGn@QQJy`x(!b0Zv*@ROq>bF@NTt|t0vy;xNqMpjZ1;}QRxwN+l-*JP0@p!F6?
z(udm9)3z{{SMy*c&}&OQM$LX!akBM?nmzw;_w5};`rvM6pVHf?q=U0@FqSmI4Ua2V
ztL~cdgML#l*-}9gewDfHo<qv@P3>1RG&lGw8}8c5@9j^QtXz${Zh<T)SfzLjFsR=M
z1mh!Mx20Bp;FyPFC$JI95af}E(R}PvCEmUE)8sx;3J$Wf!Tw=G_ys`-Ku!j%YMV7K
z;*CW>BTiCqt?B4a>%|-k`u7m^P*G7CGpdKsa{YoLOD2Z_V6FfHcMeQKIGyB{?#ykQ
zlP2=MaY>WP^nuhULP;p=)5_l#`s-e{6$~e_<BHOB%i9X&A|hrocI-5O>Pd5YZ%KYG
z;tY6Uhm!J!l28?q9|wZ0Yo;>KsN~zN7G4ai6TXasV{yoYu!;l38Rg>C#b!&o3STol
z=q+)mW<9u{U&d%{h=zn6(tLyfU7_Sst*s9wsR41{?t({X53i$4Ow{{xV7S%S8&b2{
z_WdWY+Ca2$lM$YJtI}M14Tss$>NV*5XFH3a)=~C<#Q3-ku@J5Kop7<>vI+`pkv2{8
zdL5%!Nu4%C(_a4#1s?ImqPFZs%-UPGseVp9V{+>&&#CugK-=y04h{S}Kr8dL{U><3
z@P@!^T68%Tv<=TIeDs;Bj(&yFZ@d*2OOu}r+Vr(d3W5TD<bX5yZ{<z39N%{>So(+3
zEJlp%z(9UkSyi%_5pJ(HeOU}{tlgf47-W8ihKUTh4DmbFYLUXiTjxb$nx~XNos)CZ
z$iZ4+?;iq*7pN%25LR>wB{ZW4*q%uT*$b;#{CWSPqL}+#U07f1SXmp_4vp_r8VZnY
z)^)6&>wp5(1WzU6f{p4Z>sLxGEbCud>n-Wo;Q&<sz~6BA6^4mZHh<1uZ5&3M3KMpe
z$d_HR&&9?>&d|l8l*BNDR3i1|Yc%5W_pp(<>2%tB3L2x;fol}wJO4W!ZZuox&oW|%
zo9ciB@)IerTb~)b)LaUFqvp<2-c7LdMgUKO*pO!67Z|^IfgQf5m4}zX$pciU_k#@;
z=SENvn>QJz{saWTuJvt9f0&wy{N*YD!UHnVUe192Dm#yR{9IF?8^ZFN**75ygoE_6
z>Ro@UAaW4LpNmoZZ+e9ME;4NDQT_&9`L6W-mO*<MU3}^L#wz81%si}qa_X%h0JdYY
zjr2zKDZt1>p8Xa)u8`nnb*3yrW;mqTV9G!u(4<O}@bUG$BpY!?IX##OKpzIq03=Xx
zd&+E@Fr(&TB2MX~Y0iE}5TsuLOLf&M0;ismO(an9SW?7eEda19J-(SEe1<;%Q=%RU
zPh1b-ZqF}&aPm%BVDYp{FVFD_jtIJZx!hsJ!A>x%AwzIw<|>5sPB^@lI=E0z-Krp;
z<t9lE()5PGgpi7s$)p1ci=~w{pd>rX0-_3S)von(zT;0EU~Z9moJ<3$kr`*Wqo{S>
zv?K3Kzu$1i$@&d`-MS~xB>DOHVwf$956jE;yJrPgqcVWF&yg1DO@U2Oaw|t5n+(6a
z40SfA1M=H04i1TB(OwuFnFL)Ul>qt3Y@(7}G0(@?(}w>G$kd6SOVd>DJ|CJI*zfS-
zq4+J)=+{#H2*!-ePerrDQsEA>0!guzNANo86h5IL+)rs<nB*ILt-LCPH?AUWZtipR
z*!X(MH!D>kA-{%3%rE0Vt1CB=Y&ZbF$$K>{Wo#oUL;B*ma(2EFHnPhckQS)*?4bGX
zLq~%~8*pb*a#eyYIkb4lG#wR69ikKGc(>BiyIgceh%@mGgMEVre122vn$=1^xP#Yv
z=xc0pyxo`ngWiQ_joB9e(qb_QQdQ=K@Kno~<cS@IKrVvnQ~T-kI*pYtEaT-I<u)dk
zz5VxfQ2vBO-(!ZcPlRclLLA;WRL%2FD6hc~0+I*T;-loelSJ_gTQ@j79hCOly)J@i
zn9GAG6qN+`tLnM$?e3VemKO~%yuIDV2Z8b0ha_JeLZ=U`UENw3XO^88<eu*ou@@4R
z=lV+gQ!DX`@LKdp0LdfvA8$*EXI9cQ`r>w`COobg?n?rz=)G+Z@0L?6ilUqD!O~r-
zbe<%i8oJh#71hSe{;L%yW(>LGO1!h0AYgH4;K61W9gjYpd(L2~`CC`+<jhJq&xhMx
zE7RWBKPxk_R3_AF-^JTE-Z<-=7f(iYMlf3rGlt_p8u!PJ`>_{PRpvzw1t=?l>^$#@
zK7RJvYRa8&f?2Vuz~m-xP5FibyQ|NcQ1UB-s-|uznLfqm!9Y59>)9V6N|6V!I!~k9
zWu{SS?|ml#@2A7j9)TTy8%||yD)h<-nHjUyFxC%heL1@uT(9S~dfN+4S({agB>KIk
zwTwiz6B^BeZH&$YI8_m{A%SuD)rY}qtAj$RpY@{4ny72qrQr<jH_;cjNc((v+=2Ps
z=i^Qui8QYEXR=5x>6!13Ym(?C-4C72<u7jJYd0HTb`>Y@BxYMWs@6KJRI5WO(|Lqr
z-lrJp-TBPIDz%y!DT87gm@l|fB(TGaWPghJ9CD`x{QdI5(D;E?ZT2eynCF&@F9%l<
zws9SIhpK2WFg3w3{Z+v58gB$6Z_{hBOE$taUTSXBJMPyvM!8>zf%rIL`tVcw*%^?@
z5joG1snujf^o7O6$~b+*(fSrqzZ9IUtDx51Xnr9;oxL)HW~y+YItKra5qx>Im+SOC
zP{%Z`Aw__R9xK8K6+P=A^2n+*BqSsR8N!q(khN}JT59N8DdD86!X3gw?NDTN^4h?3
z(yS1tP8fJ-8Mt>d>7k1-@NzC$(^9QEpSRIcNEg|jh0QE1uOC{UG3U*ol*cbI#4KcI
zEA+7_k5UbO+>O`vD3-=P5lUyV)QC`6-$QyJ^=`UM*#YRH;@}MBC08jOi7z&&EE;9S
z7e!*1CMW=EMGzj{1TB@eo<ib@5572#i)X3<LS(`=X3=O@9UC$0+018tgSdO+V+p6y
z%zGsiSrjA|qLpZ^nc4$8^<VLBh}zQkn$7VtQjxJC>lwQ>;k{6W8;~XA<OxwoqRujk
zLDH>tPQT%M7vIgiPmTHBc|?u9yDZdtlN3ZoQ@3~-ANwd4tw99eVeAity<}+@0Y65|
z$Zqx3ad@Y>{Lt7%;a+%L^{)_5tA#fau!>78cNfr9BESJZy$=G>oevASUqlq@f8M07
zeb9Iw?#MzxkVpf5TZx497G&(84bk9LYP{brj8>grc=gUK-s*2J0+-A;-i%iAEwvku
zK9<H?!?;(Hm&9+-LFB@&ytbHo*BxS!i3e0X-}f2?qk*?0E-2|)&>P;~y|GU=%3s{A
z`yZ$E0kx`~kEe}?c5q1red4g;8t2|m(>_oY$DD6plR6jFy(9*@Ol_zln3~>dy=F=a
z8r#x3U=|S$n>y9)CPRs)!9?-dJzawt3!Hr>9Bl!2K(JuKs@7hwjIJn_7o#Sh-*?_K
z)4h9$?+*9t%i%5v9uAMd9mI3)n<?z3H`7OX<DZb}Nwd3Z)pl0iAEv6ZT1YBd)|oyR
zR`|{$|72F`+jJhDG*T=cDDF^R(QjrkoTQq=yO5N&ANSZk*Z@nxD^Xy2^GTMZJ27IQ
z$3~hj*Ktd=>H0=qlNX!5^7Rq&&Ke0~M~SCpAGc&+ky#Xk<s#ab_rWHn%;~I31AH&n
ztr-~@cC>Qcw5;ccDpGDtTJwWPZlX0K8*bQ1LSF)BeD&AoHjI-CzI~TMRv0`{q4pxg
z1~4O@V4yA}>{ZUCKNv-M3|D(r|JnB26o%VHaW@T)A9=u3NI3Sl1@<@IKgaL)RVVd!
z=CpTMvX%-Wv2Wz4l>3#qn1*_WW_+SeAMKSIcpIa6?qHDpqDB3|F0i=l`g)vDFQAr#
z=j|QNLi}5)@2Rcv5oibsu=jU#7LZJgcP##QqzK*2N=l1&Vt7=psk^A8q-7^Bg{%&G
z0C;%zJ;7i#7A8Z94@flX?{=M12OE7CXm}1dTcLh=U~Z^8vI&_^8R|v&&fz?biWOoI
z-0wkK=h3-#lb<QG<mog&W#-S43hF4esCTp9JN5l)>`MIZXDsG#`KcLP#ak{s6h(o$
zQQ@e(eda-@&kH63{%y;_`^qNLR5q0nyKX&-L?<`$5QTv0qpwM~Q`51G`(-Z*Mu0_4
zhsk|?Y(&%o4!TR~s-#SoX?&x-!(2js2s`UZ5u;TL9qkNmuj%W-qM#Mep27i8y~uf+
zD)t{QN8fHlC;?;XtgZ{bUpGIh?<&d2pywi4RDchP8yS*3?Yx4pde<mB)+-si-o8xA
z;53nHkSH9zwjaA}K}=l=;FV4*gwF%wXNXxGm<h4wz-_JD`JTWm4KiTkX^s>NyzLo!
zl6T96Zvo<Fd<_%;Jt)a0Ot;~OM~UYAwqPv{zR-}qoP^V1FA<jjzbFYJhvTE%ZP#=#
zB7UalO}SMTjb#}-4a^J<1sm&5jFd}OePPto<9Vk-S3Cym=Omvj;y2!oyd>~POM@8}
zU6Bi31umW+y}ic0TZWlg7$RVKDE;i}=I8SJE)>x)JhQ!YQ0{YzdRRikB{^}XmD)|`
zp;t{HOKs-bhC{z7h)~+Hg1y~7SNg`B!$on;;*j!3QfYRVFvPS^+gS%)Cca%$3KI*A
zlsq8zwk%O<j;X5}qxF6w<)Y&8C8W)YYVSKX*Kt9~))xT9-Yip3+_+(M31LkaH8O@l
zQp}#BkEkIS#?b4;Eot{o2s!ua@jC&;C87`T3+iF-IX=$2P+-HttO6D6)J*jUl0mv)
zLaD<N&zhBPrb@8#nps(yQEFITy?(U@l`I;zhO+;TA$Ms}VfOt@+o+~Zl{VR7hIC!8
zD`W5`Y$j<MqM%v8W1fF_4VUz*^%le6kwVJ@c{B8`d<2=Y`-0OshY(}u&K?sQppP$}
zOdiim48$JRK8WsSz2RH3_PPCO>Z;AlE{D@^20e9K95pn&ta`G}zK4T|Q*_c3rCQnK
z@{y^-T7IK)71sNdgNqj<k$q82!I$F!se;}rCoN33%KFmW$TW6pUwaHJz{rHkVsf*&
zzv0;gP6A$<1EuVvk=XL`u?7k&MTg;=WdO!e$(4XJbJnB%`b$|9IvJ)W3yxWsu(|Z$
z>^VsKQmwgH#?yUtXB&~S)$Eg&`kot6+f7Lx)RAA*EDV)K@9bN`=~wTql$4ZU1gmE6
zsJ+WAL&S-9kFA{UK?MAnfPf#Nj+iBQnXdG?(F@KLLZE#?Vo(p$D-)!<d`89PwI%C$
z2>u32_rLm!NtA=!fw2LD;8{moNnqT^6kPBo6Y1~A>s0&LQId{t3l*zu-UGcBSS0Hc
zf<UfG!)(zzF0EKxjJ#})pxyl2WT%T%jn6y0Ex&*&qIUfz&UkB1m{<J}&L}CU)WIwT
z`<+s3j5B}^Gz}obmW>vuC9jS-|7T&~4Q)u>{9PEAKcpUmeble)wjd!r>reN)w-7r}
zcbonYqSuni;;tzeLLB?YDGZVvp?-lThE2kJNWcK^9wIMdf+}0JDr1Dj2RffU3>JCU
z0B`4|Ul>)|pVn3vrf#v%u$dM40nEiv>DB;?t$2WvS*=f{fMSVP=vT9@9J-0q_we%{
zFj$4-@1Y`d$9o%CP)yY0(R3O*ocDW}vXSs`1(++f4yVc{ma4izyOx@;l(9c}_(|x%
zaAC7Um2JC{m0c_ipd2yJH$v%#@wU);h?yLgT`qoPE~^^MeUXS7!HIP{obvtsdn(@-
z)1s!xbz0`&KFWqWX!7kg!hR)!3^pDK#j`M27vZ+J=#m*DqtvV8p%@o?0UndVURM64
ztxEPZhU>QXrXA8<X%hEaDvoYlcBCA%w7lk)rPZOkRY{Y0H72!7Gtc2DlQ(hN10IBN
z3@?%P<JW=VrC(6BrnBvmmp=%(yoY#SC!Y=V^mul;KRco4rtg$W&NsKrNMfkoiloxt
z#a+c~gr;xv%n5(c9KCXjJ6x>XjW2AsATSw!y{d_)F1_u-dV`O4@s6$qR76J?5w~9F
zrQOLpfc&!LN@~;Oy;ND%K~`=qXvtL!DyiYp-Ehg59DIIsmB?j5y+E8_hX$li%cY|y
z@hk|cONV!-{H!V~ORFuT(cR39M->J$qh2?)d!N9;rHf2`Io`zgK32Ba7<#(!MSzcv
z&NGr<@!E_$v+|Jwftr9O$Mv|PSSEVyVS>D4N=~o@KC+q1nIQR(jS=W}v=cHDv)z<(
z(g~Wm<^DNT&_QvX@pnpTMHut#ndJkO%3^nTW0l1&9qA308VgZzJm09`LPY@j;>|l0
zaoNzZ5s^c5B^+2M1Q44G#K&vV5(`_UkFUa2Lc}Bg8HsWhyWCc*%DjU6JeiLXZV{Y+
zeR~@bj4o8xZT_SEx8rn6{-?Bk84Ff@EysHDCPji)#c42wmEcJ+r18X0*bKt;6qc9o
z>W_3-<D<$GU2Apizs{ny_VnWhu4q)hzWQW=WUEe@GogFdzET<9Q=KkPMz=rcIhzmV
ztJnSXxWnWja#<y<bjFqP81eSpH>(LArFMtl)*I-x<kjlde#IYy3h(sTe{`FS)>Rh1
zuNvPR&U{N}di_34UXsld3G9TEL{M$oN^9b6te|z;EfhNH9o6x&NaK0QaMPm;8a|3~
z;i=os(^lr?8OeO{<G!&QPZf=RJ0MzYmB!vutmS;|u^KH0E+z94J3#-6@a=#t6Jmeb
z`z%691kGIXwvOh>_5Eou8#8%lr@qG*`?ZCM=bUn`Sb%2lkr4lR{>@5u*E6TZ*^D+9
zCd4;3`77h>Huv*WDtUBI=IDyYQn$(QGTv3T=R`LHSWv||5$BZsN2r^nu&PvN;N$#(
z=1*iUj>JJG@2v_^U-ezpkhUtIuG``CCm@d}8qlQQ!~5Bu(9`4V9EI?GM}h`^llnru
zvyLE%iNww&q!s_g?w})f+cAV0P--lWh?DZ|N|3+0rk#;Z%B~lRb@T8U{Mi(LNCW5g
zNLR%wq>RQ4cE*fU>w^HGH~cyrp1<YeW-O^Tdc<V6IOcA-|G0tsu)g`eXor|+(47Ia
zn7_U*UyU8y7bJE%!s=pztJJ<MY_ynYv`uLKewG+-SAgX92%FC4aX%}0=&_$3TenY=
z72WyN|By)i;(Qxz`DKLs=yWlEFv*46xN&w@JyhYmqaYmrZPBu}q4!{;VRu7+(t_vX
z#ODVoHLr1^*yID2*TI>g7HyzeK5CW`nGG2mPgb(7>wY!niHvyg7fjgiN&@})9}V@@
zV>_Uhi>~59&Rlnmy*5N$eQhtl$wofoWmm$A(q1qawX^r}X!>4QB2_I^4c2i&K@Sfg
zE<W@%th>I)Nnxm@atGPZ`N(`oA^1#`Bl44=LlTzmR1crdu29rP8eQAP?*!_*L&YbR
z?(YUBLmj-TwuF0QpRT#erTaj%(alC)7xgt!A1#q&^Sdv+5nbWc--fcZEOH|%_qBJE
z4lM9lZmD}K?3erXFxhYtr|+fdz<XXoIvDln%6o%;gGPl)*;}9(@$>DhY}=+2d$=N6
zgp0SQcoc*MtawJ8BUy#n!EaK~UxsL66t{+5AWk@8G-mrq5=6q_(UWuapkx)rwS>tc
zwL@12`oC@XnZm)p8kiT6tuosVF$qfOXJZu6=#ejF)>>Vxh%f~kqS1E&7$j)2IawXH
zsKb%rsJp}%jFf^IW4=7oFPZlM<OgvJXi4#FyZQ)6?|*}2FNMKU5u>^@LFaL6nHp^=
z*Af|1mzHCYI<HKpUDi>DQ8!D>)NI@)L%>s4-tQW#?u|ni#4J5I12JR1Y@4a#Ukjy>
z!P3$ye~!|)OvKCjIC;VkXW{MS%tAZm^X7&q1kv;IK9|1huy#AJE27#5+11y}d`KY3
z{2PkcZU!c^@6xCB+nQow6B(SWBqV$1ZZ~Tr&1&5jpX%7nEjfL7K=6{65zHKKweOf=
z>ffdVd{Tby;PPRVkAMf&+x9Vo-gE*dyuXM3OD{dM^s4R@vox$Fs4waQP+ed8yOs=I
z%R@zI^hArb-k~wBE;{QR-f-tt%4w3y2R+A?i;LjRp8TW=+(a7dMeVZFlLv9(Tge}a
z@?iy}fBX@O<hS=8{n*j<quB>s?gerQuRj^`p}@gGaBb4Nb~@k3om(*}BEWY^erRye
zl$y_)2@cB7#>KR-Tk`!MhvjpF03zStJ^Gu}pPNt@{(CzpMLEoWzgAE~`TOQSpZWVb
zfGW{O*Y!SFRrj<KRg$*6$lF0vg@@5)7Pxt{bo=QvoNTyvaEe?(qXXb(ohN-3dL;Eu
z4L2h8U|c4RdJ2L+`DWisD1WZORKD+8`Z#}O@WOMLr`r<QdWM=sp4P*r29iNP6}UoI
zi;;h{@>YG+Xxpr0jqyqC8-CNsbwDM8l;7F<<q7G=rJDUDmWTTkx4uOQaO*rqs`<;M
zn&@{VvCrd+1kEkLN&TdkMj!#eg?pLY*0AR*;ScVOMTCQRvIYD})n|vKM=EL=uIX_{
zRsqAHNuH~Ov%}kSWd4R@RTXIkCAA8|$Aui<Q^w=%G$`~}X8kTBx@c2e_kYCQwy@pQ
ze@Ur1JE{Q?52J=kP$J0=AZ%s3g5OCJ2D~mC&hA1hHt`>y*MSwMuGm-tPw1SgT!(c=
ziJ0;Jpj=xBY$#m817FcjG1W%+L%aL@qt5Fk)%?UA_27{>lYi2HYC>JntDfiu-l3K&
zXDcHWu#xXj_5F9S{(vZ|p9Aq%Ydb1RNT?~!$Ht(l6cIJe$_!O#wJ>qX6tGU5_xgf~
z4-Yz-aIE@0Hq(JtWJJh;GHEjime5EW>TvVv>K(4V&m*NP(Ar}CcdUbho7b{({F!@>
z*KgQQflyye5gRamSVL4F)-h`bbf@u56rkI<z|_h)^xnTQ{9J9JK*0_k(}mFh%l3Q;
z=B?6kDdYmx($ui;kAQ$94qfDI-d@{KJ>O`gQWH{@$;uV;F~h{@xb$|500l@IPpm#z
zFA4NoBr^&ds}2|OF+{ddM4a8ZxZUcPp3q1cw|pSua4sHi*71~OJxS#u{`Io}k3G1y
zq^>ZLL_t})IyYBz#^~<ieOd;$E!a9bl@X^@T-}fn__1%@hO*_W;38HikDET!EXi>f
z9!|+|PUShbCq+NXY08R26`@$Pxn;QRyCr-HKC=VpLwg0opb2N0GK;^M33M1d5`=n<
zSA@SekR|VHIX3(-v;>QD{rR#Go5zlq=1NVo*7l-wuj7;EtqP7jxC#BCg(X*emETQ*
zt;Nkk?v4Eec+;~s&M~XFN$Pcdwcma5y4i!DD*N%%a->GDf8{k&a1-O{Owycg4D51N
zla99&*ko|j#6YFex#4KDbza#ws`Iq{c9MsU{!X?Rj%c~><?%3h_POuZq=PaagVqc1
zl2K`H^ZDbFWL7$*5%X7vJJ3EZREzr`bT<w1o3BLf%TPByxp0lIiwpG=92L9g_;D%~
z5$+$OlY$@buRAt9D?gK3J~fzVrw=iWyPUlvoBhf-Q=jKV-M4EDh(BG=+@tZ6BGfPK
zcakTH82`-z4BOy8)r?ohBKdM7bE3B&#aW8v6c}P>+CrtnYzP<*uBq95)SV#c-dx1f
z@f<hU?_DkPYGoU~N>nG;^nNH7an$)}4gy$I%2#5FlIh3$TfOkxFPmhSV%s{UpI(Xj
zXQ~zl=#IRFpuu}Cf+aZ(z3hGT_fi<Av=7$&Ng?NtphgNJbnT-)+_ef7NQ{G=74gdg
z*WbLXKMMmwCA?$xnYNOGXI9P%z(}R0y83XhBy?~F3ypbdak6mp8%W<(Qx9DdWa3XQ
zbKB6v68@{SF08Um9fzOyvsC+$N`Pc`o6B-AqRtQf6Kz?UYODX#g!g}b?uFuFf&_mf
zivWWDDb$YjOh)1aqwhaU5=Xb9YkO>zzbX9^MX3E@kolka)LcgXhm!DDVvzy)^+Gnt
zkPebaXj?IhHq9zy;qy2*TpTa8suS5EQuz#2f`Fi<40&I*y70Ps4QU(C?(2EEGmHP6
z0LY-bo<s=Nypihh1F^1zSWfT3@Sw9z)JtpE1J1?eQyDcojbD_UOg%)bwRe<{$@Xhj
zYxsZ}xE)WeH=iwRQD+4mTCXWd4NdWMDvfipVyUW}$m}$G+EEm=+R#@t3=B^Gbm5ob
zPO#8eu&lO2#P4O3^(ZAZXPtZ#DnN;|<Mk}N<dK9yahlz$r2$|X@RZP}{T7yGBd}_t
zfL~GeuOoIrV2j|5Ujc`5a@J*s7$V$mL1)HRN5dmM>F*gf#*DDleib05ptxTo`pfb;
zP1N84U5CFA?rNWFWRhapQPjZr{HI$e&O2bJmpE)i<m{(3R4Wd@KX|WuZl6vfz_c5j
z4b0fvR_NhKnVfVr_=Y+*R0`_Bk;9l(_%rHo*fYj#qT#`8q_wxsr3wDLw%{g7OX|D)
z^K(!}xJL?_Tp{zWK8s%mPyt?We%cP1&1Z?bT?WwH5tmKsEAwr@mE)ihGp6$^08w^{
z`eJNaW+}B+-(Az#WC5EuW9T5Ww?5y(Z<3p6x757QCoK_O*Aa<C#LcpC|NK8Rh3lcP
zg-b`**jZdJaA#I>5n~`UMqZ*4<}qg!0$Hcl!+YsYzxaR(JXETIyv8ife2eiy7X}0b
z0F|DC+ho11FtOF$xLC#&$n~j~m}u5YgLw5ADF+Q$!`@OkgWlQ2T+pno4};s})SzIN
z%}09eKfUmz#5~ClOm((0C>~u}PClpTDHh4Roa1kDFR6$R6aKJXiD$Pi-FQ0P)-qQX
z#%6U;^LtZlUHw}EeR6xS_<lqCH^{)rT)W^UQ6`8B27$2MkJfx=q5092pju+w9oD@=
z6lwetc0Iw;2+qV@1Y>dRaM#E5#L|Es5t(4JlcE3+EILB9m<)9KJU1=-&EAbm*s5ro
zIb0A3Vo1j-YD+s&D4J!L{>e^jsCmAmD==1xQ^(7#l*NiCj>IvbGFVG+EaTHCMX=&g
zl<;M_mxvcK(gBlz{L@!SE2&??>vMTf>wqdfitM4@J;LXLM#UwqW$D#D!PHMPpi-c<
zuvVm7-MWb(7b{aCWZ&3v>K9hWd@n)2{NmKNp0%AVr)$s_0UsXT{JYI?3BHccWo<^M
z-US!~FO83TWQ1$_lkMsxWj1oW!lGme6@@Gmi!o5wNA&UMR!rCI?s`Ect^shseu`!}
zzG7aKn=EJ*B4*%b8GCf3fO$T4NwOTDt0qrTU*?iZ0q@ok12vcxe}U{aO!~~mL$kVx
zj~Mw5H)ejz;u}U?%XV%e<09EW(+QL;IEhPB0qMhHt;2$IoD%LFQW6&3jI$W0SF;#p
z(YN>p&fq{a85q7m(riP98d&Lq_?b@M^c<}p3-ng^vdp<EniZRUlx%uqrEM%VV5b#P
zhF$Ve*zvYr98vV0ttg5zGZoZOfW-YlbebyMm+Oe4fuO*dFILO!_mp)Bbv7jeaXXf1
z^<QBNc;DQaOAVQV5tC&SUcW9?EVb;&<GVcJ^{!_~UE*Mw_Vak3tz1OQz8Ux&m8IPq
zm%HAyG*w8?d;uc=yq+()V61WDWG(uFTl2<u<Y%m??QUM^2QZVfdC2_uXLX(TV3}Pc
zD}e!El7}qNBpP?TzJ+h+Vx5IxUiBtK1lBcv-i@tYj={`LN*l1F*K8J+e^{N96SjY2
zpFm0AKn|#RFy1O^>09vqq=7N(Af6zM6FBc9J82Q>g+dZZf*;Pg%f!a8u#t%=DN1SI
zjaTDK+{MM(+hWgObjW#h6Syec4a@`uU+%d-+C(%_7c9R6L?y!!&qh15k2p;t1Z41s
zcul#1is+lGri%SF9c`mZc7mi9^HNqBZabZ4aeZz%9ZXgl8SL69i7Z6kA?=;R&o}!Y
z(&wj5WgOSLlSsM-xRLOnO@_eyi$F$cM_oXA3;RVn0lQ^LxYM^550}hs!eFhk#o-kx
zEqSZKpE$CjQI|_SM7~ACX_6i6eKJc^-n7Fi_O@|NeYRV#M`6cv!&iz8PVoB`9*vPG
z_z@D=L{l*DA|u+eMFB<xJL$AIp-WK-^vcvS=<~;-+KV0mxf4Tg?Pp2T+x{_NqHRkG
z?nXZM>~1~PWz6=i<;|^*7nNm$0W%}EfCg%fN!Eb;=<^AFetdjcamPJT)|0$_P{5)q
ztxJ>lpNb9E1+1`#;A89hjDF0po9&rFQ0RZxi~>OaYDQkieA5QDq`+I4^0wpS!c&XU
z#U?Tm;b{Pt<byiSs73bwBmVf_otU8_u3x3;*1$2das|I28w-#nlBaqzOZOF$WB|#`
z&$Zh+mo+>`1)1KE%i_K}ti{7)vo6dpHdsPMjE2}Pe<$Qgj1^A6Q_BNxT~$gdWP2S>
zviLK(yC#3}<$FXyTY#S*=LDXpEtJE;Pc#oWwI;ztV<r^mgU~Ap63q@N#O0Nu@=M4e
z%g{88(+*J-llQ%}7N%up7qSyAadgG91!&xKG_;%>{Ql8X6q~;6T0Hcd(Lg~Y9)nLo
z<Z)%BIIc(n3L)A>b;irZ!R$1`u>$%JbFFki3<>&ik9*6=Bt<3WZx(j$bdcZl)Yjuq
zNEwr)mM8CiVf=Ya&p}yGUBfZ!bZi&5feam-vWmF|RbfereC0tUVKXfct83@oSv>t5
z*ph)FWbyIwU!u<8vY)j=V-!gG*l0u!s4JEs(A^O;*qG(5+p@>a=LI<I`|@bGkRMaq
z+vf5Fai(WvhWD8m(kH(A=N0A$hEmw_BbWME$h>EMa(PiKFm`^x82jm2Ix{avm3BW!
zLS-e*kNot!wnD^eKLecEJ25+HAi>TIVITGA0OFig=|WO``~%+9)gy#_G7opHCgR>a
z)nR=K9FO|DfW27<H6^Lb`2Ok4Z}bm_(bWMk6R!6A-Uqx3ssg3wTznvpw+>bk0zlv1
zeK%vW{PA!YwLh;lr&sTXHdmsizKm3xTc<3pQp}s>4bWs#MA5!Lhf_U-$JdE$T11ZD
z3(Lm~z0P_sl@jRo!kN_n^F?9~0)JdGlc8J9-u=!rO?1**PzqwHDo;M%xt2Adb%zyb
zfUaik3im)V0*?Ku4q~}<er2@>FPIKW_(nwu+kEr@@!k2j{_`5{rMNKH{+0!iV!hC}
zp3%LpB3zYPH=UTtYzEQ}{w{%RQgrhY)<<;E=Xrmw(Z=R=QAME^2|B+T5~WnxrLsmP
zgiER5Yd7Odx9EQ)_L}nNF&i7RAH_0rbPQ|6*yT`zgH-B%2Y+Mvfu&iYW#BrPszed^
zDN2`4&`-t1o(lzzSb69FLTV}QH@hb1)!8J_9p<Z2e);+D%pu1J9fFDQ;)ta7@4j=a
zgm`m?#<ts&>8!}kzE+IYGS%(jjzE8Ens_mF1qEchMaeBs=jpkrnV(y+gnnmP3O%<j
zsYh2vaM9qIq<BfsX?i>;y)kAP5^F6AKlrOSG7LW%#HPkZSUUl|7}yBtNWXIlZDH@W
z`LzYwL@JzeYpVu(nCB?vIb_(F9DbI&hI<E)NG&0!m!WE-_g&$cOJI8~N%`JwO0%U&
z2aAK}#Y8vd$gd&u(u)*`MOs%yO%_wlW(lp|&XOa|3LzX8vm_4)9x69ax*v56`cD*f
zLhhZ5hnzO}ar?qiL@1_{-tI77lj(}~3+=l%)1J?4r8MoF@{E070n7@=`{<jRwWq7o
zyp;^(dHHp^ad^5LEHC6EL#+hv;?mXo8(DO=g#AvV=xZ#+dE)5^F#|5ZjmYc5SX<wW
z!7B{00Vp)i13H|lXEv-+l=IAC@Imi0bTp&?pj<BT{sPC&`udXUeP6XVZzFxu+A=iV
z`k%DS9J;p$6*5n!?NV&<Zh`N=d$2MW)Y>fgT)afX$)zyk9BWByvUBx)#D!hYyUXp$
zrRYxW5X#L5=|oqyMM$DT6o<&e3`T)ZVV{pNYfB}7{O&vK9hV4R2pRlxfRk{m=O;)6
zZ;Nvv-x*Q6#2Yh%mUiQoDwQ4rW>AC>U)sY38DXcxa=1|?>XVvm>s>=TK-y>KK(0LA
z5<4~Y$yLJ(l9IOG8sriKjLaOK#v!tvdy_t^hHI*;*0GJ>lhl`@Q1N6OU5D&3q%^iV
zBr<R`ii_ras*^eNMJG^FlT|Bsj#MMx;@R{l;Y@>M8U*f#AwiBE;>Y)CN3P?o`|^j)
zj>WyW4f}ErQn;bxSG|B8;h+bb(0-Z+n3$cRL$#wyWfwN@ZE5@@ODxbf4+H&08&V$c
zhWo3s1Lp?q8^5BCS}pL-mRlKu&(5<yFP6{uhjk0ZNn%<pXm|!6I{V)^;r$b*d?5<w
zP7mBQ@1vPbaK)LW4rc;c@;hdg^^_1!e6)>euLr62i_Fk`9Rj3EXm1<d(>_Rft-`3x
zOgu&}i4S+>!_Zpyzlh?V3B@Aej2ZJME2&x#ln*HnLny?oS`9jC!Iz_=7?E4jny={W
z5tpNt6M9HdhWeMEjJ!kV*h|wqf#*s4ymLhYmAH&N!nD~H^6JYrCT;2um)WfMFlBn^
z=o6>H{QTV82xUAp^z&yn=mHJlP(Lh6Sx)f4ldo@X#Fxxh&2yH1?B5Eshxb(tm@y~(
z>(mEXl#>|$Vvp2IFz=!xz1fF2^T-gEjl87G78a#;Gj)ZMlR?LfX_-;jL-Q74F|61e
zHj#g%#?k49=Ja=M#s3lTc!5>AIzKC_STZ<^!@}~7?1c?Gid)b^j{w9Y)eEU8T6wU9
z3?#DE%=4*~*SlT=@=~h&e4`1!1Cl59vUOoiEhxB@prN&WO8+x*cehlR|IL81{Nc}R
zi)c^~eY}vos*>95Sg|8d>MkK=>BrF8T8757v#=1cnq^w|)EMN+GyG8$FWBdpnHtrJ
zd&7!x8U`5uertyZ`>)?p7+()#bXg+g3uhh9&S;#ZOL_9zs(AlZpWG$sMRDS!31pEn
zF}}giq#CX^bnJ}7J3%~=FbwZtNSGmkg~X3$+j@?Pi5b}lUg=b3CB_b6hliJ*90eeW
zavQU>tk#Re>_4}neEtQ+j+Ql!Tu4dv2IkXXZC(CZy_PvSZJBkv3BtKBLef9t=4)Xf
z3-12o34I3s@!6y`7%oDqCFC6W%+HeZGA?DR2IdB_y=|Vjmpgbcq^$H>OT-3q!;FwR
z6Y21hO7j(uY7-U0y~h_~#-L+Xi=NE%p5)wI6+5IjuAmZj(2*CKt<MJ-rN3#b{3pUn
zUYwPEqQa5fte~xcD46)oQ*NWSMv5ZG((z5e5Sx#QC#`md&_%N7&9PL-D?iFOdH+xH
zdr1vP*4y)S5xxNk;A-m_EG*tZnq~)ihkJm*Qtnn}c<#>4bk3@Qv_=VQ^8hRB8SaMQ
z@1eD!z1v43Gt7vKq+>{z4mn1tFH)xb2fJ#1$R_~1MLG=t5bos`DXbSLf5bP_z&{!b
zwn!0LM9IKMR)DOt%;d%8KGX-g9Htn}&fd*TTy|dpXRgPCNAe4wgR+<U%A3U+LK-wc
zel0jh>i$bKMv#-`dD<<A(;4mQAy{+UUh47#5ikc78xVj9aG>Yg@?i(NqnYrD@JqUk
zv$NWp>2-t3Gt2CqvMbYNu<M76?ovQ$8BO;Pga|-KI;aFp%ekuKuJ>&bp4`eoP|5Z7
z^bsTng&k`Y9_Qx6(N>_VtAXI2Sx^8_pupg;pbe+G{6OnLQ`xdJg_)orr>1_pP!7yi
z<q5VwDQ15@{iU29q(*9Sn*jYpEjvmW4vHdBuGJE=wkZny`L`~pY@BG)HCx};K_e7J
z9hBbnfbUq4ROEbvY#DXWjsk!f`^DK9=Sm_z4#+zM%m$|ul?oM3dZJ!=*_UI_2@tr^
z1+^Ausxt7hKWYmWpKc5FDAt(DiUoX32+!NCqCJ4*Q+4mj`pxdJuSSg)q>mAlW4`k4
zS9tWPdYxTW3J-46t+|1%#@+2^hT*b6I2{}$Kn{0}ft=q(R=8L5!qP^$kc5Q!jktjg
zNaIIKTsH;HWYR!<&p}#WHcb9Q3Jaa{bz2rF@Jb<9o*@=Q7X>ggJ$N}4YyPM5bG60~
z5^Tgqk}+_lBK1EOnRfmCHD5n3OXx5m_)djolYSkWRRczQu1o^uuvDUOl>RXUE`J?L
zC~>&WOo;{cMe$wYzdK3)%NuzA8R*1ZQVJ9BE18)flI<V6AV3maTI;{O1-{R7;-}#M
zkI%sOJ&@(UJ%@kyAO8LI|35F{zkG@O>VMpgzyI@J%KyJoI_9gk!jUQbIOp|5>bQw5
z&edH4yl`m$cKKX#J~WFRWDZm{>Mu)wHZXwHJg}YFRMok78kO<Fe=zT*pZ#YdoCHE)
z)!F)p=>9-{zLcA7W?TCtI&b0hNtNbf!0(B-l_g;)y!Mg<T^H`6Xg(g@cCkFf3x>N^
zDA^FY1m<pbXLf&qLw+)!m!3Mpn%%;p%ri`1?pS&taHp#PJBS;*aPtGYBY<hacwXAe
zuooj{H|HeygoqG7mEG^vWA7ci6u!+yV_;$}wvJ_d_fqDNXOr&jy!VOfXVs1O`rR#_
z_}oiY<l~jLu|oQeNfyuD@U!vBnT-QAd95p&>!&ADFkA<If4(?C%W?Tfnj6@9!tVth
z`>EFMJ;Y*g5p)X81RN~weSyt^%J5u^0F{h}IgJT;!o`E4U8g@?rhj`EJuFDA*=Msp
zxN>NND<ih=FU2iVPt<&J_zJkb`1VXEt*Cp-aWi$-%e(g5VXzrBEO$sga|-vGrkH+*
z2ass!W*SW@^k<_PH+xsF7H1y=HmY%Ppb@O_4DcOqd08)j9Uahj^sDE7I#%68?mh+d
z-#ie=bjF3~$aSax0n#(X1e(*Cu?U&VtgC-oIo<zQGC0xzKqX8f*Dqf-+(ZL8=48|Z
zH*^;-RKEXh{ha)ymW^X=Kb?^t=l(YvMf?VJdqP{L#{!TC5qHeR+DA0bLg@R6^SdK-
z9Aq!WbAT-Xu56)L!n+puxgsX#|Hb}i8fkp8|6EUTcd22Gded9gyS)PZJZni00e$@+
zeSan~fw@P^!y6>F<JCA|7$LLmQu@!F@t|TD`aFnTlC%~f?%fI?!{ljf$^S<9KM%1^
zF86TSzDf&M4Z?r)&eaj!j!>45liqmEGX6}!+>!`3ZgF0CUXCKH8y>5r?xpV|3&7LA
z3wJwd`lhUjg|1ttj9uX6>7=Uv_WzhRfa?DnEC;UuseVqGJUzku!V7HQ-_aeRy^RfN
z={s~_ZEx4YJaUAPdmK3Ds7LpDzd3d?9U<y!C?HWCQ>*5Sb?ta*;y<fgOzMbdvY+OR
zBja>xvfmmx1XnL^(SLczXgphs4~=w2(c@}(iG<+2NDS%AnJr3%h3_U*ZypVlcky!k
z8noua+i2{esVJ$Yu$Gd7s8fX3SiM6vtF+%RjJ@G<RJd<Fh$?urC~KvrsUnY3gkaI?
zp6<Tumyj`WgJV$5VyZ&7QQcWv`a=L+!R~GR>Z<7#Md>%9c_tyUT2z9~$CTkAH#kY<
zj-|)Lek=DV8du9bS%{!j*6aVqyCVkYFE(DP_!p&cy-si&wL9Ins7kcX&t+|%9l@z&
z@|hRTMnVzArzX8j*|I((OOoC9XB3k+@2Gp2L8J<KCG4S--Dg!sgcvsCM*;2v()YD~
zxsM<PJ{Y2@0}$6?;YbQZ=@+N|ok^<|$e7YAt!^qGb<ex8&jE<8xLtJkUg~OQo|k9(
zJcNg_G@X!9J|&0at-pHyMqPrk+-m-AkT;7kyzE2l)#~Two@FgNvXa0g!{zcS?9P}K
z@Ml)NMaf#r?#chf5`+9TY(z~yI4#wIu`>griEEvVcfb<GbI{+GBFzwsApa3}CSiA>
z^fYwA?W9XLY4(s&@atO&n*^>oA6_NtJXwQc4APC>-(V+>`IH$<IZzEmBRHHQ@I^sj
zFYZ71IN$X_==bmKKRs;R>leXTZnz#r61~}Yo{@CO-0m;FXu6Earm^jiK3)#*`)u6w
zAgtG$Zi<B^TIs~S00R-dUXQY~^I-s=KAB$=sm<lz1l3-8=!OgT(F>+|cAnys)+TCd
ztnT4K*`w)OrqcCv*1T;F997sR4iu(w0lppr{Z;NV-l2ia(O+Sx2N%@2gE#V!utRqk
z(K_%L92N(>cWl7)tjOOFlTcjV9AJQDb>q-A&M@rOzH6W^KJK%FXytd7H;Nzc^Z8`G
zBxg9lzp<|F`(u91ntCoX@qQ?8gY4~ovZwm+(5Zi9`AmOxqI=4G;mv3@({MN-2TQFF
z{>%lSYbpL}YO)B-X+G$SIrPno#^GrfOi^g#HRWLY^}OjT7^Awr#pFl3yzTJkF(GWD
z9FAIwn^T~w8q*T+5OMJ`eIJ+a_}I&rD}HD<^AEwQ@7LEr@edt4P*Or-Jf`|kFa)S<
z+Rq&C{eed=k+IF?qCm%OnaevgGA%6Z2fJ<XWZiVvQqzX;ARA@K21YIXN27=)*Cu`L
z{jwxZo+2e<uya4R3XS%4j^nAp7}2<tTgOrr0srQ;j~)vngM4CGqAo?xs>I!AC$vr1
z`}DjU8K8(B)vm8v`_f7KTs?5yw1|`Tb{pnK^bKG#fz5T&6>{OT<h~e(;+onnL-?{%
zz?sVFG^cWNe0+Kop2*9?GUv?LUpR0boNNhfz8&>Kr1p9&jNk?|)3<vnzLqvDOBV6=
z&_(hRdhaDSO?jXi5J||uXK*>3wK~a00O7kfq))H}A*C==F!&tTwq%8u|H#ux!<z!c
zDDW;|LM8P=yJu1Pn6=Z#$hy_uHe}sgXrC_Mzfk-dmW^mLcTvz_4N}nin~lD1!^-e5
zxCvZ`Q(J<6DR>@F*X!}RMz6;5iv4<GF^Bv=YZ0Q1UK$6<G(CvMpr1o=oO}aI21O6Q
zu^L83H^y+BBKChspNf7CJO<Jby#x*e0H{-BQYyw~j?3Q}Rm!km#%><G7>RE3B67T(
z3=3zr7Tq;vju!`hjQuBfXW89gwD8Vpf0g(7JW8pdi3I&GDvDq*7fUI~{j0VvDBQ%l
z=NHE6fd=H!@H9_{ymMpgK%X@Bn!IQ!MTA83ID3K%x{V@W#$Dycp+NbY)!LXoj5GRl
zr+{Z=`E`5D`qSLBza#&kc+9tots|ZSn9z_eoE^jt*8dOg^j&mtQ)x_UZbkL<%2ifO
z3smw;X5p{TF_LHr85NZ*c5ySDD#fB9F_~DK89AtGJ<zvqdOG%GOiVXZIq-{<H8?z;
zr`^jwbX?4jOIw1ezo$rJXo*-V%OBZ*PEpIqU0t8CqZ^Fm>v5zIIsB%g_OaRLjc-jw
zT+oFNi7ee?Jb3q;*5UCNNICUEXZK*0_RHH<iS8+#m(y%##5WtBhej6WH<9R>K&w+%
zI>Vct@WjO^FSh|j!(IXNpvF@ikA&rw0)K+1l|;X={76~3;ZeR|_fsV)_Rz)@y#UZ(
zu+n^kI+V;H_TE|bwj&cXclR9<6eK=zte)pHR^yyz|FS18hD<}!)F7ZD)Sa40o%t3M
zLGxikLaK3YzPeX63?3?-opgwvEmd0&g~WJ-t!#RE<pNY^e+e2mm>|C2CWP4+N|OAa
zRcXcyp>8y*(p$gGyBMOuy*@_iNDh%m59)=NoU}HN5u4I-+U9~ic}m4#0ZAfij4;gQ
zc*rLv_Bs6bO9O_fm-_!$h(`($Q+Nk6?|fsynzFxkT3<}90vjrzc7Fq{Kh{|pQc&Fk
zMm1DsKNWahms+9e(>(KBx(_<@yAjSX!#Low##%-su2XTP^+;u7yRFAeh5W4%W{}Eh
z9h<i=AaADtE~(@B;q2?nMhet@u5E#n-BmnW{p;g>)WgEcO<)U;SMGl!shm{R0}d^1
zcO6VmIVJwT0RSu|aUp)Cw9lt=)Alf%YCDI9L>Cyz7eFnr#Ya>7&~07W#ZybPU9`a<
zJNtp75GQ}%szh#jjNfM>1a*kuz2y=h?z&B3TC7@awL5#*5+pSdqVjCj$c1fUR&|7>
zXGuJGDT}uKSE^6%OglO<MuU5Ka*<4bdJ--cmdvOJPNx5LSgXO&Ss4ExWHlJ!;B#%#
zJA6+40J{JSK9iy3z_)rum@UA_QC*6-^NLg8S#!_jL}s(3%7Zo>H&N5z3+I2dGA(aI
zmj><D{WnpXq#%RZC~1WWB9e161e@J&#;kWF?AtepwcD50x|%!$<Z)ukV%eRl3xkCU
zEyX=n8y~2VyJknl+<49VV?{(dozJSd4?Hle9egJ#HBu;?c)RXk)q$-*4?KGC=_sfs
zXh#&jc@e70NdMu`O*X14hES0t+`n77oUV;^z0GR^GDT%(Bdr5Ge%<UZ+P5-AWHzaS
zO?x7xIZDNw9Xb5kM5|NdX%{<|EsovCGN+o!h40l%#nln;-^?kQB5L$;5Q6`*<CU6q
zAUng^{u58Zm8g(jlz9DDt{j(d0%bT49iJHK@&#l<1v}eKOSCyi<vEk5$oa>6_j;^E
zNxd;|1-HhS*6bp$SAfT)9g|Jw7itD~uGA<Qgjtz;QvRxJs4-X9v)~Kv4ONMfTVY;r
zuh({FT3issf-VG!|62MXa>co^P+m254-vuEkiQwK7af!d)rFrNqKzQA>er#72DeUC
zDLL@0K%r+zuyRxt^xwJ@{QwU}t9+wfjSOMc=0w{o>ej2>4nNCAW#iO9CS*~l0TA>E
z$bT;H75>Z^M%!$Hz0{u30E8vIc)j-Dhf78mjp8h#r%(nn-;rEsy$z8$@av98`j+dm
zbObh;4&u{U=$<^8g)ou&Kj(-CvE}YGu;CKI|FTe@0TVS5ew9P|NnP~?L2>P}dz|&&
zCE;Z9vz1zV-S&`7^x}LTWPvn}cf7Zp*%@uiOk641C>Nr5*qG^$em`MZUfFWEsC7AL
zj%<UO<ob*&wtijKBfHR?Nou3n(B&jX$w-lG;#gL@7}k4|YGXh{IuDA=czKga)W!N$
z2y!NA^u}e4Bwy+Uo6dW*&%RCS2sr2FkK0o)^>BZlx6x8~y9Nkpeys6;6W-hT(O8dQ
z?y{%Xs*mO5>eqO6Lhen=+l;1YaTL<ej^_O!Sw!M0U_)5UHC^!!veIo=jk??CEpZr&
zPA+KCWi}rt%}|mxe<pMrEZp1{tcDG52x42oBX#jrsa!kAh-rOEL?%UMS#CNcT}`?h
z;5Oz|#+T75k<s(lV;L(^3GG}y&$Lh^zC4IhejX#n2x&Fv@s2~ka{vM)N>b0dl5nGp
z3OlcOD;xjBSNAi%te~)evydC^ZZ}R=2ew6}>~6Ng4RIXjtD4pLkYBlUf|OieeT<zv
zvaQKZW3TBXGl%vsJ!ydGv;wbnzTqkeY<<2Ys4xtB9V|`~o`>fP-g1+VM03I(tgH$g
z<wj(ri_9S%T3i{F56-Deo;^Y}wdKoV(EMNh<sO|d=5SV)_e`b;0<GR|2nmc2Gn|qt
z$Zfc!j#`4c8bH)fUN0a`P;#?-mH+JwXGREMI|fP-=>3H)J4&zyVjM@nJU`?Q59#aQ
z)*mx4PDM%m>u@%re+KCnBz{pazNmij4neeJH6!uXR)@`jY4Bf`+r?aP7~eC@U2o}F
zO*ZNuJD1}g@8spopss1mOk%zZQ2(#CzB?Mu?s<ImAcg2HN+O7wAVKsj(L2E^31ZpB
z>b;AwYD8~Q60yp%>Z(x^Ho@w>_r(T@F2sKKJ)igd{`tN4pL^~-&&-{f=gv9z&di<J
zJvfxG$(?WS>d=0f6LwXN3lo{VJlhLCZT1tElV{VpYcXEa^d8NEQm$cQGSd(|a->uD
z69qH!Veh1LdL~3q4YyMD^i1M#izZ9>48J=aOx?v}oxDTWg`y+u@*2a7-mN|ccYjQd
zUr}twN&fpk7k<d!&XMJ;3n!tBHH47t{)h;@Q3ANFUN}T{@;?3mY{6*Zp8m<6>*OIV
zySbI<?|j(a%&P0MKgVFV@kmb#pxfJ79kDc!Es3$K`6s&dy6)Hsi<GYIY`5jTTfg#_
zTYmpVb5<9O+cNNzfZb%%ydIY>`dH{|X*F4i{rDk^t1$so0%(T;W6e$r?>{hur5aiC
zzr4&XVH;NJb8=BK_8fU70wO8*5>K`h&6oUZh7$@?QD_k@@Y@~<2?CX)@+I;0bC*&J
zWw$rV#FH(XXCGCCeM)~Frm)hA`a;OL`bYD-a~LNV#4D-y#tRgA#0Z)n9szb;V>$>+
zck!>eLr+JP+t=eJFH?e+a?ZB$@RV<_0x(lOHyWPT!h-K#luRfk=$WL*3s^P3TM_w$
z`ckj0ve)sM5QoK(O+PeB08v4|0l;o@{!Nz}Q8CfK0%;&LF<k+IVOY^h(=HX2qI}03
zUNcfgXomXmD&;Z|L<dlZ(3Cb&()2v0&M=$gTP+00(1_N*A=|YAd6^B4_trizVAOr$
zX+X*-x^lTgpBB~Vrci5!-bErSqc;ly%0=)Di4!*GMr)v<nY((1vGMgAD7TQBI}JOv
z(Z(c1(AhoumF1v4C6v?cYvjC)wVFd=oZPkn^WTb^rjGsEd={7tO%I`p7k{I_-V577
zDTXYK*e4c`Q!TQol|#CjZn6!kHq}QT$LV(CC7?J?cdACVk-W&wy!hQ^SrYdOO4)c>
znW8YyND&Q)n==cJg(J5wUP%3sgf((X`<Zufp}#`7!i89PF$p_or$xzZ)0NOG-Z)?3
z_;~eg`21}zQ0_<b$+)JYuJ*fKH5m-J!qgm@$>3sCU-g|tQRblRy+!+_MVicA=hrTF
z)dtAX>%&aPtErg5&QV9<B*_?z)Z;owxQGfA0)2?C&$c>ob#^*Mq+>It>s2&U7%>(!
z{X&IY610el-<@eB4vEqc?r_$TC*ET$r<Yw)Lx0A?Zgd<JbfnJTzkJB^^&Bl;$({A+
zWzT1MUXW*Af@^6D1lrhj66RgYH-&g4&B}|a-E7)gq)xTd<&W->7In#r%bw^swbb^{
zU$OI1ag7JQBJNohQ!<G<q8A2b4oG6wgt4+O8krcFy)F@aV5OTG)w*@WYWTQ0Y}Lsc
z+LdyU;p^rd{7&$}m)hb@a+!|6`n4L&PNZ4pE>#748u&U3Xu$4mzs@x{+lMAsKSebX
zWvRq8@^oIp(KdslaFiKs-sy2UlS~y1vO4|igrON{IotFQ4w2)ls_h2wN=|kc|IY~&
zp-h9nv$@2POg;Zde)@d|+bs`_LOH0>cNeidJQyI>D;u*>#APs^rC4-P*Pq0}2tdTM
z3c#=lw`MG@LD(V+D>4j|UzM<|fjO8$<|ag_^i>lfqu(;OLXgs=jy3I@p_rQF-BpvA
zWabU4dQusm;@@W0v@%5J<cnnAw&ShZzg>qnm?dfTdQ`lNCxb5<j;?qtjJ+@>EhUYi
za{&zTNr&{MA?;AL5n>3!&Q{GB6%+~3!%Yp{q^(%zSwCgu&dX6JUbp^d+6|5B{?k?F
zObW%9$BQNk>^!3MVVnfb0D`WYX+^4Oa2CNEGEt1*kjVUorm^0{d|0mKfT-yP0|r=t
zfL9~joMmk_K^$G))`!D_{50&~omp2{BB$6mdgj~t#7C}b1<%3Ko1U&a!)Mosr4Jm6
z00zSv*`JAXA7GE3p2Hc|V_ud3Ro1+%pZhF+E3U0F{qEgh3)cF7cIQ3KH<Pa>AFG!o
zYcw!LxcG(MGSVVb{!!(%`?)G-j5LWbB_g_f6|}w@zWgUaV!O$I;yi6pX<un>ao%A`
zS=9qD+q&sJ<15h^<6~8PhXim`pVFRYS`tm6tIi-ZISM^^i7DWcu8TNR(IS3Zc{0>&
zX0{at{+{r!0lgb$Y)+d~)0o3r654A@-6(+1SMqt>0?S*zBZETTgk@(icS0Z|JN<on
ze)9+4EoC$W4RJ@3m<U(0W5Vu2khjT15#=vffn>700Pnim?e4GF?rD%_3+mS#JSeO+
zcvZH$(=ruU-Tuvpw-#|+?sHt;?rT``;%Jh2?tv41CVJSW^NDAT;5+gtIwK9z06Gm)
zVx<fF&4HQIWQO~x**e!ArrZneP^#Um8IpbaQ~(zY9?EW~cvB*Iu@jiux)Cpzih$PT
zSGGdUGy;vLSBeL-@J`M#RngJWXdA>^y3re;PspkhK0wUJ_5!qjbFh<!xhKlMwCT$r
zKd(<6zlmX0TDZ74-u=6B1H`xfnI8oe6<Usihq0_#)wS_$iw(AY;0~0S0ihVmP#Ki^
zb>OaD#-e<$#zc&lK5hzcp$iT~2dW`d0u6BF@~SXDC+tS4aA|2`nFokV`q&_C*$MP%
z#=_d;W_TS^)E`*y=Bb56cCWBqipj_ia4HmC1uM*2C$8{T4ZCkxWy(oG5oK~pu385%
zG04DHFK>uWWlzA!_j$LYHRksI);TUCs5B;FLc8K6wU$0Ng%Gd&jOCekT#z_^m@@*h
z;r{W@&-3wdkBeJrDqiY|9lVMrFa&<0l>BGS=c~f6&FBliaUdd<XpnirZOg*O(JBJ|
zizf8DTxt3mL3UP6E2#9-V`H8CDe;R(<^nAo&$kmtOE~)!ygu1vD(~_8!OX;fAeT4W
zK}*|t9!K*OKDMEUi^f>mywW=wY#!U6ubED{VzIXQZU{<1TAH<aRs_=_pOxy*zd;}`
zZOpRYtH6ueEN$#s)ZF;6d*)`jpn}cb)0;oObhq$3SM6itTqcl^iJ86~!7{&j-H~L_
zkx*FW@=-T@1nj19Z6a?^^7U-2Kd*e^*aOB=zZ)SLyG3RN`AzjwrnCi0-7D`O9{V&*
zOp1}Ygw+Z27k`iiS?h<LHuST#k{sL~uj#GZ?q{BFuM+QS@!xqi@)$3D?sFhr4>6a|
zDhC3AQ+=I-Z3y#cfyOeTI^<=m8c|}^jtn)VE7to7PAM|r>u?ev^)$H@Tn^4$UA?Jx
z4M;7h9DP$?gh`o>j{hZ-Q#vAL>;5cWEZ)1f;y$&-Mw;J1-3!w^tSIzXWl=}tmh~b9
zkoFC=l%`c0YiXfn3>n}Z&+tvFpR*2%b2~+5%se*Aq!YJONN*!{)$kk&lX(FiS?3vG
z8}IG2ze;i^rwrWfL0dzFWBsscn0&sx>OAv)q%UWnq>g=2!rrC1dVdT`1s>(gnWOyc
zNQ{beSMZIgsQ^2nVpzM#R5hz8DdPR~Mjh8*`FcC^O;+J(FYa*<0}NTX&CSz*EEox(
z{<M~TW@e_WtgM2VyJNck5WvWxvu$1OAX0L_(}(e$1Q=k0QJ*2-g(^qOl37x}A(c*V
z<)<Gh^uapX{M<nBL}P0+KN|U0q#&qK@5sfpmWG|3-Z{NnNP|%fo|wlM{?aJrKhUve
zFyUYMoMqTG7&VbdR-;yM&`>LRkP#RHswrprM-F<0R=$l6;x(9@FS2!!KgW}tb<ttS
zb@*VZdj`{`<3db9y|iqx@q6veYD>pfe$2IoT(8Fh_j6T2V!K1!l6EdGC%s}_e~<!8
zu?dNid##ASN6lQ-`=U>u4BBO^F$nL4?xhbKGRX5M<7@)=;g}Dh1pBOR4q=*tj{V=D
z%%xDwA6t^?iwmThnrMYh3&mh<Bw_EFbbb6qSi|<rWp=WwRXsvG{V~o(kCTIO19G<h
z^8KP&jlYWhWDeGVkEC#89mg>l`lq?aA*sb4UWa(x&B*AtKlEWWR23-2cq7B3lB$EX
zA;c!9LQznam_ax5OJ7BWTk6!@UUyKXvvLUPH%rHvh~u^~htcgQ#c4y7FfL_^ASEsG
zS}{EMM%Y|{{4N~LawRpm`lL1_g4TmQgQTjroLk{|YMR@%-RCN?CCOeO2Q2uRvHJa8
zSk4)G^IeP{r)J)xQw^I%a8Vh{t<5D8>R9U-&*#`H72ArDP~X#`sWx-z<L#xvT#j99
ze)}?or^))EJ4g!XN9_mJ(5sD$4($u=*;Oi%pVPm7zP+2eAFwhr%{o?12u2;(NpI8c
zwPm)F($h!zpk-aA9q@7LyNMlBR=8GLB1g+xqSE5KGJ%8+g75JF9iab(KFGtVw{<_{
zXjvb}K@s^G8{n&%N7Kpf?w{8e2yHeFa5W3n=@yKYke%H$=1~M{W=Tmu5r5**H{aIQ
zrY8I%__FtNBW+Ix>igYjCcmq1i<yw`o5nEQ`sI)It!UlkY1f5NdKvFOu0tZRX5r0i
z*z>y4Q%<?`Mpn1y#}z?(m%o~Ql=2)&Q1`%_3l{<&`aFE>EomgyPrark>L8kO91)Zn
z76Dj_QY$&6z0uv=&b)+?^Pc<{btk{?P6#6%#<x-)E(IK9$1E+>g$5j-xLC9sclx#Y
zwJv<f&82k;2zbtd9n{K^-*vKa`#o}b-&n`d(v!Q~WA*DPcfiK?zC`^i8Rc?H32CAE
zL$mi-qlI;H12Y>C?)@QbhjrHJQ(S^3e4ZgTmbEhbYZYyqQE|i?@j~1^A{!bklf%h3
zekf($exReSLR#J7KJ_MX4y|*x(02;P$^XK)L~<#<uKjt^7P;CxDz1kH>gA`s9IC}_
zZf<OBmgxMb&%Q89oYnM`<#YV>(?a|xe61_Do%wb+C=*~wx7s1PM-2pCpB#8KMPVZ}
z(h291R5!PK(DA2mt=Xkg@J#-M^1`%AUEAR3`Is(<AiaUaDhaYFIL|%jSLA<Gs#oa~
zy*Gal*k=-yMboMv{6t(yd>^IIzleqmaM@#Lj`{@@;RL%i$d*rgHB{$-^;J^2{D~&U
z>$Im%jUpe`@3<vB|L}i&zZD=70HDOv@rRtxDt$Td?av&-Z@}&Z1WaUt)kUmoR?E#i
zYwCX;aT8{&j~)zmFoc|)zbjYG4sO+FTYHQb4N3yf)Bzmy*j|{p_9@voqvtNH5`!?H
zu(s_?r3>Pdgo+=N9z~Fy_dk*1gs$_6_`r=xaT_bpIGq3x^Xhz>;C4~au!Kue0ZP5O
z{tLm=O55g0^NDwel?nI@ruA1%H}drd+|1CFNZ<gw-_jws`qMb=)Q;BGo{dAdCV8?n
zA%@SN!toEmos86l_XRhWk}6}vswIj`4uXN+-xsQpZQ$B4j|)-1tK(17!gxo3A#+OF
z@6PPv+JXA@FD7dT!ot0vjef%U*~g9mUMJkqPbvk|9Y>+Dds%CVG5S@YFTT%?{^FIm
zUO~LXLPVf{ILf8x{qf4!X|(>pmzby2^drL$4H&*{wOkDnm=v01QbY2-#?3J~7?}+=
zk2pN4dH6OF77)n_OPAAwWP!JXOSojJiYzeZ4C=!9lCA4d6!j<avy)ZB8)gyk2lw1H
zi-FJTfN7B?3?d8Z;!_@4UtMS;#l#m2*CvUTd2#7hH}tsbMDk4!#1C&hndKjSdKKf4
z%4iEUh`8RcGIFt3vvhIx^;DdgNmV_X18vb1bDRE#n1T+SWH>r<Ku6c#2iIk)J<40+
zp?@vx=5~RR7qVqc@u_Hp!sNK^`!umK_Hd@}Qm?8ge#D&y!@o;W=u7}cb-Cy#vs{lH
zCEd_GcZmx1uJYy8hKZ|4DAcxM<xnewx=zHpeBIWuct>*rA+A{YGbm7f;Ussc{rp(_
z7B^BiM|S`58uIr8V`=&kI!ObCNp;&7KJE5PHGLUo0vv&?*Qjd;^|UoO***)>)E&Ef
z-UzDP?oag@y2RM_=81c0r6uHg6UtxDWWRD@<}2>{$*$up_QrsbU+j^0PbEj<p%mfz
zvkMxXYiqDR6W#G-N1fQfu>NN*RD8uNuK@dL(w?khr!fyfx3*1o&!ZlhGSJi0hs<@&
z#@dya*QUc`i6^mX<7sl@+2kLc{EzP2OWl8F|FipVh=0-iC&a&#|39GA<u%^vYs7^V
z@;KQl;jv{ov9Snly%ZucdA?ZK0UwcW{X*i%J9;ge!25BIg-E-99HXj)IfG%f7$&=v
zI1W_Qeq_!tVrrFHhatiX4rixy<;1phoZa-Mdl=f-&`^Vnjok_y8y#H@QC&yy5RsYe
zhB57hJ=4(Cq|S|xjjbX+q2@QzB1nGp=ygEdFAk@kBfMLI&$jyR+6mLsj~qLm?k!y5
zfQvM$z;@l~E0ztTzV7bs-8pn!2od$48rQkT;$l9b*M+zICx{_asO(rlI-!!^*_pVq
z-^x?RtE;P{qei({W;V96@&|Kqv9WLYOUEosOzL0vXOL0d+-j*h+itoAG}Lhs;XAN$
z4+1;wSGeC&GfWWn;e9i=D<=3)TbAJk0;Sr1^taj94+-4{L`l>8q@ols^aOvTU>wdG
zJ%_}%RN;-Z)=F_Cmw~PAxAa{c`1shbgXIcX6i)s9shsrD^<m--L!CTCk&c&C&*Exu
zOe>gFR5V>nRnYr-!^Ko&_9u9(lg7FWK^z~{U4KeONP-O6rxpwLvZWA3yK;ZHrdM#8
z&HsC8YYtJ$v2X2AZ*5B(^rw8#zuChzO-(7Gd<UEs!EbR#va9|$=QUc+5PX&6_<iCv
zhvQ?=;ADgxGH9!XSvAYVbV4doK$h<ydFm>LV@*<Q{|jV)4+4AXCrwX(qoIDm6?M|F
zF^lVu|B#*qAV#5;j{QjGrvK_a#B#Jq#dQ}%lv05P)`YlGpGko(F!(!^WZR?mt|E>N
zmJ4oATC3pS4^7nwdAsoO-uCfcvX3Z&#y@-mrGQb=qzQDRu8k))&u|Ey@^a5Os$zV$
z0QtqeHMaoDslzGPa>s5W#a(%&WUuje+-QHF5?X_5-+p(Z_yZs|O*K7WmFmmL{{yZE
Bi^Ko`

literal 0
HcmV?d00001

diff --git a/doc/assistant/share_with_a_friend_walkthrough/pairing.png b/doc/assistant/share_with_a_friend_walkthrough/pairing.png
new file mode 100644
index 0000000000000000000000000000000000000000..533f4aef5e10b2450726ea35b66064f34580fca5
GIT binary patch
literal 6892
zcmZ{pWl$UqmxYI5!4g6sXz&mmf;(ie0fM_bgS*2(NFW3VF2UX1Wni!nT!IIO;4%z4
zVbJA$cYo}+Rohi9b-KFx+*4hBpS~TTrXo*(OMwdj00<O7G8zB?n)Tzc^3x}e+f$c6
z=#M)bSCGC30PyVapB2q*EF}3+#P(EBmc?Gi!z1CvdPZgL|0t1r%IbMayEr*nJ9`48
z-L1_%t*vN%>^yC0<rS3GbVHtz0ss^?3Nr7td>7%y4vxgSDfi!C&S3bCwRCNAD3d<5
zf|RtDewbW*Iar64@L=3(tP(50XLdZ+NnTO(CBJO~^0sz2JS6#u+#-(2SH3>&wJXoN
z*i^AakZ3bWlX7D-@B?*pgJMRUGqn?s8bRUkwCi8_rR{@q!&&QTEU>%eW$c0B-|X`&
z57n&ddGRdyr)cQt=$|p!%{a{-7u2VakdSRWEG(=PE;2GQz0Us>u~>0OeO?03&d!*a
zm^h80Ns2`&?E3XqLkZ+;@tv3-^NY@VEnf1pZKpv)v~V#|%(ZKHIiqZEd2a#dvLgEU
z`1l={bA~yAX9_%NfoDT+Tb!1fEeD<zNMn>`fL;)9<>l(VIQAFE%|*=my%<ijvH}Sv
zTe63XaY0UJS07MHTTD8?f1TofkM3XDEfzf=9>SOG3ylB%{qIIN4c3#8j*gBuN-0Sx
zDM6<{Nq5Jyq6RiYq@<Q^`kQ{;n8Hx}ZJv~DXX@v+*$zt-#L0lY9968p1$qm|H)~PR
z!JXw)mcm<Ym$0rtcS<R`t=kw!K6h8=cN3YTC(@&&EzT>~KWOd&xw*OPMc+*po1K;#
zCL}Txi(+1j?wtDS)R<Hq-wvPF&2M5bW1P7eid?)wt=w30=~PeLl6Qp7U_|1Ebm=w?
zgCN)dOj)VPiv_Ru61cDEk};eM%-#XkpJ}vwQ$0gSLBD(g5+{8ye)hq(>lMfS`p@mi
zNJx&!VM+GTv>!blc($nLZ426Z%Y)7_v%VBRIQ<JS+kWvvinXYV-s|NcHnmyasB6yo
z&#SAe-JD<(H8s~ieK_qa*@{K}{{EkO)(2>UsiNihQGYJ4oB#p#bCrfxhgTZ@CA%50
zc_kAquU6zG3bwKdcJ6H=uF;av(1PNB^h9Y4+|>Od0d=1%scWLt)b~GY9E{J+7qCU1
zBc0fsj;OmBH~T86;wVJLp)PyvgUUjVzR_H6Voe5+E@XP>u4$|@<Tujb(jO2YT99|u
zHy4g)TCoZ+L*(S=;k|t8?H;i9^~vw+1C9B^$)Lp|v}CZHK(5=IsRKahbl@D&d~8%H
zD4!QUuBtUnEZK3oTn}5(ZA{Xbim=S_kr~3JG}%znW9D7n4OG|D(=#$+kNks86S(f)
zrc-T%LN2+yC5jOBIo{gdwhP!L{euiWoSsxx<yyPG%AbyX_{^Y*oRf?W_PjxpIzXj-
z^BP$5H7Ec08nNcTt9U(nTO+=va`8F}hN5}?iiCX++fi_+==d~fAw>ljEOCEbc8~ZN
zm`ixpmr>#@^U7HNbPred{!cz;NtBbN8;TzQf=8<wVbhZ`nMmU@|MoEl8eDb%`LutI
z3?fDsy!?)(m2Iykd|1t2{6=$3-Bf}sErt4PhSia(?nRQyMb5)6Gujy~X_k=J=P;fh
z;vW~zXRJq3oE94+2&d-ekgEX*2yy}3b+dvP&yno%+@GSk+mlZpm)zAw3meaiP<9Dy
zKy*oX1m2c0yeShk3JA2`RZ?|C4cP-;>uT)x&)?roJ~#2-`b?^ORK|*ZGS?#G)gKG`
zDGleULIm#P0BSNjvDSB&hGV;0|Lpcg9!hQQyTO(FA`{MA=vG?!kxjm@YdMU4$;qNt
zTD|Z3t-CKl{clFGyYxyNnV00mX1O;U>GdsD`iqPNrc0A3CRQ=J&nsdd{@@Jo#@4CX
zv`*}jqEIM_94?}Wz{^=(I2<1S>@^f}<E@}D#1)Jh*&gBlzP5KYKs3Oh+Ud75CvR$e
z1EP9<uYdgQVJ#*{Wv$CM(G*&TQC)Jh9sEUXw)ON(@CM5DHzLj!L&Z_Q+3rB5-INi)
z340im_~8BQr#0NTUpp$Gv%{Y$=zKJc@uS@R#`@{Rb!W$p?+F^fkj6N5vJKR3-m6LA
zG0v1QyJM9ZYsDL_xc@Q@;CpU&6Zyn3(0ijiR*#!^c|H(rJujU4`VJ8se0z2JT=Len
z=M$!?*lFm%rr%NBz*MZktaubHf+Lxt<@bPEy^rTY-eyiGQM}KsmRD*rJD`?cb0g-M
z4e=H5_-atf`B7147mvIsp?S`{E3@n3umGjzKy$qY)*}uX9m8rWS#WnqLpd1*hgksC
z+TLu`d1sB|3mE<$?CCZ@J4~zY9guSEW26tLPlWZZ8^D_R!%P3<{>KNOT`!m5F6M!n
zz&QJNyY&WiRtZV6B7|WiXQFe7_=?f(@?ed!K<(hI2%@d`w=m~*$kf`JpL(6z+%)%+
z#Ij?(0^r5fyy<dNM?1q)9Z1Y$V+r!IdvWqX)@?29a9*Ru>1VT-?8Oi5NMmM$3xMJ<
zJ9Jb8993(PPA!n3oU%PFJ*iAN0^CqyPa;1K?#x}D$G8}JA~i5Ya(7xIjfkS8i$Md-
zRU2d*cfrvH*I+25pyi-+Cqc{h?%LPv-?G9;Z%6;V^)indSTN*uHM$;trJ-?ilSV+$
zgrvr;&IK1B+q8-7qr>H&hYnZR?l3&3x}Y;99Xl>MxTF5bUcjt<XYKd`J$rgF?7;7~
z$7ehce$drc_ON3|{7+ukgA3R3g3auPZ9!vRO9?^5ITNOhwwIQ#C&c-h8py~eXp6h%
zoc-`oQ4+(Ztudy%cO~-Xh8HTQ?u&#+kn*jx95KJP)=HY6cc`dqoho-6HWvBGgQ*L>
z`2svNM~IdB_2C@9(&ZuwJVzV6A)Iu<W#l}rNnkn7O<h6CzhYsZo|g%GXdFeJFz_f|
zM=AM;wLD{fud;?_X_kB2y;B=hf|04PVSpQjS6dB;Dp`~!%7vmzQ2rvAIKQ<30I<em
z9&Epm>aI*-N-V@AW(A6!6yHDcme&#edW+UwoIiA*Hwv?Z$2_SV>DMG+1@qTOPPM2h
z^M3ch5lZaEHM2wmve3$cN4mLb&M_ZZpq<+MKb!u)B(USr2|_AEus-@C#~VKLs7VC0
z<O67N{Aj_;d_NEx<5cfYm&B<91hYpsjsjzIpI<Kc9j#8pCkLwEY#KLZj~l3ht4iP?
zucpA`ulius-J?AgbVK_?5?F(Px9{JHgJ!Bh5<!BTMUM6zb3)dj_5n*of1+?^7UIQ4
zo-<_dE{j14WkFUd;#YgH)ia#<x?~yq(5Ea$8by_We!!>iRcLQNFSQfff$!(*FS>wj
zy^th^KbVNV-B2RORs8oETfvsO+IPr)qpHBbjeV>!iAW#?#q=_O_L=axrvi0uMdCzJ
z8}re`tCSB95{%fiIlNbs5+yvs(eDP)yY-4SN|O$rGEP_WG?jV;`x|ZxS{~Z&8YR_<
zB(w?G>!tZ5tEa_FXZd8QC%)jx&5~hdgH3;1&Uc#GFH(t&KlFT`|J=(`&;ZYvEw5Bq
zgI!(}vyYf+fMqG4k=69&MzKxH`X)^INzR@VNbtHCdF{u!d~|-kIy9b7ye<rs0fOj>
zkZwlwL@H7EC*z?)!nF%)qi&h8e}Cq`i`mRK?)kV*Z~|;(%Qcssl_-Pq#J$ST%X4Lj
zIN4xbod|fYd&>B(kZ`WzC4;f@6B@#fI<*FiR<&8Frx9M*6c{bBe+Al6GOha3s*#@j
zZD9aJOc+y}LftA-@$up%Ha`{$jii3)=N^`#$scG0XgP^dVd+mkwJ5koGKBN1=rqp;
z@z$$|zqT(O&`{V}W{%PP_UC6jCuB=)C(A}lr21AR2J{a2G@dBv?RUaA{~b)iBxqVG
zi@03FK5nmMbTImr^t>2xnSA7>?feg5Ct*OuZ>2u9t=jK3xW!Ab<Q_Aj7eorVq6XVr
zd_!TILctC$pv)8oU-U^=LAt_rSj6V?3S2of&bHO?1S=_ofoMahT9;A70O;WYV(eMf
zE7BavE*FnJNg^a52s5ncsxKF&B2v)ya0&P&sw`B+$yZg~bBJsXm!`L~MQDGC1%(pQ
zyBeK?=ou5Fn0KlifBkYefugU(7t__1^9XtA>F6{ezsUS?A`nEek`#ro6gg9%#cY1s
zSBG!p>iz<|!q)JsMlzpa9@J?icsM3y5D7!+v<jxy+3px%#-VW_7gE!0LGz*qoI<GV
zitW~iyF#^Ojn6WY)^ed7U#k6>DPEVnDu4)}dIxR-J0?bMuF8L`sI#m{Funlh%iu;?
z)c8M1inav~U%fuWZNY+s#(kWJyFA0}a0Y@Le$6kF%;9II&=LWeJi@<_Xp8dG5>qHL
zOt{tQalHsAsEb>&D;^(mQ&*=Cm3f&UhxhhMK7EC8QKfJ%uFxwzadXN(*|<ZI*u|_M
z8!+G&A1d=SA|gR^m%jY5C?$}-DqR`lZf_}H8uJ+Q0b#j%qWUVe{j=+*bX5fR#mG1u
zw(}D;gf>NVW?2p~RKp-nt>oLWTvVO|MWo!o{<nPN=%Yi53KeP$wWmTyrK$Et!W{t*
z*_s6k;p!`x@@dL<UhTDQ&cTo@DjI5K>gBE??-3W;0ab#`C7NZ&!g+IS0Hu?z4qT28
zunah;5Ou5_>i&r{F0+EMUb|EZ{Dl2?9!|qt1)0~LQrASFwY*G2pJotRYSfUOAwZ`r
zLsoM%pq17xvCp+|H&&0@ShFWvjYlgcx{;9;(O6g!17d6ad<JT~fz(uDlo$NqCVB_o
zQp)IygSTPjGh(26=!(T&y2CpW4I5&(z10LMr$KVscc0g6E_<(9aYg_9Fw7ZY?K8)o
zgI+HpliaJDytP~dO_!)ESB`2eU!|5IKP1gjEf54?(n?eF!u6ToZVCj1iB-cA8)3JV
zzj~vGGelK>Ivi$;^5o)#0U0-Ib)~33a%2%IZJoX|Op~UjLAO!M&{c_9IC>^rM*ap}
zKv>w@XKvqI#l1Q@eJsh11R3ScDe;S(OTRs@*JgOQ&yIImX;W1_odd)U7009T;NTV3
zz%PI>Axz0=JB#Zl-DW-~?m40>zK~4!8uV@fPvpIiT}PvBZE2*UAYNX&EP19QGX`w`
z#NW|=vd2m4KX(BaX+IRSNo?rn4{W3!%I+DLPB(5h{hfGJw#(#C!73t`XRKq|X(AL*
z{ziDYzQO;@ZAx($*)#6X7=ZPBw#L&rr>9|~;57(|@57f;<D;zX;Make2O%$-n)dEe
zRz!viE{E!N7(HBOCi~sTz5Z(M5QV0QV;ga{kh4LjZOU{dS+t6F-djw<^--w~bwP!x
zGB@9{W3Ni#D-1Y-G$&9>gC97i9xfyZU7zBZNQF=jtSM5Jck!;{QXi)5alGX#LO;rV
zGNI6J@08RA3BC7qdHi%dKQ5l5n=IVjco9#U-T};IA>Pa+XHEBi+0i~Ua<hC~{6!5Y
zUBgC?3rx&-&KGL2pR!7}!L|hJ$f*%oret7J<VATX=cVdC6$&e^9%P*D-YD(H?f}yM
zCfP2=*S$@d70EfC(jr%SlNL~rdB3AJ%7)>atlp4Xzc0ERPd4Bttv(q_GHW-(tSv|(
zl*sc~;SB9$IMho}1C<({k8-nrw+MFaYS86d=4VuvU<VNrrSOPQMr*9as=Kh=6_t56
zVU+X1ydl91bnk$@L=m71*a7^7U4p9K03CgNZ7Q8igRaLpiy}ym{#}A`S$$R~oG(d%
zAD&Ma0b>2}CRtLsGLcA{sswV9M_utY&7)u{n~KNG7BXB+eHJdaSmEo^Ak0=iUFue3
zH*@%JKf8GBXP4w{@dw!FYJ9>fRr2jmbRI13|Lm7IgnxOqqqZL3zfzD{GTE@<(l5(j
z4V|3gZ~uE^MAD4dFAVJJKKpqqYnl+$;5SE>QaAObzKf2OV6e2d=M<8iL?iWx89m3t
z{E3WP4Yf|$uO!|YJkB9(Vi&|{+A@BceUXG{M)f7l@_Xckg@l;LoQFB{M{QVeUk|^U
zo)z6UDVMbvK1d&x<>EE9`O)1S=V0Y$$`<4fUJ99va^I)8Nfq2<SrS7D4E~-pMYu#s
zck1c3tk%IWyRW*Br30?z6Svu%EIV^6MrWVqI**KKQ&*oCc67P$_G8C%7)g@(2(k5-
z8ycz!-1RP3LlXh3Rr?ngZ6Y~K+Y}VTwC^cxWxhSSdS-qvHfuZfE$Ch9#=pL1WG&L?
zcffU{UmnkL#=#*RpZR&OFIm5^8Gg`3q_Ss0Gpq$3ha(;#?DGtA75W#4+W5N7R)(-d
zk_Nqh>TsnwHq|rXwY0V#sr(Kc^Gzc_NB;rwl}K<J`*tvH+nmfXN9wOn4tk6H!9w{+
za?dBY)*Y&x?L3Zzy=Ob8R&qPADmv3smsi`Sb&cCgW`dIOuG?^Qy)GviAWO62cRkQ+
zW0IHxM9jiSi{RWopPL-zMF^k8Be#8qa0-+?Itx8Q_+%%#c|9o#(-ZY-2i_@G`UmLA
z(be{RaWm8Ex5+?mF9>ln6%bG76EllnQp%x^MZDwYUJeiJ>F(|}+rR$@Ezw6vAFE_H
z<>uzD{Z~KxNB!TT`9~|$ez1h4_r=a&>AobIq=WJc_`@_JVJUO`d)o<l*}X}}PZuw0
zuyZc7Q)_%-b@P7!Q)Qbs=dGvr<;~6@v#g_%6O6=PQMi}NJ!AUQmz`d4p?~(k?6)1a
zS6HkGyPx2&anc`BvqPVU<(t6xX8`VEMLYBh8U=qAapP?X+k?X)^8BrkZ@s~T`pHs7
zw`+yC2Pd9N8cyl|O_ze=GSpaG3Uy}-ngyiO0R;QjDGY@k1<-eR8>5eRYr@;-tY;S+
zG2!<ZZnQ}ienV$?tH=JcG)AM~Yrcp8Zvw{{18mMJg-lanT&3SugRh{G$0M@xVWQe4
z$pQvX?#TJutb3-xm*jkLZq&N4yUU9Uj+eP|B|+@M!Yh0e$kOc{?7i_MR+ku0B36f{
z^y-eKKCdHBS8W7yo(jH|8A5D*C02SEi&-0b)3;wPls-P)<OltP)<d}-W~<vR^F6)%
zEZ8(Co5$$eBk^TD>Tuj^ZT=vl|BIWkPyfM9mga@E%=^zbdVF$4g8$&<u}xp}ft+;j
z|G*@VkCsna@z-PesNRwX;jd7^L_hlY?76;+MkdCeA6TYlw_ZKz5PfCO{cd@gs(`tu
zT)@4ODWPG4K{@7La{IzWTWMVJiwMiLIyn!*3&Ih@V1c**PeGEkt6+5TzJ@=PI~5`O
z;+QiU{xidn>udkOqTs@oC_<ur_@9bf53M(9#^Vm|zPA3ppXcFD1mQ$|Yco~CKnxdJ
ziesiw&lW+q%=Sk}BqSp6!CU=E?`>5+o@*r)YY?M0@oyFIjW`g+Vo612+B_$pXFUG~
zZfU^fXqK}n<FfM8h|u<|WQnFU0u!HH(J4Mg9c?T`Cvky<;$=C(>kRTC{oTpJxkA5h
zWpBW5q_c?cn43m#;<y4kR8h>BXZiV$^u)xNt>dqX)|5mIbI+;nG?5M{72abAZ4|i5
zSd@Nr&t0G{xGZeF5Be}eMK@-=F_#-lNOS_d8_WARul&@G;5xm%S8f~g@~n)mXjiTV
zWUDBY9`_-z;wDisJ*pB%S8AmKOzjA_cR6_pT+DdVGsl_0BIyJLo;fSNJ1EeqS^QN8
z1quB9c4?4!UAF+%Cwcx#Tayd#SXNvDkk-NhSjT!~CxFnfqo5XCabMg^6~ZEJzbyfQ
zi2o-I{b)RA3`x_)8MU1u$VsjDln(RGy7e~qSh>Fz5ta~37i$exf~TxW#pF;3wMe!u
z3?}-cE}Z9<ZB_I*`Z~Px@*d3!u2q0Jp9U_CaPUj5t>@MVm&V6Y4=;@3x9CNx(-is7
zeu?4W&3FR?SI(#NMWC@+9m{#C#EF~!VpU8U+_Y@w2^W*VN=l6>PMRvvIi8-M-()=^
zg&PIt@|x6pOYd}9?ldaq3gd2DE!)(9`X@A)f~qQNoK#tM4IJb#2mUs}dltuHgju@H
zVM!Z|=6<)CvOZ&dvcww;Nc%L=`4o7<NFrD@D4l(G&i+25j&Mlmh$If%Y{}88b$el6
zjz#&h(m`h2|C2i>qb}3d)*T*&j!4UM?>UAAUf<H7B9C?jRr`O#vxkU(r)@kEejGsZ
zTX^Wb;U3YdbPMvom?uN*AKFeMR*sQJ!hCx#!~ht7Q&OZqe=<ZwC-Z9CPex;f8vl?#
zj6Whj60@2#o->vqaqiTeSjKYY)LjZe&m1X2rE!>YWs1)xP&qH?L%RE1ql(Bb)ys9o
z6Di_t&V>#Q677c?URrS5M><unISr+AF@uG?dZ7IhdHv_ko3-tndf=&Pn#u~ARg+D>
z7HAcfSK>UesLyq|!+^aBnZyXHt=!DZiw1CIQ1Luz&Nl}3>uFJEwxKK1^l_*)HC*H+
zP)$@iEqkcoRJpj&+R)IkW2#Eva<X6b664sO4&m+w2pwDg2@Gn_O=jY2)av3ktDGSs
zD5oqFhxM32cGJ^yvMBU6<@2Uzj8n^^_IgXCR+OwcpJtDnhZ~;QZp~x(9NV*1t&+E>
z8V5}gl%y2|b9|yGqL_U}g~xVoOFJ;N#hOqx;jS|qIlA1nWDyilpj+4?kAtJcXp;y2
z7FR1npMa!Z`YQ934hPt)*-lS{6IGsVVOt1`{5wUHY9|UNQgb=<QV-Ce{25=IH@K0f
zhX8$_&?o;jt+wVunI9itycoTwpZDIYKz-tcora|zpT~EU=P0NZWg_koA7>K(l@IkI
z!q(YbV^iKTCW-7%t0J3vxq8-Y-LxvWVT>WUBzY)VE8Y^4GN!G$u!C{lLTwsd;oRss
zc6=wH8wL+@D_s%iUVW%G?iA61uFmUe!a}sMvtos&S_6{K`TPaAbw~MkTsq0()XhI{
zcDjR}6!2`}X#Ga;zQlToKcZ(RP43b6T=<_3Ix1LudG!Ca(_pr%;A2IkwMr$t<?*)^
OKtWbTrW$DW>AwI@MwJi%

literal 0
HcmV?d00001

diff --git a/doc/assistant/share_with_a_friend_walkthrough/wormholepairing.png b/doc/assistant/share_with_a_friend_walkthrough/wormholepairing.png
new file mode 100644
index 0000000000000000000000000000000000000000..a2817da831f6398cbefe62fc5e449d7553ca0c77
GIT binary patch
literal 59760
zcmd42bx@l@xA-5RNb%AZ*HWOx-Cc_pcPZ}ffnvoSihFT)_u}sE4uRkhAjpsQm3wFI
zduP6L|N3QykUV)d*|X>D*|VQ>Hsq_E1R63vG5`QTll&s82mrus0|2mJkzil0Sd4!-
zc=`9*?u&*a0D#`}=MN^H2A$yLBBGO|tQg`3D#3eH<gsgM)|X2}=E~|$BDU7n#x_nb
zZvg-i2jg!}#zv&B=1yj$5|XlCjp&UL0RU2fq^OXx+tTr>tLNM6XT-DlRf<F6!;GKx
zwStER?~;w>VGw@_*#8Qqee+6LInWOo=>w^VP&+*#s(p1#n}oSEBunt+iFk1L1R^mN
zTR+G~_r9b(GwLa3$HDb<9D3O#zt*ISCH_tfQy7Wt2d3~6Zi1rV-&aT~pqKZ5UKY>1
z{__#iU4N`3ZAsCe$D3Ea<;GNhKhJ&7gxYPNCY;U4!oqS-=&#a9inP1Ciysjf`{nN!
z4d?}Jb6Q$jCa~ERh4}`FD&#V!|NY`<s9?_I&%{ImZKEv3ilU<Ie_vNEou8RWQZ6b{
zrXIri``cuYh%V$6!902-Sc<TJw(i@YpbM-}DlmHUx0?>@xTT$k(0_K;JgiXhA07Nb
z?fehf{w>khJh^{}m@V~>p8Q)xGUcMT|G4@8pRFHw2A%@FE+jD>js!jijlh?3klHR%
zc6c2{9H~`=r}48GjEH!zQd>vFP$KytRRX3r?zBwgMkVD5p7)l8V&I-{HhQZq?U&Wk
z1v2B*J{8XXs`GzLvvqwUZ!T?ZG#l;dhiPqhj7pAYll|~l<q&0%K*j1?;Lev-oxpD+
zBO9RKE+~$#J$7EtSvzfG)ks$1Yb%f|U(T0L&EZ-J&-u>Ix=y751+3prRCHZ3Tz*l?
z>F~+w5OBG69Zv9it3o;ei`$PmU?im#<}H<2B$oCSu9NVM32VR~o$jnF7f}`43!_y^
z*`)&nUlmKoWHj^9wJc{l+tPooMe)jSS~k)SvIG0$E=PJFzKGdHS-R%RLr-rV>9`o|
zQ%~Toa9;;jfcINDDPps1zDphi;9X`OF#l0$G`mib<y`<&Ui~WL#>KqI?p|B&I8mA*
zKCk_`3qsRQ_&W*6YH3+xf>D9B+4EFaQp<*rngzq^Gf__-)e%#Hy?F?}(au`*E*}1C
zJWnw3&2VAas&%fV3qd63w=*VBwlw*=bYCShx!>|%F#&u4Rj4U4NE86LG5EBot|Y!6
zxJVTG4_ycGw;&o!8q%Xzb9i5c;?QOJaajh)WwgZ5_}>e|;L;4hcH*{t(14T0XKm7_
zCA)+(#3;<-#sGw_$r`CUBTNVqqxbEd`2R*b<A4z)hUwF`6)2i8^1lS^+cwS$)8Bp!
z&I4pg1{SmH_rYEeN8DH&9HBDT>7kZ+5O{jHi}3;oG~kt~EF}y~E9K}8t6PdY3q(G_
z<^cB5=4Lw)^R*T_4kuP7kM#ZynzwV_8URHGf2YAUJw3melbVag^V5&tVNLzs!A-G0
z6SC<)zrn*kp|=wKq1AuRP>CLcruytMdDEB4w!*yc2uA$G6O^I@{XX4v+2kJJmmUTU
zFVkadlTw5Bkj!Op$HgZyXlgO(bX!4rIg&4NCmBybJGJSSa)ccj=``voEM4iNP=UMP
zCF_xtkkhUo@`UBdPhRe-TQ#R+kPuv5$j0V)J0EnJ37{mPu}63-xVqg@w&ZYq8_zF4
zPRKmDu3usp)&KA?87hMYc&OThNE3L^^N$WLTP~SCPp?;~yUga!;g!~=PBTQLuR89X
z;bgAAfgz=#a6Ig8elFp?nfo>Nc;ApUT+7zX{j_}9aS|25z(9>P`c4MOP=30h-=Hv^
zZC3HzY67XC2H%&n^*_m!9jy<9ME%|sO5yxtC>JEfGcXHwcJ&<NMZ!XO7#l%g)B5Lx
zti2_n$;hf|?2?k6)R1+ZaeTWg|0WvvfO)}3XSDBgU!gEV{C8@QaV{s)VVURv5mv|j
zVN=#Rsg7TbahH(OCL4-@d%x|TUzXkv$?Hd;{!>rT2iFsihPATh^G7XPn<yG3CaJk%
zM56>C1LbM^!=q&lvg||8w{QCsjvQD#IuWxKGZ?xNA&M+M3zrrn!7cIJ&l1X>DJdbS
z$SiXpPw1Gbzusi-vADZxF*MqVY86qUEzKGfe@J1UnL5F3m@>-{Va(&qL+}t9O%kOg
zF+{gAh9Eb=&p%NwGTe+>D7VzEzuR!0jPIzhmR{xZUPZ;gU_|Y;S|$&l>jRLad!@km
zF)U@dWzF47%c&?up_-j9yK)K0v{^8`KAMp%{}%C&<A2hM=VmpY?R5umT1o%{Y+{J=
zd9f$E+u9H<d$aI^rMI6KnxSS_I4&f%8Bg|lZ#$;!#~YxEJ8!)9#={Q26?|pnN(ND?
z-QA_?DU}7G0$s%+j5K&*mkP#+0v<<J-?l2&9~htNTH;qG8Ros5%TN<w9!)z0N-L&9
z#S9`VFQ+rrY#&B?u!91BWGr`(Q&O4;gULZt%jbAvrST14?P=I4J$kmA`-hq1DsWU;
zkXt55Nes1)mS<T$jyRrMdQ<irx815QWX0svMmfqzYnooI_O@LQ7s5QnJU&L9Bzm{+
z1$Q(&0*Cv}Ng52b7K}L}t-LOe8l{G_D)(_v@issPy~?4Dm^#jOkNuevL^aFzgA>V?
znsXgg9l9;M7DZ;8>!-6A;y139MlsRk$LbxHv-u2WTcj^zH{e~Yh%*)SRFNwM$EfT3
z4UpkgTEeDuD!jdxZUmRee-6rh>#Z%F;kKR9Ca<PcpQ>#QxwzmUL93mcE%B9|hlEf=
zI0TYd21Fnu?QK>&;{wmi%^c61Ue*tUY`9ziXZ!nvbwl_-qRXKb4ga4@5kVeRt2hGp
zpy7Q5``%nBK2}^*oWvA5<=q-=IY6voj^(SW{VZPvs>q(6JfT8ZOBhmic1_GpBHUlf
zxR0^#;5T|eLq?W;2UHBQ=IK9x$2cgRegX9?oVe)KcsluGdY5<Y4hrYqr?hD^k0*Wi
z;_9#HysWQhhP5EQV*K&hU+Zmc5Loj#*q=RB04xSeY4d@cW(|Z}y@3oFjKB+cW%211
zp+74@$I?244_}y!8r|~wM_Ohzr1fd?eqBs3AN6Ruf(D?a!&T@<i3URXn*IZ1gm_}4
zZpsoLoOJ8-7P5^qd1^CinsNpM2O8o8pfcvmn*x%Ji-)#g!TxFtqPr!cED{|!2+$+j
zm33J1epD8F38Ix!+O&ruHzqz^wL7u?KEMGUF%~9aiqhDAUhg4sR0s?vKEA_g2uGeX
zmS%~bX5MftgKjv3GS{7}XE}{J8HtB?cN+~atQU&1!9!gxwh<}lVOKl;liGbdYirJv
z5SG~>DhWp#CHfzSy@Key%ynH`au`NgI<ZC%r|7O6Mr*lxJqT~>p=lPz8qa+PO=^Q~
zZG~MT_Y_+wyb}X7umbFODn@#UuF<b;PcS}TAMY$~#JHd*pmvA;`l_yLSoF&0_DT!T
z>~zy$er2-n8;#zPR8NkMgpAha`H_N~GG7Ej1~B+#h$~KvjjbG=N#bpy=VUc9;X~|0
z$xewbXr{i<X1exsPSPU%yLmi)3sxp2EIYhCaNV>1T+uxNp);a&>uk@Ilpaj!vq4XE
z+!&Y&ev5yGI7;|81i?`QiG9roI6-AHH0kqbX$c4tc>0=%$mbMq+ebn|zwUP5tVxz~
zZKU(4u0=4g17PJq&tc4#vIa4zG%sthbFk;d|N54K%ZMua2484~KUPl>rgM6-Q?12~
zlXaT_LqtS`o@9}TfQW^7;-_hU!Tz#4B6NX9SXj6N@$Fk8zAFXgo!tC=6()z&3DR}o
zc<bk~xCzb2DQcYr6?NndkD{Y{OY!gfl99;q62s7jry%<}ULxy%&cKc)MF<AO+v4!|
zk_GY@;gY?pK&X29+ZMa-L&CMv%Nmj>V4;5$g<<!B!D{7)`<cwwexFhr$>HZ$lt7A!
zuV%sZnyiRf`pOZRhJpCgkoVa5uz_s}4qD3Z^R&atv3iKJzoBBTbcvbl;ycp83y;<v
zm_;B(q3fiLXl+_hC~2C?(A-FuIBCS|BV--<pd0Sfv)&MrXbeN=WlEd+pD6wg@V*L2
z3j6WBcwz<*PFxQ5YV(!)os*CIqgaaHvNf5#>Wv&==o0Ofl5Udmy$fuc)#y*K6bcLT
z)-OW?1DGFy0f0*V&3Ove-QQim!yA(pZ~@t5+4<J7cSoA5bN9VVYw!RYiW{}yvSm9O
zpeevO@V=qcI$ZFNwLToxP3oC+WT?F+?HT?h#PvyeMMkoH4g15@4H|580w!YiX8dAN
z)xPX{B;f%e7BwtW71QJ-lm5HxY@OP$-@k=LNhvA0xnFE7*c_*bg%$<y>rC$eXPtf(
zhLVY{19a1?da{nL1IX>s@z2lg`t|c*n$`Yqq}icW)IIcGaCfu>v*e1njQeqQ$&b2<
z?iKEnAZL!93`3zL)R7<yM^R-ddmX}Isk9Wgt2Uk)F5O{xgg3D!1aXukBg+Ojo}8`K
zra1)GprYMy7+WHv@BoT0R-T1BcqdrClpkwT1OxfCFxt<HY;<Y47OUwXZlq}njVAAk
z;xKIBPujt6XyVWxT!Q~Gbst=5uF+SaeoP%nNr_jZN1p@`_%&(Q5-Y98?sY=KBlNU_
zC)Ra|FE*t82Fi6i8V(Ma3&;GT-Y~m9T%Dw<4YxYU8^|;hlYgXrhw8|m*XV~M^7}Wa
z`Qyh<|2jL~810cTyYtg6lfmR_Hq%T}Kv4lC%s8m4-(TK`61={|P;P?D=ghC(0^WD{
zuE#2!UI`DX`6`hO!p*FtxC={6?066wu0J;HcJ^{BMsm5%hr0_}6B*SwQwz`%I99)y
zs~d9p=h*T`*Ns*Z9~>O8c%DS~lZ->ztNP0^2+NX66`4{RobY)o-qNS@rOjdcrLmcx
z9q*+5yag*IWCmCA8yiRFeqahg!Mz(Q0SctRFcO+hRTLuJeR^M?Q5-7+$j)|Uu&+w!
zs&F&|#S3Kfbl7Nu0>e3Phu1`2zwCv}oYa_UQFu5``vq3+ZNZ73{o8EbSA^diT;GQk
zwUi$pSXE7HcfC^!#iKStA$&)KUEAoL3Fe@=%ey+TR#HokTyW|e3YYwZtz-;CZZf*o
z;J`gf^mmGIsDdu!qD#mUn-fG}Xj56v$UD%_5u?(_nj-KMjwbj$-F8aIbviV(5Zu{}
zuE#eV$fC9UOP;+vt52eVe$Gs-QG4aTf`5nu3{@aLQSdbn-34>U$MN<LJ)5mofpx4=
zNZ&z417rz!Kp0h<B1Wa8SPXc7pGtds(+U_Q6tpS5cT3K87PJ_ow50_hvIj@DmuJ<^
zP?rqu)QpeV31RqM(wkRqms<1Oj|Qkm2<{)>=|=P!*0jjL&;n;{)f${T9<k%zzD<vJ
zMO1+`w4}MbI7dSx#$7D$eLOM`j6W5qH&KJk2t*MLj+$^vhavi9X5exSiPgyyzs?$5
zcl_%nnsCAw4lJ)jLqngYbSTdU-s_Kl$SrDk4Qr<)$c}-17Tc8$kMi-dk-Rg^zhbSI
zl!;gB)$Q;`wky~8dp2rOr`WE=2{!&wo!y_vA0~9rhwl?>&3stV9M~$2HmLmh{Anay
zThF_&3vRxx+iDma$i=cX=D_&0hkD?AG)DQd3qvY{uGN=I3BdF<cr)*=91PI!$_i=?
zC~N8e&O|98h>T&0pmQ|eOm|StZLtxE;Es>vgN7oHE|tGIt3!9R?u2%7a9x4SSpn;_
z7FvHV@cFO*f%_ak)X|~%j57(q&w2`R<cDrI)!g*rU=Rvif{QQ|BL772!e54|ow=zN
z9A@*32bWEq@pz*zk5K!F4dU&1Ha8MG2xUH*jI>Jdvc@Wk{=Hu_occPU1gqyxVAuWW
zLWD~C6F6x|>SF@(AukOzH+p(aR!|FGUhrRx@ip&><EuI~obK&|hw=z`nWM)K3s71T
zXZ__s1j7~hJCon?9~kB2wNAl5u*JZ7#kn(xmg4W8`DI@l{4c=qZ)Wjt!0|sA&cBI=
za6I=vz{<bz$p1s@JBEz}T8*iVY!C?4VHf1deCuXrBkcIr;IleVkn;SBNIKDoQu}Bk
z#}p-@{>7())tfn4$jZ;b-l+WO26*a0dvy0lZ-LK{C;1soyq0l^iS_n%Rcqm+aX?ub
zwo2Ea3d4!I>&`g101oJMZ+^EmwW6IlQ8|}Zt;u@R{z5q(v^YGwTk3409>h}P&n`i`
zML6S#H=t?mnA)PEitmgNfrcLsrW)$%tZt$%ndG<5s|=G8a(<Uac#~c14Ynky6Z<&b
zzsDCYD-h+KDw!-7r&J3%S~!Wvc*R+pALY-xq3blOd=fIrbERSsvMPx8>9c5Ad==F5
zRo(sf+15rIXxS1FKNz188Ju1jIVS>q3=kXFV}h%-as8Oa1KEV{?NQ0(UaCo`mk~Y)
zGXWn@7Q-}H9rs#%9W}JGgbe7_YP=4y81Q8(dncKia*zMY@!3%t>28_&`XgHGGGchz
zbBws4l*2gz!G2rulhsZs2APrX_$%Cjhc50}KJPVkVi_<6w<jttLFL#+T-G=Jwb4$+
zF*J~y;Ez_6EJ(X3En+6XF4`3)6DAM_N1cJ04Clf56Y+!%N^#A`lJ6x9fb4Aw??B7k
za(WT#M6OUA;v9apU|Y2E##=IF!8!C&#7@>#<U<6I%TJ6k7;XK>qZIt!PAa{U&lk!t
z#c=@AQ<!`khHIR`CExKFxiDo%e8wph*S9op)U5^Z2&l`_xT{b>CD8#sv)CLTl=nNE
z{7Rn7t0$9wf>2iDh`Oj?m<Rj;kJTgU=<rA!ou<Aq{+F;v=!~+)G7e67Jbt<2F}}E<
z#1XZZhS#O53LkLmZ!qJ+pVuO_0}WS5uIAR{I&`rJ)Xu(wb+jB2Fv*lf-gQ!U4qPKB
zyzlgl7g9ot@g4bndv593D#`Tod2fsn!kK-3{yMn|tbJCyk7wOa4<w{DCFhc5t65KF
zy9pmdh`@LiQiMwRN)_Ij(B~e{(qfJA920?5)h7y(bHG0Z7k<=2ABAd-vcQYHCVFyk
z;>)<yZvCKFlQ0pYT{I$G=+dhpQVfJ0<sWaR_Nbi!^m}f_d?<ofj_PSk-u)qZA}!w?
zE#{vH7U?l9{kV5fQ@K?(Srnl=t0Yfm`^UTnAQ`|q{nE)vuZC(uTG(|p#3iM+RI590
z%|xpGs>c{3d+%lg#&}a{&ZiE}r?~c#06U{KD|+xa2u-2j-NL{~T7N5d!<ts`!Pfe^
z9xo(FCt4$MRqkmgFRx7;Lcs3$#z$%WL`t^E<GZ=q<7%?#r^Y(d#Z9kdu7C`7)!nxH
zrK_Z71i(zP{j-+mv5~BMo`1!DghHJ7l2dxIS6+-+fHGXbZ-SOYV*cn<wVf@qL>7y*
zhIx^&E_J-H&H0Fs&kA=9IW(71gm8>rUeP&;HcQr(W@jiO<6hV0PMRN6l%mdc3#Cg%
z^))r9BGBXKWOeM5XY-RgqVU@}9u6Te^~~1K_wJc!DbMEP_s<75yp$C8Tgzh0tGxQE
z8um<e<XZ7ewAHo4C?tN4vBX&LRP)D=Cr*3mF38CT+Zk;4WxEOGPl|YsbkX=aeNm(#
z1899&nL%`p{20Wnxscn}&D}27HY|>g*85WZ-cb_e;a#Fst6!EAhkG_pbj)T#aH_|R
zkajJSqarN6U}#xl=y=s%evL^bqMiAjN7z(G#9`k!DWzl3iYG8`+enkj)4j6&qaM2b
z1FnDilFe8;lT(#I{mO@mB-9g>EIzG_0&UYUtWZd>(R<jLeY<bP#qPSGA4bnWJ5Pj!
zrIbvZ<9pu3l)6vI-zOX=;1=wx)0dLOA;bSeA<o`@o2P%=jyd^pqKn$>nADY>88v0T
zGeM?Rak_nm*2qa4?^GjXg}sVFPb(-TTtJ?hb0-|QGHyFE6PC))Y2PP2X3WRRG+=rR
zy!yr^ykwB~9pZ_*Q85rUr%p71N|$u&-M)4)WO2OUyakGlT3=ftNqY}^PGnd0_lL&9
zn%WXG4r?fov+H^oc^ecorIHtL8yOX?C$m^PZ>&Z7XTGYm?d~TicgC-=^Nk~KFdvUE
zo<4mghHiPrAZ=WLjz~>QncvgwdO}3-)~k=Y^1xw)F&N-@JESt75tVcI%-nu;U7Xi}
zvYPKjys}u{sJ)UHo5ROue^sMWBFBTC4lS=}S)6RM55jK08@$)2S$~=;i&l4Xhk|zd
zSD|uR#0Q_{B`Z9gN0({J+Am3NVykeuWl8pbItm?ba@h^B0uns-+3;yEwgTV?Qon?W
zI$lX$3F{b8z)r{FQkSK21GVP1<K1a+<d<ixqtd;{(P-H9PI<iKNGcG{S&8GYyxx>_
zJ$Vh1*;?VT_aAy>oZa||q0n(Sds}3SqR$$0IVO_WeYY{Jc>3<=^W$geN$H3hv!MjX
zNCK`7mPB;bKtylWDKiFe^JG<&c#pRaAlv7CDpAf<K)<q>)FmeFaks!&5L+BYGNj2q
z_FK^$o>Zu_Di{Cx`<mDNz)tIo_{Y9froQItCYBMt{JcxcZ6)4WwgP$d2cztpnCH>V
zRb56*yRg5;<%<Gk&?V^LcCZ$_A1$6&Yd_Zo`;yw<u9W#kAYwb82_KWwkSDk{x|bZ6
zy`P?+F_H0DV|>KqZ!{lWq5+d=Hx3L6-5idwfG(x|5l}feQB#&Xv1MAZ?4`zq`}*QV
z$E9{uJ@ia(beMrwDm_x`mXjJ4wr=iQd3mPIZS!FAiV_^#)++m@dYgG#K9M4H@?11k
z5XIMYSU6|Rt$6bOR^d!fmn<qOY#;d`bv`G29&<lXZ>@4eXJwydN&s)AelQE7;I|Fl
z2o(tbB{`9LRznmo<%fgu!mCLC?4pt78`Ghl1``?77&u(!x_-xfZd}f3+pcD3q{zs2
z&{~tLjMG(Tm0{HLt(felb5p#ImBU<RVhUd>5?g?!s}3={S8q6(ly#|a78M|y+WWHo
zR>H)awJ8YRM<Gr`HyHGEblRWcnb#po^AS6w_?I&e17E{gFB2IKAQ)YpWe(c%n23W8
z98^d3W&Wh$=5SD9hU?NT7D_oaW#s6z&mnsh5D3IU&W@}gD)!aa$qkaC$w%+(LE5L;
z*41fo5bN0RqEhCYlOri-oSD2gRP^u%?C5xmg*k2c*brMyZs*j0zxxgevB+-jQAe+l
z9<eD|oPEO-X;ZFWDk@KK7|ymx)ED{U#!|zD{6db_hGQ&m50ozTC{&_Oj_zuyQ1rk2
z=q=GmfW93f2ItUJkFJ#JUMJcEIE%nZ{A`Cemb}k&N#9N==!BSi>>7Jl`1)K4xa+(a
z9@kc?3Mxu<dX`MNH5oBiOBbk!mzxcZUwWdTL+^FV%2h}Wd+&K8lZ8iG-;nB6tF?+s
zx*A1E{99P%X-?#|{D{`0RUvF=XYwOuI)u#yUdEANVI@TE!x*J0S%~}88Lt&@gX~EO
zb>%qK+sF4lL;aRp#F_q~kw=uZN`R>QTmJTGu#}a!z)LRC+&})ltZ@Y+<5v7#veO#7
zfZ5V-JdBIM7W9YHmLI6=#THs`XvsHJzXhabJ9m5j#9}DbSt&buirM>?GeGwVJ~~<B
zYbiE4kNd$`y5j-XhK=3zL}g`(8b;KE06#bP)18D#fhc0XgkD{pT7qL_wy*A}waMIQ
zYZ|`2vf63$yo9w?a`IgOwY^#JNvJLXLR+(2Pc8-T=SAcYu?E{+W3|_&2|8g0aZVLR
z_{v<aF~Qjyxzn-9F`rfm4>YYU7!IVHoh%_i%XJO?BOdHd(P39#&3k8HqTwn!CT#nf
z!21|F-u9!=?+Jkwjk6?iQv|OtPma_fJ4oII=@g)$t*Hmk9FgC%N{0)sV?#{>s2EUo
z)|K_Dam+dQMo|uSuI6weA*>h<4g@dCa^TC7mF<d@@&WC`s?+n&Dum{ip>336k}?`2
zFxS|RKT1!I{S)VuWh8XeuBQ?L??3ph(BZCnt0KCbbAJ6*PD@WmOB>DanL?=ihKO*)
z;`!UrzJ7w%R}(3L6gMPOlRccG9vB@bzTFQJb`m)iD3B>ZCCasBj<^Wx;z5ls1{pu~
z8UJWDC{qzK2X|Jf^y8Mx>@)?gT<VhNJvH@jB=fNN=3gQ{^J(#@!#|dpR>622*#=!S
z%c1x5xHlGh5){K#4~s$lg>1jNoJYCD4Tc@s0#HejKKM|p11iP2^!1?CI_OCpx_rE}
zS7CbfKUW)_YKG_={k7EH7G_HnTyAdK(?zUPo|_Vp`;dKzq<lOwg-hPiSsG68*#v~9
zhUYoG%w!cL><<&BU{RhZIam2BslKl*Fow9((+({~dk15sNh>J#zy|c!*BUiKuFD}X
zdR0bMGk=t3&b3Ea$1pOqr`^1NEI2_U8#zeHVMhORcC~&(8opAcG8z}l1eITdb8Ehb
zjE7-e6S|)_QNcc@Ra|v?kyRDW_D^M{V#A>v5Y_xTNx_<)Ynvx;sFGp?l-ffqFr<-^
zJyi0WKHIXU;M*eH&?Ns$Sy}6;OgC2=Ioi+lH-cstXXXxHlMju<OHyG{KoV~;zFEV8
z8(Y>5tcFzxZu9D+$p2Lfz-cl}un-=?A#Jc^OC5oAncIW%qicn|iGihljWFAL#a`T1
z7Rmhf-lL-_WmCiZ1W)fq2(d3h?ECk-UC*b8{)fJnD!5V149Aef?@U&d5)2ID<s(wO
z*)0{HhvY(7JkiM;MPO{3y!UTzy1uCr{ub`8=<Deb)k8zUu<ZJ-)5?d-(x9aPy`sj2
z@ri4|$*~)0cB!q;|2!PZvp>UM+Kc9Nb7M5J@-y-KVFl(r&4ixs6LM8StKtU)04j~Y
z*{!Fzzu1&HQx#V}#P4a1k1nZTsb)z)z%qX}C{z>#5R9)e-Yw9sz=5{j&JD>!iX6sP
zj}Uy9U*nKkoQ5`(6D2O+EiGwD?M1s927DH(ju^kS(PSa(Cf6T7M-2(Db90guUvolr
zurzJ|P;iscOv_VMzGUsN3KVcaE48FD<)nwotwKM@j-?|@<OS?Vp)qXPbh*Wid6$eZ
zLShqCPa)V*ZO6A^m?gF2FCyjhVW#kUYO)um%tm1`ak>MUkd43h#V;YKzBl@a`&c1&
zNw82FqGq5(S)dTwgCbgE!mAYW9`mAzlsvaAP098a|8(QG`dxhbs$W%9=x!5`{aNu8
zI&+d-LxIC+G*w<kfW46DfG($YLnuw>e8X~O9JYia=}O2Y@DN}R5cXRt8;DQdH5&CQ
zqQIH@Ji2hQZR*uzZ4Rt~ZOPKFs{P18x9oMbEQf71QCPHYtMxvMmdWulco}$gAq(Zu
zBU#=;;7+RH%Wwmi*sh_}x-B!c61b_@dum56QJJj__Za~6!AnJq=Tv0V=~b0RKjFGG
z*ZJU-y<@@x>O?hVtRfHFNZ+WJV7w2Rfk~;+^RDg49ZtdMZ`P=qrWd##EoNgVUqMw}
zoI-=`%+qoS(PKa&WXiheyUuhW1V0|MIEYgRiE+dZk6B$EPo`HXahsT^uSjAA@sY<c
zQSEjnM9_x}$cA)PELS#)l=K8~Gpi1bh(ODA_7U#7dTvi22iPVExu&afE;FQEALv+-
z3EUMG-JO^q7P;wF`|~T2)Gb%(-3P83O}lO39EaW6Dke!lN$C;@Fsy&AH<ev-ofZj~
zSi_mcYd%T>DDY68W`2J*X>pQep(-HNvtiWbf`7C1RMC;NS)gB<KJ~m1my~nH>Uk(7
zjsH)j<|}A+yEo>sWQ1U0oJjJV5Br~<=B9*4vwtmeBqA$uO)p6I!-MPv(RAE4K}ev;
zw5#u;Xca%&z-d8e)vD>EXWQFfNTB-+#`>+I2Ed4ZDYZhDq|VO2`zJ(h(S8<`J^j1+
zaUfZPfWK_b`qr0K%uQVlAjP%4wi}~Wl<dktHoKl)wd}FSk5e^c@%Zx;9f(a4ueG>%
zO;U#sV0_;74SP4n;N>uqeQ}RAE@YS(37TIk9#s88oARtYzgwT#{;-_6wmjw5^kKOG
zvK@8(IyRi_VpD=&eQ+!z-h`}h-)m`k@yJFPpCR_oX8!8SwVy651+1k(VXXxSc^hl~
zVef3FWg6C69pJeCw9dnV0(|h~Kc2kTo0>P1k-CESK@`8y)_7+kux}JOpb@FbbUmnl
zNVu1LHx@;7bODUDR#7c4^Y1;F-6lT%lwM^LUVgvKgxxfWdnMymyZ)f1&bgg7)yK=T
zRprwj5}llk>s><F1n3;<TGipsDY$l!W8ZgbQY>pWHsmu%0>ce0IV7+lYE`K6q(|3T
zh-_hqaB8`S<x@VgN)e-vz63sebZHz$I;U$YPVh(5&5vv0Rcg<LA-Lf7>WMj<u|b|+
zBL+X#d`aDJ&G67hzVxMV*na6dTbg-;!oj^W%6(!*Cy(s$DeF{rV5e-h(?q_tkAos!
z{3X6|8?Qf}E!fn&C&%<D<x$tsqTg#+PG7kcDjq;$`thbW@EL)Yn)?3eCUGQ3Q`GEn
zP!^!bHZa{8?@toMLhY2$6$9_%MvRO=#0d!A{MOy6cIvN>C9TBvH3Vs@?d_XkF-l)V
zM5j%u_3!422T2;^{LESQZVm9cmj^`?I_5azIm&_z0luqvEvr5VU#3ab;Iyz|m><{q
zgg-<f!+?#>^iOrMK20JIA_xPRSqCNsyR!HY5pPZcWcv&T-r2<kAsmnei9Lp45zxLU
zTGSE5vV?+$_32Gg&sX!+8S~T?342J1P<i3Eu@#+ReQ!xfFM)0A8%#__`->enHg(c3
zx~E$P{#@@~&?_D<wdf~}R|8pql#!&6oRV`FRB;>HKm;kVkA>O#m>>I{iD~@>$8vAA
zb_d!dc=(?WqEMHgz0Mr`m8L1>WYMNR*>fiGcdr07nc;UVCdyo@+lm8Y12E=?9&NT3
zEInr$9T?q6zsMLz^M3lsY;xZ^X@vUz!<M_9AQhL*xjybIhqAfOJ-Jq_ROb3G9?YzB
zHJ?)wTJKpG5}%M}#tO>`c{Koy*<IFX_n!(slE0G5yRa>vdB&!g&)LyH9EIZ%QhED$
zl-+=lRJL|+Z%UQ&z7Xex#yXGR{lW+z)!KTbmCaOX=O>kfOMOA@3!pVuif=ydm^fDM
za@}>+U26)VeuD=VmvgiI*jB8-@PLM|=PA6@m*j5LTU(ASh4QD&XkWly?w<v2?B(ZN
z&Iz%9Q1c5#CJ_A>bNxS6nf;sC{-0VaN{fFc%@tFg&<>&`(eL8&wM0yk<b`(b$um6M
zqxc}|xz{ZhGUcBJj&pk)UpiOW$G?yN^(nNiUx59pH*wiQPE-&8V1#Va3Wh03y~y)|
zm<KxIKkYo@H5`?M;W(V`pwOb=P_Y-rS@(pGYoGuPk8;mOUbCTOl>{Enr9t2<*R{M!
z%d}s?X#mu<a3+CfTBFjl;Duvy0+^R{qchQ2Vn_Oy&6naYfDYS%cuwrg;J?u8=;EJx
zYV9@WGTEd)@FlMdeN%gnBVxhhmvY$R^VMMPH6<n_pZJcTLn!s=Ab*lBB`h*xrm1RK
zLyd{&Xfk_h@`6@;Si2<LL`5c)2hJ?_4|9JmmC|u0P9twb_rN&+n(kl9r(WSLA?!-4
zW3YeB`UlBvY<DL4U)qimorUPrcHXTNP_jB6K0;o2Gjp=%NQtA?OL;`$n8tNif>Ho%
zH<w$udyQ76zO*#EK&E`KtnZ4rL0bVZUOxQOi!1x-!v`=^%pODlXdqV7Pvi>6VZ79X
zb(~DS;peYlRK<kpT$jD{E-!!)#D4XOOjU3oFduWHOI>)5I2@~xZYy==LI)qIp>rLE
zbtA2_4)NWFA=x`PAKrK2=_et=Z*DCCoz!F~>=VMyKRf%)oe1cBKpz2>F3|yVQT=$H
z%ssG3-x(ckf01Dc;eT9#$t-OtJAfakixF~!OX2kico99(W0?a#m8y;RWoYhfRX}>B
z&EMiWK<DwPq>fYkikNkVm$8{7cW0MbS>BSuf4TXjPQ}B2k@C>x^)`=&oR<DhQ>xWW
zN><my$Hc-wLfmN&w4d0{M(cwk_<+rAJvRtE5M@-XGU4Fe00bqWogO-o@Q6lV%>NZK
zP)n6oY>06pJ4A!IqP>7fb>oQF3fOR|SaE;4`V0nXgft}ZKM?y+Vbj~!Qb#P+ZHiOs
zsnZtDR@NJE-wr_|i1e3DDfPb%CDbjylcvu-S#;R+G`S%{8}FVCKsyD^Irk+BSVx8}
zL*ad%Q=f%9v#9Fi<@j9=`c<?5PVRP7IV`Bkpl6_?mW=SPa;344W;xerr#DxK*{<8k
z=cU!hTiK72O?O+39M~R9y<a#)KYS4}_IRp_TH|%+eXAeOmoKC7No{}(J5zGy?(XiA
zYw76cOTQ5Lrq<g}Wf<p{;=_BfmoopRX`ZX3_zdn1QS#GHE4Slp-X_9^t7kOdY=hq$
zu7TbeVH9>!2^ad55~)YEP_@nc0pVp{vpa9QDmP$Ze4=0s;pXr>u~<<@j`WHx+=>uV
zSj{fFxO`Arf!`G%MiOU|KByO2_nGLdSOl;BJ7K@<yU?$t5{;{vedk`B#nbfZ6sGU@
zK|a1Hjq8uEfF|8A)<eutveSftZV`XqJ~+moul&JSr2mzBD06Cf9XMsC|9Kz5nU_>}
zEw8*27End#3EL^O2JeZ0D?V?JX3j%_QOaiI>!HP%;38NGAi;Pc<ampkIrMW%6|ZIY
zD%;8T%R>P^*(vKTqhDIm^Q!6%JgzEF?~YmL+_QQ@BN&Ryfw>OQF-tMk*-`;k^Tuqh
z+KV3XD8yqPw3d7Y@pE)RG9N4jd*Pf{jOwgWvO{;rY1%ujUFtBrp*Ae=z3bXsx0{~B
zHzKA<)y4qNlRJ4my=sB5`CwFBcwB-N+DE#ModP^NLiVkmigiKdMM7@omU=}22hi1P
zw$92nC<gmNCrzv2FY(v!U<PnT<;;#@ep()1Z+DH6FqjmT=%b&(b>@Clk$N$Jfxw<A
z$J8|q_m4_+)i<lU5Bgnh0fZo){kc&+k58%dj1G3bn9>-%MvrdbfnPXMei?3hJnZ4U
z;uUBwOTm+4yhkA)^sMA^&XdtvsYmz7XA{a%5n6@cdVbel%FS}(9Tt^d`nkgC?7Ef7
zV(Lq3xl$ecbOKi<A_o2x@Zl90+ofX7+Qg>3ZD#WiEpOu-9*T9W(!E)ei%Xa-nL(p{
zk8FFa>v1b+qZ<>Jqcc`$zov^phhUiJRh^1BLQO-T?_yNK94MCH;=U<jCkN2yt@n$w
zy!r0ReJRHiAai9uj{i94Ag%WN??lCj9tUN<=<a%C`G|l6YUkCpP-HoLANwrnQkE|t
zgJ;!Qd_{vuIrPUC2@OBJfpCWI*NO-PIJ4+ihTtLYyU`*YsI5_pVCid6G>a8TIbi&Y
zPON3BK4S!0qDSiIyQ#N{d_Pi_{Ski#$ZNpOp#zGi#%$HyF8qWkYe?8d(-rl}SsdBz
zB0|5~S&mnCLzx|s`K(KafY)`0OwJKbOaB3&m#?Nw($5vFzv||C=g>uUsKalsW*{DU
z)7P9CYk|wt39Hi70cId{bKX5VO5-%HJXsayOS`hSZ|Y&+n!VO(ZajW8fTq{z?VI=L
zVWfH2Pgf#lq<%i)KVC@D01z&_2B$UQ`$z!GN9MdYeoykRwbr?lRTRm|6>&B@NVYdy
zY~OU#1j$W%JHBk<0reH@wGeg&*fgzYo42OTO&a?vpXK@Nu>?;erGU?fp-S=@!OdK4
zjFOuZZ$Q6T65qn8H#(gV9Gg@|_?yrv>vDU$92o#I$oPQ#5NrTLst3jCAgvJIok@kS
z7tK(~I~%`vX7%P5FF(gHO=H-u@zBL!ZV^+5l38mt_yd3fSZM!#>1(BHq@HPi8tIk`
zRCxV-8JY*Lv7hkW{VuFMk*@8-M}wSsgg?t;lN3?srPnG0MoRNx&ZxX>`16BV@33Wo
z$AJCS^#6wI0rZ!Z^T0`&oo{1D^v=Pv8yoGpor^EF=Ab$gjOH@qcDM^JNhEPS<*|0p
zD&VDPyO?FOt*E^p^Ini%qB>nqB)sTL_~w{azW>^mLA`duK?zcT4a<3-yty#*pYS_Q
z@b>12;j0Prd(MJ16e)~xU!{DQ%AeZ@fs1`9i=>()T-e?qUeHPm`eQ%b#7`4XN9x@{
zic6TvNG}Z@EkGaaU(4jq!qa3tfA(zKjh|hpI_jCFAn9nU6X2vdVC&MyC!po47O0wD
z8I4gQVy>P!9Z9a|wzKW;l80Sr*xW{&=Z?^5>>P|)uHBcKJ#_W^5X9ClzB@HvlJG?D
zlzQWCXWFvmV6P`7hava@3_!QhthtebBI3|HI7E9jUxwd5Ol84zI|me<)6c2RzcS<s
z=Oeznl%UyrtQ`J5SKig!yF0r?V1aV#>p0K-i4NUnO+Djbd6Lli45Ot_4h7p{NU6h1
z%sc+(t?DN$osa0Do!>>)2*7<X^cV;goG5^hWO#shy`fjhf*}CFA#LJOcw%;asQuVk
z<;<j~*X$*sqeR{u%oy|)zGsbIE&e@?6=BLsb@9&435v#t&dLk5gjV*Y^-vhmPmY06
za9M!B2;w@&)goryR=cY&9p^;Tzs6RJ-T|(NS!etLy4d+ar&}@o8SsGHrBLTdkdh0i
z<Gf5Ll2-JSC?JI}Bv7z07D-VL<a^qX_fsvT)cU~jv;!(Cfg--#mq~9D;`4jVW;bjW
zeZ`#9A2_fZBs;L*n<K%%dn@xp+3Lk*4tQ58Cc<47M7TLG9p1hV63NhEs`iin8sFir
z_ds4Fkh0PZ+gUhB#vtnad<`*_Z=dQIEKB}ZzM<<2!+RC6BNtr{o6RsoVR`^2QKd;K
z#1+cGP)fJ`zY=<@MGBLK*<(;Jt^|h~qv|iyZuz$eLs>?fgV`OhfD|he|N0*ogl*5A
zPsuM<)_A-B#0-`52i^kQz7Gk4gAP+r1%K)2?~J2g?exH&9b%RQ$r)0~er-!i0Ab_K
zt$fsSK4lS@@`d++4j6v$dkU92<-|=HYPI&xm+`dh>%rvmAyWeKx|WM<I|rovu4|#k
zNNqRh!_0G;7S1YgD*sXZP!@!hk<@U%_!ZvAmjx=zeOl56n?Fcz^O9k|wBpG?ODo=^
zCGd_93#@rX4ReJ%11bALfM5oBsFYv3mwkn<Cq;zvQ_a%kF}kQ@s6NI5L#yc9N<m!9
zO=*iIc=qx=8~(ODj$FB3wTqr+Q)h4~RpSldC5X!k#Zk~!02@qSCD^Xf7h;J5>gmgK
z9?EJ5O#zUl>GK>!*Y&numBJw|rvvqlb0xV<E;?BKcOrpT5@Ab)Y>jGJ<R!~EaGQ-r
zB2p-+NY!KQxehRum35l+MxqkZtDnj&b4qK?x^E%17<+T&v34xaLPZNNn~vybqdfG^
z^-%YNY~q&o#_IcXJA}sgWW7SHpumH2(S~mmC1DaWn!n>Ht*A#N29xWrZpvDZsW(Te
zEfuU{%cZ8XhMJ^T<GQ_wjxq>0Pit#Lbu_e7GHqGe)#URG*STo+pBQ<MmnZDJ`}sxG
z_cyURZekaeSqN&4uL{3entES52>n`_eD3rme+-hZ{|3{>+}i^{tshoA9H2VoKI=He
zV)iU4wic@l_t6S?Z!;?Ifa7}9tmCop$pJ+Q#>fQwT}khNTyq7vvcpT_V$E%}G}WDp
zZL6?+%{k!BvT`{y%Vn7ImJfZiEwV!ld1Fpuh|Wq<72(av$)lK>t))o1`RSI9ZY)Mt
zP1wm17EepkQE{gfg3rJw){8HXDx!0W9=OXXhgh_RPRW>}Ii}7fm$v1LiMnJyb#`8E
zi}_iRdxZYZal{N`Ww4!=qDuAJuXVn#e=;OvC1%%EwX)j@PJ+|Zkz$~h<Z-{TdI!kU
zgV=z<AD0(ILyl}LO*}+WP%lo_cIm(Fn-2|9w`=|QOj9?{qcZn>BRjN?$9NX!x?eqc
zME(Q&%PO+-Qeg>a7bDcy=?mv0HHqcJHUzU8gkSd6KCWs8_-&SkUsTtdXD?0JIIE*p
zxDwNs-;!#{-KiM(^*Me~`%_7abyp&?eu+NWn^Zi1dF;qrHv56G;fA><_s>@)5tj)T
z$1SX!@~#{{`6-K)bZy+!^9|k`SDTODR)N}I)Y>{eRSO--pmf@`(B6eogf+as)?qxJ
zZI6^nFube5h*GfZp`2bwN-LVz6vBj2?)p_<)qHeZrtp%8P;c<7g4GX-ZBAoNrU8H8
zDZjU28d9+o__1V!!(l=jgzXa$Q#~QT`GJK3*{7LN7K)@7{R?HP7sn^BtoK(Y4ya=5
zlkKSCzK4rO04XfeSxpA91-cJIB($(n-PJRx{*A=A3#ug<vWlyNG|d!5>n;KoSMWzP
znkwYU;_4uV39+F>^r=50bvjfT@BtBHatx<$X`r(1^bohM>#=&&JovMa#kHr^?_H5Z
zmAn0f$DggjO|{$G(lAZ_5<oC0vYzd--9sEw^%j6hYO;vDhgJ3Gc${_5`t!xk4!HLd
zVNE$vSy}IJ_0||y-Mmg9S%b?Sje|vI3H`8~)uL`%8y_AE$8Mh9J<X3N<SVtT4&md^
z6{W!6;2$WMb*{Zy^O3_~Pirt8h2i$9`ZuX)t8JF{)H#`fGo%Ga-kdHuJXHh*V<{E_
zB|x`$1b5~0Z6?&)89fTs+18Uxd>RJVQtf}HA~;kF8iI2Yamdw7C^9Bi=ieC@^x(O5
z?}59LnpQ)X3e>(KPc=DQ+!(wYdI+bf3oAxu#*#TU5DDL{L=Y}#PeMQl#~&OZ1f&Ug
zG=qkyQm!hZtk;Xd$7cgUFay3zZAVX<kb+QkAOj;aAi&&QMNQzn&G(M|97yr)o^{W(
z+~(w^f{y~qR!Z+t=uKN$q^4f$bGqJovJxciNl31q{|(@#2Rrlw?wrNIhHi7t)E9zL
zD<?gbj7;1-Zpa&w8ij$jm94-etlSgpvasVkSDZ>!BAQpU4_i`u*(yF8<_wU7C&tcq
z*eYsenQy;e9+is;1Qpm`-Wz^jYE6u>3p4TlqoVcoXM(){mF1V{faa~$SF%;MM2PTc
zjQ6s==F1)ZA2h3R5FP9L-&S~Cj{<$MZFvG+;VP&jqlOiruOg-&_wN1|Fkk<RV9?l<
z-Q(t9Y~eEz3k&VZ$B^y}^GYSldAWcPf!E0=;Q@JZ4q2isX!vZ6(4Taw$-s)p6o}-u
zt8)G;{ZbtVM4Y~%isNJKa4%)r@zt6;9L6&Dt@*`R6kKNW`8hO{V`(nL0vcdsUII6i
z35_6|)vzTh^Ln>F4?K!|?B~}z6}wVv1(~#!&Rre!1G66YKI(Zhb<20D^W;5OQ87tu
zF81cq2M%(Lv^wl<-9+`#J_^|^o^2hqx3h1K(?{N4tX@t18bo=j{AQ;E$LIhpXOP1M
z3Vfeh8`m;l-<{mDY`G{7D6)Mp=w?22X?y2#SRBhUx->SEEZ+gF2_EOS`yk<HGb%=a
zkoVzT0{iyW8Vx!go5gs3O)C<BIQx;Ci_PBa3lx1VO~+JLQdltqG}wzs=kt1ek&m?s
z7)CH<6zxp>x^_gTa;Ly`|6P&e+TG591rM-4L#bfI!{qQmn1BCl%Abp0qP^;y!pDus
z&O$ORvZ*@ymtdw)kt6WZr&VvY?T!IMJJ;^}VVog){JgCjI)00ja>q@x?Of`aS;t*N
zrClFaUWB_#k0FfLTe1?bkX>O?mZ$FHh=eik;v<J;dA%pF{He8ht9A@{8hYM;KjTFN
zfg=Z&(<0YoIx<V_&`Ojg-5XUpS-G3EUmEr|KV%qb#m8G7=`(p;HzM-D`jny=H8Y@w
zc;3cfs8-jQ=4l{-+%s<y%<{YH-Lz`bq2eF4gNfG0J5Po2(6adb!PQEP+iMSYyEp=n
zCqq5oywt52vCtlCeanucuNAKmVB^%OQG8?|6jc8?)4_pmd*b*;x@=DV?xfOGL9r=5
zUFTV$Bo!a4LYAn?E=OdobbD;>A~!1t_I~Y$jExiyhmBtqA!P!mwafuuQsOe3W;{Ih
zquzwa>9`!2E5((MO&*hzBMKevgC4=@c5yWS3~W|ged;CSJ(6V(P*edL*H&r`CI{DI
z4EWCDv^6@2=$p^vSt)!15pr+ucJZu1c}uD>0k!jCsg=9B<<%5NCboCxBjC$@m8L~_
ze6*uui*-6}ft^Va;L}4uT;UKRquW6=<uivqgDJ5$@UYw(dZ#rntx~L*m1b?qNj!}|
zB^vFKYV4CpY&VqtbTSyRY#XLtTddy;{p<w`i&LHo?UmoQ(c?{w0V3j~8Jbp@os!J)
zjpW7EOzQqQwY7vQZgsU-_v_cM4vz{A*eSQw#9wAbKBC0$VV4Fsy5^wznnl5{*xsS~
z?KF=08)FW@2%=&TAhe6~gU#%U07hofIlg{EKy>ud6Hq3{nj1MOss7f^;JHPmV07ym
z#Vms1+y92~ojPoZ$3?obM8Mx!;8%9CVLS%Db>Uj)$JCqgdu#{9x?s?yo||nW;G+m;
zinhEWRq^LVd!a1$oH@d#c(v<Z+3P?0d?jgRX9X!fe1V+E)8Zt*A|{*&pz(s{NoE_G
z@IeQB`p_l;=J-1n`okXt^PgKJ#Dhcwg56&3l8n^iO<E!&o9w*@rRdWJHNnQZT`6`h
z2;hs7stF=sz}Urg1zF!SS1Y4cvjHZA@}cT>+Y&>f+A459Z2sjJ9#IR7Nb_O&qN2<g
zLZUu|=&1C?3Usi7KM422CAG?>pXgv*-OK={=-{S6*$l4J_}l|g@y)9ak_MnAhgVe^
zlF{qNK@lKcSQIK)9qv470rQZQz_uR0v9M(YwVm0`+}jVe@iS>+5MZI|Y)^l51<Vlg
zHw=Z!6e-t-NVSzss@BF)$=mRdh4co6888SuZ|=gU)?eRLJ@wa>?0Ed-J<4*|rz*7g
z<;{0>15-1rC2(?_o8^C&={t@?L$79<EBAdramAu)I?Hsf<C@m^Pf2&vczknsEG(-t
z+35PF|9p9G;xIRV!?ABd!lAcqi+!x{*uQE46yew7*WKOsDT_soY6-YD+hUaSpZz~d
z<b7{4Qo)YWh6!J>e2Clr{O26}z@x<e%h7nW^p>P*yK@ZG{%T^dIIn<-i!H??F6K*q
z;zBK_MDK5+0_o0F8FclA`ejY}V~-#Hb^iZ<){g%_WFr23wEq9pI$E<D+Q<M?JRO*5
zXR`r|O21g;RFz(H8C=9duu>ir1!ssprUyJ-Zdf}*LdAV}*x3_P^CmAl+MgXZX1+^O
z+pmvt(+r}1o=H&~(^FI}22)m~Y_4^cD6G>}Il3@U=s{Q_USvdiIrq;YsWZyp{ZO*>
ztL>e^Yff8m+X*?jggl3KQUAH!9@DQ$YcGM;=eDU;$DW_&OD$FS%9pq+BWL(lxy}^D
zWQcvW$!?lrzndIMw7<$|*R4%v)YTf}3v7Cvi6Rozba4FZXHo^T&or--Z%i)E^>S{k
zynfx3xADQ5Wl8!|lBB^kcA97>bpQ8yYlW69WDqCdrKFqIg5=$Q5m~%dBtr#nj-|7U
zPE8T)!Um!Dx1vbzqwC;~U=H4w8o=MW`S|k|Don_-&DrtxLGqSCXh`tUuG7GeM8fu9
za&c8PJ(zvuxf+-G5Pfw!UqENSPZi7&D*tPIggp<fz3sQm6?KkX(;22OnUFBEhaGoA
zcSft}vbpksCLtn>;A^Nf_rFAHK;R0K^i8|DVR&tY>Ik9#@tc6>KNJinS1<k#gb3)|
z@3YEqyv0S4ecB+K`$wH~wDU!(Qp?TyfQzsC+Zi&`g_$Dc%oqfYt%E!@T4eZ!8(N-L
z29|<}>AvDtHN8|~rFnqQe?+Fv@9kv!dLvE=1-b`~ZbT4Eva0-7?raQQIVNAGdm}dP
zs#@8lMA*OJrA>v`PSkr6940b(h6Bnsp#O$jsaw=e*;zQ|b-!JJe}PYQ(~OM=o75SA
zwgr;IC#s+p0Xa@PUOqjg`l}E_bQ^RQb}`oP7bh6rt-!k2b5-vavzC^I<X8qi`$dt$
zCO$Vo4IOXEyqG_R_k;Qxx^ZzcI~>&lNw4RfP|Aqay#u8*sA+ob3mj7@&4F3H(v-&F
z^Mdv}KTiYHhhRuS8vzRvs^YY#c9*J)S~U3;uUD4s&*A{+W`Wo;4+46&?#65`$K3YL
zgZ;L)V2rV$4RMh6y~pg-dVtL|KgNlbnl}B3^x$MhgTVb_u}T3^(3sc!{Oa++TB8Wc
z`h$^IWxVbG$K6{7#nE-`!UF^ePH?y2?!gHXECh$(79cnT_aQ+N2u^T!cef!B0t9z=
zXK;sMhBM@To>TAp)$>-JKi~Or8mhW#?e6K`w)R@ry4LPM0IE=ho^Jv43kI>UaKFT|
z_Z$BJn=#;ep-`iX7@YVj*jObZ0hK2HPas=?Ovg}<adTTNoD182j2{0U3;S3ZJ-x%b
zi``l-vKUk~QWdFsrZt-`A$%Givh#hN32ajFa{S;uR@9;DA-|{VmR8tz_A61>!iq|`
z%H@CY)K2h3nI!!G0mI?1(7;J}J<uI56WF_q%J$!wjEh<7`;@3iU3Ey}!ZiRtkza7u
z#hfC(7FS_GD{?65($_>a&1R3;ZL>+;A(Gsw%%4Pv;s|KkcWF1hlDv?-0daP~_f(2=
zX{{TRK*{SZHfYFyKwZeE(titnl{YuJw`)n^TSt;Vk*p51dOQPg!df05=i5$BnM*^k
z)=pAVmM>SxgS5~(l<^Q)=sXBIi0t3j7!i&~m*u|4#W0_>n=La2YsWHDmP}yA#Hh*m
zs4A>3r(8g5(lXiA_uD~XyDQ7{eAXlBDc??pGE*u}k3@W=+)%BZ;+02#MrTmxBXSG1
z1!U#Z>d6&;oUu3}lsM4$y`&cL4+bG(eiLNCd0Xqm1!us^%F6!A51{*CO|&yZ0?wLm
zFjA~j9hg?fpMsuD33HFE1~BCT%pZ)<!`Tie9rjl_@Ae|5WQ=TWI~WMeXzKD=r);!^
z!!Rxmwt_p=vF0Zw+C|vPiht4dUAkeOT)%i#<m+_~n+gQz>B$ukc^iB7)v0|}*^4E)
z^VFFcsMT+F?w-5D@%toyMx`lr7{@R;N+~q0{Bs?9bVdK<qhv$R@`~|#UZwjD_h{(Z
z;kxn8=M8%2g-G~Y%f3BelK!#I7?g8Sb@lvYf%{BVf+v5w;|He-V=>T70Z^?y>~r2T
zVHO?P5%?aMmCM?Qm1Oi`+S2#Ot5ha2z-=}Kn!QMeek;<ctYwcIjus`+F&6b*aRXLJ
z$Fx4gC@#>-QcgZ`x?A{LK$Ry|yW{-E3KZ2|!qofv8y;n{5kl&B``E@p!q(E<&9t13
zZh0fS_>YYX*GJp=<lnx2{W^le^q3U=IhQV2xp*~^dQ^aXH`S$*bT@UIM)NAGe?J_>
zM%cC{H}_A4TqCLO@3-jMZ(6feSBMNI(^uXx{8V4>X5e>)<TAR<0B}hNS%wgV+jM47
zm%`JR$&o~FDj)l+_Qo3Tqiw@+3Sjd;92TgU25o<0e$U`G8`zj;BYGs5vX-slZps^R
zJjbln-k#Pqt>|BN4YxOET1ErZqQAkzF{PuU6Zw+yV0Qqk`~xhbe%Puj!e6pNx!gxh
zD`2<u%oGsWj}sMn|HWEiHcot%T+gg~*yuLWzAAY@^1atDE&E#`&Q56^qKDIwXxu^%
zHg&P1NvL50EdCgB+cTeG6z(7A(@(#R3~}w@Oeftde5ulWF^FRle#7SZ9BZ}1d3&a(
zGg{&k4^T>|06b?v9C-h;o}}&+Q|xpQ$M<{)Z~1ZQkD!BU_G<ri;`BoBIMnH}Nq(lA
z5}ztyI)G{?zXV`@AGr(#E1yruuCFIufpd*er`36ieldDXL;|kap=OV%)Jzf(tY|ZM
zP0ckV3#XiuLxtMY0*qFLSDcp4F2aj(ZWiC}EbY<8S5X`^d#Zu4hfym`gm^Y;2eZ=3
z#GF?HgnI5z$z`&ygNar?5N_rmBc1X@C{y_d9HTyxpAY7m->6+|t0v$0p)nK>D}AOD
zCujBA`yEs#ZVZA(SmG7f{GgJM*nQ_Uzj7%0M#2oc^=MifHjT<h_r^%fxBGM?DvU$I
zYxlNq^_;8S$vvisg=2r>)+{V1C91Rbs45}evH^Fy#Eo2#+x=q1rH9<kofo35i<y=A
zt*^-8^5WAlrI+PHwfNY9d}00GKq5I0y8bF7oc`xn+mT-3F1k4AEd(>3+Hbpjjqm*o
z9}jOlMOlHx;4Lc$hxm%}Fi-XB%wY{JinD@zCU%{aH6bkA!th-<mQ~QJhHWrWEha_d
zYgClvYTd9Tsib>zh}-*@ar}K6*Za&<c)4_MdVMfjZP3&fihotyeYK;UtICrKYx?X}
zv428k7LBEiB4UH4n~LRL6{k@18o4z!#^wv|M?XJ5Q8w_0f~DX(OMxQLtIfpocS#a_
zN8yE<8AAcGbkpc{QgP2w9n=oeQtj<#;w#d0v-3=#vo9(zn&ym;D%>MT(;VS?D>;YW
zpihkt=c#8!WNz>7GF~WVMB(c-mb>lFq-Cz&&n;48f4lw=hKq-Xm(i(cWKoo^nCa`R
zt5lHawaNE|bn<DAzH@CaeD|bF+|C<13oENN;WD`NH3d|<PpXW|3IO;_DdYAK)!G;(
zOy%~Za%3Hzxs8j7bMxR*>gG<bGm_&dzVV==V{|uv>qI)nKvO^<EhWt>fJ@nQVL|)s
z07ocDkWLgw^yvx_utn>$XZiFL@H9?xNo@+bv@I{Xdkophq$|>nGcW#p@k)$W*aM+p
z@DTXvQEu10ZsRZgl=}+Ye65mj0hoGO<8tvIRAmF1surU~djeu!*Mzw~hiJARu38G8
zx2_HF;NiuKWMuGkWSS|+li-Harzn%e0J-x&NHK|2#v0)v#-In|UjO8lR+0f|NUO{C
zAPf#3{C$)l{89Xc7!bSXBrigPgJWLQ>b)m!Z<cp^OD94T0(eP4iwWQQ3xOGkh{i%l
zd${UA8mdJw&W#yrmhttgV#Y{j@ml}#i(J}l@)sJ?NfR;BN;UwM%5pvyT*@@p?H%1o
z__7_W6~g_DfR-WHU*UT-wTGArBYaL4)d`m`^0hiDAV~}5J1XSyw22~qw!hbG{(dMM
zD3Lu&Eq*04PD_X&CxxdG#7|Hh9y4)f;89u(k_nb4|65%no1X!X%zzw{(E2_%qi!n&
zq;4xIp?q3`o|xA1(cSAX!5Q72%$N6eO#Qf5n*-0ZXbI$)C)BiQ3%K1%Sb(%SQc}#}
zbmYe;J0IQuc9UKA=gpw+*X@o9B)EbyWExuY)e^cC%si|dGdp$rhr+p=KPSt7-LmWk
zKj*@?4<#tYeG%?|h>?%`87GMLZ<QjTLEmf5>|1HEzOs^cDvZm!@fuN--M3c9e|;BR
zEApUD15#=*UR1f_##oLCr#n=2A;^V|!xyz*`R}ad6~Z>lJRwM=3~ns$G7B$fcEc}n
zhx0`3QVV$~a5G3MD|yFyP-q3W_UY*ha5eC7HJE|o70LrY|LMu=5AJ=<#AZ@TXfo(X
zW9})&`Kkv8=7MS3+LjtjB4&Mgxy(pCH4moCEoR}R&t=e`lf<CQLbE-nqGe@^*g}k?
z0>h!GI)_{Z!3h&F+`$@l@vvhu3z6~X5>(pSSDv%B<rBE!W}vWNXY?q}VjQ7gza~%Z
zANC_hJvK=Ot0P8P^O8j=dwxfjWs)d|k5WioGG<@J%0vtYj=_@-F5(j_6oQh{%P2|B
z$(PmnetpNe96J&+zO{=%5v^qTp6PD`esvQw?ttkk%+t#<L9*>#6wZrZ{w?6gL*vfI
z&-fGDv2Gm)pQ`YoM>hN>7sKX}RQ4z3z7`Lhz30(A?_<yUB6r{@zXInyTs;h*vP53$
zPMMU(M+H^4f0B1Yr%2RT$n%B*NDAHHU49k+2WUwNK+{b|5q#Ik(8G)hm;|6TZ8rNE
zoHcq<JsdT)(-UeaEs32p^#7`?Q0{QOnd+7y?dbd7w)Jzr&*Khb2h{FAu+dfA-?jop
z1K6{0E16OS<l=W{u~qi;2N|R7smbKXW-11mk1tl)rP>@ic#3dcPqq_xJV51_z3iZ1
zpt{h?hF{`IW)|fOe7=VR@WR13e;1)G|6^{(^y>^GsV5`NcH2$H8(Je7l@HrH&RK%&
z@a?Px0X|H_Jd4Ej-<t}AVYc2>tRMIB6&IE330xFWkP}P-QB@=);ydUT*c*}kd2x@!
z=PXu${Nyw5@oat?U2_ZFr1={(4c#8!GG2j5(RdRBYc2Ov+v%KoV%C2a&~xsQ@*f~{
zZ4bT5y`DFHL9!Txwd>Tw>>K8mv2|i2azA1vQ-S5+xbQd(`6=|$Z3|22jEk({m6o^m
zlUji0s}s0^PG(vr8*|y&ZX0GDlcAi!gA+JA{#gzo8}2>zs7uSwOr<2zIsnpN$dGzL
zXOhN=SU@b>S5xqmkfR`Vv~>hcNkFw@NO|ZB#0tK0mNC0Ek^K1$hk->tkNKBFj)kMv
z-d<f+yuOXXvs1*OS_j(eJ7a~`q+>X*N5i;ZM}(Z(J>=Jfa#j~~7l)Rx1v|w*K2QZY
z-~_YPC(fRD>ecjqCdG>2t~DD(#AFUoqo-|;9<(ZcZ0z_l(`uaTJ3dYOv+~7U^>$aT
zr}gl)5#fxdAGzF>Ru_^juDuNqv4Y(6b9rbcN^-WlLoE_H_j%4P08!r>?Xi(n5f#9J
z@bS|%V_9|)5^KHeUJ4LVpb*A~ap})pn)62LxqG5Fg^ETFL!&Y3UYKcu)L97G;!Xyw
zXLOxl*^*v7V5&QD#$N6c>RWD^qtn$I8#q4VLGk0=(?C!XmRxXvCInXcKgMzi?P8f+
z2dS#{g8~(kaKGUnw_8c!mg|v94jFZ@iwmue4dvRE+e`@%x7@T~sUZxtZU6WaSNl3i
zg)GpQ9e834<Fvdgt-cK|xqu*e?ZTQca4av$riDhDKJ<pa?V&$}-J~&Gjb`1B{&83Y
zkTkeE8D8@PQ!t1?i!+9zR_zYd(6|rOQ1ijTdzX=Llbfv_GDhNYwgHD<k(xtBmDRf7
z_s9LlMqgNyI7GFyIZ&^!NblBMyZNYq<#Qd!6-7dhtgi08%@`Xr&_#@BxiaJT*Tbnj
z!mX7(qq@Ij)80s2X3h&e<U7^cg@p+Inr{8oYy%dXJ*mi?YKn|o9fk_N`m;Fu$!nQ0
z{&V*kv1d4y@8q?r@p5zTbpDo+vz+->GwJpBG|*X^3Wko=4(jU}1`n23C%;(=`^O`H
z1gH7i{~(W-u{1h9rPW?`@*)c-225GmLq3iaIxuQq2%i{&gEY8?Db`4u&4(2s2fbJ1
z96uU5Go<TAKvoIXqvVU&VE2?o$;>*Jh+NxF`cMN?FC>JkBAfy}(2zl0ZE>^M*lL^U
zRP*U6234rDllo7tD(DpVi{J1L-jid=lIZlvK+JQyb;f~&v)_GO{kb(^SWxJ8gaVVJ
z|7)^_pslSac6d~P%H3`}tJ>RW#x&W4@`dgDzcfV)yf%R?XkH{zl;Q{2?nZ3KJ}?+0
z1%NIfEp<?&dli)GPHan^XJk>O*K^gs!=I&X9uZ;imcOd@kq?T^4l}{Gt#qi_TUIBw
zrbI+<+7I`Z`RpH4GqGcM{jIW<zOy30Vn!L`X13**jX%@CMtd(<(j@NTxUNb*nI1)m
z;GIE3-B4gV9`8ykWOCbXke${f3bgsW>-uU*nA(w@hrnstx;u`VPsU-GGq3dLZmBvC
z!1jESI=PK^wJ_CZiN)_BvfIyp@j73Lbl>+}C<Re!rmGRZwZRIaW7o1X>o1$eplLtX
zZXPx$S9kxwW~-_Mo1_-^>!q%;-@j5AW$N~D7)^zaf7kUra=|!4F)iT9-3lKRkxRC-
z+m6N%JPg=hhL}j8mbP`oHLzXxt=x5wu>^!&IJjme^RRj79i9#%us`l)L~CyT7W2vi
zfv(TGw-$z7UxcMwQ#aQhPd2T>;0{O|)iJ?gZGhZDYRl+QKx3J2k*mJYr>mk9n5gi<
zL!bo7T9N<hB++7H5`Ng6e8XDw349wni~ekK>)*jCI96Jcu$7DGw!qc9cCf+JnA^+m
z@r(#_Ew+%%=c<=?y1V6vrMoNXXKshJbL&Zc%VH~4&TUQ#dokpWh}G*NJ8**pzC3A$
zW`(y=x9+#tq)q<eoBYEeebxfYy6J0<2tQ1iO|+U)yzD%<ZgV8nRO843HJv(NH{M7>
zEZ=~BGtINS196QcBFv8Zx+tU@q!et+Po9v#LclB3pt+qLTc6z@iU5M`Jy&h3qW0E3
zsfu3(H<&Fp^~$jV_c=B>qP4Y;H_(lN8*E2rokKk6FY?F3jfx>Z_N&uIZRI9v3LJ`o
zw@^3DOoW$4BJK;6_}D+lE{@xgUQKb&a(I64)JK%^sf=|BDJwf)$twkc0(17D^7B8a
zGK>Dy5k$B~`N683?0uFI^aMZr+1~ZIK?UfcFRt8E@}bb-N*Nsj=XGV%5bU((GBD_M
z(>60ZUUffv`~A=j@_B7*s^^PL8$z?~$7ELJoFeI&sAk2Mz|t#fQq(UNt&41~V1czv
z+5p5o>XL#>#rJI&&WFx>0=*^`;?BKLA(NHiXKPC=9Ve?3y)K;En&<oBm(QCdU5uQB
z02Y-;*HWLV7(kBA4>PX%{1e66usYil2G7yd^baW9mou+%>?0bZfw76_H-RfIS6^nM
zR2HzM?$<kN)+NgoV7uN&9ue`3^V7dD{SHb=h^5|mi`P^Z`OBGW-=YVzzUuoW`SCA$
zQIr|0UI{V^96Sh=M9u~W59nTD0jk-=s}^DamDHrvWpp#jnB=&1?7oXT_3a*|HWt<H
z(kI87FP4E;7HLNhgkAu^Gu%Qqx5|wDmLH+dV(u0KcZP`pT9m+6cN4S8UDKNbQlVeE
z2r&c)E+ovQwFnBrYNoLOXJ~QoGs5RVf6iCV7H9YwuTJl+p8aNImVh4oX##z^NHcnn
zwP$h|t2Pe6r*fo7cKPJlwiZ*Z=X$`-Jm=B8R<>K3XXM}dZVp6m{nKuB9^-qONXufi
z6re-&E)@a5NHevVJ~c2)C2s_ja&lGwvH7;&V{KR41XeA?S6Vnit`;1WK5?*i-|LQb
z_3;%s#?@H3G6&$3tMVU*PtJy4{adTTgGu@*TD*G;bcAyalA#r0QlLsRmaqvfRCsrY
zF0~D@hB1mLq1Y;XcWoaTWMM7-0UBMbQx;xJHqRcB99L|5WfNzVHPXp>)n>?K;_70<
z@E8nt19?iaP#76~Do_B1F?*IKWlCNPlIJokxL94pmMTRUIfy{F@18Z&iS?C&e@?2z
z;(rYoVkwW3-xP0<B6K000+t@qjPS7BT!S680YFX$AZuR<0%E-_B!b4(Jx%%BsYcOo
z;4#Ex!sBEyEj^y033kwGIXIc<bZ;22TT)%)_cocL0<rqH=iThO#44<Pd!`b9sf|%i
z0@~gIYy;8jr=_JMvQ(^)UAwY%+!wT%Bx1D&ZXJDjXb;KV1FgDsOn>y`Y8ur>5&}>a
zBl=N%qtFJj0d4oOyJWNwU|7_aJy=o^Z*+Ed0jC;ZGS(Xn@Zqkt_JlSfQdUbh8-M4z
z=B{XbJfpCWOnt+B)ZUZd`}UxSwO~48ESO5#CF#x8iguQKpVz>_XC#9e1T+<jt$y*$
zAZCurKa0=x>=TM87cw^T7eF(~Gu<1$XuUFI+Ba`1_I>C1nKQXRUCMy8XMz!p(sjux
z;-8s?)^EM!`uZ*UivW}FO{1XlpVW<r`Uc{6M<$^z!i}kS(Z>?)eE#10a#@<@2Gatv
zI{3Eq4yd(bq*BRg$plxrFRT?^v_E}=ZOCPaAU_9a&x^XH1x&R(^mGUB#DkpTRlBwU
z*-3;H3MW&pXh2{!x7qpN;ze5Em?S_-XZv`bD2BVnonE=SJ9waJ>+~Hp2p163P>|x=
z^8ytS4Go8w^Jk|h5l;K7N(n{f{sqBK>wT&CbbL4_x1GiJSLsf^(FoSPY=&TSq};4D
z1#UT}BnHYla>aEo*=%5G9wCd|P-bPdcrJ$`okhP>93+|-2#^|ganjD$O~RmhRlWD)
z?xdp4wujM)i(-Ul#=5_zX+@$0qP}xPv`s0p7uv2u?SHwh)MCAvV<=uQhEZ%|#9P#C
zwQ}Ti6|LU$SxzOg_-%u9^0K*nCi<e~u6#7ZOF27)pyD!>)wp(!7ON%kBxnY@N@tLB
zbmhXm@Nbm_Z8;1{BSe==O3^NrNa35*tjCKpe+hYh$;Yh_Fpkc>JjPRkiQ=okKR71s
z_?t#%*w~5&H4?&okQLwG4Y3u=3C$OkMt8%3BA$ZJqk-Q|h>wSb!Wa;NSrL1#1C)=@
z>mMXdyAQsXaXQN0KKel%tS%2&fjNpJEvUUeP7FS7g`(*S!PNgTTdvSdlHUM;8(#J;
z=wjZhcdmIG6G;^?b}sp3l^vK7SF6=jzC={tmQmoQ980ewVW7P~{b1eTT#ZqkM`5LE
z&<=?;<^>=*H%Em0J!S*OTY6Jlimb6~Lls8Wu5w@b&M6j7%ez#eYs+rn3z9?ORs&~H
zr^9SELzfo9@N8#;)ll>Oz7RdHkdqJNJb~aw`|-G*sIFs}aJ6Ndn9RiJ9mojvhSVT}
z7K=gb<<63su3@5=p^q`FB}>|8wYg@aY<Z<X&b?HJRHAZKT!xGMV0Pp<<rzo5;>!~R
zhT4I}6}4^zuasWo8`vtj2|L*-`20na=|u=m>W%;NUeJ+JJ;}${*GZl$ez5fD2dV(?
z_$D1|@teZqjsUHps53dwRc`xAmeZV@8ORLP2s)+6aqI=Ed`r{(Z&4=-;a!WYjTCaI
zcs<hdO$(G=DR&ATPowz@_mf>}<66OuK^eheLtNptxCj)H#-K#BVT=l6QJc7ULQ)a4
z?lLFV=uxpP+qql$qjJVO3wc>tYXVw>-tvhFjcbgCSOfqdG&rG}w3>9nw#)phNLu;i
z+3VV)$Zr9RljB*E<_Ns*2_$3By0xE0c*M(<V&i1TA9%GbqEH9*-!}~iK4XdU^=5EZ
zldlPqLe9{BaFlCDksN=+fa?ApDBEYC#~{~=O{k#7wj*{cHPKw6t3om{HsUW*iX~f&
zrk&oKW&4evk`=d#)*uY=*A&+XfY+UXgd0P)<h0CWo}bbxJ7VFy0j{Bp@V3bMCvuRg
z42AB%RiK??ADtTgikk-wA3LsLxsV9Pp>TedF@hWxT*Pod^6Iy*?@$8*II4_n4+%t2
znEV0@t4Y6V<CRf$d}!LSY!zBH@U<Bx!_5=i*?bL$srM(g9D3J{^kJnEJZBRcNwptT
z^lkbZzM%3uSjX8uMwaI}6Ym+UCO7YF6Vm9*xs@rsm~J%r+r$XCh4p>_yff~Xbh(q1
z@gmTIw=@TJK?%}dC;90qxJ5dyjJ&+YB_d>Xw)T{*zK7ok)hN2%Qzc6CV*+D84`h7Z
z!@Qjw8RwdM9W~Asnt<CHtevETq=Q66*&uiqP`mPToJ-cteqJ8*_NbuMw!6GLzYG3{
zt}P|S8V;yx#>dOR){hQYzuCSd9ytjXZ@kE*953+(iYQweq5Yc+FjC?D^#xwW4jh)L
zvP6(aQ42Qxz$D_1=(9;XkO#+1;E)Mj6nHOpz2<v3E>P>4)*JWScojlvJV5@0v)F<Y
zeTk$O92<pS_E3#2g{Kyb3p5X`;4Z<>I0Ws4t34x-0)*2yeBt>A_$w^uw1fuU72x7Z
zGb4uc8}h5G_sL4Ry-1i<)K!7QY|nzB&$+KqOA^Fbzrm3rRqK-_arf&Gi$I_4UXb3-
zOMQ6q@;q^rKO`zmwW~JR`6U9fG$1?%J-;+O7~o)$7*Ye=`;{f;^r!aavyY{$1PXHf
zp*?jlQwDek5M~ucaqPthIqUv{4f8Uor()Taf307u+{~P$1=uJ+yxfu1LbwSOSVo@X
zn-t8T(}v2m`LvZTRegO2q;I%y{l4%6)vjv4&^BBx#G>8@x@nScfr~ks{r5$A!8-l6
z%(P><W-18mW3AG+Q-Ox4;uvpu@{zmo_1S}ypkGS3FiWP&x`%Tr4)!ta&@aiFv28$a
ziRU!Tw0fopyPIlwY7rZ?(1<@SXH$R9#92p~1bU=8cJ+sHkjISCWy{V4&YJxf@MC_G
zVheBXTB=zZyx@@$wVj&XD}75j*vuK6pn;YH2nCj+$t0~X8YbmejyABb7#P`EaMFn2
z84ASWW<&GRb}ZxIt%gRcmNmt|RgC{+?Xa%2JRUtERU_c>-Zr<Z)TLGtVK3n5sc$Ck
zia5gIt-Z(j0!K)1?F?OqxZLQ==yjph61ga(YKz~CAz{2e(WFV2YnQ)$-dsgqaOl<0
zO`f8)Jwj<6l1S&v?9{evEyGGnx4Swe=&AkQdHqI;`B4I1^|RgF(I6)N-a%vK<kEF*
zB82=#ZsqD&-l5)LbX4#3Jhea+XLnD7j#Zjc@~8%wk5_GF`M~XYReQPQC&L#}SyQM!
zYq+(tD+sAt91LFuulV?E7V_%qes80}o&f1(G`5#h@0Q=Xt2$PieZuRATY9tfs&{ES
z++u97mZuy^TA>7ug@GSgP{t?uSFwUH-CLeua}o_F5;`^l=l7W7t70;t&>~Ds$YYr_
zbGTZ5PN{}wcGnpwTx!$Q{nS<j4k_Q4m_;Cy>f~1{u|#+3?~`dZ-PM`sQgzmxhuCF7
z(763$$r>~j2|DO<!1tK~7&G=HE^7@bCmBfbP5y6mJM_d+bxxSMUtFHr!MEYX!Z%1z
z{GVLqqov)|RW*BNiPF_y43gB?HRYopJwJw@EvBgs8&x-<FfusjZV>10=7(*O?K15T
zn)uqT#L2jKs~-8)h{b_EfG18o10+2g1EoL%z$0*rtHjcKbLN%O(O?EitI!2O!3x(a
z@;YPvX3z-3JFuuC(JqJa<6YdAXO_QsHwDkF6EgDpZN?|ak*x-qG#WA@x~W1A`f`l4
zf;N6=LMV`yJWtx<-L9NOuB3k`J9!k9`eSb@T{c<?T8>mHVkzC>>=Y&ORKa-i48z|D
z$Cai`NZ<xr)yl*G;RVQ54>p3I<um}|rtcMMz1fal`jq5r+aD|A<1jo?U+uYL>aMdK
zxo;D@jM}KD+KAa4uo5A&vGj-ih_h^t{{EW~Y`)hZ<?j8#x<gr_qvR{9S8*x#1HTQC
z_FU$t+MGZ%c|%@zm2GPN*~4V4b(+R^mL`$1Tm2<BDj;}PrcVK8sQ_!Orm;b)I@36$
zbn&Fs^6l#eKiEol&-~)b<6#mhl#%*>a9-7R%ObF+lni}FW76KV5$NSnrxLZ&vq1t^
zxibAu)+{CmuTjfp`;Y-@H2IsfE};Y(N=SfUT86{u2r~_ud-9?Itk{l$QF2A(s4%XQ
zZl1kfSk;+s^vl4<C&(JAHNnI}H%<uP1XDLqR4e6EFq4ouJU8KS{pmSCT2P!=+5nR@
zBW2KzJ(`LiYl9@n3IUw$JoP$!eq)_!173#sP@sgD+5<eOnd>FXPD97f&R92)5(qms
z15BnpG*(kG4dBsl&$kDYvzUO`6~vW;&>!B@q0gM5{kQK4YmCk3fXSBgi-JYl|Is0&
zur02ehyn1LKt|i|5P_vgYE8#%>3-$rt<X-5=LpZyAWcW%Kw8@T7+``l;uX(wCf_Zk
z*f`I(!|Q5J!aiL7zHwd2y<VzG2C~l1jad07!1Ca<`p29}^J4fRSLvF1T;oyJ$#F3^
z?yK{4$DWb81ZzsKO-_JL$FfiEgJD!_xs*^JAE!0~pfv$tyXKg+M;|q3a+{mqLB_gn
z6NvX&nx^o|O)>#-9N?!u!`*>Sb*+l@FE<SAeeqko)awo46d(o=3Y_Hm`urM!`vtBV
zff>m}>~jJ+B}m=6DSXRm8Ks7Rddwcgah{1+n1!$=g#vS&z3X&NtiC2g6{@>#uKK6I
zhAJT>?vWdvm<?t$q2q@F=q8|uueUgfLPrAZED@1Y+AHZb_)Lx;+zpPV;6#D3*AewR
zO|N!qYL4IR=lF|y)a$-t&nZ%C&sVR3hTXJ^efUhoUUp5|5R~&=Ja~gM@}Q$kB0B0U
zZW<Z2u^b5({+$RZ=eI9{Nhjjs+i4gjuxHW_mlw&v-%n@>aBQ@e$r}n!EGM(Qy8Fj*
zpgMZ^=x)MRW*rh(3N|29PD-3qTs0ct{p*7(lg^6(ja-XQmjdGD1mpZ+%InS3ZF>CH
zZ=a$ok|7`T>8+RVtgNZQx%QN5(kO;m1V@mtab4zs3Fc+Nz)%j_wVvL@%~_x$p7FYj
z(}>>93J9b!vgG`j^NFK}2;oEh9raK?+Gz7PoMR*In=e1Y>O3TfHmdS>_vj0UNdf|*
z_gro$^?6S^oF4m^c{v`xE*ZZJX_@>*UWmB&Ke#_GQ>6RT+n-Uf*?lZwzTnD*>VZX!
zFxT%_q@NBenp6)04reCM)QBM$%!f_o&-=XGSP*i;@4wTK%Qx^<;zN7CuN+ECPfnV!
z1OpQyNsT_EJ_QHwSxO(Pe{EFD3v%3P`%K+lQ$O@~^r%R!a!PzT3ADUOk_6R(zqaHK
zwlrb)uu&rdUtj`u5V+-JRNS=2HyqON4cez)n3e)}Fr<*F{BOgHmU@(g9B!Q=m4_HM
z@2&k|kW$R)-ZpnT!nFaL9+Rl3`8)6d@_b5voUQDXx0%1z+5luEi<~g2)BeiZTe#bv
z_vXZBTp*9}%B9Jvj+C!5;C}e)&~RF&qF_kmt14f&nUNohX4v(!!r+xyF86R{z0RFT
z{}k@*XDGf=$3#n2Cp;KfSi(85g-r1(4BC8q{jQIKNGA^TaI1G<!sQ~&|JnE8>Q(lM
zt%sB^#&8M>N$!<vrLwZJYM(%gh`a5ZH@}-*HjlF;{G+i1P+C*hG#^)4Dd#MD@Q^b2
zpP@ZCA_FVQJ`>nC<m%JOzW$7oy=@@6Yk7UpKe>*G$%_P3uh09_lUnNGj;G)Brvhgg
z`jAOCxOOHaesSvV(6|Js#rm*F6NH8ptJHHswVoa2N68pOLI_i;%lCyx_EGT1hJ)Wy
z-ia(dLrEqB5AnxXAOQh{<E(~JGFd{4p889jzZ0a~mNb1u<*6-1@W%HCMys|}wQa3e
zlv0C?D|D2RTZK}*DqGInA9p<UubsfZm3J*Sw11UFIwe&K$DCiaiEjvK$8w#FPby`5
zU6BX6w@HfS1Ju!ThaBEU!ySS~@ua4%wR@|V#R_T$Bjgn{3x4UN7qapFoCcO?R>-;d
zxRc|TOapUVaIYzWkGZ5t*mnEFSQ{opV662egR(w2I2tsXoH+}#I6Y-P!d!_=#`*g0
zR=tmthE4<nHkZYdXY#}!`1;PILLS6?NB{>C=yEl2<Kb2X{P@?2rv%Q!cmkvTp8hTU
z?}h(a`hRlEc*$D};<1{zIR6hbflUMn6ypwp*S~r4ZS`Y7qmM@8O-|M(*C=oz$h^$I
zh#;1rv8)C&r-8hz@-qy~=h&E^TwTq=C}ac#+>zx%3PSE&og|!`)2T&+zkc2OzO}pC
zm;bIWGvU)l`nHv>=W5p&S%f3sOUM?<1i`wM&S3a?dBe2iC`kn~Mg1E%u|nsidsIM<
zMHlz?KjHMTukqw<*$*QvMoN41^L)J^mP9*?_JVcuLlU&`KrK0U$s`X=K|-imtb?DN
zOrKH)ZGKK&7~C64p85te)IiM!qqJ?@j=Rr~O~cVEc(nYo=t86>{)x(=nDMRwcfbxF
z1piBDP<rEjjqp#aXMBF0p$PX@{$8`1&uNEXSI5%5te=V_$9MNkG;3Nvb+bLW;H5H8
zi>+}`p9OLT7qr*`j$=GUoZ|_nMfu+?>(gH93rRU7n_ml5ws{Z5(l<mTow!Pzs7EaO
zL6XxCYkz=Uqx$ZJO?*&wgZ}j>FSV07fh)Gkw|ldo_!xIAO^I7KU2_k8brl&b0U%;B
zP#*wfTf5aB+35vLA?Qc}th%0MgU~$*+42#l>XVy<A$0uNM7Th58nPLrYJ}@7=TA01
z-|H6@o}=AhS0VzsR>UBmzyO41=SO(sJrPU>6g%2JXST>G6CK$mYv{hrT5`Y-C&*+3
zBz{s+uaM?yAT{H*Pi4`)!mcs-68OnRTZTu^z_db8krc2O&OGDS9(;fZn5h1-J6E0q
zTya||WZzEB)z41afAcC|j?c2pnD)BoXEDckSph8)f{gaL0GH55iR+eB&Sm2-+)DP1
z&SpA8nT<MGjUDJQ?mlv{!(`~R{F+fg0IB5mSHH60?E-g7z2015Ck|G|pIA|s1ePH>
zJ|<7(wYU46g<}GmR%S%`X7zX0#W_1stZtA&7PAxD;Sr+1-{zsyb;_%X#C@LERkaJ%
zRlody&KlUVvLe_hxQ;4wfr_cKo7v~y*MW8W+Etc)3{J`sdp3@Q#cHL6d>?Mx=IY#1
z4vvv%>g7S|^tt9pb_nhev)Pc<2S$7MYqkvz@{}rFU+?Je6`XA4z9*9Vl!nL#74Bo&
zx{+W8x8?K6lf46VGZJ@6F5#}_uz#v?i|n3f(MwaH?2wZLt>7lLqRwk##n57pLjl6b
z7%_2HE;fH}D}&7+eh4{Ix*6yc`9shF`~;dtODiCTl8<+B?j@mg2`hLDI%bDSD8QdG
zxv2IlwP%yzBSD2iRU~2pi#$%6Pys_hF|WQGFfq)K98ABGKH=-5vPx-ijkv*^)Sle{
z!6uk#O^HkkdxPEXe;Z%Lp{`Z2KXD{rC?@vms0eG2Xj)%D;Tv|v=X#a)4}0H(&#6HR
z+G@1aq%YPcicHS0ktEO5FaMcIeS9UJm#IGX={Fb`VRNe=taaNjenu4vC}fLpfcG;R
zP^#hk<i=~fqWyW(&~c|iOtAm$V|;q+KwUkvwg5&!7k+6{a12o1Y9?}U&<-J1_vT&G
z648Z-E#LtAgJfOZ8`J=<#DFrsV{*Q=!eJX}=Es#(ZC$;hK{bUW>dCUe^rBA6jUOiO
zm(2wj)Y`Zp-zWt{4*KdnO$mcbmtEiW%RfSo;$=jDy%-pvC@z$j)Xs|kOmx3GAJoBV
zOF}Cy=ll!lGXLM9fq<=Rx(Ia>1FJ}?LkGv(ei&C(ej~H{?xFnsL%q{jVnST*QQKRe
zSZ-g0Pcj}V9273zCwK<cO$G*7@dlqtFYousU0Iz@HN?dXOUvxsPl}Zt$)?zHCwlDh
zVl-$Lln1%&8{HsahdTkEy42`S^bEu$B>wWD@@ir>!Bcsw-mC+WzsiH@{zAB;XLhRY
z;MAjW-1hpO>?M2c8E;*}*t68m9~v_X!dHVmx^h;_1iN=tIj;>ksm?Ba4OqjKXw)Y^
z7<b&YtH`(uXtB6M0GF&Xx-`q#x=NNS%QBxeo7is)nwvEaW>POQTf3)h_pixHFB50G
zqg&CbSOEzJ<r)i4pBl7DQiCIBr~XlnQFa<9d#~IT=5wq4hZHt{Ss~{qMExNTS4?9l
zt2Bj4cy3E6{@U=bT0QbtdF;9&A{I_*3Mu9s_u2O8oo07PJpD@R{$txxJ5h?dDJS4S
zGSQl%7y&aaEv>4M6${ICp&z?K+Dtv99`0u#CmySQDcu+F@hYnJ-$!NWds^w#+0fg7
zQD#~vW0K6kiQlp%{4CjmclC;Q_vSF#*XwzV2JODHWIQQmJ*8iy8*01rh8FEzNXYb)
zUcodlHdHc3GI(iSj(&^l$SkmySvs`XJqRbh@Qe^RNFCUfA_MM8(Tmoj-!;5Bh^lAN
z#TG<F)lUcxisw{3FOLh%1;eN89(%Xlfg9!*pRnBgT%G6RpW4IJqR^(zvzTRD)a=O6
z(Hiubqt3B<r7y#q+9*dT_YIC;5a<{gKq0M8f<Kh@?N^8*joN50=DSKKQr6dFv<(E?
zTWjAdCFq|H2MUP=z8*Rl@AzU@#sO}elJm6dxSWYRyk!-;n9T7`n(_-&_4;<aU+cfS
zv#j14`PWP+#>#b<W#-^`T7S(O^yMXCd1X#&^5{$@&d81X!;IG&>P)d#04YgA`Ipzz
z(Wr`AYjiQ?LTrox$)NYhnTQN8N?JGX*xv0p97Lv}<bO!?t9_8-B1DNP7Y!IE03yC*
zMN^NlGp!1`;6I!&1LaI9(u;PYPv{(3YF+ZS9cVa~)sAF&_gt^WKXynI(HrR+=rmsr
zd~<YkT-t`W*N9jE98)bkO%<UOr6jk{Ft@WX{}lgiF_l<ha*>%a=*71<9Sk>KCs*`r
zEkz5Nvfm_9rBPG&q`LZ|Q~gm@pFI^mH2B_@B6)M$LAg{9!6wk_N($%nCsU}Q8*V{x
z7H3JwydqF9WS(X!_^DV(uWCdTvpze3`HP4GcA58mi#J0Q=N~&MUIego7w~65|1$J&
z!KJG3lheP}yBzflf2n`eSCOgOuBjb-+C8m<gz+L(f6XhNl1UcQ>3LN6HBW@fQap`=
zhv~&lZ>pEb!MLA|UjMZrrq*LPgUcf3&FfxoQ@Jng2@(qtGr}Y9xpk;jz=;~ggGt6~
zez&xGJu?Lbm}uc6CX0iPOw+PZ4bzj+Hm*ldqrZy$USI!DK#ruGl1+oYr*)#_BPipp
z*D~~HSQo|Qg^e5*_NDh;?lDvZVv}0PEcTNTZtWn!cZh<&po<wv=&;qKyV0z>#Iqfe
zELDsg=I}zB@B8p~w$|3zEjAYsJXD{6Nh=Lh2Vh#XQo>DRxcL?er@LCd7fKsGM1@y6
z*8;zC4*98?PaM^!18yAsm(#zc|Gn@(OaFD}e=hvb(*GB4VPY!5pnY-$;0M#&wCC-S
z`IV)tq7m@9@pUiQhA*foc52v)@4pL-3=O^X{@R**ztps+dwUCH6e)p4MNB<^eSq=j
zU-vUJGaUk6<|iBt>*zimMPL!%n7=<dH^Dz_FWBTQ0Nwk?Uj6!xNJ91RuffgRr%Rsf
z;Qw;^xAeak{%7gG?)=Y%|5^I~(=B^$*}`|_l~2bAHzo^%Z}?M{_TJ-37nj-!roo$V
zfn(ANT?jL;wpL@--GlDQj2}PCD=jT5D$1?rnJS1>)KK~jXKupBJ-*cJ)t^6q1SM_h
zOJ=91c?$n}RT<UQ#=5$*Ir)w?@8?YZYZp3_p#1M1b5&4Y+?<-%``_j1qnb=lzbZob
zf8wP5f84SEtG8qv)W<h|pdW1ohh>z_94fN0vGM?(-Lo0t`};;wm>swXC#X4+|E){f
za~8`8#e#x@KJOfjQRC*@tDDER4&GJZ_!bf}n!2;Q<S52*i%MiN0L}49ufpB1Cp!H@
zzHtlWV%OTgv0#XMfh8M&1Wk~)UfxS_<7gs%>XD2LMW}4FX48i%|MP)SL7|9!^lU_1
z84FBP%@Q8)fNFUQ`9g&PRgfjeB@#!`qDNOPk<V|N){tvhrwcp)G$~XLNwa+S8Xgb2
zf<oZi=VI}p3q9O#ZF89jyIlYJW-=NO8p!xGFbG^e$G2|B-#HzzJ9+RdH{FEP2(=UX
z_84?_aM_E9w+!9-!P0;Q!{NM|IHR41`<B#?3;gY~$I$yo7QW1k^UY(o$4NI|f*vQV
zPy)I&r$k|7hZ@tiBQ5(m`Kr#x3GCH$uq075l!j6Kk0d&LFt~-k%JEDfdRcXECa)eb
zE=YX!>JwC89v~qECoIXwFJbw$aXfA$2m~ow=<8}bnnn`-6r2jQ(s~(qeyM4~VE4r-
z1^Qm&^P)|w_{KfM$nDO)>@3J2R77ck=(zuo&;H>e3Hj{xQ|6W1HRDwQo6viMsBqoc
zfQIAKSuo%O35R5z0=rS?@j_#qkE_r8P800v@H2EJ@7VYF=Qs78Lh9F&XyVk}g!-7l
zCSdPH4pV}zM3f3t0-?DHQ!Od1u!Z?~Vm!*!UKD!NM#C;3*|P?WY(YOFW~JZB9x^X~
z1`M><NaM^+<Pa<8xn@Ts)$zU&o-!@2;aFr*He1B7k&5{80u8Jq)ipJ0(?`aQ-IIt4
z(0`TCzvDjhvk~WwFoDy@GoW%At|7L8{^pCt1?P87QH1xe_d?(VS2SCuuB8CY3<5_`
z&sE3F!FTisOjiyyb~^+q@blg#3t#M~xlEcc)l_uo#KUkM+64H31o#sl_?sF-pJ1*L
zvNnFq+OSoXDs<6H*kVRJ>~(z{OB-22+^~<@nbKsX^2SlZ&`9p4a-knw$;)Isd#gZN
zgzQoI4z?P>Wq1=P^yB1xt7H6NEV^vS2i0a<=e6X0sm0mDXpso@*!cS_`NuiEgm?@i
z;+&tqzpB?5Rr+8SqWNO^HWdb5ZB6P*O0b#rSN}$Tbhpz!-*6{CKv(+VGFkZS7E-Ui
zGtgGvmQ-$NWT0OejIyKJ{7GsLIU0#kUT4_2{Q&Ce`Jm25+v+J0-EmZiV{Dk6Vpuo=
z{~+`1(eN#7dUb|kXapY!kGRVG#y<Aj$B)7_ZglC}b+TVF)G$Udp~j@zn}vk>5`btU
zNhO``4m?+v5)CaBViQcsd>11*z@DA%2iS#yXNL<7!pL%JTEWk<<#ARKaQw#KX)bac
zw)YTs*6rNLfs{-k6AANd*htCe51ZrS{?VPge=}gr6vfM$b9)nnss=(Ap4;*RM<p+u
zMDBYz+it&3vfA+ldRy(JrTwv}^gd4^N4*nl*|1}|y+2FI%D?rE_Aea#QG@(LV2}uU
zI(a#o88|S?W@avrz6E}7A$LS>^5M$YZ3|zfgW%yFG%N|a9WvZp9@(V&SSKK#VHsHI
zaR1xv^=>-3i%WCm;IM(`!%e&p)t?N1n2gh+rfE%-fX;Wp82EmuVDiWL*`us4R3uc{
ztlfP&>1}!Lq-Q(U5MN1Nulp_lAt<29Z@oRq1m~8;ZS5uCjrW4<<Ze}2)QQ`Chgqzd
zNnv4C#+_}Z`VJNDv?EC06_k0m$0RC{lry=>c~HS>-Us_WEQ&qUMgaJ*4ZFh`HclWW
z`!t^3&zYf#Lv_EttIIVf0fEgLYq!4ukPz;Vss>sP$8xGCEt69bo=qQj*jaVv4)Qj;
z9jwjhozK`+af)w9uFoe|y5O2Sd92_pHbLj!S!57+tgIg=tsIIw^I933k?}9wg!=-D
zjq3AGgr8O#Yh#V3{=_`u%(lb*i^??KjaKrpk>t4684K3b{`XC8KAqDu;8N?%_L3s&
zI&j7!vES8CYHec4s~HEG&qKiA(GeHVk#^tJu#-UF$E9zSET&CDUcVM`vdFUmT?LO6
z2N(-I|K<XG(jB?udh{It=M{EM9jlbRvwFTav0rd=tiUZAYLZ~`>R>>KZS~>q%1r3k
z73;fGQ}@_-)hGq!-X4vEg(JD;wLCnvZ4K810f1i=oz;4E;Y94%Yz=REWe{wqiOyxZ
zE_zjrTLH=T_oc7IUS~QEjH?oApb_}EK8O>?cCYHc9b4veiw3Cf=9--8gYAbqbs8tz
zkVD3XAboww05+fDh`ZU`q!T6hr-IL##Gjkq39VL+2vsIuRh7ud2xMEmUA6vlJP7+}
z<!372G(rsKGauQ9ocsG9<(;|z+J5`ZuBzc3y6DMiZ0w&kfCKGVkIB+v-x;*$`b4ze
z;%VShIx$@`id1#=6KT%8k2QOh)+<WWJy2vY*d0;e<Gt3J>4?lBaqoC{vVw=ubaUTR
zV4G5`U#P_au3(q+1VTzP=0giw>5&gP#R5&G{F&}po4tm*>UkGo87%Mgw?7aC;>Qhz
zT77svh@xJ%)Z{b21?wdYeXBV5Nn>5k;vSjGLB@!;w8#lsq7;lFA|IA-MYOoeIbS^~
z%DetM==Jp^uh3ehGDJDPEq<ZXphoU0(q}82suK|r7fAZGLbAf3nREVdcE7TQXXie;
zFf!8R`Chy8@;l$4UU0m4556NM*+TQLL3ncVi|B>B>CCfAh@dS*0-llZUW=v_O69C^
z%jM>U>WK+o)^j(Hf{it!RSwd8X<FuAPNFf7Us+>~b4LQ*RVGK<+&n!7H^<J9u79Y&
z%<tG@H^wihe5h<c_Q;oz%1xAtyIxtV3{oc+^LMkBvP)Rq<PlY?Dx%%k=+j6{$s<Bs
zmCYBOe$?rGuWgreonfE%=GLre^illyBNSQ6MJ}T*0OMN1cJ<AjfG^SarifI7LoddS
zpY7-Qub0yTGVpd75kIFd)1_qUk*(4%G-Y&H1isU=A05e5$*n8;+`QLyd4x)fg=Ptt
zHoaCXWUP~IW`U_BdQFW`dqOUqb~}7$J0vl&p-v~qnaiX5V2NAX<b`8*>ySskFi+<`
znkTC!FYZ1@eKP>EjiF%IlfVSK3Cz#}hyd|sF~NS*)kRE#iU-|dhYv3ASTU!$uVQPW
zrH72J!xN&T{61py%fGJ@G(_6W>plr6u(@-Fi1^x4vaG%OQ7u4j;Ka)cPu7^He~~d%
zyP4Kx?cY4;e);GQsx_&uQk+)%#7$Z?GG+kPu-D`~7>6{v<K=aZ=r^~9FA!z5<`R7r
za+~QIraUs1to))3R$W%N2pIt80vep%WmF;%9gA(=Z>Wnt&d>%uSA1;pvD==IoB%Dh
z^c>AH=rY>h_N5C2%e#TEU$Hz8i?n|cg(Lg$<@Lvu{53kPcywEC5rjY?%(78tBQka>
zlQ%5i`ZXp%H%bBB&Da{Ay(Y$M71|XsXcC*ubC4rE)(yCQ!;pI6xk4J4-+{0#&ta<T
ze2RlfI)8gD#Y^+hWAV7aPR;SoBN}`^Lf_L4mM?wCY;v-c@uZ-Z$T3ploj_3T`GR4o
z;;3g<(`Mbqc1-+3&6%6DQRAb7q0bFgG>1q6N*;Q+Jk;j3w##pclj>J;0HD)*`?DOk
zu7%T6(mckt`s!cHeA!<zssOupU-9xf%JU%96Oh0MhpOn+M-XS3AWjMiv<Uq%1p8zy
z3hutky0vGFxg1!n9YdV7{Cou8wm|Bj958{#p{Cj88xyBvsfKmNc5eT-UBzL>hQ`es
z1*FwG01|$yPgX4seSy1DL`Wz!2uN=_)z8!XE8%0>pl(lBuVvC$N~fsu&N6l<EoQ1m
zPs5W}xpSDQp0me*XnvFJU}DDaaro@`I#Y&IVN^up7E%QC7khiun6*+_E8@Gh1{{y)
z9lTs#1)=F-D@Y;g%uyH=&7OV>Q|3TT>cDyrc>W$6c0coTW5KwGLdfu%%;UAsJGqt6
z8*tM5x~nkHQgV=zu>P*H5tSa+6dH*Y&1(V2ucNVD>mpf#3kUV^4;!CiACo+-C4GzE
zV1kcJXct#?R{pT5i#PK`QU^!rlFR`}g+o5}ACpVIOoyhOc3)ml6K)g`a*_W2&NI1d
z=xYPQS}YR3nfGlvY-xDxdZnwIl>2!@64pN?aMJ;9SqDVvcX19|3_)-n!RHwGgmMqf
zUb8!f(HPWz{i`-@=|eC0E>kHb+pF!bmv=E$%1cU(>+K&!gt2eeo3HPF=tdefecI$3
z^>-aDNb9EWnb5!)S;gHa!{wB1GlNnm;XF7@4%bQEUXF-2T^>_o$ceW<o_21mDXNYj
zao_z>2URTJ4LyY1oTwfzF|cl$&Xi%CPknv<*lhI{`eO9aVS8uZ73TS9X+WRbJ*kP^
z*+{zt&mCjK-_3ApIN(|mv%aK>zOBp<?+}ZKQ0jzuS8dF*neBO3q#d;Xm&UW!*Fbgl
z$KiVPu6u;u=ay1FhNuJh{cj@>8RqIvrZrD8oXvtK$LGUw-qL3a7%yT^!m>K}qNDeh
z9&dNk`S|9O2I$%pUcQFslDx)~9Y2V=E}f~w=+&Oio({<_Zb(~cY<8F)tyom9_b6zj
zp-p>F_f3Hw?}g&ay7X1*c+0pHVOOgcIrsjL>y{(lBNu)*yQ0=3Z>v9C1Di;X<9otr
zmjyn~unn$|-|YulNQj?`UZ_x2X>q?hDxj2)rXZ^zJz@NE3c$kueY2Pndz$3{acO&d
zbSHfxEW?EJiBLyvEzYLuTJ?ibBDKV?%+8)ykXy`jUXBUd{Uwd+tJRS0blM|~#(?J|
zSQDM56lv@<wr@#Zx`XN`=VLQs`2#nTP*>-?qk{Ao_Ct~+DINwPo3AjwgnKERorQ6g
zudImgpTf7nmCm#z9ql)kIe=BG%NsDd^pb-GZ+szh)N}si*y7tVtqh$6q#t!}@Kj<b
zAvzO_V9ArKoj^^J;)2&)-yt*sv*9W+3cpCQV*5F<?zW;YG5nMyO3O$WX(BjPRlI6+
zbv?zYYtV269i87G+L$POCSxQZC3*H57yf@k9y)txYow>AN6v1T|N9yvd=<yA*`G(#
zNFNdC?%{%YFtJ-RRwPq!{5$gx%WiBbkQnu`5b9S$Hm~F?g+uyY3X7oB#R!=JM;OE8
zd3hQvLoo=!_vYBB)y+mjLqlP<a$adkz30mpYNpGsm}F(!Aa;g7)6Q0SG(W|ub_viD
zr1H)=1SWo<B}!e0Mw7WqGsM`b&|1AseQ`6jS2#VNc-CC}Y?NLK(b{r=Pc;f_|K=CO
zwdgsC9`aVHS~((ym*U!hpn5(^bN(*}0gCs}lrA5Rp$=4Voq2&4(-k5Yj);lNKxpa5
za9Ttrq}ANllPD*T?Gc(agGa?~?=0Y4PjpOyn1&KJ-cO76nFj6iN29ItomCt^Q;_BQ
zh`CR*n~#@nb{T2XBH!1^8%$qOqNDn#I-n4SQ_pb2I0E2<RPr~E7tOLL!FCyOg4(~n
zIh@y~h-~x)3mHIHyjv`Hk2O@%41e6OHV`VgMICdMBcr-)jg5C%lM_k(FVfBeD$XTc
z*Nr;_f(8%4-91?F;O_43?!n!IySuvvcX!v|?$Vd+?3q0?XP<knuvm*;UHy0eP1#rP
z^L|x9nJPF~_S1*MIe8?QTA<EV=O}l~u$x`okVaWNQ9a<0e^gM9hrg%8sa0149Lu+c
zj`tHqMBdl6p=P&h^(W8WQJ!7;Sif$Y0QztS==;;-wPlvp<UP$dN#N#BEKeW;*{n6*
z&h3|Re?7mnydAwiUK$jb2z8sv@yENrwE%>lp9>_%H&K4Khn^qM4u`)Vg7c;Q^F=d7
z@Be)AuTtp($zLt#?f0+J|A$K^m#jn4sZAY!uC=+{+3@WOk}+lu`B5Obvnvbpex!Tu
z?+t}zpat)-XWTYlzRExor%B^Lp2?XfLMP^-(NvB~qFEbDSx-`n@fxLNI3%3e^}H|K
zwJ|RC2jNXZYzHls!`}Bz8nd7%<2#y7cy525wJ5neTYhwt{%XWY>Q+2yaYD{8^HP>q
zmRuk)eVBFW{9XcIm;H!N(M7ebGh`_k&$A_|F|F?O^{LXqyUag6UZI94h9yCJzksLU
zloNC;)WDhaX=|<RxLZpTn$k;PyCNXMrn-ji%zQaE&l?r<b>Kw*K&+91{>%0K6~&62
zZl^%e@XNW(Tbw8l2X_DZ!)utkHQ;OVQeTsHx?PH>*??<Of25baEQ{g82P5IRrSvS4
z>Jx6kfaZ!?%XAj;lE9(urR2{ewjrflWt!T($6t^-R==)}sX75Y7C1Vegw>o57b(<_
z-?7<`F~omh$FLgL;CYhhH4<3A$2{aGg9AXuL}+V#=o`n&0+#~@MKB<Q;VLVU)nw^v
zW998r?IQ|8b_#p|HEyHbJmXJ-v5pGhO@ezn{y0~P7fn7fs~KhvJ%*qR%QS1mw;3ho
zR+}57?CTz7)(C)2#1COa5p)bjJ!-B-$h5G6PX$^Cb_}~zI2OkLlMFUP9P&-d8uvs+
z=yxpn`Aiyr`6KSOL)e*y6dV&vJDA)qZ-3|-<199?F@#d3Hggs21=mEZ>hw($e|K=|
z0?bN_E1glL4l5hug)c*)7^Xw5rantV0D|yIQa^0e0|1l>89@oFFZh%+uW2&p7moR;
zdHY-ly*$$Xc&sD{jHQMjp_=`j%D$n@rY^`AE4D=66KOw|6<gW9s5nARmGd(m#q~di
zmSl-Q5vcO(3FZ%?_~wm>G|_1*XRTmFlej~m?i0X(9Tf)4&)`ArLyl=xcE5e4CgOSC
z{076a2?@$8E=$#X<5F4pU4?;WvvT1R{Ea2QD+quCh&(IdNpbvq{*a58Z@;$h&l0Zg
z(EuC050^#X(+U+{%(@dSbgzg$OZ6IS7+D*U)i}69*15b8Ivi4GrxEu#YJ;4=O2X0h
zzBoG@InSSY0?8ki!W}ove8EDt3cf}^AkM<Cy<Q+8mX{0Uw?b-P`BLMpr8>-}ZSS|?
zdZ_n#y_<b5jr3Pn@nq|j)3Ed4?FbnVrR?GW@ZRjcKSGI2jT8M8aRG+Lp67@HH@|5$
zHdXXF?}794LQ6~L&xFLZ(N(;*6W#n$aDX7+<2)P^UQv_U?#{jgwa&A2OS#<PRvpRR
z%%c+$?)E2?em*eMEL-oHI?sBw`Fh&5mV$dj6;7kT>~GPZ*QBVx^}sT(2Zl7%BGI20
zHAyx-xM2g^YI>H+axg_<BQcrcq8=qUwEdcck~VvMmPtFr++UWdqf8z7o~;f@4Zbdf
zUfEak+q}#avm)U)>@RHHgD4VKP=V}!G)K2+|Nh|eQxDAT^NYC#X6b^Zj!BVClIIc3
zSIP|{YH;(C@U>YrPQ>sO<Ne3d)EeS>xe~EkTyQ!IiSzb~l%WlyGx^vSU{ILA<iP&(
z+kVvSb(=Xq`b%@wH{a{|dI+~_DfRa@3FO)#xJW3e8lCka<afC)^9-)o{S*r>*1fob
zN?S?Gw+eb|TtxqDT&CKWJf4)24~~;&>mEpBl8n~#mr~-WK0xP&lFpIlU1UI9uL-u%
zDfa-s0)uvD8753PYEr&9bRt8Rt<FLvXcH}ogr(Agx${Zlx2~3tTF>vaOK3<dl3o_|
z?B*Pg3>v$!S>lq2=dJS_bpLFD{P|2PHsWnB!+~%{9>DjX>e1$D%aa=$`zt?RR8RxX
zpY}3ncI7)-8_oRk^9NnleTBVzjROwk@iq;A1kocr$gfDwG{2&?7^JK{2aU?vs9I@O
z_O8B1SBNj5anLQX+kQ$2Y`v^9R6`!%+kB1UxS8_-;TW>aFE+m|gp7}H=^7VSbwJ{I
zwZC7<mfG{ef*Q+T>?hk-xOZ@JoCphlS+kCxJ#RL;BQ|nKud6ykEm-02ZDA}ZhhCaB
z=`;qk%zIRy^6zg3U#X`yA#je#<9o0+TD6|;(-w4SwBKVm%*>1nw6LwT51);ZPqhYe
zpD$kS3a3Ghx{i<k*y=35UPoEitRtD}qebkjz*a2(JiU3*13@DhQ@0#JE=h%W%Bsw$
zHk5!Sj_7io-u!7mJlQVqa5VlZ*1X;^ETgcHEV)iU@~H8Kd+T}DRDVxis0M|{CI%W)
zjMw9B&l+S#KdX#$e>08u5od5gZXdjhx$aul?SyEPbB<PG2McJp+Op3MJ1JdefnSrK
z+HV4WRt19^nmD?IphTFKMUKQ(%ImUe54eI(!`_QvgDkT+Dncq+t+Ju&Wsgk@HKV4*
zxw+nCFrj(Z)i%NRJ7&~78@iastozS&dzGhf?Oku_$(#vOUww8uTw1x2V-?h>yoJR$
zL#!HO-eA@+x$%@=+AS-vYei)ij=a{2H(tCJAQ4Ewh}ciS?rL>Mese0ty4^;o*7h0p
zB>iZwiUgBZ!m!{@e%LuK>SjDj5C#}|al3fR%O1ygw?2nBB}l4~^Yd?h%xU{JDN7<v
z0}gLS7V;%OIEVY_;qf@vUyk+5iS^F~i`A)cB{!**#bLF~a#+lv))>mDgED2x>-=~u
zJd6x-gaJ;d<D%LRv36@Y;^S8)Mg8W!L$Xs_U0@??jQcCi+y!MtqPA-t8<QynAM7b3
zt!oI)zY2UtYkFT-?j>lsXvoC#@k%~-ZeKxU&4b?j6yt(XqkK(%Jfnf2%2SQLg(p|C
z&3}dO<V-uWG1b9vo$u^?68Q71_aaYP6U57ELf-MYrmjM>eFqOU%Pmh(`OXDQgB`%Y
zEfur)<t}-8J{ZFFQEXb*?=GWl$^;;<z{+|uj&(J5O|K&h04wMT<HXC{PYOs@EAbKw
z&ZxJ4<ZUuEb%??MI5-UUtzzXEQl-4pgCNl1U!XL~aeB42zCN-!JdC0B8g}=*4e|Om
z47m0x8^3?=nJndWzf>*NkcO9d|7PWm1vrzI;%wG1vlG*MZiREA&!ZiOEHD{4vC^@$
zCZ>sq0-&+QDjp>aSxQ3(uvVy(23~)}+<odmzhm;2dy1vR;Y13$n5{Dsd|H^Lb*R?u
zY+0^+lcRSdMJM%8Ter#yYl7f$+veU^)_X@L6OurOKbG&>kY$G6RuaJMP`x?H2CuP;
zISS{C>2VEs%PQ`^<F<DUad<qMyJ4NjRjk`BuZ*XTpKPPi*iuK2K@c%BtrgaO@Ff=6
zjvD`ol|O$ewB6({L`SRjMO8uDR*SP-&m8#jbQc-vfy4Va`9hp348-FTGMb}~jQ45#
z>_$ESy1~gd!uF0>h=23TgyzSJP7w}F3Jf6xv*$%hKD54`=5(xwy~Er*4}K^7@^BSy
zi^{K+<sTU0T!@wQ^BdeD+e{1s`UMTeVv+jFl<&MJW@ha0G+guZ@^A6!w<eIZW>=ai
z>TKA&s^~m*8(nPI&Nk?0cz%{~1wdjm=WAw!tOu*kcj(reGbZClyO_qzO+{JOJT+VM
z#*wPss&^*>AEj%`Y8Aai(wa?n3NXB`pPjhI)n%3v!KEZpUmGvCq}<xql9P^<JjT<Z
zh6|&;N~Sc{>yX=R$IeFx@#+!qCta2XL&S$cP*LO76wf_4-R4%|H{PNA%-Y`!Y)uhl
zcIQ{hfJ8FOrywJ1QW!>pEh#y0gm?YsoUbv4gYb4y-0bBGf9p|5B5GFJ;j0%na4+2S
zrV5EB)u84`6#=bSLjcg|GMMHz{x$jLWg}>GGa5I|4MAT6%FL_YSOf*o9WYhW&H~yT
zlnT;W`R#s|u{}vWnb_g9(P+HAvFrWuHMcJ|_OVXyjEC(MPmkR=uHfv+rCNg+LXzMo
z*D@vTg(c9>Q!XSE&hI|lXbf*l6WD(J*r!!ae#X!_&4<2smg{2jw!JSku(Z@-P}Mcf
zjM}N)OHiO<_bR;C4lZ0<vpuM`_<RQp3h~ipah!G@l@a~q_GBG@%`G!DjJ(lY-*EL3
z6MI8n1_+Yh5i4k8;x7Z^|DMkchW;S4L45~{u~g=pLKG;_J#YMaTTSxW@n$w2|51&x
z+hH~;YlO1tBV${gA#W%*4TD@VG9I$c>B?FbEt#Agqb43R5h*hh(M@Vw&NIzE4&IJM
zdaCYiasqgyHITrzQbzB?dC@{z;p~f<{V+?;19Gsas_-K_D<)Tc&T##sMPA*bz~PL9
z0Q$S1+>F6GNg_}rOVKt;N@H#waw=yo7go292{kw+&)b8Wu<@@*v{dX_4PvtSgE`Em
z%t)CZ6anTo7=><<!{|;R!-n&U3@iW~YbfJOg>H(q=GU0!ZI;3jy;5vRcI$8+Q<L%4
zX?LU?S&Lq<HpNJr^W&BK0I4flKZRfcM?-{_gqRLj;K8}o+_+|`ExgN0;U{TD8dWlV
zvbMv}8NnTRfUA8>#lghO&$XSPpWkDZOnKBNlqzV=ZIqsXrj@gmD0HESRGD=g72kA@
z6o$GHB;F#QSaUd=b~ArArmipiP1;>7^m%!6;^ms3<mMPo)y;lrGE$UXr06_SX%Qp5
zkJv~5@Oz@z9DKTie)PQ>;c_IXG`o(jd5Gn~BQt!fL*uURKb`b~Guys>x1Ug>3Byt(
z2<gcWwwna$SMz6Wbet6A`FQV;)oi*Ty%(<@owO##Si7*D&6ww+g@*h(JFX?K&Y7lk
z^6tY19x~QjEvi5X3wO|LI?6KcqSnmUesccy1Qk6RAftD9^Hys=Ki|*)Ot28TB4Ut|
zm|Buuy|)|{Q_*ZF3tCPdJwMY5g*s1+T%kITj93x(Jl>WJ;|z_7X(1;bY8t=iIT^cc
z;MJcr$s^?X?qAcuN)(S_h+FPfM$r--Th3XU7D=kNneOG-pm<&c(s=L8$gtlH2X*+P
zDx2=5Q9Ll{QSLHkh4H4KSlo`08R&3xp-Z*0Ti_KDTePho6iX=C=M<}G!Xn_L$W5+X
z{Yu<{K$$Um1HWQJrWE#xnl;XwhNN{8bn89J?I--DjMi!9YOBV;*V2|~8(8-`!=&zO
zKUpXqH(@ir8m84wbB*|T!J7(HG}h`5uBIBlgI0?#%X2|zs(6805<QhD=XKPg2*_qd
zy_`xDX4Hv_k-KWd>ERHOgIA%~ndduWvfu9TDxKEb<)H3n2RQFw?wH6~MiM4^KI(Dd
zUMIlmtU_dqlt!C{wu`6^-#FLJmz;enTh&mrSAUzdwKWIPk`Brk{03@G%LYtrrMQ_g
z<xSFBEyM#Sps^8=H>3Bb-g2ME1-}T@Dpoa1bxre+Fy;rPiFjl@|JkeFj>mekS`9=?
zBJDEM-@Bs4nKGxmdz+ix4t1kB>h#Q?DPQkFiPE>u(9ag`YdXOy_IBc#G1#o1rL@XZ
z_Laxjn^G5T&SjfQc&4AJLsoplJs-opEL2yzvS$d{;%GbM+#dq^D<5dy&Q<A-^RiOK
zBkR!HJWXmp;uTBZUIyZTboPdv-~df88?+?u66xz{lwKQ%N<{Y1Kmn2o<|9{D9#^YR
ze2Q0TL^+wIZE4Y(x#tLY>`li@y&-x>ZMxZ5P)&Ax<+B-!?$6@7pG=yv!0qXSzky7~
zwpWrbIMC?aQV3YxNbW8gc(Kx2TdyCsQu4f5XYR+IiDD7fFtx1kP<(!A*nNJVhKcRc
zWz|BfzKeGS1$di(zbkeM8-i!atk-cN_NENXm0gvU0_8BA=@jR}T05|c2wN3LZ)(sA
z8aNQ#BI8v<ZOXmpuSJHJl0Ow|4mXH#!9hi0{i@>0K`6uz=ewLKR%mE<?#F0mbF~X}
zYW%SwVFUIP)EM2(a9^U?h)Q1X9aS#VqT=x*ts8U-^21&%ABL1-S%#>0T#rmk&LrN(
zQ3b<yD&VS=w#l_liluJ6KO>(c;XMsLc~@@SiiZ-T3;Ne2f6iU&)^*_VE%5(t^mQ|B
zK)T9;8VGCkM=T~mZ3~>W=2#~@T6W<RcvR46dGzAJ`}r{ACcD>u7dTUd?R^9;8Y>)z
zqdzjxz$5v1$ioe6Xqj2kV0lyj%-%0Nu3tod<CO(&OQ>UhN|)$mbyq}z7UdlET2D@h
zY8*3}dg|b`zC-oP7y9zjsq)hV)i69%!@S0DYOYPwVA06}2WJaK5dhfxdfLIe$6+(e
zS5RCs--?G_#g-)%*qj0GVm1`jb0f*R&bDJpIg04{vC;|elY<VEk@-CFtr;oMsbf5U
zSghzcz-oLy{QwPqrS?3<&htx)R`p2<T<A$!X+Rm~gEJ|83?_Y?&P^TigrG5`1t-|&
zdh^7!swC2Jq*J|(VM2A~W4g#(wOd5S$mc=v(g3P71`hcJsyDAi(Pz8MXttNem9a~q
zV@9908iFcso!?!$icdL`?^jExGkj-~-7XdJNEV!S(Puzer+d4U&d)H=>^u7i8~y1+
zX~Se)gdsYOR^rVI@0cdVTvI@6K4n=+LzxfNtxs-=B`?->%e^zpF!bJTs0b3Q1Y(cB
zTbT{kjqv8^9n_6k>lf``gLU&a5;QFOyb<Z9cM}=}A<4?)-mnc*HHxqECdY1ae#gpy
z8pF2pQ?mx$SG$i}MOgt9t%L$e8n%LluETewdxD*<-%-=ZN3BYP5!UQf(6J`byw!)C
zzl9BT$WPoyH7De6?Y2gC<)jcu#N?UmBAc^(rOU6ELOA;p5Mpt3uhjF$(5-JutrooK
z#cYqiL|sJHZL=5sF}+5za9L4x2LCfZ9oPDE?6>Ob>ZgV^LE_U3=tLIa%zg|ktAh3R
z#`vZ(b+gFE2q<p=3Iikv4j`9Yr@vF`h!PCch_*<2n5gkI4caTwh#`K%`(3&FYtO~z
zkM;ZhLeJ){BJW`e)DrFSkJ8yM)4&1QY}xQz6z6J*blj4i=qzw3`-G2LFadn;<_nd|
zVFf7$Fzq)sdgizn98!eKQR2CFs6dG)p4>29iILeiG&TR>1)z(|e3YQe4ef+qa-0)s
zFh8YqTH?9rx-PhORbh<B4upqLCQx45K^AW_oXkrV&Ie_H?2=Vi@HKeX1EV6PtqOu4
z4ATt>U$%D1W^SkxO+q0}Bn5-^j;L25o)2q`oWN*P4R{#_YKhaTOl0<Q|4<FwUGjRF
z)SpA$KfFmUuT>0trJ|9}QT8WG6QkL1ioP&UM;;l*xWGdtqxwKd>2e*%+?1tj{HyNM
zziowv4agc6szd*zc_&C`7;<E)E|Z-IpPGP0oy5_5Gp7I|kfdfSXy96Mtg>VhpTp3<
zO=2Jx+mANWnEi!SWtC_WODwKrQXv2B^pTjW&k&K8zD$fcj=RW~EIrsYNu~jg9|d~r
z6`m;#hgm8f==Bc`>rrZeV`-eMbad7u-(Z@TLl$2)wJ@60U%feRpt{pajPm?DR3RON
zEF=!c*7we;lrMHkHPrP9z6N%*H5|JS4dWM#ELRp4R8V8>$b|oJGPL~3X>vV56S2eQ
zJ0ys0#BrkHRkG1k(R)j)BP3DqS*IJkILVdMVQ`)AMBKC^w`}cmuSy-4?J|<b?Mv27
ze#)q@mBv6L<pI;F-|0*~&y)?D>A_5S95Hx&C{*-8t<g)F?|wV_az_9b{(+H_>e%{L
z`aeW(uAQH2az=w>e+u6h@A&_zhyNvgga4(6|FiU6q<z8b_LiU<OL>`F*4My8+aE=v
zXCte?3fe)VZbb$!yx)@jmd;kz6ZcI?mR{=d;Va3>9saA@=_a%Ol>F%MA4)NRU1CDa
za9rTG%>EqC>EJ*gr$l&!2$0UcMY2BWddn<s1{9}6Ii_**!vsJ8c6;HN4K(X`Pmlpo
zeKX^-2!b2{5rK(&QmZ2w4Zmj8DY7ymrOb8>uUzyYszORa6QsHK2wqr9Hjt^<$`#Ft
zLsWEBjRXMce4i??BUl3#d3dUvWU2ySDQxkubiB76D8|fvm*A@Qn?wonORsfIH0Nb0
z%xZ@;AjBkRv#P`c5a|>54Q<GCOtFl~Sy8>j9L4&?1pWaiwk8i|YUHedmz&)x>p<{e
zi{6{i5)ztI`ckQ9GdRF=`$K^^`z$T(Y4giAK90IZ;8z!m|5WPe0A!)lEMqHfQU1mH
zoxIC`$e6~oHd~!1v0B9KuP5jtN3V2ezywd(zHe=8w6Gz**A*CeT(WizLxbZ-s@?Zl
zjv58V9AmVGo_LQ7o#|3MB~AKIAt&ew2|w0TA^xj$I*}_kZ>Q*Sv~=6+c89u7Www7T
z9Y;6S{}k-6ZO-Jk%B>@#;BqKSTF=4SZsjsSiSK6zLO`H)5FOuAk4Jr9)AqId$rTmR
z%_z7|O&Eldy(RubvY66RfC~Uxq+AJ7>~~WL5-yNSbV6K^Ghrs#Zxv2V-=CI^Tm+BL
z%kA}p`rc+V*5u%Z$lHukE(Q<6A%%S)YcG3xFzYoX515k$ust0OUggB-CW7zmDz(<w
zFAZgCq(O$wX?8bA-FMfO!}Q-l^l&5aDx^QHp0Vd(jDlEi)a(vNav&w&q-O;7`e+<<
z5VyCPN)(1`;drAG<IIM~>XYjf^;iQsUC=yN({P#e^g3A84VXuP=_RL&anzIvIF~=U
z9YmuNncj}-OrhK-T{J(z<dI=ybGhrSY|`o(w{LQl<Mvwf{c?mbsrMd2Urru%RJFR_
zVdW9e=GBy$!HyzFB{(B99<ek<M?^xy1bYuTY9$K(cUSB2$dl-hSsDv*K!TQ#;D#cg
zX08JUA*=M7kCv4jCQn^q!2KZVu7iRSeH$)&2_*yAuu3rjh49Dm*Rm6#xC<^eh(4>?
zw{LQeIgFDyNj0!?hkGzNvEY_eiOmu3-F8Vi&0-^`-VCLlQJ*sRelLjxbj#{z*L_;3
z-XII)Igd5oc{Z%(W%_QThu?Y)YtxUg%2+9O+!v#f#Wf=LdXfSr_=Eual+}4+v5*4p
z#m#YI_lFFgPD*h77MuR9W?v6ZmJ^e^A)~f)ORpBhaz#+Z>PDk45(3T8B9`)ye|CS*
ziMe$$gvcN^C(E-5jJTpAEZWHA=-3a*(XL}_GM<Tch)9<#t}f=@v3rA-kmpX-WHe<H
zxQtYUo;P7uB#DNiX`H8vHMExJ;GF0#5X23p4}3ZfQrXM&KasbR9NFz^p_7Q*cT*c{
z=C7>Q3Kj96Ho8?<)a-TwU}wt-5&Vc=Qn4ZX9qkt#g=HLCT623c%`G);_tzL>4Lx|+
zbnTq=h4(eVROY)t&njTUicCZ>Kn5k^eg5dozW3sehtbHJS})Iny>-(rvxr$Br^wOB
z`(tSi*7ny&D3+wNxNFaN_5O1ph|(o4t7d<*bj9FBvqI>6TQ_5j(qYT*(a+srRC&+I
zx5~Qli%b4oj$JaMoK@tSFuTEo8XpU1Fhf#gZLh18O(^M7{2|860tZ=w5_mlFp^=){
z>*jTObG<a9O?emdvXPJyOKv)o1~eu#_RqUDHduNbGj=xSEt=wRSx!LALT17F*iAJ4
z=I72!4-E>Nm@cS!TVUnW5Q6>3f(;FTfo~<Wr|!JT>p`n2^WAeLPhd4$R!zykK;{KJ
zBm`S!&t(5_yH~k!SPF<kDrbf#92|SGnyY{SR&JCIUg0vhuf_Js;k?GF7ClblV62!F
zLVT`cr$J}8rYYTr6LA+-SyWlVj+m7IObf;VChy&!&^Np6tjG*c0cf)x+*J_<{tkV`
z)1;~=yU=>B$9lD^-ZIU~;3cEE)32)9aOb7BB8HB@bqa$8qGgPDL^IEYc1yPxlJx7t
zUH-1mB`5l6`aug~?hbqV%Q$lK#jDK4K?n7I#?PLG0XWZPk4=iZ?;Y$*>?+mt;~h7n
zPG?XmqfQZFzSXymLax!>tj;_7qu$dGh$`!2a37{B4wq(uPZzx71#7Vk{MGRqEy_0L
zZAxF6wh5eQ2I?LeQzE@YJH==&UqMZiNt+0<sy$b29?r)jy&A)-gMQBhGCyZPzWsef
z`3XFx8DI1GX{RtUW&z7ey<V2mu;K)U1|CI<dJ&A!q`(OVU#(vJY+)pJAL<Uql8w#C
z76`#GA6$aSp`g*Wce4=G3**7DU@Xb~B%i_lAd>2-ZfWE~beq(<rV=&7Q#)loY4|fW
zjj{d+<*6<f*s^XkZICDL_@iOpZv5KxUG~$2rKkaN1Y;!XMXE#h6nTz-zd?)1ChPul
zkYk7bvJwXRGN%fH8vW&kWVa%Uv|J>O>J?_p+t^hgwq(_@5RT{j+epwT^((NIIr|mZ
zHt#qvmy=CODBfY(2cYblUPsNQjY{+P5oEraMM9YFkY|DF<_^eoMfhmF6p2&JTtd$Q
zH3jPa3NC9S=Rj4&<clXYL8a;k<<57x7|^2Vp%b=>QK<X~5CKzh66h8IYc-|>O8y_w
z^x-+It#yym>61B~EVZ>azQep{K-KoqCZ`G?>;r3X*`bgb6d3y`4VpwxsX`AqI}=~O
z$mL4R`soKVT6xKYxRB_VKO&Av*n!<ksP&?CtNUfQ;jx0&XPco`gcR4urO#ZxCLA{~
z?@6Qy{`3t9y~SWT1v~!|Z6V2}AY!^j1^gZ_2x^_d&;DT|=+Q!4bvwMiGyB7GK>)p_
z^Nqvd_n_#TDVg@?6>pXXm_MKVXDLCU9O<7I{Z;z^b;)0E==;~F9B!ghtIixxyg3q1
zw|$2~r8S`T=bXRM25x;?aMaG-iR|DSvOh=DPGhR@RBtULxZ>yi+VIq<YcY5>thHM2
z3T!Xyfa<lcx2tBgN`4Fds0TatFtBC~`%K)H`1=zUclbofa0)Gu`|{8KGBmtYcmCLn
zOVIZyX(?4OUxO9$+$cBEY4ez1mKIK%A{y3uxtR8NYQRAVIe7LGM^C`OcnT1H_GkY1
z`lzg;!pu1}cQ@nY`FQ1Y=9%O1iHFhZBK9m1Jt4{s52PJ<zV6okShu-5J3;RPLUei*
z^4nvumrzTxcNAIr(mI;H-wLY~XJMLJUw~k5o+W`7_pRG!2~x)#MFm!$@+=1e52c{?
z(~;V$L7DDV0``MXOTPcjt<OBKhQsI2<X6hgiaC;o_a*)(P|tbHAMr##S+r`_!wQPE
z<~r;|d<aByRzcYB)1xS)5m5ML5s=<qhB5en$yr%0Z79&&$slHI{eDIogI@(e7iABA
zlzkJ>NNlI+SN$#wHI-Ev$$PR@G>`%AP)uaW@1~STx#QhFq##Ep-v`)%P9^>%5D@|d
zh*}<5Iwe3ambImJ+abm%=nr4GVz<F{e}?xP1PDG181O`gaeO-V;L>~Qh2&So5T=m;
zZzjWAXktu@P5<!iKYb6%ST!|!-C-lXa3{-~f)#q&R9(FvwDOuNQe@u3Y43an%<pm<
zzY)LTe<FV3!(PKa5IqCwnZ2KOAX*^3>>}Nr9H#0)OWPYOoeyRjw(m=+Kk-R8OqS$S
z;Y^<4UVZGZln8U?`=UAHvWPWg&I@Wnr>!I3PvTSjp44?LSr0)Y@X)p2nrmhj7I8{j
zW^*!E9usLs2v@=}MChBDbRvIoyj(G*^m;juE-$T*D{)j=vkL7oLylVrpB3x^4pQg9
z9g)^GhB8=EcE?(B2cLHpiWRq?EKG0u<jJ;s8V5lBeuKR-HEr{y8#Nqyt75q*w9u)c
z+(N6>N$O&>+Hnj~5QfO3HA5M?53+L)LXE4H{iv9;f834pu`vutAf{c(;xF9(^ir^6
z#=7KF0fR^ulEEOj$0=_&bj&UuS-MhpW89T-Vt}$XpJTniDPFqD!7mf_deiMEY<jB5
z{@|h^j>$7qeuOGvve2p>8ko^0Cvo~p#DFMBlyP;3|9N*NAQBP3CdSrZDh%cp_rg;n
z+{_1{HS)}LUFE}_;i<@I_*eK2m`#)_73Z>*C5dM1Lz3T#TN0&G56@tr3M&V=c?}G)
ztJ!kb73;6_0jB4`&z>Hkpp@nb<ut*xd)Pjs+ZsG<qDnc8-hjMNd?YOcKhmBUyD<lT
zvK!B$BrXo=9mlt~bxLk0oExARbzgNSqLN%@vpeHMFOC5Lv%uD;V={6)Jkk2B&UW;a
zK~PoJ=xH<C)5{%j6YOOH;=Rrav?nik-0clddmOtN4c|UiG!>Dj$FgbZHvD1M@d<tn
z?O`hrpyt5tGI~6Ymr_%&M$4;_+_CM~)&dt|>9V-Eax%G0V>l$HgB!jR1akHrgB_Fw
z`O>$s_1C|xg_Nq8LQ3PXM{&RJjvC2jSI?TJo5K>=NH6WMo%^7|SUTC01=*^{W-k-#
zX8O_+7-54FyqyVBC(X`#Xj-eyvWAb0T!_Gtycg#xiPPwDS<*A#u?kwW=Rx$^a2?A)
za@^}81L_JhL+N8aJL;<QwsoBxyo+4to~srAsu$6Er2C|rHiAJ&y6bW^LiggbSnCbE
zDDgYDt%k_QhKQmUA)ZO6V{um^={TWuw732~mvd0Y>U)3WaOiZn<~_G7lz!Xv-!Ch!
zMAs`?YWxh%kM9CXN&_(PN=NZ#GpFcj?;k`;PB;5A5Hr-S2cK!TI~Tum7i4D}&&6<;
zZ_nKYT`84BC&^)riamRSWl(E*&bUmJ-aT_sAs&kXsV`0x%=j&yx0v8?mpzuYl6I>^
zJuzhAfK8T{-={+(1>5lJMxIuR%<Sf+R#6?gmMB~OL37DA3+Ent6k)`P1Hb@|6;JxB
z{$oGh?>Dj8VLPT4y`?}{uRG@yz{BJyd5=wV{43B${lfzW?oGdaEIxL~Wu~`IF4^QC
z;$$SLfm~ZM?L8SVW1cyzCbjQOZW@7i&_OX7L*FjOsKvT{TtPY>DHfuE5|yZRF*apF
z>F4P1flgIh(q-S9J6=)GcFfKGz~wXb&36fD6){yVXYWO~y;QY^{aVs9E(?9eZ5(CR
zA5n$64BeCIH|`#eQ{6?_*^X@X$Mu#6eI;!LqsO}l8`llP7{Kg^<VP1{jKF25hgEh#
z`aXNqG32&2dRp6W79R<+2K0F<_%BaGb?iEVG7fBS@?BqBA%f?yv-?S4j|y=Mn{B3!
zOR?rA`l6h``S0ctD3vk}&YibFF-QlOEc#JN(V_0J;U^u@-~Vc8J8_WiPv2<OkCLt3
zwRl&i0rI;|>o4hyu9G-AZQzITy!D5MZI#2{?ob8RP%E1>mpTW^(rE)=OS8UC*15y6
zLdTXGiBJes8BN`0v0vV#V&Tq&$A950{9<bVy0HeNQsa1f$|ya?E$sO8+MVXQ=Ffw{
zGkss^+Eko>@uTnWF?>~fyYe@O4AzNwFao_WM9U5Qmo~O`)FH}^Glb-!2(S9LV+9je
z{63DPU-jXJ9>F>ankUz^U}Ivh4I_FtH|uYohRHA{NCZ`ZM$r)-$Jb19da<)T-ZZb3
z{2yTUH53qVX@%95S{|bj&guSdq9E|8D2%7h-ji~m-9OR1L4GrPdrP7Zj1dy{73>~q
z%9#ZfOw=sSz(vY5NK7S0WnU)5hp($4LQ0djb>;CCU~V3_vQZG7PS)RT2*il|I#W+d
z|3`9uyTcbl(nn8G{5=fw{gJETPD)8^!Y$0IM<a{jO>GwguZEr3jTHICbb=&4**sYh
z;w8%5q;bU0n+TU^BJKAeFukOlZ`+18EP80L5e&sryU}b8dwF1T3xNnxl;*H>+vpZE
zCx7w<IfL%;Yi`~dUT4V2XxqZyWB|Nq9WlOs)2bwQv=q&R4U_;oP57!0)ERV((F%3@
z&{^~{h!&9s)pH*bX4i&!$zM~7foDGR#kGxG+fJa?Ct8hL3m#2bAZcpkvaFFWs4AVX
z2)=hMyqh7m9tp6F<%j%Ti9jqT<u>gVIyrlz^neg^t75fi7}U3Q{i~_7%as_1;*1Bc
z`@eB_vEV<K%I>@BFTij_OZURfzcB)|LD)6_Et=oQh+8S%h4P<u5c~)0H*cgw*`}S(
zt${zckMe)uG|^NAwX_}Pp)^w?^X|O!gM$^bqP%ZU<36&~wuXkergIhJ#hiwq(@lMc
zv>Xu1eWKr+w|l3DW}$V2g1wRJlAQ$doJJKQP8l|a^}og9pROG!bFxEVM99y_l^(zH
zwD0y<DQRguWOXouWzwA)${=J+%ogZO>x3T|GYMb2_O}kuhiJk`B-2feH+2nH;cC>c
z%E+(MG$e4s9TkRKr+zmLCz0C1I*;Jx`iFhtu)8Sj&A!koQCG9*LxIDx1TP+>#l4*}
zn5QDUAK`X;9E#1=6(N}3$QF2@`Hp>|Fc{u>I&&1l7>uaFvK^D6@*`s&8Y?vY-1{go
ztK-41iF^caJ$i<5X}_fWbN%(ze2-R}oKr*3eP&;_YgWQb+2*bHQV5i58Q%8BV$+33
z*<4+M`nH>9j^EMK^^hPOYy3?*2GG#Th<&(fh$kJVT>64KY1+4|xQCFl2GUY|P^%4S
zf6sbkM60ME`U9}AMI(JDf$@hH5w2unKntgA+O`9zOSZ}aL=Z-TQDxqU(rewd0A?$T
z6U$CTKdY@kQ29&2K<g<3Ue<$4x61s(iDsK4iW&ko6|~nVmf8b8mmIo&aUL58I<N42
z&E8r%Xf+L-0Ne!)1ljG6aj<bbI>0ncUw!{bq$wW_a-eSCd7-$8P_AJ=842x)%S)^W
z)(PVD!H}gmXA)=f=q+3n?j!+4NoF9VnhmFph_6;hsQ;ii*JuCDha+b{y)AgocuN{=
z4LJyElpL!3qTlYM$t{@{F@!brtvXOyBn~D;+w%qPa@=Bxvh^f2i(ahxw2*DeJ2ZnY
zd_@wmn4>k{f<|?37CPIbz0g<C<)V&(uO__+-HkWkS4vjLNzES6Q1K$+r2tCP>EOA&
z%@A@WeA>Ql4bR7Ywj_>ULfn?VJFAI;IAmhniUhgLm`5Mb#Hqdm;$x^JCBn%#33R5t
z(QK?Q@sZZ$a^>Zs`gkX9psj{`D^`--ra#zCi=?2=qfH_r@?AfuD>#6l&Ot#DeKt}?
zer2HeXuq`$tEiRk$a)n^VKF?_KBoZOf07pPL#%WD@X(;#=DI>RNYTbe)Gi<pGLE7w
zw!z}y-3Of?gde#s)m2qh51WESxI;~`g>wsqwzBGfhUV6(M=H6sJxWe3t=0+lgVbJK
z=u@p+ji1gP`pk55B*zhjTcM1E;rOwblnq&PUwv{OCI1ZUCM@#HXv?W{;Rq4#{IG<1
z`PTgZFb}who+drY&E_>F<tO(Z^D=M#kR|v`s3Ucm^)kq*LG+fEtc(?ICvbDfcS0^v
zquDVEVOxw4wzBk)UC<da9;diM5T+`nOwm?lba<<?W|*5JgD}%8Bu>M}b$mAiVO_1S
zm+p0xa<+z4oqUFa1z~V<5_bL3-|Bo|&=4u%ZwPyaG77uVVqGX&|D0Rz7e++eeP8tw
zo|=dIMD@~zjc??@wOTG|&;IUJMvr-)IIjK%Ap4f5GH(R{@SL+X?WOj11VnIEG{$rN
zQ@6q?y%)f`ZVwbH0(da&aD_9>PMXNbiKt28bYrBv`8GjeqICW{*!J2UGfJ?5FVnU5
zvOvK2&Q!2>F@%4YhWR`s0?_F?NkkW?3V}6Z_MoaeB`Ha;QGXM$f+#SNih0^K65L7k
zcl(J}EEbB$^*YqrFK2VZZQ)$5r>&mNrneB$^ANkT+#k}mhFQ4+MlqU2&BY>^PNxk8
zBfKSQ!SadYH|^U6<{GYi1FlP&9dCf1ToYGCce!Cn9LW>NAL;{GY~d6uoWQ$B{u{r5
zZnDY<qC7~!&wta@dP79;f7jiTiq*g#z_dK0jIC|fWWlX;ra3%(rTHPd;g4!uAW&9|
zo@1nlxBS&zzBgboPZw^i6v?S2AZR_e%`D-8Unrf-G)YD=d2EC`c-PV{G{><1J(*Ux
zQ^5Nre4U8<L(Xp#=n1vI*i0z_4<0&J^X5*gW#IHxQaa~=YY8fLYk!Zh0d^#JS_F1!
zjfa_Xv$JNJk>Sdz69s<Zum1WPU5};@gda+sh9UlrSQkBwT$P!?1Rtf6v;kYdoTTWD
z-*)3fO7$<BlneMq|A}{<RM;b~XUuuKI$o9D%|c3qpP=XowiTu?8k~Phl6N#8c^6D{
zJCZQDQtZm*dRSXul7P$fJbk!&AgCO$Bil!$FaMec+7_9|!WeO0D+G3_=sGt9<Ouh$
zGL6E8)1E8ESo1hh9PyI;!o_Sq*SOHjVn$-IdZduxG2hokNTcJQ8IivmlwdFtgrk!J
z?ZUV64bY5qk|2-1$#x}zJg!3ei^tD2MyUD}lS+b*h13MF1hf*pL$Z><ifLRs*uxG~
zx5!)Uk^;XS^ZR02tP%!ZoDi{<HU<B$@*;X{4Cu{}ay`r7+nOh-vcTAFx^gt~FD$<_
zCuF($Ywd&k>0K$L#F51?3$&8eulkSac+?#aJINVrUzw@@$UM}%UH!RcACMR4`QUFX
zh?#En+N7wWviPEQmW^`f{LKul(H5@=wns##m&vpAdkKFuECVDi8(Wpb_|HF(ccj@X
zR_<EYXrH?5W<IPX&NDksi690{s>;>=j?XfeZG7Plp%F3}-w&rnv$qs0idkb?AJXM}
zXtf&uf1}C^itjT26-!G4^8l|j<N6d`AcX1<&%xV20y{1uWnRM4rf9>w0sjyu8;gCz
z_y9)9HZ;GWyYk0c*xCe2MM5#k>@Ve0@B$3b<1ib|AC%&Ll9agdG71FSGP@33S7ck@
zPzo8V=71EbG$g_!z^2J`#uUY>K&UHbDMPrS`@}RunM2s4W)MkG>)Gx=FMkpy-hrTh
z{}({Ug01AOti6!20l{UA3->9;CIvO>RTIE&TSG>y5yQiJOF=Utzl_)ZaHU$B<`1Tz
zCLEhO^|i*pPOEA9H5e(MC(lEkmsa3Lj7=@Y;B7h4b4ETY&!~Te&!ctQq5f3ClRWYn
zny5kdSLgwnl&xl^R?VkOPogZv`)eHTyUl8&Wer7${-AI^pqL#P<|&cJT?vr*rxyVK
z53ud9#b>jBsA95Nk-(QGqZZqI)$rg(rRe@3ih+@IPVP%bTZo66Ea}nx4MsnlCE!0m
z_X$zy0VgBtbsCeaF@|t40M!kA5;Cp%Ti7M*X3P?;NlAm0jUsjA%B?_#hnKMc5}|bn
z!3bP2RKU61doNbAT0;Cb2g2?0-04Q7W}d^cslq(D7FnO%1)`vO-_w5zu71LI=^QVY
zq<<!TafSUwu>UT3>#x$k<=g*Xm;43H|Nc`R{fzcWhuc#)L!Tx71m6l#&l1-oidiDT
ziA=O{CfdiHO#;y%=TQLwMc494c)hf&5y($bkYMPl1q#v{0ma~{?;A7w?zkM3n)s6t
z(7=YtcoA-x$>6#~x?KEj0GI$?>Npi?CH^VAQll5X$t~pH+;OIeN7wu<+u=t)e>oLT
z>Q+&C)8|Yr!JXWAZCv}nCb#bF;>(#lNplBF_w~ytrO%N2pn$`_&vKDtZDKXjaM-_h
zu@c5lyukkwkEhaPb~NeBvpoE%wL*Ba(kVf?#o=2v!OM|9ROHM`neF9Oa{`@bp~gIU
zvY|$<^PjE*heIT00|SE;7K@?b;n1)!98Sm5uOy7FgDz;df1g6Jsx#O^8!-Cv(KCN|
zHs$c)3jLF+RS;eZG=afz2yq~ntCR-H4)JJ{?9JZLgD8s{XP?xJ`pwblaV8e_Q`;s*
z$tD__U`@iY4Q@lbaB7EY_(<xIvEmjK&b|4=WzLwNVcY(`j*Yg`qgAj~h3b3LZ46RP
zu7BwCH-Q-G`|sbsuc@g4(bw0HOHAx|*h|r+sSQ45E~t19cYPh7-wS!h<CZrK;Qo<I
zxN3Oku<1=ERe#*{jTU&LbBzg6(fD*wKfR5jg^TBi0yz5?{|9gV^y@AS{(!Seh~8m?
zl$DL;+Dbk7>@6)mRhw<cfWi`SmeVmzX1&F4n3MpR_uZQ8*lkydemPo^jH3T?e{tBX
zmc~o=2!V*WD2qjb&I>H=iF4DEit4K6PRh9%j7mV@LIln7DOs^);(D`!YmTbNu^*h#
zVsoBVq4ddzDQksq6|I{Tth7ybXGx+p?f5uVZyTiM*j4zH9&J4P#;DajXVTG*Vsb)q
z^K(tp7)7wi{L81KLP0@AY|B%`@8!kD#ty*cecc9P@s{n~AlAq$F+Hz~sgy&iA(V*K
zp&?zXa`$!B*!@sBsYq6}4X;t7Q;uiTH=66TAb%*i%RmGgz8v=!Q<z`^-c}*%Oh3$}
zllqlYDDZxF@eAmy`PX<MZ0r=9?LK;VFkX^aiPX30WWOWb1;rf=;62`9Epqsl^kjVU
zFZ8m1@Exf@YS<Y`83SG5RGNYmY(lBmpw*8dBRg&|C!8UNiwi^jF@Fri8H7zr*y+d?
z`ye`+cfY`;AoXu>x$e{P%qk`viMLv!RB<$40R;ik)Yw>ix>In4Tiu?9!IY~tTUP?S
z+xAJ9Y9lq+&>!sM0?x6nx8dtEud_424lONX9SFj%Z$!sB7?HI&R&6b~R(v<^<2zN4
zGP^Ni!3V~KqG6}f?XIUJKn<NKH@fAYaYV)J-{0~GW5$yn&EqB_0iW*!m&vSu!=pku
zAl$~$uOBo0ck?hPcaOk8zO5nyKVFfggSNu|iu;)R_rp$_dpu8efTwqh_A2D@tLG;V
zD~xTvHxi!H-Bx1{$S0nI^%XQ!^-k3v>UDRv(*Pq$D_%Y$4qL^3k_t){F5E1-HvAcg
zEJD4U3R9j>y_S)33%@zpGlI5r`vc>|TbGVZPsfOF>?cx(1(=8}(4Ut8=k|%wOkKc_
zT8)za6WrB}75k{8g~&(I|Lp7vE^~`2T-@QZ{>!Ome2+G$N+2FA#=Io{mJt2CN<?^3
zUSzG|ugMUi_DAOo5=LlJUppRH-=)QeFd_f2CVv2s{K;=dAXL2126u0FKHpToxC2jM
zL@>|l_tmIU=E9x*-WIj*_c-JQ_emerkI4<z|4%r#6xA_2P5b8{bwQW&bPXpi^qYJV
z1O>kP3(oxo)&3%Ff0Y_bys~sm6}CdZ;^l67IR#QqcPaZG86P?TRjR&xj7Idbn<KJJ
zuMV4?=D}+)j18@+Jy8PMTzrI5N_-RU&HU={;soj(o^3App_G(t9u)<Wz;19W5u?CC
z6~m28#XYqi9)qVN6kz*dh6`GhcVAQE;$rcQ4>p*tjvj9OW(v8By>!QL)i?H>_FN$$
z5S?B4Ln*=@r2qi1ImDPu68?HZ(DYf1HCF_)9`){_*GgA4Z#%>5P`Fn_;#z9ExfzDn
zAWq*mDCyO+@Nh8h^h)JwauCwd)Y0(<+-#952xH$4>C{O8mDRq_vCP;R1yY<o?0}g}
zgQz3mZtELOvY2s`1)3gxFaK78A`qsLO|zC*{V*(Nq+oz18Bw2Cr9n(j+dkBcFqJyW
z<@ucRerl3(u9>ZR?sjAj4f{?7$<uV3i8C~S=LxQtdpBmky(ps`=NZ@fbF$K;z!PE$
zy0fOgn;5*YiofWp6L>1d@Ht|AL$k0A{ri2!+bj!wLC|yy^tAwZvzfOq_sGMjyK1KP
z8Q)W83-fv)aiV@iMQ->$=LGtV$-c-Csri2-)+}xzjE3w(Oyxwy0w9?L`Lt-67Q$sw
z0Wd{4d>tm6^9XGr0sn&dwuOWYC)6F@ms)JUP>d3nQpPPx(?@X#Xuz7p%?Z9a(GX1J
zUqt@lCW8Qw(Q5uh<{-o3`CvfK<E0G&IJsQ`XQ#%fHhv#*-&h`m{tbrM+n?ONG7#pO
z`AjNsB8Yv2IWTQ_e5MUlz_SJ!BM9QuJ2Ja2x((kj>ayLlkXC%p7P{S7mp)P^eVuJx
zUf$hBqBw2ksuFA%JUd)dF5}+&rOcG%BV+j94ARf(RmZi{aBT(L>uamoKgXAl>dixw
zs@&HoIE&Pr$QT*mXlkAGG%q>wk-1)kHuW~qr8w{)_CdgBMnA^7&;q|+t%n9WrmtS?
zUfs~*;$oG}7QbZ`Yx|1UQH=B=`Uvb($z73Am8vv)P7a%~aIt!&1z}wia{^}glOP<3
zKb>^Bf_{BZ%QOQrOcwpChCl=S&75@XU?{P-4T>($T<q^?UxYdg*qXo2D6uXn%wMB*
zaz;5a<Nc5*H4;mkB+ufwFwaI8nkev>#<J2?(2IEMv>Z2q@uP6{&iBd#@w<U?T(ivc
zP}e0vskJDj0yR2+%kXA$u`=5oES|R7+(N7p>g*iJ#4r!GUwZiIScD9v6Zg*Uwa-p{
zv(+>mS)AOi>qC>Ot4~p^#+nbuF0R%hKGSr)w4^;#T-;bS@E#VboOp@zkn448ref5&
zbfG&*Da$LQH_rr@jfJ17;av{(Z>T$#kN-QO<8)KRj(Nx2R4~`!_7jsdnho)TG+aDb
zZuw*Q!T*@9+t7tsFZB05yf!F^RNup4(m7&0cJf#eoNXuyTd|W*=;aRM08CBQlo~G_
z+6IetYF<lwegSlrj{)eeb<1xF*5Oiq(B+nF&X#o(Swg;wsTB|_Ghc-18<1GtU1ZVg
z%oiJJ=HLPMDiLAMHe)lPZ@!7GJi*llub8I&iFg!+-mQHk(>|>tnvQsnGVT2?%OA}M
zNy_s@;woWCTTDP8d#r@s2QAaK{eMG?f=RXHCsg$HU~m9W#e^hJPAAegM35U0gZua9
z#-(;c2kmDlnUCDdRIUC9Z+#mw9s-k~TxouFQ0p3dl(oLtA)iiM%VYAj->R2<oyPT~
z<*aMbWN)qRc^XA<gJ<o;^ix2J>Ub_kjvD`+M;Y39z8T@YN{lD<b^HZIn<AR++ps@V
z)PVJW6_@@r{PEu<2n#*KldCCGvF}W}9mWvQnvBI4vnq{ARWB~lduE@*|4rg=ND;=<
z{OTefBg?JZ4+X^^PhwTpWoF$M9w0VSVAApXo_B6zKLzcWh+>_z;8UIipT8!Su+CoX
zQ;XEDz2j!7x~h$)5hUGB*L)$BfY7EE9NK#b`1I`XV`$chgDbtUvsbj*ahbk1xVP&C
z@`!n_YPEnmT?H>?$BD4+JmZKYlD+L-dFDxGxOF_OnZ@a4MnVRow5=PWH0$s3hpjxI
zUcl3;-BwADXzcOQ*~WX5mMgcv-b_0AJ@p~6?m=6OrH&)QUYa#hQ_*D+!og|HI%h0+
zJ1)JowhBu!XK*I81L@67v;#8`)?oLoymF-?npK;vH#4izVY4WJmz2_QVW8j9y<PvS
zf@oqx`q+i+3=a2{mqPa5@hm%|dyCK={#6W=kt#9!e>z3QkV$4Y5ly|IoNqGb&r%m0
z#+&_QVn2x8{`a`l{>a;T+%&L3=7;SZO&@%|mI?wPAFh+TXF>h5R8m{Zt<BZ-EcQuy
zTMl|z6_(9jrPc8^U}jcOEz<Ba``dOKm~-{%-95jWR^9d@JT>^SnFyQ)mZTS>RD}Wr
z&RY=aaA*NOeia-XytudsU|?W)TlcKHUrEqoEd7^kUD184S+DE6t$SIr3hxe9V+zjK
z#U&+LEnB3JckEzVYPWy4keEBWa5a*iUr~LL6ML@Bn}!-<Rx9KfDAAD&tvtPgY_<jH
z!+ZZ-u5DRMFy@qnqZS5Y(53!xy7>L27QRrV47g~nExIPomcGy@d8I`62erMc8l`6<
zb;wMhnMYs7IpcMetAliff*!|^x2o0|J*T@@yu;)5;w{4lxmL%1eNzT|#&SQUx^@}1
z6ID6o0$P>H*r}zqxic*%-~r;!9toCBP{F}&`ZbmQ>?{6z5(qkLv604YkdL^NopoCb
zNN3Ic^57(>m6gSh_2&v7u8T{<CueUUrG{}$XB2haEts5o?6&*LV2SZJ-!|j9D1R+q
zR(QVYR_g+xF~PY^YL0@eOyhfl1$oZ@4h)A1MIDR=q-bA%KAbt%Wmn$z5wBTv&di7D
zC;8~VZFOb7l16XZR}Dk22tXnE)@IA{%RnpKfmfgg)l*RH=#0&5{sbUOYt}TtK6kV!
zRJdXdv3xLP4l+C{VO{b#X^g0PxjS3u`Fv{wI1s)|w8ndJ1IKbms=v8}rTSXT$cJK_
zIFWxwF*@13F=wb8YRCX>h2@I-yMgqFW3w_@GzSO-A_gDN2ymHW<56GN#-b%A97V`z
zKAVist1;TW6rU|#X=5>8S}8P#rf<5wj$+Rq>fx)i4bO=>3;3JPzth2jy|P4~J%`co
z_;6}(!UKx6Njcvx!}d20+m^@4XwNYOB0bJ#^Ol^#W(`YfCv<WhK0Z+u>UG*4HM`b7
zz!w4*<6F+`V!gh1fgjb#y6Dvuigm2otBML`YeGumO4Hp)uF5)6!~zc9;$+i2@0>&B
znjgSyfE)rMuK~?{ee8c#c9mgKbzOT<1Vj{2Iz>991<3&<1eGpn=?19*1{fq1DHQ~y
zyCjCL0S1+!Ll|J_5Ez=FJHA1m=X<aBxxVkcu6O-AKlWbxthLWN_d0RkX-S=nbaL0E
z<i)ezgoBGeXy+coTSBf;H2WYsbZCg|Q2Z^+tG>bci+3K`a|<+!BuV@#40;5hopkb=
zq|pIveybplP`>(LxCoDE7GtSlWbjIJ3-Iv<u5bTy%>q}?%j1s5DCju^3}Tp(Pi(_E
z6BQC$R(LutN34S5^yYyQr=DSWT#z~msq56k&2WyTuNgdHVfP8c33xcXABJ&+@fPru
zPO9^U8fRqD<=zjy=Cl$ox8l#5c%H47#1>mcr+MTLJR{8$!Zc!bn|INj3oisap4H=m
zDZ%#kBh{MqF7Lwqx}V7O9|W|=s3FFZ@KfO058oX|;g48b6qzd9KL@xyb7+KWU=GHU
z9WBgHoQ=x1S7M&aPI&0~`L%aY@kM=1TF>a_$<{;pD9Sb&zKY$wu6E4%!&-@iRA_%f
zDIcjEV=1U3c}_)y$4;zmSUh$QQ2DYnE}ya|z~9PiVJ{%|fz*B$3k|XK!P7)#ujY_z
zl@UbpjiPc(sG5_!x@>VW0%w3n2ae+;(w=2l-(j>eD!{Ir0k|<a&RM*c>7MJ-yK3B&
zF9uyLj}Sl+l@sumlIOb_{g4|Y4^-tU9iP_csyQU(C_xAX69`uvLA8f@PnQM>^#v<0
z50wSh?(sHJLUQJp7*!K3><0rrMnySgZFs7X8UgB<84L8QG0}b*pM>Z&QuBnjxw`sG
z>wFyHGNA+#l7!(eN&}L=Ylzk0_umE;{LmLeqV7QHm#F>xZ^S8~k1dudtm@BIb~I#n
z_>YcfT02{R6`7~d)QXq{+HDW{-wk9B5{L7%F7%vOWxlQ?Qz-+LCxGH5c8Y3XnX_55
z_U;U>7n;>{)1nOe$x$VxI@6vquEQu>y`~8Vmx`!O>PDj-2~RVSy6xyic0yZk#Opk4
z5^PRYs(}3&Xfj_dgIA~Y4EQA^bc#Be%wYwu>_*{!3uv^6+rm>>5`e96l7L0qWN}Po
z#m>EoNF;-c)TC16NS1pWsRh0JZ43Y+yOs^C5Kys*9=xv-%n>zdY+T@{jRXK?*W6c@
zDKb_atzos*fdS>^6E&MrGbc@;rD=NqqVzPRDt(Yq0PpeO`zCwiqP7=CI0RXQZiPQ+
zd~XO-3ZE2zPUjAfjVR4aY53&LrTAl+IjQ|^f%Mt4q7M|8Ob9;PAJb&XwB+K5N*{OG
z5;e7Pz1PxO2a7YRBh}1j7?*^^9a=i_0+LtnlysU%s)iTrRTJhNKc=q#Jh?rd4BF5q
z_Ee)RS2$z>i#UC{b+<^QD^z(K=x9GMFTjT~49G7Fz}Y6@XK_9ngx*OiW#{~ChA}@R
zwB@yxM5?WqI=Y&ibY6N_S2cNc96zgW+iLcCQ|;*J*#?=5To~!;M<EkCOH?;X1SE%+
zsm5%UN{!zgu5%64ZVV4VH;r{`ecJ2^ONL4J?LvD$K_>~j#W{dhL(2s905lJqlzd};
z01SaZD9Fp_<mTSM#|QgNRY~C6KhgSD;yL|okxKG;U;pIRwjzP&X|&T5=JGX0c1ZI{
zuUP_hS}LqX-&bneQt_o(NA^5f^q>QxZ0??3NeWUEtV6jIn35cu=r;zMB?6zeAKavc
zO+NJ8<tx{U*Kb}GcT-N-L+s675L1{uzMN{9n)@-$0neVFF5all!Sob12SpUgGCD!u
zn(&%W1oS(f|3WSqIN*Yy?#Uu7R<>soC}0}lKu5DH8>Z#mh4ByE)M=qdh($>LVgRJP
zUL#Yh(Kt8bi^fdxk(qC-QRnRb?prAv_a?(z=BeUYTKe*5sPr$l2IWN|q1VVCtZx;#
zi5Tk5`;6DSr4U!d(i^~K!CIxMF;&?<N+UFQ%}ig7AJzgTm^PylcuRec<A74sh5P&5
zy&d{+ugg!roGaN|r{1pQPUBFMpyA{BOMOt?{q(Kqrn~FL>(~=`x_$)J<s}+ivh_bx
zb)HUjE$`&!Bd$p;l<+S!xPwWi)$eYLcM<bhcXdtRpd2W?%4YRlWNkl|r`)K!g9x%r
ztykV>tc$wJB>CPzJiP`SOLKYLRZ><QY{FQw_4(Bpsq%y<3ufZ+a>;%VIP6Q|jPsk{
zcE>AbTt=t9Pkj{-m##n*lu>bE8K=rDdD7Jg0-oy~<vr9h_7{F)V;7?<x98Q23(!g@
z^3UI{czqd7te@zp?ZAuw7P###AC`UhLZo7Xt~S>KwYk?Xor=jrDj;|(d<X#dTZ|nk
z$2NvC=ZO!$ZgW;JTyKCUPZf4PI~B6*eB^a;R2R<3x^h1Hvv!8uH08^>Id5_Wk5T5^
z*!IKp<IK6P)~4yrRV34spa*<%R@^fcU*p)wvJ^}UzTX$oi*6%#Dk^Np7d@Zzn9thl
zX~Ro+6Tv_~gjUhj*oYD*Clj~YF}1J>Frzv}e-JOME5?MV8eeeQP0@owtbWQhBG6Kh
zDY%qJ3&$ch(Zzn+h$vpe7kB_2aDhj3cRA48x$(&wzwO3eb+AKwR#f~4h<IG{R&Wl~
zBB$*UH~D6^&v6qq_Xxw(+4igc#%Fp{9-2$2yvC7go60U>b;3ZdA?FguNPS=dSd6Nz
zFLY>==z1Li)ngv#Uf_t-UVafF>nLnAKRO~UcblQo@<Zm<*^SG0c>V7;h6itZp>f#3
zBlg}BcZxOZ)<tx)4?_e_+x_80z6eEYzkB0`?iEq1%kUwG<!^i3E(iW)3>Ks4xB|(3
z{TG?>7Igt7WuiOe2CsDRVQSQmB!0Q-M!58QFt!%IE660Z96Rw}Szlj=K~rraIpPO2
zZUfpQw@7||-MKwo$@aO6pm0A4L6q`nF8pRMOI5sU2HA%87TKD*oDUNxo8^}b(w~|^
zvc>u?IYvP@pNcRcL)sn$X_GssmfR_{G~nMzOrdy!mKH6xM^@P(gMxw-BN<Zl@kj|Y
zQ2HFH_H7Ex&t>!;8R5bn;i}(f9w4}BThzwNjEhqZ4;lZe3;!(3_n>SC4ot{Q#D!>Z
z(g?a5D~6Na5ZuH1_&GXOFv%I1!gnh_@?+qE=4PZowz#z5c3~zl7bqld_*APOnkcxI
zO-?dJPN*GOrum5LpbXg{&n$dxGlA}NwxqXn*^^YpDnfrO(N(-tm0u&4@>C>O_+owI
zwa95M)nkWNPxmP9EPF|tq@M~-Fx~3h<WG)O7n{+(?}pGsTD(ea<$@lX+2y}<tar`v
z)d^XsHOv%mk)O4$hIWc9VKY{P-tr>R4|U}fJ?M#!6B1p78b}TxM#48~9bGm$50(VU
zItWlhbsGx{RHZ0MEek>^mx@N~H6&r^Cn&#Tao+1>jq25~TWmRrB$=<qpLi%C*Y*!>
z^8)l@pqL)%w5`3ykQK%fB4Ur)t|9CLa(^`i=A|<Y&yxeiZ%!HpJ8Op$){aPCgY82v
z6Hl-SSIqV}$PSr(+a!&b@CKLsQJ(fZTRc*|@nle`slDyCEh+@HUt%HF=rZ*(9`n@c
zb-K;v2rtnQMq+1-R34<1S8A?KQ(DWO{<KH0np&(@$*gyuyk?|xa=$OhunAV<BV(;u
z82Opv`o$JH(08Gl_ZkJ!AtfD!E%3W&E{$k;%3Jg0vzwWX6QGEfcQA%aV*$O#;4h%>
z9X3iNQ}o_{1XY#~^-j|oIx?;}!bzvzeECb1QR}z<#{=s>8ah3H)K<b0eWj@SGdv)R
z@XPNhI31v;!y~<kO&jx8wI@6dCaDx~dxhZTB2RY{C}G&5#TC~!xT|T$e{}{9-$ogq
zG96#H&FO>#`C*p@>_&{<tJputkMR|$B&)FF+h1^qWT`z_E{;|7rX7HfTn)$i2W2AJ
zQtYUO&9I7mKF4V2Na=*o+AhKYKO$<6-#GA?YsmQPp-5`*v2WBvfZ1Cy`ZjHuz*Xrm
z6A@JlSOHzZ6C6M;KifAWfX=P3fP%Ba70%!&5}uh!{%@a&kmO;T>Nm1a4r{t=ZDa*y
z2y4y*!nUb!iNn(P)9|#_-vM-?IN|EpcUVIk8uPV3oKPiMGM)HV?*on2IM}~h)+(sB
z#$IW*B%U;7*fC3vRY=B>Ng%4h{uL={FDDysT)<9GGSzIFw-5>HdS_|7dB>1`3h^@^
z->BzO{+Fwa@G;*xH?0m<rbC-OTA<0j$1SU5_#jI*KY`QZVbdo&95WR@bEhw@WYwA|
z!YhVi)0>)YAj$!mnQ@n)qZ-#G<=PY2TW9)C^ZO=XST0_i7Qg+$xAhXWIo3wIhpyci
z>XiY{GjjmHDQs&aC3Qj&YAL!uWYsE7^V6?mjbyTztIT>NK|0_k1qGe-gd&g13QD5(
zTxj>c4%@f39t%czmHP(*E!}jg!#)ejCqp>u1rtdxO;7M__uD4@Zw8=as-%h0I*f}(
zaqHC`iQadwc2GCXnfN}ox+z3ZyhsvWsqB~Le)v#lQj{_mU&B|uZ^ER^CUk*(b8hX{
z{W87w7Yfrhmz70+>{`xUtBjD{u<|~d+QbtRy7I5XF^FC?q)zqnSI`*acWtxk52lt0
zkfl1~BOg<RXoJt?2l-m1O{dpJ&pW>-fWYyp2GgtOtT2h5RLR|ULA$_sjMre;Oe8rg
z-Ld)Hu4y7)+c~rM*o?7tKn1Ir%JD%6ALWa&1cZwx06-9<EHA5#P8NM-wS^y18f7BA
z(jBvq>flhjRd=(fCPnP0yVo8*A8wB+|9rdkO;d>WJ}MjgfBLFO{fb0)I6E(7|6L3c
zERx`&S1|GV-iYIi@c}z5y9?iGbLCd`hWW6Ds&1!AM9O=1Y=j1yieJrWC0O~OdlK{2
z((yii`SK+>S;B6R1uS9u{A}iov<PP*fh^5Q`{>N!!^#j~7Ws6UPRezyrleo#HooiQ
z00)!U8vh171NsZ?DmaU2=r-NLujYHL8W0YDk>g@DSN3lIYf?F<4GQh;?H^V}2wFPR
ze^s)~ET?@#XBB^_Wx3=3`rC3TFTh+0<c+o+Jp``52Qzi;xVm>%A2us5AEJ)?5zF0r
z>0g4+aXNCxFi@bN8@lp?$75U>5wq>tz-q&L)(5m&u*B7asr<czm_XhD^MiZk+`3KV
zB3VR1G%~X4t?ZDSBiG!XO+~<9t&CErJYu?$-iJKq_AbE$A^2ZEc;4a!c6D-%Ied!U
zX2D+P=6TcV#?5~9k}vpbK^T+J=S>=G8E7p^00$3N#`bai)<_XC+(rE~1c!=h0@FkZ
zWCT4@-td{Jae`$rFl=b7_2SJZy43jB9B8W)W&LUsl>Zj_3`OW?pUTRXhiSV(o6g%w
zR`mjeXa_|`ZVwVrLb@AtxehnfKjrumERRiN^mhvDlG^i38)Gycw7<pE=DiE`?q=Q?
zjO$iFUw2odBj=_8kA*zI9Ec>3)yL&)AJ<Lzo2<Ea5ki+5R;6$}U^D8?w#EPh+Nwmo
zT|iErc!43<^zf_Mk&mq)6fJJb3V!G&opwc4-ZMnYlB&wC9MfsZbqW1uran4`1-@wn
zgy*}`&|bp}2}^CNz%-}5XNCtyc1t6wuZ)RPx&0k<F$O-q-_}uj)=H`vQO-dvK9#KP
zS&I*!6CM5fEj;>X7h`4$ufu}nejG412|Jq*1zz>D5<73gS?8TO>Nx5Q=ne1J;rwLE
zx33M~u%@IA^L7d8gE|c>f=wxq9VvSIqlhmKZ}o8#c7*IgSEpE79OF|9lgEE?WbSaV
z7g<6T`r5B*-E!J+8LALgUmry$rb&Vepoy~X`6AGlchq4Qv>t&VXM_v^&dn`qou+8v
z`(R98lf+4b{ziIST>3|=lmqXzIcf7Mid3O!s*Q!XG<%Q8^-6bC=?}11-15Z1>N0){
zcSe22_H$r4%$!|}?|cE$XkY-{v!$73xAo_xpEBPz##jTUaV~;JlpvNCpWEniWk2I-
z(A2{kep(|3uR6&K_J4Jf<Z^SCQ^k*8{)zshjvM?o+gYqvw<Y=D%guzkx;pF`RaI5Z
z&YJP@AzV(l`-JoTZp!d-o_Myu>7lEQmnwqiOVp^1jxIVECPUt*R^%LXQ&wjd&W?y<
zX5EMw*p_UZkGw68yIhjZPYzyguO>NAC(aQ|&2wD~Oo*VmD{)a2cPn^L%zzOdn+#$%
za@^_a4lcPf^#65Z|EY<yPe1QqH6Ely2A=};z30wAYhLe&!9RBL>Y|=c)i=C+U7>Pd
zpq=lnt32M!<TKMI>r%4h`Rvb*d)snlGWZh8P65w21Dt<}0T5g-@-RO>Ay4iQl=Q7%
zpG0_lno^|~zi@?q99LQs{+<o(0UshEp)TWY!^28K9`S5;tnx0&`QiVDd+q0kUJq0X
zPg}&V3y`J3XD@%wij_AR=wk0tU!}AgcHTi~$DE=k2Fo2lCpPJQAmmDxIb|H<h2^qD
zR6^7#$gic#GTXpijQ{L?JF}c)YEygQCdL|MzcYA2^wKRV6)3&=ri;KMu&Y07DLBJ^
zwa%GPNlcG5`Jo$$T123}v~<ewuL+?k{Ozy5(;9rgdnDpcMP((X*(*)p7X-bk$KI>6
zMOhMm@rB|!m@OaivA+Ly<;x)I#}41g?<FbQKAe-`950-;v)TXIZ^iMEw6t(rrGV_I
zU{*^c1=rDg9r(kL-vAbRMpy7JxIGLPvc%JT-oY=+oRNzgY-_PH_z$$5t+ALMO+Cky
zp|kk1FG-z?S$;9Yxl2h*3%eIJ!}6_Uco<FjnR-JAZu1#p3t+>omHiX2u$CU1=}e-(
z<lKtSO(f8Onqhg`l~yyY@B@QXlEszsT|uVJDi_|3mWfz37Ie{gWXeP~Q~ruf34-gY
zwhWnVr~T2_!$1$DJU_|))-h|iF7OA=ndkkMLd2G!KjL|RDQ^p5H6F3{7uIWi{+Ghu
ze@248-H`q@^uL-o@z2n|*7UdA|Am<U*Tnx=)8B6YvEqN9`0q7=Ec18?uFcC`#m8e}
zw5P?%ay5oUK>zAkzBa0tXi_n+bikI1=PCwS6K&Rb&dgdU`|8G$-@)<#KaI&5womOE
z!l{G7gkJu}#SORZ8elM3FYsms&xAyA&Xu)V3JL`Mo>VkJC3nzPSOk+N(f23P%ZJ}F
f|3wNsPR|+rpYePvf1~mdfHh?WRryjmv!MS0(Riy^

literal 0
HcmV?d00001

diff --git a/doc/assistant/thanks.mdwn b/doc/assistant/thanks.mdwn
new file mode 100644
index 0000000000..2b9c8279d0
--- /dev/null
+++ b/doc/assistant/thanks.mdwn
@@ -0,0 +1 @@
+[[!meta redir="/thanks#kickstarter"]]
diff --git a/doc/assistant/thumbnail.png b/doc/assistant/thumbnail.png
new file mode 100644
index 0000000000000000000000000000000000000000..346c22f025d262d390eab317de22acd3cce48f37
GIT binary patch
literal 3491
zcmV;U4P5exP)<h;3K|Lk000e1NJLTq007tk000~a0ssI2j63ES00009a7bBm000XU
z000XU0RWnu7ytkO2XskIMF-pn8xsQuwP`lu000d_Nkl<Zc-rk;e^gUfp8vcMl4uG>
zErH5ZQmutTEn!=cGSim!RLanuDgA@l3LaqQ9A>O-k2ouqmhLHC2c<Hj>5f`iW_QC(
zZJn{(jk^m4bTpn0qgI^_r-g#}1Fb|zh=jz1<h{Im_m7u^07(>#J(k1w<d6Hl_kP~@
z-FrXp`~BYg-V1a6`gMoHF*-Wxa=9>lp#Y&E6g)&6VOYYn+m>Q>$-dT3o)Df8LI|Ot
zlwwXIB&${Ty!G7DCzstL<~Yt~vniEIu~<BV6A3Kz5Xup_dAK|bY<PP$!!XP&7$!>T
zuTIgG>O=}cDD{(YR&?&J5GPNI+xidw_yO_o@NisQ+{{?$cMa4_M{tA!j9e}kiA1wt
zm<S=jjox7w%M%YJJfVbwc*!`&q6mmIib+%`UTf(WkByDZjD>-2gZjA0QwD%YB#MfP
znl*#PP(}oXAq)rwr4VkvIU+_v+=LE{a&D_b9Epiyz<_{KFg&HRZ;BWS5P$-d0R<!6
zd2>XJ92Y?l0U}btNqEEbESw*PG7JSn!1z7l91$a&14V*}ey2#i`O~bMA_@=&1fW86
zo+IL2OGNK{QD#<pMB?Kg@yF;%M6?4j!Jwh^w^ADh6(|xwdMA7Dzex8TG!&kQ4u_+-
zxY*%v2#0dHT&L4T{vy~eNYd_hkLYJ%P$C+gSj0iLXadSLjO#p>gr=I&8Ll=AN<1&%
z+KgBn1M$6gs_!NWB>=!;#p3uoH^L!_xMt0osl1$|Y;Qk&+blHgdH3L}wcjogSra76
zY2B|Aep85eOq*Z!8^dKY9|(%SZ{dNRna@<6^(W;38|c7}Y4ZbW16|JKmVt6in~yQC
zQ*?pRU6W}WPr3<0S@F3v`;-#~wKC-*f1B~lyB7fW_KNH`n+yR}VGLo4r@xu+k8Eh3
zfpqCxxYQgUKl%YHpnyc>(-<I01=|Mzk`;g?q!Iv3V2zM0f%g_>!FEHE3P>iF(WP%m
z%PpH`ju?)JIY8YDs<nGhK<4AO>v~P`V>tqe0l18?Qy>NyMhpj;N<evQ;f7@p_dEzG
z2iRd62D2E{2<5#~=Pw7y+j>qYC&*Coq&(-fthMiVdgps8*6c)#19mB3!$PUocY5r&
zJ_1GoI)p_FA&vn6M?ai0U_LO67zVN>0O~6KiUsi);mejP-W;NcC6I=Io1Ku@z%BsB
z5En>LH_R@?#roH?(<WkkeEf$Wei(MWeCtkV0Fvl&iul;ma=0VEq7Z=9(5P$tqTiuR
zj2<W~U!}-=6+rFJx0MxTe{|3c&Qw(NP-1RnC?%|h=30%xoT!c)c%ixyiZll+(QG<c
zUcO4HE*SXYpth;Ia#yWH;x#%wB9fbhW<X)HC$C8Ay*wryCf&bCHRc2s2~>-}KdtI#
z_p9f-dstb`?=B2oyD@%d*fC=Jhgb4c16SVroP&pM{O5waI9ID#_Wn+N(D`X&eQ6@=
z*8S<S^@EhP0-=LpKWoTeuQh63jvb`)t2C!Z?EoN+5>;&fQI5i;x5_k{lWraWlF}Zl
zT6bScG-q(iYX1Gw=#ULSRYQK;=CdDEr6kC4Z13aRqn4&)mLPC3{%d!><}cUZeo8Xz
zh+g~d=aBk{=pOyJK4<-}yGK3YMmXH_kCKv-_V)HQVda+6jP}a?)q8an)z*$$I6C@u
z+q|)Uz|iGPOiPplsMk8I<@Nb{YOTe!weKGn8gx4Gkuf`4QyaaZw!Z0f80G#wT7BAv
zoISPrv<*7#M*!p!B$jS$Y&-~dK-<)kSh`VQp<s0StL7<wG4KcMJ8IFqyaIL;2;ekn
ziXYu~bl4x(btQ^~PYjx^XA)Ze*7|y~9|d+8BhELfbJt((*Bp0%V0&ps*~K31)-z=n
zd*1lT%AmGjqA*byofuQ9U&<ToHw#rkv3U~IEq5NM>s5c=w{LB_psXu;^yThL+O53>
z-IwZ09ubr$H>g~{)oE%vRLz~OB?|?m;I_35R{+$#bMEAEOK>=g0y!!;%kHhcstbcp
zr{C|pVE6OcX$d{1Q8x7Gk+2>yK0ZD-H+S8-b+;dXx1264s?6*(I-2))C>!<ji^{73
z039vOtFpauxoAg4nq&ZMzj_tc?H$J!6=o*Nu_{x!jti$e+-a;W=Mtk0s(fzSroIB9
zS*G&U!-dV;wiuTbR%UvGW}wk&dqf)2BOV&$_l;Oqrzf2{XH8H3Ue*oEOM|@6=b`FX
z9mh=`L@QdaIb3V~5gAevyKnmw2}h3QeG%&h0IbhYWWDxPuaz1;v9|7f<h?&#4U#4{
zJPrW!Vq{nPRHFmy|IH?xFch{<Z|ij8WQU{Y@8=6G%Q6&MZ(i&jgW-t%<n|St2mmD5
zMh`sx;;H}XJ9PB?>eEI<E%A5%6f1aQuOcWMK-DRGuM^fbOU)}QpE-L3QYGAW&5!R}
z|C=vCX1Z7@DJkjf>>L^zx_u(<sm_!Gxk|Z7ooi%sQ@vr?(W37x-&H9bBz8CMZ|vxI
zBytn6iE{52MR=tX*t?}A8qpkJ=2HC|8|4LxU%$(3eoNtNJi+L+7tVpdDGh4c%$lFA
zeB$;0)s$w}{NYP)8wvnD3Cp+FJfxoIk_pE?c<YY8%bD+1U5a;e-w4^80?_VAcL6d$
zB^eExR@J?I4uIw-3#-18>HpR}>RU30!gktRfb_D{CG(k90KHBZAnkR!6h7tpU0tm&
zEgsyKsB=DCx9@9=u;YE7SO^LS&}*Xrj$3Gg*^-?6z1~Zf7k`k9^OoZldeh+zNyOaT
z+?tx2h^$EDzJd}^`WP|rh2E@4P4gYs)*n`G_}82?MKny^KYwldMi#uN*(jN>1jm9i
z`ZLo`t#(27=Fa_lGu7FEWRlTHt(t{4+H<VNHd4Co2U%kydFR-GED)`gsr|oi*IuNq
z8zkpneh7A0pq=4^uAX^Ox=krrZ;rZ&u(Wj7RULIjEdV<Lj}(&lU^yZH<Q*8%{W2-5
zD;C`Nayuwi>an{;tdxubtj{xXQuexAe2<j50dRt{;k;eDdnil3uqw@?f9tu7e>@x5
z1#coDmI5(B;ejn{{(JDiFVz{Zx6~D?s&*P~;ts>-h(kj|9UUEaZoS;n(vlsJVwzQJ
zHY7HGA9_jiK_CvM_Gz6hY1Iqz=6W^PvE+1pSG`tH_UoHEpsugT)N^V5`lhKyXSiw(
znzs?S2{fNw(>|-ve0I$ppa+5Ks=4gzq(2TVcIB-CT%d76?WT+Ll`fCr4?Vhn%79x8
z0z;?S`s_1p!}EGlzMr$@$xyaHaG8bXKdxvi(&2Cmn&4O<=h+Nc=jA-{RR2YrpzQg|
zlJopiu+GcNd#b0~A}BwoeKH{>>-ezf<?|1!8P_Cp;Ox@qrLfKm1rNMq|M(5B`o^@Y
zDqnHQeCQkgCZk8f67kbdKfUP$EnmKThBS0o^?h+`vRC;PWu--1YK+y@U0rF#=`WU6
zZV^@?sR5YODTVQJad|;~_nPWg^;-@qQB(;4tYgo9Q(;+|0w^pi-Lv0>5#uDI)5{UV
zEmrJ8L34Tx7q8Zx9-E}E_+-GaHU7j7RnCQh*0!tvw{v-5?N1FJtFCX?=2Q@->Z2ju
zqa!C8QVc~54qXUi3j|HqDE`u4T9zst2FC&gBSR;4C+mLXsr&efx8=tJ2eND@8d9_?
zM=P2Jye(V$45i`|4H<??xwffyau;^=oqXrs6T4T0ga=$02x<;}UGV^FnvJ)@LJ%-#
z&YW4cY}wSoFDNMRKT`=Mn>Sak$<6f;>Y<Fw0|!SP9P^*&@!oT>;a>w|fo>M+i4n4k
zMKth`1XiG*g<1kbKpTHKs1kq)FtShpD#^HsREe;Qh;9}SN^pLP(eT3a{2NDXzdv@(
z&3ZTw@$i)A38k3yME!X&+I)Kx$v|%~{nKK&fKwjC18OnaJQHdI8z%uNVhjSE!S*{Q
zp`<{T7{`5@saV?Z81sv>Pm5ulc*0~rB}R`2mjh0oE=B?-zyr;tiy;F}d4j_OTH4{Z
ztbXKSeQ~^^rr&)l1MM6RNyJ+USrinQ0TI6|;w9pruemu7$Au)~UHy2n@iC_S?6+#t
z;g&wIME}lG-QKSEx>(#A5yhC3+kUcgcZ>bzYlVo)iQlEE!1o;J)_lp{Dkidz_!uyB
zHohQ52?b%sH*UyxiHLdS=e}hk)@(d)^+oV+orsizf?*iZto*EqK=@7(JRNt6-;s{C
zvEK!Y5g{VOFkpli>VaA65h($spu+31gwDMf8}Z~P5+0FKP>28qG-@__M9KpM;03=Z
zd@43a#0bY6u~;l7gxt>8pA5q=pbP^MgD7S;dPJTQo>Cz?6UMt)Fh|75$+85wSgBMF
z4Gqog(`JT&|ATW81F;CvqFFdUJO|2C%7YS6g20E!b8@?R9bqvxylLITVwp@98yjmj
zo5#k+X1KF4@h?Y!rEeUu%_<_|O9GxUJQyA#3QFg^VWdQzq}cq!<mb|2{~wiyw0SjN
RQkMV#002ovPDHLkV1frfkyHQx

literal 0
HcmV?d00001

diff --git a/doc/assistant/unused.png b/doc/assistant/unused.png
new file mode 100644
index 0000000000000000000000000000000000000000..b0ace763cf159eab65fa73465d58c02de640b961
GIT binary patch
literal 49957
zcmdSAbyQr-wm#ZO0>KHEpb72-cM0w;!3pl}o&doDBtYXXjk^VR2ri9laCd0D`@ueY
zpLg$gXWZW%@1Hl`8qH{Wt*Tm8Q)|xoRk*UE6gmna3IG5=mys4%1ppA%0RVVfWca5$
z#=d>tPhYPbrL|oE0F0jJKR6%*2GP?^Bv%;)38WP`0vvdXlz`02r(17bB|f=|IoR2m
z*}DS7oXtMFnwh@yuyVD0Cnckxtn~$h004LgkP-i=?zwQd9H6dyolf(>ZB$N_%K?nV
zrHYbPn<xTWm4WIe={7@mzxT?Q9^oFz%Qtl{BaRYpEWgR*6dIfJH}7OeI2M|#>Gh9Z
zn@3oogHZo)ui^)S>jX$R?8GflWP(yOO}|d!=0{CYs;26t-9(U$k-e@CE-x<+?g(71
z*bwfSZe1nIJh}Ei2^|9J)mByl$e%AAxrn#$fBgsA6Mw#XIMTzOFDpLm=Zgspl6TN+
z^}Y(i6iUj>wD|tlLrrNXr?XI@%j}U<ZkBn2c&Gx)#l^)*>oqBk>+@ha8gerZZMWO&
z>oze>zXdM4i2oYYlC#%7zJT&r4)V+Uir(d4O{d4EDhygvSQTJ@f-v7u{MCIrF)f0i
zz~T%I>v;|n`*MoCw;|vEnx72@_^*EC|9QTw3N+6n7^f)y)mk1L{ygC%5YF>J*nfBZ
z`{_SR{rl<PUH=*Q@2>w4;=gwl|IY*ek8}E84g5dP>7S>6Gw1)ei=|IeASz(U*;%m3
zCKk;f7MjG(8?PhdoId!KdQf$C;B8QZ@(XbQQzjT7g3uXXg&0lo#5_8Boll>np}eod
zOTih$b5#^)3$<k}dp(VpelIZvdAUfXA3WF3x2_gPuI6ssq+;{L_&tizfAO$REN>I0
zz8Vz)xSH{Jt~rC=Z}7av#{S7zrb*;e<#Y`4i8J&OQ&{KVz$@a_@-z~_S{7N(<HS4d
zj4p?sy#<K8HR_PRG}?a66a6GpdA4B5qq$&<DZSKK(0$+1MAUeVU0R(DxWn_otGKw^
zq7*-!(&_iJ)LGqe<^uu?hmP20XK314*9o<k-m5h+!*%wC&embk13vFDS4l;@Ku2T;
zyhEk~0KUSF?`WGZx%zTv6BhyiR`9XNc>--q{xk1gEJw>!b<<nq$21rOg3GGyc!9o5
zE!fhp5#dC=wxJO};D3lC!y_VO4dLU5j1M4DvX(^a_=?!3m9S$Z8#~db6t`{srQ3cA
zVF?apC<@WueF#YTAA-drD4L{b;Nl(Xf~lppRCB|NI++{zH!%@Z;%!t+=-9dIMYLR)
z*q><Wb_BSTJnCGr=&i!git%9t#OE}@*U#vSnyHnW^+8Y#tzFQ)Xy5@xTpjf`spSyM
z{<zStY}!B*0u~fefkrZW%b3<e178sDj^>tXdMSe285g5hIiH_Txt*FJ8z7iP0sS&2
zM#}edn2M$B=b79=`>91;HDM7(88ttX$59nS4ju#ry5jGJ_SIIyOhxT%`N6%$fpwpo
z`<#_W(&RXl>g)Ez5|W!h#Ya3(!osRxC|7J<x<eyn5m?0PVdnNAxqTT-1DT&Y;+%=x
zvufHsSOD)w2-g@P28O|MY(RrxugmWkd@jD+AHxJyiIHVLj_vs!9V6GnV~dMz`17QO
zDne3&BledD5&IMy>eH`TRw6m0kv=#s`7n-eV@ME`v?k;X2!PYnN}Nj-6SN*7#EYOd
zQ>%T|#kP%&32{$3?5OWAMFj<+`lH*RIKlBAoS8rQ(K8#l?*ZfRTVdZMX(%4c$~TzS
zQ0}Y5zu*+;V&;F#uW)(TE$8A?8zl-T?M=NiNl?sJ1FK(=JR3RCo{ij<`;ZqPaELQj
z8Z0HXR7JqK$V33faDt>oZ-I4eY)o930-+gl*w<$hZ_%!=c`-5~cGAL2{mntSi~1|h
z_4CEoFY+%!`LW(!As|>FrADjosDpSooo`ym0Ls?3$7MB|;$PO*it4k?fsZ3a8bcM#
zG`w|8G|S76RqE4~2YKC}CsB}tS;wad(uoOCL{`Ce!k#FBxWtPdz8vsbwu_@C{lhOm
z3%qN@Ac+|E)NSq`vm?W~O!)K(-{rEpjHwku@5jhUB6dH;0eXCR1vql!j|~_G4uXmg
zpP5+ZL3G;A&8B6UwT#js$oDF&D$4$v2VfbsjiPY(KFA+uu(Sg*x}Bm!V(qqT8!ep3
zc9<-`DvW|W)2HU{7xmJIA*3(in<tY=Tw?++&*t~mIcuAJH}$D~quK0+B2}&FB%6MX
zx?;y^ycRoNCxyOt-pkEnwq}fJ!YQpkyFb0-HM3jnd5B?G!(Q$@^{eFxphxO#$)F(W
z?DG6qB8ZOY{kdxbClSjTD@`?f@%jNwj5Eu{{_Im(IyIO5)(ZB5s`Ki=XI|x8*_-%-
z<$!hWmk*|hNu(F*pRBvpOrXhg?x}~+Bbw_`KrE#uihtN=05B{-Ny<{PEn?YSZoO_=
zZz8k4W{|DlugYh!utAH83q>R-x7ejtcsAO?PUCY4gYBYo-V1WTQYhrp0TW>^9$&6R
zg|Ppc<=ZUXmZ%fL)Uejd)UQ=4fIlB(s@faAdp<(u98huEdL`|ZFywN(7mkk&(`8Dk
zi|F~EJ*GT(mOQo0`qGyhkhnN)T14X3jNhPZc3pw{PT?x*3eD{nJMBwe4vJcD-O1{>
zO>oQ5B@1;iwaFm2TT;}muane_CSHA0S3MJrt_PQr!6D-KQB(#bnvhjTAETym*t7(H
z7(Ki~@JwnQ)5(LwmAY8|d&nvoY`4ReoDq-C>BC#ClLIw%E)BE(XTNQAr=zZ46f_eS
z7BID8#}|g(fCL!)o*;W$v4%tQ?Ya(w33{FPG7AkWUidzdb7Z(~nCkkYn-^8}ehi(o
z8^aVAXY^s&Jd)q$x|I<diadPW`wmXEZD&q9m-(2C;J)}4Sl&`%B8~kPO`DvP%$xF|
z5vwiG_JY%28;G`gb&YvR76_s_R)(Xum<m8cQx}w1(rob|LCL19>?*2mixBw-#_W-v
zB7!qB`_=))dnO@Br7DVHdabja!fGCYqkX%T={4PK@UF{!E|fL64-SSleiSk_y~X2A
z?FEBe^s7ID-i2dvlyIXs$ET*){JrP}<C3~)gG0FSRWQM#aao=D!u(N80ON_LoWdam
z$auVc_+=qujl4}#I3fV?QK)rq!6O6l5r+Xgp-Yn{{PRbgv8!%yh;3y=EEU|EjzVF5
zALDdV&<CGxg`gmu?29tMOG$*P7}W%zL;5QP_z#i(Q9^rMH5@N3-|rg3yp**Yov1gF
zu+lQdwG2>)Y6EPi%}f7pjqD|=Gr^C;Fnb9opDU0WLYt=6pUI^UzTxhc|AiFC-nCUL
z-YB2T3so6ClcPI{#>mtUufzp4RiAs}^RLO;5)qLyN|zT`Z-z$;b}MnY`sQn-k>UiR
zbd+}wP>UTdC*K4}qFz82Jm1T75)?=-v^n2gZj2-@@U4Gl?G@(bJC-k(bH&WiuY3Dn
zWtJ9hF5|M5d68ZC3_h#Y*XA%}Z2qMarGRr`a{#W{BEA|GO<s{6QC78lDuw^`#bxin
zpHtFcmiLF3S4Vqfcv|F)FN*9-<_UeA>YEKy_Jep{y9!O8Bvc*}tN0BFR$e3ii8iim
zMh6FB2_o|&_?1<83^nwIt{6BV)B^7ArMf9X-$fgFS60-xa70{SdyXi`bxnFWvF-Yz
ztjQts`4wEFMah+LnP~hi*p{t}wO{VdpSWyzsMMl4R|E2|DDfc+L=cSY%TN@4XX{W@
zLpVmZiu6a>B}OK)b<AM2$Q@`llj3S&cl2J%2iJ1<jL0V%;WXFPXCwR!>h~f>=3}u7
z$MG>S$qV>gY=L=!ycg6e^);=t%XJRs)R4lM_*E&%>BOa_L(BA2igm(sNhzZHp+H)!
zfWpGk;wm$T!+Z%A^|}mV!4*Q$-Lp|AiarVv+P2v>$xthqPv(K&j%7@)O$8W7X!?C#
z!_MN=cgH$G%70t8XHV2WdD36VwU=E-{`#Aymfa-7;k+&PZN5M3k0ZzHBt~%J;yzz0
zJtzFq%Er&CpE7iOMeIi-j)&(%0$!DOm1m^^o^Rf_x2q$xdiexhN!NkO4K*Zq>*%ld
zH~kTcupR_k#rpM=Ai+7vZy9II7Y!oKA8e<;3j;)A-yz@DD)<eUlkklZACeZLMnxla
z35iR@TW7HYwd@?qD@ql;+xDc(+QvNl=7sUEq7+9FRf@l?wAdwH8I>s}ax!u@HGQEU
z4*PVsrpoAoYsy`0ReTry6faCPX+DKXKOS5tUuzc#o-qp5{d{N_R+Pq~vP4V@Vf2Ad
zipBbwg>8hp?x8?sq$7$uj&gRAJL-DqJcua%PJl|1{DWBF$3W5_U0{BXUZ}-*^-v-U
ztya8AiF2XiM=WG%z&aJ+R0dgY$W|AFs{iX-L~>ODznBnpNOS`-B4ya?*ZK)~L=~HU
zeU#F%zWmd}9eSbiW@^(OX-}qchM-Kdd1CVN%BJ+lsa<#zb;HP^8AJ}{q-gsIzULc5
zpk1{V^w|G>R~G%e6+M>*N4||bC`W=ou_SYM4{ZBg$$GG@a!M-rA(=hh`<9<(r=J`y
zwhE~y_v2kEa;}>a0XZ{ZD-a*K2R1vPT6XliF=)EWyZo=wrZ&V_Y=)A;jyv~$_~5R+
z5~qsaGnzBdFkDtGn<#_rKfm$Gc=K_g2UCiCl@w_NEcX@v)${LAt89ZKo$Ni;lbt2k
zaru7{ez|tf_h9KM<sbn#rf*w(mQy|a<i*fF0ubdAJmQGj@%gL2E0?T#P4i{s=V%Zo
z)_s_<320kJmb3gQ`PnUDm(&0KpGFbaN83tR2nQM+;$Lw_Ht~4b);8%}6+%b&P~wH>
zbrbgqAL9*9P>}v(Tcsw}V2nOb{)4^q#;lH1!dvSr{vB0YtQ_H!k|I%w5&>qL&!w|a
z-^CBOqWV8nK2=fiZMo`h5Pa==;iw&nHi1rc*8amjsd+DFcaM;Wm;}=*NVO5L8{FaE
z{oSlV!NeXexNhF^gl$D1xNWDawzj|T6#cF8;^u9QO5D}*W}naO!{t@^@aX>a<>eJ7
zX5)q8i<V+3yZrv%<`u~}P1>m!+HLWu13p=aY4$5-wVy{Y$LmFz*u=R(=uc6~OMZ;Y
z7^x^X{ur)#ba=||cfF(0%yuOQn`^3mBhdK8H%}Rmr{F<p@Inxa18evP=$*tn%lGQ=
zVX#6vBzn~YG_muc__)25aNB%2nI8{7#2fcxA=v#{ta(Qt&{+XdW@jF;Xd`mR)Z~#d
z(P2*wD3J+~`+6KWk1R;6`D1Az3mAP<!e+m<vibBrhY1<-pc%D0!2^`j+3>AS200D3
zPPe9}tfaH&D%#Fo<#N5V?$dc3-M28g%Xr;WwWbooy<$s(7#CqYT?^xjMrD&SaGy%>
z(4mvZWR1`69F#EQ4*+^6w$uPRtLIjy%zv}I7<voOX*25Zj){?F)LJPmJ~`n89>}Gi
z7(h**W`7>XRffK=7_8T?<yCLm{(}xlIeV7A{CAZV#hZ7uN<`1*OryWU6L;5k)o!9+
zX_hd(&$TwcfOCrTI}T?g4YY@QNsvJBBf`5+uKv0;3MRa7bj2{H>JDo2nWTsjmT{m)
z9fhg$%PWj8d=V^yz8H1nJ^h-eSD)%5SSV`yd7M2F_z|A5DX^>;#7Z_iRsS6bVp;_U
z-G6)e`0)*s_grejkOgbb_?e}YLfwQv<yH}<h1TrvFxc;!u|1BrsWdW^*-h^HURFat
zL2VcoB8>b_onKGqK6#|th$44q_2(@Ya~=tj>Y|4dEx@U>tUUZCYz<0RD7R0fQAV+v
zv=%>_P~2q%;1(;tEq|qClx4%ihV#Pl&)H`H4YQsc*lbmQ@+Mw{0nHFY0Uaq6vpMt;
zCkH$5<LRQ^w+N7;NT%Ss{XU(o9%W%7vuoUL)y25(mEPUA^4}i&<>w<brlAKM%vCwx
z^p_Qtvd|{;rh^wK!ha9N=zN;m@zXIAI#a@Q_woC@yH-)ctvQn^Pl@xyKws|r7TJiv
z;HM}vg^gH1hkNemDm42`K;p9U{1htkxm+jPH<7KBiv=IEd=(hmdRlk5iyer`<cn;2
z`3oK#_H=ucIIjHv%2YGdEU(=b+X{AI^5+HhxtL3kd}?$#wvz7xmYq7$W~zbc1RKD-
zGqYvFex?rNiYq;ARhFQD`N*nuj!B!T)uPzP#|LpSE>u6~<TU{K6#iJccBqJzRG5l`
zM378$b}fU;qjB$sE_-iR8M&Z&jM;!z62gH=l3A7FGxo`Q>=L=2Mpr*)j4q%^v(R<G
z4sOiRq&+~qy=GgU1>?H@D#R3Z$_k5Z{^e5Kk1m-KXU`7Kw`_~9g!$XAzW#Y3kZn13
zTHAK<{c(v7P_Wp95hIzu9S3nKpf1+E*8l!J?KlFsuW)BmnzHNWdjFM)#%@PZ;_#@S
zW@2_4hhH-r1-Qnho=UQ#*aLA&<NxVNLUCWt-JKZ=3{~<|>%VIv^nOruDY=rbc={|Z
zE%4x;_PCGYV*yRd%q^~JSiu=z72}9o7jo}w@Jp&6XU+7C7n*25y53K(33+-=>nwSu
z)l`Cuj+w2Pk~DZl*9GL!Q(4ovDlEvB1uBp|F;CSRK!h_ea(!v%hpph_aFuKj^V#A;
z*~r@T9a#0pHCCaa%RY3rXsd^}0B2`GUbhb(D4>t(Og)%kKN!c=h)%Ecw|2JvFhkF>
zt-u?U&*Z|cX&pNX<w<9=TZ+SuOy}i$it&-Y*P8<n%F5P15s71BAyUE>PIuPc%vOG>
z8O0i3+I8IhJe!+e#SD*zmZrqqzh61CKW@wp_a-W<tuy0h;wXw`5aF>KE-SyWGdt9z
zDy<Ff7PUS_)?^f;8E|M<yXaO}5tuKuQ3Hn&DhPigP~L-|*^dWD?B1NREdiH1ZD9C?
z5FL<~`5nNcnp-lF)mrs3U*j=u`+?7RWqDkkZpzZ}*9v?GFKL*amUf6J6JM6M6I1z&
zo(~CZTH<UuUxT(!%1_Ow51n>-W#yAviC7s%`Uoe$JI#O-PDOY|+e1^Bi2aBzPm;yG
zjh5hVRxmabU2CFn64n+-8hoBg@X{Hm{jBBZ_u`PR_OKp-hhLx=RA5a%$WgJGy5^Y2
z)tzod_uB{AS;r*-XD3ZD&2>mG3*{e5Yb(--DsGer=*G{&O3PvmO{?|QR6z=@CNJN(
z@F&Wr>SG{1<xVU7LUpato9{xq>ZLI6F{bPIGi{UZ`Zi)KP=7&&u6KJV1L<p6Asg;$
zF9KBz2hlwvRWL;=!Yk6ZBW#368IL!jfhMP7mm-(yZ{Y!wG!ND2YHC))!7M-K-~y*j
zho`i4-Kb>I6?f`h4DGq*Oc|AwtIxO4yG)YF4AsM*Vjc$Zs21Vyvk=<}&&L}|l}7ez
z?y8c5sw2|6fDMdiD$7&dG}rD1JeozQqA7tKnsndckR`II-|hGF9Xxvx#S2ZZowSAa
z!HpbZuMibos8yXfa30H0QXUUL{Q$=)sG+9PhohjuE}ES1wI%dj0jCA8lfib6?l!ze
zAv^2NHr3FX`0vlYcouRAK;C}MBEzE!1)>_#g|g8#8?d>j=bHsPPIJL9u3GeSTknuS
zb_Kk)Wh52_xwyDBaE8d#7Gv{nHIZI3KPKuOAt3uLWx<~+g6yd}WeVEIH#q!xb}{S_
z5F%iaT;=v#Q4t5Vrl_$}I`f8wF-M1cYPVa}y^$wMlWZ86Vr3kX&O|sp0;X}Z-RaCF
z;BSJUM>!Df*E$5{x5=9DB3qvCN`t6NO34cxw-k7V_EUA}5DSnnG5HXLs`S2U#<r%X
zz5h2^NH4g+qr7ziz<vqdbClfr2e9>CPVG(q&8Mu_{0s#7pq#Yz*1Wgu$%+4gD6`vJ
z4GG(PZG$xuUS^|p8v9!JJ<ae&Zahnm>FbwCpf2)|f+sE2bwL&8lYL4m;KTvc@&jdC
zEobk=<;FUC#&2h&eXcuKQohb=1RT#r_&4bV=AD*ze<o?4J96SLA-V5g8m0Z?`02uC
z1!|psyHvGSReAkTILoiRO(NJ-(!Jzb8tA7TLXX1fyPwK;9u++r`DM~>Bw8_41>s|0
zgMGj3_qvqyX-tnN?r%LWGrwOV`MePCv{n{)@uO_`oV;uotI)wEdtI+EJaP3<XFJ)m
zbw+iXDPFTi!}_p#`qzE4UUzr&BYw<*fO7p%UxiUYltYlfCHZX|c3UkHGL8M*Ck~z!
zQ}{pUEKqL)O$?FOL1$uJojrYN@d<AMN%=;HPK(y)#V-u&B;!|g{qpn80F<mNFIb7y
zEraq!)yxZ>`Sby4idxCpgR0pB1zrHG(h2#r;_39Gy2S;hQGkB;#?Zd>iUzLz_XJj7
z>(m7or`H`-6c7-~)UMG_kc)NjU6tmF_M_tt2W$0Vn%cdVhh98gjLt`;5*zR*v{1M#
z^%78_0R3P!7jv|tZwr2^O2_-(btAX^UN5K(FltIfEY__#I9D08`sQQJ%tlKzc*`L`
zzBl!YX~#|?u6+7^^gb_y1)jMV>9_n-zyDE<B8X16Knftz%n1Q&*5CyOkV8K*w>xlD
zvC>dSq6Y>rLa}L`7Qk1#ZB@}?)%+zDwM&*Su`XkJuk{2daZ<a5NW;F-e3N=)=L!{U
z--dG(nqD{qYSIbhBk3?cX@=#VGheI+-V5T~mS;z00@JO~#%bT-SR++k{g&3J<7IKx
zoeu6%Ug4c>Y)aY4VLT|r+pm?ykQ*1q=rCd{p`(w9i0@S-2Y}n+&2b%(&n;d2oeaXm
z3;f;j_T}|LK-+#>gB-f?TH6mgz<%o!$0;Q953F<B=-K5$S3YMFm>0apDQ)iaIvDVM
z8|gbwQ9V{0qLcW!+f@S@Qf+<TjYl&dp$EdZH7F@!C^oS><Qni&YU5b%pxD6`po?@L
z`av)(%O$I%n-ifx1&YJI&rs&f0dR!4QTV<B2X%{?431RlGKpw=XkjXwH)x;RkOs=(
zp&!!<Af#hSfu#5V@eZr4Y0;bd5^(*rCu?e}>PMPHfpiu`JwH#S7Xu3z-FIYC2!|K`
zO$)OzRRn<3I!9Mx^>NyPp8klFN`l)IiklAH8`4W7Z>-M+H82i9YOaccikEsGW7%8u
z7i3=r7SasUw2aq_GWA3FaKK6pU%5F?7_>n1IW24@b{f_d7oU#o@C9pi7w=kWS2azV
zAnj@-g*L*<v!lMzTzOA6uBkik=baM9rINtP2CJ++;QdD$!bK0#szd#U!IBh|PLK1=
zTYC?q7%6!8yM(5=`jm(sHE%hn*!Fi}ol8*@SUA*vEbe{@p0d5Kt#00F{5{Oe<qCLQ
zUPOF-o#v5oEwuM_w6<)EcA@D*+?fLikMK>ILhdnkE@x58;fU@XOp(mC$WB6{V3GIG
z{bd$I4XN;?vEnLk|8BmmN-6o6<ABPWk9FMzZADR1I?)Y8*H=+*k(Sx1buWJIcdikh
zjCW*ct|p^u!^eU@F`Sh8{{mju*1I<O++7o&+qkh8j84;^q;2TwPdlkZ`_`)r-Pg*J
z%XDzXTMedS9Phc3^Q=onRe2@m>QsOV^~P3hX<pPSND-u}*xA}Ts%x3@eK>jlyLH5?
z&+9D?%gGCC-7lj(xN?dOw%sXXIw=P?^kev2Ky5QX;w4|qv;m;BUgvszQ&GzA{NifG
z)&g$gPUGKMhxT;rFIl*-=K7Z(klDyMG2!7}0nkJT1Kba>zvP{`Ye2C@-XKf=0F(s|
z+M=sz7a`tIg}ol+ECf7f3?>^Cl;n`5KOh%M--|1Qw(~tG8x5j<yso`W*Killwvj9T
zr1&dA`Av1&w`XNL!Ug04(BHuey@EHwcSa6NsTysnxm(lR{pC<K8-C)fiIZP?WVq!t
zK=|ZCpK0O{^sa;4h!8n^9Qgx^oN!%%Ui=-L1`nP4;T+tb^R1!kk>9RHD`G#uDRCZY
z7pb0JEXs`;_4^g50|lwh7w5WiE+mFqe+eC?(H(i*fwi!2Q`t^S1?-^)kFYNBWzLm!
z$+UgPb2&PJ(g5v+-H&;4MS)w(l9?56V+W?t@Af}9{BTS@K4q<Kcs^dgBi=nAMz$=*
zI5Ce_<i>ig#1g$Go6ARM)6MW+dJEU}Enz0E4(R(U#GcZ3HzdpwVI85l_Otm=5+Xnn
zjt>KG`OS^(Up4QE1%;<%3F>olBB$=#-=)_7UjF^34*S1KUHo08)nQL)I{60+aKL5v
z-Ci%fpU6c*3m<EXh4g6^;@p+0!wz&^`c$Z?vtF9NuqQ7|E>0yPh4iZTW@2L}bI3;(
zpXWrR>H2wX@F9(b&xT%qHTh2R*EMkxLsO$Ec!Vl7DfhY3z5GWuGQys2-qmFQ)Uk9o
zipDLP0)@ic(=)H-Q9h56lo}zoV)$uQe-7Eo8@IP5=C5-3t9%KGgGY+UhYqUeWYGVr
zT%H50-;+Fkz+?_MK`P(z$ML<0p!IJ#kHefN^|I{GbX0sU;ZL}E1g$8vvr&**`{y*2
zZ0z6&d-3D8uu(vL*J)byNkUUHf3Z=R3)y361<?_iQ~V<Q4omgZI#L0=Terrl`FQ{i
zNQRg?w(5K;+%7uVbHluHqgkDzH4maY!OxSbaWLayLE(F!I6w7(G3Kdm@CX#Pw#VC<
zCN^JP2gW|9qV{i7XA1oH0yzEdSsp8(3I}S*(cbrXC$sIh#^(tI=_?hPK3fMn2KRT3
zvwFhbQd=q$tI+fH@!i?XWbeD=Duyqa75>+WwNjnn(Zrc^9&@{ly9|SCWkU~Vg(yYn
z=`GF<2;lp;WD~MK0sH~m^Z@17P<i13!NGdwY8U(hV3oatK*DONEiHBboEj>c_KQ2<
zIE!Z$<r7k&jnLom)@OkC4qU#I=`NU=Rs{QVer@U;X?UOcipW4_`KIRDqAUj5sg*+d
zAPWx44A{k?k0HE)PRRiiq%u5jxD5;Ww*2)$;WeE%3Z-)j{qeJ}$jyU9_FG}|VZ(ld
zb4;+j#UB-bNV7h!!Q~IBeyBALk2mSpPMl%dtaAD10dJEcSHl!=f8_;LzZiX4vD`VL
zZsI%Uk-(+YRxm4xP;+9+=x#L(rVQoSnsIifOjIS>r{Wx(p;{E37i7nX=t|Rm%>cMr
zUTlXtv|X3M+Fo~P5z=porht9J8md>Xinru4@woEwseGnlqxLA;Tz%O`T<~_HAJ+D%
zV~pRhmmz2?xy<KoMh=ofhOrZFhx+O;P*RO<CwJ~(dwA~#52&yw=$o-K6<}Wu8aK(>
zt$mCJFg7yCK*D*@^aj^^vdJT;)jrjQ^<_=ImP52;r3^c!g10k`kNRd?D2AWxFFHPt
zRT}OS_X0x&r}b18|D#9`--D3rT$lCC)c}U=?Y65)#_b+q*n`yZ&F~}O)L?wed#~Wc
zO338`Z!vQzl&JyX*Exix?W$GFpS$4p;(jQ@A3A~%aE2VX+A8Gaba`a82jZ9Qsqj66
z=+d7=YMevjPxi=KeNa~(T^0)*4+K|z`xYPO2&$}xjEQ<OELy&9Lsm!Do&?V4517p7
z4=Ulj>?-s&hNb1h1!QSE;<Z!3)u=97W?RD3W?;3E08;>p#bxusXKRzYAL2I>p`h!i
zA>ee}3+lIV_&JG^);r+BvfzJG9|_~~`6Ik<W+Q(Cy3iUJ8JYt3lD6JgtOl$d@t-W-
zzHQtcS?_5iX!j1dZ7}$i@_L8T5Vjo|a7z%w=;gP*6lv)5$3zKcxt$Q}0b7C;F>PJv
zjd62kLl;Z}ewoD?>%Y~ZU8KMLsFK8fbE?%&dtuZ~w^IS|h0V_jtro&U+sRg&KB?$M
zU%WTJ!wV4c*y+@j6G~FL^AoW@oQ%|ATQ4eD*QHp!ABa4$YZUu+j(4E1d)&fZe>;-d
zUh67vMx*hqTSFnk_H(=;l6u;9bxG)9U+L$>sLI0#Y`>G)@*RT=-+-Z+)bcs&6Q;-C
z`kW030?iV_f?E}ZOM`OM*b~-G*e9TNp}I>=@AG9>K*c?b>9Me1s6sc4nQ@+nVgz;y
zYdO7gQ6u=40sGV7P$;lpA*|g**W`$I1B3x%mfS7wDim49){<BEN=SVihZ0F|ns>y;
z9!5`3O)%|mClLz#AKYyd9Uf1C6Z}HWxoc|^%|bqBw>Rl^7SP)|!{vKko9^zh7PrNr
zaQTCNRCY|k%ilPdqw2z^9<T@VoLC1bdq2<Xp!TL&w$le2vsA3cX6H$dr#xlb=|yrg
z18j3O0Kel&(K#MF``I<_8phiFhRC!8&wGN}%lvPqV$9?2vzPVGzd;}avtj`1N3d`*
z1LVE{PQDG=N3^h5mnvt9vJ{*teIvED!JpyzK`rW4z^1g70Vo5$1Nf)+<on}AdV<t3
zc#xp^6^q;r<m6cI^^R%9?^b^=j8%+)sXK9j*y;-fg~A~&vl0d|R5M*Fe%f=F?c3P^
zw~DQ`Z%CPuO9?CI6+&n40$I2PkvkG0_T?Avx5*6s4p!}2*?FbLINbLnnBJb55-bbD
zcAABnH^M^$bRSQPc2?W*A3S?VHHAFbNXo6xO;K|n__EeH67>a5xy{j=ZG+9UzB@D;
zzP-P(@DMmVl_P^4vJ3m-bs$|-rXIIE>@T($ynY6DIO%c_hUo4A%EQ<KR9RB=layBP
zScfX0f7VFQF=GgY?rZPyfKsjep<eIq>f29l8}?zl?A1{Z3k1h4?XJhd%QaheSw-~F
zyOG|-t7C3+j3sWH<ooF_tBFuvEZFXTdz;Hu(Y<|*ZOZ-rqlX^DPSx0BBL8ZGc#x7t
z3xB$61FU5G{GMPtqe<z0onMO}&^vOC%mAeqRxZfkf4_Cg9GPwGPugLDzb({M`J-rZ
z)vmF1AE+X?X%XNxHeDeIY20KUM!-xtCiOW|0GL#S2)SP`=T?LmSCDZm3ub1E0Gb<?
z&9#%nwn>bS744pQCmC=b*#>)DFS+(#YhNj#%g|S*<-)$;-f>P+41nA^4|Oelxvynu
zbJ1`|;><Qs)=C`2AH;}wNV^@mS6VJ;C37+48rn?E)Jckz_*9>uw<9*JB*xxe(C%f`
zzS+mzT1Z8aaoG4oiBI-5jKhzHnR5?wCJD7+cK_m)^EquO>&E`iBaTEtS$C6}$|1>5
z?!BiixBiT{_s7jghO6IUedli<nJR);wyt8sEP=~mn619*0sV{b^G{@MJhy1T+=JAr
z0fyHTBQ>a#T}w33Ke<X*tv8%*QgC5yM=<^!*WPF(QmFI*k~4v$-C5W43)~SVKN6S(
z{I0*ZH_ivt7S4jG#8<v~zi#&7k7d36MR#BW$rIzXwPsvbT5Lz#>m{f+PpHJhFJL7*
zI{$0;?o_pkC6(Jf0>c}xv;JdfPr~|~U~{2y{s@NL4(7`3sfQs<Z=l`xwv+$o-7Ex2
z*h#k^v!BR(^)a#I{vO&r69+pWK(9Gz!}5gvPP89VH_EX?;qMtH&-Y69_FnHgsF3Eq
zif{FIgMd+$>A3_)t>Yb-+nNHIB7erem7UHWl{G^(Lz1u>1vJ<v+(rqe5U%C7k8BH(
z0Uq2j8hkA;Vxy`}5)Gzow;_7khrg$J->{O65VOvkTkz>^ZK`18cJXETrmz$;)7#9M
zQ7|?eQ;MGb9O>1<=U!2*-(w0-lzT=1F`T?#q!7-$kvVi*cS<bKAEP-g6*lz|H&fB_
ze^lG6SAxsumZ;b~EeOB<8nAPD(0=LYBC#j`E#8KCFIIrY#cSo#0zI>To2f%@KyQ5|
z;0#HtcXA}fW3?5M&JG*94!D{Sz7u=0()Giw+_%@qJrGPGEIDo)p<m>EDJ1$G<@Zso
zJFv6e^sQC@+oOKy;e~T}u6#bGo&U}k78}FV_QypS#J}L+UW!QVJcwUNUC(v#2zHm7
z7_unTq@YH*<bK}{-QCJr6!Pv5HEy6b^ZC;FV#|K;$#D$|mo@G@?pB=$!UAA>EV2&G
zQrUC7z2B{!5@UC#;};{&qz&-c6#`pCnGChQ;WIC@cW2R#Bx9PN|I$ji@C|FUdfyZ{
zS!z-MD%|Yzb)-^ll0Y4nu;`w1<#*=y*u>Nl^g2f~sR!#_r6e$Ez8%F##zUC9>;!tq
zHTd2HC41lygkcWASOdetG-sl2#)riCp_}$55B|4Wc9@jV-uflGhrEXXXWV<|%T0m~
zLm2oT%o4S>PlWS?zA+(V&pS-JEp%uM;Ieqw4QOL$bD??zEB-;e>~h_I))gas(aCZp
zd{1y9>}f(IoYOjea<M*0B<!`fAU5e>gML5wpfPDv!_o?G+vl)hSju%fS@P?ykAcNU
zxOld|-nL!AQ`ct)JX&?_z-<eYmU*~&ZFhMjqvuDVmJeHP@N<B=K4c_wXDqPsMx`dy
zy12tVTbt8I2pm{ni{LbCuiV17-LJ!S_E5CX!1TyGB5&Jle{a^lH_ih{=%Jo|w{r07
zwYo-WX>96BhW9J2m76`(xPerYpJ~2(G~v?B*<4ff`>KrvhgrYJk{5;eZet0wRy}Xc
z0zOh_pZfv=V@KNkV2@Obru~X-g?ZS9lS!EmbCC=VErM5~V=#Zt*?&p-0I6i7+dKZJ
ztsmDv_CIFX&eO{n{%JHX<8>2{{@L2q2;-v4<XO2VP_cUulqD~~?IHe9t6<gcVbhRA
zn9Aq(`n9Bu2@AAZ1@ljgyDzl;kt`FM&;6B*>(D3fb&}E{@#05F;m%6S9%NOI_uS!3
z&g3F@LD$|Ow!{i(C=AUnqiJi_h7A*S#xn7{Cm9pL(x-j**T=4e(U&iJS3_C+yGx6<
z)nHrvIAqL?-W6BZ!l9=Dt*3W}uznw9=Yz391%ix6t4e9`>DFqD;p5KP+~f77@b!V9
zA#`)P*T-8S#{bNr{a~4c;I8Cbvnc~p8MG^a<ZLhC@~)XGh2^MFHfAv>lNNT2>EO4E
z(*SqVwY;_ZxK?I(XX<qb%C`M7@HkT0%{ed<cS2XoegQbmJf448wJ6DOZ+)1qSjwnd
znVNMnEUbPwx@gmt6WzKFAfytOvklnO1cz7z5Yjen4fINb%=4|q%5s>K@duCT_-U(K
z-KUa#SfKJS2M6d%Q0B+*Llg7`d6x53%<EkT^tRg>Chh>9M%wwRI3{|pp18;;&h5z>
zhn5;`wF{~1ZSP~#XDc;8C^_%;?!b!KC;s32w29NxC)0Ua3<Yw3)fK8g89H-dMrpZC
zZN6+c_m&Z_9gM(N75<JFE<U4AW)LrnmM=<*1bvEk{Qr0#UlnOJSaOhYLsuaCNLwel
z{m0?>KmaXWgm7$?+h>dpg<j8^LLNPJQ(EnD>5K4qo9aT!`k+IV3jD-j7QOoecdBi!
z{B7%}pT5riife9G*yYF)UmA^<ySma*FSNGd{(#mQ+8Jl`^gC$E+wO0Y$sWeqJrO%X
zBUm-`s;xe+;h<ie0C69kvu|)}Tq+2F5B_IMrYdJ6sN*cdG^Ei18`Fs}?}x`Wm{GFf
zlCv7CzlOR1!kg`FGX^Gx&I)DX43<fJ7Ih<NYppO^JZ@)uQJ%BAy*pfL#D}_~o;T@{
zM^w5-&H-i~(g{lf^BL5M?k=wk(wLy86TUOvafUR$g^19c_1hOqk++%nKwn>Xj1C;w
zMx#Y4nM{o7*E?m4GP(MYYM((2*>Ai-hWL1fOkFb}x0xe}z5++!obZTA!%c27XeX?B
z_13_)ayIW$)c(*kQkL{=(|9_j=rBVYQ!7J2yF1B>L|JIWEGBk2iSw`;J3*h7i{L#Y
zZs>Ld8WpN;-t8QYwgs~<?09Si7E0EhoG4GOV+gOZ=hC&*WK*wMVwRGTIyps#L&nAc
z7xCqGibhM8z~hIY^+4ZzEt0BS+~C+{(;Heie0*V<S4Nx7!nMBUk&x(fGT5B(=?oKW
z`E0&NrE1wYRGeUlPC@8lzoMcA=dSrAq}aO5u<1Z-AZosLPI_L}gdaEGP901#4_|X!
zDeip1cE!<3HF%XU=%-j^SyjGioOwew_V~oVJPsFB7nC|@{c5K8Wp;2DEt(;RSOwTd
zD<fEYr(0BJA^^G_)9k)fpZ}0SC8)#Zo*W@d>QtB^r=6PaMo%wK%K157A1PkRg|kG8
zBN6N<6U<)rMsB8-A={Anp`Zb_+JC~5q6>IRhg@pNgSnlMH3l#J2wa?F5~T2ABDPhv
zK(iO&G`9Gy(B%8}i*7CZbRUY!t>|rGsOg<bxY%TS=Y~T@vOiM3hlZeO$<6rT!{jPC
zF1^Hd?K>L+Q`F(6Akm{_@8Zg!6v@5|x!cdv^q7{4*_!1~ynd@gB}_ZmT_B*9yHEXj
z=2lst;dE|v4D$i31bMKMa8(OGA0IX+a=LP%v#F_3?6rK~l?1lR0Pkl*Ipk}F!4W^J
zK_im)nV2WgjWN72rVlbS<T_?8scla2z&`}E_&bq<AtAc?x0ue2g>Cgk;vHSBPZ}`F
z`h)j}pTM_lP4_1e*HPEw?PtN%Mq-e}y)lzHE7&64eS+=W-;ASzFF7e8p(nRX?ffA1
zv$3r_tOi=KR(hx0gF0i!%ICbxl`QyneCS)O$9ezIX>o5<wmH_!Y(!@#IeC-8|9tR-
zRY7W^>p`G>GVvKqgfBsWFH10U-7sJu%<;Hw+`>IpaZml6$@;}`;lf>ZA>cugxA!eJ
z<a*nDH9a-zJmWc)Hxb3uRC(ImIRA7Po$7#}eF=FrwXN~ZbpkWuQ@ij{$;g{p!M_@o
zxPFF$jF)tqD!tMzLWnloxfk@l53bL#$ot-fJkMZ8aK-2Oh5v`6CI8=^0Aa8Jqfco~
zAOKSKeOL7N7Eq^SfyWY`|Ambjig=;mhF6QCmeRTA?YTVLC(1=<<t4M?vXPEm;-x*@
z%*-qv62U~#NR7wD$VdqzezMVL--pH3(EoHqlK>R;+8CQ7&zpw|+8%6uUcSF$PnTv`
zj)X^>>iJ`&)y`6i7kq9)pjak8?p*v;(_EHeWD=b|f5-+V-_mxlHdq?<BJ~Rj9+S2~
z?6qE07E|NoEBIh%5lrM;g{cGfC<1WjS8<1<Oq<z9M6I{vlFkYf)^$|`M4R?^U;0BU
z9zSfn2&}dXN2g&{M>wTV_|sdDXP13<4qV*ZJ0K%<w&45OV&k9J<eirL{!qZb&vuHD
z9XGivRSmE9J6-w?<MNLL*ZJm*PzT`RiT)SCL|%l}Vy((epatGn_pEZk+kMc-o~&1&
z%C>;bi|^H$h1p8jqc8;)F#hzoB({bmIU6V^R2Iq$zZs~r3d-AycA<G)v3TGPuvA(g
zcj*>E0R$Q$x}N2Z@+Ca9VLqK(`I_~`XxOtt^ipJ8<bznsSKKdIQ5C={GR`d#iErmr
z(*Dxq94|#Mt<YlQ-9t@e_^HB7x^qb#S`0`K)wYHDpo|QQHy<d40mv^!GOxZ#Z8HtN
zm#v^eo7h1Og*)U{1OSRPrg8?2J-3RbqZ@f%b^@}=nKa=n86)+jg9SN-ZaFvwkze<)
zTB3!A|I9{z+ehow_MZGgTFDrxQKsA;p0*`5sdmfiNa>aHH|>=7mC4kVxDm^0KZb;j
zPX-kQLK<+JKp&E8m|qOifVxCz5h-WmQ0Wu+x6-H4$|H<x6je0bicYc~=n_8jB=9zv
zB_!5{kUSAd`*l&zG!vz9Wq_$=VGY%|m9RJUqO6%pTA`QH23m>UHgG0#vZefD(B|u4
zM=?JMO2F+<EB?e&z1B!Y53D}2CIBV^Od?XgB9y~$(wshQNxV)=5PCvm$<$HbC)|{#
z61uzb3w~jfj?=`kj&T*WfcvmCj*-RZPVioUYi4;n1*_}BE~{08wSrGfK^aeAFoN3=
zpPkhZcE8AVu<)A?`{wQq+;VWM9rH%--h9|IclW4A!K;%S3gr;|<zP8Z7F?ynGOv3?
zQYN@AKS-83xk%SF1=+0hpho%AvC;i9?lX+_mP0>{NAL-q6p|g<UcT~4JAjRKHvj(t
z>Qet@7q^rb&lK@Kw#=*x=glr*G-EwkM>y)VwzUcqzJbF1*(H5>`s%+xUTz_e(hlcU
zqfhvxn16x1uxQ%WjvIGh5du1ME*4Yl2!}pu!2L|NV*B{XHs~1=W<~rA36pL?Pwtcc
z>u^rf`D6lxf*;9f;3xO>uM+N}q=&Z7Zp{K;RG+9tVI9*)<2Cat>*lyl#%7{>rA6QW
zID~3myBKTka+sROcTVsy6DtaU_I1^sU7f>?8sE&RbZCBq5Y=J2+t326aV(hpn+SJB
zbw8!cRI>`#bicaGI*#gHW2W9)Fre<U7UwVR$Ppn4jj8;$plTm;!sx9ryLmiDx6fM3
z*ucc3(pi4=`i3cvCVr)umxuES$GKuVc;)YI6-;_Hm^Wl~K?7GOY1%Wvc_cvi5`R4U
zn=O`E9m-ds`wN^;C$?(sD;Ezi#Smc3&DqsO++vz#9HAF74gjl#`ML^SHcnDrbL^>J
zZHbx-!xa~uJFZxw<5YwH4p`bf*q2$#mwxEoan+q&n<$*}o%BDR5_daji~RW$tj}il
z>i>xF0woF`y|p~NZoaHfSy?f%anRlQy*oVF&Yj<&Hg5GgfWtA3U&Y5Ypic-A%yHDp
zY2ht}#-Dos2&O=Yv{?R~v7NoauIX~}R_-L3v=d@lB6rElzFdE1zLJBLBVYHXcx2!x
zrd6|?szCVE3vQnNwJV|cFhr<<Y~6KI6_?aeNs`e${pI>pzF-+aGgV3cwY-~yLyVEn
zd8OQ?zADa-+82sK$b9Ic)Qf>WuT^>S(aQ&Z%!9zRQ9s`y8+71AK+u#9_{ZkP(g!)-
z^Edf*CdAdd6p%w88*#JLjpvBU{vHeLOLHe=6DOs-;K=S)JHPky(L<xETOG`-Gqcm<
z8y+dTWftB~pXKeDzU)8?C--o*#0-H$LN1Pl(X{i$XpT(Gs4KGoxkek5IPDSDEJtH=
z9lLmh*!}^kO!*Rw=E2Sp9a{)pN*VJN$#8AKp(C!TeTiOY0`Hb{ej*4UK7^*7XuriE
zO$z?>8K`Dp#o0t3RW9pC2AmBxMfoyf^|x63XI$Btbq3f9sN{_UaXmb6KRDQrnL;hz
zNUNLoVmaY`kzjRqXFk9Dt3kE!38eKGB1?L8=jkL)$4^52sFz1koU~>8nH&u9R&Jkc
z+$^h-0pBH+SB;b&b|HhMHx@`zaJ3vW^H+1abi0RF)(do$%i={d9r3p(>IwQ+S9p~N
z<JF58e-2MAZSO^3jsQz5d&k|i@xOp)m*|`96L_NWMfm#G_a$0?8qZ2Kc=k!yJCg2o
z68%WE5a+fW0dIH?(BMX*FhWToy$P6TX=AxmDB12jhu9rEPE1xo-S%4Sk}4gRb+cMo
z)GmOLW}+1O5JGf}0!8PoF5s#l{~>&3!-V~8b{l+x_ig*t(CB0u{35%($Q}gJ_xItb
za=7u0?}lbCM>ApoOjk2HBsvF79gvKP^Fs$ZcZJVvCE6&sio^0HQO+XgJdK+)+543x
z#CpJ9dL@;urYVmP;EZ$jN-P)t0zAeOx`K$^a2P5^bCd2DXB!uvnV|TJcenB;AsUKK
z`GU^Qu%B`F(;ix03d%m8>6gw83fa{)`qmxu3`Ul#n~Q`)G)4p`X6q{a)N3wo&RVGz
zghEWM-JwH1*$6|S1~behywLu1lyrcRq<cYiSyJ*P<{|quxBC8YIzhBGP>C{^G|&LY
zaBdiH)<2#ppo<Jpxs2-&-a5FsKTwkXRy}#cLvt7uA?^lPdO{r)qxpxy0W@9~5xq%2
zJsG2jP8L)Dt%EXRKI382z!#d1f4_2Lh!7f@y{u_6gYYJ*Zprq0D;`mnN@jq=F&-Ua
zr>6eAnzbWeIw<9)!a}hCC;z3cTmIm#Ml!>B>gHewLp%SPTym{uT$Q04hcn9ITAUAs
zNd5<OI(TW|SHyR?`i$1Ym>s6$aD`K^(g|Xyn8{Hb%)*PiZZkGivz*^mBj$<FB;Hl-
zaQw24&`8P|d~&QtirJqU8`JwyDj&S?d^RQF%_-@y@JjhPk(m75GHGcyCDg2dYI;@*
zqW0*@1~}>lNhrTsDz>*+j;u)sH);o&T7QD>F-RO`W=2;Y%@s19sk<_CuQSS!1R}Wm
zRub{T_&=h@Ok2Eiu;cyZ3Bt*F%eeR5ZtK|NQ1n}hs_4lhcSI~-0u~@VCT4PgN~YH%
z1t=j{c$EoXaR4RVYsV+J1^pa&_;dnW8Q<qpbc6G5DEp`&<Q#EI5-1<X0gHARv%SYb
zYjnHx?-gS_#TGs4E!AUw3N4}yad^d}YWaH%<V|m}eRM&w&Bsb36%g1(yXkR$rDG+d
zq5>Fa!UsP5&YRSY&{s<uZe)JJi!Kfd#NFRiC4;2B)KaKIQB!YxHYpUi46F?opWqUN
zD_$!VNO$})B;4D_*H4#H4CVmcO}ALmU#fWJj{wh8et<)Y-VNPb8$c8EMl5n}(=>VW
zxku~$#NsBl%{z03grx?j4j&S)In%U0D70fhv<`-MqS0eQT6d&cSH7^F>`v&DY=cY~
z68L2qX7G|@55`D_w&dI|&{RHJYrkr?<vfNm&z@GAwD)fCVa6X-mrc$3SfG6Uui&=o
z?pJRAU;+LGbVC)AY^<j*DAux{jP}jVy)e#l)vd_|f1VP-`ct-8l|!PHG+fexTlzE3
zhDwX_c?0$=Cy!5Z60b&a>y=7aQ(4w}=2=rxV)JJ=*}Jq!-jDH*Y>B_Zr*s?$UwXFc
zN5!?$s1r!Ca=FXZFJeub^_s4sup0G_Ex(a%Jcj*mK3w|gMp5SL>Sf2a70WaJ&M$Wf
zNm(p!pJ8jz_oA#k`hRM)(fZ^to{(i6(CflUHUvNo?svgY+GQW>{*=sw?W3TVJdwbL
zu0@svZP8Bgn&%x~I<pC|mE38Bfk7!c0~dpuYkNU`>)j`M4zq9c1>hGQd#=E@#f*_r
zpENJ4RhR|jrt^#9xQK_%+IFz!G9u#u(Ii#e8d;J^ksM{pxOuG7ZKV!okx$yw#wPbM
zArN=>UsAwb0H*AJwo(PkrGJ)25A+xgTZ)UO0B_L6wY*d`j&mnvQ*#-gcAYlY&f7;<
z%?~n>HLOCya&=yRvA(ReAH$>mM#aCW3>|q#>nT^Z)7nz83;g-yHa2{V>oyq5R6S)e
zYd>)SL?<TU6AbM+;E?b7jfEAz6Wo|!LBnq>B!i$%fR}0yH6(un;npPn4TO_zmkZvo
zn79nqH48)eBo{F!1w!duE5sZ&GOipU64jrSva3%i8<@Dbm&74*u_=ytH%AOP6X6hG
z71+<L;yv8Q)WdkT^Gw_+aWr=1veu@kwh?myLAEnJC!O-YLSt7sQ%V5x_cQ?MwIVTo
zOpl|3!Mg<KSzPK16s8x0aCB1x`9g=h==O@a$u|1?{7GuGn)dcP9_4f+B})W+PJ;+p
z>dj0sK<ll$!pg~Q*(ba0^?A@~r5re9Segz1`O#@zv?#5W+US&#a^iih%YS?@bv3S}
zXcuMU<UiRGlrut2B>kXZNXD$e@hkTf%~g~*nRE}J+~(&2H?(TMirz6l8&#>6!gtgX
zKXl=g{}Qm?V-?I|wqWKt9<=u{IDHff2G~aT%|Y%Ykt*FP1CYT%$b3jme0uDTgsG;e
zthNmZZ-@?qdB_#6(n*q(-{!#2#2$+1`#c2v(d9~&z&x6%_h%Vwm`*Ae4A`+;LVxq^
z-Uo|V(s6En72yqWRI`g+amu^7GW@L4<`N{@nnlKcDEb7?V^my_OClvEB~%lZ10pmB
zyO*GM#Mhv&OMB+ob*SMt<4`D|!xxsUqFd@C2qGI25(x-l1UK{-G<4|>J{u%n#uxO8
z@<8@7<-g51Z<KlYvvMW~s)gqMaB0TcN$J8W(b;{ydPyEF-R5xV;SR5(d+||&0eCJx
zVn%2|QYz12R~|o$2qXZdZ67T(KIH3<5S{asol86D90C`PqU;_GCb-k2-Y2J|U!Ru~
z&%uL`Y?LRux<m&n%6|U#KADUrK?3Nt`H~+%Hkk%03aDz`@5xDbG!YTTJB@{Bj1wMp
za;VJcACew)5Fu%h5WQ~6un(HEB()?CbFZGETH1^APISA+dn}1vI_c1<#;FrXVjc-U
zX109I!EWanDa}_C|J|r&k91dcO44n@w1m56!I$m2ft#~$>iLNKiM{8AC89%|ejUAj
zI4*<F`DVTNQCG<Zi99C-i*Bkq&ttGI@8v0-(Yf<Cm>jKIA^YC0OH*i*2bagON1lL>
z#{x~pi91mc=_};jk^>!EAA)wENMq4n^*3*&Q1A&UtB#F#%$x>kQk~6U9F0v0?h4))
zKR-3N9WRQn<H_}PQ<)A2UEh7L|1Z+s0;sNK>l)p-1_;4}6WrZBNC@uk?hxD^0t9z=
zcXyW%+}+*X?d_0r?)|=d&;MS%`m1);uC>=*y?S-8o;~K6V|Gs(6$)s_YXW>G&K->Q
zuM%X4h7!z&si%Frc}~Z?GR4`xt&@3`(T`7aHz-`)XU@(aNS>66tG}YI$nO32YuZt$
z_HAdprJ+SvNR>GJRpUxT51^FXD=#n&>zbxUJ^i^SjkGg&>V66F03i@|$6WK`FCf#5
z|7lOC+d)n4S~D8IK)Eoc48Kuovjmt$A(lMZRN6vP(C$#I<*&GR5ibXfFB}1+9iLiQ
zfgupg!;g|PO3;nziWGu1`p|BKH{2@<xo~*L+^__>s=Wd+Nv$c{?(9l^Z#uX+rez{f
z+gCV~2Vft6U5N#>gUk2`d-4CggLxtrA%99xY}<+khoOTW`??X9YR|X7JveG$K?+#a
z?VeD=2#4nP66#<=Le2!HD^9#tYk+?e^-|=^)&11%r3I?{1DxbjP}BmFK@oAQBW&%b
zQ!WPX@y7DU3x7rxD8fl_(R+<oJGD_~t=D^_NxXP?Q16_Z0>mJ50IC2tH35DnKEC_1
z0$ythNn?^Cc}p_Jx$Qd&FM1f+os;}gS^th-2;Kk;2xGwevoA=1OI;b*NzV4fa=JtX
z8i=n=C5HGYpi!#>xky7-stl!0rjWoUud14fojiynN7-kr!2hQ9OqjkJBZrVddaa@k
zf@u`gC6;RqF`$P<IV$WQ%aU)erX%rlf1%U^RrULzmSk<u#WFC{lCs2vVz=TKQZ6FD
zIYR<7!?hvBC$sAK>Xu!11N|h)Mi?y)l$%G&<c(KBt1;GzigG!#5|_GLGT&(W%9A}T
z%5shw`5-HU_oQiVH40`{+?Dll-o%8e@6}D>2_jFc=2`PTCymhRw;(L^l}4YOcQXc>
zVSU6OhIhOLF{leL6c+YAU*kW#Xb<{w^>1zBPONW`F)^}TS<PqvPNruLHm8c4ikZ26
z2LxwzWF`;|IfZ6>$J($+8Eu-L_*|ar21Zc7chse%W|YkE6z^r$ZE~soEX-NF5nI)1
zk?E)j2tfpH0=EjJ`#u5aVAsllB0_bO*%JGQmg@jF@u#M>>OYJ6n6XOi-u_twr<DEw
z-_kX-*yCX1-If#faQhd7GGsdJ{*-uwm_naF+i{!6ysn6{{}_`8W2?}E^7;@@Yt_IH
zFL2fW(2&`j=qVmoC{3W@!CpvAWwi8-EsilbD9D(Z_{B9_;$t>16fR!dO?N0d;8z_n
zOG<<EyN+i5{)x$1Ual=keHqP>lbQr7xlDlrYCf1nScVgJoMd%!AX8hK1Wah;97z>z
zu`FK%$>28mnuMPN06+`##Xl%wMB)9;V{ETe`HOf1B}Af9xrt|eM~?Ey3?pDb02_}F
zL~<@I=K^*};wnvvMjAz`pg+jT(<&cp`*NPUk=)0W0R)0fpMvy|;E^ce`Xu0~aLEKN
z1f%ec@iEXtWHF;Z^Hm|ly)90Yhg}e{$j^?C3CSU+Q6xC)F%!AlK&v-GrRZYOX7~~G
zjVx{}P>pu~%Jn7jKglZ<w_>XtS7Rpa2tWvpwppdg5EO`LlwCoYhLYxjZBAi%Hzv}c
zq<RI}5pD7`#DC}EwWoCTR{SSF6)nJeS^O24ey(G8WLj>uVq$X?ZgCEefN-m2$Fxv%
zxXBs*4iVudg_prjCO<k{Sb55kYe7a%Lx*=FS-qh;+pK4k_u}XqhlzPf^Dr}kpU#-x
zgynS74X#$yq*3s9w)1z6qe4<+0BE$-)fw|iWrlZgf0Jk9S%JXh?FAHBXwg3J5hnX@
zu*=qhoPf)*`;<O+_HU4UB@+j8rMK2M1o%MO-lt)`Z9livRkta3*5O3{=ZeQtNLyK2
z@07W|)aBSYW^v<fD3Ig;G8|RY#1AO|aQ-vUH0c^6C)HKwK97@_i<kYre@bLaIZ-uS
z2d1yxG5TySeFvtn#Wp93Xi%tSO~SNYl+ujW=98+Y*;o~JZYPSaY*4NiO~NE*WlrMj
z*4;KfBjra&ZJc?zGU!$wGO;bs*gG*%FsIj~b27^;H=XM0Z`s8sB?QUE-_&Rx#g)XZ
zFiy9&a{C+)bkmGGesQSC<9_9JwZfjBvtNDm=!G{rvW`-cjLs-g*k2J|vX`+%w^fa)
zA=?)k`S{*wYR)*9@e^~2Q^r2sk8vijFWw~((YIqcUm2YPY@kfRSfv<kI&FH{q&~PZ
z)yiOnu%MMv*M2wlo%n2uMJ}29iAUWv408XOfZ!7W4h{i5<j$=MRb0*JeEaj`^Np3&
z^T^B$`%T(>N7Pe-hb30`WHw{u5{l*!0U?e?XqEadnA`TPD=|G-M|>@%uoyZLI6v@X
z@*p|paGPSOe?`^DQ47GP%#?4mn85`da@QbX7q?At<<RX2wV=fN0anDKmyhhCIB`EO
zUP>mt$S{*_wL3P_Igt-Vw|%BSmNM`#!PhS^9K%w*RF{)nXff{WM&JbnI7^!rEk5@%
zVy;ryfHP6E+gPEqPnrP<H~ZSQdK?NuDoz3jDW(Syxk!%cmWYHe%*-qNKuMn~V<Y6#
z3Lp3sXfp|$Y*DFgq*2KUl5#?i#coHDc|0_KL2wcgg`>enLfl*y<x$>J)<c62?F0Nw
zT&0fXeevWk-@*VKCU4W6Qg|r};oCnpDhfe&RIx^A)GJh9Z@0x<GQvxx)v0r?{`4ns
zB5=aOMD!BHR(P)&m$+R=tP#!Pe#n7z;|k*Uyuvm%KaV>~p#rsVRSK-V@m7JA?OgqY
zUGs9-gJG*M0>EAZ09xm9_Vow0RilHYd6iNyYn+^-v3y}YwJEWefv1kA%X8)sJ78g|
z=qP&wA#!3owxO)cqg-G))dA#pCm?Ox-dQpxP+s`f|KtFKrrG9%!2!mw2PG=DsN`nu
zF|iV@tv#Gp-d|k413mB;*gaBqQZbBMjI)!d!6KHf-_T?!vZp-R<`Ak*5=_lvmjj(L
zVHUHoqT@>**h;EB<3}u>f*og`H60o=lC1SGKU=!CF?;P2yY%UugSRlEEXDz!i&_y?
ziLB(fCY1dYD4`P1o;YZq+aQ=@XGdICT(L@7-n{v*_6^=^acL{zR1)R#+^@75yq323
zmOh{>Td9q4#}THek+{sL9!x@&VLap9qDi!N?!r7Q3|KHM?LQQaB~zVfrtWFA>B?{%
zR!wzi-VdEQRtG<j#F%*G9@%3Xp1yRDnyPO&x|~078{Cx)HFFs~Ei%G@p1`T94vRZ!
zs!yrUf&1Of8z(sd>JeFWk|2CUe)d!oo}pU(7Ygj22M-ipmqdM<#8=og0u@caj?&f*
zOeTt~u1kdR!MTeg6-y!cLV(#`S!S^tKZFs2(R{mWLC+8Z<)%&LEprQWxDQ*WMl=#x
zu=+@5L5kglq9X0z0l;}uTu486CwBSZg5aNxPjT{K#hsMdayF^Y9)mb6K)ekk>7+Ks
zDOE5pul_{I5g*ILbC1zGX@wCf?s<joyjg?RGXDdLYS)1H-0x)yAEB1&=GijF3qXvS
z4%pV}M*F<$6iYu_C5WeH+B@xvxWBj4fA*O?-|M&&1QW26KuD;i@)B)P4E`aJ!~y_0
zwLP%tXip(ulJpe=!^b|$ky<Gs?j_iEuxl)H9ejTXx}ve6)A4t$z&KpR`6i!^Kz%Nu
zIn8Hmb~&(%R*F)zR`mfDI~Wk{C>mI`jfc`|h<wV)<vt9xuz;3ZhAh@1ODC120`|PR
zOp}>5_1UpcMj(76S!J2~!4{2mnT0mrPQQJz!l<#GV*N4lFg8}AWW}Aa8&EZf8n|c(
z(vG5z1vNG{LETH5muAVQlb$Lt7gn)M&j~>$&h39#m(&DcGbBN3^<Han?<88*c&mD`
zYWrzTnJ9Y7F$U)%y)Yxp@1Y?d0@ldds$zSu_+4@2YDhCB)jIviksb-Oq_S|7$v6tV
zSnc2m+eLT?y-)s`5qG-9Ov7UD<M{C6bsNNDA;{}et(bp(B6V5eyquu7i{<mgw1W-f
zphYp21i)BLVlX6Z22C*U^Q5kN+el3v7O^WB{FtG!BXtQbqrKs7zVFTr2pKg^;PN)K
zcd=PBo$ie2`FG8MJ5o|~QuRzZOAzRRVVr2l)~YkhM@#ojF>TZF%013~@O(>_^zH)G
z!xogln8oq!CK@$?#AnUag!lWP=>_(0Jrff`l_+l59^R|_xcrF~5yb^||K{SDSO)(S
zAK(C!Ni0I;=;_$cI|2YHO|K1tdj_Wscqa$3?g7#Qi1SV&*V!3apcotiAVP!;xqtED
z3knP#c1Fk#VwIhv4VR>TFhWmP+$o{}cuVM^hR)##SGh+mlK~*)o-#8UOPMO9L2*HR
z@W~||X2vHp;z{{k+Lh=HgYCVYzP(jWG^efYr6X^@r!DX{jf+Rx3cJCnDK+KIR`o0=
z=1soC{LUSl(ft11u(CNpoqa>Ht=(_qi+`d?CP8|G6wY%L1R~?_tX<U_Sts>2)7YR3
zCTj+9`-uPms9<4ke~Qw8v2Y={Ayf@;<9quP$e8;i%v(V~L;j~kV4=Vw-%L9`wAjDS
zW-z7xvG@Pu?7uJh_u2ouOa7@28+46pmfntFfZ|0w-P^*Ch!w0SbzymA+!5WGsuatZ
zlMdyv^+jem^<UGe*ugtRIsl<8yF>M3UwfyJWWMu!cJTYV<F`-%d?*6opoowFxIB=x
zPqXiQ5szw>xm>Tvyh2#5PT(qC(QI6S<=aXuhP;<tx+hz9?9K#@wbgwYNvLxzZBfu5
zS~yW#TX%n-*y8B1!f_Zr!zkW;Zx&xQ>IT;;FaGX*>`5I@X~e_B!xWsV1T7tzQ~fk!
zdkb<QBHTOp4*E>A-ln?64$~okTveN^;Y{1wf?4I>qLS_{RU5KMGGf{Kuq#&=%z%u`
zEkYnpaSZxp8~0fFqs_|AF+JjG2)$XVEtQD%QCEs^?@n)pl@&a3I+Nh<JEFzp?QW*y
z@p3jJE7@an&YH>7Ayr_nQE$#Xfb4Erm#TY`94?Xh0e}t+9|8cW!}Vy;5)ZKQE&wch
z#R0YA*fqU{HWULg6b)J+2tb9QP-x~ml?XWKWD=vJzrI%CAK1vsDg5L_0IglytZjlJ
zKsLLctc!^j3fYB)1eQ%bDkD@JLK!C`9DAQ<a1>1b0a6>)%QkseP`fsHqOM=6bFfeM
z0JV^2pi+nn2EgS904JaosFI*WUYB**HA0HgM$zu!_6_dJke-!ia&VY{NZy5`r%UdV
zvziaE@UC1Y{7xV*>lxXJFkV=)cNT!;)q!52n;h?8z$VXvYF;F-*by{(KxjW$CAz_+
zyks3YpxCncNyhYo>Hv!T_@pZEt0yulYi5leoKylbQ_MypnNvG27KF9%HUwbLR=1(0
zlB&$qu%M{=DdizpFqW7Cb_G#UP3#8_DS^QcEV0R3?!pAh)8c!ZMKSD(P<ylO{k`#T
zB@Zdirue$Gn^_)mR|`WEJzch<1OQbUeY%gz!}xfp!cq(Fhc*BsygJIMV8-3c$*XD{
zy`Rr3q;iDN7zY@7hjdP5dLCWqK|Vrjelp{8oErKYVFAb8G_D<k#Q?Gdukj4&8`aM~
z$+wzm>1X%Z5kzC-g{DU-LvF&sAsgI^{V|gtETV|Ubk?w>q|n5@{4%;1cnJzzg-6T+
zi%iI!PW8$P4^JvUwQJNn#*DOUeSz>Ec;8Jd(_x}k#?3G!EywdD#is0F1@w9)<!Vk+
z>=S7mziAfc1re&X8o-f;9$+ejwLd)k(4J!RXRbLhw&LN0toGKvm5urO9r@ZQ;Q?wf
zO>bo{ut#OWjdZ8>4YH(vR+^d@E2XzZh!x7^nV_M;2{-ht+^-+n*PeT6<}-zf?>ZSS
zHEl_{3a4cKf@52x@0*@QP<2WDAn90u)@7Oud%QcLQN39yXNj)QL?51D{$YiWEoWn<
zx&Og0V%32d8#Zui$)(=FOQtSF8D%?BmOx(hb;Fl?md_+J0eAKC8Sc`XPF|Hg)SY@m
zv*^LPz>Pw*FsIpB&ZQ%0=%9DUo1vA$-T@V}kr0n^1BcXmBT{i8Flu4h0x^U=KL&;v
zTg|PDDmU}fsM9h*@-*(^6}(r-teqOY`iwG~0<*gq$|h+a$77g@#QwJE?Nf{UO;cfi
z#-aG&`P}YqKAH$xSxAA5DFQ7AZ7j3t2`<7#s%94}i7ZhO72!Dt0E;9-!+6RX3~sU&
zebhXxB3I5G4t-{kY4Y2`ej|CGwQa}1BMy9jQkkZBs$P>z<?~Xa&+6k{a10&1TgL^5
zu#xW3T#cpWLMhu!J(8+g6{`F+quy~6EE^M;#kWb|hh~^>RN$xkJcaJ^p1dDU^313N
zEqU1WFr-g%RIkvv8LK1$=W#G@_foExPL37*Mk4u?*cA5)?|PJ@U6>t%LT!vzvyJK6
zgWp(QYTBfPloWkHbhqS+Cm5icj;90XyVSg|?O@9JL2ebcLWRp0R}s<{{>z&6gWMpS
zBOgS@nL=|gcC`1koja=jNW)3|*(|%JpY_(}vd*hDE`1KZ%hT>Fzn21S;4;P041;rz
z?kkROY4UzKtjrz85KUC1>&m^A?4PCWW$MFJ0=UujGnP#!%qVk+pv$CrBU<-vY<_sD
zaGtQfmK|bq(6KKzbKr9Lb?g&Lq6k&oWc_`gyB@>a-pO=oI-~9F2&r@XJLLviEIa}E
z1Nz6KM(6q|X>cUFMOQ<xuNQg`jVAC?;Uk}WTIH|TrSIh{n908&U_`34&T&bX3CS8N
zokvnK%m+KFf9WACjX@-?YhJ`f`zA^Lp$CVOK_}RZY@87`m1L2zaJG%GS)@k|MTQxy
zpZ+C)B;WOG%Vg_Du>#xj$`P`s;D>(twp2@9au(Xy>HL^HJaDIScZ#t(UpiUL2f!R8
zq|+#w6DtxVIHd7z#)^7y)$oF#S7Z6$r@$`=-=sv~6Drv;`05i)_vT732ZhWS>?w4%
zv`<(-8+08}xhzbDycgmsaosrs9T4JpxV^{&6UG-lq&7yy=LS`2sDy&-jMO<GfTgNt
z7??KdB=<khyi^+8%=yFRPn*Y5*J{{&_G-h8{(`WX*KJYPI|O6HH*I(%FED!2BjY^%
zb)oq9gnjwvo=T{_DF~aQfHQTHcpt`^BPS!VM?E8CLa1=$9r;eK+w~`T+8t#ZDVnlA
zK<FMjcSt2Jx2c+u5;Hqqfj?nO$qN0O2RazJoA@DbLMt=Q9NH_dxwt-Zyc&aMf|>Ip
zC+D6Ii<}xKR5kxQZT5f>8oiy;L3DDHNGIqo<Lz_Wqc$e&nNGbY;MPt3##>{Besz<d
zPI8wq5Ktu{7RfQ`2&-KxoioHkJ`I&k__SjXb4r4fM=A~lA}<0*wh}QsEa6{Wre0=b
zmqkFmqC3#YeSC(N+K&!;cQwle^iwurMosmLd(bE9<n1oKbT4J6A7du2TEnO_aJfpC
z`FnM~HE;AB2~1hL&GAmr@376+-pqCTtiqa?zBaZL15{B#&MePP{`kDo)Z1#z!B<O}
zilAqZuv(^w|K<3$Pz?}}XT@=Y08AmEG9vY;W=9bv(+8R((lI#>Q5LA8jhM`@sWl|o
z)w9J~Eo3M`s2;%@vw|%fVm1nn4v3E}7P(Xg=m9hJwZ>!2S&Hk{<`VP>fnc?;zGXH>
z=h3BUF$cZaYF*L)=_%Lilg3SRLjJ(MmOyxnGdgnMJV?IAa#p~im}f=}O}%L1D~<w-
zsNT;J%wBS7rs*U+M~Xt5@P~3`G4Rit#rs7DlOa)xd^=$Y9|)W8b1Vv<P<0SzBr`Ct
zP_^D0F<}!cp4R&${iRvq>Wn6U{~Sh6z55rp+>LS^OMU&m+N^iQDjfdNEs(kzxp7h)
z;26uZDm8Wa(8Opm{j%M0B5}%6IFF+s&yaAa@X!op1@1pRy=UM^c49ZB;fRGgVmU}h
zGz%6~0@krdE^_ce8Q`^}++zBRlC}Ls%Ci7Ha_Og^?`8L8SVX!Nk~D1$Eqiu#L%~$e
zkOc|$g2gH_oA4vL;-<TMXxt*|S2=`HeXc^_HHA#y?2N*Gm1$0BmQCG$q8ihsV=tG2
z7oP24_Cch%C#3ElGLK_7=#>g{K`ui7R?<Kk{w}SV$MRT9*+jDfBRTWf+@RK%?|Y=Y
z;^{vT0C5+?(J=vRCR#ej+D9>q5YFeybX-DI$cTT;(jsaEMsVRpXq`HN7CLr-0`~8B
z8Ul?fF;!}+_jlVC&I>pFY1_~k-3tnn`e59ZRyw3ax?bjzCC2TC&l^i+(`4RFsJB%z
zrD`^`v*bzB*as-XiO3m}#WIRnMwQMc^^+7p6oYMUFg*=F^#dMjyG7<?w^okjv}=RU
z++5dMHJv^G^1#`IHLn1?@=52vS%wpFTZ1gRb){_YZ<6d178XJtl}eGhsIr;%oZb4S
zYK=VW4(xV$jJWYc2npgA^Q7_^yivvR>vN18lHaadmOorm(>%J>ajaf6e%MS}xtzWp
zg7IBpHnU$i&SO-q|MtFsQ>S6FUb|dO^ymg2A6dZQfc7YWK%70ZcClLrvC4>=qIk22
z&6#03ZEMvQF+PQk*i>0)6va$tV`&65*f6#KkQo%WTxrrAJi}tfr6o-MdzMhY;;?5I
z4;Hf(0rQp*6-ChT-&%mDj&okLRvXwL!z{(Y4S{kjFUAPX=7Lf=z!>!Ulmk5u9M0x!
z<x|)~2pR=kzSfxxprDji+5Uf19d>4JstkC;k?I2S8iEcQ(74bqN1I@iyMfd@04$pD
zFhg}Ep|6)HqO(P25qq0eI10Zs$&F*pQ?sVmtwF8XQtX2jOQTA~o<s{Zrz(lLFlVY)
zz8){dnq=#k+u~F#D2Y+Z8=f-RO4ndum!Wz&vZWL$X3K8$XsKYxv;Cg-eo-UC{CR^o
zS##<vDYF0`jD072)&-jIN4T-d@^*FPgJ&%Rbv|Lm#yRq1Co~9r1giWV5lZ!Yekuap
z8fW6<>7uENYS*P{)6jkyM$8jM(*Waf(>gJ`Qq%(#bIl?{RUwmy&OA>-hYbO33lpAv
zrUr1pwM3z#X(<R_NA!yj3Z9)>_^oSS;3p3TFr=*g0h&E~3tpl%sn-I+JuQ$7X){<@
zF>X4=?mXHrKsqMM0;<JiV4W{a-$sT)g3?R71CB4K>>bX>x|`i6(H0Ga)+iIkaO$$Y
z*2_(W`kF73aiwlWibc|}+Z;tXt;qBVp_G|UQ)XHSB_GB6#GMV!i3(ll`-5F4{*$(;
z%i-bN!-+0rtU)+^DxmcV8(C6Q$+!I40;eOrK1W^;mm@uqrAzQh=vCL(y+44dfC<nA
zB9->U$&Ouw0oE*{g7ziFLJX6JWj=0?ZJb|eK(vrfyNDG4^dgRrE>-orP-d-JxrkP>
zt{OFFi++GvE}CPH8BYP2u<Ws|7mYUg)Qal_xI>1&PAAEeORVzh=cTo<7u>nUyin02
zf)>HW_3lj|WwCb9!gw4W%|T?Wj77Kk8ySVe7$>D`@LA*P1P*hYs0Rwx-us5CLI74=
zF~>hHZd0m;0=O>G&c1dn4521FKC<69v-(^HabQ=+gJ6hjKq!=2F#wdmh5Bd()BIRi
zvM+>_)3InvuwVRiEBbzVeE!`Or-fY5%Gr>XGDsFR_o9FDk0006+}YJUD^}%Yx&KWY
zEhFn?s*8N7ssGf+LM_dzlL~qe8c;f4`uQnFK<rvK4E1*Fok2V$Lj5qP2YCY%LPln8
zMD#ZzH>g&<v0pN)OdN-Tg4LR>*S-Nj$A^$rrj!nz0-JN&!5c+PRi4T(XHUz#;&d)T
zQ4Sr@KLnn|ij-1M>vZyDU7!me)2K+!QmnM0@V)v+!}>;asZ;-V#3nIeF=vo!Gu*g~
zFY@r`O@trv8Uj!ea&hiHA1opKpP94D4U4PZom^9iBB*e%W>)TNDnJJNrL>p0^N#&`
zI0!T4kmQ14E231Rf)5;@-@4QET;==Y{b5calWp<QquzO#+W`-BFoF)O<OgxzysJ`*
zg(0-rsiVS7KJI#teN)%8r?$?Ob(!9T?&&SNK2(lw?Rqn9?8+1?hXdEq)G9V4O<2DC
zgMEg5*jL?bqaHUM@oC;onc?P{>43KP%PktGY89ziXQLW}+zLouhEtXAT78qFu8Z0}
zkff>y7dS8<Ru5524n0b7fJrmk!NcDe;(o5b?$JhLW1X0Pwf<>(os!I=I4;{7buJ}I
zBiSI3zXXaDmCQ-<&V{&IBM^t3qP^*}D_rarwnCM3?KMqvoV<m~uee}5nS0sdxA_ce
z_!vxDRUM&u@I9!~tb<NZ$$Xixrr&9XBSyyX*omq#x8cE1+O@kesA9;q-u*k~Q>IT8
zM?Qw*2g6a+6j%bf54;+>6-JcOiewIlAC*AmLc)YrzmT%oSKng`mn!cPKeSVHXLc3x
z>DL4+t+Et{Oj8dM{;!_3B^^DAk_Gt|$fbS|Em}hGSLYfy3)}HT9()*Y<i@ioHgO&w
zU(o#-W2_oFIGZ@5nC+J-ua6WfCh+S?xg{imIC>z(szJBXS0{m!b&avz#riVh0uE@G
z;r34-mH9eR?j%f6pka`_Tp*oC_iy0VAS%Syfh%o!djSBjkhUF^Ug#65INUBM9l-ro
zeEIyK2Kjn}c-gTCK;ScUJ3zVC&^rKFd0v7TkgAZqpW;yzDs+F1&eKTDm+5rMPfvsf
zV49GX395uqC~9Q2&J!<&Lqhn0lVOl0GHgI0mryEd1nY%3BYOeBS+ZF<k1nU?aM!nQ
z!k#borm{R8&i9Xg?0@Ai&-L8csckIs^LEmXVRra+;L`%kjtq7T6ovjCSo2eRwalwW
zdI%vL5>2dwhz}_k^7Rdffu4_3XmWGz<WBu=SZ-ou3c}w*CKlVyKqAeVnDBVz3t|Xc
zzP=zbPBN=b+>~^a(Pxr~DmTJ1Q_XNFCo*NS>J7#o!Cp%t4SMF!kTL_Ga+YMiRTP$&
z^RAgZ@DNAqMdtSKJ5Zf+JG*79uvwqmjm%2i*c9hyUb~ftJw)Q4z%%VZ>(b`$2M(Zv
z^DlLRFaIz$?$d><EbU&tSL>4Z^|i2Lr15F+9m^mJYK70;cl}{l6~opM=6<Ck0v|*%
z1Qvb#W3dfmTDpl3$q^094!klxQ-anNj(o9XKvwsaV}=Oe6$~PxA@rNI^v`JBe`8IN
zz$+am?Oa;kzmc2Z{73BnH_T<wazL6u6W-b~pyS{sY7YMn8pCV+1X1q~KYD|D<&^E-
zF`q30qTb?MJ=RHg*D(^cpk8V4bG`NQaz@3oCQS!xM61~j>Id-~d&;(^k8Ab0c>fWg
zbuM_4sPgDzX7r^LahNk&@82}uiBIM5)aIY3iOI9_b@bKgG{!IC5ArUAnuNxGj<W#7
zG@^DP2>?3C0PFxhz$r-aoP!~f8*~YpHUJ<4?Y$I?2@VYc?UuPyHL}iqV^B|9$_OQ_
zp`HsGszDzcRh|03$S$q`<rx-?_h2Eo%TpBfv~^UnAnF7n<N$VXMDWZrN6^LF3H|sp
zOFDQAY9v1-5M{ceVM_{ZVkA%`aJoh#v8ZScaBapKSZr!#nWgl%YD*`1c)ho-(+e#w
zXa0XBZ1Sra{)>~6NyFsjDVr?}C1U?5@Na^N%C9yt_q+dggaDvM{iildMN(%da_9Yv
z|2-cDMJaY)TU?j3t~>^}$!%#rNQ(PhnKb1{iW0h9VFtMCECyh>OP8M=;=D<arI@?U
znZfH)$}EthuOUG7QuK7Ffv9Izqa_cb=N$@X(uA1frC}Z|Bz5ZuOg^VPoKCHT|IIfv
z>jf^6{VgAx4mKXT-g5L6x^H!Q@Qtn}48%TOnPK#G2)?@<JEU&jWXj-@7^pv5C;b_(
z3;G%953U$w$hMT3>!ypPv;f&L_@r2Mh|NbJwB?`~+MvR|0`q1ATT3nd2MM+=SrWG3
z9PsL!`vXJF-y3+}-ZD0)u~bc4oi#A^%7*FAA{upFmr-hAZJabLd*%Y#x1-P2&KqJJ
zg{uEZ)cESXm-%R3rT{%&0_RmQ+=w-f!G<Pay)VDo<$ujGe3jzhVi`=If^B`_A#%`@
zvADwcQ8@~4a#TXk$;FODR#`5LS)(<<#o~>8!h9bKD|QCbMra$HIc8EN#iG&rlP(m|
zT4Y1+CS!@gsKo__Oef<`M$0gI)KDu_>aKg|OZW6w`pr3ig(2m9794}a#CL4lkk40k
zPTDS0RW&V|cD@l-iz}JpFx?$cRONbhBz<8LhdX)8!Fuj+nYF}f{4(((rQL%znN|}{
z*HKEWW1ie~cJmZMVMcum%&6AJkPAC`i#vH5N#1Gx5sy{OA0$ZwQyqlDbxveE=qBnh
z&WDt9okHK@6k?O7gbU&p$Jj%V%wF3V9L=GL^)y->R(1d4JhHKO(!wybtEoZh5<}@b
zP8|%vAC^Zjv>C8K<_wPsI+kV)qPlBTZ2ICxn#$%<0g|^EKd?Ds#~hM^)us9B8yVGq
zN8hCj@BF`ju=lRnN{zIH{S~xFBYua%+k_+GsANTyZA8CR2(hLNlZ(UL4&SjfsS~ql
zN7RkUNqJ;fIxtn}7wOx$2)!1(tZ-J-JB{J>o;%-&ekNPQ;_#?QI5?#c6}Y-xpUc%T
z_5!=|!xbP8yKUH7^*@LmBV3|4lQVGz7NSTDg>N+ZrC7M}+QI!Y#o%{5{s+Z%olq%w
z#StQaZVyYQ*qW^lnLM!DTh*U`7P=$0r~ul_(but_LI4og>OGaH=}AWPjxSl2Si|Cd
ztV6Qm@C>et4OnkDT7&*VOv#q*)9Je{wqJ8aWpm&{P0iC{fEB*=Q+nxHaD44UsP?I!
z=W%AceI%~AKQYs|EE*l!BH;wj1kRWkZ~>8bhO5q?fGJo6KB9i*vUI!@o@&PM_rDE^
z4FG7?{dF)a>&XcZe@br4(aQS&qcg79J1!R{F98Bb(o5b~JrEM6>ZhNWMw2nAk2Ja$
zUE({>UL@b~;u0y`QuikzV`o{6yC$T-`N-wyzO>L@G0~z;&my=u|H~8#q%J2#m;^fo
zFU`^K$<5cxg`oU&1JGfSlx=`N{<m?HjPV|rs<U<PI=0;tH{zlZ!KO=GsFDJP<TbA}
z2~9AdAE&@JAjO!pI27z-5(@qg4lnUG6*r4zBW{t!38RWQ1sXh<R{yx^ee_?i>UW6)
ztP0%scXZvqK%mF1n~(q*3ROT4F|fOkG1caev&hi;Q&lZLs63EKAYq$@H5l51F8C_g
z+yZCg5ERcq83B-vtoAPU1Y-j-j;<Zs%$rKY-*<a!eO$mmCm<RO>5dFAHG^J=JyZSO
zy_samvSq{4Cd^*tm{Q60>tJG28|>OskW6>3BwX+n4me^*o@JN{_n(fbv;uYvXa1K-
zNc=So$<}vw@r?fD@FbgJWVqK0@nDCL(e!d<Ggts{u6?|O3;z0Rr*<PZvg<njTo5D#
zrwLuwZ6zV%!n2bri(W^+2Ja1#+{p}CBhFvV8)UJQRtA0i<z|nV<c>hKw-SJCD#^zO
zI~*aDmkIy#?3S0xAZSpJS?<p-+-pkRdGT{VH}XjJKb%K3V&{^o5yHO)fNwxy{zvIK
zqkN<~B6G(fNf1~$DaRdfy=1h4<O)d;dtt$yOy0dCdJu`rYB=Z-qN56x{?tS3f{DY*
z(mWbKSR%}4D||L9t+OC<nPNbPD=m?WV6YhSHZVy3by?BPDCi@Zhdc*$--(0>yI<{K
z*hgL0GgN9}K$<h$9kGtZPVjK^GxlT4$4=+ZIAQaH0QkHzpDatVW_6ne3!wAXnQH@h
zN4+e&HN}bvC}9`wq!o%6wm4~;5@@bqLCnam{#f9+kcZT|p4eUi`dQ5-$El?2&$H=T
z2_$RQO;Vkg{zE+6*6g+-%D<@8alSUkbdV<CpF;OyyqkGys}0Brs&-Tlk{q3d$-}#J
zro9|m(z7hpz0Az6rexBiz|{d3G-Y#j>$V2YGhvjM3q!;($UK;oRI5cNTZOO1tZm0l
zZd2_9a}P20HTG>$CmXCP9G&FpcdVJ&Q*Hc5=;n^GFhr>Oi?3UEB~`GYX(2M?uI&=-
z{L^1Kj4koJCN^y6G{TS?n(E+)41b`oa}({r=@q?ThMTU`ma$y@*xNaFS@k)d^71^v
zT9_^wWvFMPKjqzr=bIj*r<+?O>(y%m)qLw~-BqHmB+>JydX;k;C+}Gi^_OwfpQyd)
zkdOgDu<zvMD$OVA<<og1&kpMc4$a5y+al5j$Hxbt&G7a|K7&T`OA)R<|Lp|~%}|f_
zDo_}j)TQKR%uevyTrMmjsDJ9^i_D&%sQWrX`5ylcLReIV;!Gsm9#G3_<x!lmAcG&V
zjaClum@F0v$Az%I+!@A4TJL0#rq^ws8L~qf<m)s)MxrGroo4>G_mDIk{TU@<gZ?ev
ze#3cvy{}a}ZtBA0ydQR_2C(JR<jRyo6C0DW?zLk62{1K0EW=e5K0?4dun_rOzpr&E
zbErlkl}1K1QMwsF$IVR^iH+hvTfqx~fk>P}(21E_%9bmc5Z4uuZz&LG#6+Aj_%G22
zNovkkG_q=<DDegN|G}kn(n*pie9UZfb-Py2tW6Vj2dbEwcr&+l{L1xGLje1LGM)pT
zw@L!xGy+M|v$g9<XXnkjOKk79vNb0}1wmQ8eMzZWeRUwVf|)C;#fLY!Ko-Z?ik&VV
z5r7|r9z<KryazpBb+Oqbne7doqejgqOPX-}jno^NQcsd4-!usPNUjL~(i!NE^79f5
zlSYb~o16D+o~zYcMzSKni-chpmX>nc?MX|#(?~*o!<{A%9z==aD{bz{n+@H81B_7b
z_>nx$L$s!5W`5~2TtL3v$rW2wWoTgB%+!=jgtveWzS~A!LPBC?H197^j~^4hle1rM
zx$N?|xSA&V>E}nN%c7dRotaX#Kt#Me2>U;M<+36`^HXwi^PKH|UHe0LzX|i37$T?@
zu{3WtLiCd{`E!ROJ-hdBbN=?D6@N&{)c7A*?+UIeG3u>2c^W`NLi+Z^mA9GGSHWWz
zgpGZNPR~}}uT&mSR=H@nTnvUQ4@R)mf46;|Xv~*J)Yk#}$Hwq?&%W+;b1<G4l?31Y
zp~89Zw*(G)_0sWHrvu1F-kt`i!T7oE>Ha*wC#ZG*Fq;l$i)Z6<2-R>MEKcHzI@hG6
z-PzTmTJDKn-=@@1skRDXxjsYLa4lx}jkmY-6qHvY)lY48xadO6<J!%;+$c4j8Ym`w
zaGV6Sdd63Z#oL^5^v2s2d&JcoWxu>zvH>uxKhl;!7(6*zANC6s=QBH#i>y<B*gLQM
z+byUNC5djXPkOoZd`VWi11@s~*M6(9{tR5O4xM4U{V87P@cbonbMp1P{sSfsESllv
z!m0`>F0RwnUCQ-chuJDk#gp4jrZ=8OH9Sr_u8Z-}Dq25~0ruG1nh)Foe(7)2dO97)
zf3L>F6MecM{r;KoyiY2CXC>Wf^X*_TJ>?l#PWuq@t+4JMaHoqDEY8QVB?tCIwAW3w
zXu<y7l76Y@i}Z=Fn^sR-i%PF&Q^11DUe*g)Uycon&PZni`@+MyUEC};)?a2{ED06v
zuFls#6Y6k3mXd{wysmv*edxP|Ra%|ud0LAd5A2_S&HwmVKORWk?v|~XgT8m0{dZH)
z-KVPrq3@gzF>1Zu4Me~D-XlmV#dCRWrT^=7qgV<eES>XVDq0G{^J@!TGA(x-?#Cz9
zenzRjhqSw{`1Dauis%8&o%7Fod*k_OTnu+T@wlGk3NJlMxSl8V!eQK(Ti@_7JPyuD
zSMI}HXJYW2r#B(j>}gv+(Rth=dns{$HTxCba*1<m4$~rXgB)(OGJbw;#YGT3aIux6
zhI00K&oP|mT7T{C{&n{}Uluj}>EHwH)5_0Eqcpeu+mYv9rS>=quIJeJ6`PmuVMb}8
zSMJAO!^`uF^4pm1?v&aAYdu=8y^pVJn-IlDOwMQJ>F}Ow>q=H!u`(CA?H+_TnSrY|
zh}=y<f59C@G==$jb*J~Y*Lb|QscZRm?F)DQhjL9?+>f?&_Ya7&A<eXIyj)i>KVB?8
zravXHD70$ptVEsRjfRDpdKU85aOFIXCq=X`rKvLVT>ligvRcGwY9}DWPZTGK9x&2E
z2y?%Xcn&Z-LbT+5oVbl1*b>2WTk}Ux15OyUT(>?KME&WmC;s{j_g!$bZdaX9u+VO6
zz7O>lpOC*F+scx1Jwf43wOi<2eMmZW<4vM)JK0{F%dZ9g0p4Bqva7gLUMJ>p?Ah~D
z<=L$6e1`SK$$?CcJ5js{(F$PPdV6Dqy+WqQojouh!gJo<_M%I8Ui_IbvgLZS{pq1N
z{As=4*y@iVgaR}XY~pO>?xqLBUR-MI3)yK#v|kMy*`+^ZiIaQ)5Dx;)AQ?M}eT}vb
z%YeS@`7i(d^0tOPO8;Ss#rkh#2gn~keyn9?o?BWT0gH=X)$V}iQ@-P4NPL<L<mGZQ
zF~`SsS>Im!DJK=``EW4rw3i$2J5!A(Ny2&oF*9pvZay_NwKXu1l2KH?JU16n9U3vM
z+lS;KH|qTr9V+i7jnVV4`)HQ;`97SO*)wY1Eq!1%dO*J@v*lnu$@rrwX)IzuT$=pe
z>s78%T8BHLDV8bu`#;jLi7Q`W!%9UzbS*df%ZHc8(^bs|4Ignd&x1mADfi>#Uyv*c
z7o6{33P(K!ZVP!ONWuX_$?Xr}-Bzx*$-J+#B?tHZ&bsYqxmLdd(_Z$VRxZPmeio<S
z>94>P&K4@1iEqFG)|%RGw)Io78~oLHB}t--9>B49@47b86K~zmx`S2o&bw*3Jl_An
zlb<F<hI#LOZ!4SMdS8r(<FRPf0{jL!G9-B18TGWgoAuZnPS1z?@ZIlRgQr#K0}_wj
zwSRireb+f@8gFW`{=$krLu0GUfnN;C_s<)Vyf0Vrk72`0x9g;BHxop1g2ayLlPiDJ
zb2kt*`?-8cG&tW;yJ>mx^iLnBtX3YIZ+qlC(;tRieUIGN<I|-`qSZG=G@p0kJKOIr
zE=To0qf!mwM-O!UNXL-XG?P-78X5&$Y)Q3OYSbT>f8>4Y(0NR+wPag;JkIpQO%q4;
zxbhC9;dwj|!Mk%JjJ(?e!)w1fD#mkP%k=3p)I^T~Tbs7xfq3avN`DA`a>x6EO2K=#
zHaO~r`4mFSdu^}{g(r@xdDMJYoUAu&wSpa`rQyqPslca-@NKme&y)N9A*8p+Xhi%I
zvWtR7!?|~V`x(TGJK}+YeIgtTd8_cBY1`yMBQ@`J`p4LF`rVc=&8_Ffq^CVmjOZtx
z=X>7g3&tPmkD-UtuNTk>h<R0`$Nuxc(KYIR!pOa&t+h(I+I(7#_tgEu`#?0xvV1b=
znhLz|@qRST_4-3TXZq=L5_bA?yPW^A3w1bR?V&0Q3(M6*92w8mqs#G)8!J&oMoJ8;
zrpqYN@4I{*W%YQt^o&}7ewiQjyrHCBer=TEY`-|@|6OFBL(Wg!%9ruz_7%sC`L@fu
zxv?HYdx?YIY`GcUd)=*X={D#kX-2AqkxpBPy!S&`xXxRXvbJ`Afs#4&Ei2=&UR}ph
zTFce8=gah0b(;9E<+fLQ<5MBYtX63DmEt$F9|O1GU&4R<2(33@n5RX=frYy}4P-Gj
zHC432L-u-1*cxm(sy}T7J|zMUM@=i8+EJ!ppj$m6y;l><`{;og@F&IL<Itz1q@;G&
z&9T#!=19>`7n<!3d(vc@a_Qo2w`YBQeZpc>zm5f|16hHsQKhx3K578-rFA&^+um5_
z<7xZr;_Ax{Wqk+eeAnyqSY{Bu9NmDURSp~?9uIcVY|lp3!$M9GOJ!vx(C}++oa>;G
zFM2vXB86|g7Bp(e$we!1OMOTbzbW_Rblx!=e?5JDZa1}DrI|Nax4ug~b=zI<u2~NG
z193#%-MMr3AttV7HC;<fm^2Q0Bg6wNnzO3mfKV&q`fxzpu%(r**`*FVQ9Lfb-{`e~
z>Cs+{%J#MyowG5a<JcD12v_6b9#_5STH=L~rQ$n7;yS|4DEHiaMPfTq+OF4js4J~6
z-R&Q7RUdxd#csA=OOo^Az6<O=b(wAci{;e~&)<(JS%QHzY@PRqxcqvaQ@v&-95O&V
zAJ<Uev+ci?Q$G{Kl(V%H-6A4_I@z;i&mCI-8qb@?T-(CgSjivx_9FLq1F>0sgZtyn
zsK-rpKma6c2#&Oz+~utm?n|nx<!a?4!7u$PrKnmF{i>br?~C<TUzhA~zkgnNK5?8h
z{bR>nKd4HO7KsCg;#j294L7!9GH`BDW3C5TYLnoFf1`spGWbngJj%Wx_RniQ+d~!o
z8AD6XdjX-1O4K#z8yVk5xo`D7TE+fAM8`{6TYktyaYZGi+nr=926(|0wg_k+>#d*f
zFTnm_TRb4H{4yDi&5n!^==m_24%`bqc`L%VCmFaa{ORk<DeuF0co;UjK=B{8{K$7I
z=Hx1hz@D+wiR)#-to(Tcz1?Z^2P+v50{rcY>uLG(LV4?<#%WP$X=!0$rubhN7lwO9
zluB;(r;9q7jWx{|gDSy51evfm?B3HRI%#6%;z1HGwi(R*7(JK296T(NF8lXcuZb&A
zavTHOKR~!g4er@5<_!b<PmS^ahl=>0B*Fi37kvIvc>M26er?e;dd<PKd;}=tV8Z<+
z4%W0p2>n|Nusig;k;PeL6jyFcC4b;HFw#;iOv#Vb10oP7PEx(vuS;+Hiv-jUKf+d&
z8-utbLQXd2cZjGrnUy%@BP8D3EV)lm<$r2{srrQ;b15kY4ZpeD13<HFp-vi3Sd4<-
zH9aE-1DoP=@Zb7i0qYf41CN1l=yJeVhu;;JaT7=8(Wh15hLt>%+>B;g*2jk^{5{Ht
zF?#Gidgwb$6lh++_<{AfnuW$?stMVs5)?iig=0p!*a$Ed?^qH7^aFwp1Wa5&y1s7e
zp($moD;GD;X6SZyZ0|ym7|L^3$E_pf<B6yDH+NQOGa=1*CG07Uf;u5$KwucGOatza
zl#h2f+%W{8fvKeUs~l#Jjx)LKy$Elb;ORPA5ZOS$l&{H9WFmvn*LSELUmVm>1n`xd
zL0bCTj&5@OziCh1$M#5kP%5lZa{|UBKofjC=E|%UJz+qgx#l4GRHignPQ!&kQe>P#
z08N#Yc?=rhCPiYl%n1Q02&gmopF2!DT|4NsYap@-MRtKYtt{utxj}>qF0Exq&jwL#
z6cf<{WlH45#q6>M!C%uk()s9^KV=2Ks>^$K3?`dixT)2I_+unUh~%!IjTM!Y{e~iB
z67gcDr+Ir&H#dG9d$<)1g!U5Xd85WG=tWnmGmP$rck6uZz3lmxdRwaeNCE#5CQxLO
z2)`J*JGW_-G{H_Bp>YgVi(m4N%x~|lTx$()%qwf|hV>e^1rbd5p3W<W8gU3ExaB-N
zCT9N<^dBVu@D$5`#R5RKkp2WtaB8kNNK;Ovse$@i)P+%%j@T7ps*+(U2`Z{U6wr)q
z0my3aY4{5novWPXdR!>$8=Yo>QnqhAyb|b)r7>c}OUTzwB*LkhB(VP2#eH=y*ZXjZ
zgE>C1R{kAsuU&5V@Ue;rdRkxkqgziRhE2mQRH4>3m{VKL;JwPE+k<M!ii$od!42J!
z2l}Y6bJs`g9}ea}2pD4~PW^BQt+dDBnx*Gmhx^<~Xx&v{e3U9loQIhj;$KrxenHf#
z?d7~2X|84Qi3MRAdjS`t7b}WoCb-`r4GaSQJ4cSX#07_jKK@tu(o%1AQTfh}#Ufeb
zF$<Fh_Pik?l0`pOB!t3->yt_zf~|TDn7}Rq=K2*2OzoIs<bdDlD3yoUbDXWvogXhr
zA4hr2o84@^ZbwARjoWp@0sStV%#B(kW-1s>oJ3xm!8re+QYC($h#iv9$F>RUg=koa
zQQN4fr%KfC^Uo4jBKs_>#rVy(4Xyag|JKP?<{>y6mT1U<1R7>oST<Q$F63hFsX#Z<
zs)2a@w=@-%afTeGOp{}}-dd+sf{{BvH7!{eo)jvjWwq0~WdERdiaoCweQ`8(UQ=nP
zMwa4x^Y%r7y%Rgll>}C~=EVWzLwSE3jao0Nq}F2NF?Y2$@jd<X5>r6Fh!G(~sp1~f
z{7kMU`XTx`nvi@fS)f4%Cbl~Kw95{oJ9isK(R2co3L1~LGfp-my@R<bE9<c$_MsYd
zDfRqCiXvT3FY{=&ve))~(Pm+P9aMm*pln}~viWWo9Wl0S8OeMq4NnAd!0-9fyWT(}
zlfT|wTm`4(po=)~c1ag}X1!2G$@k&yNB}&Zv`iF6^*31o%mHN7Y208*VbyF!IY`3B
z(TdO<-@gVkwi-9*)i;*`vvz4ojAF|$Wptp(H2NCE{3j#vP;lhbq0j3B(9>B&6#?Hn
zq)*(U`=xWT9|Xd(xPbs)|DOt00(;~CQoM>t>K5*w99RGoDg!v*5-KOCNB-8(n#kQ_
zCi{ZeC0mYHN}pcc)^ke3bZnTycLb$PR%0BFXV=*~C=iudAMBwvf9Tl9&5jhzM_w4|
zdQ@&uKeRiNRF{`k0B)GYoN_RiVecRWO#{<OeCQ)(Z=NGpU2F8^f6H;r32Fb;ya%3D
zz)hm{1vm60#LRbPh6rMf3IDV#*?C7a+unbNraouk{brArcRDOxU>wEM%y!xMig!6^
zVr1x1LcpX4;I=?1*rD)|LX6PsOmocX{P~H}e<w!bsBZ4de_yr~aj(`Sf~q*ufEX*1
z$wjCwhy}zwdrxkEY&(JhNK>)_eqif0dhqBCoNeu6jQs>B=mBI#z6X5XXiQ&C-XUX$
z>}c{s(;(jl3RwvNrLa1n$~TZB@`aR+8OVSsW*v8C?L#F;2WDHW!P;-v6DT(if{8SM
zu{_0LMRNfdbX28UDt5j6YYob>K}E`qAm$p0w3%(lB0~51?B6QbV47{iKs%LGO5zTR
z?}U++b-sBa>^aC1Jy5nPnF_t^nH|KzVhDUAdDTuoY!8ngQn6-%GiA?ma-NpCR5_6_
zcijVtVB<8VH&k?bA>&$odg6TnB>|E#W1@OB8qc0itSUj%j_ME0hoQn>k=NKVKxOB3
zDn^=^M1zFP0@d+<By>(UUd*=0xr6}|KZ{_2iJu`#rId|0)ZKXh93|>1L{Ds6YoJ*2
zmunGvuP_)zWTcHtFLjj;&`vvu-lZtpnmgK4rCs5lC(uyb6@#e|%M#TuInLPEMJW9I
z;oMtY(OAJoa!xYs0ityN*hT_~@RnLlTwn=|>s6JSXvM|KW!1`q`$5O8z2tVRxPk%%
z3qLsI{ewg@oArmLi}{i*xBTLgQB{IG6$WHmSoSpXiu3hTT2uKGCQg2%%gV|32ef#1
z9<@}f`=#$T5~ugJsD}7Qbs=I!6wA}Y>sOG6c^y<(A<qj^bGaj>TpbSBLb1%$EyU;Q
zy<-d9Hwz6U&_G=EoUyfMc9W^oY->F+_fxDq*Mzx5J^g})^J;Oz?ll<9D{s1i(H)DO
zOcfqs)_xLmW!<_+Rf>$!Wtv%=oA690AQq?zT({HF>CVy}-U{|v1DTt8cbZpL4$8)>
zD}JnumepBw*H|a{UJKF0k8aT71RUu}8wFz4_v^JvjnB(S@yCA%RS}b^s|DUQb%<cb
zfpz3R=sIf1%THfyoq2>@y9k=$dBJ^<o8%x;wvTh|0vg=kxue&{)138DfMU8}hcP?)
zK>3{ScYHLIHNTQRICz_enE|brt_b#AdIaGCCRPP-`EOs2vJ#g(Nusd|?QaAJBkUcn
zyB3ms)AJf`aPLkfSDTs>tmTZ1aaQhSw7_vxc=639YCxc!;^nNsUbe+`4nA;lUP8NQ
z5K0s<l>&S~XaNLGEOzE|3+ZjELI=)8SS+mpyY|%by_0Vu%1!Y{{JlEd)7wzQFU1-G
zCI-{?TpV;SV_rxa(O`zuaQMjOv02uCC7nL%R?9hz3K15?5s6f&^@G{;{>(5LGl%W@
zcr<ek+?qgM`tJ~0k)tIsh@uM0anApE17m?toQmv0#ytBw+!~XIZqR3nYPZ1u!}D_U
z^W1~odm&0Ac)e)v2Ggf0j8jY@JD4ZrQ%ujJsg47eN%{~WIX990`LN2V(&iAI|Ece@
zf7U+OheWxVC-*ysUc{-E^Xi(KOywvtrUyM6QUi({%@~!;H6uwlIGVj(@-1M;Kc?No
zQS#N~lG>Biig*sw!+MZ6F`0gw%~eG5ue}#jU!K<kP1-R+M@kWy)2R;QoL!f;D1)4(
z0GzE12Cd9#)>BRXDsmN^-wy7!sP@u=rTGD7Y`h<rWnEkd=cQ)|I{p!QWD%V!RwUag
zgs?~~{)59}UK|nRWkr&IfS}px+LZ05qdJ3wh23Rf`0v1aNE1?<&R!w&+c$FB4qLG7
zk^l+|)u})BdJvY{Mur#($4&ueA?h0r5Rk~QLpe+ib_Hi;vbfAxNVVc5Dt@y?=$H>Y
zo|gh6|Ctdcr;%7U?1EQELk<qr;inA26um=JOTVi_ejmPe1B|GlMh*ci0vu+$4(R2K
z9IDEd7+wYjdSR6IV$=Wvw%_`5_{+u9Cs^lzTg+m7Ye-5N`G30m>Zmw^W?vFQ3@5k*
zvRLro&W2?106~IFaCdhC!9sxG4hin=njj(Q1{QaR1r`m??!F<P-23jk=brQ4pKs3Y
z_VlUkn(3aN?yCA#bvM1TAm4Mx{Y?Lp%r-}V_=?>n^2rG*egs1umj*Mq9bPDU`Z<N`
zbMcjhSc%tE%j|E#ob<+BKkNoIOjNTC*3gG(-k<5UT(;ikTq8<N%4e<Q5ARG)k6Tdk
z<%>_4H#8NPE8}AAG@mMH&Yk2X@F>1vJZkxG!f;iZ{#)#D41aD>-Yqt~WUlfV_8_6>
zuKL%8;zDT3zD=!M?cR2k5*DX5EN$vMOVrGXu8lZQX#!?8#?tGSl;ic(3`@)4eS&pS
z&)U8Mzy9-DuGKHc{8mXqU;Z}xD&CC1c3QraErsMR+XVfs-n8*6uHW?RT8rKN1&+&>
z|C!ayAL!S4-w0hj3xdF}Ur;>lPv7!fg7f70V>#?tw(I{W&$kIMgC_mGT&+jJtrvC9
z>6Auv3>bky{Q>UA#1Bnrjvp^$ala1w>+P3V>R$5bKL`JQ&p<GO!g2r@5o4V9m(O;o
zAqH2V+2f^N?Vh?gKx&i1xSOuXmU2T=4|;6DD)7%3-+ufVhe7AqrjqCR%^04Zd@n4A
zjt|oU!!bA_O=M#3HhG<x|0p7uYR=olGSM;)w8Q^wj2rPWC!yd(h;`?SGyjYMi04aw
z7$Abh;q{-D%aTQQmRHH#iUye~hK2#(VSgI$T{lg@etUN`URaC&hfkhpb7T{*X^pBg
zmheYFCYzSAx-vSJB2mG`Yap3x8u>qChabMek%yH=6kH%fX#J)MF>@ZDd^h!>_fvZ_
zuVP8X{SPhyzYCH@{~bg;ul;X=41o6i1*(8cwOV=OUj8#fcSe~|@C0~Vx1aofIqFFQ
znBzZ89>CD^FRJ9f@xcF}{-+}UrvA4@_T2E|v1=~F0xljn->ojZKrEpU3-+sF;G1Wc
zsncq0=j{i6*t&qJwezBvtB7nMr=XyqqGJEhNS^gpU|oO|!um~XOnKzcaI`K8ou6#b
z!fUiNJ^ehsU-i*r#k-IRVbydDM`Uwn1jK;NUFmgqYqa=bz}<^1G)IR$05qJ>yFh&w
zPoC~H)m%(e`X|0&vch`?gg<*ELqLFqZ5xaX7(_2sr*v**`2glFh?PjSf^E-bb0u=3
zAL=WA!^g5UpBjU)Q$uqY?a{Vo0luDD=?=58wghwBwwAC661<H*(3++daSiV%XL65m
z@IP_LTVG-ZpA_#xk;4JV%7X=L+ItCQ2Z5eqSuM-V4|7<5Gdhgs6JIH#&$|MGgfPPQ
z+-8nadlo--#L|bezS_0Ga(30}%SU_6S&R795J46n+|g$~@QjV53%8amg-bD00!44p
zP4^g|T_NYYk^~<g)}<NH$rQTjU3D&Lz`Ovr6CL1dP1)Py-#>a#zP6|plcX8%5j?T*
z0sn4`(&7<_Op;(CNCOtB#P=r~br3({y6AH`{`*K9BRQ;Wf&z1wYwL!vhjV><&QM{+
zwr|>iX9MiCOM7&+v^EL83tq@%^8c*Ma#`t+*p6x>mb&L8__7p^<@_h7G~J;sP4*Sj
z>(#?{o=x$H9?^#AWAyXV>z7_O`2eZuyyNDW=GV*&I;b3m_Nz|gy!E3rQp4T?*5deX
zZ2G<dKWK^MVdmxn5O17-5%}UG!L6C2Z1+yC5?4E!#d<B&oXEWgZE^!Iv@)l2r<Z{y
zBp9fXO$NHXpfnt<rh9o9Ji0!49HfGYa}Rv)=^ODB=?L0;`IYejSLI|QhF2po8!8`+
zC{|wUU7$WZSVE!HCfXiej7*=vmi!n?OvzV1{5+Hi4LjPUy>qzT7s~0kCF<i2v^~&i
zmV(|OZ&F#PQHtZMH1+6KDO4#wHM+gKb2L`uYAYBTaO9+@O)-7Rs}^vU9FVGs+6oXk
z?S;cdzo0W|JyB59s>DF>`GOxTH>+=xISJD@IOvgEx?6_5qwD)efwfEfnk>e<Lf2Ib
zzpX3})ImGd_%S|RkIThOYcenkKLn1hbu*a^wgrO&6xkI64kM1nBM%IHhLE`eX-~pg
zRnIud0u5b;aG*V3w|Pq=qp+k!g`AvyP3?)^Z07I@`Hxv=wGMDa8KmNV4DlwR+To)T
zLcmMNc?2Af9(0~xL~tQv3@wgY0v(XZ0RJs2wCf5oJ<I`#@roEHlK$X<{mN<b(OFC$
zemjb$4H^8MaJjIFq=%64?XrqI`f>oq+~<FY;zFPHfe+7~$MmxWpcfRtl;pv;xb~O+
zkL&46n1S>Mn9;=6eD99+shjZ|I}DfK910yvw4qoRQQw9VW$yUd`{Cck5ABXcOOGl5
z1Iod|#Ge36)CIH?0ABo2o$=9$;cIM$fK7Dc9QE_ymnlzoic#r)IsXh|>PeU|Mecl@
z<Mq;$E-tg7Iij!tUV4sL*<bc(x>zv=6ZK+VG>1&slxZV<L^m$ajA*1KiQ@cK@n<h(
z&<|jcfvhI&MIA8j`(?lRx!$&kmeV+2deVrJVw$sVN9tV{G@uzw7So$fD|u!B-e}$E
zn>ny7HL8+_;x)yI{S6wqg!XHk%X}o3sdT<q3r*5fM5E_gubYZ?eDRl;Fo*6KZ40Ok
zH1Ut)wy?RI)KPQX_mF(T-~W-HQLS;Dc!5~03gbM8X<EPMmDV$osoxK2Noh%8FG4iJ
z^z${|3pxpIla7m+;)&xtda#*s-S@#M#p3;8G4#6E#-KaZ#UFp^GLv`dayXUO>eBAh
z$DnNjulxoUMiZkSK5{4LriDFkJ}ty^SiraIa;tr664?nyqswk$Ud5X`jO}rZIbVvd
zs=7qvmk5BYT*sd>7oJ6*KCu`>zw=#%Ewwchg<&;SAG^q>8LOG(PB5D3<OH9cVP&#b
zG_*lT7Q~I~^Fyw<om7)ZZA(5)*9hvcRF+NVZyb!g6RlJsxYzfj8>c(Nb~U>FYeJ1Q
z2xOQh^6m_oaI~tSIbu%cAOU;-_Fj!5wDNIbZ0TfQ!FmF)ZK&hbis~!Z0dzvrl2m|j
zl{r#de_2QhHne2-wN+YI{b+Ioxu(I8AA0>LDAw0Xes!8HC~XVa-7HuFoT7agrqBZ?
z<$CJ11f!TtT;!KX4UaQt;56h}DF<&4P2H@(y5}Z0;mym83dGGbg*8gPvJlseGB+Pi
z8ij@Wa>>5_;Cw|F4aH`gdFMi>ZbvLf`iyjYQ8i{!i$^iX`EP0cSM?J}`S&WeEfmga
z$Y?nXualZa%n*}}Q>5mFPnWV$(z{FN;W7T2YHflX9w)Q8KB_LArCxLDvxzaE8Viz0
zEB(5EUwkl&D&JBzH#M!ig!O;M={P+Qm_5-Sen2H)>%XxLB)>hf55>?Xg$zF3M{N9N
zV$fadff_+-bhTR7$<3zbF{jN^zu(4o*7z{k-(8h`#nbu@;Sr7RKARWW`Tj4R6VzE9
z&A8Ww&Sho`!b-G<=;2m4eitH*-)2ZgUsaW;+0p(gCum%~9$1=RX^c<MorthF9|ECd
z38`A}xT_7ysfkHbGj5h0E9h}Hn~f|WB9$(t&*wxuOuRl{qTsd|&lF<#j;rBR&B&rd
z!jeDzygt~^2-UWo6DJP}7D_bGQWXVrehSwyGXb$_Kz0-+t(v5;<o2!KE%%JG1#n)V
zf*EhXE*GV=R8dP;r+c+FC$l>7?!DC0i!H8mX{UV$9dlbj#_J(h-XQCu%FeIke&-7k
za|Te+GufRw%(<8-C6<vnbELqsYn1)|g^Dk}VXlgm`y0>F%LuvNxpuY2@?lYvTGi?=
zF860A#jI41+z;|>Y*79#PHRu7m=UvCn&=DR=pKqY=?Lw!t5i_|`$*xcb~AWIy_X&N
zCyW%uPA>}>$5TIVy<h2Ji@<`2?4FbREx&uB)=1Dt$;usGyWf4}=)FRXobi!Go=n1G
z7tytD91g@4%5yx1?1=Yjzf#a%XX9|?#Rc?!P@XJoj|F-X=0RK19<W%Kn7atpfnDye
z02>Z+%&J|TeQUYi0;dvqueP_0tOm!g$y|9JpG(vpW+Hc!Vtj3vP-^EA@tbS?Pq?$)
zM^U5`O{d>Tm^q2b$T;3)em}X{GB#uw3MpM@q(Bc&y<$UYIaTi{gVDW}y~ogOG0%<8
zf(XX<n?5h>X#;MKs;a6=N?1XUv9V#6d=(k#6=i-dGD>E-lKsL|{dN%TqkQ&iY83^G
z?fUswBQ15zj)n)7H)8N}O6n)?m+whVH}C3`P1PAp%Mm{}<B+aA?f9xubvdwI@QLO_
zEE_Nw<bBd$(E`a&*Ks#j>11g=W#WiX2nS8@Xc|1s7%8yGS44I9b6em|$)+pC<PF1Q
zoJy8%Lf2Pty4hLYP$7_5ZZ~S>a9^HaU@Z(VDgt{88dgNl#g{<~_6HHtNKC1JnSN?n
zhT|Qokm0kUE&1Z0H7qRbgDgutd6aZIZg_xE+t^gmBYe-GUA#26{PxKVf<uVTc~?A{
ztEgb{-F)d@mlX?qU^jpuI<3aA@IS{+Pb9R&oUdT9Mk`z0aabQb#0;ZdV0XS0ELFW(
zSRM5__*&X-u|yGixd>jbj;Y<B`UoyjMY6e8H2Inz2R&%#<kmL~6&os_Q7jnCVfx(G
z7uLyq^CK$klyoDb<9A$B2X7!aK-qLEeYf*-jrBz8Rno+6(~7!}GQ?uU#!zt;=t2cx
z_Uml0OqMVG$zY&WByCdafG>~n$Fb!70MJGKF)jPmD+r8U8s|L!nHqnXiz-n!F3wt?
z$IbQOsPdZs_1%@niNRj!DJkSsRBTH5t)BMY^0T9Xc?*QBAqlQ-wOhi}ziOI-)Z<vg
zg;vw9TF87=^*646PhTS)#V`cllbioIfwt5XWZD{ZQMi_=|A13bA7G!5{xquyXL)P&
zII?8Z4lW_iq@zMxtu*ngSb^0wqW|RaqDyx(Jc#bzq3`iMuem46e9rL_qbiF&0aTar
z1A}wjSdwqEmei{*)q|gX*@dHeB32Ga+63c`MzS4JF1lQT=*Yu)$o9yVWOtiJ1$N$V
zECrl!fwjL3-+zwu%pHAxbVx9`<+a$Nnr=fxC<AmguPppWhrHsF0(0>x>6s~LO|LGW
zl`)UavNTYUfA9~SKtAMTilU&NJ%}qHvdqK1%fUb3B3{&aM1ozIkl%rt_J%FgDAZ5Y
z_aY|X`naSml40}m2%47#;T!6!jr^69Q3`3D(hNtVe!F$L`BV@gyb!aGS2c)2BO=Kg
z#5;F;^CgIY@R;`3!0@Zz5yx42P6Ekmy3PG+Wq5G+r{CpKtk2U_{qse_XONR+eInDb
zVDHjV%dW1j@a>~M+D75Cvc5u2%ULF~)P#iDF_9dMvBWsgBzx+kjWl^JFAO>Q;I5qM
z8dtY@+suZxvd^$}^K&biqLQ-c@RVT8yYo1vl4-LwIBu@CZkICA=OMq|TPeLApG+Wr
z{j2WR@_udWqF(G1LD84_(QjF;E#i-Ln$Ng?aQ?}fYiL*MWA3?+ztT>7X8P*Dj0vjp
zv(3aaRhHl*zfH{ZxN}8n@f*CDq%=6MR~GFPqPJhywg=#$Ox>mQBtdip{aXkft_zlM
zk)k#1NJ=cpht&KXn->*TO{e06Kz|CyCDmN>TC9uk?8{MAvm&+mbbvA2iEd0jcoDoG
zH1moI5%E-qEVbBr{U<`$%W5M{doG&G<!T?Rn*_t^YWPL^qKcumxAHHc$TCg(>%G`s
zeE<Fs-$Oyakpq~a-<qZvbn8aaXUfGY=4NW)^+yK@{nin6ovj!SgV&*M`p7iP@ONio
z4918P0}1C)IFX3kWI2fPcyQdXw!;JaZXbE)zP5dlsOk>-S56E4ffzMUn$b-Uk0?&E
z7Fa55g(x=p)V8H~NKUPAfAM&r^anm|MUjv5DH;^tf!7!j5m7*<uW1fT=1ix}PN9!)
zC?O(^{&sb7Q4{pK8nUoe$G%YGBsHM%Xey<Z%h{+a=QCeOO<9{ZB|&CgQDNX)vh$!c
zXlL4=Wuy@0_hCBDXV2*E!fNVx7>rot{@|TsrO}ebXB%WyvFy*Do$#!kL?#HEm8+Vm
zk1@ekCtMV2@lU~u0Vf+C*_0E+#7JT}%#?;nE_sCw`fO5*0=FM9m%I3vM;~VW_#uy1
z#{46U3-~;3&t|9cf2c8taS>pJDW9_Xy%V>H-XA)mmuc!d7D%7^b#lYY#Xh2tB4|9#
z#&c@QLr%$t@~rS5uie#5E8Hx&7GPuSeY49SA^TM9tSffvb#4xnSTl`u)>ip!Y){yQ
z_}dy26Pva1^WTe3kE}#6#{Q(62rRtqeu1-eiJaPEJ<p02J0DO7Ucn{wex}d_`o|Zi
zZqsa3QfNfX4(88_mQv@30njC|E!}Y;TVmTyGUQKxs&gXKx*;>`#<{qy%19MK6cmo2
zXBPifD(<5+7iuhp{V!jD)5DStQUrwn$Tr+v=2s7M2db~RGYjtPdHOhOt5ZZ%XG$1!
zdinbgF0jRL!=J2bXoT6Mjj|Xu=`p-t{?ac-3tEuAAJYyk<Xeu#)IF(O<aPf8^?hj3
zhJ!+w#E4H8?iMKH#j>51n?$_Q8Y|_GI^l;T_*eN9hzX?NE;Os&WF_k;VKt8q>(zaJ
z-n8}60G6iYcfE!LQ-!J-EEf<^fpBMP<LFhZ^A;ONe{{TrJkv{sP>|-UrU)1o$I6sy
zHaIhwR3fk;#I4M8k}YtdHB<7<AM17R(xLaL!Nblv(TR;>br%!3YhE3Z;RfFD%aBLu
zX8xMel?FUX%@?bYVT&TvqDBJ=ZS}ZZb}68zAIK_o+U)IKF2}AZs`mcTB-4c!$iy6q
zXIEce&UX(8E^cWxoPJ~EsvIMTun3FcQRrwr(A8`~{HnCA5I)J*oT`9gi@l|2^A)BM
zrsu4)$0y|GGHp+3RA|0*EJgdN#kpjJV*P!}Kg_sye_sc8T??SkFhM(UIHUMJpuLSz
zwD@?f1@gLw-eF5kq2`Q+b}}Dn^s8#r#ej%5%8TjB<FXg^x?+*`3C+!5nBa|4dd(5p
zI>|g;`myBCAC=o#DHnz80});VSBO_LRji09gYKUrUIQ)fxLvZmTi;5&nQOlbJsI~p
z&7{9#>CEEVxMWe5>a2AL7%QU1>L&oT(4{+rYFl%%n!jALTN5i}@tCdt=;{<d86$q+
z^c`{9R$s8w&$|ve&MIw9NwIkL7$kLY5NVxPvH$SV+?X~s-g|=Sn;DftGBtcSMYMG>
z((lJtem)Jm;gXb2`@-IBT=R&s`*pz!KN5ZUt_&&<1)2Gr00e;|0`ky2<k?ToBS%X9
zRV68_`wGOM72Up2{u_}u1T9Q9L7}t@L_0R?tu5i(qv-9~YBz6}Eu2(3v1PM5R7ugO
z<qd*-X>$Qu@94r9q}8F)Mz<DPBZ&3mxqxaL^rX!#AJR6=zxJw=_Fdc%Vbpqu&={|p
zNv$}SjVY|J!X9C2O7u*&iz-Sw4~{YQ#H3oSzM%n?(0v3<G+`e<zQCdP54Ci<jyc=E
z&dTa)XJ2zTvs{RIRpfAv<P!ci@k>@b1Z`Sr=TjYdMEDVHntE_=Wl4YNA=iqrC~udH
z<({$cy%mE=X<^NKE4!ROm-bX5=QKh`ow@>E3_;uOg&GM-URa2pxX^w;_yueXBm&+{
zn}r$6bF~H2$>_7{G8KZ4Tq6fiQ55oLf|Nmnbq~U=qup_(D>p_$WV#zw3zfje#Z8oD
z5Tfg%n`v<?z0{QD;Bh;l_S>rP=!>E{|Bi|OCpT$>H%?c!Bm?YVV!Qlu(bV0|O~1oe
z``cTg04#)&zj1_BGm9O+pM<%Nnx10Y-IibvEWCln4u?wBUH%v*#*cmXf60VslC&eG
z5wEWw6ZLwKO(M7x<tj2C=E2~hcr-g3ArvnI@5J_-uF~u&xHGGiInW-H#=N~tNXYfj
zJO<T>f8=|P%=Q|Ew)NCTRoY#<K=&C@5b!ziy$}BT91rh`FVEO0o;aIAc$5d7ha3)w
zKZ>@upr73Pp<w&%rSHM@>KnN)Gik<#J=as#H`V()n&@dwUlbX(!Rfl!9o`wiU0adw
z<@?s@iwVW&Ycg_()J_L_8-ZSbaYHU@E<temyf1%YGMDSyj#EFML>+b`^3Bys12*q9
zJFN4<pRENIvoBzhK6-M)citb;DK<J?v<{n_M%>khPbE#E%9sN#>n2pd$qPwNP5jxS
zfpfxY9wyOB5bMcIu6vEUjNd6j<sP@5WUpz|yYbxd?-G|b(bP<)S_`el1tcl&q3C&m
z#&m)57vSspMZ__#g5tAf?)az~*T5gpal(&O$CMU)l(eRvKhp_CLO5^e2!VM(cb6d4
zOK;v-fM&UH2wwRmsJ-dgLkwBi13|?;98P=gbi8HhJ9l0$bT9!Cd{E41RZ1|YNZs{q
z40}F10G0D--*v6eY+cM0IE_gE_CxGXBwU9ZW0^EXu`#xQUbF}3AsFX6hc~q{F@C?t
zoM#pv1I&iGW*;^tot>Q}B_;VB02adCJ9LV)kZiv*iXaRyznh!e!@D>Q*9QU1sB0R1
z0%ZJE`u3r&u5M)EkQ@6T9<78PD3(s~fg}A*8zBb9cYZM_@J{(s)l`ZBhq$=YBKG(1
zD_c<*7#Ozi$$!FNPinjTa4EZA{2IM8j}45A7#KWC7)|iy7x#cuj6gn`+XUlF0p@K2
zFuqMNfOquvkcHj(oBl0^fidR#H}^6P?{E4~>OYJAi~7%^|6=^lqW@(4Uy5S<?~KXG
zxjue{;^=@t#XmDQno8gFpxt*C$`{p`5e}f&*wv6S%Ihv=?z=+UcQAyy9|pZg1=!fI
z)x2!Qm*a=jd5<xG1|*z}15Z<u*D81d9@`&iEhy!7NnYdDGcsz2oO)9X-nSJ?i1af$
zr2k6)dM#=s!l(Yu191!tA5)%G&j+<|jml(hVBLNHZ<F|Dv||J+G$AedIU=IxKTew#
z7TZf({j!V8ZfZ(M(;BP_S!J!Ol_!wvGN<n$FI#h~Tpc!|h9fv;mn$$?fZl>*)q<EB
z{3AYdrXjmT<Ab0LPSRolHe{l48iqh@31ZvMNfmqQ!w;gvaox3qWkRiu6MOFKB)zv}
zDozWhnGP+GW{n_j_m*r2`?;gM>ZVy(swFkbYhZ@S#v9%on}2%vXSb87=GKHD_c^NB
ztF4o%<_lFuJI|&M(oPEJUh2_1QCACyuF}m?J4N+S$Wp!}wmk3W8K2rch1BsBC54Cc
zwVxGth<8S(Tc7H=;P%uL%{_5BGNdX;Or<zkfhqTLKe$~|Q<Nx_*10VplAlnGH3Azn
zPE|DimZq|$mDTqPqCPmj?I8|#R{JZFa>0D6t@w!}3e2G4h$lUxJ1MTsZ{iY~i^K}`
z=GdR@8$$>b4U*-Y>o0V2*c6M|?aKJ?5yr;ZeU4VW&pA+c-jX9&MN!KG;{PyOjI}v9
z$Wy~w7gc<{7(Zu~$VNqJy;L>?E}3A7(5i3awzf)8&t#}z@(+A30W)vU(;QLDe3xWs
zP)_^p>(7+uUWYXt;;EmID3O@N-TFTxW|Z#g>wD$a8qN@FFBkP!3F?Wak3YB0uF*lL
zW%{|{s$h8?GPO9hsUl_;{*h>n`&_J5@v^6O>eK7nEH0D$%*u@&Eh5b2ZAlaHs*+^6
z^rp`S1yYY+gpF>d$!qL!SdFWE(UBZg=$p3nDsO0hURqaQ9v`j&<zUR&d!1%;t)87_
z7^cXt?9m&@koS{xV_aY-EqLAT1eWYPd@9xIHr%pF;5BzM1QBpN#_0Q8i?pnYx!*7-
zxSel>Ex+r1w*p6{VxD{~jN7Vn%3A|rjE(C((t<nrKy@mMt}mDXW4Xb3&Hx@_!^);z
zWqdlHQ;to9TQ54V<(vsuvr5_tXVn$ub>4A%q?>cL-XLA*&>|~ZbKKik>R~!O=)kVV
zD80uXKCS(>SYEHGQM;9Y(4gO$rM@J`LtP;5TYnkzRn9<U`Hp2X(gROPkdLp8Hrtag
zEb=Yc-Z(MwdaVk!>HzNPf$rI_mYB&Im+osIuaJnH>%J)<ozE#gt=djM=oOIJJ8-Jw
z4IU&pQaHD_j(kh9r%tvvWRXkCkVLgJIKTMx!82p+68aMB+&Y?az`b{P<Zik1>{$CS
zE{T*t<j!u<wvA7Q`|uI0ou7j(za(C_h0$BtzMRRacXaYoR)cV~dwc`n6k-x$tg}9H
zSDr<7Zq&GTLq3YNVJo*}T6|{J&u4AeDGD!bRzdk?%|M=Hy7P?GE?&c14S9bZvzNaL
z^xQ{V+Bxd@EzZC9eO~*HcQ*Rn;Id55`src+uEv?&o7sc<U5>h$`@4j@15egHWp78y
zPJYvTGOJtx>4Sc|=(&U>mDw!>uFfF%TK!~;<FPq?egaV;)2&gmcjJ<lMUIEb&uHCL
zSTRX$b4(UAz~$n)V`ZynOQqtrQLmZlZRf={x~J7=fh9CkW$B@fJvtUrUH$lz#@nv0
z6pfsmoM7Zb+tK~ta>yem!uX8@@<Jxcctet9?*PQ#wk_AtnthW{<!VqCWbAWQpIbD9
zKsben2ncX~$=OJF0Zt2dPu7^#E2quP3Amc74<^%%c+Ri-lqLU9NG!u6wzeW?#@SYd
z!3fKlu5C-<UaUBgk+bl`bU*cc04kauumal7S`A{`V=BxD2_aB<$JRR>DS*_~p5mD{
zF$enV*?@)51F???i#b4>>m_X&yHA!)*Z2A^#<GCRT-KkQY|SceRZd1#85Uz_k?WS`
z3#T^WqwCxTLw)sy?Aiwd+92y)?W`IzZ8nt`a}Yf?Lb4%e$oOg%hYGMzgDphcDpkZg
zwJEQzF2VF$EGx4GL};<9<P1a@QXJG1_VeRCB9(W3Yc(AY8cJGX!(SyhgB~Z<rpgG)
zUym93R6Dnmx+EHRCPbN9GUdErOn$BYZmwx;0pTQ-B0rP)`?j=QE&{&p|M?RNZZUNu
z{dTVRXAa3Tr<0(KlA+hTrWI1H4IMLlb>YuJ3`LIL^&Rzcg9~Q;X-V?vKp}Oaa_U$H
z*Nt`rKM%iWpG(l--sh>fTG;ict-M0s6Q&^gJ4!y9iFF2nf;BX?nXoe#riM)r0U_gQ
z^CRnTUzFOg%CWH6R0!U4WLVRC{)zEZcvLz25Fg(=1<Z+zj&H}tHsfRW+}~3*)Wu%z
zW_uRq8wwX+ta2Q%$Pb^DcRIU&t^cD_9u@waqvMTl20iGp9l|xhM~`s&ggd~)cog2C
zG73iS&er9*$?(=_>>;1KI+(jYFJ9})+hG6|!z?2`-k7}EkNzc6F)FEM7grOFqS@o-
zot6py@VV6gyk)7c)E_Jv9R|n?fW*{)tj)+_tFTj0)M3AUQR_+et}Qjzt4^D!g-?K2
zKvtez!HqjU!=7K1wWj7pX<Hqid%ljY|Ce75?g<K-qWkBe`(vFbJiYm>D1pv0uiRN!
zrr5lxiu0&^lwQ4siB)~a{`+_O`mu)k6D>0oB~nzG(sQgI*6v?ly3LNKTjSuLjlQSj
zp#9Y#xL&okN_P+AWtzWQ<Xp0@#*BKkRY(cl@zqpTz#kBy-J2+l{)liPzj!uXtU)<p
zrjoK_%RTwm+S*=kr}th?E%FM@{^kmt)e#DgPGk)ahwZkI%_{MnMwh_#iJc}Osz*c)
z$Xy3R8*b(!HTMSoQlU)sMHfH(iY%>sq5PeZvnB$NQl-hpW6&y&HwY9l6qTDpi+~?A
zw8&a1teYm<JO8mqq#Xb8($1$vXs?USG61_w3ygfV$ae<ugqzsD&ltDtES~bpc4Mpx
z_TwX$9ehw@*BPT3%*%j*Vb9ix(3DM=UyXp-<Rwrtf@i1QU(eE^zLv_*ikEBYHc$29
znwYGm%@s8;lvjipuX-EmPp>3vBkY7;kw`+K>ffz)MxDMZ2r*W*Ma|Bu>%zZ&qI*Y9
z$j?7XL|Et`o0Sw-53&hFBGfoGUyZ9k#<lbpX|kB?Cd)`BDEjRkV%VM$<;p`8PiYBb
zc_15$Dx*_pKs;p4Mg#>fk+5HI&~r&(c1u!<U>n7Is7e@HQQaa+DIRP`M?JOuwRkEZ
z+l^A|oECR}>iABy9GUJmX>`~}7(Gxi!1VIUIKQTWFA9gG<rqiqdx}Bo{wauxPzr);
zW@TFRTQiTu3fV)UQSq(kC{)E7t6w^gWK!j&rRlHw$dJltxdT+}xP(1<tD{70P2G!Z
z*Ze#-4z?j?)t{UhToNVJPZS{&jH#wY%arbWoF#5=rQXc@g0#I<B;ZSxoHKt2WBrG^
z?wmC$*QZ44k}L4#<T-NjCw{3Yd(M{I7Bvt=+T1Q)@v*25qM*o_$Hm4rFAq_vKA9I~
zy_(HJ*<JfDw+$$bk($MQ%P9s0hu{4<<iR*=RDBX&WGjOQUn(q!8*87yTnheAt<Xq|
zdo}4C5f_eAuPcY{nCr`n<Zzw8--z?5PzIPq^5B9Y0Q_UMQL^DONTiT(qNY}9*5Z<B
zkinghar3GE^6?~_p>E9!{trP(71KXB4d13}QSgJ^v@Q2Ua=4EoPNN5nB0xDzjf9Gk
zQM}+gwb9Z-9roGnxb&DaDIB`2GaoN5cCd~nHf&!FB?bNZzW*+Xi6e(F0&Z3VTu^iU
z`KvfpIZ|`3hw-oTR8mFp8z5YUZ?jaM5);H{*U7@pQ6i7(gLQ@)RoSLPLS|@L)JV&U
zVq&JA+D1LCcJ)xr7yxD&Mo5j+?kX>fzhtjUCX=O+QQ6NksN<QB`k#F9=$1{-xxA14
zHANh$iO&YNk{CA?kRXBlf}hPqh|Aa?12dNo(&^X868Z|M?j}{xcfPo8jg!K*JD>eK
zTPN>awL{N1s_em(f2{PR7);{~A->LQ$0Tl;RPjiMZ||t6aok$bB2S6jh;_Esw{bBX
z*^KT<zCd@@*Pk}Pb)Tq2elTUnN^f_y#8v8eTEb5teDk>Ywo!H2M+x~|dWf*985ns8
zCV;bIE#{2`d&NPpmZ7I(_GLsCiDG>!o3j%2Ec`1{K#<P?hmb{k&`@Ih34fZn`e5t_
z7vg)|4XQ~&(*{fH&effqp|j>3le+MTG~v~7;G%OoHM+MlW;~N3DCY^Y(lj>qY3Vzp
zeGIHZ*uO<MM>-mZT25QFCTZ(NB)q|@8-oRl=$%W?422Xa!fD<{)4Fa(U9)8OTw*Tf
zd&{}y??NXj$f@{;8n2n-JNqo04ZquP@mlsS3?IDif<ME;SWW_54(!o<NK*46{TFO1
zq?sx0w$7ErV)UgVbhc|CMMJ@ll4kNS!pBYaGMII@VxuywoggxO4@+6$YLg~aYIv+F
z;WDYxOHxjb&^AEeUf|rGWgzKYjQKMFS<*{_a@a7Au{|Mbe1q3;wXM;6=JJ}{REUPO
z;(Qc?;~qv6VkIv*U4dT)LfjK~<8Aj4GmO`Gr9g!8YX}BLBVR`PU!BqMqyYXj9P3tn
z{62jDAKKq{#RrDZ>U&PwMlJV%V|)80-*;{Y2L~W377mB6eDG)k{vF8Y_xoYc?}-V<
z<iYkf0t&}ReNIdM*X2OqJo)|6TYerth~HOIFLZZf3XA-CG+5)@Jm1~jy*f92OT_%(
zTc??}I6As=Z~#3K%emv{S-ZP33gkC7LT)#7#c<RO`aqCU2+z#S49EQQ+QNd_{8st>
z9tD{Dv7sj^@?oeb>U+29@RtJoPaPwnlsKUPeii(K4#k!zubd(D;f3+d?WO1xJ!&O}
z3r@rwUXa)6lwVXz=l)38QTAG=dk9dMr9bx)zqhg3RTd!C*VnhRv+EAS_h>1Q&UI=F
zV)1A^#&XjG8TVgHg3$YB;G5K&fFl@9a6>B^)6MtQVvN4epUvp8e1+tjn;XX{I)EYh
zZG8Hoq{e7uWG%c<Ion+)`m~F!5Eet0Azq1Zs%>vwW$!Ehc!57FJV{w@#7$$_Zb;)i
zK&aE~hiG43dUTY&gp0#|^<g?#KIO0SfBq_MQF*N|=0J@oVB@9(3!W`ehl){-KAWPl
z9Nh2B8b*q7XOf2&KQktW^-(4l<wmq&Mhr2Xib^mlDVHU*(e7wFC$-6_^kIQO2eFXF
zq*J70+D)JCB6@}WGA1XQ5+v*ew#<bKG}dS*5A#P9tvy-A>Cs7WC{#0j@B0+K;0FTv
zbr+Ld1AB3HC_!r7M?lWp@&cty7KGP9BChM@bS*JO!6MebeDt79Tm3$+mBZz0I6zCh
z5OS3KX>d<+S^qTz3P!gL>jD5~y$iaD<PlXjlIeod0*@E<%xRAo4m}j(+RR)yH9!q^
zkdc;URl6)<V_yu?Mp7A|6f{QWdp2s_&4=aNZj3^k98W*@K=A<tid8l%78URSR$i)$
zGW~RloZuxwBNvm_wMA>qdjrnT+bbN*^nnU>ilk+5v-w??WeU4!>Y)_ymSA^wmHf`3
z!P>PN3{cjK^K6&0?yR;O2Ez99RfDXp^I>@>M)`(P0h3xX&CV-FsLN5Q#oqjh-pvGB
z)ag>x|1>`0#=|foh7sHx)Oke$Jppp%{yay=9??HBJHU^Dx&vysIN-EWF*-~G9!QwD
zq>Pd;g)ua=XL;<!j$1uwpry)G&1h8AYZ9m|=eN=v`hX}`Xe`$b&|^nrd}!cTPE&7N
z5Ve|{ZR4Gsh;V^!o>PPh_l-7e_A!$<IAqixMYS1gHrA93Zl*!%_D*>{Z0AW`-un!W
z=>tv>)UG?{>5)_x<>~5e?M-mPU2}G^FEWr?ymc>6&y>d=)Qsux(vz)tjpqa%L@y(6
zZzub*w`Iv;(e0c@0{6q3O-VgOy|i4YyZUtYF{q@t!tx<?06-$|2WkeG_I@twON)~&
z*LKtkPgv8b4lqdPj+(2iiiAP=^P#ped>RE{nA61&7T_8xsim5dRDj|ft7X+b@xqi@
zeFgdyVC0)u$?f&(<r52GDm#gD+ZL|H)a#*XSwoXq*9kbb_f%s|(cog5_hr)~TK4ER
zy#zvcH#wu4rr+j;N(R3fl{KZVC@qv!bRk2Qd?kKSkh~-QwADR6`N?;>9>XnUeIvka
zsK{JV##@vqP4YbodT|6VW>$Xs<lf49b^M1l3mQ>(Rf3Q4%*sl>-X&~+P6P}q`hYXb
zY1cp}dehLqhR!F37srHdK(8vBF^PW6DYqBrotMAbk4-h)(3ce!{7!!Pv<`ffj8C7M
zy4g2kO7cXETB^%xS8(ZSkDEEv_ssA0+;k2+S;S86;I)__mOQ1x$H(7Q;>PJF#FE#}
z9VLHmQ9j5W09}($u+>1wbK#f|6IA+x8O6j{1jVasFV~w3##ikqT+Yh&Z6#bPSZv&y
z=*YQ0-41qES5Zc3tnN-`4;o2r?nhG^y7+2p&0l4iQ9CL2+&^E0NH|P+|4^13m!vTa
zkJ7F^3kP{E^^A5O99kBqO2E{cgyd|w5euzGG(pP~N8Mzbiq>e93)hm*Tqin1cIQfi
z)a|rv$wo12D>rOX%DjZK*~v%AK&RP!vSDrTo@CX2!bL?s@;boh63+%`tFt+-6!fmp
zZPSC*8oZy`p*LMBMGx%I1)_A4JRgGkvW5oDWukF4<)@bq<Gp5x#RO!3p0q8yz5wci
z(S)t!T^(D{nxh;7I4TWcN1nLr|IYT7x>!kYgv-7@itMdK_Jg2!c-cGeuB=n4Z$9A1
zqho7;^+7|8Tz|mgG4T~QV~!a`!->1{k(=pS^PLS}-ffSxao#xY%vacLdN~fq8uMh7
zu=wk9JGbou+Oe6-@LvARQnoC<9XPgZ8us$Ts%^Vl;XTPO4`M2XYqD?(M`*zBTag;|
zqTzAvC3d8i{$R&F*cM(Hb9b>z?=EJa1P5n^kel?`N?L?k_PUq<>Nv9t{?wZc5tG2b
zJ?U%Zi*$SXZg)R3XD<P9?~ezUpBJE8Pc=G@B>HN~@j1M_5<_Lh>~t6>TRkUM-E1)L
z#!x%Nu@-c;Xz5*yDL}d2OtYV~@_3)dRSyAi^I~-X&=xM8Y8IATW|7;SY|7z-EXRm&
z_q=hAb1sm9;sh8?oiyVT-;5oQ>gr|ppfr-)2xEu&Q^{%!hUW6;eVZoG9W4FAcq053
z6N9@`_5fBV?0o8MeA-|RlR0HqNnNVe{@Pwrj$Ic%z4|WF&~S~+Gp|jKdt(9@dgx0=
zs2Ht&0DUT`&HK}mPg**9CR=pBSe75^A?)W6x^Qcpo`2Z+%3D!Wb4qZ@H}~yxJ#DX_
zpDBQObaD`Ra|5_Uo6`TrS%br8_Etu_xQQfhF)wL)=*iQkPc3kWIT?>oX3Ee_CH%j*
z79V94WE~FIp4#Xq3X#3g2(?<a{7hzen%lSbx<wE@_)ht#!%JUU8G5CJ528dUT8M6|
zKsiH=nBJruu7uHM9ni7F7W?+;5(2+!`hb5<W&cTAa<ZmLp^ObPef&d7qD4!-$3gEa
z)yP`KgmYBN97n#3iR2BoAqzf*%i=`CquZa)l+Cuhj12ek_Vx$vx{F(0gWSArvLU8L
ztk07oN;>z_uWwDV5Vin#lU<Og0u4Y;2dn%7Qang3FzoQ1>E&w&J4AR32`P4U=U($M
zz#gwMjq@4~zQBQ=Y%ZbdE*0OxGzxM6WPn*I!*gex1@=yDul{$-ok_PDU6}W`VWm{k
z+3TAhM^m~qkcd5B24gPcf*kh6Eg`(hVLm@#5s1HL{_px$A~m0O`x1Gr%W5t93@aH#
z3w5W9Z4%(Cp@2=;T>oscZiYOaU!)`G+uBRvsJOMe!v}M=p|Hc-;SNV251w>6W9NHk
z?^H&BDoVep>zwZ2;?(QxBQfwuE9~eU)?c{6>Pj(f(71-;O3<0$7Nl^b*Ar|%Zzc7`
zBDm`9>+Ab*P<zYtk1&_i!#CuiM<*vX4h|ODq@x&9PSjfnM3fLf4Wu#>XxB{JM<B{!
za8CV}@x{gHz(6$w0%7QXxv`ZU08jvM=$5^O^{3r}^zdXa_}*Td@8xmhlE2UC&O2aL
zQrll&o_Q>KZT<fCnvp0XEbIXQ=-fVlo3_|oz|~5S{SI|I%#2)FSsB2D0O4+tk7lbt
zw?NOh!|Y&+`_7OIcIu{r@k<PhyP9$kNp)ls``z0+xBtkuAiW=w05}N%8Ft?g;@gvd
zfg%4rRPsNgEdLMi&A$Me|C#as4Se%YaOb};{+}VG|6eM5pF{Ed@a5`1lpK0hms<6C
z9+va7GwHy;kG29#OH12o)e;kf&outGlUMKpbMy&?3l&9kXD9e?zrqOIP0hW&zE0-?
zbl9q9YZ)0CA0JWZNjT*#kMGNj+Y%BIlNMQXivNJ+mZdKP#`nxg_(BhgZvP=Cr39&X
I^*-o-0byRTod5s;

literal 0
HcmV?d00001

diff --git a/doc/assistant/upgradecomplete.png b/doc/assistant/upgradecomplete.png
new file mode 100644
index 0000000000000000000000000000000000000000..3f8c7f3c2b203e96c149dea3f4d8d31e94673939
GIT binary patch
literal 4817
zcmZ{ocTm$y*T;XMNR=+V3P>jcQVdNHDT4GaO_1IMLXj>?RRj$n0SUbb5_)f;U#ike
zs3IjGRS1Sq9`3#K%=`TF&d%<hIcIkE%-K2no%zJ;>uTI2XC(&!;HH+Qnjrvy6t8Vf
zQiAK1;#nQ#^>)KvTSE=F`g`QG6~nGQWG^%={I28le@_sQ@tOJBNdnb+@`z-Sf|-_H
z{s~z^CjijdXsM|f2hHzhc|z%D;Qd$Q!{%vs)o10p(rD9cQM0Xbk)5-;E}D@<bVuWi
z;|x?#*!siv<Qjp+32M)IMXi8S4^7K}A=eDArJ5%hUgIbN3)QHqx2;rEJwBpr9u6!H
zpi&Rs=X??f`SEb(r<__+4shAb7ZLqjeM$R6e*5ci{KD9Iv^ZUSq-ySh;TDELU+|un
z5CeJQQ}SrlwKUaSAMIRymjy$?6h6CK<;CYbVDP~+h%&<<k;8Z1{`8O8X%O`V#8GUk
z*&7UHzXSy0&M??>TkZB{)I(J{N!i7cRDqC}&mi4C5Z2o3NH+#L!7@5T;qciTch}{+
zp&(2cx<*xg+{6&=yQA{I_c5?G{7)9&8w>x*;va8xpIEdc%WB1&;AY4pgLjr{s@Dci
zB$w>{Q;aqb*qWX6hWLbkp8n6E(WZ;=EBFM5;a0+%MhN;Mykqlo$n7;5y7(<<Gitpv
z>)XYz#H%1UjbvY7%Ms!aS5w%#kWWtV=a!AM{@#;`!JlD%ZD$0^m?G7UEk5iMmNGH0
zw6rucWk6s(^`V(n)~*@SN&>DkJ%=sxg0*3DZatEqql!3R%0#}0S?_xKJ!bqmcaY97
zoL~~r9>xwZ`%NDGf-wT}%kms;rVm@*O&-;tXA(o0)mqP*W#i00eT08@S6K=#`#lNL
z*yqb2XMxShN;9X`F^&58*T<^nV(U!-^?aWI7258*^o$LFd0Ke|?)<N-y$Q?-Y3vm~
zYv%Xnu$ZX0iO4<?pit8!Iocj<q%yplJ@$G8U;&sbS;!q<u<!xEFJlygCkxG*8wenx
z;Q}f#kt&Rw;gL+qdy}(q0JA9h3?*vx`h;BNMx#t@7E^ciQE;VGGN{t<53vft1G(*v
z80`U__ii(Xfke@g`MbXn^F~ac4Z-A7siCI7HM;eB*O|q$iGdzM+CwVAKSkAFVPL2y
zHdM$3G(0%ek(Sd&<x@6+89hZ@Ok{R2#l&>wk#gVNidb8=#T8pu__7xp_!xBYah<LC
z0B;L+*LT;77!+(A@u*cTT3lk8C#D{EB$-R$c{9Ra8lMO-7RBy0H>8jJ^=Y1E%jInu
z@el9vFUmirchrpMyWZ}7xsiDz@=vhx(#*oQ8fwu&<Hfk2nKr+q`&UTT?}zA~i@oJf
zQo5TxQagZN&_^^ijM39*3}qTt7R^>)J$LDsp}_2Wm3S)d$*NL<H8=Nd6tkt#_pBZ}
z`A#;!kGDvb9K!~-2hI!8xstp`FHQYjfDvRpdk1=1YI1Y2s_^r{^V3*czqHTAT=hNt
z#1iea5$;dAX=S0eOUqY@PmNJ_h|fMEbmME=377LBeg28~-8zIf2^eP+yvG%G5%wne
zg`8-X$G2uk1pZsc<Lw9h@}~DSWOd|T_3=#d^w+vIJ?z<QUTT!=nA;EDyuG1l2ybgY
z%X$lMxng}MBU(1aYtjDI`{lqb_1<dDsp{p%uKo@;*slm5XecX@S>0Eq5#$FBITK{2
z+GNqJe$}rBG+dmDVspyS>$qBhn}uh>MLM(c?SA8@CrPEC^W5pvU|T2b+4k2uk)^h{
z2C6!@mXzV2CH`U>-HMpt6HU%q2oI0pZwrSihF!NI1FNP=vJzJp^rnkvRQNN;&_Tvc
z^rsUsa1*I;nvcnl4Tg-X+#6n?B9gFJERVEm`k0XcakhzvPA4iAWu#wB%kl5RZCjJw
z?r|)2Y@#%{-gK{WC`W_`sEnm6X^{xya55iSJSKD~jVNkK);jW#*7pc<&o?aH4K~gN
zj*1FL^-HBaa5>#1c79%@l&r79vM#iRft+a$g32+aR3LU6>Ga2amnCx6JT_Qwiwt<s
zCQoEn^Ei|GmeX@)V5R-0qX@BWe0b!W?pUC|_rQobTRR?>zv%zbG4JK~gGa|a$(?x{
zHCTK8`Kh!u1Uv@(i+?|`mi&RuVb`{(F1jHJ5(>!775hf!Q-!pgPo3)YH7f2vILM<7
zjf{4q{qmd_?e1<VtyQlx>FO+0i@Mh^0qJQUawjmy!519&r{$~t`o5+I$?Ne=<YZ_X
zFE%U~%;4-blxJ3j92Jtx9CI73%G30SA{QfkLBQ}L?;$$?6tE$ctOxD^c6m<{=bZZD
z7RM)`m6r>kC2o`;IJs3jzFVhgFDO>woQ5_i01uJQu459xtpk<i!v}d30K)RGL`<gH
zJJ)3qdtdv3(N3IS&CwA{+Vyil(2LR&8S)>#6%wh~S(x(Wr3k=sb2a(s;?=IRZ5(Y_
z`ys^k(#|M=*Y?cBIS11-wg=g-cq`3G!ORoG8EUU(?rkm*gkpZ)EwJ*M$RTW9l$OXq
zznUbTSr(>Mhx3-+T(~{$+1L`4aWL4TVQ<EF|5J*Y-*EGq`!bmyol?@NP~yCAoLGN5
zF{Pbcaei-ecnnl;(u*WiKe?}qS-^RLwYXsY)@Xc)&MjwnWaAVD3dz!~n5klCidQRG
z_CB@>t?$@{+FsS4)Yk><VdxJET@;fA#e`oVJm5>{k6!m$U*-s)(`vRZB>{^xxQ$)~
zdWtb>dofF@kV54O)g%+4pR3bQMt_?c<;I~aQ6SS|?MYA@K-u5|{LyHtS>(8gq$TBn
za`ydtZe_>|N5cH{sNck27hqGlrp{L<yML#6-Z!Xu9^0se=^}Q5U0%ejX}8Qv9&Nh+
zF|{=QsW7*&>-L)YhQ6iM8+6PL7U3YsJh=l6&eEkJde^E_7{zio$&qUf(inOuVRQ&S
zC9yg0iN*9%SAb_q>I%nYdTlPN3Bl}?_eKPTN^H32I&7`UjrK-k4nFX(C4bqPIu&N(
z?LDf9jaGMJbgu46#hrijEGA5Mi>P%&w2oNcT%G61>?;{69qfF5u^n-CN_{KUObq0J
zTU1Ia(ss~$A3T%Kw}z<uqs#rfH;k#UR`YD^;H4EsaWlJGP`(miG@4d8my~LrY>x{I
z1NfBsKj7;NB?A+}2E;XjoOz38KY3UnLhwE1;u5I#gFntbLIbk2RIw+)7X#iMu1c4V
zd~{9wof?ugqOAMYq1_^z1HK`WGn_fu07{3EB|{7#1$jmBpt@8qL2om;iGEhO2+*jl
z|7y#O1Zpfk^N_wv!40^R0O!x}%>hwRZrO}RnvSO{53SNnerAW`DIQ#HVDa=9JP%|+
zkqV4}716?9b$Qn^7H2tA6@M|ihkIp1KqZ(k(l;5(x!)xu9t+eSrT0<FE@{!w7}&>s
zBmWT!n+MrBK0DVX*|vDLWutv|G7Ky9^Eixp)JwrQ0NXr7c&uZeBgG=4pOg{<>N)zZ
zU#Dpu$jTrrFL|+DZzR7O8}td_(W9p)S3#b8C`VA_l#|(UY~qOqCr^SnzZ8#~b<#}R
z@f#IayuwnnkrkDAy-x0+Zx61h{_FBfuOSs%E@R!vAttUej4#JA**iqdQj@16cI3Ap
z94YW!aj;+z=B+nbec?ioO|Z~;`(h(FRcD5Ni_?*AeV{>rHQRyz&Vg*=^Jc_@Q^6UE
z(#&H0EgY8h1BDlo^#@GJh~rVN3TF>B@QVS?C?G5@;c%={MA{C{rF|rnWUuuo-+n)#
zk4?f=xSQ`a&C9#$l^8PdfyZ|y7X2+W2FvLhW*#}7t#+nyHYgh`i{Q=H@%2TkB~O)!
zitHgBp(CmV>rqx-f6H<VmHB-({y>x0(xANlxnpEEA^hH_<3Q<2ghKcjV5bGKttx#p
zGHfLJ#l!fQ^;r7Pf<*26UuA|juJE<@XZxk1?}YCv68FLVXpcCR7lMunh9u0T*rL1n
zVOw5w32;{gdyDE)I+%-_a78gv&e!NPDhQ;sA*0h83EZA)ru+dq1iC9qkW0oiWtCGd
zYD9-olzfmWMuyMt!cR5^xAd%D<)4UE9KYc;(XN?B2Gvn}hfR~Opo@(Dku2X^+P2%=
z<xf0;8<6%3yYF{qegL!9I}vSQDR)o*=`azSj<^{m`7fr1V<odKc?Pas7x@lJGX`3I
z>)NxH4tMl@(h*2(w)7wHVw0$|=Ly1Y+TE4_B@p{Ge5Ws^MFhI8ZTpM6yxh|vP~)82
z2E^y}SIR)$^5y1|xUKEgd$H8dW0Wi9%Cg7AbI$e1XSt%4Den3W%gV`uIjLnjQ<JHs
zrK7Y2t#^A-V)o|`1Z_T20ka`IH&<llq>3cYd2;HLJP5H_#{@y4*n6O7B$dVa9nXc7
z8lR(WJ{&^*bWZ%)22Bb1MM-I?K#8w`6m4PFTOnrm?i5^E9$7X_G!<7Z4<E5<q@WTc
z&3d1OPeMT`Y?FHamIzuwHcN}-1&V{<z#$}9pCRe~3)Gx#H4W<`Kd)1fPQt~sv5Ox8
zhw~^QDXz8dHL1Cuxv7br&`gdnxy$;gtF(V%MyXUnk^uX+h@($M*4`0e$7{Tep-M>9
zgt90evn=-QUe2kp6p%hHktaEHR}!vH^#IQeI)D|j#CxwYR0%!<U4}+%k^!dp(7KNa
z>b*<15)W}5MXmLSszPJ2`wTs?H;WzVnLEf6x;=I&Ua2@gSwo(-yI%d-8rD_>3S=o0
zSEN`7Q1>-!TeQ`Ob>Iv>E!A68Kw>c%aM^<rHU@@sJ|`F&sd)%s{jo#tipJ?xJ=|n2
zAC|4~G_IEz`j^V)%3$PSNwaT$m~dp9bvVv;zxoL}1$Kkq70I0u_LpQiQnj~w27j;#
z{^2*Oz{vk~Yah}+v`Tzj_UY3XM{d@N(TkxFr0t}2ttI7^zNewc7nkb>nBt!^qfjfX
zIYk%q%d`wCdFFe%)y}4uadSBVk#Y3Ijz)XPS*f_IQbjV90xwA<dTM;fO{=J-#MgXG
zagc8iR<7Qs&^^9|_23VEz2j~7PTO}PN2szV?uN<32O_!U$jRglrE7U2f33=R%aui*
zUGC><M7qAy%Fp=C?N(5wpRlkDV_~nt<&(Yl*p-dJZsgDte}7w!%ixi-kbY_Jgf<b@
z^&>M+j0aRT@3Gy8i9Yj2-}yZnIky)DNgl+Uwsk90dN<{F&YhleGK1CH0s?2mor)G(
zHwQ$tJwmn>7PCB`Flkx%tR7J13s<r`dVqGPN=29?2qOXW@lHaTJO_5%i>_rf)+$RD
zc!&!Vso%^jP}YOHQBj_03i7STZeS*+vioiVT?DTkZK@9UcMjS!ZKV(_M%SN5oH=fX
zdE7!tu&4aXxUe9Vkz{pfGTUVzFC*%x_Q8^a)R_eM(`sNV?P$h_`|5!+1?)u&3ys##
zzRepIN1%PEP^CE2fs#9wDN;p|*wU%ghz0cO?#^<%c;Jd8HTO3g!Q~djV*6elFA~r<
zNyVr5)12op3_BJQzmHjKbJnGmptLj4x^yY&kGXh(XY(Z{02ZKcE&u&X)rA7%WOBr^
zb_4t$Qzzy>w(B*~XLrJN{os9nBd{2zJw{kL@8n?o%8sp(fk59v#;m2q-GIu-D`3Hr
zvT}X{dTNC_t|eya#&4%RM*nU-bkv|0xX~*0xU|eUk%8;x=*m%VzuRatHpB?f0f+wy
zsrf<f@ntv+u^Dhbm`L5w%#x1HAhao>&-yJj$9??J>m}~|O%Lt*CC_+t%V!lSAn@VU
zXv`|_a*dv)OqzMd*-)S~l<+Q-nSyD?t1)n=<U{P7Z~f$DI2affeCazS`rodL3(Gvh
zPZd^#Cs^MM#n`ibXOkkM{EbT<nVWs}1*=iE;qo==$6YS5kr!ve0W!^UA5hgV(1TV$
z(fZq@DQGj*+3On*Z62Mx#$o0cwf1(|1HgRRy+SkDJ2@f;G*&bksW7^P;F-q2!#d(x
zeFHPM5{L$MGKx5gAvIz7fb2`1N|SuuM?-vaqHfhsX;%6pKNE~-za7=vApXihVZqVT
zf^rT5Uq^dFYLyOBdO{KT=2$oAr+4XaU;iEqc?suM+A2)Z_VM^!=TO(T9R<^;ofN0v
z3MYI+`owO<EI{-zqS1Z3V*R{QO}CUYv<qvlp+p0-F+}@A&e=6JxrP(}M@{}8ma@ax
z5Ukc^c|~z2TD9p5>4!KKS<{7iofstp8kenWD8lOkPEf6vP|qtqsCVz2G^UFWsvuQJ
zv?6!Rlh{i3)DcS05SHD(4Ye)QZztURFRJ+$l8g)G{0nT@Mz08=aRq%tWrp9c;S-?s
LNLLN1Y8Uk%u@g}u

literal 0
HcmV?d00001

diff --git a/doc/assistant/xmpp.png b/doc/assistant/xmpp.png
new file mode 100644
index 0000000000000000000000000000000000000000..c3cc53ebf5d98b5a7e29152b43ceed6a02e1b8f1
GIT binary patch
literal 27753
zcmb5V1yEegy0$&IOK^wa?(QC(;O+!>2`+))8e9f<cXxMp5AN;|$Uk}ayU*GCoPGYP
zuZj_#wR+X`)4jUa)%V?DpA|kK!Q;UL001OuDRE^00Nft{08@np2Sxaf@TNf@a1K&h
z&Hw=N>7N&v<HWZ_P!PsNT3!NX9Uc!26C96%CKMFHb&=3?5wo|o{bJ_=5Oexs<nqOo
z#Ld#hg5;C5{AZ1C$k+e?2|!w0MAd!uti#sAM9cH?wW{)=b7Cfwd^T2dT{4%)Nuk`i
zWpR5DzK0Y$EN5>!0XY(?h(T(Fcoca#xDnq5#>Ouek?b|l#zKRo5iUt+`JH46N-d~3
zEg_<3hZ1dj)EUPEmNm@vh>nHI3Histqzy&i&E5Q4HukA4lWoVc9@A7zZuNsc)6}hB
zX2as9tj=tQ4JSeX32Xq#MG}e>_@8gtP$_@@w*aFAy~74z8U9NUR@)!$zk~lg=kMUZ
z7yOUG|KF<t0K}a^oaQ~VhKK>MJ+L&&{Pfxvli%Ae>!XM;)t@CH$zcQBFI$o)%+@N#
zx|M~I5m6ywJNzFO&nJMLcNG%ov6VS$M%T|}&oC(P=9~r{t!xVyopYR?^cq@z*P^K3
zkt06X>TwPLBsDl8MO?0tHI2hM#F+`C_vW;!twRNvEm^qd%iI)%P1*#UyRI(Uo2h@5
z2u?jRf*)>uw>q>Ji#fC}WxAX=Nlzoz>fDtT3n1A%hvG)Rop@1j;sG3i-3g;qR^=WO
zL{~uvTGN#|&is02NPXQQ)p*+79_$<;0S7>L!filr1`>ruhe{|M?F5sA+A($)b?!IB
z699_K1D&1K<Eddoi&i4e(RFPy^h~Ut2RgUNkE|~O$L!bPQC<8CU-UnM13>A41W0|;
z1M|;rTUli6QiB6Lt)s#KH2Fg&CCyl?$x|Rjz8eA{tGQDk6E=?%ymspj+!Kw^G{FIo
z&bCD|XBu`oWTqS9h0ECDu)M+vQ3P#}V<M;|IJ|V~M?XZ4pzdyX*M}*x<l)b!{0k7)
zh*0nRr|oc|q?fg2hKIDnzbp2tF-%Lci=ZylKM+;Bc<{1zKm(>3h%eXJ6K{zN1=l7G
z_#v(wgdd*|d_Ce4cXVnx;w{itKuN}#?PKL6*TzDqV=%Ef-WCIB2YNa_QhS{U@I(&I
z0SsBXc^^Ns`$o^|Bpxn22Bufxb->V5pz&RNCQlv_D+=ygUE^vw@L^A!(1XzQyOu#U
z-BPaL*Z;B{PsMVnN}U8#{jyKDVtn&J*HrN_YCX~b+I#y-jTPZ5QU)GY{3t&QTt%M4
zyGY4sgn39Rx*~OooW97}x4v>#rb=P<Ce`w4|1SofeM5)Wh|3&^9S+Se4bcm|GJ`*4
zDO1yy4X6_Y?j>WUj7yAh+tfC=I>Be=jZ-P5Ve2!|)-|Vu+&^cPv2UP4&b$*k9IZ%i
z$K=c?>D<2sVx?p{+BR#&%*55<jSewE$RfPo@&k$igrM#+vYtfMDp+fnwgN>0D{53K
zW1g=%%-4X~CMgsPQ8^h0JKnkMGfRa>csSru&RvnHzt|N-bIveMM1|m2HtF1oJvEEa
zvhQ%w>QG$WJ93VsPE^GlDe=(AuLOAOZt!Nwd>gg3w$e2E_$bc+#IPeY0yt#KcETRQ
zkm{Vam8PACEPq?NrH8nK&}g2N$a@Z{8_T*RURnp|q#Gpd)KaXGCG@W=ySrW-(6(C9
z#UIjc!K>&DKa25UIraU~3GJ^h%s)nvB`_us$>`nL22rEvky<Fd>?y+@cFzNS;+#kV
zn;W+%2tyD}1@FgQUiebiCpi(HH|5uCrO&`HIlF&sW3+S1qPY~ElqJw$Pmoje8&A_c
zX?##j&DrVQ(}T}aTTt8g!DZg>yFQ&io#7=3Z1=6r+^x;6nQY_Bm(>0-VaK3TmSwKL
z%2yKFe&_RS))+l>Q>YB)|1>t0IZ1diioLtCrMD)^w-&S@YpbWpy{X5&siuPs02-Kh
zomLlCGbJ$L{Jt9bp!x>T&;Nh|rA?a@78G7q)g$QBEacOSl7Z>}s-@h@Z>z>g@nF82
zv)?<q%E!Jfqz$?Zk^+RgV^Fde-{@F<!uN2MT<P+}Jz5dedO(x#39Z3XU$OnKFtWVQ
z_muiSxiy<1YNzDNQzX(uCE~9f%-Y>KpK5C_I1F*J^qVYgNGb1AbO`7wUMvAvACkfg
zt@V@OGR2in9B0T^#miF$a>BwC*ju3^chSqRW+;1e_Az&tK@|g+CR0^6bg*6JEbpm?
zww@bk8@%#pEvzmv{dFk0z3rm(>*rWqQaB-WIKsmEU9k#65!T#X9#oZBjzgIfP0jD@
z1R`{F#$=*Cyz)sNe~~-Q7$(HOYBQ=5Kx|FXB7@rRrC_Zyz5gbzv|_8nt-fwgh|8XY
z!V4Y61OUuD4am7Zv%F43-N!0*K>>yhnhcHje^g%1eBqFIBOGDpHC0xQwD-fdz2#3G
zfr$L_`W=!SPMBD8TeY*Yy3Dw(*N8SeOR7+Z7K;v7C|_1o2BP{zbDN0GDbt~WIvMSC
zYG+^%m-RS28CKiqe4rIjtW7g#g+`lyt4jfzoqi@A(UkYfjl$;^S{|3pe$QXpTnA71
z-C3$b_rlIKz;0`cpS-D1aWa#Aeg`dHRSwnprdMB~XsA4n%>(NdKdhg;$cT#=)jy@z
zq+b3j#LK1Pr&i0H3-3~?uFM$|RZOF(THUlSZjf{_J0#)ZKN{9w+kCiy31B)4*HQCs
zf{94Ka3w|puKAojZQ5~!ym7AN-e)7*v7WX8o4kljm<<lu0uzSuwWxYoVuMWLd2!!r
z&6i?uOI`*QQe^!Y+=if9Vh$THsVH`j;K1pNc4fCxVb!t0cqb2jq;y<)YY9-Mq_B#J
z$(Ko0y|&Y?IPDY@u+lv|@st})V)7<x(mcEQI$*cJ>EZo8*LzZczu~|uXZ67_&fF#6
zXghdEY++5CB@yqL05ElJrB&0YWZG4V{Y(c?<|MO{A?8jpMuimiH&oRu+$V1zOCW*W
z5h!d3sU}c>nT8;_I*TkQ&C)kYe$O~J=aCZ{V|b2e!iK*6ydC3yr`2NkY@fHX>FVba
zyz}ZER+nC+W3nx**R!MZy+r(Ju=;Ad!m47q@jy4>>vyifC}akDQWxo!B9Gmf-J7kj
zy4)w|z>)%EXcLx%;4-Q064HoadeL!Ga(d$v&ND6?7z96ZlL3^j8aZ!Y)0MZ5Ag020
zh6JUw?@h^QE=}^N;zJ14T1<B_l@QI~>vi}ma~`G!qP$<=3=F@%kZYx=Ax$2Sh<Y3r
zmoZlnUSvo)66dSX9Nb@G9LOX(&(FB}L5D<a;p}hu_P`5BuKW6xe`O$`-s~iPZH!$F
zbV(D)*n-QqSF;Xkq-jfK+)R-vvXd%OUT@mHhZqQ?*SW7Sdhe*lxWx*8Zi+xiTu}0A
z8)q_e!y>MSf8vaV7v`0RI!q>Fd=<<<YDKZ{drv2N8<K*G^}$_r%7U1&CXcGrF54TU
zmg`-U4U_8+Ig?GZh7Bmr*{{mg&0?RZr8+j>toyZ)*WfHL>E-Y893{LkJ^Yd@Vc=af
zu}BqM$TjJf6u;E+34w|im>^RMbI3{ma^c6__k~LUK~Vff;s!4($#Z@=*|An#Yn+Ft
zg99I?QlSzxi(4H+x|kk8u~w&UY3W&KRy)U52FF1zOXwDmvdYb711tbr6k;(|{uILn
za3}Us&(iR|jI({7xk*Fbc1rPl`9#>*xhmN*KwxG&ebK^u-7dB3-CG47E)@RbGVANa
zM(|q!QHOcU=_hpG57c&xr;-PSgbV7|qo9gb7JXkeoT5+!jC=OteRnfJnsX6D75{`#
z4SP0;gF^5rXIEU1NZM?!Icb_q)OvOWrijqf`M$LE;%treEbDCGX5?z10WuLfI42}N
z3D;zwjLpdalYRQ+LzI65RhE}ek~e)qR}$kqbjC&vXC-l&{vLtkwUf!?z$9E;4c$)}
zbG)=_CT;d>6IsR#ux=c5NRb+&@Nk-XdAJC+B&ajp4F0xBb4FF|hJ_jy6G$<3<ou~T
zJP4EW<u(~zoqC2cS8S?}d$XS{7qEs->T6Ibf(8Jv-SH9;Za<%XaRVp&9VW78A5zNW
z=gf*4OOP4X3}$v`o*kcP(c4;~JzYE0UvtZ<6w7PEH6)GDzVcBp*YG!O&wL~tyAS25
z_;G+2Kw@R_`_Uga7OWBnCy+W@<L4Wm1C~_X&eG4*?`ifupTue3m2Q2Y?uQZyz(~NP
zp$D_Erm6g;Q$xrGs$|^Nt`pmFNhSco8mxkoBsJ-a7<h&2zWa>}pWg=$oN%GZamk^T
z{6(k*H`2kJ5Us#gl`jJTbpYsm9H)gKx+oj%a&>ml36(Ei8hb9WW5k_r_eRPPo}Fsz
ztiQ<5>|`*cz%<ZE*6Srf&o)6&Px2H9Nl-Vak^56Xa)n2;rD(8Xm%ypVr7h95d>9nT
zG{#v-5!8O2{*cQQA*ST@k-dS$?<_@?Q`_H*jgRX(DrU(fCa;^OIBDX-f@GQI6KX-H
zyTJUS-0?|;x2K2D03ZqvKo|>@<_zSir9U;UJgfx5>=)%CF1Bo7!hB&6L4{=KwkJSb
zmaYCw;+qjl;s(WB%s!2T+)5vT1!a)=e6aHHQ>YCgrln*&I!eNs*r!71A7$v#VvUA#
zp2|O0jiYnf2iexln%D)OP-Xrhoxg#_BI^HzgMN}K=jXA?ly>#CD_wLo)iiqzZLyTB
zeLakJbys9<cjg*nXg|EY<>~^|$-X~7f9ff;9glHe<-S+wL9;D$GiQ$uirl|M%aF`*
z4O^9a<>J7yjoE1%{tZ8~T5~Hu`CBJlZB*2iN7#+TEJTmGM8A_-X<efYfqBeEC=*)N
zF`PSwGo90UbFsuN?3}`2?PLS@utM{lamEN^HTLLNCGQI~+aYp-y;}XPo7AmNhT5b(
z)qh`$S7}ot9l?Qq&yNyGJRk(filus?WZJV6Yi#H!TuPT7fDzwf6)QBrhz~Tb*?|hh
zu%5?TLQDcgfZ+}dG4&WX@PTpgv2iVl*Wjlsm68tRj<DxTy%oqccmh}rYX;4(UiX)5
zi;W80Vp|5SEIh<S@bqPAm+F+8Zc5UUM<W_AGN6@W**cZ<N2JNqPtFT{)IOnUw%2rV
z@Jyj}oDG*I7B`HS*rswUk0g)+RLc2>K3v3Zix(~O4fNRZPO$?s(h4CBo?n#m9Mq5L
zv!l|K&otzz(?eH!B74#;b+i!Dv^70kbITpRJ@`g5p9+OWRuU1m5^Di*VYOSvzD;OU
z0jgE0Yh6+0t!v9ak?oximU}p2=9XC4dh=Cd%9}1|vk0B2o@SixZ;d7j4Y1}E7?NZp
zc)Io`TI&|MVkou{GcZ*~UOeUEN;f>O>r&86Atu4Kyut8<-D}oczTV_#yIsW;1>E)+
zGBT978rylx72)bL;Cy~)m4tjO8jGMKgW)qDDIX=F9MYha$a8*I`bit}{7EEz;~-^*
zOBDsshL~Y<Cc(-JFtc41JVc9P<Y}-TNUoqOGdfmfq$wFs1De<s&*-a1?bim(UjXZi
z%?s>!Kk^8ghxm6-dK5(dmEzW$sHo(zGS9F*s49ItZMoOcXlOn4-@8GHhfIKPUzn05
z1<FGBavM?nA7^^|FW4$1rH}BV=yAhNcIc9MkhCXduA<%5-|%xg+41vtF5sp{>ooMC
zMxD!Tc}-73GBLIUmw9E))FfGsX+4U#o5K%MTUVr&WQOUs+~=u*YP^URYAOs*3nU2y
zfqX!gJ+oEyCGg51`NKiGEwCXm7_AK3+58c_v+MZ2!gNf115%4M=JN~Qm`ps*2cKS-
zZZGGM&Y!Y}SdWCC6c?;t5kA_U++`n^$n6<g#q4AMiPm_sH-yOLKLv}k!x(&?tvKh4
z&RksXV<B^GZMv#mdNN(|y}O&g?mv~iiZRH%n1E)#I^&DUgwK2{5&MX~V%?mq=8HRF
za!kVH{s6ih`l4FaCBXmGqOLlXjrsWJ*@lO}T2VCB!&}kfTM_8XMTN^;N9V1XD-T{F
zDNLP6RCVJew`ZFEx`EZaUerE;NU7ba_7YoK2wyjRE5-Tg*e3P`ghe=OCAO)metE&s
zd_pptK4X;?`3|hUSed24$`5t2;F)xJ3PArZ_MtGTBeJjzMQ^!A*@x$(E6JotanRsC
z1q^1e7XN686Dgr+-?*4tbnIIushZC}v|1=u=zG-i82;?6zMawglNM-hWkwZ5^RcLX
zy;zC6%mrt<v=HNUff<zkwRD!W$@+>)C<27^$tb-ph@=N({m3c;a2#T{^Om7ZUdrw_
z3F5<pTqSC~r7#>|^?0;x0@EiLszItKa6mfj`Cai=SG868Ue+oPf6Y|IWQsU|Gmm6a
z{w1&zQ?_R0W0AAwRvIqf&~{Brlo10!li=mM&xiHhkRhX`^|UfYfZ;KEy|anV`@ZWK
zq5=2NxMmM?-WdN^AdDdvSoiGNr|4XbC8o1n5`ce2FCxY8!oI~3%6GjvYXt%LB5-tc
z?993}Gi!PcYAG+zRVqD-4LOq`&6E=FR3@&<>Xe%!YW9DmmCBZ)qR>bF(;KDAFM8v-
z^quPz87>^5h;-Y@Wsm$V_T_oB&L8p=JEqaPW9nrB1e-N2f=n0)pK`wrg^TX<EOHXE
z-iu8Mvgu#`NodvutvS^`&CF+ymcIrX=4=k?yD}qc9_S`66ZQ;C9X*5u*;T9Uq)UG$
z10wQ)k8RQj-FCB-4U7F_fUa<9f6y%3y<^DIfzwqf2VS>L87}EVpK9$%n>5Z7g)8-=
zS15!9U3OhJO)K(6eIk^~*-We^36S!ga>!%^xZpAuv9OF?#jNun?`Yy!rN6c_1z!q7
zY1~<IHb!F#4$exMg8=G?gG`m>gXv9}v;v7fl)|Yb=f_%k>GG12K?AGN(ZK6pca;gD
z@%5jXNiiA?Sy3d&%mHYJa1k4sQse-j#H5^=^W4|8sB$y35pz&Z`qX9FQv(xdY~BYL
z$=e3<`EB>gZB2%kBhx%DF`zY`T{L+3XcWVON1M118j^0qi@<|?M}m~UHZ|b0Nop(x
z=;SW&8IJfpjUT6>=1cW-UVrGz-0I@tN1lvXkO}M0WO9nGCud&lD^;`_z{lnwt;7Vj
zLbt2*++ZR?+$=%t$K_7f;x73YDltqtMz1*4zgc&dl`&rS{7n2Uo{Yc)WBkC=mQ8$7
z&G@O0KfB~gfsS)ZBq*T1$UMp}fYn2XkUJNg7$0v+(VkjX+XeW*RX62tX-S8a#G`mf
zdETf6T4133nxvb-$zfYGGHgZpfy#MLo6{<YXhWD3i(?fSCZ)<}u@u3O9|df%MZ^U=
zhtcpz9PP>Hrx16s#j>I~OjLw|e~Tj&XFzUEGK;J%hqCVn2l65T^-7%9YWnrBEt~ko
zZnS+o@Q&!t@t4pY+WH0)MPe+azLN<1y9ly6-BPwCd=R%izNA;}fLAEdeLY3h)|qKG
zyAvK2E#Hz#7SOlVf&R=9>8uf8icuppmz;LSH#RQyTt0Pc@g++rT?+ohiTw<0Omte+
zeF-Bdz@^yS&60yRD(bMv4N4}yv9F%%WWZa|o*v`qm;;9c^wzHk-jb=mJ25(FS(Ndk
zfZo|ur*Y++sc$Nh^U(6C-zdwP!q#-n#%H*m&COM}K&8RnZ@!)dlRaGrFQm3XWGUy;
zwgPJF7x?(Eke-|t`L+d34|akUetw`{L)4g__{)^@&}s0^7YSPBdpkc`q6@l?^B*$b
zkp_DTi#%T^TKB>>&)QR^wV;o7b*5OvY?+JDlsa0Tya_eI1Hzo!mkcXw8Hg@8RL|0-
zaYMBMsp83<^uZL6J=0XMKAz05D0546QP>HRZ=>`37R8IH%3;Nus@?%4xCk5^)nOzP
zF6x>cvSW7XGe6ievo^WVXcSf_=Qa&lp~Q^hXW+X{&rl%ypyMUND9)qG@x%7mLgs3H
zhHLk>aAKeoj91<;O%N>mYSg!5ErWZ1Hfj`zHC!70Rr^#OQ_+=^?9=H-&c%RMOLFj;
z*_K|0b{Jq7RGwBJu+QRy(zCr?GZQT?8_P43q!Nk@6$lcCgISq`*5H}%jx<Z3Ca-gZ
z#?cIfc_pka-Kh-SHu(cd+(uahw;!Rxi&%U5ALcV(HAOf_(u}fF1UKPGFohr3F|}_d
zv3-8<*%4-3*+VVwbLPXgtqZQhYkr~%U-E6uaqrftes*{j?-|Gyk+C838l|}zIMb))
zjyaQ+Dk{m=`BKekAz5h9(n^37B1sk9g#3p`zrbx}{w^;8%}%tIVpA8hPA(WYQ?i%v
zVF^^We3k|o5`hOjbuOExtYFNka^}asvY!uHljaoC$;u$9oVgj&??^pgo4)?yt!vo6
z$O7H~ITI0aDZ~_w91<1X5?zWp?dPc-E9(56em+s~g_<H>97HOuNSs=WL<Pxr^2*n|
zGpvKXLP)>v<rmK2!=VgOy?y%`-r_hAwvec0Ak~E3iq&7<!_j2*A@E1Z%JjQ4wkPz$
z99@jhN7n~(CX4w>q>z@o%&uQFMOvqsn?7d<rFA*hBI8Gth1j+Qo6vh_hbb&}i>+0h
zL`+X=^qGsRl*#8ow6#OFFVE{2CW^ugP|mrPZr*O|>h-qXj*cT<hOj|5czr+bXzc_Y
z)J!z5_xlnXw3-Zpj^>D0@vs0SlNFOMqN{-pC=La6@?K~6n<Mvh8p(Ovdk$InibP(b
zr8fLUEJ%~`S#2Hn0_xh6AM!_s7w;41DlQ6gjVmOJZkmDD!1mIF(DeF59qaRaA9<`)
z82KR_=7)3u&Z~U4zsJ=9ZRVT;9a&kA@UAKHmQTb2rXcd9JRe>oQxSiWJcU@HcKzTc
z4Pxc&ab+uZ0nNwc@tZu!k@8t1VIFzMUvUTpz#csy3vHW)2}5zsRr|H*oQrzZzCLHV
zS~Fk>CsK6xv5A7D$FQ=~)931EPuVP0gGzTIq=>(WKdk9D@<1(Nxd1J3_-12NFcS#`
zpbD2QE3Cgl^D~C3_>RDD26M@8+z=2h;8sb<ExXBxJi<tKaIQnR^WZO#{W9lEIO@-=
zJ>4fnO=UC&4p>p+KOe`c);{-*s&s(g6==?@n6v;%j)WDX?Gl+Vv8*|G?~muF-4*l~
zr20R!$JbXKhbFFmDE)0mbNB1V0Imga{KqLf1bJDMYVkj+PLDUlx8Gx%hJqwvordPU
zzYnc9r&ZAB@04bBqS5zxG;C!6H?KAVbX$&|AnDohmbrnJTOTUF&^|ekUY#tUfM8Dq
zRh+Qt-ub&qT}{t1$87Rn64xDaN}YlHpM(9j4Bem)ND+r8fAT-a{)vD8kh}gbW$S`c
zd2hn%5XtSf0_)Rc<VD&LV~?@h$6owQr>*h^j*Sthf(Xe@DmFL~1P5%(n>=*4&B=_`
z5j3~?*Sw$jA4LmrF+1H@zMipO4VX;L7QwiY^hT}N_a!h;y%V|&!O38Ma%|dp4W1$g
z0q(}$FC^<j#*KCTn+^HP$-D_Jk?%5Wv_6-{XJ$ojn(Gb30v!+^M$M-DUa;g=oOZTE
z+<@6Gju>uqorff$_Fuuw;Hq(AO9a!PBE-VK4S<#8I+QykBG5qVj&jkebc7>nmMbk4
zFwlQp8Nb8G*W5+;6%Yip{+;%kQktyW$1PBc6B~ETh$Ub6QKDO!p;>EvNcJ1YS$)kg
zmiWm|qCbX8sc^hPL_yC^R5~rLvq>=UlCU5ak|qvPkgMM|D7sXj0___*pRXWSxTWZ4
z8X3&!cLG`N+A%X(2>i4NgRS|fk{M{XXJtr3ryN>W4eW%Z;IOlwJG{$r!!p6NBK2b-
z3`ypxv1@*@@tQFb>5WW^@SZS$BzTEN<XlVnq<f3+?Hef^OqHVSU=Dt*?ai!C)y_%d
zrHIB(-d~j2d9CpitMpkQMXB(;encYsYo#|%wTS1HY4ULsBOc7gX;U2x4!NXlt7Z38
z2}@s}cdN7iP_rKRRjg9sR+$`LBWFQ_BSlr9pW(2Nw`56pdd~pDc23!@O3mjulN9f|
zAeEN<d{%3x=$0HwKC^FS{0GEPwqMgtB&((;3N9I{$^{Y6fE0CBQL)6X8_gphT4p&O
z^Y#Z4X9x}0$x1l0(i5q>kMGPR$9sRf8|^<M2pg`96(~)eY)2QLL;UoqXRdjbD{HZ=
zo^+GCJ`b#@GgbeB5ntJ;OdTKBUe|M@zIWg(8&$NhIWnjqnDxbk){0@m=_#1^?F+;9
zC}TQ<6X$RQ)0*na{2h~;z;Dl*69e@7gE;T7f}zbsV&9SvU$~sO3_40tWHxNbxa3T~
zSe_WllG5RpLOOmza5!<XfBsT+JJPBxP7Mryj@HQH1-Sc!om~xH#p*MVWCUGa70jJF
zR}h1R9@MzRa(O%u;z2^NWKFfT8t{2Jm2M?m+sIbx4aH`H<yg?xy0*6<0FsNm5Wu2b
zZRbibcW^oPuLVCm)+eQU?qYje_KkLmQIXeaUOjQn!+5Td`~SsuTI!F4&@7o|DzdU|
zC)tZTJN5z@Tx^kZHndLFsPoH9oP>D5f|a-_J^PANi(Bu#Z?_gIRP{d(RyeR4D-r2l
zA9B+-k?u1$Is33%W*aP!JF`u7*NEqZbHITLV-_67I305(-zDwChnOb6iSMkJpT{eQ
zF`w$qgeD>_J|TB^3`J)8gg_5{(`>E4K)csonkh8j6Y-#{9h{T7<gSSyGgpw)$fCbd
zfx3Bdrr#c(9KqtjpVU!omr;4MGa$z!Vr1y9sT)q5sr-;`v$qISVAc2|Ie|=81x5#r
zQ5wDKpI!j1k<S#NeA@nQ(S0V)_<h=dYVJEYFGn*+J4U>qS%#R<9=NfyWl0Yx=kZ9S
zQ?TwM))>M={C0u93Vi~$|DvVb)4ttmYrBaBDnRue+-ge=!|xl<JScYuWA9mNKy}!(
zLd?q>LRq6UfG>pVp=AL#9=6*IqrXMkZ@Njj2{8829H&UjkK`;(-}yv|8#5)P`3kte
zuJg2TdNak>bb7EnIoaE4E15G46%3pdZBHOuvZVOG=xX?p(BH?by$=IT7D=6x?vO@^
z0`Gv0s!%dVy42zBP=}O?k4h(Pby|5RQNF_|@;eH4u-?F8Z;`peq3B$_B~Ah>fizF8
zi-swMSR%=4VZ)>U?g((@vz!hXbD|kmJOB()>f1n%u_ueK-m`Cvl1@8PTnp)e22(as
zO6YT8EmKh}9PDsHTQr5U`rHJ$701Isd`oZ#_jqvnw)y;!%z*I-a4zK=2F)*L9JU&9
z?G{RczP+?416?iIG(d5^LG;&+`N27!ebVHe0(*|AJ>H7&S`TVG9*9_OMa{DZaZ<3K
z^iF21>FJI3Y*xIAANMnFRC0|3>B35MOC8F0{!u-Q)okYL(ZW?*A9LIvUzj2;AM#T-
zW|y|t`+tD?fSZJ!NikZ#?FN_uL|QN$0|lB_=P=J~T(>4lS=*#7c$23ivHiln08aZ&
z){)c4L*a2jbL_i5sQCJwD0#dOPHa`WHP+pHnDkqMEF^vc*}CY_Motq4VDdpMiNTHu
z_G9wft(ZR|uF<p=$W|2SirT^EX4UcNoiiupS8eOwIjZH(=v#PgtyVjyqcD^&{%WAQ
zxRlWX_#xU(3a47<T8SJac=Rf7NeIMcf*Ob6onQR%p}4^W8Nac(KPgAkZ(z1W<;b8m
zH2@$4Vrx;Yw}=p%H;i^ivxnHpMNvtFd5LkAHjCp<BtN{e`IL-w){RFdOug{Os6Qa=
zmWD{<iqPv9u+l&j<2@+r(IcqYA4iThbRp*y;EE|5;uNhARntSt2Te>Q+Rw?~xll+F
zKyhcNOMGTJ@bWat5mv0~DHc(z`sj-`e1C^`pE0$d_gEQ~U_qqvtZF%j=CSgnuD}&P
zfiknt2!%dM8@StZ&M>s2#AQYmonKq)qO->dnq8<18W=1ZdVn(GV|`t}deDA**x9Z#
zmkd=ybAD)j5|N#tEuBOI*USPW6Dj1ODqu79dm$aD^6N4thKG0|MO_w`hEw!Hn_O26
zZTi+RdKiCDdZE&SOr2^?2sWVnU}*=MA*?b=L?y{hathHJ&I?x!FJvO!;fLL{1A9#2
zgL^4WgaGk1La2!Na)p(9j&ALAWflAsqheyxa$l4SY-RUM55LGpa8fJsM<_Xeyc+`7
zq4LNpxXCTuxcs;+H5y+~M#=?8=R=3(n2b>EWBlSy<*y1@nNzhG;WKz~!oAOS*$H+D
zx1qkhsjC2p#Y7i?hlgn2o*0Z@6a?H3cYb$CgKt%Xw%%@bb?NQGG)!KLB|UR`b)YjO
z%&=G<`FCbX$}GXnx_Sj4P)Rj3_OhDtS^r6@#f5?5j<A5zq?m>`X!+H`Wyk##Py)zT
zNxC|J{z7#688^S5v$p8GWdz<XTHcLH@&^8jx58|i-#uwEU5*k!8GlTlLClWAdEcQ!
zlTQ#tqZIb11Inx=4Ud3^QVGubM0apQSKh{7N@aB?xc7}+yy0XtpOP-Z$5H;Oc9G8X
zu35#a)$VnG!N87Xg{{+yKDS^^E9)u3@q_46Knh3mfjWaRGb;!Fs^0~;)uy8D)kA6A
z$<F#oIa9s>>?1&fcdfo?`Mz0RC~M8<46eAqP+|T)`Z9X0KI&`S|Dq4gam&TlA~)jK
zfD@Y|ZB(|_uww}wh%IdF<aU_g&(u{chzeD`r@Q!|WH>cXMN!2Fd{pDioJ)Z|ES%cd
zd?6yPET3q7qZQA3pDvu27Z&JHa$uthZM~+7z_N{CiSzlbqX4E*#F6svkT5-8eJZoX
zr|_|*wRXZuCD)OGf+bNFGurLfUP63EJi`qqVtuB2!?$Yu0p_3e>gRsL-ma>*3A<9G
zKP18eM<otI?g=33zoTY2Fr`m4YEw;i12X(awK$=4rBNYqAVY<*q*zm+#Pdt1aOT@>
zN<2Y0Ags3pV8nIu$2*GmkRqk*p~uoer4z(e{sIUD96?%`5_FjkvlK(!!G*G<1RVrB
zrZE6dFteFbH53EBsqx!x&QHLg5Vd>W%S_5skd8rx<^j6qN*R{pibU_XklGkuH;v%c
zdavs{SAuJHm#pwq6iOZ1tu3TgR`zQPa*&*MoYP9V?)Njj=;(d4u5<L0qWtVX-tE7`
z56SzEI+7>i>&g?VGO}(#ckV+v(jhQk4=Sf5Y=tO<amjwAA*JY58QboG`hAF*Re|j3
zQ_Ty+A{&SxIeCsHcW=URx96qUBv}#i!jKW0S2!D2^{Wdra-0#)TK@>!3gJuqB>B*9
zL3Z&L)<D1l4c7e3%KA?iTqsxk|BEQ}mt*e#LWsXyb^p;Ew^O0xze1sj2*`(p`gviY
zcFrjINm>QSnn2}7z!Z>O?}v{4v$lzTCKK|%_yGWV>}+c)rlQ7trdDnf9sH}rEm<a~
zLWhb=QlA=WS5{xn_Ss$GV8l^)zP;CKQzPh6toNK^YobR{CxzJjZ;*ic$-jD*grE3;
zilmhLwIEV2GCHnsa*g*Mq$DA0g#YqI4!IF`;kuXu-cm}vG#2?-BRDwHCK%6{;weMY
zLy>$erVTgkHa27-QSti*|2G4K0;;oj7F()mCKx{s_>aBdn@h2*AONkr>`JR~mJ5C@
zsF%CXkPoD}s5(a&+$(PybWTXr8ahg`RCANis0A(|SWlD50?K91gOfDImStSv@e1Li
z=GQbg8Y0Iely7oJvaG0G`<`go11U_6(_*7seQHMv<i%J{om1*+=B2Lif8ZmBDAZOq
z)X=1VQ&Rzp;KC|h%$MvPT~+~xa$jK6l0s2tNkvgbQ3e)31Zf2d%l@!xDWyxADDznH
zKKPMdz8B4fPv(@@`2}J%Yfwk}mFow}+Ugm+?mo+JYKyux0ya-2YZ^;T-j(GDQy0Ma
zYQ4`S1)d()Y7zORO?A6v_47Kb(9VkYeW}CZ+wslL=y1=Z7Hb)6=*V@V^vn@`eHt7C
z6vT1<d>MMB?k;bI2_Y)?1ArbAhyv|wDP4i?ylcWcab+cs3Ap$KQj7BVIxQrXZ3VfU
zc}wf-ZVKAFCTyX*m2-v{Mc6AwYKfv^oAB!n2Gl|+EAiBj<{wE}whd{R>v*ASsuGgJ
znAX3I+^e|-VIwhA{ZKM;sV&-s@MC2tnMk8M%$*asH28g^_BJT3#Nv?*211U1<)O_`
zN<SI(lh!9%Wg^4>No2p9b^p$~Q*)!|%2%GAvHjEZ6XsKGymTNUhAbILe9-Uf-qBlZ
z|L)pk*}Tk!K0>86nC@2#Bjd+Z^*(g<$;@8yen-D!uQ9qZ6o@~Hm^RtoCq1<=@}-Qp
zp4rA;xx>3Z3Y2y3rY_#Xe<2JVWm$Omf2mz9H!I3^wQ&NIgk(2=8jKe>h*|i?*8pgX
z=A8OO1d>Tz!2#uhTJ!{uo{bbsl_pYC{-4<~S9mwqJ4z@{8Y=VTr-lP>3Ptu8joD)g
z0^3LGE~iOwLZ7`i7ksGx4<uQ3_GoQFoz`69%+UUrX{17QiSDRqomz5Dnij}Jjl1*!
z!|~J2g|Uu|_OJ>q9qd0cl;eDHYf8eg#BLhGOHxJ|zCWy#NR}dB=SO%oefIixNlA(s
z>5g@M!S4&89|XVc{&lm%!Es_u?4TLZuqT<b{EW{<lr;h>#$L=PyGi~=(J{X=tV(oW
zrO0cH$ty!~ae-8HTXo#6{bjy~XHuH8rQVX-Eb0j`$uez-F06m$oVq>jvDm=NxzAc1
z`A3K1%aF0SD|G+0Lm)*yIk758lL%Y4i5WGF{dYV4KEp%M(FjiT@nZSWj(;N1VH>>l
zr<uZfH6R|O*!gv}{Y}h&(B*YF-7~1Vz@*e@vUHy59kKA&yFWyMFwrq<YQv>5A-&u*
z#(6N*8?DhuIApH5x8AP^%did>kfa=rBa8g0s?uOtLIeOv7t5+<QeQ-qRiiiFH6vs*
z>GK3Iw~m_(J@@ux^r645pF~PS8nVIftmg|I>6GY?Tb+S)hPH!6T_13OY*uy#{@M*w
z)sh5qckCRGZmX*DtkO9e<8D=NAuv5cGRH-N%GjZom9KGor&K9Smx;0Npzdl|czEeh
zvjg!(VZlUE9*-g^T_<L8(Q%%q>EH|<uuPA4xzIll9r75Aw6xz7b}gL;=%y6q6F7Nf
zDo?^PY*Fzpq1!E+j?CD-T3#Ql#sbhMvLy0U@~=D@FGgH?EdGpgrU<y*UDjW0VCPIU
zHS8L}5Q<m^rJTQT7HM#5$1I)gE736*677e^9D$&)&`V!e(x~$@`tmiir;P?)O>MR1
zZ5%jaM#Q#oTuea$XI|`+^ajON8BF<qs9`JKf3mw5?cDy8+z21qMKFp^`qgbuz)<ky
zTUd%c?W+@fs=t3^$pGDl2oOC9SE91~n-Z1(eBK|&Q+8~&*?{-DGXj*0c~RhvyVWpK
zp#%fRi3N`c9Jn+7)tZXOVK;hT%gxn}Ww<g|&_JRCtZ}7KMmm?ycV2`?`cy&bOXi(S
zXx2B;@I#5XEHrJMrgJ{=TFpX|Ka~wXya6)1JaXM}e<WBvfQ~D%p4R;uX`r_Yxwdkl
zW`!L>{vgL<4^eoB->7B{Jq*&nZa8(sMxC@A4GiDlMU^6sGjo#TymFyuwzT)F&X$&>
z>B`tnI)kNI(;deIu1>^<AGe|x+(QTof4bM<+>_2kh@OqL>;Gn|(K0RqnI(TWTFp)j
z6XADH|E)=m?26^9+0f>sQ>CL~G9JG~PKtj4G?naN(Jy!4(81q7SxXOviZHoQDLc)~
zsD>6VvDc-YvQk+&6+J0Oh>n@*Lg0xEs^sLETGKQGvzsX02M*aevvgJ`d27~iEpV9`
zYzul=50BULH#koXAjbM9<I3hJDS8_j3|-TE8v?i+`8BmwHU9^J<p!X_GDwO~B4}Mc
znTS)utubfcS^}|t&g$2PzNL1~n{H{DNsgNPWPYN1?IUa|bvmySv#{*HXQm+w9iS7Z
z`~pyW<c-64Dl0DWUnAtKMD&ysBZUM5&%gcg<AORqDk}u-A?l6o5?t5OLaqsiCMoFi
zs^Pf)*BvL<`P$F-wA>4lo>vn`-x7j~OB88ac1PpnPga?&B^>5`pv!m5PnDtnqw<ue
ze`bThg<eJZV|uQ>O&vxSAD)lkp?kJ?fQM*((}|vFW6*}?FlhanQh%7zXbjrL3(qg6
zDZA%i5X@~muAphFTsBivJmFm$D`zBs&YHPsXZvPMm4Dru*>&}Ys<)kBd?@?9M$W|h
z?fPo7k#dX?k`1ZLbs!^6AGl!ED$iq!G(pM(q_<83vE`9|zG}x?iFo}lRwBWJ<ij>y
z%m(pgLjoJm(x|(i={cM!bo|Eqietls_Hi~ybCMsU1cT>Ge+E^Y^>$U7>MgONGN;J(
zd|oy^gE3@%fC(@P9GTyywv&-3EkQas*l6I^T>ZRkJg*D;R@1#Gy=gHM(Zs4V>haMT
zxC=!Ex5koPHs?O~;jWUtn>H|ES@NO&W*NKAtK=ttEz`%0!T`I(p4Aqg=xewxrtZJ=
zBg&NJ%vERN+w+=eg{LO)GbeoI?|OE`c2MPc=ov2gvq%FF`cg$w=Y)1ypcIr$oQNFv
zBOPO`d_LGW*8vMAB9w*VRi#8<;gdSS8e#yL*{oI{jf+26os3GBDrxehWUvkK!AL=o
zWSEiJ`Gs<nbh|!J6En8PukvleEoX4WRE%UO(>55houSVS@qy)o4`&vN%5FaIyjQF{
zDuA8<qIy{tu3ozm;3vaO%(a#(5Fwc@i1=j><tfnt@gputlPGESj4iA91M(Y8RA_YM
zv&$}X7urPh6?F6f^&*oo;s)M~CiXuWI?ZUu29n$K`P(V%!b?uCbwcT_Py033a-Kev
zq58b^rBl)Ow=95UBQMkouu7Lk%b1Kg@W;#aWQDp#fsWT@Y*lkH5CG1|%Q11f7v{}o
zI;Q&yHoY#Rf0pe57M~Js5jI(-YxSO5{JRp=F4)-xZ=0#9mwF%M;`K*f!qasw!(zcn
zO+z{tavLd`SvREgaGQ;8;i>pcu#Dgw&G7ips#R(uK6!Ie%^5QZoI4sE+zk@Lj4(K+
z-z9oo>=#pbxYE7ARaLCwe+ZgiiEqzVYU3n0P@dmYbSxmU=!<l$Tl8tTcJHY&zOG;7
zY|&Mfd}#LmlT2U=he_%7qn{%bu?06l>krq8NO=Wl^-H<5e+R^?1FR6f@bpOJ=+~3u
zC{faVNF}a!)0te`)r{Jn+2iKMzrZl<8Qp%Zt^kPbG{mFt5Lb-^(aIgQ6qWsr%MYv*
zw4Ej~Ia-R#OA8KK{hHgtF%Qse49G^$wp|QZ-@0c)n1J_J@RuBH#Pj+G7ow-V&erG2
z1``Bo3upP`1Zr7afSzvtU0kxrg)YK|?k7(fC^ctCLxcvak&Ii^(N9v6b^!^RFN5)N
z34ja$3p#%4O_yh<j>%pi42phYr;6z0e!vP;S%3IcBUrl%K?zT;<2dz2DND5^OCld*
zGU!GOMqjUeqR0Qe**lW_+CaSU6IOrDrf+-Yuj!NrSJOoH%Sdp;-gh-tUc6R=VKD{L
zk%5|H!((sVu61YopaP~Zo%M;AwY@9KlL(vFlKSj~_Z4{41D5TzynfK`bl8Rg#d~#A
zohfzXuV=`xq^w~b6-SA-jsuqEY33?DA?V*Us(huKXsC|v;nYL=jBUgmM59L$dbnW!
zg+BXU+)U=t>jCIZ3gi(C2IBGjN?;xtYKN>-sRL;dlS5lNCxls=ZVx|nN5krNY(L=#
zpx+=|{VLN)w@*{c^0B8uQaZ)+**QVqOjJ^w2A5kO+2@O;x25A)w~S%Iftr45XX}Am
zN!*QEkB?-5^;hy2mX<<b{!8?7>xLl*`|}M{?2pa``VoK0T>m)ycMv2l{Y&tl=lmV~
z_kw>1*YSuO^=`M`&$oQvP7Su&+!XV(a!En5S!kP<ze>scW7qGus?L`aH{V0I_g_=L
zy&W84^FiCSNMQHt+o9glw|+r)V;gv1FK8HmJv~qPUEDt7n1s{T$yP7xHB(4zZpEs<
zybGQRx9jDVtRqmIXUw>W`l1KiC@5MmFm*p(Y(QKw{k~xe64LMT&6qIjdVe`Byr~)M
z#*Pt?%_3U=rU7DJE}aKNO#)>^dSsX9$CN{2s4XHw+QR_Ii4c1!cvtqc{LnL@FCF!%
z^`o9Gd5GTlaatqa%ekr9a~h=6b*71ZpSDkzsxCL$9$)THUmq`T#hRZ_F#T67{eBO!
zwQVzQG7I`SLrs|}`poQ_(y!66SbSfPRj8HIhT26WaVdZ}oH<y_7GqeG?M$8U(bm}d
zj&WkjuBMPYoF&Hb*%xFG%*{`Jh-+N7e{W}A^RB~vQYWvAgVPfEY$4jV2Gv}B@&2;Z
z#rW&(<=%Sp++K+lPMII>3~vYEf5UAWYmCa!pi!IKg2Vq6ZV$lmz4HVdYbCh>pPnbw
zD!Yo+r2EgFIY18}G<@8U2bL6)%v`(Nx^YIW)$J?YIkS8f@-d`{Flk?aw59pilM&YX
z#wjrW0g@D1fh2+|kCF440I8r}TdgrPe@GD+i$p?u3b{n&Br!6Oqw_8j<6CxMwmr_6
zjzVH^<w)`TbkGYv>q;e?p(P+H(I(CkUO5y!;h+f35UpQd7=;FUhMuq7G_oAXC_sk7
zkIAHiOT)3K?;Nrz-<A0T#x^+H5}NZ)+k^GC6q}uEOQw|TBG*n-T~K**8t%M9%U|f}
zXW&wmfxV5*uj8!u;|{M!!CzN>_xJZPf-gs0UC$FR#O#~XllgxT+dEOa6LnH1z^%XT
zkH9rBZkXCXYjQb?(lsCYzcBja@6o1t4!7lok`MoFS=3I&h*AI{ceo9q_*@$O=?tt#
z8;iBR?nLhq;dS{7mv~2sCKslgqPu!#$80D)x;8xYtaOP6m2S(RtM-uRTcTc{*~c`i
zaJ@`uZ|U8^%Cf3?{|ZInEHgo#Lxehcd_c31p1v+F&oU3lBKcpi>haeifMX?D5D{p=
zHe(q3zWyEv?DwPxtsr<PPxCzu=^&{T1b&GDt?pFbr1)Xfuh>SXLeFj47Rs0`ano|R
zh}i8G9Z>vFe`sYK?gX2>G`wR#uTY}EJ<(IVrL^s$E)RCbg~#ug<f@Z;E93kEPk{=L
z5{G<M$afbnqffiK&OB-3vREH7zWb+ttJSBIHG4jZNy65Ubn~8x%wP4k>x@#hUzT|L
zUhbgm!$wvAXaUB!{=V7fR@J_k6ob*2hhUGmMDjO5Lzv(1S4;LU_zR#Rp(HCae8p;E
zUF9HURD8q&$2(muRH5r<vl-p>A-%9<V7qTabxKFO5HPzt<74MW?w=LBJn2ODUrHWE
zwns!cUI3rfdO|kf?GRjgQJQ7OiO5`)0hyIO(=M8<#7#+IRJ_J(TQ8YIui4YJwO7?(
z8n86v4V)$xG58RJ_0Z{jT=CgJ*8ZCs3!)3*nHxir|B0a!ZsH@1NJV!4LGI)pT7y;j
zYZ;*A$Z-7dw(^2c?^F6A84B=II&Z38*_tdS&tL8Et;<%&_xS#Q%ALZNg*4J1qe*}&
zCCO`JA=RD_gxVhorY76487ogK^AmAb^e;GCo&1jVxRVAm<&drUws;Oh{Nuk7R3(zL
zReAnXtz1_x<vPpt6;<ah=}bjm^{NM8FD`Yxt#!Tip!i;a#;IQL_S)JTbH4}kt+xv|
zp_ik);D-L$d&@Vq(mob6L0z1$3|RWXic`QzD8OGfOzrK_(OD{s!@<U1W2Z^D`-Q9K
zgCX|-LzmQ{=-UCG(g}&Y&#lJTEZjz^gli69f7>I&`P{dq<}WnCs-4}9vve|8!T>gs
zBEa-J7#})UwrJftj((=fLiu1%6>Br>*ZeZm7Rxgn1hzz`TZa2(_d12ni%Ca!8@oK_
z4K0u-v;zmbW%oR2goRBV9j{K#b6uo#xMfhIc@ru~{GZ^jQ_wrg`ll;HZUa|&qj?V(
zfgqw!m)Pw{YhJ#dw<;JPesHSt%^Ga`r400{wY#`cAwv@D9ue+bl8;X{@EJZPSlqHJ
zU2^M5jn&yfN}b-c(sqXjWo)VIX@Kc{2lV&4_4|Fw@7-Ah_0I^CnVAV1c7Fea5psXI
zI~IDI6KYuP*jRK+`k?ht+iVLo`zlN9ugPl8v0)koa%3tVfVM-L(d*w>(#4IF3j-jO
z4IQgf^dqq=Z$c`PELdS^RF<#9^rXH<lo$rjrO*f&9y6O6hq?It>7lVO^|_y47Zo<<
z(y{UyXPtEJ$C5m4V2kYjLgQKle`yP+_6}w(JdZp1f^eX<chH(Mn7^kX=|TEvCs34<
zghZtzKTb|1PLx1|y9n(VxZv(=HNR@8qnY#Ld|&_mwF2z1H*==0)8gWtE#2v3Y~ZEq
zoScQap5I!@W_3j6Rj{1J<rv`=XmDj@WbFKPGj?-3wIB2xh$0v&nYZ=+&_pccyRQ6*
zXV`rZ8YG5wc$g|a&b&trx!=lLkN2TsFz>oL4lPW;V2{93+OWLn*Y=k@^`jXia$}{u
ziPTW>hQO~Kn(Tcbh0-APFNLywg;$k69gUr9cl+SSOn4F305XBnckc~r;kja=$!pHu
z`AwjwYzgThp22owa?pZW@}uF^s9)|_5D<dp6{t6j(iHn=o*{$%olv-wpijm*FO&M?
zd{3X^w(fn;_0sqPkaGNzK!pvi5bV&7g-MQ6)#`9s!niq_cWpoW{o&n4<aZD8ub!Km
zn<WE3y(ix2^w%R4!DheT??c3X>%maSAp+IxR*umyO-%$5`)+}rDG49?cN);*S^Z0m
z*0oRQetr#!q6;LNi-i^O2ON8w=DQEsG<6{gv8@7&w$Vd;DuG6oZ?3S$YZL0Z_{>zs
zALp(nfXcoog(t@olLW`*b}0Gu;_`YFE4xh}3ftrp2P<83nTxFRFp>)(|LFzz-vmF(
zCa?A97O)zqMU~;ju<x>>(xs66n%T6p>l>m}cb4f>`vKzx*p9VA0a;_WRM&wz%*dAE
zv7vC^2E<&eeE-wVGvL2K<Hefa-6y|!Jp_8miL_~A1e=V#D7F{lv<JNL68Gk+I|XTw
zYZGL^4Ex)FX`R*fm~|MvgtX6>sk(O{cJ%OZEY8n_AB#Ke%cDj(G3L=Z*J&J;XWcC&
zhgRXc2^G++>}wJb9Y!aHi{aqr5G?$%r+Q3XLS@;c%yj|UnfAj%dW0f(AO%SZ_mDk}
z+(1WpD~jm4B<RLp4C`&L)DlHS^a+?Qf(g80_UV|F`RDLiy7{h3TFQl)#TgwEb4sXe
zVS4EC+FyX}&!o<olw{78Rh-i>@?~JNe8|F06Ii(eC9Y_{_Axe3tZJ>yH@VJuZDA`G
z?!4k4{Wk|WST!%9&U^8KhjWSbf3Q}v1=&#(U5Wm2YC62;H%!h4&W7R7($waRk4-g#
zBMR^)!2_6&CGH;V&!1e)ta(rfcF}ze{3$y9UBcy<YXlk&1?@^!WPn)bi5?4&%XAr&
zWcUFXB9tkht%T{?!oPK!2#)hB|A$t){yC0sbAq`9QP~)@gK<Y+J+G?0B}(;&a|Kz@
ze%rh8S0+s0rw5AsIo0V3R!yBzb_$yQ58s_f&wxCeJi@eqV|IMUS23ioV2Q{f(YKAv
z?}A*`>~r{=L4;C{E#;y3x?%lr%3iSwOo~k}=O(rx*_04`H?6rP58`ceS~VLd_M@Pi
zV;!t%KzM`LH9lJj5klc~qUilU7$?`=aSe2JZ-{V2bJ_=)xjW#iV%97d#{N$OC*W^G
z<Cgc{^nZ{}eawHE(ZMXlOVnMu{GM@CZNohM=E7jX+JU_L{rT#^qyJkpA#QBdX8uL9
z)@kRed;3p~8h35$blpa5j%2<~g%mumJBKf}i{~02U+zLUhy5P1PeJ2HnsE?*1pQJ2
zcN6a^f+b3?KzHIK=Xp(2f~AadC{^gM5}u-&sHh=?5L&FRS*<~Vhl;Qe4rE&PxV%VK
zHG9x*)q2_IDBC7KvpHDULsz8937({mldH2ZZ7G9vg0YB$MzPQF-$p6F9gM8Y+^<R9
zgHg;VefG)juxStc)6Mibz1j@O@qdKBqU{Tvc(fdD!pj;g`dCg<(0T77SP5Ev9f>vh
zjBtdGYQl_Ao3Yp>2ijH#2?h;D8VeOyfW<1T9H3S1BS!+I3&OfT&@Hb}cW>%X2R%pv
ze^g-?Z_*<AiFRz*a<Yl@kCglQbuexHI;pq+n!2YO5D)mLSUO6W4?n~~0q-oHblMuL
zV37}+EUeQ+y+!sEYQ}8uqNq}-!Fa)pDLGm9{qDV+HbwR&IaLcwN;w*EP?N*6&MlX-
zA<1$5jRP~jX9K@Qg~(+r$;4@SfGX^&fXz|#wD4T$yNiy;(0%^@b@rW6Q8e4yLzW~-
zP$Wst86-1EP%@G;gGiJpAQ=WxkRU;jAV`)RhMZv#K_us#a~N_OU>N3(p7);jo^$T{
z)?MG9nYFsAyQ-_YcRkPE`>AG9`ljgfN<z9}85Lke5&{UZU?{y?(4}1DZWnMdbKfJ$
zI&%Tzi6UENJ!NYZZ@GB%H==>aPN`-9_@XsWM6t~AETTj!%bqk3F>>8Zt(rKuP}FPH
zcYlOMOHa<iZlbZ@!&aNc+}?m?aRo>G=OcjF(p!1b&s<C6frbwJ^*f6~Pl_~K2>(HD
zTQURW$bWO*{~Nu%|A}e;E7KzD;)I;oS&59D1JCah%?nmYW<_L_TGU!f-nwiX`VWp8
z{mu<-9`ZFUSOiTEy#i6)who{RWe+o|MW}x7kFxPk$(*SYIvrH5cm#87`(6|VKus=E
zKk>7bWkeI3kfk6x8B^P<B^4svKIQ7f5_D#GUz8t={smt5Z989FiM9>aP{6Fl|HMkE
z+_S1Abu5W<`&9%s@E^VHavd~uIi0+A$EPYm;=gXJSx4xzuqL#A?Zlm;?`k8(J~kMc
zJ;bQ~-{fp=LceK?yNZg<<T|Z~LgM+l=D#V|xV~trwo0z_ik6Q_P7*?g2KW^IHElA=
zqh<00EE|hFGXy(LEJBwk7lPhGz!8Wg%%Bp}PunQ|r6MpjvJVBLN?w8-q84J?gir-w
zsvy^_Jfr6SL4j}uCEA2IAEpnuFNghmnq<-Wpw8zFDQ8X$A>&I1{!(c$#vLC2Mv+}(
znR&9>KtM|@6`NP4gDAj=>tAy?Cqk%&9A-NC0XqLfx7TtUl`yRzFIM&J3qSUg78qg0
z|HdoGg7wxd84D{R&XOYHYSpZnh|L(eTfN^xGNJN)l2?F76cQ=3FOwz$KRo$ZFf%?n
zS}s{w+W_#9nTvOv68vT-$B~NWj;;qG9xZ-FS6xdt3t&_r4BQB2umrx#!a2YSg#ycs
zbWxOW)WSfjiErJiYtq$mmsU^`a^l%+Y|xBr?J~2o(i`Gw6i<>h@CTB99!0lo*d8dS
zzsmtKY0(#p#$w1lV*o6#O}2%nufQ^~px=>8yiIId+Mz1&!xGusmmVTFhLay~=M6by
z-~4Cn5;&ar)%@iPSZ_s@>lA(u50&&^d69=TdDz3RItBa+bn&AX@5O??VnuW|8qcxk
zk-wO1&LP7v%Q)c07MZNoC@=`OoBrI5P@Eq#vE3ch$p!(a{^V`uZYTd0ccf_k_*F(V
zfbq`i0w_2=ElLbJ!uXHSns$oP&D#n`zkwn=K$`X)b#*hJ!Qs7o!HfmfHwnrAosVe5
z!TApzSrnn%+3t0y`8{kvg~S;?!s<1CvV=v?(CzUmYzYCsUTPv)M%}_PZ$6!q0IzxX
zr=Zu#&?^`Nss}FHM)C+%9R<B=?uWGHA-9u};FIp>fkeyC(9h-|7zybjUKw2ip_tCO
zPO4pzmB<8F@EIJavf90cq~Z-qY`pVK2zosU9$!H1fQP75Z@2k#8Ib%kxXwdpo^W0t
zbXYHYt7QPV?CJt`#-rAf8ITavK{9S1>NO}2IumfKQ8#ZM<y{56++z5E5@ZgDCc%|$
zL`h*Sy={3W$`*KH3P-KXWm?CBAxIMNH|a?Lt?<jxLTdBP%C(kwv~*isP}bodU|P|>
zpxeufYSLNwM$=RyI4FTLh^lf&<Jd<%kLF`$*T7@DJ?T-`hdlSh|AaaTfS0y^3+vPa
zP3mA%e+l*2y{KbkGy>7H;`|MrNU4E|E$|433NLD>>+;Qx-py+7tMMc?6Adva^MC|S
zyH$%Xwc6&_pG4o3S2BO3M6iyA>i%oY(DNOKcT2oA*C~T6=Y>1c*?ALuL)1Rhb{&a4
z=nie}%DlNO03pk-5)Nmfqc<yBK{sRaJ-wg^E))_DM0UF(Z`)B<uZP%Ws87K+7eMP<
zAYcn9i&8!PkQp#_t9uhvm(x3io;5MlA@uf?Jt;Hj97u?Vx^_L8LG6EsqK1}Kz$fg$
zn49_&7Y`KpN^=gVnt0s<j=DWT&*fG#!`wb<=p1#o{Mk7hwd@G;hvAnbE8=z?g2K90
z+>Z>~s<h~MBxQ;=jn-DG*X%3IlzxSgU(~^!z8zNe?Bw_WyHCOiGiI7~s)S`f+kAwk
z1bFAp)fl)%f2r*Ct|wO)6#X_O2=Df|f07>**dNX?KK|v1@Fwj&Z4irUJ3*0Coan2(
z@-S24ImYTaaVaa;J{Ml^`Rj`hYvr@t*B0o9MSsTod*l86yZiTc%iIk2oAjF-25okD
zy?9&9r{Q#FQ_~As$yVA;_o!SuA7`-zv$HgUS>BVz1LEtbpqV}5AK15~hdeSo`jfZT
z--o-898ycg71F8zYnR+p3ILa=b%5$)LqxtDlcl%MQpS9<w{y>2AB3T3>}+zAPt<11
zj<Bet<1?c9_32<$C-tIQGbd-#U5{BNPfyQ0UO_(ssq&@Aw*pF(@2J&8QO6ma%x3`4
zg^Jze2QIauUx008njah2FoR<p#h@sKXfE91F3$7Jn9{FB>E{;Ja1aS{t<N@_WRPZ8
zuVrrUS4&#Sz+1jI^FE$7NhTP8R2!8QxV=;Ic(rYc>*AO3N?g*jCc8_l{UKD5V%~C!
zTyBC429esE=Dy}fCVXD!F8vmj`@dwvsm4MtT74y#dLB2?xV;zWJ@kS;<s$O1LS)`#
zKW6X-h1*}_x#??bzw}!<u`*904*_7*MQH(LZobjxP=>(6NJln-MFgjMfUep43xzu;
zCmH3Prly<TE?>dltGaCKlc<28%gJJajaxIh{v+-*zl*)T{5j3$jcaEI+sIz{Y(eBF
zj1)>{kN0$MgYawzK1%3<&5^AI*DD?8aKJqE;`}Kjc8eV)qy)c;<uiwQbbjZI8fV<|
zesQ7h>Kw9E;yWz!a4s+9!57ETZpqIP^!6jRWS@6eY`7mW)Q|LJ0CtL0o26&;Oj)%i
z^V#JyN}bC~b`#kP3a$tFuC`r_ZWaq-hl4odyJaeoruY+?_<Mw8fv4&R<Y%9vS`m{D
zV)<73Oa>g;4ncEpy^yC<Gm<A?zIf^GD`pVHwJ1XzAi^AiHx<<HSB74Omtl5ZVNT{V
ziJ9B)xqsB9uSi?XvQx>6lUNrnPXR_|CXlbeXSZngu$F1}PD8&Rnc-+2CxOj{3Z`Ql
zSQ~2Yw2|CZLO7!{V|RoR@ri^PzbuZ{b1CT01sT!_F5N0b27O^+;153zMp9<+@ZM$M
zzKD6lK>-|2ABbk|D~rZAL0(2{-eM2$dQQ|vH=QW~Ja?jsi)m_`K5@RRG5{9S3`F;s
zm|Mfu(%J%UDEzIE=pZNnl|wb+Nn**uQ$IoZeG=eUw($;SV8JS1P9{|Xu$HM_vA&wy
zE)6Mr;>0Tx(0TZ{WLOL5mvQ}yvP0su39cy?&qNuX7z3Z=j&HHk+{)lCT}2SURKf1e
zCwWIA&;h?>(1mjee~y4@S(|4Wke7GBP>5Ngta*bLSE`9GBkj}I&ACztlD0GEAQmMl
zWN|`$F*mu+x>N#mbZwHxQpP3)vX{YDC5XH{>r;NjE;$=|<`2j3?#7uvjwaC4%8x<z
z(VS4fqw<h@(f;9`T>)>SlO&!$4ep$OfAq=)hkbHeg<|(m#(3pjn^nB)=}%9Gw5g;>
zGD{14gBV@spB}Da8<m5Cvir)%b^zO+O@!tb8`qzjlRgePiR)OfTFBfnP4GEit~}vd
z6Q*IR1s&}f9?ZVh+QYwKziA5wYe#L<*t;iZiS6;u8<><xn88Rt8|=^CwBp*l8QXNO
zb)6_(Xm}Mwws`6Ax~yY%KCRF+Bh$OGu(Mh}r65@Q@cqW_gpzL}khe^;Vp0-2PpO&_
zVi~%{X>+^ioL9SBPqWefW+1X<b?<27cD!hIFor5|Hci1}yxP^XwxHPV%D||~sizSY
z-WZU-=A}NHyJWh~`8Dl@{Y{DQQ?>el5$0eqe!Bq`m`k($ubc10`*6Eo!|bmxc+Bf+
zinQ&e#yG#p5ZyR5Om+&Qn2ha8rMx+x&eBy2U|s&ADO?18|Fms<`5jDsB@oZX4Ey1+
z`C!WiCC~jd@aXi@$ML7S{k0?zWpmA$mVSo!i@90my9f4$1-$9#u@-;T#_)rFdt@a8
zzN@9?NKyKxHAJWSAR6<X-=8rb=ATOM96eK#1nfk4w(B5IJ{hkyQ5H%0af40F5-m#(
z^k2nK>6e>k-}N)m^n|YWQJfISAZ+fFQ%ts{<{HNOTOno%<}zPj;Iu38Z1ho&h(&e2
zN}u1aPj7!igN<Q=fnF_YqJ{~Bh9Z@z;s{clhPj`)if<ON(Gc}oYJ`&lq6N5KNpAo|
zFvlr4;EfxKYda*FB7AWJ>Nvv-K_l}csCAO3=GbjG^IleAPUE1-?bn#?Jk&fna0AY$
zg&EJyABk!L!fzPY1>=f7q>&;R3%}Mc`om)#CrfdMd6|?RoI|!=o!o!9yGI}RE&(ND
zthpRUp}AEk4{|<gKA7KnPng1cin`~vOdq`;e`?U}A5F)dDZ*u)AU=uljCZ+PU@N%0
zH<23#gUOU|zV&>O!#-`T1$f<n)v;{@HdH#p#BUE^T&LG?gGz^HUvQ5{&<z_5->O@K
zLN309=j#K&3g&xcc>G_4qGLN|0?SA4<svP@9`Ep#?0N+GwaJvDOw`rq;SBJgfXNf>
zbiZSHHPhyqV!!!@y);1%&8<d~p)Q;4WHx+|O?3uf6D7mcG^Dh^j%XB7sdzxFNiAF2
z=<feBzI!bGpp7e0J+1Yq&LbODronq+bAPDjtj`X3(%QB3S@3nQwF6L~&<6BlWEm{Y
zl!LIr-5cYz3L|ZVF7FWvqsK%rSoLSZE7}$#RYgxAt^gU?NUK~g<0B>}D*y!<nP6~4
zcz8I5x}styfQ^ZX>30P(tQ7RI2knZAibR&^V}DmXxUWqcveUcaetvd#28Vla*zc~c
zuExj5f77|`)$9c1AES?d%ggKf`O_U;hKq|UDJePrO7uerht4HpuV!LtY3M9ZIU+iG
zW8&U_w$;=<J@l-CFWk8zjj;}J@!I4#G2Ho+Ljc#gVlj!LB3ubDm)a701XHgNsG>vc
z(zKd}^0(1^iS*kw>8*n{o?9MI>gJh}r1Q^29*i-U-K<YM-=|+NrT=tMpriHeT29du
zgnbmVRpKoTYF*n|b%SC1KfYlj+n$~p**5pzJukQk+6}YEZNkc-%%R>sR;Of4MY6@%
z%3)i&N@(BcAhTz>IJ<1Pmw1eyn_Z-RUhPQMj96F%NtIs?#qV!^^6IL~kD;l^gpUh1
z@j}@;sls`Gz#jcdeS5C%Yl<FPH;%?`P@l~0tP+apn9GSRysQoLu-Zzvvt)%313(qd
z*1l?(jbHIZ1gB0WpV2jYT3QEO*wHT8EkYpY6gqHkx-~0Q_u>HPzm;#Lr8{uZv3g%C
zecEE1Q1dJuXnv$~995uszvaEGM<!hta0agu5761Rnz;w7#=3|ZeaFDh!N=*ZS?gCf
z^T^dSovH1XXI;z5cWb*S_^o3JC$H2v^WA#?!ZR%~I*x$jg^Yu?;5uoV&n*p*<^#)}
zNpDpU53HP<WVWQ;FHFP6lqm<&CALQL`oZVipqkX);@+XUxp-0esipvhob2{AS7IAV
z%6<Ip*#_@iAsKe-><PWrf==s^?FsWn#08T!o+UgMzHZB3R!#w*+WsMC-E89TGqhr1
ze{wP!=!nZpt8Z8Fl$YTioz$oc8AVNRdF|Cq#5Hd=0dt3#Sm4%jQPM}=k}2!S@e~9J
z-K?Gyz-@KFyFaSF)FQ#yW4C2(IAQ`PkFNTSv+Y<%Kl@z&mXs|_k05)ev*>d{hM&uz
zsE0$(4wZg<N975A;tUT6TAOv*WjKY<lBOY{+x5w@^v@SS%dc_Lb~7R1T|-tb9L>*r
zGz$i}!J9#}tw}aKeIj4{FX(Qz#Hz_k4XJO>FV)dw!ZaAnUR>C*m<IadaU*vaCU)_8
z{Hiy$1{Uo~XFtTt12m${KXP+WS{UuvTf^H;qSDi+y|`ylk!$j6KsLy7K8&lkWY&Wa
zU0dACe9KhWJ{z3=gl6Gl*SKp@%sqyop)I?ru!BBdpz0y8tu9a_?8)1GE!p|AV`8lr
zfv2_mTH-|FP$Yi0!>JwM?CFo0>fdUW9!n8SAC!~YWJk?Ug%6tjGv)l;>8%B&m*def
zB7v#BBP5NGpysP>SIM)`IpKtxhvpmrxqM9diaO~@NRJ3dMOU2XkGIcTPaxe(dUdQ!
zt3*EXj}54H-)n~N`@OrYS)v2-ukY$64sUKhW@x0(uegvmv}r4Rn()|g{&cL*@xxSq
z-$Vgdw`<|b$$2lbNsqN==DLY_g#Za7nzeWBIH4q-8})EEcu<x4Ve9w_A#(|Xvi2Q-
zj-EUewDLW(_0YI&#|Y4#k_R;MaFbE2zUs{v#Q{jVoE7vNB&N6OT*Gj<FrJ@JtUXO)
z%!TB#-oD6%+^$w7oey0U#Zl*DVL1DK;{beA?SAeUBbw+OfwpWEISzbMW{cA<W7zY`
z38@?aWqpE}icqgCYmY?06YO%SB-~O77lpfz^f|Fh8ES@6-C5C_&?YdPOm}s#iN|JQ
z_Qq+u?mgGX8u3bq>GQnszy-OlkfVsH(~U?Lx%X=igS%8BWxGP?PZ47G90(Jzhg^#9
zb!a?mx#@L{6M_e5oJI%n#0XE(7K2>^D<NJADm_xqwDwgbvW;%c3h!dqQ0A9VSO{0m
zk&`WKVer(+4+B)g4L~y)Ib%II-5(`u$&;dnS_G=f%XFXTN7iY|k<|&jaJFIm{7UZq
zG<E(lDRGZdn$q)Pr4p2e&J#i;j)Tavg;(<>j`z>?iIdWsL4^TewZe{Hsky?bj=e%t
zrH`k^`$woh5E^prstFrF4jzj>o|F<&i^SNjrkC>Eu8{4U!}GnNt%M*}><B?zGGqnq
zs~V=8;wF)xVl6)}gogw3%Qi_R<+<zmwvLea91#}k8<ULa3`rInJZEl2!*}I7Wq22-
z&#f0X>J$}0CH_d6<tpb7X(Wg5%d%_h6tmBthAJVf-{yN!%F3M!KEg;c(em}!SDAj8
z>Zq2G9MiHL%R6psLs;8|D`KA(X%fZNQA1yoja`=ASchGQt9#z_$&=V%o8LayX0F$n
zm{qbeTh4squ0~47FF&ub>vy&aE0fpnc*E?(%Ha3Pm#)oby15DKC+}w{yO$nYTt9v&
zl<L}Uf3}!%;kLOOOA~uwoL;wM7@B6WR3odP-NJd=2%=oKE4b8$0_4I7JTew;Z5@~&
z`Kbb|oo959bUX^{0!ps<@yy2zW0%;|*jstYMyAxPYE2F|Zt0xrCX(99YHPh&cTXcd
z4D$#8vi7y~bLJUYdb=lLHK`{1Z)y`o5r(prh@Fs|$;e1P7N_}oLAy3`xncPPN>-)X
z)be~j8+Xm`KcgjCgA=*E$EToF!+yhI#iq`#_vt3H4AYXmn`&Bakw`!Y)%6s0%}5oS
z<IAqOho*)Qo!q&Ka!Vzv!j9&noq|k0(>kYhRXO<17WiWDFvz>(^re`aLZ=hPZO;sr
z8AUecsPz58eGOhw(L4rzX_Km+YWWXzdHji#GH;kU*91BA+|D8v7(l`c%BG;zlJyq4
zF9ZNmjB2_sk=m?=iab;ywHx&>+E1oM1J5rFnxmW@s?ez~xxS~HuW7>%k^#7G`ihWn
zYgQd3L7LJXxh4SjFrPesyY)MZ2wO4&%iE(q$6<K@RhF7!2<Sxu@6iv<?1z}cT=LkS
zKcf9U@)8w#IOVprs*(QW|7rzr1%Y_P$~n!UKC7bl%J~nT^Zr_@W)pV!#;}DrO3U4B
zNP7BxguPcE$$5=aB3x&8^il?mXHvZ|)XDHItHW_H*%A{r1$C`Sq=p$g4ua)lYE&jw
z&^1oNS4rpDh2Dod=K!b(m+c%P!t+Cx!q9N&4@UX}htL>_?HOM(2@#PSEe8`C=%8_s
z_+3S^&gQHF-sHZCv9U2U*2&H)ii(O-Q&o*uz2cVogR8dFK0=4c{{mirFxJ0Z^e-^>
z58(9&jQv4qe}l2>6UEne@)_&r5Rf@yIZS{{g9M+5FFAnxu#x$b9Mdr$DY}`EZ;(0O
z*NrTE$#XlO8_dY-qjuDEdo1e}cav0Eg}#__z434R6i2O&Mr@DxQ~2(Og$anTypd#8
zP;irI^{~ommdIowFY2eG+(_ynrDQ$k`F+u!gTXQwJdJP0j{A^<Nous@sgg6RtS8Cd
zFKwlz6D$XVBObJiJPuyaEEwOR<qBlI-GYXjT#|lxpYKw*pJ0l(_18N_xk;oi6QyvF
z``kYhVL|s$K|vvzPbiSn3R=t`V81=8)H58{xv^?bDj3XZbd5<~PsqpqA%tmY<8y;~
z%k}RLXU)64+%q>UOQfWIn0nH)aV1T2xWjA((5<*3E{3(DepF`jpVKn`L6;+~2W?Qo
z*-4QW7P%sfakv@$Gj2vc8rClF*mjR~J?FszgyX(392|VpaWn5<><^ikIu&6>170n$
z`)^m*AQ+@?cbiHEy5=tE8SYvhb9GwWQN6RnOcP#4>P$-hsGmfeL*6Mg>r@&e4PR9T
zz4zBN5hERGux9uaBMVm157CrI-xSd0@W;eb*b7P-*?(H@%{t@T_88YP6qoKZ&^6Y-
zn(;ENdb(|r?5Zqs4^R>C+;dO4SxJ4Et9f$Mj(xZOBd_B1&yy|hgR(1`tQrevz8-GA
z(&=Pz5Xp38P>U4m5}|6Ud!8|BTk<q{I??ni|F?2L1)|&Ey*k-oDgxnnR##H{0Zw}m
z%Er&1{_I1zebcIjQE(Z49ozInp4w(gliY&Rf5R-k1of?c29@yWuWNYau7y0s6?nYr
zdIV*urJA}FfU(g0DCNiI_L##CuU<`TQzVL;1$kL=2>}3v(BIz(_$FBL2yyu~zqI4s
zMz?gL*<bJmAgAQ3@9&a*T!z(M4)bvf4;RPEsPmEr5zApWjdPz|tosm%{f#TmN)|=^
zDUu-e(@7Z#)g5sYP8@gi?adN(4Gn9xp}S6Fp&MGR;&Yzptq#X0Ca4X|aGrZ-!=mK_
zi^*rr7V7Mp>PWnq`3*CRv4g|<rnuoSoy1{V7%b-Kk`&E)3X0}`PcI<aeVyK3!((RU
z<fm8K(=$_H)C96QHig`K(uT7HJ^l*ytoAQrw4qyWJx@nQ=Ux2Ypd!<O<-zt2BDIHo
zQ&<&PMXDHbuW~HmCDNkWM?B&;2FoLizn>t}Hh3^{pHnj3%&osrm-|KIWj|p?2ko1Z
z*N}4aaYIofuY;iM6D02wLfypR$>B3E-<&}K5PmIR$<DsJeJh2T9HWU;Xs6!DEIvob
zxia4@Plyh$3FKs(luW}gfJ9t8>Y@izW1lM^c=x3oCQmJ(w=Qw+p{l2q!rP`|x`#ul
zPY6A#s{6Doem%Cu60n67iu-;~*>7zqGtPKfyohJ|uIN>!t?%G;K1EH~<}CU2L-h%E
z-$#EYr926jcVMo{<#g}_+Xli1{-Go2c)B^;n@ZbK;p)*fmwGa5k;m3-d6~Xq8Tym5
ziFw1=7?%!^YvHY!kyzc~|7;@cCOXgmvwrOx^WD9W)%nT=qqIzrj;E3CLg7H)yZN6U
zpTq4<;*H8C5x%H2r|<kvu<WTA0Xvwba?N*I0RS}rj#MTUSUN<`WQ7hedCJGx0MLF1
zvWG9$dAEXHY9dK7(g6v?ej6;Y+rx35mU2SFz@xp`1lfmIk6te%pd=7y3_d@{%wfiL
zA{XgPjW5^CDk~2-ZVxm&sgK4V$akml3sGP!?LR-oIb@hPx?eL4eElXjQv*jQ)NMhT
zA;_z0M@><2>0SWIZzhbPu6uuVZqyeoQrYwPh=z}FWJxY|+>vN}+s6boOnizIbd~Q7
z81;$-oUuHC)cg;0(3W;n{I?DB!BxvUDCAJl8GSy-PD>mao?WM99hKaWn=^m25W^vV
z0FPzVP~c1Uw7-+X@yE83+o=(vZKh_OPvy;qJiOoMP6#(wWU>*uT@kNaSdw`9gNN}%
z#42AE;<FhW%-l|k85ho@-ec<&Npbb^M!7#zVnqKZ9J68N6s;BP6uiV%%Zo4MP|o8k
zP$y?iZZNmJ9bLc^m?tkX<x2cz9jEGxpNj5(_7-=rDVv8{UR=-oqLjfxzhzVN84gQ^
zM>p>$ANIDdx8&%%QO8ACuzqPlQ}IU@8vo)MKwshi=0f;;$xAh0J9bva!os5EXJX2U
zh>DJmmIIXNaouG_`zSgW8a>#@bz87C6cx`zE&u7N`1|z#UWWf)D<(Xe<L>vfO|Rxa
z)Tp%z3;7cCw@V|{{;bV^CkhL78|wjv4vaK7#s>NS9I77sNVrP<L-F1U=(x-PhHV%f
z6SL_P`0nd|OKsIIMJI>EJzY`z5)k6K!LE7?HkpP&3WV7jpf$GxIT(P}l61LqFv-)1
z4!4{GUz4jVk`Y;2gk;psLMvY4Vu`!IQ&GI9O|<MFg%yUDAG0uZ;?&O#Pz#_<kpt$}
z;DlV##_ud>voVIv?)(+wnY+Mmnj*q@aBRiQhVia-?X$YsNAh=daf#}An~-40=?mP1
zaE_eI<cfR*k@(q~D@xLJK0X2%)XK=K&I+E(YlEdiLq0%GSLlD=ailW9?vZ)~b_lsV
z=C@vLnDR?T7P*HsMri^b=X>^d@ZEZZmS?2t<)zKYhX^2_O@9{oe#2j?jvom<UQ6`3
z&Od_bqhCSB?-2j0;6Y)u%Lqdq<OjerwrfyK&O`3U_=0a6uc!FYJ3f7ZaemB5tN?;X
zGQEr7Tl^nmVi`o=nI&h%uekyZf!|^<v;5T&ALu-8E4cTYV;y9;_hu#d)d$+T=UF|#
z$deWz$_zP|TuUOenx6QxfE9VY;R~J?g=hE2v5xE-L$>&@Px;PaQdB=n7>+cX;W7PP
zGJPXDB73O?{!WW-@HV<>Uo>nI4Bl}hS{ByoA~6WmF&<4d@NV41cjZak$S=JuUE6jn
zD}mhRihIYP!t`AOahDTU4f=ow0FJZ;)6=Ig%YlvJ#A6H(Se7V)UQ|o5XtCAIc(nL-
zZ6bAEQR~G<?D#G)=v7gZS+zV>6$|`(H^hq;X;X6S{>-@CZ|~kxb-=Utf>bueZK+}=
zc#gBu3p5kI`xL0}Los=_ks;^Q5RzPo=VEBXW8X4kc%E#r_G~|+qxLj68j&|}f$fp-
z&DMY31?mjk#tTkBE;7_Z?VQ`9i}?@EkO?4)Y{v^uK4+ltw+4#5!Yl4;1Aj5&bSBUl
za6jn@e9hTVA*nw)=tg-7<nrUjwSMr%YEjGVyO*1f?-Vr*<dVC)8C>9xkxn9!^5<2E
ziwL+o&3W8M^~Iapa*D>VI7qzO6^3PpyLsObzA|bD&}$z_SIN+ya5s(X{h*eLm<PDT
z@Db@&$6jT-CL`T8bBqL^%2ufm9er6KUS3#%J{7G~#JR~M0rY1!>%DwPY;+q{;6M0i
zfl%zP24C}kl{{bp7B(&JBRz-baqzbf;Z7%gLw0)fEjAxp8v~6!*RBu0q53Hj6l@>?
zl0LAzIV^G9@&g$P15!UG_ugzaD)ymnq52F<)StU$uOTEPuCPc0#id4GCNDNzmoN_M
zNW-p$n%S4+Yr%}rr#8XDeqmN23u&Esm`piEEB@_cGQkSK!LPUe$ETblMN1*>1~py>
z+(QL=6P`X9*ZX&)B^|#vR~f^Anbmg|y`S>e2aec%1?yb2Z#<)VAeQ&hH|k9DY;V22
zK8dV>w8nOcdBDmXfr>{ZbL0P%2xj)v6f&#uTo4NKb~*9ZK~=y^GbVl}dDfiEwh0mU
z;u%2HVfL_dgKf8Mp|LDK%l%lLpBL7i@Gz+%IQq>Jw!E&gYj+%)E^(<dU(7m)3Y6P_
zP;*l`aCwNexFy@*?sEQ)&XN8(JW3SWyjoOnDYo!TOiD6Hkb6MT=v>oVZbKA`Xl`8o
zeg<y5dxntNFr~M+V^BR*zT};WfH(x+ooUoH-<lWhpR>zD^_^Gg(&^La;BB1zT=HK!
zrZd$E$bs2g^p=DARhuX38&^{cDk|$*k2C4_+zKUMHCLEXOjAH@po1Q`>WUz;Ai5P1
zVo<W<&rP;Y8G(b;rD*w7S}MFj;_vW0<B|4U?dP$aU=9LmcO%-%vFDaD$H9VBhj*91
z7=5K3e7#iV%BVNc=EV@(^=Mc;xQ4^}SF5QE6;2|p9q!Xf2Gg9V4kigcsbOi6Vl}`Z
zk>z<x#w9;Ol0gTxRnJYV!wGpnHnM(%2tMos1ihBWP^TD0UG0O=bcrJ#qhD=!O#Hp?
zib&31c6TQV^z6aRKTPcV1_{@wZA<dsw%3e2;(c-!a}Q30V#kX|Xwnd^Mah1+7CLrk
zM7D7K5vjKIarq$HXb0J(8;qhFt(9Anq2cgFuyUAU&%Ps$R$!E{CE6pF!nW@F1Iyi^
z_d6J|4#_l@c<8<V$(8-!cEp>0>KMyh@!rlCav+{`bmPK7Fiz@T==)$CrW}=(t>7;V
z{Ul5|{)9_dX!rZyp7#Hb_4LolBjf6;usc5jiWt#;{MYD7`VYVU?}hq*rI#YcD2Dxc
X`8a8#&{Xs{!2l{snu_J}mLdNIi6h+L

literal 0
HcmV?d00001

diff --git a/doc/assistant/xmppnudge.png b/doc/assistant/xmppnudge.png
new file mode 100644
index 0000000000000000000000000000000000000000..b3a0658cbfc1d62839c20952b588ac469cab716f
GIT binary patch
literal 6156
zcmZ8l1yCEzwhr!E+-ZSQyg-rSk|M=g+}#OKQi?-x3PoC+;1n(HP^2^zf;G4XcS@iT
zTp$0v_szU_XJ>b3cXrPC&d%)F^L-z6v{Xn483+LY0EwEa^4o{`@S%s|V?K<f`~JNT
z6Ryo`6=lHvKP|trH2GnNz*E&23;+;4`ln+6va;zOHu2u8X#(+(gpA~m1b*ec*#ZD)
zGu4z8^nB-0IYD~5j=BBaNyrH72>HSYTJ|KKd|@7gBpSnPcXQY8{1YstO$+9Z2HKA8
z4W*^vz2TlY+l8v{j<bvJ_GTqbOZyW(OqVz3h=i+DRppZU4pLc{Kq8+*aA9$jR6-q`
z9Bt?IAxQEs$aD?}<?3ZN)9>VMS;6jYpAc!kgOPLDk69TRfKVa97%l;}BquI%RnbTI
z99aa|lp_&15oSUyGph&nQYy}A5;5eVy#qxJwzf3=@NgA$85Bjwtex`aBh?WjJ7q!W
z8AY@@4WkMW&)C_FzWFIo*K18g5xa)_OJO-L>}=)F7DZMnkRp-dF@rJHD_>q~FKX2c
zxd(^;-{*r{Y|M`in4!udq4I^9@@!)o8MfK$>p9F0QPv%j#4w}bnTI6>)d-)TT^c!N
zr?~&CsA#^eZ)Wl$#Nb<#>m7LQ=~jG9jDt9A+M@H_PD6Jqy_$aG1YzmawhU~D9s3k2
z;+6=^NKR*{x6$K?UJSl9`98GU5nL67T-7O`+Rcp06lMIi9J+$;S}jg_OsvwDDR)zh
zvT;SULUGBNBk>w^n`yW9Xv!}ld6#an<uBtFr0<JH(wAzOHB=D`o&0fS<(y@{hpz#f
z-&rt6k%5<PD3Tg7SQQJqC;F%r*3%jPro5iTNFaGY(W77i<<B9xB<@%u>_9uBmtEd~
zY`zo_+Z*Xbb@~LKC|g%>3FHStwf*7at=%8UpYfi92C|9m#hn-d@O6yh!%4xU!$w71
zIBhr!_D0fETm}^~$UCKST7TYgwv}h(NofOYGY}St8LPxL4h!LoUJrX>7)#Eu9@gwJ
z%FRPp9~A^LgO1xCJ$I|{m&jStw-YvwV*kE)Vt4?GVwbAap|L9&y9s#_a!O(^D0Y1z
zMay7$Jq=4S^L=i6=(-rvMZ5bCB8}C`{Aj4$eSL*E1F`z}T$qYFTVgW2#<x54i}iJT
z%3#UDOZv{+y3`bbiI%u?gwN^ONmoaaYNsmE3S7nemh|%5_Y*1^<jrMqg#|=GjnMS3
zDn-giv+yNEJfzVilz%80(Y#=Jn_wx5_fHh;ulL1kCIhXVS@bdBiD0*2j_7fEM4l5s
z=kHo`>^d`um?VGASLISbrni61HKV0HLk>r(a{&xaFSd0lM0L0e2|%so5l)MNw`m|x
zw+>%plMZ!y9H+_W>guls3Nb28+9i}|Ef=RbJK)XUED{r|T516kjDzx;nnMUFW2$PE
zqpKFFx%MmG@k@|AQ8*6}mvF|?b0s`00b=pK?~_>m9FpjVjMuhyk!NYCZZ57fRds3X
zO!p$pV5-rV(G7h`e55JfuG7F>WY_=dP9^@Zz*CdDapQ;N&`0(S*;AcCTh6CZUr47U
z0#S3vVUA5dI63+r0y*@=j;Go`Vc`?8(W}_><86D<cwXq~zP0rpbd%dpR0OeDn9UfX
zev+PdwYPULK6T36$p{|DkT7es`t>Bw+gm7B@tTDB6U6bwaorrQ)%IIFJEzJXW3<(n
z(%Va>M8+n-gi(0AX+q9jCl!5D_jm3Z5!1NoN|%EJoLWC1E=0Y7<OjOXm$0m+$9M?7
zMUHFQEUi{b?8R-Si^IQbr3ZoeUfT3|f$m6^!d&V+EOFGkBTkI4K{TRo+b4`m8(_nc
z!Yu}3bm_*!hRh!Vv`aZf79_;ShBaY;x1x3OZip3p04L|VB0WT%9U1&nDbf{mb~QgA
zmL*4<dPl;BB{U59QIN<70BD|X?6ajEW<pX|D$q|K<uJ`<?vCWpjGp15L2w(Qv_1?v
ztJc_DvZm0{5-bnDk4mdqJWgt>;&FSf)pzNBI_?KUsi!iQm9SXFy6WQo$4(9TpRK)L
zf=|kwr=jA)4e`ivMS*n2PebkeGpFUw;5PSM7KEVwd^*qhhiztear>`<IbRxR0Cqe=
z3H?5m;Ti<#)b#_#K)z)#$k9in&~~ol@p`9L+}!vSQmUCpPz5!?mi<B82w~cdyXf90
zv-lb+q)A=B!HIS2>*A8*s;{(QG_;u&n{{Vdi9cSnW27i1+@a<8>7|%hz?@gNe9BM*
zi;)=2!4VaVPR$MeGs;cAhpuy3nNq3GA7^fz{nPA?34iW@HR|0$=h38><K$Ge#YHw2
zNZN4elHP^`k>yNXemyoW!EJ+>_94cCqQ{>yn&JL%6Z3Ae#7JsDt}C~>P(bc-dCeV$
zPO{0X%fr&LWx&P9y?LxH&@*}uOgaN6Y(&<ALmJ)d)>l!ZyFouHM@HP!Zd<!R3w!x-
zxzEJyx$A6)<{y=Iy*xHvevSBg$TxsI)MG6}6=sZKfGh_3h^sS<Wc&S0UxA18d+7(o
zw(u(>Ax(XsUL_OoX!dMSdO50H1()9FfYMEI^&NVC+aN%(U)H>*UX;YTwCB%q8%jDw
zCwnyXdX`vM<a3_=^p2l0ugUqYiJ=OgGsvPC{TzJB;QHPE-gyCf&;61ncZ9+D3Gihn
zA|uj6`)6U#uFo^9{7hWB4PJ~Nr0>T(v7UMD1bS=}Y=)dKY6Cj1*P0C&2;`&Sat`6e
zXcRgm$oDjB5m=5vf(cK$UNn9&;feK1a#(c#Q@>W%2qlbQMo;0je`qknU+3PIBKG_^
zT%3(Tpeeo(-%3^f=Nqjj*>m@29A+2KKMUs7E6VsqT?~COqj>$S8b`rN%B;l{sv*Ch
z_M*H%)G2#-__VG<p1#lX=L`MXK*FTQv?%VLZsr~uOkyHmMw?P1pW^4V*v1P@XA*MN
z2Pk><-83Yzy)sn2RnU;Z$9s$t!Ym|Jkfu4(O5w`0+GXa9oB|TvD@j}Wg=DB_P{)|$
z$rsKMy?II`X+QY1;UI6$#Zxx7HS-nt*HOYlvg8O3a&~v$<nRUXEP4Dbag3aEPI7Qq
ztW~ut`QsqBTB)K7#r7wUi8ABWgIOx`aw(*_#7=ApuL+w;?L05Q?1*KrNXCiiUVCd5
za(ndEE1rTC-*T9Q0J;!C6u~u#D^G@{CBC+xC<E*HHGzJb6%^T!U2=B0_KD1;ifY~e
z?(-*X7*99%`bQ_ZGFF-tHdb=iSQb#%g}uHwQsaGSpML$b#Buw}%dUI>5uh$ChLAX!
zb$kBChxeIgi4l<9+sm`5ZecSe2@`KG5d&}w;#!hd?nMTRI3@Kw)+lIRm_{G%)?Aw(
z_ZvDZL4PVyY9sPeaV_!8BB{K0qx^BByLJe;hiS)R)slW?ReZa>+IC=w{PW&a?9PF0
zHz#WqBCyovbUh;f_8}#=^ONP!{rrs3prnqR9O#+q8-Ke3xP2atke3egc+S}<sDQ^<
zt#iFDSZ(16;jyr6fRhgnki3zW3E6Uxg_1BdX`DUHhf!R#@>(i?i_*{u<C~uBM`dRl
z7U>QWesItC4eRIEu3Fr0PZnhK6mff@BiGwSRat0=%~Uvlaca3tY92Do2)DCR<0(*L
za%)vYWm(`EE|KWXV9TXWkZU7aoYF=y(7?ua>c}ukySkFV&5p41FS>m3j;;ZSb}IM#
z%}V88fOnocO-G_%f82zs^8VWns5%+jzD%1}Q%PE8xzHF>fugDw+n6{L^V1NjQCIzR
zqbX*2(&$~?%;3t{Q?X4Kqz7vaY3F0|`uU4IM<qhOstD4tt=h<WFGw!WVZh}<Krx-o
zHTrKbSOP!R35OGIW5<||vE$-Fzt?4U6b$<;5{h6pp~r!sVg<Ydi1OE}Wt7TelBW8s
zcN2dl87M|e%z8%7&vOm{+K0Is=9mV}yPac756|0-A1V4D=SC&P82sz%+_j+BQ{FGu
z=|;Cw|Jt>FizPDMGqscw$saOpZZ?`W3OOC!?Mlznq%Nn+*CJH|xjC}&<D5;g#*rwS
z5b#SH#W(hl)4HUmR{9?@kxoj1XY8;@HGYqRMgf>)OVNC}2~-XhFOR1tVv2((sK$;t
z;gp&mo%5d_Cj8XEN}kseA#o8Nso^fsdL`6U*GM&M7$S`djY*|&!!96b!gxPc`;ae8
zoLirw|6Jjb=3QOwRFBx;%D<JCG5o8q0<J13LU}IUt#s`E<e%z3M5ZWAN`e*iy<dkb
zp6@ALT@UTYOpF4*VEe6pd0X#t-f@9ilFWrZQ3=y%J&b8>ll0<%NB9B8#2=}Oz82d4
zX<S#8pd>s@Fi$w|PumZqT0MUwifHqkHuPeyo@~8D3zFTmul_jtHa?=2=f}gBK<?1x
zPO5jM&f_1M(q9n!DQHV9bG!kk{?M@gM2Jo*#s9$`CkZ;`zHJU;B`;U#n1slg$d16c
zxwiHq*F96C(D*nZ;-aKG5LlCOEYZuKRJsL!WXaexdDgv5JbyrO*rkK%eRGL0W$=%(
zTx`;R|IL;H7U*ax@WyAb-p|mb)s#)iY?Yszuj|~DD>*faic;OOtI$xxk7<ntZV}aJ
zqBZAq(6$)0BbHfsx&?q#SeSNmeWYC8Ga42W#Mp!_V$!eGyD3;7$t($H4v#1#&7P#!
z>`?2nfFoLQgdsP@1GN6v`%ipK_=Dy-)m-SOkaLb2=5F4rt0%jv@x?>YT{!hRv@Glq
z`L!1;9uM(I;{Su-LjM7Qj%?Xqak-$QNdF8EQZZ!XCL@@;sj{uScx4&@!Bq0nfx`4R
zqaF+>Q~w8mGMN15{E4BSACtV$sz<dJ0UXLN!(8+})A~7QvU!<3<9s{7&;7WwJ&6#Q
z!?d$4Z(Ub=-utyL;(Mn%sq2L0^UZevg~)EIT2Y|sgk)c2&6`qeD*c=%SDYqIa6oZ!
z-vk?#cfDZPPaB29&(}U+nvs9Lzl!Xc-|+`>_DYJsoBOB1c^$G>Gvy~0Yl`sqH97PW
zf6SVjeVOeBqP5PC25lYHN_fDxp(gusa`S~FBJMZ1-OFZ5Sy&7~{<yzzeEi$7vdoki
zx^-`lU&xQ&O^6Y|Za#C1oEjiiSNH5WzvZh-=^*slgdrRPmZJfn(Z<jGbfrTY`YPj6
zB-bUsQu^85L-&15u^v96WIr**gTgVyk1}OU1cbb}&w^txqEIWXOn{p&?Tkes3qB$K
z2)}`LMA=)J?a%*XdJkmpzbNQ`)4_i;!haodfEv#pr3Ls$-V+m9TToI{Z{AAP6#CiN
ztlgxB7KQA&>@%^K`mNTAfyaiHhXusAlua}c+*#f2&u@;m9eR7&lcm$zAWqm_*J=wM
zdB1~%WUO<Q(Y?LB+P}@iACvM)b`y~Skq?V&Hy;IMO@v4mR0>a}jyo!QE>dlKbmzuc
zTw6l}f<fnHLd!$U#l^LSKoZl~W!8Cq?9kPI09rWLFpm#XJvM?<1LEG{tz;#9ejX<j
zjQ9K_UAKs1b*$P62ZtMZqo?~w?w#+tkSxQ-z6zblwLlWVRqUXdbKsv;JeTtw1WIkW
zjaNJKD@j3`C6RVe0B|Z-PsoXHCfe9X%rbuSs?RHEz00j!SW%_;oAUmj9Ra1kHfWx#
zIkuYNj>!^K#fxpt{=5FklObMeSQ<>bSA#mnK;d)D&TKgo@bN4+H)XymfEOzc8}xS5
zrQ%qI*GP}4@oF+Y{4s_b71c*sZ;A{9jxc?V&eM}JN->F-q_N7%{h{$|tW~of6|){D
zSmnpAfW+IecS|;5nLqomjd(#BGgxmW!&qoezT_<w#0Z*JMm!!v8|*jb7hbL`a~b3v
zF5NiJ)I`;_c-V{_6~I(HJfl<mQKmH;(+5-CO^$wH7I-v+PI{;ji_T})$lOVA00|IU
z|D({$@G;~t(1XAz<(?b*4Vsi1*cfO$wKQ3%IoIUjz-tTvu0!XRg4-H}8T7B~^A>aU
zzZ;U#sDswDEeEO=zuoWh4y6(hgx>ou!=+7f&A)4h6e2TptyU5@m84`Fwc|}%rEA+q
zJ>5O_J|5c-7!Ocp2HIj)ri$^gyAF&U?}GzGz=S~X1q;n7B?6`5!{x#)dN8rQv&oSq
zQ&Z(U7#sEGa6y*FTR{8j@5D3H8sh~040Tg}yu9h~$cf0e)TCVVJR#N$HEwckoEUth
zcl!*G*cr{_WTqc$v&jRlCVWpr94b_q=KvC=CGyL=<XW`q&jObhLt1}g)8OT)@irJG
z+z#t~sM?Nqe2b+~h2)yiYi7A4OTJ5-;mK3`@-l>SGgSO-G%v44TRd}go<<scgYl77
zRikxu-sGSAS!<awlS|D^CsG8g&|<Cab|WAsd!b6^_ceExW1zN@*AW$#=qV9d`*1$e
zzt=!Ktb_=b*Ohy_IPhUmj=qwyM-2*V#<KEsAqL1Yp^eM2Oee}n4rc`te|TBfzDJEe
zW2C!(Av3drW12$($PJJ;zRDX*@27;i6!L_WE&cJhWV{F6O)~%aYQuYvX_~pwN>_eN
zP3z_@X4Wng==_ND^D~D}GbYZk!SOO=OMhj;$12o}GFVxfZ=W-yC4^?>gI6>uK)!#+
zCZ`2kApV8?A~`_xw1I(jW|Bk`K<9ONJtRkgWyX>P&{-V9r$wuYpNcH8B;NWGq)+P>
zVWf#~+A#+T%NlOR7KG*S7*t5lnExTS;Sl-t>Bxi^WJEkFDTd*Dw}1ogmFC+iW^;c!
zM*PDosI^k{{;u3LnO+!fD-XUac_g}5&{LPe@k0Lfbym7nY8}sZj8bwd{JxCXDkaV)
zNF+y>WE?MK{<-XagfyX^8)P%DE6MKGd}x68_dE5b)h6m-75yX6SquiR$QJvt<GMOJ
z`Z%>%45I-JYujw;kl6RVJhrL7DQNYMJc&PU#P}Kgc&&g8&QnG&nv1i_f{Sb#UZPi-
zoZb)q8USi<cb$fFBH3SG=Ts#!keBiXOj<d2KdR+9eT}9R`vad=5y>BuY0;GPo<v!g
zJ3(HZBXylIy^R~2$!67AFLX*=&08u@el-GgNv3<Y{gXp}2`D)8tQeGV1(4;;CZA0<
zNXATn=F{vO=D!YN*(dH%lrEUK)V^Qn5c?|<8BgI=ZlyAPusU8iym9jh95B&lbHij!
zhKK&5U8372AqjtGp|hOJ<n|6EF+G1$#hE4yBBl#!IZd?<&m}5aU+ll*th!OCvYtJ=
zz3-HqOIR#bkP@6ombeKR8aT9Trg7yf^;qj+5@@(;Y`eOoiZiv9T#Uy{KV}SEpN+Q_
zY~!zSB{?`s?(U?p^1EbpH@oWU*-A6ND!U%<Ei7SmK?lQc;pA@J-Tud{Z%yNxq6+H7
z6HdISaR%>qXpm1#t7JB71V_9Vh7wO8I2&&;GYk7>FYl;C_g7TXlD~`eJ*&7Pn`z~_
zVNxK&JN+VVez|&D!dmK^<7pWfAbh(lV{I&UxG9)Fjl*xu5gqzd!gBz_a=9|?NxI@U
z#&l=x-wiy0JNO#tM+CeL>dXSO{UBHGJohY})D|pNfVw{5Z#kBI2M?2^S7m{f_xfXI
zr>~T=6+b0(P!NTL7b%uNcYGT0J*V<xM1{`o4+Cm9S#x{`LWX}mXXwVL&c!6gww+oq
z=`u{AQ*_fVUoTRZQZC)?P@H+5j#<W$Y<*;_=AxDldS1g0L|5uwcPeXkeP9v}Uwn7b
z2@P0qB0rEh3!V^s!kcyYdg{%bl#f{1VK3mpC6c3Z3%{@cN__><E#k;h6-8KxssMpF
zw`UPT-9>&DGMfxFB~fakf_lQq>swPuv##~fkboI%;El5AC29sond(ni(S3kmWv(F@
zJ;6w$J66<P?gH9nVcYgyt>w|Z4hLNpU&cK-Sayr*Za`IOoxL>SeuUl#l-_=Xc3Uop
z`&vhVZ)XVnFAezrRt7%LvZ&v@vHPa17y;8@(_&$k&H}IN-+qEh|5k`Ga<YPWJNDxq
zM6hy})$Dk;e&4TtlLeO{_^g_3md5<eXn)R{!{|Zc-r!04M_m5jdgDK;cSHc}9;=GP
WK796->Vtp}0H^`Al&cl3!u|(e$>VJR

literal 0
HcmV?d00001

diff --git a/doc/assistant/xmpppairingend.png b/doc/assistant/xmpppairingend.png
new file mode 100644
index 0000000000000000000000000000000000000000..f0c9e765d1dacb737ade9ad68ddcc6a2bb8e149e
GIT binary patch
literal 34379
zcmaf41ymi&mc6)3aM$4O?gS^eySux)TM~jh1a}DT?(XjH?l3p+{Xc*HtUqgDv2N2{
zU0rqV={o1^y(>cgt2hEI4lDowK#-IWRRjP)B>(`BKxk0lnV$!x4Zsf=dkGCE000j4
z&mRaNH606h63SUp_6yW192|g#W`?bI3;-YkNQw$6yDy)%`N?Z7C0xAJ1?&*wHPE?C
zD?a>AUJbv^mRwFP5%bZL--qa*%O#&5MM#Y#e!yn7DWbZR4LZR&Mwg%KR1Tmalc41_
zDnfg7>14pj@XS^Eo*|rRTfAXK^`<GK63nB<%ONEzZ>#CJOmfbD9Y<QVLHHbie1IqU
zYL4sWGpv$Wf3M+HUbnD*a_WP4a2hE}LIfR16h08LwhI~vJVe12LIxL-HzWm~g_g1g
z|MOo&4DdpBuNd$U`RC%F3;(GZ8T+3L|93OW>Q8@q`@5O@BbskTxx;xclxjyY_ewb!
z@JhAO5_*K_^;Z}wER1N_ZwHi{w=|W#0`NL*%_-bz1}%H2!25Yj`&^p~IPyewgB{s!
z5zxyjaP@1Xl6$u3ifgg!wfO()N7cIW^8&ZTE+j!Rlsr6q1FlpF&-5{UAQBkBSYJvh
z|6Ja1tWfP(Ey*7qP7KZ$L>)9Qz9b0x5zy(c0CtMA=PuxmSOzN}_z-Xa*c$6c7@knC
zCqEABgaW~c7HbrqE}FI54BF&kB$1U+CnigTBK(FD1#u}2=%n=j!Rto`9q0~<qIGdQ
z=dM}Hg|RQL2`Dnb@?mMO9SAY?)K+q8M@9~kg3OcDQRG10sF2x!-1TrK@PY7GB(plP
z<lHcUapH8^D^bsg-Lf_FE9}8E0_3%;FEGK1VOL_O9{rA;fK19(>sp*MJ+Bc>1Z<A(
zm5w%>>_YBV?q?YLsD_?*vA_8D;rh2?-N}X}^yl2dVvB(Y_MYJ~@w86Kqg@+f{r=LN
z$WB?R)J;|fs0nv@&g~)_j53%+KhbO^mfPp`b#TZX*@A`Y24t&ts;d>SW=eh*IMRa&
zByuIkZSoM!N`G(`^B98$fG47m`KC3w7$X9*0gp@h`A1is0JC|v3=qa7@?ZlLJ+K@y
zU;ELzUy*jEk#pZ&?&Zdk03ZMYwcpaF#oQi{g1u$}Oq{r2fKiB%R-FU0Bvm9mx%O*f
zWkTsg3ju)^Wyn!d*g})@++p&C)ZS>&hRKc96Ddm7(8Jad)Y40YdmYLE?f58k62rGQ
z3QwIW*6NBw1;2%2xcI9wUL$NQ=ia1oYX2;RutM6KAnlI&bD8<SW<iPDyq4t@1pI}x
z;kybX`Lf-eutY4P0Ab%~>VA9JY2G?%n3jNy5!0omyu|L2<726u8ymz{Cl^x^zwktk
z50iqb>cvY)32$?zbP%{)fPnRxST8#J-gse_D<lVB5FV?6`*U<^3RavMTS!iu)p7dp
zBw{COh>sx&0}XTU@<9K#hO7?HB%2R?#p@oUH=<SRdpIfb$0ReqIty=PuH#^=W^1#y
z?;lSJRJFcpkw8&f1Y|ER{%Gu+XY!7O8gK%^-`VNXg9HQ{X@J+KmzAoT7SGHZPLAYM
z%+$$%2{Km8bd?D(@wm;ZTJC*YP;+e(W7q$g?9J4SOT*?!d2&}CD+JKh6YMUsNMgt_
zZqrS3{W-S7k~usP>0HgOW(cxmvMaTzn)cXl0jL@qwTuBEhrp|YW~Xu+loikFSnF%l
z(Kh`^cuydL-iDE~F6F?$sHU7!VOM28LTQP|S-)V*a(y(Mr+iF@IG!6Wb8#kf1ms_j
zT5zO~3Z|l9_!o$_Gl_=}VT$A#gA^se^duQ7ib4DkFvCNaNj$Lq(!8jA&$fWXsP59p
z;5!9R$+OJv*MupUL`v<XJ&&Qst}^_S0;=n$@!LP1-!>z1g+vPm5p?^@m@RF9FG7}0
zu=@T-BBeFrQt*&&02CI+YCm3=^(7@gL*BNO6kfs{tWfn0rE~*P>S&Em;q6;$agzlS
zD2sHm+n258)>(`*HdnpDXBr{oUeuq9x7!?J8hl-kVX0dR<$)LF<!i2Rk;dV4Ae+J<
zs>Kns&jN%4SDyq(<*X{yiHq~N>(Kz6A+KeMY1}0e1?$o1RMl<qYx)TQq;;q&{m32k
z-EepnC*ro@iL5k7I&d*fKy*`J|M_W$>5r>kjHAjw%N$L$<hN$#Ic4hyp4L(U(baEu
zBR>nL4+EVL0q2rVE=J{6-q$w{=}xQKYw8y%IB|Y-GpZ8G^D6W11yJ!)?4INUN_%P5
z!deO}ULME*ql>w@xzJYn5r1)A___j6vu6M&&k9(VK4V~P4vtP!4f&LK#BYi>E68Gj
zi8z7kFMrK^Cw|e`BsAXx%74HA3R$@?%qrJu2H+X{aIdqJNHw9ZCcu0EZWt7sy~czk
zuMF6l=yJfQ>^{emSmRgHSs+qqYR_5TN$vY#HTg-GPs+5&t_Wxg1lhUTObyzm<^oU?
zC9tl?h%d?tR+dp}Ri!uwrd}Yd4POggsYhb>Z>=Dmp1gr?z#>%y-Ahjq4$m^AmkP9J
z5Uh)=c#v2>yz|f}826u+#4uq_=6hAn5P4sZtg$n)l0|=}shzAeQ`5z;J*hjmgPDSw
z;~e5*SCJlu%BW0D>(5r9geBD+;-9g{Vdd$*c(Vo?npBTZPUX^>I5h|hmXXuDu43JB
zA0!1*8s=0KacRu`lH4smkAHT3a-Teh4g&*Z%NIxY+bT)YckCZ=c*<i7A;-ab@Ot!S
zwB`sgJn2V%AsQ9x&t-jbi3p1p8sdft1g)LdP(uMBymC^AohnifjiH^Lt?yM+P^)ZD
zn2W^Qtt7sCOej^W4D~01N(=}c8j{9C-tD^5$1X~a9`G`*78a&O0(ZCP#e$?3+l-in
z>qJ2UFhk~hyr<@EI7TA?<F~j~U*b->3h2)&s}AOF6mSUB@^}U2nI&{+@NPU!Zt9=S
zQU{{j$3KtlP3TpP6Bq(e<oBI8;monNUKnaMiHQ?GVWz1w818iJA94(vfeW1u_THOs
zPu07d@&qK?b>;<9cuYy_tW1ll0+RsVfZZGZdT|uQ!<2|o*(T&`;{F_UjbFv)=2LSC
z)+4B_x*mJZuRU|6B0LMQf29#|+{8qKVBJZT^*?Odl5d+d{yVK8a)oReg7{Zr@SpOB
z2s$K^&DGBNHR%-3ogqY%k-Lo}M2}tsOzXX=hbL5Abfg73!|NxA%k^}$ZxvPe&rw6(
zKZGeSdiQI!<Q8t9Pf@k<yN-71Gq$L8AMq`UIqI!bMCvs+d#<C+pG0DURUQh8-JaDi
zdYqLJ?;1F$-9NtK`xGZH5ugUI5u{>U5ghWef0v$=Qd^9*MYnPo82ybzR=spuvALz0
zwpOQtlT43z1}&Fy!3vjX_k^qEx=N$p%S)>IZcl3PRf11I=@l72LHeypT(Vl6qF<4z
zR+b#PxvkbG*b0|jn>XoS9Tx&SCa%8v4k71%a%g@H?#@r*nt3jpE_kI&^wXgPY#nYL
zj<z83*4~U@(Bq3q#d~kSL%;(_x;&~cpfrJHe$%QwaxkKykKuF2vvvRx=Y!?Yb9uz=
z^Y%R~G$zj%bo=b&IpIB+LONp$Y4wzJh)55yY~CNYp_lykmY*e5#^s~s%oDKbyzAw4
z^9V|350-fht3RXP<2r_C8-;i&mDN5Pb9LOaurDboR%cM^4d%#`^v^ddc;Av4l8;=X
zDXLgH{~99}2HA`fl`Hm9v4@k@O95RFty4FbM4F~cRj4hY=Jq=my!L{wSujycz;%`?
z8b+{PkV%jvwdcM$tEflp*>xxCMn6&!GSU-&U0X`uIIdc3C58Z$^O{?;)GQY~8uGp`
z?`0b4*x-u~i0_MNPfcnyJEx=wIKbIDRrXAPet{hO(e4G1fdPoN-e>x{$&;BG-Q7_~
z^||a1&)t$Mj(qg0ed5YV$sD>83{NUv($`57s^D4Lu+)p(zI8~eP*iiHzB!}+bfIxF
z=uM>f%P<hZCc*KI3dU;z4ihVU-1o$taTNV10mR6TV|%6|d5&a{Z=iX(Ij(@JAnAl>
z{;U|9Dn3q-X~H<s$=A#;ZlrP(B#2vkZUI5H#aD}biGd_xfvP{}*GKZxXdg(`P(f2)
zChC4{lwHjaxusG0O1nmpVd6lkiZ^PEdtBE+&jHxb6m>Hff)h&%rsz0^KqQWO^G`bi
z6eOEHF|w&BMjNJR@!@B)0OjhfP{bhRoaAL;+n-oI4j<CW$Vw{C&Y$a4s;ZmC>NZ1l
zX%iRcaXqCwOrKFul1qp%G`rWD5m+o$Rc37L%xPF2wE1iK?81C^QPS47nCFo|8F6A_
zukNX5itk)ZjTpUVRf6#Q;H?qu26?BQ#gMWGP>e0Z5H!iK7EgWM<W8CzQl~L@GAZ5F
zB5W^}pPIuyo4y(oR*x1fN84}%;@KJ8))jp$p*xdJyj54!W(s4j7~@tB4C%Y>e2+_$
z)8~cc_AY-akhyt?@R7zJI5Q%;wZt~dV1}Uy&zN-NDGS(3^>lA(o-%X99?MBCw&*^3
zjuObu={JOS?KZL)W5@Bx%V<?Q%Au{67{cl7Cr-IU$jYa*f=7Cg=dGGnbE46);i~`&
z%Fe4iepT2hTWg7x)npr{w~t$7lvzs2%-g;wi!OAUdbv7>dKPmWo1EcStE0fZAn+Ks
z8A0^Ol+~K%VIe6i>mFXZi?o5=MW*WZK(r0u9<wdzG1}G__8P8OVmny0SWO&iuggyi
zK2B2h!hV^<aLnsHOhdg=QB~;^8%Q?!%oGOL|HQMY-jTzhb|Yn}#o+Udg2ov}n?tr(
zzQUAes={XC^;5jV#G1Z7sDb20!rHr605{y#ynC}d0Vf(f&%1YG5CX#nAqKJ>1uzR~
z1N6rC{e;jhL^{+6yU@dE@3BTfRF@&Je7{utainO+{AgVN{=o<K36(5RKo|uhZ@%g<
zh~S+1(s_-9)@O1vNmboF>p83#m1o$jb};`$kX}OX)mg*IK@dSR+G5FiD$@(kEk#7@
z*@gu~R!K`5)pphDX&hoRXzKW+KTiHrYb_uk>RFKsP;}y~GvIa7`|{<FVG-{7zwcL<
zghFF+b!yn07i`s+b<q~M(zlU@>Mz<Y5}&Z4!Lvk+TUt*hRZXf<#UW;MoZakuNzvAq
zXKr5pt`GjAk}zF(kx2Pd-m48aUp(vf@@KLuxOmtaDqhBX??!ErZJD(WM_8}cCu?cX
z#)yza{RZ2IXlhF@$9HAc)P2*!%<$fQ*HJ*pJ8H3(m9p)Cj7o-};SBjkhX#pR?vU_U
zu1mjR1_BLNyTmDIxEK{q>yZFmpT0#s6FitdRNz!kgrgw6Sv<F~-&Ry|dVLp5#*VH>
zOI~2zd>wW+9~GTAsod{`inipoCTKaXD%P=pT-B(bQB<MU!`5Qi!KKpi1Bt^a`HN!I
zaMT4#%os6K2Ut@$EtqTbMg7Ur3#5c$yWv1XM2LJ&XPDBsdU#_#;kVOes$Pr*B^&Ci
zN&HUzQ=W%`!_+PH@i*z=1ZB32W$6&hw_oC6>gIdQ1@+!y=(T)oe#cU7_ak4fC9Dy{
z3SA!q#S(t=4swlBlpKS*l0JRQQm_PEe*c0tgu>Hzw&OkH?&2ZI1Q)86TxzG`mo17{
z{!}bs&^$R-HN1NURt#6zw<!$FQ5(Mr+(@x4J~p$I;^j^2EfpeMa+k8qu4@Q*?(IVI
z(wN%OcPk<8lE6_xMQYL=$DBgb)WQVhq76L`f|4>obQa<!sF{4~JH|a8Ew95IrlH+0
ze(pLND@xH?fb07qv1k_~@@v=H#cVG-`B7b$52F<+TJ^WQ_Sx%d<CFpASEh*&tSv6^
z6+%st7LygmJlN&fLC|fTj>e!1JfU;9FW1C={!{E0>U>d;9oz`GwDZ@(J{QS&BE7NU
zGiEHME}^}q&dT$JHP{+%D#p>Z%ODWK_c2sDswxz2cPCHSd;)n@4bLwWsM3Ruc^m6d
zgYd$x1B2?Ce#MxlZ=31ROL(NH8hhzBb@t=FbQh=cnqczfh|6DSIL%_EB9~}Lv_}Ji
zEHflEwW_bRk(J5)0t_=X=on@=9`Q)SIX|U1$iXKb;r@D7`&E-{sDk4ms$yVE2weoP
za%7gO@lK*5cy`)GiXv@j(7_dEjMOxC`yPsp8fD`WGQ`IO7{_+JzvZAvCsn7+sSn4k
zZ5D16Zl8%QSw)r@Bi=#P;+)%OzWjoTzQUW=uYgzKEZ1w(pfRuzxoqLLnsE|2cBa8P
zw_uhTG&|SA_kQ;v_B_mEs#(6-Eu`Y&rnjx=@@2)|>f={*!<Ph4B`*=K6C2z5xONk8
z#TMkSz7@S2C9SmTg|csKD_u7r`8maWQ=&#%N^+IjCN6#IO(oU1nZezmu>r0l!Iq;0
z@uef0+?#b0BSLS2H-o{$hI)o7p|M@T?`J(@XFGk+>0Y%`!VR-(3SJ?>m3$`j4@nJV
z_~tTPz(rbtMifme=o|ABEZU8X=hG0oQAd-ysf)iscj|LHVw-4HgbIdIG>FVyK{1G&
z^hzo+pU*1$Z6Yvy1<#Go|H()&?$aCwH4#EGvb4<b6A^=2(NQDL`s<tD3Fci_KbZmt
z61!W3Mv11TWqd!#{wx~A`0~3}?5okr(70~e@Nr}{tcnlRYNGYb)RuM6S(UN*9-~Bq
zwb+>A`l7@1s!45zeedq^bv>fHWi3L!c#^grYxAH;`+3GVFY>lRjce1(FioX)o9Em_
z5STLjbfxyQhdr+{?N32)=*vkad#4DR>S82N3zs!HJmk%;N-L6g6ibXrMi|-cJviP(
z_d%?m%$L`bOd7kt7UUMP<XXNG6=^-I33>Ge7hXC}RwFxSC)Wq=p+pj=<pXVWD<kHy
z3I?Bz;lbtZ=?ApUjsJq}d5svo9&Zm()R4wp;yEx>{eT9Bs?Tlh!8f(8iHira)Z|zz
zS0I!<I2SM&uqAYSUJ`Nq5k$ZxbbdrKOJqApfh4%MfT8R9E+=7xXsraB&5FzYgCq~}
zCK_JeF^a8jOs!J)J7OAs)}kYYkEdrNFLx^P(nB+*jX3UrA{Z4CCkN)`Z#V9d76#U%
z1T<?N9LF7z+o7fXukqh$iWxx^D#vWE2-`WG9mBZG?Qx9>e2vR^WbzCPCs&W@O4kNS
z{d9S3k%ClMW7v6H%f!0GY`x*VbFEKo*?5$VVzH9HH5cTycpfxcpQu^Kjpw=y&}C&A
zxAL;WFCyR%0&pPVAy&r2Rv+zsP&Ps#vQ3FLhQ6*m|BX)~ee#^5{8x4HZ=mDfwZ(tH
zHi`bN*?)jQtLf1AOCm!$p}N3;h#}Z`2Bqm;oS6VG38bx9%tTjk1{P$T&ml^0-ax;u
zR!;y@;6W!K8kBNrySUSB-5}*Yv~wVvR%}2^O|Iiw>a{Ru;P$LJE;xYK@A+^Fp|tvp
z-1=*qc#+voaqKmo5HB+gd*(yd!&mM5$4`-gRDqg^BKf($D!|HIOP!BTQ!?ZF1xogF
z`|vwgciwf^n#2X6e4Q*u`Ie9QS~GP}n^yyC3r#ke_`i^bXCy6RSZC;vI!OcM!HYh@
zO@t;D6m*O0oE3_Nby)_hy1-+xO>e~D2^g8EGinln@&kU&ZLJQKg(hx!rbL5G@>rmx
z9=~pKRZ$DVtV3mL@qN<m_=s2dQ32KgpbeNR|C-}1sP1Hd(G>;)U}ntM(1G@a`KEhR
zaU(fj&u%ncg6rgMVhiq#yy>J>W(Efq!9T3l7Q<yA%NqI@mP(E!^4ZH(_R!JxWcM-s
zvYD>o3Z(&#_EAFdz*)SU<}(n0*4Rh*kU1IDh6gC4xAi1w&J%7IdW}K1(1$4)a@ig8
zC#65HwtuSa!A1B&%n&N1^~=g4s0Ifxkyl%Q2?SJ6u+ClY-MGD(AQ_LNT=4Vse->JK
zD$zA-K>?I?+AK@u(2nB|nsQRUo;+IH!+4@c>)7nmOB=%g#<kmr86{vOGcXI2ew|Ft
z&)K(+pzPZNtB9ZbU-eiU!9AGZn+<iOId-|3l7jy?tV_fTaT67Vs)MM;i3|y-1MP2S
z&cBk`M;m&Ye>TRFiE!3RW1?7#39U#x6{<3K)1;*rc*Ob*i*<}NQu-q5)Zvb0d>gJV
zd46m&3R9e?j@=BkatelF2e>wz<-k|P33Fr>Z8n<`d2p7svz)@_U^lR^-61ncl5%6+
zY@$udc^Ml4pklh$KRGjEDG^j0V&(RV$s3NOz?AYq0*b7yPv>g^B~sWfZX@~>U@A>o
z<?Li`TF+@-I?`7RCgI~Pyw$K9`WqoAgKY5ei}J9+iN+akN;hPJ0RI8>vmY8IUo%sB
zwq`SxEO9A}kf^t7v#`=*Xjm|5Z(K97WLcp?Kdoa(Ge|B35aKz}6{FOG9b5=ZokSK`
zoJSJexn(pn!iY7k6aN8@KhsNsT-HiU&+G(%jF(w)*S23ro9It|(z7lG__E_=){G)K
zzAZPiB@B2z7w%8{Fe|!TM>}ibvQuo=av+V1sjYD)+7$2etXZc-flxvwFI`UeZm!yo
zDq5amNIfeWe5;GQR<SesDuEwDcKbUkONSb4|5L~evzvlRyp?Pd7Rg$zQ_9MZl<JHZ
zcgdxEmgEAyr0QU?4z=PbuuW39q#!21F*T{ICHVJ&vv-0G@7JJW$Ge|ZnxurjwMNI<
zbMiWdFD9mjy!=w=q4yQVPShei06Db#hzMtkDJ;CQVjysw!7G>LJPLZ4q06Uqo<Sh>
z(ahgR{ZHUH2Al9-7&Dr`k2NhnScw%>bHPL(dJA6YgaJD5>gl(fB2Z3k7G6(heO6ub
z>M>YV0taxEm(raeww^pn>af$IzO*I`XGT!|q3Uw)v6QOi9n|*W$#pgt`XWB6Gy0cc
zwsw66yCZ&XcMwiInv$wfG&t39Ciq`+zpfSS;(c&tGfz{w3mJcdg@f#<ipPfTF4h|U
zZ4r~nq-+U@&K()bqnkzm;7h+0{$Iw3q)TtT%~!2h@|<S0Dv@pRzCyyk^DM_3_Vg(=
zLiYcIBx@?wmiJ{RiRctsr9k@YqXBL$YVJt1v}@mcm8TW7iW5Y1^_KQ<mXhD-C{9Y^
zqnOfY9N5?X9d!;F58?@xyV`W8&o=VreH?LM=o2N^9`q*zloX@(r%J8$K_;q<V3Fr(
zYUTOMIoi=MIPta%mK3r&R^6fN&_@MVT4#z*)GJ#`??(H2h8uK-E06QR_X6jw1f2Ks
zntHM1%uJd!Unw!yeVMxT!FiE$%P>O0(g;T3h!Hmofc}9Npwg5RoX-_Q#D42$4euWQ
z)f}3ZtUxQ~hwMaPSN^Dlx*7?TJhj=i3Q>X~8yPJ?Hp08-{$#GyE4rB0u!2w@z^`#0
zrN^rg7W&{dR*2u8%+{=_5nYpKbCcu+;>?xHJYZsTWulZX<Kf8Y0Yi5buV|39yQr$W
z|BL(cy7;oSt<0T%L^?=ze7cAe5*QQEo8x^_bIeNa%Km&!X>Q8RI^;@wrzRt>D2?CZ
zR7%=vK>%W4XCf$~nGxj@1(9?RAfmz`P0TJUSV+E~WQLxVF(>?@A9+WuHND8MC|0%W
zBXhZ{gr!FFXmwhO29>S<g3tLB1c`lkJU6I(I!rBXmxDS-QTBBd8tED8zIer~VLDz(
z#@g77ri;p5t-6Y;&od4#i$9e#r0|>6lvGy;$MUs!i07~5(-=g}p-=e_oH$zkzQQdu
zPIy*Koq{Im=q;GS+1K6yc+*>{=;*aFZr94)#wlAw&O-8)UO>u!RvJhI1=b;1Dwd>C
z@5Z{yb}92;n0pfe_Bnvk*<Y#1$+S&hLg^xC-JRl7CtKZWaLZ6OyIueo(U&HlODV8E
z<XL!2R4&`<>QK7({sYn;$f0XpQ?5NWv=kF@+*hK`3hf_7TXT(Kugi$s#Kj-Sh<ujE
zJGWw-b^RBlpRfKsk2vjg2_X(MXo}V5ic>o?Ujj`~BVTBIGFS{*P?sYv`B>H;zVoq>
zV*4EAU>9>->sg$hA!iNs<m&S|kQJHl6=<Xw3+LpE-;cf?%bPx&PEB@*scgAbEQ|cO
zs6!-T-octUT8^$K$sq<J^*zP+_bXN{ycC)}Z##i^@h#fs)b+Ko?{kDC=XVJi8D~ZV
zxZ<&OC*227BL_cFBAr;dD(f9t#mjY0`i<oxGM5ffd31aiBzoQMon_S~8d}EdGcn83
z`QU5r6xxq%YUDC@OhwZ(i$!TnmLu^HmeeQ2yv;tPERDJ|VgDAqveq9uas*+-u^{|G
zbS-E7j8c&6gDf8$u+x^gU<n!9Amg>&Kvim~rHQgr(w>7;BLxVGy|k(W!%)Kl7>7QG
z9+xXFtE(ZQfnYg<>y_f;!5L?+B;p?L5PBAZj@1RRkNfB5mKoxvqNKXXLg<!an-g4)
zg2on+7+Rv1G0?E|3b1m-y2Ub}6Mh{P<s0x?P^&M+DeS)Nom}N!TTX7A%Re>OiX}go
zQ;prnlEJo}l{k@CvjZOn+{TTvH|S-8@mA*+DJ%w;{bTWu_p!X9)-A=a`fR((P*Gtu
zIQ8w-Q&lzbaNvHVat_hfw3QOOh$b4apX6_-lAtO%gDte%h7Ob6(rhg3)5U%i^`w0>
zg&c`BSVwL2C8_uqYZHRvaIV|$6<)(=&$F8;=*WaVZV~aQdgnXcpu33yZrUfd+TJ21
zZY{9`3i3~T`*Y9r6;jeWsWU5y1-O!Z!T;0(l+2T{AJ>Du=FZy}w3HNb;US0v{13Vq
zg=Ga%7rg&B1@UQp+v3z5_f&=W5P^D@4Icpqn`M$r{PU&)tTl;C)@;MbK#;3ACmsM0
zB4xtrnkMDQ%B7`+%S6!=bEXs8HSa6R1>l`vIXOR>p-M@-%K22wf^#Wq#EZ6k?J1&F
zr!BwrFM}<!PI55oi%%k?l;q}j6&X0Oey+?cKjUXHsV6zrqc%+XnHm$D1kP44EHr`U
ze=S9716*z*V|c++zyf(W3G}n|gR@G0mh>>oGg%SHZhc(`|JJ<2mG{{S0+?ZLALQcY
zDOAJbY7`a62qfk{9?vx>!h*YB`lklqUG|}4*pWc|lk6ZLaZ1MsV1&Ysn%-R?BVZQ0
zl~npC`SJ89+FU-CymQb6LJcX^ITCabvR8JV0|G)IXu1G*O!Ns-<AqZ1j(tB^?FSN7
zyXT!HG_<2Wc9}r@cXr@(Vjf77gB5VG7)r+-GVSn_At!m5%Ng={-e3%Y)npFK%o5)J
zpiUNdJNJkHb6a_sp<fjWQJUg27hQj>r=x!FJen_VqKupiZ4l!rqJc3C()u0;O<)sc
zR*xF~1j$S7j)Ei_&|IG%;rY}3bc^fUd8`u!xdU%uc3zmDI2>4CaUcKYtBG<_sxTkq
zAl#8Jqn%b}{e4&>eJBj}oq^{fMuN9z6jOz$U#OtMx>Q;R@iR2Zc<gFqG%9EyFOlz3
z5K#?@1H_3!|3J_Iv5~ygfg|`8=id?w^$A-?kpHI=S^<2wz6jh}&HZ2>HH{s^_XTNn
zlXY5IuE@UB)_nDDtqy_o<$qs|(0zUdJIyh#QvtpCaWe?nnJ0kCFBuUdVjTK#r!GF)
zx&i-{wJn3+R_je|Chgs&=Qy+CXw4Ov7x$+^amUH_%0A*P>$pH)OpHvAxnJMx-d3-}
z=kdq+zVaHGdKv1Ugd8}l9&GS0*d%nGI<gz}u{(FoyBqPe>@$&0P{i5uSLT~_qay&A
zI*%O>Bk^PY$Qt;|Uf?Wd`f_Fu)>G9yXWDI(o6a62%wEECcXEZs3eu{|&k8iTHZ1tL
zoQWSWWVN=YCqVqJ%QKy_j0Cm~e%IA8Rqb^<5pNKAQ~EG9WT;w;V_HXW)Yn;MZldFM
z*tgfUji6^h83Oz%HzT)$O~wW0o7$T*b>14@X^=rKATA(C6wN5pF<-kqWrK%BBm<%>
z*xE`R6=}Y%L#;#E2f}&lefE?(D-Fc;C$QaOE6oOHvgxW^;@E7ndO&>?rD>f&hYobA
z{7z(TG2LS|i+W=gTK|dzp{lYCF`HOIHLKl!FL6x+Bw;Z0bsggSJY~yx3E-y-*M&hy
zv*qeHB~^CX1kKB#zkk)hq~2yC`fQ-WBuC%YghQc7AeJda$rU^A?k=>uz$;97z(2MS
z>B2<hemWlmv86$uG&tnvi+lkZQOqnJa3UTfDguX_CGdq}u3W2nX>4bvYx{Q+7ezQo
zVPQ9>3yY)8cqPi->-alCl3o`Wq)TH-C2pDPTCDyAkgDk&nYFH}7$aK9ka2E&D04C9
zN2XF_>I$uwYI;WljN7@WTd#iu^;acet;g1|LG}N4;)dJ)e~~tl{ROf>mZBNkQ`)b&
zz>RVz=Yj;K_csLc)}-Eym#Jg2f@LS2>%4PD3IUW>w>Sp3l~+q4!^6TYqE6fL|D<qA
zlt-td%cFxm4d1m3>B4@z8||}TLUoesRdmzcr!%@~d&ld%*ptVaiCSHEkC`;m+|}7}
z7Me{w;GI~W@TZ#A=vG{OyKFM|=(V~ya)VNVWmjD&!hjLn@*kR|2-`e*byd>}GjQZZ
z-io{}$*!&hb8HhWgbp3H=)yw&{!Q`J&sX)gof@Z=T>-c7Y>%WPLbvq}WgDilbz@G?
zw<BHp4&>o{xtls+M#y=>mO3M1r$ncFt$`qe3W-X1EU%Uvw3u{+QKUc}A~qGN{?OT?
zPp4L0-QN3h5t1$=D7X_>Im`S(FuDiZ)2C&*t?6(R0dt~lUlWGZbt`TIDu<g?()zaL
zf6qEAgCy59_w0XfZl8+gE)U8a-lEErI=>F}6eFKF`k`<_Ifs-!U1i^h(J~s7_pAi)
zq!lV~UCdSq3>Z6id-$E{RSM%z0lTh}i_5Dr4(jjI%baJ)Qhx-HS#DkRkiIL<iIz=k
zN>%&pO4Ro`+yYK;oEgL=#BIKq!?M+OfYw;IK}2nB_l^_v*pX|bSBvStDV^w_`GH#4
zhVN*zi8Bja<?$-AK37I-_r>8A0Xh$ZLWu$DvS}KPO<bSuSey7JCQ%_8EU$%=noN{8
zh_{@oubD;$%jzo&<Z!`8NnJaMzlnYUB^Sxk4m4wjtQFT`TT~eB+`kMRC6zV1Madw+
zq7GytA}7{iS_!AKvKu$Kv5&+HVm#pl)vt?g{JmCZ=1gx_WM=Gb&RU2qNE_^UG~->4
z935~sV0)%M*m*jojNod8B@@ddlIRdIxYYSdv<QKsl<#aUfk(6WP2WKGrm*){vq?mZ
zK}vxlV3RFB%G&}4tbwJdavGdd_IhdCgEwaG7!h83HVMeQ=oFrCuWL0_jQ=QW9bPJ7
z!YRE)Z)e5isKa7)1WaN}Thc~!|HbBjT!6V}e6PgTOHf)cpCsQn;M__l#M+a><^aTe
zzp%+H<xgnxfgL*7ij+j2VgH(+GrgBSi@W9MJ`C?dAEpDeyW_Yj&aslqZyD2>z{LGM
zIUyU|;~3I0BNc>CjE?@b%d4_IHi3qHmcXhSmvn4*`sa`#KPF9sS76=@4jCNaxPMqR
z$^YUrD0v26P$98~tj%P7EL7TOo-ZWI%!Y#96I6YR>0V0RJx`DZ^A6yh$1sR;R?_Oq
zDpWqt=Ln+!tFM$!hyQKL6Ls~NbTJ>VGk?)tYkgnjQ_zUPq*#OqBM4j++EJ_bpP9-H
z)-=os?TScfX8tj4Oh#0piXOsJ#pxQ6FtZl8yfa+q2@O2d>Q*{wAj`en%JIC6Z6^OB
zaVU2T6%1KFuhg-wV1<Hof^{8kA(+!s3dyW+&Luq0kb-T#o;S(sH53=RmId9k90ZE2
zDPm@U(~XT}1uh@|jQ(PD%O&=^|NKh>TM3h8LN^7OA)C`tdknF8P4YzFaGpPNlj&4=
zGWjP)Twrvs(TqrsFg-y#k{@zN{)INu#&LsCf^aLrt&shB2~N|LltnP~cbQLWB|2As
zXMJpl^6t-lWUeRIe0@v_*@PwVNc?}ej@db>2^`AGy!_`KQn=_=GytK7;CC5)0imPH
z(-}zjj5%z}i!#DC5)&1(7tRe<T^(J;(ZDT?{bQ|Z76;81*qIR9P!)0pXomgDrYdj?
z8#c#Kg@hGxTI-arG*DUvwQ=cY%6r8U%k+Mc=2{!_X13*R^1230a&t&urJ*q@sOEgM
zy|pjDm$#T{mMw^S)g~VZUpdn6PH^Zmf8B9}A>iLN`-ubaHf9=o>ed}5t?GLlH9pHb
z!|!N{&Qsazdg(NG$^-!yq4dhymyTtsDmNlV=UPoQNb~U=MF^lDTsU6kC0|?+4tW~Q
z^2qmxXTOJ9PTwt;U!wY7gvtB@*NWv<`kUtZQqFJ4>>n7Mm<e~q)?)KI=-4}Du7UyI
zbh6h<xSLA#CMFJ_utVDBHUv@{_DN7`EVV3Hqq#u$R1yHgrPKp>HwlnIf<*M1U0e;r
zS%%B17Q3HRLYjPtvYC|=$R{R(ZC6pssFr>Djv>4RI4OkL2L^jp$8rr-!xKt}5kR~c
zNLZkk@OMztV3P5I2AH@)!|^{APME5mz)$NAV^EheeH&r?bT$?f&j;;<Eq)9e?_~%`
zXW2bHvdbKFfkcKOF6KvX-(qY*2Zm(tQ`hK_--Fo7Co)R~1F!o~UG$5ByJmOE`XYfL
z9%EU#q-0?NUpEFL>Cg-~vrwbCvx4TWRnx6m?$e@7RH3lQ%Ze{fke9!g5}FgF$ZMQR
zmkm!cQBqRe)#chW*7+&+ujER#6}RQ2-?4M7h;J~P&e~bA+^3?~nDV&uXS1@_;no&=
za_$5bfg9M&xRTP`CW#}esT~58RSxOn@G2^1%`~U@S6BIUqdS{8N_%P1MMr@aWA-mz
zXJy;8u+VB7q;TI!)R(Q^hsOsyON5zA<|9{2s&nqN`t)$NRVMUf?!a&_#)g8&%Z9p?
zrk`5*4&NS5n;sbnOTp)J;DFjX(~KnqCSplR%S*IIpf+>WjFF&sGT!*IcvF*3Hl`y?
zw|2jRk(Q1hk`>Q6bS<@rxOix=w}?cp9K;SgCQYxQ{#o@32Zn#Hqo0QsvtzUdDaFQ<
zP!*hGI(3MV$gX-<C^+0rn!p$GxtReQ5j&G7xLkyGbLW6C=By;umZs5@>Q6+SK_Ii+
zju`H=<vz0Zq3O4kz65wk=x`>Ajj^B1lfXcE-39vuQ)K664{n8-U{31BzFd3KxC@R*
zXryi@sOdJP;!Oj?)XcmUhnogz5<_ML&4{?SxD}mRCG4w?rI_r|{&dFXUXD>PACY-%
z@X#MW8rY~92gQNZMdZ$bMuo>Z%0{=QUx)K0SmkDOy!s&uA1<k0nXFG};?kneu!|L}
zF`!U_X^hOyvVn|psua;U)(2aSC2<jGg99hn9ob4kQTdNKlNpLk8U-T2VC=K`!D2)n
z)k8$YxF23d)#t?+0oj@%KhmW!2;Q@d@#}Lq*=JGnrBO4muu`59HVrEjltN6T0E(8l
z;GM+R*Ip$F`o$d92G0>oj%$hXh1iuIeRSD81dAP|HP@0KL&fCZZJ_R)_FyhZyBf&^
zP=6b)6uWzvUoRni75E0iDswNuJKDA%FGG(@x`G2aE52*?w;KG4Q-lErsMq^<GUea&
zT>n!~{-2utf7Hx&1jz!2`G_&IBL=XrxqAFupPx_m_wk{K*7yHMMfOL<{-2)u4^8|3
zH#lAew0+&Xt{|uu*RySp_x>2%k&%%wM0{@NLu8L{z`hs1N6=-?@jq?`WqrIJbUcmO
zamLcn(C|3!O32E_2%dSZrdC3<C^SM*E-GY3Y_0R18c>M>heR;ZTW_^c@v!0dakrqi
zQD?P~BNDdj_;h!&fQf-2oFgwSEiJa!@iG*1TS*4N$k%Zqkq_#1e}UG~>Sl8U)v@h+
zCHI#s-xaG#*Qmwk<vz`>9VWY~>T*s^@9iqiPg`ETs;0(qZ#ZG&{k{P^VJ*VXYjtr4
z(#gW)!Oiz!vur2MYF=bSfmR%ZU!lqy_kmNN%%-c?;K|nTt-%`?ka)4Bi`LjsU-zQk
z9<xVTMO)^1-*d68i#FmmjfCCiyMiykZgeO4M;S;!Q!nw^@$LDpyStlX-95-;X>V_@
zxVZTJ{T(<(I(mBFrx86}zrl(22Q$DqXnmZ~Ozb8Szb+R9pz&oWi@pul<Aof6#}$4-
zz}5HwC->ntP)PXpe*bOj2(#T8xpQUV-T7WE%jd-ET20Ti{U#oF;&kP%hZJhO{q3lZ
z=doXiRn5=fBByZsY4YXcb%LX!aurn9$M@ko=|rx*Tr;9u(uFiZd(GoXoOtEc!bNs)
zS8>uq;%h$2;+va5)7Dol&*^5Mqii$DSi|?6ZghOqPVjpjWVlgNQ!7)?G5B6Z$?-q!
zzQ4T~hT#brmfvh&o6U5#1&V6Pc0_A8f%${D>NM4zoIRZDy|PQq%C%j+tf+xbxf{M%
zY{uf6`v$COHLf6Rjt6Zr2xRCO_%HG_5YV=_-S+so!*+UgyzgGT(RAACFC=V~N537T
z&ggw;G$T%j>AetUdEbB$EFz!<>eaWoJ$&$877M!!#_(N*WZ-&H{=<##Z)fB>Zl|Tc
z7CJdPUf-Xs=zTmdY`E{l?CqJP$lT9W`l?)hn@y;<0#uy<wMR_vcf<IA$D|G_MP4_1
zq#nFpTLAgpyPvOH1D*Q=8lbGvj`m_{0Pn54#Is>m56|nVQx42+{b_C>$+qGZ8E_e7
z<p%J6NSh#7)nj}f!8QAk*GHMsyS%K>+klk6kxe;j0@bqjcy1d+@_k!EQVH|DZxeVK
zm-9{2bVdQbtZ@d0G?bJ@m6acdd2zlEEgL$`&K8!ImL?|ojg5~l8z1kO9gknSM1G9m
z6S!ZN+fl#YG2Hi!s7w&R`+A>1U5Lh=N6i<xc068VDyVBKhF9`+eDrKMHM~2&%%8n*
z_+OM{NhPu0J6=V-<Sd-dyjtE-r@V}V0l<#=px_*Kd!6JWP8hs79{`;(Zg#Qcm91?)
zq>!5ujv21O7=L!Y#90}FU9LJ!yd8=QGy`9smy3=LuZMF?UH6>k=4WZWXT?_rkoko;
z1~=c!^(<4cPcvfz_@dj1gHe7jw|*~|onapv8B<zWvAS_}Yp+HV0%&0FcMMtFZ(iqT
zADgyozJSdZ28=>!FNY6X04%W&k|8!FZy;qA9CG`W;<h~p7Ez9$eTXnnLAxCxX^lj{
z%W1zUX!F-k$tBPQTioC_G*i^iTb(y~0wgxV++-Qn`ZC)9y1i{5FIF@LvH@rNUA8Y2
ziD?gB06+o58DC7`NC3}+e<9-eTYtc*-^2YZ|Nacm>s=>B<Xa1_-%tV`?W=(e%(qvO
zW^2EYd$g7VrStU;?^^jQZKf)?#gIU@m~{ldnukt;QvtyMVc;5!Mb6%3lA^AvC2JQ3
zt2|ND700#GAufYH0m5nZVSK;erbQF6*1>n$zS|Aw$>v3757$`=bp0qPaoumSFWr70
z=VyF^$d9;Rwk0XK*2m1BOA9yLFOWW7&(A71U9|%$U!MX<=e&0IL6O>@Zsf8+{(G^5
zU%4$C<dbO0x}4R+2fe@5@$=t92e@l^m~04f+>aYFWcqp@YDFrKsj<neft`bF_!x8~
z|GupR`)E?X>#pU1y@!Ik=es$G46yrLQPcMkOn<V)=hxKmdNQ%G=++s-cOLk5!S^xB
z@y_kgCSU1;0rA4$t;_L(_5}vGD*(|@?K8@fV~*Vh*z|d8BV6MJh`%q=c4^L+%{&vp
zqZF~!G-9jE%eY_jWA$;0;YI_x;q*LQmJXypCY*!(A@WfVh_+UL4EiaRIw>*zJwY~g
zFB}><(COsd4Ofsy8r=>GFX(&(s(6i++n%*Q-5~%2UNs0T;U~U|H-n~;s}!%0sgAPj
zvOk-$P9M=%==5E&z5K7cdtJ%?V1B2Yf6F1XK-+}U{*P^0)=Gvuttn)$&nS8XbWZ03
zU4B$F*KFcd@21|@?vL?6uXB>N<|{{CHPj^E!QhE=HTikl5WBa2d6c?7(CPE1@xiTw
z*0ptK2O0k-Gzs8iBV^OBsT+E}KkvJ6nSwO*B&Zr5AgKXwSvA^fZ;DAZYUV`yuy3Df
z{nrg>A}aYkb<InA$qs0xH24H&CB6JR%vjX%8zh@;n{9&2ghPD|^d23Z739LDC(-T@
zz6Lt@y5=`CaF<sQr0#_7gq<*Thu?WI03D_@3~kH@iI&1YX+iJo!2lOd5P_SkR;PQI
zqP*YE>Fv6WB+aB?&^YJeXe*p%n_c^cAzHhFZVEg?QIAdji0G-Rk65p{z7B<W13Kv%
z_mgmNa1R2R_;;Z?#W7liRMn`V0OJ>@*5_R8Qy$jc9?jU=+ud3d)fM3{WlzC-w^tE$
zEWb9^mu&061kDQuyjwqjr*0^gN!M?zEFEMfs(tM(W|$flJ<76nu<YT^GxsxhNcjc^
zR{6#@F<CTu?>cmjc}*c3zWG{DIIs+`MDUJo0U7?)#7BCoR$~4dd*H^mZlN+5rW)Aj
z3-0@d<)mCrpH)*nfi%uZuY2#C&7&Puv$zKFRkILLud_-vH-a=yuWpp9%roA3bOsF6
z#`zglEhnpk>WFb8)OpnMbUW)g1*>H?>7>dB$O)E=a@Q=jcT>K{eoyWdd|m_wU~010
z+Yi|D3|iR(Y`StqqJ_n9n|$A{T44d}JgKp|3w2Md(x6p}OpJs(pk_!<Q*6)}BXxku
zq#Uh4x!Wwd+HU%7vFy{{Hc))RmdXmygyQS->FJL;=#I(bBb{=FP{%OP$ynh}pmyLX
zNOX3gg?kC_E3qua!Y{|-<0!UF<FXqvzv_6+I^gulnBi{nEc2nxwbDoRKyXZiDWYku
z{R+@+Fv4K2Tmk7kaR8s)b4>hXB^+G_y3-Qdzhw(3h!WYOIN64}=aEVP%lq?OgdUy!
zkrT2w4YAYZ_F=dKDM;}bn^S9A1$uJE3<Bv%EgtJe`*HiL^cDMpS~KdsqTjAiEu)A>
z*LUmsScfgmFBILYff-s=4~yN;_lTjPn7|<6Xb2{6QDncE0l;%j>M}O;r;Z=my989N
z=p+pJNR;wSu4h*!=4r;>b7zd<N=O!2u_pg4l4^gC*Zcjz@c<bUWG0h;RYRuXkx*Ml
zZFn|wBb$eh4LiGlQ_gPYX!NZ?GvlsK41hZR#15u5)>w+|mh?T%aje{~I%l2J;vq23
zF2+$ct)+OqYQ9-2$qB=MWQ&Srw(rc5%ZvsA@`${5jf{*jHW38C7d35+Vs0r(xoSfT
zBMQ;G%-5wG->iukk5V9})L)qb%H_6A2*@^Q+>t?7>U%E1y1+Iv=9l%=Y{?I>-V0o3
zOk_@tZ%bUi*<ZhDj&JK%9JT@`e0bOH%^kX0%vj%VqHN{-ahVQ5W|fb%#GaqNxv}@U
zS|warN;CZ&Mvd3}gXNS<O;RqjPB+)iv12C4QlG+q?U!DLoN$iy+B=Jdo!4A2^}pZ6
zfsoRO67D#xOFEPxt|Tp+Jds{<k4iMf?O_DC6JhbSwtva^QEeX0KM+2@*mhVi#wJ$o
zI5w)KQ!K#8417T|;qF}0JS_*fIXk@QIcLk0Y=z-10u0T6RG@l2xuJa<i5E*S_4wj`
ztU8p_a0_6Kn#YcEVK3W#B;jvxg&65;oig}FhzsW50Pl#S30zA3d;396o?%xW8*^8Y
zvlOKF<nbzMV&amHXjCcMNw5hu^mp?CK=o^+aj_or_|}}6*j|o=o!rT#IgFAaxW4i;
z&C72PT{D-^Wu6o9%Jk96E@d?Vw)NE<x`waODaVlUbks7K&DiXj8c(-y`bTv09J47}
zRt!JY)JK)>f@V%wVDqRO;?x(JGgJ}lWy}b<CW?kpSz6ptQK+P(Hv6f>j6ob8=uMl1
zNL@;ew`FpD((Q06=^3a@yX@hd?&xrpg?e${BYee7M57;MZ%<M~&7D7iU&#+%43W+y
zgu=*88nYHiMHi&PsAV@hx_Fh#Y-~D36K#tc_wzBS7uX@kyDIiLt5Kob1o532g}a0N
zyE;~&w}`<(be3hmVnirGK`+(3y5#Hm@xl#@r>~fS-Q9y6EW29%cX4I({rdp_VR^FO
z^Tn(<{dfV_B~kz&Y-1GrG+S>FE4xe2h=AQ;4skGA4Tly+vxeFhK1yU<8@m!xQU*I)
z8{y}$pIgJ9FgDm+N@A2ghe(NBV@G5T-q!VG^QN>FdtOjq5&xznG@kX^!u>qr@Ym9%
zn!^x76^ru&8^T{m4<{bKT!Myc$@KSQOl5|B>-;IUMv1^u;&34Lid#hG+8mkp+U61g
zPiLNQwukopvV&JCc4(|nmr7nvg~eokk+r!*enCBZ9@pfhX6->8YK3Z&(E2ppA_*9f
z{jXre!8s0@aSh>*?3qL72B@GnQv$)3V<+2fdtFeaJDTONv=y+*j7y0|%8dTl_<gP&
zD+;_Z9pYr}c{N=cdz*(kgogV8pemAwi6{<RE^(orm7|4h1)U!A5^~}pt!+8cw(UnT
zwE=6)+M6kZJHe43*H>Wn)%5M*W$~4lRVMKVG*D~`ur$3}j!x6k;WqZ(10jUMhXedA
zISpU)Mh1DsW2K#D*s&M%he9gCqWq!>zFC*nQuciWb0Yi<vVic1L!&e5$;uCm<oBhC
zAgJHbKciH)-lC$pM_HH!hv?>K+4b5yzsO|kKREo+yAIh-M>Npn$c1vaca8{+kT<7E
zyHb*#WB&=HWYuTN|E3Y;S%|G2%OEFJQ#1h0)lFO57VvgB{M^U%XMbhVqV9{U8CF?t
zj_;syP2Pn_!!uXuQck41k-qS8WbC;m-&z1Lxwrx+XJ<fyoMd!|e{ZG+2loKTvt<7Q
z=08`#<bSrFZ^H!WvPuDykpCM+_`f%=|GmfE9c5?-VHuccFV<OMPTX+VuBz+m@;e_+
z0t@oNAYgLV8!KadRd(M6Mfm!9An-9}=iB3;t)a2>om3oHw}{4Rw8td8P%g%Fzs0o@
zs#bX;(IClJ!G(DF2aaZ40z%;BML&rE2b}!5UZ*9cU|i~-S^(F!kN20#j`!yZofaUX
z@HuIuQm>=EstOr4L{n2UIJWU)gFY0)gSSWjmGHycro_Fs5#MLUrRV-C=n@tU;_>{Z
zrCs5P_Wl&Yf6vRV<Lye$&+lU$w*8Lvy>u&z)80QY6lfp?@&zmF2D=U4n=uX$Gz^UP
z=i^d=_p3NKSXfn6)e7yV>y?dnSD&{&0a1o4`#k;B0Yk>-=N>-9k%oZ3N`Ia!wB&oP
zFYtds1-@g|M<3HaC=)LXxgz&?I^SGuKt>+y8DLjYS<6SR1}<LTyYdsd-8!{3m+l@q
zye|D3-?2W93NPNTcsg1H+7#^}AT~N8KF%8@|29h5BFXnbAm{-H2M4TK5fV+3l9CDw
z3Z7qHDs@`wffeB%gCAGk``$?w$YWaN(8kkcT>Z%^)tnOGoPOhDT+Wua)=q6=<mGw2
zr47^lZ7@J9tIzkcYpo3ei_`Hk``7~DCh#<q??!63(W|q0DCFJneAE_(2>RHPwJKq^
zjrq|F3Q)zU^x=KBdVj|M$!I>0)^?ed1p%vM^L9BHP;2Msd4|~TfIK#*x9D|P46h<?
zw+eOHe6&=FN7;N!_?qxQV%F4F2@3E<HuYZ{^LrU3fK1F{&~5hk2t#B3Q%{N;8ey4!
zyuW4n+%NH5v??hm<R}&cAq73}>miDViw(>Y-;Zg(RR~w4R_{%}r_25Pk47)phk!LN
zIJXv%RgcRpFE;^AD&Qz}vV3|k+5<q#%2uzvU90ac0J0bBEsjodycTUvR!?mygYIWS
z0NYc^vI%7AI_ERLRo2(Y4k!Tp<05YR;^=!?GbVa*ePG9{vug;5;l-+F)#Lp%(g!h1
zbxt-i&B*f!;fXG<yJ(x8YB{Z>r^)FeOBSfOYUAZVI>chnd0sd%aA$h&kPFTAQDK(v
zQGOBuuR9|b*OT4Hz1_{tja}<i|ApVji%1xv&t0kBSP>rL#{0K{h0KiyVdCMejgKi<
zj1Oel%FBc#^bd1)4F5Forv=ok%2lb|!TOKf$E7QV*VC3TU5;UZ%!Vg2!^hIY`>EN+
zOYMRlJ!tmxP2o<6Pe;2C(xg>F{DznAM-57+fSy)usfYAiU-iz!$JjywfPPI|!%lN-
zWC9Q}M@WxLzlP^?^Fa2lKjdimp`;d08uI6Be=OKxzdt)-;uZO)3&O&}9-o{DJRjz5
zyq&ux(d(q9rfO<vP|?%Bzdv+*^fCA{<<*=$n*n4>)*1)qid@Hl%y^~W{PpUw4JH`F
zDVKWHOHA*94;0*`*zy*`dMnrSefdM<sFk7k{pLAE*82mJt<gq%lsIBP+{V`Ve>L_M
zP;G7PwxJX&S}3js3dJez&{Eu;;_mJc+}+(<ihF_J?(Xhh+=Iglr}vI`&bj}6<7H%I
zBpEw9S(0z9Ilno-4UGddZT*3^t-Y9k3$U^pCbc`<-oU;VET7N6O*j<-d3o4c_g9TB
zK0H`3at(TbM_WT9mf_PP3*<4EbiB9io>m}i2Zna`(n}mvC1(SS@?I}Rd0ytwsFXE9
zVoIa)iRXF%c2RM0>t!xO_cJ<4>Bi$;8zBIs?Ewat^EE<vw@YGYbsPQ~0owVh26@`~
zxOv&h#VoD$jRwq;`c3`Y71LhI&+i@vSNSeB)VeW)p@c%K=?11*>b=+j0d?PjZx1-%
zLAV;X6H>6+(`KPWq>c)S5f{4k8GQxQZS!vVl4{H4VE5fMhX~b+FeSM6LnW`v=~|l)
zbj@G4VzI-g$K}S^L*qdHdfq|kxvTfd2Hy?^pFD5k7DE{->RB8DfPn00YgD2p=j;2E
zC1~$O0&o?`xig7ls!8KP8+ECjR|gew4cF-e`S=+4O!U;FP3V3yTf6bWwSFz%+T#H{
zyq#%%2wayq1laGQ+dzl#EMIvAU|W|y6vsTmRvn--4l1-kRt_HF5X+-qw4a5Qp>4XK
zalKo|`_#0gd6EpaR;`;a)`w}HMztOf($Vp8V0ri-2h+kJj0kB-SEP1>ZDow*8(L_1
z&(pnCk5j5xXQ5QB*r=BKpp%;$yH#RiC_r9P=ExvS5(=T+>dn@X^GVaqafT3}O(j!i
zN#}g!yC3mN=tH>^eI~WiXvMovFVTWS{kf!1!V6H5FVsmi?|0Lhh#l&~3*ztcT7~|}
zMjXKZyvhFV;~c+w#R&}q|MhY?KeW+vf`?4*{*Yc2J}}l<bmOXZuK4-x;u>6Ob=X{c
z;{9|m+WLg;dp_$W#dsN!ugJi2Po;3!ld04Gl>el0#vp=TXj^bTrZCEnK|6Q-7QB(d
zfJAWnN(c$E^pTB}iIV@SL0@fw1Kjb7TEefuEL{WE`ZBx9MZhI98j${S#=Z7F{{pB3
zh5NN3283`?MgIIyXg*j6#RL6Q8#ox9a>km`*j8ic-r$@6=Jd;Zl)Og=#5xcXK%2_n
zcO&3s4VV0@<jfh`_t_c9fc*cKn~4(C+iYj>zVN+%^}Tc|z~0(pIAR(b1cYk3{_Z%1
z1#0=QGN<gr9T2~c+70a+;W?7ZQ>iJ#qZ|@(L6>gL2h>}GAoUS_G7!eqTVvD;)=^kK
z&B?}XR*b8tMYduM6QdH>?2Eas&b?eZOAo}R%Jt*5$Ee9QG2E8@iP3R^&$YYUEJQV`
zq`{-Sm9~h+i@mf1P}^-Vlil_W<A|X1m`&)GZrqE+0;XDI)=h|A+)}=F1pKzla?a*#
zNpSCHsinuo%AAdJ`Uwlaw4bq6h6KM1^e#xxgvYG%D_WMbURnx{$Z)?sg`p<GC9R~m
z2FJG|(?jOQfk`u=wq9o{=FF)N%0#bDhMh9;%d0AmFZo-@8lr37^DfQ*v|aO9^8irB
zk1w}~UdAt|)KH7`rQayOKY^>Y8fCmv=y@t_dw)QVSWW-KQbRh>^x(~`n_vgp=j*`O
zD{OnUtXzpTk1_$YbZ#l5NUL||EOah2HyXd#KSU1CsctTD;$_<G75RAjc<8UtRM);I
zXKQ@6*T6QaOVZYtYY0r|R;XPfb=oA8U{prX3+vmgVV$Jcw$9*c_J?XXs4keK(4RXw
zJh8pS<k680D!yxIH_II$(*nx0au>+|WnAu?lbn)!F*idOTZ&_4)kF@#kqS{$%#A5i
z&1S`#{C1E!d0t&<>;*Y4-?nJa&p4qUb-lOG+o~3HWK?9<%fp0LJnS}EZ5PGx@4&qP
zkZG~#(bHz6iQ|a2F#muG^Ai0^w*M~nt!#rnb$%Wrnr4(ix;&M*tLy^ykMYn+d^0x*
z%+mO3MR{Asx4W70V&XfMdtG6%9?v8~XO-;4p50EK#5g@W8)~hyccqV;T1!)zEpAH6
zsdbokT(8~|6|nEe`g)*i=#P6!aAhnzrnHdvnc@O<r_8vIZLNE{@Af1DeI?3TacdUB
z5i?D`lwh-bnyf<>|Ew1rzlDA@G1HUOi^Vg}p<r^G+-;_aCq2MQ^ff1(47};Ojv4QZ
z?2U5<tI=Yk0V7Zzo>G#x<RCf~fj*5P_+;=VU*-ns2zIbAkGk_?F$;sMTj}sf<)Cqy
zMyV0oMKATOgG^M<_8X%fqOV3?>I@gZer%>>a>A)UbyVCw-;8Lazh13wWdZfJY*%Z#
zN9>+U-!kcKZ)i`u^~Y(wTY2q(p&7}H$egYQXAAskemN8i=T0VJ5#hjnD3O%lK8y=A
zr;%WyL)fUIvKTi|E8Pm^8>MFMZ349I+QBILX@XDyVJl;ila{zybd!9$cIA7$jXhVU
zZF^v7ANgFZB<_M*=d4e!JI_AV8oRMA^1U@dr;yomdF{KHGt%;HT@hCZ-!S)fxy&$P
z+JF_HdK%DeUpAsJDRfVVuQ|Hwq`6gHlGo-N5m=~D`a#B0U81wT=qULYtIa7)hi!i2
zbGR(mS9!Y_Cr<OAJmp1WEGaxgMgn4ch9)y_4Sjk%LxQ)c9gVE}1nHO-fF6xcWx$>S
z6+gdGVuT3fW;ZcVMM4qV@SI<--%i*hby*<e0M+mZnNZyh*4oPF!^_Yr1f7xXehMPL
z$<0+!xDVH7b__IJnR_WGYYWI$-Hl`8{F!@b=L{4`&9_RW;i~mFDpgvtPIfs9pwop=
zorwTJAJ&f@-@U(A@i*ZGo2e%R^eClN)`EVKPsWn)rFA4O56^kggWIor3L}Q{*{nZu
zxyqTyzw(~Z!{J@8Fo@O4TW-Zm)0`-D1&o1fP+>ID11wqDs(xB;jgNoV!al4AKYh-T
zMgYJn=+8cJa0+eb4wqX<kAzBTz<ZB$5kTW-<iBB0z43b<G_SnGy)xTtyE<;oW!(?r
zsq`#-9~&E1J@_q6vD&EwX-_f_<+~;C1(bH)842Eb<W@i}752&sZd#^<cPaFcj-F<w
zU5I><+UT-4&UXBrihfm?S`9it(PJl~rkmOrLqLa>tBPNFa+Z%a!3D-%C1djz1q@DJ
zg0?4YMz9eVxV-!F$UL*(E#A|bdL{2^w-|BMo&eMCucK2lZ-M~(5IFL*HlWs6xjVxI
zo>5l5ttJl!s?Fgk4(qw6sjzRC=`+DamhD#U{$fc5Gwh|tYuG&tR%-y?$ewsfPZe^C
z<x*wawnp)lhgoUsJWa=>|2UtBHLZhnC+IcYccPt^=R+~9HW=lKHEw>a#Y@n5Ga*R5
zpxvW(FqQIFMwOGmWV0Eo`0ZVsU4#-RDW=vk$a#KSb5Sm=q-7(bVp~atSeP@HN}#^g
z*~nyrrYB#(aYeORa${YYa5VMjjt1AHTU#mne68S0{D@*vLAYxF%RCqes;$!GILh?L
zL9p!VJ=&=}=1hBens?MuYIs;$S`u3S8ST2P0(XJ#pdF@NZ&ah&kl(GUiJ|!bleV&(
zDh*K4g|&}~xiH?=#nD>~6>M97(uvyRTk1EN#4M*Q_s#T*`ob01gXE3rqL`D&M2U|T
zWn)GNNSsR~l%MzfW-hfadSAykfV7fub1FJ|m;h;AP2r%v!CdDZZ$@bZG7pEXd5&>~
z<nEiIVw9Yw30QJaG;RxF8BW#@R8zFgXlb5L3R0@1cIJ`0zxQf5f*M9^LG|fjyb2Pv
zxT8h067{G1@dWv%SB;wPRiDdWuUecoj@qUwXT&ykhd1XYC~>mGZ-5Kd%lb04+A$O@
zGw|EM1YMZqiQT8kC)I+JNy~z!SZ=e>R^-ajswl%UtccCqi>#$R1*<+?OdC($B6lKc
z3vBi#p6DCm?uHh6*&V3$TkjH*W|nm2U@2dNXe$g8ygo8j+N7zGBhU`LUl-9cT;83+
z3$La9HnLD9NN;QSWmMV1%=%p_Q$+1ypRo9+va^&MSrI+y%R4B{4bS=!rXoy>MMT?N
zw<9}oCAy>Ux02^KO+;SZH(NQTtU`7nyP1PD1PgS}ue&h2JfN;0=r}#sbb_Q)#;Q4k
zD0A@iMKHY5&Pwc>71NiT;%w>BERRg!#umo;u;(n;@vJ%Ztt}1v^FBN-rPW=lSVRz5
zC{R-F)-vu}qdfwM6%MYJXD$fmxkaVbq%cNc1K0tPi{n?}i~i?F9y4)dC|N!Dk{8rc
zQONH@PLS?O5<@<%IFnX%numjyoZQEs<Rx5%>QQ1RN|fU|3+0h++Eo=T4~f~tT)na@
ze_)Bts9O#SY6WwDlFIj3BIo>x*Z*q<EQwOL%S!JRJBwqfu#H!YqB1_nb}%&7<?DMZ
zZ`RJUv^Wq12m4T!Bsmc&QD}vqiHiefA-UT(CsZ;^QdltN-XplWZNU_!sVP;)S8goM
z8s;;9P8KXYgPm-WpET|@1LITVSlZ38mZx0gCoJrI#_uRABDAJ*jD{ZK-RbV1{%js)
zAg)L_nz%nJ(cOP!fkEG>&b5dH;95XRTBgf5>Yy_|q${J{tM1yvXxWo^l@TAZm`@)g
zI>q7*wTL7JYcpo^@eYd<>MJgXz#yhOFUc$soE{QS_9hyZZuDI!^`r<C%aOIOf0rK+
zEmTXKdf-Hsny%{couN+jsi?fZ5S<Xu^TP#1ViUm_96&7|q(}ytDRhD4e!es|rPY;r
zHki%fjKN5FMEj4Gu+lTOVn9+Pi)Zs>$huqjj`r8EsWVPKU~0oj<+^RUSfwa^_(#{^
zkaXejdiW1&0){toBkdKdocmH5EiS@VQ4OgsiAL5bSMs)YVRwDQnhChTLC8wVK2Sp9
zTh|y6Q3rD_lhH-Ee%KZ~PtFEP@ll-Hbrw>im(FU6G7>=w8J}K{Nl?DO_53V_D}i>s
zr%Y~(Uo8uNOlwx`(T6)W1T(R=u|S{Je9@Ac(aOKR3RS+Jb>smk#xtb-tYY!i&?IWx
zDti9@RrWUcS+>oCnOheYWz2T%qdtP~o4+bUE}>jz%e@qO{PR*)_pd^c)PD*^2K-eh
zvg5Bpk&1r`MgIM;VCuqkYoV1U*Q&Cz$WP!E;K|YPG4;Dp%1oCH`?o)b^nbXlYel_C
zh|KaA_zM#X%~~I}8IlqcSKKd#A@UL4$ID6KoN)uD{z%;e9a4^#4*l{IY@9hZRdj+j
z)9CByh{;iYRGquTr@7ms@R#!(Z(yoxYA(OXHmtqw7lA-v6yM$NO8s64)3gZT$sj+W
z8KRenb=2GFvLQt<gg#74^uE7mD5B_yaos&PV@iCjg6fBNv`jZJauz<1U;Ez0?@62s
zf`%Ty&6R1lKKT(p=r}uH{~pir@bGxS-s}+Fj{}#--b8NeU2*H(c~Yy!6h9FHOdQ~y
z=m+48V8q>HerWLbLskNHI1U>wZyzCW6zXg5Ztsq;{2!FPyC)}=bR-C;Yt?;^LRabZ
z7M~@3RiGl!TSDIMwwaJ1WJ8USWT=I8@8q%N#bIy_;uh+N&L=kSgaMG!=~em&5qDxk
zTVWDk_hR1w(GuZFe3@m<AX1B^<qq)E{mJtVduw5Nxz~1rN(+PzAmp^$I-IY1Av#vw
z4oaO@T=T0dV3ME#Y7MaLi4-c(K9ainNMxEQT5|jxA6?Qv+u&3?hj4!yt!K^bTyr5V
zuLbC+x3tA`S0n$_9qV8*+s2auNIP?$D;=JkgxIbI&o<V_`HMqUeOok1d3BRcpSH|%
zq7i=FmhChDX^0hzzs}s%iZA*#o?67_W~mxIRmX1F;p?Q)Zf-5QW|V|VWYMo9$hWV!
zN&V)>bSg%@&0nt_*aFZ{BniQ;IpgFkZ&dHprZOf0IQqB>rEGD=dQ|N;J8vvCUmCpK
z;RK;=$wVR#kB>utBunQL0}m@9gKuJOjoNm6Y_)gGkEQ{QSMo^cA#vO`5ZK)Vh}^7z
zB1wtl?5wPQwP(;#|4xeSXSM(rRYTL}E**eEV|?1g2#%p1D?*51_i$H=V{S$QYCJu!
zbi4lZH3c9WxBs`Hj6<OFfg~usEGDLV*nt^sIXG8eI_hY8qXSgefRa7RXEJUNXzO&5
z$3B^573UR~7y&tE0bNYtWC5z`QjwYVj_Ikw>ufs^Iw_kwwVr-SwC9xqKK3+U?#hs@
zM$c4N*MyNc;*^5cOB0!<SB{^j6lC@s8k(D%PuzF8`5*UWAY3W<e2}5_YDQfois*4b
zrA2;<^DRQJ{1^ztZU=ejo(L9s<MdXEaukP<8Ne1hhHMn2qF*@FxMRAw6+2z2vzN9H
zg%+O6d=!~$+B@NJoek?<G@NSczyJ%yaxE1>-@L%Yfvhv4o=r3VDHUjL$oy?zjWz{V
zXX4~UKJ>j75^E)zO7+FJ84#y7yukhMsk6chfrE~~F8jD;L@2;f=VK0HB53`IW$o<l
zg8T4yX=hkfPFT78Uv0XgVT;_<azE>SQ7+AvY2L3~w>YnN!1T;PD0s;GLJ`6WQ=C<(
z^Yk`of=92gH9Pn1+DZ=k94kNvE+{@jm1k=ler)>}(sg9qIstkxL>9pLBa|=GI~B$!
zJxjs4fbg^{aTK?>vc-sq48^C9B3WZy#;f9k+<jzFALZ)SzqzsJq+6zOn*wGcg^AGU
zvtpW*jPxmyN%*$U$+&r%hz3s>tyuTt<KrOY#P!dL<tEpQV(rKMt*tFoubWN?p_RsN
z&3AuTC7g41yPL&uL;zp*3cfC}qb%0|WH{^|x@~nJyPI({{Xs}aPtVE{&KuSQz=pb_
zvp6zdNLWyU0#sP%`;LwvQ24cJDw*N~oIrnngL3&;Ufg)8O}1FYnog&}otEggMW*SP
zkTn<R4gj3!bDu88a6Jb(B28&ocmm{ib!E_5I66AATd%n9q!?$q?xdjd-2emx1qC5N
zYUkSWmKQ_)yU7~?L8OJpgBTN*1aXUi1SzFQX;({1<ZSDK5;QV}NGX7*fA+h?jGT7D
z>Z_WxDc#`tMpAqhy281h25U)crt*6a03J&zYe3uBN=*aHwyj&wEl$3ry-T=-vA&%{
z4#na==J4Luj#FPZ4SsrOQUYGY(ZlVJO5~!%sgXcO)zYzAC;|@piwuGnDJSkbkfdd!
z?Pd>Tm@^@4xa8o<%F23YP*_7LEYr0hI1O0U81Ur!ybx>7ipHp<GB=hjM2$z_^g%Yt
zjc#H*1|yPLrA!*e8F1)=B?I(+^ymN|w+|}#k!4Di8Z+5LO|S5(D!{wBajW>5oA<9F
zc0wV)GCkD3HoY&Zm14Yx<;@X{`-~#`ijIyqS8x#s%OHb1A_c<=ZwG)gS#0n>qZok5
zu!2YPDxf$V3f7F`CW>HnT#*IB=I1C5Pd?f8fNF9Rwpo(_?;do%-OZUezShY6s6X7y
z3k!p7!%%Woq>*Lvy&*0`YJ93AZ?-XI$>+=DggM`QVPdTI9g_qGYH!K%-lyCzKEsLx
zS3G#g!<v>eD27)cWHqFNvlN52q*vx>k~49E6P1tO6g<-UKkg@71v*tJeYAdAl;voq
zpTtV{5yEu5eMTQ8@sQxd)&S5^(eQwjR7z(goeU`NNNDemg3v)dk9?f|O$@sroLKKy
zeb2|GqDJF`q&R4XXt*3G)MabVv(s~lF=)Cv-jUol+%&o3wK%az1aOw~Rxi`)QU0$r
zeS_JbNF9>K`urajf0BZVmnzTySp0d$0;Kjo(W6pZAku2Mr`w-exwvTy$&4hcGoR~<
zBl(i>sRWe%hMKunNC=&p;cww#XXHHZa38lFX`iHYcV6ll7%!d<Yt$Jk<@9`}fPFdp
zK$UIlosCu3H-+aI-CC23Pg?FZzd3fZZ#OOp+3hx^fwt`7^{l<@Cb*DHw>K69JGXV{
z=#pH(HK?|O6|E*wQ!Hte-H>6hU>B)rm`?_ThYp5j{Kj#*WczJ!-|Lz1#&G3oo(L4I
zaiG4xX42<eq#mndfVUvDAVeF~!1oQvrSIOjSGF7k%1wwUd+KJD48ILt|FxcQDj@)`
z19Ra>5~pN|3F$H8{upi&!SE8va2PUbSezPe!cFl1n>)GnI%0ndj*{}%!$WSJG-p1)
z^At;2y8>(s>O%;kbgF9iAw5=VWJ=1whyHicS*N%Q$cYM4+sM%6{2m=i(!_`L+mZPU
zgglT6DoJD)lIfM$!lmF%t!pC|x$<?rX64URa{z&*H=Kk%@TgPxj$-Y62xXN&e;Pf?
zpP5Qzv5kJTZreueRRUZNB=?(bTs;bDiGry@8XU4-P6XN{x;D}%$!al(Mq!AC&l<ic
z)}%@w;NWX<n0D3Ed)Pp_@rdd=iow7Dhb5sETfB5Zr|g_Ny@~+qoZ$hW;y3aU$8zG?
zd;y5A2}GLgur8~E9BT7X=l3CMIqZ)G<qz7Y=_ciagj0)+qd30nH_404yficzZDUhr
z_d`F#a*zTy^^XHokQx6k{Xz}#$L6y)WR4!yZxiqK9hH{mk-(<<_bYG_`K-+p*xM*q
zK%F*f4&oK}n*l1;5W{vgGV((MhU%Bh@6O6>J@9NA9tB7y`F28Wmzjl|@d(_XL`^Jy
zPfPr1dMv}NF)Iv~1&d^c*|uRPqRvKJ`H`IQYKaZ?Cda6LuMWa3HcS}ZB=b8}NjzGf
zs7WPNAxJ!9eD`l+25{5^UK{Y$`NCMSU{U=V+EdWj%f_&DS@q$y^of~;k=SZqPL5zR
z{oG*R>*&AHE1DHhWA@%d(Awky25vjo49^wG|IObhB+)E#wEp7cq+zpt58%SEN3w9p
zq$c{U9WhM5H^l=mxnBtKoo{buX5&o)sKX_<cQx>Qy!!G>=B?qK>Rq^-WBn=C-E{H=
zji5|zKlh!lPUS0twx*SY%>LP;>QD$9ulv!WpCvVZelVBfLlUH_v~i=&0x!ZR^o8K4
z#bNzrd$yOSQj1~4KQdn7U6-$4YH+3iN)(KRd33jJvLmk5N`!yQ%$TW`{sw<I4T#l*
z=8N0}Fp?z3x=5NpSeW}<1!4{9eNgit{mDY4n!%N%^xn}`f1<+e>A-D5>7`VY#0QI@
z#|T(^9)dYJgfAG{xk`}Wf-0yh*zEfO#9@d5;Vr&2liIIrv6On&hFP=yPFPDr_Ppkl
zo=oM=+OcIMupms=lBNK}aZT`*MKSp~f8gVpU<Pg*lm;&2?knwFI7N<XV0~ij=cd9-
z#u>eQy9sw46^;Z{ZOyN$sq}%Pw6eTJN{nn8=F{jtRqn9Z`*w*mcUih}%UNYu<W>wp
z7<~3-O*HaIm=DkZ7R2TQD0XxjQQDxL{M3LINnm3?2X-*XsT$hk$RrEV0)!utOIl;O
zGxk8<m2fjK*VX3knqnNJu`$3teEIy}S^)pd(z&UXk1TMz$CeCT38ejYU#zlrP{Nov
z-d7m<&=o%j#)Je+@TDs2Pn`(p;o5q&F=v^tic<Bk@?j9~iw=co@n?To(%uSiCsur)
zZ|6dzhmHr0aP-Um(oRwzJ=JVXlz)Z-e#56h&z$NG%6dn-BTjkJzv}ZkviGKw1Mep2
z&`94n&1QaiV%`WaHf~gRXtig7Egk^=Mu(x_bn;av2*L!+<6~_Z{4lm_<1M$njce*L
z8PpQ1Mjk~%0^*^0T-8Ln_y775-D>~Qb&2%qxLu-nddsHh9keGSmJ<Gbkd(Y<27&Dj
z%Zg5_im96gykTpfS=9)V6z#`khFq+n&gN2g7o9eKV1N8cfJT=4?YV~<b)d>f`4SW=
z4&9@|@h$i>qIOshWO2B?PI}o11NYHGz9wi2erTN?SU!vf{6Hee-hR_kg%ASgaUK;G
z4E+ffW-Puogo4sO?0tXs+8Ztr9MyGaQA7W}ZwcJ=ydRHfU&+D3ns5}zjW7_6*}{i0
zp2E$9zF>L}L}ZOhY&(zhm_r4;-HDfpxta+eC3WD5uQ8!z9)!%tYt6qvaPU3x-N6&&
z^=r&OS3>v?IQTDs{9kM2e>&{%IQqX1>(cxlxLXO?XZ}yn>`VHhx#futpi`KB@m0{%
z(KX-hq(QdLz`MQt2;rQ5^0V;ajoy#;;x>5RnUj#f^m)nA%!O$2Ux0W#M+76J3$op6
zY;4qa+spltnV;pw_ni9+>Zrl3-6$wFvsCisvzkSZkw<q|2mCkfs7}t#oRJ3y2QNGH
zUfZPze0F-xhRYG|lXs3QeNX1|0)w!reuc2TYIldpRoNJeuMqu&03fdnZ2G1teKbL|
zPWc_i3dagY*>lAc`N|X;QAkd}f{-?r^8FWF0Z0UmmOE13f++5v(^enyT3VhUcC6cp
zq!x#*zL+ZG(HFOX$3bcBitBC$gV*g~t{{QLWQv~-`CEdcmZlW08g1i^mbc~3_LK+-
zuZ*fd<4iE8`edJNnRT)bmGSPNEEu>o6+Ro9*FJ`Sm$f0av+Bd1dy6|12<ztotD%ou
z8Ls<tu$^Wf4h|-Y86L$COm9oM!&%#7k3(>>d4)9q{jwQc#$1H#RwD^G?Jjnt<las0
zIY6ie5n_+(+FCdWDWGB(>@B;qN@5RPpi*PBP@A~xwv?6>rz&`{ZQzkbiFeirRXtyV
zFUye;relkxZ7T`GzF#A(?iDi!frKWel*#fXxtKY{g$ed$=X#td_-$rPy!%LSlc73q
zFh+9Us~E7B!v9=zaHT?c2}4l<M}_&B6MGI2j$`$9#M$$1GD{2MRN79`_Js6PBoXgj
zLb<z;UEdykFXX=J%-OOH|Kszbd9C5Xa@c3Uu!lm9L^%ja8anwR5a7UOSLy+-A^&2J
zGW**A>Gv;gqyfE3$b~Ds!Q+LS3cEft0mzQ7m7I$I1d&wYuOJ;06k=9O${7hf>&Eta
zJkZvL{0iXe{Yn6&fU-WsFXaY#pA|1+D;l{P0Kh?0$o*ltX!ZLLz@|q9*feU6^;`LQ
z;H0llsjg{(<>8#YT>0*G_9v8U#C`e7zu~g}WwUR>7O>`xk-KPp1o)_tkgHP!kLv3-
zx?b$4wBAkk_xBS&od%hko4>#y@Vs$^@a9DTyTDG|eI#8)rmCX@w?_L#26(AaoE(sg
ze)jNQyn^1+feIGj*Pw)wVb|eG;k$_p4^5EGz`*90n#4!(r<Y61%8qx2(?)qNhL|A_
z5G5GE#KZ*RVHtgBk%El)p>#G%yAny_2#DQ8O};Y1aW#3xK<oM*z+&=CyVa6`JIS~5
zZs*v6cEh1GbJoo@17_}7mw*9Kpu&<Lm$vvGyWGMCMO)d71$41H81}+p6;z1Lg7Dd`
z2p~qYe#)$&>cgWWLOyrZvgbW|I41lU06@uHJFmGJczQmy7Hq6=kg~L74b=up63O>9
zG2yh&<Hy5Z_7l|4=bgl6m3@ONH>pzo3T>$Q^XTs}gJ|ej0SO5i*UCR}>l+Fob=~~e
zmZBQKTwk-9EE|p_o4Hfxse!QqOHIYzl@*0^_E`00s*F<+)J{6madyo~xaO$fYL^J1
z0#t9;d}Ujq3i7@7EL2-|cLh<F7_2*01#G(kujxk`a9gH$FXUUgIt7ruTz|TK3E)pt
zwi~nQ_L4OZdynwZn}U839SaHt_BdNc^)&!G3-jY)n2vzI4^#tn*Un)-QWE#e5d6Ux
zT^?|}Ac&;RH~T*X**~!4&w>9HWL>fm({Q+MdS`sNFQMyv^Nm!-wJ=iP%vPa~gKL~+
zN1C@XVe0RG^9JiSRY7^xkqMwV7gb~&+okiZ4?f^?uWNBW(sd<SulhpP9J_rh6$f`$
zD;>M7fLkD1FSm|msh#RpOJ6n+XKO#lIX`bx8vAD-FQUsf{1WA@Aeyre-jnhc>{?y2
z2f9?OZhLJD7ndIYs%sin^0i@NQKOV_;4<~1P!3q@p}!;oNWZ%j45^TEJIdp8Y#3b}
zwbJ8JKX=?0uY`LV0Y~lyzroz12TgK1??v$;&yBTxDaV8fpN#g^r&_^S0HR;OwKHu>
z*A4<AH0`xR+EA}tMa7h{*xSFLOBlansBQ%vf_nFu8>yps<4Q~ngYNfm$$6*vx%v+m
zRxu~vfT2Uh9p<hw^KOiIemDbFpT!IPXU`t37UhYA09%e_?;?JX%<2fwiy7#89~~G5
z^cHN11{@HE$SD;T8%kF_St%v|Vw$JPS0r64AdL}kO6<#052O6dv!-GZAfXa|i-kGd
z%Us^0g;TQ-30z9Et@ON$h0-%H)T70b`_xvjyoXa8HpVR@8LpiUwOYqu2HfiMf85Be
zq!-z7WfAp%)W`UqEZm(>=dr+(tNuQp3~k-VEr*_Jj<TKgRWL&ooy!l~ys`67VbcXH
z>9lj9oa++#Rrl$WN&e`FxrPHE>~zatPG&b5T4^z}*VustbIzxCLo>27!;cw1-e_T4
z@L>YEK5fb5+1&Y$j#*Wto5d=qZPolU$zF2i%66%imZ6_Cs!^{d#S-ePk&C;n3C(!k
z@p~<Md~+UlaSwlrY?$W)p(3NjQ!~euz`KNOJ5I$&QOL1oWN!{JNBQ2i9LStnFl$q(
zRh<3KLP$ZG54atV1*btx7ltl2aX_kXMVAR#1K)v`u63y*WlZi%Hs^C|QePpm;pIu!
zoCDVE>t7YM)2qXI3t5}=?t#Kbk8x<<KmX9FGz|2A6(;5vu!{<o+|f8@eRP?v<3r|H
z_9Tfmz5X{2%7a3ZDg}+wrm_s^aPaMDxlGG8b=Hqxxm#sb^?l(?u{*kT(LByxS@GyW
zLxLDpGWX_voj-UmEaMgZcI3;=Of@=e-~4>hZHlQPZ5lJHUxqWwt3OrT-o6{<-xH|S
zJe6fF_$M*$MX2=&Pv~>mMEH3bl&VBKhNU^bwK{SyVH|G}eb8A`1zsd~I`6L3HUU-C
zQbFjxS;pk_yDot^MpyA(GPET;N0gB_pdVB;S<QChVXrcyG)TqVG!2GIyW>cRVmlJm
z<#^yM*U9v0J%k^hHb<Mj|K1Y%E`|V53)8*y?|gOXkk*vL0FOn}1~qh`xtHQjr(Ng8
z%GUT(;R29-WKR61f$8XiCM~W?4+HyEHuI<6HsM_=fGD*Zw{oBZg+kC6h<;AoSxW9k
zG}Rq(+hCvu`yFU{ZYZ`TMnojYO|t^Km1Y}=yVW$3Kc&E{vZjffd#iOlGIyy#TGemF
zSV=FFiTt<J_qkjwqFsVfyfdAkcKKMJ;BQ&tEPt|-x+b!1D(0f52DROH0?*lU`L6+f
zg@uCw6MtGQQPrULk47u+j2q5>NcdK5%0g8&Drhcm*Utig|2Jq-@Tq&3y;JXDs?owS
z>m9YpVUXFIF~CPS#pP(!g`tcBx8PFVZRY=E;JO(`8y`<Kt7Txk*^=Q_wk1jTUv2u4
zZy3J=EL{ZCH#V7bo5f65eZh|(uwWNd*#6irmy0`HH`50VP_ffkiFt!S!vCiQ-d3%x
zOQH1{oTXGTMIqDwHBicdz6y5#0B^u{<A0#4ufot6n*`;sBs~``fO3_T(M9GX0Q8_|
zy`{X!LhqHF(P>#%kcgX6d3s6r7t@qqM=%5~a3B=vC~9{&KyV5Mp~P2eV1|gH%yz;K
zkeBID_c3#1rU#ZNy{=}QIk^fdgw7z)I*3L@EOLLSV3?I^i?IG8$I4Wi#-7`r+RuSh
zY4fU7B#`7-;&?!t=-;{K`EFVkSo8(M-QU~EJ>)Ey5fjyTIi7IngTeREnSNP&EY7O&
z?Fc?}h!)?ri9;o64HiaG>bnvUc-1Qlo8?T*s$_-pG=O}6&rs{Mh_8-kFQ3Z@XnbD6
zwi#8q<RZqE`IBN!pZLNiA8H#h+7-lwZvSHzwE*oJTDGP-Xos2YublJ8X|5B)x*D-~
z`z@>Rh5*ilU7Z1HE-iD$ZFI4f18DsLp+L{yQapz$7IaE2juU37Hf$f8plp^R%Z!&O
zwm^pAiBDA5?)TXN47iKNyqp`SrcLcE<r9~4Xak;NIyI>T(g}KPs69W-^q(uJxXb>A
z_tJ_Clzam0m<%1a$Bk<w!_QhUd<eDltLH<v25+sZrBE7oSnZ#x<rjHO1m~1i4qpA_
zvHV+Z81g4>vigshZ|Z+!jH85GLaB!fey2Wk)x<lKmsk1sPz#F{7duKzRM*B!f9pOh
zWlgpVA>Vau`E(xB4#@&<EHWT$v_O);1z-mKfUol>bK<Mw06AEc?(1Z7?_hXB)ZD2#
z4mABWD8ir$cxbPRWeh_d??AyPI(T(R#uz4uqRdw*7i*wD-h7l&KmQe++r{?aZKkzl
za(kQ7DP96k1Y^bH$t`(8q8p(u8ZHaZ)V&}QK^y5}x>Jzt8v!~iXGc^>h49<~lXry$
zFA=X_O5>^WCs{p;9o}FRbxv6xC*6dWfs@t1fbj|4YX$n4pOnpGIQ4wnyOAVBHyy$}
zCFz7XpVGQ|*qEc=+&`3w4tDRwy~Fxz`-4io68zf{mL<dnPeWtTsLJ_`c<7rKQZyJY
zWr!XNKnF){_TSuW@I8#%*k9$a|5xPszmvFs_D&lYqR6BAkZrY*rY52O;j;7U^766=
zM6aIZel8YD@<QGVV1Xo+?r%rEo<<>-`_`wcav?bjD=W|A`rU?x268uTY(y<0K7TS1
zpHAo143;wOUO6|<cP~I0BtA7g{dj2154_z@I@sTbQ2%1N^0(kcYimo(?#;9I_Vynm
z&)Zom!(Q_)I6M4Bz%tE%oTz0bV=XVT+kw_l{yX)*Fmsmn3p8D*F)wch<9S2Ueoc_H
z?(<F5v&+rtIwU&=kwZT$wmz!M?aG2z$I&7K+dRBZ#@JWuUD-~xw36`W9^cI>%su|R
zk+;6avw?1$1+Nb9(-X9$;d+v>JAsePzlTTrNeJT#<tDi`QXS?2D87r%Nb6i<9OhL3
zk!QQ1C8B#A-!^8=Q20Z3rFBUv79n3Zj%ru=?6&$Kz{e#M(rcO;8tKW&5H~(MsJ8Zb
zOXlgPLm%qXK@!0I&5dW0)|)P^+vSzQLvG+=>)rAp{^60#Sl{{-JCUioFfzfN!*vh)
z^WHK8j~Y8TLZnx_6%2oRZXe}!V|$m7<#pGmE6L}4n7mVXc*^d{eqVfe3Z?lt`8-Jc
zO5|yfzZrj^QR`uR_1rEr^zh;G5w+!+A%ysu2$0Dgh@Hg^?(=dh!sDh~yjAghIBP`e
zZ8_}&H)eUxUIz3qoC7=`gwGFKL%klS_5CcP6dATQR-X`Z$sl|AW*Q5EUS9B=KC#!s
znT+Ro90<e~A$*ZT{P_FvdbQPdGjJ(-H@ey4ZsE9BqV1~lo2K={&SUEXCo~F_NSl*K
zx!2t@-&2hE#TJ<eN&vv!?qYbB|M6%=SI3(B=FEEjyR$705J+6+>0WtH1%Q0^y2s0K
z7Rno1LR(dafgcR)oK<{J08<7Hzi#3xB;*8sUJaqi0<3vA&=Ai&-dy2hKj;0*5aF-C
zJ&xi>sdURee!ki46+H30+w{WLz9U6l^J;n&gU1=;lZ!(e5Q0ERh=459ZNIP_f?OfB
zJ0Mn+mn7r`|MLYRHa#Sj3{fla-&gU+5yal-9U%h>?hneJKksb+E-!=neJ2rc8y4hI
zxtu$TQU0*M`Ak#3;=YYfy?)k-{p$Ix-pv8OipQT9w%eT+Foe(3H3#0=DyTg7a~4~1
zW20Wzt1CBKBHEoVv!dlz<~gxZzC>6q5YnPHujgX7Y3wM%?K=JYB!}%FZ8*>Sfcz)m
zeWeIscqIan-|NKga54#Sm{<PbiK_8vUv!u158-UkuB$5`Xt6Fof48>v@d)BNxp+MB
z^0KwHwYDz*{(b%A>G<Sn4fRRDuJ0)U1KR58O1r4#K0nH6u{#a0@|d(bYE)L?P28F`
zLd<b{Ij$dss@X@x?{>&Yztwz?aR%#MU(TP$<vUZ(S9H($Wdj*7O1RuAzr<fq@X>Dv
zHLBb5dYy(}jL?f^I+ydZ#`*y&l0}i(eVu`b-QXmU^YZm`pA6r_yV>#}{VWZ*C$;+<
zvg!F~%D?_ZK>^5ZkOC0hUN=Erb&&E4qn_X@h@<311(K1G;q}n#m45p{!1Q@2VUniY
zs{%_Z+3UIe6OXbgxNhl5-J)DaXLDT8wRfVYAR2aGNmPZUG5iM-_Vb0p^KM#H>+K9>
z6|pDFz0<<o{dLb%ZJ=2oJ`sP#WXU!|iPzm-YZ(92wG32K!Deywdu@0~u(FjwTpUhg
zf0^mWf88`TA*2@yVJsi3ad~>n(+zu0$Qe67tJk9ffye7MjEC{4u7l@ChNyy;IlvT@
zBZo$(%u-7m|9RQX-a+f!t#%eK_^zC9sCvu!#$oqSgor=1m#AEReAebMUwe6RoDlr@
zl)U`ha&XPw<E?h&ewGr5cyOW}qIG|EGT{=>{gm~~r&-GQh4*Mwog-%$+$vi5><T=u
z*g?IWJNdfGfW8A_c*V$nKNT?hyz6zJWUk%L3h4DNcfUQ`<tlzm?SF9GK5Ts$wJxig
zxw@YDMJKau@!INXo8RjaW=+KF-X$S)<Ze~_{_zU+`j>iu$n9aGsgx5Q5&y$$uS-bx
zUqyMB@q0eBEiBq6z68CnfKseCY-lpP_gj0bxxK3`rcXUYkpx7*of!7(CzB%;;+A`a
z&h<{2hxgAD+Nbi+xl!6rlOiiRUhnRv;l9f_otZSB9#$qj#}77r`2EayX>?u-WcM1h
z2MkaTY~t_Jw4;(}!FlK7<z)>f<`x|d*=Ya|?+=Jy-K;voai`S0ftZp=tl}EJlG^qL
zJl$|bJ7e_b3;gB+z>CB*D!S@ppB%6M)^$IEj}$|W=jOvfafiB5(=vT}r@GkfC}96u
zCP_)Li|uq#6L2%|mIbRtX?%o$yDd%rh!x@G%*VZdxP~lD2MHp`eE9tTzoZ5)enpZ)
zg5N;FVuK)YJsb<dY;C8>Z-GY7%*l_FnvwT|g&JP<KGnj<wH8eZ%yz9K7IXo0Z{I{@
zBy+6udFXi_`kQZG)}m<_GWrV<-Dz-nbX?!sf{cj3$pk}Byat=}qhCq`n6Y2i`#3kF
zW3cwzN)PvWa96Ru16Aou*LIYprLbzdEAiW}<bb#-AGU+i@oo7o`wdz+9wDbuCb~=B
zGI|Dyd6)VH_#EvoK!H9idoEU0*cN}Dt5Zlwt{cp9VLPtxxv#CzT#=N@m`a^Sb4i{~
zuEcc!KPb^b#HFRs8&4hTsKO9pS4SO_UdNu{8^=9VT!2qq6P;~^O}$b^99f{@aB(($
zWjU$b!@3I6E|8pre6u9pAG%Yys<+#Sxlkc9J-w7v|JW#d&Xb#lC$Uz6ltR8kf`NfN
zotoPN)AyUFMcu*{E%QC55jivBTLAh#0Cc3y$IIxXXSEgJdQuyRL8HID2t}?;F@h`^
z(ZtAqT?z$K0$&&=q)>6b6*~Ar!36g?`l8{h!~AV5Q~3t2Aa%uuAFAsXfrv1_iV~IT
z<AfbkC^FV-=r6=2)PGzgJ_HpNL2Kz6onV`}T0|6C8e6Ga?)k{W6(o3zW!M90wj5rQ
z^2l0GeSo<quj>hU@5K}V;fDg9{I(Sp#$gUGr;BqLM4pVM%$Vt2ejrq8jde+GvV9EL
zn3V3qx4G@G#RN1n8U0Fi@$i!ScY2kjJe}*)FQ!je;RQH4Q^yYBi|q$cUH>uz?1VEo
zDGPrYsdzrwyc0QadQt7S664we57ng?yJua>+SI>s{ww)=te35YLrB2l#<Qry?cwM4
zGsTz>3N$%eZq5=hIR6bD!*m_yK!&=*4*J5+wS=C{(-ziUpFWw4lHw4X;jDm>?Z5@I
z|C<qba9EV|kT?y#n}wQh+1%18Qj^bq+bm`lBd5&2Ti?uli=(7_ZtP*8JJRk5Qjnf{
z^QUI7zAj%A^LF)U>Xx!)LdrLuw=@`9G8Q5w*i&+GohUW36ih-#LR#u~)!ixmbs^a4
z6aAw<hvO79jff<8r3Bc=w>hd9I}07rYDF4^M`>N#*nf4+h}L$tILtf#IR6#PZ>pGJ
z%7m-6$W(4*nlus+xVl$^8wL!mfoXae;)@Qj9MdJX9Xfb8jufuU)tsNR3S4+?19-5S
z{ncXzxnv0KO~(eO%5I_QWH_%2k4Xzh=?1k%+m2RQ?z+abljJ-e$IYwty2)j)yt;~r
zdOeNnaJh0=xGa8jJbbq+`Lmy8|Lr*7*&3qB8TlVZ2N*_{ngzZplZlUhki<4{U8&RO
zOlV|4tdD(Y7hLLs&2`ty%og+zh9JnGjZ@5I_fPU8v80U~x8NPmI0$?JnzmW`G@r9?
zhck*;yk6HiZ@)rrZY(Fc<-bdYt6T4L+r!Y%^g;&p!@mEMmPT!@I-jGCs~S2?N{Qi2
z0!s0(u$IYulC0Zdn?R>Acg*)JH1t!UhH4S){V?K?Xbm^UZt|%BN?_Lf_n!E|cGAmm
z`P(baelnc3RXr`~(##xchz^t7^Hdx;U|Dmx_Yrt%<bji`5T$4xrLxRS-)Fk`xM!-k
zh^3|eR<gn7V+E`b$2&#`aF7bLoMmzBZqYYoJIV;NUyAf$W|}+Gv_}O0@_c}bn8P*N
z21gH}zs(IvX$;<aK0B3L)7jG3&2aGZn?<lVEkF(Z+qRIs3lLZ{XD+B6El`2>o+%(c
z?-I{1cJ9gBMNjcy^b2ux{kg3Q-tJ3L5zb(Lm(lc*g$hc*{8M<QjVb^jCS=|_5IthB
zkG3#_$lTKRjT7NE@Qjz@x=lmG`c*nQT62r+b9fC0)%Nx!DxRY_fH66>K|?;KDaU93
z029v@o^XFN&Sr}+sj})Lg`xj$bhu5559emRRh;uBM5qtL;qBT?!y8ww#0e4~81hWP
zJuB}q!mcs<04TT{!Z#1gg=Q7L@AF<PNt@h{7jG6e#d$qtxB!KNSEZ|@qNY7<oOj7|
zh!NOGd2h~BdIRxNNHm07F0_EZ>)85&2gtn=cKScqbk|H;S)i8D!c)A4E*=(^U|eH&
z0K=)wEJW}s(bGTzTtW&(iV!5gQ71Vm-~3&5P|V-Cv@pcytsWzQ5u_kRkUC`>X8L|<
z2j_rq)f6sTvXgaflLG|+tyh?+&L-O0DvzI_AztKXwb*!gUUpO<q&&K{{rg<m9ruEK
z`opA&yb(jjUxo_>kmLSPFl7k=O7)pm*fjj3*nC`exW9WRlG#Wub1B@CTbu{?meii4
z8>@<6`lC}l^I`_F;?CEB1Ok=nD!g@0axx7goe`JsA<l*VM-{E(I*~!p+|-{<Hi`+<
zKVTYb+X>5i%h&U7N=@M9Tlm%vR@9{g2kD=>mUfr~J-VlW7r&>b3}|CZF%4GmPzf}*
z-e%ME?=$sl=epV<XpB#eIIUL$(e=oy-xAlR^)~EUygW?<Au7=qGeKr3lN5cYx!R5r
z{n3&J%kgMHW@EQ|fu|91TSpJ5jnzon#H_7IzjyL#zV?rrK;^`XS!4J*MbGG$>W?)E
z(f@W=2si(5nCq(ux&m^k<Kw&7Y|IFcX8*kOjUG&+EG^S&M^{h(g#eJS*j|u|T#A?k
z0AL!#zJ6Bxrx^otzJr4DdtXJSR+xRky}NnZVEr6(jbdDS=+eA^QZ^oUF&aIg?k(j1
zpGL<UmI;;CGR@6z48i7#1JlXrtV5nq$f6eSF;Xo1@d>iOJ{ZK|NtqeRms^-;cq|iw
z?T%`N9B~uWvGr_;_YBqdSur+KD#C2{GAH`AM|e!9HRv+`lXYW8<FR1>>qn1?0_sTv
zrY4Y~*7n58t^mgz7l+66EeY=F05gzZwo^04o(xfa<$ae2nqcrfsa8-?4f}<%eUK1t
zI@;W?wnU|;?|oezpCxOX(Ih;NXZ}Wr?Y3g5CJS~%bqzF(7P8_<4A1>b>(JCuj<Piz
zr#wr0Sq8TxT0&AukeX$N^~)-g&@O}q!wsaT0L&Q^B_C_4vO^F3Jw}C*%C>uIps0Ts
zeaE4lOCWY^kxh*hU&G8mp#+~4Zj+##;@>0irSXuUnP4*6KTrKyl!B9HxP_%C5j@re
z9b(w!p%vxu@aV-)8`vAIx`RF#QLH~!on+0R9wRuB55i++w$_w1McxS=1i9GPOygV`
zH-X`JE~Y74OI($T%aY@cC^j`n78b@)vTJfY=qu)}SY{k1;`vM!lT0UYwKkc`O-;=g
zhrZv61=E}*REGH6nyHjYwhay+K3?h{;g!uzDc@Jn`~<@sq$Kae|7aPt8eIuA_y=2O
z112g3t*7|t%0T}pZ<&c<7%)jAa2ht>c`(fdxsC;%whJG*6<fOYA=*;r?NvufEFDZ6
zW#Fc&$}(z;(<KK1)o)MRyuHBka-+VM^qd!4QyJB%6zRxstN{eIIS074N2_fU%$#eP
zvvm(*5ZX@)b8o;|S^3L%T>_osPYlv!C~81*eXZQ|*d%8jSvn>`wSmPH;y9+N=<82f
zq#e`WV2Bvi?(&x|j{LA%*rH^W>=H9P>T&m~G8`iB+*jZHOjuAZMlN2?#p_I*ca@RF
zMD^WtVlg@}5V-|2RWaE5>D8p9JX5u>PM9rgW9Kb3L~Db(KmV@E{JXBCp1k&rc%1e~
z6SbmBqZ8Mn|KM@r2phC_BwMGUvxG4ac~JcLr<`S;n4w(hpoXWZ1kTbwsLUdbdOIiv
z<|>GlGLHe_T1>ZCg52z8P!)lsrwzvi1+PqJQRVdyB&0E$zGrIoj<%m*rx(5C8x$#m
z4kTC<K&IEzE##`+!Z=;%oFC(<m`q#>d|sn16K9f<W35(`nrh)X;#Lx5(>XA&9?EOp
zj);qYWTicHj&#F-l$u@N($|ucE}Y}WFL<!B>$Q737!{%sn{DA=TuE&#_|-o$2%R;m
zG&z0SSldZh)gW#1m{A(4p!=xo*az~R@n+!=(F@9$4NQ*&XmC$2<Z5%dtXO4K!syHG
z5N)5>TUeslgD*@>v7h@?N1(arX=J~|D4wfSU5YEIv^o_H8FQ{1O5-URr5XgzHVl18
z0%@=?*?;%G{8pUjos=?vZf~oN4QiC4FeOrU%xx6bb8vJq$es3V(U$dd!Qtd))ME>Y
zurwmU1m9}LB!*2=p2X5;U077-PR<kp0UPIS6wk))6C}qs%3HkOx4$c^w5?{Ho_MQV
zje_NsfG%?CM}i~XM)c9J*t1UahZ)W?Ni%Lm89>I4a}r7~M8m7c(MQK_rzi#^{zda$
zMrgR-95(TRsH`ca_<)5D%brnYRIBq<6@05MKe<1WRkrVN5fG)&KZU9Ppg#Y1(awL!
jC;z9k^B*`!r1<33XwG`nN{&PUfZW7{q`#JZ(eeF1y^Xyv

literal 0
HcmV?d00001

diff --git a/doc/automatic_conflict_resolution.mdwn b/doc/automatic_conflict_resolution.mdwn
new file mode 100644
index 0000000000..0d4f55a01a
--- /dev/null
+++ b/doc/automatic_conflict_resolution.mdwn
@@ -0,0 +1,25 @@
+Running `git annex sync` or using the [[assistant]] involves merging
+changes from elsewhere into your repository's currently checked out branch.
+This could lead to a merge conflict, perhaps because the same file
+got changed in two different ways. A nice feature is that these
+merge conflicts are automatically resolved, rather than leaving
+git in the middle of a conflicted merge, which would prevent further
+syncing from happening.
+
+When a conflict occurs, there will be several messages printed about the merge
+conflict, and the file that has the merge conflict will be renamed, with
+".variant-XXX" tacked onto it. So if there are two versions of file foo,
+you might end up with "foo.variant-AAA" and "foo.variant-BBB". It's then
+up to you to decide what to do with these two files. Perhaps you can
+manually combine them back into a single file. Or perhaps you choose to
+rename them to better names and keep two versions, or delete one version
+you don't want.
+
+The "AAA" and "BBB" in the above example are essentially arbitrary
+(technically they are the MD5 checksum of the key). The automatic merge
+conflict resolution is designed so that if two or more repositories both get
+a merge conflict, and resolve it, the resolved repositories will not
+themselves conflict. This is why it doesn't use something nicer, like
+perhaps the name of the remote that the file came from.
+
+See also: [[git-annex-resolvemerge]]
diff --git a/doc/automatic_conflict_resolution/comment_1_307898855f91a2a189d4fa5eae62cce1._comment b/doc/automatic_conflict_resolution/comment_1_307898855f91a2a189d4fa5eae62cce1._comment
new file mode 100644
index 0000000000..57a8c45f84
--- /dev/null
+++ b/doc/automatic_conflict_resolution/comment_1_307898855f91a2a189d4fa5eae62cce1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnJTqmRu1YCKS2Hsm4vtOflLhP4fU-k98w"
+ nickname="Ahmed"
+ subject="Customise conflict resolution behaviour"
+ date="2014-02-25T11:42:08Z"
+ content="""
+How to customise git-annex conflict resolution behaviour, such that for example: change naming convention of conflicted files with suffix or prefix, move conflicted files to another directory structure, overwrite conflicted files from preferred content ...
+
+ 
+"""]]
diff --git a/doc/automatic_conflict_resolution/comment_2_0a8ea42764dde1a33d2112197b961c51._comment b/doc/automatic_conflict_resolution/comment_2_0a8ea42764dde1a33d2112197b961c51._comment
new file mode 100644
index 0000000000..8c50ec4e22
--- /dev/null
+++ b/doc/automatic_conflict_resolution/comment_2_0a8ea42764dde1a33d2112197b961c51._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
+ nickname="Matthias"
+ subject="Use automatic merge without syncing"
+ date="2014-03-20T10:03:41Z"
+ content="""
+Is there a possibility to use the automatic merge logic without using \"git annex sync\"? I don't want to have the \"synced\"-branches, but the auto-conflict-resolution is very nice.
+"""]]
diff --git a/doc/automatic_conflict_resolution/comment_3_5c587c6633cae1c8547ca970d55ee97e._comment b/doc/automatic_conflict_resolution/comment_3_5c587c6633cae1c8547ca970d55ee97e._comment
new file mode 100644
index 0000000000..58bdc56310
--- /dev/null
+++ b/doc/automatic_conflict_resolution/comment_3_5c587c6633cae1c8547ca970d55ee97e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.102"
+ subject="comment 3"
+ date="2014-03-20T16:10:10Z"
+ content="""
+@Matthias `git annex merge` will do what you want, as long as you have git-annex 4.20130709 or newer.
+"""]]
diff --git a/doc/automatic_conflict_resolution/comment_4_80539e11e36a0b64cee83b6b373bd843._comment b/doc/automatic_conflict_resolution/comment_4_80539e11e36a0b64cee83b6b373bd843._comment
new file mode 100644
index 0000000000..d67514452f
--- /dev/null
+++ b/doc/automatic_conflict_resolution/comment_4_80539e11e36a0b64cee83b6b373bd843._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
+ nickname="Matthias"
+ subject="merge for master branch?"
+ date="2014-03-23T23:02:23Z"
+ content="""
+As far as I observed, \"git annex merge\" only merges the \"git-annex\" branch. My wish is to have the conflict resolution from \"git annex sync\" in the \"master\" branch, but no automatic commit, such that the user can verify and possibly correct the merge. The proposed merge could go to the index. Consider the following scenario:
+
+1. We have repo A, B, and CENTRAL
+2. All three start with a root commit in \"master\" branch
+3. Then A commits a file \"test.txt\" with content \"a\" and syncs with CENTRAL
+4. Meanwhile, B commits \"test.txt\" with content \"b\"
+5. When B tries to sync with CENTRAL, the proposed conflict resolution having two files \"test.txt-variantXXXX\" and \"test.txt-variantYYYY\" should be staged in the index, but not committed yet.
+6. B can now commit a custom merge, e.g. with file content \"ab\".
+
+The point is that I really like the conflict resolution, but still want to force the user to check the result.
+"""]]
diff --git a/doc/automatic_conflict_resolution/comment_5_00ac9e4a47ce9a886dbf573480f151bd._comment b/doc/automatic_conflict_resolution/comment_5_00ac9e4a47ce9a886dbf573480f151bd._comment
new file mode 100644
index 0000000000..4d1e7c4bcd
--- /dev/null
+++ b/doc/automatic_conflict_resolution/comment_5_00ac9e4a47ce9a886dbf573480f151bd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.41"
+ subject="comment 5"
+ date="2014-03-26T18:56:30Z"
+ content="""
+@Matthias you need to install git-annex 4.20130709 or newer. Then `git-annex merge` will do what you want. As I said before. 
+
+As for committing the merge, you can always adjust the result after the fact and use `git commit --amend`.
+"""]]
diff --git a/doc/automatic_conflict_resolution/comment_6_8a0860fee88f5954918305f055a39d8d._comment b/doc/automatic_conflict_resolution/comment_6_8a0860fee88f5954918305f055a39d8d._comment
new file mode 100644
index 0000000000..4e9493d129
--- /dev/null
+++ b/doc/automatic_conflict_resolution/comment_6_8a0860fee88f5954918305f055a39d8d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
+ nickname="Matthias"
+ subject="auto conflict resolution master branch"
+ date="2014-04-13T17:48:19Z"
+ content="""
+@joeyh: This must be a misunderstanding of what I want. I use version 5.20140320. I can't find a workflow where \"git annex merge\" changes my master branch, it only updates the git-annex branch.
+
+Thinking again of it after some time, I am basically fine with \"git annex sync\". The only thing I am uncomfortable with is that the automatic merge is pushed without review.
+"""]]
diff --git a/doc/automatic_conflict_resolution/comment_7_3d2250cc26036b8532faa980065e20d0._comment b/doc/automatic_conflict_resolution/comment_7_3d2250cc26036b8532faa980065e20d0._comment
new file mode 100644
index 0000000000..9f49021da5
--- /dev/null
+++ b/doc/automatic_conflict_resolution/comment_7_3d2250cc26036b8532faa980065e20d0._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 7"
+ date="2014-04-17T20:00:22Z"
+ content="""
+@Matthias, here is an example of git-annex merge updating the master branch from the synced/master branch that was pushed to it earlier:
+
+<pre>
+joey@darkstar:~/tmp/test/2>git annex merge
+merge git-annex (merging synced/git-annex into git-annex...)
+ok
+merge synced/master 
+Updating 7942eee..1f3422e
+Fast-forward
+ new_file | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 new_file
+ok
+</pre>
+
+If you are having trouble with it somehow, I'd suggest filing a bug report.
+"""]]
diff --git a/doc/automatic_conflict_resolution/comment_8_ef474c258ce8e0ebc6485c1366ae6315._comment b/doc/automatic_conflict_resolution/comment_8_ef474c258ce8e0ebc6485c1366ae6315._comment
new file mode 100644
index 0000000000..81f089b114
--- /dev/null
+++ b/doc/automatic_conflict_resolution/comment_8_ef474c258ce8e0ebc6485c1366ae6315._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
+ nickname="Matthias"
+ subject="auto conflict resolution"
+ date="2014-04-19T17:26:11Z"
+ content="""
+Thanks Joey, I could construct a scenario where the auto-conflict-resolution was applied in the master branch.
+"""]]
diff --git a/doc/backends.mdwn b/doc/backends.mdwn
new file mode 100644
index 0000000000..da37597902
--- /dev/null
+++ b/doc/backends.mdwn
@@ -0,0 +1,115 @@
+The "backend" in git-annex specifies how a key is generated from a file's
+content and/or filesystem metadata. Most backends are different kinds of
+hashes. A single repository can use different backends for different files.
+The [[key|internals/key_format]] includes the backend that is used for that
+key.
+
+## configuring which backend to use
+
+The `annex.backend` git-config setting can be used to configure the
+default backend to use when adding new files.
+
+For finer control of what backend is used when adding different types of
+files, the `.gitattributes` file can be used. The `annex.backend`
+attribute can be set to the name of the backend to use for matching files.
+
+For example, to use the SHA256E backend for sound files, which tend to be
+smallish and might be modified or copied over time,
+while using the WORM backend for everything else, you could set
+in `.gitattributes`:
+
+	* annex.backend=WORM
+	*.mp3 annex.backend=SHA256E
+	*.ogg annex.backend=SHA256E
+
+## recommended backends to use
+
+* `SHA256E` -- The default backend for new files, combines a 256 bit SHA-2
+  hash of the file's content with the file's extension. This allows
+  verifying that the file content is right, and can avoid duplicates of
+  files with the same content. Its need to generate checksums
+  can make it slower for large files. 
+* `SHA256` -- SHA-2 hash that does not include the file extension in the
+  key, which can lead to better deduplication but can confuse some programs.
+* `SHA512`, `SHA512E` -- Best SHA-2 hash, for the very paranoid.
+* `SHA384`, `SHA384E`, `SHA224`, `SHA224E` -- SHA-2 hashes for
+  people who like unusual sizes.
+* `SHA3_512`, `SHA3_512E`, `SHA3_384`, `SHA3_384E`, `SHA3_256`, `SHA3_256E`, `SHA3_224`, `SHA3_224E`
+  -- SHA-3 hashes, for bleeding edge fun.
+* `SKEIN512`, `SKEIN512E`, `SKEIN256`, `SKEIN256E`
+  -- [Skein hash](http://en.wikipedia.org/wiki/Skein_hash),
+  a well-regarded SHA3 hash competition finalist.
+* `BLAKE2B160`, `BLAKE2B224`, `BLAKE2B256`, `BLAKE2B384`, `BLAKE2B512`
+  `BLAKE2B160E`, `BLAKE2B224E`, `BLAKE2B256E`, `BLAKE2B384E`, `BLAKE2B512E`
+  -- Fast [Blake2 hash](https://blake2.net/) variants optimised for 64 bit
+  platforms.
+* `BLAKE2S160`, `BLAKE2S224`, `BLAKE2S256`
+  `BLAKE2S160E`, `BLAKE2S224E`, `BLAKE2S256E`
+  -- Fast [Blake2 hash](https://blake2.net/) variants optimised for 32 bit
+  platforms.
+* `BLAKE2BP512`, `BLAKE2BP512E`
+  -- Fast [Blake2 hash](https://blake2.net/) variants optimised for
+  4-way CPUs.
+* `BLAKE2SP224`, `BLAKE2SP256`
+  `BLAKE2SP224E`, `BLAKE2SP256E`
+  -- Fast [Blake2 hash](https://blake2.net/) variants optimised for 
+  8-way CPUs.
+  `VURL` -- This is like an `URL` (see below) but the content can
+  be verified with a cryptographically secure checksum that is
+  recorded in the git-annex branch. It's generated when using 
+  eg `git-annex addurl --fast --verifiable`.
+
+## non-cryptograpgically secure backends
+
+The backends below do not guarantee cryptographically that the
+content of an annexed file remains unchanged.
+
+* `SHA1`, `SHA1E`, `MD5`, `MD5E` -- Smaller hashes than `SHA256`
+   for those who want a checksum but are not concerned about security.
+* `WORM` ("Write Once, Read Many") -- This assumes that any file with
+  the same filename, size, and modification time has the same content.
+  This is the least expensive backend, recommended for really large
+  files or slow systems.
+* `URL` -- This is a key that is generated from the url to a file.
+  It's generated when using eg, `git annex addurl --fast`, when the file
+  content is not available for hashing.  
+  The key may not contain the full URL; for long URLs, part of the URL may be
+  represented by a checksum.  
+  The URL key may contain `&` characters; be sure to quote the key if
+  passing it to a shell script. These types of keys are distinct from URLs/URIs
+  that may be attached to a key (using any backend) indicating the key's location
+  on the web or in one of [[special_remotes]].
+* `GIT` -- This is used internally by git-annex when exporting trees
+  containing files stored in git, rather than git-annex. It represents a
+  git sha. This is never used for git-annex links, but information about
+  keys of this type is stored in the git-annex branch.
+
+## external backends
+
+While most backends are built into git-annex, it also supports external
+backends. These are programs with names like `git-annex-backend-XFOO`,
+which can be provided by others. See [[design/external_backend_protocol]]
+for details about how to write them.
+
+Here's a list of external backends. Edit this page to add yours to the list.
+
+* [[design/external_backend_protocol/git-annex-backend-XFOO]]
+  is a demo program implementing the protocol with a shell script.
+
+Like with git-annex's builtin backends, you can add "E" to the end of the
+name of an external backend, to get a version that includes the file
+extension in the key.
+
+## notes
+
+If you want to be able to prove that you're working with the same file
+contents that were checked into a repository earlier, you should avoid
+using non-cryptographically-secure backends, and will need to use
+signed git commits. See [[tips/using_signed_git_commits]] for details.
+
+Retrieval of WORM and URL from many [[special_remotes]] is prohibited
+for [[security_reasons|security/CVE-2018-10857_and_CVE-2018-10859]].
+
+Note that the various 512 and 384 length hashes result in long paths,
+which are known to not work on Windows. If interoperability on Windows is a
+concern, avoid those.
diff --git a/doc/backends/comment_10_920cd139dfec8adb1089f5acf26de4d2._comment b/doc/backends/comment_10_920cd139dfec8adb1089f5acf26de4d2._comment
new file mode 100644
index 0000000000..a756f191a9
--- /dev/null
+++ b/doc/backends/comment_10_920cd139dfec8adb1089f5acf26de4d2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2015-01-06T17:58:28Z"
+ content="""
+@Matthias, that directory structure is not controlled by the backend.
+It is explained in [[internals]]
+"""]]
diff --git a/doc/backends/comment_11_f0f6316bbdc971a9ab157de9bbb9f74c._comment b/doc/backends/comment_11_f0f6316bbdc971a9ab157de9bbb9f74c._comment
new file mode 100644
index 0000000000..fc19964950
--- /dev/null
+++ b/doc/backends/comment_11_f0f6316bbdc971a9ab157de9bbb9f74c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="add MD5SUM (with E) backend?"
+ date="2015-01-29T22:07:40Z"
+ content="""
+probably in many cases MD5SUM might be sufficient to cover the space of the available load and 
+
+- its size would be even smaller than SHA1 (thus smaller git-annex footprint)
+- immediate matching to often distributed MD5SUMs
+- matching to ETags (whenever wasn't a multipart upload) in S3 buckets
+
+or use of MD5SUM hash is really not recommended for non-encryption-critical cases too?
+"""]]
diff --git a/doc/backends/comment_12_da76dff5fe712318d7d4313f1d827883._comment b/doc/backends/comment_12_da76dff5fe712318d7d4313f1d827883._comment
new file mode 100644
index 0000000000..e4b3b277b7
--- /dev/null
+++ b/doc/backends/comment_12_da76dff5fe712318d7d4313f1d827883._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""MD5"""
+ date="2015-02-04T17:25:45Z"
+ content="""
+I've added MD5 and MD5E. Of course, if you choose to use these, or the WORM
+backend, you give up the cryptographic verification that the content
+currently in your repository is the same content that was in it before.
+Whether that matters in your application is up to you.
+"""]]
diff --git a/doc/backends/comment_13_578423935bc71cdbdc23c3db06d1e870._comment b/doc/backends/comment_13_578423935bc71cdbdc23c3db06d1e870._comment
new file mode 100644
index 0000000000..3d8f2a5a23
--- /dev/null
+++ b/doc/backends/comment_13_578423935bc71cdbdc23c3db06d1e870._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="THANK YOU JOEY"
+ date="2015-02-09T14:04:27Z"
+ content="""
+for the MD5/MD5E (and now I have found \"email replies to me\" - I will become a power user of branchable ;) )
+"""]]
diff --git a/doc/backends/comment_14_57154dcd1041a33f220f9105b709be89._comment b/doc/backends/comment_14_57154dcd1041a33f220f9105b709be89._comment
new file mode 100644
index 0000000000..446960264b
--- /dev/null
+++ b/doc/backends/comment_14_57154dcd1041a33f220f9105b709be89._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xelez0@57a58225d4e5b260555ebc4a9d0a8df85d1e971a"
+ nickname="xelez0"
+ subject="Backend of specified file"
+ date="2015-07-05T13:19:43Z"
+ content="""
+How can I determine backend of specified file? Looking over man pages and can't find it.
+"""]]
diff --git a/doc/backends/comment_15_b3445fd1f379346c642a27211c6c798b._comment b/doc/backends/comment_15_b3445fd1f379346c642a27211c6c798b._comment
new file mode 100644
index 0000000000..3fc12afee6
--- /dev/null
+++ b/doc/backends/comment_15_b3445fd1f379346c642a27211c6c798b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 15"
+ date="2015-07-05T14:54:18Z"
+ content="""
+It's not explicit, but 'git annex info $FILE' tells you the key, which has the backend as its first component:
+
+    ## git annex info CG\ Cookie/Compositing\ in\ Blender/01_CompositingInBlender_SourceFiles.zip 
+    file: CG Cookie/Compositing in Blender/01_CompositingInBlender_SourceFiles.zip
+    size: 744.51 megabytes
+    key: SHA256E-s744506832--08d2daced60b5eb6509044d5eefca82e7a6899350f49adc0083014229739515e.zip
+
+I don't think there are any situations where the first component of the key isn't the backend, but don't hold me to that, please :)
+"""]]
diff --git a/doc/backends/comment_16_c68dfaeee2ef18f420f7e11ff5f604b9._comment b/doc/backends/comment_16_c68dfaeee2ef18f420f7e11ff5f604b9._comment
new file mode 100644
index 0000000000..64c0102e28
--- /dev/null
+++ b/doc/backends/comment_16_c68dfaeee2ef18f420f7e11ff5f604b9._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 16"
+ date="2015-07-05T15:00:46Z"
+ content="""
+Or I could not be an idiot and tell you the command specifically looking up a key for a file: lookupkey
+
+    ## git annex lookupkey CG\ Cookie/Compositing\ in\ Blender/01_CompositingInBlender_SourceFiles.zip 
+    SHA256E-s744506832--08d2daced60b5eb6509044d5eefca82e7a6899350f49adc0083014229739515e.zip
+
+So to get the backend (if the first component is always the backend):
+
+    ## git annex lookupkey CG\ Cookie/Compositing\ in\ Blender/01_CompositingInBlender_SourceFiles.zip | cut -d- -f1
+    SHA256E
+"""]]
diff --git a/doc/backends/comment_17_557a622b3304eb86fed52896e0b6cbda._comment b/doc/backends/comment_17_557a622b3304eb86fed52896e0b6cbda._comment
new file mode 100644
index 0000000000..6f6973ffd3
--- /dev/null
+++ b/doc/backends/comment_17_557a622b3304eb86fed52896e0b6cbda._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 17"""
+ date="2015-07-06T16:03:53Z"
+ content="""
+See [[internals/key_format]].
+"""]]
diff --git a/doc/backends/comment_18_784b29b086503a2b4913558350526ee1._comment b/doc/backends/comment_18_784b29b086503a2b4913558350526ee1._comment
new file mode 100644
index 0000000000..43c554f7f0
--- /dev/null
+++ b/doc/backends/comment_18_784b29b086503a2b4913558350526ee1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="junk@5e3eeba2290e8a3fcf938d9f93b0dfa2565dc7b1"
+ nickname="junk"
+ subject="Howto verify encrypted files"
+ date="2016-08-14T17:07:03Z"
+ content="""
+Hi,
+
+I'd like to be able verify the consistancy of the files on a rsync remote without having access to the git repository or the gpg-key. This can easily be done with unencrypted files by running \"sha256sum filename\". Is there a way to do the same thing with encrypted files?
+
+Thank you very much!
+"""]]
diff --git a/doc/backends/comment_19_cfcaeea6fdded241f5d36ef251ef8010._comment b/doc/backends/comment_19_cfcaeea6fdded241f5d36ef251ef8010._comment
new file mode 100644
index 0000000000..87d79167c9
--- /dev/null
+++ b/doc/backends/comment_19_cfcaeea6fdded241f5d36ef251ef8010._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2016-09-05T19:47:48Z"
+ content="""
+@junk, this page is not really the place to ask such an unrelated question.
+Please use the [[forum]] for such questions.
+
+(Anyway, git-annex uses gpg to encrypt data, so you can perhaps use gpg to
+check the embedded checksum, but I have never done it, and git-annex
+certianly doesn't support doing it.)
+"""]]
diff --git a/doc/backends/comment_1_375bb1fb5973e8fa67b763f2dd6e404b._comment b/doc/backends/comment_1_375bb1fb5973e8fa67b763f2dd6e404b._comment
new file mode 100644
index 0000000000..dc178a6fed
--- /dev/null
+++ b/doc/backends/comment_1_375bb1fb5973e8fa67b763f2dd6e404b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://nanotech.nanotechcorp.net/"
+ nickname="NanoTech"
+ subject="SHA performance"
+ date="2012-08-10T04:37:32Z"
+ content="""
+It turns out that (at least on x86-64 machines) `SHA512` [is faster than][1] `SHA256`. In some benchmarks I performed<sup>1</sup> `SHA256` was 1.8–2.2x slower than `SHA1` while `SHA512` was only 1.5–1.6x slower.
+
+`SHA224` and `SHA384` are effectively just truncated versions of `SHA256` and `SHA512` so their performance characteristics are identical.
+
+[1]: https://community.emc.com/community/edn/rsashare/blog/2010/11/01/sha-2-algorithms-when-sha-512-is-more-secure-and-faster
+<sup>1</sup> `time head -c 100000000 /dev/zero | shasum -a 512`
+"""]]
diff --git a/doc/backends/comment_20_29e500adf7e8614a938b3b714c9bd112._comment b/doc/backends/comment_20_29e500adf7e8614a938b3b714c9bd112._comment
new file mode 100644
index 0000000000..88c717a4ea
--- /dev/null
+++ b/doc/backends/comment_20_29e500adf7e8614a938b3b714c9bd112._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Lower-case extension backends: +1"
+ date="2016-10-22T17:55:13Z"
+ content="""
+> SHA256e
+> I'd really like to have a SHA256e backend -- same as SHA256E but making sure that extensions of the files in .git/annex are converted to lower case. I normally try to convert filenames from cameras etc to lower case, but not all people that I share annex with do so consistently. In my use case, I need to be able to find duplicates among files and .jpg vs .JPG throws git annex dedup off. Otherwise E backends are superior to non-E for me. Thanks, Michael.
+
+Hello,
+
+TL;DR: *I second Michael's wish for hashing backends that aligns extensions to lowercase.*
+
+## Context, files with same content, extension have different case
+
+I realized a moment ago that git-annex basically automatically deduplicates with file granularity, which is very nice... *unless duplicates have varying case*, which does happen.  For some cameras, if you download files through a cable you get one file name with one case, if you read the card directly with a card reader you get another case (and another filename, by the way).  
+
+In invite anyone interested to drop a line here.
+
+## Workaround
+
+I understand I can align case after-the-fact with a bash shell command like below. Beware: man page of `rename` says there exist other versions that don't check for destination file, so the line below in some specific case (two files with same name, different content, file name only differs in case extension) might cause you to lose some information.  Or perhaps other cases.  Make sure you know what you do, I'm not responsible.
+
+```
+for EXT in aac amr arw asf avi bup crw ctg dsc dv jpg lrv m4a m4v mov mp3 mp4 mpe mpg mrk ndf nef njb ogg pdf png pnm ppm ps psd thm tif tiff txt ufraw wav xcf xcfbz2 xmp
+do find . -iname \"*.${EXT}\" -print0 | xargs -0 rename -v \"s/${EXT}/${EXT,,}/i\" ; done
+```
+
+If you prefer to align to upper-case, replace `,,` with `^^`.  This is bash syntax.
+
+## Please consider `SHA256e` backend (and others).
+
+Anyway the shell command above is a workaround.  A case-insensitive hashing backend seems a natural thing to do.  It would bring the best of both worlds: deduplicate efficiently while not confusing programs that depend on symlink target having a particular extension.
+
+"""]]
diff --git a/doc/backends/comment_21_7f9cc5f966b28b7461e8ec42ceeb7165._comment b/doc/backends/comment_21_7f9cc5f966b28b7461e8ec42ceeb7165._comment
new file mode 100644
index 0000000000..234b838592
--- /dev/null
+++ b/doc/backends/comment_21_7f9cc5f966b28b7461e8ec42ceeb7165._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/iOGTltEpmOTQ.xZ99NFP5c7Zdcc-#6a7ba"
+ nickname="Ilya S"
+ avatar="http://cdn.libravatar.org/avatar/8a133555cc739a35b83b07d5724d28d9e2f7852c224e949eec6fd4fb7693331e"
+ subject="keys from metadata"
+ date="2018-09-07T15:57:37Z"
+ content="""
+\"When a file is annexed, a key is generated from its content and/or metadata\" -- the 'metadata' here just refers to the file name/size/mtime, not to https://git-annex.branchable.com/git-annex-metadata/ , correct?
+"""]]
diff --git a/doc/backends/comment_22_be75c669ed8e127de8b6364961a5c0cb._comment b/doc/backends/comment_22_be75c669ed8e127de8b6364961a5c0cb._comment
new file mode 100644
index 0000000000..8905276e5d
--- /dev/null
+++ b/doc/backends/comment_22_be75c669ed8e127de8b6364961a5c0cb._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/iOGTltEpmOTQ.xZ99NFP5c7Zdcc-#6a7ba"
+ nickname="Ilya S"
+ avatar="http://cdn.libravatar.org/avatar/8a133555cc739a35b83b07d5724d28d9e2f7852c224e949eec6fd4fb7693331e"
+ subject="comment 22"
+ date="2018-09-07T15:59:06Z"
+ content="""
+Is it possible to configure git-annex to use different backends based on file size?   I.e. use a faster hash or even WORM for larger files.
+"""]]
diff --git a/doc/backends/comment_23_8c8b08d7e6409756da4f9f3b21d5ad01._comment b/doc/backends/comment_23_8c8b08d7e6409756da4f9f3b21d5ad01._comment
new file mode 100644
index 0000000000..e8651e00f7
--- /dev/null
+++ b/doc/backends/comment_23_8c8b08d7e6409756da4f9f3b21d5ad01._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2018-09-11T16:52:20Z"
+ content="""
+@Ilya, indeed, this page is talking about filesystem metadata.
+I've updated it for clarity.
+
+There is not currently a way to switch backend based on file size,
+although you can use annex.largefiles to make it check eg smaller files
+directly into git rather than annexing them.
+"""]]
diff --git a/doc/backends/comment_24_f90b8eeae8d150eca6a91416f20eb223._comment b/doc/backends/comment_24_f90b8eeae8d150eca6a91416f20eb223._comment
new file mode 100644
index 0000000000..c22fe26de7
--- /dev/null
+++ b/doc/backends/comment_24_f90b8eeae8d150eca6a91416f20eb223._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 24"
+ date="2018-09-19T16:50:05Z"
+ content="""
+It seems that *E backends ignore file extensions longer than four chars: https://git-annex.branchable.com/bugs/file_extensions_of___62__4_chars_ignored_by___42__E_backends/
+Is there some reason for doing it this way?
+
+"""]]
diff --git a/doc/backends/comment_25_f6a697ac069ab018ccacf8f16b09bc7e._comment b/doc/backends/comment_25_f6a697ac069ab018ccacf8f16b09bc7e._comment
new file mode 100644
index 0000000000..9e7f9f12d7
--- /dev/null
+++ b/doc/backends/comment_25_f6a697ac069ab018ccacf8f16b09bc7e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 25"""
+ date="2018-09-24T15:42:24Z"
+ content="""
+@Ilya_Shlyakhter, it's a heuristic, what consititues a file extension is
+not very well defined (consider ".tar.gz" and ".not-an-extension").
+The heuristic has been refined over the years, but will never be perfect.
+But, I don't know of any 5+ character file extensions in common use!
+"""]]
diff --git a/doc/backends/comment_26_9e9e0f3631c60b0cdcaa9c6dd4ae0d4e._comment b/doc/backends/comment_26_9e9e0f3631c60b0cdcaa9c6dd4ae0d4e._comment
new file mode 100644
index 0000000000..3e6c61736e
--- /dev/null
+++ b/doc/backends/comment_26_9e9e0f3631c60b0cdcaa9c6dd4ae0d4e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="stable vs unstable keys"
+ date="2018-10-26T15:58:26Z"
+ content="""
+Backend.hs [classifies](https://git.kitenet.net/index.cgi/git-annex.git/tree/Backend.hs?h=6.20181011&id=426f0f3f4bff378e7be402d905ed171c6f26e472#n16) keys as \"stable\" or not, with URL keys being unstable.  How is this distinction used?  I found only one [place](https://git.kitenet.net/index.cgi/git-annex.git/tree/Remote/Helper/Chunked.hs?h=6.20181011&id=426f0f3f4bff378e7be402d905ed171c6f26e472#n111) where it's used, but couldn't quite understand it.  If \"stable\" means \"containing a hash of the content\", then wouldn't WORM keys be unstable too?
+"""]]
diff --git a/doc/backends/comment_27_c311551741a671bcb1f32b80431c1d66._comment b/doc/backends/comment_27_c311551741a671bcb1f32b80431c1d66._comment
new file mode 100644
index 0000000000..fd401470a9
--- /dev/null
+++ b/doc/backends/comment_27_c311551741a671bcb1f32b80431c1d66._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: stable vs unstable keys"""
+ date="2018-10-29T18:55:09Z"
+ content="""
+It's only used to avoid uploading one chunk from one object that the key
+points to, and then later upload a chunk from a different object.
+
+While WORM keys could in theory "collide" and the same key point to
+different content, that's no different than MD5 or SHA1 keys colliding;
+it's a smallish risk, easily quantified, and you take that risk by
+choosing to use those keys.
+
+The risk that the content at an url might change varies over time or
+something like that, so I think it makes sense to treat URL keys as specially
+unstable.
+"""]]
diff --git a/doc/backends/comment_28_44e8d93b1f0a88c36543438d6e33d702._comment b/doc/backends/comment_28_44e8d93b1f0a88c36543438d6e33d702._comment
new file mode 100644
index 0000000000..79ee17403b
--- /dev/null
+++ b/doc/backends/comment_28_44e8d93b1f0a88c36543438d6e33d702._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 28"
+ date="2018-11-01T17:12:59Z"
+ content="""
+\"The risk that the content at an url might change varies over time or something like that, so I think it makes sense to treat URL keys as specially unstable.\" -- but, if I understand correctly, a URL key does not actually represent a URL?  Rather, a URL can be attached to _any_ key, and if the contents of some URLs claimed by a remote is unstable, such remotes should be marked as untrusted; while if the contents of a URL key is stored in a trusted remote, that contents is not unstable.  But URL and WORM keys are both \"unstable\" in that their contents can't be verified.  
+[[todo/alternate_keys_for_same_content] could mitigate that.
+"""]]
diff --git a/doc/backends/comment_29_9e14c32713b5607b245972b400286a45._comment b/doc/backends/comment_29_9e14c32713b5607b245972b400286a45._comment
new file mode 100644
index 0000000000..c88adbf701
--- /dev/null
+++ b/doc/backends/comment_29_9e14c32713b5607b245972b400286a45._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 29"""
+ date="2018-11-12T20:25:37Z"
+ content="""
+The scenario that isStableKey is being used to guard against is two
+repos downloading the content of an url and each getting different content,
+followed by one repo uploading some chunks of its content and then the
+other repo "finishing" the upload with chunks of its different content.
+That would result in a mismash of chunks being stored in the remote.
+
+It's true that it could also happen using WORM with an url attached to it.
+(Not with other types of keys that verify a checksum.)
+Though it seems much less likely, since the file size is at least checked
+for WORM, while with URL keys there's often no recorded file size. And,
+WORMs don't typically have urls attached (I can't think of a single time
+I've ever done that, it just feels like asking for trouble), 
+while URL keys always do.
+
+If this is a serious concern, I'd suggest you open a todo or bug report
+about it, there are far too many comments to wade through here already.
+We could think about, perhaps not allowing download of WORM keys from urls
+or something like that..
+"""]]
diff --git a/doc/backends/comment_2_1f2626eca9004b31a0b7fc1a0df8027b._comment b/doc/backends/comment_2_1f2626eca9004b31a0b7fc1a0df8027b._comment
new file mode 100644
index 0000000000..0308873036
--- /dev/null
+++ b/doc/backends/comment_2_1f2626eca9004b31a0b7fc1a0df8027b._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7eqCMh_B7mxE0tnchbr0JoYu11FUAFRY"
+ nickname="Stéphane"
+ subject="Tracking remote copies not even stored locally / URL backend turned into a &quot;special remote&quot;."
+ date="2013-01-03T10:59:35Z"
+ content="""
+In case you came here looking for the URL backend.
+
+## The URL backend
+
+Several documents on the web refer to a special \"URL backend\", e.g. [Large file management with git-annex [LWN.net]](http://lwn.net/Articles/419241/).  Historical content will never be updated yet it drives people to living places.
+
+## Why a URL backend ?
+
+It is interesting because you can:
+
+* let `git-annex` rest on the fact that some documents are available as extra copies available at any time (but from something that is not a git repository).
+* track these documents like your own with all git features, which opens up some truly marvelous combinations, which this margin is too narrow to contain (Pierre d.F. wouldn't disapprove ;-).
+
+## How/Where now ?
+
+`git-annex` used to have a URL backend. It seems that the design changed into a \"special remote\" feature, not limited to the web. You can now track files available through plain directories, rsync, webdav, some cloud storage, etc, even clay tablets. For details see [[special remotes]].
+
+"""]]
diff --git a/doc/backends/comment_30_bea2a3f4f673e6e9d5ee99cf10d39460._comment b/doc/backends/comment_30_bea2a3f4f673e6e9d5ee99cf10d39460._comment
new file mode 100644
index 0000000000..0e56f6989d
--- /dev/null
+++ b/doc/backends/comment_30_bea2a3f4f673e6e9d5ee99cf10d39460._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="annex2384@290036d126d86bcec28ee2f2ead549de1f59e90e"
+ nickname="annex2384"
+ avatar="http://cdn.libravatar.org/avatar/ad36fdc55abd8b9913b774fcd0177709"
+ subject="Backend which doesn't stoee files at all?"
+ date="2020-02-20T14:52:21Z"
+ content="""
+I'd like to be able to have a \"thin\" repo on a FAT32 filesystem. Since this precludes hardlinks, is there a way to make a backend that just keeps track of the file's hash so we can detect when it changes? This would obviously need to rely on having copies in other repos for backup purposes. I'm thinking a mode that behaves more like Unison, which just used its fingerprint file to detect changes that need to be synced.
+
+There would still be a file in the backend named by SHA256, but instead of storing the content it would store the location of possible local copies of the file. This would obviously need to use a smudge filter. It could be the default backend for thin repos on filesystems that don't support hardlinks.
+
+"""]]
diff --git a/doc/backends/comment_31_32df8ec41dd8a6516b88b1871c998eb9._comment b/doc/backends/comment_31_32df8ec41dd8a6516b88b1871c998eb9._comment
new file mode 100644
index 0000000000..c53c2276f0
--- /dev/null
+++ b/doc/backends/comment_31_32df8ec41dd8a6516b88b1871c998eb9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="backends vs special remotes"
+ date="2020-02-20T19:23:04Z"
+ content="""
+@annex2384 \"Backend which doesn't store files at all?\" -- are you sure you're thinking of backends and not of [[special_remotes]]?  Backends don't \"store files\", special remotes do.  Backends create keys identifying specific contents.
+
+Not sure I fully understand your use case, but you could write an [[external special remote|special_remotes/external]] that, for a given git-annex key, stores \"the location of possible local copies of the file\" -- e.g. using `SETSTATE` or `SETURIPRESENT`.
+"""]]
diff --git a/doc/backends/comment_32_b0a375dcd0932aa380ce01d693462f5e._comment b/doc/backends/comment_32_b0a375dcd0932aa380ce01d693462f5e._comment
new file mode 100644
index 0000000000..c0041f0836
--- /dev/null
+++ b/doc/backends/comment_32_b0a375dcd0932aa380ce01d693462f5e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="lh"
+ avatar="http://cdn.libravatar.org/avatar/d31bade008d7da493d9bfb37d68fd825"
+ subject="Improving on the WORM situation"
+ date="2022-04-13T22:19:40Z"
+ content="""
+What do you think about a new backend? There are some hash functions out there that aren't necessarily cryptographically secure but are more performant and certainly better than metadata checks at deduplication.
+
+Modern filesystems like BTRFS implement checksumming at the filesystem level for both data and metadata to detect (but not repair, not without some sort of parity data or mirroring) bitrot. Based on BTRFS's nice [checksumming overview](https://btrfs.readthedocs.io/en/latest/Checksumming.html), maybe CRC32C or xxHash would be good options? Their benchmarks suggest they're 60× and 40× faster than SHA256, respectively. According to the [benchmark source](https://kdave.github.io/selecting-hash-for-btrfs/), xxHash offers improved collision resistance over CRC32C, but the latter is more accessible on legacy systems (not much of a concern for git-annex, I think, given this would be a new, opt-in feature anyway). Since those benchmarks, the latest version, [XXH3](https://github.com/Cyan4973/xxHash), has received a stable release, and is apparently able to keep pace with RAM sequential read.
+
+I was even thinking there could be an option to tap into filesystem checksumming, but BTRFS does this at the block level or after compression[¹](https://unix.stackexchange.com/a/411289), so that's off the table.
+
+Please let me know if this is the right place for this, or if I should've opened a forum post.
+"""]]
diff --git a/doc/backends/comment_33_4c5f9c75cbb8a546e8325b206369aba1._comment b/doc/backends/comment_33_4c5f9c75cbb8a546e8325b206369aba1._comment
new file mode 100644
index 0000000000..d94b03f2b0
--- /dev/null
+++ b/doc/backends/comment_33_4c5f9c75cbb8a546e8325b206369aba1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="new backends"
+ date="2022-04-17T19:02:09Z"
+ content="""
+>What do you think about a new backend?
+
+See the \"External backends\" section on this page for info on adding your own backends.
+"""]]
diff --git a/doc/backends/comment_34_3782e7561607c8ccf1741bd039c2c648._comment b/doc/backends/comment_34_3782e7561607c8ccf1741bd039c2c648._comment
new file mode 100644
index 0000000000..4a80db0d52
--- /dev/null
+++ b/doc/backends/comment_34_3782e7561607c8ccf1741bd039c2c648._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 34"""
+ date="2022-04-19T16:17:30Z"
+ content="""
+[[todo/add_xxHash_backend]] is tracking requirements for adding xxh3.
+"""]]
diff --git a/doc/backends/comment_35_8ac9d37cc2a7b0b361cf686fe27192dd._comment b/doc/backends/comment_35_8ac9d37cc2a7b0b361cf686fe27192dd._comment
new file mode 100644
index 0000000000..7c403b88af
--- /dev/null
+++ b/doc/backends/comment_35_8ac9d37cc2a7b0b361cf686fe27192dd._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="windfish@91c7bac51a452080189a071094cb6f914fe3435b"
+ nickname="windfish"
+ avatar="http://cdn.libravatar.org/avatar/648c1b6a023d94a30193b1b428c8d373"
+ subject="combine worm with partial hash"
+ date="2024-02-01T11:53:54Z"
+ content="""
+would it be possible to provide a combined backend of worm + partial hash? i'd imagine that this would make the backend faster than merely hashes while also lower the probability of erroneously identifying two different, but worm-equivalent files.
+"""]]
diff --git a/doc/backends/comment_3_fdcbf8727fdefb9942a54689234b9698._comment b/doc/backends/comment_3_fdcbf8727fdefb9942a54689234b9698._comment
new file mode 100644
index 0000000000..6f8b1ad7a4
--- /dev/null
+++ b/doc/backends/comment_3_fdcbf8727fdefb9942a54689234b9698._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmicVKRM8vJX4wPuAwlLEoS2cjmFXQkjkE"
+ nickname="Thomas"
+ subject="Please be more specific about what information goes into the key"
+ date="2013-07-31T11:55:09Z"
+ content="""
+It's a bit confusing to read that SHA256 does not include the file extension from which I can deduct that SHA256E does include it. What else does it include? I used to \"seed\" my git-annex with localy available data by \"git-annex add\"-ing it in a temporary folder without doing a commit and than to initiate a copy from the slow remote annex repo. My theory was that remote copy sees the pre-seeded files and does not need to copy them again.
+
+But does this theory hold true for different file names, extensions, modification date, full path? Maybe you could also link to the code that implements the different backends so that curious readers can check for themselves.
+
+Thank you!
+"""]]
diff --git a/doc/backends/comment_4_46591a3ba888fb686b1b319b80ca2c22._comment b/doc/backends/comment_4_46591a3ba888fb686b1b319b80ca2c22._comment
new file mode 100644
index 0000000000..94f25e9962
--- /dev/null
+++ b/doc/backends/comment_4_46591a3ba888fb686b1b319b80ca2c22._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmTho3mActvetF1iQdmui6gH1t6WE6c284"
+ nickname="Michael"
+ subject="SHA256e"
+ date="2013-10-30T02:00:45Z"
+ content="""
+I'd really like to have a SHA256e backend -- same as SHA256E but making sure that extensions of the files in .git/annex are converted to lower case.  I normally try to convert filenames from cameras etc to lower case, but not all people that I share annex with do so consistently.
+In my use case, I need to be able to find duplicates among files and .jpg vs .JPG throws git annex dedup off.  Otherwise E backends are superior to non-E for me.  Thanks, Michael.
+"""]]
diff --git a/doc/backends/comment_5_2210c7ff2d5812fb3b778ac172291656._comment b/doc/backends/comment_5_2210c7ff2d5812fb3b778ac172291656._comment
new file mode 100644
index 0000000000..2a205604c2
--- /dev/null
+++ b/doc/backends/comment_5_2210c7ff2d5812fb3b778ac172291656._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWBvsZvSsAL8P2ye3F0OBStjFCVnOImzM"
+ nickname="Jarno"
+ subject="Non-E backend drawbacks?"
+ date="2013-10-30T21:25:00Z"
+ content="""
+The page states \"[non-E backends] can confuse some programs\". I like the ideal simplicity and recoverability of pure checksum backends but \"confusion\" sounds a bit worrying. Any practical examples of these problems to help me choose?
+"""]]
diff --git a/doc/backends/comment_6_82f239b58680a2681bd8074c7ef9584d._comment b/doc/backends/comment_6_82f239b58680a2681bd8074c7ef9584d._comment
new file mode 100644
index 0000000000..cbd4682ab2
--- /dev/null
+++ b/doc/backends/comment_6_82f239b58680a2681bd8074c7ef9584d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 6"
+ date="2013-11-01T15:47:26Z"
+ content="""
+Some examples of problems with the raw SHA backends include, IIRC, calibre, and many programs on OSX. These programs look at the extension of the filename the symlink points at.
+"""]]
diff --git a/doc/backends/comment_7_4aa8cfaec1090f79fed530720e4ddad4._comment b/doc/backends/comment_7_4aa8cfaec1090f79fed530720e4ddad4._comment
new file mode 100644
index 0000000000..3028547fe4
--- /dev/null
+++ b/doc/backends/comment_7_4aa8cfaec1090f79fed530720e4ddad4._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmraN_ldJplGunVGmnjjLN6jL9s9TrVMGE"
+ nickname="Ævar Arnfjörð"
+ subject="Can annex use existing backends when amending existing files?"
+ date="2014-08-05T21:35:34Z"
+ content="""
+Related to the question posed in http://git-annex.branchable.com/forum/switching_backends/ can git annex be told to use the existing backend for a given file?
+
+The use case for this is that you have an existing repo that started out e.g. with SHA256, but new files are being added with SHA256E since that's the default now.
+
+But I was doing:
+
+    git annex edit .
+    rsync /some/old/copy/ .
+    git annex add .
+
+And was expecting it to show no changes for existing files, but it did, it would be nice if that was not the case.
+"""]]
diff --git a/doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment b/doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment
new file mode 100644
index 0000000000..17ac4c2754
--- /dev/null
+++ b/doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 8"
+ date="2014-08-12T18:00:46Z"
+ content="""
+Ævar, you can use `git annex add --backend=SHA256` to temporarily override the backend.
+"""]]
diff --git a/doc/backends/comment_9_5bef7f76f5e5b73a8e404fe6172b4368._comment b/doc/backends/comment_9_5bef7f76f5e5b73a8e404fe6172b4368._comment
new file mode 100644
index 0000000000..bf8f7f8d2b
--- /dev/null
+++ b/doc/backends/comment_9_5bef7f76f5e5b73a8e404fe6172b4368._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm_YXzEdPHzbSGVwtmTR7g1BqDtTnIBB5s"
+ nickname="Matthias"
+ subject="Over-long pathnames?"
+ date="2015-01-06T09:41:03Z"
+ content="""
+the SHA* backends generate too-complicated paths:
+
+lrwxrwxrwx 1 root root 193 Apr 22  2009 test.ogg -> ../../../.git/annex/objects/fX/pz/SHA256-s71983--4a55ff578b4c592c06a1f4d9e0f8a6949ea9961d9717fc22e7b3c412620ac890/SHA256-s71983--4a55ff578b4c592c06a1f4d9e0f8a6949ea9961d9717fc22e7b3c412620ac890
+
+I don't want the additional directory. What is it for?? It contains exactly one file and adds a couple of disk seeks to file lookup.
+"""]]
diff --git a/doc/bare_repositories.mdwn b/doc/bare_repositories.mdwn
new file mode 100644
index 0000000000..f73f2f845a
--- /dev/null
+++ b/doc/bare_repositories.mdwn
@@ -0,0 +1,53 @@
+Due to popular demand, git-annex can now be used with bare repositories.
+
+So, for example, you can stash a file away in the origin:
+`git annex move mybigfile --to origin`
+
+Of course, for that to work, the bare repository has to be on a system with
+[[git-annex-shell]] installed. If "origin" is on GitWeb, you still can't
+use git-annex to store stuff there.
+
+It took a while, but bare repositories are now supported exactly as well
+as non-bare repositories. Except for these caveats:
+
+* `git annex fsck` works in a bare repository, but does not display
+  warnings about insufficient
+  [[copies]]. To get those warnings, just run it in one of the non-bare
+  checkouts.
+* `git annex unused` in a bare repository only knows about keys used in
+  branches that have been pushed to the bare repository. So use it with care..
+* Commands that need a work tree, like `git annex add` won't work in a bare
+  repository, of course.
+* However, you can run commands like `git annex copy`, `git annex get`, and
+  `git annex drop` in a bare repository. In a bare repository, these
+  behave as if the `--all` option were used, and so operate
+  on every single version of every single file that is present in the git
+  repository history. The `--branch` option can be used to make these
+  commands only operate on the files referenced by a specified branch.  
+  For example: `git annex get --branch master`
+
+***
+
+Here is a quick example of how to set this up, using `origin` as the remote name, and assuming `~/annex` contains an annex:
+
+On the server:
+
+    git init --bare bare-annex.git
+    cd bare-annex.git && git annex init origin
+
+Now configure the remote and do the initial push:
+
+    cd ~/annex
+    git remote add origin example.com:bare-annex.git
+    git push origin master git-annex
+
+Now `git annex info` should show the configured bare remote. If it does
+not, you may have to pull from the remote first (older versions of
+`git-annex`).
+
+If you wish to configure git such that you can push/pull without arguments,
+set the upstream branch:
+
+    git branch master --set-upstream origin/master
+
+   
diff --git a/doc/bare_repositories/comment_1_148e1da70d37d311634a0309a4ff8dcd._comment b/doc/bare_repositories/comment_1_148e1da70d37d311634a0309a4ff8dcd._comment
new file mode 100644
index 0000000000..c1ba9f2f4a
--- /dev/null
+++ b/doc/bare_repositories/comment_1_148e1da70d37d311634a0309a4ff8dcd._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmraN_ldJplGunVGmnjjLN6jL9s9TrVMGE"
+ nickname="Ævar Arnfjörð"
+ subject="How to convert bare repositories to non-bare"
+ date="2012-11-11T20:14:44Z"
+ content="""
+I made a repository bare and later wanted to convert it, this would have worked with just plain git:
+
+    cd bare-repo.git
+    mkdir .git
+    mv .??* * .git/
+    git config --unset core.bare
+    git reset --hard
+
+But because git-annex uses different hashing directories under bare repositories all the files in the repo will point to files you don't have. Here's how you can fix that up assuming you're using a backend that assigns unique hashes based on file content (e.g. the SHA256 backend):
+
+    mv .git/annex/objects from-bare-repo
+    git annex add from-bare-repo
+    git rm -f from-bare-repo
+
+
+"""]]
diff --git a/doc/bare_repositories/comment_2_c88216da0588562c851c2ceabbfebc0a._comment b/doc/bare_repositories/comment_2_c88216da0588562c851c2ceabbfebc0a._comment
new file mode 100644
index 0000000000..4350407037
--- /dev/null
+++ b/doc/bare_repositories/comment_2_c88216da0588562c851c2ceabbfebc0a._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/814e4910-8e9b-4fe5-83ef-ff863c1a7314"
+ nickname="BehemothTheCat"
+ subject="push fails"
+ date="2015-02-14T00:11:40Z"
+ content="""
+These instructions don't work for me, unfortunately.
+
+This step:
+
+    git push origin master git-annex
+
+results in:
+
+    To ssh://my.server.com/home/itz/git/annex.git
+     ! [rejected]        git-annex -> git-annex (non-fast-forward)
+    error: failed to push some refs to 'ssh://my.server.com/home/itz/git/annex.git'
+    hint: Updates were rejected because a pushed branch tip is behind its remote
+    hint: counterpart. Check out this branch and integrate the remote changes
+    hint: (e.g. 'git pull ...') before pushing again.
+    hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+
+Versions: git 1:1.9.1-1~bpo70+2 , git-annex 5.20141024~bpo70+1 (both packaged by Debian, same on local and remote)
+
+And yes, I did a pull on the master branch first.  Afraid to do anything
+with the git-annex branch without explicit instruction.
+
+"""]]
diff --git a/doc/bare_repositories/comment_3_26ba93bddb0cd1bb4e1799311f3ca750._comment b/doc/bare_repositories/comment_3_26ba93bddb0cd1bb4e1799311f3ca750._comment
new file mode 100644
index 0000000000..b20ce0be83
--- /dev/null
+++ b/doc/bare_repositories/comment_3_26ba93bddb0cd1bb4e1799311f3ca750._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-02-17T21:54:33Z"
+ content="""
+Since the two repos git-annex branches have diverged, you need to run `git
+annex merge` to merge them before you can push that branch.
+
+Of course, `git annex sync` handles all that for you. It can be used
+against a bare repository as well as a non-bare.
+"""]]
diff --git a/doc/bare_repositories/comment_4_7cf6103709a7a2710686681a6f406214._comment b/doc/bare_repositories/comment_4_7cf6103709a7a2710686681a6f406214._comment
new file mode 100644
index 0000000000..0953d091f0
--- /dev/null
+++ b/doc/bare_repositories/comment_4_7cf6103709a7a2710686681a6f406214._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7"
+ nickname="Frederik Vanrenterghem"
+ subject="Convert bare repository to normal"
+ date="2015-05-19T09:17:15Z"
+ content="""
+Just wondering what the right steps are to convert a bare repository to a normal one? The comment above from 2.5 years ago includes the creation of a .git directory, which actually already exists. Have things changed in the mean time?
+"""]]
diff --git a/doc/bare_repositories/comment_5_6328134497c0de6a088087fc9cb0e59e._comment b/doc/bare_repositories/comment_5_6328134497c0de6a088087fc9cb0e59e._comment
new file mode 100644
index 0000000000..80906857ed
--- /dev/null
+++ b/doc/bare_repositories/comment_5_6328134497c0de6a088087fc9cb0e59e._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 5"
+ date="2015-05-19T12:18:05Z"
+ content="""
+Well, no, i don't think they changed, unless i missed something: there
+shouldn't be a `.git` repository there.
+
+There are [various
+instructions](http://stackoverflow.com/questions/10637378/how-do-i-convert-a-bare-git-repository-into-a-normal-one-in-place)
+on how to do this online. They do seem to agree with the first comment
+above.
+
+Personnally, I would just `git clone` to a different repo and `git
+annex forget` the old one. Unless you have a very complex repository
+with a lot of files, this is simple enough... You could even use `git
+annex reinit` to recycle the previous uuid if that's a concern. So in
+short:
+
+   git clone repo.git repo
+   cd repo
+   git annex info --fast # find the UUID of repo.git
+   git annex move --from $UUID
+   git annex reinit $UUID
+
+Then `repo.git` can be removed if you are certain everything is
+correct in `repo`.
+
+Note that you may want to have backups of everything before you do
+anything, as usual.
+"""]]
diff --git a/doc/bare_repositories/comment_6_bf227861ec3cb2ea474c143218c68133._comment b/doc/bare_repositories/comment_6_bf227861ec3cb2ea474c143218c68133._comment
new file mode 100644
index 0000000000..1a43c0a2f0
--- /dev/null
+++ b/doc/bare_repositories/comment_6_bf227861ec3cb2ea474c143218c68133._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7"
+ nickname="Frederik Vanrenterghem"
+ subject="comment 6"
+ date="2015-05-21T06:14:33Z"
+ content="""
+Thanks Anarcat. I actually was dealing with a repository in direct mode, not bare mode. Only realised after today encountering one in bare mode, and reading [[internals]]. Your method worked too, but
+
+    git annex indirect 
+
+would have been quicker I guess.
+"""]]
diff --git a/doc/bare_repositories/comment_7_9e065a2d8aaf7371ab7c0bb4f0c724b0._comment b/doc/bare_repositories/comment_7_9e065a2d8aaf7371ab7c0bb4f0c724b0._comment
new file mode 100644
index 0000000000..c21b67f095
--- /dev/null
+++ b/doc/bare_repositories/comment_7_9e065a2d8aaf7371ab7c0bb4f0c724b0._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="scottgorlin@a32946b2aad278883c1690a0753241583a9855b9"
+ nickname="scottgorlin"
+ avatar="http://cdn.libravatar.org/avatar/2dd1fc8add62bbf4ffefac081b322563"
+ subject="synced/* branches necessary on bare repo?"
+ date="2016-10-18T21:17:40Z"
+ content="""
+Are the synced/* branches necessary for a bare repo?  Since there is no working directory, can't sync operate directly on the top level branches of choice, and avoid 'branch pollution'?  Is it implemented this way just to simplify the code, or ...?
+
+Also wondering if there is a practical difference between a bare repo and an rsync repo (other than storing the metadata, of course) - they both use rsync for transfer, no?  Any speed/overhead/other differences to consider when choosing?
+
+For my use case pertaining to question 2 I am using a local ARM NAS which works with the binary (plus S3 or gdrive remotes etc), but I figure why not spin up a private gitlab repo with metadata and no content since I want an off-site backup of the metadata anyways.  Does a bare repo on a nas add anything here, vs an rsync remote?  Perhaps just rsync is even better to avoid overhead on a tiny/slow NAS?
+"""]]
diff --git a/doc/bare_repositories/comment_8_d4dff0d6265be941af9f66ba09f36ebe._comment b/doc/bare_repositories/comment_8_d4dff0d6265be941af9f66ba09f36ebe._comment
new file mode 100644
index 0000000000..d237d1bf62
--- /dev/null
+++ b/doc/bare_repositories/comment_8_d4dff0d6265be941af9f66ba09f36ebe._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2016-10-26T17:44:55Z"
+ content="""
+@scottgorlin bare git repositories cannot in general be detected when
+looking at a remote, so `git annex sync` picks a behavior that works
+whether a remote is a bare git repository or not.
+
+A bare repo and a rsync special remote should have pretty similar
+performance.
+"""]]
diff --git a/doc/bugs.mdwn b/doc/bugs.mdwn
new file mode 100644
index 0000000000..cca00b8907
--- /dev/null
+++ b/doc/bugs.mdwn
@@ -0,0 +1,11 @@
+This is git-annex's bug list.
+
+To mark a bug as closed add \[\[done\]\] to the end of the original bug description. Closed bugs are moved to [[done]].
+
+[[!inline pages="(./bugs/* or tagged(forum/forumbug)) and !./bugs/*/* and !./bugs/done and !link(done) 
+and !./bugs/moreinfo and !./bugs/confirmed and !./bugs/forwarded and !./bugs/duplicate
+and !*/Discussion"
+actions=yes postform=yes postformtext="Report a new bug titled:" show=0 archive=yes
+feedlimit=10 template=buglist]]
+
+[[!edittemplate template=templates/bugtemplate match="bugs/*" silent=yes]]
diff --git a/doc/bugs/--git-dir_and_--work-tree_separation_issue.mdwn b/doc/bugs/--git-dir_and_--work-tree_separation_issue.mdwn
new file mode 100644
index 0000000000..b45b80ee34
--- /dev/null
+++ b/doc/bugs/--git-dir_and_--work-tree_separation_issue.mdwn
@@ -0,0 +1,99 @@
+### Please describe the problem.
+
+When `--git-dir` and `--work-tree` deviate from standard, running commands like `git annex list` fails in untracked directories.
+
+### What steps will reproduce the problem?
+
+- see transcript below
+- separate `--git-dir` and `--work-tree` as commonly used to track one's dotfiles
+- run `git annex list` in an untracked directory
+- error is `error: pathspec 'DIRECTORY' did not match any file(s) known to git`
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20230627-g2469720e1
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
++ set -x
++ chmod +w -R .dotfiles
++ rm -rf .dotfiles
++ git init --bare .dotfiles
+Initialized empty Git repository in /home/yann2/.dotfiles/
++ alias 'dit=git --work-tree=$HOME --git-dir=$HOME/.dotfiles'
++ echo '*' > .gitignore
++ git --work-tree=/home/yann2 --git-dir=/home/yann2/.dotfiles add -f .gitignore
++ git --work-tree=/home/yann2 --git-dir=/home/yann2/.dotfiles commit -m 'add gitignore'
+[main (root-commit) 65d21e1] add gitignore
+ 1 file changed, 1 insertion(+)
+ create mode 100644 .gitignore
++ git --work-tree=/home/yann2 --git-dir=/home/yann2/.dotfiles annex init
+init  ok
+(recording state in git...)
++ mkdir dir1
++ cd dir1
++ git --work-tree=/home/yann2 --git-dir=/home/yann2/.dotfiles annex list
+here
+|web
+||bittorrent
+|||
+Did you forget to 'git add'?
+list: 1 failed
++ touch myfile
++ git --work-tree=/home/yann2 --git-dir=/home/yann2/.dotfiles annex add --no-check-gitignore myfile
+add myfile 
+ok
+(recording state in git...)
++ git --work-tree=/home/yann2 --git-dir=/home/yann2/.dotfiles annex sync -m 'add file in dir1'
+git-annex sync will change default behavior to operate on --content in a future version of git-annex. Recommend you explicitly use --no-content (or -g) to prepare for that change. (Or you can configure annex.synccontent)
+commit  
+[main da84a6c] add file in dir1
+ 1 file changed, 1 insertion(+)
+ create mode 120000 dir1/myfile
+ok
++ git --work-tree=/home/yann2 --git-dir=/home/yann2/.dotfiles annex list
+here
+|web
+||bittorrent
+|||
+X__ myfile
++ cd
++ git --work-tree=/home/yann2 --git-dir=/home/yann2/.dotfiles annex list
+here
+|web
+||bittorrent
+|||
+X__ dir1/myfile
++ mkdir dir2
++ cd dir2
++ git --work-tree=/home/yann2 --git-dir=/home/yann2/.dotfiles annex list
+here
+|web
+||bittorrent
+|||
+error: pathspec 'dir2/' did not match any file(s) known to git
+Did you forget to 'git add'?
+list: 1 failed
++ git --work-tree=/home/yann2 --git-dir=/home/yann2/.dotfiles -C /home/yann2 annex list
+here
+|web
+||bittorrent
+|||
+X__ dir1/myfile
++ git --work-tree=/home/yann2 --git-dir=/home/yann2/.dotfiles -C / annex list
+here
+|web
+||bittorrent
+|||
+X__ dir1/myfile
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yep, git-annex is awesome! 🥳
+
diff --git a/doc/bugs/--git-dir_and_--work-tree_separation_issue/comment_1_fa97996b85c0f949bbd720204db8ed46._comment b/doc/bugs/--git-dir_and_--work-tree_separation_issue/comment_1_fa97996b85c0f949bbd720204db8ed46._comment
new file mode 100644
index 0000000000..8d5ebdfafe
--- /dev/null
+++ b/doc/bugs/--git-dir_and_--work-tree_separation_issue/comment_1_fa97996b85c0f949bbd720204db8ed46._comment
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-09-13T16:46:35Z"
+ content="""
+I reproduced the behavior you showed.
+
+But git behaves the same way in the same situation. Compare these two commands:
+
+	joey@darkstar:~/tmp/bench/dir2>git --work-tree=/home/joey/tmp/bench --git-dir=/home/joey/tmp/bench/.dotfiles annex list
+	here
+	|web
+	||bittorrent
+	|||
+	error: pathspec 'dir2/' did not match any file(s) known to git
+	Did you forget to 'git add'?
+	list: 1 failed
+
+	joey@darkstar:~/tmp/bench/dir2>git --git-dir=../.git --work-tree=.. ls-files --stage --error-unmatch --
+	error: pathspec 'dir2/' did not match any file(s) known to git
+	Did you forget to 'git add'?
+
+The second command is actually what the first command runs internally.
+
+Also, the behavior does not have anything to do with --git-dir and --work-tree:
+
+	joey@darkstar:~/tmp/bench>git init repo
+	Initialized empty Git repository in /home/joey/tmp/bench/repo/.git/
+	joey@darkstar:~/tmp/bench>cd repo
+	joey@darkstar:~/tmp/bench/repo>git-annex init
+	init  ok
+	m(recording state in git...)
+	joey@darkstar:~/tmp/bench/repo>mkdir dir2
+	joey@darkstar:~/tmp/bench/repo>cd dir2
+	joey@darkstar:~/tmp/bench/repo/dir2>git-annex list
+	here
+	|web
+	||bittorrent
+	|||
+	error: pathspec 'dir2/' did not match any file(s) known to git
+	Did you forget to 'git add'?
+	list: 1 failed
+
+So if there's a bug here, it's that `git-annex list` displays an error message
+when run in a subdirectory that does not contain any files tracked by git.
+
+Also, many other git-annex commands run `git ls-files --error-unmatch`
+and so behave the same when run in such a subdirectory. Including whereis, find,
+get, etc.
+
+In fact, annex.skipunknown controls whether `--error-unmatch` is used.
+Setting it to true will avoid this behavior. But there were good reasons to
+change the annex.skipunknown default to false. And good reasons to use 
+`--error-unmatch` to implement that.
+
+Also, this behavior is somewhat documented, in the documentation of annex.skipunknown,
+it specifically talks about the case where no files in the current (or specified) 
+directory are tracked by git.
+
+So in my opinion, this does not seem like a bug.
+"""]]
diff --git a/doc/bugs/10.20220525_cannot_probe_for_untrusted_remote_key.mdwn b/doc/bugs/10.20220525_cannot_probe_for_untrusted_remote_key.mdwn
new file mode 100644
index 0000000000..499a732e69
--- /dev/null
+++ b/doc/bugs/10.20220525_cannot_probe_for_untrusted_remote_key.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+10.20220525 forcefully untrusts `exporttree=yes`, causing `fsck` to unconditionally fail when probing for a key that only exists on such a remote.
+
+The full story is at https://github.com/datalad/datalad-next/issues/72
+
+The summary is that an application needs to know whether a particular key is on such a remote, and it can only be on that remote (there is no other). Because the availability info from `whereis` cannot be trusted (same rational as the one causing the change in git-annex implementation) it uses `annex fsck --fast --key -f ...` which now fails.
+
+Parsing the JSON output of the failing `fsck` call seems to be the only way left to accomplish this goal.
+
+```
+% git -C myclone/.git/dl-repoannex/origin/repoannex -c diff.ignoreSubmodules=none annex fsck -f origin --fast --key XDLRA--refs -c annex.dotfiles=true --json
+  Only these untrusted locations may have copies of XDLRA--refs
+        d8735795-663e-4702-8f7e-8c684264a9df -- [origin]
+  Back it up to trusted locations with git-annex copy.
+{"dead":[],"command":"fsck","note":"(Avoid this check by running: git annex dead --key )","success":false,"input":[],"untrusted":[{"here":false,"uuid":"d8735795-663e-4702-8f7e-8c684264a9df","description":"[origin]"}],"key":"XDLRA--refs","error-messages":[],"file":null}
+fsck: 1 failed
+```
+
+That however, is substantially more complex than looking at the exit code -- given that the entire call is about a single key.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+99.9% are just splendid. Wondering here whether this particular consequence of the change was intentional and avoidable?
+
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/10.20220525_cannot_probe_for_untrusted_remote_key/comment_1_e35bef8fb0b9a40938022c43c87df597._comment b/doc/bugs/10.20220525_cannot_probe_for_untrusted_remote_key/comment_1_e35bef8fb0b9a40938022c43c87df597._comment
new file mode 100644
index 0000000000..5df59eb22b
--- /dev/null
+++ b/doc/bugs/10.20220525_cannot_probe_for_untrusted_remote_key/comment_1_e35bef8fb0b9a40938022c43c87df597._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-06-09T17:19:07Z"
+ content="""
+That was a fix for an old reversion, so trying to use fsck for that would
+have also failed before 8.20201129.
+
+Fsck is not the right tool for the job. Fscking can fail for any of a
+variety of reasons, including probably reasons that have not been thought
+of or implemented yet, so taking failure to mean only one possible thing is
+doomed.
+
+A better tool exists: `git-annex checkpresentkey`
+"""]]
diff --git a/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows.mdwn b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows.mdwn
new file mode 100644
index 0000000000..ae1f7c5229
--- /dev/null
+++ b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows.mdwn
@@ -0,0 +1,5 @@
+Having a windows build of Git-Annex in an archived format would be very usefull for automation, and deploy.
+Could it be possible to add this to the buildserver of gitannex?
+
+[[!tag moreinfo]]
+
diff --git a/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_1_70480ffd417788f18cd75a9b625ecf3b._comment b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_1_70480ffd417788f18cd75a9b625ecf3b._comment
new file mode 100644
index 0000000000..3bd7381e16
--- /dev/null
+++ b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_1_70480ffd417788f18cd75a9b625ecf3b._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-16T18:41:25Z"
+ content="""
+It would be helpful to have more details, such as an example of software
+distributed for windows that way, or documentation of how such an archive
+is used on windows.
+
+The git-annex Windows installer is a exe file that uses the NullSoft
+installation system. As far as I know that's pretty common in the Windows
+world.
+
+I don't see any point in zipping up the single exe. It would be possible to
+make a zip containing all the files that instlling the exe installs. But,
+the installation process has to integrate git-annex with git, it installs
+menu items, etc. A zip file would not be able to handle that integration.
+So its use seems limited to me.
+"""]]
diff --git a/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_2_afa6a131999feda67876859cd85ebcfc._comment b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_2_afa6a131999feda67876859cd85ebcfc._comment
new file mode 100644
index 0000000000..b0db544798
--- /dev/null
+++ b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_2_afa6a131999feda67876859cd85ebcfc._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="luckcolorsgoo@ab4f3c1c44a7dbcbcb9d9a29315b59ad524ceaaa"
+ nickname="luckcolorsgoo"
+ avatar="http://cdn.libravatar.org/avatar/ddff84cd2a97252a05cccb4bc5010448"
+ subject="comment 2"
+ date="2016-11-16T22:56:46Z"
+ content="""
+In my case i was going to make a script for automatically downloading and updating an git portbale / git annex instance, by first fetching git portbale and then downloading the gitannex exe.
+
+So yeah it's more reliable to extract an archive rather than trying to extract the setup without executing it.
+That's why i'm asking for this feature. :)
+
+
+
+"""]]
diff --git a/doc/bugs/Adjust_--unlock_not_using_--reflink__63__.mdwn b/doc/bugs/Adjust_--unlock_not_using_--reflink__63__.mdwn
new file mode 100644
index 0000000000..ad2187ae8b
--- /dev/null
+++ b/doc/bugs/Adjust_--unlock_not_using_--reflink__63__.mdwn
@@ -0,0 +1,20 @@
+### Please describe the problem.
+
+Running adjust --unlock is unexpectedly slow and seems to use a lot of space, even on BTRFS, suggesting it probably does not use --reflink=auto like most other commands.
+
+### What steps will reproduce the problem?
+
+Run adjust --unlock with very large files.
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170101-1+deb9u1 on Debian Stretch
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes I have! I've used it manage lots of video editing disks before, and am now migrating several slightly different copies of 15TB sized documentary footage from random USB3 disks and LTO tapes to a RAID server with BTRFS.
+
+> Yay, this got fixed some time ago, by making the smudge filter not output
+> the file content at all, but instead the link, and having a git hook
+> later run git-annex to populate the files, which it does use reflink for
+> when possible. [[done]] --[[Joey]]
diff --git a/doc/bugs/Adjust_--unlock_not_using_--reflink__63__/comment_1_c42743828ddc62f7df7f612c713ee309._comment b/doc/bugs/Adjust_--unlock_not_using_--reflink__63__/comment_1_c42743828ddc62f7df7f612c713ee309._comment
new file mode 100644
index 0000000000..e30471b84c
--- /dev/null
+++ b/doc/bugs/Adjust_--unlock_not_using_--reflink__63__/comment_1_c42743828ddc62f7df7f612c713ee309._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-12-05T17:24:24Z"
+ content="""
+What happens is `git annex adjust` creates a branch and runs `git checkout`
+to check it out. Then git calls `git-annex smudge` on files, and
+unfortunately the git smudge interface requires that git-annex output the
+whole content of the file, to stdout, which git then writes to disk.
+
+So yes, this doesn't use reflinks, but it's worse than that, a better
+interface would let git-annex simply move or hard-link the file into place,
+even on filesystems not supporting reflinks.
+
+This is discussed in detail in [[todo/smudge]]. Unfortunately it will need
+a better interface in git to be addressed, and that's why v6 is still an
+experimental feature.
+"""]]
diff --git a/doc/bugs/Always_identical_UUIDs.mdwn b/doc/bugs/Always_identical_UUIDs.mdwn
new file mode 100644
index 0000000000..988d5cf585
--- /dev/null
+++ b/doc/bugs/Always_identical_UUIDs.mdwn
@@ -0,0 +1,89 @@
+### Please describe the problem.
+If I do `git annex init`, I consistently get the same UUID's which messes up lots of remote transfers
+
+### What steps will reproduce the problem?
+If I do `git annex init` on my system and then `git annex info`, it always shows 
+```
+trusted repositories: 0
+semitrusted repositories: 3
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        5df76b66-a137-4b11-bc65-316ee27d52b7 -- :CURRENTPATH [here]
+```
+(where currentpath is the path of the git annex repo). It's always 5df
+
+### What version of git-annex are you using? On what operating system?
+I used the downloaded version, as well as recompiled this morning
+```
+git-annex version: 10.20230322-ga91f8070e7
+build flags: Assistant Webapp Pairing Inotify TorrentParser Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 9
+```
+
+### Please provide any additional information below.
+I also don't get anything from
+`git config --local annex.uuid` so tried to add a manual UUID, but it starts to feel overly hacky when dealing with critical data
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Git annex is great, I use it to manage 3TB+ of research data, and it's useful for manually keeping data in track and versioned
+
+
+
+### Please describe the problem.
+If I do `git annex init`, I consistently get the same UUID's which messes up lots of remote transfers
+
+### What steps will reproduce the problem?
+If I do `git annex init` on my system and then `git annex info`, it always shows 
+```
+trusted repositories: 0
+semitrusted repositories: 3
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        5df76b66-a137-4b11-bc65-316ee27d52b7 -- :CURRENTPATH [here]
+```
+(where currentpath is the path of the git annex repo). It's always 5df
+
+### What version of git-annex are you using? On what operating system?
+I used the downloaded version, as well as recompiled this morning
+```
+git-annex version: 10.20230322-ga91f8070e7
+build flags: Assistant Webapp Pairing Inotify TorrentParser Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 9
+```
+
+### Please provide any additional information below.
+I also don't get anything from
+`git config --local annex.uuid` so tried to add a manual UUID, but it starts to feel overly hacky when dealing with critical data
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Git annex is great, I use it to manage 3TB+ of research data, and it's useful for manually keeping data in track and versioned
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Always_identical_UUIDs/comment_1_1223fe5e635d771848d7054f0492920f._comment b/doc/bugs/Always_identical_UUIDs/comment_1_1223fe5e635d771848d7054f0492920f._comment
new file mode 100644
index 0000000000..6371df9f78
--- /dev/null
+++ b/doc/bugs/Always_identical_UUIDs/comment_1_1223fe5e635d771848d7054f0492920f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-28T18:09:26Z"
+ content="""
+What CPU is this happening with?
+
+git-annex generates uuids using <https://hackage.haskell.org/package/uuid>
+and the V4 uuid uses <https://hackage.haskell.org/package/entropy>,
+which in turn uses RDRAND when available. 
+
+So if your CPU supports RDRAND, it seems the CPU must have a broken
+random number generator! Or there's a bug in that software stack
+somewhere.
+"""]]
diff --git a/doc/bugs/Always_identical_UUIDs/comment_2_6c44232cac847f6160f5bec7c8f1434b._comment b/doc/bugs/Always_identical_UUIDs/comment_2_6c44232cac847f6160f5bec7c8f1434b._comment
new file mode 100644
index 0000000000..32839257cf
--- /dev/null
+++ b/doc/bugs/Always_identical_UUIDs/comment_2_6c44232cac847f6160f5bec7c8f1434b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-03-28T18:25:30Z"
+ content="""
+> I also don't get anything from `git config --local annex.uuid`
+
+Do you mean you don't get anything different? Surely that outputs
+something. Or exits with a nonzero exit code.
+"""]]
diff --git a/doc/bugs/Always_identical_UUIDs/comment_3_cdb2eec514bcf125b7f79c7be5ed810a._comment b/doc/bugs/Always_identical_UUIDs/comment_3_cdb2eec514bcf125b7f79c7be5ed810a._comment
new file mode 100644
index 0000000000..40c2a1d16d
--- /dev/null
+++ b/doc/bugs/Always_identical_UUIDs/comment_3_cdb2eec514bcf125b7f79c7be5ed810a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-03-28T18:26:52Z"
+ content="""
+If you're able to run ghci, here's how to generate a UUID the same way
+git-annex does:
+
+ghci -e 'import Data.UUID.V4' -e nextRandom
+
+And here's how to get entropy the same way that does:
+
+ghci -e 'System.Entropy.getEntropy 16'
+"""]]
diff --git a/doc/bugs/Android__44___unable_to_start_browser_.mdwn b/doc/bugs/Android__44___unable_to_start_browser_.mdwn
new file mode 100644
index 0000000000..a90741bb02
--- /dev/null
+++ b/doc/bugs/Android__44___unable_to_start_browser_.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+When launching git annex webapp in Termux the browser does not open.
+
+
+### What steps will reproduce the problem?
+
+git-annex is installed in android termux according to installation instructions
+I execute the "git annex webapp" command in termux and I get this error:
+Launching web browser on http://127.0.0.1:59394/........
+/data/data/com.termux/files/usr/bin/am: 4: exec: /system/bin/app_process: Operation not permitted
+
+So the browser does not automatically open with the webapp.
+If I manually open the browser and I copy-paste the url to it, then it works.
+
+
+### What version of git-annex are you using? On what operating system?
+7.20190219-g728228d5d for android
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Not yet: I tried to use it some years ago to handle my photo collection but I think digikam didn't like the sim links and it was very slow; I also was not lucky with the external (NTFS) drive that I used for sync/backup.
+But I like this project so much that I frequently come back to check for updates and test myself with it.
diff --git a/doc/bugs/Android__44___unable_to_start_browser_/comment_1_1fc9d5168fec0b277b5ab5321c07385f._comment b/doc/bugs/Android__44___unable_to_start_browser_/comment_1_1fc9d5168fec0b277b5ab5321c07385f._comment
new file mode 100644
index 0000000000..3d434bf11f
--- /dev/null
+++ b/doc/bugs/Android__44___unable_to_start_browser_/comment_1_1fc9d5168fec0b277b5ab5321c07385f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-03-18T17:38:40Z"
+ content="""
+git-annex uses the xdg-open command in termux to open the webapp,
+so you will probably get the same error message if you run a command like
+
+	xdg-open http://google.com/
+
+So this is a problem with termux, or perhaps something in your Android is
+preventing termux from communicating with it correctly. It's not a problem
+I can address in git-annex, so I'm going to close this bug report.
+"""]]
diff --git a/doc/bugs/Android__44___unable_to_start_browser_/comment_2_8db1f505c02fd6d4e8acc1b6bbded03f._comment b/doc/bugs/Android__44___unable_to_start_browser_/comment_2_8db1f505c02fd6d4e8acc1b6bbded03f._comment
new file mode 100644
index 0000000000..0c709d2f16
--- /dev/null
+++ b/doc/bugs/Android__44___unable_to_start_browser_/comment_2_8db1f505c02fd6d4e8acc1b6bbded03f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Fabio"
+ avatar="http://cdn.libravatar.org/avatar/2bf56b78ae28b64d6131ba3115df238b"
+ subject="no problem with xdg-open"
+ date="2019-03-20T21:57:00Z"
+ content="""
+I tried xdg-open http://www.google.com and it actually works fine. I also tried with xdg-open http://127.0.0.1:annexport/annexurlpath and I don't have any issue with that: the browser opens up and it shows the assistant page.
+
+Any other idea?
+"""]]
diff --git a/doc/bugs/Android__44___unable_to_start_browser_/comment_3_93e260d1cb9de25fe4e2a6a973f05da6._comment b/doc/bugs/Android__44___unable_to_start_browser_/comment_3_93e260d1cb9de25fe4e2a6a973f05da6._comment
new file mode 100644
index 0000000000..332f68cf62
--- /dev/null
+++ b/doc/bugs/Android__44___unable_to_start_browser_/comment_3_93e260d1cb9de25fe4e2a6a973f05da6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-03-22T13:42:43Z"
+ content="""
+Reopened the bug since you confirmed xdg-open usually works.
+
+Why is it failing when git-annex runs it but not otherwise?
+Perhaps it has something to do with the environment set up by runshell.
+"""]]
diff --git a/doc/bugs/Android__58___Several_error_messages___47___warnings.mdwn b/doc/bugs/Android__58___Several_error_messages___47___warnings.mdwn
new file mode 100644
index 0000000000..c6085c21ab
--- /dev/null
+++ b/doc/bugs/Android__58___Several_error_messages___47___warnings.mdwn
@@ -0,0 +1,38 @@
+### Please describe the problem.
+
+When I start Git Annex then there are several warnings. The app renders my phone basically unusable (two time my phone rebooted and several time I had to remove the battery because the phone didn't respond).
+
+It seems Git Annex uses all the available memory (one warning is that git-annex has text relocations and that this wastes memory.
+
+I've attached a screen shot of the error messages.
+
+
+### What steps will reproduce the problem?
+
+Starting Git Annex on my phone
+
+
+### What version of git-annex are you using? On what operating system?
+
+Git Annex: 5.20150927-gb506fb2
+Android: 5.0.2
+
+
+### Please provide any additional information below.
+
+My phone is low-end (it has only ~512MB memory for example) - but normally everything works more or less okay.
+
+If I use Chrome as the browser and start the webapp then Git Annex gets (it seems) killed quite often. It seems because there is not enough memory.
+
+If I use a browser with a small memory footprint then the webapp works only barely better - very unresponsive (but at least Git Annex isn't killed).
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sorry, no, I'm just starting out with Git Annex :)
+
+But Git Annex looks amazing - exactly what I need! ;)
+
+Can I somehow help to find the problem?
+
+I'd really love to use Git Annex on my phone.
diff --git a/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_1_85da61d3dfb528fef17366effe123ff5._comment b/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_1_85da61d3dfb528fef17366effe123ff5._comment
new file mode 100644
index 0000000000..92a19534a2
--- /dev/null
+++ b/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_1_85da61d3dfb528fef17366effe123ff5._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-29T15:27:20Z"
+ content="""
+I don't think that the warning about text relocations is a significant
+source of memory usage.
+
+It would probably help if you can get some memory use value for git-annex
+while it's running, and for chrome after it's loaded the git-annex webapp.
+These are two separate uses of memory, and it's not clear which one is
+actually using up too much of your memory.
+
+I've run git-annex on android systems that are smaller than 512 mb, and
+generally the assistant only uses a few MB of memory on other platforms.
+"""]]
diff --git a/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_2_97ddaba23e91a903f69cf00931627444._comment b/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_2_97ddaba23e91a903f69cf00931627444._comment
new file mode 100644
index 0000000000..22aacf3062
--- /dev/null
+++ b/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_2_97ddaba23e91a903f69cf00931627444._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="dah"
+ subject="comment 2"
+ date="2015-10-04T18:25:29Z"
+ content="""
+I think the CPU of my phone is not good enough to be usable with a web browser on my phone.
+
+I can use Git Annex without the WebApp without phone stability problems. But if I start the WebApp then nothing works (it seems 100% of my CPU is used - but it could also be that the CPU monitor app did freeze).
+
+Websites like Google and Wikipedia work without problems but I had another website that made my phone unusable and forced me to restart my phone.
+
+I think therefore my phone is the problem and not Git Annex.
+
+So, the best way for me to use Git Annex on my phone is probably the cammand line interface.
+
+Besides the text relocations warning there was another message that said \"Falling back to hardcoded app location: cannot find expected files in $path\".
+
+Is this a problem or does everything work properly?
+
+
+"""]]
diff --git a/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_3_b4ea7ff7deb9626a02dfd0eb459f22a2._comment b/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_3_b4ea7ff7deb9626a02dfd0eb459f22a2._comment
new file mode 100644
index 0000000000..f63f93d147
--- /dev/null
+++ b/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_3_b4ea7ff7deb9626a02dfd0eb459f22a2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-10-04T19:27:18Z"
+ content="""
+Note that you can close the web browser and the git-annex assistant can
+still be running, and doing its thing. This might be a viable alternative
+to using the command line manually for you.
+
+The message about hardcoded app location isn't a problem if git-annex
+works.
+"""]]
diff --git a/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_4_5edddd7e90b8f11c52a44abfb891ce25._comment b/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_4_5edddd7e90b8f11c52a44abfb891ce25._comment
new file mode 100644
index 0000000000..976ead6892
--- /dev/null
+++ b/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_4_5edddd7e90b8f11c52a44abfb891ce25._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="dah"
+ subject="comment 4"
+ date="2015-10-10T19:02:56Z"
+ content="""
+
+But how would I configure git-annex assistant in this case?
+
+My plan was to somehow add the information about the repos etc. using the command line interface and then just start the assistant using 'git annex assistant --autostart' as the terminal startup command.
+
+Would that work?
+
+By the way, is there any documentation about how to use the assistant without the web interface?
+
+I could only find information about how to configure the assistant using the web app.
+
+Thanks for your help!
+
+
+"""]]
diff --git a/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_4_b38b675a2862d527fad28b7477f7ddde._comment b/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_4_b38b675a2862d527fad28b7477f7ddde._comment
new file mode 100644
index 0000000000..81e0c0fa0c
--- /dev/null
+++ b/doc/bugs/Android__58___Several_error_messages___47___warnings/comment_4_b38b675a2862d527fad28b7477f7ddde._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-10-12T17:15:30Z"
+ content="""
+The assistant will use whatever git remotes and git-annex configuration is
+present in the repository when it's started up.
+"""]]
diff --git a/doc/bugs/Android__58___addurl__58___Network.BSD.getProtocolByName__58___does_not_exist___40__no_such_protocol_name__58___tcp__41__.mdwn b/doc/bugs/Android__58___addurl__58___Network.BSD.getProtocolByName__58___does_not_exist___40__no_such_protocol_name__58___tcp__41__.mdwn
new file mode 100644
index 0000000000..d62be04014
--- /dev/null
+++ b/doc/bugs/Android__58___addurl__58___Network.BSD.getProtocolByName__58___does_not_exist___40__no_such_protocol_name__58___tcp__41__.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+Attempting to use git-annex addurl on Android 9 (Pixel 3a) fails with "ConnectionFailure Network.BSD.getProtocolByName: does not exist (no such protocol name: tcp)"
+
+To be clear, this is the installed the current way, inside of Termux. Not the obsolete apk.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+$ git-annex addurl --file "Thermopen Mk4.pdf" "http://www.thermoworks.com/pdf/thermapen_mk4_operating_instructions_a.pdf"
+addurl http://www.thermoworks.com/pdf/thermapen_mk4_operating_instructions_a.pdf
+download failed: ConnectionFailure Network.BSD.getProtocolByName: does not exist (no such protocol name: tcp)
+failed
+git-annex: addurl: 1 failed
+
+$ git-annex version
+git-annex version: 7.20190508-g8b44548d0
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux aarch64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 7
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yep, I continue to use git-annex a bunch of places. And this bug isn't a huge deal, wget followed by add worked fine.
+
diff --git a/doc/bugs/Android__58___addurl__58___Network.BSD.getProtocolByName__58___does_not_exist___40__no_such_protocol_name__58___tcp__41__/comment_1_be30193f501c530bd99e97992a9c08ad._comment b/doc/bugs/Android__58___addurl__58___Network.BSD.getProtocolByName__58___does_not_exist___40__no_such_protocol_name__58___tcp__41__/comment_1_be30193f501c530bd99e97992a9c08ad._comment
new file mode 100644
index 0000000000..023ab6730e
--- /dev/null
+++ b/doc/bugs/Android__58___addurl__58___Network.BSD.getProtocolByName__58___does_not_exist___40__no_such_protocol_name__58___tcp__41__/comment_1_be30193f501c530bd99e97992a9c08ad._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-06-26T16:26:48Z"
+ content="""
+It's looking for /etc/protocols. May be that termux provides the same
+file in some other location.
+
+It would be difficult to make the termux package use it if so, since it's
+reusing git-annex that was compiled for a standard Linux system. I don't
+think that libc provides a way to make getprotobyname read a different
+file, other than `LD_PRELOAD` open hacks.
+"""]]
diff --git a/doc/bugs/Android___58___handling_DCIM__47__Camera_not_being_configurable.mdwn b/doc/bugs/Android___58___handling_DCIM__47__Camera_not_being_configurable.mdwn
new file mode 100644
index 0000000000..a52857d1f1
--- /dev/null
+++ b/doc/bugs/Android___58___handling_DCIM__47__Camera_not_being_configurable.mdwn
@@ -0,0 +1,16 @@
+### Please describe the problem.
+
+In order to handle the fact that the directory where pictures are saved is not configurable on my phone, I set up a second git annex repository with the Repository group "file source".
+
+### What version of git-annex are you using? On what operating system?
+
+5.20140108-gce9652
+
+### Please provide any additional information below.
+
+In the log, there are many "too many open files" errors like these :
+
+git:createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files)
+
+[[!tag moreinfo]]
+[[!meta title="too many open files on android"]]
diff --git a/doc/bugs/Android___58___handling_DCIM__47__Camera_not_being_configurable/comment_1_1fe5f8c68a430b2436649cf4ba8f4987._comment b/doc/bugs/Android___58___handling_DCIM__47__Camera_not_being_configurable/comment_1_1fe5f8c68a430b2436649cf4ba8f4987._comment
new file mode 100644
index 0000000000..eea1f2094d
--- /dev/null
+++ b/doc/bugs/Android___58___handling_DCIM__47__Camera_not_being_configurable/comment_1_1fe5f8c68a430b2436649cf4ba8f4987._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="71.80.94.56"
+ subject="comment 1"
+ date="2014-02-07T18:59:29Z"
+ content="""
+I guess that this bug report is not about the DCIM/Camera location not being configurable, since that is up to Android, not git-annex. 
+
+So, it seems to be a bug report about a file descriptor leak. It would be helpful, if you can reproduce the leak, to look at /proc/$pid/fd/ to see what files git-annex has open.
+"""]]
diff --git a/doc/bugs/Android_can__39__t_sync_files_with_utf-8_characters_in_names.mdwn b/doc/bugs/Android_can__39__t_sync_files_with_utf-8_characters_in_names.mdwn
new file mode 100644
index 0000000000..b8f45e4d17
--- /dev/null
+++ b/doc/bugs/Android_can__39__t_sync_files_with_utf-8_characters_in_names.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+I have a repo where some files have utf-8 characters in their names. They are copied without problems between linux-running pcs, but on Android I only get a small, 206 bytes files with the hash data.
+
+### What steps will reproduce the problem?
+Add some files with utf-8 characters in names, try to sync to Android
+
+### What version of git-annex are you using? On what operating system?
+PC side: tried 5.20140412ubuntu1 from ubuntu repo and standalone tarball 5.20140517-gee56d21, both on Ubuntu Trusy
+Android side: Android 4.4.2 on Nexus 7
+
+### Please provide any additional information below.
+Part of daemon.log I believe is related to this. Lines starting with Number followed by dot are the filenames, but truncated at first non-ascii character.
+I suspect empty lines before the "rsync failed" represent files with names that start with non-ascii character.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+  rsync failed -- run git annex again to resume file transfer
+
+
+  rsync failed -- run git annex again to resume file transfer
+
+
+  rsync failed -- run git annex again to resume file transfer
+
+02. Wyspa W
+  rsync failed -- run git annex again to resume file transfer
+
+05. Ponad Krain
+  rsync failed -- run git annex again to resume file transfer
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/Android_can__39__t_sync_files_with_utf-8_characters_in_names/comment_1_bcc3ce19cf26731057a7f3189fcbae19._comment b/doc/bugs/Android_can__39__t_sync_files_with_utf-8_characters_in_names/comment_1_bcc3ce19cf26731057a7f3189fcbae19._comment
new file mode 100644
index 0000000000..130e4a420a
--- /dev/null
+++ b/doc/bugs/Android_can__39__t_sync_files_with_utf-8_characters_in_names/comment_1_bcc3ce19cf26731057a7f3189fcbae19._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniXLhO9mLn-7EDfawdENZ2fQwlGy5w_oc"
+ nickname="Michał"
+ subject="Update - 20140529"
+ date="2014-06-01T01:36:16Z"
+ content="""
+Tried with the new 20140529 on Android, same behavior.
+
+One more note: I managed to spot the attempted update in the webapp. The filename that shows up there has all the non-ascii characters replaced by ��� (not truncated as in logs), ex: old/������������.pdf
+"""]]
diff --git a/doc/bugs/Android_termux_install_fails_with_Bad_system_call.mdwn b/doc/bugs/Android_termux_install_fails_with_Bad_system_call.mdwn
new file mode 100644
index 0000000000..819bab56f0
--- /dev/null
+++ b/doc/bugs/Android_termux_install_fails_with_Bad_system_call.mdwn
@@ -0,0 +1,16 @@
+Following the installation instructions for termux fails on multiple
+phones (including my own) with "Bad system call" when it comes to running
+git-annex.
+
+My guess as to what has happened is that the arm64 build has been updated
+to use a newer version of glibc etc, and that is trying to use a syscall
+that the Android kernel is too old to support. (Kernel 4.19 in my phone's
+case.)
+
+Unsure when it broke, but the arm64 build is built on Debian testing
+for whatever reason, so it's will need a reasonably recent kernel. Perhaps
+there should be an equivilant of the i386-ancient build for older arm64
+systems? arm64 has by now been around as long as the Debian jessie used for
+i386-ancient. --[[Joey]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/Android_unable_to_use_external_special_remote.mdwn b/doc/bugs/Android_unable_to_use_external_special_remote.mdwn
new file mode 100644
index 0000000000..0a40642f4e
--- /dev/null
+++ b/doc/bugs/Android_unable_to_use_external_special_remote.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+I'm trying to set up the rclone special remote from [here](https://github.com/Craeckie/git-annex-remote-rclone) (a fork of the recommended that works with newer versions of rclone), for syncing across my laptop and tablet. So far, I've managed to sync everything from my laptop to the remote perfectly well, and I'm now trying to get it to work in Termux.
+
+Having added `git-annex-remote-rclone` to my `$PATH` in Termux, and having installed git-annex itself (which seems to work fine), I tried running `git annex initremote mega type=external externaltype=rclone target=mega-encrypted prefix=git-annex chunk=1MiB encryption=none rclone_layout=lower`, and was greeted (among several linker errors, which are said to be harmless) with the following:
+
+```
+Cannot run /data/data/com.termux/files/home/.git-annex/git-annex.linux/bin/git-annex-remote-rclone -- Make sure it's executable and that its dependencies are installed.
+```
+
+This is after trying to put the `git-annex-remote-rclone` shell script into a git annex internal binaries folder, though it works nowhere else in my $PATH either. I suspect this is an issue with `proot` not copying in my `$PATH` correctly, though I'm not sure how I would fix this, seeing as I can't find any documentation on how to moify the PRoot flags `git-annex` uses.
+
+### What steps will reproduce the problem?
+
+1. Download `git-annex` into Termux on Android as documented [here](https://git-annex.branchable.com/Android).
+2. Download the `git-annex-remote-rclone` folder from [here]() and place it anywhere in your `$PATH`.
+3. Run `git init && git annex init` in some directory.
+4. Run `git annex initremote test type=external externaltype=rclone target=thisdoesnotexist prefix=git-annex chunk=1MiB encryption=none rclone_layout=lower`. This should print an rclone-related error, but it prints a `git-annex` error as above.
+
+### What version of git-annex are you using? On what operating system?
+10.20220121-g0bcb94487 on Android 12 on a Samsung Galaxy Tab S6.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/anne
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I'm very new to the program, but so far I've found it excellently effective on my laptop! Thanks for a great tool!
diff --git a/doc/bugs/Android_unable_to_use_external_special_remote/comment_1_17b13329db6fb4788240428ed1e2b212._comment b/doc/bugs/Android_unable_to_use_external_special_remote/comment_1_17b13329db6fb4788240428ed1e2b212._comment
new file mode 100644
index 0000000000..aaaa2524b7
--- /dev/null
+++ b/doc/bugs/Android_unable_to_use_external_special_remote/comment_1_17b13329db6fb4788240428ed1e2b212._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-07-28T16:03:32Z"
+ content="""
+Does Android have a /bin/bash, which is in the shebang of that script? 
+You might want to try running `termux-fix-shebang` on 
+git-annex-remote-rclone, or otherwise modify it to use a shell that is
+available.
+
+You can modify git-annex.linux/runshell to change how it runs proot. The
+call to proot is right down at the end of it.
+"""]]
diff --git a/doc/bugs/Android_unable_to_use_external_special_remote/comment_2_c235675c07faaecf8e7df2d77fdac3ea._comment b/doc/bugs/Android_unable_to_use_external_special_remote/comment_2_c235675c07faaecf8e7df2d77fdac3ea._comment
new file mode 100644
index 0000000000..a08ac0a617
--- /dev/null
+++ b/doc/bugs/Android_unable_to_use_external_special_remote/comment_2_c235675c07faaecf8e7df2d77fdac3ea._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ceramic_glass"
+ avatar="http://cdn.libravatar.org/avatar/adc8ffa8bf5b777008b1fb2083df1cf0"
+ subject="comment 2"
+ date="2022-07-29T08:08:32Z"
+ content="""
+No luck with that I'm afraid, still getting the same error. I figured out the `runshell` bit, but I can run `proot git-annex-remote-rclone` with no problems, so I don't think that's the issue.
+"""]]
diff --git a/doc/bugs/Android_version_converts_plain_git_file___40__git_add__41___to_git-annex_file.mdwn b/doc/bugs/Android_version_converts_plain_git_file___40__git_add__41___to_git-annex_file.mdwn
new file mode 100644
index 0000000000..aac64a4d5a
--- /dev/null
+++ b/doc/bugs/Android_version_converts_plain_git_file___40__git_add__41___to_git-annex_file.mdwn
@@ -0,0 +1,57 @@
+### Please describe the problem.
+
+I have a README file in my repository, which is an ordinary text file added with `git add` (not `git annex add`). This seems fine with all the Linux machines, including ones running the assistant. However, when I start the assistant on Android, it converts it to an annexed file. I don't have any other direct mode repositories to check if it's a direct mode problem or an Android problem.
+
+My setup is basically a star tolopogy with a Debian GNU/Linux (jessie) box in the middle. All the clients are Debian as well, mostly testing, except for an Android tablet.
+
+### What steps will reproduce the problem?
+
+On a Linux box:
+
+    git add README
+    git commit -m 'README'
+    git annex sync --content
+
+then on Android, start git-annex and let the assistant sync.
+
+You'll get a commit like this:
+
+    $ git show 4f1c76374c75a11702c14ea6a5dbe82c99c6dd08
+    commit 4f1c76374c75a11702c14ea6a5dbe82c99c6dd08
+    Author: android <git-annex@android>
+    Date:   Wed Dec 9 15:49:01 2015 -0500
+    
+        git-annex in Smoot /sdcard/Westerley-Board
+    
+    diff --git a/Contracts/Archive/README b/Contracts/Archive/README
+    deleted file mode 100644
+    index 8fe1349..0000000
+    --- a/Contracts/Archive/README
+    +++ /dev/null
+    @@ -1,3 +0,0 @@
+    -These are old, no longer active contracts. The year is the year of
+    -archival (typically when the contract ended, or the last year covered by
+    -the contract).
+    diff --git a/Contracts/Archive/README b/Contracts/Archive/README
+    new file mode 120000
+    index 0000000..38ba43f
+    --- /dev/null
+    +++ b/Contracts/Archive/README
+    @@ -0,0 +1 @@
+    +../../.git/annex/objects/0v/9K/SHA256E-s155--d0e49ec7e493366a5afea5bc12629ba579fd8407162795c22a6346c25bafbb6e/SHA256E-s155--d0e49ec7e493366a5afea5bc12629ba579fd8407162795c22a6346c25bafbb6e
+    \ No newline at end of file
+
+### What version of git-annex are you using? On what operating system?
+
+Android is fairly recent, unfortunately the battery is currently dead
+making it hard to check :-( Must be at least 5.20151019, but probably
+20151116.
+
+### Please provide any additional information below.
+
+If needed, I'll grab the assistant log from the tablet once the battery
+is charged.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! I've been using git-annex quite a bit over the past year, for everything from my music collection to my personal files. Using it for a not-for-profit too. Even trying to get some Mac and Windows users to use it for our HOA's files. I'm looking forward to smudge mode to make direct mode work better.
diff --git a/doc/bugs/Assistant__39__s_transfer_bar_often_stuck_at_100__37___and_only_SHA_instead_of_file_content_.mdwn b/doc/bugs/Assistant__39__s_transfer_bar_often_stuck_at_100__37___and_only_SHA_instead_of_file_content_.mdwn
new file mode 100644
index 0000000000..555a2b6cfc
--- /dev/null
+++ b/doc/bugs/Assistant__39__s_transfer_bar_often_stuck_at_100__37___and_only_SHA_instead_of_file_content_.mdwn
@@ -0,0 +1,307 @@
+### Please describe the problem.
+
+I have set up a host machine and a VM with git annex assistant 'Local computer' sharing. When pairing the pairing gets stuck at 'Pairing in progress ..' and I have to manually click on 
+dashbord desite sync succeeding.
+When I modify and safe one file on the host the transfer bar gets almost always stuck
+at 100% and the respective file on the VM only shows the SHA instead of the actual content, or after some stuck transfer files simply don't get updated anymore. (Same behaviour when transferring vice versa)
+I then have to cancel the transfer and run git annex get on the VM, defeating the purpose of the annex assistant.
+
+
+### What steps will reproduce the problem?
+
+- Setup file sharing via git annex assistant 'Local computer' sharing (behaviour probably also via remote server)
+- Notice that pairing gets stuck at 'Pairing in progress..' but sync succeeds.
+- Click on Dashbord
+- Create files in the shared folder
+- Modify files alternately on both machines until status bar gets stuck at 100% for many files (around 90%-100% of times)
+- Notice that respective file on other machine contains only SHA instead of updated content or does not get updated anymore.
+
+### What version of git-annex are you using? On what operating system?
+8.20200330-7 on manjaro-kde-19.0.2-200311-linux54
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+[2020-04-15 13:48:21.7056893] main: starting assistant version 8.20200330-gdbad6c5c3
+[2020-04-15 13:48:21.718362084] Cronner: You should enable consistency checking to protect your data. 
+(scanning...) [2020-04-15 13:48:21.912322575] Watcher: Performing startup scan
+(started...) 
+Generating public/private rsa key pair.
+Your identification has been saved in /tmp/git-annex-keygenI1lLqc/key
+Your public key has been saved in /tmp/git-annex-keygenI1lLqc/key.pub
+The key fingerprint is:
+SHA256:5V7j4+jy3W/D7hT+rBExiTQcB+WDwBoIkkplPIEKbqQ alejandra@alejandra-pc
+The key's randomart image is:
++---[RSA 3072]----+
+|  ==o. . ...=+o  |
+|.+o+  . . .o.* . |
+|B.  .    o. o *  |
+|Eo      .o     + |
+|.       S . o .. |
+|         . o ....|
+|          . o oo |
+|        .  + o.=o|
+|         ++ o =*=|
++----[SHA256]-----+
+[2020-04-15 13:48:38.095033553] main: Pairing in progress
+Generating public/private rsa key pair.
+Your identification has been saved in /tmp/git-annex-keygenoF74Qa/key
+Your public key has been saved in /tmp/git-annex-keygenoF74Qa/key.pub
+The key fingerprint is:
+SHA256:lVu+FAF9gP/jGOamjGbFzXFx1uT4Hfy0GIdoDbZLwcU alejandra@alejandra-pc
+The key's randomart image is:
++---[RSA 3072]----+
+|          oB=o .o|
+|          ooBE=o+|
+|          o*o=.Bo|
+|         .o++.=o=|
+|        S..+o= .+|
+|          o.=.o  |
+|         . o.+ . |
+|        oo  + .  |
+|       o. oo     |
++----[SHA256]-----+
+[2020-04-15 13:49:57.556502118] main: Pairing in progress
+[2020-04-15 13:50:30.588506645] PairListener: Syncing with manjarobios.local_Desktop_annex 
+warning: no common commits
+From ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex
+ * [new branch]      adjusted/master(unlocked) -> manjarobios.local_Desktop_annex/adjusted/master(unlocked)
+ * [new branch]      git-annex  -> manjarobios.local_Desktop_annex/git-annex
+ * [new branch]      master     -> manjarobios.local_Desktop_annex/master
+(merging manjarobios.local_Desktop_annex/git-annex into git-annex...)
+(recording state in git...)
+(Merging into master...) Already up to date!
+Merge made by the 'recursive' strategy.
+(Merging into adjusted branch...) 
+Updating 4c91e84..6342378
+Fast-forward
+[2020-04-15 13:50:33.654970467] Pusher: Syncing with manjarobios.local_Desktop_annex 
+remote: error: cannot lock ref 'refs/heads/synced/git-annex': reference already exists        
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+ ! [remote rejected] git-annex -> synced/git-annex (failed to update ref)
+error: failed to push some refs to 'ssh://manjarobios@git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/'
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   136b79c..305df7c  master -> synced/master
+ * [new branch]      git-annex -> synced/git-annex
+From ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex
+ + 0872b3a...ed5e6fb adjusted/master(unlocked) -> manjarobios.local_Desktop_annex/adjusted/master(unlocked)  (forced update)
+Everything up-to-date
+[2020-04-15 13:54:38.785014695] Committer: Adding TestFile1.txt
+add TestFile1.txt ok
+[2020-04-15 13:54:38.846796771] Committer: Committing changes to git
+(recording state in git...)
+[2020-04-15 13:54:38.908886364] Pusher: Syncing with manjarobios.local_Desktop_annex 
+(recording state in git...)
+
+
+100%  2 B                 1 B/s 0s
+                                  
+[2020-04-15 13:54:41.563838822] Transferrer: Uploaded TestFile1.txt
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   351d3ca..c1900de  git-annex -> synced/git-annex
+   305df7c..5b93460  master -> synced/master
+[2020-04-15 13:54:47.631284311] Committer: Adding TestFile1.txt
+add TestFile1.txt ok
+[2020-04-15 13:54:47.656086205] Committer: Committing changes to git
+(recording state in git...)
+
+
+100%  17 B              986 B/s 0s
+                                  
+[2020-04-15 13:54:47.859686766] Transferrer: Uploaded TestFile1.txt
+[2020-04-15 13:54:47.93982864] Pusher: Syncing with manjarobios.local_Desktop_annex 
+(recording state in git...)
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   c1900de..46b5173  git-annex -> synced/git-annex
+   5b93460..c3dbb6f  master -> synced/master
+(merging synced/git-annex into git-annex...)
+(merging synced/git-annex into git-annex...)
+(Merging into master...) Updating c3dbb6f..3cb38cd
+Fast-forward
+ TestFile1.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+(Merging into adjusted branch...) 
+Updating e2cde79..640c290
+Fast-forward
+ TestFile1.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+[2020-04-15 13:56:23.138926931] Committer: Committing changes to git
+(recording state in git...)
+[2020-04-15 13:56:23.230412042] Pusher: Syncing with manjarobios.local_Desktop_annex 
+
+
+100%  32 B              182 B/s 0s
+                                  
+(checksum...) [2020-04-15 13:56:23.471654381] Transferrer: Downloaded TestFile1.txt
+[2020-04-15 13:56:24.67751826] Committer: Adding TestFile1.txt
+add TestFile1.txt ok
+[2020-04-15 13:56:24.692071343] Committer: Committing changes to git
+(recording state in git...)
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   46b5173..bc7da3b  git-annex -> synced/git-annex
+[2020-04-15 13:56:37.508510449] Pusher: Syncing with manjarobios.local_Desktop_annex 
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   bc7da3b..9d994e6  git-annex -> synced/git-annex
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+(Merging into master...) Updating 3cb38cd..644b2c2
+Fast-forward
+ TestFile1.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+(Merging into adjusted branch...) 
+Updating 2efdbac..3ad6997
+Fast-forward
+ TestFile1.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+[2020-04-15 13:57:26.572140658] Committer: Committing changes to git
+(recording state in git...)
+[2020-04-15 13:57:26.711267728] Pusher: Syncing with manjarobios.local_Desktop_annex 
+[2020-04-15 13:57:28.045186493] Committer: Adding TestFile1.txt
+add TestFile1.txt ok
+[2020-04-15 13:57:28.067821299] Committer: Committing changes to git
+(recording state in git...)
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   9d994e6..ac253ff  git-annex -> synced/git-annex
+   644b2c2..c0ef509  master -> synced/master
+[2020-04-15 13:57:37.205281607] Committer: Adding TestFile1.txt
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+add TestFile1.txt ok
+[2020-04-15 13:57:37.344736169] Committer: Committing changes to git
+(recording state in git...)
+
+
+100%  63 B              3 KiB/s 0s
+                                  
+[2020-04-15 13:57:37.604509822] Transferrer: Uploaded TestFile1.txt
+[2020-04-15 13:57:43.872997704] Pusher: Syncing with manjarobios.local_Desktop_annex 
+(recording state in git...)
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   ac253ff..301cec6  git-annex -> synced/git-annex
+   ffebc7f..71d50f9  master -> synced/master
+(merging synced/git-annex into git-annex...)
+(Merging into master...) Updating 71d50f9..d6fbcef
+Fast-forward
+ TextFileCreadedByVm.txt | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 TextFileCreadedByVm.txt
+(Merging into adjusted branch...) 
+Updating 6cf6158..e464f35
+Fast-forward
+ TextFileCreadedByVm.txt | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 TextFileCreadedByVm.txt
+[2020-04-15 13:58:28.922447217] Committer: Committing changes to git
+(recording state in git...)
+[2020-04-15 13:58:29.003532092] Pusher: Syncing with manjarobios.local_Desktop_annex 
+(recording state in git...)
+[2020-04-15 13:58:30.121232466] Committer: Committing changes to git
+(recording state in git...)
+(merging synced/git-annex into git-annex...)
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   301cec6..8a60331  git-annex -> synced/git-annex
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+ ! [rejected]        master -> master (fetch first)
+error: failed to push some refs to 'ssh://manjarobios@git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/'
+hint: Updates were rejected because the remote contains work that you do
+hint: not have locally. This is usually caused by another repository pushing
+hint: to the same ref. You may want to first integrate the remote changes
+hint: (e.g., 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+(Merging into master...) Updating d6fbcef..3f389fd
+Fast-forward
+ TextFileCreadedByVm.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+[2020-04-15 13:58:43.352572624] Pusher: Syncing with manjarobios.local_Desktop_annex 
+(Merging into adjusted branch...) 
+Updating 6f7e537..411e021
+Fast-forward
+ TextFileCreadedByVm.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+[2020-04-15 13:58:46.473084994] Committer: Committing changes to git
+(recording state in git...)
+[2020-04-15 13:58:47.879634494] Committer: Adding TextFileC..dByVm.txt
+add TextFileCreadedByVm.txt ok
+[2020-04-15 13:58:47.90195794] Committer: Committing changes to git
+(recording state in git...)
+(merging synced/git-annex into git-annex...)
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   8a60331..fb78a8e  git-annex -> synced/git-annex
+[2020-04-15 13:59:01.63874079] Pusher: Syncing with manjarobios.local_Desktop_annex 
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   fb78a8e..e44b5a7  git-annex -> synced/git-annex
+[2020-04-15 13:59:16.580076548] Committer: Adding TextFileC..dByVm.txt
+add TextFileCreadedByVm.txt ok
+[2020-04-15 13:59:16.602073897] Committer: Committing changes to git
+(recording state in git...)
+[2020-04-15 13:59:16.657771598] Pusher: Syncing with manjarobios.local_Desktop_annex 
+(recording state in git...)
+
+
+100%  33 B              3 KiB/s 0s
+                                  
+[2020-04-15 13:59:16.768196257] Transferrer: Uploaded TextFileC..dByVm.txt
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   e44b5a7..b2ab43f  git-annex -> synced/git-annex
+   0e228b8..16959d0  master -> synced/master
+[2020-04-15 13:59:28.352892434] Pusher: Syncing with manjarobios.local_Desktop_annex 
+(recording state in git...)
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   b2ab43f..1cddb88  git-annex -> synced/git-annex
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+(Merging into master...) Updating 16959d0..42aeae0
+Fast-forward
+ TextFileCreadedByVm.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+(Merging into adjusted branch...) 
+Updating cc589d4..8108c64
+Fast-forward
+ TextFileCreadedByVm.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+[2020-04-15 13:59:49.422226799] Committer: Adding TextFileC..dByVm.txt
+add TextFileCreadedByVm.txt ok
+[2020-04-15 13:59:49.43447346] Committer: Committing changes to git
+(recording state in git...)
+[2020-04-15 13:59:49.47331159] Pusher: Syncing with manjarobios.local_Desktop_annex 
+(merging synced/git-annex into git-annex...)
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+   1cddb88..f85dba3  git-annex -> synced/git-annex
+fd:72: hPutStr: illegal operation (handle is closed)
+(Merging into master...) Updating 42aeae0..88cba5b
+Fast-forward
+ TextFileCreadedByVm.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+To ssh://git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/
+ ! [rejected]        master -> master (non-fast-forward)
+error: failed to push some refs to 'ssh://manjarobios@git-annex-manjarobios.local-manjarobios_22_Desktop.2Fannex/~/Desktop/annex/'
+hint: Updates were rejected because a pushed branch tip is behind its remote
+hint: counterpart. Check out this branch and integrate the remote changes
+hint: (e.g. 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+fd:72: hPutStr: illegal operation (handle is closed)
+[2020-04-15 14:00:59.469617044] Committer: Adding TextFileC..dByVm.txt
+add TextFileCreadedByVm.txt (Merging into master...) Updating 88cba5b..b1c4ef8
+Fast-forward
+ TextFromVm2.txt | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 TextFromVm2.txt
+[2020-04-15 14:02:43.220016515] Committer: Adding TextFileC..dByVm.txt
+add TextFileCreadedByVm.txt 
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/Assistant__39__s_transfer_bar_often_stuck_at_100__37___and_only_SHA_instead_of_file_content_/comment_1_f88d08035baf75efa1dbbddc296b591a._comment b/doc/bugs/Assistant__39__s_transfer_bar_often_stuck_at_100__37___and_only_SHA_instead_of_file_content_/comment_1_f88d08035baf75efa1dbbddc296b591a._comment
new file mode 100644
index 0000000000..5485ee8087
--- /dev/null
+++ b/doc/bugs/Assistant__39__s_transfer_bar_often_stuck_at_100__37___and_only_SHA_instead_of_file_content_/comment_1_f88d08035baf75efa1dbbddc296b591a._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-01T17:53:57Z"
+ content="""
+I was able to reproduce the progress bar sticking at 100%. I made two local
+repos in the assistant, each a remote of the other (not using ssh), and
+added a file to one. It reached 100% fairly quickly, and then sat there
+for a minute or so, before getting unstuck.
+
+(The bug submitter's log includes "hPutStr: illegal operation (handle is
+closed)" and I did not always see that in my test. May be unrelated.)
+
+While stuck like that, I noticed that git-annex info also said the transfer
+was still in progress. So apparently transferkeys is being delayed from
+finishing the transfer for some reason.
+
+Looking at ps, I noticed that "git-annex smudge --clean -- thefile" was a
+child process of transferkeys. (The file was unlocked, and was the file I
+had just added and that it was stuck on.) This may be a red herring; I
+don't always see that when it's stuck.
+
+On a hunch, I stopped the assistant process that was running in the sibling
+repo of the one where I was adding files. So there was only a single
+assistant running, not two. That seems to have gotten rid of the delay, or
+at least most of it. It still takes around 6s longer than I would have
+expected at the end.
+
+Running transferkeys manually, and feeding it requests in its internal
+protocol, transfers happened in well under a second. It did not do any
+smudging then.
+
+My guess so far is that something about the two assistants causes a race,
+which it has to delay for a while to recover from.
+"""]]
diff --git a/doc/bugs/Assistant__39__s_transfer_bar_often_stuck_at_100__37___and_only_SHA_instead_of_file_content_/comment_2_c1b86731f0e2fe8ce70931fe4a0d1656._comment b/doc/bugs/Assistant__39__s_transfer_bar_often_stuck_at_100__37___and_only_SHA_instead_of_file_content_/comment_2_c1b86731f0e2fe8ce70931fe4a0d1656._comment
new file mode 100644
index 0000000000..16156fbcab
--- /dev/null
+++ b/doc/bugs/Assistant__39__s_transfer_bar_often_stuck_at_100__37___and_only_SHA_instead_of_file_content_/comment_2_c1b86731f0e2fe8ce70931fe4a0d1656._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-05-01T18:57:22Z"
+ content="""
+stracing transferkeys after it got stuck, it was stuck until 
+this completed:
+
+	wait4(461218, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 461218
+
+That pid was "git --git-dir=../annex2/.git --work-tree=../annex2
+--literal-pathspecs --literal-pathspecs -c core.safecrlf=false update-index
+-q --refresh -z --stdin", and it did have a git-annex smudge --clean that
+seemed stuck for a while.
+
+Then it proceeded doing this:
+
+	rename("../annex2/.git/annexindex.0/index", "../annex2/.git/index") = 0
+
+annex2 is the remote. That temp directory and the git update-index process
+says restagePointerFile is what got stuck.
+
+I managed to strace the stuck git-annex smudge --clean, and it's in a loop:
+
+	rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
+	rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
+	rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
+
+(Just before that loop, it seemed to be waiting for some
+child processes, but I didn't catch which ones they were.)
+
+After many iterations:
+
+	rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
+	rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
+	munmap(0x7f4438549000, 41947136)        = 0
+	munmap(0x7f443ad4a000, 41947136)        = 0
+	exit_group(0)                           = ?
+	+++ exited with 0 +++
+"""]]
diff --git a/doc/bugs/Assistant_crashes_with_handle_issues_-_never_works.mdwn b/doc/bugs/Assistant_crashes_with_handle_issues_-_never_works.mdwn
new file mode 100644
index 0000000000..557b87bcf2
--- /dev/null
+++ b/doc/bugs/Assistant_crashes_with_handle_issues_-_never_works.mdwn
@@ -0,0 +1,51 @@
+### Please describe the problem.
+
+I have tried to use the assistant as per archival walkthrough. I have
+
+1. Created a client drive locally
+2. Created a small archive on an attached drive
+3. Created and archive folder on the user drive
+4. Moved files into the user drive and then into the archive
+
+I very soon saw the assistant fail with errors all referencing `fd:50: hPutStr: illegal operation (handle is closed)`.
+
+As a result, transactions and syncs were often incomplete and I had to use `git` and `git annex` commands to fix things up. The behaviour I had expected based on the documentation - automated archival of files moved to the `archive` directory - **never** worked.
+
+I upgraded to the PPA that is offering the latest builds but have seen no change.
+
+I ran the built-in self-test and saw 74 failed tests.
+
+
+```sh
+
+ warning
+NetWatcherFallback crashed: fd:50: hPutStr: illegal operation (handle is closed)
+×
+ warning
+Committer crashed: fd:50: hPutStr: illegal operation (handle is closed)
+×
+ warning
+PushRetrier crashed: fd:50: hPutStr: illegal operation (handle is closed)
+```
+
+### What steps will reproduce the problem?
+
+I do not have the time to produce a repeatable test suite.
+
+### What version of git-annex are you using? On what operating system?
+
+Latest from PPA on Ubuntu 20.04 LTS current to-the-day.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+No. But I *was* very enthusiastic about the theory behind it.
diff --git a/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__.mdwn b/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__.mdwn
new file mode 100644
index 0000000000..9b40fa3869
--- /dev/null
+++ b/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__.mdwn
@@ -0,0 +1,37 @@
+### Please describe the problem.
+A couple of days ago I merged a v5 repo with an OLD one (see [1]) - both on the local drive.  I *thought* it all went relatively smoothly until I tried to find some files that existed pre-merge.
+
+**All** files from before the merge were deleted as part of the merge commit.  Fortunately, they seem to be available when I do `git annex unused`
+
+
+---
+
+Any thoughts on how I would recover the removed files?  Some have a web remote, so doing it by hand for all 300ish would be a PITA.
+
+---
+
+[1] Last commit was Dec 2013, and `.git/config` has `annex.version = 3`
+
+
+### What steps will reproduce the problem?
+
+Ah.  That's hard as I can't remember exactly what I did...  :-/
+
+1. Find an OLD repo and merge with a current one using the assistant.
+2. I *think* I used the webapp and changed repositories to the old one (that was marked as `unwanted`).
+3. I *think* I stopped and restarted the assistant a few times.  (It was a loooooong merge).
+
+### What version of git-annex are you using? On what operating system?
+
+- git-annex version: 6.20170520 (at time of merge)
+- git-annex version: 6.20170818 (currently)
+- Operating system: macOS Sierra v10.12.6
+- Installed by: homebrew
+
+### Please provide any additional information below.
+
+I suspect this is a bug that can't be reproduced easily.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+<3 <3 <3
diff --git a/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_1_27d96b639bc386132b9e74170532d749._comment b/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_1_27d96b639bc386132b9e74170532d749._comment
new file mode 100644
index 0000000000..e9dbba0ad3
--- /dev/null
+++ b/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_1_27d96b639bc386132b9e74170532d749._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="olaf"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="Similar(ish) bug reports"
+ date="2017-08-23T05:55:50Z"
+ content="""
+- [git annex sync deleted a bunch of files (not expected)](/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/)
+- [Assistant deleted file when merging](/bugs/git_annex_still_deleting_content_when_merging/)
+"""]]
diff --git a/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_2_b9a39f172115fc39fee21c8987843faa._comment b/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_2_b9a39f172115fc39fee21c8987843faa._comment
new file mode 100644
index 0000000000..c8305a4e6d
--- /dev/null
+++ b/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_2_b9a39f172115fc39fee21c8987843faa._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="olaf"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="It's the old remote..."
+ date="2017-08-23T06:03:45Z"
+ content="""
+So, looking at `git log` has a clue...
+
+The commit message is
+
+    git-annex in <OLD REPO NAME>
+
+So... I guess I've switched in the webapp to the `unwanted` repo and it's gone and deleted the files.
+
+That seems weird.  I would have thought that the type of the repo `unwanted`/`full backup`/etc. would be part of the details shared by a sync and so commands in the old repo should know that it is `unwanted`.  Somehow auto-*magic*-ally I would have hoped that `unwanted` repos would be not dominant in merges.
+
+So @joeyh should I change this bug to something about `unwanted` repos being passive aggressive? ;-)
+
+---
+
+## However...
+
+I'd still like some suggestion(s) on how to get my files back...
+
+
+"""]]
diff --git a/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_3_324213fb62c67dc9565f0e812500e046._comment b/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_3_324213fb62c67dc9565f0e812500e046._comment
new file mode 100644
index 0000000000..b26b052a7c
--- /dev/null
+++ b/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_3_324213fb62c67dc9565f0e812500e046._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 3"
+ date="2017-08-26T12:18:54Z"
+ content="""
+Related: [https://git-annex.branchable.com/bugs/Data_loss_when_copying_files_with_running_assistant/](https://git-annex.branchable.com/bugs/Data_loss_when_copying_files_with_running_assistant/)
+"""]]
diff --git a/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_4_271c48d2cf4b09c27cf47ecba7fe1a64._comment b/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_4_271c48d2cf4b09c27cf47ecba7fe1a64._comment
new file mode 100644
index 0000000000..ada2986120
--- /dev/null
+++ b/doc/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/comment_4_271c48d2cf4b09c27cf47ecba7fe1a64._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 4"
+ date="2017-08-26T12:19:17Z"
+ content="""
+Related: [https://git-annex.branchable.com/bugs/Data_loss_when_copying_files_with_running_assistant/](https://git-annex.branchable.com/bugs/Data_loss_when_copying_files_with_running_assistant/)
+"""]]
diff --git a/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn b/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn
new file mode 100644
index 0000000000..83fedbb1e2
--- /dev/null
+++ b/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn
@@ -0,0 +1,90 @@
+### Please describe the problem.
+
+When using the assistant to synchronize several annex repositories, changes are not correctly or not at all propagated to repositories that are in the adjusted branch.
+
+* New files from other repositories are not created automatically in adjusted branch repos
+* Commited changes in files from other repositories are not reflected in in adjusted branch repos
+
+The manual states:
+>	To propigate  changes from  the adjusted branch  back to  the original
+>	branch, and to other repositories, as well as to merge in changes from
+>	other repositories, use git annex sync.
+
+I would expect that the assistant is just doing this, that I don't have to trigger the sync in the adjusted branch repo by myself.
+
+### What steps will reproduce the problem?
+
+Synchronizing several git annex repositories (three) with the assistant, with the second one being in the adjusted branch:
+
+* Create a new file in the first repository (normal v5, autocommit=true)
+* The file is being commited automatically and synchronized into the 3rd repository (normal v5).
+* But the file does not appear in the 2nd one, being in the adjusted branch
+
+Once you trigger
+    git annex sync
+in the 2nd repository, it seems the adjusted branch synchronizes with the master and the file appears.
+
+The same happens with changes in files.
+
+### What version of git-annex are you using? On what operating system?
+
+* git-annex version: 6.20160511-1~ubuntu14.04.1~ppa1
+* Linux 4.4.0-24-generic #43~14.04.1-Ubuntu x86_64
+* Linux Mint 17.3 Rosa
+
+### Please provide any additional information below.
+
+Assistant log from adjust branch repo.
+test7.txt is the new file created on other repo which didn't showed up immediately.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+(merging origin/git-annex into git-annex...)
+To /home/sven/Temporary/Annex1
+ + 9cc4eea...0e6c4ba git-annex -> synced/git-annex (forced update)
+(started...) 
+(merging synced/git-annex into git-annex...)
+(Merging into master...) Merge made by the 'recursive' strategy.
+ script.sh | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 script.sh
+(Merging into adjusted branch...) 
+Updating 449f26f..09950df
+Fast-forward
+ script.sh | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 script.sh
+[2016-09-25 16:32:28.594537] Committer: Committing changes to git
+(recording state in git...)
+[2016-09-25 16:32:28.631525] Pusher: Syncing with origin 
+To /home/sven/Temporary/Annex1
+   0e6c4ba..578f070  git-annex -> synced/git-annex
+   9754018..38c3683  master -> synced/master
+[2016-09-25 16:32:29.632224] Committer: Committing changes to git
+(recording state in git...)
+[2016-09-25 16:32:30.661338] Pusher: Syncing with origin 
+Everything up-to-date
+(merging synced/git-annex into git-annex...)
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+git-annex: Daemon is already running.
+[2016-09-25 16:36:58.360139] Committer: Adding test7.txt
+add test7.txt ok
+[2016-09-25 16:36:58.476985] Committer: Committing changes to git
+(recording state in git...)
+[2016-09-25 16:36:58.494964] Pusher: Syncing with origin 
+Everything up-to-date
+[2016-09-25 16:36:59.575623] Committer: Adding test7.txt
+add test7.txt ok
+[2016-09-25 16:36:59.578454] Committer: Committing changes to git
+(recording state in git...)
+[2016-09-25 16:37:00.506906] Pusher: Syncing with origin 
+Everything up-to-date
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I'm using git-annex a lot for synchronizing stuff between work, home, external backup discs, and now that I see the autocommit=false flag I'll surely start to use the assistant.
+And the new adjust branch is perfect for one of my use cases, but not like it behaves right now.
diff --git a/doc/bugs/Assistant_doesn__39__t_sync_directory_remotes.mdwn b/doc/bugs/Assistant_doesn__39__t_sync_directory_remotes.mdwn
new file mode 100644
index 0000000000..3be92bdb03
--- /dev/null
+++ b/doc/bugs/Assistant_doesn__39__t_sync_directory_remotes.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+I have set up a repository with assistant.  Then, within it, I ran:
+
+```
+git annex initremote source type=directory directory=... importtree=yes encryption=none
+git annex enableremote source type=directory directory=...
+git config remote.source.annex-readonly true
+git config remote.source.annex-tracking-branch main:data
+git annex import main:data --from source
+```
+
+At this point, git annex sync will (usually) sync this.
+
+### What steps will reproduce the problem?
+
+There are two problems.
+
+1. The assistant will never sync this, no matter what I do.  I can request a manual sync of either the repo or the remote, and neither does anything.
+2. It appears that the assistant is creating a locking race with the CLI.  For instance, I got `fatal: Unable to create '.git/index.lock': .git/index.lock: openFd: already exists (File exists)` with one run of `git annex sync`, but the run of it before and after worked fine.
+
+When there isn't a race with `git annex sync`, it behaves as desired.
+
+### What version of git-annex are you using? On what operating system?
+
+8.20210223-2 on Debian bullseye.
+
+### Please provide any additional information below.
+
+I will probably disable assistant 
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I'm pretty excited about using this approach to help archive some photos and such!
diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn
new file mode 100644
index 0000000000..52a2efda22
--- /dev/null
+++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+
+git-annex assistant starts to drop files in remote repos, even when they are set to manual.
+
+### What steps will reproduce the problem?
+
+
+Create 3 repos:
+
+* A -- standard, archive
+* m1 -- standard, manual
+* m2 -- standard, manual
+
+System has 3 files annexed: file1, file2, file3. Repo "A" has all three files, m1 has none, m2 has file3.
+
+So, while in m1:
+
+    m1 $ git annex find --want-drop --in m2
+    file3
+
+file3 shouln't be dropped from m2. There is no reason to do this. m2 is set as manual, and it shouldn't be touched in any case.
+
+Now, let's get this file in m1:
+
+    m1 $ git annex get file3
+    get file3 (from m2...) ok
+    (Recording state in git...)
+    m1 $ git annex find --want-drop --in m2
+
+So when 'file3' is present in local repo, it's not going to be dropped from m2.
+
+I guess that rule 'present' works in local repo context while 'drop' acts on remote files.
+
+
+### What version of git-annex are you using? On what operating system?
+
+I'm using latest version in Debian Jessie (5.20141024) on amd64 and armhf. I've also reproduced the bug with manually compiled 5.20141105-g8d8b248 on amd64.
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_1_5e7d5b0b996a171c641fa560a613d319._comment b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_1_5e7d5b0b996a171c641fa560a613d319._comment
new file mode 100644
index 0000000000..412dbcaeb5
--- /dev/null
+++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_1_5e7d5b0b996a171c641fa560a613d319._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-11-06T19:33:18Z"
+ content="""
+The command `git annex find --want-drop --in m2`
+finds files that meet 2 criteria:
+
+1. Present in the m2 remote. In this case, that is file3.
+2. Are not wanted to be present in the repository in which you run
+   git-annex. In this case, that's all files, since you're running it
+   in m1, which has no files, and is set to manual mode.
+
+Combining criterion 1 and criterion 2, the command finds file3.
+Not that you expected, but only I think because you misunderstood 
+what --in does.
+
+So, I don't see a bug here?
+"""]]
diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_2_2015dfc648d26d6dfabe6ad4f4754034._comment b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_2_2015dfc648d26d6dfabe6ad4f4754034._comment
new file mode 100644
index 0000000000..48125db22e
--- /dev/null
+++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_2_2015dfc648d26d6dfabe6ad4f4754034._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnDx6KWBl4PpP7qikNB7rp0hK_UvwQq_L0"
+ nickname="Александр"
+ subject="comment 2"
+ date="2014-11-06T21:15:14Z"
+ content="""
+Joey, thank you very much for the explanation. I completely agree that what I described in \"how to reproduce\" works as it should.
+
+Actually I was trying to isolate an issue I had where assistant drops files in a remote manual repo. I don't quite get what circumstances are, but sometimes assistant running in m1 starts to drop files in m2 (while still leaving a copy in A). In this test setting the issue doesn't appear... In my actual setup there is an archive and 3 manual live repos, everything connected via ssh, sometimes on slow links, one manual repo is on a linux phone. Assistants were running on several repos.
+
+I'll try to find a convinient way to reproduce this situation, or maybe discover that bug is in my head again ) Anyway I'll return with an update soon.
+
+"""]]
diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_3_8f394437982cebeaf878f5b3871afaf3._comment b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_3_8f394437982cebeaf878f5b3871afaf3._comment
new file mode 100644
index 0000000000..6b281b60fe
--- /dev/null
+++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_3_8f394437982cebeaf878f5b3871afaf3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
+ nickname="Walter"
+ subject="comment 3"
+ date="2014-11-06T22:59:38Z"
+ content="""
+This might not be a very helpful comment, but a while ago I also had a situation where files would be dropped from a remote manual repo.
+
+Unfortunately, I was not able to get this to happen reliably, but from memory
+
+(on repo 1)
+
+    git annex get file --from repo2
+
+would result in ``file`` being gotten, and then dropped, from repo2, even though both repos were set to manual.
+
+But, the unhelpful part, is I can't even remember exactly when this happened (maybe a year ago), so this might not help narrow it down.
+"""]]
diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_4_ccd108a53a9fb747539e269becfb3e05._comment b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_4_ccd108a53a9fb747539e269becfb3e05._comment
new file mode 100644
index 0000000000..a9ca8c8cd9
--- /dev/null
+++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_4_ccd108a53a9fb747539e269becfb3e05._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://renaud.casenave.fr/"
+ subject="comment 4"
+ date="2014-11-07T04:43:44Z"
+ content="""
+This is the same problem I try to report here: http://git-annex.branchable.com/bugs/file_in_manual_mode_repository_is_dropped_when_it_is_copied_to_another_manual_mode_repository/
+
+It is as Walter said, `git annex get file --from repo2` will add the file to the current repo but will drop it in repo2
+"""]]
diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_5_7ee571496c6d7cd57a206e6356dc2be3._comment b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_5_7ee571496c6d7cd57a206e6356dc2be3._comment
new file mode 100644
index 0000000000..962f98e35c
--- /dev/null
+++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_5_7ee571496c6d7cd57a206e6356dc2be3._comment
@@ -0,0 +1,166 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnDx6KWBl4PpP7qikNB7rp0hK_UvwQq_L0"
+ nickname="Александр"
+ subject="comment 5"
+ date="2014-11-16T12:32:28Z"
+ content="""
+Thanks Walter, renaud.
+
+I was finally able to consitently reproduce the bug and record clean debug logs.
+
+There are 3 repos, \"arch\", \"man1\", \"man2\". They are on different machines connected via ssh. \"arch\" is archive, \"man1\" and \"man2\" are in manual mode. Assistant is started only at \"man1\" with args -v -d, after that some files are added. Assistant detects them, adds and then transfers to \"arch\", this works as expected.
+
+After that in \"man2\" I run command:
+
+    git annex get --from man1 random_1_24
+
+File is successfully transferred, and then assistant removes it from \"man1\". Here is corresponding part of logs at \"man1\":
+
+    [2014-11-16 15:10:12 MSK] TransferWatcher: transfer starting: Upload UUID \"d865391b-cf21-42d6-a04c-e1b32897c1af\" random_1_24 Nothing
+    [2014-11-16 15:10:12 MSK] TransferWatcher: transfer starting: Upload UUID \"d865391b-cf21-42d6-a04c-e1b32897c1af\" random_1_24 Nothing
+    [2014-11-16 15:10:13 MSK] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID \"d865391b-cf21-42d6-a04c-e1b32897c1af\", transferKey = Key {keyName = \"f91971893f882086488ca244c7c9e60a5ca23e088a95c171c21e40327de3278b\", keyBackendName = \"SHA256E\", keySize = Just 3145728, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}}
+    [2014-11-16 15:10:13 MSK] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID \"d865391b-cf21-42d6-a04c-e1b32897c1af\", transferKey = Key {keyName = \"f91971893f882086488ca244c7c9e60a5ca23e088a95c171c21e40327de3278b\", keyBackendName = \"SHA256E\", keySize = Just 3145728, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}}
+    [2014-11-16 15:10:14 MSK] RemoteControl: SYNCING ssh://jolla:2222//home/nemo/annex_test
+    [2014-11-16 15:10:14 MSK] RemoteControl: Syncing with man2 
+    From ssh://jolla:2222//home/nemo/annex_test
+    d20436c..f7aff95  git-annex  -> man1/git-annex
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"show-ref\",\"git-annex\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"refs/heads/git-annex..ea323207549cd5853213f1aeaf5f3c1f32e79fe9\",\"-n1\",\"--pretty=%H\"]
+    [2014-11-16 15:10:14 MSK] RemoteControl: DONESYNCING ssh://jolla:2222//home/nemo/annex_test 1
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"refs/heads/git-annex..5701db750b10ae4d579bbccee828c808c8031e7e\",\"-n1\",\"--pretty=%H\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"refs/heads/git-annex..08e7fcc374ee7e233f5f26c0bb7ff825a673818e\",\"-n1\",\"--pretty=%H\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"refs/heads/git-annex..959215d3a9eae6a65ec5e6c68f345f9f623a0d1e\",\"-n1\",\"--pretty=%H\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"refs/heads/git-annex..f7aff95774a095ccf3a5b11bf2e27108d6aadf58\",\"-n1\",\"--pretty=%H\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"refs/heads/git-annex..4aae0d044273fd8716c4cf4946126b0ebf2e0db3\",\"-n1\",\"--pretty=%H\"]
+    (merging man1/git-annex into git-annex...)
+    [2014-11-16 15:10:14 MSK] feed: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"update-index\",\"-z\",\"--index-info\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"f7aff95774a095ccf3a5b11bf2e27108d6aadf58\"]
+    [2014-11-16 15:10:14 MSK] chat: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"hash-object\",\"-t\",\"blob\",\"-w\",\"--stdin\",\"--no-filters\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"f7aff95774a095ccf3a5b11bf2e27108d6aadf58..refs/heads/git-annex\",\"-n1\",\"--pretty=%H\"]
+    (Recording state in git...)
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"write-tree\"]
+    [2014-11-16 15:10:14 MSK] chat: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"commit-tree\",\"dd91fafe3d6acfe88b41c677e66507c0f1905175\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\",\"-p\",\"f7aff95774a095ccf3a5b11bf2e27108d6aadf58\"]
+    [2014-11-16 15:10:14 MSK] call: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"update-ref\",\"refs/heads/git-annex\",\"2ad4a45d95a29db1ecc84a49d5c68bf709f2b3db\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"show-ref\",\"git-annex\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"refs/heads/git-annex..2ad4a45d95a29db1ecc84a49d5c68bf709f2b3db\",\"-n1\",\"--pretty=%H\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"refs/heads/git-annex..5701db750b10ae4d579bbccee828c808c8031e7e\",\"-n1\",\"--pretty=%H\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"refs/heads/git-annex..08e7fcc374ee7e233f5f26c0bb7ff825a673818e\",\"-n1\",\"--pretty=%H\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"refs/heads/git-annex..959215d3a9eae6a65ec5e6c68f345f9f623a0d1e\",\"-n1\",\"--pretty=%H\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"refs/heads/git-annex..f7aff95774a095ccf3a5b11bf2e27108d6aadf58\",\"-n1\",\"--pretty=%H\"]
+    [2014-11-16 15:10:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"log\",\"refs/heads/git-annex..4aae0d044273fd8716c4cf4946126b0ebf2e0db3\",\"-n1\",\"--pretty=%H\"]
+    drop random_1_24 (checking arch...) [2014-11-16 15:10:23 MSK] call: ssh [\"-S\",\".git/annex/ssh/axe\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"axe\",\"git-annex-shell 'inannex' '//home/butler/annex_test' 'SHA256E-s3145728--f91971893f882086488ca244c7c9e60a5ca23e088a95c171c21e40327de3278b' --uuid 5aaf3dc8-f94c-4949-8491-26d5d0de5127\"]
+    ok
+    [2014-11-16 15:10:23 MSK] dropped random_1_24 (from here) (copies now 2) : drop wanted after Upload UUID \"d865391b-cf21-42d6-a04c-e1b32897c1af\" random_1_24 Nothing
+    drop man2 random_1_24 (checking arch...) [2014-11-16 15:10:23 MSK] call: ssh [\"-S\",\".git/annex/ssh/axe\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"axe\",\"git-annex-shell 'inannex' '//home/butler/annex_test' 'SHA256E-s3145728--f91971893f882086488ca244c7c9e60a5ca23e088a95c171c21e40327de3278b' --uuid 5aaf3dc8-f94c-4949-8491-26d5d0de5127\"]
+    [2014-11-16 15:10:23 MSK] call: ssh [\"-S\",\".git/annex/ssh/jolla!2222\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-p\",\"2222\",\"-T\",\"jolla\",\"git-annex-shell 'dropkey' '//home/nemo/annex_test' '--quiet' '--force' 'SHA256E-s3145728--f91971893f882086488ca244c7c9e60a5ca23e088a95c171c21e40327de3278b' --uuid d865391b-cf21-42d6-a04c-e1b32897c1af\"]
+    ok
+    [2014-11-16 15:10:23 MSK] dropped random_1_24 (from UUID \"d865391b-cf21-42d6-a04c-e1b32897c1af\") (copies now 1) : drop wanted after Upload UUID \"d865391b-cf21-42d6-a04c-e1b32897c1af\" random_1_24 Nothing
+    [2014-11-16 15:11:14 MSK] read: git [\"--git-dir=/home/butler/annex_test/.git\",\"--work-tree=/home/butler/annex_test\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+
+Here is git annex vicfg at \"man1\":
+
+    # git-annex configuration
+    # 
+    # Changes saved to this file will be recorded in the git-annex branch.
+    # 
+    # Lines in this file have the format:
+    #   setting field = value
+
+    # Repository trust configuration
+    # (Valid trust levels: trusted semitrusted untrusted dead)
+    # (for web)
+    #trust 00000000-0000-0000-0000-000000000001 = semitrusted
+    # (for man2)
+    #trust 2104670a-6a96-11e4-a3ca-0f84dcf32d24 = semitrusted
+    # (for [arch])
+    #trust 5aaf3dc8-f94c-4949-8491-26d5d0de5127 = semitrusted
+    # (for [man2])
+    #trust d865391b-cf21-42d6-a04c-e1b32897c1af = semitrusted
+    # (for man1)
+    #trust f15688ce-14e0-43ba-a3a2-69ee9d5bdf45 = semitrusted
+
+    # Repository groups
+    # (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted)
+    # (Separate group names with spaces)
+    # (for [arch])
+    group 5aaf3dc8-f94c-4949-8491-26d5d0de5127 = archive
+    # (for [man2])
+    group d865391b-cf21-42d6-a04c-e1b32897c1af = manual
+    # (for man1)
+    group f15688ce-14e0-43ba-a3a2-69ee9d5bdf45 = manual
+    # (for web)
+    #group 00000000-0000-0000-0000-000000000001 = 
+    # (for man2)
+    #group 2104670a-6a96-11e4-a3ca-0f84dcf32d24 = 
+
+    # Repository preferred contents
+    # (Set to \"standard\" to use a repository's group's preferred contents)
+    # (for [arch])
+    wanted 5aaf3dc8-f94c-4949-8491-26d5d0de5127 = standard
+    # (for [man2])
+    wanted d865391b-cf21-42d6-a04c-e1b32897c1af = standard
+    # (for man1)
+    wanted f15688ce-14e0-43ba-a3a2-69ee9d5bdf45 = standard
+    # (for web)
+    #wanted 00000000-0000-0000-0000-000000000001 = 
+    # (for man2)
+    #wanted 2104670a-6a96-11e4-a3ca-0f84dcf32d24 = 
+
+    # Group preferred contents
+    # (Used by repositories with \"groupwanted\" in their preferred contents)
+    #groupwanted archive = 
+    #groupwanted backup = 
+    #groupwanted client = 
+    #groupwanted incrementalbackup = 
+    #groupwanted manual = 
+    #groupwanted public = 
+    #groupwanted smallarchive = 
+    #groupwanted source = 
+    #groupwanted transfer = 
+    #groupwanted unwanted = 
+
+    # Standard preferred contents
+    # (Used by wanted or groupwanted expressions containing \"standard\")
+    # (For reference only; built-in and cannot be changed!)
+    # standard client = (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1
+    # standard transfer = (not (inallgroup=client and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)) or approxlackingcopies=1
+    # standard backup = include=* or unused
+    # standard incrementalbackup = ((include=* or unused) and (not copies=incrementalbackup:1)) or approxlackingcopies=1
+    # standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1
+    # standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1
+    # standard source = not (copies=1)
+    # standard manual = present and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
+    # standard public = inpreferreddir
+    # standard unwanted = exclude=*
+
+    # Repository required contents
+    # (for web)
+    #required 00000000-0000-0000-0000-000000000001 =
+    # (for man2)
+    #required 2104670a-6a96-11e4-a3ca-0f84dcf32d24 =
+    # (for [arch])
+    #required 5aaf3dc8-f94c-4949-8491-26d5d0de5127 =
+    # (for [man2])
+    #required d865391b-cf21-42d6-a04c-e1b32897c1af =
+    # (for man1)
+    #required f15688ce-14e0-43ba-a3a2-69ee9d5bdf45 =
+
+    # Scheduled activities
+    # (Separate multiple activities with \"; \")
+    # (for web)
+    #schedule 00000000-0000-0000-0000-000000000001 =
+    # (for man2)
+    #schedule 2104670a-6a96-11e4-a3ca-0f84dcf32d24 =
+    # (for [arch])
+    #schedule 5aaf3dc8-f94c-4949-8491-26d5d0de5127 =
+    # (for [man2])
+    #schedule d865391b-cf21-42d6-a04c-e1b32897c1af =
+    # (for man1)
+    #schedule f15688ce-14e0-43ba-a3a2-69ee9d5bdf45 =                                                  
+
+Please let me know if I can provide more information, some extra logs, traces, recompile git-annex, etc.
+
+"""]]
diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_6_6c88b218b8186242a6106fc3e7b3edf5._comment b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_6_6c88b218b8186242a6106fc3e7b3edf5._comment
new file mode 100644
index 0000000000..e907711e42
--- /dev/null
+++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_6_6c88b218b8186242a6106fc3e7b3edf5._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2015-07-06T20:31:06Z"
+ content="""
+Well, you've provided some great information, and your setup seems sane,
+and I'd expect it to keep the file in manual mode and not drop it.
+
+The key part of the log is this:
+
+	[2014-11-16 15:10:23 MSK] dropped random_1_24 (from here) (copies now 2) : drop wanted after Upload UUID \"d865391b-cf21-42d6-a04c-e1b32897c1af\" random_1_24 Nothing
+
+So, after transferring the file to the remote where you're getting it, it
+has apparently checked the local repo's preferred content, and thinks it says
+that the local repo doesn't want the file anymore. Which certianly doesn't
+make sense if the repo is configured to be in manual mode.
+
+The only time I'd expect this to happen is if the file in question is one that
+a "client" repository wouldn't normally want. So, if "random_1_24" was in an
+archive directory, the preferred content expression would let it drop it then.
+
+I tried to replicate your configuration, and wasn't able to reproduce
+it deciding to drop the file, when testing with git-annex version 5.20150618.
+
+Can you reproduce this with the most recent release of git-annex?
+
+If so, can you verify that running "git annex drop --auto" doesn't try to drop any files when you run it 
+in the repository that's confgured to be in manual mode?
+"""]]
diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_7_fbbf9d1a63fc61a5fd288fd308b24ca1._comment b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_7_fbbf9d1a63fc61a5fd288fd308b24ca1._comment
new file mode 100644
index 0000000000..372e91b559
--- /dev/null
+++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_7_fbbf9d1a63fc61a5fd288fd308b24ca1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2015-07-06T22:08:11Z"
+ content="""
+I have also not been able to reproduce this using version 5.20141024. So,
+there must be some peice of information left out that's needed to reproduce
+this, or possibly it's an intermittent problem.
+
+I did verify that my attempts to reproduce it caused the code path that
+handles drops after transfers to fire; in my tests it decided not to drop
+the file.
+"""]]
diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_8_fe2498f60b02104a8a044c79cb5bea63._comment b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_8_fe2498f60b02104a8a044c79cb5bea63._comment
new file mode 100644
index 0000000000..2eec510269
--- /dev/null
+++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_8_fe2498f60b02104a8a044c79cb5bea63._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="etesial@f4797a6d725e971a2d41f3cbcf174991da178c29"
+ nickname="etesial"
+ subject="comment 8"
+ date="2015-07-07T14:45:32Z"
+ content="""
+Hi Joey, I've failed to reproduce it now on Debian's 5.20141105-g8d8b248 and have already deleted dirs from previous setup. Maybe I'll try again later if I get some ideas what to tune.
+
+This time I've written a script to setup repos for better reproducibility and while result is negative, I think it'll still may be useful to post it here:
+
+    #!/bin/bash
+
+    set -x
+    set -e
+
+    DIRS=(\"/home/butler/annex_test/data\"
+	\"/home/butler/annex_test/data\"
+	\"/home/butler/annex_test/data\")
+
+    NAMES=(\"antiferno\" \"axe\" \"deadbird\")
+
+    URIS=(\"ssh://antiferno//${DIRS[0]}\"
+	\"ssh://axe//${DIRS[1]}\"
+	\"ssh://deadbird//${DIRS[2]}\")
+
+    MODES=(\"manual\" \"backup\" \"manual\")
+
+
+    function init {
+	git init \"$1\"
+    }
+
+    function git_add_remote {
+	git --git-dir=\"$1/.git\" --work-tree=\"$1\" remote add \"$2\" \"$3\"
+    }
+
+    function annex_init {
+	git --git-dir=\"$1/.git\" --work-tree=\"$1\" annex init \"annex at $2\"
+    }
+
+    function annex_set_mode {
+	git --git-dir=\"$1/.git\" --work-tree=\"$1\" annex wanted . standard
+	git --git-dir=\"$1/.git\" --work-tree=\"$1\" annex group . \"$2\"
+    }
+
+    function add_initial_file {
+	path=\"$1/file_$2\"
+	echo \"File from $2\" >\"$path\"
+	git --git-dir=\"$1/.git\" --work-tree=\"$1\" annex add \"$path\"
+	git --git-dir=\"$1/.git\" --work-tree=\"$1\" commit -m \"First file on $2\"
+    }
+
+    function setup {
+	init \"${DIRS[$1]}\"
+	annex_init \"${DIRS[$1]}\" \"${NAMES[$1]}\"
+	git_add_remote \"${DIRS[$1]}\" \"${NAMES[$2]}\" \"${URIS[$2]}\"
+	git_add_remote \"${DIRS[$1]}\" \"${NAMES[$3]}\" \"${URIS[$3]}\"
+	annex_set_mode \"${DIRS[$1]}\" \"${MODES[$1]}\"
+	add_initial_file \"${DIRS[$1]}\" \"${NAMES[$1]}\"
+    }
+
+    if [ \"$1\" == \"${NAMES[0]}\" ]; then setup 0 1 2; fi
+    if [ \"$1\" == \"${NAMES[1]}\" ]; then setup 1 2 0; fi
+    if [ \"$1\" == \"${NAMES[2]}\" ]; then setup 2 0 1; fi
+
+"""]]
diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment
new file mode 100644
index 0000000000..a6a2397e7f
--- /dev/null
+++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="boh"
+ avatar="http://cdn.libravatar.org/avatar/e7fa2d1c5d95e323fe48887f7f827b1f"
+ subject="comment 9"
+ date="2016-11-27T12:23:20Z"
+ content="""
+Seems as if the problem still exists in 6.20161118 (Debian).
+
+I have three repositories (among others), `jolla`, `sts-3xx`, and `here`.  `jolla` and `here` are in group `manual`, `sts-3xx` is `backup`; `here` and `sts-3xx` have assistants running, `jolla` not.  `jolla` and `sts-3xx` have slightly older versions of git-annex installed.
+
+Now, when I copy a file from `here` to `jolla` like this
+
+    git annex copy real_programmers.png -t jolla
+
+the file is subsequently dropped by the assistant:
+
+```
+drop real_programmers.png (locking jolla...) [2016-11-27 13:00:02.667376556] chat: ssh [\"-S\",\".git/annex/ssh/jolla\",\"-o\",\"ControlMaster
+=auto\",\"-o\",\"ControlPersist=yes\",\"-F\",\".git/annex/ssh.config\",\"-T\",\"jolla\",\"git-annex-shell 'lockcontent' '/~/Music/media/' '--debug' '
+SHA256E-s84499--ff98a733cc0122858fb11433c720e2d038fec190a3d36380d0e7e8dab468f883.png' --uuid 5298e3ce-1106-4d5e-b052-0aee4b27a344\"]
+(locking sts-3xx...) [2016-11-27 13:00:03.252473676] chat: ssh [..., \"git-annex-shell 'lockcontent' '/backups/exot/media/' '--debug' 'SHA256E-s84499--ff98a733cc0122858fb11433c720e2d038fec190a3d 36380d0e7e8dab468f883.png' --uuid 1fec6253-171d-4f86-885b-e233be2d65ec\"]
+(lockcontent failed) [2016-11-27 13:00:03.486158016] process done ExitFailure 1
+(checking sts-3xx...) [2016-11-27 13:00:03.487047149] call: ssh [..., \"git-annex-shell 'inannex' '/backups/exot/media/' '--debug' 'SHA256E-s84499--ff98a733cc0122858fb11433c720e2d038fec190a3d363 80d0e7e8dab468f883.png' --uuid 1fec6253-171d-4f86-885b-e233be2d65ec\"]
+[2016-11-27 13:00:03.76435136] process done ExitSuccess
+[2016-11-27 13:00:03.764705754] Dropping from here proof: Just (SafeDropProof (NumCopies 2) [RecentlyVerifiedCopy UUID \"1fec6253-171d-4 f86-885b-e233be2d65ec\",LockedCopy UUID \"5298e3ce-1106-4d5e-b052-0aee4b27a344\"] (Just (ContentRemovalLock (Key {keyName = \"ff98a733cc012 2858fb11433c720e2d038fec190a3d36380d0e7e8dab468f883.png\", keyBackendName = \"SHA256E\", keySize = Just 84499, keyMtime = Nothing, keyChun kSize = Nothing, keyChunkNum = Nothing}))))
+[2016-11-27 13:00:04.24333081] process done ExitFailure 1
+ok
+[2016-11-27 13:00:04.251232455] dropped real_programmers.png (from here) (copies now 4) : drop wanted after Upload UUID \"5298e3ce-1106- 4d5e-b052-0aee4b27a344\" real_programmers.png Just 84499
+```
+
+However, I failed to reproduce the problem by replicating my setup with fresh repositories …
+
+Please let me know if you need more information, and *so* many thanks for git-annex!
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories.mdwn b/doc/bugs/Assistant_has_created_155_semitrusted_repositories.mdwn
new file mode 100644
index 0000000000..b1caf530d4
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories.mdwn
@@ -0,0 +1,191 @@
+### Please describe the problem.
+git annex status reports 160 semitrusted repositories. Four of them are the ones I created (only via webapp, I think I never edited any git-annex config file). One is 	00000000-0000-0000-0000-000000000001 -- web
+ and although I do not know what it is, it is not something new. The remaining 155 appeared spontaneously after several Gb of data (mostly many small files) were added to an Annex (in an 'archive' directory) operated in direct mode by the assistant.
+
+
+
+### What steps will reproduce the problem?
+Add several Gb of files was enough to trigger this problem, but I did not try to reproduce it. It happened the day I installed the 4.20131106~bpo70+1 version.
+
+### What version of git-annex are you using? On what operating system?
+
+4.20131106~bpo70+1 on debian squeeze (7.2), with git  1.8.4.rc3.
+
+
+### Please provide any additional information below.
+May be related or not: at some point the webapp displayed two warning boxes. One of them held a message that I did not wirte down and proposed to "Restart the thread". This apparently worked since the box disappeared. The other warning box indicated "NetWatcherFallback crashed: unknown response from git cat-file" and proposed to restart the thread. Trying to "restart the thread" via the provided button just did not trigger any response of the webapp which seemed dead at that point.
+
+In spite of the git annex status shown below, the webapp still shows only the expected four repositories.
+
+Output of git annex status (hostname and xmpp account name were edited away):
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+repository mode: direct
+trusted repositories: 
+0
+semitrusted repositories: 160
+	00000000-0000-0000-0000-000000000001 -- web
+ 	0ab193eb-0c76-4559-a93c-2e30ed8630a8 -- someMachineIown_datadir (archive)
+ 	1384784127.91222s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384784164.437824s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384784176.944372s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384784179.254498s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384785147.558938s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785147.717223s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785159.041203s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785159.199504s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785185.79485s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785187.318128s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785215.236504s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785215.389096s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785313.539843s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785313.701305s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785315.596206s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785344.184461s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785348.192805s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785402.70316s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785406.524044s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384785446.074236s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384873605.313126s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384873697.029999s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384873761.687234s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384873774.608376s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384926279.456728s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384926368.736s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384926454.99433s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384926494.152645s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384926504.438232s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384934790.89717s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384934848.757067s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384934899.087168s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384934908.238587s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384948772.14552s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384948805.441196s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384948813.397132s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384948921.45481s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384948924.855852s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384949073.988946s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384949082.298976s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384949399.608138s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384949581.12213s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384949583.9923s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384949700.22807s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384949765.484768s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955202.85962s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955230.953995s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955402.534938s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955457.1885s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955524.603709s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955611.891061s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955677.84592s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955689.293082s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955894.057476s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955910.723021s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955914.732132s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955968.717875s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384955969.634658s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384956004.284925s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384956029.567195s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384956188.628995s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384956379.844701s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384956381.613833s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384956387.923418s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384956395.418701s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384956408.792928s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384956504.019733s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384956519.578085s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384956524.419783s -- 1 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384965891.562742s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384965891.815119s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384965903.355602s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384965905.276128s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384965978.806653s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384965979.393089s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966097.495566s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966097.704474s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966154.97658s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966156.967406s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966233.310488s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966233.522324s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966241.284523s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966241.475381s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966301.688497s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966303.427685s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966392.875983s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966393.38718s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966404.708568s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966406.441164s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966553.557387s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966555.752786s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966653.725847s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966654.23288s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966695.201885s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966695.689398s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966784.556877s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966786.574886s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966791.446852s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966793.218318s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384966884.335685s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384966886.147083s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384967054.857465s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384967055.158871s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384967190.980027s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384967193.176584s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384967328.93796s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384967330.428095s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384967526.127311s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384967526.588491s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384967627.132549s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384967627.685201s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384967686.283694s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384967686.728086s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384967768.270887s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384967768.58402s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384967769.245615s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384967771.122238s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384967813.8197s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384967814.168477s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384967915.243469s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384967917.020051s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384968031.757775s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384968032.190452s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384968035.733635s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384968036.03299s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384968144.555556s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384968144.714535s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384968150.090148s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384968150.820567s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384968304.393177s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384968304.613624s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384968604.499519s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384968604.813256s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384968702.566939s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384968704.427767s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384968725.375289s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384968725.939271s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384968798.402904s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384968798.659754s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384969055.285004s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384969055.715448s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384969159.885115s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384969162.382266s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384969184.633052s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384969185.413769s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384969374.791849s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384969377.497842s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384969475.469111s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384969489.697737s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384969492.087023s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384969492.58214s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384969784.725195s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384969786.49773s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	1384969814.984624s -- 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+ 	1384969815.397676s -- 0 391b0557-dc68-4e40-b6d0-da3033588753
+ 	391b0557-dc68-4e40-b6d0-da3033588753 -- here (client)
+ 	668ef9d8-68c6-484e-89e5-06634d590a11 -- rsync.net_datadir_annex (transfer)
+ 	b0d3c000-0ac9-4a05-aef4-47f826d5c759 -- user.name (client)
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_10_c5508b476fc48e7a0002b6ecb8d5eac0._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_10_c5508b476fc48e7a0002b6ecb8d5eac0._comment
new file mode 100644
index 0000000000..77f19b15b8
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_10_c5508b476fc48e7a0002b6ecb8d5eac0._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 10"
+ date="2013-12-03T18:05:11Z"
+ content="""
+It's normal for the git-annex assistant to keep a couple of long-running git cat-file and git check-attr processes running at all times. So I'd not worry about that.
+
+I received the emailed tarball of uuid.log versions. (message-id CAL5AKQq9i4QwReWHZkKOm1Ggon66FqFkjbM832PP1drgiR3x5g@mail.gmail.com)
+
+Can you show the command you used to dump those files? Because the contents of them is really quite weird. 
+
+Take file 0, which I'm guessing might be the first version of the uuid.log. It starts off with what I'd expect to see in a uuid.log, but then has a section of what looks like trust.log data, followed by what is certianly supposed to be remote.log data, followed by what looks like `git show 966ec7aaf408dffe0d6e6ce04aebc15dc5b26f5b`, a commit which apparently was made by \"Firstname.Lastname@somedomain.com\" (unless you anonymized that) and added a file `test` to the git repository.
+
+It gets worse, some of the versions of the uuid.log file appear to be megabytes in size, which is just insane, and these contain more such apparent `git show` of git commits adding files to the repository.
+
+The general pattern of uuid.log data +trust.log data + remote.log data + git show of a commit seems to repeat in each version of the uuid.log file.
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_11_cb49edcc8a13928c171a2acdde32dce9._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_11_cb49edcc8a13928c171a2acdde32dce9._comment
new file mode 100644
index 0000000000..74a30886c6
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_11_cb49edcc8a13928c171a2acdde32dce9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="comment 11"
+ date="2013-12-03T18:32:59Z"
+ content="""
+The files I sent you were collected with:
+
+```for i in $(seq 0 52); do git show git-annex:uuid.log @{$i} > ~/tmp/uuid.logs/$i; done```
+
+
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_12_a86c8347526e7b0a6f7633f3aea528bb._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_12_a86c8347526e7b0a6f7633f3aea528bb._comment
new file mode 100644
index 0000000000..4a92b1f8a4
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_12_a86c8347526e7b0a6f7633f3aea528bb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="comment 12"
+ date="2013-12-03T18:38:45Z"
+ content="""
+and yes: as I wrote in email my name and the domain of email address are private and were edited away (sed firstname, lastname, domain except gmail which is used for xmpp). So the \"Firstname.Lastname@somedomain.com\" has replaced my real professional email address.
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_13_a26c2b49ee7746be06f4772aa838d5aa._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_13_a26c2b49ee7746be06f4772aa838d5aa._comment
new file mode 100644
index 0000000000..e4d552ad7d
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_13_a26c2b49ee7746be06f4772aa838d5aa._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 13"
+ date="2013-12-03T20:23:43Z"
+ content="""
+Ok, that explains the weird results, because I get the same crazy data dumped when I try eg `git show git-annex:uuid.log @{0}` in a repository that is completely ok.
+
+The @{0} causes git show to show some commit. Not the commit that changed uuid.log however. So it first shows the uuid.log (always the most recent version), and then some random commit.
+
+This will work:
+
+<pre>
+git clone myrepo myrepo.tmp
+cd myrepo.tmp
+git checkout git-annex
+mkdir logs
+for r in $(git log --pretty='%H' uuid.log); do git show $r > logs/$r; done
+git log uuid.log > logs/gitlog
+</pre>
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_14_b958da97a69091d283918e0d5a658da5._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_14_b958da97a69091d283918e0d5a658da5._comment
new file mode 100644
index 0000000000..b5b4996695
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_14_b958da97a69091d283918e0d5a658da5._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="comment 14"
+ date="2013-12-04T08:47:15Z"
+ content="""
+I followed the procedure you suggested, please see email for how to transfer it to you. There are several points I would like to note:
+
+1. In the cloned repository created as you suggest above, the output of ```git annex status``` does not contain all the weird things that appear in the original repository (although it contains other stuff, see 3)
+2. In the original repository (~/datadir/Annex), the output of ```git annex status``` still contains the 155 nonrepositories, plus some other stuff (see 3)
+3. In the meantime, I created (always with the webapp) another annex for private stuff (~/private/Annex) on the same set of machines. Although I chose to \"keep repositories separated\", the few files that I put for testing into the new ~/private/Annex have appeared as broken symlinks in the work annex ~/datadir/Annex. The transfer repositories used for the work and private annexes are different and are not even hosted on the same machines. The jabber account on the contrary is the same for all annexes. 
+4. In the webapp (client1) in ~/private/Annex, only the correct repositories appear.
+5. In the webapp (client1) in ~/datadir/Annex the correct repositories appear, plus the private repository of client 2 and twice the transfer repository of the ~/private/Annex
+6. ```git annex status``` on client1 in ~/datadir/Annex shows the repositories of ~/private/Annex in addition to the 155 nonrepositories and its own repositories
+7. Because of 3), you will find at the end of the logs some new stuff that is in principle not related to the original bug report.
+
+In the end the situation is now the following:
+
+* 3 annexes (~/Annex for initial testing, ~/datadir/Annex for work, ~/private/Annex for private stuff), all created via webapp and handled by the assistant
+* files which were added on client 1 into ~/private/Annex also appear as broken links in ~/datadir/Annex on client 1 but nowhere in client 2
+* files which were added on client 2 into ~/private/Annex also appear as broken links in ~/datadir/Annex on client 1 and in client 2
+* The first created annex still seems to work as expected
+
+I am sorry that the situation is that messy. Is there a way to separate these repositories that have somehow become entangled? 
+
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_1_169b24b34cce3f5c8446c2150beb6827._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_1_169b24b34cce3f5c8446c2150beb6827._comment
new file mode 100644
index 0000000000..99bb737e4f
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_1_169b24b34cce3f5c8446c2150beb6827._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 1"
+ date="2013-11-22T16:54:53Z"
+ content="""
+Please post the output of `git show git-annex:uuid.log` run in the repository.
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_2_6acd6f38297772a07d8d5fb999bd2eaa._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_2_6acd6f38297772a07d8d5fb999bd2eaa._comment
new file mode 100644
index 0000000000..6db2a8fcae
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_2_6acd6f38297772a07d8d5fb999bd2eaa._comment
@@ -0,0 +1,183 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="comment 2"
+ date="2013-11-22T17:23:19Z"
+ content="""
+Here it is (user name edited):
+
+[[!format sh \"\"\"
+
+
+0ab193eb-0c76-4559-a93c-2e30ed8630a8 archive timestamp=1384664310.014349s
+0ab193eb-0c76-4559-a93c-2e30ed8630a8 datadir on st08 timestamp=1384522780.868451s
+0ab193eb-0c76-4559-a93c-2e30ed8630a8 username@st08:~/datadir_annex timestamp=1384540428.076617s
+0ab193eb-0c76-4559-a93c-2e30ed8630a8 username@st08:~/datadir_annex timestamp=1384541057.852874s
+0ab193eb-0c76-4559-a93c-2e30ed8630a8 username@st08:~/datadir_annex timestamp=1384548609.891111s
+1384784127.91222s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384784164.437824s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384784176.944372s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384784179.254498s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384785147.558938s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785147.717223s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785159.041203s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785159.199504s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785185.79485s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785187.318128s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785215.236504s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785215.389096s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785313.539843s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785313.701305s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785315.596206s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785344.184461s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785348.192805s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785402.70316s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785406.524044s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384785446.074236s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384873605.313126s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384873697.029999s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384873761.687234s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384873774.608376s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384926279.456728s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384926368.736s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384926454.99433s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384926494.152645s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384926504.438232s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384934790.89717s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384934848.757067s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384934899.087168s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384934908.238587s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384948772.14552s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384948805.441196s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384948813.397132s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384948921.45481s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384948924.855852s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384949073.988946s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384949082.298976s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384949399.608138s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384949581.12213s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384949583.9923s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384949700.22807s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384949765.484768s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955202.85962s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955230.953995s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955402.534938s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955457.1885s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955524.603709s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955611.891061s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955677.84592s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955689.293082s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955894.057476s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955910.723021s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955914.732132s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955968.717875s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384955969.634658s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384956004.284925s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384956029.567195s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384956188.628995s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384956379.844701s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384956381.613833s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384956387.923418s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384956395.418701s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384956408.792928s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384956504.019733s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384956519.578085s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384956524.419783s 1 391b0557-dc68-4e40-b6d0-da3033588753
+1384965891.562742s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384965891.815119s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384965903.355602s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384965905.276128s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384965978.806653s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384965979.393089s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966097.495566s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966097.704474s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966154.97658s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966156.967406s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966233.310488s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966233.522324s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966241.284523s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966241.475381s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966301.688497s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966303.427685s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966392.875983s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966393.38718s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966404.708568s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966406.441164s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966553.557387s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966555.752786s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966653.725847s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966654.23288s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966695.201885s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966695.689398s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966784.556877s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966786.574886s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966791.446852s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966793.218318s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384966884.335685s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384966886.147083s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384967054.857465s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384967055.158871s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384967190.980027s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384967193.176584s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384967328.93796s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384967330.428095s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384967526.127311s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384967526.588491s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384967627.132549s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384967627.685201s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384967686.283694s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384967686.728086s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384967768.270887s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384967768.58402s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384967769.245615s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384967771.122238s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384967813.8197s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384967814.168477s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384967915.243469s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384967917.020051s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384968031.757775s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384968032.190452s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384968035.733635s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384968036.03299s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384968144.555556s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384968144.714535s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384968150.090148s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384968150.820567s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384968304.393177s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384968304.613624s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384968604.499519s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384968604.813256s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384968702.566939s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384968704.427767s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384968725.375289s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384968725.939271s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384968798.402904s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384968798.659754s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384969055.285004s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384969055.715448s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384969159.885115s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384969162.382266s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384969184.633052s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384969185.413769s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384969374.791849s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384969377.497842s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384969475.469111s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384969489.697737s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384969492.087023s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384969492.58214s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384969784.725195s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384969786.49773s 0 391b0557-dc68-4e40-b6d0-da3033588753
+1384969814.984624s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+1384969815.397676s 0 391b0557-dc68-4e40-b6d0-da3033588753
+391b0557-dc68-4e40-b6d0-da3033588753 client timestamp=1384528843.958836s
+391b0557-dc68-4e40-b6d0-da3033588753 username@big:~/datadir/Annex timestamp=1384521164.194035s
+668ef9d8-68c6-484e-89e5-06634d590a11 cipher=dFpZLzI4M3ZqVUl1S0p3ajl5N25vUUJyTFJXand5T2pNSGliOGo5WXBkN2NNY3ZqR3pvNmN0L2tLOFFKZW1aWDdHYUpCMGF1UGxybk9zeUdQOEpsMGZ5RzgwTVo1S2N6Rlo1eTVnNXFGYjJmblV0bzRjT3lTb29uZnY1QmpwMVVwYlZEOGVlaVlNR0R5dTcxNW50TFcrU1dSVi9PUXk5RkR6Zm14UFJzZEEvOHB5MTZXbkp5TW13Qm5UZ2FkUEsrUTdVZ2cxVWZnai9mbGRDYWVXYlpDVzFQL2tzanNTMU16aGxuVktETXpOY04vR1lSZnEzNVdJSkpDUEtMV1pPWXczVUVNTEJCNGtmUldiTVZoWWdlYm9NTTN4T2c1RXRvTXEzTytXazNaaFNKeUtsSlNmOUFXdTIrYnZLbkgvSFljSFVPOVlid0lCSHFlSDk0ZVQ3M3E4eHR6ckM1SjdIbjF0dmRSTGVibFFSdzUrdnVMM3p6UDl5R0JOUWNhL3Q4MXVVVGF0RjFjNGoyditZUGRzOUEraHZ5Z29hNkk0SDNiaVdYVnJFQmxTRTdTd3hOcjR3amJzRkd3d1VEUXFFZDhLNTBhWGF6bUY5LzZCZ2F5U1lOZEFDdXdSU2pMOU9qVGJWM29wVGNhNEt1Z09jU1JXRnQ0QUhoZXMxZlpvN1Qzc1o4WTQ3S1dUNVdJM3FjK05aQm5kUk10Nm8zSG1Ccys3cFdDUWVaUGJCbUhwK2ozdGw0cmxhK3FydkF5b3ZOM0xmbEJKdVBpTHNxd3JSUEpXdndkSENzQjlteHovZW9JOUtWUGJKNGxoRExSRVloNDUrNFZ6YmFZQVNZdkcxV2JxSzZTc2ZING90cmRBREZtTFRlRnc3OW92ZXBxQ0pPa21UMFFuR0ZJNG89Cg== encryption=shared name=rsync.net_datadir_annex rsyncurl=rsusername@git-annex-ch-s011.rsync.net-rsusername_datadir_annex.2F:datadir_annex/ type=rsync timestamp=1384948273.302009s
+668ef9d8-68c6-484e-89e5-06634d590a11 cipher=dFpZLzI4M3ZqVUl1S0p3ajl5N25vUUJyTFJXand5T2pNSGliOGo5WXBkN2NNY3ZqR3pvNmN0L2tLOFFKZW1aWDdHYUpCMGF1UGxybk9zeUdQOEpsMGZ5RzgwTVo1S2N6Rlo1eTVnNXFGYjJmblV0bzRjT3lTb29uZnY1QmpwMVVwYlZEOGVlaVlNR0R5dTcxNW50TFcrU1dSVi9PUXk5RkR6Zm14UFJzZEEvOHB5MTZXbkp5TW13Qm5UZ2FkUEsrUTdVZ2cxVWZnai9mbGRDYWVXYlpDVzFQL2tzanNTMU16aGxuVktETXpOY04vR1lSZnEzNVdJSkpDUEtMV1pPWXczVUVNTEJCNGtmUldiTVZoWWdlYm9NTTN4T2c1RXRvTXEzTytXazNaaFNKeUtsSlNmOUFXdTIrYnZLbkgvSFljSFVPOVlid0lCSHFlSDk0ZVQ3M3E4eHR6ckM1SjdIbjF0dmRSTGVibFFSdzUrdnVMM3p6UDl5R0JOUWNhL3Q4MXVVVGF0RjFjNGoyditZUGRzOUEraHZ5Z29hNkk0SDNiaVdYVnJFQmxTRTdTd3hOcjR3amJzRkd3d1VEUXFFZDhLNTBhWGF6bUY5LzZCZ2F5U1lOZEFDdXdSU2pMOU9qVGJWM29wVGNhNEt1Z09jU1JXRnQ0QUhoZXMxZlpvN1Qzc1o4WTQ3S1dUNVdJM3FjK05aQm5kUk10Nm8zSG1Ccys3cFdDUWVaUGJCbUhwK2ozdGw0cmxhK3FydkF5b3ZOM0xmbEJKdVBpTHNxd3JSUEpXdndkSENzQjlteHovZW9JOUtWUGJKNGxoRExSRVloNDUrNFZ6YmFZQVNZdkcxV2JxSzZTc2ZING90cmRBREZtTFRlRnc3OW92ZXBxQ0pPa21UMFFuR0ZJNG89Cg== encryption=shared name=rsync.net_datadir_annex rsyncurl=rsusername@git-annex-ch-s011.rsync.net-rsusername_datadir_annex:datadir_annex/ type=rsync timestamp=1384547300.727425s
+668ef9d8-68c6-484e-89e5-06634d590a11 rsync.net_datadir_annex timestamp=1384547300.725734s
+668ef9d8-68c6-484e-89e5-06634d590a11 rsync.net_datadir_annex timestamp=1384948273.280063s
+668ef9d8-68c6-484e-89e5-06634d590a11 transfer timestamp=1384948273.352386s
+b0d3c000-0ac9-4a05-aef4-47f826d5c759 client timestamp=1384575989.965159s
+b0d3c000-0ac9-4a05-aef4-47f826d5c759 username@mezzo:~/datadir/Annex timestamp=1384547220.353298s
+
+\"\"\"]]
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_3_6a4118e5c5fbe5e84d27094ac72b741b._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_3_6a4118e5c5fbe5e84d27094ac72b741b._comment
new file mode 100644
index 0000000000..2d31d1a7a6
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_3_6a4118e5c5fbe5e84d27094ac72b741b._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 3"
+ date="2013-11-22T17:47:30Z"
+ content="""
+Any chance I could get a copy of this git repository? (Excluding the .git/annex part)
+
+Feel free to email me id@joeyh.name to arrange a secure transfer.
+
+Otherwise, I need to see what the git-annex:uuid.log file looked like before this happened to it. The corruption may have occurred progressively in several commits, or all at once.
+
+You might also still have some logs in `.git/annex/daemon.log*`, and sending those might help, assuming the strange messages you mentioned are logged in there.
+
+> 1384785215.389096s 1 0ab193eb-0c76-4559-a93c-2e30ed8630a8
+
+This is pretty weird thing to be in the uuid.log. The \"1\" makes me think this might be a scrambled version of what's normally stored in the trust.log:
+
+> 511f4722-63d5-11e1-8b26-1bb951ea9f7b 1 timestamp=1330630786.417597s
+
+This seems to be the same bug as [[bugs/non-repos in repositories list (+ other weird output) from git annex status]]
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_4_04daa20d5d7c74bb34ec48e752ed9fe8._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_4_04daa20d5d7c74bb34ec48e752ed9fe8._comment
new file mode 100644
index 0000000000..dd037bcc02
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_4_04daa20d5d7c74bb34ec48e752ed9fe8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 4"
+ date="2013-11-22T17:48:37Z"
+ content="""
+What hardware are you running git-annex on?
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_5_11af8ab2587e6eeb671051ba8191995b._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_5_11af8ab2587e6eeb671051ba8191995b._comment
new file mode 100644
index 0000000000..de9d4fd719
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_5_11af8ab2587e6eeb671051ba8191995b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="comment 5"
+ date="2013-11-22T18:22:55Z"
+ content="""
+One client is a thinkpad 121e, the other one a hp Z420 workstation. The archive is a basic Dell desktop. All of them run wheezy with git-annex and git  from official backports. The transfer repository is at rsync.net. 
+
+The daemon.log file was empty at the time I noticed the situation. Now git-annex has been scanning this repository for some time and the log has information again but it looks a bit too long to be posted here. I will email about the repository copy and the log.
+
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_6_26236cdc2bce532017854791bcd727d1._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_6_26236cdc2bce532017854791bcd727d1._comment
new file mode 100644
index 0000000000..8b5c80f6bb
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_6_26236cdc2bce532017854791bcd727d1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="comment 6"
+ date="2013-11-22T19:29:08Z"
+ content="""
+Some additional information (useful at least from user's point of view): the data that was in the annex but outside of the archive is still accessible from both clients. Part of the data that was in the archive does not seem to be accessible on one client: ```git annex get```  says it gets data in an amount which seems correct but the link to the data remains broken. Fortunately I can still access the data on the other client. Some of the data in the archive is still accessible in both clients. The part that is still accessible was put in the annex a few days ago, only the last directory which was added and seems to have triggered the problem is \"broken\" on one client. It is possible (not sure, sorry) that this directory was first added in the annex, and then moved to the archive shortly after, before the first addition had propagated to the other client.
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_7_3c532dd5b8a01ecdeda1300b49aba675._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_7_3c532dd5b8a01ecdeda1300b49aba675._comment
new file mode 100644
index 0000000000..00abc500bd
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_7_3c532dd5b8a01ecdeda1300b49aba675._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="comment 7"
+ date="2013-11-23T13:16:10Z"
+ content="""
+OK, sorry but it will be difficult to provide you with a copy of this repository. I hope I can still help in spite of being only a very novice git user. I checked that the git-annex:uuid.log file at the first commit was identical to the one above.  The only difference is that in this first commit file there is a mention at the bottom of who created the file (me@somedomain.com) with the mention \"created repository\". 
+
+So it is very possible that these nonexisting remotes are present since day 1. It is possible that I did not notice it earlier (I am not sure I had ever run git annex status in this repository since I am looking for a dropbox-like experience). What triggered my curiosity was the difficulty I had to get some data. At that point it might be that there are two independent problems. One with these nonexisting repositories, and another one with the fact that I cannot get some data in this client.
+
+Would it be useful to you to have the full history (52 revisions) of the git-annex:uuid.log file?
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_8_119142c5ebc499f0ee0926dbca265308._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_8_119142c5ebc499f0ee0926dbca265308._comment
new file mode 100644
index 0000000000..d50964f64c
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_8_119142c5ebc499f0ee0926dbca265308._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 8"
+ date="2013-11-26T16:34:13Z"
+ content="""
+Yes, it would be helpful to have the full history of the file.
+
+You might try running `git annex fsck` on the file in the client that it says it has gotten but that you cannot access.
+"""]]
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_9_0651071ee1654eeaa9aa9369873fdf6a._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_9_0651071ee1654eeaa9aa9369873fdf6a._comment
new file mode 100644
index 0000000000..863c5b53d4
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_9_0651071ee1654eeaa9aa9369873fdf6a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="comment 9"
+ date="2013-12-02T20:49:14Z"
+ content="""
+I had already tried ```git annex fsck``` and for all files the command returned ```ok```. Nevertheless, it was still not possible to get the data. Now after a few days it seems I can get all the data I tried from both clients. Maybe because the repository contains many files (about 1.5e6) the daily sanity check spawns git processes which do not seem to terminate even when the delay has expired but other than that the repository does not seem to be in a bad state, the only weirdness being the 155 nonrepositories in the status.
+"""]]
diff --git a/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory.mdwn b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory.mdwn
new file mode 100644
index 0000000000..954d26ec23
--- /dev/null
+++ b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory.mdwn
@@ -0,0 +1,520 @@
+I have a git annex assistant process using 1.2 gigabytes of RAM and a git cat-file --batch child consuming CPU time constantly. I am running 5.20140320 on Ubuntu 12.04.
+
+[[!format sh """
+  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
+11775 ion       20   0 1350m 1.2g  12m S   48 62.4 425:56.85 git-annex
+11787 ion       20   0  9856 1484 1232 R   54  0.1 366:16.14 git
+"""]]
+
+The assistant UI looks perfectly normal and does not indicate it is doing anything. daemon.log is empty and the assistant process seems to be logging into a rotated and deleted log file.
+
+[[!format sh """
+COMMAND     PID USER   FD   TYPE     DEVICE SIZE/OFF     NODE NAME
+git-annex 11775  ion    1w   REG      9,127    80841 55181369 /storage/ion/media/video/.git/annex/daemon.log.10 (deleted)
+git-annex 11775  ion    2w   REG      9,127    80841 55181369 /storage/ion/media/video/.git/annex/daemon.log.10 (deleted)
+"""]]
+
+strace -s10000 -e trace=read,write -p 11787 indicates that the assistant is having the cat-file process cat same objects over and over again.
+
+[[!format sh """
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "d95950acebb5c4318329d7b989d36d01b76b7801 blob 232\n", 50) = 50
+write(1, "1396057825.366657s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.538068s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.560144s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.538542s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:ee2/2ee/SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "977039ea431522e6e27a78bdec2c1299f883eb85 blob 232\n", 50) = 50
+write(1, "1396057823.999737s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057835.133409s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057835.215084s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.468307s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:a84/f1f/SHA256E-s47051987--dcfd0413db883506ccb8c45e3b2d60cb3ff5c83cc55c9c7e44818d7556dbc07f.mp4.log\n", 4096) = 121
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "6c0ff555a1a34337c9379d8856c8283429bef973 blob 231\n", 50) = 50
+write(1, "1396057829.505426s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057839.859236s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057839.875213s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.77741s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:50a/5fc/SHA256E-s275654757--52823cd2061375910ccbd8de38865eca91511d9b4621243d2ef96a974d7546aa.flv.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "cdbc7ce6b426dfcce9d718387b6c412e870a2d12 blob 232\n", 50) = 50
+write(1, "1396057828.887576s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.117938s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.197196s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.687354s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 232) = 232
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:9b5/545/SHA256E-s32710--6005b5faf1a6d42d499053f8cca87d080536abfa8442b33c87f7966e86726e4f.fin.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+read(3, "", 214)                        = 0
+write(1, "82a98cbfe8f24d336a537cecea2182922c4681e1 blob 231\n", 50) = 50
+write(1, "1396057825.390306s 1 3f89d0d8-6162-4362-852a-cb688d6c0696\n1396057866.37922s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396057866.386029s 1 161c3d7f-eb60-4294-84d2-eb611786c91e\n1396058160.588219s 0 3f89d0d8-6162-4362-852a-cb688d6c0696\n", 231) = 231
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:d28/166/SHA256E-s59188--9c04581bd67ea7c78b537a164d104bea5ac91a4a69f06b477cf07892a2d9b852.fih.srt.log\n", 4096) = 122
+read(3, "0936a1fdd849b8b46abb879d7cf82cc758b367e3\n", 255) = 41
+"""]]
diff --git a/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_10_edb2428552cf98bfb1735c2d6daf2b20._comment b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_10_edb2428552cf98bfb1735c2d6daf2b20._comment
new file mode 100644
index 0000000000..d5f7ce363b
--- /dev/null
+++ b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_10_edb2428552cf98bfb1735c2d6daf2b20._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://johan.kiviniemi.name/"
+ nickname="Johan"
+ subject="comment 10"
+ date="2014-05-01T01:33:10Z"
+ content="""
+Note to self: I experienced this bug with the standalone tarball release (5.20140421) as well, so it’s not caused by something that is different on my system wrt. git-annex’s dependencies etc.
+"""]]
diff --git a/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_1_ac8c39e362e6c806b9d68befc0199ccd._comment b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_1_ac8c39e362e6c806b9d68befc0199ccd._comment
new file mode 100644
index 0000000000..e9c5d3fff8
--- /dev/null
+++ b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_1_ac8c39e362e6c806b9d68befc0199ccd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 1"
+ date="2014-04-02T18:48:51Z"
+ content="""
+All I can tell from the strace is that it's looking at location logs, and it's looking at the same few keys, but not a single on in a tight loop.
+
+It would probably help a lot to run the assistant with --debug and get a debug log while this is going on. We need to pinpoint the part of the assistant that is affected, and there may be other activity too.
+"""]]
diff --git a/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_2_b2941bf7901a1b2237b7210c8f0af2a5._comment b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_2_b2941bf7901a1b2237b7210c8f0af2a5._comment
new file mode 100644
index 0000000000..c9e798c28c
--- /dev/null
+++ b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_2_b2941bf7901a1b2237b7210c8f0af2a5._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 2"
+ date="2014-04-07T21:07:35Z"
+ content="""
+Except of log when this apparently happened. Note the 6 minute time discontinuity when it was apparently looping:
+
+<pre>
+[2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"write-tree\"]
+[2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"rev-parse\",\"84068090af4bcd3d24f16d865ac07b0478f20ada:\"]
+[2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"symbolic-ref\",\"HEAD\"]
+[2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"refs/heads/master\"]
+[2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"git-annex\"]
+[2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..214ed317536695b91c8dd5bed059c46c11ad00be\",\"--oneline\",\"-n1\"]
+</pre>
+
+Also probably relevant, the network topology AIUI was: `client --> server` where both nodes ran the assistant. This happened on the server shortly after the client dropped off a refs/heads/synced/master.
+
+(Also, the \"logging to a deleted file\" appears to have been a local misconfiguration; a cron job that repeatedly tried to start the assistant. Only one will start, but later ones will rotate the logs before noticing it's running and giving up.)
+"""]]
diff --git a/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_3_1429ca784a03bc424b3537cbe0449421._comment b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_3_1429ca784a03bc424b3537cbe0449421._comment
new file mode 100644
index 0000000000..fd9fa89715
--- /dev/null
+++ b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_3_1429ca784a03bc424b3537cbe0449421._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 3"
+ date="2014-04-07T21:55:19Z"
+ content="""
+Unfortunately all I have been able to tell for sure from this log is that it seems that the expensive transfer scan is not running, and this is unlikely to be a repository auto-repair.
+
+My best guess as to what might be going on is an update of the git-annex branch. 
+
+[2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"write-tree\"]
+
+This is prep for an index file commit, probably to the git-annex branch.
+
+[2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"rev-parse\",\"84068090af4bcd3d24f16d865ac07b0478f20ada:\"]
+
+This is a getting the parent commit's tree.
+
+The git-cat-file churn could then be a union merge reading the contents of the git-annex branch to union-merge it into the `.git/annex/index` (in `mergeIndex`). This would reuse the main git cat-file process.
+
+That does not explain why it would need to read eg, SHA256E-s106800355--c70e31d511e7eec4881a15dfba521ea3d1fe14694968f81ae1819f1a2a93f9be.mp4.log 28 times.
+Normally, during a union merge only files listed by `diff-index` need to be read, and it lists each file only once.
+"""]]
diff --git a/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_4_f9e65cf5598b4b14eeee1f41f46d4084._comment b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_4_f9e65cf5598b4b14eeee1f41f46d4084._comment
new file mode 100644
index 0000000000..148920c233
--- /dev/null
+++ b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_4_f9e65cf5598b4b14eeee1f41f46d4084._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 4"
+ date="2014-04-07T21:57:32Z"
+ content="""
+Does `git log git-annex` show a commit that was made at 23:30? 
+
+Does it show a commit 84068090af4bcd3d24f16d865ac07b0478f20ada?
+
+Is 84068090af4bcd3d24f16d865ac07b0478f20ada the parent of the 23:30 commit?
+"""]]
diff --git a/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_5_044ecac2d2e670e1ef69809c944093d1._comment b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_5_044ecac2d2e670e1ef69809c944093d1._comment
new file mode 100644
index 0000000000..6013650041
--- /dev/null
+++ b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_5_044ecac2d2e670e1ef69809c944093d1._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 5"
+ date="2014-04-07T22:12:14Z"
+ content="""
+Is the repository using direct mode?
+
+Another theory is that:
+
+* test/hello appears
+* watcher sees new symlink, tries to make a commit with it
+* master branch already has that symlink
+* this is why the write-tree is not followed by a commit-tree. The commit would have been empty. 
+
+If this is the case, then 84068090af4bcd3d24f16d865ac07b0478f20ada will be a ref on the master branch.
+
+And all of the above is normal operation. But it does suggest, that if this repo is in direct mode, it might be running a direct mode work tree update around then. Which requires a lot of cat-file queries of the git-annex branch. And would certainly make repeated queries at least if the repository has duplicate copies of some files..
+"""]]
diff --git a/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_6_6f4f51e1583bed5e7e601e4f30f4207b._comment b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_6_6f4f51e1583bed5e7e601e4f30f4207b._comment
new file mode 100644
index 0000000000..0b5f904894
--- /dev/null
+++ b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_6_6f4f51e1583bed5e7e601e4f30f4207b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 6"
+ date="2014-04-07T22:17:16Z"
+ content="""
+Does the git log have any recent commits that were \"git-annex automatic merge conflict fix\" ?
+"""]]
diff --git a/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_7_683a0a3d4caea0ee625e41ae8a6c7c06._comment b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_7_683a0a3d4caea0ee625e41ae8a6c7c06._comment
new file mode 100644
index 0000000000..1705e738cb
--- /dev/null
+++ b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_7_683a0a3d4caea0ee625e41ae8a6c7c06._comment
@@ -0,0 +1,81 @@
+[[!comment format=mdwn
+ username="http://johan.kiviniemi.name/"
+ nickname="Johan"
+ subject="comment 7"
+ date="2014-04-07T22:44:33Z"
+ content="""
+In the git-annex branch, there is
+
+* [[!toggle id=\"4deec8203e0baf7bb5b7d5d868d82439261ab3bc\" text=\"a commit at 23:21:51\"]] from my desktop box where I added `test/hello`
+
+[[!toggleable id=\"4deec8203e0baf7bb5b7d5d868d82439261ab3bc\" text=\"\"\"
+    commit 4deec8203e0baf7bb5b7d5d868d82439261ab3bc
+    Author: Johan Kiviniemi <devel@johan.kiviniemi.name>
+    Date:   Mon Apr 7 23:21:51 2014 +0300
+    
+        update
+    
+    diff --git a/992/280/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.log b/992/280/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.log
+    new file mode 100644
+    index 0000000..1cf060c
+    --- /dev/null
+    +++ b/992/280/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.log
+    @@ -0,0 +1 @@
+    +1396902111.893785s 1 86e07a59-8bba-4878-8d0b-5dfe8c6366c4
+\"\"\"]]
+
+* [[!toggle id=\"2e0884d9c8859339855ceee396b9ea9ae05865b4\" text=\"a commit at 23:21:54\"]] when the desktop box synced to the server (from which the log excerpt came)
+
+[[!toggleable id=\"2e0884d9c8859339855ceee396b9ea9ae05865b4\" text=\"\"\"
+    commit 2e0884d9c8859339855ceee396b9ea9ae05865b4
+    Author: Johan Kiviniemi <devel@johan.kiviniemi.name>
+    Date:   Mon Apr 7 23:21:54 2014 +0300
+    
+        update
+    
+    diff --git a/992/280/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e84
+    6f6be03.log b/992/280/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e8
+    46f6be03.log
+    index 1cf060c..cd0bccc 100644
+    --- a/992/280/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03
+    .log
+    +++ b/992/280/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03
+    .log
+    @@ -1 +1,2 @@
+    +1396902112.657779s 1 09ada430-8802-47da-bbfa-f5256a3c55d2
+     1396902111.893785s 1 86e07a59-8bba-4878-8d0b-5dfe8c6366c4
+\"\"\"]]
+
+* [[!toggle id=\"214ed317536695b91c8dd5bed059c46c11ad00be\" text=\"a commit at 23:24:24\"]] (2.5 minutes later!) when the assistant on the server finally merged `synced/git-annex` into `git-annex` (`test/hello` became visible in the working tree at that time).
+
+[[!toggleable id=\"214ed317536695b91c8dd5bed059c46c11ad00be\" text=\"\"\"
+    commit 214ed317536695b91c8dd5bed059c46c11ad00be
+    Merge: 4deec82 2e0884d
+    Author: sarjat <sarjat@alku.heh.fi>
+    Date:   Mon Apr 7 23:24:24 2014 +0300
+    
+        merging synced/git-annex into git-annex
+\"\"\"]]
+
+There is no commit in the `git-annex` branch at 23:30. The next commit is from unrelated changes at 00:06.
+
+[[!toggle id=\"84068090af4bcd3d24f16d865ac07b0478f20ada\" text=\"84068090af4bcd3d24f16d865ac07b0478f20ada\"]] is the commit in `master` which added `test/hello` at 23:21:51.
+
+[[!toggleable id=\"84068090af4bcd3d24f16d865ac07b0478f20ada\" text=\"\"\"
+    commit 84068090af4bcd3d24f16d865ac07b0478f20ada
+    Author: Johan Kiviniemi <devel@johan.kiviniemi.name>
+    Date:   Mon Apr 7 23:21:51 2014 +0300
+    
+    diff --git a/test/hello b/test/hello
+    new file mode 120000
+    index 0000000..8c2678f
+    --- /dev/null
+    +++ b/test/hello
+    @@ -0,0 +1 @@
+    +../.git/annex/objects/zK/02/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08
+    \ No newline at end of file
+\"\"\"]]
+
+The repository on the server is in indirect mode.
+
+"""]]
diff --git a/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_8_03dd76b01f46a7cc66eddac3e054c8ad._comment b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_8_03dd76b01f46a7cc66eddac3e054c8ad._comment
new file mode 100644
index 0000000000..d6aa43da05
--- /dev/null
+++ b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_8_03dd76b01f46a7cc66eddac3e054c8ad._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://johan.kiviniemi.name/"
+ nickname="Johan"
+ subject="comment 8"
+ date="2014-04-07T22:48:18Z"
+ content="""
+There are no commits in `master` or `git-annex` that have the word conflict in the description.
+"""]]
diff --git a/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_9_5f4444f03cbebaa44628288095383679._comment b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_9_5f4444f03cbebaa44628288095383679._comment
new file mode 100644
index 0000000000..09383141e0
--- /dev/null
+++ b/doc/bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory/comment_9_5f4444f03cbebaa44628288095383679._comment
@@ -0,0 +1,89 @@
+[[!comment format=mdwn
+ username="http://johan.kiviniemi.name/"
+ nickname="Johan"
+ subject="comment 9"
+ date="2014-04-07T22:55:12Z"
+ content="""
+[[!toggle id=\"excerpt\" text=\"The full log excerpt\"]] which includes the sync from the client and the final messages after the cat-file loop ended and things stabilized (but a memory leak of 30 MB in the git-annex assistant process remained).
+
+[[!toggleable id=\"excerpt\" text=\"\"\"
+    [2014-04-04 10:55:00 EEST] main: starting assistant version 5.20140402
+    
+    
+    
+    [2014-04-07 23:21:08 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"git-annex\"]
+    [2014-04-07 23:21:08 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2014-04-07 23:21:08 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..20d1f5538f6aa430f29ef938f6db045f5a69425d\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:21:08 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..b402a6e7b9268e25dbd9c6a027f4a5258993980d\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:21:08 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..7b18a191d58d779aab5789b923adb09863938ffe\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:21:08 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+    [2014-04-07 23:21:52 EEST] TransferWatcher: transfer starting: Download UUID \"86e07a59-8bba-4878-8d0b-5dfe8c6366c4\" SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03 Nothing
+    [2014-04-07 23:21:52 EEST] read: git [\"config\",\"--null\",\"--list\"]
+    [2014-04-07 23:21:52 EEST] TransferWatcher: transfer starting: Download UUID \"86e07a59-8bba-4878-8d0b-5dfe8c6366c4\" test/hello Nothing
+    [2014-04-07 23:21:52 EEST] read: git [\"config\",\"--null\",\"--list\"]
+    [2014-04-07 23:21:52 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"git-annex\"]
+    [2014-04-07 23:21:52 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2014-04-07 23:21:52 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..20d1f5538f6aa430f29ef938f6db045f5a69425d\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:21:52 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..4deec8203e0baf7bb5b7d5d868d82439261ab3bc\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:21:52 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..b402a6e7b9268e25dbd9c6a027f4a5258993980d\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:21:52 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..7b18a191d58d779aab5789b923adb09863938ffe\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:21:52 EEST] feed: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"update-index\",\"-z\",\"--index-info\"]
+    [2014-04-07 23:21:52 EEST] TransferWatcher: transfer finishing: Transfer {transferDirection = Download, transferUUID = UUID \"86e07a59-8bba-4878-8d0b-5dfe8c6366c4\", transferKey = Key {keyName = \"5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03\", keyBackendName = \"SHA256E\", keySize = Just 6, keyMtime = Nothing}}
+    [2014-04-07 23:21:52 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"4deec8203e0baf7bb5b7d5d868d82439261ab3bc\"]
+    [2014-04-07 23:21:52 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"4deec8203e0baf7bb5b7d5d868d82439261ab3bc..refs/heads/git-annex\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:21:52 EEST] call: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"update-ref\",\"refs/heads/git-annex\",\"4deec8203e0baf7bb5b7d5d868d82439261ab3bc\"]
+    [2014-04-07 23:22:08 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"symbolic-ref\",\"HEAD\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"refs/heads/master\"]
+    [2014-04-07 23:24:24 EEST] Merger: merging refs/heads/synced/master into refs/heads/master
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"--hash\",\"refs/heads/master\"]
+    [2014-04-07 23:24:24 EEST] call: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"merge\",\"--no-edit\",\"refs/heads/synced/master\"]
+    Updating 645e474..8406809
+    Fast-forward
+     test/hello |    1 +
+     1 file changed, 1 insertion(+)
+     create mode 120000 test/hello
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"git-annex\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..4deec8203e0baf7bb5b7d5d868d82439261ab3bc\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..2e0884d9c8859339855ceee396b9ea9ae05865b4\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..b402a6e7b9268e25dbd9c6a027f4a5258993980d\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..7b18a191d58d779aab5789b923adb09863938ffe\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:24:24 EEST] chat: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+    [2014-04-07 23:24:24 EEST] feed: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"update-index\",\"-z\",\"--index-info\"]
+    [2014-04-07 23:24:24 EEST] feed: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"update-index\",\"-z\",\"--index-info\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"2e0884d9c8859339855ceee396b9ea9ae05865b4\"]
+    [2014-04-07 23:24:24 EEST] chat: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"hash-object\",\"-t\",\"blob\",\"-w\",\"--stdin\",\"--no-filters\"]
+    [2014-04-07 23:24:24 EEST] feed: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"update-index\",\"-z\",\"--index-info\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"refs/heads/git-annex\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"write-tree\"]
+    [2014-04-07 23:24:24 EEST] chat: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"commit-tree\",\"0bd4352b4008165d356bc9b1250bdb456c675175\",\"-p\",\"refs/heads/git-annex\",\"-p\",\"2e0884d9c8859339855ceee396b9ea9ae05865b4\"]
+    [2014-04-07 23:24:24 EEST] call: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"update-ref\",\"refs/heads/git-annex\",\"214ed317536695b91c8dd5bed059c46c11ad00be\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+    [2014-04-07 23:24:24 EEST] Watcher: add symlink test/hello
+    [2014-04-07 23:24:24 EEST] chat: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"hash-object\",\"-t\",\"blob\",\"-w\",\"--stdin\",\"--no-filters\"]
+    [2014-04-07 23:24:24 EEST] Committer: committing 1 changes
+    [2014-04-07 23:24:24 EEST] Committer: Committing changes to git
+    [2014-04-07 23:24:24 EEST] feed: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"update-index\",\"-z\",\"--index-info\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"symbolic-ref\",\"HEAD\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"--hash\",\"refs/heads/master\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"write-tree\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"rev-parse\",\"84068090af4bcd3d24f16d865ac07b0478f20ada:\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"symbolic-ref\",\"HEAD\"]
+    [2014-04-07 23:24:24 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"refs/heads/master\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"git-annex\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..214ed317536695b91c8dd5bed059c46c11ad00be\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..2e0884d9c8859339855ceee396b9ea9ae05865b4\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..b402a6e7b9268e25dbd9c6a027f4a5258993980d\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..7b18a191d58d779aab5789b923adb09863938ffe\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"git-annex\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..214ed317536695b91c8dd5bed059c46c11ad00be\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..2e0884d9c8859339855ceee396b9ea9ae05865b4\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..b402a6e7b9268e25dbd9c6a027f4a5258993980d\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:30:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"log\",\"refs/heads/git-annex..7b18a191d58d779aab5789b923adb09863938ffe\",\"--oneline\",\"-n1\"]
+    [2014-04-07 23:31:13 EEST] read: git [\"--git-dir=/storage/sarjat/annex-sarjat/.git\",\"--work-tree=/storage/sarjat/annex-sarjat\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+\"\"\"]]
+"""]]
diff --git a/doc/bugs/Assistant_is_stuck_with___39__fuzztest__39__.mdwn b/doc/bugs/Assistant_is_stuck_with___39__fuzztest__39__.mdwn
new file mode 100644
index 0000000000..76c6ad4587
--- /dev/null
+++ b/doc/bugs/Assistant_is_stuck_with___39__fuzztest__39__.mdwn
@@ -0,0 +1,23 @@
+### Please describe the problem.
+
+I want to use Git Annex as a synchronization tool between external devices.  I did set up v7 repositories in two separate file systems placed on physically separate devices.  I created a systemd service that fires Git Annex Assistant in each of those file systems as soon as their corresponding devices are mounted.  The idea was to get automatic synchronization upon drag and drop of files to back up into either of the file systems.  What I noticed so far, is that things do not work well all the time.  There are several problems I encountered, but here I want to concentrate only on one.
+
+The first issue is that when doing some operations, at some point, Git Annex Assistant on either side stops synchronizing as if it would be stuck.  It's a race condition and cannot be easily reproduced.  Hence, I used `fuzztest` to prove that one can always get into that issue.  What I've noticed so far is that when this happens, it means that on either side there one of the Git Annex Assistant processes has spawned a child `git-annex transferkeys`, which is not present from the beginning but now is stuck there forever.  Most probably, this is the reason why synchronization stops.  That is during `fuzztest`, the files will keep accumulating but there will be no more automatic commits and/or pushes.
+
+### What steps will reproduce the problem?
+
+Just create two repos in v7 mode, make them remotes of each other, run assistants in each of them, and start `fuzztest` within each of them as well.
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 7.20190322-gece57002c6
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.6.4 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 7
+"""]]
diff --git a/doc/bugs/Assistant_only_watches_one_repo_on_startup.mdwn b/doc/bugs/Assistant_only_watches_one_repo_on_startup.mdwn
new file mode 100644
index 0000000000..70ccf4818f
--- /dev/null
+++ b/doc/bugs/Assistant_only_watches_one_repo_on_startup.mdwn
@@ -0,0 +1,29 @@
+### Please describe the problem.
+
+I have multiple git-annex assistant repos that I want watched.  On startup, it is only watching one of them, despite all of them being listed in ~/.config/git-annex/autostart.  
+
+Launching the webapp, clicking on the "switch repository" button, and selecting the other repository will cause git-annex to immediately launch a startup scan and thereafter it seems to be monitored.
+
+### What steps will reproduce the problem?
+
+killall git-annex, and then restart
+
+### What version of git-annex are you using? On what operating system?
+
+5.20151208-1 from jessie-backports
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Really nice tool.  Thanks Joey!
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Assistant_only_watches_one_repo_on_startup/comment_1_4606e5c7159e8e9f2f12e010cbd22e6a._comment b/doc/bugs/Assistant_only_watches_one_repo_on_startup/comment_1_4606e5c7159e8e9f2f12e010cbd22e6a._comment
new file mode 100644
index 0000000000..355b12a86f
--- /dev/null
+++ b/doc/bugs/Assistant_only_watches_one_repo_on_startup/comment_1_4606e5c7159e8e9f2f12e010cbd22e6a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-06-10T19:40:54Z"
+ content="""
+You're left out the command line which you use to start the assistant.
+
+Without that, I see no indication that there is a bug. You have to pass
+--autostart to make the assistant start up in all configured repositories. 
+If you are not using that parameter, the assistant will only start up in
+the repository corresponding to the current working directory.
+"""]]
diff --git a/doc/bugs/Assistant_temporary_delete_and_recommit_files.mdwn b/doc/bugs/Assistant_temporary_delete_and_recommit_files.mdwn
new file mode 100644
index 0000000000..4106b1ecfa
--- /dev/null
+++ b/doc/bugs/Assistant_temporary_delete_and_recommit_files.mdwn
@@ -0,0 +1,606 @@
+### Please describe the problem.
+Hi,
+
+I'm using git-annex assistant to sync my org-mode files between two hosts. Because these files are just plaintext, I configured git(-annex) to store the content inside git (and not annex). The setup is quite simple: On both hosts (laptop and server) there is a git-annex repository in `~/Org/Privat` which have a remote configured (over ssh) point to each other. I run "git-annex assistant" on both hosts and this works pretty well, except that `git-annex assistant` temporary delete and recommit files (probably during merge). This is no big deal because the file is still there but it unnecessarily messes up the `git log`. I'm not sure if this is a bug or just a side effect of how git-annex works.
+
+
+### What steps will reproduce the problem?
+
+    [Laptop]
+    mkdir -p ~/foo
+    cd ~/foo
+    git init
+    git annex init --version=6
+    git annex describe "laptop"
+    cat > .gitattributes << EOF
+    *.org annex.largefiles=nothing
+    *.org_archive annex.largefiles=nothing
+    EOF
+    git add .gitattributes
+    git commit -m "Versioning org-mode files with git"
+    git remote add server server:~/foo/
+
+
+
+    [Server]
+    git clone laptop:~/foo/ ~/foo/
+    cd ~/foo
+    git annex init "server"
+    git annex upgrade # update from v5 to v6
+    git annex assistant
+
+    [Laptop]
+    cd ~/foo
+    git annex assistant
+    echo "* this is a headline" >> test.org
+
+This is the basic setup. After editing test.org multiple times, the server get those changes, delete test.org and immediately recommit it. Unfortunately, I can't really reproduce the issue with the above instructions. I'm not sure if it's a timing problem, the content of the file matters or anything like that. Hopefully the attached `daemon.log` can provide more infos.
+
+
+### What version of git-annex are you using? On what operating system?
+    [Laptop, Debian stretch]
+    git-annex version: 6.20170101.1
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 6
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
+    [Server, Debian stretch]
+    git-annex version: 6.20180316
+    build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+    dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 6
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
+
+### Please provide any additional information below.
+daemon.log from server, interesting part:
+    [2018-04-09 11:37:44.985603501] Watcher: file deleted Eingang.org
+
+
+I'm also not sure where the `.#Eingang.org` comes from. (autosave-mode and backup stuff is disabled in Emacs). Note that I also ignore `.#` files:
+
+    *~
+    .#*
+    \#*#
+    .gitignore (END)
+
+[[!format sh """
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+[2018-04-09 11:34:41.651229076] main: starting assistant version 6.20180316
+[2018-04-09 11:34:41.653000679] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-04-09 11:34:41.656349808] process done ExitSuccess
+[2018-04-09 11:34:41.656682497] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-04-09 11:34:41.660412588] process done ExitSuccess
+[2018-04-09 11:34:41.660905012] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..19354e4a5c6bd694a449992d5bd0d4bae48eba3b","--pretty=%H","-n1"]
+[2018-04-09 11:34:41.664232695] process done ExitSuccess
+[2018-04-09 11:34:41.66500315] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-04-09 11:34:41.666629464] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-04-09 11:34:41.668907654] Cronner: You should enable consistency checking to protect your data. 
+[2018-04-09 11:34:41.673213064] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--","."]
+[2018-04-09 11:34:41.67746018] process done ExitSuccess
+[2018-04-09 11:34:41.677940071] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--","."]
+[2018-04-09 11:34:41.680803467] process done ExitSuccess
+[2018-04-09 11:34:41.682995824] chat: nice ["ionice","-c3","nocache","/usr/bin/git-annex","remotedaemon","--foreground"]
+[2018-04-09 11:34:41.698996042] TransferScanner: Syncing with laptop 
+[2018-04-09 11:34:41.714084077] TransferWatcher: watching for transfers
+[2018-04-09 11:34:41.71886081] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-tree","--full-tree","-z","--","refs/heads/git-annex","uuid.log","remote.log","trust.log","group.log","numcopies.log","schedule.log","preferred-content.log","required-content.log","group-preferred-content.log"]
+[2018-04-09 11:34:41.736468728] process done ExitSuccess
+[2018-04-09 11:34:41.737473438] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:34:41.740351978] process done ExitSuccess
+[2018-04-09 11:34:41.740604847] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:34:41.743608301] process done ExitSuccess
+[2018-04-09 11:34:41.743883152] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:34:41.746600971] process done ExitSuccess
+[2018-04-09 11:34:41.746859505] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:34:41.749864575] process done ExitSuccess
+
+  No known network monitor available through dbus; falling back to polling
+
+  No known volume monitor available through dbus; falling back to mtab polling
+[2018-04-09 11:34:41.75133072] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-04-09 11:34:41.755913773] process done ExitSuccess
+[2018-04-09 11:34:41.756133988] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-04-09 11:34:41.759413558] process done ExitSuccess
+[2018-04-09 11:34:41.759874669] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..19354e4a5c6bd694a449992d5bd0d4bae48eba3b","--pretty=%H","-n1"]
+[2018-04-09 11:34:41.763534204] process done ExitSuccess
+[2018-04-09 11:34:41.764491559] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-tree","--full-tree","-z","--","refs/heads/git-annex","uuid.log","remote.log","trust.log","group.log","numcopies.log","schedule.log","preferred-content.log","required-content.log","group-preferred-content.log"]
+[2018-04-09 11:34:41.768098522] process done ExitSuccess
+[2018-04-09 11:34:41.769538385] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","fetch","laptop"]
+[2018-04-09 11:34:41.774051138] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:34:41.784145283] process done ExitSuccess
+[2018-04-09 11:34:41.784410291] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:34:41.790119006] process done ExitSuccess
+[2018-04-09 11:34:41.790448451] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/heads/synced/master","--pretty=%H","-n1"]
+[2018-04-09 11:34:41.803315234] process done ExitSuccess
+[2018-04-09 11:34:41.803726537] Merger: merging refs/heads/synced/master into refs/heads/master
+
+[2018-04-09 11:34:41.803885147] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2018-04-09 11:34:41.806791552] process done ExitSuccess
+[2018-04-09 11:34:41.807106639] read: git ["--version"]
+[2018-04-09 11:34:41.809213293] process done ExitSuccess
+[2018-04-09 11:34:41.809579548] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","commit.gpgsign=false","merge","--no-edit","refs/heads/synced/master","--allow-unrelated-histories"]
+Aktualisiere 9d81724..1f72868
+Fast-forward
+ Eingang.org | 146 +++++++++++++++++++++++++++++++
+ Privat.org  | 284 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ 2 files changed, 430 insertions(+)
+ create mode 100644 Eingang.org
+ create mode 100644 Privat.org
+[2018-04-09 11:34:41.869190999] process done ExitSuccess
+[2018-04-09 11:34:41.869616621] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-04-09 11:34:41.87263735] process done ExitSuccess
+[2018-04-09 11:34:41.872886362] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-04-09 11:34:41.876100082] process done ExitSuccess
+[2018-04-09 11:34:41.876526799] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..19354e4a5c6bd694a449992d5bd0d4bae48eba3b","--pretty=%H","-n1"]
+[2018-04-09 11:34:41.879793847] process done ExitSuccess
+(scanning...) [2018-04-09 11:34:41.880538361] Watcher: Performing startup scan
+[2018-04-09 11:34:41.880979369] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-04-09 11:34:41.884247108] process done ExitSuccess
+[2018-04-09 11:34:41.884492946] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-04-09 11:34:41.887468992] process done ExitSuccess
+[2018-04-09 11:34:41.88788752] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..19354e4a5c6bd694a449992d5bd0d4bae48eba3b","--pretty=%H","-n1"]
+[2018-04-09 11:34:41.891145787] process done ExitSuccess
+[2018-04-09 11:34:41.891582283] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-04-09 11:34:41.892133862] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-04-09 11:34:41.900436044] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:34:41.903468755] process done ExitSuccess
+[2018-04-09 11:34:41.903676566] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:34:41.906280325] process done ExitSuccess
+[2018-04-09 11:34:41.906524648] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:34:41.908819698] process done ExitSuccess
+[2018-04-09 11:34:41.909024433] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:34:41.911759505] process done ExitSuccess
+[2018-04-09 11:34:41.912398343] read: git ["--version"]
+[2018-04-09 11:34:41.914443754] process done ExitSuccess
+[2018-04-09 11:34:41.914752675] chat: git ["--git-dir=.git","--work-tree=.","check-ignore","-z","--stdin","--verbose","--non-matching"]
+[2018-04-09 11:34:41.917108907] Watcher: add Eingang.org
+[2018-04-09 11:34:41.91734644] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/remotes/laptop/master","--pretty=%H","-n1"]
+[2018-04-09 11:34:41.920660043] process done ExitSuccess
+[2018-04-09 11:34:41.921055355] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+[2018-04-09 11:34:41.921800291] read: git ["--version"]
+[2018-04-09 11:34:41.925093152] process done ExitSuccess
+[2018-04-09 11:34:41.926328604] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:34:41.928840733] process done ExitSuccess
+[2018-04-09 11:34:41.929206878] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:34:41.934755521] process done ExitSuccess
+[2018-04-09 11:34:41.935152027] Merger: watching .git/refs
+[2018-04-09 11:34:41.958868627] Watcher: add Privat.org
+[2018-04-09 11:34:41.959579297] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--deleted","-z","--","."]
+[2018-04-09 11:34:41.962332644] process done ExitSuccess
+(started...) 
+[2018-04-09 11:34:41.962726051] Watcher: watching .
+Von laptop:Org/Privat
+   9d81724..1f72868  master        -> laptop/master
+   316555e..19354e4  git-annex     -> laptop/git-annex
+ * [neuer Branch]    synced/master -> laptop/synced/master
+[2018-04-09 11:34:41.997168884] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:34:42.004185608] process done ExitSuccess
+[2018-04-09 11:34:42.004431346] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:34:42.009686504] process done ExitSuccess
+[2018-04-09 11:34:42.010153632] process done ExitSuccess
+[2018-04-09 11:34:42.010482295] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-04-09 11:34:42.013335466] process done ExitSuccess
+[2018-04-09 11:34:42.013718719] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-04-09 11:34:42.019932467] process done ExitSuccess
+[2018-04-09 11:34:42.020329615] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..19354e4a5c6bd694a449992d5bd0d4bae48eba3b","--pretty=%H","-n1"]
+[2018-04-09 11:34:42.023886643] process done ExitSuccess
+[2018-04-09 11:34:42.024275073] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/remotes/laptop/master","--pretty=%H","-n1"]
+[2018-04-09 11:34:42.027633095] process done ExitSuccess
+[2018-04-09 11:34:42.028007368] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
+[2018-04-09 11:34:42.03206509] process done ExitSuccess
+[2018-04-09 11:34:42.03231932] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/laptop/master"]
+[2018-04-09 11:34:42.034779842] process done ExitSuccess
+[2018-04-09 11:34:42.035052574] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/remotes/laptop/master","--pretty=%H","-n1"]
+[2018-04-09 11:34:42.038557601] process done ExitSuccess
+[2018-04-09 11:34:42.038806754] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/laptop/synced/master"]
+[2018-04-09 11:34:42.041302446] process done ExitSuccess
+[2018-04-09 11:34:42.041621633] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/synced/master..refs/remotes/laptop/synced/master","--pretty=%H","-n1"]
+[2018-04-09 11:34:42.044851439] process done ExitSuccess
+[2018-04-09 11:34:42.045116323] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-04-09 11:34:42.048082132] process done ExitSuccess
+[2018-04-09 11:34:42.048322864] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-04-09 11:34:42.051728257] process done ExitSuccess
+[2018-04-09 11:34:42.052150695] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..19354e4a5c6bd694a449992d5bd0d4bae48eba3b","--pretty=%H","-n1"]
+[2018-04-09 11:34:42.055676191] process done ExitSuccess
+[2018-04-09 11:34:42.056232266] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:34:42.058900877] process done ExitSuccess
+[2018-04-09 11:34:42.059140096] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:34:42.062072724] process done ExitSuccess
+[2018-04-09 11:34:42.062321782] TransferScanner: pushing to [Remote { name ="laptop" }]
+[2018-04-09 11:34:42.062448681] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:34:42.065011986] process done ExitSuccess
+[2018-04-09 11:34:42.065252161] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:34:42.068152308] process done ExitSuccess
+[2018-04-09 11:34:42.069095635] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/remotes/laptop/synced/master","--pretty=%H","-n1"]
+[2018-04-09 11:34:42.069826395] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","+git-annex:synced/git-annex","master:synced/master"]
+[2018-04-09 11:34:42.073909169] process done ExitSuccess
+To laptop:Org/Privat
+ * [new branch]      git-annex -> synced/git-annex
+[2018-04-09 11:34:42.114149032] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-04-09 11:34:42.114953858] process done ExitSuccess
+[2018-04-09 11:34:42.115154911] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","git-annex"]
+[2018-04-09 11:34:42.118392157] process done ExitSuccess
+[2018-04-09 11:34:42.118622237] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-04-09 11:34:42.124076787] process done ExitSuccess
+[2018-04-09 11:34:42.124811487] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..19354e4a5c6bd694a449992d5bd0d4bae48eba3b","--pretty=%H","-n1"]
+[2018-04-09 11:34:42.131284656] process done ExitSuccess
+[2018-04-09 11:34:42.150151612] process done ExitSuccess
+[2018-04-09 11:34:42.150527374] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","master"]
+[2018-04-09 11:34:42.179702012] process done ExitSuccess
+[2018-04-09 11:34:42.700210723] Committer: committing 2 changes
+[2018-04-09 11:34:42.70055449] Committer: Committing changes to git
+(recording state in git...)
+[2018-04-09 11:34:42.70085964] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--force","--"]
+[2018-04-09 11:34:42.784196514] process done ExitSuccess
+[2018-04-09 11:34:42.785257124] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:34:42.791617178] process done ExitSuccess
+[2018-04-09 11:34:42.791841318] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2018-04-09 11:34:42.795239558] process done ExitSuccess
+[2018-04-09 11:34:42.795513253] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2018-04-09 11:34:42.799350469] process done ExitSuccess
+[2018-04-09 11:34:42.799629834] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","rev-parse","1f72868a7a2ebf60ca9e58ec154773d75115b9d8:"]
+[2018-04-09 11:34:42.803096203] process done ExitSuccess
+[2018-04-09 11:34:42.803365134] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:34:42.806041146] process done ExitSuccess
+[2018-04-09 11:34:42.80628186] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:34:42.809185013] process done ExitSuccess
+[2018-04-09 11:34:42.809474896] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
+[2018-04-09 11:34:42.813085481] process done ExitSuccess
+[2018-04-09 11:34:43.682704066] Pusher: Syncing with laptop 
+[2018-04-09 11:34:43.685333086] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:34:43.68940378] process done ExitSuccess
+[2018-04-09 11:34:43.689881594] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:34:43.693390894] process done ExitSuccess
+[2018-04-09 11:34:43.693694954] Pusher: pushing to [Remote { name ="laptop" }]
+[2018-04-09 11:34:43.694609849] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","+git-annex:synced/git-annex","master:synced/master"]
+[2018-04-09 11:34:43.710791388] RemoteControl: CONNECTED ssh://laptop/~/Org/Privat
+[2018-04-09 11:34:43.71113574] RemoteControl: fromList [UUID "234c34d9-5493-44aa-967f-8b915796a618"]
+Everything up-to-date
+[2018-04-09 11:34:43.727077172] process done ExitSuccess
+[2018-04-09 11:34:43.727454237] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","git-annex"]
+[2018-04-09 11:34:43.766167107] process done ExitSuccess
+[2018-04-09 11:34:43.766500325] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","master"]
+[2018-04-09 11:34:43.811781891] process done ExitSuccess
+[2018-04-09 11:34:44.181196303] TransferScanner: starting scan of [Remote { name ="laptop" }]
+[2018-04-09 11:34:44.182448533] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--"]
+[2018-04-09 11:34:44.228488077] process done ExitSuccess
+[2018-04-09 11:34:44.22870839] TransferScanner: finished scan of [Remote { name ="laptop" }]
+[2018-04-09 11:35:41.769179017] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-tree","--full-tree","-z","--","refs/heads/git-annex","uuid.log","remote.log","trust.log","group.log","numcopies.log","schedule.log","preferred-content.log","required-content.log","group-preferred-content.log"]
+[2018-04-09 11:35:41.774173415] process done ExitSuccess
+[2018-04-09 11:36:13.313726536] Watcher: add Eingang.org
+[2018-04-09 11:36:13.314592472] Watcher: file deleted .#Eingang.org
+[2018-04-09 11:36:13.314880376] Committer: committing 1 changes
+[2018-04-09 11:36:13.315012724] Committer: Committing changes to git
+[2018-04-09 11:36:13.315522929] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--force","--"]
+[2018-04-09 11:36:13.348942513] process done ExitSuccess
+(recording state in git...)
+[2018-04-09 11:36:13.349347047] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+[2018-04-09 11:36:13.386484644] process done ExitSuccess
+[2018-04-09 11:36:13.386779923] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:13.389185774] process done ExitSuccess
+[2018-04-09 11:36:13.389510587] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2018-04-09 11:36:13.392440035] process done ExitSuccess
+[2018-04-09 11:36:13.392732949] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2018-04-09 11:36:13.427572223] process done ExitSuccess
+[2018-04-09 11:36:13.427923407] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","rev-parse","1f72868a7a2ebf60ca9e58ec154773d75115b9d8:"]
+[2018-04-09 11:36:13.431080357] process done ExitSuccess
+[2018-04-09 11:36:13.431414943] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:13.433986742] process done ExitSuccess
+[2018-04-09 11:36:13.434288205] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:36:13.43725448] process done ExitSuccess
+[2018-04-09 11:36:13.437592844] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
+[2018-04-09 11:36:13.4409276] process done ExitSuccess
+[2018-04-09 11:36:13.441326536] Pusher: Syncing with laptop 
+[2018-04-09 11:36:13.441756651] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:13.444837303] process done ExitSuccess
+[2018-04-09 11:36:13.445166889] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:36:13.448357577] process done ExitSuccess
+[2018-04-09 11:36:13.448675589] Pusher: pushing to [Remote { name ="laptop" }]
+[2018-04-09 11:36:13.449509449] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","+git-annex:synced/git-annex","master:synced/master"]
+Everything up-to-date
+[2018-04-09 11:36:13.490272243] process done ExitSuccess
+[2018-04-09 11:36:13.490695983] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","git-annex"]
+[2018-04-09 11:36:13.528199661] process done ExitSuccess
+[2018-04-09 11:36:13.528538098] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","master"]
+[2018-04-09 11:36:13.562512923] process done ExitSuccess
+[2018-04-09 11:36:14.452568279] Committer: committing 1 changes
+[2018-04-09 11:36:14.452892251] Committer: Committing changes to git
+[2018-04-09 11:36:14.453110793] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:14.456921344] process done ExitSuccess
+[2018-04-09 11:36:14.45731823] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2018-04-09 11:36:14.461828918] process done ExitSuccess
+[2018-04-09 11:36:14.462244454] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2018-04-09 11:36:14.465199856] process done ExitSuccess
+[2018-04-09 11:36:14.465582073] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","rev-parse","1f72868a7a2ebf60ca9e58ec154773d75115b9d8:"]
+[2018-04-09 11:36:14.468458637] process done ExitSuccess
+[2018-04-09 11:36:14.468799034] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:14.471547079] process done ExitSuccess
+[2018-04-09 11:36:14.471853595] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:36:14.474845478] process done ExitSuccess
+[2018-04-09 11:36:14.475161153] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
+[2018-04-09 11:36:14.478481548] process done ExitSuccess
+[2018-04-09 11:36:15.563886253] Pusher: Syncing with laptop 
+[2018-04-09 11:36:15.564475349] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:15.56845368] process done ExitSuccess
+[2018-04-09 11:36:15.568873956] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:36:15.573271271] process done ExitSuccess
+[2018-04-09 11:36:15.573737154] Pusher: pushing to [Remote { name ="laptop" }]
+[2018-04-09 11:36:15.575005334] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","+git-annex:synced/git-annex","master:synced/master"]
+Everything up-to-date
+[2018-04-09 11:36:15.614114318] process done ExitSuccess
+[2018-04-09 11:36:15.614502392] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","git-annex"]
+[2018-04-09 11:36:15.653929632] process done ExitSuccess
+[2018-04-09 11:36:15.654325001] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","master"]
+[2018-04-09 11:36:15.693126157] process done ExitSuccess
+[2018-04-09 11:36:28.906543231] Watcher: add Eingang.org
+[2018-04-09 11:36:28.9075571] Watcher: file deleted .#Eingang.org
+[2018-04-09 11:36:28.907841012] Committer: committing 1 changes
+[2018-04-09 11:36:28.907976823] Committer: Committing changes to git
+[2018-04-09 11:36:28.908467825] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--force","--"]
+[2018-04-09 11:36:28.942067906] process done ExitSuccess
+(recording state in git...)
+[2018-04-09 11:36:28.94239642] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+[2018-04-09 11:36:28.982158922] process done ExitSuccess
+[2018-04-09 11:36:28.982429899] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:28.98502309] process done ExitSuccess
+[2018-04-09 11:36:28.985343324] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2018-04-09 11:36:28.988397366] process done ExitSuccess
+[2018-04-09 11:36:28.988708167] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2018-04-09 11:36:29.023882235] process done ExitSuccess
+[2018-04-09 11:36:29.024232929] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","rev-parse","1f72868a7a2ebf60ca9e58ec154773d75115b9d8:"]
+[2018-04-09 11:36:29.027517239] process done ExitSuccess
+[2018-04-09 11:36:29.027864] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","f966ae65d12ccffc312af47ceff025cbad91c221","--no-gpg-sign","-p","1f72868a7a2ebf60ca9e58ec154773d75115b9d8"]
+[2018-04-09 11:36:29.031510789] process done ExitSuccess
+[2018-04-09 11:36:29.031851849] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/master","4b4905f59851c29ddbf1c245d13098266c51be27"]
+[2018-04-09 11:36:29.035606493] process done ExitSuccess
+[2018-04-09 11:36:29.035905803] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:29.038544683] process done ExitSuccess
+[2018-04-09 11:36:29.039085199] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:36:29.042182652] process done ExitSuccess
+[2018-04-09 11:36:29.042514323] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
+[2018-04-09 11:36:29.046951109] process done ExitSuccess
+[2018-04-09 11:36:29.047323546] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:29.048148357] Pusher: Syncing with laptop 
+[2018-04-09 11:36:29.050543182] process done ExitSuccess
+[2018-04-09 11:36:29.050886803] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:36:29.054442432] process done ExitSuccess
+[2018-04-09 11:36:29.055031142] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:29.057832869] process done ExitSuccess
+[2018-04-09 11:36:29.058164071] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:36:29.061083988] process done ExitSuccess
+[2018-04-09 11:36:29.061406465] Pusher: pushing to [Remote { name ="laptop" }]
+[2018-04-09 11:36:29.061573814] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:29.064134558] process done ExitSuccess
+[2018-04-09 11:36:29.064441998] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:36:29.067405287] process done ExitSuccess
+[2018-04-09 11:36:29.068528484] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/heads/synced/master","--pretty=%H","-n1"]
+[2018-04-09 11:36:29.068801805] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","+git-annex:synced/git-annex","master:synced/master"]
+[2018-04-09 11:36:29.072287644] process done ExitSuccess
+To laptop:Org/Privat
+   1f72868..4b4905f  master -> synced/master
+[2018-04-09 11:36:29.126939523] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:29.129007245] process done ExitSuccess
+[2018-04-09 11:36:29.129421784] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","git-annex"]
+[2018-04-09 11:36:29.131751468] process done ExitSuccess
+[2018-04-09 11:36:29.132079594] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:36:29.136949419] process done ExitSuccess
+[2018-04-09 11:36:29.137239065] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/remotes/laptop/synced/master","--pretty=%H","-n1"]
+[2018-04-09 11:36:29.140617503] process done ExitSuccess
+[2018-04-09 11:36:29.161862199] process done ExitSuccess
+[2018-04-09 11:36:29.16237389] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","master"]
+[2018-04-09 11:36:29.20090369] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:29.201988286] process done ExitSuccess
+[2018-04-09 11:36:29.204332853] process done ExitSuccess
+[2018-04-09 11:36:29.204687171] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:36:29.207943434] process done ExitSuccess
+[2018-04-09 11:36:29.208323263] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/remotes/laptop/master","--pretty=%H","-n1"]
+[2018-04-09 11:36:29.211711264] process done ExitSuccess
+[2018-04-09 11:36:30.059006711] Committer: committing 1 changes
+[2018-04-09 11:36:30.059230003] Committer: Committing changes to git
+[2018-04-09 11:36:30.059357379] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:30.061820862] process done ExitSuccess
+[2018-04-09 11:36:30.062223878] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2018-04-09 11:36:30.064990209] process done ExitSuccess
+[2018-04-09 11:36:30.065375169] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2018-04-09 11:36:30.069576223] process done ExitSuccess
+[2018-04-09 11:36:30.069919208] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","rev-parse","4b4905f59851c29ddbf1c245d13098266c51be27:"]
+[2018-04-09 11:36:30.072788736] process done ExitSuccess
+[2018-04-09 11:36:30.073110243] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:30.075829716] process done ExitSuccess
+[2018-04-09 11:36:30.076124925] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:36:30.079137617] process done ExitSuccess
+[2018-04-09 11:36:30.079480821] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
+[2018-04-09 11:36:30.083511227] process done ExitSuccess
+[2018-04-09 11:36:31.203242705] Pusher: Syncing with laptop 
+[2018-04-09 11:36:31.203770975] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:36:31.20738917] process done ExitSuccess
+[2018-04-09 11:36:31.207759515] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:36:31.212090647] process done ExitSuccess
+[2018-04-09 11:36:31.212468233] Pusher: pushing to [Remote { name ="laptop" }]
+[2018-04-09 11:36:31.213635349] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","+git-annex:synced/git-annex","master:synced/master"]
+Everything up-to-date
+[2018-04-09 11:36:31.24862919] process done ExitSuccess
+[2018-04-09 11:36:31.249023428] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","git-annex"]
+[2018-04-09 11:36:31.284126372] process done ExitSuccess
+[2018-04-09 11:36:31.284485355] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","master"]
+[2018-04-09 11:36:31.319518403] process done ExitSuccess
+[2018-04-09 11:37:44.963088675] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:44.966932815] process done ExitSuccess
+[2018-04-09 11:37:44.967153854] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:44.971643779] process done ExitSuccess
+[2018-04-09 11:37:44.971907699] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/heads/synced/master","--pretty=%H","-n1"]
+[2018-04-09 11:37:44.975334885] process done ExitSuccess
+[2018-04-09 11:37:44.975583378] Merger: merging refs/heads/synced/master into refs/heads/master
+
+[2018-04-09 11:37:44.975715785] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2018-04-09 11:37:44.978548143] process done ExitSuccess
+[2018-04-09 11:37:44.97878846] read: git ["--version"]
+[2018-04-09 11:37:44.9809852] process done ExitSuccess
+[2018-04-09 11:37:44.981307187] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","commit.gpgsign=false","merge","--no-edit","refs/heads/synced/master","--allow-unrelated-histories"]
+Aktualisiere 4b4905f..1e93ab8
+[2018-04-09 11:37:44.985603501] Watcher: file deleted Eingang.org
+Fast-forward
+ Eingang.org | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+[2018-04-09 11:37:45.015531778] process done ExitSuccess
+[2018-04-09 11:37:45.020024283] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:45.023151518] process done ExitSuccess
+[2018-04-09 11:37:45.023371468] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:45.02639557] process done ExitSuccess
+[2018-04-09 11:37:45.031466881] Committer: committing 1 changes
+[2018-04-09 11:37:45.031772484] Committer: Committing changes to git
+[2018-04-09 11:37:45.031924501] Watcher: add Eingang.org
+(recording state in git...)
+[2018-04-09 11:37:45.032110655] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+[2018-04-09 11:37:45.035283993] process done ExitSuccess
+[2018-04-09 11:37:45.036044409] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:45.039234835] process done ExitSuccess
+[2018-04-09 11:37:45.039492196] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2018-04-09 11:37:45.042630173] process done ExitSuccess
+[2018-04-09 11:37:45.042981734] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2018-04-09 11:37:45.047116516] process done ExitSuccess
+[2018-04-09 11:37:45.047486142] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","rev-parse","1e93ab8142b8bb17e9e0c8905a1fd18ac21e4397:"]
+[2018-04-09 11:37:45.051027357] process done ExitSuccess
+[2018-04-09 11:37:45.051380622] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","3b9cd858a5dfefbde85709982d51c2cf70c2bae7","--no-gpg-sign","-p","1e93ab8142b8bb17e9e0c8905a1fd18ac21e4397"]
+[2018-04-09 11:37:45.055070888] process done ExitSuccess
+[2018-04-09 11:37:45.055575957] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/master","23edac69fdf1974824411bbc4e962bb37ba877d0"]
+[2018-04-09 11:37:45.059674278] process done ExitSuccess
+[2018-04-09 11:37:45.059981691] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:45.063167888] process done ExitSuccess
+[2018-04-09 11:37:45.063491598] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:45.066642148] process done ExitSuccess
+[2018-04-09 11:37:45.066983555] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
+[2018-04-09 11:37:45.071106509] process done ExitSuccess
+[2018-04-09 11:37:45.071691114] Pusher: Syncing with laptop 
+[2018-04-09 11:37:45.072263006] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:45.07493712] process done ExitSuccess
+[2018-04-09 11:37:45.075246682] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:45.078232243] process done ExitSuccess
+[2018-04-09 11:37:45.078881383] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:45.081568528] process done ExitSuccess
+[2018-04-09 11:37:45.081911449] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:45.084855103] process done ExitSuccess
+[2018-04-09 11:37:45.085170767] Pusher: pushing to [Remote { name ="laptop" }]
+[2018-04-09 11:37:45.085937221] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:45.088659937] process done ExitSuccess
+[2018-04-09 11:37:45.088961916] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:45.091923163] process done ExitSuccess
+[2018-04-09 11:37:45.093368856] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","+git-annex:synced/git-annex","master:synced/master"]
+[2018-04-09 11:37:45.095171302] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/heads/synced/master","--pretty=%H","-n1"]
+[2018-04-09 11:37:45.09889799] process done ExitSuccess
+[2018-04-09 11:37:45.099297672] Watcher: add Eingang.org
+To laptop:Org/Privat
+   1e93ab8..23edac6  master -> synced/master
+[2018-04-09 11:37:45.142813244] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:45.14435156] process done ExitSuccess
+[2018-04-09 11:37:45.144680359] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","git-annex"]
+[2018-04-09 11:37:45.146874025] process done ExitSuccess
+[2018-04-09 11:37:45.147115536] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:45.150090387] process done ExitSuccess
+[2018-04-09 11:37:45.150528273] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/remotes/laptop/synced/master","--pretty=%H","-n1"]
+[2018-04-09 11:37:45.154260324] process done ExitSuccess
+[2018-04-09 11:37:45.178355356] process done ExitSuccess
+[2018-04-09 11:37:45.178667467] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","master"]
+[2018-04-09 11:37:45.215080611] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:45.216096995] process done ExitSuccess
+[2018-04-09 11:37:45.218474735] process done ExitSuccess
+[2018-04-09 11:37:45.218797245] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:45.222475722] process done ExitSuccess
+[2018-04-09 11:37:45.222892395] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/remotes/laptop/master","--pretty=%H","-n1"]
+[2018-04-09 11:37:45.22635232] process done ExitSuccess
+[2018-04-09 11:37:46.073054429] Committer: committing 2 changes
+[2018-04-09 11:37:46.073357348] Committer: Committing changes to git
+(recording state in git...)
+[2018-04-09 11:37:46.073668003] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--force","--"]
+[2018-04-09 11:37:46.115020265] process done ExitSuccess
+[2018-04-09 11:37:46.115297828] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:46.117646357] process done ExitSuccess
+[2018-04-09 11:37:46.118005719] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2018-04-09 11:37:46.121575344] process done ExitSuccess
+[2018-04-09 11:37:46.12191231] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2018-04-09 11:37:46.12567614] process done ExitSuccess
+[2018-04-09 11:37:46.126023972] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","rev-parse","23edac69fdf1974824411bbc4e962bb37ba877d0:"]
+[2018-04-09 11:37:46.129133505] process done ExitSuccess
+[2018-04-09 11:37:46.129595522] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","a53bcee98b7883dc9ab92cfdc8a40c02557ccf04","--no-gpg-sign","-p","23edac69fdf1974824411bbc4e962bb37ba877d0"]
+[2018-04-09 11:37:46.133911504] process done ExitSuccess
+[2018-04-09 11:37:46.134222417] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/master","498b482206f92064205ba7b5dd057191ad278e3e"]
+[2018-04-09 11:37:46.13870126] process done ExitSuccess
+[2018-04-09 11:37:46.138982474] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:46.141654394] process done ExitSuccess
+[2018-04-09 11:37:46.142020296] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:46.145649381] process done ExitSuccess
+[2018-04-09 11:37:46.146010442] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
+[2018-04-09 11:37:46.150654031] process done ExitSuccess
+[2018-04-09 11:37:46.151027708] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:46.153712467] process done ExitSuccess
+[2018-04-09 11:37:46.154031515] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:46.157608747] process done ExitSuccess
+[2018-04-09 11:37:46.158107189] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:46.161188313] process done ExitSuccess
+[2018-04-09 11:37:46.161500737] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:46.164460849] process done ExitSuccess
+[2018-04-09 11:37:46.165020868] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/heads/synced/master","--pretty=%H","-n1"]
+[2018-04-09 11:37:46.169117625] process done ExitSuccess
+[2018-04-09 11:37:47.217100926] Pusher: Syncing with laptop 
+[2018-04-09 11:37:47.217699349] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:47.221401849] process done ExitSuccess
+[2018-04-09 11:37:47.221833584] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:47.225466461] process done ExitSuccess
+[2018-04-09 11:37:47.225805241] Pusher: pushing to [Remote { name ="laptop" }]
+[2018-04-09 11:37:47.22690315] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","+git-annex:synced/git-annex","master:synced/master"]
+Everything up-to-date
+[2018-04-09 11:37:47.262439321] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:47.263256084] process done ExitSuccess
+[2018-04-09 11:37:47.263663099] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","git-annex"]
+[2018-04-09 11:37:47.265655322] process done ExitSuccess
+[2018-04-09 11:37:47.266023431] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:47.270704463] process done ExitSuccess
+[2018-04-09 11:37:47.271058723] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/remotes/laptop/synced/master","--pretty=%H","-n1"]
+[2018-04-09 11:37:47.274346464] process done ExitSuccess
+[2018-04-09 11:37:47.298748348] process done ExitSuccess
+[2018-04-09 11:37:47.299087186] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","laptop","master"]
+[2018-04-09 11:37:47.333645742] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2018-04-09 11:37:47.334812765] process done ExitSuccess
+[2018-04-09 11:37:47.33762396] process done ExitSuccess
+[2018-04-09 11:37:47.337963852] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2018-04-09 11:37:47.341750677] process done ExitSuccess
+[2018-04-09 11:37:47.342184466] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/remotes/laptop/master","--pretty=%H","-n1"]
+[2018-04-09 11:37:47.345724578] process done ExitSuccess
+"""]]
+
+
+`git log`
+[[!format sh """
+commit 498b482206f92064205ba7b5dd057191ad278e3e
+Author: me
+Date:   Mon Apr 9 11:37:46 2018 +0200
+
+    git-annex in server
+
+:000000 100644 0000000... 0bf8613... A  Eingang.org
+
+commit 23edac69fdf1974824411bbc4e962bb37ba877d0
+Author: me
+Date:   Mon Apr 9 11:37:45 2018 +0200
+
+    git-annex in server
+
+:100644 000000 0bf8613... 0000000... D  Eingang.org
+
+commit 1e93ab8142b8bb17e9e0c8905a1fd18ac21e4397
+Author: me
+Date:   Mon Apr 9 11:37:44 2018 +0200
+
+    git-annex in laptop
+
+:100644 100644 450fc30... 0bf8613... M  Eingang.org
+
+"""]]
diff --git a/doc/bugs/Attempting_to_repair_repository_almost_every_day.mdwn b/doc/bugs/Attempting_to_repair_repository_almost_every_day.mdwn
new file mode 100644
index 0000000000..6925606f0e
--- /dev/null
+++ b/doc/bugs/Attempting_to_repair_repository_almost_every_day.mdwn
@@ -0,0 +1,5 @@
+I'm using the webapp on my two main computers with up-to-date Debian (one has testing and the other one sid) and I have consistency checks scheduled every day.
+
+The problem is that almost every time the check runs I'm getting the "Attempting to repair" message and git-annex starts using 100% CPU for quite a while, but after it it seams to have done no change to the git tree or the files.
+
+The two computers are never on at the same time, but they are constantly syncing files (through box.com), I don't now if downloading files while the check is in progress might have something to do.
diff --git a/doc/bugs/Auto-repair_greatly_slows_down_the_machine.mdwn b/doc/bugs/Auto-repair_greatly_slows_down_the_machine.mdwn
new file mode 100644
index 0000000000..6c1420e54a
--- /dev/null
+++ b/doc/bugs/Auto-repair_greatly_slows_down_the_machine.mdwn
@@ -0,0 +1,21 @@
+### Please describe the problem.
+
+The assistant regulary ends up trying to perform repair (I don't know why, it happens fairly often, once a week or so). When it does so, it ends up creating a huge (2.4G) .git/objects directory, and a git prune-packed process uses so much I/O the machine really slows down.
+
+### What steps will reproduce the problem?
+
+I don't have any reliable way to reproduce it. The repository ends up being attempted to be repaired around once a week. This week the repair (and the slowdown) also happened on a second computer.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20140221-gbdfc8e1 (using the standalone 64bit builds)
+
+This is on an up-to-date Arch Linux. It also happened on Fedora 20.
+
+### Please provide any additional information below.
+
+The daemon.log is fairly long, but not particulary interesting: [[https://ssl.zerodogg.org/~zerodogg/private/tmp/daemon.log-2014-02-25.1]]
+
+The «resource vanished (Broken pipe)» at the end is the result of me killing the prune-packed in order to be able to use the machine again.
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_10_d46c6314bff75a0ae679bc2358b28c2b._comment b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_10_d46c6314bff75a0ae679bc2358b28c2b._comment
new file mode 100644
index 0000000000..5fb031e256
--- /dev/null
+++ b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_10_d46c6314bff75a0ae679bc2358b28c2b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="80.202.103.55"
+ subject="comment 10"
+ date="2014-06-07T05:47:25Z"
+ content="""
+Given that it's ususally the same repo, I'm going to try to create a completely fresh repository instead and see if the frequent auto-repairs are stopped by that.
+"""]]
diff --git a/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_11_1c2c3adfbccd2b14a7d1c4618800e735._comment b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_11_1c2c3adfbccd2b14a7d1c4618800e735._comment
new file mode 100644
index 0000000000..904ec92f55
--- /dev/null
+++ b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_11_1c2c3adfbccd2b14a7d1c4618800e735._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 11"
+ date="2014-06-10T19:31:38Z"
+ content="""
+Disable consistency checks for the repo in the webapp UI, wait until long enough that you're sure the assistant would be wanting to repair it again if you hadn't disabled that, and run `git annex repair` at the console so I can see what's going on.
+"""]]
diff --git a/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_1_a52e4ef04209d0a2449165e2b4cb9ccc._comment b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_1_a52e4ef04209d0a2449165e2b4cb9ccc._comment
new file mode 100644
index 0000000000..b50a0cfb82
--- /dev/null
+++ b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_1_a52e4ef04209d0a2449165e2b4cb9ccc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.146"
+ subject="comment 1"
+ date="2014-02-26T17:38:05Z"
+ content="""
+Auto repair is not intended to be a common occurrance. It means something went badly, horribly wrong on your machine, and it lost data that git wrote to disk. It's more important in such a scenraio to get back to a working system eventually than to do something fast or inexpensively.
+
+If you're seeing the need for auto repair on a weekly basis, your computer is failing in a horrible way horribly frequently, and the thing to do is to find out why, and fix that. Perhaps you need to start cleanly shutting down the system. Perhaps something is causing your computer to crash, and you need to fix that.
+"""]]
diff --git a/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_2_9f5340ab1012f335af0c246b82c1a777._comment b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_2_9f5340ab1012f335af0c246b82c1a777._comment
new file mode 100644
index 0000000000..6cbd58f2f3
--- /dev/null
+++ b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_2_9f5340ab1012f335af0c246b82c1a777._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="80.202.213.223"
+ subject="comment 2"
+ date="2014-02-27T14:16:11Z"
+ content="""
+That's the thing. The drive is fine, I've fscked it, and the machine is always shut down cleanly (and it is very stable, can't remember the last time it crashed). So there's no reason why this should be happening, and since git-annex doesn't say anything about why it started the auto-repair, I'm unable to track it down further.
+
+It's also always this repository. I have several assistant managed repos on the same machine, and this is the only one that git-annex regulary starts repairing (and the only one that it has auto-repaired on another box as well). No files in the repository itself has ever been noticed as corrupt, nor has there been any indications anywhere else about problems, hardware or filesystem (nothing wrong in the 40 or so git repos on the machine, no problems with software installed on the drive, never seen anything in dmesg).
+
+It's happening often enough for me to have to consider dropping use of the assistant. It could still be a problem with the machine (though it seems unlikely, given that it's consistently the same repo, and that it has done it with the same repo on other machines), but git-annex doesn't provide any information about it.
+
+Could you add some more information about what it thinks is wrong to the logging?
+
+Funnily enough, git-annex started repairing it again as I was writing this.
+"""]]
diff --git a/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_3_67bfccf0934075559d439b1deafc001e._comment b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_3_67bfccf0934075559d439b1deafc001e._comment
new file mode 100644
index 0000000000..edf7c781b8
--- /dev/null
+++ b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_3_67bfccf0934075559d439b1deafc001e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnX1msQxnLoSeu7q-i-c9BWghonsN7Qmns"
+ nickname="Jan Ulrich"
+ subject="comment 3"
+ date="2014-03-05T11:47:06Z"
+ content="""
+I observe something similar. Today git-annex started to repair a repository. CPU is at 100%, I can still work because I have a multikernel system, so I'll wait and see if it comes to an end.
+
+"""]]
diff --git a/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_4_5fa785aa759d1a1917f2a292324fe5ec._comment b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_4_5fa785aa759d1a1917f2a292324fe5ec._comment
new file mode 100644
index 0000000000..3a43c92603
--- /dev/null
+++ b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_4_5fa785aa759d1a1917f2a292324fe5ec._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnX1msQxnLoSeu7q-i-c9BWghonsN7Qmns"
+ nickname="Jan Ulrich"
+ subject="comment 4"
+ date="2014-03-06T06:21:59Z"
+ content="""
+Just for the records. I just shutdown the daemon because it ran all night long with 100%. 
+"""]]
diff --git a/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_5_9fe529034ad0115792b58d7da99c167e._comment b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_5_9fe529034ad0115792b58d7da99c167e._comment
new file mode 100644
index 0000000000..4683165c37
--- /dev/null
+++ b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_5_9fe529034ad0115792b58d7da99c167e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.146"
+ subject="comment 5"
+ date="2014-03-06T18:14:37Z"
+ content="""
+auto-repair is only done if git fsck detects a problem. You can run git fsck yourself to see.
+"""]]
diff --git a/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_6_93ed991ef2a74c18575073ca72e06185._comment b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_6_93ed991ef2a74c18575073ca72e06185._comment
new file mode 100644
index 0000000000..05935b034d
--- /dev/null
+++ b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_6_93ed991ef2a74c18575073ca72e06185._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnX1msQxnLoSeu7q-i-c9BWghonsN7Qmns"
+ nickname="Jan Ulrich"
+ subject="comment 6"
+ date="2014-03-10T14:14:06Z"
+ content="""
+I manually ran git fsck without problems but git-annex still wants to repair something.
+"""]]
diff --git a/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_7_4649fa11745ff668e43833209811d005._comment b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_7_4649fa11745ff668e43833209811d005._comment
new file mode 100644
index 0000000000..58499da8bb
--- /dev/null
+++ b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_7_4649fa11745ff668e43833209811d005._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.3"
+ subject="comment 7"
+ date="2014-05-21T18:31:54Z"
+ content="""
+It seems to me that if you don't want to repair your repository, you can just go into the webapp and disable all scheduled consistency check jobs.
+
+If someone with this problem would like to run \"git annex repair\" at the console, and paste the output, perhaps I could then see why it thinks it needs to repair the repository. So far, I have nothing to go on, and no proof that this is a bug at all, and not just people with actually corrupted repositories that really do need to be repaired.
+"""]]
diff --git a/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_8_6138a48f0b7e8be2bb66430397afdf5a._comment b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_8_6138a48f0b7e8be2bb66430397afdf5a._comment
new file mode 100644
index 0000000000..33944ac273
--- /dev/null
+++ b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_8_6138a48f0b7e8be2bb66430397afdf5a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="80.202.103.55"
+ subject="comment 8"
+ date="2014-05-21T19:19:30Z"
+ content="""
+The trouble with providing more information (outside of the logfile above) is that by the time I realize that there is a problem it is because git-annex has started to repair. Perhaps an option that makes git-annex write a ~/.git/annex/repair-reason.log file with the reason (ie. git fsck output etc.) for starting the repair could help?
+"""]]
diff --git a/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_9_3da5940bb2e9689b00239eec9a073f1c._comment b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_9_3da5940bb2e9689b00239eec9a073f1c._comment
new file mode 100644
index 0000000000..8bea236edc
--- /dev/null
+++ b/doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_9_3da5940bb2e9689b00239eec9a073f1c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="80.202.103.55"
+ subject="comment 9"
+ date="2014-06-06T16:13:55Z"
+ content="""
+Any chance of any progress on this? Either a way to disable it, or some additional logging to track down the problem? git-annex is currently repairing one particular repository several times a month accross different machines, rendering git-annex practically unusable.
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android.mdwn b/doc/bugs/Bootstrap3_icons_missing_on_Android.mdwn
new file mode 100644
index 0000000000..480825bc9c
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android.mdwn
@@ -0,0 +1,7 @@
+I’m running git-annex 5.20140517-gee56d21 on Android 4.3.
+
+A number of icons seem to be missing since the bootstrap3 update:
+
+<img src="http://heh.fi/tmp/git-annex-missing-icons.png" alt="git-annex missing icons" width="540">
+
+[[!tag confirmed done]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_10_da4e26c77376a8171493a815bdb51ff1._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_10_da4e26c77376a8171493a815bdb51ff1._comment
new file mode 100644
index 0000000000..78732490fa
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_10_da4e26c77376a8171493a815bdb51ff1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc"
+ nickname="Sören"
+ subject="comment 10"
+ date="2014-05-28T15:03:26Z"
+ content="""
+Seems to work! The icons show up on android now.
+
+But JavaScript seems to be broken instead, dropdown menus don't work. Maybe more unwanted evil splicing in other files?
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_11_506e26de284a6429366def33b007bc0c._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_11_506e26de284a6429366def33b007bc0c._comment
new file mode 100644
index 0000000000..ba3fff8011
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_11_506e26de284a6429366def33b007bc0c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc"
+ nickname="Sören"
+ subject="comment 11"
+ date="2014-05-28T17:30:43Z"
+ content="""
+Ok it seems like the linebreak at the end of each javascript file (0x0a) is replaced by a null byte on android. This probably causes the browser not to accept it as javascript so it's not executed.
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_12_a77477951576fc657d693811f11f9975._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_12_a77477951576fc657d693811f11f9975._comment
new file mode 100644
index 0000000000..23b523bbe4
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_12_a77477951576fc657d693811f11f9975._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 12"
+ date="2014-05-28T22:31:21Z"
+ content="""
+The evilspliced data for eg, bootstrap.js omits that last byte. So presumably we overflow one byte and find a null (if we're lucky..).
+
+I checked the -ddump-splices output, and it omits that last newline!
+
+<pre>
+              \});\
+              \\
+              \})( jQuery );\"#),
+</pre>
+
+Indeed, ghc omits any number of trailing newlines in this display.
+
+This is probably only recently a problem because of the wacky use of a unsafe bytestring + length that file-embed has started to do. Before, the newline was not included, but that's still valid JS.
+
+So, one fix would be to have the EvilSplicer rewrite the unsafePackAddressLen back to a regular bytestring construction. But this would need some tricky parsing (need to find the end of the string to remove the # from it). Alternatively, could remove trailing newlines from all the static js and css files. (Luckily none of the other static files end in a newline, and ghc is careful to preserve ending NULs etc).
+
+For now, I've removed the trailing newlines from the files.
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_13_c3ef67bded8ed3c511a8ea85b8bd81a5._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_13_c3ef67bded8ed3c511a8ea85b8bd81a5._comment
new file mode 100644
index 0000000000..dc8b24ba1b
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_13_c3ef67bded8ed3c511a8ea85b8bd81a5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc"
+ nickname="Sören"
+ subject="comment 13"
+ date="2014-05-29T16:48:18Z"
+ content="""
+Works fine now (tested on android 4.4).
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_1_97cf233d8401d642337d5fe9dd525e2b._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_1_97cf233d8401d642337d5fe9dd525e2b._comment
new file mode 100644
index 0000000000..15b6018b52
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_1_97cf233d8401d642337d5fe9dd525e2b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.3"
+ subject="comment 1"
+ date="2014-05-21T17:10:24Z"
+ content="""
+reproduced this with android 4.0
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_2_4981a0a894b77e94a3bffec82b0f6e51._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_2_4981a0a894b77e94a3bffec82b0f6e51._comment
new file mode 100644
index 0000000000..5404fbe497
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_2_4981a0a894b77e94a3bffec82b0f6e51._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.3"
+ subject="comment 2"
+ date="2014-05-21T18:06:09Z"
+ content="""
+I've verified that the assistant is serving up the files, such as http://127.0.0.1:$port/static/fonts/glyphicons-halflings-regular.svg
+
+I've verified that the files it's serving have the right content.
+
+This seems to only leave the likely explanation that the android web browser doesn't support the technology bootstrap 3 is using for its icons. This is svg, plus ttf, plus Embedded OpenType and Web Open Font Format. (I suppose it uses different ones on different browsers.)
+
+I'm surprised that bootstrap would be using web fonts technology if it's not supported on Android, or wouldn't have a fallback to the plain old image method old versions of bootstrap used.
+
+I have found some bootstrap bugs about icons not showing up on Android, like this one <https://github.com/twbs/bootstrap/issues/10106> ... but those are about specific icons not showing up due to unicode issues. Not about all icons failing to show up.
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_3_dbe960392aaa0839886381820754814a._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_3_dbe960392aaa0839886381820754814a._comment
new file mode 100644
index 0000000000..f6f4e48798
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_3_dbe960392aaa0839886381820754814a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc"
+ nickname="Sören"
+ subject="comment 3"
+ date="2014-05-21T18:47:42Z"
+ content="""
+I don't think it's an issue with the Android browser. It happens with Chrome and Firefox on Android as well. Moreover, the icons still don't show up if open the Webapp running on Android over network from a desktop browser. Firebug doesn't even show the request that should load the font file (compare to the desktop version where it loads the woff file in Firefox). So I suspect the Web server behaves different somehow. Some weird blocking issue maybe?
+
+Not sure if this is related but I noticed a strange behavior: If I try to download the font file in a new tab, it blocks until I refresh the tab running the webapp. Only seen on desktop Firefox. Doesn't happen in Chromium.
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_4_cdf9621fe3e9f8eb8b7af88f779a7116._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_4_cdf9621fe3e9f8eb8b7af88f779a7116._comment
new file mode 100644
index 0000000000..dabc21ccee
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_4_cdf9621fe3e9f8eb8b7af88f779a7116._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc"
+ nickname="Sören"
+ subject="comment 4"
+ date="2014-05-21T19:19:45Z"
+ content="""
+I forgot to mention that the --listen argument doesn't seem to work on Android so I used ssh -R in order to access the webapp from my desktop.
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_5_a2318f094b30f58fefc072807896c099._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_5_a2318f094b30f58fefc072807896c099._comment
new file mode 100644
index 0000000000..9f18e604e4
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_5_a2318f094b30f58fefc072807896c099._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc"
+ nickname="Sören"
+ subject="comment 5"
+ date="2014-05-27T19:58:37Z"
+ content="""
+On Android, the webserver returns a broken bootstrap.css. It seems like some binary garbage is appended to the end of the css file that looks suspiciously like the content or some fragment of the font file \"glyphicons-halflings-regular.eot\". Reason unknown.
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_6_7c2f1d914793798708ca13b6ac3dd474._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_6_7c2f1d914793798708ca13b6ac3dd474._comment
new file mode 100644
index 0000000000..8806de16f4
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_6_7c2f1d914793798708ca13b6ac3dd474._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 6"
+ date="2014-05-27T20:23:03Z"
+ content="""
+I checked the evilspliced tmp/androidtree/Assistant/WebApp/Types.hs, and the bootstrap.css there ends correctly, nothing weird appended.
+
+The TH generated for this:
+
+<pre>
+       (\"css/bootstrap.css\", 
+        GHC.IO.unsafePerformIO
+          (Data.ByteString.Unsafe.unsafePackAddressLen
+             121220
+             file_content_omitted)
+</pre>
+
+That looks right, in particular the size is the same as the number of bytes in the file.
+
+Hmm.. To double-check, I edited the file so that the string containing the content of this file was defined in foo.
+
+<pre>
+*Main> length foo
+113023
+</pre>
+
+This might be innocuous; there are some unicode characters in the string that encode to multiple bytes. OTOH, if you see exactly 8197 bytes of extra garbage appended, I think we have our culprit.
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_7_a24b5165590b5d58919da1003cd20c54._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_7_a24b5165590b5d58919da1003cd20c54._comment
new file mode 100644
index 0000000000..194d1c8311
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_7_a24b5165590b5d58919da1003cd20c54._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 7"
+ date="2014-05-28T00:02:42Z"
+ content="""
+The string is indeed truncated; it seems that something, probably the EvilSplicer is doing effectively a s/\w+:// on the string.
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_8_71ed14b8e5a898b1643d5e37591c2476._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_8_71ed14b8e5a898b1643d5e37591c2476._comment
new file mode 100644
index 0000000000..f5bc22ec74
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_8_71ed14b8e5a898b1643d5e37591c2476._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 8"
+ date="2014-05-28T00:04:58Z"
+ content="""
+Almost certinaly the EvilSplicer; it contains a hack to remove package-version qualifications from symbols. (s/package-version:symbol/symbol/)
+"""]]
diff --git a/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_9_15357e33c2431080d45f7cef5f4f1209._comment b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_9_15357e33c2431080d45f7cef5f4f1209._comment
new file mode 100644
index 0000000000..65db845566
--- /dev/null
+++ b/doc/bugs/Bootstrap3_icons_missing_on_Android/comment_9_15357e33c2431080d45f7cef5f4f1209._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 9"
+ date="2014-05-28T00:37:30Z"
+ content="""
+[[!commit 37da3d7b5dcfd328aee6a7a91508b02edf720bca]] should fix this problem. I've verified the truncation is not present in the spliced source; lack bandwidh to test the binary right now.
+"""]]
diff --git a/doc/bugs/Broken_symlinks_in_directory_remote_causes_crash.mdwn b/doc/bugs/Broken_symlinks_in_directory_remote_causes_crash.mdwn
new file mode 100644
index 0000000000..db5ebbddb8
--- /dev/null
+++ b/doc/bugs/Broken_symlinks_in_directory_remote_causes_crash.mdwn
@@ -0,0 +1,37 @@
+### Please describe the problem.
+
+I have a directory remote with importtree=yes.  In that remote, I have some symlinks that are broken.  (Long story; this is a file server and they work on the system that has mounted them, but are broken here.)
+
+### What steps will reproduce the problem?
+
+I've added it with `git config remote.source.annex-tracking-branch main:$REPO`.  When I run `git annex sync`, I get:
+
+```
+commit 
+On branch adjusted/main(unlocked)
+nothing to commit, working tree clean
+ok
+list source 
+git-annex: Unable to list contents of source: [redacted]: getFileStatus: does not exist (No such file or directory)
+failed
+git-annex: sync: 1 failed
+```
+
+### What version of git-annex are you using? On what operating system?
+
+8.20210223-2 on Debian
+
+### Please provide any additional information below.
+
+I would like git-annex to either:
+
+1. Store the symlink as a symlink, or
+2. Ignore bad symlinks
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Loading in other parts of my photo collection as we speak!
+
+> [[fixed|done]], by ignoring the broken symlink. (There is a todo
+> about importing symlinks,
+>[[todo/import_symlinks_when_importing_from_directory]])--[[Joey]]
diff --git a/doc/bugs/Button_to_cancel_conistency_checks.mdwn b/doc/bugs/Button_to_cancel_conistency_checks.mdwn
new file mode 100644
index 0000000000..2fd63dd2a8
--- /dev/null
+++ b/doc/bugs/Button_to_cancel_conistency_checks.mdwn
@@ -0,0 +1,21 @@
+### Please describe the problem.
+
+Sometimes a consistency check is undesired, e.g. when one wants to unmount the external drive. Add a button (along Configure) to the bubble that says Consistency check in progress to the assistent.
+
+### What steps will reproduce the problem?
+
+Run an automatic conistency check.
+
+### What version of git-annex are you using? On what operating system?
+
+20141024
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/CHECKPRESENT_could_check_file_size_as_well.mdwn b/doc/bugs/CHECKPRESENT_could_check_file_size_as_well.mdwn
new file mode 100644
index 0000000000..83c87c355d
--- /dev/null
+++ b/doc/bugs/CHECKPRESENT_could_check_file_size_as_well.mdwn
@@ -0,0 +1,7 @@
+The [external special remote protocol](http://git-annex.branchable.com/design/external_special_remote_protocol/) CHECKPRESENT command has no support for checking the file size.
+
+In many cases a special remote is able to fetch the size of an object as it checks its availability with no additional cost (for example when you use the `stat()` function: the size is already included in the response). The remote protocol could be extended so that the backend returns the size with the CHECKPRESENT-SUCCESS command, so that git-annex can provide a primitive but probably useful additional integrity check. This is helpful, for example, to detect bugs that result in the truncation of a file in the special remote; or to detect the case of an aborted upload that resulted in the file being checked into the remote anyway.
+
+When it is not easy to get the file size without incurring in additional costs, the backend can simply return a flag value like `-1` to tell git-annex to ignore it.
+
+There is a delicate point in how git-annex computes the expected object size for an encrypted remote. I do not know if there is a way to compute the size of a file after it has been encrypted with HMAC/GPG without actually performing all the computation. In line of principle it should not be difficult, but I do not know the details.
diff --git a/doc/bugs/CHECKPRESENT_could_check_file_size_as_well/comment_1_7bbba896da745a8a6b69ec62bf71fc89._comment b/doc/bugs/CHECKPRESENT_could_check_file_size_as_well/comment_1_7bbba896da745a8a6b69ec62bf71fc89._comment
new file mode 100644
index 0000000000..e917ec9988
--- /dev/null
+++ b/doc/bugs/CHECKPRESENT_could_check_file_size_as_well/comment_1_7bbba896da745a8a6b69ec62bf71fc89._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 1"
+ date="2015-01-06T17:41:45Z"
+ content="""
+The encrypted content size is not constant, and not known to git-annex.
+
+The only git-annex remote that checks the size in its checkpresent implementation is the web special remote, precisely because it's never encrypted. Also because files on the web change content from time to time and so that needs to be detected.
+
+What would make sense is to extend the reply to `CHECKPRESENT-SUCCESS Key [size]` or perhaps `CHECKPRESENT-SIZE Key size`. git-annex can then compare the value with the key's known size, if any. If the key is encrypted, it would need to skip this check.
+
+Note that chunk keys currently have their keySize inherited from the parent key, and the keyChunkSize of each chunk key is set to the key size. The last chunk of a key will typically be shorter than its keyChunkSize. That would need to be cleaned up.
+"""]]
diff --git a/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive.mdwn b/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive.mdwn
new file mode 100644
index 0000000000..06d01733c7
--- /dev/null
+++ b/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive.mdwn
@@ -0,0 +1,64 @@
+### Please describe the problem.
+
+I have created a git-annex via Windows. If I use sshfs to mount this
+onto a Linux server, and then setup a new remote, I encounter the
+error:
+
+    fatal: cannot run hooks/post-receive: No such file or directory
+
+I've already identified that, due to the Windows created repository,
+the script uses crlf line-endings. And of course, the Linux kernel
+interprets the carriage-return as a trailing component of the shebang
+
+    #!/bin/sh^M
+
+and obviously can't find the executable.
+
+I've already worked around this by using a binfmt_misc approach
+workaround, registering the shebang with ^M to trigger a wrapper
+script. But I'm seeking the permanent fix of git-annex creating these
+hooks with unix line-endings only. I think it's fair to say, there's
+currently no approach that allows hooks to be in any other form than
+unix scripts, and I'm happy to stand corrected, that it makes little
+sense to have any other line-endings.
+
+### What steps will reproduce the problem?
+
+Run git annex sync against a Windows created remote git-annex, however
+that is mounted, on a Linux/unix host.
+
+### What version of git-annex are you using? On what operating system?
+
+    $ git annex version
+    git-annex version: 8.20210223
+
+on a Debian bullseye operating system.
+
+### Please provide any additional information below.
+
+[[!format sh """
+$ git annex sync
+On branch master
+Your branch is ahead of 'origin/master' by 1 commit.
+  (use "git push" to publish your local commits)
+
+
+It took 3.28 seconds to enumerate untracked files. 'status -uno'
+may speed it up, but you have to be careful not to forget to add
+new files yourself (see 'git help status').
+nothing to commit, working tree clean
+ok
+pull origin
+ok
+push origin
+fatal: cannot run hooks/post-receive: No such file or directory
+To /var/tmp/mnt/winhost-w10-5920/cygdrive/e/my.gitannex/
+   a0ebd1826d..15cfd91da4  git-annex -> synced/git-annex
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes. I think git-annex is a hidden gem of the open source
+community.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_1_a9501e2f347b957e7dc53a06fe59cff4._comment b/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_1_a9501e2f347b957e7dc53a06fe59cff4._comment
new file mode 100644
index 0000000000..dadc7b49e4
--- /dev/null
+++ b/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_1_a9501e2f347b957e7dc53a06fe59cff4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-11-28T17:57:19Z"
+ content="""
+You can edit the hooks that git-annex installs however you need to. It will
+not overwrite modified hook files. If you edit this hook to have unix line
+endings, does the hook still work when using this repository on windows?
+
+Actually, I'm having difficulty seeing how the CR could have gotten into
+that hook. `mkHookScript` uses `unlines` which behaves the same on Windows
+as on Linux, so in either case lines should be separated only by `\n`.
+
+This makes me wonder if something else modified the hook after git-annex
+wrote it. If so, `git-annex init` should complain that the hook is
+modified.
+"""]]
diff --git a/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_2_e4cac0d18fd6cde1084e93d0fe997f40._comment b/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_2_e4cac0d18fd6cde1084e93d0fe997f40._comment
new file mode 100644
index 0000000000..a9deb1126d
--- /dev/null
+++ b/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_2_e4cac0d18fd6cde1084e93d0fe997f40._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="comment 2"
+ date="2023-01-05T06:48:58Z"
+ content="""
+Apologies for the delay in response.
+
+> You can edit the hooks that git-annex installs however you need to. It will not overwrite modified hook files. If you edit this hook to have unix line endings, does the hook still work when using this repository on windows?
+
+Thanks, that aligns with what I surmised. I didn't apply that type of workaround for the sake of the report being as linear as possible (no alterations outside of running the git-annex commands).
+
+Yes, of course, if I run dos2unix on the hook file, the repository works for both Linux and Windows. The latter, I understand because it is using msys to run the script, which is flexible with both forms of line-endings.
+
+> Actually, I'm having difficulty seeing how the CR could have gotten into that hook. mkHookScript uses unlines which behaves the same on Windows as on Linux, so in either case lines should be separated only by \n.
+
+My understanding has always been... native implementations on Windows (ie. no posix emulation linkage), if you don't call open() for \"binary\", your line-feeds indicate line termination only, and then the native line ending is written to the file, ie. Windows text files. So Windows native Python, Java, etc implementations, behave this way.
+
+If I understand correctly, git-annex is relying on a native build of GHC? And it's library behaves that way too? Is that right?
+
+> This makes me wonder if something else modified the hook after git-annex wrote it. If so, git-annex init should complain that the hook is modified.
+
+As per above, I doubt that there was any alterations here. I tried again with a clean scenario, and indeed, the hook files were written as described.
+
+"""]]
diff --git a/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_3_a3a702176a316d6b599eb2a149a293ad._comment b/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_3_a3a702176a316d6b599eb2a149a293ad._comment
new file mode 100644
index 0000000000..48585a67b2
--- /dev/null
+++ b/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_3_a3a702176a316d6b599eb2a149a293ad._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="comment 3"
+ date="2023-01-05T07:16:30Z"
+ content="""
+I should add, and this is not a commentary on the implementation of git-annex, etc... but having limited experience with BSD, and understanding that it uses different line endings for text files (???)... and other considerations... the git hooks mechanism is powerful, but seemingly presents challenges for interoperability.
+
+Maybe the right approach is actually... as I did... let the end-user find their own workaround. It seems it's not really a git-annex fault after all.
+
+I initially thought that git-annex should write the file out correctly... but it kind of is. It's writing it out for the local sensibilities.
+
+In this particular case, it's my challenge to solve, not the tools... if you agree, I'd be content to have this closed with no action.
+
+But I leave it to your better judgement.
+
+"""]]
diff --git a/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_4_82103077cde68c3b6a70dcf70c4ed837._comment b/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_4_82103077cde68c3b6a70dcf70c4ed837._comment
new file mode 100644
index 0000000000..a54f932f79
--- /dev/null
+++ b/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_4_82103077cde68c3b6a70dcf70c4ed837._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="sb-beryllium@6e2c477eac63b823bd315ef8aaf5f93173c1f15b"
+ nickname="sb-beryllium"
+ avatar="http://cdn.libravatar.org/avatar/ef62105380b73ef91d760ec327c14e22"
+ subject="comment 4"
+ date="2023-01-07T13:05:23Z"
+ content="""
+Apologies, this is beryllium (by alias)... due to unforeseen circumstances, I have had to register with a different email address. I am hoping this is a temporary situation.
+
+Further apologies... I acknowledge that I am vacillating  somewhat, but I've reverted to thinking that the hooks should be generated with unix line-endings (LF).
+
+The reason I say this is, it does appear that the pseudo-standard for files under the .git directory is that they use unix line-endings only (perhaps an actual, documented standard... I'm not sure where to look/ask to confirm it).
+
+This is the case for files such as .git/config, and .git/refs/** etc... under Git for Windows, and even JGit running with Windows native Java.
+
+So to me.. it seems to make sense that hook files should have unix line-endings exclusively.
+
+There are possible other mitigations... but that's where I stand with that finally. I'm still not fussed if no actions is determined to be the best course of action.
+
+Thanks regardless.
+
+"""]]
diff --git a/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_5_c22f9e3c5e438b2cc05008bc3f91b7fc._comment b/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_5_c22f9e3c5e438b2cc05008bc3f91b7fc._comment
new file mode 100644
index 0000000000..de5861f990
--- /dev/null
+++ b/doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_5_c22f9e3c5e438b2cc05008bc3f91b7fc._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-11-29T17:29:08Z"
+ content="""
+[[!commit 4e35067325022e4d8790d45557156fd1166484df]] fixed this.
+Previously, git-annex did write hook scripts with CRLF line endings.
+
+Existing hook scripts won't be changed by git-annex, but if you delete
+them, and re-run `git-annex init` it will reinstall it without the CRLF.
+"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X.mdwn b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X.mdwn
new file mode 100644
index 0000000000..95a04740d7
--- /dev/null
+++ b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X.mdwn
@@ -0,0 +1,39 @@
+I have some git repositories I don't edit often that I'd like to back up.  I'd like to add these to my git annex, so I don't have to resort to a time-consuming hack (such as setting up a proper submodule, or bundling the repositories).
+
+But when I try to add a .git directory to git annex, I get a bunch of errors of the form
+
+    git-annex: user error (xargs ["-0","git","--git-dir=/tmp/tmp.LhGN3nT9uM/annex/.git","--work-tree=/tmp/tmp.LhGN3nT9uM/annex","add","--"] exited 123)
+    failed
+    git-annex: add: 1 failed
+    add repo/.git/hooks/pre-push.sample ok
+    (Recording state in git...)
+    error: Invalid path 'repo/.git/hooks/pre-push.sample'
+    error: unable to add repo/.git/hooks/pre-push.sample to index
+    fatal: adding files failed
+
+STR:
+
+    $ mkdir annex
+    $ cd annex
+    annex$ git init
+    annex$ git annex init
+    annex$ cd ..
+
+    $ mkdir repo
+    $ cd repo
+    repo$ git init
+    repo$ cd ..
+
+    $ mv repo annex
+    $ cd annex
+    annex$ find repo | xargs -n1 git annex add
+    # Lots of errors of the form above.
+
+You can't simply do `git annex add repo` because that will ignore the .git directory.  Similarly,` git annex add .git` (which I'd think really should try to add the contents of the .git directory) ignores everything.
+
+I don't know what this error means.  Is there a right way to work around this?
+
+> [[!meta title="cannot add .git/ to a git repository. even when using git-annex."]]
+> [[!taglink confirmed]] (but may be out of scope for git-annex) --[[Joey]]
+> > 
+> > [[closing|done]] as out of scope
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_1_5d23b1f02c6a0db0b43939210c427994._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_1_5d23b1f02c6a0db0b43939210c427994._comment
new file mode 100644
index 0000000000..ff4b30122f
--- /dev/null
+++ b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_1_5d23b1f02c6a0db0b43939210c427994._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andy"
+ avatar="http://cdn.libravatar.org/avatar/1f1c630290d8b02d7faddc9fa4482c8d"
+ subject="comment 1"
+ date="2017-02-16T06:34:50Z"
+ content="""
+I've had the same problem; I solve it by packing the repositories into a compressed file of some sort (currently a 7z archive) and committing that to Git Annex. I have a script that makes that a one-line job. If I need to make changes to the repo, I can unpack the archive and work on the repo as usual.
+"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_2_6ede677f8113fcd6215ecd68de237f06._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_2_6ede677f8113fcd6215ecd68de237f06._comment
new file mode 100644
index 0000000000..260ea540e1
--- /dev/null
+++ b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_2_6ede677f8113fcd6215ecd68de237f06._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 2"
+ date="2022-01-13T18:10:22Z"
+ content="""
+I found an even better workaround, see [[tips/using_nested_git_repositories/]]
+"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_3_3377120e8e246f5ec74d372015590a6c._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_3_3377120e8e246f5ec74d372015590a6c._comment
new file mode 100644
index 0000000000..9ba55f760a
--- /dev/null
+++ b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_3_3377120e8e246f5ec74d372015590a6c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-01-25T16:39:05Z"
+ content="""
+I think this is out of scope for git-annex. It's not its place to change
+what files git allows to be version controlled.
+"""]]
diff --git a/doc/bugs/Cannot_add_gcrypt_remote_in_webapp__58___gcrypt_backend.mdwn b/doc/bugs/Cannot_add_gcrypt_remote_in_webapp__58___gcrypt_backend.mdwn
new file mode 100644
index 0000000000..28c30bbd23
--- /dev/null
+++ b/doc/bugs/Cannot_add_gcrypt_remote_in_webapp__58___gcrypt_backend.mdwn
@@ -0,0 +1,15 @@
+### Please describe the problem.
+
+I have a repository that is encrypted using GPG. It is supposed to sync a folder between two laptops. (Note: this is a DIFFERENT repository than the one in my other bug report https://git-annex.branchable.com/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/ but the setup is the same)
+
+I set everything up on laptop1. This time, I decided to wait for the syncing to finish, between laptop1 and laptop2 in order to prevent corruption. After laptop1 had finished syncing, I went to laptop2 and setup the repository.
+
+- I created a local repository on laptop2.
+- I told the webapp to combine repositories.
+
+Then I got
+
+"
+Internal Server Error
+Cannot find configuration for the gcrypt remote at ssh://denisa@vps.ip/backup/annex/denisa/Studium
+"
diff --git a/doc/bugs/Cannot_clone_an_annex.mdwn b/doc/bugs/Cannot_clone_an_annex.mdwn
new file mode 100644
index 0000000000..77989ecb67
--- /dev/null
+++ b/doc/bugs/Cannot_clone_an_annex.mdwn
@@ -0,0 +1,69 @@
+I have an annex that I use to store my digital photos.  I had a few false
+starts creating this annex, but now it's looking good on my server:
+
+    root@titan.local:/tank/Media/Pictures# git annex status
+    supported backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+    supported remote types: git S3 bup directory rsync web hook
+    trusted repositories: 0
+    semitrusted repositories: 2
+            00000000-0000-0000-0000-000000000001 -- web
+            be88bc5a-17e2-11e2-a99b-d388d4437350 -- here (titan)
+    untrusted repositories: 0
+    dead repositories: 5
+            0A9F3136-A12A-43C7-9BE2-33F59954FD52 -- vulcan
+            57349F02-E497-4420-9230-6B15D8AB14EE -- vulcan
+            6195C912-2707-4B75-AC8C-11C51FAA8FE0 -- vulcan
+            D51DEDC4-9255-4A99-8520-2B1CED337674 -- hermes
+            EE327B34-3E20-4B5B-8F0E-D500CBC9738D -- hermes
+    transfers in progress: none
+    available local disk space: unknown
+    local annex keys: 20064
+    local annex size: 217 gigabytes
+    known annex keys: 21496
+    known annex size: 217 gigabytes
+    bloom filter size: 16 mebibytes (4% full)
+    backend usage: 
+            SHA256E: 41560
+    root@titan.local:/tank/Media/Pictures# git annex unused
+    unused . (checking for unused data...) ok
+
+It passes `git annex fsck` without any problems.  However, when I "git clone"
+this annex to my desktop machine and then do a `git annex sync`, I see this:
+
+    Vulcan /Volumes/tank/Media/Pictures (master) $ git annex status
+    supported backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+    supported remote types: git S3 bup directory rsync web hook
+    trusted repositories: 0
+    semitrusted repositories: 5
+            00000000-0000-0000-0000-000000000001 -- web
+            0A9F3136-A12A-43C7-9BE2-33F59954FD52 -- vulcan
+            274D3474-7A25-44CD-8368-CF11C451014F -- here (vulcan)
+            EE327B34-3E20-4B5B-8F0E-D500CBC9738D -- hermes
+            be88bc5a-17e2-11e2-a99b-d388d4437350 -- titan
+    untrusted repositories: 0
+    dead repositories: 3
+            57349F02-E497-4420-9230-6B15D8AB14EE -- vulcan
+            6195C912-2707-4B75-AC8C-11C51FAA8FE0 -- vulcan
+            D51DEDC4-9255-4A99-8520-2B1CED337674 -- hermes
+    transfers in progress: none
+    available local disk space: 1 terabyte (+1 megabyte reserved)
+    local annex keys: 0
+    local annex size: 0 bytes
+    known annex keys: 21025
+    known annex size: 217 gigabytes
+    bloom filter size: 16 mebibytes (0% full)
+    backend usage: 
+            SHA256: 18707
+            SHA256E: 2318
+
+Where did all these `SHA256` keys come from?
+
+Why doesn't the known annex keys size match?
+
+Further, I cannot `git annex get` on most of the files, because it says that
+the `SHA256` key is not present.
+
+It looks like I'll have to rollback my ZFS snapshots and start over, but I'm
+wondering: how was I even able to create this situation?
+
+> [[Done]]; user error. --[[Joey]] 
diff --git a/doc/bugs/Cannot_clone_an_annex/comment_1_b40a2652361a79c6c6eab0fc21be8e46._comment b/doc/bugs/Cannot_clone_an_annex/comment_1_b40a2652361a79c6c6eab0fc21be8e46._comment
new file mode 100644
index 0000000000..44b93b1c2f
--- /dev/null
+++ b/doc/bugs/Cannot_clone_an_annex/comment_1_b40a2652361a79c6c6eab0fc21be8e46._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.23"
+ subject="comment 1"
+ date="2012-10-22T13:53:06Z"
+ content="""
+The SHA256 keys are symlinks in your git repository with \"SHA256-\" as the prefix on the file linked to. You should be able to determine the rest by looking at the history of those files in git.
+"""]]
diff --git a/doc/bugs/Cannot_delete_remote_when_ssh_sync_fails.mdwn b/doc/bugs/Cannot_delete_remote_when_ssh_sync_fails.mdwn
new file mode 100644
index 0000000000..f780ace7ca
--- /dev/null
+++ b/doc/bugs/Cannot_delete_remote_when_ssh_sync_fails.mdwn
@@ -0,0 +1,8 @@
+### Please describe the problem.
+The webapp does not offer me the option to delete a remote repository that it did not succeed to synchronize with. Status of the repository is sync enabled (metadata only) but in settings I may only edit the repo, but cannot delete it.
+
+### What steps will reproduce the problem?
+Set up git-annex on a new computer. Forget to enable ssh on the machine. Perform a local pairing (success). The sync fails for obvious reasons.
+
+### What version of git-annex are you using? On what operating system?
+System is ubuntu but I assume this is a general issue. Version of git-annex is 5.20140117
diff --git a/doc/bugs/Cannot_delete_remote_when_ssh_sync_fails/comment_1_3c8e8fae688a9db8e18e869a187fb4eb._comment b/doc/bugs/Cannot_delete_remote_when_ssh_sync_fails/comment_1_3c8e8fae688a9db8e18e869a187fb4eb._comment
new file mode 100644
index 0000000000..c89d1cb0c7
--- /dev/null
+++ b/doc/bugs/Cannot_delete_remote_when_ssh_sync_fails/comment_1_3c8e8fae688a9db8e18e869a187fb4eb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.46"
+ subject="comment 1"
+ date="2014-01-26T17:57:25Z"
+ content="""
+If you go to Edit, it will let you upgrade the repository, which should fix your problem.
+"""]]
diff --git a/doc/bugs/Cannot_delete_remote_when_ssh_sync_fails/comment_2_e189617c4ac23df50f02af8c517fa399._comment b/doc/bugs/Cannot_delete_remote_when_ssh_sync_fails/comment_2_e189617c4ac23df50f02af8c517fa399._comment
new file mode 100644
index 0000000000..0d2f2e99b1
--- /dev/null
+++ b/doc/bugs/Cannot_delete_remote_when_ssh_sync_fails/comment_2_e189617c4ac23df50f02af8c517fa399._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmXtqLEfN6cGcF9gW_09QUDoRpsexSdRcM"
+ nickname="Thomas"
+ subject="comment 2"
+ date="2014-01-26T18:12:08Z"
+ content="""
+Unfortunately, upgrading did not fix it. I suppose, a restart of the remote server (ssh was just installed) would have been necessary. Instead, I just deleted the repository on the remote.
+
+Now my local repository was caught in a situation, where I couldn't upgrade the broken remote and I couldn't delete it either.
+
+By recreating the repository on the remote, I finally was able to get rid of the broken link, but I think the proper solution would be to have the ability to remove unsynced repositories.
+
+Thanks for the quick response!
+"""]]
diff --git a/doc/bugs/Cannot_delete_remote_when_ssh_sync_fails/comment_3_35a08daa2776c648d5ee010b77e72bd4._comment b/doc/bugs/Cannot_delete_remote_when_ssh_sync_fails/comment_3_35a08daa2776c648d5ee010b77e72bd4._comment
new file mode 100644
index 0000000000..3c1691cb3a
--- /dev/null
+++ b/doc/bugs/Cannot_delete_remote_when_ssh_sync_fails/comment_3_35a08daa2776c648d5ee010b77e72bd4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~r0lf"
+ nickname="r0lf"
+ avatar="http://cdn.libravatar.org/avatar/aa82122557e706df7ba83bd1983eb79ef1ba2e51350217850176d4f9a1bb2bc0"
+ subject="still an issue in Ubuntu Focal"
+ date="2021-04-05T01:28:46Z"
+ content="""
+This is still an issue in Ubuntu Focal which has version 8.20200226-1 of git-annex.
+
+What I did here is to create a gcrypt remote on hidrive.strato.com over plain git. The obfuscated URL is url = \"gcrypt::git.hidrive.strato.com:users/myuser/gcrypt.git#gcrypt\". That remote shows as \"syncing enabled (metadata only)\" in the webapp interface and cannot be deleted there.  I don't think strato.com has git-annex-shell installed.
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX.mdwn b/doc/bugs/Changing_sync_to_include_content_breaks_UX.mdwn
new file mode 100644
index 0000000000..14380e6964
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX.mdwn
@@ -0,0 +1,68 @@
+### Please describe the problem.
+
+After upgrading to git-annex 10.20230626, running `git annex sync` reports:
+
+    git-annex sync will change default behavior to operate on --content in a future version of git-annex. Recommend you explicitly use --no-content (or -g) to prepare for that change. (Or you can configure annex.synccontent)
+
+which appears to be a barely documented change plan (at least I cannot find it in [the git-annex dev blog](https://git-annex.branchable.com/devblog/), only in the [latest change log]((https://hackage.haskell.org/package/git-annex-10.20230626/changelog)).
+
+From the little that is said in [the 10.20230626 changelog](https://hackage.haskell.org/package/git-annex-10.20230626/changelog), it appears the intention is to -- **after 10 years** -- fairly quickly switch from `git annex sync` just syncing metadata (allowing git annexes to easily hold partial subsets of content), to doing a full content sync bidirectionally (apparently not allowing git annexes to hold partial subsets of content without explicit countermeasures for this behaviour breaking change).
+  
+I can understand why users might want a `git annex sync` that syncs content.  And even maybe why it might want to be the default for those users who expect, eg, "Dropbox like behaviour".
+
+But **changing the git annex sync default after 10 years** seems extremely user hostile.
+
+Especially so when changing it from something that does not copy much data (default `git annex sync --no-content`) to something which (a) potentially copies a lot of data (over what might be a slow/expensive link), and (b) will potentially fill up drives due to repopulating entire large annexes which have historically relied on having only a subset of the content available locally, if the change in behaviour (after 10 years) is not caught in time.
+
+The idea that users should go around every single git annex (I have dozens, with copies of those on dozens of machines and a bunch of offline drives), and make sure each one has `annex.synccontent` set, or every script that runs `git annex sync` has `git annex sync --no-content` on it, just to *restore the default of 10 years* is a pretty rough transition, and not a great user experience.
+
+I would really strongly suggest that you do not change the behaviour of `sync` in this way *after 10 years*.  And if you want a full sync option for user friendliness, then create, eg, `git annex fullsync` which is an alias for `git annex sync --content`.
+
+If you no longer want to support the user model of having "incomplete annexes" (ie, all copies of a git annex must contain local copies of all data except changes made since the last sync), then the deprecation should be explicitly documented with advanced warning.
+
+At minimum this signficant behaviour breaking change needs to be communicated *way* better than a random change log entry, and suddenly appearing in `git annex` output as a warning the world is going to break.  And it shouldn't be necessary to, eg, trawl through the git source history to try to find any context for a major planned change.
+
+Some slight saving graces:
+
+* Fortunately `git annex sync --no-content` seems to be accepted at least back to git-annex 6.x, so at least it can be added into scripts without having to also check which git annex version is running; it's just a "no op" option in everything prior to git-annex 10.20030626.
+
+* It looks like [`git annex config --set annex.synccontent false`](https://git-annex.branchable.com/git-annex-config/) might be carried with the repository (across syncs), reducing the number of places the new "override, back to the old default behaviour" setting has to be set (but it has to be set on every existing and new git annex, just to restore the 10 year historical behaviour)
+
+* The [git annex source commit](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=f93a7fce1d5272c3282ce234053d26b10dd44198) has a tiny bit more context about there needing to be a "Debian Stable release" before the default changes, which doesn't seem to be documented anywhere else; if true, then since [Debian Bookworm  just released, with git-annex 10.20230126](https://packages.debian.org/bookworm/git-annex) then the change in behaviour is at least 2-3 years away, at Debian's normal stable release schedule.  But this doesn't seem to be documented anywhere else.
+
+If the plan is that this change in default behaviour will be, eg, in 2H 2025, then I'd suggest (a) putting that planned date in the warning being issued on every run, and (b) putting that date in the documentation for [git annex sync](https://git-annex.branchable.com/git-annex-sync/) which currently just says "will change in a future version of git-annex" (which is very vague, and could be next month or a decade away).  However as stated above, I'd really really strongly suggest just creating a new command, like `fullsync` for the new default behaviour, and *not* breaking backwards compatibility in behaviour.
+
+
+### What steps will reproduce the problem?
+
+Upgrade to git-annex 10.20230626, run `git annex sync` in a git annex repository, without having set `annex.synccontent` (i the git-annex config, or the git config).
+
+Try to find documentation on this pending change; find nothing other than the changelog note foreshadowing a major change in behaviour after 10 years, and some comments in the source code.
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex 10.20230626, on macOS, installed from Home Brew.
+
+```
+ewen@basadi:~$ git annex version
+git-annex version: 10.20230626
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24.1 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.4.4 http-client-0.7.13.1 persistent-sqlite-2.13.1.1 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+ewen@basadi:~$ 
+```
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Absolutely.  I've been using git-annex since nearly the beginning; and use it extensively to maintain partial copies of large annexes on laptops/desktops (and other space constrained systems).  Hence this foreshadowed sudden change in behaviour being extremely surprising, and somewhat alarming.
+
+Thanks for writing git-annex.  It's the reason I've been sponsoring you on Patreon for years.
+
+Please don't break backwards compatibility.  Even in the user experience :-)
+
+> [[closing|done]] per new plan --[[Joey]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_10_ec80bdff87c7b70e4235cd5b2ba6ed05._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_10_ec80bdff87c7b70e4235cd5b2ba6ed05._comment
new file mode 100644
index 0000000000..65d31dd535
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_10_ec80bdff87c7b70e4235cd5b2ba6ed05._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 10"
+ date="2023-07-12T16:25:48Z"
+ content="""
+@nobodyinperson, @ewen: Thank you for a balanced discussion! I'm not as elegant with words
+but here is my take on your ideas.
+
+@nobodyinperson:
+
+> How about:
+
+> - `git annex assist` (exists, works):
+
+Yes, I understand the need for `assist` -- not in any way opposed to it. However, I think both
+`assist` and `sync` ought learn a new option called `--edit` (or, `--edit-message` but that's wordy)
+to be used in a similar fashion to `git commit -m msg --edit`, ie. it would open the user's preferred editor
+to edit the commit message.
+
+> - `git annex metasync` (new proposal):
+
+You mention that this command would be \"Option-wise as 'dumb' as git annex assist\" but I disagree: as a true
+replacement for `sync` it definitely should have at least the `--no-commit` flag as an additional option so that those
+used to a `git annex add; git commit -m foo [--edit]; git annex sync --no-content --no-commit` workflow could
+migrate to it. Also, no auto-adding (please!) if this is supposed be a replacement for `sync --no-content`.
+
+> - `git annex sync` (exists, has many options and configs):
+
+You mention that this command ought to be \"deprecated eventually (in many years), with a big warning upon execution now already\".
+Yes, I agree but only if we get a `metasync` with a `--no-commit` flag for reasons above.
+
+---
+
+@ewen:
+
+> Firstly, if `git annex assist` has been added to create the magical \"Dropbox like experience\", I don't see the need for changing the default behaviour of `git annex sync` at all.  (For the record I'm glad `git annex assist` exists; I don't need it, or want it, but it clearly solves a bunch of UI problems for some users, and that's great.  This is entirely about backwards incompatible UX changes in existing commands.)
+
+I think you have a point there that the situation pre-10.20230626 would be preferable.
+But I can live with Yann's (@nobodyinperson) suggestions if there is some amount of compromising.
+
+> Secondly, your (@nobodyinperson) suggestion for \"improving\" the current situation seems to be:
+
+> 1.  Entirely remove `git annex sync` (entirely breaking backwards compatiblity) and/or have it permanently display a warning that cannot be removed (annoying, incompatible with anything looking at output); and
+
+> 2.  Add a new (ie, not in any older version) `git annex metasync` which has some of the existing functionality, and some random other (unwanted by me at least) additional functionality (auto-adding any files in a directory where git annex is run, which I definitely do not want)
+
+Yes, a replacement for `sync` should not in any case auto-add files. We want more control, not less.
+
+(continued...)
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_11_82e32aca2c23a1e27553bcd9708870b2._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_11_82e32aca2c23a1e27553bcd9708870b2._comment
new file mode 100644
index 0000000000..d236976601
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_11_82e32aca2c23a1e27553bcd9708870b2._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2023-07-12T17:03:27Z"
+ content="""
+Please don't engage in unwarranted speculation about strange desires of mine
+to eliminate features that are crucial to git-annex. In general, avoid
+inflammatory language on this website. Thank you.
+
+It's important that git-annex be able to make changes that make it better.
+Backwards compatability is not everything. Improvements can make git-annex
+more cohesive and easier to understand for new users.
+This kind of pre-warned transition is commonly used by git when making
+similarly impactful changes.
+
+annex.synccontent can be set in your global git config. It can also be set
+with `git-annex config` which will affect all clones of that repo. This
+will be a minor amount of work for most users to deal with.
+
+BTW, this transition plan actually started 6 years ago when I added
+annex.syncontent configuration and --no-content.
+[[!commit b77903af48e650dbb777f29e98d0c7b388353ebd]]
+As you note, it's important that's already available in all commonly used
+old versions of git-annex.
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_12_4e0746d00d8a596d878c1fe12ec68849._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_12_4e0746d00d8a596d878c1fe12ec68849._comment
new file mode 100644
index 0000000000..43a368a7f1
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_12_4e0746d00d8a596d878c1fe12ec68849._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 12"
+ date="2023-07-12T17:30:52Z"
+ content="""
+(...continued)
+
+@ewen:
+
+> My suggestion for preserving backwards compatibilty would be:
+
+> 1.  Move the behaviour change out of `git annex sync` and into `git annex init` (rationale: it's run once per annex/machine pair, not many times per day/week, *and* it makes the change \"new annexes only\" which is much closer to \"opt in\")
+
+> 2.  From git annex version N + 1, have git annex automatically set `annex.synccontent=true` at `git annex init` of a *new* repo (ie, not just naming the local copy of the annex), and for version N+1 to N+3 (or higher) have `git annex init` issue a warning it has defaulted sync content on now (unlike earlier versions), and describe how to find out how to turn it off (unless a global git setting is making `annex.synccontent=true` the user preferred default anyway, in which case the user doesn't need a warning of a setting matching their preferred option).
+
+> 3.  For any annex where `annex.synccontent` is *not* set, assume it's an older annex, and use the backwards compatible, historical, default (false) *without* issuing any warnings about \"this is going to change\" (and never change that behaviour for historical annexes)
+
+> 4.  Retain `git annex sync` forever, with it obeying `annex.synccontent` (default: false, but set to true in newly created annexes by default)
+
+> 5.  Remove the newly added warning in `git annex sync` entirely, and just keep the functionality of the version before 10.20230623
+
+Sounds good. I like the concept of an opt-in the way you laid it out. It's well thought out.
+
+> This would:
+
+> 1.  Allow changing the `git annex sync` default from `metadata only` to `full content` in a \"new usage, opt in only\" way
+
+> 2.  Provide a clear path to opt out, and a clear path to opt in existing repos to match
+
+> 3.  Avoid needing to issue warnings to users on every run of a very core command until they set config
+
+> 4.  Avoid breaking existing usage, and use cases
+
+(Yes, that warning is annoying to say the least.)
+
+I'm willing to accept some breakage to my workflows but I'd rather still see a separate
+`git annex add`, `git commit -m ...` and \"sync metadata with one command\" workflow being supported.
+The name of that sync command is not that important for me but I understand why it is for you.
+
+> The git annex \"meta data sync\" dance (which effectively allows `git push` into a repo that has a working directory attached, something that is normally otherwise difficult) was great, and the thing which made git annex attractive to me over other options.  It'd be a shame to render that great functionality unreachable without unwanted \"some users wanted this, so all users must have this\" functionality.
+
+I agree to the strongest degree. I'm not a very good git user, but the core parts of git-annex
+like `add` and `sync` have made me feel comfortable to a greater extent than the porcelain of core git.
+I'm sure I can adapt to newfangled ways of doing my routine things with git-annex but as on \"old dog\" I'd
+rather not adopt those new ways if I can avoid it.
+
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_13_80ba2e4241372ff3ce1505900e17c22f._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_13_80ba2e4241372ff3ce1505900e17c22f._comment
new file mode 100644
index 0000000000..fb4dc59c76
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_13_80ba2e4241372ff3ce1505900e17c22f._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="Plumbing commands vs Porcelain commands"
+ date="2023-07-13T00:26:20Z"
+ content="""
+@joey (re [comment 11](http://git-annex.branchable.com/bugs/Changing_sync_to_include_content_breaks_UX/#comment-e4557f089ec22304ff506f09f791bb81)): thank you for replying.  I apologise if my tone sounded accusatory; in hindsight writing late at night after a stressful year probably wasn't the best idea.
+
+I don't know what your intentions are here, which is part of the problem.  From the outside, it feels like the git-annex assistant functionality is now the dominant use case which is guiding the development changes.  (And that's understandable if it's most/all of your funding to work on the project.)  That seems to be leading towards the \"plumbing\" low level commands being transitioned into higher level (\"porcelain\" in git terminology) commands, which do multiple things; and access to the low level functionality being decreased or removed.
+
+Yes, git has done a few \"UX breaking\" transitions in the past.  But in all the cases I can think of the change in functionality was accompanied with obvious documentation on why the change was being made, and how to adapt.  For instance the [git safe directory behaviour change (CVE-2022-24765)](https://github.blog/2022-04-12-git-security-vulnerability-announced/) prompted a lot of documentation about why it was changed (eg, [git config manpage](https://git-scm.com/docs/git-config#Documentation/git-config.txt-safedirectory)), and specifically how users could restore the existing functionality where that was appropriate (and, eg, it gave an exact command to run in the warning output).  I've been running into that problem repeatedly for a year (including supporting other users), but at least knowing why, and that the recommended \"fix command\" is the ideal solution, makes it quick to explain/fix/carry on.
+
+In the case of this git-annex change to `sync` (from a \"just plumbing\" meta data sync command, to a \"porcelain\" git annex assistant like command) there doesn't seem to be any clear documentation on why it is changing, or the recommended process to preserve (or recreate) the existing default functionality (meta data sync only), particularly in a backwards compatible way.
+
+The reference to the [six year old commit](http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=b77903af48e650dbb777f29e98d0c7b388353ebd) which you see as \"starting this change\" adds some more context, but almost all of the \"documentation\" about this change appears to be scattered between some source code commits, some short changelog entries, and a bug that started being about something else.  As someone who has followed your personal blog and the git-annex dev blog for years, the change of \"sync\" from a low level plumbing command (with optional \"please do more\") to a high level porcelain command (with optional \"please skip most of the things you want to do) still seemed to appear very suddenly, without any foreshadowing it was going to change.  And I remain unclear on the intended timeline for the (fairly fundamental, IMHO) change in default behaviour.
+
+For my purposes I think from here on I'll be doing *all* of the following:
+
+1.  On any system I install git-annex, running `git config --global annex.synccontent false` to set my per-user, per-machine state to equivalent to now
+
+2.  On any git-annex wrapper scripts I have that run `sync`, explicitly calling `git annex sync --no-content` instead of a bare `git-annex sync` as before
+
+3.  On any new git-annex repo that I set up, running `git annex config --set annex.synccontent false`
+
+4.  On the existing git-annex repos, as I interact with them again and remember, run `git annex config --set annex.synccontent false` to maintain the existing default
+
+5.  On new/existing git-annex repos, consider also running `git annex wanted . present` as well, since that seems to effectively match my current policy (ie, what is there is what is supposed to be there, because I put it there).
+
+(I appreciate that mostly any one of those \"should be sufficient\".  But with a lot of existing git annex repos, spread across lots of machines/drives, some of which are offline, the risks of overlooking one or more of them later on is non-trivial.  So belt and braces here.)
+
+Ewen
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_14_08f3c3d26d13fd44ae9c26791b90a8fc._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_14_08f3c3d26d13fd44ae9c26791b90a8fc._comment
new file mode 100644
index 0000000000..f40ea41eec
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_14_08f3c3d26d13fd44ae9c26791b90a8fc._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2023-07-14T00:01:27Z"
+ content="""
+> From the outside, it feels like the git-annex assistant functionality is
+> now the dominant use case which is guiding the development changes.
+
+Based on what, the changes in the last release?
+
+You're seeing a pattern where none exists.
+
+> (And that's understandable if it's most/all of your funding to work on the project.)
+
+No such funding, not that I allow funding to determine overall direction of
+this project.
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_15_38a0eafe91e05a7784dd5e305f38a8f3._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_15_38a0eafe91e05a7784dd5e305f38a8f3._comment
new file mode 100644
index 0000000000..a2e6d36f5c
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_15_38a0eafe91e05a7784dd5e305f38a8f3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2023-07-15T16:09:46Z"
+ content="""
+My current thinking is that when a repository does not have a preferred
+content expression, a content sync could avoid adding content to it. 
+
+This would avoid surprising behavior after the transition, except for 
+repositories that did at some time have a preferred content expression set,
+but one that no longer reflects the use of the repository.
+
+However, current users of `sync --content` (or of annex.synccontent) do
+expect it to fill their repositories that don't have preferred content
+configured. So would a sync that defaults to content syncing then need to
+behave differently than an explicit `sync --content`? Or should changing
+behavior in that case also be part of the transition?
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_16_ee529ac7b3d27f1cdc7edf5154c0da8f._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_16_ee529ac7b3d27f1cdc7edf5154c0da8f._comment
new file mode 100644
index 0000000000..8eeeeb694b
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_16_ee529ac7b3d27f1cdc7edf5154c0da8f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 16"
+ date="2023-07-15T17:04:38Z"
+ content="""
+> My current thinking is that when a repository does not have a preferred content expression, a content sync could avoid adding content to it.
+
+Technically, that would make the default preferred content expression `present` instead of `include=*`, right? I'd like that. Less unwanted content after the initial clone when running `git annex assist` or `git annex sync --content`. Goes into the direction of [specifying the default preferred content expression](https://git-annex.branchable.com/todo/Setting_default_preferred_content_expressions/). Users having freshly cloned a repo can then explicitly `get` files or set up their preferred content expression.
+
+Many annexed repos will be huge in size and rarely one will want *everything* from it initially. Also great for DataLad datasets.
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_17_d60adea3f0c0030a403c33c57f27abda._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_17_d60adea3f0c0030a403c33c57f27abda._comment
new file mode 100644
index 0000000000..61bbf12ed9
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_17_d60adea3f0c0030a403c33c57f27abda._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="unspecified default preferred content = present"
+ date="2023-07-17T00:50:09Z"
+ content="""
+I would also be in favour of changing the default preferred content expression to be \"present\" at the same time as `sync` was changed to automatically sync content as well as metadata.  The effective user experience of a user with the existing default out of box configuration would be basically equivalent (now: `sync` does not sync content by default; then: `sync` will sync content if a policy to indicate desired content is set, but the default policy is \"whatever is here is correct\").
+
+If that change were made (default preferred content expression is \"present\") then:
+
+*  I think the current warning on `sync` without `--no-content` could be removed (as the effective default change from the historical defaults is small)
+
+*  There should probably be a warning on `git annex sync` *with* a preferred content policy explicitly set (*other than* `present`, the new default), that the `sync` without `--no-content` will \"soon\" automatically include that preferred content
+
+*  There should probably be a warning on `git annex sync --content` where there is no preferred content policy explicitly set, that the default preferred content policy is changing, and the user should set an explicit one
+
+That should result in \"I do everything manually\" users (who haven't set a preferred content policy, or set it to `present`) having basically \"no effective change\".  And the special cases of users (relying on the default `sync` not including their preferred content policy; relying on the existing default preferred content policy to work with `git annex sync --content`) get a reminder they'll need a smaller tweak to their config.
+
+I'd also be fine if *new* git annexes (ie `git annex init` after new release) were to set an explicit preferred content policy to the current default (just leaving \"no content policy set\" as the implied `present` suggested above).  So new annexes would still get the \"gets everything by default\" behaviour that it seems some users want.  (I do *not* want everything by default as almost always I use annexes for content that is too large to keep on my laptop/desktop.)
+
+Thanks for considering reducing the size of the UX change here.
+
+Ewen
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_18_594ae4ce426c7fd9963a22def58904d8._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_18_594ae4ce426c7fd9963a22def58904d8._comment
new file mode 100644
index 0000000000..ff734a4ec7
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_18_594ae4ce426c7fd9963a22def58904d8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 18"
+ date="2023-07-17T06:12:26Z"
+ content="""
+> I think the current warning on sync without --no-content could be removed (as the effective default change from the historical defaults is small)
+
+The effect in term of file location will be the same after a `git annex symc` (with `present` as new defsult - or let's call it fallback - preferred content expression) and a `git annex sync --content`. **But**: There's one thing that `--content` also changes in terms of UX: speed/runtime. In my large annex repos with many files (~5 figures), a `git annex sync --content` takes *much* longer, even if no content is eventually synced. Git Annex apparently needs to go through all files whether they want to be copied somewhere. **Maybe a short-circuit path could be introduced here when all preferred content expressions effectively turn out to be `present`**. Users might wonder why `git annex sync` suddenly takes so long now.
+
+In general, **a progress bar or if that's impossible another indication of what's going on between metadata syncing and content syncing** would be helpful. With this, I could agree that the warning can go away for a simple `git annex sync` with no preferred content expressions set.
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_19_bdc211b026d3b05de127f6ed5a3d19b0._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_19_bdc211b026d3b05de127f6ed5a3d19b0._comment
new file mode 100644
index 0000000000..611d045637
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_19_bdc211b026d3b05de127f6ed5a3d19b0._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2023-08-14T16:56:48Z"
+ content="""
+Changing the default preferred content expression to `present` rather than
+`anything` would affect other things like `get --auto` and the assistant. I
+don't think that is a good idea.
+
+My idea in comment #15 is a special case for sync and not a wider change.
+
+It will have a special case either way. The current special case means
+that users who have set preferred content need to remember to use `sync
+--content`. The new special case will only manifest as a difference in
+behavior between `sync` and `sync --content` (and `get --auto` etc)
+for users with no preferred content configured.
+
+I do think that's a valuable narrowing of the special case.
+
+Gone ahead and changed the warning.
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_1_1541a9323009b20f527501ebedc9d395._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_1_1541a9323009b20f527501ebedc9d395._comment
new file mode 100644
index 0000000000..a57481d6fb
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_1_1541a9323009b20f527501ebedc9d395._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-07-12T06:49:46Z"
+ content="""
+Simultaneously, a new command `git annex assist` has been added that does basically a single step of the assistant, so roughly `git annex add;git add -A;git annex sync --content`. That goes into the direction of your `fullsync` suggestion.
+
+You can read more about the reasoning for `git annex sync` syncing content by default [here](https://git-annex.branchable.com/todo/Having___39__git_annex_sync__39___optionally_add/#comment-fc813a22c713490156234567ed211277), where I suggested to add a config to `git annex sync` that would optionally add new files as well. That turned out to launch an avalanche of new commands and changes (git annex pull, git annex push, git annex assist, sync syncing conent, etc.). 😅
+
+IIUC, Joeys reasoning is that `git annex sync` was incomplete/inconsistent from the start and did too many configurable things. `git annex assist` syncs the entire repo state - as the assistant. Preferred content expressions can be used to specify what files a repo wants. If you set that to `git annex wanted REPO present`, a content sync won't affect it anyway. I still think that a configurable default preferred content expression for new repos is very important, now that syncinc content by default might get the default: https://git-annex.branchable.com/todo/Setting_default_preferred_content_expressions/
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_2_c06017f123f1ee34c7310f923086d09a._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_2_c06017f123f1ee34c7310f923086d09a._comment
new file mode 100644
index 0000000000..10b153608b
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_2_c06017f123f1ee34c7310f923086d09a._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="I have to agree that this change to `sync` is annoying"
+ date="2023-07-12T07:18:54Z"
+ content="""
+Frankly, as a fellow user of \"incomplete annexes\" I also find it rather jarring that having gotten used to git committing my own changes
+on the command line and not relying on mere `sync` to do that (or the assistant -- I haven't found a use
+for the assistant yet) but then also preferring to use invocations of `git annex sync --no-commit` (which I've abbreviated to
+`git annex-sync` by way of a git alias) rather freely to record my git-level changes across remotes,
+I would from here on out be forced to add the `-g` flag to all my invocations just to make sure that I don't get
+an annoying warning or my then current repo doesn't cause possibly huge content to flow across the remotes because I haven't
+remembered to set `annex.synccontent` appropriately. I know the ideal is to have preferred content settings
+for all annexes but not every git-annex user have an innate sense of all the intricacies involved in doing that
+and for them to be forced to do so is a bit too much, in my humble opinion.
+
+@Joey, I have a suggestion: instead of breaking the UX of `sync`, why not do that on a lesser used command `mirror` and change it
+to sync git-level data in addition to files (ie. I suggest that `mirror` could be a better/shorter name for OP's `fullsync`).
+Then add a flag called `--only-content` to `mirror` to restore its old behavior. I bet that would have a smaller impact on git-annex's
+users than making us count our blessings with `-g`s and all.
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_3_c03b45321728155eae9470cd8bb2cc93._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_3_c03b45321728155eae9470cd8bb2cc93._comment
new file mode 100644
index 0000000000..11fcf6f9cb
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_3_c03b45321728155eae9470cd8bb2cc93._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 3"
+ date="2023-07-12T07:33:16Z"
+ content="""
+> IIUC, Joeys reasoning is that git annex sync was incomplete/inconsistent from the start and did too many configurable things.
+
+That's not a reason to break backwards compatibility for such a prominent command as `sync`. Just no.
+
+> git annex assist syncs the entire repo state - as the assistant.
+
+I don't want to use the assistant -- or it's CLI alter ego assist -- I want my own manicured commit messages, puh-lease! The assistant
+is a whole another use case, just not mine at the moment.
+
+Just give us our old `sync` back. Rename it to `synk` (or, `sc`/`sk` -- as in \"sync for [k]urmudgeons\") if you want but let us have it. :)
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_4_bb6972e9870a68a98d90c6847228ab31._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_4_bb6972e9870a68a98d90c6847228ab31._comment
new file mode 100644
index 0000000000..f121140811
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_4_bb6972e9870a68a98d90c6847228ab31._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 4"
+ date="2023-07-12T09:21:55Z"
+ content="""
+Just for the record: 
+
+- `git annex assist -m MESSAGE` works, you can make own messages. 
+- `git annex assist` has nothing to do with the assistant and can be used without. It's just `git annex sync --content` plus adding new files. A very important command for newcomers to 'just sync it'.
+
+To get 'the old sync' back, you have several options:
+
+- `git config --global annex.synccontent false` for your entire local machine, overrides the next option
+- `git annex config --set annex.synccontent false` for all participants of a git annex repo (yes, it syncs between machines), still overrideable by users' local git configs above
+- properly set up preferred content expressions (effectively), e.g. `git annex wanted . present`.
+- `git annex sync --no-content`
+
+If you don't use preferred content expressions to decide which repo should get which files and you want only partial checkouts with some files, then I indeed don't see why you would ever need `git annex sync --content` as you probably manually `get` the files you want. In that case one could argue that `sync` is a misleading word, you are actually only looking for a metadata sync (`msync`, `metasync`, ...?) strictly without content.
+
+[I was also surprised](https://git-annex.branchable.com/todo/Having___39__git_annex_sync__39___optionally_add/#comment-c8c3138128a684080e2aaafc48aedfcf) that joey opted for introducing `assist` instead of teaching `sync` how to (optionally) add new files as well and keeping the rest as it was. But I can understand the direction of his reasoning.
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_5_da9812dd37de7bba4fe2b1785bdca1ae._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_5_da9812dd37de7bba4fe2b1785bdca1ae._comment
new file mode 100644
index 0000000000..96df7c5155
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_5_da9812dd37de7bba4fe2b1785bdca1ae._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="History of change"
+ date="2023-07-12T10:27:43Z"
+ content="""
+Thanks for the [pointer to the earlier bug discussing changing sync entirely](https://git-annex.branchable.com/todo/Having___39__git_annex_sync__39___optionally_add) @nobodyinperson; it's at least useful to have a reference for where all this breaking change suddenly came from given it's otherwise undocumented.  I've added a back pointer comment to that bug pointing at this one, as they're clearly related discussion (and it wasn't obvious the other \"sync\" bug was at all related to the change).
+
+I still strongly disagree with changing \"sync\" to do something pretty different from what it's done for 10 years being a good idea.  But would certainly support there being *another* command that did a \"Dropbox like full sync\".
+
+(Personally I'd really really prefer that \"sync\" stayed doing the same thing it's done for a decade: meta data sync, only.  If we're going to have to run a new different command just to retain core \"meta data sync\" behaviour, I guess \"git annex sync --no-content\" is not much worse than any other command we'd have to remember to suddenly use instead starting version N + 1.)
+
+Ewen
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_6_bc8154b171c460b4590d2b32401f24a2._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_6_bc8154b171c460b4590d2b32401f24a2._comment
new file mode 100644
index 0000000000..5e9f65fbd8
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_6_bc8154b171c460b4590d2b32401f24a2._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="Preferred content settings not really an alternative"
+ date="2023-07-12T10:53:41Z"
+ content="""
+To echo @jkniiv's \"preferred content settings for all annexes\", as a git annex user for at least 8 years (the annex I found this issue in dates back to 2015), I've still never figured out how \"preferred content settings\" are supposed to help in git annex -- let alone for my use cases.
+
+As an example, the git annex I spotted this new warning in is one I use for downloading/collecting podcasts.  The downloads happen on my desktop, or sometimes a laptop.  All content gets *pushed* to two of my NASes as soon as possible (for an \"archival copy\" -- immediately after download if I'm at home), and then once I've listened to the podcast I drop it from my desktop/laptop, so it's gone from the \"to listen\" queue (and historically, to recover space on smaller laptop drives).  I don't want the files suddenly appearing again, unless I need to refer to it for some reason, then I do \"git annex get ...\".
+
+There's around 300GB of podcasts in the annex (around 7000 files) on my NASes; but the checked out version on my desktop is 9GB (about 200 files).  300GB is more space than some of my laptop internal drives have in total; and definitely more free space than any of them had, which is one of the reasons for using git annex for this purpose.
+
+The \"preferred content policy\" is \"if I just downloaded it I want it until I drop it, then I don't want it unless I explicitly request it again, but the two NASes should always have copies\".   From [setting git annex preferred content policy](https://git-annex.branchable.com/preferred_content/), and the [preferred content policy syntax](https://git-annex.branchable.com/git-annex-preferred-content/), AFAICT \"present\" is the closest thing to the \"content policy\" I want on my desktop/laptops, ie \"trust the user, I know what I'm doing, don't automatically move files\".  But up to version \"10.20230626 + N\" that was also the default without a content policy, as file content didn't automagically move around unless some other policy was explicitly set.
+
+Ewen
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_7_20febad4aa06d5b39668a858d2b118b1._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_7_20febad4aa06d5b39668a858d2b118b1._comment
new file mode 100644
index 0000000000..d6170ac3e0
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_7_20febad4aa06d5b39668a858d2b118b1._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="There is already something like fullsync: `git annex assist`, suggestion: new `metasync` command"
+ date="2023-07-12T11:15:26Z"
+ content="""
+>  But would certainly support there being another command that did a \"Dropbox like full sync\".
+
+You might have missed it above, but `git annex assist` is **exactly** that new command that does a 'Dropbox-like sync' (adding new files, adding changes, metadata sync, content sync) and as OP suggested with `fullsync`. It is there, it works, it's wonderful. I think we can put that part of the discussion to rest.
+
+> Personally I'd really really prefer that \"sync\" stayed doing the same thing it's done for a decade: meta data sync, only. 
+
+Actually, `git annex sync` isn't always **just** metadata sync. If you're in a repo where someone (anyone!) decided to run `git annex config --set annex.synccontent true`, there flies your Terabytes of content around when you do your `git annex sync`, assuming it's metadata-only. At first I was a fan of teaching `git annex sync` everything with flags and configs, but I think joey is right that this is inconsistent and leads to surprises.
+
+If we're at it, we could get rid of the ambiguous `sync` command altogether (this is what joey also proposed for the very long run) and introduce a metadata-only sync command (`metasync`?) that **can't** sync content. Not with a setting, not with a flag, it just can't. Then that's perfect for those who only want to sync metadata and `get` files they want manually and without preferred content expressions (I suppose that's how you do it?).
+
+How about:
+
+- `git annex assist` (exists, works):
+  - syncs everything: metadata&content, leaves the repo completely clean and all participating remotes updated to the same state 
+  - for those who don't want to run the assistant, but still have 'one command to sync it all' whenever they feel like it or want to specify a custom commit message. 
+  - Preferred content expressions manage what files land where.
+  - Very important for newcomers as this will effectively be the only command they'll need to know to get a workflow started.
+- `git annex metasync` (new proposal): 
+  - basically `git annex sync --no-content` that **can't** ever sync content. No surprises through configs.
+  - Leaves the repo in a clean state and all connected remotes at the same state of metadata (the git stuff). Also adds new files! People who want more control should use the manual commands `git annex add|push|pull|etc.`.
+  - Option-wise as 'dumb' as `git annex assist'
+  - for those who never want automatic content syncing but `get|copy|move|...` stuff manually and don't want to fiddle with preferred content expressions
+  - current users of 'old' `git annex sync` without content syncing will eventually switch to this.
+- `git annex sync` (exists, has many options and configs): 
+  - roll back to non-content-syncing as before, for those that don't want to change their workflows yet
+  - deprecated eventually (in many years), with a big warning upon execution now already.
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_8_84d31b8fdde0f0ab0355a5d30760e90d._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_8_84d31b8fdde0f0ab0355a5d30760e90d._comment
new file mode 100644
index 0000000000..19b15c0bb8
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_8_84d31b8fdde0f0ab0355a5d30760e90d._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="Alternative proposal for better backwards compatibility"
+ date="2023-07-12T12:48:03Z"
+ content="""
+Firstly, if `git annex assist` has been added to create the magical \"Dropbox like experience\", I don't see the need for changing the default behaviour of `git annex sync` at all.  (For the record I'm glad `git annex assist` exists; I don't need it, or want it, but it clearly solves a bunch of UI problems for some users, and that's great.  This is entirely about backwards incompatible UX changes in existing commands.)
+
+Secondly, your (@nobodyinperson) suggestion for \"improving\" the current situation seems to be:
+
+1.  Entirely remove `git annex sync` (entirely breaking backwards compatiblity) and/or have it permanently display a warning that cannot be removed (annoying, incompatible with anything looking at output); and
+2.  Add a new (ie, not in any older version) `git annex metasync` which has some of the existing functionality, and some random other (unwanted by me at least) additional functionality (auto-adding any files in a directory where git annex is run, which I definitely do not want)
+
+Which, to me, is *even more* breaking the user experience of using `git annex` for the last 8 years, than is currently happening.  AFAICT there would then be *no way* at all to get the `git annex` \"just sync metadata without other unwanted behaviour\" that existed before.  *And* it'd then require git annex version detection in scripts to tell if `git annex metadata --no-add-really-just-copy-metadata-honest` was available or not, or if one had to fall back to an old version of the command, which is a really user-hostile way to \"retain\" existing behaviour.  (FTR in my case at least there is *zero* chance that `git annex sync` would suddenly encounter `annex.synccontent=true`, as it's just me, and I haven't set that; I don't need a \"guarantees\" it won't copy content option, except as a defense against the git annex defaults suddenly changing after 8 years.)
+
+My suggestion for preserving backwards compatibilty would be:
+
+1.  Move the behaviour change out of `git annex sync` and into `git annex init` (rationale: it's run once per annex/machine pair, not many times per day/week, *and* it makes the change \"new annexes only\" which is much closer to \"opt in\")
+
+2.  From git annex version N + 1, have git annex automatically set `annex.synccontent=true` at `git annex init` of a *new* repo (ie, not just naming the local copy of the annex), and for version N+1 to N+3 (or higher) have `git annex init` issue a warning it has defaulted sync content on now (unlike earlier versions), and describe how to find out how to turn it off (unless a global git setting is making `annex.synccontent=true` the user preferred default anyway, in which case the user doesn't need a warning of a setting matching their preferred option).
+
+3.  For any annex where `annex.synccontent` is *not* set, assume it's an older annex, and use the backwards compatible, historical, default (false) *without* issuing any warnings about \"this is going to change\" (and never change that behaviour for historical annexes)
+
+4.  Retain `git annex sync` forever, with it obeying `annex.synccontent` (default: false, but set to true in newly created annexes by default)
+
+5.  Remove the newly added warning in `git annex sync` entirely, and just keep the functionality of the version before 10.20230623
+
+This would:
+
+1.  Allow changing the `git annex sync` default from `metadata only` to `full content` in a \"new usage, opt in only\" way
+
+2.  Provide a clear path to opt out, and a clear path to opt in existing repos to match
+
+3.  Avoid needing to issue warnings to users on every run of a very core command until they set config
+
+4.  Avoid breaking existing usage, and use cases
+
+The git annex \"meta data sync\" dance (which effectively allows `git push` into a repo that has a working directory attached, something that is normally otherwise difficult) was great, and the thing which made git annex attractive to me over other options.  It'd be a shame to render that great functionality unreachable without unwanted \"some users wanted this, so all users must have this\" functionality.
+
+Ewen
+
+PS: `git annex push` / `git annex pull` do not appear to be meta data only tools to replace sync; they appear to be very explicitly targetted at copying content, and to be one remote at at a time as well (where as sync is \"all known remotes\").  Historically it looks like my wrapper scripts use `git annex get ...` to retrieve content, and `git annex copy --to=REMOTE ...` to put content onto a specific remote (ie, a `put`, when there is no `put`).
+"""]]
diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_9_17a75fa68bf3718230d1d523b7eb0250._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_9_17a75fa68bf3718230d1d523b7eb0250._comment
new file mode 100644
index 0000000000..2c3b4cf6bb
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_9_17a75fa68bf3718230d1d523b7eb0250._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 9"
+ date="2023-07-12T13:10:26Z"
+ content="""
+Fine with me to keep `git annex sync` at its old behaviour. I'm happy about `assist|push|pull` and would also be happy with a `metasync`.
+
+These are all decisions that joey will have to decide himself. He has written this amazing piece of software that I'll be forever grateful for (Thanks joey!!). If he decides that `git annex sync` syncs content, so be it.
+
+Your idea with moving the content-syncing into `init` sounds reasonable from a backwards-compatibility point of view. But I doubt joey will want to make `init` (or any other command) accumulate patchy stuff.
+"""]]
diff --git a/doc/bugs/Cloned_from_.git_under_Windows__44___get_fails.mdwn b/doc/bugs/Cloned_from_.git_under_Windows__44___get_fails.mdwn
new file mode 100644
index 0000000000..188efeaf2e
--- /dev/null
+++ b/doc/bugs/Cloned_from_.git_under_Windows__44___get_fails.mdwn
@@ -0,0 +1,292 @@
+### Please describe the problem.
+
+Under Windows (not tested in Unix), if an annex is cloned from the .git directory, git annex get fails and is different to cloning from workdir
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+shaddy@COMPUTER-W10 U:\Temp
+> git annex version
+git-annex version: 8.20211118-g2e2d35869
+build flags: Assistant Webapp Pairing TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 2 3 4 5 6 7
+
+shaddy@COMPUTER-W10 U:\Temp
+> dir
+ Volume in drive U has no label.
+ Volume Serial Number is D684-6493
+
+ Directory of U:\Temp
+
+13/01/2022  01:42 PM    <DIR>          .
+13/01/2022  01:42 PM    <DIR>          ..
+10/04/2020  07:36 PM        14,572,000 vc_redist.x64.exe
+               1 File(s)     14,572,000 bytes
+               2 Dir(s)  21,238,497,280 bytes free
+
+shaddy@COMPUTER-W10 U:\Temp
+> git init --separate-git-dir separategitmaster.git separategitmaster
+Initialized empty Git repository in U:/Temp/separategitmaster.git/
+
+shaddy@COMPUTER-W10 U:\Temp
+> cd separategitmaster
+
+shaddy@COMPUTER-W10 U:\Temp\separategitmaster
+> git annex init master
+init master
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Switched to branch 'adjusted/master(unlocked)'
+ok
+(recording state in git...)
+
+shaddy@COMPUTER-W10 U:\Temp\separategitmaster
+> copy ..\vc_redist.x64.exe .
+        1 file(s) copied.
+
+shaddy@COMPUTER-W10 U:\Temp\separategitmaster
+> git annex add vc_redist.x64.exe
+add vc_redist.x64.exe
+ok
+(recording state in git...)
+
+shaddy@COMPUTER-W10 U:\Temp\separategitmaster
+> git commit -m vc_redist.x64.exe
+[adjusted/master(unlocked) a32d7ba] vc_redist.x64.exe
+ 1 file changed, 1 insertion(+)
+ create mode 100755 vc_redist.x64.exe
+
+shaddy@COMPUTER-W10 U:\Temp\separategitmaster
+> cd ..
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitslave
+> REM note, cloning from workdir, not .git
+
+shaddy@COMPUTER-W10 U:\Temp
+> git clone separategitmaster separategitslave
+Cloning into 'separategitslave'...
+done.
+
+shaddy@COMPUTER-W10 U:\Temp
+> cd separategitslave
+
+shaddy@COMPUTER-W10 U:\Temp\separategitslave
+> dir
+ Volume in drive U has no label.
+ Volume Serial Number is D684-6493
+
+ Directory of U:\Temp\separategitslave
+
+13/01/2022  01:45 PM    <DIR>          .
+13/01/2022  01:45 PM    <DIR>          ..
+13/01/2022  01:45 PM               108 vc_redist.x64.exe
+               1 File(s)            108 bytes
+               2 Dir(s)  21,209,219,072 bytes free
+
+shaddy@COMPUTER-W10 U:\Temp\separategitslave
+> git config user.name "Shaddy Baddah"
+
+shaddy@COMPUTER-W10 U:\Temp\separategitslave
+> git annex init slave
+init slave
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+ok
+(recording state in git...)
+
+shaddy@COMPUTER-W10 U:\Temp\separategitslave
+> git annex sync
+commit
+On branch adjusted/master(unlocked)
+Your branch is up to date with 'origin/adjusted/master(unlocked)'.
+
+nothing to commit, working tree clean
+ok
+pull origin
+ok
+push origin
+Enumerating objects: 9, done.
+Counting objects: 100% (9/9), done.
+Delta compression using up to 2 threads
+Compressing objects: 100% (5/5), done.
+Writing objects: 100% (6/6), 718 bytes | 359.00 KiB/s, done.
+Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
+To U:/Temp/separategitmaster
+ * [new branch]      master -> synced/master
+ * [new branch]      git-annex -> synced/git-annex
+ok
+
+shaddy@COMPUTER-W10 U:\Temp\separategitslave
+> git annex get vc_redist.x64.exe
+get vc_redist.x64.exe (from origin...)
+ok
+(recording state in git...)
+
+shaddy@COMPUTER-W10 U:\Temp\separategitslave
+> REM All ok. But now lets clone from the .git dir
+
+shaddy@COMPUTER-W10 U:\Temp\separategitslave
+> cd ..
+
+shaddy@COMPUTER-W10 U:\Temp
+> git init --separate-git-dir separatetake2gitmaster.git separatetake2gitmaster
+Initialized empty Git repository in U:/Temp/separatetake2gitmaster.git/
+
+shaddy@COMPUTER-W10 U:\Temp
+> cd separatetake2gitmaster
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitmaster
+> git annex init master
+init master
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Switched to branch 'adjusted/master(unlocked)'
+ok
+(recording state in git...)
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitmaster
+> copy ..\vc_redist.x64.exe .
+        1 file(s) copied.
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitmaster
+> git annex add vc_redist.x64.exe
+add vc_redist.x64.exe
+ok
+(recording state in git...)
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitmaster
+> git commit -m vc_redist.x64.exe
+git-annex.exe: .\vc_redist.x64.exe: DeleteFile "\\\\?\\U:\\Temp\\separatetake2gitmaster\\vc_redist.x64.exe": permission denied (The process cannot access the file because it is being used by another process.)
+error: external filter 'git-annex smudge --clean -- %f' failed 1
+error: external filter 'git-annex smudge --clean -- %f' failed
+[adjusted/master(unlocked) 50bb6c7] vc_redist.x64.exe
+ 1 file changed, 1 insertion(+)
+ create mode 100755 vc_redist.x64.exe
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitmaster
+> REM unfortunate Windows gotcha, but I believe it doesnt effect the scenario
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitmaster
+> dir
+ Volume in drive U has no label.
+ Volume Serial Number is D684-6493
+
+ Directory of U:\Temp\separatetake2gitmaster
+
+13/01/2022  01:47 PM    <DIR>          .
+13/01/2022  01:47 PM    <DIR>          ..
+10/04/2020  07:36 PM        14,572,000 vc_redist.x64.exe
+               1 File(s)     14,572,000 bytes
+               2 Dir(s)  21,149,949,952 bytes free
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitmaster
+> cd ..\
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitmaster
+> REM cloning from the .git this time
+
+shaddy@COMPUTER-W10 U:\Temp
+> git clone separatetake2gitmaster.git separatetake2gitslave
+Cloning into 'separatetake2gitslave'...
+done.
+
+shaddy@COMPUTER-W10 U:\Temp
+> cd separatetake2gitslave
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitslave
+> git annex init slave
+init slave
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+ok
+(recording state in git...)
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitslave
+> dir
+ Volume in drive U has no label.
+ Volume Serial Number is D684-6493
+
+ Directory of U:\Temp\separatetake2gitslave
+
+13/01/2022  01:48 PM    <DIR>          .
+13/01/2022  01:48 PM    <DIR>          ..
+13/01/2022  01:48 PM               108 vc_redist.x64.exe
+               1 File(s)            108 bytes
+               2 Dir(s)  21,149,868,032 bytes free
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitslave
+> git annex sync
+commit
+On branch adjusted/master(unlocked)
+Your branch is up to date with 'origin/adjusted/master(unlocked)'.
+
+nothing to commit, working tree clean
+ok
+pull origin
+ok
+push origin
+Enumerating objects: 9, done.
+Counting objects: 100% (9/9), done.
+Delta compression using up to 2 threads
+Compressing objects: 100% (5/5), done.
+Writing objects: 100% (6/6), 719 bytes | 719.00 KiB/s, done.
+Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
+To U:/Temp/separatetake2gitmaster.git
+ * [new branch]      master -> synced/master
+ * [new branch]      git-annex -> synced/git-annex
+ok
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitslave
+> git annex get vc_redist.x64.exe
+get vc_redist.x64.exe
+  Unable to access these remotes: origin
+
+  No other repository is known to contain the file.
+failed
+get: 1 failed
+
+shaddy@COMPUTER-W10 U:\Temp\separatetake2gitslave
+> REM this is a confusing situation and repeatable
+# End of transcript or log.
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+shaddy@COMPUTER-W10 U:\Temp
+> git annex version
+git-annex version: 8.20211118-g2e2d35869
+
+### Please provide any additional information below.
+
+[[!format sh """
+Note, in my example, I'm using a .git directory that has been "separated" from its workdir.
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes. Git annex is very good. I acknowledge that the way I use it can be unconventional.
diff --git a/doc/bugs/Cloned_from_.git_under_Windows__44___get_fails/comment_1_0d619c1a4c9645a6b76619b05b3d518c._comment b/doc/bugs/Cloned_from_.git_under_Windows__44___get_fails/comment_1_0d619c1a4c9645a6b76619b05b3d518c._comment
new file mode 100644
index 0000000000..d5485f8c1d
--- /dev/null
+++ b/doc/bugs/Cloned_from_.git_under_Windows__44___get_fails/comment_1_0d619c1a4c9645a6b76619b05b3d518c._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-25T16:42:36Z"
+ content="""
+I can reproduce this on linux.
+
+It's getting confused by a url pointing to a git directory that has
+core.bare=false.
+
+git-annex's RepoLocation data type does not have a way to represent
+this situation, and it would complicate it significantly to do so.
+
+I do not see any good reason to use a non-bare git directory as if it is a
+bare repository. Not good enough for me to spend days complicating
+git-annex's code for anyway. Is there a good reason you are doing that?
+"""]]
diff --git a/doc/bugs/Cloned_from_.git_under_Windows__44___get_fails/comment_2_0bc5932c037002dac6b096f97d12584c._comment b/doc/bugs/Cloned_from_.git_under_Windows__44___get_fails/comment_2_0bc5932c037002dac6b096f97d12584c._comment
new file mode 100644
index 0000000000..2c148ed31f
--- /dev/null
+++ b/doc/bugs/Cloned_from_.git_under_Windows__44___get_fails/comment_2_0bc5932c037002dac6b096f97d12584c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="comment 2"
+ date="2022-03-18T08:37:22Z"
+ content="""
+There's no real good reason for me doing this. I just thought I'd report it because usually, the two ways to clone (from bare, or not), are usually interchangeable.
+
+That's fine if there is no fix.
+"""]]
diff --git a/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_.mdwn b/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_.mdwn
new file mode 100644
index 0000000000..5ca73dd805
--- /dev/null
+++ b/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_.mdwn
@@ -0,0 +1,46 @@
+### Please describe the problem.
+
+Any file containing non ascii chars either won't get commited by the webapp or when clone of that repo is made they are shown as deleted in git status but the files are there. 
+
+you can not commit them neither,
+
+    git commit -m 'foo'
+
+or
+ 
+    git annex sync
+
+will get them to commit trying to reset the state using, 
+     
+    git checkout master 
+
+or 
+
+    git clean -f 
+
+won't fix the issue. till the issue is fixed sync does not work from the command line since there are changes. Temporarily running assistant in the directory does fix the problem but every now and then it pops again.
+
+Also moving any symlinks around containing non ascii chars also causes the same issue. git annex won't add the moved symlinks git annex fix or git annex add won't add them git annex sync also skips them again the only solution is to either run the assistant or restart it if it is running.
+
+### What steps will reproduce the problem?
+
+Adding any file with a non ascii char on OS X (10.9).
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20140421-gc34a665
+
+### Please provide any additional information below.
+
+Also another thing I noticed is that same file names same repo will clone fine on Linux no errors this only happens on OS X.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_1_81a4647a9b51bed8c230a2a16990915d._comment b/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_1_81a4647a9b51bed8c230a2a16990915d._comment
new file mode 100644
index 0000000000..e600657377
--- /dev/null
+++ b/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_1_81a4647a9b51bed8c230a2a16990915d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.36"
+ subject="comment 1"
+ date="2014-05-24T19:23:08Z"
+ content="""
+I think you are going to need to provide more information:
+
+* Some actual file names that have the problem. \"non-ascii chars\" is a very wide description, you don't even say if you're using unicode or what.
+* Some error messages or transcripts of what happens when you see the problem.
+* What is your locale setting on OSX.
+
+I tried with some unicode filenames on OSX and they were committed without difficulty in the en_US.utf8 locale.
+"""]]
diff --git a/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_2_f8e97dded9ba6d2305de1278025924fe._comment b/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_2_f8e97dded9ba6d2305de1278025924fe._comment
new file mode 100644
index 0000000000..b404cc3817
--- /dev/null
+++ b/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_2_f8e97dded9ba6d2305de1278025924fe._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 2"
+ date="2014-05-25T15:16:33Z"
+ content="""
+I file name I remember messing is the following,
+
+    George's Café
+
+I experience this problem with any char that is not ascii. As for my locale,
+
+LANG=\"en_US.UTF-8\"
+LC_COLLATE=\"en_US.UTF-8\"
+LC_CTYPE=\"en_US.UTF-8\"
+LC_MESSAGES=\"en_US.UTF-8\"
+LC_MONETARY=\"en_US.UTF-8\"
+LC_NUMERIC=\"en_US.UTF-8\"
+LC_TIME=\"en_US.UTF-8\"
+LC_ALL=\"en_US.UTF-8\"
+
+There no errors other than the behaviour I've described.
+"""]]
diff --git a/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_3_eb34061429cb8c7d0b155825e84b657b._comment b/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_3_eb34061429cb8c7d0b155825e84b657b._comment
new file mode 100644
index 0000000000..acd5775cd5
--- /dev/null
+++ b/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_3_eb34061429cb8c7d0b155825e84b657b._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 3"
+ date="2014-05-27T18:02:11Z"
+ content="""
+I tried with that filename, and had no difficulty committing it.
+
+<pre>
+oberon:repo joeyh$ git annex add George\'s\ Cafe\314\201 
+add George's Café ok
+(Recording state in git...)
+oberon:repo joeyh$ git commit -m foo
+[master (root-commit) 8acd5d4] foo
+ Committer: Joey Hess <joeyh@oberon.local.tam-lin.net>
+Your name and email address were configured automatically based
+on your username and hostname. Please check that they are accurate.
+You can suppress this message by setting them explicitly:
+
+    git config --global user.name \"Your Name\"
+    git config --global user.email you@example.com
+
+After doing this, you may fix the identity used for this commit with:
+
+    git commit --amend --reset-author
+
+ 1 file changed, 1 insertion(+)
+ create mode 120000 \"George's Caf\303\251\"
+
+</pre>
+
+I even tried running the assistant with all locale settings set to C, and it still had no problem adding and committing that filename.
+
+So, I need help reproducing this, or I need to see the error message you see when the problem happens to you.
+"""]]
diff --git a/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_4_8cf5dc85a94c60b9c88c8e8354f19772._comment b/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_4_8cf5dc85a94c60b9c88c8e8354f19772._comment
new file mode 100644
index 0000000000..ca4b9ad14f
--- /dev/null
+++ b/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_4_8cf5dc85a94c60b9c88c8e8354f19772._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="https://joelpurra.com/"
+ avatar="http://cdn.libravatar.org/avatar/6b09b608da8a2f34acf3d89caf8b7438ddbd404bb2db31414855118a7dab678c"
+ subject="macOS HFS+, core.precomposeUnicode"
+ date="2017-01-13T14:27:15Z"
+ content="""
+@joeyh.name: did you notice the subtle difference between the filename in the input and the output in your example? I think it might cause problems due to a discrepancy between `git annex` and the file system when checking if a file exists or not. Not sure if the problem is in `git` or `git annex`; what do you think?
+
+```text
+git annex add George\'s\ Cafe\314\201
+...
+create mode 120000 \"George's Caf\303\251\"
+```
+
+See [Unicode Subtleties in the HFS Plus Volume Format](https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#UnicodeSubtleties) and `git config` for [`core.precomposeUnicode`](https://git-scm.com/docs/git-config#git-config-coreprecomposeUnicode)
+
+Here's a `printf` example.
+
+```bash
+printf '\303\251 e\314\201 (note double space)  \314\201'
+```
+```text
+é é (note double space)  ́
+```
+```bash
+printf '\303\251 e\314\201 (note double space)  \314\201' | LC_ALL=C vis -otc
+```
+```text
+\303\251 e\314\201 (note double space)  \314\201
+```
+
+"""]]
diff --git a/doc/bugs/Continual_space_exhaustion_from_syncing_metadata.mdwn b/doc/bugs/Continual_space_exhaustion_from_syncing_metadata.mdwn
new file mode 100644
index 0000000000..ca826fb7fb
--- /dev/null
+++ b/doc/bugs/Continual_space_exhaustion_from_syncing_metadata.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+When the preferred content for a repo is greater than the free space on the drive for me, the space becomes exhausted due to upload that occurs during syncing -- the git history ends up exhausting the space.  The result for me has been corrupted repos with broken refs and heads.
+
+I think it would be better if the git syncing process respected the same space limitations that the content syncing does, and did not push if space was exhausted on the destination, nor pull if space exhausted locally.
+
+### What steps will reproduce the problem?
+Make enough git commits that it exhausts the free space on some repo.
+
+### What version of git-annex are you using? On what operating system?
+I've been using a few different versions; right now I am using 6.2016-0511 and 6.2016-0517-g766728c
+but I have not tested this issue with these most recent versions.  I am still trying to get my smaller repos back together.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes !!! I'm moving all my files into my annex.  It is very robust; whenever something is wrong there is always some other copy somewhere that can be used.
+
diff --git a/doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_1_93e3deab54b34e9ad608fd549119e221._comment b/doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_1_93e3deab54b34e9ad608fd549119e221._comment
new file mode 100644
index 0000000000..df07a2a8ad
--- /dev/null
+++ b/doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_1_93e3deab54b34e9ad608fd549119e221._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-23T18:02:11Z"
+ content="""
+It would be nice if git checked disk space before writing object
+files. However, it unfortunatly does not do so currently, and not checking
+disk space is typical of unix tools so it might be hard to convince the git
+devs to add that.
+
+git-annex has annex.diskreserve because it's dealing with so much data and
+such large files that it's best to not let it fill the disk and instead
+abort before it downloads too much data.
+
+I don't see any way that git-annex can avoid git objects taking up too much
+disk space, without re-implementing all of git + space checking. 
+
+Sure, `git annex sync` could avoid pulling if annex.diskreserve was not
+free, but this would not help with manual `git pull`, or `git commit`, or
+`git receive-pack`, or any of the other ways objects can be added to a git
+repository.
+
+What you can do though, is set annex.diskreserve to a reasonably
+large amount, so that git-annex tries to keep that much space free.
+Eg, set it to at least half the current size of `du -hs .git/objects`
+"""]]
diff --git a/doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_2_9401be5e6af886edadaf3ad7ba6a071d._comment b/doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_2_9401be5e6af886edadaf3ad7ba6a071d._comment
new file mode 100644
index 0000000000..f0a570eae7
--- /dev/null
+++ b/doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_2_9401be5e6af886edadaf3ad7ba6a071d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="comment 2"
+ date="2016-10-09T12:13:38Z"
+ content="""
+I'm still running into this issue.  Although it is true that users can manually exhaust space, they are in control of what is happening, get more feedback, and there is no automatic process that will continue to fail further when the space is exhausted.
+
+I do not use the assistant because of its frequent syncing causing complete space exhaustion, and then its inability to recover because it cannot write temporary or log files.  Occasionally I have accidentally committed huge files directly to git, and this has also caused the issue.
+
+I think it would be really great if git annex prevented this workflow-halting event at least by refusing to pull/commit/etc if reserved space is not met unless --force is passed.  Additionally, it would really be great if actions that result in space exhaustion (fail, and then free space == 0) cleaned up their temporary files after the fact, certainly before trying to log anything.
+
+"""]]
diff --git a/doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_3_3309c51dbd251cc46a25557a0d25e946._comment b/doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_3_3309c51dbd251cc46a25557a0d25e946._comment
new file mode 100644
index 0000000000..55c5122b37
--- /dev/null
+++ b/doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_3_3309c51dbd251cc46a25557a0d25e946._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jgsuess@732b8c62c50d8595d7b1d58eea11e5019c2308b1"
+ nickname="jgsuess"
+ avatar="http://cdn.libravatar.org/avatar/35a99d1b5df046b206807941ce9795d3"
+ subject="Automatic watch for the heuristic"
+ date="2021-08-07T12:25:02Z"
+ content="""
+It seems there is a good heuristic based on the object size. It is given in this thread. Could this check not be used in annex automatic syncing modes to avoid this problem. I have run into it several times now and recovery, while possible, is time-consuming and messy.
+"""]]
diff --git a/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow.mdwn b/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow.mdwn
new file mode 100644
index 0000000000..1fac81f073
--- /dev/null
+++ b/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow.mdwn
@@ -0,0 +1,81 @@
+### Please describe the problem.
+
+Copying many files (thousands) to a bup remote is *very* slow. <1MiB/s slow.
+
+When evaluating multiple options for compressed deduplicated storage, I tried storing my documents repo that has 1.35 gigabytes split across 1265 local annex keys.
+
+This is how long it took (tmpfs -> bup in tmpfs):
+
+```
+* J1
+  real    72m19.684s
+  user    63m8.171s
+  sys     12m10.564s
+* J2
+  copy: 3 failed
+
+  real    37m1.465s
+  user    66m24.674s
+  sys     11m48.973s
+* J4
+  copy: 17 failed
+
+  real    22m36.806s
+  user    75m21.566s
+  sys     12m54.847s
+```
+
+(Failures due to https://git-annex.branchable.com/bugs/bup_often_errors_out_when_-J___62___1/)
+ 
+
+### What steps will reproduce the problem?
+
+```
+$ cd /tmp
+$ wget http://sun.aei.polsl.pl/~sdeor/corpus/silesia.zip
+$ unzip silesia.zip
+$ cd silesia
+$ git init
+$ git annex init
+$ git annex add
+$ git commit -m "silesia corpus"
+$ git annex initremote bup type=bup bupdir=/tmp/bup
+$ time git annex copy --to bup -J4
+```
+
+Will be decently fast: 12s on my machine (~17MB/s).
+
+Now do the same but untar+rm mozilla, samba and xml before adding.
+
+On my machine, it now took **34 minutes**; 210MiB/24min ~= 0.1MiB/s.
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 10.20220624
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.11 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin aarch64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+```
+
+(Same happens on Linux)
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_1_d81f94dfdb1b15b8bc0d9c243ef748db._comment b/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_1_d81f94dfdb1b15b8bc0d9c243ef748db._comment
new file mode 100644
index 0000000000..75f8eaec6c
--- /dev/null
+++ b/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_1_d81f94dfdb1b15b8bc0d9c243ef748db._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-08T15:24:36Z"
+ content="""
+I don't think that git-annex is doing anything particularly slow with the
+bup special remote. Other than actually running bup, that special remote
+should run about as fast as other similar special remotes, like say
+the directory special remote.
+
+So, this is probably a performance problem in bup. Now, git-annex does
+use bup in an unusual way, running one bup-split per file to store in it.
+That was the only way to shoehorn what git-annex needs to do into bup
+though.
+"""]]
diff --git a/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_2_0f5ff10d84450a6df35cb974cdb4739e._comment b/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_2_0f5ff10d84450a6df35cb974cdb4739e._comment
new file mode 100644
index 0000000000..c82b5371e9
--- /dev/null
+++ b/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_2_0f5ff10d84450a6df35cb974cdb4739e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 2"
+ date="2022-08-09T06:14:05Z"
+ content="""
+Agreed.
+
+I see two potential ways to improve performance:
+
+* Batching:
+  Bup can split multiple files at once. If it's given 10, 20, 100 files at a time, the per-split overhead matters less. Batching is something git-annex might need to learn sooner or later anyways because file transfer generally doesn't scale well currently (bup's slowness just exacerbates the problem).
+* Bup index+save:
+  Use the same pattern as Borg. Back up the whole git-annex repo at a time and selectively restore in order to `get`. Not sure this would be a great idea but it should improve performance in my use-case (copy everything).
+"""]]
diff --git a/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_3_7150178b47a15857d5eece0fbe57a971._comment b/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_3_7150178b47a15857d5eece0fbe57a971._comment
new file mode 100644
index 0000000000..3fcd26ce91
--- /dev/null
+++ b/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_3_7150178b47a15857d5eece0fbe57a971._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-08-09T16:28:16Z"
+ content="""
+While `bup split` can run on multiple files at once, it concacenates the
+files together and stores a single object. That is not useful for git-annex.
+
+Using the borg pattern with bup is a good idea.
+"""]]
diff --git a/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_4_d2896b544d6d26663b532735c3924134._comment b/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_4_d2896b544d6d26663b532735c3924134._comment
new file mode 100644
index 0000000000..4e52bc45ad
--- /dev/null
+++ b/doc/bugs/Copying_many_files_to_bup_remotes_is_very_slow/comment_4_d2896b544d6d26663b532735c3924134._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 4"
+ date="2022-08-10T12:35:27Z"
+ content="""
+Indeed it does. I assumed it'd concatenate the files internally for efficiency but is still able to output them separately later but that is not the case. I guess you could store the offsets externally and skip/seek but that'd be inefficient. 
+Perhaps bup could add an option for batching multiple singular-file splits in one invocation to avoid overhead.
+
+Alternatively, git-annex could index+save using excludes. That could be quite complicated (especially tracking which object exists inside which batches) but it could work.
+"""]]
diff --git a/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant.mdwn b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant.mdwn
new file mode 100644
index 0000000000..efe32c8397
--- /dev/null
+++ b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant.mdwn
@@ -0,0 +1,658 @@
+### Please describe the problem.
+I’ve noticed a repo in which I’m running the assistant wouldn’t push updates to its remote anymore. Inspecting the assistant log revealed that there was a problem with the index used for the git-annex branch. After deleting the index file, the assistant could sync to the remote again. (Could deleting the annex index have introduced any inconsistencies into the git-annex branch?)
+
+### What steps will reproduce the problem?
+Uncertain. However, I made a copy of .git/annex/index and can reproduce the error by cloning my original repo, checking out the git-annex branch, copying in the backed-up index file and doing git write-tree, which then yields an invalid object error.
+
+It looks like the respective object isn’t present in the git object store. The error is for b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8, but no directory .git/objects/b5 exists (even after unpacking packed objects).
+
+I could supply you with the index file; do you need anything else? If I don’t clone from my repo, I obviously get an invalid object for everything; should I supply you with a git-bundle of the git-annex ref?
+
+### What version of git-annex are you using? On what operating system?
+git-annex 5.20150508-1
+Linux 4.0.5
+
+### Please provide any additional information below.
+
+Below is the daemon.log* concatenated, starting with the earliest one. Grep for “invalid object” or “write tree”.
+
+[[!format sh """
+[2015-06-05 16:59:45 CEST] main: starting assistant version 5.20150508-g883d57f
+[2015-06-05 16:59:45 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2015-06-05 16:59:57 CEST] TransferScanner: Syncing with origin 
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2015-06-05 16:59:57 CEST] Watcher: Performing startup scan
+(started...) [2015-06-05 16:59:58 CEST] RemoteControl: Syncing with origin 
+gpg: assuming signed data in '/tmp/git-annex.tmp.0/info'
+gpg: Signature made Thu May 28 19:01:58 2015 CEST using DSA key ID 89C809CB
+gpg: /tmp/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-06-05 16:59:58 CEST] Upgrader: An upgrade of git-annex is available.  (version 5.20150528)
+[2015-06-05 16:59:59 CEST] Committer: Committing changes to git
+[2015-06-05 16:59:59 CEST] Pusher: Syncing with origin 
+error: Unable to create '/home/seb/Annex/.git/refs/remotes/origin/master.lock': File exists.
+
+If no other git process is currently running, this probably means a
+git process crashed in this repository earlier. Make sure no other git
+process is running and remove the file manually to continue.
+error: Cannot lock the ref 'refs/remotes/origin/master'.
+From ssh://redacted.net/srv/git/seb/annex/annex
+ ! d71a4e0..1f265ec  master     -> origin/master  (unable to update local ref)
+From ssh://redacted.net/srv/git/seb/annex/annex
+   d71a4e0..1f265ec  master     -> origin/master
+error: Unable to create '/home/seb/Annex/.git/refs/remotes/origin/git-annex.lock': File exists.
+
+If no other git process is currently running, this probably means a
+git process crashed in this repository earlier. Make sure no other git
+process is running and remove the file manually to continue.
+error: Cannot lock the ref 'refs/remotes/origin/git-annex'.
+ ! 33446d6..973fbda  git-annex  -> origin/git-annex  (unable to update local ref)
+   33446d6..973fbda  git-annex  -> origin/git-annex
+error: Unable to create '/home/seb/Annex/.git/refs/remotes/origin/synced/git-annex.lock': File exists.
+
+If no other git process is currently running, this probably means a
+git process crashed in this repository earlier. Make sure no other git
+process is running and remove the file manually to continue.
+error: Cannot lock the ref 'refs/remotes/origin/synced/git-annex'.
+ ! 33446d6..973fbda  synced/git-annex -> origin/synced/git-annex  (unable to update local ref)
+   d71a4e0..1f265ec  synced/master -> origin/synced/master
+   33446d6..973fbda  synced/git-annex -> origin/synced/git-annex
+error: Ref refs/remotes/origin/synced/master is at 1f265ecc6288ead453681794551c527f64660f8c but expected d71a4e027cdd61c1323fbdc67103dde97f613192
+error: Cannot lock the ref 'refs/remotes/origin/synced/master'.
+ ! d71a4e0..1f265ec  synced/master -> origin/synced/master  (unable to update local ref)
+Updating d71a4e0..1f265ec
+Fast-forward
+ org/software/software.org | 4 +++-
+ org/software/theming.org  | 7 +++++++
+ 2 files changed, 10 insertions(+), 1 deletion(-)
+Already up-to-date.
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+ + 973fbda...33446d6 git-annex -> synced/git-annex (forced update)
+ ! [rejected]        master -> synced/master (non-fast-forward)
+error: failed to push some refs to 'ssh://redacted.net/srv/git/seb/annex/annex.git'
+hint: Updates were rejected because a pushed branch tip is behind its remote
+hint: counterpart. Check out this branch and integrate the remote changes
+hint: (e.g. 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+[2015-06-05 17:00:00 CEST] Committer: Committing changes to git
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   33446d6..973fbda  git-annex -> synced/git-annex
+Everything up-to-date
+[2015-06-05 17:00:05 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+Connection to redacted.net closed by remote host.
+ssh: connect to host redacted.nessh: connect to host redactedssh: connect to host redacted.n[2015-06-05 17:59:57 CEST] NetWatcherFallback: Syncing with origin 
+Everything up-to-date
+[2015-06-05 18:51:33 CEST] Committer: Committing changes to git
+[2015-06-05 18:51:33 CEST] Pusher: Syncing with origin 
+[2015-06-05 18:51:34 CEST] Committer: Committing changes to git
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   1f265ec..1cee9eb  master -> synced/master
+[2015-06-05 18:51:37 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 19:00:01 CEST] NetWatcherFallback: Syncing with origin 
+Everything up-to-date
+packet_write_wait: Connection to 37.221.198.119: Broken pipe
+[2015-06-05 20:00:03 CEST] NetWatcherFallback: Syncing with origin 
+Everything up-to-date
+[2015-06-05 20:13:01 CEST] main: starting assistant version 5.20150508-g883d57f
+[2015-06-05 20:13:01 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2015-06-05 20:13:12 CEST] TransferScanner: Syncing with origin 
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2015-06-05 20:13:12 CEST] Watcher: Performing startup scan
+(started...) gpg: assuming signed data in '/tmp/git-annex.tmp.0/info'
+gpg: Signature made Thu May 28 19:01:58 2015 CEST using DSA key ID 89C809CB
+gpg: /tmp/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-06-05 20:13:13 CEST] Upgrader: An upgrade of git-annex is available.  (version 5.20150528)
+Everything up-to-date
+[2015-06-05 20:13:14 CEST] Committer: Committing changes to git
+[2015-06-05 20:13:14 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 21:13:12 CEST] NetWatcherFallback: Syncing with origin 
+Everything up-to-date
+[2015-06-05 22:13:14 CEST] NetWatcherFallback: Syncing with origin 
+Everything up-to-date
+[2015-06-05 22:33:04 CEST] Committer: Committing changes to git
+[2015-06-05 22:33:04 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 22:33:08 CEST] Committer: Committing changes to git
+[2015-06-05 22:33:08 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 22:33:11 CEST] Committer: Committing changes to git
+[2015-06-05 22:33:11 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 22:33:14 CEST] Committer: Committing changes to git
+[2015-06-05 22:33:14 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 22:33:16 CEST] Committer: Committing changes to git
+[2015-06-05 22:33:18 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 22:33:20 CEST] Committer: Committing changes to git
+[2015-06-05 22:33:21 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 22:33:27 CEST] Committer: Committing changes to git
+[2015-06-05 22:33:27 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 22:33:28 CEST] Committer: Committing changes to git
+[2015-06-05 22:33:30 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 22:33:37 CEST] Committer: Committing changes to git
+[2015-06-05 22:33:37 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 22:33:43 CEST] Committer: Committing changes to git
+[2015-06-05 22:33:43 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 22:34:12 CEST] Committer: Committing changes to git
+[2015-06-05 22:34:12 CEST] Pusher: Syncing with origin 
+[2015-06-05 22:34:13 CEST] Committer: Committing changes to git
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   1cee9eb..46828df  master -> synced/master
+[2015-06-05 22:34:15 CEST] Pusher: Syncing with origin 
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   46828df..8e93c98  master -> synced/master
+[2015-06-05 22:34:23 CEST] Committer: Committing changes to git
+[2015-06-05 22:34:23 CEST] Pusher: Syncing with origin 
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   8e93c98..9bed0e6  master -> synced/master
+[2015-06-05 22:34:24 CEST] Committer: Committing changes to git
+[2015-06-05 22:34:27 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 23:04:49 CEST] Committer: Committing changes to git
+[2015-06-05 23:04:49 CEST] Pusher: Syncing with origin 
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   9bed0e6..ec8f2c4  master -> synced/master
+[2015-06-05 23:04:50 CEST] Committer: Committing changes to git
+[2015-06-05 23:04:52 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 23:11:39 CEST] Committer: Committing changes to git
+[2015-06-05 23:11:39 CEST] Pusher: Syncing with origin 
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   ec8f2c4..14bc26a  master -> synced/master
+[2015-06-05 23:11:40 CEST] Committer: Committing changes to git
+[2015-06-05 23:11:43 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 23:13:16 CEST] NetWatcherFallback: Syncing with origin 
+Everything up-to-date
+[2015-06-05 23:33:28 CEST] Committer: Committing changes to git
+[2015-06-05 23:33:28 CEST] Pusher: Syncing with origin 
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   14bc26a..bd150f5  master -> synced/master
+[2015-06-05 23:33:29 CEST] Committer: Committing changes to git
+[2015-06-05 23:33:32 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 23:34:09 CEST] Committer: Committing changes to git
+[2015-06-05 23:34:09 CEST] Pusher: Syncing with origin 
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   bd150f5..290c21c  master -> synced/master
+[2015-06-05 23:34:10 CEST] Committer: Committing changes to git
+[2015-06-05 23:34:12 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 23:34:15 CEST] Committer: Committing changes to git
+[2015-06-05 23:34:15 CEST] Pusher: Syncing with origin 
+[2015-06-05 23:34:16 CEST] Committer: Committing changes to git
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   290c21c..a56091f  master -> synced/master
+[2015-06-05 23:34:19 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-05 23:35:17 CEST] Committer: Committing changes to git
+[2015-06-05 23:35:17 CEST] Pusher: Syncing with origin 
+[2015-06-05 23:35:18 CEST] Committer: Committing changes to git
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   a56091f..2fb635b  master -> synced/master
+[2015-06-05 23:35:21 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+
+  lost dbus connection; falling back to polling (ClientError {clientErrorMessage = "Error reading message from socket: UnmarshalError \"Unexpected end of input while parsing message header.\"", clientErrorFatal = True})
+
+  dbus failed; falling back to mtab polling (ClientError {clientErrorMessage = "Error reading message from socket: UnmarshalError \"Unexpected end of input while parsing message header.\"", clientErrorFatal = True})
+[2015-06-06 07:17:17 CEST] main: starting assistant version 5.20150508-g883d57f
+[2015-06-06 07:17:17 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2015-06-06 07:17:25 CEST] TransferScanner: Syncing with origin 
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2015-06-06 07:17:30 CEST] Watcher: Performing startup scan
+gpg: assuming signed data in '/tmp/git-annex.tmp.0/info'
+gpg: Signature made Thu May 28 19:01:58 2015 CEST using DSA key ID 89C809CB
+gpg: /tmp/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-06-06 07:17:32 CEST] Upgrader: An upgrade of git-annex is available.  (version 5.20150528)
+Everything up-to-date
+(started...) [2015-06-06 07:17:36 CEST] Committer: Committing changes to git
+[2015-06-06 07:17:36 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-06 07:45:05 CEST] main: starting assistant version 5.20150508-g883d57f
+[2015-06-06 07:45:05 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2015-06-06 07:45:10 CEST] TransferScanner: Syncing with origin 
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2015-06-06 07:45:10 CEST] Watcher: Performing startup scan
+(started...) /usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'notifychanges' '/srv/git/seb/annex/annex.git' --uuid a2131774-31b2-47d2-9185-b2e344c16134' is not rsync
+gpg: assuming signed data in '/tmp/git-annex.tmp.0/info'
+gpg: Signature made Thu May 28 19:01:58 2015 CEST using DSA key ID 89C809CB
+gpg: /tmp/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-06-06 07:45:12 CEST] Upgrader: An upgrade of git-annex is available.  (version 5.20150528)
+[2015-06-06 07:45:12 CEST] Committer: Committing changes to git
+[2015-06-06 07:45:12 CEST] Pusher: Syncing with origin 
+/usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'notifychanges' '/srv/git/seb/annex/annex.git' --uuid a2131774-31b2-47d2-9185-b2e344c16134' is not rsync
+Everything up-to-date
+Everything up-to-date
+/usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'notifychanges' '/srv/git/seb/annex/annex.git' --uuid a2131774-31b2-47d2-9185-b2e344c16134' is not rsync
+/usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'notifychanges' '/srv/git/seb/annex/annex.git' --uuid a2131774-31b2-47d2-9185-b2e344c16134' is not rsync
+/usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'notifychanges' '/srv/git/seb/annex/annex.git' --uuid a2131774-31b2-47d2-9185-b2e344c16134' is not rsync
+/usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'notifychanges' '/srv/git/seb/annex/annex.git' --uuid a2131774-31b2-47d2-9185-b2e344c16134' is not rsync
+/usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'notifychanges' '/srv/git/seb/annex/annex.git' --uuid a2131774-31b2-47d2-9185-b2e344c16134' is not rsync
+
+(recording state in git...)
+
+  bugs/nouveau-bug/nouveau.log.8 still has writers, not adding
+[2015-06-06 07:47:04 CEST] Committer: Adding nouveau.log.8
+add bugs/nouveau-bug/nouveau.log.8 [2015-06-06 07:47:04 CEST] Committer: Committing changes to git
+[2015-06-06 07:47:04 CEST] Pusher: Syncing with origin 
+error: invalid object 100644 b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8 for '88c/df4/SHA256E-s4644--eca6d831c0a94895a81296327bc21bdf417234c7ebfa3e93fd21a71523ac9da9.log.6.log'
+fatal: git-write-tree: error building trees
+Pusher crashed: failed to read sha from git write-tree
+[2015-06-06 07:47:04 CEST] Pusher: warning Pusher crashed: failed to read sha from git write-tree
+/usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'recvkey' '/srv/git/seb/annex/annex.git' 'SHA256E-s4491--e35540a06d6839455b48ecd8f2a4c7714d420379bae55a7b383dc1a5dc60d8e0.log.8' --uuid a2131774-31b2-47d2-9185-b2e344c16134 '--' 'remoteuuid=1dda4b9a-1ff2-4a9b-aaf8-47dfdd02c8ae' 'direct=' 'associatedfile=bugs/nouveau-bug/nouveau.log.8' '--' dummy rsync --server -pe.Lsfx --log-format=X --inplace . .' is not rsync
+rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.1]
+[2015-06-06 07:47:05 CEST] Committer: Committing changes to git
+/usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'recvkey' '/srv/git/seb/annex/annex.git' 'SHA256E-s4491--e35540a06d6839455b48ecd8f2a4c7714d420379bae55a7b383dc1a5dc60d8e0.log.8' --uuid a2131774-31b2-47d2-9185-b2e344c16134 '--' 'remoteuuid=1dda4b9a-1ff2-4a9b-aaf8-47dfdd02c8ae' 'direct=' 'associatedfile=bugs/nouveau-bug/nouveau.log.8' '--' dummy rsync --server -pe.Lsfx --log-format=X --inplace . .' is not rsync
+rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.1]
+/usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'notifychanges' '/srv/git/seb/annex/annex.git' --uuid a2131774-31b2-47d2-9185-b2e344c16134' is not rsync
+/usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'notifychanges' '/srv/git/seb/annex/annex.git' --uuid/usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'notifychanges' '/srv/git/seb/annex/annex.git' --uuid a2131774-31b2-47d2-9185-b2e344c16134' is not rsync
+/usr/lib/rsync/rrsync: SSH_ORIGINAL_COMMAND='git-annex-shell 'notifychanges' '/srv/git/seb/annex/annex.git' --uuid a2131774-31b2-47d2-9185-b2e344c16134' is not rsync
+[2015-06-06 08:45:10 CEST] NetWatcherFallback: Syncing with origin 
+error: invalid object 100644 b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8 for '88c/df4/SHA256E-s4644--eca6d831c0a94895a81296327bc21bdf417234c7ebfa3e93fd21a71523ac9da9.log.6.log'
+fatal: git-write-tree: error building trees
+NetWatcherFallback crashed: failed to read sha from git write-tree
+[2015-06-06 08:45:12 CEST] NetWatcherFallback: warning NetWatcherFallback crashed: failed to read sha from git write-tree
+[2015-06-06 15:58:38 CEST] main: starting assistant version 5.20150508-g883d57f
+[2015-06-06 15:58:38 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2015-06-06 15:58:44 CEST] TransferScanner: Syncing with origin 
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2015-06-06 15:58:44 CEST] Watcher: Performing startup scan
+(started...) gpg: assuming signed data in '/tmp/git-annex.tmp.0/info'
+gpg: Signature made Thu May 28 19:01:58 2015 CEST using DSA key ID 89C809CB
+gpg: /tmp/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-06-06 15:58:45 CEST] Upgrader: An upgrade of git-annex is available.  (version 5.20150528)
+error: invalid object 100644 b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8 for '88c/df4/SHA256E-s4644--eca6d831c0a94895a81296327bc21bdf417234c7ebfa3e93fd21a71523ac9da9.log.6.log'
+fatal: git-write-tree: error building trees
+TransferScanner crashed: failed to read sha from git write-tree
+[2015-06-06 15:58:45 CEST] TransferScanner: warning TransferScanner crashed: failed to read sha from git write-tree
+[2015-06-06 15:58:46 CEST] Committer: Committing changes to git
+[2015-06-06 15:58:46 CEST] Pusher: Syncing with origin 
+error: invalid object 100644 b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8 for '88c/df4/SHA256E-s4644--eca6d831c0a94895a81296327bc21bdf417234c7ebfa3e93fd21a71523ac9da9.log.6.log'
+fatal: git-write-tree: error building trees
+Pusher crashed: failed to read sha from git write-tree
+[2015-06-06 15:58:46 CEST] Pusher: warning Pusher crashed: failed to read sha from git write-tree
+[2015-06-06 16:58:44 CEST] NetWatcherFallback: Syncing with origin 
+error: invalid object 100644 b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8 for '88c/df4/SHA256E-s4644--eca6d831c0a94895a81296327bc21bdf417234c7ebfa3e93fd21a71523ac9da9.log.6.log'
+fatal: git-write-tree: error building trees
+NetWatcherFallback crashed: failed to read sha from git write-tree
+[2015-06-06 16:58:47 CEST] NetWatcherFallback: warning NetWatcherFallback crashed: failed to read sha from git write-tree
+[2015-06-06 18:10:24 CEST] Committer: Committing changes to git
+[2015-06-06 18:10:25 CEST] Committer: Committing changes to git
+[2015-06-06 20:01:34 CEST] Committer: Committing changes to git
+[2015-06-06 20:01:35 CEST] Committer: Committing changes to git
+[2015-06-06 22:42:41 CEST] main: starting assistant version 5.20150508-g883d57f
+[2015-06-06 22:42:41 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2015-06-06 22:42:47 CEST] TransferScanner: Syncing with origin 
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2015-06-06 22:42:47 CEST] Watcher: Performing startup scan
+(started...) error: invalid object 100644 b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8 for '88c/df4/SHA256E-s4644--eca6d831c0a94895a81296327bc21bdf417234c7ebfa3e93fd21a71523ac9da9.log.6.log'
+fatal: git-write-tree: error building trees
+TransferScanner crashed: failed to read sha from git write-tree
+[2015-06-06 22:42:48 CEST] TransferScanner: warning TransferScanner crashed: failed to read sha from git write-tree
+gpg: assuming signed data in '/tmp/git-annex.tmp.0/info'
+gpg: Signature made Thu May 28 19:01:58 2015 CEST using DSA key ID 89C809CB
+gpg: /tmp/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-06-06 22:42:48 CEST] Upgrader: An upgrade of git-annex is available.  (version 5.20150528)
+[2015-06-06 22:42:49 CEST] Committer: Committing changes to git
+[2015-06-06 22:42:49 CEST] Pusher: Syncing with origin 
+error: invalid object 100644 b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8 for '88c/df4/SHA256E-s4644--eca6d831c0a94895a81296327bc21bdf417234c7ebfa3e93fd21a71523ac9da9.log.6.log'
+fatal: git-write-tree: error building trees
+Pusher crashed: failed to read sha from git write-tree
+[2015-06-06 22:42:49 CEST] Pusher: warning Pusher crashed: failed to read sha from git write-tree
+
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+
+  bugs/nouveau-bug/nouveau.log.9 still has writers, not adding
+[2015-06-06 22:43:47 CEST] Committer: Adding nouveau.log.9
+add bugs/nouveau-bug/nouveau.log.9 [2015-06-06 22:43:48 CEST] Committer: Committing changes to git
+
+SHA256E-s4427--4e02ba661d0106ff4715a2cfda0fe39185865551bcb484539e618f2b64f9ec0c.log.9
+
+          4,427 100%    0.00kB/s    0:00:00  
+          4,427 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-06 22:43:48 CEST] Transferrer: Uploaded nouveau.log.9
+[2015-06-06 22:43:49 CEST] Committer: Committing changes to git
+ok
+(recording state in git...)
+
+  lost dbus connection; falling back to polling (ClientError {clientErrorMessage = "Error reading message from socket: UnmarshalError \"Unexpected end of input while parsing message header.\"", clientErrorFatal = True})
+[2015-06-07 07:41:35 CEST] main: starting assistant version 5.20150508-g883d57f
+[2015-06-07 07:41:35 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2015-06-07 07:41:42 CEST] TransferScanner: Syncing with origin 
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2015-06-07 07:41:42 CEST] Watcher: Performing startup scan
+(started...) error: invalid object 100644 b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8 for '88c/df4/SHA256E-s4644--eca6d831c0a94895a81296327bc21bdf417234c7ebfa3e93fd21a71523ac9da9.log.6.log'
+fatal: git-write-tree: error building trees
+TransferScanner crashed: failed to read sha from git write-tree
+[2015-06-07 07:41:43 CEST] TransferScanner: warning TransferScanner crashed: failed to read sha from git write-tree
+gpg: assuming signed data in '/tmp/git-annex.tmp.0/info'
+gpg: Signature made Thu May 28 19:01:58 2015 CEST using DSA key ID 89C809CB
+gpg: /tmp/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-06-07 07:41:43 CEST] Upgrader: An upgrade of git-annex is available.  (version 5.20150528)
+[2015-06-07 07:41:44 CEST] Committer: Committing changes to git
+[2015-06-07 07:41:44 CEST] Pusher: Syncing with origin 
+error: invalid object 100644 b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8 for '88c/df4/SHA256E-s4644--eca6d831c0a94895a81296327bc21bdf417234c7ebfa3e93fd21a71523ac9da9.log.6.log'
+fatal: git-write-tree: error building trees
+Pusher crashed: failed to read sha from git write-tree
+[2015-06-07 07:41:44 CEST] Pusher: warning Pusher crashed: failed to read sha from git write-tree
+[2015-06-07 08:41:42 CEST] NetWatcherFallback: Syncing with origin 
+error: invalid object 100644 b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8 for '88c/df4/SHA256E-s4644--eca6d831c0a94895a81296327bc21bdf417234c7ebfa3e93fd21a71523ac9da9.log.6.log'
+fatal: git-write-tree: error building trees
+NetWatcherFallback crashed: failed to read sha from git write-tree
+[2015-06-07 08:41:43 CEST] NetWatcherFallback: warning NetWatcherFallback crashed: failed to read sha from git write-tree
+[2015-06-07 09:21:46 CEST] main: starting assistant version 5.20150508-g883d57f
+[2015-06-07 09:21:46 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2015-06-07 09:21:49 CEST] main: starting assistant version 5.20150508-g883d57f
+[2015-06-07 09:21:49 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2015-06-07 09:21:54 CEST] TransferScanner: Syncing with origin 
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2015-06-07 09:21:55 CEST] Watcher: Performing startup scan
+(started...) 
+(recording state in git...)
+error: invalid object 100644 b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8 for '88c/df4/SHA256E-s4644--eca6d831c0a94895a81296327bc21bdf417234c7ebfa3e93fd21a71523ac9da9.log.6.log'
+fatal: git-write-tree: error building trees
+TransferScanner crashed: failed to read sha from git write-tree
+[2015-06-07 09:21:55 CEST] TransferScanner: warning TransferScanner crashed: failed to read sha from git write-tree
+gpg: assuming signed data in '/tmp/git-annex.tmp.0/info'
+gpg: Signature made Thu May 28 19:01:58 2015 CEST using DSA key ID 89C809CB
+gpg: /tmp/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-06-07 09:21:56 CEST] Upgrader: An upgrade of git-annex is available.  (version 5.20150528)
+[2015-06-07 09:21:56 CEST] Committer: Committing changes to git
+(recording state in git...)
+[2015-06-07 09:21:56 CEST] Pusher: Syncing with origin 
+(recording state in git...)
+error: invalid object 100644 b5f693aa67b6d185e6d967e0a45c3c57a4f4b4a8 for '88c/df4/SHA256E-s4644--eca6d831c0a94895a81296327bc21bdf417234c7ebfa3e93fd21a71523ac9da9.log.6.log'
+fatal: git-write-tree: error building trees
+Pusher crashed: failed to read sha from git write-tree
+[2015-06-07 09:21:57 CEST] Pusher: warning Pusher crashed: failed to read sha from git write-tree
+[2015-06-07 09:23:07 CEST] main: starting assistant version 5.20150508-g883d57f
+[2015-06-07 09:23:07 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2015-06-07 09:23:12 CEST] TransferScanner: Syncing with origin 
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2015-06-07 09:23:12 CEST] Watcher: Performing startup scan
+(started...) 
+(recording state in git...)
+gpg: assuming signed data in '/tmp/git-annex.tmp.0/info'
+gpg: Signature made Thu May 28 19:01:58 2015 CEST using DSA key ID 89C809CB
+gpg: /tmp/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-06-07 09:23:13 CEST] Upgrader: An upgrade of git-annex is available.  (version 5.20150528)
+[2015-06-07 09:23:14 CEST] Committer: Committing changes to git
+(recording state in git...)
+[2015-06-07 09:23:14 CEST] Pusher: Syncing with origin 
+
+SHA256E-s4491--e35540a06d6839455b48ecd8f2a4c7714d420379bae55a7b383dc1a5dc60d8e0.log.8
+
+          4,491 100%    0.00kB/s    0:00:00  
+          4,491 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-07 09:23:15 CEST] Transferrer: Uploaded nouveau.log.8
+error: Unable to create '/srv/git/seb/annex/annex.git/refs/heads/synced/git-annex.lock': File exists.
+
+If no other git process is currently running, this probably means a
+git process crashed in this repository earlier. Make sure no other git
+process is running and remove the file manually to continue.
+remote: error: Cannot lock the ref 'refs/heads/synced/git-annex'.        
+error: Unable to create '/srv/git/seb/annex/annex.git/refs/heads/synced/master.lock': File exists.
+
+If no other git process is currently running, this probably means a
+git process crashed in this repository earlier. Make sure no other git
+process is running and remove the file manually to continue.
+remote: error: Cannot lock the ref 'refs/heads/synced/master'.        
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   aec4d80..5cac670  master -> synced/master
+ ! [remote rejected] git-annex -> synced/git-annex (failed to update ref)
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   973fbda..118a888  git-annex -> synced/git-annex
+ ! [remote rejected] master -> synced/master (failed to update ref)
+error: failed to push some refs to 'ssh://redacted.net/srv/git/seb/annex/annex.git'
+error: failed to push some refs to 'ssh://redacted.net/srv/git/seb/annex/annex.git'
+error: Ref refs/remotes/origin/master is at 5cac670bc3d15a2d1a976ab02b2717078717ad48 but expected aec4d80548993b2b6e126124153fab9c93de8375
+error: Cannot lock the ref 'refs/remotes/origin/master'.
+From ssh://redacted.net/srv/git/seb/annex/annex
+ ! aec4d80..5cac670  master     -> origin/master  (unable to update local ref)
+error: Ref refs/remotes/origin/git-annex is at 118a888e0244e644c2ec6c0bf100e787d25a222d but expected 973fbdad6d8b549c4db0633ef11fa5a8f9ec0ed1
+error: Cannot lock the ref 'refs/remotes/origin/git-annex'.
+ ! 973fbda..118a888  git-annex  -> origin/git-annex  (unable to update local ref)
+Everything up-to-date
+Everything up-to-date
+(recording state in git...)
+[2015-06-07 09:23:20 CEST] main: starting assistant version 5.20150508-g883d57f
+[2015-06-07 09:23:20 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2015-06-07 09:23:25 CEST] TransferScanner: Syncing with origin 
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2015-06-07 09:23:25 CEST] Watcher: Performing startup scan
+(started...) 
+From ssh://redacted.net/srv/git/seb/annex/annex
+   118a888..e058e35  git-annex  -> origin/git-annex
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+gpg: assuming signed data in '/tmp/git-annex.tmp.0/info'
+gpg: Signature made Thu May 28 19:01:58 2015 CEST using DSA key ID 89C809CB
+gpg: /tmp/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-06-07 09:23:26 CEST] Upgrader: An upgrade of git-annex is available.  (version 5.20150528)
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   118a888..37bc288  git-annex -> synced/git-annex
+[2015-06-07 09:23:27 CEST] Committer: Committing changes to git
+(recording state in git...)
+[2015-06-07 09:23:27 CEST] Pusher: Syncing with origin 
+Everything up-to-date
+[2015-06-07 09:25:21 CEST] Committer: Adding daemon.log.4
+add bugs/git-annex/daemon.log.4 ok
+[2015-06-07 09:25:21 CEST] Committer: Committing changes to git
+(recording state in git...)
+[2015-06-07 09:25:21 CEST] Pusher: Syncing with origin 
+(recording state in git...)
+
+SHA256E-s2383--66aa385819f9ba961c3b4701dd68b6d1450af08ae24428461d342be8b12784a2.log.4
+
+          2,383 100%    0.00kB/s    0:00:00  
+          2,383 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-07 09:25:21 CEST] Transferrer: Uploaded daemon.log.4
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   37bc288..5c63092  git-annex -> synced/git-annex
+   5cac670..3a5e7d0  master -> synced/master
+[2015-06-07 09:25:22 CEST] Committer: Committing changes to git
+[2015-06-07 09:25:24 CEST] Pusher: Syncing with origin 
+(recording state in git...)
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   5c63092..07a3e47  git-annex -> synced/git-annex
+[2015-06-07 09:25:40 CEST] Committer: Adding index~
+add bugs/git-annex/index~ ok
+[2015-06-07 09:25:40 CEST] Committer: Committing changes to git
+(recording state in git...)
+[2015-06-07 09:25:40 CEST] Pusher: Syncing with origin 
+(recording state in git...)
+
+SHA256E-s178074--cf093bacc4367a5e86a07cb8523b183dd0a5401805dde646cf0b2b0ddc8ee282
+
+         32,768  18%    0.00kB/s    0:00:00  
+        178,074 100%   69.29MB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-07 09:25:41 CEST] Committer: Committing changes to git
+[2015-06-07 09:25:41 CEST] Transferrer: Uploaded index~
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   07a3e47..32d41fc  git-annex -> synced/git-annex
+   3a5e7d0..20e6e3c  master -> synced/master
+[2015-06-07 09:25:44 CEST] Pusher: Syncing with origin 
+(recording state in git...)
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   32d41fc..b61b73e  git-annex -> synced/git-annex
+[2015-06-07 09:44:47 CEST] Committer: Adding daemon.log daemon.log.1 daemon.log.10 daemon.log.2 daemon.log.3
+add bugs/git-annex/daemon.log ok
+add bugs/git-annex/daemon.log.1 ok
+add bugs/git-annex/daemon.log.10 ok
+add bugs/git-annex/daemon.log.2 ok
+add bugs/git-annex/daemon.log.3 ok
+[2015-06-07 09:44:47 CEST] Committer: Committing changes to git
+(recording state in git...)
+[2015-06-07 09:44:47 CEST] Pusher: Syncing with origin 
+(recording state in git...)
+
+SHA256E-s3284--5784c99b359a5fdfb52f26e82165ffba54d62f9f5cd846fce25a3c6f694eb890.log
+
+          3,284 100%    0.00kB/s    0:00:00  
+          3,284 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-07 09:44:47 CEST] Transferrer: Uploaded daemon.log
+
+SHA256E-s178--704e1850cab9a6b074ba2a77344199b866e9408541b83bf1ad6b3bbd23dfc54a.log.3
+
+            178 100%    0.00kB/s    0:00:00  
+            178 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-07 09:44:48 CEST] Transferrer: Uploaded daemon.log.3
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   b61b73e..854cbda  git-annex -> synced/git-annex
+   20e6e3c..0d8b74a  master -> synced/master
+
+SHA256E-s1993--7f1bec5289ebe07306bf57fb91e0dec25b1d8f5cf1efd15297815503f1290477.log.2
+
+          1,993 100%    0.00kB/s    0:00:00  
+          1,993 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-07 09:44:48 CEST] Committer: Committing changes to git
+(recording state in git...)
+[2015-06-07 09:44:48 CEST] Transferrer: Uploaded daemon.log.2
+
+SHA256E-s4969--ff59d2458e0b43a1965258bd0064626de1a0b7f911de693a02f34fc1bcb4959a.log.10
+
+          4,969 100%    0.00kB/s    0:00:00  
+          4,969 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-07 09:44:48 CEST] Transferrer: Uploaded daemon.log.10
+
+SHA256E-s3385--0e7aef46d502f1d3a583b642239cf1272b2410d5976603b65a104fc866c02e70.log.1
+
+          3,385 100%    0.00kB/s    0:00:00  
+          3,385 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-07 09:44:49 CEST] Transferrer: Uploaded daemon.log.1
+[2015-06-07 09:44:50 CEST] Committer: Adding daemon.log.5 daemon.log.6 daemon.log.7 daemon.log.8 daemon.log.9
+add bugs/git-annex/daemon.log.5 ok
+add bugs/git-annex/daemon.log.6 ok
+add bugs/git-annex/daemon.log.7 ok
+add bugs/git-annex/daemon.log.8 ok
+add bugs/git-annex/daemon.log.9 ok
+[2015-06-07 09:44:50 CEST] Committer: Committing changes to git
+(recording state in git...)
+
+SHA256E-s2792--313d72ecb598b18884602babaed667b71786a0f50edd291754bac0b70c666fa9.log.5
+
+          2,792 100%    0.00kB/s    0:00:00  
+          2,792 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-07 09:44:50 CEST] Transferrer: Uploaded daemon.log.5
+
+SHA256E-s6792--8aaddbb316719160b93305bc7a6698df1b2d6b0e6f3366c0fa9f7d258cf12303.log.9
+
+          6,792 100%    0.00kB/s    0:00:00  
+          6,792 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-07 09:44:50 CEST] Transferrer: Uploaded daemon.log.9
+[2015-06-07 09:44:50 CEST] Pusher: Syncing with origin 
+
+SHA256E-s1183--12703bbab3cd4db78fc4449b5c3dddfb82da77c9b4a750d2b7a902f3eb63547b.log.8
+
+          1,183 100%    0.00kB/s    0:00:00  
+          1,183 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+(recording state in git...)
+[2015-06-07 09:44:51 CEST] Transferrer: Uploaded daemon.log.8
+[2015-06-07 09:44:51 CEST] Committer: Committing changes to git
+(recording state in git...)
+
+SHA256E-s5310--51d80ffdcfdeff4e035f740de0f18afa660404fb448a72421bd7af85ae87ae6f.log.7
+
+          5,310 100%    0.00kB/s    0:00:00  
+          5,310 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-07 09:44:51 CEST] Transferrer: Uploaded daemon.log.7
+
+SHA256E-s2639--c7a0e874ae2dbc874732c000928a5c2a1a6c3d75dcb89b590fcb9e13415427cd.log.6
+
+          2,639 100%    0.00kB/s    0:00:00  
+          2,639 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-06-07 09:44:51 CEST] Transferrer: Uploaded daemon.log.6
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   854cbda..c940c96  git-annex -> synced/git-annex
+   0d8b74a..3865343  master -> synced/master
+[2015-06-07 09:44:54 CEST] Pusher: Syncing with origin 
+(recording state in git...)
+To ssh://redacted.net/srv/git/seb/annex/annex.git
+   c940c96..95a399f  git-annex -> synced/git-annex
+   3865343..c04efc3  master -> synced/master
+
+"""]]
diff --git a/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_1_f2102da5822a35e1600d67326954e059._comment b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_1_f2102da5822a35e1600d67326954e059._comment
new file mode 100644
index 0000000000..37a50c662f
--- /dev/null
+++ b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_1_f2102da5822a35e1600d67326954e059._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="eigengrau"
+ subject="comment 1"
+ date="2015-06-07T08:40:05Z"
+ content="""
+Hm, I wondered why there’s the “rrsync” stuff in the logs, because git-annex doesn’t use rrsync, right? I noticed I still had an old SSH key with a forced-command for rrsync in my authorized_keys on the remote. Could this have played into the problem, or would that have been dealt with gracefully?
+"""]]
diff --git a/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_2_656986cdc4831a8d2f80432acaf8a884._comment b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_2_656986cdc4831a8d2f80432acaf8a884._comment
new file mode 100644
index 0000000000..4346bebee9
--- /dev/null
+++ b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_2_656986cdc4831a8d2f80432acaf8a884._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-06-09T19:34:57Z"
+ content="""
+So, thanks for providing me the index file, but the relevant problem
+seems to be that your index file refers to a git object that failed to make
+it to disk.
+
+The most likely cause of this would be a crash before disk buffers got
+flushed, or something like that.
+
+It's perfectly fine to remove your .git/annex/index if this happens. You
+must have lost some information that was being committed to the git-annex
+branch, so you might want to run `git annex fsck` to make sure everything 
+gets updated.
+
+I'd expect `git-annex repair` to detect this problem (and fix it the same
+way you did).
+
+It's possible that the assistant's code for detecting when there are
+problems doesn't work well enough for it to have
+automatically detected and fixed this problem. Which is why I'm leaving
+this bug open for now.
+"""]]
diff --git a/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_3_fa94d1b008a6c1663e40854edcd5504d._comment b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_3_fa94d1b008a6c1663e40854edcd5504d._comment
new file mode 100644
index 0000000000..6fbc820f8d
--- /dev/null
+++ b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_3_fa94d1b008a6c1663e40854edcd5504d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="eigengrau"
+ subject="comment 3"
+ date="2015-06-11T15:12:23Z"
+ content="""
+Thanks! FWIW I didn’t have any hard kernel lockups recently. I figure git replaces the index file atomically, and only after all objects have been written to the store? I guess a userland crash couldn’t be the cause either, in that case?
+
+What happens when you manually run git gc at an inopportune moment, seeing that it probably doesn’t know about the secondary index? In the logs, I saw mention of locks on individual refs. Is the whole repository also locked down when git-annex commits something, or could it happen that a manual git gc prunes away objects added by git-annex before it had a chance to write the tree and commit it to a ref?
+"""]]
diff --git a/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_4_5a26a33c34594ec6eb50bd675d68801a._comment b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_4_5a26a33c34594ec6eb50bd675d68801a._comment
new file mode 100644
index 0000000000..4b41d988d5
--- /dev/null
+++ b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_4_5a26a33c34594ec6eb50bd675d68801a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-06-15T18:05:38Z"
+ content="""
+git does update the index file atomically (via `rename(2)`) but
+that doesn't necessarily mean that the filesystem writes all
+the data to disk before there is a problem.
+
+That's a good point about `git gc` and the index; it does look
+at the regular git index. But, `git gc` seems unlikely to cause any problem,
+even if .git/annex/index  pointed to a newer object that the git-annex branch
+hadn't yet been updated to refer to; since `git gc` defaults to only
+pruning objects that are 2 weeks old. The time that an object would
+normally be in .git/annex/index without getting flushed in a commit
+is normally measured in seconds to minutes.
+"""]]
diff --git a/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_5_81e2f37e7adbd8f24734b67a1dd209f9._comment b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_5_81e2f37e7adbd8f24734b67a1dd209f9._comment
new file mode 100644
index 0000000000..71d7a7338a
--- /dev/null
+++ b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_5_81e2f37e7adbd8f24734b67a1dd209f9._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="eigengrau"
+ subject="comment 5"
+ date="2015-06-16T13:20:07Z"
+ content="""
+You’re right, but the problem might be my somehow developing a perhaps overzealous habit of using the occasional `--aggressive --prune=now`. From what you said I would surmise that this could be a fairly good explanation for the missing object in my case.
+"""]]
diff --git a/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_6_f0999dbd00e06ab2cbf68b58527c2b9b._comment b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_6_f0999dbd00e06ab2cbf68b58527c2b9b._comment
new file mode 100644
index 0000000000..f11e80bbec
--- /dev/null
+++ b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_6_f0999dbd00e06ab2cbf68b58527c2b9b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2015-07-02T19:14:40Z"
+ content="""
+Yeah, --prune=now is bad news when using git-annex. At least, if
+you might be doing it at the same time that git-annex is staging
+objects in the index.
+
+Using it in combination with annex.alwayscommit=false is a particularly
+foot-shootish thing. I've added a warning to its documentation.
+
+`git gc` uses a lock file, `.git/gc.pid`. It might be possible for
+git-annex to hold that lock when it's in the process of staging and
+committing objects, to avoid `git gc` running at such times.
+"""]]
diff --git a/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too.mdwn b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too.mdwn
new file mode 100644
index 0000000000..595b86c296
--- /dev/null
+++ b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+On my raspberry pi, an SSH remote was in /var/lib/store (symlinked with /home/carlo/store), which contained a LVM volume spanning several USB drives. One of the drives got corrupted, which lead to this:
+
+$ cd /home/carlo/store
+$ ls
+Input/Output Error
+
+On my desktop machine, I then had a lot of transfers. After transfer, the file was turned into a symlink.
+
+### What steps will reproduce the problem?
+
+* Create an annex and a remote ssh server.
+* [Simulate a corrupted drive](http://stackoverflow.com/questions/1361518/how-can-i-simulate-a-failed-disk-during-testing) for the remote, creating an input output error.
+* Wait until the annex starts syncing on the desktop machine. If there were no further unidentified causes on my side, the assistant will start transfers that revert files to symlinks.
+
+### What version of git-annex are you using? On what operating system?
+
+Ubuntu 12.04 64bit
+git annex 3.20121017 ([from Ubuntu PPA](https://launchpad.net/~rubiojr/+archive/git-annex))
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+Please see [all my daemon.log](http://capocasa.name/daemon.tgz) files.
+
+I noticed the problem yesterday afternoon (Thu 24 Oct).
+
+# End of transcript or log.
+"""]]
+
+> [[!taglink moreinfo]]; either I don't have enough information to work on this,
+> or it might have just been user error. --[[Joey]]
diff --git a/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_1_80ca50f5305eda71fe32f2b0bc922c34._comment b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_1_80ca50f5305eda71fe32f2b0bc922c34._comment
new file mode 100644
index 0000000000..e47cbd327f
--- /dev/null
+++ b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_1_80ca50f5305eda71fe32f2b0bc922c34._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-10-26T19:22:57Z"
+ content="""
+It seems to me that if a subdirectory of the repository is on a corrupted drive, and so it's not possible to list the files on it, this is basically the same as if you'd 'rm -rf' that subdirectory. So when it starts up, the assistant will see that these files are not present, and commit a removal to git.
+
+Then when another machine syncs with that, it would delete the files from its repository too. However, it actually keeps the contents of the files stashed away in `.git/annex`. So to recover from this, all you have to do is `git annex indirect` and `git revert` the commit that deleted the files. All your files would then be available again.
+
+However, what you describe is instead that the assistant chose to drop the content associated with the files, but kept the symlinks for them checked into git.
+I don't understand why it would do that. Can you show the output of running, on the desktop machine:
+
+    git annex whereis $somefile
+    git annex get $somefile
+
+Where $somefile is one of the files that has been reduced to a symlink.
+
+Looking at your logs, they appear to be the logs from the server. The strange thing that appears in one of them is \"git-annex: Not in a git repository.\"
+which was logged around 2013-10-24 20:07:25 CEST. I am not sure, but I think it might have been the rpi git-annex saying that, because there is also \"fatal: '~/store/annex/' does not appear to be a git repository\"
+"""]]
diff --git a/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_2_e6bc6d1c0eb8c469e9e00b37bbcc9b86._comment b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_2_e6bc6d1c0eb8c469e9e00b37bbcc9b86._comment
new file mode 100644
index 0000000000..18959ed682
--- /dev/null
+++ b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_2_e6bc6d1c0eb8c469e9e00b37bbcc9b86._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="comment 2"
+ date="2013-10-27T19:26:42Z"
+ content="""
+Thanks for looking into it and the recover instructions, will recover and post back when I'm back at work. I also have an another indirect mode repo on my home desktop as an extra backup so nothing real bad happened, but it's reassuring data's still there at work.
+
+"""]]
diff --git a/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_5_0d0f6b6b46d0153433fead2bbd1bbe64._comment b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_5_0d0f6b6b46d0153433fead2bbd1bbe64._comment
new file mode 100644
index 0000000000..a254b31a82
--- /dev/null
+++ b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_5_0d0f6b6b46d0153433fead2bbd1bbe64._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="comment 5"
+ date="2013-10-30T15:05:37Z"
+ content="""
+The assistant autorecovered my work repo before I noticed, so it looks like I can't provide the necessary info. There were a bunch of files missing that got re-synced from my home PC.
+
+For what it's worth, I noticed that on my phone, when cutting the internet connection while syncing, the assistant downloaded existing files into placeholder files, and then continued actually downloading files when the network connection was restored.
+
+
+"""]]
diff --git a/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_5_6058a22b733cb02126286af950074ed4._comment b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_5_6058a22b733cb02126286af950074ed4._comment
new file mode 100644
index 0000000000..33e85c7724
--- /dev/null
+++ b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_5_6058a22b733cb02126286af950074ed4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 5"
+ date="2013-11-03T01:17:39Z"
+ content="""
+I don't understand what you mean by \"The assistant autorecovered my work repo before I noticed\". What repo is the work repo, and how could the assistant \"autorecover\" it, and what did it do?
+
+At this point, I am completely in the dark about whether you're reporting a problem, and what the problem is. 
+"""]]
diff --git a/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_6_593a49669e2fadfb91773f8c84fbb031._comment b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_6_593a49669e2fadfb91773f8c84fbb031._comment
new file mode 100644
index 0000000000..af31edcf87
--- /dev/null
+++ b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_6_593a49669e2fadfb91773f8c84fbb031._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="comment 6"
+ date="2013-10-31T10:03:01Z"
+ content="""
+Of course, the autorecovery wouldn't affect the daemon.log from the work machine... so here they are: http://capocasa.name/work-desktop-ubuntu-12.04-daemonlog.tgz
+"""]]
diff --git a/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_6_5a348c5f327f16e1192ef6bd7f2880bb._comment b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_6_5a348c5f327f16e1192ef6bd7f2880bb._comment
new file mode 100644
index 0000000000..7e611cebd4
--- /dev/null
+++ b/doc/bugs/Corrupted_drive__58___Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too/comment_6_5a348c5f327f16e1192ef6bd7f2880bb._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="comment 6"
+ date="2013-11-19T09:48:26Z"
+ content="""
+Sorry, missed the comment.
+
+My work repo is the repository on my work laptop, where deletions got synced to.
+
+Git annex had then run repository repair automatically, so the odd symlinks where no longer there for me to check out.
+
+It is possible that I ran some git commands in direct mode I shouldn't have; I put the files back in and it's working nicely now. So this might have been a \"no direct mode guard\" issue.
+
+"""]]
diff --git a/doc/bugs/Corrupted_git___40__but_not_annex__41___controlled_files.mdwn b/doc/bugs/Corrupted_git___40__but_not_annex__41___controlled_files.mdwn
new file mode 100644
index 0000000000..8f19956979
--- /dev/null
+++ b/doc/bugs/Corrupted_git___40__but_not_annex__41___controlled_files.mdwn
@@ -0,0 +1,102 @@
+### Please describe the problem.
+
+I have files that match annex.largefiles and therefore should be added to git but not to annex, they seem to be getting corrupted after cloning the repo.
+
+### What steps will reproduce the problem?
+
+I couldn't immediately find the exact steps to reproduce the issue but I have multiple git repositories showing this.
+
+### What version of git-annex are you using? On what operating system?
+
+The problem has occurred a while ago but I have just noticed it. This is on macOS if it helps. I also tend to use the latest released version of git-annex (installed via Homebrew)
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+$ cd Documents
+$ cat .gitattributes
+* annex.largefiles=((not(mimetype=text/*))or(largerthan=100kb))
+
+*.png binary
+*.jpg binary
+*.jpeg binary
+*.gif binary
+*.ico binary
+
+*.mp3 binary
+*.fla binary
+
+*.mov binary
+*.mp4 binary
+*.flv binary
+*.swf binary
+*.avi binary
+*.mkv binary
+*.mpg binary
+*.mpeg binary
+
+*.gz binary
+*.zip binary
+*.7z binary
+*.rar binary
+*.bz2 binary
+
+*.ttf binary
+
+*.pdf binary
+
+$ ls -la Docs/2016-XXX/XXX/
+total 696
+drwx------@ 4 denis  staff     136 Jul 11 15:05 ./
+drwxr-xr-x@ 9 denis  staff     306 Dec 12 19:42 ../
+-rwxr-xr-x@ 1 denis  staff  265898 Jul 11 13:03 XXX.pdf*
+-rwxr-xr-x@ 1 denis  staff   89586 Jul 11 13:03 Summary.pdf*
+$ file --mime-type Docs/2016-XXX/XXX/XXX.pdf
+Docs/2016-XXX/XXX/XXX.pdf: application/pdf
+$ git show 60a76858a57a73967131b929af45a99703f67335
+commit 60a76858a57a73967131b929af45a99703f67335
+Author: Denis Dzyubenko <denis@ddenis.info>
+Date:   Mon Jul 11 15:05:37 2016 +0200
+
+    XXX
+
+diff --git a/Docs/2016-XXX/XXX/XXX.pdf b/Docs/2016-XXX/XXX/XXX.pdf
+new file mode 100755
+index 00000000..112f68d0
+Binary files /dev/null and b/Docs/2016-XXX/XXX/XXX.pdf differ
+diff --git a/Docs/2016-XXX/XXX/Summary.pdf b/Docs/2016-XXX/XXX/Summary.pdf
+new file mode 100755
+index 00000000..3828383e
+Binary files /dev/null and b/Docs/2016-XXX/XXX/Summary.pdf differ
+diff --git a/Docs/2016-XXX/XXX.pdf b/Docs/2016-XXX/XXX.pdf
+deleted file mode 120000
+index 6d347a22..00000000
+--- a/Docs/2016-XXX/XXX.pdf
++++ /dev/null
+@@ -1 +0,0 @@
+-../../.git/annex/objects/zJ/X1/SHA256E-s190749--ee0c8329c88f9c1656cc75cf37d4df64060a022e73d199164c5e5222ba1739d1.pdf/SHA256E-s190749--ee0c8329c88f9c1656cc
+\ No newline at end of file
+
+
+
+$ git clone Documents Documents.tmp
+Cloning into 'Documents.tmp'...
+done.
+$ cd ./Documents.tmp/
+$ ls -la Docs/2016-XXX/XXX/
+total 184
+drwxr-xr-x  4 denis  staff    136 Dec 19 00:09 ./
+drwxr-xr-x  8 denis  staff    272 Dec 19 00:09 ../
+-rwxr-xr-x  1 denis  staff    101 Dec 19 00:09 XXX.pdf*
+-rwxr-xr-x  1 denis  staff  89586 Dec 19 00:09 Summary.pdf*
+$ cat Docs/2016-XXX/XXX/XXX.pdf
+/annex/objects/SHA256E-s265898--9c750c01dce9689ac3880224d2e95da6287b0cc89759c0c882e7a9a0fe48d664.pdf
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
diff --git a/doc/bugs/Corrupted_git___40__but_not_annex__41___controlled_files/comment_1_48f15b40bf3a7cd3beb7cabd4e706337._comment b/doc/bugs/Corrupted_git___40__but_not_annex__41___controlled_files/comment_1_48f15b40bf3a7cd3beb7cabd4e706337._comment
new file mode 100644
index 0000000000..9d95e475ff
--- /dev/null
+++ b/doc/bugs/Corrupted_git___40__but_not_annex__41___controlled_files/comment_1_48f15b40bf3a7cd3beb7cabd4e706337._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-01-29T18:57:41Z"
+ content="""
+> I have files that match annex.largefiles and therefore should be added to git but not to annex
+
+That's backwards, if they match, they will be added to the annex.
+
+It's not at all clear to me what the bug is supposed to be in what you
+showed, or how I'd reproduce whatever the problem was.
+
+I realize you filed this 4 years ago, and it slipped through the cracks
+until now, but please followup if possible.
+"""]]
diff --git a/doc/bugs/Could_not_read_from_remote_repository.mdwn b/doc/bugs/Could_not_read_from_remote_repository.mdwn
new file mode 100644
index 0000000000..46391e6603
--- /dev/null
+++ b/doc/bugs/Could_not_read_from_remote_repository.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+
+I've been using git-annex for a few weeks now, and everything was working fine until today. Now, when git-annex goes to sync my files, it will hang for a while, and then display a red box on the left side, saying `! Synced with adam.liter`. So, basically, it doesn't really sync. The logs say that it cannot read from the remote repository, which is set up on box.com and was working just fine until today.
+
+I've tried reconfiguring my jabber account on all my devices with git-annex as well as deleting and remaking the box.com repository, and none of these steps have solved the problem.
+
+### What steps will reproduce the problem?
+
+Making changes to any file located in the repository.
+
+### What version of git-annex are you using? On what operating system?
+
+Mac OS X 10.8.4 and git-annex version 4.20130801-gc88bbc4.
+
+### Please provide any additional information below.
+
+[[!format sh """
+[2013-09-09 01:33:03 EDT] XMPPSendPack: Syncing with adam.liter 
+Already up-to-date.
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+"""]]
+
+[[!meta title="xmpp syncing sometimes fails"]]
+
+[[!tag confirmed]]
diff --git a/doc/bugs/Could_not_read_from_remote_repository/comment_1_da842a9d146bcd5c7773b58364c25597._comment b/doc/bugs/Could_not_read_from_remote_repository/comment_1_da842a9d146bcd5c7773b58364c25597._comment
new file mode 100644
index 0000000000..c236beacdd
--- /dev/null
+++ b/doc/bugs/Could_not_read_from_remote_repository/comment_1_da842a9d146bcd5c7773b58364c25597._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.255.110"
+ subject="comment 1"
+ date="2013-09-09T06:01:18Z"
+ content="""
+From the small bit of log posted, it seems to be failing to sync over XMPP. Perhaps the XMPP server is down or it cannot connect? You can turn on debugging to get a lot more debugging about XMPP sync attempts.
+"""]]
diff --git a/doc/bugs/Could_not_read_from_remote_repository/comment_2_82746a0cf989d884cd0fd796db092b3c._comment b/doc/bugs/Could_not_read_from_remote_repository/comment_2_82746a0cf989d884cd0fd796db092b3c._comment
new file mode 100644
index 0000000000..8312bb3a38
--- /dev/null
+++ b/doc/bugs/Could_not_read_from_remote_repository/comment_2_82746a0cf989d884cd0fd796db092b3c._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkgH7oNEqNbh3g-N1-UHXuqleXaRYDgj1U"
+ nickname="Adam"
+ subject="comment 2"
+ date="2013-09-09T06:12:44Z"
+ content="""
+This is what is in the logs after I turned on debugging:
+
+    [2013-09-09 02:04:22 EDT] XMPPSendPack: finished running push Pushing \"a29\" (PushRequest (UUID \"c96c8493-b702-4ca0-9a88-f8a38dd6c3f5\")) True
+    [2013-09-09 02:04:22 EDT] XMPPSendPack: started running push Pushing \"a29\" (PushRequest (UUID \"c96c8493-b702-4ca0-9a88-f8a38dd6c3f5\"))
+    [2013-09-09 02:04:22 EDT] read: git [\"--git-dir=/Users/adamliter/Library/texmf/.git\",\"--work-tree=/Users/adamliter/Library/texmf\",\"symbolic-ref\",\"HEAD\"]
+    [2013-09-09 02:04:22 EDT] read: git [\"--git-dir=/Users/adamliter/Library/texmf/.git\",\"--work-tree=/Users/adamliter/Library/texmf\",\"show-ref\",\"refs/heads/master\"]
+    [2013-09-09 02:04:22 EDT] call: git [\"--git-dir=/Users/adamliter/Library/texmf/.git\",\"--work-tree=/Users/adamliter/Library/texmf\",\"branch\",\"-f\",\"synced/master\"]
+    [2013-09-09 02:04:22 EDT] XMPPSendPack: Syncing with adam.liter 
+    [2013-09-09 02:04:22 EDT] call: git [\"--git-dir=/Users/adamliter/Library/texmf/.git\",\"--work-tree=/Users/adamliter/Library/texmf\",\"push\",\"adam.liter\",\"git-annex:refs/synced/6258750b-9b0d-4f05-b443-61f4fb0a3f66/YWRhbS5saXRlckBnbWFpbC5jb20=/git-annex\",\"refs/heads/master:refs/synced/6258750b-9b0d-4f05-b443-61f4fb0a3f66/YWRhbS5saXRlckBnbWFpbC5jb20=/master\"]
+    [2013-09-09 02:04:22 EDT] XMPPClient: sending: Pushing \"a29\" (StartingPush (UUID \"6258750b-9b0d-4f05-b443-61f4fb0a3f66\"))
+    [2013-09-09 02:04:22 EDT] XMPPClient: to client: a10/F4E99F98
+    [2013-09-09 02:04:23 EDT] XMPPReceivePack: timeout waiting for git send-pack output via XMPP
+    fatal: The remote end hung up unexpectedly
+    [2013-09-09 02:04:23 EDT] XMPPReceivePack: finished running push Pushing \"a29\" (StartingPush (UUID \"c96c8493-b702-4ca0-9a88-f8a38dd6c3f5\")) True
+    [2013-09-09 02:04:23 EDT] XMPPClient: sending: Pushing \"a29\" (ReceivePackDone (ExitFailure 128))
+    [2013-09-09 02:04:23 EDT] XMPPReceivePack: started running push Pushing \"a29\" (StartingPush (UUID \"c96c8493-b702-4ca0-9a88-f8a38dd6c3f5\"))
+    [2013-09-09 02:04:23 EDT] XMPPClient: to client: a10/F4E99F98
+    [2013-09-09 02:04:23 EDT] XMPPReceivePack: Syncing with adam.liter 
+    [2013-09-09 02:04:23 EDT] chat: git [\"receive-pack\",\"/Users/adamliter/Library/texmf\"]
+    [2013-09-09 02:04:23 EDT] XMPPClient: sending: Pushing \"a29\" (ReceivePackOutput 1 \"<elided>\")
+    [2013-09-09 02:04:23 EDT] XMPPClient: to client: a10/F4E99F98
+    [2013-09-09 02:04:23 EDT] XMPPClient: sending: Pushing \"a29\" (ReceivePackOutput 2 \"<elided>\")
+    [2013-09-09 02:04:23 EDT] XMPPClient: to client: a10/F4E99F98
+    [2013-09-09 02:04:23 EDT] XMPPClient: received: [\"Pushing \\"a29\\" (StartingPush (UUID \\"c96c8493-b702-4ca0-9a88-f8a38dd6c3f5\\"))\"]
+    [2013-09-09 02:04:23 EDT] XMPPClient: received: [\"Unknown message\"]
+
+
+
+
+"""]]
diff --git a/doc/bugs/Could_not_read_from_remote_repository/comment_3_95d16045dc238dba19a98808de2eeedf._comment b/doc/bugs/Could_not_read_from_remote_repository/comment_3_95d16045dc238dba19a98808de2eeedf._comment
new file mode 100644
index 0000000000..a8d2705a62
--- /dev/null
+++ b/doc/bugs/Could_not_read_from_remote_repository/comment_3_95d16045dc238dba19a98808de2eeedf._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnvVfFLW4CTKs7UjdiLIsOn_cxj1Jnh64I"
+ nickname="Charl"
+ subject="Could it be gmail.com XMPP throttling?"
+ date="2014-03-23T19:26:08Z"
+ content="""
+I was seeing similar error messages, until I registered for a different XMPP account at jabber.de and started using that instead of my gmail.com account.
+
+My current suspicion is that it could be Google performing throttling on their XMPP service. See here: http://stackoverflow.com/questions/1843837/what-is-the-throttling-rate-that-gtalk-applies-to-xmpp-messages
+
+"""]]
diff --git a/doc/bugs/Crash_when_disabling_syncing_in_the_webapp.mdwn b/doc/bugs/Crash_when_disabling_syncing_in_the_webapp.mdwn
new file mode 100644
index 0000000000..b239c0a401
--- /dev/null
+++ b/doc/bugs/Crash_when_disabling_syncing_in_the_webapp.mdwn
@@ -0,0 +1,25 @@
+### Please describe the problem.
+The watcher crashes.
+
+I only need to restart the thread in the pop-up to get everything to work again, but I'm reporting just in case that this issue has any other implications.
+
+
+### What steps will reproduce the problem?
+I open the webapp and in the minutes before it starts syncing (syncing is enabled) I disable it (clicking in the 'syncing enabled' text).
+
+This produces a crash every time.
+
+
+### What version of git-annex are you using? On what operating system?
+5.20140320 in Debian sid and testing
+
+
+### Please provide any additional information below.
+This is all I can see in the logs
+
+[[!format sh """
+Watcher crashed: PauseWatcher
+[2014-03-26 08:54:57 CET] Watcher: warning Watcher crashed: PauseWatcher
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Crash_when_disabling_syncing_in_the_webapp/comment_1_e25dd80370820782f9c6a877101d8703._comment b/doc/bugs/Crash_when_disabling_syncing_in_the_webapp/comment_1_e25dd80370820782f9c6a877101d8703._comment
new file mode 100644
index 0000000000..ce4af5caa5
--- /dev/null
+++ b/doc/bugs/Crash_when_disabling_syncing_in_the_webapp/comment_1_e25dd80370820782f9c6a877101d8703._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.41"
+ subject="comment 1"
+ date="2014-03-26T17:36:00Z"
+ content="""
+How did you install git-annex? Is this Debian Linux?
+
+I have not been able to reproduce a crash. It's indeed the case that a PauseWatcher exception is thrown, but the Watcher explicitly catches that exception.
+"""]]
diff --git a/doc/bugs/Crash_when_disabling_syncing_in_the_webapp/comment_2_4031c16362137747717e9595cb5c8a15._comment b/doc/bugs/Crash_when_disabling_syncing_in_the_webapp/comment_2_4031c16362137747717e9595cb5c8a15._comment
new file mode 100644
index 0000000000..07efa451d7
--- /dev/null
+++ b/doc/bugs/Crash_when_disabling_syncing_in_the_webapp/comment_2_4031c16362137747717e9595cb5c8a15._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
+ nickname="Jon Ander"
+ subject="comment 2"
+ date="2014-04-01T08:04:51Z"
+ content="""
+Yes, this is Debian Linux and I've been able to reproduce it in i386 and amd64. git-annex is installed from the Debian repositories.
+
+I'll try to continue testing the issue and will report back if I can find any useful info.
+"""]]
diff --git a/doc/bugs/Crash_when_disabling_syncing_in_the_webapp/comment_3_0667f39f60bdaba6670f5b8304a8a77c._comment b/doc/bugs/Crash_when_disabling_syncing_in_the_webapp/comment_3_0667f39f60bdaba6670f5b8304a8a77c._comment
new file mode 100644
index 0000000000..60f82a5b30
--- /dev/null
+++ b/doc/bugs/Crash_when_disabling_syncing_in_the_webapp/comment_3_0667f39f60bdaba6670f5b8304a8a77c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 3"
+ date="2014-04-02T20:38:12Z"
+ content="""
+So we have the same version of git-annex from the same build, and only you see the problem. Hmm..
+
+You mentioned that you see the problem if you disable syncing at a particular time. Does it only crash at that time, or at any time?
+
+If you create a brand new empty repository and run the webapp in it, can you reporoduce the problem there? Ie, \"mkdir test; cd test; git init; git annex init; git annex webapp\"
+"""]]
diff --git a/doc/bugs/Creating_an_encrypted_S3_does_not_check_for_presence_of_GPG.mdwn b/doc/bugs/Creating_an_encrypted_S3_does_not_check_for_presence_of_GPG.mdwn
new file mode 100644
index 0000000000..611e86d613
--- /dev/null
+++ b/doc/bugs/Creating_an_encrypted_S3_does_not_check_for_presence_of_GPG.mdwn
@@ -0,0 +1,19 @@
+What steps will reproduce the problem?
+
+Don't have gpg installed/on your $PATH, and attempt to create an encrypted S3 remote via the web interface.
+
+What is the expected output? What do you see instead?
+
+Expected to be told to install GPG. Actual output was a Yesod error:
+
+Internal Server Error
+user error (gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--gen-random","--armor","1","512"] exited 127)
+
+What version of git-annex are you using? On what operating system?
+
+3.20130107 on Fedora 17 (64-bit).
+
+Please provide any additional information below.
+
+[[!tag /design/assistant]]
+[[!tag confirmed]]
diff --git a/doc/bugs/Data_loss_when_copying_files_with_running_assistant.mdwn b/doc/bugs/Data_loss_when_copying_files_with_running_assistant.mdwn
new file mode 100644
index 0000000000..ba563953c3
--- /dev/null
+++ b/doc/bugs/Data_loss_when_copying_files_with_running_assistant.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+
+I’ve just experienced something strange. When files are copied (instead of moved) into a repo with an assistant running, some of them get lost.
+
+### What steps will reproduce the problem?
+
+1. Start the assistant.
+2. `cp -rv some-big-directory your-annex-repo/`
+3. Wait for sync to finish.
+4. Compare some-big-directory with your-annex-repo/some-big-directory.
+
+It might be of some importance that I’m syncing this repo to 5 different machines.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 6.20170520
+local repository version: 6
+operating system: linux x86_64
+
+### Please provide any additional information below.
+
+Hard to tell, sometimes it happens, sometimes not.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sure, very cool, but this data loss thing creeped me out!
diff --git a/doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_1_51e7afb030dfb3052044b0fa95e08bed._comment b/doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_1_51e7afb030dfb3052044b0fa95e08bed._comment
new file mode 100644
index 0000000000..f43dbe6f35
--- /dev/null
+++ b/doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_1_51e7afb030dfb3052044b0fa95e08bed._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 1"
+ date="2017-08-20T15:47:03Z"
+ content="""
+These files can be seen in `git annex unused` on the machine that was to add them…
+"""]]
diff --git a/doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_2_b9cc9ae227a6dd883a2324b6d70b88ad._comment b/doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_2_b9cc9ae227a6dd883a2324b6d70b88ad._comment
new file mode 100644
index 0000000000..dc3f82a0ca
--- /dev/null
+++ b/doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_2_b9cc9ae227a6dd883a2324b6d70b88ad._comment
@@ -0,0 +1,111 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 2"
+ date="2017-08-20T16:45:09Z"
+ content="""
+I’ve got some `git log -S'KEY'` of what happened. Names censored. So it seems like peers are deleting and re-adding this files, and at the end they end up deleted. :( The last commit is me manually re-adding them one last time.
+
+Please note, that these are completely new files, it’s not possible that merges are deleting them.
+
+```
+commit 38134b87fdd6957c578f2a9d06d6c50aefee361b
+Author: Elzbieta
+Date:   Sun Aug 20 18:21:04 2017 +0200
+
+    Re-add unused files
+
+ ...7e4a6e20cba47b04eefef5ad0a85e16b00e8f5bbc5bcfade24ad0b934738d790.docx | 1 +
+ 1 file changed, 1 insertion(+)
+
+commit 9d3be6aafe84fa7e114f5de12c0a15adc0b2704e
+Author: Elzbieta
+Date:   Sun Aug 20 12:20:13 2017 +0200
+
+    git-annex in elzbietarus
+
+ .../SA\305\201ATKA \305\232LEDZIOWA, SA\305\201ATKA Z SZYNKI.docx\"       | 1 +
+ 1 file changed, 1 insertion(+)
+
+commit 92c1e62f8483c6b4fa263180a8a506bf5d0a46c7
+Author: Elzbieta
+Date:   Sun Aug 20 12:20:10 2017 +0200
+
+    git-annex in elzbietarus
+
+ .../SA\305\201ATKA \305\232LEDZIOWA, SA\305\201ATKA Z SZYNKI.docx\"       | 1 -
+ 1 file changed, 1 deletion(-)
+
+commit cd51d4dfed402a0929d357bb9557923618fdadff
+Author: Robert
+Date:   Sun Aug 20 12:19:56 2017 +0200
+
+    git-annex in robertrus-qx511
+
+ .../SA\305\201ATKA \305\232LEDZIOWA, SA\305\201ATKA Z SZYNKI.docx\"       | 1 +
+ 1 file changed, 1 insertion(+)
+
+commit 879256502d8047f0a3ed5487a57854076459f9a7
+Author: Robert
+Date:   Sun Aug 20 12:19:54 2017 +0200
+
+    git-annex in robertrus-qx511
+
+ .../SA\305\201ATKA \305\232LEDZIOWA, SA\305\201ATKA Z SZYNKI.docx\"       | 1 -
+ 1 file changed, 1 deletion(-)
+
+commit 7196eb855f2ca3ca87959002c3e61c7e060d7ae6
+Author: Elzbieta
+Date:   Sun Aug 20 12:19:50 2017 +0200
+
+    git-annex in elzbietarus
+
+ .../SA\305\201ATKA \305\232LEDZIOWA, SA\305\201ATKA Z SZYNKI.docx\"       | 1 +
+ 1 file changed, 1 insertion(+)
+
+commit f566cb65b19aa6144e7587cdcb2a8b910584391c
+Author: Elzbieta
+Date:   Sun Aug 20 12:19:42 2017 +0200
+
+    git-annex in elzbietarus
+
+ .../SA\305\201ATKA \305\232LEDZIOWA, SA\305\201ATKA Z SZYNKI.docx\"       | 1 -
+ 1 file changed, 1 deletion(-)
+
+commit de732718be3c25580463ddc5cd8abaf5eb6ca4be
+Author: Michal Rus <m@michalrus.com>
+Date:   Sun Aug 20 12:19:28 2017 +0200
+
+    git-annex in michalrus
+
+ .../SA\305\201ATKA \305\232LEDZIOWA, SA\305\201ATKA Z SZYNKI.docx\"       | 1 -
+ 1 file changed, 1 deletion(-)
+
+commit b25b6274332bc5ac42dc0b6a0d69abe3bd32e0e0
+Author: Robert
+Date:   Sun Aug 20 12:19:24 2017 +0200
+
+    git-annex in robertrus-np300e5a
+
+ .../SA\305\201ATKA \305\232LEDZIOWA, SA\305\201ATKA Z SZYNKI.docx\"       | 1 +
+ 1 file changed, 1 insertion(+)
+
+commit f26399a8a62ae54eec45355f60228bc55527302d
+Author: Robert
+Date:   Sun Aug 20 12:19:22 2017 +0200
+
+    git-annex in robertrus-np300e5a
+
+ .../SA\305\201ATKA \305\232LEDZIOWA, SA\305\201ATKA Z SZYNKI.docx\"       | 1 -
+ 1 file changed, 1 deletion(-)
+
+commit 103a62866df6fa8c7e18b727865c6c354fd6fc12
+Author: Elzbieta
+Date:   Sun Aug 20 12:16:29 2017 +0200
+
+    git-annex in elzbietarus
+
+ .../SA\305\201ATKA \305\232LEDZIOWA, SA\305\201ATKA Z SZYNKI.docx\"       | 1 +
+ 1 file changed, 1 insertion(+)
+```
+"""]]
diff --git a/doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_3_15f4fc02d574a2ed55e683dd99e9b72c._comment b/doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_3_15f4fc02d574a2ed55e683dd99e9b72c._comment
new file mode 100644
index 0000000000..2acf16d380
--- /dev/null
+++ b/doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_3_15f4fc02d574a2ed55e683dd99e9b72c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 3"
+ date="2017-08-26T12:18:11Z"
+ content="""
+Related: [https://git-annex.branchable.com/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/](https://git-annex.branchable.com/bugs/Assistant_deleted_file_when_merging___40__another_report__41__/)
+"""]]
diff --git a/doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_4_c16ecf8fabd0c63a7b59927fe0bb6e2c._comment b/doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_4_c16ecf8fabd0c63a7b59927fe0bb6e2c._comment
new file mode 100644
index 0000000000..e55d4538e5
--- /dev/null
+++ b/doc/bugs/Data_loss_when_copying_files_with_running_assistant/comment_4_c16ecf8fabd0c63a7b59927fe0bb6e2c._comment
@@ -0,0 +1,94 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 4"
+ date="2017-09-21T12:56:30Z"
+ content="""
+Look. What’s happening here? Reverse order. First, a file is saved and then assistant running on other machines makes a decision to remove it. Where does it come from? :o
+
+```
+commit cc61f6db3273c749ac2e4bdfb489457af919472c
+Author: Elzbieta Rus <rus.elzbieta@gmail.com>
+Date:   Sat Sep 2 14:23:13 2017 +0200
+
+    git-annex in elzbietarus
+
+ Dokumenty/Przepisy/SERNIK NA ZIMNO.docx | 1 -
+ 1 file changed, 1 deletion(-)
+
+commit 30965f29f756f02ad5d617d6fd07ec7013e01226
+Merge: d69d69901f ec07710223
+Author: Robert Rus <rusrob@poczta.onet.pl>
+Date:   Sat Sep 2 14:17:20 2017 +0200
+
+    Merge remote-tracking branch 'refs/remotes/origin/master'
+
+commit d69d69901fc2a4c958077cfbf8b27f595465627c
+Author: Robert Rus <rusrob@poczta.onet.pl>
+Date:   Sat Sep 2 14:17:17 2017 +0200
+
+    git-annex in robertrus-asus-1225c
+
+ Dokumenty/Przepisy/SERNIK NA ZIMNO.odt | 1 +
+ 1 file changed, 1 insertion(+)
+
+commit ec07710223770d1458de76004ec9baab5c20d508
+Merge: a60c530e9b 1cb58f2783
+Author: Robert Rus <rusrob@poczta.onet.pl>
+Date:   Sat Sep 2 14:17:17 2017 +0200
+
+    Merge remote-tracking branch 'refs/remotes/origin/master'
+
+commit 1e29dee284b5b9f4593cd7c0484c194ac2a9644c
+Merge: 1a36f09308 1cb58f2783
+Author: Robert Rus <rusrob@poczta.onet.pl>
+Date:   Sat Sep 2 14:17:16 2017 +0200
+
+    Merge remote-tracking branch 'refs/remotes/origin/master'
+
+commit a60c530e9b167c17b625e66f42e7282a1e275703
+Author: Robert Rus <rusrob@poczta.onet.pl>
+Date:   Sat Sep 2 14:17:16 2017 +0200
+
+    git-annex in robertrus-acer
+
+ Dokumenty/Przepisy/SERNIK NA ZIMNO.odt | 1 +
+ 1 file changed, 1 insertion(+)
+
+commit 1a36f09308c4134646b7074f2e827c909ee7033a
+Author: Robert Rus <rusrob@poczta.onet.pl>
+Date:   Sat Sep 2 14:17:14 2017 +0200
+
+    git-annex in robertrus-asus-1225c
+
+ Dokumenty/Przepisy/SERNIK NA ZIMNO.odt | 1 -
+ 1 file changed, 1 deletion(-)
+
+commit 1cb58f2783485e83d369ab9acb41f7e83cc3314c
+Author: Mikolaj Rus <mikolaj.rus6@gmail.com>
+Date:   Sat Sep 2 14:17:12 2017 +0200
+
+    git-annex in mikolajrus
+
+ Dokumenty/Przepisy/SERNIK NA ZIMNO.odt | 1 +
+ 1 file changed, 1 insertion(+)
+
+commit 3542add42a050c5331cbfa67bffee38a05ce6bc6
+Author: Mikolaj Rus <mikolaj.rus6@gmail.com>
+Date:   Sat Sep 2 14:17:11 2017 +0200
+
+    git-annex in mikolajrus
+
+ Dokumenty/Przepisy/SERNIK NA ZIMNO.odt | 1 -
+ 1 file changed, 1 deletion(-)
+
+commit 956243cab7b865f9e633f51d4376154a3478210a
+Author: Elzbieta Rus <rus.elzbieta@gmail.com>
+Date:   Sat Sep 2 14:17:00 2017 +0200
+
+    git-annex in elzbietarus
+
+ Dokumenty/Przepisy/SERNIK NA ZIMNO.odt | 1 +
+ 1 file changed, 1 insertion(+)
+```
+"""]]
diff --git a/doc/bugs/Deasn__39__t_clean_up_ssh_keys_after_removing_remote_repo.mdwn b/doc/bugs/Deasn__39__t_clean_up_ssh_keys_after_removing_remote_repo.mdwn
new file mode 100644
index 0000000000..0899ea4675
--- /dev/null
+++ b/doc/bugs/Deasn__39__t_clean_up_ssh_keys_after_removing_remote_repo.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+I created a remote repo on ssh server with the same git-annex version, no personal ssh keys for the repo (password authentication). But I put ~ in front of the repo name so it created in different place than I wanted. I deleted it from assistant and then deleted the remote repo dir. When I added it with the correct path again it always asks for server password (it has some old annex pub key in authorized_keys, but not the new one; it might have been prompted for the password also with the initial repo). During the whole thing it failed to connect a few times due to wrong password or me realizing too late that it asks for yet another one and it generated keys few times, but ultimately didn't put the last one in remote's authorized_keys.
+
+### What steps will reproduce the problem?
+Create, delete and create again a new repo on remote ssh server with password auth.
+
+### What version of git-annex are you using? On what operating system?
+git-annex 4.20130601 Gentoo amd64
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/Deasn__39__t_clean_up_ssh_keys_after_removing_remote_repo/comment_1_88fbf70eae48484988dbb433a437c717._comment b/doc/bugs/Deasn__39__t_clean_up_ssh_keys_after_removing_remote_repo/comment_1_88fbf70eae48484988dbb433a437c717._comment
new file mode 100644
index 0000000000..84686f1e45
--- /dev/null
+++ b/doc/bugs/Deasn__39__t_clean_up_ssh_keys_after_removing_remote_repo/comment_1_88fbf70eae48484988dbb433a437c717._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 1"
+ date="2013-06-25T18:20:05Z"
+ content="""
+It's true that deleting a ssh repository in the webapp does not delete any ssh keys that the webapp configured to access that repository. I'm a bit reluctant to try to clean it up entirely automatically, because the ssh configuration might have been manually altered, or might be used by another local repository. Particularly, if another local repo is set up to use the same ssh remote, the webapp will reuse the ssh key.
+
+> Create, delete and create again a new repo on remote ssh server with password auth.
+
+I tried doing this, and did not encounter any problem. Since the new repo had a different path on the ssh server, I simply ended up with two ssh keys configured in `~/.ssh/config` for two different repositories. The presence or absence of the first key did not affect the second key.
+
+I think you need to go into more detail about exactly what you did, or show the files in .ssh that were set up, so I can see what the actual problem is.
+"""]]
diff --git a/doc/bugs/Debian_and_MacOSX_cannot_read_eachother__39__s_S3_credentials.mdwn b/doc/bugs/Debian_and_MacOSX_cannot_read_eachother__39__s_S3_credentials.mdwn
new file mode 100644
index 0000000000..b2be7e9fa2
--- /dev/null
+++ b/doc/bugs/Debian_and_MacOSX_cannot_read_eachother__39__s_S3_credentials.mdwn
@@ -0,0 +1,66 @@
+### Please describe the problem.
+I seem to be hitting a problem with the way git annex encrypts the credentials for S3 remotes. I am creating an S3 remote with shared encryption and embedded credentials. If I create the remote on MacOSX, enableremote fails on Debian. If I create the remote on Debian, enableremote fails on MacOSX with a similar error.  I can enable MacOSX created remotes on other MacOSX systems and Debian created remotes on other Debian systems. 
+The enableremote creates a .git/annex/creds/uuid file, but the contents are garbled.
+
+Could this be an issue with different versions of GPG on the systems? 
+
+### What steps will reproduce the problem?
+- New git annex remote on Debian.
+- Clone and git annex init on MacOSX
+- Create S3 remote on MacOSX with encryption=shared embedcreds=yes 
+- Git annex sync
+- On Debian  enable remote
+
+Alternatively, create the S3 remote on Debian, sync and enable remote on MacOSX
+
+### What version of git-annex are you using? On what operating system?
+    MacOSX
+    gpg (GnuPG/MacGPG2) 2.0.30
+    libgcrypt 1.6.6
+    git-annex version: 6.20170101
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: darwin x86_64
+
+    Debian 7
+    gpg (GnuPG) 1.4.12
+    git-annex version: 6.20170101+gitg93d69b1-1~ndall+1
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
+### Please provide any additional information below.
+
+[[!format sh """
+# Debian 7
+    $ git annex enableremote S3
+    enableremote S3 gpg: packet(2) with unknown version 13
+      gpg error above was caused by an old git-annex bug in credentials storage. Working around it..
+    git-annex: bad creds
+    CallStack (from HasCallStack):
+      error, called at ./Creds.hs:116:22 in main:Creds
+
+ #   MacOSX
+    git annex enableremote S34
+    enableremote S34 gpg: [don't know]: invalid packet (ctb=6b)
+      gpg error above was caused by an old git-annex bug in credentials storage. Working around it..
+    git-annex: bad creds
+    CallStack (from HasCallStack):
+      error, called at ./Creds.hs:116:22 in main:Creds
+
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Yes! git annex has been enormously helpful. Thanks so much for this tool.
+
+
+> I guess this was caused by an old gpg, and so no point in keeping it
+> open. [[done]] --[[Joey]]
diff --git a/doc/bugs/Debian_and_MacOSX_cannot_read_eachother__39__s_S3_credentials/comment_1_e307e5d0ec02ed76dc7c3f0894770539._comment b/doc/bugs/Debian_and_MacOSX_cannot_read_eachother__39__s_S3_credentials/comment_1_e307e5d0ec02ed76dc7c3f0894770539._comment
new file mode 100644
index 0000000000..840bfdaa2e
--- /dev/null
+++ b/doc/bugs/Debian_and_MacOSX_cannot_read_eachother__39__s_S3_credentials/comment_1_e307e5d0ec02ed76dc7c3f0894770539._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-13T18:27:02Z"
+ content="""
+The .git/annex/creds/uuid files for S3 special remotes are supposed to
+contain the S3 access credentials, the same values you set
+`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to. Since it's just some
+high-entropy credentials, perhaps that's why you thought it looked garbled?
+
+I doubt that the error message about the cause of the gpg error is
+right; that is a workaround for an old bug in git-annex 5.20140916. Unless
+you used such an old version to set up the special remote, it's probably
+not related to that problem at all.
+
+The actual problem seems to be:
+
+	gpg: packet(2) with unknown version 13
+	gpg: [don't know]: invalid packet (ctb=6b)
+
+This probably points to an incompatability between the gpg versions.
+The easiest fix is probably to upgrade Debian to gpg 2.
+
+With embedcreds, the S3 creds are symmetrically encrypted/decrypted
+using gpg --symmetric. This is a less common way to use gpg,
+and it could be that there's an incompatability with how different
+versions of gpg do it.
+"""]]
diff --git a/doc/bugs/Delete_data__47__update_location_log_when_a_special_remote_fails_to_fsck.mdwn b/doc/bugs/Delete_data__47__update_location_log_when_a_special_remote_fails_to_fsck.mdwn
new file mode 100644
index 0000000000..a7c2c77775
--- /dev/null
+++ b/doc/bugs/Delete_data__47__update_location_log_when_a_special_remote_fails_to_fsck.mdwn
@@ -0,0 +1,72 @@
+### Please describe the problem.
+
+After all the work I did [here](https://git-annex.branchable.com/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/), I discvovered that I have a Git Annex-encrypted special remote that has some corrupted data on it. I can run `git annex fsck --from=remotename` and have Git Annex complain about all the files that have failed to fsck. But Git Annex is not updating the location log. It still thinks the data is in the special remote, after fscking it and not getting the right data out.
+
+This makes sense if the failure was from a download corrupted in transit, but I think the files are actually corrupted in the remote. How do I make `git annex fsck` update the location log to say that files aren't there when they fail to fsck? Alternately, how do I get a nice list of all the filenames that failed to fsck, so I can have a script drop them from the offending remote?
+
+### What steps will reproduce the problem?
+
+1. Make a Git Annex encrypted special remote.
+
+2. Put some data in it.
+
+3. Modify the encrypted data, to corrupt it.
+
+4. Use `git annex fsck` on the file you broke.
+
+5. See that `git annex whereis` still thinks the file is in the special remote.
+
+### What version of git-annex are you using? On what operating system?
+
+This is Git Annex 6.20170408+gitg804f06baa-1~ndall+1 on Ubuntu 14.04.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+$ git annex whereis info.txt
+whereis info.txt (6 copies) 
+  	...
+        ...
+   	21a0c4ba-7255-4a9e-9baa-c638f7df68e5 -- gdrive [amazon]
+   	...
+   	...
+   	...
+ok
+$ git annex fsck --from=amazon info.txt
+...
+gpg: decryption failed: bad key
+2017/06/13 20:14:54 Local file system at /tmp/tmp.Cu2Dsk0jY3: Waiting for checks to finish
+2017/06/13 20:14:54 Local file system at /tmp/tmp.Cu2Dsk0jY3: Waiting for transfers to finish
+2017/06/13 20:14:54 Attempt 1/3 failed with 0 errors and: directory not found
+2017/06/13 20:14:54 Local file system at /tmp/tmp.Cu2Dsk0jY3: Waiting for checks to finish
+2017/06/13 20:14:54 Local file system at /tmp/tmp.Cu2Dsk0jY3: Waiting for transfers to finish
+2017/06/13 20:14:54 Attempt 2/3 failed with 0 errors and: directory not found
+2017/06/13 20:14:55 Local file system at /tmp/tmp.Cu2Dsk0jY3: Waiting for checks to finish
+2017/06/13 20:14:55 Local file system at /tmp/tmp.Cu2Dsk0jY3: Waiting for transfers to finish
+  failed to download file from remote
+2017/06/13 20:14:55 Attempt 3/3 failed with 0 errors and: directory not found
+2017/06/13 20:14:55 Failed to copy: directory not found
+git-annex: fsck: 1 failed
+$ git annex whereis info.txt
+whereis info.txt (6 copies) 
+  	...
+   	...
+   	21a0c4ba-7255-4a9e-9baa-c638f7df68e5 -- gdrive [amazon]
+   	...
+   	...
+   	...
+ok
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yeah, it works great! If not for it I would not have noticed this data corruption until it was too late.
+
+
diff --git a/doc/bugs/Delete_data__47__update_location_log_when_a_special_remote_fails_to_fsck/comment_1_203ebe6fa1bb8d3c6e7c0b948fc7dd6b._comment b/doc/bugs/Delete_data__47__update_location_log_when_a_special_remote_fails_to_fsck/comment_1_203ebe6fa1bb8d3c6e7c0b948fc7dd6b._comment
new file mode 100644
index 0000000000..60fd9b8df8
--- /dev/null
+++ b/doc/bugs/Delete_data__47__update_location_log_when_a_special_remote_fails_to_fsck/comment_1_203ebe6fa1bb8d3c6e7c0b948fc7dd6b._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-26T17:14:56Z"
+ content="""
+`fsck --from remote` is supposed to update the location log when it
+determines that the remote does not contain the file.
+
+But in your case, the decryption failure appears to fsck as a transfer
+failure, which as you note can be transient. So it doesn't update the
+location log.
+
+It seems that what's needed is different errors to be returned when
+download fails, vs when download succeeds but decryption/verification fails.
+Then fsck could mark the file as not being present in the remote
+in the latter case.
+
+Although, that would leave the presumably corrupted encrypted data in the
+remote. (Unless fsck also tried to delete it.)
+
+Also, decryption can fail for other reasons, eg missing gpg keys,
+and in such a case, it would be bad for fsck to decide that the remote
+didn't contain any content! (And super bad for it to delete it from the
+remote!!)
+
+So hmm, I'm not sure about that idea.
+
+Your idea of getting a list of files that fsck failed to download
+is certianly useful. Perhaps a good way would be to make `git annex fsck
+--from remote --json` work, then the json output could be parsed to get a list of
+files, and you could use `git annex drop --from remote` to remove the bad
+data. That was the easiest possible thing, so I've made that change.
+"""]]
diff --git a/doc/bugs/Direct_mode_repositories_still_use_symlinks_sometimes.mdwn b/doc/bugs/Direct_mode_repositories_still_use_symlinks_sometimes.mdwn
new file mode 100644
index 0000000000..10b25d774b
--- /dev/null
+++ b/doc/bugs/Direct_mode_repositories_still_use_symlinks_sometimes.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+When a repository is set in direct mode it will still replace files with symlinks when it becomes aware of a change but still hasn't been able to sync the file contents. This can create repositories that are temporarily unusable with files replaced with broken symlinks.
+
+### What steps will reproduce the problem?
+
+1. Create two repositories with each other as remotes
+2. Run the assistant on both
+3. Create some file changes in one and watch the directory in another.
+4. For a brief (or sometimes long) time the destination repository will have it's old version of the file replaced by a broken symlink
+
+This is particularly noticeable when using XMPP as it can often be the case that the two repositories can't connect to each other directly but can talk through XMPP. This breaks using git-annex in direct mode for things like having a synced config directory across machines. Something like having "~/.bashrc" linked into "~/annex-repository/bashrc", doesn't work as there will be times when a machine is broken because .bashrc is linked to a broken symlink while it fetches a new version. 
+
+The desired behavior would be to have git-annex in direct mode only replace older versions of files with newer versions of files.
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+$ git annex version
+git-annex version: 4.20130516.1
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+local repository version: 4
+default repository version: 3
+supported repository versions: 3 4
+upgrade supported from repository versions: 0 1 2
+$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 12.04.2 LTS
+Release:	12.04
+Codename:	precise
+"""]]
+
+[[!meta title="git-annex does not guarantee modified files are available when merging with a new version of a repository"]]
+
+[[!tag confirmed]]
diff --git a/doc/bugs/Directory_remotes_with_same_mount_point.mdwn b/doc/bugs/Directory_remotes_with_same_mount_point.mdwn
new file mode 100644
index 0000000000..14d422229e
--- /dev/null
+++ b/doc/bugs/Directory_remotes_with_same_mount_point.mdwn
@@ -0,0 +1,55 @@
+### Please describe the problem.
+
+I have a repository with two directory special remotes that use the same mount point (it's a USB SD card reader using udevil). I use "git-annex-command" with lsblk and grep using the UUID to prevent git-annex from attempting to sync with the remote if it's not mounted. When trying to import from the second remote, I get "file content has changed" for every file, which seems to be related to inode-based caching.
+
+Each of the remotes uses a subdirectory of the mount, though I did change the directory for the first one (it originally used the mount point directly). 
+
+### What steps will reproduce the problem?
+
+1. Create a directory special remote on a removable device and import from it
+2. Create a second directory special remote on a second removable device at the same mount point and import from it
+
+
+### What version of git-annex are you using? On what operating system?
+
+8.20201130-g75988a790, Debian Buster
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+$ git annex import --from=pi1541 master:c64
+list pi1541 ok                                    
+import pi1541 nav96.d64                           
+                                                                
+  file content has changed                                  
+ok                                                    
+import pi1541 fb64                                    
+                                                                  
+  file content has changed                                        
+ok                                                  
+import pi1541 cbmcmd22.d64                     
+                                          
+  file content has changed                               
+ok                                                         
+import pi1541 cbmcmd22.d80                 
+                                                  
+  file content has changed                             
+ok                                                      
+...
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I've used it successfully on Linux and Android. My attempts on Windows have been less successful, though I never tried with core.ignoreStat=true. Now I'm trying to use it to manage the SD cards for various devices: my Pi1541, Odroid Go, and Sansa Clip Zip.
+
+> Calling this [[done]] because I'm fairly sure if it was some kind of
+> inode related bug, it would be fixed now by changes to the directory
+> special remote. Please do followup if you still see the bug with the most
+> recent git-annex release, or have other information about how to
+> reproduce the alleged behavior. --[[Joey]]
diff --git a/doc/bugs/Directory_remotes_with_same_mount_point/comment_1_351063bf8fb7779a9a7ecd21bef8b801._comment b/doc/bugs/Directory_remotes_with_same_mount_point/comment_1_351063bf8fb7779a9a7ecd21bef8b801._comment
new file mode 100644
index 0000000000..73f88e9dd6
--- /dev/null
+++ b/doc/bugs/Directory_remotes_with_same_mount_point/comment_1_351063bf8fb7779a9a7ecd21bef8b801._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="seanl@fe5df935169a5440a52bdbfc5fece85cdd002d68"
+ nickname="seanl"
+ avatar="http://cdn.libravatar.org/avatar/082ffc523e71e18c45395e6115b3b373"
+ subject="Works fine after changing mount point"
+ date="2021-01-17T07:24:38Z"
+ content="""
+I uninstalled udevil in favor of udiskie, which uses a mount point name based on the label instead of the device, updated the directory to point at the new mount point with `git annex enableremote pi1541 <new mount point>/1541`, and the problem went away. But it doesn't seem like having different mount points for removable devices should be a requirement.
+"""]]
diff --git a/doc/bugs/Directory_remotes_with_same_mount_point/comment_2_90351193c14f4c68f9b92640dae82f13._comment b/doc/bugs/Directory_remotes_with_same_mount_point/comment_2_90351193c14f4c68f9b92640dae82f13._comment
new file mode 100644
index 0000000000..3e698483dc
--- /dev/null
+++ b/doc/bugs/Directory_remotes_with_same_mount_point/comment_2_90351193c14f4c68f9b92640dae82f13._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-01-18T16:23:42Z"
+ content="""
+I don't think this has anything to do with mount points being in common.
+Consider that, a single disk with a git-annex repository, and 2 directory
+special remotes all on it has everything under a common mount point. And
+I'm pretty sure works. Also there's just nothing in the relevant code that
+cares what the mount point is.
+
+It looks to me like the inode was somehow not the same in the "list" stage
+of the command as it was in the "import" stage, or the file that was seen
+in the first stage was no longer present in the second stage. I don't see
+how that could be a git-annex bug. It could, for example, happen if one SD
+card was mounted there at the "list" stage, and then a different card got
+mounted there at the "import" stage, or even if the SD card just got
+unmounted in between the two stages.
+
+I have not been able to replicate the problem either, using 2 removable
+devices on the same mount point, 2 special remotes, etc. So you will have
+to show me how to reproduce this if it's actually a bug.
+"""]]
diff --git a/doc/bugs/Directory_remotes_with_same_mount_point/comment_3_6b7727db8e2487394a80fc061d76868e._comment b/doc/bugs/Directory_remotes_with_same_mount_point/comment_3_6b7727db8e2487394a80fc061d76868e._comment
new file mode 100644
index 0000000000..91c72c89f9
--- /dev/null
+++ b/doc/bugs/Directory_remotes_with_same_mount_point/comment_3_6b7727db8e2487394a80fc061d76868e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="seanl@fe5df935169a5440a52bdbfc5fece85cdd002d68"
+ nickname="seanl"
+ avatar="http://cdn.libravatar.org/avatar/082ffc523e71e18c45395e6115b3b373"
+ subject="Went away with fsck?"
+ date="2021-01-19T01:15:51Z"
+ content="""
+I tried unmounting the sd card, fscking, and remounting, and then I was able to import without issue. I haven't tried a sync or a second import, though. All of my SD cards use VFAT, and this one has 160k+ files on it. I'm wondering if there are cases where Linux's VFAT implementation will give different inode numbers for the same file during the same session? The only mention of inode numbers in the Linux VFAT documentation is in the NFS section, though. I'll let you know if I run into it again.
+"""]]
diff --git a/doc/bugs/Directory_remotes_with_same_mount_point/comment_4_5a4b3daa0f8a0d7f330f5a1d922d0f6a._comment b/doc/bugs/Directory_remotes_with_same_mount_point/comment_4_5a4b3daa0f8a0d7f330f5a1d922d0f6a._comment
new file mode 100644
index 0000000000..ebfd97e4bd
--- /dev/null
+++ b/doc/bugs/Directory_remotes_with_same_mount_point/comment_4_5a4b3daa0f8a0d7f330f5a1d922d0f6a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-01-19T15:40:49Z"
+ content="""
+I don't think linux would change inode numbers while the filesystem was
+mounted. But each mount of FAT gets new inode numbers, since FAT doesn't
+actually have them and linux makes them up. So the filesystem being
+unmounted and remounted for some reason in between the two steps of the
+import would explain the behavior.
+
+Note that I've opened 
+[[todo/import_tree_from_FAT_does_unnecessary_work_due_to_inode_instability]]
+after thinking of some other consequences of this.
+"""]]
diff --git a/doc/bugs/Directory_remotes_with_same_mount_point/comment_5_fb21865b36819a54a23e1ccb7f377fa1._comment b/doc/bugs/Directory_remotes_with_same_mount_point/comment_5_fb21865b36819a54a23e1ccb7f377fa1._comment
new file mode 100644
index 0000000000..d9e34d4eb8
--- /dev/null
+++ b/doc/bugs/Directory_remotes_with_same_mount_point/comment_5_fb21865b36819a54a23e1ccb7f377fa1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-01-19T16:53:54Z"
+ content="""
+Well, the changes I made for that todo make changes to inodes due to
+remounting in the middle of an import not cause behavior like this. Of
+course I don't know that's what caused this behavior, but it does seem
+likely those changes would turn out to have fixed this, if we understood 
+how to reproduce the problem.
+"""]]
diff --git a/doc/bugs/Disabling_remote_auto-enabling_not_possible.mdwn b/doc/bugs/Disabling_remote_auto-enabling_not_possible.mdwn
new file mode 100644
index 0000000000..b90623b009
--- /dev/null
+++ b/doc/bugs/Disabling_remote_auto-enabling_not_possible.mdwn
@@ -0,0 +1,65 @@
+### Please describe the problem.
+
+I have a repository with a special remote that is autoenable=true. The special remote is (no longer) accessible to everyone. I want to disable autoenable, but this fails, because the special remote is not accessible.
+
+How can autoenable be disabled, once a remote is no longer (or even temporarily) inaccessible to someone?
+
+### What steps will reproduce the problem?
+
+Here is a small script that demos this for a type-git special remote. However, the problem has been initially observed with different external special remotes. I only reproduced it with a git-annex built-in to see whether an implementation detail in the external special remote is causing this.
+
+```sh
+# create an annex-repo (using datalad, but this is the standard init+init dance)
+$ datalad create originds
+# make a clone with datalad (same as clone+init)
+$ datalad clone originds dsclone
+# add the autoenabling special remote in the clone
+$ git -C dsclone annex initremote myremote type=git "location=$(readlink -f originds)" autoenable=true
+
+# as long as `originds` is accessible everything runs smoothly
+$ datalad clone dsclone autoclone1
+
+# make the special remote target inaccessible
+$ mv originds originds-moved
+
+# enabling is no longer possible
+$ datalad clone dsclone autoclone2
+$ git -C autoclone2 annex enableremote myremote
+...
+Remote myremote cannot currently be accessed.
+...
+
+# access by special remote name is no possible
+$ git -C dsclone annex enableremote myremote autoenable=false
+...
+Remote myremote cannot currently be accessed.
+...
+git-annex: That is a normal git remote; passing these parameters does not make sense: autoenable=false
+
+# determine UUID from
+#   git -C dsclone annex info | grep myremote
+# because `git -C dsclone annex info myremote | grep uuid:` no longer lists it
+$ git -C dsclone annex enableremote ba87b7e1-4fec-4826-bd01-302a8e2eda0a autoenable=false
+Remote myremote cannot currently be accessed.
+...
+enableremote ba87b7e1-4fec-4826-bd01-302a8e2eda0a error: remote myremote already exists.
+
+git-annex: git [Param "remote",Param "add",Param "myremote",Param "/tmp/originds"] failed
+failed
+enableremote: 1 failed
+
+# autoenable is still on
+$ git -C dsclone cat-file -p git-annex:remote.log
+ba87b7e1-4fec-4826-bd01-302a8e2eda0a autoenable=true location=/tmp/originds name=myremote type=git timestamp=1681453180.645186501s
+```
+
+### What version of git-annex are you using? On what operating system?
+
+I am on Debian sid. I tried git-annex versions 10.20221003 and 10.20230126 -- both show the same behavior.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Loads! This particular issue started to show up in the datalad support channels due to aging infrastructure setups with still popular datasets tracking them using autoenabling special remotes.
+
+> [[fixed|done]] --[[Joey]]
+
diff --git a/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_1_136c0fa106347bd0474f8298fde227f5._comment b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_1_136c0fa106347bd0474f8298fde227f5._comment
new file mode 100644
index 0000000000..3e9a9c8a3b
--- /dev/null
+++ b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_1_136c0fa106347bd0474f8298fde227f5._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-04-17T17:42:31Z"
+ content="""
+`git-annex dead` will work.
+
+But it does seem to me that there is perhaps room to have a way 
+to clear the autoenable setting without killing the remote entirely,
+but without needing to be able to enableremote the remote.
+
+And I think, when you say "The special remote is (no longer) accessible to
+everyone" you mean some people still have access, right? But you're not
+one of those people and want to disable the autoenable.
+
+If so, I ought to add something like `git-annex configremote foo
+autoenable=false`.
+"""]]
diff --git a/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_2_f6b1d513e664d1a5ee51b90f49731eeb._comment b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_2_f6b1d513e664d1a5ee51b90f49731eeb._comment
new file mode 100644
index 0000000000..7df5268e80
--- /dev/null
+++ b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_2_f6b1d513e664d1a5ee51b90f49731eeb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Confirm"
+ date="2023-04-18T07:54:46Z"
+ content="""
+Yes, in this particular case the situation is as you describe it. The remote itself is fine for a select few, but I (and others) do not have the necessary means to access it. I want to disable autoenable in my \"fork\" to streamline usage for myself and people like me.
+
+I think your proposed solution would work well for this scenario. Thanks!
+"""]]
diff --git a/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_3_c2c7144fa74bdc455e1bd36b594902c1._comment b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_3_c2c7144fa74bdc455e1bd36b594902c1._comment
new file mode 100644
index 0000000000..bbef6139e0
--- /dev/null
+++ b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_3_c2c7144fa74bdc455e1bd36b594902c1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-04-18T16:28:40Z"
+ content="""
+Hmm, you could dead it in your fork. The issue would be, if they ever merge
+from it, their working repo will get marked as dead.
+
+A `git-annex configremote` would likewise cause them problems if they
+merged from your fork, if they rely on autoenabling being enabled. That's
+less likely to be a problem to them I suppose.
+"""]]
diff --git a/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_4_4f3e9f15fcc96cd98c6915ec68cc471f._comment b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_4_4f3e9f15fcc96cd98c6915ec68cc471f._comment
new file mode 100644
index 0000000000..8b148644cf
--- /dev/null
+++ b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_4_4f3e9f15fcc96cd98c6915ec68cc471f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-04-18T16:40:57Z"
+ content="""
+A sub-bug here is that enableremote of a normal git remote adding autoenable=false
+always fails with 
+"That is a normal git remote; passing these parameters does not make sense: autoenable=false".
+
+That happens even when the repo is accessible. So there is no way to disable
+a normal git remote that has been initremoted with autoenable=true.
+
+Update: Fixed that.
+"""]]
diff --git a/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_5_ccb5b6960da43a93ff0b7404190c51de._comment b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_5_ccb5b6960da43a93ff0b7404190c51de._comment
new file mode 100644
index 0000000000..c61178fbfe
--- /dev/null
+++ b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_5_ccb5b6960da43a93ff0b7404190c51de._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-04-18T16:49:45Z"
+ content="""
+I retried your example not using a regular git remote, but a special
+remote. When the special remote is made inaccessible, it does not fail in
+the same way. Actually, the clone doesn't fail at all:
+
+	joey@darkstar:~/tmp/dl>datalad clone dsclone autoclone5
+	[INFO   ] special remote made inacessible for testing
+	[INFO   ] Fetching updates for Dataset(/home/joey/tmp/dl/autoclone5) 
+	update(ok): . (dataset)
+	update(ok): . (dataset)
+	configure-sibling(ok): . (sibling)
+	install(ok): /home/joey/tmp/dl/autoclone5 (dataset)
+	action summary:
+	  configure-sibling (ok: 1)
+	  install (ok: 1)
+	  update (ok: 1)
+
+Likewise `git-annex init` displays the message from the special remote as a warning
+but exits successfully and without autoenabling it.
+
+Compare with datalad's behavior when it is a regular git remote. The failure there
+happens because git-annex auto-enables the remote successfully, and then
+datalad tries to fetch from it, but the repo is not available.
+
+So other than the special case of a git remote stored by initremote, this bug's
+real impact seems to only be that enableremote can't be used to change the
+configuration of a remote that's not accessible and `git-annex init` will
+warn about such a remote.
+"""]]
diff --git a/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_6_5b6359663efb608b9a78ab17c02be9ee._comment b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_6_5b6359663efb608b9a78ab17c02be9ee._comment
new file mode 100644
index 0000000000..7baf64ce95
--- /dev/null
+++ b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_6_5b6359663efb608b9a78ab17c02be9ee._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-04-18T18:11:18Z"
+ content="""
+Seems that `git-annex configremote` would be very limited in what
+configuration it can change. Changing configuration with enableremote
+re-runs the `setup` method, which is passed a RemoteConfig with the user's
+proposed changes and can either fail if the config is not valid, or return
+a RemoteConfig that might not be the same as the input one. Since `setup` also
+prepares to use the remote, which is what's failing when the remote is not
+accessible, it could not be used by `configremote`.
+
+So, I think autoenable is about the only config setting that it would make
+sense for configremote to be able to change. Changing anything else would
+risk storing a configuration that `setup` would not allow. Which could
+break the remote in arbitrary ways.
+"""]]
diff --git a/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_7_995b88efc83f76f14ccb22bc2a6ef4bd._comment b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_7_995b88efc83f76f14ccb22bc2a6ef4bd._comment
new file mode 100644
index 0000000000..1750b0c764
--- /dev/null
+++ b/doc/bugs/Disabling_remote_auto-enabling_not_possible/comment_7_995b88efc83f76f14ccb22bc2a6ef4bd._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2023-04-18T19:29:28Z"
+ content="""
+Implemented `git-annex configremote`
+"""]]
diff --git a/doc/bugs/Dropping_filename_extensions_with_more_than_4_char.mdwn b/doc/bugs/Dropping_filename_extensions_with_more_than_4_char.mdwn
new file mode 100644
index 0000000000..88276135e6
--- /dev/null
+++ b/doc/bugs/Dropping_filename_extensions_with_more_than_4_char.mdwn
@@ -0,0 +1,55 @@
+### Please describe the problem.
+
+The file extension of annexed files are dropped if they have more than four characters (like `.blend` files)
+All `*E` backends are affected but `WORM` seems to work.
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+mkdir foo && cd foo
+git init
+git annex init
+echo '* annex.backend=SHA256E' > .gitattributes
+echo '* annex.largefiles=(largerthan=0)' >> .gitattributes
+echo 'foo' > foo.abc
+echo 'bar' > bar.abcd
+echo 'baz' > baz.abcde
+echo 'faz' > faz.abcdef
+git annex add .
+ls -l
+"""]]
+
+Outputs
+
+[[!format sh """
+total 16
+lrwxrwxrwx 1 foo bar 188 Apr 18 11:52 bar.abcd -> .git/annex/objects/z2/jk/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730.abcd/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730.abcd
+lrwxrwxrwx 1 foo bar 178 Apr 18 11:52 baz.abcde -> .git/annex/objects/MZ/Fq/SHA256E-s4--bf07a7fbb825fc0aae7bf4a1177b2b31fcf8a3feeaf7092761e18c859ee52a9c/SHA256E-s4--bf07a7fbb825fc0aae7bf4a1177b2b31fcf8a3feeaf7092761e18c859ee52a9c
+lrwxrwxrwx 1 foo bar 178 Apr 18 11:52 faz.abcdef -> .git/annex/objects/6Z/zG/SHA256E-s4--0206bf5fc94a74ae22c2c0e93ad1b578ae7f16cb52fb470cddf1f0d324c6bbf3/SHA256E-s4--0206bf5fc94a74ae22c2c0e93ad1b578ae7f16cb52fb470cddf1f0d324c6bbf3
+lrwxrwxrwx 1 foo bar 186 Apr 18 11:52 foo.abc -> .git/annex/objects/Mq/J5/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.abc/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.abc
+"""]]
+
+
+### What version of git-annex are you using? On what operating system?
+
+- Tested with Ubuntu 22.04
+- git-annex v8 from original ubuntu ppa
+- git-annex-standalone v10 from neurodebian ppa
+
+### Please provide any additional information below.
+
+[[!format sh """
+$ git annex version
+git-annex version: 10.20240227-1~ndall+1
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+"""]]
+
+> As nobodyinperson says, set annex.maxextensionlength to 5 in order to
+> support such long extensions. [[done]] --[[Joey]]
diff --git a/doc/bugs/Dropping_filename_extensions_with_more_than_4_char/comment_1_ecc9ff2bca0638797f358d5ff0d9e363._comment b/doc/bugs/Dropping_filename_extensions_with_more_than_4_char/comment_1_ecc9ff2bca0638797f358d5ff0d9e363._comment
new file mode 100644
index 0000000000..b75b109e72
--- /dev/null
+++ b/doc/bugs/Dropping_filename_extensions_with_more_than_4_char/comment_1_ecc9ff2bca0638797f358d5ff0d9e363._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="annex.maxextensionlength and annex.maxextensions"
+ date="2024-04-27T19:16:29Z"
+ content="""
+See the recently added `annex.maxextensionlength` and `annex.maxextensions` configurations: https://git-annex.branchable.com/git-annex/, which should fix your issue.
+"""]]
diff --git a/doc/bugs/Duplicate_descriptions_cause_confusing_error.mdwn b/doc/bugs/Duplicate_descriptions_cause_confusing_error.mdwn
new file mode 100644
index 0000000000..ab40b4e527
--- /dev/null
+++ b/doc/bugs/Duplicate_descriptions_cause_confusing_error.mdwn
@@ -0,0 +1,46 @@
+### Please describe the problem.
+
+Running `git annex info <remote description>` on a remote that shares a description with another remote shows a confusing generic error:
+
+```
+fatal: Not a valid object name testname
+info testname (not a directory or an annexed file or a treeish or a remote or a uuid) failed
+```
+
+It should instead tell the user that there are multiple remotes by that description and unique identification is therefore not possible.
+
+This is also a thing when all remotes except for one are dead. git-annex should prefer the alive remote here and ignore all the dead ones.
+
+### What steps will reproduce the problem?
+
+1. Have a git-annex repo with multiple remotes that share a description
+2. Run `git annex info <remotename>`
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 10.20220822
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin aarch64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Empty_files_make_git_status_slow.mdwn b/doc/bugs/Empty_files_make_git_status_slow.mdwn
new file mode 100644
index 0000000000..64e4d171ac
--- /dev/null
+++ b/doc/bugs/Empty_files_make_git_status_slow.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+
+[[!meta title="Empty files make git status slow in v6 repo"]]
+
+When empty files are committed to a repository, git status becomes slow because git annex smudge is run for every empty file under git annex even with clean HEAD. I know git annex is for large files (rather than infinity small ones), but I'm using it to manage a GRASS GIS database, which oddly uses empty files for some things:/
+
+### What steps will reproduce the problem?
+```
+# slow
+touch emptyfile
+git add emptyfile
+git commit -a -m 'Added empty file.'
+GIT_TRACE=1 git status
+
+# fast
+cat 1 > emptyfile
+git commit -a -m 'Added a 1 to emptyfile.'
+GIT_TRACE=1 git status
+```
+
+### What version of git-annex are you using? On what operating system?
+- git-annex version: 6.20170228-g7a32e08c4
+- operating system: linux x86_64 (SLE 12.2)
+- local repository version: 6
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Yes, git with git annex has revolutionised my scientific project file organisation and thats why I want to improve it.
diff --git a/doc/bugs/Empty_files_make_git_status_slow/comment_1_67662686361d345b3b82d1c80adc2452._comment b/doc/bugs/Empty_files_make_git_status_slow/comment_1_67662686361d345b3b82d1c80adc2452._comment
new file mode 100644
index 0000000000..8c16331523
--- /dev/null
+++ b/doc/bugs/Empty_files_make_git_status_slow/comment_1_67662686361d345b3b82d1c80adc2452._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-02T17:20:24Z"
+ content="""
+I don't know why git is repeatedly smudging the empty file.
+(I was able to reproduce it.)
+
+git-annex does not treat an empty file any differently than any other file.
+It seems that this is probably a bug in git.
+
+Note that v6 git repos are known to be innefficient due to git's smudge
+interface not being very good. This is why they are not yet used by
+default.
+"""]]
diff --git a/doc/bugs/Empty_files_make_git_status_slow/comment_2_39876be38934e9056e9aa2a9fcdeaedf._comment b/doc/bugs/Empty_files_make_git_status_slow/comment_2_39876be38934e9056e9aa2a9fcdeaedf._comment
new file mode 100644
index 0000000000..777f26ac92
--- /dev/null
+++ b/doc/bugs/Empty_files_make_git_status_slow/comment_2_39876be38934e9056e9aa2a9fcdeaedf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Michel"
+ avatar="http://cdn.libravatar.org/avatar/cf9fdab9aa34af56f769bf584c8e7011"
+ subject="Thanks"
+ date="2017-03-09T07:34:25Z"
+ content="""
+Thanks for the looking into it. I guess it will have to be sorted out at the git end then or I will need to fill my empty files with a single character. I must say I love the v6 repo tho and hope it will become the default soon.
+"""]]
diff --git a/doc/bugs/Empty_files_make_git_status_slow/comment_3_17b400bc03eb176f63009b9e01a862f4._comment b/doc/bugs/Empty_files_make_git_status_slow/comment_3_17b400bc03eb176f63009b9e01a862f4._comment
new file mode 100644
index 0000000000..892eb6b728
--- /dev/null
+++ b/doc/bugs/Empty_files_make_git_status_slow/comment_3_17b400bc03eb176f63009b9e01a862f4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Michel"
+ avatar="http://cdn.libravatar.org/avatar/cf9fdab9aa34af56f769bf584c8e7011"
+ subject="Solution"
+ date="2017-03-11T00:44:18Z"
+ content="""
+I found a relatively simple solution by setting the following in .gitattributes:
+
+```
+* annex.largefiles=(largerthan=0kb)
+```
+
+"""]]
diff --git a/doc/bugs/Empty_files_make_git_status_slow/comment_4_d3a05649e8d7d5d62cc3e80ce0f45fe4._comment b/doc/bugs/Empty_files_make_git_status_slow/comment_4_d3a05649e8d7d5d62cc3e80ce0f45fe4._comment
new file mode 100644
index 0000000000..9c43129ea6
--- /dev/null
+++ b/doc/bugs/Empty_files_make_git_status_slow/comment_4_d3a05649e8d7d5d62cc3e80ce0f45fe4._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-08-27T16:17:32Z"
+ content="""
+Verified to still be the case with current git-annex
+and git 2.18.0.
+
+I suppose one workaround would be to default annex.largefiles to your
+setting. 
+
+But, the user might want to use `git annex export`, which currently exports
+only annexed file, not in-git files. Or there might be a workflow with
+git-annex metadata, which likewise can only be added to annexed files. Such
+a special case by default may be more trouble than it's worth.
+
+I'm guessing that git uses 0 size in the index to indicate it doesn't know
+the stat information for the file, or something like that. Perhaps git
+could be changed to use 0 inode instead.
+"""]]
diff --git a/doc/bugs/Empty_files_make_git_status_slow/comment_5_e2c9b041388685bb2ada57244c1735fd._comment b/doc/bugs/Empty_files_make_git_status_slow/comment_5_e2c9b041388685bb2ada57244c1735fd._comment
new file mode 100644
index 0000000000..d61cb66e04
--- /dev/null
+++ b/doc/bugs/Empty_files_make_git_status_slow/comment_5_e2c9b041388685bb2ada57244c1735fd._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-08-28T16:05:53Z"
+ content="""
+Since it's not clear from the above, git only behaves this way when the
+empty file is unlocked. So `git annex lock` is a good workaround too.
+
+(Also, `git annex export` has since gotten the ability to export
+non-annexed files, for the record.)
+"""]]
diff --git a/doc/bugs/Empty_files_make_git_status_slow/comment_6_d107491ed7ac97c4732dc96707defaf0._comment b/doc/bugs/Empty_files_make_git_status_slow/comment_6_d107491ed7ac97c4732dc96707defaf0._comment
new file mode 100644
index 0000000000..a39d3dc7de
--- /dev/null
+++ b/doc/bugs/Empty_files_make_git_status_slow/comment_6_d107491ed7ac97c4732dc96707defaf0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-05-01T21:07:19Z"
+ content="""
+I'm guessing that, in a v10 repo, this is less of a problem, since
+git-annex uses git's long-running filter-process interface then. So git can
+probably run `git-annex filter-process` once and use it to re-smudge all
+the empty files it (for whatever reason) wants to re-smudge.
+"""]]
diff --git a/doc/bugs/Empty_folders_don__39__t_get_remove.mdwn b/doc/bugs/Empty_folders_don__39__t_get_remove.mdwn
new file mode 100644
index 0000000000..8562f23393
--- /dev/null
+++ b/doc/bugs/Empty_folders_don__39__t_get_remove.mdwn
@@ -0,0 +1,4 @@
+### Please describe the problem.
+When you rename, move or delete a folder (with files in it) the old folder doesn't get deleted in the other clients
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Empty_folders_don__39__t_get_remove/comment_1_9f41638299c214b2ee13f23ab41349da._comment b/doc/bugs/Empty_folders_don__39__t_get_remove/comment_1_9f41638299c214b2ee13f23ab41349da._comment
new file mode 100644
index 0000000000..e32059fb62
--- /dev/null
+++ b/doc/bugs/Empty_folders_don__39__t_get_remove/comment_1_9f41638299c214b2ee13f23ab41349da._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 1"
+ date="2013-12-12T19:16:34Z"
+ content="""
+I can't reproduce this. Tested in direct mode (which I assume you're using, but you didn't say), using both command-line `git annex sync`, and using the assistant. In all cases, when the last file in a directory was removed, the directory was deleted.
+
+Please write back with a version number, and an example showing the problem happening.
+"""]]
diff --git a/doc/bugs/Empty_folders_don__39__t_get_remove/comment_2_35f59adc30fe743221f29bbfecff639b._comment b/doc/bugs/Empty_folders_don__39__t_get_remove/comment_2_35f59adc30fe743221f29bbfecff639b._comment
new file mode 100644
index 0000000000..e471d33664
--- /dev/null
+++ b/doc/bugs/Empty_folders_don__39__t_get_remove/comment_2_35f59adc30fe743221f29bbfecff639b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ subject="Experienced this"
+ date="2016-06-14T22:08:43Z"
+ content="""
+Hi,
+
+I experienced this just now.  Have a git-annex assistant repo set up (so using direct mode).
+
+On one machine, I mv'd entire directories out of the git-annex repo.
+
+The other machine saw the files deleted, but the directories remained.
+
+On the machine on which I mv'd directories out, git-annex actually re-created some of them with symlinks to now-nonexistant hashes!  I have no idea why it did that.
+"""]]
diff --git a/doc/bugs/Empty_folders_don__39__t_get_remove/comment_3_ccc703f8667805ce2886719c57e76ef8._comment b/doc/bugs/Empty_folders_don__39__t_get_remove/comment_3_ccc703f8667805ce2886719c57e76ef8._comment
new file mode 100644
index 0000000000..93bb20f255
--- /dev/null
+++ b/doc/bugs/Empty_folders_don__39__t_get_remove/comment_3_ccc703f8667805ce2886719c57e76ef8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ subject="Version"
+ date="2016-06-14T22:35:59Z"
+ content="""
+Forgot to add: 5.20151208
+"""]]
diff --git a/doc/bugs/Enable__47__paus_syncing_to_remote_ssh_server_with_multiple_directories.mdwn b/doc/bugs/Enable__47__paus_syncing_to_remote_ssh_server_with_multiple_directories.mdwn
new file mode 100644
index 0000000000..823466f65e
--- /dev/null
+++ b/doc/bugs/Enable__47__paus_syncing_to_remote_ssh_server_with_multiple_directories.mdwn
@@ -0,0 +1,19 @@
+What steps will reproduce the problem?
+
+Add two remote repositories to same server using ssh. Each directory is added to repositories list and starts syncing. 
+After both repositories are scanned click on "syncing enabled" to disable syncing for one of the two remote repositories.
+
+What is the expected output? What do you see instead?
+
+Only remote repository which i clicked should stop syncing, but both remote repos start to stop syncing.
+Its also working the other way around (enable -> pause -> enable -> ..)
+
+What version of git-annex are you using? On what operating system?
+
+Version: 4.20130314, Debian
+
+Please provide any additional information below.
+
+I am an "webinterface only" user.
+
+[[!tag /design/assistant moreinfo]]
diff --git a/doc/bugs/Enable__47__paus_syncing_to_remote_ssh_server_with_multiple_directories/comment_1_e8affeca873c2ef73255f8f77e0ac16f._comment b/doc/bugs/Enable__47__paus_syncing_to_remote_ssh_server_with_multiple_directories/comment_1_e8affeca873c2ef73255f8f77e0ac16f._comment
new file mode 100644
index 0000000000..d25a46a98a
--- /dev/null
+++ b/doc/bugs/Enable__47__paus_syncing_to_remote_ssh_server_with_multiple_directories/comment_1_e8affeca873c2ef73255f8f77e0ac16f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-16T21:56:37Z"
+ content="""
+Hmm, I can't quite reproduce this, but I did just fix a bug that, among other manifestations, caused the display of whether syncing is enabled for a remote to be wrong sometimes.
+
+Can you send a copy of your repository's .git/config file to this bug report? (That's `annex/.git/config`)
+"""]]
diff --git a/doc/bugs/Enabling_useConfigOnly_not_honored.mdwn b/doc/bugs/Enabling_useConfigOnly_not_honored.mdwn
new file mode 100644
index 0000000000..13a117fc07
--- /dev/null
+++ b/doc/bugs/Enabling_useConfigOnly_not_honored.mdwn
@@ -0,0 +1,67 @@
+### Please describe the problem.
+
+Git's `user.useConfigOnly` is not honored by git-annex commands that create commits (e.g., `init` or `sync`). 
+
+### What steps will reproduce the problem?
+
+Having not globally set `user.{name,email}`, the following will cause git-annex to ignore said setting and proceed with `$USER` as identity:
+
+    $ git config --global user.useConfigOnly true
+    $ git init annex && cd $_
+    Initialized empty Git repository in /tmp/annex/.git/
+    $ git annex init
+    init  Author identity unknown
+    
+    *** Please tell me who you are.
+    
+    Run
+    
+      git config --global user.email "you@example.com"
+      git config --global user.name "Your Name"
+    
+    to set your account's default identity.
+    Omit --global to set the identity only in this repository.
+    
+    fatal: no email was given and auto-detection is disabled
+    ok
+    (recording state in git...)
+
+Looking at the git-annex branch confirms this:
+
+    $ git log git-annex
+    commit 8eb575828cf52a3c150780d89c22672a51291f46
+    Author: $USER <$USER>
+    Date:   2023-03-29 13:22:44 +0200
+    
+        update
+    
+    commit 0b247e1da51e742bcf7b027aa25fc0d61520270d
+    Author: $USER <$USER>
+    Date:   2023-03-29 13:22:44 +0200
+    
+        branch created
+
+Furthermore, the identity is now even set in the local repository:
+
+    $ git config user.name
+    $USER
+
+Enabling `user.useConfigOnly` should prevent this, making it easier to work with several different identities.
+
+### What version of git-annex are you using? On what operating system?
+
+    git-annex version: 10.20230321-gb624394c7
+    build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+    dependency versions: aws-0.24 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+    operating system: linux x86_64
+    supported repository versions: 8 9 10
+    upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+    local repository version: 10
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, it's great!
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Enabling_useConfigOnly_not_honored/comment_1_4f0e4da06d8c9a9db771e593be1e2608._comment b/doc/bugs/Enabling_useConfigOnly_not_honored/comment_1_4f0e4da06d8c9a9db771e593be1e2608._comment
new file mode 100644
index 0000000000..6644dd83cd
--- /dev/null
+++ b/doc/bugs/Enabling_useConfigOnly_not_honored/comment_1_4f0e4da06d8c9a9db771e593be1e2608._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-04-04T18:34:32Z"
+ content="""
+Yeah, git-annex goes to considerable trouble to make sure it can convince
+git to commit. This is because, when I didn't do that, I was *inundated*
+with bug reports from users with poorly configured systems where git cannot
+guess a default user.name for various reasons.
+
+I'm willing to support user.useConfigOnly, but only to the extent it
+doesn't make me have to deal with all that again.
+
+And I think it's probably unncessary for git-annex to set user.name and
+user.email in the git config ever. It should be able to temporarily override
+them when it needs to do so.
+"""]]
diff --git a/doc/bugs/Enabling_useConfigOnly_not_honored/comment_2_5dede8445ba1c20e9750a30fe29de0b0._comment b/doc/bugs/Enabling_useConfigOnly_not_honored/comment_2_5dede8445ba1c20e9750a30fe29de0b0._comment
new file mode 100644
index 0000000000..fccb89d2b6
--- /dev/null
+++ b/doc/bugs/Enabling_useConfigOnly_not_honored/comment_2_5dede8445ba1c20e9750a30fe29de0b0._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-04-04T19:17:56Z"
+ content="""
+I've made user.useConfigOnly be honored when set.
+
+Turns out it was not practical for git-annex init to not set user.name and
+user.email when that is necessary to get git commit to work. But it now
+avoids setting those when user.useConfigOnly is set.
+"""]]
diff --git a/doc/bugs/Encoding_error_in_webapp.mdwn b/doc/bugs/Encoding_error_in_webapp.mdwn
new file mode 100644
index 0000000000..ee57e8b06c
--- /dev/null
+++ b/doc/bugs/Encoding_error_in_webapp.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+In the webapp, file names with UTF-8 characters are displayed correctly when they are in the queue but not when they are being transferred.
+
+
+### What steps will reproduce the problem?
+
+- Create a file with accented characters (éèà...) in their path
+- Run the webapp :)
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 6.20170612-ge4100fd60e (on Arch Linux)
+
+
+### Please provide any additional information below.
+
+![Screenshot](http://i.imgur.com/xHgdVKc.png)
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Oh yes! I love git-annex :) I've written the hubiC special remote for git-annex, the zsh completion, contributed to the crowdfunding campaigns, and I'm a supporter on Patreon :)
diff --git a/doc/bugs/EvilLinker_needs_to_escape_spaces_in_user_name.mdwn b/doc/bugs/EvilLinker_needs_to_escape_spaces_in_user_name.mdwn
new file mode 100644
index 0000000000..1abe3e6918
--- /dev/null
+++ b/doc/bugs/EvilLinker_needs_to_escape_spaces_in_user_name.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+
+git-annex build on Windows does not complete when user name has a space in it
+
+### What steps will reproduce the problem?
+
+Build git-annex from scratch as described on the Windows page of the guide when running as user Joe Blogs
+
+
+### What version of git-annex are you using? On what operating system?
+
+Windows 7 Prof, Cygwin install on 28/5/2014
+
+### Please provide any additional information below.
+
+The problem arises in escapeDosPaths of EvilLinker: windows usernames can have spaces in them which also need escaping
+
+[[!tag confirmed]]
diff --git a/doc/bugs/EvilLinker_needs_to_escape_spaces_in_user_name/comment_1_6b289221a65a750444b1b5850df3386c._comment b/doc/bugs/EvilLinker_needs_to_escape_spaces_in_user_name/comment_1_6b289221a65a750444b1b5850df3386c._comment
new file mode 100644
index 0000000000..db335239b8
--- /dev/null
+++ b/doc/bugs/EvilLinker_needs_to_escape_spaces_in_user_name/comment_1_6b289221a65a750444b1b5850df3386c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 1"
+ date="2014-05-28T22:29:05Z"
+ content="""
+Unfortunately, this is fairly intractable. It would be more productive to fix the [ghc bug](https://ghc.haskell.org/trac/ghc/ticket/8596) that the EvilLinker works around.
+
+Recommend building in a different directory in the meantime.
+"""]]
diff --git a/doc/bugs/FTBFS_for_the_2nd_day.mdwn b/doc/bugs/FTBFS_for_the_2nd_day.mdwn
new file mode 100644
index 0000000000..b39964410a
--- /dev/null
+++ b/doc/bugs/FTBFS_for_the_2nd_day.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+
+Got the report in the past days that failed to build across all platforms. Looked today:
+
+```
+[274 of 679] Compiling CmdLine.Usage    ( CmdLine/Usage.hs, dist/build/git-annex/git-annex-tmp/CmdLine/Usage.o )
+
+CmdLine/Usage.hs:63:1: error:
+    Duplicate type signatures for `paramRemote'
+    at CmdLine/Usage.hs:61:1-11
+       CmdLine/Usage.hs:63:1-11
+   |
+63 | paramRemote :: String
+   | ^^^^^^^^^^^
+
+CmdLine/Usage.hs:64:1: error:
+    Multiple declarations of `paramRemote'
+    Declared at: CmdLine/Usage.hs:62:1
+                 CmdLine/Usage.hs:64:1
+   |
+64 | paramRemote = "REPOSITORY"
+   | ^^^^^^^^^^^
+```
+
+on Debian, didn't check if other systems are anyhow different, will bounce report with pointers just in case.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/FTBFS_for_the_2nd_day/comment_1_b7278de8f98c9fd96219281d61284461._comment b/doc/bugs/FTBFS_for_the_2nd_day/comment_1_b7278de8f98c9fd96219281d61284461._comment
new file mode 100644
index 0000000000..ec15a2ab6f
--- /dev/null
+++ b/doc/bugs/FTBFS_for_the_2nd_day/comment_1_b7278de8f98c9fd96219281d61284461._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 1"
+ date="2022-10-06T06:21:40Z"
+ content="""
+That seems to be a simple typo where the latter/duplicate definition should be named `paramRepository` instead.
+The following fixes the build:
+
+[[!format diff \"\"\"
+diff --git a/CmdLine/Usage.hs b/CmdLine/Usage.hs
+index f3434d709..65879f7c3 100644
+--- a/CmdLine/Usage.hs
++++ b/CmdLine/Usage.hs
+@@ -60,8 +60,8 @@ paramNumRange :: String
+ paramNumRange = \"NUM|RANGE\"
+ paramRemote :: String
+ paramRemote = \"REMOTE\"
+-paramRemote :: String
+-paramRemote = \"REPOSITORY\"
++paramRepository :: String
++paramRepository = \"REPOSITORY\"
+ paramField :: String
+ paramField = \"FIELD\"
+ paramGlob :: String
+\"\"\"]]
+
+Windows tests are A-OK also.
+"""]]
diff --git a/doc/bugs/FTBFS_for_the_2nd_day/comment_2_05c93396766cb9ac6a596db679519718._comment b/doc/bugs/FTBFS_for_the_2nd_day/comment_2_05c93396766cb9ac6a596db679519718._comment
new file mode 100644
index 0000000000..afe7d6a7eb
--- /dev/null
+++ b/doc/bugs/FTBFS_for_the_2nd_day/comment_2_05c93396766cb9ac6a596db679519718._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-10-06T12:50:01Z"
+ content="""
+Thank you jkniiv! If Joey doesn't fix it soon, I will add that patch. FTR: [an example of a patch PR for our datalad/git-annex build](https://github.com/datalad/git-annex/pull/77).
+"""]]
diff --git a/doc/bugs/FTBFS_for_the_2nd_day/comment_3_0037f0e43383f32b22ee1ba2c98d78f8._comment b/doc/bugs/FTBFS_for_the_2nd_day/comment_3_0037f0e43383f32b22ee1ba2c98d78f8._comment
new file mode 100644
index 0000000000..8e4e5695ac
--- /dev/null
+++ b/doc/bugs/FTBFS_for_the_2nd_day/comment_3_0037f0e43383f32b22ee1ba2c98d78f8._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 3"
+ date="2022-10-06T16:04:41Z"
+ content="""
+You're welcome, Yarik! I try to do my part for git-annex although for medical reasons my personal
+bandwidth is a bit limited (for instance, I don't pretend to grok Haskell much at all except at
+a general functional programming level and I have even trouble with some of the intricacies of git, too).
+However, I felt your last sentence was a small hint/suggestion, so with a small leap of faith I made my first
+contribution to an outside project in the form of a pull request to datalad/git-annex,
+[here](https://github.com/datalad/git-annex/pull/134) . :)
+
+
+"""]]
diff --git a/doc/bugs/FTBFS_on_OSX__47__Windows.mdwn b/doc/bugs/FTBFS_on_OSX__47__Windows.mdwn
new file mode 100644
index 0000000000..d88137e378
--- /dev/null
+++ b/doc/bugs/FTBFS_on_OSX__47__Windows.mdwn
@@ -0,0 +1,42 @@
+### Please describe the problem.
+
+For the past few days consistently
+
+```
+ 496   T Mar 06 GitHub Actions  *-4.4* (4.8K/0) datalad/git-annex daily summary: 14 PASSED, 3 FAILED, 5 INCOMPLETE                                                                   
+ 935   T Mar 05 GitHub Actions  *-4.3* (4.8K/0) datalad/git-annex daily summary: 14 PASSED, 3 FAILED, 5 INCOMPLETE                                                                   
+1471 N T Mar 04 GitHub Actions  *-1.9* (4.8K/0) datalad/git-annex daily summary: 15 PASSED, 2 FAILED, 5 INCOMPLETE                                                                   
+1704   T Mar 03 GitHub Actions  *-0.9* (4.8K/0) datalad/git-annex daily summary: 15 PASSED, 2 FAILED, 5 INCOMPLETE                                                                   
+2619   T Mar 01 GitHub Actions  *-3.1* (6.5K/0) datalad/git-annex daily summary: 30 PASSED                                                                                           
+2935 O T Feb 28 GitHub Actions  *-3.8* (6.5K/0) datalad/git-annex daily summary: 30 PASSED        
+```
+
+[sample build on OSX](https://github.com/datalad/git-annex/actions/runs/4320138939/jobs/7540059666) says
+
+```
+
+Utility/RawFilePath.hs:40:1: error:
+    Could not load module ‘System.Posix.Files.ByteString’
+    It is a member of the hidden package ‘unix-2.7.2.2’.
+    You can run ‘:set -package unix’ to expose it.
+    (Note: this unloads all the modules in the current scope.)
+    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
+   |
+40 | import System.Posix.Files.ByteString
+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Utility/RawFilePath.hs:41:1: error:
+    Could not load module ‘System.Posix.Directory.ByteString’
+    It is a member of the hidden package ‘unix-2.7.2.2’.
+    You can run ‘:set -package unix’ to expose it.
+    (Note: this unloads all the modules in the current scope.)
+    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
+   |
+41 | import qualified System.Posix.Directory.ByteString as D
+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+```
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/FTBFS_on_OSX__47__Windows/comment_1_04e4ec83077eec6af8ce50d6f1b2c71e._comment b/doc/bugs/FTBFS_on_OSX__47__Windows/comment_1_04e4ec83077eec6af8ce50d6f1b2c71e._comment
new file mode 100644
index 0000000000..14f20441e4
--- /dev/null
+++ b/doc/bugs/FTBFS_on_OSX__47__Windows/comment_1_04e4ec83077eec6af8ce50d6f1b2c71e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-08T16:17:53Z"
+ content="""
+Windows was already fixed.
+
+OSX got further than that after some fixes on Monday. I've fixed
+one more build problem on it which may get it to build again.
+"""]]
diff --git a/doc/bugs/FTBFS_since_yesterday_on_linux.mdwn b/doc/bugs/FTBFS_since_yesterday_on_linux.mdwn
new file mode 100644
index 0000000000..da7068dbef
--- /dev/null
+++ b/doc/bugs/FTBFS_since_yesterday_on_linux.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+
+
+thought to check on [another issue test](https://git-annex.branchable.com/todo/standlone__58___growing_number_of_libpcre.so_lookups/) but todays build failed with
+
+```
+FWIW, thought to look into current number but that test didn't run since build failed today due to
+
+```
+[34 of 35] Compiling Build.LinuxMkLibs ( Build/LinuxMkLibs.hs, Build/LinuxMkLibs.o )
+
+Build/LinuxMkLibs.hs:129:17: error:
+    parse error (possibly incorrect indentation or mismatched brackets)
+    |
+129 |                 "arm" ->
+    |                 ^
+make[3]: *** [Makefile:150: Build/Standalone] Error 1
+make[3]: Leaving directory '/home/runner/work/git-annex/git-annex/git-annex-source'
+make[2]: *** [Makefile:158: linuxstandalone] Error 2
+make[2]: Leaving directory '/home/runner/work/git-annex/git-annex/git-annex-source'
+make[1]: *** [debian/rules:24: override_dh_auto_build] Error 2
+make[1]: Leaving directory '/home/runner/work/git-annex/git-annex/git-annex-source'
+make: *** [debian/rules:17: build] Error 2
+dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
+I: FAIL line matches with some context
+Error: Process completed with exit code 1.
+```
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop.mdwn b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop.mdwn
new file mode 100644
index 0000000000..a190b262e7
--- /dev/null
+++ b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop.mdwn
@@ -0,0 +1,56 @@
+### Please describe the problem.
+
+git-annex failed to update the local adjusted branch after `git annex drop` stopped abruptly. In turn, `git annex drop` stopped abruptly because a `git annex copy --from X --to Y` had to be stopped (CTRL-C) because of lack of space.
+
+(Perhaps there are two issues here: `drop` being unable to cope with the unexpected situation, and the adjustment code being unable to cope with the weird stat left by `drop`'s abrupt interruption.)
+
+### What steps will reproduce the problem?
+
+```
+$ git copy -J4 --from X --to Y
+[notice that git-annex starts saying "not enough free space, need 27.87 MB more"]
+[kill process with CTRL-C]
+$ git annex drop dirF/
+drop dirF/a/a1.txt ok
+drop dirF/a/a2.txt ok
+[...]
+error: Your local changes to the following files would be overwritten by checkout:
+	dirF/a/a1.txt
+	dirF/a/a2.txt
+	[...]
+
+Aborting
+
+  Updating adjusted branch failed.
+(recording state in git...)
+$ git status
+HEAD detached at 9d92415fb
+nothing to commit, working tree clean
+$ git annex status
+$ git branch
+* (HEAD detached at 9d92415fb)
+  adjusted/master(unlocked)
+  adjusted/master(unlockpresent)
+  git-annex
+  master
+  synced/master
+```
+
+`dirF/` is the directory whose files were being copied when the process has been stopped with `CTRL-C`.
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 10.20230215-gd24914f2a
+[...]
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+```
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git-annex is too good. It so rarely causes problems that one does not develop the "git-annex troubleshooting muscle". :)
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_1_08b3eafdabe5f60ec2206584dff5d230._comment b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_1_08b3eafdabe5f60ec2206584dff5d230._comment
new file mode 100644
index 0000000000..1380567474
--- /dev/null
+++ b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_1_08b3eafdabe5f60ec2206584dff5d230._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-23T19:26:12Z"
+ content="""
+I assume this is a --hide-missing adjusted branch?
+
+Update: Oh, I see from a forum post that it's --unlock-present actually.
+
+What is the annex.adjustedbranchrefresh git config set to?
+"""]]
diff --git a/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_2_a947f8afde3d7f63fd33b0b7e5998e43._comment b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_2_a947f8afde3d7f63fd33b0b7e5998e43._comment
new file mode 100644
index 0000000000..f5ce8f9aea
--- /dev/null
+++ b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_2_a947f8afde3d7f63fd33b0b7e5998e43._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-03-23T19:35:33Z"
+ content="""
+I was able to reproduce something that looks similar to this without
+needing to interrupt any command:
+
+	joey@darkstar:~/tmp/bench>git clone a b
+	Cloning into 'b'...
+	done.
+	joey@darkstar:~/tmp/bench>cd b
+	joey@darkstar:~/tmp/bench/b>git config annex.adjustedbranchrefresh 1
+	joey@darkstar:~/tmp/bench/b>git annex adjust --unlock-present
+	adjust 
+	Switched to branch 'adjusted/master(unlockpresent)'
+	ok
+	joey@darkstar:~/tmp/bench/b#master(unlockpresent)>ls
+	foo@
+	joey@darkstar:~/tmp/bench/b#master(unlockpresent)>git-annex get
+	get foo (from origin...) 
+	ok                                
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/b#master(unlockpresent)>ls
+	foo
+	joey@darkstar:~/tmp/bench/b#master(unlockpresent)>git-annex drop
+	drop foo ok
+	error: Your local changes to the following files would be overwritten by checkout:
+		foo
+	Please commit your changes or stash them before you switch branches.
+	Aborting
+	
+	  Updating adjusted branch failed.
+	(recording state in git...)
+
+And it was left in a similar detached head status:
+
+	HEAD detached at 2aab85d
+	nothing to commit, working tree clean
+
+This seems be be a bug with the implementation of annex.adjustedbranchrefresh
+"""]]
diff --git a/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_3_c8ce6c9fc35fa6ad5165ecf9a3592c9d._comment b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_3_c8ce6c9fc35fa6ad5165ecf9a3592c9d._comment
new file mode 100644
index 0000000000..28215d4c79
--- /dev/null
+++ b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_3_c8ce6c9fc35fa6ad5165ecf9a3592c9d._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-03-23T19:50:45Z"
+ content="""
+git-annex is what writes that detached HEAD,
+in updateAdjustedBranch. And I've verified that when it fails like this,
+git status shows the file is modified. But of course the modification is
+only that the annex content has been replaced by an annex pointer. Running
+`git add` on the file makes the modification status go away.
+
+And this only happens when annex.adjustedbranchrefresh=1.
+At higher values, it calls Annex.Queue.flush, but at 1 it does not, and so 
+restagePointerFiles does not get called before adjustedBranchRefreshFull.
+(Or at least may not, they're both running as cleanup actions and order is
+not really defined.)
+
+I wonder if there are other situations where modifications can prevent
+checkout of the updated adjusted branch? Eg, what if the user has made some
+other modification to an annexed file? It seems wise for git-annex to
+defend against it in depth, by making sure no crash can leave it in
+detached head state.
+"""]]
diff --git a/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_4_2a4de8981ced7894148ca9a68e5ef60b._comment b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_4_2a4de8981ced7894148ca9a68e5ef60b._comment
new file mode 100644
index 0000000000..76b2779873
--- /dev/null
+++ b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_4_2a4de8981ced7894148ca9a68e5ef60b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="gioele@678b7c03f524f2669b179b603f65352fcc16774e"
+ nickname="gioele"
+ avatar="http://cdn.libravatar.org/avatar/366dbda84e78aff8a8a070622aeb63ce"
+ subject="comment 4"
+ date="2023-03-24T08:13:00Z"
+ content="""
+Thanks for investigating this!
+
+These are the local settings:
+
+	thin = true
+	adjustedbranchrefresh = 1
+
+"""]]
diff --git a/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_5_7b989f777b211f21ca0e9ca681869bff._comment b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_5_7b989f777b211f21ca0e9ca681869bff._comment
new file mode 100644
index 0000000000..9e7aba1e28
--- /dev/null
+++ b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_5_7b989f777b211f21ca0e9ca681869bff._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="gioele@678b7c03f524f2669b179b603f65352fcc16774e"
+ nickname="gioele"
+ avatar="http://cdn.libravatar.org/avatar/366dbda84e78aff8a8a070622aeb63ce"
+ subject="comment 5"
+ date="2023-03-25T08:47:01Z"
+ content="""
+> I wonder if there are other situations where modifications can prevent checkout of the updated adjusted branch?
+
+I clearly remember seeing something similar when a `sync` failed due a non-recoverable network failure. Unfortunately I have no logs from that day.
+
+> It seems wise for git-annex to defend against it in depth, by making sure no crash can leave it in detached head state.
+
+Perhaps also extend `fsck` to automatically recover from such a state? Or at least suggest a couple of possible solutions to the user?
+"""]]
diff --git a/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_6_f9ef22fcfabc6445060b964f08080c76._comment b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_6_f9ef22fcfabc6445060b964f08080c76._comment
new file mode 100644
index 0000000000..b5155705f4
--- /dev/null
+++ b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_6_f9ef22fcfabc6445060b964f08080c76._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-03-28T17:11:53Z"
+ content="""
+Weird, I don't see how a network failure could lead in that direction.
+
+Anyway, [[!commit 038a2600f4cf71294976280c5c29f6710359375f]]
+avoids it with a detached head.
+
+git-annex fsck can't do anything about this because the user may have their
+own reasons to check out a detached head.
+"""]]
diff --git a/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_7_f679af07b798cb4bfae75565dd46e8ed._comment b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_7_f679af07b798cb4bfae75565dd46e8ed._comment
new file mode 100644
index 0000000000..faff098303
--- /dev/null
+++ b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_7_f679af07b798cb4bfae75565dd46e8ed._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="gioele@678b7c03f524f2669b179b603f65352fcc16774e"
+ nickname="gioele"
+ avatar="http://cdn.libravatar.org/avatar/366dbda84e78aff8a8a070622aeb63ce"
+ subject="comment 7"
+ date="2023-04-01T11:06:25Z"
+ content="""
+> I wonder if there are other situations where modifications can prevent checkout of the updated adjusted branch?
+>
+>> I clearly remember seeing something similar when a sync failed due a non-recoverable network failure. Unfortunately I have no logs from that day.
+>
+>>> Weird, I don't see how a network failure could lead in that direction.
+
+All I remember is that the command that was running was `git annex sync --content`.
+
+Perhaps the fact that `annex.alwayscommit = false` was set made a difference.
+
+
+"""]]
diff --git a/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_8_c7c210961b51a87770932f40a9563622._comment b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_8_c7c210961b51a87770932f40a9563622._comment
new file mode 100644
index 0000000000..c07046dbbe
--- /dev/null
+++ b/doc/bugs/Failed_adjusted_branch_update_after_error_in_drop/comment_8_c7c210961b51a87770932f40a9563622._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="gioele@678b7c03f524f2669b179b603f65352fcc16774e"
+ nickname="gioele"
+ avatar="http://cdn.libravatar.org/avatar/366dbda84e78aff8a8a070622aeb63ce"
+ subject="comment 8"
+ date="2023-04-01T11:09:49Z"
+ content="""
+<hr/>
+
+> Anyway, 038a2600f4cf71294976280c5c29f6710359375f avoids it with a detached head.
+
+With git-annex 10.20230329-g30d7f9ad7 I got the following message after checking out `adjusted/master(unlockpresent)` and running `git annex copy --from foo --to bar -J2`:
+
+```
+git-annex: .git/HEAD: openFile: resource busy (file is locked)\"
+```
+
+This message appeared at the very end of the `copy` process.
+
+Regardless of this, everything seems to work just fine.
+
+"""]]
diff --git a/doc/bugs/Failed_move__47__get_over_ssh_in_new_version.mdwn b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version.mdwn
new file mode 100644
index 0000000000..5a55655515
--- /dev/null
+++ b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version.mdwn
@@ -0,0 +1,97 @@
+### Please describe the problem.
+
+Since a couple of days I can't move files to or get files from a remote over ssh.
+
+I'm guessing that it has something to do with the new release 10.20220127 release that I'm using locally, as I haven't changed a single thing in the setup, and now it doesn't work anymore. I also have a different computer with version 6.20180227, and that one can access the remote without any problems.
+
+Maybe it's also that I have an older git-annex version installed on it (again 6.20180227). The remote server is basically an old small ARM processor running on Ubuntu 18.04 using an SSD card, and that's the newest version that's available.
+
+### What steps will reproduce the problem?
+
+The same effect happens when I'm creating a new repository.
+Everything, including syncing works. But as soon as I'm moving files, errors pop up.
+
+```shell
+$ git init
+$ git annex init
+$ echo 123 > file                                                               
+$ git annex add file                                      
+$ git commit -m "added file"
+$ # remotely at host rock64 (details specified in .ssh/config) create a a directory at /mnt/wd8ext/remote-annex and git init it
+$ git remote add wd8ext ssh://rock64/mnt/wd8ext/remote-annex                    
+$ git annex sync                                   
+$ git annex --verbose --debug move --to wd8ext file
+[2022-02-08 21:34:58.211337603] (Utility.Process) process [426973] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2022-02-08 21:34:58.212514973] (Utility.Process) process [426973] done ExitSuccess
+[2022-02-08 21:34:58.212846926] (Utility.Process) process [426974] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2022-02-08 21:34:58.21382918] (Utility.Process) process [426974] done ExitSuccess
+[2022-02-08 21:34:58.214613297] (Utility.Process) process [426975] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..81758130587469be97e82c11cb4fc39ebcab2c35","--pretty=%H","-n1"]
+[2022-02-08 21:34:58.215981386] (Utility.Process) process [426975] done ExitSuccess
+[2022-02-08 21:34:58.217035304] (Utility.Process) process [426976] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2022-02-08 21:34:58.223715442] (Utility.Process) process [426977] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2022-02-08 21:34:58.22483633] (Utility.Process) process [426977] done ExitSuccess
+[2022-02-08 21:34:58.225122771] (Utility.Process) process [426978] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","refs/heads/master"]
+[2022-02-08 21:34:58.226399383] (Utility.Process) process [426978] done ExitSuccess
+[2022-02-08 21:34:58.226786503] (Utility.Process) process [426979] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-files","--stage","-z","--","file"]
+[2022-02-08 21:34:58.22728136] (Utility.Process) process [426980] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2022-02-08 21:34:58.227992286] (Utility.Process) process [426981] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2022-02-08 21:34:58.228323732] (Utility.Process) process [426976] done ExitSuccess
+[2022-02-08 21:34:58.229063353] (Utility.Process) process [426982] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+move file 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+[2022-02-08 21:34:58.232369632] (Utility.Process) process [426984] chat: ssh ["rock64","-T","git-annex-shell 'p2pstdio' '/mnt/wd8ext/remote-annex' '--debug' '73dd11e5-3911-4269-9ef9-5f2796f68dd4' --uuid eea8c03e-1fa2-4998-8c1b-a47fbad2e37e"]
+fatal: Run with no arguments or with -c cmd
+git-annex-shell: git-shell failed
+[2022-02-08 21:34:59.990281774] (Utility.Process) process [426984] done ExitFailure 1
+(unable to check wd8ext) failed
+[2022-02-08 21:34:59.990887594] (Utility.Process) process [426982] done ExitSuccess
+[2022-02-08 21:34:59.991067464] (Utility.Process) process [426981] done ExitSuccess
+[2022-02-08 21:34:59.991183308] (Utility.Process) process [426980] done ExitSuccess
+[2022-02-08 21:34:59.991280532] (Utility.Process) process [426979] done ExitSuccess
+move: 1 failed
+```
+
+### What version of git-annex are you using? On what operating system?
+
+**Locally**
+
+Operating system: Manjaro Linux 21.2.3
+
+```shell
+$ git annex version
+git-annex version: 10.20220127-ge6e60b644                                         
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-9.0.2 http-client-0.7.10 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+```
+
+**Remote at rock64**
+
+Operating System: Ubuntu 18.04.5 LTS
+
+```shell
+$ git annex version
+git-annex version: 6.20180227
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.1 persistent-sqlite-2.6.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+```
+
+
+
+### Please provide any additional information below.
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, everything worked perfectly (using git-annex since at least 2 years).
+
+[[!meta title="improve unclear error message when used with too old git-annex-shell"]]
diff --git a/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_1_13252610f5b05251d1dcdf81f295ae7c._comment b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_1_13252610f5b05251d1dcdf81f295ae7c._comment
new file mode 100644
index 0000000000..73097b4354
--- /dev/null
+++ b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_1_13252610f5b05251d1dcdf81f295ae7c._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-10T19:42:35Z"
+ content="""
+From the NEWS file:
+
+	git-annex (8.20211028) upstream; urgency=medium
+	
+	  This version of git-annex removes support for communicating with git-annex
+	  remotes that have version 6.20180312 or older installed.
+
+So you will need to upgrade your remote.
+
+I'm leaving this bug report open because it currently fails without
+explaining why, and it would be good to indicate that the remote is too old
+if possible. (I am not, however, unsure if it's actually possible to do
+that.)
+"""]]
diff --git a/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_2_ae1807997fe2098f8534d23130039ae4._comment b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_2_ae1807997fe2098f8534d23130039ae4._comment
new file mode 100644
index 0000000000..a14d2d7f35
--- /dev/null
+++ b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_2_ae1807997fe2098f8534d23130039ae4._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="ycp@f118e050dc106530b9cf62ead031e05eef7b1687"
+ nickname="ycp"
+ avatar="http://cdn.libravatar.org/avatar/5cac8fe093b20b23a05c1a54841dfe47"
+ subject="I have the same problem"
+ date="2022-02-16T08:03:05Z"
+ content="""
+Both local and remote git annex has version 10.20220127-ge6e60b644.
+
+Initially both my local and remote repos had version 8.  I used `git annex upgrade` to upgrade them to 9 then 10, but the problem persisted.
+
+I tried running the `git-annex-shell p2pstdio` command in the server shell after sshing in and it worked.
+I also tried a different git-annex-shell command (configlist) remotely from local with `ssh -T`, and it worked too.
+
+But when I do p2pstdio remotely with `ssh -T` I get
+
+```
+fatal: Run with no arguments or with -c cmd
+git-annex-shell: git-shell failed
+```
+
+"""]]
diff --git a/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_3_fcb4b6a62bcee4d2f70c58fb7f270b7a._comment b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_3_fcb4b6a62bcee4d2f70c58fb7f270b7a._comment
new file mode 100644
index 0000000000..ee324fa18f
--- /dev/null
+++ b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_3_fcb4b6a62bcee4d2f70c58fb7f270b7a._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-02-18T15:58:51Z"
+ content="""
+@ycp it is very possible that you also have an older version of git-annex
+installed on the server, in such a way that the newer version is in PATH
+when you log in interactively, but the older version is when you log in
+non-interactively.
+
+See <https://git-annex.branchable.com/tips/get_git-annex-shell_into_PATH/>
+
+Note that "Run with no arguments or with -c cmd" is not a git-annex
+message. It is a message output by git-shell, eg:
+
+> git-shell -c p2pstdio foo
+> fatal: Run with no arguments or with -c cmd
+
+This probably means that git-annex-shell, not understanding the "p2pstdio"
+command, has passed it on to git-shell, which failed like that. Which hints
+very strongly that you do indeed have an old git-annex-shell in PATH at
+that point.
+"""]]
diff --git a/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_4_f2fe8462292a4e80b5df4adeac20ee72._comment b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_4_f2fe8462292a4e80b5df4adeac20ee72._comment
new file mode 100644
index 0000000000..786c401b90
--- /dev/null
+++ b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_4_f2fe8462292a4e80b5df4adeac20ee72._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="ycp@f118e050dc106530b9cf62ead031e05eef7b1687"
+ nickname="ycp"
+ avatar="http://cdn.libravatar.org/avatar/5cac8fe093b20b23a05c1a54841dfe47"
+ subject="comment 4"
+ date="2022-02-19T01:15:23Z"
+ content="""
+Damn you are right - thanks @joey!
+"""]]
diff --git a/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_5_a769702d5d203eb435677bbd423857a6._comment b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_5_a769702d5d203eb435677bbd423857a6._comment
new file mode 100644
index 0000000000..781fce7a2f
--- /dev/null
+++ b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_5_a769702d5d203eb435677bbd423857a6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Soxofaan"
+ avatar="http://cdn.libravatar.org/avatar/2083c64f7bc36bfd8809f15f0036ade1"
+ subject="Same problem"
+ date="2022-06-26T21:53:39Z"
+ content="""
+Same problem here: on my synology NAS I'm stuck at git-annex version 6.20161212  (later releases fail to run) and I recently (blindly) updated git-annex on my macbook with homebrew to 10.20220624 (I don't remember what previous version was installed).
+
+Because upgrading git-annex at the NAS-side is not an option at the moment, I had to downgrade git-annex locally to 8.20211011. This was quite a challenge unfortunately, and I documented it [on my blog](https://www.stefaanlippens.net/git-annex-homebrew-version-woes.html) (in case anybody else might face the same uphill battle)
+"""]]
diff --git a/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_6_8b18048e0ba4341ecef60787855cdac3._comment b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_6_8b18048e0ba4341ecef60787855cdac3._comment
new file mode 100644
index 0000000000..c85f441df7
--- /dev/null
+++ b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_6_8b18048e0ba4341ecef60787855cdac3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-06-28T16:25:34Z"
+ content="""
+I'm sorry this caused you that trouble. But 6.20161212 is really extremely
+old, and supporting the quirks of old versions of git-annex forever in
+current versions is not something I want to take on.
+"""]]
diff --git a/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_7_5c8ac4f42293240cacfb2edceada1a0b._comment b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_7_5c8ac4f42293240cacfb2edceada1a0b._comment
new file mode 100644
index 0000000000..6cab1debd0
--- /dev/null
+++ b/doc/bugs/Failed_move__47__get_over_ssh_in_new_version/comment_7_5c8ac4f42293240cacfb2edceada1a0b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Soxofaan"
+ avatar="http://cdn.libravatar.org/avatar/2083c64f7bc36bfd8809f15f0036ade1"
+ subject="no worries"
+ date="2022-06-30T16:51:50Z"
+ content="""
+No worries, @joey, I fully understand that you sometimes have to make breaking changes. 2016 is indeed really ages ago, but my NAS is currently stuck there.
+My blog post probably comes across more \"complainy\" than I intended. My point is actually that thanks to the \"open\" in open source, I eventually managed to cook up a solution.
+"""]]
diff --git a/doc/bugs/Fails_to_connect_to_newly_added_remote_on_Windows.mdwn b/doc/bugs/Fails_to_connect_to_newly_added_remote_on_Windows.mdwn
new file mode 100644
index 0000000000..3f6a1320e3
--- /dev/null
+++ b/doc/bugs/Fails_to_connect_to_newly_added_remote_on_Windows.mdwn
@@ -0,0 +1,22 @@
+### Please describe the problem.
+
+After adding a new SSH remote with the assistant on Windows, git-annex can't connect the remote.
+
+### What steps will reproduce the problem?
+
+1. On Windows, add a new "Remote server" repository in the webapp.
+2. Use password authentication. The pairing will succeed initially but it will be added as a "metadata only" remote because SSH connections using the new key pair fail.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex 10.20221213-gac824ff96
+
+Installed with the scoop package on Windows.
+
+### Please provide any additional information below.
+
+The problem seems to be that the private key is written with CRLF line endings. I can manually SSH to the remote (using git-annex's key) with the system-installed `ssh`, but Git for Windows rejects the key as invalid until it's converted to LF line endings.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! I've been using git-annex from the command line to manage my music library for years. Now I'm in the middle of replacing my Syncthing usage with git-annex assistant.
diff --git a/doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__.mdwn b/doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__.mdwn
new file mode 100644
index 0000000000..664a808bfa
--- /dev/null
+++ b/doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__.mdwn
@@ -0,0 +1,132 @@
+Under very particular conditions a `git annex drop --force --all` fails in a bare repository on windows with:
+
+```
+git-annex: .\annex\objects\3f7\4a3\XDLRA--refs\XDLRA--refs: DeleteFile "\\\\?\\<BASEDIR>\\<REPODIR>\\annex\\objects\\3f7\\4a3\\XDLRA--refs\\XDLRA--refs": permission denied (Access is denied.)
+```
+
+(`<BASEDIR>` and `<REPODIR>` are put by me to improve readability here and below).
+
+The key reported as "access denied" is in fact present and has the "read-only" flag set.
+
+What makes this strange is that I can reliably trigger this error, or avoid it, with small differences in the command sequence -- differences that, to me, should not impact the ability to drop a key.
+
+Below I am posting two complete command sequences (and the diff between them) for triggering and not triggering the error.
+I edited the logs to make all matching paths uniform, for readability again. The logs are produced by the same unittest under the same runtime conditions. Both logs start by initializing a git repo in a previously non-existing directory. In both cases a `type=directory` special remote is initialized, but once with `exporttree=yes` and once without. The only other difference is that in the `exporttree=yes` case a custom tree is written to the repository (without creating a commit or advancing a branch), and a "fake" `export.log` record is created that claims that this custom tree was exported from "here" to the initialized directory special remote (this change is committed to the git-annex branch). Afterwards the sequence is identical again.
+
+The failure occurs in the simple case, *without* the fake-export, and only on windows. Both scenarios work on linux and macos.
+
+I am using git annex version 8.20211117-gc3af94eff and git version 2.34.1.windows.1 on an up-to-date win10 box. But I am also seeing this behavior on a windows appveyor CI runner (windows 10.0.17763) with 2.33.1.windows.1.
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+# drop-failure
+
+[DBG] Initialize empty Git repository at '<BASEDIR>\<REPODIR>' ['--bare']
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', '-C', '<BASEDIR>\\<REPODIR>', 'init', '--bare'] (cwd=<BASEDIR>\<REPODIR>)
+[DBG] Run ['git', 'config', '-z', '-l', '--show-origin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'config', 'annex.private', 'true'] (cwd=<BASEDIR>\<REPODIR>)
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'init'] (cwd=<BASEDIR>\<REPODIR>)
+[Level 11] stderr|   Detected a filesystem without fifo support.
+[Level 11] stderr|   Disabling ssh connection caching.
+[Level 11] stderr|   Detected a crippled filesystem.
+[DBG] Run ['git', 'config', '-z', '-l', '--show-origin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'annex', 'version', '--raw'] (cwd=None) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'initremote', 'origin', 'type=directory', 'directory=C:\\REMOTE', 'encryption=none', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'config', '-z', '-l', '--show-origin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'cat-file', 'blob', 'git-annex:remote.log'] (cwd=<BASEDIR>\<REPODIR>)
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'fsck', '-f', 'origin', '--fast', '--key', 'XDLRA--refs', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'drop', '--force', '--key', 'XDLRA--refs', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'get', '--key', 'XDLRA--refs', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'contentlocation', 'XDLRA--refs', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'drop', '--force', '--all', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 1
+fatal: CommandError(CommandError: '"git" "-c" "diff.ignoreSubmodules=none" "annex" "drop" "--force" "--all" "-c" "annex.dotfiles=true"' failed with exitcode 1 under <BASEDIR>\<REPODIR> [out: 'drop XDLRA--refs
+failed
+drop XDLRA--refs
+failed'] [err: 'git-annex: .\annex\objects\3f7\4a3\XDLRA--refs\XDLRA--refs: DeleteFile "\\\\?\\<BASEDIR>\\<REPODIR>\\annex\\objects\\3f7\\4a3\\XDLRA--refs\\XDLRA--refs": permission denied (Access is denied.)
+git-annex: .\annex\objects\3f7\4a3\XDLRA--refs\XDLRA--refs: DeleteFile "\\\\?\\<BASEDIR>\\<REPODIR>\\annex\\objects\\3f7\\4a3\\XDLRA--refs\\XDLRA--refs": permission denied (Access is denied.)
+drop: 2 failed'])
+
+# drop-success / exporttree=yes
+
+[DBG] Initialize empty Git repository at '<BASEDIR>\<REPODIR>' ['--bare']
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', '-C', '<BASEDIR>\\<REPODIR>', 'init', '--bare'] (cwd=<BASEDIR>\<REPODIR>)
+[DBG] Run ['git', 'config', '-z', '-l', '--show-origin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'config', 'annex.private', 'true'] (cwd=<BASEDIR>\<REPODIR>)
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'init'] (cwd=<BASEDIR>\<REPODIR>)
+[Level 11] stderr|   Detected a filesystem without fifo support.
+[Level 11] stderr|   Disabling ssh connection caching.
+[Level 11] stderr|   Detected a crippled filesystem.
+[DBG] Run ['git', 'config', '-z', '-l', '--show-origin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'annex', 'version', '--raw'] (cwd=None) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'initremote', 'origin', 'type=directory', 'directory=C:\\REMOTE', 'encryption=none', 'exporttree=yes', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'config', '-z', '-l', '--show-origin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'hash-object', '-w', '--stdin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'update-index', '--add', '--cacheinfo', '120000', 'a4725c5396b9e1abbb67ad1531b30ba5902ccf02', '.datalad/dotgit/refs'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'hash-object', '-w', '--stdin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'update-index', '--add', '--cacheinfo', '120000', '6e67546efb8b9f1a0ded02f07221586c6a93f292', '.datalad/dotgit/repo.zip'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'write-tree'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'hash-object', '-w', '--stdin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'read-tree', 'git-annex'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'update-index', '--add', '--cacheinfo', '100644', '8db4da90bf1b3cd4e9d0b6d079532696e71c1998', 'export.log'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'write-tree'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', 'commit-tree', '-m', 'Fake export', '-p', 'git-annex', '0c8af6e758e0d66d3d0d041c7f3f73f79f0dcab9'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'update-ref', 'refs/heads/git-annex', '9dbd3377a4cca0cded93986a83bb025a0ac15b66'] (cwd=<BASEDIR>\<REPODIR>)
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'cat-file', 'blob', 'git-annex:remote.log'] (cwd=<BASEDIR>\<REPODIR>)
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'fsck', '-f', 'origin', '--fast', '--key', 'XDLRA--refs', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'drop', '--force', '--key', 'XDLRA--refs', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'get', '--key', 'XDLRA--refs', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'contentlocation', 'XDLRA--refs', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'drop', '--force', '--all', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+[DATALAD-ANNEX] drop XDLRA--refs ok
+
+"""]]
+
+And here is the diff between the two sequences  (failure(-) vs success(+)
+
+[[!format diff """
+
+--- annex_remote.txt    2022-01-19 21:25:57.025990250 +0100
++++ export_remote.txt   2022-01-19 21:29:57.262464761 +0100
+@@ -8,17 +8,23 @@
+ [Level 11] stderr|   Detected a crippled filesystem.
+ [DBG] Run ['git', 'config', '-z', '-l', '--show-origin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+ [DBG] Run ['git', 'annex', 'version', '--raw'] (cwd=None) Finished with status 0
+-[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'initremote', 'origin', 'type=directory', 'directory=C:\\REMOTE', 'encryption=none', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'initremote', 'origin', 'type=directory', 'directory=C:\\REMOTE', 'encryption=none', 'exporttree=yes', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+ [DBG] Run ['git', 'config', '-z', '-l', '--show-origin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DBG] Run ['git', 'hash-object', '-w', '--stdin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DBG] Run ['git', 'update-index', '--add', '--cacheinfo', '120000', 'a4725c5396b9e1abbb67ad1531b30ba5902ccf02', '.datalad/dotgit/refs'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DBG] Run ['git', 'hash-object', '-w', '--stdin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DBG] Run ['git', 'update-index', '--add', '--cacheinfo', '120000', '6e67546efb8b9f1a0ded02f07221586c6a93f292', '.datalad/dotgit/repo.zip'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DBG] Run ['git', 'write-tree'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DBG] Run ['git', 'hash-object', '-w', '--stdin'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DBG] Run ['git', 'read-tree', 'git-annex'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DBG] Run ['git', 'update-index', '--add', '--cacheinfo', '100644', '8db4da90bf1b3cd4e9d0b6d079532696e71c1998', 'export.log'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DBG] Run ['git', 'write-tree'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DBG] Run ['git', 'commit-tree', '-m', 'Fake export', '-p', 'git-annex', '0c8af6e758e0d66d3d0d041c7f3f73f79f0dcab9'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'update-ref', 'refs/heads/git-annex', '9dbd3377a4cca0cded93986a83bb025a0ac15b66'] (cwd=<BASEDIR>\<REPODIR>)
+ [DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'cat-file', 'blob', 'git-annex:remote.log'] (cwd=<BASEDIR>\<REPODIR>)
+ [DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'fsck', '-f', 'origin', '--fast', '--key', 'XDLRA--refs', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+ [DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'drop', '--force', '--key', 'XDLRA--refs', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+ [DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'get', '--key', 'XDLRA--refs', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+ [DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'contentlocation', 'XDLRA--refs', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
+-[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'drop', '--force', '--all', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 1
+-fatal: CommandError(CommandError: '"git" "-c" "diff.ignoreSubmodules=none" "annex" "drop" "--force" "--all" "-c" "annex.dotfiles=true"' failed with exitcode 1 under <BASEDIR>\<REPODIR> [out: 'drop XDLRA--refs
+-failed
+-drop XDLRA--refs
+-failed'] [err: 'git-annex: .\annex\objects\3f7\4a3\XDLRA--refs\XDLRA--refs: DeleteFile "\\\\?\\<BASEDIR>\\<REPODIR>\\annex\\objects\\3f7\\4a3\\XDLRA--refs\\XDLRA--refs": permission denied (Access is denied.)
+-git-annex: .\annex\objects\3f7\4a3\XDLRA--refs\XDLRA--refs: DeleteFile "\\\\?\\<BASEDIR>\\<REPODIR>\\annex\\objects\\3f7\\4a3\\XDLRA--refs\\XDLRA--refs": permission denied (Access is denied.)
+-drop: 2 failed'])
++[DBG] Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'drop', '--force', '--all', '-c', 'annex.dotfiles=true'] (cwd=<BASEDIR>\<REPODIR>) Finished with status 0
++[DATALAD-ANNEX] drop XDLRA--refs ok
+
+
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+This observation comes from an effort to implement a git-remote-helper that uses git-annex to enable fetch/push to and from any location that can be reached by any special remote. The fact that git-annex can be used to build things like this is just crazy cool! Thx much!
+
+[[!tag projects/datalad]]
diff --git a/doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__/comment_1_fdad38ba9decc434e0d04a446f0a02e5._comment b/doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__/comment_1_fdad38ba9decc434e0d04a446f0a02e5._comment
new file mode 100644
index 0000000000..db6c3dc959
--- /dev/null
+++ b/doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__/comment_1_fdad38ba9decc434e0d04a446f0a02e5._comment
@@ -0,0 +1,52 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-06-22T16:42:25Z"
+ content="""
+I tried to construct a test case that I can from from these transcripts.
+
+	key=XDLRA--refs
+	mkdir $base/repo
+	cd $base/repo
+	git -c diff.ignoreSubmodules=none -C $base/repo init --bare
+	git config -z -l --show-origin
+	git -c diff.ignoreSubmodules=none config annex.private true
+	git -c diff.ignoreSubmodules=none annex init
+	git config -z -l --show-origin
+	git annex version --raw
+	git -c diff.ignoreSubmodules=none annex initremote origin type=directory directory=$remote encryption=none -c annex.dotfiles=true
+	git config -z -l --show-origin
+	git -c diff.ignoreSubmodules=none cat-file blob git-annex:remote.log
+	git -c diff.ignoreSubmodules=none annex fsck -f origin --fast --key $key -c annex.dotfiles=true
+	git -c diff.ignoreSubmodules=none annex drop --force --key $key -c annex.dotfiles=true
+	git -c diff.ignoreSubmodules=none annex get --key $key -c annex.dotfiles=true
+	git -c diff.ignoreSubmodules=none annex contentlocation $key -c annex.dotfiles=true
+	git -c diff.ignoreSubmodules=none annex drop --force --all -c annex.dotfiles=true
+
+Now, this would normally fail at the fsck step, since no object file exists for
+XDLRA--refs. I suppose that you must have pre-populated the special remote with
+it, somehow, and left that part out. The fsck would then learn that the object
+does exist there.
+
+It seems to me that how you prepopulated it might be a crucial detail, since
+that object file gets copied from the special remote and perhaps something to
+do with its permissions etc are what is later preventing deleting the copy.
+
+You're also using an external backend for whatever reason, and it would
+simplify the test case if that external backend were not needed and it just
+used a built-in backend. Using key=WORM--refs seems like it should behave the
+same, unless your external backend is doing something very strange. If the
+external backend is necessary to reproduce it, I will need some kind of minimal
+version of it.
+
+So, I've tried pre-populating the file in the remote like this:
+
+	mkdir -p $remote/06b/f75/WORM--refs
+	echo hi > $remote/06b/f75/WORM--refs/WORM--refs
+
+With that, I've gotten as far as getting the test case to succeed on linux.
+
+But I don't think it's worth the bother of getting a windows environment set up
+and running these commands on it, without first knowing how you prepopulated
+the special remote with the object file.
+"""]]
diff --git a/doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__/comment_2_cdedb5512dc9c27a88632e963a27a389._comment b/doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__/comment_2_cdedb5512dc9c27a88632e963a27a389._comment
new file mode 100644
index 0000000000..1f1090c353
--- /dev/null
+++ b/doc/bugs/Fails_to_drop_key_on_windows___40__Access_denied__41__/comment_2_cdedb5512dc9c27a88632e963a27a389._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="jasonc"
+ nickname="mail"
+ avatar="http://cdn.libravatar.org/avatar/cb07bdfbe978aa83388d64e08a972eb2"
+ subject="Possible simplified scenario"
+ date="2024-04-03T16:48:04Z"
+ content="""
+Hello, firstly thank you for developing a really useful piece of software.  During my initial experimentation I came across what appears to be a variation of this bug, and think I've distilled it to a minimal reproducible scenario.
+
+Initialise in the usual way on an NTFS partition, then add a directory special remote (no `encryption`, no `importtree` and no `exporttree`):
+<pre>
+    git init
+    git annex init local
+    git annex initremote nextdoor type=directory directory=N:\nextdoordir encryption=none
+</pre>
+
+In my case I then added and committed the files locally, then moved them to the directory special remote and back again:
+<pre>
+    git annex add .
+    git commit --all --message=\"first commit\"
+    git annex move . --to nextdoor
+    git annex move . --from nextdoor
+</pre>
+
+This completes successfully, however repeating the last two steps a second time triggers the `permission denied (Access is denied.)` failure at the start of the bug report.
+
+Going through each part step by step:
+
+* Since NTFS is designated as a \"crippled filesystem\", the annexed objects appear to be read-write by default (no ACL modifications, no ReadOnly attribute).
+* When the files are moved away to the directory special remote (in my test, the same NTFS partition), they pick up a ReadOnly attribute in the new location, so `Archive+Compression` becomes `ReadOnly+Archive+Compression`.
+* When the files are then moved back from the directory special remote, the ReadOnly attribute persists.
+* Repeating the movement then fails, as the file cannot be dropped locally (the UNC path exists, but `DeleteFile` fails).
+
+If I remove the ReadOnly attributes and try again, the move away is successful.  Similarly if I use a networked ext4 location for the directory special remote (and NTFS locally), the same cycle of success then failure can be observed.
+
+Version information: git `git version 2.44.0.windows.1`, annex `git-annex version: 10.20240130-gad8e32c09d3ec866e0c0654cdcd146bf1aefbc5e` (installer from 2024-02-27), Windows 10 22H2
+
+If you require logs or other information, please let me know.
+"""]]
diff --git a/doc/bugs/Failure_to_get_small_files_over_P2P_protocol.mdwn b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol.mdwn
new file mode 100644
index 0000000000..cb0a2b663b
--- /dev/null
+++ b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol.mdwn
@@ -0,0 +1,120 @@
+### Please describe the problem.
+I'm storing lots of recordings from our satellite receiver into a git annex repo for easy syncing to a backup server that's not always switched on. Now, I'm trying to replace this backup server and pulling all data onto my new node. Most files work fine, but there are a bunch of small files that throw an error. In the debug log the GET command seems to use the file's size as offset, resulting in 0 bytes of data, throwing an error
+
+### What steps will reproduce the problem?
+    $ git annex get Documentaires/Oorlogen/20170124_2110_-_CANVAS_HD_-_1945__THE_SAVAGE_PEACE.* --debug
+    [2021-12-19 17:13:10.308043464] process [4214] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+    [2021-12-19 17:13:10.309545353] process [4214] done ExitSuccess
+    [2021-12-19 17:13:10.310048003] process [4215] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+    [2021-12-19 17:13:10.312009938] process [4215] done ExitSuccess
+    [2021-12-19 17:13:10.328167499] process [4216] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--","Documentaires/Oorlogen/20170124_2110_-_CANVAS_HD_-_1945__THE_SAVAGE_PEACE.eit","Documentaires/Oorlogen/20170124_2110_-_CANVAS_HD_-_1945__THE_SAVAGE_PEACE.ts","Documentaires/Oorlogen/20170124_2110_-_CANVAS_HD_-_1945__THE_SAVAGE_PEACE.ts.ap","Documentaires/Oorlogen/20170124_2110_-_CANVAS_HD_-_1945__THE_SAVAGE_PEACE.ts.cuts","Documentaires/Oorlogen/20170124_2110_-_CANVAS_HD_-_1945__THE_SAVAGE_PEACE.ts.meta","Documentaires/Oorlogen/20170124_2110_-_CANVAS_HD_-_1945__THE_SAVAGE_PEACE.ts.sc"]
+    [2021-12-19 17:13:10.328598306] process [4217] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+    [2021-12-19 17:13:10.328861515] process [4218] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+    [2021-12-19 17:13:10.329676569] process [4219] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+    get Documentaires/Oorlogen/20170124_2110_-_CANVAS_HD_-_1945__THE_SAVAGE_PEACE.ts.meta [2021-12-19 17:13:10.341285273] process [4221] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+    [2021-12-19 17:13:10.342469002] process [4221] done ExitSuccess
+    [2021-12-19 17:13:10.342787111] process [4222] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+    [2021-12-19 17:13:10.343851119] process [4222] done ExitSuccess
+    [2021-12-19 17:13:10.34416143] process [4223] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..33675b567939705c283bd955c2c7de13e15ba28a","--pretty=%H","-n1"]
+    [2021-12-19 17:13:10.345389634] process [4223] done ExitSuccess
+    [2021-12-19 17:13:10.345949274] process [4224] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+    [2021-12-19 17:13:10.346209136] process [4225] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+    (from garage...) 
+    [2021-12-19 17:13:10.349782417] process [4226] read: ssh ["-o","BatchMode=true","-S",".git/annex/ssh/root@10.19.20.147","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","root@10.19.20.147","true"]
+    [2021-12-19 17:13:11.687712914] process [4226] done ExitSuccess
+    [2021-12-19 17:13:11.68875019] process [4231] chat: ssh ["root@10.19.20.147","-S",".git/annex/ssh/root@10.19.20.147","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","git-annex-shell 'p2pstdio' '/opt/Sat' '--debug' 'b22315b4-77f0-4f46-aed3-fe376b350ab9' --uuid dd4c0b26-2331-4133-82bf-1888753c3268"]
+    [2021-12-19 17:13:12.407472022] [ssh connection Just 4231] [ThreadId 4] P2P < AUTH-SUCCESS dd4c0b26-2331-4133-82bf-1888753c3268
+    [2021-12-19 17:13:12.40779008] [ssh connection Just 4231] [ThreadId 4] P2P > VERSION 1
+    [2021-12-19 17:13:12.423477213] [ssh connection Just 4231] [ThreadId 4] P2P < VERSION 1
+    [2021-12-19 17:13:12.423831707] [ssh connection Just 4231] [ThreadId 4] P2P > GET 165 Documentaires/Oorlogen/20170124_2110_-_CANVAS_HD_-_1945__THE_SAVAGE_PEACE.ts.meta SHA256E-s164--41ece560a700c3a1f2c1a28f37399c6cf139dde68f8c97ff9f7e10ac1080c746.ts.meta
+    [2021-12-19 17:13:28.731615325] [ThreadId 4] P2P < GET 165 Documentaires/Oorlogen/20170124_2110_-_CANVAS_HD_-_1945__THE_SAVAGE_PEACE.ts.meta SHA256E-s164--41ece560a700c3a1f2c1a28f37399c6cf139dde68f8c97ff9f7e10ac1080c746.ts.meta
+    [2021-12-19 17:13:28.796144027] [ThreadId 4] P2P > DATA 0
+    [2021-12-19 17:13:28.796944343] [ThreadId 4] P2P > VALID
+    [2021-12-19 17:13:12.518895068] [ssh connection Just 4231] [ThreadId 4] P2P < DATA 0
+    [2021-12-19 17:13:12.521393464] [ssh connection Just 4231] [ThreadId 4] P2P < VALID
+    [2021-12-19 17:13:12.522008877] [ssh connection Just 4231] [ThreadId 4] P2P > FAILURE
+
+      transfer failed
+    [2021-12-19 17:13:12.524417003] process [4224] done ExitSuccess
+    [2021-12-19 17:13:12.525545594] process [4225] done ExitSuccess
+
+    [2021-12-19 17:13:12.526125714] [ssh connection Just 4231] [ThreadId 4] P2P > GET 165 Documentaires/Oorlogen/20170124_2110_-_CANVAS_HD_-_1945__THE_SAVAGE_PEACE.ts.meta SHA256E-s164--41ece560a700c3a1f2c1a28f37399c6cf139dde68f8c97ff9f7e10ac1080c746.ts.meta
+    [2021-12-19 17:13:28.807577749] [ThreadId 4] P2P < FAILURE
+    [2021-12-19 17:13:28.812468221] [ThreadId 4] P2P < GET 165 Documentaires/Oorlogen/20170124_2110_-_CANVAS_HD_-_1945__THE_SAVAGE_PEACE.ts.meta SHA256E-s164--41ece560a700c3a1f2c1a28f37399c6cf139dde68f8c97ff9f7e10ac1080c746.ts.meta
+    [2021-12-19 17:13:28.812746153] [ThreadId 4] P2P > DATA 0
+    [2021-12-19 17:13:28.812854143] [ThreadId 4] P2P > VALID
+    [2021-12-19 17:13:12.533471116] [ssh connection Just 4231] [ThreadId 4] P2P < DATA 0
+    [2021-12-19 17:13:12.534230317] [ssh connection Just 4231] [ThreadId 4] P2P < VALID
+    [2021-12-19 17:13:12.534505767] [ssh connection Just 4231] [ThreadId 4] P2P > FAILURE
+
+      transfer failed
+
+      Unable to access these remotes: garage
+    [2021-12-19 17:13:12.537799752] process [4235] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+    [2021-12-19 17:13:12.538818173] process [4236] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+    [2021-12-19 17:13:28.820206504] [ThreadId 4] P2P < FAILURE
+
+      No other repository is known to contain the file.
+    failed
+    [2021-12-19 17:13:12.55009435] process [4235] done ExitSuccess
+    [2021-12-19 17:13:12.550952683] process [4236] done ExitSuccess
+    [2021-12-19 17:13:12.551390026] process [4219] done ExitSuccess
+    [2021-12-19 17:13:12.551709257] process [4218] done ExitSuccess
+    [2021-12-19 17:13:12.551975888] process [4217] done ExitSuccess
+    [2021-12-19 17:13:12.552194866] process [4216] done ExitSuccess
+    [2021-12-19 17:13:12.561312091] process [4238] read: ssh ["-O","stop","-S","root@10.19.20.147","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
+    [2021-12-19 17:13:12.569198309] process [4238] done ExitSuccess
+    git-annex: get: 1 failed
+
+As you can see the offset in the p2p get command is 165, which is exactly the file size of what it's supposed to be getting:
+
+    -r-xr-xr-x 1 root root 165 Apr 29  2020 .git/annex/objects/5V/x8/SHA256E-s164--41ece560a700c3a1f2c1a28f37399c6cf139dde68f8c97ff9f7e10ac1080c746.ts.meta/SHA256E-s164--41ece560a700c3a1f2c1a28f37399c6cf139dde68f8c97ff9f7e10ac1080c746.ts.meta
+
+
+
+### What version of git-annex are you using? On what operating system?
+On the old server:
+
+    $ git annex version 
+    git-annex version: 8.20200908
+    build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+    dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso hook external
+    operating system: linux x86_64
+    supported repository versions: 8
+    upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+    local repository version: 8
+
+On the new server:
+
+    $ git annex version
+    git-annex version: 8.20210223
+    build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+    dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+    operating system: linux x86_64
+    supported repository versions: 8
+    upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+    local repository version: 8
+
+Both servers are debian.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I've been using git annex for years now, some periods more intensively than others. The only data I've lost I can only blame on my own stupidity, even after a terminal disk failure I managed to recover almost everything with a reinject. I'm still using it entirely cli though, no assistants or gui for me.
+
+[[!meta title="corrupted tmp file can prevent getting an object"]]
+
+> [[fixed|done]] (the related issue that I discovered in comment #1
+> specifically) --[[Joey]]
diff --git a/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_1_72a8b9b6ed582dad36301cb9beece2f8._comment b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_1_72a8b9b6ed582dad36301cb9beece2f8._comment
new file mode 100644
index 0000000000..f77ba20200
--- /dev/null
+++ b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_1_72a8b9b6ed582dad36301cb9beece2f8._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-12-26T16:17:43Z"
+ content="""
+It looks rather like the full content of the file may already have been
+downloaded, in `.git/annex/tmp/` which is why it "resumes"
+from the end of the file.
+
+But this does not necessarily look like a protocol problem. The protocol
+handles no more data being sent. The failure is on the receiving side,
+after it's received the data it indicates an overall failure.
+
+One reason this could be happening is if the file in `.git/annex/tmp/` is
+corrupted, so verifying the completed download fails.
+
+I tried two experiements. First, I populated `.git/annex/tmp/` with a copy of
+the annexed object file from the other repository. Then `git-annex get`
+succeeded, and looked this this:
+
+	[2021-12-26 11:25:32.364107322] (P2P.IO) [ThreadId 4] P2P < GET 30 foo SHA256E-s30--8559e95c5b77e5e577466959d83097039d0d3f2b6a7e18b2fd5df0188ef648c6
+	[2021-12-26 11:25:32.365992548] (P2P.IO) [ThreadId 4] P2P > DATA 0
+	[2021-12-26 11:25:32.366778465] (P2P.IO) [ThreadId 4] P2P > VALID
+	[2021-12-26 11:25:32.394964731] (P2P.IO) [ThreadId 4] P2P < SUCCESS
+
+Next, I did the same, but corrupted the tmp file. With that I reproduced
+your problem exactly.
+
+So, I suggest you try deleting files in `.git/annex/tmp/` and get them again.
+
+I think that git-annex should probably try to recover from this by,
+when verification of a downloaded file fails, deleting the tmp file.
+But that will need some more thought.
+"""]]
diff --git a/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_2_53970994816f1de9816e3496fdf0ef71._comment b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_2_53970994816f1de9816e3496fdf0ef71._comment
new file mode 100644
index 0000000000..2fdb5f6c4c
--- /dev/null
+++ b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_2_53970994816f1de9816e3496fdf0ef71._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="tim@5431dd39464df207b7d46d3cf1bc74c82123ac68"
+ nickname="tim"
+ avatar="http://cdn.libravatar.org/avatar/967c2815f001d24b5f9f33300c03ba6f"
+ subject="Found the issue"
+ date="2022-01-03T08:25:05Z"
+ content="""
+Hi Joey,
+
+Thank you for having a look at this, but we can put this one under \"my own stupidity\". The files that give these errors are apparently only status files which get rewritten every time you play a recording, so they continuously get rewritten, get \"git annex add\"ed with a cron job, but don't always get pushed before they get overwritten, so yeah, it's not unexpected that some of these may get lost at some point.
+Still no real data lost though, but errors like these worry me enough to file a bug report.
+
+regards,
+Tim
+"""]]
diff --git a/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_3_4c359c12d5c61351484dfcb2f5547222._comment b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_3_4c359c12d5c61351484dfcb2f5547222._comment
new file mode 100644
index 0000000000..3ac6afe830
--- /dev/null
+++ b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_3_4c359c12d5c61351484dfcb2f5547222._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-01-03T17:25:03Z"
+ content="""
+Err, unless you have `annex.thin` set, once you `git-annex add` a file,
+it should not be possible for it be overwritten in a way that loses the
+annexed copy of it.
+"""]]
diff --git a/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_4_1e286c1506fc542df85c6158a8ec3d1c._comment b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_4_1e286c1506fc542df85c6158a8ec3d1c._comment
new file mode 100644
index 0000000000..3d948e5205
--- /dev/null
+++ b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_4_1e286c1506fc542df85c6158a8ec3d1c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tim@5431dd39464df207b7d46d3cf1bc74c82123ac68"
+ nickname="tim"
+ avatar="http://cdn.libravatar.org/avatar/967c2815f001d24b5f9f33300c03ba6f"
+ subject="well, yes"
+ date="2022-01-04T11:28:33Z"
+ content="""
+Well, yes, it does, if you start discarding disks after you've done a git annex pull on a temp usb repo and then again to the new server... Hence, my own stupidity.
+"""]]
diff --git a/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_5_c667e4d4899925a5484c94256044f6ee._comment b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_5_c667e4d4899925a5484c94256044f6ee._comment
new file mode 100644
index 0000000000..260d2f191a
--- /dev/null
+++ b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_5_c667e4d4899925a5484c94256044f6ee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-01-04T15:22:47Z"
+ content="""
+Ah, I see. :)
+
+I am going to leave this bug open, since the corrupted tmp file problem I
+found is a real problem, though not actually your problem.
+"""]]
diff --git a/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_6_5ed6591954aeafe6c99ae152f4f4ad67._comment b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_6_5ed6591954aeafe6c99ae152f4f4ad67._comment
new file mode 100644
index 0000000000..08dc1ba5e3
--- /dev/null
+++ b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_6_5ed6591954aeafe6c99ae152f4f4ad67._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-01-07T16:12:20Z"
+ content="""
+Current thinking on deleting corrupted tmp files: If a download succeeds,
+and verification then fails, the whole file content has been downloaded,
+and is corrupt. So it would be ok to always delete it then, as far as p2p
+transfers goes.
+
+For other remotes, the same is often true. The only exceptions are like
+rsync and bittorrent, which can recover from corruption on retry. But,
+I don't think either rsync or bittorrent will usually write corrupt data
+to a file anyway. They would catch over-the-wire corruption with rolling
+checksums etc. So, it seems like a verification should never fail after
+a successful rsync or bittorrent download. Unless the disk corrupted the
+data in the meantime. Which is an unlikely situation, and not one that it's
+really necessary for git-annex to recover from with optimal efficiency.
+
+... Oh interesting.. It already is supposed to do that, in
+getViaTmpFromDisk. It seems, what is happening is the transfer fails
+when all the file content is present, and so it never gets to the point of
+verifying it, let alone deleting it.
+"""]]
diff --git a/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_7_247db3d1c03b207296e97975a3554756._comment b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_7_247db3d1c03b207296e97975a3554756._comment
new file mode 100644
index 0000000000..438e5cd155
--- /dev/null
+++ b/doc/bugs/Failure_to_get_small_files_over_P2P_protocol/comment_7_247db3d1c03b207296e97975a3554756._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-01-07T16:34:42Z"
+ content="""
+This seems to be a reversion caused by incremental verification. In
+P2P.Annex it does incremental verification, and so it notices that the temp
+file is corrupted. So, the transfer fails, and the temp file is left
+behind.
+
+So I suppose the fix is that, whenever doing incremental verification,
+also delete the temp file when it fails.
+"""]]
diff --git a/doc/bugs/Files_disappear_from_locally_paired_annexes_when_edited.mdwn b/doc/bugs/Files_disappear_from_locally_paired_annexes_when_edited.mdwn
new file mode 100644
index 0000000000..16109fb237
--- /dev/null
+++ b/doc/bugs/Files_disappear_from_locally_paired_annexes_when_edited.mdwn
@@ -0,0 +1,36 @@
+**What steps will reproduce the problem?**
+
+Create two annexes from the command line on two separate machines:
+
+    mkdir ~/Files.annex
+    cd ~/Files.annex
+    git init
+    git annex init
+    git annex untrust .
+    git annex direct
+
+Add remote to each one pointing to the other:
+
+    git remote add [remote] [remote hostname]:Files.annex
+
+Start assistant on both repos:
+
+    git annex assistant
+
+Fill one repository with a few text files, and wait for them to propagate.
+
+Edit one of the text files using vim, and save.
+
+**What is the expected output? What do you see instead?**
+
+Edited file should remain in the repo, but a significant portion of the time, the file disappeared from the repo in which it was edited (the file is present and properly synced on the other repo).
+
+**What version of git-annex are you using? On what operating system?**
+
+git-annex 4.20130323, Mac OS X on the repo where the file was edited, Arch Linux for the other paired repo.
+
+**Please provide any additional information below.**
+
+I have observed this problem setting up the repos through the webapp as well, so I don't think it is related to setting up the repos manually. I think the way vim is writing the files seems to be tickling a race condition (both command-line vim and MacVim produce the behavior). I started trying to work around it by switching to emacs to edit those files, and the files haven't disappeared from the edited repo (so far at least).
+
+[[!tag /design/assistant moreinfo]]
diff --git a/doc/bugs/Files_disappear_from_locally_paired_annexes_when_edited/comment_1_bdc97db9dc9954331e4c400baf9e5541._comment b/doc/bugs/Files_disappear_from_locally_paired_annexes_when_edited/comment_1_bdc97db9dc9954331e4c400baf9e5541._comment
new file mode 100644
index 0000000000..46b3332714
--- /dev/null
+++ b/doc/bugs/Files_disappear_from_locally_paired_annexes_when_edited/comment_1_bdc97db9dc9954331e4c400baf9e5541._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-08T17:14:23Z"
+ content="""
+When you say that the file \"disappeared from the repo\", do you mean that the actual file is no longer present on disk, or that the file is present on disk, but is no longer staged in the git repository?
+
+Version 4.20130405 fixes a bug that can result in the latter behavior.
+"""]]
diff --git a/doc/bugs/Files_recorded_with_other_file__39__s_checksums.mdwn b/doc/bugs/Files_recorded_with_other_file__39__s_checksums.mdwn
new file mode 100644
index 0000000000..55dd7aa5e0
--- /dev/null
+++ b/doc/bugs/Files_recorded_with_other_file__39__s_checksums.mdwn
@@ -0,0 +1,102 @@
+### Please describe the problem.
+
+I have a special remote "source" set up as type=directory importtree=yes.
+
+I pulled it into one repo in which none of the files were wanted.  So far so good.  I cloned that repo to a second, archive, repo.  git annex sync worked (but took 2 hours).  Then I did `git annex get --auto`, most of the files came through OK.  But some said things like this:
+
+```
+get Pictures/.dtrash/info/IMG_2979_v1-e9dced7b.dtrashinfo (from source...) (checksum...)
+  verification of content failed
+
+  Unable to access these remotes: source
+
+  No other repository is known to contain the file.
+failed
+```
+
+(Both repos are unlocked via adjust --unlocked)
+
+Upon looking at the file in the repo where it wasn't wanted, I saw this:
+
+```
+$ cat IMG_2979_v1-e9dced7b.dtrashinfo 
+/annex/objects/SHA256E-s144--cec5c7b6a9d97344e374e8395e02b74350678147ff65d6df091f5115cf18bf72
+```
+
+Interesting.  So, in the source directory:
+
+```
+$ sha256sum IMG_2979_v1-e9dced7b.dtrashinfo 
+aca3ed7243def7a0bd5fcad542c66841b8e7d2a670b4cafe749eb27e032d8975  IMG_2979_v1-e9dced7b.dtrashinfo
+```
+
+That's not a match at all.  Well, OK then:
+
+```
+$ sha256sum * | grep cec5c7
+cec5c7b6a9d97344e374e8395e02b74350678147ff65d6df091f5115cf18bf72  IMG_2981_v1-5fc99c7a.dtrashinfo
+```
+
+Yikes.  So for IMG_2979_v1-e9dced7b.dtrashinfo, git-annex recorded a checksum that belonged to IMG_2981_v1-5fc99c7a.dtrashinfo.  Well then, what is this other file recorded as, back in the git-annex repo?
+
+```
+$ cat IMG_2981_v1-5fc99c7a.dtrashinfo 
+/annex/objects/SHA256E-s144--cec5c7b6a9d97344e374e8395e02b74350678147ff65d6df091f5115cf18bf72
+```
+
+OK, so two files that were not identical in the source directory got recorded with an identical checksum in git-annex somehow.  And, when they were attempted to be imported via `git annex get --auto`, this at least was detected there.
+
+In this .dtrash/info directory, 436 files out of 719 were not loaded by `git annex get`, presumably due to this issue.
+
+In this directory, the source files were ranging in size from 140 to 227 bytes.
+
+In a companion directory, .dtrash/files, 24 out of 719 files exhibited this issue.  These files tended to be larger, but one that was 495MB triggered it also.
+
+I have not yet seen it outside .dtrash, but it will be many hours until this get process completes fully, as it needs to copy about 1TB of data.
+
+In case you are wondering if there is a race condition with .dtrash: no.  The only application that writes to it isn't running, and the last time a file was modified in there was over a year ago.  Also the content of the .info files is just JSON and a corresponding filename embedded in them, so it is very clear that the files on the filesystem are correct and the calculated checksums at issue here were never correct.
+
+### What steps will reproduce the problem?
+
+I have laid that out as best I can above.
+
+### What version of git-annex are you using? On what operating system?
+
+8;.20210223 on Debian
+
+### Please provide any additional information below.
+
+Assistant is not being used.
+
+Setup:
+
+```
+REPO=Pictures
+cd /acrypt/git-annex/repos
+mkdir $REPO
+cd $REPO
+git init
+git config annex.thin true
+git annex init 'local hub'
+git annex wanted . "include=* and exclude=$REPO/*"
+
+# Now initialize things.
+touch mtree
+git annex add mtree
+git annex sync
+git annex adjust --unlock
+
+git annex initremote source type=directory directory=/acrypt/git-annex/bind-ro/$REPO importtree=yes encryption=none
+
+git annex enableremote source directory=/acrypt/git-annex/bind-ro/$REPO
+git config remote.source.annex-readonly true
+git config remote.source.annex-tracking-branch main:$REPO
+git config annex.securehashesonly true
+git config annex.genmetadata true
+git config annex.diskreserve 100M
+```
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+> [[done]] since this has pretty strongly been confirmed to be a bug that
+> was already fixed in a newer git-annex version. --[[Joey]] 
diff --git a/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_1_05e3e33e1ca2361546dbe08c6bd476d6._comment b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_1_05e3e33e1ca2361546dbe08c6bd476d6._comment
new file mode 100644
index 0000000000..68ab41bb32
--- /dev/null
+++ b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_1_05e3e33e1ca2361546dbe08c6bd476d6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 1"
+ date="2022-09-05T01:14:53Z"
+ content="""
+Update: This also occurred in other directories, with some video files from 2018.  One directory contains 1945 files, and another 21 files.  I'm not finding an obvious pattern to the issue.
+"""]]
diff --git a/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_2_0735ed4187e23ddea6bd0aa408451942._comment b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_2_0735ed4187e23ddea6bd0aa408451942._comment
new file mode 100644
index 0000000000..b5693f342d
--- /dev/null
+++ b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_2_0735ed4187e23ddea6bd0aa408451942._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 2"
+ date="2022-09-05T09:35:18Z"
+ content="""
+You really should upgrade to the latest version.
+"""]]
diff --git a/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_3_06b7be9e651e528440a054ef43f7142f._comment b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_3_06b7be9e651e528440a054ef43f7142f._comment
new file mode 100644
index 0000000000..4c6f3bd6bd
--- /dev/null
+++ b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_3_06b7be9e651e528440a054ef43f7142f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-09-05T17:48:49Z"
+ content="""
+Concur that you need to upgrade. In particular, this seems likely to have
+been fixed by [[!commit 3e2f1f73cbc5fc10475745b3c3133267bd1850a7]].
+
+If so, the two files in the source directory will turn out to have the
+same size and mtime, so were considered to have the same content identifier
+when importing from a directory with your version of git-annex.
+"""]]
diff --git a/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_4_bc9cf721f8087cb91954cc2435376bc2._comment b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_4_bc9cf721f8087cb91954cc2435376bc2._comment
new file mode 100644
index 0000000000..c58aceed35
--- /dev/null
+++ b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_4_bc9cf721f8087cb91954cc2435376bc2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 4"
+ date="2022-09-05T18:29:31Z"
+ content="""
+Thanks!  I noticed some changes in v10 around checksumming, so I got it started with v10 last night.  It's still running, but I'll update you when it's done.  Appreciate it!
+"""]]
diff --git a/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_5_8f0bbd819b95dfa97e2f4848e08a787a._comment b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_5_8f0bbd819b95dfa97e2f4848e08a787a._comment
new file mode 100644
index 0000000000..a9cf6f5cf1
--- /dev/null
+++ b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_5_8f0bbd819b95dfa97e2f4848e08a787a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 5"
+ date="2022-09-05T18:44:01Z"
+ content="""
+Following up a bit - I had blown away the repos that were in use for this, but based on what I logged here, I can confirm that at least the files I mentioned with conflicts had the same size and mtime.
+
+I may yet want to use ignoreinodes=yes.  Eventually I want to be feeding git-annex from zfs clones to get a guaranteed stable source at any given moment, and I'm not really sure what that will do to inodes (it should, at minimum, have a different device number, I would assume).
+"""]]
diff --git a/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_6_17a0864cec6f28a0445998f3c5fc7f10._comment b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_6_17a0864cec6f28a0445998f3c5fc7f10._comment
new file mode 100644
index 0000000000..fde8ede9d7
--- /dev/null
+++ b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_6_17a0864cec6f28a0445998f3c5fc7f10._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 6"
+ date="2022-09-05T22:01:24Z"
+ content="""
+With the latest v10 git, I'm seeing some things like this:
+
+```
+get Pictures/0_New/5/20-03-31 21-12-12 0184.mp4 (from source...)   file content has changed
+
+
+  Unable to access these remotes: source
+
+  No other repository is known to contain the file.
+failed
+```
+
+Now, the file content really had not chnaged.  That file looks like this:
+
+```
+$ cat 20-03-31\ 21-12-12\ 0184.mp4 
+/annex/objects/SHA256E-s55936559--0d418e4bb62cfc7ef5b053f8b622dd72794781a49931abc41bb9499acaf51b09.mp4
+```
+
+And on-disk, the file is:
+
+```
+$ sha256sum 20-03-31\ 21-12-12\ 0184.mp4 
+0d418e4bb62cfc7ef5b053f8b622dd72794781a49931abc41bb9499acaf51b09  20-03-31 21-12-12 0184.mp4
+```
+
+So, this is something different, but it's producing the same result (files left around not checked out).  I obvserve that in .dtrash/info, the directory that had such a problem before, zero files now do.  But in .dtrash/files, the problem seems to be triggered by a file that has a duplicate somewhere in the source repository (with the same sha256sum).  I was able to find another file with the same sha256sum as that one in the same directory.  In the origin repo, in which the given files were not present and it's using unlock-present, all instances of the file contained a broken symlink to the appropriate target.  In the repo in question here, which uses plain unlock and is on NTFS (though Linux is the OS accessing it), I'm having this problem.
+ 
+"""]]
diff --git a/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_7_d480e85683f0418441f26c7d61c4af02._comment b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_7_d480e85683f0418441f26c7d61c4af02._comment
new file mode 100644
index 0000000000..0d3ab40e70
--- /dev/null
+++ b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_7_d480e85683f0418441f26c7d61c4af02._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-09-09T18:50:43Z"
+ content="""
+Well, it seems that you have confirmed that the bug you were seeing is the
+known and already fixed problem involving files that had the same size and
+mtime.
+
+I suggest filing a new bug report for the other problem, since it does not
+seem like the same problem. I don't like to have to re-read long threads
+about unrelated problems to tease out the "current" problem than a bug
+report is talking about. 1 bug report per problem saves everyone time and
+confusion.
+"""]]
diff --git a/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_8_80763c1c40acdf0915134182d15e4fd8._comment b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_8_80763c1c40acdf0915134182d15e4fd8._comment
new file mode 100644
index 0000000000..2011fd6c1c
--- /dev/null
+++ b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_8_80763c1c40acdf0915134182d15e4fd8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 8"
+ date="2022-09-10T00:37:45Z"
+ content="""
+Sure.  Created the new bug at [[/bugs/Files_recorded_with_other_file__39__s_checksums/]].  Thanks Joey!  I don't know how to close this one or I would.
+"""]]
diff --git a/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_9_7c3180616e40b49fc5ddf398d23d0201._comment b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_9_7c3180616e40b49fc5ddf398d23d0201._comment
new file mode 100644
index 0000000000..3cb53063c7
--- /dev/null
+++ b/doc/bugs/Files_recorded_with_other_file__39__s_checksums/comment_9_7c3180616e40b49fc5ddf398d23d0201._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 9"
+ date="2022-09-10T00:38:17Z"
+ content="""
+OK, so that link didn't work.  I'll try <https://git-annex.branchable.com/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/>
+"""]]
diff --git a/doc/bugs/Files_unaccessible_in___40__some__63____41___views_on_a_crippled_filesystem.mdwn b/doc/bugs/Files_unaccessible_in___40__some__63____41___views_on_a_crippled_filesystem.mdwn
new file mode 100644
index 0000000000..ac047ab1f6
--- /dev/null
+++ b/doc/bugs/Files_unaccessible_in___40__some__63____41___views_on_a_crippled_filesystem.mdwn
@@ -0,0 +1,80 @@
+(note: this is a more clear version of a previously reported bug. sorry if this breaks bug-reporting etiquette, but the title was incredibly unclear)
+
+### Please describe the problem.
+In a v6 repository on a FAT filesystem, the view `/=*` replaces locally available files with placeholders normally used for unavailable files. 
+
+### What steps will reproduce the problem?
+[[!format sh """
+[leo60228@digitaleo:~]$ fallocate -l $((1024*1024*1024*2)) demo.img
+
+[leo60228@digitaleo:~]$ mkfs.vfat demo.img 
+mkfs.fat 4.1 (2017-01-24)
+
+[leo60228@digitaleo:~]$ mkdir demo
+
+[leo60228@digitaleo:~]$ sudo mount -o loop,uid=${UID},gid=$(id -g $UID) demo.img demo
+
+[leo60228@digitaleo:~]$ cd demo
+
+[leo60228@digitaleo:~/demo]$ git init
+Initialized empty Git repository in /home/leo60228/demo/.git/
+
+[leo60228@digitaleo:~/demo]$ git commit --allow-empty -m 'init'
+[master (root-commit) 8dc8e0a] init
+
+[leo60228@digitaleo:~/demo]$ git annex init
+init  
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Enabling direct mode.
+ok
+(recording state in git...)
+
+[leo60228@digitaleo:~/demo]$ mkdir subdir
+
+[leo60228@digitaleo:~/demo]$ echo hi > subdir/file
+
+[leo60228@digitaleo:~/demo]$ git annex upgrade
+upgrade (v5 to v6...) (scanning for unlocked files...)
+ok
+(recording state in git...)
+
+[leo60228@digitaleo:~/demo]$ git annex add subdir/
+add subdir/file ok
+(recording state in git...)
+
+[leo60228@digitaleo:~/demo]$ git commit -m 'add file'
+[adjusted/master(unlocked) 0e870b3] add file
+ 1 file changed, 1 insertion(+)
+ create mode 100644 subdir/file
+
+[leo60228@digitaleo:~/demo]$ ls subdir/
+file
+
+[leo60228@digitaleo:~/demo]$ cat subdir/file 
+hi
+
+[leo60228@digitaleo:~/demo]$ git-annex view /=*
+view (searching...) 
+Switched to branch 'views/_=_'
+ok
+
+[leo60228@digitaleo:~/demo]$ ls subdir/
+file_%subdir%
+
+[leo60228@digitaleo:~/demo]$ cat subdir/file_%subdir% 
+../.git/annex/objects/zQ/MQ/SHA256E-s3--98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4/SHA256E-s3--98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+6.20180427 on NixOS. Installed via `nix-env -iA nixos.gitAndTools.git-annex`.
+
+### Please provide any additional information below.
+The repository is in v6 mode, because I was having strange issues with normal git commands such as `git commit` in direct mode. I know I needed to proxy the command, but are *all* git commands supposed to be broken in direct mode?
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Yep! I already use it to move files between my laptop's HDD and SSD, and to copy files between my many SD cards. I was trying this to see if I could not have to scroll as far on my 3D printer's menu.
diff --git a/doc/bugs/FreeBSD_patches.mdwn b/doc/bugs/FreeBSD_patches.mdwn
new file mode 100644
index 0000000000..ef9310d9b3
--- /dev/null
+++ b/doc/bugs/FreeBSD_patches.mdwn
@@ -0,0 +1,25 @@
+diff --git a/git-annex.cabal b/git-annex.cabal
+index 0a50878eb..63d79bde9 100644
+--- a/git-annex.cabal
++++ b/git-annex.cabal
+@@ -396,8 +396,7 @@ Executable git-annex
+     GHC-Options: -O0
+ 
+   -- Avoid linking with unused dynamic libaries.
+-  -- (Only tested on Linux).
+-  if os(Linux)
++  if os(Linux) || os(freebsd)
+     GHC-Options: -optl-Wl,--as-needed
+ 
+   if (os(windows))
+@@ -517,7 +516,7 @@ Executable git-annex
+             Other-Modules: Utility.DirWatcher.Kqueue
+ 
+   if flag(Dbus)
+-    if (os(linux))
++    if os(linux) || os(freebsd)
+       Build-Depends: dbus (>= 0.10.7), fdo-notify (>= 0.3)
+       CPP-Options: -DWITH_DBUS -DWITH_DESKTOP_NOTIFY -DWITH_DBUS_NOTIFICATIONS
+       Other-Modules: Utility.DBus
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/FreeBSD_patches/comment_1_3473c3d4207a8387d962366dd1aa88b1._comment b/doc/bugs/FreeBSD_patches/comment_1_3473c3d4207a8387d962366dd1aa88b1._comment
new file mode 100644
index 0000000000..59e265ba00
--- /dev/null
+++ b/doc/bugs/FreeBSD_patches/comment_1_3473c3d4207a8387d962366dd1aa88b1._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="7thyearold@339ab97e59cee5c85e14df94a5059f251a143e65"
+ nickname="7thyearold"
+ avatar="http://cdn.libravatar.org/avatar/bec2e77ce4d1f264936115aa20c6b194"
+ subject="comment 1"
+ date="2022-05-30T09:52:11Z"
+ content="""
+```diff
+diff --git a/git-annex.cabal b/git-annex.cabal
+index 0a50878eb..63d79bde9 100644
+--- a/git-annex.cabal
++++ b/git-annex.cabal
+@@ -396,8 +396,7 @@ Executable git-annex
+     GHC-Options: -O0
+ 
+   -- Avoid linking with unused dynamic libaries.
+-  -- (Only tested on Linux).
+-  if os(Linux)
++  if os(Linux) || os(freebsd)
+     GHC-Options: -optl-Wl,--as-needed
+ 
+   if (os(windows))
+@@ -517,7 +516,7 @@ Executable git-annex
+             Other-Modules: Utility.DirWatcher.Kqueue
+ 
+   if flag(Dbus)
+-    if (os(linux))
++    if os(linux) || os(freebsd)
+       Build-Depends: dbus (>= 0.10.7), fdo-notify (>= 0.3)
+       CPP-Options: -DWITH_DBUS -DWITH_DESKTOP_NOTIFY -DWITH_DBUS_NOTIFICATIONS
+       Other-Modules: Utility.DBus
+```
+"""]]
diff --git a/doc/bugs/FreeBSD_patches/comment_2_ba8df081ebf5cbbb5561aa48343e4fcd._comment b/doc/bugs/FreeBSD_patches/comment_2_ba8df081ebf5cbbb5561aa48343e4fcd._comment
new file mode 100644
index 0000000000..130579e350
--- /dev/null
+++ b/doc/bugs/FreeBSD_patches/comment_2_ba8df081ebf5cbbb5561aa48343e4fcd._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-05-31T17:07:27Z"
+ content="""
+Have you actually verified that git-annex on freebsd, when compiled with
+dbus support, is able to use it for anything? It expects to be speaking
+to udisks2 to get notifications of things being mounted, and to
+network-manager or wicd or systemd-networkd to get noticiations of
+networking changes. I don't know if any of those are used on freebsd.
+
+I have applied the --as-needed patch
+
+In general, when sending patches, you really need to provide an explanation
+of why the change is the right change to make..
+"""]]
diff --git a/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos.mdwn b/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos.mdwn
new file mode 100644
index 0000000000..c882dbe2d1
--- /dev/null
+++ b/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos.mdwn
@@ -0,0 +1,16 @@
+Hi, git-annex Team.
+
+I want to ask you this issue.
+GIN is not recognized as a git-annex enabled repository when using the HTTPS protocol.  
+I cloned a GIN repository with HTTPS protocol and then did `git annex init` on the cloned local repository, but it is not recognized as a git annex-enabled remote.   
+I checked the .git/config file and it says annex-ignore=true. 
+
+![image](https://user-images.githubusercontent.com/91708725/182578704-c04fdb60-5b6a-4faf-8869-04914723c27f.png)<br>
+Because of this, git annex copy --to [GIN remote repository] is not possible with HTTPS protocol.  
+Is git-annex capable of copying content over the HTTPS protocol?  
+If there are any mistakes in my understanding please let me know.
+
+sincerely yours,  
+Rino Mizuguchi
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_1_8a27545e11b3d9e4e45aea4c9a5c9af4._comment b/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_1_8a27545e11b3d9e4e45aea4c9a5c9af4._comment
new file mode 100644
index 0000000000..6112e946e2
--- /dev/null
+++ b/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_1_8a27545e11b3d9e4e45aea4c9a5c9af4._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-04T16:22:09Z"
+ content="""
+If you're using GIN, perhaps you're also using Datalad. Have you read 
+[their documentation](http://handbook.datalad.org/en/0.13_a/basics/101-139-gin.html)
+on using it with git-annex?
+
+Part of that documentation that seems likely to be especially
+relevant is [here](http://handbook.datalad.org/en/0.13_a/basics/101-139-gin.html#access):
+
+> Important: Take the URL in the browser, not the copy-paste URL
+> Please note that you need to use the browser URL of the repository,
+> not the copy-paste URL on the upper right hand side of the repository if you want
+> to get anonymous HTTPS access! The two URLs differ only by a .git extension:
+> 
+>    Brower bar: `https://gin.g-node.org/<user>/<repo>`
+> 
+>    Copy-paste “HTTPS clone”: `https://gin.g-node.org/<user>/<repo>.git`
+> 
+> A dataset cloned from `https://gin.g-node.org/<user>/<repoy>.git`, however, can not retrieve annexed files!
+
+The reason is that git-annex needs to construct urls to download
+files from the repo, starting with git's `config` file.
+Looking at the sample repo <https://gin.g-node.org/adswa/DataLad-101>,
+an url based on that works <https://gin.g-node.org/adswa/DataLad-101/config>,
+but its web page suggests cloning the url 
+<https://gin.g-node.org/adswa/DataLad-101.git>, and
+<https://gin.g-node.org/adswa/DataLad-101.git/config> does not work.
+
+How does git manage to clone the latter url then? Well,
+the http server is speaking the git smart http protocol.
+So git makes requests like `https://gin.g-node.org/adswa/DataLad-101.git/info/refs?service=git-upload-pack`
+which do work. But that protocol is not useful for git-annex, so it
+needs the url where the actual files in the repository can be downloaded,
+not the url where the smart http protocol is spoken.
+
+There is not generally a way to discover one url from the other url
+(removing ".git" might work in this case, but not in other cases).
+So unfortunately you will need to remember to use the right url.
+"""]]
diff --git a/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_2_3e2f01eaaf717710a08ba092856af193._comment b/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_2_3e2f01eaaf717710a08ba092856af193._comment
new file mode 100644
index 0000000000..0cc75496da
--- /dev/null
+++ b/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_2_3e2f01eaaf717710a08ba092856af193._comment
@@ -0,0 +1,75 @@
+[[!comment format=mdwn
+ username="rinomizu5@5ead4c82685c65d7717dbd5591b80425036ae9e3"
+ nickname="rinomizu5"
+ avatar="http://cdn.libravatar.org/avatar/62478823018c68821064febcda7e5d4f"
+ subject="Additional Questions: git annex copy failed"
+ date="2022-08-08T10:31:04Z"
+ content="""
+Thanks for the advice, joey.  
+ 
+I understand that the URL in the browser bar needs to be set to remote.  
+Then, after modifying the remote URL, I am trying to sync the contents of the git annex file to GIN using the https protocol.  
+But git annex copy command failed.  
+<pre>(base) <font color=\"#8AE234\"><b>mizuguchi@ubuntu</b></font>:<font color=\"#729FCF\"><b>~/https</b></font>$ git annex copy --to=origin test2.txt
+copy test2.txt (not found) failed
+copy: 1 failed
+</pre>  
+I checked the origin remote has annex-uuid, and it's the same as uuid of [annex] in https://gin.g-node.org/ivis-mizuguchi/https/config.   
+I would like to know why git annex cannot find test2.txt.  
+
+### The version of the tool used in my environment is below.  
+- git version 2.24.0  
+- git-annex version: 8.20211123+git12-g02e3756bd-1~ndall+1  
+
+### The repository in GIN
+[https://gin.g-node.org/ivis-mizuguchi/https](https://gin.g-node.org/ivis-mizuguchi/https)
+
+### I have done the following process and failed.  
+1. Create a repository named [https](https://gin.g-node.org/ivis-mizuguchi/https) in GIN with initialization.  And set the repository to public.   
+2. git clone https://gin.g-node.org/ivis-mizuguchi/https  
+3. cd https  
+4. git annex init  
+5. echo \"test\" > test.txt  
+6. git annex add test.txt  
+7. git commit -m \"test\"  
+8. git annex sync origin  
+9. echo \"test\" > test2.txt  
+10. git annex add 'test2.txt'  
+11. git commit -m 'test2'  
+12. git push origin master  
+13. git annex copy --to=origin test2.txt
+  <pre>(base) <font color=\"#8AE234\"><b>mizuguchi@ubuntu</b></font>:<font color=\"#729FCF\"><b>~/https</b></font>$ git annex copy --to=origin test2.txt
+copy test2.txt (not found) failed
+copy: 1 failed
+</pre>
+14. cat .git/config
+  <pre>(base) <font color=\"#8AE234\"><b>mizuguchi@ubuntu</b></font>:<font color=\"#729FCF\"><b>~/https</b></font>$ cat .git/config
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+[remote &quot;origin&quot;]
+	url = https://gin.g-node.org/ivis-mizuguchi/https
+	fetch = +refs/heads/*:refs/remotes/origin/*
+	annex-uuid = c7a50190-9146-44de-8f1d-288551fa32e3
+[branch &quot;master&quot;]
+	remote = origin
+	merge = refs/heads/master
+[annex]
+	uuid = 80f0adc3-3144-4bba-a288-09a9ab009cef
+	version = 8
+[filter &quot;annex&quot;]
+	smudge = git-annex smudge -- %f
+	clean = git-annex smudge --clean -- %f
+</pre>
+
+Any advice would be appreciated.  
+Sincerely,   
+Rino Mizuguchi
+
+
+
+
+
+"""]]
diff --git a/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_3_07460def4969896c87e8696955740fa9._comment b/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_3_07460def4969896c87e8696955740fa9._comment
new file mode 100644
index 0000000000..1bb92766de
--- /dev/null
+++ b/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_3_07460def4969896c87e8696955740fa9._comment
@@ -0,0 +1,75 @@
+[[!comment format=mdwn
+ username="rinomizu5@5ead4c82685c65d7717dbd5591b80425036ae9e3"
+ nickname="rinomizu5"
+ avatar="http://cdn.libravatar.org/avatar/62478823018c68821064febcda7e5d4f"
+ subject="Additional Questions: git annex copy failed"
+ date="2022-08-08T10:31:26Z"
+ content="""
+Thanks for the advice, joey.  
+ 
+I understand that the URL in the browser bar needs to be set to remote.  
+Then, after modifying the remote URL, I am trying to sync the contents of the git annex file to GIN using the https protocol.  
+But git annex copy command failed.  
+<pre>(base) <font color=\"#8AE234\"><b>mizuguchi@ubuntu</b></font>:<font color=\"#729FCF\"><b>~/https</b></font>$ git annex copy --to=origin test2.txt
+copy test2.txt (not found) failed
+copy: 1 failed
+</pre>  
+I checked the origin remote has annex-uuid, and it's the same as uuid of [annex] in https://gin.g-node.org/ivis-mizuguchi/https/config.   
+I would like to know why git annex cannot find test2.txt.  
+
+### The version of the tool used in my environment is below.  
+- git version 2.24.0  
+- git-annex version: 8.20211123+git12-g02e3756bd-1~ndall+1  
+
+### The repository in GIN
+[https://gin.g-node.org/ivis-mizuguchi/https](https://gin.g-node.org/ivis-mizuguchi/https)
+
+### I have done the following process and failed.  
+1. Create a repository named [https](https://gin.g-node.org/ivis-mizuguchi/https) in GIN with initialization.  And set the repository to public.   
+2. git clone https://gin.g-node.org/ivis-mizuguchi/https  
+3. cd https  
+4. git annex init  
+5. echo \"test\" > test.txt  
+6. git annex add test.txt  
+7. git commit -m \"test\"  
+8. git annex sync origin  
+9. echo \"test\" > test2.txt  
+10. git annex add 'test2.txt'  
+11. git commit -m 'test2'  
+12. git push origin master  
+13. git annex copy --to=origin test2.txt
+  <pre>(base) <font color=\"#8AE234\"><b>mizuguchi@ubuntu</b></font>:<font color=\"#729FCF\"><b>~/https</b></font>$ git annex copy --to=origin test2.txt
+copy test2.txt (not found) failed
+copy: 1 failed
+</pre>
+14. cat .git/config
+  <pre>(base) <font color=\"#8AE234\"><b>mizuguchi@ubuntu</b></font>:<font color=\"#729FCF\"><b>~/https</b></font>$ cat .git/config
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+[remote &quot;origin&quot;]
+	url = https://gin.g-node.org/ivis-mizuguchi/https
+	fetch = +refs/heads/*:refs/remotes/origin/*
+	annex-uuid = c7a50190-9146-44de-8f1d-288551fa32e3
+[branch &quot;master&quot;]
+	remote = origin
+	merge = refs/heads/master
+[annex]
+	uuid = 80f0adc3-3144-4bba-a288-09a9ab009cef
+	version = 8
+[filter &quot;annex&quot;]
+	smudge = git-annex smudge -- %f
+	clean = git-annex smudge --clean -- %f
+</pre>
+
+Any advice would be appreciated.  
+Sincerely,   
+Rino Mizuguchi
+
+
+
+
+
+"""]]
diff --git a/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_4_f97de485f97d8016a5ab4e276799d230._comment b/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_4_f97de485f97d8016a5ab4e276799d230._comment
new file mode 100644
index 0000000000..d2d44cd9cd
--- /dev/null
+++ b/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_4_f97de485f97d8016a5ab4e276799d230._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-08-08T15:27:21Z"
+ content="""
+Well, that is a different problem than the problem you reported, isn't it?
+You seem to have shown that git-annex does in fact recognize your GIN
+remote as a git-annex repo.
+
+git-annex does not support uploading files to a git repo on GIN using http.
+
+The datalad documentation says to add a remote using the ssh url of the GIN
+repository, which git-annex can store files on. See 
+<http://handbook.datalad.org/en/0.13_a/basics/101-139-gin.html#publishing-your-dataset-to-gin>
+
+Without using datalad, the equivilant commands would be something like:
+
+	git remote add gin git@gin.g-node.org:/ivis-mizuguchi/https.git
+	git-annex copy --to gin
+
+---
+
+So this leaves the question of why git-annex tries to do a http request
+when you ask it to copy the content to the http repo. That http request
+failing is what results in the "(not found)" message.
+
+Looks like that is due to `git-annex copy` checking to see if the content
+exists on the remote. It does not. So it ought to try to send it,
+which would fail with a better "copying to non-ssh repo not supported" error message.
+However, intstead it displays the error.
+
+I've fixed this bug, and now it fails with this message:
+
+	copy test3.txt (to origin...) 
+	  copying to non-ssh repo not supported
+"""]]
diff --git a/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_5_cf4130cb932d3d884e605d7c6447e61e._comment b/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_5_cf4130cb932d3d884e605d7c6447e61e._comment
new file mode 100644
index 0000000000..dba4af574b
--- /dev/null
+++ b/doc/bugs/GIN_is_not_recognized_as_a_git-annex_enabled_repos/comment_5_cf4130cb932d3d884e605d7c6447e61e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="rinomizu5@5ead4c82685c65d7717dbd5591b80425036ae9e3"
+ nickname="rinomizu5"
+ avatar="http://cdn.libravatar.org/avatar/62478823018c68821064febcda7e5d4f"
+ subject="comment 5"
+ date="2022-08-09T00:33:55Z"
+ content="""
+Thank you joey for the additional help.  
+
+I see that I need to use the SSH protocol to upload the file contents to GIN with git annex.  
+And I also understand why it showed (not found).
+
+I appreciate your advice.
+RIno Mizuguchi
+"""]]
diff --git a/doc/bugs/GPG_passphrase_repeated_prompt.mdwn b/doc/bugs/GPG_passphrase_repeated_prompt.mdwn
new file mode 100644
index 0000000000..56b2bba4ed
--- /dev/null
+++ b/doc/bugs/GPG_passphrase_repeated_prompt.mdwn
@@ -0,0 +1,25 @@
+#### What steps will reproduce the problem?
+
+1. Create a new repository with a directory
+2. Add files
+3. Select "Store your data in the cloud" with the "Remote server" option
+4. Enter host, user, directory
+5. Select "Use an encrypted rsync repository on the server" (Will there be an option for unencrypted later?)
+6. GPG Passphrase prompt comes up for every file
+
+#### What is the expected output? What do you see instead?
+
+I expect to enter a passphase once and then it will sync all files with the remote server.
+
+Instead, it begins syncing the files to the server but prompts for a GPG passphase for every single file.
+
+#### What version of git-annex are you using? On what operating system?
+
+3.20121017 precompiled binary on Arch Linux
+
+#### Please provide any additional information below.
+
+Not sure if I'm just missing a setting for GPG, but I would think I should only need to use the web app to configure the remote server.
+
+[[!tag /design/assistant]]
+[[!tag confirmed]]
diff --git a/doc/bugs/GPG_passphrase_repeated_prompt/comment_1_6ef1c9725befc84ad57bce196ef630ef._comment b/doc/bugs/GPG_passphrase_repeated_prompt/comment_1_6ef1c9725befc84ad57bce196ef630ef._comment
new file mode 100644
index 0000000000..016ecb9945
--- /dev/null
+++ b/doc/bugs/GPG_passphrase_repeated_prompt/comment_1_6ef1c9725befc84ad57bce196ef630ef._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.194"
+ subject="you should install a gpg agent"
+ date="2012-10-31T17:39:53Z"
+ content="""
+A gpg agent will cache your passphrase. It is beyond the scope of the git-annex package to provide one (though it does bundle gpg), but it should be easy to install gpg-agent on your distribution.
+
+That's all that's needed for normal git-annex use, but the assistant does seem to have a larger problem in this area, since it can need to unlock a remote's key at any time to sync files from it. Since a separate
+process is spawned for each transfer, this defeats git-annex's normal in-process caching of encryption keys of remotes. So I think it needs to unlock any encrypted special remotes at startup, or when first accessing them, and pass the cached keys to the transfer processes it spawns. This is now on my todo list.
+
+However, none of the special remotes set up by the assistant will use
+password protected gpg keys, even when it's using encryption it's using a
+non-password protected shared key. So only encrypted special remotes set up
+at the command line cause this problem.
+"""]]
diff --git a/doc/bugs/Get_crashes_when_remote_contains_non-english_chars.mdwn b/doc/bugs/Get_crashes_when_remote_contains_non-english_chars.mdwn
new file mode 100644
index 0000000000..fe6098f754
--- /dev/null
+++ b/doc/bugs/Get_crashes_when_remote_contains_non-english_chars.mdwn
@@ -0,0 +1,107 @@
+Hi,
+
+### Please describe the problem.
+I'm trying to set up a git-annex repo for my books/technical papers to have easy access to them on my desktop and laptop. I'm using a centralized server (following [this guide](https://git-annex.branchable.com/tips/centralized_git_repository_tutorial/on_your_own_server/)) to make it easy to sync between my machines.
+
+The issue is however that sqlite crashes when I'm trying to get a file from my server. See the log further down for the error message. I'm suspecting it is due to the repo on my server is named `Böcker` (swedish name for books). It does work if I'm cloning it locally on my server. E.g.
+
+[[!format sh """
+$ ssh server
+$ git clone /mnt/Valhalla/Böcker books
+$ cd books
+$ git annex init
+init  ok
+(recording state in git...)
+$ git annex get facklitteratur/rapporter/143-rods.pdf
+get facklitteratur/rapporter/143-rods.pdf (from origin...) 
+ok                                
+(recording state in git...)
+"""]]
+
+And if I use the `ssh://server/~/books` as a remote it works fine.
+
+### What steps will reproduce the problem?
+[[!format sh """
+$ ssh server
+server$ mkdir /tmp/Böcker
+server$ cd /tmp/Böcker
+server$ git init
+server$ git annex init
+server$ dd if=/dev/zeo of=foo bs=4k count=1
+server$ git annex add foo
+server$ git commit -m "Add foo"
+server$ exit
+$ git clone ssh://server/tmp/Böcker /tmp/Böcker
+$ cd Böcker
+$ git annex init
+$ git annex get foo
+"""]]
+Note that `foo` need to have some size hence the use of `dd`, just doing `touch foo` did not trigger the issue for me.
+
+### What version of git-annex are you using? On what operating system?
+On my desktop:
+[[!format sh """
+$ git annex version
+git-annex version: 10.20240227
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.23 bloomfilter-2.0.1.2 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.2.5 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+"""]]
+
+Running Guix with linux kernel 6.6.18
+
+On my server:
+[[!format sh """
+$ git annex version
+git-annex version: 10.20240227-gbee3abab14f99f3e3d981d8255ca0dd4ff124a84
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24 bloomfilter-2.0.1.2 crypton-0.34 DAV-1.3.4 feed-1.3.2.1 ghc-9.2.8 http-client-0.7.15 persistent-sqlite-2.13.1.0 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+"""]]
+Running Arch Linux with kernel 6.7.9-arch1-1
+
+### Please provide any additional information below.
+Here is the error message I get without any changes to the config (I can silence the warning by enabling annex.sshcaching).
+[[!format sh """
+⎣plattfot@desktop Böcker⎦ git annex get facklitteratur/rapporter/143-rods.pdf
+get facklitteratur/rapporter/143-rods.pdf (from origin...) 
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+git-annex: sqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform open "/mnt/Valhalla/B\65533\65533cker/.git/annex/keysdb/db".
+p2pstdio: 1 failed
+
+  Lost connection (fd:19: hGetChar: end of file)
+
+  Transfer failed
+
+  Unable to access these remotes: origin
+
+  Maybe add some of these git remotes (git remote add ...):
+  	8c92de49-1a89-4870-8186-b0099ad84be6 -- plattfot@server:~/books
+failed
+get: 1 failed
+
+# End of transcript or log.
+"""]]
+
+Note that this was run after I tested to create a repo with the name books.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sadly no, I manage to hit this on my first try of git-annex.  But I have known about git-annex for a few years, never found a good use for it in my workflow. As I've been using Syncthing for bigger files and that has been working ok.  But with that you pretty much get all or nothing and conflicts are no fun to resolve.  With my books I want to have my .bib file in git but somehow sync the files. I did not want to put everything in a normal git repo as the books directory takes about 64GB. After looking around I remembered git-annex and reading the walkthrough it seems to be a perfect fit! The killer feature in my opinion is that I can specify what files to sync. Which will be handy on my laptop as I don't really want to use up 64GB just so I can read one or two papers.
+
+I'm not giving up on this that easily. Worst case I'll just rename my repo on my server to Books.
+
+Thank you for all the hours developing this software!
+
diff --git a/doc/bugs/Get_gpg_subkey_id_used_for_encryption.mdwn b/doc/bugs/Get_gpg_subkey_id_used_for_encryption.mdwn
new file mode 100644
index 0000000000..174480b0e7
--- /dev/null
+++ b/doc/bugs/Get_gpg_subkey_id_used_for_encryption.mdwn
@@ -0,0 +1,20 @@
+### Please describe the problem.
+
+When you encrypt something to a master key, gpg actually encrypts to its corresponding encryption subkey, but the id of the master key gets recorded in the remote information. It is useful to be able to see the actual subkey id to make sure everything is encrypted as expected in a multi-subkey setup.
+
+### What steps will reproduce the problem?
+
+1. Have a master key with two encryption subkeys
+2. Create a remote with `hybrid` encryption with `keyid` set to the key’s email address or master key id
+3. Use `git annex enableremote keyid+=` and the `!` suffix to add the second encryption key.
+4. Try to use `git annex info` to see which subkeys can be used for decryption.
+
+
+### What version of git-annex are you using? On what operating system?
+
+7.20181211
+
+
+### Please provide any additional information below.
+
+I managed to do this for myself by thaking the `cypher` from `remote.log`, decoding base64 and running it through `gpg --list-packets`, but, I guess, it would be nicer to have an easy way to do this: maybe some flag for `git annex info` to do this dance for me, or even just record the subkey in `remote.log`.
diff --git a/doc/bugs/Get_gpg_subkey_id_used_for_encryption/comment_1_2cbdc33f22d18b8ea25473d361e591eb._comment b/doc/bugs/Get_gpg_subkey_id_used_for_encryption/comment_1_2cbdc33f22d18b8ea25473d361e591eb._comment
new file mode 100644
index 0000000000..ce80fe609f
--- /dev/null
+++ b/doc/bugs/Get_gpg_subkey_id_used_for_encryption/comment_1_2cbdc33f22d18b8ea25473d361e591eb._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-02-07T17:57:01Z"
+ content="""
+If you use "keyid!" to specify a subkey, it is shown by git-annex info:
+
+	joey@darkstar:/tmp/bob>git annex initremote d type=directory directory=../d encryption=pubkey keyid='B38389A117065459!'
+	initremote d (encryption setup) (to gpg keys: B38389A117065459!) ok
+	(recording state in git...)
+	joey@darkstar:/tmp/bob>git annex info d | grep encryption
+	encryption: pubkey (to gpg keys: B38389A117065459!)
+
+So I don't see a bug here?
+"""]]
diff --git a/doc/bugs/Get_gpg_subkey_id_used_for_encryption/comment_2_81f2725bf6cfbef43cd9253a61eb7cfa._comment b/doc/bugs/Get_gpg_subkey_id_used_for_encryption/comment_2_81f2725bf6cfbef43cd9253a61eb7cfa._comment
new file mode 100644
index 0000000000..17472f523d
--- /dev/null
+++ b/doc/bugs/Get_gpg_subkey_id_used_for_encryption/comment_2_81f2725bf6cfbef43cd9253a61eb7cfa._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="kirelagin@6d93475882c55a329fedae6be1971868a775ec7e"
+ nickname="kirelagin"
+ avatar="http://cdn.libravatar.org/avatar/325af9a946cb4337c6640f0e95044be1"
+ subject="comment 2"
+ date="2019-02-07T19:03:35Z"
+ content="""
+> If you use \"keyid!\" to specify a subkey, it is shown by git-annex info
+
+But if I do not, then it is not shown, even though there can still be multiple valid encryption subkeys and god knows which one it chose.
+"""]]
diff --git a/doc/bugs/Get_gpg_subkey_id_used_for_encryption/comment_3_efae569e57322f263f626e330c64aac5._comment b/doc/bugs/Get_gpg_subkey_id_used_for_encryption/comment_3_efae569e57322f263f626e330c64aac5._comment
new file mode 100644
index 0000000000..a84a4ea692
--- /dev/null
+++ b/doc/bugs/Get_gpg_subkey_id_used_for_encryption/comment_3_efae569e57322f263f626e330c64aac5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-02-07T19:22:23Z"
+ content="""
+Right, but if you're not sure if it's encrypted to a given subkey, you can
+simply add the subkey with `keyid+='xxx!'` and then you'll know for sure
+it's encrypting to it.
+
+Seems to me that users who want to do things with multiple subkeys can just
+do that, once, and we avoid needing to add a whole lot of complication to
+git-annex.
+"""]]
diff --git a/doc/bugs/Git-annex_and_Microsoft_Office_files_on_OS_X.mdwn b/doc/bugs/Git-annex_and_Microsoft_Office_files_on_OS_X.mdwn
new file mode 100644
index 0000000000..22a0bb65b7
--- /dev/null
+++ b/doc/bugs/Git-annex_and_Microsoft_Office_files_on_OS_X.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+
+On OS X 10.11.6, if you save any MS office file (.pptx, .docx, .xlsx) in a git-annex directory it won't be synced by the assistant unless you restart the daemon. If you look in the logs it says "/Users/me/annex/test.pptx still has writers, not adding" This probably has something to do with temporary/lockfiles used by MS office apps (Office 2011 for Mac). Any ideas on a workaround, other than restarting the daemon constantly?
+
+
+### What steps will reproduce the problem?
+
+1.  Create any MS office file (.docx, .pptx, .xlsx).  Save in a directory managed by git-annex assistant.  Error message "still has writers, not adding" will show up in git-annex log.  File will not be synced to any other computer running git-annex assistant until Office application quit and daemon restarted.
+
+
+### What version of git-annex are you using? On what operating system?
+
+6.20161211-gf58b134, OS X 10.11.6
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes!  It's wonderful otherwise!
diff --git a/doc/bugs/Git-annex_and_Microsoft_Office_files_on_OS_X/comment_1_0cf11096ceeb6cf93db5609a42a70641._comment b/doc/bugs/Git-annex_and_Microsoft_Office_files_on_OS_X/comment_1_0cf11096ceeb6cf93db5609a42a70641._comment
new file mode 100644
index 0000000000..ae27704b28
--- /dev/null
+++ b/doc/bugs/Git-annex_and_Microsoft_Office_files_on_OS_X/comment_1_0cf11096ceeb6cf93db5609a42a70641._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-09T17:52:00Z"
+ content="""
+This must have to do with the fsevents interface used on OSX.
+
+In Assistant.Threads.Committer.safeToAdd, when lsof detects
+a file is still open for write by some process, it cancels
+the add. This relies on events being received when files
+get closed (closingTracked).
+
+In Utility.DirWatcher.FSEvents.watchDir, when an event has
+eventFlagItemModified set, it treats that as a file add event.
+The intent is to emulate inotify's handling of file add events when
+files are closed.
+
+So, two theories:
+
+1. Perhaps eventFlagItemModified only gets set if the file
+   is actually modified. Ie, if MS office writes the file
+   and while it's being written another process opens it to read
+   it (perhaps to index the content), then if the other process
+   doesn't modify it, eventFlagItemModified is not set.
+
+2. Perhaps the way the assistant hard links/moves the file around
+   confuses the FSEvents handling. Perhaps there is an event with
+   eventFlagItemModified, but it's for the locked down file, or
+   something like that, so git-annex ignores it.
+
+In any case, I'm leaning toward thinking that closingTracked should
+not be True for FSEvents. This bug report seems to show, conclusively,
+that FSEvents does not have that property. If closingTracked was False,
+as it is for KQueue, the assistant would postpone adding the file,
+and keep retrying, around once per second, until it no longer had
+any writers, and then add it.
+
+So, I've made that change. I suspect it fixes the bug, but it would
+be pretty hard for me to test it. Could you please download tomorrow's
+daily build of git-annex for OSX, and see if it fixes the problem?
+"""]]
diff --git a/doc/bugs/Git_checkout_fails_using_--recurse-submodules.mdwn b/doc/bugs/Git_checkout_fails_using_--recurse-submodules.mdwn
new file mode 100644
index 0000000000..551d9ea60c
--- /dev/null
+++ b/doc/bugs/Git_checkout_fails_using_--recurse-submodules.mdwn
@@ -0,0 +1,83 @@
+### Please describe the problem.
+
+Consider a parent repository with a single submodule and two branches in the parent repository. When checking out a branch in the parent using --recurse-submodules, git returns the error:
+
+```
+fatal: could not open 'sub/.git' for writing: Is a directory
+```
+
+This issue was originally mentioned in [this post](https://git-annex.branchable.com/submodules/) where there is a statement that "The conversion of .git file to .git symlink mostly won't bother git." It is precisely this change that git has a problem with when changing to a new branch. The original poster said there was a solution to use "git checkout mybranch && git submodule update", but this does not work with git version 2.40.0 and git-annex version 10.20230407. In this case, rather than giving a fatal error, git is unable to remove the submodule directory and leaves it untouched. However, this then leaves the new branch in a dirty state (because the submodule is an untracked or modified file). 
+
+The end goal for using `--recurse-submodules` is so that either
+  1) a submodule will exist only in a single branch and/or
+  2) different branches in the parent will automatically point to different branches in the submodule
+
+### What steps will reproduce the problem?
+Here is a sequence of steps to reproduce the issue.
+
+```bash
+# create git repo to use as a submodule
+SUB_DIR=/tmp/submodule-source
+if [ -d $SUB_DIR ]; then
+    sudo rm -rf $SUB_DIR
+fi
+mkdir -p $SUB_DIR
+cd $SUB_DIR
+git init
+git annex init
+# add file to main
+touch sub_file1.txt
+git annex add .
+git commit -m "Add sub_file1.txt"
+
+# setup parent dataset
+PRNT_DIR=/tmp/submodule-annex
+if [ -d $PRNT_DIR ]; then
+    sudo rm -rf $PRNT_DIR
+fi
+mkdir -p $PRNT_DIR
+cd $PRNT_DIR
+git init
+git annex init
+# add file to main
+touch file1.txt
+git annex add .
+git commit -m "Create file1.txt"
+
+# Add branch 1 to parent dataset
+cd $PRNT_DIR
+git checkout -b branch_1 main
+# add submodule 1 to branch 1 of parent dataset
+git -c protocol.file.allow=always submodule add $SUB_DIR/.git sub
+git commit -m "Add submodule 1"
+
+# add new file to submodule annex
+cd sub
+touch sub_file2.txt
+git annex add .
+git commit -m "Create sub_file2.txt"
+
+# register changes in the parent
+cd ..
+git add .
+git commit -m "Register sub changes"
+
+# return to main branch, this fails
+git checkout main --recurse-submodules
+# return to main branch, this fails
+# git checkout main && git submodule update
+```
+
+### What version of git-annex are you using? On what operating system?
+
+git version 2.40.0
+
+git-annex version: 10.20230407
+
+operating system: darwin aarch64
+
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Yes! Been familiarizing myself with it on and off over the last year and am very excited about it's possibilities.
+
diff --git a/doc/bugs/Git_checkout_fails_using_--recurse-submodules/comment_1_571703fc4e1e2f4e34f54db7a7da7080._comment b/doc/bugs/Git_checkout_fails_using_--recurse-submodules/comment_1_571703fc4e1e2f4e34f54db7a7da7080._comment
new file mode 100644
index 0000000000..e0061a2411
--- /dev/null
+++ b/doc/bugs/Git_checkout_fails_using_--recurse-submodules/comment_1_571703fc4e1e2f4e34f54db7a7da7080._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-04-20T17:51:01Z"
+ content="""
+Notice that your script is doing something a bit unusual. You check out a
+branch, add the submodule in that branch, and then check out the original
+branch, which is before the submodule was added.
+
+So, git needs to delete the submodule. Deleting the submodule is
+mentioned in [[submodules]] as a particular case where git-annex's hack to
+support submodules does not work very well.
+
+If that's all this bug is about, its description is over-broad. 
+It doesn't seem to prevent using submodules with git-annex in situations
+where you are not deleting a submodule, but are updating submodules
+
+Yes, `git checkout main --recurse-submodules` will fail in those
+situations, but the workaround in [this comment](https://git-annex.branchable.com/submodules/#comment-0d7c31e3f08e803bf9b13ab0568fedcc)
+of using `git checkout main && git submodule update` will work.
+
+And yes, I've verified that does still work, with git 2.40.0.
+I modified the test case to add the submodule before checking out
+the branch, then add `sub_file2.txt`, and commit that to the branch.
+At that point,  `git checkout main && git submodule update` worked fine.
+
+So, nothing changed in git, and git-annex's approach for submodules does
+broadly work, except git has issues deleting submodules that have a .git
+directory in them. The solution is to `rm -rf` the submodule after
+running `git checkout`.
+"""]]
diff --git a/doc/bugs/Git_checkout_fails_using_--recurse-submodules/comment_2_9fe6b56ffda6d0c77ce65786514cd79d._comment b/doc/bugs/Git_checkout_fails_using_--recurse-submodules/comment_2_9fe6b56ffda6d0c77ce65786514cd79d._comment
new file mode 100644
index 0000000000..03e893759c
--- /dev/null
+++ b/doc/bugs/Git_checkout_fails_using_--recurse-submodules/comment_2_9fe6b56ffda6d0c77ce65786514cd79d._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-04-20T18:04:56Z"
+ content="""
+I don't think it's possible to improve git-annex's behavior here much.
+
+git-annex could avoid converting .git file to a directory, but then the
+git-annex symlinks would point to the wrong place. It could, when in a
+submodule, make the git-annex symlinks point up to ../.git/modules/sub/,
+but then the links would not work when the submodule was cloned by itself,
+or when the submodule was located at a different directory level.
+
+The only other thing git-annex can do is avoid using symlinks at all,
+eg adjusted unlocked branches. I don't think it's a good trafeoff to do
+that. On the one hand, there is this minor issue with submodule deletion,
+and the need to avoid using `--recurse-submodules` and instead do `git
+submodule update`. On the other hand, unlocked annexed files use 2x
+as much disk space.
+"""]]
diff --git a/doc/bugs/Git_checkout_fails_using_--recurse-submodules/comment_3_fce2467a0442f98194fa11caffa466ad._comment b/doc/bugs/Git_checkout_fails_using_--recurse-submodules/comment_3_fce2467a0442f98194fa11caffa466ad._comment
new file mode 100644
index 0000000000..572805244d
--- /dev/null
+++ b/doc/bugs/Git_checkout_fails_using_--recurse-submodules/comment_3_fce2467a0442f98194fa11caffa466ad._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-04-20T18:13:04Z"
+ content="""
+Well, there is `git-annex adjust --fix` now. So in theory, git-annex in a
+submodule could leave .git a file and enter an adjusted fixed branch, and
+when generating that branch, make the annex object symlinks point to
+`../.git/modules/sub/`
+
+Then git would commit the ref of the adjusted branch as the submodule.
+So checking it out elsewhere would need to either replicate that same
+commit sha  with `git-annex adjust --fix` again (doable but tricky),
+or that ref would need to be pushed.
+
+The user would also need to use `git-annex sync` in the submodule
+after making changes if they want to propatate them out of the adjusted
+branch to the main branch.
+"""]]
diff --git a/doc/bugs/Git_copy_fails_with_absolute_path_on_mavericks.mdwn b/doc/bugs/Git_copy_fails_with_absolute_path_on_mavericks.mdwn
new file mode 100644
index 0000000000..5704bf1ccc
--- /dev/null
+++ b/doc/bugs/Git_copy_fails_with_absolute_path_on_mavericks.mdwn
@@ -0,0 +1,12 @@
+### Please describe the problem.
+
+git-annex version: 6.20160126
+
+Problem happens on Mavericks, not on Yosemite with same version.
+
+Can do a relative or absolute path on a git annex add.
+
+But on the git annex copy to an S3 remote, if I use an absolute path for the file descriptor (e.g. /Users/name/git_directory/test.txt) it will not report an error, but will also not print the "copied..." string. A subsequent call with a relative path (e.g. test.txt) will work, show the copied message and indeed show up on S3.
+
+
+Good news: It's working great on Yosemite!
diff --git a/doc/bugs/Git_copy_fails_with_absolute_path_on_mavericks/comment_1_2f0c74aba502533b85b922ea81ded70d._comment b/doc/bugs/Git_copy_fails_with_absolute_path_on_mavericks/comment_1_2f0c74aba502533b85b922ea81ded70d._comment
new file mode 100644
index 0000000000..e538a75c62
--- /dev/null
+++ b/doc/bugs/Git_copy_fails_with_absolute_path_on_mavericks/comment_1_2f0c74aba502533b85b922ea81ded70d._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-03-14T17:34:21Z"
+ content="""
+Using absolute paths to files is an unusual thing to do with git in my
+experience. But, git does seem to support it, at least some of the time.
+
+I think that git-annex's support for it comes down to what `git ls-files`
+does. For example:
+
+	joey@darkstar:~/tmp/me> git ls-files ~/tmp/me/foo
+	foo
+
+Since git-annex uses git ls-files, it sees a relative file and so
+all or most all git-annex commands can work with the absolute file input.
+
+Does git ls-files convert the absolute path to a relative path
+when you run it on the Mavericks system?
+
+What version of git is installed on the Mavericks system? Is
+git-annex installed from the git-annex app, or from homebrew, or how?
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves.mdwn b/doc/bugs/Git_repos_corrupt_themselves.mdwn
new file mode 100644
index 0000000000..9bef074686
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves.mdwn
@@ -0,0 +1,109 @@
+### Please describe the problem.
+
+This has happened a few times now which is why I'm reporting it. Git-annex seems to do something that causes my git repo to randomly corrupt on their own which is very worrying because I need to trust these repos to keep their content safe.
+It has never happened with regular repos and happens on both my Linux machine and my MBP. It hasn't happened on my NAS (SOTERIA) yet though which is exclusively accessed remotely, so I suspect this is an issue with the assistant/daemon.
+
+### What steps will reproduce the problem?
+
+Just have the assistant running, committing and syncing. No idea what other factors migh play into this.
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 8.20210428
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.28 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.4 http-client-0.6.4.1 persistent-sqlite-2.11.1.0 torrent-10000.1.1 uuid-1.3.14 yesod-1.6.1.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+```
+
+https://github.com/Atemu/nixpkgs/tree/498831397e77a265c240cf8f8a7d15e738f2f05b
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+[2021-05-09 17:55:13.653645489] Committer: Committing changes to git
+(recording state in git...)
+[2021-05-09 17:55:13.702843262] Pusher: Syncing with SOTERIA 
+To ssh://192.168.101.24/~/Annex/Documents.git/
+   041f52d19..40cc59126  master -> synced/master
+git-annex: internal error: evacuate: strange closure type 4325399
+    (GHC version 8.10.4 for x86_64_unknown_linux)
+    Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
+(recording state in git...)
+(scanning...) ControlSocket .git/annex/ssh/atemu@192.168.101.24 already exists, disabling multiplexing
+(started...) 
+(recording state in git...)
+Unpacking all pack files.
+remote: error: cannot lock ref 'refs/heads/synced/git-annex': is at 9166c83718695df3021d5bbf4fef2297d3f4cc84 but expected 7f761edbbe3c2a4710c629e9e7fdfb730c0639e7        
+remote: error: cannot lock ref 'refs/heads/synced/master': is at 42cab466f705c2496fb19249e272487bceb38808 but expected 40cc591261675e872f79b6a9ea966215d3f73581        
+To ssh://192.168.101.24/~/Annex/Documents.git/
+ ! [remote rejected]     git-annex -> synced/git-annex (failed to update ref)
+ ! [remote rejected]     master -> synced/master (failed to update ref)
+error: failed to push some refs to 'ssh://192.168.101.24/~/Annex/Documents.git/'
+To ssh://192.168.101.24/~/Annex/Documents.git/
+   7f761edbb..9166c8371  git-annex -> synced/git-annex
+   40cc59126..42cab466f  master -> synced/master
+fatal: early EOF
+git-annex: internal error: evacuate: strange closure type 4325399
+    (GHC version 8.10.4 for x86_64_unknown_linux)
+    Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
+(recording state in git...)
+ControlSocket .git/annex/ssh/atemu@192.168.101.24 already exists, disabling multiplexing
+Auto packing the repository in background for optimum performance.
+See "git help gc" for manual housekeeping.
+error: Could not read 1f2ab777cdd4eb9add96d42de5022bde0a4a9a8b
+error: Could not read 0f74453f84ff23d31b00a9bc9c331c00988f465a
+error: Could not read 0f74453f84ff23d31b00a9bc9c331c00988f465a
+error: Could not read 1f2ab777cdd4eb9add96d42de5022bde0a4a9a8b
+error: Could not read 0f74453f84ff23d31b00a9bc9c331c00988f465a
+error: Could not read 1f2ab777cdd4eb9add96d42de5022bde0a4a9a8b
+error: Could not read 0f74453f84ff23d31b00a9bc9c331c00988f465a
+error: Could not read 1f2ab777cdd4eb9add96d42de5022bde0a4a9a8b
+error: Could not read 0f74453f84ff23d31b00a9bc9c331c00988f465a
+hint: Using 'master' as the name for the initial branch. This default branch name
+hint: is subject to change. To configure the initial branch name to use in all
+hint: of your new repositories, which will suppress this warning, call:
+hint: 
+hint: 	git config --global init.defaultBranch <name>
+hint: 
+hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
+hint: 'development'. The just-created branch can be renamed via this command:
+hint: 
+hint: 	git branch -m <name>
+Initialized empty Git repository in /tmp/tmpreporFb6Gq/.git/
+Trying to recover missing objects from remote SOTERIA.
+fatal: 'SOTERIA' does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+Trying to recover missing objects from remote SOTERIA.
+fatal: 'SOTERIA' does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+65 missing objects could not be recovered!
+To force a recovery to a usable state, retry with the --force parameter.
+# End of transcript or log.
+"""]]
+
+I'm not precisely sure when the actual crash happened (could be that it happened after starting up the machine today) as the log is a bit ambiguous. All I know is that it was corrupted today and that I was making commits till yesterday ~18:00.
+
+The objects mentioned in the log are both 6 days old; one is a commit on master and one on git-annex.
+
+Git fsck spat out a huge list of broken blobs and trees.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+There are a surprising amount of weird bugs and quirks like these but it's such an amazing tool, there's nothing like it.
+
+> [[fixed|done]] although I have opened [[assistant_repair_misfires]] for
+> part of the cause of this. --[[Joey]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_10_74e6d17a1b14b2fdc7eddf4ee1895733._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_10_74e6d17a1b14b2fdc7eddf4ee1895733._comment
new file mode 100644
index 0000000000..53492231a8
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_10_74e6d17a1b14b2fdc7eddf4ee1895733._comment
@@ -0,0 +1,601 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 10"
+ date="2021-05-25T11:00:39Z"
+ content="""
+A new crash just happened. I haven't upgraded git-annex to master yet but the strange closure bug didn't occur this time. Annotated daemon.log:
+
+```
+(scanning...) (started...) 
+<lots of this>
+ssh: connect to host 192.168.101.68 port 22: Connection timed out
+<because the MBP is sleeping>
+add file.etherpad ok <note: textconv is set up to pipe .etherpad through `jq .` to pretty-print it>
+(recording state in git...)
+
+<git annex fsck all the tree's files. I did not trigger this and automatic consistency checks are off!>
+(recording state in git...)
+(recording state in git...)
+git-annex: fsck: 1 failed
+(recovering from race...)
+ssh: connect to host 192.168.101.68 port 22: Connection timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+
+
+remote: error: cannot lock ref 'refs/heads/master': is at 6e737fee3f50ee203c9db151e3f9d0308c63df9b but expected fc38ba7550f8dd0d29262bc47ae3085403a55784        To ssh://192.168.101.24/~/Annex/Documents.git/ ! [remote rejected]     master -> master (failed to update ref)error: failed to push some refs to 'ssh://192.168.101.24/~/Annex/Documents.git/'ssh: connect to host 192.168.101.68 port 22: No route to host
+fatal: Could not read from remote repository.Please make sure you have the correct access rightsand the repository exists.ssh: connect to host 192.168.101.68 port 22: Connection timed out
+fatal: Could not read from remote repository.Please make sure you have the correct access rightsand the repository exists.ssh: connect to host 192.168.101.68 port 22: Connection timed out
+fatal: Could not read from remote repository.Please make sure you have the correct access rightsand the repository exists.ssh: connect to host 192.168.101.68 port 22: Connection timed out
+fatal: Could not read from remote repository.Please make sure you have the correct access rightsand the repository exists.ssh: connect to host 192.168.101.68 port 22: No route to host
+fatal: Could not read from remote repository.Please make sure you have the correct access rightsand the repository exists.ssh: connect to host 192.168.101.68 port 22: No route to host
+fatal: Could not read from remote repository.Please make sure you have the correct access rightsand the repository exists.  Transfer failed
+Unpacking all pack files.
+hint: Using 'master' as the name for the initial branch. This default branch name
+hint: is subject to change. To configure the initial branch name to use in all
+hint: of your new repositories, which will suppress this warning, call:
+hint: 
+hint: 	git config --global init.defaultBranch <name>
+hint: 
+hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
+hint: 'development'. The just-created branch can be renamed via this command:
+hint: 
+hint: 	git branch -m <name>
+Initialized empty Git repository in /tmp/tmprepoZrGQTy/.git/
+Trying to recover missing objects from remote MB-<REDACTED>.
+fatal: 'MB-<REDACTED>' does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+Trying to recover missing objects from remote SOTERIA.
+fatal: 'SOTERIA' does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+Trying to recover missing objects from remote MB-<REDACTED>.
+fatal: 'MB-<REDACTED>' does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+Trying to recover missing objects from remote SOTERIA.
+fatal: 'SOTERIA' does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+2 missing objects could not be recovered!
+To force a recovery to a usable state, retry with the --force parameter.
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+add <.txt render of the etherpad file> fatal: Invalid revision range refs/heads/master..refs/synced/d7d728f7-891a-4035-a758-c7ee80a8017a/master
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+ok
+(recording state in git...)
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+CONFLICT (add/add): Merge conflict in <unrelated but frequently edited file>.org
+Auto-merging <file>.org
+<a handful of conflicts like this>
+Automatic merge failed; fix conflicts and then commit the result.
+
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: Merging is not possible because you have unmerged files.
+hint: Fix them up in the work tree, and then use 'git add/rm <file>'
+hint: as appropriate to mark resolution and make a commit.
+fatal: Exiting because of an unresolved conflict.
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+
+
+100%  3.33 KiB        198 MiB/s 0s
+                                  
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+ssh: connect to host 192.168.101.68 port 22: Connection timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: Merging is not possible because you have unmerged files.
+hint: Fix them up in the work tree, and then use 'git add/rm <file>'
+hint: as appropriate to mark resolution and make a commit.
+fatal: Exiting because of an unresolved conflict.
+
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: Merging is not possible because you have unmerged files.
+hint: Fix them up in the work tree, and then use 'git add/rm <file>'
+hint: as appropriate to mark resolution and make a commit.
+fatal: Exiting because of an unresolved conflict.
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+ssh: connect to host 192.168.101.68 port 22: No route to host
+
+
+ssh: connect to host 192.168.101.68 port 22: Connection timed out
+fatal: Could not read from remote repository.Please make sure you have the correct access rightsand the repository exists.  Transfer failed
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+ssh: connect to host 192.168.101.68 port 22: Connection timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+ssh: connect to host 192.168.101.68 port 22: Connection timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+To ssh://192.168.101.24/~/Annex/Documents.git/
+   105d6d0..4bd9661  git-annex -> synced/git-annex
+ ! [rejected]        master -> synced/master (fetch first)
+error: failed to push some refs to 'ssh://192.168.101.24/~/Annex/Documents.git/'
+hint: Updates were rejected because the remote contains work that you do
+hint: not have locally. This is usually caused by another repository pushing
+hint: to the same ref. You may want to first integrate the remote changes
+hint: (e.g., 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+ssh: connect to host 192.168.101.68 port 22: No route to host
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+error: refs/remotes/SOTERIA/master does not point to a valid object!
+error: refs/remotes/SOTERIA/synced/master does not point to a valid object!
+From ssh://192.168.101.24/~/Annex/Documents
+ * [new branch]      master        -> SOTERIA/master
+ * [new branch]      synced/master -> SOTERIA/synced/master
+Auto packing the repository in background for optimum performance.
+See \"git help gc\" for manual housekeeping.
+
+error: Merging is not possible because you have unmerged files.
+hint: Fix them up in the work tree, and then use 'git add/rm <file>'
+hint: as appropriate to mark resolution and make a commit.
+fatal: Exiting because of an unresolved conflict.
+
+error: Merging is not possible because you have unmerged files.
+hint: Fix them up in the work tree, and then use 'git add/rm <file>'
+hint: as appropriate to mark resolution and make a commit.
+fatal: Exiting because of an unresolved conflict.
+
+error: Merging is not possible because you have unmerged files.
+hint: Fix them up in the work tree, and then use 'git add/rm <file>'
+hint: as appropriate to mark resolution and make a commit.
+fatal: Exiting because of an unresolved conflict.
+
+error: Merging is not possible because you have unmerged files.
+hint: Fix them up in the work tree, and then use 'git add/rm <file>'
+hint: as appropriate to mark resolution and make a commit.
+fatal: Exiting because of an unresolved conflict.
+To ssh://192.168.101.24/~/Annex/Documents.git/
+ ! [rejected]        master -> synced/master (non-fast-forward)
+error: failed to push some refs to 'ssh://192.168.101.24/~/Annex/Documents.git/'
+hint: Updates were rejected because a pushed branch tip is behind its remote
+hint: counterpart. Check out this branch and integrate the remote changes
+hint: (e.g. 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+ssh: connect to host 192.168.101.68 port 22: Connection timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+ssh: connect to host 192.168.101.68 port 22: No route to host
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+To ssh://192.168.101.24/~/Annex/Documents.git/
+   8cd959c..4bd9661  git-annex -> refs/synced/8dc76e63-3dac-4cc3-a752-e73e81d57c1a/git-annex
+ ! [rejected]        master -> refs/synced/8dc76e63-3dac-4cc3-a752-e73e81d57c1a/master (non-fast-forward)
+error: failed to push some refs to 'ssh://192.168.101.24/~/Annex/Documents.git/'
+hint: Updates were rejected because a pushed branch tip is behind its remote
+hint: counterpart. Check out this branch and integrate the remote changes
+hint: (e.g. 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+ssh: connect to host 192.168.101.68 port 22: Connection timed out
+```
+
+Git is now trying to merge refs/synced/d7d728f7-891a-4035-a758-c7ee80a8017a/master which points at a commit made on the MBP 4d ago. This commit has previously been **merged** into the original branch on this machine and contains a change to a txt render of a different .etherpad file. This also means that the commit before it contains a change to the according .etherpad file.
+
+My branch is now a single commit made at 11:49:21 that adds the whole state of the working dir.
+However, the diff for the .etherpad file says (without textconv):
+
+```
+diff --git a/Uni/LAWR/V10/132c6ef4e421c88547d4a228fef3c39491ba0610.etherpad b/Uni/LAWR/V10/132c6ef4e421c88547d4a228fef3c39491ba0610.etherpad
+new file mode 100644
+index 0000000..33e0a8f
+--- /dev/null
++++ b/Uni/LAWR/V10/132c6ef4e421c88547d4a228fef3c39491ba0610.etherpad
+@@ -0,0 +1 @@
++/annex/objects/SHA256E-s675354--3b69c1b0549173d731e6259d6c817eebabcd5b43a4e5cf6b83c7498603dae6d2
+diff --git a/Uni/LAWR/V10/132c6ef4e421c88547d4a228fef3c39491ba0610.txt b/Uni/LAWR/V10/132c6ef4e421c88547d4a228fef3c39491ba0610.txt
+new file mode 100644
+index 0000000..f9ce6fe
+--- /dev/null
++++ b/Uni/LAWR/V10/132c6ef4e421c88547d4a228fef3c39491ba0610.txt
+@@ -0,0 +1 @@
++/annex/objects/SHA256E-s3406--d5168f8722e96719e2cf32d21760690930264aa8c88d76098477d3438fa247ab.txt
+```
+
+It added these as a unlocked largefiles despite my largefiles rule excluding them. This has happened before once I think but I manually committed at that time.
+
+The other .etherpad files I had in the tree were not added as largefiles.
+
+I remember having issues with textconv and annex before too and disabling a few rules that I didn't really need.
+
+The git-annex branch seems to be in-tact. However, its commits are a bit weird. Here is `git log synced/git-annex..git-annex --patch`:
+
+```
+commit 4bd9661256a12d81186420a16d1bc1fb5f5d261a
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:49:22 2021 +0200
+
+    update (recovery from race #1; expected commit parent Ref \"5edabb3782060a334f966387e03252440ef50b10\" but found [Ref \"c518e6a6cac2b966e757a97dc8d26b64743be377\"] )
+
+commit efdaa77dbf258954289366e236f056e50a258e1a
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:49:22 2021 +0200
+
+    update
+
+commit c518e6a6cac2b966e757a97dc8d26b64743be377
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:49:22 2021 +0200
+
+    update (recovery from race #1; expected commit parent Ref \"5edabb3782060a334f966387e03252440ef50b10\" but found [Ref \"79a6d5f9b7b45ae891529a9bf2ead592f3968faa\"] )
+
+commit fd7d4f7a6c875ca43cfe5e2e34b27c4cd6daab0a
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:49:22 2021 +0200
+
+    update
+
+commit 79a6d5f9b7b45ae891529a9bf2ead592f3968faa
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:49:22 2021 +0200
+
+    update (recovery from race #1; expected commit parent Ref \"5edabb3782060a334f966387e03252440ef50b10\" but found [Ref \"79190c0161b13aae6570cb24f232ea6ef9288f66\"] )
+
+commit 1276807833ad40c19190049a85ba82b5b171edd2
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:49:22 2021 +0200
+
+    update
+
+commit 79190c0161b13aae6570cb24f232ea6ef9288f66
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:49:22 2021 +0200
+
+    update
+
+diff --git a/672/674/SHA256E-s3406--d5168f8722e96719e2cf32d21760690930264aa8c88d76098477d3438fa247ab.txt.log b/672/674/SHA256E-s3406--d5168f8722e96719e2cf32d21760690930264aa8c88d76098477d3438fa247ab.txt.log
+index 92b1312..0ff0604 100644
+--- a/672/674/SHA256E-s3406--d5168f8722e96719e2cf32d21760690930264aa8c88d76098477d3438fa247ab.txt.log
++++ b/672/674/SHA256E-s3406--d5168f8722e96719e2cf32d21760690930264aa8c88d76098477d3438fa247ab.txt.log
+@@ -1 +1,2 @@
+ 1621936161.088002573s 1 8dc76e63-3dac-4cc3-a752-e73e81d57c1a
++1621936161.329141017s 1 b0512e28-91b3-4792-a4ef-71357fc4b63a
+
+commit 5edabb3782060a334f966387e03252440ef50b10
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:49:21 2021 +0200
+
+    update
+
+diff --git a/672/674/SHA256E-s3406--d5168f8722e96719e2cf32d21760690930264aa8c88d76098477d3438fa247ab.txt.log b/672/674/SHA256E-s3406--d5168f8722e96719e2cf32d21760690930264aa8c88d76098477d3438fa247ab.txt.log
+new file mode 100644
+index 0000000..92b1312
+--- /dev/null
++++ b/672/674/SHA256E-s3406--d5168f8722e96719e2cf32d21760690930264aa8c88d76098477d3438fa247ab.txt.log
+@@ -0,0 +1 @@
++1621936161.088002573s 1 8dc76e63-3dac-4cc3-a752-e73e81d57c1a
+diff --git a/672/674/SHA256E-s3406--d5168f8722e96719e2cf32d21760690930264aa8c88d76098477d3438fa247ab.txt.log.met b/672/674/SHA256E-s3406--d5168f8722e96719e2cf32d21760690930264aa8c88d76098477d3438fa247ab.txt.log.met
+new file mode 100644
+index 0000000..9972f75
+--- /dev/null
++++ b/672/674/SHA256E-s3406--d5168f8722e96719e2cf32d21760690930264aa8c88d76098477d3438fa247ab.txt.log.met
+@@ -0,0 +1 @@
++1621936161.086396922s day +25 month +5 year +2021
+
+commit 6dbb8cc706949f8ef1dbbbd1003dbe728b642f8a
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:45:51 2021 +0200
+
+    update (recovery from race #1; expected commit parent Ref \"1ccaa3ce85972818d9afee1ff047183d8836c927\" but found [Ref \"260477393b0e18fbf0d4fc77afa10ab0069f2d40\"] )
+
+commit 1f035559a42966383b424ebb0dd62509f8259543
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:45:51 2021 +0200
+
+    update
+
+commit 260477393b0e18fbf0d4fc77afa10ab0069f2d40
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:45:51 2021 +0200
+
+    update
+
+diff --git a/activity.log b/activity.log
+index e388b9e..890cae5 100644
+--- a/activity.log
++++ b/activity.log
+@@ -1,37 +1,8 @@
+ 00b14f31-5c38-4eb3-b16f-17140b671470 Fsck timestamp=1610259369.931977s
+ 1968d496-fca5-4b48-ac56-b4de73d6af82 Fsck timestamp=1609853522.83856s
+-283a9cfc-cc28-481f-8ab3-28564f61e278 Fsck timestamp=1614085193.126619514s
+-283a9cfc-cc28-481f-8ab3-28564f61e278 Fsck timestamp=1614155865.00518998s
+ 283a9cfc-cc28-481f-8ab3-28564f61e278 Fsck timestamp=1614159798.683064383s
+ 4ea64ba8-3d84-439d-88c9-021380c3b097 Fsck timestamp=1610235815.801036s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1614161439.951758036s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1614161875.368919604s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1614503753.902534237s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1618474275.133432744s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1619560801.449019468s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1620081126.285146124s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1620655938.401915298s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621159014.044988654s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621161156.147989006s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621161290.856706788s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621161317.85070715s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621161413.579088689s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621328885.881572492s
+-8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621422002.80957147s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621935951.378910574s
+ a45a1abf-086e-40ea-8db5-f286a4fb69ef Fsck timestamp=1609849766.99771s
+-d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1614161148.72413s
+-d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1614162182.895703s
+-d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1614162687.460662s
+-d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1618351280.306775s
+-d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1619444550.542679s
+-d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1619733602.694413s
+-d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1619833893.739576s
+-d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1620079818.367555s
+-d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1620513005.967486s
+-d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1620775822.267693s
+-d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1621161025.720264s
+-d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1621239795.218301s
+ d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1621444868.775013s
+-f5f5f557-ecf2-4c2e-b704-add87173d58a Fsck timestamp=1612954464.455509s
+-f5f5f557-ecf2-4c2e-b704-add87173d58a Fsck timestamp=1614085579.354101s
+ f5f5f557-ecf2-4c2e-b704-add87173d58a Fsck timestamp=1614160037.595461s
+
+commit 1ccaa3ce85972818d9afee1ff047183d8836c927
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:45:51 2021 +0200
+
+    update
+
+diff --git a/af5/b21/SHA256E-s675354--3b69c1b0549173d731e6259d6c817eebabcd5b43a4e5cf6b83c7498603dae6d2.log b/af5/b21/SHA256E-s675354--3b69c1b0549173d731e6259d6c817eebabcd5b43a4e5cf6b83c7498603dae6d2.log
+index 0252166..3150f67 100644
+--- a/af5/b21/SHA256E-s675354--3b69c1b0549173d731e6259d6c817eebabcd5b43a4e5cf6b83c7498603dae6d2.log
++++ b/af5/b21/SHA256E-s675354--3b69c1b0549173d731e6259d6c817eebabcd5b43a4e5cf6b83c7498603dae6d2.log
+@@ -1 +1,2 @@
+ 1621935950.772957836s 1 8dc76e63-3dac-4cc3-a752-e73e81d57c1a
++1621935951.025150823s 1 b0512e28-91b3-4792-a4ef-71357fc4b63a
+
+commit 105d6d0ddea616d0f62f5bb78080954545966947
+Author: Atemu <atemu.main@gmail.com>
+Date:   Tue May 25 11:45:50 2021 +0200
+
+    update
+
+diff --git a/activity.log b/activity.log
+index f925d0a..e388b9e 100644
+--- a/activity.log
++++ b/activity.log
+@@ -1,8 +1,37 @@
+ 00b14f31-5c38-4eb3-b16f-17140b671470 Fsck timestamp=1610259369.931977s
+ 1968d496-fca5-4b48-ac56-b4de73d6af82 Fsck timestamp=1609853522.83856s
++283a9cfc-cc28-481f-8ab3-28564f61e278 Fsck timestamp=1614085193.126619514s
++283a9cfc-cc28-481f-8ab3-28564f61e278 Fsck timestamp=1614155865.00518998s
+ 283a9cfc-cc28-481f-8ab3-28564f61e278 Fsck timestamp=1614159798.683064383s
+ 4ea64ba8-3d84-439d-88c9-021380c3b097 Fsck timestamp=1610235815.801036s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1614161439.951758036s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1614161875.368919604s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1614503753.902534237s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1618474275.133432744s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1619560801.449019468s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1620081126.285146124s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1620655938.401915298s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621159014.044988654s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621161156.147989006s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621161290.856706788s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621161317.85070715s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621161413.579088689s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621328885.881572492s
+ 8dc76e63-3dac-4cc3-a752-e73e81d57c1a Fsck timestamp=1621422002.80957147s
+ a45a1abf-086e-40ea-8db5-f286a4fb69ef Fsck timestamp=1609849766.99771s
++d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1614161148.72413s
++d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1614162182.895703s
++d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1614162687.460662s
++d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1618351280.306775s
++d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1619444550.542679s
++d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1619733602.694413s
++d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1619833893.739576s
++d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1620079818.367555s
++d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1620513005.967486s
++d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1620775822.267693s
++d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1621161025.720264s
++d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1621239795.218301s
+ d7d728f7-891a-4035-a758-c7ee80a8017a Fsck timestamp=1621444868.775013s
++f5f5f557-ecf2-4c2e-b704-add87173d58a Fsck timestamp=1612954464.455509s
++f5f5f557-ecf2-4c2e-b704-add87173d58a Fsck timestamp=1614085579.354101s
+ f5f5f557-ecf2-4c2e-b704-add87173d58a Fsck timestamp=1614160037.595461s
+diff --git a/af5/b21/SHA256E-s675354--3b69c1b0549173d731e6259d6c817eebabcd5b43a4e5cf6b83c7498603dae6d2.log b/af5/b21/SHA256E-s675354--3b69c1b0549173d731e6259d6c817eebabcd5b43a4e5cf6b83c7498603dae6d2.log
+new file mode 100644
+index 0000000..0252166
+--- /dev/null
++++ b/af5/b21/SHA256E-s675354--3b69c1b0549173d731e6259d6c817eebabcd5b43a4e5cf6b83c7498603dae6d2.log
+@@ -0,0 +1 @@
++1621935950.772957836s 1 8dc76e63-3dac-4cc3-a752-e73e81d57c1a
+diff --git a/af5/b21/SHA256E-s675354--3b69c1b0549173d731e6259d6c817eebabcd5b43a4e5cf6b83c7498603dae6d2.log.met b/af5/b21/SHA256E-s675354--3b69c1b0549173d731e6259d6c817eebabcd5b43a4e5cf6b83c7498603dae6d2.log.met
+new file mode 100644
+index 0000000..2aa827d
+--- /dev/null
++++ b/af5/b21/SHA256E-s675354--3b69c1b0549173d731e6259d6c817eebabcd5b43a4e5cf6b83c7498603dae6d2.log.met
+@@ -0,0 +1 @@
++1621935950.772381243s day +25 month +5 year +2021
+diff --git a/efe/f7f/SHA256E-s2496630--0f778a1c32dfddf8098406ff28297d826b28759b4efeb1aa27a1841dd4897248.pdf.log b/efe/f7f/SHA256E-s2496630--0f778a1c32dfddf8098406ff28297d826b28759b4efeb1aa27a1841dd4897248.pdf.log
+index 7fd0604..d907850 100644
+--- a/efe/f7f/SHA256E-s2496630--0f778a1c32dfddf8098406ff28297d826b28759b4efeb1aa27a1841dd4897248.pdf.log
++++ b/efe/f7f/SHA256E-s2496630--0f778a1c32dfddf8098406ff28297d826b28759b4efeb1aa27a1841dd4897248.pdf.log
+@@ -1,3 +1,4 @@
+ 1621350596.596630026s 1 8dc76e63-3dac-4cc3-a752-e73e81d57c1a
++1621350602.99782945s 1 b0512e28-91b3-4792-a4ef-71357fc4b63a
+ 1621350603.027097277s 1 b0512e28-91b3-4792-a4ef-71357fc4b63a
+ 1621445067.293418s 1 d7d728f7-891a-4035-a758-c7ee80a8017a
+diff --git a/efe/f7f/SHA256E-s2496630--0f778a1c32dfddf8098406ff28297d826b28759b4efeb1aa27a1841dd4897248.pdf.log.met b/efe/f7f/SHA256E-s2496630--0f778a1c32dfddf8098406ff28297d826b28759b4efeb1aa27a1841dd4897248.pdf.log.met
+index b7f2ee1..2e12d4b 100644
+--- a/efe/f7f/SHA256E-s2496630--0f778a1c32dfddf8098406ff28297d826b28759b4efeb1aa27a1841dd4897248.pdf.log.met
++++ b/efe/f7f/SHA256E-s2496630--0f778a1c32dfddf8098406ff28297d826b28759b4efeb1aa27a1841dd4897248.pdf.log.met
+@@ -1 +1,2 @@
++1621350596.859331937s day +18 month +5 year +2021
+ 1621445071.205197s day -18 +19 month +5 year +2021
+diff --git a/schedule.log b/schedule.log
+index 88f8251..f29a67c 100644
+--- a/schedule.log
++++ b/schedule.log
+@@ -1,7 +1,16 @@
+ 00b14f31-5c38-4eb3-b16f-17140b671470 fsck self 1h every day at any time timestamp=1610259355.086542s
+ 1968d496-fca5-4b48-ac56-b4de73d6af82 fsck self 1h every day at any time timestamp=1609853466.30146s
++283a9cfc-cc28-481f-8ab3-28564f61e278 fsck self 1h every day at any time timestamp=1609829311.089081351s
++283a9cfc-cc28-481f-8ab3-28564f61e278 fsck self 1h every day at any time timestamp=1609829331.993124414s
+ 283a9cfc-cc28-481f-8ab3-28564f61e278 fsck self 1h every day at any time timestamp=1609831717.238587482s
++283a9cfc-cc28-481f-8ab3-28564f61e278 fsck self 8d13h every day at any time timestamp=1609829516.974129064s
+ 4ea64ba8-3d84-439d-88c9-021380c3b097  timestamp=1610030955.40944s
++4ea64ba8-3d84-439d-88c9-021380c3b097 fsck self 1h every day at any time timestamp=1609857462.383747s
+ 8dc76e63-3dac-4cc3-a752-e73e81d57c1a  timestamp=1621328896.270884603s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a fsck self 1h every day at any time timestamp=1614161325.360455592s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a fsck self 1h every day at any time timestamp=1616330220.055006692s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a fsck self 1h every day at any time timestamp=1620642662.423064041s
++8dc76e63-3dac-4cc3-a752-e73e81d57c1a fsck self 1h every day at any time; fsck self 10h1m every day at any time timestamp=1616329120.414652786s
+ d7d728f7-891a-4035-a758-c7ee80a8017a  timestamp=1621444873.058565s
++d7d728f7-891a-4035-a758-c7ee80a8017a fsck self 1h every day at any time timestamp=1616364223.127229s
+ f5f5f557-ecf2-4c2e-b704-add87173d58a fsck self 1h every day at any time timestamp=1610259937.483933s
+```
+
+synced/master is in the same state as it was 4d ago, the date of the merge commit git is now trying to merge.
+There have only been smallfile changes made to master since.
+
+I'm especially confused by the changes to schedule.log.
+
+***
+
+Looks like there are some major incompatibilities with textconv and git-annex that need to be documented and/or fixed.
+
+Smallfiles don't seem to be handled that well either, perhaps my other issues are related to using those almost exclusively in this repo?  
+Automatic merges have never worked for me for example. (Though I probably wouldn't want them anyways).  
+
+Is anyone else having issues with this combination of features? I can't be the only one, right?
+
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_11_d1f454482feef0350a6fa61bdf7673cc._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_11_d1f454482feef0350a6fa61bdf7673cc._comment
new file mode 100644
index 0000000000..db9b34e25a
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_11_d1f454482feef0350a6fa61bdf7673cc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 11"
+ date="2021-05-31T19:07:31Z"
+ content="""
+The consistency check somehow enabled itself the other day and sure enough, as soon as I started the webapp, the repo corrupted itself on the MBP. Haven't seen a corruption on the Linux machine since I disabled consistency checks.
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_12_5a13945d6bec6fa5fac84555f7ef8e21._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_12_5a13945d6bec6fa5fac84555f7ef8e21._comment
new file mode 100644
index 0000000000..6aa661b5f5
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_12_5a13945d6bec6fa5fac84555f7ef8e21._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2021-06-28T18:04:26Z"
+ content="""
+This seems conclusive that the repair is somehow triggering unncessarily
+and also corrupting the repo in this situation.
+
+The comment #3 log shows that the repair is started, and then 1 minute
+later a git object is missing.
+
+(It's odd that log shows a second fsck run after the repair was already
+triggered. I do not see a way that this would happen unless fscks are
+scheduled very close together.)
+
+The automatic repair is supposed to be a non-destructive repair; the
+destructive repair only happens after prompting in the UI.
+
+This also reminds me of a persistent issue with a git-annex repo, using the
+assistant, on my sister's laptop corrupting itself.
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_13_6715bc3370f115f90627cfc4b06cf0e8._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_13_6715bc3370f115f90627cfc4b06cf0e8._comment
new file mode 100644
index 0000000000..821c937b43
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_13_6715bc3370f115f90627cfc4b06cf0e8._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2021-06-28T18:13:40Z"
+ content="""
+The repair process moves all pack files to a temp dir and then unpacks the
+loose objects from them. So, there is a time window, when the repair is
+running, where git objects that were present before will be missing. And if
+the assistant stops before that is complete, it would leave it in that
+state. Unpacking pack files can take a long time, so this might
+be a sufficient explanation.
+
+But then, something must be causing it to incorrectly think it needs
+a repair in the first place. Assuming it is incorrect, of course. Either git
+fsck is exiting nonzero for some reason, or git-annex is thinking
+it sees git fsck complain about a missing object, that is not really
+missing. While there are fsck outputs that it can misinterpret, it
+double-checks by trying to cat the object, which should avoid the latter
+problem.
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_14_6234b04455acc0b2b2f22a1d8c2ab475._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_14_6234b04455acc0b2b2f22a1d8c2ab475._comment
new file mode 100644
index 0000000000..d8124b248e
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_14_6234b04455acc0b2b2f22a1d8c2ab475._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2021-06-28T18:28:06Z"
+ content="""
+To avoid moving the pack files, repair could set `GIT_OBJECT_DIRECTORY`
+to a temp directory, and copy each pack file into it in turn, and unpack.
+And after each unpack, move the unpacked objects from the temp directory to
+the real object directory, followed by deleting the pack file (in case it's
+corrupt).
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_16_586e591a1e3cc53fd0108da91492c5c2._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_16_586e591a1e3cc53fd0108da91492c5c2._comment
new file mode 100644
index 0000000000..c3f3afa06e
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_16_586e591a1e3cc53fd0108da91492c5c2._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2021-06-29T16:11:03Z"
+ content="""
+I have verified that an interrupted repair results in data loss, when
+.git/objects contains pack files.
+
+Fixed that. Which leaves 2 open questions:
+
+* Was the assistant interrupted somehow while it was running repair, in
+  Atemu's case? That could have been anything from the laptop being
+  powered off, to it being stopped explicitly, to it crashing.
+* What caused the assistant to think it needed repair in the first place?
+
+Although the answer to the second question doesn't matter much if the
+data loss bug is fixed -- if there's a problem of some kind causing
+unnecessary repairs, it would only be some excess CPU load.
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_16_7a1cdfba17f129f6bf87a71549bbaab6._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_16_7a1cdfba17f129f6bf87a71549bbaab6._comment
new file mode 100644
index 0000000000..00374bc0bd
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_16_7a1cdfba17f129f6bf87a71549bbaab6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2021-06-28T18:48:32Z"
+ content="""
+Removing repair from the assistant (and git-annex repair) should be on the
+table as a solution to this. It's a whole lot of complexity that might fix
+a few user's repos sometimes, but is outside of git-annex's scope and is
+mostly only used by assistant users.
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_17_faaa433ba8df649771469fdbcd9bb69e._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_17_faaa433ba8df649771469fdbcd9bb69e._comment
new file mode 100644
index 0000000000..e7459a8c71
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_17_faaa433ba8df649771469fdbcd9bb69e._comment
@@ -0,0 +1,52 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 17"
+ date="2021-06-29T22:57:39Z"
+ content="""
+Hi Joey, thank you for looking into this again.
+
+> It's odd that log shows a second fsck run after the repair was already triggered. I do not see a way that this would happen unless fscks are scheduled very close together.)
+
+Note that I started the assistant again in that log. The consistency check didn't finish the first time because somehow corruption was detected and the assistant crashed itself in trying to repair (I didn't accept any repair prompts in the GUI that time IIRC).
+
+AFAICT the consistency check is what triggers the issue because, since turning it off (and creating new repos on my clients), I haven't experienced a single repo corruption.
+
+The schedule was set to whatever the assistant nudges you to set by default.
+
+> comment 14
+
+That sounds a lot more sane.
+
+Perhaps the repair functionality could use a complete overhaul. I've also found it to be extremely slow compared to simply copying missing or corrupt objects/packs from another remote.
+
+Ideally it should be able to restore a git repo to a working state without .git/objects present at all as it should only needs remotes and refs.  
+Extracting objects from the corrupt objects dir which aren't in any remote should be done if possible though because important local-only objects are a thing (stashes, additional branches, branches that are ahead of the remote's)
+
+> Removing repair from the assistant (and git-annex repair) should be on the table as a solution to this.
+
+Manual repair and detection can stay IMO but any *automatic* repair needs to go entirely or be optional.
+
+> Removing repair from the assistant (and git-annex repair) should be on the table as a solution to this. It's a whole lot of complexity that might fix a few user's repos sometimes, but is outside of git-annex's scope and is mostly only used by assistant users.
+
+I've actually (tried) using it from the CLI too, having it as an option there would be useful.
+
+I agree that it's out of scope though. It would probably be better off as a separate project as it's useful in any git repo, not just git-annex ones. Some integration with git-annex would be appreciated though.  
+Perhaps this functionality could be fully spun out into git-repair which could then become an optional add-on to git-annex.
+
+> Was the assistant interrupted somehow while it was running repair, in Atemu's case?
+
+The laptop being powered off etc. was not the case. Though I do shut down the daemon quite often because of https://git-annex.branchable.com/bugs/OSX__58___Pushed_changes_are_autocommited/  (via the GUI or --stop). Do the shutdown and restart procedures check for a running repair?
+
+I also sometimes had to kill all git processes for one reason or another but I don't think that ever happened after I pressed the repair button (I wait that out for good reason).
+
+***
+
+So current issues distilled from this thread so far:
+
+* The scheduled consistency check can trigger automatic(!) repairs and even do so erroneously
+* This repair procedure does something destructive without a prompt
+* Applying the destructive repair to a working repo corrupts it
+* Repair can't actually repair the mishap despite all the data being available
+* Repair would probably be better off as a dedicated project outside of git-annex
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_18_238bbbcabd626c33acc14f930a7d536c._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_18_238bbbcabd626c33acc14f930a7d536c._comment
new file mode 100644
index 0000000000..a2ffd63a87
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_18_238bbbcabd626c33acc14f930a7d536c._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 18"""
+ date="2021-06-30T15:36:39Z"
+ content="""
+If the assistant crashed in the middle of a repair that confirms my
+analysis, and my fix will avoid both the data loss problem *and* the crash.
+
+Only remaining question to me is why would it trigger an unnecessary repair.
+
+But that could be anything that causes git fsck to exit nonzero. Or it
+might be that git fsck found an actual problem, but not one that was
+preventing the repo from working. Eg, a missing/corrupt object used
+somewhere deep in the history.
+
+(Note that git-repair already exists. git-annex integrates it.)
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_1_c7fbc3da4404fb33a4b0babf068dc4d3._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_1_c7fbc3da4404fb33a4b0babf068dc4d3._comment
new file mode 100644
index 0000000000..001f6a85ec
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_1_c7fbc3da4404fb33a4b0babf068dc4d3._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-05-10T14:25:20Z"
+ content="""
+git-annex does not write directly to your git repository; all writes go via
+git. So it is hard to see how any corruption like this could be due to a
+bug in git-annex.
+
+What it usually is caused by is a filesystem losing data, eg because of an
+unclean shutdown or a crash, or sometimes because of a disk error.
+
+Setting the git config core.fsyncObjectFiles may help. Configuring the
+filesystem to write data to disk more promptly (eg enabling journalling of
+file contents) may help.
+
+`git-annex repair --force` may be able to recover from this situation.
+
+The "evacuate: strange closure" error does seem notable, something strange
+is going on in the memory of git-annex. Presumably due to either a compiler
+bug or some kind of memory problem.
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_2_f2368358a0ccdd36a551a2c833cb9c9a._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_2_f2368358a0ccdd36a551a2c833cb9c9a._comment
new file mode 100644
index 0000000000..983c18951f
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_2_f2368358a0ccdd36a551a2c833cb9c9a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 2"
+ date="2021-05-11T07:37:07Z"
+ content="""
+This also looks suspicious:
+
+    Auto packing the repository in background for optimum performance.
+    See \"git help gc\" for manual housekeeping.
+
+And after that something (git-annex?) is complaining about missing git objects. So maybe you can try to set `gc.auto` to `0` and see if that works better.
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_3_f7d921256107773dcb294747cdc38ebd._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_3_f7d921256107773dcb294747cdc38ebd._comment
new file mode 100644
index 0000000000..dec219faf8
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_3_f7d921256107773dcb294747cdc38ebd._comment
@@ -0,0 +1,73 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 3"
+ date="2021-05-12T14:17:05Z"
+ content="""
+The weird thing is, this only ever happens with my Documents git-annex repo, the only one where I use the assistant. It has never happened in 4 years of actively using regular git nor my manually committed and synced git-annex repos.
+
+Another corruption just occured but this time on the MBP:
+
+```
+[2021-05-11 08:04:43.038047] main: starting assistant version 8.20210330
+[2021-05-11 08:04:43.169107] Cronner: Consistency check in progress
+[2021-05-11 08:04:43.175482] TransferScanner: Syncing with SOTERIA 
+(scanning...) [2021-05-11 08:04:43.340744] Watcher: Performing startup scan
+(recording state in git...)
+(recording state in git...)
+(recovering from race...)
+To ssh://192.168.101.24/~/Annex/Documents.git/
+   7b587c48b..4c7b284c5  git-annex -> synced/git-annex
+[2021-05-11 08:04:47.087899] Cronner: Attempting to repair MB-<REDACTED> [here]
+Watcher crashed: PauseWatcher
+[2021-05-11 08:04:47.138205] Watcher: warning Watcher crashed: PauseWatcher
+Unpacking all pack files.
+fatal: early EOF
+[2021-05-11 08:05:27.149344] main: starting assistant version 8.20210330
+[2021-05-11 08:05:27.325057] Cronner: Consistency check in progress
+(recording state in git...)
+error: invalid object 100644 f30c0963ac4560878ae6803608310c289de30e26 for '319/854/SHA256E-s1400--dd4744948961710e8369365e439bb37013c5664ed6d8e58ef21a855a08ff4108.o.log'
+fatal: git-write-tree: error building trees
+.git-annex-wrapped: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
+[2021-05-11 08:05:28.719256] TransferScanner: Syncing with SOTERIA 
+(recording state in git...)
+error: invalid object 100644 f30c0963ac4560878ae6803608310c289de30e26 for '319/854/SHA256E-s1400--dd4744948961710e8369365e439bb37013c5664ed6d8e58ef21a855a08ff4108.o.log'
+fatal: git-write-tree: error building trees
+Merger crashed: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
+[2021-05-11 08:05:28.905248] Merger: warning Merger crashed: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
+Auto packing the repository in background for optimum performance.
+See \"git help gc\" for manual housekeeping.
+error: Could not read d3720891bb000797d5fba08403540f8db208fd7a
+error: Could not read 0fa98c99e87fd34202e68016c39f7ba00b7e3e1a
+error: Could not read 0fa98c99e87fd34202e68016c39f7ba00b7e3e1a
+error: Could not read 0fa98c99e87fd34202e68016c39f7ba00b7e3e1a
+error: Could not read d3720891bb000797d5fba08403540f8db208fd7a
+error: Could not read 0fa98c99e87fd34202e68016c39f7ba00b7e3e1a
+error: Could not read d3720891bb000797d5fba08403540f8db208fd7a
+error: Could not read 0fa98c99e87fd34202e68016c39f7ba00b7e3e1a
+error: Could not read d3720891bb000797d5fba08403540f8db208fd7a
+(recording state in git...)
+error: invalid object 100644 f30c0963ac4560878ae6803608310c289de30e26 for '319/854/SHA256E-s1400--dd4744948961710e8369365e439bb37013c5664ed6d8e58ef21a855a08ff4108.o.log'
+fatal: git-write-tree: error building trees
+TransferScanner crashed: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
+[2021-05-11 08:05:29.430437] TransferScanner: warning TransferScanner crashed: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
+[2021-05-11 08:05:52.410361] main: warning git-annex has been shut down
+```
+
+This happened just after I started the assistant/webapp and you can see that I shut it down in the end.
+
+My filesystems are ZFS on the Linux machine and APFS on the MBP. Being an Apple product, I'd expect APFS to be built to high standards (though I don't fully trust it) but ZFS corrupting anything or losing data is almost unheard of.  
+I'll try setting `core.fsyncObjectFiles` on this repo and update this issue accordingly when I see another corruption with it on. Shouldn't take too long as this occurs worringly frequently.
+
+Btw, repair always fails in my setup because git seems to be unable to find the `SOTERIA` remote; is it trying to use the remote name literally as an address perhaps?
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_4_cf152fccbdb281dcbeb02cb398686ac0._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_4_cf152fccbdb281dcbeb02cb398686ac0._comment
new file mode 100644
index 0000000000..58dcf16bd5
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_4_cf152fccbdb281dcbeb02cb398686ac0._comment
@@ -0,0 +1,85 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 4"
+ date="2021-05-16T10:27:47Z"
+ content="""
+Something peculiar just happened. I had the MBP with me while I was out and was editing documents with no connection to any of my machines.
+
+I usually stop the assistant at home so that it only runs on one machine at a time because of https://git-annex.branchable.com/bugs/OSX__58___Pushed_changes_are_autocommited/ but because I was out, I started it.
+
+On startup, it said that it was trying to repair my repo. I shut it down because it couldn't do any repairs without a connection to my machines (and it wouldn't succeed even if it did unfortunately).
+
+I ran `git fsck` to see what happened but, to my surprise, it returned no errors besides missing reflog entries from previous corruptions. `git gc` didn't error either.
+
+I commited my changes manually while I was out.
+
+That was about two days ago. I synced my changes manually at home where an unrelated and trivial issue happened during which I ran another successful `git fsck` and, after fixing that issue, I started the webapp.  
+It was attempting to repair again and was complaining about a thread having crashed (logs below).
+
+Now however, the repo is actually broken with missing blobs, trees and links everywhere.
+
+daemon.log.1:
+
+```
+[2021-05-16 11:58:04.848709] main: starting assistant version 8.20210330
+[2021-05-16 11:58:04.946261] Cronner: Consistency check in progress
+[2021-05-16 11:58:04.974666] TransferScanner: Syncing with SOTERIA 
+(scanning...) [2021-05-16 11:58:05.191375] Watcher: Performing startup scan
+(recording state in git...)
+(recording state in git...)
+(recovering from race...)
+ControlSocket .git/annex/ssh/atemu@192.168.101.24 already exists, disabling multiplexing
+To ssh://192.168.101.24/~/Annex/Documents.git/
+   343d6291c..184ff9756  git-annex -> synced/git-annex
+[2021-05-16 11:58:09.404901] Cronner: Attempting to repair MB-<REDACTED> [here]
+Watcher crashed: PauseWatcher
+[2021-05-16 11:58:09.445038] Watcher: warning Watcher crashed: PauseWatcher
+Unpacking all pack files.
+fatal: early EOF
+```
+
+daemon.log:
+
+```
+[2021-05-16 11:58:21.699212] main: starting assistant version 8.20210330
+[2021-05-16 11:58:21.778787] Cronner: You should enable consistency checking to protect your data. 
+[2021-05-16 11:58:22.249053] TransferScanner: Syncing with SOTERIA 
+Auto packing the repository in background for optimum performance.
+See \"git help gc\" for manual housekeeping.
+Everything up-to-date
+
+
+
+[2021-05-16 11:58:25.957064] Transferrer: Uploaded <1 pdf file>
+[2021-05-16 11:58:25.95937] Pusher: Syncing with SOTERIA 
+(recording state in git...)
+error: invalid object 100644 3d5a69ecabdbf871de3b7c339b16bc9315ae17e4 for '5d3/ae2/SHA256E-s56534--2de587e678bd455f4346a5304e450eafac892f1a389ee4046cd25948a01789a9.pdf.log.met'
+fatal: git-write-tree: error building trees
+Pusher crashed: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
+[2021-05-16 11:58:26.037969] Pusher: warning Pusher crashed: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
+
+
+[2021-05-16 11:58:28.564268] Transferrer: Uploaded <a bunch of files because I changed numcopies>
+[2021-05-16 11:58:51.983601] Pusher: Syncing with SOTERIA 
+(recording state in git...)
+error: invalid object 100644 3b1a2b60bcb28a299c7e6b706ce3de5808909bcc for '031/bc2/SHA256E-s138590--273323cbd322923f9d19280b6b4fa73bfa3638d2982b685b9efcaee43c988a07.pdf.log.met'
+fatal: git-write-tree: error building trees
+Pusher crashed: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
+[2021-05-16 11:58:52.11129] Pusher: warning Pusher crashed: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
+[2021-05-16 11:59:08.905898] main: warning git-annex has been shut down
+```
+
+I haven't set the fsync option yet but this system hasn't been restarted in a long time and the corruption happened while the system was on; right in front of my eyes basically.
+
+I'll now manually fix the corruption again by rsync'ing the `.git/objects/` dir to the state of a working repo's.
+
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_5_652928a8f8bd0250973f19fa28cbb029._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_5_652928a8f8bd0250973f19fa28cbb029._comment
new file mode 100644
index 0000000000..c5219f996a
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_5_652928a8f8bd0250973f19fa28cbb029._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 5"
+ date="2021-05-18T09:13:32Z"
+ content="""
+Another crash on the Linux machine as I was starting the assistant today. Usually it doesn't happen nearly this frequently though.
+
+`core.fsyncObjectFiles` was set to `true` this time.
+
+log.3 (2d ago 19:xx):
+
+```
+git-annex: internal error: evacuate: strange closure type 4566880
+    (GHC version 8.10.4 for x86_64_unknown_linux)
+    Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
+```
+
+log.2 (today 10:16):
+
+```
+<regular git-annex fsck output>
+ControlSocket .git/annex/ssh/e5a88504f7bbb083855b27a1c1ca4a26 already exists, disabling multiplexing
+To ssh://192.168.101.24/~/Annex/Documents.git/
+   f153f6740..b52bda802  git-annex -> synced/git-annex
+To ssh://git-annex-.MacBook.2DPro.2Efritz.2Ebox-TobiasDe_22_Documents/~/Documents/
+   bb6821230..b52bda802  git-annex -> synced/git-annex
+(started...) 
+Unpacking all pack files.
+fatal: early EOF
+```
+
+at the time of log.1 (10:55), corruption has already set in.
+
+I'm sniffing an issue with the auto-repair feature wrongly detecting corruption, trying to fix it and thereby actually corrupting the repo. I'd like to turn it off for investigation, is that possible somehow? By disabling consistency checks perhaps?
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_6_315606cfa07d2c4b20a6c9ec477c83d1._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_6_315606cfa07d2c4b20a6c9ec477c83d1._comment
new file mode 100644
index 0000000000..f22fc03564
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_6_315606cfa07d2c4b20a6c9ec477c83d1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-05-21T16:26:55Z"
+ content="""
+Note that the strange closure crash is a separate bug,
+and has been fixed in git master. I do not think that bug could corrupt git
+repos since as I mentioned before git-annex doesn't write directly to the
+git repo, so any such bug in it should not be possible to corrupt it.
+
+Anyway, it would probably be a good idea to upgrade to a current daily
+build to get past that bug.
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_7_54aed251ddb9df1c8164a25240e1533f._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_7_54aed251ddb9df1c8164a25240e1533f._comment
new file mode 100644
index 0000000000..61a7cdb3c2
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_7_54aed251ddb9df1c8164a25240e1533f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 7"
+ date="2021-05-22T17:02:07Z"
+ content="""
+What could I do to get to the bottom of this? Is there a verbose logging feature for the assistant that could give more insight?
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_8_a1131917149dd07ec73367e7cbc3b3f2._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_8_a1131917149dd07ec73367e7cbc3b3f2._comment
new file mode 100644
index 0000000000..c893804877
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_8_a1131917149dd07ec73367e7cbc3b3f2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 8"
+ date="2021-05-22T17:19:19Z"
+ content="""
+You could run the equivalent of `strace` for mac os and make it log every syscall of git-annex assistant and it's children. This would show which `git` action corrupts the repo and how.
+"""]]
diff --git a/doc/bugs/Git_repos_corrupt_themselves/comment_9_033def91d2a30f1cee498fabbfe5d37f._comment b/doc/bugs/Git_repos_corrupt_themselves/comment_9_033def91d2a30f1cee498fabbfe5d37f._comment
new file mode 100644
index 0000000000..632afdc356
--- /dev/null
+++ b/doc/bugs/Git_repos_corrupt_themselves/comment_9_033def91d2a30f1cee498fabbfe5d37f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 9"
+ date="2021-05-22T17:31:01Z"
+ content="""
+This also happens on Linux, so I'd rather use `strace` itself but I think it'd be extremely hard to spot anything useful in that and probably is not worth the performance cost.
+"""]]
diff --git a/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time.mdwn b/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time.mdwn
new file mode 100644
index 0000000000..b0bf84a601
--- /dev/null
+++ b/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time.mdwn
@@ -0,0 +1,18 @@
+Hi,
+
+some time ago, I accidentally copied some files from the archive to the non-archive part of my (indirect, type 'client') repository (instead of moving), with the effect that assistant always kept downloading and afterwards immediately dropping the files. Now this was not really surprising once I found the duplicate folder, but maybe git annex could detect this case and refuse to run in circles or at least complain about it.
+
+Best
+Karsten
+
+[[!tag /design/assistant]]
+
+> Update: Current status is this is fixed for direct mode.
+> 
+> In indirect mode, the startup scan will still download and then drop
+> content if a file outside and inside the archive directory has the
+> same content. It doesn't loop like it did in direct mode, only
+> happens once (or once per duplicate file, really). Is still potentially
+> annoying and a bug. --[[Joey]]
+
+[[!tag confirmed]]
diff --git a/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_1_e8bb3d6a2318402b985caed08282d473._comment b/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_1_e8bb3d6a2318402b985caed08282d473._comment
new file mode 100644
index 0000000000..0606fdffbb
--- /dev/null
+++ b/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_1_e8bb3d6a2318402b985caed08282d473._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-11T16:32:43Z"
+ content="""
+This is a known problem.
+
+It seems possible to fix it for direct mode. After all, direct mode tracks all files associated with a key, so it could expose this to preferred content expressions, and the expression check if any of the associated files was in an archive directory.
+
+Unsure how to deal with it in indirect mode. Short of making indirect mode do all the same tracking direct mode does, or otherwise build a key to file lookup table.
+"""]]
diff --git a/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_2_ead9fa75a12ef36be9a92637b144e74f._comment b/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_2_ead9fa75a12ef36be9a92637b144e74f._comment
new file mode 100644
index 0000000000..2be39d451a
--- /dev/null
+++ b/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_2_ead9fa75a12ef36be9a92637b144e74f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-06-15T17:52:36Z"
+ content="""
+This turns out to be much worse in direct mode than in indirect mode.
+
+In indirect mode, it only does extra work during the full startup scan. Suppose there are 3 files with the same content, 1, archive/2, and 3. It will download 1, and then will drop archive/2, and then will download 3. This certainly is not ideal, especially when the file content is large.
+
+In indirect mode, it continally and repeatedly downloads the drops the files, as long as it's running. Which is beyond unacceptable.
+
+What seems to be going on is that when archive/2 gets dropped, it necessary needs to convert 1 and 3 to broken symlinks. But the watcher than sees those file changes, thinks these are new or renamed files that have appeared, and promptly re-downloads them. That, in turn triggers an update of archive/2, to convert it back from symlink to direct mode file, and that in turn is noticed by the watcher. Round and round we go!
+"""]]
diff --git a/doc/bugs/Hard_links_not_synced_in_direct_mode.mdwn b/doc/bugs/Hard_links_not_synced_in_direct_mode.mdwn
new file mode 100644
index 0000000000..03827d4647
--- /dev/null
+++ b/doc/bugs/Hard_links_not_synced_in_direct_mode.mdwn
@@ -0,0 +1,130 @@
+[[!meta title="hard links not synced"]]
+
+### Please describe the problem.
+
+Direct mode repositories seem to initially ignore hard linked files and then when changes are done to them sync them as separate files. However, changes to one file are only propagated to that file and not to any of the others that are hardlinked to it.
+
+### What steps will reproduce the problem?
+
+Inside a direct mode repository linked to a ssh remote:
+
+[[!format sh """
+$ ls -l
+total 0
+$ echo "something" > foo
+$ ln foo bar
+$ ls -l
+total 8
+-rw-r--r-- 2 pedrocr pedrocr 10 May 29 12:08 bar
+-rw-r--r-- 2 pedrocr pedrocr 10 May 29 12:08 foo
+$ tail .git/annex/daemon.log
+   6c0fbd7..0bb8ef9  git-annex -> synced/git-annex
+   0bae1b4..bfedc45  master -> synced/master
+
+sent 77 bytes  received 31 bytes  72.00 bytes/sec
+total size is 10  speedup is 0.09
+[2013-05-29 12:08:03 WEST] Transferrer: Uploaded foo
+Already up-to-date.
+[2013-05-29 12:08:05 WEST] Pusher: Syncing with golias 
+To ssh://golias.git-annex/home/pedrocr/testsync
+   0bb8ef9..2ce5013  git-annex -> synced/git-annex
+$ git status
+# On branch master
+# Changes not staged for commit:
+#   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
+#
+#	typechange: foo
+#
+# Untracked files:
+#   (use "git add <file>..." to include in what will be committed)
+#
+#	bar
+no changes added to commit (use "git add" and/or "git commit -a")
+"""]]
+
+On the remote repository:
+
+[[!format sh """
+$ ls -l
+total 4
+-rw-r--r-- 1 pedrocr pedrocr 10 May 29 12:08 foo
+"""]]
+
+If I now just touch the linked file on the repository:
+
+[[!format sh """
+$ touch bar
+$ tail .git/annex/daemon.log
+
+(merging synced/git-annex into git-annex...)
+(Recording state in git...)
+add bar (checksum...) [2013-05-29 12:12:49 WEST] Committer: Committing changes to git
+[2013-05-29 12:12:49 WEST] Pusher: Syncing with golias 
+Already up-to-date.
+To ssh://golias.git-annex/home/pedrocr/testsync
+   2ce5013..d36166b  git-annex -> synced/git-annex
+   bfedc45..ee3a7a1  master -> synced/master
+Already up-to-date.
+"""]]
+
+On the remote repository:
+
+[[!format sh """
+$ ls -l
+total 8
+-rw-r--r-- 1 pedrocr pedrocr 10 May 29 12:08 bar
+-rw-r--r-- 1 pedrocr pedrocr 10 May 29 12:08 foo
+"""]]
+
+Note that now bar has been synced as a new file and not a hardlink as it should be (the 1's after the permissions). 
+
+The sync also isn't acting properly on the linked files. For example. 
+
+First in the origin repository:
+
+[[!format sh """
+$ cat bar
+something
+$ cat foo
+something
+$ echo "someotherthing" > bar
+$ cat bar
+someotherthing
+$ cat foo
+someotherthing
+"""]]
+
+The result in the destination:
+
+[[!format sh """
+$ cat bar
+someotherthing
+$ cat foo
+something
+"""]]
+
+So even if the intended behavior is for hardlinked files to be synced as two separate files the sync isn't correct because the two files changed in the origin and only one of them changed in the destination. This probably needs to be fixed with actual hard links for real filesystems and with some copying for crippled filesystems.
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+$ git annex version
+git-annex version: 4.20130516.1
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+local repository version: 4
+default repository version: 3
+supported repository versions: 3 4
+upgrade supported from repository versions: 0 1 2
+$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 12.04.2 LTS
+Release:	12.04
+Codename:	precise
+"""]]
+
+
+> [[!taglink confirmed]] (but may be out of scope for git-annex) --[[Joey]] 
+
+[[!meta title="assistant does not notice all changes to hard linked files"]]
diff --git a/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_1_aaa781664ae0c62c4f6530cb075ed367._comment b/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_1_aaa781664ae0c62c4f6530cb075ed367._comment
new file mode 100644
index 0000000000..5d7422c08d
--- /dev/null
+++ b/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_1_aaa781664ae0c62c4f6530cb075ed367._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkx5V3MTbzCXS3J7Mn9FEq8M9bPPYMkAHY"
+ nickname="Pedro"
+ subject="comment 1"
+ date="2013-05-29T11:33:05Z"
+ content="""
+Implementing hard links will probably also require handling the edge case where the user has setup two repositories where one of them spans filesystems. So:
+
+- Repository A is all in a single filesystem
+- Repository B has it's root in one filesystem and them /someotherdirectory/ is another filesystem.
+
+If the user in repository A does a \"ln /somefile /someotherdirectory/otherfile\" you'd need to treat this as in the crippled case as repository B can't do the hardlink spanning filesystems.
+
+Another edge case may also be that OSX supports hardlinked directories for use with their TimeMachine feature. The feature isn't exposed through the normal ln command but users may sometimes hack around that[1]. Also, any TimeMachine backups will naturally have hardlinked directories.
+
+[1] http://stackoverflow.com/questions/1432540/creating-directory-hard-links-in-macos-x
+"""]]
diff --git a/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_2_213aa10909d1fd0f20ed078a7ed93e79._comment b/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_2_213aa10909d1fd0f20ed078a7ed93e79._comment
new file mode 100644
index 0000000000..39d601dba1
--- /dev/null
+++ b/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_2_213aa10909d1fd0f20ed078a7ed93e79._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-05-29T15:39:48Z"
+ content="""
+git does not support hard linked files, so neither can git-annex.
+"""]]
diff --git a/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_3_e6b783d9aaae20c0d35e9888d878716a._comment b/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_3_e6b783d9aaae20c0d35e9888d878716a._comment
new file mode 100644
index 0000000000..179d80b217
--- /dev/null
+++ b/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_3_e6b783d9aaae20c0d35e9888d878716a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-05-29T16:11:46Z"
+ content="""
+It would be possible to make the assistant use the inotify CREATE event (which it currently ignores) to add a file to the repository when a hard link is created. However, when a hard linked file is modified, inotify only sends an event for the file that was changed, not for other hard links to it. So, without keeping track of all hard links that exist on my own, there's no way for the assistant to automatically handle that case. And even if it tried to, hard links to files in the repository from outside the repository would still allow modifying them without the assistant being able to detect it.
+
+Since hard links cannot be propigated over git anyway, I don't want to get into this mess. It's best to wontfix this I think.
+"""]]
diff --git a/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_4_b008ae7b1cf8685d92c9a87a7609de1e._comment b/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_4_b008ae7b1cf8685d92c9a87a7609de1e._comment
new file mode 100644
index 0000000000..8e8acd9cb7
--- /dev/null
+++ b/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_4_b008ae7b1cf8685d92c9a87a7609de1e._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkx5V3MTbzCXS3J7Mn9FEq8M9bPPYMkAHY"
+ nickname="Pedro"
+ subject="comment 4"
+ date="2013-05-29T18:48:10Z"
+ content="""
+I agree with your assessment for the traditional git-annex, as it's an extension of git. For the assistant (in direct mode at least) it seems like broken behavior, there will be files that exist on one side but not the other and files that have the same content on one side but not the other.
+
+I just had a look and unfortunately there doesn't seem to be a general way to do inode to path lookup in UNIX, so an inode cache would really be needed. It would look something like:
+
+* On inotify CREATE detect that the file has other hardlinked instances, find out if they are in the repository by keeping a inode->path cache of all files
+* When the file is a hardlink to another file already in the repository commit some kind of special file to git that states \"hardlink to /path/to/otherfile\" and add metadata to the original file saying what files are hardlinks to it
+* When a remote gets a special file after a sync it will itself run a \"ln /path/to/otherfile /path/to/newfile\" or alteratively a copy when the two paths span filesystems or the filesystem is crippled
+* When a crippled remote gets a write to a file with hardlinks, it will replicate those writes to the other files (this is where the metadata is needed)
+* When a crippled remote does a write to a file with hardlinks that file becomes independent in the remotes with hardlinks since the content is now different between the two (or more) files.
+
+This does get pretty hairy with the corner cases. Right now the simple case of \"sync between two non-crippled filesystems\" shows pretty surprising results though so I'd argue something needs to change. I think that for direct mode to really be a \"transparent folder sync\" kind of solution this should be fixed.
+"""]]
diff --git a/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_5_949c891209713a2c0a5e66af11ed4c79._comment b/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_5_949c891209713a2c0a5e66af11ed4c79._comment
new file mode 100644
index 0000000000..52f3e30f7d
--- /dev/null
+++ b/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_5_949c891209713a2c0a5e66af11ed4c79._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 5"
+ date="2013-06-26T16:34:23Z"
+ content="""
+To fix [[Problems_with_syncing_gnucash]], I have made some changes to how hard links are dealt with.
+
+Assistant will now notice when a hard link is created, and add the same thing to git it would add for any other file. The hard link is not propigated to other repositories.
+
+Files remain hard linked locally. This means that a change to one will affect the contents of the other. The assistant, lacking a hard link cache, will not notice this, and so will commit the change to the file that was written to, but not commit its hard link. Running `git annex add` manually (or restarting the assistant) will make it finally notice the other file has changed. 
+
+So, the assistant still does not keep hard links in sync on an ongoing basis. This bug is still unsolved.
+"""]]
diff --git a/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_6_12379a8e89ce8505123f5b24f3dbbaca._comment b/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_6_12379a8e89ce8505123f5b24f3dbbaca._comment
new file mode 100644
index 0000000000..1164b6066a
--- /dev/null
+++ b/doc/bugs/Hard_links_not_synced_in_direct_mode/comment_6_12379a8e89ce8505123f5b24f3dbbaca._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2019-09-11T17:24:38Z"
+ content="""
+This bug is not specific to direct mode; in v7 adjusted unlocked branch
+the assistant behaves the same as it did in my last comment above.
+"""]]
diff --git a/doc/bugs/Homebrew_build_broken.mdwn b/doc/bugs/Homebrew_build_broken.mdwn
new file mode 100644
index 0000000000..20f30d81ff
--- /dev/null
+++ b/doc/bugs/Homebrew_build_broken.mdwn
@@ -0,0 +1,3 @@
+[The PR to upgrade git-annex in Homebrew to 10.20230126](https://github.com/Homebrew/homebrew-core/pull/121594) is currently stalled because of a build failure.  The error message seems to imply the problem is due to a faulty `.cabal` file, which would mean it's a problem with the git-annex source itself.
+
+> [[fixed|done]] in homebrew --[[Joey]]
diff --git a/doc/bugs/Homebrew_build_broken/comment_1_c30517144c98faaf592b0e8e2bcc7db4._comment b/doc/bugs/Homebrew_build_broken/comment_1_c30517144c98faaf592b0e8e2bcc7db4._comment
new file mode 100644
index 0000000000..0680a12e2d
--- /dev/null
+++ b/doc/bugs/Homebrew_build_broken/comment_1_c30517144c98faaf592b0e8e2bcc7db4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-02-06T16:38:38Z"
+ content="""
+I don't think this is a problem with the cabal file. It has the necessary
+build-depends on async.
+
+This seems to be some sort of toolchain problem. But not one that affects
+other builds on OSX.
+
+I doubt that there is a change I can make to the source code that will help
+them.
+"""]]
diff --git a/doc/bugs/Homebrew_build_broken/comment_2_d3f253a12a77fe4a354144880d0a4935._comment b/doc/bugs/Homebrew_build_broken/comment_2_d3f253a12a77fe4a354144880d0a4935._comment
new file mode 100644
index 0000000000..677a98af02
--- /dev/null
+++ b/doc/bugs/Homebrew_build_broken/comment_2_d3f253a12a77fe4a354144880d0a4935._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-06-21T17:53:22Z"
+ content="""
+Looks like homebrew fixed the build on their side, closing this.
+"""]]
diff --git a/doc/bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo.mdwn b/doc/bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo.mdwn
new file mode 100644
index 0000000000..93c9f48cef
--- /dev/null
+++ b/doc/bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo.mdwn
@@ -0,0 +1,234 @@
+### Please describe the problem.
+
+When trying to link/create Rsync.net report (linked already to unix laptop) on android via webapp it fails in resolving hostname. Using dig in Termux resolves the hostname fine, verified no typos. Verified same behaviour whether using WiFI or Cell Data network
+
+### What steps will reproduce the problem?
+
+Via webapp, normal process for adding rsync.net repository. Using default annex folder, my assigned hostname from RSync is 'usw-s007.rsync.net' (without quotes :) and that syncs fine with my linux laptop
+
+### What version of git-annex are you using? On what operating system?
+
+$ git-annex version
+git-annex version: 8.20200523-g3ece3aafe
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux aarch64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+
+Phone is a Blackberry KeyOne (BBB100-7) Running Android 8.1.0
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+[2020-06-19 21:29:59.980193661] main: starting assistant version 8.20200523-g3ece3aafe
+[2020-06-19 21:30:00.155131422] Cronner: You should enable consistency checking to protect your data. 
+
+  dbus failed; falling back to mtab polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 13>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 13>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+(scanning...) [2020-06-19 21:30:00.573055119] Watcher: Performing startup scan
+(started...) 
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 46>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 46>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 48>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 54>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 63>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 82>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 78>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 78>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 85>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 78>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 78>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 78>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 78>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 78>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 78>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 78>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 78>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 78>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+[2020-06-19 21:48:35.922714798] UpgradeWatcher: A new version of git-annex has been installed. 
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+  lost dbus connection; falling back to polling (SocketError {socketErrorMessage = "Network.Socket.connect: <socket: 30>: does not exist (No such file or directory)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:path=/var/run/dbus/system_bus_socket")})
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Only recently came across it :) but sufficiently excited about prospects that I signed up at rsync.net for a year. Works great thus far on my Qubes laptop (currently only running it from one of my Fedora 30 VMs but looking at other ways of leveraging it as I dig further.
+
diff --git a/doc/bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo/comment_1_a7a613c3fa1bee42442a446366027381._comment b/doc/bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo/comment_1_a7a613c3fa1bee42442a446366027381._comment
new file mode 100644
index 0000000000..71c50228ef
--- /dev/null
+++ b/doc/bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo/comment_1_a7a613c3fa1bee42442a446366027381._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="gitannexuser2021"
+ avatar="http://cdn.libravatar.org/avatar/e0d5a0aa4ca494b520a971c53865edcd"
+ subject="Still seeing the issue."
+ date="2021-10-19T22:37:44Z"
+ content="""
+I'm using termux to install git-annex on my android. When trying to add Rsync.net repo, the provided hostname cannot be resolved. Adding repo on my laptop (linux) works normally. I'm able to ping the hostname via termux successfully.
+"""]]
diff --git a/doc/bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo/comment_2_97bf976e0e04fb27916e245eb9c7709d._comment b/doc/bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo/comment_2_97bf976e0e04fb27916e245eb9c7709d._comment
new file mode 100644
index 0000000000..706e54e995
--- /dev/null
+++ b/doc/bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo/comment_2_97bf976e0e04fb27916e245eb9c7709d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-10-20T17:52:23Z"
+ content="""
+This is not limited to rsync.net, other DNS lookups by git-annex also fail.
+
+Without investigating, my strong hunch is that this is because git-annex is
+linked to glibc, and so it expects there to be /etc/nssswitch.conf,
+/etc/resolv.conf, /etc/services etc that glibc uses. And
+some/all of those files are not present on Android. If you were able to set
+up the files, it would probably work.
+"""]]
diff --git a/doc/bugs/How_to_git_union-merge__63__.mdwn b/doc/bugs/How_to_git_union-merge__63__.mdwn
new file mode 100644
index 0000000000..3272cd2508
--- /dev/null
+++ b/doc/bugs/How_to_git_union-merge__63__.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+It's unclear how to use `git union-merge` as described [here](https://git-annex.branchable.com/git-union-merge/).
+
+### What steps will reproduce the problem?
+
+Run `git union-merge`, yields `git: 'union-merge' is not a git command. See 'git --help'.`
+
+No binary `git-union-merge` is shipped in the standalone tarball and distros also don't seem to ship it.
+
+### What version of git-annex are you using? On what operating system?
+
+Tried with (on a Manjaro box):
+
+- git-annex-standalone-amd64.tar.gz	2023-10-09 14:21 	51M	 from [here](https://downloads.kitenet.net/git-annex/linux/current/) (the build is a month old, is that right?)
+- `git-annex` in Manjaro repos
+- `git-annex-standalone-nightly-bin` from AUR
+- `nix-shell -p git-annex` (10.20230926 in nixos-unstable)
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git-annex rules and is a marvelous tool.
+
+I wanted to try the union merging to resolve merge conflicts on non-annexed files. It's not ideal, but might be better than repeated `git annex assist|sync` eventually adding the merge conflict markers `<<<<<<<<<` and the like to the files, breaking things like `.gitattributes` syntax which in turn has more devastating lockup consequences...
diff --git a/doc/bugs/How_to_git_union-merge__63__/comment_1_58b6c9712d7c209248d9ef87bcc0e110._comment b/doc/bugs/How_to_git_union-merge__63__/comment_1_58b6c9712d7c209248d9ef87bcc0e110._comment
new file mode 100644
index 0000000000..00f291361a
--- /dev/null
+++ b/doc/bugs/How_to_git_union-merge__63__/comment_1_58b6c9712d7c209248d9ef87bcc0e110._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-11-21T20:12:11Z"
+ content="""
+I think I should probably just remove that. It's not being maintained.
+
+Adding it to the cabal file so it gets built would slow down builds
+producing this extra binary. It would need to be handled as a multicall
+program in git-annex the way git-annex-shell and git-remote-tor-annex are.
+
+Do you have a reason to want to use it?
+"""]]
diff --git a/doc/bugs/How_to_git_union-merge__63__/comment_2_22701b82e8d53acff66ddea5bf9448bf._comment b/doc/bugs/How_to_git_union-merge__63__/comment_2_22701b82e8d53acff66ddea5bf9448bf._comment
new file mode 100644
index 0000000000..63edd6f659
--- /dev/null
+++ b/doc/bugs/How_to_git_union-merge__63__/comment_2_22701b82e8d53acff66ddea5bf9448bf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2023-11-21T20:20:13Z"
+ content="""
+It sounds promising as an automatic merge conflict resolver that I'd like to fall back to for non-annexed file conflicts. I don't really know how do achieve that manually. If it's easily possible in another way, I'll try that.
+"""]]
diff --git a/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files.mdwn b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files.mdwn
new file mode 100644
index 0000000000..e4b785a01a
--- /dev/null
+++ b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files.mdwn
@@ -0,0 +1,118 @@
+### Please describe the problem.
+
+I had to migrate a special remote using hybrid encryption from an Amazon Cloud Drive-hosted rclone remote to a Google Drive-hosted rclone remote. Now I am testing it by trying to fsck a particular file.
+
+I've left all of the special remote settings on the git annex side the same, and just changed my `.rclone.conf` to have "amazondrive", the rclone remote name, actually point to the new Google Drive location.
+
+When I try to fsck my file, git annex generates an HMAC key, successfully downloads it from the remote, but then fails to decrypt it. After that, it looks like it retries: it generates a **different HMAC key**, which it can't find the file for.
+
+I've compared the files in Amazon and in Google Drive and they are the same.
+
+Using the [independent decryption script](https://git-annex.branchable.com/tips/Decrypting_files_in_special_remotes_without_git-annex/), modified to use the SHA512 MAC that my repo uses, and to not use every matching line from `remote.log`, I can generate the *second* HMAC key that git annex appears to fall back to, but not the first one. I think that this means I can't generate the decryption key either; I've had no luck manually decrypting the file with the characters after the first 256 of the decrypted shared key as the GPG passphrase.
+
+How is Git Annex generating that first HMAC, if not by the process used in the decryption script? Why is it able to get an HMAC that exists but not a valid decryption key? What is the thinking behind trying multiple HMAC keys for the same file?
+
+### What steps will reproduce the problem?
+
+Have an encrypted, hybrid Git Annex repo in an Amazon Drive rclone remote.
+Copy all the files over to Google Drive, and make a Google Drive rclone remote in rclone.conf with the same name that the Amazon Drive one had.
+Try to retrieve files from the remote with Git Annex.
+
+### What version of git-annex are you using? On what operating system?
+
+`6.20170525+gitge1cf095ae-1~ndall+1` on Ubuntu 16.04
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+$ git annex fsck info.txt --from=amazon --debug
+[2017-06-03 11:24:31.368563623] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2017-06-03 11:24:31.373358653] process done ExitSuccess
+[2017-06-03 11:24:31.373520685] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2017-06-03 11:24:31.379319755] process done ExitSuccess
+[2017-06-03 11:24:31.382954929] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2017-06-03 11:24:31.386196477] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2017-06-03 11:24:31.392852081] read: git ["config","--null","--list"]
+[2017-06-03 11:24:31.397686571] process done ExitSuccess
+[2017-06-03 11:24:31.400187312] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","info.txt"]
+[2017-06-03 11:24:31.424951599] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+[2017-06-03 11:24:31.425544622] read: git ["--version"]
+[2017-06-03 11:24:31.428009953] process done ExitSuccess
+fsck info.txt [2017-06-03 11:24:31.479360829] chat: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"]
+[2017-06-03 11:24:31.503040759] process done ExitSuccess
+[2017-06-03 11:24:31.506638987] chat: /home/anovak/bin/git-annex-remote-rclone []
+[2017-06-03 11:24:31.510094668] git-annex-remote-rclone[1] --> VERSION 1
+[2017-06-03 11:24:31.510281634] git-annex-remote-rclone[1] <-- PREPARE
+[2017-06-03 11:24:31.511006098] git-annex-remote-rclone[1] --> GETCONFIG prefix
+[2017-06-03 11:24:31.511148645] git-annex-remote-rclone[1] <-- VALUE data/annex-rclone
+[2017-06-03 11:24:31.515487261] git-annex-remote-rclone[1] --> GETCONFIG target
+[2017-06-03 11:24:31.515770189] git-annex-remote-rclone[1] <-- VALUE amazondrive
+[2017-06-03 11:24:31.519503001] git-annex-remote-rclone[1] --> GETCONFIG rclone_layout
+[2017-06-03 11:24:31.519666709] git-annex-remote-rclone[1] <-- VALUE lower
+[2017-06-03 11:24:31.523726589] git-annex-remote-rclone[1] --> PREPARE-SUCCESS
+[2017-06-03 11:24:31.523902589] git-annex-remote-rclone[1] <-- CHECKPRESENT GPGHMACSHA512--4354571263cd241ac8300e0bd8fc3643c184b922500c3d9318b7ce590684e1de820d41c0b245f1595e0bd38b2844a5151192981b4f9ab41bda135d5f7a184d16
+[2017-06-03 11:24:31.530946791] git-annex-remote-rclone[1] --> DIRHASH-LOWER GPGHMACSHA512--4354571263cd241ac8300e0bd8fc3643c184b922500c3d9318b7ce590684e1de820d41c0b245f1595e0bd38b2844a5151192981b4f9ab41bda135d5f7a184d16
+[2017-06-03 11:24:31.531236912] git-annex-remote-rclone[1] <-- VALUE b95/785/
+Total objects: 1 Total size: 119 Bytes (119 Bytes) 2017/06/03 11:24:42 Transferred: 0 Bytes (0 Bytes/s) Errors: 0 Checks: 0 Transferred: 0 Elapsed time: 10.4s
+[2017-06-03 11:24:42.04576211] git-annex-remote-rclone[1] --> CHECKPRESENT-SUCCESS GPGHMACSHA512--4354571263cd241ac8300e0bd8fc3643c184b922500c3d9318b7ce590684e1de820d41c0b245f1595e0bd38b2844a5151192981b4f9ab41bda135d5f7a184d16
+
+[2017-06-03 11:24:42.049286934] git-annex-remote-rclone[1] <-- TRANSFER RETRIEVE GPGHMACSHA512--4354571263cd241ac8300e0bd8fc3643c184b922500c3d9318b7ce590684e1de820d41c0b245f1595e0bd38b2844a5151192981b4f9ab41bda135d5f7a184d16 .git/annex/tmp/GPGHMACSHA512--4354571263cd241ac8300e0bd8fc3643c184b922500c3d9318b7ce590684e1de820d41c0b245f1595e0bd38b2844a5151192981b4f9ab41bda135d5f7a184d16
+[2017-06-03 11:24:42.050298028] git-annex-remote-rclone[1] --> DIRHASH-LOWER GPGHMACSHA512--4354571263cd241ac8300e0bd8fc3643c184b922500c3d9318b7ce590684e1de820d41c0b245f1595e0bd38b2844a5151192981b4f9ab41bda135d5f7a184d16
+[2017-06-03 11:24:42.05045573] git-annex-remote-rclone[1] <-- VALUE b95/785/
+2017/06/03 11:24:52 Local file system at /tmp/tmp.ITXaCoES4i: Waiting for checks to finish
+2017/06/03 11:24:52 Local file system at /tmp/tmp.ITXaCoES4i: Waiting for transfers to finish
+2017/06/03 11:24:54 
+Transferred:    119 Bytes (9 Bytes/s)
+Errors:                 0
+Checks:                 0
+Transferred:            1
+Elapsed time:         12s
+[2017-06-03 11:24:54.083003717] git-annex-remote-rclone[1] --> TRANSFER-SUCCESS RETRIEVE GPGHMACSHA512--4354571263cd241ac8300e0bd8fc3643c184b922500c3d9318b7ce590684e1de820d41c0b245f1595e0bd38b2844a5151192981b4f9ab41bda135d5f7a184d16
+[2017-06-03 11:24:54.083554696] chat: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--batch","--passphrase-fd","22","--decrypt"]
+gpg: decryption failed: bad key
+[2017-06-03 11:24:54.086768586] process done ExitFailure 2
+[2017-06-03 11:24:54.088931923] git-annex-remote-rclone[1] <-- TRANSFER RETRIEVE GPGHMACSHA512--7439fc103f30635cd914af0ce14370aef2f9a81f415ba7a652bc20454c90893bcd5701ebbed855f6a0285fce413e5c039c15a7049738cf519e2719c9d485ce28 .git/annex/tmp/GPGHMACSHA512--7439fc103f30635cd914af0ce14370aef2f9a81f415ba7a652bc20454c90893bcd5701ebbed855f6a0285fce413e5c039c15a7049738cf519e2719c9d485ce28
+[2017-06-03 11:24:54.089806756] git-annex-remote-rclone[1] --> DIRHASH-LOWER GPGHMACSHA512--7439fc103f30635cd914af0ce14370aef2f9a81f415ba7a652bc20454c90893bcd5701ebbed855f6a0285fce413e5c039c15a7049738cf519e2719c9d485ce28
+[2017-06-03 11:24:54.090050153] git-annex-remote-rclone[1] <-- VALUE b47/e54/
+2017/06/03 11:25:03 Local file system at /tmp/tmp.5lapDbIoZy: Waiting for checks to finish
+2017/06/03 11:25:03 Local file system at /tmp/tmp.5lapDbIoZy: Waiting for transfers to finish
+2017/06/03 11:25:03 Attempt 1/3 failed with 0 errors and: directory not found
+2017/06/03 11:25:03 Local file system at /tmp/tmp.5lapDbIoZy: Waiting for checks to finish
+2017/06/03 11:25:03 Local file system at /tmp/tmp.5lapDbIoZy: Waiting for transfers to finish
+2017/06/03 11:25:03 Attempt 2/3 failed with 0 errors and: directory not found
+2017/06/03 11:25:04 Local file system at /tmp/tmp.5lapDbIoZy: Waiting for checks to finish
+2017/06/03 11:25:04 Local file system at /tmp/tmp.5lapDbIoZy: Waiting for transfers to finish
+2017/06/03 11:25:04 Attempt 3/3 failed with 0 errors and: directory not found
+2017/06/03 11:25:04 Failed to copy: directory not found
+[2017-06-03 11:25:04.479940212] git-annex-remote-rclone[1] --> TRANSFER-FAILURE RETRIEVE GPGHMACSHA512--7439fc103f30635cd914af0ce14370aef2f9a81f415ba7a652bc20454c90893bcd5701ebbed855f6a0285fce413e5c039c15a7049738cf519e2719c9d485ce28
+
+  failed to download file from remote
+failed
+[2017-06-03 11:25:04.492702185] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]
+[2017-06-03 11:25:04.494054942] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+[2017-06-03 11:25:04.672344301] process done ExitSuccess
+[2017-06-03 11:25:04.67255166] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2017-06-03 11:25:04.68070068] process done ExitSuccess
+(recording state in git...)
+[2017-06-03 11:25:04.680983817] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2017-06-03 11:25:04.900456464] process done ExitSuccess
+[2017-06-03 11:25:04.900643429] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","a8fc26b91dab1ffac0499d3e21c0f691858d3a6a","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2017-06-03 11:25:04.965122443] process done ExitSuccess
+[2017-06-03 11:25:04.965288386] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","c0b297184826849d8a24c899faa9f4f47c1f8e53"]
+[2017-06-03 11:25:04.970235879] process done ExitSuccess
+[2017-06-03 11:25:04.971493023] process done ExitSuccess
+git-annex: fsck: 1 failed
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yeah, it works great most of the time, and it was working great on the amazon remote before I tried to pull these migration shenanigans.
+
+> Closing this since there has been no response for information for 5
+> years. [[done]] --[[Joey]]
diff --git a/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_1_bbc1e7205d7701afd405c6e62a1c0aa3._comment b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_1_bbc1e7205d7701afd405c6e62a1c0aa3._comment
new file mode 100644
index 0000000000..7d03495191
--- /dev/null
+++ b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_1_bbc1e7205d7701afd405c6e62a1c0aa3._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="yibe"
+ avatar="http://cdn.libravatar.org/avatar/649c9e417b6c509a17f7b48caf065c91"
+ subject="comment 1"
+ date="2017-06-04T20:07:31Z"
+ content="""
+Hello,
+
+I have no idea why git-annex fails to decrypt your file, but as for the two different HMAC keys, I guess you have chunking enabled on that remote (at least when you uploaded the file) and that first HMAC key is the right key for the 1st chunk of your file. That decryption script does not take chunks into account, so you were only able to generate the second HMAC key, which should be the right key if the file was uploaded without chunking enabled. I've just [posted][1] a modified version of the script that supports chunks.
+
+[1]: http://git-annex.branchable.com/tips/Decrypting_files_in_special_remotes_without_git-annex/#comment-ea2df7b4739f3d66c169bf297e339e9d
+
+"""]]
diff --git a/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_2_52a1800537f1244ad6cf417c5f25ebe0._comment b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_2_52a1800537f1244ad6cf417c5f25ebe0._comment
new file mode 100644
index 0000000000..07fa485449
--- /dev/null
+++ b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_2_52a1800537f1244ad6cf417c5f25ebe0._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-06-06T15:38:24Z"
+ content="""
+Your remote has chunking enabled, so git-annex first tries generating a
+HMAC for a chunked key. When decrypting the content fails for some reason,
+it falls back to trying the HMAC for an unchunked key. This is done because
+chunking can be enabled after some content has been uploaded to a remote,
+so it always tries the unchunked location just in case.
+
+It looks like gpg is successfully decrypting the hybrid encryption key
+that's embedded in your git repository. That is the first, successful
+call tp gpg in your log.
+
+The "bad key" error then comes when gpg is asked to use the hybrid
+encryption key to decrypt the content. This seems to indicate it's not
+using the same hybrid encryption key that was used to encrypt it.
+
+The fact that it was able to generate the right HMAC key to download the
+content though, indicates that it did get the right hybrid encryption key
+(since half of that key is used to generate the HMAC).
+
+So hmm, I don't understand what is going on.
+
+Are you able to retrieve the same file successfully when the rclone.conf
+is configured to use the Amazon Cloud Drive? (Assuming that the content of
+the file is still present over there.)
+"""]]
diff --git a/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_3_414bd487619e46b25e8d9a57d9aef1f6._comment b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_3_414bd487619e46b25e8d9a57d9aef1f6._comment
new file mode 100644
index 0000000000..bc136ec452
--- /dev/null
+++ b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_3_414bd487619e46b25e8d9a57d9aef1f6._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="interfect@b151490178830f44348aa57b77ad58c7d18e8fe7"
+ nickname="interfect"
+ avatar="http://cdn.libravatar.org/avatar/3ba541a3204f4ea4b274049a152489c5"
+ subject="comment 3"
+ date="2017-06-09T01:40:00Z"
+ content="""
+Unfortunately even though the content is still over at Amazon, ACD can no longer be accessed through rclone, so I can't get Git Annex to go over there and download it.
+
+With the new chunk-supporting decryption script (which I further modified to actually use the timestamps on the log entries), I am able to generate the right key for my test file. I was also able to generate the key for and decrypt another test file, and then testing with git annex again shows that I can successfully fsck other file in the remote.
+
+I think what is happening is that my small file I was testing with somehow became corrupted or was modified while on Amazon's servers. I downloaded from Amazon before the transfer and from Google after and did a diff, and both files are identical, so I think I moved over corrupt data. 
+
+It looks like git annex is just successfully doing its job and identifying some data corruption here. The bug can probably be closed.
+
+
+"""]]
diff --git a/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_4_81abd2627672911ba6367effbf5c487b._comment b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_4_81abd2627672911ba6367effbf5c487b._comment
new file mode 100644
index 0000000000..66c23ee4ff
--- /dev/null
+++ b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_4_81abd2627672911ba6367effbf5c487b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="interfect@b151490178830f44348aa57b77ad58c7d18e8fe7"
+ nickname="interfect"
+ avatar="http://cdn.libravatar.org/avatar/3ba541a3204f4ea4b274049a152489c5"
+ subject="comment 4"
+ date="2017-06-09T01:48:15Z"
+ content="""
+I'm actually seeing a lot of files (mostly smaller ones, for some reason) failing to fsck because GPG decryption failed. I can't tell at the moment whether they got corrupted in the transfer, or corrupted in the initial upload somehow. I'm pretty sure the problem here isn't with git annex itself, or more people would have noticed, but I'm definitely going to be fscking my cloud remotes more frequently.
+"""]]
diff --git a/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_5_ce0342e38a87017ad58c9a79b17d759a._comment b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_5_ce0342e38a87017ad58c9a79b17d759a._comment
new file mode 100644
index 0000000000..d20a6e6a13
--- /dev/null
+++ b/doc/bugs/Hybrid_encryption_can__39__t_generate_the_right_key_after_moving_files/comment_5_ce0342e38a87017ad58c9a79b17d759a._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-06-09T17:04:09Z"
+ content="""
+"I think what is happening is that my small file I was testing with somehow
+became corrupted or was modified while on Amazon's servers."
+
+That was also kind of my guess. It's hard to imagine how
+the way that a file is downloaded from The Cloud changes
+how git-annex decrypts it. As long as the content is the same,
+the decrpytion step should behave identially no matter where
+the file is downloaded from.
+
+But, multiple small files getting corrupted seems like it must
+have a cause other than a bit flip. Perhaps something about how
+they were transferred between the two clouds corrupted them..
+
+I suppose there could also be a bug in git-annex or rclone that somehow
+corrupts uploads of small files. Perhaps something to do with chunking..
+What does `git annex info theremote --fast` say about its configuration?
+
+What is the range of sizes of small files that you've found to be
+corrupted? Is there a cut-off point after which all larger files are
+not corrupted? Are any small files not corrupted?
+"""]]
diff --git a/doc/bugs/Impossible_to_enable_an_existing_gcrypt_repo_in_the_webapp.mdwn b/doc/bugs/Impossible_to_enable_an_existing_gcrypt_repo_in_the_webapp.mdwn
new file mode 100644
index 0000000000..d9bae50190
--- /dev/null
+++ b/doc/bugs/Impossible_to_enable_an_existing_gcrypt_repo_in_the_webapp.mdwn
@@ -0,0 +1,23 @@
+### Please describe the problem.
+As described earlier in [[tips/fully_encrypted_git_repositories_with_gcrypt]]
+
+### What steps will reproduce the problem?
+- A: use the webapp to create a new repository
+- A: add a remote server to the repository using the 'gcrypt' method
+- A: add a jabber account
+
+- B: use the webapp to create a new repository
+- B: add the jabber account
+- B: see the previously created 'cloud repository' with status 'not enabled'
+- B: click enable, see that the stored credentials are correct, and press "verify this server"
+- B: enter the ssh password twice
+- B: get redirected to a blank screen (on the url /config/repository/enable/gcrypt/UUID "x"?auth=y)
+
+The assistent logfiles show nothing after the "Your public key has been saved in", the server shows that no public key for B was added to the account.
+
+This is with git-annex installed on the remote server; without it the process gets stuck after clicking "encrypt repository" in step 2, it will just indefinitely keep prompting for the SSH password.
+
+### What version of git-annex are you using? On what operating system?
+Latest nightly build on ubuntu 13.10
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Impossible_to_enable_an_existing_gcrypt_repo_in_the_webapp/comment_1_17814787e333d15da3ab4e57c7d31d4b._comment b/doc/bugs/Impossible_to_enable_an_existing_gcrypt_repo_in_the_webapp/comment_1_17814787e333d15da3ab4e57c7d31d4b._comment
new file mode 100644
index 0000000000..5bd45d6866
--- /dev/null
+++ b/doc/bugs/Impossible_to_enable_an_existing_gcrypt_repo_in_the_webapp/comment_1_17814787e333d15da3ab4e57c7d31d4b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 1"
+ date="2013-11-13T16:51:40Z"
+ content="""
+I've tried to reproduce this, and cannot; it enabled the repository without trouble.
+
+Also, I have never seen the webapp fail with a blank screen, so that's strange.
+
+I think you need to show your `~/annex/.git/annex/daemon.log` from B.
+"""]]
diff --git a/doc/bugs/Incompatibility_with_git_2.37.mdwn b/doc/bugs/Incompatibility_with_git_2.37.mdwn
new file mode 100644
index 0000000000..3544c30c37
--- /dev/null
+++ b/doc/bugs/Incompatibility_with_git_2.37.mdwn
@@ -0,0 +1,55 @@
+### Please describe the problem.
+
+Starting with git 2.37, `git annex init` fails with a lock issue.
+
+### What steps will reproduce the problem?
+
+Run `git annex init` with git version > 2.36 (I tested 2.37.0 and 2.37.1)
+
+### What version of git-annex are you using? On what operating system?
+
+10.20220624-g17e4081d4 on Arch Linux
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+arno@genie ⛁ /tmp/annex_test 
+ ★ rm -rf .git
+
+arno@genie ⛁ /tmp/annex_test 
+ ★ git init
+Initialized empty Git repository in /tmp/annex_test/.git/
+
+arno@genie ⛁ /tmp/annex_test 
+ ★ git annex init test
+init test fatal: Unable to create '/tmp/annex_test/.git/annex/index.lock': File exists.
+
+Another git process seems to be running in this repository, e.g.
+an editor opened by 'git commit'. Please make sure all processes
+are terminated then try again. If it still fails, a git process
+may have crashed in this repository earlier:
+remove the file manually to continue.
+
+git-annex: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
+failed
+init: 1 failed
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes ! git-annex is my goto tool for file storage.
+
+
+> [[done]]; this is a bug in git and will have to be fixed there.
+> (git-annex could work around it by making sure the index file
+> exists before calling write-tree, but I don't think it makes sense to
+> work around a segfault bug like that, at least not unless it gets
+> into some stable release of an OS...)
+> --[[Joey]]
diff --git a/doc/bugs/Incompatibility_with_git_2.37/comment_1_c24657bb9d3b3072698572c4e75ccb5d._comment b/doc/bugs/Incompatibility_with_git_2.37/comment_1_c24657bb9d3b3072698572c4e75ccb5d._comment
new file mode 100644
index 0000000000..a18f60cbec
--- /dev/null
+++ b/doc/bugs/Incompatibility_with_git_2.37/comment_1_c24657bb9d3b3072698572c4e75ccb5d._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="akspecs@fae4f3d58a0c6c9d50f01a850ce53d425e1a90ba"
+ nickname="akspecs"
+ avatar="http://cdn.libravatar.org/avatar/43d7148aaa9adf3a40c42e3388123326"
+ subject="cannot reproduce"
+ date="2022-07-19T12:53:45Z"
+ content="""
+```
+$ pacman -Q git-annex
+git-annex 10.20220624-14
+
+$ git annex version
+git-annex version: 10.20220624-g17e4081d4
+...
+
+$ git --version
+git version 2.37.1
+
+$ mkdir annex_test
+$ cd annex_test
+$ git init
+Initialized empty Git repository in /tmp/annex_test/.git/
+
+$ git annex init test
+init test ok
+(recording state in git...)
+
+$ git annex info
+trusted repositories: 0
+semitrusted repositories: 3
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	83b33af6-29d2-4568-aa96-f7ef94667784 -- test [here]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 8.23 gigabytes (+1 megabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 0
+size of annexed files in working tree: 0 bytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+```
+"""]]
diff --git a/doc/bugs/Incompatibility_with_git_2.37/comment_2_4d5eb77736e8512affc25e7bdd5190f1._comment b/doc/bugs/Incompatibility_with_git_2.37/comment_2_4d5eb77736e8512affc25e7bdd5190f1._comment
new file mode 100644
index 0000000000..b03714d4a2
--- /dev/null
+++ b/doc/bugs/Incompatibility_with_git_2.37/comment_2_4d5eb77736e8512affc25e7bdd5190f1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="arnaud@c1d1cc612a3921dc06a417301be08a3e125478c4"
+ nickname="arnaud"
+ avatar="http://cdn.libravatar.org/avatar/c0defbf54541c499f6c0464588fc2ad0"
+ subject="Happens only when core.untrackedCache=true"
+ date="2022-07-21T08:23:04Z"
+ content="""
+I did a little testing with potential triggers in my ~/.gitconfig and traced it down to core.untrackedCache=true
+
+With core.untrackedCache=true and git 2.36, everything works as expected. With git 2.37, I get the bug.
+"""]]
diff --git a/doc/bugs/Incompatibility_with_git_2.37/comment_3_889ece8b2168b20019253ab6dd5b0e48._comment b/doc/bugs/Incompatibility_with_git_2.37/comment_3_889ece8b2168b20019253ab6dd5b0e48._comment
new file mode 100644
index 0000000000..4bd9542003
--- /dev/null
+++ b/doc/bugs/Incompatibility_with_git_2.37/comment_3_889ece8b2168b20019253ab6dd5b0e48._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-07-22T15:46:46Z"
+ content="""
+`git write-tree` has always locked the index, so it seems something else
+has changed to also lock the index when core.untrackedCache is set, that
+did not before.
+
+Probably `git update-index`, since that's what looks at the config.
+`git-annex init` does run that, before `git write-tree`, but it
+waits for it to exit. So I don't understand what would have the index still
+locked.
+
+I've reproduced it, setting core.untrackedCache.
+"""]]
diff --git a/doc/bugs/Incompatibility_with_git_2.37/comment_4_95b8ea35cd10ac80e1d01b658e24d7a9._comment b/doc/bugs/Incompatibility_with_git_2.37/comment_4_95b8ea35cd10ac80e1d01b658e24d7a9._comment
new file mode 100644
index 0000000000..b1c285f2ec
--- /dev/null
+++ b/doc/bugs/Incompatibility_with_git_2.37/comment_4_95b8ea35cd10ac80e1d01b658e24d7a9._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-07-22T16:25:27Z"
+ content="""
+Seems that git write-tree is segfaulting, which leaves the index locked:
+
+	openat(AT_FDCWD, "/tmp/n/.git/annex/index.lock", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = 3
+	rt_sigaction(SIGINT, {sa_handler=0x55f953819fb0, sa_mask=[INT], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fba9b3d2940}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
+	rt_sigaction(SIGHUP, {sa_handler=0x55f953819fb0, sa_mask=[HUP], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fba9b3d2940}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
+	rt_sigaction(SIGTERM, {sa_handler=0x55f953819fb0, sa_mask=[TERM], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fba9b3d2940}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
+	rt_sigaction(SIGQUIT, {sa_handler=0x55f953819fb0, sa_mask=[QUIT], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fba9b3d2940}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
+	rt_sigaction(SIGPIPE, {sa_handler=0x55f953819fb0, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fba9b3d2940}, {sa_handler=SIG_DFL, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fba9b3d2940}, 8) = 0
+	getpid()                                = 2873826
+	openat(AT_FDCWD, "/tmp/n/.git/annex/index", O_RDONLY) = -1 ENOENT (No such file or directory)
+	--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xd0} ---
+	+++ killed by SIGSEGV +++
+
+And this is not due to anything git-annex is doing, git is 100% broken:
+
+	joey@darkstar:/tmp>git init emptyrepo
+	warning: templates not found in /home/joey/share/git-core/templates
+	Initialized empty Git repository in /tmp/emptyrepo/.git/
+	joey@darkstar:/tmp>cd emptyrepo/
+	joey@darkstar:/tmp/emptyrepo>git config core.untrackedCache true
+	joey@darkstar:/tmp/emptyrepo>git write-tree
+	Segmentation fault
+
+git 2.37.1 has the same problem. I have emailed the git list about it.
+"""]]
diff --git a/doc/bugs/Incompatibility_with_git_2.37/comment_5_d0e60d224dd48d7c31adb6b250f662df._comment b/doc/bugs/Incompatibility_with_git_2.37/comment_5_d0e60d224dd48d7c31adb6b250f662df._comment
new file mode 100644
index 0000000000..59a4fb3eca
--- /dev/null
+++ b/doc/bugs/Incompatibility_with_git_2.37/comment_5_d0e60d224dd48d7c31adb6b250f662df._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="arnaud@c1d1cc612a3921dc06a417301be08a3e125478c4"
+ nickname="arnaud"
+ avatar="http://cdn.libravatar.org/avatar/c0defbf54541c499f6c0464588fc2ad0"
+ subject="comment 5"
+ date="2022-07-23T08:48:17Z"
+ content="""
+Awesome, thanks !
+"""]]
diff --git a/doc/bugs/Incompatibility_with_git_2.37/comment_6_3bb6424838d4f8a971f3dce6d1b8dbfb._comment b/doc/bugs/Incompatibility_with_git_2.37/comment_6_3bb6424838d4f8a971f3dce6d1b8dbfb._comment
new file mode 100644
index 0000000000..787d17a4ce
--- /dev/null
+++ b/doc/bugs/Incompatibility_with_git_2.37/comment_6_3bb6424838d4f8a971f3dce6d1b8dbfb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-08-04T17:46:32Z"
+ content="""
+Now 2 weeks since the segfault in git has been known, and they have not
+fixed it.
+
+Now feeling that it's might be worth git-annex init avoiding the
+segfault, by making sure to do something that creates the index file before
+write-tree. So I don't have to worry about when this gets fixed in git,
+or the chances that a buggy release will start being widely used for a long
+time.
+
+Yeah, done so.
+"""]]
diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates.mdwn b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates.mdwn
new file mode 100644
index 0000000000..e5411b3d9d
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates.mdwn
@@ -0,0 +1,54 @@
+### Please describe the problem.
+
+
+
+With the latest v10 git, I'm seeing some things like this:
+
+```
+get Pictures/0_New/5/20-03-31 21-12-12 0184.mp4 (from source...)   file content has changed
+
+
+  Unable to access these remotes: source
+
+  No other repository is known to contain the file.
+failed
+```
+
+Now, the file content really had not chnaged. That file looks like this:
+
+```
+$ cat 20-03-31\ 21-12-12\ 0184.mp4 
+/annex/objects/SHA256E-s55936559--0d418e4bb62cfc7ef5b053f8b622dd72794781a49931abc41bb9499acaf51b09.mp4
+```
+
+And on-disk, the file is:
+
+```
+$ sha256sum 20-03-31\ 21-12-12\ 0184.mp4 
+0d418e4bb62cfc7ef5b053f8b622dd72794781a49931abc41bb9499acaf51b09  20-03-31 21-12-12 0184.mp4
+```
+
+The result here is that files are left around not checked out.
+
+This is in an unlocked, thin repository and it is pulling in data from a directory special remote with importtree=yes.
+
+The problem seems to be triggered by a file that has a duplicate somewhere in the source repository (with the same sha256sum). I was able to find another file with the same sha256sum as that one in the same directory. In the origin repo, in which the given files were not present and it's using unlock-present, all instances of the file contained a broken symlink to the appropriate target. In the repo in question here, which uses plain unlock and is on NTFS (though Linux is the OS accessing it), I'm having this problem.
+
+
+### What steps will reproduce the problem?
+
+Any command that causes it to load the file content from the special remote (eg, git annex import, or git annex get)
+
+### What version of git-annex are you using? On what operating system?
+
+10.20220823 on Debian bullseye
+
+### Please provide any additional information below.
+
+Original conversation was at [[/bugs/Files_recorded_with_other_file__39__s_checksums/]].
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes!  I used it for awhile with the assistant to sync a lot of files.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_1_b9491e9cb432ca3b8bdb08a00c89b346._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_1_b9491e9cb432ca3b8bdb08a00c89b346._comment
new file mode 100644
index 0000000000..f02fd2cd6c
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_1_b9491e9cb432ca3b8bdb08a00c89b346._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-16T17:10:24Z"
+ content="""
+"file content has changed" is a message from the directory special remote
+when it sees that a file in the directory has a different mtime,size,inode
+tuple (content identifier) than the one that was recorded when importing
+the tree.
+
+Maybe that has something to do with the duplicate files, since they would
+have different inodes. Except, it does try to support that; it can keep
+track of multiple content identifiers for a key, and when there are
+duplicate files, that works in my testing.
+
+I notice that, if I have a directory special remote that was initially
+set up with ignoreinodes=no, and I've imported a tree that way from it,
+I can cause what looks like this problem:
+
+	joey@darkstar:~/tmp/bench/x>git-annex enableremote t directory=../x ignoreinodes=yes
+	enableremote t ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/x>git-annex get 3 --from t
+	get 3 (from t...) 
+	  file content has changed
+
+Which seems like a bug that it allows changing it, but I think that the idea was
+that, after changing ignoreinores, the user would re-run git-annex import,
+which would re-import all the files since the content identifier has
+changed. Still, I think that 
+[[!commit 3e2f1f73cbc5fc10475745b3c3133267bd1850a7]] didn't consider that
+it could cause a get to fail.
+
+I know you have recently upgraded from a version that defaulted
+to ignoring inodes. Maybe you only need to re-run `git-annex import` from the
+directory remote to fix the problem?
+"""]]
diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_2_cf9ce09377da2eae63ff41d07cb222d7._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_2_cf9ce09377da2eae63ff41d07cb222d7._comment
new file mode 100644
index 0000000000..03c7024b25
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_2_cf9ce09377da2eae63ff41d07cb222d7._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-16T17:32:29Z"
+ content="""
+If I was on the wrong track with my first comment, it would be helpful
+to take a look at the content identifier that is recorded for
+the key, by running:
+
+	git show git-annex:$(git-annex examinekey SHA256E-s55936559--0d418e4bb62cfc7ef5b053f8b622dd72794781a49931abc41bb9499acaf51b09.mp4 --format='${hashdirlower}${key}.log.cid')
+
+The part after the UUID in the output is the content identifier(s). If more
+than one, they are separated by colons. The format of a content identifier
+is "inode size mtime", and the inode will be 0 if it was generated with
+ignoreinodes=yes. So you could then compare the content identifiers
+with the stat of the files in the directory special remote and see if
+something has actually changed.
+"""]]
diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_3_a99df351ed700f908b6aaf3f52d245b4._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_3_a99df351ed700f908b6aaf3f52d245b4._comment
new file mode 100644
index 0000000000..ed50e89846
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_3_a99df351ed700f908b6aaf3f52d245b4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-09-16T17:43:38Z"
+ content="""
+I've made the directory special remote treat content identifiers
+that differ only in one having the inode set to 0. Which will avoid it
+failing in the situation I showed.
+"""]]
diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_4_d370abe891d554577a9af7f959c9e3f0._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_4_d370abe891d554577a9af7f959c9e3f0._comment
new file mode 100644
index 0000000000..598a1ac09f
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_4_d370abe891d554577a9af7f959c9e3f0._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 4"
+ date="2022-09-19T13:55:07Z"
+ content="""
+Examining that `git show` command:
+
+```
+git show git-annex:$(git-annex examinekey SHA256E-s55936559--0d418e4bb62cfc7ef5b053f8b622dd72794781a49931abc41bb9499acaf51b09.mp4 --format='${hashdirlower}${key}.log.cid')
+1662351509.054973915s 58255588-b988-47ba-9a88-7cb1118503ba 164140 55936559 1585707132 :167232 55936559 1585707132 
+```
+
+From the source material:
+
+```
+$ stat '0_New/5/20-03-31 21-12-12 0184.mp4'
+  File: 0_New/5/20-03-31 21-12-12 0184.mp4
+  Size: 55936559        Blocks: 109238     IO Block: 131072 regular file
+Device: 49h/73d Inode: 167232      Links: 1
+Access: (0644/-rw-r--r--)  Uid: ( 1000/jgoerzen)   Gid: ( 1000/jgoerzen)
+Access: 2020-03-31 21:12:12.000000000 -0500
+Modify: 2020-03-31 21:12:12.000000000 -0500
+Change: 2020-06-07 23:07:21.475946002 -0500
+ Birth: -
+```
+
+So it looks like the inode number changed.  But, on a hunch, I thought: this only happens with duplicate files; what if there's a file with that sha256 and that inode number?
+
+And sure enough:
+
+```
+stat ./0_New/5/laura-john-20200331.mp4
+  File: ./0_New/5/laura-john-20200331.mp4
+  Size: 55936559        Blocks: 109238     IO Block: 131072 regular file
+Device: 49h/73d Inode: 164140      Links: 1
+Access: (0644/-rw-r--r--)  Uid: ( 1000/jgoerzen)   Gid: ( 1000/jgoerzen)
+Access: 2020-03-31 21:12:12.000000000 -0500
+Modify: 2020-03-31 21:12:12.000000000 -0500
+Change: 2020-03-31 21:21:50.131297383 -0500
+ Birth: -
+```
+
+I didn't set ignoreinodes on this remote.
+
+Is that helpful?
+"""]]
diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_5_68a3936700a02a17d0379d96880eea15._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_5_68a3936700a02a17d0379d96880eea15._comment
new file mode 100644
index 0000000000..a45c9876b9
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_5_68a3936700a02a17d0379d96880eea15._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-09-20T16:23:07Z"
+ content="""
+The two files have the same two inodes that are recorded in the git-annex
+branch. The size and mtime also seem to match. Interesting,
+it must be another problem than the one I fixed.
+
+I wonder if it's expecting the first file to have the second one's inode,
+or vice-versa?
+
+I don't know how that would have happened to you, but I was able to force
+it to happen, by importing a tree from a directory remote that had 2
+duplicate files. Then I swapped the names of the 2 files in the directory.
+This causes git-annex get to fail with the same error message.
+
+That must be a bug itself, because re-importing from the special remote
+generates the same tree (of course) and so get continues failing, there is
+no recovery possible except deleting or touching the files.
+
+Aha: Another indication that handling of duplicate imported files is broken
+is to import two files, and then delete the first of them. This also causes
+git-annex get to fail, but now it always fails with "no such file or
+directory". It is only trying to get the first file, it does not try the
+second. Re-importing from the special remote teaches it about the deleted
+file, and that leads back to the "file content has changed" problem because
+it seems to be looking for the deleted file's inode. So that's one way you
+could have gotten into this situation without the unlikely swapping of two
+duplicate files.
+"""]]
diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_6_4d05a896fd57b55388fb21638ed02233._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_6_4d05a896fd57b55388fb21638ed02233._comment
new file mode 100644
index 0000000000..848f170302
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_6_4d05a896fd57b55388fb21638ed02233._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-09-20T16:42:18Z"
+ content="""
+Ah, here's the smoking gun: In Remote.Helper.ExportImport,
+it gets the cids for a key. And promptly picks the first one to pass to
+retrieveExportWithContentIdentifier, ignoring all the rest.
+It also gets the first recorded export location and likewise passes it to
+retrieveExportWithContentIdentifier.
+
+It seems like a fix would be to try retrieveExportWithContentIdentifier
+with each combination of cid and export location. But that would cause an
+`O(N^2)` explosion and it's possible a remote has say 1000 empty files in
+it.
+
+Maybe instead make retrieveExportWithContentIdentifier take a list of valid
+cids, and accept any one of them? Then it would only need to be tried on
+each export location in turn until one succeeds. 
+
+(Hm, removeExportWithContentIdentifier and 
+checkPresentExportWithContentIdentifier already use a list, so similar problems
+are avoided with them.)
+"""]]
diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_7_4a1248ea257c04f1afe233891a606eea._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_7_4a1248ea257c04f1afe233891a606eea._comment
new file mode 100644
index 0000000000..b023e3c6f6
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_7_4a1248ea257c04f1afe233891a606eea._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-09-20T17:35:10Z"
+ content="""
+Ok, fixed that. I'm confident this will fix the issue for you, so closing.
+"""]]
diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_8_37eb9d35191bcfc0e7e4496f5720cbed._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_8_37eb9d35191bcfc0e7e4496f5720cbed._comment
new file mode 100644
index 0000000000..e80c02e061
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_8_37eb9d35191bcfc0e7e4496f5720cbed._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 8"
+ date="2022-09-22T03:40:04Z"
+ content="""
+Thank you!
+"""]]
diff --git a/doc/bugs/Infinite_loop_when_synchronizing_between_many_machines.mdwn b/doc/bugs/Infinite_loop_when_synchronizing_between_many_machines.mdwn
new file mode 100644
index 0000000000..5fc8da66b7
--- /dev/null
+++ b/doc/bugs/Infinite_loop_when_synchronizing_between_many_machines.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+
+When an assistant adds a lot of new files, and there’s an assistant running for the repo on each of some 5 machines, infinite loop happens on those receiving the new files.
+
+### What steps will reproduce the problem?
+
+1. Have 5 machines with a repo checked out.
+2. Run git-annex-assistant on each.
+3. Copy a lot of files into the repo on one machine.
+4. Look at the webapp UIs on other machines.
+5. In the UI, the same files get enqueued and dequeued repeatedly and nothing else happens.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 6.20170520
+
+local repository version: 6
+
+operating system: linux x86_64
+
+### Please provide any additional information below.
+
+—
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! But do you test it for similar races on more than two simultaneous machines?
diff --git a/doc/bugs/Infinite_loop_when_synchronizing_between_many_machines/comment_1_6d8f42446749f3e697af20626f22cf8b._comment b/doc/bugs/Infinite_loop_when_synchronizing_between_many_machines/comment_1_6d8f42446749f3e697af20626f22cf8b._comment
new file mode 100644
index 0000000000..037f632c80
--- /dev/null
+++ b/doc/bugs/Infinite_loop_when_synchronizing_between_many_machines/comment_1_6d8f42446749f3e697af20626f22cf8b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 1"
+ date="2017-08-20T15:27:31Z"
+ content="""
+Restarting the daemon helps, but I can’t reasonably expect my parents to do this regularly… :c
+"""]]
diff --git a/doc/bugs/Infinite_loop_when_synchronizing_between_many_machines/comment_2_3b4e529564488e732dd62569247b3d56._comment b/doc/bugs/Infinite_loop_when_synchronizing_between_many_machines/comment_2_3b4e529564488e732dd62569247b3d56._comment
new file mode 100644
index 0000000000..2c8a53c014
--- /dev/null
+++ b/doc/bugs/Infinite_loop_when_synchronizing_between_many_machines/comment_2_3b4e529564488e732dd62569247b3d56._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-18T16:42:42Z"
+ content="""
+This does not generally happen, I have repositories synced by the assistant
+on many machines.
+
+I'd need to see .git/annex/daemon.log from a repository where this was
+happening to help with this.
+"""]]
diff --git a/doc/bugs/Initial___34__Make_repository__34___fails_due_to___34__empty_ident_name___40__for___60__email-address__62____41___not_allowed__34__.mdwn b/doc/bugs/Initial___34__Make_repository__34___fails_due_to___34__empty_ident_name___40__for___60__email-address__62____41___not_allowed__34__.mdwn
new file mode 100644
index 0000000000..b15cfad68e
--- /dev/null
+++ b/doc/bugs/Initial___34__Make_repository__34___fails_due_to___34__empty_ident_name___40__for___60__email-address__62____41___not_allowed__34__.mdwn
@@ -0,0 +1,43 @@
+### Please describe the problem.
+
+During an initial run of "git annex webapp", it gets stuck at the "Make repository" stage. Entering a directory and pressing "Make repository" takes the user back to the same page repeatedly, preventing them from advancing.
+
+### What steps will reproduce the problem?
+
+Download https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386.tar.gz from 2015-10-19 (sha1: 3b30de86d6790fdf80de90b2f54967de8345fe98 ) on an Ubuntu Trusty Tahr server, untar, run git-annex-webapp, attempt to make a Repository in ~/annex. "Make repository" fails to advance.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex-standalone-i386.tar.gz downloaded on 2015-10-19 (sha1: 3b30de86d6790fdf80de90b2f54967de8345fe98), on Ubuntu Trusty Tahr (14.04.3).
+
+### Please provide any additional information below.
+
+The following is printed to the console (no daemon.log is generated):
+
+[[!format sh """
+~/src/git-annex.linux$ ./git-annex-webapp 
+Launching web browser on file:///tmp/webapp8296.html
+
+
+*** Please tell me who you are.
+
+Run
+
+  git config --global user.email "you@example.com"
+  git config --global user.name "Your Name"
+
+to set your account's default identity.
+Omit --global to set the identity only in this repository.
+
+fatal: empty ident name (for <k@home.everets.org>) not allowed
+(recording state in git...)
+
+
+# End of transcript or log.
+"""]]
+
+Manually running the "git config --global user.name" will allow the process to proceed. It will just be confusing to users who launched the webapp via a menu item.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Works well using the debian testing package on a debian laptop!
diff --git a/doc/bugs/Initial___34__Make_repository__34___fails_due_to___34__empty_ident_name___40__for___60__email-address__62____41___not_allowed__34__/comment_1_267b252368dca4803d706c70a3ef3244._comment b/doc/bugs/Initial___34__Make_repository__34___fails_due_to___34__empty_ident_name___40__for___60__email-address__62____41___not_allowed__34__/comment_1_267b252368dca4803d706c70a3ef3244._comment
new file mode 100644
index 0000000000..376ea92efe
--- /dev/null
+++ b/doc/bugs/Initial___34__Make_repository__34___fails_due_to___34__empty_ident_name___40__for___60__email-address__62____41___not_allowed__34__/comment_1_267b252368dca4803d706c70a3ef3244._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-11-10T19:45:36Z"
+ content="""
+I was able to completely reproduce this in every particular, except for one
+important thing:
+
+The webapp *was* able to advance; the repository was created, and 
+when I looked inside its .git/config, I saw as expected:
+
+	[user]
+	name = foo
+	email = bar
+
+So, as far as I can see, git-annex's existing code to detect when the
+system is so badly configured that git commit doesn't work, and fix the git
+configuration of the repository well enough for git commit to proceed, is
+working. The git error just occurs when git-annex is doing that probing.
+
+And, in your transcript, it says "(recording state in git...)" so
+it seems to have gotten past that git error just fine as well.
+
+If the webapp didn't advance beyond creating the repository, what error
+message was displayed **in the webapp**?
+
+Currently, my guess is you saw scary stuff on the console and assumed it
+meant it wouldn't work, but it did.
+"""]]
diff --git a/doc/bugs/Installing_git-annex_on_macOS_10.13_HighSierra_via_brew_install_git-annex_require_to_install_lib_magic_via_the_command_brew_install_lib_magic.mdwn b/doc/bugs/Installing_git-annex_on_macOS_10.13_HighSierra_via_brew_install_git-annex_require_to_install_lib_magic_via_the_command_brew_install_lib_magic.mdwn
new file mode 100644
index 0000000000..310761e690
--- /dev/null
+++ b/doc/bugs/Installing_git-annex_on_macOS_10.13_HighSierra_via_brew_install_git-annex_require_to_install_lib_magic_via_the_command_brew_install_lib_magic.mdwn
@@ -0,0 +1,29 @@
+### Please describe the problem.
+
+Installing git annex on MacOS 10.13 HighSierra  via brew install git-annex issues an error:
+...
+Trap 6
+
+The fix is to install lib magic with this command:
+
+brew install libmagic
+
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
diff --git a/doc/bugs/Installing_git-annex_on_macOS_10.13_HighSierra_via_brew_install_git-annex_require_to_install_lib_magic_via_the_command_brew_install_lib_magic/comment_1_43614460d92cfac8a40ad2d6654926b9._comment b/doc/bugs/Installing_git-annex_on_macOS_10.13_HighSierra_via_brew_install_git-annex_require_to_install_lib_magic_via_the_command_brew_install_lib_magic/comment_1_43614460d92cfac8a40ad2d6654926b9._comment
new file mode 100644
index 0000000000..5be4a0a662
--- /dev/null
+++ b/doc/bugs/Installing_git-annex_on_macOS_10.13_HighSierra_via_brew_install_git-annex_require_to_install_lib_magic_via_the_command_brew_install_lib_magic/comment_1_43614460d92cfac8a40ad2d6654926b9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-03-16T15:55:48Z"
+ content="""
+I don't think I can make any changes to git-annex to fix this, it's an
+issue with the homebrew packaging of it, which should pull in the libmagic
+dependency. Can you file a bug on homebrew about this?
+"""]]
diff --git a/doc/bugs/Invalid_argument_saving_FreeSurfer_file_on_NTFS.mdwn b/doc/bugs/Invalid_argument_saving_FreeSurfer_file_on_NTFS.mdwn
new file mode 100644
index 0000000000..241ee8ce8c
--- /dev/null
+++ b/doc/bugs/Invalid_argument_saving_FreeSurfer_file_on_NTFS.mdwn
@@ -0,0 +1,95 @@
+### Please describe the problem.
+
+Annexing files can fail with "Invalid argument" error. It appears to be an interaction of filesystem and file name. The file name is `lh.aparc.DKTatlas.annot`/`rh.aparc.DKTatlas.annot`, and the filesystem is:
+
+[[!format sh """
+$ mount | grep data
+/dev/mapper/bitlocker on /data type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
+$ ntfs-3g
+ntfs-3g: No device is specified.
+
+ntfs-3g 2021.8.22 integrated FUSE 28 - Third Generation NTFS Driver
+                Configuration type 7, XATTRS are on, POSIX ACLS are on
+"""]]
+
+However, formatting a file as NTFS and mounting as loop to make a minimal reproduction allowed the operation to succeed.
+
+### What steps will reproduce the problem?
+
+I am able to reproduce this problem reliably on the filesystem above:
+
+[[!format sh """
+$ git init test/
+$ cd test
+$ git annex init
+$ curl -sSL https://file.io/ZtE5ivep7E9V -o lh.aparc.DKTatlas.annot
+$ git annex add lh.aparc.DKTatlas.annot
+add lh.aparc.DKTatlas.annot 
+  .git/annex/othertmp/: openTempFile template ingest-lh.: invalid argument (Invalid argument)
+
+failed
+add: 1 failed
+"""]]
+
+However, renaming the file to `L.annot`, annexing it, and `git mv`ing it back works, so I am not stuck adding the file contents directly to git.
+
+I hope the log below will give you a hint of what's going on, as I regret I am unable to reproduce this on other filesystems.
+
+### What version of git-annex are you using? On what operating system?
+
+OS: Ubuntu 22.04.3 LTS
+
+[[!format sh """
+git-annex version: 10.20230408-g5b1e8ba77
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+"""]]
+
+### Please provide any additional information below.
+[[!format sh """
+$ git annex add -d lh.aparc.DKTatlas.annot
+[2023-12-05 09:40:20.256526552] (Utility.Process) process [1162202] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2023-12-05 09:40:20.260613884] (Utility.Process) process [1162202] done ExitSuccess
+[2023-12-05 09:40:20.260892906] (Utility.Process) process [1162203] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2023-12-05 09:40:20.265019085] (Utility.Process) process [1162203] done ExitSuccess
+[2023-12-05 09:40:20.265446352] (Utility.Process) process [1162204] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..eb539b816feb00e6be3a252d36efaa7426eccca1","--pretty=%H","-n1"]
+[2023-12-05 09:40:20.270301207] (Utility.Process) process [1162204] done ExitSuccess
+[2023-12-05 09:40:20.271251091] (Utility.Process) process [1162205] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2023-12-05 09:40:20.275373234] (Utility.Process) process [1162206] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2023-12-05 09:40:20.278672692] (Utility.Process) process [1162206] done ExitSuccess
+[2023-12-05 09:40:20.278946202] (Utility.Process) process [1162207] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","refs/heads/master"]
+[2023-12-05 09:40:20.282475944] (Utility.Process) process [1162207] done ExitFailure 1
+[2023-12-05 09:40:20.282779905] (Utility.Process) process [1162208] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-files","-z","--others","--exclude-standard","--","lh.aparc.DKTatlas.annot"]
+[2023-12-05 09:40:20.286209985] (Utility.Process) process [1162209] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","check-attr","-z","--stdin","annex.backend","annex.largefiles","annex.numcopies","annex.mincopies","--"]
+[2023-12-05 09:40:20.28954558] (Utility.Process) process [1162210] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+add lh.aparc.DKTatlas.annot [2023-12-05 09:40:20.293105736] (Utility.Process) process [1162211] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2023-12-05 09:40:20.296109063] (Utility.Process) process [1162211] done ExitSuccess
+[2023-12-05 09:40:20.296268327] (Utility.Process) process [1162212] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","refs/heads/master"]
+[2023-12-05 09:40:20.299447211] (Utility.Process) process [1162212] done ExitFailure 1
+[2023-12-05 09:40:20.299472144] (Annex.Perms) freezing content lh.aparc.DKTatlas.annot
+
+  .git/annex/othertmp/: openTempFile template ingest-lh.: invalid argument (Invalid argument)
+
+failed
+[2023-12-05 09:40:20.299683526] (Utility.Process) process [1162208] done ExitSuccess
+[2023-12-05 09:40:20.299804817] (Utility.Process) process [1162213] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-files","-z","--modified","--","lh.aparc.DKTatlas.annot"]
+[2023-12-05 09:40:20.302582841] (Utility.Process) process [1162213] done ExitSuccess
+[2023-12-05 09:40:20.302707305] (Utility.Process) process [1162214] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","diff","--name-only","--diff-filter=T","-z","--cached","--","lh.aparc.DKTatlas.annot"]
+[2023-12-05 09:40:20.30608269] (Utility.Process) process [1162214] done ExitSuccess
+[2023-12-05 09:40:20.306609675] (Utility.Process) process [1162205] done ExitSuccess
+[2023-12-05 09:40:20.306732757] (Utility.Process) process [1162210] done ExitSuccess
+[2023-12-05 09:40:20.306873108] (Utility.Process) process [1162209] done ExitSuccess
+add: 1 failed
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! I use git annex and datalad all the time for personal and work projects. 
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Invalid_argument_saving_FreeSurfer_file_on_NTFS/comment_1_181a319138cc10742bc8676d77e8a614._comment b/doc/bugs/Invalid_argument_saving_FreeSurfer_file_on_NTFS/comment_1_181a319138cc10742bc8676d77e8a614._comment
new file mode 100644
index 0000000000..0ab08545f2
--- /dev/null
+++ b/doc/bugs/Invalid_argument_saving_FreeSurfer_file_on_NTFS/comment_1_181a319138cc10742bc8676d77e8a614._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-12-05T16:16:35Z"
+ content="""
+This is EINVAL from probably open(2) or something like that.
+
+       EINVAL The  final  component ("basename") of pathname is invalid (e.g.,
+              it contains characters not permitted by the underlying  filesys‐
+              tem).
+
+The problem is likely the ending ".", since FAT and probably other Microsoft filesystems
+don't allow that, and/or have other strange behavior like silently removing that.
+
+Changed the code to avoid this.
+"""]]
diff --git a/doc/bugs/Invalid_option___96__--time-limit__61__1m__39___with_pull.mdwn b/doc/bugs/Invalid_option___96__--time-limit__61__1m__39___with_pull.mdwn
new file mode 100644
index 0000000000..42f42f366a
--- /dev/null
+++ b/doc/bugs/Invalid_option___96__--time-limit__61__1m__39___with_pull.mdwn
@@ -0,0 +1,46 @@
+### Please describe the problem.
+
+git annex pull reports `--time-limit=1m` as an invalid option, even though its manpage states that it can use the options from git-annex-common-options and the manpage for those includes the --time-limit option.
+
+
+### What steps will reproduce the problem?
+
+git annex pull while specifying the --time-limit option.
+
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+$ git annex version
+git-annex version: 10.20240227
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24.1 bloomfilter-2.0.1.2 crypton-0.34 DAV-1.3.4 feed-1.3.2.1 ghc-9.6.4 http-client-0.7.17 persistent-sqlite-2.13.3.0 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+"""]]
+
+On Ubuntu, but git-annex is installed from a recent nixpkgs.
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+$ git annex pull --time-limit=1m
+Invalid option `--time-limit=1m'
+
+Usage: git-annex COMMAND
+[...]
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I am currently working on a web interface that lets non-git-annex users request files to be available in a specific repository (which will be located on the storage cluster of a HPC system). A combination of git annex metadata and an appropriate required content expression should make this essentially trivial, which is nice. The time-limit option would be helpful for the background worker doing all the fetching, though.
diff --git a/doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__.mdwn b/doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__.mdwn
new file mode 100644
index 0000000000..0e7d61b2f8
--- /dev/null
+++ b/doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__.mdwn
@@ -0,0 +1,20 @@
+What steps will reproduce the problem?
+
+Adding files to a local annex set up to sync to a remote S3 one
+
+
+What is the expected output? What do you see instead?
+
+It syncs, but maxes out the uplink
+
+
+What version of git-annex are you using? On what operating system?
+
+3.20121112 on Debian testing
+
+
+Please provide any additional information below.
+
+The man page lists how to configure rate limiting for rsync, not sure how to do it for this
+
+[[!tag confirmed]]
diff --git a/doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__/comment_1_ef97e735ce308f7bcc03f5d9fda588bf._comment b/doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__/comment_1_ef97e735ce308f7bcc03f5d9fda588bf._comment
new file mode 100644
index 0000000000..67de2becf4
--- /dev/null
+++ b/doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__/comment_1_ef97e735ce308f7bcc03f5d9fda588bf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2012-11-13T15:10:45Z"
+ content="""
+There's always trickle..
+
+    trickle -u 50 git annex ...
+"""]]
diff --git a/doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__/comment_2_539b89de8743e435386b86119d1e982f._comment b/doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__/comment_2_539b89de8743e435386b86119d1e982f._comment
new file mode 100644
index 0000000000..122bafbba5
--- /dev/null
+++ b/doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__/comment_2_539b89de8743e435386b86119d1e982f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.11.120"
+ subject="comment 2"
+ date="2012-11-13T17:09:31Z"
+ content="""
+It's not there yet. I don't think it will be hard to add, most of the same things need to be done to support upload progress bars with S3.
+"""]]
diff --git a/doc/bugs/Issue_fewer_S3_GET_requests.mdwn b/doc/bugs/Issue_fewer_S3_GET_requests.mdwn
new file mode 100644
index 0000000000..8bbcfa1792
--- /dev/null
+++ b/doc/bugs/Issue_fewer_S3_GET_requests.mdwn
@@ -0,0 +1,9 @@
+It appears that git-annex issues one GET request to S3 / Google cloud for every file it tries to copy, if you don't pass --fast.  (I could be wrong; I'm basing this on the fact that each "checking <remote name>" takes about the same amount of time, and that it's slow enough to be hitting the network.)
+
+Amazon lets you GET 1000 objects in one GET request, and afaict a request that returns 1000 objects costs just as much as a request that returns 1 object.  The cost of GET'ing every file in my annex is nontrivial -- Google charges 0.01 per 1000 GETs, and my repo has 130k objects, so that's $1.3, compared to a monthly cost for storage of under $10.  This means that if I want to back up my files more than, say, once a week, I need to write a script that parses the JSON output of git annex whereis and uploads with --fast only the files that aren't present in the cloud.  It also means that I have to trust the output of whereis.
+
+All those GETs also slow down the non-fast copy, and this also applies to other kinds of remotes.
+
+There are a number of ways one could implement this.  One way would be to have a command that updates the whereis data from the remote and then to add a parameter (maybe you already have it) to copy that's like --fast but skips files that are already present (maybe this is what --fast already does, but I did a quick check and it doesn't seem to).  Because of the way git annex names files, I think it would be hard to coalesce GETs during a copy command, but it could be done.
+
+Anyway, please don't consider this a high-priority request; I can get by as-is, and I <3 git annex.
diff --git a/doc/bugs/Issue_fewer_S3_GET_requests/comment_1_59a6b87d01c003bf55cde4c882e1778c._comment b/doc/bugs/Issue_fewer_S3_GET_requests/comment_1_59a6b87d01c003bf55cde4c882e1778c._comment
new file mode 100644
index 0000000000..b0c6b76132
--- /dev/null
+++ b/doc/bugs/Issue_fewer_S3_GET_requests/comment_1_59a6b87d01c003bf55cde4c882e1778c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.96"
+ subject="comment 1"
+ date="2014-10-22T21:36:27Z"
+ content="""
+The man page documents this:
+
+> To avoid contacting the remote to check if it has every
+> file when copying --to the repository, specify --fast
+
+As you've noted, this has to rely on the location tracking information being up-to-date, so if it's not it might miss copying a file to the remote that the remote doesn't currently have but used to. Otherwise, it's fine to use `copy --fast --to --remote` or `copy --not --in remote --to remote`, which is functionally identical.
+
+The check is not a GET request, it's a HEAD request, to check if the file
+is present. Does S3 have a way to combine multiple HEAD requests in a
+single http request? That seems unlikely. Maybe it is enough to reuse an
+open http connection for multiple HEADs? Anything needing a single HEAD request would not fit well into git-annex, but ways to do more caching of open http connections are being considered.
+"""]]
diff --git a/doc/bugs/Issue_fewer_S3_GET_requests/comment_2_8fdeb3352ac00a76625ec9c007e5b76a._comment b/doc/bugs/Issue_fewer_S3_GET_requests/comment_2_8fdeb3352ac00a76625ec9c007e5b76a._comment
new file mode 100644
index 0000000000..b3b2594450
--- /dev/null
+++ b/doc/bugs/Issue_fewer_S3_GET_requests/comment_2_8fdeb3352ac00a76625ec9c007e5b76a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c"
+ nickname="Justin"
+ subject="comment 2"
+ date="2014-10-24T04:49:20Z"
+ content="""
+Oh jeez, I screwed that up wrt HEAD and GET.  Sorry.  The cost per HEAD on Google is 1/10 the price of GET, so we're talking $.13 to HEAD my 130k-file annex, which is totally reasonable.
+
+One can GET a bucket, which is what I was looking at.  This returns up to 1000 elements of its contents (and there's a way to iterate over larger buckets).  Of course this would only be useful if the majority of files in the bucket were of interest to git-annex, and it sounds like more trouble than it's worth at the prices I'm seeing.
+
+There might be a throughput improvement to be had by keeping the connection alive, although in my brief investigation, I think there may be a larger gain to be had by pipelining the various steps.  Based on the fact that git-annex oomed when trying to upload a large file from my rpi, it seems like maybe the whole file is encrypted in memory before it's uploaded?  And certainly the HEAD(s) appear not to be done in parallel with the upload.
+
+Sorry again for that HEAD/GET fail.
+"""]]
diff --git a/doc/bugs/Issue_fewer_S3_GET_requests/comment_3_6ccbb1cff7bc6b4640220d98f7ce21c3._comment b/doc/bugs/Issue_fewer_S3_GET_requests/comment_3_6ccbb1cff7bc6b4640220d98f7ce21c3._comment
new file mode 100644
index 0000000000..353281db65
--- /dev/null
+++ b/doc/bugs/Issue_fewer_S3_GET_requests/comment_3_6ccbb1cff7bc6b4640220d98f7ce21c3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.96"
+ subject="comment 3"
+ date="2014-10-24T16:02:23Z"
+ content="""
+The OOM is [[S3_memory_leaks]]; fixed in the s3-aws branch.
+
+Yeah, GET of a bucket is doable. Another problem with it though is, if the bucket has a lot of contents, such as many files, or large files split into many chunks, that all has to be buffered in memory or processed as a stream. It would make sense in operations where git-annex knows it wants to check every key in a bucket. `git annex unused --from $s3remote` is the case that springs to mind where it could be quite useful to do that. Integrating it with `get`, not so much.
+
+I'd be inclined to demote this to a wishlist todo item to try to use bucket GET for `unused`. And/or rethink whether it makes sense for `copy --to` to run in --fast mode by default. I've been back and forth on that question before, but just from a runtime perspective, not from a 13 cents perspective. ;)
+"""]]
diff --git a/doc/bugs/Issue_on_OSX_with_some_system_limits.mdwn b/doc/bugs/Issue_on_OSX_with_some_system_limits.mdwn
new file mode 100644
index 0000000000..3942132208
--- /dev/null
+++ b/doc/bugs/Issue_on_OSX_with_some_system_limits.mdwn
@@ -0,0 +1,27 @@
+I was dumping ~gigs of files of approximately 3-6megs a pop (my music collection) so I could track the files that I want to listen to when I'm on the go. I had the git watch command running from the assistant branch.
+
+I was getting something along the lines of...
+
+    /Users/jtang/annex/.git/annex/tmp/: openTempFile: resource exhausted (Too many open files)
+
+and
+
+    git-annex: createPipe: resource exhausted (Too many open files)
+
+I also noticed that I somehow ended up with 256 ssh-agent's running on one of my machines, I'm not sure if the two issues are related or not, I had not noticed this type of behaviour up until recently.
+
+Also this was appearing in the logs
+
+    x00:annex jtang$ tail -f .git/annex/daemon.log
+    (scanning...) Already up-to-date.
+    kqueue: Too many open files
+
+To be precise, I suspect that the kqueue limit is 256, I had 325 files in the 'queue', I ended up doing a _git annex add_ manually and all was fine.
+
+[[!meta title="kqueue system limits"]]
+
+> This affects BSD systems that use Kqueue. It no longer affects OSX,
+> since we use FSEvents there instead. --[[Joey]] 
+
+[[!tag /design/assistant]]
+[[!tag confirmed]]
diff --git a/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_1_5fc1eedb5231edc37c87a2d9b91313b9._comment b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_1_5fc1eedb5231edc37c87a2d9b91313b9._comment
new file mode 100644
index 0000000000..d30cddca50
--- /dev/null
+++ b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_1_5fc1eedb5231edc37c87a2d9b91313b9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.25"
+ subject="comment 1"
+ date="2012-06-25T15:42:48Z"
+ content="""
+Yes, this is a known problem with kqueue, it has to keep every directory in the tree open. On [[design/assistant/inotify]] I have a note that it may need to fork off extra watcher processes to deal with this. Of course that adds significant complication.
+
+In the meantime, you may be able to increase your system's maximum allowed number of open files per process somehow.
+
+(I doubt that the ssh-agent is related; git-annex does not use ssh-agent directly anyway..)
+"""]]
diff --git a/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_2_b14e697c211843163285aaa8de5bf4c6._comment b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_2_b14e697c211843163285aaa8de5bf4c6._comment
new file mode 100644
index 0000000000..17dcf76343
--- /dev/null
+++ b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_2_b14e697c211843163285aaa8de5bf4c6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2012-06-29T12:02:48Z"
+ content="""
+Doing,
+
+    sudo sysctl -w kern.maxfilesperproc=400000
+
+Somewhat works for me, git-annex watch at least starts up and takes a while to scan the directory, but it's not ideal. Also, creating files seems to work okay, when I remove a file the changes don't seem to get pushed across my other repos, running a sync on the remote repo fixes things.
+"""]]
diff --git a/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_3_18ddf8b5934dd6fb1676cd6adc7d103b._comment b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_3_18ddf8b5934dd6fb1676cd6adc7d103b._comment
new file mode 100644
index 0000000000..eb886acf6b
--- /dev/null
+++ b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_3_18ddf8b5934dd6fb1676cd6adc7d103b._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 3"
+ date="2012-07-04T12:32:44Z"
+ content="""
+Jimmy, sounds like I could use something like this to get the current limit:
+
+    sysctl kern.maxfilesperproc
+
+Probably prints \"sysctl kern.maxfilesperproc = 256\" or such.. can you verify?
+Once I have the limit, I can make the kqueue code use subset of it, and print out a message when it needs to be increased, like the inotify code does.
+
+(Also, the kqueue code only opens directories, not files, so unless you have 400000 directories, that's
+a little high.)
+
+---
+
+On file removal not propigating, does this still happen? When you remove a file does a git commit automatically happen, or is that broken with kqueue?
+"""]]
diff --git a/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_4_c25a8eb369e546f65e1a72d89f43066f._comment b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_4_c25a8eb369e546f65e1a72d89f43066f._comment
new file mode 100644
index 0000000000..509752bf18
--- /dev/null
+++ b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_4_c25a8eb369e546f65e1a72d89f43066f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 4"
+ date="2012-07-08T18:13:58Z"
+ content="""
+On kFreeBSD, I get this:
+
+    $ sysctl kern.maxfilesperproc
+    kern.maxfilesperproc: 11095
+
+But ulimit still has 1024 limit, so you'd need to adjust both, as root. Messy..
+"""]]
diff --git a/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_5_6407a3e7aa0316cba2994bfef0e3c633._comment b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_5_6407a3e7aa0316cba2994bfef0e3c633._comment
new file mode 100644
index 0000000000..30ea6b310e
--- /dev/null
+++ b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_5_6407a3e7aa0316cba2994bfef0e3c633._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 4"
+ date="2012-07-04T13:17:05Z"
+ content="""
+In relation to the system limits,
+
+    laplace:~ jtang$ sysctl kern.maxfilesperproc
+    kern.maxfilesperproc: 10240
+
+Also, the maxfiles for the whole system is
+
+    laplace:~ jtang$ sysctl kern.maxfiles
+    kern.maxfiles: 12288
+
+the above was the defaults as far as I recall. What you probably would be interested is the ulimits that the user see
+
+    laplace:~ jtang$ ulimit -a
+    core file size          (blocks, -c) 0
+    data seg size           (kbytes, -d) unlimited
+    file size               (blocks, -f) unlimited
+    max locked memory       (kbytes, -l) unlimited
+    max memory size         (kbytes, -m) unlimited
+    open files                      (-n) 256
+    pipe size            (512 bytes, -p) 1
+    stack size              (kbytes, -s) 8192
+    cpu time               (seconds, -t) unlimited
+    max user processes              (-u) 709
+    virtual memory          (kbytes, -v) unlimited
+
+I would imagine the limit that you are looking for is 256. Hope this helps.
+
+----
+
+On the point about deletions not being propagated, it does do a commit. I suspect that the kqueue code is just not picking up the changes and pushing the changes out. The watch command on a single annex with no remotes functions as expected.
+"""]]
diff --git a/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_6_f01887695e8b8386e125464c6d401565._comment b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_6_f01887695e8b8386e125464c6d401565._comment
new file mode 100644
index 0000000000..cd5c73a7a5
--- /dev/null
+++ b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_6_f01887695e8b8386e125464c6d401565._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2012-06-25T22:36:39Z"
+ content="""
+On the system limits side, I think if you want to make it more approachable by more users then adjusting system limits might scare users away. On the note of the ssh-agents spawning like no tomorrow on my machine, it turned out that i had a symlink from my .bashrc to .bash_profile, I guess I should not be too lazy and have two seperate files.
+"""]]
diff --git a/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_7_c7776d5b2d073e0d2ae36515185c25aa._comment b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_7_c7776d5b2d073e0d2ae36515185c25aa._comment
new file mode 100644
index 0000000000..b65dc4dfcc
--- /dev/null
+++ b/doc/bugs/Issue_on_OSX_with_some_system_limits/comment_7_c7776d5b2d073e0d2ae36515185c25aa._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="Just encountered this today"
+ date="2012-11-29T19:21:50Z"
+ content="""
+& it's killing my assistant.
+
+Found a workaround here: https://github.com/mockko/livereload/issues/1
+
+This fixes it for now:
+
+ulimit -n 4096
+
+Just posting here in case anybody else runs into this issue and, like me, finds themselves here via search engine.
+
+"""]]
diff --git a/doc/bugs/It_is_very_easy_to_turn_git-annex_into_a_zombie.mdwn b/doc/bugs/It_is_very_easy_to_turn_git-annex_into_a_zombie.mdwn
new file mode 100644
index 0000000000..9148252091
--- /dev/null
+++ b/doc/bugs/It_is_very_easy_to_turn_git-annex_into_a_zombie.mdwn
@@ -0,0 +1,25 @@
+What steps will reproduce the problem?
+
+Run the git-annex assitant, and then "sudo kill" it.
+
+What is the expected output? What do you see instead?
+
+I expect it to die, instead I end up with:
+
+    14604   ??  S      0:00.64 ga assistant
+    14623   ??  Z      0:00.00 (git)
+    14624   ??  Z      0:00.00 (git)
+    14936   ??  Z      0:00.00 (git-annex)
+
+The only way to clear these zombies is to reboot.  Perhaps there is some resource not being correctly terminated under exceptional conditions?
+
+Note that on OpenIndiana the problem is even more severe: Aborting git-annex at the wrong time leaves behind both zombie processes and lock files which cause the machine to suddenly halt if I try to access them in any way (via mv, rsync, etc)!
+
+What version of git-annex are you using? On what operating system?
+
+4d1e0c9 on OS X 10.8.2.
+
+Please provide any additional information below.
+
+[[!meta title="strange OSX behavior when killed"]]
+[[!tag /design/assistant/OSX moreinfo]]
diff --git a/doc/bugs/It_is_very_easy_to_turn_git-annex_into_a_zombie/comment_1_d5fba6c061fb21795021ea83070dbfa2._comment b/doc/bugs/It_is_very_easy_to_turn_git-annex_into_a_zombie/comment_1_d5fba6c061fb21795021ea83070dbfa2._comment
new file mode 100644
index 0000000000..8d7eea6c52
--- /dev/null
+++ b/doc/bugs/It_is_very_easy_to_turn_git-annex_into_a_zombie/comment_1_d5fba6c061fb21795021ea83070dbfa2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="Correction"
+ date="2012-10-20T05:34:47Z"
+ content="""
+If I \"sudo kill -9\" all the processes in the above group after deleting the annex directories, then they do go away without needing to reboot.
+"""]]
diff --git a/doc/bugs/It_is_very_easy_to_turn_git-annex_into_a_zombie/comment_2_12cba707239018989e8d5b6f456fa754._comment b/doc/bugs/It_is_very_easy_to_turn_git-annex_into_a_zombie/comment_2_12cba707239018989e8d5b6f456fa754._comment
new file mode 100644
index 0000000000..2b552c6aa4
--- /dev/null
+++ b/doc/bugs/It_is_very_easy_to_turn_git-annex_into_a_zombie/comment_2_12cba707239018989e8d5b6f456fa754._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.23"
+ subject="comment 2"
+ date="2012-10-22T14:01:42Z"
+ content="""
+It's not at all clear to me from this what process you killed. 
+
+(I can't comment on files that somehow crash a kernel on access.. That's not in any UNIX spec I'm aware of.)
+"""]]
diff --git a/doc/bugs/J1_display_issue.mdwn b/doc/bugs/J1_display_issue.mdwn
new file mode 100644
index 0000000000..d0591f16f2
--- /dev/null
+++ b/doc/bugs/J1_display_issue.mdwn
@@ -0,0 +1,13 @@
+With -J1, git-annex get does not display filenames:
+
+    git-annex get -J1 foo
+
+    23%   166.11 MiB        3 MiB/s 3m18s
+
+The filename is displayed at end.
+
+This does not happen at -J2 or without -J.
+
+--[[Joey]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8.mdwn b/doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8.mdwn
new file mode 100644
index 0000000000..9cd08ff769
--- /dev/null
+++ b/doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8.mdwn
@@ -0,0 +1,91 @@
+### Please describe the problem.
+I had also commented this on [[another bug|bugs/git-annex_fromkey_barfs_on_utf-8_input]], but the original issue there is fixed now.
+I tested `fromkey`, `calckey --batch`, `lookupkey --batch` (in standalone) after your fix, they work nicely.
+
+However, `git-annex metadata --batch --json` using the [[linux standalone|install/Linux_standalone]] (autobuild) still fails when it encounters UTF-8 characters (e.g. ü, ç, ä).
+Also, `git-annex metadata --json` gives `"file":"��.txt"` for `ü.txt`.
+
+This happens only in the standalone builds.
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+$ .../git-annex.linux/runshell
+$ touch u.txt ü.txt
+$ git-annex add .
+
+$ git-annex metadata --batch --json
+{"file":"ü.txt"}
+git-annex: Batch input parse failure: Error in $: Failed reading: Cannot decode byte '\xb3': Data.Text.Internal.Encoding.decodeUtf8: Invalid UTF-8 stream
+
+$ git-annex metadata --batch --json
+{"file":"u.txt","fields":{"ç":["b"]}}
+git-annex: Batch input parse failure: Error in $: Failed reading: Cannot decode byte '\xb3': Data.Text.Internal.Encoding.decodeUtf8: Invalid UTF-8 stream
+
+$ git-annex metadata --batch --json
+{"file":"u.txt","fields":{"b":["ä"]}}
+git-annex: Batch input parse failure: Error in $: Failed reading: Cannot decode byte '\xb3': Data.Text.Internal.Encoding.decodeUtf8: Invalid UTF-8 stream
+
+$ git-annex metadata --json
+{"command":"metadata","note":"","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"u.txt","fields":{}}
+{"command":"metadata","note":"","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"��.txt","fields":{}}
+# success, but the second line should have "file":"ü.txt"
+"""]]
+
+It's the same even if I call `.../git-annex.linux/git-annex` directly (without `runshell`)
+
+### What version of git-annex are you using? On what operating system?
+Using the Linux standalone: [git-annex-standalone-amd64.tar.gz](https://downloads.kitenet.net/git-annex/autobuild/amd64/git-annex-standalone-amd64.tar.gz) on Xubuntu 16.04
+
+[[!format sh """
+$ git-annex version
+git-annex version: 6.20161213-g55a34b493
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux x86_64
+"""]]
+
+### Please provide any additional information below.
+
+None of the characters I used have `\xb3` in it, but all the errors happen due to it:
+[[!format sh """
+$ .../git-annex.linux/runshell
+$ echo -n ü | xxd
+00000000: c3bc                                     ..
+$ echo -n ç | xxd
+00000000: c3a7                                     ..
+$ echo -n ä | xxd
+00000000: c3a4                                     ..
+"""]]
+
+In `runshell`, `ls` can't show UTF-8, but `git-annex status` can:
+[[!format sh """
+$ .../git-annex.linux/runshell
+$ ls
+u.txt  ??.txt
+$ git-annex status
+A u.txt
+A ü.txt
+"""]]
+
+`man` complains about locale in `runshell` as well:
+[[!format sh """
+$ .../git-annex.linux/runshell
+$ man
+man: can\'t set the locale; make sure $LC_* and $LANG are correct
+What manual page do you want?
+# I escaped that \', formatting was messy otherwise
+$ set | grep LANG
+GDM_LANG='en_GB'
+LANG='en_GB.UTF-8'
+LANGUAGE='en_GB:en'
+$ set | grep LC
+# nothing
+"""]]
+
+[[!meta title="metadata --batch --json cannot parse utf8 when not in utf8 locale"]]
+[[!tag confirmed]]
diff --git a/doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8/comment_1_1765400777911cc61eb591b76c84ae89._comment b/doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8/comment_1_1765400777911cc61eb591b76c84ae89._comment
new file mode 100644
index 0000000000..4a15b19871
--- /dev/null
+++ b/doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8/comment_1_1765400777911cc61eb591b76c84ae89._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-12-19T20:37:56Z"
+ content="""
+runshell was recently changed to bypass using the system locales, it
+includes its own locale data and attempts to generate a locale definition
+file for the locale. The code that did that was failing to notice that
+en_GB.UTF-8 was a UTF-8 locale (en_GB.utf8 would work though), which
+explains why the locale is not set inside runshell
+(git-annex.linux/git-annex is a script that uses runshell). I've corrected
+that problem, and verified it fixes the problem you reported.
+
+----
+
+However.. The same thing happens when using LANG=C with git-annex
+installed by any method and --json --batch. So the deeper problem is that
+it's forcing the batch input to be decoded as utf8 via the current locale.
+This happens in Command/MetaData.hs parseJSONInput which uses
+`BU.fromString`. 
+
+I tried swapping in `encodeBS` for `BU.fromString`. That prevented the
+decoding error, but made git-annex complain that the file was not annexed,
+due to a Mojibake problem: 
+
+With `encodeBS`, the input `{"file":"ü.txt"}` is encoded as
+`"{\"file\":\"\195\188.txt\"}"`. Aeson parses that input to this:
+
+	JSONActionItem {itemCommand = Nothing, itemKey = Nothing, itemFile = Just "\252.txt", itemAdded = Nothing}
+
+Note that the first two bytes have been
+parsed by Aeson as unicode (since JSON is unicode encoded),
+yielding character 252 (ü).
+
+In a unicode locale, this works ok, because the encoding layer is able to
+convert that unicode character back to two bytes 195 188 
+and finds the file on disk. But in a non-unicode locale, it doesn't know
+what to do with the unicode character, and in fact it gets discarded
+and so it looks for a file named ".txt".
+
+So, to make --batch --json input work in non-unicode locales, it would
+need, after parsing the json, to re-encode filenames (and perhaps other
+data), from utf8 to the filesystem encoding. I have not yet worked out how
+to do that.
+"""]]
diff --git a/doc/bugs/Local_network___40__ssh__41___fails_to_pair__47__sync.mdwn b/doc/bugs/Local_network___40__ssh__41___fails_to_pair__47__sync.mdwn
new file mode 100644
index 0000000000..bff665a5e9
--- /dev/null
+++ b/doc/bugs/Local_network___40__ssh__41___fails_to_pair__47__sync.mdwn
@@ -0,0 +1,177 @@
+### Please describe the problem.
+I am trying to set out two computers on the same network to synchronise.
+
+### What steps will reproduce the problem?
+Install Git-Annex. Start the webapp. Try to connect. Enter a secret phrase on both. The Mythbuntu machine shows "Failed to sync with Inspiron 14z" (the laptop). The laptop shows "Pairing in progress" forever.
+
+The machines can normally connect together passwordlessly through ssh with public key encryption. 
+
+### What version of git-annex are you using? On what operating system?
+Ubuntu Raring Version: 3.20121112ubuntu2 from the repos on my laptop.  Install version 4.20130627 from the PPA on Mythbuntu Precise (which I use as a home server).
+
+### Please provide any additional information below.
+From the the laptop, where I started the pairing:
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+$ git-annex webapp 
+
+(process:3084): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
+
+** (firefox:3084): WARNING **: Failed to find domain member of JSON manifest
+Running global cleanup code from study base classes.
+(Recording state in git...)
+
+Launching web browser on file:///tmp/webapp3075.html
+(scanning...) 
+  dbus failed; falling back to mtab polling (ClientError {clientErrorMessage = "Call failed: The name org.gtk.Private.GduVolumeMonitor was not provided by any .service files", clientErrorFatal = False})
+(started...) Generating public/private rsa key pair.
+Your identification has been saved in /tmp/git-annex-keygen3075.0/key.
+Your public key has been saved in /tmp/git-annex-keygen3075.0/key.pub.
+The key fingerprint is:
+79:00:67:a4:f0:5f:62:26:78:ed:09:97:e4:c4:dd:56 aaron@Inspiron-14z
+The key's randomart image is:
++--[ RSA 2048]----+
+|    . .o*. . .E  |
+|     + X... o    |
+|    . * X ..     |
+|     . O *       |
+|        S .      |
+|         .       |
+|                 |
+|                 |
+|                 |
++-----------------+
+Control socket connect(/home/shared/annex/.git/annex/ssh/mythbuntu@git-annex-mythbuntu-server.local-mythbuntu): Connection refused
+Failed to connect to new control master
+warning: no common commits
+
+  Remote mythbuntuserver.local_annex does not have git-annex installed; setting remote.mythbuntuserver.local_annex.annex-ignore
+Already up-to-date.
+Counting objects: 13, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (9/9), done.
+Writing objects: 100% (11/11), 1.06 KiB, done.
+Total 11 (delta 2), reused 0 (delta 0)
+To ssh://mythbuntu@git-annex-mythbuntu-server.local-mythbuntu/~/annex/
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+Already up-to-date!
+Merge made by the 'recursive' strategy.
+Already up-to-date.
+Already up-to-date.
+Counting objects: 2, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (2/2), done.
+Writing objects: 100% (2/2), 326 bytes, done.
+Total 2 (delta 1), reused 0 (delta 0)
+To ssh://mythbuntu@git-annex-mythbuntu-server.local-mythbuntu/~/annex/
+   82bf946..dfe0bd1  master -> synced/master
+Already up-to-date.
+SendMessage (77594660, 0x101f, (nil), (nil))
+SendMessage (0, 0x1203, (nil), 0x7fffc68a1850)
+SendMessage (0, 0x1204, (nil), 0x7fffc68a1850)
+SendMessage (0, 0x1203, 0x1, 0x7fffc68a1850)
+SendMessage (0, 0x1204, 0x1, 0x7fffc68a1850)
+SendMessage (0, 0x1203, 0x2, 0x7fffc68a1850)
+SendMessage (0, 0x1204, 0x2, 0x7fffc68a1850)
+SendMessage (0, 0x1203, 0x3, 0x7fffc68a1850)
+SendMessage (0, 0x1204, 0x3, 0x7fffc68a1850)
+SendMessage (0, 0x1203, 0x4, 0x7fffc68a1850)
+SendMessage (0, 0x1204, 0x4, 0x7fffc68a1850)
+SendMessage (77594660, 0x101f, (nil), (nil))
+SendMessage (0, 0x1203, (nil), 0x7fffc68a1810)
+SendMessage (0, 0x1204, (nil), 0x7fffc68a1810)
+SendMessage (0, 0x1203, 0x1, 0x7fffc68a1810)
+SendMessage (0, 0x1204, 0x1, 0x7fffc68a1810)
+SendMessage (0, 0x1203, 0x2, 0x7fffc68a1810)
+SendMessage (0, 0x1204, 0x2, 0x7fffc68a1810)
+SendMessage (0, 0x1203, 0x3, 0x7fffc68a1810)
+SendMessage (0, 0x1204, 0x3, 0x7fffc68a1810)
+SendMessage (0, 0x1203, 0x4, 0x7fffc68a1810)
+SendMessage (0, 0x1204, 0x4, 0x7fffc68a1810)
+SendMessage (77594660, 0x101f, (nil), (nil))
+SendMessage (0, 0x1203, (nil), 0x7fffc68a2920)
+SendMessage (0, 0x1204, (nil), 0x7fffc68a2920)
+SendMessage (0, 0x1203, 0x1, 0x7fffc68a2920)
+SendMessage (0, 0x1204, 0x1, 0x7fffc68a2920)
+SendMessage (0, 0x1203, 0x2, 0x7fffc68a2920)
+SendMessage (0, 0x1204, 0x2, 0x7fffc68a2920)
+SendMessage (0, 0x1203, 0x3, 0x7fffc68a2920)
+SendMessage (0, 0x1204, 0x3, 0x7fffc68a2920)
+SendMessage (0, 0x1203, 0x4, 0x7fffc68a2920)
+SendMessage (0, 0x1204, 0x4, 0x7fffc68a2920)
+Redirection loop trying to set HTTPS on:
+  http://www.aol.com/favicon.ico
+(falling back to HTTP)
+SendMessage (77594652, 0x444, 0x1, 0x3652e00)
+SendMessage (77594652, 0x444, 0x1, 0x3647de0)
+SendMessage (77594652, 0x444, 0x1, 0x3667a80)
+SendMessage (77594652, 0x444, 0x1, 0x3667a80)
+
+# End of transcript or log.
+# End of transcript or log.
+"""]]
+
+On the Mythbuntu machine:
+[[!format sh """
+$ git-annex webapp
+Launching web browser on file:///tmp/webapp8399.html
+(Recording state in git...)
+"""]]
+
+Unless I'm going mad, there doesn't seem to be a daemon.log on my laptop.
+
+Daemon.log on the Mythbuntu machine:
+[[!format sh """
+[2013-07-14 10:38:56 BST] main: starting assistant version 4.20130627
+(scanning...) [2013-07-14 10:38:56 BST] Watcher: Performing startup scan
+(started...) [2013-07-14 10:38:57 BST] PairListener: aaron@Inspiron-14z:/home/shared/annex is sending a pair request.
+Generating public/private rsa key pair.
+Your identification has been saved in /tmp/git-annex-keygen.0/key.
+Your public key has been saved in /tmp/git-annex-keygen.0/key.pub.
+The key fingerprint is:
+bb:8c:66:05:22:8e:fa:e1:10:33:6d:cb:d6:57:e2:47 mythbuntu@mythbuntu-server
+The key's randomart image is:
++--[ RSA 2048]----+
+|                 |
+|                 |
+|                 |
+| .. . .          |
+|+oo. ...E        |
+|.*.o . +..       |
+|o = . o.o        |
+|.+ . .o+ .       |
+| .o  o. o        |
++-----------------+
+[2013-07-14 10:39:13 BST] main: Pairing with aaron@Inspiron-14z:/home/shared/annex in progress
+ssh: connect to host Inspiron-14z.local port 22: Connection refused
+ssh: connect to host Inspiron-14z.local port 22: Connection refused
+fatal: The remote end hung up unexpectedly
+[2013-07-14 10:39:17 BST] PairListener: Syncing with Inspiron14z.local__home_shared_annex 
+ssh: connect to host Inspiron-14z.local port 22: Connection refused
+fatal: The remote end hung up unexpectedly
+ssh: connect to host Inspiron-14z.local port 22: Connection refused
+fatal: The remote end hung up unexpectedly
+ssh: connect to host Inspiron-14z.local port 22: Connection refused
+fatal: The remote end hung up unexpectedly
+Already up-to-date.
+Already up-to-date.
+ssh: connect to host Inspiron-14z.local port 22: Connection refused
+fatal: The remote end hung up unexpectedly
+ssh: connect to host Inspiron-14z.local port 22: Connection refused
+fatal: The remote end hung up unexpectedly
+Updating 82bf946..dfe0bd1
+Fast-forward
+[2013-07-14 10:39:56 BST] Pusher: Syncing with Inspiron14z.local__home_shared_annex 
+ssh: connect to host Inspiron-14z.local port 22: Connection refused
+fatal: The remote end hung up unexpectedly
+ssh: connect to host Inspiron-14z.local port 22: Connection refused
+fatal: The remote end hung up unexpectedly
+ssh: connect to host Inspiron-14z.local port 22: Connection refused
+fatal: The remote end hung up unexpectedly
+ssh: connect to host Inspiron-14z.local port 22: Connection refused
+fatal: The remote end hung up unexpectedly
+"""]]
+
+[[!taglink moreinfo]]
diff --git a/doc/bugs/Local_network___40__ssh__41___fails_to_pair__47__sync/comment_1_bab9cd5bdcffec3c48b9e8657cd9bbf7._comment b/doc/bugs/Local_network___40__ssh__41___fails_to_pair__47__sync/comment_1_bab9cd5bdcffec3c48b9e8657cd9bbf7._comment
new file mode 100644
index 0000000000..272cf26840
--- /dev/null
+++ b/doc/bugs/Local_network___40__ssh__41___fails_to_pair__47__sync/comment_1_bab9cd5bdcffec3c48b9e8657cd9bbf7._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnFjuvfPpi1kf6l54bxfFUm0Aw_Gf_IO0o"
+ nickname="Aaron"
+ subject="Some things working"
+ date="2013-07-14T10:06:13Z"
+ content="""
+Oh, that's odd...
+
+The Mythbuntu machine says it fails and the laptop screen still says pairing, but a new window on the laptop says that it synced with the Mythbuntu server. On the Mythbuntu server, it has a blank entry for the laptop, which if you click to edit says \"Internal Server Error\" \"Unknown UUID\".
+
+When I add things on the laptop, they immediately become shortcuts and an equivalent shortcut appears on the Mythbuntu machine, though updates to the content (in this case a text file) are not sychronised. 
+
+Adding a file on the Mythbuntu machine does not turn into a shortcut and nothing appears on the laptop.
+"""]]
diff --git a/doc/bugs/Local_network___40__ssh__41___fails_to_pair__47__sync/comment_2_104898dce3c67c082a9f2b36e2f45ff8._comment b/doc/bugs/Local_network___40__ssh__41___fails_to_pair__47__sync/comment_2_104898dce3c67c082a9f2b36e2f45ff8._comment
new file mode 100644
index 0000000000..09d7a6d59a
--- /dev/null
+++ b/doc/bugs/Local_network___40__ssh__41___fails_to_pair__47__sync/comment_2_104898dce3c67c082a9f2b36e2f45ff8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 2"
+ date="2013-07-28T00:27:23Z"
+ content="""
+Remote mythbuntuserver.local_annex does not have git-annex installed; setting remote.mythbuntuserver.local_annex.annex-ignore
+
+So, how did you install git-annex on mythbuntuserver? What does the `.ssh/authorized_keys` on mythbuntuserver look like? (In particular the key that git-annex adds to it, which should be set to run git-annex-shell.)
+"""]]
diff --git a/doc/bugs/Location_change_of_remote_DNS_ignored.mdwn b/doc/bugs/Location_change_of_remote_DNS_ignored.mdwn
new file mode 100644
index 0000000000..b35f660685
--- /dev/null
+++ b/doc/bugs/Location_change_of_remote_DNS_ignored.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+git-annex ignores changing of remote location in .git/config
+
+### What steps will reproduce the problem?
+1. Change Hostname of previously working remote so that the existing remote will no longer work and produce "ssh: connect to host <DNS hostname> port 22: Network is unreachable" errors.
+2. Stop all running git-annex processes.
+3. Edit DNS name in corresponding remote .git/config.
+4. Restart git-annex.
+5. Turns out: git-annex still uses the old remote's DNS name.
+
+### What version of git-annex are you using? On what operating system?
+newest one available.
+5.20151116-gbe86081 
+
+### Please provide any additional information below.
+See following entry in log, occurring plenty often:
+[[!format sh """
+ssh: connect to host some.unreachable.dns.net port 22: Network is unreachable
+rsync: connection unexpec
+  rsync failed -- run git annex again to resume file transfer
+tedly closed (0 bytes received so far) [Receiver]
+rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.1]
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Trust me I love git-annex. Had dreams of something like git-annex for almost 10 years. I instantly got stuck on git-annex when I have read the first few sentences about it. Since then, things in my life have changed in a quite serious manner.
+
+THANKS for your help!
diff --git a/doc/bugs/Location_change_of_remote_DNS_ignored/comment_1_449bfb3a594f99cf5e71a6e18d6d3dbc._comment b/doc/bugs/Location_change_of_remote_DNS_ignored/comment_1_449bfb3a594f99cf5e71a6e18d6d3dbc._comment
new file mode 100644
index 0000000000..4f81c4348e
--- /dev/null
+++ b/doc/bugs/Location_change_of_remote_DNS_ignored/comment_1_449bfb3a594f99cf5e71a6e18d6d3dbc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="torpidus"
+ subject="comment 1"
+ date="2015-12-06T20:29:25Z"
+ content="""
+**self-edit**:
+Changed location of .git/config once again as described but instead of re-starting assistant, I ran \"git-annex sync\" which ended with no errors. After that, assistant started correctly and also had the corrected remote location. From my point of view, this thread has been resolved - even though I wonder what changed the value back to the old one in the first place.
+"""]]
diff --git a/doc/bugs/Location_change_of_remote_DNS_ignored/comment_2_b097dec73d4965f62c61003ed27e4209._comment b/doc/bugs/Location_change_of_remote_DNS_ignored/comment_2_b097dec73d4965f62c61003ed27e4209._comment
new file mode 100644
index 0000000000..d099ea8046
--- /dev/null
+++ b/doc/bugs/Location_change_of_remote_DNS_ignored/comment_2_b097dec73d4965f62c61003ed27e4209._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-12-11T15:24:44Z"
+ content="""
+It seems likely that you didn't stop the assistant. There's no
+caching of urls to git remotes; git-annex just uses whatever's there in
+.git/config.
+"""]]
diff --git a/doc/bugs/Low_disk_space_corrupts_state.mdwn b/doc/bugs/Low_disk_space_corrupts_state.mdwn
new file mode 100644
index 0000000000..ecdfc48a2e
--- /dev/null
+++ b/doc/bugs/Low_disk_space_corrupts_state.mdwn
@@ -0,0 +1,61 @@
+### Please describe the problem.
+
+When there are low disk space left, changes in the annex repo are only semi updated, leaving the dir and git annex state out of sync, leaving error messages with "invalid objects" and "fatal: git-write-tree: error building trees".
+
+I ignored these errors, and kept on trying to copy over all the files to a remote disk, since I wanted a backup, which resultet in symlinks pointing to files which aren't there.
+
+Maybe git-annex should stop if it sees that it's not enough disk space to perform a certain operation? E.g. cache space needed for syncing.
+
+### What steps will reproduce the problem?
+
+I'm not certain about what command that created the issue, but i ran various commands:
+
+- `git annex sync EXTERNALREPO`
+- `git annex copy --to EXTERNALREPO`
+- `git annex unlock Videos/`
+- `git annex lock Videos/`
+
+My disk had 280MB left, and the repo were at a few GBs. Somewhere in between these commands, git-annex started producing a lot of error messages for various files.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20140717 (Fedora 23)
+
+### Please provide any additional information below.
+
+Unfortunately, I don't have the full transcript of my badly behaved commands. Instead I add some of the error messages:
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+    $ git annex lock Videos/
+    error: invalid object 100644 56715f46d9256bdcef0cd387364818e597dc9f41 for '003/a56/SHA256-s23430--26dc3b33a5101e4ead217241a371b17f15e7a2f37bbcaedd0d35a0a1aa4eb9b0.log.cnk'
+    fatal: git-write-tree: error building trees
+    git-annex: failed to read sha from git write-tree
+    
+    $ git annex sync
+    error: refs/remotes/remote_annex/synced/master does not point to a valid object!
+    error: refs/remotes/home/synced/master does not point to a valid object!
+    error: refs/remotes/work_annex/synced/master does not point to a valid object!
+    error: refs/remotes/home_annex/synced/master does not point to a valid object!
+    error: refs/remotes/home/synced/master does not point to a valid object!
+    error: refs/remotes/work_annex/synced/master does not point to a valid object!
+    error: Could not read bf3d6640fa32460032926ae6...
+    fatal: revision walk setup failed
+    error: Could not read 8cdec1808723971eaf30e32...
+    fatal: revision walk setup failed
+    (merging work/git-annex into git-annex...)
+    fatal: unable to read tree 21e0681190de239f41d...
+    (Recording state in git...)
+    error: invalid object 100644 56715f36d9256bdeff... for '003/a56/SHA256-s23430--2dc3b411e5ead...log.cnk'
+    fatal: git-write-tree: error building trees
+    git-annex: failed to read sha from git write-tree
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+It worked as a charm until my disk got full! (Maybe it is better to split it up in various, smaller repos, and sync them individually?)
diff --git a/doc/bugs/Low_disk_space_corrupts_state/comment_1_d8235498e2206c3b5284455e5c4182b9._comment b/doc/bugs/Low_disk_space_corrupts_state/comment_1_d8235498e2206c3b5284455e5c4182b9._comment
new file mode 100644
index 0000000000..334a0fd94b
--- /dev/null
+++ b/doc/bugs/Low_disk_space_corrupts_state/comment_1_d8235498e2206c3b5284455e5c4182b9._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joakim.hovlandsvag@ad788ffa13d1ccbf03f2c485653900f8baa33950"
+ nickname="joakim.hovlandsvag"
+ subject="Repairing ignores disk space issues too"
+ date="2015-12-13T09:13:24Z"
+ content="""
+It seems that `git annex repair` also ignores such issues:
+
+    $ git annex repair
+    Running git fsck ...
+    Initialized empty Git repository in /tmp/tmprepo.0/.git/
+    Trying to recover missing objects from remote home.
+    Unpacking all pack files.
+    error: file write error (No space left on device)
+    fatal: unable to write sha1 file
+    Successfully recovered repository!
+    You should run \"git fsck\" to make sure, but it looks like everything was recovered ok.
+    ok
+
+"""]]
diff --git a/doc/bugs/Low_disk_space_corrupts_state/comment_2_0e47c63a48e10ae760754df0ce165388._comment b/doc/bugs/Low_disk_space_corrupts_state/comment_2_0e47c63a48e10ae760754df0ce165388._comment
new file mode 100644
index 0000000000..3ee40ef92e
--- /dev/null
+++ b/doc/bugs/Low_disk_space_corrupts_state/comment_2_0e47c63a48e10ae760754df0ce165388._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-04-13T19:23:29Z"
+ content="""
+I suggest that you first free up some disk space, and only then try to run
+`git annex repair`.
+
+I checked, and git-annex repair actually has a legitimate reason for
+ignoring the error to unpack a pack file. The pack file could be corrupt.
+It can't tell why git fails to unpack a pack file, so can't detect that
+it's due to low disk space.
+
+I don't know if git-repair managed to get your repository back to a working
+state (although with git history lost) or not. It seems like it thinks
+it managed to repair the repo enough for it to work, is that not the case?
+"""]]
diff --git a/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected.mdwn b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected.mdwn
new file mode 100644
index 0000000000..47eef03017
--- /dev/null
+++ b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected.mdwn
@@ -0,0 +1,126 @@
+### Please describe the problem.
+
+I've added a backup USB Drive and a small archive USB drive and created a archive folder in the root of my ~/annex folder.
+
+If I move a file into the ~/annex folder and then move the same file into the ~/annex/archive folder the file gets uploaded to the small archive USB drive, but not dropped from my ~/annex/archive folder.
+
+[[!format sh """
+[2015-08-14 19:03:47 CEST] Committer: Adding git-annex..iving.ogv
+ok
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+add /Users/markus/annex/git-annex-assistant-archiving.ogv [2015-08-14 19:03:47 CEST] Committer: Committing changes to git
+[2015-08-14 19:03:47 CEST] Pusher: Syncing with annexbackup, annexarchive
+
+git-annex-assistant-archiving.ogv
+To /Volumes/annex-archive/annex-archive0
+   6ef9226..6c87a7d  git-annex -> synced/git-annex
+   b8855cc..bc20ee2  annex/direct/master -> synced/master
+To /Volumes/annex-backup/annex-backup
+   6ef9226..6c87a7d  git-annex -> synced/git-annex
+   b8855cc..bc20ee2  annex/direct/master -> synced/master
+    15428954 100%   20.71MB/s    0:00:00 (xfer#1, to-check=0/1)
+
+sent 15430948 bytes  received 42 bytes  10287326.67 bytes/sec
+total size is 15428954  speedup is 1.00
+[2015-08-14 19:03:48 CEST] Transferrer: Uploaded git-annex..iving.ogv
+[2015-08-14 19:03:49 CEST] Pusher: Syncing with annexbackup, annexarchive
+To /Volumes/annex-backup/annex-backup
+   6c87a7d..d24edd5  git-annex -> synced/git-annex
+To /Volumes/annex-archive/annex-archive
+   6c87a7d..d24edd5  git-annex -> synced/git-annex
+[2015-08-14 19:04:23 CEST] Committer: Adding git-annex..iving.ogv
+ok
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+add /Users/markus/annex/archive/git-annex-assistant-archiving.ogv [2015-08-14 19:04:23 CEST] Committer: Committing changes to git
+[2015-08-14 19:04:23 CEST] Pusher: Syncing with annexbackup, annexarchive
+
+git-annex-assistant-archiving.ogv
+To /Volumes/annex-backup/annex-backup:00
+   d24edd5..507be0c  git-annex -> synced/git-annex
+   bc20ee2..8fea81a  annex/direct/master -> synced/master
+To /Volumes/annex-archive/annex-archive
+   d24edd5..507be0c  git-annex -> synced/git-annex
+   bc20ee2..8fea81a  annex/direct/master -> synced/master
+    15428954 100%   30.72MB/s    0:00:00 (xfer#1, to-check=0/1)
+
+sent 15430948 bytes  received 42 bytes  30861980.00 bytes/sec
+total size is 15428954  speedup is 1.00
+[2015-08-14 19:04:23 CEST] Transferrer: Uploaded git-annex..iving.ogv
+[2015-08-14 19:04:25 CEST] Pusher: Syncing with annexbackup, annexarchive
+To /Volumes/annex-archive/annex-archive
+   507be0c..ba58f77  git-annex -> synced/git-annex
+To /Volumes/annex-backup/annex-backup
+   507be0c..ba58f77  git-annex -> synced/git-annex
+"""]]
+
+If I directly move a file e.g. from ~/Downloads to ~/annex/archive the file gets uploaded to the small archive USB drive and then dropped from my drive (as expected).
+
+[[!format sh """
+[2015-08-14 19:04:25 CEST] Pusher: Syncing with annexbackup, annexarchive
+To /Volumes/annex-archive/annex-archive
+   507be0c..ba58f77  git-annex -> synced/git-annex
+To /Volumes/annex-backup/annex-backup
+   507be0c..ba58f77  git-annex -> synced/git-annex
+[2015-08-14 19:09:44 CEST] Committer: Adding Oracle_VM..x-extpack
+ok
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+add /Users/markus/annex/archive/Oracle_VM_VirtualBox_Extension_Pack-5.0.0-101573.vbox-extpack [2015-08-14 19:09:44 CEST] Committer: Committing changes to git
+[2015-08-14 19:09:44 CEST] Pusher: Syncing with annexbackup, annexarchive
+
+Oracle_VM_VirtualBox_Extension_Pack-5.0.0-101573.vbox-extpack
+To /Volumes/annex-backup/annex-backup:00
+   ba58f77..73eed9e  git-annex -> synced/git-annex
+   8fea81a..68526f7  annex/direct/master -> synced/master
+To /Volumes/annex-archive/annex-archive
+   ba58f77..73eed9e  git-annex -> synced/git-annex
+   8fea81a..68526f7  annex/direct/master -> synced/master
+    18028050 100%   25.65MB/s    0:00:00 (xfer#1, to-check=0/1)
+
+sent 18030392 bytes  received 42 bytes  12020289.33 bytes/sec
+total size is 18028050  speedup is 1.00
+[2015-08-14 19:09:45 CEST] Transferrer: Uploaded Oracle_VM..x-extpack
+ok
+(recording state in git...)
+(recording state in git...)
+drop /Users/markus/annex/archive/Oracle_VM_VirtualBox_Extension_Pack-5.0.0-101573.vbox-extpack [2015-08-14 19:09:47 CEST] Pusher: Syncing with annexbackup, annexarchive
+To /Volumes/annex-backup/annex-backup
+   73eed9e..93dc4a3  git-annex -> synced/git-annex
+To /Volumes/annex-archive/annex-archive
+   73eed9e..93dc4a3  git-annex -> synced/git-annex
+"""]]
+
+But if I move the file-link from ~/annex/archive to ~/annex the file stays a link and don't get transferred back to my drive.
+
+[[!format sh """
+[2015-08-14 19:12:39 CEST] Committer: Committing changes to git
+[2015-08-14 19:12:39 CEST] Pusher: Syncing with annexbackup, annexarchive
+To /Volumes/annex-backup/annex-backup
+   68526f7..082e0d8  annex/direct/master -> synced/master
+To /Volumes/annex-archive/annex-archive
+   68526f7..082e0d8  annex/direct/master -> synced/master
+"""]] 
+
+
+### What version of git-annex are you using? On what operating system?
+
+Im using MacOSX 10.11 Beta (15A243d) with the most resend MacOSX App.
+ 
+[[!format sh """
+$ /Applications/git-annex.app/Contents/MacOS/git-annex version
+git-annex version: 5.20150812-ga6f7b36
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA TorrentParser Database
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+"""]]
+
+
+[[!taglink  confirmed]] —marked as confirmed on 2018-12-30
diff --git a/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_1_c8ce2a1978fc1bfa5f31cff9f48690f6._comment b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_1_c8ce2a1978fc1bfa5f31cff9f48690f6._comment
new file mode 100644
index 0000000000..d1380f1c52
--- /dev/null
+++ b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_1_c8ce2a1978fc1bfa5f31cff9f48690f6._comment
@@ -0,0 +1,57 @@
+[[!comment format=mdwn
+ username="mhubig"
+ subject="comment 1"
+ date="2015-08-17T11:42:18Z"
+ content="""
+Here's some more infos from running git-annex with debug:
+
+Moving a 'symlinked' file from `~/annex/archive` to `~/annex`. I expected that the file get's automagically pulled from the archive drive and the symlink is replaced with the real file.
+but what happens is this:
+
+[[!format sh \"\"\"
+[2015-08-17 13:29:48 CEST] Watcher: file deleted /Users/markus/annex/archive/Crisi\'s Trail und Stubenfelsen Jam.gpx
+[2015-08-17 13:29:48 CEST] Committer: committing 1 changes
+[2015-08-17 13:29:48 CEST] Committer: Committing changes to git
+(recording state in git...)
+[2015-08-17 13:29:48 CEST] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/annex/direct/master\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"write-tree\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"rev-parse\",\"df537468c185961a9785d9288d00b0bc5f628a28:\"]
+[2015-08-17 13:29:48 CEST] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"commit-tree\",\"be3e4a4a4477d6a1aad9fcbd333b43d84295e9b6\",\"--no-gpg-sign\",\"-p\",\"df537468c185961a9785d9288d00b0bc5f628a28\"]
+[2015-08-17 13:29:48 CEST] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"update-ref\",\"refs/heads/annex/direct/master\",\"3436556450500cf342154e9b03bfd1825402f5eb\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2015-08-17 13:29:48 CEST] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"synced/master\"]
+[2015-08-17 13:29:48 CEST] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"master\"]
+[2015-08-17 13:29:48 CEST] Pusher: Syncing with annexbackup, annexarchive
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2015-08-17 13:29:48 CEST] Pusher: pushing to [Remote { name =\"annexbackup\" },Remote { name =\"annexarchive\" }]
+[2015-08-17 13:29:48 CEST] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annexbackup\",\"+git-annex:synced/git-annex\",\"annex/direct/master:synced/master\"]
+[2015-08-17 13:29:48 CEST] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annexarchive\",\"+git-annex:synced/git-annex\",\"annex/direct/master:synced/master\"]
+To /Volumes/annex-archive/annex-archive
+   df53746..3436556  annex/direct/master -> synced/master
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annexarchive\",\"git-annex\",\"master\"]
+To /Volumes/annex-backup/annex-backup
+   464ebc5..2413398  git-annex -> synced/git-annex
+   df53746..3436556  annex/direct/master -> synced/master
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annexbackup\",\"git-annex\",\"master\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/heads/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/annexarchive/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..24133980364c5ae86e939c214deea1b6ab63135c\",\"-n1\",\"--pretty=%H\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..d42c35efe8b1333930587a41aec8744aa0e90ae3\",\"-n1\",\"--pretty=%H\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..796db681152a16121be271668d5f79c845e24b8c\",\"-n1\",\"--pretty=%H\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/annexbackup/synced/master\",\"-n1\",\"--pretty=%H\"]
+\"\"\"]]
+ 
+"""]]
diff --git a/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_2_cf9a679c7e6ec5cae4109e748b20b8f9._comment b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_2_cf9a679c7e6ec5cae4109e748b20b8f9._comment
new file mode 100644
index 0000000000..8398805bed
--- /dev/null
+++ b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_2_cf9a679c7e6ec5cae4109e748b20b8f9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-09-21T19:29:26Z"
+ content="""
+If this is OSX specific, which it seems to be (I've tested archive folders
+working as expected plenty on Linux), it might have to do with the
+assistant not seeing an event for the file being added when it's renamed
+to/from the archive folder. In the --debug log, it looks like the file
+got deleted but never added back.
+
+If this is the case, `git annex status` should show the file as not being
+checked into git.
+"""]]
diff --git a/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_3_4026607087a9da2759f841e59aadfcdc._comment b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_3_4026607087a9da2759f841e59aadfcdc._comment
new file mode 100644
index 0000000000..ae32c97888
--- /dev/null
+++ b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_3_4026607087a9da2759f841e59aadfcdc._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nanotech"
+ subject="comment 3"
+ date="2016-03-17T08:39:36Z"
+ content="""
+I think this is the same bug as [Moved files are not picked up by the assistant on OS X](https://git-annex.branchable.com/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/). To reproduce, run the first transcript there but drop the file before moving it.
+
+FSEvents fails to produce add events for dangling symlinks (<https://github.com/facebook/watchman/issues/172>), although it does produce removal events. Recompiling and using Kqueue with git-annex instead seems to detect dangling symlinks and add them correctly.
+"""]]
diff --git a/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_4_45c1e00e64f916ef8a5f9200144861eb._comment b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_4_45c1e00e64f916ef8a5f9200144861eb._comment
new file mode 100644
index 0000000000..4d33e50579
--- /dev/null
+++ b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_4_45c1e00e64f916ef8a5f9200144861eb._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="olaf"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="comment 4"
+ date="2017-06-22T04:50:13Z"
+ content="""
+I can confirm this is still a problem.
+
+## OS:
+macOS Sierra, version 10.12.5 (16F73)
+
+## git-annex versions:
+
+### OSX DMG install
+```
+Version: 6.20170611-gb493ac8
+Build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Quvi Dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.21 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.6.1 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+```
+
+### Homebrew install
+```
+git-annex version: 6.20170521
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: darwin x86_64
+```
+
+
+## Question
+
+@nanotech - can you elaborate on your recompile with Kqueue comment above?
+"""]]
diff --git a/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_5_9501e259e7d813545ff9cfdac22748f6._comment b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_5_9501e259e7d813545ff9cfdac22748f6._comment
new file mode 100644
index 0000000000..b0c11e7625
--- /dev/null
+++ b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_5_9501e259e7d813545ff9cfdac22748f6._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="olaf"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="Still a problem"
+ date="2017-11-23T04:34:17Z"
+ content="""
+Not wanting to repeat myself, but this is still an issue.
+
+**ISSUE** Moving files to the `archive` folder on MacOS does not result in them being dropped.
+
+## To reproduce
+
+- Created two linked repos with the `webapp`, one is `client` the other is `full archive` type.
+- Using MacOS' GUI drag some files into the `client` directory.
+  - All good.  They get added and copied over to the `full archive` (looking at the `webapp` and `git annex status`)
+- Drag one of the files into the `archive` folder the `webapp`/`assistant` helpfully created for me.
+  - File move is noticed and `git m[o]v[ed]`  (looking at the `webapp` and `git annex status`)
+  - However, file is not dropped from `client` 
+
+
+## Version
+
+    git-annex version: 6.20171109
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents TorrentParser MagicMime Feeds Quvi
+    dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.24 DAV-1.3.1 feed-1.0.0.0 ghc-8.2.1 http-client-0.5.7.0 persistent-sqlite-2.6.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 6
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: darwin x86_64
+
+
+## I want to help!
+
+What can I do to help debug this Joey?
+"""]]
diff --git a/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_6_6c42b7b4c53d2bd547d5ba8d2a3b4c9e._comment b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_6_6c42b7b4c53d2bd547d5ba8d2a3b4c9e._comment
new file mode 100644
index 0000000000..0e99df9d80
--- /dev/null
+++ b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_6_6c42b7b4c53d2bd547d5ba8d2a3b4c9e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="flpgdt@f64318f00d9e1c9535e11f5d27c80c1d799cce00"
+ nickname="flpgdt"
+ avatar="http://cdn.libravatar.org/avatar/df837a3ae490227608cc38a7c9edfc7a"
+ subject="comment 6"
+ date="2018-12-22T20:06:32Z"
+ content="""
+Bumping this bug up in hopes it gets some attention. This feature would be very useful for mac users.
+"""]]
diff --git a/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_7_660bf8f60d340feca469cfd4e28b7e43._comment b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_7_660bf8f60d340feca469cfd4e28b7e43._comment
new file mode 100644
index 0000000000..f5ecf0e0d5
--- /dev/null
+++ b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_7_660bf8f60d340feca469cfd4e28b7e43._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 7"
+ date="2018-12-30T23:23:46Z"
+ content="""
+Just tested with `7.20181106-g352f88226` on macOS 10.12.6. Archive groups work fine with v5 repo but do not work with a v7 repo. With a v7 repo content is synced, but content is never dropped from the source archive folder. If I disable assistant and run `git annex drop --auto` from the client repo this will in fact drop the files from the archive folder. With the v5 repo I get drop logs in daemon.log with the v7 repos I get no errors in the logs and also no drop logs.
+
+Also reported by a user here: [https://git-annex.branchable.com/bugs/OSX_Assistant_will_not_automatically_drop/]
+"""]]
diff --git a/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_8_06c95f066ffc844b0e1e4b4c16d30da8._comment b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_8_06c95f066ffc844b0e1e4b4c16d30da8._comment
new file mode 100644
index 0000000000..ca0c3308aa
--- /dev/null
+++ b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_8_06c95f066ffc844b0e1e4b4c16d30da8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="flpgdt@f64318f00d9e1c9535e11f5d27c80c1d799cce00"
+ nickname="flpgdt"
+ avatar="http://cdn.libravatar.org/avatar/df837a3ae490227608cc38a7c9edfc7a"
+ subject="comment 8"
+ date="2018-12-31T16:53:50Z"
+ content="""
+Would that be a possible workaround? Is there a way to force git-annex to use only v5 repos?
+"""]]
diff --git a/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_9_ab4b7a243f9d1dfddf1c2c2609863d99._comment b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_9_ab4b7a243f9d1dfddf1c2c2609863d99._comment
new file mode 100644
index 0000000000..0a40fc698d
--- /dev/null
+++ b/doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_9_ab4b7a243f9d1dfddf1c2c2609863d99._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 9"
+ date="2019-01-01T19:00:07Z"
+ content="""
+I believe all repos are created at v5 by default currently both from the command-line and the assistant webapp, but there is no guarantee that will always be the case. With the latest version of git-annex a v6 repo will automatically be upgraded to a v7 repo whenever you run any git-annex command (or start the assistant or webapp).
+
+Also just for help troubleshooting Joey: I just tested this with `6.20180914-g13dc117e9` and v6 indirect repos. Same issue, files moved to an archive folder (unlocked and locked) are never dropped by the assistant even after they have reached an archive repo. As with v7 repos, running `git-annex drop --auto` does drop them.
+"""]]
diff --git a/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X.mdwn b/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X.mdwn
new file mode 100644
index 0000000000..0a3815cb96
--- /dev/null
+++ b/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+On indirect repos on OS X, when a symlink is moved asisstant does not pick it up it. Even though assistant syncs after delete/move changes are not committed. git annex status returns ?? for the moved files. when I run git annex add on the files it says it added them but instead they still show up as ??. the only way to solve the problem is to manually restart the daemon which commits them.
+
+### What steps will reproduce the problem?
+
+Moving an annex file.
+
+
+### What version of git-annex are you using? On what operating system?
+
+5.20140703 g3cfcd54
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_1_75c14b405929a8f771a7c261dcc4b7a2._comment b/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_1_75c14b405929a8f771a7c261dcc4b7a2._comment
new file mode 100644
index 0000000000..5346cb9495
--- /dev/null
+++ b/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_1_75c14b405929a8f771a7c261dcc4b7a2._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="unable to reproduce, please provide transcript"
+ date="2014-07-11T19:36:37Z"
+ content="""
+I have tried to reproduce this problem on OSX, but it seems to work fine:
+
+<pre>
+oberon:xx joeyh$ git annex assistant 
+oberon:xx joeyh$ date > foo
+oberon:xx joeyh$ git log --stat
+commit 93a208c6aa0080e70a636181606f53af5f2c4441
+Author: Joey Hess <joeyh@oberon.local.tam-lin.net>
+Date:   Fri Jul 11 15:33:50 2014 -0400
+
+ foo | 1 +
+ 1 file changed, 1 insertion(+)
+oberon:xx joeyh$ mv foo bar
+oberon:xx joeyh$ git log --stat
+commit 495592b2977ee96029db99761d20396577ff3c51
+Author: Joey Hess <joeyh@oberon.local.tam-lin.net>
+Date:   Fri Jul 11 15:33:54 2014 -0400
+
+ bar | 1 +
+ foo | 1 -
+ 2 files changed, 1 insertion(+), 1 deletion(-)
+
+commit 93a208c6aa0080e70a636181606f53af5f2c4441
+Author: Joey Hess <joeyh@oberon.local.tam-lin.net>
+Date:   Fri Jul 11 15:33:50 2014 -0400
+
+ foo | 1 +
+ 1 file changed, 1 insertion(+)
+oberon:xx joeyh$ git annex status
+oberon:xx joeyh$ 
+</pre>
+
+> when I run git annex add on the files it says it added them but instead they still show up as ??
+
+This must be the root of whatever the problem is, so please provide a transcript of you doing that.
+"""]]
diff --git a/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_2_f52483415c623ea0649c3805728ce761._comment b/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_2_f52483415c623ea0649c3805728ce761._comment
new file mode 100644
index 0000000000..9b7f17789a
--- /dev/null
+++ b/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_2_f52483415c623ea0649c3805728ce761._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 2"
+ date="2014-07-12T10:00:59Z"
+ content="""
+[[!format sh \"\"\"
+host annex/(master) $ ls -a Staging/Rise*
+Staging/Rise and Fall of the Berlin Wall - History Channel.mkv
+host annex/(master) $ mv Staging/Rise\ and\ Fall\ of\ the\ Berlin\ Wall\ -\ History\ Channel.mkv Documentary/
+host annex/(master) $ git status
+On branch master
+Untracked files:
+  (use \"git add <file>...\" to include in what will be committed)
+
+        Documentary/Rise and Fall of the Berlin Wall - History Channel.mkv
+
+nothing added to commit but untracked files present (use \"git add\" to track)
+host annex/(master) $ ga status
+D Documentary/Rise and Fall of the Berlin Wall - History Channel.mkv
+host annex/(master) $ git annex add .
+add Documentary/Rise and Fall of the Berlin Wall - History Channel.mkv ok
+(Recording state in git...)
+host annex/(master) $ ga status
+D Documentary/Rise and Fall of the Berlin Wall - History Channel.mkv
+host annex/(master) $ git annex sync
+commit  ok
+pull server 
+ok
+host annex/(master) $ ga status
+D Documentary/Rise and Fall of the Berlin Wall - History Channel.mkv
+host annex/(master) $ 
+\"\"\"]]
+
+"""]]
diff --git a/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_3_fd73fbeef61df106f084ac235fca904a._comment b/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_3_fd73fbeef61df106f084ac235fca904a._comment
new file mode 100644
index 0000000000..a659ad2c14
--- /dev/null
+++ b/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_3_fd73fbeef61df106f084ac235fca904a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 3"
+ date="2014-07-12T10:03:07Z"
+ content="""
+BTW the mv operation is picked up by the assistant it start syncing immediately after mv but the symlink link is left dangling. I've also waited for the assistant to sync before readding the file.
+"""]]
diff --git a/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_4_c5e9843a956984efd22bad629930f6bd._comment b/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_4_c5e9843a956984efd22bad629930f6bd._comment
new file mode 100644
index 0000000000..a437142af2
--- /dev/null
+++ b/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/comment_4_c5e9843a956984efd22bad629930f6bd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 4"
+ date="2014-07-14T20:15:07Z"
+ content="""
+Well, I don't see the \"??\" that you were talking about before in your transcript. I do not understand why the file's status shows as \"D\" which means it's deleted. What does `git ls-files` say? Does this stange behavior persist if you stop the assistant from running and re-run the same git-annex commands?
+"""]]
diff --git a/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__.mdwn b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__.mdwn
new file mode 100644
index 0000000000..1cc8e096b1
--- /dev/null
+++ b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__.mdwn
@@ -0,0 +1,69 @@
+### Please describe the problem.
+
+I added a google-cloud nearline special remote.  It worked great for about two weeks.  But now I cannot do any operations on the bucket; they all fail with 400s.
+
+### What steps will reproduce the problem?
+
+(I've XXX'ed out things that look like they might contain secrets.)
+
+	$ AWS_ACCESS_KEY_ID=GOOGXXX AWS_SECRET_ACCESS_KEY=XXX git annex copy --to goog-cloud-nearline2 photos/raw-photos/2007/Birds\ at\ GovCo/ --debug --json --verbose
+	[2016-11-02 10:09:43.617264] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+	[2016-11-02 10:09:43.628311] process done ExitSuccess
+	[2016-11-02 10:09:43.62842] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+	[2016-11-02 10:09:43.638154] process done ExitSuccess
+	[2016-11-02 10:09:43.639472] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+	[2016-11-02 10:09:43.670284] read: git ["config","--null","--list"]
+	[2016-11-02 10:09:43.684014] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","photos/raw-photos/2007/Birds at GovCo/"]
+	copy photos/raw-photos/2007/Birds at GovCo/IMG_4186.dng (checking goog-cloud-nearline2...) [2016-11-02 10:09:43.845838] String to sign: "HEAD\n\n\nWed,  2 Nov 2016 17:09:43 GMT\n/jlebar-annex-nearline2/GPGHMACSHA1--07b92ba4ec937b88911ce8128974ba449382113d"
+	[2016-11-02 10:09:43.845906] Host: "jlebar-annex-nearline2.storage.googleapis.com"
+	[2016-11-02 10:09:43.845938] Path: "/GPGHMACSHA1--07b92ba4ec937b88911ce8128974ba449382113d"
+	[2016-11-02 10:09:43.845966] Query string: ""
+	[2016-11-02 10:09:43.954556] Response status: Status {statusCode = 400, statusMessage = "Bad Request"}
+	[2016-11-02 10:09:43.954689] Response header 'X-GUploader-UploadID': 'XXX'
+	[2016-11-02 10:09:43.954818] Response header 'Content-Type': 'application/xml; charset=UTF-8'
+	[2016-11-02 10:09:43.954893] Response header 'Content-Length': '178'
+	[2016-11-02 10:09:43.95498] Response header 'Date': 'Wed, 02 Nov 2016 17:09:41 GMT'
+	[2016-11-02 10:09:43.955017] Response header 'Expires': 'Wed, 02 Nov 2016 17:09:41 GMT'
+	[2016-11-02 10:09:43.955047] Response header 'Cache-Control': 'private, max-age=0'
+	[2016-11-02 10:09:43.955143] Response header 'Server': 'UploadServer'
+	[2016-11-02 10:09:43.95518] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
+	(StatusCodeException (Status {statusCode = 400, statusMessage = "Bad Request"}) [("X-GUploader-UploadID","XXX"),("Content-Type","application/xml; charset=UTF-8"),("Content-Length","178"),("Date","Wed, 02 Nov 2016 17:09:41 GMT"),("Expires","Wed, 02 Nov 2016 17:09:41 GMT"),("Cache-Control","private, max-age=0"),("Server","UploadServer")] (CJ {expose = []})) failed
+	git-annex: copy: 1 failed
+	CallStack (from HasCallStack):
+	  error, called at ./CmdLine/Action.hs:41:28 in main:CmdLine.Action
+
+### What version of git-annex are you using? On what operating system?
+
+	$ git annex version
+	git-annex version: 6.20160923
+	build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+	key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+	remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+	local repository version: 6
+	supported repository versions: 5 6
+	upgrade supported from repository versions: 0 1 2 3 4 5
+	operating system: darwin x86_64
+
+### Please provide any additional information below.
+
+As I read their docs, GCS should be sending back a more helpful error message
+in the body of the response:
+https://cloud.google.com/storage/docs/xml-api/reference-status.  I tried to
+figure out how to get git annex to print that out, but...did you know git annex
+is a nontrivial Haskell program?  :)
+
+If we could get git annex to print out the body of the response and there is in
+fact an error message in there, I expect the reason for this error would be
+obvious.  Or if we could get git annex to do a "dry run" and print the HTTP
+requeset it *would have* made, I could probably run it in curl and get the
+response that way.
+
+(I actually considered setting up wireshark to capture the response, but I'd
+have to set up an HTTPS MITM...)
+
+I cannot figure out what made this stop working all of a sudden.  I don't think it was a git annex version update, and I checked remotes.log, and this remote's metadata hasn't changed.  (The line for this remote has been updated a few times, but afaict only the timestamp changed.)
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+It was working so great up until it wasn't -- I was very happy.  Thank you
+for all your work on this software; there is nothing like it.
diff --git a/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_1_2a1c20b432dd839e0153827e151fbbc0._comment b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_1_2a1c20b432dd839e0153827e151fbbc0._comment
new file mode 100644
index 0000000000..ed426f3e30
--- /dev/null
+++ b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_1_2a1c20b432dd839e0153827e151fbbc0._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-07T17:34:32Z"
+ content="""
+If you pass the --debug option, the debug output includes a transcript of
+the S3 http session. Edit: I see you did that, so you can in fact see
+the query and response in the debug output.
+
+I can confirm there have been no recent changes to git-annex's S3 support.
+Of course it's possible that if you upgraded git-annex the version of
+<http://hackage.haskell.org/package/aws> used changed, but that seems
+unlikely to cause such breakage.
+
+Seems likely that if it's stopped working, something changed on Google's
+end..
+"""]]
diff --git a/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_2_c227071f23a96ed9928f128e7f77e503._comment b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_2_c227071f23a96ed9928f128e7f77e503._comment
new file mode 100644
index 0000000000..820e6b0401
--- /dev/null
+++ b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_2_c227071f23a96ed9928f128e7f77e503._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="justin.lebar@7a36fcafc322d9a381e89f08ab6289033c6dde91"
+ nickname="justin.lebar"
+ avatar="http://cdn.libravatar.org/avatar/9fca4b61a1ab555f231851e7543f9a3e"
+ subject="comment 2"
+ date="2016-11-20T03:47:23Z"
+ content="""
+Thanks for your reply, Joey.  Sorry for the delay getting back to this -- I didn't realize I hadn't enabled notifications on the thread.
+
+The GCS docs suggest that 400 errors should be accompanied by an explanation in the reply body.
+
+> Error responses usually include a JSON document in the response body, which contains information about the error.
+
+https://cloud.google.com/storage/docs/json_api/v1/status-codes
+
+Do you think we're not getting an http response body here, or that it's not being printed out?
+"""]]
diff --git a/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_3_5ac676877feaa7cdb9e05d6b71b1a4c3._comment b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_3_5ac676877feaa7cdb9e05d6b71b1a4c3._comment
new file mode 100644
index 0000000000..67b215bc72
--- /dev/null
+++ b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_3_5ac676877feaa7cdb9e05d6b71b1a4c3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="justin.lebar@7a36fcafc322d9a381e89f08ab6289033c6dde91"
+ nickname="justin.lebar"
+ avatar="http://cdn.libravatar.org/avatar/9fca4b61a1ab555f231851e7543f9a3e"
+ subject="comment 3"
+ date="2016-12-04T04:30:38Z"
+ content="""
+For a while things were working, but now it's not working again, same problem as before.
+
+Do you think maybe it's a timestamp bug in the signature or something?  That could explain this \"mysteriously works then stops working\" behavior.
+"""]]
diff --git a/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_4_3853bebdfcb7dac647edefd6f55ba8d5._comment b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_4_3853bebdfcb7dac647edefd6f55ba8d5._comment
new file mode 100644
index 0000000000..9b3bc55354
--- /dev/null
+++ b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_4_3853bebdfcb7dac647edefd6f55ba8d5._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-02-20T17:00:55Z"
+ content="""
+I'd expect that the respone body is indeed not shown by --debug.
+
+A timestamp bug seems as good a theory as anything. In either the S3
+library git-annex is using, or the S3 emulation Google Cloud Storage is
+using. Or perhaps google has different versions of the servers that behave
+differently.
+
+Over on [[tips/using_Google_Cloud_Storage]], @Dosenpfand
+reports what looks like the same 400 when initializing a nearline remote.
+
+Since this is using a S3 interoperability layer in Google Cloud Storage,
+I'd not be surprised if there were bugs or limitations in it. 
+Using the native GCS API seems like an increasingly good idea,
+and <https://github.com/bgilbert/gcsannex> implements that.
+"""]]
diff --git a/doc/bugs/No_viable_build_plan_for_ghc_9.2.2.mdwn b/doc/bugs/No_viable_build_plan_for_ghc_9.2.2.mdwn
new file mode 100644
index 0000000000..e2366a6329
--- /dev/null
+++ b/doc/bugs/No_viable_build_plan_for_ghc_9.2.2.mdwn
@@ -0,0 +1,86 @@
+### Please describe the problem.
+
+Some dependencies of `git-annex` don't have viable releases for ghc-9.2.2 (aws, bloomfilter).
+
+```
+cabal v2-build
+Resolving dependencies...
+cabal: Could not resolve dependencies:
+[__0] trying: bloomfilter-2.0.1.0 (user goal)
+[__1] trying: deepseq-1.4.6.1/installed-1.4.6.1 (dependency of bloomfilter)
+[__2] trying: bytestring-0.11.3.0/installed-0.11.3.0 (dependency of
+bloomfilter)
+[__3] trying: base-4.16.1.0/installed-4.16.1.0 (dependency of bloomfilter)
+[__4] trying: git-annex-10.20220322 (user goal)
+[__5] trying: uuid-1.3.15 (dependency of git-annex)
+[__6] trying: time-1.11.1.1/installed-1.11.1.1 (dependency of git-annex)
+[__7] trying: aws-0.22 (dependency of git-annex)
+[__8] next goal: aeson (dependency of git-annex)
+[__8] rejecting: aeson-2.0.3.0 (conflict: aws => aeson>=0.6 && <1.6)
+[__8] skipping: aeson-2.0.2.0, aeson-2.0.1.0, aeson-2.0.0.0 (has the same
+characteristics that caused the previous version to fail: excluded by
+constraint '>=0.6 && <1.6' from 'aws')
+...
+```
+
+### What steps will reproduce the problem?
+
+`cabal v2-build [--allow-newer]`
+
+### What version of git-annex are you using? On what operating system?
+
+I checked out HEAD as of `b25bfecb1`. Building it on OpenBSD with ghc-9.2.2.
+
+
+### Please provide any additional information below.
+
+Building with `--allow-newer` first points at `bloomfilter` which is a [known problem with a patch](https://github.com/bos/bloomfilter/pull/20). The next problem is with `aws` and this appears to [also be a known issue](https://github.com/aristidb/aws/issues/275) which also [has a patch](https://github.com/aristidb/aws/pull/277).
+
+### Have you had any luck using git-annex before? 
+
+Yes, very much so. It works great as an OpenBSD port when built with ghc-8.10.6.
+
+### Minor fix is required to git-annex
+
+Once I apply this little fix to `git-annex` and the two patches referenced above, the code type-checks.
+
+```patch
+diff --git a/Types/Export.hs b/Types/Export.hs
+index a5cb173e5..2d5419b91 100644
+--- a/Types/Export.hs
++++ b/Types/Export.hs
+@@ -21,7 +21,7 @@ import Git.FilePath
+ import Utility.Split
+ import Utility.FileSystemEncoding
+ 
+-import Data.ByteString.Short as S
++import qualified Data.ByteString.Short as S
+ import qualified System.FilePath.Posix as Posix
+ import GHC.Generics
+ import Control.DeepSeq
+```
+
+I also see all but one tests pass, but I'm pretty sure the same test used to fail with the older compiler:
+
+```
+Tests
+  Tasty
+    tasty self-check:                      OK
+      +++ OK, passed 1 test.
+  Repo Tests v8 locked
+    Init Tests
+      init:                                OK (0.77s)
+      add:                                 OK (2.71s)
+    rsync remote:                          FAIL (3.58s)
+      ./Test/Framework.hs:328:
+      able to modify annexed file's foo content
+      Use -p '/rsync remote/' to rerun this test only.
+    conflict resolution (adjusted branch): OK (16.26s)
+    conversion annexed to git:             OK (3.32s)
+    move (ssh remote):                     OK (6.11s)
+    export_import:                         OK (13.23s)
+
+1 out of 8 tests failed (46.00s)
+```
+
+> I took over maintenance of bloomfilter, and this is [[done]] --[[Joey]]
diff --git a/doc/bugs/No_viable_build_plan_for_ghc_9.2.2/comment_1_8e7f9605f05880899eba7eae4e6f7ea0._comment b/doc/bugs/No_viable_build_plan_for_ghc_9.2.2/comment_1_8e7f9605f05880899eba7eae4e6f7ea0._comment
new file mode 100644
index 0000000000..7c13f68095
--- /dev/null
+++ b/doc/bugs/No_viable_build_plan_for_ghc_9.2.2/comment_1_8e7f9605f05880899eba7eae4e6f7ea0._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-02T18:13:47Z"
+ content="""
+I've applied the patch to git-annex to qualify the export.
+
+That failing test is an unrelated and now fixed bug.
+
+I can't do much more about the dependencies needing updates. Aside from
+maintaining them myself, which I kind of have been with aws to an extent,
+but not enough to be able to cut a new release with the fix.
+"""]]
diff --git a/doc/bugs/No_viable_build_plan_for_ghc_9.2.2/comment_2_e30befdadfd7989de2e214b8e1f6ed07._comment b/doc/bugs/No_viable_build_plan_for_ghc_9.2.2/comment_2_e30befdadfd7989de2e214b8e1f6ed07._comment
new file mode 100644
index 0000000000..99c4493b1c
--- /dev/null
+++ b/doc/bugs/No_viable_build_plan_for_ghc_9.2.2/comment_2_e30befdadfd7989de2e214b8e1f6ed07._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-06-21T18:10:04Z"
+ content="""
+aws is fixed
+
+I have emailed bloomfilter's maintainer offering to take on maintenance
+"""]]
diff --git a/doc/bugs/No_way_to_merge_conflicts_while_on_adjusted_branch.mdwn b/doc/bugs/No_way_to_merge_conflicts_while_on_adjusted_branch.mdwn
new file mode 100644
index 0000000000..39f9997a2d
--- /dev/null
+++ b/doc/bugs/No_way_to_merge_conflicts_while_on_adjusted_branch.mdwn
@@ -0,0 +1,74 @@
+### Please describe the problem.
+While on an adjusted branch, merge conflicts can neither be resolved manually nor with a git merge driver. See the transcript below.
+
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 10.20230802
+debian bullseye
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+$ cat ~/.gitconfig 
+...
+[merge "commit"]
+        name = commit conflict markers
+        driver = "bash -c 'git merge-file %A %O %B; exit 0'"
+...
+
+$ cat .gitattributes 
+* annex.backend=SHA256E
+study.org* merge=commit
+
+dotfiles/** merge=commit
+
+$ git annex sync
+git-annex sync will change default behavior to operate on --content in a future version of git-annex. Recommend you explicitly use --no-content (or -g) to prepare for that change. (Or you can configure annex.synccontent)
+commit  
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+ok
+pull uni-lfs 
+(Merging into master...) 
+Auto-merging study.org
+CONFLICT (content): Merge conflict in study.org
+Automatic merge failed; fix conflicts and then commit the result.
+(Merging into master...) 
+Auto-merging study.org
+CONFLICT (content): Merge conflict in study.org
+Automatic merge failed; fix conflicts and then commit the result.
+failed
+push uni-lfs 
+To xxx
+ ! [rejected]          master -> synced/master (non-fast-forward)
+error: failed to push some refs to 'xxx'
+hint: Updates were rejected because a pushed branch tip is behind its remote
+hint: counterpart. Check out this branch and integrate the remote changes
+hint: (e.g. 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+To xxx
+ ! [rejected]          master -> master (non-fast-forward)
+error: failed to push some refs to 'xxx'
+hint: Updates were rejected because a pushed branch tip is behind its remote
+hint: counterpart. Check out this branch and integrate the remote changes
+hint: (e.g. 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+
+  Pushing to uni-lfs failed.
+failed
+sync: 2 failed
+
+$ git annex version
+git-annex version: 10.20230802
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/No_way_to_merge_conflicts_while_on_adjusted_branch/comment_1_77c241c5d61b62b1fae552145c6c94ef._comment b/doc/bugs/No_way_to_merge_conflicts_while_on_adjusted_branch/comment_1_77c241c5d61b62b1fae552145c6c94ef._comment
new file mode 100644
index 0000000000..3a2e141757
--- /dev/null
+++ b/doc/bugs/No_way_to_merge_conflicts_while_on_adjusted_branch/comment_1_77c241c5d61b62b1fae552145c6c94ef._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-01-02T18:05:47Z"
+ content="""
+git is what's doing the automatic merge, using the merge driver that you
+configured. Is the file `study.org` an annexed file? If not, I don't really
+see how this involves git-annex. git doesn't care if an adjusted branch is
+checked out or not, when using a merge driver to merge a non-annexed file.
+
+It looks like your merge driver is perhaps not working..
+"""]]
diff --git a/doc/bugs/Non-annexed_files_being_annexed_and_not_stored.mdwn b/doc/bugs/Non-annexed_files_being_annexed_and_not_stored.mdwn
new file mode 100644
index 0000000000..e05a6181d7
--- /dev/null
+++ b/doc/bugs/Non-annexed_files_being_annexed_and_not_stored.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+Somehow in my repo, perhaps since I started using the webapp, some of the files which have been commited plain into git have become annexed and turned into broken symlinks.  However, they are not marked as stored in any repositories, so it is difficult to recover them (they need to be checked out again from git history).
+
+### What steps will reproduce the problem?
+I'm not sure how this happened.
+
+### What version of git-annex are you using? On what operating system?
+I've been using builds of git annex between february and april of 2016, on linux.
+
+### Please provide any additional information below.
+
+It looks like the problem occurred on Sun Apr 10 00:49:27 2016 -0400.  I'm mostly recording here that this problem happened, as a lot is on my backlog atm, but if somebody wanted to let me know what logs to investigate, I plan to still be using this repository into the future.
+
+It looks like the system which caused this problem had a looser largefiles setting than the system which added the files to git.  It looks like it was using the 6.20160229-g37a89cc build.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Git-annex rocks, I am a monthly flatr'r.
diff --git a/doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_1_ef6c2dee191e80a46e348c78ba054fc2._comment b/doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_1_ef6c2dee191e80a46e348c78ba054fc2._comment
new file mode 100644
index 0000000000..7db4ea2233
--- /dev/null
+++ b/doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_1_ef6c2dee191e80a46e348c78ba054fc2._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-20T18:09:37Z"
+ content="""
+Seems that there are two potential bugs here; a file that was stored in git
+somehow got stored in the annex instead, and something seems to have
+happened to the content of the file in the annex.
+
+Try using `git annex log` to see where the content of the file was
+stored in the past and when the content got marked as no longer being
+present.
+
+A looser annex.largefiles setting could result in a modified file
+that had been stored in git being stored in the annex instead.
+Look at the symlink that was checked into git for the annexed file
+and compare that with the sha256sum of the file that you rescued
+from the git history. Are they the same or different?
+"""]]
diff --git a/doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_2_6d73b11c55e7b2ed4003e1908558426d._comment b/doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_2_6d73b11c55e7b2ed4003e1908558426d._comment
new file mode 100644
index 0000000000..a71e3809c6
--- /dev/null
+++ b/doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_2_6d73b11c55e7b2ed4003e1908558426d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="comment 2"
+ date="2016-04-25T21:25:58Z"
+ content="""
+The checksum of a file is the same as the generated symlink name.  
+For a file which had the issue, `git annex log` appears empty.
+I used `git checkout [revision] [filename]` to get the old version of the file in the newly versioned repo, not sure if that would confuse `git annex log`.
+
+"""]]
diff --git a/doc/bugs/OSX_Assistant_will_not_automatically_drop.mdwn b/doc/bugs/OSX_Assistant_will_not_automatically_drop.mdwn
new file mode 100644
index 0000000000..7e43f089fb
--- /dev/null
+++ b/doc/bugs/OSX_Assistant_will_not_automatically_drop.mdwn
@@ -0,0 +1,172 @@
+### Please describe the problem.
+I cannot reproduce the archive behaviour explained in the screencast: git annex assistant archiving.
+
+### What steps will reproduce the problem?
+Install the OSX dmg.  Open the webapp. Make a client repo `~/annex` on the laptop and a full archive repo `/Volumes/Seagate/annex` on an external hard drive. Disregard the errors in the webapp. Restart daemon. Finish configuration of the archive repo as full archive.
+Put a test file in `~/annex`, watch it copy over in the webapp.  Verify copies with `git-annex whereis`.  
+**Use the GUI to move the test file to `~/annex/archive`.  The file does not turn into a symlink as expected.**  
+Run the command `git-annex drop --auto`.  the archived file is now replaced by a symlink.  `git annex whereis` verifies that the only copy is in the archive repo.
+Now move the symlink back to `~/annex`. The symlink is not replaced by the file.
+Restart the assistant using the webapp.  The symlink is replaced by the file.  
+Repeat above steps with the same effect.
+
+### What version of git-annex are you using? On what operating system?
+OSX 10.11.6 El Capitan  
+git-annex version: 6.20180409-gfb0780266  
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Testsuite  
+dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5  
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+
+Version 6.20180426 also produces the same result, however the webapp does not launch a browser window.
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+[2018-04-29 22:12:25.754703] main: starting assistant version 6.20180409-gfb0780266
+[2018-04-29 22:12:25.780218] Cronner: You should enable consistency checking to protect your data. 
+(scanning...) [2018-04-29 22:12:25.901493] Watcher: Performing startup scan
+(started...) 
+gpg: assuming signed data in '/var/folders/vt/jdjpydy51cb4c9743nvk2s7m0000gp/T/git-annex.tmpvDEpq7/info'
+gpg: Signature made Fri Apr 27 20:03:18 2018 EAT using DSA key ID 89C809CB
+gpg: /var/folders/vt/jdjpydy51cb4c9743nvk2s7m0000gp/T/git-annex-gpg.tmpBe1DxC/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2018-04-29 22:12:28.884998] Upgrader: An upgrade of git-annex is available.  (version 6.20180426)
+(recording state in git...)
+29/Apr/2018:22:13:13 +0300 [Error#yesod-core] there is no available git remote named "SeagateBlack" @(yesod-core-1.4.37-GCI7RasEcSMIU2vku0fHJ1:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:693:5)
+fatal: remote SeagateBlack already exists.
+29/Apr/2018:22:13:21 +0300 [Error#yesod-core] there is no available git remote named "SeagateBlack" @(yesod-core-1.4.37-GCI7RasEcSMIU2vku0fHJ1:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:693:5)
+fatal: remote SeagateBlack already exists.
+29/Apr/2018:22:13:24 +0300 [Error#yesod-core] there is no available git remote named "SeagateBlack" @(yesod-core-1.4.37-GCI7RasEcSMIU2vku0fHJ1:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:693:5)
+
+##restarted daemon via webapp##
+
+[2018-04-29 22:13:33.426914] main: starting assistant version 6.20180409-gfb0780266
+[2018-04-29 22:13:33.474857] Cronner: You should enable consistency checking to protect your data. 
+[2018-04-29 22:13:33.494878] TransferScanner: Syncing with SeagateBlack 
+(scanning...) [2018-04-29 22:13:33.646686] Watcher: Performing startup scan
+(started...) 
+warning: no common commits
+From /Volumes/SeagateBlack/annex
+ * [new branch]      git-annex  -> SeagateBlack/git-annex
+(merging SeagateBlack/git-annex into git-annex...)
+(recording state in git...)
+To /Volumes/SeagateBlack/annex
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      annex/direct/master -> synced/master
+gpg: assuming signed data in '/var/folders/vt/jdjpydy51cb4c9743nvk2s7m0000gp/T/git-annex.tmpIrPVZb/info'
+gpg: Signature made Fri Apr 27 20:03:18 2018 EAT using DSA key ID 89C809CB
+gpg: /var/folders/vt/jdjpydy51cb4c9743nvk2s7m0000gp/T/git-annex-gpg.tmptALBpe/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2018-04-29 22:13:38.218204] Upgrader: An upgrade of git-annex is available.  (version 6.20180426)
+[2018-04-29 22:14:33.641316] Pusher: Syncing with SeagateBlack 
+Everything up-to-date
+
+##restarted daemon via webapp##
+
+[2018-04-29 22:14:04.840648] main: starting assistant version 6.20180409-gfb0780266
+[2018-04-29 22:14:04.914622] Cronner: You should enable consistency checking to protect your data. 
+[2018-04-29 22:14:04.938372] TransferScanner: Syncing with SeagateBlack 
+(scanning...) [2018-04-29 22:14:05.129225] Watcher: Performing startup scan
+(recording state in git...)
+(started...) 
+To /Volumes/SeagateBlack/annex
+   96eb102..56b72d6  git-annex -> synced/git-annex
+gpg: assuming signed data in '/var/folders/vt/jdjpydy51cb4c9743nvk2s7m0000gp/T/git-annex.tmp6iw9TV/info'
+gpg: Signature made Fri Apr 27 20:03:18 2018 EAT using DSA key ID 89C809CB
+gpg: /var/folders/vt/jdjpydy51cb4c9743nvk2s7m0000gp/T/git-annex-gpg.tmpFugMM8/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2018-04-29 22:14:13.443848] Upgrader: An upgrade of git-annex is available.  (version 6.20180426)
+[2018-04-29 22:14:29.453797] Committer: Adding testing.txt
+add /Users/jhnichol/Desktop/annex/testing.txt ok
+[2018-04-29 22:14:29.458807] Committer: Committing changes to git
+(recording state in git...)
+[2018-04-29 22:14:29.508458] Pusher: Syncing with SeagateBlack 
+(recording state in git...)
+
+testing.txt
+          13 100%    0.00kB/s    0:00:00
+          13 100%    0.00kB/s    0:00:0(checksum...) 0 (xfer#1, to-check=0/1)
+
+sent 105 bytes  received 42 bytes  294.00 bytes/sec
+total size is 13  speedup is 0.09
+[2018-04-29 22:14:29.908335] Transferrer: Uploaded testing.txt
+To /Volumes/SeagateBlack/annex
+   56b72d6..97076de  git-annex -> synced/git-annex
+   f981f0e..903f744  annex/direct/master -> synced/master
+[2018-04-29 22:14:31.993469] Pusher: Syncing with SeagateBlack 
+(recording state in git...)
+To /Volumes/SeagateBlack/annex
+   97076de..351ae72  git-annex -> synced/git-annex
+[2018-04-29 22:14:37.442779] Committer: Adding testing.txt
+add /Users/jhnichol/Desktop/annex/archive/testing.txt ok
+[2018-04-29 22:14:37.451934] Committer: Committing changes to git
+(recording state in git...)
+[2018-04-29 22:14:37.506885] Pusher: Syncing with SeagateBlack 
+To /Volumes/SeagateBlack/annex
+   903f744..0ace0a4  annex/direct/master -> synced/master
+[2018-04-29 22:15:05.080814] Pusher: Syncing with SeagateBlack 
+To /Volumes/SeagateBlack/annex
+   351ae72..acc6f66  git-annex -> synced/git-annex
+[2018-04-29 22:15:07.643433] Committer: Committing changes to git
+(recording state in git...)
+[2018-04-29 22:15:07.716942] Pusher: Syncing with SeagateBlack 
+To /Volumes/SeagateBlack/annex
+   0ace0a4..216adc1  annex/direct/master -> synced/master
+
+##restarted daemon via webapp##
+
+[2018-04-29 22:15:12.721042] main: starting assistant version 6.20180409-gfb0780266
+[2018-04-29 22:15:12.780184] Cronner: You should enable consistency checking to protect your data. 
+[2018-04-29 22:15:12.802662] TransferScanner: Syncing with SeagateBlack 
+(scanning...) [2018-04-29 22:15:12.995192] Watcher: Performing startup scan
+Everything up-to-date
+(started...) 
+[2018-04-29 22:15:13.807031] Committer: Committing changes to git
+(recording state in git...)
+
+SHA256E-s13--091dfb50686a31a1137099832271eb582fbb745aeca5c0c8153ffc9acc7cd0fe.txt
+          13 100%    0.00kB/s    0:00:00
+          13 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/1)
+
+sent 175 bytes  received 42 bytes  434.00 bytes/sec
+total size is 13  speedup is 0.06
+(checksum...) [2018-04-29 22:15:13.980745] Transferrer: Downloaded testing.txt
+[2018-04-29 22:15:14.805402] Pusher: Syncing with SeagateBlack 
+(recording state in git...)
+To /Volumes/SeagateBlack/annex
+   acc6f66..f62818b  git-annex -> synced/git-annex
+   216adc1..bebd3d1  annex/direct/master -> synced/master
+[2018-04-29 22:15:15.384765] Committer: Adding testing.txt
+add /Users/jhnichol/Desktop/annex/testing.txt ok
+[2018-04-29 22:15:15.447495] Committer: Committing changes to git
+(recording state in git...)
+gpg: assuming signed data in '/var/folders/vt/jdjpydy51cb4c9743nvk2s7m0000gp/T/git-annex.tmpxY52C5/info'
+gpg: Signature made Fri Apr 27 20:03:18 2018 EAT using DSA key ID 89C809CB
+gpg: /var/folders/vt/jdjpydy51cb4c9743nvk2s7m0000gp/T/git-annex-gpg.tmpqPe64c/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2018-04-29 22:15:15.908187] Upgrader: An upgrade of git-annex is available.  (version 6.20180426)
+[2018-04-29 22:15:16.983499] Pusher: Syncing with SeagateBlack 
+Everything up-to-date
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I have not used it before, but I'm determined to make it work!  I'm nomadic and archive my pictures/videos/files and therefore this software must be perfect for me!
diff --git a/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_1_9a3a594f983048a9035f385101b394cf._comment b/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_1_9a3a594f983048a9035f385101b394cf._comment
new file mode 100644
index 0000000000..2f32bb5225
--- /dev/null
+++ b/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_1_9a3a594f983048a9035f385101b394cf._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-05-04T15:58:59Z"
+ content="""
+Hmmm. I am testing on macOS 10.12.6 with git-annex 6.20180409-gfb0780266 installed from dmg in /Applications
+
+The webapp launch behavior seems a bit odd. If I launch from the command-line `git-annex webapp` from my `/Users/Shared/a1` directory, then a webpage loads (for me in Chrome) and no assistant daemons are started, or at least I can't find any with `ps aux`. If I add files to `/Users/Shared/a1` the assistant sees them, but it doesn't transfer to my backup repo at `/Users/Shared/a3`. It seems to only see files from the repo I started git-annex webapp from. Is this the intended behavior Joey?
+
+I have three repos listed at `~/.config/git-annex/autostart`. If I run `git-annex assistant --autostart` from one of my repo directories, then an assistant daemon is started for each repo, I can verify that with `ps aux | grep \"git-annex assistant --startdelay\"` which lists one assistant process per repository (3 total). If I start the assistants this way, they seem to stick around. Then, I can follow the mentioned archiving video and successfully sync/archive as shown.
+
+I have these errors in `system.log`: `bumblebee git-annex[766]: no path for address 0x107d40000`, I don't have anything interesting in any of my daemon.log files. I can't find any other interesting system logs.
+
+—Andrew
+
+
+
+
+"""]]
diff --git a/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_2_7901e1211ab86429ef8bd95c72ed89f5._comment b/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_2_7901e1211ab86429ef8bd95c72ed89f5._comment
new file mode 100644
index 0000000000..057e3c6b19
--- /dev/null
+++ b/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_2_7901e1211ab86429ef8bd95c72ed89f5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="thoughts?"
+ date="2018-05-20T17:41:28Z"
+ content="""
+Any thoughts Joey? I am happy to troubleshoot this further, but I am not really sure what to test. I do have git-annex building from source on a mac, but I don't have any experience with Haskell, so don't really know what I could be checking.
+
+Thanks. Andrew
+"""]]
diff --git a/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_3_1ba89b95a028ba4a84b22dfd983049fd._comment b/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_3_1ba89b95a028ba4a84b22dfd983049fd._comment
new file mode 100644
index 0000000000..21b93d0419
--- /dev/null
+++ b/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_3_1ba89b95a028ba4a84b22dfd983049fd._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="jhnichol@cce81d2a480707652a3340ea2f24b3dc4b1f808c"
+ nickname="jhnichol"
+ avatar="http://cdn.libravatar.org/avatar/2d05fd7e681bf4838bba8bab538ac65d"
+ subject="comment 3"
+ date="2018-05-24T19:28:27Z"
+ content="""
+> Andrew:
+> \" I have three repos listed at `~/.config/git-annex/autostart`. If I run `git-annex assistant --autostart` from one of my repo directories, then an assistant daemon is started for each repo, I can verify that with `ps aux | grep \"git-annex assistant --startdelay\"` which lists one assistant process per repository (3 total). If I start the assistants this way, they seem to stick around. Then, I can follow the mentioned archiving video and successfully sync/archive as shown. \"
+
+I have only one repo listed at `~/.config/git-annex/autostart` which is my laptop. The other repo was created with the webapp on a USB drive; it is bare and will not allow me to start an assistant on it.  Again, I cannot successfully sync/archive as shown in the archiving video.
+
+I tried using `git-annex version: 6.20180509-gd801a3318` but no help.
+
+FYI, I also noticed that clicking the .app now successfully opens the webapp again.
+"""]]
diff --git a/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_4_704ef9c0ed78a00030f7d4d151ecbe5b._comment b/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_4_704ef9c0ed78a00030f7d4d151ecbe5b._comment
new file mode 100644
index 0000000000..5e4ff10197
--- /dev/null
+++ b/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_4_704ef9c0ed78a00030f7d4d151ecbe5b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 4"
+ date="2018-05-30T15:24:47Z"
+ content="""
+So [bare repositories](https://git-annex.branchable.com/bare_repositories/) should work fine with Assistant.
+
+You said `it is bare and will not allow me to start an assistant on it`. Do you get an error message from the webapp?
+
+What happens if you manually add the path to your bare USB drive repo to the `~/.config/git-annex/autostart` file, then run `git-annex assistant --autostart`? Then is assistant running on it?
+"""]]
diff --git a/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_5_47aa5de003b409d3d2a4c58a0f08a14a._comment b/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_5_47aa5de003b409d3d2a4c58a0f08a14a._comment
new file mode 100644
index 0000000000..722d92dd39
--- /dev/null
+++ b/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_5_47aa5de003b409d3d2a4c58a0f08a14a._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="jhnichol@cce81d2a480707652a3340ea2f24b3dc4b1f808c"
+ nickname="jhnichol"
+ avatar="http://cdn.libravatar.org/avatar/2d05fd7e681bf4838bba8bab538ac65d"
+ subject="comment 5"
+ date="2018-05-30T17:36:30Z"
+ content="""
+I started over, making new repos with the webapp & version: 6.20180527-gc3064edac .
+I still get an error in the webapp when adding the USB repo .
+The USB repo `/Volumes/SeagateBlack/annex` was not in `~/.config/git-annex/autostart` , so I added it .
+I enabled debugging in the webapp, shutdown the webapp and assistants, and used the terminal:
+
+	JamesMac:annex jhnichol$ cd /Volumes/SeagateBlack/annex 
+	JamesMac:annex jhnichol$ git-annex assistant --autostart
+	git-annex: You cannot run this command in a bare repository.
+	JamesMac:annex jhnichol$ cd /Users/jhnichol/Desktop/annex 
+	JamesMac:annex jhnichol$ git-annex assistant --autostart
+	git-annex autostart in /Users/jhnichol/Desktop/annex
+	[2018-05-30 20:13:45.005716] call: /Applications/git-annex.app/Contents/MacOS/bundle/git-annex [\"assistant\",\"--stop\"]
+	[2018-05-30 20:13:45.064878] process done ExitSuccess
+	[2018-05-30 20:13:45.065006] call: /Applications/git-annex.app/Contents/MacOS/bundle/git-annex [\"assistant\",\"--startdelay=5s\"]
+	[2018-05-30 20:13:45.117653] logging to .git/annex/daemon.log
+	[2018-05-30 20:13:45.507796] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+	[2018-05-30 20:13:45.520686] process done ExitSuccess
+	[2018-05-30 20:13:45.520806] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+	[2018-05-30 20:13:45.526297] process done ExitSuccess
+	[2018-05-30 20:13:45.526857] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..2f0d4e1b6fe058a5cc899012ef99870cd2877d2c\",\"--pretty=%H\",\"-n1\"]
+	[2018-05-30 20:13:45.537446] process done ExitSuccess
+	[2018-05-30 20:13:45.537572] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..31d29d92a8a48146cdf9dd4517f5a034daf4a467\",\"--pretty=%H\",\"-n1\"]
+	[2018-05-30 20:13:45.543984] process done ExitSuccess
+	[2018-05-30 20:13:45.544626] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
+	[2018-05-30 20:13:45.546186] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+	[2018-05-30 20:13:45.550793] read: git [\"config\",\"--null\",\"--list\"]
+	[2018-05-30 20:13:45.556288] process done ExitSuccess
+	[2018-05-30 20:13:45.557233] logging to .git/annex/daemon.log
+	[2018-05-30 20:13:45.565149] process done ExitSuccess
+	ok
+	git-annex autostart in /Volumes/SeagateBlack/annex 
+	failed
+
+so you see I got the \"You cannot run this command in a bare repository\" error from the assistant.
+Also, the assistant for the USB drive just fails with no error details.
+
+Thank you so much for your comments! I feel so close to having working software!
+"""]]
diff --git a/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_6_69781b2f00afe6150bc5997335b8af90._comment b/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_6_69781b2f00afe6150bc5997335b8af90._comment
new file mode 100644
index 0000000000..88d00cd336
--- /dev/null
+++ b/doc/bugs/OSX_Assistant_will_not_automatically_drop/comment_6_69781b2f00afe6150bc5997335b8af90._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="bare remotes, workflow"
+ date="2018-05-31T12:50:55Z"
+ content="""
+Aaah.
+
+So although git-annex does support storing files in bare repositories it treats them in much the same way as git in general. Namely, they are meant to be added as remotes from other full repositories. Assistant is responsible for monitoring a working directory for changes and automatically committing and syncing those changes. Bare repositories don't actually need assistant monitoring them because they don't have a working directory where users are adding and removing files from.
+
+In your case, you want assistant monitoring `~/Desktop/annex` which it now is. If you then add `/Volumes/SeagateBlack/annex` as a remote to `~/Desktop/annex` then assistant, by watching just `~/Desktop/annex` will sync with all remotes whenever you add remove files in `~/Desktop/annex`.  I imagine you already have your USB drive correctly setup as a remote. Just run `git annex info` from your `~/Desktop/annex` directory to see what remotes it knows about.
+
+Once USB is a remote of `~/Desktop/annex`, then if you launch the webapp from your `~/Desktop/annex` directory,`git-annex webapp` you should actually see both `~/Desktop/annex` and `/Volumes/SeagateBlack/annex` listed. The webapp automatically lists all remotes your repo knows about.
+
+In terms of workflow, I am not actually sure that using a bare repo is what you want on your USB drive. I always setup normal full git repositories on USB drives (not bare repos). That way I can use Finder to actually browse out to the files on the USB drive, add files when I am on the go, copy files etc… If you use a bare repo, then the files won't actually be listed in a usable form. But, if you don't actually want to ever look at the files on your USB drive (from Finder) then using a bare remote on a USB drive has the advantage that you don't need assistant monitoring it, and is probably marginally faster in some extreme cases since there is no working tree to update.
+
+"""]]
diff --git a/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state.mdwn b/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state.mdwn
new file mode 100644
index 0000000000..c7231cd1b1
--- /dev/null
+++ b/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state.mdwn
@@ -0,0 +1,151 @@
+### Please describe the problem.
+Shortly after starting the assistant the local client repository is in an inconsistent state. Just using the cli works fine without destroying the repository.
+
+### What steps will reproduce the problem?
+- Working git annex repository
+
+- Start the Git-Annex Assistant
+> git annex assistant
+
+- Wait a short time and then check the repository state:
+> ➜  annex git:(master) ✗ gst
+> On branch master
+> error: Could not read ea63b58d1252e3432280cdce1282eb02035c926e
+> error: Could not read ea63b58d1252e3432280cdce1282eb02035c926e
+> fatal: Failed to traverse parents of commit 108fa97a989aeabff16738558e1aa636c836598b
+
+- refs/heads/synced/git-annex links to an unknown commit
+> ➜  .git git:(master) cat refs/heads/synced/git-annex
+> be8e6023fbb172b12cec8fdbaa8654194f71c4f5% 
+
+> git show be8e6023fbb172b12cec8fdbaa8654194f71c4f5
+> fatal: unable to read source tree (d2959525362dcadd4dbec96a8f18d80cc689a851)
+
+### What version of git-annex are you using? On what operating system?
+- git-annex version: 5.20150508-gf71c23f
+- Mac OSX 10.10.2
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+[2015-05-15 07:06:32 CEST] main: starting assistant version 5.20150508-gf71c23f
+[2015-05-15 07:06:32 CEST] Cronner: Consistency check in progress
+fsck 2015-05-01 07.56.02.jpg (checksum…)
+ok
+fsck 2015-05-01 09.55.58.jpg (checksum…)
+ok
+fsck 2015-05-14 12.38.24.jpg (checksum…)
+ok
+fsck 2015-05-14 12.39.30.jpg (checksum…)
+ok
+fsck 2015-05-14 12.40.49.jpg (checksum…)
+ok
+fsck 2015-05-14 12.40.53.jpg (checksum…)
+ok
+fsck 2015-05-14 12.43.42.jpg (checksum…)
+ok
+fsck 2015-05-14 12.44.16.jpg (checksum…)
+ok
+fsck 2015-05-14 12.45.11.jpg (checksum…)
+ok
+(recording state in git…)
+[2015-05-15 07:06:39 CEST] TransferScanner: Syncing with nas 
+(scanning…) [2015-05-15 07:06:39 CEST] Watcher: Performing startup scan
+gpg: Unterschrift vom Fr  8 Mai 22:10:28 2015 CEST mittels DSA-Schlüssel ID 89C809CB
+gpg: Unterschrift kann nicht geprüft werden: Öffentlicher Schlüssel nicht gefunden
+(started…) 
+[2015-05-15 07:06:41 CEST] Committer: Committing changes to git
+(recording state in git…)
+[2015-05-15 07:06:41 CEST] Pusher: Syncing with nas 
+
+
+0%            0.0 B/s 0s
+2%          32.0KB/s 47s
+...
+90%         467.6KB/s 0s
+                        
+[2015-05-15 07:06:47 CEST] Transferrer: Uploaded 2015-05-1..38.24.jpg
+
+
+0%            0.0 B/s 0s
+1%          32.0KB/s 54s
+...
+91%         534.5KB/s 0s
+                        
+[2015-05-15 07:06:54 CEST] Transferrer: Uploaded 2015-05-1..45.11.jpg
+
+
+0%            0.0 B/s 0s
+2%        16.0KB/s 1m30s
+…
+90%         440.4KB/s 0s
+                        
+[2015-05-15 07:07:01 CEST] Transferrer: Uploaded 2015-05-1..44.16.jpg
+
+
+0%            0.0 B/s 0s
+1%        16.0KB/s 1m42s
+...
+91%         508.2KB/s 0s
+                        
+[2015-05-15 07:07:07 CEST] Transferrer: Uploaded 2015-05-1..43.42.jpg
+
+
+0%            0.0 B/s 0s
+1%        16.0KB/s 1m40s
+...
+91%         371.6KB/s 0s
+                        
+[2015-05-15 07:07:13 CEST] Transferrer: Uploaded 2015-05-1..40.53.jpg
+
+
+0%            0.0 B/s 0s
+1%          32.0KB/s 50s
+...
+91%         495.1KB/s 0s
+                        
+[2015-05-15 07:07:19 CEST] Transferrer: Uploaded 2015-05-1..40.49.jpg
+
+
+0%            0.0 B/s 0s
+1%          32.0KB/s 53s
+...
+92%         528.2KB/s 0s
+                        
+[2015-05-15 07:07:25 CEST] Transferrer: Uploaded 2015-05-1..39.30.jpg
+ssh: connect to host 1.2.3.43 port 22: Operation timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+fatal: ‚/Volumes/WD1500GB/annex‘ does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+ssh: connect to host 1.2.3.43 port 22: Operation timed out
+s(recording state in git…)
+fatal: ‚/Volumes/WD1500GB/annex‘ does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+ssh: connect to host 1.2.3.43 port 22: Operation timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+[2015-05-15 07:08:16 CEST] Cronner: Attempting to repair aether [here]
+Unpacking all pack files.
+ssh: connect to host 1.2.3.43 port 22: Operation timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+ssh: connect to host 1.2.3.36 port 22:sssssh: connect to host 1.2.3.43 port 22: Operation timed out
+fatal: early EOF
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_1_0dfd9eedccb48f1f3d7939677dc96446._comment b/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_1_0dfd9eedccb48f1f3d7939677dc96446._comment
new file mode 100644
index 0000000000..be48ca87fb
--- /dev/null
+++ b/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_1_0dfd9eedccb48f1f3d7939677dc96446._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="git annex repair --force"
+ date="2015-05-15T08:01:25Z"
+ content="""
+This command removed all history. It looks like no file was ever added.
+
+Any idea how I should handle this client repository? I could clone again from a backup. Is it possible to keep the annex UUID for a new clone?
+"""]]
diff --git a/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_2_5c5e7356cae8ddf8d2c8964fb69000f5._comment b/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_2_5c5e7356cae8ddf8d2c8964fb69000f5._comment
new file mode 100644
index 0000000000..5d39e8ac22
--- /dev/null
+++ b/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_2_5c5e7356cae8ddf8d2c8964fb69000f5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="Disaster recovery"
+ date="2015-05-15T09:40:16Z"
+ content="""
+Ah, found it:
+
+https://git-annex.branchable.com/design/assistant/disaster_recovery/
+
+> As long as the git repository has at least one remote, another method is to clone the remote, sync from all other remotes, move over .git/config and .git/annex/objects, and tar up the old broken git repo and git annex add it
+"""]]
diff --git a/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_3_1e0841d71c33fd3919310f1711b6e0b4._comment b/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_3_1e0841d71c33fd3919310f1711b6e0b4._comment
new file mode 100644
index 0000000000..319b001f82
--- /dev/null
+++ b/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_3_1e0841d71c33fd3919310f1711b6e0b4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="A possible solution"
+ date="2015-05-19T11:03:22Z"
+ content="""
+While searching for the problem I found this:
+
+http://feeding.cloud.geek.nz/posts/error-while-running-git-gc/
+> git reflog expire --all --stale-fix
+
+I can't verify this because I nuked the broken repository after recreating it.
+"""]]
diff --git a/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_4_eb5b0f8259d861000510fcfd58f66617._comment b/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_4_eb5b0f8259d861000510fcfd58f66617._comment
new file mode 100644
index 0000000000..395c31b948
--- /dev/null
+++ b/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_4_eb5b0f8259d861000510fcfd58f66617._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="Once again"
+ date="2015-06-08T15:45:15Z"
+ content="""
+I was using the assistant on two machines in parallel and both git repositories got broken. Before that I was just using the command line tools and just one assistant. Today the history got inconsistent when firing up the second assistant.
+
+Repos in use:
+- client 1 with active assistant
+- client 2 with active assistant
+- Synology NAS with git-annex installed (armel-based)
+
+I could recover everything pretty fast by cloning again from the nas device. Copying the .git/config and moving over the .git/annex directory.
+
+I will send you the log-files via mail.
+"""]]
diff --git a/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_5_4343ee35e4091fc50268f9fc611f5148._comment b/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_5_4343ee35e4091fc50268f9fc611f5148._comment
new file mode 100644
index 0000000000..0ec1370819
--- /dev/null
+++ b/doc/bugs/OSX__58___Assistant_leaves_repo_in_inconsistent_state/comment_5_4343ee35e4091fc50268f9fc611f5148._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="How to debug?"
+ date="2015-07-25T18:10:08Z"
+ content="""
+I want to give the two assistants one more try with the newest version.
+
+But I want the assistant not to try a repair once a failure is detected. I want to check the state of the repository to get a clue what goes wrong.
+As I understood the code there is no configuration to prevent the repair. Am I wrong? If not I could try to introduce one if it makes sense.
+"""]]
diff --git a/doc/bugs/OSX__58___Pushed_changes_are_autocommited.mdwn b/doc/bugs/OSX__58___Pushed_changes_are_autocommited.mdwn
new file mode 100644
index 0000000000..5449ac1e78
--- /dev/null
+++ b/doc/bugs/OSX__58___Pushed_changes_are_autocommited.mdwn
@@ -0,0 +1,88 @@
+### Please describe the problem.
+
+When changes committed in external repos are automatically pushed to a repo residing on OSX via the assistant, the chanes are applied to the repo without the knowledge of the assistant running on the OSX machine or something like that, I can't really explain it.
+
+Example:
+
+If I save a change in a file on Linux, it gets auto-committed and pushed to the OSX machine by the assistant as expected. However, the OSX machine then commits a deletion and re-addition of the file in two separate commits.
+So whenever I save a change, I get a pattern like this:
+
+```
+150ec0dfc * git-annex in MB-<REDACTED>
+29fbe8c12 * git-annex in MB-<REDACTED>
+909a6f30b * git-annex in atemu@HEPHAISTOS:~/Documents
+```
+
+90 are my changes, 29 deletes the file I changed and 15 adds the same file back.  
+As I said, this happens to every change pushed to the OSX machine.
+
+This is especially problematic when merge conflicts arise as it *commits the addition of merge conflict markers*. If that wasn't enough, this is even more problematic when handling unlocked files as those are just plain text files containing paths.
+
+This has often left me with files like these before I gave up and turned off auto-sync:
+
+```
+<<<<<<< HEAD
+/annex/objects/SHA256E-s24532--ce9e93b9ee9f639c916edf5ae07ceb93100718ca039ee9cd2dc6d466074a1c79.org
+=======
+/annex/objects/SHA256E-s24569--f033d710717df25a0082a89266352b95acd6b0b6b170699d5895b335e5f8fcaa.org
+>>>>>>> refs/remotes/10.10.10.18_annex/master
+```
+
+Not fun.
+
+### What steps will reproduce the problem?
+
+1. Assistants running on Linux and OSX machines, syncing with each other
+2. Make a change on the Linux machine
+3. Observe OSX assistant commiting repo changes due to pushed sync
+
+### What version of git-annex are you using? On what operating system?
+
+NixOS Unstable:
+
+https://github.com/Atemu/nixpkgs/tree/637664ff05140d360077c109d9a5bdaf059a47fd
+
+```
+git-annex version: 8.20210127
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.27 DAV-1.3.4 feed-1.3.0.1 ghc-8.10.3 http-client-0.6.4.1 persistent-sqlite-2.11.0.0 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+```
+
+OSX 10.15.7:
+
+https://github.com/NixOS/nixpkgs/tree/a58a0b5098f0c2a389ee70eb69422a052982d990
+
+```
+git-annex version: 8.20210127
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.27 DAV-1.3.4 feed-1.3.0.1 ghc-8.10.3 http-client-0.6.4.1 persistent-sqlite-2.11.0.0 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+```
+
+### Please provide any additional information below.
+
+I use `annex.largefiles=mimeencoding=binary` and text file changes make up the bulk of my commits but the same happens with annexed files as I mentioned.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Annex yes, it's amazing; Assistant see frustration above.
+
diff --git a/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_1_ff7fc340c34297beb913e8cba5af052b._comment b/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_1_ff7fc340c34297beb913e8cba5af052b._comment
new file mode 100644
index 0000000000..46c452192f
--- /dev/null
+++ b/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_1_ff7fc340c34297beb913e8cba5af052b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-05-11T08:41:41Z"
+ content="""
+Do you have `receive.denyCurrentBranch` set to `warn` or `ignore` anywhere? I could imagine this may cause such problems.
+"""]]
diff --git a/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_2_fb72d7dc7b56c6166c557aa03b951eb1._comment b/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_2_fb72d7dc7b56c6166c557aa03b951eb1._comment
new file mode 100644
index 0000000000..db0cba7ab9
--- /dev/null
+++ b/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_2_fb72d7dc7b56c6166c557aa03b951eb1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 2"
+ date="2021-05-11T10:28:12Z"
+ content="""
+Like [[bugs/git_annex_sync_remove_all_recently_added_files/]], I can also reproduce this with `receive.denyCurrentBranch` set to `warn` or `ignore` and I get similar commit patters sometimes. I guess it's very racy.
+
+So yeah, don't set that config.
+"""]]
diff --git a/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_3_8420ed892366eb78a874eec793eaa38d._comment b/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_3_8420ed892366eb78a874eec793eaa38d._comment
new file mode 100644
index 0000000000..828283c37c
--- /dev/null
+++ b/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_3_8420ed892366eb78a874eec793eaa38d._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-05-12T15:26:00Z"
+ content="""
+I do not think you need to reach for receive.denyCurrentBranch
+to explain this behavior. The assistant runs git merge itself,
+and is watching for changes to the working tree at the same time. 
+So it can get notifications of changes, that are made by git merge,
+and commit them. 
+
+The result is that basically, any change that gets made to the work tree
+while the assistant is running, can end up being recorded in a git commit.
+Which is normally what you want and expect. In this case the change is
+a file being removed breifly before being replaced with a new version.
+Whether that is a bug is debatable, but it might be a good idea for the
+assistant to at least pause committing while it's running a git merge.
+
+The fact that it's committing files with merge conflict markers in them
+is certianly a bug. I do wonder if that might be due to annex.resolvemerge
+being configured to false; normally the assistant does not merge in a way
+that would result in merge conflict markers ever appearing in the working
+tree.
+"""]]
diff --git a/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_4_5def2bf7430c4cba0c6ed154e75c967b._comment b/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_4_5def2bf7430c4cba0c6ed154e75c967b._comment
new file mode 100644
index 0000000000..5cee82f7c1
--- /dev/null
+++ b/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_4_5def2bf7430c4cba0c6ed154e75c967b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 4"
+ date="2021-05-16T11:37:25Z"
+ content="""
+Neither of those options are set AFAICT.
+
+The assistant not trying to commit anything while it's waiting for git to do something else sound like a good idea to me aswell. Shouldn't such behaviour at least be caught by a lockfile though?
+
+Are you able to reproduce the assistant turining unlocked files into merge markers Joey?
+"""]]
diff --git a/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_5_72c7566677b4c2f212bddeca49262181._comment b/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_5_72c7566677b4c2f212bddeca49262181._comment
new file mode 100644
index 0000000000..230a6ac026
--- /dev/null
+++ b/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_5_72c7566677b4c2f212bddeca49262181._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 5"
+ date="2021-07-16T22:47:44Z"
+ content="""
+I just tested this again with 8.20210714 since the assistant got a few improvements but unfortunately this is still just as reproducible.
+
+I also tried setting delayadd since that works with smallfiles properly now but all that does is delay the re-adding of the file it \"deleted\" in the commit before which still happens instantly.
+"""]]
diff --git a/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_6_13ad56d86b5bdbaaacdad5b31347551c._comment b/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_6_13ad56d86b5bdbaaacdad5b31347551c._comment
new file mode 100644
index 0000000000..98b56d335f
--- /dev/null
+++ b/doc/bugs/OSX__58___Pushed_changes_are_autocommited/comment_6_13ad56d86b5bdbaaacdad5b31347551c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 6"
+ date="2022-07-22T23:47:19Z"
+ content="""
+Sadly, this is still an issue on the current master (e1de941b2c7a881ec690d7abafdd1e8915cee9a6).
+
+I tried using kqueue instead of FsEvents but that resulted in the same behaviour.
+
+If anybody needs an OSX machine for testing, https://github.com/kholia/OSX-KVM works well.
+"""]]
diff --git a/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass.mdwn b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass.mdwn
new file mode 100644
index 0000000000..bb76e96e52
--- /dev/null
+++ b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass.mdwn
@@ -0,0 +1,119 @@
+### Please describe the problem.
+
+git-annex assistant on Mac OSX 10.8.5 fails to download new repo files from SSH remote/rsync shared-encryption annex after initial startup.  The assistant does sync with the repo and create symlinks for new files, and file contents can manually be retrieved using 'git annex get $file' once the file is in the repository. However, assistant makes no subsequent attempt to download the new files until assistant is restarted.  Once restarted, assistant downloads all new files for which is previously only had symlinks.
+
+git-annex whereis $file does not indicate that the files represented as symlinks are located on the Mac OSX clients in question until after files are manually retrieved or assistant is retarted and files are automatically downloaded, replacing the symlinks.
+
+git-annex assistant on Mac OSX does not have problems uploading files to the remote as they are added.
+
+git-annex 5.20140517.4 on Ubuntu 12.04 behaves as expected and downloads new files (with content) properly as they are added to the repo.
+
+### What steps will reproduce the problem?
+
+(all using git-annex webapp)
+
+--create client repo on Mac OSX, direct mode (used two 10.8.5 machines)
+
+--create client repo on Ubuntu, direct mode (used several 12.04 VMs)
+
+--create repo (transfer mode) on VPS
+
+--create shared encryption repo (backup mode) on same VPS
+
+--add VPS transfer repo to each client (shared encryption repo appears and syncing is enabled for each client)
+
+--create file in Mac OSX annex - file gets distributed to VPS backup repo and each linux system. Symlink is created on 2nd Mac OS X machine.
+
+--create file in Ubuntu VM annex - file gets distributed to VPS backup repo and each linux system.  Symlink is created on both Mac OSX machines.
+
+
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 5.20140421 (installed using brew), Mac OSX 10.8.5
+
+I tested 5.20140613 (from brew) also and it appears to also not download new files automatically.
+
+
+
+### Please provide any additional information below.
+I've tested a few things I thought might be related.  Since restarting assistant seems to temporarily "fix" the problem, I thought there may be some SSH client caching problems... as in the existing connection not being reused properly.  However, I disabled annex.sshcaching as described elsewhere and that did not have any affect. 
+
+I've enabled XMPP and it only introduced more confusion as the XMPP messaging was not reliably consistent.
+
+daemon.log for Mac OS systems does not show the "Pusher" process getting initiated once new files are added to the repo if the assistant is currently running, however it is logged immediately after assistant is started if there are new files in the repo.  
+
+daemon.log for Ubuntu systems does contain the Pusher process event following the repo sync that takes place once the file has been added to the repo.
+
+
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+MACOSX:user$git-annex assistant --autostart
+
+daemon.log:
+
+[2014-06-25 11:52:04 CDT] main: starting assistant version 5.20140421
+[2014-06-25 11:52:09 CDT] TransferScanner: Syncing with serverrepo 
+
+Already up-to-date.
+(scanning...) [2014-06-25 11:52:09 CDT] Watcher: Performing startup scan
+
+Already up-to-date.
+(started...) 
+[2014-06-25 11:52:10 CDT] Committer: Committing changes to git
+(Recording state in git...)
+(gpg) 
+Already up-to-date.
+
+Already up-to-date.
+[2014-06-25 11:52:11 CDT] Pusher: Syncing with serverrepo 
+
+GPGHMACSHA1--3e18c6a4ee5aece84f4f00fc2e7fcb828d8fa7d8
+Everything up-to-date0.00kB/s    0:00:00
+Everything up-to-date4.56MB/s    0:00:00
+     8409197 100%    4.94MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 38 bytes  received 8411383 bytes  2403263.14 bytes/sec
+total size is 8409197  speedup is 1.00
+[2014-06-25 11:52:13 CDT] Transferrer: Downloaded 67-more-fromubuntu
+[2014-06-25 11:52:14 CDT] Committer: Adding 67-more-fromubuntu
+add /Users/user/computer_annex/67-more-fromubuntu ok
+[2014-06-25 11:52:14 CDT] Committer: Committing changes to git
+(Recording state in git...)
+[2014-06-25 11:52:20 CDT] Pusher: Syncing with serverrepo 
+(Recording state in git...)
+To ssh://user@git-annex-server.remotehost.net-user_.2Fhome.2Fuser.2Fserver_repo/home/user/server_repo/
+   7e375a8..1a64e4c  git-annex -> synced/git-annex
+[2014-06-25 11:52:36 CDT] RemoteControl: Syncing with serverrepo 
+From ssh://git-annex-server.remotehost.net-user_.2Fhome.2Fuser.2Fserver_repo/home/user/server_repo
+   1a64e4c..dee9f84  synced/git-annex -> serverrepo/synced/git-annex
+   d424057..989003e  synced/master -> serverrepo/synced/master
+(merging serverrepo/synced/git-annex into git-annex...)
+
+<<<File gets added to any other client annex, MAC OSX or Ubuntu>>>
+
+Updating d424057..989003e
+Fast-forward
+ 89-more-fromubuntu | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 89-more-fromubuntu
+[2014-06-25 11:58:42 CDT] RemoteControl: Syncing with serverrepo 
+From ssh://git-annex-server.remotehost.net-user_.2Fhome.2Fuser.2Fserver_repo/home/user/server_repo
+   dee9f84..b24c8bf  synced/git-annex -> serverrepo/synced/git-annex
+(merging serverrepo/synced/git-annex into git-annex...)
+[2014-06-25 11:58:47 CDT] RemoteControl: Syncing with serverrepo 
+From ssh://git-annex-server.remotehost.net-user_.2Fhome.2Fuser.2Fserver_repo/home/user/server_repo
+   b24c8bf..6488b45  synced/git-annex -> serverrepo/synced/git-annex
+(merging serverrepo/synced/git-annex into git-annex...)
+[2014-06-25 11:58:56 CDT] RemoteControl: Syncing with serverrepo 
+From ssh://git-annex-server.remotehost.net-user_.2Fhome.2Fuser.2Fserver_repo/home/user/server_repo
+   6488b45..c73c180  synced/git-annex -> serverrepo/synced/git-annex
+(merging serverrepo/synced/git-annex into git-annex...)
+
+
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_10_3feba4ba84efb77bd4f8f46b6b4600f1._comment b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_10_3feba4ba84efb77bd4f8f46b6b4600f1._comment
new file mode 100644
index 0000000000..37aa47c37e
--- /dev/null
+++ b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_10_3feba4ba84efb77bd4f8f46b6b4600f1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawncukUQl56TwiBJb7dIyAqP1YirNg_wjR4"
+ nickname="Matthew"
+ subject="Actions -> Sync Now in webapp does properly download new files"
+ date="2014-07-17T13:50:06Z"
+ content="""
+confirmed - your understanding is correct
+"""]]
diff --git a/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_1_a33fcd088e419d8e6c459e42f21f8bbe._comment b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_1_a33fcd088e419d8e6c459e42f21f8bbe._comment
new file mode 100644
index 0000000000..b78fd5aa07
--- /dev/null
+++ b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_1_a33fcd088e419d8e6c459e42f21f8bbe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnu1NjsjNS3m0OxiYLKO-5SKNpSERxpi6k"
+ nickname="Matthew"
+ subject="comment 1"
+ date="2014-07-09T13:56:31Z"
+ content="""
+\"workaround\" is just a cron job that runs 'git annex sync --content' every N minutes... 
+
+Is there any possible configuration error I've made that would cause the OSX clients to behave differently than the linux clients despite ostensibly being set up identically??
+"""]]
diff --git a/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_2_47196f7e781137751ebd1a1d7083838a._comment b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_2_47196f7e781137751ebd1a1d7083838a._comment
new file mode 100644
index 0000000000..ee5ad138e5
--- /dev/null
+++ b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_2_47196f7e781137751ebd1a1d7083838a._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 2"
+ date="2014-07-10T19:19:36Z"
+ content="""
+Could you please go into some more detail about these two things:
+
+> --create repo (transfer mode) on VPS
+> 
+> --create shared encryption repo (backup mode) on same VPS
+
+It's not clear to me what kind of repositories these are. Are they bare git repositories? What version of git-annex, if any, is installed on that VPS?
+
+> git-annex whereis $file does not indicate that the files represented as symlinks are located on the Mac OSX clients in question until after files are manually retrieved
+
+Well, I'd not expect whereis to say that the file is in a repository until it's retrieved into that repository. However, does whereis, on the OSX clients, ever say that the file has reached one of the repos on the VPS?
+"""]]
diff --git a/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_3_672d98ee06e051430f8e01faa93bb4cf._comment b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_3_672d98ee06e051430f8e01faa93bb4cf._comment
new file mode 100644
index 0000000000..e26492dd7c
--- /dev/null
+++ b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_3_672d98ee06e051430f8e01faa93bb4cf._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawncukUQl56TwiBJb7dIyAqP1YirNg_wjR4"
+ nickname="Matthew"
+ subject="comment 3"
+ date="2014-07-11T17:06:43Z"
+ content="""
+I created an local repository on each of 2 OS X (10.8.5) systems running git-annex version 5.20140421, and each of 2 Ubuntu 12.04 systems running version 5.20140517.4
+
+I then created a remote SSH repository by selecting \"Make an unencrypted git repository on the server\" - this repo is in \"transfer\" mode.
+
+On the 2nd OSX client, I added a remote SSH repository, providing the same host and path information and elected to \"combine\" my local repo with the remote repo so that files would stay in sync.
+
+I did the same on each of the linux clients.
+
+git-annex indicates that local repos on each machine are in direct mode and show all expected semi trusted repos: web, SSH remote, other clients that have combined with the SSH remote.
+
+git-annex indicates that the SSH remote repo is in indirect mode
+
+git indicates that all repos are in bare mode
+
+git-annex version 5.20140412ubuntu1 is installed on the VPS, and 'git-annex shell notify changes' processes are running.
+
+Agreed on the behavior of git-annex whereis… just pointing out that the location info is accurate.
+
+The 2nd, encrypted repo may have no bearing at all because even when I remove it, the client behavior on OSX doesn't change.
+
+Thanks for taking the time to consider this!
+"""]]
diff --git a/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_4_06fb3031b838cd443326f4ecd689b600._comment b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_4_06fb3031b838cd443326f4ecd689b600._comment
new file mode 100644
index 0000000000..0f77607a04
--- /dev/null
+++ b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_4_06fb3031b838cd443326f4ecd689b600._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawncukUQl56TwiBJb7dIyAqP1YirNg_wjR4"
+ nickname="Matthew"
+ subject="comment 4"
+ date="2014-07-11T17:11:41Z"
+ content="""
+I should add that in the web app on OSX, the behavior is consistent;  syncing the local repository on an OSX client create a symlink (if that hasn't already been done in the background).  resyncing \"here\" (local client) doesn't download the file.  syncing the remote SSH repo, however does download the file content (as does git-annex sync --content)
+
+thanks! 
+"""]]
diff --git a/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_5_42d447400c15acf6ca031d165b2c781c._comment b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_5_42d447400c15acf6ca031d165b2c781c._comment
new file mode 100644
index 0000000000..04a5de75c8
--- /dev/null
+++ b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_5_42d447400c15acf6ca031d165b2c781c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawncukUQl56TwiBJb7dIyAqP1YirNg_wjR4"
+ nickname="Matthew"
+ subject="comment 5"
+ date="2014-07-11T18:10:06Z"
+ content="""
+Sorry to miss this previously, but, yes, whereis does indicate that it has made it to both of the remotes.
+"""]]
diff --git a/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_6_edd7d5d5c761ff665840f0ef7bea50c9._comment b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_6_edd7d5d5c761ff665840f0ef7bea50c9._comment
new file mode 100644
index 0000000000..9b28909867
--- /dev/null
+++ b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_6_edd7d5d5c761ff665840f0ef7bea50c9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 6"
+ date="2014-07-16T20:51:36Z"
+ content="""
+5.20140421 happens to be the very first version of git-annex to support notifychanges. I forget what bugs that first attempt may have had. Have you tried upgrading the macs to a newer version?
+
+
+"""]]
diff --git a/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_7_18e5334ab89efcf89ba8847436d55065._comment b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_7_18e5334ab89efcf89ba8847436d55065._comment
new file mode 100644
index 0000000000..197fca67af
--- /dev/null
+++ b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_7_18e5334ab89efcf89ba8847436d55065._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawncukUQl56TwiBJb7dIyAqP1YirNg_wjR4"
+ nickname="Matthew"
+ subject="comment 7"
+ date="2014-07-16T21:23:00Z"
+ content="""
+git-annex version: 5.20140613 also behaves the same way, however it generates a new log message during the sync attempt:
+
+Automatic merge went well; stopped before committing as requested
+
+
+
+"""]]
diff --git a/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_8_35b2bbdc24a7bd686527cd1839dee7d0._comment b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_8_35b2bbdc24a7bd686527cd1839dee7d0._comment
new file mode 100644
index 0000000000..f551fe6275
--- /dev/null
+++ b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_8_35b2bbdc24a7bd686527cd1839dee7d0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 8"
+ date="2014-07-16T22:23:50Z"
+ content="""
+Hmm, it looks to me like the transfer scan may not be getting run after the git branches get pulled. I would expect to see \"starting scan of\" in the debug log when it does that scan. Do you see that in the log?
+
+AIUI, when you click on Actions -> Sync Now in the webapp for the repository that contains the content, it gets downloaded right? That does the same scan that should be automatically run after a branch is pulled.
+"""]]
diff --git a/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_9_a771c6b453e6a4b3895dd69a53093440._comment b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_9_a771c6b453e6a4b3895dd69a53093440._comment
new file mode 100644
index 0000000000..bf57b46be3
--- /dev/null
+++ b/doc/bugs/OSX_assistant_fails_to_download_new_file_after_initial_pass/comment_9_a771c6b453e6a4b3895dd69a53093440._comment
@@ -0,0 +1,246 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawncukUQl56TwiBJb7dIyAqP1YirNg_wjR4"
+ nickname="Matthew"
+ subject="comment 9"
+ date="2014-07-17T01:58:29Z"
+ content="""
+Hi Joey,
+
+Thanks for taking the time to follow up on this - I sincerely appreciate it!
+
+Only immediately after I start the assistant does the \"starting scan of\" message get logged:
+
+[2014-07-16 20:38:07 CDT] TransferScanner: starting scan of [Remote { name =\"hostrepo\" }]
+
+and, at that point, new files are downloaded.
+
+If the assistant has been running for a while, I then create a new file in an annex on another machine, and the OS X assistant has synced and then created a symlink for new files, the following log is generated (NOTE the groovy scroodled first line if it's at all of interest...):
+
+
+[2014-07-16 20:30:[312 0C1D4T-] 0c7a-ll1:6  g2i0t: 3[0\":--3g1i tC-DdTi]r =R/eUmsoetresC/omnhtirlotly:/ sShYiNnCiIeNrG_ asnsnhe:x///.mgaitte\"o,@\"g-i-tw-oarnkn-etxr-egeo=t/aU.sienrfsr/omnhtiiletrys/.snheitn-imeart_eaon_ngeoxt\"a,_\"r-ecp\"o,/\"~c/ogroet.ab_arreep=of/a
+lse\",\"fetch\",\"hostrepo\"]
+
+[2014-07-16 20:30:31 CDT] RemoteControl: Syncing with hostrepo 
+From ssh://git-annex-host.vpshost.net-someuser_host_repo/~/host_repo
+   fdd1eff..e1057e0  synced/git-annex -> hostrepo/synced/git-annex
+   fa3cfb0..e4ba411  synced/master -> hostrepo/synced/master
+
+[2014-07-16 20:30:32 CDT] RemoteControl: DONESYNCING ssh://someuser@git-annex-host.vpshost.net-someuser_host_repo/~/host_repo/ 1
+
+[2014-07-16 20:30:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+
+[2014-07-16 20:30:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:30:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..fdd1effb8d2b8073e94725874e16056d6557f199\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..bfef6b84186d59431377343ab968e255db8c76fa\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..e1057e037f03ba804f021c8c39073b2efd1fad08\",\"--oneline\",\"-n1\"]
+(merging hostrepo/synced/git-annex into git-annex...)
+
+[2014-07-16 20:30:32 CDT] feed: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+
+[2014-07-16 20:30:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"e1057e037f03ba804f021c8c39073b2efd1fad08\"]
+
+[2014-07-16 20:30:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"e1057e037f03ba804f021c8c39073b2efd1fad08..refs/heads/git-annex\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:32 CDT] call: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-ref\",\"refs/heads/git-annex\",\"e1057e037f03ba804f021c8c39073b2efd1fad08\"]
+
+[2014-07-16 20:30:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+
+[2014-07-16 20:30:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"HEAD\"]
+
+[2014-07-16 20:30:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+
+[2014-07-16 20:30:32 CDT] Merger: merging refs/remotes/hostrepo/synced/master into refs/heads/annex/direct/master
+
+[2014-07-16 20:30:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/annex/direct/master\"]
+
+[2014-07-16 20:30:32 CDT] call: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex/.git/annex/merge/\",\"-c\",\"core.bare=false\",\"merge\",\"--no-edit\",\"refs/remotes/hostrepo/synced/master\"]
+
+Updating fa3cfb0..e4ba411
+Fast-forward
+ from-ubuntu | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 from-ubuntu
+
+[2014-07-16 20:30:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"diff-tree\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"-r\",\"fa3cfb01cc4493ed8a7cf84dff38bbba1fc042f9\",\"HEAD\"]
+
+[2014-07-16 20:30:33 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+
+[2014-07-16 20:30:33 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:30:33 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..e1057e037f03ba804f021c8c39073b2efd1fad08\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:33 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..bfef6b84186d59431377343ab968e255db8c76fa\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:33 CDT] feed: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+
+[2014-07-16 20:30:33 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:30:45 CDT][ cal2l0:1 4g-i0t7 -[16\" -2-0g:i3t0-:di4r5= /CUDsTe]r sR/emmhoitletCyo/nsthrionli:e rS_YaNnCnIeNxG/ .sgsiht:\"/,/\"m-a-tweoor@kg-ittr-eaen=n/eUxs-egrost/am.hiinlftryo/nsthiienrise.rn_eatn-nmeaxt\"e,o\"_-gco\"t,a\"_croerpeo./b~a/rgeo=tfaa_lrseep\"o,/\"
+fetch\",\"hostrepo\"]
+
+[2014-07-16 20:30:45 CDT] RemoteControl: Syncing with hostrepo 
+From ssh://git-annex-host.vpshost.net-someuser_host_repo/~/host_repo
+   e1057e0..d44a67a  synced/git-annex -> hostrepo/synced/git-annex
+
+[2014-07-16 20:30:47 CDT] RemoteControl: DONESYNCING ssh://someuser@git-annex-host.vpshost.net-someuser_host_repo/~/host_repo/ 1
+
+[2014-07-16 20:30:47 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+
+[2014-07-16 20:30:47 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:30:47 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..e1057e037f03ba804f021c8c39073b2efd1fad08\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:47 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..bfef6b84186d59431377343ab968e255db8c76fa\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:47 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..d44a67a5795c28e423a9ac018bead9dac793be5c\",\"--oneline\",\"-n1\"]
+(merging hostrepo/synced/git-annex into git-annex...)
+
+[2014-07-16 20:30:47 CDT] feed: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+
+[2014-07-16 20:30:47 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"d44a67a5795c28e423a9ac018bead9dac793be5c\"]
+
+[2014-07-16 20:30:47 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"d44a67a5795c28e423a9ac018bead9dac793be5c..refs/heads/git-annex\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:47 CDT] call: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-ref\",\"refs/heads/git-annex\",\"d44a67a5795c28e423a9ac018bead9dac793be5c\"]
+
+[2014-07-16 20:30:48 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+
+[2014-07-16 20:30:48 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:30:48 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..d44a67a5795c28e423a9ac018bead9dac793be5c\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:48 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..bfef6b84186d59431377343ab968e255db8c76fa\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:48 CDT] feed: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+
+[2014-07-16 20:30:48 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:30:51 CD[T]2 0c1a4l-l:0 7g-it1 6[ \"2-0-:g3i0t:-d5i1r =C/DUTs]e rRse/mmohtielCtoyn/tsrhoiln:i eSrY_NaCnInNeGx /s.sghi:t/\"/,m\"a-t-ewoo@rgki-tt-raenen=e/xU-sgeortsa/.mihniflrtoyn/tsiheirnsi.enre_ta-nmnaetxe\"o,_\"g-oct\"a,_\"rceoproe/.~b/agroet=af_arlespeo\"/,
+\"fetch\",\"hostrepo\"]
+
+[2014-07-16 20:30:51 CDT] RemoteControl: Syncing with hostrepo 
+From ssh://git-annex-host.vpshost.net-someuser_host_repo/~/host_repo
+   d44a67a..660d71a  synced/git-annex -> hostrepo/synced/git-annex
+
+[2014-07-16 20:30:51 CDT] RemoteControl: DONESYNCING ssh://someuser@git-annex-host.vpshost.net-someuser_host_repo/~/host_repo/ 1
+
+[2014-07-16 20:30:51 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+
+[2014-07-16 20:30:51 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:30:51 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..d44a67a5795c28e423a9ac018bead9dac793be5c\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:51 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..bfef6b84186d59431377343ab968e255db8c76fa\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:52 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..660d71ac55b47061c531e5c8fa2af7910f2e13aa\",\"--oneline\",\"-n1\"]
+(merging hostrepo/synced/git-annex into git-annex...)
+
+[2014-07-16 20:30:52 CDT] feed: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+
+[2014-07-16 20:30:52 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"660d71ac55b47061c531e5c8fa2af7910f2e13aa\"]
+
+[2014-07-16 20:30:52 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"660d71ac55b47061c531e5c8fa2af7910f2e13aa..refs/heads/git-annex\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:52 CDT] call: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-ref\",\"refs/heads/git-annex\",\"660d71ac55b47061c531e5c8fa2af7910f2e13aa\"]
+
+[2014-07-16 20:30:52 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+
+[2014-07-16 20:30:52 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:30:52 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..660d71ac55b47061c531e5c8fa2af7910f2e13aa\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:53 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..bfef6b84186d59431377343ab968e255db8c76fa\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:30:53 CDT] feed: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+
+[2014-07-16 20:30:53 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20[:32101:4-007-71 6 C2D0T:]3 1:ca0l7l :C DgTi]t  Re[m\"ot-e-Cognitrtol-: dSiYNrCI=NG/ Usssh:e/r/msa/tmeoh@giitl-tayn/nesx-hgoitan.iinefrron_tiaerns.nneetx-/m.agtieto\"_,g\"o-t-a_wroepro/k~/-gottar_reepeo/=
+/Users/someuser/local_ann[ex\"2,0\"1-4c-\",0\"7c-o1r6e .2b0a:r3e1=:fa0l7s eC\"D,T\"]f eRtecmho\"t,e\"Cgoonttarroelp:o \"]
+Syncing with hostrepo 
+From ssh://git-annex-host.vpshost.net-someuser_host_repo/~/host_repo
+   660d71a..273bc7f  synced/git-annex -> hostrepo/synced/git-annex
+
+[2014-07-16 20:31:09 CDT] RemoteControl: DONESYNCING ssh://someuser@git-annex-host.vpshost.net-someuser_host_repo/~/host_repo/ 1
+
+[2014-07-16 20:31:09 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-
+annex\"]
+
+[2014-07-16 20:31:09 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:31:09 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..660d71ac55b47061c531e5c8fa2af7910f2e13aa\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:31:09 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..bfef6b84186d59431377343ab968e255db8c76fa\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:31:09 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..273bc7f261a79539abcc237f1f0bbf5cd4f57add\",\"--oneline\",\"-n1\"]
+(merging hostrepo/synced/git-annex into git-annex...)
+
+[2014-07-16 20:31:09 CDT] feed: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+
+[2014-07-16 20:31:09 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"273bc7f261a79539abcc237f1f0bbf5cd4f57add\"]
+
+[2014-07-16 20:31:09 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"273bc7f261a79539abcc237f1f0bbf5cd4f57add..refs/heads/git-annex\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:31:09 CDT] call: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-ref\",\"refs/heads/git-annex\",\"273bc7f261a79539abcc237f1f0bbf5cd4f57add\"]
+
+[2014-07-16 20:31:10 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+
+[2014-07-16 20:31:10 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:31:10 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..273bc7f261a79539abcc237f1f0bbf5cd4f57add\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:31:10 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..bfef6b84186d59431377343ab968e255db8c76fa\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:31:10 CDT] feed: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+
+[2014-07-16 20:31:10 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:31:11 CDT] Watcher: directory deleted /Users/someuser/local_annex/local_annex-test
+
+[2014-07-16 20:31:11 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"ls-files\",\"--deleted\",\"-z\",\"--\",\"/Users/someuser/local_annex/local_annex-test\"]
+
+[2014-07-16 20:31[:1270 1C4D-T]0 7c-al1l6:  2g0i:t3 1[:\"-1-7g iCtD-Td]i rR=e/mUosteerCso/nmthriollt:y /SsYhNiCnIiNeGr _sasnhn:e/x//m.agtieto\"@,g\"i-t--waonrnke-xt-rgeoet=a/.Uisnefrrso/nmthiielrtsy./nsehti-nmiaetre_oa_ngnoetxa\"_r,e\"po-/c~\"/g,o\"tcao_rreep.ob/a
+re=false\",\"fetch\",\"g[ot2a0r1e4p-o0\"7]-
+16 20:31:17 CDT] RemoteControl: Syncing with hostrepo 
+From ssh://git-annex-host.vpshost.net-someuser_host_repo/~/host_repo
+   273bc7f..ce6dd68  synced/git-annex -> hostrepo/synced/git-annex
+
+[2014-07-16 20:31:18 CDT] RemoteControl: DONESYNCING ssh://someuser@git-annex-host.vpshost.net-someuser_host_repo/~/host_repo/ 1
+
+[2014-07-16 20:31:18 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+
+[2014-07-16 20:31:18 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:31:18 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..273bc7f261a79539abcc237f1f0bbf5cd4f57add\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:31:18 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..bfef6b84186d59431377343ab968e255db8c76fa\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:31:18 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..ce6dd68adec97bbf73f5da408c17511aca8840c5\",\"--oneline\",\"-n1\"]
+(merging hostrepo/synced/git-annex into git-annex...)
+
+[2014-07-16 20:31:18 CDT] feed: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+
+[2014-07-16 20:31:18 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"ce6dd68adec97bbf73f5da408c17511aca8840c5\"]
+
+[2014-07-16 20:31:18 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"ce6dd68adec97bbf73f5da408c17511aca8840c5..refs/heads/git-annex\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:31:18 CDT] call: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-ref\",\"refs/heads/git-annex\",\"ce6dd68adec97bbf73f5da408c17511aca8840c5\"]
+
+[2014-07-16 20:31:19 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+
+[2014-07-16 20:31:19 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:31:19 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..ce6dd68adec97bbf73f5da408c17511aca8840c5\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:31:19 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..bfef6b84186d59431377343ab968e255db8c76fa\",\"--oneline\",\"-n1\"]
+
+[2014-07-16 20:31:19 CDT] feed: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+
+[2014-07-16 20:31:19 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"refs/heads/git-annex\"]
+
+[2014-07-16 20:31:32 CDT] read: git [\"--git-dir=/Users/someuser/local_annex/.git\",\"--work-tree=/Users/someuser/local_annex\",\"-c\",\"core.bare=false\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+
+"""]]
diff --git a/doc/bugs/OSX_case_insensitive_filesystem.mdwn b/doc/bugs/OSX_case_insensitive_filesystem.mdwn
new file mode 100644
index 0000000000..cbdcea99ba
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem.mdwn
@@ -0,0 +1,56 @@
+### Please describe the problem.
+
+I copied one entire folder from my OSX local machine to a linux server.
+That folder was version controlled by git with git annex big files.
+On the linux machine the symlinks were broken.
+
+In particular, on my local machine, a file like:
+```
+file.vcf.gz.tbi -> ../../.git/annex/objects/J4/Pg/SHA256E-s572463--85b357849ddad75fc1138b27d6af62cf410876e329ff035f21a631bd53146224.gz.tbi/SHA256E-s572463--85b357849ddad75fc1138b27d6af62cf410876e329ff035f21a631bd53146224.gz.tbi
+```
+
+but the file resides in:
+
+```
+../../.git/annex/objects/j4/Pg/SHA256E-s572463--85b357849ddad75fc1138b27d6af62cf410876e329ff035f21a631bd53146224.gz.tbi/SHA256E-s572463--85b357849ddad75fc1138b27d6af62cf410876e329ff035f21a631bd53146224.gz.tbi
+```
+
+Notice the difference between `J4` and `j4`. This is not a problem on my OSX but becomes one on a linux machine.
+
+### What steps will reproduce the problem?
+
+on local machine:
+```rsync -aztv folder/ remote-machine:folder/```
+
+on server:
+```find . -type l -exec sh -c "file -b {} | grep -q ^broken" \; -print```
+listed every symlink as broken.
+
+### What version of git-annex are you using? On what operating system?
+
+git annex version 6.20160318
+
+my special remote is rsync.net
+
+OSX 10.11.4
+
+Not sure of which option were used when creating ther file system, but I suspect a HFS+ case insensitive.
+
+### Please provide any additional information below.
+
+I wanted to do this full copy because the transfer speed from the special remote was too slow.
+Since then I got decent speeds, and if I do `git annex get .` on the server, all is fine.
+So, my "problem" is solved but I'm still wondering why the discrepant folder capitalization.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sure, it works marvels :-) Also what I was trying to do is perhaps not by the book...
+
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_1_2e81165ac03e1d0566c81016e7728ee6._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_1_2e81165ac03e1d0566c81016e7728ee6._comment
new file mode 100644
index 0000000000..73070f777e
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_1_2e81165ac03e1d0566c81016e7728ee6._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-20T18:14:25Z"
+ content="""
+So the directory structure got lower cased when you copied it from OSX to
+linux. OSX remembered a lower-case name for the J4 directory, for example,
+and propigated that over to linux.
+
+Unfortunately, git-annex is stuck using mixed case hash directories for
+backwards compatability reasons. Changing to all lower-case hash
+directories would need every git-annex repo to be converted; would
+invalidate all old tags and branches and history in the repos, etc.
+This is discussed in [[design/new_repo_versions]].
+
+It's actually possible to make brand-new git-annex repos use all lower case
+hash directories today, by setting `git config annex.tune.objecthashlower true`
+before you run `git annex init` for the first time. 
+
+If you know you will need to move a repository between case-insensitive and
+case-sensitive filesystems, you could use that configuration. But that
+would be very forward looking, and instead users are just going to stumble
+over the mixed case directories from time to time.
+
+What I'd recommend you do is, move the repository back to OSX, and then
+make a clone of it on the linux system, and use `git annex move --all
+--from origin` to move all the annexed file contents over from OSX to
+linux. This method avoids the problem entirely.
+"""]]
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_2_4472d5db7a1cf7242077184912e32e17._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_2_4472d5db7a1cf7242077184912e32e17._comment
new file mode 100644
index 0000000000..4f841513eb
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_2_4472d5db7a1cf7242077184912e32e17._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="Case-sensitive on OSX"
+ date="2016-04-22T07:53:56Z"
+ content="""
+> What I'd recommend you do is, move the repository back to OSX, and then make a clone of it on the linux system
+
+Alternatively, create a case-sensitive FS on the Mac (just in a .dmg) and do the clone and copy to there, before rsync'ing to the remote Linux.
+"""]]
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_3_4be758c2b70c0aadfe4fc9ecff8e4522._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_3_4be758c2b70c0aadfe4fc9ecff8e4522._comment
new file mode 100644
index 0000000000..dc6b89f910
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_3_4be758c2b70c0aadfe4fc9ecff8e4522._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="objecthashlower"
+ date="2016-04-22T07:55:40Z"
+ content="""
+> It's actually possible to make brand-new git-annex repos use all lower case hash directories today, by setting git config annex.tune.objecthashlower true before you run git annex init for the first time.
+
+Am I interpreting this correctly, that this sets some attribute in the git-annex branch, so that clones of this repo will use the same annex layout?
+"""]]
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_4_0b0c95a902718dd4e0976bf4e2cf265b._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_4_0b0c95a902718dd4e0976bf4e2cf265b._comment
new file mode 100644
index 0000000000..29a53e04f3
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_4_0b0c95a902718dd4e0976bf4e2cf265b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="objecthashlower"
+ date="2016-04-22T07:58:33Z"
+ content="""
+... i.e., can I just `git config --global annex.tune.objecthashlower true` and it will Just Work, managing old repos correctly and using the feature for new repos? And remote machines will handle things correctly just as long as they run a modern enough `git-annex`?
+"""]]
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_5_2123944418123c3aaf187d34df5c11e0._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_5_2123944418123c3aaf187d34df5c11e0._comment
new file mode 100644
index 0000000000..e8c9c3efe0
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_5_2123944418123c3aaf187d34df5c11e0._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-04-22T18:41:22Z"
+ content="""
+You should not set annex.tune.* globally. Only set it when
+initializing a new git-annex repo for the first time. Clones of the repo will
+automatically inherit the tunings.
+
+See [[tuning]].
+"""]]
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_6_f82c803d725829722842c6d54e388719._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_6_f82c803d725829722842c6d54e388719._comment
new file mode 100644
index 0000000000..b65c0787b5
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_6_f82c803d725829722842c6d54e388719._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="comment 6"
+ date="2016-04-22T19:01:45Z"
+ content="""
+But it only checks the parameter at `annex init` time? What will the bad consequences be if it is set at other times?
+"""]]
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_7_45e0178ce9598d086f34a89701536eb5._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_7_45e0178ce9598d086f34a89701536eb5._comment
new file mode 100644
index 0000000000..e1a5fec74d
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_7_45e0178ce9598d086f34a89701536eb5._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="thowz"
+ subject="create symlinks inside .git/annex/objects"
+ date="2016-04-27T00:36:57Z"
+ content="""
+I also ran into this problem when copying a folder from Mac to Linux. Because the HFS+ filesystem is case-insensitive, directories that should be multiple directories are instead collapsed into one. For example, if there are four different files that are supposed to go into folders FG, fG, Fg, and fg, they will all end up in just one folder (whichever of the four was created first). But the symlinks will still point to different cases, so when everything gets moved to a case-sensitive filesystem, the symlinks break.
+
+I did a quick fix on the Linux side by making symlinks within .git/annex/objects to account for all the case variations (if folder FG exists and has more than one sub-folder, create symlinks  fG --> FG,  Fg --> FG,  fg --> FG).
+
+To do this for the whole set of directories and sub-directories, I made a perl script:
+
+    #!/usr/bin/perl 
+    
+    $dir=$ARGV[0];
+    $dir=substr($dir,2,2);
+    $link=$dir;
+    
+    if($dir =~ /[a-zA-Z]\d/){
+        substr($link,0,1) ^= \" \";
+        system(\"ln\", \"-s\", $dir, $link);
+    }
+    
+    if($dir =~ /\d[a-zA-Z]/){
+        substr($link,1,1) ^= \" \";
+        system(\"ln\", \"-s\", $dir, $link);
+    }
+    
+    if($dir =~ /[a-zA-Z]{2}/){
+        substr($link,0,1) ^= \" \";
+        system(\"ln\", \"-s\", $dir, $link);
+        substr($link,1,1) ^= \" \";
+        system(\"ln\", \"-s\", $dir, $link);
+        substr($link,0,1) ^= \" \";
+        system(\"ln\", \"-s\", $dir, $link);
+    }
+
+
+And ran it this way (with script made executable and placed in $PATH):
+
+    find .git/annex/objects -mindepth 1 -maxdepth 2 -links +3 -type d -execdir makelinks.pl {} \;
+
+It might be nice if git-annex-fsck could check whether a file was \"misfiled\" into the wrong directory due to case-insensitivity (before concluding that the file is missing). Although it also makes sense just to recommend cloning instead of copying when moving to a different filesystem (or remembering to set `annex.tune.objecthashlower true` when initiating a repo on a case-insensitive system).
+"""]]
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_8_3384bca070d84220efe166a398eed8a4._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_8_3384bca070d84220efe166a398eed8a4._comment
new file mode 100644
index 0000000000..0dfa655077
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_8_3384bca070d84220efe166a398eed8a4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="thowz"
+ subject="reinject files"
+ date="2016-05-04T00:52:38Z"
+ content="""
+Here's a way to put files into their proper case-sensitive folders using `git-annex reinject --known`:
+
+    # Enable write permissions on directories containing misfiled items
+    chmod u+w `find -xtype l -printf \"%l\n\" | sed -r \"s/.*(\.git\/annex\/objects\/)[^\/]*\/[^\/]*\/([^\/]*).*/\1*\/*\/\2/\" | sort | uniq`
+    
+    # Reinject those files into the annex
+    git-annex reinject --known `find -xtype l -printf \"%l\n\" | sed -r \"s/.*(\.git\/annex\/objects\/)[^\/]*\/[^\/]*\/([^\/]*.*)/\1*\/*\/\2/\" | sort | uniq`
+
+    # Remove empty directories (rmdir will fail on the non-empty directories)
+    find .git/annex/objects -mindepth 3 -maxdepth 3 -type d -exec rmdir {} \;
+    find .git/annex/objects -mindepth 2 -maxdepth 2 -type d -exec rmdir {} \;
+"""]]
diff --git a/doc/bugs/Offline_editing_in_Android_removes_files_and_creates_links.mdwn b/doc/bugs/Offline_editing_in_Android_removes_files_and_creates_links.mdwn
new file mode 100644
index 0000000000..9dd05d1d40
--- /dev/null
+++ b/doc/bugs/Offline_editing_in_Android_removes_files_and_creates_links.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+Two androids, A and B, and a computer, C. All running git annex assistant.
+If you edit a file on A while A is offline, when A is back online and reconnects, that file will disappear from C and, in B, it will be substituted by a link
+If you create a new file on A, that file will appear as a link in B and in C
+
+
+### What steps will reproduce the problem?
+- Have A, B, and C be connected sharing some repo. Create a file, file1. Let it propagate, so file1 is on A, B, C.
+
+- Take A offline (e.g., turn wifi off).
+
+- Edit file1 in A.
+
+- Create file2 in A.
+
+- (Let those files appear in the repo in A as in
+[2015-02-27 20:55:04 CET] Committer: Adding file1
+add file1 ok
+)
+
+- Turn the wifi of A on again.
+
+- Sync A from the webapp (clik on sync now)
+
+- In B (the other android) both file1 and file2 will contain just links, not the actual content of file1 and file2.
+
+- In the computer, file1 will have disappeared and file2 will be a link that points nowhere. (The link that file2 points too, as a string, are the contents of file2 in B). 
+
+
+
+### What version of git-annex are you using? On what operating system?
+Computer: 5.20141125 
+
+Androids: 5.20150226-g9c72d37 and 5.20150224-g9dca034
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/Offline_editing_in_Android_removes_files_and_creates_links/comment_1_a15eb9cd1a7bcdfa4b16459ef978a019._comment b/doc/bugs/Offline_editing_in_Android_removes_files_and_creates_links/comment_1_a15eb9cd1a7bcdfa4b16459ef978a019._comment
new file mode 100644
index 0000000000..236f7f07d3
--- /dev/null
+++ b/doc/bugs/Offline_editing_in_Android_removes_files_and_creates_links/comment_1_a15eb9cd1a7bcdfa4b16459ef978a019._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnbPKLjBONawBd74MKJZo05juCqdsP1jAU"
+ nickname="Ramon"
+ subject="comment 1"
+ date="2015-02-27T22:06:51Z"
+ content="""
+I can confirm the above using, in the computer 
+
+5.20150219-g52daae5 
+
+and 5.20150226-g9c72d37
+
+In the computer, files that were edited in the Android while offline, might not always disappear, but might reappear as content after first being shown as links that point nowhere. Or may remain as links that point nowhere.
+
+In the Androids files that contain links (instead of original content) continue containint the links for over 1 hour.
+
+Binary (e.g., PDFs) and plain text files do not always behave the same. Plain text files are more easily affected (whereas PDFs are back to what they should be sooner).
+
+"""]]
diff --git a/doc/bugs/Offline_editing_in_Android_removes_files_and_creates_links/comment_2_1c061621f0abe435182d763cd871f405._comment b/doc/bugs/Offline_editing_in_Android_removes_files_and_creates_links/comment_2_1c061621f0abe435182d763cd871f405._comment
new file mode 100644
index 0000000000..2408ccf266
--- /dev/null
+++ b/doc/bugs/Offline_editing_in_Android_removes_files_and_creates_links/comment_2_1c061621f0abe435182d763cd871f405._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-07T19:26:27Z"
+ content="""
+These links are what is put in place if the content of a file has not yet
+reached the local repository. On a more featureful system than Android,
+it's a broken symlink, which is nicer than a link target.
+
+So, unless the content has reached the local repository, this is normal.
+
+There's a feature request somewhere, which I am having trouble finding,
+that only files whose content is present be shown. I'm inclined to merge
+this bug with that.
+"""]]
diff --git a/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__.mdwn b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__.mdwn
new file mode 100644
index 0000000000..d7788fa93f
--- /dev/null
+++ b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__.mdwn
@@ -0,0 +1,93 @@
+### Please describe the problem.
+
+Following steps from http://git-annex.branchable.com/assistant/quickstart/ does not get past the first screen.
+
+### What steps will reproduce the problem?
+
+* On a nearly fresh Lubuntu system, nearly fresh account, Lubuntu session, run `git-annex` from the start menu.
+* Opens firefox, in `Create a git-annex repository` select my `~/Documents` folder, press `Make Repository`.
+
+* Expected: a new, different page opens.
+* Observed: the same page opens, only difference the path displayed is `/home/mylogin/Documents`. Pressing `Make Repository` again shows the same page again.
+
+I couldn't find any logs at the time. Now I see that they are in .git/annex/daemon.log but content from that time is already gone.
+
+### What version of git-annex are you using? On what operating system?
+
+A fresh Ubuntu 14.04 (actually Lubuntu but this shouldn't change anything, right ?), create a user, login.
+
+
+    LC_ALL=C apt-cache policy git-annex
+    git-annex:
+      Installed: 5.20140412ubuntu1
+      Candidate: 5.20140412ubuntu1
+      Version table:
+     *** 5.20140412ubuntu1 0
+            500 http://fr.archive.ubuntu.com/ubuntu/ trusty/universe i386 Packages
+            100 /var/lib/dpkg/status
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# No command line in bug occurrence.  This is the transcript of the workaround I found.
+# Actually, the PC was rebooted then I went command line.
+cd ~/Documents
+git status
+fatal: This operation must be run in a work tree
+# oh I see it's a bare repo
+git annex add .
+add (my file names... one line for each) ok
+(Recording state in git...)
+
+Now the webapp seems to run okay, I can see many pages, schedule checks, etc.
+
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+-> Ok but log shows only events after I manually dit git annex add.
+
+[2014-06-08 14:28:46 CEST] main: starting assistant version 5.20140412ubuntu1
+[2014-06-08 14:28:46 CEST] Cronner: You should enable consistency checking to protect your data.
+
+  dbus failed; falling back to mtab polling (ClientError {clientErrorMessage = "runClient: unable to determine DBUS address", clientErrorFatal = True})
+(scanning...) [2014-06-08 14:28:46 CEST] Watcher: Performing startup scan
+(started...) [2014-06-08 14:28:47 CEST] Committer: Adding (myfiles)
+
+add (my files...) ok
+[2014-06-08 14:32:51 CEST] Committer: Committing changes to git
+[2014-06-08 14:34:12 CEST] Committer: Committing changes to git
+[2014-06-08 14:34:13 CEST] Committer: Adding (myfiles)
+ok
+(Recording state in git...)
+(Recording state in git...)
+(Recording state in git...)
+(Recording state in git...)
+(Recording state in git...)
+add (myfile) ok
+add (myfile) [2014-06-08 14:34:13 CEST] Committer: Committing changes to git
+[2014-06-08 14:42:48 CEST] Cronner: Consistency check in progress
+fsck (myfile) (checksum...)
+ok
+
+# End of transcript or log.
+"""]]
+
+
+
+# Question:
+
+    cat /etc/xdg/autostart/git-annex.desktop
+    [Desktop Entry]
+    Type=Application
+    Version=1.0
+    Name=Git Annex Assistant
+    Comment=Autostart
+    Terminal=false
+    Exec=/usr/bin/git-annex assistant --autostart
+    Categories=
+
+Should there be a git-annex process whenever I log in even if I don't launch the webapp ?
+I can check that on next login.
+
+At the moment there is "git-annex webapp" and several child processes.
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_1_7508685b6f676c72e316642b80e40ee8._comment b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_1_7508685b6f676c72e316642b80e40ee8._comment
new file mode 100644
index 0000000000..e92e1b1007
--- /dev/null
+++ b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_1_7508685b6f676c72e316642b80e40ee8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-06-09T18:57:25Z"
+ content="""
+It sounds rather like the webapp is failing to create the repository. Although I would expect for it to show an error message in red beneath the repository path. OTOH, it also sounds like something (either the webapp or eg a manual git-annex run) set up a git-annex repository in ~/Documents.
+
+git-annex will be started automatically on login as long as `~/.config/git-annex/autostart` lists a repository to use. If that file exists and contains ~/Documents then we'll know that the webapp successfully set up the repository.
+"""]]
diff --git a/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_2_c4dd12ea578d1f07464e1b9d68ec96cf._comment b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_2_c4dd12ea578d1f07464e1b9d68ec96cf._comment
new file mode 100644
index 0000000000..a94d0c13a8
--- /dev/null
+++ b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_2_c4dd12ea578d1f07464e1b9d68ec96cf._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7eqCMh_B7mxE0tnchbr0JoYu11FUAFRY"
+ nickname="Stéphane"
+ subject="comment 2"
+ date="2014-06-09T20:34:55Z"
+ content="""
+> It sounds rather like the webapp is failing to create the repository. Although I would expect for it to show an error message in red beneath the repository path. 
+
+No message in red at any time.
+
+> OTOH, it also sounds like something (either the webapp or eg a manual git-annex run) set up a git-annex repository in ~/Documents.
+
+There was none before the webapp.
+After the webapp failure, there was one, but without any file.
+Only after I manually did git annex add, it looked \"unlocked\".
+
+> git-annex will be started automatically on login as long as ~/.config/git-annex/autostart lists a repository to use. If that file exists and contains ~/Documents then we'll know that the webapp successfully set up the repository.
+
+Can't check now, the machine is off.  Should check soon.  Thanks.
+"""]]
diff --git a/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_3_8687c1d1c44d88a8ac13208273565d6c._comment b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_3_8687c1d1c44d88a8ac13208273565d6c._comment
new file mode 100644
index 0000000000..4e497e240a
--- /dev/null
+++ b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_3_8687c1d1c44d88a8ac13208273565d6c._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7eqCMh_B7mxE0tnchbr0JoYu11FUAFRY"
+ nickname="Stéphane"
+ subject="No git-annex process."
+ date="2014-06-11T17:55:56Z"
+ content="""
+> It sounds rather like the webapp is failing to create the repository. Although I would expect for it to show an error message in red beneath the repository path. OTOH, it also sounds like something (either the webapp or eg a manual git-annex run) set up a git-annex repository in ~/Documents.
+
+As told before, there was definitely no git repository there before the webapp tried to create one.
+
+> git-annex will be started automatically on login as long as ~/.config/git-annex/autostart lists a repository to use. If that file exists and contains ~/Documents then we'll know that the webapp successfully set up the repository.
+
+There exists a ~/.config/git-annex/autostart containing one line, the correct /home/mylogin/Documents path to the folder.
+
+There is no process with git or annex in its name when user logs on his desktop session.
+
+
+    $ grep . $(dpkg -L git-annex | grep -i desktop)
+    /usr/share/applications/git-annex.desktop:[Desktop Entry]
+    /usr/share/applications/git-annex.desktop:Type=Application
+    /usr/share/applications/git-annex.desktop:Version=1.0
+    /usr/share/applications/git-annex.desktop:Name=Git Annex
+    /usr/share/applications/git-annex.desktop:Comment=Track and sync the files in your Git Annex
+    /usr/share/applications/git-annex.desktop:Terminal=false
+    /usr/share/applications/git-annex.desktop:Exec=/usr/bin/git-annex webapp
+    /usr/share/applications/git-annex.desktop:Icon=git-annex
+    /usr/share/applications/git-annex.desktop:Categories=Network;FileTransfer;
+    /etc/xdg/autostart/git-annex.desktop:[Desktop Entry]
+    /etc/xdg/autostart/git-annex.desktop:Type=Application
+    /etc/xdg/autostart/git-annex.desktop:Version=1.0
+    /etc/xdg/autostart/git-annex.desktop:Name=Git Annex Assistant
+    /etc/xdg/autostart/git-annex.desktop:Comment=Autostart
+    /etc/xdg/autostart/git-annex.desktop:Terminal=false
+    /etc/xdg/autostart/git-annex.desktop:Exec=/usr/bin/git-annex assistant --autostart
+    /etc/xdg/autostart/git-annex.desktop:Categories=
+
+"""]]
diff --git a/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_4_62be3dd4092b15cdf85cf9a231b2863a._comment b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_4_62be3dd4092b15cdf85cf9a231b2863a._comment
new file mode 100644
index 0000000000..748b57df5c
--- /dev/null
+++ b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_4_62be3dd4092b15cdf85cf9a231b2863a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 4"
+ date="2014-06-11T20:09:14Z"
+ content="""
+What happens if you run `git-annex assistant --autostart` ?
+"""]]
diff --git a/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_5_cca4905426a3e01da6e12be855c7a418._comment b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_5_cca4905426a3e01da6e12be855c7a418._comment
new file mode 100644
index 0000000000..50b6e5dfa1
--- /dev/null
+++ b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_5_cca4905426a3e01da6e12be855c7a418._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7eqCMh_B7mxE0tnchbr0JoYu11FUAFRY"
+ nickname="Stéphane"
+ subject="Can't reproduce"
+ date="2014-06-30T20:06:30Z"
+ content="""
+I tried to reproduce the bug on another account on the same machine, same LXDE environment.
+The bug did not occur again.
+
+> What happens if you run `git-annex assistant --autostart` ?
+
+To answer that, I went back to the first account. Just logging in.
+The following git-related processes are automatically launched without running `git-annex assistant --autostart`.
+
+     git-annex assistant --startdelay=5s
+     git --git-dir=/home/somelogin/Documents/.git --work-tree=/home/somelogin/Documents -c core.bare=false cat-file --batch
+     git --git-dir=/home/somelogin/Documents/.git --work-tree=/home/somelogin/Documents -c core.bare=false cat-file --batch
+     git --git-dir=/home/somelogin/Documents/.git --work-tree=/home/somelogin/Documents -c core.bare=false check-ignore -z --stdin --verbose --non-matching
+     git --git-dir=/home/somelogin/Documents/.git --work-tree=/home/somelogin/Documents -c core.bare=false check-attr -z --stdin annex.backend annex.numcopies --
+
+So, somehow things went back in order by themselves ?
+
+There were quite a bunch of software upgrades from Ubuntu, including `lxsession`.  Perhaps something was wrong in handling autostart desktop files ?
+
+Since things appear to work now, should we close the bug ?
+
+"""]]
diff --git a/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_6_ae2ca07169321c4a51b7e8e581fda5e2._comment b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_6_ae2ca07169321c4a51b7e8e581fda5e2._comment
new file mode 100644
index 0000000000..6349de01e2
--- /dev/null
+++ b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_6_ae2ca07169321c4a51b7e8e581fda5e2._comment
@@ -0,0 +1,72 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7eqCMh_B7mxE0tnchbr0JoYu11FUAFRY"
+ nickname="Stéphane"
+ subject="Cconfirmed it was a LXDE issue, now fixed."
+ date="2014-07-03T09:58:24Z"
+ content="""
+Since this is a little strange, I just looked again at the machine.
+Your software attracts archivist kind of git-annex user, so don't be surprise that I kept logs of the machine.
+
+Short answer: **confirmed it was a LXDE issue, now fixed**.
+
+## From what date has git-annex started to work ?
+
+	git log | grep Date:
+
+    (many other lines...)
+    Date:   Mon Jun 30 21:43:49 2014 +0200
+    Date:   Mon Jun 30 21:42:07 2014 +0200
+    Date:   Mon Jun 30 21:38:22 2014 +0200
+    Date:   Sun Jun 8 14:34:13 2014 +0200
+    Date:   Sun Jun 8 14:28:48 2014 +0200
+    Date:   Sat Jun 7 16:21:06 2014 +0200
+
+So I tried to enable it on June 7, reported bug on June 8.
+The the machine was used on a regular basis but git-annex assistant was ineffective.
+Then it started working as expected from June 30th.
+
+## Any package install near June 30th ?
+
+Updates installed regularly.
+
+    cd /var/log ; zgrep -h \" installed.*\" dpkg.log* | grep '2014-0[67]-..' -o | sort | uniq -c
+
+          2 2014-06-02
+          3 2014-06-03
+          3 2014-06-04
+          3 2014-06-06
+         49 2014-06-07
+          3 2014-06-10
+          8 2014-06-11
+         45 2014-06-12
+          7 2014-06-13
+          2 2014-06-16
+         42 2014-06-21
+         20 2014-06-25
+          3 2014-06-26
+         23 2014-06-27
+         13 2014-06-28
+          6 2014-06-30
+         15 2014-07-02
+          3 2014-07-03
+
+Which packages were installed on 2014-06-30 ?
+
+    cd /var/log ; zgrep -h \" installed.*\" dpkg.log* | grep '2014-06-(29|30)' -E
+
+    2014-06-30 17:29:15 status installed lxsession-data:all 0.4.9.2+git20140410-0ubuntu1.1
+    2014-06-30 17:29:29 status installed desktop-file-utils:i386 0.22-1ubuntu1
+    2014-06-30 17:29:30 status installed mime-support:all 3.54ubuntu1
+    2014-06-30 17:29:30 status installed lxsession-default-apps:i386 0.4.9.2+git20140410-0ubuntu1.1
+    2014-06-30 17:29:44 status installed lxsession-logout:i386 0.4.9.2+git20140410-0ubuntu1.1
+    2014-06-30 17:29:58 status installed lxsession:i386 0.4.9.2+git20140410-0ubuntu1.1
+
+And indeed [0.4.9.2+git20140410-0ubuntu1.1 : “lxsession” package : Ubuntu](https://launchpad.net/ubuntu/+source/lxsession/0.4.9.2+git20140410-0ubuntu1.1)
+
+So it was indeed a lxde bug.
+
+[Diff text](http://launchpadlibrarian.net/177201602/lxsession_0.4.9.2%2Bgit20140410-0ubuntu1_0.4.9.2%2Bgit20140410-0ubuntu1.1.diff.gz)
+
+I added a comment there (#69) which may serve as a hint to other people having not updated their system. [Bug #1308348 “network settings indicator missing from panel” : Bugs : “lxsession” package : Ubuntu](https://bugs.launchpad.net/ubuntu/+source/lxsession/+bug/1308348)
+
+"""]]
diff --git a/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_7_ae5c434a9c94aa000b604095f52e3d3c._comment b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_7_ae5c434a9c94aa000b604095f52e3d3c._comment
new file mode 100644
index 0000000000..4ae5454078
--- /dev/null
+++ b/doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__/comment_7_ae5c434a9c94aa000b604095f52e3d3c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 7"
+ date="2014-07-03T19:03:52Z"
+ content="""
+That lubuntu bug explains why git-annex would not autostart on login.
+
+However, that does not explain the original problem description, which was that the `Make Repository` button seemed to make a repository but not switch to the webapp running in that repository. In the case of making a new repository, the webapp is started in it by git-annex, not by the desktop autostart mechanism.
+
+Can you reproduce the original problem?
+
+
+"""]]
diff --git a/doc/bugs/On_Windows__44___can__39__t_use_a_USB_disk_annex_created_on_Linux.mdwn b/doc/bugs/On_Windows__44___can__39__t_use_a_USB_disk_annex_created_on_Linux.mdwn
new file mode 100644
index 0000000000..b997a8c725
--- /dev/null
+++ b/doc/bugs/On_Windows__44___can__39__t_use_a_USB_disk_annex_created_on_Linux.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+On Windows, git-annex is unable to 'annex get' from a repository hosted on an external USB disk.
+
+### What steps will reproduce the problem?
+1. Create an annex (A1) on a Linux system
+2. Clone A1 to a new annex (A2) to an external USB drive. add A1 as a remote, "annex get ."
+3. Mount the USB drive to a windows system. Clone A2 to a new annex (A3).
+4. add A2 as a remote to A3
+5. "git annex get ."
+6. annex get will fail with file not found errors. This appears to be due to case sensitivity on Windows.
+
+
+### What version of git-annex are you using? On what operating system?
+Windows 7: 4.20140627-g8a36ec5 (from the git-annex download page)
+
+Debian Linux: 3.20120629 (from the package manager)
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/On_Windows__44___can__39__t_use_a_USB_disk_annex_created_on_Linux/comment_1_f224f4155d857a59595658357f97dac1._comment b/doc/bugs/On_Windows__44___can__39__t_use_a_USB_disk_annex_created_on_Linux/comment_1_f224f4155d857a59595658357f97dac1._comment
new file mode 100644
index 0000000000..403c9a1b91
--- /dev/null
+++ b/doc/bugs/On_Windows__44___can__39__t_use_a_USB_disk_annex_created_on_Linux/comment_1_f224f4155d857a59595658357f97dac1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.254.222"
+ subject="comment 1"
+ date="2013-07-07T17:50:40Z"
+ content="""
+Is A2 a bare or a non-bare git repository?
+
+What filesystem is used on the USB drive?
+
+Why do you think it has to do with case sensativity?
+"""]]
diff --git a/doc/bugs/On_Windows__44___can__39__t_use_repository_that_has_a_unix-style_local_remote_configured.mdwn b/doc/bugs/On_Windows__44___can__39__t_use_repository_that_has_a_unix-style_local_remote_configured.mdwn
new file mode 100644
index 0000000000..92de1dce3e
--- /dev/null
+++ b/doc/bugs/On_Windows__44___can__39__t_use_repository_that_has_a_unix-style_local_remote_configured.mdwn
@@ -0,0 +1,22 @@
+### Please describe the problem.
+On Windows, I try to "annex get" from a Linux based repository, but it fails with no useful error message.
+
+### What steps will reproduce the problem?
+1. Create annex (A1) on a Linux system.
+2. clone A1 to another annex (A2) on the same file tree (on a mounted USB drive, for example)
+3. add A2 as a remote to A1.
+4. clone A1 to an annex (A3) on a Windows 7 system.
+5. attempt to "git annex get ."
+6. annex reports that it can find no repositories, and asks to make one available.
+
+
+### What version of git-annex are you using? On what operating system?
+Windows 7: 4.20140627-g8a36ec5 (from the git-annex download page)
+Debian Linux: 3.20120629 (from the package manager)
+
+### Please provide any additional information below.
+I experienced this bug several times with a plain git-annex install, and the only workaround was removing the unix-style remotes from remote repos.
+
+After other hackery to get git-annex working on Windows, I can't currently reproduce the issue.
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/On_Windows__44___can__39__t_use_repository_that_has_a_unix-style_local_remote_configured/comment_1_95655915ff6ba9fb5d873358ff047496._comment b/doc/bugs/On_Windows__44___can__39__t_use_repository_that_has_a_unix-style_local_remote_configured/comment_1_95655915ff6ba9fb5d873358ff047496._comment
new file mode 100644
index 0000000000..d727bcafcb
--- /dev/null
+++ b/doc/bugs/On_Windows__44___can__39__t_use_repository_that_has_a_unix-style_local_remote_configured/comment_1_95655915ff6ba9fb5d873358ff047496._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.2.134"
+ subject="comment 1"
+ date="2013-09-13T19:14:55Z"
+ content="""
+I don't understand what is meant by a \"unix-style\" remote.
+
+Generally it helps to provide some commands I can run on Windows to replicate the problem.
+"""]]
diff --git a/doc/bugs/One_Client_Not_Syncing_Content.mdwn b/doc/bugs/One_Client_Not_Syncing_Content.mdwn
new file mode 100644
index 0000000000..2535074bee
--- /dev/null
+++ b/doc/bugs/One_Client_Not_Syncing_Content.mdwn
@@ -0,0 +1,54 @@
+### Please describe the problem.
+
+I am fairly new to git annex - so I may have a misconception about how it should work.
+
+I have two laptop clients A and B that each have a single ssh remote, server C, setup as a full backup. Both of the laptops were setup through the web and have the assistant running.
+
+The problem I am seeing is that laptop A does not seem to sync contents created on laptop B. If i do the following:
+
+    laptopA# echo "foo" > bar
+    laptopB# cat bar
+    > foo
+
+    laptopB# echo "baz" > bang
+    laptopA# cat bang
+    > No such file or directory
+
+Laptop A has the symlink for bang but no contents. 
+
+if i run the following:
+
+    laptopA# git annex find --want-get --not --in .
+it returns 'bang'
+
+So it seems that laptopA wants the contents of the file created on laptopB, but doesn't sync it. If I manually run git annex sync --content everything is good. But when running the assistant should I not care about this?
+
+
+### What steps will reproduce the problem?
+
+See above.
+
+### What version of git-annex are you using? On what operating system?
+
+laptopA: OSX 10.10
+
+    git-annex version: 5.20150205
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA TorrentParser
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+laptopB: Archlinux
+
+    git-annex version: 5.20150219-g7751a05
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA TorrentParser
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+
+### Please provide any additional information below.
diff --git a/doc/bugs/One_Client_Not_Syncing_Content/comment_1_b8c8a9d10a12b72ea828b6b35d87fa5e._comment b/doc/bugs/One_Client_Not_Syncing_Content/comment_1_b8c8a9d10a12b72ea828b6b35d87fa5e._comment
new file mode 100644
index 0000000000..8f60325e3f
--- /dev/null
+++ b/doc/bugs/One_Client_Not_Syncing_Content/comment_1_b8c8a9d10a12b72ea828b6b35d87fa5e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-26T18:17:57Z"
+ content="""
+What version of git-annex is installed on laptopA?
+
+If it's too old, it won't be getting change notifications from the server
+when laptopB pushes to it.
+
+Since laptopB immediately notices pushes from laptopA, I guess that
+both laptopB and the server have new enough versions of git-annex
+for that change noitification to work.
+"""]]
diff --git a/doc/bugs/One_Client_Not_Syncing_Content/comment_2_59921abb184bffb5ac1656cc50054e11._comment b/doc/bugs/One_Client_Not_Syncing_Content/comment_2_59921abb184bffb5ac1656cc50054e11._comment
new file mode 100644
index 0000000000..fda5be00c1
--- /dev/null
+++ b/doc/bugs/One_Client_Not_Syncing_Content/comment_2_59921abb184bffb5ac1656cc50054e11._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm69GSNODRsVx40rPWDWyecnZn2r3bmOlY"
+ nickname="Jeffery"
+ subject="comment 2"
+ date="2015-03-28T03:02:24Z"
+ content="""
+laptop A has 5.20150205 while B has 5.20150219-g7751a05 ... they are fairly close. Could this cause a problem?
+"""]]
diff --git a/doc/bugs/Option_--from-anywhere_not_recognized_in_copy.mdwn b/doc/bugs/Option_--from-anywhere_not_recognized_in_copy.mdwn
new file mode 100644
index 0000000000..1f1a806bc1
--- /dev/null
+++ b/doc/bugs/Option_--from-anywhere_not_recognized_in_copy.mdwn
@@ -0,0 +1,48 @@
+### Please describe the problem.
+The `--from-anywhere` option is not recognized.
+
+### What steps will reproduce the problem?
+Create a repo, add a file to it, clone it, then try to copy the files with `git annex copy $FILE --from-anywhere --to=here`
+```sh
+$ mkdir a && cd a
+$ git init
+$ git annex init
+$ touch somefile
+$ git annex add somefile
+$ git commit -m "blub"
+$ cd ..
+$ git clone a b
+$ cd b
+$ git annex init
+$ git annex copy somefile --from-anywhere --to=here
+```
+The last command fails with
+`Invalid option `--from-anywhere'`
+
+### What version of git-annex are you using? On what operating system?
+Output from `git annex version`
+```
+git-annex version: 10.20231129-gbacd781c4fe05126219c4b5f2963677a6de01481
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24 bloomfilter-2.0.1.2 crypton-0.34 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.15 persistent-sqlite-2.13.1.0 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+I'm experiencing this issue on EndeavourOS
+```
+$ uname -r
+6.6.10-arch1-1
+```
+
+### Please provide any additional information below.
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+git annex does everything I was looking for when I found it and then some. Thank you for creating and maintaining it!
+
+> not a bug, version too old [[done]] --[[Joey]]
diff --git a/doc/bugs/Option_--from-anywhere_not_recognized_in_copy/comment_1_92bb18a7a50cf3dcbca75f544d7a0acf._comment b/doc/bugs/Option_--from-anywhere_not_recognized_in_copy/comment_1_92bb18a7a50cf3dcbca75f544d7a0acf._comment
new file mode 100644
index 0000000000..6419182420
--- /dev/null
+++ b/doc/bugs/Option_--from-anywhere_not_recognized_in_copy/comment_1_92bb18a7a50cf3dcbca75f544d7a0acf._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-01-18T15:57:56Z"
+ content="""
+Your git-annex version is from before --from-anywhere was implemented.
+
+Also, `--from-anywhere` needs `--to=remote`, as documented on the man page.
+"here" is not a remote name, so `--from-anywhere --to=here` will not work.
+
+	git-annex copy --from-anywhere --to=here
+	git-annex: there is no available git remote named "here"
+
+A simpler way to do what you were trying to do, that does work is
+`git-annex copy --to=here`
+
+An even simpler way to do exactly the same thing is `git-annex get`
+
+So, I don't see any point in trying to support `--from-anywhere --to=here`
+with `git-annex copy`.
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant.mdwn b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant.mdwn
new file mode 100644
index 0000000000..9a8eed58fa
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+I tried to sync a folder between two laptops, using the webapp and GPG encryption. I started by seting up the repository on laptop1, and then, while all the files were uploading, I went over to laptop2 and set things up there as well.
+
+At first, everything looked fine, laptop1 was uploading and laptop2 was downloading. Then, laptop2 reported "Failed to sync with VPS, and the log file showed a gcrypt error: "Packfile long-hash does not match digest!"
+
+### What version of git-annex are you using? On what operating system?
+
+
+
+Laptop1 is running wheezy with git annex version 6.20160307+gitgb095561-1~ndall+1 from neurodebian.
+
+VPS is running wheezy
+
+Laptop2 is runing jessie with git annex version 6.20160307+gitgb095561-1~ndall+1 from neurodebian.
+
+### Please provide any additional information below.
+
+http://denisa.hobbs.cz/laptop1.daemon.log
+http://denisa.hobbs.cz/laptop2.daemon.log
+
+### Have you had any luck using git-annex before?
+
+If I could get this syncing to work, then that would be great! I don't want to use unison, because that wouldn't be encrypted... So this would be wonderful.
+
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_10_9d4fdddd7ab05de9dfa4cc90f1051ef5._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_10_9d4fdddd7ab05de9dfa4cc90f1051ef5._comment
new file mode 100644
index 0000000000..2bb9552ff2
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_10_9d4fdddd7ab05de9dfa4cc90f1051ef5._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2016-09-21T21:36:18Z"
+content="""
+@Don and @pot, did you actually see un-encrypted data end up in the gcrypt
+repository? Or by "same issue" do you mean you saw the same error message,
+perhaps due to a very different cause?
+
+@jgoerzen, when you say that the gcrypt reposotory had an "unencrypted
+index", are you referring to a regular git index file, or to a pack's .idx
+file?
+
+It would be very strange if a gcrypt repository had an index file.
+I've never been able to use git-remote-gcrypt with a non-bare repository,
+and bare repositories don't normally have index files.
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_11_bbd8b537e277d24df254ed058ad40e24._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_11_bbd8b537e277d24df254ed058ad40e24._comment
new file mode 100644
index 0000000000..adff369df4
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_11_bbd8b537e277d24df254ed058ad40e24._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="pot"
+ subject="inodes...."
+ date="2016-09-30T22:00:31Z"
+ content="""
+I think I may have tracked this down partly, I ran out of inodes on a removeable drive and started getting the same error. Will try and rectify underlying inode issue and then see.
+
+(secondary point, how on earth has my docs directory used up all 59 million inodes available to it when put into an annex???)
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_12_5090e41cf96dfe542d1d2326aebc556c._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_12_5090e41cf96dfe542d1d2326aebc556c._comment
new file mode 100644
index 0000000000..af336a193b
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_12_5090e41cf96dfe542d1d2326aebc556c._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://schnouki.net/"
+ nickname="Schnouki"
+ avatar="http://cdn.libravatar.org/avatar/5f6406e9db28564121169f0051645b8c30a12a20ca7bc40287ac9bf2cd3ad283"
+ subject="comment 12"
+ date="2017-05-29T09:56:59Z"
+ content="""
+Not sure how I did it, but I have 2 repos that give me the same error. (Perhaps it happened when killing the assistant in the middle of a sync? No idea…)
+
+However I \"solved\" the issue for one repo:
+
+1. cloned the gcrypt remote to a temporary directory
+2. removed all the (encrypted) files with `git rm`, committed that, and pushed it (the repo is hosted on Gitlab and I can't just remove the branch or do something like that)
+3. removed the `gcrypt-id| from my `.git/config`
+4. ran `git annex sync` again
+
+And voilà! It works :)
+
+I don't have any content in this remote, only metadata, so it's easy to do. But I still don't know what caused this.
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_13_2bfa76c4083ff9c1d2a4adfe38ced2f0._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_13_2bfa76c4083ff9c1d2a4adfe38ced2f0._comment
new file mode 100644
index 0000000000..1a2bc7cd18
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_13_2bfa76c4083ff9c1d2a4adfe38ced2f0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="A hint?"
+ date="2017-10-02T02:05:32Z"
+ content="""
+Hi folks,
+
+I no longer use git-annex so I can't comment directly on this.  However, in some testing with git-remote-gcrypt, I came across an issue where changes seem to be lost.  In short, every git push behaves as if --force were given.  Details in [Debian but #877464](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877464).
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_14_2274479a1eef9ffc6a53ffb65e2c3511._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_14_2274479a1eef9ffc6a53ffb65e2c3511._comment
new file mode 100644
index 0000000000..7249adc933
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_14_2274479a1eef9ffc6a53ffb65e2c3511._comment
@@ -0,0 +1,52 @@
+[[!comment format=mdwn
+ username="xwvvvvwx"
+ avatar="http://cdn.libravatar.org/avatar/7198160b33539b5b1b2d56ca85c562d9"
+ subject="comment 14"
+ date="2019-11-21T17:32:31Z"
+ content="""
+I just reproduced this when pushing to a gcrypt remote on rsync.net using the assistant. There is only one client pushing to the gcrypt remote.
+
+It was during the initial sync of a moderately large amount of data (~22G), perhaps this has something to do with it?
+
+I could reproduce the issue by cloning with gcrypt directly (`git clone gcrypt::ssh://....`).
+
+I was able to recover by following the steps outlined in Schnouki's comment (#12), but this is obviously quite an unsatisfactory fix. 
+
+I am using annex to replicate important personal data, and I find this issue highly concerning.
+
+Foolishly, I did not keep a copy of the bad repo before I forced pushed over it on the remote, so I do not have a copy available to experiment with :(
+
+---
+
+## logs
+
+`daemon.log` excerpt: [https://ipfs.io/ipfs/QmcoPuTLY2v5FWPABQLVwgyqW5WdsvkBbVS33cJh6zjzi4](https://ipfs.io/ipfs/QmcoPuTLY2v5FWPABQLVwgyqW5WdsvkBbVS33cJh6zjzi4)
+
+
+`git clone` output:
+
+```
+[annex@xwvvvvwx:~]$ git clone gcrypt::ssh://<URL> remote
+Cloning into 'remote'...
+gcrypt: Decrypting manifest
+gpg: Signature made Thu 21 Nov 2019 04:02:40 PM CET
+gpg:                using RSA key 92E9F58E9F8C6845423C251AACD9A98951774194
+gpg: Good signature from \"git-annex <annex@xwvvvvwx.com>\" [ultimate]
+gcrypt: Remote ID is :id:tWrcOFKu2yX7y+jLDLxm
+gcrypt: Packfile e7b619864585f3c921b491fd041127cf0ae33c4480810610dcb2e37ec46a82be does not match digest!
+fatal: early EOF
+```
+
+`git annex version`:
+
+```
+git-annex version: 7.20191114
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.2.0.1 ghc-8.6.5 http-client-0.6.4 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+```
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_15_e8deee63316c8af39d7cf0996d26ecba._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_15_e8deee63316c8af39d7cf0996d26ecba._comment
new file mode 100644
index 0000000000..da21345ae5
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_15_e8deee63316c8af39d7cf0996d26ecba._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="sirio@84e81889437b3f6208201a26e428197c6045c337"
+ nickname="sirio"
+ avatar="http://cdn.libravatar.org/avatar/9f3a0cfaf4825081710b652cc0b438a4"
+ subject="Duplicate 'gcrypt-id' may be the issue?"
+ date="2019-12-29T22:10:26Z"
+ content="""
+Had a repo exhibit this behavior just now:
+
+- commit graph `XX -> YY`
+- host `A` @ commit `YY`
+- host `B` @ commit `XX` (1 behind)
+- remotes `hub` and `lab` both @ commit `XX`
+- `B` pushes and pulls from both `hub` and `lab`: OK
+- `A` pushes to `hub` (updates to commit `YY`): OK
+- `B` pulls from `hub`: FAIL with *Packfile does not match digest*
+- `B` pulls from `lab`: OK
+- `B` pushes to `hub`: FAIL with *Packfile does not match digest*
+- `A` pulls from `hub`: OK
+- `A` pulls from `lab`: OK
+
+When looking in `.git/config` I noticed that `remote.hub.gcrypt-id` and `remote.lab.gcrypt-id` were identical.
+
+To fix, I:
+
+- removed `remote.hub.gcrypt-id` from `.git/config` on both `A` and `B`
+- deleted and re-created a blank repo on `hub`
+- `git push hub` on `B`
+- `git pull hub master` on `A`
+
+This resulted in a new and unique value for `remote.hub.gcrypt-id`, which is the same on both `A` and `B`.
+
+Have not had time to dig into why but this is the only thread I can find about this problem so I figured I would log this somewhere for posterity.
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_16_2139bcb34591be137ff3da959f08bc76._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_16_2139bcb34591be137ff3da959f08bc76._comment
new file mode 100644
index 0000000000..5256c76087
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_16_2139bcb34591be137ff3da959f08bc76._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="branch"
+ subject="comment 16"
+ date="2023-10-23T09:56:59Z"
+ content="""
+This issue is still present, when using the assistant with git-remote-gcrypt.
+
+Although one can recover from this issue by resetting the repository, this is handicaping, as we have to continuously monitor whether pushes have been successful, which contradicts the idea of the assistant.
+
+This may be anecdotal, but the push before the 'Packfile *** does not match digest!' error, have had some network issues, as follows:
+
+```
+gcrypt: Due to a longstanding bug, this push implicitly has --force.
+gcrypt: Consider explicitly passing --force, and setting
+gcrypt: gcrypt's require-explicit-force-push git config key.
+gcrypt: Encrypting to:  -r ***
+gcrypt: Requesting manifest signature
+error: src refspec refs/gcrypt/gitception+ does not match any
+fatal: the remote end hung up unexpectedly
+error: failed to push some refs to ***
+error: failed to push some refs to ***
+```
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_17_7fcd45354f94756c34b2f3f912972c19._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_17_7fcd45354f94756c34b2f3f912972c19._comment
new file mode 100644
index 0000000000..097b85d926
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_17_7fcd45354f94756c34b2f3f912972c19._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="felix@996ab1030f55d480e424a17116e03a48bd984549"
+ nickname="felix"
+ avatar="http://cdn.libravatar.org/avatar/d6198e60afe87cca852190852feeafa8"
+ subject="Same issue after kernel oops"
+ date="2024-02-05T14:58:33Z"
+ content="""
+Just to add one more data point – I ran into the situation after a kernel oops had caused my rootfs to become read-only. So maybe related to the \"out of inodes\" issue reported above.
+
+~~~
+$ git push
+gcrypt: Decrypting manifest
+gpg: error getting version from 'scdaemon': No SmartCard daemon
+gpg: Signature made Mo 05 Feb 2024 15:22:01 CET
+gpg:                using RSA key XXX
+gpg: Good signature from \"XXX\" [ultimate]
+Primary key fingerprint: XXX
+gcrypt: Due to a longstanding bug, this push implicitly has --force.
+gcrypt: Consider explicitly passing --force, and setting
+gcrypt: gcrypt's require-explicit-force-push git config key.
+gcrypt: Repacking remote origin, ...
+gcrypt: Packfile XXX does not match digest!
+fatal: early EOF
+error: failed to push some refs to 'XXX'
+~~~
+
+XXX is obviously my redactions. I was not running the assistant, just plain git-annex.
+
+There was no plaintext on the remote and the only way for me to recover was to nuke the remote repo.
+
+I kept copies of both repos, though I unfortunately cannot share the unencrypted one.
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_1_bf61defadd3be9bc867be961b3149be6._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_1_bf61defadd3be9bc867be961b3149be6._comment
new file mode 100644
index 0000000000..cd3735334c
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_1_bf61defadd3be9bc867be961b3149be6._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-13T18:10:03Z"
+ content="""
+That error message is certainly not coming from git-annex. It sounds like a
+git error message, but I don't find it in the current git source code.
+
+What it sounds like is some form of corruption of the git repository,
+probably to a pack file. Since git-annex doesn't have anything to do with
+writing such files, it's hard to see how this could be a bug in git-annex.
+
+This kind of corruption problem tends to happen when a disk loses data,
+perhaps having to do with an unclean shutdown. Or perhaps it received
+bad git repository data from the VPS.
+
+Suggest you run `git fsck` and if it reports problems, you may be ableo
+to fix them by running `git annex repair`.
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_2_8a8ead857917e7b843f1bdfe07b5d52d._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_2_8a8ead857917e7b843f1bdfe07b5d52d._comment
new file mode 100644
index 0000000000..77a1e4d997
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_2_8a8ead857917e7b843f1bdfe07b5d52d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Don"
+ subject="comment 2"
+ date="2016-04-14T19:31:52Z"
+ content="""
+I've been watching this thread because I have the same issue.  Joey, it seems like this error message is coming from the `get_verify_decrypt_pack()` function in git-remote-gcrypt.
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_3_2432df64f920f3962b6ba02adaa9b61d._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_3_2432df64f920f3962b6ba02adaa9b61d._comment
new file mode 100644
index 0000000000..bfdddc9c7f
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_3_2432df64f920f3962b6ba02adaa9b61d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-04-14T19:57:58Z"
+ content="""
+Ok, so definitely not a bug in git-annex then.
+
+`get_verify_decrypt_pack` downloads an encrypted pack file, and then
+uses gpg to hash the pack file and compares this to the hash
+encoded in the name of the pack file.
+
+So, this could happen if the pack files in the gcrypt remote have gotten
+the wrong data into them. Or it could be a bug of some kind in
+git-remote-gcrypt.
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_4_536fbc38a7f2e7ab42188b5a8700e2cf._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_4_536fbc38a7f2e7ab42188b5a8700e2cf._comment
new file mode 100644
index 0000000000..524f507e62
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_4_536fbc38a7f2e7ab42188b5a8700e2cf._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ subject="A caution on this"
+ date="2016-06-23T21:24:49Z"
+ content="""
+Although I believe Joey's analysis is correct, I want to interject a caution: while investigating this issue on my own system, I discovered that a gcrypt remote has an unencrypted pack file and unencrypted index, which somehow contained actual data of mine.  I would consider it a git-annex bug that data (file contents) wound up in a pack file (this is a git-annex assistant repo) but a gcrypt bug that it made it there unencrypted.
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_5_f45d09939527be362c586ae1d470afe4._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_5_f45d09939527be362c586ae1d470afe4._comment
new file mode 100644
index 0000000000..4fbbfe1cad
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_5_f45d09939527be362c586ae1d470afe4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="pot"
+ subject="Same issue"
+ date="2016-07-25T18:23:13Z"
+ content="""
+Anyone got any ideas on how to fix this, or move forward without starting again and trashing the gcrypt repos? Bit of a serious bug this, if it can't be repaired. I was using git-annex for backups, but finding your backups are corrupt would be a bit of a nightmare!
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_6_88178fa312f351a7667b3b2c48335b02._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_6_88178fa312f351a7667b3b2c48335b02._comment
new file mode 100644
index 0000000000..c31f2345c9
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_6_88178fa312f351a7667b3b2c48335b02._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ subject="comment 6"
+ date="2016-07-25T19:09:09Z"
+ content="""
+This was concerning enough to me that I wound up switching to Syncthing for this particular use case.
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_7_cd6a850119dd1aa0d9bb34c6d8fe560c._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_7_cd6a850119dd1aa0d9bb34c6d8fe560c._comment
new file mode 100644
index 0000000000..e7d8b41a33
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_7_cd6a850119dd1aa0d9bb34c6d8fe560c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="branchable@1f03006a73aeda463532c8138da071037870395b"
+ nickname="branchable"
+ subject="Transcrypt? "
+ date="2016-08-05T07:28:27Z"
+ content="""
+Any experience with using transcrypt instead of git crypt?
+
+
+https://github.com/elasticdog/transcrypt
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_8_39139e25175ae265a4dc15f0b6b7b618._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_8_39139e25175ae265a4dc15f0b6b7b618._comment
new file mode 100644
index 0000000000..7629d45df8
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_8_39139e25175ae265a4dc15f0b6b7b618._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="pot"
+ subject="Hmmm, seems odd such a serious bug is allowed to linger without serious investigation"
+ date="2016-08-09T19:22:48Z"
+ content="""
+Should a developer not be all over this, would seem like a very major issue with the gcrypt backend (and annex's interaction with it) that this outcome could even be possible. You can't be using an encrypted store, which becomes irrepairably corrupted and with some of your data sat outside, unencrypted!
+
+Any thoughts from more knowledgeable developers on how to fix, investigate further, or do something useful on this front?
+"""]]
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_9_16c004fe7c77cbbba113787ce6410c9e._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_9_16c004fe7c77cbbba113787ce6410c9e._comment
new file mode 100644
index 0000000000..6c76241229
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_9_16c004fe7c77cbbba113787ce6410c9e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 9"
+ date="2016-08-09T20:17:47Z"
+ content="""
+I'm the git-remote-gcrypt maintainer, but as it stands it's not really possible to do anything about this bug without steps to reliably reproduce the corrupted/unencrypted remote repository.
+
+I have been using git-remote-gcrypt with git-annex and with plain git repos for more than two years and I have never encountered anything like this issue.  So there's no starting point to work on a fix for the issue.
+"""]]
diff --git a/doc/bugs/Pairing_locally_shows__58_____34__bad_comment_in_ssh_public_key_ssh-rsa__34__.mdwn b/doc/bugs/Pairing_locally_shows__58_____34__bad_comment_in_ssh_public_key_ssh-rsa__34__.mdwn
new file mode 100644
index 0000000000..6999d714c9
--- /dev/null
+++ b/doc/bugs/Pairing_locally_shows__58_____34__bad_comment_in_ssh_public_key_ssh-rsa__34__.mdwn
@@ -0,0 +1,23 @@
+Open two webapp sessions (in two different *screen* windows or whatever)
+
+    name@name-Computermodel-1000:~/test/annex1$ git-annex webapp
+    name@name-Computermodel-1000:~/test/annex2$ git-annex webapp
+
+In annex1's web UI, choose *Configuration* -> *Manage repositories* -> *Local computer*.
+
+Fill in the secret phrase and press *Start pairing*.
+
+In annex2's web UI, a pairing request will show on the left notifications bar. Choose *Respond*, fill in the phrase field and press *Finish pairing*.
+
+I was expecting a pairing between the two running session. But I got this after pressing *Finish pairing* in annex2's web UI:
+
+**start of output**
+# Internal Server Error
+
+bad comment in ssh public key ssh-rsa [very long GPG key jibber jabber] name@name-Computermodel-1000
+
+**end of output**
+
+git-annex version: 3.20121017, Ubuntu 12.04
+
+> [[Done]], allowed dash and underscore in there now.
diff --git a/doc/bugs/Paths_behind_relative_symlinks_in_repo_don__39__t_work.mdwn b/doc/bugs/Paths_behind_relative_symlinks_in_repo_don__39__t_work.mdwn
new file mode 100644
index 0000000000..7a1a311b7c
--- /dev/null
+++ b/doc/bugs/Paths_behind_relative_symlinks_in_repo_don__39__t_work.mdwn
@@ -0,0 +1,123 @@
+### Please describe the problem.
+
+Except for `git annex info` many (all?) other git-annex file-based commands seem to have a problem with paths behind relative symlinks to *directories* in the repository. Using the 'full' tracked-by-git or absolute path works. I guess git-annex relies on git for determining if a file is tracked and git itself fails to 'see' files behind relative symlinks to dirs in the repo as well.
+
+### What steps will reproduce the problem?
+
+Run this script:
+
+[[!format sh """
+#!/bin/sh
+export LC_ALL=C
+chmod +w -R git-annex-link
+rm -rf git-annex-link
+mkdir git-annex-link
+cd git-annex-link
+(
+git init
+git config commit.gpgsign false
+git annex init
+# make folder structure with some files
+mkdir -p level1/level2
+for f in level1/file level1/level2/file;do echo "$f" > "$f";done
+ln -rsf level1 link-to-level1
+ln -rsf level1/level2 link-to-level2
+git annex add --force-large
+git commit -m "Add files"
+) >/dev/null 2>/dev/null
+echo;(set -x;tree);echo;echo
+echo "Test results:"
+for cmd in info metadata get lookupkey whereis list fix;do
+    for file in level1/file level1/level2/file link-to-level1/file link-to-level2/file;do
+        printf "git annex %10s %20s %s\n" $cmd $file "$(git annex $cmd $file 2>/dev/null >/dev/null && echo -n ok || echo -n fail)"
+    done
+done
+echo;echo "The error is: "
+(set -x;git annex get link-to-level1/file)
+"""]]
+
+Output:
+
+```
+
++ tree
+.
+|-- level1
+|   |-- file -> ../.git/annex/objects/P7/z4/SHA256E-s12--17313e162321955543c4644ea8e1accc8d3039a9e0a9224429f26bafafe0d1b6/SHA256E-s12--17313e162321955543c4644ea8e1accc8d3039a9e0a9224429f26bafafe0d1b6
+|   `-- level2
+|       `-- file -> ../../.git/annex/objects/24/K3/SHA256E-s19--633195e34fd1e133557ece8767e268a0ebd9e4caedad4776bab4470c60a84439/SHA256E-s19--633195e34fd1e133557ece8767e268a0ebd9e4caedad4776bab4470c60a84439
+|-- link-to-level1 -> level1
+`-- link-to-level2 -> level1/level2
+
+4 directories, 2 files
+
+
+Test results:
+git annex       info          level1/file ok
+git annex       info   level1/level2/file ok
+git annex       info  link-to-level1/file ok
+git annex       info  link-to-level2/file ok
+git annex   metadata          level1/file ok
+git annex   metadata   level1/level2/file ok
+git annex   metadata  link-to-level1/file fail
+git annex   metadata  link-to-level2/file fail
+git annex        get          level1/file ok
+git annex        get   level1/level2/file ok
+git annex        get  link-to-level1/file fail
+git annex        get  link-to-level2/file fail
+git annex  lookupkey          level1/file ok
+git annex  lookupkey   level1/level2/file ok
+git annex  lookupkey  link-to-level1/file fail
+git annex  lookupkey  link-to-level2/file fail
+git annex    whereis          level1/file ok
+git annex    whereis   level1/level2/file ok
+git annex    whereis  link-to-level1/file fail
+git annex    whereis  link-to-level2/file fail
+git annex       list          level1/file ok
+git annex       list   level1/level2/file ok
+git annex       list  link-to-level1/file fail
+git annex       list  link-to-level2/file fail
+git annex        fix          level1/file ok
+git annex        fix   level1/level2/file ok
+git annex        fix  link-to-level1/file fail
+git annex        fix  link-to-level2/file fail
+
+The error is: 
++ git annex get link-to-level1/file
+error: pathspec 'link-to-level1/file' did not match any file(s) known to git
+Did you forget to 'git add'?
+get: 1 failed
+```
+
+
+### What version of git-annex are you using? On what operating system?
+
+```
+❯ inxi
+CPU: 8-core AMD Ryzen 7 5800H with Radeon Graphics (-MT MCP-)
+speed/min/max: 1450/1200/4462 MHz Kernel: 6.1.1-1-MANJARO x86_64 Up: 4h 23m
+Mem: 4370.6/13832.0 MiB (31.6%) Storage: 953.87 GiB (40.9% used) Procs: 376
+Shell: fish inxi: 3.3.24
+❯ git annex version
+git-annex version: 10.20221212-gab11fd70e
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+```
+
+
+### Please provide any additional information below.
+
+I came across this while developing my [`thunar-plugins`](https://pypi.org/project/thunar-plugins/1.0.0/) Python package for git-annex integration in XFCE's Thunar file manager. It is easily [worked around there by resolving all links before handing them to git-annex](https://gitlab.com/nobodyinperson/thunar-plugins/-/blob/de5d273106b79a5f397962c2fb3124943bdd03f7/thunar_plugins/menus/git_annex.py#L133-144). However having git-annex handle this situation natively would be nice, e.g. by also first resolving paths it gets handed. 
+
+One motivation for such relative symlinks to directories somewhere in the repository is to make **shortcuts** to some deeply nested folders.
+
+Links to *files* (not directories) get converted to links to the annex, so not a problem there.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, `git-annex` is absolutely awesome, 🎉 'finding' it was one of my highlights of 2022 😉!
diff --git a/doc/bugs/Paths_behind_relative_symlinks_in_repo_don__39__t_work/comment_1_d7ca8767953e1ec06740727a0eda4697._comment b/doc/bugs/Paths_behind_relative_symlinks_in_repo_don__39__t_work/comment_1_d7ca8767953e1ec06740727a0eda4697._comment
new file mode 100644
index 0000000000..bde87c5309
--- /dev/null
+++ b/doc/bugs/Paths_behind_relative_symlinks_in_repo_don__39__t_work/comment_1_d7ca8767953e1ec06740727a0eda4697._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="re: Paths behind relative symlinks in repo"
+ date="2023-01-03T18:28:22Z"
+ content="""
+I'll second this request.  See also [[todo/symlinks_to_symlinks_to_the_annex]] and [[todo/import_symlinks_when_importing_from_directory]].  Basic reason for wanting this is uniformity: it would help if operations worked the same way on symlinks as they do on originals.
+"""]]
diff --git a/doc/bugs/Paths_behind_relative_symlinks_in_repo_don__39__t_work/comment_2_c4e6ab98e88add01eefe545551b12929._comment b/doc/bugs/Paths_behind_relative_symlinks_in_repo_don__39__t_work/comment_2_c4e6ab98e88add01eefe545551b12929._comment
new file mode 100644
index 0000000000..4c586d3370
--- /dev/null
+++ b/doc/bugs/Paths_behind_relative_symlinks_in_repo_don__39__t_work/comment_2_c4e6ab98e88add01eefe545551b12929._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-01-16T18:56:42Z"
+ content="""
+git-annex actually has very similar behavior to git. Consider from your example:
+
+	joey@darkstar:~/tmp/xx/git-annex-link>git annex get link-to-level1/file
+	error: pathspec 'link-to-level1/file' did not match any file(s) known to git
+	Did you forget to 'git add'?
+	get: 1 failed
+	
+Compare to:
+
+	joey@darkstar:~/tmp/xx/git-annex-link>git rm link-to-level1/file
+	fatal: pathspec 'link-to-level1/file' did not match any files
+
+If anything, it seems that the bug is in `git-annex info` for behaving 
+differently in this case when run on a file behind a symlink.
+
+Also this is not a problem if you `cd` to the symlink and then run commands
+operating on relative files.
+"""]]
diff --git a/doc/bugs/Podcast_filename_encoding_breaks_Android_client.mdwn b/doc/bugs/Podcast_filename_encoding_breaks_Android_client.mdwn
new file mode 100644
index 0000000000..73a9351fe3
--- /dev/null
+++ b/doc/bugs/Podcast_filename_encoding_breaks_Android_client.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+Imported podcast files with iso-8859-1 encoding and swedish
+characters break repo on Android client with errors like.
+
+``error: unable to create file pod/Pennypodden___om_bostadspolitik/E54___�se_Richard__Gr�nby_.mp3 (Invalid argument)``
+
+Android clients empty direct repo is then distributed to all clients. Whole
+annex repo appears empty on all clients. Old revision has to be checked out to
+get files back. As soon as Android client syncs again however, all repos are
+emptied.
+
+### What steps will reproduce the problem?
+Set up indirect repo on linux laptop and direct repo on Android phone. On the
+laptop do:
+
+``git-annex importfeed http://www.pennygangen.se/podcast/podcast.xml``
+
+Wait for changes to propagate if using the assistant or sync manually.
+
+### What version of git-annex are you using? On what operating system?
+
+ - Debian sid and testing with 5.20141125 on various clients and 
+ - Android 4.4 with 5.20150219-gd24cfd3 on the phone.
+
+### Please provide any additional information below.
+
+After failing to write the files with problematic filenames git annex appears
+to belive it should commit the fact that the repo is empty and sync this
+emptiness to everyone.
+
+``convmv -f iso-8859-1 -t utf8 $problemfile --notest`` on the laptop fixes the
+filenames and the Android client stops wrecking everything.
+
diff --git a/doc/bugs/Podcast_filename_encoding_breaks_Android_client/comment_1_1bb8e3f3a3d190ed557302df8b8e0335._comment b/doc/bugs/Podcast_filename_encoding_breaks_Android_client/comment_1_1bb8e3f3a3d190ed557302df8b8e0335._comment
new file mode 100644
index 0000000000..c2e7795423
--- /dev/null
+++ b/doc/bugs/Podcast_filename_encoding_breaks_Android_client/comment_1_1bb8e3f3a3d190ed557302df8b8e0335._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-04T18:59:05Z"
+ content="""
+The bug that caused merge to empty the repo was fixed in a newer
+version of git-annex than the 5.20150219 that you're using
+on your android device. So, you should upgrade.
+
+git-annex is supposed to be completely filename encoding agnostic.
+Need to investigate what might be breaking that on Android. 
+Perhaps it's really git, and not git-annex, that's
+crashing with the "unable to create file" error?
+
+Seems so; git's entry.c contains that message.
+"""]]
diff --git a/doc/bugs/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted.mdwn b/doc/bugs/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted.mdwn
new file mode 100644
index 0000000000..35df2824d8
--- /dev/null
+++ b/doc/bugs/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted.mdwn
@@ -0,0 +1,38 @@
+### Please describe the problem.
+
+Hello! <br>
+
+&nbsp;&nbsp;&nbsp;&nbsp; I am running `Termux` on a `Huawei P20` running `Android 9.x`; when syncing content, I seem to keep getting this on most / all annexed objects:
+
+```bash
+/data/data/com.termux/files/home/git-annex.linux/shimmed/cp/cp: preserving times for '.git/annex/othertmp/*': Operation not permitted
+```
+
+where `*` is replaced by whatever object is in the folder. I don't know if this is a permissions issue or not, but it is kind of annoying, and takes time from the sync process itself. <br>
+
+&nbsp;&nbsp;&nbsp;&nbsp; Is there any way to change the shimmed `cp` to ignore times? <br>
+
+&nbsp;&nbsp;&nbsp;&nbsp; Thank you kindly for the help!
+
+
+### What steps will reproduce the problem?
+
+&nbsp;&nbsp;&nbsp;&nbsp; Simply adding or syncing content in a git annex repository in Termux on Android.
+
+### What version of git-annex are you using? On what operating system?
+
+&nbsp;&nbsp;&nbsp;&nbsp; `Version 8.20200227-ge156a2b74`
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+This is a bloody awesome project, and while I've just started using it, I'm eagre to learn more! Thank you kindly for the all the work put into this!
diff --git a/doc/bugs/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted/comment_1_093b92c3a751d32600958f34c3f2122d._comment b/doc/bugs/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted/comment_1_093b92c3a751d32600958f34c3f2122d._comment
new file mode 100644
index 0000000000..2eab7fed05
--- /dev/null
+++ b/doc/bugs/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted/comment_1_093b92c3a751d32600958f34c3f2122d._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-16T17:56:51Z"
+ content="""
+What git-annex could do is avoid passing -p to cp when it's running on
+android.
+
+Utility.Android.osAndroid already has a way to detect
+that, but running uname on every file copy is not an acceptable
+performance hit, so it would need to somehow only do it once.
+
+I am not currently seeing a satisfactory way to do that,
+everything adds at least some overhead (ie a MVar lookup) 
+to every file copy in the non-android case, and it's just 
+not acceptable that a niche use case like android adversely
+affect linux.
+
+Also, I don't think I saw this when I used git-annex on android,
+although I'm not sure if I tried anything that does copy a file.
+And it probably happens when the repo is in the sdcard, but not when it's
+in other locations, like the termux home directory, that are not on the
+mess of a filesystem stack that android uses for the sdcard.
+"""]]
diff --git a/doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key.mdwn b/doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key.mdwn
new file mode 100644
index 0000000000..1d4ea21053
--- /dev/null
+++ b/doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key.mdwn
@@ -0,0 +1,387 @@
+### Please describe the problem.
+Using the assistant on two computers to setup a shared encrypted repository (while sharing the same pgp key) on a third computer leads to files not propagating between one and two.
+
+The first and second computer does not get changes done on the other. If new files are added on the first computer it appears as if everything works (no error messages) but the files never reach the second computer (and vice versa).  
+
+
+### What steps will reproduce the problem?
+
+Three computers needed.
+
+* Computer A: Use the assistant to create a repository
+* Computer A: Use the assitant to setup a remote repository on Computer C (Add another repository - Remote server - Encrypt with GnuPG key/Encript repository with a new encryption key - Save changes)
+
+[At this point files propagate from A to C]
+ 
+* Computer A: Export the private and public gpg keys to files
+* Computer B: Import these private and public gpg files, fix trust to ultimate
+* Computer B: Use the assistant to create a repository
+* Computer B: Use the assitant to connect with the remote repository on Computer C (Add another repository - Remote server - Combine the repositories)
+
+[Files created on A before adding B now appear on B]
+
+[New files created on A do not appear on B, new files created on B do not appear on A. Files from A and B seem to propagate to C (the number of files/directories in the object sub directory on C goes up after adding files on A or B)]
+
+
+
+### What version of git-annex are you using? On what operating system?
+Computer A:
+[[!format sh """
+dirk@A:~$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 14.04.1 LTS
+Release:	14.04
+Codename:	trusty
+dirk@A:~$ git-annex version
+git-annex version: 5.20140818-g10bf03a
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+dirk@A:~$
+
+dirk@A:~$ gpg --list-keys --list-options show-uid-validity
+/home/dirk/.gnupg/pubring.gpg
+-----------------------------
+pub   4096R/0A7AA2A4 2014-08-23
+uid       [ultimate] dirk's git-annex encryption key
+
+dirk@A:~$ gpg --list-secret-keys --list-options show-uid-validity
+/home/dirk/.gnupg/secring.gpg
+-----------------------------
+sec   4096R/0A7AA2A4 2014-08-23
+uid                  dirk's git-annex encryption key
+
+dirk@A:~$
+"""]]
+
+Computer B:
+[[!format sh """
+dirk@B:~$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 14.04.1 LTS
+Release:	14.04
+Codename:	trusty
+dirk@B:~$ git-annex version
+git-annex version: 5.20140818-g10bf03a
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+dirk@B:~$
+
+dirk@B:~$ gpg --list-keys --list-options show-uid-validity
+/home/dirk/.gnupg/pubring.gpg
+-----------------------------
+pub   4096R/0A7AA2A4 2014-08-23
+uid       [ultimate] dirk's git-annex encryption key
+
+dirk@B:~$ gpg --list-secret-keys --list-options show-uid-validity
+/home/dirk/.gnupg/secring.gpg
+-----------------------------
+sec   4096R/0A7AA2A4 2014-08-23
+uid                  dirk's git-annex encryption key
+
+dirk@B:~$
+"""]]
+
+Computer C:
+[[!format sh """
+dirk@C:~$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Debian
+Description:	Debian GNU/Linux 7.6 (wheezy)
+Release:	7.6
+Codename:	wheezy
+dirk@C:~$ git-annex version
+git-annex version: 5.20140717~bpo70+1
+build flags: Assistant Webapp Pairing S3 Inotify DBus XMPP Feeds Quvi TDFA
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+remote types: git gcrypt S3 bup directory rsync web tahoe glacier ddar hook external
+dirk@C:~$
+"""]]
+
+### Please provide any additional information below.
+
+.git/annex/daemon.log - Computer A
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+[2014-08-23 15:15:01 CEST] main: starting assistant version 5.20140818-g10bf03a
+[2014-08-23 15:15:01 CEST] Cronner: You should enable consistency checking to protect your data. 
+(scanning...) [2014-08-23 15:15:01 CEST] Watcher: Performing startup scan
+(started...) 
+gpg: new configuration file `/home/dirk/.gnupg/gpg.conf' created
+gpg: WARNING: options in `/home/dirk/.gnupg/gpg.conf' are not yet active during this run
+
+Not enough random bytes available.  Please do some other work to give
+the OS a chance to collect more entropy! (Need 235 more bytes)
+....+++++
+
+Not enough random bytes available.  Please do some other work to give
+the OS a chance to collect more entropy! (Need 196 more bytes)
+.......+++++
+gpg: /home/dirk/.gnupg/trustdb.gpg: trustdb created
+gpg: key 0A7AA2A4 marked as ultimately trusted
+Generating public/private rsa key pair.
+Your identification has been saved in /tmp/git-annex-keygen.0/key.
+Your public key has been saved in /tmp/git-annex-keygen.0/key.pub.
+The key fingerprint is:
+7d:02:34:56:d4:86:b6:e5:82:b0:d9:4f:3b:51:b3:c7 dirk@A
+The key's randomart image is:
++--[ RSA 2048]----+
+|        +ooo     |
+|      .o .o *    |
+|       =.o * +   |
+|      o oo= o E  |
+|        Soo+..   |
+|          +o     |
+|           .     |
+|                 |
+|                 |
++-----------------+
+(encryption setup) (hybrid cipher with gpg key 7815EA570A7AA2A4) gcrypt: Development version -- Repository format MAY CHANGE
+gpg: checking the trustdb
+gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
+gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
+gcrypt: Repository not found: ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Repository not found: ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+gcrypt: Setting up new repository
+gcrypt: Remote ID is :id:00RaA3cNQu+nZDMERYMM
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+To gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+ * [new branch]      git-annex -> git-annex
+ok
+[2014-08-23 15:25:46 CEST] main: Syncing with C_annex 
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:25:45 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+(Recording state in git...)
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:25:45 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+To gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      annex/direct/master -> synced/master
+[2014-08-23 15:26:46 CEST] Pusher: Syncing with C_annex 
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:25:49 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+Everything up-to-date
+[2014-08-23 15:34:01 CEST] Committer: Adding hhhhn.txt
+add hhhhn.txt ok
+add hhhhn.txt ok
+[2014-08-23 15:34:01 CEST] Committer: Committing changes to git
+(Recording state in git...)
+[2014-08-23 15:34:01 CEST] Pusher: Syncing with C_annex 
+(Recording state in git...)
+gcrypt: Development version -- Repository format MAY CHANGE
+(gpg) 
+GPGHMACSHA1--7a46226ea53e4043cb45e8df6a2382ac2696164e
+
+             74 100%    0.00kB/s    0:00:00  
+             74 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2014-08-23 15:34:01 CEST] Transferrer: Uploaded hhhhn.txt
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:33:27 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+gcrypt: WARNING:
+gcrypt: WARNING: Remote ID has changed!
+gcrypt: WARNING: from :id:00RaA3cNQu+nZDMERYMM
+gcrypt: WARNING: to   :id:h/BFJbR+mE8CEkASZ/tx
+gcrypt: WARNING:
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+To gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+   85b70d6..e1d6871  annex/direct/master -> synced/master
+ + 99dc810...a7a89ff git-annex -> synced/git-annex (forced update)
+[2014-08-23 15:34:07 CEST] Pusher: Syncing with C_annex 
+(Recording state in git...)
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:34:04 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+To gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+   a7a89ff..e68b5a9  git-annex -> synced/git-annex
+[2014-08-23 15:48:30 CEST] main: warning git-annex has been shut down
+# End of transcript or log.
+"""]]
+
+.git/annex/daemon.log - Computer B
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+[2014-08-23 15:30:11 CEST] main: starting assistant version 5.20140818-g10bf03a
+[2014-08-23 15:30:11 CEST] Cronner: You should enable consistency checking to protect your data. 
+
+  dbus failed; falling back to mtab polling (ClientError {clientErrorMessage = "runClient: unable to determine DBUS address", clientErrorFatal = True})
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2014-08-23 15:30:11 CEST] Watcher: Performing startup scan
+(started...) 
+Generating public/private rsa key pair.
+Your identification has been saved in /tmp/git-annex-keygen.0/key.
+Your public key has been saved in /tmp/git-annex-keygen.0/key.pub.
+The key fingerprint is:
+b5:c3:6b:af:fc:fe:82:f2:a6:f3:42:e9:50:4b:63:9e dirk@A
+The key's randomart image is:
++--[ RSA 2048]----+
+|                 |
+|                 |
+|          .      |
+|        =o .     |
+|       =S=+      |
+|      . E  o     |
+|       +  o.     |
+|        =oo..    |
+|        .O=++o.  |
++-----------------+
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:25:49 PM CEST using RSA key ID 0A7AA2A4
+gpg: checking the trustdb
+gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
+gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
+gpg: Good signature from "dirk's git-annex encryption key"
+gcrypt: Remote ID is :id:00RaA3cNQu+nZDMERYMM
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:25:49 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+gcrypt: Remote ID is :id:00RaA3cNQu+nZDMERYMM
+Receiving objects:  14% (1/7)   
+Receiving objects:  28% (2/7)   
+Receiving objects:  42% (3/7)   
+Receiving objects:  57% (4/7)   
+Receiving objects:  71% (5/7)   
+Receiving objects:  85% (6/7)   
+Receiving objects: 100% (7/7)   
+Receiving objects: 100% (7/7), done.
+Receiving objects:  12% (1/8)   
+Receiving objects:  25% (2/8)   
+Receiving objects:  37% (3/8)   
+Receiving objects:  50% (4/8)   
+Receiving objects:  62% (5/8)   
+Receiving objects:  75% (6/8)   
+Receiving objects:  87% (7/8)   
+Receiving objects: 100% (8/8)   
+Receiving objects: 100% (8/8), done.
+From gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex
+ * [new branch]      git-annex  -> tmpgcryptremote/git-annex
+ * [new branch]      synced/git-annex -> tmpgcryptremote/synced/git-annex
+ * [new branch]      synced/master -> tmpgcryptremote/synced/master
+ * [new branch]      master     -> tmpgcryptremote/master
+(merging tmpgcryptremote/git-annex tmpgcryptremote/synced/git-annex into git-annex...)
+(Recording state in git...)
+(encryption update) (hybrid cipher with gpg key 7815EA570A7AA2A4) gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:25:49 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+gcrypt: Remote ID is :id:00RaA3cNQu+nZDMERYMM
+From gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex
+ * [new branch]      git-annex  -> C_annex/git-annex
+ * [new branch]      synced/git-annex -> C_annex/synced/git-annex
+ * [new branch]      synced/master -> C_annex/synced/master
+ * [new branch]      master     -> C_annex/master
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:25:49 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+remote: error: denying non-fast-forward refs/heads/master (you should pull first)        
+To ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+ ! [remote rejected] refs/gcrypt/gitception+ -> master (non-fast-forward)
+error: failed to push some refs to 'ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/'
+error: failed to push some refs to 'gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/'
+ok
+[2014-08-23 15:31:36 CEST] main: Syncing with C_annex 
+
+Automatic merge went well; stopped before committing as requested
+Already up-to-date!
+gcrypt: Development version -- Repository format MAY CHANGE
+[2014-08-23 15:31:37 CEST] Pusher: Syncing with C_annex 
+(Recording state in git...)
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gcrypt: Repository not found: ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+gcrypt: Setting up new repository
+gpg: Signature made Sat 23 Aug 2014 03:25:49 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+fatal: ambiguous argument 'refs/heads/synced/master..refs/remotes/C_annex/synced/master': unknown revision or path not in the working tree.
+Use '--' to separate paths from revisions, like this:
+'git <command> [<revision>...] -- [<file>...]'
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Remote ID is :id:h/BFJbR+mE8CEkASZ/tx
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:25:49 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+To gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      annex/direct/master -> synced/master
+fatal: Not a valid object name refs/gcrypt/gitception+
+To gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+   5d2eb63..e4763b8  git-annex -> synced/git-annex
+   da18915..3068bad  annex/direct/master -> synced/master
+[2014-08-23 15:32:37 CEST] Pusher: Syncing with C_annex 
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:31:43 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+gcrypt: WARNING:
+gcrypt: WARNING: Remote ID has changed!
+gcrypt: WARNING: from :id:00RaA3cNQu+nZDMERYMM
+gcrypt: WARNING: to   :id:h/BFJbR+mE8CEkASZ/tx
+gcrypt: WARNING:
+Everything up-to-date
+[2014-08-23 15:33:17 CEST] Committer: Adding fmksmxxs.txt
+add fmksmxxs.txt ok
+add fmksmxxs.txt ok
+[2014-08-23 15:33:18 CEST] Committer: Committing changes to git
+(Recording state in git...)
+[2014-08-23 15:33:18 CEST] Pusher: Syncing with C_annex 
+(Recording state in git...)
+gcrypt: Development version -- Repository format MAY CHANGE
+(gpg) gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:31:43 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+
+GPGHMACSHA1--f605f108429ffba3058a2fcf0bc006a1fbe600be
+
+             70 100%    0.00kB/s    0:00:00  
+             70 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2014-08-23 15:33:20 CEST] Transferrer: Uploaded fmksmxxs.txt
+To gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+   e4763b8..85dbfc5  git-annex -> synced/git-annex
+   3068bad..85b70d6  annex/direct/master -> synced/master
+[2014-08-23 15:33:25 CEST] Pusher: Syncing with C_annex 
+(Recording state in git...)
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:33:22 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+To gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+   85dbfc5..99dc810  git-annex -> synced/git-annex
+[2014-08-23 15:48:39 CEST] main: warning git-annex has been shut down
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key/comment_1_c8e7be58222afff2a4c1df60f657d2ed._comment b/doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key/comment_1_c8e7be58222afff2a4c1df60f657d2ed._comment
new file mode 100644
index 0000000000..5b26906daf
--- /dev/null
+++ b/doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key/comment_1_c8e7be58222afff2a4c1df60f657d2ed._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk7iPiqWr3BVPLWEDvJhSSvcOqheLEbLNo"
+ nickname="Dirk"
+ subject="comment 1"
+ date="2014-08-23T18:13:06Z"
+ content="""
+Restarting the two git-annex instances actually now leads to an error message on computer B.
+
+[[!format sh \"\"\"
+[2014-08-23 20:02:00 CEST] main: starting assistant version 5.20140818-g10bf03a
+[2014-08-23 20:02:00 CEST] Cronner: You should enable consistency checking to protect your data. 
+
+  dbus failed; falling back to mtab polling (ClientError {clientErrorMessage = \"runClient: unable to determine DBUS address\", clientErrorFatal = True})
+[2014-08-23 20:02:00 CEST] TransferScanner: Syncing with C_annex 
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2014-08-23 20:02:00 CEST] Watcher: Performing startup scan
+gcrypt: Development version -- Repository format MAY CHANGE
+(started...) 
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:34:08 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from \"dirk's git-annex encryption key\"
+gcrypt: Packfile 59a8d97d3d252effb044625e020f9dc8621804649186a5c33c4e47f9e961cc1a does not match digest!
+fatal: early EOF
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:34:08 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from \"dirk's git-annex encryption key\"
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+To gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+   e1d6871..85b70d6  annex/direct/master -> synced/master
+ + e68b5a9...99dc810 git-annex -> synced/git-annex (forced update)
+\"\"\"]]
+"""]]
diff --git a/doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit/comment_1_720dbf9d959a0050a159713cd1386913._comment b/doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit/comment_1_720dbf9d959a0050a159713cd1386913._comment
new file mode 100644
index 0000000000..da503f4131
--- /dev/null
+++ b/doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit/comment_1_720dbf9d959a0050a159713cd1386913._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-10T16:08:21Z"
+ content="""
+I have tried a clean install of msysgit 1.9.5, and verified that it still
+puts `cmd` in the PATH, as long as you follow the instructions and tell it
+to.
+
+Closing this bug.
+"""]]
diff --git a/doc/bugs/Push_to_special_remote_includes_unwanted_files.mdwn b/doc/bugs/Push_to_special_remote_includes_unwanted_files.mdwn
new file mode 100644
index 0000000000..29da8a3010
--- /dev/null
+++ b/doc/bugs/Push_to_special_remote_includes_unwanted_files.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+
+When pushing to a special remote, non-largefiles (Git text files) are not filtered by the wanted setting.
+
+### What steps will reproduce the problem?
+
+Push to a directory special remote with exporttree and importtree set yes. The wanted setting filters largefiles, but all Git text files are included even though some are not included in the filter.
+
+### What version of git-annex are you using? On what operating system?
+
+10.20231130-g0e9bc415882a5e3a285e004cf9f80936e5762a07
+Linux
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/Push_to_special_remote_includes_unwanted_files/comment_1_a9d43aaca191a2ea464d13bcba6cd31d._comment b/doc/bugs/Push_to_special_remote_includes_unwanted_files/comment_1_a9d43aaca191a2ea464d13bcba6cd31d._comment
new file mode 100644
index 0000000000..3d746d9408
--- /dev/null
+++ b/doc/bugs/Push_to_special_remote_includes_unwanted_files/comment_1_a9d43aaca191a2ea464d13bcba6cd31d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-01-25T18:09:23Z"
+ content="""
+Thing is that non-annexed files cannot really be matched by preferred
+content settings generally.
+
+I guess you are using something like `exclude=*.c`?
+"""]]
diff --git a/doc/bugs/Push_to_special_remote_includes_unwanted_files/comment_2_44143f10ac80a979513477fbac2637f3._comment b/doc/bugs/Push_to_special_remote_includes_unwanted_files/comment_2_44143f10ac80a979513477fbac2637f3._comment
new file mode 100644
index 0000000000..bbfc19da02
--- /dev/null
+++ b/doc/bugs/Push_to_special_remote_includes_unwanted_files/comment_2_44143f10ac80a979513477fbac2637f3._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="jstritch"
+ avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
+ subject="comment 2"
+ date="2024-01-31T22:12:47Z"
+ content="""
+Yes, copying .h but not .c would be an example. It makes a mess of the special remote's directory structure.
+
+Export has the same problem, so there is no way to copy files to the special remote without making a mess.
+
+Import does it correctly going the other way by *not* grabbing files *wanted* by the repository but *not wanted* the special remote. I believe symmetry is desirable in this case.
+
+Please provide a way to copy to a special remote with import-like filtering.
+
+"""]]
diff --git a/doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__.mdwn b/doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__.mdwn
new file mode 100644
index 0000000000..46c97a03a6
--- /dev/null
+++ b/doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__.mdwn
@@ -0,0 +1,42 @@
+I'm running three repositories (laptop, usb connected to laptop, local server) that are connected via ssh access.
+Running the webapp on both laptop and server, I'm quite frequently seeing in both webapps:
+
+     warning
+    Pusher crashed: fd:56: hPutStr: illegal operation (handle is closed)
+
+Pushing the "Restart thread" button sometimes dismisses the warning, sometimes it immediatly comes back even when trying several times.
+A similar warning sometimes shows up for a Netwatcher thread.
+
+Not sure but when that crash occurs tranfers between the repos seem to get stalled.
+
+Server: git-annex 7.20190129-2~bpo9+1 on debian stretch
+Laptop: git-annex 7.20190129-3 on debian testing
+
+
+Log snippet:
+
+[[!format sh """
+[2019-09-07 14:10:30.330041206] Committer: Adding jmg_0578.jpg5895 jmg_0578.jpg
+add incoming/5d/jmg_0578.jpg [2019-09-07 14:10:30.358484399] Committer: Committing changes to git
+(recording state in git...)
+[2019-09-07 14:13:01.986780732] Pusher: Syncing with usbimg, cube_media_srv_img 
+Pusher crashed: fd:56: hPutStr: illegal operation (handle is closed)
+[2019-09-07 14:13:02.009823288] Pusher: warning Pusher crashed: fd:56: hPutStr: illegal operation (handle is closed)
+[2019-09-07 14:13:49.112731437] RemoteControl: Syncing with cube_media_srv_img 
+(merging synced/git-annex into git-annex...)
+fd:56: hPutStr: illegal operation (handle is closed)
+fd:56: hPutStr: illegal operation (handle is closed)
+From ssh://git-annex-cube-flixh_22_.2Fmedia.2Fsrv.2Fimg/media/srv/img
+   3c9104b770..cea5c2f058  annex/direct/master -> cube_media_srv_img/annex/direct/master
+   71006e08a7..536584bdfa  git-annex  -> cube_media_srv_img/git-annex
+fd:56: hPutStr: illegal operation (handle is closed)
+[2019-09-07 14:15:58.002820518] Committer: Adding jmg_0592...ftool_tmp
+[2019-09-07 14:15:59.526375687] Committer: Adding jmg_0592...ftool_tmp jmg_0592.cr2
+add incoming/5d/jmg_0592.cr2 [2019-09-07 14:15:59.599057025] Committer: Committing changes to git
+(recording state in git...)
+[2019-09-07 14:15:59.670107852] Pusher: Syncing with usbimg, cube_media_srv_img 
+Pusher crashed: fd:56: hPutStr: illegal operation (handle is closed)
+[2019-09-07 14:15:59.683904185] Pusher: warning Pusher crashed: fd:56: hPutStr: illegal operation (handle is closed)
+[2019-09-07 14:18:09.282924907] Committer: Adding CI1026+1375.JPG5895
+
+"""]]
diff --git a/doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__/comment_1_ab1e86667225a0174a4e19210778f97c._comment b/doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__/comment_1_ab1e86667225a0174a4e19210778f97c._comment
new file mode 100644
index 0000000000..e1d9076929
--- /dev/null
+++ b/doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__/comment_1_ab1e86667225a0174a4e19210778f97c._comment
@@ -0,0 +1,63 @@
+[[!comment format=mdwn
+ username="jgeerds"
+ subject="Pusher crashed: fd:56: hPutStr: illegal operation (handle is closed)"
+ date="2020-04-27T08:52:11Z"
+ content="""
+I'm having the same issue on my machines. Is there anything I can do to help debugging the issue?
+
+The error occurs multiple times per day and git-annex stops working after that (or at least pushing). Unfortunately, it happens so frequently, that I'm not always aware of. 
+
+
+**git-annex version**
+
+```
+❯ git-annex version
+git-annex version: 7.20200204
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.4 feed-1.2.0.1 ghc-8.6.5 http-client-0.6.4 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+```
+
+**log messages**
+```
+[2020-04-22 23:46:32.097215608] NetWatcherFallback: Syncing with annexhost
+Everything up-to-date
+[2020-04-23 00:46:32.359155185] NetWatcherFallback: Syncing with annexhost
+Everything up-to-date
+[2020-04-23 00:50:54.17444612] Committer: Adding My_File.org
+add My_File.org ok
+[2020-04-23 00:50:54.178821719] Committer: Committing changes to git
+(recording state in git...)
+[2020-04-23 00:50:54.203132132] Pusher: Syncing with annexhost
+(recording state in git...)
+
+^M100%  5.67 KiB        119 KiB/s 0sTo ssh://annexhost.mydomain.test:/home/jascha.geerds/Org/Privat
+   72f666e..6c6173d  git-annex -> synced/git-annex
+   ee59f26..dbd86f6  master -> synced/master
+^M                                  ^M[2020-04-23 00:50:54.396222895] Transferrer: Uploaded My_File.org
+[2020-04-23 00:50:56.593376023] Pusher: Syncing with annexhost
+Pusher crashed: fd:49: hPutStr: illegal operation (handle is closed)
+[2020-04-23 00:50:56.596448524] Pusher: warning Pusher crashed: fd:49: hPutStr: illegal operation (handle is closed)
+[2020-04-23 01:44:22.764148489] NetWatcher: Syncing with annexhost
+mux_client_request_session: read from master failed: Broken pipe
+Von ssh://annexhost.mydomain.test:/home/jascha.geerds/Org/Privat
+   6c6173d..eea706b  git-annex  -> annexhost/git-annex
+fd:49: hPutStr: illegal operation (handle is closed)
+git-annex: fd:49: hPutStr: illegal operation (handle is closed)
+[2020-04-23 16:37:01.848110929] NetWatcherFallback: Syncing with annexhost
+NetWatcherFallback crashed: fd:49: hPutStr: illegal operation (handle is closed)
+[2020-04-23 16:37:01.903992912] NetWatcherFallback: warning NetWatcherFallback crashed: fd:49: hPutStr: illegal operation (handle is closed)
+[2020-04-23 17:00:15.467028948] Committer: Adding My_File.org
+add My_File.org [2020-04-23 17:00:15.478417574] Committer: Committing changes to git
+(recording state in git...)
+[2020-04-23 17:37:12.269224569] Committer: Committing changes to git
+(recording state in git...)
+[2020-04-23 17:37:13.377765106] Committer: Committing changes to git
+```
+
+
+"""]]
diff --git a/doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__/comment_2_cc207e43757c44b4e749488b563fdc87._comment b/doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__/comment_2_cc207e43757c44b4e749488b563fdc87._comment
new file mode 100644
index 0000000000..1b164533cf
--- /dev/null
+++ b/doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__/comment_2_cc207e43757c44b4e749488b563fdc87._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="felix.hagemann@b76e9ea0928cf33dacffc37ec3dbecf33171a8a5"
+ nickname="felix.hagemann"
+ avatar="http://cdn.libravatar.org/avatar/1f7e89860de517a494f35ebfb385288e"
+ subject="Still happening"
+ date="2021-04-25T16:20:04Z"
+ content="""
+I am still suffering from the same problem, git-annex versions are:
+laptop git-annex version: 8.20210223
+server git-annex version: 8.20200330
+
+Also as soon as there is a bit more something to be synced the repositories frequently need to be repaired, which on the server takes days for this 130GB repo.
+
+Anything I can do to help debug this?
+"""]]
diff --git a/doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__/comment_3_7cdef9cf264f1b11cef7cea3accf112a._comment b/doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__/comment_3_7cdef9cf264f1b11cef7cea3accf112a._comment
new file mode 100644
index 0000000000..1adbae14b8
--- /dev/null
+++ b/doc/bugs/Pusher_crashed__58___fd__58__56__58___hPutStr__58___illegal_operation___40__handle_is_closed__41__/comment_3_7cdef9cf264f1b11cef7cea3accf112a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jgsuess@732b8c62c50d8595d7b1d58eea11e5019c2308b1"
+ nickname="jgsuess"
+ avatar="http://cdn.libravatar.org/avatar/35a99d1b5df046b206807941ce9795d3"
+ subject="Also seeing this behaviour"
+ date="2021-08-02T06:14:41Z"
+ content="""
+I also have this problem. Any advice?
+"""]]
diff --git a/doc/bugs/Race_condition_between_watch__47__assistant_and_addurl.mdwn b/doc/bugs/Race_condition_between_watch__47__assistant_and_addurl.mdwn
new file mode 100644
index 0000000000..1fee439281
--- /dev/null
+++ b/doc/bugs/Race_condition_between_watch__47__assistant_and_addurl.mdwn
@@ -0,0 +1,195 @@
+Addurl can fail due to an apparent race condition when watch or assistant is running and the repository is in direct mode. The following stress test script encounters the bug consistently on my system. I am running git-annex 5.20140320 on on Ubuntu 13.10.
+
+[[!format sh """
+#!/bin/sh
+set -eu
+
+cleanup() {
+  local dir
+  dir="$1"; shift
+  if [ -d "$dir" ]; then
+    (
+      set -x
+      fuser -k -w "$dir/annex/.git/annex/daemon.log" || :
+      find "$dir" -type d -exec chmod 700 '{}' '+'
+      find "$dir" -type f -exec chmod 600 '{}' '+'
+      rm -fr "$dir"
+    )
+  fi
+}
+
+go() {
+  local dir
+  dir="$(mktemp -d "${TMP:-/tmp}/stress-annex.XXXXXXXXXX")"
+  trap "cleanup '$dir'" 0 1 2 13 15
+
+  (
+    cd "$dir"
+    mkdir annex
+    cd annex
+    set -x
+
+    git init
+    git annex init
+    git annex direct
+    git annex watch
+
+    for n in $(seq 100); do
+      git annex addurl --file=foo http://heh.fi/robots.txt
+      git annex sync
+      rm -f foo
+      git annex sync
+    done
+
+    git annex watch --stop
+    git annex uninit
+  )
+
+  cleanup "$dir"
+  trap - 0 1 2 13 14
+}
+
+go
+"""]]
+
+Script output:
+
+[[!format sh """
+% ./stress-annex
++ git init
+Initialized empty Git repository in /tmp/stress-annex.OKj6D8kVmV/annex/.git/
++ git annex init
+init  ok
+(Recording state in git...)
++ git annex direct
+commit  
+On branch master
+
+Initial commit
+
+nothing to commit
+ok
+direct  ok
++ git annex watch
++ seq 100
++ git annex addurl --file=foo http://heh.fi/robots.txt
+addurl foo (downloading http://heh.fi/robots.txt ...) 
+--2014-03-27 03:14:29--  http://heh.fi/robots.txt
+Resolving heh.fi (heh.fi)... 83.145.237.222
+Connecting to heh.fi (heh.fi)|83.145.237.222|:80... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 0 [text/plain]
+Saving to: ‘/tmp/stress-annex.OKj6D8kVmV/annex/.git/annex/tmp/URL--http&c%%heh.fi%robots.txt’
+
+    [ <=>                                                                                      ] 0           --.-K/s   in 0s      
+
+2014-03-27 03:14:29 (0.00 B/s) - ‘/tmp/stress-annex.OKj6D8kVmV/annex/.git/annex/tmp/URL--http&c%%heh.fi%robots.txt’ saved [0/0]
+
+(Recording state in git...)
+ok
+(Recording state in git...)
++ git annex sync
+commit  ok
++ rm -f foo
++ git annex sync
+commit  (Recording state in git...)
+ok
+(Recording state in git...)
++ git annex addurl --file=foo http://heh.fi/robots.txt
+addurl foo (downloading http://heh.fi/robots.txt ...) 
+--2014-03-27 03:14:29--  http://heh.fi/robots.txt
+Resolving heh.fi (heh.fi)... 83.145.237.222
+Connecting to heh.fi (heh.fi)|83.145.237.222|:80... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 0 [text/plain]
+Saving to: ‘/tmp/stress-annex.OKj6D8kVmV/annex/.git/annex/tmp/URL--http&c%%heh.fi%robots.txt’
+
+    [ <=>                                                                                      ] 0           --.-K/s   in 0s      
+
+2014-03-27 03:14:29 (0.00 B/s) - ‘/tmp/stress-annex.OKj6D8kVmV/annex/.git/annex/tmp/URL--http&c%%heh.fi%robots.txt’ saved [0/0]
+
+(Recording state in git...)
+ok
+(Recording state in git...)
++ git annex sync
+commit  ok
++ rm -f foo
++ git annex sync
+commit  (Recording state in git...)
+ok
+(Recording state in git...)
++ git annex addurl --file=foo http://heh.fi/robots.txt
+addurl foo (downloading http://heh.fi/robots.txt ...) 
+--2014-03-27 03:14:29--  http://heh.fi/robots.txt
+Resolving heh.fi (heh.fi)... 83.145.237.222
+Connecting to heh.fi (heh.fi)|83.145.237.222|:80... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 0 [text/plain]
+Saving to: ‘/tmp/stress-annex.OKj6D8kVmV/annex/.git/annex/tmp/URL--http&c%%heh.fi%robots.txt’
+
+    [ <=>                                                                                      ] 0           --.-K/s   in 0s      
+
+2014-03-27 03:14:29 (0.00 B/s) - ‘/tmp/stress-annex.OKj6D8kVmV/annex/.git/annex/tmp/URL--http&c%%heh.fi%robots.txt’ saved [0/0]
+
+
+git-annex: /tmp/stress-annex.OKj6D8kVmV/annex/.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/: openTempFile: permission denied (Permission denied)
+failed
+git-annex: addurl: 1 failed
++ fuser -k -w /tmp/stress-annex.OKj6D8kVmV/annex/.git/annex/daemon.log
+/tmp/stress-annex.OKj6D8kVmV/annex/.git/annex/daemon.log: 30704 30709 30735 30738 30778
++ find /tmp/stress-annex.OKj6D8kVmV -type d -exec chmod 700 {} +
++ find /tmp/stress-annex.OKj6D8kVmV -type f -exec chmod 600 {} +
++ rm -fr /tmp/stress-annex.OKj6D8kVmV
+"""]]
+
+The script also seems to encounter another issue. The output when seq 100 is changed to seq 1 and addurl happens to succeed:
+
+[[!format sh """
++ git init
+Initialized empty Git repository in /tmp/stress-annex.QEs0pNyS9z/annex/.git/
++ git annex init
+init  ok
+(Recording state in git...)
++ git annex direct
+commit  
+On branch master
+
+Initial commit
+
+nothing to commit
+ok
+direct  ok
++ git annex watch
++ seq 1
++ git annex addurl --file=foo http://heh.fi/robots.txt
+addurl foo (downloading http://heh.fi/robots.txt ...) 
+--2014-03-27 03:17:20--  http://heh.fi/robots.txt
+Resolving heh.fi (heh.fi)... 83.145.237.222
+Connecting to heh.fi (heh.fi)|83.145.237.222|:80... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 0 [text/plain]
+Saving to: ‘/tmp/stress-annex.QEs0pNyS9z/annex/.git/annex/tmp/URL--http&c%%heh.fi%robots.txt’
+
+    [ <=>                                                                                      ] 0           --.-K/s   in 0s      
+
+2014-03-27 03:17:20 (0.00 B/s) - ‘/tmp/stress-annex.QEs0pNyS9z/annex/.git/annex/tmp/URL--http&c%%heh.fi%robots.txt’ saved [0/0]
+
+(Recording state in git...)
+ok
+(Recording state in git...)
++ git annex sync
+commit  ok
++ rm -f foo
++ git annex sync
+commit  (Recording state in git...)
+ok
+(Recording state in git...)
++ git annex watch --stop
++ git annex uninit
+git-annex: /tmp/stress-annex.QEs0pNyS9z/annex/.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.map: removeLink: permission denied (Permission denied)
++ fuser -k -w /tmp/stress-annex.QEs0pNyS9z/annex/.git/annex/daemon.log
++ :
++ find /tmp/stress-annex.QEs0pNyS9z -type d -exec chmod 700 {} +
++ find /tmp/stress-annex.QEs0pNyS9z -type f -exec chmod 600 {} +
++ rm -fr /tmp/stress-annex.QEs0pNyS9z
+"""]]
diff --git a/doc/bugs/Race_condition_between_watch__47__assistant_and_addurl/comment_1_8f56b8661a600729d7a9d569e8a0ba70._comment b/doc/bugs/Race_condition_between_watch__47__assistant_and_addurl/comment_1_8f56b8661a600729d7a9d569e8a0ba70._comment
new file mode 100644
index 0000000000..cf010cd253
--- /dev/null
+++ b/doc/bugs/Race_condition_between_watch__47__assistant_and_addurl/comment_1_8f56b8661a600729d7a9d569e8a0ba70._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="http://johan.kiviniemi.name/"
+ nickname="Johan"
+ subject="Another race condition"
+ date="2014-03-31T03:42:42Z"
+ content="""
+Here’s another race condition which seems related:
+
+[[!format sh \"\"\"
+% git annex addurl 'quvi:http://youtu.be/-CbFj9K9AQg'
+addurl David_Raymond_Christiansen___Dependently_Typed_Programming_in_Idris___A_Demo.webm 
+--2014-03-31 05:45:49--  http://r4---sn-oxc0a5-ixae.googlevideo.com/videoplayback?<cut>
+Resolving r4---sn-oxc0a5-ixae.googlevideo.com (r4---sn-oxc0a5-ixae.googlevideo.com)... 83.145.196.143, 2001:1bc8:100:1b::f
+Connecting to r4---sn-oxc0a5-ixae.googlevideo.com (r4---sn-oxc0a5-ixae.googlevideo.com)|83.145.196.143|:80... connected.
+HTTP request sent, awaiting response... 302 Found
+Location: http://r13---sn-5go7dn7s.googlevideo.com/videoplayback?<cut> [following]
+--2014-03-31 05:45:49--  http://r13---sn-5go7dn7s.googlevideo.com/videoplayback?<cut>
+Resolving r13---sn-5go7dn7s.googlevideo.com (r13---sn-5go7dn7s.googlevideo.com)... 173.194.48.18, 2a00:1450:400f::12
+Connecting to r13---sn-5go7dn7s.googlevideo.com (r13---sn-5go7dn7s.googlevideo.com)|173.194.48.18|:80... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 320557466 (306M) [video/webm]
+Saving to: ‘/home/ion/nobackup/media/video/.git/annex/tmp/URL--quvi&chttp&c%%youtu.be%-CbFj9K9AQg’
+
+100%[======================================>] 320,557,466  895KB/s   in 6m 14s 
+
+2014-03-31 05:52:04 (837 KB/s) - ‘/home/ion/nobackup/media/video/.git/annex/tmp/URL--quvi&chttp&c%%youtu.be%-CbFj9K9AQg’ saved [320557466/320557466]
+
+(Recording state in git...)
+fatal: Unable to create '/home/ion/nobackup/media/video/.git/index.lock': File exists.
+
+If no other git process is currently running, this probably means a
+git process crashed in this repository earlier. Make sure no other git
+process is running and remove the file manually to continue.
+
+git-annex: user error (xargs [\"-0\",\"git\",\"--git-dir=/home/ion/nobackup/media/video/.git\",\"--work-tree=/home/ion/nobackup/media/video\",\"-c\",\"core.bare=false\",\"add\",\"--\"] exited 123)
+failed
+git-annex: addurl: 1 failed
+
+% ls -l /home/ion/nobackup/media/video/.git/index.lock
+ls: cannot access /home/ion/nobackup/media/video/.git/index.lock: No such file or directory
+\"\"\"]]
+
+The only lines in daemon.log from that time:
+
+[[!format sh \"\"\"
+[2014-03-31 05:52:04 EEST] Committer: Committing changes to git
+[2014-03-31 05:52:04 EEST] Pusher: Syncing with heh.fi 
+Already up-to-date.
+To heh.fi:/storage/ion/media/video
+   3df241b..095d6c3  git-annex -> synced/git-annex
+   10b3166..98074c1  annex/direct/master -> synced/master
+Already up-to-date.
+\"\"\"]]
+
+"""]]
diff --git a/doc/bugs/Race_condition_between_watch__47__assistant_and_addurl/comment_2_46dc67bdcd174cd50ccc421ec56735ad._comment b/doc/bugs/Race_condition_between_watch__47__assistant_and_addurl/comment_2_46dc67bdcd174cd50ccc421ec56735ad._comment
new file mode 100644
index 0000000000..ec3c974d98
--- /dev/null
+++ b/doc/bugs/Race_condition_between_watch__47__assistant_and_addurl/comment_2_46dc67bdcd174cd50ccc421ec56735ad._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 2"
+ date="2014-04-02T20:17:19Z"
+ content="""
+These races look beniegn, as far as I can see it doesn't cause any data to be lost, or indeed anything to happen that wouldn't have happened if addurl had been run without the assistant running.
+
+The first race probably has addurl and the assistant both trying to move the file object into the annex at the same time. One wins and moves it; the other loses and sulks.
+
+The second race has addurl trying to `git add` the file, while the assistant has already noticed the file appeared, `git add`ed it, and committed the add.
+
+The only way to really avoid these races would be to add a lot of lock checking. Or just make `git annex addurl` and presumably also `git annex add` and maybe several other commands refuse to run when the assistant is running.
+"""]]
diff --git a/doc/bugs/Race_condition_or_double-locking_with_pidlock.mdwn b/doc/bugs/Race_condition_or_double-locking_with_pidlock.mdwn
new file mode 100644
index 0000000000..4347fc2e06
--- /dev/null
+++ b/doc/bugs/Race_condition_or_double-locking_with_pidlock.mdwn
@@ -0,0 +1,59 @@
+### Please describe the problem.
+
+When doing `git annex sync` with new changes from a remote (i.e. synced/main and/or some_remote/main is ahead of our main), git annex seems to try and lock at least two things/times. With pidlock, this of course isn't possible, so somewhere around a `git merge`, we get the following error:
+
+```
+   waiting for pid lock file .git/annex/pidlock which is held by another process (or may be stale)
+```
+
+When I inspect the content of the pidlock, the `git-annex-sync` process has the lock.
+
+Manually running `git merge <ref that is ahead>` and then `git annex sync` doesn't have this issue, so it seems related to merging changes to the main branch (not the git-annnex branch). 
+
+### What steps will reproduce the problem?
+
+I've really struggled to find a minimal reproducer, but I've hit this bug with several large real-world repos (@joeyh, I would be more than happy to give private access to one of these if you think it would be useful for debugging)
+
+The latest time this happened, this was the full log:
+
+```
+$ git annex sync
+pull origin 
+
+Updating 130dffc63..f8889be0c
+  waiting for pid lock file .git/annex/pidlock which is held by another process (or may be stale)
+#### hangs indefinitely  ######
+^C
+$ git merge origin/main
+Updating 130dffc63..f8889be0c
+Updating files: 100% (223/223), done.
+Fast-forward
+ .gitignore 
+<and then quite a large diff, including many files created/deleted>
+$ git annex sync
+# merges git-annex branch and pushes to all remotes successfully
+```
+
+Sometimes, but not always, it seems that a git merge updates the files on disk, but not the git index, leading to an inconsistent state where I have the working tree of the latest commit, but git believes I'm still on the older HEAD and shows the diff as unstaged changes. In these cases one must `git reset --hard HEAD && git clean -df` to clear the state back to HEAD, and then git merge manually, and only then will git annex sync behave as expected.
+
+### What version of git-annex are you using? On what operating system?
+
+This issue seems to only exist on versions 10.xxxx, and I remember first running into this a bit over a year ago (I first assumed that it was user error, but I've since had it occur quite a few tim  es where it can't be, e.g. freshly logging into a server that was just restarted). At least the following versions are affected:
+
+* git-annex version: 10.20220526-gc6b112108
+* git-annex version: 10.20230803-gb2887edc9
+* git-annex version: 10.20230926-g44a7b4c9734adfda5912dd82c1aa97c615689f57
+
+This is on various linuxes, mostly a few years old as these are institutional supercomputing clusters (ubuntu 20.04, debian 10, SLES 15.4).
+
+### Please provide any additional information below.
+
+This only affects clones with pidlock enabled (on compute clusters with NFS filesystems), the same repo on a laptop or whatever with a standard local filesystem (e.g. ext4, xfs) works perfectly.
+
+Could this be caused by e.g. git annex running git merge which runs git annex filterprocess (directly or via git status), and git-annex-filterprocess tries to take the pidlock that git-annex-sync already has?
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Lots! This problem popped up during our regular use of git-annex in plant genomic research, where we use git annex to manage and move our analyses between the many clusters we must use for computation. Git annex is indispensable for this use case!!
+
+> [[fixed|done]] (for the merge case at least) --[[Joey]]
diff --git a/doc/bugs/Race_condition_or_double-locking_with_pidlock/comment_1_bd92615c640ff017cd8a2ebfcc117a37._comment b/doc/bugs/Race_condition_or_double-locking_with_pidlock/comment_1_bd92615c640ff017cd8a2ebfcc117a37._comment
new file mode 100644
index 0000000000..daa07df33f
--- /dev/null
+++ b/doc/bugs/Race_condition_or_double-locking_with_pidlock/comment_1_bd92615c640ff017cd8a2ebfcc117a37._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-12-04T17:06:11Z"
+ content="""
+> Could this be caused by e.g. git annex running git merge which runs git annex
+> filterprocess (directly or via git status), and git-annex-filterprocess tries
+> to take the pidlock that git-annex-sync already has?
+
+If so you should be able to see the two git-annex's running in ps when this hang occurs
+with the git process in between them.
+That would be very helpful to verify since it would narrow down the git command
+that runs this git-annex child process.
+
+git-annex does deal with exactly this kind of scenario when running eg
+`git update-index`, by setting an environment variable to tell the child git-annex
+process not to re-lock the pid lock. But not in eg the case of a git merge.
+
+So, if you can narrow it down specifically to `git merge` running when this
+happens, or whatever other command, it should be easy to fix it.
+
+Hmm, I suppose that it makes sense `git merge` will sometimes need to check if
+a worktree file is modified, and so run git-annex. I'm pretty convinced by your
+transcript that it is the git merge that's hanging. So I've gone ahead and put
+in the workaround for that. There's of course still the possibility there's
+some other git command I've not anticipated that still needs the workaround.
+"""]]
diff --git a/doc/bugs/Race_condition_or_double-locking_with_pidlock/comment_2_6db20a7c8ddde72cba76240b3f7faddd._comment b/doc/bugs/Race_condition_or_double-locking_with_pidlock/comment_2_6db20a7c8ddde72cba76240b3f7faddd._comment
new file mode 100644
index 0000000000..20cc237b72
--- /dev/null
+++ b/doc/bugs/Race_condition_or_double-locking_with_pidlock/comment_2_6db20a7c8ddde72cba76240b3f7faddd._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="confirmed fixed"
+ date="2024-01-03T09:03:44Z"
+ content="""
+Hi Joey, sorry, I should have confirmed this earlier but this seems to have completely fixed this issue in all cases I'd observed it. Many thanks!
+
+best,
+K
+"""]]
diff --git a/doc/bugs/Recreating_remote_repository__39__s_annex.mdwn b/doc/bugs/Recreating_remote_repository__39__s_annex.mdwn
new file mode 100644
index 0000000000..58003f6245
--- /dev/null
+++ b/doc/bugs/Recreating_remote_repository__39__s_annex.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+My remote repository's annex was lost.  In the webapp, I can now click to recreate it, that fails half-way.
+
+### What steps will reproduce the problem?
+Create a remote repo, delete the annex directory.
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 5.20140517-g0aed6d9
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+local repository version: unknown
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+
+### Please provide any additional information below.
+
+[[!format sh """
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Repository not found: ssh://lhunath@satura.lyndir.com/~/annex/
+gcrypt: Setting up new repository
+gcrypt: Remote ID is :id:ROTs3SImZEdvdO2yCMku
+gcrypt: Encrypting to:  -R 0EF21226F43EA6BC
+gcrypt: Requesting manifest signature
+Warning: remote port forwarding failed for listen port 2222
+Warning: remote port forwarding failed for listen port 37218
+fatal: '~/annex/' does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Recreating_remote_repository__39__s_annex/comment_1_9fffb1329a4a06111cf2afd8552aea62._comment b/doc/bugs/Recreating_remote_repository__39__s_annex/comment_1_9fffb1329a4a06111cf2afd8552aea62._comment
new file mode 100644
index 0000000000..94404fca37
--- /dev/null
+++ b/doc/bugs/Recreating_remote_repository__39__s_annex/comment_1_9fffb1329a4a06111cf2afd8552aea62._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmZilYULa6CDEGfuagoDlesyakBgnf-dF8"
+ nickname="Maarten"
+ subject="comment 1"
+ date="2014-05-21T22:21:37Z"
+ content="""
+I'd delete the repo and recreate it but I can't do that either - deleting works from webapp but when recreating it says there is already a repo by that name.  enableing that repo leads me to this situation again.
+"""]]
diff --git a/doc/bugs/Recreating_remote_repository__39__s_annex/comment_2_b7f5634e136294ea1a3d4ce6de58fc5d._comment b/doc/bugs/Recreating_remote_repository__39__s_annex/comment_2_b7f5634e136294ea1a3d4ce6de58fc5d._comment
new file mode 100644
index 0000000000..887fca94af
--- /dev/null
+++ b/doc/bugs/Recreating_remote_repository__39__s_annex/comment_2_b7f5634e136294ea1a3d4ce6de58fc5d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="comment 2"
+ date="2014-05-23T14:27:01Z"
+ content="""
+What are you clicking on in the webapp?
+
+What kind of repository did the remote have before it got deleted? Was it a repository encrypted with git-remote-gcrypt?
+
+Show the contents of ~/annex/.git/config on your local system.
+"""]]
diff --git a/doc/bugs/Redundant_quote_in_the_filepath_with_rsync_remote.mdwn b/doc/bugs/Redundant_quote_in_the_filepath_with_rsync_remote.mdwn
new file mode 100644
index 0000000000..71bbb75271
--- /dev/null
+++ b/doc/bugs/Redundant_quote_in_the_filepath_with_rsync_remote.mdwn
@@ -0,0 +1,49 @@
+### Please describe the problem.
+Using a rsync remote with hybrid encryption, I encounter the following problem.
+
+    $ git annex get 30.zip                                                                                                                                                                                                                                                      
+    get 30.zip (from to...) 
+    rsync: [sender] change_dir "/home/user/drive/Annex/t/eec/656/'GPGHMACSHA1--addf78b2c59182e951d16ce90e03900cfe15dc7d" failed: No such file or directory (2)
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1835) [Receiver=3.2.4]
+    rsync: [Receiver] write error: Broken pipe (32)
+    rsync exited 23
+    rsync: [sender] change_dir "/home/user/drive/Annex/t/Vk/Zj/'GPGHMACSHA1--addf78b2c59182e951d16ce90e03900cfe15dc7d" failed: No such file or directory (2)
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1835) [Receiver=3.2.4]
+    rsync: [Receiver] write error: Broken pipe (32)
+    rsync exited 23
+
+Note the extra single quote inserted in the filepath in front of the GPGHMACSHA1... folder name. I have verified that the file exists on the remote drive.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex-8.20211123-3.fc36.x86_64
+
+### Have you had any luck using git-annex before?
+
+I have used git annex with great success for better part of the decade. Thank you for all your hard work!
+
+### Extra debugging
+
+To figure out if it was really just the mangled path, I have added a symlink to pretend the variant of the folder name with the leading quote exists:
+
+    lrwxrwxrwx. 1 user user   53 May 31 20:31 "'GPGHMACSHA1--addf78b2c59182e951d16ce90e03900cfe15dc7d" -> GPGHMACSHA1--addf78b2c59182e951d16ce90e03900cfe15dc7d
+    drwxrwxr-x. 2 user user 4096 Jul 19  2020  GPGHMACSHA1--addf78b2c59182e951d16ce90e03900cfe15dc7d
+
+Now the git annex get fails with
+
+    rsync: [sender] link_stat "/home/user/drive/Annex/t/eec/656/'GPGHMACSHA1--addf78b2c59182e951d16ce90e03900cfe15dc7d/GPGHMACSHA1--addf78b2c59182e951d16ce90e03900cfe15dc7d'" failed: No such file or directory (2)
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1835) [Receiver=3.2.4]
+    rsync: [Receiver] write error: Broken pipe (32)
+
+Note that we were able to chdir into the folder now, but the file itself is not being found. This time we do not have a leading quote, but a trailing one. Adding another symlink, this time for the file:
+
+    -rw-rw-r--. 1 user user 157865953 Jul 19  2020  GPGHMACSHA1--addf78b2c59182e951d16ce90e03900cfe15dc7d
+    lrwxrwxrwx. 1 user user        53 May 31 20:42 "GPGHMACSHA1--addf78b2c59182e951d16ce90e03900cfe15dc7d'" -> GPGHMACSHA1--addf78b2c59182e951d16ce90e03900cfe15dc7d
+
+Makes this particular error go away, only to fail with
+
+    ../../../.git/annex/tmp/GPGHMACSHA1--addf78b2c59182e951d16ce90e03900cfe15dc7d: openBinaryFile: does not exist (No such file or directory)
+
+This is likely because the file has been downloaded into tmp directory with the trailing quote. To summarize, it seems that file and its parent folder in the rsync remote directory tree are being wrapped by single quotes, resulting into a file lookup failure.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Redundant_quote_in_the_filepath_with_rsync_remote/comment_1_53d3e78c0fb4d4c398dd47498e6348aa._comment b/doc/bugs/Redundant_quote_in_the_filepath_with_rsync_remote/comment_1_53d3e78c0fb4d4c398dd47498e6348aa._comment
new file mode 100644
index 0000000000..8d06f3faae
--- /dev/null
+++ b/doc/bugs/Redundant_quote_in_the_filepath_with_rsync_remote/comment_1_53d3e78c0fb4d4c398dd47498e6348aa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-06-02T15:58:10Z"
+ content="""
+This is a breakage caused by rsync 3.2.4 which broke backwards
+compatability.
+
+It is fixed in git-annex 10.20220504.
+"""]]
diff --git a/doc/bugs/Remote_repositories_have_to_be_setup_encrypted.mdwn b/doc/bugs/Remote_repositories_have_to_be_setup_encrypted.mdwn
new file mode 100644
index 0000000000..bcac962ee6
--- /dev/null
+++ b/doc/bugs/Remote_repositories_have_to_be_setup_encrypted.mdwn
@@ -0,0 +1,28 @@
+What steps will reproduce the problem?
+
+Create a new remote repository in the webapp. Get to the final phase of the setup where it asks you if you want to encrypt it, yet no other option is given to continue.
+
+What is the expected output? What do you see instead?
+
+At least two options:
+
+1. Use an encrypted rsync repository on the server (the existing one)
+2. Use an unencrypted rsync repository on the server
+
+What version of git-annex are you using? On what operating system?
+
+    $ ./git-annex version
+    git-annex version: 3.20130102
+
+    $ uname -a
+    Linux wintermute 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:45:18 UTC 2012 i686 i686 i386 GNU/Linux
+
+    $ lsb_release -a
+    Distributor ID:	Ubuntu
+    Description:	Ubuntu 12.04.1 LTS
+    Release:	12.04
+    Codename:	precise
+
+[[!meta title="webapp does not allow disabling encryption on rsync special remotes"]]
+[[!tag /design/assistant]]
+[[!tag confirmed]]
diff --git a/doc/bugs/Remote_repositories_have_to_be_setup_encrypted/comment_1_95f73315657bc35a8d3ff9b4ba207af0._comment b/doc/bugs/Remote_repositories_have_to_be_setup_encrypted/comment_1_95f73315657bc35a8d3ff9b4ba207af0._comment
new file mode 100644
index 0000000000..f54b4626b2
--- /dev/null
+++ b/doc/bugs/Remote_repositories_have_to_be_setup_encrypted/comment_1_95f73315657bc35a8d3ff9b4ba207af0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.211"
+ subject="comment 1"
+ date="2013-01-03T18:02:21Z"
+ content="""
+Specifically, this affects only rsync special remotes. All the other ones have a check box that allows enabling encryption or not. I didn't get around to adding that for rsync due to some complications in the code. Of course, you can use `git annex initremote` at the command line to set up non-encrypted rsync remotes.
+"""]]
diff --git a/doc/bugs/Remote_webapp_on_debian_stretch_not_responding.mdwn b/doc/bugs/Remote_webapp_on_debian_stretch_not_responding.mdwn
new file mode 100644
index 0000000000..9109ae3464
--- /dev/null
+++ b/doc/bugs/Remote_webapp_on_debian_stretch_not_responding.mdwn
@@ -0,0 +1,16 @@
+In a fresh repository installation on debian stretch (arm) (git-annex version: 6.20170101)
+the remote webapp will start and present the dashboard page,
+however any request made by clicking any link does not receive a response.
+
+I have a workaround: to ssh into my server and access the webapp locally using lynx browser, and that does seem to work well.
+
+It presents me with a warning:
+
+warning
+
+   WebApp crashed: xdg-open: createProcess: runInteractiveProcess: exec:
+   does not exist (No such file or directory)
+
+I'm not getting any errors, just the requests not returning responses.
+
+I'm pretty new to this software.
diff --git a/doc/bugs/Remote_webapp_on_debian_stretch_not_responding/comment_1_e2a0d0f458d263eae15640f36d59f071._comment b/doc/bugs/Remote_webapp_on_debian_stretch_not_responding/comment_1_e2a0d0f458d263eae15640f36d59f071._comment
new file mode 100644
index 0000000000..8ba6d9946b
--- /dev/null
+++ b/doc/bugs/Remote_webapp_on_debian_stretch_not_responding/comment_1_e2a0d0f458d263eae15640f36d59f071._comment
@@ -0,0 +1,59 @@
+[[!comment format=mdwn
+ username="moaxey"
+ avatar="http://cdn.libravatar.org/avatar/06abae5b84ce9bbcd39c1cbf49817d29"
+ subject="I also found this log"
+ date="2018-04-17T22:52:15Z"
+ content="""
+```
+   Here's everything that has been logged by the git-annex assistant, as
+   well as by programs it has run.
+[2018-04-17 21:55:06.712567732] main: starting assistant version 6.20170101
+[2018-04-17 21:55:06.754681296] Cronner: You should enable consistency checking
+to protect your data.
+
+  No known network monitor available through dbus; falling back to polling
+
+  No known volume monitor available through dbus; falling back to mtab polling
+(scanning...) [2018-04-17 21:55:06.920804804] Watcher: Performing startup scan
+(started...)
+WebApp crashed: unable to bind to local socket
+CallStack (from HasCallStack):
+  error, called at ./Utility/WebApp.hs:124:19 in main:Utility.WebApp
+[2018-04-17 21:55:07.19622235] WebApp: warning WebApp crashed: unable to bind to
+ local socket
+CallStack (from HasCallStack):
+  error, called at ./Utility/WebApp.hs:124:19 in main:Utility.WebApp
+[2018-04-17 21:57:06.821805552] main: starting assistant version 6.20170101
+[2018-04-17 21:57:06.858432032] Cronner: You should enable consistency checking
+to protect your data.
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2018-04-17 21:57:07.025115165] Watcher: Performing startup scan
+(started...)
+
+  No known volume monitor available through dbus; falling back to mtab polling
+WebApp crashed: unable to bind to local socket
+CallStack (from HasCallStack):
+  error, called at ./Utility/WebApp.hs:124:19 in main:Utility.WebApp
+[2018-04-17 21:57:07.243030677] WebApp: warning WebApp crashed: unable to bind t
+o local socket
+CallStack (from HasCallStack):
+  error, called at ./Utility/WebApp.hs:124:19 in main:Utility.WebApp
+[2018-04-17 21:59:07.137839178] main: starting assistant version 6.20170101
+[2018-04-17 21:59:07.177856054] Cronner: You should enable consistency checking
+to protect your data.
+
+  No known network monitor available through dbus; falling back to polling
+
+  No known volume monitor available through dbus; falling back to mtab polling
+
+(scanning...) [2018-04-17 22:24:10.365052622] Watcher: Performing startup scan
+(started...)
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+
+     Performed startup scan
+
+```
+
+"""]]
diff --git a/doc/bugs/Renamed_special_remote_cannot_be_reactivated_by_the_webapp.mdwn b/doc/bugs/Renamed_special_remote_cannot_be_reactivated_by_the_webapp.mdwn
new file mode 100644
index 0000000000..ccf6ef1caa
--- /dev/null
+++ b/doc/bugs/Renamed_special_remote_cannot_be_reactivated_by_the_webapp.mdwn
@@ -0,0 +1,30 @@
+Setup:
+
+* fresh install of Debian Wheezy with git-annex 4.20130227 pulled in from unstable
+* clone existing repository and activate assistant
+* repository has encrypted rsync remote originally setup with the name `metaarray`
+* this remote was renamed to `ma` a long time ago, using the webapp
+* had to perform this rename on each client
+
+Steps:
+
+* attempt to reactivate special remote using webapp repositories page, on reinstalled machine
+
+Expected:
+
+* special remote starts working
+* renaming special remotes ought to survive clones
+
+Actual:
+
+* firstly, special remote activation page has blank hostname box and the hostname of the machine is in the username box
+* form gives error "cannot change encryption type of existing remote"
+
+Workaround:
+
+* execute `git annex initremote metaarray`
+* rename `metaarray` to `ma` again using the webapp
+
+Perhaps the renaming of the remote not surviving clones is unavoidable, but the webapp should be able to cope with the situation.  Thanks.
+
+[[!tag /design/assistant]]
diff --git a/doc/bugs/Repo_manipulation_breaks_git-annex_drop_--all.mdwn b/doc/bugs/Repo_manipulation_breaks_git-annex_drop_--all.mdwn
new file mode 100644
index 0000000000..1c861fd5aa
--- /dev/null
+++ b/doc/bugs/Repo_manipulation_breaks_git-annex_drop_--all.mdwn
@@ -0,0 +1,58 @@
+I am working with a bare repository to transfer two keys from a custom backend to and from a special remote. This seems to be working fine.
+
+In order to be able to make use of export remotes (exporttree=yes), I need to be able to specific a tree to be exported. For technical reasons, I want to keep using a bare repository, and use a `hash-object`, `update-index`, and `write-tree` manually in order to create a tree. The Python code snippet that does this looks like this:
+
+```
+    for key, prefix, fname in (
+            # the prefixes are constant hashdir-lower
+            (RepoAnnexGitRemote.refs_key, 'a11/1c8', '.datalad/dotgit/refs'),
+            (RepoAnnexGitRemote.repo_export_key, '6b2/c13',
+             '.datalad/dotgit/repo-export.zip')):
+        # create a blob for the annex link
+        out = repo._git_runner.run(
+            ['git', 'hash-object', '-w', '--stdin'],
+            stdin=bytes(
+                f'../../.git/annex/objects/{prefix}/{key}/{key}', 'utf-8'),
+            protocol=StdOutCapture)
+        linkhash = out['stdout'].strip()
+        # place link into a tree
+        out = repo._git_runner.run(
+            ['git', 'update-index', '--add', '--cacheinfo', '120000',
+             linkhash, fname],
+            protocol=StdOutCapture)
+    # write the complete tree, and return ID
+    out = repo._git_runner.run(
+        ['git', 'write-tree'],
+        protocol=StdOutCapture)
+    exporttree = out['stdout'].strip()
+ ```
+
+It essentially creates the two blobs for the annex links, puts them together in a tree, and writes it to the repo.
+
+However, after this code ran, git-annex is not longer operating properly in the bare repo:
+
+```
+% git annex drop --all
+fatal: relative path syntax can't be used outside working tree
+fatal: relative path syntax can't be used outside working tree
+fatal: relative path syntax can't be used outside working tree
+fatal: relative path syntax can't be used outside working tree
+fatal: relative path syntax can't be used outside working tree
+fatal: relative path syntax can't be used outside working tree
+fatal: relative path syntax can't be used outside working tree
+fatal: relative path syntax can't be used outside working tree
+fatal: relative path syntax can't be used outside working tree
+fatal: relative path syntax can't be used outside working tree
+fatal: relative path syntax can't be used outside working tree
+git-annex: fd:21: Data.ByteString.hGetLine: end of file
+```
+
+(fatal error messages are from cat-file batch calls inside)
+
+When I comment this code out, everything goes back to normal. It seems to makes no difference whether I follow the problematic code up with a `commit-tree` and `update-ref` to actually have the mainline branch point to a commit with that tree. It also seems to make no difference, when I explicitly `setpresentkey <key> <here> 0`.
+
+AFAICS this creates the same records as if I would have done this in a regular worktree using high-level git-annex tooling. Other git-annex commands like `fsck` seem to be working fine. If a create a branch with that tree, also `findref` seems to be working properly.
+
+Is this a bug, or am I doing something wrong? Thanks in advance for your time!
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Repo_manipulation_breaks_git-annex_drop_--all/comment_1_22fb9214e6e31d04b0ffe3266d26ea69._comment b/doc/bugs/Repo_manipulation_breaks_git-annex_drop_--all/comment_1_22fb9214e6e31d04b0ffe3266d26ea69._comment
new file mode 100644
index 0000000000..082b7b7332
--- /dev/null
+++ b/doc/bugs/Repo_manipulation_breaks_git-annex_drop_--all/comment_1_22fb9214e6e31d04b0ffe3266d26ea69._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-11T16:25:50Z"
+ content="""
+`git update-index` creates an index file. A repo with an index file is no
+longer a bare repo to a certain extent, at least it is very unusual for a
+repo to be both bare and contain an index file, since after all an index
+file is a record of the files in the working tree. This seems to be the root
+of the confusion.
+
+I was able to reproduce this by simply copying `.git/index` from a non-bare
+repo into the bare repo and then running `git-annex drop --all`.
+
+Removing the index file was not sufficient to fix it. It turned out I also 
+needed to delete `annex/keydb*`. Then things returned to normal.
+
+So, it seems that the keys database is getting populated in a bare repo
+when there's an index file, and once the keys database is populated, it
+runs code paths that will not work in a bare repo, because that database
+contains paths (taken from the index) that it treats as being present in a
+nonexistant working tree. I've fixed it to both avoid populating the keys
+database, and ignore a populated keys database in this situation.
+
+But.. My suggestion is, if you need to do this kind of thing in a bare repo,
+set `GIT_INDEX_FILE` to some other file. That's how git-annex makes similar
+tree objects.
+"""]]
diff --git a/doc/bugs/Repo_manipulation_breaks_git-annex_drop_--all/comment_2_fac648fb7550f0c3c433ce423e3ea7f6._comment b/doc/bugs/Repo_manipulation_breaks_git-annex_drop_--all/comment_2_fac648fb7550f0c3c433ce423e3ea7f6._comment
new file mode 100644
index 0000000000..ed38f6ac40
--- /dev/null
+++ b/doc/bugs/Repo_manipulation_breaks_git-annex_drop_--all/comment_2_fac648fb7550f0c3c433ce423e3ea7f6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Thanks!"
+ date="2022-01-11T18:59:36Z"
+ content="""
+That was the missing piece for me. Thank you!
+"""]]
diff --git a/doc/bugs/Request_the_ability_to_specify_pull_commit_message.mdwn b/doc/bugs/Request_the_ability_to_specify_pull_commit_message.mdwn
new file mode 100644
index 0000000000..7c32d176b3
--- /dev/null
+++ b/doc/bugs/Request_the_ability_to_specify_pull_commit_message.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+
+There is no way to specify the commit message used by the pull command.
+
+### What steps will reproduce the problem?
+
+When pulling from a special remote with importtree=yes to get new/modified files, git-annex generates the commit message. It is desired to specify the commit message to describe the content being pulled.
+
+### What version of git-annex are you using? On what operating system?
+
+10.20231130-g0e9bc415882a5e3a285e004cf9f80936e5762a07
+Linux
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/Request_the_ability_to_specify_pull_commit_message/comment_1_6d581ea36afab3829cd56d6d6b83c6f3._comment b/doc/bugs/Request_the_ability_to_specify_pull_commit_message/comment_1_6d581ea36afab3829cd56d6d6b83c6f3._comment
new file mode 100644
index 0000000000..db1e45acc5
--- /dev/null
+++ b/doc/bugs/Request_the_ability_to_specify_pull_commit_message/comment_1_6d581ea36afab3829cd56d6d6b83c6f3._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-01-18T16:18:38Z"
+ content="""
+This would need to start with `git-annex import --from=remote` 
+getting a `--message` option. Which I've just implemented.
+
+As for adding an option to `git-annex pull`, it would need to be an option
+other than `--message`, because `git-annex sync` already uses `--message`
+for the commit message. And since `git-annex pull` can pull from more than
+one remote at a time, it seems that it would need an option that specifies
+a message plus which remote to use that message for. Or the option
+would need to only be used when using `git-annex pull` with a single
+specified remote.
+
+That seems like perhaps unncessary complexity, since if you want to import
+a tree from a remote and specify a message, you can just use 
+`git-annex import` with `--message` now. 
+And then you can run `git-annex pull` to proceed with the rest of what it does.
+
+Good enough?
+"""]]
diff --git a/doc/bugs/Request_the_ability_to_specify_pull_commit_message/comment_2_bdb4b0200ab9d7c15454a2f3fcae474c._comment b/doc/bugs/Request_the_ability_to_specify_pull_commit_message/comment_2_bdb4b0200ab9d7c15454a2f3fcae474c._comment
new file mode 100644
index 0000000000..9ede847a98
--- /dev/null
+++ b/doc/bugs/Request_the_ability_to_specify_pull_commit_message/comment_2_bdb4b0200ab9d7c15454a2f3fcae474c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jstritch"
+ avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
+ subject="comment 2"
+ date="2024-01-19T17:44:39Z"
+ content="""
+The new import option --message should do the trick.  I'll probably it up with the recommended git annex merge instead of git annex pull. Thanks!
+"""]]
diff --git a/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32.mdwn b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32.mdwn
new file mode 100644
index 0000000000..90821b161d
--- /dev/null
+++ b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32.mdwn
@@ -0,0 +1,94 @@
+### Please describe the problem.
+
+The change of resolver to LTS 19 (lts-19.16) still causes stack builds to fail on Windows
+with a plan construction problem. Pinning Win32 as `Win32-2.11.1.0` in extra-deps as
+suggested by stack is not enough to resolve the issue -- one has to go further and
+pin Win32 as `Win32-2.9.0.0` and do similarly with a few other GHC boot packages
+including `Cabal`. This setup then builds and tests just fine. I'm aware this needs to
+be probably addressed in the cabal file instead but as a user the patch below is my
+local fix for the issue.
+
+### What steps will reproduce the problem?
+
+`stack setup && stack build`. Observe the following output:
+
+[[!format sh """
+Warning: C:\Projektit\git-annex.branchable.com\git-annex--BUILD-220730-b5dc04099\stack.yaml: Unrecognized field in ProjectAndConfigMonoid: explicit-setup-deps
+
+Error: While constructing the build plan, the following exceptions were encountered:
+
+In the dependencies for git-annex-10.20220724(+assistant
++benchmark
+-dbus
+-debuglocks
++gitlfs
+-magicmime
++pairing
++production
++torrentparser
++webapp):
+    Win32-2.12.0.1 from stack configuration does not match (>=2.6.1.0 && <2.12.0.0)  (latest
+                   matching version is 2.11.1.0)
+needed since git-annex is a build target.
+
+Some different approaches to resolving this:
+
+  * Set 'allow-newer: true'
+    in C:\hs-stack\config.yaml to ignore all version constraints and build anyway.
+
+  * Recommended action: try adding the following to your extra-deps
+    in C:\Projektit\git-annex.branchable.com\git-annex--BUILD-220730-b5dc04099\stack.yaml:
+
+- Win32-2.11.1.0@sha256:f503acb4ea2e7da6433549d5ff7d0851da54f226df032b40ae51559c7914d62f,4387
+
+Plan construction failed.
+# End of transcript or log.
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20220725-gb5dc04099
+build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.11 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+"""]]
+
+A successful build that passes the testsuite is achieved with the patch to `stack.yaml` below.
+
+Windows 10 version 21H2 (build 19044.1826), 64 bit.
+
+### Please provide any additional information below.
+
+Apply the following patch to build on Windows:
+
+[[!format diff """
+diff --git a/stack.yaml b/stack.yaml
+index 8ca5d7383..94b724fe2 100644
+--- a/stack.yaml
++++ b/stack.yaml
+@@ -22,5 +22,10 @@ extra-deps:
+ - network-multicast-0.3.2
+ - sandi-0.5
+ - torrent-10000.1.1
++- Win32-2.9.0.0
++- Cabal-3.6.3.0
++- directory-1.3.7.1
++- process-1.6.14.0
++- time-1.11.1.2
+ explicit-setup-deps:
+   git-annex: true
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Git Annex is great. I use it several times a week with my multigigabyte backups, where it gives structure to my image-based backup routines, so you could say I'm a believer. :)
+
+[[!meta author=jkniiv]]
+[[!meta title="windows: Resolver lts-19.16 still causes trouble with Win32 for stack builds"]]
+
+> reverted, [[done]] --[[Joey]]
diff --git a/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_1_7fc0ffa7787353cf40fff0bc8da43c1d._comment b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_1_7fc0ffa7787353cf40fff0bc8da43c1d._comment
new file mode 100644
index 0000000000..31ef6d2c9f
--- /dev/null
+++ b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_1_7fc0ffa7787353cf40fff0bc8da43c1d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="lts version"
+ date="2022-07-31T17:25:27Z"
+ content="""
+Did the resolver change to lts-19.16? [`stack.yaml` on hackage](https://hackage.haskell.org/package/git-annex-10.20220724/src/stack.yaml) still seems to say lts-18.
+
+
+"""]]
diff --git a/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_2_0b96112c5d57886add62d79e7bf6044e._comment b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_2_0b96112c5d57886add62d79e7bf6044e._comment
new file mode 100644
index 0000000000..e62aa2a009
--- /dev/null
+++ b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_2_0b96112c5d57886add62d79e7bf6044e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 2"
+ date="2022-07-31T18:00:59Z"
+ content="""
+@Ilya: Yes, the change took place in commit [[!commit b5dc04099efd8b1bd2dbfa09a288518eabf8ceec]] which was some 24 hours after
+release 10.20220724. :)
+"""]]
diff --git a/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_3_79cafc76eb23e54ff70c72c2f528e724._comment b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_3_79cafc76eb23e54ff70c72c2f528e724._comment
new file mode 100644
index 0000000000..98083e6238
--- /dev/null
+++ b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_3_79cafc76eb23e54ff70c72c2f528e724._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-08-01T17:13:22Z"
+ content="""
+Hey, thanks and sorry for inflicting that stack change on you a second
+time. I hypothesized that the toolchain installation, that failed before,
+might have been a transient problem, and it seems it was, but now these other
+problems surface..
+
+Surprisingly, putting Win32 in the stack file does not break stack build
+on linux. But I don't like putting it in there regardless, and needing
+to downgrade the other dependencies for it is also suboptimal.
+
+I'll revert the stack.yaml change again, and it seems we'll need to wait for
+[[todo/windows__58___prepare_for_Win32_not_export_c__95___entities]]
+to be fixed before updating it.
+"""]]
diff --git a/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_4_07f1b2eacf7e9e58809ee44fc1d6b574._comment b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_4_07f1b2eacf7e9e58809ee44fc1d6b574._comment
new file mode 100644
index 0000000000..cfe2026977
--- /dev/null
+++ b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_4_07f1b2eacf7e9e58809ee44fc1d6b574._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 4"
+ date="2022-08-03T15:47:07Z"
+ content="""
+@joey: No problem. Most of my git-annex use is rather vanilla (apart from annexing huge files) so I
+don't usually need the very latest in git-annex so I can always fall back to an earlier release/build.
+It's just that I like to keep track of git-annex's development and make sure it works on Windows most
+of the time which means I feel a need to build fresh versions and then kind of dogfood them as soon
+as possible. As a non-developer being able to report build errors and other bugs is my way of taking
+part in this project and hopefully in the process help make things smoother for the Windows user constituent
+that I represent.
+
+PS. Ikiwiki broke that link you made to my related todo. What's with that? The backlink appears in the todo,
+however.
+"""]]
diff --git a/doc/bugs/Resolver_lts-19.33_still_causes_trouble_with_Win32.mdwn b/doc/bugs/Resolver_lts-19.33_still_causes_trouble_with_Win32.mdwn
new file mode 100644
index 0000000000..97428699b9
--- /dev/null
+++ b/doc/bugs/Resolver_lts-19.33_still_causes_trouble_with_Win32.mdwn
@@ -0,0 +1,426 @@
+### Please describe the problem.
+
+I'm sorry for barking up the same tree once again but the change of resolver to LTS 19 (now lts-19.33)
+still causes stack builds to fail on Windows with a plan construction problem. Joey pinned Win32 as 
+`Win32-2.11.1.0` in extra-deps and while that might be sufficient on Linux, on Windows stack seems to
+be rather picky and wants to have none of it. In fact my bumbling around with editing `stack.yaml`
+trying to placate the Haskell Stack gods has only found a single solution to the predicament and that is
+to pin Win32 as `Win32-2.9.0.0` (sic! -- due to the dependencies for `haskeline`) and do similarly with
+a few other GHC boot packages including `Cabal`. This setup then builds and tests just fine. (There is
+a patch to `stack.yaml` below.)
+
+I know `Win32-2.9.0.0` is a bit long in the tooth (although, who knows, maybe it works equally well
+for git-annex' purposes?) but I wonder do we have a choice if we want to keep aws-0.24 in the configuration?
+
+### What steps will reproduce the problem?
+
+`stack setup && stack build`. Observe the following output:
+
+[[!format sh """
+Error: [S-4804]
+       Stack failed to construct a build plan.
+
+       While constructing the build plan, Stack encountered the following errors:
+
+       In the dependencies for Glob-0.10.2:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> Glob-0.10.2
+
+       In the dependencies for Win32-notify-0.3.0.3:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> Win32-notify-0.3.0.3
+
+       In the dependencies for aeson-2.0.3.0:
+           time must match >=1.6.0.1 && <1.13, but this GHC boot package has been pruned (issue
+                #4510); you need to add the package explicitly to extra-deps (latest matching
+                version is 1.12.2)
+       needed due to git-annex-10.20230214 -> aeson-2.0.3.0
+
+       In the dependencies for alex-3.2.7.1:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> alex-3.2.7.1
+
+       In the dependencies for attoparsec-iso8601-1.0.2.1:
+           time must match >=1.6.0.1 && <1.13, but this GHC boot package has been pruned (issue
+                #4510); you need to add the package explicitly to extra-deps (latest matching
+                version is 1.12.2)
+       needed due to git-annex-10.20230214 -> attoparsec-iso8601-1.0.2.1
+
+       In the dependencies for aws-0.24:
+           directory must match >=1.0 && <2.0, but this GHC boot package has been pruned (issue
+                     #4510); you need to add the package explicitly to extra-deps (latest matching
+                     version is 1.3.8.0)
+           time must match >=1.4.0 && <2.0, but this GHC boot package has been pruned (issue
+                #4510); you need to add the package explicitly to extra-deps (latest matching
+                version is 1.12.2)
+       needed due to git-annex-10.20230214 -> aws-0.24
+
+       In the dependencies for cabal-doctest-1.0.9:
+           Cabal must match >=1.10 && <3.10, but the Stack configuration has no specified
+                 version (latest matching version is 3.8.1.0)
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> cabal-doctest-1.0.9
+
+       In the dependencies for clientsession-0.9.1.2:
+           directory must match >=1, but this GHC boot package has been pruned (issue #4510); you
+                     need to add the package explicitly to extra-deps (latest matching version is
+                     1.3.8.0)
+       needed due to git-annex-10.20230214 -> clientsession-0.9.1.2
+
+       In the dependencies for concurrent-output-1.10.16:
+           directory must match >=1.2.0 && <1.4.0, but this GHC boot package has been pruned (issue
+                     #4510); you need to add the package explicitly to extra-deps (latest matching
+                     version is 1.3.8.0)
+           process must match >=1.6.0 && <1.7.0, but this GHC boot package has been pruned (issue
+                   #4510); you need to add the package explicitly to extra-deps (latest matching
+                   version is 1.6.17.0)
+       needed due to git-annex-10.20230214 -> concurrent-output-1.10.16
+
+       In the dependencies for conduit-1.3.4.3:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> conduit-1.3.4.3
+
+       In the dependencies for conduit-extra-1.3.6:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+           process needed, but this GHC boot package has been pruned (issue #4510); you need to add
+                   the package explicitly to extra-deps (latest matching version is 1.6.17.0)
+       needed due to git-annex-10.20230214 -> conduit-extra-1.3.6
+
+       In the dependencies for cookie-0.4.5:
+           time must match >=1.5, but this GHC boot package has been pruned (issue #4510); you need
+                to add the package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> cookie-0.4.5
+
+       In the dependencies for criterion-1.5.13.0:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+           time needed, but this GHC boot package has been pruned (issue #4510); you need to add the
+                package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> criterion-1.5.13.0
+
+       In the dependencies for easy-file-0.2.2:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+           time needed, but this GHC boot package has been pruned (issue #4510); you need to add the
+                package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> easy-file-0.2.2
+
+       In the dependencies for entropy-0.4.1.10:
+           Cabal must match >=1.10 && <3.9, but the Stack configuration has no specified
+                 version (latest matching version is 3.8.1.0)
+           directory must match <1.4, but this GHC boot package has been pruned (issue #4510); you
+                     need to add the package explicitly to extra-deps (latest matching version is
+                     1.3.8.0)
+           process must match <1.7, but this GHC boot package has been pruned (issue #4510); you
+                   need to add the package explicitly to extra-deps (latest matching version is
+                   1.6.17.0)
+       needed due to git-annex-10.20230214 -> entropy-0.4.1.10
+
+       In the dependencies for fast-logger-3.1.1:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> fast-logger-3.1.1
+
+       In the dependencies for feed-1.3.2.1:
+           time must match <1.12, but this GHC boot package has been pruned (issue #4510); you need
+                to add the package explicitly to extra-deps (latest matching version is 1.11.1.2)
+       needed due to git-annex-10.20230214 -> feed-1.3.2.1
+
+       In the dependencies for file-embed-0.0.15.0:
+           directory must match >=1.0.0.3, but this GHC boot package has been pruned (issue
+                     #4510); you need to add the package explicitly to extra-deps (latest matching
+                     version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> file-embed-0.0.15.0
+
+       In the dependencies for git-annex-10.20230214(+assistant
+       +benchmark
+       -dbus
+       -debuglocks
+       +gitlfs
+       -magicmime
+       +pairing
+       +production
+       +torrentparser):
+           Cabal must match <4.0, but the Stack configuration has no specified version (latest
+                 matching version is 3.8.1.0)
+           directory must match >=1.2.7.0, but this GHC boot package has been pruned (issue
+                     #4510); you need to add the package explicitly to extra-deps (latest matching
+                     version is 1.3.8.0)
+           process must match >=1.6.3, but this GHC boot package has been pruned (issue #4510); you
+                   need to add the package explicitly to extra-deps (latest matching version is
+                   1.6.17.0)
+           time must match >=1.5.0, but this GHC boot package has been pruned (issue #4510); you
+                need to add the package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed since git-annex is a build target.
+
+       In the dependencies for haskeline-0.8.2:
+           Win32-2.11.1.0 from Stack configuration does not match >=2.1 && <2.10 || >=2.12 (latest
+                          matching version is 2.13.4.0)
+           directory must match >=1.1 && <1.4, but this GHC boot package has been pruned (issue
+                     #4510); you need to add the package explicitly to extra-deps (latest matching
+                     version is 1.3.8.0)
+           process must match >=1.0 && <1.7, but this GHC boot package has been pruned (issue
+                   #4510); you need to add the package explicitly to extra-deps (latest matching
+                   version is 1.6.17.0)
+       needed due to git-annex-10.20230214 -> haskeline-0.8.2
+
+       In the dependencies for http-client-0.7.13.1:
+           time must match >=1.2, but this GHC boot package has been pruned (issue #4510); you need
+                to add the package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> http-client-0.7.13.1
+
+       In the dependencies for http-date-0.0.11:
+           time needed, but this GHC boot package has been pruned (issue #4510); you need to add the
+                package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> http-date-0.0.11
+
+       In the dependencies for libyaml-0.1.2:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> libyaml-0.1.2
+
+       In the dependencies for microstache-1.0.2.2:
+           directory must match >=1.1.0.2 && <1.4, but this GHC boot package has been pruned (issue
+                     #4510); you need to add the package explicitly to extra-deps (latest matching
+                     version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> microstache-1.0.2.2
+
+       In the dependencies for mwc-random-0.15.0.2:
+           time needed, but this GHC boot package has been pruned (issue #4510); you need to add the
+                package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> mwc-random-0.15.0.2
+
+       In the dependencies for network-3.1.2.7:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> network-3.1.2.7
+
+       In the dependencies for optparse-applicative-0.16.1.0:
+           process must match >=1.0 && <1.7, but this GHC boot package has been pruned (issue
+                   #4510); you need to add the package explicitly to extra-deps (latest matching
+                   version is 1.6.17.0)
+       needed due to git-annex-10.20230214 -> optparse-applicative-0.16.1.0
+
+       In the dependencies for path-pieces-0.2.1:
+           time needed, but this GHC boot package has been pruned (issue #4510); you need to add the
+                package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> path-pieces-0.2.1
+
+       In the dependencies for persistent-2.13.3.5:
+           time must match >=1.6, but this GHC boot package has been pruned (issue #4510); you need
+                to add the package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> persistent-2.13.3.5
+
+       In the dependencies for persistent-sqlite-2.13.1.0:
+           time needed, but this GHC boot package has been pruned (issue #4510); you need to add the
+                package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> persistent-sqlite-2.13.1.0
+
+       In the dependencies for resource-pool-0.2.3.2:
+           time needed, but this GHC boot package has been pruned (issue #4510); you need to add the
+                package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> resource-pool-0.2.3.2
+
+       In the dependencies for shakespeare-2.0.30:
+           directory must match >=1.2, but this GHC boot package has been pruned (issue #4510); you
+                     need to add the package explicitly to extra-deps (latest matching version is
+                     1.3.8.0)
+           process must match >=1.0, but this GHC boot package has been pruned (issue #4510); you
+                   need to add the package explicitly to extra-deps (latest matching version is
+                   1.6.17.0)
+           time must match >=1, but this GHC boot package has been pruned (issue #4510); you need to
+                add the package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> shakespeare-2.0.30
+
+       In the dependencies for silently-1.2.5.3:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> silently-1.2.5.3
+
+       In the dependencies for streaming-commons-0.2.2.5:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+           process needed, but this GHC boot package has been pruned (issue #4510); you need to add
+                   the package explicitly to extra-deps (latest matching version is 1.6.17.0)
+       needed due to git-annex-10.20230214 -> streaming-commons-0.2.2.5
+
+       In the dependencies for terminal-size-0.3.3:
+           process needed, but this GHC boot package has been pruned (issue #4510); you need to add
+                   the package explicitly to extra-deps (latest matching version is 1.6.17.0)
+       needed due to git-annex-10.20230214 -> terminal-size-0.3.3
+
+       In the dependencies for th-compat-0.1.4:
+           directory must match >=1.1.0.0 && <1.4, but this GHC boot package has been pruned (issue
+                     #4510); you need to add the package explicitly to extra-deps (latest matching
+                     version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> th-compat-0.1.4
+
+       In the dependencies for time-compat-1.9.6.1:
+           time must
+                match >=1.5 && <1.7 || >=1.8 && <1.9 || >=1.9.2 && <1.9.4 || >=1.10 && <1.10.1 || >=1.11 && <1.11.2 || >=1.12 && <1.13,
+                but this GHC boot package has been pruned (issue #4510); you need to add the package
+                explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> time-compat-1.9.6.1
+
+       In the dependencies for time-locale-compat-0.1.1.5(-old-locale):
+           time must match >=1.5, but this GHC boot package has been pruned (issue #4510); you need
+                to add the package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> time-locale-compat-0.1.1.5
+
+       In the dependencies for typed-process-0.2.10.1:
+           process must match >=1.2, but this GHC boot package has been pruned (issue #4510); you
+                   need to add the package explicitly to extra-deps (latest matching version is
+                   1.6.17.0)
+       needed due to git-annex-10.20230214 -> typed-process-0.2.10.1
+
+       In the dependencies for unix-compat-0.5.4:
+           directory must match >=1.2 && <1.4, but this GHC boot package has been pruned (issue
+                     #4510); you need to add the package explicitly to extra-deps (latest matching
+                     version is 1.3.8.0)
+           time must match >=1.0 && <1.13, but this GHC boot package has been pruned (issue
+                #4510); you need to add the package explicitly to extra-deps (latest matching
+                version is 1.12.2)
+       needed due to git-annex-10.20230214 -> unix-compat-0.5.4
+
+       In the dependencies for unliftio-0.2.23.0:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+           process must match >=1.2.0.0, but this GHC boot package has been pruned (issue
+                   #4510); you need to add the package explicitly to extra-deps (latest matching
+                   version is 1.6.17.0)
+           time needed, but this GHC boot package has been pruned (issue #4510); you need to add the
+                package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> unliftio-0.2.23.0
+
+       In the dependencies for uuid-1.3.15:
+           time must match >=1.4 && <1.13, but this GHC boot package has been pruned (issue
+                #4510); you need to add the package explicitly to extra-deps (latest matching
+                version is 1.12.2)
+       needed due to git-annex-10.20230214 -> uuid-1.3.15
+
+       In the dependencies for wai-app-static-3.1.7.4:
+           directory must match >=1.0.1, but this GHC boot package has been pruned (issue
+                     #4510); you need to add the package explicitly to extra-deps (latest matching
+                     version is 1.3.8.0)
+           time must match >=1.1.4, but this GHC boot package has been pruned (issue #4510); you
+                need to add the package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> wai-app-static-3.1.7.4
+
+       In the dependencies for wai-extra-3.1.12.1:
+           directory must match >=1.2.7.0, but this GHC boot package has been pruned (issue
+                     #4510); you need to add the package explicitly to extra-deps (latest matching
+                     version is 1.3.8.0)
+           time must match >=1.1.4, but this GHC boot package has been pruned (issue #4510); you
+                need to add the package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> wai-extra-3.1.12.1
+
+       In the dependencies for wai-logger-2.4.0:
+           Cabal needed, but the Stack configuration has no specified version (latest matching
+                 version is 3.8.1.0)
+       needed due to git-annex-10.20230214 -> wai-logger-2.4.0
+
+       In the dependencies for warp-3.3.21:
+           time needed, but this GHC boot package has been pruned (issue #4510); you need to add the
+                package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> warp-3.3.21
+
+       In the dependencies for x509-store-1.6.9:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> x509-store-1.6.9
+
+       In the dependencies for x509-system-1.6.7:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+           process needed, but this GHC boot package has been pruned (issue #4510); you need to add
+                   the package explicitly to extra-deps (latest matching version is 1.6.17.0)
+       needed due to git-annex-10.20230214 -> x509-system-1.6.7
+
+       In the dependencies for xml-conduit-1.9.1.1:
+           Cabal needed, but the Stack configuration has no specified version (latest matching
+                 version is 3.8.1.0)
+       needed due to git-annex-10.20230214 -> xml-conduit-1.9.1.1
+
+       In the dependencies for yaml-0.11.8.0:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> yaml-0.11.8.0
+
+       In the dependencies for yesod-1.6.2.1:
+           directory needed, but this GHC boot package has been pruned (issue #4510); you need to
+                     add the package explicitly to extra-deps (latest matching version is 1.3.8.0)
+       needed due to git-annex-10.20230214 -> yesod-1.6.2.1
+
+       In the dependencies for yesod-core-1.6.24.0:
+           time must match >=1.5, but this GHC boot package has been pruned (issue #4510); you need
+                to add the package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> yesod-core-1.6.24.0
+
+       In the dependencies for yesod-form-1.7.3:
+           time must match >=1.1.4, but this GHC boot package has been pruned (issue #4510); you
+                need to add the package explicitly to extra-deps (latest matching version is 1.12.2)
+       needed due to git-annex-10.20230214 -> yesod-form-1.7.3
+
+       In the dependencies for yesod-static-1.6.1.0:
+           directory must match >=1.0, but this GHC boot package has been pruned (issue #4510); you
+                     need to add the package explicitly to extra-deps (latest matching version is
+                     1.3.8.0)
+           process needed, but this GHC boot package has been pruned (issue #4510); you need to add
+                   the package explicitly to extra-deps (latest matching version is 1.6.17.0)
+       needed due to git-annex-10.20230214 -> yesod-static-1.6.1.0
+
+# End of transcript or log.
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20230215-g648e59cac
+build flags: Assistant Webapp Pairing TorrentParser Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+"""]]
+
+A successful build that passes the testsuite on Windows is achieved with the patch to `stack.yaml` below.
+
+Windows 10 version 22H2 (build 19045.2486), 64 bit.
+
+### Please provide any additional information below.
+
+Apply the following patch to build on Windows:
+
+[[!format diff """
+diff --git a/stack.yaml b/stack.yaml
+index c7fb4b099..f6a5e06e9 100644
+--- a/stack.yaml
++++ b/stack.yaml
+@@ -21,4 +21,8 @@ extra-deps:
+ - network-multicast-0.3.2
+ - sandi-0.5
+ - torrent-10000.1.1
+-- Win32-2.11.1.0
++- Win32-2.9.0.0
++- Cabal-3.6.3.0
++- directory-1.3.7.1
++- process-1.6.17.0
++- time-1.11.1.2
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Git Annex is great. I use it several times a week with my multigigabyte backups, where it gives structure to my image-based backup routines, so you could say I'm a believer. :)
+
+[[!meta author=jkniiv]]
+[[!meta title="windows: Resolver lts-19.33 still (!) causes trouble with Win32 for stack builds"]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Resolver_lts-19.33_still_causes_trouble_with_Win32/comment_1_dcc2067ea1bc26510d013ca52096513f._comment b/doc/bugs/Resolver_lts-19.33_still_causes_trouble_with_Win32/comment_1_dcc2067ea1bc26510d013ca52096513f._comment
new file mode 100644
index 0000000000..d648bcb32a
--- /dev/null
+++ b/doc/bugs/Resolver_lts-19.33_still_causes_trouble_with_Win32/comment_1_dcc2067ea1bc26510d013ca52096513f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-02-20T19:12:19Z"
+ content="""
+Drat. The problem is haskeline-0.8.2 depending on a different Win32
+version. I'll take your word for it that was the only dependency solution
+though.
+
+Win32-2.9.0.0 is quite old and I don't want to risk reverting to some bug
+fixed in the meantime. And I'm doubtful about bumping Cabal and directory
+to newer versions too.
+
+So, I've reverted this attempt, and won't make another one until there's a
+ghc release that has the filepath (>=1.4.100.0) that Wind32 needs.
+Shouldn't be more than half a year or so..
+"""]]
diff --git a/doc/bugs/Resource_exhausted.mdwn b/doc/bugs/Resource_exhausted.mdwn
new file mode 100644
index 0000000000..3f125b08aa
--- /dev/null
+++ b/doc/bugs/Resource_exhausted.mdwn
@@ -0,0 +1,45 @@
+What steps will reproduce the problem?
+My annex dir has 23459 files and uses 749MB disk space.
+Just create a repository put this dir inside, and git-annex will crash.
+
+What is the expected output? What do you see instead?
+I expect git-annex handles large number of files, and does not watch every single file of it.
+
+What version of git-annex are you using? On what operating system?
+I'm using git-annex linux build, version 2013.04.17.
+
+Please provide any additional information below.
+
+    [2013-04-17 23:52:35 CEST] Transferrer: Downloaded pappas_hu..di_44.jpg
+    git-annex: runInteractiveProcess: pipe: Too many open files
+    Committer crashed: lsof: createProcess: resource exhausted (Too many open files)
+    [2013-04-17 23:53:52 CEST] Committer: warning Committer crashed: lsof: createProcess: resource exhausted (Too many open files)
+    git-annex: runInteractiveProcess: pipe: Too many open files
+    git: createProcess: resource exhausted (Too many open files)
+    DaemonStatus crashed: /home/user/Desktop/down/annex_test/.git/annex/daemon.status.tmp21215: openFile: resource exhausted (Too many open files)
+    [2013-04-17 23:57:24 CEST] DaemonStatus: warning DaemonStatus crashed: /home/user/Desktop/down/annex_test/.git/annex/daemon.status.tmp21215: openFile: resource exhausted (Too many open files)
+    git-annex: runInteractiveProcess: pipe: Too many open files
+    git: createProcess: resource exhausted (Too many open files)
+    git-annex: runInteractiveProcess: pipe: Too many open files
+    NetWatcherFallback crashed: git: createProcess: resource exhausted (Too many open files)
+    [2013-04-18 00:27:17 CEST] NetWatcherFallback: warning NetWatcherFallback crashed: git: createProcess: resource exhausted (Too many open files)
+    git-annex: runInteractiveProcess: pipe: Too many open files
+    git-annex: git: createProcess: resource exhausted (Too many open files)
+    git-annex: accept: resource exhausted (Too many open files)
+
+Instead of raising system's limit (which is a neverending story), can we make git-annex only watch a directory and not every file of it?
+
+Or could the user specify some directory which he knows it is rarely change, to not be watched only check it once a day?
+
+The best would be if git annex could automatically adapt itself.
+Ie. it watches eg. 200 files, and if some of it does not change for three days, then it drops from the watching basket, and those who changed (noticed while sanity checked) it adds to the basket.
+
+I don't really want to raise the ulimit, because my ultimate goal is to have git-annex on multiple raspberry pi with external harddrive (one at my home, one at my mom's home, one at my friends home, etc, etc). And raspberry is fairly low on resource.
+
+I'm interested in your thoughts.
+
+Best, 
+ Laszlo
+
+[[!tag /design/assistant]]
+[[!meta title="assistant can try to add too many files at once in batch add mode"]]
diff --git a/doc/bugs/Resource_exhausted/comment_10_bccf9528ffe963154c92ce49762e7ea6._comment b/doc/bugs/Resource_exhausted/comment_10_bccf9528ffe963154c92ce49762e7ea6._comment
new file mode 100644
index 0000000000..da2a15ba2a
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_10_bccf9528ffe963154c92ce49762e7ea6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 10"
+ date="2013-08-26T18:33:40Z"
+ content="""
+@Joey: it was a \"pretty large\" transfer, several hundred gigabytes in perhaps ~100000 files.  The copying was going to a GPG-encrypted directory remote.
+The error only happened once or twice so far.  Point taken about find in /proc; I'll do that if it happens next time.
+
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_11_24ad3a76a25a787ac59e2c5270709e72._comment b/doc/bugs/Resource_exhausted/comment_11_24ad3a76a25a787ac59e2c5270709e72._comment
new file mode 100644
index 0000000000..9cf8d04e01
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_11_24ad3a76a25a787ac59e2c5270709e72._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 11"
+ date="2013-12-16T17:20:34Z"
+ content="""
+I now understand the problem described in comment 6, where once it started failing, it would leak one file descriptor per failure.
+
+I think that failure mode was fixed by accident in the changes in [[!commit 2fd63f3cfac705f0a18f4bcbe0489ce8ea1800d7]].
+
+This doesn't explain what would open so many files to get it into that failure mode, however.
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_12_1943ff77f3bccf885229ecc10c82399d._comment b/doc/bugs/Resource_exhausted/comment_12_1943ff77f3bccf885229ecc10c82399d._comment
new file mode 100644
index 0000000000..a2b82023dc
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_12_1943ff77f3bccf885229ecc10c82399d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkipQLNyt8RHREHpg2k5wdYeRSCCvSNSBg"
+ nickname="Tim"
+ subject="Having &quot;too many open files&quot; message show up"
+ date="2014-01-13T14:57:11Z"
+ content="""
+This is happening to me now about twice per day.  I've got a repo that is completely synced already and I'm working on a project in IntelliJ.  When I check git-annex I often see this message when it is doing a startup scan or consistency check.
+
+The message can be seen here: http://imgur.com/Xb4LA73
+
+Are there logs somewhere that I can gather and supply to you to help track this down?  I'm using the 2014-01-07 release of git-annex for Mac OS.
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_13_c3cac0717232e04e89df62efa1db0870._comment b/doc/bugs/Resource_exhausted/comment_13_c3cac0717232e04e89df62efa1db0870._comment
new file mode 100644
index 0000000000..5e8ca65f13
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_13_c3cac0717232e04e89df62efa1db0870._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkipQLNyt8RHREHpg2k5wdYeRSCCvSNSBg"
+ nickname="Tim"
+ subject="Happened four times yesterday"
+ date="2014-01-14T14:33:02Z"
+ content="""
+Maybe you can e-mail me and we can discuss this?
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_1_a5ef7a62d4ed9365f9448520bb17e3b5._comment b/doc/bugs/Resource_exhausted/comment_1_a5ef7a62d4ed9365f9448520bb17e3b5._comment
new file mode 100644
index 0000000000..9bd4b0779f
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_1_a5ef7a62d4ed9365f9448520bb17e3b5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 1"
+ date="2013-04-18T06:20:13Z"
+ content="""
+Once resource exhausted git-annex has git [defunct] process too. 
+
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_2_cdba2015e603f3c21f3e1697dd6fafcd._comment b/doc/bugs/Resource_exhausted/comment_2_cdba2015e603f3c21f3e1697dd6fafcd._comment
new file mode 100644
index 0000000000..fb0f4c16b1
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_2_cdba2015e603f3c21f3e1697dd6fafcd._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-04-23T19:44:04Z"
+ content="""
+I have tried repeatedly to reproduce this problem, and I cannot. 
+
+git-annex does *not* keep every file open. It tends to have less than 10 open file descriptors at any one time.
+
+I thought perhaps `lsof` opened every file, but it does not seem to, either.
+
+So far, I have no indication that the problem had to do with git-annex at all. If some other program on the system opened a great many files, it could cause this to happen to git-annex.
+
+You pasted a debug log that shows that the problem persisted for several minutes. So you should make it happen again, and in that time period, investigate what program has so many files open. You can do this with lsof, or, if lsof won't run, by looking in /proc/$pid/fd/
+
+Or, of course, give me enough information to reproduce the problem. \"I have 23459 files\" isn't much help..
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_3_747d16d050fdcf69dd3d2bc5ca469a2e._comment b/doc/bugs/Resource_exhausted/comment_3_747d16d050fdcf69dd3d2bc5ca469a2e._comment
new file mode 100644
index 0000000000..07badd83a7
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_3_747d16d050fdcf69dd3d2bc5ca469a2e._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="I just reproduced this"
+ date="2013-07-26T23:37:26Z"
+ content="""
+On openSUSE 12.3 with this version (which I'm sure is horribly old):
+
+    git-annex version: 4.20130314
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3 4
+    upgrade supported from repository versions: 0 1 2
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS
+
+I ran 'git annex get' on a large repository, and got this:
+
+    [snipped]
+    git-annex: /home/adam/music/.git/annex/transfer/failed/download/9c930baf-6b25-4294-b1f9-a90ba9663fb7/SHA1-s7227476--49d203960b062ec00c0d1d7042c4b6aa6720b976: openFile: resource exhausted (Too many open files)
+    failed
+    git-annex: runInteractiveProcess: pipe: Too many open files
+
+    git-annex: git: runInteractiveProcess: resource exhausted (Too many open files)
+    failed
+    git-annex: get: 1207 failed
+
+Then I ran it again and saw that after every file retrieved, git-annex leaks another lockfile.  lsof shows an ever increasing number of files like this:
+
+    [snipped]
+    git-annex 32498 adam   86rR  REG  253,3        0   787353 /home/adam/music/.git/annex/ssh/adam@atlantic.lock
+    git-annex 32498 adam   87rR  REG  253,3        0   787353 /home/adam/music/.git/annex/ssh/adam@atlantic.lock
+    git-annex 32498 adam   88rR  REG  253,3        0   787353 /home/adam/music/.git/annex/ssh/adam@atlantic.lock
+    git-annex 32498 adam   89rR  REG  253,3        0   787353 /home/adam/music/.git/annex/ssh/adam@atlantic.lock
+    git-annex 32498 adam   90rR  REG  253,3        0   787353 /home/adam/music/.git/annex/ssh/adam@atlantic.lock
+    git-annex 32498 adam   91rR  REG  253,3        0   787353 /home/adam/music/.git/annex/ssh/adam@atlantic.lock
+    git-annex 32498 adam   92rR  REG  253,3        0   787353 /home/adam/music/.git/annex/ssh/adam@atlantic.lock
+    git-annex 32498 adam   93r  FIFO    0,8      0t0 28752703 pipe
+    git-annex 32498 adam   94r  FIFO    0,8      0t0 28765910 pipe
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_4_1e9b74e60da57c3d5f08c1eb3801c1d2._comment b/doc/bugs/Resource_exhausted/comment_4_1e9b74e60da57c3d5f08c1eb3801c1d2._comment
new file mode 100644
index 0000000000..eee206168f
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_4_1e9b74e60da57c3d5f08c1eb3801c1d2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 4"
+ date="2013-07-28T00:23:08Z"
+ content="""
+Hmm, Adam your version is older than the bug reporter's version. OTOH, while there were several FD leak fixes after your version, none of them were to Annex.LockPool, which is what's used for the ssh lock files.
+
+I can't reproduce it with `git annex get` and the current release.. can you?
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_5_f55d933bce77fd2185ebd0cc46fe57ec._comment b/doc/bugs/Resource_exhausted/comment_5_f55d933bce77fd2185ebd0cc46fe57ec._comment
new file mode 100644
index 0000000000..19bcdb3763
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_5_f55d933bce77fd2185ebd0cc46fe57ec._comment
@@ -0,0 +1,64 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="I just reproduced this with the latest version"
+ date="2013-08-11T03:17:11Z"
+ content="""
+At some point during a large copy, there's an ever increasing number of pipes in /proc/git-annex-pid/fd
+As soon as it hits the limit (1023 in my case), copies start failing
+
+    etc
+    r-x------ 1 michael michael 64 Aug 10 20:14 851 -> pipe:[2250609]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 852 -> pipe:[2251549]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 853 -> pipe:[2251550]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 854 -> pipe:[2250612]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 855 -> pipe:[2250613]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 856 -> pipe:[2246639]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 857 -> pipe:[2246640]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 858 -> pipe:[2246642]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 859 -> pipe:[2246643]
+    l-wx------ 1 michael michael 64 Aug 10 20:13 86 -> pipe:[2241378]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 860 -> pipe:[2246645]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 861 -> pipe:[2246646]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 862 -> pipe:[2246648]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 863 -> pipe:[2246649]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 864 -> pipe:[2246653]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 865 -> pipe:[2246654]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 866 -> pipe:[2249407]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 867 -> pipe:[2251789]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 868 -> pipe:[2250627]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 869 -> pipe:[2250628]
+    lr-x------ 1 michael michael 64 Aug 10 20:13 87 -> pipe:[2241379]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 870 -> pipe:[2251778]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 871 -> pipe:[2251779]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 872 -> pipe:[2251781]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 873 -> pipe:[2251782]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 874 -> pipe:[2250635]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 875 -> pipe:[2250636]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 876 -> pipe:[2251575]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 877 -> pipe:[2251576]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 878 -> pipe:[2251785]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 879 -> pipe:[2251786]
+    l-wx------ 1 michael michael 64 Aug 10 20:13 88 -> pipe:[2247853]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 880 -> pipe:[2249430]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 881 -> pipe:[2249431]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 882 -> pipe:[2251581]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 883 -> pipe:[2251582]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 884 -> pipe:[2250653]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 885 -> pipe:[2250654]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 886 -> pipe:[2251790]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 887 -> pipe:[2250670]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 888 -> pipe:[2250663]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 889 -> pipe:[2250664]
+    lr-x------ 1 michael michael 64 Aug 10 20:13 89 -> pipe:[2247854]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 890 -> pipe:[2250668]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 891 -> pipe:[2250669]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 892 -> pipe:[2250671]
+    l-wx------ 1 michael michael 64 Aug 10 20:14 894 -> pipe:[2251601]
+    lr-x------ 1 michael michael 64 Aug 10 20:14 895 -> pipe:[2251602]
+    lr-x------ 1 michael michael 64 Aug 10 20:13 9 -> pipe:[2241268]
+    lr-x------ 1 michael michael 64 Aug 10 20:13 90 -> pipe:[2242273]
+    l-wx------ 1 michael michael 64 Aug 10 20:13 91 -> pipe:[2245776]
+    etc
+
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_6_26c98fca45b029a527f9684873db4be5._comment b/doc/bugs/Resource_exhausted/comment_6_26c98fca45b029a527f9684873db4be5._comment
new file mode 100644
index 0000000000..b95b6cfa28
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_6_26c98fca45b029a527f9684873db4be5._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 6"
+ date="2013-08-11T03:20:37Z"
+ content="""
+with every
+
+    git annex
+    copy blah/blah/blah (to testremote...) 
+    git-annex: runInteractiveProcess: pipe: Too many open files
+    failed
+
+The number of open fd's by git-annex increases by 1.
+
+4.20130802 built with cabal on Ubuntu 13.04
+
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_7_8bab413b472f900e04977db2bc3951b6._comment b/doc/bugs/Resource_exhausted/comment_7_8bab413b472f900e04977db2bc3951b6._comment
new file mode 100644
index 0000000000..1b050aa333
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_7_8bab413b472f900e04977db2bc3951b6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 7"
+ date="2013-08-11T03:21:45Z"
+ content="""
+...increases in the failing case, that is. This doesn't happen all the time.
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_8_e9bec0b80179b1229b6af0979a21c727._comment b/doc/bugs/Resource_exhausted/comment_8_e9bec0b80179b1229b6af0979a21c727._comment
new file mode 100644
index 0000000000..2135211cd6
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_8_e9bec0b80179b1229b6af0979a21c727._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 8"
+ date="2013-08-11T20:44:19Z"
+ content="""
+It also looks like the location log has got corrupted (files are actually present, but not recorded in the location log) somewhere along the lines as I was trying to get/drop to figure out what's going on.
+Explicitly dropping files then getting files fixes the location log issue.
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_9_419e24e0b91f569294ece28c42daa246._comment b/doc/bugs/Resource_exhausted/comment_9_419e24e0b91f569294ece28c42daa246._comment
new file mode 100644
index 0000000000..0e06f5af92
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_9_419e24e0b91f569294ece28c42daa246._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 9"
+ date="2013-08-24T19:10:21Z"
+ content="""
+@Michael how large a copy are you doing? And what kind of remote are you copying the files to?
+It would be helpful if you could be more specific about something I could do to reproduce the problem. Without a test case, I am unlikely to fix the bug. With a test case, I'd be surprised if it took long to fix it.
+
+If you have a process running that is experiencing the problem, you can also narrow it down a *lot* by looking at what these leaking pipe file descriptors are pipes to.  For example, if you have:
+
+lr-x------ 1 michael michael 64 Aug 10 20:14 895 -> pipe:[2251602]
+
+You can run `find /proc/ -ls 2251602` and find the process at other end of the pipe, and look its pid up in ps to see what command it is.
+"""]]
diff --git a/doc/bugs/Resource_temporarily_unavailable_when_running_enableremote.mdwn b/doc/bugs/Resource_temporarily_unavailable_when_running_enableremote.mdwn
new file mode 100644
index 0000000000..071782d518
--- /dev/null
+++ b/doc/bugs/Resource_temporarily_unavailable_when_running_enableremote.mdwn
@@ -0,0 +1,23 @@
+### Please describe the problem.
+
+enableremote gives this weird error when trying to change settings on the s3 remote:
+
+<pre>
+$ git annex enableremote s3
+enableremote s3
+git-annex: .git/annex/creds/SOME-LONG-HASH-I-AM-NOT-SURE-SHOULD-BE-PUBLIC: openFile: resource exhausted (Resource temporarily unavailable)
+failed
+git-annex: enableremote: 1 failed
+</pre>
+
+### What steps will reproduce the problem?
+
+Unclear. I tried to update to the latest neurodebian packages to make use of the new [[tips/public_Amazon_S3_remote]] but it seems something is going wrong here.
+
+The git-annex repository is on a "persistent amazon volume" (EBS, presumably?) so there may be something fishy with the filesystem there... 
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150610+gitg608172f-1~ndall+1 on Ubuntu precise, in amazon EC2. --[[anarcat]]
+
+A workaround is to run this on a different machine. I suspect some amazon foul play at hand... so this could be invalid. :(
diff --git a/doc/bugs/Resource_temporarily_unavailable_when_running_enableremote/comment_1_14a5135c2e822129972feb570e453bc8._comment b/doc/bugs/Resource_temporarily_unavailable_when_running_enableremote/comment_1_14a5135c2e822129972feb570e453bc8._comment
new file mode 100644
index 0000000000..6fce74e31f
--- /dev/null
+++ b/doc/bugs/Resource_temporarily_unavailable_when_running_enableremote/comment_1_14a5135c2e822129972feb570e453bc8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T15:45:13Z"
+ content="""
+So it's writing the creds file that's failing. The only thing unusual
+about this file write is that it's done with a umask of 0077.
+
+Seeing what strace has to say about it would probably be useful..
+"""]]
diff --git a/doc/bugs/S3_ACL_deprecation.mdwn b/doc/bugs/S3_ACL_deprecation.mdwn
new file mode 100644
index 0000000000..b000f20c3c
--- /dev/null
+++ b/doc/bugs/S3_ACL_deprecation.mdwn
@@ -0,0 +1,158 @@
+### Please describe the problem.
+
+Amazon has [deprecated ACLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html)
+
+> A majority of modern use cases in Amazon S3 no longer require the use of ACLs, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually. With Object Ownership, you can disable ACLs and rely on policies for access control. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies.
+
+They are encouraging everyone to [migrate to bucket policies](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-ownership-migrating-acls-prerequisites.html) instead.
+
+But if such a bucket is public (meaning: write needs credentials, reads are open to the world):
+
+* `public=yes` causes `git annex copy --to` to always set an ACL, which fails, which fails the entire upload
+* But setting `public=no` causes `publicurl` to be ignored by `git annex copy --from`, failing the download
+
+#### Feature Request
+
+
+* If `public=yes`, instead of trying to set an ACL, first try `HTTP HEAD` on the newly uploaded object without using the AWS credentials. Only if that fails, fall over to trying to set an ACL using credential. And if you get AccessControlListNotSupported (i.e. the error due to BucketOwnerEnforced), then give a warning that the bucket policy is not configured for public access.
+* Make `publicurl` orthogonal to `public`: if set, `git annex copy --from` should _always_ use it unconditionally. 
+* Update [the docs here](https://git-annex.branchable.com/special_remotes/S3/) to explain how to set up a public bucket policy as recommended by Amazon, and that `public=yes` will either try to confirm that the bucket policy is public, or will fallback to using (legacy) ACLs.
+
+
+### What steps will reproduce the problem?
+
+In a bucket I run, I reset the ACLs on that bucket to Amazon's default permissions:
+
+* Bucket owner (your AWS account):
+  * Objects:
+    * List
+    * Write
+  * Bucket ACL (i.e. what ACLs are applied by default to all objects):
+    * Read
+    * Write
+
+and with that set Amazon let me also set
+
+>    Object ownership: Bucket owner enforced
+
+
+This should be the **default configuration** for any new bucket created now, so you only need to do the above if you're migrating an existing bucket like I was; for reproducing, just creating an empty bucket should be enough.
+
+It should look like this:
+
+[[!img S3_bucket.png align="right" size="" alt=""]]
+
+With that in place, I wrote and attached this Bucket Policy to make it public:
+
+```
+{
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Effect": "Allow",
+            "Principal": "*",
+            "Action": "s3:GetObject",
+            "Resource": [
+                "arn:aws:s3:::BUCKET-NAME",
+                "arn:aws:s3:::BUCKET-NAME/*"
+            ]
+        }
+    ]
+}
+```
+
+[[!img S3_bucket-perms.png align="right" size="" alt=""]]
+
+
+I told `git-annex` about it with
+
+```
+git annex initremote amazon type=S3 bucket=BUCKET_NAME public=yes publicurl=https://BUCKET_NAME.s3.amazonaws.com autoenable=true
+```
+
+But, attempting to use the new setup failed:
+
+```
+$ git annex copy --to amazon what.nii.gz 
+copy what.nii.gz (checking amazon...) (to amazon...) 
+41%   8.15 MiB         20 MiB/s 0s
+  S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, s3ErrorCode = "AccessControlListNotSupported", s3ErrorMessage = "The bucket does not allow ACLs", s3ErrorResource = Nothing, s3ErrorHostId = Just "a6+ieujj4z3Z4P8ooA306DdbGAoxWDiXd6O2ZwjdfapGnuOGPyL5/WQ4UBEytR80FG+5b6xdlsM=", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+
+32%   6.43 MiB         16 MiB/s 0s 
+  S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, s3ErrorCode = "AccessControlListNotSupported", s3ErrorMessage = "The bucket does not allow ACLs", s3ErrorResource = Nothing, s3ErrorHostId = Just "bFOgMomROCOes9yI6HZHysQGoZaTbsPI5b7rHjcTI0wA8Yx5Dm1JOky9BvXvpcXxzY1kVt48FRQ=", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+
+37%   7.37 MiB         21 MiB/s 0s 
+  S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, s3ErrorCode = "AccessControlListNotSupported", s3ErrorMessage = "The bucket does not allow ACLs", s3ErrorResource = Nothing, s3ErrorHostId = Just "hqd4HRNk5yp3tKJ6yMhcECEpCjBw8qB6oTpKF3PaOsYFeVG0C+dGI06xq3zgmvnPoFUttI040sY=", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+
+39%   7.81 MiB         21 MiB/s 0s 
+  S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, s3ErrorCode = "AccessControlListNotSupported", s3ErrorMessage = "The bucket does not allow ACLs", s3ErrorResource = Nothing, s3ErrorHostId = Just "7m7wwG5woSPmICIuXr9QnBOEjUikuyzHSebMLuaNyZMc2Ki2vaqKpU9U+GOTYmR/NzFjOeyxngk=", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+failed
+git-annex: copy: 1 failed
+```
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+```
+$ git annex version
+git-annex version: 8.20210223
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+$ cat /etc/os-release 
+PRETTY_NAME="Ubuntu 22.04 LTS"
+NAME="Ubuntu"
+VERSION_ID="22.04"
+VERSION="22.04 LTS (Jammy Jellyfish)"
+VERSION_CODENAME=jammy
+ID=ubuntu
+ID_LIKE=debian
+HOME_URL="https://www.ubuntu.com/"
+SUPPORT_URL="https://help.ubuntu.com/"
+BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
+PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
+UBUNTU_CODENAME=jammy
+```
+
+### Please provide any additional information below.
+
+
+Disabling `public` allows uploads:
+
+```
+$ git annex enableremote amazon public=no
+enableremote amazon ok
+(recording state in git...)
+$ git annex copy --to amazon what.nii.gz 
+copy what.nii.gz (checking amazon...) (to amazon...) 
+ok                                
+```
+
+But then causes the new problem that downloads fail when other users try to download the updated dataset:
+
+```
+$ git annex get what.nii.gz
+get what.nii.gz (from amazon...) 
+
+  S3 bucket does not allow public access; Set both AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to use S3
+
+  cannot download content
+
+  Unable to access these remotes: amazon
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+git-annex: get: 1 failed
+```
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+We use git-annex to share large datasets with the scientific community at https://github.com/spine-generic/data-multi-subject !
+
+> [[fixed|done]] --[[Joey]] 
diff --git a/doc/bugs/S3_ACL_deprecation/comment_1_07d0d382b88426180e77bac962306f44._comment b/doc/bugs/S3_ACL_deprecation/comment_1_07d0d382b88426180e77bac962306f44._comment
new file mode 100644
index 0000000000..f175d1f962
--- /dev/null
+++ b/doc/bugs/S3_ACL_deprecation/comment_1_07d0d382b88426180e77bac962306f44._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="comment 1"
+ date="2022-09-08T00:28:32Z"
+ content="""
+I'm sorry, I don't know what happened to my screenshot. It didn't upload correctly I guess? I've lost it now. I don't think its loss detracts too much though.
+"""]]
diff --git a/doc/bugs/S3_ACL_deprecation/comment_2_63b541a937cb34cc4c68504e00dc3fb8._comment b/doc/bugs/S3_ACL_deprecation/comment_2_63b541a937cb34cc4c68504e00dc3fb8._comment
new file mode 100644
index 0000000000..5311db3fb3
--- /dev/null
+++ b/doc/bugs/S3_ACL_deprecation/comment_2_63b541a937cb34cc4c68504e00dc3fb8._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-07-21T17:53:25Z"
+ content="""
+This only affects new S3 buckets. Existing S3 buckets that were
+created before April 2023 and were set up to allow public access should
+keep working, including ACL settings when storing new files in them.
+Per [Amazon's announcement](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-s3-automatically-enable-block-public-access-disable-access-control-lists-buckets-april-2023/),
+"There is no change for existing buckets."
+
+I've made `publicurl` orthogonal to `public`.
+
+As for the idea of `HTTP HEAD` before trying to set the ACL,
+the ACL is currently sent at past of the PutObject request. And
+either there is not a way to change the ACL later, or the aws haskell library
+is missing support for the API to do that. 
+
+While git-annex could HEAD without creds when publicyes=yes to verify that the
+user has configured the bucket correctly, and at least warn about a
+misconfiguration, that would add some overhead, and I guess if the user has not
+configured the bucket correctly, they will notice in some other way eventually
+and can fix its bucket policy after the fact. So I'm inclined not to do
+that.
+
+Instead I've simply depredated `public`, noting that it should not be set
+on new buckets. The user will have to deal with setting up the Bucket
+Policy themselves.
+"""]]
diff --git a/doc/bugs/S3_remote___8212___un-embedding_creds__63__.mdwn b/doc/bugs/S3_remote___8212___un-embedding_creds__63__.mdwn
new file mode 100644
index 0000000000..d26cf3f8c2
--- /dev/null
+++ b/doc/bugs/S3_remote___8212___un-embedding_creds__63__.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+After once embedding credentials into a S3 remote, there’s no way to un-embed them.
+
+### What steps will reproduce the problem?
+
+1. Add a S3 remote with `embedcreds=yes`.
+1. Try to set `embedcreds=no`.
+1. `git annex sync` here, and in some other clone.
+1. Check `git annex info my-s3-remote` for the other clone. Credentials are still embedded.
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170101 on NixOS 16.09 (stable).
+
+### Please provide any additional information below.
+
+[[!format sh """
+% g annex info test2 | grep '^creds'
+creds: embedded in git repository (gpg encrypted)
+
+% g annex enableremote test2 embedcreds=no
+enableremote test2 (encryption update) (to gpg keys: 134164FA6FAFE075) ok
+(recording state in git...)
+
+% g annex info test2 | grep '^creds'
+creds: embedded in git repository (gpg encrypted)
+
+%
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, it’s awesome! Thank you!
diff --git a/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_1_336e1c2a5c2a367cba0ad74896b3895b._comment b/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_1_336e1c2a5c2a367cba0ad74896b3895b._comment
new file mode 100644
index 0000000000..79a44d7c52
--- /dev/null
+++ b/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_1_336e1c2a5c2a367cba0ad74896b3895b._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-20T18:38:16Z"
+ content="""
+When you used embedcreds=yes, it *committed* the creds to the git-annex
+branch of the git repository. For embedcreds=no to do anything useful,
+it would need to remove that data from the git repository history.
+
+Removing data from a git repository tends to involve rewriting commits and
+forced pushes to all remotes, it's not a simple process and not ameanable
+to automation. It will be much easier, and more secure, to go into S3
+and generate new credentials, and revoke access to the old ones.
+
+What `git annex enableremote` with `embedcreds=no` does do is prevent
+any new creds from being embedded into the repository. Otherwise,
+`git annex enableremote` will update the embedded creds
+with whatever new ones are set in the environment when you run it.
+"""]]
diff --git a/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_2_282aaaed5e95e8062460f94ac3a68dea._comment b/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_2_282aaaed5e95e8062460f94ac3a68dea._comment
new file mode 100644
index 0000000000..9c2e141f37
--- /dev/null
+++ b/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_2_282aaaed5e95e8062460f94ac3a68dea._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 2"
+ date="2017-02-25T18:47:35Z"
+ content="""
+Sure, that’s what I did at the very beginning (revoking the creds on AWS).
+
+But still, when I clone this repo, `git annex info S3` in this fresh clone, says that credentials are embedded. This is a bit misleading.
+
+Maybe updating S3 configuration with `embedcreds=no` could change that behavior?
+
+It wouldn’t matter from the security standpoint (which is solved by changing permissions directly on AWS), but would simply be beneficial for usability. =)
+"""]]
diff --git a/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_3_07fb8558238285883d11d8805884bdae._comment b/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_3_07fb8558238285883d11d8805884bdae._comment
new file mode 100644
index 0000000000..fb97783f72
--- /dev/null
+++ b/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_3_07fb8558238285883d11d8805884bdae._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-03-06T17:34:29Z"
+ content="""
+If `git annex info` had said that the creds were not embedded after
+you tried `embedcreds=no`, then wouldn't you have belived it, and so not
+revoked the creds on AWS?
+"""]]
diff --git a/doc/bugs/S3_remote_errors_with_garage_endpoint.mdwn b/doc/bugs/S3_remote_errors_with_garage_endpoint.mdwn
new file mode 100644
index 0000000000..a9a7c5a8f0
--- /dev/null
+++ b/doc/bugs/S3_remote_errors_with_garage_endpoint.mdwn
@@ -0,0 +1,33 @@
+### Please describe the problem.
+
+When I attempt to create a S3 remote against my garage[1] cluster, it errors with the following:
+
+```
+$ git annex initremote garage type=S3 encryption=none host=my-s3-endpoint.domain.com protocol=https bucket=git-annex requeststyle=path datacenter=garage signature=v4
+initremote garage (checking bucket...) (creating bucket in garage...)
+git-annex: S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, s3ErrorCode = "AuthorizationHeaderMalformed", s3ErrorMessage = "Authorization header malformed, expected scope: 20230118/my-s3-endpoint.domain.com/s3/aws4_request", s3ErrorResource = Just "/git-annex/", s3ErrorHostId = Nothing, s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+failed
+initremote: 1 failed
+
+$ git annex initremote garage type=S3 encryption=none host=my-s3-endpoint.domain.com protocol=https bucket=git-annex requeststyle=path datacenter=garage
+initremote garage (checking bucket...) (creating bucket in garage...)
+git-annex: S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, s3ErrorCode = "InvalidRequest", s3ErrorMessage = "Bad request: Unsupported authorization method", s3ErrorResource = Just "/git-annex/", s3ErrorHostId = Nothing, s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+failed
+initremote: 1 failed
+```
+
+Garage appears to support v4 signatures: https://garagehq.deuxfleurs.fr/documentation/reference-manual/s3-compatibility/#high-level-features - and other S3 tooling works against the endpoint.
+
+
+### What version of git-annex are you using? On what operating system?
+
+Fedora Silverblue 37 / git-annex-10.20221212-1.fc37.x86_64
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, many years ago - now trying to get it up and running with my self-hosted S3 endpoint.
+
+[1]: https://garagehq.deuxfleurs.fr/
+
+> [[fixed|done]] although it needs git-annex to be built against 
+> a not yet released version of aws. --[[Joey]]
diff --git a/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_10_ea7a56193439eb63ad45074bd40f4ff5._comment b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_10_ea7a56193439eb63ad45074bd40f4ff5._comment
new file mode 100644
index 0000000000..8b842d3707
--- /dev/null
+++ b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_10_ea7a56193439eb63ad45074bd40f4ff5._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="jpds"
+ avatar="http://cdn.libravatar.org/avatar/24d746ec6a7726b162c12ecceb3ee267"
+ subject="comment 10"
+ date="2023-02-09T09:51:21Z"
+ content="""
+Thank you for the changes Joey, I can confirm that it's working and I've added this to the garage docs: https://git.deuxfleurs.fr/Deuxfleurs/garage/pulls/502
+
+I did however have to change git-annex's stack.yaml as follows to make this compile:
+
+```
+diff --git a/stack.yaml b/stack.yaml
+index 7dbfb657a..cf2db080b 100644
+--- a/stack.yaml
++++ b/stack.yaml
+@@ -11,10 +11,10 @@ flags:
+     gitlfs: true
+ packages:
+ - '.'
+-resolver: lts-18.13
++resolver: lts-19.16
+ extra-deps:
+ - IfElse-0.85
+-- aws-0.22
++- aws-0.24
+ - bloomfilter-2.0.1.0
+ - git-lfs-1.2.0
+ - http-client-restricted-0.0.4
+@@ -24,4 +24,4 @@ extra-deps:
+ - base16-bytestring-0.1.1.7
+ - base64-bytestring-1.0.0.3
+ - bencode-0.6.1.1
+-- http-client-0.7.9
++- http-client-0.7.11
+```
+
+On my machine, it wasn't happy about the aeson version without the lts bump and I also hit the bug at https://github.com/snoyberg/http-client/issues/482 hence the http-client change.
+
+> Thanks for clarifying that \"scope\" is internal jargon of garage though.
+
+I believe that this is actually an AWS thing, as it's extensively used in their Python and Rust SDKs: https://github.com/awslabs/aws-sdk-rust/blob/66423e05991ee831696bc32fe3e452694cf0d231/sdk/s3/src/config.rs#L98
+"""]]
diff --git a/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_1_1d5b499a0cea623aadebf7e3b7fd9752._comment b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_1_1d5b499a0cea623aadebf7e3b7fd9752._comment
new file mode 100644
index 0000000000..94f0e7c110
--- /dev/null
+++ b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_1_1d5b499a0cea623aadebf7e3b7fd9752._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jpds"
+ avatar="http://cdn.libravatar.org/avatar/24d746ec6a7726b162c12ecceb3ee267"
+ subject="comment 1"
+ date="2023-01-18T22:57:58Z"
+ content="""
+Error on Garage's side is triggered here: https://git.deuxfleurs.fr/Deuxfleurs/garage/src/commit/fcc5033466e58e3beec05ee7748d33522b6b32b0/src/api/signature/payload.rs#L297
+"""]]
diff --git a/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_2_ca7ffa315cfa49e028fe6ff2d5c3133b._comment b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_2_ca7ffa315cfa49e028fe6ff2d5c3133b._comment
new file mode 100644
index 0000000000..c19475c45d
--- /dev/null
+++ b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_2_ca7ffa315cfa49e028fe6ff2d5c3133b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jpds"
+ avatar="http://cdn.libravatar.org/avatar/24d746ec6a7726b162c12ecceb3ee267"
+ subject="comment 2"
+ date="2023-01-19T15:09:01Z"
+ content="""
+I took a look at the credentialv4 structure at https://github.com/aristidb/aws/blob/9bdc4ee018d0d9047c0434eeb21e2383afaa9ccf/Aws/Core.hs#L621 and found it curious that it has the region inside the scope (as the garage code) does... however in my error message from git-annex - the hostname of the S3 service is what's inside the scope instead of the 'garage' region name.
+
+I therefore adjusted the garage API's configuration to have the FQDN as the region and then... git-annex Just Worked.
+"""]]
diff --git a/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_3_ae9308a3bab8904dd0f501cbe2f09de0._comment b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_3_ae9308a3bab8904dd0f501cbe2f09de0._comment
new file mode 100644
index 0000000000..c796318031
--- /dev/null
+++ b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_3_ae9308a3bab8904dd0f501cbe2f09de0._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="jpds"
+ avatar="http://cdn.libravatar.org/avatar/24d746ec6a7726b162c12ecceb3ee267"
+ subject="comment 3"
+ date="2023-01-19T16:28:19Z"
+ content="""
+I believe the fix for this is:
+
+```
+diff --git a/Remote/S3.hs b/Remote/S3.hs
+index f5014202e..49f2ebd58 100644
+--- a/Remote/S3.hs
++++ b/Remote/S3.hs
+@@ -948,8 +948,8 @@ s3Configuration c = cfg
+                        | otherwise -> AWS.HTTP
+        cfg = case getRemoteConfigValue signatureField c of
+                Just (SignatureVersion 4) ->
+-                       S3.s3v4 proto endpoint False S3.SignWithEffort
+-               _ -> S3.s3 proto endpoint False
++                       S3.s3v4 proto datacenter False S3.SignWithEffort
++               _ -> S3.s3 proto datacenter False
+
+ data S3Info = S3Info
+        { bucket :: S3.Bucket
+```
+
+...however I cannot test it myself right now as it's failing to compile on another bit of code:
+
+```
+[452 of 679] Compiling Remote.S3
+
+git/joeyh/git-annex.branchable.com/Remote/S3.hs:922:68: error:
+    • Couldn't match type ‘B8.ByteString’ with ‘[Char]’
+      Expected type: String
+        Actual type: B8.ByteString
+    • In the first argument of ‘T.pack’, namely ‘datacenter’
+      In the second argument of ‘($)’, namely ‘T.pack datacenter’
+      In the expression: AWS.s3HostName $ T.pack datacenter
+    |
+922 |                 | h == AWS.s3DefaultHost = AWS.s3HostName $ T.pack datacenter
+    |                                                                    ^^^^^^^^^^
+```
+"""]]
diff --git a/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_4_f17018fbc7a8205a3ef0bdea74069fb9._comment b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_4_f17018fbc7a8205a3ef0bdea74069fb9._comment
new file mode 100644
index 0000000000..4a3bdc1a7b
--- /dev/null
+++ b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_4_f17018fbc7a8205a3ef0bdea74069fb9._comment
@@ -0,0 +1,53 @@
+[[!comment format=mdwn
+ username="jpds"
+ avatar="http://cdn.libravatar.org/avatar/24d746ec6a7726b162c12ecceb3ee267"
+ subject="comment 4"
+ date="2023-01-24T15:55:36Z"
+ content="""
+I think this can all be removed as only the 'region' should be in the `S3.*` calls:
+
+```
+diff --git a/Remote/S3.hs b/Remote/S3.hs
+index f5014202e..d017378a8 100644
+--- a/Remote/S3.hs
++++ b/Remote/S3.hs
+@@ -913,14 +913,7 @@ s3Configuration c = cfg
+                Nothing -> S3.s3RequestStyle cfg
+        }
+   where
+-       h = fromJust $ getRemoteConfigValue hostField c
+        datacenter = fromJust $ getRemoteConfigValue datacenterField c
+-       -- When the default S3 host is configured, connect directly to
+-       -- the S3 endpoint for the configured datacenter.
+-       -- When another host is configured, it's used as-is.
+-       endpoint
+-               | h == AWS.s3DefaultHost = AWS.s3HostName $ T.pack datacenter
+-               | otherwise = T.encodeUtf8 $ T.pack h
+        port = case getRemoteConfigValue portField c of
+                Just s ->
+                        case reads s of
+@@ -948,8 +941,8 @@ s3Configuration c = cfg
+                        | otherwise -> AWS.HTTP
+        cfg = case getRemoteConfigValue signatureField c of
+                Just (SignatureVersion 4) ->
+-                       S3.s3v4 proto endpoint False S3.SignWithEffort
+-               _ -> S3.s3 proto endpoint False
++                       S3.s3v4 proto datacenter False S3.SignWithEffort
++               _ -> S3.s3 proto datacenter False
+
+ data S3Info = S3Info
+        { bucket :: S3.Bucket
+```
+
+But now I get this as an error and I do not know why:
+
+```
+initremote garage (checking bucket...) (creating bucket in garage...)
+git-annex: getRemoteConfigValue datacenter found value of unexpected type [Char]. This is a bug in git-annex!
+CallStack (from HasCallStack):
+  error, called at ./Annex/SpecialRemote/Config.hs:179:28 in main:Annex.SpecialRemote.Config
+  getRemoteConfigValue, called at ./Remote/S3.hs:916:33 in main:Remote.S3
+failed
+initremote: 1 failed
+```
+"""]]
diff --git a/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_5_fb7a448a2a4231b08277741805c12c76._comment b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_5_fb7a448a2a4231b08277741805c12c76._comment
new file mode 100644
index 0000000000..49eb41ff72
--- /dev/null
+++ b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_5_fb7a448a2a4231b08277741805c12c76._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-01-31T18:45:08Z"
+ content="""
+Firstly, this code is working, as far as I know, when accessing AWS.
+And I want to be very careful to avoid breaking that. So patching all
+that out would have to be very carefully examined and/or tested.
+
+I've verified that the s3Endpoint is supposed to be a hostname. It's
+used as such in s3SignQuery:
+	
+	(host, path) = case s3RequestStyle of
+	               PathStyle   -> ([Just s3Endpoint], [Just "/", fmap (`B8.snoc` '/') s3QBucket, urlEncodedS3QObject])
+
+If s3Endpoint were just "garage" that would break.
+
+s3SignQuery also has `region = s3ExtractRegion s3Endpoint`.
+s3ExtractRegion parses a hostname like
+"s3-foo.amazonaws.com" to "foo", and that is used as the region
+(or "scope" as you've called it).
+
+git-annex makes sure to set s3Endpoint to a hostname. When the
+default AWS hostname is used, it converts the datacenter=foo value
+to a hostname like s3-foo.amazonaws.com and sets s3Endpoint to that.
+When some other hostname= is provided, it set s3Endpoints to
+that hostname, ignoring the datacenter= value. 
+
+This seems like the only thing git-annex *can* do. Your proposed
+patch would make a configuration of "datacenter=us-west-1" set
+s3Endpoint to "us-west-1" and s3SignQuery would use that as the
+host. 
+
+So I think this is probably a bug or shortcoming of the aws library.
+It seems that to fix this, the aws library would need to have
+a way to specify a "scope" or "region" separate from the s3Endpoint.
+And git-annex would then need to expose that as something other
+than datacenter=
+
+I've filed an issue on aws about this:
+<https://github.com/aristidb/aws/issues/283>
+"""]]
diff --git a/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_6_513bdbb6595612432fd4f33bd8e4e737._comment b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_6_513bdbb6595612432fd4f33bd8e4e737._comment
new file mode 100644
index 0000000000..b63f80440f
--- /dev/null
+++ b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_6_513bdbb6595612432fd4f33bd8e4e737._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="jpds"
+ avatar="http://cdn.libravatar.org/avatar/24d746ec6a7726b162c12ecceb3ee267"
+ subject="comment 6"
+ date="2023-01-31T22:28:16Z"
+ content="""
+> Firstly, this code is working, as far as I know, when accessing AWS.
+
+It's working, because presumably AWS accept 's3.amazon.com' as a region setting for the scope in their cloud.
+
+> I've verified that the s3Endpoint is supposed to be a hostname. It's used as such in s3SignQuery:
+>
+> (host, path) = case s3RequestStyle of
+>               PathStyle   -> ([Just s3Endpoint], [Just \"/\", fmap (`B8.snoc` '/') s3QBucket, urlEncodedS3QObject])
+>
+> If s3Endpoint were just \"garage\" that would break.
+
+My S3 endpoint is indeed the FQDN of my self-hosted S3 endpoint. My \"AWS region\" is \"garage\".
+
+To give exact examples, this is what I configure in my environment when interacting with garage with any other S3 utility:
+ 
+export AWS_ACCESS_KEY_ID=foo
+export AWS_SECRET_ACCESS_KEY=bar
+export AWS_DEFAULT_REGION='garage'
+export AWS_ENDPOINT='https://my-s3-endpoint.example.com/'
+
+The region bit is what's added to the credentialV4 in Core.hs (and what AWS appear to also accept as s3.amazon.com(? - I do not have an AWS account to test this). To make git-annex work, I need to do the equivalent of this (after changing garage's configuration):
+
+export AWS_DEFAULT_REGION='my-s3-endpoint.example.com'
+
+Once I do this, awscli and every other tool breaks:
+
+$ aws s3 ls s3://
+Provided region_name 'my-s3-endpoint.example.com' doesn't match a supported format.
+
+> s3SignQuery also has region = s3ExtractRegion s3Endpoint. s3ExtractRegion parses a hostname like \"s3-foo.amazonaws.com\" to \"foo\", and that is used as the region (or \"scope\" as you've called it).
+>
+> git-annex makes sure to set s3Endpoint to a hostname. When the default AWS hostname is used, it converts the datacenter=foo value to a hostname like s3-foo.amazonaws.com and sets s3Endpoint to that. When some other hostname= is provided, it set s3Endpoints to that hostname, ignoring the datacenter= value.
+
+It might be best to deprecate datacenter= and add region= directly to match AWS parlance
+
+> This seems like the only thing git-annex can do. Your proposed patch would make a configuration of \"datacenter=us-west-1\" set s3Endpoint to \"us-west-1\" and s3SignQuery would use that as the host.
+
+What I'd really like to test is just being able to set datacenter=garage but with my change it's not accepted as a [Char].
+"""]]
diff --git a/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_7_131eb46d499d29b124c576653796e270._comment b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_7_131eb46d499d29b124c576653796e270._comment
new file mode 100644
index 0000000000..6be643bda8
--- /dev/null
+++ b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_7_131eb46d499d29b124c576653796e270._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="jpds"
+ avatar="http://cdn.libravatar.org/avatar/24d746ec6a7726b162c12ecceb3ee267"
+ subject="comment 7"
+ date="2023-02-02T15:53:34Z"
+ content="""
+> s3ExtractRegion parses a hostname like \"s3-foo.amazonaws.com\" to \"foo\", and that is used as the region (or \"scope\" as you've called it).
+
+I'd also like to clarify this bit in that what I mean by \"scope\" is that line in the error message from the backend:
+
+```
+s3ErrorMessage = \"Authorization header malformed, expected scope: 20230118/my-s3-endpoint.domain.com/s3/aws4_request\"
+```
+
+git-annex is incorrectly setting the FQDN/endpoint of the service in this, instead of what garage and the linked Haskell library want here after the date which is the region.
+"""]]
diff --git a/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_8_d8cdf46fb8de877ea167d14a055813e0._comment b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_8_d8cdf46fb8de877ea167d14a055813e0._comment
new file mode 100644
index 0000000000..ec62c54bbe
--- /dev/null
+++ b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_8_d8cdf46fb8de877ea167d14a055813e0._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-02-06T16:51:58Z"
+ content="""
+> It's working, because presumably AWS accept 's3.amazon.com' as a region setting for the scope in their cloud.
+
+I doubt it; that's not what aws sends to it.
+
+Just to be clear, comment #5 is me fully understanding the problem
+and escalating the issue to the relevant library. Further speculation
+would probably muddy the water.
+
+Thanks for clarifying that "scope" is internal jargon of garage though.
+Also it's good to know that `AWS_DEFAULT_REGION` is a commonly used
+environment variable for it.
+"""]]
diff --git a/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_9_3d2033edcd49e62045339e341996fd28._comment b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_9_3d2033edcd49e62045339e341996fd28._comment
new file mode 100644
index 0000000000..046002c5c9
--- /dev/null
+++ b/doc/bugs/S3_remote_errors_with_garage_endpoint/comment_9_3d2033edcd49e62045339e341996fd28._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2023-02-06T17:33:25Z"
+ content="""
+Implemented this in aws: https://github.com/aristidb/aws/pull/284
+Which should be released as version 0.24.
+
+git-annex will support region= when built with that version of aws.
+"""]]
diff --git a/doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces.mdwn b/doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces.mdwn
new file mode 100644
index 0000000000..72e22e7a19
--- /dev/null
+++ b/doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces.mdwn
@@ -0,0 +1,33 @@
+I tried to use the S3 special remote to access DigitalOcean's Spaces API. [Their docs](https://developers.digitalocean.com/documentation/spaces/) suggest that this should be possible. However, it doesn't work.
+
+The command I ran, with key removed:
+
+    git annex --debug initremote xamsi-everything type=S3 protocol=https host=sfo2.digitaloceanspaces.com datacenter=sfo2 chunk=64MiB encryption=hybrid keyid=XXX
+
+The non-debug output, in full, with key removed:
+
+    initremote xamsi-everything (encryption setup) (to gpg keys: XXX) (checking bucket...) (creating bucket in sfo2...) 
+    git-annex: XmlException {xmlErrorMessage = "Missing error Message"}
+    failed
+    git-annex: initremote: 1 failed
+
+The debug output of the part that breaks, again with key material removed:
+
+    (creating bucket in sfo2...) [2019-10-15 08:40:41.119524792] String to sign: "PUT\n\n\nTue, 15 Oct 2019 15:40:41 GMT\n/xamsi-everything-a36e2044-07ac-4d85-8450-e5760c897a9b/"
+    [2019-10-15 08:40:41.119586065] Host: "xamsi-everything-a36e2044-07ac-4d85-8450-e5760c897a9b.sfo2.digitaloceanspaces.com"
+    [2019-10-15 08:40:41.119639648] Path: "/" 
+    [2019-10-15 08:40:41.119683721] Query string: ""
+    [2019-10-15 08:40:41.11972899] Header: [("Date","Tue, 15 Oct 2019 15:40:41 GMT"),("Authorization","AWS XXX")]
+    [2019-10-15 08:40:41.119846915] Body: "<?xml version=\"1.0\" encoding=\"UTF-8\"?><CreateBucketConfiguration xmlns=\"http://s3.amazonaws.com/doc/2006-03-01/\"><LocationConstraint>sfo2</LocationConstraint></CreateBucketConfiguration>"
+    [2019-10-15 08:40:41.174450718] Response status: Status {statusCode = 403, statusMessage = "Forbidden"}
+    [2019-10-15 08:40:41.174566002] Response header 'Content-Length': '190'
+    [2019-10-15 08:40:41.174627301] Response header 'x-amz-request-id': 'tx0000000000001c5b175eb-005da5e879-23e283-sfo2a'
+    [2019-10-15 08:40:41.174685597] Response header 'Accept-Ranges': 'bytes'
+    [2019-10-15 08:40:41.174730858] Response header 'Content-Type': 'application/xml'
+    [2019-10-15 08:40:41.174776256] Response header 'Date': 'Tue, 15 Oct 2019 15:40:41 GMT'
+    [2019-10-15 08:40:41.174821726] Response header 'Strict-Transport-Security': 'max-age=15552000; includeSubDomains; preload'
+    [2019-10-15 08:40:41.174984394] Response metadata: S3: request ID=tx0000000000001c5b175eb-005da5e879-23e283-sfo2a, x-amz-id-2=<none>
+
+> This was either fixed by the signature=v4 support, or is a bug on digital
+> ocean's side. Anyway, it's very old, and there has been no response, 
+> so closing. [[done]] --[[Joey]] 
diff --git a/doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces/comment_1_12fd9dfb47e157e1d38c5e88a543498b._comment b/doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces/comment_1_12fd9dfb47e157e1d38c5e88a543498b._comment
new file mode 100644
index 0000000000..56718b48e5
--- /dev/null
+++ b/doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces/comment_1_12fd9dfb47e157e1d38c5e88a543498b._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-06T17:41:21Z"
+ content="""
+This is either a bug in <http://hackage.haskell.org/package/aws> or
+Digital Ocean's implementation of the S3 protocol. I don't know which,
+but I do know it has to be fixed in one of those two place, and not
+in git-annex.
+
+The fact that the aws library can't even parse an error message out of
+their response kind of says something.
+
+But the real problem seems to
+While they claim to support V2 signatures,
+my guess is there's a problem with their support for V2, since they're
+mostly dealing with V4. The aws library's support for V4 is experimental
+and [apparently buggy](https://github.com/aristidb/aws/issues/262), but
+as git-annex uses it, it will only use V2.
+"""]]
diff --git a/doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces/comment_2_3bbdf23c8a4a480f4f6b8e8a2f8ddecd._comment b/doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces/comment_2_3bbdf23c8a4a480f4f6b8e8a2f8ddecd._comment
new file mode 100644
index 0000000000..14bce58c32
--- /dev/null
+++ b/doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces/comment_2_3bbdf23c8a4a480f4f6b8e8a2f8ddecd._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-05-07T16:46:14Z"
+ content="""
+I have added to git-annex a way to use v4 authentication signatures.
+
+You will need a daily build, or the next release of git-annex.
+
+Give it a try by adding signature=v4 to your initremote
+or enableremote, and please let me know if it works or how it fails with
+that.
+"""]]
diff --git a/doc/bugs/SQlite_failed_when_copying_to_remote_repository.mdwn b/doc/bugs/SQlite_failed_when_copying_to_remote_repository.mdwn
new file mode 100644
index 0000000000..396c66312a
--- /dev/null
+++ b/doc/bugs/SQlite_failed_when_copying_to_remote_repository.mdwn
@@ -0,0 +1,82 @@
+### Please describe the problem.
+
+When I copy file from on directory to another, I have the following error
+
+```
+$ git annex copy . --to another
+
+...
+copy file1 (to another...) 
+100%  321.93 MiB      115 MiB/s 0ssqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform open "repo/.git/annex/keysdb/db".
+  sqlite query crashed: thread blocked indefinitely in an MVar operation
+  CallStack (from HasCallStack):
+    error, called at ./Database/Handle.hs:102:40 in main:Database.Handle
+
+  transfer failed
+
+ok
+copy file2 (to another...) 
+100%  424.24 MiB      109 MiB/s 0ssqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform open "repo/.git/annex/keysdb/db".
+  sqlite query crashed: thread blocked indefinitely in an MVar operation
+  CallStack (from HasCallStack):
+    error, called at ./Database/Handle.hs:102:40 in main:Database.Handle
+
+  transfer failed
+
+ok
+
+...
+```
+
+
+### What steps will reproduce the problem?
+
+Any time I copy files to this remote
+
+
+### What version of git-annex are you using? On what operating system?
+
+On local machine:
+
+```
+$ git-annex version
+git-annex version: 8.20210223
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+
+$ uname -a
+Linux kiwi 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux
+```
+
+On remote machine:
+
+```
+$ git-annex version
+git-annex version: 8.20200617
+build flags: Assistant Webapp Pairing S3 WebDAV Kqueue DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.27 DAV-1.3.4 feed-1.3.0.1 ghc-8.10.3 http-client-0.7.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: freebsd x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+
+$ uname -a
+FreeBSD extra-2 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 n245412-484f039b1d0 TRUENAS  amd64
+```
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I use git-annex for several years, and I'm very happy with it. I's one of the best files synchronisation tools.
+
+
+[[!meta title="sqlite fails when repository path contains non-unicode"]]
+
+> [[fixed|done]], when git-annex is built against persistent-sqlite version
+> 2.13.3. --[[Joey]]
diff --git a/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_1_4578b04c1cfc46849e9440f257f49303._comment b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_1_4578b04c1cfc46849e9440f257f49303._comment
new file mode 100644
index 0000000000..97292cc932
--- /dev/null
+++ b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_1_4578b04c1cfc46849e9440f257f49303._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-01-31T17:22:24Z"
+ content="""
+Seems to me that you are not able to read the `repo/.git/annex/keysdb/db` file,
+likely due to a permissions problem or because it is owned by another user.
+
+I was able to reproduce this by making the repository itself owned by
+me, but making that specific file in it owned by a different user and not
+readable by me:
+
+	sqlite query crashed: thread blocked indefinitely in an MVar operation
+	  CallStack (from HasCallStack):
+	    error, called at ./Database/Handle.hs:82:40 in main:Database.Handle
+
+"""]]
diff --git a/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_2_a953d5506f30cf19fe97c6ece155b45e._comment b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_2_a953d5506f30cf19fe97c6ece155b45e._comment
new file mode 100644
index 0000000000..4787543417
--- /dev/null
+++ b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_2_a953d5506f30cf19fe97c6ece155b45e._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="hurlebouc"
+ avatar="http://cdn.libravatar.org/avatar/bda734a6d937c1fe0c9778a6eaefffbc"
+ subject="comment 2"
+ date="2023-02-01T12:26:04Z"
+ content="""
+Thank you for your anser
+
+I've checked user right and all seem ok for me:
+
+```
+$ ls -ln
+total 7
+-rw-r--r--  1 1002  1002  28672 Dec  6 08:09 db
+
+$ id -u
+1002
+
+```
+
+Thus for me the solution is somewhere else.
+"""]]
diff --git a/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_3_5b2956522ce9c9cdc0c704e63efe8dac._comment b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_3_5b2956522ce9c9cdc0c704e63efe8dac._comment
new file mode 100644
index 0000000000..a98ad3ce58
--- /dev/null
+++ b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_3_5b2956522ce9c9cdc0c704e63efe8dac._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="hurlebouc"
+ avatar="http://cdn.libravatar.org/avatar/bda734a6d937c1fe0c9778a6eaefffbc"
+ subject="comment 3"
+ date="2023-02-21T06:49:27Z"
+ content="""
+Hi,
+
+Any idea explainig this failure?
+"""]]
diff --git a/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_4_3966cce3267fe134f5c9c6b05e1149b5._comment b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_4_3966cce3267fe134f5c9c6b05e1149b5._comment
new file mode 100644
index 0000000000..b2c5afc5ee
--- /dev/null
+++ b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_4_3966cce3267fe134f5c9c6b05e1149b5._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-02-23T18:48:04Z"
+ content="""
+Version 8.20210223 is quite old, it would be good to try with a newer
+version and see if the error message is different.
+
+You might also try strace and look to see what it says happens when it
+tries to open "repo/.git/annex/keysdb/db".
+
+I don't know if what you showed about file permissions means you can really
+read it. There might be ACLs or other complications? The best way to show
+you can read it is to actually try to read it, eg `cat db >/dev/null`
+"""]]
+
diff --git a/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_5_0c0aec23302afafffc0f69d1bd89ad8f._comment b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_5_0c0aec23302afafffc0f69d1bd89ad8f._comment
new file mode 100644
index 0000000000..ab8b037c00
--- /dev/null
+++ b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_5_0c0aec23302afafffc0f69d1bd89ad8f._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="hurlebouc"
+ avatar="http://cdn.libravatar.org/avatar/bda734a6d937c1fe0c9778a6eaefffbc"
+ subject="comment 5"
+ date="2023-03-08T15:11:26Z"
+ content="""
+Hi, and thank you for keeping anwsering my question!
+
+I do succeed in reading this file. And here is the content:
+
+   sqlite> .dump
+   PRAGMA foreign_keys=OFF;
+   BEGIN TRANSACTION;
+   CREATE TABLE IF NOT EXISTS \"associated\"(\"id\" INTEGER PRIMARY KEY,\"key\" BLOB NOT NULL,\"file\" BLOB NOT NULL,CONSTRAINT \"key_file_index\" UNIQUE (\"key\",\"file\"),CONSTRAINT \"file_key_index\" UNIQUE (\"file\",\"key\"));
+   CREATE TABLE IF NOT EXISTS \"content\"(\"id\" INTEGER PRIMARY KEY,\"key\" BLOB NOT NULL,\"inodecache\" VARCHAR NOT NULL,\"filesize\" VARCHAR NOT NULL,\"mtime\" INTEGER NOT NULL,CONSTRAINT \"key_inode_cache_index\" UNIQUE (\"key\",\"inodecache\"),CONSTRAINT \"inode_cache_key_index\" UNIQUE (\"inodecache\",\"key\"));
+   COMMIT;
+   sqlite> 
+
+"""]]
diff --git a/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_6_031f049fdc2c284303e9db42071ebda7._comment b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_6_031f049fdc2c284303e9db42071ebda7._comment
new file mode 100644
index 0000000000..8dc022b11d
--- /dev/null
+++ b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_6_031f049fdc2c284303e9db42071ebda7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="hurlebouc"
+ avatar="http://cdn.libravatar.org/avatar/bda734a6d937c1fe0c9778a6eaefffbc"
+ subject="comment 6"
+ date="2023-03-08T15:16:28Z"
+ content="""
+Problem identified!
+
+The directory `repo` was actually containing \"é\" char. When I remove this char, problem disapeared.
+"""]]
diff --git a/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_7_3d4a7d330d80060275c34d0a13416fb7._comment b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_7_3d4a7d330d80060275c34d0a13416fb7._comment
new file mode 100644
index 0000000000..6b6344a5b0
--- /dev/null
+++ b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_7_3d4a7d330d80060275c34d0a13416fb7._comment
@@ -0,0 +1,78 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2023-03-14T17:00:06Z"
+ content="""
+Oho, I reproduced it!
+
+First I made a git-annex repo named "fooé", and added a file "foo" to it,
+and that is unlocked.
+
+	joey@darkstar:/tmp>git clone fooé bar
+	Cloning into 'bar'...
+	done.
+	joey@darkstar:/tmp>cd bar
+	joey@darkstar:/tmp/bar>git-annex move --from origin
+	move foo (from origin...)
+	(recording state in git...)
+	ok
+	(recording state in git...)
+	joey@darkstar:/tmp/bar>git-annex copy --to origin
+	copy foo (to origin...)
+	(recording state in git...)
+	ok
+	(recording state in git...)
+	joey@darkstar:/tmp/bar>git-annex move --from origin
+	move foo (from origin...) (recording state in git...)
+	ok
+	(recording state in git...)
+	joey@darkstar:/tmp/bar>LANG=C git-annex copy --to origin
+	copy foo (to origin...)
+	
+	  sqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform open "/tmp/foo\65533\65533/.git/annex/keysdb/db".
+	  CallStack (from HasCallStack):
+	    error, called at ./Database/Handle.hs:87:25 in main:Database.Handle
+	
+	ok
+
+Note that using git-annex in repo fooé with LANG=C works. The problem
+seems limited to a remote with a unicode character in its name when not in a
+unicode locale.
+
+In strace I see this:
+
+	3451696 openat(AT_FDCWD, "/tmp/foo\357\277\275\357\277\275/.git/annex/keysdb/db", O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644 <unfinished ...>
+	3451694 <... close resumed>)            = 0
+	3451696 <... openat resumed>)           = -1 ENOENT (No such file or directory)
+
+That doesn't look like the correct encoding for "é" does it?
+`"/tmp/foo\303\251"` would be correct and is what git-annex otherwise uses
+when accessing that repo.
+
+I think the reason for this is simply that persistent-sqlite uses Text
+for the location of the database. And Text is unicode encoded. So when the non
+unicode locale results in a FilePath that is encoded using the filesystem encoding,
+with surrogate characters, and that gets fed to Data.Text.pack, it replaces the
+"invalid scalar values" with "\65533".
+
+The same thing would happen in a unicode locale if the remote's path was not
+valid unicode.
+
+Filed an issue to get persistent-sqlite to not use Text for the FilePath
+<https://github.com/yesodweb/persistent/issues/1481>
+
+I don't think that non-unicode FilePaths can be generally squeezed into a Text,
+so we may need to wait persistent getting fixed. Although it should be possible,
+in a non-unicode locale, to convert a non-unicode FilePath like "fooé"
+to a Text.
+
+----
+
+Also notice that git-annex succeeds despite this error. Which is reasonable
+since it was only unable to update the remote's keys db, and the remote
+can and will just update it itself next time git-annex is used over there.
+Which will work since that git-annex will be running in the directory 
+and will use relative paths.
+
+So perhaps the error message could just be suppressed?
+"""]]
diff --git a/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_8_1501223d25a03c27a7ceffc6b0ea32a3._comment b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_8_1501223d25a03c27a7ceffc6b0ea32a3._comment
new file mode 100644
index 0000000000..c9fb1de251
--- /dev/null
+++ b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_8_1501223d25a03c27a7ceffc6b0ea32a3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="hurlebouc"
+ avatar="http://cdn.libravatar.org/avatar/bda734a6d937c1fe0c9778a6eaefffbc"
+ subject="comment 8"
+ date="2023-03-22T05:47:16Z"
+ content="""
+Thank you very much for the analysis! This reinforces my conviction that git-annex is a very high quality project. 
+"""]]
diff --git a/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_9_192c219b32c95954ec6400367474dd78._comment b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_9_192c219b32c95954ec6400367474dd78._comment
new file mode 100644
index 0000000000..34d7a3170d
--- /dev/null
+++ b/doc/bugs/SQlite_failed_when_copying_to_remote_repository/comment_9_192c219b32c95954ec6400367474dd78._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2023-03-23T19:27:33Z"
+ content="""
+I sent in a pull request today to persistent-sqlite
+that will let git-annex fix this once accepted.
+
+<https://github.com/yesodweb/persistent/pull/1486>
+
+Once/if that is merged, git-annex can be changed to 
+use the new `open'`
+"""]]
diff --git a/doc/bugs/SSL_repos_does_not_show_up_in_Assistant.mdwn b/doc/bugs/SSL_repos_does_not_show_up_in_Assistant.mdwn
new file mode 100644
index 0000000000..6f21cb5342
--- /dev/null
+++ b/doc/bugs/SSL_repos_does_not_show_up_in_Assistant.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+
+I have recently switched to self hosted git. Gitbucket over SSL. When I swithced origin from rsync ssh to ssl url assistant stopped showing origin in the repositories list it also does not sync to it when a file changes. (It does sync to it every 5 6 hours.). Running sync on the command line does sync to the repo. Authentication is done using netrc file. Replacing the ssl based url to ssh based url, repo shows up in the list and assistant syncs to it.
+
+
+### What steps will reproduce the problem?
+
+Replacing the ssh url with ssl url.
+
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150823-geb17375
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/SSL_repos_does_not_show_up_in_Assistant/comment_1_5a8e599d6e22e7c1960bd1715666657b._comment b/doc/bugs/SSL_repos_does_not_show_up_in_Assistant/comment_1_5a8e599d6e22e7c1960bd1715666657b._comment
new file mode 100644
index 0000000000..d394ca039d
--- /dev/null
+++ b/doc/bugs/SSL_repos_does_not_show_up_in_Assistant/comment_1_5a8e599d6e22e7c1960bd1715666657b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-10-12T18:52:42Z"
+ content="""
+You seem to be talking about using https to access a git repository.
+
+git-annex is not generally able to use https as a transport -- ie, it
+can maybe download files from a git repository over https, if
+the repository is set up just right. But it can't upload file to that
+repository, nor can it promptly notice when changes are synced to that
+repository from elsewhere.
+
+So, there's not much that the assistant can do with such a repository.
+
+You'll be better off using ssh for your git-annex repositories.
+"""]]
diff --git a/doc/bugs/SSL_repos_does_not_show_up_in_Assistant/comment_2_2ad5098c5e2ac9b8651cb464adb974c1._comment b/doc/bugs/SSL_repos_does_not_show_up_in_Assistant/comment_2_2ad5098c5e2ac9b8651cb464adb974c1._comment
new file mode 100644
index 0000000000..0759fb7771
--- /dev/null
+++ b/doc/bugs/SSL_repos_does_not_show_up_in_Assistant/comment_2_2ad5098c5e2ac9b8651cb464adb974c1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 2"
+ date="2015-10-13T16:57:24Z"
+ content="""
+You are right about https access, server does not support git-annex so it is set to meta data only. when using ssh changes are sync (git changes only) but with https changes are not synced (meta data). It is not even listed in repos. When using ssh it is listed in repos as meta data only. I do not store files in the repo just meta data.
+"""]]
diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably.mdwn b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably.mdwn
new file mode 100644
index 0000000000..a6c258332a
--- /dev/null
+++ b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+Entering a jabber address which's server got a selfsigned certificate, the process just fails, without asking for acceptance for that certificate. This is quite a showstopper.
+(for example: jabber.ccc.de)
+
+
+### What steps will reproduce the problem?
+Try with an account from e.g. jabber.ccc.de
+
+
+### What version of git-annex are you using? On what operating system?
+Arch Linux, aur/git-annex-standalone 4.20130709-1 
+
+### Please provide any additional information below.
+There is no logoutput to add... I'm sorry.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+[[!meta title="XMPP does not work with jabber.ccc.de"]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_1_13d27ba41d9ef78c8db534b6bc26314e._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_1_13d27ba41d9ef78c8db534b6bc26314e._comment
new file mode 100644
index 0000000000..a591b51e1b
--- /dev/null
+++ b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_1_13d27ba41d9ef78c8db534b6bc26314e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 1"
+ date="2013-07-16T17:33:23Z"
+ content="""
+Hmm, actually the XMPP library it's using does not fail on an invalid or self-signed cert. This is something that SSL using libraries sadly often get wrong, and yeah, I see I contacted the library author a while ago, and a \"sessionIsSecure\" has been added to it, which can be used to check if the cert was valid.
+
+This leaves open the question of what's happening with you on the CCC server. Did you get an error message?
+
+
+"""]]
diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_2_018eed99e71680be9e7c0844020419bb._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_2_018eed99e71680be9e7c0844020419bb._comment
new file mode 100644
index 0000000000..9caee8a735
--- /dev/null
+++ b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_2_018eed99e71680be9e7c0844020419bb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 2"
+ date="2013-07-16T17:42:42Z"
+ content="""
+Actually, sessionIsSecure only tells me if it's using SSL at all; still waiting on the XMPP library to add cert checking..
+"""]]
diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_3_1e7578dd1321f399b12197056495b0b6._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_3_1e7578dd1321f399b12197056495b0b6._comment
new file mode 100644
index 0000000000..62d723c7b3
--- /dev/null
+++ b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_3_1e7578dd1321f399b12197056495b0b6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~psycojoker"
+ nickname="psycojoker"
+ subject="comment 3"
+ date="2013-11-25T09:54:33Z"
+ content="""
+Just to confirm that I'm also affected. Maybe you should add the possibility in the error message next to \"is the password correct?\".
+"""]]
diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_4_a1948b7cd6ea990c8f1be5e483c835fa._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_4_a1948b7cd6ea990c8f1be5e483c835fa._comment
new file mode 100644
index 0000000000..6eec4ae9a1
--- /dev/null
+++ b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_4_a1948b7cd6ea990c8f1be5e483c835fa._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://xlogon.net/yminus"
+ nickname="http://xlogon.net/yminus"
+ subject="comment 4"
+ date="2014-05-08T21:12:49Z"
+ content="""
+When will this issue be fixed? Currently my Jabber account is on jabber.ccc.de.
+
+This is the error message:
+
+    Unable to connect to the Jabber server. Maybe you entered the wrong password? (Error message: host jabberd.jabber.ccc.de.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"bad-protocol\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}); host jabberd.jabber.ccc.de.:80 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"bad-protocol\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}))
+
+Can you advise me another trustworthy non-profit and free (free as in free beer\" as well as \"free as in free speech\") jabber server?
+"""]]
diff --git a/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_5_293b333134c97dc666a825cc7a8b2b62._comment b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_5_293b333134c97dc666a825cc7a8b2b62._comment
new file mode 100644
index 0000000000..37c86cc80b
--- /dev/null
+++ b/doc/bugs/Selfsigned_certificates_with_jabber_fail_miserably/comment_5_293b333134c97dc666a825cc7a8b2b62._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.36"
+ subject="comment 5"
+ date="2014-05-24T20:03:46Z"
+ content="""
+AFAIKS, this is not a failure from a self-signed certificate. git-annex contacted the jabber server, accepted its certificate, and tried to log in. The jabber server rejected the login.
+
+This kind of problem has in the past turned out to involve incompatabilities in SASL authentication using some newish authentication schemes. Often it's been a bug in the XMPP server that's tickled by the haksell TLS library. See for example <http://bugs.debian.org/717463>
+
+So, what XMPP server is used by CCC?
+"""]]
diff --git a/doc/bugs/Share_with_a_friend_fails.mdwn b/doc/bugs/Share_with_a_friend_fails.mdwn
new file mode 100644
index 0000000000..010fa03b89
--- /dev/null
+++ b/doc/bugs/Share_with_a_friend_fails.mdwn
@@ -0,0 +1,52 @@
+### Please describe the problem.
+Fails with below error
+
+### What steps will reproduce the problem?
+Click add another repository
+
+Click Let's get start
+
+Receive Error
+
+### What version of git-annex are you using? On what operating system?
+git-annex version 8.20200501
+MacOS 10.15.4 (19E287)
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+[2020-05-07 15:01:42.693876] main: starting assistant version 8.20200501
+(scanning...) [2020-05-07 15:01:42.754501] Watcher: Performing startup scan
+(started...) 
+07/May/2020:15:01:56 -0700 [Error#yesod-core] Failed to enable tor
+
+enable-tor 
+  You will be prompted for root's password
+su: illegal option -- c
+usage: su [-] [-flm] [login [args]]
+
+git-annex: Failed to run as root: /usr/local/Cellar/git-annex/8.20200501/bin/git-annex enable-tor 501
+failed
+git-annex: enable-tor: 1 failed
+ @(yesod-core-1.6.18-Chd8Br2Wdd9GRfQbrxaPhy:Yesod.Core.Class.Yesod src/Yesod/Core/Class/Yesod.hs:688:5)
+07/May/2020:15:04:58 -0700 [Error#yesod-core] Failed to enable tor
+
+enable-tor 
+  You will be prompted for root's password
+su: illegal option -- c
+usage: su [-] [-flm] [login [args]]
+
+git-annex: Failed to run as root: /usr/local/Cellar/git-annex/8.20200501/bin/git-annex enable-tor 501
+failed
+git-annex: enable-tor: 1 failed
+ @(yesod-core-1.6.18-Chd8Br2Wdd9GRfQbrxaPhy:Yesod.Core.Class.Yesod src/Yesod/Core/Class/Yesod.hs:688:5)
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git-annex is working well syncing with my rsync.net account
diff --git a/doc/bugs/Share_with_a_friend_fails/comment_1_d3ba5f786c45e677ea9a7b4a7b36e1a9._comment b/doc/bugs/Share_with_a_friend_fails/comment_1_d3ba5f786c45e677ea9a7b4a7b36e1a9._comment
new file mode 100644
index 0000000000..16378dc40d
--- /dev/null
+++ b/doc/bugs/Share_with_a_friend_fails/comment_1_d3ba5f786c45e677ea9a7b4a7b36e1a9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-08T17:18:08Z"
+ content="""
+So it's trying to run "su -c". Does your OSX have the "osascript"
+command available? It's supposed to use that when available, which is the
+right way to run a command as root on OSX.
+"""]]
diff --git a/doc/bugs/Share_with_a_friend_fails/comment_2_1d5568c00a9b11a05b7fde0d2d3bc327._comment b/doc/bugs/Share_with_a_friend_fails/comment_2_1d5568c00a9b11a05b7fde0d2d3bc327._comment
new file mode 100644
index 0000000000..b6c8e5539c
--- /dev/null
+++ b/doc/bugs/Share_with_a_friend_fails/comment_2_1d5568c00a9b11a05b7fde0d2d3bc327._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="ryan.singer@5db89d157f0565db67eac571e2433fa96c187e32"
+ nickname="ryan.singer"
+ avatar="http://cdn.libravatar.org/avatar/a3ad31fba780a2cbebeeda3f3e627afb"
+ subject="comment 2"
+ date="2020-05-12T23:26:11Z"
+ content="""
+Seems like osascript works, but git annex doesn't seem to be using it.
+"""]]
diff --git a/doc/bugs/Should_try_again_when_network_fails___40__esp._DNS__41__.mdwn b/doc/bugs/Should_try_again_when_network_fails___40__esp._DNS__41__.mdwn
new file mode 100644
index 0000000000..988f986e56
--- /dev/null
+++ b/doc/bugs/Should_try_again_when_network_fails___40__esp._DNS__41__.mdwn
@@ -0,0 +1,50 @@
+### Please describe the problem.
+
+If you have a flaky connection big uploads and downloads will fail. git-annex should try again few times.
+
+This is an example of failed download.
+
+[[!format sh """
+$ git annex get --not --in here
+get File1.bin (from s3...) (gpg) 
+You need a passphrase to unlock the secret key for
+user: "Gioele"
+4096-bit RSA key, ....
+
+gpg: gpg-agent is not available in this session
+
+  ErrorMisc "<socket: 14>: hGetBuf: resource vanished (Connection reset by peer)"
+                        
+  Unable to access these remotes: s3
+
+  Try making some of these repositories available:
+        331fa184-799d-4511-1725-ef2a17ace8b4 -- s3
+        c2a0cfa0-8871-9721-9b81-5649281fabdc -- other
+failed
+get File2.bin (from s3...) 
+
+  Unable to access these remotes: s3
+
+  Try making some of these repositories available:
+        331fa184-799d-4511-1725-ef2a17ace8b4 -- s3
+        c2a0cfa0-8871-9721-9b81-5649281fabdc -- other
+failed
+git-annex: get: 2 failed
+"""]]
+
+This is especially annoying when the DNS is out of order for a few seconds every now and then. In such cases, git-annex will complain, skip very fast to the next file, and repeat this process until it runs out of files. In the end it will have uploaded or downloaded very few files.
+
+Please not that it may not possible to write a simple shell loop to try again as the are GPG passwords to be entered.
+
+Git-annex should try again to upload or download a file in case something goes wrong.
+
+### What version of git-annex are you using? On what operating system?
+
+    git-annex version: 4.20130709.1
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+    local repository version: unknown
+    default repository version: 3
+    supported repository versions: 3 4
+    upgrade supported from repository versions: 0 1 2
+
+Ubuntu 12.04.2 LTS
diff --git a/doc/bugs/Should_try_again_when_network_fails___40__esp._DNS__41__/comment_1_dd792bd98a48554a65150c06401ed3e5._comment b/doc/bugs/Should_try_again_when_network_fails___40__esp._DNS__41__/comment_1_dd792bd98a48554a65150c06401ed3e5._comment
new file mode 100644
index 0000000000..620f5e82e4
--- /dev/null
+++ b/doc/bugs/Should_try_again_when_network_fails___40__esp._DNS__41__/comment_1_dd792bd98a48554a65150c06401ed3e5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 1"
+ date="2013-07-17T18:54:47Z"
+ content="""
+Trying again one time does not seem like it would help, given the example you show. Trying multiple times by default would, I think, be annoying in lots of use cases where one just wants to get whatever is available, and having it get stuck retrying to download a file from a remote that is offline would not be desired when it could move on and get another file from a remote that is online.
+
+I'm willing to consider some kind of option to control how much it retries on error. But I'm not 100% sold on it being better than a simple loop. At least in most cases, using a gpg agent and a loop would work. I suppose the case it would not work as well is if enough time has elapsed for the gpg agent to re-lock the key.
+
+One approach that might work well is to add a --retry-failures-at-end option. It turns out that all failed downloads are already logged (the assistant uses this to automatically retry them), and so it would be easy to add. And rather than retrying immediately after a failure, when transferring multiple files, this puts some space in between, in which the problem may correct itself.
+"""]]
diff --git a/doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex.mdwn b/doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex.mdwn
new file mode 100644
index 0000000000..9bad58b804
--- /dev/null
+++ b/doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex.mdwn
@@ -0,0 +1,43 @@
+### Please describe the problem.
+
+In SmartGit, doing a cherry-pick invokes the following 2 commands.
+
+``git cherry-pick --no-commit <commit-id>``
+``git commit "--author='<name and email>'" "--date='<date-time>'" --file=/var/folders/bw/jh4pq43918gfd_r7qxzkkt_40000gq/T/smartgit3129597356340000806tmp/commit7268815197345344355.tmp``
+
+The error is _git 'annex' is not a git command_.
+
+
+### What steps will reproduce the problem?
+
+``git-annex init <some-name>``
+
+Do some commits in 2 branches.
+Do a cherry-pick in SmartGit.
+
+
+### What version of git-annex are you using? On what operating system?
+
+PLEASE provide instructions here on how to get the git-annex version.
+(It is ``git-annex version``. And why is ``git-annex | less`` blanking out when I press any key?)
+
+git-annex: 5.20151019
+
+OS: Mac OS El Capitan.
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes. Lots. Am an expert at it now.
+
+This can either be a problem with SmartGit, or a problem with the hacks that git-annex puts into a standard git repo.
diff --git a/doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex/comment_1_6fd91f615e8d5212674a9748d1b4135b._comment b/doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex/comment_1_6fd91f615e8d5212674a9748d1b4135b._comment
new file mode 100644
index 0000000000..541eefc41d
--- /dev/null
+++ b/doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex/comment_1_6fd91f615e8d5212674a9748d1b4135b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-12-19T17:51:55Z"
+ content="""
+`git-annex init` sets up .git/hooks/pre-commit to run `git annex pre-commit`.
+It looks like when git commit is run, the git-annex program is not in PATH.
+This probably has something to do with the way you installed git-annex.
+
+(Why is git-annex | less blanking out? Because git-annex outputs usage
+messages to stderr, and less pages stdout. Use git-annex 2>&1 |less)
+"""]]
diff --git a/doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex/comment_2_3dbaf39065c2f0941f8f7092c27fd4cb._comment b/doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex/comment_2_3dbaf39065c2f0941f8f7092c27fd4cb._comment
new file mode 100644
index 0000000000..7f401acd6a
--- /dev/null
+++ b/doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex/comment_2_3dbaf39065c2f0941f8f7092c27fd4cb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="jhannwong@c9c7a67b5632a4bbc0c959cfeb3d340e02f28565"
+ nickname="jhannwong"
+ subject="A problem with SmartGit then?"
+ date="2015-12-21T03:21:58Z"
+ content="""
+> git-annex init sets up .git/hooks/pre-commit to run git annex pre-commit. It looks like when git commit is run, the git-annex program is not in PATH. This probably has something to do with the way you installed git-annex.
+
+``which git-annex`` shows ``/usr/local/bin/git-annex``. I think I installed via Homebrew.
+
+Seems to be a problem with SmartGit then. The pre-commit hooks work just fine in Terminal sessions.
+
+> (Why is git-annex | less blanking out? Because git-annex outputs usage messages to stderr, and less pages stdout. Use git-annex 2>&1 |less)
+
+Ah. Oops.
+"""]]
diff --git a/doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex/comment_3_996139be157e23e17ece9f131b17240a._comment b/doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex/comment_3_996139be157e23e17ece9f131b17240a._comment
new file mode 100644
index 0000000000..3af1b89bcf
--- /dev/null
+++ b/doc/bugs/SmartGit__39__s_Cherry-Pick_function_throws_error_with_git-annex/comment_3_996139be157e23e17ece9f131b17240a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-01-15T20:04:19Z"
+ content="""
+If SmartGit is started from the OSX GUI, and
+/usr/local/bin is added to your PATH in eg .bashrc, there's a good chance
+that the PATH won't include it.
+
+If this were a Linux system, I'd suggest setting the PATH in `.xsessionrc`.
+I don't know what the equivilant is for OSX.
+"""]]
diff --git a/doc/bugs/Strange_case_of_data_loss__44___possibly_linked_to_git-annex_with_encrypted_rsync_remote.mdwn b/doc/bugs/Strange_case_of_data_loss__44___possibly_linked_to_git-annex_with_encrypted_rsync_remote.mdwn
new file mode 100644
index 0000000000..ffa9b5d676
--- /dev/null
+++ b/doc/bugs/Strange_case_of_data_loss__44___possibly_linked_to_git-annex_with_encrypted_rsync_remote.mdwn
@@ -0,0 +1,61 @@
+This is not really a proper bug report, but I thought I should post this here
+in case someone can find any sane, non-supernatural reason for a strange case
+of data loss I have experienced with git-annex.
+
+Some time ago I cloned a bunch of git-annex repos from an external drive (let's
+call it disk1) to a new computer (computer3). On one of my repos git-annex
+marked a bunch of files corrupt and moved them to .git/annex/bad. Oops, I
+thought, I must have a failing disk. Luckily I had offsite backups -- no less
+than two other external hard disks (disk2-3), each having a full copy of the
+repo in question. However, **both of these** had the same, corrupt files. The
+files have the correct size, but are filled with zeroes. Other files in the
+repo are fine, and so are other repos.
+
+I have been trying to wrap my head around this but I can't think of any reason
+how this could occur. However the files have gotten corrupted in the first
+place, the corruption should have been picked up when copying the content to
+the external drives disk2 and disk3, right? I have to rule out NSA/MIB/aliens
+from messing with me because these files are not that valuable or sensitive.
+
+The files in question were added to git-annex back in 2012, so the trail is
+cold on this one. Naturally, I have no idea on how to reproduce this, nor can I
+reliably say that git-annex is to blame. I can gather some hints though. The
+files were all added on the same commit in 2012, but not all files from that
+commit are corrupted. The corrupted files have consecutive file names. The
+files were never modified since (except for the corruption), and the content
+*may* have been copied via an encrypted rsync transfer repository. I have
+always used git-annex on Arch Linux and in indirect more. The files used the
+SHA-1 backend.
+
+All these files have a similar tracking log that looks something like this
+(uuids replaced with symbolic names):
+
+    1356690700.542152s 1 computer1			<- first added
+    1356691074.253815s 1 disk1				<- copied to disk1
+    1356719321.145126s 1 rsync				<- copied to rsync repo
+    1358070999.435676s 1 rsync				<- copied to rsync repo (again?)
+    1362166895.310332s 1 disk2				<- copied to disk2
+    1362906850.555869s 1 computer2 (dead)	<- copied to another computer
+    1364926664.362195s 0 computer1			<- dropped from computer1 as enough copies in disks
+    1374412057.409496s 0 computer2 (dead)	<- dropped from computer2, now dead
+    1445691595.764108s 1 disk3				<- copied to disk3
+    1445770764.165792s 0 rsync				<- dropped from rsync repo to save space
+    1482077052.217353646s 0 disk1			<- first noticed as corrupted on disk1
+    1482741278.318274404s 0 disk3			<- WTF, also corrupted on disk3
+    1482926246.268440532s 0 disk2			<- double-WTF, also corrupted on disk2
+
+The only thing that strikes odd to me is the double entry with the rsync
+remote. The non-corrupted files from the same commit do not seem to have such a
+double entry.
+
+So my main question is, has there ever been a bug in git-annex that could have
+caused this behavior? Or is there any other realistic explanation for this? In
+case this is an existing bug, is there any other evidence I can gather?
+Needless to say, the lesson here is to run `git annex fsck` regularly even if
+you have offsite backups...
+
+> My diagnosis is that the file got corrupted before it was copied to disk2
+> and disk3. What repository they reached them via does not matter much.
+> And indeed, 5 year old git-annex didn't verify the content of
+> files it transferred to/from a remote. Current git-annex does, so I guess 
+> this is [[done]]. --[[Joey]]
diff --git a/doc/bugs/Strange_case_of_data_loss__44___possibly_linked_to_git-annex_with_encrypted_rsync_remote/comment_1_4038261a4d49694374c37ff029d3540f._comment b/doc/bugs/Strange_case_of_data_loss__44___possibly_linked_to_git-annex_with_encrypted_rsync_remote/comment_1_4038261a4d49694374c37ff029d3540f._comment
new file mode 100644
index 0000000000..7c448d6d7b
--- /dev/null
+++ b/doc/bugs/Strange_case_of_data_loss__44___possibly_linked_to_git-annex_with_encrypted_rsync_remote/comment_1_4038261a4d49694374c37ff029d3540f._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="user4"
+ avatar="http://cdn.libravatar.org/avatar/cd0825fd95c541c0a48c7138b59c240a"
+ subject="remote.log"
+ date="2017-06-11T19:53:27Z"
+ content="""
+Since the most likely culprit (after aliens) is the encrypted rsync remote, here is the remote.log. I've replaced
+sensitive information with variables in double curly braces
+
+    {{uuid}} = cipher={{cipher}} cipherkeys={{keyid}} {{url}}= name={{name}} rsyncurl={{url}} type=rsync timestamp=1345706291.523459s
+    {{uuid}} = cipher={{cipher}} cipherkeys={{keyid}} {{url}}= name={{name}} rsyncurl={{url}} type=rsync timestamp=1482178826.391400069s
+    {{uuid}} = cipher={{cipher}} cipherkeys={{keyid}} {{url}}= name={{name}} rsyncurl={{url}} type=rsync timestamp=1482742412.058733547s
+    {{uuid}} = cipher={{cipher}} cipherkeys={{keyid}} {{url}}= name={{name}} rsyncurl={{url}} type=rsync timestamp=1482742686.603751605s
+    {{uuid}} cipher={{cipher}} cipherkeys={{keyid}} name={{name}} rsyncurl={{url}} type=rsync timestamp=1343199142.018003s
+    {{uuid}} cipher={{cipher}} cipherkeys={{keyid}} name={{name}} rsyncurl={{url}} type=rsync timestamp=1343199310.53916s
+    {{uuid}} cipher={{cipher}} cipherkeys={{keyid}} name={{name}} rsyncurl={{url}} type=rsync timestamp=1343486259.34504s
+
+Here {{uuid}} is the uuid of the encrypted rsync remote. It's odd that there are several lines for the same remote, and not all in the same format.
+Could this be a PEBKAC involving a misconfigured rsync remote?
+"""]]
diff --git a/doc/bugs/Stress_test.mdwn b/doc/bugs/Stress_test.mdwn
new file mode 100644
index 0000000000..3bc701bbda
--- /dev/null
+++ b/doc/bugs/Stress_test.mdwn
@@ -0,0 +1,45 @@
+What steps will reproduce the problem?
+
+mkdir annex_stress; cd annex_stress, 
+then execute the following script:
+
+    #! /bin/sh
+    
+    # creating a directory, in which we dump all the files.
+    mkdir probes; cd probes
+    
+    for i in `seq -w 1 25769`; do
+        mkdir probe$i
+        echo "This is an important file, which saved also in backup ('back') directory too.\n Content changes: $i" > probe$i/probe$i.txt
+        echo "This is just an identical content file. Saved in each subdir." > probe$i/defaults.txt
+        echo "This is a variable ($i) content file, which is not backed up in 'back' directory." > probe$i/probe-nb$i.txt
+        mkdir probe$i/back
+        cp probe$i/probe$i.txt probe$i/back/probe$i.txt
+    done
+
+
+It creates about 25000 directory and 3 files in each, two of them are identical.
+
+What is the expected output? What do you see instead?
+
+I expect git annex could import the directory within 12 hours. 
+Yet, it just crashes the gui (starting webapp, uses the cpu 100% and it does not finish after 28hours.)
+
+
+What version of git-annex are you using? On what operating system?
+
+version 2013.04.17
+
+Please provide any additional information below.
+
+I do hope git-annex can be fixed to handle large number of files.
+This stress test models well enough my own directory structure, 
+relatively high number of files relatively low disk space usage 
+(my own directory structure: 750MB, this test creates 605MB).
+
+
+Best, 
+ Laszlo
+
+[[!meta title="assistant Stress test"]]
+[[!tag /design/assistant]]
diff --git a/doc/bugs/Stress_test/comment_10_1694e990eab6592159309c231c6dcc16._comment b/doc/bugs/Stress_test/comment_10_1694e990eab6592159309c231c6dcc16._comment
new file mode 100644
index 0000000000..ec50b58c5a
--- /dev/null
+++ b/doc/bugs/Stress_test/comment_10_1694e990eab6592159309c231c6dcc16._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 10"
+ date="2013-05-06T16:54:36Z"
+ content="""
+My estimate was indeed slightly optimistic. While I did not run the whole import, it did run slower for the later batches of files. As far as I can see, that slowdown is just because git gets slower as it has more files. So nothing I can do about it. git-annex is now scaling well itself, though.
+
+Re checksumming on startup: There was a bug that caused the assistant to re-checksum all direct mode files on startup. This bug was fixed in version 4.20130417. If you're using that version and still see it re-checksumming files, please file a new bug report about it, as this is not intended behavior.
+
+You seem to be saying that the assistant is failing to add some files, and then when stopped and restarted it finds and adds them. I don't quite know how that would happen. If you can provide a test case that I can use to reproduce that behavior, I will try to debug it.
+"""]]
diff --git a/doc/bugs/Stress_test/comment_11_ab4cb6eefd279e6c1f229e089f703581._comment b/doc/bugs/Stress_test/comment_11_ab4cb6eefd279e6c1f229e089f703581._comment
new file mode 100644
index 0000000000..05c409a514
--- /dev/null
+++ b/doc/bugs/Stress_test/comment_11_ab4cb6eefd279e6c1f229e089f703581._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 11"
+ date="2013-05-11T05:36:48Z"
+ content="""
+rechecksuming: it seem like it is indeed fixed in the newest (2013.05.01) version downloaded from here:
+http://downloads.kitenet.net/git-annex/linux/
+
+I tried to add the big stress test dir as a secondary repository into git-annex (along with my real data dir), but 
+seems like some library is not matching on my system, so some curl is complaining:
+
+    curl: /lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.12' not found (required by /home/user/Desktop/down/git-annex.linux//usr/lib/i386-linux-gnu/libldap_r-2.4.so.2)
+
+I'm on ubuntu 10.04.
+
+And the log file is starting to fill up, so maybe once a problem occur, it should only write into the log file once.
+
+I will redone this stress test next week, without combining with any repository.
+Thank you very much for your response, I do appreciate you are bothering/dealing with my complains!:)
+
+Best, 
+ Laszlo
+
+"""]]
diff --git a/doc/bugs/Stress_test/comment_1_c4c764488ac082f5c48d3a6b4b5fba42._comment b/doc/bugs/Stress_test/comment_1_c4c764488ac082f5c48d3a6b4b5fba42._comment
new file mode 100644
index 0000000000..42750808b7
--- /dev/null
+++ b/doc/bugs/Stress_test/comment_1_c4c764488ac082f5c48d3a6b4b5fba42._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-23T20:00:31Z"
+ content="""
+Is this related or unrelated to the bug you filed at [[Resource_exhausted]]?
+
+I tried this test, and noticed that it was taking the assistant rather a long time to get to the 10 thousand file threshhold where it makes a batch commit. A small change to a better data structure for its queue reduced that time from probably 10 minutes to 2.5. 
+
+I was unable to reproduce any problem with the webapp. Please provide lots of details to back up \"it just crashes the GUI\".
+
+The main problem with this directory tree is that it has more directories than inotify can watch, in the default configuration. 
+So after it adds the first 8192 directories, it begins failing to watch any more, and printing a message about you needing to increase the inotify limits for each additional directory. I don't think that 51 thousand directories is a particularly realistic amount for any real-world usage of git-annex. (It will also break file manager, dropbox, etc, which all use inotify in the same way.)
+
+The other main time sink is that git-annex needs to run `git hash-object` once per file to stage its symlink. That is a lot of processes to run, and perhaps it could be sped up by using `git fast-import`.
+"""]]
diff --git a/doc/bugs/Stress_test/comment_2_42125bba09a0ea9821cda7183e458100._comment b/doc/bugs/Stress_test/comment_2_42125bba09a0ea9821cda7183e458100._comment
new file mode 100644
index 0000000000..26ffe2d62d
--- /dev/null
+++ b/doc/bugs/Stress_test/comment_2_42125bba09a0ea9821cda7183e458100._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 2"
+ date="2013-04-24T06:30:16Z"
+ content="""
+Hi,
+
+First of all thank you for your time looking into my bug. I try to research more from my side.
+
+The 'Resource exhausted' bugreport 
+(which lost its title, and could not click on it to add this testcase as a comment)
+was tested on real data, my own working directory (a copy of it).
+This bugreport is tested on the output of this small shell script.
+
+None of them succeeded to import, and I quickly assumed it is the exact same.
+
+So I will test again, raising the ulimit to 81920, and report.
+
+    The main problem with this directory tree is that it has more directories than inotify can watch, in the default configuration
+
+I would be perfectly fine if I could configure git-annex to sync those directory only once a month or once a week
+(ie. check for update once a week). So no need to watch it real time, those are my archived work files.
+
+    I don't think that 51 thousand directories is a particularly realistic amount for any real-world usage of git-annex.
+
+Well, it is not 25000 dir in a single a folder, but rather something like this:
+
+    work_done/2009/workname/back9/back8/back7/back6/back5
+
+Where each 'backX' contains a whole backup the work until it. 
+So the directory structure is a bit more deep, and no 25000 subdirectory in a single dir. 
+But the overall numbers are right.
+
+If I could somehow mark this **work_done** dir to not sync real time (or work_done/2008,work_done/2009,work_done/2010,work_done/2011,work_done/2012 subdir in them), 
+then my whole issue would vanish.
+
+I only want to use git-annex to have a backup of this directory. 
+In case of laptop theft, or misfunction I could have a backup. 
+I dont need live sync anywhere, I have directories which I know I will not touch for months.
+
+Best,
+ Laszlo
+
+
+
+"""]]
diff --git a/doc/bugs/Stress_test/comment_3_8240e61106b494d3600ad91f16eb5b1c._comment b/doc/bugs/Stress_test/comment_3_8240e61106b494d3600ad91f16eb5b1c._comment
new file mode 100644
index 0000000000..8469f489fd
--- /dev/null
+++ b/doc/bugs/Stress_test/comment_3_8240e61106b494d3600ad91f16eb5b1c._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 3"
+ date="2013-04-24T09:10:20Z"
+ content="""
+    (It will also break file manager, dropbox, etc, which all use inotify in the same way.)
+
+I beg to differ: with dropbox I handle my scrapbook(1) folder, 
+which means 130 thousand files for over 2 years now without problem between three computers.
+
+    ~/Dropbox/scrapbook$ ls -R -1 |wc -l
+    130263
+
+Don't get me wrong. I'm not complaining, I only give you a completely unrelated usecase, 
+which requires also high number of files handling. And in that case the 81 thousand ulimit would not help either.
+
+(1): https://addons.mozilla.org/hu/firefox/addon/scrapbook/
+
+"""]]
diff --git a/doc/bugs/Stress_test/comment_4_c38d84e0dcc834931804c44bce7f7b7a._comment b/doc/bugs/Stress_test/comment_4_c38d84e0dcc834931804c44bce7f7b7a._comment
new file mode 100644
index 0000000000..c7cdd4bfd9
--- /dev/null
+++ b/doc/bugs/Stress_test/comment_4_c38d84e0dcc834931804c44bce7f7b7a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-04-24T15:05:33Z"
+ content="""
+You're confusing number of files (inotify doesn't care) with number of directories (inotify does care).
+
+Dropbox is on record about being limited in the number of directories it can watch without adjusting the inotify limit. 
+<https://www.dropbox.com/help/145>
+"""]]
diff --git a/doc/bugs/Stress_test/comment_5_60ce20ee255451c4ea809ba475561adb._comment b/doc/bugs/Stress_test/comment_5_60ce20ee255451c4ea809ba475561adb._comment
new file mode 100644
index 0000000000..820f04ba99
--- /dev/null
+++ b/doc/bugs/Stress_test/comment_5_60ce20ee255451c4ea809ba475561adb._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 5"
+ date="2013-04-24T15:30:04Z"
+ content="""
+I found a bug in the webapp thanks to this stress test. When inotify goes over limit, it displays a message about how to fix it..
+But it displays that message over and over for each file. The result is a constantly updating very large web page. 
+
+Unless you tell me differently, I'm going to assume that's what the GUI crash you referred to was, since it can make a web browser very slow.
+
+I've fixed this problem. Now when it goes over limit, the webapp will just display this:
+
+[[/assistant/inotify_max_limit_alert.png]]
+"""]]
diff --git a/doc/bugs/Stress_test/comment_6_1371562e201393986cd41597f6f288cb._comment b/doc/bugs/Stress_test/comment_6_1371562e201393986cd41597f6f288cb._comment
new file mode 100644
index 0000000000..26f14ef092
--- /dev/null
+++ b/doc/bugs/Stress_test/comment_6_1371562e201393986cd41597f6f288cb._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 6"
+ date="2013-04-24T17:26:39Z"
+ content="""
+I put in a further change to reduce the number of alerts shown in the webapp when bulk adding files. This probably quadrupled the speed or more, even when the webapp was not running, as updating an alert every time a file was added was a lot of unnecessary work.
+
+After these changes, it adds the first 10 thousand files in 35 minutes, on my five year old netbook. It should scale linear
+(aside from git's own scalability issues with a lot of files, which I don't think are very bad under 1 million files),
+so adding all 100 thousand files should take 6 hours or so.
+
+I'm interested to see what results you get, compared with before..
+"""]]
diff --git a/doc/bugs/Stress_test/comment_7_a14be7699da224a8f6c9b34f1b911219._comment b/doc/bugs/Stress_test/comment_7_a14be7699da224a8f6c9b34f1b911219._comment
new file mode 100644
index 0000000000..3d02a27184
--- /dev/null
+++ b/doc/bugs/Stress_test/comment_7_a14be7699da224a8f6c9b34f1b911219._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 7"
+ date="2013-04-24T21:02:55Z"
+ content="""
+A few more changes got the rate down to 21 minutes per 10 thousand files. Estimate 3.5 hours for all.
+"""]]
diff --git a/doc/bugs/Stress_test/comment_8_a01995bdca7ade7dde9842b53fbc4e0c._comment b/doc/bugs/Stress_test/comment_8_a01995bdca7ade7dde9842b53fbc4e0c._comment
new file mode 100644
index 0000000000..d12b7ebfea
--- /dev/null
+++ b/doc/bugs/Stress_test/comment_8_a01995bdca7ade7dde9842b53fbc4e0c._comment
@@ -0,0 +1,57 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="Definite improvement"
+ date="2013-05-03T06:27:12Z"
+ content="""
+Hi,
+
+I have just tried it out again with the latest (20130501) version.
+
+It is really nice to see you have been working on it, and it have improved tremendously!
+The logging issue solved, and logrotates even, and it finished importing without crashing!
+
+Remaining polishing things:
+
+a)
+The import time is not as good (as you write), it slowes itself down.
+It is true the first 10000 files import in about an hour, but it finishes with everything
+in 9 hours 20 minutes.
+(on a normal laptop, the last 5000 file portion took more then 2 hours)
+
+b) 
+Every startup means rechecksuming everything, so it means the second start took also around 8-12 hours.
+(I don't know exactly because it finished somewhere during the night, but it was longer then 8 hours)
+I don't think rechecksuming is necessary at all, if the filename, size and date have not modified, 
+then why rechecksuming (sha) it?
+
+
+c) 
+It is leaking. 
+At the second startup, it reported it successfully added:
+    Added 2375 files 5 files probe25366.txt
+
+I have not touched the directory. ls confirms leaking:
+
+    After first start (importing):
+    annex_many/.git$ ls -lR |wc -l
+    770199
+
+    After second startup:
+    annex_many/.git$ ls -lR |wc -l
+    788351
+
+d) Without ulimit raise, it does not work at all.
+I think it could be solved by not watching each and every directory all the time.
+Every users will likely have a working directory and some which he don't intend to touch/modify at all.
+Some usecases: photo archiving, video archiving, finished work archiving, etc
+
+All the above results with the stress test script. 
+I would love to have a confirmation by a thirdparty.
+
+Overall I'm impressed with the work you have done.
+
+Best, 
+ Laszlo
+
+"""]]
diff --git a/doc/bugs/Stress_test/comment_9_9f7efe81b7e40aaa04a865394c53e20f._comment b/doc/bugs/Stress_test/comment_9_9f7efe81b7e40aaa04a865394c53e20f._comment
new file mode 100644
index 0000000000..a82b98611c
--- /dev/null
+++ b/doc/bugs/Stress_test/comment_9_9f7efe81b7e40aaa04a865394c53e20f._comment
@@ -0,0 +1,52 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="Maybe it is not leaking after all"
+ date="2013-05-03T18:37:48Z"
+ content="""
+I have been working the whole day zipping up (tar.gz) all the unused directories.
+Now my real data dir looks like this:
+
+    ./annex_real/work_done$ du -hs .
+    1,1G	.
+    Has 9088 files and 1608 directories in total:
+    ./annex_real/work_done$ ls -R1l |grep \\-r |wc -l
+    9088
+    ./annex_real/work_done$ ls -R1l |grep ^d |wc -l
+    1608
+
+When I first started git annex, it added 5492 files, then next time it added the missing 3596 files. Then it stopped adding files.
+From the gui everything looked fine even at the first start (performed startup scan), even in the log files (daemon.log.x) was nothing suspicious.
+
+    ./annex_real/work_done$ for i in ../.git/annex/daemon.log.*; do echo $i; cat $i |grep files; done
+     ../.git/annex/daemon.log.1
+     ../.git/annex/daemon.log.2
+     ../.git/annex/daemon.log.3
+     ../.git/annex/daemon.log.4
+     [2013-05-03 20:03:34 CEST] Committer: Adding 3596 files
+     ../.git/annex/daemon.log.5
+     [2013-05-03 19:15:22 CEST] Committer: Adding 5492 files
+
+As you can see, this case is not a stress test at all, 
+it is really the minimal test case, 1.1GB diskspace, 9088 files and a thousand dirs. 
+The real question is, why git-annex miss at the first startup 3492 files (ie. adding all the files).
+
+It would help tremendously, if it would display at startup how many files he found, 
+and when it adds, then how many left to be added.
+Something like this:
+
+    (scanning...) [2013-05-03 20:03:14 CEST] Watcher: Performing startup scan
+    (started...)
+    [2013-05-03 20:03:34 CEST] Committer: Found 9088 files
+    [2013-05-03 20:03:34 CEST] Committer: Adding 3596 files of 9088 remaining files (9088 in total)
+    ....
+    [2013-05-03 20:05:04 CEST] Committer: Adding 1492 files of 5492 remaining files (9088 in total)
+    ....
+    [2013-05-03 20:06:02 CEST] Committer: Adding 4000 files of 4000 remaining files (9088 in total)
+
+So it is definietly a bug, and I stuck how to debug it further. Everything looks just fine.
+
+Best, 
+ Laszlo
+
+"""]]
diff --git a/doc/bugs/Support_manual_configuration_of_tor_hidden_service.mdwn b/doc/bugs/Support_manual_configuration_of_tor_hidden_service.mdwn
new file mode 100644
index 0000000000..59d863c381
--- /dev/null
+++ b/doc/bugs/Support_manual_configuration_of_tor_hidden_service.mdwn
@@ -0,0 +1,23 @@
+### Please describe the problem.
+I am running NixOS, so the automatic configuration of the tor hidden service does not work because system state is not mutable. Could you provide a way to configure the tor hidden service manually, perhaps printing out the configuration instead of installing it?
+
+### What steps will reproduce the problem?
+N/A
+
+### What version of git-annex are you using? On what operating system?
+7.2, NixOS
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Yes, I love it.
+
+
diff --git a/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_1_643a8e22d6ffd27a5497c077e4ce3bcd._comment b/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_1_643a8e22d6ffd27a5497c077e4ce3bcd._comment
new file mode 100644
index 0000000000..a39942bfdc
--- /dev/null
+++ b/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_1_643a8e22d6ffd27a5497c077e4ce3bcd._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="petersjt014@c20995a2e26a13566cd49aef30a99a7dff732a4e"
+ nickname="petersjt014"
+ avatar="http://cdn.libravatar.org/avatar/3664265775c485eca0cf7c2e0028192b"
+ subject="tor remote"
+ date="2020-07-03T07:33:54Z"
+ content="""
+I have come across what I think is the 'right' way to do this: there seems to be [an option](https://nixos.org/nixos/options.html#services.tor.hiddenservices) where the service can be specified, which would eliminate the need for a manual configuration (note: you can also do `man configuration.nix` and /-search for it if you didn't know).
+
+Now comes the problem: I'm not sure what to actually _put_ in it. Ports seem like a good place to start, and I've done some digging to try and determine which ones to use
+
+After starting the remote manually, I think the answer might be apparent in `sudo netstat -leepnuta --wide | grep -E 'Proto|tor|annex'`, but I'm not sure--my networking knowledge is limited. 40449 could be relevant, since it appears so frequently. There's also _lots_ of random 5-digit ones. I thought they might be ephermeral, but not all of them are within [that range](https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers#Dynamic,_private_or_ephemeral_ports).
+
+Also worth noting: After letting git-annex create the torrc file by changing a bunch of permissions I probably shouldn't, the line where the socket is specified starts with `HiddenServicePort 28913`, although that port is not found within netstat (suggesting that I haven't got the remote actually working).
+
+That's all I got so far. I will be messing with it more though.
+"""]]
diff --git a/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_2_90deb38d083cfac454bf364884ce06c6._comment b/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_2_90deb38d083cfac454bf364884ce06c6._comment
new file mode 100644
index 0000000000..6addbc360b
--- /dev/null
+++ b/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_2_90deb38d083cfac454bf364884ce06c6._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-08-10T18:17:29Z"
+ content="""
+The port can be any otherwise unused port of the system.
+
+The service's unix socket file has to have a name that ends
+with the uuid of the git-annex repository that's going to use it,
+because git-annex parses torrc to find that.
+
+And git-annex has to know what the port and onion address are
+to construct the base p2p address ("tor-annex:$onionaddr:$port").
+That gets stored in `.git/annex/p2paddrs`.
+
+Otherwise, you can use more or less whatever tor configuration you want to.
+"""]]
diff --git a/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_3_59fe23f38b4bb70e629b0c7c698d1438._comment b/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_3_59fe23f38b4bb70e629b0c7c698d1438._comment
new file mode 100644
index 0000000000..e3e65561f5
--- /dev/null
+++ b/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_3_59fe23f38b4bb70e629b0c7c698d1438._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-08-10T18:37:49Z"
+ content="""
+If you write up a [[tip|tips]] documenting how to manually set one up
+(nix specific would be fine), then it might make sense to simplify that
+documentation with a command like:
+
+	git-annex-enable-tor --already-configured --onion-address=... --hidden-service-port=...
+
+To avoid needing to manually write data into .git/annex/
+
+I think that and documentation is all that's needed, and that command
+on its own is not very useful w/o documentation of the full manual setup,
+which is why I suggest you write the documentation first.
+"""]]
diff --git a/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_4_20c00e22eff7cb5a5f907895bf4b0b44._comment b/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_4_20c00e22eff7cb5a5f907895bf4b0b44._comment
new file mode 100644
index 0000000000..88723c9e31
--- /dev/null
+++ b/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_4_20c00e22eff7cb5a5f907895bf4b0b44._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-08-24T15:05:10Z"
+ content="""
+Someone wrote a tip explaining how to do it: [[tips/enable_tor_on_nixos]]
+
+It might be that some simple changes to git-annex enabletor could simplify
+the process documented there. An option to control where the torrc file
+is comes to mind.
+"""]]
diff --git a/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_5_7e6e7c0ce27504273be3e5bc27685d93._comment b/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_5_7e6e7c0ce27504273be3e5bc27685d93._comment
new file mode 100644
index 0000000000..d7314a9071
--- /dev/null
+++ b/doc/bugs/Support_manual_configuration_of_tor_hidden_service/comment_5_7e6e7c0ce27504273be3e5bc27685d93._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="nothingmuch@486b0e001f63ad0513f9fc6921a31f08832ba22d"
+ nickname="nothingmuch"
+ avatar="http://cdn.libravatar.org/avatar/81912bc5ca02376f99a5ee44531dee27"
+ subject="comment 5"
+ date="2021-08-26T21:19:43Z"
+ content="""
+Yep, I wrote that tip partly to document how to do it and partly to provoke this discussion =)
+
+As a user what I think I would find the most useful is an option like you described (and a related option for specifying the path to the torrc file) which will detect and enable an already configured hidden service, but just prints the configuration you should add instead of adding it itself to torrc. With a third option to manually specify the hidden service address no root privs would be needed either. The last useful thing I can think of is to relax the `socketFile` matching in the code, so that if the repo UUID appears anywhere in the path and the file is accessible, that seems sufficiently unambiguous to me, and when doing this check it would also be helpful to report permission errors clearly.
+
+Such functionality should provide a reasonable UX not only for nix/guix users, but also anyone who is running tor as a user service.
+"""]]
diff --git a/doc/bugs/Symlink_support_on_Windows_10_Creators_Update_with_Developer_Mode.mdwn b/doc/bugs/Symlink_support_on_Windows_10_Creators_Update_with_Developer_Mode.mdwn
new file mode 100644
index 0000000000..b0ea928205
--- /dev/null
+++ b/doc/bugs/Symlink_support_on_Windows_10_Creators_Update_with_Developer_Mode.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+Since the Win10 Creators Update, if Developer Mode is enabled, symlinks can be created without elevated privileges. During cloning of a repository with symlinks, git detects this and creates symbolic links, whereas in the past it would simply create text-like files with a path.
+
+When symlinks are created, git-annex breaks in many wonderful ways. The symlinks are not detected as annexed files and `git annex info` shows that no files are in the annex.
+
+### What steps will reproduce the problem?
+On a Windows 10 machine with Creators update (v1709) and Developer mode enabled, do a `git clone` of a git-annex repository. Then `git annex init` and `git annex info`.
+
+Additionally, if a `git annex sync` is performed, the symlinks are deleted.
+
+### What version of git-annex are you using? On what operating system?
+v6.20180112 on Windows 10 with update 1709.
+
+### Please provide any additional information below.
+Since the aforementioned Windows update (commonly referred to as Creators Update), the mklink command can be executed without requiring elevated privileges if Developer mode is enabled.
+See the following two articles for some background:
+
+- [Windows 10 Creators Update: Symlinks without elevation
+ [ghacks.net]](https://www.ghacks.net/2016/12/04/windows-10-creators-update-symlinks-without-elevation/)
+- [What Is “Developer Mode” in Windows 10? [howtogeek.com]](https://www.howtogeek.com/292914/what-is-developer-mode-in-windows-10/)
+
+It would seem that git detects this and does not disable symlinks as git-annex expects it to do on Windows.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Yes. I use it frequently on multiple platforms.
+
diff --git a/doc/bugs/Sync_fails_when_borg_remote_is_inaccessible.mdwn b/doc/bugs/Sync_fails_when_borg_remote_is_inaccessible.mdwn
new file mode 100644
index 0000000000..46cfc3daa4
--- /dev/null
+++ b/doc/bugs/Sync_fails_when_borg_remote_is_inaccessible.mdwn
@@ -0,0 +1,83 @@
+### Please describe the problem.
+
+When a Borg special remote becomes inaccessible, git-annex sync interprets it as
+a failed sync. This contrasts from the behavior of git-annex sync when a regular
+git-annex repository is not available, where it'll be skipped instead.
+
+My workflow involves backup drives that aren't always connected, which can make
+this behavior somewhat confusing to see.
+
+### What steps will reproduce the problem?
+
+1. Create a git-annex and BorgBackup repository.
+
+2. Set up borg repository as a special remote.
+
+3. Move borg repository to another location.
+
+4. Attempt to sync, expecting git-annex to skip the borg repository and exit
+   with a success regardless. Instead, git-annex exits with a failure.
+
+See below for a script that produces this error for me.
+
+### What version of git-annex are you using? On what operating system?
+
+Using the Guix package on Fedora.
+
+```
+git-annex version: 10.20230626
+build flags: Assistant Webapp Pairing Inotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.23 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.2.5 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+### Please provide any additional information below.
+
+[[!format sh """
+#!/usr/bin/env sh
+
+# Initialize git-annex and borg repository
+
+git init repo
+cd repo
+git-annex init 'git-annex repository'
+borg init --encryption=none ../repo.borg
+git-annex initremote borg-repository type=borg borgrepo=../repo.borg
+
+# Sync works as expected when repository is found
+
+echo asdf > testfile
+git-annex assist
+
+# Simulate borg repository becoming inaccessible, which results in a failed sync
+
+mv ../repo.borg ../repo.borg.tmp
+git-annex sync
+"""]]
+
+The following is what `git-annex sync` produces:
+
+```
+git-annex sync will change default behavior to operate on --content in a future version of git-annex. Recommend you explicitly use --no-content (or -g) to prepare for that change. (Or you can configure annex.synccontent)
+commit  
+On branch master
+nothing to commit, working tree clean
+ok
+list borg-repository Repository /home/alvin/Downloads/test/repo.borg does not exist.
+
+git-annex: Unable to list contents of borg-repository: user error (borg ["list","--format","{barchive}{NUL}","../repo.borg"] exited 2)
+failed
+sync: 1 failed
+```
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Been working on an addon command that I'll hopefully get quality enough to be
+worth adding to the related software section soon :)
+
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/Sync_fails_when_borg_remote_is_inaccessible/comment_1_5e83630a60aa0242969bd1279a70628a._comment b/doc/bugs/Sync_fails_when_borg_remote_is_inaccessible/comment_1_5e83630a60aa0242969bd1279a70628a._comment
new file mode 100644
index 0000000000..70684e3064
--- /dev/null
+++ b/doc/bugs/Sync_fails_when_borg_remote_is_inaccessible/comment_1_5e83630a60aa0242969bd1279a70628a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-08-15T16:59:11Z"
+ content="""
+Note that same thing happens when a directory special remote is configured
+with importtree=yes exporttree=yes and the directory gets moved out of the
+way. (Well, it does now.. Previously it failed to fail and imported an empty
+tree, which was much worse a bug.)
+
+Failure to access the borg repo doesn't prevent the rest of the sync from
+happening though. It still syncs with other remotes.
+
+Yes, there is a special case in sync to skip local git repositories that
+are not present. Skipping borg and directory special remotes would need
+that special case to be improved to an interface.
+"""]]
diff --git a/doc/bugs/Sync_fails_when_borg_remote_is_inaccessible/comment_2_eff73163e8a7ae09ceeb596fca04c507._comment b/doc/bugs/Sync_fails_when_borg_remote_is_inaccessible/comment_2_eff73163e8a7ae09ceeb596fca04c507._comment
new file mode 100644
index 0000000000..106c64be7b
--- /dev/null
+++ b/doc/bugs/Sync_fails_when_borg_remote_is_inaccessible/comment_2_eff73163e8a7ae09ceeb596fca04c507._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-08-16T20:01:21Z"
+ content="""
+Made sync skip many kinds of remotes that use a directory when the
+directory does not exist.
+"""]]
diff --git a/doc/bugs/Syncing_bare_repository_doesn__39__t_work_after_using_watch_on_Windows.mdwn b/doc/bugs/Syncing_bare_repository_doesn__39__t_work_after_using_watch_on_Windows.mdwn
new file mode 100644
index 0000000000..34f310b43f
--- /dev/null
+++ b/doc/bugs/Syncing_bare_repository_doesn__39__t_work_after_using_watch_on_Windows.mdwn
@@ -0,0 +1,93 @@
+### Please describe the problem.
+
+After initializing a (indirect) repository on my Linux PC and git cloning it on a FAT32 formatted USB drive (direct mode), git annex sync worked fine.
+After using it on a Windows system (git annex watch), I took it back to the Linux machine. Now doing git annex sync on the USB drive repository lead to:
+
+    (usb drive) $ git annex sync
+    commit  ok
+
+      There are no commits yet in the currently checked out branch, so cannot merge any remote changes into it.
+    failed
+    pull PC 
+    ....
+    merge: refs/remotes/PC/annex/direct/master - not something we can merge
+    merge: refs/remotes/PC/synced/master - not something we can merge
+    failed
+    (merging origin/git-annex into git-annex...)
+    git-annex: sync: 2 failed
+    $ git fsck
+    Checking object directories: 100% (256/256), done.
+    $ git annex fsck
+    fsck blah.pdf (checksum...) ok
+    fsck foo.pdf (checksum...) ok
+    fsck bar.pdf (checksum...) ok
+    ...
+    (recording state in git...)
+
+Note that for some reason it mentions the ref refs/remotes/PC/annex/direct/master - which doesn't exist, because the Linux PC repo is in indirect mode.
+
+### What steps will reproduce the problem?
+
+1. git init / git annex init on a ext* drive under Linux
+2. git sync it to a FAT32-formatted (USB) drive
+3. git annex init on the USB drive
+4. add each others as remote
+5. git sync each other - works fine
+6. Change into a Windows system
+7. git annex watch inside the git annex repository under Windows
+8. add some files, they are committed (says daemon.log)
+9. Ctrl+C git annex watch, unmount drive...
+10. Change back to a Linux system
+11. git annex sync from the annex repository on USB
+
+
+### What version of git-annex are you using? On what operating system?
+
+Gentoo:
+
+    git-annex version: 6.20170611-gb493ac8d3
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
+Windows 10:
+
+    git-annex version: 6.20170611-gb493ac8
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV ConcurrentOutput TorrentParser Feeds Quvi
+    dependency versions: aws-0.14.0 bloomfilter-2.0.1.0 cryptonite-0.7 DAV-1.3.1 feed-0.3.11.1 ghc-7.10.2 http-client-0.4.31.1 persistent-sqlite-2.2 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 2 3 4 5
+    operating system: mingw32 i386
+
+### Please provide any additional information below.
+
+[[!format sh """
+# daemon.log from git watch
+[2017-08-16 13:16:01.6773524] main: starting watch version 6.20170611-gb493ac8
+(scanning...) [2017-08-16 13:16:02.0049693] Watcher: Performing startup scan
+(started...) 
+[2017-08-16 13:16:03.0007698] Committer: Committing changes to git
+(recording state in git...)
+[2017-08-16 13:16:51.420494] Committer: Adding annex3.txt
+add annex3.txt ok
+[2017-08-16 13:16:51.771892] Committer: Committing changes to git
+(recording state in git...)
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Used it under only-linux before. I especially like the location tracking.
+
+
+Also tried using special remotes (mega.nz) with encryption - although I was very confused at first that you need the private key for the hybrid approach. After some reading I think I need sharedpubkey? (I just wanna use it for myself, but don't wanna insert the smartcard where my private key is stored every time for sending the files to the remote).
diff --git a/doc/bugs/Syncing_bare_repository_doesn__39__t_work_after_using_watch_on_Windows/comment_1_e197b8dc0eae0dd6dea4febdc2ecce53._comment b/doc/bugs/Syncing_bare_repository_doesn__39__t_work_after_using_watch_on_Windows/comment_1_e197b8dc0eae0dd6dea4febdc2ecce53._comment
new file mode 100644
index 0000000000..d386792800
--- /dev/null
+++ b/doc/bugs/Syncing_bare_repository_doesn__39__t_work_after_using_watch_on_Windows/comment_1_e197b8dc0eae0dd6dea4febdc2ecce53._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/8a69a637-97cb-41e6-8f45-00f08ba54d6e"
+ nickname="Andreas Duering"
+ avatar="http://cdn.libravatar.org/avatar/915cf485815ded2f7f4b68736994c185ecda8c31dd293acd16f5e21ca7db23e1"
+ subject="comment 1"
+ date="2017-08-16T17:10:58Z"
+ content="""
+Oh, and by the way: The bug does *not* occur if you don't use git annex watch, but git annex add the files manually under Windows.
+
+(In this case, I have a weird drive letter problem, probably (can't figure out how to make the link work) bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail)
+"""]]
diff --git a/doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant.mdwn b/doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant.mdwn
new file mode 100644
index 0000000000..590c862057
--- /dev/null
+++ b/doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant.mdwn
@@ -0,0 +1,134 @@
+### Please describe the problem.
+
+Since I last tested git-annex (version 4.20130516.1) my setup seems to no longer work in current versions (5.20131130)
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+$ mkdir 1 2
+$ cd 1; git init; git-annex init; git annex direct; echo "file added to 1" > file_from_1; cd ..
+Initialized empty Git repository in /home/pedrocr/testannexbug/1/.git/
+init  ok
+(Recording state in git...)
+commit  
+# On branch master
+#
+# Initial commit
+#
+nothing to commit (create/copy files and use "git add" to track)
+ok
+direct  ok
+$ cd 2; git init; git-annex init; git annex direct; echo "file added to 2" > file_from_2; cd ..
+Initialized empty Git repository in /home/pedrocr/testannexbug/2/.git/
+init  ok
+(Recording state in git...)
+commit  
+# On branch master
+#
+# Initial commit
+#
+nothing to commit (create/copy files and use "git add" to track)
+ok
+direct  ok
+$ cd 1; git remote add 2 ssh://localhost/~pedrocr/Hacks/test-git-annex/2; git annex assistant; cd ..
+$ cd 2; git remote add 1 ssh://localhost/~pedrocr/Hacks/test-git-annex/1; git annex assistant; cd ..
+$ ls -la 1
+total 20
+drwxrwxr-x 3 pedrocr pedrocr 4096 Dec 15 11:33 .
+drwxrwxr-x 4 pedrocr pedrocr 4096 Dec 15 11:33 ..
+-rw-rw-r-- 1 pedrocr pedrocr   16 Dec 15 11:33 file_from_1
+-rw-r--r-- 1 pedrocr pedrocr   16 Dec 15 11:33 file_from_2
+drwxrwxr-x 9 pedrocr pedrocr 4096 Dec 15 11:33 .git
+$ ls -la 2
+total 20
+drwxrwxr-x 3 pedrocr pedrocr 4096 Dec 15 11:33 .
+drwxrwxr-x 4 pedrocr pedrocr 4096 Dec 15 11:33 ..
+-rw-r--r-- 1 pedrocr pedrocr   16 Dec 15 11:33 file_from_1
+-rw-rw-r-- 1 pedrocr pedrocr   16 Dec 15 11:33 file_from_2
+drwxrwxr-x 9 pedrocr pedrocr 4096 Dec 15 11:33 .git
+"""]]
+
+so far so good
+
+[[!format sh """
+$ date | tee 1/file_from_1
+Sun Dec 15 11:53:18 WET 2013
+$ date | tee 2/file_from_2
+Sun Dec 15 11:53:22 WET 2013
+$ cat 1/*
+Sun Dec 15 11:53:18 WET 2013
+file added to 2
+$ cat 2/*
+file added to 1
+Sun Dec 15 11:53:22 WET 2013
+$
+"""]]
+
+But then syncing doesn't work. There doesn't seem to be anything special in the logs
+
+[[!format sh """
+$ tail -n 20 1/.git/annex/daemon.log 
+(Recording state in git...)
+add file_from_1 (checksum...) [2013-12-15 11:53:18 WET] Committer: Committing changes to git
+[2013-12-15 11:53:18 WET] Pusher: Syncing with 2 
+
+file_from_1
+          29 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/1)
+
+sent 104 bytes  received 31 bytes  270.00 bytes/sec
+total size is 29  speedup is 0.21
+[2013-12-15 11:53:18 WET] Transferrer: Uploaded file_from_1
+Already up-to-date.
+To ssh://localhost/~pedrocr/Hacks/test-git-annex/2
+   f025062..431ac37  git-annex -> synced/git-annex
+   d393bb3..fef60ca  annex/direct/master -> synced/master
+Already up-to-date.
+[2013-12-15 11:53:21 WET] Pusher: Syncing with 2 
+To ssh://localhost/~pedrocr/Hacks/test-git-annex/2
+   431ac37..3cc7045  git-annex -> synced/git-annex
+
+
+$ tail -n 20 2/.git/annex/daemon.log 
+(Recording state in git...)
+add file_from_2 (checksum...) [2013-12-15 11:53:22 WET] Committer: Committing changes to git
+[2013-12-15 11:53:22 WET] Pusher: Syncing with 1 
+
+file_from_2
+          29 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/1)
+Already up-to-date.
+
+sent 104 bytes  received 31 bytes  270.00 bytes/sec
+total size is 29  speedup is 0.21
+[2013-12-15 11:53:22 WET] Transferrer: Uploaded file_from_2
+To ssh://localhost/~pedrocr/Hacks/test-git-annex/1
+   ebbcd4c..dae7a77  git-annex -> synced/git-annex
+   ffd5a90..67ad7c1  annex/direct/master -> synced/master
+Already up-to-date.
+[2013-12-15 11:53:25 WET] Pusher: Syncing with 1 
+To ssh://localhost/~pedrocr/Hacks/test-git-annex/1
+   dae7a77..976c899  git-annex -> synced/git-annex
+"""]]
+
+
+
+### What version of git-annex are you using? On what operating system?
+
+I'm running git-annex from the Ubuntu PPA on Ubuntu 12.04 LTS.
+
+[[!format sh """
+$ lsb_release -v
+No LSB modules are available.
+$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 12.04.3 LTS
+Release:	12.04
+Codename:	precise
+$ git annex version
+git-annex version: 5.20131130
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus XMPP Feeds Quvi TDFA
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav glacier hook
+"""]]
+
+> [[!taglink moreinfo]] needed. --[[Joey]]
diff --git a/doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant/comment_1_8100505a7ac74646e0767d03fe643a45._comment b/doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant/comment_1_8100505a7ac74646e0767d03fe643a45._comment
new file mode 100644
index 0000000000..337bd12b05
--- /dev/null
+++ b/doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant/comment_1_8100505a7ac74646e0767d03fe643a45._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 1"
+ date="2013-12-16T20:48:12Z"
+ content="""
+Sounds to me like it could be a messed up direct mode mapping file due to bugs in version 4.20130516. But I am not sure I follow your transcript; you don't seem to show how things looked when it went wrong. If it was the mapping, `git annex fsck` would correct the problem.
+"""]]
diff --git a/doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant/comment_2_9833e8f77c6148db9572316066a67eee._comment b/doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant/comment_2_9833e8f77c6148db9572316066a67eee._comment
new file mode 100644
index 0000000000..db7c82fd36
--- /dev/null
+++ b/doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant/comment_2_9833e8f77c6148db9572316066a67eee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkx5V3MTbzCXS3J7Mn9FEq8M9bPPYMkAHY"
+ nickname="Pedro"
+ subject="comment 2"
+ date="2013-12-16T23:00:48Z"
+ content="""
+What my transcript shows is that after the initial sync 1 doesn't get the changes from 2 and vice versa. This test is from scratch so it can't be something related to the old version. I'll try the fsck on my other machines to see if it fixes the issues there.
+"""]]
diff --git a/doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant/comment_3_1504f8767f1f4415222d8c315c734e81._comment b/doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant/comment_3_1504f8767f1f4415222d8c315c734e81._comment
new file mode 100644
index 0000000000..07d6eec3a6
--- /dev/null
+++ b/doc/bugs/Syncing_of_file_contents_seems_to_be_broken_in_recent_versions_of_the_assistant/comment_3_1504f8767f1f4415222d8c315c734e81._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.146"
+ subject="comment 3"
+ date="2014-03-07T17:21:02Z"
+ content="""
+Any news on this? Does it happen with the current version?
+
+"""]]
diff --git a/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address.mdwn b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address.mdwn
new file mode 100644
index 0000000000..f638638e48
--- /dev/null
+++ b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address.mdwn
@@ -0,0 +1,58 @@
+### Please describe the problem.
+
+After updating my Synology DS216+ NAS from [6.2-23739-1](https://www.synology.com/en-uk/releaseNote/DS216+II#ver_23739-1) to [6.2-23739-2](https://www.synology.com/en-uk/releaseNote/DS216+II#ver_23739-2), running `git-annex` with any non-trivial command, locally on the NAS or remotely on the NAS results in:
+
+    git-annex: timer_create: Bad address
+
+I'm guessing that this means that a library function the standalone binary needs is no longer present, but I'm unsure why.  The `-1` to `-2` update seems to only have two security fixes ([SA 18-36](https://www.synology.com/en-uk/support/security/Synology_SA_18_36), and [SA 18-01](https://www.synology.com/en-uk/support/security/Synology_SA_18_01) -- the latter being a Spectre/Meltdown bug).
+
+Do you know if `timer_create` is a kernel system call?  Or a libc (etc) library function?
+
+### What steps will reproduce the problem?
+
+Update Synology NAS to [6.2-23739-2](https://www.synology.com/en-uk/releaseNote/DS216+II#ver_23739-2), run `git annex sync`, `git annex version` or similar (remotely or locally).
+
+### What version of git-annex are you using? On what operating system?
+
+`x86-32`, stand alone build, for ancient-kernels, as that the 64-bit stand alone build [no longer seemed to work due to locale issues](https://ewen.mcneill.gen.nz/blog/entry/2017-05-28-git-annex-on-synology-ds216+/) (see note added at the end).
+
+I believe it is `6.20180626`, but `git annex version` currently also fails...
+
+### Please provide any additional information below.
+
+    ewen@nas01:/volume1/music/podcasts$ hostname --fqdn
+    nas01
+    ewen@nas01:/volume1/music/podcasts$ git annex sync
+    git-annex: timer_create: Bad address
+    ewen@nas01:/volume1/music/podcasts$ 
+    ewen@nas01:/volume1/music/podcasts$ git annex version
+    git-annex: timer_create: Bad address
+    ewen@nas01:/volume1/music/podcasts$ 
+    ewen@nas01:/volume1/music/podcasts$ uname -mr
+    3.10.105 x86_64
+    ewen@nas01:/volume1/music/podcasts$ 
+
+There is a [6.2.1 firmware release](https://www.synology.com/en-uk/releaseNote/DS216+) for the Synology NAS released a couple of days ago, but it does not yet seem to be visible to my NAS.  I can try that one if it'd help.
+
+I can also try switching back to one of the more modern `x86-64` / `x86-32` stand alone builds if that'd help.  But then I'd need some assistance with working around the:
+
+    sh: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
+    error: git-annex died of signal 6
+
+error I was seeing on those builds.  (From other work elsewhere it feels a lot like the LC_TIME structure changed in size in some libc definition somewhere in the last 6-12 months; in another project we had a similar break on Ubuntu 18.04 issues which didn't affect Ubuntu 16.04 and earlier.)
+
+In case it helps, out of the box defaults give:
+
+    ewen@nas01:/volume1/music/podcasts$ echo $LANG
+    en_US.utf8
+    ewen@nas01:/volume1/music/podcasts$ ls /volume1/thirdparty/git-annex.linux/locales/en_US.utf8/
+    LC_ADDRESS  LC_IDENTIFICATION  LC_MONETARY  LC_PAPER
+    LC_COLLATE  LC_MEASUREMENT     LC_NAME      LC_TELEPHONE
+    LC_CTYPE    LC_MESSAGES        LC_NUMERIC   LC_TIME
+    ewen@nas01:/volume1/music/podcasts$ 
+
+(although those files are currently generated with the now broken x86-32 legacy standalone build).
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Definitely.  It was working until I updated the NAS firmware image this afternoon... for this repository holding years of podcasts and many others.
diff --git a/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_1_8ce2cbdf5b5c31fd42b0ed270c54a824._comment b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_1_8ce2cbdf5b5c31fd42b0ed270c54a824._comment
new file mode 100644
index 0000000000..8970688f90
--- /dev/null
+++ b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_1_8ce2cbdf5b5c31fd42b0ed270c54a824._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="timer_create"
+ date="2018-09-03T22:06:00Z"
+ content="""
+From some digging around it looks like [`timer_create`](http://man7.org/linux/man-pages/man2/timer_create.2.html) is a Linux system call.  So presumably the issue with the Synology NAS is being caused by the kernel being updated.
+
+Of note, it appears that [Microsoft Windows System for Linux does not support `timer_create` either](https://github.com/Microsoft/WSL/issues/307).  And that [system call is apparently required for Haskell binaries](https://github.com/Microsoft/WSL/issues/307#issuecomment-217051052)...  Apparently (from this thread) other people have hit this issue trying to run `git-annex` too.
+
+There's a [suggestion of some work around flags](https://github.com/Microsoft/WSL/issues/307#issuecomment-239617836), but they do not seem to work with the `git-annex` stand alone binary as it is currently built:
+
+    ewen@nas01:~$ git-annex +RTS -V0 -RTS help
+    git-annex: Most RTS options are disabled. Link with -rtsopts to enable them.
+    ewen@nas01:~$ export GHCRTS=-V0
+    ewen@nas01:~$ git annex help
+    git-annex: Most RTS options are disabled. Link with -rtsopts to enable them.
+    ewen@nas01:~$ 
+
+Possibly it'll be necessary to try to persuade Synology to re-enable the `timer_create` system call.  But my guess is maybe they turned it off as a Spectre/Meltdown fix, so it may be non-trivial to persuade them to change it back.
+
+Ewen
+"""]]
diff --git a/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_2_1316ea67dc7df8d3d6f681ac3caf6d3c._comment b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_2_1316ea67dc7df8d3d6f681ac3caf6d3c._comment
new file mode 100644
index 0000000000..e849792a78
--- /dev/null
+++ b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_2_1316ea67dc7df8d3d6f681ac3caf6d3c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="Synology bug report"
+ date="2018-09-03T22:36:07Z"
+ content="""
+FWIW, I've created a Synology Account, to create a Synology Support Request, [#2082132](https://account.synology.com/en-global/support/2082132/detail) for the missing timer_create system call on DSM 6.2-23739-2.  I'm not holding out a lot of hope given it's a third party application running on the NAS, and not even one in their app store, but maybe there's a chance it'll get the system call turned back on again.  That Synology support request includes a link to this bug report.
+
+Ewen
+
+PS: I expect that bug report will only be visible if you're logged in with my Synology account.  But at least someone else reporting it can reference the same issue to Synology Support.
+"""]]
diff --git a/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_3_0e098ee460a0ad70dbe34d74c5e9bf3b._comment b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_3_0e098ee460a0ad70dbe34d74c5e9bf3b._comment
new file mode 100644
index 0000000000..782e7272ae
--- /dev/null
+++ b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_3_0e098ee460a0ad70dbe34d74c5e9bf3b._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="x86-64 build working on Synology NAS (with work around)"
+ date="2018-09-08T02:03:21Z"
+ content="""
+The Synology reply was \"our developers suspected that this is related to some library linking problem in the kernel\", and they asked for remote access to my device -- which I wasn't very keen on so I did some experimentation of my own.
+
+With the latest standalone `x86-64` build, I do *not* get the `timer_create` error.  So it does seem like there's a linking issue around accessing `timer_create` from the \"ancient\" builds on the current Synology DS216+ kernel/libc.
+
+However, the standalone `x86-64` builds *do* fail with `LC_TIME` issues by default:
+
+    ewen@nas01:/volume1/thirdparty$ git-annex help
+    warning: /bin/sh: setlocale: LC_ALL: cannot change locale (en_US.utf8)
+    sh: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
+    Aborted
+    ewen@nas01:/volume1/thirdparty$ 
+
+(and have for a while; it was why I switched to trying the Ancient 32-bit build earlier this year).  It appears at some point the `LC_TIME` structure changed in size, which means that mixing statically linked binaries with `locale` information that is older/newer causes problems.
+
+Fortunately that problem is now [common](https://unix.stackexchange.com/questions/444102/loadlocale-c-nl-intern-locale-data-assertion-error) [enough](https://github.com/hadolint/hadolint/issues/173) ([etc](https://github.com/ProteoWizard/pwiz/issues/29)), due to people encountering it with, eg Ubuntu 18.04 LTS, that it's widely known, and there's a [pretty easy work around](https://stackoverflow.com/questions/49301627/android-7-1-2-armv7):
+
+    export LC_ALL=C
+
+(which overrides the Synology shell default of `LC_ALL=en_US.utf8`).  Just setting `LC_TIME` does not seem to be sufficient if either `LC_ALL` or `LANG` are set to other values (with the Synology shell does by default).
+
+That `LC_ALL=C` override works for me, so I've tweaked my `git-annex-shell`, `git-annex-wrapper`, and `git-annex` shell scripts to do that before carrying on to call the rest of the `git-annex` tools, and everything seems to work again.  Possibly the `standalone` builds should do that automatically?
+
+    ewen@nas01:~$ set | egrep 'LANG|LC_'
+    LANG=en_US.utf8
+    LC_ALL=en_US.utf8
+    ewen@nas01:~$ LC_ALL=C git-annex version
+    git-annex version: 6.20180807-g48d11a5df
+    build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+    dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.13 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+    operating system: linux x86_64
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    ewen@nas01:~$
+
+Ewen
+"""]]
diff --git a/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_4_64fd17f3537fec02f8356e535a1d0bb4._comment b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_4_64fd17f3537fec02f8356e535a1d0bb4._comment
new file mode 100644
index 0000000000..6ce52c04b1
--- /dev/null
+++ b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_4_64fd17f3537fec02f8356e535a1d0bb4._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-09-11T17:20:18Z"
+ content="""
+IIRC the haskell runtime stopped using `timer_create` after ghc 7 or
+something like that. These days it uses poll.
+
+That said, `timer_create` is part of POSIX and part of the linux API
+and that is unlikely to change. There might be something in the libc/kernel
+interface that has changed in newer kernels, if so it may be that the
+i386ancient build is not going to work with new kernels.. But it's there to
+support old kernels anyway.
+
+As for the setlocale failure, while LC_ALL=C avoids it, that's not
+something I want to set by default, because people do use git-annex with
+unicode filenames and that can impact that, as well as of course preventing
+display of any translated messages by anything git-annex runs (though
+git-annex itself is not translated). It would be good to get to the bottom
+of the setlocale failure.
+"""]]
diff --git a/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_5_dacfb426f7e67e984bb9281a40427e85._comment b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_5_dacfb426f7e67e984bb9281a40427e85._comment
new file mode 100644
index 0000000000..3dbaa43558
--- /dev/null
+++ b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_5_dacfb426f7e67e984bb9281a40427e85._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="timer_create"
+ date="2018-09-11T21:37:24Z"
+ content="""
+It does very much look like something has removed `timer_create` from the Synology NAS.  Eg, if I statically compile the [example `timer_create` program in the man page](http://man7.org/linux/man-pages/man2/timer_create.2.html) on Debian Jessie/Stretch with:
+
+    gcc -o test_timer_create.jessie -static test_timer_create.c -lrt -lpthread
+
+and try to run it on the Synology NAS now, I get effectively the same symptoms:
+
+    ewen@nas01:~$ ./test_timer_create.jessie 1 100
+    Establishing handler for signal 34
+    Blocking signal 34
+    timer_create: Bad address
+    ewen@nas01:~$ 
+
+(Unfortunately I have no easy way to check if with a previous Synology NAS version.)
+
+The same manpage notes that it *can* be configured out of the kernel: \"Since Linux 4.10, support for POSIX timers is a configurable option that is enabled by default.  Kernel support can be disabled via the CONFIG_POSIX_TIMERS option.\" for which [the patch](https://patchwork.kernel.org/patch/9422453/) notes that \"Some embedded systems have no use for them\".  Obviously the Synology NAS is an embedded kernel situation.  Given that the tripping point was the [release where Synology introduced their Meltdown/Spectre fixes](https://www.synology.com/en-uk/releaseNote/DS216+II#ver_23739-2), I imagine that they backported a *lot* of related fixes from later kernels, and it seems likely that they did deliberately turn off `CONFIG_POSIX_TIMERS`, even if their 1st level/2nd level helpdesk did not know about it, since timing RAM accesses is pretty much key to the common Meltdown/Spectre exploits, and thus various projects removed \"high resolution\" timers.  (Unfortunately there's no `/proc/config.gz` or similar that I can see, and while I can find some [Synology open source bits](https://sourceforge.net/projects/dsgpl/files/) I got bored digging to try to find a kernel config file.)
+
+The fact that later Haskell switched to `poll` probably explains why the later build works.  At least that seems to a viable path forward for using `git-annex` on my NAS for now.
+
+Ewen
+"""]]
diff --git a/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_6_c85f2c69aa2cff05859e92afc95e9ccf._comment b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_6_c85f2c69aa2cff05859e92afc95e9ccf._comment
new file mode 100644
index 0000000000..beb30c1193
--- /dev/null
+++ b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_6_c85f2c69aa2cff05859e92afc95e9ccf._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="LC_TIME"
+ date="2018-09-11T22:23:49Z"
+ content="""
+From some hunting around I can find reports of that `loadlocale.c` issue with `LC_TIME` throughout 2018.  It seems to be more commonly encountered now that things like Ubuntu 18.04 are released with the newer glibc. (There's also a `LC_COLLATE` change somewhere around [mid](https://www.reddit.com/r/archlinux/comments/3g9dzf/loadlocalec130_error_on_everything/)/[late](https://www.linuxquestions.org/questions/slackware-arm-108/login-error-after-upgrade-of-current-4175562326/) 2015, which seems to be the previous change in data format impacting people in this way.)
+
+The generally understood wisdom seems to be that it's caused by locale data compiled by older (glibc) tool versions than the ones being used to load it (eg, statically linked into the binaries).  This is at least the second context in which I've come across it, in the last month, myself.  Both being caused by statically linked binaries built on Linux versions older/newer than the one on which they were being run, approximately across the 2017/2018 calendar boundary.
+
+On the Synology NAS this seems to be the locale tools version:
+
+    ewen@nas01:~$ locale --version
+    locale (crosstool-NG 1.20.0) 2.20-2014.11
+    Copyright (C) 2014 Free Software Foundation, Inc.
+    This is free software; see the source for copying conditions.  There is NO
+    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+    Written by Ulrich Drepper.
+    ewen@nas01:~$ 
+
+which is a tiny bit newer than Debian Jessie:
+
+    ewen@noc:~$ cat /etc/debian_version 
+    8.11
+    ewen@noc:~$ locale --version
+    locale (Debian GLIBC 2.19-18+deb8u10) 2.19
+    Copyright (C) 2014 Free Software Foundation, Inc.
+    This is free software; see the source for copying conditions.  There is NO
+    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+    Written by Ulrich Drepper.
+    ewen@noc:~$ 
+
+and somewhat older than Debian Stretch (2.24), Debian Unstable (2.27), or [Ubuntu 18.04](https://packages.ubuntu.com/bionic/locales) which is also 2.27.  My guess from the timing is that something in the `lc_time` structure size changed between about glibc 2.24 and 2.27, maybe late 2017 or early 2018.
+
+Digging in the glibc git tree turns up [commit f301e5334065e93aace667fd4a87bce6fc1dbd13](https://sourceware.org/git/?p=glibc.git;a=commit;h=f301e5334065e93aace667fd4a87bce6fc1dbd13), from 2017-10-27 which foreshadows a change with \"Now when we are about to add alternative month
+names to LC_TIME (BZ#10871) this will fail again.\".  This appears to be [BugZilla #10871](https://sourceware.org/bugzilla/show_bug.cgi?id=10871) which had been open forever, but the patches seem to have been [finally pushed on 2018-01-22](https://sourceware.org/bugzilla/show_bug.cgi?id=10871#c137).  Which is about the right timing for the problems seen.  Building locales with a glibc after that and loading with an older libc (statically linked), or vice versa, is going to break.  (I think this [might be the commit that breaks things](https://sourceware.org/git/?p=glibc.git;a=commit;h=95cb863a1ef7760a11272bbd7ba5fe62dc41be54), and if not, it's very nearby that commit in the history.  Applied 2018-01-22.)
+
+I don't see a work around for statically linked binaries using system locale files, short of building versions with code from on either side of that flag date and suggesting people use the right version depending on their locale files...
+
+... the best kludge I've thought of so far that *might* work is to turn `LC_ALL` into `LC_...` settings for each individual one, except `LC_TIME=C`, in the hope that maybe that'll cause the (changed) time part not to load.  But I haven't tested that myself.
+
+Ewen
+
+PS: One might hope that this change could have been done in a backwards compatible manner.  But that does not appear to be the case here.  glibc seem to have been perfectly fine with creating a flag day, presumably reasoning distros can always force the locales to be recompiled so they'll always stay in sync.
+"""]]
diff --git a/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_7_e8c76f8b9645733a793676dc274744ef._comment b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_7_e8c76f8b9645733a793676dc274744ef._comment
new file mode 100644
index 0000000000..445089f3bd
--- /dev/null
+++ b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_7_e8c76f8b9645733a793676dc274744ef._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="LC_TIME"
+ date="2018-09-11T23:52:23Z"
+ content="""
+In case it helps, I think this is the [change to the `lc_time` structure definition](https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=locale/categories.def;h=3cbb4e673882eb4ff827fa2b6d9eec2faafceff4;hp=47947f76862ea77779b821a7ca294a3eff67136e;hb=95cb863a1ef7760a11272bbd7ba5fe62dc41be54;hpb=4612268a0ad8e3409d8ce2314dd2dd8ee0af5269), and this is an example of the [change needed to a program loading them](https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=locale/programs/ld-time.c;h=41864482eccb14e31e0ff6cbe27c7008f687160d;hp=67d055a1c41d859b651e3af60f55b6a1499ed107;hb=95cb863a1ef7760a11272bbd7ba5fe62dc41be54;hpb=4612268a0ad8e3409d8ce2314dd2dd8ee0af5269).  Looks like two new arrays (one `char *`, one wide char), each 12 entries long, and maybe a flag for whether the \"alt month\" (names) are present (`alt_mon_defined`), but I'm not clear whether or not that is in the loaded files.  Both linked from the commit I mentioned in the previous comment.
+
+While the parser in that program seems to be able to cope with various formats to some extent, the [loadlocale.c code has an assert check on size](https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/loadlocale.c;h=15f93bec80e1f11c114eaac1c85f77e6ed071712;hb=95cb863a1ef7760a11272bbd7ba5fe62dc41be54#l126) that makes it more brittle.  (And at this point I think I've seen it fail both with \"newer locale files, older binary\" and \"older locale files, newer binary\", so I suspect both are at least \"untested\".)
+
+For the Synology NAS case building on Debian Stretch will *might* still work, and building on Debian Jessie looks like it should still work, but building on Debian Testing/Unstable presumably will not.  Presumably this incompatibility issue will just get more common over 2018/2019 as more things are/aren't upgraded.  Joy.
+
+Ewen
+"""]]
diff --git a/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_8_902afcef5ad9c3f2a80d5df1ce99e1d5._comment b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_8_902afcef5ad9c3f2a80d5df1ce99e1d5._comment
new file mode 100644
index 0000000000..ef55f1a66c
--- /dev/null
+++ b/doc/bugs/Synology_NAS__58___timer__95__create__58___Bad_address/comment_8_902afcef5ad9c3f2a80d5df1ce99e1d5._comment
@@ -0,0 +1,62 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="Synology NAS 6.2.1-23824"
+ date="2018-10-18T00:00:34Z"
+ content="""
+FTR, Synology finally released the NAS DSM 6.2.1-23824 (OS) software to my region (New Zealand; last I assume) so I've been able to install the September software update.  That does work with the 64-bit Git Annex standalone version, providing the `LC_ALL=C` workaround is still in place:
+
+    ewen@nas01:~$ git-annex version
+    rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
+    /volume1/thirdparty/git-annex.linux/runshell: line 132: 14602 Aborted                 rm -rf \"$localecache\" 2>&1
+    cmp: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
+    /volume1/thirdparty/git-annex.linux/runshell: line 142: 14603 Aborted                 cmp \"$LOCPATH/buildid\" \"$base/buildid\" > /dev/null
+    rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
+    /volume1/thirdparty/git-annex.linux/runshell: line 142: 14604 Aborted                 rm -rf \"$LOCPATH\"
+    ewen@nas01:~$ LC_ALL=C git-annex version
+    git-annex version: 6.20180807-g48d11a5df
+    build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+    dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.13 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+    operating system: linux x86_64
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    ewen@nas01:~$ 
+
+so at least for now I'm leaving my hand-edited work around in place:
+
+    ewen@nas01:~$ grep -B 1 LC_ALL /usr/local/bin/git-annex
+    # 2018-09-08 - work around for LC_TIME mismatch in locales
+    LC_ALL=C
+    export LC_ALL
+    ewen@nas01:~$ 
+
+Interestingly I hadn't noticed previously that it seems like its `rm` and `cmp` and the like which are running into locale loading problems, at least now.  Ironically line 132 is the point where it tries to clean up locale caches...
+
+    # Clean up locale caches when their standalone bundle no longer exists.
+    for localecache in $HOME/.cache/git-annex/locales/*; do
+        cachebase=$(cat \"$localecache/base\" 2>/dev/null || true)
+        if [ ! -d \"$cachebase\" ] || ! cmp \"$localecache/buildid\" \"$cachebase/buildid\" >/dev/null ; then
+            rm -rf \"$localecache\" 2>&1 || true
+        fi
+    done
+
+and 142 is the bit that tries to refresh the locale cache:
+
+    # If the locale cache for this bundle is out of date, refresh it.
+    if [ -e \"$LOCPATH/buildid\" ] && ! cmp \"$LOCPATH/buildid\" \"$base/buildid\" >/dev/null ; then
+        rm -rf \"$LOCPATH\"
+    fi
+    if ! mkdir -p \"$LOCPATH\"; then
+        echo \"Unable to write to $LOCPATH; can't continue!\" >&2
+        exit 1
+    fi
+    echo \"$base\" > \"$LOCPATH/base\"
+    cp \"$base/buildid\" \"$LOCPATH/buildid\"
+
+
+so it's possible the *new* issue might just be that bits of the git annex work around for locale issues are now unreachable... due to locale issues.  In which case maybe only the work around step needs `LC_ALL=C`?  I haven't experimented with that, but it does seem plausible that if it can get far enough to build/use locales in the right format for its own libc, that it'd then work properly.
+
+Ewen
+"""]]
diff --git a/doc/bugs/Synology___40__armel__41___clock__95__gettime__58___Invalid_argument.mdwn b/doc/bugs/Synology___40__armel__41___clock__95__gettime__58___Invalid_argument.mdwn
new file mode 100644
index 0000000000..f65eeb7fbe
--- /dev/null
+++ b/doc/bugs/Synology___40__armel__41___clock__95__gettime__58___Invalid_argument.mdwn
@@ -0,0 +1,22 @@
+### Please describe the problem.
+
+Executing 'runshell' works fine. However, every git-annex command fails with 'clock_gettime: Invalid argument':
+
+    $ git annex init
+    warning: /bin/sh: setlocale: LC_ALL: cannot change locale (en_US.utf8)
+    warning: /bin/sh: setlocale: LC_ALL: cannot change locale (en_US.utf8)
+    clock_gettime: Invalid argument
+
+### What steps will reproduce the problem?
+
+Download armel package. Run runshell. Try git-annex.
+
+### What version of git-annex are you using? On what operating system?
+
+Used an up2date armel build:
+
+https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-armel.tar.gz
+
+The kernel on this synology box is quite old, maybe that's the reason why git-annex is not running:
+
+    Linux skyranch 3.10.108 #42962 SMP Fri Mar 24 13:07:57 CST 2023 armv7l GNU/Linux synology_armada38x_ds216j
diff --git a/doc/bugs/Synology___40__armel__41___clock__95__gettime__58___Invalid_argument/comment_1_5277a05a17b348a1be80845e697c018c._comment b/doc/bugs/Synology___40__armel__41___clock__95__gettime__58___Invalid_argument/comment_1_5277a05a17b348a1be80845e697c018c._comment
new file mode 100644
index 0000000000..30f90e0226
--- /dev/null
+++ b/doc/bugs/Synology___40__armel__41___clock__95__gettime__58___Invalid_argument/comment_1_5277a05a17b348a1be80845e697c018c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-08-28T16:03:38Z"
+ content="""
+That system call dates to linux 2.6, but perhaps there is some
+incompatability.
+
+I doubt anything can be done in the build to address this.
+"""]]
diff --git a/doc/bugs/System.PosixCompat.User_removed_in_unix-compat-0.7.mdwn b/doc/bugs/System.PosixCompat.User_removed_in_unix-compat-0.7.mdwn
new file mode 100644
index 0000000000..542be432e0
--- /dev/null
+++ b/doc/bugs/System.PosixCompat.User_removed_in_unix-compat-0.7.mdwn
@@ -0,0 +1,60 @@
+### Please describe the problem.
+
+Module `System.PosixCompat.User` has been removed in `unix-compat-0.7` (see
+[changelog](https://hackage.haskell.org/package/unix-compat-0.7/changelog)). As
+a result, git-annex failed to build, with the following error:
+
+```
+Starting     git-annex-10.20230329 (all, legacy fallback)
+Error: cabal: Failed to build git-annex-10.20230329. The failure occurred
+during the configure step. The exception was:
+/private/tmp/git-annex-20230329-55610-12n1hf4/git-annex-10.20230329/.brew_home/.cabal/logs/ghc-9.4.4/gt-nnx-10.20230329-579147b2.log:
+withFile: user error (Error: cabal: '/opt/homebrew/opt/ghc/bin/ghc' exited
+with an error:
+
+/private/tmp/cabal-install.-55709/dist-newstyle/tmp/src-55709/git-annex-10.20230329/Utility/UserInfo.hs:24:1:
+error:
+Could not find module ‘System.PosixCompat.User’
+Perhaps you meant
+System.PosixCompat.Temp (from unix-compat-0.7)
+System.PosixCompat.Time (from unix-compat-0.7)
+System.PosixCompat.Files (from unix-compat-0.7)
+Use -v (or `:set -v` in ghci) to see a list of the files searched for.
+|
+24 | import System.PosixCompat.User
+| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+)
+```
+
+### What steps will reproduce the problem?
+
+```
+cabal v2-update
+cabal v2-install --jobs=8 --max-backjumps=100000 --install-method=copy --installdir=/opt/homebrew/Cellar/git-annex/10.20230329/bin --flags=+S3
+```
+
+(Note: I omitted some workarounds used to build with GHC >= 9.2. The full
+package description for building git-annex can be found
+[here](https://github.com/Homebrew/homebrew-core/blob/83f9beeb6ce6d44cd06856f4e9fc513e80cd237d/Formula/git-annex.rb).)
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex: 10.20230329 (But it failed with 10.20230321, too.)
+
+OS: macOS 11, 12, 13 (x86_64 and arm64), Ubuntu 22.04 (x86_64)
+
+### Please provide any additional information below.
+
+The error was observed while packaging git-annex for Homebrew
+[here](https://github.com/Homebrew/homebrew-core/pull/127002). Currently, that's
+being worked around by restricting `unix-compat` version to `>= 0.5 && < 0.7` in
+`git-annex.cabal`.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sorry, I'm not a git-annex user. I'm a maintainer of the Homebrew package
+manager, and I help to make the newest git-annex available to our users.
+
+Thanks for all your work maintaining git-annex!
+
+> [[fixed|done]] by avoiding the broken version --[[Joey]]
diff --git a/doc/bugs/System.PosixCompat.User_removed_in_unix-compat-0.7/comment_1_cd573b785b7d7feec72387cb0dafdcab._comment b/doc/bugs/System.PosixCompat.User_removed_in_unix-compat-0.7/comment_1_cd573b785b7d7feec72387cb0dafdcab._comment
new file mode 100644
index 0000000000..9894d24ea6
--- /dev/null
+++ b/doc/bugs/System.PosixCompat.User_removed_in_unix-compat-0.7/comment_1_cd573b785b7d7feec72387cb0dafdcab._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-31T16:50:28Z"
+ content="""
+Unfortunately pinning to 0.6 is the only solution, I cannot work around
+this ill-considered change in git-annex. I have opened an issue and hope
+the maintainers reconsider.
+<https://github.com/haskell-pkg-janitors/unix-compat/issues/3>
+"""]]
diff --git a/doc/bugs/System.PosixCompat.User_removed_in_unix-compat-0.7/comment_2_6b15d11b6e25689e2430663a4aa90168._comment b/doc/bugs/System.PosixCompat.User_removed_in_unix-compat-0.7/comment_2_6b15d11b6e25689e2430663a4aa90168._comment
new file mode 100644
index 0000000000..2048e072f1
--- /dev/null
+++ b/doc/bugs/System.PosixCompat.User_removed_in_unix-compat-0.7/comment_2_6b15d11b6e25689e2430663a4aa90168._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="zhongruoyu@80ae9772857666624009364c29f07c70beed46ac"
+ nickname="zhongruoyu"
+ avatar="http://cdn.libravatar.org/avatar/b1c7aaba6e8b09ef40ca161135d3b14b"
+ subject="comment 2"
+ date="2023-03-31T18:32:29Z"
+ content="""
+Thanks for doing that. I cannot comment on the `unix-compat` change, because I'm not familiar with it. But let me use the fix you've just committed and keep an eye on the updates, if any.
+
+"""]]
diff --git a/doc/bugs/Tests_v8_locked__58___rsync_remote__58___FAIL.mdwn b/doc/bugs/Tests_v8_locked__58___rsync_remote__58___FAIL.mdwn
new file mode 100644
index 0000000000..d7137d7cce
--- /dev/null
+++ b/doc/bugs/Tests_v8_locked__58___rsync_remote__58___FAIL.mdwn
@@ -0,0 +1,43 @@
+### Please describe the problem.
+
+```
+2022-04-28T03:40:48.4460611Z   Repo Tests v8 locked
+2022-04-28T03:40:48.4460898Z     Init Tests
+2022-04-28T03:40:48.4461239Z       init:                                               OK (0.08s)
+2022-04-28T03:40:48.4461605Z       add:                                                OK (0.31s)
+2022-04-28T03:40:48.4461985Z     preferred content:                                    OK (1.26s)
+2022-04-28T03:40:48.4462414Z     rsync remote:                                         FAIL (0.63s)
+```
+
+across setups:
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2022/04[master]cron-20220428
+$> git grep -n FAIL| grep test-annex                                                                
+build-macos.yaml-670-0346631d-failed/1_test-annex (normal, macos-10.15).txt:1580:2022-04-28T02:40:19.9278580Z     rsync remote:                                 FAIL (1.44s)
+build-macos.yaml-670-0346631d-failed/2_test-annex (crippled-tmp, macos-10.15).txt:1692:2022-04-28T02:44:48.5060190Z     rsync remote:                                 FAIL (1.41s)
+build-macos.yaml-670-0346631d-failed/3_test-annex (normal, macos-latest).txt:1581:2022-04-28T02:40:39.2774670Z     rsync remote:                                 FAIL (1.32s)
+build-macos.yaml-670-0346631d-failed/test-annex (crippled-tmp, macos-10.15)/8_Run tests.txt:1425:2022-04-28T02:44:48.5060140Z     rsync remote:                                 FAIL (1.41s)
+build-macos.yaml-670-0346631d-failed/test-annex (normal, macos-10.15)/8_Run tests.txt:1314:2022-04-28T02:40:19.9278580Z     rsync remote:                                 FAIL (1.44s)
+build-macos.yaml-670-0346631d-failed/test-annex (normal, macos-latest)/8_Run tests.txt:1314:2022-04-28T02:40:39.2774650Z     rsync remote:                                 FAIL (1.32s)
+build-ubuntu.yaml-675-0346631d-failed/1_test-annex (normal, ubuntu-latest).txt:1427:2022-04-28T03:40:48.4462418Z     rsync remote:                                         FAIL (0.63s)
+build-ubuntu.yaml-675-0346631d-failed/2_test-annex (crippled-tmp, ubuntu-latest).txt:1577:2022-04-28T03:41:44.8645593Z     rsync remote:                                         FAIL (0.64s)
+build-ubuntu.yaml-675-0346631d-failed/4_test-annex (nfs-home, ubuntu-latest).txt:1513:2022-04-28T03:45:52.6285760Z     rsync remote:                                         FAIL (1.56s)
+build-ubuntu.yaml-675-0346631d-failed/test-annex (crippled-tmp, ubuntu-latest)/7_Run tests.txt:1334:2022-04-28T03:41:44.8645589Z     rsync remote:                                         FAIL (0.64s)
+build-ubuntu.yaml-675-0346631d-failed/test-annex (nfs-home, ubuntu-latest)/7_Run tests.txt:1270:2022-04-28T03:45:52.6285755Z     rsync remote:                                         FAIL (1.56s)
+build-ubuntu.yaml-675-0346631d-failed/test-annex (normal, ubuntu-latest)/7_Run tests.txt:1185:2022-04-28T03:40:48.4462414Z     rsync remote:                                         FAIL (0.63s)
+
+```
+
+and for some time already (as pinged in an email) -- since 20220420
+
+
+```
+$> git grep -n rsync.*FAIL| grep test-annex | grep ubuntu-late
+cron-20220420/build-ubuntu.yaml-667-0346631d-failed/1_test-annex (normal, ubuntu-latest).txt:1427:2022-04-20T03:30:39.0198567Z     rsync remote:                                         FAIL (0.70s)
+cron-20220420/build-ubuntu.yaml-667-0346631d-failed/2_test-annex (crippled-tmp, ubuntu-latest).txt:1582:2022-04-20T03:31:17.9571887Z     rsync remote:                                         FAIL (0.62s)
+cron-20220420/build-ubuntu.yaml-667-0346631d-failed/4_test-annex (nfs-home, ubuntu-latest).txt:1511:2022-04-20T03:34:57.9524586Z     rsync remote:                                         FAIL (1.57s)
+...
+```
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Tests_v8_locked__58___rsync_remote__58___FAIL/comment_1_809ca8b986ccadbc3940cc795d1823e8._comment b/doc/bugs/Tests_v8_locked__58___rsync_remote__58___FAIL/comment_1_809ca8b986ccadbc3940cc795d1823e8._comment
new file mode 100644
index 0000000000..4ce0ff8c8a
--- /dev/null
+++ b/doc/bugs/Tests_v8_locked__58___rsync_remote__58___FAIL/comment_1_809ca8b986ccadbc3940cc795d1823e8._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-02T16:53:13Z"
+ content="""
+The failure message is:
+
+      ./Test/Framework.hs:328:
+      able to modify annexed file's foo content
+
+Apparently some change to rsync in 3.2.4 has messed
+up something involving permissions.
+
+See also another bug caused by the new rsync <http://bugs.debian.org/1010397>
+"""]]
diff --git a/doc/bugs/Tests_v8_locked__58___rsync_remote__58___FAIL/comment_2_0327663314d2a8b2f0cab7536fdaa6bd._comment b/doc/bugs/Tests_v8_locked__58___rsync_remote__58___FAIL/comment_2_0327663314d2a8b2f0cab7536fdaa6bd._comment
new file mode 100644
index 0000000000..c6aa04f30b
--- /dev/null
+++ b/doc/bugs/Tests_v8_locked__58___rsync_remote__58___FAIL/comment_2_0327663314d2a8b2f0cab7536fdaa6bd._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-05-02T17:08:15Z"
+ content="""
+Here is the bug in action:
+
+	-r--r--r-- 1 joey joey 30 May  2 12:42 .git/annex/objects/Gj/8J/SHA256E-s30--3d65cafd9435fde3867a527d75ff8aea05a3632cb60574d45e0fc277f06c8a64/SHA256E-s30--3d65cafd9435fde3867a527d75ff8aea05a3632cb60574d45e0fc277f06c8a64
+	joey@darkstar:/tmp/x>git-annex copy --to foo
+	copy x (to foo...) 
+	ok
+	joey@darkstar:/tmp/x>ls -l .git/annex/objects/Gj/8J/SHA256E-s30--3d65cafd9435fde3867a527d75ff8aea05a3632cb60574d45e0fc277f06c8a64/SHA256E-s30--3d65cafd9435fde3867a527d75ff8aea05a3632cb60574d45e0fc277f06c8a64
+	-rwxr--r-- 1 joey joey 30 May  2 12:42 .git/annex/objects/Gj/8J/SHA256E-s30--3d65cafd9435fde3867a527d75ff8aea05a3632cb60574d45e0fc277f06c8a64/SHA256E-s30--3d65cafd9435fde3867a527d75ff8aea05a3632cb60574d45e0fc277f06c8a64*
+
+At first I thought this was rsync modifying the permissions of the source file.
+
+But no... [[!commit 17b20a24502aee3bfc5683146c3899a233295aea]]
+changed how temp directories get cleaned up. removePathForcibly
+is actually changing the permissions of the object file hard link
+in the rsynctmp directory when deleting that directory. Which also 
+changes the permissions of the object file.
+
+Filed a bug on removePathForcibly. <https://github.com/haskell/directory/issues/135>
+
+I think this makes removePathForcibly unsuitable for general purpose
+use in git-annex, because there are just too many ways for a hard link
+to enter the picture. (Eg annex.thin, or even a user making their own
+hard link that git-annex does not know about.) 
+
+So, I've reverted that commit, and put in a more
+targeted fix for the problem it was addressing.
+"""]]
diff --git a/doc/bugs/TransferScanner_crashed__58___fd__58__59__58___hGetLine__58___end_of_file.mdwn b/doc/bugs/TransferScanner_crashed__58___fd__58__59__58___hGetLine__58___end_of_file.mdwn
new file mode 100644
index 0000000000..40cd3ebb9c
--- /dev/null
+++ b/doc/bugs/TransferScanner_crashed__58___fd__58__59__58___hGetLine__58___end_of_file.mdwn
@@ -0,0 +1,50 @@
+### Please describe the problem.
+git-annex assistant reports a warning:
+TransferScanner crashed: fd:59: hGetLine: end of file
+
+### What steps will reproduce the problem?
+I don't know. Just run git-annex assistant and wait for this to happen.
+
+### What version of git-annex are you using? On what operating system?
+Version: 5.20140709
+Build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS Feeds Quvi TDFA CryptoHash 
+
+Gentoo
+
+### Please provide any additional information below.
+
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+error: object file /home/crabman/annex/.git/objects/97/3b57761ebe88b11e1d0d2c70c8d3b48530202f is empty
+fatal: loose object 973b57761ebe88b11e1d0d2c70c8d3b48530202f (stored in /home/crabman/annex/.git/objects/97/3b57761ebe88b11e1d0d2c70c8d3b48530202f) is corrupt
+error: object file /home/crabman/annex/.git/objects/97/3b57761ebe88b11e1d0d2c70c8d3b48530202f is empty
+fatal: loose object 973b57761ebe88b11e1d0d2c70c8d3b48530202f (stored in /home/crabman/annex/.git/objects/97/3b57761ebe88b11e1d0d2c70c8d3b48530202f) is corrupt
+error: object file /home/crabman/annex/.git/objects/97/3b57761ebe88b11e1d0d2c70c8d3b48530202f is empty
+fatal: loose object 973b57761ebe88b11e1d0d2c70c8d3b48530202f (stored in /home/crabman/annex/.git/objects/97/3b57761ebe88b11e1d0d2c70c8d3b48530202f) is corrupt
+error: object file /home/crabman/annex/.git/objects/97/3b57761ebe88b11e1d0d2c70c8d3b48530202f is empty
+fatal: loose object 973b57761ebe88b11e1d0d2c70c8d3b48530202f (stored in /home/crabman/annex/.git/objects/97/3b57761ebe88b11e1d0d2c70c8d3b48530202f) is corrupt
+fd:31: hGetLine: end of file
+fd:32: hGetLine: end of file
+fd:33: hGetLine: end of file
+fd:34: hGetLine: end of file
+fd:38: hGetLine: end of file
+fd:41: hGetLine: end of file
+fd:41: hGetLine: end of file
+fd:41: hGetLine: end of file
+fd:41: hGetLine: end of file
+fd:41: hGetLine: end of file
+fd:41: hGetLine: end of file
+fd:43: hGetLine: end of file
+fd:41: hGetLine: end of file
+fd:41: hGetLine: end of file
+fd:41: hGetLine: end of file
+fd:41: hGetLine: end of file
+fd:41: hGetLine: end of file
+fd:41: hGetLine: end of file
+fd:43: hGetLine: end of file
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/TransferScanner_crashed__58___fd__58__59__58___hGetLine__58___end_of_file/comment_1_a1392b92efdff82783a4b0cc2c3c7f2f._comment b/doc/bugs/TransferScanner_crashed__58___fd__58__59__58___hGetLine__58___end_of_file/comment_1_a1392b92efdff82783a4b0cc2c3c7f2f._comment
new file mode 100644
index 0000000000..101b234047
--- /dev/null
+++ b/doc/bugs/TransferScanner_crashed__58___fd__58__59__58___hGetLine__58___end_of_file/comment_1_a1392b92efdff82783a4b0cc2c3c7f2f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-14T18:47:21Z"
+ content="""
+You did not seem to paste the whole log, but it's clear that your git repository is corrupt. You might try running `git annex repair` inside it.
+
+This was probably caused by a disk corruption or if you're lucky just a hard shutdown that caused files to get truncated.
+
+The assistant tries to detect corrupt repositories on startup, but it's hard to detect when a repository has a few corrupt objects like this. This is why the webapp suggests you set up periodic repository consistency checks, which should eventually repair this kind of problem.
+
+Perhaps it would make sense for the webapp, when a thread crashes, to provide a button to run an consistency check immediately.
+"""]]
diff --git a/doc/bugs/TransferScanner_crashed__58___fd__58__59__58___hGetLine__58___end_of_file/comment_2_5e153b7c59c474988fe551a505e545bc._comment b/doc/bugs/TransferScanner_crashed__58___fd__58__59__58___hGetLine__58___end_of_file/comment_2_5e153b7c59c474988fe551a505e545bc._comment
new file mode 100644
index 0000000000..c8d4a988af
--- /dev/null
+++ b/doc/bugs/TransferScanner_crashed__58___fd__58__59__58___hGetLine__58___end_of_file/comment_2_5e153b7c59c474988fe551a505e545bc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jg123h12jh3y12g3y"
+ ip="86.62.100.131"
+ subject="comment 2"
+ date="2014-07-15T07:58:15Z"
+ content="""
+But I do have periodice consistency checks turned on. I think git-annex assistant should tell the user what the heck is going on and maybe try to repair it automatically.
+"""]]
diff --git a/doc/bugs/Transfers_continue_after_daemon_stopped.mdwn b/doc/bugs/Transfers_continue_after_daemon_stopped.mdwn
new file mode 100644
index 0000000000..0d9b4f6488
--- /dev/null
+++ b/doc/bugs/Transfers_continue_after_daemon_stopped.mdwn
@@ -0,0 +1,5 @@
+After creating a new pairing, I stopped the daemon through the webapp while it was syncing.  The webapp shut down and was no longer accessible, but git-annex continued running in the background, along with git-annex-shell, and they continued to run new transfers with new rsync processes.  This continued until I killed them all.
+
+I expected that when I stopped the daemon in the webapp, all git-annex processes and all transfers would stop.
+
+Using the 20131101 tarball.
diff --git a/doc/bugs/Transfers_continue_after_daemon_stopped/comment_1_39eb527d64367e6762281246f1d49b1f._comment b/doc/bugs/Transfers_continue_after_daemon_stopped/comment_1_39eb527d64367e6762281246f1d49b1f._comment
new file mode 100644
index 0000000000..9d504f743c
--- /dev/null
+++ b/doc/bugs/Transfers_continue_after_daemon_stopped/comment_1_39eb527d64367e6762281246f1d49b1f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-05T16:01:14Z"
+ content="""
+I've checked, and shutting down the daemon does cause it to stop any transfers it is running.
+
+However, this does not stop other transfers initiated by the other paired computer.
+
+I'm ambivilant about whether local pairing should only allow transfers when both daemons are running.
+"""]]
diff --git a/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead.mdwn b/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead.mdwn
new file mode 100644
index 0000000000..99055e7c5d
--- /dev/null
+++ b/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead.mdwn
@@ -0,0 +1,51 @@
+What steps will reproduce the problem?
+
+I added a (encrypted) ssh remote and everything worked fine. Now I marked the remote as dead, but git-annex still tries to upload to this remote. I recognize this because it asks for my ssh and gpg keys passwords. 
+
+While transfering (or asking for the password), `git annex status` shows the following:
+<pre>
+supported backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+supported remote types: git S3 bup directory rsync web hook
+trusted repositories: 0
+semitrusted repositories: 2
+	00000000-0000-0000-0000-000000000001 -- web
+ 	cd16b9c6-f464-11e1-9845-8749687232d2 -- here (Dell)
+untrusted repositories: 0
+dead repositories: 7
+	11379fa0-ecd6-49e2-9bec-24fc19cc7b9f -- vserver.dbruhn.de_annex
+ 	2195e036-d2ef-4357-8c89-a9aaec23ebdc -- vserver-plain
+ 	4d066ea1-fb9f-45fd-990a-5c5c836f530e -- inTmp
+ 	bb276045-6ba6-488f-88d0-39a3c5f5134d -- vserver-enc
+ 	c49f3372-3fcf-49fc-b626-73ba4454c172 -- annexBare (bareAnnex)
+ 	e52645b3-bfb6-457d-b281-967353919e29 -- AnnexUSBFAT
+ 	ea3d6acc-716c-48e8-9b6b-993b90dcc1db -- vserver2
+transfers in progress: 
+	uploading Schmidt/somefile.m4a
+
+
+ to vserver2
+available local disk space: 43 gigabytes (+1 megabyte reserved)
+temporary directory size: 389 megabytes (clean up with git-annex unused)
+local annex keys: 23
+local annex size: 396 megabytes
+known annex keys: 19
+known annex size: 396 megabytes
+bloom filter size: 16 mebibytes (0% full)
+backend usage: 
+	SHA256E: 42
+</pre>
+
+As you can see, the `vserver2` remote is marked as dead but git-annex still tries to upload. This problem keeps occuring even after restarts. 
+
+What is the expected output? What do you see instead?
+
+If I do not get the `dead` status wrong, git-annex should not use these remotes.
+
+
+What version of git-annex are you using? On what operating system?
+
+git-annex HEAD from yesterdays git. Ubuntu 12.10
+
+Please provide any additional information below.
+
+[[!tag /design/assistant moreinfo]]
diff --git a/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_1_108b3984891f82429430b503cddfb3c1._comment b/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_1_108b3984891f82429430b503cddfb3c1._comment
new file mode 100644
index 0000000000..f8a85cb166
--- /dev/null
+++ b/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_1_108b3984891f82429430b503cddfb3c1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.194"
+ subject="comment 1"
+ date="2012-11-04T20:01:35Z"
+ content="""
+Are you using the git-annex assistant? It's supposed to have code in it to prevent it from using dead remotes. Perhaps that is not working.
+
+When not using the git-annex assistant, nothing prevents git-annex from trying to continue to use dead remotes. I think this is ok; maybe the dead remote is not 100% dead yet; if it is, the remote can be removed from git's configuration to prevent it being used of course.
+"""]]
diff --git a/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_2_fa5b1bc26ed3e5bfe48441490c94fe3a._comment b/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_2_fa5b1bc26ed3e5bfe48441490c94fe3a._comment
new file mode 100644
index 0000000000..fd0d9d2ab9
--- /dev/null
+++ b/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_2_fa5b1bc26ed3e5bfe48441490c94fe3a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://www.dbruhn.de/"
+ nickname="Dominik"
+ subject="comment 2"
+ date="2012-11-08T14:13:00Z"
+ content="""
+Actually this happens when using the assistant.
+"""]]
diff --git a/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_3_0a785b5dfbf4eef30854d6bedb12b7d1._comment b/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_3_0a785b5dfbf4eef30854d6bedb12b7d1._comment
new file mode 100644
index 0000000000..e839e7a156
--- /dev/null
+++ b/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_3_0a785b5dfbf4eef30854d6bedb12b7d1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.11.120"
+ subject="comment 3"
+ date="2012-11-13T18:00:42Z"
+ content="""
+I've tried & failed to reproduce this using the assistant. When I mark a repo as dead, and go into Configuration -> Manage repositories, the repository is not shown in the list of repositories it'll sync to, and it certainly doesn't upload any files to it.
+
+
+"""]]
diff --git a/doc/bugs/URL_key_potential_data_loss.mdwn b/doc/bugs/URL_key_potential_data_loss.mdwn
new file mode 100644
index 0000000000..4893ce6374
--- /dev/null
+++ b/doc/bugs/URL_key_potential_data_loss.mdwn
@@ -0,0 +1,32 @@
+Using URL keys can lead to data loss. Two remotes can have two different
+objects for the same URL key, as the content of an url may change over
+time. If git-annex gets part of an object from the first remote, but is
+then interrupted or fails, and then resumes from the second remote's
+object, it will stitch together a chimera that has never existed at the
+url. Then dropping the URL objects from both remotes will result in no
+valid copies of the object remaining.
+
+This could also happen with WORM, but it would be much less likely. Two
+files with the same mtime, size, and path would have to be added to two
+repos.
+
+And it could happen if an old git-annex is being used in a repo that uses
+some new key that it doesn't support, like a new checksum type.
+
+Special remotes are affected if they use chunking, or if they resume
+when the destination file already exists and don't have their own
+checksumming. So the rsync special remote is affected when it's used with
+chunking, but not otherwise.
+
+With the default annex.security.allow-unverified-downloads config, 
+encrypted special remotes already don't allow downloading the problem keys.
+
+The bug affects remotes using the git-annex P2P protocol, but not ssh remotes
+using rsync. So the introduction of the P2P protocol made this bug more
+prevelant.
+
+Best fix for this seems to be to prevent resuming download of keys 
+when their content is not verifiable.
+
+The P2P protocol could also be extended to use a checksum to verify a
+resume is safe to do. That would only be worth doing for the affected keys.
diff --git a/doc/bugs/URL_key_potential_data_loss/comment_1_a921dab2c4335f690df4d5189fe4e4c2._comment b/doc/bugs/URL_key_potential_data_loss/comment_1_a921dab2c4335f690df4d5189fe4e4c2._comment
new file mode 100644
index 0000000000..b952596695
--- /dev/null
+++ b/doc/bugs/URL_key_potential_data_loss/comment_1_a921dab2c4335f690df4d5189fe4e4c2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="storing checksums for non-checksum keys in metadata"
+ date="2019-08-16T16:06:29Z"
+ content="""
+One related improvement would be for git-annex to compute and store, as metadata, checksum-based [[keys|backends]] corresponding to non-checksum-based keys, when git-annex sees the contents of the non-checksum-based key ( e.g. [[todo/alternate_keys_for_same_content]] ). There is of course [[`git-annex-migrate`|git-annex-migrate]], but it requires manual invocation, clouds the commit history of the main git branch with commits that don't really change the content, and leads to either duplicate content in remotes or (if duplicates are dropped) inability to git-annex-get the contents of some past commits.
+"""]]
diff --git a/doc/bugs/URL_key_potential_data_loss/comment_2_0c9e7b8e00db92e8d638328f0390f6e9._comment b/doc/bugs/URL_key_potential_data_loss/comment_2_0c9e7b8e00db92e8d638328f0390f6e9._comment
new file mode 100644
index 0000000000..aed14317b0
--- /dev/null
+++ b/doc/bugs/URL_key_potential_data_loss/comment_2_0c9e7b8e00db92e8d638328f0390f6e9._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-01-29T17:31:02Z"
+ content="""
+Backend.URL has isStableKey = False, and that does prevent
+chunking URL keys on special remotes. So looking at that is the thing to
+do, and will not affect WORM but only URL. (And any external backends that
+are not stable.)
+
+While some remotes can handle it, eg rsync, this does not seem like
+something every remote should need to worry about getting right.
+
+While retrieveKeyFile can be wrapped and made to delete the destination
+file before the transfer if the key is not stable, what to do about
+storeKey? If it chooses to resume, it's based on data on the remote.
+removeKey does not necessarily remove a partially recieved key; it doesn't
+for P2P where the temp file holds the content until it's fully received.
+
+Could refuse to storeKey URL keys, which would be nearly the same as 
+deprecating/removing support for URL keys entirely. (Which is not
+unappealing, but I know people are using them and dropping support would be
+painful.)
+
+Or ugh, special case isStableKey checks in P2P and any other remotes 
+that support resuming storeKey w/o using chunking and resume based on file
+offsent and not content. But there could be external remotes that I don't
+know about that would still be affected.
+"""]]
diff --git a/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows.mdwn b/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows.mdwn
new file mode 100644
index 0000000000..f499338e27
--- /dev/null
+++ b/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows.mdwn
@@ -0,0 +1,68 @@
+### Please describe the problem.
+
+Unable to addurl to a `file:///` on Windows
+
+1. doesn't understand `file:///C:/`
+2. with `file://C:/` blows with permission denied:
+
+[[!format sh """
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>git annex addurl --file buga file:///C:/123
+addurl file:///C:/123
+download failed: /C:/123: openBinaryFile: invalid argument (Invalid argument)
+failed
+git-annex: addurl: 1 failed
+
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>git annex addurl --file buga file://C:/123
+addurl file://C:/123
+(to buga)
+git-annex: .git\annex\tmp\URL-s6--file&c%%C&c%123: renameFile:renamePath:MoveFileEx "\\\\?\\C:\\Users\\appveyor\\
+AppData\\Local\\Temp\\1\\datalad_temp_testrepo_tmphjl88\\.git\\annex\\tmp\\URL-s6--file&c%%C&c%123" Just "\\\\?\\
+C:\\Users\\appveyor\\AppData\\Local\\Temp\\1\\datalad_temp_testrepo_tmphjl88\\buga": permission denied (The proce
+ss cannot access the file because it is being used by another process.)
+failed
+git-annex: addurl: 1 failed
+
+"""]]
+
+here is some relevant details (and showing curl handling both file:// and file:///):
+[[!format sh """
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>git annex version
+git-annex version: 7.20181205-g51d6f38b1
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV TorrentParser Feeds Testsuite
+dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client
+-0.5.7.1 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3
+_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B51
+2E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S
+160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM
+ URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: mingw32 i386
+supported repository versions: 5 7
+upgrade supported from repository versions: 2 3 4 5 6
+local repository version: 7
+
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>curl file://C:/123
+124
+
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>curl file:///C:/123
+124
+"""]]
+
+More information about this appveyor server could be obtained from [datalad wtf](http://paste.debian.net/1055359/) output
+
+Awhile back we [had related discussion](https://git-annex.branchable.com/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/) but at least `addurl` seemed to work then.
+
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows/comment_1_c4cfa1d0f90193b127722711285e1210._comment b/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows/comment_1_c4cfa1d0f90193b127722711285e1210._comment
new file mode 100644
index 0000000000..b1ca8a5171
--- /dev/null
+++ b/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows/comment_1_c4cfa1d0f90193b127722711285e1210._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-27T16:27:00Z"
+ content="""
+I tried this on windows, and the second command succeeds now.
+
+The first command still fails as shown.
+
+At this point, what's left of this bug seems to be the same as
+<https://git-annex.branchable.com/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/>
+"""]]
diff --git a/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows/comment_2_ff71a541b3df8bb272e576c856b3aa9d._comment b/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows/comment_2_ff71a541b3df8bb272e576c856b3aa9d._comment
new file mode 100644
index 0000000000..2c216e7e40
--- /dev/null
+++ b/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows/comment_2_ff71a541b3df8bb272e576c856b3aa9d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-03-27T17:57:12Z"
+ content="""
+Ok, put in an ugly hack to fix this.
+"""]]
diff --git a/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier.mdwn b/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier.mdwn
new file mode 100644
index 0000000000..b7e8754f76
--- /dev/null
+++ b/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier.mdwn
@@ -0,0 +1,43 @@
+I'll just started using git-annex and now I'm trying archiving to glacier. Unfortunately if I put a simple 2mb pdf with the name 'test.txt' into the archive folder, I get the following error:
+
+[[!format sh """
+Traceback (most recent call last):
+  File "/usr/local/bin/glacier", line 9, in <module>
+    load_entry_point('glacier-cli==0.1.0', 'console_scripts', 'glacier-cli')()
+  File "build/bdist.macosx-10.11-x86_64/egg/glacier.py", line 732, in entry_point
+  File "build/bdist.macosx-10.11-x86_64/egg/glacier.py", line 718, in main
+  File "build/bdist.macosx-10.11-x86_64/egg/glacier.py", line 500, in archive_upload
+  File "/Users/markus/.virtualenvs/glacier-cli/lib/python2.7/site-packages/boto-2.38.0-py2.7.egg/boto/glacier/vault.py", line 178, in create_archive_from_file
+    writer.close()
+  File "/Users/markus/.virtualenvs/glacier-cli/lib/python2.7/site-packages/boto-2.38.0-py2.7.egg/boto/glacier/writer.py", line 228, in close
+    self.partitioner.flush()
+  File "/Users/markus/.virtualenvs/glacier-cli/lib/python2.7/site-packages/boto-2.38.0-py2.7.egg/boto/glacier/writer.py", line 79, in flush
+    self._send_part()
+  File "/Users/markus/.virtualenvs/glacier-cli/lib/python2.7/site-packages/boto-2.38.0-py2.7.egg/boto/glacier/writer.py", line 75, in _send_part
+    self.send_fn(part)
+  File "/Users/markus/.virtualenvs/glacier-cli/lib/python2.7/site-packages/boto-2.38.0-py2.7.egg/boto/glacier/writer.py", line 222, in _upload_part
+    self.uploader.upload_part(self.next_part_index, part_data)
+  File "/Users/markus/.virtualenvs/glacier-cli/lib/python2.7/site-packages/boto-2.38.0-py2.7.egg/boto/glacier/writer.py", line 129, in upload_part
+    content_range, part_data)
+  File "/Users/markus/.virtualenvs/glacier-cli/lib/python2.7/site-packages/boto-2.38.0-py2.7.egg/boto/glacier/layer1.py", line 1279, in upload_part
+    response_headers=response_headers)
+  File "/Users/markus/.virtualenvs/glacier-cli/lib/python2.7/site-packages/boto-2.38.0-py2.7.egg/boto/glacier/layer1.py", line 114, in make_request
+    data=data)
+  File "/Users/markus/.virtualenvs/glacier-cli/lib/python2.7/site-packages/boto-2.38.0-py2.7.egg/boto/connection.py", line 1071, in make_request
+    retry_handler=retry_handler)
+  File "/Users/markus/.virtualenvs/glacier-cli/lib/python2.7/site-packages/boto-2.38.0-py2.7.egg/boto/connection.py", line 943, in _mexe
+    request.body, request.headers)
+  File "/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1053, in request
+    self._send_request(method, url, body, headers)
+  File "/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1093, in _send_request
+    self.endheaders(body)
+  File "/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1049, in endheaders
+    self._send_output(message_body)
+  File "/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 891, in _send_output
+    msg += message_body
+UnicodeDecodeError: 'ascii' codec can't decode byte 0x8c in position 0: ordinal not in range(128)
+"""]]
+
+I also filled a bugreport here: https://github.com/basak/glacier-cli/issues/61
+
+I'm using git-annex from homebrew and the most recent version of glacier-cli.
diff --git a/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_1_f68d5ad86d67aa73074389cf9a21469e._comment b/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_1_f68d5ad86d67aa73074389cf9a21469e._comment
new file mode 100644
index 0000000000..3e5468e63a
--- /dev/null
+++ b/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_1_f68d5ad86d67aa73074389cf9a21469e._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-14T18:07:10Z"
+ content="""
+Doesn't seem likely that this is a bug in git-annex.
+git-annex is clearly operating on the file just fine until it passes
+it off to glacier-cli.
+
+I suggest you pass --debug to git-annex, and see what glacier-cli command
+it's running. That will probably be useful information for the glacier-cli
+developers, to reproduce the problem without involving git-annex.
+
+One possibility that comes to mind, given
+<https://github.com/basak/glacier-cli/issues/16> is that your git-annex
+repository might be in a path with some characters that glacier-cli doesn't
+like in its name. If git-annex passes the full path to the file to
+glacier-cli, it might then run into this problem. I'm not sure ATM if
+git-annex does pass the full path to the file; it seems like a relative
+path would avoid such a problem. The --debug output should answer this
+too..
+"""]]
diff --git a/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_2_f0f1f18265ebb83caf4e6f1fb23ec876._comment b/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_2_f0f1f18265ebb83caf4e6f1fb23ec876._comment
new file mode 100644
index 0000000000..c288b02783
--- /dev/null
+++ b/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_2_f0f1f18265ebb83caf4e6f1fb23ec876._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="mhubig"
+ subject="comment 2"
+ date="2015-08-17T11:44:40Z"
+ content="""
+Yes it's a glacier.cli related bug ... maybe git-annex should use boto3 for glacier support ...
+"""]]
diff --git a/doc/bugs/Upgrade_impossible_om_Mac_OSX.mdwn b/doc/bugs/Upgrade_impossible_om_Mac_OSX.mdwn
new file mode 100644
index 0000000000..de0392eaa0
--- /dev/null
+++ b/doc/bugs/Upgrade_impossible_om_Mac_OSX.mdwn
@@ -0,0 +1,22 @@
+### Please describe the problem.
+When starting git-annex Version: 5.20140420-ga25b8bb Build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash on My MBP running OSX 10.9.2 I get a notification about:  An upgrade of git-annex is available. (version 5.20140421) 
+
+I then click UPGRADE and then get this message: Internal Server Error Cannot find old distribution bundle; not upgrading.
+
+### What steps will reproduce the problem?
+See problem description above, not sure what else to say.
+
+### What version of git-annex are you using? On what operating system?
+See problem description above, not sure what else to say.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_10_8c1487635f724d017ebe2f8b7bc10e8d._comment b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_10_8c1487635f724d017ebe2f8b7bc10e8d._comment
new file mode 100644
index 0000000000..13427f4663
--- /dev/null
+++ b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_10_8c1487635f724d017ebe2f8b7bc10e8d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="OK"
+ date="2014-05-21T18:19:30Z"
+ content="""
+so I'll watch this behavior with future updates and reply if I have more info
+"""]]
diff --git a/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_1_84e52a4d1502fd622bdb25e04b459292._comment b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_1_84e52a4d1502fd622bdb25e04b459292._comment
new file mode 100644
index 0000000000..6ddb5ef30d
--- /dev/null
+++ b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_1_84e52a4d1502fd622bdb25e04b459292._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="fixed"
+ date="2014-05-09T13:12:59Z"
+ content="""
+re-downloaded the old version, re-isntalled and now it actually starts downlaoding the new version => http://screencast.com/t/id2Ng57Z9
+
+NOT sure though, why it now uploads the new version to all repositories? i.e. box.com? IS there a reason for this?
+
+Transfers
+git-annex.dmg (for upgrade)→box.com 42% of 22.52 MiB
+"""]]
diff --git a/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_2_f2b109f6cf92f101d7f0afeb91605240._comment b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_2_f2b109f6cf92f101d7f0afeb91605240._comment
new file mode 100644
index 0000000000..9ed8dade9f
--- /dev/null
+++ b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_2_f2b109f6cf92f101d7f0afeb91605240._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="spoke too soon"
+ date="2014-05-09T13:23:52Z"
+ content="""
+Stuck in a loop, now with every restart of git-annex it downloads the update and then uploads it to all my repositories again:
+http://screencast.com/t/Ow7SlPVaS68 
+
+And then it says: 
+ Finished upgrading git-annex to version 5.20140420-ga25b8bb 
+BUT that is the OLD version not the new one :-/
+
+NEXT TRY:
+
+killed all processes of git and git-annex, restart. 
+
+Was greeted by: 
+ An upgrade of git-annex is available.
+(version 5.20140421)
+
+Klicked the Upgrade button.
+Nothing happens, except that the upgrade notice disappeared :-/
+"""]]
diff --git a/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_3_df9b111aefea82b9d108495b79d7ffb4._comment b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_3_df9b111aefea82b9d108495b79d7ffb4._comment
new file mode 100644
index 0000000000..32b067a97c
--- /dev/null
+++ b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_3_df9b111aefea82b9d108495b79d7ffb4._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="comment 3"
+ date="2014-05-09T13:28:38Z"
+ content="""
+here is what the log looks like:
+
+[2014-05-09 15:23:22 SAST] main: starting assistant version 5.20140420-ga25b8bb
+(scanning...) [2014-05-09 15:23:23 SAST] Watcher: Performing startup scan
+[2014-05-09 15:23:24 SAST] Upgrader: An upgrade of git-annex is available.  (version 5.20140421)
+(started...) [2014-05-09 15:25:10 SAST] main: warning git-annex has been shut down
+[2014-05-09 15:25:31 SAST] main: starting assistant version 5.20140420-ga25b8bb
+(scanning...) [2014-05-09 15:25:31 SAST] Watcher: Performing startup scan
+[2014-05-09 15:25:32 SAST] Upgrader: An upgrade of git-annex is available.  (version 5.20140421)
+(started...) [2014-05-09 15:25:59 SAST] main: warning git-annex has been shut down
+
+[2014-05-09 15:27:14 SAST] main: starting assistant version 5.20140420-ga25b8bb
+(scanning...) [2014-05-09 15:27:14 SAST] Watcher: Performing startup scan
+[2014-05-09 15:27:15 SAST] Upgrader: An upgrade of git-annex is available.  (version 5.20140421)
+(started...) [2014-05-09 15:27:46 SAST] main: starting assistant version 5.20140420-ga25b8bb
+(scanning...) [2014-05-09 15:27:46 SAST] Watcher: Performing startup scan
+(started...) [2014-05-09 15:27:48 SAST] Upgrader: An upgrade of git-annex is available.  (version 5.20140421)
+"""]]
diff --git a/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_4_e3b5bc815376383bbd1f312cc1c32a41._comment b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_4_e3b5bc815376383bbd1f312cc1c32a41._comment
new file mode 100644
index 0000000000..e55d370d99
--- /dev/null
+++ b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_4_e3b5bc815376383bbd1f312cc1c32a41._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 4"
+ date="2014-05-16T17:36:10Z"
+ content="""
+\"Cannot find old distribution bundle; not upgrading\"
+
+This message means that git-annex was unable to find where the old version was installed, which it needs to do in order to replace it with the new version. It looks for a `git-annex.app` directory, and could not find one. How did you install the old version, and to what location?
+
+I think it might try to upload the dmg file to a repository if that repository is set as a full backup and so wants all files even ones not in the work tree.
+"""]]
diff --git a/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_5_cd9b77e6670840a9902f5be80e1e658a._comment b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_5_cd9b77e6670840a9902f5be80e1e658a._comment
new file mode 100644
index 0000000000..8320e53a2b
--- /dev/null
+++ b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_5_cd9b77e6670840a9902f5be80e1e658a._comment
@@ -0,0 +1,87 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="comment 5"
+ date="2014-05-16T17:45:48Z"
+ content="""
+I gave up on this. After doing this a few times, I stopped. Living in Africa, bandwidth is really expensive :-/ 
+
+Initially I installed via the downloaded .dmg file. 
+After poking around a few times, I found a folder inside my Applications folder:
+
+    ls -al /Applications/gi*
+    /Applications/git-annex.app:
+    total 0
+    drwxr-xr-x@   3 ovi   admin   102 May 12 13:10 .
+    drwxrwxr-x+ 155 root  admin  5270 May 15 04:19 ..
+    drwxr-xr-x    5 ovi   admin   170 May  9 15:45 Contents
+
+    /Applications/git-annex.app.5.20140421:
+    total 0
+    drwxr-xr-x    2 ovi   admin    68 May 11 11:26 .
+    drwxrwxr-x+ 155 root  admin  5270 May 15 04:19 ..
+
+Every time I now open git-annex assistant I am greeted with: 
+
+    An upgrade of git-annex is available.
+    (version 5.20140421)
+
+I just did it again and it starts downloading again arrrghh!
+
+    Transfers
+    git-annex.dmg (for upgrade)←web 12% of 22.52 MiB
+
+restarted the assistant and it now says: 
+
+    Finished upgrading git-annex to version 5.20140420-ga25b8bb
+
+Then I check and find this:
+
+ls -al /Applications/gi*
+/Applications/git-annex.app:
+total 0
+drwxr-xr-x@   3 ovi   admin   102 May 12 13:10 .
+drwxrwxr-x+ 155 root  admin  5270 May 15 04:19 ..
+drwxr-xr-x    5 ovi   admin   170 May  9 15:45 Contents
+
+/Applications/git-annex.app.5.20140421:
+total 0
+drwxr-xr-x    2 ovi   admin    68 May 11 11:26 .
+drwxrwxr-x+ 155 root  admin  5270 May 15 04:19 ..
+shiny-2:~ ovi$ ls -al /Applications/gi*
+/Applications/git-annex.app:
+total 0
+drwxr-xr-x@   3 ovi   admin   102 May 12 13:10 .
+drwxrwxr-x+ 155 root  admin  5270 May 15 04:19 ..
+drwxr-xr-x    5 ovi   admin   170 May  9 15:45 Contents
+
+/Applications/git-annex.app.5.20140421:
+total 0
+drwxr-xr-x    2 ovi   admin    68 May 11 11:26 .
+drwxrwxr-x+ 155 root  admin  5270 May 15 04:19 ..
+
+LOL. restarting the assistant am greeted with click here to finish the upgrade. did so.
+
+now only 2 folders not 3 left:
+
+ls -al /Applications/gi*
+/Applications/git-annex.app:
+total 0
+drwxr-xr-x@   3 ovi   admin   102 May 12 13:10 .
+drwxrwxr-x+ 155 root  admin  5270 May 15 04:19 ..
+drwxr-xr-x    5 ovi   admin   170 May  9 15:45 Contents
+
+/Applications/git-annex.app.5.20140421:
+total 0
+drwxr-xr-x    2 ovi   admin    68 May 11 11:26 .
+drwxrwxr-x+ 155 root  admin  5270 May 15 04:19 ..
+
+Started the asistant again, am greeted with:
+
+ An upgrade of git-annex is available.
+(version 5.20140421)
+
+Thank you very much... not going to downlaod it again...
+
+COULD YOU PLEASE JUST SHARE THE DOWNLOAD LINK TO THE NEWEST ONE?
+"""]]
diff --git a/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_6_4584393333d377532d8607b42319abd9._comment b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_6_4584393333d377532d8607b42319abd9._comment
new file mode 100644
index 0000000000..023ccebfef
--- /dev/null
+++ b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_6_4584393333d377532d8607b42319abd9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="failed upgrade log file"
+ date="2014-05-16T17:55:34Z"
+ content="""
+Just in case it helps diagnose the problem: http://pastebin.com/PUpPRURb
+"""]]
diff --git a/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_7_d9d36ff62267dde98a27c5981951df7f._comment b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_7_d9d36ff62267dde98a27c5981951df7f._comment
new file mode 100644
index 0000000000..b38502bf40
--- /dev/null
+++ b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_7_d9d36ff62267dde98a27c5981951df7f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 7"
+ date="2014-05-16T17:57:13Z"
+ content="""
+The repeated attempts to upgrade to 21 when it only downloads 20 are due to a different bug: [[bugs/git-annex_auto_upgrade_is_redundant]]. I've just put in a quick fix that should avoid that.
+
+However, for the purposes of this bug report, I'm interested in the original problem of \"Cannot find old distribution bundle; not upgrading\", and to fix that, I need to know how you originally installed git-annex.
+"""]]
diff --git a/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_8_5b26711c737eeb0b302060f098cb320b._comment b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_8_5b26711c737eeb0b302060f098cb320b._comment
new file mode 100644
index 0000000000..b2cab60970
--- /dev/null
+++ b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_8_5b26711c737eeb0b302060f098cb320b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="comment 8"
+ date="2014-05-16T17:59:13Z"
+ content="""
+download 20.dmg, double clicked it, dragged it into my Applications folder.
+"""]]
diff --git a/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_9_1bf050056dcac7c1e0f497ee6e87a95a._comment b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_9_1bf050056dcac7c1e0f497ee6e87a95a._comment
new file mode 100644
index 0000000000..245bdc56a8
--- /dev/null
+++ b/doc/bugs/Upgrade_impossible_om_Mac_OSX/comment_9_1bf050056dcac7c1e0f497ee6e87a95a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.3"
+ subject="comment 9"
+ date="2014-05-21T17:28:16Z"
+ content="""
+I have adjusted the \"Cannot find old distribution bundle; not upgrading\" message to say where it looked, and failed to find the git-annex.app directory.
+
+I am going to have to moreinfo this, since without knowing where git-annex was installed to, I can't say why it failed to find a git-annex.app directory.
+"""]]
diff --git a/doc/bugs/Upload_to_S3_fails_.mdwn b/doc/bugs/Upload_to_S3_fails_.mdwn
new file mode 100644
index 0000000000..de74bfd7f8
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_.mdwn
@@ -0,0 +1,59 @@
+### Please describe the problem.
+
+Uploading a 21GB file to an S3 special remote fails. It will generally fail somewhere at about 3-15%. I am using the new chunking feature, with chunks set to 25MiB.
+
+### What steps will reproduce the problem?
+
+    $ git annex copy my-big-file.tar.bz --to s3
+    copy my-big-file.tar.bz (gpg) (checking s3...) (to s3...)
+    13%       863.8KB/s 6h0m
+      ErrorClosed
+    failed
+    git-annex: copy: 1 failed
+
+### What version of git-annex are you using? On what operating system?
+
+Running on Arch Linux.
+
+    git-annex version: 5.20140818-g10bf03a
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+### Please provide any additional information below.
+
+If I fire up the web app and open the log, the end looks like this:
+
+
+[[!format sh """
+...
+
+3%       857.3KB/s 6h46m
+3%       857.3KB/s 6h46m
+3%       857.3KB/s 6h46m
+3%       857.4KB/s 6h46m
+3%       857.4KB/s 6h46m
+3%       857.5KB/s 6h46m
+3%       857.5KB/s 6h46m
+3%       857.6KB/s 6h46m
+3%       857.6KB/s 6h46m
+3%       857.6KB/s 6h46m
+3%       857.7KB/s 6h46m
+3%       857.7KB/s 6h46m
+3%       857.8KB/s 6h46m
+3%       857.8KB/s 6h46m
+3%       857.8KB/s 6h46m
+3%       857.9KB/s 6h46m
+3%       857.9KB/s 6h46m
+3%       858.0KB/s 6h46m
+3%       858.0KB/s 6h46m
+3%       858.1KB/s 6h46m
+3%       858.1KB/s 6h45m
+3%       858.1KB/s 6h45mmux_client_request_session: read from master failed: Broken pipe
+
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_10_b7e912bac673bdffa5775b71d5d39937._comment b/doc/bugs/Upload_to_S3_fails_/comment_10_b7e912bac673bdffa5775b71d5d39937._comment
new file mode 100644
index 0000000000..ecc34d4871
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_10_b7e912bac673bdffa5775b71d5d39937._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkvSZ1AFJdY_1FeutZr_KWeqtzjZta1PNE"
+ nickname="Thedward"
+ subject="comment 10"
+ date="2014-10-21T21:25:57Z"
+ content="""
+The only files that succeeded were small text files. The other files — 3-200MiB — all failed.
+"""]]
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_11_65cb9b1dd69cd657f2cfde036eb60417._comment b/doc/bugs/Upload_to_S3_fails_/comment_11_65cb9b1dd69cd657f2cfde036eb60417._comment
new file mode 100644
index 0000000000..ec59d6a207
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_11_65cb9b1dd69cd657f2cfde036eb60417._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.96"
+ subject="comment 11"
+ date="2014-10-23T21:05:15Z"
+ content="""
+When it resumes, it will start at 0% but jump forward to the resume point pretty quickly, after verifying which chunks have already been sent.
+If any full chunk gets transferred, I'd expect it to resume. This may not be very obvious it's happening for smaller files.
+
+I have been running `git annex testremote` against S3 special remotes today, and have not managed to reproduce this problem (using either the old S3 or the new AWS libraries). It could be anything, including a problem with your network or the network between you and the S3 endpoint. Have you tried using a different S3 region?
+"""]]
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment b/doc/bugs/Upload_to_S3_fails_/comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment
new file mode 100644
index 0000000000..a18ca1d05a
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-09-18T18:49:43Z"
+ content="""
+This is using the old hS3 library. So, each chunk is sent using a new http connection. It seems that the connection must be being closed by S3 part way through the upload of a chunk.
+
+It may be that the new aws library somehow avoids this problem. So, a git-annex built with the `s3-aws` branch merged in may help with this bug. OTOH, that new branch makes a single http connection be reused for all the chunks in a file, so it might also make things worse.
+"""]]
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_2_f33ce058c9460cf7d151e739bff0440a._comment b/doc/bugs/Upload_to_S3_fails_/comment_2_f33ce058c9460cf7d151e739bff0440a._comment
new file mode 100644
index 0000000000..dcf719bba7
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_2_f33ce058c9460cf7d151e739bff0440a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 2"
+ date="2014-09-18T18:52:17Z"
+ content="""
+If you're using the new chunking system, git-annex should support resuming the upload to S3. Next time you try to send the file, it should find the chunks that were successfully sent, and resume at the chunk where it failed.
+
+Supporting this even for encrypted uploads was a major benefit of the new chunking system, so I hope it works...?
+"""]]
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_3_cd1e768fe1e67daf08b5afd460620922._comment b/doc/bugs/Upload_to_S3_fails_/comment_3_cd1e768fe1e67daf08b5afd460620922._comment
new file mode 100644
index 0000000000..5efb786853
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_3_cd1e768fe1e67daf08b5afd460620922._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="annexuser"
+ ip="71.198.212.13"
+ subject="comment 3"
+ date="2014-09-19T04:43:42Z"
+ content="""
+Was the version I listed above not using the new chunking from the `s3-aws` branch? How do I determine if my version of git-annex was built with the new or old chunking?
+"""]]
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_4_0cdd2e8d6e83c03de717ecd3253e753d._comment b/doc/bugs/Upload_to_S3_fails_/comment_4_0cdd2e8d6e83c03de717ecd3253e753d._comment
new file mode 100644
index 0000000000..216aea5751
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_4_0cdd2e8d6e83c03de717ecd3253e753d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="67.223.1.203"
+ subject="comment 4"
+ date="2014-09-19T18:33:17Z"
+ content="""
+Your version supports both new and old style chunking. Which is used depends on how the S3 remote was configured when it was set up. It can't really be changed w/o re-setting up the remote. You can check which is used by `git show git-annex:remote.log`, find the line for the UUID of the remote, and see if it has chunk= (new chunking) or chunksize= (old chunking).
+"""]]
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_5_020c055f6c06860dda27c1debb123742._comment b/doc/bugs/Upload_to_S3_fails_/comment_5_020c055f6c06860dda27c1debb123742._comment
new file mode 100644
index 0000000000..368d2853f7
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_5_020c055f6c06860dda27c1debb123742._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkvSZ1AFJdY_1FeutZr_KWeqtzjZta1PNE"
+ nickname="Thedward"
+ subject="comment 5"
+ date="2014-10-21T04:10:16Z"
+ content="""
+
+I am experiencing similar behavior on Ubuntu Trusty (x86_64) using a prebuilt Linux release:
+
+    Linux hostname 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
+
+    Distributor ID:	Ubuntu
+    Description:	Ubuntu 14.04.1 LTS
+    Release:	14.04
+    Codename:	trusty
+
+    git-annex version: 5.20141016-g26b38fd
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+
+Copying files to S3 consistently fails both from the command line and via the assistant:
+
+    [2014-10-20 22:34:32 CDT] read: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+    [2014-10-20 22:34:32 CDT] read: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2014-10-20 22:34:32 CDT] read: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..78e9b6b85f3b453d8ed4f66f63ff09e03ce13d06\",\"-n1\",\"--pretty=%H\"]
+    [2014-10-20 22:34:32 CDT] read: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..658720ba59a2fefee89c908b972971ca901f84dc\",\"-n1\",\"--pretty=%H\"]
+    [2014-10-20 22:34:32 CDT] chat: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
+    [2014-10-20 22:34:32 CDT] read: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"storage/data.bin\"]
+    [2014-10-20 22:34:32 CDT] chat: git [\"--git-dir=/home/user/git-annex/.git\",\"--work-tree=/home/user/git-annex\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
+    copy storage/data.bin (gpg) (checking S3git-annex...) (to S3git-annex...) 
+    0%            0.0 B/s 0s[2014-10-20 22:34:33 CDT] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"14\",\"--symmetric\",\"--force-mdc\",\"--no-textmode\"]
+    8%         512.0KB/s 21s[2014-10-20 22:34:35 CDT] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"14\",\"--symmetric\",\"--force-mdc\",\"--no-textmode\"]
+    8%         528.0KB/s 21s
+      ErrorClosed
+    failed                  
+    git-annex: copy: 1 failed
+
+Two files (out of several hundred) have succeeded.
+
+Any ideas?
+
+"""]]
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_6_8bc023fca8cedfc517856cdcd20b7f10._comment b/doc/bugs/Upload_to_S3_fails_/comment_6_8bc023fca8cedfc517856cdcd20b7f10._comment
new file mode 100644
index 0000000000..ed21bb8fb6
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_6_8bc023fca8cedfc517856cdcd20b7f10._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.96"
+ subject="comment 6"
+ date="2014-10-21T16:31:02Z"
+ content="""
+I need to know if the S3 remote is configured to use the new style chunking feature, and what size chunks it is configured to use. I have already explained how to check that in this thread.
+
+I also need to know if retrying the upload after it fails lets it resume where it left off.
+"""]]
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_7_32685258748a7cdd177e7af2105f128e._comment b/doc/bugs/Upload_to_S3_fails_/comment_7_32685258748a7cdd177e7af2105f128e._comment
new file mode 100644
index 0000000000..4d66552245
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_7_32685258748a7cdd177e7af2105f128e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkvSZ1AFJdY_1FeutZr_KWeqtzjZta1PNE"
+ nickname="Thedward"
+ subject="comment 7"
+ date="2014-10-21T17:35:16Z"
+ content="""
+It is running the new style chunking (chunk=1MiB).
+
+It does not appear to resume when it tries again. If I try copying a file to the remote from the command line, it always starts at 0% and dies at some point before 100% even if it has tried to copy that file before.
+"""]]
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_8_841fd94d0f599c71a76fd22b07944366._comment b/doc/bugs/Upload_to_S3_fails_/comment_8_841fd94d0f599c71a76fd22b07944366._comment
new file mode 100644
index 0000000000..61e201c9db
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_8_841fd94d0f599c71a76fd22b07944366._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkvSZ1AFJdY_1FeutZr_KWeqtzjZta1PNE"
+ nickname="Thedward"
+ subject="comment 8"
+ date="2014-10-21T17:47:35Z"
+ content="""
+Additional info: I created both of the related git-annex repositories yesterday via the webapp. Then imported a number of files to each one. Then connected them via xmpp. Then created the S3 remote via the webapp so they could actually share files. I am using an IAM identity for S3 instead of my root access key; it has full S3 access (and data IS showing up in the bucket, so it's not a *simple* permissions problem).
+"""]]
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_9_dd837a1cb2146224b9c000cbeea4f3b3._comment b/doc/bugs/Upload_to_S3_fails_/comment_9_dd837a1cb2146224b9c000cbeea4f3b3._comment
new file mode 100644
index 0000000000..4cfda38c2f
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_9_dd837a1cb2146224b9c000cbeea4f3b3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.96"
+ subject="comment 9"
+ date="2014-10-21T20:22:52Z"
+ content="""
+How big is the file that it fails to copy?
+"""]]
diff --git a/doc/bugs/User-Agent_not_sent_with_S3_remote.mdwn b/doc/bugs/User-Agent_not_sent_with_S3_remote.mdwn
new file mode 100644
index 0000000000..b270f8163c
--- /dev/null
+++ b/doc/bugs/User-Agent_not_sent_with_S3_remote.mdwn
@@ -0,0 +1,3 @@
+### Please describe the problem.
+
+git-annex does not appear to send a User-Agent when used with an S3 remote.
diff --git a/doc/bugs/User-Agent_not_sent_with_S3_remote/comment_1_68fd5b6a69d90bb9623740752a918657._comment b/doc/bugs/User-Agent_not_sent_with_S3_remote/comment_1_68fd5b6a69d90bb9623740752a918657._comment
new file mode 100644
index 0000000000..03bf891cc5
--- /dev/null
+++ b/doc/bugs/User-Agent_not_sent_with_S3_remote/comment_1_68fd5b6a69d90bb9623740752a918657._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-02-10T17:49:31Z"
+ content="""
+Unfortunately the `aws` library git-annex uses does not allow a user-agent
+to be provided. Filed an issue here: 
+<https://github.com/aristidb/aws/issues/286>
+
+What is the severity of this for you? Is there a S3 endpoint that requires
+a user-agent be sent, or would it only be nice to have?
+"""]]
diff --git a/doc/bugs/Utility.Url.Parse_fails_to_build_on_Win___40__imports__41__.mdwn b/doc/bugs/Utility.Url.Parse_fails_to_build_on_Win___40__imports__41__.mdwn
new file mode 100644
index 0000000000..d4dd1b5474
--- /dev/null
+++ b/doc/bugs/Utility.Url.Parse_fails_to_build_on_Win___40__imports__41__.mdwn
@@ -0,0 +1,96 @@
+### Please describe the problem.
+
+The removal of some imports causes Utility.Url.Parse to fail to build on Windows.
+
+### What steps will reproduce the problem?
+
+`stack --stack-yaml stack-lts-18.13.yaml setup && stack --stack-yaml stack-lts-18.13.yaml build`
+
+Observe the following output:
+
+[[!format sh """
+[...]
+C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-230817-83056e7b5\Utility\Terminal.hs:43:41: warning: [-Wunused-matches]
+    Defined but not used: b'
+   |
+43 |                                         b' <- isMinTTYHandle h'
+   |                                         ^^
+[106 of 689] Compiling Utility.ThreadLock
+[107 of 689] Compiling Utility.ThreadScheduler
+[108 of 689] Compiling Utility.TimeStamp
+[109 of 689] Compiling Annex.VectorClock.Utility
+[110 of 689] Compiling Utility.Tmp
+[111 of 689] Compiling Utility.MoveFile
+[112 of 689] Compiling Utility.Tmp.Dir
+[113 of 689] Compiling Utility.Touch
+[114 of 689] Compiling Utility.Tuple
+[115 of 689] Compiling Utility.Scheduled
+[116 of 689] Compiling Utility.Scheduled.QuickCheck
+[117 of 689] Compiling Utility.Url.Parse
+
+C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-230817-83056e7b5\Utility\Url\Parse.hs:34:19: error:
+    Variable not in scope: isPrefixOf :: t0 -> String -> Bool
+   |
+34 |         | "file:" `isPrefixOf` s = do
+   |                   ^^^^^^^^^^^^
+
+Error: [S-7282]
+       Stack failed to execute the build plan.
+
+       While executing the build plan, Stack encountered the error:
+
+       [S-7011]
+       While building package git-annex-10.20230802 (scroll up to its section to see the error)
+       using:
+       C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-230817-83056e7b5\.stack-work\dist\274b403a\setup\setup --verbose=1 --builddir=.stack-work\dist\274b403a build exe:git-annex --ghc-options ""
+       Process exited with code: ExitFailure 1
+
+# End of transcript or log.
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20230803-g83056e7b53
+build flags: Assistant Webapp Pairing TorrentParser Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+"""]]
+
+A successful build that passes the testsuite on Windows is achieved with the patch below.
+
+Windows 10 version 22H2 (build 19045.3324), 64 bit.
+
+### Please provide any additional information below.
+
+Apply the following patch to build on Windows:
+
+[[!format diff """
+diff --git a/Utility/Url/Parse.hs b/Utility/Url/Parse.hs
+index 7fc952b034..ab456ed31e 100644
+--- a/Utility/Url/Parse.hs
++++ b/Utility/Url/Parse.hs
+@@ -18,6 +18,7 @@ module Utility.Url.Parse (
+
+ import Network.URI
+ #ifdef mingw32_HOST_OS
++import Common
+ import qualified System.FilePath.Windows as PW
+ #endif
+
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sure, Git Annex is great as always. I use it several times a week with my multigigabyte
+backups, where it gives structure to my image-based backup routines, so you could
+say I'm a believer. :)
+
+[[!meta title="Utility.Url.Parse fails to build on Windows (missing import)"]]
+[[!meta author=jkniiv]]
+
+> [[fixed|done]], thank you! --[[Joey]]
diff --git a/doc/bugs/VFAT_crazy_limit_on_max_filenames_in_directory.mdwn b/doc/bugs/VFAT_crazy_limit_on_max_filenames_in_directory.mdwn
new file mode 100644
index 0000000000..8c526ea620
--- /dev/null
+++ b/doc/bugs/VFAT_crazy_limit_on_max_filenames_in_directory.mdwn
@@ -0,0 +1,2 @@
+VFAT limits have been hit when the .git/annex/journal/
+directory gets a lot of stuff in it. See <http://bugs.debian.org/696313>
diff --git a/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects.mdwn b/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects.mdwn
new file mode 100644
index 0000000000..f73238565a
--- /dev/null
+++ b/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects.mdwn
@@ -0,0 +1,399 @@
+### Please describe the problem.
+
+When exporting commits to S3 with versioning=yes and exporttree=yes, deleted annexed objects are marked as deleted but deleted git objects remain. This prevents a user from retrieving a consistent version of the exporttree commit without using git-annex.
+
+### What steps will reproduce the problem?
+
+* Create a repository and add annexed and git objects.
+* Add S3 special remote with exporttree=yes and versioning=yes
+* Export to the remote.
+* Remove a git object and an annexed object.
+* Export again and the annexed object will be removed while the git object remains.
+
+Example repository and publicly readable remote having this issue here:
+
+https://github.com/openneurodatasets/ds001705
+
+Git files in the 1.0.0 tag are still present in the S3 1.0.1 export. sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json is an example file not present in 1.0.1 that is still present on S3.
+
+### What version of git-annex are you using? On what operating system?
+
+Debian bullseye
+
+```
+git-annex version: 10.20220927-ga92546587
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+### Please provide any additional information below.
+
+[[!format sh """
+# git annex export 1.0.0 --to=s3-PUBLIC
+export s3-PUBLIC .bidsignore 
+ok                                
+export s3-PUBLIC .datalad/.gitattributes 
+ok                                
+export s3-PUBLIC .datalad/config 
+ok                                
+export s3-PUBLIC .gitattributes 
+ok                                
+export s3-PUBLIC CHANGES 
+ok                                
+export s3-PUBLIC README 
+ok                                
+export s3-PUBLIC dataset_description.json 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/anat/sub-000101_ses-baseline_T1w.nii.gz 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/anat/sub-000101_ses-baseline_label-displacementROI_dseg.nii.gz 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/pet/.bidsignore 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_K1.nii.gz 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_Vb.nii.gz 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_k2.nii.gz 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_k3.nii.gz 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_k4.nii.gz 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.nii.gz 
+ok                                
+export s3-PUBLIC sub-000101/ses-displaced/anat/sub-000101_ses-displaced_T1w.nii.gz 
+ok                                
+export s3-PUBLIC sub-000101/ses-displaced/anat/sub-000101_ses-displaced_label-displacementROI_dseg.nii.gz 
+ok                                
+export s3-PUBLIC sub-000101/ses-displaced/pet/.bidsignore 
+ok                                
+export s3-PUBLIC sub-000101/ses-displaced/pet/sub-000101_ses-displaced_k3.nii.gz 
+ok                                
+export s3-PUBLIC sub-000101/ses-displaced/pet/sub-000101_ses-displaced_rec-MLEM_pet.json 
+ok                                
+export s3-PUBLIC sub-000101/ses-displaced/pet/sub-000101_ses-displaced_rec-MLEM_pet.nii.gz 
+ok                                
+export s3-PUBLIC sub-000102/ses-baseline/anat/sub-000102_ses-baseline_T1w.nii.gz 
+ok                                
+export s3-PUBLIC sub-000102/ses-baseline/anat/sub-000102_ses-baseline_label-displacementROI_dseg.nii.gz 
+ok                                
+export s3-PUBLIC sub-000102/ses-baseline/pet/.bidsignore 
+ok                                
+export s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_K1.nii.gz 
+ok                                
+export s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_Vb.nii.gz 
+ok                                
+export s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_k2.nii.gz 
+ok                                
+export s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_k3.nii.gz 
+ok                                
+export s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_k4.nii.gz 
+ok                                
+export s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_rec-MLEM_pet.json 
+ok                                
+export s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_rec-MLEM_pet.nii.gz 
+ok                                
+export s3-PUBLIC sub-000102/ses-displaced/anat/sub-000102_ses-displaced_T1w.nii.gz 
+ok                                
+export s3-PUBLIC sub-000102/ses-displaced/anat/sub-000102_ses-displaced_label-displacementROI_dseg.nii.gz 
+ok                                
+export s3-PUBLIC sub-000102/ses-displaced/pet/.bidsignore 
+ok                                
+export s3-PUBLIC sub-000102/ses-displaced/pet/sub-000102_ses-displaced_k3.nii.gz 
+ok                                
+export s3-PUBLIC sub-000102/ses-displaced/pet/sub-000102_ses-displaced_rec-MLEM_pet.json 
+ok                                
+export s3-PUBLIC sub-000102/ses-displaced/pet/sub-000102_ses-displaced_rec-MLEM_pet.nii.gz 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/anat/sub-000103_ses-baseline_T1w.nii.gz 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/anat/sub-000103_ses-baseline_label-displacementROI_dseg.nii.gz 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/pet/.bidsignore 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_K1.nii.gz 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_Vb.nii.gz 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_k2.nii.gz 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_k3.nii.gz 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_k4.nii.gz 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_rec-MLEM_pet.json 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_rec-MLEM_pet.nii.gz 
+ok                                
+export s3-PUBLIC sub-000103/ses-displaced/anat/sub-000103_ses-displaced_T1w.nii.gz 
+ok                                
+export s3-PUBLIC sub-000103/ses-displaced/anat/sub-000103_ses-displaced_label-displacementROI_dseg.nii.gz 
+ok                                
+export s3-PUBLIC sub-000103/ses-displaced/pet/.bidsignore 
+ok                                
+export s3-PUBLIC sub-000103/ses-displaced/pet/sub-000103_ses-displaced_k3.nii.gz 
+ok                                
+export s3-PUBLIC sub-000103/ses-displaced/pet/sub-000103_ses-displaced_rec-MLEM_pet.json 
+ok                                
+export s3-PUBLIC sub-000103/ses-displaced/pet/sub-000103_ses-displaced_rec-MLEM_pet.nii.gz 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/anat/sub-000104_ses-baseline_T1w.nii.gz 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/anat/sub-000104_ses-baseline_label-displacementROI_dseg.nii.gz 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/pet/.bidsignore 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_K1.nii.gz 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_Vb.nii.gz 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_k2.nii.gz 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_k3.nii.gz 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_k4.nii.gz 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_rec-MLEM_pet.json 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_rec-MLEM_pet.nii.gz 
+ok                                
+export s3-PUBLIC sub-000104/ses-displaced/anat/sub-000104_ses-displaced_T1w.nii.gz 
+ok                                
+export s3-PUBLIC sub-000104/ses-displaced/anat/sub-000104_ses-displaced_label-displacementROI_dseg.nii.gz 
+ok                                
+export s3-PUBLIC sub-000104/ses-displaced/pet/.bidsignore 
+ok                                
+export s3-PUBLIC sub-000104/ses-displaced/pet/sub-000104_ses-displaced_k3.nii.gz 
+ok                                
+export s3-PUBLIC sub-000104/ses-displaced/pet/sub-000104_ses-displaced_rec-MLEM_pet.json 
+ok                                
+export s3-PUBLIC sub-000104/ses-displaced/pet/sub-000104_ses-displaced_rec-MLEM_pet.nii.gz 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/anat/sub-000105_ses-baseline_T1w.nii.gz 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/anat/sub-000105_ses-baseline_label-displacementROI_dseg.nii.gz 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/pet/.bidsignore 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_K1.nii.gz 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_Vb.nii.gz 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_k2.nii.gz 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_k3.nii.gz 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_k4.nii.gz 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_rec-MLEM_pet.json 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_rec-MLEM_pet.nii.gz 
+ok                                
+export s3-PUBLIC sub-000105/ses-displaced/anat/sub-000105_ses-displaced_T1w.nii.gz 
+ok                                
+export s3-PUBLIC sub-000105/ses-displaced/anat/sub-000105_ses-displaced_label-displacementROI_dseg.nii.gz 
+ok                                
+export s3-PUBLIC sub-000105/ses-displaced/pet/.bidsignore 
+ok                                
+export s3-PUBLIC sub-000105/ses-displaced/pet/sub-000105_ses-displaced_k3.nii.gz 
+ok                                
+export s3-PUBLIC sub-000105/ses-displaced/pet/sub-000105_ses-displaced_rec-MLEM_pet.json 
+ok                                
+export s3-PUBLIC sub-000105/ses-displaced/pet/sub-000105_ses-displaced_rec-MLEM_pet.nii.gz 
+ok                                 
+(recording state in git...)
+
+# git annex export 1.0.1 --to=s3-PUBLIC
+unexport s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_K1.nii.gz ok
+unexport s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_k2.nii.gz ok
+unexport s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_k3.nii.gz ok
+unexport s3-PUBLIC .bidsignore ok
+unexport s3-PUBLIC sub-000101/ses-baseline/anat/sub-000101_ses-baseline_T1w.nii.gz ok
+rename s3-PUBLIC sub-000101/ses-baseline/anat/sub-000101_ses-baseline_label-displacementROI_dseg.nii.gz -> .git-annex-tmp-content-MD5E-s9793--13db6c96808070211b8987c327240ff8.nii.gz ok
+unexport s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_Vb.nii.gz ok
+unexport s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_K1.nii.gz ok
+unexport s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_Vb.nii.gz ok
+unexport s3-PUBLIC sub-000104/ses-baseline/anat/sub-000104_ses-baseline_T1w.nii.gz ok
+unexport s3-PUBLIC sub-000104/ses-displaced/pet/sub-000104_ses-displaced_rec-MLEM_pet.nii.gz ok
+unexport s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_k4.nii.gz ok
+unexport s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_k3.nii.gz ok
+unexport s3-PUBLIC sub-000103/ses-displaced/anat/sub-000103_ses-displaced_T1w.nii.gz ok
+unexport s3-PUBLIC sub-000105/ses-displaced/pet/sub-000105_ses-displaced_k3.nii.gz ok
+rename s3-PUBLIC sub-000102/ses-displaced/anat/sub-000102_ses-displaced_label-displacementROI_dseg.nii.gz -> .git-annex-tmp-content-MD5E-s9794--419a63ecba6de7235554c1f5a7fbc7d8.nii.gz ok
+rename s3-PUBLIC sub-000102/ses-baseline/anat/sub-000102_ses-baseline_label-displacementROI_dseg.nii.gz -> .git-annex-tmp-content-MD5E-s9793--45358ccfe2d8a7455c3202691ee632eb.nii.gz ok
+unexport s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_rec-MLEM_pet.nii.gz ok
+rename s3-PUBLIC sub-000105/ses-baseline/anat/sub-000105_ses-baseline_label-displacementROI_dseg.nii.gz -> .git-annex-tmp-content-MD5E-s9793--508a92de80b90e3030d2e46bb920f051.nii.gz ok
+rename s3-PUBLIC sub-000101/ses-displaced/anat/sub-000101_ses-displaced_label-displacementROI_dseg.nii.gz -> .git-annex-tmp-content-MD5E-s9794--512f12576f0f99de20f12aa715000251.nii.gz ok
+unexport s3-PUBLIC dataset_description.json ok
+unexport s3-PUBLIC sub-000105/ses-displaced/pet/sub-000105_ses-displaced_rec-MLEM_pet.nii.gz ok
+unexport s3-PUBLIC CHANGES ok
+unexport s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_Vb.nii.gz ok
+unexport s3-PUBLIC sub-000101/ses-displaced/anat/sub-000101_ses-displaced_T1w.nii.gz ok
+unexport s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_K1.nii.gz ok
+unexport s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_K1.nii.gz ok
+unexport s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_rec-MLEM_pet.nii.gz ok
+rename s3-PUBLIC sub-000105/ses-displaced/anat/sub-000105_ses-displaced_label-displacementROI_dseg.nii.gz -> .git-annex-tmp-content-MD5E-s9794--726e1c95511fb7b8bc94f275e9d6e9e7.nii.gz ok
+unexport s3-PUBLIC sub-000105/ses-baseline/anat/sub-000105_ses-baseline_T1w.nii.gz ok
+unexport s3-PUBLIC sub-000105/ses-displaced/pet/.bidsignore ok
+unexport s3-PUBLIC sub-000105/ses-displaced/anat/sub-000105_ses-displaced_T1w.nii.gz ok
+unexport s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_Vb.nii.gz ok
+unexport s3-PUBLIC sub-000103/ses-displaced/pet/sub-000103_ses-displaced_rec-MLEM_pet.nii.gz ok
+unexport s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_rec-MLEM_pet.nii.gz ok
+rename s3-PUBLIC sub-000103/ses-displaced/anat/sub-000103_ses-displaced_label-displacementROI_dseg.nii.gz -> .git-annex-tmp-content-MD5E-s9794--887598ee2277aeebae901fd7d97a7f4c.nii.gz ok
+unexport s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_k4.nii.gz ok
+unexport s3-PUBLIC sub-000105/ses-displaced/pet/sub-000105_ses-displaced_rec-MLEM_pet.json ok
+unexport s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_Vb.nii.gz ok
+unexport s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_k3.nii.gz ok
+unexport s3-PUBLIC sub-000103/ses-displaced/pet/sub-000103_ses-displaced_k3.nii.gz ok
+unexport s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_k4.nii.gz ok
+unexport s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_k3.nii.gz ok
+unexport s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_rec-MLEM_pet.nii.gz ok
+unexport s3-PUBLIC sub-000103/ses-baseline/anat/sub-000103_ses-baseline_T1w.nii.gz ok
+unexport s3-PUBLIC sub-000102/ses-displaced/anat/sub-000102_ses-displaced_T1w.nii.gz ok
+unexport s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_k2.nii.gz ok
+unexport s3-PUBLIC sub-000101/ses-displaced/pet/sub-000101_ses-displaced_k3.nii.gz ok
+unexport s3-PUBLIC README ok
+rename s3-PUBLIC sub-000104/ses-displaced/anat/sub-000104_ses-displaced_label-displacementROI_dseg.nii.gz -> .git-annex-tmp-content-MD5E-s9794--bd645a943d74dda136f4e0c421d49c85.nii.gz ok
+unexport s3-PUBLIC sub-000104/ses-displaced/pet/sub-000104_ses-displaced_k3.nii.gz ok
+unexport s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_K1.nii.gz ok
+unexport s3-PUBLIC sub-000101/ses-displaced/pet/sub-000101_ses-displaced_rec-MLEM_pet.nii.gz ok
+unexport s3-PUBLIC sub-000102/ses-displaced/pet/sub-000102_ses-displaced_k3.nii.gz ok
+unexport s3-PUBLIC sub-000102/ses-baseline/anat/sub-000102_ses-baseline_T1w.nii.gz ok
+unexport s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_k2.nii.gz ok
+unexport s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_k4.nii.gz ok
+unexport s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_k2.nii.gz ok
+rename s3-PUBLIC sub-000104/ses-baseline/anat/sub-000104_ses-baseline_label-displacementROI_dseg.nii.gz -> .git-annex-tmp-content-MD5E-s9793--de819fa10f3f6253e4eeec3b77158726.nii.gz ok
+unexport s3-PUBLIC sub-000102/ses-displaced/pet/sub-000102_ses-displaced_rec-MLEM_pet.nii.gz ok
+unexport s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_k3.nii.gz ok
+rename s3-PUBLIC sub-000103/ses-baseline/anat/sub-000103_ses-baseline_label-displacementROI_dseg.nii.gz -> .git-annex-tmp-content-MD5E-s9793--e6f2a37df1a0a47325fc9cb065117e0d.nii.gz ok
+unexport s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_k2.nii.gz ok
+unexport s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.nii.gz ok
+unexport s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_k4.nii.gz ok
+unexport s3-PUBLIC sub-000104/ses-displaced/anat/sub-000104_ses-displaced_T1w.nii.gz ok
+rename s3-PUBLIC .git-annex-tmp-content-MD5E-s9793--13db6c96808070211b8987c327240ff8.nii.gz -> derivatives/masks/sub-000101/ses-baseline/sub-000101_ses-baseline_label-displacementROI_dseg.nii.gz ok
+rename s3-PUBLIC .git-annex-tmp-content-MD5E-s9794--419a63ecba6de7235554c1f5a7fbc7d8.nii.gz -> derivatives/masks/sub-000102/ses-displaced/sub-000102_ses-displaced_label-displacementROI_dseg.nii.gz ok
+rename s3-PUBLIC .git-annex-tmp-content-MD5E-s9793--45358ccfe2d8a7455c3202691ee632eb.nii.gz -> derivatives/masks/sub-000102/ses-baseline/sub-000102_ses-baseline_label-displacementROI_dseg.nii.gz ok
+rename s3-PUBLIC .git-annex-tmp-content-MD5E-s9793--508a92de80b90e3030d2e46bb920f051.nii.gz -> derivatives/masks/sub-000105/ses-baseline/sub-000105_ses-baseline_label-displacementROI_dseg.nii.gz ok
+rename s3-PUBLIC .git-annex-tmp-content-MD5E-s9794--512f12576f0f99de20f12aa715000251.nii.gz -> derivatives/masks/sub-000101/ses-displaced/sub-000101_ses-displaced_label-displacementROI_dseg.nii.gz ok
+rename s3-PUBLIC .git-annex-tmp-content-MD5E-s9794--726e1c95511fb7b8bc94f275e9d6e9e7.nii.gz -> derivatives/masks/sub-000105/ses-displaced/sub-000105_ses-displaced_label-displacementROI_dseg.nii.gz ok
+rename s3-PUBLIC .git-annex-tmp-content-MD5E-s9794--887598ee2277aeebae901fd7d97a7f4c.nii.gz -> derivatives/masks/sub-000103/ses-displaced/sub-000103_ses-displaced_label-displacementROI_dseg.nii.gz ok
+rename s3-PUBLIC .git-annex-tmp-content-MD5E-s9794--bd645a943d74dda136f4e0c421d49c85.nii.gz -> derivatives/masks/sub-000104/ses-displaced/sub-000104_ses-displaced_label-displacementROI_dseg.nii.gz ok
+rename s3-PUBLIC .git-annex-tmp-content-MD5E-s9793--de819fa10f3f6253e4eeec3b77158726.nii.gz -> derivatives/masks/sub-000104/ses-baseline/sub-000104_ses-baseline_label-displacementROI_dseg.nii.gz ok
+rename s3-PUBLIC .git-annex-tmp-content-MD5E-s9793--e6f2a37df1a0a47325fc9cb065117e0d.nii.gz -> derivatives/masks/sub-000103/ses-baseline/sub-000103_ses-baseline_label-displacementROI_dseg.nii.gz ok
+export s3-PUBLIC .bidsignore 
+ok                                
+export s3-PUBLIC CHANGES 
+ok                                
+export s3-PUBLIC LICENSE 
+ok                                
+export s3-PUBLIC README 
+ok                                
+export s3-PUBLIC dataset_description.json 
+ok                                
+export s3-PUBLIC derivatives/masks/dseg.tsv 
+ok                                
+export s3-PUBLIC participants.json 
+ok                                
+export s3-PUBLIC participants.tsv 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/anat/sub-000101_ses-baseline_T1w.json 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/anat/sub-000101_ses-baseline_T1w.nii 
+ok                                 
+export s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_pet.json 
+ok                                
+export s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_pet.nii 
+ok                                   
+export s3-PUBLIC sub-000101/ses-displaced/anat/sub-000101_ses-displaced_T1w.json 
+ok                                
+export s3-PUBLIC sub-000101/ses-displaced/anat/sub-000101_ses-displaced_T1w.nii 
+ok                                 
+export s3-PUBLIC sub-000101/ses-displaced/pet/sub-000101_ses-displaced_pet.json 
+ok                                
+export s3-PUBLIC sub-000101/ses-displaced/pet/sub-000101_ses-displaced_pet.nii 
+ok                                   
+export s3-PUBLIC sub-000102/ses-baseline/anat/sub-000102_ses-baseline_T1w.json 
+ok                                
+export s3-PUBLIC sub-000102/ses-baseline/anat/sub-000102_ses-baseline_T1w.nii 
+ok                                 
+export s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_pet.json 
+ok                                
+export s3-PUBLIC sub-000102/ses-baseline/pet/sub-000102_ses-baseline_pet.nii 
+ok                                   
+export s3-PUBLIC sub-000102/ses-displaced/anat/sub-000102_ses-displaced_T1w.json 
+ok                                
+export s3-PUBLIC sub-000102/ses-displaced/anat/sub-000102_ses-displaced_T1w.nii 
+ok                                
+export s3-PUBLIC sub-000102/ses-displaced/pet/sub-000102_ses-displaced_pet.json 
+ok                                
+export s3-PUBLIC sub-000102/ses-displaced/pet/sub-000102_ses-displaced_pet.nii 
+ok                                   
+export s3-PUBLIC sub-000103/ses-baseline/anat/sub-000103_ses-baseline_T1w.json 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/anat/sub-000103_ses-baseline_T1w.nii 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_pet.json 
+ok                                
+export s3-PUBLIC sub-000103/ses-baseline/pet/sub-000103_ses-baseline_pet.nii 
+ok                                  
+export s3-PUBLIC sub-000103/ses-displaced/anat/sub-000103_ses-displaced_T1w.json 
+ok                                
+export s3-PUBLIC sub-000103/ses-displaced/anat/sub-000103_ses-displaced_T1w.nii 
+ok                                
+export s3-PUBLIC sub-000103/ses-displaced/pet/sub-000103_ses-displaced_pet.json 
+ok                                
+export s3-PUBLIC sub-000103/ses-displaced/pet/sub-000103_ses-displaced_pet.nii 
+ok                                   
+export s3-PUBLIC sub-000104/ses-baseline/anat/sub-000104_ses-baseline_T1w.json 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/anat/sub-000104_ses-baseline_T1w.nii 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_pet.json 
+ok                                
+export s3-PUBLIC sub-000104/ses-baseline/pet/sub-000104_ses-baseline_pet.nii 
+ok                                   
+export s3-PUBLIC sub-000104/ses-displaced/anat/sub-000104_ses-displaced_T1w.json 
+ok                                
+export s3-PUBLIC sub-000104/ses-displaced/anat/sub-000104_ses-displaced_T1w.nii 
+ok                                
+export s3-PUBLIC sub-000104/ses-displaced/pet/sub-000104_ses-displaced_pet.json 
+ok                                
+export s3-PUBLIC sub-000104/ses-displaced/pet/sub-000104_ses-displaced_pet.nii 
+ok                                   
+export s3-PUBLIC sub-000105/ses-baseline/anat/sub-000105_ses-baseline_T1w.json 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/anat/sub-000105_ses-baseline_T1w.nii 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_pet.json 
+ok                                
+export s3-PUBLIC sub-000105/ses-baseline/pet/sub-000105_ses-baseline_pet.nii 
+ok                                   
+export s3-PUBLIC sub-000105/ses-displaced/anat/sub-000105_ses-displaced_T1w.json 
+ok                                
+export s3-PUBLIC sub-000105/ses-displaced/anat/sub-000105_ses-displaced_T1w.nii 
+ok                                
+export s3-PUBLIC sub-000105/ses-displaced/pet/sub-000105_ses-displaced_pet.json 
+ok                                
+export s3-PUBLIC sub-000105/ses-displaced/pet/sub-000105_ses-displaced_pet.nii 
+ok                                   
+(recording state in git...)
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Thank you for all your work making this wonderful tool!
+
+[[!meta title="export tree bug when two files with the same content both should be removed"]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_1_70428ebc4027538253edc483dc5cb971._comment b/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_1_70428ebc4027538253edc483dc5cb971._comment
new file mode 100644
index 0000000000..9a016f3498
--- /dev/null
+++ b/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_1_70428ebc4027538253edc483dc5cb971._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-11-09T18:16:29Z"
+ content="""
+I tried making a repository with just 2 files, one in git and one in git-annex,
+and am unable to reproduce the bug. Here is 
+what `git-annex export master --to remote --debug` showed when
+exporting a tree that deleted file "foo" which was a git object:
+
+	[2022-11-09 14:16:09.513485291] (Remote.S3) String to sign: "DELETE\n/foo\n\nhost:t-a9b9d406-30e5-41cc-a74c-c5d83b2953fb.s3.amazonaws.com\nx-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\nx-amz-date:20221109T181609Z\n\nhost;x-amz-content-sha256;x-amz-date\ne3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
+	[2022-11-09 14:16:09.513608493] (Remote.S3) Host: "t-a9b9d406-30e5-41cc-a74c-c5d83b2953fb.s3.amazonaws.com"
+	[2022-11-09 14:16:09.513697445] (Remote.S3) Path: "/foo"
+	[2022-11-09 14:16:09.513748086] (Remote.S3) Query string: ""
+	[2022-11-09 14:16:09.513829584] (Remote.S3) Header: (redacted -- JEH)
+	[2022-11-09 14:16:09.687814925] (Remote.S3) Response status: Status {statusCode = 204, statusMessage = "No Content"}
+
+The S3 console showed that the file was deleted from the bucket.
+And as far as the S3 remote implementation is concerned, there should
+not be anything different between a git object and a git-annex object.
+At the level of the S3 remote both have a git-annex key that it deletes
+in the same way.
+
+In your log, the only thing it does with the file is export it, but it does
+not later unexport it:
+
+	$ grep baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json Versioned_S3_tree_does_not_unexport_git_objects.mdwn
+	Git files in the 1.0.0 tag are still present in the S3 1.0.1 export. sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json is an example file not present in 1.0.1 that is still present on S3.
+	export s3-PUBLIC sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json 
+	$
+
+If the bug is that it's somehow failing to try to unexport the file,
+that should happen independently of the special remote type, so would also
+happen with a directory special remote. So I tried that:
+
+	$ git clone https://github.com/openneurodatasets/ds001705
+	$ cd ds001705
+	$ git-annex get --branch=tags/1.0.0
+	$ git-annex get --branch=tags/1.0.1
+	$ mkdir ../d
+	$ git-annex initremote d type=directory directory=../d encryption=none exporttree=yes
+ 	$ git-annex export 1.0.0 --to d
+	$ ls ../d/sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json
+	../d/sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json
+	$ git-annex export 1.0.1 --to d
+	$ ls ../d/sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json
+	../d/sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json
+
+Ok, so, nothing to do with S3 or versioning at all.
+"""]]
diff --git a/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_2_059b9beb31d9cbc97ea4a59f47d2e63d._comment b/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_2_059b9beb31d9cbc97ea4a59f47d2e63d._comment
new file mode 100644
index 0000000000..dae5c72f0c
--- /dev/null
+++ b/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_2_059b9beb31d9cbc97ea4a59f47d2e63d._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-11-09T19:15:59Z"
+ content="""
+Interestingly, it does not happen in simpler situations:
+
+	$ git checkout 1.0.0
+	$ git-annex export 1.0.0 --to d
+	$ git rm sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json
+	$ git commit -m removed
+	$ git-annex export HEAD --to d
+	unexport d sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json ok
+	$ ls ../d/sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json
+	ls: cannot access '../d/sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json': No such file or directory
+
+So something about the diff between 1.0.0 and 1.0.1 is somehow causing the
+bug..
+"""]]
diff --git a/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_3_176cbc137afb5cf8841ff9114b111fef._comment b/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_3_176cbc137afb5cf8841ff9114b111fef._comment
new file mode 100644
index 0000000000..0d8f4ce9e4
--- /dev/null
+++ b/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_3_176cbc137afb5cf8841ff9114b111fef._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-11-09T19:41:33Z"
+ content="""
+Ok, the bug is due to 2 files that have the same content.
+
+	sub-000101/ses-baseline/pet/sub-000101_ses-baseline_rec-MLEM_pet.json
+	sub-000101/ses-displaced/pet/sub-000101_ses-displaced_rec-MLEM_pet.json
+
+Both files get deleted. And the bug makes it only pick one of the two files
+to delete, because it's using a map from key to file and the second file
+overwrites the first in the map.
+
+So this would also presumably affect annexed files when two have the same 
+content and are being deleted.
+"""]]
diff --git a/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_4_a6490af0427bbe4363bea824d55a7593._comment b/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_4_a6490af0427bbe4363bea824d55a7593._comment
new file mode 100644
index 0000000000..18cb92cde5
--- /dev/null
+++ b/doc/bugs/Versioned_S3_tree_does_not_unexport_git_objects/comment_4_a6490af0427bbe4363bea824d55a7593._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nell@7201fe78ade251118ef3441f4e509b37cd836503"
+ nickname="nell"
+ avatar="http://cdn.libravatar.org/avatar/7d9b55f7fec5eaba6fcd3fecc65ccb7d"
+ subject="comment 4"
+ date="2022-11-09T19:51:20Z"
+ content="""
+Nice, thank you for looking into this, Joey! That makes sense why it would appear to be git files, we tend to have identical duplicate metadata files much more often than duplicate image files within datasets.
+"""]]
diff --git a/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem.mdwn b/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem.mdwn
new file mode 100644
index 0000000000..cc0bc621a0
--- /dev/null
+++ b/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem.mdwn
@@ -0,0 +1,123 @@
+### Please describe the problem.
+
+git-annex fails to add file to the repository because of permission problem (probably faulty permission handling in WSL). Interestingly, it is possible to add a file anyway, by executing `git annex add` twice. Unfortunately, files added this way are writeable, when they shouldn't.
+
+It's probably not in the scope of git-annex developing, but I think it's good to keep trace on the problem.
+
+### What steps will reproduce the problem?
+
+```
+cd /mnt/c
+git init test
+cd test
+git annex init test
+init test
+touch file
+git annex add file
+```
+
+### What version of git-annex are you using? On what operating system?
+
+Windows 10 Pro version 1909 build 18363.476 - WSL (Arch)
+
+```
+git-annex version: 7.20191114-ga95efcbc55
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.3 feed-1.2.0.1 ghc-8.6.5 http-client-0.6.4 persistent-sqlite-2.10.5 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 7
+```
+
+### Please provide any additional information below.
+
+[[!format sh """
+$ git annex init test
+init test
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+(scanning for unlocked files...)
+ok
+(recording state in git...)
+$ touch file
+$ git annex add file --debug
+[2019-11-28 11:52:53.048398] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2019-11-28 11:52:53.0570463] process done ExitSuccess
+[2019-11-28 11:52:53.0573639] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2019-11-28 11:52:53.0656397] process done ExitFailure 1
+[2019-11-28 11:52:53.0660529] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--others","--exclude-standard","-z","--","file"]
+[2019-11-28 11:52:53.0742999] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+[2019-11-28 11:52:53.0822627] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2019-11-28 11:52:53.0853736] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+add file [2019-11-28 11:52:53.0949002] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2019-11-28 11:52:53.1027361] process done ExitSuccess
+[2019-11-28 11:52:53.1030132] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2019-11-28 11:52:53.1122577] process done ExitFailure 1
+
+[2019-11-28 11:52:53.1232169] call: cp ["--reflink=auto","--preserve=timestamps",".git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855","file"]
+[2019-11-28 11:52:53.1606206] process done ExitSuccess
+
+git-annex: .git/annex/othertmp/file.0/file: rename: permission denied (Permission denied)
+failed
+[2019-11-28 11:52:53.1617248] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--modified","-z","--","file"]
+[2019-11-28 11:52:53.1693198] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--name-only","--diff-filter=T","-z","--cached","--","file"]
+[2019-11-28 11:52:53.1825925] process done ExitSuccess
+[2019-11-28 11:52:53.1835521] process done ExitSuccess
+[2019-11-28 11:52:53.1844047] process done ExitSuccess
+git-annex: add: 1 failed
+"""]]
+
+Second attempt:
+
+[[!format sh """
+$ git annex add file --debug
+[2019-11-28 11:57:56.4029726] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2019-11-28 11:57:56.4114361] process done ExitSuccess
+[2019-11-28 11:57:56.411681] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2019-11-28 11:57:56.4201317] process done ExitFailure 1
+[2019-11-28 11:57:56.420548] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--others","--exclude-standard","-z","--","file"]
+[2019-11-28 11:57:56.4316368] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+[2019-11-28 11:57:56.4416827] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2019-11-28 11:57:56.4452357] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+add file [2019-11-28 11:57:56.4545013] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2019-11-28 11:57:56.4626846] process done ExitSuccess
+[2019-11-28 11:57:56.4629866] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2019-11-28 11:57:56.4735385] process done ExitFailure 1
+
+[2019-11-28 11:57:56.4848163] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2019-11-28 11:57:56.488706] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+ok
+[2019-11-28 11:57:56.4964438] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--modified","-z","--","file"]
+[2019-11-28 11:57:56.5043041] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--name-only","--diff-filter=T","-z","--cached","--","file"]
+(recording state in git...)
+[2019-11-28 11:57:56.5152453] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"]
+[2019-11-28 11:57:56.5426207] process done ExitSuccess
+[2019-11-28 11:57:56.5438586] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]
+[2019-11-28 11:57:56.5478542] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+[2019-11-28 11:57:56.5713] process done ExitSuccess
+[2019-11-28 11:57:56.5716027] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2019-11-28 11:57:56.5803067] process done ExitSuccess
+[2019-11-28 11:57:56.5807703] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2019-11-28 11:57:56.6111405] process done ExitSuccess
+[2019-11-28 11:57:56.6115303] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","ffa5a12eba0b2ea9bc5b529278597615f70c901c","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2019-11-28 11:57:56.6269742] process done ExitSuccess
+[2019-11-28 11:57:56.6272697] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","0ece4a3a069693ea12cb61168cfb701040c8a7a7"]
+[2019-11-28 11:57:56.6465065] process done ExitSuccess
+[2019-11-28 11:57:56.6506175] process done ExitSuccess
+[2019-11-28 11:57:56.651426] process done ExitSuccess
+[2019-11-28 11:57:56.6520969] process done ExitSuccess
+[2019-11-28 11:57:56.6527282] process done ExitSuccess
+[2019-11-28 11:57:56.6536136] process done ExitSuccess
+[2019-11-28 11:57:56.6554327] process done ExitSuccess
+$ echo "this should fail" > file
+$ cat file
+this should fail
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! Thank you very much Joey for your hard work and digging into WSL bugs :)
diff --git a/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_1_6b54cc0a268885570170620222b774d7._comment b/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_1_6b54cc0a268885570170620222b774d7._comment
new file mode 100644
index 0000000000..3677a6ec55
--- /dev/null
+++ b/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_1_6b54cc0a268885570170620222b774d7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="annex2384@290036d126d86bcec28ee2f2ead549de1f59e90e"
+ nickname="annex2384"
+ avatar="http://cdn.libravatar.org/avatar/ad36fdc55abd8b9913b774fcd0177709"
+ subject="Using -o metadata?"
+ date="2020-02-04T03:22:45Z"
+ content="""
+I'm having the same issue, though I can add files if I set annex.addunlocked=true.
+"""]]
diff --git a/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_2_5634af4cef0d0fe0d2affe40d9c0d5ea._comment b/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_2_5634af4cef0d0fe0d2affe40d9c0d5ea._comment
new file mode 100644
index 0000000000..1d4dd4a59f
--- /dev/null
+++ b/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_2_5634af4cef0d0fe0d2affe40d9c0d5ea._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-10-20T17:31:07Z"
+ content="""
+These look like very similar problems:
+<https://git-annex.branchable.com/bugs/__34__rename__58___permission_denied__34__/>
+<https://git-annex.branchable.com/bugs/still_seeing_errors_with_parallel_git-annex-add/>
+"""]]
diff --git a/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_3_816bae469b0341c6dae2316050a95ad5._comment b/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_3_816bae469b0341c6dae2316050a95ad5._comment
new file mode 100644
index 0000000000..8f10a6362d
--- /dev/null
+++ b/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_3_816bae469b0341c6dae2316050a95ad5._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 3"
+ date="2021-10-26T20:13:18Z"
+ content="""
+This problem as it happens in WSL1 is due to calling `withhardlink` in `lockDown'`
+
+
+```
+lockDown' cfg file = tryNonAsync $ ifM crippledFileSystem
+	( nohardlink
+	, case hardlinkFileTmpDir cfg of
+		Nothing -> nohardlink
+		Just tmpdir -> withhardlink tmpdir
+	)
+```
+
+With `nohardlink`, the write bits are removed from the file in the working tree, moved into .git/annex/objects, a symlink is created in a temp dir and moved into the working tree. No problems here.
+
+With `withhardlink`, the write bits are removed from the file in the working tree, hardlinked into a temp dir, moved into .git/annex/objects, a symlink is created in a temp dir and moved into the working tree replacing the original file. However, Windows will not allow you to do this because when the write bits are removed, the file is set to read only and cannot be replaced in this manner. The only way to get around this is to delete the file in the working tree first.
+"""]]
diff --git a/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_4_ab64e43330e466482f30487b8bd13bbf._comment b/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_4_ab64e43330e466482f30487b8bd13bbf._comment
new file mode 100644
index 0000000000..210582f5f7
--- /dev/null
+++ b/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_4_ab64e43330e466482f30487b8bd13bbf._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-10-27T18:19:58Z"
+ content="""
+Interesting, thanks for that analysis.
+
+I don't like the prospect of adding hacks to git-annex on linux to deal
+with infelicities of WSL1. WSL should emulate linux well, and to the
+extent it does not, that seems Microsoft's problem, not mine.
+
+However, I wonder what that analysis implies about the other linked bugs
+with similar error messages, which are on OSX and (probably) Linux.
+
+What could be done to detect this drvfs problem is to add this case to the
+probing that's done for crippled filesystems. Then it would take the
+nohardlink path.
+
+But drvfs is used for /mnt/c/ etc, so that would make most all repos on WSL1 be
+treated as in a crippled filesystem, using unlocked adjusted branches, etc.
+
+Also, I seem to remember using git-annex in WSL1 in /mnt/c/ and git-annex
+add presumably working. So I wonder what has changed.
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol.mdwn b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol.mdwn
new file mode 100644
index 0000000000..52a3c2dcbf
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol.mdwn
@@ -0,0 +1,125 @@
+### Please describe the problem.
+
+I'm unable to use adjusted branches (`---unlock`) on WSL because of sqlite crashes. `smudge` tends to fail with output like:
+
+```
+sqlite worker thread crashed: user error (SQLite3 returned ErrorProtocol while attempting to perform prepare "SELECT null from content limit 1": locking protocol(while opening database connection))
+git-annex: sqlite query crashed
+CallStack (from HasCallStack):
+  error, called at ./Database/Handle.hs:98:42 in main:Database.Handle
+git-annex: smudge: 1 failed
+error: external filter 'git-annex smudge --clean -- %f' failed 1
+error: external filter 'git-annex smudge --clean -- %f' failed
+```
+
+### What steps will reproduce the problem?
+
+```
+git init test
+cd test
+git annex init test
+git annex upgrade
+echo asdf > asdf
+git annex add asdf # fails for some reason on DrvFs
+git annex add asdf # works when executed second time
+git annex sync
+git annex --debug adjust --unlock
+```
+
+
+### What version of git-annex are you using? On what operating system?
+
+Windows 10 Pro v1903 build 18362.207 - WSL (Arch)
+
+```
+git-annex version: 7.20190615-g0bd9e8c0e2
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.3 feed-1.1.0.0 ghc-8.6.5 http-client-0.6.4 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 7
+```
+
+
+### Terminal log
+
+[[!format sh """
+$ git init test
+Initialized empty Git repository in /mnt/d/debug/test/.git/
+$ cd test
+$ git annex init test
+init test
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+ok
+(recording state in git...)
+$ git annex upgrade
+upgrade (v5 to v6...) (v6 to v7...) ok
+$ echo asdf > asdf
+$ git annex add asdf
+add asdf
+git-annex: .git/annex/othertmp/asdf.0/asdf: rename: permission denied (Permission denied)
+failed
+git-annex: add: 1 failed
+zsh: exit 1     git annex add asdf
+$ git annex add asdf
+add asdf ok
+(recording state in git...)
+$ git annex sync
+commit
+[master (root-commit) 54e120b] git-annex in test
+ 1 file changed, 1 insertion(+)
+ create mode 120000 asdf
+ok
+$ git annex --debug adjust --unlock
+[2019-07-06 11:23:39.4031313] read: git ["--version"]
+[2019-07-06 11:23:39.4128108] process done ExitSuccess
+adjust [2019-07-06 11:23:39.4137008] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2019-07-06 11:23:39.4273287] process done ExitSuccess
+[2019-07-06 11:23:39.4276698] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2019-07-06 11:23:39.4436791] process done ExitSuccess
+[2019-07-06 11:23:39.4440342] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/heads/adjusted/master(unlocked)"]
+[2019-07-06 11:23:39.4571275] process done ExitFailure 1
+[2019-07-06 11:23:39.4579141] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/basis/adjusted/master(unlocked)","refs/heads/master"]
+[2019-07-06 11:23:39.4740989] process done ExitSuccess
+[2019-07-06 11:23:39.4745965] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","mktree","--batch","-z"]
+[2019-07-06 11:23:39.4770107] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-tree","--full-tree","-z","-r","-t","--","refs/basis/adjusted/master(unlocked)"]
+[2019-07-06 11:23:39.4940556] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2019-07-06 11:23:39.4960848] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2019-07-06 11:23:39.5412121] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","diff.external=","-c","filter.annex.smudge=","-c","filter.annex.clean=","diff","--cached","--raw","-z","--abbrev=40","-G^/annex/objects/","--diff-filter=AMUT","--no-renames","--ignore-submodules=all","--no-ext-diff"]
+[2019-07-06 11:23:39.5743181] process done ExitSuccess
+[2019-07-06 11:23:39.5754474] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]
+[2019-07-06 11:23:39.5981937] process done ExitSuccess
+[2019-07-06 11:23:39.5990927] process done ExitSuccess
+[2019-07-06 11:23:39.6010222] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","69b3149d64ac2eb225c6f5336fa15c518dcd4d83","--no-gpg-sign","-p","refs/basis/adjusted/master(unlocked)"]
+[2019-07-06 11:23:39.6194551] process done ExitSuccess
+[2019-07-06 11:23:39.6199068] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","-m","entering adjusted branch","refs/heads/adjusted/master(unlocked)","c4e772ae22f9b1146b798404d85268ea3ca40e03"]
+[2019-07-06 11:23:39.6402592] process done ExitSuccess
+
+[2019-07-06 11:23:39.6409432] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","checkout","adjusted/master(unlocked)","--progress"]
+sqlite worker thread crashed: user error (SQLite3 returned ErrorProtocol while attempting to perform prepare "SELECT null from content limit 1": locking protocol(while opening database connection))
+git-annex: thread blocked indefinitely in an MVar operation
+error: external filter 'git-annex smudge -- %f' failed 1
+error: external filter 'git-annex smudge -- %f' failed
+Switched to branch 'adjusted/master(unlocked)'
+sqlite worker thread crashed: user error (SQLite3 returned ErrorProtocol while attempting to perform prepare "SELECT null from content limit 1": locking protocol(while opening database connection))
+git-annex: sqlite query crashed
+CallStack (from HasCallStack):
+  error, called at ./Database/Handle.hs:98:42 in main:Database.Handle
+git-annex: smudge: 1 failed
+error: external filter 'git-annex smudge --clean -- %f' failed 1
+error: external filter 'git-annex smudge --clean -- %f' failed
+[2019-07-06 11:24:03.3626765] process done ExitSuccess
+ok
+[2019-07-06 11:24:03.372672] process done ExitSuccess
+[2019-07-06 11:24:03.3742067] process done ExitSuccess
+[2019-07-06 11:24:03.3756292] process done ExitSuccess
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Yes, on macOS & HFS+ :)
+
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_10_93c9d3ea6d7a1f2d035f8a52c81790ad._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_10_93c9d3ea6d7a1f2d035f8a52c81790ad._comment
new file mode 100644
index 0000000000..15b06ccc7f
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_10_93c9d3ea6d7a1f2d035f8a52c81790ad._comment
@@ -0,0 +1,71 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 10"
+ date="2021-10-20T22:54:39Z"
+ content="""
+The error I get previously (before [[!commit 0f38ad9a6]]) with my test case is
+
+```
+init
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+ok
+(recording state in git...)
+get a (from origin...)
+ok
+get b (from origin...)
+ok
+(recording state in git...)
+sqlite worker thread crashed: user error (SQLite3 returned ErrorProtocol while attempting to perform prepare \"SELECT null from content limit 1\": locking protocol(while opening database connection))
+git-annex: sqlite query crashed: thread blocked indefinitely in an MVar operation
+CallStack (from HasCallStack):
+  error, called at ./Database/Handle.hs:102:40 in main:Database.Handle
+error: external filter 'git-annex smudge --clean -- %f' failed 1
+error: external filter 'git-annex smudge --clean -- %f' failed
+sqlite worker thread crashed: user error (SQLite3 returned ErrorProtocol while attempting to perform prepare \"SELECT null from content limit 1\": locking protocol(while opening database connection))
+git-annex: sqlite query crashed: thread blocked indefinitely in an MVar operation
+CallStack (from HasCallStack):
+  error, called at ./Database/Handle.hs:102:40 in main:Database.Handle
+error: external filter 'git-annex smudge --clean -- %f' failed 1
+error: external filter 'git-annex smudge --clean -- %f' failed
+```
+
+With [[!commit d0ef8303c]], the test case still works, but adjusted branches still have the same error. 
+
+```
+git init
+git annex init
+git config annex.crippledfilesystem true
+echo aaa > a
+cp a b
+git annex add .
+git commit -m .
+git annex adjust --unlock
+```
+
+produces
+
+```
+adjust
+sqlite worker thread crashed: user error (SQLite3 returned ErrorProtocol while attempting to perform prepare \"SELECT null from content limit 1\": locking protocol(while opening database connection))
+git-annex: thread blocked indefinitely in an MVar operation
+error: external filter 'git-annex smudge -- %f' failed 1
+error: external filter 'git-annex smudge -- %f' failed
+sqlite worker thread crashed: user error (SQLite3 returned ErrorProtocol while attempting to perform prepare \"SELECT null from content limit 1\": locking protocol(while opening database connection))
+git-annex: thread blocked indefinitely in an MVar operation
+error: external filter 'git-annex smudge -- %f' failed 1
+error: external filter 'git-annex smudge -- %f' failed
+Switched to branch 'adjusted/master(unlocked)'
+sqlite worker thread crashed: user error (SQLite3 returned ErrorProtocol while attempting to perform prepare \"SELECT null from content limit 1\": locking protocol(while opening database connection))
+git-annex: sqlite query crashed: thread blocked indefinitely in an MVar operation
+CallStack (from HasCallStack):
+  error, called at ./Database/Handle.hs:79:40 in main:Database.Handle
+failed
+adjust: 1 failed
+```
+
+About `git-annex version`, I'm using `make install-home` to do an incremental build but the version does not update.
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_11_94d00ed84dfebebd7889fa861172df61._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_11_94d00ed84dfebebd7889fa861172df61._comment
new file mode 100644
index 0000000000..b01e115845
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_11_94d00ed84dfebebd7889fa861172df61._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 11"
+ date="2021-10-21T02:06:50Z"
+ content="""
+I found a new type of failure which occurs when there are new unlocked files in the index.
+
+```
+git init
+git annex init
+git config annex.crippledfilesystem true
+git config annex.addunlocked true
+touch a
+git annex add . # OK
+touch b
+git annex add . # 1 error
+touch c
+git annex add . # 2 errors
+```
+
+Something is happening to the files already in the index and the error is triggered once per file in the index.
+
+```
+add c
+ok
+sqlite worker thread crashed: user error (SQLite3 returned ErrorProtocol while attempting to perform prepare \"SELECT null from content limit 1\": locking protocol(while opening database connection))
+git-annex: sqlite query crashed: thread blocked indefinitely in an MVar operation
+CallStack (from HasCallStack):
+  error, called at ./Database/Handle.hs:102:40 in main:Database.Handle
+error: external filter 'git-annex smudge --clean -- %f' failed 1
+error: external filter 'git-annex smudge --clean -- %f' failed
+add a
+ok
+sqlite worker thread crashed: user error (SQLite3 returned ErrorProtocol while attempting to perform prepare \"SELECT null from content limit 1\": locking protocol(while opening database connection))
+git-annex: sqlite query crashed: thread blocked indefinitely in an MVar operation
+CallStack (from HasCallStack):
+  error, called at ./Database/Handle.hs:102:40 in main:Database.Handle
+error: external filter 'git-annex smudge --clean -- %f' failed 1
+error: external filter 'git-annex smudge --clean -- %f' failed
+add b
+ok
+(recording state in git...)
+```
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_12_76f765e3befd5e263a8863b56cad139b._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_12_76f765e3befd5e263a8863b56cad139b._comment
new file mode 100644
index 0000000000..adaae56df5
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_12_76f765e3befd5e263a8863b56cad139b._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 12"
+ date="2021-10-21T02:09:02Z"
+ content="""
+Forgot to add in the previous comment. The index looks fine afterwards
+
+```
+On branch master
+
+No commits yet
+
+Changes to be committed:
+  (use \"git rm --cached <file>...\" to unstage)
+        new file:   a
+        new file:   b
+        new file:   c
+```
+
+```
+diff --git a/a b/a
+new file mode 100755
+index 0000000..f8e47b9
+--- /dev/null
++++ b/a
+@@ -0,0 +1 @@
++/annex/objects/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+diff --git a/b b/b
+new file mode 100755
+index 0000000..f8e47b9
+--- /dev/null
++++ b/b
+@@ -0,0 +1 @@
++/annex/objects/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+diff --git a/c b/c
+new file mode 100755
+index 0000000..f8e47b9
+--- /dev/null
++++ b/c
+@@ -0,0 +1 @@
++/annex/objects/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+```
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_13_5e08dcb7e40e7fbcb22425b3ff8b0610._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_13_5e08dcb7e40e7fbcb22425b3ff8b0610._comment
new file mode 100644
index 0000000000..925b99e6f7
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_13_5e08dcb7e40e7fbcb22425b3ff8b0610._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2021-11-02T19:20:23Z"
+ content="""
+@asakurareiko could you try this patch, and see if it
+fixes some/all of the remaining problems?
+
+	diff --git a/Database/Handle.hs b/Database/Handle.hs
+	index 9eb32b4e2..828c26df4 100644
+	--- a/Database/Handle.hs
+	+++ b/Database/Handle.hs
+	@@ -187,7 +187,7 @@ runSqliteRobustly tablename db a = do
+	 					-- will stop being busy eventually.
+	 					briefdelay
+	 					settle conn retries
+	-				| e == Sqlite.ErrorIO -> do
+	+				| e == Sqlite.ErrorIO || e == Sqlite.ErrorProtocol -> do
+ 						-- Could be a real IO error,
+ 						-- so don't retry indefinitely.
+	 					Sqlite.close conn
+
+If that doesn't work, it's possible this version might somehow work better.
+At least it would be worth a try as well:
+
+	diff --git a/Database/Handle.hs b/Database/Handle.hs
+	index 9eb32b4e2..e146ba675 100644
+	--- a/Database/Handle.hs
+	+++ b/Database/Handle.hs
+	@@ -182,7 +182,7 @@ runSqliteRobustly tablename db a = do
+	 		case r of
+ 				Right _ -> return conn
+	 			Left ex@(Sqlite.SqliteException { Sqlite.seError = e })
+	-				| e == Sqlite.ErrorBusy -> do
+	+				| e == Sqlite.ErrorBusy || e == Sqlite.ErrorProtocol-> do
+	 					-- Wait and retry any number of times; it 
+ 						-- will stop being busy eventually.
+	 					briefdelay
+
+This second one might cause git-annex to get stuck and retry forever though,
+if it doesn't work.
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_14_45b1da34ec60d6322477edfd6a3a2bba._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_14_45b1da34ec60d6322477edfd6a3a2bba._comment
new file mode 100644
index 0000000000..0d14328489
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_14_45b1da34ec60d6322477edfd6a3a2bba._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 14"
+ date="2022-09-25T19:43:31Z"
+ content="""
+Either of these changes causes the test case in comment 11 to hang indefinitely. Probably no way to fix these issues in general due to [[sqlite write locks aren't respected in WSL|https://github.com/microsoft/WSL/issues/2395]], but as things are currently everything works well enough.
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_1_0bcbce94586ef96c2dcbe5ef9da4ac6f._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_1_0bcbce94586ef96c2dcbe5ef9da4ac6f._comment
new file mode 100644
index 0000000000..6efeab13d7
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_1_0bcbce94586ef96c2dcbe5ef9da4ac6f._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-07-19T17:16:37Z"
+ content="""
+I have seen several sqlite-related problems in WSL, they seem to come and
+go for me.
+
+I guess this is WSL not emulating Linux very well and so breaking sqlite.
+There is not much that git-annex can do about it.
+
+(Here's stack having to work around a similar problem 
+https://github.com/commercialhaskell/stack/issues/4876 and the error
+message looks very similar. But git-annex
+cannot afford to disable WAL mode as that would break concurrent operation.)
+
+I hear they've given up on emulating Linux syscalls and the next version of
+WSL will just use the Linux kernel. Which should avoid this problem.
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_2_bdb3cadf29facd4729120a6cd057b8a8._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_2_bdb3cadf29facd4729120a6cd057b8a8._comment
new file mode 100644
index 0000000000..3650331303
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_2_bdb3cadf29facd4729120a6cd057b8a8._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-08-27T19:05:02Z"
+ content="""
+I reproduced with git-annex from debian stable on WSL in MS Edge preview
+fall 2019. Also with a current git-annex autobuild.
+
+Interestingly, using v7 with unlocked files not in an adjusted branch
+seems to work ok. Which seems to indicate that sqlite is generally working.
+
+May be somehow caused by there being 2 git-annex processes running when it
+fails. They could be contending over the database in some way that
+works less well in WSL.
+
+Backing up that theory, .git/annex/keys/db does get created and is
+populated with the right tables and data.
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_3_2a9f0396df93d9500306b3d7039803a2._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_3_2a9f0396df93d9500306b3d7039803a2._comment
new file mode 100644
index 0000000000..fb1206a7d1
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_3_2a9f0396df93d9500306b3d7039803a2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ply"
+ avatar="http://cdn.libravatar.org/avatar/1270501a59ed4a4042366b00295fe236"
+ subject="comment 3"
+ date="2019-11-28T11:18:50Z"
+ content="""
+Thanks Joey for investigating this! It looks like I need to wait for WSL 2 to become available in windows public release. In the meantime I've submitted a bug on [faulty behaviour of `git annex add` on DrvFs](https://git-annex.branchable.com/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/). I don't think you can fix it, as it is apparantly a WSL problem, but I think it's good to keep track of it and warn potential users
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_4_da42c839f96314ed8c5ad646b614b75d._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_4_da42c839f96314ed8c5ad646b614b75d._comment
new file mode 100644
index 0000000000..c18924e995
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_4_da42c839f96314ed8c5ad646b614b75d._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-10-09T23:43:47Z"
+ content="""
+I tried using Windows 10 build 19041 from 
+<https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/>
+That is new enough to support WSL2.
+
+At first, this bug reproduced. Turns out that still has WSL1 by default.
+<https://docs.microsoft.com/en-us/windows/wsl/install-win10> explains how
+to enable WSL2.
+
+Unfortunately, those instructions failed at the final hurdle, 
+`wsl --set-version Ubuntu 2` said Virtual Machine Platform needed to be
+enabled, or virtualization enabled in the BIOS. I had already done the
+former in an earlier step, so I guess VirtualBox is not enabling it in the
+BIOS. 
+
+Probably it needs nested VT-x. VirtualBox has that option greyed out
+for me. 
+<https://github.com/microsoft/WSL/issues/5030> says this needs virtualbox
+to use Hyper-V, which needs a fix that landed 2 weeks ago, not yet in a
+released version. Or use another emulator, or maybe try it on real
+hardware?
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_5_f8ee3d06a79bdc429a114b5256290206._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_5_f8ee3d06a79bdc429a114b5256290206._comment
new file mode 100644
index 0000000000..aa6ace7e17
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_5_f8ee3d06a79bdc429a114b5256290206._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 5"
+ date="2021-10-17T01:14:18Z"
+ content="""
+Since WSL2 has terrible performance with the NTFS volumes already mounted in Windows, consumes more memory, and has higher hardware requirements, I'm still interested in using WSL1. I applied the patch to disable WAL from [this comment](http://git-annex.branchable.com/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/#comment-46e7f3e4052eec268ae72ead4afc3cea), however now I get a different sqlite error that happens more often as well.
+
+```
+  failed to commit changes to sqlite database: Just user error (SQLite3 returned ErrorBusy while attempting to perform step: database is locked(after successful open))
+  CallStack (from HasCallStack):
+    error, called at ./Database/Handle.hs:116:26 in main:Database.Handle
+```
+
+Without this patch other than adjusted branches, unlocked files generally do work in WSL1. Sqlite error may occur at the end of commands such as `git annex get/drop` and can be fixed by manually removing .git/index.lock and doing a `git annex add` or `git reset`.
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_6_b7a3837fd6af236e9ecf6d5bae077fd0._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_6_b7a3837fd6af236e9ecf6d5bae077fd0._comment
new file mode 100644
index 0000000000..5f46a0be3c
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_6_b7a3837fd6af236e9ecf6d5bae077fd0._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-10-19T16:44:13Z"
+ content="""
+@asakurareiko it makes sense it would fail that way with WAL disabled,
+since the sqlite database cannot support multiple writers then. And
+there are probably several situations where multiple git-annex processes
+end up using the database, even when you are only running a single
+git-annex command at a time.
+
+> Without this patch other than adjusted branches, unlocked files generally do
+> work in WSL1. Sqlite error may occur at the end of commands such as `git annex get/drop`
+
+Sounds like `restagePointerFile`, which tends to run at the
+end of such an operation to handle all the files that have been updated. 
+That runs `git update-index`, which then runs `git-annex smudge`.
+So both the parent and child git-annex process can have the database open
+for write, which WAL mode normally supports, but something in WSL prevents
+it from working right.
+
+Following this theory, I've made `restagePointerFile` close the database
+first. Perhaps that will avoid the problem, at least in those cases. Your
+testing is appreciated.
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_7_276be047d18b2e20a8e3114abe3132ee._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_7_276be047d18b2e20a8e3114abe3132ee._comment
new file mode 100644
index 0000000000..0a267591d8
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_7_276be047d18b2e20a8e3114abe3132ee._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 7"
+ date="2021-10-20T14:42:33Z"
+ content="""
+I tested 0f38ad9a6 with the test case below as well as with the repo I use and sqlite errors no longer occur. Adjusted branches still do not work but everything else with unlocked files seems to be ok now. Thank you Joey.
+
+Setup:
+
+```
+# on NTFS volume mounted with metadata option
+git init annex
+cd annex
+git annex init
+git config annex.addunlocked true
+git config annex.crippledfilesystem true
+echo aaa > a
+cp a b
+git annex add .
+git commit -m .
+```
+
+Test:
+
+```
+git clone annex annex2
+cd annex2
+git annex init
+git config annex.crippledfilesystem true
+git annex get .
+```
+
+
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_8_cb7ce88ae3d77b9ba0a4e33c2321a3e1._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_8_cb7ce88ae3d77b9ba0a4e33c2321a3e1._comment
new file mode 100644
index 0000000000..6368239641
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_8_cb7ce88ae3d77b9ba0a4e33c2321a3e1._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2021-10-20T17:04:09Z"
+ content="""
+@asakurareiko oh that's encouraging that I seem to be on the right track.
+
+Although I was not aware that this test case in your comment #8 failed
+before?
+
+I noticed that git-annex opened a second connection to the database for
+writes, in addition to the connection it used for reads. That seems likely
+to be involved in whatever locking problem there is on WSL.
+
+Commit [[!commit d0ef8303cf8c4f40a1d17bd134af961fd9917ca4]] eliminates that
+second connection. But there's some chance I'll have to revert it.
+
+If you test, please include `git-annex version` output
+so I can make sure you have a version with that change.
+"""]]
diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_9_b0700fdf101f6cc883857b293cd35267._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_9_b0700fdf101f6cc883857b293cd35267._comment
new file mode 100644
index 0000000000..3761132d4b
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_9_b0700fdf101f6cc883857b293cd35267._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-10-20T17:15:27Z"
+ content="""
+The crash shows that runSqliteRobustly called `rethrow "while opening
+database connection"`, and I think it was in the "| otherwise" branch
+because the error is not Sqlite.ErrorIO.
+
+So, it may also possibly help to handle Sqlite.ErrorProtocol,
+which seems like what the actual error is from the message.
+Handling it the same as Sqlite.ErrorBusy would make opening the db
+be retried until whatever else had it open closes it, or finishes
+the operation that is causing the problem. On the other hand, 
+that might make git-annex hang until another git-annex process exits,
+which would not be helpful. So perhaps it would be better to handle it
+like Sqlite.ErrorIO is handled, waiting for up to 1/10th of a second.
+But perhaps that would not be enough of a wait.
+
+Anyway, this is a note to myself: If all else fails,
+try catching Sqlite.ErrorProtocol and experiment
+with different ways to handle it.
+"""]]
diff --git a/doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist.mdwn b/doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist.mdwn
new file mode 100644
index 0000000000..347f8b3d5e
--- /dev/null
+++ b/doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist.mdwn
@@ -0,0 +1,10 @@
+### Please describe the problem.
+
+On windows 7 under assistant/webapp, we have the following message displayed :
+
+warning
+Watcher crashed: .git\annex\objects\56b\ff2\SHA256E-s298110--0ff71fda9236dbf84954969add770bfbf90c800916450823335a1bd6c6229a5e.pdf\: openTempFile: does not exist (No such file or directory)
+
+git annex fsck indeed complains that several such files are missing.
+
+Hope this helps.
diff --git a/doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist/comment_1_9892f6b80597f0b637aeb96d212164d9._comment b/doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist/comment_1_9892f6b80597f0b637aeb96d212164d9._comment
new file mode 100644
index 0000000000..a4715c7937
--- /dev/null
+++ b/doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist/comment_1_9892f6b80597f0b637aeb96d212164d9._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="OlivierBerger"
+ subject="More details"
+ date="2015-11-09T14:52:24Z"
+ content="""
+AFAIU, this happened when we moved a lot of files at once, trying to dispatch files into subdirs, in direct mode. Hope this helps
+"""]]
diff --git a/doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist/comment_2_687a9fd1c0b760dd2bef9647cd16175c._comment b/doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist/comment_2_687a9fd1c0b760dd2bef9647cd16175c._comment
new file mode 100644
index 0000000000..23ea64bd31
--- /dev/null
+++ b/doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist/comment_2_687a9fd1c0b760dd2bef9647cd16175c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-12-02T17:32:32Z"
+ content="""
+What version of git-annex?
+
+Is it possible that the .git/annex/objects directory,
+or something related to it (maybe .git itself) is one of the 
+files you moved?
+"""]]
diff --git a/doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist/comment_3_1ef917c10f944e6c874aa40affae7602._comment b/doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist/comment_3_1ef917c10f944e6c874aa40affae7602._comment
new file mode 100644
index 0000000000..9830d3dce7
--- /dev/null
+++ b/doc/bugs/Watcher_crashed__58___.git__92__annex__92__objects__92__...sha256....pdf__92____58___openTempFile__58___does_not_exist/comment_3_1ef917c10f944e6c874aa40affae7602._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="OlivierBerger"
+ subject="Difficult to tell"
+ date="2015-12-04T10:21:26Z"
+ content="""
+Sorry, Joey, but I don't have the details of the version which crahed on us, and we updated afterwards : no time to try and reproduce fully : really busy producing videos, and anxious to find a solution on backing up videos reliably (which by the way I solved like this : https://www-public.tem-tsp.eu/~berger_o/weblog/2015/11/26/handling-video-files-produced-for-a-mooc-on-windows-with-git-and-git-annex/).
+
+I don't see however how we could have touched the contents of the .git/ : we were only doing Windows explorer actions : dragging files here and there, renaming dirs, saving stuff in Camtasia, but all inside subdirs of the git clone.
+
+Sorry for the poor quality of the report, but we were in a real hurry and had to find solutions without distracting us from the main topic : video editing :-/
+"""]]
diff --git a/doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__.mdwn b/doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__.mdwn
new file mode 100644
index 0000000000..270a69ecb2
--- /dev/null
+++ b/doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+
+In webapp UI, added on first install, the location for repository: /storage/sdcard1
+
+!warning
+
+Watcher crashed: addWatch:
+
+permission denied (Permission denied)
+
+[Restart Thread]
+
+:Performing startup scan
+
+In terminal Window 1:
+
+nex webapp <
+
+Detected a crippled filesystem.
+
+Enabling direct mode.
+
+Detected a filesystem without fifo support.
+
+Disabling ssh connection caching.
+
+### What steps will reproduce the problem?
+
+In webapp UI, added on first install, the location for repository: /storage/sdcard1
+
+### What version of git-annex are you using? On what operating system?
+
+Android 4.1.1 Huawei Y300 Annex.apk v1.0.52 version 4.20130723
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__/comment_1_71b052be40fbdaca09ca3ede8c59ac7a._comment b/doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__/comment_1_71b052be40fbdaca09ca3ede8c59ac7a._comment
new file mode 100644
index 0000000000..0622a24391
--- /dev/null
+++ b/doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__/comment_1_71b052be40fbdaca09ca3ede8c59ac7a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 1"
+ date="2013-07-30T18:42:32Z"
+ content="""
+You should have a `/storage/sdcard1/.git/annex/daemon.log` file. Please paste it here.
+"""]]
diff --git a/doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__/comment_3_0f7cc02e0193c969c9b6ceb27e71af8a._comment b/doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__/comment_3_0f7cc02e0193c969c9b6ceb27e71af8a._comment
new file mode 100644
index 0000000000..0ea47dc402
--- /dev/null
+++ b/doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__/comment_3_0f7cc02e0193c969c9b6ceb27e71af8a._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="/storage/sdcard1/.git/annex/daemon.log"
+ date="2013-07-30T23:11:29Z"
+ content="""
+    [2013-07-30 23:17:43 BST] main: starting assistant version 4.20130723-ged05a63
+    (scanning...) [2013-07-30 23:17:44 BST] Watcher: Performing startup scan
+    Watcher crashed: addWatch: permission denied (Permission denied)
+    [2013-07-30 23:17:45 BST] Watcher: warning Watcher crashed: addWatch: permission denied (Permission denied)
+    [2013-07-30 23:17:45 BST] Committer: Adding 229286 229381
+    add LOST.DIR/229286 (checksum...) ok
+    add LOST.DIR/229381 (checksum...) [2013-07-30 23:17:47 BST] Committer: Committing changes to git
+    [2013-07-30 23:20:22 BST] Committer: Adding git-annex..stall.log
+    ok
+    (Recording state in git...)
+    (Recording state in git...)
+    add git-annex-install.log (checksum...) ok
+    add git-annex-install.log (checksum...) [2013-07-30 23:20:22 BST] Committer: Committing changes to git
+"""]]
diff --git a/doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__/comment_3_1a7542249b9c37507126e97441057c12._comment b/doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__/comment_3_1a7542249b9c37507126e97441057c12._comment
new file mode 100644
index 0000000000..9bc0c90e64
--- /dev/null
+++ b/doc/bugs/Watcher_crashed_in_Android_on___47__storage__47__sdcard1_-_bug__63__/comment_3_1a7542249b9c37507126e97441057c12._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 3"
+ date="2013-11-10T18:18:09Z"
+ content="""
+Seems to me this was probably fixed in [[!commit 6b37fcffd872b62fb78047a77e4cee5ab0bb57f1]].
+
+However, I don't know why permission problems would happen on Android, which typically uses a filesystem that does not have restricted permissions for the sdcard.
+
+If you upgrade, you should be able to see if it fixed the crash, and it will also mention any file or directory that it's unable to read in the log.
+"""]]
diff --git a/doc/bugs/Webapp_won__180__t_start_on_MacOS.mdwn b/doc/bugs/Webapp_won__180__t_start_on_MacOS.mdwn
new file mode 100644
index 0000000000..1210fd1c96
--- /dev/null
+++ b/doc/bugs/Webapp_won__180__t_start_on_MacOS.mdwn
@@ -0,0 +1,315 @@
+### Please describe the problem.
+
+After an update the webapp won´t start. git-annex itself works just fine :)
+It doesn´t even try to open the browser. It seems like the command isn't recognised.
+(Invalid argument `webapp')
+
+### What steps will reproduce the problem?
+
+git annex webapp
+
+
+### What version of git-annex are you using? On what operating system?
+
+I just updated to version 10.20220822 via homebrew on MacOS 12.5.1 (Monterey)
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+(scanning...) remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+ControlSocket .git/annex/ssh/git@gitlab.com already exists, disabling multiplexing
+To ssh://git-annex-Backupserver.fritz.box-Florian_22_.2Fsrv.2Fmergerfs.2FPOOL01.2FBackupFlosSoundPodcast.2F/srv/mergerfs/POOL01/BackupFlosSoundPodcast/
+   d865495..82b25c1  git-annex -> synced/git-annex
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+To gitlab.com:gitannex1/FlosSoundPodcast.git
+   d865495..82b25c1  git-annex -> synced/git-annex
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+(started...) 
+(recording state in git...)
+git-annex filter-process: git-annex: command not found
+fatal: the remote end hung up unexpectedly
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+ControlSocket .git/annex/ssh/24d7fc76050b5b840322d70167a1797d already exists, disabling multiplexing
+ControlSocket .git/annex/ssh/24d7fc76050b5b840322d70167a1797d already exists, disabling multiplexing
+fatal: Unable to create '/Users/Florian/FlosSoundPodcast/.git/index.lock': File exists.
+
+Another git process seems to be running in this repository, e.g.
+an editor opened by 'git commit'. Please make sure all processes
+are terminated then try again. If it still fails, a git process
+may have crashed in this repository earlier:
+remove the file manually to continue.
+
+  user error (xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--force","--"] exited 1)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+To ssh://git-annex-Backupserver.fritz.box-Florian_22_.2Fsrv.2Fmergerfs.2FPOOL01.2FBackupFlosSoundPodcast.2F/srv/mergerfs/POOL01/BackupFlosSoundPodcast/
+   82b25c1..21d448b  git-annex -> synced/git-annex
+   0856a3e..961a904  master -> synced/master
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+remote: 
+remote: To create a merge request for synced/master, visit:        
+remote:   https://gitlab.com/gitannex1/FlosSoundPodcast/-/merge_requests/new?merge_request%5Bsource_branch%5D=synced%2Fmaster        
+remote: 
+To gitlab.com:gitannex1/FlosSoundPodcast.git
+   82b25c1..21d448b  git-annex -> synced/git-annex
+   0856a3e..961a904  master -> synced/master
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+fatal: Unable to create '.git/index.lock': .git/index.lock: openFd: already exists (File exists)
+
+If no other git process is currently running, this probably means a
+git process crashed in this repository earlier. Make sure no other git
+process is running and remove the file manually to continue.
+
+Committer crashed: .git/index.lock: openFd: already exists (File exists)
+(recording state in git...)
+(recovering from race...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+(recording state in git...)
+remote: error: cannot lock ref 'refs/heads/synced/git-annex': Unable to create '/home/florian/FlosSoundPodcast/.git/./refs/heads/synced/git-annex.lock': File exists.        
+remote: 
+remote: Another git process seems to be running in this repository, e.g.        
+remote: an editor opened by 'git commit'. Please make sure all processes        
+remote: are terminated then try again. If it still fails, a git process        
+remote: may have crashed in this repository earlier:        
+remote: remove the file manually to continue.        
+(recording state in git...)
+To ssh://git-annex-SonyVaioLaptop.local-florian_22_FlosSoundPodcast/~/FlosSoundPodcast/
+ ! [remote rejected] git-annex -> synced/git-annex (failed to update ref)
+error: failed to push some refs to 'ssh://git-annex-SonyVaioLaptop.local-florian_22_FlosSoundPodcast/~/FlosSoundPodcast/'
+(recording state in git...)
+(recovering from race...)
+To ssh://git-annex-SonyVaioLaptop.local-florian_22_FlosSoundPodcast/~/FlosSoundPodcast/
+   045d2fb..21d448b  git-annex -> synced/git-annex
+   0856a3e..961a904  master -> synced/master
+To ssh://git-annex-SonyVaioLaptop.local-florian_22_FlosSoundPodcast/~/FlosSoundPodcast/
+   21d448b..9aec50f  git-annex -> synced/git-annex
+Everything up-to-date
+To ssh://git-annex-Backupserver.fritz.box-Florian_22_.2Fsrv.2Fmergerfs.2FPOOL01.2FBackupFlosSoundPodcast.2F/srv/mergerfs/POOL01/BackupFlosSoundPodcast/
+   21d448b..9aec50f  git-annex -> synced/git-annex
+To gitlab.com:gitannex1/FlosSoundPodcast.git
+   21d448b..9aec50f  git-annex -> synced/git-annex
+To ssh://git-annex-Backupserver.fritz.box-Florian_22_.2Fsrv.2Fmergerfs.2FPOOL01.2FBackupFlosSoundPodcast.2F/srv/mergerfs/POOL01/BackupFlosSoundPodcast/
+   961a904..f1e3307  master -> synced/master
+To ssh://git-annex-SonyVaioLaptop.local-florian_22_FlosSoundPodcast/~/FlosSoundPodcast/
+   961a904..f1e3307  master -> synced/master
+remote: error: cannot lock ref 'refs/heads/synced/master': is at f1e33074064f9c0055c9e1d7e629745136907957 but expected 961a904a20dbc6b246539f295129b1f5cc56cf08        
+To gitlab.com:gitannex1/FlosSoundPodcast.git
+ ! [remote rejected] master -> synced/master (failed to update ref)
+error: failed to push some refs to 'gitlab.com:gitannex1/FlosSoundPodcast.git'
+Everything up-to-date
+Everything up-to-date
+Everything up-to-date
+Everything up-to-date
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+To ssh://git-annex-SonyVaioLaptop.local-florian_22_FlosSoundPodcast/~/FlosSoundPodcast/
+   9aec50f..04bec1d  git-annex -> synced/git-annex
+To ssh://git-annex-Backupserver.fritz.box-Florian_22_.2Fsrv.2Fmergerfs.2FPOOL01.2FBackupFlosSoundPodcast.2F/srv/mergerfs/POOL01/BackupFlosSoundPodcast/
+   9aec50f..04bec1d  git-annex -> synced/git-annex
+To gitlab.com:gitannex1/FlosSoundPodcast.git
+   9aec50f..04bec1d  git-annex -> synced/git-annex
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+Everything up-to-date
+Everything up-to-date
+Everything up-to-date
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+From ssh://git-annex-SonyVaioLaptop.local-florian_22_FlosSoundPodcast/~/FlosSoundPodcast
+   04bec1d..bdfba09  git-annex  -> SonyVaioLaptop/git-annex
+   0856a3e..f1e3307  master     -> SonyVaioLaptop/master
+From ssh://git-annex-SonyVaioLaptop.local-florian_22_FlosSoundPodcast/~/FlosSoundPodcast
+   bdfba09..45d1d71  git-annex  -> SonyVaioLaptop/git-annex
+(merging SonyVaioLaptop/git-annex into git-annex...)
+Everything up-to-date
+To ssh://git-annex-SonyVaioLaptop.local-florian_22_FlosSoundPodcast/~/FlosSoundPodcast/
+   04bec1d..45d1d71  git-annex -> synced/git-annex
+Everything up-to-date
+Everything up-to-date
+Everything up-to-date
+Everything up-to-date
+Everything up-to-date
+Everything up-to-date
+Everything up-to-date
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+Everything up-to-date
+Everything up-to-date
+Everything up-to-date
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+Everything up-to-date
+Everything up-to-date
+Everything up-to-date
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+Everything up-to-date
+Everything up-to-date
+Everything up-to-date
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+(recording state in git...)
+git-annex-shell: <stdin>: hGetChar: end of file
+git-annex-shell: <stdin>: hGetChar: end of file
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I had tons of luck using git-annex. I am a non-programmer person and I could easily get the hang of it. At the moment I am using it for my podcast production.
+I can cut and export now from every available computer in my home. I have a central server on my LAN and git-annex also helps me to back up every episode.
+My next goal is to use it for my personal documents like scans of invoices, letter and so on. I think an archive repo will help me with this. So I can have all the stuff in one big folder.
+Thanks for inventing such a nice tool
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_1_0a8b46efd3f6b7c9f818fc64af9a5f4f._comment b/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_1_0a8b46efd3f6b7c9f818fc64af9a5f4f._comment
new file mode 100644
index 0000000000..ef74d474f7
--- /dev/null
+++ b/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_1_0a8b46efd3f6b7c9f818fc64af9a5f4f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 1"
+ date="2022-08-25T16:18:38Z"
+ content="""
+First of all, look for and stop background git processes that are holding `/Users/Florian/FlosSoundPodcast/.git/index.lock`. Easiest way would be a restart. If the file persists a reboot, remove it.
+
+Next you should set `remote.<name>.annex-ignore` on the gitlab remote because gitlab does not support git-annex.
+
+What do the logs say after you've done that?
+"""]]
diff --git a/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_2_7eb9cf2b8c7192ae654831cdc0c00253._comment b/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_2_7eb9cf2b8c7192ae654831cdc0c00253._comment
new file mode 100644
index 0000000000..e9c02d5ec2
--- /dev/null
+++ b/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_2_7eb9cf2b8c7192ae654831cdc0c00253._comment
@@ -0,0 +1,283 @@
+[[!comment format=mdwn
+ username="hoegiflo@befdf51af27be5af346451fe32863dadb1d37ad5"
+ nickname="hoegiflo"
+ avatar="http://cdn.libravatar.org/avatar/4ebf46d26c5a42c69b022f8793295991"
+ subject="comment 2"
+ date="2022-08-27T21:00:48Z"
+ content="""
+Hey, thanks a lot. I set:
+git config remote.origin.annex-ignore true
+
+And I deleted the lock file. It was
+still there after rebooting. 
+
+What do you think is preventing git-annex from recognizing the webapp command?
+
+Here is my log:
+recording state in git...)
+(scanning...) remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+ControlSocket .git/annex/ssh/git@gitlab.com already exists, disabling multiplexing
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+(started...) 
+To gitlab.com:gitannex1/FlosSoundPodcast.git
+   217cb33..aa2388c  git-annex -> synced/git-annex
+(recording state in git...)
+git-annex filter-process: git-annex: command not found
+fatal: the remote end hung up unexpectedly
+To ssh://git-annex-Backupserver.fritz.box-Florian_22_.2Fsrv.2Fmergerfs.2FPOOL01.2FBackupFlosSoundPodcast.2F/srv/mergerfs/POOL01/BackupFlosSoundPodcast/
+   217cb33..aa2388c  git-annex -> synced/git-annex
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+remote: 
+remote: ========================================================================
+remote: 
+remote: ERROR: Unknown command: git-annex-shell 'notifychanges' '/~/gitannex1/FlosSoundPodcast.git'
+
+remote: 
+remote: ========================================================================
+remote: 
+git-annex filter-process: git-annex: command not found
+fatal: the remote end hung up unexpectedly
+
+  user error (xargs [\"-0\",\"git\",\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"add\",\"--force\",\"--\"] exited 1)
+git-annex filter-process: git-annex: command not found
+fatal: the remote end hung up unexpectedly
+
+  user error (xargs [\"-0\",\"git\",\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"add\",\"--force\",\"--\"] exited 1)
+git-annex filter-process: git-annex: command not found
+fatal: the remote end hung up unexpectedly
+
+  user error (xargs [\"-0\",\"git\",\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"add\",\"--force\",\"--\"] exited 1)
+git-annex filter-process: git-annex: command not found
+fatal: the remote end hung up unexpectedly
+
+  user error (xargs [\"-0\",\"git\",\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"add\",\"--force\",\"--\"] exited 1)
+git-annex filter-process: git-annex: command not found
+fatal: the remote end hung up unexpectedly
+
+  user error (xargs [\"-0\",\"git\",\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"add\",\"--force\",\"--\"] exited 1)
+git-annex filter-process: git-annex: command not found
+fatal: the remote end hung up unexpectedly
+
+  user error (xargs [\"-0\",\"git\",\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"add\",\"--force\",\"--\"] exited 1)Der
+"""]]
diff --git a/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_3_069b107437b6456d027c8d97bc708d48._comment b/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_3_069b107437b6456d027c8d97bc708d48._comment
new file mode 100644
index 0000000000..bf7e39191b
--- /dev/null
+++ b/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_3_069b107437b6456d027c8d97bc708d48._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 3"
+ date="2022-08-28T17:56:20Z"
+ content="""
+There are still errors but those shouldn't prevent git-annex from working.
+
+Could you run `git annex sync` manually?
+
+Is the name of the gitlab remote really `origin`? Because it still seems to be trying to sync with it. Could you run `git remote -v`?
+"""]]
diff --git a/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_4_1e944c517796ca29f8870fcf76c9a0d4._comment b/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_4_1e944c517796ca29f8870fcf76c9a0d4._comment
new file mode 100644
index 0000000000..c6b59c7cbf
--- /dev/null
+++ b/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_4_1e944c517796ca29f8870fcf76c9a0d4._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-08-29T17:56:55Z"
+ content="""
+git-annex can be built without support for `git-annex webapp`,
+and it seems that your updated build ended up with that turned off.
+
+It would be good to contact the homebrew developers and file a bug report
+about this. From what I can see, their formula for git-annex does not
+explicitly disable the webapp, but some problem may have caused it to get
+disabled.
+
+I suspect what caused this is a problem with a new version of cabal.
+When I build git-annex (on linux) with cabal 3.4.1.0 and ghc 9.0.2,
+it builds without the webapp. This is even though the webapp is supposed
+to be build by default. Even `cabal configure -fWebapp`
+does not cause it to build the webapp. Made a bug for that at
+[[cabal_builds_without_assistant]].
+"""]]
diff --git a/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_5_2c7d2e81cbe943fe9154830fdf958181._comment b/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_5_2c7d2e81cbe943fe9154830fdf958181._comment
new file mode 100644
index 0000000000..d1ec499a92
--- /dev/null
+++ b/doc/bugs/Webapp_won__180__t_start_on_MacOS/comment_5_2c7d2e81cbe943fe9154830fdf958181._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-08-29T19:21:22Z"
+ content="""
+I've committed a workaround to that cabal problem, so assuming that was
+the cause of your problem, it will be fixed by the next git-annex release.
+
+If something else caused it, the next git-annex release would
+probably fail to build on homebrew. Which the homebrew developers will
+follow up on.
+
+So, I don't think this bug needs to be kept open any longer. Although you
+will need to wait, or install git-annex by another means than homebrew, in
+the meantime..
+"""]]
diff --git a/doc/bugs/When_--git-dir_is_not_in_--work-tree.mdwn b/doc/bugs/When_--git-dir_is_not_in_--work-tree.mdwn
new file mode 100644
index 0000000000..dbc430b22c
--- /dev/null
+++ b/doc/bugs/When_--git-dir_is_not_in_--work-tree.mdwn
@@ -0,0 +1,52 @@
+Bug report incorrectly originally posted in the forum as
+[[/forum/When_--git-dir_is_not_in_--work-tree]].
+
+Simple test case:
+
+        joey@darkstar:~/src/git-annex>cd /tmp
+        joey@darkstar:/tmp>mkdir foo
+        joey@darkstar:/tmp>cd foo
+        joey@darkstar:/tmp/foo>git --git-dir=`pwd`/.dotfiles --work-tree=`pwd` init
+        Initialized empty Git repository in /tmp/foo/.dotfiles/
+        joey@darkstar:/tmp/foo>git --git-dir=`pwd`/.dotfiles --work-tree=`pwd` annex init
+        init
+        git-annex: Git refuses to operate in this repository,
+        probably because it is owned by someone else.
+
+        To add an exception for this directory, call:
+                git config --global --add safe.directory /tmp/foo
+
+        failed
+
+And --debug shows:
+
+	[2022-09-20 14:17:56.238686901] (Utility.Process) process [1284622] read: git ["config","--local","--list"]
+	[2022-09-20 14:17:56.240836887] (Utility.Process) process [1284622] done ExitFailure 128
+	[2022-09-20 14:17:56.24107763] (Git.Config) config output: fatal: --local can only be used inside a git repository
+
+So passing --git-dir to that command will make it succeeed. The problem
+though is that passing --git-dir to that command also bypasses git's
+fix for CVE-2022-24765. The command would even succeed if the directory
+were owned by someone else then.
+
+	joey@darkstar:/tmp/foo>sudo chown -R root.root .
+	[sudo] password for joey:
+	joey@darkstar:/tmp/foo>git --git-dir=`pwd`/.dotfiles config --local --list
+	core.repositoryformatversion=0
+	core.filemode=true
+	core.bare=false
+	core.logallrefupdates=true
+	core.worktree=/tmp/foo
+	joey@darkstar:/tmp/foo>git config --local --list
+	fatal: --local can only be used inside a git repository
+
+But, if the user runs git-annex with an explicit --git-dir,
+it's actually ok for git-annex to bypass the CVE-2022-24765 check.
+Because --git-dir actually bypasses that check.
+
+So, the fix for this seems like it will involve it remembering
+when the git repo was originally specified using --git-dir (or `GIT_DIR`),
+and if so, guardSafeToUseRepo can skip the check, or pass --git-dir to
+`git config --local --list`.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Windows__58___Doesn__39__t_want_to_handle_files_with_2_dots_in_filename.mdwn b/doc/bugs/Windows__58___Doesn__39__t_want_to_handle_files_with_2_dots_in_filename.mdwn
new file mode 100644
index 0000000000..3a0da6b1dc
--- /dev/null
+++ b/doc/bugs/Windows__58___Doesn__39__t_want_to_handle_files_with_2_dots_in_filename.mdwn
@@ -0,0 +1,29 @@
+### Please describe the problem.
+
+Git annex assistant on Windows 7 won't handle files with 2 dots in the filename
+
+### What steps will reproduce the problem?
+
+Create a file like "3.2 Restriction et projection.mp4" which is in a directory synced by Assistant.
+
+The file is unmanaged.
+
+Renaming it to "3-2 Restriction et projection.mp4", and there it goes : synced with the remote repo.
+
+### What version of git-annex are you using? On what operating system?
+
+Latext git-annex on Win 7
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/Windows__58___Doesn__39__t_want_to_handle_files_with_2_dots_in_filename/comment_1_43f6de166d1811e9f9bd6e6d8b152e05._comment b/doc/bugs/Windows__58___Doesn__39__t_want_to_handle_files_with_2_dots_in_filename/comment_1_43f6de166d1811e9f9bd6e6d8b152e05._comment
new file mode 100644
index 0000000000..1012cc729f
--- /dev/null
+++ b/doc/bugs/Windows__58___Doesn__39__t_want_to_handle_files_with_2_dots_in_filename/comment_1_43f6de166d1811e9f9bd6e6d8b152e05._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-22T15:56:37Z"
+ content="""
+Unable to reproduce this on Windows XP.
+
+Is there anything in .git/annex/daemon.log that might help with debugging?
+"""]]
diff --git a/doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process.mdwn b/doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process.mdwn
new file mode 100644
index 0000000000..3ba796050b
--- /dev/null
+++ b/doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process.mdwn
@@ -0,0 +1,56 @@
+### Please describe the problem.
+I've had this problem intermittently through various versions of git-annex that use the filters. Just recently on the latest 7.20190912-g05bc37910, and only ever on windows.
+Messages look like this:
+
+```
+git-annex.exe: .\2018/18-06-14 playcenter fun/18-06-14 playcenter fun_001[archer].jpg: DeleteFile "\\\\?\\D:\\Pictures\\Photos_again\\2018\\18-06-14 playcenter fun\\18-06-14 playcenter fun_001[archer].jpg": permission denied (The process cannot access the file because it is being used by another process.)
+error: external filter 'git-annex smudge --clean -- %f' failed 1
+error: external filter 'git-annex smudge --clean -- %f' failed
+git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git update-index -q --refresh <file>
+```
+
+Essentially this will come up seemingly randomly when adding files, or when committing them. When it happens, git annex ends up in a strange state and often data is lost (the commit / additions continue despite errors and turn the affected files into the standin text files with paths to the content). It's scary enough, and unfortunately common enough, that I now make a copy of everything I add until I know for sure it has been successfully added and committed. My work around... is to delete failures, go to my copy, put it back and try adding it again (which may or may not work, due to the issue below).
+
+What I have at the moment is an issue in which the file was added correctly (I can only assume... as it exists in the annex with the correct hash, and I've added it multiple times always resulting in the same one). I found/confirmed its location by following the hardlink (annex.thin is active) `fsutils hardlink list <file>`, so that worked. Yet fsck / whereis tells me it's not there. `git annex add <file>` was successful and `git commit -m "stuff"` completed "successfully" with the fail message above.
+
+```
+$ git annex info 18-06-14\ playcenter\ fun_001\[archer\].jpg
+file: 18-06-14 playcenter fun_001[archer].jpg
+size: 1.18 megabytes
+key: SHA256E-s1177925--cf68e564a1505be3c609af97f80b77373264be399a5e5269ff20a43fe0f12e1d.jpg
+present: false
+```
+
+Yet the file exists at `D:\Pictures\Photos_again\.git\annex\objects\403\52d\SHA256E-s1177925--cf68e564a1505be3c609af97f80b77373264be399a5e5269ff20a43fe0f12e1d.jpg\SHA256E-s1177925--cf68e564a1505be3c609af97f80b77373264be399a5e5269ff20a43fe0f12e1d.jpg` which to my naive eyes looks ok. Viewing the files content as well confirms it's correct visually (and again, it's hardlinked)
+
+Yet...
+
+```
+$ git annex fsck 18-06-14\ playcenter\ fun_001\[archer\].jpg
+fsck 18-06-14 playcenter fun_001[archer].jpg (checksum...)
+  ** No known copies exist of 18-06-14 playcenter fun_001[archer].jpg
+failed
+(recording state in git...)
+git-annex: fsck: 1 failed
+```
+
+Is this something you've seen before? As I currently have a repo in this state, if there are any commands I could run that might help illuminate the status of things let me know. Also if there are any secret ways to tell git annex "hey I know this exists, look again" that would be neat to know. ;)
+
+Sorry I don't have more information at this stage. Please let me know how I can help out!
+
+
+
+### What steps will reproduce the problem?
+
+Unfortunately I have no way to reproduce. I've had it happen from time to time, so it is most definitely not a once off. I'm assuming it's some windows quirk as I've only ever seen it there.
+
+### What version of git-annex are you using? On what operating system?
+
+In this case "7.20190912-g05bc37910" but I seen it on earlier versions too. I think v6+. OS windows 8.1
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Seriously. Git annex is amazing. I've used it for a bunch of things for a few years now and continue to love it. Outside of the issue above I have nothing but good things to say about it. My only hope is it continues to receive the love it has for years to come.
+
+Thanks a lot everyone!
diff --git a/doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process/comment_1_79c57a6a8c0b100c07d014d8d2b862cb._comment b/doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process/comment_1_79c57a6a8c0b100c07d014d8d2b862cb._comment
new file mode 100644
index 0000000000..72a2c87e22
--- /dev/null
+++ b/doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process/comment_1_79c57a6a8c0b100c07d014d8d2b862cb._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="One other thing to add"
+ date="2019-10-15T10:44:14Z"
+ content="""
+I suppose one other thing I can add is that even within a command this is patchy. For instance in this commit of 16 files, 8 of them have this issue.
+
+I can only assume there is some race condition in windows causing the process problem (but I don't want to assume too much).
+
+I hope that helps, and I'm curious if anyone else has seen this.
+"""]]
diff --git a/doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process/comment_2_6242b7aded8b221aba8a5e3e4374238a._comment b/doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process/comment_2_6242b7aded8b221aba8a5e3e4374238a._comment
new file mode 100644
index 0000000000..791b480ca7
--- /dev/null
+++ b/doc/bugs/Windows__58___The_process_cannot_access_the_file_because_it_is_being_used_by_another_process/comment_2_6242b7aded8b221aba8a5e3e4374238a._comment
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="Does git annex add do something different to smudge filter add?"
+ date="2019-10-19T00:51:13Z"
+ content="""
+When adding a file with annex vs add (largefiles enabled) the same content is added to git but the result seems different. Then it goes and tries to delete the file and process busy, yadda yadda.
+
+```
+$ git status
+On branch adjusted/master(unlocked)
+Untracked files:
+  (use \"git add <file>...\" to include in what will be committed)
+        2018/18-09-28 bashed tooth/
+
+nothing added to commit but untracked files present (use \"git add\" to track)
+
+$ git annex add 2018/18-09-28\ bashed\ tooth/18-09-28\ bashed\ tooth_001\[archer\].mp4
+add 2018/18-09-28 bashed tooth/18-09-28 bashed tooth_001[archer].mp4
+ok
+(recording state in git...)
+
+$ git ls-files -s 2018/18-09-28\ bashed\ tooth/
+100644 d04fdcb2861e5cd57525db2bbfb7125bd64e99bd 0       2018/18-09-28 bashed tooth/18-09-28 bashed tooth_001[archer].mp4
+
+$ git cat-file -p d04fdcb2861e5cd57525db2bbfb7125bd64e99bd
+/annex/objects/SHA256E-s14269326--60ca9d2727cba35a06e308eb7aa9f03f0438599a9a611dcdfa897556791f7b9a.mp4
+
+$ git status
+git-annex.exe: .\2018/18-09-28 bashed tooth/18-09-28 bashed tooth_001[archer].mp4: DeleteFile \"\\\\?\\D:\\Pictures\\Photos_again\\2018\\18-09-28 bashed tooth\\18-09-28 bashed tooth_001[archer].mp4\": permission denied (The process cannot access the file because it is being used by another process.)
+error: external filter 'git-annex smudge --clean -- %f' failed 1
+error: external filter 'git-annex smudge --clean -- %f' failed
+Refresh index: 100% (13959/13959), done.
+On branch adjusted/master(unlocked)
+Changes to be committed:
+  (use \"git restore --staged <file>...\" to unstage)
+        new file:   2018/18-09-28 bashed tooth/18-09-28 bashed tooth_001[archer].mp4
+
+Changes not staged for commit:
+  (use \"git add <file>...\" to update what will be committed)
+  (use \"git restore <file>...\" to discard changes in working directory)
+        modified:   2018/18-09-28 bashed tooth/18-09-28 bashed tooth_001[archer].mp4
+
+$ git reset
+
+$ git add 2018/18-09-28\ bashed\ tooth/18-09-28\ bashed\ tooth_001\[archer\].mp4
+
+$ git ls-files -s 2018/18-09-28\ bashed\ tooth/
+100644 d04fdcb2861e5cd57525db2bbfb7125bd64e99bd 0       2018/18-09-28 bashed tooth/18-09-28 bashed tooth_001[archer].mp4
+
+$ git cat-file -p d04fdcb2861e5cd57525db2bbfb7125bd64e99bd
+/annex/objects/SHA256E-s14269326--60ca9d2727cba35a06e308eb7aa9f03f0438599a9a611dcdfa897556791f7b9a.mp4
+
+$ git status
+On branch adjusted/master(unlocked)
+Changes to be committed:
+  (use \"git restore --staged <file>...\" to unstage)
+        new file:   2018/18-09-28 bashed tooth/18-09-28 bashed tooth_001[archer].mp4
+``` 
+"""]]
diff --git a/doc/bugs/Windows__58___git_annex_get_failed.mdwn b/doc/bugs/Windows__58___git_annex_get_failed.mdwn
new file mode 100644
index 0000000000..6c7416653f
--- /dev/null
+++ b/doc/bugs/Windows__58___git_annex_get_failed.mdwn
@@ -0,0 +1,90 @@
+### Please describe the problem.
+I'm using git-annex v6 in windows and seems `git annex get` fails.
+Deleting the pointer files and doing a hard reset seems to fix the problem.
+Another bug report named "v6 repo can not restore files with executable permission" seems to point to the same problem but a little different.
+
+[[!retitle "git annex get fails sometimes in v6 repository on Windows"]]
+
+### What steps will reproduce the problem?
+I have a repo in D:\annex with a file `test`
+Now I create another repo:
+
+	$ cd H:\annex
+
+	$ git init
+	Initialized empty Git repository in H:/annex/.git/
+
+	$ git annex init "portable drive"
+	init portable drive
+	  Detected a filesystem without fifo support.
+
+	  Disabling ssh connection caching.
+
+	  Detected a crippled filesystem.
+
+	  Enabling direct mode.
+	ok
+	(recording state in git...)
+
+	$ git annex upgrade
+	upgrade . (v5 to v6...)
+	  Upgraded repository out of direct mode.
+
+	  Changes have been staged for all annexed files in this repository; you should run `git commit` to commit these changes.
+
+	  Any other clones of this repository that use direct mode need to be upgraded now, too.
+	ok
+
+	$ git remote add laptop D:/annex
+
+	$ git annex sync
+	commit  ok
+	pull laptop
+	warning: no common commits
+	remote: Counting objects: 21, done.
+	remote: Compressing objects: 100% (15/15), done.
+	remote: Total 21 (delta 3), reused 0 (delta 0)
+	Unpacking objects: 100% (21/21), done.
+	From D:/annex
+	 * [new branch]      git-annex  -> laptop/git-annex
+	 * [new branch]      master     -> laptop/master
+	 * [new branch]      synced/git-annex -> laptop/synced/git-annex
+	 * [new branch]      synced/master -> laptop/synced/master
+
+
+	Already up-to-date.
+	ok
+	(merging laptop/git-annex laptop/synced/git-annex into git-annex...)
+	(recording state in git...)
+	push laptop
+	Counting objects: 8, done.
+	Delta compression using up to 8 threads.
+	Compressing objects: 100% (6/6), done.
+	Writing objects: 100% (8/8), 928 bytes | 0 bytes/s, done.
+	Total 8 (delta 0), reused 0 (delta 0)
+	To D:/annex
+	   c1aee82..980dc01  git-annex -> synced/git-annex
+	ok
+
+	$ git annex get .
+	get test (from laptop...)
+	SHA256E-s14488367--4391729b982439764813156e1bfc12e9626ae89452ab812f5180c376fbd57fc0
+		 14,488,367 100%   63.24MB/s    0:00:00 (xfr#1, to-chk=0/1)
+	(checksum...)
+	git-annex: DeleteFile ".\\test": permission denied (The process cannot access the file because it is being used by another process.)
+	failed
+	git-annex: get: 1 failed
+
+It seems to try to delete the pointer file, but finds the file in use. Maybe fsck is using it?
+
+	$ cat test
+	/annex/objects/SHA256E-s14488367--4391729b982439764813156e1bfc12e9626ae89452ab812f5180c376fbd57fc0
+
+	$ git annex lock
+	lock test git-annex: content not present; cannot lock
+
+And `git annex unlock` will do nothing.
+
+If you can't reproduce the problem, I'll run the tests for you.
+### What version of git-annex are you using? On what operating system?
+Latest compile from source, Windows 8.1
diff --git a/doc/bugs/Windows__58___git_annex_get_failed/comment_2_0866038e64aa20c3b9ba3b3190074293._comment b/doc/bugs/Windows__58___git_annex_get_failed/comment_2_0866038e64aa20c3b9ba3b3190074293._comment
new file mode 100644
index 0000000000..4e77a505c8
--- /dev/null
+++ b/doc/bugs/Windows__58___git_annex_get_failed/comment_2_0866038e64aa20c3b9ba3b3190074293._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-04-04T19:24:08Z"
+ content="""
+Note that v6 mode is still considered experimental.
+
+I know that I saw a problem like this, where git-annex was reading the
+pointer file and didn't always get around to closing it before it tried to
+replace it. I thought I fixed it back in February though -- but that fix
+may have bit rotted; looking at the current code, I think it could leave
+the file open until a GC pass, so if the GC doesn't always 
+run in time, that could explain the reported indeterminacy.
+
+Please paste the actual version of git-annex you're using,
+"latest build from source" is a little bit vague.
+
+Since you are building from source, you might try pulling;
+I've made a change that may fix it again.
+"""]]
diff --git a/doc/bugs/Windows__58___git_annex_get_failed/comment_3_22809831226478bac7f9361ad8d0c79d._comment b/doc/bugs/Windows__58___git_annex_get_failed/comment_3_22809831226478bac7f9361ad8d0c79d._comment
new file mode 100644
index 0000000000..7ca9875f1a
--- /dev/null
+++ b/doc/bugs/Windows__58___git_annex_get_failed/comment_3_22809831226478bac7f9361ad8d0c79d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="ExGen"
+ subject="Found?"
+ date="2016-04-03T20:15:01Z"
+ content="""
+I think I found the problem: <br/>
+After I edit the file and commit, if I **lock** the file and **commit again**, the problem won't happen. <br/>
+I thought there shouldn't be a difference between committing a locked file and an unlocked file? <br/><br/>
+There is another problem too: When you unlock the file, git thinks you changed it. Maybe you could fix this too?
+"""]]
diff --git a/doc/bugs/Windows__58___git_annex_get_failed/comment_3_8a19ca100d44ab8131e40932f1bcdf29._comment b/doc/bugs/Windows__58___git_annex_get_failed/comment_3_8a19ca100d44ab8131e40932f1bcdf29._comment
new file mode 100644
index 0000000000..3140fee364
--- /dev/null
+++ b/doc/bugs/Windows__58___git_annex_get_failed/comment_3_8a19ca100d44ab8131e40932f1bcdf29._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="ExGen"
+ subject="comment 3^^"
+ date="2016-04-08T21:03:15Z"
+ content="""
+It's 6.20160401-g083dd8f, Sorry for the delay.
+And btw my v6 repo is not in adjusted mode. But I think adjusted mode has the same problem too.
+
+
+"""]]
diff --git a/doc/bugs/Windows__58___git_annex_get_failed/comment_4_b70fa3da7e776a6cd6d8467df30839c9._comment b/doc/bugs/Windows__58___git_annex_get_failed/comment_4_b70fa3da7e776a6cd6d8467df30839c9._comment
new file mode 100644
index 0000000000..a6d7ebecdc
--- /dev/null
+++ b/doc/bugs/Windows__58___git_annex_get_failed/comment_4_b70fa3da7e776a6cd6d8467df30839c9._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="ExGen"
+ subject="comment 4"
+ date="2016-04-08T22:00:33Z"
+ content="""
+I pulled and checked 6.20160408-gf970490. <br/>
+There are several problems now: <br/>
+
+1. When I `sync` on a new repo it `get`s all the files<br/>
+2. `drop` doesn't drop the file
+3. `lock` doesn't work <br/>
+4. I don't know if the problem with `get` really fixed because it isn't needed
+
+Btw, look at my comment on /todo/smudge (maybe put on a wrong page) <br/>
+I think using hardlinks on windows can fix many problems here ( adjusted/direct mode which I hate :)) ) <br/>
+And it should need little work as tools already accept it on windows
+
+I'll put all the commands needed to reproduce the problem:
+
+	cd D:/annex
+	git init
+	git annex init \"laptop\"
+	git annex upgrade
+	git add .
+	git commit -a -m \"First\"
+	git annex lock
+	git annex sync
+
+	cd H:/annex
+	git init
+	git annex init \"usb\"
+	git annex upgrade
+	git remote add laptop D:/annex
+	git annex sync
+"""]]
diff --git a/doc/bugs/Windows__58___support_NTFS_symlinks.mdwn b/doc/bugs/Windows__58___support_NTFS_symlinks.mdwn
new file mode 100644
index 0000000000..5a3da78ad9
--- /dev/null
+++ b/doc/bugs/Windows__58___support_NTFS_symlinks.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+
+Although it does require you to put your system in Developer Mode, [NTFS has supported symlinks without privilege elevation for almost five years now](https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/), and has supported them for programs run as administrator since Vista. git-annex, however, unconditionally assumes Windows filesystems are crippled.
+
+### What steps will reproduce the problem?
+
+Initialize a git-annex repository on an NTFS partition with a Windows system in Developer Mode.
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 8.20210715-g7334893d4
+build flags: Assistant Webapp Pairing TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 2 3 4 5 6 7
+```
+
+### Please provide any additional information below.
+
+n/a
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+It's worked excellently under Linux for about 6 months prior to me needing to switch to Windows for unrelated reasons.
diff --git a/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree.mdwn b/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree.mdwn
new file mode 100644
index 0000000000..57f95d992b
--- /dev/null
+++ b/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree.mdwn
@@ -0,0 +1,46 @@
+### Please describe the problem.
+
+On windows, git-annex webapp reports a crash.
+
+On the command-line, I get :
+
+$ git annex fsck
+fatal: unable to read tree 6d692a016b7d772800ddc3993ffd68fc6aaa21f3
+error: invalid object 100644 39e3d739a15dc3ed11a0c324781bf3658ccb933a for '001/e8c/SHA256E-s38500--9017f32c23b4de6363d3e5105bc1c47dd3cd983e471e71e0a9d420daaf0e3e7b.html.log'
+fatal: git-write-tree: error building trees
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+git-annex: failed to read sha from git write-tree
+
+Then, I try :
+
+$ git annex repair
+Running git fsck ...
+Unpacking all pack files.
+
+git-annex: DeleteFile ".git\\objects\\pack\\pack-c53ea32e9514b6dda95af1d8d879d91d32240d76.idx": permission denied (Accès refusé.)
+failed
+git-annex: repair: 1 failed
+
+
+### What steps will reproduce the problem?
+
+Dunno how that got messed up, and what to do now...
+
+### What version of git-annex are you using? On what operating system?
+
+latest nightly build (2015/10/19) on win 7
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_1_5829b551f5e1413ee236055eb3345760._comment b/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_1_5829b551f5e1413ee236055eb3345760._comment
new file mode 100644
index 0000000000..3ed4e18868
--- /dev/null
+++ b/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_1_5829b551f5e1413ee236055eb3345760._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-10-26T17:34:09Z"
+ content="""
+Why can't you read files in your git repository? This must be due to some
+permissions issue, etc. I know nothing about permissons in Windows, so
+can't offer any useful advice, beyond the fact that, for git (or git-annex)
+to work, you need to be able to read all the files in the git repository.
+
+You may also have some form of corruption of the files in the repository.
+Perhaps your disk is going bad or something?
+
+I don't see any indications of a git-annex bug here.
+"""]]
diff --git a/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_2_535016130f3307c8104168e6bb8a583d._comment b/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_2_535016130f3307c8104168e6bb8a583d._comment
new file mode 100644
index 0000000000..bda2a400dc
--- /dev/null
+++ b/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_2_535016130f3307c8104168e6bb8a583d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="aloukian"
+ subject="Your directory depth is too long"
+ date="2015-11-19T00:13:21Z"
+ content="""
+I've had a similar problem when the location of my annex was too deep. Windows only allows 256 char filenames. Git annex takes up a fair bit of that by storing files named according to their hash. I worked around the problem by creating my repo at the drive root and then creating a \"junction\" between the place where I wanted it to be and that location. It seems to work now.
+"""]]
diff --git a/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_3_79c66569c22a1280b807a3c21c2cdc4f._comment b/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_3_79c66569c22a1280b807a3c21c2cdc4f._comment
new file mode 100644
index 0000000000..c95034fdfe
--- /dev/null
+++ b/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_3_79c66569c22a1280b807a3c21c2cdc4f._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-12-02T17:22:01Z"
+ content="""
+Windows certianly does cause problems with its short path limits. The
+SHA512 hash backend is known to not work at all on windows, for example.
+
+However, recent versions of git-annex use relative paths to files, so it
+shouldn't much matter if they're run in a directory deep in a tree; it'll
+refer to '.git/foo' rather than 'c:/verylong/path/to/.git/foo'
+
+Also, a long path is certianly not the cause of
+
+	DeleteFile ".git\\objects\\pack\\pack-c53ea32e9514b6dda95af1d8d879d91d32240d76.idx": permission denied
+
+Since the path there is relative, is plenty short to not bother Windows's
+tiny mind, and there's clearly some sort of permission problem preventing
+this user from modifying this file.
+"""]]
diff --git a/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_4_2e5791aa8f568f86d0185a553227afa8._comment b/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_4_2e5791aa8f568f86d0185a553227afa8._comment
new file mode 100644
index 0000000000..31a51db950
--- /dev/null
+++ b/doc/bugs/Windows___58___git-annex__58___failed_to_read_sha_from_git_write-tree/comment_4_2e5791aa8f568f86d0185a553227afa8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="OlivierBerger"
+ subject="Again, difficult to tell"
+ date="2015-12-04T12:24:06Z"
+ content="""
+Well, I really don't understand either what may have caused the crashes... but the path issue might be a hint. I think our repo was cloned in a path something like : \"C:\Users\Majdi\git\git-annex.tem-tsp.eu\testscpo\" which already takes around 48 chars.
+"""]]
diff --git a/doc/bugs/Windows_build_test_failures.mdwn b/doc/bugs/Windows_build_test_failures.mdwn
new file mode 100644
index 0000000000..556f5dd387
--- /dev/null
+++ b/doc/bugs/Windows_build_test_failures.mdwn
@@ -0,0 +1,1234 @@
+Given that others can build+run OK I wonder if this is a build environment setup problem rather than a code issue. 
+This might be two bugs, but I rather suspect the fix to one is the fix to the other.
+
+### Please describe the problem.
+Some tests fail with:
+ssh: Could not resolve hostname C: no address associated with name
+
+then if you try and do a copy to/from an ssh remote then it fails with simply 'copy: 1 failed'
+
+### What steps will reproduce the problem?
+
+For the tests, simply sh standalone/windows/build.sh
+
+For the other, I'm using a modified version of the other windows user's script, the set -x'd output is:
+
+<pre>
++ git-annex version
+git-annex version: 4.20130621-g36258de^M
+build flags: Pairing Testsuite S3 WebDAV DNS^M
++ ssh gitremote sh testrepo.sh
+git-annex version: 4.20130621-g36258de
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS
+Initialized empty Git repository in /media/backup/git/repo.git/
+init origin ok
+(Recording state in git...)
+commit
+ok
+git-annex: no branch is checked out
++ rm -rf repo
++ git init repo
+Initialized empty Git repository in c:/Users/Oliver/repo/.git/
++ cd repo
++ git-annex init
+init  ^M
+  Detected a crippled filesystem.^M
+^M
+  Enabling direct mode.^M
+^M
+  Detected a filesystem without fifo support.^M
+^M
+  Disabling ssh connection caching.^M
+ok^M
+(Recording state in git...)^M
++ git remote add origin ssh://git@remote/~/repo.git
++ echo hello
++ git-annex add .
+add foo.txt (checksum...) ok^M
+(Recording state in git...)^M
++ git commit -m .
+[master (root-commit) f34a076] .
+ 1 file changed, 1 insertion(+)
+ create mode 120000 foo.txt
++ git-annex sync
+commit  ^M
+ok^M
+pull origin warning: no common commits
+From ssh://remote/~/repo
+ * [new branch]      git-annex  -> origin/git-annex
+^M
+ok^M
+(merging origin/git-annex into git-annex...)^M
+(Recording state in git...)^M
+push origin To ssh://git@remote/~/repo.git
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+^M
+ok^M
++ git-annex copy --to origin
+copy foo.txt (checking origin...) (to origin...) ^M
+failed^M
+git-annex.exe: copy: 1 failed
+</pre>
+
+
+
+
+
+### What version of git-annex are you using? On what operating system?
+Windows (8 x64):
+git-annex version: 4.20130621-g36258de
+build flags: Pairing Testsuite S3 WebDAV DNS
+Linux (debian wheezy i386):
+git-annex version: 4.20130621-g36258de
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS
+
+other versions
+git-bash: git(1.8.0.msysgit.0),ssh(ssh 4.6p1, ssl 0.9.8e 23 feb 2007)
+msys: git(none) ssh(ssh 5.4p1, ssl 1.0.0 29 Mar 2010)
+cygwin: git(1.7.9) ssh(none)
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+build.log:
++ set -e
++ HP='/c/Program Files (x86)/Haskell Platform/2012.4.0.0'
++ FLAGS='-Webapp -Assistant -XMPP'
++ PATH='/c/Program Files (x86)/Haskell Platform/2012.4.0.0/bin:/c/Program Files (x86)/Haskell Platform/2012.4.0.0/lib/extralibs/bin:/c/Program Files (x86)/NSIS:/home/Oliver/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files (x86)/Haskell/bin:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/lib/extralibs/bin:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin:/c/Program Files (x86)/AMD APP/bin/x86_64:/c/Program Files (x86)/AMD APP/bin/x86:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files (x86)/ATI Technologies/ATI.ACE/Core-Static:/c/Program Files (x86)/Windows Kits/8.0/Windows Performance Toolkit/:/c/Program Files/Microsoft/Web Platform Installer/:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/mingw/bin:/c/Users/Oliver/AppData/Roaming/cabal/bin'
++ rm -f git-annex-installer.exe
++ cabal update
+Downloading the latest package list from hackage.haskell.org
++ rm -rf MissingH-1.2.0.0
++ cabal unpack MissingH
+Unpacking to MissingH-1.2.0.0\
++ cd MissingH-1.2.0.0
++ withcyg patch -p1
++ PATH='/c/Program Files (x86)/Haskell Platform/2012.4.0.0/bin:/c/Program Files (x86)/Haskell Platform/2012.4.0.0/lib/extralibs/bin:/c/Program Files (x86)/NSIS:/home/Oliver/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files (x86)/Haskell/bin:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/lib/extralibs/bin:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin:/c/Program Files (x86)/AMD APP/bin/x86_64:/c/Program Files (x86)/AMD APP/bin/x86:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files (x86)/ATI Technologies/ATI.ACE/Core-Static:/c/Program Files (x86)/Windows Kits/8.0/Windows Performance Toolkit/:/c/Program Files/Microsoft/Web Platform Installer/:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/mingw/bin:/c/Users/Oliver/AppData/Roaming/cabal/bin:/c/cygwin/bin'
++ patch -p1
+patching file src/System/IO/WindowsCompat.hs
+Hunk #1 succeeded at 119 (offset -1 lines).
+Hunk #2 succeeded at 132 (offset -1 lines).
++ cabal install
+Resolving dependencies...
+In order, the following would be installed:
+MissingH-1.2.0.0 (reinstall)
+cabal.exe: The following packages are likely to be broken by the reinstalls:
+hS3-0.5.7
+Use --force-reinstalls if you want to install anyway.
++ true
++ cd ..
++ cabal install --only-dependencies '-f-Webapp -Assistant -XMPP'
+Resolving dependencies...
+All the requested packages are already installed:
+Use --reinstall if you want to reinstall anyway.
++ '[' -e last-incremental-failed ']'
++ touch last-incremental-failed
++ withcyg cabal configure '-f-Webapp -Assistant -XMPP'
++ PATH='/c/Program Files (x86)/Haskell Platform/2012.4.0.0/bin:/c/Program Files (x86)/Haskell Platform/2012.4.0.0/lib/extralibs/bin:/c/Program Files (x86)/NSIS:/home/Oliver/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files (x86)/Haskell/bin:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/lib/extralibs/bin:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin:/c/Program Files (x86)/AMD APP/bin/x86_64:/c/Program Files (x86)/AMD APP/bin/x86:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files (x86)/ATI Technologies/ATI.ACE/Core-Static:/c/Program Files (x86)/Windows Kits/8.0/Windows Performance Toolkit/:/c/Program Files/Microsoft/Web Platform Installer/:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/mingw/bin:/c/Users/Oliver/AppData/Roaming/cabal/bin:/c/cygwin/bin'
++ cabal configure '-f-Webapp -Assistant -XMPP'
+Resolving dependencies...
+[ 1 of 24] Compiling Utility.Applicative ( Utility\Applicative.hs, dist\setup\Utility\Applicative.o )
+[ 2 of 24] Compiling Utility.PartialPrelude ( Utility\PartialPrelude.hs, dist\setup\Utility\PartialPrelude.o )
+[ 3 of 24] Compiling Utility.FileSystemEncoding ( Utility\FileSystemEncoding.hs, dist\setup\Utility\FileSystemEncoding.o )
+[ 4 of 24] Compiling Utility.Exception ( Utility\Exception.hs, dist\setup\Utility\Exception.o )
+[ 5 of 24] Compiling Utility.Misc     ( Utility\Misc.hs, dist\setup\Utility\Misc.o )
+[ 6 of 24] Compiling Utility.Process  ( Utility\Process.hs, dist\setup\Utility\Process.o )
+[ 7 of 24] Compiling Utility.Env      ( Utility\Env.hs, dist\setup\Utility\Env.o )
+[ 8 of 24] Compiling Utility.UserInfo ( Utility\UserInfo.hs, dist\setup\Utility\UserInfo.o )
+[ 9 of 24] Compiling Utility.OSX      ( Utility\OSX.hs, dist\setup\Utility\OSX.o )
+[10 of 24] Compiling Utility.Tmp      ( Utility\Tmp.hs, dist\setup\Utility\Tmp.o )
+[11 of 24] Compiling Utility.Monad    ( Utility\Monad.hs, dist\setup\Utility\Monad.o )
+[12 of 24] Compiling Utility.Path     ( Utility\Path.hs, dist\setup\Utility\Path.o )
+[13 of 24] Compiling Utility.FreeDesktop ( Utility\FreeDesktop.hs, dist\setup\Utility\FreeDesktop.o )
+[16 of 24] Compiling Utility.SafeCommand ( Utility\SafeCommand.hs, dist\setup\Utility\SafeCommand.o )
+[17 of 24] Compiling Utility.ExternalSHA ( Utility\ExternalSHA.hs, dist\setup\Utility\ExternalSHA.o )
+[18 of 24] Compiling Utility.Directory ( Utility\Directory.hs, dist\setup\Utility\Directory.o )
+Linking .\dist\setup\setup.exe ...
+  checking version... 4.20130621-g36258de
+  checking git... yes
+  checking git version... 1.7.9
+  checking cp -a... yes
+  checking cp -p... yes
+  checking cp --reflink=auto... no
+  checking xargs -0... yes
+  checking rsync... yes
+  checking curl... no
+  checking wget... yes
+  checking bup... no
+  checking gpg... not available
+  checking lsof... not available
+  checking ssh connection caching... no
+  checking sha1... sha1sum
+  checking sha256... sha256sum
+  checking sha512... sha512sum
+  checking sha224... sha224sum
+  checking sha384... sha384sum
+Configuring git-annex-4.20130601...
++ withcyg cabal build
++ PATH='/c/Program Files (x86)/Haskell Platform/2012.4.0.0/bin:/c/Program Files (x86)/Haskell Platform/2012.4.0.0/lib/extralibs/bin:/c/Program Files (x86)/NSIS:/home/Oliver/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files (x86)/Haskell/bin:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/lib/extralibs/bin:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin:/c/Program Files (x86)/AMD APP/bin/x86_64:/c/Program Files (x86)/AMD APP/bin/x86:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files (x86)/ATI Technologies/ATI.ACE/Core-Static:/c/Program Files (x86)/Windows Kits/8.0/Windows Performance Toolkit/:/c/Program Files/Microsoft/Web Platform Installer/:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/mingw/bin:/c/Users/Oliver/AppData/Roaming/cabal/bin:/c/cygwin/bin'
++ cabal build
+Building git-annex-4.20130601...
+Preprocessing executable 'git-annex' for git-annex-4.20130601...
+Touch.hsc:117:2: warning: #warning "utimensat and lutimes not available; building without symlink timestamp preservation support"
+Touch.hsc: In function 'main':
+Touch.hsc:117:2: warning: #warning "utimensat and lutimes not available; building without symlink timestamp preservation support"
+Touch.hsc:117:2: warning: #warning "utimensat and lutimes not available; building without symlink timestamp preservation support"
+In file included from Mounts.hsc:23:0:
+Utility/libmounts.h:17:3: warning: #warning mounts listing code not available for this OS
+
+Utility\libdiskfree.c:36:3:
+     warning: #warning free space checking code not available for this OS
+
+In file included from Utility\libmounts.c:35:0: 
+
+Utility\libmounts.h:17:3:
+     warning: #warning mounts listing code not available for this OS
+[  1 of 217] Compiling Utility.Dot      ( Utility\Dot.hs, dist\build\git-annex\git-annex-tmp\Utility\Dot.o )
+[  2 of 217] Compiling BuildFlags       ( BuildFlags.hs, dist\build\git-annex\git-annex-tmp\BuildFlags.o )
+[  3 of 217] Compiling Utility.Percentage ( Utility\Percentage.hs, dist\build\git-annex\git-annex-tmp\Utility\Percentage.o )
+[  4 of 217] Compiling Utility.Base64   ( Utility\Base64.hs, dist\build\git-annex\git-annex-tmp\Utility\Base64.o )
+[  5 of 217] Compiling Utility.JSONStream ( Utility\JSONStream.hs, dist\build\git-annex\git-annex-tmp\Utility\JSONStream.o )
+[  6 of 217] Compiling Git.Types        ( Git\Types.hs, dist\build\git-annex\git-annex-tmp\Git\Types.o )
+[  7 of 217] Compiling Utility.DataUnits ( Utility\DataUnits.hs, dist\build\git-annex\git-annex-tmp\Utility\DataUnits.o )
+[  8 of 217] Compiling Types.FileMatcher ( Types\FileMatcher.hs, dist\build\git-annex\git-annex-tmp\Types\FileMatcher.o )
+[  9 of 217] Compiling Types.BranchState ( Types\BranchState.hs, dist\build\git-annex\git-annex-tmp\Types\BranchState.o )
+[ 10 of 217] Compiling Messages.JSON    ( Messages\JSON.hs, dist\build\git-annex\git-annex-tmp\Messages\JSON.o )
+[ 11 of 217] Compiling Types.UUID       ( Types\UUID.hs, dist\build\git-annex\git-annex-tmp\Types\UUID.o )
+[ 12 of 217] Compiling Types.Group      ( Types\Group.hs, dist\build\git-annex\git-annex-tmp\Types\Group.o )
+[ 13 of 217] Compiling Utility.Shell    ( Utility\Shell.hs, dist\build\git-annex\git-annex-tmp\Utility\Shell.o )
+[ 14 of 217] Compiling Utility.QuickCheck ( Utility\QuickCheck.hs, dist\build\git-annex\git-annex-tmp\Utility\QuickCheck.o )
+[ 15 of 217] Compiling Utility.PartialPrelude ( Utility\PartialPrelude.hs, dist\build\git-annex\git-annex-tmp\Utility\PartialPrelude.o )
+[ 16 of 217] Compiling Utility.HumanTime ( Utility\HumanTime.hs, dist\build\git-annex\git-annex-tmp\Utility\HumanTime.o )
+[ 17 of 217] Compiling Utility.FileSystemEncoding ( Utility\FileSystemEncoding.hs, dist\build\git-annex\git-annex-tmp\Utility\FileSystemEncoding.o )
+[ 18 of 217] Compiling Utility.Touch    ( dist\build\git-annex\git-annex-tmp\Utility\Touch.hs, dist\build\git-annex\git-annex-tmp\Utility\Touch.o )
+
+UtilityTouch.hsc:17:1: Warning:
+    The import of `Utility.FileSystemEncoding' is redundant
+      except perhaps to import instances from `Utility.FileSystemEncoding'
+    To import instances alone, use: import Utility.FileSystemEncoding()
+
+UtilityTouch.hsc:19:1: Warning:
+    The import of `Foreign' is redundant
+      except perhaps to import instances from `Foreign'
+    To import instances alone, use: import Foreign()
+
+UtilityTouch.hsc:21:1: Warning:
+    The import of `Control.Monad' is redundant
+      except perhaps to import instances from `Control.Monad'
+    To import instances alone, use: import Control.Monad()
+[ 19 of 217] Compiling Utility.Applicative ( Utility\Applicative.hs, dist\build\git-annex\git-annex-tmp\Utility\Applicative.o )
+[ 20 of 217] Compiling Utility.Monad    ( Utility\Monad.hs, dist\build\git-annex\git-annex-tmp\Utility\Monad.o )
+[ 21 of 217] Compiling Utility.Exception ( Utility\Exception.hs, dist\build\git-annex\git-annex-tmp\Utility\Exception.o )
+[ 22 of 217] Compiling Utility.Tmp      ( Utility\Tmp.hs, dist\build\git-annex\git-annex-tmp\Utility\Tmp.o )
+[ 23 of 217] Compiling Utility.Env      ( Utility\Env.hs, dist\build\git-annex\git-annex-tmp\Utility\Env.o )
+[ 24 of 217] Compiling Utility.UserInfo ( Utility\UserInfo.hs, dist\build\git-annex\git-annex-tmp\Utility\UserInfo.o )
+[ 25 of 217] Compiling Utility.Misc     ( Utility\Misc.hs, dist\build\git-annex\git-annex-tmp\Utility\Misc.o )
+
+Utility\Misc.hs:22:1: Warning:
+    The import of `Utility.Exception' is redundant
+      except perhaps to import instances from `Utility.Exception'
+    To import instances alone, use: import Utility.Exception()
+[ 26 of 217] Compiling Utility.Process  ( Utility\Process.hs, dist\build\git-annex\git-annex-tmp\Utility\Process.o )
+
+Utility\Process.hs:44:1: Warning:
+    The import of `Data.Maybe' is redundant
+      except perhaps to import instances from `Data.Maybe'
+    To import instances alone, use: import Data.Maybe()
+[ 27 of 217] Compiling Utility.Network  ( Utility\Network.hs, dist\build\git-annex\git-annex-tmp\Utility\Network.o )
+[ 28 of 217] Compiling Utility.Verifiable ( Utility\Verifiable.hs, dist\build\git-annex\git-annex-tmp\Utility\Verifiable.o )
+[ 29 of 217] Compiling Utility.Format   ( Utility\Format.hs, dist\build\git-annex\git-annex-tmp\Utility\Format.o )
+[ 30 of 217] Compiling Build.SysConfig  ( Build\SysConfig.hs, dist\build\git-annex\git-annex-tmp\Build\SysConfig.o )
+[ 31 of 217] Compiling Utility.Path     ( Utility\Path.hs, dist\build\git-annex\git-annex-tmp\Utility\Path.o )
+[ 32 of 217] Compiling Config.Cost      ( Config\Cost.hs, dist\build\git-annex\git-annex-tmp\Config\Cost.o )
+[ 33 of 217] Compiling Types.Messages   ( Types\Messages.hs, dist\build\git-annex\git-annex-tmp\Types\Messages.o )
+[ 34 of 217] Compiling Types.TrustLevel ( Types\TrustLevel.hs, dist\build\git-annex\git-annex-tmp\Types\TrustLevel.o )
+[ 35 of 217] Compiling Utility.SafeCommand ( Utility\SafeCommand.hs, dist\build\git-annex\git-annex-tmp\Utility\SafeCommand.o )
+[ 36 of 217] Compiling Utility.Directory ( Utility\Directory.hs, dist\build\git-annex\git-annex-tmp\Utility\Directory.o )
+[ 37 of 217] Compiling Utility.ExternalSHA ( Utility\ExternalSHA.hs, dist\build\git-annex\git-annex-tmp\Utility\ExternalSHA.o )
+[ 38 of 217] Compiling Common           ( Common.hs, dist\build\git-annex\git-annex-tmp\Common.o )
+[ 39 of 217] Compiling Git.Filename     ( Git\Filename.hs, dist\build\git-annex\git-annex-tmp\Git\Filename.o )
+[ 40 of 217] Compiling Logs.UUIDBased   ( Logs\UUIDBased.hs, dist\build\git-annex\git-annex-tmp\Logs\UUIDBased.o )
+[ 41 of 217] Compiling Types.Key        ( Types\Key.hs, dist\build\git-annex\git-annex-tmp\Types\Key.o )
+[ 42 of 217] Compiling Utility.FileMode ( Utility\FileMode.hs, dist\build\git-annex\git-annex-tmp\Utility\FileMode.o )
+[ 43 of 217] Compiling Git              ( Git.hs, dist\build\git-annex\git-annex-tmp\Git.o )
+
+Git.hs:41:1: Warning:
+    The import of `Utility.FileMode' is redundant
+      except perhaps to import instances from `Utility.FileMode'
+    To import instances alone, use: import Utility.FileMode()
+[ 44 of 217] Compiling Utility.InodeCache ( Utility\InodeCache.hs, dist\build\git-annex\git-annex-tmp\Utility\InodeCache.o )
+[ 45 of 217] Compiling Types.KeySource  ( Types\KeySource.hs, dist\build\git-annex\git-annex-tmp\Types\KeySource.o )
+[ 46 of 217] Compiling Types.Backend    ( Types\Backend.hs, dist\build\git-annex\git-annex-tmp\Types\Backend.o )
+[ 47 of 217] Compiling Utility.Gpg      ( Utility\Gpg.hs, dist\build\git-annex\git-annex-tmp\Utility\Gpg.o )
+
+Utility\Gpg.hs:12:1: Warning:
+    The import of `System.Posix.Types' is redundant
+      except perhaps to import instances from `System.Posix.Types'
+    To import instances alone, use: import System.Posix.Types()
+
+Utility\Gpg.hs:14:1: Warning:
+    The import of `Control.Concurrent' is redundant
+      except perhaps to import instances from `Control.Concurrent'
+    To import instances alone, use: import Control.Concurrent()
+
+Utility\Gpg.hs:15:1: Warning:
+    The import of `Control.Exception' is redundant
+      except perhaps to import instances from `Control.Exception'
+    To import instances alone, use: import Control.Exception()
+
+Utility\Gpg.hs:16:1: Warning:
+    The import of `System.Path' is redundant
+      except perhaps to import instances from `System.Path'
+    To import instances alone, use: import System.Path()
+
+Utility\Gpg.hs:19:1: Warning:
+    The import of `Utility.Env' is redundant
+      except perhaps to import instances from `Utility.Env'
+    To import instances alone, use: import Utility.Env()
+[ 48 of 217] Compiling Types.Crypto     ( Types\Crypto.hs, dist\build\git-annex\git-annex-tmp\Types\Crypto.o )
+[ 49 of 217] Compiling Utility.Matcher  ( Utility\Matcher.hs, dist\build\git-annex\git-annex-tmp\Utility\Matcher.o )
+[ 50 of 217] Compiling Utility.Metered  ( Utility\Metered.hs, dist\build\git-annex\git-annex-tmp\Utility\Metered.o )
+[ 51 of 217] Compiling Git.FilePath     ( Git\FilePath.hs, dist\build\git-annex\git-annex-tmp\Git\FilePath.o )
+[ 52 of 217] Compiling Git.Url          ( Git\Url.hs, dist\build\git-annex\git-annex-tmp\Git\Url.o )
+[ 53 of 217] Compiling Git.Construct    ( Git\Construct.hs, dist\build\git-annex\git-annex-tmp\Git\Construct.o )
+[ 54 of 217] Compiling Git.Config       ( Git\Config.hs, dist\build\git-annex\git-annex-tmp\Git\Config.o )
+[ 55 of 217] Compiling Git.CurrentRepo  ( Git\CurrentRepo.hs, dist\build\git-annex\git-annex-tmp\Git\CurrentRepo.o )
+
+Git\CurrentRepo.hs:16:1: Warning:
+    The import of `Utility.Env' is redundant
+      except perhaps to import instances from `Utility.Env'
+    To import instances alone, use: import Utility.Env()
+
+Git\CurrentRepo.hs:43:17: Warning: Defined but not used: `s'
+[ 56 of 217] Compiling Git.SharedRepository ( Git\SharedRepository.hs, dist\build\git-annex\git-annex-tmp\Git\SharedRepository.o )
+[ 57 of 217] Compiling Types.GitConfig  ( Types\GitConfig.hs, dist\build\git-annex\git-annex-tmp\Types\GitConfig.o )
+[ 58 of 217] Compiling Types.Remote     ( Types\Remote.hs, dist\build\git-annex\git-annex-tmp\Types\Remote.o )
+[ 59 of 217] Compiling Types.StandardGroups ( Types\StandardGroups.hs, dist\build\git-annex\git-annex-tmp\Types\StandardGroups.o )
+[ 60 of 217] Compiling Utility.Gpg.Types ( Utility\Gpg\Types.hs, dist\build\git-annex\git-annex-tmp\Utility\Gpg\Types.o )
+[ 61 of 217] Compiling Git.Sha          ( Git\Sha.hs, dist\build\git-annex\git-annex-tmp\Git\Sha.o )
+[ 62 of 217] Compiling Utility.CoProcess ( Utility\CoProcess.hs, dist\build\git-annex\git-annex-tmp\Utility\CoProcess.o )
+[ 63 of 217] Compiling Git.Command      ( Git\Command.hs, dist\build\git-annex\git-annex-tmp\Git\Command.o )
+[ 64 of 217] Compiling Git.LsFiles      ( Git\LsFiles.hs, dist\build\git-annex\git-annex-tmp\Git\LsFiles.o )
+[ 65 of 217] Compiling Git.CatFile      ( Git\CatFile.hs, dist\build\git-annex\git-annex-tmp\Git\CatFile.o )
+[ 66 of 217] Compiling Git.UpdateIndex  ( Git\UpdateIndex.hs, dist\build\git-annex\git-annex-tmp\Git\UpdateIndex.o )
+[ 67 of 217] Compiling Git.Queue        ( Git\Queue.hs, dist\build\git-annex\git-annex-tmp\Git\Queue.o )
+[ 68 of 217] Compiling Git.Version      ( Git\Version.hs, dist\build\git-annex\git-annex-tmp\Git\Version.o )
+[ 69 of 217] Compiling Git.CheckAttr    ( Git\CheckAttr.hs, dist\build\git-annex\git-annex-tmp\Git\CheckAttr.o )
+[ 70 of 217] Compiling Annex            ( Annex.hs, dist\build\git-annex\git-annex-tmp\Annex.o )
+[ 71 of 217] Compiling Types.Option     ( Types\Option.hs, dist\build\git-annex\git-annex-tmp\Types\Option.o )
+[ 72 of 217] Compiling Types            ( Types.hs, dist\build\git-annex\git-annex-tmp\Types.o )
+[ 73 of 217] Compiling Locations        ( Locations.hs, dist\build\git-annex\git-annex-tmp\Locations.o )
+[ 74 of 217] Compiling Messages         ( Messages.hs, dist\build\git-annex\git-annex-tmp\Messages.o )
+[ 75 of 217] Compiling Common.Annex     ( Common\Annex.hs, dist\build\git-annex\git-annex-tmp\Common\Annex.o )
+[ 76 of 217] Compiling Crypto           ( Crypto.hs, dist\build\git-annex\git-annex-tmp\Crypto.o )
+[ 77 of 217] Compiling Annex.CatFile    ( Annex\CatFile.hs, dist\build\git-annex\git-annex-tmp\Annex\CatFile.o )
+[ 78 of 217] Compiling Backend.SHA      ( Backend\SHA.hs, dist\build\git-annex\git-annex-tmp\Backend\SHA.o )
+[ 79 of 217] Compiling Backend.WORM     ( Backend\WORM.hs, dist\build\git-annex\git-annex-tmp\Backend\WORM.o )
+[ 80 of 217] Compiling Backend.URL      ( Backend\URL.hs, dist\build\git-annex\git-annex-tmp\Backend\URL.o )
+[ 81 of 217] Compiling Annex.Exception  ( Annex\Exception.hs, dist\build\git-annex\git-annex-tmp\Annex\Exception.o )
+[ 82 of 217] Compiling Remote.Helper.Special ( Remote\Helper\Special.hs, dist\build\git-annex\git-annex-tmp\Remote\Helper\Special.o )
+[ 83 of 217] Compiling Remote.Helper.Chunked ( Remote\Helper\Chunked.hs, dist\build\git-annex\git-annex-tmp\Remote\Helper\Chunked.o )
+[ 84 of 217] Compiling Annex.Environment ( Annex\Environment.hs, dist\build\git-annex\git-annex-tmp\Annex\Environment.o )
+
+Annex\Environment.hs:13:1: Warning:
+    The import of `Utility.Env' is redundant
+      except perhaps to import instances from `Utility.Env'
+    To import instances alone, use: import Utility.Env()
+
+Annex\Environment.hs:14:1: Warning:
+    The import of `Utility.UserInfo' is redundant
+      except perhaps to import instances from `Utility.UserInfo'
+    To import instances alone, use: import Utility.UserInfo()
+[ 85 of 217] Compiling Types.Command    ( Types\Command.hs, dist\build\git-annex\git-annex-tmp\Types\Command.o )
+[ 86 of 217] Compiling Usage            ( Usage.hs, dist\build\git-annex\git-annex-tmp\Usage.o )
+[ 87 of 217] Compiling Annex.Queue      ( Annex\Queue.hs, dist\build\git-annex\git-annex-tmp\Annex\Queue.o )
+[ 88 of 217] Compiling Annex.BranchState ( Annex\BranchState.hs, dist\build\git-annex\git-annex-tmp\Annex\BranchState.o )
+[ 89 of 217] Compiling Remote.Helper.Encryptable ( Remote\Helper\Encryptable.hs, dist\build\git-annex\git-annex-tmp\Remote\Helper\Encryptable.o )
+[ 90 of 217] Compiling Fields           ( Fields.hs, dist\build\git-annex\git-annex-tmp\Fields.o )
+[ 91 of 217] Compiling Annex.CheckAttr  ( Annex\CheckAttr.hs, dist\build\git-annex\git-annex-tmp\Annex\CheckAttr.o )
+[ 92 of 217] Compiling Git.HashObject   ( Git\HashObject.hs, dist\build\git-annex\git-annex-tmp\Git\HashObject.o )
+[ 93 of 217] Compiling Annex.Link       ( Annex\Link.hs, dist\build\git-annex\git-annex-tmp\Annex\Link.o )
+[ 94 of 217] Compiling Utility.CopyFile ( Utility\CopyFile.hs, dist\build\git-annex\git-annex-tmp\Utility\CopyFile.o )
+[ 95 of 217] Compiling Git.Ref          ( Git\Ref.hs, dist\build\git-annex\git-annex-tmp\Git\Ref.o )
+[ 96 of 217] Compiling Git.Branch       ( Git\Branch.hs, dist\build\git-annex\git-annex-tmp\Git\Branch.o )
+[ 97 of 217] Compiling Git.UnionMerge   ( Git\UnionMerge.hs, dist\build\git-annex\git-annex-tmp\Git\UnionMerge.o )
+[ 98 of 217] Compiling Git.Merge        ( Git\Merge.hs, dist\build\git-annex\git-annex-tmp\Git\Merge.o )
+[ 99 of 217] Compiling Git.DiffTree     ( Git\DiffTree.hs, dist\build\git-annex\git-annex-tmp\Git\DiffTree.o )
+[100 of 217] Compiling Utility.DiskFree ( Utility\DiskFree.hs, dist\build\git-annex\git-annex-tmp\Utility\DiskFree.o )
+[101 of 217] Compiling Utility.Url      ( Utility\Url.hs, dist\build\git-annex\git-annex-tmp\Utility\Url.o )
+[102 of 217] Compiling Utility.Rsync    ( Utility\Rsync.hs, dist\build\git-annex\git-annex-tmp\Utility\Rsync.o )
+[103 of 217] Compiling Utility.LogFile  ( Utility\LogFile.hs, dist\build\git-annex\git-annex-tmp\Utility\LogFile.o )
+
+Utility\LogFile.hs:67:1: Warning:
+    Top-level binding with no type signature:
+      redir :: forall t t1 t2. t -> t1 -> t2
+[104 of 217] Compiling Utility.Daemon   ( Utility\Daemon.hs, dist\build\git-annex\git-annex-tmp\Utility\Daemon.o )
+
+Utility\Daemon.hs:13:1: Warning:
+    The import of `Utility.LogFile' is redundant
+      except perhaps to import instances from `Utility.LogFile'
+    To import instances alone, use: import Utility.LogFile()
+
+Utility\Daemon.hs:19:1: Warning:
+    The import of `System.Posix.Types' is redundant
+      except perhaps to import instances from `System.Posix.Types'
+    To import instances alone, use: import System.Posix.Types()
+[105 of 217] Compiling Git.AutoCorrect  ( Git\AutoCorrect.hs, dist\build\git-annex\git-annex-tmp\Git\AutoCorrect.o )
+[106 of 217] Compiling Utility.ThreadScheduler ( Utility\ThreadScheduler.hs, dist\build\git-annex\git-annex-tmp\Utility\ThreadScheduler.o )
+[107 of 217] Compiling Git.LsTree       ( Git\LsTree.hs, dist\build\git-annex\git-annex-tmp\Git\LsTree.o )
+[108 of 217] Compiling Config           ( Config.hs, dist\build\git-annex\git-annex-tmp\Config.o )
+[109 of 217] Compiling Annex.UUID       ( Annex\UUID.hs, dist\build\git-annex\git-annex-tmp\Annex\UUID.o )
+[110 of 217] Compiling Backend          ( Backend.hs, dist\build\git-annex\git-annex-tmp\Backend.o )
+[111 of 217] Compiling Annex.Version    ( Annex\Version.hs, dist\build\git-annex\git-annex-tmp\Annex\Version.o )
+[112 of 217] Compiling Annex.Perms      ( Annex\Perms.hs, dist\build\git-annex\git-annex-tmp\Annex\Perms.o )
+[113 of 217] Compiling Logs.Transfer    ( Logs\Transfer.hs, dist\build\git-annex\git-annex-tmp\Logs\Transfer.o )
+
+Logs\Transfer.hs:126:20: Warning: Defined but not used: `mode'
+
+Logs\Transfer.hs:146:29: Warning: Defined but not used: `fd'
+[114 of 217] Compiling Annex.ReplaceFile ( Annex\ReplaceFile.hs, dist\build\git-annex\git-annex-tmp\Annex\ReplaceFile.o )
+[115 of 217] Compiling Annex.Journal    ( Annex\Journal.hs, dist\build\git-annex\git-annex-tmp\Annex\Journal.o )
+
+Annex\Journal.hs:89:23: Warning: Defined but not used: `mode'
+[116 of 217] Compiling Annex.Branch     ( Annex\Branch.hs, dist\build\git-annex\git-annex-tmp\Annex\Branch.o )
+[117 of 217] Compiling Logs.Remote      ( Logs\Remote.hs, dist\build\git-annex\git-annex-tmp\Logs\Remote.o )
+[118 of 217] Compiling Logs.Presence    ( Logs\Presence.hs, dist\build\git-annex\git-annex-tmp\Logs\Presence.o )
+[119 of 217] Compiling Logs.UUID        ( Logs\UUID.hs, dist\build\git-annex\git-annex-tmp\Logs\UUID.o )
+[120 of 217] Compiling Logs.Location    ( Logs\Location.hs, dist\build\git-annex\git-annex-tmp\Logs\Location.o )
+[121 of 217] Compiling Annex.Content.Direct ( Annex\Content\Direct.hs, dist\build\git-annex\git-annex-tmp\Annex\Content\Direct.o )
+[122 of 217] Compiling Annex.Content    ( Annex\Content.hs, dist\build\git-annex\git-annex-tmp\Annex\Content.o )
+
+Annex\Content.hs:50:1: Warning:
+    The import of `Annex.Exception' is redundant
+      except perhaps to import instances from `Annex.Exception'
+    To import instances alone, use: import Annex.Exception()
+
+Annex\Content.hs:89:21: Warning: Defined but not used: `f'
+
+Annex\Content.hs:96:21: Warning: Defined but not used: `h'
+
+Annex\Content.hs:106:9: Warning: Defined but not used: `is_locked'
+
+Annex\Content.hs:113:13: Warning: Defined but not used: `key'
+[123 of 217] Compiling Annex.Direct     ( Annex\Direct.hs, dist\build\git-annex\git-annex-tmp\Annex\Direct.o )
+[124 of 217] Compiling Init             ( Init.hs, dist\build\git-annex\git-annex-tmp\Init.o )
+
+Init.hs:29:1: Warning:
+    The import of `Utility.UserInfo' is redundant
+      except perhaps to import instances from `Utility.UserInfo'
+    To import instances alone, use: import Utility.UserInfo()
+
+Init.hs:31:1: Warning:
+    The import of `Utility.FileMode' is redundant
+      except perhaps to import instances from `Utility.FileMode'
+    To import instances alone, use: import Utility.FileMode()
+[125 of 217] Compiling Logs.Web         ( Logs\Web.hs, dist\build\git-annex\git-annex-tmp\Logs\Web.o )
+[126 of 217] Compiling Logs.Group       ( Logs\Group.hs, dist\build\git-annex\git-annex-tmp\Logs\Group.o )
+[127 of 217] Compiling Upgrade.V2       ( Upgrade\V2.hs, dist\build\git-annex\git-annex-tmp\Upgrade\V2.o )
+[128 of 217] Compiling Upgrade          ( Upgrade.hs, dist\build\git-annex\git-annex-tmp\Upgrade.o )
+[129 of 217] Compiling Creds            ( Creds.hs, dist\build\git-annex\git-annex-tmp\Creds.o )
+
+Creds.hs:18:1: Warning:
+    The import of `Utility.Env' is redundant
+      except perhaps to import instances from `Utility.Env'
+    To import instances alone, use: import Utility.Env()
+[130 of 217] Compiling Remote.Helper.AWS ( Remote\Helper\AWS.hs, dist\build\git-annex\git-annex-tmp\Remote\Helper\AWS.o )
+[131 of 217] Compiling Annex.LockPool   ( Annex\LockPool.hs, dist\build\git-annex\git-annex-tmp\Annex\LockPool.o )
+
+Annex\LockPool.hs:17:1: Warning:
+    The import of `Annex.Perms' is redundant
+      except perhaps to import instances from `Annex.Perms'
+    To import instances alone, use: import Annex.Perms()
+
+Annex\LockPool.hs:39:12: Warning: Defined but not used: `fd'
+[132 of 217] Compiling Remote.Helper.Hooks ( Remote\Helper\Hooks.hs, dist\build\git-annex\git-annex-tmp\Remote\Helper\Hooks.o )
+
+Remote\Helper\Hooks.hs:18:1: Warning:
+    The import of `Annex.Perms' is redundant
+      except perhaps to import instances from `Annex.Perms'
+    To import instances alone, use: import Annex.Perms()
+
+Remote\Helper\Hooks.hs:74:17: Warning: Defined but not used: `lck'
+[133 of 217] Compiling Remote.S3        ( Remote\S3.hs, dist\build\git-annex\git-annex-tmp\Remote\S3.o )
+[134 of 217] Compiling Remote.Directory ( Remote\Directory.hs, dist\build\git-annex\git-annex-tmp\Remote\Directory.o )
+[135 of 217] Compiling Remote.Web       ( Remote\Web.hs, dist\build\git-annex\git-annex-tmp\Remote\Web.o )
+[136 of 217] Compiling Remote.WebDAV    ( Remote\WebDAV.hs, dist\build\git-annex\git-annex-tmp\Remote\WebDAV.o )
+[137 of 217] Compiling Remote.Glacier   ( Remote\Glacier.hs, dist\build\git-annex\git-annex-tmp\Remote\Glacier.o )
+[138 of 217] Compiling Remote.Hook      ( Remote\Hook.hs, dist\build\git-annex\git-annex-tmp\Remote\Hook.o )
+[139 of 217] Compiling Annex.Ssh        ( Annex\Ssh.hs, dist\build\git-annex\git-annex-tmp\Annex\Ssh.o )
+
+Annex\Ssh.hs:21:1: Warning:
+    The import of `Annex.Perms' is redundant
+      except perhaps to import instances from `Annex.Perms'
+    To import instances alone, use: import Annex.Perms()
+[140 of 217] Compiling Remote.Rsync     ( Remote\Rsync.hs, dist\build\git-annex\git-annex-tmp\Remote\Rsync.o )
+[141 of 217] Compiling Remote.Helper.Ssh ( Remote\Helper\Ssh.hs, dist\build\git-annex\git-annex-tmp\Remote\Helper\Ssh.o )
+[142 of 217] Compiling Remote.Git       ( Remote\Git.hs, dist\build\git-annex\git-annex-tmp\Remote\Git.o )
+
+Remote\Git.hs:20:1: Warning:
+    The import of `Utility.CopyFile' is redundant
+      except perhaps to import instances from `Utility.CopyFile'
+    To import instances alone, use: import Utility.CopyFile()
+
+Remote\Git.hs:360:21: Warning: Defined but not used: `r'
+
+Remote\Git.hs:360:23: Warning: Defined but not used: `key'
+
+Remote\Git.hs:360:27: Warning: Defined but not used: `file'
+[143 of 217] Compiling Remote.Bup       ( Remote\Bup.hs, dist\build\git-annex\git-annex-tmp\Remote\Bup.o )
+[144 of 217] Compiling Remote.List      ( Remote\List.hs, dist\build\git-annex\git-annex-tmp\Remote\List.o )
+[145 of 217] Compiling Logs.Trust       ( Logs\Trust.hs, dist\build\git-annex\git-annex-tmp\Logs\Trust.o )
+[146 of 217] Compiling Remote           ( Remote.hs, dist\build\git-annex\git-annex-tmp\Remote.o )
+[147 of 217] Compiling Limit            ( Limit.hs, dist\build\git-annex\git-annex-tmp\Limit.o )
+[148 of 217] Compiling Option           ( Option.hs, dist\build\git-annex\git-annex-tmp\Option.o )
+[149 of 217] Compiling Annex.FileMatcher ( Annex\FileMatcher.hs, dist\build\git-annex\git-annex-tmp\Annex\FileMatcher.o )
+[150 of 217] Compiling Logs.PreferredContent ( Logs\PreferredContent.hs, dist\build\git-annex\git-annex-tmp\Logs\PreferredContent.o )
+[151 of 217] Compiling Annex.Wanted     ( Annex\Wanted.hs, dist\build\git-annex\git-annex-tmp\Annex\Wanted.o )
+[152 of 217] Compiling Seek             ( Seek.hs, dist\build\git-annex\git-annex-tmp\Seek.o )
+[153 of 217] Compiling Checks           ( Checks.hs, dist\build\git-annex\git-annex-tmp\Checks.o )
+[154 of 217] Compiling Command          ( Command.hs, dist\build\git-annex\git-annex-tmp\Command.o )
+[155 of 217] Compiling Logs.Unused      ( Logs\Unused.hs, dist\build\git-annex\git-annex-tmp\Logs\Unused.o )
+[156 of 217] Compiling CmdLine          ( CmdLine.hs, dist\build\git-annex\git-annex-tmp\CmdLine.o )
+[157 of 217] Compiling Command.ConfigList ( Command\ConfigList.hs, dist\build\git-annex\git-annex-tmp\Command\ConfigList.o )
+[158 of 217] Compiling Command.InAnnex  ( Command\InAnnex.hs, dist\build\git-annex\git-annex-tmp\Command\InAnnex.o )
+[159 of 217] Compiling Command.DropKey  ( Command\DropKey.hs, dist\build\git-annex\git-annex-tmp\Command\DropKey.o )
+[160 of 217] Compiling Command.SendKey  ( Command\SendKey.hs, dist\build\git-annex\git-annex-tmp\Command\SendKey.o )
+[161 of 217] Compiling Command.RecvKey  ( Command\RecvKey.hs, dist\build\git-annex\git-annex-tmp\Command\RecvKey.o )
+[162 of 217] Compiling Command.TransferInfo ( Command\TransferInfo.hs, dist\build\git-annex\git-annex-tmp\Command\TransferInfo.o )
+[163 of 217] Compiling Command.Commit   ( Command\Commit.hs, dist\build\git-annex\git-annex-tmp\Command\Commit.o )
+[164 of 217] Compiling GitAnnex.Options ( GitAnnex\Options.hs, dist\build\git-annex\git-annex-tmp\GitAnnex\Options.o )
+[165 of 217] Compiling Command.Unannex  ( Command\Unannex.hs, dist\build\git-annex\git-annex-tmp\Command\Unannex.o )
+[166 of 217] Compiling Command.FromKey  ( Command\FromKey.hs, dist\build\git-annex\git-annex-tmp\Command\FromKey.o )
+[167 of 217] Compiling Command.Fix      ( Command\Fix.hs, dist\build\git-annex\git-annex-tmp\Command\Fix.o )
+[168 of 217] Compiling Command.Init     ( Command\Init.hs, dist\build\git-annex\git-annex-tmp\Command\Init.o )
+[169 of 217] Compiling Command.Describe ( Command\Describe.hs, dist\build\git-annex\git-annex-tmp\Command\Describe.o )
+[170 of 217] Compiling Command.InitRemote ( Command\InitRemote.hs, dist\build\git-annex\git-annex-tmp\Command\InitRemote.o )
+[171 of 217] Compiling Command.EnableRemote ( Command\EnableRemote.hs, dist\build\git-annex\git-annex-tmp\Command\EnableRemote.o )
+[172 of 217] Compiling Command.Unused   ( Command\Unused.hs, dist\build\git-annex\git-annex-tmp\Command\Unused.o )
+[173 of 217] Compiling Command.Unlock   ( Command\Unlock.hs, dist\build\git-annex\git-annex-tmp\Command\Unlock.o )
+[174 of 217] Compiling Command.Lock     ( Command\Lock.hs, dist\build\git-annex\git-annex-tmp\Command\Lock.o )
+[175 of 217] Compiling Command.Find     ( Command\Find.hs, dist\build\git-annex\git-annex-tmp\Command\Find.o )
+[176 of 217] Compiling Command.Whereis  ( Command\Whereis.hs, dist\build\git-annex\git-annex-tmp\Command\Whereis.o )
+[177 of 217] Compiling Command.Log      ( Command\Log.hs, dist\build\git-annex\git-annex-tmp\Command\Log.o )
+[178 of 217] Compiling Command.Merge    ( Command\Merge.hs, dist\build\git-annex\git-annex-tmp\Command\Merge.o )
+[179 of 217] Compiling Command.Uninit   ( Command\Uninit.hs, dist\build\git-annex\git-annex-tmp\Command\Uninit.o )
+[180 of 217] Compiling Command.Trust    ( Command\Trust.hs, dist\build\git-annex\git-annex-tmp\Command\Trust.o )
+[181 of 217] Compiling Command.Untrust  ( Command\Untrust.hs, dist\build\git-annex\git-annex-tmp\Command\Untrust.o )
+[182 of 217] Compiling Command.Semitrust ( Command\Semitrust.hs, dist\build\git-annex\git-annex-tmp\Command\Semitrust.o )
+[183 of 217] Compiling Command.Dead     ( Command\Dead.hs, dist\build\git-annex\git-annex-tmp\Command\Dead.o )
+[184 of 217] Compiling Command.Group    ( Command\Group.hs, dist\build\git-annex\git-annex-tmp\Command\Group.o )
+[185 of 217] Compiling Command.Content  ( Command\Content.hs, dist\build\git-annex\git-annex-tmp\Command\Content.o )
+[186 of 217] Compiling Command.Ungroup  ( Command\Ungroup.hs, dist\build\git-annex\git-annex-tmp\Command\Ungroup.o )
+[187 of 217] Compiling Command.Vicfg    ( Command\Vicfg.hs, dist\build\git-annex\git-annex-tmp\Command\Vicfg.o )
+[188 of 217] Compiling Command.RmUrl    ( Command\RmUrl.hs, dist\build\git-annex\git-annex-tmp\Command\RmUrl.o )
+[189 of 217] Compiling Command.Map      ( Command\Map.hs, dist\build\git-annex\git-annex-tmp\Command\Map.o )
+[190 of 217] Compiling Command.Upgrade  ( Command\Upgrade.hs, dist\build\git-annex\git-annex-tmp\Command\Upgrade.o )
+[191 of 217] Compiling Command.Version  ( Command\Version.hs, dist\build\git-annex\git-annex-tmp\Command\Version.o )
+[192 of 217] Compiling Command.Test     ( Command\Test.hs, dist\build\git-annex\git-annex-tmp\Command\Test.o )
+[193 of 217] Compiling Command.Add      ( Command\Add.hs, dist\build\git-annex\git-annex-tmp\Command\Add.o )
+[194 of 217] Compiling Command.ReKey    ( Command\ReKey.hs, dist\build\git-annex\git-annex-tmp\Command\ReKey.o )
+[195 of 217] Compiling Command.AddUnused ( Command\AddUnused.hs, dist\build\git-annex\git-annex-tmp\Command\AddUnused.o )
+[196 of 217] Compiling Command.PreCommit ( Command\PreCommit.hs, dist\build\git-annex\git-annex-tmp\Command\PreCommit.o )
+[197 of 217] Compiling Command.Import   ( Command\Import.hs, dist\build\git-annex\git-annex-tmp\Command\Import.o )
+[198 of 217] Compiling Command.Drop     ( Command\Drop.hs, dist\build\git-annex\git-annex-tmp\Command\Drop.o )
+[199 of 217] Compiling Command.Move     ( Command\Move.hs, dist\build\git-annex\git-annex-tmp\Command\Move.o )
+[200 of 217] Compiling Command.Copy     ( Command\Copy.hs, dist\build\git-annex\git-annex-tmp\Command\Copy.o )
+[201 of 217] Compiling Command.Get      ( Command\Get.hs, dist\build\git-annex\git-annex-tmp\Command\Get.o )
+[202 of 217] Compiling Command.TransferKey ( Command\TransferKey.hs, dist\build\git-annex\git-annex-tmp\Command\TransferKey.o )
+[203 of 217] Compiling Command.DropUnused ( Command\DropUnused.hs, dist\build\git-annex\git-annex-tmp\Command\DropUnused.o )
+[204 of 217] Compiling Command.Fsck     ( Command\Fsck.hs, dist\build\git-annex\git-annex-tmp\Command\Fsck.o )
+[205 of 217] Compiling Command.Reinject ( Command\Reinject.hs, dist\build\git-annex\git-annex-tmp\Command\Reinject.o )
+[206 of 217] Compiling Command.Migrate  ( Command\Migrate.hs, dist\build\git-annex\git-annex-tmp\Command\Migrate.o )
+[207 of 217] Compiling Command.Status   ( Command\Status.hs, dist\build\git-annex\git-annex-tmp\Command\Status.o )
+[208 of 217] Compiling Command.Sync     ( Command\Sync.hs, dist\build\git-annex\git-annex-tmp\Command\Sync.o )
+[209 of 217] Compiling Command.Help     ( Command\Help.hs, dist\build\git-annex\git-annex-tmp\Command\Help.o )
+[210 of 217] Compiling Command.AddUrl   ( Command\AddUrl.hs, dist\build\git-annex\git-annex-tmp\Command\AddUrl.o )
+[211 of 217] Compiling Command.Direct   ( Command\Direct.hs, dist\build\git-annex\git-annex-tmp\Command\Direct.o )
+[212 of 217] Compiling Command.Indirect ( Command\Indirect.hs, dist\build\git-annex\git-annex-tmp\Command\Indirect.o )
+[213 of 217] Compiling Command.FuzzTest ( Command\FuzzTest.hs, dist\build\git-annex\git-annex-tmp\Command\FuzzTest.o )
+[214 of 217] Compiling Test             ( Test.hs, dist\build\git-annex\git-annex-tmp\Test.o )
+[215 of 217] Compiling GitAnnexShell    ( GitAnnexShell.hs, dist\build\git-annex\git-annex-tmp\GitAnnexShell.o )
+[216 of 217] Compiling GitAnnex         ( GitAnnex.hs, dist\build\git-annex\git-annex-tmp\GitAnnex.o )
+[217 of 217] Compiling Main             ( git-annex.hs, dist\build\git-annex\git-annex-tmp\Main.o )
+Linking dist\build\git-annex\git-annex.exe ...
++ cabal install nsis
+Resolving dependencies...
+All the requested packages are already installed:
+nsis-0.2.2
+Use --reinstall if you want to reinstall anyway.
++ ghc --make Build/NullSoftInstaller.hs
+[15 of 18] Compiling Build.SysConfig  ( Build\SysConfig.hs, Build\SysConfig.o )
+Linking Build\NullSoftInstaller.exe ...
++ withcyg Build/NullSoftInstaller.exe
++ PATH='/c/Program Files (x86)/Haskell Platform/2012.4.0.0/bin:/c/Program Files (x86)/Haskell Platform/2012.4.0.0/lib/extralibs/bin:/c/Program Files (x86)/NSIS:/home/Oliver/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files (x86)/Haskell/bin:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/lib/extralibs/bin:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin:/c/Program Files (x86)/AMD APP/bin/x86_64:/c/Program Files (x86)/AMD APP/bin/x86:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files (x86)/ATI Technologies/ATI.ACE/Core-Static:/c/Program Files (x86)/Windows Kits/8.0/Windows Performance Toolkit/:/c/Program Files/Microsoft/Web Platform Installer/:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/mingw/bin:/c/Users/Oliver/AppData/Roaming/cabal/bin:/c/cygwin/bin'
++ Build/NullSoftInstaller.exe
+MakeNSIS v2.46 - Copyright 1995-2009 Contributors
+See the file COPYING for license details.
+Credits can be found in the Users Manual.
+
+Processing config: 
+Processing plugin dlls: "c:\Program Files (x86)\NSIS\Plugins\*.dll"
+ - AdvSplash::show
+ - Banner::destroy
+ - Banner::getWindow
+ - Banner::show
+ - BgImage::AddImage
+ - BgImage::AddText
+ - BgImage::Clear
+ - BgImage::Destroy
+ - BgImage::Redraw
+ - BgImage::SetBg
+ - BgImage::SetReturn
+ - BgImage::Sound
+ - Dialer::AttemptConnect
+ - Dialer::AutodialHangup
+ - Dialer::AutodialOnline
+ - Dialer::AutodialUnattended
+ - Dialer::GetConnectedState
+ - InstallOptions::dialog
+ - InstallOptions::initDialog
+ - InstallOptions::show
+ - LangDLL::LangDialog
+ - Math::Script
+ - NSISdl::download
+ - NSISdl::download_quiet
+ - Splash::show
+ - StartMenu::Init
+ - StartMenu::Select
+ - StartMenu::Show
+ - System::Alloc
+ - System::Call
+ - System::Copy
+ - System::Free
+ - System::Get
+ - System::Int64Op
+ - System::Store
+ - TypeLib::GetLibVersion
+ - TypeLib::Register
+ - TypeLib::UnRegister
+ - UserInfo::GetAccountType
+ - UserInfo::GetName
+ - UserInfo::GetOriginalAccountType
+ - VPatch::GetFileCRC32
+ - VPatch::GetFileMD5
+ - VPatch::vpatchfile
+ - nsDialogs::Create
+ - nsDialogs::CreateControl
+ - nsDialogs::CreateItem
+ - nsDialogs::CreateTimer
+ - nsDialogs::GetUserData
+ - nsDialogs::KillTimer
+ - nsDialogs::OnBack
+ - nsDialogs::OnChange
+ - nsDialogs::OnClick
+ - nsDialogs::OnNotify
+ - nsDialogs::SelectFileDialog
+ - nsDialogs::SelectFolderDialog
+ - nsDialogs::SetRTL
+ - nsDialogs::SetUserData
+ - nsDialogs::Show
+ - nsExec::Exec
+ - nsExec::ExecToLog
+ - nsExec::ExecToStack
+
+!define: "MUI_INSERT_NSISCONF"=""
+
+Changing directory to: "C:\MinGW\msys\1.0\home\Oliver\src\git-annex"
+
+Processing script file: "git-annex.nsi"
+!include: "c:\Program Files (x86)\NSIS\Include\MUI2.nsh"
+!include: "c:\Program Files (x86)\NSIS\Contrib\Modern UI 2\MUI2.nsh"
+NSIS Modern User Interface version 2.0 - Copyright 2002-2009 Joost Verburg (c:\Program Files (x86)\NSIS\Contrib\Modern UI 2\MUI2.nsh:8)
+!define: "MUI_INCLUDED"=""
+!define: "MUI_SYSVERSION"="2.0"
+!define: "MUI_VERBOSE"="3"
+!include: closed: "c:\Program Files (x86)\NSIS\Contrib\Modern UI 2\MUI2.nsh"
+!include: closed: "c:\Program Files (x86)\NSIS\Include\MUI2.nsh"
+Name: "git-annex"
+OutFile: "git-annex-installer.exe"
+InstallDir: "$PROGRAMFILES\Git\cmd"
+!insertmacro: MUI_PAGE_DIRECTORY
+!insertmacro: end of MUI_PAGE_DIRECTORY
+!insertmacro: MUI_PAGE_LICENSE
+!insertmacro: end of MUI_PAGEDECLARATION_LICENSE
+!insertmacro: end of MUI_PAGE_LICENSE
+!insertmacro: MUI_PAGE_INSTFILES
+!insertmacro: end of MUI_PAGE_INSTFILES
+!insertmacro: MUI_LANGUAGE
+!insertmacro: end of MUI_LANGUAGE
+Section: "main" ->(_sec10)
+SetOutPath: "$INSTDIR"
+File: "git-annex.exe" [compress] 7664822/31704766 bytes
+File: "git-annex-licenses.txt" [compress] 60509/237415 bytes
+File: "cp.exe" [compress] 62591/116736 bytes
+File: "xargs.exe" [compress] 17002/33280 bytes
+File: "rsync.exe" [compress] 188346/359424 bytes
+File: "ssh.exe" [compress] 157190/320000 bytes
+File: "wget.exe" [compress] 155666/349184 bytes
+File: "sha1sum.exe" [compress] 20337/39424 bytes
+File: "sha256sum.exe" [compress] 18279/37390 bytes
+File: "sha512sum.exe" [compress] 30393/92174 bytes
+File: "sha224sum.exe" [compress] 18279/37390 bytes
+File: "sha384sum.exe" [compress] 30392/92174 bytes
+File: "cygwin1.dll" [compress] 1036075/2874639 bytes
+File: "cygasn1-8.dll" [compress] 154881/459293 bytes
+File: "cygattr-1.dll" [compress] 5460/13838 bytes
+File: "cygheimbase-1.dll" [compress] 4441/10781 bytes
+File: "cygroken-18.dll" [compress] 26103/52253 bytes
+File: "cygcom_err-2.dll" [compress] 3984/9757 bytes
+File: "cygheimntlm-0.dll" [compress] 9018/20509 bytes
+File: "cygsqlite3-0.dll" [compress] 334366/601629 bytes
+File: "cygcrypt-0.dll" [compress] 3352/7182 bytes
+File: "cyghx509-5.dll" [compress] 95839/216093 bytes
+File: "cygssp-0.dll" [compress] 3377/8206 bytes
+File: "cygcrypto-1.0.0.dll" [compress] 652766/1553920 bytes
+File: "cygiconv-2.dll" [compress] 738899/1008654 bytes
+File: "cyggcc_s-1.dll" [compress] 40241/80910 bytes
+File: "cygintl-8.dll" [compress] 17737/35342 bytes
+File: "cygwind-0.dll" [compress] 73172/160797 bytes
+File: "cyggssapi-3.dll" [compress] 81662/183837 bytes
+File: "cygkrb5-26.dll" [compress] 170204/381469 bytes
+File: "cygz.dll" [compress] 42634/74269 bytes
+WriteUninstaller: "git-annex-uninstall.exe"
+SectionEnd
+Section: "Uninstall" ->(_sec11)
+Delete: /REBOOTOK "$INSTDIR\git-annex.exe"
+Delete: /REBOOTOK "$INSTDIR\git-annex-licenses.txt"
+Delete: /REBOOTOK "$INSTDIR\git-annex-uninstall.exe"
+Delete: /REBOOTOK "$INSTDIR\cp.exe"
+Delete: /REBOOTOK "$INSTDIR\xargs.exe"
+Delete: /REBOOTOK "$INSTDIR\rsync.exe"
+Delete: /REBOOTOK "$INSTDIR\ssh.exe"
+Delete: /REBOOTOK "$INSTDIR\wget.exe"
+Delete: /REBOOTOK "$INSTDIR\sha1sum.exe"
+Delete: /REBOOTOK "$INSTDIR\sha256sum.exe"
+Delete: /REBOOTOK "$INSTDIR\sha512sum.exe"
+Delete: /REBOOTOK "$INSTDIR\sha224sum.exe"
+Delete: /REBOOTOK "$INSTDIR\sha384sum.exe"
+Delete: /REBOOTOK "$INSTDIR\cygwin1.dll"
+Delete: /REBOOTOK "$INSTDIR\cygasn1-8.dll"
+Delete: /REBOOTOK "$INSTDIR\cygattr-1.dll"
+Delete: /REBOOTOK "$INSTDIR\cygheimbase-1.dll"
+Delete: /REBOOTOK "$INSTDIR\cygroken-18.dll"
+Delete: /REBOOTOK "$INSTDIR\cygcom_err-2.dll"
+Delete: /REBOOTOK "$INSTDIR\cygheimntlm-0.dll"
+Delete: /REBOOTOK "$INSTDIR\cygsqlite3-0.dll"
+Delete: /REBOOTOK "$INSTDIR\cygcrypt-0.dll"
+Delete: /REBOOTOK "$INSTDIR\cyghx509-5.dll"
+Delete: /REBOOTOK "$INSTDIR\cygssp-0.dll"
+Delete: /REBOOTOK "$INSTDIR\cygcrypto-1.0.0.dll"
+Delete: /REBOOTOK "$INSTDIR\cygiconv-2.dll"
+Delete: /REBOOTOK "$INSTDIR\cyggcc_s-1.dll"
+Delete: /REBOOTOK "$INSTDIR\cygintl-8.dll"
+Delete: /REBOOTOK "$INSTDIR\cygwind-0.dll"
+Delete: /REBOOTOK "$INSTDIR\cyggssapi-3.dll"
+Delete: /REBOOTOK "$INSTDIR\cygkrb5-26.dll"
+Delete: /REBOOTOK "$INSTDIR\cygz.dll"
+SectionEnd
+Function: ".onInit"
+IfFileExists: "$PROGRAMFILES\Git\cmd" ? _lbl3 : 0
+MessageBox: 48: "You need git installed to use git-annex. Looking at $PROGRAMFILES\Git\cmd , it seems to not be installed, or may be installed in another location. You can install git from http://git-scm.com/" (on IDOK goto 0)
+FunctionEnd
+
+Processed 1 file, writing output:
+Processing pages... Done!
+Removing unused resources... Done!
+Generating language tables... Done!
+Generating uninstaller... Done!
+
+Output: "C:\MinGW\msys\1.0\home\Oliver\src\git-annex\git-annex-installer.exe"
+Install: 4 pages (256 bytes), 1 section (1048 bytes), 98 instructions (2744 bytes), 133 strings (239643 bytes), 1 language table (278 bytes).
+Uninstall: 2 pages (128 bytes), 
+1 section (1048 bytes), 33 instructions (924 bytes), 72 strings (1154 bytes), 1 language table (194 bytes).
+
+Using zlib compression.
+
+EXE header size:               48640 / 35840 bytes
+Install code:                  63270 / 244345 bytes
+Install data:               11918141 / 41172867 bytes
+Uninstall code+data:           10537 / 14897 bytes
+CRC (0x090A4FD3):                  4 / 4 bytes
+
+Total size:                 12040592 / 41467953 bytes (29.0%)
++ rm -f last-incremental-failed
++ rm -rf .t
++ withcyg dist/build/git-annex/git-annex.exe test
++ PATH='/c/Program Files (x86)/Haskell Platform/2012.4.0.0/bin:/c/Program Files (x86)/Haskell Platform/2012.4.0.0/lib/extralibs/bin:/c/Program Files (x86)/NSIS:/home/Oliver/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files (x86)/Haskell/bin:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/lib/extralibs/bin:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin:/c/Program Files (x86)/AMD APP/bin/x86_64:/c/Program Files (x86)/AMD APP/bin/x86:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files (x86)/ATI Technologies/ATI.ACE/Core-Static:/c/Program Files (x86)/Windows Kits/8.0/Windows Performance Toolkit/:/c/Program Files/Microsoft/Web Platform Installer/:/c/Program Files (x86)/Haskell Platform/2013.2.0.0/mingw/bin:/c/Users/Oliver/AppData/Roaming/cabal/bin:/c/cygwin/bin'
++ dist/build/git-annex/git-annex.exe test
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          ----------------------------------------------------------------------
+First, some automated quick checks of properties ...
+----------------------------------------------------------------------
+prop_idempotent_deencode_git
++++ OK, passed 100 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_idempotent_deencode
++++ OK, passed 100 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_idempotent_fileKey
++++ OK, passed 100 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_idempotent_key_encode
++++ OK, passed 100 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_idempotent_shellEscape
++++ OK, passed 100 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_idempotent_shellEscape_multiword
++++ OK, passed 100 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_idempotent_configEscape
++++ OK, passed 100 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_parse_show_Config
++++ OK, passed 100 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_parentDir_basics
++++ OK, passed 100 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_relPathDirToFile_basics
++++ OK, passed 100 tests.
+(0 tests)         prop_relPathDirToFile_regressionTest
++++ OK, passed 1 tests.
+(0 tests)         prop_cost_sane
++++ OK, passed 1 tests.
+(0 tests)         prop_matcher_sane
++++ OK, passed 1 tests.
+(0 tests)         prop_HmacSha1WithCipher_sane
++++ OK, passed 1 tests.
+(0 tests)         prop_TimeStamp_sane
++++ OK, passed 1 tests.
+(0 tests)         prop_addLog_sane
++++ OK, passed 1 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_verifiable_sane
++++ OK, passed 100 tests.
+(0 tests)         prop_segment_regressionTest
++++ OK, passed 1 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_read_write_transferinfo
++++ OK, passed 100 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_read_show_inodecache
++++ OK, passed 100 tests.
+(0 tests)         (1 test)        (2 tests)         (3 tests)         (4 tests)         (5 tests)         (6 tests)         (7 tests)         (8 tests)         (9 tests)         (10 tests)          (11 tests)          (12 tests)          (13 tests)          (14 tests)          (15 tests)          (16 tests)          (17 tests)          (18 tests)          (19 tests)          (20 tests)          (21 tests)          (22 tests)          (23 tests)          (24 tests)          (25 tests)          (26 tests)          (27 tests)          (28 tests)          (29 tests)          (30 tests)          (31 tests)          (32 tests)          (33 tests)          (34 tests)          (35 tests)          (36 tests)          (37 tests)          (38 tests)          (39 tests)          (40 tests)          (41 tests)          (42 tests)          (43 tests)          (44 tests)          (45 tests)          (46 tests)          (47 tests)          (48 tests)          (49 tests)          (50 tests)          (51 tests)          (52 tests)          (53 tests)          (54 tests)          (55 tests)          (56 tests)          (57 tests)          (58 tests)          (59 tests)          (60 tests)          (61 tests)          (62 tests)          (63 tests)          (64 tests)          (65 tests)          (66 tests)          (67 tests)          (68 tests)          (69 tests)          (70 tests)          (71 tests)          (72 tests)          (73 tests)          (74 tests)          (75 tests)          (76 tests)          (77 tests)          (78 tests)          (79 tests)          (80 tests)          (81 tests)          (82 tests)          (83 tests)          (84 tests)          (85 tests)          (86 tests)          (87 tests)          (88 tests)          (89 tests)          (90 tests)          (91 tests)          (92 tests)          (93 tests)          (94 tests)          (95 tests)          (96 tests)          (97 tests)          (98 tests)          (99 tests)          prop_parse_show_log
++++ OK, passed 100 tests.
+(0 tests)         prop_read_show_TrustLevel
++++ OK, passed 1 tests.
+(0 tests)         prop_parse_show_TrustLog
++++ OK, passed 1 tests.
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0init test repo 
+  Detected a crippled filesystem.
+
+  Disabling core.symlinks.
+
+  Enabling direct mode.
+
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+ok
+(Recording state in git...)
+
+                                          
+Cases: 1  Tried: 1  Errors: 0  Failures: 0
+
+Cases: 3  Tried: 0  Errors: 0  Failures: 0add foo (checksum...) ok
+(Recording state in git...)
+add sha1foo (checksum...) ok
+(Recording state in git...)
+add apple ok
+(Recording state in git...)
+
+Cases: 3  Tried: 1  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex add:1
+git clone failed
+
+Cases: 3  Tried: 2  Errors: 0  Failures: 1ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex add:2
+git clone failed
+Cases: 3  Tried: 3  Errors: 0  Failures: 2
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex reinject/fromkey
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 2  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex unannex:0:no content
+git clone failed
+
+Cases: 2  Tried: 1  Errors: 0  Failures: 1ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex unannex:1:with content
+git clone failed
+Cases: 2  Tried: 2  Errors: 0  Failures: 2
+
+Cases: 3  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex drop:0:no remotes
+git clone failed
+
+Cases: 3  Tried: 1  Errors: 0  Failures: 1ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex drop:1:with remote
+git clone failed
+
+Cases: 3  Tried: 2  Errors: 0  Failures: 2ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex drop:2:untrusted remote
+git clone failed
+Cases: 3  Tried: 3  Errors: 0  Failures: 3
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex get
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex move
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex copy
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex unlock/lock
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 2  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex edit/commit:0
+git clone failed
+
+Cases: 2  Tried: 1  Errors: 0  Failures: 1ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex edit/commit:1
+git clone failed
+Cases: 2  Tried: 2  Errors: 0  Failures: 2
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex fix
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex trust/untrust/semitrust/dead
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 4  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex fsck:0
+git clone failed
+
+Cases: 4  Tried: 1  Errors: 0  Failures: 1ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex fsck:1
+git clone failed
+
+Cases: 4  Tried: 2  Errors: 0  Failures: 2ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex fsck:2
+git clone failed
+
+Cases: 4  Tried: 3  Errors: 0  Failures: 3ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex fsck:3
+git clone failed
+Cases: 4  Tried: 4  Errors: 0  Failures: 4
+
+Cases: 2  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex migrate:0
+git clone failed
+
+Cases: 2  Tried: 1  Errors: 0  Failures: 1ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex migrate:1
+git clone failed
+Cases: 2  Tried: 2  Errors: 0  Failures: 2
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex unused/dropunused
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex describe
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex find
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex merge
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex status
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex version
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex sync
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: union merge regression
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: automatic conflict resolution
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex map
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex uninit
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex upgrade
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex whereis
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex hook remote
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex directory remote
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex rsync remote
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex bup remote
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex crypto
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+
+Cases: 1  Tried: 0  Errors: 0  Failures: 0ssh: Could not resolve hostname C: no address associated with name
+fatal: The remote end hung up unexpectedly
+
+                                          
+### Failure in: git-annex preferred-content
+git clone failed
+Cases: 1  Tried: 1  Errors: 0  Failures: 1
+----------------------------------------------------------------------
+Now, some broader checks ...
+  (Do not be alarmed by odd output here; it's normal.
+   wait for the last line to see how it went.)
+----------------------------------------------------------------------
+init
+----------------------------------------------------------------------
+add
+----------------------------------------------------------------------
+reinject
+----------------------------------------------------------------------
+unannex
+----------------------------------------------------------------------
+drop
+----------------------------------------------------------------------
+get
+----------------------------------------------------------------------
+move
+----------------------------------------------------------------------
+copy
+----------------------------------------------------------------------
+lock
+----------------------------------------------------------------------
+edit
+----------------------------------------------------------------------
+fix
+----------------------------------------------------------------------
+trust
+----------------------------------------------------------------------
+fsck
+----------------------------------------------------------------------
+migrate
+----------------------------------------------------------------------
+ unused
+----------------------------------------------------------------------
+describe
+----------------------------------------------------------------------
+find
+----------------------------------------------------------------------
+merge
+----------------------------------------------------------------------
+status
+----------------------------------------------------------------------
+version
+----------------------------------------------------------------------
+sync
+----------------------------------------------------------------------
+union merge regression
+----------------------------------------------------------------------
+conflict resolution
+----------------------------------------------------------------------
+map
+----------------------------------------------------------------------
+uninit
+----------------------------------------------------------------------
+upgrade
+----------------------------------------------------------------------
+whereis
+----------------------------------------------------------------------
+hook remote
+----------------------------------------------------------------------
+directory remote
+----------------------------------------------------------------------
+rsync remote
+----------------------------------------------------------------------
+bup remote
+----------------------------------------------------------------------
+crypto
+----------------------------------------------------------------------
+preferred content
+----------------------------------------------------------------------
+Some tests failed!
+  (This could be due to a bug in git-annex, or an incompatibility
+   with utilities, such as git, installed on this system.)
+
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
+
+> Closing as this bug report is very old. [[done]] --[[Joey]]
diff --git a/doc/bugs/Windows_build_test_failures/comment_1_ea7523fdbafdc8be2971df52d9038826._comment b/doc/bugs/Windows_build_test_failures/comment_1_ea7523fdbafdc8be2971df52d9038826._comment
new file mode 100644
index 0000000000..dc09fb89b0
--- /dev/null
+++ b/doc/bugs/Windows_build_test_failures/comment_1_ea7523fdbafdc8be2971df52d9038826._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.2.134"
+ subject="comment 1"
+ date="2013-09-13T19:18:26Z"
+ content="""
+The Windows port has improved quite a lot since this bug was filed. Can you still reproduce it?
+
+If you install the pre-built git-annex for Windows, you can run `git annex test` to run the test suite.  Does that work? It works for some others on Windows.
+"""]]
diff --git a/doc/bugs/Windows_installer_includes_curl_and_wget__44___but_not_required_DLLs.mdwn b/doc/bugs/Windows_installer_includes_curl_and_wget__44___but_not_required_DLLs.mdwn
new file mode 100644
index 0000000000..a21813500e
--- /dev/null
+++ b/doc/bugs/Windows_installer_includes_curl_and_wget__44___but_not_required_DLLs.mdwn
@@ -0,0 +1,17 @@
+### Please describe the problem.
+On a default, clean install on Windows, annex get over HTTP fails, as neither wget nor curl have all necessary DLLs.
+
+### What steps will reproduce the problem?
+1. Install git from git-scm.org, and git-annex from git-annex.branchable.com.
+2. Don't install, or remove if installed, Cygwin.
+3. clone an annex over HTTP
+4. attempt to 'annex get' a file
+5. get dialog box, explaining missing DLLs.
+
+### What version of git-annex are you using? On what operating system?
+Windows 7.
+
+### Please provide any additional information below.
+Installing Cygwin and adding to path seems to fix issue.
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/Windows_installer_includes_curl_and_wget__44___but_not_required_DLLs/comment_1_a7bf0f027f2209e5632e292afd7214d0._comment b/doc/bugs/Windows_installer_includes_curl_and_wget__44___but_not_required_DLLs/comment_1_a7bf0f027f2209e5632e292afd7214d0._comment
new file mode 100644
index 0000000000..05639ef3a9
--- /dev/null
+++ b/doc/bugs/Windows_installer_includes_curl_and_wget__44___but_not_required_DLLs/comment_1_a7bf0f027f2209e5632e292afd7214d0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.254.222"
+ subject="comment 1"
+ date="2013-07-07T17:47:54Z"
+ content="""
+The Windows installer includes numerous DLLs from Cygwin. I have tested it in a non-cygwin environment and it seems to work for me, and for other users. At least generally.. perhaps it *is* missing something used by wget or curl?
+
+Can you please provide the names of the DLLs that seem to be missing?
+"""]]
diff --git a/doc/bugs/Wrong_permission_when_using_shared_repository.mdwn b/doc/bugs/Wrong_permission_when_using_shared_repository.mdwn
new file mode 100644
index 0000000000..bcb217dd01
--- /dev/null
+++ b/doc/bugs/Wrong_permission_when_using_shared_repository.mdwn
@@ -0,0 +1,68 @@
+### Please describe the problem.
+I just found that the annexed files are at risk of being altered as far as I understand when the repository is shared with other users.
+
+### What steps will reproduce the problem?
+Go to a temporary location for these steps.
+[[!format sh """
+$ git init .
+$ git annex init main
+$ git config core.sharedRepository group
+$ echo foo > foo
+$ git annex add foo
+$ git annex sync
+"""]]
+
+One can verify the file in the annex (aka in `.git.annex/objects`) is writable by the user and group.
+
+[[!format sh """
+$ ls -l foo
+lrwxrwxrwx  1 christian christian 178 17. Aug 14:50 foo -> .git/annex/objects/91/9x/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c
+$ ls -lL foo
+-rw-rw-r-- 1 christian christian 4 17. Aug 16:03 foo
+"""]]
+
+This makes it possible to alter the file in the annex without notification or previous unlocking.
+
+[[!format sh """
+$ echo bar > foo
+$ git status
+On branch master
+nothing to commit, working tree clean
+"""]]
+
+My understanding is that the files in the annex should be read-only to prevent just this. Only by `git annex unlock` a full copy is generated that can be altered by external programs.
+
+### What version of git-annex are you using? On what operating system?
+```
+$ git annex version 
+git-annex version: 10.20220624-g17e4081d4
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime DebugLocks Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.11 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+```
+
+### Please provide any additional information below.
+
+The transcript is interleaved in the steps above.
+
+When repeating all steps but skipping the step `git config core.sharedRepository group`, the result is as expected:
+
+```
+$ ls -l foo
+lrwxrwxrwx 1 christian christian 178 17. Aug 16:22 foo -> .git/annex/objects/91/9x/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c
+$ ls -lL foo
+-r--r--r-- 1 christian christian 4 17. Aug 16:22 foo
+```
+
+My motivation here is the following: I want to use the git-annex as an (external) storage backend for my Nextcloud. That will allow me to store the files deduplicated and effectively manageable way. Also, I can use it to have multiple views on my files depending on the need. As the Nextcloud server user is different from my personal user, I need a way to allow both users access to the annex.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I have used git-annex in a single-user scenario yet. So far it works like a charm. I need more time to learn to get a hold of all functions but this is okay.
+
+> [[done]] in v10 --[[Joey]]
diff --git a/doc/bugs/Wrong_permission_when_using_shared_repository/comment_1_bfcb858bfd1c5377c2b15961b59a835a._comment b/doc/bugs/Wrong_permission_when_using_shared_repository/comment_1_bfcb858bfd1c5377c2b15961b59a835a._comment
new file mode 100644
index 0000000000..8050f6822c
--- /dev/null
+++ b/doc/bugs/Wrong_permission_when_using_shared_repository/comment_1_bfcb858bfd1c5377c2b15961b59a835a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-17T16:38:40Z"
+ content="""
+This was necessary to allow locking the object files.
+
+Repository v10 fixed that, so if you upgrade your repository, 
+you will no longer have this problem. Run `git-annex upgrade`.
+"""]]
diff --git a/doc/bugs/Wrong_permission_when_using_shared_repository/comment_2_e3c9e3b9004f1fe964b23d955083089b._comment b/doc/bugs/Wrong_permission_when_using_shared_repository/comment_2_e3c9e3b9004f1fe964b23d955083089b._comment
new file mode 100644
index 0000000000..16c4ec964c
--- /dev/null
+++ b/doc/bugs/Wrong_permission_when_using_shared_repository/comment_2_e3c9e3b9004f1fe964b23d955083089b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="account+annex@806a7c5f67b75d530bced4ea294c77681ebdf766"
+ nickname="account+annex"
+ avatar="http://cdn.libravatar.org/avatar/f325a5448e1b6c79c2998c69ea1435ae"
+ subject="comment 2"
+ date="2022-08-17T16:59:16Z"
+ content="""
+Yes, thank you for the hint. I had to use `--force`. This I found on the help page of the update subprocess.
+
+Thank you very much!
+"""]]
diff --git a/doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy.mdwn b/doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy.mdwn
new file mode 100644
index 0000000000..96b21ca057
--- /dev/null
+++ b/doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy.mdwn
@@ -0,0 +1,44 @@
+### Please describe the problem.
+
+Sometimes `git annex copy` complains with `git-annex: .git/HEAD: openFile: resource busy (file is locked)`. For example:
+
+```
+$ git annex copy --from r1 --to r2 --not --in r2
+copy dir/foo/bar/baz.txt (from r1...)
+(checksum...) (to r2...)
+ok
+copy dir/quux/buz/bez1.bin (from r1...)
+(checksum...) (to r2...)
+ok
+copy dir/quux/buz/bez2.bin (from r1...)
+(checksum...) (to r2...)
+ok
+copy dir/quux/buz/bez3.bin (from r1...)
+(checksum...) (to r2...)
+ok
+git-annex: .git/HEAD: openFile: resource busy (file is locked)
+```
+
+This happens in a `adjusted/master(unlockpresent)` branch.
+
+everything seems to work fine regardless of the complaint, so I don't know if this warning message is just a cosmetic issue or if it is the tip of the iceberg, hiding a more serious problem.
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 10.20230329-g30d7f9ad7
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E [...] WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+```
+
+### Please provide any additional information below.
+
+This is probably related to [[bugs/Failed_adjusted_branch_update_after_error_in_drop/]]
+
+> [[fixed|done]] (I presume) --[[Joey]]
diff --git a/doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy/comment_1_b05e0060d503a1d58c972796c5be151b._comment b/doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy/comment_1_b05e0060d503a1d58c972796c5be151b._comment
new file mode 100644
index 0000000000..cfd162c934
--- /dev/null
+++ b/doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy/comment_1_b05e0060d503a1d58c972796c5be151b._comment
@@ -0,0 +1,87 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="happens during sync too"
+ date="2023-04-03T11:48:09Z"
+ content="""
+I get the same complaint/error while on a hidemissing-unlocked adjusted branch (as a Windows user)
+and trying to sync with a regular remote (which happens to be an unlocked adjusted branch).
+Manually bisecting I found out that the problem first occurs with [[!commit 038a2600f4cf71294976280c5c29f6710359375f]]
+(so \"00f\" indeed) which seems to confirm that the fixes made for the linked bug seem to be
+the culprit.
+
+Here's a simple PowerShell transcript of me committing a disk image backup file to an annex
+and then proceeding to `sync` with a remote
+ trying different versions of git-annex with the one
+built from [[!commit cb4d9f7b1f8ce251d86f8f0163c0884cb9454603]] finally working, ie. doing a full
+pull and push cycle (here `git annex-sync` is simply an alias for `git annex sync --no-commit`):
+
+[[!format sh \"\"\"
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked) +1 ~0 -0 !]> git annex version --raw
+10.20230329-g000723d96
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked) +1 ~0 -0 !]> time git annex add
+add D2DB92DE496EC33F-06-06.mrimg
+ok
+(recording state in git...)
+00:05:42.5080264
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked) +1 ~0 -0 ~]> git status
+Refresh index: 100% (33/33), done.
+On branch adjusted/master(hidemissing-unlocked)
+Changes to be committed:
+  (use \"git restore --staged <file>...\" to unstage)
+        new file:   D2DB92DE496EC33F-06-06.mrimg
+
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked) +1 ~0 -0 ~]> git annex-meta -t differentiaali -s varmistus=differentiaali D2DB92DE496EC33F-06-06.mrimg
+metadata D2DB92DE496EC33F-06-06.mrimg
+  lastchanged=2023-04-03@09-31-18
+  tag=differentiaali
+  tag-lastchanged=2023-04-03@09-31-18
+  varmistus=differentiaali
+  varmistus-lastchanged=2023-04-03@09-31-18
+ok
+(recording state in git...)
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked) +1 ~0 -0 ~]> git commit -m 'Lisätty: D2DB92DE496EC33F-06-06.mrimg; differentiaali'
+[adjusted/master(hidemissing-unlocked) 6cc1044] Lisätty: D2DB92DE496EC33F-06-06.mrimg; differentiaali
+ 1 file changed, 1 insertion(+)
+ create mode 100644 Jarkon ThinkPad T450s (Win10 v21H1) . B/D2DB92DE496EC33F-06-06.mrimg
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex-sync
+pull k-levyn-annex2
+From k:\Reflect-varmistukset
+   3649f50..407d219  git-annex  -> k-levyn-annex2/git-annex
+ok
+git-annex: .git\HEAD: openFile: resource busy (file is locked)
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex-sync
+pull k-levyn-annex2
+ok
+git-annex: .git\HEAD: openFile: resource busy (file is locked)
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex version --raw
+10.20230329-g000723d96
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex version --raw
+10.20230322-g038a2600f
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex-sync
+pull k-levyn-annex2
+ok
+git-annex: .git\HEAD: openFile: resource busy (file is locked)
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex version --raw
+10.20230322-gcb4d9f7b1
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex-sync
+pull k-levyn-annex2
+ok
+push k-levyn-annex2
+Enumerating objects: 17, done.
+Counting objects: 100% (17/17), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (12/12), done.
+Writing objects: 100% (14/14), 1.27 KiB | 432.00 KiB/s, done.
+Total 14 (delta 5), reused 0 (delta 0), pack-reused 0
+remote: Checking connectivity: 14, done.
+To k:\Reflect-varmistukset
+   3649f50..e420747  git-annex -> synced/git-annex
+   c74664e..6cab55f  master -> synced/master
+ok
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex version --raw
+10.20230322-gcb4d9f7b1
+\"\"\"]]
+
+
+"""]]
diff --git a/doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy/comment_2_399dcbe7f3772526efbe13bd5b13156d._comment b/doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy/comment_2_399dcbe7f3772526efbe13bd5b13156d._comment
new file mode 100644
index 0000000000..f102bfa530
--- /dev/null
+++ b/doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy/comment_2_399dcbe7f3772526efbe13bd5b13156d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-04-04T18:13:49Z"
+ content="""
+Clearly a laziness bug, so the fix seems obvious and I've commited it.
+
+But I've not managed to reproduce it. It makes sense it would be
+intermittent. Please followup if you still see it after
+[[!commit 3eb51ee929c75376d004341f41aa38a1488558a3]]
+"""]]
diff --git a/doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy/comment_3_201c7dcd0e809cb2c22ab4b621079c71._comment b/doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy/comment_3_201c7dcd0e809cb2c22ab4b621079c71._comment
new file mode 100644
index 0000000000..78815e33ae
--- /dev/null
+++ b/doc/bugs/__34__.git__47__HEAD__58___openFile__58___resource_busy__34___after_copy/comment_3_201c7dcd0e809cb2c22ab4b621079c71._comment
@@ -0,0 +1,62 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 3"
+ date="2023-04-05T09:42:11Z"
+ content="""
+I can confirm that things seem to be AOK now:
+
+[[!format sh \"\"\"
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex-sync
+merge synced/master (Merging into master...)
+Merge made by the 'ort' strategy.
+ Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-02-02.mrimg | 1 -
+ Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-03-03.mrimg | 1 -
+ Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-04-04.mrimg | 1 -
+ Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-05-05.mrimg | 1 -
+ Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-06-06.mrimg | 1 -
+ Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-07-07.mrimg | 1 -
+ Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-08-08.mrimg | 1 -
+ 7 files changed, 7 deletions(-)
+ delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-02-02.mrimg
+ delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-03-03.mrimg
+ delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-04-04.mrimg
+ delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-05-05.mrimg
+ delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-06-06.mrimg
+ delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-07-07.mrimg
+ delete mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/arkistoidut/BDF96DE98ECBB6EC-08-08.mrimg
+(Merging into adjusted branch...)
+Updating a21ddee..445c0c9
+Fast-forward
+ok
+pull k-levyn-annex2
+From k:\Reflect-varmistukset
+   e420747..6621032  git-annex     -> k-levyn-annex2/git-annex
+   6cab55f..7638c8c  master        -> k-levyn-annex2/master
+   6cab55f..7638c8c  synced/master -> k-levyn-annex2/synced/master
+ok
+git-annex: .git\HEAD: openFile: resource busy (file is locked)
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex version --raw
+10.20230329-g000723d96
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex version --raw
+10.20230330-g3eb51ee92
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex-sync
+pull k-levyn-annex2
+ok
+push k-levyn-annex2
+Enumerating objects: 11, done.
+Counting objects: 100% (11/11), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (7/7), done.
+Writing objects: 100% (7/7), 810 bytes | 405.00 KiB/s, done.
+Total 7 (delta 4), reused 0 (delta 0), pack-reused 0
+To k:\Reflect-varmistukset
+   e420747..6621032  git-annex -> synced/git-annex
+   7638c8c..73de8e2  master -> synced/master
+ok
+H:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(hidemissing-unlocked)]> git annex version --raw
+10.20230330-g3eb51ee92
+\"\"\"]]
+
+Thank you so much, Joey, well done! 🎉
+"""]]
diff --git a/doc/bugs/__34__Missing_location__34___with_partsize__39__d_uploads.mdwn b/doc/bugs/__34__Missing_location__34___with_partsize__39__d_uploads.mdwn
new file mode 100644
index 0000000000..c5c50e855e
--- /dev/null
+++ b/doc/bugs/__34__Missing_location__34___with_partsize__39__d_uploads.mdwn
@@ -0,0 +1,29 @@
+### Please describe the problem.
+
+On my Garage/S3 remote, if I configure `partsize=100Mib`, any uploads which are larger than this partsize return:
+
+```
+copy testlargefile (to garage...)
+
+  XmlException {xmlErrorMessage = "Missing Location"}
+
+
+  XmlException {xmlErrorMessage = "Missing Location"}
+failed
+```
+
+The file here is at 124MiB - I can then immediately reattempt the copy command and get:
+
+```
+copy testlargefile ok
+```
+
+Any files below 100MiB report no errors and if I configure no partsize - there are no errors either.
+
+### What version of git-annex are you using? On what operating system?
+
+master on Fedora Silverblue.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+All wonderful otherwise.
diff --git a/doc/bugs/__34__Missing_location__34___with_partsize__39__d_uploads/comment_1_b3b767b3ab4a73590bf7e2af8640f906._comment b/doc/bugs/__34__Missing_location__34___with_partsize__39__d_uploads/comment_1_b3b767b3ab4a73590bf7e2af8640f906._comment
new file mode 100644
index 0000000000..16c5a94401
--- /dev/null
+++ b/doc/bugs/__34__Missing_location__34___with_partsize__39__d_uploads/comment_1_b3b767b3ab4a73590bf7e2af8640f906._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-09-26T17:07:59Z"
+ content="""
+The "Missing Location" message is generated by the aws library when a
+multipart upload results in a response from the S3 server that does not
+include a Location tag.
+
+You should be able to verify this by passing --debug to see the http
+response.
+
+This is documented in the AWS API
+[here](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CompleteMultipartUpload.html#AmazonS3-CompleteMultipartUpload-response-Location).
+
+I suspect this is (another) respect where the Garage server doesn't
+implement the API quite right..
+
+It would be possible to change the aws library to not throw an error here,
+and git-annex is not actually using that Location tag for anything. But it
+seems like it would probably be better to fix Garage.
+
+Setting chunk= rather than partsize= should be an easy workaround for the
+problem.
+"""]]
diff --git a/doc/bugs/__34__Unsupported_url_scheme__34___message_when_trying_to_cconnect_to_ftp_server.mdwn b/doc/bugs/__34__Unsupported_url_scheme__34___message_when_trying_to_cconnect_to_ftp_server.mdwn
new file mode 100644
index 0000000000..830d382b58
--- /dev/null
+++ b/doc/bugs/__34__Unsupported_url_scheme__34___message_when_trying_to_cconnect_to_ftp_server.mdwn
@@ -0,0 +1,54 @@
+I am trying to use git-annex as part of a datalad install on an Ubuntu 18.04 VirtualBox VM to set up a repository linking to some datasets at a public ftp server.  When I use git-annex version 7.20190219 (installed with apt-get install git-annex-standalone from NeuroDebian) to add the links, I get the following error:
+
+emmet@emmet-VirtualBox:~/conp-dataset/projects/1KGP-22May2019$ git annex addurl ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20130502/ALL.chr6.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz –file=1KGP_chr6-vcf.gz
+addurl ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20130502/ALL.chr6.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz Unsupported url scheme ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20130502/ALL.chr6.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz
+
+download failed: Unsupported url scheme ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20130502/ALL.chr6.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz
+failed
+git-annex: addurl: 1 failed
+
+
+
+However when I use git-annex v 6.20180227 (installed from the apt repository that came with Ubuntu 18.04) the link is generated correctly:
+
+emmet@emmet-VirtualBox:~/conp-dataset/projects/1KGP-22May2019$ git annex addurl ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20130502/ALL.chr6.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz --file=1KGP_chr6-vcf.gz
+addurl ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20130502/ALL.chr6.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz
+ALL.chr6.phase3_shapeit2_mvncall_integrated_ 100%[===========================================================================================>] 953.14M  9.81MB/s    in 93s    
+2019-05-22 16:10:44 URL: ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20130502/ALL.chr6.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz [999436830] -> "/home/emmet/conp-dataset/projects/1KGP-22May2019/.git/annex/tmp/URL-s999436830--ftp&c%%ftp.1000genomes.ebi.ac.uk-dda0592051d00d19f6c947a6b3aae6a5" [1]
+(to 1KGP_chr6-vcf.gz) ok
+(recording state in git...)
+
+
+
+Similarly, after publishing the correctly formed links generated with 6.20180227 to github, trying to download them on another Ubuntu VirtualBox VM with git-annex 7.20190219 installed causes the following error:
+
+emmet@emmet-VirtualBox:~/conp-dataset/projects/1KGP-22May2019$ git annex get 1KGP_chr2-vcf.gz
+get 1KGP_chr2-vcf.gz (from web...)
+download failed: Unsupported url scheme ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20130502/ALL.chr2.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz
+
+  Unable to access these remotes: web
+
+  Try making some of these repositories available:
+      00000000-0000-0000-0000-000000000001 -- web
+       2cc9a182-813f-4740-8157-c7a560560238 -- emmet@emmet-VirtualBox:~/conp-dataset/projects/1KGP-22May2019
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+git-annex: get: 1 failed
+
+
+
+but downloading them on that same VM with git-annex v 6.20180227 installed instead works:
+
+emmet@emmet-VirtualBox:~/conp-dataset/projects/1KGP-22May2019$ git annex get 1KGP_chr2-vcf.gz
+get 1KGP_chr2-vcf.gz (from web...)
+ALL.chr2.phase3_sha 100%[===================>]   1.22G  6.99MB/s    in 3m 11s 
+2019-05-22 16:25:44 URL: ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20130502/ALL.chr2.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz [1312735578] -> "/home/emmet/conp-dataset/projects/1KGP-22May2019/.git/annex/tmp/MD5E-s1312735578--774370621affaf125e6994089f975ed7.gz" [1]
+(checksum...) ok
+(recording state in git...)
+
+
+Would you know why this is happening?  And how I can avoid this failure mode in the more up-to-date version of git-annex?
+ 
+> Added back support for ftp urls with no special configuration needed.
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/__34__Unsupported_url_scheme__34___message_when_trying_to_cconnect_to_ftp_server/comment_1_db2b9e26bc01abbc3312731b95cf770f._comment b/doc/bugs/__34__Unsupported_url_scheme__34___message_when_trying_to_cconnect_to_ftp_server/comment_1_db2b9e26bc01abbc3312731b95cf770f._comment
new file mode 100644
index 0000000000..1b18333c93
--- /dev/null
+++ b/doc/bugs/__34__Unsupported_url_scheme__34___message_when_trying_to_cconnect_to_ftp_server/comment_1_db2b9e26bc01abbc3312731b95cf770f._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-05-29T13:19:08Z"
+ content="""
+Behavior change due to a security hole being fixed. See the discussion
+here:
+<http://git-annex.branchable.com/bugs/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/>
+
+While that bug was specific to redirects, as I note in the comment it's a
+more general reversion, but necessary due to the security fix. Perhaps
+I'll find a fix though.
+
+The workaround is this which makes git-annex use curl: 
+
+	git config annex.web-options -n
+	git config annex.security.allowed-http-addresses all
+"""]]
diff --git a/doc/bugs/__34__commitBuffer__58___invalid_argument___40__invalid_character__41____34___during___34__git_annex_sync__34__.mdwn b/doc/bugs/__34__commitBuffer__58___invalid_argument___40__invalid_character__41____34___during___34__git_annex_sync__34__.mdwn
new file mode 100644
index 0000000000..d4e3ad4716
--- /dev/null
+++ b/doc/bugs/__34__commitBuffer__58___invalid_argument___40__invalid_character__41____34___during___34__git_annex_sync__34__.mdwn
@@ -0,0 +1,52 @@
+### Please describe the problem.
+
+In my unlocked adjusted branch, I get a lot of errors during "git annex sync". It appears to work fine otherwise (the files actually get synced). Below is what I see on the terminal. The repository is otherwise clean (no local or remote changes).
+This has started to happen around a month ago, though I cannot pinpoint the exact version. This is in the same repo you used to debug the disappearing files in direct mode recently (thanks a lot btw!).
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+$ git annex version
+git-annex version: 6.20161110-gd48f4ca
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+$ lsb_release -a
+No LSB modules are available.
+Distributor ID: Debian
+Description:    Debian GNU/Linux 8.6 (jessie)
+Release:        8.6
+Codename:       jessie
+"""]]
+
+### Please provide any additional information below.
+
+[[!format sh """
+$ git annex sync --content
+commit
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+ok
+pull origin
+remote: Counting objects: 113, done.
+remote: Compressing objects: 100% (113/113), done.
+remote: Total 113 (delta 112), reused 0 (delta 0)
+Receiving objects: 100% (113/113), 7.16 KiB | 0 bytes/s, done.
+Resolving deltas: 100% (112/112), completed with 112 local objects.
+From /srv/annex/bilder
+   97a4806..78cb4ef  git-annex  -> origin/git-annex
+ok
+(merging origin/git-annex into git-annex...)
+
+git-annex: fd:25: commitBuffer: invalid argument (invalid character)
+failed
+
+git-annex: fd:25: commitBuffer: invalid argument (invalid character)
+failed
+
+[...]
+
+git-annex: fd:25: commitBuffer: invalid argument (invalid character)
+failed
+git-annex: sync: 2653 failed
+"""]]
diff --git a/doc/bugs/__34__directory__34___special_remote_leaves_empty_dirs.mdwn b/doc/bugs/__34__directory__34___special_remote_leaves_empty_dirs.mdwn
new file mode 100644
index 0000000000..148f57ebed
--- /dev/null
+++ b/doc/bugs/__34__directory__34___special_remote_leaves_empty_dirs.mdwn
@@ -0,0 +1,116 @@
+### Please describe the problem.
+
+"directory" special remote leaves empty directories after dropping files. I
+compared it to rsync, and he cleans empty dirs, so I wonder if this is a bug in
+"directory".
+
+Also I think is it possible to make `testremote` also test for it? First I
+found this behavior in rclone special remote and was very confused, then
+compared to "directory" and got confused even more.
+
+### What steps will reproduce the problem?
+
+I made a little script :D, here it is:
+
+[[!format sh """
+#!/bin/bash
+
+test_dir=$(mktemp -d /tmp/test-empties.XXX)
+cd "$test_dir" || exit 1
+
+# create repo
+mkdir rep && cd rep || exit 1
+git init
+git annex init
+
+# add special remotes
+mkdir ../sp_directory
+git annex initremote sp_directory type=directory directory=../sp_directory encryption=none
+git annex initremote sp_rsync type=rsync rsyncurl=../sp_rsync encryption=none
+
+# add file and copy to remotes
+touch a
+git annex add a
+git commit -m commit
+git annex copy a --to sp_directory
+git annex copy a --to sp_rsync
+
+
+test_it() {
+    name="$1"
+
+    echo -e "\n\n"
+    echo "--------- special remote: $name ---------"
+    echo "--------- before drop: ---------" && tree "../sp_$name"
+    echo
+    git annex drop a --from "sp_$name" --force
+    echo
+    echo "--------- after drop: ---------" && tree "../sp_$name"
+}
+
+test_it directory
+test_it rsync
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20230626-g55fef4fb81
+
+OS: archlinux
+
+### Please provide any additional information below.
+
+Output of my script:
+
+[[!format sh """
+<cut>
+
+--------- special remote: directory ---------
+--------- before drop: ---------
+../sp_directory
+├── f87
+│   └── 4d5
+│       └── SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+│           └── SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+└── tmp
+
+5 directories, 1 file
+
+drop sp_directory a ok
+(recording state in git...)
+
+--------- after drop: ---------
+../sp_directory
+├── f87
+│   └── 4d5
+└── tmp
+
+4 directories, 0 files
+
+
+
+--------- special remote: rsync ---------
+--------- before drop: ---------
+../sp_rsync
+└── f87
+    └── 4d5
+        └── SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+            └── SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+
+4 directories, 1 file
+
+drop sp_rsync a ok
+(recording state in git...)
+
+--------- after drop: ---------
+../sp_rsync
+
+0 directories, 0 files
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I'm tinkering with annex for about 1 week, "doing research" in preparation to
+use it as storage for backups.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/__34__directory__34___special_remote_leaves_empty_dirs/comment_1_8cef8650103d118fbbe56d20a4f59f96._comment b/doc/bugs/__34__directory__34___special_remote_leaves_empty_dirs/comment_1_8cef8650103d118fbbe56d20a4f59f96._comment
new file mode 100644
index 0000000000..2d75add7f6
--- /dev/null
+++ b/doc/bugs/__34__directory__34___special_remote_leaves_empty_dirs/comment_1_8cef8650103d118fbbe56d20a4f59f96._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-21T18:08:52Z"
+ content="""
+Hmm, I guess this wasn't implemented because a generally small number of
+hash directories are not a bother. And because implementing it was a bit
+annoying.
+
+Testremote cannot test for this, because remotes do not need to have the
+concept of a "directory". For example, a S3 bucket does not contain
+directories, only filenames that may contain a "/" in them. Also, I don't
+think it's necessarily a bug for a special remote to leave hash directories
+in place when removing files. There could be good reasons to do that in
+some cases.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit.mdwn b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit.mdwn
new file mode 100644
index 0000000000..f6265f05a6
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+After having added new content (SHA1E backend), when trying to commit, git commit fails with the following error:
+
+[[!format sh """
+(Recording state in git...)
+error: invalid object 100644 5d471129a031f0f493de3736eaea6f2f4056aeee for '000/091/WORM-s1493-m1321288671--scrapbook%data%20111114173520%horiz-menu-tab-r_001.png.log'
+fatal: git-write-tree: error building trees
+git-annex: failed to read sha from git write-tree
+"""]]
+
+The commit subsequently fails and the index is left as is. When I did git-annex add, I got the same error, but the additions seem to have been staged, at least.
+
+What’s curious about this is that I migrated all keys to SHA1E earlier and dropped all WORM keys. git annex info also says that all my keys are SHA1E.
+
+Can this be related to your changes to the WORM backend? I upgraded to git-annex 5.20140818 today. Rolling back to 5.20140716 didn’t allow me to commit, either, though.
+
+Any way I could resolve this? I don’t want to git reset for now, since this will leave the added objects in the annex store.
+
+### What version of git-annex are you using? On what operating system?
+git-annex 5.20140818
+
+Linux 3.16.1
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_10_8abfe7417167df54b686960319465a65._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_10_8abfe7417167df54b686960319465a65._comment
new file mode 100644
index 0000000000..a8d501682f
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_10_8abfe7417167df54b686960319465a65._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ ip="81.111.193.130"
+ subject="comment 10"
+ date="2014-09-08T08:08:50Z"
+ content="""
+Removing .git/annex/index is safe, it is a step in getting git-annex to [forget a commit entirely](http://git-annex.branchable.com/forum/How_to_get_git-annex_to_forget_a_commit__63__).
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_11_7776659e257a97c9a3855c8ad008207a._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_11_7776659e257a97c9a3855c8ad008207a._comment
new file mode 100644
index 0000000000..4632a5df3b
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_11_7776659e257a97c9a3855c8ad008207a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 11"
+ date="2014-10-02T16:09:37Z"
+ content="""
+It seems to me that the problem must be with .git/annex/index.
+
+I would be interested in looking at this git repository, if there's a way to get a copy (no .git/annex/objects needed).
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_12_e8bbfb4eb26dae31f90a5fa53b4dc948._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_12_e8bbfb4eb26dae31f90a5fa53b4dc948._comment
new file mode 100644
index 0000000000..dd6b5c1960
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_12_e8bbfb4eb26dae31f90a5fa53b4dc948._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""ping?"""
+ date="2015-02-10T17:37:06Z"
+ content="""
+Do you still have this repository?
+
+Marking this bug moreinfo.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_13_aee32c53d2198ba1e82acd0c617d517c._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_13_aee32c53d2198ba1e82acd0c617d517c._comment
new file mode 100644
index 0000000000..d0ca7f5542
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_13_aee32c53d2198ba1e82acd0c617d517c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="zenture@51f656b89d89727211c54a15824fd8393ba11a79"
+ nickname="zenture"
+ subject="same problem"
+ date="2015-05-29T08:30:42Z"
+ content="""
+Hello, I've had the same problem, removing the index fixed the issue.
+
+I have a backup of it, it's 88MB, how shall I share it with you, Joey?
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_14_f41116524fb7b423ff03c9440b5f278b._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_14_f41116524fb7b423ff03c9440b5f278b._comment
new file mode 100644
index 0000000000..fb65220efe
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_14_f41116524fb7b423ff03c9440b5f278b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="konubinix"
+ avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
+ subject="Same here"
+ date="2017-01-26T11:19:01Z"
+ content="""
+Instead of index, I removed index.lck, it looks like it resolved the problem also.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_15_0f61544accba5002edef2bcd4131e69f._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_15_0f61544accba5002edef2bcd4131e69f._comment
new file mode 100644
index 0000000000..3ce7b7bb41
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_15_0f61544accba5002edef2bcd4131e69f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="konubinix"
+ avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
+ subject="Same here"
+ date="2017-01-26T11:19:24Z"
+ content="""
+Instead of index, I removed index.lck, it looks like it resolved the problem also.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_16_9dc2f74dc69ccf867ac4e68cc502fda4._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_16_9dc2f74dc69ccf867ac4e68cc502fda4._comment
new file mode 100644
index 0000000000..598b75b12a
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_16_9dc2f74dc69ccf867ac4e68cc502fda4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="konubinix"
+ avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
+ subject="Same here"
+ date="2017-01-26T11:19:50Z"
+ content="""
+Instead of index, I removed index.lck, it looks like it resolved the problem also.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_17_0525b887cd75c183a34de0f486ec022c._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_17_0525b887cd75c183a34de0f486ec022c._comment
new file mode 100644
index 0000000000..7c2cf5e36a
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_17_0525b887cd75c183a34de0f486ec022c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="konubinix"
+ avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
+ subject="Same here"
+ date="2017-01-26T11:20:12Z"
+ content="""
+Instead of index, I removed index.lck, it looks like it resolved the problem also.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_18_fd55979b686b5f83ba2b95300abd1852._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_18_fd55979b686b5f83ba2b95300abd1852._comment
new file mode 100644
index 0000000000..c7b2756a08
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_18_fd55979b686b5f83ba2b95300abd1852._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="konubinix"
+ avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
+ subject="Same here"
+ date="2017-01-26T11:20:32Z"
+ content="""
+Instead of index, I removed index.lck, it looks like it resolved the problem also.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_19_bdd9e29413f4407207efa01283ad68ad._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_19_bdd9e29413f4407207efa01283ad68ad._comment
new file mode 100644
index 0000000000..b1e9a27276
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_19_bdd9e29413f4407207efa01283ad68ad._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="bump"
+ date="2019-01-05T23:06:05Z"
+ content="""
+same here: scary error message, easy fix (`rm .git/annex/index.lck`):
+
+    (recording state in git...)
+    error: invalid object 100644 81c85a0001f059e769034c34d4f739376ecd9429 for '000/53b/SHA256E-s1346--41101bacc557f53ceec3a7fd401a3f6a53c0dfe649ac7fe2812208e4d0384a13.RAF.xmp.log'
+    fatal: git-write-tree: error building trees
+    git-annex: failed to read sha from git write-tree
+    CallStack (from HasCallStack):
+      error, called at ./Git/Sha.hs:18:15 in main:Git.Sha
+
+Unfortunately, this is a very large repo and I can't really reproduce now that I removed the lockfile. Do note there was an out of disk space condition earlier on that drive, but that was resolved before starting the git-annex operations. -- [[anarcat]]
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_1_2a64a2da445a64149da7335f35142a08._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_1_2a64a2da445a64149da7335f35142a08._comment
new file mode 100644
index 0000000000..af980d1bce
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_1_2a64a2da445a64149da7335f35142a08._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 1"
+ date="2014-08-22T09:27:34Z"
+ content="""
+git fsck only shows a few dangling blobs from a branch I did earlier and left behind, but otherwise reports no errors.
+
+git annex fsck --fast ultimately fails with the original error message at some point:
+
+[[!format sh \"\"\"
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+# nx fsck --fast|egrep -v 'ok$'
+[2014-08-22 11:14:43 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"ls-files\",\"--cached\",\"-z\",\"--\"]
+[2014-08-22 11:14:43 CEST] chat: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.numcopies\",\"--\"]
+[2014-08-22 11:14:43 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"git-annex\"]
+[2014-08-22 11:14:43 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-08-22 11:14:43 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"log\",\"refs/heads/git-annex..dda9b068ac5c075e79ab63a531770ad772ae8491\",\"-n1\",\"--pretty=%H\"]
+[2014-08-22 11:14:43 CEST] chat: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"cat-file\",\"--batch\"]
+[2014-08-22 11:25:24 CEST] chat: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2014-08-22 11:25:24 CEST] feed: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"update-index\",\"-z\",\"--index-info\"]
+[2014-08-22 11:25:24 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-08-22 11:25:24 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"write-tree\"]
+error: invalid object 100644 5d471129a031f0f493de3736eaea6f2f4056aeee for '000/091/WORM-s1493-m1321288671--scrapbook%data%20111114173520%horiz-menu-tab-r_001.png.log'
+fatal: git-write-tree: error building trees
+git-annex: failed to read sha from git write-tree
+(Recording state in git...)
+
+# End of transcript or log.
+\"\"\"]]
+
+
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_20_f12f7f14ef09fa765c78dbeef809da7d._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_20_f12f7f14ef09fa765c78dbeef809da7d._comment
new file mode 100644
index 0000000000..2a44d60f9b
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_20_f12f7f14ef09fa765c78dbeef809da7d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 20"
+ date="2021-11-25T19:23:46Z"
+ content="""
+Also ran across this today. All I did was a simple copy of a few files to a remote using a filter. I can provide the index and lck files if needed.
+
+    git-annex version: 8.20211011
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_21_3f2ce7b851392ad5285e95f3857d0959._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_21_3f2ce7b851392ad5285e95f3857d0959._comment
new file mode 100644
index 0000000000..e4d12df11f
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_21_3f2ce7b851392ad5285e95f3857d0959._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 21"""
+ date="2021-11-29T17:09:33Z"
+ content="""
+This seems to be a not entirely uncommon git failure.
+[google search](https://www.google.com/search?client=firefox-b-1-d&q=git+error%3A+invalid+object+100644+)
+has tens of thousands of hits that look like this and do not involve
+git-annex.
+
+One commenter in <https://stackoverflow.com/questions/14448326/git-commit-stopped-working-error-building-trees>
+said it was a permissions problem.
+
+Disconnecting a drive before all of git's changes have been written to it
+seem like the other likely way.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_22_94dc1d1485c3a380fe19dabe8f95aac2._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_22_94dc1d1485c3a380fe19dabe8f95aac2._comment
new file mode 100644
index 0000000000..a71cbd7dd6
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_22_94dc1d1485c3a380fe19dabe8f95aac2._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="markus.l2ll@17cbf3ea36ca05f481e573fd58be50dce9bf8ef9"
+ nickname="markus.l2ll"
+ avatar="http://cdn.libravatar.org/avatar/31c9e7cad2fba31ae36e793e957fb026"
+ subject="same error, same fix"
+ date="2023-02-01T06:44:20Z"
+ content="""
+Got the same error today, added some files (git annex add .) then tried to commit and got:
+
+error: invalid object 100644 88e4306546e6d62a10fb79506d06bcf6492d3934 for '000/c75/SHA256E-s200678--f0fd2056044082bc8c0e03edb93fbcc745627b6e638c4e2f4263fbb0a1fa0cce.SDT.log'
+fatal: git-write-tree: error building trees
+.git-annex-wrapped: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
+
+Doing a `rm .git/annex/index.lck` fixed it.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_2_decb1689b8cc2541077e2d0ae273b5e7._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_2_decb1689b8cc2541077e2d0ae273b5e7._comment
new file mode 100644
index 0000000000..b4feb654f0
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_2_decb1689b8cc2541077e2d0ae273b5e7._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 2"
+ date="2014-08-22T09:38:03Z"
+ content="""
+git commit with git-annex debug output enabled:
+
+
+[[!format sh \"\"\"
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+[2014-08-22 11:36:46 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"diff\",\"--cached\",\"--name-only\",\"-z\",\"--diff-filter=ACMRT\",\"--\",\".\"]
+[2014-08-22 11:36:46 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"diff\",\"--name-only\",\"--diff-filter=T\",\"-z\",\"--cached\",\"--\",\".\"]
+[2014-08-22 11:36:46 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"symbolic-ref\",\"HEAD\"]
+[2014-08-22 11:36:46 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"refs/heads/master\"]
+[2014-08-22 11:36:46 CEST] chat: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2014-08-22 11:36:46 CEST] feed: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"update-index\",\"-z\",\"--index-info\"]
+[2014-08-22 11:36:46 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+(Recording state in git...)
+[2014-08-22 11:36:46 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"write-tree\"]
+error: invalid object 100644 5d471129a031f0f493de3736eaea6f2f4056aeee for '000/091/WORM-s1493-m1321288671--scrapbook%data%20111114173520%horiz-menu-tab-r_001.png.log'
+fatal: git-write-tree: error building trees
+git-annex: failed to read sha from git write-tree
+
+# End of transcript or log.
+\"\"\"]]
+
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_3_1f6443e495cc16a13e2e4175e73dc8f1._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_3_1f6443e495cc16a13e2e4175e73dc8f1._comment
new file mode 100644
index 0000000000..78e7f4138a
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_3_1f6443e495cc16a13e2e4175e73dc8f1._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 3"
+ date="2014-08-22T09:58:05Z"
+ content="""
+Doing a git annex fsck on a new clone of the repository succeded; the problem must somehow with the .git/annex/index then, I presume?
+
+I did a git reset to restore to the sane state state before adding, but the problem is that I cannot unannex the files I added. :(
+
+[[!format sh \"\"\"
+nx unannex scrapbook/data/20140822101558/1.jpg
+[2014-08-22 11:56:16 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"--head\"]
+[2014-08-22 11:56:16 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"diff-index\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"--cached\",\"HEAD\"]
+[2014-08-22 11:56:16 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"scrapbook/data/20140822101558/1.jpg\"]
+[2014-08-22 11:56:16 CEST] call: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"commit\",\"-q\",\"--allow-empty\",\"--no-verify\",\"-m\",\"content removed from git annex\"]
+[2014-08-22 11:56:16 CEST] chat: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2014-08-22 11:56:16 CEST] feed: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"update-index\",\"-z\",\"--index-info\"]
+[2014-08-22 11:56:16 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+(Recording state in git...)
+[2014-08-22 11:56:16 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"write-tree\"]
+error: invalid object 100644 5d471129a031f0f493de3736eaea6f2f4056aeee for '000/091/WORM-s1493-m1321288671--scrapbook%data%20111114173520%horiz-menu-tab-r_001.png.log'
+fatal: git-write-tree: error building trees
+git-annex: failed to read sha from git write-tree
+\"\"\"]]
+
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_4_522020e71393434834def6c80b82e39e._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_4_522020e71393434834def6c80b82e39e._comment
new file mode 100644
index 0000000000..bfab0d1be6
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_4_522020e71393434834def6c80b82e39e._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 4"
+ date="2014-08-22T10:15:51Z"
+ content="""
+The file referred to in the error message seems to be in good shape:
+
+[[!format sh \"\"\"
+git --no-pager show git-annex:000/091/WORM-s1493-m1321288671--scrapbook%data%20111114173520%horiz-menu-tab-r_001.png.log
+1408605730.57892s 0 b25f42de-f4be-4d31-84d1-ab0b71dfec01
+1408562938.526946s 0 e148ea91-0eb6-4f47-86e9-db2136a15279
+\"\"\"]]
+
+Strangely, the SHA1 of the blob is different from the one reported in the write-tree error.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_5_cc4cba022869b32d298cdafed9545a34._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_5_cc4cba022869b32d298cdafed9545a34._comment
new file mode 100644
index 0000000000..0be1eb958b
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_5_cc4cba022869b32d298cdafed9545a34._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 5"
+ date="2014-08-22T13:07:34Z"
+ content="""
+I remembered I keep an hourly snapshot regimen and was able to get back the repository from before doing the «add» this morning. Both git fsck and git annex fsck return no errors, and yet, whenever anything is done to the git-annex branch (I tried add and forget), I get the above error.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_6_e71b251db2ff1f52a40fec40303cdefc._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_6_e71b251db2ff1f52a40fec40303cdefc._comment
new file mode 100644
index 0000000000..3fcbf200ba
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_6_e71b251db2ff1f52a40fec40303cdefc._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 6"
+ date="2014-08-22T13:15:06Z"
+ content="""
+I tried git annex repair on the repo (before doing any adds). It reports no fsck errors, but the repair then dies from a stack overflow.
+
+[[!format sh \"\"\"
+Running git fsck ...
+No problems found.
+Stack space overflow: current size 8388608 bytes.
+Use `+RTS -Ksize -RTS' to increase it.
+\"\"\"]]
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_7_0b6413f9ca403be3d83bb3306d1e7f8f._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_7_0b6413f9ca403be3d83bb3306d1e7f8f._comment
new file mode 100644
index 0000000000..eb2dea9563
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_7_0b6413f9ca403be3d83bb3306d1e7f8f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 7"
+ date="2014-08-22T14:00:42Z"
+ content="""
+I experimented on my snapshot a bit and found out something odd: When I reset the git-annex branch from dda9b06 to git-annex~1 (4246f73) my local file additions succeed, even though git-annex will fast-forward the branch to dda9b06 again before adding (when merging from origin/git-annex). dda9b06 is a large commit in which I dropped many unused WORM keys from another remote.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_8_f951981f0bf8cbaecfc46e7b9c903d70._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_8_f951981f0bf8cbaecfc46e7b9c903d70._comment
new file mode 100644
index 0000000000..ec876d2ea4
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_8_f951981f0bf8cbaecfc46e7b9c903d70._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 8"
+ date="2014-08-22T18:57:37Z"
+ content="""
+I just checked my other large git annex repo and noticed that here too I could no longer add files to the annex. The same observations as above apply. Here too on the tip of the git-anenx branch I had one huge commit in which I dropped the last of the unused WORM keys from another remote. Resetting the git-annex branch to git-annex~1 allowed me to make additions again, even though the reset tip was subsequently merged in again from the remote tracking branch.
+"""]]
diff --git a/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_9_7c98c8b291fdf28a09ccb6c7e4001d5a._comment b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_9_7c98c8b291fdf28a09ccb6c7e4001d5a._comment
new file mode 100644
index 0000000000..1a49e449ff
--- /dev/null
+++ b/doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_9_7c98c8b291fdf28a09ccb6c7e4001d5a._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 9"
+ date="2014-09-07T14:04:51Z"
+ content="""
+Any ideas? I noticed one alternative way (cf. the reset workaround
+above) to make «git annex add» work again is by deleting
+.git/annex/index*. Is this safe?
+
+In both repos, I had not even staged annex additions before the index
+was corrupted; the corruption must somehow have been left-over from
+earlier actions, altough all previous additions succeeded at the time,
+before both repositories mysteriously stopped working (in the context
+of backend-migration).
+
+I still have the original snapshots around if you’d like to debug
+this. As noted, «git fsck» succeeds, and all the block-level checksums
+check out, so the problem can’t be on the block device or file-system
+level.
+
+"""]]
diff --git a/doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field.mdwn b/doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field.mdwn
new file mode 100644
index 0000000000..2f56bb05a1
--- /dev/null
+++ b/doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field.mdwn
@@ -0,0 +1,11 @@
+### Please describe the problem.
+
+### What steps will reproduce the problem?
+
+I ran `git annex adjust --unlock` in a repo. `git-annex` did its job and added a commit with the description "git-annex adjusted branch". The author field does not seem to respect utf8, though. I get: "Author:     Félix <felix@example.com>" while I have "Author:     Félix <felix@example.com>" for all the other (manual) commits.
+
+### What version of git-annex are you using? On what operating system?
+
+Current Debian sid version: 7.20181205
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field/comment_1_6708d83b96b791e4cd829bb0a65cda6d._comment b/doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field/comment_1_6708d83b96b791e4cd829bb0a65cda6d._comment
new file mode 100644
index 0000000000..be654bfffe
--- /dev/null
+++ b/doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field/comment_1_6708d83b96b791e4cd829bb0a65cda6d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="comment 1"
+ date="2020-07-20T06:45:25Z"
+ content="""
+Got bitten again by this bug. The author field and the description of the commit do not respect utf8.
+
+git-annex version: 8.20200330
+
+"""]]
diff --git a/doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field/comment_2_d28894bc233987f68159e8d1a7a97096._comment b/doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field/comment_2_d28894bc233987f68159e8d1a7a97096._comment
new file mode 100644
index 0000000000..b7842401c6
--- /dev/null
+++ b/doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field/comment_2_d28894bc233987f68159e8d1a7a97096._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-09-22T17:37:50Z"
+ content="""
+Was a bit tricky to reproduce this (which does not excuse forgetting about
+it for 5 years!)
+
+	export LANG=en_US.utf8
+	git init foo
+	cd foo
+	export GIT_AUTHOR_NAME=Félix
+	git-annex init
+	touch foo
+	git-annex add
+	git commit -m add
+	unset GIT_AUTHOR_NAME
+	export LANG=C
+	git-annex adjust --unlock
+
+Err... I thought I had reproduced this with something like the above, 
+but now that is not working for me. I get:
+
+	commit 50fedeefa3ece65ed4866fe7a1e0c1fe9cc90d78 (HEAD -> adjusted/master(unlocked))
+	Author: Félix <joeyh@joeyh.name>
+	Date:   Fri Sep 22 15:23:18 2023 -0400
+	
+	    git-annex adjusted branch
+
+I've tried several other combinations of locale settings, LANG=C from the
+beginning, etc, and all seem to work ok. I also looked at the values coming
+into git-annex with LANG=C and going out, and it roundtrips unicode fine
+even in non-unicode locales.
+"""]]
diff --git a/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation.mdwn b/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation.mdwn
new file mode 100644
index 0000000000..d3fae595bc
--- /dev/null
+++ b/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation.mdwn
@@ -0,0 +1,44 @@
+### Please describe the problem.
+
+"git status" returns a list of almost all files in the annex (located on a FAT32 device) with these messages:
+
+    git-annex: git status will show music/a.flac to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git update-index -q --refresh music/a.flac
+    ... (a lot of similar messages for +30000 files)
+
+and then a new list of messages:
+
+    ...
+    git-annex: thread blocked indefinitely in an MVar operation
+    error: external filter 'git-annex smudge --clean %f' failed 1
+    error: external filter 'git-annex smudge --clean %f' failed
+    git-annex: thread blocked indefinitely in an MVar operation
+    error: external filter 'git-annex smudge --clean %f' failed 1
+    error: external filter 'git-annex smudge --clean %f' failed
+    ...
+    refresh index:  81% (30495/37394)
+
+
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+debian sid, git-annex version: 7.20190129
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
+> I think this got fixed by [[!commit 195508fc6541b8f03b78e2ae457422308fc8d9e2]].
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_1_a63994b33b651dccfd4d4cf946ab7170._comment b/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_1_a63994b33b651dccfd4d4cf946ab7170._comment
new file mode 100644
index 0000000000..aec5eb15e4
--- /dev/null
+++ b/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_1_a63994b33b651dccfd4d4cf946ab7170._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-03-18T17:59:46Z"
+ content="""
+Does this still happen with version 7.20190220?
+
+I take it you're using v7 mode with unlocked files?
+"""]]
diff --git a/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_2_2166a985e48a31c1b86cb77263f72ce2._comment b/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_2_2166a985e48a31c1b86cb77263f72ce2._comment
new file mode 100644
index 0000000000..2e4e91678b
--- /dev/null
+++ b/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_2_2166a985e48a31c1b86cb77263f72ce2._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="comment 2"
+ date="2019-03-21T20:40:55Z"
+ content="""
+That's right, I'm using v7 mode with unlocked files.
+
+```
+[core]
+        repositoryformatversion = 0
+        filemode = false
+        bare = false
+        logallrefupdates = true
+        symlinks = false
+        ignorecase = true
+[annex]
+        uuid = 25e5f762-db7f-49ad-a504-93e02bba642f
+        sshcaching = false
+        crippledfilesystem = true
+        version = 7
+        thin = true
+[filter \"annex\"]
+        smudge = git-annex smudge %f
+        clean = git-annex smudge --clean %f
+```
+
+
+With 7.20190220-g9d7663432, I now get:
+
+    sqlite worker thread crashed: user error (SQLite3 returned ErrorIO while attempting to perform prepare \"SELECT null from content limit 1\": disk I/O error(while opening database connection))
+    sqlite worker thread crashed: user error (SQLite3 returned ErrorIO while attempting to perform prepare \"SELECT null from content limit 1\": disk I/O error(while opening database connection))
+    ...
+"""]]
diff --git a/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_3_17b96f95f44a04063f5a52d690d96b32._comment b/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_3_17b96f95f44a04063f5a52d690d96b32._comment
new file mode 100644
index 0000000000..d07500a7c7
--- /dev/null
+++ b/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_3_17b96f95f44a04063f5a52d690d96b32._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="comment 3"
+ date="2019-03-21T22:57:36Z"
+ content="""
+The command above finally ended. Then `git annex sync` returns:
+
+```
+commit 
+fatal: Unable to create '/mnt/usb/audio/.git/index.lock': File exists.
+
+Another git process seems to be running in this repository, e.g.
+an editor opened by 'git commit'. Please make sure all processes
+are terminated then try again. If it still fails, a git process
+may have crashed in this repository earlier:
+remove the file manually to continue.
+ok
+fatal: Unable to create '.git/index.lock': .git/index.lock: openFd: already exists (File exists)
+
+If no other git process is currently running, this probably means a
+git process crashed in this repository earlier. Make sure no other git
+process is running and remove the file manually to continue.
+
+
+git-annex: .git/index.lock: openFd: already exists (File exists)
+failed
+git-annex: sync: 1 failed
+```
+
+I think I found the problem: my filesystem is probably full after all, I just noticed that `annex.thin` isn't supported on FAT and that the files got duplicated :-(. Bad news for me and my perfect rockbox player backed up with git-annex!
+"""]]
diff --git a/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_4_df73b69e651c728943a404223f350ebf._comment b/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_4_df73b69e651c728943a404223f350ebf._comment
new file mode 100644
index 0000000000..92d5c77530
--- /dev/null
+++ b/doc/bugs/__34__git_status__34___thread_blocked_indefinitely_in_an_MVar_operation/comment_4_df73b69e651c728943a404223f350ebf._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-03-22T13:14:51Z"
+ content="""
+Ok, it makes sense that sqlite would crash creating a DB if the disk was
+full.
+
+I hope that the earlier Mvar error was the same problem, just a different
+handling of the exception in that version. Or something similar failing on
+full disk.
+
+annex.thin needing hard links is a limitation that may one day be lifted,
+see [[todo/annex.thin_without_hardlinks]]
+"""]]
diff --git a/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn b/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn
new file mode 100644
index 0000000000..5a06bf0920
--- /dev/null
+++ b/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn
@@ -0,0 +1,91 @@
+### Please describe the problem.
+In my repo network, multiple repos are cropping up with an "invalid object" error.  The object in question changes and appears to be from git-annex's hidden branch.
+
+### What steps will reproduce the problem?
+This is happening after I add a mess of new files and sync, within a couple times of doing this, after a day or so.
+
+### What version of git-annex are you using? On what operating system?
+6.20160518-g766728c on linux
+
+### Please provide any additional information below.
+
+[[!format sh """
+# Example error, file in question will change
+    (recording state in git...)
+    error: invalid object 100644 d547f60ac6c53f8bf38999d93ce954e3dfca1656 for
+    '051/0b4/SHA3_512-s12447441634--b84ff2ead694b9d355d8deb4eae620b5979f0127f127718d53d02cd32f1020fba45f1e63723484462beb10110328dab29d875ea1788f949ce541640603fa73c0.log'
+    fatal: git-write-tree: error building trees
+    git-annex: failed to read sha from git write-tree
+# End of transcript or log.
+
+# log of attempting to determine the issue yesterday
+2016-05-22
+
+Issue history:
+Original annex started being unable to finish commit.
+Second annex, I cloned and copied objects folder over.  Soon, same issue.
+Third annex, cloned from elsewhere, use git annex get to get objects from
+broken repo.  Same issue developed.
+Fourth annex, cloned from elsewhere, was able to commit successfully
+prior to adding objects from broken repo.
+Some object in the broken repo seems to be causing this issue somehow.
+
+Plan to resolve:
+- copy all objects over again.  verify that issue immediately develops.
+  
+  I expect the issue will trigger when I add a set of objects with litelog.
+  So I could narrow it either by narrowing the objects I add with litelog,
+  or by narrowing the object I copy from the broken repo.
+
+  I'll narrow the issue between the two, first.
+
+annex: used to be annex.2, busted
+annex.3: third repository, busted, holds objects
+annex.4:
+  1. cloned from delta
+  2. added logs, no issue
+  3. 10:24:24 EDT rsync --delete-during'd objects in from annex.3
+  4. 10:25:10 EDT added small test file, sync'd with delta fine
+  5. 2016-05-22 10:27:38
+      I ran fetchall but ran by root by mistake.
+      files were added with wrong permissions
+      fixed permissions.  only two files were cpied, voicerecorder and muse.
+      sync works fine.'
+  6. ran fetchall (as root) again, got 4 sensorium files
+  7. add and sync seems to work fine.
+  So now this repository is functioning with additional objects copied into
+  its annex folder.  It must have been something else which caused the issue
+  on the other repo I initialized this way.
+  8. I foolishly tried to git annex add the alphabetically first object from
+  the annex/objects folder to get it annex's logs.  It failed when trying to
+  _delete_ it to replace it with a link to itself, luckily it was not writable.
+
+  I'll try using this repo - 2016-05-22 10:36:24 EDT
+
+  I'll add the remotes one at a time and sync with them, adding litelog after
+  each one.
+
+  9. 2016-05-23 00:08 EDT
+    Issue reoccurred uploading data from phone. Was a larger block of data.
+    First fetched
+    then added
+    then copied to delta
+    issue showed at end of copy to delta
+
+    perhaps the issue resides on delta ??? but we synced to delta fine before
+    the issue must happen over time while I am away from the computer
+    or respond to a large amount of logs being uploaded
+    or it could have happened as a result of my work on the nested repo
+ 10. 2016-05-23 00:10:15 EDT
+   $ git annex copy --to=gitlab
+   06:55 EDT
+   $ git annex sync gitlab
+    both commands ran without issue
+    delta also fsck'd fine
+ 11. 2016-05-23 07:01 EDT
+    local repo fsck'd fine
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Very stable.  Still excited.
+
diff --git a/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_1_d146a64ef8d76c2a7e45bf85d8943456._comment b/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_1_d146a64ef8d76c2a7e45bf85d8943456._comment
new file mode 100644
index 0000000000..6c7b8e2689
--- /dev/null
+++ b/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_1_d146a64ef8d76c2a7e45bf85d8943456._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-23T16:52:23Z"
+ content="""
+Try running `git fsck` and see if it complains about a corrupt object file.
+You may then need to delete the object file and fix up the repository to
+not refer to it. `git annex repair` can probably handle that.
+
+> Some object in the broken repo seems to be causing this issue somehow.
+
+Maybe, but you also say that the object it complains about has varied.
+Perhaps you have multiple corrupt objects in the git repo..
+
+You mention "litelog". What is that and how is it relevant? Is Android
+involved somehow?
+"""]]
diff --git a/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_2_6585b15aa7ae63175482d08b2b5b79fc._comment b/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_2_6585b15aa7ae63175482d08b2b5b79fc._comment
new file mode 100644
index 0000000000..72417ff8b8
--- /dev/null
+++ b/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_2_6585b15aa7ae63175482d08b2b5b79fc._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="comment 2"
+ date="2016-05-29T02:02:38Z"
+ content="""
+This has occurred for me yet again, after starting a new remote.
+
+Strangely 'git fsck' succeeds, showing only dangling objects, but 'git annex sync' fails on commit with this error.
+
+litelog is a set of service scripts I'm making which automatically record and log from devices when they are connected.  Voice recorder and sensor logs are copied off of android phones from a handful of supported apps.
+"""]]
diff --git a/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_3_973d90a6fde1c6f26fcf594610693fad._comment b/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_3_973d90a6fde1c6f26fcf594610693fad._comment
new file mode 100644
index 0000000000..92ae9f2d55
--- /dev/null
+++ b/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_3_973d90a6fde1c6f26fcf594610693fad._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-05-31T15:59:49Z"
+ content="""
+It may be that .git/annex/index is referring to an object that is somehow
+not present in the git object store. In this case, deleting the index file
+may recover.
+
+I can't see any way this can normally happen (short of the object file
+getting deleted somehow); git should always write
+objects to the object store before their sha1s are available to be put in
+an index file. But, a couple of people have reported something like this
+before.
+
+Any clues to reproducing it would be useful.
+"""]]
diff --git a/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway.mdwn b/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway.mdwn
new file mode 100644
index 0000000000..a318692b4e
--- /dev/null
+++ b/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway.mdwn
@@ -0,0 +1,69 @@
+### Please describe the problem.
+The git-annex assistant queues files for transfer to gcrypt git (not SSH) remotes, which shouldn't happen. `git-annex sync gcrypt` doesn't.  
+I think the problem might be that the assistant triggers a content sync, despite showing "metadata only", and that sync --content circumvents gcrypt.
+
+I have a gcrypt remote set up with github, but I can reprodue this issue using a directory as the destination as well.
+
+When I set up the remote and sync it, it works as it should:
+
+    ~/annex (git)-[annex/direct/master] % git remote add gcrypt gcrypt::/tmp/test
+    ~/annex (git)-[annex/direct/master] % git-annex sync gcrypt
+    commit  (recording state in git...)
+    ok
+    pull gcrypt
+    gcrypt: Development version -- Repository format MAY CHANGE
+    gcrypt: Repository not found: /tmp/test
+    ok
+    push gcrypt
+    gcrypt: Development version -- Repository format MAY CHANGE
+    gcrypt: Repository not found: /tmp/test
+    gcrypt: Setting up new repository
+    gcrypt: Remote ID is :id:thetwentycharacterid
+    Counting objects: 469459, done.
+    Compressing objects: 100% (122643/122643), done.
+    Total 469459 (delta 342415), reused 468156 (delta 341616)
+    gcrypt: Encrypting to:  -r fngerprintremoved
+    gcrypt: Requesting manifest signature
+    To gcrypt::/tmp/test
+     * [new branch]      git-annex -> synced/git-annex
+     * [new branch]      annex/direct/master -> synced/master
+    ok
+
+But when I launch the assistant/webapp, it starts queuing and syncing file contents, even though the remote is listed as "metadata only".
+
+After letting the assistant run for a minute:
+
+    ~ % ls /tmp/test/annex/objects/
+    000  043  091  0ed  130  18e  1d8  21c  26c  2b2  2f4  334  371  3ad  3e3  439  471  4b4  525  565  5c3  61b  691  724  788  ...
+
+*And the files aren't encrypted!*
+
+    find /tmp/test/annex/objects/ -type f -exec file {} \; | head -n10
+    /tmp/test/annex/objects/247/100/SHA256E-s5310--06c62006efde5abd7d03dbb15e3725982c80c0eaffde90e3b566fab26d810d6d.opf/SHA256E-s5310--06c62006efde5abd7d03dbb15e3725982c80c0eaffde90e3b566fab26d810d6d.opf: XML 1.0 document text
+    /tmp/test/annex/objects/5f8/851/SHA256E-s36705--a3b71efc462876709de6c95a7b21218fe437fe45ed39cf5da2709be546c360bc.jpg/SHA256E-s36705--a3b71efc462876709de6c95a7b21218fe437fe45ed39cf5da2709be546c360bc.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 310x500, frames 3
+    /tmp/test/annex/objects/f09/b22/SHA256E-s358928--7e7680e24baf28a82b94cf9931d73a8353ae5c009d81cb4d8c6e313bdc0b22e0/SHA256E-s358928--7e7680e24baf28a82b94cf9931d73a8353ae5c009d81cb4d8c6e313bdc0b22e0: EPUB document
+    /tmp/test/annex/objects/512/38c/SHA256E-s4246--f7dda72a07aa9f11e329e180c873ba1edd45ac80aa270e379ac52e09302ccfa0.opf/SHA256E-s4246--f7dda72a07aa9f11e329e180c873ba1edd45ac80aa270e379ac52e09302ccfa0.opf: XML 1.0 document text
+    /tmp/test/annex/objects/079/b2d/SHA256E-s496807--d5ba2b9a564a199ea33da246d70f43c8f531c53745130c4ae82ac8b5b5180684.epub/SHA256E-s496807--d5ba2b9a564a199ea33da246d70f43c8f531c53745130c4ae82ac8b5b5180684.epub: EPUB document
+    /tmp/test/annex/objects/6e3/e05/SHA256E-s5145--07a4770b8d1c10e46834b895484c20fca7f7e0850a51f8eb1f7c91f175ab2f8a.opf/SHA256E-s5145--07a4770b8d1c10e46834b895484c20fca7f7e0850a51f8eb1f7c91f175ab2f8a.opf: XML 1.0 document text
+    /tmp/test/annex/objects/b65/708/SHA256E-s271061--dc839391472cf5f08edc2807f7dd016a1ce4f5e3113a964882585fd6dcc51ce2.epub/SHA256E-s271061--dc839391472cf5f08edc2807f7dd016a1ce4f5e3113a964882585fd6dcc51ce2.epub: EPUB document
+    /tmp/test/annex/objects/9a4/9d3/SHA256E-s38917--5a1a770c758f2f9b254ad7f2f6b6e33b87f14486322d04b5d25b09569772b9e1.jpg/SHA256E-s38917--5a1a770c758f2f9b254ad7f2f6b6e33b87f14486322d04b5d25b09569772b9e1.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 305x500, frames 3
+    /tmp/test/annex/objects/4ec/b23/SHA256E-s307073--cbdef5840ad0addde500d2bfbb5e916c71dea6394f647f6663771abdb05a1776/SHA256E-s307073--cbdef5840ad0addde500d2bfbb5e916c71dea6394f647f6663771abdb05a1776: EPUB document
+    /tmp/test/annex/objects/074/106/SHA256E-s307165--9a379564df17b9e1a0b7a2221e81180db447a05a9f1123b52fe2a618462a922e.epub/SHA256E-s307165--9a379564df17b9e1a0b7a2221e81180db447a05a9f1123b52fe2a618462a922e.epub: EPUB document
+
+The above files are part of my Calibre library.
+
+For my github repo, the assistant still shows files queuing but they don't actually show up in the repo. I think it's trying to sync using SSH but failing.
+
+### What steps will reproduce the problem?
+1. Create a git-remote-gcrypt remote on a git server or in a local directory
+2. Open the git-annex webapp, ensuring that syncing is enabled
+
+### What version of git-annex are you using? On what operating system?
+
+    ~ % git-annex version
+    git-annex version: 5.20150519-g87f28bb
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 Inotify DBus DesktopNotify DNS Feeds Quvi TDFA TorrentParser
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent glacier ddar hook external
+
+I'm running Arch Linux
diff --git a/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_1_30a0a715fb9d8738e5ec53296375c1b3._comment b/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_1_30a0a715fb9d8738e5ec53296375c1b3._comment
new file mode 100644
index 0000000000..515079a79c
--- /dev/null
+++ b/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_1_30a0a715fb9d8738e5ec53296375c1b3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="chris@f4ea67aa5ae4709d79959f782fcebb5edae9a79b"
+ nickname="chris"
+ subject="similar problem"
+ date="2016-06-02T16:28:18Z"
+ content="""
+For me it's a version 6 repository, but I also get lots of queued transfers to my \"metadata only\" git-remote-gcrypt repo when I launch the webapp. Luckily they don't actually seem to turn up amongst the remote repo's objects (unless I'm missing something), but it causes the assistant to be busy being useless for a while.
+"""]]
diff --git a/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_2_b91f9337b7ed536539bb3236b7552d82._comment b/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_2_b91f9337b7ed536539bb3236b7552d82._comment
new file mode 100644
index 0000000000..db88d6b5d4
--- /dev/null
+++ b/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_2_b91f9337b7ed536539bb3236b7552d82._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="chris@f4ea67aa5ae4709d79959f782fcebb5edae9a79b"
+ nickname="chris"
+ subject="comment 2"
+ date="2016-06-07T13:40:24Z"
+ content="""
+The way I got round this was to give the metadata-only repository an annex-uuid of 00000000-0000-0000-0000-000000000000, and to run \"git annex wanted remotename nothing\".  Now everything works as I want, whether with the assistant or when I run git annex sync --content [--all] manually.
+"""]]
diff --git a/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_3_79268506a1653220ddfbb45f9c61d8a7._comment b/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_3_79268506a1653220ddfbb45f9c61d8a7._comment
new file mode 100644
index 0000000000..e24cb210b9
--- /dev/null
+++ b/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_3_79268506a1653220ddfbb45f9c61d8a7._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-06-09T20:27:07Z"
+ content="""
+This was fixed in [[!commit fbf5045d4f17accde9e20fa528e52cb1dce61c47]]
+for `git annex sync --content`
+
+I don't remember the immediate cause of it being in a code that that the
+webapp would call, but I did add a belt-and-suspenders fix at a lower level
+which I'd hope would prevent the webapp from uploading anything in any
+case.
+
+Sounds like the webapp tries to queue transfers to a NoUUID remote, and
+then presumably gives up before the object gets uploaded.
+
+Looking at the code, calcSyncRemotes does not filter out NoUUID remotes
+when populating syncDataRemotes. So, I've fixed that too now.
+"""]]
diff --git a/doc/bugs/__34__no_such_file_or_directory__34___when_using_bundle/comment_1_9c2410c55154bc8d9f733377cde58eb9._comment b/doc/bugs/__34__no_such_file_or_directory__34___when_using_bundle/comment_1_9c2410c55154bc8d9f733377cde58eb9._comment
new file mode 100644
index 0000000000..97cfb25e75
--- /dev/null
+++ b/doc/bugs/__34__no_such_file_or_directory__34___when_using_bundle/comment_1_9c2410c55154bc8d9f733377cde58eb9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lyderic"
+ avatar="http://cdn.libravatar.org/avatar/d03e900b5e94b54891ee9596460f76c3"
+ subject="This bug has alreay been raised"
+ date="2020-10-29T10:13:50Z"
+ content="""
+I found out that this bug has already been raised and addressed...
+https://git-annex.branchable.com/bugs/git_annex_init_fails/
+"""]]
diff --git a/doc/bugs/__34__rename__58___permission_denied__34__.mdwn b/doc/bugs/__34__rename__58___permission_denied__34__.mdwn
new file mode 100644
index 0000000000..32a2734dc0
--- /dev/null
+++ b/doc/bugs/__34__rename__58___permission_denied__34__.mdwn
@@ -0,0 +1,69 @@
+## I'm considering this a "false alarm", but leaving it around for others who may run into it
+
+It took a long time to add the files (50 minutes). When I did, and did a `git status`, the ones that failed due to "permission denied" just appeared as having not been added. I added them, and it worked fine. I have no reason to believe that my folder has gotten corrupted.
+
+So I don't personally think this needs fixing. But if anyone else out there runs into this issue, at least this page is here.
+
+
+### Please describe the problem.
+
+When adding 400k files to a new annex, I get an error "rename: permission denied". It doesn't seem to be about file permissions (I have `chown`ed them), and it's inconsistent from run to run. So each time I try the import, different files may show the permission denied error.
+
+One thing I'm concerned about is how to confirm whether these files have made it into annex, or if I now have a corrupted folder structure.
+
+I do intend to do smaller imports, or try using `-J1`.
+
+
+### What steps will reproduce the problem?
+
+1. `git config annex.jobs cpus`
+2. `git annex add .`
+
+
+### What version of git-annex are you using? On what operating system?
+
+macOS 10.15.7
+
+```
+git-annex version: 8.20210310
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.28 DAV-1.3.4 feed-1.3.0.1 ghc-8.10.4 http-client-0.7.6 persistent-sqlite-2.11.1.0 torrent-10000.1.1 uuid-1.3.14 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+```
+
+
+### Please provide any additional information below.
+
+iMac 10-core i9 (maybe 20 threads?)
+
+```
+git-annex: .git/annex/othertmp/ingest-A23998-2216: rename: permission denied (Permission denied)
+git-annex: .git/annex/othertmp/ingest-Ad23998-21291: rename: permission denied (Permission denied)
+git-annex: .git/annex/othertmp/ingest-P23998-30359: rename: permission denied (Permission denied)
+git-annex: .git/annex/othertmp/ingest-Audio23998-182890: rename: permission denied (Permission denied)
+git-annex: .git/annex/othertmp/ingest-wasd_clap_sys100_cra23998-206554: rename: permission denied (Permission denied)
+git-annex: .git/annex/othertmp/ingest-wasd_clap_sys100_f23998-206560: rename: permission denied (Permission denied)
+git-annex: .git/annex/othertmp/ingest-wasd_clap_sys100_f23998-206561: rename: permission denied (Permission denied)
+git-annex: .git/annex/othertmp/ingest-Fairligh23998-248968: rename: permission denied (Permission denied)
+git-annex: .git/annex/othertmp/ingest-ly23998-268165: rename: permission denied (Permission denied)
+git-annex: .git/annex/othertmp/ingest-123998-269213: rename: permission denied (Permission denied)
+git-annex: .git/annex/othertmp/ingest-46223998-278087.wav: rename: permission denied (Permission denied)
+git-annex: .git/annex/othertmp/ing23998-290478: rename: permission denied (Permission denied)
+git-annex: .git/annex/othertmp/ingest-H23998-292758: rename: permission denied (Permission denied)
+```
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Absolutely! :)
diff --git a/doc/bugs/__34__rename__58___permission_denied__34__/comment_1_19de24208042d09572c114bca80f4854._comment b/doc/bugs/__34__rename__58___permission_denied__34__/comment_1_19de24208042d09572c114bca80f4854._comment
new file mode 100644
index 0000000000..c36b696fd0
--- /dev/null
+++ b/doc/bugs/__34__rename__58___permission_denied__34__/comment_1_19de24208042d09572c114bca80f4854._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-06-25T17:23:44Z"
+ content="""
+git-annex is hard linking the file to the temp directory with "ingest-" in its
+name. Then later it renames that into .git/annex/objects/
+
+So the permissions problem must involve one of those directories, but neither
+seems likely. The newly created temp file is in a directory whose permissions
+certainly let it delete it since they let it create it there. The destination
+directory gets its write bit set before the rename.
+
+I wonder if some of these files, or other files you're
+adding might have identical content? It seems possible that there
+could be some concurrency related problem with that. Although I
+have not been able to produce any.
+
+Something OSX specific, possibly...
+"""]]
diff --git a/doc/bugs/__34__rename__58___permission_denied__34__/comment_2_e70c8b8192eb0f8868e52dc7a287e526._comment b/doc/bugs/__34__rename__58___permission_denied__34__/comment_2_e70c8b8192eb0f8868e52dc7a287e526._comment
new file mode 100644
index 0000000000..0643173352
--- /dev/null
+++ b/doc/bugs/__34__rename__58___permission_denied__34__/comment_2_e70c8b8192eb0f8868e52dc7a287e526._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-10-20T17:30:24Z"
+ content="""
+These look like very similar problems:
+<https://git-annex.branchable.com/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/>
+<https://git-annex.branchable.com/bugs/still_seeing_errors_with_parallel_git-annex-add/>
+"""]]
diff --git a/doc/bugs/__39__Production__39___build_doesn__39__t_pass_testsuite_on_Win32.mdwn b/doc/bugs/__39__Production__39___build_doesn__39__t_pass_testsuite_on_Win32.mdwn
new file mode 100644
index 0000000000..4965962860
--- /dev/null
+++ b/doc/bugs/__39__Production__39___build_doesn__39__t_pass_testsuite_on_Win32.mdwn
@@ -0,0 +1,783 @@
+### Please describe the problem.
+
+Building an optimized Windows binary with flag `Production` active doesn't result in one that is able
+to pass its test suite.
+
+### What steps will reproduce the problem?
+
+`stack --stack-yaml stack-lts-18.13.yaml setup && stack --stack-yaml stack-lts-18.13.yaml build --flag 'git-annex:Production' --flag 'git-annex:-Crypton'`
+
+(I found that the `Crypton` flag needs to be explicitly negated due to the `Production` flag somehow making it active causing
+the build to fail because of a missing dependency `crypton`. A bug in Cabal, perhaps?)
+
+Then run the test suite in Git Bash in a directory that contains the executable and the requisite DLLs (the latter
+obtained by way of `stack exec ldd -- git-annex.exe` and copying over the ones in `/mingw64`). Observe the following
+(`just` is a cross-platform command runner that I use instead of GNU make.)
+
+[[!format sh """
+jkniiv@AINESIS MINGW64 ~/Projektit/git-annex.branchable.com/git-annex--BUILD-231130-10.20231129~P/.annx-test (BUILD-231130-10.20231129)
+$ just tests-new
+/usr/bin/time ./git-annex.exe test  2>&1 | tee git-annex.test.LOG~200
+
+All 0 tests passed (0.00s)
+Tests
+  Repo Tests v10 adjusted unlocked branch
+    Init Tests
+      init:                          OK (9.36s)
+      add:                           FAIL
+        Exception: fd:4: hGetChar: invalid argument (invalid byte sequence)
+        Use -p '/Init Tests.add/' to rerun this test only.
+    crypto:                          SKIP
+
+      Use -p '/crypto/' to rerun this test only.
+    uninit (in git-annex branch):    SKIP
+
+      Use -p '/uninit (in git-annex branch)/' to rerun this test only.
+    conflict resolution symlink bit: SKIP
+
+      Use -p '/conflict resolution symlink bit/' to rerun this test only.
+    union merge regression:          SKIP
+
+      Use -p '/union merge regression/' to rerun this test only.
+    unused:                          SKIP
+
+      Use -p '/unused/' to rerun this test only.
+    fsck (bare):                     SKIP
+
+      Use -p '/fsck (bare)/' to rerun this test only.
+    lock:                            SKIP
+
+      Use -p '/Repo Tests v10 adjusted unlocked branch.lock/' to rerun this test only.
+    drop (with remote):              SKIP
+
+      Use -p '/drop (with remote)/' to rerun this test only.
+    log:                             SKIP
+
+      Use -p '/log/' to rerun this test only.
+    add extras:                      SKIP
+
+      Use -p '/add extras/' to rerun this test only.
+
+11 out of 12 tests failed (11.65s)
+[...]
+"""]]
+
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20231129-gbacd781c4fe05126219c4b5f2963677a6de01481
+build flags: Assistant Webapp Pairing TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 pe
+rsistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SH
+A3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512
+BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLA
+KE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM UR
+L X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg h
+ook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+"""]]
+
+Windows 10 version 22H2 (build 19045.3693), 64 bit.
+
+### Please provide any additional information below.
+
+This is how I build my "production" version of git-annex (in PowerShell):
+
+[[!format sh """
+C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P [BUILD-231130-10.20231129 +6 ~0 -0 !]> just setup-build
+cd 'C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P' && stack --stack-yaml stack-lts-18.13.yaml setup --verbose 2>&1 | & $env:GNU_TEE_CMD stack.setup---verbose.LOG~101
+Version 2.13.1, Git revision 8102bb8afce90fc954f48efae38b87f37cabc988 x86_64 hpack-0.36.0
+2023-12-08 16:24:52.098843: [debug] Loading project config file stack-lts-18.13.yaml
+2023-12-08 16:24:52.130837: [debug] Use of Casa server enabled: (CasaRepoPrefix "https://casa.stackage.org", 1280).
+2023-12-08 16:24:52.142835: [debug] (SQL) SELECT COUNT(*) FROM "last_performed" WHERE ("action"=?) AND ("timestamp">=?); [PersistInt64 1,PersistUTCTime 2023-12-07 14:24:52.1418345 UTC]
+2023-12-08 16:24:52.144833: [debug] Using package location completions from a lock file
+2023-12-08 16:24:52.154836: [debug] Loaded snapshot from Pantry database.
+2023-12-08 16:24:52.575861: [debug] Prefetching git repos: []
+2023-12-08 16:24:52.576863: [debug] []
+2023-12-08 16:24:52.614841: [debug] Asking for a supported GHC version
+2023-12-08 16:24:52.624838: [debug] Installed tools:
+ - msys2-20200903
+ - ghc-9.6.2
+ - ghc-9.0.2
+ - ghc-8.8.4
+ - ghc-8.8.3
+ - ghc-8.6.5
+ - ghc-8.4.3
+ - ghc-8.10.7
+ - ghc-8.10.4
+2023-12-08 16:24:52.625841: [debug] Potential GHC builds: standard
+2023-12-08 16:24:52.625841: [debug] Found already installed GHC builds: standard
+2023-12-08 16:24:52.630839: [debug] Performing a sanity check on: C:\Users\jkniiv\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\bin\ghc-8.10.7.exe
+2023-12-08 16:24:52.632844: [debug] Run process within C:\Users\jkniiv\AppData\Local\Temp\stack-sanity-check-2b0507b6fb5a74f8\: C:\Users\jkniiv\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\bin\ghc-8.10.7.exe C:\Users\jkniiv\AppData\Local\Temp\stack-sanity-check-2b0507b6fb5a74f8\Main.hs -no-user-package-db -hide-all-packages "-package base" "-package Cabal"
+2023-12-08 16:25:16.713070: [debug] Process finished in 24079ms: C:\Users\jkniiv\AppData\Local\Programs\stack\x86_64-windows\ghc-8.10.7\bin\ghc-8.10.7.exe C:\Users\jkniiv\AppData\Local\Temp\stack-sanity-check-2b0507b6fb5a74f8\Main.hs -no-user-package-db -hide-all-packages "-package base" "-package Cabal"
+2023-12-08 16:25:16.721070: [debug] (SQL) SELECT "id","actual_version","arch","ghc_path","ghc_size","ghc_modified","ghc_pkg_path","runghc_path","haddock_path","cabal_version","global_db","global_db_cache_size","global_db_cache_modified","info","global_dump" FROM "compiler_cache" WHERE "ghc_path"=?; [PersistText "C:\\Users\\jkniiv\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.10.7\\bin\\ghc-8.10.7.exe"]
+2023-12-08 16:25:16.806072: [debug] Loaded compiler information from cache
+2023-12-08 16:25:16.806072: [debug] Asking for a supported GHC version
+2023-12-08 16:25:16.806072: [info] Stack will use a sandboxed GHC it installed. To use this GHC and packages outside of a project,
+consider using: stack ghc, stack ghci, stack runghc, or stack exec.
+C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P [BUILD-231130-10.20231129 +6 ~0 -0 !]> just build-production
+cd 'C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P' && stack --stack-yaml stack-lts-18.13.yaml build --flag 'git-annex:Production' --flag 'git-annex:-Crypton' 2>&1 | & $env:GNU_TEE_CMD stack.build---flag-git-annex_Production.LOG~102
+Building all executables for git-annex once. After a successful build of all of them, only specified
+executables will be rebuilt.
+git-annex> configure (exe)
+[ 1 of 22] Compiling Author           ( Author.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Author.o )
+[ 2 of 22] Compiling Utility.Data     ( Utility\Data.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\Data.o )
+[ 3 of 22] Compiling Utility.FileSystemEncoding ( Utility\FileSystemEncoding.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\FileSystemEncoding.o )
+[ 4 of 22] Compiling Utility.Debug    ( Utility\Debug.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\Debug.o )
+[ 5 of 22] Compiling Utility.Misc     ( Utility\Misc.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\Misc.o )
+[ 6 of 22] Compiling Utility.Monad    ( Utility\Monad.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\Monad.o )
+[ 7 of 22] Compiling Utility.Process.Shim ( Utility\Process\Shim.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\Process\Shim.o )
+[ 8 of 22] Compiling Utility.SafeOutput ( Utility\SafeOutput.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\SafeOutput.o )
+[ 9 of 22] Compiling Utility.Exception ( Utility\Exception.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\Exception.o )
+[10 of 22] Compiling Utility.Process  ( Utility\Process.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\Process.o )
+[11 of 22] Compiling Utility.SafeCommand ( Utility\SafeCommand.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\SafeCommand.o )
+[12 of 22] Compiling Utility.Env.Basic ( Utility\Env\Basic.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\Env\Basic.o )
+[13 of 22] Compiling Build.Version    ( Build\Version.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Build\Version.o )
+[14 of 22] Compiling Utility.Split    ( Utility\Split.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\Split.o )
+[15 of 22] Compiling Utility.DottedVersion ( Utility\DottedVersion.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\DottedVersion.o )
+[16 of 22] Compiling Git.Version      ( Git\Version.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Git\Version.o )
+[17 of 22] Compiling Utility.SystemDirectory ( Utility\SystemDirectory.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\SystemDirectory.o )
+[18 of 22] Compiling Utility.Path     ( Utility\Path.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Utility\Path.o )
+[19 of 22] Compiling Build.TestConfig ( Build\TestConfig.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Build\TestConfig.o )
+[20 of 22] Compiling Build.Configure  ( Build\Configure.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Build\Configure.o )
+[21 of 22] Compiling Main             ( C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\Setup.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\Main.o )
+[22 of 22] Compiling StackSetupShim   ( C:\\hs-stack\setup-exe-src\setup-shim-9p6GVs8J.hs, C:\\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\dist\ed8db9df\setup\StackSetupShim.o )
+Linking C:\\Users\\jkniiv\\Projektit\\git-annex.branchable.com\\git-annex--BUILD-231130-10.20231129~P\\.stack-work\\dist\\ed8db9df\\setup\\setup.exe ...
+  checking UPGRADE_LOCATION... not available
+  checking git... yes
+  checking git version... 2.43.0.windows.1
+  checking cp -a... yes
+  checking cp -p... yes
+  checking cp --preserve=timestamps... yes
+  checking cp_reflink_supported... no
+  checking cp --no-preserve=xattr... yes
+  checking xargs -0... yes
+  checking rsync... no
+  checking curl... yes
+  checking bup... no
+  checking borg... no
+  checking nice... yes
+  checking ionice... no
+  checking nocache... no
+  checking gpg... gpg
+  checking lsof... not available
+  checking git-remote-gcrypt... not available
+  checking ssh connection caching... yes
+Configuring git-annex-10.20231129...
+git-annex> build (exe)
+Preprocessing executable 'git-annex' for git-annex-10.20231129..
+Building executable 'git-annex' for git-annex-10.20231129..
+[  1 of 693] Compiling Assistant.Types.BranchChange
+[  2 of 693] Compiling Assistant.Types.ThreadName
+[  3 of 693] Compiling Assistant.Types.TransferSlots
+[...snip...]
+[691 of 693] Compiling Command.Assistant
+[692 of 693] Compiling CmdLine.GitAnnex
+[693 of 693] Compiling Main
+Linking .stack-work\\dist\\ed8db9df\\build\\git-annex\\git-annex.exe ...
+git-annex> copy/register
+Installing executable git-annex in C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P\.stack-work\install\f241563d\bin
+C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P [BUILD-231130-10.20231129 +6 ~0 -0 !]> cp .\.stack-work\install\f241563d\bin\git-annex.exe .
+C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P [BUILD-231130-10.20231129 +7 ~0 -0 !]> .\git-annex.exe version > git-annex.version.TXT
+C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P [BUILD-231130-10.20231129 +7 ~0 -0 !]> head -1 .\git-annex.version.TXT
+git-annex version: 10.20231129-gbacd781c4fe05126219c4b5f2963677a6de01481
+C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P [BUILD-231130-10.20231129 +7 ~0 -0 !]> cat build.TXT
+git-annex--BUILD-231130-10.20231129~P
+resolver: lts-18.13
+C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P [BUILD-231130-10.20231129 +7 ~0 -0 !]> just copy-dlls-over-to-here
++ PATH='/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Program Files/PowerShell/7:<theRestRedacted />'
++ cd 'C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P'
+++ stack exec ldd -- git-annex.exe
+++ grep /mingw64
+++ cut '-d ' -f3
++ dlls_to_copy='/mingw64/bin/libmagic-1.dll
+/mingw64/bin/libsystre-0.dll
+/mingw64/bin/libtre-5.dll
+/mingw64/bin/libintl-8.dll'
++ stack exec cp -- -pv /mingw64/bin/libmagic-1.dll /mingw64/bin/libsystre-0.dll /mingw64/bin/libtre-5.dll /mingw64/bin/libintl-8.dll .
+'C:/Users/jkniiv/AppData/Local/Programs/stack/x86_64-windows/msys2-20200903/mingw64/bin/libmagic-1.dll' -> './libmagic-1.dll'
+'C:/Users/jkniiv/AppData/Local/Programs/stack/x86_64-windows/msys2-20200903/mingw64/bin/libsystre-0.dll' -> './libsystre-0.dll'
+'C:/Users/jkniiv/AppData/Local/Programs/stack/x86_64-windows/msys2-20200903/mingw64/bin/libtre-5.dll' -> './libtre-5.dll'
+'C:/Users/jkniiv/AppData/Local/Programs/stack/x86_64-windows/msys2-20200903/mingw64/bin/libintl-8.dll' -> './libintl-8.dll'
+C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P [BUILD-231130-10.20231129 +12 ~0 -0 !]> just install-files-to-annx-test-dir
++ PATH='/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Program Files/PowerShell/7:<theRestRedacted />'
++ cd 'C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-231130-10.20231129~P'
+++ shopt -s nullglob
+++ echo git-annex.exe libintl-8.dll libmagic-1.dll libsystre-0.dll libtre-5.dll build.TXT git-annex.version.TXT stack.build---flag-git-annex_Production.LOG~102 stack.build.LOG~102 stack.setup---verbose.LOG~101 CHANGELOG
++ files_to_copy='git-annex.exe libintl-8.dll libmagic-1.dll libsystre-0.dll libtre-5.dll build.TXT git-annex.version.TXT stack.build---flag-git-annex_Production.LOG~102 stack.build.LOG~102 stack.setup---verbose.LOG~101 CHANGELOG'
++ cp -pv git-annex.exe libintl-8.dll libmagic-1.dll libsystre-0.dll libtre-5.dll build.TXT git-annex.version.TXT stack.build---flag-git-annex_Production.LOG~102 stack.build.LOG~102 stack.setup---verbose.LOG~101 CHANGELOG .annx-test
+'git-annex.exe' -> '.annx-test/git-annex.exe'
+'libintl-8.dll' -> '.annx-test/libintl-8.dll'
+'libmagic-1.dll' -> '.annx-test/libmagic-1.dll'
+'libsystre-0.dll' -> '.annx-test/libsystre-0.dll'
+'libtre-5.dll' -> '.annx-test/libtre-5.dll'
+'build.TXT' -> '.annx-test/build.TXT'
+'git-annex.version.TXT' -> '.annx-test/git-annex.version.TXT'
+'stack.build---flag-git-annex_Production.LOG~102' -> '.annx-test/stack.build---flag-git-annex_Production.LOG~102'
+'stack.build.LOG~102' -> '.annx-test/stack.build.LOG~102'
+'stack.setup---verbose.LOG~101' -> '.annx-test/stack.setup---verbose.LOG~101'
+'CHANGELOG' -> '.annx-test/CHANGELOG'
+
+# End of transcript or log.
+"""]]
+
+And this is how I usually run the test suite in Git Bash (with some preliminary actions to record the tests available + make
+an SHA256SUMS file of the most important files in this test directory):
+
+[[!format sh """
+jkniiv@AINESIS MINGW64 ~/Projektit/git-annex.branchable.com/git-annex--BUILD-231130-10.20231129~P (BUILD-231130-10.20231129)
+$ cd .annx-test/
+
+jkniiv@AINESIS MINGW64 ~/Projektit/git-annex.branchable.com/git-annex--BUILD-231130-10.20231129~P/.annx-test (BUILD-231130-10.20231129)
+$ just record-tests
+./git-annex.exe test --list-tests > git-annex.test---list-tests.TXT
+
+jkniiv@AINESIS MINGW64 ~/Projektit/git-annex.branchable.com/git-annex--BUILD-231130-10.20231129~P/.annx-test (BUILD-231130-10.20231129)
+$ just sums check-sums
+sha256sum git-annex.exe libintl-8.dll libmagic-1.dll libsystre-0.dll libtre-5.dll build.TXT git-annex.test---list-tests.
+TXT git-annex.version.TXT > SHA256SUMS
+sha256sum -c SHA256SUMS
+git-annex.exe: OK
+libintl-8.dll: OK
+libmagic-1.dll: OK
+libsystre-0.dll: OK
+libtre-5.dll: OK
+build.TXT: OK
+git-annex.test---list-tests.TXT: OK
+git-annex.version.TXT: OK
+
+jkniiv@AINESIS MINGW64 ~/Projektit/git-annex.branchable.com/git-annex--BUILD-231130-10.20231129~P/.annx-test (BUILD-231130-10.20231129)
+$ ls -l
+total 73065
+-rw-r--r-- 1 jkniiv 197121   429145 Dec  8 14:28 CHANGELOG
+-rw-r--r-- 1 jkniiv 197121     1073 Dec 14  2022 Justfile
+-rw-r--r-- 1 jkniiv 197121      664 Dec  8 16:48 SHA256SUMS
+-rw-r--r-- 1 jkniiv 197121       60 Dec  8 15:27 build.TXT
+-rwxr-xr-x 1 jkniiv 197121 73740800 Dec  8 16:41 git-annex.exe*
+-rw-r--r-- 1 jkniiv 197121     8464 Dec  8 16:48 git-annex.test---list-tests.TXT
+-rw-r--r-- 1 jkniiv 197121     1112 Dec  8 16:42 git-annex.version.TXT
+-rwxr-xr-x 1 jkniiv 197121   187145 Nov 23 11:21 libintl-8.dll*
+-rwxr-xr-x 1 jkniiv 197121   226435 Dec  4 20:11 libmagic-1.dll*
+-rwxr-xr-x 1 jkniiv 197121    18240 Jan 17  2018 libsystre-0.dll*
+-rwxr-xr-x 1 jkniiv 197121    92313 Jan 17  2018 libtre-5.dll*
+-rw-r--r-- 1 jkniiv 197121    37834 Dec  8 16:41 stack.build---flag-git-annex_Production.LOG~102
+-rw-r--r-- 1 jkniiv 197121    37834 Dec  8 15:45 stack.build.LOG~102
+-rw-r--r-- 1 jkniiv 197121     2757 Dec  8 16:25 stack.setup---verbose.LOG~101
+
+jkniiv@AINESIS MINGW64 ~/Projektit/git-annex.branchable.com/git-annex--BUILD-231130-10.20231129~P/.annx-test (BUILD-231130-10.20231129)
+$ ldd git-annex.exe
+        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff93f190000)
+        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff93e380000)
+        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ff93c9d0000)
+        ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7ff93e870000)
+        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ff93d2b0000)
+        libmagic-1.dll => /c/Users/jkniiv/Projektit/git-annex.branchable.com/git-annex--BUILD-231130-10.20231129~P/.annx-test/libmagic-1.dll (0x7ff8fd370000)
+        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ff93e250000)
+        SHLWAPI.dll => /c/WINDOWS/System32/SHLWAPI.dll (0x7ff93e440000)
+        libsystre-0.dll => /c/Users/jkniiv/Projektit/git-annex.branchable.com/git-annex--BUILD-231130-10.20231129~P/.annx-test/libsystre-0.dll (0x6bcc0000)
+        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ff93e120000)
+        CRYPT32.dll => /c/WINDOWS/System32/CRYPT32.dll (0x7ff93d090000)
+        libtre-5.dll => /c/Users/jkniiv/Projektit/git-annex.branchable.com/git-annex--BUILD-231130-10.20231129~P/.annx-test/libtre-5.dll (0x63bc0000)
+        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ff93cf00000)
+        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ff93d1f0000)
+        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ff93ced0000)
+        libintl-8.dll => /c/Users/jkniiv/Projektit/git-annex.branchable.com/git-annex--BUILD-231130-10.20231129~P/.annx-test/libintl-8.dll (0x7ff8f3d20000)
+        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ff93ccd0000)
+        dbghelp.dll => /c/WINDOWS/SYSTEM32/dbghelp.dll (0x7ff93ae50000)
+        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ff93c8c0000)
+        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ff93d6c0000)
+        ole32.dll => /c/WINDOWS/System32/ole32.dll (0x7ff93d4e0000)
+        libiconv-2.dll => /c/Users/jkniiv/bin/libiconv-2.dll (0x7ff8a6e00000)
+        combase.dll => /c/WINDOWS/System32/combase.dll (0x7ff93e510000)
+        IPHLPAPI.DLL => /c/WINDOWS/SYSTEM32/IPHLPAPI.DLL (0x7ff93bbf0000)
+        SHELL32.dll => /c/WINDOWS/System32/SHELL32.dll (0x7ff93d900000)
+        WS2_32.dll => /c/WINDOWS/System32/WS2_32.dll (0x7ff93d860000)
+        WINMM.dll => /c/WINDOWS/SYSTEM32/WINMM.dll (0x7ff928e00000)
+        CRYPTBASE.DLL => /c/WINDOWS/SYSTEM32/CRYPTBASE.DLL (0x7ff93c070000)
+        dbgcore.DLL => /c/WINDOWS/SYSTEM32/dbgcore.DLL (0x7ff928dc0000)
+
+jkniiv@AINESIS MINGW64 ~/Projektit/git-annex.branchable.com/git-annex--BUILD-231130-10.20231129~P/.annx-test (BUILD-231130-10.20231129)
+$ just tests-new
+/usr/bin/time ./git-annex.exe test  2>&1 | tee git-annex.test.LOG~200
+
+All 0 tests passed (0.00s)
+Tests
+  Repo Tests v10 adjusted unlocked branch
+    Init Tests
+      init:                          OK (9.36s)
+      add:                           FAIL
+        Exception: fd:4: hGetChar: invalid argument (invalid byte sequence)
+        Use -p '/Init Tests.add/' to rerun this test only.
+    crypto:                          SKIP
+
+      Use -p '/crypto/' to rerun this test only.
+    uninit (in git-annex branch):    SKIP
+
+      Use -p '/uninit (in git-annex branch)/' to rerun this test only.
+    conflict resolution symlink bit: SKIP
+
+      Use -p '/conflict resolution symlink bit/' to rerun this test only.
+    union merge regression:          SKIP
+
+      Use -p '/union merge regression/' to rerun this test only.
+    unused:                          SKIP
+
+      Use -p '/unused/' to rerun this test only.
+    fsck (bare):                     SKIP
+
+      Use -p '/fsck (bare)/' to rerun this test only.
+    lock:                            SKIP
+
+      Use -p '/Repo Tests v10 adjusted unlocked branch.lock/' to rerun this test only.
+    drop (with remote):              SKIP
+
+      Use -p '/drop (with remote)/' to rerun this test only.
+    log:                             SKIP
+
+      Use -p '/log/' to rerun this test only.
+    add extras:                      SKIP
+
+      Use -p '/add extras/' to rerun this test only.
+
+11 out of 12 tests failed (11.65s)
+Tests
+  QuickCheck
+    prop_quote_unquote_roundtrip:            OK (0.10s)
+      +++ OK, passed 1000 tests.
+    prop_encode_c_decode_c_roundtrip:        OK (0.11s)
+      +++ OK, passed 1000 tests.
+    prop_isomorphic_key_encode:              OK (0.05s)
+      +++ OK, passed 1000 tests.
+    prop_isomorphic_shellEscape:             OK (0.04s)
+      +++ OK, passed 1000 tests.
+    prop_isomorphic_shellEscape_multiword:   OK (1.25s)
+      +++ OK, passed 1000 tests.
+    prop_isomorphic_configEscape:            OK (0.03s)
+      +++ OK, passed 1000 tests.
+    prop_parse_show_Config:                  OK (0.08s)
+      +++ OK, passed 1000 tests.
+    prop_upFrom_basics:                      OK
+      +++ OK, passed 1000 tests.
+    prop_relPathDirToFileAbs_basics:         OK (0.04s)
+      +++ OK, passed 1000 tests.
+    prop_relPathDirToFileAbs_regressionTest: OK
+      +++ OK, passed 1 test.
+    prop_dirContains_regressionTest:         OK
+      +++ OK, passed 1 test.
+    prop_cost_sane:                          OK
+      +++ OK, passed 1 test.
+    prop_matcher_sane:                       OK
+      +++ OK, passed 1 test.
+    prop_HmacSha1WithCipher_sane:            OK
+      +++ OK, passed 1 test.
+    prop_VectorClock_sane:                   OK
+      +++ OK, passed 1 test.
+    prop_addMapLog_sane:                     OK
+      +++ OK, passed 1 test.
+    prop_verifiable_sane:                    OK (0.11s)
+      +++ OK, passed 1000 tests.
+    prop_segment_regressionTest:             OK
+      +++ OK, passed 1 test.
+    prop_read_write_transferinfo:            OK (0.06s)
+      +++ OK, passed 1000 tests.
+    prop_read_show_inodecache:               OK (0.04s)
+      +++ OK, passed 1000 tests.
+    prop_parse_build_presence_log:           OK (1.92s)
+      +++ OK, passed 1000 tests.
+    prop_parse_build_contentidentifier_log:  OK (1.65s)
+      +++ OK, passed 1000 tests.
+    prop_read_show_TrustLevel:               OK
+      +++ OK, passed 1 test.
+    prop_parse_build_TrustLevelLog:          OK
+      +++ OK, passed 1 test.
+    prop_schedule_roundtrips:                OK (0.01s)
+      +++ OK, passed 1000 tests.
+    prop_past_sane:                          OK
+      +++ OK, passed 1 test.
+    prop_duration_roundtrips:                OK
+      +++ OK, passed 1000 tests.
+    prop_metadata_sane:                      OK (1.00s)
+      +++ OK, passed 1000 tests.
+    prop_metadata_serialize:                 OK (1.07s)
+      +++ OK, passed 1000 tests.
+    prop_branchView_legal:                   OK (1.10s)
+      +++ OK, passed 1000 tests.
+    prop_viewPath_roundtrips:                OK (0.02s)
+      +++ OK, passed 1000 tests.
+    prop_view_roundtrips:                    OK (0.55s)
+      +++ OK, passed 1000 tests.
+    prop_viewedFile_rountrips:               OK (0.04s)
+      +++ OK, passed 1000 tests.
+    prop_standardGroups_parse:               OK
+      +++ OK, passed 1 test.
+    sha1 stable:                             OK
+      +++ OK, passed 1 test.
+    sha2_224 stable:                         OK
+      +++ OK, passed 1 test.
+    sha2_256 stable:                         OK
+      +++ OK, passed 1 test.
+    sha2_384 stable:                         OK
+      +++ OK, passed 1 test.
+    sha2_512 stable:                         OK
+      +++ OK, passed 1 test.
+    skein256 stable:                         OK
+      +++ OK, passed 1 test.
+    skein512 stable:                         OK
+      +++ OK, passed 1 test.
+    sha3_224 stable:                         OK
+      +++ OK, passed 1 test.
+    sha3_256 stable:                         OK
+      +++ OK, passed 1 test.
+    sha3_384 stable:                         OK
+      +++ OK, passed 1 test.
+    sha3_512 stable:                         OK
+      +++ OK, passed 1 test.
+    blake2s_160 stable:                      OK
+      +++ OK, passed 1 test.
+    blake2s_224 stable:                      OK
+      +++ OK, passed 1 test.
+    blake2s_256 stable:                      OK
+      +++ OK, passed 1 test.
+    blake2sp_224 stable:                     OK
+      +++ OK, passed 1 test.
+    blake2sp_256 stable:                     OK
+      +++ OK, passed 1 test.
+    blake2b_160 stable:                      OK
+      +++ OK, passed 1 test.
+    blake2b_224 stable:                      OK
+      +++ OK, passed 1 test.
+    blake2b_256 stable:                      OK
+      +++ OK, passed 1 test.
+    blake2b_384 stable:                      OK
+      +++ OK, passed 1 test.
+    blake2b_512 stable:                      OK
+      +++ OK, passed 1 test.
+    blake2bp_512 stable:                     OK
+      +++ OK, passed 1 test.
+    md5 stable:                              OK
+      +++ OK, passed 1 test.
+    HmacSha1 stable:                         OK
+      +++ OK, passed 1 test.
+    HmacSha224 stable:                       OK
+      +++ OK, passed 1 test.
+    HmacSha256 stable:                       OK
+      +++ OK, passed 1 test.
+    HmacSha384 stable:                       OK
+      +++ OK, passed 1 test.
+    HmacSha512 stable:                       OK
+      +++ OK, passed 1 test.
+
+All 62 tests passed (9.40s)
+Tests
+  Repo Tests v10 adjusted unlocked branch
+    Init Tests
+      init:                                OK (9.46s)
+      add:                                 FAIL
+        Exception: fd:4: hGetChar: invalid argument (invalid byte sequence)
+        Use -p '/add/' to rerun this test only.
+    bup remote:                            SKIP
+
+      Use -p '/bup remote/' to rerun this test only.
+    map:                                   SKIP
+
+      Use -p '/map/' to rerun this test only.
+    conflict resolution movein regression: SKIP
+
+      Use -p '/conflict resolution movein regression/' to rerun this test only.
+    sync:                                  SKIP
+
+      Use -p '/sync/' to rerun this test only.
+    migrate:                               SKIP
+
+      Use -p '/migrate/' to rerun this test only.
+    trust:                                 SKIP
+
+      Use -p '/trust/' to rerun this test only.
+    move (numcopies):                      SKIP
+
+      Use -p '/move (numcopies)/' to rerun this test only.
+    unannex (with copy):                   SKIP
+
+      Use -p '/unannex (with copy)/' to rerun this test only.
+    export and import of subdir:           SKIP
+
+      Use -p '/export and import of subdir/' to rerun this test only.
+
+10 out of 11 tests failed (11.84s)
+Tests
+  Repo Tests v10 adjusted unlocked branch
+    Init Tests
+      init:                                         OK (9.47s)
+      add:                                          FAIL
+        Exception: fd:4: hGetChar: invalid argument (invalid byte sequence)
+        Use -p '/Init Tests.add/' to rerun this test only.
+    borg remote:                                    SKIP
+
+      Use -p '/borg remote/' to rerun this test only.
+    uninit:                                         SKIP
+
+      Use -p '/uninit/' to rerun this test only.
+    conflict resolution (mixed directory and file): SKIP
+
+      Use -p '/conflict resolution (mixed directory and file)/' to rerun this test only.
+    concurrent get of dup key regression:           SKIP
+
+      Use -p '/concurrent get of dup key regression/' to rerun this test only.
+    migrate (via gitattributes):                    SKIP
+
+      Use -p '/migrate (via gitattributes)/' to rerun this test only.
+    fsck (basics):                                  SKIP
+
+      Use -p '/fsck (basics)/' to rerun this test only.
+    copy:                                           SKIP
+
+      Use -p '/copy/' to rerun this test only.
+    drop (no remote):                               SKIP
+
+      Use -p '/drop (no remote)/' to rerun this test only.
+    shared clone:                                   SKIP
+
+      Use -p '/shared clone/' to rerun this test only.
+    add dup:                                        SKIP
+
+      Use -p '/add dup/' to rerun this test only.
+
+11 out of 12 tests failed (11.82s)
+Tests
+  Repo Tests v10 adjusted unlocked branch
+    Init Tests
+      init:                                   OK (8.97s)
+      add:                                    FAIL
+        Exception: fd:4: hGetChar: invalid argument (invalid byte sequence)
+        Use -p '/Init Tests.add/' to rerun this test only.
+    addurl:                                   SKIP
+
+      Use -p '/addurl/' to rerun this test only.
+    directory remote:                         SKIP
+
+      Use -p '/directory remote/' to rerun this test only.
+    conflict resolution (nonannexed symlink): SKIP
+
+      Use -p '/conflict resolution (nonannexed symlink)/' to rerun this test only.
+    conflict resolution:                      SKIP
+
+      Use -p '$0=="Tests.Repo Tests v10 adjusted unlocked branch.conflict resolution"' to rerun this test only.
+    info:                                     SKIP
+
+      Use -p '/info/' to rerun this test only.
+    conversion git to annexed:                SKIP
+
+      Use -p '/conversion git to annexed/' to rerun this test only.
+    partial commit:                           SKIP
+
+      Use -p '/partial commit/' to rerun this test only.
+    move:                                     SKIP
+
+      Use -p '/move/' to rerun this test only.
+    reinject:                                 SKIP
+
+      Use -p '/reinject/' to rerun this test only.
+    metadata:                                 SKIP
+
+      Use -p '/metadata/' to rerun this test only.
+
+11 out of 12 tests failed (11.20s)
+Tests
+  Repo Tests v10 adjusted unlocked branch
+    Init Tests
+      init:                                       OK (9.18s)
+      add:                                        FAIL
+        Exception: fd:4: hGetChar: invalid argument (invalid byte sequence)
+        Use -p '/Init Tests.add/' to rerun this test only.
+    preferred content:                            SKIP
+
+      Use -p '/preferred content/' to rerun this test only.
+    upgrade:                                      SKIP
+
+      Use -p '/upgrade/' to rerun this test only.
+    conflict resolution (uncommitted local file): SKIP
+
+      Use -p '/conflict resolution (uncommitted local file)/' to rerun this test only.
+    adjusted branch merge regression:             SKIP
+
+      Use -p '/adjusted branch merge regression/' to rerun this test only.
+    describe:                                     SKIP
+
+      Use -p '/describe/' to rerun this test only.
+    fsck (local untrusted):                       SKIP
+
+      Use -p '/fsck (local untrusted)/' to rerun this test only.
+    lock --force:                                 SKIP
+
+      Use -p '/lock --force/' to rerun this test only.
+    drop (untrusted remote):                      SKIP
+
+      Use -p '/drop (untrusted remote)/' to rerun this test only.
+    view:                                         SKIP
+
+      Use -p '/view/' to rerun this test only.
+    add moved link:                               SKIP
+
+      Use -p '/add moved link/' to rerun this test only.
+
+11 out of 12 tests failed (11.64s)
+Tests
+  Repo Tests v10 adjusted unlocked branch
+    Init Tests
+      init:                                OK (9.02s)
+      add:                                 FAIL
+        Exception: fd:4: hGetChar: invalid argument (invalid byte sequence)
+        Use -p '/Init Tests.add/' to rerun this test only.
+    add subdirs:                           SKIP
+
+      Use -p '/add subdirs/' to rerun this test only.
+    hook remote:                           SKIP
+
+      Use -p '/hook remote/' to rerun this test only.
+    conflict resolution (nonannexed file): SKIP
+
+      Use -p '/conflict resolution (nonannexed file)/' to rerun this test only.
+    transition propagation:                SKIP
+
+      Use -p '/transition propagation/' to rerun this test only.
+    merge:                                 SKIP
+
+      Use -p '/merge/' to rerun this test only.
+    fsck --from remote:                    SKIP
+
+      Use -p '/fsck --from remote/' to rerun this test only.
+    edit (pre-commit):                     SKIP
+
+      Use -p '/edit (pre-commit)/' to rerun this test only.
+    get (ssh remote):                      SKIP
+
+      Use -p '/get (ssh remote)/' to rerun this test only.
+    import:                                SKIP
+
+      Use -p '/import/' to rerun this test only.
+    ignore deleted files:                  SKIP
+
+      Use -p '/ignore deleted files/' to rerun this test only.
+
+11 out of 12 tests failed (11.22s)
+Tests
+  Repo Tests v10 adjusted unlocked branch
+    Init Tests
+      init:                             OK (8.99s)
+      add:                              FAIL
+        Exception: fd:4: hGetChar: invalid argument (invalid byte sequence)
+        Use -p '/add/' to rerun this test only.
+    required_content:                   SKIP
+
+      Use -p '/required_content/' to rerun this test only.
+    whereis:                            SKIP
+
+      Use -p '/whereis/' to rerun this test only.
+    conflict resolution (removed file): SKIP
+
+      Use -p '/conflict resolution (removed file)/' to rerun this test only.
+    adjusted branch subtree regression: SKIP
+
+      Use -p '/adjusted branch subtree regression/' to rerun this test only.
+    find:                               SKIP
+
+      Use -p '/find/' to rerun this test only.
+    fsck (remote untrusted):            SKIP
+
+      Use -p '/fsck (remote untrusted)/' to rerun this test only.
+    edit (no pre-commit):               SKIP
+
+      Use -p '/edit (no pre-commit)/' to rerun this test only.
+    get:                                SKIP
+
+      Use -p '/get/' to rerun this test only.
+    magic:                              SKIP
+
+      Use -p '/magic/' to rerun this test only.
+    readonly remote:                    SKIP
+
+      Use -p '/readonly remote/' to rerun this test only.
+
+11 out of 12 tests failed (11.22s)
+Tests
+  Repo Tests v10 adjusted unlocked branch
+    Init Tests
+      init:                                               OK (5.91s)
+      add:                                                FAIL
+        Exception: fd:4: hGetChar: invalid argument (invalid byte sequence)
+        Use -p '/add/' to rerun this test only.
+    repair:                                               SKIP
+
+      Use -p '/repair/' to rerun this test only.
+    rsync remote:                                         SKIP
+
+      Use -p '/rsync remote/' to rerun this test only.
+    conflict resolution (mixed locked and unlocked file): SKIP
+
+      Use -p '/conflict resolution (mixed locked and unlocked file)/' to rerun this test only.
+    conflict resolution (adjusted branch):                SKIP
+
+      Use -p '/conflict resolution (adjusted branch)/' to rerun this test only.
+    version:                                              SKIP
+
+      Use -p '/Repo Tests v10 adjusted unlocked branch.version/' to rerun this test only.
+    conversion annexed to git:                            SKIP
+
+      Use -p '/conversion annexed to git/' to rerun this test only.
+    fix:                                                  SKIP
+
+      Use -p '/fix/' to rerun this test only.
+    move (ssh remote):                                    SKIP
+
+      Use -p '/move (ssh remote)/' to rerun this test only.
+    unannex (no copy):                                    SKIP
+
+      Use -p '/unannex (no copy)/' to rerun this test only.
+    export and import:                                    SKIP
+
+      Use -p '/export and import/' to rerun this test only.
+
+11 out of 12 tests failed (7.23s)
+  (Failures above could be due to a bug in git-annex, or an incompatibility
+   with utilities, such as git, installed on this system.)
+Command exited with non-zero status 1
+0.00user 0.04system 0:31.25elapsed 0%CPU (0avgtext+0avgdata 5248maxresident)k
+0inputs+0outputs (1391major+0minor)pagefaults 0swaps
+
+jkniiv@AINESIS MINGW64 ~/Projektit/git-annex.branchable.com/git-annex--BUILD-231130-10.20231129~P/.annx-test (BUILD-231130-10.20231129)
+$ ./git-annex.exe test -p ' /Init Tests.add/'
+
+All 0 tests passed (0.00s)
+Tests
+  Repo Tests v10 adjusted unlocked branch
+    Init Tests
+      init: OK (5.02s)
+      add:  FAIL
+        Exception: fd:4: hGetChar: invalid argument (invalid byte sequence)
+        Use -p '(/Init Tests.add/||/Init Tests/)&&/add/' to rerun this test only.
+
+1 out of 2 tests failed (6.37s)
+
+All 0 tests passed (0.00s)
+  (Failures above could be due to a bug in git-annex, or an incompatibility
+   with utilities, such as git, installed on this system.)
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sure, Git Annex is great as always. I use it several times a week with my multigigabyte
+backups, where it gives structure to my image-based backup routines, so you could
+say I'm a believer. :)
+
+[[!meta author=jkniiv]]
+
+### Update 20 Dec 2023
+
+P.S. This is a bit embarrasing but I found out this is [[notabug|done]], cf. my comment --[[jkniiv]]
diff --git a/doc/bugs/__39__Production__39___build_doesn__39__t_pass_testsuite_on_Win32/comment_1_7ac6938faef9111da701080a62c4d7e9._comment b/doc/bugs/__39__Production__39___build_doesn__39__t_pass_testsuite_on_Win32/comment_1_7ac6938faef9111da701080a62c4d7e9._comment
new file mode 100644
index 0000000000..6b70005ccf
--- /dev/null
+++ b/doc/bugs/__39__Production__39___build_doesn__39__t_pass_testsuite_on_Win32/comment_1_7ac6938faef9111da701080a62c4d7e9._comment
@@ -0,0 +1,67 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="my report was actually a User Failure on my part"
+ date="2023-12-19T23:02:15Z"
+ content="""
+Uh-oh, after adding the option `--test-debug` to the `test` subcommand I got a lead on
+the real culprit and it wasn't git-annex but libmagic:
+
+[[!format sh \"\"\"
+[...snip...]
+ok
+[2023-12-19 22:52:17.5370274] (Utility.Process) process [21636] done ExitSuccess
+[2023-12-19 22:52:17.5460328] (Utility.Process) process [10460] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-p
+athspecs\",\"-c\",\"annex.debug=true\",\"ls-files\",\"-z\",\"--modified\",\"--\",\"foo\"]
+[2023-12-19 22:52:17.5970346] (Utility.Process) process [10460] done ExitSuccess
+[2023-12-19 22:52:17.6030281] (Utility.Process) process [9208] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pa
+thspecs\",\"-c\",\"annex.debug=true\",\"diff\",\"--name-only\",\"--diff-filter=T\",\"-z\",\"--cached\",\"--\",\"foo\"]
+[2023-12-19 22:52:17.6550242] (Utility.Process) process [9208] done ExitSuccess
+(recording state in git...)
+[2023-12-19 22:52:17.6650254] (Utility.Process) process [24064] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-p
+athspecs\",\"-c\",\"annex.debug=true\",\"update-index\",\"-z\",\"--index-info\"]
+[2023-12-19 22:52:17.7090277] (Utility.Process) process [24064] done ExitSuccess
+[2023-12-19 22:52:17.7240248] (Utility.Process) process [22248] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-p
+athspecs\",\"-c\",\"annex.debug=true\",\"update-index\",\"-z\",\"--index-info\"]
+[2023-12-19 22:52:17.7700259] (Utility.Process) process [22248] done ExitSuccess
+[2023-12-19 22:52:17.7780282] (Utility.Process) process [23188] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-p
+athspecs\",\"-c\",\"annex.debug=true\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2023-12-19 22:52:17.8270228] (Utility.Process) process [23188] done ExitSuccess
+[2023-12-19 22:52:17.8340274] (Utility.Process) process [17648] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-p
+athspecs\",\"-c\",\"annex.debug=true\",\"update-index\",\"-z\",\"--index-info\"]
+[2023-12-19 22:52:17.8420331] (Utility.Process) process [21928] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-p
+athspecs\",\"-c\",\"annex.debug=true\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"refs/heads/git-annex\",
+\"--\"]
+[2023-12-19 22:52:17.8980416] (Utility.Process) process [21928] done ExitSuccess
+[2023-12-19 22:52:17.9060216] (Utility.Process) process [17648] done ExitSuccess
+[2023-12-19 22:52:17.920024] (Utility.Process) process [18680] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pa
+thspecs\",\"-c\",\"annex.debug=true\",\"write-tree\"]
+[2023-12-19 22:52:17.982027] (Utility.Process) process [18680] done ExitSuccess
+[2023-12-19 22:52:17.9890276] (Utility.Process) process [10892] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-p
+athspecs\",\"-c\",\"annex.debug=true\",\"commit-tree\",\"bb68ce15d91f27eec51749b9481ede5cc6bcd190\",\"--no-gpg-sign\",\"-p\",\"refs/he
+ads/git-annex\"]
+[2023-12-19 22:52:18.0490233] (Utility.Process) process [10892] done ExitSuccess
+[2023-12-19 22:52:18.0570304] (Utility.Process) process [6552] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pa
+thspecs\",\"-c\",\"annex.debug=true\",\"update-ref\",\"refs/heads/git-annex\",\"71b9bb13e4244bd2233de7ca7cf7fc01011f1e62\"]
+[2023-12-19 22:52:18.1170343] (Utility.Process) process [6552] done ExitSuccess
+[2023-12-19 22:52:18.1300416] (Utility.Process) process [10116] done ExitSuccess
+[2023-12-19 22:52:18.1350241] (Utility.Process) process [20976] done ExitSuccess
+[2023-12-19 22:52:18.1400231] (Utility.Process) process [9880] done ExitSuccess
+[2023-12-19 22:52:18.1450249] (Utility.Process) process [872] done ExitSuccess
+C:\Users\jkniiv\AppData\Local/.magic/magic.mgc, 1: Warning: offset `∟♦▲FAIL (2.36s)
+        .\\Test\\Framework.hs:83:
+        add with SHA1 failed with unexpected exit code
+        Use -p '(/Init Tests.add/||/Init Tests/)&&/add/' to rerun this test only.
+
+1 out of 2 tests failed (8.86s)
+git-annex: thread blocked indefinitely in an STM transaction
+
+\"\"\"]]
+
+So the real error turned out to be a user failure of mine: libmagic (or the msys2 package `mingw-w64-x86_64-file`)
+had a recent update and the new library didn't like my previous magic database located in the fallback location
+`%localappdata%\.magic\magic.mgc`. By copying the msys2 file `/mingw64/share/misc/magic.mgc` to the aforementioned
+location, the whole issue cleared itself and this report became moot.
+
+
+"""]]
diff --git a/doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo.mdwn b/doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo.mdwn
new file mode 100644
index 0000000000..cb3c7ef813
--- /dev/null
+++ b/doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo.mdwn
@@ -0,0 +1,40 @@
+### Please describe the problem.
+massive repo, max cpu using
+
+    git annex add .
+
+had to interrupt the job as it was processing 1 small file per 5 seconds after about 3h run.
+
+I am running it on the root of a large (currently 1TB) exFAT-based drive used for archiving
+
+The repo grew to 28G.
+
+Is this a regular issue with exFAT? I've done quite a bit of searching. I'll do more.
+
+### What steps will reproduce the problem?
+- install on El Capitan (latest) via homebrew
+- create 1TB exFAT file store
+- follow walk through to setup annex locally and on external
+- add
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 6.20160126
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+
+El Capitan 10.11.3
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I'd love to say I have. You'll hear my shout of joy when I do.
diff --git a/doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo/comment_1_3233c29405da296360d57af7d5eb418d._comment b/doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo/comment_1_3233c29405da296360d57af7d5eb418d._comment
new file mode 100644
index 0000000000..4bd283aa22
--- /dev/null
+++ b/doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo/comment_1_3233c29405da296360d57af7d5eb418d._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-03-14T17:59:08Z"
+ content="""
+If I've done the math right, 5 files per second over 3 hours is only 2000 files.
+The size of the files does matter, since git-annex has to read them all.
+You said the repo grew to 28 gb; does that mean you added 2000 files
+totalling 28 gb in size?
+
+I can add 2000 tiny files (5 bytes each) in 2 seconds on a SSD on Linux.
+
+By using a FAT filesystem, you've forced git-annex to use direct mode.
+Direct mode can be a little slower, but not a great deal. Adding 2000 files
+to a direct mode repo takes around 11 seconds here. (I did a little
+optimisation and sped that up to 7 seconds.)
+
+Doing the same benchmark on a removable USB stick with a FAT filesystem
+was still not slow; 7 seconds again.
+
+But then I had linux mount that FAT filesystem sync (so, it flushes each
+file write to disk, not buffering them), and I start getting closer to your
+slow speed; benchmark took 53 minutes.
+
+So, I think the slow speed you're seeing is quite likely due to a
+combination of, in order from most to least important:
+
+1. Synchronous writes to your disk drive. Fixable in linux by eg, running
+   "mount -o remount,async /path/to/repo" and there's probably something
+   similar for OSX.
+2. External drive being slow to access. (And if a spinning disk, slow to
+   seek.)
+3. git-annex using direct mode on FAT
+
+Also there is a fair amount of faff that git-annex does when adding a file
+around calling rename, stat, mkdir, etc multiple times. It may be possible
+to optimize some of that to get at some speedup on synchronous disks.
+But, I'd not expect more than a few percentage points speedup from such
+optimisation.
+
+One other possiblity is you could be hitting an edge case where direct mode's
+performace is bad. One known such edge case is if you have a lot of files
+that all have the same content. For example, I made 2000 files that were
+all empty; adding them to a direct mode repository gets slower and slower
+to the point it's spending 10 or more seconds per file. 
+"""]]
diff --git a/doc/bugs/__39__git_annex_assist__39___doesn__39__t_honor_--jobs.mdwn b/doc/bugs/__39__git_annex_assist__39___doesn__39__t_honor_--jobs.mdwn
new file mode 100644
index 0000000000..8ef89034ef
--- /dev/null
+++ b/doc/bugs/__39__git_annex_assist__39___doesn__39__t_honor_--jobs.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+It seems that `git annex assist` doesn't actually do multiprocessing despite `--jobs=cpus` or `git config annex.jobs cpus`
+
+### What steps will reproduce the problem?
+
+- make an annex repo
+- add more than one remote to it
+- add some files
+- run `git annex assist --jobs` (operates sequentially)
+- run `git annex sync --jobs` (operates in parallel)
+- set `git config annex.jobs cpus`
+- run `git annex assist` (operates sequentially)
+- run `git annex sync` (operates in parallel)
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+❯ git annex version
+git-annex version: 10.20230627-g06f734555
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+"""]]
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git-annex is **marvellous** and a game-changer for all my workflows 👍
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/__39__git_annex_assist__39___doesn__39__t_honor_--jobs/comment_1_96b3c705c7c83b153cde2e8bb16ed380._comment b/doc/bugs/__39__git_annex_assist__39___doesn__39__t_honor_--jobs/comment_1_96b3c705c7c83b153cde2e8bb16ed380._comment
new file mode 100644
index 0000000000..6717fa0747
--- /dev/null
+++ b/doc/bugs/__39__git_annex_assist__39___doesn__39__t_honor_--jobs/comment_1_96b3c705c7c83b153cde2e8bb16ed380._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-05T16:00:25Z"
+ content="""
+Reproduced. The adds do run in parallel, the content transfers do not.
+"""]]
diff --git a/doc/bugs/__47__exe__47__git-annex.mdwn b/doc/bugs/__47__exe__47__git-annex.mdwn
new file mode 100644
index 0000000000..8d7e157f3d
--- /dev/null
+++ b/doc/bugs/__47__exe__47__git-annex.mdwn
@@ -0,0 +1,51 @@
+### Please describe the problem.
+
+
+### What steps will reproduce the problem?
+I have system:
+Linux RPI-4B 5.15.74-2-MANJARO-ARM-RPI #1 SMP PREEMPT Thu Oct 20 16:43:17 UTC 2022 aarch64 GNU/Linux
+
+Doesnt't have git-annex in aur and pacman.
+So download git-annex-standalone-arm64.tar.gz from web.
+./runshell
+
+```git-annex enable-tor                                                     (adjusted/master(unlocked)+2) 10:25:22 
+enable-tor 
+  You may be prompted for a password
+
+git-annex: Failed to run as root: /home/gyurmo/.local/git-annex.linux/bin/git-annex enable-tor 1000
+failed
+enable-tor: 1 failed```
+
+
+sudo /home/gyurmo/.local/git-annex.linux/bin/git-annex enable-tor 1000
+[sudo] gyurmo jelszava: 
+/home/gyurmo/.local/git-annex.linux/bin/git-annex: sor: 4: /exe/git-annex: No such file or directory
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20220121-g0bcb94487
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux aarch64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/__47__exe__47__git-annex/comment_1_8a9e9d83a3dcf07ed76a22f03636f6d1._comment b/doc/bugs/__47__exe__47__git-annex/comment_1_8a9e9d83a3dcf07ed76a22f03636f6d1._comment
new file mode 100644
index 0000000000..45c0e01b52
--- /dev/null
+++ b/doc/bugs/__47__exe__47__git-annex/comment_1_8a9e9d83a3dcf07ed76a22f03636f6d1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-10-26T18:53:40Z"
+ content="""
+Using this command instead should work:
+
+	sudo /home/gyurmo/.local/git-annex.linux/git-annex enable-tor 1000
+"""]]
diff --git a/doc/bugs/__47__exe__47__git-annex/comment_2_381ac4e8b27343cdc470584c05edec76._comment b/doc/bugs/__47__exe__47__git-annex/comment_2_381ac4e8b27343cdc470584c05edec76._comment
new file mode 100644
index 0000000000..6db2b4d8bf
--- /dev/null
+++ b/doc/bugs/__47__exe__47__git-annex/comment_2_381ac4e8b27343cdc470584c05edec76._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-10-26T19:44:24Z"
+ content="""
+And I've fixed this problem now.
+"""]]
diff --git a/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__.mdwn b/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__.mdwn
new file mode 100644
index 0000000000..8f10b83bca
--- /dev/null
+++ b/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__.mdwn
@@ -0,0 +1,3 @@
+### Please describe the problem.
+
+Adding a comment or a bug takes easily 15 seconds after pressing “Submit” or “Save”…
diff --git a/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_1_3afce2aadeb2221c66f397e631d0e4a6._comment b/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_1_3afce2aadeb2221c66f397e631d0e4a6._comment
new file mode 100644
index 0000000000..6ec99e8635
--- /dev/null
+++ b/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_1_3afce2aadeb2221c66f397e631d0e4a6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 1"
+ date="2017-08-26T12:20:58Z"
+ content="""
+^ This one took 21 s.
+"""]]
diff --git a/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_2_220b3ed61dfcce4d6d33fa8516cd1ec1._comment b/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_2_220b3ed61dfcce4d6d33fa8516cd1ec1._comment
new file mode 100644
index 0000000000..48aab919cb
--- /dev/null
+++ b/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_2_220b3ed61dfcce4d6d33fa8516cd1ec1._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-09-29T16:27:40Z"
+ content="""
+ikiwiki gets slow the more pages it has to deal with. With only a few
+thousand pages, it's pretty fast. Including comments, there are currently 
+nearly 10k pages here. (The server might also have been overloaded
+for some reason when this bug was filed. There were some stability problems
+in august related to apache bugs.)
+
+In the past I've deleted old closed bugs to speed it back up.
+There around 3k pages in bugs and todo including comments.
+
+Deleted bugs closed before this year and removed almost 1k pages.
+
+Also, needing to update the rss and atom feeds when adding a bug
+meant writing over 10 mb to disk every time. Limited the size of those
+feeds, which should help a lot.
+"""]]
diff --git a/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_3_8fb126d6583014d3e16137e9c18057e6._comment b/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_3_8fb126d6583014d3e16137e9c18057e6._comment
new file mode 100644
index 0000000000..7fb7dd096f
--- /dev/null
+++ b/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_3_8fb126d6583014d3e16137e9c18057e6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 3"
+ date="2017-09-29T20:38:31Z"
+ content="""
+Thank you! =)
+"""]]
diff --git a/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_4_72204d0647ec808145b6838d5e621107._comment b/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_4_72204d0647ec808145b6838d5e621107._comment
new file mode 100644
index 0000000000..493d3e63ad
--- /dev/null
+++ b/doc/bugs/__91__meta__93___ikiwiki_is___42__slow__42__/comment_4_72204d0647ec808145b6838d5e621107._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 4"
+ date="2017-09-29T20:38:59Z"
+ content="""
+^ This comment took only 10 seconds, so there’s improvement. (ﾉ^_^)ﾉ
+"""]]
diff --git a/doc/bugs/__96__git_add__96___adds_files_unlocked_instead_of_locked.mdwn b/doc/bugs/__96__git_add__96___adds_files_unlocked_instead_of_locked.mdwn
new file mode 100644
index 0000000000..f4b5d71f8d
--- /dev/null
+++ b/doc/bugs/__96__git_add__96___adds_files_unlocked_instead_of_locked.mdwn
@@ -0,0 +1,55 @@
+### Please describe the problem.
+If `.gitattributes` contains `* annex.largefiles=anything`, then `git add` will add files in an unlocked state. According to this page (https://git-annex.branchable.com/tips/unlocked_files/) though, git-annex should add files in a locked state by default:
+> By default, git-annex commands will add files in locked mode, unless used on a filesystem that does not support symlinks, when unlocked mode is used. To make them always use unlocked mode, run: git config annex.addunlocked true
+
+### What steps will reproduce the problem?
+
+```
+cd $(mktemp -d)
+git init
+echo '* annex.largefiles=anything' > .gitattributes
+git add .
+git commit -m "Add gitattributes"
+git annex init
+cat >> annexed.txt <<EOF
+This text file is unlocked
+EOF
+git add .
+git commit -m "Add annexed"
+```
+
+Observe that annexed.txt will be added as a pointer file, i.e. in unlocked mode.
+
+### What version of git-annex are you using? On what operating system?
+
+Latest from conda-forge on Ubuntu 22.04: git-annex 10.20230626 alldep_h97b9560_100 conda-forge
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+(git-annex) $ bash <script-with-commands-from-reproduce-section> 
+Initialized empty Git repository in /tmp/tmp.XzlfX1juzC/.git/
+[main (root-commit) 7633536] Add gitattributes
+ 1 file changed, 1 insertion(+)
+ create mode 100644 .gitattributes
+init  ok
+(recording state in git...)
+(recording state in git...)
+[main 60f1b44] Add annexed
+ 1 file changed, 1 insertion(+)
+ create mode 100644 annexed.txt
+(git-annex) $ cd /tmp/tmp.XzlfX1juzC
+(git-annex) /tmp/tmp.XzlfX1juzC$ ls -l
+total 4
+-rw-rw-r-- 1 <user> <group> 27 Okt 23 17:12 annexed.txt
+(git-annex) /tmp/tmp.XzlfX1juzC$ git annex find --unlocked
+annexed.txt
+(git-annex) /tmp/tmp.XzlfX1juzC$
+
+# End of transcript or log.
+"""]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/__96__git_add__96___adds_files_unlocked_instead_of_locked/comment_1_58abf8693ed90fc8c6e3f750310c17e4._comment b/doc/bugs/__96__git_add__96___adds_files_unlocked_instead_of_locked/comment_1_58abf8693ed90fc8c6e3f750310c17e4._comment
new file mode 100644
index 0000000000..6877505071
--- /dev/null
+++ b/doc/bugs/__96__git_add__96___adds_files_unlocked_instead_of_locked/comment_1_58abf8693ed90fc8c6e3f750310c17e4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-10-23T17:48:54Z"
+ content="""
+I wish it were possible to make `git add` add files in a locked state.
+However, the smudge/clean interface git-annex uses to hook into `git add`
+makes it impossible to do that.
+
+This is why the documentation refers to "git-annex commands", which does
+exclude `git add`. I've made that a little bit more explicit.
+"""]]
diff --git a/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote.mdwn b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote.mdwn
new file mode 100644
index 0000000000..968d4f4916
--- /dev/null
+++ b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote.mdwn
@@ -0,0 +1,84 @@
+### Please describe the problem.
+
+Context: As part of trying to get a non-star topology as described [here](https://git-annex.branchable.com/todo/Allow_remote_sync__42___and_ignore__42___in_git_annex_config/), I added remotes that are not online and don't have the ignore flag set.
+
+Running `git annex info` (without additional args) causes git-annex to try to ssh to the enabled git special remote and then git fetch it which takes *minutes* to time out.
+
+### What steps will reproduce the problem?
+
+1. Add a reachable but unavailable ip address such as 101.101.101.101 to a local interface for setup
+2. `git annex initremote bad type=git location=ssh://101.101.101.101:/tmp/foo`
+3. Remove the address from the local interface again (and clear annex ssh caches)
+4. `git annex info` (hangs)
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 10.20230802
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24.1 bloomfilter-2.0.1.2 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.4.6 http-client-0.7.13.1 persistent-sqlite-2.13.1.1 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+```
+
+### Please provide any additional information below.
+
+```
+$ time git annex info --debug
+[2023-10-01 11:54:30.392801032] (Utility.Process) process [588948] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2023-10-01 11:54:30.393683972] (Utility.Process) process [588948] done ExitSuccess
+[2023-10-01 11:54:30.393935272] (Utility.Process) process [588949] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2023-10-01 11:54:30.394796062] (Utility.Process) process [588949] done ExitSuccess
+[2023-10-01 11:54:30.395083822] (Utility.Process) process [588950] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..3d1d07c0a9dc56682f27ba310660fae82a483487","--pretty=%H","-n1"]
+[2023-10-01 11:54:30.396110553] (Utility.Process) process [588950] done ExitSuccess
+[2023-10-01 11:54:30.396321043] (Utility.Process) process [588951] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..314451b72f15a36ad620106fce7972c03f729cdf","--pretty=%H","-n1"]
+[2023-10-01 11:54:30.397313663] (Utility.Process) process [588951] done ExitSuccess
+[2023-10-01 11:54:30.397520583] (Utility.Process) process [588952] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..c7a89661d145e9cd2f019301a49cad3382bdaa4e","--pretty=%H","-n1"]
+[2023-10-01 11:54:30.398499344] (Utility.Process) process [588952] done ExitSuccess
+[2023-10-01 11:54:30.399090524] (Utility.Process) process [588953] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2023-10-01 11:54:30.400543744] (Utility.Process) process [588954] call: sh ["-c","ping -c 1 -W 0.3 -n LYKOURGOS.redacted 2>&1 >/dev/null"]
+[2023-10-01 11:54:30.704778033] (Utility.Process) process [588954] done ExitFailure 1
+[2023-10-01 11:54:30.705468863] (Utility.Process) process [588956] call: sh ["-c","ping -c 1 -W 0.3 -n uranos.redacted 2>&1 >/dev/null"]
+[2023-10-01 11:54:31.011500591] (Utility.Process) process [588956] done ExitFailure 1
+[2023-10-01 11:54:31.012659161] (Utility.Process) process [588958] read: ssh ["101.101.101.101","-S",".git/annex/ssh/101.101.101.101","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","git-annex-shell 'configlist' '/tmp/foo' '--debug'"]
+
+[2023-10-01 11:56:43.654364825] (Utility.Process) process [588958] done ExitFailure 255
+
+  Unable to parse git config from bad
+[2023-10-01 11:56:43.654791355] (Utility.Process) process [589323] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","fetch","--quiet","bad"]
+ssh: connect to host 101.101.101.101 port 22: Connection timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+[2023-10-01 11:58:56.774415157] (Utility.Process) process [589323] done ExitFailure 128
+trusted repositories: 0
+semitrusted repositories: 8
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        080e4b9c-a094-4b74-9825-438b689b665c -- foo2
+        330a9e48-26c2-43ef-a16b-d798f90dd215 -- URANOS
+        65cc3cd9-a1a9-490b-ba46-2bc15b195f96 -- LYKOURGOS
+        8b88ef14-74ef-482f-80ad-74581516ddbb -- atemu@HEPHAISTOS:/tmp/foo4
+        ef313204-e6a2-4895-b817-66365273854c -- bad [here]
+        ff295fe4-85eb-4f98-be21-a070314627e9 -- [SOTERIA]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 32.53 gigabytes (+1 gigabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: [2023-10-01 11:58:56.775992177] (Utility.Process) process [589591] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-files","-z","--cached","--others","--","."]
+[2023-10-01 11:58:56.776843407] (Utility.Process) process [589591] done ExitSuccess
+0
+size of annexed files in working tree: 0 bytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage:
+[2023-10-01 11:58:56.777581777] (Utility.Process) process [588953] done ExitSuccess
+
+real    4m26.397s
+user    0m0.513s
+sys     0m0.038s
+```
diff --git a/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_1_e3bc14a173600b86c5875d90228aea8b._comment b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_1_e3bc14a173600b86c5875d90228aea8b._comment
new file mode 100644
index 0000000000..b6685e786b
--- /dev/null
+++ b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_1_e3bc14a173600b86c5875d90228aea8b._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-10-09T18:50:00Z"
+ content="""
+An easier way to see this behavior is:
+
+	git remote add foo 192.168.1.101:/dne
+	time git fetch foo
+	2:14.36elapsed
+
+So I'm having difficulty seeing this as a bug in git-annex
+particularly.
+
+Yes, git-annex has to ssh once to new git remotes, 
+in order to determine their git-annex uuid. git-annex
+info needs to know what uuids each remote has, so it's
+certianly right that it does this.
+
+Yes, if that fails git-annex falls back to a git fetch,
+in order to determine if the remote is unavailable,
+or if the remote is available but does not
+have git-annex-shell installed. So it takes twice
+as long to time out as the usual ssh tcp timeout.
+"""]]
diff --git a/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_2_9274223b32601ead9a508aa9852e4933._comment b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_2_9274223b32601ead9a508aa9852e4933._comment
new file mode 100644
index 0000000000..2724e16158
--- /dev/null
+++ b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_2_9274223b32601ead9a508aa9852e4933._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/86b8c2d893dfdf2146e1bbb8ac4165fb"
+ subject="comment 2"
+ date="2023-12-01T10:21:09Z"
+ content="""
+I've had an idea on this: Why not only update UUIDs on (manual) sync/fetch?
+
+This would be in line with how git interacts with regular remotes otherwise too; always requiring an explicit fetch to update its info.
+
+To me it just violates the principle of least surprise to have git-annex try and reach remotes when running something as simple as `info`.
+"""]]
diff --git a/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_3_8f46a9d4a7ceae80e378149d88dd1f19._comment b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_3_8f46a9d4a7ceae80e378149d88dd1f19._comment
new file mode 100644
index 0000000000..79e4308e73
--- /dev/null
+++ b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_3_8f46a9d4a7ceae80e378149d88dd1f19._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Another possibility to make --fast faster?"
+ date="2023-12-01T11:50:25Z"
+ content="""
+How about having `git annex info --fast` skip this lookup step for remotes where it doesn't know the UUID of yet?
+
+`git annex info` can already be quite slow in the other steps it takes (counting files, disk space, etc.) in large repos, so it is not so much of a surprise that it hangs a while by default. But if `--fast` would make it actually fast by staying completely offline (right?) and skipping the slow local counting steps, this would be logical.
+
+"""]]
diff --git a/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_4_c3130a2595fc35525dfdbcc6cec57713._comment b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_4_c3130a2595fc35525dfdbcc6cec57713._comment
new file mode 100644
index 0000000000..12a0352361
--- /dev/null
+++ b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_4_c3130a2595fc35525dfdbcc6cec57713._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/86b8c2d893dfdf2146e1bbb8ac4165fb"
+ subject="comment 4"
+ date="2023-12-03T21:11:19Z"
+ content="""
+I'd flip that around; make `--fast` the default and add a `--full` flag to show full info. I rarely need it.
+"""]]
diff --git a/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_5_eeb4f35b7609cb36fdcece9b8cb94430._comment b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_5_eeb4f35b7609cb36fdcece9b8cb94430._comment
new file mode 100644
index 0000000000..759127675a
--- /dev/null
+++ b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_5_eeb4f35b7609cb36fdcece9b8cb94430._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-12-04T16:50:45Z"
+ content="""
+git-annex does only do uuid discovery of new remotes when it is dealing
+with remotes. Many git-annex commands do deal with remotes, and that
+includes `git-annex info`, which after all shows a list of repositories.
+Commands that do not deal with remotes do skip the uuid discovery.
+
+Since this kind of configuration can cause many different git-annex (and
+also git) commands to hang for a while, it doesn't seem very useful to
+do something specifically to `git-annex info` to deal with it.
+"""]]
diff --git a/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_6_ee21d4d8b276a32b227199175ea30721._comment b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_6_ee21d4d8b276a32b227199175ea30721._comment
new file mode 100644
index 0000000000..ef7a519b92
--- /dev/null
+++ b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_6_ee21d4d8b276a32b227199175ea30721._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="How about a --offline flag?"
+ date="2023-12-04T17:52:44Z"
+ content="""
+How about a global `--offline` flag, then? 🙃 It would prevent running anything that has to do with (non-specified) remotes (git pull/push, copying files, fetching UUIDs, etc.), however local things like committing, merging any already present `synced` branches, etc. would still run. 
+
+I can imagine this being helpful in offline kind of situations: 
+
+- You're in an network-less vault/safe and want to sync up your offline hard-drive with just `git annex assist|sync --offline OFFLINEDRIVE` (although that would already do little with other remotes, except when it's run for the first time to auto-enable other remotes, right?)
+- You're on a really bad mobile connection and want to run `git annex assist --offline` to save your current changes without git-annex trying to sync with other remotes (internet is bad anyway). Alternative is to `git annex add` and `git commit` manually.
+
+It could go as far as allowing remotes that are on a local path on a non-networked filesystem, but for that to work reliably git-annex would need to go out of its way quite far, so probably a bit much to ask.
+"""]]
diff --git a/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_7_9104e12c57bc47cfd0a6c109ad085de1._comment b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_7_9104e12c57bc47cfd0a6c109ad085de1._comment
new file mode 100644
index 0000000000..713fb113d6
--- /dev/null
+++ b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_7_9104e12c57bc47cfd0a6c109ad085de1._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/86b8c2d893dfdf2146e1bbb8ac4165fb"
+ subject="comment 7"
+ date="2023-12-25T13:03:50Z"
+ content="""
+To explain my rationale a bit more, I use `git-annex info` for three purposes (descending frequency):
+
+1. Overview of repos and trust level (like `git remote`)
+2. Query metadata of files/keys (size, repo/group presence)
+3. Query metadata of individual repos (size, trust)
+
+AFAICT, none of these actually interact with remote repositories in any way; they gather information from the local `git-annex` branch and present it in a digestible format. (Apart from the presence check functionality in question of course.) I'd expect these to run these as fast as the CPU and disk allow without any possible interference by the network.  
+
+Commands like `sync`, `copy` or get must obviously interact with other repositories; it's their primary or even sole purpose. When remote repos are present, I'd fully expect network usage with these and, equally important, timing dependence.  
+(Though I too would love to see an offline flag for these commands like Yann suggested; i.e. `git annex copy --auto --offline` only copying from and to locally available repos.)
+
+I would not expect `info` to have to open any network connections to do its job however; all of the data should be present in the `git-annex` branch afterall. Repo presence is a practical and desirable feature but I wouldn't expect it to be updated on every invocation of `info` and in fact it isn't: When I unmount a repo and run `info` again, git-annex still thinks its present. Actually not even a `sync` will update that; I'm unsure whether it's even possible to do so?
+
+I think I'd prefer an explicit `git annex info --fetch` command (or perhaps even a new sub command) which runs the repo presence check from scratch for all repos or a specific repo. This stops the regular `info` command from requiring any networking whatsoever and provides confidence that remotes are actually present when claimed as such after you run it.
+"""]]
diff --git a/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_8_c5b96e6c35c8969062489d6e03066f34._comment b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_8_c5b96e6c35c8969062489d6e03066f34._comment
new file mode 100644
index 0000000000..335ef537c7
--- /dev/null
+++ b/doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_8_c5b96e6c35c8969062489d6e03066f34._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 8"
+ date="2023-12-30T11:35:22Z"
+ content="""
+I solved this problem by having my own dhcp+dns server (dnsmasq) running on the LAN which gives out only 30 second dhcp leases. This way only alive hosts are resolvable. And remotes are accessed not by ip, but by hostname.
+
+Another way to do this is via mdns, but I found that to be very unreliable.
+"""]]
diff --git a/doc/bugs/__96__git_annex_sync___60__REMOTE__62____96___swallows_network_failure.mdwn b/doc/bugs/__96__git_annex_sync___60__REMOTE__62____96___swallows_network_failure.mdwn
new file mode 100644
index 0000000000..171b4cffb8
--- /dev/null
+++ b/doc/bugs/__96__git_annex_sync___60__REMOTE__62____96___swallows_network_failure.mdwn
@@ -0,0 +1,68 @@
+### Please describe the problem.
+
+`git annex sync` does not report when `git fetch` and `git push` fail due to
+network issues.  While `git fetch`'s error messages are printed, the exit
+status of `git annex sync` will still be `0`.
+
+Looking at the source code, this seems to be a deliberate design decision. The
+synchronization operation are coded in such a way that failing to send/receive
+commits to/from a remote is not reported as an error. (See `pullRemote` and
+`pushRemote` in `Command/Sync.hs`.) This has the advantage of allowing the user
+to simply say `git annex sync` without worrying too much about whether all of
+their configured remotes are reachable.
+
+However, this poses problems when trying to use `git annex sync` in an
+automated way. If networking issues (including authentication failures) are
+ignored, this can easily convince a script using `git annex sync` that the
+operation has succeeded, when in fact it has failed.
+
+I can think of a few ways of addressing this issue:
+
+1. Keep going of any of the `pullRemote`/`pushRemote` invocations fail, but
+   keep track of the fact that something has failed, and exit with status 1 if
+   this happens. This has the advantage that scripts will be properly alerted
+   when things go wrong, but isn't strictly backwards compatible.
+2. Add an option to `git annex sync` which causes any failures within
+   `pullRemote`/`pushRemote` to be considered fatal errors. Perhaps the option
+   could be called `--batch` or `--report-errors`. This would allow for strict
+   backwards-compatibility.
+3. Make failures of `pullRemote`/`pushRemote` fatal errors if exactly one
+   remote is given on the command line. This isn't backwards compatible, and
+   also has issues because the semantics are not necessarily obvious to those
+   using `git annex sync`.
+
+I'm sure there are other solutions, but I think users of `git annex sync` need
+a way of detecting network errors and responding to them appropriately.
+Especially when you're only trying to synchronize with a single remote, and
+failing to reach that remote is by definition a failure of the entire process.
+
+### What steps will reproduce the problem?
+
+Attempt to pull from any standard properly-configured `git-annex` remote
+`<REMOTE>` with
+[[!format sh """
+ $ git annex sync <REMOTE>
+"""]]
+when `<REMOTE>` is not reachable on the network.
+Then check the exit status with
+[[!format sh """
+ $ echo $?
+"""]]
+You should get `0` as the result.
+
+### What version of git-annex are you using? On what operating system?
+
+I'm using the latest version in Debian stable, 8.20210223-2.
+
+### Please provide any additional information below.
+
+Not really sure what to put here. Except perhaps to apologize for the overly
+design-oriented bug report. Also, be aware that I'm more than happy to put in
+the legwork of fixing the issue I've described above. But I'd like to make sure
+we agree on a solution before I spend a lot of effort assembling a patch
+series.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Oh yes, I've used `git annex` for many years now to handle synchronizing files
+between various machines. Many thanks for your work on this project.
diff --git a/doc/bugs/__96__lookupkey__96___unexpectedly_slow.mdwn b/doc/bugs/__96__lookupkey__96___unexpectedly_slow.mdwn
new file mode 100644
index 0000000000..bac6814d06
--- /dev/null
+++ b/doc/bugs/__96__lookupkey__96___unexpectedly_slow.mdwn
@@ -0,0 +1,25 @@
+### Please describe the problem.
+
+I need to discover a potentially existing annex-key for any file in the worktree of a Git repository. I assumed that a batch-mode `lookupkey` would be faster than a `find --json --batch`, but that is not the case.
+
+My test repository has 36k files.
+
+```
+❯ time git ls-files | git annex lookupkey --batch > /dev/null
+git ls-files  0.01s user 0.01s system 0% cpu 2:42.37 total
+git annex lookupkey --batch > /dev/null  91.00s user 73.39s system 98% cpu 2:46.25 total
+
+❯ time git ls-files | git annex find --anything --json --batch > /dev/null
+git ls-files  0.01s user 0.00s system 0% cpu 4.093 total
+git annex find --anything --json --batch > /dev/null  3.20s user 2.02s system 124% cpu 4.195 total
+```
+
+`lookupkey` appears to be many times slower than `find`, although the latter reports much more information.
+
+This surprised me, hence I am reporting it here as a potential bug.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20230126
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/__96__lookupkey__96___unexpectedly_slow/comment_1_13003e3b46c5cfab60b6e34fb18731d7._comment b/doc/bugs/__96__lookupkey__96___unexpectedly_slow/comment_1_13003e3b46c5cfab60b6e34fb18731d7._comment
new file mode 100644
index 0000000000..0fe5dfc5c7
--- /dev/null
+++ b/doc/bugs/__96__lookupkey__96___unexpectedly_slow/comment_1_13003e3b46c5cfab60b6e34fb18731d7._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-10-30T18:51:11Z"
+ content="""
+This is due to lookupkey passing each filename through `git ls-files`
+in order to support absolute filepaths input. See 
+[[!commit cfdfe4df6c8b3fe46bbc7afcc8274237a5b2ce2a]]
+
+Made it only do that for absolute paths, which should make it at least
+marginally faster than git-annex find. I would not expect it to be much
+faster though, because git-annex find displaying a little more information
+takes negligible CPU time really.
+"""]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__.mdwn b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__.mdwn
new file mode 100644
index 0000000000..237f41633c
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__.mdwn
@@ -0,0 +1,728 @@
+### Please describe the problem.
+
+A `git annex sync --no-commit --content-of X` (or `git annex sync --no-commit --content` when it
+wants to get only this one file) between two git remotes takes significantly longer than a simple
+`git annex get X`. It turns out that in the latter case git-annex reads the whole copied file
+after its been written which to me seems it performs an extra verify / checksum pass to the file,
+presumably needlessly.
+
+### What steps will reproduce the problem?
+
+1. git annex drop file
+2. time git annex get file
+3. git annex drop file
+4. (time git annex sync --no-commit)
+5. time git annex sync --no-commit --content-of file
+6. (_rinse and repeat if needed_)
+
+The latter retrieval takes about double the time of the former. I investigated the reason
+to that with [FileSpy](http://www.zezula.net/en/fstools/filespy.html), a program
+by Ladislav Zezula for monitoring Windows filesystem requests.
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 8.20210804-gab7b5a492
+build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 2 3 4 5 6 7
+local repository version: 8
+"""]]
+
+Windows 10 version 21H1 (build 19043.1165), 64 bit.
+
+### Please provide any additional information below.
+
+First we have the
+<details>
+<summary>setup (PowerShell).</summary>
+[[!format sh """
+PS I:\Reflect-varmistukset-test\Jarkon ThinkPad T450s (Win10 v21H1) . B> ls
+
+    Directory: I:\Reflect-varmistukset-test\Jarkon ThinkPad T450s (Win10 v21H1) . B
+
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+d-----         25.8.2021      3:36                arkistoidut
+-a----         25.8.2021      3:36             75 9BEAE03792B9FAFB-00-00.mrimg
+-a----         25.8.2021      6:07     9722174075 9BEAE03792B9FAFB-01-01.mrimg
+-a----         25.8.2021      3:36             74 9BEAE03792B9FAFB-02-02.mrimg
+-a----         25.8.2021      3:36            617 Justfile
+
+
+PS I:\Reflect-varmistukset-test\Jarkon ThinkPad T450s (Win10 v21H1) . B> git annex info 9BEAE03792B9FAFB-01-01.mrimg
+file: 9BEAE03792B9FAFB-01-01.mrimg
+size: 9.72 gigabytes
+key: MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg
+present: true
+PS I:\Reflect-varmistukset-test\Jarkon ThinkPad T450s (Win10 v21H1) . B> git annex whereis 9BEAE03792B9FAFB-01-01.mrimg
+whereis 9BEAE03792B9FAFB-01-01.mrimg (4 copies)
+        3362df51-1789-4471-96a0-d2267ada6aa4 -- Reflect-varmistukset [origin]
+        46a41e47-45c8-4a86-b348-db0c4cfb18f3 -- Reflect-varmistukset
+        e3115644-bf78-420d-89af-7256521d5dda -- Reflect-varmistukset-test [here]
+        f40fab57-df0e-4297-ba83-76e6ad64f9c1 -- t450s-win10-v21h1-b--chunked
+ok
+PS I:\Reflect-varmistukset-test\Jarkon ThinkPad T450s (Win10 v21H1) . B> git remote show -n origin
+* remote origin
+  Fetch URL: g:\Reflect-varmistukset
+  Push  URL: g:\Reflect-varmistukset
+  HEAD branch: (not queried)
+  Remote branches: (status not queried)
+    adjusted/master(hidemissing)
+    adjusted/master(hidemissing-unlocked)
+    adjusted/master(locked)
+    adjusted/master(unlocked)
+    git-annex
+    master
+    synced/git-annex
+    synced/master
+  Local branch configured for 'git pull':
+    adjusted/master(hidemissing-unlocked) merges with remote adjusted/master(hidemissing-unlocked)
+  Local ref configured for 'git push' (status not queried):
+    (matching) pushes to (matching)
+
+# End of transcript or log.
+"""]]
+</details>
+
+As we can see from above the file in question is rather large so re-retrieving it from the `origin`
+which is on another HDD should take a couple of minutes. (We are talking 2.5" SATA drives in USB
+enclosures here.)
+
+So we have these two retrieval operations, basically `git annex get` and `git annex sync --content`.
+To measure these operations, I first `drop` the content of the file mentioned and then continue with
+the respective operation in debug mode timing them. The corresponding transcripts are to be found below:
+
+<details>
+<summary>`git annex get --debug X` transcript (PowerShell)</summary>
+[[!format sh """
+PS I:\Reflect-varmistukset-test\Jarkon ThinkPad T450s (Win10 v21H1) . B> git annex drop 9BEAE03792B9FAFB-01-01.mrimg
+drop 9BEAE03792B9FAFB-01-01.mrimg ok
+(recording state in git...)
+PS I:\Reflect-varmistukset-test\Jarkon ThinkPad T450s (Win10 v21H1) . B> time git annex get --debug 9BEAE03792B9FAFB-01-01.mrimg
+[2021-08-27 00:08:56.0972626] (Utility.Process) process [214660] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2021-08-27 00:08:56.1632595] (Utility.Process) process [214660] done ExitSuccess
+[2021-08-27 00:08:56.1732634] (Utility.Process) process [214844] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","show-ref","refs/heads/adjusted/master(unlocked)"]
+[2021-08-27 00:08:56.2522579] (Utility.Process) process [214844] done ExitSuccess
+[2021-08-27 00:08:56.265259] (Utility.Process) process [211408] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","ls-files","--stage","-z","--","9BEAE03792B9FAFB-01-01.mrimg"]
+[2021-08-27 00:08:56.2793132] (Utility.Process) process [22624] chat: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-27 00:08:56.3472587] (Utility.Process) process [214792] chat: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-27 00:08:56.3792631] (Utility.Process) process [211324] chat: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+get 9BEAE03792B9FAFB-01-01.mrimg [2021-08-27 00:08:56.4872626] (Utility.Process) process [209176] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2021-08-27 00:08:56.5442548] (Utility.Process) process [209176] done ExitSuccess
+[2021-08-27 00:08:56.553261] (Utility.Process) process [214420] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-08-27 00:08:56.6162598] (Utility.Process) process [214420] done ExitSuccess
+[2021-08-27 00:08:56.6292572] (Utility.Process) process [24416] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..00be8770deba79dd666680c63e6f5e9d894e6438","--pretty=%H","-n1"]
+[2021-08-27 00:08:56.6892571] (Utility.Process) process [24416] done ExitSuccess
+[2021-08-27 00:08:56.7002581] (Utility.Process) process [211376] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..d992de9ad3a7f46b3d532fad356994695e4ea992","--pretty=%H","-n1"]
+[2021-08-27 00:08:56.761257] (Utility.Process) process [211376] done ExitSuccess
+[2021-08-27 00:08:56.7832583] (Utility.Process) process [214384] chat: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","hash-object","-w","--stdin-paths","--no-filters"]
+[2021-08-27 00:08:56.8082631] (Utility.Process) process [214428] chat: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-08-27 00:08:56.8282591] (Utility.Process) process [209492] chat: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-27 00:08:56.8392637] (Utility.Process) process [214696] feed: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index-info"]
+[2021-08-27 00:08:56.8512639] (Utility.Process) process [203716] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","diff-index","--raw","-z","-r","--no-renames","-l0","--cached","refs/heads/git-annex","--"]
+[2021-08-27 00:08:56.9772567] (Utility.Process) process [203716] done ExitSuccess
+[2021-08-27 00:08:56.9982588] (Utility.Process) process [214696] done ExitSuccess
+[2021-08-27 00:08:57.0332634] (Utility.Process) process [197724] read: git ["config","--null","--list"]
+[2021-08-27 00:08:57.0922579] (Utility.Process) process [197724] done ExitSuccess
+[2021-08-27 00:08:57.4812578] (Utility.Process) process [212412] read: git ["--git-dir=g:\\Reflect-varmistukset\\.git","--work-tree=g:\\Reflect-varmistukset","--literal-pathspecs","--literal-pathspecs","-c","filter.annex.smudge=","-c","filter.annex.clean=","write-tree"]
+[2021-08-27 00:08:57.5552571] (Utility.Process) process [212412] done ExitSuccess
+[2021-08-27 00:08:57.5632589] (Utility.Process) process [211664] read: git ["--git-dir=g:\\Reflect-varmistukset\\.git","--work-tree=g:\\Reflect-varmistukset","--literal-pathspecs","--literal-pathspecs","show-ref","--hash","refs/annex/last-index"]
+[2021-08-27 00:08:57.6262611] (Utility.Process) process [211664] done ExitSuccess
+(from origin...)
+[2021-08-27 00:10:45.6276714] (Utility.Process) process [214428] done ExitSuccess
+[2021-08-27 00:10:45.6376719] (Utility.Process) process [209492] done ExitSuccess
+[2021-08-27 00:10:45.6426688] (Utility.Process) process [214384] done ExitSuccess
+[2021-08-27 00:10:45.8886681] (Utility.Process) process [215768] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","-c","filter.annex.smudge=","-c","filter.annex.clean=","write-tree"]
+[2021-08-27 00:10:46.0606718] (Utility.Process) process [215768] done ExitSuccess
+[2021-08-27 00:10:46.0716732] (Utility.Process) process [203184] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/annex/last-index"]
+[2021-08-27 00:10:46.1826731] (Utility.Process) process [203184] done ExitSuccess
+[2021-08-27 00:10:46.7836666] (Annex.Branch) read 8b2\d61\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg.log
+[2021-08-27 00:10:46.7936806] (Utility.Process) process [214544] chat: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-08-27 00:10:46.8076747] (Utility.Process) process [194932] chat: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-27 00:10:46.8916778] (Annex.Branch) set 8b2\d61\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg.log
+ok
+[2021-08-27 00:10:46.9066721] (Utility.Process) process [214544] done ExitSuccess
+[2021-08-27 00:10:46.9166731] (Utility.Process) process [194932] done ExitSuccess
+[2021-08-27 00:10:46.9406745] (Utility.Process) process [211324] done ExitSuccess
+[2021-08-27 00:10:46.9406745] (Utility.Process) process [214792] done ExitSuccess
+[2021-08-27 00:10:46.9406745] (Utility.Process) process [22624] done ExitSuccess
+[2021-08-27 00:10:46.9416716] (Utility.Process) process [211408] done ExitSuccess
+(recording state in git...)
+[2021-08-27 00:10:46.9616725] (Utility.Process) process [5096] feed: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","-c","core.safecrlf=false","update-index","-q","--refresh","-z","--stdin"]
+[2021-08-27 00:10:47.3986727] (Utility.Process) process [215868] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2021-08-27 00:10:47.4226935] (Utility.Process) process [210580] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-27 00:10:47.8616724] (Utility.Process) process [212036] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","filter.annex.smudge=","-c","filter.annex.clean=","write-tree"]
+[2021-08-27 00:10:47.9116715] (Database.Keys) reconcileStaged start (in conflict)
+[2021-08-27 00:10:47.9206678] (Utility.Process) process [212288] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/annex/last-index"]
+[2021-08-27 00:10:47.9876758] (Utility.Process) process [210996] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-27 00:10:47.9976825] (Utility.Process) process [212180] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-27 00:10:48.0136775] (Utility.Process) process [215600] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","filter.annex.smudge=","-c","filter.annex.clean=","-c","diff.external=","diff","8b1d3ee71090ebc5af2edccc01c7a6ae5edb6214","--staged","--raw","-z","--no-abbrev","-G/annex/objects/","--no-renames","--ignore-submodules=all","--no-ext-diff"]
+[2021-08-27 00:10:48.1186692] (Utility.Process) process [215600] done ExitSuccess
+[2021-08-27 00:10:48.154675] (Utility.Process) process [212180] done ExitSuccess
+[2021-08-27 00:10:48.1556741] (Utility.Process) process [210996] done ExitSuccess
+[2021-08-27 00:10:48.1556741] (Database.Keys) reconcileStaged end
+[2021-08-27 00:10:48.1776731] (Utility.Process) process [215868] done ExitSuccess
+[2021-08-27 00:10:48.1916692] (Utility.Process) process [210580] done ExitSuccess
+[2021-08-27 00:10:48.2276735] (Utility.Process) process [5096] done ExitSuccess
+[2021-08-27 00:10:48.2566706] (Utility.Process) process [214308] feed: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index[2021-08-27 00:10:48.2576698] (Utility.Process) process done ExitSuccess
+[2021-08-27 00:10:48.2717046] (Utility.Process) process [214248] chat: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","hash-object","-w","--stdin-paths","--no-filters"]
+[2021-08-27 00:10:48.3786694] (Utility.Process) process [214308] done ExitSuccess
+[2021-08-27 00:10:48.3946743] (Utility.Process) process [207012] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-08-27 00:10:48.4666735] (Utility.Process) process [207012] done ExitSuccess
+[2021-08-27 00:10:48.4766715] (Utility.Process) process [215924] chat: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-08-27 00:10:48.4896881] (Utility.Process) process [214828] chat: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-27 00:10:48.5026911] (Utility.Process) process [214220] feed: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index-info"]
+[2021-08-27 00:10:48.5786744] (Utility.Process) process [215144] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","diff-index","--raw","-z","-r","--no-renames","-l0","--cached","refs/heads/git-annex","--"]
+[2021-08-27 00:10:48.8506705] (Utility.Process) process [215144] done ExitSuccess
+[2021-08-27 00:10:48.8596735] (Utility.Process) process [214220] done ExitSuccess
+[2021-08-27 00:10:48.8766719] (Utility.Process) process [56664] read: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","write-tree"]
+[2021-08-27 00:10:49.2976762] (Utility.Process) process [56664] done ExitSuccess
+[2021-08-27 00:10:49.3106759] (Utility.Process) process [58928] chat: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","commit-tree","16586410ea49fba2489c28486fed2d6ddf07e73b","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2021-08-27 00:10:49.5236701] (Utility.Process) process [58928] done ExitSuccess
+[2021-08-27 00:10:49.5346727] (Utility.Process) process [210900] call: git ["--git-dir=..\\.git","--work-tree=..","--literal-pathspecs","-c","annex.debug=true","update-ref","refs/heads/git-annex","2b02572ac2e05fa9729c71fc9e5e79702f42dfa0"]
+[2021-08-27 00:10:49.652673] (Utility.Process) process [210900] done ExitSuccess
+[2021-08-27 00:10:49.6836729] (Utility.Process) process [215924] done ExitSuccess
+[2021-08-27 00:10:49.6936724] (Utility.Process) process [214828] done ExitSuccess
+[2021-08-27 00:10:49.7066751] (Utility.Process) process [214248] done ExitSuccess
+00:01:53.9447083
+
+# End of transcript or log.
+"""]]
+</details>
+
+<details>
+<summary>`git annex sync --no-commit` & `git annex sync --no-commit --content-of X --debug`
+transcript (PowerShell)</summary>
+[[!format sh """
+PS I:\Reflect-varmistukset-test\Jarkon ThinkPad T450s (Win10 v21H1) . B> git annex drop 9BEAE03792B9FAFB-01-01.mrimg
+drop 9BEAE03792B9FAFB-01-01.mrimg ok
+(recording state in git...)
+PS I:\Reflect-varmistukset-test\Jarkon ThinkPad T450s (Win10 v21H1) . B> time git annex sync --no-commit
+pull origin
+ok
+push origin
+Enumerating objects: 19, done.
+Counting objects: 100% (19/19), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (12/12), done.
+Writing objects: 100% (15/15), 1.09 KiB | 185.00 KiB/s, done.
+Total 15 (delta 9), reused 0 (delta 0), pack-reused 0
+remote: Checking connectivity: 15, done.
+To g:\Reflect-varmistukset
+   d992de9..23bccc8  git-annex -> synced/git-annex
+ok
+00:00:15.2608678
+PS I:\Reflect-varmistukset-test\Jarkon ThinkPad T450s (Win10 v21H1) . B> time git annex sync --no-commit --content-of 9BEAE03792B9FAFB-01-01.mrimg --debug
+[2021-08-27 00:13:49.3375398] (Utility.Process) process [214132] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2021-08-27 00:13:49.4105437] (Utility.Process) process [214132] done ExitSuccess
+[2021-08-27 00:13:49.4215952] (Utility.Process) process [201560] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-08-27 00:13:49.496541] (Utility.Process) process [201560] done ExitSuccess
+[2021-08-27 00:13:49.5115409] (Utility.Process) process [215808] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..23bccc89e78eab969cc2241fabbbb0c0d325d857","--pretty=%H","-n1"]
+[2021-08-27 00:13:49.6305429] (Utility.Process) process [215808] done ExitSuccess
+[2021-08-27 00:13:49.6785395] (Utility.Process) process [216836] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","hash-object","-w","--stdin-paths","--no-filters"]
+[2021-08-27 00:13:49.6955432] (Utility.Process) process [216436] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-08-27 00:13:49.7115402] (Utility.Process) process [209236] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-27 00:13:49.7265414] (Utility.Process) process [216160] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index-info"]
+[2021-08-27 00:13:49.7395377] (Utility.Process) process [214088] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","diff-index","--raw","-z","-r","--no-renames","-l0","--cached","refs/heads/git-annex","--"]
+[2021-08-27 00:13:49.8525381] (Utility.Process) process [214088] done ExitSuccess
+[2021-08-27 00:13:49.8635371] (Utility.Process) process [216160] done ExitSuccess
+[2021-08-27 00:13:49.8935393] (Utility.Process) process [208424] read: git ["config","--null","--list"]
+[2021-08-27 00:13:49.9395358] (Utility.Process) process [208424] done ExitSuccess
+[2021-08-27 00:13:49.9555593] (Utility.Process) process [213288] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2021-08-27 00:13:50.0065366] (Utility.Process) process [213288] done ExitSuccess
+[2021-08-27 00:13:50.0175535] (Utility.Process) process [216916] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","refs/heads/adjusted/master(unlocked)"]
+[2021-08-27 00:13:50.1175443] (Utility.Process) process [216916] done ExitSuccess
+[2021-08-27 00:13:50.12754] (Utility.Process) process [216968] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--verify","-q","refs/heads/synced/master"]
+[2021-08-27 00:13:50.2015442] (Utility.Process) process [216968] done ExitSuccess
+[2021-08-27 00:13:50.2135494] (Utility.Process) process [211172] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/adjusted/master(unlocked)..refs/heads/synced/master","--pretty=%H","-n1"]
+[2021-08-27 00:13:50.2915401] (Utility.Process) process [211172] done ExitSuccess
+pull origin
+[2021-08-27 00:13:50.3015454] (Utility.Process) process [198256] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","fetch","origin"]
+[2021-08-27 00:13:50.9255402] (Utility.Process) process [198256] done ExitSuccess
+[2021-08-27 00:13:50.9375907] (Utility.Process) process [216960] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","branch","-f","synced/master","refs/heads/master"]
+[2021-08-27 00:13:51.0135362] (Utility.Process) process [216960] done ExitSuccess
+[2021-08-27 00:13:51.0245377] (Utility.Process) process [216716] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--verify","-q","refs/remotes/origin/master"]
+[2021-08-27 00:13:51.0825456] (Utility.Process) process [216716] done ExitSuccess
+[2021-08-27 00:13:51.0955363] (Utility.Process) process [216888] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/master..refs/remotes/origin/master","--pretty=%H","-n1"]
+[2021-08-27 00:13:51.1725363] (Utility.Process) process [216888] done ExitSuccess
+[2021-08-27 00:13:51.1825395] (Utility.Process) process [215632] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--verify","-q","refs/remotes/origin/synced/master"]
+[2021-08-27 00:13:51.2445413] (Utility.Process) process [215632] done ExitSuccess
+[2021-08-27 00:13:51.2575386] (Utility.Process) process [18444] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/synced/master..refs/remotes/origin/synced/master","--pretty=%H","-n1"]
+[2021-08-27 00:13:51.3425473] (Utility.Process) process [18444] done ExitSuccess
+ok
+[2021-08-27 00:13:51.3545543] (Utility.Process) process [214256] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2021-08-27 00:13:51.4295365] (Utility.Process) process [214256] done ExitSuccess
+[2021-08-27 00:13:51.4415352] (Utility.Process) process [216864] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-08-27 00:13:51.5255415] (Utility.Process) process [216864] done ExitSuccess
+[2021-08-27 00:13:51.5475389] (Utility.Process) process [216180] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..23bccc89e78eab969cc2241fabbbb0c0d325d857","--pretty=%H","-n1"]
+[2021-08-27 00:13:51.6355408] (Utility.Process) process [216180] done ExitSuccess
+[2021-08-27 00:13:51.6485405] (Utility.Process) process [215368] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index-info"]
+[2021-08-27 00:13:51.6665404] (Utility.Process) process [217068] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","diff-index","--raw","-z","-r","--no-renames","-l0","--cached","refs/heads/git-annex","--"]
+[2021-08-27 00:13:51.7665362] (Utility.Process) process [217068] done ExitSuccess
+[2021-08-27 00:13:51.7805369] (Utility.Process) process [215368] done ExitSuccess
+[2021-08-27 00:13:51.8005439] (Utility.Process) process [215204] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-files","--stage","-z","--","I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg"]
+[2021-08-27 00:13:51.8145422] (Utility.Process) process [214200] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-27 00:13:51.8265727] (Utility.Process) process [212624] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-27 00:13:51.9115397] (Utility.Process) process [214656] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-27 00:13:52.0015476] (Utility.Process) process [206800] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-08-27 00:13:52.0115407] (Utility.Process) process [216304] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+get Jarkon ThinkPad T450s (Win10 v21H1) . B/9BEAE03792B9FAFB-01-01.mrimg [2021-08-27 00:13:52.186541] (Utility.Process) process [215352] read: git ["--git-dir=g:\\Reflect-varmistukset\\.git","--work-tree=g:\\Reflect-varmistukset","--literal-pathspecs","--literal-pathspecs","-c","filter.annex.smudge=","-c","filter.annex.clean=","write-tree"]
+[2021-08-27 00:13:52.2955443] (Utility.Process) process [215352] done ExitSuccess
+[2021-08-27 00:13:52.3085383] (Utility.Process) process [216744] read: git ["--git-dir=g:\\Reflect-varmistukset\\.git","--work-tree=g:\\Reflect-varmistukset","--literal-pathspecs","--literal-pathspecs","show-ref","--hash","refs/annex/last-index"]
+[2021-08-27 00:13:52.3725498] (Utility.Process) process [216744] done ExitSuccess
+(from origin...)
+[2021-08-27 00:15:36.2939028] (Utility.Process) process [206800] done ExitSuccess
+[2021-08-27 00:15:36.3029014] (Utility.Process) process [216304] done ExitSuccess
+[2021-08-27 00:15:36.3149024] (Utility.Process) process [216836] done ExitSuccess
+[2021-08-27 00:15:36.3499337] (Utility.Process) process [213608] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","-c","filter.annex.smudge=","-c","filter.annex.clean=","write-tree"]
+[2021-08-27 00:15:36.4519021] (Utility.Process) process [213608] done ExitSuccess
+[2021-08-27 00:15:36.4608984] (Utility.Process) process [215680] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/annex/last-index"]
+[2021-08-27 00:15:36.5279003] (Utility.Process) process [215680] done ExitSuccess
+[2021-08-27 00:15:36.5779058] (Annex.Branch) read 8b2\d61\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg.log
+[2021-08-27 00:15:36.5888998] (Utility.Process) process [215224] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-08-27 00:15:36.6039512] (Utility.Process) process [216116] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-27 00:15:36.6868986] (Annex.Branch) set 8b2\d61\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg.log
+ok
+[2021-08-27 00:17:46.1533905] (Utility.Process) process [217444] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","check-attr","-z","--stdin","annex.backend","annex.largefiles","annex.numcopies","annex.mincopies","--"]
+[2021-08-27 00:17:46.275388] (Annex.Branch) read numcopies.log
+[2021-08-27 00:17:46.3353888] (Annex.Branch) read mincopies.log
+[2021-08-27 00:17:46.3783936] (Utility.Process) process [215224] done ExitSuccess
+[2021-08-27 00:17:46.4003873] (Utility.Process) process [216116] done ExitSuccess
+[2021-08-27 00:17:46.4393899] (Utility.Process) process [217444] done ExitSuccess
+[2021-08-27 00:17:46.4454328] (Utility.Process) process done ExitSuccess
+[2021-08-27 00:17:46.4474155] (Utility.Process) process [214656] done ExitSuccess
+[2021-08-27 00:17:46.4524071] (Utility.Process) process done ExitSuccess
+[2021-08-27 00:17:46.4553874] (Utility.Process) process done ExitSuccess
+[2021-08-27 00:17:46.4553874] (Utility.Process) process [212624] done ExitSuccess
+[2021-08-27 00:17:46.4553874] (Utility.Process) process [214200] done ExitSuccess
+[2021-08-27 00:17:46.4563875] (Utility.Process) process [215204] done ExitSuccess
+pull origin
+[2021-08-27 00:17:46.4663927] (Utility.Process) process [217376] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","fetch","origin"]
+[2021-08-27 00:17:47.807387] (Utility.Process) process [217376] done ExitSuccess
+[2021-08-27 00:17:47.8254033] (Utility.Process) process [216624] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","branch","-f","synced/master","refs/heads/master"]
+[2021-08-27 00:17:47.9233892] (Utility.Process) process [216624] done ExitSuccess
+[2021-08-27 00:17:47.9403873] (Utility.Process) process [216812] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--verify","-q","refs/remotes/origin/master"]
+[2021-08-27 00:17:48.0253856] (Utility.Process) process [216812] done ExitSuccess
+[2021-08-27 00:17:48.0453871] (Utility.Process) process [217076] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/master..refs/remotes/origin/master","--pretty=%H","-n1"]
+[2021-08-27 00:17:48.1843855] (Utility.Process) process [217076] done ExitSuccess
+[2021-08-27 00:17:48.1963916] (Utility.Process) process [213108] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--verify","-q","refs/remotes/origin/synced/master"]
+[2021-08-27 00:17:48.2783861] (Utility.Process) process [213108] done ExitSuccess
+[2021-08-27 00:17:48.2963914] (Utility.Process) process [217628] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/synced/master..refs/remotes/origin/synced/master","--pretty=%H","-n1"]
+[2021-08-27 00:17:48.3833858] (Utility.Process) process [217628] done ExitSuccess
+ok
+[2021-08-27 00:17:48.3993895] (Utility.Process) process [213996] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index-info"]
+[2021-08-27 00:17:48.4083897] (Utility.Process) process done ExitSuccess
+[2021-08-27 00:17:48.4303952] (Utility.Process) process [216136] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","hash-object","-w","--stdin-paths","--no-filters"]
+[2021-08-27 00:17:48.654389] (Utility.Process) process [213996] done ExitSuccess
+[2021-08-27 00:17:48.6703942] (Utility.Process) process [214536] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-08-27 00:17:49.0205141] (Utility.Process) process [214536] done ExitSuccess
+(recording state in git...)
+[2021-08-27 00:17:49.0415205] (Utility.Process) process [217516] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-08-27 00:17:49.0565146] (Utility.Process) process [217488] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-27 00:17:49.0745205] (Utility.Process) process [217464] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index-info"]
+[2021-08-27 00:17:49.0885149] (Utility.Process) process [217664] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","diff-index","--raw","-z","-r","--no-renames","-l0","--cached","refs/heads/git-annex","--"]
+[2021-08-27 00:17:49.3175172] (Utility.Process) process [217664] done ExitSuccess
+[2021-08-27 00:17:49.3325187] (Utility.Process) process [217464] done ExitSuccess
+[2021-08-27 00:17:49.3505184] (Utility.Process) process [217720] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","write-tree"]
+[2021-08-27 00:17:49.7095175] (Utility.Process) process [217720] done ExitSuccess
+[2021-08-27 00:17:49.7205203] (Utility.Process) process [217760] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","commit-tree","1a868cb2ce3525f2268df3faa4f1784593d6ee5e","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2021-08-27 00:17:49.8860794] (Utility.Process) process [217760] done ExitSuccess
+[2021-08-27 00:17:49.8990766] (Utility.Process) process [217916] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-ref","refs/heads/git-annex","f050618c3839d83854bc5a83bead8d49694fe17e"]
+[2021-08-27 00:17:50.0160774] (Utility.Process) process [217916] done ExitSuccess
+[2021-08-27 00:17:50.0310721] (Utility.Process) process [217748] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2021-08-27 00:17:50.1360769] (Utility.Process) process [217748] done ExitSuccess
+[2021-08-27 00:17:50.148072] (Utility.Process) process [217944] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-08-27 00:17:50.260071] (Utility.Process) process [217944] done ExitSuccess
+[2021-08-27 00:17:50.2730764] (Utility.Process) process [213304] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..f050618c3839d83854bc5a83bead8d49694fe17e","--pretty=%H","-n1"]
+[2021-08-27 00:17:50.3800768] (Utility.Process) process [213304] done ExitSuccess
+[2021-08-27 00:17:50.393075] (Utility.Process) process [209548] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..23bccc89e78eab969cc2241fabbbb0c0d325d857","--pretty=%H","-n1"]
+[2021-08-27 00:17:50.4730747] (Utility.Process) process [209548] done ExitSuccess
+[2021-08-27 00:17:50.4880776] (Utility.Process) process [215656] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index-info"]
+[2021-08-27 00:17:50.5020794] (Utility.Process) process [218048] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","diff-index","--raw","-z","-r","--no-renames","-l0","--cached","refs/heads/git-annex","--"]
+[2021-08-27 00:17:50.5940713] (Utility.Process) process [218048] done ExitSuccess
+[2021-08-27 00:17:50.6050732] (Utility.Process) process [215656] done ExitSuccess
+[2021-08-27 00:17:50.6260788] (Utility.Process) process [217248] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/basis/adjusted/master(unlocked)"]
+[2021-08-27 00:17:50.7000724] (Utility.Process) process [217248] done ExitSuccess
+[2021-08-27 00:17:50.7100744] (Utility.Process) process [211624] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-08-27 00:17:50.7250742] (Utility.Process) process [14260] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-27 00:17:50.8180757] (Utility.Process) process [217092] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/basis/adjusted/master(unlocked)..refs/heads/adjusted/master(unlocked)","--pretty=%H","--reverse"]
+[2021-08-27 00:17:50.9546056] (Utility.Process) process [217092] done ExitSuccess
+[2021-08-27 00:17:50.968617] (Utility.Process) process [12384] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-ref","refs/basis/adjusted/master(unlocked)","da6ae1e1f6e3024f0f90079332685bbd4d950068"]
+[2021-08-27 00:17:51.0826057] (Utility.Process) process [12384] done ExitSuccess
+[2021-08-27 00:17:51.1016108] (Utility.Process) process [217132] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-ref","refs/heads/master","da6ae1e1f6e3024f0f90079332685bbd4d950068"]
+[2021-08-27 00:17:51.2076769] (Utility.Process) process [217132] done ExitSuccess
+[2021-08-27 00:17:51.2306834] (Utility.Process) process [211008] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","commit-tree","8b1d3ee71090ebc5af2edccc01c7a6ae5edb6214","--no-gpg-sign","-p","da6ae1e1f6e3024f0f90079332685bbd4d950068"]
+[2021-08-27 00:17:51.3016768] (Utility.Process) process [211008] done ExitSuccess
+[2021-08-27 00:17:51.3126762] (Utility.Process) process [216868] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-ref","-m","rebasing adjusted branch on top of updated original branch","refs/heads/adjusted/master(unlocked)","12230f33ae02f213ac044680f6e2f44ad504d81b"]
+[2021-08-27 00:17:51.4186757] (Utility.Process) process [216868] done ExitSuccess
+[2021-08-27 00:17:51.4306819] (Utility.Process) process [213772] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","branch","-f","synced/master","refs/heads/master"]
+[2021-08-27 00:17:51.5206755] (Utility.Process) process [213772] done ExitSuccess
+[2021-08-27 00:17:51.5306808] (Utility.Process) process [217164] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--verify","-q","refs/remotes/origin/synced/master"]
+[2021-08-27 00:17:51.5966814] (Utility.Process) process [217164] done ExitSuccess
+[2021-08-27 00:17:51.6106763] (Utility.Process) process [214000] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/remotes/origin/synced/master..refs/heads/synced/master","--pretty=%H","-n1"]
+[2021-08-27 00:17:51.7146793] (Utility.Process) process [214000] done ExitSuccess
+[2021-08-27 00:17:51.7236796] (Utility.Process) process [216680] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--verify","-q","refs/remotes/origin/git-annex"]
+[2021-08-27 00:17:51.8096754] (Utility.Process) process [216680] done ExitSuccess
+[2021-08-27 00:17:51.8216807] (Utility.Process) process [217408] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/remotes/origin/git-annex..git-annex","--pretty=%H","-n1"]
+[2021-08-27 00:17:51.9116765] (Utility.Process) process [217408] done ExitSuccess
+push origin
+ster","+git-annex:synced/git-annex"]
+Counting objects: 100% (9/9), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (4/4), done.
+Writing objects: 100% (5/5), 410 bytes | 37.00 KiB/s, done.
+Total 5 (delta 3), reused 0 (delta 0), pack-reused 0
+To g:\Reflect-varmistukset
+   23bccc8..f050618  git-annex -> synced/git-annex
+[2021-08-27 00:17:55.0492122] (Utility.Process) process [216816] done ExitSuccess
+[2021-08-27 00:17:55.0622115] (Utility.Process) process [217956] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","push","origin","git-annex"]
+[2021-08-27 00:17:56.7432043] (Utility.Process) process [217956] done ExitSuccess
+[2021-08-27 00:17:56.7552126] (Utility.Process) process [215284] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","push","origin","master"]
+[2021-08-27 00:17:57.1182069] (Utility.Process) process [215284] done ExitSuccess
+ok
+(recording state in git...)
+[2021-08-27 00:17:57.1552103] (Utility.Process) process [217300] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","-c","core.safecrlf=false","update-index","-q","--refresh","-z","--stdin"]
+[2021-08-27 00:17:57.6632069] (Utility.Process) process [215568] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2021-08-27 00:17:57.6752084] (Utility.Process) process [217372] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-27 00:17:57.7862096] (Utility.Process) process [217436] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","filter.annex.smudge=","-c","filter.annex.clean=","write-tree"]
+[2021-08-27 00:17:57.8792042] (Utility.Process) process [217436] done ExitFailure 128
+[2021-08-27 00:17:57.8812054] (Database.Keys) reconcileStaged start (in conflict)
+[2021-08-27 00:17:57.8932088] (Utility.Process) process [214408] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/annex/last-index"]
+[2021-08-27 00:17:57.9732051] (Utility.Process) process [214408] done ExitSuccess
+[2021-08-27 00:17:57.9852111] (Utility.Process) process [217984] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-27 00:17:58.0202119] (Utility.Process) process [216252] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-27 00:17:58.0352085] (Utility.Process) process [205448] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","filter.annex.smudge=","-c","filter.annex.clean=","-c","diff.external=","diff","8b1d3ee71090ebc5af2edccc01c7a6ae5edb6214","--staged","--raw","-z","--no-abbrev","-G/annex/objects/","--no-renames","--ignore-submodules=all","--no-ext-diff"]
+[2021-08-27 00:17:58.2442068] (Utility.Process) process [205448] done ExitSuccess
+[2021-08-27 00:17:58.2732066] (Utility.Process) process [216252] done ExitSuccess
+[2021-08-27 00:17:58.2822569] (Utility.Process) process [217984] done ExitSuccess
+[2021-08-27 00:17:58.284208] (Database.Keys) reconcileStaged end
+[2021-08-27 00:17:58.3102596] (Utility.Process) process [215568] done ExitSuccess
+[2021-08-27 00:17:58.3332062] (Utility.Process) process [217372] done ExitSuccess
+[2021-08-27 00:17:58.4222128] (Utility.Process) process [217300] done ExitSuccess
+[2021-08-27 00:17:58.4702079] (Utility.Process) process [211624] done ExitSuccess
+[2021-08-27 00:17:58.4832068] (Utility.Process) process [14260] done ExitSuccess
+[2021-08-27 00:17:58.4992128] (Utility.Process) process [217516] done ExitSuccess
+[2021-08-27 00:17:58.5142044] (Utility.Process) process [217488] done ExitSuccess
+[2021-08-27 00:17:58.5232096] (Utility.Process) process [216136] done ExitSuccess
+00:04:09.6301535
+
+# End of transcript or log.
+"""]]
+</details>
+
+Please note that the `time` command output in the powershell transcripts above is non-standard/different
+from what we are used to in POSIXland. It's a utility/script from the Scoop installation manager (psutils
+package) and simply produces a wall-clock execution time in a hours, minutes, seconds, and microseconds format
+(HH:MM:SS.uuuuuu). As you can see, I have also timed a plain `git annex sync --no-commit` in the latter transcript.
+
+<details>
+<summary>FileSpy trace on Windows during `sync --no-commit --content-of X` (the first 160 and the last 120 lines of a converted file [log->csv->markdown])</summary> 
+[[!format mdwn """
+| #      | Time sent    | Dur. | Process       | Request                   | IRP Flags | FsContext        | Path                                                                                                                                                                              | Status                       | More info                                                                                                                                                                                                                            |
+|--------|--------------|------|---------------|---------------------------|-----------|------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| 1      | 00:13:49.235 |      | git.exe       | IRP_MJ_CREATE             | 884       | 0                | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\.git                                                                                                      | STATUS_OBJECT_NAME_NOT_FOUND | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0                                                                                                                                                               |
+| 2      | 00:13:49.235 |      | git.exe       | IRP_MJ_NETWORK_QUERY_OPEN |           | 0                | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\HEAD                                                                                                      | STATUS_OBJECT_NAME_NOT_FOUND | FileNetworkOpenInformation CreateTime: 0 LastAccTime: 0 LastWrtTime: 0 ChangeTime: 0 AllocationSize: 00000000-00000000 EndOfFile: 00000000-00000000 Attrib: 0                                                                        |
+| 3      | 00:13:49.277 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | 0                | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\.git                                                                                                      | STATUS_OBJECT_NAME_NOT_FOUND | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080                                                                                                                                                        |
+| 4      | 00:13:49.277 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | 0                | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\config                                                                                                    | STATUS_OBJECT_NAME_NOT_FOUND | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0                                                                                                                                                               |
+| 5      | 00:13:49.278 |      | git-annex.exe | IRP_MJ_NETWORK_QUERY_OPEN |           | 0                | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\git.exe                                                                                                   | STATUS_OBJECT_NAME_NOT_FOUND | FileNetworkOpenInformation CreateTime: 0 LastAccTime: 0 LastWrtTime: 0 ChangeTime: 0 AllocationSize: 00000000-00000000 EndOfFile: 00000000-00000000 Attrib: 0                                                                        |
+| 6      | 00:13:51.788 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 7      | 00:13:51.788 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 8      | 00:13:51.788 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 9      | 00:13:51.789 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 10     | 00:13:51.789 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 11     | 00:13:51.789 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 12     | 00:13:51.789 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 13     | 00:13:51.789 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 14     | 00:13:51.789 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 15     | 00:13:51.789 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 16     | 00:13:51.789 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 17     | 00:13:51.789 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 18     | 00:13:51.789 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00120089 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 19     | 00:13:51.789 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 20     | 00:13:51.789 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 21     | 00:13:51.911 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 22     | 00:13:51.912 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 23     | 00:13:51.912 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 24     | 00:13:51.912 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 25     | 00:13:51.912 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 26     | 00:13:51.912 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 27     | 00:13:51.912 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 28     | 00:13:51.932 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 29     | 00:13:51.932 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 30     | 00:13:51.932 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 31     | 00:13:51.932 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 32     | 00:13:51.932 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 33     | 00:13:51.933 | 4    | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00120089 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 34     | 00:13:51.937 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 35     | 00:13:51.937 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 36     | 00:13:51.991 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | 0                | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_OBJECT_NAME_NOT_FOUND | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0                                                                                                                                                               |
+| 37     | 00:13:51.992 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | 0                | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_OBJECT_NAME_NOT_FOUND | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0                                                                                                                                                               |
+| 38     | 00:14:24.396 |      | System        | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 39     | 00:15:36.317 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | 0                | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_OBJECT_NAME_NOT_FOUND | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0                                                                                                                                                               |
+| 40     | 00:15:36.318 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | 0                | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_OBJECT_NAME_NOT_FOUND | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0                                                                                                                                                               |
+| 41     | 00:15:36.318 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78379036170 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg                                                           | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 42     | 00:15:36.318 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78379036170 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg                                                           | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 43     | 00:15:36.318 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78379036170 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg                                                           | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 44     | 00:15:36.318 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78379036170 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg                                                           | STATUS_SUCCESS               | FILE_OPEN CreOpts: 0 Access: 00100002 Share: 00000003 Attrib: 0 Result: FILE_OPENED                                                                                                                                                  |
+| 45     | 00:15:36.319 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78379036170 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg                                                           | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 46     | 00:15:36.319 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78379036170 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg                                                           | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 47     | 00:15:36.319 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 48     | 00:15:36.319 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 49     | 00:15:36.528 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 50     | 00:15:36.528 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 51     | 00:15:36.528 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 52     | 00:15:36.530 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 53     | 00:15:36.530 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 54     | 00:15:36.530 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 55     | 00:15:36.531 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 56     | 00:15:36.532 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 57     | 00:15:36.532 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 58     | 00:15:36.532 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 59     | 00:15:36.532 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 60     | 00:15:36.532 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 61     | 00:15:36.533 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00120089 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 62     | 00:15:36.533 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 63     | 00:15:36.533 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 64     | 00:15:36.535 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 65     | 00:15:36.535 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 66     | 00:15:36.535 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 67     | 00:15:36.535 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 68     | 00:15:36.535 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 69     | 00:15:36.535 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 70     | 00:15:36.536 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 72     | 00:15:36.536 |      | git-annex.exe | IRP_MJ_READ               | 60900     | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | Offset: 00000000-00000000 ToRead: 2000 Read: 48                                                                                                                                                                                      |
+| 71     | 00:15:36.536 |      | git-annex.exe | IRP_MJ_READ               | 60403     | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | Offset: 00000000-00000000 ToRead: 1000 Read: 48                                                                                                                                                                                      |
+| 73     | 00:15:36.536 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_END_OF_FILE           | Offset: 00000000-00000048 ToRead: 2000 Read: 0                                                                                                                                                                                       |
+| 74     | 00:15:36.536 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 75     | 00:15:36.536 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 76     | 00:15:36.537 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 77     | 00:15:36.537 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 78     | 00:15:36.537 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 79     | 00:15:36.537 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 80     | 00:15:36.537 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 81     | 00:15:36.537 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 82     | 00:15:36.537 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 83     | 00:15:36.537 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 84     | 00:15:36.537 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 85     | 00:15:36.537 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 86     | 00:15:36.537 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 87     | 00:15:36.538 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00120089 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 88     | 00:15:36.538 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 89     | 00:15:36.538 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 90     | 00:15:36.538 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00200040 Access: 00010080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 91     | 00:15:36.538 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 92     | 00:15:36.538 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 93     | 00:15:36.540 | 1    | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 94     | 00:15:36.541 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 95     | 00:15:36.541 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 96     | 00:15:36.541 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 97     | 00:15:36.541 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 98     | 00:15:36.541 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 99     | 00:15:36.541 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 100    | 00:15:36.541 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 101    | 00:15:36.541 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 102    | 00:15:36.542 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 103    | 00:15:36.542 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 104    | 00:15:36.542 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 105    | 00:15:36.542 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00120089 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 106    | 00:15:36.542 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 107    | 00:15:36.542 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 108    | 00:15:36.543 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00200020 Access: 00100100 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 109    | 00:15:36.543 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 110    | 00:15:36.543 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 111    | 00:15:36.554 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 112    | 00:15:36.554 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 113    | 00:15:36.557 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 114    | 00:15:36.557 | 1    | git-annex.exe | IRP_MJ_READ               | 60900     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | Offset: 00000000-00000000 ToRead: 2000 Read: 2000                                                                                                                                                                                    |
+| 115    | 00:15:36.558 | 18   | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 116    | 00:15:36.576 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 117    | 00:15:36.687 | 2    | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 118    | 00:15:36.690 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 119    | 00:15:36.690 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 120    | 00:15:36.690 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 121    | 00:15:36.691 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 122    | 00:15:36.691 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 123    | 00:15:36.691 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 124    | 00:15:36.691 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 125    | 00:15:36.691 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 126    | 00:15:36.691 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 127    | 00:15:36.692 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 128    | 00:15:36.692 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 129    | 00:15:36.692 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 130    | 00:15:36.692 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 131    | 00:15:36.692 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 132    | 00:15:36.692 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 133    | 00:15:36.692 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 134    | 00:15:36.692 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 135    | 00:15:36.693 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00120089 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 136    | 00:15:36.693 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 137    | 00:15:36.693 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 138    | 00:15:36.695 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 139    | 00:15:36.695 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 140    | 00:15:36.695 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 141    | 00:15:36.695 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 142    | 00:15:36.696 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 143    | 00:15:36.696 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 144    | 00:15:36.716 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 145    | 00:15:36.717 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 146    | 00:15:36.717 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 147    | 00:15:36.717 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 148    | 00:15:36.717 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 149    | 00:15:36.717 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 150    | 00:15:36.717 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 151    | 00:15:36.717 |      | git-annex.exe | IRP_MJ_READ               | 60900     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00000000 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 152    | 00:15:36.719 |      | System        | IRP_MJ_CLOSE              | 404       | FFFFA78403C2D7C0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 153    | 00:15:36.720 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00007FF0 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 154    | 00:15:36.720 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-0000FFE0 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 155    | 00:15:36.720 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00017FD0 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 156    | 00:15:36.720 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-0001FFC0 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 157    | 00:15:36.721 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00027FB0 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 158    | 00:15:36.722 | 34   | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-0002FFA0 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 159    | 00:15:36.757 | 2    | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00037F90 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 296985 | 00:17:46.052 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000002-437807F0 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 296986 | 00:17:46.052 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000002-437887E0 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 296987 | 00:17:46.053 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000002-437907D0 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 296988 | 00:17:46.053 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000002-437987C0 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 296989 | 00:17:46.068 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000002-437A07B0 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 296990 | 00:17:46.069 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000002-437A87A0 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 296991 | 00:17:46.069 | 23   | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000002-437B0790 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 296992 | 00:17:46.096 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000002-437B8780 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 296993 | 00:17:46.099 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000002-437C0770 ToRead: 7FF0 Read: 7FF0                                                                                                                                                                                    |
+| 296994 | 00:17:46.099 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000002-437C8760 ToRead: 7FF0 Read: 131B                                                                                                                                                                                    |
+| 296995 | 00:17:46.099 | 1    | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_END_OF_FILE           | Offset: 00000002-437C9A7B ToRead: 6CD5 Read: 0                                                                                                                                                                                       |
+| 296996 | 00:17:46.101 |      | git-annex.exe | IRP_MJ_READ               |           | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_END_OF_FILE           | Offset: 00000002-437C9A7B ToRead: 7FF0 Read: 0                                                                                                                                                                                       |
+| 296997 | 00:17:46.102 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 296998 | 00:17:46.102 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 296999 | 00:17:46.102 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297000 | 00:17:46.102 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297001 | 00:17:46.102 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297002 | 00:17:46.102 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297003 | 00:17:46.103 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297004 | 00:17:46.103 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297005 | 00:17:46.107 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 297006 | 00:17:46.107 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297007 | 00:17:46.107 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297008 | 00:17:46.108 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297009 | 00:17:46.108 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297010 | 00:17:46.108 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297011 | 00:17:46.109 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00120089 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297012 | 00:17:46.109 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297013 | 00:17:46.109 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297014 | 00:17:46.114 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 297015 | 00:17:46.114 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297016 | 00:17:46.114 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297017 | 00:17:46.115 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297018 | 00:17:46.115 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297019 | 00:17:46.115 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297020 | 00:17:46.275 |      | git.exe       | IRP_MJ_NETWORK_QUERY_OPEN |           | 0                | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\.gitattributes                                                                                            | STATUS_OBJECT_NAME_NOT_FOUND | FileNetworkOpenInformation CreateTime: 0 LastAccTime: 0 LastWrtTime: 0 ChangeTime: 0 AllocationSize: 00000000-00000000 EndOfFile: 00000000-00000000 Attrib: 0                                                                        |
+| 297021 | 00:17:57.163 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297022 | 00:17:57.163 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297023 | 00:17:57.163 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297024 | 00:17:57.164 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297025 | 00:17:57.164 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297026 | 00:17:57.164 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297027 | 00:17:57.164 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 297028 | 00:17:57.164 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297029 | 00:17:57.164 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297030 | 00:17:57.165 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297031 | 00:17:57.165 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297032 | 00:17:57.165 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297033 | 00:17:57.165 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00120089 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297034 | 00:17:57.166 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297035 | 00:17:57.166 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297036 | 00:17:57.170 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 297037 | 00:17:57.170 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297038 | 00:17:57.170 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297039 | 00:17:57.171 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297040 | 00:17:57.171 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297041 | 00:17:57.171 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297042 | 00:17:57.249 |      | git.exe       | IRP_MJ_CREATE             | 884       | FFFFA7841BF14170 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\arkistoidut                                                                                               | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100081 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297043 | 00:17:57.249 |      | git.exe       | IRP_MJ_CLEANUP            | 404       | FFFFA7841BF14170 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\arkistoidut                                                                                               | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297044 | 00:17:57.249 |      | git.exe       | IRP_MJ_CLOSE              | 404       | FFFFA7841BF14170 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\arkistoidut                                                                                               | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297045 | 00:17:57.251 |      | git.exe       | IRP_MJ_NETWORK_QUERY_OPEN |           | 0                | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FileNetworkOpenInformation CreateTime: 01D79ABF-4571077F LastAccTime: 01D79ABF-D0AAA385 LastWrtTime: 01D79ABF-833DDB03 ChangeTime: 01D79ABF-8373B7ED AllocationSize: 00000002-437CA000 EndOfFile: 00000002-437C9A7B Attrib: 00000020 |
+| 297046 | 00:17:57.251 |      | git.exe       | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000003 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 297047 | 00:17:57.253 |      | git.exe       | IRP_MJ_NETWORK_QUERY_OPEN |           | 0                | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\.gitattributes                                                                                            | STATUS_OBJECT_NAME_NOT_FOUND | FileNetworkOpenInformation CreateTime: 0 LastAccTime: 0 LastWrtTime: 0 ChangeTime: 0 AllocationSize: 00000000-00000000 EndOfFile: 00000000-00000000 Attrib: 0                                                                        |
+| 297048 | 00:17:57.292 | 8    | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00000000 ToRead: 8000 Read: 8000                                                                                                                                                                                    |
+| 297049 | 00:17:57.300 | 25   | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00008000 ToRead: 8000 Read: 8000                                                                                                                                                                                    |
+| 297050 | 00:17:57.325 | 23   | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00010000 ToRead: 10000 Read: 10000                                                                                                                                                                                  |
+| 297051 | 00:17:57.349 | 10   | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00020000 ToRead: 20000 Read: 20000                                                                                                                                                                                  |
+| 297052 | 00:17:57.359 | 1    | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00040000 ToRead: 40000 Read: 40000                                                                                                                                                                                  |
+| 297053 | 00:17:57.362 | 11   | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00080000 ToRead: 80000 Read: 80000                                                                                                                                                                                  |
+| 297054 | 00:17:57.374 | 9    | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00100000 ToRead: 100000 Read: 100000                                                                                                                                                                                |
+| 297055 | 00:17:57.384 | 29   | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00200000 ToRead: 100000 Read: 100000                                                                                                                                                                                |
+| 297056 | 00:17:57.415 | 4    | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00300000 ToRead: 100000 Read: 100000                                                                                                                                                                                |
+| 297057 | 00:17:57.421 | 11   | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00400000 ToRead: 100000 Read: 100000                                                                                                                                                                                |
+| 297058 | 00:17:57.435 | 28   | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00500000 ToRead: 100000 Read: 100000                                                                                                                                                                                |
+| 297059 | 00:17:57.465 | 13   | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00600000 ToRead: 100000 Read: 100000                                                                                                                                                                                |
+| 297060 | 00:17:57.479 | 27   | git.exe       | IRP_MJ_READ               | 60043     | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\.git\\annex\\objects\\8b2\\d61\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg\\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg | STATUS_SUCCESS               | Offset: 00000000-00700000 ToRead: 100000 Read: 100000                                                                                                                                                                                |
+| 297061 | 00:17:57.756 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297062 | 00:17:57.756 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297063 | 00:17:57.756 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297064 | 00:17:57.756 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297065 | 00:17:57.756 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297066 | 00:17:57.756 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297067 | 00:17:57.757 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 297068 | 00:17:57.757 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297069 | 00:17:57.757 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297070 | 00:17:57.757 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297071 | 00:17:57.757 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297072 | 00:17:57.757 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297073 | 00:17:57.757 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00120089 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297074 | 00:17:57.757 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297075 | 00:17:57.757 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297076 | 00:17:57.759 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 297077 | 00:17:57.759 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297078 | 00:17:57.759 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297079 | 00:17:57.760 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297080 | 00:17:57.760 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297081 | 00:17:57.760 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297082 | 00:17:58.285 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297083 | 00:17:58.285 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297084 | 00:17:58.285 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297085 | 00:17:58.285 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297086 | 00:17:58.285 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297087 | 00:17:58.285 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297088 | 00:17:58.286 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 297089 | 00:17:58.286 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297090 | 00:17:58.286 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297091 | 00:17:58.286 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297092 | 00:17:58.286 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297093 | 00:17:58.286 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297094 | 00:17:58.286 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00120089 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297095 | 00:17:58.286 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297096 | 00:17:58.286 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297097 | 00:17:58.288 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000060 Access: 00120089 Share: 00000007 Attrib: 00000080 Result: FILE_OPENED                                                                                                                                    |
+| 297098 | 00:17:58.288 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297099 | 00:17:58.288 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297100 | 00:17:58.289 |      | git-annex.exe | IRP_MJ_CREATE             | 884       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               | FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 0 Result: FILE_OPENED                                                                                                                                           |
+| 297101 | 00:17:58.289 |      | git-annex.exe | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297102 | 00:17:58.289 |      | git-annex.exe | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297103 | 00:17:58.410 |      | git.exe       | IRP_MJ_CLEANUP            | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+| 297104 | 00:17:58.410 |      | git.exe       | IRP_MJ_CLOSE              | 404       | FFFFA783ED9DF1B0 | I:\\Reflect-varmistukset-test\\Jarkon ThinkPad T450s (Win10 v21H1) . B\\9BEAE03792B9FAFB-01-01.mrimg                                                                              | STATUS_SUCCESS               |                                                                                                                                                                                                                                      |
+"""]]
+</details>
+
+If you compare the latter transcript and the FileSpy trace (which contains only open, close and read requests),
+you notice that around timestamp
+"[2021-08-27 00:15:36.6868986]" git-annex says
+"(Annex.Branch) set 8b2\d61\MD5E-s9722174075--f7cd18042ba15862c395d98f61eed228.mrimg.log" after which
+it stays silent for around two minutes during which the FileSpy trace shows it's reading[^1] the annexed file
+from .git/annex/objects presumably for verification / checksumming (I've removed the boring middle section
+from the originally huge trace log, so that's why the event number in the first column increases suddenly
+from 159 to 296985).
+
+[^1]: incidentally, 0x7FF0 (32752) bytes at a time 
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Git Annex is great. It works quite nicely with my multi-gigabyte backup files (largest around 180GB) via the BLAKE2B160E backend :)
+
+[[!meta title="windows: sync -C takes longer than get, apparently extra checksum"]] 
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment
new file mode 100644
index 0000000000..1cb822e8e7
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-10-01T14:57:11Z"
+ content="""
+The second hash is done by isUnmodifiedLowLevel, and
+is indeed done because the inode cache does not verify.
+
+The inode cache does not verify because for some reason,
+it does not have any inode cached for the object file
+when that is called.
+
+The reason this only happens in sync and not get is that sync also sends
+files it received to other remotes, and to do that it needs to check if
+their content is present. Which is normally inexpensive, so not a problem.
+
+It so happens that sync calls inAnnex even when
+there are no other remotes to send the content to. Which is unnecessary, and
+avoiding that could be used to fix this problem. But there would still be a
+problem if there were some other remote that the content ought to be sent to,
+if it still called inAnnex in that case. Maybe it's possible to avoid it calling
+inAnnex at all though, since it knows when it's gotten the content.
+
+The inode cache gets written to the database before sync calls
+inAnnex. And queued writes get flushed to the database before reading
+from it. I've confirmed all this is happening.
+So why does getting the inode cache from the db not see the previously
+written data?
+
+I suspect this is where NTFS enters the picture. Perhaps
+something about it is causing changes to the sqlite database to not
+be visible immediately to a reader. Might involve whatever locking
+sqlite is or is not able to do on NTFS, or something like that.
+
+(Interestingly, at the end of the sync, the smudge clean filter
+gets called, and it is able to read the inode cache from the db
+at that point. So another process run just a bit later can see the data.)
+"""]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_11_d485bbc1c0f2fceaaa2e4142dccdc1f7._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_11_d485bbc1c0f2fceaaa2e4142dccdc1f7._comment
new file mode 100644
index 0000000000..820b3972aa
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_11_d485bbc1c0f2fceaaa2e4142dccdc1f7._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2021-10-01T15:57:12Z"
+ content="""
+Fixed by avoiding sync calling inAnnex when it knows it has the content,
+because it just got it.
+
+This does leave open the possibility that there are similar situations
+elsewhere, that lead to either extra work like this, or to incorrect
+behavior. Since sqlite write followed by a read is generally something
+git-annex is careful of, and also since it is generally careful to have
+reasonable behavior is sqlite somehow loses data, I'm not too worried about
+incorrect behavior. I feel comfortable closing this bug with just this fix,
+despite not getting to the bottom of the issue of why sqlite writes are
+not immediately able to be read back on NTFS.
+"""]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_12_b0132b0f846e4882a5511b53694a1fa2._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_12_b0132b0f846e4882a5511b53694a1fa2._comment
new file mode 100644
index 0000000000..d5a71432b0
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_12_b0132b0f846e4882a5511b53694a1fa2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 12"
+ date="2021-10-02T19:58:17Z"
+ content="""
+Thanks, Joey! 💐 Well done. :)
+"""]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_1_fa2fb2493ea1244f334b54e6af2b553b._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_1_fa2fb2493ea1244f334b54e6af2b553b._comment
new file mode 100644
index 0000000000..abcd6f1719
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_1_fa2fb2493ea1244f334b54e6af2b553b._comment
@@ -0,0 +1,73 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-09-06T18:52:21Z"
+ content="""
+I tried to reproduce this on Linux, and cannot:
+
+	joey@darkstar:~/tmp/r>/usr/bin/time git-annex get bigfile 
+	get bigfile (from origin...) 
+	ok                                   
+	(recording state in git...)
+	11.66user 2.08system 0:13.76elapsed 99%CPU (0avgtext+0avgdata 99012maxresident)k
+	206440inputs+2048856outputs (46major+21865minor)pagefaults 0swaps
+	joey@darkstar:~/tmp/r>git annex drop
+	drop bigfile ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/r>/usr/bin/time git annex sync --no-commit --no-push --no-pull --content-of bigfile 
+	get bigfile (from origin...) 
+	ok                                  
+	(recording state in git...)
+	11.43user 1.91system 0:13.43elapsed 99%CPU (0avgtext+0avgdata 97132maxresident)k
+	60016inputs+2048312outputs (25major+11680minor)pagefaults 0swaps
+
+One reason it may do an extra checksum is if for some reason the inode
+cache is stale. Since [[!commit 3b5a3e168d8decd196509ad582ad4b8795d979a6]]
+it will check that and checksum before starting to send the content.
+
+In this case, it will display "(checksum...)" before the progress display
+has started.
+
+One way I can reproduce that, on Linux, is to touch the annex object file
+in the remote git repository before running git-annex. This is the result:
+
+	joey@darkstar:~/tmp/r>/usr/bin/time git-annex get bigfile 
+	get bigfile (from origin...) (checksum...) 
+	ok                                   
+	(recording state in git...)
+	22.06user 2.22system 0:24.85elapsed 97%CPU (0avgtext+0avgdata 97192maxresident)k
+	704inputs+2048432outputs (33major+10701minor)pagefaults 0swaps
+
+But that shows that git-annex get also behaves that way, which does not
+explain why only git-annex sync would have the problem for you. 
+(And the two run the same code; sync literally runs code from get.) Also
+I don't know why the inode cache would be getting stale on windows.
+
+If it does not display "(checksum...)" before the progress display,
+it's certianly not that. And if it does not display "(checksum...)"
+at any point at all, that would be good to know, because normally
+git-annex does display that when checksumming.
+Your transcript seems to show no such output.
+
+At the "2021-08-27 00:15:36.6868986" timestamp in your log, it's just
+completed updating the location log, and you identify the pause after that
+as where it's checksumming. So that seems to suggest it's already
+transferred the content there, and updated the location log, before
+checksumming. But it doesn't do anything normally
+after updating the location log, and it won't update the location log
+before it's satisfied it transferred the right content, so after any
+checksumming.
+
+Possibly `git annex sync` is trying to drop the content from some
+remote due to its preferred content setting no longer wanting the content
+to be there. Do you have preferred content expressions configured?
+(I'm doubtful about this theaory because I don't think it ever hashes the
+content during a drop, but one difference between `get` and `sync`
+is that sync drops..)
+
+Only other thing I can think that it could be is perhaps git is running
+the smudge/clean filter on the content, after the transfer, and git-annex
+hashes it again when run that way. Hard for me to tell from the filespray
+log if that might be the case. Setting `GIT_TRACE=1` would show if this
+happens.
+"""]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_2_ccd90a2ad9cb9c896a47d62ecdfc5304._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_2_ccd90a2ad9cb9c896a47d62ecdfc5304._comment
new file mode 100644
index 0000000000..449f30f14c
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_2_ccd90a2ad9cb9c896a47d62ecdfc5304._comment
@@ -0,0 +1,121 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 2"
+ date="2021-09-25T05:47:15Z"
+ content="""
+This is really odd. I tried to reproduce the issue in a new git annex repo and if I remember correctly I couldn't
+-- even on Windows. It must be something that has crept up during the usage of my specific annex meant for
+storing whole-system images/backups. Most definitely it does not display \"(checksum...)\" at any point. Nor does
+running my git-annex commands while the environment variable `GIT_TRACE=1` is set show any evidence of git running
+the smudge/clean filters.
+
+I prepared a minimal version of my repo by way of the tip [[tips/splitting_a_repository]]. It does not have any
+preferred-content (or required) expressions active as far as I know. It includes only one \"small\" (9GB) backup file,
+the differential backup named `9BEAE03792B9FAFB-01-01.mrimg`. This repo and its clones exhibit all the same symptoms
+reported above and most notably also on Linux with a ntfs-3g mount. In fact -- after some iteration -- I wrote
+a bash script to test it out with strace(1):
+
+[[!format sh \"\"\"
+#! /usr/bin/env bash
+
+set -eu
+set -o pipefail
+
+file_under_test=9BEAE03792B9FAFB-01-01.mrimg
+
+strace_log_file_pre=strace.git-annex--op-
+strace_log_file_post=.LOG
+strace_flags='-y -f -qq -tt'
+
+debug_log_file_pre=git-annex--op-
+debug_log_file_post=.LOG
+
+echo '* Running/strace(1)ing `git annex get` and `git annex sync -C` while targeting the same file ($file_under_test).'
+echo '* We also `git annex drop` the file before each operation.'
+echo '*'
+echo '* Depending on the file this might take a while :)'
+echo '*'
+
+# op: get
+##
+echo '* op: get'
+echo
+
+git annex drop ${file_under_test}
+
+strace -e trace=read ${strace_flags} -o ${strace_log_file_pre}get${strace_log_file_post} \
+    /bin/time git annex get ${file_under_test} \
+    --debug 2> ${debug_log_file_pre}get${debug_log_file_post}
+
+annexobj=$(git annex find --format='.git/annex/objects/${hashdirlower}${backend}-s${bytesize}--${keyname}/${backend}-s${bytesize}--${keyname}\n' ${file_under_test})
+
+echo '* Number of read(2) file operation of annex object during `get` sub-command:' \
+    $(fgrep \"${annexobj}\" ${strace_log_file_pre}get${strace_log_file_post} | wc -l)
+echo
+
+# op: sync -C
+##
+echo '* op: sync -C'
+echo
+
+git annex drop ${file_under_test}
+
+strace -e trace=read ${strace_flags} -o ${strace_log_file_pre}sync-C${strace_log_file_post} \
+    /bin/time git annex sync --no-commit --no-push --no-pull -C ${file_under_test} \
+    --debug 2> ${debug_log_file_pre}sync-C${debug_log_file_post}
+
+annexobj=$(git annex find --format='.git/annex/objects/${hashdirlower}${backend}-s${bytesize}--${keyname}/${backend}-s${bytesize}--${keyname}\n' ${file_under_test})
+
+echo '* Number of read(2) file operation of annex object during `sync -C` sub-command:' \
+    $(fgrep \"${annexobj}\" ${strace_log_file_pre}sync-C${strace_log_file_post} | wc -l)
+echo
+
+echo '* Finished.'
+
+# end of script
+\"\"\" 
+]]
+
+One such test run on Ubuntu 20.04 (git-annex version 8.20210804-gab7b5a492) shows the following:
+
+[[!format sh \"\"\"
+jkniiv@ubuntu:/media/veracrypt1/Reflect-varmistukset-test@issue2$ _scripts/exemplify-issue.git-annex--get-vs-sync-C.sh 
+* Running/strace(1)ing `git annex get` and `git annex sync -C` whilst targeting the same file ($file_under_test).
+* We also `git annex drop` the file before each operation.
+*
+* Depending on the file this might take a while :)
+*
+* op: get
+
+get 9BEAE03792B9FAFB-01-01.mrimg (from origin...) 
+ok                                    
+(recording state in git...)
+* Number of read(2) file operation of annex object during `get` sub-command: 296845
+
+* op: sync -C
+
+drop 9BEAE03792B9FAFB-01-01.mrimg ok
+(recording state in git...)
+get 9BEAE03792B9FAFB-01-01.mrimg (from origin...) 
+ok                                    
+(recording state in git...)
+(recording state in git...)
+* Number of read(2) file operation of annex object during `sync -C` sub-command: 593690
+
+* Finished.
+jkniiv@ubuntu:/media/veracrypt1/Reflect-varmistukset-test@issue2$ bc
+bc 1.07.1
+Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc.
+This is free software with ABSOLUTELY NO WARRANTY.
+For details type `warranty'. 
+296845 * 2
+593690
+\"\"\"
+]]
+
+So the `sync -C` operation above seems to issue exactly double the amounts of reads compared to the `get` operation.
+The `get` op doesn't seems to do any reads of the annex object on Windows but I suppose on Linux what it does is
+a `tailVerify` instead of passing the file through a pipe or sth.
+
+"""]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_3_c7e71722379431789f26b5e743e13d9c._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_3_c7e71722379431789f26b5e743e13d9c._comment
new file mode 100644
index 0000000000..31ddf54fc4
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_3_c7e71722379431789f26b5e743e13d9c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 3"
+ date="2021-09-25T06:05:40Z"
+ content="""
+Joey, would you be interested in taking a look at my minimal test case if I could send you the repo somehow?
+I could just forcefully `drop` the last sensitive file in the annex and add an innocuous, say 100MB random file,
+into the annex instead and then zip the repo up (with 7z or fsarchiver) and send it to you (by whatever means)
+if that would be fine with you, perhaps? I know this an odd corner case but I would be definitely grateful if
+you could oblige this hell-bent Windows user here. :)
+
+"""]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_4_f730f3593ab5aeac34e74ec48f943949._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_4_f730f3593ab5aeac34e74ec48f943949._comment
new file mode 100644
index 0000000000..ca5d6e5da1
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_4_f730f3593ab5aeac34e74ec48f943949._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-09-27T16:17:19Z"
+ content="""
+Sure, if you can produce a repository you're willing to share that can
+reproduce the problem I am willing to take a look at it. Just email me a
+link and instructions for how to use the repository to see the problem.
+"""]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_5_934ee22209920f8429c0ac71002bab1e._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_5_934ee22209920f8429c0ac71002bab1e._comment
new file mode 100644
index 0000000000..21bd7c5d4c
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_5_934ee22209920f8429c0ac71002bab1e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 5"
+ date="2021-09-29T04:38:08Z"
+ content="""
+Thanks, Joey. Email with a gdrive link and explanation sent your way.
+"""]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_6_1611ef71978eeb61da4c42cffcff2411._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_6_1611ef71978eeb61da4c42cffcff2411._comment
new file mode 100644
index 0000000000..70bef48a7e
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_6_1611ef71978eeb61da4c42cffcff2411._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-09-30T16:51:42Z"
+ content="""
+You may need to resend that email, I have not received it. I will reply to
+it when I do get it.
+"""]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_7_6700aabc3b4cb02a5b370cf4c71c6a0c._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_7_6700aabc3b4cb02a5b370cf4c71c6a0c._comment
new file mode 100644
index 0000000000..b311f1cc44
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_7_6700aabc3b4cb02a5b370cf4c71c6a0c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="Email resent from my personal domain jibun.eu"
+ date="2021-09-30T18:22:44Z"
+ content="""
+@Joey: It seems Gmail didn't like my email or something didn't like Gmail. :) In any case I resent the message from
+my own domain jibun.eu (I usually don't use it cos Gmail has a better spam filter -- which has its pluses and minuses).
+I hope your email address is still id ät joeyh.name?
+
+"""]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_7_a0b287e187396b7072e4d7bab3664621._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_7_a0b287e187396b7072e4d7bab3664621._comment
new file mode 100644
index 0000000000..80a7f63c1d
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_7_a0b287e187396b7072e4d7bab3664621._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-09-30T18:44:53Z"
+ content="""
+I've received the sample repo, and can reproduce the problem using its
+script. (After changing a /bin/time to not hardcode the wrong path.)
+
+	get 9BEAE03792B9FAFB-01-01--partial.dat.age (from origin...) 
+	ok                                   
+	(recording state in git...)
+	* Number of read(2) file operations of annex object during `get` sub-command: 3205
+	
+	* op: sync -C
+	
+	drop 9BEAE03792B9FAFB-01-01--partial.dat.age ok
+	(recording state in git...)
+	get 9BEAE03792B9FAFB-01-01--partial.dat.age (from origin...) 
+	ok                                   
+	(recording state in git...)
+	(recording state in git...)
+	* Number of read(2) file operations of annex object during `sync -C` sub-command: 6410
+
+Should be possible to track down the extra work from here.
+
+(Sample repo stored in my big annex as
+`git-annex-test-repos/Reflect-varmistukset-test@issue.tar`.
+Mail with details of how to use it is
+`1321234683.1930009.1633025607916@privateemail.com`.
+Note that NTFS filesystem needs to be 1.5 gb or larger in size.)
+"""]]
diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_8_0b4e0acecbcc6a8736849801446a189c._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_8_0b4e0acecbcc6a8736849801446a189c._comment
new file mode 100644
index 0000000000..575b876226
--- /dev/null
+++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_8_0b4e0acecbcc6a8736849801446a189c._comment
@@ -0,0 +1,52 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2021-09-30T19:15:14Z"
+ content="""
+Initial look at the strace of the sync shows it's opening the
+object file after it copies it from the remote repo, and reading
+it a second time.
+
+	1654392 14:58:09.293550 openat(AT_FDCWD, "/mnt/Reflect-varmistukset-test@issue/.git/annex/objects/f19/dad/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age", O_RDONLY|O_NOCTTY|O_NONBLOCK <unfinished ...>
+	...
+	1654392 14:58:13.572543 openat(AT_FDCWD, ".git/annex/objects/f19/dad/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 15
+	1654392 14:58:13.573055 fstat(15</mnt/Reflect-varmistukset-test@issue2/.git/annex/objects/f19/dad/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age>, {st_mode=S_IFREG|0777, st_size=104883384, ...}) = 0
+	1654393 14:58:13.573282 <... read resumed>"\1\0\0\0\0\0\0\0", 8) = 8
+	1654392 14:58:13.573370 ioctl(15</mnt/Reflect-varmistukset-test@issue2/.git/annex/objects/f19/dad/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age>, TCGETS <unfinished ...>
+	1654393 14:58:13.573471 read(4<anon_inode:[timerfd]>,  <unfinished ...>
+	1654392 14:58:13.573601 <... ioctl resumed>, 0x7ffd3d3fa9d0) = -1 EINVAL (Invalid argument)
+	1654392 14:58:13.573753 read(15</mnt/Reflect-varmistukset-test@issue2/.git/annex/objects/f19/dad/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age>, "age-encryption.org/v1\n-> X25519 "..., 32752) = 32752
+	1654393 14:58:13.574238 <... read resumed>"\1\0\0\0\0\0\0\0", 8) = 8
+	1654392 14:58:13.574356 read(15</mnt/Reflect-varmistukset-test@issue2/.git/annex/objects/f19/dad/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age>,  <unfinished ...>
+
+Certianly does look like a checksum operation.
+
+Just before the second open is this:
+
+	1654396 14:58:13.570074 pread64(21</mnt/Reflect-varmistukset-test@issue2/.git/annex/keysdb/db>, "\n\0\0\0\0\20\0\0\17\251\0\0\0\0\0\0\0\0
+	\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 20480) = 4096
+	1654393 14:58:13.570353 <... read resumed>"\1\0\0\0\0\0\0\0", 8) = 8
+	1654396 14:58:13.570464 futex(0xb7af808, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
+	1654393 14:58:13.570562 read(4<anon_inode:[timerfd]>,  <unfinished ...>
+	1654396 14:58:13.570727 <... futex resumed>) = 1
+	1654392 14:58:13.570834 <... futex resumed>) = 0
+	1654396 14:58:13.570948 futex(0xb7afb28, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
+	1654392 14:58:13.571040 futex(0xb7af810, FUTEX_WAKE_PRIVATE, 1) = 0
+	1654393 14:58:13.571239 <... read resumed>"\1\0\0\0\0\0\0\0", 8) = 8
+	1654393 14:58:13.571356 read(4<anon_inode:[timerfd]>,  <unfinished ...>
+	1654392 14:58:13.571450 stat(".git/annex/objects/f19/dad/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age/MD5E-s104883384--4187e
+	ad516ef69c540aab3d27eba27c5.dat.age", {st_mode=S_IFREG|0777, st_size=104883384, ...}) = 0
+	1654392 14:58:13.571958 access(".git/annex/objects/f19/dad/MD5E-s104883384--4187ead516ef69c540aab3d27eba27c5.dat.age/MD5E-s104883384--418
+	7ead516ef69c540aab3d27eba27c5.dat.age", F_OK) = 0
+	1654393 14:58:13.572314 <... read resumed>"\1\0\0\0\0\0\0\0", 8) = 8
+	1654393 14:58:13.572425 read(4<anon_inode:[timerfd]>,  <unfinished ...>
+
+That looks like a query from the keys db for the inode cache,
+followed by checking stat of the object to verify it.
+So maybe an inode cache verification issue, which is being
+resolved by a checksum..
+
+So far, I've ruled out prepSendAnnex's call to sameInodeCache.
+The InodeCache of the object verifies there. The second open comes
+later.
+"""]]
diff --git a/doc/bugs/____adjusted_branch_subtree_regression__58___FAIL_.mdwn b/doc/bugs/____adjusted_branch_subtree_regression__58___FAIL_.mdwn
new file mode 100644
index 0000000000..16054a13ed
--- /dev/null
+++ b/doc/bugs/____adjusted_branch_subtree_regression__58___FAIL_.mdwn
@@ -0,0 +1,14 @@
+### Please describe the problem.
+
+in recent builds [eg](https://github.com/datalad/git-annex/actions/runs/7417377022/job/20183877530#step:7:1288)
+
+```
+    adjusted branch subtree regression: FAIL (1.26s)
+      Test.hs:1675:
+      a/b/x/y missing from master after adjusted branch sync
+      Use -p '/adjusted branch subtree regression/' to rerun this test only.
+```
+
+may be more
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/____adjusted_branch_subtree_regression__58___FAIL_/comment_1_2b2040240fe8f01a6348eb68959d9319._comment b/doc/bugs/____adjusted_branch_subtree_regression__58___FAIL_/comment_1_2b2040240fe8f01a6348eb68959d9319._comment
new file mode 100644
index 0000000000..2f5dbc69ff
--- /dev/null
+++ b/doc/bugs/____adjusted_branch_subtree_regression__58___FAIL_/comment_1_2b2040240fe8f01a6348eb68959d9319._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-01-10T20:32:54Z"
+ content="""
+This was caused by [[!commit 2c86651180d5c8648b8244be894c26bc98a6c334]]
+and so I've reverted that commit for now.
+
+Leaving this bug open because that commit was an important optimisation and
+needs to be fixed and reapplied.
+"""]]
diff --git a/doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git.mdwn b/doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git.mdwn
new file mode 100644
index 0000000000..2045310559
--- /dev/null
+++ b/doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+An encrypted remote is added to a working git annex repository (mind ":~/" in the remote add command). However, after that any git annex command fails. 
+
+### What steps will reproduce the problem?
+    > git remote add encrypted gcrypt::ssh://git@gitlab.com:~/gitlabname/reponame.git
+    > git push encrypted master
+    gcrypt: Repository not found: ssh://git@gitlab.com:~/gitlabname/reponame.git
+    gcrypt: Setting up new repository
+    gcrypt: Remote ID is :id:abcdefghijklmnopqrst
+    Counting objects: 53, done.
+    Compressing objects: 100% (52/52), done.
+    Total 53 (delta 12), reused 0 (delta 0)
+    gcrypt: Encrypting to: --throw-keyids --default-recipient-self
+    gcrypt: Requesting manifest signature
+    ...
+    To gcrypt::ssh://git@gitlab.com:~/gitlabname/reponame.git
+     * [new branch]      master -> master
+    >
+    >  git annex sync
+    git-annex: bad url ssh://git@gitlab.com:~/gitlabname/reponame.git
+
+### What version of git-annex are you using? On what operating system?
+5.20150419-g900e1b6 on Mac OS X
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+- 
+
+# End of transcript or log.
+"""]]
+
+> Fixed in [[!commit 2aa4fab62a69bb3fb5073d571d8ec110a61a144e]]
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git/comment_1_60db0d6bfc71a62b3c1021527a8d2d60._comment b/doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git/comment_1_60db0d6bfc71a62b3c1021527a8d2d60._comment
new file mode 100644
index 0000000000..4b7b0e90a7
--- /dev/null
+++ b/doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git/comment_1_60db0d6bfc71a62b3c1021527a8d2d60._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-29T15:16:31Z"
+ content="""
+According to the git-fetch man page, the syntax to use
+for this kind of url is:
+
+	ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
+
+Your url is missing the leading slash before the `~`, and has
+a : with no port specified.
+
+	ssh://git@gitlab.com:~/gitlabname/reponame.git
+
+It is in fact, not a legal url.
+
+Now, git might accept it despite not documenting it as an accepted form,
+but why wander into undefined territory when there are legal ways to write
+this url that work fine?
+
+Does GitLab promote using these malformed urls?
+"""]]
diff --git a/doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git/comment_2_49682a91147990a578929678880bd226._comment b/doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git/comment_2_49682a91147990a578929678880bd226._comment
new file mode 100644
index 0000000000..e937086445
--- /dev/null
+++ b/doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git/comment_2_49682a91147990a578929678880bd226._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://rfhbuk.pip.verisignlabs.com.pip.verisignlabs.com/"
+ nickname="rfhb"
+ subject="comment 2"
+ date="2015-04-29T15:45:34Z"
+ content="""
+Thank you. I was wondering about the URL as flagged above. When I specify the URL as I did, the git commands work but when I change it to ssh://git@gitlab.com:/~/gitlabname/reponame.git, git command fails with 
+
+    > git push encrypted master 
+    gcrypt: Development version -- Repository format MAY CHANGE
+    gcrypt: Repository not found: ssh://git@gitlab.com:/~/gitlabname/reponame.git
+    gcrypt: Setting up new repository
+    gcrypt: Remote ID is :id:xxxxxxxxxxxxxxxxx
+    Counting objects: 3, done.
+    Total 3 (delta 0), reused 0 (delta 0)
+    gcrypt: Encrypting to: --throw-keyids --default-recipient-self
+    gcrypt: Requesting manifest signature
+    .... passphase entered ... 
+    GitLab: No such project       
+    fatal: Could not read from remote repository.
+    Please make sure you have the correct access rights
+    and the repository exists.
+    error: failed to push some refs to 'gcrypt::ssh://git@gitlab.com:/~/gitlabname/reponame.git'
+
+So perhaps I need to investigate how to get gcrypt to work with remote git(lab) repositories. Thanks. 
+"""]]
diff --git a/doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git/comment_3_bf0fa06596338444a3772d1865b17e26._comment b/doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git/comment_3_bf0fa06596338444a3772d1865b17e26._comment
new file mode 100644
index 0000000000..0d7fb9c2da
--- /dev/null
+++ b/doc/bugs/_git-annex__58___bad_url_ssh__58____47____47__git__64__gitlab.com__58____126____47__gitlabname__47__reponame.git/comment_3_bf0fa06596338444a3772d1865b17e26._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-29T17:09:07Z"
+ content="""
+This works: ssh://git@gitlab.com/username/reponame.git
+"""]]
diff --git a/doc/bugs/acl_not_honoured_in_rsync_remote.mdwn b/doc/bugs/acl_not_honoured_in_rsync_remote.mdwn
new file mode 100644
index 0000000000..edc4e67d7d
--- /dev/null
+++ b/doc/bugs/acl_not_honoured_in_rsync_remote.mdwn
@@ -0,0 +1,59 @@
+in a setup where an rsync(+gnupg) remote is shared among different users of the same git-annex repository (ie, the people copying to there use different accounts on the rsync server), acls are not honored under some circumstances.
+
+the error message reads as follows:
+
+    copy …filename… (to prometheus...) Reading passphrase from file descriptor 11    
+    
+    sending incremental file list
+    rsync: recv_generator: mkdir "/home/shared/photos/encrypted_storage/9a6/0ff" failed: Permission denied (13)
+    *** Skipping any contents from this failed directory ***
+    9a6/0ff/
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1070) [sender=3.0.8]
+    
+    sent 185 bytes  received 18 bytes  135.33 bytes/sec
+    total size is 2119419  speedup is 10440.49
+    
+      This could have failed because --fast is enabled.
+    failed
+
+the acl used in my particular case is:
+
+    # file: .
+    # owner: chrysn
+    # group: chrysn
+    user::rwx
+    group::rwx
+    group:family:rwx
+    mask::rwx
+    other::r-x
+    default:user::rwx
+    default:group::rwx
+    default:group:family:rwx
+    default:mask::rwx
+    default:other::r-x
+
+sub-directories are observed to have diverging permissions, though:
+
+    # file: 794
+    # owner: chrysn
+    # group: chrysn
+    user::rwx
+    group::rwx                      #effective:r-x
+    group:family:rwx                #effective:r-x
+    mask::r-x
+    other::r-x
+    default:user::rwx
+    default:group::rwx
+    default:group:family:rwx
+    default:mask::rwx
+    default:other::r-x
+
+something seems to apply the umask (default 022) and revoke group write access from the files, overruling the acl. this is not what a umask is normally used for, and smells of [coreutils slavishly observing posix specs that don't consider all features](http://savannah.gnu.org/bugs/?19546) -- the observed effect is exactly what's described there.
+
+the git annex version used is 3.20121017 as in debian, the receiving site uses rsync 3.0.7; the affected directories come from a time when these very versions are known to have been used.
+
+this is probably not a bug of git-annex alone, but affects its operation and might be solvable by invoking rsync differently.
+
+(this is kind of a follow-up on [[forum/__34__permission_denied__34___in_fsck_on_shared_repo]])
+
+[[!tag forwarded]]
diff --git a/doc/bugs/acl_not_honoured_in_rsync_remote/comment_1_aa6fe1d7b029eae7ee71c97e0f0937a6._comment b/doc/bugs/acl_not_honoured_in_rsync_remote/comment_1_aa6fe1d7b029eae7ee71c97e0f0937a6._comment
new file mode 100644
index 0000000000..c24b021572
--- /dev/null
+++ b/doc/bugs/acl_not_honoured_in_rsync_remote/comment_1_aa6fe1d7b029eae7ee71c97e0f0937a6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 1"
+ date="2012-11-06T20:49:47Z"
+ content="""
+I don't know much about ACLs, but you might try setting `remote.prometheus.annex-rsync-options` with rsync options such as --acls or --no-acls
+"""]]
diff --git a/doc/bugs/acl_not_honoured_in_rsync_remote/comment_2_ffb9424e966ee10a4fe2d446b3042cb2._comment b/doc/bugs/acl_not_honoured_in_rsync_remote/comment_2_ffb9424e966ee10a4fe2d446b3042cb2._comment
new file mode 100644
index 0000000000..96dbc6a2e2
--- /dev/null
+++ b/doc/bugs/acl_not_honoured_in_rsync_remote/comment_2_ffb9424e966ee10a4fe2d446b3042cb2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="further tracking"
+ date="2012-11-11T01:15:41Z"
+ content="""
+the behavior is rooted in rsync, which behaves similar to `mkdir -p`. it can probably be worked around by configuring the rsync option `--chmod=775`, but that would add executability to files.
+
+i've opened a bug in rsync's bug tracker at <https://bugzilla.samba.org/show_bug.cgi?id=9377>, let's see what the developer says.
+"""]]
diff --git a/doc/bugs/acl_not_honoured_in_rsync_remote/comment_3_f93177593a2d90627672647fd5f065c9._comment b/doc/bugs/acl_not_honoured_in_rsync_remote/comment_3_f93177593a2d90627672647fd5f065c9._comment
new file mode 100644
index 0000000000..6b20bbc3a7
--- /dev/null
+++ b/doc/bugs/acl_not_honoured_in_rsync_remote/comment_3_f93177593a2d90627672647fd5f065c9._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="eigengrau"
+ subject="comment 3"
+ date="2016-01-03T07:52:36Z"
+ content="""
+I recently experimented with shared repos a bit and came across this rsync issue. I’ve found that instead of setting `rsync-options` to `--chmod=755`, you can also set it to `--chmod=ugo=rX`. This will cause the executable bit to be set only when the source file is already executable.
+"""]]
diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync.mdwn b/doc/bugs/adb_creates_empty_commits_on_import__47__sync.mdwn
new file mode 100644
index 0000000000..126d75dbec
--- /dev/null
+++ b/doc/bugs/adb_creates_empty_commits_on_import__47__sync.mdwn
@@ -0,0 +1,42 @@
+### Please describe the problem.
+
+[[!meta title="import tree creates empty commits"]]
+
+Adb special remote on both "import" and "sync" commands creates empty commits in "main" branch,
+even if files hadn't changed  in either remote or local repo.
+
+This clutters history of "main" branch (which is mostly manually curated),
+and hides commits actually introducing added/deleted files amongst the clutter.
+
+Moreover, this behavior differs from expectations: "sync" with proper remote never created empty commits in "main" branch.
+
+## What steps will reproduce the problem?
+
+Setup adb import/export, like here: 
+[[https://git-annex.branchable.com/forum/Mixed_content_repos_with_import_and_export/#comment-764ac971faf756140055333649ffb94c]].
+
+Repetition of "git annex sync --content" introduces new empty commits without proper reason.
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 8.20211118-g23ee48898
+
+
+### Please provide any additional information below.
+
+Example of "main" branch history cluttered by empty commits:
+
+[[!format txt """
+*   2022-01-01 bb23200 remote tracking branch                                       (android/main) [annex]
+|\
+* | 2022-01-01 42b8111 remote tracking branch                                       (HEAD -> main, synced/main) [annex]
+|\|
+| * 2022-01-01 223f5f7 import from android                                          [annex]
+* | 2022-01-01 f5b5f0a remote tracking branch                                       [annex]
+|\|
+* | 2022-01-01 2a6177e remote tracking branch                                       [annex]
+|\|
+| * 2022-01-01 7ef4649 import from android                                          [annex]
+"""]]
+
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_10_87efdd2a9c7091f92a6bc96e87a59e18._comment b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_10_87efdd2a9c7091f92a6bc96e87a59e18._comment
new file mode 100644
index 0000000000..d4d681429b
--- /dev/null
+++ b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_10_87efdd2a9c7091f92a6bc96e87a59e18._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2022-04-04T16:03:06Z"
+ content="""
+Well, a change to the inode would change the CID, but what I saw back in
+comment #4 was that a change to the CID when the file content did not
+actually change, did not result in an empty commit. So I still don't
+understand how you are getting empty commits here.
+
+I also don't think all android devices do that, because such a change of
+the inode will mean it needs to re-download the file, and I do not see
+periodic re-downloads of files when syncing with my own android phone.
+"""]]
diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_11_206d98a17319292d4de4c475a7b8d091._comment b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_11_206d98a17319292d4de4c475a7b8d091._comment
new file mode 100644
index 0000000000..262ec209bb
--- /dev/null
+++ b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_11_206d98a17319292d4de4c475a7b8d091._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2023-06-21T18:20:00Z"
+ content="""
+I no longer see an empty commit in the scenario I described in comment #1.
+I'm not sure what fixed that.
+
+So this bug is blocked on more information being available, since I still
+don't know how to reproduce the empty commit problem. Marking moreinfo.
+"""]]
diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_1_522c68d019e5db592e140db9501435ba._comment b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_1_522c68d019e5db592e140db9501435ba._comment
new file mode 100644
index 0000000000..6ab85944bb
--- /dev/null
+++ b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_1_522c68d019e5db592e140db9501435ba._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-03T17:32:34Z"
+ content="""
+I guess you mean commits like "import from foo",
+or perhaps "remote tracking branch". Not adb-specific at all.
+
+The "remote tracking branch" commits are merge commits, so cannot be
+avoided, even though they don't make any apparent changes.
+
+It mostly does manage to avoid making the "import from" commits
+when there is no difference from the previous commit.
+The only case I know of where it does not is in the initial import,
+if the branch was exported first, and then imported. I see an empty 
+"import from" then. Subsequent imports, when there are no changes to the
+tree, do not make a new commit.
+
+Of course, you can rebase out any of these commits if you want to.
+"""]]
diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_2_5000af944e3a7917a97b65fb7d1c5c3e._comment b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_2_5000af944e3a7917a97b65fb7d1c5c3e._comment
new file mode 100644
index 0000000000..45e1f3c187
--- /dev/null
+++ b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_2_5000af944e3a7917a97b65fb7d1c5c3e._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="amerlyq+annex@12121d70a602f094228689a0a24d348d478a8af1"
+ nickname="amerlyq+annex"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="comment 2"
+ date="2022-01-04T13:41:03Z"
+ content="""
+> I guess you mean commits like \"import from foo\", or perhaps \"remote tracking branch\". Not adb-specific at all.
+
+Yes. 
+
+* First \"import from foo\" commit is OK, but second was empty -- and false-positive, because there were no changes on android.
+* Consequently, first \"remote tracking branch\" is OK to merge histories, but all next are empty -- and useless, because there is no changes in \"android/main\" branch.
+---
+> The \"remote tracking branch\" commits are merge commits, so cannot be avoided, even though they don't make any apparent changes.
+
+Can't we simply... don't do them? Skip? Revert? Fast-forward?
+
+I don't mind this history hell inside git-annex branch, but cluttering \"main\" branch... is something else.
+After first merge of unrelated histories -- we don't really need another merge commit unless new changes where introduced during import, do we?
+---
+> Of course, you can rebase out any of these commits if you want to.
+
+Theoretically yes, practically no. If I run \"git annex sync\" -- this history will be propagated to all my connected in that moment devices -- PC, laptop, NAS, remote VPS, and maybe HDD.
+Rebasing and cleaning up them after that -- impractical.
+
+---
+> It mostly does manage to avoid making the \"import from\" commits when there is no difference from the previous commit.
+> Subsequent imports, when there are no changes to the tree, do not make a new commit.
+
+It seems this does not work as described.
+
+You depend on CID (size, modificiation time, and inode) when doing comparisons.
+
+1) Most likely this issue is related to https://git-annex.branchable.com/bugs/adb_pull_does_not_preserve_timestamp/ ,
+that results in a different mtime on remote and on PC when you \"import\" new files.
+
+Then each time you do \"import\" -- git-annex detect changes by mtime and creates commit, but it's empty because content hadn't actually changed.
+
+2) Alternative *heisenbug* is the time skew between what android \"sdcard\" virtual filesystem reports and what it actually transfers. Probability is too low, though :)
+
+---
+P.S. I'm not sure if it's a separate bug or related to \"mtime\" too (scenario (1) or even (2)), but:
+
+* if I create a new repo and do \"export\" multiple times in a row into empty folder -- it works OK.
+* But on the next day when I'm trying to \"export\" again -- it reports error \"unsafe to overwrite file //failed\"
+
+But I had no changes in either repo or in android folder. And it worked multiple times in a row the day before!
+"""]]
diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_3_a9b3e07f180ab97f5025d7ce9ca58c05._comment b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_3_a9b3e07f180ab97f5025d7ce9ca58c05._comment
new file mode 100644
index 0000000000..6abc3c9381
--- /dev/null
+++ b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_3_a9b3e07f180ab97f5025d7ce9ca58c05._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-01-04T15:33:25Z"
+ content="""
+Please show me how to get more than one "import from foo"
+commit that is empty, starting from a new remote.
+
+I have only managed to get one, maximum, as I said.
+
+I do not thik your CID analysis is correct. The CID is
+calculated on the android side and has nothing to do with
+the timestamps of anything in the git repo.
+
+Now, if Android is varying the mtime it reports for files, so resulting in
+a changed CID, it may be that would cause an import of content it had already 
+imported before, and maybe that leads to the unnecessary commit.
+"""]]
diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_4_4e9e55d54d9afb2dbb48320156757f11._comment b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_4_4e9e55d54d9afb2dbb48320156757f11._comment
new file mode 100644
index 0000000000..6dbe5a96ec
--- /dev/null
+++ b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_4_4e9e55d54d9afb2dbb48320156757f11._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-01-05T16:32:50Z"
+ content="""
+> Now, if Android is varying the mtime it reports for files [...]
+
+I do not think this idea of mine can cause it. I tried, using a directory
+special remote, touching a file in the remote after having already imported
+it once. This resulted in git-annex sync importing the same file again, but
+since the content was the same it built the same tree it had before, and
+noticed this and avoided making an empty commit.
+
+On the merge commits, importing creates one, and exporting creates one.
+So sync creates two. Also, if you export and then merge the remote tracking
+branch (a fast-forward merge), and then export again, 
+it makes another merge commit. So any number can be stacked up that way.
+
+See [[!commit 1503b86a14865ce300ebb9c4d96315eeb254d0b8]]
+(and subsequent [[!commit 2bd0e07ed83db39907f0c824854d68c1a8ba77ac]]
+and [[!commit a32f31235a67d572d989ad9e344efe11d78774a5]] where this was
+introduced. This stuff makes my head hurt, and getting it wrong leads to
+broken merges from the remote tracking branch...
+"""]]
diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_4_d500b9ae8e3f57a2f8dcd2314c0022dd._comment b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_4_d500b9ae8e3f57a2f8dcd2314c0022dd._comment
new file mode 100644
index 0000000000..edb23a1ee5
--- /dev/null
+++ b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_4_d500b9ae8e3f57a2f8dcd2314c0022dd._comment
@@ -0,0 +1,73 @@
+[[!comment format=mdwn
+ username="amerlyq"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="comment 4"
+ date="2022-01-05T15:46:07Z"
+ content="""
+> I do not thik your CID analysis is correct.
+
+Yes, sorry, you are right. You only use \"find -exec stat\" to get remote CID.
+
+> Please show me how to get more than one \"import from foo\" commit that is empty, starting from a new remote.
+
+Hm, it really looks like *heisenbug* as I can't reproduce it stably and immediately.
+Usually issue arises after some indeterminate time had passed. 
+Dunno what action could trigger it, as all of them look unrelated and improbable: phone reboot, system reboot, cold file cache, NTP skew...
+
+When I wrap everything into the script which completes in 10 sec -- there is no problem.
+But after several days -- import creates new empty commit and export refuses to overwrite existing file.
+
+I read something kind of similar months ago: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1631854.html
+
+---
+
+Let's focus on empty \"remote tracking branch\" merge commits for now.
+At least until I find how to reproduce empty \"import from foo\" too.
+
+Can we avoid new empty merge commits if \"import\" was done first?
+
+    #!/usr/bin/env bash
+    set -o errexit -o errtrace -o noclobber -o noglob -o nounset -o pipefail
+
+    adb shell \"rm -rf /storage/0000-0000/ttt\"
+
+    cd /tmp
+    test -d ttt && find ttt -not -writable -exec chmod +w -- {} +
+    rm -rf ttt
+    mkdir ttt
+
+    cd ttt
+    git init .
+    git config --local init.defaultBranch main
+    git config --local user.name annex
+    git config --local user.email test
+
+    git annex init test
+    git annex config --set annex.largefiles 'not mimetype=text/*'
+
+    # git commit --allow-empty -m init
+    echo hello > README.rst
+    git add README.rst
+    git commit -m init
+
+    mkdir new old
+    for f in old/1 old/2 new/3 new/4; do (head -c100 /dev/zero;echo $f) > $f; done
+    git annex add
+    git commit -m annex
+
+    git annex initremote android type=adb androiddirectory=/storage/0000-0000/ttt encryption=none exporttree=yes importtree=yes
+    git config --local remote.android.annex-sync false
+
+    echo
+    git config remote.android.annex-tracking-branch main
+    for _ in {0..6}; do git annex sync --no-commit --content android; done
+
+    echo
+    find . -name .git -prune -o -xtype f -exec stat -c '%s %Y %i %n' {} +
+    echo
+    adb shell \"find /storage/0000-0000/ttt -type f -exec stat -c '%s %Y %i %n' {} +\"
+
+    echo
+    git -c color.ui=no --no-pager log --topo-order --oneline --patch --decorate --graph main
+
+"""]]
diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_6_aafa4a00a9579e54c3080586c1b7bb3e._comment b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_6_aafa4a00a9579e54c3080586c1b7bb3e._comment
new file mode 100644
index 0000000000..f5136565b2
--- /dev/null
+++ b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_6_aafa4a00a9579e54c3080586c1b7bb3e._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="amerlyq"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="comment 6"
+ date="2022-01-08T14:32:11Z"
+ content="""
+Now, if Android is varying the mtime it reports for files [...]
+
+> I tried, using a directory special remote, touching a file in the remote after having already imported it once.
+
+Hm, I think I will enable debug logging for awhile, and will try to catch more info for my heisenbug.
+It may take weeks though, so simply know that no activity in this issue does not mean I had abandoned it.
+I will explicitly state so, if it will ever be a case.
+
+> On the merge commits, importing creates one, and exporting creates one. So sync creates two.
+> Also, if you export and then merge the remote tracking branch (a fast-forward merge), and then export again, it makes another merge commit. 
+
+Yes, and I hoped for a fast and dirty fix -- check diff before merge -- and if it's empty -- don't do that useless merge commit.
+It will unblock my primary workflow to start using ADB in full, as I stop fearing to trash my history on all my remotes (as I mentioned \"rebase\" won't help due to how \"git annex sync\" works).
+But maybe on empty commits still better to print something into debug logs or in warnings -- so the original bug still could be tracked and I continued searching for root cause.
+
+> See 1503b86a14865ce300ebb9c4d96315eeb254d0b8 (and subsequent 2bd0e07ed83db39907f0c824854d68c1a8ba77ac and a32f31235a67d572d989ad9e344efe11d78774a5 where this was introduced. This stuff makes my head hurt, and getting it wrong leads to broken merges from the remote tracking branch...
+
+I skimmed through those diffs, and I may say my head huts too :)
+And I will need to look more into surrounding code to understand them in full.
+Still I will return to them again after some debug logs were collected.
+
+Until then -- is it possible to do what I mentioned above -- \"check diff before merge -- and don't merge if it's empty\" ?
+"""]]
diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_7_f1e37aa68778408629c53c09f0a0857f._comment b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_7_f1e37aa68778408629c53c09f0a0857f._comment
new file mode 100644
index 0000000000..2cfae47ff2
--- /dev/null
+++ b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_7_f1e37aa68778408629c53c09f0a0857f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="amerlyq"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="comment 7"
+ date="2022-01-29T15:59:31Z"
+ content="""
+> * if I create a new repo and do \"export\" multiple times in a row into empty folder -- it works OK.
+> * But on the next day when I'm trying to \"export\" again -- it reports error \"unsafe to overwrite file //failed\"
+
+I somewhat narrowed down the issue.
+Error \"unsafe to overwrite file\" only appears for plaint text files (and symlinks) committed to .git itself.
+This error only appears after several exports and some time passes (still can't catch conditions).
+
+Current hypothesis is that empty commits in history are related to these plain text files.
+@joey, do you have any thoughts?
+"""]]
diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_8_0a7f24a4567ff934cee37a4c0224f000._comment b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_8_0a7f24a4567ff934cee37a4c0224f000._comment
new file mode 100644
index 0000000000..55813f912f
--- /dev/null
+++ b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_8_0a7f24a4567ff934cee37a4c0224f000._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-01-31T16:26:55Z"
+ content="""
+Well that message suggests that the CID of the file appears to have
+changed. But I investigated the changed CID theory back in comment #4 and
+could not get it to produce an empty commit.
+
+The file being not annexed might be a clue.
+
+If it happens with a symlink, that would certianly be a clue. But
+git-annex avoids exporting symlinks to special remotes now, so it would be
+worth upgrading to the most recent release to avoid the old behavior with
+them.
+"""]]
diff --git a/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_9_9b4d104a7255a7618221f9dbb410fdcb._comment b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_9_9b4d104a7255a7618221f9dbb410fdcb._comment
new file mode 100644
index 0000000000..6e6382ecb6
--- /dev/null
+++ b/doc/bugs/adb_creates_empty_commits_on_import__47__sync/comment_9_9b4d104a7255a7618221f9dbb410fdcb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="amerlyq"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="Inode rotation on android /sdcard"
+ date="2022-04-02T14:00:44Z"
+ content="""
+@joey I had found out the root cause of the bug !
+CID really changes between different days.
+
+Basically, on android /sdcard internal user memory (and /storage/* mounted SDCard) are not exposed directly, but through virtual flash driver.
+And this driver REGULARLY increments inode for ALL files in FS, around once per day on average (but I spotted once per several days, and several times a day too).
+For example same file had 3 different inodes over the week: 323733 -> 338757 -> 364584 -> ... -> 426292.
+I dunno why it rotates regularly or after some events -- but truth is *inode is not reliable* as CID on android.
+
+In that case -- can we change CID for android remote to (mtime, name) only?
+"""]]
diff --git a/doc/bugs/adb_pull_does_not_preserve_timestamp.mdwn b/doc/bugs/adb_pull_does_not_preserve_timestamp.mdwn
new file mode 100644
index 0000000000..4b7e821479
--- /dev/null
+++ b/doc/bugs/adb_pull_does_not_preserve_timestamp.mdwn
@@ -0,0 +1,44 @@
+### Please describe the problem.
+Adb special remote does not preserve remote timestamp on "import".
+Therefore files downloaded several days ago lose their real mtime when transferred to PC,
+and from that moment onward files on android will have mtime different from stored in annex/symlinks.
+
+But all files already present in PC repo -- during "export" correctly propagate their mtime to android.
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+git annex initremote android type=adb androiddirectory=/storage/0000-0000/books encryption=none exporttree=yes importtree=yes
+git config remote.android.annex-sync false
+git config remote.android.annex-tracking-branch main
+git annex export main --to android
+# ADD: download some "file" through android into "books"
+git annex sync --content android
+stat -c%y "file"
+Modify: 2022-01-01 20:51:11.487603199 +0200
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 8.20211118-g23ee48898
+ArchLinux 5.15.12-arch1-1
+
+### Please provide any additional information below.
+Most likely can be fixed by:
+
+[[!format diff """
+--- i/Remote/Adb.hs
++++ w/Remote/Adb.hs
+@@ -202,6 +202,7 @@ retrieve' serial src dest =
+                showOutput -- make way for adb pull output
+                liftIO $ boolSystem "adb" $ mkAdbCommand serial
+                        [ Param "pull"
++                      , Param "-a"
+                        , File $ fromAndroidPath src
+                        , File dest
+                        ]
+"""]]
+
+### Have you had any luck using git-annex before?
+
+Nice work fixing earlier notorious bug, it made the ADB special remote usable for me at least in PC -> android direction! :)  
+[[https://git-annex.branchable.com/forum/Mixed_content_repos_with_import_and_export/#comment-764ac971faf756140055333649ffb94c]]
diff --git a/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_1_b695826d1f948249b496c055b4d745df._comment b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_1_b695826d1f948249b496c055b4d745df._comment
new file mode 100644
index 0000000000..49c8924aab
--- /dev/null
+++ b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_1_b695826d1f948249b496c055b4d745df._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-03T17:48:38Z"
+ content="""
+Git does not preserve timestamps. So this is kind of out of scope.
+
+While git-annex will sometimes preserve timestamps when it's easy to do so,
+there are no guarantees. Most special remotes do not preserve any
+timestamps in either direction.
+
+It might be that `adb pull -a` would fix this. But that also preserves
+the permissions, and pulling in random permissions for annex object files
+could lead to arbitrary breakage (imagine a suid executable for example).
+So it would need to clear the permissions. The complexity does not seem
+worth trying to support a thing that is generally out of scope.
+"""]]
diff --git a/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_2_2d49693c5f8d826f9a4b1cf2f8dca2c5._comment b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_2_2d49693c5f8d826f9a4b1cf2f8dca2c5._comment
new file mode 100644
index 0000000000..0513d95fca
--- /dev/null
+++ b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_2_2d49693c5f8d826f9a4b1cf2f8dca2c5._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="amerlyq+annex@12121d70a602f094228689a0a24d348d478a8af1"
+ nickname="amerlyq+annex"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="comment 2"
+ date="2022-01-04T12:55:14Z"
+ content="""
+> Git does not preserve timestamps. So this is kind of out of scope.
+
+Yes, git does not, but PC filesystem *does*.
+And when you annex files -- git-annex copies file own mtime to its symlink.
+Therefore you can *sort* and *seek* files based on the date of your first *acquaintance* (downloading) instead of the date of batch-sync.
+
+> pulling in random permissions for annex object files could lead to arbitrary breakage (imagine a suid executable for example). 
+> So it would need to clear the permissions.
+
+I don't see a reason to sync any native executables with Android phone for usual mediafile-centered workflow with usual /storage location.
+Moreover, suid is of no concern for years due to virtual filesystem used in Android, which simply does not support suid or exec anyway:
+
+    /data/media on /storage/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid,default_normal,reserved=20MB)
+    /mnt/media_rw/0000-0000 on /storage/0000-0000 type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,mask=6)
+
+> The complexity does not seem worth trying to support a thing that is generally out of scope.
+
+Consider next workflow:
+
+* android folder /Downloads (or even whole /emulated) is actively filled by many apps -- and used as \"source\" for git-annex
+* once a week I use \"adb import\" to move everything present in folder/android to PC and sort it on PC -- using comfortable tools 
+* usually things downloaded on the same day are somehow related to each other -- therefore sorting them much easier if presorted by date first, and then by filetype
+* some files are moved to \"archive of misc references/2022-01-XX\" -- because they are not important enough to spend time thinking about them further, but good to backtrack when needed
+* other important files are usually moved to respective contexts -- work/home/projects/leisure/etc. -- by keeping them inside their \"2022-01-XX\" folder to easily refer to other tasks I did on that day in those contexts.
+* after that some contexts (which have separate git-annex) are \"exported\" back to android to have immediate access -- e.g. filtered repos for \"leisure\", \"books\" -- which contain only most important and most recent entries.
+
+If adb does not preserve timestamps -- you lose \"date\" information, and core of the workflow crumbles to dust.
+And you can't use (name, size, mtime) as kind of UID for sync too.
+
+To support this workflow I used rsync+adbfs, but it's a pain due to  how you can't simply and efficiently rsync from phone into annex symlinks and back and be done with it.
+Moreover it's a separate different step, which could be eliminated if \"git annex sync\" properly worked with adb remote.
+"""]]
diff --git a/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_3_cf555d2f0f93248a913014f30ce513b2._comment b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_3_cf555d2f0f93248a913014f30ce513b2._comment
new file mode 100644
index 0000000000..4feb134ac8
--- /dev/null
+++ b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_3_cf555d2f0f93248a913014f30ce513b2._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-01-05T16:07:09Z"
+ content="""
+But you would have the same problem with that workflow if you were
+checking the files into a git repository not using git-annex, 
+and pulling from that repository. 
+
+For that metter, you would have the same problem with that workflow if
+you were running `git-annex add` and using `git-annex get`
+to transfer over a ssh connection.
+
+The mere fact that it might be possible to support that particular workflow
+with adb or some other type of remote does not mean that it's a bug for
+git-annex not to support it. Or that it's a good idea to complicate
+git-annex to partially support it.
+
+> And when you annex files -- git-annex copies file own mtime to its symlink
+
+That's entirely different. When you run `git add` on a file, the file's
+mtime is left unchanged. It follows that, when you `git-annex add` a file,
+the mtime of the file (now a symlink) should also be unchanged. That's
+entirely unrelated to remotes.
+"""]]
diff --git a/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_4_9d5cbd2479a07d778bacfdfe0aaaa524._comment b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_4_9d5cbd2479a07d778bacfdfe0aaaa524._comment
new file mode 100644
index 0000000000..6fc38031b2
--- /dev/null
+++ b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_4_9d5cbd2479a07d778bacfdfe0aaaa524._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="amerlyq"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="comment 4"
+ date="2022-01-07T12:52:35Z"
+ content="""
+Basical consclusion is: you won't ever add \"pull -a\" (despite android's \"nosuid noexec\"), correct ?
+"""]]
diff --git a/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_5_244a5803178b4e44f3ec4460c5daf258._comment b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_5_244a5803178b4e44f3ec4460c5daf258._comment
new file mode 100644
index 0000000000..38f5cf2239
--- /dev/null
+++ b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_5_244a5803178b4e44f3ec4460c5daf258._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-01-07T16:06:52Z"
+ content="""
+This bug report is still open because I am still open to being argued out
+of my current position. But such an argument would have to engage with the
+things I discussed.
+"""]]
diff --git a/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_6_77416807482416c552922d39a0319a65._comment b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_6_77416807482416c552922d39a0319a65._comment
new file mode 100644
index 0000000000..152645c26d
--- /dev/null
+++ b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_6_77416807482416c552922d39a0319a65._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="amerlyq"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="comment 6"
+ date="2022-01-08T14:15:55Z"
+ content="""
+> open to being argued out of my current position
+
+Ok, let's continue :)
+
+> same problem:
+
+> * checking the files into a git repository not using git-annex, and pulling from that repository.
+
+> * running git-annex add and using git-annex get to transfer over a ssh connection.
+
+> * [not supporting] workflow with adb or some other type of remote [is not a bug]
+
+I distinguish ADB from all other types of remotes -- because it's the actual *source* of new files -- not yet processed by user manually.
+And what you mentioned above -- are scenarios occuring on full-fledged work system, not on half-baked android phone.
+
+When you sync Laptop with PC -- you must add files either on Laptop or on PC into git-annex first.
+Therefore you have an opportunity to do something with files first e.g. sort them into the folders by date,
+before adding them into git and losing that mtime information (which at that point is still useful, but not necessary).
+
+When you sync PC with any \"backup\" remote -- they are pushed/pulled *after* files were added to git-annex.
+I.e. none of them adds new files, which user never seen before -- and process only \"existing\" ones.
+
+But when you use ADB (or maybe Directory too -- however I still don't have a usecase for that) -- new files are added to ADB
+directly, avoiding user intervention. Because it's a pain to sort them on the phone immeditely without proper tools and scripts.
+And one of the purposes of using git-annex here -- is to fetch them to PC to sort properly on big screen.
+But fetching them without \"pull -a\" looses the necessary information.
+It's not that big of a problem for DCIM folder, as files contain dates in filenames, but it's an issue for Downloads (and separate folders of each chat app).
+
+Therefore yes, ADB is different, it's involved into different workflow, and therefore deserves different treatment.
+
+---
+
+> when you git-annex add a file, the mtime of the file (now a symlink) should also be unchanged
+Ok, that's a different original reason. Agreed.
+
+Still, it has a nice consequence of preserving mtime for files already present on PC.
+
+And it allows me to scan whole filesystem and dump metadata into a separate file (e.g. \"find -printf \"%T@ %P\n\"),
+to preserve the information \"when I first seen/downloaded that file\" for the future.
+
+And it's very important information (at least for me), because it's easier to remember and link related things occuring in a similar timespan,
+than to sort files by types and then fruitlessly trying to link those fragmented and sparse datasets inside my head after several months or years.
+"""]]
diff --git a/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_7_216316d2db3a728837fd059587ad1928._comment b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_7_216316d2db3a728837fd059587ad1928._comment
new file mode 100644
index 0000000000..1158315375
--- /dev/null
+++ b/doc/bugs/adb_pull_does_not_preserve_timestamp/comment_7_216316d2db3a728837fd059587ad1928._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="amerlyq"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="TL;DR"
+ date="2022-04-02T14:13:48Z"
+ content="""
+@joey can we change android remote to use \"pull -a\" at least \"for now\"?
+
+Let's try doing it in Linux Kernel or ZeroMQ way: enable/disable feature and wait for new bugreports.
+And if new bugreports were critical -- revert feature back.
+After all we can't predict everything from the get go.
+
+I wish to preserve file original mtime (date of download) at least \"somewhere\" (e.g. manually dump find/CID into textual file).
+But doing \"annex pull\" from android remote loses this information completely.
+And this feature is critical for me -- unless some evidence will appear that having this feature more detrimental than not.
+
+Concerns about SUID and other permissions are ungrounded, 
+because Android virtual driver for /sdcard uses only 644/755 by design.
+But instead of speculating -- we may simply wait for new bugreports.
+
+@joey, what do you say? 
+Let's experiment and gather results from wider audience?
+"""]]
diff --git a/doc/bugs/adb_remote_fails_to_import_treeish.mdwn b/doc/bugs/adb_remote_fails_to_import_treeish.mdwn
new file mode 100644
index 0000000000..d53bd900d9
--- /dev/null
+++ b/doc/bugs/adb_remote_fails_to_import_treeish.mdwn
@@ -0,0 +1,75 @@
+### Please describe the problem.
+i have an adb remote setup to import and export treeishes.  Recently when I tried to import from my adb remote i was met with the follwing error
+
+    commit
+    On branch master
+    Your branch is ahead of 'seagate5tb/master' by 14 commits.
+      (use "git push" to publish your local commits)
+
+    nothing to commit, working tree clean
+    ok
+    list motoE5 find: bad arg '-printf'
+    See stat --help
+    stat: Needs 1 argument
+
+    git-annex: Unable to list contents of motoE5: adb find failed
+    failed
+
+### What steps will reproduce the problem?
+* setup an adb special remote, enabling importtreeish and exporttreeish
+* use the command "git annex sync --content -remoteName-
+* it should fail with the above mentioned error
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20220504-g4e4c44ed8
+
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.11 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+
+operating system: linux x86_64
+
+supported repository versions: 8 9 10
+
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+
+local repository version: 8
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+git annex sync --content motoE5                                                                                                                                                                                130 ↵ ──(Mon,Jul11)─┘
+commit
+On branch master
+Your branch is ahead of 'seagate5tb/master' by 14 commits.
+  (use "git push" to publish your local commits)
+
+nothing to commit, working tree clean
+ok
+list motoE5 find: bad arg '-printf'
+See stat --help
+stat: Needs 1 argument
+
+git-annex: Unable to list contents of motoE5: adb find failed
+failed
+
+# End of transcript or log.
+"""]]
+after it fails, i use ctrl-c to break out of the command in fear of it messing up the current state of the tree that is exported to my android device
+
+also it appears that someone else is having this issue as well, but they posted it in the comment section of the adb remote tutorial page instead of filing a bug report
+
+http://git-annex.branchable.com/tips/android_sync_with_adb/#comment-88511cef6861a2ab4d2da8b38d52dd64
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+git annex has been great so far, aside from some pitfalls on some of the more advanced features, i have been using it to manage my files using all kinds of special and non special remotes very solidly for 2 years now.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/adb_remote_fails_to_import_treeish/comment_1_8012368012cf53e8552d7670b9b8315d._comment b/doc/bugs/adb_remote_fails_to_import_treeish/comment_1_8012368012cf53e8552d7670b9b8315d._comment
new file mode 100644
index 0000000000..5349e2e511
--- /dev/null
+++ b/doc/bugs/adb_remote_fails_to_import_treeish/comment_1_8012368012cf53e8552d7670b9b8315d._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-07-12T16:15:59Z"
+ content="""
+How unfortunate that Android on your phone does not support `find -printf`.
+What version of Android is that? I've tested a few and they do support it.
+
+Reverting [[!commit a32ff6cef03ceb695af7bc6415ae7eaac06d3443]] would
+certainly avoid this problem. But that commit did solve a bug in supporting
+large numbers of files.
+
+Android's find is (probably) from toybox, and looking at its changelog, 
+`find -printf` was added in May 2019, version 0.8.1. So versions of Android
+before 2020 or so will probably have too old a version.
+
+Maybe git-annex should have an option for older versions of android that
+falls back to using `find -exec stat {} ;`. That would be a lot slower,
+since it would run stat once per file, but it would work. Or it could
+fall back to the old `find +` behavior that is limited to a certain number
+of files. Or, it could consume the `find` output, segment it into groups of
+files itself, and run `adb stat` on each group. Which would be somewhat
+slower than using xargs, and potentially hard to get right.
+"""]]
diff --git a/doc/bugs/adb_remote_fails_to_import_treeish/comment_2_54867d63c04ee18c76b1d769db71bc00._comment b/doc/bugs/adb_remote_fails_to_import_treeish/comment_2_54867d63c04ee18c76b1d769db71bc00._comment
new file mode 100644
index 0000000000..d532e9a53f
--- /dev/null
+++ b/doc/bugs/adb_remote_fails_to_import_treeish/comment_2_54867d63c04ee18c76b1d769db71bc00._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jenkin.schibel@286264d9ceb79998aecff0d5d1a4ffe34f8b8421"
+ nickname="jenkin.schibel"
+ avatar="http://cdn.libravatar.org/avatar/692d82fb5c42fc86d97cc44ae0fb61ca"
+ subject="phone version"
+ date="2022-07-12T18:37:16Z"
+ content="""
+to answer your question about what kind of phone i have, i have a 2018 motorola MotoE5.  So if what you say is true about the phone possibly being too old, this phone does fit that criteria.  I think it would be beneficial to add a configuration option for the adb remote to support older android phones.
+"""]]
diff --git a/doc/bugs/adb_remote_fails_to_import_treeish/comment_3_5e819d0b5f3101e86f0f95a7ab725ad4._comment b/doc/bugs/adb_remote_fails_to_import_treeish/comment_3_5e819d0b5f3101e86f0f95a7ab725ad4._comment
new file mode 100644
index 0000000000..242fa0a53b
--- /dev/null
+++ b/doc/bugs/adb_remote_fails_to_import_treeish/comment_3_5e819d0b5f3101e86f0f95a7ab725ad4._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-07-13T19:18:13Z"
+ content="""
+Ok, I've added an oldandroid=yes configuration to fix this. To enable it:
+
+	git-annex enableremote android oldandroid=yes
+
+(Replace "android" with whatever name you used for the adb remote.)
+
+I don't much like this, but it's better than git-annex being slow with new
+phones, and being slow with old phones is better than failing when there are
+too many files to import. I did consider trying to auto-probe it from the
+error message, but that seemed likely to be too fragile.
+"""]]
diff --git a/doc/bugs/adb_replaces_symlinks_by_plain_text_files.mdwn b/doc/bugs/adb_replaces_symlinks_by_plain_text_files.mdwn
new file mode 100644
index 0000000000..5e663589fb
--- /dev/null
+++ b/doc/bugs/adb_replaces_symlinks_by_plain_text_files.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+Using adb special remote import/export corrupts all symlinks in main repo (by replacing them by plain text files).
+
+### What steps will reproduce the problem?
+Primary annex repo contains an absolute symlink to another annex repo (or whatever).
+Exporting it through adb replaces it by plain text file (as android FS abstraction does not support symlinks).
+Importing from adb copies that plain text file and deletes symlink already present in the repo,
+treating it as a new file modified by user.
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 8.20211118-g23ee48898
+
+
+### Please provide any additional information below.
+
+Possible solutions:
+
+1) if PC repo contains symlink -- continue to export it as a plain text file (less changes).
+But on "import" compare its size with symlink size, and then compare content.
+Don't do anything if they are the same. 
+Cavet: user won't be able to *intentionally* replace symlinks by plain files on remote. Too esoteric usecase to consider.
+
+2) resolve symlink on PC and export actual file to android (probably most preferred workflow?).
+But on "import" compare its size against followed symlink file size, and then its content.
+Don't do anything if they are the same. 
+Replace symlink by actual file if they differ.
+
+[[!meta title="export then import replaces non-annex symlinks by plain text files"]]
+
+> [[fixed|done]] by skipping syminks. --[[Joey]]
diff --git a/doc/bugs/adb_replaces_symlinks_by_plain_text_files/comment_1_bcc12b77c5069769ab04e448b23b3d85._comment b/doc/bugs/adb_replaces_symlinks_by_plain_text_files/comment_1_bcc12b77c5069769ab04e448b23b3d85._comment
new file mode 100644
index 0000000000..cd422c2272
--- /dev/null
+++ b/doc/bugs/adb_replaces_symlinks_by_plain_text_files/comment_1_bcc12b77c5069769ab04e448b23b3d85._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-03T17:27:03Z"
+ content="""
+This is not adb specific. No special remotes support preserving symlinks
+(except for git-annex object links). Reproduced using a directory special
+remote.
+
+Probably export/import should somehow skip symlinks.
+"""]]
diff --git a/doc/bugs/adb_replaces_symlinks_by_plain_text_files/comment_2_f5db61aa7efb7a916d0ffebd563cc2c7._comment b/doc/bugs/adb_replaces_symlinks_by_plain_text_files/comment_2_f5db61aa7efb7a916d0ffebd563cc2c7._comment
new file mode 100644
index 0000000000..d042b41f10
--- /dev/null
+++ b/doc/bugs/adb_replaces_symlinks_by_plain_text_files/comment_2_f5db61aa7efb7a916d0ffebd563cc2c7._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="amerlyq+annex@12121d70a602f094228689a0a24d348d478a8af1"
+ nickname="amerlyq+annex"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="comment 2"
+ date="2022-01-04T13:10:13Z"
+ content="""
+Probably skipping symlinks for both import/export is for the best.
+
+My personal expectations (pipe dream?) are to export symlinks as real files -- but only compare during import and warn if different.
+
+Because if I see file/symlink in some repo -- it's placed there for a reason, and after sync I expect to find all the expected files in their folders (even if through multiple copies). 
+Silently ignoring of symlinks forces me to remember to check that whatever I want to sync does not contain them.
+Otherwise I may be in a very delicate situation, if files needed for work were not synced to phone and I have no access to PC at that moment ;)
+
+On the other hand, I remember literally months I spent debugging and configuring samba, and reading their history of symlinks implementations.
+It contains so much frustrating corner cases, that banning symlinks completely isn't a bad idea, actually.
+"""]]
diff --git a/doc/bugs/adb_replaces_symlinks_by_plain_text_files/comment_3_7346adcffb3d9056dc880dcf1e2ab03f._comment b/doc/bugs/adb_replaces_symlinks_by_plain_text_files/comment_3_7346adcffb3d9056dc880dcf1e2ab03f._comment
new file mode 100644
index 0000000000..c1f930d9d1
--- /dev/null
+++ b/doc/bugs/adb_replaces_symlinks_by_plain_text_files/comment_3_7346adcffb3d9056dc880dcf1e2ab03f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-01-04T15:24:33Z"
+ content="""
+The only special remotes that could probably even support symlinks
+in theory are adb and directory, and those only sometimes.
+
+Supporting them would complicate the special remote API, and I feel
+unncessarily so.
+"""]]
diff --git a/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files.mdwn b/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files.mdwn
new file mode 100644
index 0000000000..884ca9e783
--- /dev/null
+++ b/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files.mdwn
@@ -0,0 +1,21 @@
+### Please describe the problem.
+I added an adb special remote (to a fresh repo) with androiddirectory=/storage/self/primary/DCIM and while importing fetches all the files from the device, they are not all added to the repo. For example, all the thumbnail files seem to be stored, but of the 9 mp4 files in DCIM/Camera fetched, only 1 is stored.
+
+While git-annex does mention that "there was an error fetching files, rerun to resume", there is no error output anywhere I could see (e.g. with --debug). All the file fetches are shown as "OK".
+
+Making the special remote with androiddirectory=/storage/self/primary/DCIM/Camera instead, results in the 9 files being fetched and stored as expected.
+
+### What steps will reproduce the problem?
+    git init android
+    git annex init mycomputer
+    git annex initremote int_dcim type=adb androiddirectory=/storage/self/primary/DCIM encryption=none exporttree=yes importtree=yes
+    git annex import --from int_dcim master:somedir
+
+### What version of git-annex are you using? On what operating system?
+* git-annex version: 7.20190503-g4da50456a3
+* Operating System: Arch Linux
+
+### Have you had any luck using git-annex before?
+(in a gamedev IRC channel, discussing my use of git-annex)
+
+    > Oh, I know. it is difficult to not notice how much you fangirl over it :p
diff --git a/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_1_31142cacafa0c975cd33a76c22f60bf3._comment b/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_1_31142cacafa0c975cd33a76c22f60bf3._comment
new file mode 100644
index 0000000000..acc84d41fb
--- /dev/null
+++ b/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_1_31142cacafa0c975cd33a76c22f60bf3._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-05-23T17:21:53Z"
+ content="""
+"Failed to import some files from remotename. Re-run command to resume import."
+
+AFAICS if it displayed that, it would not go on to add *any* files
+to the remote's tracking branch. Only when it's been able to import all
+the files it found on the remote does a commit get made.
+
+I have seen the adb pull of a file fail once or twice (out of several
+hundred imports so far), and adb did display an error message, and I
+assume git-annex also then said the import of that file failed.
+
+The other way it could fail to download a file is if the content seems to
+have changed since file list for the import was built. In that case,
+there would be no error message, just "import foo failed" rather than 
+"import foo ok"
+
+Can you paste a transcript of the problem?
+"""]]
diff --git a/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_2_09f5982e930a04c25ea3ce8caac449c4._comment b/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_2_09f5982e930a04c25ea3ce8caac449c4._comment
new file mode 100644
index 0000000000..f641b9e21d
--- /dev/null
+++ b/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_2_09f5982e930a04c25ea3ce8caac449c4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="jksrecko"
+ avatar="http://cdn.libravatar.org/avatar/5b4ec0230521d006e2ece44fe1d9800b"
+ subject="comment 2"
+ date="2020-03-15T09:13:27Z"
+ content="""
+I'm facing a same issue and it persists (tried to sync a couple of times) for one of my adb remotes (DCIM on SD card, i.e. /storage/[vol_id]/DCIM and wanted expression which excludes thumbs and .emptyshow file).
+
+I get \"Failed to import some files from [remotename]. Re-run command to resume import.\" message and no files are imported. Same as for the reporter of the issue, I get that all the files are pulled ok.
+
+I'm using the latest version of git annex (8.20200309-ga9d56a1ab).
+
+"""]]
diff --git a/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_3_3b4100037ee9180346ffc2240a34064e._comment b/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_3_3b4100037ee9180346ffc2240a34064e._comment
new file mode 100644
index 0000000000..5d56f4b61d
--- /dev/null
+++ b/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_3_3b4100037ee9180346ffc2240a34064e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="jksrecko"
+ avatar="http://cdn.libravatar.org/avatar/5b4ec0230521d006e2ece44fe1d9800b"
+ subject="comment 3"
+ date="2020-03-15T09:54:00Z"
+ content="""
+I forgot to mention that I also get:
+
+\"Not updating export to [remote] to reflect changes to the tree, because export tracking is not enabled.  (Set remote.[remotename].annex-tracking-branch to enable it.)\"
+
+But I have this set. Maybe I get it because there was no successful sync yet?
+"""]]
diff --git a/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles.mdwn b/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles.mdwn
new file mode 100644
index 0000000000..353fbdd1dd
--- /dev/null
+++ b/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles.mdwn
@@ -0,0 +1,103 @@
+This is an upstream resubmission of [Debian bug #959506](https://bugs.debian.org/959506).
+
+### Please describe the problem.
+
+As of v8, git-annex divides files into “large” and “non-large” files, the
+former of which are supposed to be automatically added to the annex and the
+latter to vanilla git when running `git annex add`. git-annex uses the
+configuration option `annex.largefiles`, a file matching expression, to
+categorize files as “large”; all other files end up as “non-large”.
+
+Furthermore, git-annex always treats “dotfiles” as “non-large”, without
+consulting `annex.largefiles`. Setting the configuration option
+`annex.dotfiles` (false by default) makes git-annex use `annex.largefiles`
+to also categorize “dotfiles”.
+
+The manual never defines which files are considered “dotfiles”, therefore
+I am assuming a definition of “a dotfile is a non-directory file whose
+basename begins with an ASCII period”. git-annex however will treat any file
+in any directory as a dotfile – i.e., it will ignore `annex.largefiles` and
+always add the file to vanilla git, unless `annex.dotfiles` is set to true
+– as long as the relative pathname to the file begins with an ASCII period,
+e.g. `.foo/bar.txt` (which is *not* a dotfile according to the assumed
+definition above). git-annex will further cease treating the same file as
+a dotfile if the relative pathname no longer begins with an ASCII period,
+e.g. because the working directory has been changed.
+
+I expect git-annex to distinguish between dotfiles and non-dotfiles solely
+by looking at the file's basename, even if the relative path to the file
+begins with a dot. I also expect `annex.dotfiles` to have no influence
+whatsoever on files whose basename doesn't begin with an ASCII period, even
+if the containing directory does. git-annex's *actual* behavior is highly
+counter-intuitive to the notion that being a dotfile is a property of the
+file's (base-)name. Due to the lack of definition of dotfiles in the manual,
+it is unclear to me whether this is intended (but in my opinion quirky)
+behavior, or rather a bug.
+
+### What steps will reproduce the problem?
+
+1.  Set up a repository for use with git-annex. Leave `annex.dotfiles` at
+    its default value (`false`), and `annex.largefiles` unset.
+
+2.  Create files `bar1`, `bar2` and `bar3` within a directory `.foo`. What
+    matters is that `.foo` begins with a period, `bar1` etc. don't.
+
+3.  Run `git annex add .foo/bar1`. git-annex will have forced the file into
+    vanilla git as a “non-large” file, because it is recognized as
+    a “dotfile”. But `bar1` is not a dotfile because it does not begin with
+    a period.
+
+4.  (Optional.) Set `annex.dotfiles` to `true` and run `git annex add
+    .foo/bar2`. The file is added to the annex. In conjunction with step 3,
+    this shows that git-annex really does apply the `annex.dotfiles` setting
+    to files such as `.foo/bar2`, even if they aren't “dotfiles” because the
+    file basenames don't start with a period.
+
+5.  (Optional.) Set `annex.dotfiles` back to false, change directory to
+    `.foo`, then run `git annex add bar3`. The file will be added to the
+    annex, as it is no longer recognized as a dotfile. This shows that
+    git-annex's behavior is inconsistent: the same file is either seen as
+    a dotfile or not, depending on which directory git-annex is run from and
+    what the resulting relative pathnames look like.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex v8.20200330, on Debian sid, as of 2020-05-08
+
+### Please provide any additional information below.
+
+[[!format sh """
+$ cd /tmp/git-annex-dotfiles
+$ git init
+Initialized empty Git repository in /tmp/git-annex-dotfiles/.git/
+$ git annex init
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
+$ mkdir .foo
+$ echo a > .foo/bar1
+$ echo b > .foo/bar2
+$ echo c > .foo/bar3
+$ git annex add .foo/bar1   # I expect this to be added to the annex, but no
+add .foo/bar1 (non-large file; adding content to git repository) ok
+(recording state in git...)
+$ git config annex.dotfiles true
+$ git annex add .foo/bar2   # clearly affected by annex.dotfiles
+add .foo/bar2
+ok
+(recording state in git...)
+$ git config annex.dotfiles false
+$ cd .foo
+$ git annex add bar3        # clearly affected by the exact relative pathname
+add bar3
+ok
+(recording state in git...)
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes. git-annex has been in use on my end for a couple of years, and it is my
+go-to solution for “want something versioned, but can't store the
+contents themselves (too big, too sensitive, etc.)?”. Furthermore, git-annex
+documentation in general is excellent. But that is also why I'm stumped that
+the manual is so silent on this point.
diff --git a/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_1_263bfea4cae5a612de1761b3c3fc32b8._comment b/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_1_263bfea4cae5a612de1761b3c3fc32b8._comment
new file mode 100644
index 0000000000..7d6dcfd31f
--- /dev/null
+++ b/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_1_263bfea4cae5a612de1761b3c3fc32b8._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-11T16:31:58Z"
+ content="""
+I think it's quite likely that most people consider files in dotdirs to be
+dotfiles, most of the time. (.git/index is clearly not a dotfile,
+.git/config probably is) The exact semantics of it are vague enough that
+it's probably better to not consider them when it comes to this bug report.
+
+The actual bug is not about whether .foo/bar is a dotfile, but about
+inconsistent behavior adding it.
+
+Avoiding treating them as dotfiles, even if they're broadly understood as
+such would resolve the inconsistency.
+
+Otoh, the inconsistency only arises when run inside a dot directory,
+which is probably a fairly rare thing to do.
+"""]]
diff --git a/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_2_6fbd20761f9388c04fa13b38af2354d9._comment b/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_2_6fbd20761f9388c04fa13b38af2354d9._comment
new file mode 100644
index 0000000000..c7cb0f845f
--- /dev/null
+++ b/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_2_6fbd20761f9388c04fa13b38af2354d9._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-05-11T16:40:46Z"
+ content="""
+I'm also reluctant to start another behavior change in this area, there has
+been more than enough drama around dotfile handling recently.
+
+At least the behavior change would only result in small files that users
+want to store in git being annexed, rather than large files being
+unexpectedly put in git.
+
+It would also be possible for users to get back the current behavior if
+desired by configuring annex.dotfiles and annex.largefiles.
+
+Also as far as the priority of this goes, I think that the number of
+dotdirs that contain files that get version controlled at all is probably
+quite small, excluding version controlling of HOME.
+"""]]
diff --git a/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_3_e8636243a3c98b11e54b6fa8617f9e32._comment b/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_3_e8636243a3c98b11e54b6fa8617f9e32._comment
new file mode 100644
index 0000000000..ebc1097f34
--- /dev/null
+++ b/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_3_e8636243a3c98b11e54b6fa8617f9e32._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="the13thletter"
+ avatar="http://cdn.libravatar.org/avatar/596520d6cdaa0709ae4413665b10ec7c"
+ subject="comment 3"
+ date="2020-06-02T14:26:52Z"
+ content="""
+OP here. Sorry for the radio silence.
+
+> I think it's quite likely that most people consider files in dotdirs to be dotfiles, most of the time. (.git/index is clearly not a dotfile, .git/config probably is) **The exact semantics of it are vague enough** that it's probably better to not consider them when it comes to this bug report.
+>
+> [...]
+>
+> I'm also reluctant to start another behavior change in this area, there has been more than enough drama around dotfile handling recently.
+>
+> [...]
+>
+> It would also be possible for users to get back the current behavior if desired by configuring annex.dotfiles and annex.largefiles.
+
+(Emphasis mine.) Given the points above, which I agree with (1) or accept (2 and 3), I'm perfectly fine with documenting the current behavior as correct and leaving it at that. My confusion stems from the fact that when I see `.foo/bar`, I say “no dotfile, because the file is actually named ‘bar’”, and git-annex says “dotfile, because the pathname expression begins with a dot” (or something like that) instead. Stating the exact rules git-annex uses to classify dotfiles as such, ideally alongside the documentation for `annex.dotfiles` and `annex.largefiles`, would avoid this confusion.
+"""]]
diff --git a/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_4_27bf6cfce4f73a1d29a753e33c1e871a._comment b/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_4_27bf6cfce4f73a1d29a753e33c1e871a._comment
new file mode 100644
index 0000000000..f68cfea1b0
--- /dev/null
+++ b/doc/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/comment_4_27bf6cfce4f73a1d29a753e33c1e871a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="lell"
+ avatar="http://cdn.libravatar.org/avatar/4c4138a71d069e290240a3a12367fabe"
+ subject="comment 4"
+ date="2022-04-15T12:05:19Z"
+ content="""
+> Also as far as the priority of this goes, I think that the number of dotdirs that
+> contain files that get version controlled at all is probably quite small, excluding
+> version controlling of HOME.
+
+I think this assessment changes with the advent of containers. I use git-annex to version-control a research computation which runs inside a container. The folder is mounted as the home directory in that container, so python modules, self-compiled software etc. go into .local, configuration of tools goes into .config, etc. All of these are not annexed but inflate the repository size and might lead to inadverent sharing of information. It makes git-annexes behaviour difficult to explain to others with this exception of dotfile handling. Why can't git-annex just handle the `.git` folder differently and for all others just annex or not as set in the largefile rules?
+"""]]
diff --git a/doc/bugs/add_config_var_preventing_adjusted_branch_mode.mdwn b/doc/bugs/add_config_var_preventing_adjusted_branch_mode.mdwn
new file mode 100644
index 0000000000..e80df84e82
--- /dev/null
+++ b/doc/bugs/add_config_var_preventing_adjusted_branch_mode.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+
+Somewhat too late for our current usecase since older git-annex would not know about it, but I think could be generalized into adding a configuration variable right away for **any** automated migration. E.g. there is no variable to prevent autoupgrades of the repos (e.g. from v5 to the next one etc), but AFAIK there is none for automated conversion" into `adjusted/master(unlocked)` mode.  
+
+Rationale: With thaw/freeze commands we now can use git-annex in indirect (default) mode on our HPC. But that requires a recent version of git-annex.  User might have some other (older) version of git-annex available system-wide by default, and if the user forgets to switch to new version of git-annex before using it, it might trigger git-annex to realize that it operates on crippled FS, and since not knowing about thaw/freeze -- it just migrates repository to adjusted, which is very undesired. 
+
+
+### What steps will reproduce the problem?
+
+here is a demo of older git-annex going back to adjusted branch mode... yet to discover how else we could have migrated without directly invoking `git annex init`:
+
+```
+[d31548v@discovery7 d31548v]$ mkdir repo
+[d31548v@discovery7 d31548v]$ cd repo
+[d31548v@discovery7 repo]$ git init
+Initialized empty Git repository in /dartfs/rc/lab/D/DBIC/DBIC/d31548v/repo/.git/
+[d31548v@discovery7 repo]$ git config --add annex.thawcontent-command "$HOME/bin-annex/thaw-content %path"
+[d31548v@discovery7 repo]$ git config --add annex.freezecontent-command "$HOME/bin-annex/freeze-content %path"
+[d31548v@discovery7 repo]$ git annex init
+init  ok
+(recording state in git...)
+[d31548v@discovery7 repo]$ echo 123 > 123
+[d31548v@discovery7 repo]$ git annex add 123
+add 123 
+ok                                
+(recording state in git...)
+git comm[d31548v@discovery7 repo]$ git commit -m 'added 123 in indirect mode' 123
+[master (root-commit) 3ceb200] added 123 in indirect mode
+ 1 file changed, 1 insertion(+)
+ create mode 120000 123
+[d31548v@discovery7 repo]$ ls -ld 123
+lrwxr-x--- 1 d31548v rc-DBIC 178 May  6 11:19 123 -> .git/annex/objects/G6/qW/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+[d31548v@discovery7 repo]$ ls -l .git/annex/objects
+total 3
+drwxr-x--- 3 d31548v rc-DBIC 20 May  6 11:19 G6
+[d31548v@discovery7 repo]$ export PATH=/opt/bin:$PATH
+[d31548v@discovery7 repo]$ git annex version | head -n 1
+git-annex version: 8.20200502-g55acb2e52
+[d31548v@discovery7 repo]$ git annex drop 123
+drop 123 
+git-annex: failed to lock content: .git/annex/objects/G6/qW/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b: openFd: permission denied (Permission denied)
+failed
+git-annex: drop: 1 failed
+[d31548v@discovery7 repo]$ git annex init
+init  
+  Filesystem allows writing to files whose write bit is not set.
+
+  Detected a crippled filesystem.
+
+  Disabling core.symlinks.
+(scanning for unlocked files...)
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Switched to branch 'adjusted/master(unlocked)'
+ok
+```
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[notabug|done]] per comments --[[Joey]]
diff --git a/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_1_d7ca1f4ccb4bc8a72788f6dcf8af9439._comment b/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_1_d7ca1f4ccb4bc8a72788f6dcf8af9439._comment
new file mode 100644
index 0000000000..81edca7bea
--- /dev/null
+++ b/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_1_d7ca1f4ccb4bc8a72788f6dcf8af9439._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-09T15:00:47Z"
+ content="""
+git-annex does not enter adjusted branch mode except on `git-annex
+init` or when you explcitly tell it to. The only exception to this that I
+can find is that upgrading from a v5 repository that was in direct mode
+will enter an adjusted branch.
+
+Switching back from an adjusted branch to master is a simple `git
+checkout`.
+
+These two facts do not argue for a separate config setting IMHO.
+"""]]
diff --git a/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_2_0c064717d0b85ff4b9df1bada7c6e7ad._comment b/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_2_0c064717d0b85ff4b9df1bada7c6e7ad._comment
new file mode 100644
index 0000000000..6010c0a569
--- /dev/null
+++ b/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_2_0c064717d0b85ff4b9df1bada7c6e7ad._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-05-09T15:13:39Z"
+ content="""
+It might be worth preventing `git-annex init` when in an existing, already
+initalized repo from entering an adjusted branch. But re-running `git-annex
+init` generally re-does initialization, except for generating a new UUID
+and description. If a repo has been moved to a crippled filesystem,
+I think it would be reasonable for a user to expect re-running git-annex
+init will react to that. (Which can also involve setting annex.pidlock or
+disabling annex.sshcaching.)
+"""]]
diff --git a/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_3_1f4b1f2a32f11da4c9bba95f25dd45c1._comment b/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_3_1f4b1f2a32f11da4c9bba95f25dd45c1._comment
new file mode 100644
index 0000000000..97fde9c374
--- /dev/null
+++ b/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_3_1f4b1f2a32f11da4c9bba95f25dd45c1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2023-02-17T21:50:19Z"
+ content="""
+here my \"concern\" was freeze/thawing procedure. I am yet to get to the bottom of \"variance\" of how differently different ACL paths behave (some exploration from this friday is [here](https://github.com/dbic/handbook/issues/20)). And what I am afraid is that at some point, something would \"trigger\" git-annex to decide that path here is crippled now -- go to adjusted branches mode. If you say it cannot happen, it is ok - I will become more brave ;-)
+"""]]
diff --git a/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_4_0fb992fe4ef5ec14876d2d1912dca4c5._comment b/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_4_0fb992fe4ef5ec14876d2d1912dca4c5._comment
new file mode 100644
index 0000000000..24a838f338
--- /dev/null
+++ b/doc/bugs/add_config_var_preventing_adjusted_branch_mode/comment_4_0fb992fe4ef5ec14876d2d1912dca4c5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-02-20T18:40:00Z"
+ content="""
+Well, if you unset annex.version, it will automatically reinitialize, and
+would enter an adjusted branch if a crippled filesystem was detected.
+
+That's the only way I can see that does not involve you running
+`git-annex init` (or upgrade from v5 direct mode as mentioned earlier).
+"""]]
diff --git a/doc/bugs/add_overwrite_race.mdwn b/doc/bugs/add_overwrite_race.mdwn
new file mode 100644
index 0000000000..65f695d69f
--- /dev/null
+++ b/doc/bugs/add_overwrite_race.mdwn
@@ -0,0 +1,59 @@
+I was running `git-annex add` on 5 gb of files, and accidentially overwrote
+some of the first ones, which it had already processed, while it was
+running. This caused binary files to get staged in git, rather than the
+annex pointers. 
+
+Test case: 
+
+	echo hi > 1
+	dd if=/dev/urandom of=2 bs=1M count=1000
+	(sleep 2s; rm 1; echo bye > 1) &
+	git-annex add
+	git diff --cached 1
+	diff --git a/1 b/1
+	new file mode 100644
+	index 0000000..b023018
+	--- /dev/null
+	+++ b/1
+	@@ -0,0 +1 @@
+	+bye
+
+This happens due to ingestAdd using addLink on the symlink, 
+which just queues a "git add" of the file for later. In the
+meantime, the symlink is replaced with something else, so git
+adds that.
+
+It seems that the solution will be to use update-index rather than git add.
+Note that addLink has a comment about why it uses git add, which seems to mostly
+be that it's faster. It also sometimes relies on git add to check gitignore,
+although sometimes redundandly, some of the callers of it may rely on that
+and have to be changed to check it first themselves.
+
+Since adding a file to the annex also involves locking it down and
+detecting modifications made while generating the key, update-index is
+sufficient.
+
+> Update: This is fixed.
+
+When it's adding a file unlocked, it already stages the pointer file using
+update-index instead so there is no overwrite problem there.
+
+But, there's a similar problem when it decides not to annex a file
+and adds it to git. If the file content is overwritten then, it will
+git add the new content. Which may be large enough that it should have been
+added to the annex after all. Test case for this:
+
+	git config annex.largefiles largerthan=3b
+	echo hi > 1
+	dd if=/dev/urandom of=2 bs=1M count=1000
+	(sleep 2s; rm 1; echo bye > 1) &
+	git-annex add
+	git diff --cached 1
+
+Guess it needs to cache the inode,
+hash the file content, then verifiy the inode did not change during
+hashing, and then also use update-index.
+
+> [[done]]
+
+--[[Joey]]
diff --git a/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow.mdwn b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow.mdwn
new file mode 100644
index 0000000000..95751527b3
--- /dev/null
+++ b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow.mdwn
@@ -0,0 +1,87 @@
+Creating additional branches in history seems to slow down the 'git annex unused' command quadratically, even if the location of the branches should be irrelevant as far as unused data goes.
+
+This was tested on:
+
+	$ git annex version
+	git-annex version: 3.20130216
+	local repository version: 3
+	default repository version: 3
+	supported repository versions: 3
+	upgrade supported from repository versions: 0 1 2
+
+What steps will reproduce the problem?
+
+	$ mkdir a
+	$ cd a
+	$ git init
+	$ git annex init
+	$ i=0 ; while test $i -lt 1000; do dd if=/dev/urandom of=$i.img bs=1M count=1; i=$(($i+1)); done
+	$ git annex add .
+	$ git commit -m"foo"
+	$ git rm 1*
+	$ git commit -m"bar"
+	$ git log --oneline --decorate
+	ffcca3a (HEAD, master) bar
+	3e7793d foo
+	$ time -p git annex unused
+	unused . (checking for unused data...) (checking master...)
+	(...)
+	real 0.76
+	user 0.40
+	sys 0.06
+	git commit --allow-empty -m"baz"
+	$ git log --oneline --decorate
+	4390c32 (HEAD, master) baz
+	ffcca3a bar
+	3e7793d foo
+	$ time -p git annex unused
+	unused . (checking for unused data...) (checking master...)
+	(...)
+	real 0.75
+	user 0.38
+	sys 0.07
+	$ git branch boo HEAD^
+	$ time -p git annex unused
+	unused . (checking for unused data...) (checking boo...) (checking master...)
+	(...)
+	real 1.29
+	user 0.62
+	sys 0.08
+	arand@mas:~/tmp/more/a(master)$ git branch beeboo HEAD^
+	4390c32 (HEAD, master) baz
+	ffcca3a (boo, beeboo) bar
+	3e7793d foo
+	arand@mas:~/tmp/more/a(master)$ time -p git annex unused
+	unused . (checking for unused data...) (checking beeboo...) (checking master...)
+	(...)
+	real 2.50
+	user 1.12
+	sys 0.14
+	$ git branch -d boo beeboo
+	$ git log --oneline --decorate
+	4390c32 (HEAD, master) baz
+	ffcca3a bar
+	3e7793d foo
+	$ time -p git annex unused
+	unused . (checking for unused data...) (checking master...)
+	(...)
+	real 0.77
+	user 0.42
+	sys 0.04
+
+What is the expected output? What do you see instead?
+
+I would expect the time to be the same in all the above cases.
+
+What version of git-annex are you using? On what operating system?
+
+	$ git annex version
+	git-annex version: 3.20130216
+
+On current Debian sid/experimental
+
+> [[Done]], thanks to guilhem. We ended up using a different algorythm
+> which is faster yet, basically it now does a diff-index between the
+> index and each branch for its second stage bloom filter.
+> Speedup is 30x with 0 (or 1?) branch, and then massive for each
+> additional branch. --[[Joey]] 
diff --git a/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_1_d350c39c67031c500e3224e92c0029ea._comment b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_1_d350c39c67031c500e3224e92c0029ea._comment
new file mode 100644
index 0000000000..f8b7e789b5
--- /dev/null
+++ b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_1_d350c39c67031c500e3224e92c0029ea._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.210"
+ subject="comment 1"
+ date="2013-02-26T20:29:05Z"
+ content="""
+`git annex unused` finds content that is not used by the working tree or by *any* branch is unused. For the working tree, it can look at the symlinks on disk, which is the fastest option.
+
+For branches, it has to first use `git ls-tree` to find the files on the branch, and then use `git cat-file` to look up the key used by each file. It does this as fast as it can (eg, it runs a single `git cat-file --batch`, rather than one process per file). Still, this is pulling potentially a lot of data out of git, and it gets pretty slow.
+
+I've spent a lot of time optimising this as much as is possible with these constraints. One nice one is that, if it finds no unused keys after checking the working tree, it can stop, rather than checking any branches. Your example avoids this optimisation.
+
+Another optimisation is to only check each git ref once, even if multiple branches refer to it. You can see this optmisation firing in your transcript, when it only shows it's checking one branch of the two identical branches you've made.
+
+Indeed, if you go on and add 100 identical branches, you'll find it runs in just about the same time it ran with 2 branches. (There's a little overhead in getting the list of branches and throwing out the duplicates, but that's all.)
+
+What then explains your numbers? Well, I have no idea. I cannot replicate them; I tend to see about the same amount of time taken with two duplicate branches as with one branch. I suspect you just didn't get statistically valid results, which playing around with `time` at the command line often doesn't,
+due to caching, other active processes, etc.
+"""]]
diff --git a/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_2_b2d2b1caa51ffec3d87c36b373cb8d4a._comment b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_2_b2d2b1caa51ffec3d87c36b373cb8d4a._comment
new file mode 100644
index 0000000000..0954e89880
--- /dev/null
+++ b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_2_b2d2b1caa51ffec3d87c36b373cb8d4a._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~arand"
+ nickname="arand"
+ subject="comment 2"
+ date="2013-02-27T15:53:37Z"
+ content="""
+Hmm, indeed, after further testing it seems like the increased time due to the duplicate branch seems to have been a random quirk, bleh :(
+
+But shouldn't it theoretically be possible to optimize out much of the overhead of multiple very-similar (though not identical) branches though?
+
+I've experimented around with ls-tree and cat-file in a bash script[1], and in this primitive implementation the running time seems to be considerably lower (~0.3s vs ~4s), with much less overhead for extra very-similar branches (~0.7s vs ~37s)
+
+Am I missing some key element that's the reason for the time taken by git annex unused?
+
+
+[1] primitive annex unused script: [https://gitorious.org/arand-scripts/arand-scripts/blobs/master/annex-funused](https://gitorious.org/arand-scripts/arand-scripts/blobs/master/annex-funused)
+
+timing script: [https://gitorious.org/arand-scripts/arand-scripts/blobs/master/annex-testunused](https://gitorious.org/arand-scripts/arand-scripts/blobs/master/annex-testunused)
+
+"""]]
diff --git a/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_3_12b20cbbc2b4cd1ab8af7e3eec9589b4._comment b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_3_12b20cbbc2b4cd1ab8af7e3eec9589b4._comment
new file mode 100644
index 0000000000..9c1da8eeaa
--- /dev/null
+++ b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_3_12b20cbbc2b4cd1ab8af7e3eec9589b4._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="arand"
+ ip="130.243.226.21"
+ subject="comment 3"
+ date="2013-08-10T17:00:21Z"
+ content="""
+So, if I've understood it correctly (please correct me if that's not the case :) )
+
+Currently git-annex unused goes through this process
+
+* Look through all files in the index and find those which are git-annex keys (git ls-tree + git cat-file)
+* Look through all files the current ref and find those which are git-annex keys (git ls-tree + git cat-file)
+* For each ref in the repo
+  - Look through all files and find those which are git-annex keys (git ls-tree + git cat-file)
+* Then at the end
+  - Compare this list of keys with what is stored in .git/annex/objects
+  - Print out any objects which does not match a key.
+
+If that's the case, it means if that if you have multiple refs, even is they only differ by single empty commits, git-annex will end up doing a cat-file for the same file multiple times (one per ref), which is expensive.
+
+Would it be possible to change the algorithm for git-annex unused into instead something like:
+
+* For the index, HEAD, and all refs
+  - Create a list all files and remove those which are duplicates based on their sha1 hash (git ls-tree | uniq)
+* Then Look through this reduced list to find those which are git-annex keys (git cat-file)
+* Then check as before
+
+Unless this bypasses some safety or case I've overlooked, I think it should be possible to speed up git-annex unused quite a bit.
+
+"""]]
diff --git a/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_4_a50b43c15d2650df90f0fa1ced47f532._comment b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_4_a50b43c15d2650df90f0fa1ced47f532._comment
new file mode 100644
index 0000000000..3de85407e3
--- /dev/null
+++ b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_4_a50b43c15d2650df90f0fa1ced47f532._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 4"
+ date="2013-08-11T12:48:47Z"
+ content="""
+I think that could work. It would probably tend to use more memory than the current method, but only a small constant multiplier more. And unused is already the one command that necessarily needs to hold information about the whole repository in memory.
+
+Note that git cat-file is only needed when dealing with branches other than the current working tree. In that special case, it can, and AFAIK does have the optimisation of looking directly at the symlink target instead. Your method may turn out to be both slower and use more memory in that case. It may make sense to special case handling of that case and keep the current code paths there (most of the necessary code for it is used by other stuff anyway).
+"""]]
diff --git a/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_5_7328bc51bd001f2b732a92a2ae175839._comment b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_5_7328bc51bd001f2b732a92a2ae175839._comment
new file mode 100644
index 0000000000..21890a4e1e
--- /dev/null
+++ b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_5_7328bc51bd001f2b732a92a2ae175839._comment
@@ -0,0 +1,114 @@
+[[!comment format=mdwn
+ username="arand"
+ ip="130.243.226.21"
+ subject="comment 5"
+ date="2013-08-11T20:43:22Z"
+ content="""
+I've compared my bash/coreutils implementation mentioned above [annex-funused](https://gitorious.org/arand-scripts/arand-scripts/blobs/918cc79b99e22cbdca01ea4de10e2ca64abfc27a/annex-funused) with `git annex unused` in various situations, and from what I've seen `annex-funused` is pretty much always faster.
+
+In the case of no unused files they seem to be about the same.
+
+In all other cases there is a very considerable difference, for example, in my current main annex I get:
+
+    $ time git annex unused                                                                                                      
+    unused . (checking for unused data...) (checking master...) (checking synced/master...) (checking barracuda160G/master...) ok
+    
+    real    5m13.830s
+    user    2m0.444s
+    sys     0m28.344s
+
+
+whereas
+
+    $ time annex-funused                                                                                                             
+     == WARNING ==
+    This program should NOT be trusted to reliably find unused files in the
+    git annex.
+    
+    
+    real    0m1.569s
+    user    0m2.024s
+    sys     0m0.184s
+
+I tried to check memory usage via `/usr/bin/time -v` as well, and that showed (re-running in the same annex as above)
+
+annex-funused
+
+    Maximum resident set size (kbytes): 13560
+
+git annex unused
+
+    Maximum resident set size (kbytes): 29120
+
+
+I've also written a comparison script [annex-testunused](https://gitorious.org/arand-scripts/arand-scripts/blobs/918cc79b99e22cbdca01ea4de10e2ca64abfc27a/annex-testunused) (needs annex-funused in $PATH) which creates an annex with a bunch of unused files and compares the running time for both versions:
+
+<pre>
+$ annex-testunused
+Initialized empty Git repository in /tmp/tmp.fmsAvsPTcd/.git/
+init  ok
+(Recording state in git...)
+###
+* b2840d7 (HEAD, master) delete ~1100 files
+* c4a1e3a add 3000 files
+* bc19777 (git-annex) update
+* b3e6539 update
+* bec2c8f branch created
+annex unused
+real 0m4.154s
+real 0m2.029s
+real 0m2.044s
+annex funused
+real 0m0.923s
+real 0m0.933s
+real 0m0.905s
+Initialized empty Git repository in /tmp/tmp.7qFoCRWzB3/.git/
+init  ok
+(Recording state in git...)
+###
+* a5ff392 (HEAD, master) empty
+* cca4810 (1) delete ~1100 files
+* 587c406 add 3000 files
+* de0afeb (git-annex) update
+* 37b7881 update
+* 1735062 branch created
+annex unused
+real 0m3.499s
+real 0m3.443s
+real 0m3.435s
+annex funused
+real 0m0.956s
+real 0m0.956s
+real 0m0.874s
+Initialized empty Git repository in /tmp/tmp.L5fjdAgnFv/.git/
+init  ok
+(Recording state in git...)
+###
+* 94463a0 (HEAD, master) empty
+* e115619 (10) empty
+* 20686d4 (9) empty
+* 2e01a3f (8) empty
+* 043289d (7) empty
+* 6a52966 (6) empty
+* 0dc866d (5) empty
+* 35db331 (4) empty
+* 48504bc (3) empty
+* e25cac7 (2) empty
+* 655d026 (1) delete ~1100 files
+* 91a07d1 add 3000 files
+* 3c9ac62 (git-annex) update
+* c5736e0 update
+* 862d5b8 branch created
+annex unused
+real 0m16.242s
+real 0m16.277s
+real 0m16.246s
+annex funused
+real 0m0.960s
+real 0m0.960s
+real 0m0.927s
+</pre>
+
+So, unless I've missed something fundamental (I keep thinking I might have...), it seems to be very consistently faster, and scale ok where `git annex unused` scales rather poorly.
+
+"""]]
diff --git a/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_6_880ef2ee797221332dbb629b2d55522f._comment b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_6_880ef2ee797221332dbb629b2d55522f._comment
new file mode 100644
index 0000000000..a4fea313f9
--- /dev/null
+++ b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_6_880ef2ee797221332dbb629b2d55522f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 6"
+ date="2013-08-12T04:14:18Z"
+ content="""
+The memory usage is probably lower because `sort` and `comm` and bash's `<(command)` all have particularly well tuned memory usage with 37 years of history behind them. Particularly GNU `sort` will transparently use a temp file rather than storing too much data in memory, and does rather sophisticated stuff to make that work efficiently. It's rather harder to get that kind of behavior when not using the unix tools and instead using stock programming language primatives like sort() and hashes.
+
+I still suspect that `git cat-file` is slower than a direct readlink(2) of the symlink, when that can be done.
+"""]]
diff --git a/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_7_826fd82cdf9b1c79c9b555ca26c2c176._comment b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_7_826fd82cdf9b1c79c9b555ca26c2c176._comment
new file mode 100644
index 0000000000..c2dbd18109
--- /dev/null
+++ b/doc/bugs/added_branches_makes___39__git_annex_unused__39___slow/comment_7_826fd82cdf9b1c79c9b555ca26c2c176._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="arand"
+ ip="130.243.226.21"
+ subject="comment 7"
+ date="2013-08-12T18:07:44Z"
+ content="""
+Hmm, probably, do you think this way of getting everything and then doing the filtering could work reasonably in git-annex? Assuming \"git cat-file --batch\" is the main bottleneck, reducing the amount of runs for it would still likely be an improvement?
+"""]]
diff --git a/doc/bugs/adding_a_remote_server_fails.mdwn b/doc/bugs/adding_a_remote_server_fails.mdwn
new file mode 100644
index 0000000000..06e6af4dae
--- /dev/null
+++ b/doc/bugs/adding_a_remote_server_fails.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+I tried to add a remote server to my annex repo using the webapp.
+
+### What steps will reproduce the problem?
+Configuration -> Repositories -> Remote server -> Fill in stuff, use public key auth -> click "check this server" -> enjoy
+
+### What version of git-annex are you using? On what operating system?
+OpenSUSE Tumbleweed, git-annex 5.20140709-gc75193e
+
+### Please provide any additional information below.
+Error message: `user error (gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--with-colons","--list-secret-keys","--fixed-list-mode"] exited 2)`
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+[2014-07-11 12:03:52 CEST] main: starting assistant version 5.20140709-gc75193e
+[2014-07-11 12:03:53 CEST] UpgradeWatcher: Finished upgrading git-annex to version 5.20140709-gc75193e 
+(scanning...) [2014-07-11 12:03:53 CEST] Watcher: Performing startup scan
+(started...) gpg: /home/zilti/.gnupg/gpg.conf:200: argument not expected
+gpg: /home/zilti/.gnupg/gpg.conf:201: invalid option
+gpg: /home/zilti/.gnupg/gpg.conf:200: argument not expected
+gpg: /home/zilti/.gnupg/gpg.conf:201: invalid option
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/adding_a_remote_server_fails/comment_1_cf7ea9171f002c5793a882b42d33a77d._comment b/doc/bugs/adding_a_remote_server_fails/comment_1_cf7ea9171f002c5793a882b42d33a77d._comment
new file mode 100644
index 0000000000..1dc6d69548
--- /dev/null
+++ b/doc/bugs/adding_a_remote_server_fails/comment_1_cf7ea9171f002c5793a882b42d33a77d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="obvious questions"
+ date="2014-07-11T18:12:44Z"
+ content="""
+From what source did you install git-annex?
+
+What version of gpg is installed on your system? What is the contents of line 200 and 201 of/home/zilti/.gnupg/gpg.conf? 
+"""]]
diff --git a/doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work.mdwn b/doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work.mdwn
new file mode 100644
index 0000000000..944d986dbf
--- /dev/null
+++ b/doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work.mdwn
@@ -0,0 +1,39 @@
+(Sorry for the uninformative title, but I had to work within the character limit.)
+
+### Please describe the problem.
+
+`git-annex metadata` does nothing on Windows if invoked while `git-annex addurl` is in progress on other files.
+
+### What steps will reproduce the problem?
+
+On Windows (but not on Linux or macOS, where everything works fine):
+
+- Start `git-annex addurl` in batch mode
+- Feed it two or more URLs
+- After reading the completion message for a URL from addurl's stdout, but before reading the remaining output, run `git-annex metadata` in batch mode and try to set the metadata for the file that was just downloaded.
+- `git-annex metadata` will output an empty line (i.e., just CR LF), and if nothing further is fed to it, it will exit successfully without printing anything else on stdout or stderr.
+- Querying the file's metadata normally after `git-annex addurl` exits will show that no metadata was set for the file.
+
+The Python script at <https://github.com/jwodder/git-annex-bug-20221024/blob/master/mvce.py> (Python 3.8+ required) will run the above steps and show the output from `git-annex metadata`.  A sample run under GitHub Actions can be seen at <https://github.com/jwodder/git-annex-bug-20221024/actions/runs/3322463020/jobs/5491516209>; note the following section of the output under "Run script":
+
+```
+16:04:04 [DEBUG   ] __main__: Opening pipe to: git-annex metadata --batch --json --json-error-messages
+16:04:04 [DEBUG   ] __main__: Input to metadata: b'{"file": "programming/gameboy.pdf", "fields": {"title": ["GameBoy Programming Manual"]}}\n'
+16:04:04 [DEBUG   ] __main__: r.returncode=0
+16:04:04 [DEBUG   ] __main__: r.stdout=b'\r\n'
+16:04:04 [DEBUG   ] __main__: r.stderr=b''
+```
+
+This problem does not always occur, but it seems to occur most of the time.  Using `git-annex registerurl` in place of `git-annex metadata` works fine.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex 10.20221003, provided by datalad/git-annex, on Microsoft Windows Server 2022 
+
+### Please provide any additional information below.
+
+This affects a hobby project of mine – "gamdam", implemented in [Python](https://github.com/jwodder/gamdam) and [Rust](https://github.com/jwodder/gamdam-rust) — that interacts with git-annex.
+
+[[!meta author=jwodder]]
+
+> [[fixed|done]], see my comments --[[Joey]]
diff --git a/doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work/comment_1_831dc2185919865d418b29cd06ef42be._comment b/doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work/comment_1_831dc2185919865d418b29cd06ef42be._comment
new file mode 100644
index 0000000000..c1e1d254cb
--- /dev/null
+++ b/doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work/comment_1_831dc2185919865d418b29cd06ef42be._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-10-26T16:44:21Z"
+ content="""
+Windows is not needed, this will happen in a 
+repository where `git annex adjust --unlock` has been run.
+
+A simpler example:
+
+	joey@darkstar:~/tmp/t2#master(unlocked)>git-annex addurl --batch
+	http://google.com/
+	addurl http://google.com/
+	(to google.com_) ok
+	^Z
+	joey@darkstar:~/tmp/t2#master(unlocked)>git-annex metadata --batch --json
+	{"file":"google.com_","fields":{"author":["bar"]}}
+
+I'm not sure if this is a bug, because it's documented to output a blank
+line when batch mode is provided a file that is not an annexed file, and
+the file is not an annexed file yet due to the pointer not yet having been
+staged in git. Which is needed, when in an adjusted unlocked branch, for
+git-annex to know that this is an annexed file.
+
+When the file is locked, it just stats the symlink, so the fact that the
+symlink is not yet staged in git doesn't matter.
+
+It does not seem to make sense to have addurl update the index
+after each file it adds, because that would make addurl of a lot
+of files unncessarily slow.
+
+So, I think if anything is changed, it would need to be a change to make
+the behavior with unlocked files consistent with the behavior with locked
+files. Eg, when the symlink is not yet staged in git, treat it as a
+non-annexed file. Which is also consistent with other handling of such
+files by git-annex when not in batch mode.
+
+The solution for your program, though, seems like it will be to end the
+git-annex addurl process before trying to set metadata on just-added files.
+Or, alternatively, to use addurl with --json, extract the key, and set the
+metadata of the key.
+"""]]
diff --git a/doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work/comment_2_88b7db5434a56c25c75772caa37bc14a._comment b/doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work/comment_2_88b7db5434a56c25c75772caa37bc14a._comment
new file mode 100644
index 0000000000..80ac4fc644
--- /dev/null
+++ b/doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work/comment_2_88b7db5434a56c25c75772caa37bc14a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-10-26T18:13:42Z"
+ content="""
+I've made --batch handling of unstaged locked files consistent with the
+handling of unstaged unlocked files.
+"""]]
diff --git a/doc/bugs/addurl_--batch_errors_with__git-annex__58___user_error_.mdwn b/doc/bugs/addurl_--batch_errors_with__git-annex__58___user_error_.mdwn
new file mode 100644
index 0000000000..910dee99c2
--- /dev/null
+++ b/doc/bugs/addurl_--batch_errors_with__git-annex__58___user_error_.mdwn
@@ -0,0 +1,73 @@
+### Please describe the problem.
+
+
+original report [https://github.com/dandi/dandisets/issues/168](https://github.com/dandi/dandisets/issues/168)
+
+- likely to happen due to dealing with lots of non-large files
+- happens only for non-large .json files (due to `* annex.largefiles=((mimeencoding=binary)and(largerthan=0))`)
+
+- our log for a sample file looks like
+
+```
+(base) dandi@drogon:/mnt/backup/dandi/dandisets/000108/.git/dandi/logs$ grep 'sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json' sync-20220608125450Z-1944539.log
+2022-06-08T09:34:27-0400 [INFO    ] backups2datalad sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json: Syncing
+2022-06-08T09:34:27-0400 [INFO    ] backups2datalad sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json: Not in dataset; will add
+2022-06-08T09:34:27-0400 [DEBUG   ] backups2datalad sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json: Fetching bucket URL
+2022-06-08T09:34:27-0400 [DEBUG   ] backups2datalad sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json: About to query S3
+2022-06-08T09:34:28-0400 [DEBUG   ] backups2datalad sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json: Got bucket URL
+2022-06-08T09:34:28-0400 [INFO    ] backups2datalad sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json: File is text; sending off for download from https://dandiarchive.s3.amazonaws.com/blobs/4a8/75e/4a875eb7-ab7c-4d54-b962-671b7c35a9d6?versionId=5dwackcdjuYtMeNZUh23k0rIpU7tRqbn
+2022-06-08T09:34:28-0400 [INFO    ] backups2datalad sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json: Downloading from https://dandiarchive.s3.amazonaws.com/blobs/4a8/75e/4a875eb7-ab7c-4d54-b962-671b7c35a9d6?versionId=5dwackcdjuYtMeNZUh23k0rIpU7tRqbn
+2022-06-08T09:34:28-0400 [TRACE   ] backups2datalad Sending to addurl command: 'https://dandiarchive.s3.amazonaws.com/blobs/4a8/75e/4a875eb7-ab7c-4d54-b962-671b7c35a9d6?versionId=5dwackcdjuYtMeNZUh23k0rIpU7tRqbn sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json\n'
+2022-06-08T09:34:28-0400 [TRACE   ] backups2datalad Decoded line from addurl command: '{"command":"addurl","note":"to sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json\\nnon-large file; adding content to git repository","success":false,"input":["https://dandiarchive.s3.amazonaws.com/blobs/4a8/75e/4a875eb7-ab7c-4d54-b962-671b7c35a9d6?versionId=5dwackcdjuYtMeNZUh23k0rIpU7tRqbn sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json"],"error-messages":["git-annex: user error (xargs [\\"-0\\",\\"git\\",\\"--git-dir=.git\\",\\"--work-tree=.\\",\\"--literal-pathspecs\\",\\"-c\\",\\"filter.annex.smudge=\\",\\"-c\\",\\"filter.annex.clean=\\",\\"-c\\",\\"filter.annex.process=\\",\\"add\\",\\"-f\\",\\"--\\"] exited 123)"],"file":"sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json"}\n'
+2022-06-08T09:34:28-0400 [ERROR   ] backups2datalad sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json: download failed: git-annex: user error (xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","filter.annex.smudge=","-c","filter.annex.clean=","-c","filter.annex.process=","add","-f","--"] exited 123)
+
+```
+
+- that file is downloaded but not added to git (according to git status)
+- dedicated `git add` on that file after proceeds fine
+
+<details>
+<summary>seems to happen for some files more than for the others (grepping across logs across multiple runs) -- 38 different files failed, some up to 4 times</summary> 
+
+```shell
+(base) dandi@drogon:/mnt/backup/dandi/dandisets/000108/.git/dandi/logs$ awk '{print $5;}' < /tmp/108-download-fails.log | sort | uniq -c  | sort -n | nl | tail
+    29        2 sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-LEC_run-1_chunk-7_SPIM.json:
+    30        2 sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-1_SPIM.json:
+    31        2 sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-5_SPIM.json:
+    32        2 sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-YO_run-1_chunk-6_SPIM.json:
+    33        2 sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-YO_run-1_chunk-7_SPIM.json:
+    34        2 sub-MITU01/ses-20220315h17m32s36/micr/sub-MITU01_ses-20220315h17m32s36_sample-25_stain-NN_run-1_chunk-1_SPIM.json:
+    35        2 sub-MITU01/ses-20220315h17m32s36/micr/sub-MITU01_ses-20220315h17m32s36_sample-25_stain-NN_run-1_chunk-7_SPIM.json:
+    36        3 sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-LEC_run-1_chunk-4_SPIM.json:
+    37        4 sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-6_SPIM.json:
+    38        4 sub-MITU01/ses-20220311h10m19s37/micr/sub-MITU01_ses-20220311h10m19s37_sample-22_stain-NN_run-1_chunk-7_SPIM.json:
+```
+</details>
+
+- ATM there is about 3k of staged "new file" .json files and 4 not staged (those errors)
+- invocation was `git-annex addurl --batch --with-files --jobs 5 --json --json-error-messages --json-progress --raw`
+
+### What steps will reproduce the problem?
+
+haven't tried to create reproducer yet.  may be I could just grep log for all those addurls and provide text file to feed annex addurls..
+
+### What version of git-annex are you using? On what operating system?
+
+`10.20220525+git57-ge796080f3-1~ndall+1` before that was some other recent -- same problem
+
+```
+(base) dandi@drogon:/mnt/backup/dandi/dandisets/000108$ /home/dandi/git-annexes/10.20220525+git57-ge796080f3-1~ndall+1/usr/lib/git-annex.linux/git --version
+git version 2.30.2
+(base) dandi@drogon:/mnt/backup/dandi/dandisets/000108$ /home/dandi/git-annexes/10.20220525+git57-ge796080f3-1~ndall+1/usr/lib/git-annex.linux/git-annex version
+git-annex version: 10.20220525+git57-ge796080f3-1~ndall+1
+...
+```
+
+
+Please advise on how to debug or share ideas on what could lead to it or what to try.
+
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/addurl_--batch_errors_with__git-annex__58___user_error_/comment_1_996a54315c21e1dcb94cca9576d1d5f7._comment b/doc/bugs/addurl_--batch_errors_with__git-annex__58___user_error_/comment_1_996a54315c21e1dcb94cca9576d1d5f7._comment
new file mode 100644
index 0000000000..a4e66d94f6
--- /dev/null
+++ b/doc/bugs/addurl_--batch_errors_with__git-annex__58___user_error_/comment_1_996a54315c21e1dcb94cca9576d1d5f7._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-06-13T17:14:42Z"
+ content="""
+Well, this is a case where `git add` is failing for some reason. It seems
+very likely that it output some error message to stderr, so I'd look for
+that in the log. It's not clear to me if your grep would show that.
+
+If `git add` was silent on stderr, then I'd move on to thinking it must
+have crashed  (or have a weird bug). The 123 exit code is from xargs and
+only indicates that `git add` exited nonzero, so we don't know what the
+actual exit code was. But it seems that `git add` did not die of a
+segfault; it if had the exit code from xargs would be 125.
+
+Since git-annex is batching up some number of files and sending them all to
+a single `git add`, the files that come last would fail to be added if any
+earlier file somehow caused `git add` to give up. So that could explain why
+it happens more often for some files.
+"""]]
diff --git a/doc/bugs/addurl_--preserve-filename_still_modifies_file_names.mdwn b/doc/bugs/addurl_--preserve-filename_still_modifies_file_names.mdwn
new file mode 100644
index 0000000000..80445ab6a6
--- /dev/null
+++ b/doc/bugs/addurl_--preserve-filename_still_modifies_file_names.mdwn
@@ -0,0 +1,41 @@
+### Please describe the problem.
+
+The new `--preserve-filename` option does not have its described effect on torrent files.
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+$ git annex addurl --preserve-filename \
+        http://downloads.endor.at/chaos-math_multi-language_1080p_mkv.ea15601881aa1be1.torrent
+"""]]
+
+(cancelling when at least a file has arrived)
+
+[[!format sh """
+$ tree
+└── downloads.endor.at_chaos-math_multi-language_1080p_mkv.ea15601881aa1be1.torrent/
+    └── 01._Motion_and_determinism_-_Panta_Rhei__1080p_.mkv 
+$ btcheck -l <(curl 'https://downloads.endor.at/chaos-math_multi-language_1080p_mkv.ea15601881aa1be1.torrent')
+Base directory : chaos-math_multi-language_1080p_mkv
+01. Motion and determinism - Panta Rhei [1080p].mkv     (409315188)
+"""]]
+
+Based on the description of `--preserve-filename`, given that nothing in the names is particularly malicious, I'd have expected the tree output to look like this:
+
+[[!format sh """
+$ tree
+└── chaos-math_multi-language_1080p_mkv/   (as per base directory)
+    └── 01. Motion and determinism - Panta Rhei [1080p].mkv 
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+8.20200522 (built using `gbp buildpackage` from current git master, 87dc9cd0)
+
+### Please provide any additional information below.
+
+This option, when working with torrents, would be a building block to [[todo/bittorrent: support offline operation and verification]], and resolve most of the suggestions from there.
+
+### Have you had any luck using git-annex before?
+
+Yes: It saved me from potential data loss when my backup cron jobs stopped working and the mails got lost -- `git annex drop` failing on the laptops was both the right thing to do given numcopies=2, and alerted me to the problem in due time.
diff --git a/doc/bugs/addurl_--preserve-filename_still_modifies_file_names/comment_1_88c0a762e2a37f680f6a4419582eddac._comment b/doc/bugs/addurl_--preserve-filename_still_modifies_file_names/comment_1_88c0a762e2a37f680f6a4419582eddac._comment
new file mode 100644
index 0000000000..bb7f7fdc33
--- /dev/null
+++ b/doc/bugs/addurl_--preserve-filename_still_modifies_file_names/comment_1_88c0a762e2a37f680f6a4419582eddac._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-26T14:37:42Z"
+ content="""
+It certianly should not be mangling the filenames inside the torrent
+directory, eg replacing space with underscore. I have fixed that now.
+
+As to the name of the directory used by the torrent file, the interface
+with remotes does not currently let the remote provide it, and would
+need to be changed, which would also involve changing the external
+special remote protocol.
+
+Hmm, I suppose if the remote returns a set of files all within a single
+subdirectory, it could use that subdirectory instead of the mangled url as
+the containing subdirectory. Then the bittorrent remote could just add
+the name as a prefix to the list of files in the torrent. (Or rather,
+stop removing the name prefix, which is what it actually does currently..)
+
+Then any external remotes that support CHECKURL and return multiple files all
+inside the same single subdirectory would change behavior with and without
+--preserve-filename. Without it, the single directory would be removed,
+and the files in it put inside the mangled url subdirectory. 
+With it, the single directory would be used without the containing 
+subdirectory. The behavior change without --preserve-filename is the
+possibly concerning one. Unfortunately I don't think this approach is a
+safe one because something might rely on the current behavior.
+
+I am not keen on complicating the remote interface, and especially the
+external special remote protocol with something that only supports
+this special case.
+"""]]
diff --git a/doc/bugs/addurl_--preserve-filename_still_modifies_file_names/comment_2_386891c1effda6cae17d88eacbfa0daf._comment b/doc/bugs/addurl_--preserve-filename_still_modifies_file_names/comment_2_386891c1effda6cae17d88eacbfa0daf._comment
new file mode 100644
index 0000000000..17604a235e
--- /dev/null
+++ b/doc/bugs/addurl_--preserve-filename_still_modifies_file_names/comment_2_386891c1effda6cae17d88eacbfa0daf._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="comment 2"
+ date="2020-05-26T16:35:25Z"
+ content="""
+Thanks for the fast fix. I've run it with my test torrent and the files now all have their original names.
+
+
+As for the the directory name, there's the component that git-annex picks, and the one in the torrent.
+
+As git-annex has historically ignored the latter, so be it -- we could think up a configurable option, but I wouldn't bother. (And it wouldn't necessarily be a change in the remote protocol, the torrent remote could just prefix its paths with the `name` field if that gets configured.)
+
+The component that git-annex picks I would kind of have expected to be absent: If I'm in a directory and tell git-annex to --preserve-filename get a copy of whatever, I'd expect the server-provided name (or names) of that thing to pop up in that directory, the command was issued, not in a subdirectory.
+"""]]
diff --git a/doc/bugs/addurl_fails_because_special_remote_is_not_available.mdwn b/doc/bugs/addurl_fails_because_special_remote_is_not_available.mdwn
new file mode 100644
index 0000000000..ed5bc62705
--- /dev/null
+++ b/doc/bugs/addurl_fails_because_special_remote_is_not_available.mdwn
@@ -0,0 +1 @@
+I can't addurl a file because there is a special remote which is not available. I can see that git annex is asking it if it wants to claim the url which it doesn't. I don't feel addurl should depend on the remote after CLAIMURL-FAILURE. Or do I miss something?
diff --git a/doc/bugs/addurl_fails_because_special_remote_is_not_available/comment_1_7caf2377477495c08378755cdf45dec8._comment b/doc/bugs/addurl_fails_because_special_remote_is_not_available/comment_1_7caf2377477495c08378755cdf45dec8._comment
new file mode 100644
index 0000000000..9733346c02
--- /dev/null
+++ b/doc/bugs/addurl_fails_because_special_remote_is_not_available/comment_1_7caf2377477495c08378755cdf45dec8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2019-09-02T15:49:57Z"
+ content="""
+Post the trace (with `git annex --debug --verbose`) and your config files (`git config --list`)?  (Redact any sensitive info).  Maybe, `annex.security.allowed-ip-addresses` excludes the IP address of the URL, so the built-in web remote never gets a chance to claim the URL?  I recall running into something like you describe, and the issue was with some config setting I had.
+"""]]
diff --git a/doc/bugs/addurl_fails_because_special_remote_is_not_available/comment_2_83a864a73f9c1c6bf86dc60b47a965fe._comment b/doc/bugs/addurl_fails_because_special_remote_is_not_available/comment_2_83a864a73f9c1c6bf86dc60b47a965fe._comment
new file mode 100644
index 0000000000..14c356a807
--- /dev/null
+++ b/doc/bugs/addurl_fails_because_special_remote_is_not_available/comment_2_83a864a73f9c1c6bf86dc60b47a965fe._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-16T17:38:35Z"
+ content="""
+If the special remote responds with CLAIMURL-FAILURE, then addurl will not
+use it.
+
+There might be some other way the special remote could fail that breaks
+addurl. The only one I can see currently is if the special remote sends
+something that's not a valid response in the protocol.
+
+So I second Ilya, we need a protocol dump or a better explanation about what
+behavior you are seeing.
+"""]]
diff --git a/doc/bugs/addurl_fails_because_special_remote_is_not_available/comment_3_b0e9f373c3439b15a28fd20e9b0e24a6._comment b/doc/bugs/addurl_fails_because_special_remote_is_not_available/comment_3_b0e9f373c3439b15a28fd20e9b0e24a6._comment
new file mode 100644
index 0000000000..1c699cc1aa
--- /dev/null
+++ b/doc/bugs/addurl_fails_because_special_remote_is_not_available/comment_3_b0e9f373c3439b15a28fd20e9b0e24a6._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 3"
+ date="2019-12-12T21:11:58Z"
+ content="""
+Apparently it happens when the remote returns PREPARE-FAILURE (in this case due to insufficient internet connection). So we get back to 
+[PREPARE-LOCAL](http://git-annex.branchable.com/design/external_special_remote_protocol/#comment-2eec51c9f774f577b8634e9cdc86cde3) and  [external_remote_querying_transition](https://git-annex.branchable.com/todo/external_remote_querying_transition).
+
+I'm going to change git-annex-remote-googledrive to defer network connection to when when it's needed. But as external remotes are encouraged to establish network connections in PREPARE, something should be done on git-annex's side, too. 
+
+
+    % git annex addurl --batch --with-files --debug
+    [url] [filename]
+    [2019-12-12 21:41:14.540686936] read: git [\"--git-dir=../../../.git\",\"--work-tree=../../..\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+    [2019-12-12 21:41:14.546632041] process done ExitSuccess
+    [2019-12-12 21:41:14.546795605] read: git [\"--git-dir=../../../.git\",\"--work-tree=../../..\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2019-12-12 21:41:14.551391222] process done ExitSuccess
+    [2019-12-12 21:41:14.551593051] read: git [\"--git-dir=../../../.git\",\"--work-tree=../../..\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..802429a871b754d61047457aa9936bde404e3172\",\"--pretty=%H\",\"-n1\"]
+    [2019-12-12 21:41:14.553261192] process done ExitSuccess
+    [2019-12-12 21:41:14.553318623] read: git [\"--git-dir=../../../.git\",\"--work-tree=../../..\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..0e8f6eb6cc45d9bb11f42fcf8590b3473e6f2623\",\"--pretty=%H\",\"-n1\"]
+    [2019-12-12 21:41:14.555647103] process done ExitSuccess
+    [2019-12-12 21:41:14.555710805] read: git [\"--git-dir=../../../.git\",\"--work-tree=../../..\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..7271aaaa110b0f84b5e730673c66b176789ddcaf\",\"--pretty=%H\",\"-n1\"]
+    [2019-12-12 21:41:14.557235619] process done ExitSuccess
+    [2019-12-12 21:41:14.557298991] read: git [\"--git-dir=../../../.git\",\"--work-tree=../../..\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..b9112bcb862041cf96f00e12c6dd33dc31fda5fa\",\"--pretty=%H\",\"-n1\"]
+    [2019-12-12 21:41:14.560071044] process done ExitSuccess
+    [2019-12-12 21:41:14.560126818] read: git [\"--git-dir=../../../.git\",\"--work-tree=../../..\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..1598b00a78067edc438652f401498a25635cd5a9\",\"--pretty=%H\",\"-n1\"]
+    [2019-12-12 21:41:14.562966332] process done ExitSuccess
+    [2019-12-12 21:41:14.563218447] chat: git [\"--git-dir=../../../.git\",\"--work-tree=../../..\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+    [2019-12-12 21:41:14.563535554] chat: git [\"--git-dir=../../../.git\",\"--work-tree=../../..\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+    [2019-12-12 21:41:14.56562967] read: git [\"config\",\"--null\",\"--list\"]
+    [2019-12-12 21:41:14.566788099] process done ExitSuccess
+    [2019-12-12 21:41:14.567203332] read: git [\"config\",\"--null\",\"--list\"]
+    [2019-12-12 21:41:14.568286923] read: git [\"config\",\"--null\",\"--list\"]
+    [2019-12-12 21:41:14.569077497] chat: /home/silvio/.local/bin/git-annex-remote-googledrive []
+    [2019-12-12 21:41:14.944193013] git-annex-remote-googledrive[1] --> VERSION 1
+    [2019-12-12 21:41:14.944312387] git-annex-remote-googledrive[1] <-- EXTENSIONS INFO
+    [2019-12-12 21:41:14.944486597] git-annex-remote-googledrive[1] --> EXTENSIONS
+    [2019-12-12 21:41:14.944557495] git-annex-remote-googledrive[1] <-- EXPORTSUPPORTED
+    [2019-12-12 21:41:14.94467435] git-annex-remote-googledrive[1] --> EXPORTSUPPORTED-SUCCESS
+    [2019-12-12 21:41:14.944906493] chat: /home/silvio/.local/bin/git-annex-remote-googledrive []
+    [2019-12-12 21:41:15.333971094] git-annex-remote-googledrive[1] --> VERSION 1
+    [2019-12-12 21:41:15.334086558] git-annex-remote-googledrive[1] <-- EXTENSIONS INFO
+    [2019-12-12 21:41:15.334273359] git-annex-remote-googledrive[1] --> EXTENSIONS
+    [2019-12-12 21:41:15.334334558] git-annex-remote-googledrive[1] <-- PREPARE
+    [...]
+    [2019-12-12 21:41:43.372727829] git-annex-remote-googledrive[1] --> PREPARE-FAILURE ('Failed to connect with Google. Please check your internet connection.', ServerNotFoundError('Unable to find the server at www.googleapis.com'))
+    git-annex: ('Failed to connect with Google. Please check your internet connection.', ServerNotFoundError('Unable to find the server at www.googleapis.com'))
+
+"""]]
diff --git a/doc/bugs/addurl_unittest_failing_under_windows.mdwn b/doc/bugs/addurl_unittest_failing_under_windows.mdwn
new file mode 100644
index 0000000000..7929112e15
--- /dev/null
+++ b/doc/bugs/addurl_unittest_failing_under_windows.mdwn
@@ -0,0 +1,56 @@
+### Please describe the problem.
+git annex works perfectly fine under windows now; awesome work! One of the tests in the suite still fails (which might affect some features, that I don't use (yet?)).
+
+### What steps will reproduce the problem?
+[[!format sh """
+$ git annex test -p addurl
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+$ git --version
+git version 2.6.4.windows.1
+
+$ git annex version
+git-annex version: 5.20151218-g5008846
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3(multipartupload) WebDAV ConcurrentOutput DNS Feeds Quvi TDFA TorrentParser Database
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+"""]]
+
+Windows 10 (OS Build 10586.0)
+
+### Please provide any additional information below.
+
+[[!format sh """
+$ git annex test -p addurl
+Tests
+  Unit Tests
+Init Tests
+    addurl:   init:   Detected a filesystem without fifo support.
+  Disabling ssh connection caching.
+  Detected a crippled filesystem.
+  Enabling direct mode.
+OK (2.74s)
+  add:  fatal: This operation must be run in a work tree
+OK (6.00s)
+
+All 2 tests passed (8.79s)
+  Detected a filesystem without fifo support.
+  Disabling ssh connection caching.
+  Detected a crippled filesystem.
+  Enabling direct mode.
+removeDirectoryRecursive: permission denied (The process cannot access the file because it is being used by another process.)
+sleeping 10 seconds and will retry directory cleanup
+FAIL (7.16s)
+      addurl failed on file:///Users/born/.t/tmprepo0/myurl
+
+1 out of 1 tests failed (28.13s)
+  (This could be due to a bug in git-annex, or an incompatibility
+   with utilities, such as git, installed on this system.)
+"""]]
+
+
+> This seems to have been fixed in the meantime, windows test case fully
+> passes these days. [[done]] --[[Joey]]
diff --git a/doc/bugs/addurl_unittest_failing_under_windows/comment_1_8f723e986d80754a8b68308ab8b15c20._comment b/doc/bugs/addurl_unittest_failing_under_windows/comment_1_8f723e986d80754a8b68308ab8b15c20._comment
new file mode 100644
index 0000000000..de5b45a1d6
--- /dev/null
+++ b/doc/bugs/addurl_unittest_failing_under_windows/comment_1_8f723e986d80754a8b68308ab8b15c20._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-15T19:17:54Z"
+ content="""
+That test needs curl to be available. git-annex relies on Git for Windows
+containing curl.
+
+Is the curl command available in the shell where you ran git-annex test?
+"""]]
diff --git a/doc/bugs/addurl_unittest_failing_under_windows/comment_2_e0bbb72af2852b2210bb1ce520e88f1d._comment b/doc/bugs/addurl_unittest_failing_under_windows/comment_2_e0bbb72af2852b2210bb1ce520e88f1d._comment
new file mode 100644
index 0000000000..8f1c3a21a7
--- /dev/null
+++ b/doc/bugs/addurl_unittest_failing_under_windows/comment_2_e0bbb72af2852b2210bb1ce520e88f1d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-09-24T19:33:41Z"
+ content="""
+Just ran into the same situation!   Happens in both v6 and direct modes.  I have `curl` but not wget available in that shell (Anaconda's shell).
+Here are examples:
+[v6](http://www.onerussian.com/tmp/gkrellShoot_09-24-18_152906.png), [direct](http://www.onerussian.com/tmp/gkrellShoot_09-24-18_153055.png)
+"""]]
diff --git a/doc/bugs/adjusted__40__unlocked__41___does_not_honor_addunlocked.mdwn b/doc/bugs/adjusted__40__unlocked__41___does_not_honor_addunlocked.mdwn
new file mode 100644
index 0000000000..394b93e072
--- /dev/null
+++ b/doc/bugs/adjusted__40__unlocked__41___does_not_honor_addunlocked.mdwn
@@ -0,0 +1,43 @@
+### Please describe the problem.
+
+Files added/modified in an `adjusted(unlocked)` branch get added as locked (symlink) files to the related branch, without honoring the `annex.addunlocked` setting.
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+#!/bin/sh -x
+set -x
+test -e testrepo && chmod +w -R testrepo && rm -rf testrepo
+git -c init.defaultBranch=main init testrepo
+cd testrepo
+git annex init
+git annex config --set annex.addunlocked true
+echo content > README.md
+git annex assist
+git annex adjust --unlock
+echo "changed on adjusted(unlocked) branch" > README.md
+git annex assist
+git switch main
+file README.md # should be an unlocked file, but is a symlink
+# README.md: symbolic link to .git/annex/objects/1z/J4/SHA256E-s37--947ef3df7717076c1cdd9c17f5fe90d69347c479e491500dac3051a4a03c6ecb.md/SHA256E-s37--947ef3df7717076c1cdd9c17f5fe90d69347c479e491500dac3051a4a03c6ecb.md
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+# on NixOS
+> git annex version
+git-annex version: 10.20240129
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24.1 bloomfilter-2.0.1.2 crypton-0.32 DAV-1.3.4 feed-1.3.2.1 ghc-9.4.8 http-client-0.7.15 persistent-sqlite-2.13.2.0 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Hell yeah, git annex rules! 💪
diff --git a/doc/bugs/adjusted__47__main__40__unlocked__41___not_syncing_with_main.mdwn b/doc/bugs/adjusted__47__main__40__unlocked__41___not_syncing_with_main.mdwn
new file mode 100644
index 0000000000..88b0db994d
--- /dev/null
+++ b/doc/bugs/adjusted__47__main__40__unlocked__41___not_syncing_with_main.mdwn
@@ -0,0 +1,65 @@
+### Please describe the problem.
+
+I'm using Git Annex on Windows and Linux.
+
+On Windows - Git annex is using `adjusted/main(unlocked)` branch that is syncing to `main`. This setup worked reliably for a few weeks
+
+A couple days ago `adjusted/main(unlocked)` branch stopped syncing to `main`. Currently log looks like this:
+
+```
+commit C (HEAD -> adjusted/main(unlocked))
+Date:   Wed Feb 8 07:47:49 2023 -0500
+    New commit on windows - no longer syncing to main
+
+commit B
+Date:   Mon Jan 30 21:09:41 2023 -0500
+    git-annex adjusted branch
+
+commit A (origin/synced/main, origin/main, synced/main, main)
+Date:   Mon Jan 30 21:09:41 2023 -0500
+    Last commit before sync stopped working
+```
+
+I've tried (several times):
+
+```
+git annex sync
+commit
+On branch adjusted/main(unlocked)
+nothing to commit, working tree clean
+ok
+```
+
+```
+git annex sync --cleanup
+cleanup local ok
+```
+
+So `sync` is reporting that there is nothing to do, but `main` branch is not syncing. I've tried adding a new commit to `adjusted/main(unlocked)` and the did not help with restoring sync. Not sure what else to try.
+
+Hoping to figure out what caused this. Help is much appreciated!
+
+### What steps will reproduce the problem?
+
+Git annex Windows repo stoped syncing. I don't know what caused this. It worked reliably for a few weeks
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20221105-g56f824d21
+Windows 10
+local repository version: 10
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
+> Added a warning message in this situation. [[done]] --[[Joey]]
diff --git a/doc/bugs/adjusted__47__main__40__unlocked__41___not_syncing_with_main/comment_1_e5ebc1cf8621761b559d53884731d0e3._comment b/doc/bugs/adjusted__47__main__40__unlocked__41___not_syncing_with_main/comment_1_e5ebc1cf8621761b559d53884731d0e3._comment
new file mode 100644
index 0000000000..33deefcdf6
--- /dev/null
+++ b/doc/bugs/adjusted__47__main__40__unlocked__41___not_syncing_with_main/comment_1_e5ebc1cf8621761b559d53884731d0e3._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="rshalaev@3e2130a1e3cb0aaff7dd80aba7548ad9be0ea2d4"
+ nickname="rshalaev"
+ avatar="http://cdn.libravatar.org/avatar/d7f181d338cbcef7418faa01f0441e86"
+ subject="comment 1"
+ date="2023-02-09T14:22:19Z"
+ content="""
+Update:
+
+I was able to resolve the problem - believe that it was caused by the fact that I changed branch name from `master` to `main` and had leftover `refs/basis/adjusted/master(unlocked)`.
+
+Resolved following this steps:
+
+```
+git switch main
+git annex merge \"adjusted/main(unlocked)\"
+git branch -D \"adjusted/main(unlocked)\"
+rm -rf .git/refs/basis/*
+git annex adjust --unlocked
+```
+
+Tested that sync is now working
+"""]]
diff --git a/doc/bugs/adjusted__47__main__40__unlocked__41___not_syncing_with_main/comment_2_149502c4d8fa2c50507e7e6e312f9703._comment b/doc/bugs/adjusted__47__main__40__unlocked__41___not_syncing_with_main/comment_2_149502c4d8fa2c50507e7e6e312f9703._comment
new file mode 100644
index 0000000000..4c3f9e3866
--- /dev/null
+++ b/doc/bugs/adjusted__47__main__40__unlocked__41___not_syncing_with_main/comment_2_149502c4d8fa2c50507e7e6e312f9703._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-02-10T18:07:47Z"
+ content="""
+For an adjusted branch, git-annex keeps
+a hidden  ref, `refs/basis/adjusted/master(unlocked)`. 
+That ref also needs to be renamed if you're going to
+rename the adjusted branch and the original branch.
+
+It's of course fine to delete the old adjusted branch and
+re-adjust the new branch.
+
+I think that git-annex should warn if it cannot find 
+the basis ref for an adjusted branch.
+"""]]
diff --git a/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified.mdwn b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified.mdwn
new file mode 100644
index 0000000000..f5e51c397c
--- /dev/null
+++ b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified.mdwn
@@ -0,0 +1,57 @@
+### Please describe the problem.
+
+When checking an adjusted (unlocked) branch, after a while (a few hours), without modifying anything but running several times "git status", a lot of files are reported as "modified" by "git status".
+
+### What steps will reproduce the problem?
+
+On a ~1.5To repo with 1Go to 4Go files, running "git adjust --unlock" works, but after a while "git status" reports a lot of files being modified, "git restore myfiles" restores the files, but other files are reported by "git status" as modified...
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 8.20201103, Debian sid
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+$ cat .git/config
+[core]
+    repositoryformatversion = 0
+    filemode = true
+    bare = false
+    logallrefupdates = true
+[annex]
+    uuid = 56c81321-3ca1-4464-8c42-b4b405a2502d
+    version = 8
+    thin = true
+    autocommit = false
+[receive]
+    denyCurrentBranch = updateInstead
+[filter "annex"]
+    smudge = git-annex smudge %f
+    clean = git-annex smudge --clean %f
+$ git status
+Refresh index: 100% (4703/4703), done.
+On branch adjusted/master(unlocked)
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git restore <file>..." to discard changes in working directory)
+      modified:    file1.avi
+      modified:    file2.avi
+      ...
+
+
+It took 3.88 seconds to enumerate untracked files. 'status -uno'
+may speed it up, but you have to be careful not to forget to add
+new files yourself (see 'git help status').
+no changes added to commit (use "git add" and/or "git commit -a")
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+It's almost perfect :-).
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_10_8a355d509fb2005cfd9da8f2d4bb560e._comment b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_10_8a355d509fb2005cfd9da8f2d4bb560e._comment
new file mode 100644
index 0000000000..96a850759b
--- /dev/null
+++ b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_10_8a355d509fb2005cfd9da8f2d4bb560e._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2022-06-02T15:47:14Z"
+ content="""
+Well, I can confirm that, with .git/info/attributes missing, `git status`
+displays unlocked files as modified.
+
+But, the bug originally reported here had the files only start to show up
+as modified after some amount of time, not immediately. And also, it had
+`git diff --cached` outputting nothing when run on those files. The
+behavior with .git/info/attributes does not match either of those. So I
+don't think yours is the same problem as the original bug report. Which
+it's pretty clear involved sshfs.
+
+As to how .git/info/attributes could be missing:
+It is created by `git-annex init`. Upgrading a repository from v5 or older
+will also create it. So I don't see how it could normally be missing. At the
+moment the most likely reason would be if you had deleted it earlier..
+
+(One other way it can be missing is if annex.supportunlocked is set to
+false.)
+"""]]
diff --git a/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_11_ee707efce9c5537a1f7d0ffded952af8._comment b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_11_ee707efce9c5537a1f7d0ffded952af8._comment
new file mode 100644
index 0000000000..686481aad0
--- /dev/null
+++ b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_11_ee707efce9c5537a1f7d0ffded952af8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2023-06-21T18:38:29Z"
+ content="""
+Oh, I think oliv5 and guuex were the same person..
+
+If you had .git/info/attributes missing all along, that nicely explains it
+all.
+
+I think this can be closed then.
+"""]]
diff --git a/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_1_0fcdba2f621c8c32f09b2633c11266ee._comment b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_1_0fcdba2f621c8c32f09b2633c11266ee._comment
new file mode 100644
index 0000000000..1e649716df
--- /dev/null
+++ b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_1_0fcdba2f621c8c32f09b2633c11266ee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2020-11-23T19:06:13Z"
+ content="""
+Did you change the [[backend|https://git-annex.branchable.com/backends/]] of some files via `.gitattributes` in the meantime? I think git annex's smudge/clean filter will then return the hash of the new backend and that differs from the one of the old backend, so git reports the files as changed.
+"""]]
diff --git a/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_2_4719510b78d347f28a0fe8910c086982._comment b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_2_4719510b78d347f28a0fe8910c086982._comment
new file mode 100644
index 0000000000..aea1696764
--- /dev/null
+++ b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_2_4719510b78d347f28a0fe8910c086982._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="comment 2"
+ date="2020-11-24T21:07:37Z"
+ content="""
+You mean between the \"git annex adjust\" and the \"git status\"? No, I did nothing at all :(.
+
+After running \"git restore\" some files (but not all, it seems to be the first N files ordered alphabetically) are still marked as modified, some others get modified again after another \"git restore\"... Weird!
+"""]]
diff --git a/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_3_05f178a19b8949efc5c6e189ff8fa5e0._comment b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_3_05f178a19b8949efc5c6e189ff8fa5e0._comment
new file mode 100644
index 0000000000..d37c419fe4
--- /dev/null
+++ b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_3_05f178a19b8949efc5c6e189ff8fa5e0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-01-29T16:52:47Z"
+ content="""
+I've never seen this behavior, but it seems that if git thinks the files
+are modified, either `git diff` or `git diff --cached` must show some kind
+of change, and seeing what that change might be would be a useful clue to
+what happened.
+"""]]
diff --git a/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_4_ad4621b602e7632d74d58f1728b80cda._comment b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_4_ad4621b602e7632d74d58f1728b80cda._comment
new file mode 100644
index 0000000000..250b1f55a6
--- /dev/null
+++ b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_4_ad4621b602e7632d74d58f1728b80cda._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="comment 4"
+ date="2021-02-01T18:11:40Z"
+ content="""
+I'd say around 50% of the files are reported as modified by \"git status\".
+
+`git --no-pager diff --cached --output git-annex-cached-diff.diff` returns
+instantly, with no output and nothing in `git-annex-cached-diff.diff`.
+`git --no-pager diff --output git-annex-diff.diff` ran for around 5 hours, with no output and nothing in `git-annex-diff.diff`.
+"""]]
diff --git a/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_5_fcb259337b70b0d5c5e50c8facb845e4._comment b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_5_fcb259337b70b0d5c5e50c8facb845e4._comment
new file mode 100644
index 0000000000..34a1d99ee4
--- /dev/null
+++ b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_5_fcb259337b70b0d5c5e50c8facb845e4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="comment 5"
+ date="2021-02-01T18:33:48Z"
+ content="""
+The repo is in a dir mounted with sshfs.
+"""]]
diff --git a/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_6_1df979b8e222dd135a10046c51f0dc0b._comment b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_6_1df979b8e222dd135a10046c51f0dc0b._comment
new file mode 100644
index 0000000000..d055b0dae7
--- /dev/null
+++ b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_6_1df979b8e222dd135a10046c51f0dc0b._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-02-02T16:28:29Z"
+ content="""
+Being on sshfs makes me wonder if perhaps something synthesized by that
+filesystem is confusing git, so eg it thinks the inode or mtime of a file has
+changed and so it's modified.
+
+However, normally git status does the same work to verify if there's really
+a modification as git diff does (running the smudge filter in this case).
+So I'm not clear what's going on here, but it's currently looking more like
+a problem at the git level, or a filesystem that is too wonky for git to
+work well, rather than anything git-annex can do.
+
+I have to wonder why you'd even use git-annex on sshfs. The more usual way
+would be to have a local repository with a remote using ssh to access the
+server.
+"""]]
diff --git a/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_7_5e3482024e20759f8d42e14598d4dc26._comment b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_7_5e3482024e20759f8d42e14598d4dc26._comment
new file mode 100644
index 0000000000..a97a34b1e0
--- /dev/null
+++ b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_7_5e3482024e20759f8d42e14598d4dc26._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="comment 7"
+ date="2021-02-03T17:06:24Z"
+ content="""
+I have a local repo (without most of the files) with Debian sid and a remote using ssh, on a server with Debian stable. The files are big, so it is easier to access them with sshfs, to avoid copying them. I wanted to use adjusted branches for users who access the files with gnome/nautilus (via sshfs integration) which is not clever with copying symlinks. So, I upgraded the repo from my laptop (repo mounted with sshfs).
+
+Note that this problem only occurs with adjusted branched, I also have other repos accessed and upgraded via sshfs (sometimes because I just ran \"git status\" on a repo mounted with sshfs, which resulted in an upgrade (I think)), and there is no file reported as modified (git status is also slow, though).
+"""]]
diff --git a/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_8_4e9f342281b01ecb9354a08200c04ab0._comment b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_8_4e9f342281b01ecb9354a08200c04ab0._comment
new file mode 100644
index 0000000000..628793ae32
--- /dev/null
+++ b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_8_4e9f342281b01ecb9354a08200c04ab0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="comment 8"
+ date="2021-02-03T17:20:24Z"
+ content="""
+I've just seen it happen on a repo without adjusted branches, sorry! So, it does not seem to be related with them.
+"""]]
diff --git a/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_9_63af8f32512ce8ec07c48361317ce51d._comment b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_9_63af8f32512ce8ec07c48361317ce51d._comment
new file mode 100644
index 0000000000..060eafb9e5
--- /dev/null
+++ b/doc/bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified/comment_9_63af8f32512ce8ec07c48361317ce51d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 9"
+ date="2022-06-01T11:16:35Z"
+ content="""
+One note for people with the same issue: on my side, the file .git/info/attributes was missing.
+
+I created it with the following content, taken from \"git-annex help smudge\" manpage:
+
+    * filter=annex
+    .* !filter
+
+And the \"git status\" issue vanished...
+"""]]
diff --git a/doc/bugs/android_sync_messes_tree.mdwn b/doc/bugs/android_sync_messes_tree.mdwn
new file mode 100644
index 0000000000..204df363f2
--- /dev/null
+++ b/doc/bugs/android_sync_messes_tree.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+
+Hi,
+
+I'm trying to sync some files to my Android phone using the adb special remote.
+
+Of course, I have a complicated 'wanted' expression: I want new files matching a query be exported automatically on 'sync' and files added on the phone be imported automatically. I also want the files I manually export to the phone to stay where they are.
+
+I'm still debugging my 'wanted' expression,
+I run 'git annex sync --content',
+notice it isn't syncing the right files,
+ctrl+C.
+
+My worktree is left in a weird state: All the files are moved or removed.
+It seems git-annex made the worktree into the desired shape for syncing. However, it did that with my main worktree, which is annoying.
+
+To recover from that, 'git reset --hard' works but I also need to do 'git add' then 'git annex fix'.
+
+Is here a reason to use the main worktree instead of a temporary directory to do that ?
+
+Also, it makes a branch 'android/master' which seems weird. First, it doesn't look like 'master' at all, a cryptic name would be better.
+This branch isn't supposed to be pushed anywhere and generates tons of conflicts every time, I don't think it should do a branch at all.
+Why not rebuild the desired tree into a temporary directory without storing it in git in any way ?
+
+### What steps will reproduce the problem?
+
+Have an 'adb' remote with 'annex-tracking-branch' set to a subdirectory, 'master:subdirectory'.
+Kill the process while it is syncing files.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20220504
+Android Debug Bridge version 1.0.41 (31.0.3p1-android-tools)
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I've been using git-annex for a year and it has been awesome for me ! I'm trusting it more and more and that's why I'm trying new things with it.
+
+Thanks a lot for the awesome work !
diff --git a/doc/bugs/android_sync_messes_tree/comment_1_a90afb9011c760843836728d03353619._comment b/doc/bugs/android_sync_messes_tree/comment_1_a90afb9011c760843836728d03353619._comment
new file mode 100644
index 0000000000..95f83f70d7
--- /dev/null
+++ b/doc/bugs/android_sync_messes_tree/comment_1_a90afb9011c760843836728d03353619._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="jules@a6ba859eba6f59bd980f294741b1ad9b7624552a"
+ nickname="jules"
+ avatar="http://cdn.libravatar.org/avatar/a751e2ef9129dfaf6c68a0d762e5db60"
+ subject="mess up commited to my branch"
+ date="2022-09-29T09:26:05Z"
+ content="""
+I noticed that even when the syncing finishes. Worse than that, the 'android/master' branch is merged into 'master'.
+The removed files are brought back during the merge, but the moved files are committed.
+
+I definitely don't want git annex to touch my master branch. I have 'autocommit = false', 'synconlyannex = true' and 'alwayscommit = false'. I take care of merging and pushing the 'git-annex' branch myself.
+
+Perhaps I'm not using git-annex right ?
+"""]]
diff --git a/doc/bugs/android_sync_messes_tree/comment_2_90d589053c4d1b646edd07978999d001._comment b/doc/bugs/android_sync_messes_tree/comment_2_90d589053c4d1b646edd07978999d001._comment
new file mode 100644
index 0000000000..e3ca86f242
--- /dev/null
+++ b/doc/bugs/android_sync_messes_tree/comment_2_90d589053c4d1b646edd07978999d001._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-10-04T16:44:54Z"
+ content="""
+I'm quite sure that syncing with a extporttree=yes special remote does not
+alter the working tree or the usual index beyond the sync command's usual
+commit of any staged changes. It writes the tree using `git mktree` 
+and `git commit-tree`.
+
+I have tried to reproduce this, without any luck. I used a directory
+special remote not adb, but that should not possibly change anything.
+
+	joey@darkstar:~/tmp/bench/ar>git-annex initremote directory type=directory directory=../d encryption=none exporttree=yes importtree=yes
+	joey@darkstar:~/tmp/bench/ar>git config remote.directory.annex-tracking-branch master:subdirectory
+	joey@darkstar:~/tmp/bench/ar>dd if=/dev/urandom of=subdirectory/bigfile2 bs=1M count=100
+	joey@darkstar:~/tmp/bench/ar>git-annex add subdirectory/bigfile2
+
+	joey@darkstar:~/tmp/bench/ar>git-annex sync --content
+	commit 
+	[master 159757a] git-annex in joey@darkstar:~/tmp/bench/ar
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 subdirectory/bigfile2
+	ok
+	list directory ok
+	update refs/remotes/directory/master ok
+	
+	Merge made by the 'ort' strategy.
+	export directory bigfile2 ^C
+	- exit 130
+	joey@darkstar:~/tmp/bench/ar>git st
+	On branch master
+	nothing to commit, working tree clean
+	joey@darkstar:~/tmp/bench/ar>ls
+	foo@  subdirectory/
+
+Also, I don't understand what you mean by this:
+
+	This branch isn't supposed to be pushed anywhere and generates tons of conflicts every time
+
+What do these conflicts look like? When do they happen?
+
+Please show a transcript of the problem happening. Ideally starting with a
+fresh git repository and showing all steps you used to set it up.
+"""]]
diff --git a/doc/bugs/android_sync_messes_tree/comment_3_f964c18aced83ba02d3436941dbcbacc._comment b/doc/bugs/android_sync_messes_tree/comment_3_f964c18aced83ba02d3436941dbcbacc._comment
new file mode 100644
index 0000000000..21d246634b
--- /dev/null
+++ b/doc/bugs/android_sync_messes_tree/comment_3_f964c18aced83ba02d3436941dbcbacc._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-10-04T17:13:21Z"
+ content="""
+Here's my suspicion: You started with annex-tracking-branch set to
+some value, and synced. Then you changed it to some other value and synced
+again.
+
+For example, if you start with it set to master:subdirectory, then
+change it to master, this happens on the subsequent sync:
+
+	list directory ok
+	update refs/remotes/directory/master ok
+	
+	Updating d946446..8dd4a6f
+	Fast-forward
+	 bigfile                           | 1 +
+	 foo                               | 1 -
+	 subdirectory/bigfile              | 1 -
+
+So, files not in subdirectory get removed, and everything in subdirectory
+is moved out of it and into the top of the tree.
+
+Does this behavior make sense? I am not sure, but by changing 
+annex-tracking-branch, you have certianlly ripped the rug out from under
+git-annex. And that seems to more or less match what you are describing.
+
+(Nothing to do with being interrupted, and no merge conflicts though.)
+"""]]
diff --git a/doc/bugs/android_sync_messes_tree/comment_4_1f819796ec13f83e56917332efffe54d._comment b/doc/bugs/android_sync_messes_tree/comment_4_1f819796ec13f83e56917332efffe54d._comment
new file mode 100644
index 0000000000..c906c027f4
--- /dev/null
+++ b/doc/bugs/android_sync_messes_tree/comment_4_1f819796ec13f83e56917332efffe54d._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-10-04T17:21:44Z"
+ content="""
+The reason that happens is that the remote tracking branch has a tree with
+"subdirectory/bigfile" and "foo" in it. The new tree imported from the
+remote, after changing annex-tracking-branch, has "bigfile" in it. So the
+result is the same as if a regular git remote used to contain that old
+tree, and has been updated to the new tree. `git merge` with a remote where
+that has happened naturally updates master to move "subdirectory/bigfile"
+to "bigfile" and to delete "foo".
+
+I think this does beg the question of how to safely change
+annex-tracking-branch. One way is to sync, change it, sync again. Then
+revert the commit that imports from the remote. That gets the tree back
+into the state it was before, and then syncing again will update the
+remote.
+
+Perhaps git-annex should detect when the annex-tracking-branch config
+has changed, and somehow handle this better, or just refuse to sync?
+"""]]
diff --git a/doc/bugs/android_sync_messes_tree/comment_5_7fda943808cc1b7155c1223fea08e8df._comment b/doc/bugs/android_sync_messes_tree/comment_5_7fda943808cc1b7155c1223fea08e8df._comment
new file mode 100644
index 0000000000..09784bfd8f
--- /dev/null
+++ b/doc/bugs/android_sync_messes_tree/comment_5_7fda943808cc1b7155c1223fea08e8df._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="jules@a6ba859eba6f59bd980f294741b1ad9b7624552a"
+ nickname="jules"
+ avatar="http://cdn.libravatar.org/avatar/a751e2ef9129dfaf6c68a0d762e5db60"
+ subject="comment 5"
+ date="2022-10-04T17:59:53Z"
+ content="""
+Yes, I did change the 'annex-tracking-branch' in the way you described. I was trying various values and I guess I expected git-annex not to keep any state after I interrupted the transfer (a few files were transfered).
+
+I suspect the merge conflicts (on the android/master branch) were a combination of interrupting the process and changing the config back and forth. I think I could see them because my git config (name, email) is temporarily broken if the worktree is changed, which interrupted the committing.
+
+I would expect git-annex to remember what happened only if it completed. In the case of adb, transfer is pretty slow and it's not likely to ever terminate (if I didn't meant to sync that many files, I won't wait days for it to complete).
+The impacted files were all the files to be synced, only a fraction of which was actually synced.
+
+"""]]
diff --git a/doc/bugs/annex.autocommit_seems_ignored_for_new_files.mdwn b/doc/bugs/annex.autocommit_seems_ignored_for_new_files.mdwn
new file mode 100644
index 0000000000..a06d3aa5a6
--- /dev/null
+++ b/doc/bugs/annex.autocommit_seems_ignored_for_new_files.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+
+When `annex.autocommit` is set to `false`, the assistant continues to commit to the repository, at least in indirect mode (direct mode not tested). I'd like it to not even `git annex add`, but it should at least not `git commit`.
+
+### What steps will reproduce the problem?
+
+I started the assistant with `git annex assistant`. Then I also opened the webapp with `git annex website`.
+
+Next, I ran `git config --bool --local --replace-all annex.autocommit false`. Supposedly that'll stop the assistant from committing things.
+
+Then I did a `echo "hello world" > test`.
+
+The webapp showed the file syncing, and `ls -l test` confirmed it'd been added the annex. `git status` confirmed it'd been committed as well.
+
+I did a `git rm test`, and then a `git status`... and it turns out the annex committed that as well.
+
+NOTE: My repository is in indirect mode.
+
+I tried `--global` instead of `--local` for the config, and that didn't make a difference.
+
+
+### What version of git-annex are you using? On what operating system?
+
+5.20141125 on Debian testing, from the package. (And, thank you Joey, for all your work on Debian. You'll be missed.)
+
+### Please provide any additional information below.
+
+> The assistant does not notice changes to the 
+> git configuration that are made while it's already running.
+> 
+> I have verified that setting `git config annex.autocommit true`
+> and then starting the assistant behaves as documented.
+>
+> So will asking the webapp to restart.
+> 
+> Retitling bug report appropriately. --[[Joey]]
+
+[[!meta title="git-annex assistant could watch .git/config and react to config changes on the fly"]]
+[[!tag confirmed]]
diff --git a/doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data.mdwn b/doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data.mdwn
new file mode 100644
index 0000000000..367169fd8b
--- /dev/null
+++ b/doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data.mdwn
@@ -0,0 +1,11 @@
+Suppose two git-annex symlinks (locked files) point to the same key.  If you unlock one symlink, and `annex.thin` is `true`, editing the file will change the contents pointed to by the second, supposedly locked, symlink.  
+
+Maybe, with `annex.thin`, when one copy of a file is unlocked, all must be unlocked?
+
+Also, with `annex.thin`, the [[invariant|internals]] that `.git/annex/objects/aa/bb/*/*` contains content with given key gets broken if the file is edited.  Might that affect other things, like metadata lookup? [[`git-annex-fsck`|git-annex-fsck]] reports this as an error.
+
+[[`git-annex-drop`|git-annex-drop]] succeeds but does not actually drop the file.
+
+Also, even if the current repo is trusted, with `annex.thin`, an unlocked file should not count as a trusted copy.
+
+[[!tag confirmed]]
diff --git a/doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_1_d02a1e53cb95b0cb3c4330c668bcb15b._comment b/doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_1_d02a1e53cb95b0cb3c4330c668bcb15b._comment
new file mode 100644
index 0000000000..94673cf296
--- /dev/null
+++ b/doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_1_d02a1e53cb95b0cb3c4330c668bcb15b._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-06-21T19:28:52Z"
+ content="""
+Confirmed this is still a problem. `git-annex fsck` does detect and deal
+with it, by eg deleting the corrupted object.
+
+It seems like it would be hard for git-annex to make other files that use
+the same object be unlocked. Consider a repo with one file, that is
+unlocked and uses an object. Then a `git merge` adds another, locked file,
+using the same object. git-annex didn't have a chance to run at all, and
+now the stage is set for this problem to happen if the user appends to the
+unlocked file.
+
+In a way, the docs for annex.thin do warn the user about this. If you squint
+just right:
+
+	... but when a modification is made to a
+        file, you will lose the local (and possibly only)  copy  of  the
+        old version
+
+But, git-annex goes out of its way to avoid 2 unlocked files being hardlinked
+when using annex.thin. So it seems wrong that a locked file and an unlocked file
+will be hard linked, and that the locked file can get corrupted.
+
+I've made the docs warn about it better.
+"""]]
diff --git a/doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_2_a6806787dc0163f67dc141415c951add._comment b/doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_2_a6806787dc0163f67dc141415c951add._comment
new file mode 100644
index 0000000000..69d2c81ea3
--- /dev/null
+++ b/doc/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/comment_2_a6806787dc0163f67dc141415c951add._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-06-22T17:45:08Z"
+ content="""
+Ugh, I had closed this as not solvable, but on second thought, it's a very
+real wart and if it's not solvable that doesn't make it not a problem.
+
+And it does seem that it could be solved in some outside the box way. 
+
+For example, what if thin files were not hard links to the object file?
+Now, they *have* to hard link to somewhere, to prevent git checkout from
+deleting the only copy of a thin file. But it could hard link to a
+different name in the object directory. One that symlinks do not point to.
+
+Then `git-annex fix` or fsck would need to notice when a symlink points to
+an object file that is missing, and copy the thin file to it to populate
+it. And, something might also want to reap object files that have become
+only used by thin files.
+"""]]
diff --git a/doc/bugs/annex_add_freezes_before_moving__58___stopped_working.mdwn b/doc/bugs/annex_add_freezes_before_moving__58___stopped_working.mdwn
new file mode 100644
index 0000000000..922c3e161f
--- /dev/null
+++ b/doc/bugs/annex_add_freezes_before_moving__58___stopped_working.mdwn
@@ -0,0 +1,70 @@
+### Please describe the problem.
+
+git-annex freezes the file to be moved under .git/annex/objects before moving, but freezing of the file could make it unmovable (at least that is what happens to us now on discovery although that did not happen before, not yet sure what has changed).
+
+Here is what happens on a sample repo:
+
+```
+[d31548v@ndoli derivatives]$ mkdir test; cd test; git init; git annex init; touch 123; git annex add --debug 123
+Initialized empty Git repository in /dartfs-hpc/rc/lab/C/CANlab/labdata/data/WASABI/derivatives/test/.git/
+init  ok
+(recording state in git...)
+[2023-01-16 12:17:34.428880032] (Utility.Process) process [15018] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2023-01-16 12:17:34.472934882] (Utility.Process) process [15018] done ExitSuccess
+[2023-01-16 12:17:34.474468798] (Utility.Process) process [15019] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2023-01-16 12:17:34.520392371] (Utility.Process) process [15019] done ExitSuccess
+[2023-01-16 12:17:34.523255323] (Utility.Process) process [15020] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..d54f4272ddecfccbc2b80f85aa10fc0c1182a8bd","--pretty=%H","-n1"]
+[2023-01-16 12:17:34.574881634] (Utility.Process) process [15020] done ExitSuccess
+[2023-01-16 12:17:34.58416992] (Utility.Process) process [15021] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2023-01-16 12:17:34.631862153] (Utility.Process) process [15022] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2023-01-16 12:17:34.669579382] (Utility.Process) process [15022] done ExitSuccess
+[2023-01-16 12:17:34.6712721] (Utility.Process) process [15023] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","refs/heads/master"]
+[2023-01-16 12:17:34.715405595] (Utility.Process) process [15023] done ExitFailure 1
+[2023-01-16 12:17:34.718334524] (Utility.Process) process [15024] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-files","-z","--others","--exclude-standard","--","123"]
+[2023-01-16 12:17:34.76320148] (Utility.Process) process [15025] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","check-attr","-z","--stdin","annex.backend","annex.largefiles","annex.numcopies","annex.mincopies","--"]
+[2023-01-16 12:17:34.809269539] (Utility.Process) process [15026] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+add 123 [2023-01-16 12:17:34.848893304] (Utility.Process) process [15027] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2023-01-16 12:17:34.883573286] (Utility.Process) process [15027] done ExitSuccess
+[2023-01-16 12:17:34.885621822] (Utility.Process) process [15028] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","refs/heads/master"]
+[2023-01-16 12:17:34.920147829] (Utility.Process) process [15028] done ExitFailure 1
+[2023-01-16 12:17:34.922913861] (Utility.Process) process [15029] call: sh ["-c","/dartfs-hpc/rc/home/j/f003z4j/bin-annex/freeze-content '123'"]
+[2023-01-16 12:17:34.954774083] (Utility.Process) process [15029] done ExitSuccess
+
+[2023-01-16 12:17:34.987464314] (Utility.Process) process [15034] call: sh ["-c","/dartfs-hpc/rc/home/j/f003z4j/bin-annex/thaw-content '.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'"]
+[2023-01-16 12:17:35.025118709] (Utility.Process) process [15034] done ExitSuccess
+[2023-01-16 12:17:35.031067944] (Utility.Process) process [15039] call: sh ["-c","/dartfs-hpc/rc/home/j/f003z4j/bin-annex/freeze-content '.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'"]
+[2023-01-16 12:17:35.065740268] (Utility.Process) process [15039] done ExitSuccess
+
+git-annex: .git/annex/othertmp/ingest-12315012-0: rename: permission denied (Permission denied)
+failed
+[2023-01-16 12:17:35.073776498] (Utility.Process) process [15024] done ExitSuccess
+[2023-01-16 12:17:35.074875132] (Utility.Process) process [15044] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-files","-z","--modified","--","123"]
+[2023-01-16 12:17:35.108396621] (Utility.Process) process [15044] done ExitSuccess
+[2023-01-16 12:17:35.109700932] (Utility.Process) process [15045] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","diff","--name-only","--diff-filter=T","-z","--cached","--","123"]
+[2023-01-16 12:17:35.147595321] (Utility.Process) process [15045] done ExitSuccess
+[2023-01-16 12:17:35.159897061] (Utility.Process) process [15021] done ExitSuccess
+[2023-01-16 12:17:35.160360662] (Utility.Process) process [15026] done ExitSuccess
+[2023-01-16 12:17:35.160730269] (Utility.Process) process [15025] done ExitSuccess
+add: 1 failed
+[d31548v@ndoli test]$ nfs4_getfacl 
+123   .git/ 
+[d31548v@ndoli test]$ nfs4_getfacl 123
+
+# file: 123
+A::OWNER@:rxtncy
+A::GROUP@:rxtncCoy
+A:g:rc-CANlab-wasabi@KIEWIT.DARTMOUTH.EDU:rxtncy
+```
+
+So -- git-annex first freezes the to be annexed file, and then moves it into thawed up key directory, which it then freezes.  That seems to no longer work for us.
+
+Currently we get our run to error because our freezing script rightfully removes `d` flag, which [according to docs](https://www.osc.edu/book/export/html/4523) is for "delete the file/directory" permissions -- we wanted to prevent deletion of the file.  And so far it seems I have failed to tune up containing directory's ACL in such a way that I would be forbidden to remove a file from under it if file has `d` permission.  So it might be a divergence from POSIX system behavior where ability to remove file solely relies on directory's permission?
+
+if that is the case, and if I do not find ACL setting which would forbid removal of a file based on directory's permissions, could annex then
+
+- delay freezing of the file containing the data until it actually moves the file into .git/annex/objects location?
+
+To me such behavior might make a little more sense that current assumption that filesystem allows to have frozen file to be moved.
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
diff --git a/doc/bugs/annex_add_freezes_before_moving__58___stopped_working/comment_1_b3c780a6f888c8afc3bd5cd7d436527c._comment b/doc/bugs/annex_add_freezes_before_moving__58___stopped_working/comment_1_b3c780a6f888c8afc3bd5cd7d436527c._comment
new file mode 100644
index 0000000000..d67e518c0e
--- /dev/null
+++ b/doc/bugs/annex_add_freezes_before_moving__58___stopped_working/comment_1_b3c780a6f888c8afc3bd5cd7d436527c._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-01-16T19:56:10Z"
+ content="""
+Could your script be changed to not remove the `d` flag when freezing
+the file, but instead when freezing the directory, remove the `d` flag from the
+file then? (And restore the file's `d` flag when thawing the directory.)
+
+That seems like it would avoid the problem since as you say,
+git-annex freezes the directory after moving the file into it. And freezing
+the directory is logically what you are doing really.
+
+But, you would need to convert .git/annex/objects/xx/yy/KEY to
+.git/annex/objects/xx/yy/KEY/KEY to get the name of the file,
+which is a bit grubbing into git-annex internals I suppose.
+
+git-annex has a good reason to want to prevent modifications to the file
+before moving it: It has to hash it before knowing where to move it to, and
+it would like to avoid the file getting modified while it is being hashed.
+(Though of course it will recover if that does happen.) So I would not want
+to skip the permission setting part of the pre-move freeze. What I suppose
+it could do is only set the permissions at that point, and defer running
+the freeze hook until after moving the file.
+
+(I checked and Comand.Import also has a `freezeContent` that comes
+before a file is moved and would need to be changed. 
+Rest of the calls look ok.)
+"""]]
diff --git a/doc/bugs/annex_add_freezes_before_moving__58___stopped_working/comment_2_97df39b9fed0e9bb716b1940c0641140._comment b/doc/bugs/annex_add_freezes_before_moving__58___stopped_working/comment_2_97df39b9fed0e9bb716b1940c0641140._comment
new file mode 100644
index 0000000000..8b35e0e752
--- /dev/null
+++ b/doc/bugs/annex_add_freezes_before_moving__58___stopped_working/comment_2_97df39b9fed0e9bb716b1940c0641140._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2023-01-16T21:27:12Z"
+ content="""
+hm, good point on freezing before checksumming... and indeed I also dislike a little the need to make freeze/thawing very annex-specific as to freeze/thaw file(s) under `KEY/`.
+Before going that way, I think, I also should re-try my initial attempt [described here](https://git-annex.branchable.com/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/) of adding/removing explicit  `D::EVERYONE@:wadTN`, which was not possible back in those times but should work now. Even though that approach probably would not resolve this particular issue, should make it a little cleaner.
+
+NB still not sure what change rendered prior working setup not working. Need to make testing of those helpers run daily on that system as part of the client testing of datalad/git-annex
+"""]]
diff --git a/doc/bugs/annex_add_freezes_before_moving__58___stopped_working/comment_3_db0070d2b601e66aca3059248cc24bbb._comment b/doc/bugs/annex_add_freezes_before_moving__58___stopped_working/comment_3_db0070d2b601e66aca3059248cc24bbb._comment
new file mode 100644
index 0000000000..7eaf11344a
--- /dev/null
+++ b/doc/bugs/annex_add_freezes_before_moving__58___stopped_working/comment_3_db0070d2b601e66aca3059248cc24bbb._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-01-17T16:59:22Z"
+ content="""
+On the idea of only removing the write permissions before checksumming and
+running the freeze hook later, it occurs to me that on some systems, write
+perms are inneffective, but the freeze hook is able to more effectively
+prevent writing.
+
+Actually, the immutable bit on linux is a good example of this. If a
+process has the file open for write when `git-annex add` is run, removing
+the write bit will not prevent modifications to the file happening during
+checksumming. But `chattr +i` actually causes further writes to that handle
+to fail with EPERM. So if someone is able to use chattr and sets up a hook,
+they get better prevention of an unlikely but possible scenario, where
+a write to a file done during checksumming is not detectable by git-annex.
+
+(Unlikely because the file mtime also has to get reset back to what it was
+before, and the file size can't change. A process would have to really
+go out of its way to defeat git-annex, but still one *could*.)
+"""]]
diff --git a/doc/bugs/annex_get__stalls_over_ssh.mdwn b/doc/bugs/annex_get__stalls_over_ssh.mdwn
new file mode 100644
index 0000000000..9d95ebdedd
--- /dev/null
+++ b/doc/bugs/annex_get__stalls_over_ssh.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+
+```
+yoh      1441153  0.0  0.0   9732  3924 pts/31   S+   11:38   0:00          |   \_ git annex --debug get sourcedata
+yoh      1441155  0.5  0.0 1075008100 48380 pts/31 Sl+ 11:38   0:00          |   |   \_ /usr/lib/git-annex.linux/exe/git-annex --library-path /usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git-annex/git-annex --debug get sourcedata
+yoh      1441187  0.0  0.0  11592  4516 pts/31   S+   11:38   0:00          |   |       \_ /usr/lib/git-annex.linux/exe/git --library-path /usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.debug=true hash-object -w --no-filters --stdin-paths
+yoh      1441191  0.0  0.0  51252  5760 pts/31   S+   11:38   0:00          |   |       \_ /usr/lib/git-annex.linux/exe/git --library-path /usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.debug=true cat-file --batch
+yoh      1441202  0.0  0.0  44852  5580 pts/31   S+   11:38   0:00          |   |       \_ /usr/lib/git-annex.linux/exe/git --library-path /usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.debug=true cat-file --batch
+yoh      1441248  0.0  0.0  12444  6736 pts/31   S+   11:38   0:00          |   |       \_ ssh user@server.dartmouth.edu -S .git/annex/ssh/user@server.dartmouth.edu -o ControlMaster=auto -o ControlPersist=yes -T git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba726b95-7662-41fa-8e82-f7ffd16fce7e' --uuid 6384a551-a41d-4290-b186-9258befede97
+yoh      1441249  0.0  0.0  12444  6780 pts/31   S+   11:38   0:00          |   |       \_ ssh user@server.dartmouth.edu -S .git/annex/ssh/user@server.dartmouth.edu -o ControlMaster=auto -o ControlPersist=yes -T git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba726b95-7662-41fa-8e82-f7ffd16fce7e' --uuid 6384a551-a41d-4290-b186-9258befede97
+yoh      1441250  0.0  0.0  12444  6900 pts/31   S+   11:38   0:00          |   |       \_ ssh user@server.dartmouth.edu -S .git/annex/ssh/user@server.dartmouth.edu -o ControlMaster=auto -o ControlPersist=yes -T git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba726b95-7662-41fa-8e82-f7ffd16fce7e' --uuid 6384a551-a41d-4290-b186-9258befede97
+yoh      1441251  0.0  0.0  12444  6508 pts/31   S+   11:38   0:00          |   |       \_ ssh user@server.dartmouth.edu -S .git/annex/ssh/user@server.dartmouth.edu -o ControlMaster=auto -o ControlPersist=yes -T git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba726b95-7662-41fa-8e82-f7ffd16fce7e' --uuid 6384a551-a41d-4290-b186-9258befede97
+yoh      1441154  0.0  0.0   5372   504 pts/31   S+   11:38   0:00          |   \_ tee /tmp/annex-get-debug.log
+```
+
+with git-annex 10.20230321-1~ndall+1 and ssh's:
+```ssh
+$> ssh -V
+OpenSSH_8.4p1 Debian-5+deb11u1+p1, OpenSSL 1.1.1n  15 Mar 2022
+
+$> ssh user@server.dartmouth.edu ssh -V
+OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
+
+$> ssh user@server.dartmouth.edu git-annex version | head -n1
+git-annex version: 6.20180808-ga1327779a
+```
+
+am I right to blame too outdated remote git-annex-shell?
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
diff --git a/doc/bugs/annex_get__stalls_over_ssh/comment_1_335a8901b7992c2041eabed3785a25e0._comment b/doc/bugs/annex_get__stalls_over_ssh/comment_1_335a8901b7992c2041eabed3785a25e0._comment
new file mode 100644
index 0000000000..e57c1cfc7e
--- /dev/null
+++ b/doc/bugs/annex_get__stalls_over_ssh/comment_1_335a8901b7992c2041eabed3785a25e0._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-06-12T16:57:14Z"
+ content="""
+Your git-annex-shell does support p2pstdio, not the older thing that
+git-annex no longer uses. But it's from fairly early in
+its rollout, and it does seem likely that it has a since-fixed bug.
+
+There were at least 3 commits made soon after version 6.20180808
+that fixed hangs in the p2p protocol:
+
+[[!commit 0b053b96119c1a2d6c2d03ba7f98f032e89b8b66]]
+[[!commit 983c9d5a53189f71797591692c0ed675f5bd1c16]]
+[[!commit 6ecd55a9fa4c64399b5ede3944bd2aa5f78cf0b1]]
+
+So I think it will likely be fixed by an upgrade.
+"""]]
diff --git a/doc/bugs/annex_import_does_not_account_for_versioning_on_S3.mdwn b/doc/bugs/annex_import_does_not_account_for_versioning_on_S3.mdwn
new file mode 100644
index 0000000000..4f6229e34c
--- /dev/null
+++ b/doc/bugs/annex_import_does_not_account_for_versioning_on_S3.mdwn
@@ -0,0 +1,16 @@
+### Please describe the problem.
+Using the S3 special remote with version support enabled (`versioning=yes`) leads to a bit of a strange effect with multiple `annex import` calls.
+First import from an existing bucket is fine. Now, if there were changes done to a file in the bucket and one runs `annex import` again, git-annex will record that the old version of said file is gone from the remote, requiring a `git annex fsck` to be called right after that import to fix it again. That seems a bit strange given that this versioning support comes with a "native" special remote.
+
+I suppose that's probably a more general issue with how import/export works, since there's no way for a special remote to communicate to annex whether two different versions of the same file (same remote path, but different key) would overwrite each other. Neither an importtree nor an exporttree remote has a way to tell annex whether and how the availability of a previous key associated with the same remote path was affected.
+
+
+### What version of git-annex are you using? On what operating system?
+Observed with several versions from 8-10 on linux. As laid out above, I strongly suspect this is true for all versions.
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Lots. I love git-annex.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/annex_import_does_not_account_for_versioning_on_S3/comment_1_a04fbb936785456ed99512ea4c29fd53._comment b/doc/bugs/annex_import_does_not_account_for_versioning_on_S3/comment_1_a04fbb936785456ed99512ea4c29fd53._comment
new file mode 100644
index 0000000000..c3d8aa057b
--- /dev/null
+++ b/doc/bugs/annex_import_does_not_account_for_versioning_on_S3/comment_1_a04fbb936785456ed99512ea4c29fd53._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-10-11T16:28:39Z"
+ content="""
+This looks like a simple fix. After importing from a versioned remote,
+it can just skip updating the location logs to remove the keys that are not
+present in the current tree. The same as is already done when exporting
+to a versioned remote. I've made that change.
+"""]]
diff --git a/doc/bugs/annex_import_does_not_account_for_versioning_on_S3/comment_2_6015c5488e69307424a3c0281b50a49e._comment b/doc/bugs/annex_import_does_not_account_for_versioning_on_S3/comment_2_6015c5488e69307424a3c0281b50a49e._comment
new file mode 100644
index 0000000000..134394ae66
--- /dev/null
+++ b/doc/bugs/annex_import_does_not_account_for_versioning_on_S3/comment_2_6015c5488e69307424a3c0281b50a49e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="benjamin.poldrack@d09ccff6d42dd20277610b59867cf7462927b8e3"
+ nickname="benjamin.poldrack"
+ avatar="http://cdn.libravatar.org/avatar/5c1a901caa7c2cfeeb7e17e786c5230d"
+ subject="comment 2"
+ date="2022-10-12T06:12:17Z"
+ content="""
+Thank you!
+"""]]
diff --git a/doc/bugs/annex_remotedaemon_100__37___cpu_hungry.mdwn b/doc/bugs/annex_remotedaemon_100__37___cpu_hungry.mdwn
new file mode 100644
index 0000000000..6b20db9fda
--- /dev/null
+++ b/doc/bugs/annex_remotedaemon_100__37___cpu_hungry.mdwn
@@ -0,0 +1,81 @@
+### Please describe the problem.
+
+Rebooted my laptop recently (after dunno how long of uptime) and annex assistant was shut off in previous uptime, but this time decided to leave it running. spotted that laptop is hot today to see that git-annex is busy.  And I am not sure what it is really doing:  top says
+
+     3087 yoh       30  10  520700  21084  14748 S 100.0  0.1  80:50.60 /usr/bin/git-annex remotedaemon 
+
+
+[[!format sh """
+
+$> tail -20 /proc/3087/cwd/.git/annex/daemon.log
+
+Please make sure you have the correct access rights
+and the repository exists.
+ssh: connect to host vagus.cns.dartmouth.edu port 22: Connection timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+ssh: connect to host vagus.cns.dartmouth.edu port 22: Connection timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+[2015-03-28 20:27:53 EDT] main: Syncing with debandy_Vault 
+hostname: Name or service not known
+hostname: Name or service not known
+To ssh://yoh@git-annex-andy-yoh_.2Fmedia.2FVault.2Fannex/media/Vault/annex/
+   8c181af..a0b0bd6  git-annex -> synced/git-annex
+   8352761..537d4a6  master -> synced/master
+
+"""]]
+
+in webapp I saw it struggling to connect  to vagus which is offline, I turned it off, then reanabled syncing to above yoh@git-annex-andy-yoh_.2Fmedia.2FVault.2Fannex .  I don't know if annex was busier or not before, but it is 100% busy now, but nothing seems to be done -- no traffic, no changing fd's for that annex process
+
+strace shows busy reading from fd 24:
+
+[[!format sh """
+[pid  3110] read(24, "", 8096)          = 0
+[pid  3110] read(24, "", 8096)          = 0
+[pid  3110] read(24, "", 8096)          = 0
+[pid  3110] read(24, "", 8096)          = 0
+"""]]
+
+
+    $> ls -l /proc/3087/fd/24                      
+    lr-x------ 1 yoh yoh 64 Mar 28 20:31 /proc/3087/fd/24 -> pipe:[794930]
+
+
+so what could it be doing?
+
+[[!format sh """
+ 2807 yoh        20   0  693M  110M 36948 S  1.4  0.7 11:15.32 ├─ /usr/bin/git-annex assistant --startdelay=5s
+ 3359 yoh        39  19 20996  3412  3096 S  0.0  0.0  0:00.01 │  ├─ git --git-dir=.git --work-tree=. check-attr -z --stdin annex.backend annex.numcopies --
+ 3140 yoh        20   0 21128  3504  3188 S  0.0  0.0  0:00.01 │  ├─ git --git-dir=.git --work-tree=. check-ignore -z --stdin --verbose --non-matching
+ 3117 yoh        20   0  693M  110M 36948 S  0.0  0.7  0:00.00 │  ├─ /usr/bin/git-annex assistant --startdelay=5s
+ 3108 yoh        20   0  693M  110M 36948 S  0.0  0.7  0:00.15 │  ├─ /usr/bin/git-annex assistant --startdelay=5s
+ 3087 yoh        30  10  508M 21084 14748 S 97.9  0.1  1h29:16 │  ├─ /usr/bin/git-annex remotedaemon
+24361 yoh        30  10  508M 21084 14748 S  0.0  0.1  0:00.00 │  │  ├─ /usr/bin/git-annex remotedaemon
+19799 yoh        30  10     0     0     0 Z  0.0  0.0  0:00.01 │  │  ├─ ssh
+19440 yoh        30  10  508M 21084 14748 S  0.0  0.1  0:00.00 │  │  ├─ /usr/bin/git-annex remotedaemon
+ 3222 yoh        30  10 27368  5796  3456 S  0.0  0.0  0:00.00 │  │  ├─ git --git-dir=.git --work-tree=. cat-file --batch
+ 3110 yoh        30  10  508M 21084 14748 R 97.5  0.1  1h29:10 │  │  ├─ /usr/bin/git-annex remotedaemon
+ 3090 yoh        30  10  508M 21084 14748 S  0.0  0.1  0:00.98 │  │  ├─ /usr/bin/git-annex remotedaemon
+ 3089 yoh        30  10  508M 21084 14748 S  0.0  0.1  0:00.03 │  │  └─ /usr/bin/git-annex remotedaemon
+"""]]
+
+how could I figure out what is doing??? meanwhile I have just sent STOP signal to 3087
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150327+git27-g6af24b6-1
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/annex_sync_silently_resets_master_to_previous_sync.mdwn b/doc/bugs/annex_sync_silently_resets_master_to_previous_sync.mdwn
new file mode 100644
index 0000000000..9c088c90c2
--- /dev/null
+++ b/doc/bugs/annex_sync_silently_resets_master_to_previous_sync.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+
+Familiarizing myself more with adjusted branches mode and might be doing smth wrong.  But in this http://www.oneukrainian.com/tmp/case-20230630.tgz case I observe that `annex sync` simply updates `master` to some prior state, thus possibly silently causing a data loss for me if I don't spot it:
+
+```
+❯ tar -xzf case-20230630.tgz
+❯ cd case
+content.html@  datasets.datalad.org/  subfolder/
+❯ ( source ~/git-annexes/10.20230626+git13-g029d12815c.env; git annex version | head -n 1; git describe master; git checkout 'adjusted/master(unlocked)'; git annex sync ; git describe master; )
+git-annex version: 10.20230626+git13-g029d12815c-1~ndall+1
+0.0.0-2-gf34191a
+Switched to branch 'adjusted/master(unlocked)'
+git-annex sync will change default behavior to operate on --content in a future version of git-annex. Recommend you explicitly use --no-content (or -g) to prepare for that change. (Or you can configure annex.synccontent)
+commit  
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+ok
+0.0.0-1-gde710c5
+```
+
+PS investigation of adjusted/unlocked came up in ReproNim context where people wanted a "hard copy" of the fmriprep results without symlinks to simplify navigation of the results in the browser, which otherwise due to browser resolving symlinks makes it hard and require a workaround like starting a webserver [as we documented in dbic handbook](https://dbic-handbook.readthedocs.io/en/latest/datalad.html#how-to-view-mriqcfmriprepetc-dataladified-results-in-a-browser)
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/annex_sync_silently_resets_master_to_previous_sync/comment_1_84346dcb210b86e86bd474820bb5f494._comment b/doc/bugs/annex_sync_silently_resets_master_to_previous_sync/comment_1_84346dcb210b86e86bd474820bb5f494._comment
new file mode 100644
index 0000000000..e648393674
--- /dev/null
+++ b/doc/bugs/annex_sync_silently_resets_master_to_previous_sync/comment_1_84346dcb210b86e86bd474820bb5f494._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-05T19:49:19Z"
+ content="""
+Simplified test case:
+
+	git init tc
+	cd tc
+	git-annex init
+	echo 1 > foo
+	git-annex add
+	git commit -m add
+	git annex adjust --unlock
+	git checkout master
+	rm foo
+	echo 2 > foo
+	git-annex add
+	git commit -m "this commit will be lost"
+	git checkout 'adjusted/master(unlocked)'
+	git annex adjust --unlock  # or git-annex sync
+	git log master
+
+What an unfortunate oversight! And it's not a reversion, it's been there
+since the beginning of adjusted branches.
+
+git-annex adjust should display a warning message in that situation,
+since the original branch has diverged from the adjusted branch.
+
+And git-annex sync should be able to resolve the divergence by
+auto-merging the changes from the original branch into the adjusted
+branch.
+"""]]
diff --git a/doc/bugs/annex_sync_silently_resets_master_to_previous_sync/comment_2_c420c76e5aebb1339f4c478b4d56d5de._comment b/doc/bugs/annex_sync_silently_resets_master_to_previous_sync/comment_2_c420c76e5aebb1339f4c478b4d56d5de._comment
new file mode 100644
index 0000000000..280b9b318e
--- /dev/null
+++ b/doc/bugs/annex_sync_silently_resets_master_to_previous_sync/comment_2_c420c76e5aebb1339f4c478b4d56d5de._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-07-05T21:01:53Z"
+ content="""
+I've fixed the data loss part of this bug.
+
+`git-annex sync` is able to resolve the divergence too. But for some
+reason, the first time it's run after the divergence, it leaves it
+diverged, and the second time it resolves it. That needs to be fixed.
+"""]]
diff --git a/doc/bugs/annex_sync_silently_resets_master_to_previous_sync/comment_3_80d241b2654856669d82d1ab5de40c00._comment b/doc/bugs/annex_sync_silently_resets_master_to_previous_sync/comment_3_80d241b2654856669d82d1ab5de40c00._comment
new file mode 100644
index 0000000000..7fe0789c79
--- /dev/null
+++ b/doc/bugs/annex_sync_silently_resets_master_to_previous_sync/comment_3_80d241b2654856669d82d1ab5de40c00._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-07-06T16:16:36Z"
+ content="""
+Ok, fixed git-annex sync to immediately merge the changes from the original
+branch into the adjusted branch.
+"""]]
diff --git a/doc/bugs/annex_tries_to_start_old_binaray.mdwn b/doc/bugs/annex_tries_to_start_old_binaray.mdwn
new file mode 100644
index 0000000000..76f9350015
--- /dev/null
+++ b/doc/bugs/annex_tries_to_start_old_binaray.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+See the logs. git-annex-shell tries to use not existing runshell
+
+
+### What steps will reproduce the problem?
+I am on Debian testing and have, some month ago, tried the tarball distribution.
+I have returned to deb packages later and  deleted the tarball installation. 
+Seems that there some traces left.  
+
+I have tried to find the runshell configuration, but failed to do so.
+
+I have destroyed the repo completely, has not helped.
+
+### What version of git-annex are you using? On what operating system?
+ii  git-annex      5.20140831   amd64      
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+[2014-09-07 17:15:04 CEST] main: starting assistant version 5.20140831
+[2014-09-07 17:15:04 CEST] Cronner: Consistency check in progress
+/home/<user>/.ssh/git-annex-shell: 4: exec: /home/<user>/git-annex.linux.5.20131213/runshell: not found
+/home/<user>/.ssh/git-annex-shell: 4: exec: /home/<user>/git-annex.linux.5.20131213/runshell: not found
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+/home/<user>/.ssh/git-annex-shell: 4: exec: /home/<user>/git-annex.linux.5.20131213/runshell: not found
+/home/<user>/.ssh/git-annex-shell: 4: exec: /home/<user>/git-annex.linux.5.20131213/runshell: not found
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+/home/<user>/.ssh/git-annex-shell: 4: exec: /home/<user>/git-annex.linux.5.20131213/runshell: not found
+(scanning...) [2014-09-07 17:16:47 CEST] Watcher: Performing startup scan
+/home/<user>/.ssh/git-annex-shell: 4: exec: /home/<user>/git-annex.linux.5.20131213/runshell: not found
+/home/<user>/.ssh/git-annex-shell: 4: exec: /home/<user>/git-annex.linux.5.2013121/
+/home/<user>/.ssh/git-annex-shell: 4: exec: /home/<user>/git-annex.linux.5.20131213/runshell: not found
+/home/<user>/.ssh/git-annex-shell: 4: exec: /home/<user>/git-annex.linux.5.20131213/runshell: not found
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/annex_tries_to_start_old_binaray/comment_1_209c36b737a48a6136eeb85d1f3d01b3._comment b/doc/bugs/annex_tries_to_start_old_binaray/comment_1_209c36b737a48a6136eeb85d1f3d01b3._comment
new file mode 100644
index 0000000000..753b9a9980
--- /dev/null
+++ b/doc/bugs/annex_tries_to_start_old_binaray/comment_1_209c36b737a48a6136eeb85d1f3d01b3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.132"
+ subject="comment 1"
+ date="2014-09-11T17:55:28Z"
+ content="""
+~/.ssh/git-annex-shell is a wrapper script that gets installed when you use the standalone build. You can delete it and your problem will be fixed.
+
+It would probably be good if the standalone build came with an uninstallation script.
+"""]]
diff --git a/doc/bugs/annex_unannex__47__uninit_should_handle_copies.mdwn b/doc/bugs/annex_unannex__47__uninit_should_handle_copies.mdwn
new file mode 100644
index 0000000000..e830f11564
--- /dev/null
+++ b/doc/bugs/annex_unannex__47__uninit_should_handle_copies.mdwn
@@ -0,0 +1,20 @@
+Just starting using v3, even more awesome, thanks!
+
+With git-annex, I take the habit to do copies of files without restriction, as they end up into (cheap) symlink copies.
+However, if 2 copies are unannexed, only one is restored, the other becomes a broken symlink, so I kind of loose some information 
+(my use case: I have a repo on which I recently started using annex, but most of the files, which i would want to be annexed, are only in git,
+so my plan is to unninit this repo, delete the .git dir, and then annex everything, as I don't mind the history).
+
+Rafaël
+
+> The only way for git-annex to support this in its current state would be
+> for the unannex command to copy the file content from the annex, rather
+> than moving it out. Then multiple links to the same content could be
+> unannexed.
+> 
+> But, this would be slower, and would depend on a later `unused` and
+> `dropunused` to actually remove the content. While doable, by use case
+> for unannex is more to quickly undo a mistaken add, and it's unlikely there
+> are multiple symlinks to the same content in this situation. --[[Joey]] 
+
+[[!tag done]]
diff --git a/doc/bugs/annex_unannex__47__uninit_should_handle_copies/comment_1_c896ff6589f62178b60e606771e4f2bf._comment b/doc/bugs/annex_unannex__47__uninit_should_handle_copies/comment_1_c896ff6589f62178b60e606771e4f2bf._comment
new file mode 100644
index 0000000000..839992477a
--- /dev/null
+++ b/doc/bugs/annex_unannex__47__uninit_should_handle_copies/comment_1_c896ff6589f62178b60e606771e4f2bf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"
+ nickname="Rafaël"
+ subject="comment 1"
+ date="2011-07-04T16:57:25Z"
+ content="""
+You convince me for unannex, but isn't the goal of uninit to revert all annex operations? In the current state, a clean revert is not possible (because of the broken symlinks after uninit). Instead of copying, using hard links is out of question?
+
+For my needs, is the command \"git annex unlock .\" (from the root of the repo) a correct workaround?
+"""]]
diff --git a/doc/bugs/annex_unannex__47__uninit_should_handle_copies/comment_2_9249609f83f8e9c7521cd2f007c1a39e._comment b/doc/bugs/annex_unannex__47__uninit_should_handle_copies/comment_2_9249609f83f8e9c7521cd2f007c1a39e._comment
new file mode 100644
index 0000000000..21c0c449b0
--- /dev/null
+++ b/doc/bugs/annex_unannex__47__uninit_should_handle_copies/comment_2_9249609f83f8e9c7521cd2f007c1a39e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmJfIszzreLNvCqzqzvTayA9_9L6gb9RtY"
+ nickname="Joey"
+ subject="comment 2"
+ date="2011-07-04T20:25:38Z"
+ content="""
+Indeed, uninit needed to be improved. I've done so. Also, unannex --fast can be used to make hard links to content left in the annex.
+"""]]
diff --git a/doc/bugs/apparent_hang_in_git-annex-smudge.mdwn b/doc/bugs/apparent_hang_in_git-annex-smudge.mdwn
new file mode 100644
index 0000000000..be174cebb9
--- /dev/null
+++ b/doc/bugs/apparent_hang_in_git-annex-smudge.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+
+I have a repository that I assume is somehow broken, in which `git status` hangs indefinitely. Investigating the process tree, the `git status` has spawned a `git-annex smudge` call, which itself has spawned various `git` calls, all of which are unresponsive after multiple days.
+
+### What steps will reproduce the problem?
+
+1. Have this particular weirdly broken repository of mine
+2. Run `git status`
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 10.20230407
+build flags: Assistant Webapp Pairing Kqueue DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.2.8 http-client-0.7.13.1 persistent-sqlite-2.13.1.1 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: freebsd x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+```
+
+Running on FreeBSD 13.2
+
+### Please provide any additional information below
+
+I have an `strace` (really BSD `truss`) of the parent process running. This process is just spinning in a loop responding to SIGALRM, I assume because it's waiting on the unresponsive child process.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I use git-annex extensively and find it indispensable.
diff --git a/doc/bugs/apparent_hang_in_git-annex-smudge/comment_1_80e24b74572d50f648d8aaae228b8827._comment b/doc/bugs/apparent_hang_in_git-annex-smudge/comment_1_80e24b74572d50f648d8aaae228b8827._comment
new file mode 100644
index 0000000000..34d078db18
--- /dev/null
+++ b/doc/bugs/apparent_hang_in_git-annex-smudge/comment_1_80e24b74572d50f648d8aaae228b8827._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-21T19:04:05Z"
+ content="""
+Suggest you truss the `git-annex smudge` process and see what it's stuck
+on. Looking at what file descriptors it has open would also be useful.
+
+Unless you have prevented git-annex from upgrading your repository from
+annex.version 8, it would normally have `filter.annex.process` configured,
+and so `git status` would normally run `git-annex filter-process` rather
+than `git annex smudge`.
+
+So I suppose you either have an old repository version or have manually
+unset `filter.annex.process`. Which it is seems like relevant information
+to try to reproduce this.
+
+Closest I can come to this bug is the deadlock that was fixed
+by [[!commit d5451afc8f90832a58e78b17cfc461c24e417d52]] in 2020..
+"""]]
diff --git a/doc/bugs/aria2c_display_broken_in_git-annex.mdwn b/doc/bugs/aria2c_display_broken_in_git-annex.mdwn
new file mode 100644
index 0000000000..c08fdeba0b
--- /dev/null
+++ b/doc/bugs/aria2c_display_broken_in_git-annex.mdwn
@@ -0,0 +1,147 @@
+[[!meta title="aria2c output very verbose (non-console mode)"]]
+[[!tag confirmed]]
+
+### Please describe the problem.
+
+Instead of displaying what are probably carriage returns, git-annex strips those out and outputs a *lot* of lines when downloading stuff through aria2c. On small downloads, it's not a big deal, but on large downloads it can flood the screen pretty badly.
+
+### What steps will reproduce the problem?
+
+Just download a torrent with git-annex.
+
+### What version of git-annex are you using? On what operating system?
+
+`5.20150205-gbf9058a` on current debian jessie.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+anarcat@marcos:iso(master +)$ /srv/downloads.kitenet.net/git-annex/linux/current/git-annex.linux/git-annex addurl http://images.kali.org/kali-linux-1.1.0-amd64.torrent
+(downloading torrent file...)
+--2015-02-09 22:12:51--  http://images.kali.org/kali-linux-1.1.0-amd64.torrent
+Résolution de images.kali.org (images.kali.org)… 50.7.37.130
+Connexion à images.kali.org (images.kali.org)|50.7.37.130|:80… connecté.
+requête HTTP transmise, en attente de la réponse… 200 OK
+Taille : 233152 (228K) [application/octet-stream]
+Sauvegarde en : « ../.git/annex/misctmp/torrent32659 »
+
+100%[=====================================================================================================================================================================================================>] 233 152      610KB/s   ds 0,4s
+
+2015-02-09 22:12:52 (610 KB/s) — « ../.git/annex/misctmp/torrent32659 » sauvegardé [233152/233152]
+
+addurl images.kali.org_kali_linux_1.1.0_amd64.torrent/kali_linux_1.1.0_amd64.iso (from bittorrent)
+
+
+02/09 22:12:52 [NOTICE] IPv4 DHT: listening on UDP port 6940
+
+02/09 22:12:52 [ERROR] Erreur d'intégrité détectée. fichier=../.git/annex/misctmp/URL--http&c%%images.kali.org%kali-linux-1.1.0-amd64.torrent/kali-linux-1.1.0-amd64
+
+02/09 22:12:52 [NOTICE] IPv4 BitTorrent: listening on TCP port 6923
+
+02/09 22:12:52 [NOTICE] IPv6 BitTorrent: listening on TCP port 6923
+[#066a28 0B/2.8GiB(0%) CN:0 SD:0 DL:0B]
+[#066a28 0B/2.8GiB(0%) CN:44 SD:0 DL:0B]
+[#066a28 0B/2.8GiB(0%) CN:44 SD:0 DL:0B]
+[#066a28 0B/2.8GiB(0%) CN:44 SD:1 DL:0B]
+[#066a28 0B/2.8GiB(0%) CN:44 SD:2 DL:0B]
+[#066a28 16KiB/2.8GiB(0%) CN:44 SD:2 DL:11KiB ETA:72h44m54s]
+[#066a28 32KiB/2.8GiB(0%) CN:44 SD:4 DL:11KiB ETA:72h55m47s]
+[#066a28 48KiB/2.8GiB(0%) CN:44 SD:5 DL:10KiB ETA:79h7m17s]
+[#066a28 64KiB/2.8GiB(0%) CN:49 SD:6 DL:10KiB ETA:77h27m]
+[#066a28 96KiB/2.8GiB(0%) CN:47 SD:6 DL:13KiB ETA:60h20m41s]
+[#066a28 160KiB/2.8GiB(0%) CN:45 SD:6 DL:20KiB ETA:41h20m43s]
+[#066a28 304KiB/2.8GiB(0%) CN:45 SD:6 DL:33KiB ETA:24h28m29s]
+[#066a28 384KiB/2.8GiB(0%) CN:45 SD:6 DL:38KiB ETA:21h34m21s]
+[#066a28 416KiB/2.8GiB(0%) CN:44 SD:6 DL:37KiB ETA:21h54m17s]
+[#066a28 512KiB/2.8GiB(0%) CN:44 SD:6 DL:42KiB ETA:19h26m19s]
+[#066a28 544KiB/2.8GiB(0%) CN:44 SD:6 DL:41KiB ETA:19h48m32s]
+[#066a28 624KiB/2.8GiB(0%) CN:44 SD:6 DL:44KiB ETA:18h38m8s]
+[#066a28 720KiB/2.8GiB(0%) CN:44 SD:6 DL:52KiB ETA:15h42m33s]
+[#066a28 736KiB/2.8GiB(0%) CN:44 SD:6 DL:50KiB ETA:16h30m42s]
+[#066a28 768KiB/2.8GiB(0%) CN:44 SD:7 DL:52KiB ETA:15h42m44s]
+[#066a28 896KiB/2.8GiB(0%) CN:44 SD:7 DL:57KiB ETA:14h20m4s]
+[#066a28 1.0MiB/2.8GiB(0%) CN:44 SD:7 DL:69KiB ETA:11h58m54s]
+[#066a28 1.1MiB/2.8GiB(0%) CN:44 SD:7 DL:79KiB ETA:10h21m22s]
+[#066a28 1.2MiB/2.8GiB(0%) CN:44 SD:7 DL:87KiB ETA:9h24m15s]
+[#066a28 1.4MiB/2.8GiB(0%) CN:44 SD:6 DL:90KiB ETA:9h8m26s]
+[#066a28 1.4MiB/2.8GiB(0%) CN:44 SD:6 DL:88KiB ETA:9h23m40s]
+[#066a28 1.5MiB/2.8GiB(0%) CN:44 SD:6 DL:85KiB ETA:9h41m21s]
+[#066a28 1.6MiB/2.8GiB(0%) CN:44 SD:6 DL:89KiB ETA:9h12m17s]
+[#066a28 1.6MiB/2.8GiB(0%) CN:44 SD:6 DL:86KiB ETA:9h32m9s]
+[#066a28 1.7MiB/2.8GiB(0%) CN:44 SD:6 DL:85KiB UL:451KiB(288KiB) ETA:9h37m58s]
+[#066a28 1.8MiB/2.8GiB(0%) CN:44 SD:6 DL:89KiB UL:168KiB(288KiB) ETA:9h16m53s]
+[#066a28 1.8MiB/2.8GiB(0%) CN:44 SD:6 DL:84KiB UL:105KiB(288KiB) ETA:9h47m6s]
+[#066a28 1.8MiB/2.8GiB(0%) CN:44 SD:6 DL:89KiB UL:76KiB(288KiB) ETA:9h16m44s]
+[#066a28 1.9MiB/2.8GiB(0%) CN:44 SD:7 DL:85KiB UL:59KiB(288KiB) ETA:9h36m53s]
+[#066a28 1.9MiB/2.8GiB(0%) CN:44 SD:7 DL:79KiB UL:49KiB(288KiB) ETA:10h24m56s]
+[#066a28 2.1MiB/2.8GiB(0%) CN:44 SD:7 DL:80KiB UL:42KiB(288KiB) ETA:10h15m19s]
+[#066a28 2.2MiB/2.8GiB(0%) CN:44 SD:7 DL:75KiB UL:68KiB(544KiB) ETA:10h56m]
+[#066a28 2.3MiB/2.8GiB(0%) CN:44 SD:7 DL:75KiB UL:60KiB(544KiB) ETA:10h54m12s]
+[#066a28 2.4MiB/2.8GiB(0%) CN:44 SD:7 DL:70KiB UL:54KiB(544KiB) ETA:11h39m51s]
+[#066a28 2.4MiB/2.8GiB(0%) CN:44 SD:7 DL:71KiB UL:49KiB(544KiB) ETA:11h29m45s]
+[#066a28 2.6MiB/2.8GiB(0%) CN:44 SD:7 DL:74KiB UL:44KiB(544KiB) ETA:11h1m53s]
+[#066a28 2.6MiB/2.8GiB(0%) CN:44 SD:7 DL:73KiB UL:41KiB(544KiB) ETA:11h14m27s]
+[#066a28 2.7MiB/2.8GiB(0%) CN:44 SD:7 DL:76KiB UL:38KiB(544KiB) ETA:10h52m4s]
+[#066a28 2.7MiB/2.8GiB(0%) CN:44 SD:7 DL:73KiB UL:19KiB(544KiB) ETA:11h18m54s]
+[#066a28 2.8MiB/2.8GiB(0%) CN:44 SD:7 DL:78KiB UL:27KiB(544KiB) ETA:10h31m16s]
+[#066a28 2.9MiB/2.8GiB(0%) CN:44 SD:7 DL:74KiB UL:25KiB(544KiB) ETA:11h7m40s]
+[#066a28 2.9MiB/2.8GiB(0%) CN:44 SD:7 DL:72KiB UL:22KiB(544KiB) ETA:11h22m19s]
+[#066a28 3.0MiB/2.8GiB(0%) CN:44 SD:7 DL:77KiB UL:41KiB(800KiB) ETA:10h42m53s]
+[#066a28 3.0MiB/2.8GiB(0%) CN:44 SD:7 DL:79KiB UL:38KiB(800KiB) ETA:10h24m56s]
+[#066a28 3.2MiB/2.8GiB(0%) CN:44 SD:7 DL:82KiB UL:35KiB(800KiB) ETA:10h4m14s]
+[#066a28 3.2MiB/2.8GiB(0%) CN:44 SD:7 DL:76KiB UL:72KiB(800KiB) ETA:10h44m14s]
+[#066a28 3.2MiB/2.8GiB(0%) CN:44 SD:7 DL:69KiB UL:113KiB(1.0MiB) ETA:11h48m20s]
+[#066a28 3.3MiB/2.8GiB(0%) CN:44 SD:8 DL:69KiB UL:92KiB(1.0MiB) ETA:11h54m37s]
+[#066a28 3.4MiB/2.8GiB(0%) CN:44 SD:8 DL:73KiB UL:78KiB(1.0MiB) ETA:11h17m38s]
+[#066a28 3.6MiB/2.8GiB(0%) CN:44 SD:8 DL:78KiB UL:67KiB(1.0MiB) ETA:10h27m51s]
+[#066a28 3.7MiB/2.8GiB(0%) CN:44 SD:9 DL:76KiB UL:59KiB(1.0MiB) ETA:10h46m10s]
+[#066a28 3.7MiB/2.8GiB(0%) CN:44 SD:9 DL:72KiB UL:53KiB(1.0MiB) ETA:11h21m24s]
+[#066a28 3.8MiB/2.8GiB(0%) CN:44 SD:10 DL:75KiB UL:72KiB(1.2MiB) ETA:10h55m4s]
+[#066a28 3.9MiB/2.8GiB(0%) CN:44 SD:10 DL:74KiB UL:66KiB(1.2MiB) ETA:11h9m6s]
+[#066a28 4.0MiB/2.8GiB(0%) CN:44 SD:10 DL:80KiB UL:62KiB(1.3MiB) ETA:10h12m8s]
+[#066a28 4.1MiB/2.8GiB(0%) CN:44 SD:10 DL:84KiB UL:58KiB(1.3MiB) ETA:9h45m9s]
+[#066a28 4.2MiB/2.8GiB(0%) CN:44 SD:9 DL:88KiB UL:54KiB(1.3MiB) ETA:9h17m20s]
+[#066a28 4.2MiB/2.8GiB(0%) CN:44 SD:9 DL:83KiB UL:46KiB(1.3MiB) ETA:9h53m47s]
+[#066a28 4.3MiB/2.8GiB(0%) CN:44 SD:8 DL:75KiB UL:42KiB(1.3MiB) ETA:10h55m25s]
+[#066a28 4.4MiB/2.8GiB(0%) CN:44 SD:8 DL:82KiB UL:39KiB(1.3MiB) ETA:10h3m52s]
+[#066a28 4.4MiB/2.8GiB(0%) CN:44 SD:7 DL:80KiB UL:36KiB(1.3MiB) ETA:10h18m43s]
+[#066a28 4.4MiB/2.8GiB(0%) CN:44 SD:7 DL:76KiB UL:53KiB(1.5MiB) ETA:10h49m36s]
+[#066a28 4.4MiB/2.8GiB(0%) CN:44 SD:7 DL:66KiB UL:48KiB(1.5MiB) ETA:12h22m22s]
+[#066a28 4.5MiB/2.8GiB(0%) CN:44 SD:7 DL:57KiB UL:43KiB(1.5MiB) ETA:14h27m44s]
+[#066a28 4.5MiB/2.8GiB(0%) CN:44 SD:7 DL:55KiB UL:39KiB(1.5MiB) ETA:14h52m9s]
+[#066a28 4.5MiB/2.8GiB(0%) CN:44 SD:8 DL:52KiB UL:37KiB(1.5MiB) ETA:15h48m10s]
+[#066a28 4.6MiB/2.8GiB(0%) CN:44 SD:8 DL:50KiB UL:21KiB(1.5MiB) ETA:16h13m54s]
+[#066a28 4.6MiB/2.8GiB(0%) CN:44 SD:9 DL:42KiB UL:30KiB(1.5MiB) ETA:19h24m47s]
+[#066a28 4.6MiB/2.8GiB(0%) CN:44 SD:9 DL:41KiB UL:53KiB(1.8MiB) ETA:19h44m57s]
+[#066a28 4.7MiB/2.8GiB(0%) CN:44 SD:9 DL:32KiB UL:48KiB(1.8MiB) ETA:25h20m56s]
+[#066a28 4.7MiB/2.8GiB(0%) CN:44 SD:10 DL:38KiB UL:44KiB(1.8MiB) ETA:21h24m33s]
+[#066a28 4.8MiB/2.8GiB(0%) CN:44 SD:10 DL:34KiB UL:40KiB(1.8MiB) ETA:23h45m37s]
+[#066a28 4.8MiB/2.8GiB(0%) CN:48 SD:10 DL:31KiB UL:56KiB(2.0MiB) ETA:26h11m56s]
+[#066a28 4.8MiB/2.8GiB(0%) CN:46 SD:10 DL:30KiB UL:52KiB(2.0MiB) ETA:27h15m40s]
+[#066a28 4.9MiB/2.8GiB(0%) CN:44 SD:10 DL:32KiB UL:75KiB(2.0MiB) ETA:25h13m45s]
+[#066a28 4.9MiB/2.8GiB(0%) CN:44 SD:10 DL:36KiB UL:66KiB(2.0MiB) ETA:22h32m9s]
+[#066a28 4.9MiB/2.8GiB(0%) CN:44 SD:10 DL:35KiB UL:61KiB(2.0MiB) ETA:23h9m10s]
+[#066a28 5.0MiB/2.8GiB(0%) CN:44 SD:9 DL:36KiB UL:80KiB(2.3MiB) ETA:22h43m56s]
+[#066a28 5.0MiB/2.8GiB(0%) CN:44 SD:9 DL:35KiB UL:69KiB(2.3MiB) ETA:23h6m29s]
+[#066a28 5.1MiB/2.8GiB(0%) CN:44 SD:10 DL:37KiB UL:62KiB(2.3MiB) ETA:21h58m37s]
+[#066a28 5.1MiB/2.8GiB(0%) CN:44 SD:10 DL:38KiB UL:58KiB(2.3MiB) ETA:21h19m1s]
+[#066a28 5.1MiB/2.8GiB(0%) CN:49 SD:12 DL:35KiB UL:55KiB(2.3MiB) ETA:23h3s]
+[#066a28 5.2MiB/2.8GiB(0%) CN:48 SD:11 DL:38KiB UL:48KiB(2.3MiB) ETA:21h41m12s]
+[#066a28 5.2MiB/2.8GiB(0%) CN:45 SD:11 DL:32KiB UL:64KiB(2.6MiB) ETA:25h8m51s]
+[#066a28 5.2MiB/2.8GiB(0%) CN:44 SD:12 DL:32KiB UL:59KiB(2.6MiB) ETA:25h17m48s]
+^C
+anarcat@marcos:iso(master +%)$ aria2c kali-linux-1.1.0-amd64.torrent
+
+02/09 22:17:16 [NOTICE] IPv4 DHT: listening on UDP port 6963
+
+02/09 22:17:16 [NOTICE] IPv4 BitTorrent: listening on TCP port 6950
+
+02/09 22:17:16 [NOTICE] IPv6 BitTorrent: listening on TCP port 6950
+[#51d0f6 5.2MiB/2.8GiB(0%) CN:44 SD:12 DL:241KiB ETA:3h25m7s]
+
+# End of transcript or log.
+"""]]
+
+Could be caused by [[bittorrent_special_url_double-encoding]]? --[[anarcat]]
diff --git a/doc/bugs/aria2c_display_broken_in_git-annex/comment_1_770e1d657bba2a3f5782eac2e8bdca57._comment b/doc/bugs/aria2c_display_broken_in_git-annex/comment_1_770e1d657bba2a3f5782eac2e8bdca57._comment
new file mode 100644
index 0000000000..2fe9bf475b
--- /dev/null
+++ b/doc/bugs/aria2c_display_broken_in_git-annex/comment_1_770e1d657bba2a3f5782eac2e8bdca57._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-10T16:11:09Z"
+ content="""
+This is because aria2c detects it's not outputting to a terminal, so it
+stops using \r for progress displays. You can get the same effect by piping
+aria2c to less. There does not seem to be any switch to force console-style
+output.
+
+The only solution would be the complexity of making git-annex use a pty
+internally, or just not showing aria2c progress output (or not intercepting
+it for metering).
+"""]]
diff --git a/doc/bugs/aria2c_display_broken_in_git-annex/comment_2_2f26037c5a67f6f8928204ab0b7b7965._comment b/doc/bugs/aria2c_display_broken_in_git-annex/comment_2_2f26037c5a67f6f8928204ab0b7b7965._comment
new file mode 100644
index 0000000000..4f12f3681f
--- /dev/null
+++ b/doc/bugs/aria2c_display_broken_in_git-annex/comment_2_2f26037c5a67f6f8928204ab0b7b7965._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 2"
+ date="2015-02-10T17:22:08Z"
+ content="""
+maybe adding `\r` chars ourselves would fix it?
+"""]]
diff --git a/doc/bugs/assistant_--autostop_stops_after_nonexistant_repo.mdwn b/doc/bugs/assistant_--autostop_stops_after_nonexistant_repo.mdwn
new file mode 100644
index 0000000000..712a8057cf
--- /dev/null
+++ b/doc/bugs/assistant_--autostop_stops_after_nonexistant_repo.mdwn
@@ -0,0 +1,25 @@
+### Please describe the problem.
+
+`git annex assistant --autostop` stops shutting down processes after encountering the first non-existant repo listed in `.config/git-annex/autostart`, leaving other processes running.
+
+### What steps will reproduce the problem?
+
+- add several existing repos to `.config/git-annex/autostart`
+- somewhere in the middle, add a non-existant path
+- run `git annex assistant --autostart` (this just skips the nonexistant repo interestingly)
+- run `git annex assistant --autostop` (this fails on the nonexistant repo and doesn't continue with the others)
+
+### What version of git-annex are you using? On what operating system?
+
+```
+# on Linux
+❯ git annex version                                                                                                             
+git-annex version: 10.20230329-ge6a337e8e
+```
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I love it! 🤩
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/assistant___40__webapp__41___commited_unlocked_link_to_annex.mdwn b/doc/bugs/assistant___40__webapp__41___commited_unlocked_link_to_annex.mdwn
new file mode 100644
index 0000000000..1b084030c1
--- /dev/null
+++ b/doc/bugs/assistant___40__webapp__41___commited_unlocked_link_to_annex.mdwn
@@ -0,0 +1,106 @@
+### Please describe the problem.
+
+Today I noticed odd commits happening such as
+
+```
+❯ git show 4a157861f3d27a40b38ae441dfe306e45e448c66
+commit 4a157861f3d27a40b38ae441dfe306e45e448c66
+Author: ReproStim User <changeme@example.com>
+Date:   Wed Apr 17 09:22:04 2024 -0400
+
+    git-annex in reprostim@reproiner:/data/reprostim
+
+diff --git a/Videos/2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log b/Videos/2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log
+index fc930f54..92b79020 100644
+--- a/Videos/2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log
++++ b/Videos/2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log
+@@ -1 +1 @@
+-/annex/objects/MD5E-s68799--29541299bea3691f430d855d2fb432fb.mkv.log
++/annex/objects/MD5E-s69--08983cc11522233e5d4815e4ef62275a.mkv.log
+```
+
+-- today is April but commits are for files in March... 
+
+There is `git annex webapp` running which is configured to offload all content to another host.
+
+And actual patch shows that it pretty much annexed the "unlocked link" file after the file was offloaded to remote host.
+
+
+Do not have a minimal reproducer yet, but I think it happened while
+
+- I had initially .log files which are text going to git
+- then I added to `.gitattributes` 
+
+```
+*.log annex.largefiles=anything
+```
+
+but it was never committed (? I assumed that annex webapp/assistant would do that -- it didn't) -- only now I did that.  
+- not sure how this morning was special...
+
+The most interesting is that if I `annex get` -- I do get correct file...
+
+It is like an inception!!!
+
+On the fresh clone, if I look inside that file I see short key:
+
+```
+❯ cat 2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log
+/annex/objects/MD5E-s69--08983cc11522233e5d4815e4ef62275a.mkv.log
+```
+
+then, if I `annex get` it -- I get content with long key
+
+```shell
+❯ git annex get 2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log
+get 2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log (from rolando...) 
+ok                                
+(recording state in git...)
+❯ cat 2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log
+/annex/objects/MD5E-s68799--29541299bea3691f430d855d2fb432fb.mkv.log
+```
+
+then upon subsequent get -- I will get the actual content:
+
+```shell
+❯ git annex get 2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log
+get 2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log (from rolando...) 
+ok                                
+(recording state in git...)
+❯ head -n 1 2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log
+2024-03-17 14:09:12.551 [info] [685899] Session logging begin   : reprostim-videocapture 1.5.0.119, session_logger_2024.03.17.14.09.12.550, start_ts=2024.03.17.14.09.12.550
+```
+and dropping it would lead me just to the "long key"
+
+```
+❯ git annex drop 2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log
+drop 2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log (locking rolando...) ok
+(recording state in git...)
+❯ cat 2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log
+/annex/objects/MD5E-s68799--29541299bea3691f430d855d2fb432fb.mkv.log
+```
+
+and will not be able to come out into reality from the 2nd level of inception:
+
+```
+❯ git annex drop 2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log
+❯ cat 2024.03.17.14.09.12.550_2024.03.17.14.09.18.818.mkv.log
+/annex/objects/MD5E-s68799--29541299bea3691f430d855d2fb432fb.mkv.log
+```
+
+
+### What version of git-annex are you using? On what operating system?
+
+on original server with webapp:  10.20240227-1~ndall+1
+
+on intermediate server through which transfer of files happens: I think it might be old 
+
+```
+[bids@rolando VIDS] > git annex version
+git-annex version: 6.20180808-ga1327779a
+```
+
+on laptop where I dive into inception: 10.20240129
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
diff --git a/doc/bugs/assistant_bails_when_adding_encrypted_usbdrive_repo_on_mac.mdwn b/doc/bugs/assistant_bails_when_adding_encrypted_usbdrive_repo_on_mac.mdwn
new file mode 100644
index 0000000000..23babd7975
--- /dev/null
+++ b/doc/bugs/assistant_bails_when_adding_encrypted_usbdrive_repo_on_mac.mdwn
@@ -0,0 +1,53 @@
+### Please describe the problem.
+Tried adding a removable drive repository through git-annex assistant on Mac, asked to encrypt it, got Internal server error with explanation: unable to determine gcrypt-id of remote
+
+### What steps will reproduce the problem?
+current (today's) version of git-annex build for Mountain Lion installed
+app launched
+default annex initialized, a couple file added
+a removable 2GB USB drive (ExFAT) mounted in OS
+click Add another repository
+choose removable drive
+choose to encrypt
+a window explaining the need to wait for entropy shows
+then we get the Internal server error: unable to determine gcrypt-id of remote
+
+### What version of git-annex are you using? On what operating system?
+git-annex version 4.20130922-g7dc188a
+Mac OS X 10.8.5
+
+### Please provide any additional information below.
+
+looking at transcript below, it appears the root cause is the lack of initial git/gcrypt configuration. perhaps this needs to be caught/addressed somehow
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+gpg: can't open `/usr/local/share/gnupg/options.skel': No such file or directory
+.......+++++
+.+++++
+gpg: key 71BFBC31 marked as ultimately trusted
+ok
+(Recording state in git...)
+(Recording state in git...)
+(encryption setup) (hybrid cipher with gpg key C4B2EA8D71BFBC31) gcrypt: Development version -- Repository format MAY CHANGE
+gpg: checking the trustdb
+gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
+gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
+gcrypt: WARNING: Skipping missing key C4B2EA8D71BFBC31
+gcrypt: You have not configured any keys you can encrypt to for this repository
+gcrypt: Use ::
+gcrypt:   git config gcrypt.participants YOURKEYID
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: WARNING: Skipping missing key C4B2EA8D71BFBC31
+gcrypt: You have not configured any keys you can encrypt to for this repository
+gcrypt: Use ::
+gcrypt:   git config gcrypt.participants YOURKEYID
+03/Oct/2013:00:05:24 +0400 [Error#yesod-core] unable to determine gcrypt-id of remote @(yesod-core-1.1.8.3:Yesod.Internal.Core ./Yesod/Internal/Core.hs:550:5)
+
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/assistant_bails_when_adding_encrypted_usbdrive_repo_on_mac/comment_1_4ea192e57f86a33087997746722e6acf._comment b/doc/bugs/assistant_bails_when_adding_encrypted_usbdrive_repo_on_mac/comment_1_4ea192e57f86a33087997746722e6acf._comment
new file mode 100644
index 0000000000..2d0802cae7
--- /dev/null
+++ b/doc/bugs/assistant_bails_when_adding_encrypted_usbdrive_repo_on_mac/comment_1_4ea192e57f86a33087997746722e6acf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2013-10-02T20:37:03Z"
+ content="""
+Can you take a look at ~/annex/.git/config and if there is an entry for this git remote, post it? (Or post the whole thing if unsure..)
+
+Also, can you get gpg to list your secret keys, and see if key 71BFBC31 is in the list? You can do so by running `gpg --list-secret-keys` ; if you don't have gpg in your path at the terminal, you can use the version from the git-annex DMG by first running `/Volumes/git-annex/git-annex.app/Contents/MacOS/runshell`
+"""]]
diff --git a/doc/bugs/assistant_bails_when_adding_encrypted_usbdrive_repo_on_mac/comment_2_622ad5b34780fc8468c5c515ad9f27fa._comment b/doc/bugs/assistant_bails_when_adding_encrypted_usbdrive_repo_on_mac/comment_2_622ad5b34780fc8468c5c515ad9f27fa._comment
new file mode 100644
index 0000000000..2ba7a59845
--- /dev/null
+++ b/doc/bugs/assistant_bails_when_adding_encrypted_usbdrive_repo_on_mac/comment_2_622ad5b34780fc8468c5c515ad9f27fa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnyMzZZLS1xGW1raqc_9Md6Ksdkvx5rUJU"
+ nickname="Michael"
+ subject="comment 2"
+ date="2013-10-04T10:59:30Z"
+ content="""
+Sorry Joey, I was tinkering around trying to get the assistant off the ground and have destroyed the evidence of the bug in the process. I will try to recreate it and post the details. (most of my problems are/were related to bundled git/gpg/other software, I posted a separate comment in OSX Install page)
+"""]]
diff --git a/doc/bugs/assistant_cannot_sync_files_to_empty_indirect_repo.mdwn b/doc/bugs/assistant_cannot_sync_files_to_empty_indirect_repo.mdwn
new file mode 100644
index 0000000000..1193671c91
--- /dev/null
+++ b/doc/bugs/assistant_cannot_sync_files_to_empty_indirect_repo.mdwn
@@ -0,0 +1,281 @@
+### Please describe the problem.
+I create two new local repositories each a remote of each-other. I put both repos in autostart and then i autostart the assistant. I create a new file in repo1 it doesn't get transfered to repo2. Once I create a new file manually in repo2 now bi-directional transferring happens fine. Presumably assistant is not able to handle the case where the initial git commit has not yet happened in an indirect mode destination repo?
+
+I think this might be happening for repositories created from the webapp gui as well sometimes.
+
+
+### What steps will reproduce the problem?
+See log.
+
+### What version of git-annex are you using? On what operating system?
+7.20181106-g352f88226, macOS 10.12.6
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+andrew@bumblebee /Users/Shared$ git-annex version
+git-annex version: 7.20181106-g352f88226
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV FsEvents TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: darwin x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+andrew@bumblebee /Users/Shared$ mkdir repo1
+andrew@bumblebee /Users/Shared$ mkdir repo2
+andrew@bumblebee /Users/Shared$ cd repo1
+andrew@bumblebee /Users/Shared/repo1$ git init
+Initialized empty Git repository in /Users/Shared/repo1/.git/
+andrew@bumblebee /Users/Shared/repo1$ git annex init
+init  ok
+(recording state in git...)
+andrew@bumblebee /Users/Shared/repo1$ cd ../repo2
+andrew@bumblebee /Users/Shared/repo2$ git init
+Initialized empty Git repository in /Users/Shared/repo2/.git/
+andrew@bumblebee /Users/Shared/repo2$ git annex init
+init  ok
+(recording state in git...)
+andrew@bumblebee /Users/Shared/repo2$ git remote add /Users/Shared/repo1 repo1
+fatal: '/Users/Shared/repo1' is not a valid remote name
+andrew@bumblebee /Users/Shared/repo2$ git remote add repo1 /Users/Shared/repo1
+andrew@bumblebee /Users/Shared/repo2$ cd ../repo1
+andrew@bumblebee /Users/Shared/repo1$ git remote add repo2 /Users/Shared/repo2
+andrew@bumblebee /Users/Shared/repo1$ cat ~/.config/git-annex/autostart
+/Users/Shared/repo2
+/Users/Shared/repo1
+andrew@bumblebee /Users/Shared/repo1$ cd ..
+andrew@bumblebee /Users/Shared$ git-annex assistant --autostart
+git-annex autostart in /Users/Shared/repo2
+ok
+git-annex autostart in /Users/Shared/repo1
+ok
+andrew@bumblebee /Users/Shared$ cd repo1
+andrew@bumblebee /Users/Shared/repo1$ ls
+andrew@bumblebee /Users/Shared/repo1$ date
+Mon Nov 12 11:28:59 EST 2018
+andrew@bumblebee /Users/Shared/repo1$ touch a.txt
+andrew@bumblebee /Users/Shared/repo1$ git-annex whereis a.txt
+whereis a.txt (2 copies) 
+  	746bb051-e2c5-463b-8d4c-7d4eee6de855 -- andrew@bumblebee.local:/Users/Shared/repo1 [here]
+   	87af3666-1f63-4ad1-8a1e-a1d260c90751 -- andrew@bumblebee.local:/Users/Shared/repo2 [repo2]
+ok
+andrew@bumblebee /Users/Shared/repo1$ cd ../repo2
+andrew@bumblebee /Users/Shared/repo2$ date
+Mon Nov 12 11:29:27 EST 2018
+andrew@bumblebee /Users/Shared/repo2$ ls
+andrew@bumblebee /Users/Shared/repo2$ git-annex whereis a.txt
+git-annex: a.txt not found
+git-annex: whereis: 1 failed
+andrew@bumblebee /Users/Shared/repo2$ git status
+On branch master
+
+No commits yet
+
+nothing to commit (create/copy files and use "git add" to track)
+andrew@bumblebee /Users/Shared/repo2$ ls
+andrew@bumblebee /Users/Shared/repo2$ date
+Mon Nov 12 11:29:58 EST 2018
+andrew@bumblebee /Users/Shared/repo2$ ls
+andrew@bumblebee /Users/Shared/repo2$ touch b.txt
+andrew@bumblebee /Users/Shared/repo2$ ls
+b.txt
+andrew@bumblebee /Users/Shared/repo2$ ls
+a.txt	b.txt
+andrew@bumblebee /Users/Shared/repo2$ ls ../repo1/
+a.txt	b.txt
+andrew@bumblebee /Users/Shared/repo2$ git annex info
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 4
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	746bb051-e2c5-463b-8d4c-7d4eee6de855 -- andrew@bumblebee.local:/Users/Shared/repo1 [repo1]
+ 	87af3666-1f63-4ad1-8a1e-a1d260c90751 -- andrew@bumblebee.local:/Users/Shared/repo2 [here]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 39.71 gigabytes (+1 megabyte reserved)
+local annex keys: 1
+local annex size: 0 bytes
+annexed files in working tree: 2
+size of annexed files in working tree: 0 bytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+	SHA256E: 2
+andrew@bumblebee /Users/Shared/repo2$ cd ../repo1
+andrew@bumblebee /Users/Shared/repo1$ git annex info
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 4
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	746bb051-e2c5-463b-8d4c-7d4eee6de855 -- andrew@bumblebee.local:/Users/Shared/repo1 [here]
+ 	87af3666-1f63-4ad1-8a1e-a1d260c90751 -- andrew@bumblebee.local:/Users/Shared/repo2 [repo2]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 39.71 gigabytes (+1 megabyte reserved)
+local annex keys: 1
+local annex size: 0 bytes
+annexed files in working tree: 2
+size of annexed files in working tree: 0 bytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+	SHA256E: 2
+andrew@bumblebee /Users/Shared/repo1$ git annex status
+andrew@bumblebee /Users/Shared/repo1$ cat .git/config 
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+	ignorecase = true
+	precomposeunicode = true
+[annex]
+	uuid = 746bb051-e2c5-463b-8d4c-7d4eee6de855
+	version = 5
+[remote "repo2"]
+	url = /Users/Shared/repo2
+	fetch = +refs/heads/*:refs/remotes/repo2/*
+	annex-uuid = 87af3666-1f63-4ad1-8a1e-a1d260c90751
+andrew@bumblebee /Users/Shared/repo1$ cd ../repo2/
+andrew@bumblebee /Users/Shared/repo2$ cat .git/config 
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+	ignorecase = true
+	precomposeunicode = true
+[annex]
+	uuid = 87af3666-1f63-4ad1-8a1e-a1d260c90751
+	version = 5
+[remote "repo1"]
+	url = /Users/Shared/repo1
+	fetch = +refs/heads/*:refs/remotes/repo1/*
+	annex-uuid = 746bb051-e2c5-463b-8d4c-7d4eee6de855
+andrew@bumblebee /Users/Shared/repo2$ less .git/annex/daemon.log 
+andrew@bumblebee /Users/Shared/repo2$ cat .git/annex/daemon.log 
+[2018-11-12 11:28:49.465425] main: starting assistant version 7.20181106-g352f88226
+[2018-11-12 11:28:49.512513] Cronner: You should enable consistency checking to protect your data. 
+[2018-11-12 11:28:54.562634] TransferScanner: Syncing with repo1 
+(scanning...) [2018-11-12 11:28:54.726133] Watcher: Performing startup scan
+(started...) 
+warning: no common commits
+From /Users/Shared/repo1
+ * [new branch]      git-annex  -> repo1/git-annex
+(merging repo1/git-annex into git-annex...)
+(recording state in git...)
+
+merge: refs/remotes/repo1/master - not something we can merge
+
+merge: refs/remotes/repo1/synced/master - not something we can merge
+gpg: assuming signed data in '/var/folders/h8/r85pzlmn7nn9_cslphvm3fl00000gn/T/git-annex.tmpdFD1JY/info'
+gpg: Signature made Wed Nov  7 17:35:16 2018 EST
+gpg:                using DSA key 40055C6AFD2D526B2961E78F5EE1DBA789C809CB
+gpg: /var/folders/h8/r85pzlmn7nn9_cslphvm3fl00000gn/T/git-annex-gpg.tmp4i2O5V/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+[2018-11-12 11:29:54.740571] Pusher: Syncing with repo1 
+[2018-11-12 11:30:34.763638] Committer: Adding b.txt
+add b.txt ok
+[2018-11-12 11:30:34.781129] Committer: Committing changes to git
+(recording state in git...)
+[2018-11-12 11:30:34.840133] Pusher: Syncing with repo1 
+To /Users/Shared/repo1
+ * [new branch]      git-annex -> synced/git-annex
+ ! [rejected]        master -> synced/master (non-fast-forward)
+error: failed to push some refs to '/Users/Shared/repo1'
+hint: Updates were rejected because a pushed branch tip is behind its remote
+hint: counterpart. Check out this branch and integrate the remote changes
+hint: (e.g. 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+To /Users/Shared/repo1
+ ! [rejected]        master -> master (non-fast-forward)
+error: failed to push some refs to '/Users/Shared/repo1'
+hint: Updates were rejected because the tip of your current branch is behind
+hint: its remote counterpart. Integrate the remote changes (e.g.
+hint: 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+From /Users/Shared/repo1
+ * [new branch]      master        -> repo1/master
+ * [new branch]      synced/master -> repo1/synced/master
+
+Merge made by the 'recursive' strategy.
+ a.txt | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 a.txt
+
+Already up to date.
+[2018-11-12 11:30:35.847507] Committer: Committing changes to git
+(recording state in git...)
+To /Users/Shared/repo1
+   fc9cada..6ba5ac7  master -> synced/master
+[2018-11-12 11:30:38.007996] Pusher: Syncing with repo1 
+Everything up-to-date
+andrew@bumblebee /Users/Shared/repo2$ cd ../repo1
+andrew@bumblebee /Users/Shared/repo1$ cat .git/annex/daemon.log 
+[2018-11-12 11:28:49.721989] main: starting assistant version 7.20181106-g352f88226
+[2018-11-12 11:28:49.769131] Cronner: You should enable consistency checking to protect your data. 
+[2018-11-12 11:28:54.824594] TransferScanner: Syncing with repo2 
+(scanning...) [2018-11-12 11:28:55.021515] Watcher: Performing startup scan
+(started...) 
+From /Users/Shared/repo2
+ * [new branch]      git-annex  -> repo2/git-annex
+(merging repo2/git-annex into git-annex...)
+
+merge: refs/remotes/repo2/master - not something we can merge
+
+merge: refs/remotes/repo2/synced/master - not something we can merge
+gpg: assuming signed data in '/var/folders/h8/r85pzlmn7nn9_cslphvm3fl00000gn/T/git-annex.tmpDX5TrA/info'
+gpg: Signature made Wed Nov  7 17:35:16 2018 EST
+gpg:                using DSA key 40055C6AFD2D526B2961E78F5EE1DBA789C809CB
+gpg: /var/folders/h8/r85pzlmn7nn9_cslphvm3fl00000gn/T/git-annex-gpg.tmpoINnOV/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" [unknown]
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2018-11-12 11:29:08.133292] Committer: Adding a.txt
+add a.txt ok
+[2018-11-12 11:29:08.156146] Committer: Committing changes to git
+(recording state in git...)
+[2018-11-12 11:29:08.213209] Pusher: Syncing with repo2 
+(recording state in git...)
+(checksum...) [2018-11-12 11:29:08.423322] Transferrer: Uploaded a.txt
+To /Users/Shared/repo2
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+[2018-11-12 11:29:10.600961] Pusher: Syncing with repo2 
+(recording state in git...)
+To /Users/Shared/repo2
+   0d60202..3f14350  git-annex -> synced/git-annex
+[2018-11-12 11:29:55.03181] Pusher: Syncing with repo2 
+Everything up-to-date
+
+Updating fc9cada..6ba5ac7
+Fast-forward
+ b.txt | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 b.txt
+[2018-11-12 11:30:36.890836] Committer: Committing changes to git
+(recording state in git...)
+[2018-11-12 11:30:36.924606] Pusher: Syncing with repo2 
+To /Users/Shared/repo2
+   3f14350..c67ada1  git-annex -> synced/git-annex
+andrew@bumblebee /Users/Shared/repo1$
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes. Its excellent!
diff --git a/doc/bugs/assistant_cannot_sync_files_to_empty_indirect_repo/comment_1_af9b44674bafb63de05b888b90878325._comment b/doc/bugs/assistant_cannot_sync_files_to_empty_indirect_repo/comment_1_af9b44674bafb63de05b888b90878325._comment
new file mode 100644
index 0000000000..1b1f41ffa2
--- /dev/null
+++ b/doc/bugs/assistant_cannot_sync_files_to_empty_indirect_repo/comment_1_af9b44674bafb63de05b888b90878325._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-11-20T21:42:11Z"
+ content="""
+Also note from the log above that `whereis` on repo1 reports that repo2 has a copy of the file even though git failed to merge into repo1 and even though repo1 does not actually have the file.
+
+    andrew@bumblebee /Users/Shared/repo1$ git-annex whereis a.txt
+    whereis a.txt (2 copies) 
+        746bb051-e2c5-463b-8d4c-7d4eee6de855 -- andrew@bumblebee.local:/Users/Shared/repo1 [here]
+        87af3666-1f63-4ad1-8a1e-a1d260c90751 -- andrew@bumblebee.local:/Users/Shared/repo2 [repo2]
+    ok
+    andrew@bumblebee /Users/Shared/repo1$ cd ../repo2
+    andrew@bumblebee /Users/Shared/repo2$ date
+    Mon Nov 12 11:29:27 EST 2018
+    andrew@bumblebee /Users/Shared/repo2$ ls
+    andrew@bumblebee /Users/Shared/repo2$ git-annex whereis a.txt
+    git-annex: a.txt not found
+    git-annex: whereis: 1 failed
+"""]]
diff --git a/doc/bugs/assistant_cannot_sync_files_to_empty_indirect_repo/comment_2_789149eb53162a11cbafde399215e40e._comment b/doc/bugs/assistant_cannot_sync_files_to_empty_indirect_repo/comment_2_789149eb53162a11cbafde399215e40e._comment
new file mode 100644
index 0000000000..e3abecd4df
--- /dev/null
+++ b/doc/bugs/assistant_cannot_sync_files_to_empty_indirect_repo/comment_2_789149eb53162a11cbafde399215e40e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 2"
+ date="2018-11-20T21:56:03Z"
+ content="""
+I have the same issue with two version 7 repos.
+"""]]
diff --git a/doc/bugs/assistant_committer_crashes_due_to_missing_file.mdwn b/doc/bugs/assistant_committer_crashes_due_to_missing_file.mdwn
new file mode 100644
index 0000000000..c32d333ce3
--- /dev/null
+++ b/doc/bugs/assistant_committer_crashes_due_to_missing_file.mdwn
@@ -0,0 +1,71 @@
+### Please describe the problem.
+
+The git annex assistant committer stops working and crashes under certain circumstances when dealing with small files.
+
+This seems to occur when a small file is in the committer queue but is deleted before the queue is flushed.
+
+### What steps will reproduce the problem?
+
+Set the `annex.largefiles` option to exclude certain files from the annex: `git config annex.largefiles 'exclude=*.txt'`.
+
+Create and immediately delete some file that is excluded from the annex:
+
+[[!format sh """
+touch somefile.txt && rm somefile.txt
+"""]]
+
+This will cause a "user error" to occur every time the committer thread tries to do a commit, essentially causing it to stop working.
+
+In addition, if no file activity occurs for 5 minutes, creating another file will cause the committer to crash:
+
+[[!format sh """
+sleep 310
+touch someotherfile.txt
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+Operating system: Arch Linux x86_64
+
+git-annex version: 10.20230329
+
+### Please provide any additional information below.
+
+[[!format sh """
+# .git/annex/daemon.log
+
+[2023-06-14 17:32:42.652269404] (Watcher) add somefile.txt
+[2023-06-14 17:32:42.652761285] (Watcher) add somefile.txt
+[2023-06-14 17:32:42.652832039] (Watcher) file deleted somefile.txt
+[2023-06-14 17:32:42.663222161] (Utility.Process) process [1178267] read: lsof ["-F0can","+d",".git/annex/watchtmp/"]
+[2023-06-14 17:32:42.830892116] (Utility.Process) process [1178267] done ExitFailure 1
+[2023-06-14 17:32:42.831219136] (Utility.Process) process [1178269] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index-info"]
+[2023-06-14 17:32:42.832078397] (Utility.Process) process [1178269] done ExitSuccess
+[2023-06-14 17:32:42.832140832] (Committer) committing 2 changes
+(recording state in git...)
+[2023-06-14 17:32:42.832442128] (Utility.Process) process [1178270] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","add","--force","--"]
+fatal: pathspec 'somefile.txt' did not match any files
+[2023-06-14 17:32:42.833714128] (Utility.Process) process [1178270] done ExitFailure 123
+[2023-06-14 17:33:10.166497909] (Utility.Process) process [1178219] done ExitSuccess
+[2023-06-14 17:33:10.167361436] (Utility.Process) process [1178207] done ExitSuccess
+[2023-06-14 17:33:10.168264148] (Utility.Process) process [1178218] done ExitSuccess
+[2023-06-14 17:33:10.16909154] (Utility.Process) process [1178238] done ExitSuccess
+[2023-06-14 17:33:10.169892592] (Utility.Process) process [1178240] done ExitSuccess
+[2023-06-14 17:33:10.170694357] (Utility.Process) process [1178227] done ExitFailure 1
+[2023-06-14 17:33:40.185689237] (Utility.Process) process [1178330] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-tree","--full-tree","-z","--","refs/heads/git-annex","uuid.log","remote.log","trust.log","group.log","numcopies.log","mincopies.log","schedule.log","preferred-content.log","required-content.log","group-preferred-content.log"]
+[2023-06-14 17:33:40.189177926] (Utility.Process) process [1178330] done ExitSuccess
+[2023-06-14 17:37:52.65735194] (Utility.Process) process [1178648] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2023-06-14 17:37:52.660710625] (Utility.Process) process [1178649] chat: git ["--git-dir=.git","--work-tree=.","-c","annex.debug=true","check-ignore","-z","--stdin","--verbose","--non-matching"]
+[2023-06-14 17:37:52.663100743] (Watcher) add someotherfile.txt
+[2023-06-14 17:37:52.663984987] (Watcher) add someotherfile.txt
+[2023-06-14 17:37:52.674996448] (Utility.Process) process [1178650] read: lsof ["-F0can","+d",".git/annex/watchtmp/"]
+[2023-06-14 17:37:52.825736165] (Utility.Process) process [1178650] done ExitFailure 1
+[2023-06-14 17:37:52.826111004] (Utility.Process) process [1178652] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","add","--force","--"]
+fatal: pathspec 'somefile.txt' did not match any files
+[2023-06-14 17:37:52.82750231] (Utility.Process) process [1178652] done ExitFailure 123
+Committer crashed: user error (xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","add","--force","--"] exited 123)
+
+# End of transcript or log.
+"""]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/assistant_does_not_allow_adding_an_existing_repo.mdwn b/doc/bugs/assistant_does_not_allow_adding_an_existing_repo.mdwn
new file mode 100644
index 0000000000..8d2c3c9964
--- /dev/null
+++ b/doc/bugs/assistant_does_not_allow_adding_an_existing_repo.mdwn
@@ -0,0 +1,10 @@
+The assistant does not allow adding an existing repo: I tried to add a "remote server", to enter the credits, and then I add to choose between "git-annex" or "rsync". Choosing "git-annex" tries to create a new repo and then fails. The repo on the server is a bare one, accessed via gitolite. Setting the remote manually ("git remote add origin git@example.org:my-annex.git" works (I can pull, push, ...))
+
+Mac OS 10.7 version 2013-09-10
+
+
+[[!meta title="assistant does not interoperate with gitolite when adding a repository"]]
+
+[2013-09-13 17:00:55 CEST] chat: ssh ["-p","22","git@example.org","sh -c 'mkdir -p '\"'\"'my-annex.git'\"'\"'&&cd '\"'\"'my-annex.git'\"'\"'&&if [ ! -d .git ]; then git init --bare --shared; fi&&git annex init'"]
+
+[[!tag confirmed]]
diff --git a/doc/bugs/assistant_does_not_allow_adding_an_existing_repo/comment_1_87e84d56d56abefe8cac8a52b76c9003._comment b/doc/bugs/assistant_does_not_allow_adding_an_existing_repo/comment_1_87e84d56d56abefe8cac8a52b76c9003._comment
new file mode 100644
index 0000000000..b260b8df51
--- /dev/null
+++ b/doc/bugs/assistant_does_not_allow_adding_an_existing_repo/comment_1_87e84d56d56abefe8cac8a52b76c9003._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.2.134"
+ subject="comment 1"
+ date="2013-09-13T18:19:03Z"
+ content="""
+I suppose the assistant could try to add a git remote and pull from it, and only if this pull fails go try to run shell commands to create it. This might work with gitolite, gitosis, github, etc. Although only partially for ones that don't support running git-annex-shell..
+"""]]
diff --git a/doc/bugs/assistant_does_not_allow_adding_an_existing_repo/comment_2_55fcf44eefe6abac3f61a14e9ce9206c._comment b/doc/bugs/assistant_does_not_allow_adding_an_existing_repo/comment_2_55fcf44eefe6abac3f61a14e9ce9206c._comment
new file mode 100644
index 0000000000..8ebdb4ff98
--- /dev/null
+++ b/doc/bugs/assistant_does_not_allow_adding_an_existing_repo/comment_2_55fcf44eefe6abac3f61a14e9ce9206c._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="effigies"
+ subject="Strategy for getting up and running"
+ date="2015-03-09T17:32:19Z"
+ content="""
+The following is the set of steps I use when setting assistant up on a new repository:
+
+    git clone user@host:repo.git
+    pushd repo
+    git annex init
+        touch EMPTY
+        git annex add EMPTY
+        git commit -m 'Initial commit'
+        git push --all
+        git annex copy --to origin
+        git annex direct
+        git annex sync
+        git annex untrust .
+    popd
+
+Entering the folder path now lets the assistant take over.
+
+For an existing repository:
+
+    git clone user@host:repo.git
+    pushd repo
+        git annex get .
+        git annex direct
+        git annex sync
+        git annex untrust .
+    popd
+
+Not sure if this would be helpful for working out what the assistant behavior should be, but maybe it'll help others get to the point where the assistant works with a gitolite managed repo.
+"""]]
diff --git a/doc/bugs/assistant_does_not_always_use_repo_cost_info_when_queueing_downloads.mdwn b/doc/bugs/assistant_does_not_always_use_repo_cost_info_when_queueing_downloads.mdwn
new file mode 100644
index 0000000000..d7002a2f7a
--- /dev/null
+++ b/doc/bugs/assistant_does_not_always_use_repo_cost_info_when_queueing_downloads.mdwn
@@ -0,0 +1,18 @@
+git-annex has nice repository cost tracking, but the assistant doesn't
+always use this when queuing downloads.
+
+For example, if a network comes up, it'll queue a lot of downloads from a
+remote, perhaps expensive server. If a removable drive is then attached,
+which has a lower cost, it'll queue downloads from there, but
+only once it works through all the ones it's already queued from the
+network.
+
+There is a workaround: Since the webapp allows disabling syncing to a
+remote, the user can go in and disable syncing to the network remote
+temporarily.
+
+[[!tag /design/assistant]]
+
+--[[Joey]] 
+
+[[!tag confirmed]]
diff --git a/doc/bugs/assistant_doesn__39__t_notice_changes_to_gitignore_files.mdwn b/doc/bugs/assistant_doesn__39__t_notice_changes_to_gitignore_files.mdwn
new file mode 100644
index 0000000000..805aaf00f2
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_notice_changes_to_gitignore_files.mdwn
@@ -0,0 +1,41 @@
+### Please describe the problem.
+
+Once the assistant daemon is started, it won't notice updates to any gitignore files.  This is probably because it spawns a long-lived `git check-ignore -z --stdin --verbose --non-matching` process which only reads gitignore files on startup.
+
+### What steps will reproduce the problem?
+
+- Start the assistant
+- Add a pattern to a relevant `.gitignore` or `.git/info/exclude`
+- (Just to be safe) wait for the assistant to commit and sync that change
+- Create a file matching the new ignore pattern
+- Observe the assistant committing the file to the repository despite it matching the new ignore pattern
+
+### What version of git-annex are you using? On what operating system?
+
+7.20191230-gef6d1e327 on openSUSE Leap 15.1
+
+### Please provide any additional information below.
+
+I assume that the obvious fix would be to watch for changes to gitignore files, and restart the `check-ignore` process accordingly.
+
+A workaround is to restart the assistant.  I've tested this and it works fine.
+
+Unsurprisingly the daemon log just shows the normal behaviour so it's probably not very useful, but including anyway just in case:
+
+[[!format sh """
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+Everything up-to-date
+[2020-01-06 15:40:21.863988735] Committer: Committing changes to git
+(recording state in git...)
+[2020-01-06 15:40:22.024703938] Pusher: Syncing with peer1 
+[2020-01-06 15:40:23.025650786] Committer: Committing changes to git
+(recording state in git...)
+To tor-annex::<censored>.onion:5227
+   841db50..d47d59e  master -> synced/master
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, worked great for many years, but struggling to get the assistant to a point I can use it.  Main blockers are [[assistant_sometimes_removes_and_re-adds_whole_file]] and [[todo/wishlist__58___disable_automatic_commits]].
diff --git a/doc/bugs/assistant_doesn__39__t_sync_empty_directories.mdwn b/doc/bugs/assistant_doesn__39__t_sync_empty_directories.mdwn
new file mode 100644
index 0000000000..53ee5a1050
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_empty_directories.mdwn
@@ -0,0 +1,32 @@
+### Please describe the problem.
+
+The assistant seems to only sync files and not directories, so empty directories will not be synced.
+
+### What steps will reproduce the problem?
+
+- Create an empty directory on HostA
+- See that nothing gets synced (daemon.log is silent) and the directory doesn't exist on the other HostB
+- Create an empty file inside the empty directory on HostA
+- See that now HostB has the empty file inside the directory
+
+I'm sure this comes directly from the git behavior but is at least surprising for a direct mode repository using the assistant.
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+$ git annex version
+git-annex version: 4.20130516.1
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+local repository version: 4
+default repository version: 3
+supported repository versions: 3 4
+upgrade supported from repository versions: 0 1 2
+$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 12.04.2 LTS
+Release:	12.04
+Codename:	precise
+"""]]
+
+> [[!taglink confirmed]] (but may be out of scope) --[[Joey]] 
diff --git a/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_1_78a3bde607f43c0f518bd2d3d7196022._comment b/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_1_78a3bde607f43c0f518bd2d3d7196022._comment
new file mode 100644
index 0000000000..b31955ed38
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_1_78a3bde607f43c0f518bd2d3d7196022._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-31T21:14:11Z"
+ content="""
+Git does not have a concept of an empty directory. The  typical workaround is to put a .gitignore file in the directory.
+"""]]
diff --git a/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_2_83777384b72732b1d0a19b32686d3d1f._comment b/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_2_83777384b72732b1d0a19b32686d3d1f._comment
new file mode 100644
index 0000000000..a62cba1e37
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_2_83777384b72732b1d0a19b32686d3d1f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkx5V3MTbzCXS3J7Mn9FEq8M9bPPYMkAHY"
+ nickname="Pedro"
+ subject="comment 2"
+ date="2013-05-31T21:48:24Z"
+ content="""
+Adding .gitignore files makes sense for a git standpoint but whatever workaround is needed to make the assistant works properly should be done by the assistant itself no? Maybe having direct mode commit a shaddow \".this_is_a_magic_empty_file\" in empty directories and then not actually writing that file into direct mode repositories on the other side.
+"""]]
diff --git a/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_3_f9b2a700c060707fae1bcb2ec0e4e4dc._comment b/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_3_f9b2a700c060707fae1bcb2ec0e4e4dc._comment
new file mode 100644
index 0000000000..757a1c7276
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_3_f9b2a700c060707fae1bcb2ec0e4e4dc._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmOsy6nbvPyXLd--qqjPMLnVIzxgZwtKlQ"
+ nickname="Nicolas"
+ subject="comment 3"
+ date="2013-09-11T23:19:26Z"
+ content="""
+This behaviour is indeed very confusing when one attempts to use git-annex with the assistant only, without thinking about the underlying machinery.
+Having the assistant automatically put a .gitignore file in empty directories is a possible solution, but maybe printing a warning in the log when the watcher sees an empty directory could be an unobtrusive and helpful solution? (At least it would have helped me)
+"""]]
diff --git a/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_4_014d213a959dd7993bdd247722a8817e._comment b/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_4_014d213a959dd7993bdd247722a8817e._comment
new file mode 100644
index 0000000000..f6be08ae4b
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_4_014d213a959dd7993bdd247722a8817e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmOsy6nbvPyXLd--qqjPMLnVIzxgZwtKlQ"
+ nickname="Nicolas"
+ subject="comment 4"
+ date="2013-09-11T23:24:58Z"
+ content="""
+Another problem with the current behaviour is that when deleting a directory and its contents on a repository, the contents are deleted on the other repositories but empty directories are left behind...
+"""]]
diff --git a/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_5_440f349781d7d9ca2d1ed81386f7dd26._comment b/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_5_440f349781d7d9ca2d1ed81386f7dd26._comment
new file mode 100644
index 0000000000..0d5f0aa295
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_empty_directories/comment_5_440f349781d7d9ca2d1ed81386f7dd26._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="comment 5"
+ date="2013-11-01T22:12:04Z"
+ content="""
+I agree that this is very confusing.  Also having to manually delete empty, renamed directories is...less than ideal.  :)
+"""]]
diff --git a/doc/bugs/assistant_doesn__39__t_sync_file_permissions.mdwn b/doc/bugs/assistant_doesn__39__t_sync_file_permissions.mdwn
new file mode 100644
index 0000000000..48a99d7c24
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_file_permissions.mdwn
@@ -0,0 +1,47 @@
+### Please describe the problem.
+
+The assistant does not sync file permissions so if you set something as executable it won't be set the same on the other repositories.
+
+### What steps will reproduce the problem?
+
+On the first host:
+
+[[!format sh """
+$ echo -e '#!/bin/sh\necho "Hello World!"' > testscript
+$ chmod ugo+x testscript 
+$ ./testscript 
+Hello World!
+$ ls -l
+total 4
+-rwxr-xr-x 1 pedrocr pedrocr 30 May 31 20:00 testscript
+"""]]
+
+And on the second host:
+
+[[!format sh """
+$ ls -l
+total 4
+-rw-r--r-- 1 pedrocr pedrocr 30 May 31 20:00 testscript
+$ ./testscript
+bash: ./testscript: Permission denied
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+$ git annex version
+git-annex version: 4.20130516.1
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+local repository version: 4
+default repository version: 3
+supported repository versions: 3 4
+upgrade supported from repository versions: 0 1 2
+$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 12.04.2 LTS
+Release:	12.04
+Codename:	precise
+"""]]
+
+> [[!taglink confirmed]] (but may be out of scope) --[[Joey]] 
diff --git a/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_1_fc8d3ea209a2ab39c1aeff52452d4c58._comment b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_1_fc8d3ea209a2ab39c1aeff52452d4c58._comment
new file mode 100644
index 0000000000..9e1b801a4e
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_1_fc8d3ea209a2ab39c1aeff52452d4c58._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-31T21:17:17Z"
+ content="""
+More generally, symbolic links cannot have permissions of their own, and git in fact indicates a file is a symlink by setting the tree object's mode to a specific magic number. So there is no git metadata that git-annex can use to track whether a file is supposed to be executable.
+
+Therefore, this will only get fixed when there's some kind of full-fledged metadata storage for git.
+"""]]
diff --git a/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_2_1a364c422e0dd7418f74e1cc3d543a3c._comment b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_2_1a364c422e0dd7418f74e1cc3d543a3c._comment
new file mode 100644
index 0000000000..8585e309c1
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_2_1a364c422e0dd7418f74e1cc3d543a3c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkx5V3MTbzCXS3J7Mn9FEq8M9bPPYMkAHY"
+ nickname="Pedro"
+ subject="comment 2"
+ date="2013-05-31T21:45:39Z"
+ content="""
+Note that the file I created wasn't a symlink. I assume you mention symlinks because git-annex itself checks in symlinks to git instead of actual files?
+"""]]
diff --git a/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_3_4d5ae51b4c7e6177d934d7c9f21b912c._comment b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_3_4d5ae51b4c7e6177d934d7c9f21b912c._comment
new file mode 100644
index 0000000000..6bf1894145
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_3_4d5ae51b4c7e6177d934d7c9f21b912c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="comment 3"
+ date="2013-11-02T23:49:49Z"
+ content="""
+Dropbox handles permissions, e.g. if I \"chmod -x\" a file on one system, it does the same to my other systems.  It would be a bit of a step backward if git-annex can't do this.  :/  Just my two cents.
+"""]]
diff --git a/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_4_ec7b491ad3c9a1f253d886682bff8b82._comment b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_4_ec7b491ad3c9a1f253d886682bff8b82._comment
new file mode 100644
index 0000000000..4b287c9df6
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_4_ec7b491ad3c9a1f253d886682bff8b82._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="TobiasTheViking"
+ subject="comment 4"
+ date="2014-01-12T19:16:07Z"
+ content="""
+Yeah, now i just hit this. kinda annoying.
+
+Couldn't this at least be solved for direct mode repositories?
+
+"""]]
diff --git a/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_5_e04ddcd7a3d260c1dac54e41911bb4bc._comment b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_5_e04ddcd7a3d260c1dac54e41911bb4bc._comment
new file mode 100644
index 0000000000..73f3d00d86
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_5_e04ddcd7a3d260c1dac54e41911bb4bc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://cstork.org/"
+ nickname="Chris Stork"
+ subject="comment 5"
+ date="2014-01-14T08:33:21Z"
+ content="""
+@Pedro: What Joey is refering to is that git-annex uses sym-links behind the scenes to store even such a small file.  (BTW, that can be changed with the large-file config option, IIRC.)
+
+@Joey: Even a \"full-fledged metadata storage for git\" wouldn't solve this problem since from git's POV it's still just a sym-link without permissions.
+"""]]
diff --git a/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_6_13db3474113b157b7431eb1c835e5814._comment b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_6_13db3474113b157b7431eb1c835e5814._comment
new file mode 100644
index 0000000000..6f7283be26
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_6_13db3474113b157b7431eb1c835e5814._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="178.79.137.64"
+ subject="comment 6"
+ date="2014-06-24T10:05:26Z"
+ content="""
+Now that git-annex has a proper metadata system now, can this be handled?
+
+Perhaps doing this:
+
+git annex metadata -s __executable 001
+
+could cause git-annex to set the executable bit (on get, fsck etc.) and that be set automatically on git annex add if the file has executable bit set (numbers are a bitmask for which execute bit to set..?).
+"""]]
diff --git a/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_7_3cc6eeb8eae14ac3727b1e420f96ee7d._comment b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_7_3cc6eeb8eae14ac3727b1e420f96ee7d._comment
new file mode 100644
index 0000000000..8b62a7d93c
--- /dev/null
+++ b/doc/bugs/assistant_doesn__39__t_sync_file_permissions/comment_7_3cc6eeb8eae14ac3727b1e420f96ee7d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="no generic solution is possible in indirect mode BUT still would be nice to have a 99% solution"
+ date="2018-08-03T21:51:22Z"
+ content="""
+just ran into this as well, so was looking around. 
+I am afraid that in indirect mode no \"proper\" solution is possible since for the same content (git-annex key) there could originally be multiple files with different permissions -- e.g. one executable and one not. 
+**BUT** IMHO even though no proper solution possible, if would indeed be very useful to have it resolved to work for 99% of cases, where such collisions aren't likely and a \"union\" of executable bit across present files in the repo could be used (so if one is executable, all others with the same content are as well).  Since git annex by default inherits/propagates metadata changes across \"editions\" of the files it would already be handy even if e.g. executable shell scripts gets modified which is kinda a neat side effect ;-)
+"""]]
diff --git a/doc/bugs/assistant_expensive_scan_unnecessarily_queues_files.mdwn b/doc/bugs/assistant_expensive_scan_unnecessarily_queues_files.mdwn
new file mode 100644
index 0000000000..0196b7d7d4
--- /dev/null
+++ b/doc/bugs/assistant_expensive_scan_unnecessarily_queues_files.mdwn
@@ -0,0 +1,65 @@
+### Please describe the problem.
+Summary: The assistant pulls files from remote repos although they are stored on trusted repos (remote machine may be up or down).
+
+After starting the assistant via "git annex webapp --listen #ip# --verbose --debug" it starts to check for pending tasks and starts to queue lots of files (could be all of them). I checked the daemon.log and found the following line:
+
+[[!format sh """
+[2014-06-03 21:39:04 CEST] TransferScanner: queued Download UUID "541d2f88-16c3-11e2-aa7e-8f1a2c8e14c5" apps/Apache_OpenOffice_4.0.0_MacOS_x86_install_en-US.dmg Nothing : expensive scan found missing object
+"""]]
+
+The file is available in a remote repo:
+
+[[!format sh """
+$ git annex whereis apps/Apache_OpenOffice_4.0.0_MacOS_x86_install_en-US.dmg
+whereis apps/Apache_OpenOffice_4.0.0_MacOS_x86_install_en-US.dmg (1 copy) 
+  	541d2f88-16c3-11e2-aa7e-8f1a2c8e14c5 -- dump
+ok
+"""]]
+
+The remote "dump" is trusted and is configured as "backup" repo. The repo running the assistant is configured as "manual". The configuration settings for wanted, required and scheduled remained untouched.
+
+Num copies is unset and defaults to 1:
+
+[[!format sh """
+$ git annex numcopies
+global numcopies is not set
+(default is 1)
+"""]]
+
+When calling "git annex find --want-get" no files are listed as in my case, all are stored in the "dump" repo which is trusted.
+
+[[!format sh """
+$ git annex find --want-get
+$ 
+"""]]
+
+### What steps will reproduce the problem?
+Start the assistant and wait for it to finish startup checking. The assistant adds lots (all?) of the files due to “expensive scan found missing object”.
+
+### What version of git-annex are you using? On what operating system?
+Snapshot build from the annex branchable webpage running on an OSX 10.9.3 machine:
+[[!format sh """
+$ git annex version
+git-annex version: 5.20140411-g2503f43
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+"""]]
+
+Note: Updated to 5.20140529-g68a56a6 but same behavior is observed.
+
+### Please provide any additional information below.
+
+The backup node was down while the assistant starts up. However also files from another trusted node that is online 24/7 is pulled. Repo was upgraded from version 4 to 5. Is there a way to further check why a file was added e.g. to dump all variables of the evaluated term (approxlackingcopies, copies, etc)?
+
+[[!format sh """
+[2014-06-03 21:39:04 CEST] TransferScanner: starting scan of [Remote { name ="origin" },Remote { name ="dump" }]
+[2014-06-03 21:39:04 CEST] read: git ["--git-dir=/Volumes/DATA/annex/images/.git","--work-tree=/Volumes/DATA/annex/images","ls-files","--cached","-z","--"]
+[2014-06-03 21:39:04 CEST] chat: git ["--git-dir=/Volumes/DATA/annex/images/.git","--work-tree=/Volumes/DATA/annex/images","check-attr","-z","--stdin","annex.backend","annex.numcopies","--"]
+[2014-06-03 21:39:04 CEST] TransferScanner: queued Download UUID "541d2f88-16c3-11e2-aa7e-8f1a2c8e14c5" apps/Apache_OpenOffice_4.0.0_MacOS_x86_install_en-US.dmg Nothing : expensive scan found missing object
+[2014-06-03 21:39:04 CEST] Transferrer: Transferring: Download UUID "541d2f88-16c3-11e2-aa7e-8f1a2c8e14c5" apps/Apache_OpenOffice_4.0.0_MacOS_x86_install_en-US.dmg Nothing
+[2014-06-03 21:39:04 CEST] TransferScanner: queued Download UUID "541d2f88-16c3-11e2-aa7e-8f1a2c8e14c5" apps/Apache_OpenOffice_4.0.1_MacOS_x86_install_en-US.dmg Nothing : expensive scan found missing object
+"""]]
diff --git a/doc/bugs/assistant_expensive_scan_unnecessarily_queues_files/comment_1_bc874e077009b81ab36a6d43d793030a._comment b/doc/bugs/assistant_expensive_scan_unnecessarily_queues_files/comment_1_bc874e077009b81ab36a6d43d793030a._comment
new file mode 100644
index 0000000000..91c8616c26
--- /dev/null
+++ b/doc/bugs/assistant_expensive_scan_unnecessarily_queues_files/comment_1_bc874e077009b81ab36a6d43d793030a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-06-12T20:07:30Z"
+ content="""
+This seems to me to be likely to be some kind of configuration problem. In particular, what is the \"wanted\" setting for the repo running the assistant? If it's not \"standard\" then the fact that it's in the \"manual\" group won't affect the assistant's behavior.
+
+If that's not it, it would probably help to paste the entire vicfg display, so I can replicate the config (or share the repo).
+"""]]
diff --git a/doc/bugs/assistant_expensive_scan_unnecessarily_queues_files/comment_2_a7e9d8ec500399dd6794e168f85e6a5c._comment b/doc/bugs/assistant_expensive_scan_unnecessarily_queues_files/comment_2_a7e9d8ec500399dd6794e168f85e6a5c._comment
new file mode 100644
index 0000000000..589086f6e1
--- /dev/null
+++ b/doc/bugs/assistant_expensive_scan_unnecessarily_queues_files/comment_2_a7e9d8ec500399dd6794e168f85e6a5c._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmXSkgjC_ypUQafVwvHTLsStrkiXH8CfHU"
+ nickname="Matthias"
+ subject="comment 2"
+ date="2014-06-13T18:30:25Z"
+ content="""
+Thanks for your fast reply, Joey. I appended the shortened config below. Wanted and groupwanted were untouched and therefore still commented out. I removed the hash from wanted to explicitly set it standard. Now the assistant behaves as expected. However I’m wondering:
+
+* Shouldn’t ‘standard’ be the default rule to apply for wanted/groupwanted in case both are not explicitly set in the config? I assumed this to be the case.
+* Shouldn’t “find --want-get” list the identical set of files that is also requested by the assistant? Especially this one confused me.
+
+[[!format sh \"\"\"
+# Repository trust configuration
+# (for macbook)
+#trust 3938865a-ce40-4166-a918-2012078846c7 = semitrusted
+
+# Repository groups
+# (for macbook)
+group 3938865a-ce40-4166-a918-2012078846c7 = manual
+
+# Repository preferred contents
+# (for macbook)
+#wanted 3938865a-ce40-4166-a918-2012078846c7 = standard
+
+# Group preferred contents
+# (Used by repositories with \"groupwanted\" in their preferred contents)
+(config defaults - all commented out)
+
+# Standard preferred contents
+(config defaults - all commented out)
+
+# Repository required contents
+# (for macbook)
+#required 3938865a-ce40-4166-a918-2012078846c7 = 
+
+# Scheduled activities
+# (for macbook)
+#schedule 3938865a-ce40-4166-a918-2012078846c7 = 
+\"\"\"]]
+"""]]
diff --git a/doc/bugs/assistant_expensive_scan_unnecessarily_queues_files/comment_3_a0824e00f04f95c39823f29d6c76e7fe._comment b/doc/bugs/assistant_expensive_scan_unnecessarily_queues_files/comment_3_a0824e00f04f95c39823f29d6c76e7fe._comment
new file mode 100644
index 0000000000..58f2069c18
--- /dev/null
+++ b/doc/bugs/assistant_expensive_scan_unnecessarily_queues_files/comment_3_a0824e00f04f95c39823f29d6c76e7fe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-06-13T18:35:53Z"
+ content="""
+I need to look into why --want-get didn't behave as expected.
+
+It would probably make sense to make standard be the default. There could be upgrade concerns though.
+"""]]
diff --git a/doc/bugs/assistant_locked_my_files.mdwn b/doc/bugs/assistant_locked_my_files.mdwn
new file mode 100644
index 0000000000..07bafd6cc2
--- /dev/null
+++ b/doc/bugs/assistant_locked_my_files.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+
+When the assistant is running, using "git annex unlock" on the commandline may lead to unexpected results.
+
+### What steps will reproduce the problem?
+
+Make sure the assitant is running on a repository.
+
+`git annex unlock somefiles`, try to edit them, wait a while, try to edit.
+
+If you're not lucky, the assistant will notice the unlocked files as new and will add them back, locking them in the process, and you won't be able to save them.
+
+### What version of git-annex are you using? On what operating system?
+
+debian wheezy.
+
+[[!format sh """
+git-annex version: 5.20131109-gf2cb5b9
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav glacier hook
+local repository version: 3
+default repository version: 3
+supported repository versions: 3 5
+upgrade supported from repository versions: 0 1 2 4
+"""]]
+
+### Please provide any additional information below.
+
+[[!tag confirmed]]
diff --git a/doc/bugs/assistant_locked_my_files/comment_1_74ee7ea12df7bfbb44c9d0485f787b73._comment b/doc/bugs/assistant_locked_my_files/comment_1_74ee7ea12df7bfbb44c9d0485f787b73._comment
new file mode 100644
index 0000000000..fdf921c471
--- /dev/null
+++ b/doc/bugs/assistant_locked_my_files/comment_1_74ee7ea12df7bfbb44c9d0485f787b73._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 1"
+ date="2013-12-05T20:46:30Z"
+ content="""
+Right -- you can't use the assistant at the same time as git-annex commands that get/drop/unlock files, unless you set the assistant to run in manual mode (which prevents it undoing a get/drop) and/or disable syncing in the assistant entirely (which prevents it adding back unlocked files).
+"""]]
diff --git a/doc/bugs/assistant_memory_leak.mdwn b/doc/bugs/assistant_memory_leak.mdwn
new file mode 100644
index 0000000000..ca23cf8ffb
--- /dev/null
+++ b/doc/bugs/assistant_memory_leak.mdwn
@@ -0,0 +1,22 @@
+### Please describe the problem.
+
+The assistant is using gruesome amounts of resident memory:
+
+<pre>
+USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
+www-data 23898 29.0 90.4 7842888 5536740 ?     Sl   Jun17 2810:08 /usr/lib/git-annex.linux/exe/git-annex --library-path /usr/lib/git-annex.linu
+</pre>
+
+I had to stop the assistant because it ended up using all memory.
+
+### What steps will reproduce the problem?
+
+Unclear. The assistant has been running for a while and there's a big tansfer (~800GB) of files in progress.
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150610+gitg608172f-1~ndall+1 on Debian 7 Wheezy.
+
+### Please provide any additional information below.
+
+daemon.log: http://paste2.org/YJVGvpy5 --[[anarcat]]
diff --git a/doc/bugs/assistant_not_synching_with_content.mdwn b/doc/bugs/assistant_not_synching_with_content.mdwn
new file mode 100644
index 0000000000..ce8c6c4d51
--- /dev/null
+++ b/doc/bugs/assistant_not_synching_with_content.mdwn
@@ -0,0 +1,97 @@
+### Please describe the problem.
+
+I have the following repos
+
+a - group manual - all content currently originates on this repo (OS X 10.14.4)
+b - group backup - this is a rclone special backed by google drive
+c - this is the underlying git repo on gitlab.com
+d - group backup - a server that is supposed to backup everything (OS X 10.14.4)
+
+Assistant is running on a and d
+
+It is not guaranteed that a and d will be able to directly connect, however, they both have very good connectivity to b and c
+
+When I add a set of files into a (using git-annex add) the non-annex files get checked into the git repo and pushed to c.  Similarly, the content (annex files) get pushed to b.  This is confirmed by git-anenx list --allrepos
+
+Within an hour or so, d will know about the files that were added (git-annex list) and the git log shows that it is on the same commit as a and c.
+
+However, the assistant on d never does the git-annex sync --content
+
+If I manually run git-annex sync --content on d, all is updated as expected.
+
+I've made no changes to the groupwants, group, etc. settings
+
+### What steps will reproduce the problem?
+
+create a repo with a central git upstream and a special via rclone on gdrive.  Clone that repo in another machine that can also see the upstream and special, but isn't directly connected to the originator of the repo
+
+Add annex-handled files to the original repo.
+
+Check the status of the git upstream, special, and the clone.
+
+After failure is acknowledged, run git annex sync --content to confirm that the mechanics still work
+
+### What version of git-annex are you using? On what operating system?
+
+Both hosts are OSX 10.14.4 and are running 7.20191218
+
+### Please provide any additional information below.
+
+This is from the assistant on the clone.  It is running in debug mode.
+
+[[!format sh """
+
+[2019-12-30 17:44:09.362492] main: starting assistant version 7.20191114
+[2019-12-30 17:44:14.532638] TransferScanner: Syncing with origin
+(scanning...) [2019-12-30 17:44:14.590159] Watcher: Performing startup scan
+ControlSocket .git/annex/ssh/git@gitlab already exists, disabling multiplexing
+Disallowed command
+Everything up-to-date
+Disallowed command
+Disallowed command
+Disallowed command
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+
+  git cat-file EOF: user error
+
+  fd:38: hFlush: resource vanished (Broken pipe)
+
+  fd:38: hFlush: resource vanished (Broken pipe)
+Disallowed command
+(started...)
+[2019-12-30 17:44:33.097035] Committer: Committing changes to git
+(recording state in git...)
+[2019-12-30 17:44:33.176213] Pusher: Syncing with origin
+
+
+
+
+
+Everything up-to-date
+Disallowed command
+
+<<A bunch of white space lines removed for brevity>>
+
+Disallowed command
+Disallowed command
+Disallowed command
+Disallowed command
+Disallowed command
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes - I can run this manually, and overall this is great - I would just love to get this automated....
+
+
diff --git a/doc/bugs/assistant_should_set_up_dedicated_ssh_keys_for_remotes_using_the_standalone_tarball.mdwn b/doc/bugs/assistant_should_set_up_dedicated_ssh_keys_for_remotes_using_the_standalone_tarball.mdwn
new file mode 100644
index 0000000000..7e605ba7cc
--- /dev/null
+++ b/doc/bugs/assistant_should_set_up_dedicated_ssh_keys_for_remotes_using_the_standalone_tarball.mdwn
@@ -0,0 +1,21 @@
+git remotes that have git-annex and git "installed" using the linux
+standalone tarball (or the OSX dmg) may not have git-receive-pack in PATH.
+
+To make `git annex sync` and `git push` etc work on such a remote,
+it needs to have a dedicated ssh key that runs git-annex-shell and uses it
+to run the command.
+
+The assistant sets that up when it sets up a dedicated ssh key. However, if
+the server can be sshed into without a password using an existing ssh key,
+the assistant re-uses that key.
+
+The assistant should either always set up a dedicated ssh key, even when
+not otherwise needed, or it should probe to see if git-receive-pack and
+git-send-pack can be run as part of its probing, and set up a dedicated
+ssh key when they cannot be. --[[Joey]] 
+
+> After recent sshpassword changes, the webapp sets up a dedicated ssh key
+> by default. If the user chooses to use an existing ssh key, it will be
+> used. So this is less likely to be a problem. --[[Joey]] 
+
+[[!tag confirmed]]
diff --git a/doc/bugs/assistant_sometimes_does_not_merge_changes_from_remote.mdwn b/doc/bugs/assistant_sometimes_does_not_merge_changes_from_remote.mdwn
new file mode 100644
index 0000000000..1abc7ffcb2
--- /dev/null
+++ b/doc/bugs/assistant_sometimes_does_not_merge_changes_from_remote.mdwn
@@ -0,0 +1,12 @@
+This bug seems to be somewhat reproducible:
+
+1. Set up ~/annex using webapp, keep empty.
+2. Add another local repo, eg /tmp/annex, and combine the 2 repositories.
+
+Now files written to ~/annex should quickly appear in /tmp/annex, and
+vice-versa. However, this seems not to happen at first. There's a pause
+for some reason until changes start propigating. Apparently a push from
+the repo that got the file to the other repo doesn't happen.
+After this pause, syncing of changes starts happening quickly, as expected.
+
+--[[Joey]]
diff --git a/doc/bugs/assistant_sometimes_does_not_merge_changes_from_remote/comment_1_43bae1f11621232a9133cdef21d1f063._comment b/doc/bugs/assistant_sometimes_does_not_merge_changes_from_remote/comment_1_43bae1f11621232a9133cdef21d1f063._comment
new file mode 100644
index 0000000000..e8c59eac38
--- /dev/null
+++ b/doc/bugs/assistant_sometimes_does_not_merge_changes_from_remote/comment_1_43bae1f11621232a9133cdef21d1f063._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-09-30T17:41:23Z"
+ content="""
+It may be that git is not overwriting the file with its new content, but is
+unlinking it and then writing the new content. If so, that could explain
+the assistant's behavior, since it could notice the file has been deleted,
+and might commit that before it notices it's been added back.
+
+I tried stracing git checkout, and it indeed does unlink
+a modified file then it opens the file for write and writes out the new
+content. Kind of surprising it's not more atomic.
+
+The nature of the assistant is that it's never going to be guaranteed to
+always make commits that make logical sense in the same way that manually
+committing will. It might be possible to improve this by having it delay
+committing removals for some period of time.
+"""]]
diff --git a/doc/bugs/assistant_sometimes_removes_and_re-adds_whole_file.mdwn b/doc/bugs/assistant_sometimes_removes_and_re-adds_whole_file.mdwn
new file mode 100644
index 0000000000..c082e3fcc1
--- /dev/null
+++ b/doc/bugs/assistant_sometimes_removes_and_re-adds_whole_file.mdwn
@@ -0,0 +1,73 @@
+### Please describe the problem.
+
+I have syncing set up between two peers via tor.  Sometimes when I change a (non-annexed) file in one peer, the other peer receives the change, but then within a second or two adds a commit which removes the entire file, and within another second another commit which adds it back.
+
+### What steps will reproduce the problem?
+
+This is not 100% reproducible.  I haven't figured out any pattern yet as to when it happens or doesn't happen.
+
+1. Set up a fresh repo
+1. `echo '* annex.largefiles=nothing' >.gitattributes` and commit
+1. Add another (text) file and commit
+1. `scp` the repo to another machine
+1. Run `enable-tor`, `remotedaemon`, and `p2p --pair` on both
+1. Modify the text file
+1. Observe that the remote peer ends up with three new commits on `master` rather than one; from oldest to newest:
+    1. The commit received via tor from the source side (4bd9c99 in the below example)
+    2. A local commit removing the text file (1ef9061)
+    3. A local commit adding it back with identical contents (e662a33)
+
+### What version of git-annex are you using? On what operating system?
+
+7.20190912-g05bc37910 on both openSUSE nodes (sender is Leap 15.0, receiver is Tumbleweed)
+
+### Please provide any additional information below.
+
+[[!format sh """
+# Relevant output from .git/annex/daemon.log on the sending side
+[2019-09-29 23:44:13.781640446] Committer: Committing changes to git
+(recording state in git...)
+[2019-09-29 23:44:15.105628185] Committer: Committing changes to git
+
+Updating 4bd9c99..1ef9061
+Fast-forward
+ TODO.org | 10919 --------------------------------------------------------------------------------------------------------------------------------------------
+ 1 file changed, 10919 deletions(-)
+ delete mode 100644 TODO.org
+[2019-09-29 23:44:17.668876311] Committer: Committing changes to git
+(recording state in git...)
+
+Updating 1ef9061..e662a33
+Fast-forward
+ TODO.org | 10919 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 10919 insertions(+)
+ create mode 100644 TODO.org
+
+
+# Relevant output from .git/annex/daemon.log on the receiving side
+[2019-09-29 23:44:14.293079441] RemoteControl: Syncing with peer1 
+From tor-annex::rpxkm55i6gxlirqohcjup4g4orlgzyval2n2yymah36ekipjcppmrvid.onion:42294
+   28aa4b9..4bd9c99  master        -> peer1/master
+   28aa4b9..4bd9c99  synced/master -> peer1/synced/master
+
+Updating 28aa4b9..4bd9c99
+Fast-forward
+ TODO.org | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+[2019-09-29 23:44:16.054093704] Committer: Committing changes to git
+(recording state in git...)
+[2019-09-29 23:44:16.169742975] Pusher: Syncing with peer1 
+[2019-09-29 23:44:17.169984217] Committer: Committing changes to git
+(recording state in git...)
+To tor-annex::rpxkm55i6gxlirqohcjup4g4orlgzyval2n2yymah36ekipjcppmrvid.onion:42294
+   4bd9c99..1ef9061  master -> synced/master
+remote: error: refusing to update checked out branch: refs/heads/master        
+To tor-annex::rpxkm55i6gxlirqohcjup4g4orlgzyval2n2yymah36ekipjcppmrvid.onion:42294
+ ! [remote rejected] master -> master (branch is currently checked out)
+error: failed to push some refs to 'tor-annex::rpxkm55i6gxlirqohcjup4g4orlgzyval2n2yymah36ekipjcppmrvid.onion:42294'
+[2019-09-29 23:44:23.623525612] Pusher: Syncing with peer1 
+To tor-annex::rpxkm55i6gxlirqohcjup4g4orlgzyval2n2yymah36ekipjcppmrvid.onion:42294
+   1ef9061..e662a33  master -> synced/master
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/assistant_sometimes_removes_and_re-adds_whole_file/comment_1_52a4748fda6682e6e667501726fd05c6._comment b/doc/bugs/assistant_sometimes_removes_and_re-adds_whole_file/comment_1_52a4748fda6682e6e667501726fd05c6._comment
new file mode 100644
index 0000000000..37245b4276
--- /dev/null
+++ b/doc/bugs/assistant_sometimes_removes_and_re-adds_whole_file/comment_1_52a4748fda6682e6e667501726fd05c6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="I wonder if this is related to the use of tor"
+ date="2020-06-11T09:56:08Z"
+ content="""
+I'll try to test with a simple ssh remote.
+"""]]
diff --git a/doc/bugs/available_space_miscomputed_on_large_macOS_volume.mdwn b/doc/bugs/available_space_miscomputed_on_large_macOS_volume.mdwn
new file mode 100644
index 0000000000..82a882df62
--- /dev/null
+++ b/doc/bugs/available_space_miscomputed_on_large_macOS_volume.mdwn
@@ -0,0 +1,78 @@
+### Please describe the problem.
+
+`git-annex` is misreporting the available disk space on my large (98TiB) APFS volume on MacOS.
+
+### What steps will reproduce the problem?
+
+- acquire a large storage array (how large, unclear)
+- format with APFS on MacOS (no idea if it also occurs on on other platforms or file systems)
+- clone a git-annex repo onto it
+- look at `git annex info` / try to copy data
+
+Here's my `df` output:
+
+```
+Filesystem      Size    Used   Avail Capacity iused ifree %iused  Mounted on
+/dev/disk5s1    98Ti   2.2Ti    96Ti     3%     54k  1.0T    0%   /Volumes/ABYSS
+```
+
+And here's the `git annex info`:
+
+```
+trusted repositories: 0
+semitrusted repositories: 8
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	335d1827-1f6e-40d8-ae70-23ba9dd4b4a6 -- borg
+ 	4d887674-fb3f-47ee-afea-487f0143950e -- dvc
+ 	512ca1ff-43b7-4537-bf64-0f55e1ba2e8a -- cci server [origin]
+ 	71414f81-c837-4838-894d-840d0a2170ff -- [pocket]
+ 	dd695a7f-4b41-4a7d-ae57-3174f6a839e1 -- bsu server [grue]
+ 	df875036-d197-46f8-940c-9df5dc7fc2cd -- abyss [here]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 3.94 gigabytes (+100 megabytes reserved)
+local annex keys: 14380
+local annex size: 4.18 terabytes
+annexed files in working tree: 13312
+size of annexed files in working tree: 2.59 terabytes
+combined annex size of all repositories: 19.09 terabytes (+ 9 unknown size)
+annex sizes of repositories:
+	  5.57 TB: 512ca1ff-43b7-4537-bf64-0f55e1ba2e8a -- cci server [origin]
+ 	  4.18 TB: df875036-d197-46f8-940c-9df5dc7fc2cd -- abyss [here]
+ 	  3.21 TB: 71414f81-c837-4838-894d-840d0a2170ff -- [pocket]
+ 	  2.52 TB: 335d1827-1f6e-40d8-ae70-23ba9dd4b4a6 -- borg
+ 	  1.92 TB: dd695a7f-4b41-4a7d-ae57-3174f6a839e1 -- bsu server [grue]
+ 	879.87 GB: 00000000-0000-0000-0000-000000000001 -- web
+ 	819.55 GB: 4d887674-fb3f-47ee-afea-487f0143950e -- dvc
+backend usage:
+	SHA256: 6991
+	SHA256E: 6321
+bloom filter size: 32 mebibytes (2.9% full)
+```
+
+### What version of git-annex are you using? On what operating system?
+
+MacOS Sonoma 14.4.1, Git Annex version below:
+
+```
+git-annex version: 10.20240227
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24.1 bloomfilter-2.0.1.2 crypton-0.34 DAV-1.3.4 feed-1.3.2.1 ghc-9.6.3 http-client-0.7.16 persistent-sqlite-2.13.3.0 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin aarch64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+### Please provide any additional information below.
+
+I don't know what other file system versions (or operating systems) this may appear in, as this is the only 98TiB volume I have right now.
+
+I'm happy to do some poking around or test proposed fixes, I have some Haskell experience but it's been a while. My current instinct is that either `disk-free-space` is misbehaving on a disk this large for unclear reasons.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Been successfully using it for the last year+, for managing archives of academic research & teaching work and the assets for my web site. Generally quite happy :). Like it enough I want to use it schlep a few terabytes (and growing) onto my new Thunderbolt RAID array...
diff --git a/doc/bugs/available_space_miscomputed_on_large_macOS_volume/comment_1_cb1e92ef1412e68c12f6a1c9a10a7414._comment b/doc/bugs/available_space_miscomputed_on_large_macOS_volume/comment_1_cb1e92ef1412e68c12f6a1c9a10a7414._comment
new file mode 100644
index 0000000000..ea323e9c51
--- /dev/null
+++ b/doc/bugs/available_space_miscomputed_on_large_macOS_volume/comment_1_cb1e92ef1412e68c12f6a1c9a10a7414._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="mdekstrand"
+ avatar="http://cdn.libravatar.org/avatar/0acb8a6c848d39aa53d94bd81239b034"
+ subject="Update after transferring more files"
+ date="2024-04-09T14:45:07Z"
+ content="""
+After transferring many more files with `--force`, `git annex info` reports an available space of 17.46 terabytes, with following actual space:
+
+```
+$ df -h .
+Filesystem      Size    Used   Avail Capacity iused ifree %iused  Mounted on
+/dev/disk5s1    98Ti   2.3Ti    96Ti     3%     75k  1.0T    0%   /Volumes/ABYSS
+```
+
+I suspect the problem is either an integer overflow of some kind, or an integer size/precision error reading from the disk space struct in the disk space library.
+"""]]
diff --git a/doc/bugs/backend_option_for_init_is_in_no_effect__63__.mdwn b/doc/bugs/backend_option_for_init_is_in_no_effect__63__.mdwn
new file mode 100644
index 0000000000..7f69f9f678
--- /dev/null
+++ b/doc/bugs/backend_option_for_init_is_in_no_effect__63__.mdwn
@@ -0,0 +1,77 @@
+### Please describe the problem.
+
+`annex init --help` talks about supporting `--backend` so I expected either modification of .gitattributes to add backend, or at least non-persistent setting in .git/config ... but seems nothing is actually done?
+
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170525+gitge1cf095ae-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+$> git annex init --backend=MD5E
+init  ok
+(recording state in git...)
+(dev) 2 27354 [1].....................................:Wed 12 Jul 2017 07:08:21 PM EDT:.
+(git)hopa:/tmp/1233[master]
+$> cat .git/config 
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+[annex]
+	uuid = 8a045a11-af4a-43b6-922f-cf402efab619
+	version = 5
+(dev) 2 27355 [1].....................................:Wed 12 Jul 2017 07:08:26 PM EDT:.
+(git)hopa:/tmp/1233[master]
+$> git annex init --help        
+git-annex init - initialize git-annex
+
+Usage: git-annex init [DESC] [--version VALUE]
+
+Available options:
+  --version VALUE          Override default annex.version
+  --force                  allow actions that may lose annexed data
+  -F,--fast                avoid slow operations
+  -q,--quiet               avoid verbose output
+  -v,--verbose             allow verbose output (default)
+  -d,--debug               show debug messages
+  --no-debug               don't show debug messages
+  -b,--backend NAME        specify key-value backend to use
+  -N,--numcopies NUMBER    override default number of copies
+  --trust REMOTE           override trust setting
+  --semitrust REMOTE       override trust setting back to default
+  --untrust REMOTE         override trust setting to untrusted
+  -c,--config NAME=VALUE   override git configuration setting
+  --user-agent NAME        override default User-Agent
+  --trust-glacier          Trust Amazon Glacier inventory
+  --notify-finish          show desktop notification after transfer finishes
+  --notify-start           show desktop notification after transfer starts
+  -h,--help                Show this help text
+
+For details, run: git-annex help init
+(dev) 2 27356 [1].....................................:Wed 12 Jul 2017 07:08:31 PM EDT:.
+(git)hopa:/tmp/1233[master]
+$> ls
+(dev) 2 27357 [1].....................................:Wed 12 Jul 2017 07:08:39 PM EDT:.
+(git)hopa:/tmp/1233[master]
+$> ls -lta
+total 312
+drwx------   9 yoh  yoh    4096 Jul 12 19:08 .git/
+drwx------   3 yoh  yoh    4096 Jul 12 19:08 ./
+drwxrwxrwt 143 root root 307200 Jul 12 19:08 ../
+(dev) 2 27358 [1].....................................:Wed 12 Jul 2017 07:08:40 PM EDT:.
+(git)hopa:/tmp/1233[master]
+$> grep -r MD5E .
+
+
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+kinda
+
+> [[fixed|done]], --backend is no longer a global option. --[[Joey]]
diff --git a/doc/bugs/backend_option_for_init_is_in_no_effect__63__/comment_1_6b40b5ea277d8e28f0b632701a776587._comment b/doc/bugs/backend_option_for_init_is_in_no_effect__63__/comment_1_6b40b5ea277d8e28f0b632701a776587._comment
new file mode 100644
index 0000000000..f024c46937
--- /dev/null
+++ b/doc/bugs/backend_option_for_init_is_in_no_effect__63__/comment_1_6b40b5ea277d8e28f0b632701a776587._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-15T16:54:56Z"
+ content="""
+--backend is a global option, so it appears in every command's help.
+
+There are several of these global options left over from the previous
+option parsing regime.
+"""]]
diff --git a/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo.mdwn b/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo.mdwn
new file mode 100644
index 0000000000..459b08bcb5
--- /dev/null
+++ b/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo.mdwn
@@ -0,0 +1,15 @@
+### Please describe the problem.
+
+I have a git annex repository at `~/doc` which has a remote stored on a second drive at `/media/backup/doc.git`, which is a bare git annex repo.  The webapp is run from `~/doc`. Changes are made to `/media/backup/doc.git` by syncing from other computers, but then those changes to the remote are not automatically propagated to `~/doc` by the webapp.
+
+The use case that lead to this situation is syncing several computers to a large hard drive on a server, utilizing a bare repo as a full backup, and then wishing to have a client repo in the home folder on the server.  So other computers sync their repos to `/media/backup/doc.git` and then any changes should be propagated to `~/doc` on the server. 
+
+Changes made to `~/doc` *are* synced to the backup repository on the backup hard drive, and those changes are almost immediately synced to the other machines by the webapp running on those respective machines. Those computers are configured to connect to `/media/backup/doc.git` on the server using SSH only (and git-annex-shell on the server), and do not use XMPP. 
+
+### What version of git-annex are you using? On what operating system?
+
+The amd64 pre-built tarball, git-annex version: 6.20160613-g35dbe35, running on Ubuntu 16.04.  
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Migrated all of my syncing to git annex about 10 months ago and haven't had any significant trouble :)
diff --git a/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_1_66ffaa679ba0fe86bba114fd9cdc5a53._comment b/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_1_66ffaa679ba0fe86bba114fd9cdc5a53._comment
new file mode 100644
index 0000000000..698338b1b2
--- /dev/null
+++ b/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_1_66ffaa679ba0fe86bba114fd9cdc5a53._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Farhan"
+ subject="More Info"
+ date="2016-06-23T12:15:28Z"
+ content="""
+Can you please provide the following info? For curiosity's sake.
+
+When you are viewing the repos in the web app, on the right hand side for each repo is a drop down menu labelled \"actions\". Please click there and go to the option labelled \"Edit\". Click this option, and on the resulting page there should be a field labelled \"Repository group\". Can you tell us the \"Repository group\" for the repos you mentioned? What is the \"Repository group\" for the backup on the secondary drive, the repo in your home folder and the remote clients? My hunch is that these group types are not set up to reflect the configuration you want.
+"""]]
diff --git a/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_2_a7617cc63584dafb16bdc9373fb1e304._comment b/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_2_a7617cc63584dafb16bdc9373fb1e304._comment
new file mode 100644
index 0000000000..01b0e4cd0a
--- /dev/null
+++ b/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_2_a7617cc63584dafb16bdc9373fb1e304._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Don"
+ subject="comment 2"
+ date="2016-06-24T05:40:23Z"
+ content="""
+The bare repo on the external drive is configured as `full backup` and the repo at `~/doc` is `client`.  
+"""]]
diff --git a/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_3_ecb57e72c0bf583d1c3461313a83c4f2._comment b/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_3_ecb57e72c0bf583d1c3461313a83c4f2._comment
new file mode 100644
index 0000000000..15662ca519
--- /dev/null
+++ b/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_3_ecb57e72c0bf583d1c3461313a83c4f2._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Farhan"
+ subject="Thanks"
+ date="2016-06-24T06:35:10Z"
+ content="""
+And the other repositories (which are syncing correctly), they are also marked as client? Clients should sync with each other whenever they can connect to each other, but perhaps your client repositories cannot connect to each other?
+
+[Here is a comment from Joey](https://git-annex.branchable.com/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__/) about a similar setup. He says you might need to set up an XMPP account for the various clients to message each other when they have new changes? But that was a long time ago. And anyways it seems like the webapp would be doing this automatically (yet in your post you say the computers do not use XMPP?).
+
+I think everyone would benefit from more info still. For example, what does the webapp look like when you are syncing this repo? Are all the clients and the backup on the same page? Is each client only combined to the backup itself and no other repos? What kind of remote repos are the other computers?
+
+Hope you don't mind the questions, I'm also curious about this issue myself. Thanks for bringing it up.
+"""]]
diff --git a/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_4_bf0e16f9181438c2050521c5ff5bb7d0._comment b/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_4_bf0e16f9181438c2050521c5ff5bb7d0._comment
new file mode 100644
index 0000000000..e34ea04670
--- /dev/null
+++ b/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_4_bf0e16f9181438c2050521c5ff5bb7d0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Don"
+ subject="comment 4"
+ date="2016-06-24T07:16:20Z"
+ content="""
+Good questions.  The setup is essentially a star topology where the central node is the full-backup, bare git repository on the external drive on the server.  It's not encrypted, if that matters.  Since it's a bare repo, nothing actually changes in that node except when changes are pushed from elsewhere.  
+
+Every other node is configured as a client and is connected to that repo on the server via SSH.  When a change is made to one of the client repos, syncing is happening automatically and nearly instantaneously--not just to the server repo, but the changes are very quickly propagated to the other SSH-connected clients.  (I think this is supposed to happen for SSH repos now without using XMPP.  In the release notes for version 5.20140421: \"This release begins to deprecate XMPP support. In particular, if you use the assistant with a ssh remote that has this version of git-annex installed, you don't need XMPP any longer to get immediate syncing of changes.\")
+
+But then there's this one other node in the star topology---the client repo (non-bare) that is actually on the same system as the bare, backup repo.  When changes are made to the client, they are synced immediately to the backup repo, and those changes are quickly synced to the other client repos on other computers connected by SSH.  The problem is changes in the other direction; when a client repo on a remote system is changed, the updates are synced to the backup repo on the server, but no farther.  The webapp running on the server never (or only very slowly) syncs those changes to that client repo that is on the same system.  The webapp on the server is running with that local client repo as the \"main\" repo (I mean, the upper right hand corner says \"Repository: ~/doc\", which is the client repo).  All of the status messages are green and say that the repos are synced.  You can, of course, force a sync from there, and and then the changes are noticed and propagated to the client.
+
+I did some testing and it seems like repositories with non-bare remotes on the same filesystem are synced immediately using inotify or something.  Maybe this just doesn't happen for bare repos?  That's the variable that seems to make syncing not happen automatically, in my limited testing.  I can test more to isolate exactly when it happens, but I was hoping Joey would know off the top of his head if this should be working or not.
+
+"""]]
diff --git a/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_5_aeea3ff59c8493c87c313fbaf7614f20._comment b/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_5_aeea3ff59c8493c87c313fbaf7614f20._comment
new file mode 100644
index 0000000000..92241bf51a
--- /dev/null
+++ b/doc/bugs/bare_remote_is_not_automatically_synced_to_local_repo/comment_5_aeea3ff59c8493c87c313fbaf7614f20._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-06-07T16:40:18Z"
+ content="""
+This has nothing to do with repository groups; it's the git branch
+not getting synced by the assistant when master is updated in the
+bare repository.
+
+This is easy enough to repoduce.
+
+The assistant relies on `git annex remotedaemon` to notice changes in
+remotes, and the remotedaemon only supports remotes accessed via ssh, not
+on a local drive.
+
+The assistant has some special case handling for repositories on 
+removable drives, which lets those be plugged in and syncs with them.
+Removable drives are also why the remotedaemon does not watch repositories
+on a local drive. If the drive is removable, the remotedaemon would
+keep it always busy, by having directories open for inotify, 
+and so prevent a clean removal of the drive.
+
+So, I don't think anything can be done about this, at least in the default
+configuration. One workaround it using a ssh url for the remote will
+make the remotedaemon watch it for changes. 
+
+I could add a non-default configuration setting that
+makes a remote on a local drive be watched for changes.
+
+But, it's not clear to me why you'd want to have the changes be pushed
+in to a repository on a removable drive, rather than pushing/syncing
+with the repository where the assistant is running. The assistant would
+then sync changes it received on to the removable drive. That seems like a
+better setup, will still work when the drive is removed for a while,
+and is already supported.
+"""]]
diff --git a/doc/bugs/bare_remote_safe_directory.mdwn b/doc/bugs/bare_remote_safe_directory.mdwn
new file mode 100644
index 0000000000..b05c490ec4
--- /dev/null
+++ b/doc/bugs/bare_remote_safe_directory.mdwn
@@ -0,0 +1,15 @@
+    git init foo.git
+    cd foo.git
+    git-annex init
+    cd ..
+    git clone foo.git bar
+    sudo chown root.root foo.git
+    cd bar
+    git-annex init
+    init  fatal: not a git repository: /tmp/foo.git/.git'
+
+This is specific to bare git remotes, for non-bare it 
+detects and warns that safe.directory is needed to use the
+remote. --[[Joey]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/batch_commands_miss_journalled_changes_made_while_running.mdwn b/doc/bugs/batch_commands_miss_journalled_changes_made_while_running.mdwn
new file mode 100644
index 0000000000..09fc596841
--- /dev/null
+++ b/doc/bugs/batch_commands_miss_journalled_changes_made_while_running.mdwn
@@ -0,0 +1,12 @@
+--batch commands are supposed to notice changes that get made to the
+journal while they are running. This way, if two batch commands are run,
+one making changes and the other reading the values, the reader notices the
+changes.
+
+That does not currently happen. Looks like runUpdateOnce runs before 
+enableInteractiveBranchAccess, and so sets journalIgnorable. Only if the
+batch command writes to the journal does journalIgnorable get unset, and
+then the command will notice journalled changes by itself or others.
+But query commands 
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/be_consistent_with_git_in_handling_http__58____47____47___with___58___.mdwn b/doc/bugs/be_consistent_with_git_in_handling_http__58____47____47___with___58___.mdwn
new file mode 100644
index 0000000000..4bbc6fe71d
--- /dev/null
+++ b/doc/bugs/be_consistent_with_git_in_handling_http__58____47____47___with___58___.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+I have not checked if it is legit to have an "empty" port number in the (http) URL but I see that `git` itself handles it fine, but git-annex is not happy:
+
+```
+❯ git clone https://datasets.datalad.org:/dbic/QA/.git/
+Cloning into 'QA'...
+warning: redirecting to https://datasets.datalad.org/dbic/QA/.git/
+remote: Enumerating objects: 61661, done.
+remote: Counting objects: 100% (61661/61661), done.
+remote: Compressing objects: 100% (23181/23181), done.
+remote: Total 61661 (delta 31300), reused 56651 (delta 26299)
+Receiving objects: 100% (61661/61661), 33.27 MiB | 25.03 MiB/s, done.
+Resolving deltas: 100% (31300/31300), done.
+
+❯ git annex get sub-emmet/ses-20180508/anat/sub-emmet_ses-20180508_acq-MPRAGE_T1w.nii.gz
+
+  Remote origin not usable by git-annex; setting annex-ignore
+
+  https://datasets.datalad.org:/dbic/QA/.git//config download failed: Unsupported url scheme https://datasets.datalad.org:/dbic/QA/.git//config
+get sub-emmet/ses-20180508/anat/sub-emmet_ses-20180508_acq-MPRAGE_T1w.nii.gz (from datasets.datalad.org...) 
+(scanning for annexed files...)   
+ok
+(recording state in git...)
+```
+
+so it got the file only after enabling type=git special remote for the same location but with correct URL.
+
+I think it would be nice if git-annex was as robust as git in such cases to avoid "late surprise".
+
+Backstory: Happened to a user trying to access some NWB files on gin for DANDI project, here I used different/simpler/faster URL
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/be_consistent_with_git_in_handling_http__58____47____47___with___58___/comment_1_c41e4999eb41846eb841b6ce9802b77b._comment b/doc/bugs/be_consistent_with_git_in_handling_http__58____47____47___with___58___/comment_1_c41e4999eb41846eb841b6ce9802b77b._comment
new file mode 100644
index 0000000000..0ec25e2200
--- /dev/null
+++ b/doc/bugs/be_consistent_with_git_in_handling_http__58____47____47___with___58___/comment_1_c41e4999eb41846eb841b6ce9802b77b._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-02-10T17:04:51Z"
+ content="""
+Not a legal url really, RFC 1738 says "If the port is omitted, the colon is as well."
+But web browsers, curl, wget, etc do mostly seem to support it, so at least 
+Postel's law seems to apply..
+
+Here's the root cause of it failing:
+
+	ghci> parseRequest "https://datasets.datalad.org:/dbic/QA/.git/"
+	*** Exception: InvalidUrlException "https://datasets.datalad.org:/dbic/QA/.git/" "Invalid port"
+
+So http-conduit refuses to parse it and so can't be used to download it.
+
+Filed an issue, but I don't know if they'll want to change
+http-conduit to accept a malformed url.
+<https://github.com/snoyberg/http-client/issues/501>
+
+Since network-uri is able to parse it, into an URI
+that has `"uriPort = ":"`, git-annex could special 
+case handling of the empty port there, changing it to ""
+and so generating an url that http-conduit can parse.
+I've implemented this fix.
+"""]]
diff --git a/doc/bugs/bla__47__.git__47__annex__47__transfer__47__failed__47__download__47__...tmp__58___rename__58___resource_exhausted___40__No_space_left_on_device__41__.mdwn b/doc/bugs/bla__47__.git__47__annex__47__transfer__47__failed__47__download__47__...tmp__58___rename__58___resource_exhausted___40__No_space_left_on_device__41__.mdwn
new file mode 100644
index 0000000000..8b3b7c2c39
--- /dev/null
+++ b/doc/bugs/bla__47__.git__47__annex__47__transfer__47__failed__47__download__47__...tmp__58___rename__58___resource_exhausted___40__No_space_left_on_device__41__.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+
+I'm syncing the content of an annex to another annex on a fat32 partition connected with usb (on an ipod video, with rockbox). I created this annex  with "git init && git annex init", so it is using unlocked adusted branch.
+
+Here is the .git/config:
+
+    [core]
+            repositoryformatversion = 0
+            filemode = false
+            bare = false
+            logallrefupdates = true
+            symlinks = false
+            ignorecase = true
+    [annex]
+            uuid = 25e5f762-db7f-49ad-a504-93e02bba642f
+            sshcaching = false
+            crippledfilesystem = true
+            version = 7
+    [filter "annex"]
+            smudge = git-annex smudge %f
+            clean = git-annex smudge --clean %f
+
+
+
+The sync seems to go well, all files are being copied, but I see an error for each copy during the checksum:
+
+
+    ...
+    copy music/file.flac (to ipod...) 
+    SHA256E-s26126286--32b36b6ff0e9a667c588229f159ff7a553fcd08012b8a74a65bf9f09874044e2.flac
+     26,126,286 100%   25.21MB/s    0:00:00 (xfr#1, to-chk=0/1)
+    (checksum...) 
+      ../../../media/gueux/IPOD/audio/.git/annex/othertmp/927_692_SHA256E-s26126286--32b36b6ff0e9a667c588229f159ff7a553fcd08012b8a74a65bf9f09874044e2.flac.log: openFile: resource exhausted (No space left on device)
+    
+      ../../../media/gueux/IPOD/audio/.git/annex/transfer/failed/download/fa8db49d-df5f-4c65-9af4-712d38729ef0/SHA256E-s26126286--32b36b6ff0e9a667c588229f159ff7a553fcd08012b8a74a65bf9f09874044e2.flac26375-82266.tmp: rename: resource exhausted (No space left on device)
+    ok
+    ...
+
+Note that there is plenty space left on device (300 out of 500Go), and this happened since the beginning of the sync, when the disk was almost empty.
+
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+Debian sid,
+
+    git-annex version: 7.20190129
+    build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+    dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+    operating system: linux x86_64
+    supported repository versions: 5 7
+    upgrade supported from repository versions: 0 1 2 3 4 5 6
+    local repository version: 7
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sure, I love it, and unlocked branch is really a great addition for crippled filesystems!
diff --git a/doc/bugs/bla__47__.git__47__annex__47__transfer__47__failed__47__download__47__...tmp__58___rename__58___resource_exhausted___40__No_space_left_on_device__41__/comment_1_644835e95676da0aa38737b3419022e2._comment b/doc/bugs/bla__47__.git__47__annex__47__transfer__47__failed__47__download__47__...tmp__58___rename__58___resource_exhausted___40__No_space_left_on_device__41__/comment_1_644835e95676da0aa38737b3419022e2._comment
new file mode 100644
index 0000000000..5567112871
--- /dev/null
+++ b/doc/bugs/bla__47__.git__47__annex__47__transfer__47__failed__47__download__47__...tmp__58___rename__58___resource_exhausted___40__No_space_left_on_device__41__/comment_1_644835e95676da0aa38737b3419022e2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="comment 1"
+ date="2019-02-07T14:02:41Z"
+ content="""
+That looks like https://git-annex.branchable.com/bugs/VFAT_crazy_limit_on_max_filenames_in_directory/
+"""]]
diff --git a/doc/bugs/blake3_hash_support.mdwn b/doc/bugs/blake3_hash_support.mdwn
new file mode 100644
index 0000000000..1485e79ac3
--- /dev/null
+++ b/doc/bugs/blake3_hash_support.mdwn
@@ -0,0 +1,377 @@
+This is a patch that seems to work for my personal use.
+BLAKE3 does support variable lengths, but my code does not implement support for anything other than 256-bit (32-byte) digests.
+I'm not familiar enough with the codebase to be sure whether adding variable length support later is a backwards compatibility hazard or not.
+
+[[!format patch """
+From a661bf0ba954b86909fa2f6b58727294068ac082 Mon Sep 17 00:00:00 2001
+From: edef <edef@edef.eu>
+Date: Fri, 2 Dec 2022 12:16:44 +0000
+Subject: [PATCH v3 1/2] support BLAKE3
+
+This uses the blake3 package from Hackage, since cryptonite does not
+have BLAKE3 support yet.
+---
+ Backend/Hash.hs | 29 +++++++++++++++++++++++++++++
+ Types/Key.hs    |  6 ++++++
+ git-annex.cabal |  1 +
+ stack.yaml      |  1 +
+ 4 files changed, 37 insertions(+)
+
+diff --git a/Backend/Hash.hs b/Backend/Hash.hs
+index 550d8fc6c..809a82599 100644
+--- a/Backend/Hash.hs
++++ b/Backend/Hash.hs
+@@ -27,8 +27,11 @@ import qualified Data.ByteString as S
+ import qualified Data.ByteString.Short as S (toShort, fromShort)
+ import qualified Data.ByteString.Char8 as S8
+ import qualified Data.ByteString.Lazy as L
++import Data.IORef
++import Control.Arrow
+ import Control.DeepSeq
+ import Control.Exception (evaluate)
++import qualified BLAKE3
+ 
+ data Hash
+ 	= MD5Hash
+@@ -40,6 +43,7 @@ data Hash
+ 	| Blake2bpHash HashSize
+ 	| Blake2sHash HashSize
+ 	| Blake2spHash HashSize
++	| Blake3Hash
+ 
+ cryptographicallySecure :: Hash -> Bool
+ cryptographicallySecure (SHA2Hash _) = True
+@@ -49,6 +53,7 @@ cryptographicallySecure (Blake2bHash _) = True
+ cryptographicallySecure (Blake2bpHash _) = True
+ cryptographicallySecure (Blake2sHash _) = True
+ cryptographicallySecure (Blake2spHash _) = True
++cryptographicallySecure Blake3Hash = True
+ cryptographicallySecure SHA1Hash = False
+ cryptographicallySecure MD5Hash = False
+ 
+@@ -63,6 +68,7 @@ hashes = concat
+ 	, map (Blake2bpHash . HashSize) [512]
+ 	, map (Blake2sHash . HashSize) [256, 160, 224]
+ 	, map (Blake2spHash . HashSize) [256, 224]
++	, [Blake3Hash]
+ 	, [SHA1Hash]
+ 	, [MD5Hash]
+ 	]
+@@ -99,6 +105,7 @@ hashKeyVariety (Blake2bHash size) he = Blake2bKey size he
+ hashKeyVariety (Blake2bpHash size) he = Blake2bpKey size he
+ hashKeyVariety (Blake2sHash size) he = Blake2sKey size he
+ hashKeyVariety (Blake2spHash size) he = Blake2spKey size he
++hashKeyVariety Blake3Hash he = Blake3Key he
+ 
+ {- A key is a hash of its contents. -}
+ keyValue :: Hash -> KeySource -> MeterUpdate -> Annex Key
+@@ -219,6 +226,7 @@ hasher (Blake2bHash hashsize) = blake2bHasher hashsize
+ hasher (Blake2bpHash hashsize) = blake2bpHasher hashsize
+ hasher (Blake2sHash hashsize) = blake2sHasher hashsize
+ hasher (Blake2spHash hashsize) = blake2spHasher hashsize
++hasher Blake3Hash = blake3Hasher
+ 
+ mkHasher :: HashAlgorithm h => (L.ByteString -> Digest h) -> Context h -> Hasher
+ mkHasher h c = (show . h, mkIncrementalVerifier c descChecksum . sameCheckSum)
+@@ -272,6 +280,27 @@ blake2spHasher (HashSize hashsize)
+ 	| hashsize == 224 = mkHasher blake2sp_224 blake2sp_224_context
+ 	| otherwise = error $ "unsupported BLAKE2SP size " ++ show hashsize
+ 
++blake3Hasher :: Hasher
++blake3Hasher = (hash, incremental) where
++	finalize :: BLAKE3.Hasher -> BLAKE3.Digest BLAKE3.DEFAULT_DIGEST_LEN
++	finalize = BLAKE3.finalize
++
++	hash :: L.ByteString -> String
++	hash = show . finalize . L.foldlChunks ((. pure) . BLAKE3.update) BLAKE3.hasher
++
++	incremental :: Key -> IO IncrementalVerifier
++	incremental k = do
++		v <- newIORef (Just (BLAKE3.hasher, 0))
++		return $ IncrementalVerifier
++			{ updateIncrementalVerifier = \b ->
++				modifyIORef' v . fmap $ flip BLAKE3.update [b] *** (fromIntegral (S.length b) +)
++			, finalizeIncrementalVerifier =
++				fmap (sameCheckSum k . show . finalize . fst) <$> readIORef v
++			, unableIncrementalVerifier = writeIORef v Nothing
++			, positionIncrementalVerifier = fmap snd <$> readIORef v
++			, descIncrementalVerifier = descChecksum
++			}
++
+ sha1Hasher :: Hasher
+ sha1Hasher = mkHasher sha1 sha1_context
+ 
+diff --git a/Types/Key.hs b/Types/Key.hs
+index 271723982..43f64a74d 100644
+--- a/Types/Key.hs
++++ b/Types/Key.hs
+@@ -214,6 +214,7 @@ data KeyVariety
+ 	| Blake2bpKey HashSize HasExt
+ 	| Blake2sKey HashSize HasExt
+ 	| Blake2spKey HashSize HasExt
++	| Blake3Key HasExt
+ 	| SHA1Key HasExt
+ 	| MD5Key HasExt
+ 	| WORMKey
+@@ -247,6 +248,7 @@ hasExt (Blake2bKey _ (HasExt b)) = b
+ hasExt (Blake2bpKey _ (HasExt b)) = b
+ hasExt (Blake2sKey _ (HasExt b)) = b
+ hasExt (Blake2spKey _ (HasExt b)) = b
++hasExt (Blake3Key (HasExt b)) = b
+ hasExt (SHA1Key (HasExt b)) = b
+ hasExt (MD5Key (HasExt b)) = b
+ hasExt WORMKey = False
+@@ -262,6 +264,7 @@ sameExceptExt (Blake2bKey sz1 _) (Blake2bKey sz2 _) = sz1 == sz2
+ sameExceptExt (Blake2bpKey sz1 _) (Blake2bpKey sz2 _) = sz1 == sz2
+ sameExceptExt (Blake2sKey sz1 _) (Blake2sKey sz2 _) = sz1 == sz2
+ sameExceptExt (Blake2spKey sz1 _) (Blake2spKey sz2 _) = sz1 == sz2
++sameExceptExt (Blake3Key _) (Blake3Key _) = True
+ sameExceptExt (SHA1Key _) (SHA1Key _) = True
+ sameExceptExt (MD5Key _) (MD5Key _) = True
+ sameExceptExt _ _ = False
+@@ -275,6 +278,7 @@ formatKeyVariety v = case v of
+ 	Blake2bpKey sz e -> adde e (addsz sz "BLAKE2BP")
+ 	Blake2sKey sz e -> adde e (addsz sz "BLAKE2S")
+ 	Blake2spKey sz e -> adde e (addsz sz "BLAKE2SP")
++	Blake3Key e -> adde e "BLAKE3_256"
+ 	SHA1Key e -> adde e "SHA1"
+ 	MD5Key e -> adde e "MD5"
+ 	WORMKey -> "WORM"
+@@ -337,6 +341,8 @@ parseKeyVariety "BLAKE2SP224"  = Blake2spKey (HashSize 224) (HasExt False)
+ parseKeyVariety "BLAKE2SP224E" = Blake2spKey (HashSize 224) (HasExt True)
+ parseKeyVariety "BLAKE2SP256"  = Blake2spKey (HashSize 256) (HasExt False)
+ parseKeyVariety "BLAKE2SP256E" = Blake2spKey (HashSize 256) (HasExt True)
++parseKeyVariety "BLAKE3_256"   = Blake3Key (HasExt False)
++parseKeyVariety "BLAKE3_256E"  = Blake3Key (HasExt True)
+ parseKeyVariety "SHA1"         = SHA1Key (HasExt False)
+ parseKeyVariety "SHA1E"        = SHA1Key (HasExt True)
+ parseKeyVariety "MD5"          = MD5Key (HasExt False)
+diff --git a/git-annex.cabal b/git-annex.cabal
+index eb9b68cbc..30614e156 100644
+--- a/git-annex.cabal
++++ b/git-annex.cabal
+@@ -362,6 +362,7 @@ Executable git-annex
+    securemem,
+    crypto-api,
+    cryptonite (>= 0.23),
++   blake3,
+    memory,
+    deepseq,
+    split,
+diff --git a/stack.yaml b/stack.yaml
+index 7dbfb657a..936ee841b 100644
+--- a/stack.yaml
++++ b/stack.yaml
+@@ -25,3 +25,4 @@ extra-deps:
+ - base64-bytestring-1.0.0.3
+ - bencode-0.6.1.1
+ - http-client-0.7.9
++- blake3-0.2@sha256:d1146b9a51ccfbb0532780778b6d016a614e3d44c05d8c1923dde9a8be869045,2448
+"""]]
+
+[[!format patch """
+From 9385299c5d9d7862ec2768ef57cab1fb7f59695d Mon Sep 17 00:00:00 2001
+From: edef <edef@edef.eu>
+Date: Fri, 16 Dec 2022 14:37:53 +0000
+Subject: [PATCH v3 2/2] make BLAKE3 support optional
+
+This sticks it behind a build flag, since not all distros ship the
+blake3 package.
+---
+ Backend/Hash.hs | 19 +++++++++++++++++--
+ Types/Key.hs    | 11 +++++++++++
+ git-annex.cabal |  9 ++++++++-
+ 3 files changed, 36 insertions(+), 3 deletions(-)
+
+diff --git a/Backend/Hash.hs b/Backend/Hash.hs
+index 809a82599..4e9a75725 100644
+--- a/Backend/Hash.hs
++++ b/Backend/Hash.hs
+@@ -5,6 +5,7 @@
+  - Licensed under the GNU AGPL version 3 or higher.
+  -}
+ 
++{-# LANGUAGE CPP #-}
+ {-# LANGUAGE OverloadedStrings #-}
+ 
+ module Backend.Hash (
+@@ -27,11 +28,13 @@ import qualified Data.ByteString as S
+ import qualified Data.ByteString.Short as S (toShort, fromShort)
+ import qualified Data.ByteString.Char8 as S8
+ import qualified Data.ByteString.Lazy as L
+-import Data.IORef
+-import Control.Arrow
+ import Control.DeepSeq
+ import Control.Exception (evaluate)
++#ifdef WITH_BLAKE3
++import Data.IORef
++import Control.Arrow
+ import qualified BLAKE3
++#endif
+ 
+ data Hash
+ 	= MD5Hash
+@@ -43,7 +46,9 @@ data Hash
+ 	| Blake2bpHash HashSize
+ 	| Blake2sHash HashSize
+ 	| Blake2spHash HashSize
++#ifdef WITH_BLAKE3
+ 	| Blake3Hash
++#endif
+ 
+ cryptographicallySecure :: Hash -> Bool
+ cryptographicallySecure (SHA2Hash _) = True
+@@ -53,7 +58,9 @@ cryptographicallySecure (Blake2bHash _) = True
+ cryptographicallySecure (Blake2bpHash _) = True
+ cryptographicallySecure (Blake2sHash _) = True
+ cryptographicallySecure (Blake2spHash _) = True
++#ifdef WITH_BLAKE3
+ cryptographicallySecure Blake3Hash = True
++#endif
+ cryptographicallySecure SHA1Hash = False
+ cryptographicallySecure MD5Hash = False
+ 
+@@ -68,7 +75,9 @@ hashes = concat
+ 	, map (Blake2bpHash . HashSize) [512]
+ 	, map (Blake2sHash . HashSize) [256, 160, 224]
+ 	, map (Blake2spHash . HashSize) [256, 224]
++#ifdef WITH_BLAKE3
+ 	, [Blake3Hash]
++#endif
+ 	, [SHA1Hash]
+ 	, [MD5Hash]
+ 	]
+@@ -105,7 +114,9 @@ hashKeyVariety (Blake2bHash size) he = Blake2bKey size he
+ hashKeyVariety (Blake2bpHash size) he = Blake2bpKey size he
+ hashKeyVariety (Blake2sHash size) he = Blake2sKey size he
+ hashKeyVariety (Blake2spHash size) he = Blake2spKey size he
++#ifdef WITH_BLAKE3
+ hashKeyVariety Blake3Hash he = Blake3Key he
++#endif
+ 
+ {- A key is a hash of its contents. -}
+ keyValue :: Hash -> KeySource -> MeterUpdate -> Annex Key
+@@ -226,7 +237,9 @@ hasher (Blake2bHash hashsize) = blake2bHasher hashsize
+ hasher (Blake2bpHash hashsize) = blake2bpHasher hashsize
+ hasher (Blake2sHash hashsize) = blake2sHasher hashsize
+ hasher (Blake2spHash hashsize) = blake2spHasher hashsize
++#ifdef WITH_BLAKE3
+ hasher Blake3Hash = blake3Hasher
++#endif
+ 
+ mkHasher :: HashAlgorithm h => (L.ByteString -> Digest h) -> Context h -> Hasher
+ mkHasher h c = (show . h, mkIncrementalVerifier c descChecksum . sameCheckSum)
+@@ -280,6 +293,7 @@ blake2spHasher (HashSize hashsize)
+ 	| hashsize == 224 = mkHasher blake2sp_224 blake2sp_224_context
+ 	| otherwise = error $ "unsupported BLAKE2SP size " ++ show hashsize
+ 
++#ifdef WITH_BLAKE3
+ blake3Hasher :: Hasher
+ blake3Hasher = (hash, incremental) where
+ 	finalize :: BLAKE3.Hasher -> BLAKE3.Digest BLAKE3.DEFAULT_DIGEST_LEN
+@@ -300,6 +314,7 @@ blake3Hasher = (hash, incremental) where
+ 			, positionIncrementalVerifier = fmap snd <$> readIORef v
+ 			, descIncrementalVerifier = descChecksum
+ 			}
++#endif
+ 
+ sha1Hasher :: Hasher
+ sha1Hasher = mkHasher sha1 sha1_context
+diff --git a/Types/Key.hs b/Types/Key.hs
+index 43f64a74d..806bdc034 100644
+--- a/Types/Key.hs
++++ b/Types/Key.hs
+@@ -5,6 +5,7 @@
+  - Licensed under the GNU AGPL version 3 or higher.
+  -}
+ 
++{-# LANGUAGE CPP #-}
+ {-# LANGUAGE OverloadedStrings, DeriveGeneric #-}
+ 
+ module Types.Key (
+@@ -214,7 +215,9 @@ data KeyVariety
+ 	| Blake2bpKey HashSize HasExt
+ 	| Blake2sKey HashSize HasExt
+ 	| Blake2spKey HashSize HasExt
++#ifdef WITH_BLAKE3
+ 	| Blake3Key HasExt
++#endif
+ 	| SHA1Key HasExt
+ 	| MD5Key HasExt
+ 	| WORMKey
+@@ -248,7 +251,9 @@ hasExt (Blake2bKey _ (HasExt b)) = b
+ hasExt (Blake2bpKey _ (HasExt b)) = b
+ hasExt (Blake2sKey _ (HasExt b)) = b
+ hasExt (Blake2spKey _ (HasExt b)) = b
++#ifdef WITH_BLAKE3
+ hasExt (Blake3Key (HasExt b)) = b
++#endif
+ hasExt (SHA1Key (HasExt b)) = b
+ hasExt (MD5Key (HasExt b)) = b
+ hasExt WORMKey = False
+@@ -264,7 +269,9 @@ sameExceptExt (Blake2bKey sz1 _) (Blake2bKey sz2 _) = sz1 == sz2
+ sameExceptExt (Blake2bpKey sz1 _) (Blake2bpKey sz2 _) = sz1 == sz2
+ sameExceptExt (Blake2sKey sz1 _) (Blake2sKey sz2 _) = sz1 == sz2
+ sameExceptExt (Blake2spKey sz1 _) (Blake2spKey sz2 _) = sz1 == sz2
++#ifdef WITH_BLAKE3
+ sameExceptExt (Blake3Key _) (Blake3Key _) = True
++#endif
+ sameExceptExt (SHA1Key _) (SHA1Key _) = True
+ sameExceptExt (MD5Key _) (MD5Key _) = True
+ sameExceptExt _ _ = False
+@@ -278,7 +285,9 @@ formatKeyVariety v = case v of
+ 	Blake2bpKey sz e -> adde e (addsz sz "BLAKE2BP")
+ 	Blake2sKey sz e -> adde e (addsz sz "BLAKE2S")
+ 	Blake2spKey sz e -> adde e (addsz sz "BLAKE2SP")
++#ifdef WITH_BLAKE3
+ 	Blake3Key e -> adde e "BLAKE3_256"
++#endif
+ 	SHA1Key e -> adde e "SHA1"
+ 	MD5Key e -> adde e "MD5"
+ 	WORMKey -> "WORM"
+@@ -341,8 +350,10 @@ parseKeyVariety "BLAKE2SP224"  = Blake2spKey (HashSize 224) (HasExt False)
+ parseKeyVariety "BLAKE2SP224E" = Blake2spKey (HashSize 224) (HasExt True)
+ parseKeyVariety "BLAKE2SP256"  = Blake2spKey (HashSize 256) (HasExt False)
+ parseKeyVariety "BLAKE2SP256E" = Blake2spKey (HashSize 256) (HasExt True)
++#ifdef WITH_BLAKE3
+ parseKeyVariety "BLAKE3_256"   = Blake3Key (HasExt False)
+ parseKeyVariety "BLAKE3_256E"  = Blake3Key (HasExt True)
++#endif
+ parseKeyVariety "SHA1"         = SHA1Key (HasExt False)
+ parseKeyVariety "SHA1E"        = SHA1Key (HasExt True)
+ parseKeyVariety "MD5"          = MD5Key (HasExt False)
+diff --git a/git-annex.cabal b/git-annex.cabal
+index 30614e156..0778948fb 100644
+--- a/git-annex.cabal
++++ b/git-annex.cabal
+@@ -288,6 +288,10 @@ Flag GitLfs
+   Description: Build with git-lfs library (rather than vendored copy)
+   Default: True
+ 
++Flag Blake3
++  Description: Enable blake3 support
++  Default: True
++
+ source-repository head
+   type: git
+   location: git://git-annex.branchable.com/
+@@ -362,7 +366,6 @@ Executable git-annex
+    securemem,
+    crypto-api,
+    cryptonite (>= 0.23),
+-   blake3,
+    memory,
+    deepseq,
+    split,
+@@ -572,6 +575,10 @@ Executable git-annex
+       CPP-Options: -DWITH_DBUS -DWITH_DESKTOP_NOTIFY -DWITH_DBUS_NOTIFICATIONS
+       Other-Modules: Utility.DBus
+ 
++  if flag(Blake3)
++    Build-Depends: blake3
++    CPP-Options: -DWITH_BLAKE3
++
+   if flag(Pairing)
+     Build-Depends: network-multicast, network-info
+     CPP-Options: -DWITH_PAIRING
+"""]]
diff --git a/doc/bugs/blake3_hash_support/comment_1_723a531dad2df722514a7cbf1b8e0d8a._comment b/doc/bugs/blake3_hash_support/comment_1_723a531dad2df722514a7cbf1b8e0d8a._comment
new file mode 100644
index 0000000000..ff0df34668
--- /dev/null
+++ b/doc/bugs/blake3_hash_support/comment_1_723a531dad2df722514a7cbf1b8e0d8a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="blake3 enhancement"
+ date="2022-12-11T19:25:27Z"
+ content="""
+Seems like this should be under [[todo]] suggestions -- maybe repost there?
+
+"""]]
diff --git a/doc/bugs/blake3_hash_support/comment_2_7be0932328ba4f49c33b0ab14429a283._comment b/doc/bugs/blake3_hash_support/comment_2_7be0932328ba4f49c33b0ab14429a283._comment
new file mode 100644
index 0000000000..e4bbda8c59
--- /dev/null
+++ b/doc/bugs/blake3_hash_support/comment_2_7be0932328ba4f49c33b0ab14429a283._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-12-12T16:22:17Z"
+ content="""
+Thanks for the patch.
+
+I do think it would make sense to include "256" in the name of the backend,
+unless BLAKE3 recommends against using other lengths for some good reason.
+
+As for accepting this patch, the added dependency makes it harder. This
+would require distributions like Debian add the blake3 package. If
+cryptonite included it, that would be much easier -- though it would still 
+need ifdefs to support the old versions of crytonite for some time.
+
+Going the current route with adding a blake3 depdenency would need to start
+with it as a build flag..
+"""]]
diff --git a/doc/bugs/blake3_hash_support/comment_3_a28c55a1d6158e301cc63d6087d8ab0e._comment b/doc/bugs/blake3_hash_support/comment_3_a28c55a1d6158e301cc63d6087d8ab0e._comment
new file mode 100644
index 0000000000..2489306b98
--- /dev/null
+++ b/doc/bugs/blake3_hash_support/comment_3_a28c55a1d6158e301cc63d6087d8ab0e._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="edef"
+ subject="""comment 3"""
+ date="2022-12-16T13:53:04Z"
+ content="""
+> I do think it would make sense to include "256" in the name of the backend,
+> unless BLAKE3 recommends against using other lengths for some good reason.
+
+Done.
+
+> Going the current route with adding a blake3 depdenency would need to start
+> with it as a build flag..
+
+I've added a followup patch that makes blake3 into a build flag. I'm
+happy to roll with that for now, if that gets code merged. I'm not
+particularly satisfied by the existing BLAKE3 libraries for Haskell,
+so I might opt to roll a nicer one with proper parallelism when I have
+some time to spare.
+
+It appears that some flags switch between a vendored library copy and
+an external dependency (namely, the git-lfs flag), maybe that's an
+alternative option for the interim?
+"""]]
diff --git a/doc/bugs/blake3_hash_support/comment_4_3ef2af8eb62a81299e49a3b7dccd337e._comment b/doc/bugs/blake3_hash_support/comment_4_3ef2af8eb62a81299e49a3b7dccd337e._comment
new file mode 100644
index 0000000000..e41f3066d8
--- /dev/null
+++ b/doc/bugs/blake3_hash_support/comment_4_3ef2af8eb62a81299e49a3b7dccd337e._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-12-26T16:26:45Z"
+ content="""
+I've only vendored libraries that I developed myself,
+that made sense to split out of git-annex. I don't want to get into
+vendoring other stuff here. But I think a build flag is ok, it does not
+need vendoring.
+
+Looking at the code, I suspect that updateIncrementalVerifier
+might have a space leak. It does not force the S.length to be evaluated.
+And BLAKE3.update might also be lazy, I am not sure?
+Compare with the very similar code in mkIncrementalHasher,
+which is careful to force the length and also the hash update.
+
+Also I would prefer not to use Control.Arrow just because I'm not
+idiomatically familiar with it. Not that `***` is very complicated,
+but it obfuscates the code slightly for me.
+
+So, I would be happier if that part of the code were changed to just
+spell it all out and force everything like mkIncrementalHasher does.
+(Or if mkIncrementalHasher were generalized so that it could reuse its
+code. Looks doable by parameterizing hashUpdate and hashFinalize.)
+
+Also doc/backends.mdwn will need to be updated.
+
+The rest of the code looks good and I'm ready to merge it once the above
+are addressed.
+"""]]
diff --git a/doc/bugs/broken_repo_when_inodes_exhausted.mdwn b/doc/bugs/broken_repo_when_inodes_exhausted.mdwn
new file mode 100644
index 0000000000..3c03478811
--- /dev/null
+++ b/doc/bugs/broken_repo_when_inodes_exhausted.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+I found one of my repos damaged after letting the webapp sync with it for a while.  The filesystem inodes were exhausted and all the refs pointed to objects that do not exist.
+
+### What steps will reproduce the problem?
+I expect this issue to be reproduced by syncing to a filesystem without enough free inodes to hold the incoming files.
+
+### What version of git-annex are you using? On what operating system?
+This repo is using git-annex 6.20160229-g37a89cc
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+$ git status
+fatal: bad object HEAD
+$ git pull
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/git-annex does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/git-annex does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/git-annex does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/git-annex does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+remote: Counting objects: 3, done.
+remote: Compressing objects: 100% (3/3), done.
+remote: Total 3 (delta 0), reused 0 (delta 0)
+Unpacking objects: 100% (3/3), done.
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/git-annex does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+fatal: bad object HEAD
+error: /home/olpc/annex-ext4 did not send all necessary objects
+
+Auto packing the repository in background for optimum performance.
+See "git help gc" for manual housekeeping.
+error: The last gc run reported the following. Please correct the root cause
+and remove .git/gc.log.
+Automatic cleanup will not be performed until the file is removed.
+
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/git-annex does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/beta/master does not point to a valid object!
+error: refs/remotes/beta/synced/master does not point to a valid object!
+error: refs/remotes/halloween/master does not point to a valid object!
+error: refs/remotes/halloween/synced/master does not point to a valid object!
+fatal: bad object HEAD
+error: failed to run repack
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I'm running into a few issues but I intend to work through them.  
diff --git a/doc/bugs/broken_repo_when_inodes_exhausted/comment_1_8ccfac4cea4c54029b96b436ac2114ed._comment b/doc/bugs/broken_repo_when_inodes_exhausted/comment_1_8ccfac4cea4c54029b96b436ac2114ed._comment
new file mode 100644
index 0000000000..c71e59fcd5
--- /dev/null
+++ b/doc/bugs/broken_repo_when_inodes_exhausted/comment_1_8ccfac4cea4c54029b96b436ac2114ed._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-27T16:55:36Z"
+ content="""
+Pretty much anything is going to break when you run out of inodes; 
+all the errors shown here are due to the git repository getting
+inconsistent because of it. I don't see any part that's git-annex specific.
+
+Is `git annex repair` able to repair it at all? I'd expect it would be able
+to, as long as `git fsck` reports that there are problems.
+"""]]
diff --git a/doc/bugs/broken_repo_when_inodes_exhausted/comment_2_4c6ced0d3163735c7f4bd5a4a7053159._comment b/doc/bugs/broken_repo_when_inodes_exhausted/comment_2_4c6ced0d3163735c7f4bd5a4a7053159._comment
new file mode 100644
index 0000000000..270968bbcc
--- /dev/null
+++ b/doc/bugs/broken_repo_when_inodes_exhausted/comment_2_4c6ced0d3163735c7f4bd5a4a7053159._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="comment 2"
+ date="2016-05-18T09:43:13Z"
+ content="""
+Thanks.  It turns out I'd deleted that repo in order to free the inodes up.  Next time I will see if I can repair.
+
+But it would be nice if git-annex tracked inodes the way it tracks free space, so that it could refrain from causing the inode exhaustion.  This also would have alerted me to how few inodes I had remaining.
+"""]]
diff --git a/doc/bugs/build_for_OpenBSD_is_outdated.mdwn b/doc/bugs/build_for_OpenBSD_is_outdated.mdwn
new file mode 100644
index 0000000000..c435ba531c
--- /dev/null
+++ b/doc/bugs/build_for_OpenBSD_is_outdated.mdwn
@@ -0,0 +1,16 @@
+### Please describe the problem.
+The version of git-annex available on OpenBSD is quite old.
+I've tried building a more recent version with cabal install git-annex, but this also failed. I guess these tools are also rather old.
+Unfortunately I have zero experience with Haskell and only mediocre OpenBSD skills. 
+I'm hoping someone can pick this up and build a more up-to-date version.
+
+- git-annex-8.20210223p1
+- cabal-install-3.4.0.0p2
+- ghc-8.10.6p0
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I've used it extensively during my time at university to keep track of materials and assignments. It ever let me down.
+Unfortunately I later lost the data due to multiple corrupted external disks and backup drives with LUKS where I didn't remember the password. Luckily I had no use for it anymore anyway.
+I'm hoping to use it again, this time in an effort to disconnect.
+
+> [[done]] --[[Joey]] 
diff --git a/doc/bugs/build_for_OpenBSD_is_outdated/comment_1_59d9f99747cd3ba93a87ba634824d4ca._comment b/doc/bugs/build_for_OpenBSD_is_outdated/comment_1_59d9f99747cd3ba93a87ba634824d4ca._comment
new file mode 100644
index 0000000000..f0d1abb5df
--- /dev/null
+++ b/doc/bugs/build_for_OpenBSD_is_outdated/comment_1_59d9f99747cd3ba93a87ba634824d4ca._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-03-21T17:26:23Z"
+ content="""
+You will need to get in touch with the OpenBSD maintainers to get them to
+update the package. Nothing that filing a bug here can do about it.
+
+Unless there is some problem with the git-annex code that is preventing
+them from building a newer version of course.
+
+ghc 8.10 is not old at all, it's a commonly used version, and the version of
+cabal is also recent enough. git-annex should build with those versions.
+"""]]
diff --git a/doc/bugs/build_for_OpenBSD_is_outdated/comment_2_cb4f3d710b0c46b27bebed48bd2e9a21._comment b/doc/bugs/build_for_OpenBSD_is_outdated/comment_2_cb4f3d710b0c46b27bebed48bd2e9a21._comment
new file mode 100644
index 0000000000..6a510d77a2
--- /dev/null
+++ b/doc/bugs/build_for_OpenBSD_is_outdated/comment_2_cb4f3d710b0c46b27bebed48bd2e9a21._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="gnezdo"
+ avatar="http://cdn.libravatar.org/avatar/4176f99bc203b65ebe09a539a3b9c6bb"
+ subject="Fixed"
+ date="2022-04-23T21:42:42Z"
+ content="""
+This has been [fixed in -current on Apr 13](https://github.com/openbsd/ports/commit/a9f826b37e077cd0004f4ef4e7e0ddaa18ffdc4a).
+"""]]
diff --git a/doc/bugs/build_for_OpenBSD_is_outdated/comment_3_99e6c86785c91b8320ec1e7df1e02e2c._comment b/doc/bugs/build_for_OpenBSD_is_outdated/comment_3_99e6c86785c91b8320ec1e7df1e02e2c._comment
new file mode 100644
index 0000000000..fd5865bae5
--- /dev/null
+++ b/doc/bugs/build_for_OpenBSD_is_outdated/comment_3_99e6c86785c91b8320ec1e7df1e02e2c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-05-02T18:25:12Z"
+ content="""
+This is not the place to file bug reports about a distribution of git-annex
+by eg OpenBSD or a Linux distribution being out of date. In the future,
+file the bug with the distributor, which is where the changes need to
+happen to update it.
+
+The exception, of course, is if something about git-annex is preventing the
+distributor from upgrading it.
+"""]]
diff --git a/doc/bugs/bup_often_errors_out_when_-J___62___1.mdwn b/doc/bugs/bup_often_errors_out_when_-J___62___1.mdwn
new file mode 100644
index 0000000000..f98a123b72
--- /dev/null
+++ b/doc/bugs/bup_often_errors_out_when_-J___62___1.mdwn
@@ -0,0 +1,44 @@
+### Please describe the problem.
+
+When copying to a bup remote with -J many copies "fail":
+
+```
+copy samba-2.2.3a/packaging/LSB/lsb-samba.spec (to bup...) 
+  user error (bup ["split","-r","/tmp/silesia_bup","-q","-n","SHA256E-s2260--1e95bcc60c9b332608774459570b80ab9576b5e971013a30ff6da6d93ebcfd9d.spec"] exited 1)
+```
+
+They actually seem to complete in some sense though as trying to copy them again will print `ok` instantly.
+
+### What steps will reproduce the problem?
+
+    git annex copy --to bup -J2
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 10.20220624
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.11 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+```
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+It's amazing and I use it every day :)
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_1_1731cfb2662890299ca6daeacdd4bb47._comment b/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_1_1731cfb2662890299ca6daeacdd4bb47._comment
new file mode 100644
index 0000000000..6659b61e8d
--- /dev/null
+++ b/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_1_1731cfb2662890299ca6daeacdd4bb47._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-05T15:57:26Z"
+ content="""
+This seems most likely to be a concurrency issue in bup itself, or in how
+it uses git.
+
+However, I have not been able to reproduce it so far. I tried making 8
+different files each 100 mb, and was able to copy them all to a bup repository
+concurrently with no failures.
+
+That was with bup 0.32. What is your bup version?
+
+It would be good to know what error message bup outputs.
+Unfortunately, since `bup split -q` is noisy on stderr, git-annex
+sinks it to /dev/null and so you don't see it.
+
+I've changed git-annex to display the stderr when `bup split` fails.
+So if you can get an updated build of git-annex, and reproduce this problem,
+we'll be able to see if this is a bug in bup, or what.
+"""]]
diff --git a/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_2_f0f87b7a2c60afba609072566b0048ac._comment b/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_2_f0f87b7a2c60afba609072566b0048ac._comment
new file mode 100644
index 0000000000..1b5e98c3ba
--- /dev/null
+++ b/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_2_f0f87b7a2c60afba609072566b0048ac._comment
@@ -0,0 +1,190 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 2"
+ date="2022-08-07T08:05:23Z"
+ content="""
+Thanks for looking into this!
+
+> However, I have not been able to reproduce it so far. I tried making 8 different files each 100 mb, and was able to copy them all to a bup repository concurrently with no failures.
+
+You need more than that; 8 Files might randomly work without error.
+
+Perhaps it only really manifests itself on smaller files? That's mainly what I've been copying.
+
+Here's an example output of git-annex 6d762fafae45cb1f6a6106ac25f347631d6d0ca8 `git-annex copy --not --in bup --to bup -J2 --all`:
+
+```
+...
+copy SHA256E-s227509--23bcff8394a16cb8ae090ac9f67e7cccb8a2c4354788b11426bfc14d01c136c6.csv (to bup...) 
+  bup [\"split\",\"-r\",\"/tmp/bup\",\"-q\",\"-n\",\"SHA256E-s227509--23bcff8394a16cb8ae090ac9f67e7cccb8a2c4354788b11426bfc14d01c136c6.csv\"] exited 1 (stderr output: Traceback (most recent call last):
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-midx\", line 298, in <module>
+      do_midx_dir(path, opt.output, byte_stream(sys.stdout))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-midx\", line 192, in do_midx_dir
+      m = git.open_idx(mname)
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 668, in open_idx
+      return midx.PackMidx(filename)
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/midx.py\", line 29, in __init__
+      self.map = mmap_read(open(filename))
+  FileNotFoundError: [Errno 2] No such file or directory: b'/tmp/bup/index-cache/None__tmp_bup/midx-5bfad00d8c17012ca48231b22dd894649c385b15.midx'
+  [b'/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup', b'midx', b'--auto', b'--dir', b'/tmp/bup/index-cache/None__tmp_bup']: returned 1
+  WARNING: 1 errors encountered while saving.
+  )
+ok
+copy SHA256E-s6061--b57b1e42ee05102f095d700c9bcb12b48142a9c57879573d3fd128d181b60f5f.txt.user (to bup...) ok
+copy SHA256E-s1861--86988a46008289c58943f2e59f4e543fdec3fc9853ce8b53375e11f9ccbd4138.cpp (to bup...) 
+  bup [\"split\",\"-r\",\"/tmp/bup\",\"-q\",\"-n\",\"SHA256E-s1861--86988a46008289c58943f2e59f4e543fdec3fc9853ce8b53375e11f9ccbd4138.cpp\"] exited 1 (stderr output: Traceback (most recent call last):
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-server\", line 320, in <module>
+      cmd(conn, rest)
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-server\", line 137, in receive_objects_v2
+      oldpack = w.exists(shar, want_source=True)
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 804, in exists
+      self._require_objcache()
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 797, in _require_objcache
+      self.objcache = self.objcache_maker()
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 686, in _make_objcache
+      return PackIdxList(repo(b'objects/pack'))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 517, in __init__
+      self.refresh()
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 607, in refresh
+      midxl.sort(key=lambda ix:
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 608, in <lambda>
+      (-len(ix), -xstat.stat(ix.name).st_mtime))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/xstat.py\", line 131, in stat
+      return stat_result.from_xstat_rep(_helpers.stat(path))
+  FileNotFoundError: [Errno 2] No such file or directory: '/tmp/bup/objects/pack/midx-13188bb9c81006e5bc683627ee9fe186c09a9104.midx'
+  Traceback (most recent call last):
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-split\", line 232, in <module>
+      pack_writer.close()  # must close before we can update the ref
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/client.py\", line 520, in close
+      id = self._end()
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/client.py\", line 517, in _end
+      return self.suggest_packs() # Returns last idx received
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/client.py\", line 285, in _suggest_packs
+      self.check_ok()
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/client.py\", line 155, in check_ok
+      raise ClientError('server exited unexpectedly with code %r'
+  bup.client.ClientError: server exited unexpectedly with code 1
+  )
+ok
+copy SHA256E-s247--598ca11afb6b5a92fb0539d5e51b5933986a02b9af76c306ed0e3d123eba7f73.org (to bup...) ok
+copy SHA256E-s17120--e883a44474fb01cb2598a35de65bb8f149e8a86f0edad9e769c29cb47738f1d7.org (to bup...) ok
+copy SHA256E-s51256--6a45e5a834b84467ca8730b19d11997b1fda618e8264f3052466b0c0d9df33fb (to bup...) ok
+copy SHA256E-s138590--273323cbd322923f9d19280b6b4fa73bfa3638d2982b685b9efcaee43c988a07.pdf (to bup...) ok
+copy SHA256E-s1142--68e432e17b706adc8fed0c6e573957ebf3fdb3c2ed52152e8e11ff68742a964c.cpp (to bup...) ok
+copy SHA256E-s2357--88f5bd074dce62a99f67a2fcb89f69edc323f5b781c43f75e2266caa75f452a8.nix (to bup...) ok
+copy SHA256E-s17167--f1a52bf34dc0c09bd05ea76c129bca1edf01cb1634967facddc87ceed030ac0e.org (to bup...) ok
+copy SHA256E-s20152--ec24a0a718ff33a20fd18a672e7f8e8d29358a4930a0cb668fc023c6319acff2.cpp (to bup...) ok
+copy SHA256E-s74935712--48a36e91a03d46fe73ec361454b9cd3808ae0a6d5372df089c2400ea135269e1.pptx (to bup...) ok
+copy SHA256E-s32801--33568e97fb3c67d5646698a3157d2387ccbd447dbe846604e21f135962b7a82a.org (to bup...) ok
+copy SHA256E-s1112--08efad2257400abb2a011b7a2bcee115ad69a7c5f8fe622df94f9252e767f4b1.cpp (to bup...) ok
+copy SHA256E-s4--af489f7170eaf213b960628333c4752e3907304303ed0b052b43d864d2653c2e (to bup...) ok
+copy SHA256E-s270--fd3d6db55c73971d25b7a12211f618ee0f5b9185329974e15a71b8c7313b71d3.org (to bup...) ok
+copy SHA256E-s26781--66ff44f139d2f825d6202437078e2a6652214f2d4841f618268a39cb25919c52.org (to bup...) ok
+copy SHA256E-s267--5face6a2e6cf04634542c17626cfb273b5cd6d1ff8cad644bb3dfd50b5b26c10 (to bup...) ok
+copy SHA256E-s1117802--d9b03b85205196237df6bdcaaa74642db77da46fbea35d1e0de4034f24387cf4.pdf (to bup...) ok
+copy SHA256E-s265--fc2aec4bcb3af72e043a2f892440a1370ed19704cf4fb4a3cc26114441b6f8d0.org (to bup...) ok
+copy SHA256E-s34783--ad8860a118f942f58672a95c2df3dcfbfd2cc8ee3f5930f52bfbb88dc0a90132.org (to bup...) ok
+copy SHA256E-s56184--30106a0f9dd300f8a88e2eb88b2a184a1342874afa2cb4aaa64404a187f1e8c4 (to bup...) ok
+copy SHA256E-s74919040--86dcfa59caa040dcfc512bc41b8fe652abc0814324f8fe18d88043a14ecf4402.pptx (to bup...) ok
+copy SHA256E-s26013--0bae4beaba4bdf971bd79061a215e2835953b3bb00e532fb0341e6628b796008.org (to bup...) ok
+copy SHA256E-s58752--e03f8dc86ed2dc218612022331323a2f5cac319a250b4a24fc15d7312ee9e607 (to bup...) ok
+copy SHA256E-s8847--cc7aa3b84e82f7aa197d653f41b545a1e807c98f16187210ded3d2463b41ea86.csv (to bup...) ok
+copy SHA256E-s21189--8ffdc40240a69693c596b70a94dd58258cd753b41f34e0c16c38d8dbd89f698e.org (to bup...) ok
+copy SHA256E-s24137--9a5c833a7f70f53ba26aa26e3dd2faf22b16e1c4ce33c5733d0a2109560b7c71.org (to bup...) ok
+copy SHA256E-s359450--0d0ec93306f455d231ede0e8f2f6c047dd94e0de9a16639e1a7f0b3d86203ac3.pdf (to bup...) 
+  bup [\"split\",\"-r\",\"/tmp/bup\",\"-q\",\"-n\",\"SHA256E-s359450--0d0ec93306f455d231ede0e8f2f6c047dd94e0de9a16639e1a7f0b3d86203ac3.pdf\"] exited 1 (stderr output: Traceback (most recent call last):
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-midx\", line 298, in <module>
+      do_midx_dir(path, opt.output, byte_stream(sys.stdout))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-midx\", line 198, in do_midx_dir
+      midxs.sort(key=lambda ix: (-sizes[ix], -xstat.stat(ix).st_mtime))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-midx\", line 198, in <lambda>
+      midxs.sort(key=lambda ix: (-sizes[ix], -xstat.stat(ix).st_mtime))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/xstat.py\", line 131, in stat
+      return stat_result.from_xstat_rep(_helpers.stat(path))
+  FileNotFoundError: [Errno 2] No such file or directory: '/tmp/bup/index-cache/None__tmp_bup/midx-3da3384b3acf53204d7890e1bc78030c8b46b3a9.midx'
+  [b'/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup', b'midx', b'--auto', b'--dir', b'/tmp/bup/index-cache/None__tmp_bup']: returned 1
+  WARNING: 1 errors encountered while saving.
+  )
+ok
+copy SHA256E-s1433--20e8793d98da9272424818b56c28af028c1568ec3e82967d6f07ff81015c4108.cpp (to bup...) ok
+copy SHA256E-s91176--46ebe34cba131ea6ced189768edccfbf7eb4b7e33fa0be53c36c7888e2bff4a5 (to bup...) 
+  bup [\"split\",\"-r\",\"/tmp/bup\",\"-q\",\"-n\",\"SHA256E-s91176--46ebe34cba131ea6ced189768edccfbf7eb4b7e33fa0be53c36c7888e2bff4a5\"] exited 1 (stderr output: Traceback (most recent call last):
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-server\", line 320, in <module>
+      cmd(conn, rest)
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-server\", line 137, in receive_objects_v2
+      oldpack = w.exists(shar, want_source=True)
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 804, in exists
+      self._require_objcache()
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 797, in _require_objcache
+      self.objcache = self.objcache_maker()
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 686, in _make_objcache
+      return PackIdxList(repo(b'objects/pack'))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 517, in __init__
+      self.refresh()
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 607, in refresh
+      midxl.sort(key=lambda ix:
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/git.py\", line 608, in <lambda>
+      (-len(ix), -xstat.stat(ix.name).st_mtime))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/xstat.py\", line 131, in stat
+      return stat_result.from_xstat_rep(_helpers.stat(path))
+  FileNotFoundError: [Errno 2] No such file or directory: '/tmp/bup/objects/pack/midx-4b7dfbb64132c6a9e65912f5d75a49fcc27dfc14.midx'
+  Traceback (most recent call last):
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-split\", line 232, in <module>
+      pack_writer.close()  # must close before we can update the ref
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/client.py\", line 520, in close
+      id = self._end()
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/client.py\", line 517, in _end
+      return self.suggest_packs() # Returns last idx received
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/client.py\", line 285, in _suggest_packs
+      self.check_ok()
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/client.py\", line 155, in check_ok
+      raise ClientError('server exited unexpectedly with code %r'
+  bup.client.ClientError: server exited unexpectedly with code 1
+  )
+ok
+copy SHA256E-s84648--95ced533e6e0117e09eb0c6e887e3258ccd85e7c14b376a48683028d1959e6f4 (to bup...) ok
+copy SHA256E-s33116--1c7622be0217bef8b345d7a2d741a1ea7140df79fb69ee966d0e2596aedd9b92.org (to bup...) ok
+copy SHA256E-s1405--707992e818ada3dcf8ddee86d0bf01db6206e1cd9354c8b32bd760a842757890.cpp (to bup...) ok
+copy SHA256E-s34172--5ae202572227ab6df161298ab61c4bfe5ebca4b710e8646602c910996c9c4229.org (to bup...) ok
+copy SHA256E-s1406289--7462f1e3ca02e796090fe2ba18a50168a24f5cabc66bb8bf949836d4c81774cb.csv (to bup...) ok
+copy SHA256E-s263520--1ae605c38fb827de59f90fe304ad20c673a2d8fcbf8166a4cf44bfc45320fb43 (to bup...) ok
+copy SHA256E-s57968--830ff82c9c697a29a7cdf1f4765aadb532e42c932a01c45eafe3d66b254dc30b (to bup...) ok
+copy SHA256E-s16350--45d12a82d07c62c00fbb211b3cfbc7abea2fb8b4b1777140b56ebee9244ef7af.org (to bup...) 
+  bup [\"split\",\"-r\",\"/tmp/bup\",\"-q\",\"-n\",\"SHA256E-s16350--45d12a82d07c62c00fbb211b3cfbc7abea2fb8b4b1777140b56ebee9244ef7af.org\"] exited 1 (stderr output: Traceback (most recent call last):
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-midx\", line 298, in <module>
+      do_midx_dir(path, opt.output, byte_stream(sys.stdout))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-midx\", line 198, in do_midx_dir
+      midxs.sort(key=lambda ix: (-sizes[ix], -xstat.stat(ix).st_mtime))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-midx\", line 198, in <lambda>
+      midxs.sort(key=lambda ix: (-sizes[ix], -xstat.stat(ix).st_mtime))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/xstat.py\", line 131, in stat
+      return stat_result.from_xstat_rep(_helpers.stat(path))
+  FileNotFoundError: [Errno 2] No such file or directory: '/tmp/bup/index-cache/None__tmp_bup/midx-fef6f07a351680cef8630a1c0ba203f2ed8c0e72.midx'
+  [b'/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup', b'midx', b'--auto', b'--dir', b'/tmp/bup/index-cache/None__tmp_bup']: returned 1
+  WARNING: 1 errors encountered while saving.
+  )
+ok
+copy SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa (to bup...) 
+  bup [\"split\",\"-r\",\"/tmp/bup\",\"-q\",\"-n\",\"SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa\"] exited 1 (stderr output: Traceback (most recent call last):
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-midx\", line 298, in <module>
+      do_midx_dir(path, opt.output, byte_stream(sys.stdout))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-midx\", line 198, in do_midx_dir
+      midxs.sort(key=lambda ix: (-sizes[ix], -xstat.stat(ix).st_mtime))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup-midx\", line 198, in <lambda>
+      midxs.sort(key=lambda ix: (-sizes[ix], -xstat.stat(ix).st_mtime))
+    File \"/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/../bup/xstat.py\", line 131, in stat
+      return stat_result.from_xstat_rep(_helpers.stat(path))
+  FileNotFoundError: [Errno 2] No such file or directory: '/tmp/bup/index-cache/None__tmp_bup/midx-fef6f07a351680cef8630a1c0ba203f2ed8c0e72.midx'
+  [b'/nix/store/xqgy6d53wbazvkjcgqwdpbww4s87b69z-bup-0.32/lib/bup/cmd/bup', b'midx', b'--auto', b'--dir', b'/tmp/bup/index-cache/None__tmp_bup']: returned 1
+  WARNING: 1 errors encountered while saving.
+  )
+ok
+^C
+```
+
+(Ran this on aarch64-darwin because that's all I have access to ATM but x86_64-linux will probably have the same errors.)
+
+Given the error, it indeed looks like a concurrency issue in `bup` itself. Version is 0.32 which is the newest.
+
+"""]]
diff --git a/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_3_ca2b909c54a772e1eea58b7cbc07bf39._comment b/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_3_ca2b909c54a772e1eea58b7cbc07bf39._comment
new file mode 100644
index 0000000000..d726ca75c2
--- /dev/null
+++ b/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_3_ca2b909c54a772e1eea58b7cbc07bf39._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-08-08T15:11:53Z"
+ content="""
+Looks like bup-midx is at fault, and that makes sense; it converts git pack
+files into "midx" files, so is reading and deleting pack files. So it seems
+likely that two of those running at the same time would fail like this.
+
+I've posted to bup's mailing list about this:
+<https://groups.google.com/g/bup-list/c/SJg6rQ2XWy8>
+
+git-annex may need to work around this by only running one bup-split at a
+time.
+"""]]
diff --git a/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_4_d7156224245542f5468783c1b5763154._comment b/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_4_d7156224245542f5468783c1b5763154._comment
new file mode 100644
index 0000000000..dcae1ea760
--- /dev/null
+++ b/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_4_d7156224245542f5468783c1b5763154._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-08-08T20:13:24Z"
+ content="""
+Got confirmation that bup is generally not concurrency safe.
+
+I've made git-annex limit the number of bup-split it runs to 1.
+
+It may be that this will also need to be done with bup-join, but I think
+probably not since it probably does not write to the repo, and a bup-split
+is unlikely to get in its way.
+"""]]
diff --git a/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_5_90d280582d71f77d75aeedcd30c7c437._comment b/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_5_90d280582d71f77d75aeedcd30c7c437._comment
new file mode 100644
index 0000000000..5ccfcb5fae
--- /dev/null
+++ b/doc/bugs/bup_often_errors_out_when_-J___62___1/comment_5_90d280582d71f77d75aeedcd30c7c437._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 5"
+ date="2022-08-09T06:22:50Z"
+ content="""
+Thank you!
+
+That's sad to hear as it means bup will perform even worse where it wasn't performing well to begin with but unsafe is unsafe.
+
+I'd consider this issue solved as bup performance problems are tracked in https://git-annex.branchable.com/bugs/Copying_many_files_to_bup_remotes_is_very_slow/ already.
+"""]]
diff --git a/doc/bugs/cabal_builds_without_assistant.mdwn b/doc/bugs/cabal_builds_without_assistant.mdwn
new file mode 100644
index 0000000000..feab883c71
--- /dev/null
+++ b/doc/bugs/cabal_builds_without_assistant.mdwn
@@ -0,0 +1,14 @@
+With cabal 3.4.1.0, `cabal build` does not build the assistant, even though
+all dependencies are there. Even after `cabal configure -fAssistant`, it
+silently skips installing the deps for the assistant and does not enable the
+CPP for the flag. Same for webapp.
+
+Earlier versions of cabal did not behave this way. Perhaps it is a cabal
+bug?
+
+I tried moving the build-depends out of the `if flag(Assistant)` section
+to the main build-depends section. It was able to install all the build
+depends, so it's not some dependency issue making it decide to turn off
+that build flag. --[[Joey]]
+
+> [[fixed|done]] by moving the dependencies into the main block. --[[Joey]]
diff --git a/doc/bugs/can__39__t_build_without_assistant.mdwn b/doc/bugs/can__39__t_build_without_assistant.mdwn
new file mode 100644
index 0000000000..7cb17ece2a
--- /dev/null
+++ b/doc/bugs/can__39__t_build_without_assistant.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+1. Building minimal variant of git-annex failed.
+1. Seems, that instructions about [minimal building from source](https://git-annex.branchable.com/install/fromsource/) are out-of-date, at least because options 'xmpp' and 'dns' don't exist in git-annex.cabal.
+1. Also seems, that file Utility/SRV.hs unused, may be remove it?
+
+In git-annex.cabal 'Assistant' flag doesn't influence on list of modules, only on compile flags and dependencies. 'Assistant/\*' modules includes into base variant of building (and some 'Assistant/\*' modules turn on with WebApp flag).
+
+### What steps will reproduce the problem?
+Try to build as in [archlinux package](https://git.archlinux.org/svntogit/community.git/tree/repos/community-x86_64/PKGBUILD?h=packages/git-annex), but turn off assistant:
+
+`runhaskell Setup configure -O --prefix=/usr --enable-executable-dynamic --disable-library-vanilla --docdir="/usr/share/doc/git-annex" -fconcurrentoutput -ftorrentparser -f-androidsplice -f-android -fproduction -fpairing -fwebapp -f-assistant -fwebdav -fs3 -f-benchmark -fdbus -fmagicmime`
+
+`runhaskell Setup.hs build`
+
+After that I got error:
+
+`Utility/Mounts.hs:13:1: error:`
+
+`    Could not find module ‘System.MountPoints’`
+
+haskell-mountpoints package is instaled.
+If turn on assistant flag, building is ok.
+
+### Please provide any additional information below.
+I don't know haskell, but try to make optional building of Assistant, see [patch](https://github.com/fftmp/git-annex-min-pkgbuild/blob/master/0002-optional-build-assistant-and-other-small-cabal-refin.patch). Seems, that it works for minimal building, but may be incomplete.
+### What version of git-annex are you using? On what operating system?
+6.20180807,  Archlinux
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Yes, use it for several years and have approx 100G repo with 10k+ files. Works fine.
+
+> You had the webapp flag enabled and the assistant disabled. 
+> That does not make sense; the assistant is part of the webapp.
+> That explains why it failed to build. Disabling both webapp and assistant
+> works, or only webapp and not assistant. 
+> 
+> Ok, fixed it to not build the webapp when the assistant flag is disabled.
+> [done]] --[[Joey]] 
diff --git a/doc/bugs/can__39__t_build_without_assistant/comment_1_41b96b4e7f01b79a2e942b8098faa534._comment b/doc/bugs/can__39__t_build_without_assistant/comment_1_41b96b4e7f01b79a2e942b8098faa534._comment
new file mode 100644
index 0000000000..e21ae48a4e
--- /dev/null
+++ b/doc/bugs/can__39__t_build_without_assistant/comment_1_41b96b4e7f01b79a2e942b8098faa534._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-09-05T15:23:49Z"
+ content="""
+Thanks for the patch, but while it is moving in a good direction,
+it gets some things wrong too. Problems I noticed:
+
+* It removes the "&& ! os(solaris) && ! os(gnu)" from the assistant flag
+  test, which are important to support building git-annex on hurd and
+  solaris.
+* Utility.Android is used inside *linux* builds to detect android at
+  runtime. So moving it under the flag(Android) test is wrong and will
+  break all linux builds AFAICS.
+* Build.DesktopFile is not linked into the assistant, like Build.Configure
+  it's only listed to get the source file into the cabal tarball. Best to
+  keep it with the other such files.
+
+I've applied the patch but reverted the above changes.
+"""]]
diff --git a/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain.mdwn b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain.mdwn
new file mode 100644
index 0000000000..b63f56ce83
--- /dev/null
+++ b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain.mdwn
@@ -0,0 +1,21 @@
+### Please describe the problem.
+In "Configuring jabber account" custom domains through google apps don't connect properly.
+
+### What steps will reproduce the problem?
+Try to use a google account that uses a non-gmail domain, e.g. user@domain.com
+
+### What version of git-annex are you using? On what operating system?
+Newest, on Mac OS 10.9
+
+### Please provide any additional information below.
+The issue is because git-annex is trying to connect to @domain.com as the jabber server, but the server should be talk.google.com:5223.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_1_6537e928a0d6d5c41b55370f112f4afb._comment b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_1_6537e928a0d6d5c41b55370f112f4afb._comment
new file mode 100644
index 0000000000..26a63f87f0
--- /dev/null
+++ b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_1_6537e928a0d6d5c41b55370f112f4afb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-02T17:28:01Z"
+ content="""
+This seems like the same problem as in [[bugs/googlemail]]. 
+
+git-annex uses SRV records to find the jabber server for a domain. What is google doing that makes this not work? Do you have a sample domain?
+"""]]
diff --git a/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_b639ad750a4635d95f6ad16a1aa39a3e._comment b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_b639ad750a4635d95f6ad16a1aa39a3e._comment
new file mode 100644
index 0000000000..a705f68551
--- /dev/null
+++ b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_b639ad750a4635d95f6ad16a1aa39a3e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlU0H3uyacCnqWxjSI_chHBlHu8TDIkTt0"
+ nickname="Matt"
+ subject="cannot connect via google apps domain"
+ date="2014-08-14T15:55:07Z"
+ content="""
+Having the same issue with our domain: zebradog.com SRV records are correctly specified (as defined here: https://support.google.com/a/answer/34143?hl=en)
+"""]]
diff --git a/doc/bugs/can__39__t_get.mdwn b/doc/bugs/can__39__t_get.mdwn
new file mode 100644
index 0000000000..d5a29a2aec
--- /dev/null
+++ b/doc/bugs/can__39__t_get.mdwn
@@ -0,0 +1,81 @@
+### Please describe the problem.
+
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+$> git annex get 2read/ISNN2010__Tang.pdf
+git-annex: Cannot mix --all or --unused with file names.
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+
+[[!format sh """
+$> apt-cache policy git-annex
+git-annex:
+  Installed: 5.20140116
+  Candidate: 5.20140116
+  Version table:
+ *** 5.20140116 0
+        600 http://debian.lcs.mit.edu/debian/ sid/main amd64 Packages
+        100 /var/lib/dpkg/status
+"""]]
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+$> git annex get 2read/ISNN2010__Tang.pdf
+git-annex: Cannot mix --all or --unused with file names.
+
+but seems to start fetching some load if I do not specify any path and just run 'git annex get'.
+
+There seems to be some screw up:
+
+I have plenty of objects under .git/annex/objects/ (seems largely from
+the directory above), nothing is now reported by unused (with obscure
+msg):
+
+$> du -scmL * 2>/dev/null | tail -1
+1	total                      
+
+$> du -scm .git/annex/objects 
+334	.git/annex/objects
+334	total
+
+$> git annex dropunused all
+git-annex: Map.findMin: empty map has no minimal element
+
+Here is some portion of the history which lead to such a state (there
+was git annex unused somewhere before)
+
+25954  git annex move --unused --to onerussian.com_annex
+25955  git annex dropunused
+25956  git annex dropunused all
+25962  git annex unused
+25963  git log --stat -SSHA256E-s5639442--67691e57cb4d6c51afe838590ad265ba4bea9c291cf52d58ed24f05b70bf33bf.mp3
+25965  git log --stat -SSHA256E-s143042--b4012bf03ed0a387a9e714390efa75f1dd769162cca4c9b77e516732342be3f9.html
+25968  git annex move --unused --to onerussian.com_annex
+25969  git annex dropunused all
+25976  git annex unused
+25978  git br
+25980  git log --stat -Ss741707--7c215090893f1f0c994e2a9ad3088016676464bbad26768841dd08c07295a2fe.pdf.map
+25981  git annex unused
+25982  git annex fsck
+25983  git annex unused
+25984  git annex dropkey
+25985  git log --stat -SSHA256E-s14534131--20de680eedb3e1fb687c9b00c154d978333b61f4ea122c632bdb5bcdbb1553ff.pdf
+25986  git show de3ccae8304efbae4a7a8add49de638f64b821fc
+25991  git annex fsck
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
+
+> Tagged moreinfo since I have a workable theory about how this happened,
+> which would make it user configuration error and not a bug, but 
+> that has not been confirmed. --[[Joey]]
diff --git a/doc/bugs/can__39__t_get/comment_1_ef32287828481c161bd913c9db9052a5._comment b/doc/bugs/can__39__t_get/comment_1_ef32287828481c161bd913c9db9052a5._comment
new file mode 100644
index 0000000000..6530ae3c80
--- /dev/null
+++ b/doc/bugs/can__39__t_get/comment_1_ef32287828481c161bd913c9db9052a5._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="git annex fix starts fixing but then spits bulk of errors"
+ date="2014-01-18T05:42:15Z"
+ content="""
+probably related:
+
+```
+fix books/Мои первые книжки/PDF/Благинина Е.А. - Лодочки (Мои первые книжки) - 1962.pdf ok
+fix books/Мои первые книжки/PDF/Благинина Е.А. - Не мешайте мне трудиться (Мои первые книжки) - 1975.pdf fatal: This operation must be run in a work tree
+ok
+(Recording state in git...)
+
+git-annex: user error (xargs [\"-0\",\"git\",\"--git-dir=/home/yoh/annex/.git\",\"add\",\"--force\",\"--\"] exited 123)
+fatal: This operation must be run in a work tree
+failed
+(Recording state in git...)
+
+git-annex: user error (xargs [\"-0\",\"git\",\"--git-dir=/home/yoh/annex/.git\",\"add\",\"--force\",\"--\"] exited 123)
+fatal: This operation must be run in a work tree
+failed
+(Recording state in git...)
+
+....
+```
+"""]]
diff --git a/doc/bugs/can__39__t_get/comment_2_31fe400f4bac516a5c1101612cb06a54._comment b/doc/bugs/can__39__t_get/comment_2_31fe400f4bac516a5c1101612cb06a54._comment
new file mode 100644
index 0000000000..456bd0342d
--- /dev/null
+++ b/doc/bugs/can__39__t_get/comment_2_31fe400f4bac516a5c1101612cb06a54._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="repair seems to be also confused"
+ date="2014-01-18T05:47:02Z"
+ content="""
+[[[
+$> git annex repair                               
+Running git fsck ...
+No problems found.
+fatal: '/home/yoh/annex/.git' is outside repository
+Had to delete the .git/annex/index file as it was corrupt.
+No data was lost.
+ok
+
+$> ls
+2enjoy/   2read/    2watch/  books/  hardware/  videos/
+2listen/  2review/  abooks/  docs/   pics/
+
+$> git annex repair
+Running git fsck ...
+No problems found.
+fatal: '/home/yoh/annex/.git' is outside repository
+Had to delete the .git/annex/index file as it was corrupt.
+No data was lost.
+ok
+
+$> git annex get 2read/ISNN2010__Tang.pdf
+git-annex: Cannot mix --all or --unused with file names.
+
+]]]
+"""]]
diff --git a/doc/bugs/can__39__t_get/comment_3_87d123c04815d38abb92f967829c3a23._comment b/doc/bugs/can__39__t_get/comment_3_87d123c04815d38abb92f967829c3a23._comment
new file mode 100644
index 0000000000..b7a7f3bc46
--- /dev/null
+++ b/doc/bugs/can__39__t_get/comment_3_87d123c04815d38abb92f967829c3a23._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="could it be part/reason of the problem"
+ date="2014-01-18T06:05:50Z"
+ content="""
+not sure how that happened... definitely not me consciously! ;-)  some commands are complaining that \"You cannot run this command in a bare repository\" which I thought is BS since it is not BARE! but then looked into .git/config and it does have core.bare = True ... yikes!.. 
+
+This repository is also under assistant \"control\".
+
+changing to bare=False seems to start 'get'ing things, git annex repair doesn't produce obscure errors.
+
+git annex fix though now doesn't report any problems -- only 'ok', but none of those files mentioned 'ok' has a working symlink,,,  but I guess that is a fluke after many upgrades -- just dropping everything locally and getting needed context after purging .git/annex/objects .
+
+So I guess issue is resolved by discovering that repository was set to 'bare' mode somehow although it was not and seemed like working but not quite
+"""]]
diff --git a/doc/bugs/can__39__t_get/comment_4_b99cff87dbe38f08f888200dfe7e2436._comment b/doc/bugs/can__39__t_get/comment_4_b99cff87dbe38f08f888200dfe7e2436._comment
new file mode 100644
index 0000000000..0d0422fd35
--- /dev/null
+++ b/doc/bugs/can__39__t_get/comment_4_b99cff87dbe38f08f888200dfe7e2436._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.43"
+ subject="comment 4"
+ date="2014-01-18T15:42:59Z"
+ content="""
+git-annex sets core.bare=true for direct mode, but it also then sets annex.direct=true and so does not treat it as a bare mode repository. If you had eg, manually tried to change annex.direct to false, and left it in bare mode, that would explain everything.
+
+> git annex fix though now doesn't report any problems -- only 'ok', but none of those files mentioned 'ok' has a working symlink
+
+That is completely normal behavior; git annex fix does not care if the content is locally present or not; it just checks that the symlinks would point to it if it were present.
+
+(Fixed the partial function in dropunused.)
+"""]]
diff --git a/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options.mdwn b/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options.mdwn
new file mode 100644
index 0000000000..258927f746
--- /dev/null
+++ b/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options.mdwn
@@ -0,0 +1,32 @@
+### Please describe the problem.
+
+git annex specifies its own socket path via -S.  To overload with our socket path (to be reused by annex and other ssh invocations) we need to provide the path via annex-ssh-options option.  And we cannot pass it as an overload -o ControlPath since -S specification provided by annex "overrides" it.
+The difficulty comes in possibly not quite common but still possible case when path to the socket contains a space.  I have tried all kinds of possible specifications but failed to find one which works... 
+
+Could you give me a hint!? ;)
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170307+gitg24ade8a25-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+# so -- ssh works
+$> ssh -O check -oControlMaster=auto -S"/tmp/te st/socket" 'yohtest@smaug'
+Master running (pid=20336)
+# but can't get annex to use it:
+
+$> git annex init -c 'remote.origin.annex-ssh-options=-oControlMaster=auto -S"/tmp/te st/socket"' 
+init  ssh: Could not resolve hostname st/socket": Name or service not known   
+yohtest@smaug's password: 
+
+$> git annex init -c 'remote.origin.annex-ssh-options=-oControlMaster=auto "-S\"/tmp/te st/socket\""' 
+init  ssh: Could not resolve hostname "-s\\"/tmp/te: Name or service not known
+yohtest@smaug's password: 
+
+# etc
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
diff --git a/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options/comment_1_d773dee03276e9b0e0b75d0709b76278._comment b/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options/comment_1_d773dee03276e9b0e0b75d0709b76278._comment
new file mode 100644
index 0000000000..002f9d1151
--- /dev/null
+++ b/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options/comment_1_d773dee03276e9b0e0b75d0709b76278._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-21T17:38:57Z"
+ content="""
+You can't accomplish this with `remote.<name>.annex-ssh-options`,
+since it is not exposed to the shell, and the parser just breaks it up into
+words.
+
+A smarter parser would be needed. Or you could configure it in
+~/.ssh/config, or perhaps make a ssh config file elsewhere and use
+annex-ssh-options to pass -F to ssh to make it use this other config file.
+
+Now that git-annex supports `GIT_SSH_COMMAND`, which is exposed to the
+shell, you should be able to accomplish it that way. I don't know if that
+would work in your use case, since the environment variable affects all ssh
+remotes, not just one.
+"""]]
diff --git a/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options/comment_2_01cb7ba7d3c19863d39f6fac0d45d235._comment b/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options/comment_2_01cb7ba7d3c19863d39f6fac0d45d235._comment
new file mode 100644
index 0000000000..2c4f6c56c2
--- /dev/null
+++ b/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options/comment_2_01cb7ba7d3c19863d39f6fac0d45d235._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-06-24T16:24:29Z"
+ content="""
+Is this still something you need, or does `GIT_SSH_COMMAND` cover the use
+case?
+
+The missing case would be, if you need remote.name.annex-ssh-options,
+to pass the options only to that one remote and not others.
+
+I don't feel it would be a good idea for git-annex to try to parse quoted
+options, etc. It would need to expose the config to the shell, the same way
+it implements GIT_SSH_COMMAND`, by wrapping the original command in "sh
+-c".
+
+That would need to be a different config than ssh-options, because
+existing ssh-options might be broken by the change. Eg, if it is set to
+something containing a "$", that would not be exposed to the shell
+currently.
+
+So, while this is clearly a gap, I'd prefer to only implement a fix if it's
+actually needed. Since the bug report is 3 years old and I've not gotten a
+nudge, I'm guessing maybe not needed..
+"""]]
diff --git a/doc/bugs/cannot_add_a_files_with_an_accent_in_it.mdwn b/doc/bugs/cannot_add_a_files_with_an_accent_in_it.mdwn
new file mode 100644
index 0000000000..f85453a88a
--- /dev/null
+++ b/doc/bugs/cannot_add_a_files_with_an_accent_in_it.mdwn
@@ -0,0 +1,43 @@
+### Please describe the problem.
+
+I cannot add a file that has an accent in its name. If I change the file name to not have accents, everything works.
+
+### What steps will reproduce the problem?
+
+- create a file with an accent in its name
+- "git annex status" shows the file is not checked in
+- "git annex add" the file
+- nothing happens, and "git annex status" still shows the file as not checked in
+
+### What version of git-annex are you using? On what operating system?
+
+% brew info git-annex
+git-annex: stable 5.20151218 (bottled), HEAD
+
+OS X 10.11.2
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+[schmitta@charm-ecran:~/Documents/annex on master]
+% git annex status
+[schmitta@charm-ecran:~/Documents/annex on master]
+% cat > é
+foo
+[schmitta@charm-ecran:~/Documents/annex on master]
+% git annex status                                                            ✭
+? é
+[schmitta@charm-ecran:~/Documents/annex on master]
+% git annex add é                                                             ✭
+[schmitta@charm-ecran:~/Documents/annex on master]
+% git annex status                                                            ✭
+? é
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, git annex is great and I use it to store videos I want to watch later but that are too big to all be stored on my laptop.
diff --git a/doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_1_d465d7f88c8f11b4b636fba56711d745._comment b/doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_1_d465d7f88c8f11b4b636fba56711d745._comment
new file mode 100644
index 0000000000..0d47449a0d
--- /dev/null
+++ b/doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_1_d465d7f88c8f11b4b636fba56711d745._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-11T16:46:42Z"
+ content="""
+I can't even type an e with an accent in it into the bash prompt on OSX.
+However, I copied over such a file, and had no problem adding it:
+
+	bash-3.2$ ls
+	e??
+	bash-3.2$ git annex add .
+	add ë ok
+	bash-3.2$ git annex status
+	A ë
+
+I also tried tab-completing a file named "testë" and that also works:
+
+	oberon:gd joeyh$ git annex add teste\314\210 
+	add testë ok
+	(recording state in git...)
+
+So, I can't reproduce your problem.
+"""]]
diff --git a/doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_2_b6886a5c38725d93630562a3172d1a5c._comment b/doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_2_b6886a5c38725d93630562a3172d1a5c._comment
new file mode 100644
index 0000000000..7dc9497bc2
--- /dev/null
+++ b/doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_2_b6886a5c38725d93630562a3172d1a5c._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="Alan"
+ subject="Some additional information"
+ date="2016-01-12T17:48:58Z"
+ content="""
+Here is what `locale` returns here
+
+    LANG=
+    LC_COLLATE=\"en_US.UTF-8\"
+    LC_CTYPE=\"en_US.UTF-8\"
+    LC_MESSAGES=\"en_US.UTF-8\"
+    LC_MONETARY=\"en_US.UTF-8\"
+    LC_NUMERIC=\"en_US.UTF-8\"
+    LC_TIME=\"en_US.UTF-8\"
+    LC_ALL=\"en_US.UTF-8\"
+
+I think it may matter as I see that your accents are not displayed correctly when you \"tab\".
+
+To type a é on OS X with qwerty, you can do `option-e` then e.
+"""]]
diff --git a/doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_3_7c34ada3c7b413f2b622149b60757f6e._comment b/doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_3_7c34ada3c7b413f2b622149b60757f6e._comment
new file mode 100644
index 0000000000..a30e2259e0
--- /dev/null
+++ b/doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_3_7c34ada3c7b413f2b622149b60757f6e._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="Alan"
+ avatar="http://cdn.libravatar.org/avatar/9cbc26346f1c693d7df198e662a5fdae"
+ subject="Issue still present"
+ date="2017-03-10T07:32:16Z"
+ content="""
+I'm still having this issue, now with a folder. I added several files:
+
+    % git annex add Théâtre\ Augustin\ 2016/*                                           
+    add Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Bizarre, Bizarre.webm ok
+    add Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Conte A Rebours.webm ok
+    add Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Coup De Theatre.webm ok
+    add Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Inspecteur Toutou.webm ok
+    add Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - La Princesse Qui Disait Toujours Non.webm ok
+    add Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Le Magicien Qui Aimait Les Bonbons.webm ok
+    (recording state in git...)
+
+and they show as both added and untracked
+
+    % git annex status                                                                 
+    A Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Bizarre, Bizarre.webm
+    A Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Conte A Rebours.webm
+    A Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Coup De Theatre.webm
+    A Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Inspecteur Toutou.webm
+    A Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - La Princesse Qui Disait Toujours Non.webm
+    A Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Le Magicien Qui Aimait Les Bonbons.webm
+    ? Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Bizarre, Bizarre.webm
+    ? Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Conte A Rebours.webm
+    ? Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Coup De Theatre.webm
+    ? Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Inspecteur Toutou.webm
+    ? Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - La Princesse Qui Disait Toujours Non.webm
+    ? Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Le Magicien Qui Aimait Les Bonbons.webm
+
+It seems to be related to this: https://stackoverflow.com/questions/11968183/how-to-handle-accented-characters-in-file-names-in-git-on-mac-os-x-converted-to
+
+I “solved“ the issue by doing a git add of the repository, but I'm wondering what options I need to use with git to avoid such issues in the future.
+"""]]
diff --git a/doc/bugs/cannot_add_local_readonly_repo_through_the_webapp.mdwn b/doc/bugs/cannot_add_local_readonly_repo_through_the_webapp.mdwn
new file mode 100644
index 0000000000..9b1f726cf6
--- /dev/null
+++ b/doc/bugs/cannot_add_local_readonly_repo_through_the_webapp.mdwn
@@ -0,0 +1,98 @@
+### Please describe the problem.
+
+A readonly repository that I can add fine on the commandline (and sync content from) cannot be added through the webapp.
+
+### What steps will reproduce the problem?
+
+Say I have a readonly (owned by root) repository in `~/test/a` and I create a `~/test/b` (owned by my user). In the webapp, when to add `/home/anarcat/test/a` as a "local repository" (`Add another local repository`) to the `~/test/b` repo, it fails when i enter that path, with "Cannot write a repository there." I obviously can't sync content from there then.
+
+This works on the commandline, although with warnings.
+
+### What version of git-annex are you using? On what operating system?
+
+Version: 5.20140927 
+Build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+
+Debian Jessie.
+
+### Please provide any additional information below.
+
+Here's the transcript of the commandline equivalent:
+
+~~~
+anarcat@marcos:test$ git init a
+Dépôt Git vide initialisé dans /home/anarcat/test/a/.git/
+anarcat@marcos:test$ git init b
+Dépôt Git vide initialisé dans /home/anarcat/test/b/.git/
+anarcat@marcos:test$ cd a
+anarcat@marcos:a$ git annex init
+init  ok
+(Recording state in git...)
+anarcat@marcos:a$ echo hellow world > README
+anarcat@marcos:a$ git annex add README
+add README ok
+(Recording state in git...)
+anarcat@marcos:a$ git commit -m"test repo a"
+[master (commit racine) 3ece2a1] test repo a
+ 1 file changed, 1 insertion(+)
+ create mode 120000 README
+anarcat@marcos:a$ cd ../ ^C
+anarcat@marcos:a$ sudo chown -R root .
+[sudo] password for anarcat:
+Sorry, try again.
+[sudo] password for anarcat:
+anarcat@marcos:a$ cd ../b
+anarcat@marcos:b$ git annex init
+init  ok
+(Recording state in git...)
+anarcat@marcos:b$ git remote add a ../a
+anarcat@marcos:b$ git annex sync a
+commit  ok
+pull a
+warning: no common commits
+remote: Décompte des objets: 13, fait.
+remote: Compression des objets: 100% (9/9), fait.
+remote: Total 13 (delta 1), reused 0 (delta 0)
+Dépaquetage des objets: 100% (13/13), fait.
+Depuis ../a
+ * [nouvelle branche] git-annex  -> a/git-annex
+ * [nouvelle branche] master     -> a/master
+
+
+merge: refs/remotes/a/synced/master - not something we can merge
+failed
+(merging a/git-annex into git-annex...)
+(Recording state in git...)
+push a
+Décompte des objets: 8, fait.
+Delta compression using up to 2 threads.
+Compression des objets: 100% (6/6), fait.
+Écriture des objets: 100% (8/8), 819 bytes | 0 bytes/s, fait.
+Total 8 (delta 1), reused 0 (delta 0)
+remote: error: insufficient permission for adding an object to repository database objects
+remote: fatal: failed to write object
+error: unpack failed: unpack-objects abnormal exit
+To ../a
+ ! [remote rejected] git-annex -> synced/git-annex (unpacker error)
+ ! [remote rejected] master -> synced/master (unpacker error)
+error: impossible de pousser des références vers '../a'
+
+  Pushing to a failed.
+
+  (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
+failed
+git-annex: sync: 2 failed
+anarcat@marcos:b$ ls
+README
+anarcat@marcos:b$ git annex copy --from a
+copy README (from a...) ok
+(Recording state in git...)
+anarcat@marcos:b$ ls -al
+total 16K
+drwxr-xr-x 3 anarcat anarcat 4096 oct.  20 15:36 .
+drwxr-xr-x 4 anarcat anarcat 4096 oct.  20 15:35 ..
+drwxr-xr-x 9 anarcat anarcat 4096 oct.  20 15:36 .git
+lrwxrwxrwx 1 anarcat anarcat  180 oct.  20 15:36 README -> .git/annex/objects/wz/Zq/SHA256E-s13--8c083c6897455257dfbace7a9012d92ca8ebfb6e6ebe8acddc6dfa8fc81226ed/SHA256E-s13--8c083c6897455257dfbace7a9012d92ca8ebfb6e6ebe8acddc6dfa8fc81226ed
+~~~
+
+This is part of the [[todo/read-only_removable_drives/]] series. --[[anarcat]]
diff --git a/doc/bugs/cannot_ungroup_a_repository.mdwn b/doc/bugs/cannot_ungroup_a_repository.mdwn
new file mode 100644
index 0000000000..d9dc68e672
--- /dev/null
+++ b/doc/bugs/cannot_ungroup_a_repository.mdwn
@@ -0,0 +1,55 @@
+### Please describe the problem.
+
+I had a repository in the `transfer` group that I wanted to move out of there and switch to `manual`.
+
+I can't remove it from the `transfer` group.
+
+### What steps will reproduce the problem?
+
+[[!format txt """
+git annex group . transfer
+git annex group . manual
+git annex ungroup . transfer
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format txt """
+anarcat@angela:video[1]$ git annex version
+git-annex version: 10.20221003
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 9
+"""]]
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+anarcat@angela:video$ git annex ungroup . transfer
+git-annex: Specify a repository and a group.
+anarcat@angela:video[1]$ git annex group .
+manual transfer
+anarcat@angela:video$ git annex ungroup ae3d62e6-49be-4340-ba25-c8736a1637c4 transfer
+git-annex: Specify a repository and a group.
+anarcat@angela:video[1]$ git annex ungroup .
+git-annex: Specify a repository and a group.
+anarcat@angela:video[1]$ git annex ungroup 
+git-annex: Specify a repository and a group.
+anarcat@angela:video[1]$
+# End of transcript or log.
+"""]]
+
+I just can't figure out how to use the ungroup command, it seems.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! I could have sworn this worked before too. :)
+
+> [[unreproducible|done]] by submitter --[[Joey]]
diff --git a/doc/bugs/cannot_ungroup_a_repository/comment_1_5476ceb9af2fa2d862a868824e5865e4._comment b/doc/bugs/cannot_ungroup_a_repository/comment_1_5476ceb9af2fa2d862a868824e5865e4._comment
new file mode 100644
index 0000000000..017db0a8f5
--- /dev/null
+++ b/doc/bugs/cannot_ungroup_a_repository/comment_1_5476ceb9af2fa2d862a868824e5865e4._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-02-07T16:19:21Z"
+ content="""
+That's weird. It does work for me:
+
+	joey@darkstar:~/tmp/xxx>git annex group .
+	
+	joey@darkstar:~/tmp/xxx>git annex group . transfer
+	group . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/xxx>git annex group . manual
+	group . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/xxx>git annex ungroup . transfer
+	ungroup . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/xxx>git annex group .
+	manual
+
+That's with exactly the same version of git-annex too (10.20221003).
+
+The "Specify a repository and a group." error is only
+displayed when there are not exactly 2 parameters. You
+seem to be providing exactly 2, but it seems we need
+to rule out the possibility that something (eg the shell, a
+wrapper program, or git) is causing some other number of
+parameters to be provided..
+
+	joey@darkstar:~/tmp/xxx>strace -o log git-annex ungroup . transfer
+	ungroup . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/xxx>grep execve log
+	execve("/usr/bin/git-annex", ["git-annex", "ungroup", ".", "transfer"], 0x7ffde3606738 /* 66 vars */) = 0
+	joey@darkstar:~/tmp/grep execve log | head -n2
+	2720010 execve("/usr/bin/git", ["git", "annex", "ungroup", ".", "transfer"], 0x7fff42a31338 /* 66 vars */) = 0
+	2720011 execve("/usr/bin/git-annex", ["/usr/bin/git-annex", "ungroup", ".", "transfer"], 0x55e494ddb4f0 /* 67 vars */ <unfinished ...>
+"""]]
diff --git a/doc/bugs/cannot_ungroup_a_repository/comment_2_0be32bc80e98c0e10b2eb949b20b18dc._comment b/doc/bugs/cannot_ungroup_a_repository/comment_2_0be32bc80e98c0e10b2eb949b20b18dc._comment
new file mode 100644
index 0000000000..c20293c4df
--- /dev/null
+++ b/doc/bugs/cannot_ungroup_a_repository/comment_2_0be32bc80e98c0e10b2eb949b20b18dc._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="comment 2"
+ date="2023-02-08T15:38:03Z"
+ content="""
+I'm sorry to say that the error went away after attaching a strace to it:
+
+```
+anarcat@angela:video$ strace -o log -e execve git annex ungroup . transfer
+ungroup . ok
+(recording state in git...)
+```
+
+no idea wtf happened here, but i guess we can call this [[done]]? next time i'll try strace, sorry, i should have thought of it the first time.
+"""]]
diff --git a/doc/bugs/cannot_ungroup_a_repository/comment_3_16f1b5ce3830f9d26df4b14ed666e189._comment b/doc/bugs/cannot_ungroup_a_repository/comment_3_16f1b5ce3830f9d26df4b14ed666e189._comment
new file mode 100644
index 0000000000..c9ac772ba4
--- /dev/null
+++ b/doc/bugs/cannot_ungroup_a_repository/comment_3_16f1b5ce3830f9d26df4b14ed666e189._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-02-08T16:23:36Z"
+ content="""
+Have you confirmed the problem no longer happens when not stracing as well?
+If it were say, some shell alias causing a problem, using strace would
+bypass it..
+"""]]
diff --git a/doc/bugs/cannot_ungroup_a_repository/comment_4_bc93a6cb01e7d5d43cccb0eca81b5f33._comment b/doc/bugs/cannot_ungroup_a_repository/comment_4_bc93a6cb01e7d5d43cccb0eca81b5f33._comment
new file mode 100644
index 0000000000..b03fc6cc44
--- /dev/null
+++ b/doc/bugs/cannot_ungroup_a_repository/comment_4_bc93a6cb01e7d5d43cccb0eca81b5f33._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="comment 4"
+ date="2023-02-14T19:03:24Z"
+ content="""
+Yeah, it's not strace: the problem just disappeared, sorry. :/ If I hit it again, i'll be sure to do my homework. :)
+"""]]
diff --git a/doc/bugs/chunks_not_deduplicated.mdwn b/doc/bugs/chunks_not_deduplicated.mdwn
new file mode 100644
index 0000000000..9a70aae973
--- /dev/null
+++ b/doc/bugs/chunks_not_deduplicated.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+When data is chunked for storage on a remote, identical chunks may be stored repeatedly with different hashes.
+
+### What steps will reproduce the problem?
+```
+git annex init .
+dd count=16 bs=1024 if=/dev/urandom of=rand1.bin
+dd count=15 skip=1 bs=1024 if=rand1.bin of=rand2.bin
+git annex add rand1.bin rand2.bin
+mkdir data
+git annex initremote data type=directory directory=data encryption=none chunk=1024
+git annex copy --all --to=data
+find data -type f | xargs sha1sum | sort # shows doubly-stored identical chunks
+```
+
+### What version of git-annex are you using? On what operating system?
+10.20221004-gbf27a02b0 on redhat 7
+
+### Please provide any additional information below.
+
+I imagine an optional upgrade to a new key format for chunks, such that they had their own hashes, and the larger key they were a part of were identified separately (e.g. in data content or metadata). They would then become deduplicated already using existing means.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yesterday I recovered a bricked phone by accessing flash partitions I had backed up with git-annex. I deleted them locally by accident, by git-annex cobbled many of them together from remotes. The ones it didn't find still had their hashes preserved in the repository, and I was able to compare with hashes on the device and reconstructed all but one. The one I didn't reconstruct is regenerateable.
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/chunks_not_deduplicated/comment_1_3890af3669ac6b37b88dac938ed79d16._comment b/doc/bugs/chunks_not_deduplicated/comment_1_3890af3669ac6b37b88dac938ed79d16._comment
new file mode 100644
index 0000000000..036afc770a
--- /dev/null
+++ b/doc/bugs/chunks_not_deduplicated/comment_1_3890af3669ac6b37b88dac938ed79d16._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-11-07T16:25:27Z"
+ content="""
+See [[todo/option_to_individually_hash_chunks]].
+"""]]
diff --git a/doc/bugs/commitBuffer__58___invalid_argument___40__invalid_character__41__2.mdwn b/doc/bugs/commitBuffer__58___invalid_argument___40__invalid_character__41__2.mdwn
new file mode 100644
index 0000000000..1be88f4a14
--- /dev/null
+++ b/doc/bugs/commitBuffer__58___invalid_argument___40__invalid_character__41__2.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+git-annex fails if there are any "invalid characters" in the filename. That should have been fixed already? In one of my repos I cannot commit anymore:
+
+$ git commit -m u
+git-annex: .git/annex/misctmp/jlog6281: commitBuffer: invalid argument (invalid character)
+
+This logfile is empty by the way. The obvious fix would be to move out of germany and to not listen to german podcasts, but there has to be another solution :).
+
+Because I did not have any particular problems with that in the past, this bug must have been introduced in one of the latest releases I guess.
+
+### What steps will reproduce the problem?
+
+Try
+
+git-annex importfeed --fast http://ulm.ccc.de/dev/radio/podcast-ogg.xml
+
+It will fail at entry "DR14: Verschwörungstheorien"
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150327-g19a1a35 (standalone build) on Fedora 21
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/commitBuffer__58___invalid_argument___40__invalid_character__41__2/comment_1_b56c847c5eda432a4330b4d853a25519._comment b/doc/bugs/commitBuffer__58___invalid_argument___40__invalid_character__41__2/comment_1_b56c847c5eda432a4330b4d853a25519._comment
new file mode 100644
index 0000000000..43e6a390b2
--- /dev/null
+++ b/doc/bugs/commitBuffer__58___invalid_argument___40__invalid_character__41__2/comment_1_b56c847c5eda432a4330b4d853a25519._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T17:49:57Z"
+ content="""
+I cannot reproduce this, I get:
+
+	addurl _dev_radio/DR14__Verschwörungstheorien.ogg ok
+
+Does the _dev_radio/DR14__Verschwörungstheorien.ogg file get created?
+If so, how does it look?
+
+The jlog tells me it's trying to commit the git-annex branch journal.
+Does .git/annex/journal/ contain any files? Any files containing German
+characters?
+
+Do you have any git config settings for git-annex beyone the typical
+annex.uuid?
+
+I noticed one place in the journal commit code where it does seem to
+neglect to use filesystem encoding when dealing with writing filenames to
+the jlog tmpfile. Which could lead to this crash theoretically. I've fixed
+that, but since I couldn't reproduce the problem, I don't know if this will
+fix your problem. Nor do I understand how annex journal log files could
+have these characters in their names. You can try today's upcoming release
+of git-annex to test the fix though.
+"""]]
diff --git a/doc/bugs/concurrent_git-annex_processes_can_lead_to_locking_issues.mdwn b/doc/bugs/concurrent_git-annex_processes_can_lead_to_locking_issues.mdwn
new file mode 100644
index 0000000000..2485e7b19e
--- /dev/null
+++ b/doc/bugs/concurrent_git-annex_processes_can_lead_to_locking_issues.mdwn
@@ -0,0 +1,53 @@
+When two git-annex processes are running and both modifying the git-annex
+branch, it's possible one will fail due to git's locking. When this
+happens, git-annex has already recorded its state in the journal (so no
+data is lost), but git-annex does crash, which can be surprising.
+
+I feel that, in general, multiple git-annex processes should be able to run
+concurrently. A big lock around all commands, or even all
+repository-modifying commands is a bad idea. Also, it's probably best to
+only worry about locking conflicts editing the git-annex branch. While `git
+annex add` and a few other commands make changes to the main git repo,
+and can have similar locking issues, so can any git commands that stage
+changes (I think.. check).
+
+Probably should KISS. Just add a lock file that is taken before changes to
+the git-annex branch, and if it's locked, wait. Changes to the git-annex
+branch tend to happen quickly (unless it's committing an enormous set of
+changes, and even that is relatively fast), so waiting seems ok. --[[Joey]] 
+
+----
+
+Commit 7981eb4cb512fbe3c49a3dd165c31be14ae4bc49 is more pessimistic, 
+describes some other potential issues. 
+
+* The journal needs to be emptied (done) and kept locked (not done) during
+  a merge, since a merge operates at a level below the journal, and any
+  changes that are journaled during a merge can overwrite changes merged
+  in from another branch.
+
+* Two git-annex processes can be doing conflicting things and inconsistent
+  information be written to the journal.
+
+  - One example would be concurrent get and drop of the same key.
+    But could this really race? If the key was already present, the get
+    would do nothing, so record no changes. If the key was not yet present,
+    the drop would do nothing, and record no changes.
+
+  - Instead, consider two copys of a key to different locations. If the
+    slower copy starts first and ends last, it could cache the location 
+    info, add the  new location, and lose the other location it was copied to.
+    Tested it and the location is not cached during the whole copy (logChange
+    reads the current log immediatly before writing), so this
+    race's window is very small -- but does exist.
+
+---- 
+
+## Updated plan
+
+Make Branch.change transactional, so it takes a lock, reads a file,
+applies a function to it, and writes the changed file.
+
+Make Branch.update hold the same lock.
+
+> [[Done]].
diff --git a/doc/bugs/confirmed.mdwn b/doc/bugs/confirmed.mdwn
new file mode 100644
index 0000000000..1bb3c864fc
--- /dev/null
+++ b/doc/bugs/confirmed.mdwn
@@ -0,0 +1,5 @@
+This tag is for bugs that have been confirmed to be real bugs, and so are likely
+to be the next bugs fixed.
+
+If your bug report is not tagged as confirmed, you probably need to provide more
+information so that the bug can be reproduced.
diff --git a/doc/bugs/conflict_resolution___40____63____41___test_stalls_on_an_occasion.mdwn b/doc/bugs/conflict_resolution___40____63____41___test_stalls_on_an_occasion.mdwn
new file mode 100644
index 0000000000..075a1841ce
--- /dev/null
+++ b/doc/bugs/conflict_resolution___40____63____41___test_stalls_on_an_occasion.mdwn
@@ -0,0 +1,40 @@
+### Please describe the problem.
+
+In a daily testing of git-annex on client systems, on `smaug` we observed tests stalling and being eventually killed once in a while consistently at `conflict resolution (mixed locked and unlocked file):` step:
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex-ci-client-jobs[master]builds/2022
+$> datalad foreach-dataset --o-s relpath git grep 'Elapsed time: 3600 seconds'
+06/result-smaug-720/handle-result.yaml-164-4355efb7-success/result-smaug-720/git-annex.log:    conflict resolution (nonannexed symlink): + echo 'Elapsed time: 3600 seconds'                                                                                       
+06/result-smaug-720/handle-result.yaml-164-4355efb7-success/result-smaug-720/git-annex.log:Elapsed time: 3600 seconds
+11/result-smaug-900/handle-result.yaml-437-402e214e-success/result-smaug-900/git-annex.log:        present False:                                   + echo 'Elapsed time: 3600 seconds'                                                                            
+11/result-smaug-900/handle-result.yaml-437-402e214e-success/result-smaug-900/git-annex.log:Elapsed time: 3600 seconds
+08/result-smaug-787/handle-result.yaml-276-ca542974-success/result-smaug-787/git-annex.log:    conflict resolution (nonannexed symlink): + echo 'Elapsed time: 3600 seconds'                                                                                       
+08/result-smaug-787/handle-result.yaml-276-ca542974-success/result-smaug-787/git-annex.log:Elapsed time: 3600 seconds
+10/result-smaug-853/handle-result.yaml-373-7e7a9411-success/result-smaug-853/git-annex.log:    conflict resolution (mixed locked and unlocked file): + echo 'Elapsed time: 3600 seconds'                                                                           
+10/result-smaug-853/handle-result.yaml-373-7e7a9411-success/result-smaug-853/git-annex.log:Elapsed time: 3600 seconds
+10/result-smaug-854/handle-result.yaml-375-d95326d3-success/result-smaug-854/git-annex.log:    conflict resolution (nonannexed symlink): + echo 'Elapsed time: 3600 seconds'
+10/result-smaug-854/handle-result.yaml-375-d95326d3-success/result-smaug-854/git-annex.log:Elapsed time: 3600 seconds
+```
+
+so far seemed to happen only on smaug among "test clients". 
+
+### What version of git-annex are you using? On what operating system?
+
+in above `grep` the versions are:
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex-ci-client-jobs[master]builds/2022
+$> datalad foreach-dataset --o-s relpath git grep -l 'Elapsed time: 3600 seconds' | xargs grep '^git-annex version:' | sort -n
+06/result-smaug-720/handle-result.yaml-164-4355efb7-success/result-smaug-720/git-annex.log:git-annex version: 10.20220525+git47-g4bf796225-1~ndall+1
+08/result-smaug-787/handle-result.yaml-276-ca542974-success/result-smaug-787/git-annex.log:git-annex version: 10.20220724+git77-ga24ae0814-1~ndall+1
+10/result-smaug-853/handle-result.yaml-373-7e7a9411-success/result-smaug-853/git-annex.log:git-annex version: 10.20220927+git27-g82dab0749-1~ndall+1
+10/result-smaug-854/handle-result.yaml-375-d95326d3-success/result-smaug-854/git-annex.log:git-annex version: 10.20220927+git27-g82dab0749-1~ndall+1
+11/result-smaug-900/handle-result.yaml-437-402e214e-success/result-smaug-900/git-annex.log:git-annex version: 10.20221103+git9-gad7dfdb37-1~ndall+1
+```
+
+full logs are available on smaug at the paths listed above
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
diff --git a/doc/bugs/conflict_resolution___40____63____41___test_stalls_on_an_occasion/comment_1_ab2c1db51a42a146708b28f4cb3309a6._comment b/doc/bugs/conflict_resolution___40____63____41___test_stalls_on_an_occasion/comment_1_ab2c1db51a42a146708b28f4cb3309a6._comment
new file mode 100644
index 0000000000..ebda9a160d
--- /dev/null
+++ b/doc/bugs/conflict_resolution___40____63____41___test_stalls_on_an_occasion/comment_1_ab2c1db51a42a146708b28f4cb3309a6._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-11-07T16:32:15Z"
+ content="""
+I notice that just the init test is taking 346 seconds to run. Then the add
+test is taking 499 seconds. Those are both tests that do very little work,
+and here run in 1s or so. The only thing "wrong" with the conflict resolution tests
+may be that they do 10x as much work.
+
+In the same log, the quickcheck tests, which are entirely CPU bound, ran at normal
+speed. So probably it's disk IO slowing the other tests down.
+
+Also, `result-smaug-900/handle-result.yaml-437-402e214e-success/result-smaug-900/git-annex.log`
+times out on another test. So I'm sure the problem is not a specific test stalling.
+
+And in `result-smaug-899/handle-result.yaml-435-3e89687a-success/result-smaug-899/git-annex.log`,
+it succeeds in 856 seconds. That still seems slow, my laptop can run it in 250 seconds
+with 4 cores (even when using -J16). That makes me think that the IO load (or whatever)
+on smaug is varying and slowing down the test by different amounts.
+
+Smaug has 16 cores. The test suite automatically parallelizes, so there
+will be 16 worker processes. But each worker process has to itself 
+run the init and add tests, which are prereqs for most other tests. So those
+tests are being run 16 times. Which just by itself, at the 346 and 499 second
+run times, will take more than an hour. Also if disk IO is starved, a lot
+of workers is only going to thrash it more.
+
+So `git-annex test -J1` or so seems like a good idea.
+
+It might also be better to not have a single timeout for the whole
+test suite, but time out if it stalls for long enough without generating new
+output.
+"""]]
diff --git a/doc/bugs/conflict_resolution___40____63____41___test_stalls_on_an_occasion/comment_2_e7da4a54b27f459d528a7651fd615913._comment b/doc/bugs/conflict_resolution___40____63____41___test_stalls_on_an_occasion/comment_2_e7da4a54b27f459d528a7651fd615913._comment
new file mode 100644
index 0000000000..2118ae0519
--- /dev/null
+++ b/doc/bugs/conflict_resolution___40____63____41___test_stalls_on_an_occasion/comment_2_e7da4a54b27f459d528a7651fd615913._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-11-07T17:07:52Z"
+ content="""
+I wondered if running the add and init tests once per worker was causing
+a diminishing returns at higher -J levels. Since at -J16, each worker runs
+the add and init tests followed by only 2 or 3 other tests, the time spent
+on the add and init tests becomes more and more significant.
+
+Timings from my laptop (with 4 cores):
+
+	-J16    250 seconds
+	-J8     212 seconds
+	-J4     214 seconds
+        -J2     307 seconds
+
+So a small diminishing returns at -J16.
+
+After some improvements:
+
+	-J16    223 seconds
+	-J8     218 seconds
+	-J4     214 seconds
+
+That won't solve smaug being so overloaded though.
+If anything, it will just make it get to some other test before it times out..
+"""]]
diff --git a/doc/bugs/copy+rename_of_file_on_windows_breaks_original.mdwn b/doc/bugs/copy+rename_of_file_on_windows_breaks_original.mdwn
new file mode 100644
index 0000000000..538fd45399
--- /dev/null
+++ b/doc/bugs/copy+rename_of_file_on_windows_breaks_original.mdwn
@@ -0,0 +1,49 @@
+### Please describe the problem.
+Copying and renaming a file "breaks" the original. I'm not using git-annex long enough to use the correct terminology here. "Broken" means "git annex status" reports "fatal: Not a valid object name".
+
+### What steps will reproduce the problem?
+Using the Assistant on Windows, create a fresh repository. Place a file called starship.jpg in the root. Make two directories, called "pic" and "space". Using Explorer, move the picture into "space". Move "space" into "pic". Go into "pic>space". Copy the image and paste it to the root of the repo. Rename the image "wallpaper.jpg". 
+
+
+[[!format sh """
+$ git annex info wallpaper.jpg
+file: wallpaper.jpg
+size: 225.75 kilobytes
+key: SHA256E-s225747--e5cba8967f4bea1a971e7405169056852beb3efbbf7fa2d3758c61ba769296c1.jpg
+present: true
+
+$ git annex info pic/space/starship.jpg
+fatal: Not a valid object name pic/space/starship.jpg
+info pic/space/starship.jpg (not a directory or an annexed file or a treeish or a remote or a uuid) failed
+
+$ git annex status
+D .\space/starship.jpg
+? .\pic/space/starship.jpg
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+[[!format sh """
+$ git annex version
+git-annex version: 10.20220526-gc6b112108
+build flags: Assistant Webapp Pairing TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+local repository version: 8
+"""]]
+
+OS: Windows 10 Pro, 21H1, 19043.1766
+
+### Please provide any additional information below.
+There's no .git/annex/daemon.log in my repo. Probably because after encountering this issue and reproducing it for this report, I made a new repo, and it seems that the Assistant's logs ended up in the original repo's logs.
+
+Test image used in this bug report: https://wallpapercave.com/wp/wp8215486.jpg
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I'm really loving git-annex. I've been reading up and I'm more than halfway through the devlog and I'm hoping to use git-annex for a lot and a long while. Mostly, I'm expecting to use it on Linux systems, but I'd love to be able to rely on it on my (Windows) work laptop as well. Thanks for looking at my report!
+
+[[!meta title="assistant on windows misses copy+rename of file"]]
+[[done]]
diff --git a/doc/bugs/copy+rename_of_file_on_windows_breaks_original/comment_1_c6e8e3e76185b6ca25067c2a7e5cd8fc._comment b/doc/bugs/copy+rename_of_file_on_windows_breaks_original/comment_1_c6e8e3e76185b6ca25067c2a7e5cd8fc._comment
new file mode 100644
index 0000000000..4c25df1a09
--- /dev/null
+++ b/doc/bugs/copy+rename_of_file_on_windows_breaks_original/comment_1_c6e8e3e76185b6ca25067c2a7e5cd8fc._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-06-28T16:29:03Z"
+ content="""
+Well, this appears to be a case where the assistant somehow misses the
+rename of the file, so it has not gotten around to annexing it.
+
+You can get the same error message when not using the assistant, eg:
+
+	# touch foo
+	# git-annex info foo
+	fatal: Not a valid object name foo
+	info foo (not a directory or an annexed file or a treeish or a remote or a uuid) failed
+
+I guess that `git-annex add` would resolve your problem.
+The assistant should also notice the file the next time it starts up,
+and add it the same as it would any new file.
+"""]]
diff --git a/doc/bugs/copy+rename_of_file_on_windows_breaks_original/comment_2_7e2604bad32225682513b51c1be6f571._comment b/doc/bugs/copy+rename_of_file_on_windows_breaks_original/comment_2_7e2604bad32225682513b51c1be6f571._comment
new file mode 100644
index 0000000000..6b7f71ed00
--- /dev/null
+++ b/doc/bugs/copy+rename_of_file_on_windows_breaks_original/comment_2_7e2604bad32225682513b51c1be6f571._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="contr-error"
+ avatar="http://cdn.libravatar.org/avatar/d79c2491dfc6947b8084796b06174cdb"
+ subject="comment 2"
+ date="2022-06-29T19:13:56Z"
+ content="""
+Hi Joey, thanks for looking into this and your work on git-annex! You're correct on both counts. After posting the report I tried manually adding the file and, indeed, restarting the assistant also makes it notice the file. I'm still exploring, but what seemed to be inscrutable behaviour at first, now seems reasonable enough.
+
+I've also encountered some access violations and I'm running into sqlite errors on WSL (1 & 2), both of which probably aren't worth reporting at this time, and the latter of which is probably out of scope of this bug tracker, anyway.
+"""]]
diff --git a/doc/bugs/copy_--fast_--from_--to_checks_destination_files.mdwn b/doc/bugs/copy_--fast_--from_--to_checks_destination_files.mdwn
new file mode 100644
index 0000000000..64cf7c1025
--- /dev/null
+++ b/doc/bugs/copy_--fast_--from_--to_checks_destination_files.mdwn
@@ -0,0 +1,88 @@
+### Please describe the problem.
+
+I need to "quickly" ensure that remote has all the files it should have gotten. For that I use invocation like
+
+```
+time git annex copy --fast --from web --to dandi-dandisets-dropbox
+```
+
+or
+
+```
+time git annex copy --auto --from web --to dandi-dandisets-dropbox
+```
+
+but then in the cases where all files are already there according to
+
+```
+dandi@drogon:/mnt/backup/dandi/dandisets/000003$ time git annex find  --not --in dandi-dandisets-dropbox
+
+real    0m0.562s
+user    0m0.051s
+sys     0m0.019s
+```
+
+the `copy` still goes and checks every chunk of every file
+
+```
+dandi@drogon:/mnt/backup/dandi/dandisets/000003$ time git annex copy --fast --from web --to dandi-dandisets-dropbox
+copy sub-YutaMouse20/sub-YutaMouse20_ses-YutaMouse20-140321_behavior+ecephys.nwb Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+^C
+
+real    0m3.886s
+user    0m0.037s
+sys     0m0.032s
+
+```
+
+so to achieve what I need, I thought to explicitly specify the query:
+
+```
+dandi@drogon:/mnt/backup/dandi/dandisets/000003$ time git annex copy --fast --not --in dandi-dandisets-dropbox --from web --to dandi-dandisets-dropbox
+
+real    0m0.221s
+user    0m0.056s
+sys     0m0.018s
+```
+
+but it  doesn't works out correctly whenever there are some files to actually copy:
+
+```
+dandi@drogon:/mnt/backup/dandi/dandisets/000037$ git annex find --in web --not --in dandi-dandisets-dropbox | nl | tail -n 2
+    40  sub-440889/sub-440889_ses-837360280_obj-raw_behavior+image+ophys.nwb
+    41  sub-440889/sub-440889_ses-838633305_obj-raw_behavior+image+ophys.nwb
+dandi@drogon:/mnt/backup/dandi/dandisets/000037$ git annex copy --fast --from web --to dandi-dandisets-dropbox --not --in dandi-dandisets-dropbox
+dandi@drogon:/mnt/backup/dandi/dandisets/000037$ git annex copy --fast --from web --to dandi-dandisets-dropbox --in web --not --in dandi-dandisets-dropbox
+dandi@drogon:/mnt/backup/dandi/dandisets/000037$ git annex copy --from web --to dandi-dandisets-dropbox --in web --not --in dandi-dandisets-dropbox
+```
+
+so the only way now would be to pipe `find` output into `copy`?
+
+note on edit: filed a dedicated [https://git-annex.branchable.com/bugs/copy_--from_--to_does_not_copy_if_present_locally/](https://git-annex.branchable.com/bugs/copy_--from_--to_does_not_copy_if_present_locally/) 
+
+NB `git annex find` has `-z` for input but not for output...
+
+
+refs to related reports/issues which were said to be addressed for `--fast` mode:
+
+- [https://git-annex.branchable.com/forum/copy_--auto_copies_already_synced_files/](https://git-annex.branchable.com/forum/copy_--auto_copies_already_synced_files/)
+- [https://git-annex.branchable.com/forum/batch_check_on_remote_when_using_copy/](https://git-annex.branchable.com/forum/batch_check_on_remote_when_using_copy/)
+
+### What version of git-annex are you using? On what operating system?
+
+
+```
+10.20230321-1~ndall+1
+```
+
+and then in conda with `10.20230626-g801c4b7` 
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/copy_--fast_--from_--to_checks_destination_files/comment_1_2a2997e6f914afb0477f2baa69b174fc._comment b/doc/bugs/copy_--fast_--from_--to_checks_destination_files/comment_1_2a2997e6f914afb0477f2baa69b174fc._comment
new file mode 100644
index 0000000000..5682b0cc8a
--- /dev/null
+++ b/doc/bugs/copy_--fast_--from_--to_checks_destination_files/comment_1_2a2997e6f914afb0477f2baa69b174fc._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-11-17T20:57:19Z"
+ content="""
+> but it doesn't works out correctly whenever there are some files to actually copy
+
+I think that was due to the bug you linked, which is now fixed.
+
+I've confirmed that `--fast` is not actually implemented for `git-annex
+copy --from --to`. Explicitly specifying `--not --in destremote` is a
+fine workaround. But I've gone ahead and implemented `--fast` for it too.
+"""]]
diff --git a/doc/bugs/copy_--fast_--from_--to_checks_destination_files/comment_2_f7bf30e8cc2d1995976bde723dfbfe01._comment b/doc/bugs/copy_--fast_--from_--to_checks_destination_files/comment_2_f7bf30e8cc2d1995976bde723dfbfe01._comment
new file mode 100644
index 0000000000..a12cc7c372
--- /dev/null
+++ b/doc/bugs/copy_--fast_--from_--to_checks_destination_files/comment_2_f7bf30e8cc2d1995976bde723dfbfe01._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-11-17T21:16:35Z"
+ content="""
+BTW `git-annex find --print0`  is the output eqivilant of -z.
+"""]]
diff --git a/doc/bugs/copy_--from_--to_does_not_adjust_avail_info.mdwn b/doc/bugs/copy_--from_--to_does_not_adjust_avail_info.mdwn
new file mode 100644
index 0000000000..40f6d995b7
--- /dev/null
+++ b/doc/bugs/copy_--from_--to_does_not_adjust_avail_info.mdwn
@@ -0,0 +1,55 @@
+### Please describe the problem.
+
+```
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandizarrs/27964c5b-6ccd-4e23-a67d-a535282bab34$ git annex whereis 0/0/0/13/2/12 | head
+whereis 0/0/0/13/2/12 (1 copy) 
+        00000000-0000-0000-0000-000000000001 -- web
+
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/0/0
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/1/0
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/10/0
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/11/0
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/12/0
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/13/0
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/14/0
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandizarrs/27964c5b-6ccd-4e23-a67d-a535282bab34$ time git annex copy --from web --to dandi-dandizarrs-dropbox 0/0/0/13/2/12
+copy 0/0/0/13/2/12 (from web...) (to dandi-dandizarrs-dropbox...) ok
+
+real    0m0.366s
+user    0m0.104s
+sys     0m0.042s
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandizarrs/27964c5b-6ccd-4e23-a67d-a535282bab34$ git annex whereis 0/0/0/13/2/12 | head
+whereis 0/0/0/13/2/12 (1 copy) 
+        00000000-0000-0000-0000-000000000001 -- web
+
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/0/0
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/1/0
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/10/0
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/11/0
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/12/0
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/13/0
+  web: https://api.dandiarchive.org/api/zarr/27964c5b-6ccd-4e23-a67d-a535282bab34.zarr/0/0/0/1/14/0
+
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandizarrs/27964c5b-6ccd-4e23-a67d-a535282bab34$ git annex list 0/0/0/13/2/12
+here
+|github
+||dandiapi
+|||web
+||||bittorrent
+|||||dandi-dandizarrs-dropbox (untrusted)
+||||||
+__XX__ 0/0/0/13/2/12
+```
+
+I would expect `copy` to make a record locally that now the content is also on destination remote, so 2nd invocation of `copy --from ... --to ... --auto` does nothing.
+
+### What version of git-annex are you using? On what operating system?
+
+```
+10.20230227-gb02b9cc  Debian GNU/Linux
+```
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/copy_--from_--to_does_not_adjust_avail_info/comment_1_d6a1dd2e039dcb6dafcf4675b9244617._comment b/doc/bugs/copy_--from_--to_does_not_adjust_avail_info/comment_1_d6a1dd2e039dcb6dafcf4675b9244617._comment
new file mode 100644
index 0000000000..b5698f0fe1
--- /dev/null
+++ b/doc/bugs/copy_--from_--to_does_not_adjust_avail_info/comment_1_d6a1dd2e039dcb6dafcf4675b9244617._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-13T18:34:36Z"
+ content="""
+Aah, I see, this is when the content is present on the --to
+remote, but git-annex is not locally aware of that yet.
+
+And `git-annex copy --to remote` does
+update location tracking in such a case, so --from --to should also.
+"""]]
diff --git a/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally.mdwn b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally.mdwn
new file mode 100644
index 0000000000..af7a4e0da8
--- /dev/null
+++ b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally.mdwn
@@ -0,0 +1,93 @@
+### Please describe the problem.
+
+originally reported while composing [https://git-annex.branchable.com/bugs/copy_--fast_--from_--to_checks_destination_files/](https://git-annex.branchable.com/bugs/copy_--fast_--from_--to_checks_destination_files/) but it is a separate issue: some files are simply not `annex copy`'ed at all: here it tries 6 out of 8 files and still reports that 2 are not on the target remote:
+
+```
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000235$ git annex copy --from web --to dandi-dandisets-dropbox --fast
+copy sub-Fish01-GCaMP-vlgut-FBd-5dpf-RandomWave/sub-Fish01-GCaMP-vlgut-FBd-5dpf-RandomWave_ses-20210818T112556_behavior+ophys.nwb Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 696.194 MBytes (730012683 Bytes)
+(from web...) (to dandi-dandisets-dropbox...) ok
+copy sub-Fish13-GCaMP-vlgut-FBv-5dpf-RandomWave/sub-Fish13-GCaMP-vlgut-FBv-5dpf-RandomWave_ses-20210830T100716_behavior+ophys.nwb Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 224.618 MBytes (235528804 Bytes)
+(from web...) (to dandi-dandisets-dropbox...) ok
+copy sub-Fish31-GCaMP-vlgut-FBd-5dpf-RandomWave/sub-Fish31-GCaMP-vlgut-FBd-5dpf-RandomWave_ses-20210920T120959_behavior+ophys.nwb Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 295.387 MBytes (309735634 Bytes)
+(from web...) (to dandi-dandisets-dropbox...) ok
+copy sub-Fish32-GCaMP-vlgut-FBv-5dpf-RandomWave/sub-Fish32-GCaMP-vlgut-FBv-5dpf-RandomWave_ses-20210920T181347_behavior+ophys.nwb Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 860.168 MBytes (901951882 Bytes)
+(from web...) (to dandi-dandisets-dropbox...) ok
+copy sub-Fish47-GCaMP-vlgut-FBd-7dpf-RandomWave/sub-Fish47-GCaMP-vlgut-FBd-7dpf-RandomWave_ses-20211124T174401_behavior+ophys.nwb Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 856.342 MBytes (897939760 Bytes)
+(from web...) (to dandi-dandisets-dropbox...) ok
+copy sub-Fish58-GCaMP-vlgut-FBd-5dpf-RandomWave/sub-Fish58-GCaMP-vlgut-FBd-5dpf-RandomWave_ses-20220525T092829_behavior+ophys.nwb Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 953.674 MBytes (1000000000 Bytes)
+Total objects: 1 Total size: 948.656 MBytes (994737479 Bytes)
+(from web...) (to dandi-dandisets-dropbox...) ok
+
+
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000235$ git annex find --in web --not --in dandi-dandisets-dropbox | nl
+     1  sub-Fish02-GCaMP-vlgut-FBv-5dpf-RandomWave/sub-Fish02-GCaMP-vlgut-FBv-5dpf-RandomWave_ses-20210818T173531_behavior+ophys.nwb
+     2  sub-Fish41-GCaMP-vlgut-FBv-7dpf-RandomWave/sub-Fish41-GCaMP-vlgut-FBv-7dpf-RandomWave_ses-20210929T173736_behavior+ophys.nwb
+```
+
+and it seems to boil down (at least in one case, don't know yet if generalizes to other cases I have) to having those keys present locally:
+
+
+```
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000235$ git annex find --in web --not --in dandi-dandisets-dropbox | xargs ls -lL
+-r--r--r-- 1 dandi dandi 3878847966 Mar 16  2023 sub-Fish02-GCaMP-vlgut-FBv-5dpf-RandomWave/sub-Fish02-GCaMP-vlgut-FBv-5dpf-RandomWave_ses-20210818T173531_behavior+ophys.nwb
+-r--r--r-- 1 dandi dandi 3665589468 Mar 16  2023 sub-Fish41-GCaMP-vlgut-FBv-7dpf-RandomWave/sub-Fish41-GCaMP-vlgut-FBv-7dpf-RandomWave_ses-20210929T173736_behavior+ophys.nwb
+```
+
+but somehow it doesn't know that it has them according to `list`:
+
+```
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000235$ git annex list
+here
+|github
+||dandiapi
+|||web
+||||bittorrent
+|||||dandi-dandisets-dropbox (untrusted)
+||||||
+__XX_x sub-Fish01-GCaMP-vlgut-FBd-5dpf-RandomWave/sub-Fish01-GCaMP-vlgut-FBd-5dpf-RandomWave_ses-20210818T112556_behavior+ophys.nwb
+__XX__ sub-Fish02-GCaMP-vlgut-FBv-5dpf-RandomWave/sub-Fish02-GCaMP-vlgut-FBv-5dpf-RandomWave_ses-20210818T173531_behavior+ophys.nwb
+__XX_x sub-Fish13-GCaMP-vlgut-FBv-5dpf-RandomWave/sub-Fish13-GCaMP-vlgut-FBv-5dpf-RandomWave_ses-20210830T100716_behavior+ophys.nwb
+__XX_x sub-Fish31-GCaMP-vlgut-FBd-5dpf-RandomWave/sub-Fish31-GCaMP-vlgut-FBd-5dpf-RandomWave_ses-20210920T120959_behavior+ophys.nwb
+__XX_x sub-Fish32-GCaMP-vlgut-FBv-5dpf-RandomWave/sub-Fish32-GCaMP-vlgut-FBv-5dpf-RandomWave_ses-20210920T181347_behavior+ophys.nwb
+__XX__ sub-Fish41-GCaMP-vlgut-FBv-7dpf-RandomWave/sub-Fish41-GCaMP-vlgut-FBv-7dpf-RandomWave_ses-20210929T173736_behavior+ophys.nwb
+__XX_x sub-Fish47-GCaMP-vlgut-FBd-7dpf-RandomWave/sub-Fish47-GCaMP-vlgut-FBd-7dpf-RandomWave_ses-20211124T174401_behavior+ophys.nwb
+__XX_x sub-Fish58-GCaMP-vlgut-FBd-5dpf-RandomWave/sub-Fish58-GCaMP-vlgut-FBd-5dpf-RandomWave_ses-20220525T092829_behavior+ophys.nwb
+
+```
+
+running without `--from web` starts the transfer:
+
+```
+git annex copy --fast --to dandi-dandisets-dropbox
+```
+
+IMHO it should perform copy from the local store into the remote since in effect it would be fulfilling the goal - adding a copy to the destination.
+I didn't check `move` command but if it does support similar `--from --to` and has similar defect -- should just compliment with dropping after from the original remote.
+
+### What version of git-annex are you using? On what operating system?
+
+10.20230626-g801c4b7 from conda-forge .
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_1_ae76f27d9ef4ebac7ad57e6aef9a7586._comment b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_1_ae76f27d9ef4ebac7ad57e6aef9a7586._comment
new file mode 100644
index 0000000000..75b6338818
--- /dev/null
+++ b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_1_ae76f27d9ef4ebac7ad57e6aef9a7586._comment
@@ -0,0 +1,57 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-11-17T19:58:39Z"
+ content="""
+> -r--r--r-- 1 dandi dandi 3665589468 Mar 16  2023 sub-Fish41-GCaMP-vlgut-FBv-7dpf-RandomWave/sub-Fish41-GCaMP-vlgut-FBv-7dpf-RandomWave_ses-20210929T173736_behavior+ophys.nwb
+
+This could be an unlocked file that has gotten modified but the staged
+version is not actually present locally. Or if `git-annex fsck` on it says
+its fixing the location logs, that would tell us something happened that
+got the location tracking out of sync with reality.
+
+So possibly there's an issue that could be tracked down regarding the state
+of that file. But in either case, git-annex doesn't know it has a local
+copy of the file, so `copy --from --to` could not use it.
+
+----
+
+But: `copy --from --to` does in fact have an interesting bug:
+
+	joey@darkstar:~/tmp/bench/r2>git-annex whereis foo
+	whereis foo (2 copies)
+	  	22dfa446-7482-4c0a-92c9-70db793859fb -- joey@darkstar:~/tmp/bench/r [origin]
+	   	8a504049-2c22-4baa-9a16-218e9561608b -- joey@darkstar:~/tmp/bench/r2 [here]
+	ok
+	joey@darkstar:~/tmp/bench/r2>git-annex copy foo --from origin --to r3
+	joey@darkstar:~/tmp/bench/r2>
+
+So the file content being present locally prevents it sending it to the remote! This needs to get fixed.
+
+Hmm: In the corresponding case of `git-annex move --from --to`, it does not
+behave that way.
+
+----
+
+As far as what the behavior ought to be when a file is present locally but not on the --from remote,
+the documentation does say:
+
+       --from=remote
+
+              Copy the content of files from the specified remote to the local repository.
+
+              Any files that are not available on the remote will be silently skipped.
+
+So it is behaving as documented. I can think of two reasons why that
+documented behavior makes some sense:
+
+* The user may be intending to only copy files --to that are present in --from.
+  The local repo may have a lot of files they do not want to populate --to.
+  (For example, perhaps the goal is to make a replica of the --from
+  repository.)
+  With that said, the user could do `git-annex copy --from foo --to bar --in foo`
+  to explicitly only act on files that are present in it.
+* Performance. Needing to check if there is a local copy when there is no
+  remote copy would be a little extra work. Likely not enough to be
+  significant though.
+"""]]
diff --git a/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_2_e857c1d89b350517fcb9829e52d6c6db._comment b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_2_e857c1d89b350517fcb9829e52d6c6db._comment
new file mode 100644
index 0000000000..d9d1bc1602
--- /dev/null
+++ b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_2_e857c1d89b350517fcb9829e52d6c6db._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-11-17T20:27:37Z"
+ content="""
+> So the file content being present locally prevents it sending it to the remote!
+
+Fixed that.
+"""]]
diff --git a/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_3_492d7c932fe5663aab916aacc829fb5d._comment b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_3_492d7c932fe5663aab916aacc829fb5d._comment
new file mode 100644
index 0000000000..a3d85237bf
--- /dev/null
+++ b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_3_492d7c932fe5663aab916aacc829fb5d._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-11-17T20:33:01Z"
+ content="""
+That bug I fixed would also explain the behavior that you saw if the
+content *was* present locally, and the location log *was* out of date about
+that.
+
+In that situation, git-annex sees that the object file is present, and so
+treats the content as present, despite the location log not knowing it's
+present. Which triggers the situation of the bug I fixed, causing it to
+skip copying the file.
+
+Also, there's a pretty easy way to get into this situation. When the file
+is not present, run `git-annex --from --to`. Then interrupt it after it's
+downloaded the file --from but before it's finished sending it --to.
+This results in the file being present locally, but only transiently so it
+didn't update the location log.
+
+So my guess is you interrupted a copy like that (or it failed incomplete
+for whatever reason).
+
+Now that I've fixed that bug, the behavior in that situation is that it
+does copy the file to the remote. And then it drops the local copy since
+the location log doesn't contain it. So it resumes correctly now.
+"""]]
diff --git a/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_4_8cfb9f2c14559a7574edd29b161cf7c7._comment b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_4_8cfb9f2c14559a7574edd29b161cf7c7._comment
new file mode 100644
index 0000000000..8afe914bd7
--- /dev/null
+++ b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_4_8cfb9f2c14559a7574edd29b161cf7c7._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-11-17T20:42:24Z"
+ content="""
+So that leaves only the question of what it should do when
+content is present locally but not on the --from remote.
+
+Another reason for the current behavior is to be symmetric with `git-annex
+move --from foo --to bar`. It would be surprising, I think, if that
+populated bar with files that are not present in foo, but are in the local
+repository!
+
+So I'm inclined to not change the documented behavior. If you want to
+populate a remote with files that are either in the local repo or in a
+--from remote, you can just run `git-annex copy` twice after all.
+
+(Or there could be a new option like `git-annex copy --to bar --from foo --or-from-here`)
+"""]]
diff --git a/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_5_fd23d0559018c531595cd06f81290258._comment b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_5_fd23d0559018c531595cd06f81290258._comment
new file mode 100644
index 0000000000..0354a9a3a8
--- /dev/null
+++ b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_5_fd23d0559018c531595cd06f81290258._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2023-11-18T01:35:35Z"
+ content="""
+> (Or there could be a new option like git-annex copy --to bar --from foo --or-from-here)
+
+or may be 
+
+`git-annex copy --to bar --from remote1 --or-from remote2 ...` or alike so there could be a sequence (in order of preference) of remotes?  or better a general `git-annex copy --to bar --from-anywhere` so that `annex` first `get`'s it following current set costs etc if not present here, and then copies over.
+"""]]
diff --git a/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_6_c374eb44ea08f220dbcce5ecb88403fb._comment b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_6_c374eb44ea08f220dbcce5ecb88403fb._comment
new file mode 100644
index 0000000000..38e8ea92d2
--- /dev/null
+++ b/doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_6_c374eb44ea08f220dbcce5ecb88403fb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-11-30T18:26:30Z"
+ content="""
+I like the idea of `copy --from-anywhere --to=remote` and just 
+use the lowest cost remote (when not in local repo). Like `git-annex get`
+and `git-annex copy --to=here`.
+
+Hmm, if there's a remote that is too expensive to want to use in such a
+copy, it would be possible to use `-c remote.foo.annex-ignore=true`
+to make it avoid using that remote. As can also be done in the case of
+`git-annex get`, although that was not documented well.
+
+I've implemented --from-anywhere..
+"""]]
diff --git a/doc/bugs/copy_-J_--to_local_git_remote_does_not_run_concurrently.mdwn b/doc/bugs/copy_-J_--to_local_git_remote_does_not_run_concurrently.mdwn
new file mode 100644
index 0000000000..b3ead46927
--- /dev/null
+++ b/doc/bugs/copy_-J_--to_local_git_remote_does_not_run_concurrently.mdwn
@@ -0,0 +1,36 @@
+I am copying files to a remote with -J3 and keep seeing this pattern:
+
+	copy x (to remote..) ok
+	copy foo (to remote...)
+	47%   1.03 GiB         31 MiB/s 37s
+	copy bar (to remote...)
+	copy baz (to remote...)
+
+Ie, there are 3 active jobs, but only one of them, typically the first of
+them, is actually copying. The other 2 are blocked on something which must
+be a resource the 1 is keeping busy.
+
+That was with the remote having a path as an url. Changed it to
+localhost:path and 3 transfers ran concurrently with progress meters.
+
+copy --from/get also runs concurrently, only --to has the problem.
+
+Also, a copy --to a directory special remote runs concurrently. So
+only local path git remotes have the problem.
+
+(Of course, there's often no benefit to parellizing writes to a disk as it
+will cause seeking, but -J requests it, and if the disk was a SSD, it
+would make sense to.)
+
+git-annex version: 8.20201103 --[[Joey]]
+
+> Reproduced with 10.20220625. 3 100 mb files and copy to a local git repo.
+> Also, `copy --from` and `get` do have the problem, at least they do now.
+> --[[Joey]]
+
+> The problem is that Remote.Git.onLocal uses a MVar for the remote state,
+> and the copy runs in that. So while one copy is running, the rest block.
+> So fixing this will need a pool of local remote states.
+> --[[Joey]]
+
+>> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/corrupt_backend_upon_sync__63__.mdwn b/doc/bugs/corrupt_backend_upon_sync__63__.mdwn
new file mode 100644
index 0000000000..e99dfcc88c
--- /dev/null
+++ b/doc/bugs/corrupt_backend_upon_sync__63__.mdwn
@@ -0,0 +1,78 @@
+### Please describe the problem.
+
+When syncing with a remote, I get some files with "unknown backend".
+
+Original:
+
+    $ ls -lh Pictures/2014/06/21/2014-06-21\ 13.52.34.png
+    lrwxrwxrwx 1 jean jean 214 Jun 21  2014 Pictures/2014/06/21/2014-06-21 13.52.34.png -> ../../../../.git/annex/objects/mx/Ff/SHA256E-s247069--d425c1049778880eb9b9fcab74a82ec86dd22882db9c026f8fc0e9cb6270d022.34.png/SHA256E-s247069--d425c1049778880eb9b9fcab74a82ec86dd22882db9c026f8fc0e9cb6270d022.34.png
+
+This picture and symlink is fine.
+
+Remote (broken symlink):
+
+    $ ls -lh Pictures/2014/06/21/2014-06-21\ 13.52.34.png
+    lrwxrwxrwx 1 jean jean 214 Apr  6 12:50 Pictures/2014/06/21/2014-06-21 13.52.34.png -> ./../../.git/annex/objects/mx/Ff/SHA256E-s247069--d425c134ac2f9b0eb9b9fcab74a82ec86dd22882db9c026f8fc0e9cb6270d022.34.pn0.png/SHE-s247069--d425c1049778880eb9b9fcab74a82ec86dd22882db9c09efe84ca9cb6270d022.34.png
+
+In this case the paths differ: there is an extra `.pn0` component, and the final `SHA256E` has changed to `SHE`.
+
+### What steps will reproduce the problem?
+
+I don't know yet.
+
+### What version of git-annex are you using? On what operating system?
+
+    $ git annex version
+    git-annex version: 5.20140412ubuntu1
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+Ubuntu 14.04.1 LTS
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+$ git annex info
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 6
+        00000000-0000-0000-0000-000000000001 -- web
+        ...
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 168.35 gigabytes (+1 megabyte reserved)
+local annex keys: 16503
+local annex size: 39.15 gigabytes
+annexed files in working tree:
+  skipping Pictures/2014/06/21/2014-06-21 13.52.34.png (unknown backend SHE)
+
+  skipping Pictures/2014/06/21/2014-06-21 13.52.45.png (unknown backend SHE)
+
+  skipping Pictures/2014/06/21/2014-06-21 13.58.03.png (unknown backend SHA256EE)
+104552
+size of annexed files in working tree: 124.64 gigabytes
+bloom filter size: 16 mebibytes (3.3% full)
+backend usage:
+        SHA256E: 121054
+        SHA256: 1
+
+$ git annex get --from=laptop
+
+  skipping Pictures/2014/06/21/2014-06-21 13.52.34.png (unknown backend SHE)
+
+  skipping Pictures/2014/06/21/2014-06-21 13.52.45.png (unknown backend SHE)
+
+  skipping Pictures/2014/06/21/2014-06-21 13.58.03.png (unknown backend SHA256EE)
+
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/corrupt_backend_upon_sync__63__/comment_1_9f248d82f93040b739b56515d18458c7._comment b/doc/bugs/corrupt_backend_upon_sync__63__/comment_1_9f248d82f93040b739b56515d18458c7._comment
new file mode 100644
index 0000000000..ddec07c1eb
--- /dev/null
+++ b/doc/bugs/corrupt_backend_upon_sync__63__/comment_1_9f248d82f93040b739b56515d18458c7._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T17:39:28Z"
+ content="""
+The symink that you're showing is a file checked into git.
+
+So, you should be able to run `git log 'Pictures/2014/06/21/2014-06-21 13.52.34.png'`
+on the remote and find a commit that somehow changed the symlink to the
+broken one that the remote has.
+
+The only other possibilities are
+
+* Somehow the data in git in the remote got corrupted, and git didn't
+  notice. Seems very unlikely.
+* Somehow git decided to munge up the symlink when checking it out on the
+  remote. While there are some git features like smudge filters that could
+  perhaps be configured to do that, I don't see how git could do it on its
+  own.
+
+I've never seen git do anything like this.
+You're going to have to investigate this on your own and/or provide enough
+information to reproduce the problem.
+"""]]
diff --git a/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been.mdwn b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been.mdwn
new file mode 100644
index 0000000000..05f3f5b7d1
--- /dev/null
+++ b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been.mdwn
@@ -0,0 +1,29 @@
+### Please describe the problem.
+
+This is a one-off thing, not a reproducible bug.  It was just so weird that I wanted to make a note of it in case somebody else had the same problem and it was reproducible.
+
+I have a remote on the a USB drive which I mount once in a while on /Volumes/TOSHIBAEXT which has a remote on /Volumes/TOSHIBAEXT/annex.   It's a remote which I created by hand using "git clone" a long time ago, not something the assistant set up for me.
+
+Anyway, today the assistant kept reporting that it could not sync to it.  I didn't know why, because I checked in my Finder sidebar and it showed a mounted drive called TOSHIBAEXT.  It's only when I checked with the command line that I noticed something was up!  There was now an ordinary directory at /Volumes/TOSHIBAEXT/annex.   This had apparently been created at some point when the drive was unmounted, so when it re-mounted, because there was a directory in the way, it re-mounted at "/Volumes/TOSHIBAEXT 1".  But it was displayed in the finder sidebar as just "TOSHIBAEXT" anyway because the finder hides this workaround from the user for whatever reason.
+
+Presumably git-annex assistant at some point, for some reason, created an ordinary directory where it expected to find the annex.
+
+I wonder if this may have to do with the fact that this is a non-bare, created-by-hand repo, from before I was using the assistant, not a normal bare remote that the assistant would have created for me if I'd been using the webapp.
+
+### What steps will reproduce the problem?
+
+I've only seen it once, and report the bug not as an outstanding issue but only as a heads-up that this has ever happened.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 4.20130501-gb61740e
+
+OS X lion (10.7)
+
+### Please provide any additional information below.
+
+I wasn't logging when this happened.
+
+Again, just a heads-up; I'll keep my eye open for this happening again and post more info if it does.
+
+[[!tag confirmed]]
diff --git a/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_1_41cfd5e48426a6ef52bef70a06a6f46a._comment b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_1_41cfd5e48426a6ef52bef70a06a6f46a._comment
new file mode 100644
index 0000000000..a4d0a5895e
--- /dev/null
+++ b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_1_41cfd5e48426a6ef52bef70a06a6f46a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 1"
+ date="2013-05-05T20:55:19Z"
+ content="""
+Huh.  This happened a second time today.  I'll try and catch it in the act, and make a proper bug report, when I get a chance.
+
+Still not sure this is a bug rather than just a peculiarity of how I have things set up.
+
+"""]]
diff --git a/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_2_bd584ccbe128427fca99e61d66d301c9._comment b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_2_bd584ccbe128427fca99e61d66d301c9._comment
new file mode 100644
index 0000000000..1d9e09ef95
--- /dev/null
+++ b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_2_bd584ccbe128427fca99e61d66d301c9._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-05-06T14:50:01Z"
+ content="""
+Hmm.. One way I can think that this could happen is if git-annex was running, and doing something in the repository on the drive that involved making a directory, and the drive was removed. There are several places in git-annex where it has code, like this:
+
+<pre>
+createAnnexDirectory
+-- some action here that expects to have the git-annex directory
+</pre>
+
+Is the repo you have on the drive a direct mode repo by any chance? This is the only obvious way I can see that would cause it to create just the top level directory of the repository, and not a deeper directory tree like `.git/annex/tmp/`
+
+The assistant also has a MountWatcher that detects when repositories that were not accessible get mounted, but it does not do anything to stop the repository being used when its drive gets unmounted. Even if it did, it couldn't go anything about code that is already running using the previously mounted repository. However, as things stand, it would probably also be possible for the drive to be removed, and some time to pass before an action was run that tried to do something to the no longer present repository.
+So making the mountwatcher disable repositories when drives are unmounted would at least make this window narrower.
+"""]]
diff --git a/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_3_5bb0347215b321444643646f25a35759._comment b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_3_5bb0347215b321444643646f25a35759._comment
new file mode 100644
index 0000000000..d163925427
--- /dev/null
+++ b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_3_5bb0347215b321444643646f25a35759._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 3"
+ date="2013-05-06T16:52:07Z"
+ content="""
+It's possible, even likely, that there were indeed more directories and I didn't notice because they were hidden and I just looked at them with a vanilla \"ls\" command with no flags like \"-a\".
+
+So it's probably exactly what you're thinking --t here was something going on, a transfer queued or something, that I didn't realize was happening and I removed it and it went and created the directory as if it were there.  
+"""]]
diff --git a/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_4_73848a9c783ecf3d9fccdd41b20fbe36._comment b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_4_73848a9c783ecf3d9fccdd41b20fbe36._comment
new file mode 100644
index 0000000000..7b588ecc73
--- /dev/null
+++ b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_4_73848a9c783ecf3d9fccdd41b20fbe36._comment
@@ -0,0 +1,56 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkfHTPsiAcHEEN7Xl7WxiZmYq-vX7azxFY"
+ nickname="Vincent"
+ subject="comment 4"
+ date="2013-07-24T14:19:01Z"
+ content="""
+I saw this too, today. The repo in my case was created via the webapp, using the 'usb key' option.
+I was messing about with deleting repos and had turned off synchronisation for the repo on the key as I didn't have it inserted.
+
+I only just stumbled on this bug report after removing the repository from the key entirely, so it's difficult to define the reproduction steps.
+
+* create a 'usb key' repo via webapp, transfer type
+* let it sync
+* disable sync
+* change a file in another repo, so there is something to sync
+* unmount key, unplug key
+* turn on sync again - should see 'failed ot sync with ...' in webapp dashboard
+* reinsert key
+* let it sync
+* unplug key without properly unmounting
+* change a file in another repo, so there is something to sync
+
+I just did this. The key was mounting at /Volumes/VERBATIM4. Just after unplugging without unmounting, that directory was gone.
+When I made the change that could be synced, I got a /Volumes/VERBATIM4 directory. The directory tree structure is similar to but different
+from the structure on the usb key, see below.
+
+Now when I try to plug it in again os/x will spot the potential conflict and mount the key at /Volumes/VERBATIM4\ 1.
+
+If I instead rm -rf /Volumes/VERBATIM4 and then replug the usb key, everything syncs as expected.
+
+Version: 4.20130723-ge023649 (os/x 10.8)
+
+Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS
+
+Tree structure of the phantom directory:
+
+    /Volumes/VERBATIM4/annex/
+    └── annex
+        ├── journal.lck
+        ├── objects
+        │   └── df3
+        │       └── 043
+        │           └── SHA256E-s17363--4c5ef74b4fcb9ecd962c6ecac694f87277e580836335e57924654762668a5448
+        │               └── SHA256E-s17363--4c5ef74b4fcb9ecd962c6ecac694f87277e580836335e57924654762668a5448
+        ├── tmp
+        └── transfer
+            ├── download
+            │   └── adf30a67-777a-45a6-a658-e2266770f01b
+            └── failed
+                └── download
+                    └── adf30a67-777a-45a6-a658-e2266770f01b
+                        └── SHA256E-s17363--4c5ef74b4fcb9ecd962c6ecac694f87277e580836335e57924654762668a5448
+
+    12 directories, 3 files
+
+"""]]
diff --git a/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_5_64bf56f2b0ff206c3caf5cadebfd0cda._comment b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_5_64bf56f2b0ff206c3caf5cadebfd0cda._comment
new file mode 100644
index 0000000000..49ab80ed4b
--- /dev/null
+++ b/doc/bugs/creating_a_plain_directory_where_a_mountpoint_should_have_been/comment_5_64bf56f2b0ff206c3caf5cadebfd0cda._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmTNrhkVQ26GBLaLD5-zNuEiR8syTj4mI8"
+ nickname="Juan"
+ subject="Same happening here"
+ date="2014-07-09T14:45:32Z"
+ content="""
+Any hint about how to stop this from happening again? This time I think I was careful and tried to stop git-annex, however I got ghosts.
+Whats the correct way to unplug the drive?
+
+My scenario is the following, I have two repos on HDD synced with a USB drive. I want to sync them to the USB drive from time to time when I plug it. I want a safe way to unplug drive without getting these ghost directories. 
+
+This time, I entered both directories in the HDD and made a git-annex assistant --stop, but after doing a ps aux | grep git-annex I still see many processes running so I'm not sure if I truly stopped it.
+The webapp gives me the impression of working on a per-repo basis, so I miss having some sort of general feedback about git-annex. Something like: \"at the moment you are syncing repos A and B\" or \"idle\".
+So I never have a clue about whats going on.
+I'm trying to set up this since long time, and I'm a very capable unix guy, and I still have the feeling that I can't trust git-annex.
+I really like the tool but I'm not sure how to use it properly.
+Thanks in advance.
+
+
+"""]]
diff --git a/doc/bugs/creating_a_remote_server_repository.mdwn b/doc/bugs/creating_a_remote_server_repository.mdwn
new file mode 100644
index 0000000000..07367d7731
--- /dev/null
+++ b/doc/bugs/creating_a_remote_server_repository.mdwn
@@ -0,0 +1,24 @@
+What steps will reproduce the problem?
+
+I was trying to add a remote server repository. Unfortunately, this didn't work. Enter Host name, user name, directory, port
+(left most of them at their default), but there is no way, to specify a password.) Clicking check this server failed:
+
+ Failed to ssh to the server. Transcript: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,password). 
+
+(Problem was, I could never enter a password. Interestingly, on the konsole, I get a prompt for a password, but I can't enter anything there).
+
+
+What is the expected output? What do you see instead?
+
+Successfully create a connection and use the remote server.
+
+
+What version of git-annex are you using? On what operating system?
+Version: 3.20130124
+
+
+
+Please provide any additional information below.
+
+[[!tag /design/assistant done]]
+[[!meta title="ssh password prompting issue with assistant"]]
diff --git a/doc/bugs/creating_a_remote_server_repository/comment_1_de1a370347428245bcfca60eaca96779._comment b/doc/bugs/creating_a_remote_server_repository/comment_1_de1a370347428245bcfca60eaca96779._comment
new file mode 100644
index 0000000000..aad008fd01
--- /dev/null
+++ b/doc/bugs/creating_a_remote_server_repository/comment_1_de1a370347428245bcfca60eaca96779._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.125"
+ subject="comment 1"
+ date="2013-02-05T19:22:04Z"
+ content="""
+You're not really intended to start the git-annex assistant from a console. If you do, ssh will go ahead and prompt for passwords using that controlling console.
+
+When the assistant is not started from a console, ssh should use the `ssh-askpass` to prompt for the password. Assuming your system has that installed.
+"""]]
diff --git a/doc/bugs/creating_a_remote_server_repository/comment_2_482ac9b0f881099910f9bd9f7cda184d._comment b/doc/bugs/creating_a_remote_server_repository/comment_2_482ac9b0f881099910f9bd9f7cda184d._comment
new file mode 100644
index 0000000000..2370f7d478
--- /dev/null
+++ b/doc/bugs/creating_a_remote_server_repository/comment_2_482ac9b0f881099910f9bd9f7cda184d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edward.myopenid.com/"
+ nickname="edward"
+ subject="Same problem on Android 4.3"
+ date="2013-12-01T08:47:06Z"
+ content="""
+I have the same error on Android. Is git-annex on Android meant to come with ssh-askpass?
+"""]]
diff --git a/doc/bugs/creating_a_remote_server_repository/comment_3_b7c7f684d0eef14fcc00cb2ac0566703._comment b/doc/bugs/creating_a_remote_server_repository/comment_3_b7c7f684d0eef14fcc00cb2ac0566703._comment
new file mode 100644
index 0000000000..ca56e7e3f5
--- /dev/null
+++ b/doc/bugs/creating_a_remote_server_repository/comment_3_b7c7f684d0eef14fcc00cb2ac0566703._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 3"
+ date="2013-12-01T20:10:02Z"
+ content="""
+The bug your are commenting on is over a year old, and is closed, and does not involve Android. If you're having trouble with android, file a new bug report.
+
+On android, git-annex runs from a terminal app. The ssh password prompting is currently done inside that app.
+"""]]
diff --git a/doc/bugs/creating_dot-git-as-symlink_workaround_drops_worktree_configuration_from_submodules.mdwn b/doc/bugs/creating_dot-git-as-symlink_workaround_drops_worktree_configuration_from_submodules.mdwn
new file mode 100644
index 0000000000..b65c9e568c
--- /dev/null
+++ b/doc/bugs/creating_dot-git-as-symlink_workaround_drops_worktree_configuration_from_submodules.mdwn
@@ -0,0 +1,58 @@
+### Please describe the problem.
+
+When using [[submodules]], a `git annex init` in the submodule drops the `core.workdir` configuration from the git config around the time it replaces the plain `.git` file with a symlink.
+
+The lack of that option rarely affects anything (the command-line git or -annex operations I've tried from inside the workdir went OK), but when libgit2 is used to load the submodule and discover its workdir, the missing option becomes apparent, and libgit2 reports an incorrect working directory.
+
+### What steps will reproduce the problem?
+
+As this is about a comparatively comprehensive setup, I've phrased it as a shell script:
+
+[[!format sh """
+git init inner-original
+cd inner-original
+touch inner-file
+git add inner-file
+git commit -m "initial inner check-in"
+cd ..
+
+git init outer
+cd outer
+git submodule add ../inner-original inner
+cd ..
+
+cp -a outer outer-with-annex
+cp -a outer outer-with-ln
+
+cd outer-with-annex/inner
+git annex init
+cd ../..
+cd outer-with-ln/inner
+ln -sf ../.git/modules/inner .git
+cd ../..
+"""]]
+
+Now apparently, all those inner directories still work (eg. `git diff inner-file`).
+However, `git config core.worktree` only reports on those that `git annex` did not touch.
+
+The practical problem arising with this can most easily seen when executing the following Python snippet in any of the outer directories:
+
+[[!format python """
+import pygit2
+r = pygit2.Repository(".")
+r2 = r.lookup_submodule("inner").open()
+print (r.workdir, r2.workdir)
+"""]]
+
+which reports the workdir of the outer correctly, but reports `$PATH/outer-with-annex/.git/modules/` (which is definitely not a workdir) for the annex.
+
+When the option is restored, libgit2's discovery works, but git-annex stops working with "git-annex: /tmp/inner: changeWorkingDirectory: does not exist (No such file or directory)" -- apparently, git-annex does use the workdir if it is set, but uses different resolution rules than git.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex 7.20191114 as packaged in Debian as 7.20191114-1.
+
+
+### Have you had any luck using git-annex before?
+
+Luck had nothing to do with it -- it's by its design that it usually works :-)
diff --git a/doc/bugs/creating_dot-git-as-symlink_workaround_drops_worktree_configuration_from_submodules/comment_1_ca12be107b7a7dc36cb71595e347ce28._comment b/doc/bugs/creating_dot-git-as-symlink_workaround_drops_worktree_configuration_from_submodules/comment_1_ca12be107b7a7dc36cb71595e347ce28._comment
new file mode 100644
index 0000000000..9b12b7aecb
--- /dev/null
+++ b/doc/bugs/creating_dot-git-as-symlink_workaround_drops_worktree_configuration_from_submodules/comment_1_ca12be107b7a7dc36cb71595e347ce28._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Workaround"
+ date="2019-12-22T10:50:32Z"
+ content="""
+As a workaround to keep both git submodule workdir discovery and git annex functional, the original git submodule core.worktree parameter can be restored, and overridden for git-annex calls using
+
+[[!format sh \"\"\"
+GIT_WORK_TREE=\"$PWD\" git annex whereis
+\"\"\"]]
+
+and similar.
+"""]]
diff --git a/doc/bugs/creating_dot-git-as-symlink_workaround_drops_worktree_configuration_from_submodules/comment_2_b7f03cbb85862ed294ecd0f8cbbd2086._comment b/doc/bugs/creating_dot-git-as-symlink_workaround_drops_worktree_configuration_from_submodules/comment_2_b7f03cbb85862ed294ecd0f8cbbd2086._comment
new file mode 100644
index 0000000000..24142a1d04
--- /dev/null
+++ b/doc/bugs/creating_dot-git-as-symlink_workaround_drops_worktree_configuration_from_submodules/comment_2_b7f03cbb85862ed294ecd0f8cbbd2086._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="update"
+ date="2020-09-17T14:57:52Z"
+ content="""
+There's been a slight change in the behavior since this was originally reported (or I missed that before): The worktree is still removed, but it shows a
+
+```
+warning: unable to convert submodule to form that will work with git-annex
+```
+
+when annex-init'ing the inner. Contrary to what it says, everything on git-annex's *does* appear to work fine in the `outer-with-annex/inner` -- only the libgit access there fails.
+"""]]
diff --git a/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error.mdwn b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error.mdwn
new file mode 100644
index 0000000000..957889e73e
--- /dev/null
+++ b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error.mdwn
@@ -0,0 +1,115 @@
+### Please describe the problem.
+
+It was a long journey... ;-)  First I had ran `git annex test` which resulted in `437 out of 834 tests failed` and saw bunch of those failures - [full log](http://www.onerussian.com/tmp/git-annex-test-log-8.20200502-g55acb2e52-2.log) ... Then I got to "troubleshoot" too long of pidlock detection [filed separately](https://git-annex.branchable.com/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/?updated), where a complete run of `annex get` finally crashed with
+
+[[!format sh """
+[2020-06-04 22:16:49.683393126] process done ExitSuccess
+git-annex: SQLite3 returned ErrorIO while attempting to perform prepare "PRAGMA journal_mode=WAL;": disk I/O error
+
+[yhalchen@discovery7 containers]$ echo $?
+1
+"""]]
+
+<details>
+<summary>A full log:</summary> 
+
+```shell
+*[yhalchen@discovery7 containers]$ git annex --debug get --from origin images/bids/bids-fmriprep--20.1.0.sing
+[2020-06-04 22:14:49.036738929] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2020-06-04 22:14:49.053892561] process done ExitSuccess
+[2020-06-04 22:14:49.054443458] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2020-06-04 22:14:49.066856316] process done ExitFailure 1
+[2020-06-04 22:14:49.06701345] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","origin/git-annex"]
+[2020-06-04 22:14:49.07703984] process done ExitFailure 1
+[2020-06-04 22:14:49.079889542] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2020-06-04 22:14:49.097069694] process done ExitSuccess
+[2020-06-04 22:14:49.097233049] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","4b825dc642cb6eb9a060e54bf8d69288fbee4904","--no-gpg-sign"]
+[2020-06-04 22:14:49.131741755] process done ExitSuccess
+[2020-06-04 22:14:49.131910038] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","8cab5728da95189f68c785bd4bb59ca754e133fd"]
+[2020-06-04 22:14:49.153852043] process done ExitSuccess
+[2020-06-04 22:14:49.159730902] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.uuid","fd97689f-716d-4e82-87ce-5b96c2421dd6"]
+[2020-06-04 22:14:49.175319685] process done ExitSuccess
+[2020-06-04 22:14:49.175479616] read: git ["config","--null","--list"]
+[2020-06-04 22:14:49.184803048] process done ExitSuccess
+
+  Detected a filesystem without POSIX fcntl lock support.
+
+  Enabling annex.pidlock.
+[2020-06-04 22:16:49.25775881] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.pidlock","true"]
+[2020-06-04 22:16:49.28355608] process done ExitSuccess
+[2020-06-04 22:16:49.283718998] read: git ["config","--null","--list"]
+[2020-06-04 22:16:49.294520291] process done ExitSuccess
+[2020-06-04 22:16:49.319943516] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2020-06-04 22:16:49.337681756] process done ExitSuccess
+[2020-06-04 22:16:49.337851772] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2020-06-04 22:16:49.350699481] process done ExitSuccess
+[2020-06-04 22:16:49.351471951] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..8cab5728da95189f68c785bd4bb59ca754e133fd","--pretty=%H","-n1"]
+[2020-06-04 22:16:49.364911775] process done ExitSuccess
+[2020-06-04 22:16:49.365042588] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..e3361f4b81727323f8ea01f390de1013fc970fe0","--pretty=%H","-n1"]
+[2020-06-04 22:16:49.382315188] process done ExitSuccess
+[2020-06-04 22:16:49.39123874] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2020-06-04 22:16:49.392177285] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+(merging origin/git-annex into git-annex...)
+[2020-06-04 22:16:49.403384458] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]
+[2020-06-04 22:16:49.404525057] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+[2020-06-04 22:16:49.405361559] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff-index","--raw","-z","-r","--no-renames","-l0","--cached","e3361f4b81727323f8ea01f390de1013fc970fe0","--"]
+[2020-06-04 22:16:49.419146962] process done ExitSuccess
+[2020-06-04 22:16:49.423309792] process done ExitSuccess
+[2020-06-04 22:16:49.424375953] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","e3361f4b81727323f8ea01f390de1013fc970fe0..refs/heads/git-annex","--pretty=%H","-n1"]
+[2020-06-04 22:16:49.437440657] process done ExitSuccess
+(recording state in git...)
+[2020-06-04 22:16:49.438388893] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2020-06-04 22:16:49.455648835] process done ExitSuccess
+[2020-06-04 22:16:49.455794606] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","1e2019e8261920b3331694be7582e576f48f98ce","--no-gpg-sign","-p","refs/heads/git-annex","-p","e3361f4b81727323f8ea01f390de1013fc970fe0"]
+[2020-06-04 22:16:49.474057462] process done ExitSuccess
+[2020-06-04 22:16:49.474203707] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","40ec653567414f60bb5a8fcecbf35e445329d19c"]
+[2020-06-04 22:16:49.496182398] process done ExitSuccess
+[2020-06-04 22:16:49.510323334] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.version","8"]
+[2020-06-04 22:16:49.52428458] process done ExitSuccess
+[2020-06-04 22:16:49.524446647] read: git ["config","--null","--list"]
+[2020-06-04 22:16:49.53479347] process done ExitSuccess
+[2020-06-04 22:16:49.534979055] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","status","--porcelain"]
+[2020-06-04 22:16:49.616544919] process done ExitSuccess
+[2020-06-04 22:16:49.616691354] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","filter.annex.smudge","git-annex smudge -- %f"]
+[2020-06-04 22:16:49.631712464] process done ExitSuccess
+[2020-06-04 22:16:49.631878376] read: git ["config","--null","--list"]
+[2020-06-04 22:16:49.642378001] process done ExitSuccess
+[2020-06-04 22:16:49.642543068] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","filter.annex.clean","git-annex smudge --clean -- %f"]
+[2020-06-04 22:16:49.656618605] process done ExitSuccess
+[2020-06-04 22:16:49.65676469] read: git ["config","--null","--list"]
+[2020-06-04 22:16:49.667352993] process done ExitSuccess
+(scanning for unlocked files...)
+[2020-06-04 22:16:49.671201261] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--head"]
+[2020-06-04 22:16:49.683393126] process done ExitSuccess
+git-annex: SQLite3 returned ErrorIO while attempting to perform prepare "PRAGMA journal_mode=WAL;": disk I/O error
+
+```
+</details>
+
+
+File system details:
+
+[[!format sh """
+[yhalchen@discovery7 containers]$ df -h .
+Filesystem                          Type  Size  Used Avail Use% Mounted on
+isilon.hpcc.dartmouth.edu:/ifs/home nfs    51G   23G   28G  45% /ihome
+
+[yhalchen@discovery7 containers]$ mount | grep /ifs/home
+isilon.hpcc.dartmouth.edu:/ifs/home on /ihome type nfs (rw,relatime,vers=3,rsize=131072,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.232.???.???,mountvers=3,mountport=300,mountproto=udp,local_lock=none,addr=10.232.???.???)
+"""]]
+
+
+[[!format sh """
+git-annex version: 8.20200502-g55acb2e52
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+
+"""]]
+
+I think I should look at some point to establish similar setup within https://github.com/datalad/datalad-extensions to run released and freshly built annex tests also on a crippled FS.
diff --git a/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_1_aaea812a8f2b04d9b17d1ba9c6fad39f._comment b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_1_aaea812a8f2b04d9b17d1ba9c6fad39f._comment
new file mode 100644
index 0000000000..788fd2f2f1
--- /dev/null
+++ b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_1_aaea812a8f2b04d9b17d1ba9c6fad39f._comment
@@ -0,0 +1,60 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-11T18:13:05Z"
+ content="""
+This is sqlite failing to do its own internal locking which I'll bet is
+some elaborate and fine-grained locking indeed.
+
+Essentially the same problem as
+<https://git-annex.branchable.com/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO/>
+(And also the main problem using git-annex on Windows in WSL.)
+
+Not a great deal I can do about this, because the locking is in sqlite.
+That other bug has some thoughts about avoiding unnecessary use of sqlite
+or moving the databases to some other filesystem.
+
+It may be that not enabling WAL mode on the database would change sqlite's
+locking behavior to something that works better on the filesystem.
+I would normally not want to do that, but with pidlock enabled, only one
+git-annex is going to be running anyway, and so there's no need for WAL
+mode's concurrency support.
+
+Here's a patch to test. I would not use this in production, since it does
+not check for pidlock, but just always disables WAL.
+
+	diff --git a/Database/Handle.hs b/Database/Handle.hs
+	index 4422d9e75..790833d72 100644
+	--- a/Database/Handle.hs
+	+++ b/Database/Handle.hs
+	@@ -34,6 +34,7 @@ import qualified Data.Text as T
+	 import Control.Monad.Trans.Resource (runResourceT)
+	 import Control.Monad.Logger (runNoLoggingT)
+	 import System.IO
+	+import Lens.Micro
+	 
+	 {- A DbHandle is a reference to a worker thread that communicates with
+	  - the database. It has a MVar which Jobs are submitted to. -}
+	@@ -196,8 +197,9 @@ runSqliteRobustly tablename db a = do
+ 	rethrow msg e = throwIO $ userError $ show e ++ "(" ++ msg ++ ")"
+ 	
+	 	go conn retries = do
+	+		let i = over walEnabled (const False) (mkSqliteConnectionInfo db)
+	 		r <- try $ runResourceT $ runNoLoggingT $
+	-			withSqlConnRobustly (wrapConnection conn) $
+	+			withSqlConnRobustly (wrapConnectionInfo i conn) $
+	 				runSqlConn a
+	 		case r of
+	 			Right v -> return v
+	diff --git a/Database/Init.hs b/Database/Init.hs
+	index c66fe43ac..0c8478c7d 100644
+	--- a/Database/Init.hs
+	+++ b/Database/Init.hs
+	@@ -52,5 +52,5 @@ initDb db migration = do
+	  - Note that once WAL mode is enabled, it will persist whenever the
+	  - database is opened. -}
+	 enableWAL :: T.Text -> SqliteConnectionInfo
+	-enableWAL db = over walEnabled (const True) $ 
+	+enableWAL db = over walEnabled (const False) $ 
+	 	mkSqliteConnectionInfo db
+"""]]
diff --git a/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_2_c55f2d95f7f08e6f6439f36790e5a538._comment b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_2_c55f2d95f7f08e6f6439f36790e5a538._comment
new file mode 100644
index 0000000000..cf6b6f8895
--- /dev/null
+++ b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_2_c55f2d95f7f08e6f6439f36790e5a538._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-06-11T19:26:05Z"
+ content="""
+This does seem to be an unnecessary use of the database,
+git-annex init always creates the db in scanUnlockedFiles
+when the repo has a HEAD ref, but normally it will find no unlocked files
+and so it could just not create the database there.
+
+That should make git-annex usable, until a situation where it does
+need to use the database, like something to do with an unlocked file.
+
+Implemented that, which will fix the immediate problem reported here,
+but I'd like to pursue the WAL stuff still.
+"""]]
diff --git a/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_3_b49a3df3b13f564e588824910a07bc43._comment b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_3_b49a3df3b13f564e588824910a07bc43._comment
new file mode 100644
index 0000000000..6fe68ca662
--- /dev/null
+++ b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_3_b49a3df3b13f564e588824910a07bc43._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="hdclark@be373988ada6dc692f87a8eefdd600432e54f7d4"
+ nickname="hdclark"
+ avatar="http://cdn.libravatar.org/avatar/55f92a50f2617099e2dc7509130ce158"
+ subject="This occurs on 9P filesystem too"
+ date="2020-08-07T20:41:06Z"
+ content="""
+Just thought I would chime in that I experienced sqlite errors for about 2 months before realizing it was due to 9P filesystem + virtio in a Qemu VM. Prior to (roughly) 2 months back I did not encounter this error, but it now appears in all recent versions of git-annex (Arch Linux package, most recent standalone version, and git build).
+
+Is there any way to alter the sqlite config (e.g., through .git/config or a dotfile) to workaround the issue? It renders my current setup, in which several VMs share the same hardware but have exclusive access to storage devices, completely inoperable.
+"""]]
diff --git a/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_4_a9e6e37dbaa1664d825bdbd64de4fbdd._comment b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_4_a9e6e37dbaa1664d825bdbd64de4fbdd._comment
new file mode 100644
index 0000000000..12ab1e45a2
--- /dev/null
+++ b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_4_a9e6e37dbaa1664d825bdbd64de4fbdd._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-08-10T16:41:23Z"
+ content="""
+@hdclark it would be worth trying to disable WAL mode for the sqlite
+database and see if that fixes the problem. The patch I posted earlier
+can do it.
+"""]]
diff --git a/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_5_3a5eaa2492e4c62a15b4fcee7f96d9dd._comment b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_5_3a5eaa2492e4c62a15b4fcee7f96d9dd._comment
new file mode 100644
index 0000000000..4c5168cd46
--- /dev/null
+++ b/doc/bugs/crippled_fs___40__pidlock__41___leads_to_git-annex__58___SQLite3_error/comment_5_3a5eaa2492e4c62a15b4fcee7f96d9dd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-08-12T17:24:16Z"
+ content="""
+It's now possible to set annex.dbdir to a directory on some other
+filesystem than one containing the repository, where sqlite works better.
+"""]]
diff --git a/doc/bugs/cygwin.mdwn b/doc/bugs/cygwin.mdwn
new file mode 100644
index 0000000000..4d0bf07a62
--- /dev/null
+++ b/doc/bugs/cygwin.mdwn
@@ -0,0 +1,406 @@
+Cygwin do not work with git-annex windows installed version
+
+
+### What steps will reproduce the problem?
+* Install git-annex windows version
+* Try run git annex test under cygwin, and got 65 test failed out of 101.
+* Try run git annex test under git bash windows and got 101 test passed.
+* NOTE: git-lfs windows installed version working fine under cygwin and git bash windows.
+
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 7.20191106-ge486fd5e0
+build flags: Assistant Webapp Pairing S3 WebDAV TorrentParser Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: mingw32 x86_64
+supported repository versions: 7
+upgrade supported from repository versions: 2 3 4 5 6
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+Cygwin ~/git..t_tools/wget/cache (test)
+(506)$ git-annex test
+Tests
+  QuickCheck
+    prop_encode_decode_roundtrip:                         OK (0.04s)
+      +++ OK, passed 1000 tests.
+    prop_encode_c_decode_c_roundtrip:                     OK (0.03s)
+      +++ OK, passed 1000 tests.
+    prop_isomorphic_key_encode:                           OK
+      +++ OK, passed 1000 tests.
+    prop_isomorphic_shellEscape:                          OK (0.02s)
+      +++ OK, passed 1000 tests.
+    prop_isomorphic_shellEscape_multiword:                OK (0.70s)
+      +++ OK, passed 1000 tests.
+    prop_isomorphic_configEscape:                         OK (0.02s)
+      +++ OK, passed 1000 tests.
+    prop_parse_show_Config:                               OK (0.04s)
+      +++ OK, passed 1000 tests.
+    prop_upFrom_basics:                                   OK (0.02s)
+      +++ OK, passed 1000 tests.
+    prop_relPathDirToFile_basics:                         OK (0.03s)
+      +++ OK, passed 1000 tests.
+    prop_relPathDirToFile_regressionTest:                 OK
+      +++ OK, passed 1 test.
+    prop_cost_sane:                                       OK
+      +++ OK, passed 1 test.
+    prop_matcher_sane:                                    OK
+      +++ OK, passed 1 test.
+    prop_HmacSha1WithCipher_sane:                         OK
+      +++ OK, passed 1 test.
+    prop_VectorClock_sane:                                OK
+      +++ OK, passed 1 test.
+    prop_addMapLog_sane:                                  OK
+      +++ OK, passed 1 test.
+    prop_verifiable_sane:                                 OK (0.07s)
+      +++ OK, passed 1000 tests.
+    prop_segment_regressionTest:                          OK
+      +++ OK, passed 1 test.
+    prop_read_write_transferinfo:                         OK (0.04s)
+      +++ OK, passed 1000 tests.
+    prop_read_show_inodecache:                            OK (0.02s)
+      +++ OK, passed 1000 tests.
+    prop_parse_build_presence_log:                        OK (1.27s)
+      +++ OK, passed 1000 tests.
+    prop_parse_build_contentidentifier_log:               OK (1.23s)
+      +++ OK, passed 1000 tests.
+    prop_read_show_TrustLevel:                            OK
+      +++ OK, passed 1 test.
+    prop_parse_build_TrustLevelLog:                       OK
+      +++ OK, passed 1 test.
+    prop_hashes_stable:                                   OK
+      +++ OK, passed 1 test.
+    prop_mac_stable:                                      OK
+      +++ OK, passed 1 test.
+    prop_schedule_roundtrips:                             OK (0.01s)
+      +++ OK, passed 1000 tests.
+    prop_past_sane:                                       OK
+      +++ OK, passed 1 test.
+    prop_duration_roundtrips:                             OK
+      +++ OK, passed 1000 tests.
+    prop_metadata_sane:                                   OK (0.86s)
+      +++ OK, passed 1000 tests.
+    prop_metadata_serialize:                              OK (0.84s)
+      +++ OK, passed 1000 tests.
+    prop_branchView_legal:                                OK (0.77s)
+      +++ OK, passed 1000 tests.
+    prop_viewPath_roundtrips:                             OK (0.03s)
+      +++ OK, passed 1000 tests.
+    prop_view_roundtrips:                                 OK (0.52s)
+      +++ OK, passed 1000 tests.
+    prop_viewedFile_rountrips:                            OK (0.02s)
+      +++ OK, passed 1000 tests.
+    prop_b64_roundtrips:                                  OK
+      +++ OK, passed 1000 tests.
+    prop_standardGroups_parse:                            OK
+      +++ OK, passed 1 test.
+  Unit Tests v7 adjusted unlocked branch
+    add dup:                                              Init Tests
+  init: init test repo
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Disabling core.symlinks.
+(scanning for unlocked files...)
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+ not found .
+git-annex.exe: pre-commit: 1 failed
+
+  Failed to enter adjusted branch!
+ok
+(recording state in git...)
+ not found .
+git-annex.exe: pre-commit: 1 failed
+FAIL (6.92s)
+    .\\Test\\Framework.hs:469:
+    git commit failed
+  add:  add foo
+ok
+(recording state in git...)
+add sha1foo
+ok
+(recording state in git...)
+ not found .
+git-annex.exe: pre-commit: 1 failed
+FAIL (8.10s)
+    Test.hs:303:
+    git commit failed
+
+2 out of 2 tests failed (15.02s)
+FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    add extras:                                           FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    export_import:                                        FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    export_import_subdir:                                 FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    shared clone:                                         FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    log:                                                  FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    import:                                               FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    reinject:                                             FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    unannex (no copy):                                    FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    unannex (with copy):                                  FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    drop (no remote):                                     FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    drop (with remote):                                   FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    drop (untrusted remote):                              FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    get:                                                  FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    get (ssh remote):                                     FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    move:                                                 FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    move (ssh remote):                                    FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    copy:                                                 FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    lock:                                                 FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    lock --force:                                         FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    edit (no pre-commit):                                 FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    edit (pre-commit):                                    FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    partial commit:                                       FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    fix:                                                  FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    trust:                                                FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    fsck (basics):                                        FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    fsck (bare):                                          FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    fsck (local untrusted):                               FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    fsck (remote untrusted):                              FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    fsck --from remote:                                   FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    migrate:                                              FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    migrate (via gitattributes):                          FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    unused:                                               FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    describe:                                             FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    find:                                                 FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    merge:                                                FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    info:                                                 FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    version:                                              FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    sync:                                                 FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    union merge regression:                               FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    adjusted branch merge regression:                     FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    adjusted branch subtree regression:                   FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    conflict resolution:                                  FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    conflict resolution (adjusted branch):                FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    conflict resolution movein regression:                FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    conflict resolution (mixed directory and file):       FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    conflict resolution symlink bit:                      FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    conflict resolution (uncommitted local file):         FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    conflict resolution (removed file):                   FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    conflict resolution (nonannexed file):                FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    conflict resolution (nonannexed symlink):             FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    conflict resolution (mixed locked and unlocked file): FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    map:                                                  FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    uninit:                                               FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    uninit (in git-annex branch):                         FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    upgrade:                                              FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    whereis:                                              FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    hook remote:                                          FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    directory remote:                                     FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    rsync remote:                                         FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    bup remote:                                           FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    crypto:                                               FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    preferred content:                                    FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    add subdirs:                                          FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+    addurl:                                               FAIL
+      Exception: init tests failed! cannot continue
+      CallStack (from HasCallStack):
+        error, called at .\\Test\\Framework.hs:427:33 in main:Test.Framework
+
+65 out of 101 tests failed (21.64s)
+  (Failures above could be due to a bug in git-annex, or an incompatibility
+   with utilities, such as git, installed on this system.)
+# End of transcript or log.
+"""]]
+
+
diff --git a/doc/bugs/cygwin/comment_1_88b6c7d1f50d0f17443ee74b5886649c._comment b/doc/bugs/cygwin/comment_1_88b6c7d1f50d0f17443ee74b5886649c._comment
new file mode 100644
index 0000000000..70c4e3f67f
--- /dev/null
+++ b/doc/bugs/cygwin/comment_1_88b6c7d1f50d0f17443ee74b5886649c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-10-19T16:54:15Z"
+ content="""
+> not found .
+> git-annex.exe: pre-commit: 1 failed
+
+I guess whatever this is, running `git annex pre-commit`
+would probably reproduce it, and then you could add the --debug flag and it
+would show what program it's trying to run when this happens.
+
+I don't know why it would not display the name of a program it's tried to
+run. But I guess it's probably a program, since that seems to be the most
+likely thing that would be broken by running git-annex in this unusual way.
+"""]]
diff --git a/doc/bugs/dead_with_no_params_can_mark_repo_with_empty_description_dead.mdwn b/doc/bugs/dead_with_no_params_can_mark_repo_with_empty_description_dead.mdwn
new file mode 100644
index 0000000000..d84b000453
--- /dev/null
+++ b/doc/bugs/dead_with_no_params_can_mark_repo_with_empty_description_dead.mdwn
@@ -0,0 +1,13 @@
+	joey@darkstar:~/tmp/xxxx>git annex describe here ""
+	describe here ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/xxxx>git-annex dead
+	dead  ok
+	(recording state in git...)
+
+I would be ok with `git-annex dead ""` doing that, perhaps, but when
+no parameters are given, it constructs the empty string itself, which is a bug.
+
+Found this in <https://bugs.debian.org/855648> --[[Joey]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/describe_what_git-annex_actually_is.mdwn b/doc/bugs/describe_what_git-annex_actually_is.mdwn
new file mode 100644
index 0000000000..feee65a0e5
--- /dev/null
+++ b/doc/bugs/describe_what_git-annex_actually_is.mdwn
@@ -0,0 +1,14 @@
+The homepage lists lots of things, but does not succinctly specify the core of git-annex.
+It took me multiple sifts through the pages and a failed attempt at setting it up to discover that, and how it does not do what I currently need.
+
+> git-annex allows managing files with git, without checking the file contents into git.
+> While that may seem paradoxical, it is useful when dealing with files larger than git can currently easily handle, whether due to limitations in memory, time, or disk space.
+
+The second sentence does not really help to explain the tool, for me it sounds a lot like git-lfs. My suggestion:
+
+> git-annex is a sparse file management tool that tracks files separately from their contents.
+> It enables managing files larger than git can easily handle, whether due to limitations in memory, time, or disk space.
+
+Still not optimal, but feels a little more precise
+
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/describe_what_git-annex_actually_is/comment_1_25fc9ffb24fc4c96b81a6393427bbe95._comment b/doc/bugs/describe_what_git-annex_actually_is/comment_1_25fc9ffb24fc4c96b81a6393427bbe95._comment
new file mode 100644
index 0000000000..ac81ed6be3
--- /dev/null
+++ b/doc/bugs/describe_what_git-annex_actually_is/comment_1_25fc9ffb24fc4c96b81a6393427bbe95._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-11-08T19:38:35Z"
+ content="""
+Describing what `git-annex` does is pretty hard. So when I talk about it, I usually say what you can do with it: manage, sync, backup and archive your data, offline and online, with everything checksummed.
+"""]]
diff --git a/doc/bugs/describe_what_git-annex_actually_is/comment_2_1f6ec7cedf56863b261bad0e3f3c80de._comment b/doc/bugs/describe_what_git-annex_actually_is/comment_2_1f6ec7cedf56863b261bad0e3f3c80de._comment
new file mode 100644
index 0000000000..70272d5e84
--- /dev/null
+++ b/doc/bugs/describe_what_git-annex_actually_is/comment_2_1f6ec7cedf56863b261bad0e3f3c80de._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-01-06T16:23:15Z"
+ content="""
+Thanks, these are good suggestions. I've made some improvements to the
+description.
+"""]]
diff --git a/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable.mdwn b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable.mdwn
new file mode 100644
index 0000000000..74cd6aa6ac
--- /dev/null
+++ b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable.mdwn
@@ -0,0 +1,70 @@
+### Please describe the problem.
+
+git takes "Boolean true literals are yes, on, true, and 1."
+
+IMHO git-annex should centrally/uniformly handle all boolean values for all configuration and remote settings.
+
+majority of the boolean variable settings e.g. for special remotes in examples etc use `yes`.  But examples with `autoenable` seems to use `true` and having `yes` causes git-annex to not autoenable it:
+
+```shell
+$> (set -x ; ds=ds002396; rm -rf $ds; git clone https://github.com/OpenNeuroDatasets/$ds.git && git -C $ds show origin/git-annex:remote.log && git -C $ds annex init && git -C $ds annex info | grep -i s3-public )
++zsh:194> ds=ds002396 
++zsh:194> rm -rf ds002396
++zsh:194> git clone https://github.com/OpenNeuroDatasets/ds002396.git
+Cloning into 'ds002396'...
+remote: Enumerating objects: 93, done.
+remote: Counting objects: 100% (93/93), done.
+remote: Compressing objects: 100% (56/56), done.
+remote: Total 93 (delta 19), reused 93 (delta 19), pack-reused 0
+Receiving objects: 100% (93/93), 9.30 KiB | 414.00 KiB/s, done.
+Resolving deltas: 100% (19/19), done.
++zsh:194> git -C ds002396 show origin/git-annex:remote.log
+6b554bb8-47cc-4f88-b3f0-b4becdb80272 autoenable=yes bucket=openneuro.org datacenter=US encryption=none exporttree=yes fileprefix=ds002396/ host=s3.amazonaws.com name=s3-PUBLIC partsize=1GiB port=80 public=yes publicurl=http://openneuro.org.s3.amazonaws.com/ storageclass=STANDARD type=S3 versioning=yes timestamp=1579150706.611377263s
++zsh:194> git -C ds002396 annex init
+init  (merging origin/git-annex into git-annex...)
+(recording state in git...)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+ok
+(recording state in git...)
++zsh:194> git -C ds002396 annex info
++zsh:194> grep '--color=auto' -d skip -i s3-public
+ 	6b554bb8-47cc-4f88-b3f0-b4becdb80272 -- s3-PUBLIC
+```
+
+<details>
+<summary>whenever it autoenables if I explicitly replace yes with true here:</summary> 
+
+```shell
+$> ds=ds002396; rm -rf $ds*; ( git clone https://github.com/OpenNeuroDatasets/$ds.git && cd $ds && git checkout git-annex && sed -i -e 's,autoenable=yes,autoenable=true,g' remote.log && git commit -m "fix yes to true" -a && git checkout master; ) && git clone $ds $ds-clone && git -C $ds-clone annex init
+Cloning into 'ds002396'...
+remote: Enumerating objects: 93, done.
+remote: Counting objects: 100% (93/93), done.
+remote: Compressing objects: 100% (56/56), done.
+remote: Total 93 (delta 19), reused 93 (delta 19), pack-reused 0
+Receiving objects: 100% (93/93), 9.30 KiB | 4.65 MiB/s, done.
+Resolving deltas: 100% (19/19), done.
+CHANGES  dataset_description.json  sub-01/  sub-02/
+Branch 'git-annex' set up to track remote branch 'git-annex' from 'origin'.
+Switched to a new branch 'git-annex'
+[git-annex 3770aed] fix yes to true
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+Switched to branch 'master'
+Your branch is up to date with 'origin/master'.
+Cloning into 'ds002396-clone'...
+done.
+init  (merging origin/git-annex into git-annex...)
+(recording state in git...)
+(Auto enabling special remote s3-PUBLIC...)
+ok
+(recording state in git...)
+
+```
+</details>
+
+FWIW -- above examples are with git annex 7.20190819+git2-g908476a9b-1~ndall+1 but initially investigated using 8.20200330+git28-g7ebc11877-1~ndall+1
+
+References: [initial report on neurostars](https://neurostars.org/t/datalad-install-problem-ds002393/6544/3)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
diff --git a/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_1_2f13e023228fa4938dd314e040a8ec10._comment b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_1_2f13e023228fa4938dd314e040a8ec10._comment
new file mode 100644
index 0000000000..141897d5b9
--- /dev/null
+++ b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_1_2f13e023228fa4938dd314e040a8ec10._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 1"
+ date="2020-04-07T15:30:54Z"
+ content="""
+As of 7.20200202.7, initremote and enableremote will refuse to accept
+unknown values:
+
+```
+$ git annex initremote d type=directory directory=/$PWD../dir/ autoenable=yes encryption=none
+initremote d                                         
+git-annex: Bad value for autoenable (expected true or false)
+failed
+git-annex: initremote: 1 failed
+```
+
+Here's your [todo][0] related to those changes.
+
+Rejecting invalid values isn't the more liberal casting of boolean
+values that you're asking for here, but the above behavior would stop
+an initremote caller from misconfiguring the remote, preventing cases
+like the report you link to.
+
+Assuming that taking multiple values for a boolean is a good thing in
+general, it seems like it'd be problematic to switch special remote
+parameters over to this behavior.  The stored config is used when
+enabling it in other repos, so an older version of git-annex would
+see, say, autoenable=yes and not treat it as autoenable=true.  To
+avoid that, I suppose git-annex could map the value onto the currently
+accepted form when storing the config, but I'd guess at that point
+support for multiple ways to say true isn't really worth the
+trade-off.
+
+[0]: https://git-annex.branchable.com/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/
+
+"""]]
diff --git a/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_2_01985a25dbdcfe487e28aaeb5823fded._comment b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_2_01985a25dbdcfe487e28aaeb5823fded._comment
new file mode 100644
index 0000000000..570fb588d3
--- /dev/null
+++ b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_2_01985a25dbdcfe487e28aaeb5823fded._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-04-07T17:28:52Z"
+ content="""
+Yes, true, git-annex has some inconsistent parsing of these.
+
+It's certianly at least a bug worth fixing that the Git.Config parser only
+supports "true" and not "1" and "on". (And IIRC git-config also has a
+special case for true boolean settings that has only the setting in the
+config file, without a value -- which git-annex also may not parse.)
+
+On special remotes, Kyle's right. Same reasoning also applies to 
+booleans set by git-annex config. I don't immediately see any good way to
+add a translation layer to either when things are set, it would be an ugly
+addition in both cases.
+
+I don't feel git-annex necessarily needs to mimic git here in accepting
+all those things. It's well known that not all of git's UI choices are good,
+and git-annex does not mimic all of them, eg git has some very nasty
+positional --switch parsing.
+
+But readonly and autoenable using true/false while all other special remote
+configs uses yes/no is not good UI either.
+"""]]
diff --git a/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_3_136e937bdeda3dec080b49d4755d1fba._comment b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_3_136e937bdeda3dec080b49d4755d1fba._comment
new file mode 100644
index 0000000000..ae9c79b4f3
--- /dev/null
+++ b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_3_136e937bdeda3dec080b49d4755d1fba._comment
@@ -0,0 +1,90 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2020-04-07T18:25:46Z"
+ content="""
+> I don't feel git-annex necessarily needs to mimic git here in accepting all those things. It's well known that not all of git's UI choices are good, and git-annex does not mimic all of them, eg git has some very nasty positional --switch parsing.
+
+I would not over-generalize this issue to all possible `git` UI bad decisions... Talking about configuration boolean options, given the:
+
+> But readonly and autoenable using true/false while all other special remote configs uses yes/no is not good UI either.
+
+IMHO staying inline with git would bring desired consistent (even if undesired flexibility, which I do not like either) handling.  
+
+FWIW, in DataLad, in reading the bool config values [we have](https://github.com/datalad/datalad/blob/master/datalad/config.py#L120)
+
+```python
+ def anything2bool(val):
+    if hasattr(val, 'lower'):
+        val = val.lower()
+    if val in {\"off\", \"no\", \"false\", \"0\"} or not bool(val):
+        return False
+    elif val in {\"on\", \"yes\", \"true\", True} \
+            or (hasattr(val, 'isdigit') and val.isdigit() and int(val)) \
+            or isinstance(val, int) and val:
+        return True
+    else:
+        raise TypeError(
+            \"Got value %s which could not be interpreted as a boolean\"
+            % repr(val))
+```
+so for better or for worse, any non-0 positive integer is considered `True` as well... it seems we are ALMOST inline with git:
+
+```shell
+$> for v in true yes 1 200 '' false no 0 -1 0.00 0.1 string; do echo -n \"$v=\"; git -c \"sec.blah=$v\" config --bool sec.blah; python -c \"from datalad.config import anything2bool; print(anything2bool('$v'))\"; echo; done
+true=true
+True
+
+yes=true
+True
+
+1=true
+True
+
+200=true
+True
+
+=false
+False
+
+false=false
+False
+
+no=false
+False
+
+0=false
+False
+
+-1=true
+Traceback (most recent call last):
+  File \"<string>\", line 1, in <module>
+  File \"/home/yoh/proj/datalad/datalad-maint/datalad/config.py\", line 132, in anything2bool
+    % repr(val))
+TypeError: Got value '-1' which could not be interpreted as a boolean
+
+0.00=fatal: bad numeric config value '0.00' for 'sec.blah': invalid unit
+Traceback (most recent call last):
+  File \"<string>\", line 1, in <module>
+  File \"/home/yoh/proj/datalad/datalad-maint/datalad/config.py\", line 132, in anything2bool
+    % repr(val))
+TypeError: Got value '0.00' which could not be interpreted as a boolean
+
+0.1=fatal: bad numeric config value '0.1' for 'sec.blah': invalid unit
+Traceback (most recent call last):
+  File \"<string>\", line 1, in <module>
+  File \"/home/yoh/proj/datalad/datalad-maint/datalad/config.py\", line 132, in anything2bool
+    % repr(val))
+TypeError: Got value '0.1' which could not be interpreted as a boolean
+
+string=fatal: bad numeric config value 'string' for 'sec.blah': invalid unit
+Traceback (most recent call last):
+  File \"<string>\", line 1, in <module>
+  File \"/home/yoh/proj/datalad/datalad-maint/datalad/config.py\", line 132, in anything2bool
+    % repr(val))
+TypeError: Got value 'string' which could not be interpreted as a boolean
+
+```
+so only the negative integer is tolerated by git but not by us.  I will send a quick PR
+"""]]
diff --git a/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_4_aa4ae6db181b1261a36ad06f223ec28f._comment b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_4_aa4ae6db181b1261a36ad06f223ec28f._comment
new file mode 100644
index 0000000000..9ba58b74f1
--- /dev/null
+++ b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_4_aa4ae6db181b1261a36ad06f223ec28f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-04-07T18:48:18Z"
+ content="""
+Surely values that git does not even document can be considered to have
+undefined behavior.
+"""]]
diff --git a/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_5_ea204e2190c5a34cfcb3dc0e0710a4e3._comment b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_5_ea204e2190c5a34cfcb3dc0e0710a4e3._comment
new file mode 100644
index 0000000000..49b7fa9bb3
--- /dev/null
+++ b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_5_ea204e2190c5a34cfcb3dc0e0710a4e3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2020-04-08T01:08:10Z"
+ content="""
+> Surely values that git does not even document can be considered to have undefined behavior.
+
+yeah. integers which aren't 0 or 1 are indeed a dark (undocumented) zone. Might be worth contributing to git and making them documented (probably better to not change behavior at this point).
+"""]]
diff --git a/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_6_2f998fab7d88a9ade53354d1820248ea._comment b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_6_2f998fab7d88a9ade53354d1820248ea._comment
new file mode 100644
index 0000000000..6cedc6591f
--- /dev/null
+++ b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_6_2f998fab7d88a9ade53354d1820248ea._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-04-13T17:45:51Z"
+ content="""
+I've made the git-config parser support all the ways of indicating true and
+false that git documents, including the strange distinction between an empty
+config setting (false) and no config setting (true). I'm not going to
+chase undocumented git behavior that could vary between versions of git.
+
+That also made it support values like "on" that are set by
+git-annex config --set. It was always possible to set such things.
+Older git-annex will display an error message if used with a repo
+that has such values set. That seems acceptable.
+
+I have not done anything about making special remote configs consistent.
+"""]]
diff --git a/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_7_bfbc9a9fbae3715fea0f4a11549ec8a9._comment b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_7_bfbc9a9fbae3715fea0f4a11549ec8a9._comment
new file mode 100644
index 0000000000..a7f951b7b7
--- /dev/null
+++ b/doc/bugs/does_not_understand___34__yes__34___as_boolean_true_value_for_autoenable/comment_7_bfbc9a9fbae3715fea0f4a11549ec8a9._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2020-04-23T16:39:16Z"
+ content="""
+Looking closer at the affected special remote configs:
+
+* readonly=true is only used by external special remotes. It used to be
+  stored in the remote.log, but after examining it, I have changed that.
+
+  So, it could be safely changed to also accept readonly=yes with no
+  back-compat issues.
+
+* When git-annex init is run, any autoenable= that is stored never results
+  in an error no matter what the value is; if it doesn't recognise it, it
+  assumes false. (And more generally, no value already stored in remote.log
+  causes a parse error, even if it cannot be parsed.) So autoenable=yes
+  would only result in older git-annex init not enabling the remote. Which
+  I guess is not a hard problem for a user to recover from, the remote
+  clearly won't be enabled when they try to use it. Two arguments in favor
+  of not worrying about backwards compatability for autoenable=yes:
+  
+  1. When autoenable=true was added originally, we obviously didn't worry
+     that older git-annex's would ignore that config and not autoenable.
+  
+  2. If the user does anything other than git-annex init, autoenabling
+     doesn't happen currently, which seems like rather more foot shooting
+     potential for ending up w/o a remote autoenabled, but I'm not seeing
+     much complaint about that. Though IIRC there might be a todo about it.
+
+So I'm leaning a bit toward it would be ok to accept yes/no as well as
+true/false for those two, without worrying about translation to values old
+git-annex will understand.
+
+But.. Allowing yes/no for these two while still also allowing true/false
+does not remove the special case, it just buries it a bit. All the other
+initremote booleans are yes/no and not true/false. And changing them
+*would* need a translation layer. I don't feel that bit of uniformity is
+worth that added complexity.
+"""]]
diff --git a/doc/bugs/done.mdwn b/doc/bugs/done.mdwn
new file mode 100644
index 0000000000..fc4e6abaa9
--- /dev/null
+++ b/doc/bugs/done.mdwn
@@ -0,0 +1,4 @@
+recently fixed [[bugs]]
+
+[[!inline pages="(./* or tagged(forum/forumbug)) and link(./done) and !*/Discussion" sort=mtime show=0
+archive=yes feedlimit=10]]
diff --git a/doc/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO.mdwn b/doc/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO.mdwn
new file mode 100644
index 0000000000..36f7fc7aaa
--- /dev/null
+++ b/doc/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO.mdwn
@@ -0,0 +1,52 @@
+[[!format sh """
+$> git clone http://data.pymvpa.org/datasets/tutorial_data/.git tutorial_data-2
+Cloning into 'tutorial_data-2'...
+Checking connectivity... done.
+cd 
+#35 !280 [0].....................................:Thu Jul 14 10:16:49:.
+anthill:/home/ironfs/scratch/yarik
+$> cd tutorial_data-2
+total 36
+ 4 freesurfer/   4 hyperalignment_tutorial_data.hdf5.gz@  20 suma_surfaces/
+ 4 haxby2001/    4 results/
+(git)/home/ironfs/scratch/yarik/tutorial_data-2:[master]
+#36 !281 [0].....................................:Thu Jul 14 10:16:50:.
+anthill:/home/ironfs/scratch/yarik/tutorial_data-2
+$> git annex get hyperalignment_tutorial_data.hdf5.gz 
+
+  Detected a filesystem without POSIX fcntl lock support.
+
+  Enabling annex.pidlock.
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+/home/ironfs/scratch 100%[===================>]  15.04M  68.9MB/s    in 0.2s    
+(checksum...) ok
+(recording state in git...)
+(git)/home/ironfs/scratch/yarik/tutorial_data-2:[master]
+#37 !282 [0].....................................:Thu Jul 14 10:16:54:.
+anthill:/home/ironfs/scratch/yarik/tutorial_data-2
+$> git annex drop hyperalignment_tutorial_data.hdf5.gz
+drop hyperalignment_tutorial_data.hdf5.gz (checking origin...) git-annex: SQLite3 returned ErrorIO while attempting to perform prepare "PRAGMA journal_mode=WAL;": disk I/O error
+(git)/home/ironfs/scratch/yarik/tutorial_data-2:[master]
+
+$> git annex fsck
+fsck freesurfer/anat_nii.nii sqlite worker thread crashed: SQLite3 returned ErrorIO while attempting to perform prepare "SELECT null from content limit 1": disk I/O error
+git-annex: sqlite query crashed
+
+$> git annex version
+git-annex version: 6.20160613-g35dbe35
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux x86_64
+(git)/home/ironfs/scratch/yarik/tutorial_data:[master]
+
+"""]]
+
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
diff --git a/doc/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO/comment_1_49e8920ad09ae71874686f50f566b77c._comment b/doc/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO/comment_1_49e8920ad09ae71874686f50f566b77c._comment
new file mode 100644
index 0000000000..a9734a4f5d
--- /dev/null
+++ b/doc/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO/comment_1_49e8920ad09ae71874686f50f566b77c._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-19T15:38:21Z"
+ content="""
+The v6 changes added a sqlite database. Some code will try to query or
+write that database even in v5 mode, although it's meant to give up if the
+database is not available.
+
+So, the easy fix, at least for the drop problem, is to avoid using the keys
+database at all in v5 mode. I've made this change and it will probably fix
+the case you reported.
+
+But, that won't help with v6 repos which need to use that sqlite database.
+And, incremental fsck uses its own sqlite database too. And,
+[[design/caching_database]] plans are to use sqlite databases more broadly
+in the future.
+
+I'm sure that it's not a good idea for git-annex to catch "disk IO error"
+exceptions from the database layer. So, it seems that most any other fix than
+avoiding using the database would need to be made in sqlite or in lustre,
+which it seems don't get along. At a guess, sqlite is trying to use some
+POSIX filesystem functionality, likely related to locking, that lustre does
+not support.
+
+Hmm, what could be done to hack in support for lustre is to 
+move the sqlite databases to a different filesystem. But, accessing the
+same repo from different hosts which have different sqlite databases would
+lead to inconsistent and buggy behavior. And repo setup would need to
+decide where to put the sqlite databases and manually configure that
+location. So this would be very much a caveat empror configuration.
+"""]]
diff --git a/doc/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO/comment_2_5f5de9dc70bf61c8a369841b24a5ec2a._comment b/doc/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO/comment_2_5f5de9dc70bf61c8a369841b24a5ec2a._comment
new file mode 100644
index 0000000000..670b2a18f1
--- /dev/null
+++ b/doc/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO/comment_2_5f5de9dc70bf61c8a369841b24a5ec2a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-08-12T17:27:25Z"
+ content="""
+It's now possible to set annex.dbdir to a directory on some other
+filesystem than one containing the repository, where sqlite works better.
+
+Unsure yet if it would be safe to set annex.dbdir to a local directory,
+and have the git-annex repository on a networked filesystem that is
+accessed from multiple clients. Each client will have its own set of sqlite
+databases, and will maintain them as best it can.
+"""]]
diff --git a/doc/bugs/drop_from_special_hybrid_encryption_remote_fails.mdwn b/doc/bugs/drop_from_special_hybrid_encryption_remote_fails.mdwn
new file mode 100644
index 0000000000..13e06bd287
--- /dev/null
+++ b/doc/bugs/drop_from_special_hybrid_encryption_remote_fails.mdwn
@@ -0,0 +1,57 @@
+### Please describe the problem.
+
+I am trying to drop a file from a special, hybrid encryption remote. It says "failed", but I cannot figure out why, the commands in --debug all seem to exit with ExitSuccess.
+
+### What steps will reproduce the problem?
+
+Not sure how to reproduce from scratch, see log below for what happens when I do 
+git annex drop file -f specialremote ...
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+$ git annex version
+git-annex version: 5.20150916+gitg79661ef-1~ndall+1
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA Database
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+"""]]
+
+### Please provide any additional information below.
+
+[[!format sh """
+[2015-12-27 00:15:58.093036] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","ls-files","--cached","-z","--","20150816_cccamp/DSC04537.ARW"]
+[2015-12-27 00:15:58.147092] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","show-ref","git-annex"]
+[2015-12-27 00:15:58.150596] process done ExitSuccess
+[2015-12-27 00:15:58.150901] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2015-12-27 00:15:58.155607] process done ExitSuccess
+[2015-12-27 00:15:58.157843] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","log","refs/heads/git-annex..85eb4dbbebcc100c2414f5a71f4fb9a22f0239fb","-n1","--pretty=%H"]
+[2015-12-27 00:15:58.162227] process done ExitSuccess
+[2015-12-27 00:15:58.162985] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","log","refs/heads/git-annex..c0747d4c69cf80aa0290f1385454eb76a4c21032","-n1","--pretty=%H"]
+[2015-12-27 00:15:58.168515] process done ExitSuccess
+[2015-12-27 00:15:58.168888] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","log","refs/heads/git-annex..0357da603dc61b28814125650def17fb0e3f82ca","-n1","--pretty=%H"]
+[2015-12-27 00:15:58.174589] process done ExitSuccess
+[2015-12-27 00:15:58.1749] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","log","refs/heads/git-annex..4673c36870f0a536b4bedc3f5826f2d6b39c9d6a","-n1","--pretty=%H"]
+[2015-12-27 00:15:58.214221] process done ExitSuccess
+[2015-12-27 00:15:58.215418] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","log","refs/heads/git-annex..75de80c0acf77e04e5b2b4c6f7947aec75603989","-n1","--pretty=%H"]
+[2015-12-27 00:15:58.243546] process done ExitSuccess
+[2015-12-27 00:15:58.244412] chat: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","cat-file","--batch"]
+[2015-12-27 00:15:58.250349] read: git ["config","--null","--list"]
+[2015-12-27 00:15:58.250859] read: git ["config","--null","--list"]
+[2015-12-27 00:15:58.253927] process done ExitSuccess
+[2015-12-27 00:15:58.254538] chat: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","--"]
+[2015-12-27 00:15:58.255324] read: git ["--version"]
+[2015-12-27 00:15:58.257803] process done ExitSuccess
+drop stratohidrive 20150816_cccamp/DSC04537.ARW [2015-12-27 00:15:58.328068] chat: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"]
+[2015-12-27 00:15:58.354229] process done ExitSuccess
+failed
+git-annex: drop: 1 failed
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+As mentioned before, I am very, very happy with git-annex :-) Discovery of 2015 for me.
diff --git a/doc/bugs/drop_from_special_hybrid_encryption_remote_fails/comment_1_09e26fdacfb5c159997671680dc95ab7._comment b/doc/bugs/drop_from_special_hybrid_encryption_remote_fails/comment_1_09e26fdacfb5c159997671680dc95ab7._comment
new file mode 100644
index 0000000000..96a96bd4fe
--- /dev/null
+++ b/doc/bugs/drop_from_special_hybrid_encryption_remote_fails/comment_1_09e26fdacfb5c159997671680dc95ab7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-20T19:14:23Z"
+ content="""
+What kind of special remote is this? In fact, can you just paste the output
+of `git annex info thenameoftheremote`
+
+There are plenty of reasons that an operation like a drop can fail,
+most of which are not bugs, but some kind of configuration problem,
+an inaccessible remote, etc. Most or all of them should come with a
+useful error message though..
+"""]]
diff --git a/doc/bugs/dropkey_-z_does_not_drop_etc.mdwn b/doc/bugs/dropkey_-z_does_not_drop_etc.mdwn
new file mode 100644
index 0000000000..f026cf3380
--- /dev/null
+++ b/doc/bugs/dropkey_-z_does_not_drop_etc.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+
+```
+❯ ( source ~/git-annexes/10.20230407+git201-g5df89d58c7.env; git annex version | head -n 1; git annex findkeys --in here | git annex dropkey --force --batch -z ; )
+git-annex version: 10.20230407+git201-g5df89d58c7-1~ndall+1
+git-annex: <stdout>: commitBuffer: resource vanished (Broken pipe)
+dropkey MD5E-s5663237--4608ffbd6b78ce3a325eb338fa556589.nii.gz
+ ok
+❯ ls -ld .git/annex/objects/**/*gz/MD5E-s5663237--4608ffbd6b78ce3a325eb338fa556589.nii.gz
+-r-------- 1 yoh yoh 5663237 May 19 09:50 .git/annex/objects/V7/Pj/MD5E-s5663237--4608ffbd6b78ce3a325eb338fa556589.nii.gz/MD5E-s5663237--4608ffbd6b78ce3a325eb338fa556589.nii.gz
+❯ ( source ~/git-annexes/10.20230407+git201-g5df89d58c7.env; git annex version | head -n 1; git annex findkeys --in here | git annex dropkey --force --batch  ; )
+git-annex version: 10.20230407+git201-g5df89d58c7-1~ndall+1
+git-annex: <stdout>: commitBuffer: resource vanished (Broken pipe)
+dropkey MD5E-s5663237--4608ffbd6b78ce3a325eb338fa556589.nii.gz ok
+❯ ls -ld .git/annex/objects/**/*gz/MD5E-s5663237--4608ffbd6b78ce3a325eb338fa556589.nii.gz
+ls: cannot access '.git/annex/objects/**/*gz/MD5E-s5663237--4608ffbd6b78ce3a325eb338fa556589.nii.gz': No such file or directory
+
+```
+
+and also was reported on 10.20230407 to not return anything causing us to stall: [https://github.com/datalad/datalad/issues/7315#issuecomment-1554348911](https://github.com/datalad/datalad/issues/7315#issuecomment-1554348911).
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
+> [[closing|done]] per my comments --[[Joey]]
diff --git a/doc/bugs/dropkey_-z_does_not_drop_etc/comment_1_278595e3bb8fe54357ea3ee78f780ccf._comment b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_1_278595e3bb8fe54357ea3ee78f780ccf._comment
new file mode 100644
index 0000000000..ccadccf5d1
--- /dev/null
+++ b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_1_278595e3bb8fe54357ea3ee78f780ccf._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-05-19T17:39:29Z"
+ content="""
+You are piping non-null-terminated output into a command that needs 
+terminating nulls. So, it reads the entire findkeys output, including
+newlines as the name of a key. And drops that key, which doesn't exist of
+course.
+
+With `findkeys --print0`, it does work. It would also be fine to not use
+`-z`, since keys should never actually contain a newline in their name.
+"""]]
diff --git a/doc/bugs/dropkey_-z_does_not_drop_etc/comment_2_d387dff8a99f9733db7856c4b216beff._comment b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_2_d387dff8a99f9733db7856c4b216beff._comment
new file mode 100644
index 0000000000..78e2929185
--- /dev/null
+++ b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_2_d387dff8a99f9733db7856c4b216beff._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-05-19T17:53:51Z"
+ content="""
+However, after successfully dropping all the keys with `--print0`, there
+is then this oddity:
+
+	git-annex: Batch input parse failure: bad key
+
+That's a bug in nul splitting when there's a trailing nul. Oops. I've
+fixed that.
+
+Also while I reproduced the rest of the behavior, I didn't see this part:
+
+	commitBuffer: resource vanished 
+
+I'm not sure which command that comes from. Probably I think the findkeys,
+if its entire output was not consumed for some reason.
+"""]]
diff --git a/doc/bugs/dropkey_-z_does_not_drop_etc/comment_3_52f21e094853f787c18f4b9737d9771f._comment b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_3_52f21e094853f787c18f4b9737d9771f._comment
new file mode 100644
index 0000000000..cdbbc90768
--- /dev/null
+++ b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_3_52f21e094853f787c18f4b9737d9771f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2023-05-19T18:47:49Z"
+ content="""
+It makes total sense, thank you Joey!  I guess a little odd behavior is only the reporting of git annex `ok` for dropping an unknown key. I guess like with `rm unknownfile` (unless `-f` is used) I would have expected it to error out. 
+"""]]
diff --git a/doc/bugs/dropkey_-z_does_not_drop_etc/comment_4_a2f221d36d538c89fa5786a3ff12bbfa._comment b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_4_a2f221d36d538c89fa5786a3ff12bbfa._comment
new file mode 100644
index 0000000000..aefb3d78ac
--- /dev/null
+++ b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_4_a2f221d36d538c89fa5786a3ff12bbfa._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2023-05-19T18:49:29Z"
+ content="""
+re vanished -- it is from `annex version` whenever its output is not fully written out due to use of `head`:
+
+```
+❯ ( source ~/git-annexes/10.20230407+git201-g5df89d58c7.env; git annex version | head -n 1)
+git-annex version: 10.20230407+git201-g5df89d58c7-1~ndall+1
+git-annex: <stdout>: commitBuffer: resource vanished (Broken pipe)
+
+```
+"""]]
diff --git a/doc/bugs/dropkey_-z_does_not_drop_etc/comment_5_46d527889606595da1a6b00b631ee2b7._comment b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_5_46d527889606595da1a6b00b631ee2b7._comment
new file mode 100644
index 0000000000..762866d45e
--- /dev/null
+++ b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_5_46d527889606595da1a6b00b631ee2b7._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2023-05-19T18:49:48Z"
+ content="""
+re vanished -- it is from `annex version` whenever its output is not fully written out due to use of `head`:
+
+```
+❯ ( source ~/git-annexes/10.20230407+git201-g5df89d58c7.env; git annex version | head -n 1)
+git-annex version: 10.20230407+git201-g5df89d58c7-1~ndall+1
+git-annex: <stdout>: commitBuffer: resource vanished (Broken pipe)
+
+```
+"""]]
diff --git a/doc/bugs/dropkey_-z_does_not_drop_etc/comment_6_d6377ddfb9d907d56c70141b0c3a8a32._comment b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_6_d6377ddfb9d907d56c70141b0c3a8a32._comment
new file mode 100644
index 0000000000..59bc49f541
--- /dev/null
+++ b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_6_d6377ddfb9d907d56c70141b0c3a8a32._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-05-19T18:54:53Z"
+ content="""
+Aha, thanks for clearing up that `git-annex version` does that! That seems
+like a bit of a bug on its own really. 
+
+
+.. Fixed that.
+"""]]
diff --git a/doc/bugs/dropkey_-z_does_not_drop_etc/comment_7_57b63abb8ccb7fbbd71afd599cb9ef5c._comment b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_7_57b63abb8ccb7fbbd71afd599cb9ef5c._comment
new file mode 100644
index 0000000000..1c49707ce9
--- /dev/null
+++ b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_7_57b63abb8ccb7fbbd71afd599cb9ef5c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2023-05-19T18:55:35Z"
+ content="""
+The reason dropkeys does not error on an unknown key is that it's entirely
+possible to get a repository into a state where a key's content is present
+but the key is otherwise unknown to git-annex. Eg, it doesn't have any
+location tracking information for it, there are no files in the git repo
+that point to it, etc. 
+
+It makes sense to support dropping the content of such a key.
+
+And, dropkeys intentionally operates the same on a key when its content is
+not present as it does when the content is present and it successfully
+dropped it. Because in either case the result is now that the specified
+key's content is not present.
+"""]]
diff --git a/doc/bugs/dropkey_-z_does_not_drop_etc/comment_8_c537d9ff75804fe4afc174791c427df4._comment b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_8_c537d9ff75804fe4afc174791c427df4._comment
new file mode 100644
index 0000000000..25c428fd57
--- /dev/null
+++ b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_8_c537d9ff75804fe4afc174791c427df4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 8"
+ date="2023-05-19T19:22:04Z"
+ content="""
+Gotcha.  Just a food for possible discussion/future:  I think it is more then of \"annotation\" of the action outcome to be not just a binary \"ok/fail\". Indeed `dropkey` can say \"ok\" as to the promise that in the end there is no key (either it was known or not etc).  But it can arrive there differently.  Similarish for \"fail\".  In DataLad we have now 4 \"status\" states: \"ok\", \"notneeded\", \"impossible\", \"error\" for that reason where first two are for \"ok\" and the other two for \"fail\". [documented here](https://github.com/datalad/datalad/blob/HEAD/docs/source/design/result_records.rst#status].
+So, here `dropkey unknown` was more of \"notneeded\" success I guess if it was for datalad to report.  May be `--json` records and non-json output of `git-annex` in the future could somehow discriminate between those outcomes.
+"""]]
diff --git a/doc/bugs/dropkey_-z_does_not_drop_etc/comment_9_f3bcf33b3b3882073765250c2d113180._comment b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_9_f3bcf33b3b3882073765250c2d113180._comment
new file mode 100644
index 0000000000..324e500f03
--- /dev/null
+++ b/doc/bugs/dropkey_-z_does_not_drop_etc/comment_9_f3bcf33b3b3882073765250c2d113180._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2023-05-23T15:42:39Z"
+ content="""
+Many commands do reflect "notneeded" by not displaying any output.
+
+(I suppose that could even be a problem with --json --batch, since
+a command like drop will not output anything when it has nothing to do.)
+
+In the case of dropkey, it could have skipped displaying anything for keys
+that don't exist, but changing that now doesn't seem wise.
+"""]]
diff --git a/doc/bugs/dropunused_returns_ok_but_doesn__39__t_delete_files.mdwn b/doc/bugs/dropunused_returns_ok_but_doesn__39__t_delete_files.mdwn
new file mode 100644
index 0000000000..c265dff773
--- /dev/null
+++ b/doc/bugs/dropunused_returns_ok_but_doesn__39__t_delete_files.mdwn
@@ -0,0 +1,55 @@
+### Please describe the problem.
+I deleted a lot of files with "git rm" and now have the problem that I cannot delete the file-contents with annex dropunused.
+"git annex unused" shows correctly the files, then I delete them with "git annex dropunsed 1-1000" and the command
+returns Sucess/OK. When I go back to "git annex unused" all files are still there, altough they should have been deleted. 
+
+
+### What version of git-annex are you using? On what operating system?
+Debian 11 Bullseye; git-annex version: 10.20220322-1~ndall+1 
+
+### Please provide any additional information below.
+
+[[!format sh """
+# git annex unused
+unused . (checking for unused data...) (checking master...)
+  Some annexed data is no longer used by any files:
+    NUMBER  KEY
+    1       SHA256E-s38888--42db1349c507d96722d2a506921dbc1a90a0a278828db732c9f1971eb9cfb70c.pyc
+    2       SHA256E-s22918--093c4494596c7441d2cc6ee90efdd98463e7b830fa5030b2a081b05b559db3bc.pyc
+    3       SHA256E-s12896--8c2c167031e59888aea1af627705d4005b41a80b433bce4f1e751f9a6e5dc149.pyc
+    4       SHA256E-s63363--dbb7bdd1512300464f0116a79ab970f26f82bb6dd71236c8ab3d58bb591a473f.pyc
+    ....
+
+  (To see where this data was previously used, run: git annex whereused --historical --unused
+
+  To remove unwanted data: git-annex dropunused NUMBER
+
+ok
+
+#git annex dropunused 1-1600 --force
+dropunused 1 ok
+dropunused 2 ok
+dropunused 3 ok
+dropunused 4 ok
+...
+
+# git annex unused
+unused . (checking for unused data...) (checking master...)
+  Some annexed data is no longer used by any files:
+    NUMBER  KEY
+    1       SHA256E-s38888--42db1349c507d96722d2a506921dbc1a90a0a278828db732c9f1971eb9cfb70c.pyc
+    2       SHA256E-s22918--093c4494596c7441d2cc6ee90efdd98463e7b830fa5030b2a081b05b559db3bc.pyc
+    3       SHA256E-s12896--8c2c167031e59888aea1af627705d4005b41a80b433bce4f1e751f9a6e5dc149.pyc
+    4       SHA256E-s63363--dbb7bdd1512300464f0116a79ab970f26f82bb6dd71236c8ab3d58bb591a473f.pyc
+    ....
+
+  (To see where this data was previously used, run: git annex whereused --historical --unused
+
+  To remove unwanted data: git-annex dropunused NUMBER
+
+ok
+
+"""]]
+
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/dropunused_returns_ok_but_doesn__39__t_delete_files/comment_1_61fc9ee219d3042e1e32e35b5086ef4e._comment b/doc/bugs/dropunused_returns_ok_but_doesn__39__t_delete_files/comment_1_61fc9ee219d3042e1e32e35b5086ef4e._comment
new file mode 100644
index 0000000000..173b56c207
--- /dev/null
+++ b/doc/bugs/dropunused_returns_ok_but_doesn__39__t_delete_files/comment_1_61fc9ee219d3042e1e32e35b5086ef4e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-02T18:47:22Z"
+ content="""
+I tried to reproduce this, but dropunused removes the data here.
+So this is not as simple as it being broken, there is something else going
+on.
+
+Can you look in .git/annex/objects/
+and find the object files for one of these
+keys?
+"""]]
diff --git a/doc/bugs/duplicate.mdwn b/doc/bugs/duplicate.mdwn
new file mode 100644
index 0000000000..66d9a425b7
--- /dev/null
+++ b/doc/bugs/duplicate.mdwn
@@ -0,0 +1 @@
+This tag is for bugs that are a duplicate of an existing bug. Please link to the original bug in a comment.
diff --git a/doc/bugs/enable-tor_failing_on_Android.mdwn b/doc/bugs/enable-tor_failing_on_Android.mdwn
new file mode 100644
index 0000000000..fe7848d860
--- /dev/null
+++ b/doc/bugs/enable-tor_failing_on_Android.mdwn
@@ -0,0 +1,109 @@
+### Please describe the problem.
+
+`git annex enable-tor` fails on Android/Termux (both when entering the command manually and in the webapp)
+
+*(apologies if this is a duplicate, but I couldn't find anything related to this problem)*
+
+### What steps will reproduce the problem?
+
+Occurs reliably when trying to enable p2p pairing via tor (see below)
+
+### What version of git-annex are you using? On what operating system?
+
+* Version: 7.20181122-gbb94cc9f8
+
+  Build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite Dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.12 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 
+
+* Installed via the Termux app using this guide: [[https://git-annex.branchable.com/Android/]]
+* Termux version 0.65
+
+* tor installed in Termux via `pkg install tor`
+
+* Rooted Android with SuperSU installed
+
+
+### Please provide any additional information below.
+
+##### In the webapp via 'Add another repository -> Share with a friend -> Let's get started':
+[[!format txt
+"""
+Failed to enable tor 
+
+enable-tor 
+  You will be prompted for root's password
+mkdir: '//.cache': Read-only file system 
+Unable to write to //.cache/git-annex/locales/_data_data_com.termux_files_home_git-annex.linux; can't continue! 
+
+git-annex: Failed to run as root: /data/data/com.termux/files/home/git-annex.linux/git-annex enable-tor 10076 
+failed
+git-annex: enable-tor: 1 failed
+"""]]
+  A SuperSU prompt to confirm root permissions is shown during the process
+
+##### On the Termux commandline (in the annex repo directory):
+Need to use the full file path since git-annex isn't in $PATH
+[[!format txt """
+$ su
+# /data/data/com.termux/files/home/git-annex.linux/git-annex enable-tor 10076
+mkdir: '//.cache': Read-only file system
+Unable to write to //.cache/git-annex/locales/_data_data_com.termux_files_home_git-annex.linux; can't continue!
+"""]]
+
+Seems like an environment variable isn't set correctly and/or is empty (hence the double // at the start), leading to an incorrect path.
+
+Output of `env` (as root):
+[[!format txt """
+# env
+_=/system/bin/env
+ANDROID_DATA=/data
+HOME=/
+ANDROID_STORAGE=/storage
+PWD=/data/data/com.termux/files/home/storage/shared/annex
+TERMINFO=/system/etc/terminfo
+TERM=xterm-256color
+ANDROID_CACHE=/cache
+SHLVL=1
+DOWNLOAD_CACHE=/cache
+LOGNAME=root
+LANG=en_US.UTF-8
+OLDPWD=/data/data/com.termux/files/home
+BOOTCLASSPATH=/system/framework/core-oj.jar:/system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/telephony-common.jar:/system/framework/voip-common.jar:/system/framework/ims-common.jar:/system/framework/apache-xml.jar:/system/framework/org.apache.http.legacy.boot.jar:/system/framework/telephony-ext.jar
+SHELL=/su/bin/sush
+ANDROID_BOOTLOGO=1
+SYSTEMSERVERCLASSPATH=/system/framework/org.cyanogenmod.platform.jar:/system/framework/org.cyanogenmod.hardware.jar:/system/framework/services.jar:/system/framework/ethernet-service.jar:/system/framework/wifi-service.jar
+LD_PRELOAD=libsigchain.so
+ASEC_MOUNTPOINT=/mnt/asec
+ANDROID_ASSETS=/system/app
+EXTERNAL_STORAGE=/sdcard
+USER=root
+TMPDIR=/data/local/tmp
+PATH=/sbin/su:/su/bin:/su/xbin:/system/bin:/system/xbin
+HOSTNAME=mido
+ANDROID_ROOT=/system
+PREFIX=/data/data/com.termux/files/usr
+"""]]
+
+Output of `env` (as normal user):
+[[!format txt """
+$ env
+LD_LIBRARY_PATH=/data/data/com.termux/files/usr/lib
+LANG=en_US.UTF-8
+PREFIX=/data/data/com.termux/files/usr
+PWD=/data/data/com.termux/files/home/storage/shared/annex
+HOME=/data/data/com.termux/files/home
+TMPDIR=/data/data/com.termux/files/usr/tmp
+SHELL=/data/data/com.termux/files/usr/bin/bash
+TERM=xterm-256color
+SHLVL=1
+ANDROID_ROOT=/system
+ANDROID_DATA=/data
+EXTERNAL_STORAGE=/sdcard
+PATH=/data/data/com.termux/files/usr/bin:/data/data/com.termux/files/usr/bin/applets:/data/data/com.termux/files/home/git-annex.linux
+LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec.so
+_=/data/data/com.termux/files/usr/bin/env
+OLDPWD=/data/data/com.termux/files/home/storage/shared
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sure thing! git-annex is amazing and usually works really well. Using it to keep files in sync between my pc, laptop and phone.
diff --git a/doc/bugs/enable-tor_failing_on_Android/comment_1_7592b563c0ddb338e1f39ff6cf5fa1f0._comment b/doc/bugs/enable-tor_failing_on_Android/comment_1_7592b563c0ddb338e1f39ff6cf5fa1f0._comment
new file mode 100644
index 0000000000..723d527489
--- /dev/null
+++ b/doc/bugs/enable-tor_failing_on_Android/comment_1_7592b563c0ddb338e1f39ff6cf5fa1f0._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-01-22T21:28:17Z"
+ content="""
+I see you're trying to run git-annex from termux having su'd to root
+and that fails. (Not due to a missing env var, but due to HOME=/ and
+android not letting root write to / apparently?!)
+
+I don't know that chasing down that failure is a good use
+of my time, because having tor installed system-wide on a rooted android
+is not going to be a very common thing to do.
+
+termux has a tor package, and with tor installed that way, its
+configuration is in `$PREFIX/etc/tor/torrc` in the termux file tree,
+and is writable by the termux user, without su.
+
+<https://wiki.termux.com/wiki/Remote_Access#Accessing_Termux_from_the_Internet>
+
+Making enable-tor use that seems like a more fruitful avenue to pursue.
+Utility/Tor.hs has a findTorrc function that could be modified to
+find the termux torrc file. Other changes would also be needed for eg
+torLibDir.
+"""]]
diff --git a/doc/bugs/enable-tor_unsupported_on_osx.mdwn b/doc/bugs/enable-tor_unsupported_on_osx.mdwn
new file mode 100644
index 0000000000..99cdde1d3b
--- /dev/null
+++ b/doc/bugs/enable-tor_unsupported_on_osx.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+
+enable-tor on an OSX box (with magic-wormhole and tor installed via brew) fails miserably.
+
+### What steps will reproduce the problem?
+
+run git-annex enable-tor - multiple fails, see details.
+
+
+### What version of git-annex are you using? On what operating system?
+
+7.20191106
+
+OSX 10.14.5
+
+### Please provide any additional information below.
+
+The first failure is that enable-tor can't run as root.  Instead, I call it with sudo git-annex enable-tor <UID>
+
+The second failure is that you try and write into /etc/tor/torrc - which is not where torrc is located on a brew installed tor - it's in /usr/local/etc/tor/torrc.  I made a symlink to get around that problem.
+
+The third failure is a complaint about systemctl not being present.  I looked in Utilities/Tor.hc and saw you were trying to call for a reload of tor.  To hack around that, I wrote a script called systemctl that simply called 'brew services' with the args passed in ( brew services $1 $2 ).  
+
+After that, I still get the error: git-annex: tor failed to create hidden service, perhaps the tor service is not running
+
+I have restarted tor manually, and it is indeed running.  It looks like something is failing in setting up the Onion socket, but I can't see what
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I love it - using it to protect my photo archive now using a central special repo (rclone) for the data, and a gitlab repo for the base.  
diff --git a/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated.mdwn b/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated.mdwn
new file mode 100644
index 0000000000..07c8eae8cb
--- /dev/null
+++ b/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated.mdwn
@@ -0,0 +1,46 @@
+### Please describe the problem.
+
+```shell
+$> git annex version
+git-annex version: 10.20230828+git6-g86c70833a1-1~ndall+1
+...
+
+$> git annex enableremote typhon                                                          
+enableremote (normal) typhon 
+  Unable to parse git config from typhon
+
+  Remote typhon does not have git-annex installed; setting annex-ignore
+
+  This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote typhon
+failed
+enableremote: 1 failed
+
+```
+
+here git-annex hints on git-annex not being installed (totally not true), or inability to parse config (in effect it is true but not for the reason of config being wrong etc).
+
+It is all because that folder on the ssh remote belongs to someone else and if I run shell command manually then I see the hint from `git` itself:
+
+```
+$> ssh typhon git-annex-shell configlist /mnt/DATA/data/studies/bep302/gin_BEP032-examples --debug
+[2023-08-31 11:57:26.338523978] (Utility.Process) process [3594411] read: git ["--git-dir=/mnt/DATA/data/studies/bep302/gin_BEP032-examples/.git","--work-tree=/mnt/DATA/data/studies/bep302/gin_BEP032-examples","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2023-08-31 11:57:26.339808748] (Utility.Process) process [3594411] done ExitSuccess
+[2023-08-31 11:57:26.340366568] (Utility.Process) process [3594412] read: git ["config","--local","--list"]
+[2023-08-31 11:57:26.342570264] (Utility.Process) process [3594412] done ExitFailure 128
+[2023-08-31 11:57:26.342620672] (Git.Config) config output: fatal: --local can only be used inside a git repository
+
+git-annex-shell: Git refuses to operate in this repository,
+probably because it is owned by someone else.
+
+To add an exception for this directory, call:
+	git config --global --add safe.directory /mnt/DATA/data/studies/bep302/gin_BEP032-examples
+```
+
+so, ideally `git annex enableremote` should provide a similar diagnostic output instead of incorrect reasons stated.
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+```
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_1_c23de4c4ff536a214c795a805957c9f1._comment b/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_1_c23de4c4ff536a214c795a805957c9f1._comment
new file mode 100644
index 0000000000..a19d556fee
--- /dev/null
+++ b/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_1_c23de4c4ff536a214c795a805957c9f1._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-09-07T17:01:41Z"
+ content="""
+I wonder if it even makes sense for git-annex-shell to replicate this git
+security check, or would it be better for it to instruct git to trust the
+repository, so it can be used on it?
+
+git's CVE-2022-24765 involves a malicious creation of a .git repository
+above the victim's cwd, with a .git/config that causes things like eg shell
+prompts that run git to execute attacker-controlled commands.
+
+git-annex-shell commands all take the directory that the repository is
+in, and uses that repository. So it doesn't traverse above looking for
+other .git directories.
+
+And, `git clone` will happily clone a remote repsository that's owned 
+by another user, including over ssh. And pull and push etc work with such a
+remote. So git-annex-shell should too.
+
+(For that matter, other git-annex-shell commands do work, it's only the
+command that reads the git config that fails to work.)
+"""]]
diff --git a/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_2_c75d3a033b1b8699e512df4641a38548._comment b/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_2_c75d3a033b1b8699e512df4641a38548._comment
new file mode 100644
index 0000000000..2bb5be7ff9
--- /dev/null
+++ b/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_2_c75d3a033b1b8699e512df4641a38548._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-09-07T18:21:30Z"
+ content="""
+Closely related, when a local repo is owned by someone else, cloning it and
+using it as a git-annex remote also fails, at the same config listing
+stage.
+
+I think the same reasoning applies to that, the path to the repo is
+explicitly specified in the remote url, so it should treat it as a safe
+repo for the purposes of listing its config.
+"""]]
diff --git a/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_3_39e13618336181485175dddc7185160a._comment b/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_3_39e13618336181485175dddc7185160a._comment
new file mode 100644
index 0000000000..ce89951483
--- /dev/null
+++ b/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_3_39e13618336181485175dddc7185160a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-09-07T18:32:57Z"
+ content="""
+Basically the same fix works for both the ssh remote and the local
+remote cases.
+"""]]
diff --git a/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_4_c7a5c3dfaca25fad2edf9575f65629e8._comment b/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_4_c7a5c3dfaca25fad2edf9575f65629e8._comment
new file mode 100644
index 0000000000..a672b77ac8
--- /dev/null
+++ b/doc/bugs/enableremote_fails_with___34__wrong_reason__34___stated/comment_4_c7a5c3dfaca25fad2edf9575f65629e8._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-09-07T18:36:37Z"
+ content="""
+Another related case is when git has been configured with
+safe.bareRepository=explicit and the remote (either ssh or local)
+is a bare repo. git-annex-shell will fail with the same misleading message,
+and for a local repo, git-annex will also display the same misleading
+message.
+
+I think it also ought to override safe.bareRepository for such remotes,
+because eg git pull works with such remotes. The point of 
+safe.bareRepository=explicit is not to prevent using bare remotes, but to
+prevent things like shell prompts to accidentially use bare repos that are
+eg, committed by a malicious attacker to a git repository, to avoid using
+git configs that allow running arbitrary code.
+"""]]
diff --git a/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade.mdwn b/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade.mdwn
new file mode 100644
index 0000000000..93cbcec6f4
--- /dev/null
+++ b/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade.mdwn
@@ -0,0 +1,96 @@
+### Please describe the problem.
+
+When running git-annex sync on a regular repository, where a remote bare git repository is only, I am encountering the following:
+
+[[!format sh """
+$ git-annex sync
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+git-annex: fd:17: Data.ByteString.hGetLine: end of file
+
+  Remote webdav: Repository /u01/webdav/www/databases.git-annex.uxgit/MultiArchPackages.git-annex.git is at unsupported version 9. Automatic upgrade failed!
+commit
+On branch master
+nothing to commit, working tree clean
+ok
+pull webdav
+ok
+"""]]
+
+I found two fixed bugs that seem to mirror this:
+
+* <https://git-annex.branchable.com/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/>
+* <https://git-annex.branchable.com/projects/datalad/bugs-done/add_--force-small_fails_on_modified_submodules/>
+
+Unlike those bugs, I am not (or at least not aware of) using submodules.
+
+### What steps will reproduce the problem?
+
+Apologies, at this stage I haven't tried to set this up as a reproducible scenario, but I suspect it will not be an easily contrived scenario because of repository versions.
+
+### What version of git-annex are you using? On what operating system?
+
+Using neurodebian on actual Debian 12, amd64:
+
+[[!format sh """
+$ git-annex version
+git-annex version: 10.20230321-1~ndall+1
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 9
+"""]]
+
+### Please provide any additional information below.
+
+Just to avoid confusion, yes, this is webdav shared, but I am not using a webdav special repository. I am actually allowing the repository to be mounted via webdav.
+
+Also, I've started using neurodebian's git-annex, because I want to get nearer the bleeding edge across Debian, Ubuntu and Windows hosts.
+
+If I change directory to that remote itself, and run the command (determined from --debug) to perform the upgrade, I see this:
+
+[[!format sh """
+$ cd /u01/webdav/www/databases.git-annex.uxgit/MultiArchPackages.git-annex.git/
+$ git-annex version
+git-annex version: 10.20230321-1~ndall+1
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 9
+$ git-annex upgrade --quiet --autoonly
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+git-annex: fd:17: Data.ByteString.hGetLine: end of file
+"""]]
+
+### Have you had any luck using git-annex before?
+
+Yes, it's one of my favourite opensource tools.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_1_041e664be0a5ae635cf5848d9fee380c._comment b/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_1_041e664be0a5ae635cf5848d9fee380c._comment
new file mode 100644
index 0000000000..a80db46ea4
--- /dev/null
+++ b/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_1_041e664be0a5ae635cf5848d9fee380c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-10-09T18:28:15Z"
+ content="""
+The "unsupported version 9" is wrong, version 9 is still supported and so
+this upgrade failing won't prevent git-annex from using the repository.
+I've corrected the message.
+"""]]
diff --git a/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_2_b0deace2dcadbd50c0e0cb155041b255._comment b/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_2_b0deace2dcadbd50c0e0cb155041b255._comment
new file mode 100644
index 0000000000..3d8a5a145c
--- /dev/null
+++ b/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_2_b0deace2dcadbd50c0e0cb155041b255._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-10-09T18:29:08Z"
+ content="""
+As to why the upgrade fails, it seems to me that mounting webdav as a
+filesystem could easily have incompatabilities that cause strange behavior.
+
+git can fail with this error message in at least 3 different ways. Although
+in all cases it's supposed to be displaying a path where it has "(null)",
+so it seems something is causing git to have a null pointer. That seems
+like it almost has to be a bug in git.
+
+It might help to run the git-annex command with --debug to determine what
+git command is doing this.
+"""]]
diff --git a/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_3_60f745051264fcacdce882eb8646b3fe._comment b/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_3_60f745051264fcacdce882eb8646b3fe._comment
new file mode 100644
index 0000000000..9d5d53c472
--- /dev/null
+++ b/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_3_60f745051264fcacdce882eb8646b3fe._comment
@@ -0,0 +1,56 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ nickname="beryllium"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="comment 3"
+ date="2023-10-09T22:30:46Z"
+ content="""
+Thanks joey. Based off of your comments, I believe I have found the root cause, which you are right, I don't think it's git-annex.
+
+Also, I realise I should have added a bit more detail.
+
+The /u01/webdav/www/ path is not a webdav mount, it's the backing real filesystem for actual webdav mounts. And this is important.
+
+Further, this scenario worked with the Debian 11 version of git-annex, and I think those other bugs I linked to might account for the difference, because handing of dot files changed... but I'm not sure.
+
+Also, I did run --debug, but the reason I reached out is, the git calls were of the form:
+
+[[!format  sh \"\"\"
+git --git-dir=. --literal-pathspecs -c annex.debug=true hash-object -w --no-filters --stdin-paths
+\"\"\"]]
+
+and I couldn't work out what paths were being passed via stdin. However, I've run strace and the reason I believe I see these messages is this:
+
+[[!format sh \"\"\"
+$ find . -name .DAV -print
+./.DAV
+./refs/heads/.DAV
+./refs/heads/synced/.DAV
+./info/.DAV
+./annex/.DAV
+./annex/journal/.DAV
+./hooks/.DAV
+./objects/71/.DAV
+./objects/ba/.DAV
+./objects/80/.DAV
+./objects/15/.DAV
+./objects/7a/.DAV
+./objects/a8/.DAV
+./objects/b0/.DAV
+./objects/27/.DAV
+./objects/pack/.DAV
+./objects/a5/.DAV
+./objects/33/.DAV
+./objects/28/.DAV
+./objects/b6/.DAV
+./objects/77/.DAV
+./objects/ad/.DAV
+./objects/94/.DAV
+\"\"\"]]
+
+So for me, the solution is to use an actual webdav mount, even on the local hosting server, and that will hide these webdav \"internals\"/metadata.
+
+Is there cause at all for config changes around git-annex to avoid that though?
+
+
+"""]]
diff --git a/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_4_9e32aa105bbf11a6d2610a62bfa9517b._comment b/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_4_9e32aa105bbf11a6d2610a62bfa9517b._comment
new file mode 100644
index 0000000000..ade1760f19
--- /dev/null
+++ b/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_4_9e32aa105bbf11a6d2610a62bfa9517b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ nickname="beryllium"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="comment 4"
+ date="2023-10-10T02:36:51Z"
+ content="""
+I should say that, sometimes I forget my internal monologue/designs.
+
+My initial intention was to use the webdav mount exclusively, but somehow I setup my remote to the backing filesystem path
+
+So, there's no need for a workaround really. Please free to close.
+"""]]
diff --git a/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_5_28d35ef30f76ec326363d86ab2948ad3._comment b/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_5_28d35ef30f76ec326363d86ab2948ad3._comment
new file mode 100644
index 0000000000..abf36c782f
--- /dev/null
+++ b/doc/bugs/encountering_fatal_error_on_auto_annex_upgrade/comment_5_28d35ef30f76ec326363d86ab2948ad3._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-10-10T17:00:37Z"
+ content="""
+Reproduced as follows:
+
+	joey@darkstar:~/tmp/bench>git init  --bare dav
+	Initialized empty Git repository in /home/joey/tmp/bench/dav/
+	joey@darkstar:~/tmp/bench>cd dav
+	joey@darkstar:~/tmp/bench/dav>git-annex init --version=9
+	init  ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/dav>for s in $(find -type d); do mkdir $s/.DAV;done
+	joey@darkstar:~/tmp/bench/dav>git-annex init --version=9
+	init  fatal: Unable to add (null) to database
+
+So it's these empty directories indeed. (Empty .DAV files don't cause this.)
+
+In particular, it's any empty directory in .git/annex/journal. Which is
+supposed to only contain files that git-annex wrote there. Staging the journal
+is why git hash-object gets involved.
+
+	mkdir .DAV
+	echo .DAV | git hash-object -w --stdin-paths
+	fatal: Unable to add .DAV to database
+
+Still unclear why git ends up with "(null)" in the error message.
+
+While it will slow git-annex down a tiny bit to check if it's a regular file,
+it seems better for git-annex to be robust against this kind of pollution.
+"""]]
diff --git a/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote.mdwn b/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote.mdwn
new file mode 100644
index 0000000000..991d054933
--- /dev/null
+++ b/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote.mdwn
@@ -0,0 +1,44 @@
+### Please describe the problem.
+When cloning a remote client repo via ssh and then enableremote the encryptionsetting seem not be used
+
+
+### What steps will reproduce the problem?
+- create a repository (as client) on computer WO
+- create a special remote via rsync+ssh on computer BA with encryption=none from WO
+--> syncing works
+- git clone via ssh from WO on computer XY, group is manual
+- git-annex get on XY with source WO workes (OK)
+- enableremote BA on computer XY
+- shutdown computer WO
+- try to get some file on computer XY. The download is first tried from WO, then from BA  --> correct
+
+
+- download from BA fails (ERROR) 
+--> Reason seems to be that encryption=none is not honored: 
+rsync: change_dir "XXXXXXXX/GPGHMACSHA1--398057f8bd37edf898aeae4557c6277f1162382b" failed: No such file or directory (2)
+
+I additionally could not find out where to manually change the encryption settings after enableremote
+
+
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 5.20140412ubuntu1
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote/comment_1_ce62150a3bb8c6be05b9f2ddbe64ae8b._comment b/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote/comment_1_ce62150a3bb8c6be05b9f2ddbe64ae8b._comment
new file mode 100644
index 0000000000..410849ec5a
--- /dev/null
+++ b/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote/comment_1_ce62150a3bb8c6be05b9f2ddbe64ae8b._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-25T18:10:38Z"
+ content="""
+I cannot reproduce this, and you did not provide any kind of transcript,
+which makes it hard to guess where you went wrong.
+
+Here is a transcript of it working.
+
+<pre>
+joey@darkstar:~/tmp/1>mkdir /tmp/demo
+joey@darkstar:~/tmp/1>git annex initremote demo type=rsync encryption=none rsyncurl=localhost:/tmp/demo
+initremote demo ok
+(recording state in git...)
+joey@darkstar:~/tmp/1>git annex copy --to demo
+copy foo (checking demo...) (to demo...) 
+sending incremental file list
+f28/
+f28/734/
+f28/734/SHA256E-s30--20c71ffd77c7f25e52416eb6afd36bf8df9410a9942d8a42e7caf74f6cfa5fb8/
+f28/734/SHA256E-s30--20c71ffd77c7f25e52416eb6afd36bf8df9410a9942d8a42e7caf74f6cfa5fb8/SHA256E-s30--20c71ffd77c7f25e52416eb6afd36bf8df9410a9942d8a42e7caf74f6cfa5fb8
+             30 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/5)
+ok
+(recording state in git...)
+joey@darkstar:~/tmp/1>cd ..
+joey@darkstar:~/tmp>cd 2
+joey@darkstar:~/tmp/2>git annex sync
+[...]
+joey@darkstar:~/tmp/2>git annex enableremote demo
+enableremote demo ok
+(recording state in git...)
+joey@darkstar:~/tmp/2>git annex get --from demo
+get foo (from demo...) 
+SHA256E-s30--20c71ffd77c7f25e52416eb6afd36bf8df9410a9942d8a42e7caf74f6cfa5fb8
+             30 100%   29.30kB/s    0:00:00 (xfr#1, to-chk=0/1)
+ok
+(recording state in git...)
+"""]]
diff --git a/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15.mdwn b/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15.mdwn
new file mode 100644
index 0000000000..136ae77dbb
--- /dev/null
+++ b/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15.mdwn
@@ -0,0 +1,101 @@
+### Please describe the problem.
+
+When doing 
+
+git checkout 3b18836
+
+on a very large repository, where tens of thousands of files will be changed, I get many
+
+error: external filter 'git-annex filter-process' failed
+error: git-annex filter-process died of signal 15
+
+and finally
+
+git-annex: git: createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files)
+fatal: the remote end hung up unexpectedly
+
+
+### What steps will reproduce the problem?
+
+git checkout
+on a really big commit.
+
+### What version of git-annex are you using? On what operating system?
+
+The system and all the SW should be up to date.  
+
+% git --version                             
+git version 2.34.1
+
+% git annex version                        
+git-annex version: 10.20220322-1~ndall+1
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 9
+
+% uname -a                                  
+Linux  5.15.0-33-generic #34-Ubuntu SMP Wed May 18 13:34:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
+
+% cat /etc/os-release                       
+PRETTY_NAME="Ubuntu 22.04 LTS"
+NAME="Ubuntu"
+VERSION_ID="22.04"
+VERSION="22.04 LTS (Jammy Jellyfish)"
+VERSION_CODENAME=jammy
+ID=ubuntu
+ID_LIKE=debian
+HOME_URL="https://www.ubuntu.com/"
+SUPPORT_URL="https://help.ubuntu.com/"
+BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
+PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
+UBUNTU_CODENAME=jammy
+
+
+The computer has 128GB of main memory, and so is not running out of that.
+
+This is a large repository:
+
+du -sh .                                            p
+43G	.
+
+(62)% du -sh .git                                      
+42G	.git
+
+(63)% du -sh .git/annex                                 
+19G	.git/annex
+
+% git gc                                   
+Enumerating objects: 375565, done.
+Counting objects: 100% (375565/375565), done.
+Delta compression using up to 12 threads
+Compressing objects: 100% (153675/153675), done.
+Writing objects: 100% (375565/375565), done.
+Total 375565 (delta 215701), reused 364628 (delta 207259), pack-reused 0
+73.38s real  97.69s user  4.93s system  139% 0,0 socket  13753 mem git gc
+
+
+I'm trying to recover from a mess caused by creating a new remote repository, making it shallow to save space, and updating it by mounting it on a local system with sshfs, etc.   That caused an unintended rebase messing things up, e.g., git log shows most of the commits vanished (merged?).   So I was trying to go back to an earlier, good, commit.  However that requires changing, basically, everything.  And that seems to be too big a change for git annex to process.
+
+FWIW, I'm not using lfs.
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Otherwise, it's great.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_1_02da33e41e4f4471d1ae08e9fede229a._comment b/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_1_02da33e41e4f4471d1ae08e9fede229a._comment
new file mode 100644
index 0000000000..df76b6d693
--- /dev/null
+++ b/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_1_02da33e41e4f4471d1ae08e9fede229a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-06-29T16:13:25Z"
+ content="""
+How big a commit are we talking here, in terms of number of files
+added/changed?
+
+I've tried with 10000 modified files and not seen a problem IIRC.
+
+Also, signal 15 is SIGTERM, which would be a strange signal to happen
+unless it were ctrl-c'd.
+
+Final weird thing is "fatal: the remote end hung up unexpectedly", since
+that would indicate a git fetch was running, and git-annex certianly does
+not fetch..
+"""]]
diff --git a/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_2_5ebfc18008cf4bc21ffce57067314fc0._comment b/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_2_5ebfc18008cf4bc21ffce57067314fc0._comment
new file mode 100644
index 0000000000..4ef52812d5
--- /dev/null
+++ b/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_2_5ebfc18008cf4bc21ffce57067314fc0._comment
@@ -0,0 +1,85 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-07-13T19:53:44Z"
+ content="""
+Just reproduced this. In my big repo, I had commit
+eab6ac8b34be1d7c36df2a2f41a9414cf5908041 checked out
+and ran `git reset --hard fbbe4045871f`
+
+Git reported that it updated 112465 files, and near to the beginning,
+filter-process died of signal 15.
+
+Even better, it is reproducible, going back to that
+starting commit and running that command again works every time!
+
+And I got a strace too. Here is the git command:
+
+	write(5, "0013command=smudge\n", 19)    = 19
+	write(5, "0019pathname=new/cleanup\n", 25) = 25
+	write(5, "0035treeish=fbbe4045871fb749299b"..., 53) = 53
+	write(5, "0032blob=baad2545defeae59f526ea3"..., 50) = 50
+	write(5, "0000", 4)                     = 4
+	write(5, "0322", 4)                     = 4
+	write(5, "#!/bin/sh\n\ngit commit -m 'pre cl"..., 798) = 798
+	write(5, "0000", 4)                     = 4
+	read(6, "0000", 4)                      = 4
+	rt_sigaction(SIGPIPE, {sa_handler=0x563cf8debb50, sa_mask=[PIPE], sa_flags=SA_RES
+	TORER|SA_RESTART, sa_restorer=0x7fab5717c920}, {sa_handler=SIG_IGN, sa_mask=[PIPE
+	], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fab5717c920}, 8) = 0
+	write(2, "error: external filter 'git-anne"..., 57) = 57
+	kill(1638045, SIGTERM)                  = 0
+
+So git sends SIGTERM when it gets unhappy with the response it got from
+git-annex filter-process.
+
+Here is where git runs git-annex filter-process via the shell:
+
+	execve("/bin/sh", ["/bin/sh", "-c", "git-annex filter-process", "git-annex filter-process"], 0x563cfacbfb40 /* 68 vars */) = 0
+	...
+	newfstatat(AT_FDCWD, "/home/joey/bin/git-annex", {st_mode=S_IFREG|0755, st_size=72524080, ...}, 0) = 0
+	rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0
+	vfork()                                 = 1631132
+	rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0
+	wait4(-1, 0x7fff910d697c, 0, NULL)      = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+	--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1631129, si_uid=1000} ---
+	+++ killed by SIGTERM +++
+
+But the actual git-annex process read the last thing git wrote to it,
+replied, and keeps running until it later reads an EOF from git.
+
+	write(1, "0000", 4)                     = 4
+	poll([{fd=0, events=POLLIN}], 1, 0)     = 0 (Timeout)
+	epoll_ctl(4, EPOLL_CTL_MOD, 0, {EPOLLIN|EPOLLONESHOT, {u32=0, u64=287065581021036544}}) = 0
+	futex(0x67fe568, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY) = 0
+	futex(0x67fe570, FUTEX_WAKE_PRIVATE, 1) = 0
+	futex(0x67fe68c, FUTEX_WAKE_PRIVATE, 1) = 1
+	read(0, "0013command=smudge\n0019pathname=new/cleanup\n0035treeish=fbbe4045871fb749299b4484862645bd9a7f175a\n0032blob=baad2545defeae59f526ea3d64174398899cb9cc\n00000322", 8192) = 155
+	poll([{fd=0, events=POLLIN}], 1, 0)     = 1 ([{fd=0, revents=POLLIN}])
+	futex(0x67fe688, FUTEX_WAKE_PRIVATE, 1) = 1
+	futex(0x67fe690, FUTEX_WAKE_PRIVATE, 1) = 0
+	read(0, "#!/bin/sh....", 8192) = 802
+	futex(0x67fe56c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY) = -1 EAGAIN (Resource temporarily unavailable)
+	futex(0x67fe570, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)
+	futex(0x67fe570, FUTEX_WAKE_PRIVATE, 1) = 0
+	poll([{fd=1, events=POLLOUT}], 1, 0)    = 1 ([{fd=1, revents=POLLOUT}])
+	futex(0x67fe68c, FUTEX_WAKE_PRIVATE, 1) = 1
+	futex(0x67fe690, FUTEX_WAKE_PRIVATE, 1) = 0
+	write(1, "0013status=success\n", 19)    = 19
+	futex(0x67fe568, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY) = 0
+	futex(0x67fe570, FUTEX_WAKE_PRIVATE, 1) = 0
+	poll([{fd=1, events=POLLOUT}], 1, 0)    = 1 ([{fd=1, revents=POLLOUT}])
+	write(1, "0000", 4)                     = 4
+	poll([{fd=1, events=POLLOUT}], 1, 0)    = 1 ([{fd=1, revents=POLLOUT}])
+	write(1, "0322#!/bin/sh...", 802) = 802
+	poll([{fd=1, events=POLLOUT}], 1, 0)    = 1 ([{fd=1, revents=POLLOUT}])
+	write(1, "0000", 4)                     = 4
+	poll([{fd=1, events=POLLOUT}], 1, 0)    = 1 ([{fd=1, revents=POLLOUT}])
+	write(1, "0000", 4)                     = 4
+	poll([{fd=0, events=POLLIN}], 1, 0)     = 0 (Timeout)
+
+Git does not see that 0013status=success response though. It sees "0000",
+which must be the one that git-annex wrote earlier (top of above strace).
+
+So, this seems like a protocol problem of some kind.
+"""]
diff --git a/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_3_c74018853a4da8e609da1803051a6893._comment b/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_3_c74018853a4da8e609da1803051a6893._comment
new file mode 100644
index 0000000000..93f088f6c0
--- /dev/null
+++ b/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_3_c74018853a4da8e609da1803051a6893._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-07-13T20:32:03Z"
+ content="""
+I also saw this when adding a single file to git:
+
+	joey@darkstar:/tmp/a1>touch .foo.lck
+	joey@darkstar:/tmp/a1>git add .foo.lck 
+	error: external filter 'git-annex filter-process' failed
+	error: git-annex filter-process died of signal 15
+
+But, I have not succeeded to reproduce that again. This was in a v9 repository BTW.
+"""]]
diff --git a/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_4_0a80393f055ead9a3a62da0aa4ec3298._comment b/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_4_0a80393f055ead9a3a62da0aa4ec3298._comment
new file mode 100644
index 0000000000..004b6170d0
--- /dev/null
+++ b/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_4_0a80393f055ead9a3a62da0aa4ec3298._comment
@@ -0,0 +1,54 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-07-13T20:35:53Z"
+ content="""
+Feeling like this is most likley a pkt-line protocol bug in git-annex, and
+probably one inovlving empty files. Both because of the prior comment with
+the empty file and it turns out there is also an empty file in my first
+reproducer.
+
+Here is a `GIT_TRACE_PACKET=1` log when reproducing it. I have omitted
+the actual content of my files..
+
+	16:30:18.248308 pkt-line.c:80           packet:          git> command=smudge
+	16:30:18.248335 pkt-line.c:80           packet:          git> pathname=new/.updater
+	16:30:18.248344 pkt-line.c:80           packet:          git> treeish=fbbe4045871fb749299b4484862645bd9a7f175a
+	16:30:18.248352 pkt-line.c:80           packet:          git> blob=dd75da379e8a2cad5a793d352e7def865d65158d
+	16:30:18.248358 pkt-line.c:80           packet:          git> 0000
+	16:30:18.248397 pkt-line.c:80           packet:          git> #!/bin/sh....
+	16:30:18.248409 pkt-line.c:80           packet:          git> 0000
+	16:30:18.248637 pkt-line.c:80           packet:          git< status=success
+	16:30:18.248728 pkt-line.c:80           packet:          git< 0000
+	16:30:18.248806 pkt-line.c:80           packet:          git< #!/bin/sh....
+	16:30:18.248818 pkt-line.c:80           packet:          git< 0000
+	16:30:18.248826 pkt-line.c:80           packet:          git< 0000
+	16:30:18.248985 pkt-line.c:80           packet:          git> command=smudge
+	16:30:18.249007 pkt-line.c:80           packet:          git> pathname=new/.updater.lock
+	16:30:18.249017 pkt-line.c:80           packet:          git> treeish=fbbe4045871fb749299b4484862645bd9a7f175a
+	16:30:18.249024 pkt-line.c:80           packet:          git> blob=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
+	16:30:18.249031 pkt-line.c:80           packet:          git> 0000
+	16:30:18.249037 pkt-line.c:80           packet:          git> 0000
+	16:30:18.249245 pkt-line.c:80           packet:          git< status=success
+	16:30:18.249262 pkt-line.c:80           packet:          git< 0000
+	16:30:18.249270 pkt-line.c:80           packet:          git< 0000
+	16:30:18.249277 pkt-line.c:80           packet:          git< 0000
+	16:30:18.280842 pkt-line.c:80           packet:          git> command=smudge
+	16:30:18.280882 pkt-line.c:80           packet:          git> pathname=new/cleanup
+	16:30:18.280891 pkt-line.c:80           packet:          git> treeish=fbbe4045871fb749299b4484862645bd9a7f175a
+	16:30:18.280898 pkt-line.c:80           packet:          git> blob=baad2545defeae59f526ea3d64174398899cb9cc
+	16:30:18.280904 pkt-line.c:80           packet:          git> 0000
+	16:30:18.280932 pkt-line.c:80           packet:          git> #!/bin/sh...
+	16:30:18.280942 pkt-line.c:80           packet:          git> 0000
+	16:30:18.280953 pkt-line.c:80           packet:          git< 0000
+	error: external filter 'git-annex filter-process' failed
+	error: git-annex filter-process died of signal 15
+
+Now, from git's perspective, the last response of "0000" does look wrong.
+It should have been "status=success" followed by "0000" and then the file
+content, and then "0000" and "0000" again. 
+
+But as seen in the strace, git-annex sends more than that.
+
+My guess is that git-annex is sending one 0000 too many for an empty file.
+"""]]
diff --git a/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_5_8b27c6099afea7011717492f53fcdac4._comment b/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_5_8b27c6099afea7011717492f53fcdac4._comment
new file mode 100644
index 0000000000..0ba99290ca
--- /dev/null
+++ b/doc/bugs/error__58___git-annex_filter-process_died_of_signal_15/comment_5_8b27c6099afea7011717492f53fcdac4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-07-13T21:11:07Z"
+ content="""
+Indeed, I put in a special case for empty files and solved this!
+"""]]
diff --git a/doc/bugs/error_creating_internet_archive_item_via_web_UI.mdwn b/doc/bugs/error_creating_internet_archive_item_via_web_UI.mdwn
new file mode 100644
index 0000000000..af43a59b26
--- /dev/null
+++ b/doc/bugs/error_creating_internet_archive_item_via_web_UI.mdwn
@@ -0,0 +1,47 @@
+### Please describe the problem.
+
+When I hit **Add Internet Archive item**, I get:
+
+Internal Server Error  
+Unexpected parameters: x-amz-interactive-priority x-amz-mediatype  
+git-annex version 8.20210223
+
+
+### What steps will reproduce the problem?
+
+create a directory; git init; git annex init
+start the web ui; point it at said directory
+
+Hit the **+ Add another repository** button
+
+Choose **Internet Archive**
+
+On the _Adding an Internet Archive item_ page, enter access key, secret key
+
+choose Media Type software  
+Item Name: commons-software
+
+Hit **Add Internet Archive item**
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version 8.20210223
+
+linux (ubuntu)
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I recently started trying to use it to manage photos, but I'm struggling a bit to get my head around it.
+Today I'm trying to use it to archive my open source software downloads.
+
+
diff --git a/doc/bugs/error_creating_internet_archive_item_via_web_UI/comment_1_4047d926154b444f33674f4db52be04d._comment b/doc/bugs/error_creating_internet_archive_item_via_web_UI/comment_1_4047d926154b444f33674f4db52be04d._comment
new file mode 100644
index 0000000000..6168e33d67
--- /dev/null
+++ b/doc/bugs/error_creating_internet_archive_item_via_web_UI/comment_1_4047d926154b444f33674f4db52be04d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="dckc@4f72e5f6436280fd19a91a9805af71b9921a4f9b"
+ nickname="dckc"
+ avatar="http://cdn.libravatar.org/avatar/37c748efab0968b1203f146fd1d0e5ae"
+ subject="keep me posted by email please"
+ date="2022-12-07T14:40:52Z"
+ content="""
+I think I neglected to hit the relevant checkbox the 1st time.
+"""]]
diff --git a/doc/bugs/error_during_copy_to_S3.mdwn b/doc/bugs/error_during_copy_to_S3.mdwn
new file mode 100644
index 0000000000..6636abd6ac
--- /dev/null
+++ b/doc/bugs/error_during_copy_to_S3.mdwn
@@ -0,0 +1,40 @@
+### Please describe the problem.
+When copying large files to an S3 special remote, I get a cryptic error message -- what can cause this?
+
+### What steps will reproduce the problem?
+[[!format sh """
+git annex copy --all --to s3_dssi-bioinfo-shlyakhi_sccrispr-data
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+[[!format sh """
+$ git annex version
+git-annex version: 10.20220724-ge30d846
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+$ uname -a
+Linux ctchpcpx212.merck.com 3.10.0-1160.6.1.el7.x86_64 #1 SMP Tue Nov 17 13:59:11 UTC 2020 x86_64 GNU/Linux
+"""]]
+
+### Please provide any additional information below.
+
+[[!format sh """
+copy SHA256E-s67657--d4ab2864cf2d94fb9eeb74721860da93bea55c45194b6c678d5c66040126edfb.csv ok
+copy SHA256E-s10246716468--aa082f7efc476b2903330d57261d16d884653e97e5d007e559ef5ae6a03a52ba.bam (to s3_dssi-bioinfo-shlyakhi_sccrispr-data...) 
+                                      
+  13:1 (567)-13:8 (574): Expected end element for: Name {nameLocalName = "meta", nameNamespace = Nothing, namePrefix = Nothing}, but received: EventEndElement (Name {nameLocalName = "head", nameNamespace = Nothing, namePrefix = Nothing})
+                                      
+                                      
+  13:1 (567)-13:8 (574): Expected end element for: Name {nameLocalName = "meta", nameNamespace = Nothing, namePrefix = Nothing}, but received: EventEndElement (Name {nameLocalName = "head", nameNamespace = Nothing, namePrefix = Nothing})
+failed
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git-annex fills a real need, and none of the alternate tools I've looked at fill it as well.  I've used it at three different workplaces to manage data, and been able to adapt it to every use case.  It also represents a staggering amount of work by one person.
diff --git a/doc/bugs/error_during_copy_to_S3/comment_1_14740dc386510409a8fbda5635eee831._comment b/doc/bugs/error_during_copy_to_S3/comment_1_14740dc386510409a8fbda5635eee831._comment
new file mode 100644
index 0000000000..1f62cd2bcd
--- /dev/null
+++ b/doc/bugs/error_during_copy_to_S3/comment_1_14740dc386510409a8fbda5635eee831._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-24T17:01:17Z"
+ content="""
+This error message is from xml-conduit, which is used by aws
+to parse a response from the S3 server. It seems that response is probably
+malformed XML.
+
+What S3 server is this using?
+
+You may be able to get more information about the http request and response
+by using the --debug flag.
+"""]]
diff --git a/doc/bugs/error_during_copy_to_S3/comment_2_157d4bfcb593cf380445caae0523dbbb._comment b/doc/bugs/error_during_copy_to_S3/comment_2_157d4bfcb593cf380445caae0523dbbb._comment
new file mode 100644
index 0000000000..40b43537f3
--- /dev/null
+++ b/doc/bugs/error_during_copy_to_S3/comment_2_157d4bfcb593cf380445caae0523dbbb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="copying to S3: partsize/chunking"
+ date="2022-08-25T17:45:48Z"
+ content="""
+Re-enabling the remote with `partsize=1GiB` seems to fix the issue.  Maybe, make that the default for S3?
+
+Are there reasons to use `chunk` in addition to `partsize`, or does `partsize` obviate the need for chunking?
+
+"""]]
diff --git a/doc/bugs/error_during_copy_to_S3/comment_3_0e1ed01fc34a5a98c67dd290cb58481f._comment b/doc/bugs/error_during_copy_to_S3/comment_3_0e1ed01fc34a5a98c67dd290cb58481f._comment
new file mode 100644
index 0000000000..ee4aad2da1
--- /dev/null
+++ b/doc/bugs/error_during_copy_to_S3/comment_3_0e1ed01fc34a5a98c67dd290cb58481f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-08-30T16:46:41Z"
+ content="""
+Is this remote configured with chunk? (`git-annex info
+s3_dssi-bioinfo-shlyakhi_sccrispr-data`)
+
+Either chunk or partsize should work. partsize is disabled by default
+because there are a lot of S3 implementations besides AWS, that may not
+support it.
+
+Generally, it's probably better to use partsize rather than chunk if the S3
+server supports it.
+"""]]
diff --git a/doc/bugs/error_on_only_repository_copy_deletion.mdwn b/doc/bugs/error_on_only_repository_copy_deletion.mdwn
new file mode 100644
index 0000000000..7c7be888ed
--- /dev/null
+++ b/doc/bugs/error_on_only_repository_copy_deletion.mdwn
@@ -0,0 +1,16 @@
+**What steps will reproduce the problem?**<br>
+Delete the last repository in the current repository (where it says: warning type in "yes please do as i say").
+Then try running git annex webapp
+<br><br>
+**What is the expected output? What do you see instead?**<br>
+Webapp starts. git-annex: Not in a git repository.
+<br><br>
+**What version of git-annex are you using? On what operating system?**<br>
+4.20130417. Debian wheezy/testing
+<br><br>
+**Please provide any additional information below.**<br>
+See also
+[[bugs/git-annex:_Not_in_a_git_repository._/]]
+where the same error message occurs
+
+[[!tag /design/assistant moreinfo]]
diff --git a/doc/bugs/error_on_only_repository_copy_deletion/comment_1_af394ac0956ab33a77256bcb02ef2a0f._comment b/doc/bugs/error_on_only_repository_copy_deletion/comment_1_af394ac0956ab33a77256bcb02ef2a0f._comment
new file mode 100644
index 0000000000..a60eee1379
--- /dev/null
+++ b/doc/bugs/error_on_only_repository_copy_deletion/comment_1_af394ac0956ab33a77256bcb02ef2a0f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-23T16:39:08Z"
+ content="""
+Do you still have a `~/annex` or `~/Desktop/annex`? What's in there?
+
+Also, please show me the content of your `~/.config/git-annex/autostart` file.
+
+The only bug I have been able to track down is that it fails to remove the repository from the autostart file, and so if the repository directory still exists, this will happen. I've fixed it to properly remove the repository from the file, but hesitate to close this bug as I don't understand how the repository directory could still exist after it's supposed to be deleted. 
+
+(When I try, it does get deleted, and starting the webapp again allows starting over with a new repository.)
+"""]]
diff --git a/doc/bugs/error_out_on_file_size_0_from_external_spec_remote.mdwn b/doc/bugs/error_out_on_file_size_0_from_external_spec_remote.mdwn
new file mode 100644
index 0000000000..a2ad892628
--- /dev/null
+++ b/doc/bugs/error_out_on_file_size_0_from_external_spec_remote.mdwn
@@ -0,0 +1,90 @@
+### Please describe the problem.
+
+Here is a reproducer using the place where I encountered it -- using git-annex-remote-rclone (tiny bash script; needs fixing though for recent rclone -- take from [my fork where I am tuning testing etc](https://github.com/yarikoptic/git-annex-remote-rclone/blob/enh-tests/git-annex-remote-rclone)) [https://github.com/DanielDent/git-annex-remote-rclone/](https://github.com/DanielDent/git-annex-remote-rclone/)
+
+<details>
+<summary>this is a reproducer which creates repo and commits to annex of size 0</summary> 
+
+```bash
+#!/bin/bash
+
+cd "$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)"
+
+set -eux
+
+# provide versioning information to possibly ease troubleshooting
+git annex version
+rclone --version
+
+export HOME=$PWD
+echo -e '[local]\ntype = local\nnounc =' > ~/.rclone.conf
+# to pacify git/git-annex
+git config --global user.name Me
+git config --global user.email me@example.com
+git config --global init.defaultBranch master
+
+# Prepare rclone remote local store
+mkdir rclone-local
+export RCLONE_PREFIX=$PWD/rclone-local
+
+git-annex version
+mkdir testrepo
+cd testrepo
+git init .
+git-annex init
+git-annex initremote GA-rclone-CI type=external externaltype=rclone target=local prefix=$RCLONE_PREFIX chunk=100MiB encryption=shared mac=HMACSHA512
+
+# Rudimentary test, spaces in the filename must be ok, 0 length files should be ok
+
+touch "test 0"
+
+#echo 1 > "test 1"
+
+git-annex add *
+git-annex copy * --to GA-rclone-CI
+git-annex drop *
+git-annex get --debug *
+
+```
+</details> 
+
+where it ends with
+
+```
++ git-annex get --debug 'test 0'
+[2022-06-09 13:16:20.668338168] (Utility.Process) process [1022440] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-files","--stage","-z","--error-unmatch","--","test 0"]
+[2022-06-09 13:16:20.668784836] (Utility.Process) process [1022441] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2022-06-09 13:16:20.669111286] (Utility.Process) process [1022442] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2022-06-09 13:16:20.66965775] (Utility.Process) process [1022443] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2022-06-09 13:16:20.670318546] (Utility.Process) process [1022443] done ExitSuccess
+[2022-06-09 13:16:20.67074703] (Utility.Process) process [1022444] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2022-06-09 13:16:20.671504449] (Utility.Process) process [1022444] done ExitSuccess
+[2022-06-09 13:16:20.672125442] (Utility.Process) process [1022445] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..0da4aa78e4397feb9906400d1e08aaebccac1be1","--pretty=%H","-n1"]
+[2022-06-09 13:16:20.673019668] (Utility.Process) process [1022445] done ExitSuccess
+[2022-06-09 13:16:20.673440353] (Utility.Process) process [1022446] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+get test 0 [2022-06-09 13:16:20.674594171] (Utility.Process) process [1022448] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+(from GA-rclone-CI...) 
+[2022-06-09 13:16:20.682205613] (Annex.Perms) freezing content directory .git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+
+git-annex: .git/annex/tmp/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855: rename: does not exist (No such file or directory)
+failed
+[2022-06-09 13:16:20.682296739] (Utility.Process) process [1022446] done ExitSuccess
+[2022-06-09 13:16:20.682333234] (Utility.Process) process [1022442] done ExitSuccess
+[2022-06-09 13:16:20.682384256] (Utility.Process) process [1022441] done ExitSuccess
+[2022-06-09 13:16:20.682408227] (Utility.Process) process [1022440] done ExitSuccess
+[2022-06-09 13:16:20.682701178] (Utility.Process) process [1022448] done ExitSuccess
+get: 1 failed
+
+```
+
+- you can see that there is not even an attempt to talk to the remote. git-annex crashes before then with that " rename: does not exist (No such file or directory)"
+
+so I do not think it is an issue of the remote (which might also have some size 0 issues from looking at some conditions)
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+tried both 8.20211123 and  10.20220504 from debian 
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_1_6af7ba08e93349b2c6176f91ba25a06f._comment b/doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_1_6af7ba08e93349b2c6176f91ba25a06f._comment
new file mode 100644
index 0000000000..a2ac6c2d01
--- /dev/null
+++ b/doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_1_6af7ba08e93349b2c6176f91ba25a06f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-06-09T17:34:31Z"
+ content="""
+I can reproduce this with a directory special remote, initialized with
+
+	git annex initremote d type=directory directory=../d encryption=shared chunk=100MiB
+
+The chunking is what causes the problem.
+"""]]
diff --git a/doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_2_1d78459554bc12d0423a317bd9f466d1._comment b/doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_2_1d78459554bc12d0423a317bd9f466d1._comment
new file mode 100644
index 0000000000..a37c6f1d06
--- /dev/null
+++ b/doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_2_1d78459554bc12d0423a317bd9f466d1._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-06-09T18:05:15Z"
+ content="""
+This was broken by [[!commit dad4be97c2057db1ef3a13bb983d1701a90c9069]].
+
+For a key of size zero, `addspeculative` adds on a `[]` to the list of chunk
+key. But that causes retrieveChunks to think that it's already retrieved
+all the chunks, so it avoids doing any retrieval, so the file is not
+written. It needs to retrieve the empty key even though it's empty,
+so it can decrypt it when it's encrypted; git-annex does not special case
+empty file retrieval.
+
+Odd that testremote did not detect this. It does test with empty keys, and
+with chunking.
+"""]]
diff --git a/doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_3_aa083a54e0c77cdba9939a061b509488._comment b/doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_3_aa083a54e0c77cdba9939a061b509488._comment
new file mode 100644
index 0000000000..af5678741d
--- /dev/null
+++ b/doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_3_aa083a54e0c77cdba9939a061b509488._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2022-06-09T21:53:05Z"
+ content="""
+
+> fixed in [10.20220525-73-g13fc6a9b6](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=13fc6a9b6ad4f0ee0a783c91825ab7ad35dd2b64) --[[yarikoptic]]
+
+PS I wish there was a similar but automated annotation of those `[done]` to know actually \"when/with what\"
+"""]]
diff --git a/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times.mdwn b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times.mdwn
new file mode 100644
index 0000000000..7321afc811
--- /dev/null
+++ b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+Spotted today in https://github.com/datalad/git-annex/runs/5135259845?check_suite_focus=true
+
+```
+    export_import_subdir:                                 FAIL (0.88s)
+      ./Test/Framework.hs:57:
+      import of subdir failed (transcript follows)
+      list foo ok
+```
+
+and looked through the logs for jan and feb:
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex[master]builds/2022
+$> git -C 01 grep 'export_import_subdir:                             .*FAIL'
+cron-20220127/build-ubuntu.yaml-556-85dd9355-failed/1_test-annex (normal, ubuntu-latest).txt:2022-01-27T02:55:39.3579843Z     export_import_subdir:                                 FAIL (0.88s)
+cron-20220127/build-ubuntu.yaml-556-85dd9355-failed/test-annex (normal, ubuntu-latest)/7_Run tests.txt:2022-01-27T02:55:39.3579807Z     export_import_subdir:                                 FAIL (0.88s)
+cron-20220129/build-ubuntu.yaml-559-85dd9355-failed/1_test-annex (normal, ubuntu-latest).txt:2022-01-29T02:54:18.7490762Z     export_import_subdir:                                 FAIL (0.77s)
+cron-20220129/build-ubuntu.yaml-559-85dd9355-failed/test-annex (normal, ubuntu-latest)/7_Run tests.txt:2022-01-29T02:54:18.7490729Z     export_import_subdir:                                 FAIL (0.77s)
+manual-20220127/build-ubuntu.yaml-557-85dd9355-failed/1_test-annex (normal, ubuntu-latest).txt:2022-01-27T20:19:09.6297697Z     export_import_subdir:                                 FAIL (1.24s)
+manual-20220127/build-ubuntu.yaml-557-85dd9355-failed/test-annex (normal, ubuntu-latest)/7_Run tests.txt:2022-01-27T20:19:09.6297656Z     export_import_subdir:                                 FAIL (1.24s)
+
+$> git -C 02 grep 'export_import_subdir:                             .*FAIL'
+cron-20220202/build-ubuntu.yaml-563-85dd9355-failed/1_test-annex (normal, ubuntu-latest).txt:2022-02-02T02:55:00.5579720Z     export_import_subdir:                                 FAIL (0.74s)
+cron-20220202/build-ubuntu.yaml-563-85dd9355-failed/test-annex (normal, ubuntu-latest)/7_Run tests.txt:2022-02-02T02:55:00.5579682Z     export_import_subdir:                                 FAIL (0.74s)
+cron-20220207/build-ubuntu.yaml-568-85dd9355-failed/1_test-annex (normal, ubuntu-latest).txt:2022-02-07T02:59:10.1650377Z     export_import_subdir:                                 FAIL (1.00s)
+cron-20220207/build-ubuntu.yaml-568-85dd9355-failed/test-annex (normal, ubuntu-latest)/7_Run tests.txt:2022-02-07T02:59:10.1650337Z     export_import_subdir:                                 FAIL (1.00s)
+cron-20220210/build-ubuntu.yaml-571-85dd9355-failed/2_test-annex (crippled-tmp, ubuntu-latest).txt:2022-02-10T02:58:30.1065871Z     export_import_subdir:                                 FAIL (0.88s)
+cron-20220210/build-ubuntu.yaml-571-85dd9355-failed/test-annex (crippled-tmp, ubuntu-latest)/7_Run tests.txt:2022-02-10T02:58:30.1065811Z     export_import_subdir:                                 FAIL (0.88s)
+```
+
+so it fails only some times and primarily in normal, not crippled-tmp setup.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
diff --git a/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_1_cae9d3f611a2b08d47466e5e5c6e80ed._comment b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_1_cae9d3f611a2b08d47466e5e5c6e80ed._comment
new file mode 100644
index 0000000000..ed29b474dc
--- /dev/null
+++ b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_1_cae9d3f611a2b08d47466e5e5c6e80ed._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-18T16:20:10Z"
+ content="""
+This is odd because the test suite says
+that "git-annex import" failed, but its
+output "list foo ok" seems to indicate it succeeded.
+(There is no other output apparently.)
+
+commitRemote outputs "update" when it starts, so it apparently
+never got that far. Seems to leave a failure in importKeys
+that somehow crashes it without an error message.
+
+I can't think of a way that git-annex could crash without an error message,
+unless it was an external problem eg a SIGEGV or OOM killer or something like
+that.
+"""]]
diff --git a/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_2_8cfd20ada49f2441ad305b2225a738bb._comment b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_2_8cfd20ada49f2441ad305b2225a738bb._comment
new file mode 100644
index 0000000000..ff119adde7
--- /dev/null
+++ b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_2_8cfd20ada49f2441ad305b2225a738bb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-05-05T16:03:03Z"
+ content="""
+I checked on smaug, and there have been no new failures of this type
+since this bug was reported.
+"""]]
diff --git a/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_3_6b3e21c80fd75d153282cd4170f4b9d2._comment b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_3_6b3e21c80fd75d153282cd4170f4b9d2._comment
new file mode 100644
index 0000000000..cea1fea30b
--- /dev/null
+++ b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_3_6b3e21c80fd75d153282cd4170f4b9d2._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="it is still there"
+ date="2022-05-05T20:22:13Z"
+ content="""
+each month is a submodule, so the most recent one seems to be from 2 weeks ago
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex[master]builds/2022
+$> git -C 05 grep 'export_import_subdir:.*FAIL'
+
+$> git -C 04 grep 'export_import_subdir:.*FAIL'
+cron-20220424/build-ubuntu.yaml-671-0346631d-failed/1_test-annex (normal, ubuntu-latest).txt:2022-04-24T03:08:45.8548538Z     export_import_subdir:                  FAIL (1.16s)
+cron-20220424/build-ubuntu.yaml-671-0346631d-failed/test-annex (normal, ubuntu-latest)/7_Run tests.txt:2022-04-24T03:08:45.8548535Z     export_import_subdir:                  FAIL (1.16s)
+git -C 04 grep 'export_import_subdir:.*FAIL'  5.08s user 2.04s system 369% cpu 1.927 total
+```
+
+and there were a few in march (do with `-C 03`)
+"""]]
diff --git a/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_4_e49f6175def95abcd353708acbfc3519._comment b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_4_e49f6175def95abcd353708acbfc3519._comment
new file mode 100644
index 0000000000..c82014e495
--- /dev/null
+++ b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_4_e49f6175def95abcd353708acbfc3519._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-06-02T16:09:03Z"
+ content="""
+There is now a later failure:
+
+	cron-20220527/build-ubuntu.yaml-710-90215d4e-failed/2_test-annex (crippled-tmp, ubuntu-latest).txt:2022-05-27T03:27:10.4794513Z     export_import_subdir:                  FAIL (1.04s)
+	cron-20220527/build-ubuntu.yaml-710-90215d4e-failed/test-annex (crippled-tmp, ubuntu-latest)/7_Run tests.txt:2022-05-27T03:27:10.4794510Z     export_import_subdir:                  FAIL (1.04s)
+
+Which was git-annex version 10.20220525+git3-gf69c6a360. Unfortunately
+that means that the fix for [[todo/test_suite_unsafe_use_of_setEnv]]
+did not fix this.
+
+Also, the failures go back to before test suite parellization.
+"""]]
diff --git a/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_5_45a95910d34d602a916282e4e8ec9a08._comment b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_5_45a95910d34d602a916282e4e8ec9a08._comment
new file mode 100644
index 0000000000..1949a07e0c
--- /dev/null
+++ b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_5_45a95910d34d602a916282e4e8ec9a08._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-09-13T17:19:46Z"
+ content="""
+See also [[bugs/some_conflict_resolution_tests_fail_some_time]]
+which has a similar apparent crash in the middle of a git-annex command w/o
+an error.
+"""]]
diff --git a/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_6_78b6f81f900fb4d28808005d223a9da8._comment b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_6_78b6f81f900fb4d28808005d223a9da8._comment
new file mode 100644
index 0000000000..980c163c7e
--- /dev/null
+++ b/doc/bugs/export__95__import__95__subdir_started_to_fail_some_times/comment_6_78b6f81f900fb4d28808005d223a9da8._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-09-13T17:21:54Z"
+ content="""
+Occurs to me that it could be that a bug in processTranscript is preventing
+the test framework from showing all the output of a git-annex command
+when it has exited unsuccessfully.
+
+In both this and the other seemingly similar bug, the transcript ends after
+a line of output, with another expected line of output not showing up.
+
+Since processTranscript uses hGetLineUntilExitOrEOF, a bug in that
+could mean it stops reading buffered output between lines like that.
+
+But, I have not been able to find such a bug in hGetLineUntilExitOrEOF
+so far. By either trying a process that buffers multiline output before
+exiting, or by inspection. And even if it were buggy, something would still
+be making the `git-annex import` command fail unexpectedly.
+"""]]
diff --git a/doc/bugs/export_doesn__39__t_copy_from_adjusted_branch.mdwn b/doc/bugs/export_doesn__39__t_copy_from_adjusted_branch.mdwn
new file mode 100644
index 0000000000..7cf57892e8
--- /dev/null
+++ b/doc/bugs/export_doesn__39__t_copy_from_adjusted_branch.mdwn
@@ -0,0 +1,35 @@
+### Please describe the problem.
+
+Exporting to a directory remote with exporttree=yes works if the source repository is not on an adjusted branch.
+
+
+If, before the export, git annex adjust is invoked with --unlock or --lock (the only two I tested) the new files are not copied.
+
+FWIW, annex.adjustedbranchrefresh is set true.
+
+### What steps will reproduce the problem?
+
+git annex export --json-progress --to export-special-remote main:Music
+
+### What version of git-annex are you using? On what operating system?
+
+10.20231228-g5540f42e21afce6947d5410c5f18b178de6c336a
+
+on Linux
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, I am developing the easy-git-annex interface.
+
+> Considering this not a bug as explained in my comment. [[done]]
+> --[[Joey]]
diff --git a/doc/bugs/export_doesn__39__t_copy_from_adjusted_branch/comment_1_5ff140be453458e84bd6072594e70d8a._comment b/doc/bugs/export_doesn__39__t_copy_from_adjusted_branch/comment_1_5ff140be453458e84bd6072594e70d8a._comment
new file mode 100644
index 0000000000..cee7fdf6d3
--- /dev/null
+++ b/doc/bugs/export_doesn__39__t_copy_from_adjusted_branch/comment_1_5ff140be453458e84bd6072594e70d8a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-02-05T18:06:59Z"
+ content="""
+You have to `git-annex sync` (or `push`) first to get your changes
+propagated from the adjusted branch to the main branch that you are
+exporting.
+
+(You could alternatively export the adjusted branch itself.)
+
+This is the same as if you tried `git push main origin` when on an adjusted
+branch. It would surely not be a bug that doesn't push changes you have
+only committed to the adjusted branch. So I think it's reasonable for the
+export workflow to need the same step that the git push workflow needs.
+"""]]
diff --git a/doc/bugs/exporttree_interaction_with_adjusted_branch.mdwn b/doc/bugs/exporttree_interaction_with_adjusted_branch.mdwn
new file mode 100644
index 0000000000..e3f603e774
--- /dev/null
+++ b/doc/bugs/exporttree_interaction_with_adjusted_branch.mdwn
@@ -0,0 +1,9 @@
+When on an adjusted branch, git annex sync --content with an exportree
+remote that  should commit changes, merge back to master, and then when
+the remote's annex-tracking-branch is master, the updated master should be
+exported to the remote.
+
+I'm told there's a one sync lag in changes reaching the remote. Ie, it's
+exporting to the remote before merging adjusted/master into master, or
+something like that. Have not verified and it could be some other root
+cause than that. --[[Joey]]
diff --git a/doc/bugs/external_remote_export_sent_to_wrong_process.mdwn b/doc/bugs/external_remote_export_sent_to_wrong_process.mdwn
new file mode 100644
index 0000000000..193f5c00f7
--- /dev/null
+++ b/doc/bugs/external_remote_export_sent_to_wrong_process.mdwn
@@ -0,0 +1,87 @@
+### Please describe the problem.
+
+When getting a lot of objects from an external special remote of the exporttree kind,
+sometimes the `EXPORT` command is sent to a different process of the external remote
+than the following `TRANSFEREXPORT` command.
+
+As a result, one process receives two `EXPORT`s in a row, the first of which it ignores,
+while some other process receives a `TRANSFEREXPORT` without a prior `EXPORT`,
+reusing whatever filename was set in the previous transaction,
+and either ovewriting the last accessed remote file with the wrong content,
+or retrieving the content of the last accessed remote file instead of the one git-annex wanted.
+
+Or I misunderstood the protocol - please tell me if that's the case.
+
+### What steps will reproduce the problem?
+
+I don't have a minimal reproducing example.
+
+I was working on adding tree export support to git-annex-remote-rclone,
+and its the testsuite on my branch can reproduce the problem around half of the time, but only on MacOS.
+It seems like it's a race condition and the interleaving that triggers it doesn't happen on Linux
+
+Here's an example test run when it fails 
+[on github](https://github.com/Wolf480pl/git-annex-remote-rclone/actions/runs/4525558194/jobs/7970140554)
+
+and the test code - [on github](https://github.com/Wolf480pl/git-annex-remote-rclone/blob/bd1a497fca8614286ec290bb557c83442c0e23c9/tests/all-in-one.sh#L224)
+(I'd post it as an attachment but I'm getting an error that only admin can upload attachments).
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20230227
+OS: macOS 12.6.3 21G419
+
+### Please provide any additional information below.
+
+Full log is quite long so I put it in a [github gist](https://gist.github.com/Wolf480pl/4bdc83e23154827aad46e84bad631419).
+I wanted to upload it as an attachment but apparently I'm not allowed.
+
+Here are the interesting parts:
+
+First, during the tree export, we see an example of correct upload of the `test 9.dat` and `test 10.dat` files:
+[[!format txt """
+2023-03-26T16:34:52.2551390Z [2023-03-26 16:34:52.085377] (Annex.ExternalAddonProcess) /Users/runner/work/git-annex-remote-rclone/git-annex-remote-rclone/git-annex-remote-rclone[3] <-- EXPORT test 9.dat
+2023-03-26T16:34:52.2653060Z [2023-03-26 16:34:52.086085] (Annex.ExternalAddonProcess) /Users/runner/work/git-annex-remote-rclone/git-annex-remote-rclone/git-annex-remote-rclone[3] <-- TRANSFEREXPORT STORE SHA256E-s7--a30e9d26ce633b40da3ba8cd8806b9b349cb6c3de6816c6d64f85a571012a973.dat .git/annex/objects/zZ/kw/SHA256E-s7--a30e9d26ce633b40da3ba8cd8806b9b349cb6c3de6816c6d64f85a571012a973.dat/SHA256E-s7--a30e9d26ce633b40da3ba8cd8806b9b349cb6c3de6816c6d64f85a571012a973.dat
+[...]
+2023-03-26T16:34:49.9382650Z [2023-03-26 16:34:49.629684] (Annex.ExternalAddonProcess) /Users/runner/work/git-annex-remote-rclone/git-annex-remote-rclone/git-annex-remote-rclone[3] <-- EXPORT test 10.dat
+2023-03-26T16:34:49.9384770Z [2023-03-26 16:34:49.629761] (Annex.ExternalAddonProcess) /Users/runner/work/git-annex-remote-rclone/git-annex-remote-rclone/git-annex-remote-rclone[3] <-- TRANSFEREXPORT STORE SHA256E-s8--d5624694cf1515bdf8c3a648ae35d64f4bdff934800a22a070c6d0baddc120b0.dat .git/annex/objects/6k/X3/SHA256E-s8--d5624694cf1515bdf8c3a648ae35d64f4bdff934800a22a070c6d0baddc120b0.dat/SHA256E-s8--d5624694cf1515bdf8c3a648ae35d64f4bdff934800a22a070c6d0baddc120b0.dat
+"""]]
+
+so we know that key of `test 9.dat` is `a30e...973.dat`, and for `test 10.dat` it's `d56...0b0.dat`
+
+Then, during the get, we see the bug happen:
+[[!format txt """
+2023-03-26T16:34:55.4392510Z [2023-03-26 16:34:54.534833] (Annex.ExternalAddonProcess) /Users/runner/work/git-annex-remote-rclone/git-annex-remote-rclone/git-annex-remote-rclone[5] --> TRANSFER-SUCCESS RETRIEVE SHA256E-s8--fbb0a327e1528cdb3214abb2ec3fb1dd97cc39dfc12751df102eca019f602e73.dat
+2023-03-26T16:34:55.4394480Z [2023-03-26 16:34:54.53532] (Annex.Perms) freezing content .git/annex/objects/45/Gp/SHA256E-s8--91d9183c1a8f61526ed68c5357d52a719481ccbba5039f815cf8f71ae4edbf24.dat/SHA256E-s8--91d9183c1a8f61526ed68c5357d52a719481ccbba5039f815cf8f71ae4edbf24.dat
+2023-03-26T16:34:55.4395900Z [2023-03-26 16:34:54.545524] (Annex.Branch) read b51/a3b/SHA256E-s7--a30e9d26ce633b40da3ba8cd8806b9b349cb6c3de6816c6d64f85a571012a973.dat.log
+2023-03-26T16:34:55.4397280Z [2023-03-26 16:34:54.545836] (Annex.Perms) freezing content directory .git/annex/objects/45/Gp/SHA256E-s8--91d9183c1a8f61526ed68c5357d52a719481ccbba5039f815cf8f71ae4edbf24.dat
+2023-03-26T16:34:55.4398630Z [2023-03-26 16:34:54.54609] (Annex.Branch) read 253/975/SHA256E-s8--91d9183c1a8f61526ed68c5357d52a719481ccbba5039f815cf8f71ae4edbf24.dat.log
+2023-03-26T16:34:55.4399950Z [2023-03-26 16:34:54.5477] (Annex.Branch) set 253/975/SHA256E-s8--91d9183c1a8f61526ed68c5357d52a719481ccbba5039f815cf8f71ae4edbf24.dat.log
+2023-03-26T16:34:55.4401900Z [2023-03-26 16:34:54.558828] (Annex.ExternalAddonProcess) /Users/runner/work/git-annex-remote-rclone/git-annex-remote-rclone/git-annex-remote-rclone[2] --> TRANSFER-SUCCESS RETRIEVE SHA256E-s7--b163189df1a08d63ba85e1566799cf07ca2de3865ac97a85b2b2d0cbfbd9a2f3.dat
+2023-03-26T16:34:55.4403360Z [2023-03-26 16:34:54.559391] (Annex.Branch) read c9a/21e/SHA256E-s8--128888bb8975fc51a7fd410322b088593e158b37a24973483da2ad17fb6d7ff5.dat.log
+2023-03-26T16:34:55.4405510Z [2023-03-26 16:34:54.561866] (Annex.ExternalAddonProcess) /Users/runner/work/git-annex-remote-rclone/git-annex-remote-rclone/git-annex-remote-rclone[2] <-- EXPORT test 9.dat
+2023-03-26T16:34:55.4407810Z [2023-03-26 16:34:54.561942] (Annex.ExternalAddonProcess) /Users/runner/work/git-annex-remote-rclone/git-annex-remote-rclone/git-annex-remote-rclone[2] <-- EXPORT test 10.dat
+2023-03-26T16:34:55.4409480Z [2023-03-26 16:34:54.561946] (Annex.ExternalAddonProcess) /Users/runner/work/git-annex-remote-rclone/git-annex-remote-rclone/git-annex-remote-rclone[5] <-- TRANSFEREXPORT RETRIEVE SHA256E-s7--a30e9d26ce633b40da3ba8cd8806b9b349cb6c3de6816c6d64f85a571012a973.dat .git/annex/tmp/SHA256E-s7--a30e9d26ce633b40da3ba8cd8806b9b349cb6c3de6816c6d64f85a571012a973.dat
+2023-03-26T16:34:55.4411390Z [2023-03-26 16:34:54.562032] (Annex.ExternalAddonProcess) /Users/runner/work/git-annex-remote-rclone/git-annex-remote-rclone/git-annex-remote-rclone[2] <-- TRANSFEREXPORT RETRIEVE SHA256E-s8--d5624694cf1515bdf8c3a648ae35d64f4bdff934800a22a070c6d0baddc120b0.dat .git/annex/tmp/SHA256E-s8--d5624694cf1515bdf8c3a648ae35d64f4bdff934800a22a070c6d0baddc120b0.dat
+"""]]
+
+As you can see in the last 4 lines:
+
+ * process 2 got `EXPORT test 9.dat` and then immediately `EXPORT test 10.dat`
+ * then process 5 got the `TRANSFEREXPORT` command for the `test 9.dat` file (`a30..973.dat`)
+   * process 5 did not, prior to this transfer, receive any `EXPORT` command since its last transfer of an unrelated file (see `TRANSFER-SUCCESS` in the first quoted line).
+   * so it was still holding the old filename from that unrelated transfer
+ * then, process 2 receives a (correct) `TRANSFEREXPORT` for the `test 10.dat` file (`d56...0b0.dat`).
+
+It appears that the `EXPORT test 9.dat` should've been sent to process 5 instead of process 2.
+But since it wasn't, process 5 retrieved the wrong file into what git-annex expected to be `test 9.dat`.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I really wanted to use git annex for my media storage, it seems like the project I've been looking for for years.
+
+But I first needed to be able to exporttree over FTP.
+(I have a cheap NAS is terribly slow at encryption (SSH, etc) so I'm using FTP to get reasonable speeds with it.)
+So I thought I'd implement it and then hit this bug.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/external_remote_export_sent_to_wrong_process/comment_1_831bdc33451de9ef5c54592a7455683f._comment b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_1_831bdc33451de9ef5c54592a7455683f._comment
new file mode 100644
index 0000000000..f4c5189082
--- /dev/null
+++ b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_1_831bdc33451de9ef5c54592a7455683f._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-28T18:35:23Z"
+ content="""
+Looking at the code, handleRequestExport first uses
+withExternalState to send EXPORT, and then it calls
+handleRequestKey to send the following command. That uses
+withExternalState a second time.
+
+withExternalState operates on a pool of processes, so in a race
+(when using -J presumably, as your test case does), the two
+calls to it can use different externals. And so the bug.
+
+Was easy to fix based on that analysis. I have not tried to reproduce it,
+but am confident that I fixed it in
+[[!commit 02662f52920e84cd9464641ada84f6c3bbe3f86a]]
+
+----
+
+In your implementation, you're keeping EXPORT set after handling TRANSFEREXPORT
+and similar commands, and so if you receive a TRANSFEREXPORT not prefixed by an
+EXPORT, it can be bad. A natural way to write things, indeed 
+`doc/special_remotes/external/example.sh` does the same.
+
+An alternative implementation would be to clear the EXPORT after handling a 
+TRANSFEREXPORT, CHECKPRESENTEXPORT, REMOVEEXPORT, or RENAMEEXPORT.
+And have those error out if no EXPORT was received before them.
+
+But, that does not fully avoid the data loss problem. Because this might
+happen:
+
+	EXPORT foo
+	EXPORT bar
+	TRANSFEREXPORT STORE $foo_key $foo_file
+
+So even ignoring the first EXPORT can result in the external special remote
+doing the wrong thing. To fully guard against it, you'd have to error out
+if multiple EXPORT were received before a request that uses one, rather
+than ignoring the first EXPORT.
+
+So, fixing this in your remote and others would need significant defensive
+coding. Too much to make sense, IMHO. I think git-annex needs to chnge the
+protocol in some way instead, to make it easy for you to avoid speaking to
+a buggy git-annex.
+"""]]
diff --git a/doc/bugs/external_remote_export_sent_to_wrong_process/comment_2_8ff0638891c38f423d792f5c3cbfb64f._comment b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_2_8ff0638891c38f423d792f5c3cbfb64f._comment
new file mode 100644
index 0000000000..ce766cb387
--- /dev/null
+++ b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_2_8ff0638891c38f423d792f5c3cbfb64f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-03-28T19:29:01Z"
+ content="""
+What about simply increasing the protocol version number? If VERSION 2 is
+the same as VERSION 1, but only supported by the fixed git-annex, then an
+external can just be updated to send VERSION 2, and it does not need to
+worry about talking with a buggy version of git-annex.
+
+git-annex could either continue to also support VERSION 1, or it could
+refuse to work with externals that don't use VERSION 2. The latter would
+force externals to get updated. But then those externals would have no way to work
+with old git-annex even if they wanted to. I think forcing an update is not called
+for. So git-annex will keep supporting both versions.
+"""]]
diff --git a/doc/bugs/external_remote_export_sent_to_wrong_process/comment_3_d774a7319bd1a1778adb2004229f057e._comment b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_3_d774a7319bd1a1778adb2004229f057e._comment
new file mode 100644
index 0000000000..5f8d9eef55
--- /dev/null
+++ b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_3_d774a7319bd1a1778adb2004229f057e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-03-28T20:51:40Z"
+ content="""
+I've implemented support for `VERSION 2`. Recommend any external special
+remotes that support exporttree=yes use it to avoid talking with a buggy
+git-annex version.
+
+(See [[todo/better_message_for_external_special_remote_protocol_mismatch]]
+for related todo.)
+"""]]
diff --git a/doc/bugs/external_remote_export_sent_to_wrong_process/comment_4_db89603335995755d145141705ac4584._comment b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_4_db89603335995755d145141705ac4584._comment
new file mode 100644
index 0000000000..fa9eff74b1
--- /dev/null
+++ b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_4_db89603335995755d145141705ac4584._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="wolf480@8ad1ccdd08efc303a88f7e88c4e629be6637a44e"
+ nickname="wolf480"
+ avatar="http://cdn.libravatar.org/avatar/816b19ee786208f3216fe146d7733086"
+ subject="comment 4"
+ date="2023-03-30T17:33:10Z"
+ content="""
+Hmm but a remote only learns that it's being used with exporttree=yes *after* it has sent a `VERSION`?
+
+I'm afraid I can't bump the version in case of git-annex-remote-rclone, it's already widely used for non-exporttree scenarios and requiring a git-annex that supports `VERSION 2` for these existing usecases (which aren't affected by this bug) would be a regression...
+
+I'll ask git-annex-remote-rclone maintainers, but it seems to me that defensive coding around the `EXPORT` command is gonna be a better solution in this remote's case.
+"""]]
diff --git a/doc/bugs/external_remote_export_sent_to_wrong_process/comment_5_48656a34262fce77ac50836d1d38b9fe._comment b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_5_48656a34262fce77ac50836d1d38b9fe._comment
new file mode 100644
index 0000000000..e2d96b7ecf
--- /dev/null
+++ b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_5_48656a34262fce77ac50836d1d38b9fe._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="wolf480@8ad1ccdd08efc303a88f7e88c4e629be6637a44e"
+ nickname="wolf480"
+ avatar="http://cdn.libravatar.org/avatar/816b19ee786208f3216fe146d7733086"
+ subject="comment 5"
+ date="2023-03-30T17:33:58Z"
+ content="""
+Oh, also many thanks for quickly fixing this!
+"""]]
diff --git a/doc/bugs/external_remote_export_sent_to_wrong_process/comment_6_e38b776c73affdbb06f3debdddb07e59._comment b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_6_e38b776c73affdbb06f3debdddb07e59._comment
new file mode 100644
index 0000000000..de7cd4053d
--- /dev/null
+++ b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_6_e38b776c73affdbb06f3debdddb07e59._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-03-31T16:55:49Z"
+ content="""
+What if I made git-annex send "EXTENSIONS PROTOCOLVERSION2"? Then
+you could reply to EXPORTSUPPORTED with EXPORTSUPPORTED-FAILURE
+when used by a buggy git-annex.
+"""]]
diff --git a/doc/bugs/external_remote_export_sent_to_wrong_process/comment_7_6a85fcfa3eb0b4974733a62bcc0bbab2._comment b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_7_6a85fcfa3eb0b4974733a62bcc0bbab2._comment
new file mode 100644
index 0000000000..a633b3828a
--- /dev/null
+++ b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_7_6a85fcfa3eb0b4974733a62bcc0bbab2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="wolf480@8ad1ccdd08efc303a88f7e88c4e629be6637a44e"
+ nickname="wolf480"
+ avatar="http://cdn.libravatar.org/avatar/816b19ee786208f3216fe146d7733086"
+ subject="comment 7"
+ date="2023-04-01T07:23:18Z"
+ content="""
+So basically I'd reply to it with `EXTENSIONS PROTOCOLVERSION2`, and then set a flag that supporting export is ok?
+And `EXTENSIONS` always comes before `EXPORTSUPPORTED` ?
+Sounds like a very ad-hoc use of the extension mechanism... I think it'd work but I'd feel bad if you made a release with such a feature and then it turned out it doesn't work...
+Do you have some sort of per-releases?
+"""]]
diff --git a/doc/bugs/external_remote_export_sent_to_wrong_process/comment_8_c4610009f691ce60940979b73bef4d78._comment b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_8_c4610009f691ce60940979b73bef4d78._comment
new file mode 100644
index 0000000000..97fc92bed5
--- /dev/null
+++ b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_8_c4610009f691ce60940979b73bef4d78._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-04-04T18:26:29Z"
+ content="""
+You would not need to send back `EXTENSIONS PROTOCOLVERSION2`
+yourself, only check if git-annex sends it. A better name might be 
+EXPORTBUGFIXED, it's only using the existing extensions mechanism as a flag
+to communicate that git-annex has the bug fixed.
+
+Some old versions of git-annex don't send EXTENSIONS at all (and those
+also don't have the bug fixed), but if git-annex does send it, it will
+always be before EXPORTSUPPORTED.
+"""]]
diff --git a/doc/bugs/external_remote_protocol_unable_to_parse_command.mdwn b/doc/bugs/external_remote_protocol_unable_to_parse_command.mdwn
new file mode 100644
index 0000000000..2b15892c4a
--- /dev/null
+++ b/doc/bugs/external_remote_protocol_unable_to_parse_command.mdwn
@@ -0,0 +1,33 @@
+### Please describe the problem.
+
+I'm writing an [external special remote](/design/external_special_remote_protocol) and am unable to send GETSTATE in response to CHECKPRESENT, e.g.
+
+[[!format sh """
+copy foo [2022-03-21 12:31:22.499943048] (Utility.Process) process [3998210] chat: /home/ben/go/bin/git-annex-remote-blah []
+[2022-03-21 12:31:22.503831297] (Annex.ExternalAddonProcess) /home/ben/go/bin/git-annex-remote-blah[1] --> VERSION 1
+[2022-03-21 12:31:22.503974302] (Annex.ExternalAddonProcess) /home/ben/go/bin/git-annex-remote-blah[1] <-- EXTENSIONS INFO GETGITREMOTENAME ASYNC
+[2022-03-21 12:31:22.504199734] (Annex.ExternalAddonProcess) /home/ben/go/bin/git-annex-remote-blah[1] --> UNSUPPORTED-REQUEST
+[2022-03-21 12:31:22.50428745] (Annex.ExternalAddonProcess) /home/ben/go/bin/git-annex-remote-blah[1] <-- PREPARE
+[2022-03-21 12:31:22.504410356] (Annex.ExternalAddonProcess) /home/ben/go/bin/git-annex-remote-blah[1] --> GETCREDS auth_token
+[2022-03-21 12:31:22.504586934] (Annex.ExternalAddonProcess) /home/ben/go/bin/git-annex-remote-blah[1] <-- CREDS  ellided
+[2022-03-21 12:31:22.504764648] (Annex.ExternalAddonProcess) /home/ben/go/bin/git-annex-remote-blah[1] --> PREPARE-SUCCESS
+[2022-03-21 12:31:22.504835875] (Annex.ExternalAddonProcess) /home/ben/go/bin/git-annex-remote-blah[1] <-- CHECKPRESENT SHA256E-s19--3b99fd544e5e49915ca060f193c615caf82a045b1145672dd6f2181473fd516d
+[2022-03-21 12:31:22.504954457] (Annex.ExternalAddonProcess) /home/ben/go/bin/git-annex-remote-blah[1] --> GETSTATE foo
+
+  external special remote protocol error, unexpectedly received "GETSTATE foo" (unable to parse command)
+[2022-03-21 12:31:22.510269196] (Utility.Process) process [3998217] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+(unable to use special remote due to protocol error) failed
+"""]]
+
+Have I misunderstood the protocol or is this a bug?
+
+### What version of git-annex are you using? On what operating system?
+
+10.20220128-g7e9ebea91 on Debian
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I use git-annex successfully constantly and have done for years. :-) First time writing a special external remote, though.
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/external_remote_protocol_unable_to_parse_command/comment_1_a10012aa7df76a2366ea40da8c37b798._comment b/doc/bugs/external_remote_protocol_unable_to_parse_command/comment_1_a10012aa7df76a2366ea40da8c37b798._comment
new file mode 100644
index 0000000000..4dd1650617
--- /dev/null
+++ b/doc/bugs/external_remote_protocol_unable_to_parse_command/comment_1_a10012aa7df76a2366ea40da8c37b798._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-03-21T17:17:54Z"
+ content="""
+"foo" is not a valid git-annex key, so "GETSTATE foo" is a protocol error.
+
+If you had it send "GETSTATE SHA256E-s19--3b99fd544e5e49915ca060f193c615caf82a045b1145672dd6f2181473fd516d",
+it would work.
+"""]]
diff --git a/doc/bugs/external_remote_protocol_unable_to_parse_command/comment_2_a4556ce5c5f40ca022385cfb3a97ddac._comment b/doc/bugs/external_remote_protocol_unable_to_parse_command/comment_2_a4556ce5c5f40ca022385cfb3a97ddac._comment
new file mode 100644
index 0000000000..1eeb5366da
--- /dev/null
+++ b/doc/bugs/external_remote_protocol_unable_to_parse_command/comment_2_a4556ce5c5f40ca022385cfb3a97ddac._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="bz4"
+ avatar="http://cdn.libravatar.org/avatar/88de97ce728b76df2a27b496ad27af0c"
+ subject="comment 2"
+ date="2022-03-21T19:18:53Z"
+ content="""
+Ah, I see. Thank you!
+"""]]
diff --git a/doc/bugs/fails_to_authenticate_into_S3_for_initremote__63__.mdwn b/doc/bugs/fails_to_authenticate_into_S3_for_initremote__63__.mdwn
new file mode 100644
index 0000000000..c658fb78ce
--- /dev/null
+++ b/doc/bugs/fails_to_authenticate_into_S3_for_initremote__63__.mdwn
@@ -0,0 +1,32 @@
+### Please describe the problem.
+
+```
+(dandisets) dandi@drogon:/mnt/backup/dandi/tmp/dandisets/test-importtree-s3$ AWS_ACCESS_KEY_ID=$(awk '/^access_key/{print $3}' ~/.s3cfg-dandi-backup) AWS_SECRET_ACCESS_KEY=$(awk '/^secret_key/{print $3}' ~/.s3cfg-dandi-backup) git annex initremote s3-origin type=S3 importtree=yes encryption=none autoenable=true bucket=dandiarchive fileprefix=zarr-checksums/2ac71edb-738c-40ac-bd8c-8ca985adaa12/
+initremote s3-origin (checking bucket...) (creating bucket in US...)
+git-annex: S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, s3ErrorCode = "InvalidRequest", s3ErrorMessage = "The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256.", s3ErrorResource = Nothing, s3ErrorHostId = Just "????=", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+failed
+initremote: 1 failed
+
+(dandisets) dandi@drogon:/mnt/backup/dandi/tmp/dandisets/test-importtree-s3$ git annex version
+git-annex version: 10.20220525-gf1fdc90
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+
+```
+
+what exactly does it want from me for AWS4-HMAC-SHA256 ?  here is how those secrets look like (after slight obfuscation):
+
+```
+$ echo AWS_ACCESS_KEY_ID=$(awk '/^access_key/{print $3}' ~/.s3cfg-dandi-backup) AWS_SECRET_ACCESS_KEY=$(awk '/^secret_key/{print $3}' ~/.s3cfg-dandi-backup) | tr 'a-z0-9' '?-?'
+AWS_ACCESS_KEY_ID=AKIA?GIMZPVVE??Y?NKH AWS_SECRET_ACCESS_KEY=/??U??TV?LH?L???KZJ??RF?G???Y+?S??????LM
+```
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+[[!tag moreinfo]]
diff --git a/doc/bugs/fails_to_authenticate_into_S3_for_initremote__63__/comment_1_a7fcd34cf9376e900db832a8010df7d7._comment b/doc/bugs/fails_to_authenticate_into_S3_for_initremote__63__/comment_1_a7fcd34cf9376e900db832a8010df7d7._comment
new file mode 100644
index 0000000000..0096874f3d
--- /dev/null
+++ b/doc/bugs/fails_to_authenticate_into_S3_for_initremote__63__/comment_1_a7fcd34cf9376e900db832a8010df7d7._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-07-13T17:46:54Z"
+ content="""
+That seems to be Signature Version 4. Try adding this to the initremote: signature=v4
+
+Some AWS regions need V4, others still work with V2, which is what it used
+by default. I have not seen the default US region require V4 before.
+Could be something about your AWS access key that needs v4?
+"""]]
diff --git a/doc/bugs/failure_getting__47__copying_on_git-lfs_remote___40__gcrypt__41__.mdwn b/doc/bugs/failure_getting__47__copying_on_git-lfs_remote___40__gcrypt__41__.mdwn
new file mode 100644
index 0000000000..fda8ed98a3
--- /dev/null
+++ b/doc/bugs/failure_getting__47__copying_on_git-lfs_remote___40__gcrypt__41__.mdwn
@@ -0,0 +1,246 @@
+### Please describe the problem.
+
+I'm not sure this is a bug.
+
+We are trying to share a git-lfs special remote on GitLab, encrypted with gcrypt, but one client is getting  "gpg: decryption failed: No secret key" when getting or copying content, but sync works well.
+
+I followed the [private encrypted git remote on a git-lfs hosting site](https://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/#index4h2) guide.
+
+I can sync/add/get git-annex content from the git-lfs special remote (named origin), I can also clone the repository on another machine and get/copy content to origin with no problems.
+
+My collegue (listed in gcryt-participants) is able to clone the repo and sync the remote but he cannot get/add content to it (see below). 
+
+### What steps will reproduce the problem?
+
+Fist I created an new empty project on GitLab
+
+On my machine I created an empty swws-library directory then:
+
+[[!format sh """
+git init
+
+# initialize git annex and set the encrypted git-lfs remote
+git annex init
+git annex initremote origin type=git-lfs url=gcrypt::git@gitlab.com:softwareworkers/swws-library.git keyid=FCE2EDE78BD9B2CB keyid=D37D0EA7CECC3912
+git config remote.origin.gcrypt-participants "D37D0EA7CECC3912 FCE2EDE78BD9B2CB"
+
+git annex sync
+# I had to unprotect the master branch in the GitLab project repository settings and again:
+git annex sync
+
+# Add a couple of media files
+git annex sync --content
+
+
+# All went fine
+"""]]
+
+Then, my collegue (the owner of the FCE2EDE78BD9B2CB gpg key) cloned the repository and:
+
+[[!format sh """
+git annex enableremote origin
+git config remote.origin.gcrypt-participants "D37D0EA7CECC3912 FCE2EDE78BD9B2CB"
+git push origin master git-annex
+git annex sync
+# git annex add <some media>
+git annex sync
+# all is going fine
+"""]]
+
+On my machine I can "git annex sync origin" and get the updated repository, but my collegue cannot get or copy from/to that remote:
+
+[[!format sh """
+a9i@trix:~/Repos/SW/swws-library$ git annex get 
+smarketing/220517_workshop_testuale_part1.mp3
+get smarketing/220517_workshop_testuale_part1.mp3 (from origin...)
+gpg: decryption failed: No secret key
+
+   user error (gpg 
+["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"] 
+exited 2)
+
+   Unable to access these remotes: origin
+
+   Maybe add some of these git remotes (git remote add ...):
+	5e070ec6-adbe-4a60-be06-af60b777d03f -- 
+g@renaissance:~/{git}/softwareworkers.it/swws-library
+failed
+get: 1 failed
+"""]]
+
+This is the debug output when copying annexed files to the origin remote:
+
+[[!format sh """
+  a9i@trix:~/Repos/SW/swws-library$ LC_ALL=C git annex copy --debug --to=origin corsi/
+  [2022-07-18 15:47:28.478299533] (Utility.Process) process [269581] read: 
+  git 
+  ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+  [2022-07-18 15:47:28.480014105] (Utility.Process) process [269581] done 
+  ExitSuccess
+  [2022-07-18 15:47:28.480418294] (Utility.Process) process [269582] read: 
+  git 
+  ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+  [2022-07-18 15:47:28.482213732] (Utility.Process) process [269582] done 
+  ExitSuccess
+  [2022-07-18 15:47:28.491746214] (Utility.Process) process [269583] read: 
+  git 
+  ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..19a97025cc5689891c920766f8fa3ed85fe16229","--pretty=%H","-n1"]
+  [2022-07-18 15:47:28.494757234] (Utility.Process) process [269583] done 
+  ExitSuccess
+  [2022-07-18 15:47:28.496856609] (Utility.Process) process [269584] chat: 
+  git 
+  ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+  [2022-07-18 15:47:28.507245457] (Utility.Process) process [269585] read: 
+  git 
+  ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-files","--stage","-z","--error-unmatch","--","corsi/"]
+  [2022-07-18 15:47:28.509053804] (Utility.Process) process [269586] chat: 
+  git 
+  ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) 
+  %(objecttype) %(objectsize)","--buffer"]
+  [2022-07-18 15:47:28.510594336] (Utility.Process) process [269587] chat: 
+  git 
+  ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) 
+  %(objecttype) %(objectsize)","--buffer"]
+  [2022-07-18 15:47:28.511891608] (Utility.Process) process [269584] done 
+  ExitSuccess
+  [2022-07-18 15:47:28.513074507] (Utility.Process) process [269588] chat: 
+  git 
+  ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) 
+  %(objecttype) %(objectsize)","--buffer"]
+  copy corsi/2022-06-09_Landing-Pages/2022-06-09_Landing-Pages.org 
+  [2022-07-18 15:47:28.524203277] (Utility.Process) process [269590] chat: 
+  gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"]
+  gpg: decryption failed: No secret key
+  [2022-07-18 15:47:28.532883171] (Utility.Process) process [269590] done 
+  ExitFailure 2
+  (user error (gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"] 
+  exited 2)) failed
+  copy corsi/2022-06-09_Landing-Pages/2022-06-09_Landing-Pages.org~ 
+  [2022-07-18 15:47:28.533500984] (Utility.Process) process [269592] chat: 
+  gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"]
+  gpg: decryption failed: No secret key
+  [2022-07-18 15:47:28.540138973] (Utility.Process) process [269592] done 
+  ExitFailure 2
+  (user error (gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"] 
+  exited 2)) failed
+  copy corsi/2022-06-09_Landing-Pages/202206 Formaper - Landing page.pdf 
+  [2022-07-18 15:47:28.540791533] (Utility.Process) process [269594] chat: 
+  gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"]
+  gpg: decryption failed: No secret key
+  [2022-07-18 15:47:28.551983197] (Utility.Process) process [269594] done 
+  ExitFailure 2
+  (user error (gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"] 
+  exited 2)) failed
+  copy corsi/2022-06-09_Landing-Pages/3700213292852724482.mp4 [2022-07-18 
+  15:47:28.554726904] (Utility.Process) process [269596] chat: gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"]
+  gpg: decryption failed: No secret key
+  [2022-07-18 15:47:28.567432702] (Utility.Process) process [269596] done 
+  ExitFailure 2
+  (user error (gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"] 
+  exited 2)) failed
+  copy corsi/2022-06-09_Landing-Pages/6258438201216682752.mp4 [2022-07-18 
+  15:47:28.571835037] (Utility.Process) process [269598] chat: gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"]
+  gpg: decryption failed: No secret key
+  [2022-07-18 15:47:28.579064056] (Utility.Process) process [269598] done 
+  ExitFailure 2
+  (user error (gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"] 
+  exited 2)) failed
+  copy corsi/2022-06-09_Landing-Pages/8959772244561726210.mp4 [2022-07-18 
+  15:47:28.581423831] (Utility.Process) process [269600] chat: gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"]
+  gpg: decryption failed: No secret key
+  [2022-07-18 15:47:28.602507936] (Utility.Process) process [269600] done 
+  ExitFailure 2
+  (user error (gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"] 
+  exited 2)) failed
+  copy corsi/2022-06-09_Landing-Pages/Slide - Landing page efficaci.pdf 
+  [2022-07-18 15:47:28.6080323] (Utility.Process) process [269602] chat: 
+  gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"]
+  gpg: decryption failed: No secret key
+  [2022-07-18 15:47:28.616162922] (Utility.Process) process [269602] done 
+  ExitFailure 2
+  (user error (gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"] 
+  exited 2)) failed
+  copy corsi/2022-06-09_Landing-Pages/Story_mapping.png [2022-07-18 
+  15:47:28.617007178] (Utility.Process) process [269604] chat: gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"]
+  gpg: decryption failed: No secret key
+  [2022-07-18 15:47:28.624214363] (Utility.Process) process [269604] done 
+  ExitFailure 2
+  (user error (gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"] 
+  exited 2)) failed
+  copy corsi/2022-06-09_Landing-Pages/canvas.png [2022-07-18 
+  15:47:28.624826009] (Utility.Process) process [269606] chat: gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"]
+  gpg: decryption failed: No secret key
+  [2022-07-18 15:47:28.634726242] (Utility.Process) process [269606] done 
+  ExitFailure 2
+  (user error (gpg 
+  ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--decrypt"] 
+  exited 2)) failed
+  [2022-07-18 15:47:28.634918681] (Utility.Process) process [269588] done 
+  ExitSuccess
+  [2022-07-18 15:47:28.634986759] (Utility.Process) process [269587] done 
+  ExitSuccess
+  [2022-07-18 15:47:28.635050868] (Utility.Process) process [269586] done 
+  ExitSuccess
+  [2022-07-18 15:47:28.63509396] (Utility.Process) process [269585] done 
+  ExitSuccess
+  copy: 9 failed
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20220624 on Guix on Debian as foreign distro.
+
+### Please provide any additional information below.
+
+This is my collegue (the failing part) git repository configuration:
+
+[[!format sh """
+    [core]
+	    repositoryformatversion = 0
+	    filemode = true
+	    bare = false
+	    logallrefupdates = true
+    [remote "origin"]
+	    url = gcrypt::git@gitlab.com:softwareworkers/swws-library.git
+	    gcrypt-id = :id:Fb42A4B5ODZW/35Z5ZoI
+	    fetch = +refs/heads/*:refs/remotes/origin/*
+	    annex-git-lfs = true
+	    annex-uuid = 9b43bd79-3d24-4e6f-b196-46f5bc67f214
+	    gcrypt-participants = D37D0EA7CECC3912 FCE2EDE78BD9B2CB
+	    gcrypt-publish-participants = true
+	    annex-ignore = false
+    [branch "master"]
+	    remote = origin
+	    merge = refs/heads/master
+    [annex]
+	    uuid = 6a09ad78-19a1-451a-8ab5-fb51d18966eb
+	    version = 8
+    [filter "annex"]
+	    smudge = git-annex smudge -- %f
+	    clean = git-annex smudge --clean -- %f
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Oh yes, I'm using git-annex since many many years ago and it's my preferred storage solution, I really love it!
+
+**Kudos** Joey!
+
+> [[fixed|done]], I think, see my comment --[[Joey]]
diff --git a/doc/bugs/failure_getting__47__copying_on_git-lfs_remote___40__gcrypt__41__/comment_1_ba5b0ed901c99a23ff72d68b83c0d2fa._comment b/doc/bugs/failure_getting__47__copying_on_git-lfs_remote___40__gcrypt__41__/comment_1_ba5b0ed901c99a23ff72d68b83c0d2fa._comment
new file mode 100644
index 0000000000..62bbca6f71
--- /dev/null
+++ b/doc/bugs/failure_getting__47__copying_on_git-lfs_remote___40__gcrypt__41__/comment_1_ba5b0ed901c99a23ff72d68b83c0d2fa._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-15T17:42:49Z"
+ content="""
+I think that the problem is that keyid= can only be specified once,
+so the last keyid= you specified was used, which was yours, and it ignored
+the other one.
+
+Try `git-annex enableremote origin keyid+=FCE2EDE78BD9B2CB`
+
+I found some documentation that says that keyid= can be repeated multiple
+times, and I think that documentation is wrong, and probably led you
+astray. It's also possible that it used to work and was broken in some
+option parsing changes, unsure. I'm working to correct the documentation now.
+
+(Or, encryption=shared seems likely to avoid whatever the problem is.)
+"""]]
diff --git a/doc/bugs/fat_support.mdwn b/doc/bugs/fat_support.mdwn
new file mode 100644
index 0000000000..70ee3b369c
--- /dev/null
+++ b/doc/bugs/fat_support.mdwn
@@ -0,0 +1,13 @@
+Klaus pointed out that there are two problems that keep
+git-annex from being used on USB keys, that would typically
+be VFAT formatted:
+
+- Use of symlinks, which VFAT does not support. Very hard to fix.
+  Instead, just use [[/bare_repositories]] on the key,
+  they're supported now.
+- Use of ":" in filenames of object files, also not supported.
+  Could easily be fixed by reorganizing the object directory.
+
+[[Done]]; in annex.version 2 repos, colons are entirely avoided in
+filenames. So a bare git clone can be put on VFAT, and git-annex
+used to move stuff --to and --from it, for sneakernet.
diff --git a/doc/bugs/fat_support/comment_1_04bcc4795d431e8cb32293aab29bbfe2._comment b/doc/bugs/fat_support/comment_1_04bcc4795d431e8cb32293aab29bbfe2._comment
new file mode 100644
index 0000000000..510e449842
--- /dev/null
+++ b/doc/bugs/fat_support/comment_1_04bcc4795d431e8cb32293aab29bbfe2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="fmarier"
+ ip="121.73.248.43"
+ subject="Exporting to a FAT filesystem?"
+ date="2011-04-04T07:40:41Z"
+ content="""
+I'm using git-annex to keep my music in sync between all of my different machines. What I'd love to be able to do is to also keep it in sync with my iRiver player. Unfortunately, the firmware, Rockbox, doesn't support ext3, so I'm stuck with a FAT filesystem.
+
+I can see how the design of git-annex makes it rather difficult to get rid of the symlinks, so how about taking a different approach: something like a \"git annex export DEST\" which would take a destination (not a git remote) and rsync the content over to there as regular files.
+
+Maybe \"git annex sync DEST\" or \"git annex rsync DEST\" would be better names if we want to convey the idea that the destination will be made to look like the source repo, including performing the necessary deletions.
+"""]]
diff --git a/doc/bugs/fat_support/comment_2_bb4a97ebadb5c53809fc78431eabd7c8._comment b/doc/bugs/fat_support/comment_2_bb4a97ebadb5c53809fc78431eabd7c8._comment
new file mode 100644
index 0000000000..7618c9a7b6
--- /dev/null
+++ b/doc/bugs/fat_support/comment_2_bb4a97ebadb5c53809fc78431eabd7c8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-04-04T18:20:45Z"
+ content="""
+Hey @fmarier. Well, this bug report is closed because you can already get rid of the symlinks. Just put a bare git repo on your fat filesystem, and use git-annex copy --to/--from there.
+
+Now, that puts all the files that are on the device in .git/annex/objects/xx/yy/blah.mp3 -- how well rockbox would support that I don't know. And if it tries to modify or delete those files, git annex also can't help you manage those changes.
+
+Another recent option is the [[special_remotes/directory]] special remote type, which again uses \"xx/yy/blah.mp3\" and can't track changes made to the files. This could perhaps be extended in the direction you suggest, although trying to fit this into the special remote infrastructure might not be a good fit really.
+
+The most likely way this has to get dealt with is really by using [[todo/smudge]] filters, which would eliminate the symlinks and allow copying a non-bare git repo onto vfat. 
+"""]]
diff --git a/doc/bugs/fat_support/comment_3_df3b943bc1081a8f3f7434ae0c8e061e._comment b/doc/bugs/fat_support/comment_3_df3b943bc1081a8f3f7434ae0c8e061e._comment
new file mode 100644
index 0000000000..f3db75c2f6
--- /dev/null
+++ b/doc/bugs/fat_support/comment_3_df3b943bc1081a8f3f7434ae0c8e061e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="fmarier"
+ subject="comment 3"
+ date="2011-04-05T10:00:21Z"
+ content="""
+Thanks for the reply @joey.
+
+While it would certainly be possible for a bare repo to exist on my iRiver, the problem is that the music player uses the filesystem to organize files into directories like \"Artist/Album/Track.ogg\". So replacing that with \"..../xx/yy/Track.ogg\" would make it fairly difficult to browse my music collection and select the album/track I want to listen to :)
+
+So unless I have the files physically organized like the symlinks, then it's probably not going to work very for that particular workflow. Smudge filters are interesting though. In the meantime, I'll look into rsyncing from another box which has the right filesystem layout onto my iRiver directly.
+"""]]
diff --git a/doc/bugs/fat_support/comment_4_90a8a15bedd94480945a374f9d706b86._comment b/doc/bugs/fat_support/comment_4_90a8a15bedd94480945a374f9d706b86._comment
new file mode 100644
index 0000000000..722cbdd9e7
--- /dev/null
+++ b/doc/bugs/fat_support/comment_4_90a8a15bedd94480945a374f9d706b86._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://ethan.betacantrips.com/"
+ nickname="ethan.glasser.camp"
+ subject="no symlinks"
+ date="2011-06-08T20:59:38Z"
+ content="""
+If you try to clone a git repo that has a symlink over to a VFAT filesystem, you get (in its place) a regular file that contains the name of the symlink target.  So why can't git-annex use that?  I could still do git annex get on this file, git annex would still \"know\" that it's a symlink, and could replace it with a copy of the real file (instead of putting it in .git/annex).
+
+I know if it were that simple, someone would have done it already, so what am I missing?  I guess trying to get the file FROM the repository would fail because it wouldn't find the file in .git/annex?  Couldn't you store a reverse mapping?  You wouldn't be able to move the file around, but you already lose that once you give up symlinks.  It would also be a little harder to tell which symlinks were \"dangling\"; I don't see an easy way to get around that.  It would still be better than a bare repo..
+"""]]
diff --git a/doc/bugs/fat_support/comment_5_64bbf89de0836673224b83fdefa0407b._comment b/doc/bugs/fat_support/comment_5_64bbf89de0836673224b83fdefa0407b._comment
new file mode 100644
index 0000000000..1063b0f910
--- /dev/null
+++ b/doc/bugs/fat_support/comment_5_64bbf89de0836673224b83fdefa0407b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 5"
+ date="2011-06-10T16:41:43Z"
+ content="""
+@ethan the reason that wouldn't work is because git would then see a file that was checked in and had its one line symlinkish content replaced with a huge binary blob. And git commit would try to commit that etc. The potential for foot-shooting is too high.
+"""]]
diff --git a/doc/bugs/fat_support/comment_6_a3b6000330c9c376611c228d746a1d55._comment b/doc/bugs/fat_support/comment_6_a3b6000330c9c376611c228d746a1d55._comment
new file mode 100644
index 0000000000..c7defd13ef
--- /dev/null
+++ b/doc/bugs/fat_support/comment_6_a3b6000330c9c376611c228d746a1d55._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkZRoTRyW3tox-FD2DQWxskgI6_tkEtHL4"
+ nickname="Ben"
+ subject="comment 6"
+ date="2012-07-23T16:11:52Z"
+ content="""
+The above would work fine for me but the files in my annex (e.g. .git/annex/objects/xx/yy/blah.ogg) don't have extensions like that, so my media player doesn't recognize them as media files. How do I get the files under \"objects\" to keep the extensions of the original files like in Joey's example?
+"""]]
diff --git a/doc/bugs/fat_support/comment_7_a0ac7f2c44efc8116940c7b94b35e9d0._comment b/doc/bugs/fat_support/comment_7_a0ac7f2c44efc8116940c7b94b35e9d0._comment
new file mode 100644
index 0000000000..11668615e6
--- /dev/null
+++ b/doc/bugs/fat_support/comment_7_a0ac7f2c44efc8116940c7b94b35e9d0._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 7"
+ date="2012-07-24T14:51:50Z"
+ content="""
+You can get the extensions by migrating to the SHA1E (or SHA256E) backend. 
+"""]]
diff --git a/doc/bugs/fat_support/comment_8_acc947643a635eb10a1bff92083a3506._comment b/doc/bugs/fat_support/comment_8_acc947643a635eb10a1bff92083a3506._comment
new file mode 100644
index 0000000000..558e0ca105
--- /dev/null
+++ b/doc/bugs/fat_support/comment_8_acc947643a635eb10a1bff92083a3506._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmcYryijvlF8bJvM_eZNSrUPEkMlxMDGTQ"
+ nickname="Thiago"
+ subject="POSIX layer on top of VFAT using FUSE"
+ date="2012-11-24T00:21:23Z"
+ content="""
+I just found out about this project and didn't try it, but it looks like it would allow using git-annex on an usb stick with a normal repository:
+
+<http://sourceforge.net/projects/posixovl/>
+"""]]
diff --git a/doc/bugs/fatal__58___Cannot_handle_files_this_big.mdwn b/doc/bugs/fatal__58___Cannot_handle_files_this_big.mdwn
new file mode 100644
index 0000000000..7272bfc294
--- /dev/null
+++ b/doc/bugs/fatal__58___Cannot_handle_files_this_big.mdwn
@@ -0,0 +1,96 @@
+### Please describe the problem.
+
+Syncing a 20GB video file causes this error. I have no problems with 8GB files. 
+
+### What steps will reproduce the problem?
+
+See additional info
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20140920-gb0c4300
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 2 3 4
+
+git version 1.9.4.msysgit.2
+
+Windows 7 64bit 
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+Z:\>git clone L:\repositories\bigFilesTest.git-annex
+Cloning into 'bigFilesTest.git-annex'...
+done.
+
+Z:\>cd bigFilesTest.git-annex
+
+Z:\bigFilesTest.git-annex>git annex init "cloned"
+init cloned
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Enabling direct mode.
+ok
+(Recording state in git...)
+
+Z:\bigFilesTest.git-annex>git annex add test20GBVideo.mkv
+add test20GBVideo.mkv ok
+(Recording state in git...)
+
+Z:\bigFilesTest.git-annex>git annex sync --debug
+[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","git-annex"]
+[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--hash","refs/heads/git-annex"]
+[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/heads/git-annex..54de336a3423f7f8f72f897effd29f952534c24e","-n1","--pretty=%H"]
+[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/heads/git-annex..53cfcf38b40247b3992b6007336b2c915a945ad4","-n1","--pretty=%H"]
+[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] chat: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","cat-file","--batch"]
+[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] read: git ["config","--null","--list"]
+commit  [2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","ls-files","--stage","-z","--others","--exclude-standard","--","Z:\\bigFilesTest.git-annex"]
+[2014-10-18 15:39:02 Mitteleuropäische Sommerzeit] chat: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","cat-file","--batch"]
+(Recording state in git...)
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","add","-f","test20GBVideo.mkv"]
+fatal: Cannot handle files this big
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--head"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","diff-index","-z","--raw","--no-renames","-l0","--cached","HEAD"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","symbolic-ref","HEAD"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--hash","refs/heads/annex/direct/master"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","write-tree"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","rev-parse","b12e8477242df97be13c1395db143f860ce8e895:"]
+ok
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","symbolic-ref","HEAD"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","refs/heads/annex/direct/master"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--verify","-q","refs/heads/synced/master"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/heads/annex/direct/master..refs/heads/synced/master","-n1","--pretty=%H"]
+pull origin
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","fetch","origin"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--verify","-q","refs/remotes/origin/annex/direct/master"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--verify","-q","refs/remotes/origin/synced/master"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/heads/synced/master..refs/remotes/origin/synced/master","-n1","--pretty=%H"]
+ok
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","git-annex"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--hash","refs/heads/git-annex"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/heads/git-annex..54de336a3423f7f8f72f897effd29f952534c24e","-n1","--pretty=%H"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/heads/git-annex..53cfcf38b40247b3992b6007336b2c915a945ad4","-n1","--pretty=%H"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","branch","-f","synced/master"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","branch","-f","master"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--verify","-q","refs/remotes/origin/synced/master"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/remotes/origin/synced/master..refs/heads/synced/master","-n1","--pretty=%H"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","show-ref","--verify","-q","refs/remotes/origin/git-annex"]
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","log","refs/remotes/origin/git-annex..git-annex","-n1","--pretty=%H"]
+push origin
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","push","origin","+git-annex:synced/git-annex","annex/direct/master:synced/master"]
+Everything up-to-date
+[2014-10-18 15:39:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=Z:\\bigFilesTest.git-annex\\.git","--work-tree=Z:\\bigFilesTest.git-annex","-c","core.bare=false","push","origin","master"]
+ok
+
+
+
+"""]]
diff --git a/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_1_e4f03a86a7adc6c5421d1e70c37659e0._comment b/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_1_e4f03a86a7adc6c5421d1e70c37659e0._comment
new file mode 100644
index 0000000000..b580cdbe68
--- /dev/null
+++ b/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_1_e4f03a86a7adc6c5421d1e70c37659e0._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-10T17:29:44Z"
+ content="""
+I recently fixed a bug that would
+likewise cause git-annex to fail on windows with a large file, although I
+didn't see it failing with this message.
+
+There's a good chance that git-annex version 5.20150205 might fix this
+problem. 
+
+I was able to successfully use git-annex with a 6 gb file, after the fixes.
+
+Please check, and followup. I'm closing this bug provisionally in the
+meantime.
+"""]]
diff --git a/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_2_546782c644230741470f9a9de23bd019._comment b/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_2_546782c644230741470f9a9de23bd019._comment
new file mode 100644
index 0000000000..0ea9dc4d1d
--- /dev/null
+++ b/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_2_546782c644230741470f9a9de23bd019._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="bvaa"
+ subject="similar problem"
+ date="2016-03-01T08:12:27Z"
+ content="""
+I have a similar problem on Windows 7 64bit trying to add files that are around 5GB in size. I tried repository version 5 and 6 with same results.
+
+```
+$ git annex add bigfile
+add bigfile ok
+(recording state in git...)
+
+$ git annex status
+fatal: Cannot handle files this big
+```
+git-annex version: 6.20160229-g37a89cc
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload) WebDAV ConcurrentOutput TorrentParser Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 5 6
+upgrade supported from repository versions: 2 3 4 5
+
+"""]]
diff --git a/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_3_151e7cf96c7d168e1397d111aa47f279._comment b/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_3_151e7cf96c7d168e1397d111aa47f279._comment
new file mode 100644
index 0000000000..e6ad551e42
--- /dev/null
+++ b/doc/bugs/fatal__58___Cannot_handle_files_this_big/comment_3_151e7cf96c7d168e1397d111aa47f279._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-03-01T14:41:45Z"
+ content="""
+git (not git-annex) will throw this error if a file size is greater than
+`size_t`.
+
+This bug report seemed to originally concern git add being run on such a
+file, but I can't see how git-annex would do that, it doesn't add large
+files to git.
+
+I think that in the case of git-annex status, when it runs git status, that
+looks at work tree files, and so falls over if they're large, even if
+what's checked into git is a nice small git-annex symlink. This would also
+probably affect other places where git looks at worktree files, perhaps git
+diff (in v6 repo mode).
+
+Reopening bug report.
+"""]]
diff --git a/doc/bugs/file_extension_not_used_for_URIs_from_special_remotes/comment_1_3b47ce467eee2b903c0ed40e251d4bc1._comment b/doc/bugs/file_extension_not_used_for_URIs_from_special_remotes/comment_1_3b47ce467eee2b903c0ed40e251d4bc1._comment
new file mode 100644
index 0000000000..6b7b19457a
--- /dev/null
+++ b/doc/bugs/file_extension_not_used_for_URIs_from_special_remotes/comment_1_3b47ce467eee2b903c0ed40e251d4bc1._comment
@@ -0,0 +1,88 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-04T18:58:32Z"
+ content="""
+That would certianly be a bug, but I am not able to reproduce it. 
+
+I used this external special remote program:
+
+	#!/bin/sh
+	set -e
+	runcmd () {
+		"$@" >&2
+	}
+	echo VERSION 1
+	while read line; do
+		set -- $line
+		case "$1" in
+			INITREMOTE)
+				echo INITREMOTE-SUCCESS
+			;;
+			PREPARE)
+				echo PREPARE-SUCCESS
+			;;
+			CLAIMURL)
+				url="$2"
+				echo CLAIMURL-SUCCESS
+			;;
+			CHECKURL)
+				echo CHECKURL-CONTENTS 0 foo.gif
+			;;
+			TRANSFER)
+				op="$2"
+				key="$3"
+				shift 3
+				file="$@"
+				case "$op" in
+					STORE)
+						echo TRANSFER-FAILURE STORE "$key" dummy
+					;;
+					RETRIEVE)
+						touch "$file"
+						echo TRANSFER-SUCCESS RETRIEVE "$key"
+					;;
+				esac
+			;;
+			CHECKPRESENT)
+				key="$2"
+				echo CHECKPRESENT-UNKNOWN "$key" dummy
+			;;
+			REMOVE)
+				key="$2"
+				echo REMOVE-SUCCESS "$key"
+			;;
+			*)
+				echo UNSUPPORTED-REQUEST
+			;;
+		esac	
+	done
+
+That claims all urls, and provides an (empty) .gif file.
+
+Result using it:
+
+	joey@darkstar:/tmp>git init test
+	Initialized empty Git repository in /tmp/test/.git/
+	joey@darkstar:/tmp>cd test
+	joey@darkstar:/tmp/test>git annex init
+	init  ok
+	(recording state in git...)
+	joey@darkstar:/tmp/test>>git annex initremote test type=external externaltype=test ecryption=none
+	initremote test ok
+	(recording state in git...)
+	joey@darkstar:/tmp/test>git annex addurl http://bar/ 
+	addurl http://bar/ (from test) (to foo.gif) 
+	ok
+	(recording state in git...)
+	joey@darkstar:/tmp/test>ls -l foo.gif 
+	lrwxrwxrwx 1 joey joey 186 Oct  4 15:01 foo.gif -> .git/annex/objects/Zp/QG/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.gif/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.gif
+
+Which is as expected, and in the code it downloads the file to the worktree
+and then ingests it from there, so it's handled the same way as a wget and
+a git annex add would be.
+
+It may be that older versions of git-annex behaved differently. I don't 
+know what version you are using. Please always include a version number in
+bug reports.
+"""]]
diff --git a/doc/bugs/file_field_omitted_from_import_--json-progress.mdwn b/doc/bugs/file_field_omitted_from_import_--json-progress.mdwn
new file mode 100644
index 0000000000..ce060104c3
--- /dev/null
+++ b/doc/bugs/file_field_omitted_from_import_--json-progress.mdwn
@@ -0,0 +1,37 @@
+### Please describe the problem.
+
+When importing from a directory special remote created with importtree=yes and the --json-progress option is specified, the file field is omitted from the progress objects.
+
+### What steps will reproduce the problem?
+
+The command
+
+git annex import --from import-special-remote --json-progress main:Music
+
+generates output with the file field omitted from the nested action object in the progress objects on line 2 and 4, below.
+
+### What version of git-annex are you using? On what operating system?
+
+10.20231228-g5540f42e21afce6947d5410c5f18b178de6c336a
+
+on Linux
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+{\"command\":\"list\",\"error-messages\":[],\"input\":[],\"success\":true}
+{\"action\":{\"command\":\"import import-special-remote\",\"input\":[]},\"byte-progress\":9972,\"percent-progress\":\"100%\",\"total-size\":9972}
+{\"command\":\"import import-special-remote\",\"error-messages\":[],\"input\":[],\"success\":true}
+{\"action\":{\"command\":\"import import-special-remote\",\"input\":[]},\"byte-progress\":18,\"percent-progress\":\"100%\",\"total-size\":18}
+{\"command\":\"import import-special-remote\",\"error-messages\":[],\"input\":[],\"success\":true}
+{\"command\":\"update\",\"error-messages\":[],\"input\":[],\"success\":true}
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, I am developing the easy-git-annex interface.
diff --git a/doc/bugs/file_field_omitted_from_import_--json-progress/comment_1_bea5a95e6fe120e1ee8c87ce6c55f161._comment b/doc/bugs/file_field_omitted_from_import_--json-progress/comment_1_bea5a95e6fe120e1ee8c87ce6c55f161._comment
new file mode 100644
index 0000000000..369a46d51f
--- /dev/null
+++ b/doc/bugs/file_field_omitted_from_import_--json-progress/comment_1_bea5a95e6fe120e1ee8c87ce6c55f161._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jstritch"
+ avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
+ subject="comment 1"
+ date="2024-02-01T20:49:12Z"
+ content="""
+I'm not convinced the remote name should appear in the command field of the nested action. The whole point of using JSON is to avoid parsing strings.
+
+Adding a separate field with a string array of the command arguments would be ok, but I'm not requesting it now.
+"""]]
diff --git a/doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field.mdwn b/doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field.mdwn
new file mode 100644
index 0000000000..ae2ddf907f
--- /dev/null
+++ b/doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field.mdwn
@@ -0,0 +1,10 @@
+### Please describe the problem.
+File modification metadata is stored separately as year, month and day according to the annex.genmetadata docs. This makes reading and writing it unnecessarily complicated. Also, every field has its own modification timestamp and two out of the three become meaningless once you change one. (Does the modification time field even need its own modification time field?)
+
+It would be easier to work with if it was represented as a UTC unix timestamp or ISO 8601 string or something similar, ideally something date(1) and/or touch(1) (GNU and BSD) will understand natively. Also, you could fit more precision in there for little cost.
+
+### What steps will reproduce the problem?
+`git annex metadata <any file with modification metadata>`
+
+### What version of git-annex are you using? On what operating system?
+git annex 6.20180227, various Linuxes.
diff --git a/doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_1_7fef3484f3019539c0a305d5f4a801ce._comment b/doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_1_7fef3484f3019539c0a305d5f4a801ce._comment
new file mode 100644
index 0000000000..6d49f7d77a
--- /dev/null
+++ b/doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_1_7fef3484f3019539c0a305d5f4a801ce._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 1"
+ date="2018-03-23T19:01:02Z"
+ content="""
+The year, month and day fields are used when creating views that sort files by modification date, eg. `git annex view year=* month=* day=*`. This cannot be done using timestamps. I agree that an additional timestamp field is a good idea, so I modified the pre-commit-annex hook by adding
+
+    field=\"mtime\"
+    value=$(stat -Lc %Y \"$f\")
+    addmeta \"$f\" \"$field\" \"$value\"
+
+at the end of the process function.
+"""]]
diff --git a/doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_2_32285971869ec56460b3f0eee4edfa23._comment b/doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_2_32285971869ec56460b3f0eee4edfa23._comment
new file mode 100644
index 0000000000..68c177c83b
--- /dev/null
+++ b/doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_2_32285971869ec56460b3f0eee4edfa23._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-04-04T16:40:19Z"
+ content="""
+One use case for the separate fields is `git-annex view`,
+where they allow creating view branches with yyyy/mm/ subdirectories
+or artist/yyyy/ or whatever kind of thing the user wants.
+
+Part of the original metadata design, which never got implemented,
+was to allow pure functions on metadata, that added to the set of available
+metadata. So a unix timestamp could be what's stored in metadata, and then
+the individual fields (and more fields that are currently omitted to avoid
+bloat) derived from it.
+
+I'd be happy to see that part of the metadata design actually happen.
+There are some potential problems with it that need to be thought about,
+such as:
+
+* What should happen if the user runs `git annex metadata` to change
+  or delete such a derived metadata field?
+* If a unix timestamp is stored, it's harder for the user to make
+  some simple edit, such as adjusting the year of a file to the year they
+  want. Should a change to a derived year field propigate back to the unix
+  timestamp? (Would need reversible functions.)
+
+(BTW, the timestamps on metadata fields come for "free" in that the
+underlying metadata storage log necessarily contains timestamps of when
+each part of the metadata was changed.)
+"""]]
diff --git a/doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_3_7bf423111829ec6b358c6925d012a3e2._comment b/doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_3_7bf423111829ec6b358c6925d012a3e2._comment
new file mode 100644
index 0000000000..8c5973f255
--- /dev/null
+++ b/doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_3_7bf423111829ec6b358c6925d012a3e2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="vrs+annex@ea5fa24dbb279be61a8e50adb638bf8366300717"
+ nickname="vrs+annex"
+ avatar="http://cdn.libravatar.org/avatar/74219abcec6eece8e2c9d4351c2c912c"
+ subject="comment 3"
+ date="2018-04-05T02:11:41Z"
+ content="""
+If pure functions were part of the design anyway, why not avoid adding derived fields and introduce functions like `year()` etc instead? The semantics would be obvious (you don't assign to a function call) and existing workflows involving the year field would keep working.
+
+As for editing the timestamp in general, I'll post an answer to <https://git-annex.branchable.com/bugs/proposal_for_timestamp_semantics/> later that should address this.
+"""]]
diff --git a/doc/bugs/filemanager_integration_broken.mdwn b/doc/bugs/filemanager_integration_broken.mdwn
new file mode 100644
index 0000000000..aef3896fd7
--- /dev/null
+++ b/doc/bugs/filemanager_integration_broken.mdwn
@@ -0,0 +1,44 @@
+### Please describe the problem.
+
+I tried now for hours to understand why the filemanager inegration is just not working.
+Debug output in Assistent/Install.hs is basically none existent so I don't even know if anything is run at all.
+There is no dedicated process to get the .desktop files etc created or an example that you could use if the process fails.
+I'm out of ideas now.
+
+I tried running with GIT_ANNEX_PACKAGE_INSTALL=1 and without, tried to ensure directories exist. 
+
+### What steps will reproduce the problem?
+
+git annex assistant
+
+
+
+### What version of git-annex are you using? On what operating system?
+
+nixos
+
+git-annex version: 6.20171003
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux x86_64
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+yes
+
diff --git a/doc/bugs/filemanager_integration_broken/comment_1_aa5afe9af21e534a6c0683064296d9e6._comment b/doc/bugs/filemanager_integration_broken/comment_1_aa5afe9af21e534a6c0683064296d9e6._comment
new file mode 100644
index 0000000000..3a4184791a
--- /dev/null
+++ b/doc/bugs/filemanager_integration_broken/comment_1_aa5afe9af21e534a6c0683064296d9e6._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-04-04T16:26:07Z"
+ content="""
+Did you install git-annex from the nix package?
+
+The desktop file is supposed to be shipped with the OS's package of
+git-annex, in /etc so it's available for file managers to use as soon as
+it's installed. `make install` arranges for that to happen. 
+
+If nix is building
+git-annex in some other way, they may be leaving out such ancillary files.
+(And from what I know of nix, there would be some complication providing 
+files in /etc.)
+
+The other way the desktop file is installed was added for
+the git-annex standalone bundle, and installs it into the home directory
+of the user who starts the git-annex webapp. You've correctly
+identified the (undocumented) `GIT_ANNEX_PACKAGE_INSTALL=1` that informs
+git-annex that it's running in such a situation. But there's also a
+`GIT_ANNEX_APP_BASE`
+that it expects to point to where the standalone bundle is located
+(in order to use an icon file from there in the desktop file),
+and it doesn't install the desktop file when that's not set.
+
+I think that the nix package maintainer should be looped into this,
+so we can come up with some solution that works out of the box with those
+packages.
+"""]]
diff --git a/doc/bugs/find_by_metadata_is_slow.mdwn b/doc/bugs/find_by_metadata_is_slow.mdwn
new file mode 100644
index 0000000000..7cdec7d63b
--- /dev/null
+++ b/doc/bugs/find_by_metadata_is_slow.mdwn
@@ -0,0 +1,19 @@
+### Please describe the problem.
+
+Finding files by metadata is possible with
+
+    git annex find --metadata some-key="something*"
+
+From looking at the code, inspecting .git/annex and running this multiple times, it seems to me that this does not use any cache.
+Accordingly, it takes ~25s on my large repo.
+
+This is too slow for many use cases.
+
+I was not sure whether to add this here as a bug or in the todo section.
+The design notes for [[design/caching_database]] gave me the impression that some metadata caching is already planned?
+
+A metadata cache could track the git-annex commit sha-1 that it was built for. Then git-annex only needs to check, whether any change to a metadata file happened in a commit between the current HEAD of the git-annex branch and the commit sha-1 of the cache.
+
+### What version of git-annex are you using? On what operating system?
+
+8.20200227-gf56dfe791
diff --git a/doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__.mdwn b/doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__.mdwn
new file mode 100644
index 0000000000..3bd64aeede
--- /dev/null
+++ b/doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__.mdwn
@@ -0,0 +1,87 @@
+### Please describe the problem.
+I cloned my git-annex repository to a bare repository on my server (and deleted the original to reinstall the OS). When I try to clone back to a new machine
+
+    $ git-annex get .
+    get programs/2017-06-drafts/About.txt (not available) 
+      Try making some of these repositories available:
+      	8ddb8c4d-06ac-4c93-bf28-15639e0ea600 -- MacBook
+    failed
+
+and so for many files I committed. The files are actually on the server as I can see from the size of the repo and I remember them being copied there.
+
+When I strace that command, I see that it stats a missing file
+
+    stat(".git/annex/objects/7v/5x/SHA256E-s81068--de1d8de99645d74ba1ea186b6cabd1fc116cb6c1823130756f33ff81807815ed.pdf/SHA256E-s81068--de1d8de99645d74ba1ea186b6cabd1fc116cb6c1823130756f33ff81807815ed.pdf", 0x200015bf0) = -1 ENOENT (No such file or directory)
+
+`.git/annex/objects` is absent in the cloned repository on the server (I test it there - on my machine it doesn't work either).
+
+However I can find that the SHA file really exists 
+
+    $ locate SHA256E-s81068--de1d8de99645d74ba1ea186b6cabd1fc116cb6c1823130756f33ff81807815ed.pdf/SHA256E-s81068--de1d8de99645d74ba1ea186b6cabd1fc116cb6c1823130756f33ff81807815ed.pdf
+    /home/yaroslav/work.git/d0d/994/SHA256E-s81068--de1d8de99645d74ba1ea186b6cabd1fc116cb6c1823130756f33ff81807815ed.pdf/SHA256E-s81068--de1d8de99645d74ba1ea186b6cabd1fc116cb6c1823130756f33ff81807815ed.pdf
+
+and that contains the necessary data.
+
+So I wrote this bash script to recover some files from the corrupt repo (put there your parameters like directory names etc)
+
+    fix_obj.sh
+[[!format  bash """
+NEWDIR=new
+while IFS=  read -r -d $'\0'; 
+do
+        trueloc=`sed 's/\/annex\/objects\///g' <"$REPLY"`  
+        # if you had swap files from editors, they may appear here. Fix them in advance.
+        # echo "$REPLY"':'$trueloc
+        truefil=`locate $trueloc/$trueloc | grep work.git-copy`
+        mkdir -p $NEWDIR/`dirname $REPLY`
+        cp -p $truefil $NEWDIR/$REPLY
+done < <(find $1/* -type f -print0)
+"""]]
+
+The cycle on all files is not a simple "for dir in \`find $1\`" because of possible newlines and spaces in directories. For my directories that worked, but I'm still not sure about possible bugs in that (actually it complains several times, but seems to work). The script doesn't work in sh, but can be launched via e.g.
+
+    . fix_obj.sh programs
+
+where 'programs' is a subdirectory (without a backslash) in your git repo that you want to recover.
+
+I don't know how this situation occured and how to fix that in other way. I tried `git gc`, `git-annex fsck`, `git-annex repair`, of course cloned (git and git-annex) and other things, but that didn't help. 
+
+I've read [disaster recovery](https://git-annex.branchable.com/design/assistant/disaster_recovery/)
+
+> # git repository repair
+> There are several ways git repositories can get damanged.
+> The most common is empty files in .git/annex/objects and commits that refer to those objects. When the objects have not yet been pushed anywhere. I've several times recovered from this manually by removing the bad files and resetting to before the commits that referred to them. Then re-staging any divergence in the working tree. This could perhaps be automated.
+> ...
+> This is useful outside git-annex as well, so make it a git-recover-repository command.
+
+I think that would be nice to provide some means to recover from these situations. At least those who face the same problem as me can use the script above.
+
+### What steps will reproduce the problem?
+
+1. Create git-annex on your local machine.
+2. Clone that to a remote server. Unfortunately I don't remember the exact commands - I think that was done with the `rsync` special backend.
+3. \* Delete all the data except on the server (better not do that).
+4. Try to clone that from the server to a new machine.
+
+### What version of git-annex are you using? On what operating system?
+
+On the original machine I used `version 6` with `thin`. git-annex was downloaded from this site as a binary maybe several months ago. The OS was `Fedora Core 24`, the FS was `ext4`.
+
+On the server where I cloned the repo I noticed that the git-annex version was `5`. On the server the git-annex version is `6.20171003-g14ffdd779`. The OS is `CentOS Linux 7 (Core)` (a virtual private server).
+
+### Please provide any additional information below.
+
+I managed to recover a unique part of my data, however I don't know how the repo could be recovered (which would be best). I will combine the data again from available pieces. 
+
+I'd also like to add that I'm not a git expert, I use quite few commands from that and now I may know it not better than git-annex. Only recently I realized that `special remotes` don't have a copy of the git repository (I found this only [here](http://git-annex.branchable.com/special_remotes/rsync/#comment-525d3951ab1f09fdf471f450a798b50e) and still can't see that on [special remotes](http://git-annex.branchable.com/special_remotes/) page). That would be great if we could understand not only basic things about e.g. special remotes, but also the underlying facts about git-annex, to better understand possible problems. It's not intuitive that some repositories are cloned via `git clone`, and some via `git-annex initremote` etc, or that could better pronounced if that is the only difference, otherwise things mess up: I still don't quite understand what would be the difference between `git-annex get .` and `git-annex sync --content` (because the latter showed me that my repo above was synced - even though it really missed the files I needed). 
+
+git-annex version 6 seems very promising, but I have a feeling that the documentation for the project should be a bit rewritten/restructured, because when I read comments from several years ago, I can't judge whether that is still appropriate or not. Sorry if I should had submitted that in another bug on the documentation. 
+
+And maybe one should rename my question, because I can't locate precisely the problem and mostly just used the keywords for a better search.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, I have a working git-annex repository on a server (with `gcrypt`) and on two laptops of mine. That works fine, though [not blazingly fast](http://git-annex.branchable.com/bugs/v6__58___git_status__47__add_after_unlock_is_linear_to_the_file_size/#comment-5b8baf74551f8cc192d5d87b8d6aefa3). 
+> and a lil' positive end note
+
+I think there are no other variants for me. A year ago I tried some 'out-of-the box' popular alternatives, but the only use from that was to better learn SELinux and process isolation. Now I think the best is the \*NIX style where you control everything and you can learn. I've spent many days learning git-annex and hope that will work (though the last link above). 
diff --git a/doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/comment_1_70e050ef94ab57e74b45b18f3f9ca1f3._comment b/doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/comment_1_70e050ef94ab57e74b45b18f3f9ca1f3._comment
new file mode 100644
index 0000000000..bae013a871
--- /dev/null
+++ b/doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/comment_1_70e050ef94ab57e74b45b18f3f9ca1f3._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-10-25T19:13:16Z"
+ content="""
+The strance output you pasted shows git-annex checking the *local*
+repository to see if it has a copy of the file. As far as I can see, that
+has nothing to do with any failure to get the file from a remote
+repository. 
+
+> Clone that to a remote server. Unfortunately I don't remember the exact commands - I think that was done with the rsync special backend.
+
+Are you talking about a git-annex rsync special remote,
+or a git repository accessed via a rsync:// url, or what?
+
+> /home/yaroslav/work.git/d0d/994/SHA256E-s81068--de1d8de99645d74ba1ea186b6cabd1fc116cb6c1823130756f33ff81807815ed.pdf/SHA256E-s81068--de1d8de99645d74ba1ea186b6cabd1fc116cb6c1823130756f33ff81807815ed.pdf
+
+What this path tells me is that, despite this being a bare git repository,
+the content of objects is not in work.git/annex/objects/ where it belongs,
+but at the top of the repository.
+
+Hypothesis: You created this bare git repository. But then rather than
+simply having git-annex send contents of files to it in the sane and
+regular way, you them proceeded to set up some kind of special remote,
+in the same directory. It could have been a rsync special remote, or
+a directory special remote. You copied the files to that special remote.
+
+Then, you deleted the original git repository, which was the only one that
+knew about the special remote, before syncing it to anywhere.
+
+That fits all the evidence. I don't think that's a mistake many people
+are likely to make.
+
+It should be possible to recover from this situation by:
+
+	cd /home/yaroslav/work.git/
+	mkdir -p annex/objects
+	mv d0d annex/objects
+	# also move any other 3 letter directories that have annex
+	# objects in them
+	git annex fsck
+
+Then after `git annex sync` in your clone, it should know where the content
+is and be able to get it from the bare repo.
+
+Assuming that works, I'm having a hard time treating this as any kind
+of bug in git-annex. You put the gun in a vise, bent its barrel
+to a 180 degree angle, and... ;)
+"""]]
diff --git a/doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/comment_2_35df3798ddb3424fb26e11df53420d2d._comment b/doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/comment_2_35df3798ddb3424fb26e11df53420d2d._comment
new file mode 100644
index 0000000000..547fe70095
--- /dev/null
+++ b/doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/comment_2_35df3798ddb3424fb26e11df53420d2d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="ynikitenko"
+ avatar="http://cdn.libravatar.org/avatar/168d629704097ddc596f75ca32a687a3"
+ subject="thanks"
+ date="2017-10-29T16:28:33Z"
+ content="""
+Dear Joey, many thanks for your useful reply. Now I understand that better. I tried your fix and it worked - no there are no complaints and the files are being synced.
+
+However, in my /annex/objects there is 1.9Gb, while in the cloned repo there are only 20 Mb of data synced. Do you have any ideas of what could be done? Should I ask at the forum? Many thanks anyway. 
+
+Now I think this is not a bug of git-annex, but I still think that the documentation for that could be improved. Should I delete this report, move it to the forum or anything?
+
+"""]]
diff --git a/doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/comment_3_584fce9a8a501e380426c123505bfdf9._comment b/doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/comment_3_584fce9a8a501e380426c123505bfdf9._comment
new file mode 100644
index 0000000000..e7a1704bf3
--- /dev/null
+++ b/doc/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/comment_3_584fce9a8a501e380426c123505bfdf9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-10-30T15:48:34Z"
+ content="""
+You could try running `git annex unused` in the repository of unusual size
+and see if it perhaps finds something to remove.
+
+Always happy to improve documentation if you have ideas.
+"""]]
diff --git a/doc/bugs/forwarded.mdwn b/doc/bugs/forwarded.mdwn
new file mode 100644
index 0000000000..1a544a4f7d
--- /dev/null
+++ b/doc/bugs/forwarded.mdwn
@@ -0,0 +1,2 @@
+This tag is for bugs that have been forwarded from git-annex to some other
+software, such as a library it uses.
diff --git a/doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_.mdwn b/doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_.mdwn
new file mode 100644
index 0000000000..cbcbedbd1e
--- /dev/null
+++ b/doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_.mdwn
@@ -0,0 +1,33 @@
+### Please describe the problem.
+
+See e.g. on [https://github.com/datalad/git-annex/actions/runs/6680765679/job/18154374923](https://github.com/datalad/git-annex/actions/runs/6680765679/job/18154374923)
+
+```
+  Repo Tests v10 unlocked
+    Init Tests
+      init:                                   OK (0.17s)
+      add:                                    OK (0.73s)
+    addurl:                                   OK (0.57s)
+    crypto:                                   FAIL (3.07s)
+      ./Test/Framework.hs:86:
+      initremote failed with unexpected exit code (transcript follows)
+      initremote foo (encryption setup) (to gpg keys: 129D6E0AC537B9C7) 
+      git-annex: .git/annex/othertmp/remote.log: hPut: invalid argument (invalid character)
+      failed
+      (recording state in git...)
+      initremote: 1 failed
+```
+
+started only recently but consistently:
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2023/10[master]git
+$> git grep -l 'hPut: invalid argument'
+cron-20231027/build-ubuntu.yaml-1289-1c03c8fd-failed/0_test-annex (normal, ubuntu-latest).txt
+...
+```
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_/comment_1_6b2c645f9ca440f4707c671a94566bb7._comment b/doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_/comment_1_6b2c645f9ca440f4707c671a94566bb7._comment
new file mode 100644
index 0000000000..586c9184bf
--- /dev/null
+++ b/doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_/comment_1_6b2c645f9ca440f4707c671a94566bb7._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-11-01T16:07:15Z"
+ content="""
+Reproduced with LANG=C:
+
+      ./Test/Framework.hs:86:
+      initremote failed with unexpected exit code (transcript follows)
+      initremote foo (encryption setup) (to gpg keys: 129D6E0AC537B9C7)
+      git-annex: .git/annex/othertmp/remote.log: withFile: invalid argument (cannot encode character '\132')
+      failed
+      (recording state in git...)
+      initremote: 1 failed
+
+Not quite the same error but almost certianly the same problem.
+
+I've confirmed this is caused by 
+[[!commit 3742263c99180d1391e4fd51724aae52d6d02137]]
+"""]]
diff --git a/doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_/comment_2_52185ae4ebdfcb61840444e3ef1e0404._comment b/doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_/comment_2_52185ae4ebdfcb61840444e3ef1e0404._comment
new file mode 100644
index 0000000000..ea1469e6cd
--- /dev/null
+++ b/doc/bugs/fresh_test_fails__58___hPut__58___invalid_argument_/comment_2_52185ae4ebdfcb61840444e3ef1e0404._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-11-01T16:53:48Z"
+ content="""
+Will probably need to revert the Remote/Helper/Encryptable.hs part of that
+commit. 
+
+What is happening here is, encodeBS is failing when run on the String from
+a SharedPubKeyCipher. That String comes from Utility.Gpg.genRandom and is
+literally a bunch of random bytes. So it's not encoded with the filesystem
+encoding. And it really ought to be a ByteString of course, but since it's
+not, anything involving encoding it fails.
+
+That's why the old code had this comment:
+
+	{- Not using Utility.Base64 because these "Strings" are really
+	 - bags of bytes and that would convert to unicode and not round-trip
+	 - cleanly. -}
+
+And converted that String to a ByteString via `B.pack . s2w8`, which avoids this problem.
+
+What an ugly thing. Really ought to be fixed to use ByteString throughout. 
+But for now, let's revert.
+"""]]
diff --git a/doc/bugs/fsck_--json_incomplete_error_reporting.mdwn b/doc/bugs/fsck_--json_incomplete_error_reporting.mdwn
new file mode 100644
index 0000000000..d44bf347fa
--- /dev/null
+++ b/doc/bugs/fsck_--json_incomplete_error_reporting.mdwn
@@ -0,0 +1,53 @@
+### Please describe the problem.
+
+I ran git annex fsck --json. I have some files that are lacking numcopies. I get output in stderr, but no error details in the json body.
+
+For example:
+
+{"command":"fsck","success":false,"key":"SHA256E-s165540--ddcf7ce58593667e1b836e2a7f28a9f5227f3d9ba46cf8f98c7ab9dd26ef1896.jpg","error-messages":[],"file":"2022/12/04/chandrian_10:06:41.jpg","dead":[],"untrusted":[],"input":["2022/12/04/chandrian_10:06:41.jpg"]}
+  Only 2 of 5 trustworthy copies exist of 2022/12/04/chandrian_11:05:20.jpg
+  Back it up with git-annex copy.
+
+
+It would be great if error-messages contained all the details for failures. Thank you
+
+
+### What steps will reproduce the problem?
+
+* create a new repo
+* annex a file
+* set numcopies to 2 or whatever
+* git annex fsck --json
+
+
+### What version of git-annex are you using? On what operating system?
+
+I'm on Fedora 37.
+
+git annex version
+git-annex version: 10.20221103
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.6.4.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! Git annex is amazing and is managing over 10 TB of data across 5 git annexes and around 10 hard drives. No data loss this entire time -- over 8 years.
+
+> [[notabug|done]]; see my comment --[[Joey]]
diff --git a/doc/bugs/fsck_--json_incomplete_error_reporting/comment_1_979d52131fe94a9e800f939da88b369e._comment b/doc/bugs/fsck_--json_incomplete_error_reporting/comment_1_979d52131fe94a9e800f939da88b369e._comment
new file mode 100644
index 0000000000..0e33e6f007
--- /dev/null
+++ b/doc/bugs/fsck_--json_incomplete_error_reporting/comment_1_979d52131fe94a9e800f939da88b369e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="kanak@3c4f6e7d832d88751c617b25bdbac896417eb93b"
+ nickname="kanak"
+ avatar="http://cdn.libravatar.org/avatar/708121dfec06e554300b2a3a73a26818"
+ subject="comment 1"
+ date="2022-12-04T17:40:38Z"
+ content="""
+Not just limited to numcopies:
+
+{\"command\":\"fsck\",\"success\":true,\"key\":\"SHA256E-s119046--239da5a85ddf8c4071d8803a864a896d13e2a2fd65fd5684fc2f6dcaf264e875.jpg\",\"error-messages\":[],\"file\":\"12/03/chandrian_22:37:41.jpg\",\"note\":\"checksum...\",\"input
+\":[\"12/03/chandrian_22:37:41.jpg\"]} 
+  ** Based on the location log, 12/03/chandrian_23:05:41.jpg                                                                                                                                                        
+  ** was expected to be present, but its content is missing.  
+
+
+
+"""]]
diff --git a/doc/bugs/fsck_--json_incomplete_error_reporting/comment_2_71fd5ede0aa24fcc6522a03010ccec5c._comment b/doc/bugs/fsck_--json_incomplete_error_reporting/comment_2_71fd5ede0aa24fcc6522a03010ccec5c._comment
new file mode 100644
index 0000000000..f369a27d9e
--- /dev/null
+++ b/doc/bugs/fsck_--json_incomplete_error_reporting/comment_2_71fd5ede0aa24fcc6522a03010ccec5c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-12-26T17:27:54Z"
+ content="""
+Use the --json-error-messages option to move that into the json. It is
+documented on the man page.
+"""]]
diff --git a/doc/bugs/fsck_does_not_detect_corruption_on_yt_vids.mdwn b/doc/bugs/fsck_does_not_detect_corruption_on_yt_vids.mdwn
new file mode 100644
index 0000000000..6130778562
--- /dev/null
+++ b/doc/bugs/fsck_does_not_detect_corruption_on_yt_vids.mdwn
@@ -0,0 +1,72 @@
+### Please describe the problem.
+
+I added a YT vid via addurl and then intentionally corrupted it by rewriting the underlying contents. After doing so, the video was clearly broken, but `git annex fsck` did not detect this.
+
+
+### What steps will reproduce the problem?
+
+```
+$ git annex addurl 'https://www.youtube.com/watch?v=zGDzdps75ns'
+addurl https://www.youtube.com/watch?v=zGDzdps75ns 
+(using yt-dlp) (to Small short test video [zGDzdps75ns].webm) 
+ok                                   
+(recording state in git...)
+$ git commit -m 'test'
+$ echo test | sudo tee './Small short test video [zGDzdps75ns].webm'
+test
+$ git annex fsck './Small short test video [zGDzdps75ns].webm'
+fsck Small short test video [zGDzdps75ns].webm ok
+(recording state in git...)
+$ file -L ./Small\ short\ test\ video\ \[zGDzdps75ns\].webm
+./Small short test video [zGDzdps75ns].webm: ASCII text
+```
+
+The fsck reports the file is "ok". Even an fsck `--from=web` reports the video is OK:
+
+```
+$ git annex fsck './Small short test video [zGDzdps75ns].webm' --from=web
+fsck Small short test video [zGDzdps75ns].webm 
+ok                                    
+(recording state in git...)
+```
+
+In contrast, doing the same thing to a non-youtube video via addurl _does_ get detected by fsck:
+
+```
+$ git annex addurl 'https://git-annex.branchable.com/logo_small.png'
+addurl https://git-annex.branchable.com/logo_small.png 
+(to git-annex.branchable.com_logo_small.png) ok
+(recording state in git...)
+$ git commit -m 'test'
+$ echo test | sudo tee ./git-annex.branchable.com_logo_small.png 
+test
+$ git annex fsck ./git-annex.branchable.com_logo_small.png
+fsck git-annex.branchable.com_logo_small.png 
+  git-annex.branchable.com_logo_small.png: Bad file size (4.74 kB smaller); moved to .git/annex/bad/SHA256E-s4749--c604d942bd8edebe5e8e01d18d1ad3604b0874c38d436c9486c52d601e4251dd.png
+failed
+(recording state in git...)
+fsck: 1 failed
+```
+
+
+
+### What version of git-annex are you using? On what operating system?
+
+10.20230828, on Ubuntu Jammy.
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Excited to move my photo collection over to it!
+
+
diff --git a/doc/bugs/fsck_does_not_detect_corruption_on_yt_vids/comment_1_e7f61f04af8cc4c7ff9125fa37b90f4f._comment b/doc/bugs/fsck_does_not_detect_corruption_on_yt_vids/comment_1_e7f61f04af8cc4c7ff9125fa37b90f4f._comment
new file mode 100644
index 0000000000..81fb5ed984
--- /dev/null
+++ b/doc/bugs/fsck_does_not_detect_corruption_on_yt_vids/comment_1_e7f61f04af8cc4c7ff9125fa37b90f4f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="gitannex@fe613c61745e9d1e7f6df5e24a666828bb5682cc"
+ nickname="gitannex"
+ avatar="http://cdn.libravatar.org/avatar/d6820063ef0e9c0e23d42d3b797246f0"
+ subject="comment 1"
+ date="2023-08-31T01:56:30Z"
+ content="""
+I think I found a likely explanation: The yt-dlp downloaded videos use the URL backend, which doesn't include any sort of hashing. That makes some sense, but the indicator that `git annex fsck` gives here is still misleading. You might have silent corruption without realizing it, which is never something I'd anticipate with files stored in a git repo.
+
+Should `git annex fsck` perhaps print a warning of some type when checking files it cannot verify consistency on?
+"""]]
diff --git a/doc/bugs/fsck_does_not_detect_corruption_on_yt_vids/comment_2_8f26d11cbfceb6928648fe40b890c49b._comment b/doc/bugs/fsck_does_not_detect_corruption_on_yt_vids/comment_2_8f26d11cbfceb6928648fe40b890c49b._comment
new file mode 100644
index 0000000000..28ac15bb15
--- /dev/null
+++ b/doc/bugs/fsck_does_not_detect_corruption_on_yt_vids/comment_2_8f26d11cbfceb6928648fe40b890c49b._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-09-07T18:58:31Z"
+ content="""
+The intent of this is to allow downloading the same youtube video to
+multiple devices, since youtube might present different encodings of the
+video at different times.
+
+You can use `git-annex migrate --backend=SHA256` to convert to a backend
+that does get hash checked.
+
+If you set the annex.securehashesonly config to true, `git-annex fsck`
+will complain about any files that are not hashed (as well as files using
+insecure hashes).
+
+Setting annex.securehashesonly will also prevent `git-annex addurl` from
+adding youtube videos, eg:
+
+	git-annex addurl 'https://www.youtube.com/watch?v=uA3yPe5lG4c'
+	addurl https://www.youtube.com/watch?v=uA3yPe5lG4c
+	(using yt-dlp)
+	  annex.securehashesonly blocked transfer of URL key
+	failed
+
+Perhaps it would be better for addurl, with that configuration, to
+not generate an URL key, but hash it with the default backend.
+"""]]
diff --git a/doc/bugs/fsck_ignores_--json-error-messages_when_--quiet.mdwn b/doc/bugs/fsck_ignores_--json-error-messages_when_--quiet.mdwn
new file mode 100644
index 0000000000..83c4d44db3
--- /dev/null
+++ b/doc/bugs/fsck_ignores_--json-error-messages_when_--quiet.mdwn
@@ -0,0 +1,76 @@
+### Please describe the problem.
+
+As I understand the manual:
+
+- Options `--json --json-error-messages` are provided so that another program can parse the `git annex fsck` results. 
+
+- Option `--quiet` is provided to list only problems (not print anything for OK files). 
+
+However, when options are combined, only plain text error messages are provided, no json output is provided.
+
+I understand this may be "as designed", quiet is quiet... But then how to log only errors in json? I have +300k files in the annex, and no need to log when everything is fine.
+
+### What steps will reproduce the problem?
+
+Create a repo with files b and c 
+
+Corrupt file b
+ 
+`git annex fsck  --json --json-error-messages --quiet`
+
+I expected to have a json output with only files that fail the fsck, instead I get only normal stderr, just like with 
+`git annex fsck  --quiet`
+
+### What version of git-annex are you using? On what operating system?
+10.20230926-12 on arch
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+# Expected plain result 
+> git annex fsck
+
+fsck b 
+  ** No known copies exist of b
+failed
+fsck c (checksum...) ok
+(recording state in git...)
+fsck: 1 failed
+
+# Expected json result (error message to stderr, both logs)
+> git annex fsck --json
+
+  ** No known copies exist of b
+{"command":"fsck","dead":[],"error-messages":[],"file":"b","input":["b"],"key":"SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2","success":false,"untrusted":[]}
+{"command":"fsck","error-messages":[],"file":"c","input":["c"],"key":"SHA256E-s4--530a0b93b8c1ea618546d3aaa6ec71f888d2a6095322bfdb1b04c9225e26481e","note":"checksum...","success":true}
+fsck: 1 failed
+
+# Expected json output with error message embedded 
+> git annex fsck  --json --json-error-messages
+
+{"command":"fsck","dead":[],"error-messages":["** No known copies exist of b"],"file":"b","input":["b"],"key":"SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2","success":false,"untrusted":[]}
+{"command":"fsck","error-messages":[],"file":"c","input":["c"],"key":"SHA256E-s4--530a0b93b8c1ea618546d3aaa6ec71f888d2a6095322bfdb1b04c9225e26481e","note":"checksum...","success":true}
+fsck: 1 failed
+
+# Expected only error message
+> git annex fsck --quiet
+
+  ** No known copies exist of b
+fsck: 1 failed
+
+# UnExpected result: I expected a json output with the error message embedded "--json --json-error-messages" seem ignored here
+> git annex fsck  --json --json-error-messages --quiet
+
+  ** No known copies exist of b
+fsck: 1 failed
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, great tool ! Thanks !
+
+
+> [[wontfix|done]] per my comment --[[Joey]]
diff --git a/doc/bugs/fsck_ignores_--json-error-messages_when_--quiet/comment_1_a23d96af8c0e418350a73cbce5bc24be._comment b/doc/bugs/fsck_ignores_--json-error-messages_when_--quiet/comment_1_a23d96af8c0e418350a73cbce5bc24be._comment
new file mode 100644
index 0000000000..f0f8660751
--- /dev/null
+++ b/doc/bugs/fsck_ignores_--json-error-messages_when_--quiet/comment_1_a23d96af8c0e418350a73cbce5bc24be._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-11-21T20:03:45Z"
+ content="""
+Hmm, I've never considered combining --quiet with --json. It's kind of
+undefined and really not clear to me what it should do.
+
+But, --json-error-messages makes the json contain an error-messages field,
+and the error message is in there. So you can just extract that and ignore
+the other messages in the json output. No need to use --quiet then.
+
+I suppose there may be someone who uses --json as a matter of course, but
+adds --quiet to that when they want to disable the json output. So
+changing the current behavior, ill-defined as it is, would be asking for
+trouble.
+
+What actually happens currently is which ever output option comes last
+overrides earlier options. So `--json --quiet` is quiet, and `--quiet
+--json` outputs json. `--json-error-messages` is like `--json` in this
+regard to. Which is just behavior that fell out of the option parser
+implementation.
+"""]]
diff --git a/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote.mdwn b/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote.mdwn
new file mode 100644
index 0000000000..a8d249d324
--- /dev/null
+++ b/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote.mdwn
@@ -0,0 +1,47 @@
+### Please describe the problem.
+fsck says ok while file is not present in the remote
+
+The remote looks like this:
+`apple-slicer	gcrypt::rsync://apple-slicer/encr/gits/important_docs`
+
+```
+> git annex fsck --from apple-slicer Taxes/2018-19/Joint_T5.pdf                       
+fsck Taxes/2018-19/Joint_T5.pdf ok
+(recording state in git...)
+```
+
+This portion in the log does not look good
+
+```
+[2023-10-20 18:06:23.514382] (Utility.Process) process [63613] done ExitSuccess
+[2023-10-20 18:06:23.515339] (Utility.Process) process [63621] read: rsync ["apple-slicer:/encr/gits/important_docs/annex/objects/093/d6e/GPGHMACSHA1--47089ada3aaae768ea5e1d2ccc9284ac83a1d80f/GPGHMACSHA1--47089ada3aaae768ea5e1d2ccc9284ac83a1d80f"]
+[2023-10-20 18:06:24.344801] (Utility.Process) process [63621] done ExitFailure 23
+[2023-10-20 18:06:24.346693] (Utility.Process) process [63630] read: rsync ["apple-slicer:/encr/gits/important_docs/annex/objects/f9/V3/GPGHMACSHA1--47089ada3aaae768ea5e1d2ccc9284ac83a1d80f/GPGHMACSHA1--47089ada3aaae768ea5e1d2ccc9284ac83a1d80f"]
+[2023-10-20 18:06:25.148852] (Utility.Process) process [63630] done ExitFailure 23
+ok
+[2023-10-20 18:06:25.152624] (Utility.Process) process [63599] done ExitSuccess
+```
+
+Full log: https://privatebin.net/?c70841788ba0b6c1#9aCknSWqLjzQZd3n1hJUCK4GFEcoPFd1cZrfnWWoF5zm
+
+### What steps will reproduce the problem?
+1. Create a special remote of type `gcrypt::rsync`
+2. `git annex fsck --from {special remote} --debug`
+
+### What version of git-annex are you using? On what operating system?
+macOS
+`git-annex version: 10.20230626`
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_1_ce9085e6330625dabf479e6e3beeeb47._comment b/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_1_ce9085e6330625dabf479e6e3beeeb47._comment
new file mode 100644
index 0000000000..218cc0050b
--- /dev/null
+++ b/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_1_ce9085e6330625dabf479e6e3beeeb47._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-10-21T16:26:06Z"
+ content="""
+I don't see a bug here. If the file is not present there and was not
+expected to be present there, and there are enough copies in other places,
+then fsck has nothing to complain about.
+"""]]
diff --git a/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_2_59e89c065a3cd8f7c80cfdb3c2c2808d._comment b/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_2_59e89c065a3cd8f7c80cfdb3c2c2808d._comment
new file mode 100644
index 0000000000..dde7cc6805
--- /dev/null
+++ b/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_2_59e89c065a3cd8f7c80cfdb3c2c2808d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Manager2103"
+ avatar="http://cdn.libravatar.org/avatar/c3e024b0067a77f1ef99c6dd88614060"
+ subject="comment 2"
+ date="2023-10-21T17:22:53Z"
+ content="""
+I see. How could I check the consistency of all the files in a given remote? I thought that was the command
+"""]]
diff --git a/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_3_264a1b39c1677545af4c02901dd23d22._comment b/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_3_264a1b39c1677545af4c02901dd23d22._comment
new file mode 100644
index 0000000000..ba110ba0b5
--- /dev/null
+++ b/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_3_264a1b39c1677545af4c02901dd23d22._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-10-23T17:41:04Z"
+ content="""
+Well `fsck --from` does check the consistency of what's in the remote.
+That entails verifying that the remote contains the data that
+git-annex thinks it contains. But it also means verifying that the remote
+does not contain any data that git-annex didn't know it contains. 
+
+Checking the file is not present on the remote is part of the latter.
+
+If you wanted to only verify that files git-annex thinks are on the remote
+are present there, you could use eg `git-annex fsck --from theremote --in theremote`
+"""]]
diff --git a/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_4_f08e305e39953c5c1906df0fb2eb113b._comment b/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_4_f08e305e39953c5c1906df0fb2eb113b._comment
new file mode 100644
index 0000000000..2abae48cc5
--- /dev/null
+++ b/doc/bugs/fsck_says_ok_for_a_file_that_is_not_in_the_remote/comment_4_f08e305e39953c5c1906df0fb2eb113b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Manager2103"
+ avatar="http://cdn.libravatar.org/avatar/c3e024b0067a77f1ef99c6dd88614060"
+ subject="comment 4"
+ date="2023-10-23T17:50:22Z"
+ content="""
+That makes perfect sense. Thank you so much!
+
+And thanks for some fantastic software :)
+"""]]
diff --git a/doc/bugs/fsck_tells___39__ok__39___also_if_no_file_present.mdwn b/doc/bugs/fsck_tells___39__ok__39___also_if_no_file_present.mdwn
new file mode 100644
index 0000000000..860a94f3d1
--- /dev/null
+++ b/doc/bugs/fsck_tells___39__ok__39___also_if_no_file_present.mdwn
@@ -0,0 +1,77 @@
+### Please describe the problem.
+
+git-annex fsck tells ok, if there is no file present - is this behavior correct? I would expect git-annex to tell me that the file is not available.
+Well there is a (checksum...) ok output if the file exists, but I find 'ok' to be misleading if there is no file present. You could think that the file was checked and the checksum was correct - but this is not the case.
+
+
+### What steps will reproduce the problem?
+
+Just drop/move a file in the repo and than fsck it. git-annex will tell you 'ok' but the file dosen't exits.
+
+```sh
+sc@section9 ~/t/repo2> git status
+On branch master
+Your branch is up to date with 'origin/master'.
+
+nothing to commit, working tree clean
+sc@section9 ~/t/repo2> git annex info XMonad.png 
+file: XMonad.png
+size: 397.17 kilobytes
+key: SHA256E-s397167--4114f98837a83581add0f513ac2c1f0257ad8de0c18614ca30a9a5dbfe7a5904.png
+present: true
+sc@section9 ~/t/repo2> git annex fsck XMonad.png 
+fsck XMonad.png (checksum...) ok
+(recording state in git...)
+sc@section9 ~/t/repo2> git annex move --to origin XMonad.png
+move XMonad.png ok
+(recording state in git...)
+sc@section9 ~/t/repo2> git status
+On branch master
+Your branch is up to date with 'origin/master'.
+
+nothing to commit, working tree clean
+sc@section9 ~/t/repo2> git annex info XMonad.png 
+file: XMonad.png
+size: 397.17 kilobytes
+key: SHA256E-s397167--4114f98837a83581add0f513ac2c1f0257ad8de0c18614ca30a9a5dbfe7a5904.png
+present: false
+sc@section9 ~/t/repo2> git annex fsck XMonad.png 
+fsck XMonad.png ok   # ok? well there is no file, how can git-annex tell me that Xmonad.png checksum is okay?
+(recording state in git...)
+```
+
+### What version of git-annex are you using? On what operating system?
+
+```sh
+sc@section9 ~/t/repo2> git annex version
+git-annex version: 8.20200330
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.3 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+
+
+sc@section9 ~> cat /etc/issue 
+
+<<< Welcome to NixOS 19.09.2370.e10c65cdb35 (\m) - \l >>>
+
+```
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
+> [[notabug|done]] (I did add some more detail to the man page tho) --[[Joey]]
diff --git a/doc/bugs/gcrypt__58___WARNING__58___Remote_ID_has_changed__33__.mdwn b/doc/bugs/gcrypt__58___WARNING__58___Remote_ID_has_changed__33__.mdwn
new file mode 100644
index 0000000000..0b15a070fb
--- /dev/null
+++ b/doc/bugs/gcrypt__58___WARNING__58___Remote_ID_has_changed__33__.mdwn
@@ -0,0 +1,50 @@
+### Please describe the problem.
+
+For some reason, after a while I can't sync to any remotes (removeable drives, servers, etc.)
+
+
+### What steps will reproduce the problem?
+
+git annex sync, git annex assistant doing its autosync, etc.
+
+
+### What version of git-annex are you using? On what operating system?
+
+Arch Linux, git annex 6.20160613-g1e4e6f4
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+
+Typing git annex synx in a terminal gives me:
+
+commit  ok
+pull disk0_annexes_docs 
+gcrypt: Decrypting manifest
+gpg: Signature made Mon 25 Jul 2016 00:13:00 BST using RSA key ID XXXXXXXXXXXXXXX
+gpg: Good signature from "XXX <XXX@XXX.XXX>" [ultimate]
+gcrypt: WARNING:
+gcrypt: WARNING: Remote ID has changed!
+gcrypt: WARNING: from :id:lczpGq00kb1sF+cxgCNE
+gcrypt: WARNING: to   :id:2br4BOnJZkrGUsXTlQR8
+
+
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+Not specific to assistant.
+
+
+# End of transcript or log.
+"""]]
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, this worked for ages, a year or more, it's awesome! Haven't plugged the removeable drives in for a while, now when I do this happens...
+
+> git-annex does not set the gcrypt id. git-remote-gcrypt does that.
+> So if it somehow changed, it must be because of a bug in
+> git-remote-gcrypt. Or, because of something you did..
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/gcrypt_remotes_using_relative_paths.mdwn b/doc/bugs/gcrypt_remotes_using_relative_paths.mdwn
new file mode 100644
index 0000000000..fab52069e3
--- /dev/null
+++ b/doc/bugs/gcrypt_remotes_using_relative_paths.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+`git annex sync` is not automatically run for gcrypt remotes using rsync with a relative path
+
+### What steps will reproduce the problem?
+Flow 1 (relative path, broken)
+
+* `git remote add test gcrypt::rsync://user@user.rsync.net:relative/path/to/repo`
+* `git annex sync` -> DOES NOT SYNC to test remote
+* Nothing has been synced so I CANNOT successfully clone from the test remote with `git clone gcrypt::rsync://user@user.rsync.net:relative/path/to/repo`
+* `git push test git-annex master`
+* I can successfully clone from the test remote with `git clone gcrypt::rsync://user@user.rsync.net:relative/path/to/repo`
+
+Flow 2 (absolute path, working)
+
+* `git remote add test gcrypt::rsync://user@user.rsync.net/full/path/to/repo`
+* `git annex sync` -> DOES SYNC to test remote
+* I can successfully clone from the test remote with `git clone gcrypt::rsync://user@user.rsync.net:relative/path/to/repo`
+
+
+### What version of git-annex are you using? On what operating system?
+* Debian 11
+* git-annex version: 10.20230227
+* git-remote-gcrypt version 1.5
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I am VERY happy with git annex and am using it successfully with a gcrypt remote using an absolute path :)
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/gcrypt_remotes_using_relative_paths/comment_1_b4523baf0cdfc2ad70cded93b1629eca._comment b/doc/bugs/gcrypt_remotes_using_relative_paths/comment_1_b4523baf0cdfc2ad70cded93b1629eca._comment
new file mode 100644
index 0000000000..7f589384a2
--- /dev/null
+++ b/doc/bugs/gcrypt_remotes_using_relative_paths/comment_1_b4523baf0cdfc2ad70cded93b1629eca._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-23T17:53:22Z"
+ content="""
+The lack of a transcript made this bug hard to understand. After about
+half an hour of staring at it, I realized that you mean that `git-annex sync`
+does not even attempt to sync with the remote when it has the relative url:
+
+	joey@darkstar:~/tmp/bb>git remote add test gcrypt::rsync://user@user.rsync.net:relative/path/to/repo
+	joey@darkstar:~/tmp/bb>git-annex sync
+	commit
+	On branch master
+	nothing to commit, working tree clean
+	ok
+
+It does sync with it when asked to sync with explicitly that remote:
+
+	joey@darkstar:~/tmp/bb>git-annex sync test
+	commit 
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	pull test 
+	gcrypt: Repository not found: rsync://user@user.rsync.net:relative/path/to/repo
+	ok
+
+With the absolute url, it does sync with it when no remote
+is explicitly specified.
+"""]]
diff --git a/doc/bugs/gcrypt_remotes_using_relative_paths/comment_2_45281c947992c2ab124efd0f109255d6._comment b/doc/bugs/gcrypt_remotes_using_relative_paths/comment_2_45281c947992c2ab124efd0f109255d6._comment
new file mode 100644
index 0000000000..4175db0e42
--- /dev/null
+++ b/doc/bugs/gcrypt_remotes_using_relative_paths/comment_2_45281c947992c2ab124efd0f109255d6._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-03-23T18:27:36Z"
+ content="""
+Analysis: When parsing the relative url, git-annex ends up constructing a
+Repo with location `LocalUnknown "./rsync://user@user.rsync.net:relative/path/to/repo.git"`
+
+So, it thinks it's a local git repository, which of course does not exist,
+so it skips syncing with it.
+
+Why does it do that? Well:
+
+	ghci> import Network.URI
+	ghci> parseURI "rsync://user@user.rsync.net:relative/path/to/repo.git"
+	Nothing
+
+And Git.GCrypt.encryptedRemote strips off the "gcrypt::",
+leaving that.
+
+	ghci> r
+	Repo {location = LocalUnknown "/home/joey/tmp/bb", config = fromList [], fullconfig = fromList [], remoteName = Nothing, gitEnv = Nothing, gitEnvOverridesGitDir = False, gitGlobalOpts = [], gitDirSpecifiedExplicitly = False}
+	ghci> rr
+	Repo {location = Url gcrypt::rsync://user@user.rsync.net:relative/path/to/repo, config = fromList [], fullconfig = fromList [], remoteName = Just "test1", gitEnv = Nothing, gitEnvOverridesGitDir = False, gitGlobalOpts = [], gitDirSpecifiedExplicitly = False}
+	ghci> encryptedRemote r rr
+	Repo {location = LocalUnknown "/home/joey/tmp/bb/rsync://user@user.rsync.net:relative/path/to/repo.git", config = fromList [], fullconfig = fromList [], remoteName = Nothing, gitEnv = Nothing, gitEnvOverridesGitDir = False, gitGlobalOpts = [], gitDirSpecifiedExplicitly = False}
+	ghci> parseRemoteLocation "rsync://user@user.rsync.net:relative/path/to/repo" r
+	RemotePath "rsync://user@user.rsync.net:relative/path/to/repo"
+
+parseRemoteLocation uses isURI and that does not parse as a valid URI.
+
+So Git.GCrypt.encryptedRemote will need to force it to parse as an url in this case.
+
+(I remember that I fixed git-remote-gcrypt to support absolute urls for related
+reasons. Those relative nonstandard urls are not a good idea.)
+"""]]
diff --git a/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation.mdwn b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation.mdwn
new file mode 100644
index 0000000000..cd045b0b9b
--- /dev/null
+++ b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation.mdwn
@@ -0,0 +1,60 @@
+### Please describe the problem.
+
+On a user Windows machine, we get an odd issue of being unable to `annex get` a file from an ssh remote ([https://gin.g-node.org/yarikoptic/test-annex](https://gin.g-node.org/yarikoptic/test-annex)) while using an ssh key with a passphrase.  The reason seems to be that 2nd invocation of `ssh` by git-annex does not result in the prompt for the passphrase.
+
+I failed to reproduce locally in Windows VM machine.  In my case (probably different setup of ssh etc), I 1). get passphrase prompt via external gui window (not in the same terminal); 2). do get 2nd prompt as well.
+
+[Here you can get a full log](http://www.onerussian.com/tmp/test-annex-output-windows-ssh-passphrase-20211209.txt) where you can see passphrase prompt for initial clone, then within `get` once and not after 2nd ssh call
+
+
+```
+$> grep -1 -e passphrase -e faile -e 'ssh ' test-annex-output-windows-ssh-passphrase-20211209.txt
+Cloning into 'test-annex'...
+Enter passphrase for key '/c/Users/mvdmlab/.ssh/id_rsa':
+remote: Enumerating objects: 58, done.
+--
+# manually added to grep output for more consistent extract
+(NWB) PS D:\NWB\test_annex> cd .\test-annex\
+
+
+(NWB) PS D:\NWB\test_annex\test-annex> git annex --debug get annexed  
+--
+
+  Disabling ssh connection caching.
+[2021-12-09 10:41:16.7006865] (Utility.Process) process [14232] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","config","annex.sshcaching","false"]
+--
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+[2021-12-09 10:41:21.819308] (Utility.Process) process [9560] read: ssh ["git@gin.g-node.org","-n","-T","git-annex-shell 'configlist' '/yarikoptic/test-annex' '--debug'"]
+Enter passphrase for key '/c/Users/mvdmlab/.ssh/id_rsa':
+[2021-12-09 10:41:32.8083061] (Utility.Process) process [9560] done ExitSuccess
+--
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+[2021-12-09 10:41:32.8443384] (Utility.Process) process [2248] chat: ssh ["git@gin.g-node.org","-T","git-annex-shell 'p2pstdio' '/yarikoptic/test-annex' '--debug' 'dfff8737-36e2-4a1c-8206-bca071a5294d' --uuid 2a0fa804-1bd6-4298-aa55-4dc2d250eeac"]
+[2021-12-09 10:41:34.1335084] (Utility.Process) process [2248] done ExitFailure 255
+
+  Transfer failed
+
+--
+  No other repository is known to contain the file.
+failed
+[2021-12-09 10:41:34.1405139] (Utility.Process) process [14104] done ExitSuccess
+--
+[2021-12-09 10:41:34.1475217] (Utility.Process) process [500] done ExitSuccess
+get: 1 failed
+
+```
+
+### What version of git-annex are you using? On what operating system?
+
+Windows, 8.20211124-ga8ff96864
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_10_66386390af02c67c2e5bace223251f53._comment b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_10_66386390af02c67c2e5bace223251f53._comment
new file mode 100644
index 0000000000..75b20a826e
--- /dev/null
+++ b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_10_66386390af02c67c2e5bace223251f53._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="manishofyore@b68d21cd485417e84ea87876a9064f82714a08a1"
+ nickname="manishofyore"
+ avatar="http://cdn.libravatar.org/avatar/1250b23630e3f754368ceaf56cb8be9d"
+ subject="comment 10"
+ date="2021-12-16T19:35:02Z"
+ content="""
+By not getting through to the shell, do you mean the absence of a prompt?
+In any case here's a screenshot of the command with and without '-T'. 
+I first press 'Enter' once and see that Error message and 
+then I type 'test' and press enter. Then I press Ctrl + C 
+to exit and try the next command without '-T'. And the same result!
+
+https://github.com/vandermeerlab/data-formats/blob/master/debug/Output2.png
+"""]]
diff --git a/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_11_f818dadfa541520ac7ad2409b9174776._comment b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_11_f818dadfa541520ac7ad2409b9174776._comment
new file mode 100644
index 0000000000..0dc8ba08e8
--- /dev/null
+++ b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_11_f818dadfa541520ac7ad2409b9174776._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2022-01-03T16:22:05Z"
+ content="""
+Ok, you've ruled out my theory about -T, and stdin is being connected up
+through ssh correctly it looks like.
+
+One other thing to try would be to enable ssh verbose debugging,
+by running: `git config annex.ssh-options "-v -v -v"`  
+And perhaps that will give a clue.
+
+But I think the signs are pointing to you needing to change something
+about your ssh installation on Windows. Perhaps a different version of ssh
+for Windows would support the GUI password prompt. Normally, ssh comes
+from Git for Windows, which bundles a ssh, and I think that one does
+support the GUI prompt. Do you have some other ssh build installed?
+"""]]
diff --git a/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_1_18e194d53646cb6049058635ad54fe1f._comment b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_1_18e194d53646cb6049058635ad54fe1f._comment
new file mode 100644
index 0000000000..a3a6cce221
--- /dev/null
+++ b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_1_18e194d53646cb6049058635ad54fe1f._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-12-09T18:48:41Z"
+ content="""
+I do not think that git-annex is doing anything there that prevents ssh
+from asking for a password. Ie, it's not setting BatchMode=true,
+which it does do when it wants to prevent ssh from prompting for a
+password. That is done only when ssh connection caching is supported,
+which it's not on Windows.
+
+It's running `ssh git@gin.g-node.org -T "git-annex-shell 'p2pstdio' '/yarikoptic/test-annex' '--debug' 'dfff8737-36e2-4a1c-8206-bca071a5294d' --uuid 2a0fa804-1bd6-4298-aa55-4dc2d250eeac"`
+and that somehow fails, and the failure is at the ssh level (ssh exit status
+255 means a ssh error). This might not involve a password at all. For
+whatever reason ssh is failing without displaying any error message.
+
+It could be something as simple as this ssh not supporting -T. Or 
+just being broken in whatever way ssh on windows might be broken.
+
+My suggestion is, run the ssh command yourself, and see if it exits
+255, if so proceed to debugging ssh..
+"""]]
diff --git a/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_2_2766d9082373c11628006f14262509ad._comment b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_2_2766d9082373c11628006f14262509ad._comment
new file mode 100644
index 0000000000..d883322d38
--- /dev/null
+++ b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_2_2766d9082373c11628006f14262509ad._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2021-12-09T19:10:57Z"
+ content="""
+quick one, and I don't have --debug output, but if we use an ssh key without any passphrase, all goes well.
+"""]]
diff --git a/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_3_a15a47b120c0c1c1c8ee5050d6105bb1._comment b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_3_a15a47b120c0c1c1c8ee5050d6105bb1._comment
new file mode 100644
index 0000000000..78a10c53b0
--- /dev/null
+++ b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_3_a15a47b120c0c1c1c8ee5050d6105bb1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-12-09T19:37:35Z"
+ content="""
+That does not help diagnose your problem, does it? All is says is that the
+problem somehow involves password protected ssh keys. But ssh is what deals
+with those.
+
+You have to show that the problem is actually caused by git-annex, not by ssh,
+before I can really do anything about it. The obvious way to do that is
+to run the command as I suggested. 
+"""]]
diff --git a/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_4_72f08e454aad5092acc609a6597d9872._comment b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_4_72f08e454aad5092acc609a6597d9872._comment
new file mode 100644
index 0000000000..9140591995
--- /dev/null
+++ b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_4_72f08e454aad5092acc609a6597d9872._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2021-12-09T21:45:29Z"
+ content="""
+here is a screenshot I got: [http://www.onerussian.com/tmp/annex-ssh-20211209.png](http://www.onerussian.com/tmp/annex-ssh-20211209.png)
+"""]]
diff --git a/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_5_81f23cf6fe835358c9b88af50eab22a5._comment b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_5_81f23cf6fe835358c9b88af50eab22a5._comment
new file mode 100644
index 0000000000..c87e2071bc
--- /dev/null
+++ b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_5_81f23cf6fe835358c9b88af50eab22a5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-12-13T16:41:26Z"
+ content="""
+What is the exit status of ssh when you run that?
+
+That would normally print out the AUTH-SUCCESS and block waiting for input
+from stdin.  Your transcript seems to show it closing immediately after that
+output, unless perhaps you sent it a ctrl-d.
+
+So perhaps stdin is not getting connected through the `ssh -T`,
+or something could be failing on the remote end.
+"""]]
diff --git a/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_6_bbcf4c05813adc2239c1f6017425f1c9._comment b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_6_bbcf4c05813adc2239c1f6017425f1c9._comment
new file mode 100644
index 0000000000..4d3ba8a2e1
--- /dev/null
+++ b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_6_bbcf4c05813adc2239c1f6017425f1c9._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="manishofyore@b68d21cd485417e84ea87876a9064f82714a08a1"
+ nickname="manishofyore"
+ avatar="http://cdn.libravatar.org/avatar/1250b23630e3f754368ceaf56cb8be9d"
+ subject="comment 6"
+ date="2021-12-13T23:12:52Z"
+ content="""
+The behavior on Windows is as you said it is going to be. See screenshot below:
+
+https://ibb.co/cbXBgGM
+"""]]
diff --git a/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_7_23715781fb5fd3ece5e042be069812ab._comment b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_7_23715781fb5fd3ece5e042be069812ab._comment
new file mode 100644
index 0000000000..3fce6d6fec
--- /dev/null
+++ b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_7_23715781fb5fd3ece5e042be069812ab._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-12-16T14:53:41Z"
+ content="""
+@manishofyore your screenshot link is broken.
+"""]]
diff --git a/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_8_a037b7da3c4f2e04b23706592f04b0ac._comment b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_8_a037b7da3c4f2e04b23706592f04b0ac._comment
new file mode 100644
index 0000000000..b508927e93
--- /dev/null
+++ b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_8_a037b7da3c4f2e04b23706592f04b0ac._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="manishofyore@b68d21cd485417e84ea87876a9064f82714a08a1"
+ nickname="manishofyore"
+ avatar="http://cdn.libravatar.org/avatar/1250b23630e3f754368ceaf56cb8be9d"
+ subject="comment 8"
+ date="2021-12-16T18:53:15Z"
+ content="""
+Sorry for that. Here's a much more permanent link: https://github.com/vandermeerlab/data-formats/blob/master/debug/Output.png
+"""]]
diff --git a/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_9_6efb1a75b236b4384d1d2fccc3ab30b8._comment b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_9_6efb1a75b236b4384d1d2fccc3ab30b8._comment
new file mode 100644
index 0000000000..926a22e601
--- /dev/null
+++ b/doc/bugs/get__58___no_passphrase_ask_for_the_2nd_ssh_invocation/comment_9_6efb1a75b236b4384d1d2fccc3ab30b8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-12-16T19:21:31Z"
+ content="""
+Thank you. So standard input is not getting connected through the ssh to
+git-annex-shell, it appears.
+
+Could you try the same command with without the -T option, and see if it
+allows you to interact with it? Eg, after it says "AUTH-SUCCESS", see if
+you can enter "test" and if it replies to that.
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing.mdwn b/doc/bugs/get_is_busy_doing_nothing.mdwn
new file mode 100644
index 0000000000..3dd630ced5
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing.mdwn
@@ -0,0 +1,83 @@
+### Please describe the problem.
+
+spotted that our backup job, running git-annex 10.20220322-g7b64dea, had not exited for a number of days. In htop I see:
+
+
+```
+ 381205 dandi      20   0  169M  4276  4272 S  0.0  0.0  0:05.15 │                    └─ python -m tools.backups2datalad -l DEBUG -J 5 --target /mnt/backup/dandi/dandisets populate dandi-dandisets-dropbox
+ 389485 dandi      20   0 1026G 1140M 16208 S 171.  1.8     155h │                       └─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389486 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 17:33.20 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389488 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 22:07.69 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389490 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 24:49.46 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389494 dandi      20   0 10636  1968  1964 S  0.0  0.0  0:00.00 │                          ├─ git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.retry=3 cat-file --batch
+ 389496 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 13:41.26 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389497 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 10:47.33 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389498 dandi      20   0 1026G 1140M 16208 S 43.1  1.8 36h53:20 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389499 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 27:15.88 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389500 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 32:34.61 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389501 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 25:05.81 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389506 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 26:42.46 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389507 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 28:43.57 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389510 dandi      20   0 10636  1976  1972 S  0.0  0.0  0:00.02 │                          ├─ git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.retry=3 cat-file --batch
+ 389511 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 20:59.64 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389512 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 25:06.37 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389513 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 33:52.81 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389514 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 29:43.56 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389516 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 23:44.52 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389517 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 17:07.65 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389519 dandi      20   0 1026G 1140M 16208 S 43.1  1.8 36h16:00 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389520 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 18:49.32 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389521 dandi      20   0 1026G 1140M 16208 S  0.0  1.8  0:00.02 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389522 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 18:45.09 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389524 dandi      20   0 1026G 1140M 16208 S 41.8  1.8 36h32:16 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389528 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 20:00.35 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389556 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 24:22.72 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 389759 dandi      20   0 1026G 1140M 16208 S  0.0  1.8  0:00.04 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 390392 dandi      20   0 1026G 1140M 16208 S 42.5  1.8 37h16:15 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 391588 dandi      20   0 1026G 1140M 16208 S  0.0  1.8 20:03.40 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 394739 dandi      20   0 1026G 1140M 16208 S  0.0  1.8  0:00.00 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 441349 dandi      20   0 1026G 1140M 16208 S  0.0  1.8  9:46.65 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+ 444725 dandi      20   0 1026G 1140M 16208 S  0.0  1.8  7:42.72 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+1910907 dandi      20   0 1026G 1140M 16208 S  0.0  1.8  0:00.00 │                          ├─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+2277116 dandi      20   0 1026G 1140M 16208 S  0.0  1.8  0:00.00 │                          └─ git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+
+```
+
+relevant open files in that git repo:
+
+```
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000233$ lsof -p 389485 | grep 000
+lsof: WARNING: can't stat() btrfs file system /mnt/backup/docker/btrfs
+      Output information may be incomplete.
+git-annex 389485 dandi  cwd       DIR      0,40         266  88559549 /mnt/backup/dandi/dandisets/000233
+git-annex 389485 dandi  mem       REG       9,0       93000   3146348 /lib/x86_64-linux-gnu/libresolv-2.31.so
+git-annex 389485 dandi  mem-r     REG      0,35             118071211 /mnt/backup/dandi/dandisets/000233/.git/annex/keysdb/db-shm (path dev=0,40)
+git-annex 389485 dandi   29u      REG      0,40      139264  88559612 /mnt/backup/dandi/dandisets/000233/.git/annex/keysdb/db
+git-annex 389485 dandi   30u      REG      0,40           0 117504617 /mnt/backup/dandi/dandisets/000233/.git/annex/transfer/download/00000000-0000-0000-0000-000000000001/lck.SHA256E-s124312933165--d769cd7cbec2012515085d63eee594299d7411500c0bb9c13d10c0cd68d5ddce.nwb
+git-annex 389485 dandi   32u      REG      0,40           0 118071210 /mnt/backup/dandi/dandisets/000233/.git/annex/keysdb/db-wal
+git-annex 389485 dandi   34u      REG      0,40       32768 118071211 /mnt/backup/dandi/dandisets/000233/.git/annex/keysdb/db-shm
+git-annex 389485 dandi   50w      REG      0,40 47012344309 117504625 /mnt/backup/dandi/dandisets/000233/.git/annex/tmp/SHA256E-s124312933165--d769cd7cbec2012515085d63eee594299d7411500c0bb9c13d10c0cd68d5ddce.nwb
+```
+
+That key is available from:
+
+```
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000233$ git annex whereis --key SHA256E-s124312933165--d769cd7cbec2012515085d63eee594299d7411500c0bb9c13d10c0cd68d5ddce.nwb
+whereis SHA256E-s124312933165--d769cd7cbec2012515085d63eee594299d7411500c0bb9c13d10c0cd68d5ddce.nwb (1 copy) 
+        00000000-0000-0000-0000-000000000001 -- web
+
+  web: https://api.dandiarchive.org/api/assets/5304ce04-3a87-400c-a484-aa889156a505/download/
+  web: https://dandiarchive.s3.amazonaws.com/blobs/c84/640/c846401f-10bf-452f-b26a-82e3d905556c?versionId=naDNt0WozdY8oi6M9L6MGhfsvnRuW6RJ
+ok
+```
+where the first one is redirect to the second one. And I think it had not progressed from that 47012344309 size in quite awhile (will check again in an hour).
+
+I would have expected it to fail may be (and possibly `retry` if annex.retry) but not really get stuck.
+
+Is there any diagnostic information I should collect to help troubleshooting the issue, or could I just kill/restart that process?
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[[!meta title="SQLite3 returned ErrorBusy while attempting to perform step: database is locked"]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_10_10fea4ce67f5f9c6c33ba2a23a185f8a._comment b/doc/bugs/get_is_busy_doing_nothing/comment_10_10fea4ce67f5f9c6c33ba2a23a185f8a._comment
new file mode 100644
index 0000000000..4cd21b58b9
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_10_10fea4ce67f5f9c6c33ba2a23a185f8a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 10"
+ date="2022-06-01T05:27:21Z"
+ content="""
+You can set NOCOW only on emtpy files. e.g.
+
+    mv db db.tmp
+    touch db
+    chattr +C db
+    cat db.tmp >db
+    rm -f db.tmp
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_11_36dd4a0dba9e544d18376013e879b9c2._comment b/doc/bugs/get_is_busy_doing_nothing/comment_11_36dd4a0dba9e544d18376013e879b9c2._comment
new file mode 100644
index 0000000000..26941ed0d9
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_11_36dd4a0dba9e544d18376013e879b9c2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 11"
+ date="2022-06-01T13:49:05Z"
+ content="""
+Thank you @Lukey!
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_13_795ffef1e6a9f1acbd4394c1fca3818e._comment b/doc/bugs/get_is_busy_doing_nothing/comment_13_795ffef1e6a9f1acbd4394c1fca3818e._comment
new file mode 100644
index 0000000000..254c57886b
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_13_795ffef1e6a9f1acbd4394c1fca3818e._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2022-06-01T16:43:42Z"
+ content="""
+I tried modifying git-annex to throw ErrorBusy whenever it wrote to the
+sqlite database, to see how much of the behavior that could reproduce.
+
+That led to 10 second delays due to retrying, and the "failed to commit
+changes to sqlite database: Just SQLite3 returned ErrorBusy" message.
+
+But, it did not cause the "thread blocked indefinitely in an MVar
+operation". Which makes me wonder if that is caused by sqlite use
+elsewhere, perhaps in a read operation rather than a write.
+
+I did try making reads throw ErrorBusy, and it didn't reproduce the MVar
+problem either, instead "sqlite query crashed: SQLite3 returned ErrorBusy".
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_13_afae18b8b3a17f376b9a345059d9dbd4._comment b/doc/bugs/get_is_busy_doing_nothing/comment_13_afae18b8b3a17f376b9a345059d9dbd4._comment
new file mode 100644
index 0000000000..30ab1ceb36
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_13_afae18b8b3a17f376b9a345059d9dbd4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="defending BTRFS"
+ date="2022-06-02T18:43:02Z"
+ content="""
+FWIW, may be just as a defender of BTRFS decided to share a \"terminal shot\" of screens from drogon -- you can see how busy it is (`top` and `dstat` at the bottom) downloading (>= 100MBps) and reading (70MBps) and saving (>200MBps) while there is a good number of parallel processes which have a number of parallel git-annex processes:
+[screenshot](http://www.onerussian.com/tmp/busy-drogon-MVar-operation.png)
+
+and I don't know how well any other file system would have held up ;) 
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_13_bdfbcb8b6052a3c904e46678fce6adeb._comment b/doc/bugs/get_is_busy_doing_nothing/comment_13_bdfbcb8b6052a3c904e46678fce6adeb._comment
new file mode 100644
index 0000000000..781d182d41
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_13_bdfbcb8b6052a3c904e46678fce6adeb._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2022-06-03T17:52:12Z"
+ content="""
+To hopefully find out what MVar operation is blocking, I have added lock
+debugging instrumentation to all database calls. This will need a special
+build of git-annex with the DebugLocks build flag enabled. 
+
+I have made a standalone tarball built that way available here:
+<https://downloads.kitenet.net/git-annex/linux/debuglocks/>
+
+It should display a backtrace on stderr when the MVar deadlock happens.
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_14_9f6fde051e877638a56094d3179dc550._comment b/doc/bugs/get_is_busy_doing_nothing/comment_14_9f6fde051e877638a56094d3179dc550._comment
new file mode 100644
index 0000000000..f50d8233bb
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_14_9f6fde051e877638a56094d3179dc550._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 14"
+ date="2022-06-03T16:42:38Z"
+ content="""
+ok, none of those 3 jobs returned, I have a good number (>40) of git* related processes \"running\", see [screenshot](http://www.onerussian.com/tmp/git-annexes-stuck-1.png) .
+I will keep it in this \"state\" for possible introspection for another hour, and if no immediate ideas on what to look at, I will kill/update git-annex (from that `10.20220322-g7b64dea`) and restart jobs.
+
+FWIW, I have git config annex.stalldetection 1KB/120s
+
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_16_4d375d35a0d05d99c7becf591823d6b8._comment b/doc/bugs/get_is_busy_doing_nothing/comment_16_4d375d35a0d05d99c7becf591823d6b8._comment
new file mode 100644
index 0000000000..0cb20ebbd6
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_16_4d375d35a0d05d99c7becf591823d6b8._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 16"
+ date="2022-06-05T12:55:04Z"
+ content="""
+Nodatacow is not an option. It disables most safetly guarentees of btrfs (also w.r.t. RAID I believe) and is essentially a hack. As pointed out, it's also difficult to enable retroactively.
+
+Autodefrag is fundamentally broken and might result in overall worse performance. Also not an option.
+
+If a file is highly fragmented (which it might not be, amount of extents isn't an accurate representation fragmentation on btrfs), the correct measure is to `btrfs filesystem defragment` it.  
+If git-annex db fragmentation really is a common problem on btrfs (again, you'd have to do actual performance tests, I'm not aware of other means of measuring fragmentation), perhaps an automatic defrag similar to git's automatic gc would be appropriate. Keys DB files range in the Megabytes IME, so re-writing them every now and then shouldn't be a huge load.
+
+A file's fragmentation on-disk also shouldn't cause issues on DB writes because btrfs is CoW; new writes don't go where the old data was. It can only impact read performance.  
+Free space fragmentation might impact write performance but that's not something a userspace program can or should solve. @yarikoptic try `btrfs balance start -dusage=10`.
+
+I'm not sure I understand the situation 100% but poor DB write performance with hangouts and stalls can also be caused by long filesystem commits.  
+Writing a ton of file data to the filesystem only puts it in the cache and it gets written later. When that \"later\" occurs (usually after 30s), as I understand it, all of that data (potentially megabytes-gigabytes) needs to be written to disk *before* a DB's synchronous write returns.  
+
+This is essentially what git-annex does when getting data from a remote; it \"writes\" a file's data while downloading (without committing, so no disk activity whatsoever) and then does a syncs at the end (lots of disk activity) before starting the next download. A DB commit at the end can take for as long as (up to) 30s worth of transferred data takes to write. With a fast source/pipe, that could potentially be a lot of data.  
+Btrfs itself also has issues with insane commit times under some conditions (dedup especially), compounding the issue.
+
+It might be worth looking into the timings of `git annex get`'s write operations using `iostat --human 1`.
+
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_17_f687c46fb89009712247fe480f0f9566._comment b/doc/bugs/get_is_busy_doing_nothing/comment_17_f687c46fb89009712247fe480f0f9566._comment
new file mode 100644
index 0000000000..a834809b47
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_17_f687c46fb89009712247fe480f0f9566._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 17"
+ date="2022-06-06T14:00:05Z"
+ content="""
+FWIW4Joey:
+
+> I have made a standalone tarball built that way available here: https://downloads.kitenet.net/git-annex/linux/debuglocks/
+
+I have tried that version.  Placing similar load I just got some `move`s to fail ([our issue+idea to just call multiple times](https://github.com/dandi/dandisets/issues/176)) and some other oddities (not new, yet to figure out) but overall  -- I have not spotted similar MVar messages :-/ (filing a comment to \"jinx\" it, rerunning again -- seeing some `get`'s going ;))
+
+4Atemu:
+
+>  I'm not aware of other means of measuring fragmentation
+
+isn't https://github.com/kilobyte/compsize the one reporting number of fragments, thus degree of fragmentation?  As I summarized in [comment above](http://git-annex.branchable.com/bugs/get_is_busy_doing_nothing/#comment-9c647c8d9837d46e45675de30ebfeefc) I have used it + `btrfs fi defrag`.
+
+> It might be worth looking into the timings of git annex get's write operations using iostat --human 1.
+
+well -- it confirms that there is \"write silence\" for a while followed by a burst, e.g.:
+
+```
+Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
+dm-0             50.00       800.0k         0.0k         0.0k     800.0k       0.0k       0.0k
+dm-0              9.00       144.0k         0.0k         0.0k     144.0k       0.0k       0.0k
+dm-0              0.00         0.0k         0.0k         0.0k       0.0k       0.0k       0.0k
+dm-0              0.00         0.0k         0.0k         0.0k       0.0k       0.0k       0.0k
+dm-0              0.00         0.0k         0.0k         0.0k       0.0k       0.0k       0.0k
+dm-0              0.00         0.0k         0.0k         0.0k       0.0k       0.0k       0.0k
+dm-0              0.00         0.0k         0.0k         0.0k       0.0k       0.0k       0.0k
+dm-0             17.00         0.0k       207.3M         0.0k       0.0k     207.3M       0.0k
+dm-0             50.00         4.0M       319.9M         0.0k       4.0M     319.9M       0.0k
+dm-0            111.00        12.6M       365.8M         0.0k      12.6M     365.8M       0.0k
+dm-0             99.00         2.9M       685.5M         0.0k       2.9M     685.5M       0.0k
+dm-0            107.00         1.6M        10.4M         0.0k       1.6M      10.4M       0.0k
+dm-0            236.00         3.7M         0.0k         0.0k       3.7M       0.0k       0.0k
+dm-0            330.00         5.2M         0.0k         0.0k       5.2M       0.0k       0.0k
+dm-0            323.00         5.0M         0.0k         0.0k       5.0M       0.0k       0.0k
+```
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_18_0e5796c55c76dc8b37f9fd875d87eff0._comment b/doc/bugs/get_is_busy_doing_nothing/comment_18_0e5796c55c76dc8b37f9fd875d87eff0._comment
new file mode 100644
index 0000000000..29d86fdaf5
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_18_0e5796c55c76dc8b37f9fd875d87eff0._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 18"
+ date="2022-06-06T14:50:16Z"
+ content="""
+> I have made a standalone tarball built that way available here: https://downloads.kitenet.net/git-annex/linux/debuglocks/
+> It should display a backtrace on stderr when the MVar deadlock happens.
+
+jinxing helped ... thought I thought to complain that I don't see any traceback but apparently it is due to `-J5` (I guess) and lines being ovrewritten, but I managed to `Ctrl-s` at a point showing
+
+```
+get 0/0/0/3/5/50 (from web...)
+MVar deadlock detected CallStack (from HasCallStack):
+  debugLocks, called at ./Database/Queue.hs:55:30 in main:Database.Queue
+  thread blocked indefinitely in an MVar operation
+(Delaying 1s before retrying....)
+```
+
+which when I let it go became smth like
+
+```
+get 0/0/0/3/0/98 (from web...)
+  thread blocked indefinitely in an MVar operation
+(Delaying 1s before retrying....)
+ok
+get 0/0/0/3/1/111 (from web...) ok
+```
+
+and reconfirmed for those in screenlog I quickly collected:
+
+```
+(base) dandi@drogon:~$ grep debugLocks screenlog.3
+  debugLocks, called at ./Database/Queue.hs:55:30 in main:Database.Queue
+  debugLocks, called at ./Database/Queue.hs:55:30 in main:Database.Queue
+  debugLocks, called at ./Database/Queue.hs:55:30 in main:Database.Queue
+  debugLocks, called at ./Database/Queue.hs:55:30 in main:Database.Queue
+  debugLocks, called at ./Database/Queue.hs:55:30 in main:Database.Queue
+```
+
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_19_216aefa4a78d13cc0c46780161921a36._comment b/doc/bugs/get_is_busy_doing_nothing/comment_19_216aefa4a78d13cc0c46780161921a36._comment
new file mode 100644
index 0000000000..06bbb569ff
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_19_216aefa4a78d13cc0c46780161921a36._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2022-06-06T15:55:15Z"
+ content="""
+So in flushDbQueue, which is waiting for all queued writes to complete.
+When the write failed with an exception, a previous flushDbQueue
+would have left the queue's MVar empty.
+
+So, now I understand how the original problem can lead to this MVar
+problem. And I've fixed that part of it. Now a write failing this way will
+refill the queue with what it failed to write. So it will try to write it
+again later.
+
+This flushDbQueue probably also explains the hang at
+"recording state in git" since there is also a final flushDbQueue at that
+point, and I guess it fails to detect a deadlock at that point so just
+hangs forever. So my fix should also avoid that.
+
+None of which means this is fixed, really, just the fallout from the
+write timeout problem will be less severe now.
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_1_ea9363fac84619b72d6c9f2a3a5c2d6d._comment b/doc/bugs/get_is_busy_doing_nothing/comment_1_ea9363fac84619b72d6c9f2a3a5c2d6d._comment
new file mode 100644
index 0000000000..9e4e3b6fe6
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_1_ea9363fac84619b72d6c9f2a3a5c2d6d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-18T20:53:33Z"
+ content="""
+git-annex has stall detection, but it's not enabled by default, because how
+slow a "stall" is can vary quite a bit. Setting annex.stalldetection would
+probably help.
+
+Plenty of http clients can stall out if there's a network problem. For
+example, wget that and pull the ethernet cable; you'll see wget hang for at
+least as long as it took me to write this comment. Since it's just waiting
+for a read, it will block until the TCP connection closes, and situations can
+cause dead TCP connections to not close for a long time.
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_20_981cc786be798a612046d207c0f85955._comment b/doc/bugs/get_is_busy_doing_nothing/comment_20_981cc786be798a612046d207c0f85955._comment
new file mode 100644
index 0000000000..9b8e965f0d
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_20_981cc786be798a612046d207c0f85955._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 20"""
+ date="2022-06-06T16:12:53Z"
+ content="""
+It does occur to me that one "solution" might be to have flushDbQueue
+not rethrow the exception, and just re-enqueue the write. Then, if a write
+fails in the middle of a long git-annex command, it will just queue up
+sqlite changes until later. And hopefully whatever is preventing writing to
+the database at that time would later resolve itself. At shutdown, it would
+need to make sure to flush the remaining queue and not ignore a write
+failure then.
+
+That has the potential problem that, if the write keeps failing, it might
+end up buffering a large number of writes in memory, and since the queue
+would be full, it would be trying to write every time. So it would both use
+an ever-growing amount of memory, and be slowed down by the write attempts.
+
+Still, it does give it something better to do while the write is failing
+than sleeping and retrying, eg to do the rest of the work it's been asked
+to do.
+
+(Update: Reads from a database first call flushDbQueue, and it would
+not be safe for that to return without actually writing to the database,
+since the read would then see possible stale information. It turns
+out that `git-annex get` does do a database read per file (getAssociatedFiles).
+So it seems this approach will not work.)
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_21_eabe406ab0d6e71c3f5f30908016a592._comment b/doc/bugs/get_is_busy_doing_nothing/comment_21_eabe406ab0d6e71c3f5f30908016a592._comment
new file mode 100644
index 0000000000..2836a8287e
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_21_eabe406ab0d6e71c3f5f30908016a592._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: comment 16"""
+ date="2022-06-06T16:20:55Z"
+ content="""
+@Atemu, that seems like at least a plausible theory, that disk write
+pressure (eg from getting annex objects) is causing sqlite writes to take a
+long time. Increasing the wait time from the current 10 seconds would make
+sense if that's what's happening.
+
+The somewhat weird thing is that, with a single git-annex process, no
+matter the number of jobs, it only has a single database handle open,
+and so it should not be possible for one write to still be happening when
+a second write happens. Unless, of course, sqlite is doing something behind
+my back, like finishing the write in a separate thread? Or, of course,
+there might be a second process that has somehow not been visible..
+
+So, I've added some debugging of when it commits to the database. 
+@yarik, please get an updated build with commit
+5da1a785086910c32559a46f9110779d765af0cd,
+and try after setting:
+
+	git config annex.debug true
+	git config annex.debugfilter Database.Handle
+
+This should tell us if there are somehow multiple writers at the same time,
+and also will tell us the timing of how long it is taking to commit to the
+db.
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_22_711bf1ba8688bdc3bf33e7103340bc11._comment b/doc/bugs/get_is_busy_doing_nothing/comment_22_711bf1ba8688bdc3bf33e7103340bc11._comment
new file mode 100644
index 0000000000..c8b7cf29ff
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_22_711bf1ba8688bdc3bf33e7103340bc11._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 22"
+ date="2022-06-06T17:22:41Z"
+ content="""
+> So, I've added some debugging of when it commits to the database. @yarik, please get an updated build with commit 5da1a785086910c32559a46f9110779d765af0cd,
+
+it doesn't need custom build with DebugLocks right?  Then I will \"wait\" for daily build of datalad/git-annex to happen and test then... meanwhile also running `git clone https://github.com/dandizarrs/4ea5a47f-10d6-48a7-8c1e-ce6ce511f9a7; cd 4ea5a47f-10d6-48a7-8c1e-ce6ce511f9a7; git annex get -J25 . ` on smaug to see if reproduces there (but it is not busy IO so most likely would finish without whining; boosted to -J25 to \"make it harder\"). `smaug` is also BTRFS although underlying storage is setup differently (no LVM)
+
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_23_3671d133d18f6722901ed01a1fa38164._comment b/doc/bugs/get_is_busy_doing_nothing/comment_23_3671d133d18f6722901ed01a1fa38164._comment
new file mode 100644
index 0000000000..fedf75d417
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_23_3671d133d18f6722901ed01a1fa38164._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 23"
+ date="2022-06-07T12:07:29Z"
+ content="""
+> isn't https://github.com/kilobyte/compsize the one reporting number of fragments, thus degree of fragmentation?
+
+It is reporting the number of extents, just like `filefrag` does.
+
+Non-CoW filesystems overwrite data in-place, so there is never a need to create new fragments for (pre-allocated) in-file writes. New extents are only created when the free space at the file's location doesn't allow for further expansion and fragmentation is required.
+
+\# of extents is therefore indicative of fragmentation in non-CoW filesystems but this does not hold true in CoW filesystems like btrfs. If you wrote 1M to the first half of a 2M file and then 1M to the latter, you'll have 2 1M extents that might be right behind each other on-disk due to CoW.
+
+With transparent compression in the mix, this gets even worse because extent size caps out at 128K. A 1M incompressible file will have 8 extents/\"fragments\" at minimum despite its data possibly being layed out fully sequentially.
+
+> there is \"write silence\" for a while followed by a burst
+
+Does this burst occur at the same time the DB times out?
+
+If you take a look at `top`/`iotop`, which threads are using CPU time and writing? Look out for btrfs-transacti and btrfs-endio-wri.
+
+> disk write pressure (eg from getting annex objects) is causing sqlite writes to take a long time.
+
+The problem isn't exactly that. Sure, write activity will make DB operations take longer (larger queue -> higher latency) but this effect should stay within reasonable bounds. I think that the actual big problem is that the object writes are buffered and not written until they hit a deadline after which they *must* be written ASAP. I believe in such a situation, any other write operation must wait until those dirty pages are committed and a commit can take quite a while in btrfs due to integrity guarantees.
+
+I think it'd be better to avoid these dirty page deadline commits, start writing out data sooner (ideally immediately) and block the source if the target can't keep up.  
+IMO there's not much point in letting the target seem to \"write\" at a higher speed than it can actually take in a case of sequential writes like git-annex' object transfer. It'll only lead to wasted memory and erratic IO. (I guess a small buffer (something that could be flushed in a few seconds) could be helpful in smoothing over a little variance.)
+
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_24_054db0e62994590631737b9bd768d901._comment b/doc/bugs/get_is_busy_doing_nothing/comment_24_054db0e62994590631737b9bd768d901._comment
new file mode 100644
index 0000000000..f2a528db56
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_24_054db0e62994590631737b9bd768d901._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 24"""
+ date="2022-06-08T16:53:06Z"
+ content="""
+Right, DebugLocks is not needed. The current daily build should work now.
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_25_4766362f74f135887d5b6103db9a8a06._comment b/doc/bugs/get_is_busy_doing_nothing/comment_25_4766362f74f135887d5b6103db9a8a06._comment
new file mode 100644
index 0000000000..6fb6cd3c37
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_25_4766362f74f135887d5b6103db9a8a06._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 25"""
+ date="2022-10-11T17:17:13Z"
+ content="""
+Revisiting this, I don't understand why the htop at the top of this page
+lists so many `git-annex get` processes. They all seem to be children
+of a single parent `git-annex get` process. But `git-annex get` does
+not fork children like those. I wonder if perhaps those child
+processes were forked() to do something else, but somehow hung before
+they could exec?!
+
+By comment #2,  annex.stalldetection  is enabled, so `git-annex get`
+runs 5 `git-annex transferrer` processes. Each of those can write to the
+database, so concurrent sqlite writes can happen. So, my "re: comment 16"
+comment was off-base in thinking there was a single git-annex process.
+And so, I don't think the debug info requested in that comment is needed.
+
+Also, it turns out that the database queue is being flushed after every
+file it gets, which is causing a sqlite write per file. So there are a 
+lot of sqlite writes happening, which probably makes this issue much more
+likely to occur, on systems with slow enough disk IO that it does occur. 
+Especially if the files are relatively small. 
+
+The reason for the queue flush is partly that Annex.run forces a queue
+flush after every action. That could, I think be avoided. That was only
+done to make sure the queue is flushed before the program exits, which 
+should be able to be handled in a different way. But also,
+the queue has to be flushed before reading from the database in order
+for the read to see current information. In the `git-annex get` case,
+it queues a change to the inode cache, and then reads the associated
+files. To avoid that, it would need to keep track of the two different
+tables in the keys db, and flush the queue only when querying a table
+that a write had been queued to. That would be worth doing
+just to generally speed up `git-annex get`. A quick benchmark shows
+a get of 1000 small files that takes 17s will only take 12s once that's
+done. And that's on a fast SSD, probably much more on a hard drive!
+
+So I don't have a full solution, but speeding git-annex up significantly and
+also making whatever the problem in this bug is probably much less likely
+to occur is a good next step..
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_26_d02b310b007b304e0eda23bd5e565851._comment b/doc/bugs/get_is_busy_doing_nothing/comment_26_d02b310b007b304e0eda23bd5e565851._comment
new file mode 100644
index 0000000000..3aafff13ff
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_26_d02b310b007b304e0eda23bd5e565851._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 26"""
+ date="2022-10-12T19:34:05Z"
+ content="""
+I've avoided the excessive sqlite database writes. Which doubled the speed
+of git-annex in some circumstances, wow!
+
+@yoh see if it still happens once you upgrade to a git-annex
+with [[!commit 6fbd337e34cd62881ed5e21616e9c00d7bf35378]].
+
+It would be possible for git-annex to do its own locking around writes
+to the sqlite database. That would surely avoid any problem that sqlite might
+have that would cause ErrorBusy. I want to think some about 
+[[todo/withExclusiveLock_blocking_issue]] first.
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_27_45168f110bded2f8c8f9777e1edda945._comment b/doc/bugs/get_is_busy_doing_nothing/comment_27_45168f110bded2f8c8f9777e1edda945._comment
new file mode 100644
index 0000000000..c69a88ec49
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_27_45168f110bded2f8c8f9777e1edda945._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 27"""
+ date="2022-10-17T18:49:47Z"
+ content="""
+I've made it retry as long as necessary on ErrorBusy, while also noticing
+when another process is suspended and has the sqlite database locked,
+and avoiding retrying forever in that situation.
+
+This seems to be as far as I can take this bug report, I don't know
+100% for sure if I've fixed it, but git-annex's behavior should certainly
+be improved.
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_2_8b11e01481065814d2b35f9d728df9f7._comment b/doc/bugs/get_is_busy_doing_nothing/comment_2_8b11e01481065814d2b35f9d728df9f7._comment
new file mode 100644
index 0000000000..7d771fc28a
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_2_8b11e01481065814d2b35f9d728df9f7._comment
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-05-24T20:35:58Z"
+ content="""
+FWIW, I have added 
+```
+(base) dandi@drogon:/mnt/backup/dandi/dandisets$ git config  annex.stalldetection
+1KB/120s
+```
+and I see 4 days old (now it is `Tue 24 May 2022 04:34:33 PM EDT`)
+
+```
+dandi    1682561  0.0  0.1 173328 73808 ?        S    May20   0:02                 python -m tools.backups2datalad -l DEBUG -J 5 --target /mnt/backup/dandi/dandisets populate dandi-dandisets-dropbox
+dandi    1683786  0.0  0.0 1075306796 61632 ?    Sl   May20   2:49                   git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+dandi    1683813  0.4  0.0 1074200772 46872 ?    Sl   May20  26:18                     /home/dandi/miniconda3/envs/dandisets/bin/git-annex transferrer -c annex.retry=3
+dandi    1683820  0.0  0.0 109896  2504 ?        S    May20   0:00                       git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.retry=3 cat-file --batch
+dandi    1683819  0.4  0.0 1074200772 48152 ?    Sl   May20  24:56                     /home/dandi/miniconda3/envs/dandisets/bin/git-annex transferrer -c annex.retry=3
+dandi    1683826  0.0  0.0 109896  2320 ?        S    May20   0:00                       git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.retry=3 cat-file --batch
+dandi    1683830  0.4  0.0 1074200772 47092 ?    Sl   May20  26:27                     /home/dandi/miniconda3/envs/dandisets/bin/git-annex transferrer -c annex.retry=3
+dandi    1683843  0.0  0.0 109896  2288 ?        S    May20   0:00                       git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.retry=3 cat-file --batch
+dandi    1683846  0.4  0.0 1074200804 47932 ?    Sl   May20  25:12                     /home/dandi/miniconda3/envs/dandisets/bin/git-annex transferrer -c annex.retry=3
+dandi    1683852  0.0  0.0 109896  2460 ?        S    May20   0:00                       git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.retry=3 cat-file --batch
+dandi    1683863  0.0  0.0 1074127072 47300 ?    Sl   May20   0:26                     /home/dandi/miniconda3/envs/dandisets/bin/git-annex transferrer -c annex.retry=3
+dandi    1683869  0.0  0.0 109896  3244 ?        S    May20   0:00                       git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.retry=3 cat-file --batch
+```
+which smells like stuck... looking at open files, I see the stderr to be redirected and looking into it:
+
+```
+(base) dandi@drogon:/mnt/backup/dandi/dandisets$ tail /mnt/backup/dandi/dandisets/.git/tmp/stderr
+(Delaying 1s before retrying....)
+ok
+get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-MotorCortexS08_stain-Calretinin_chunk-00_SPIM.ome.tif (from web...) 
+  thread blocked indefinitely in an MVar operation
+(Delaying 1s before retrying....)
+ok
+get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-MotorCortexS08_stain-Nuclei_chunk-05_SPIM.ome.tif (from web...) 
+  thread blocked indefinitely in an MVar operation
+(Delaying 1s before retrying....)
+ok
+```
+
+and I do not think that file saw any updates (`tail -f ` is silent):
+
+```
+(base) dandi@drogon:/mnt/backup/dandi/dandisets$ stat /mnt/backup/dandi/dandisets/.git/tmp/stderr
+  File: /mnt/backup/dandi/dandisets/.git/tmp/stderr
+  Size: 28944     	Blocks: 64         IO Block: 4096   regular file
+Device: 28h/40d	Inode: 34338261    Links: 1
+Access: (0644/-rw-r--r--)  Uid: ( 1001/   dandi)   Gid: ( 1015/   dandi)
+Access: 2021-12-16 17:10:51.838720227 -0500
+Modify: 2022-05-20 21:10:19.383226789 -0400
+Change: 2022-05-20 21:10:19.383226789 -0400
+ Birth: 2021-12-16 17:10:51.838720227 -0500
+```
+
+NB I got a bit surprised that we dump to such possibly shared stderr file, but it is done within `tools/backups2datalad-cron` which we guard with flock to not run more than 1 instance so it is ok.
+
+Would you recommend to look at anything specific or may be `thread blocked indefinitely in an MVar operation` is giving ideas? (FTR: I believe the annex is `10.20220322-g7b64dea`)
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_3_f06b9085e1d48298c6c1739afb17d2bb._comment b/doc/bugs/get_is_busy_doing_nothing/comment_3_f06b9085e1d48298c6c1739afb17d2bb._comment
new file mode 100644
index 0000000000..3194137dd9
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_3_f06b9085e1d48298c6c1739afb17d2bb._comment
@@ -0,0 +1,84 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2022-05-24T21:05:03Z"
+ content="""
+I should have looked above in that stderr where interesting part begins with possibly relevant extra complaints:
+
+```
+    52  2022-05-20T19:27:59-0400 [INFO    ] backups2datalad Downloading files for Dandiset 000026
+    53  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS10_stain-NeuN_chunk-04_SPIM.ome.tif (from web...) 
+    54    failed to commit changes to sqlite database: Just SQLite3 returned ErrorBusy while attempting to perform step: database is locked
+    55    CallStack (from HasCallStack):
+    56      error, called at ./Database/Handle.hs:91:26 in main:Database.Handle
+    57  (Delaying 1s before retrying....)
+    58  ok
+    59  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS10_stain-NeuN_chunk-02_SPIM.ome.tif (from web...) 
+    60    thread blocked indefinitely in an MVar operation
+    61  (Delaying 1s before retrying....)
+    62  ok
+    63  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS12_stain-Calretinin_chunk-00_SPIM.ome.tif (from web...) 
+    64    thread blocked indefinitely in an MVar operation
+    65  (Delaying 1s before retrying....)
+    66  ok
+    67  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS12_stain-NeuN_chunk-01_SPIM.ome.tif (from web...) 
+    68    thread blocked indefinitely in an MVar operation
+    69  (Delaying 1s before retrying....)
+    70  ok
+    71  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS12_stain-Nuclei_chunk-01_SPIM.ome.tif (from web...) 
+    72    thread blocked indefinitely in an MVar operation
+    73  (Delaying 1s before retrying....)
+    74  ok
+    75  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS12_stain-Nuclei_chunk-05_SPIM.ome.tif (from web...) 
+    76    failed to commit changes to sqlite database: Just SQLite3 returned ErrorBusy while attempting to perform step: database is locked
+    77    CallStack (from HasCallStack):
+    78      error, called at ./Database/Handle.hs:91:26 in main:Database.Handle
+    79  (Delaying 1s before retrying....)
+    80  ok
+    81  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS12_stain-Nuclei_chunk-06_SPIM.ome.tif (from web...) 
+    82    thread blocked indefinitely in an MVar operation
+    83  (Delaying 1s before retrying....)
+    84  ok
+    85  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS13_stain-NeuN_chunk-02_SPIM.ome.tif (from web...) 
+    86    thread blocked indefinitely in an MVar operation
+    87  (Delaying 1s before retrying....)
+    88  ok
+    89  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS14_stain-Calretinin_chunk-01_SPIM.ome.tif (from web...) 
+    90    thread blocked indefinitely in an MVar operation
+    91  (Delaying 1s before retrying....)
+    92  ok
+    93  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS13_stain-Nuclei_chunk-05_SPIM.ome.tif (from web...) 
+    94    thread blocked indefinitely in an MVar operation
+    95  (Delaying 1s before retrying....)
+    96  ok
+    97  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS14_stain-NeuN_chunk-07_SPIM.ome.tif (from web...) 
+    98    thread blocked indefinitely in an MVar operation
+    99  (Delaying 1s before retrying....)
+   100  ok
+   101  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS13_stain-Nuclei_chunk-08_SPIM.ome.tif (from web...) 
+   102    thread blocked indefinitely in an MVar operation
+   103  (Delaying 1s before retrying....)
+   104  ok
+   105  get rawdata/sub-I46/ses-SPIM/micr/sub-I46_ses-SPIM_sample-BrocaAreaS14_stain-NeuN_chunk-10_SPIM.ome.tif (from web...) 
+   106    thread blocked indefinitely in an MVar operation
+   107  (Delaying 1s before retrying....)
+```
+
+`strace -f -p 1683786` ends with
+
+```
+[pid 1683799] <... sched_yield resumed>) = 0
+[pid 1683798] sched_yield( <unfinished ...>
+[pid 1683810] futex(0x7fd5cc000c08, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
+[pid 1683803] futex(0x7fd5c0000be8, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
+[pid 1683799] futex(0x5b180ec, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
+[pid 1683798] <... sched_yield resumed>) = 0
+[pid 1683798] futex(0x7fd5d8000bec, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
+[pid 1683787] <... read resumed>\"\1\0\0\0\0\0\0\0\", 8) = 8
+[pid 1683787] futex(0x4a4844c, FUTEX_WAIT_PRIVATE, 0, NULL
+```
+
+I will now interrupt that process to \"proceed\", knowing what to do next time would be helpful
+
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_4_422aed4fc2729483e1479cadd54f45e1._comment b/doc/bugs/get_is_busy_doing_nothing/comment_4_422aed4fc2729483e1479cadd54f45e1._comment
new file mode 100644
index 0000000000..f941ff5e26
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_4_422aed4fc2729483e1479cadd54f45e1._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-05-25T16:49:30Z"
+ content="""
+Concurrent writes to sqlite (in WAL mode) can fail, 
+but git-annex deals with that by retrying 100 times (once every 0.1 seconds).
+So apparently other writes kept making it fail, or the database is somehow
+stuck locked.
+
+I think that the MVar blocking happens as a consequence of the sqlite
+write failing and is not worth investigating separately, probably.
+
+What filesystem is this happening on?
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_5_28da709b2152b1ce1d0c926b099febad._comment b/doc/bugs/get_is_busy_doing_nothing/comment_5_28da709b2152b1ce1d0c926b099febad._comment
new file mode 100644
index 0000000000..3accf28615
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_5_28da709b2152b1ce1d0c926b099febad._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="What filesystem is this happening on?"
+ date="2022-05-25T21:09:38Z"
+ content="""
+BTRFS
+
+```
+/dev/mapper/vg_backup-lv_backup on /mnt/backup type btrfs (rw,noatime,compress=lzo,space_cache=v2,subvolid=5,subvol=/,x-systemd.mount-timeout=30m)
+
+```
+
+over LVM over mdadm raid6 arrays ;)
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_6_c9594a39c44f7fd6649c418dbb5d2c59._comment b/doc/bugs/get_is_busy_doing_nothing/comment_6_c9594a39c44f7fd6649c418dbb5d2c59._comment
new file mode 100644
index 0000000000..75c562dfdf
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_6_c9594a39c44f7fd6649c418dbb5d2c59._comment
@@ -0,0 +1,97 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="another/different? stall"
+ date="2022-05-26T14:31:33Z"
+ content="""
+next one stalled at the end at
+```
+get sub-dt15/sub-dt15_ses-dt15_6705um_200213_091923_ecephys.nwb (from web...) ok
+get sub-bruce/sub-bruce_ses-bruce_0um_210115_155615_ecephys.nwb (from web...) ok
+get sub-bruce/sub-bruce_ses-bruce_0um_210110_171041_ecephys.nwb (from web...) ok
+get sub-ros/sub-ros_ses-ros_210320_091833_ecephys.nwb (from web...) ok
+(recording state in git...)
+
+```
+with recent `gets` not complaining about being unable to lock, only some longer before did, e.g.
+
+```
+get sub-CGM49/sub-CGM49_ses-CGM49_512um_210227_093748_ecephys.nwb (from web...)
+  failed to commit changes to sqlite database: Just SQLite3 returned ErrorBusy while attempting to perform step: database is locked
+  CallStack (from HasCallStack):
+    error, called at ./Database/Handle.hs:91:26 in main:Database.Handle
+(Delaying 1s before retrying....)
+
+44%   9.58 GiB         57 MiB/s 3m36s
+get sub-CGM52/sub-CGM52_ses-CGM52_0um_210216_144320_ecephys.nwb (from web...)
+```
+
+```
+dandi    2013903  0.0  0.0   5492     0 pts/1    S+   May25   0:00       flock -E 0 -e -n /home/dandi/.run/backup2datalad-cron.lock bash -c /mnt/backup/dandi/dandisets/tools/backups2datalad-cron
+dandi    2013904  0.0  0.0   7024  1892 pts/1    S+   May25   0:00         /bin/bash /mnt/backup/dandi/dandisets/tools/backups2datalad-cron
+dandi    2013933  0.0  0.0   7024  1520 pts/1    S+   May25   0:00           /bin/bash /mnt/backup/dandi/dandisets/tools/backups2datalad-cron
+dandi    2113421  0.0  0.0 321448  3140 pts/1    S+   May25   0:04             python -m tools.backups2datalad -l DEBUG -J 5 --target /mnt/backup/dandi/dandisets populate dandi-dandisets-dropbox
+dandi    2151114  0.8  0.0 1075306800 32416 pts/1 Sl+ May25   9:39               git-annex get -c annex.retry=3 --jobs 5 --from=web --not --in dandi-dandisets-dropbox --and --not --in here
+dandi    2151142 11.6  0.0 1074200808 37352 pts/1 Sl  May25 138:50                 /home/dandi/miniconda3/envs/dandisets/bin/git-annex transferrer -c annex.retry=3
+dandi    2151170  0.0  0.0  10640  1260 pts/1    S    May25   0:00                   git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.retry=3 cat-file --batch
+dandi    2151143 12.9  0.0 1074200808 36384 pts/1 Sl  May25 153:23                 /home/dandi/miniconda3/envs/dandisets/bin/git-annex transferrer -c annex.retry=3
+dandi    2151158  0.0  0.0  10640  1256 pts/1    S    May25   0:00                   git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.retry=3 cat-file --batch
+dandi    2151147 12.7  0.0 1074127044 35308 pts/1 Sl  May25 150:49                 /home/dandi/miniconda3/envs/dandisets/bin/git-annex transferrer -c annex.retry=3
+dandi    2151160  0.0  0.0  10640  1232 pts/1    S    May25   0:00                   git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.retry=3 cat-file --batch
+dandi    2151148 16.3  0.0 1074200776 35596 pts/1 Sl  May25 193:42                 /home/dandi/miniconda3/envs/dandisets/bin/git-annex transferrer -c annex.retry=3
+dandi    2151168  0.0  0.0  10640  1336 pts/1    S    May25   0:00                   git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.retry=3 cat-file --batch
+dandi    2151161 13.0  0.0 1074200808 32060 pts/1 Sl  May25 155:15                 /home/dandi/miniconda3/envs/dandisets/bin/git-annex transferrer -c annex.retry=3
+dandi    2151177  0.0  0.0  10640  1096 pts/1    S    May25   0:00                   git --git-dir=.git --work-tree=. --literal-pathspecs -c annex.retry=3 cat-file --batch
+```
+
+strace end is 
+
+```
+[pid 2151125] sched_yield( <unfinished ...>
+[pid 2151129] <... sched_yield resumed>) = 0
+[pid 2151125] <... sched_yield resumed>) = 0
+[pid 2151129] sched_yield()             = 0
+[pid 2151125] sched_yield( <unfinished ...>
+[pid 2151129] sched_yield( <unfinished ...>
+[pid 2151125] <... sched_yield resumed>) = 0
+[pid 2151129] <... sched_yield resumed>) = 0
+[pid 2151137] rt_sigprocmask(SIG_SETMASK, [],  <unfinished ...>
+[pid 2151126] sched_yield( <unfinished ...>
+[pid 2151137] <... rt_sigprocmask resumed>NULL, 8) = 0
+[pid 2151129] sched_yield( <unfinished ...>
+[pid 2151125] sched_yield( <unfinished ...>
+[pid 2151137] futex(0x7fe75c000be8, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
+[pid 2151129] <... sched_yield resumed>) = 0
+[pid 2151125] <... sched_yield resumed>) = 0
+[pid 2151129] futex(0x7fe740000be8, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
+[pid 2151125] futex(0x52eae6c, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
+[pid 2151126] <... sched_yield resumed>) = 0
+[pid 2151126] futex(0x52eb068, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
+[pid 2151115] <... read resumed>\"\1\0\0\0\0\0\0\0\", 8) = 8
+[pid 2151115] futex(0x4a4844c, FUTEX_WAIT_PRIVATE, 0, NULL^Cstrace: Process 2151114 detached
+strace: Process 2151115 detached
+ <detached ...>
+strace: Process 2151116 detached
+strace: Process 2151117 detached
+strace: Process 2151119 detached
+strace: Process 2151124 detached
+strace: Process 2151125 detached
+strace: Process 2151126 detached
+strace: Process 2151127 detached
+strace: Process 2151128 detached
+strace: Process 2151129 detached
+strace: Process 2151132 detached
+strace: Process 2151133 detached
+strace: Process 2151136 detached
+strace: Process 2151137 detached
+strace: Process 2151138 detached
+strace: Process 2151139 detached
+strace: Process 2151140 detached
+strace: Process 2677004 detached
+strace: Process 2925046 detached
+strace: Process 3026979 detached
+strace: Process 3027102 detached
+```
+
+I have now killed that `get` process and restarted our backup beastie (should now get to `copy` those `get`ed files into backup)
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_7_7a7f6e9793817884a309632e4ebaba1b._comment b/doc/bugs/get_is_busy_doing_nothing/comment_7_7a7f6e9793817884a309632e4ebaba1b._comment
new file mode 100644
index 0000000000..f8b6f2d884
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_7_7a7f6e9793817884a309632e4ebaba1b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-05-31T17:16:26Z"
+ content="""
+It seems that sqlite on BTRFS is somewhat problimatic performance-wise. 
+See this blog post from Colin Walters where firefox was periodically
+freezing due to sqlite, and apparently the database file was highly fragmented.
+<https://blog.verbum.org/2020/07/14/on-btrfs/>
+
+Mounting with nodatacow or autodefrag may help, or 
+`chattr +C .git/annex/keysdb/db`
+
+Possibly being slow could explain the ErrorBusy: If there are somehow
+two processes writing to the database and one is being slow, then
+the other one could get ErrorBusy repeatedly for the 10 seconds it takes
+git-annex to give up.
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_8_0b507f49b6c23d9a9e1557fe96ad58b1._comment b/doc/bugs/get_is_busy_doing_nothing/comment_8_0b507f49b6c23d9a9e1557fe96ad58b1._comment
new file mode 100644
index 0000000000..685ac8df9e
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_8_0b507f49b6c23d9a9e1557fe96ad58b1._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 8"
+ date="2022-05-31T19:07:59Z"
+ content="""
+Hi Joey -- thanks for digging all that up!  On my laptop I also use BTRFS (on top of dm encrypted volume) and always thought to check why `notmuch new` running at the end of offlineimap for me at times holds the entire laptop \"stalled\" for a few seconds.  I think you gave me the answer!  Following [this article](https://wiki.tnonline.net/w/Btrfs/Defrag) and defragmented `.glass` files under `~/Maildir/.notmuch/xapian` . Let's see now in the long run if I encounter similar stalling ;)
+
+But I am not yet entirely sure if it really answers the \"total stall\" situation -- slow should still work.
+
+FWIW -- I have checked in two repositories which were mentioned in this issue, in one (000233) the `keysdb/db` was ok -- just 30 refs, but the 000026 (a heavy beast ;)) had 2994:
+
+```
+drogon:/mnt/backup/dandi/dandisets/000026/.git/annex# /usr/sbin/compsize keysdb/db 
+Processed 1 file, 2643 regular extents (2994 refs), 0 inline.
+Type       Perc     Disk Usage   Uncompressed Referenced  
+TOTAL       98%       20M          20M          14M       
+none       100%       19M          19M          13M       
+lzo         46%      352K         752K         400K 
+```
+FWIW I defraged it into 1 ref.  And then did the `chattr +C` on all repos I have there so far.  Let's see if that anyhow helps.
+
+PS Have been using BTRFS on that server and smaug for almost 10 years now and had thousands of git annex repos... I guess these particular ones are pushing some limits  ;)
+"""]]
diff --git a/doc/bugs/get_is_busy_doing_nothing/comment_9_6209db4f931bced0f6782d231aa45452._comment b/doc/bugs/get_is_busy_doing_nothing/comment_9_6209db4f931bced0f6782d231aa45452._comment
new file mode 100644
index 0000000000..0c8eeced0f
--- /dev/null
+++ b/doc/bugs/get_is_busy_doing_nothing/comment_9_6209db4f931bced0f6782d231aa45452._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 9"
+ date="2022-05-31T19:17:05Z"
+ content="""
+interesting!  For some (only some) repos chattr didn't work
+
+```
+(base) dandi@drogon:/mnt/backup/dandi/dandisets$ chattr +C */.git/annex/keysdb/db
+chattr: Invalid argument while setting flags on 000008/.git/annex/keysdb/db
+chattr: Invalid argument while setting flags on 000019/.git/annex/keysdb/db
+...
+```
+
+and that is I guess because they already have 
+
+```
+(base) dandi@drogon:/mnt/backup/dandi/dandisets$ lsattr 000228/.git/annex/keysdb/db
+---------------------m 000228/.git/annex/keysdb/db
+
+(base) dandi@drogon:/mnt/backup/dandi/dandisets$ lsattr -l  000228/.git/annex/keysdb/db
+000228/.git/annex/keysdb/db  Dont_Compress
+```
+
+and I don't recall setting that attr for those some.  Does `git-annex` do that since some time recently or in the past? 
+
+PS `chattr +C` seems to have no effect on `keysdb/db`:
+
+```
+(base) dandi@drogon:/mnt/backup/dandi/dandisets$ chattr +C 000246/.git/annex/keysdb/db
+(base) dandi@drogon:/mnt/backup/dandi/dandisets$ lsattr 000246/.git/annex/keysdb/db
+---------------------- 000246/.git/annex/keysdb/db
+(base) dandi@drogon:/mnt/backup/dandi/dandisets$ file 000246/.git/annex/keysdb/db
+000246/.git/annex/keysdb/db: SQLite 3.x database, last written using SQLite version 3033000
+```
+
+but it does add it for e.g. `000246/.git/annex/keysdb.lck` ... heh heh odd
+
+"""]]
diff --git a/doc/bugs/gets_stuck_in_Remote_Tests___40____63____41___while_running_on_OSX_with_HOME_on_crippled_FS.mdwn b/doc/bugs/gets_stuck_in_Remote_Tests___40____63____41___while_running_on_OSX_with_HOME_on_crippled_FS.mdwn
new file mode 100644
index 0000000000..ad09709061
--- /dev/null
+++ b/doc/bugs/gets_stuck_in_Remote_Tests___40____63____41___while_running_on_OSX_with_HOME_on_crippled_FS.mdwn
@@ -0,0 +1,32 @@
+### Please describe the problem.
+
+[https://github.com/jwodder](https://github.com/jwodder) is cooking up OS X build recipe (+testing) in [datalad-extensions/pull/31](https://github.com/datalad/datalad-extensions/pull/31).  The test step where HOME is pointing to a crippled FS (see [workflow + scripts in PR](https://github.com/datalad/datalad-extensions/pull/31/files) for details of the setup) was running for 3h and I canceled it, so the [log]() showed
+
+### What version of git-annex are you using? On what operating system?
+
+tired me failed to find a clear version printed anywhere  (will be added) but it happened earlier today so some state a few hours back from 8.20200908-9-g8955ac39f
+
+### Please provide any additional information below.
+
+[[!format sh """
+  Remote Tests
+    remote type directory
+  Detected a filesystem without fifo support.
+  Disabling ssh connection caching.
+  Filesystem allows writing to files whose write bit is not set.
+  Detected a crippled filesystem.
+  Disabling core.symlinks.
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+Switched to branch 'adjusted/master(unlocked)'
+git-annex: openFile: resource busy (file is locked)
+      init:                                               FAIL (2.18s)
+        Test.hs:249:
+        init failed
+      unavailable remote
+##[error]The operation was canceled.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+depends on the weather, but I am a rain magnet.
+
diff --git a/doc/bugs/git-annex-copy_fails_with___34__thread_blocked_indefinitely_in_an_STM_transaction__34__.mdwn b/doc/bugs/git-annex-copy_fails_with___34__thread_blocked_indefinitely_in_an_STM_transaction__34__.mdwn
new file mode 100644
index 0000000000..59221c2380
--- /dev/null
+++ b/doc/bugs/git-annex-copy_fails_with___34__thread_blocked_indefinitely_in_an_STM_transaction__34__.mdwn
@@ -0,0 +1,56 @@
+### Please describe the problem.
+`git-annex-copy` fails after a short time with the message "thread blocked indefinitely in an STM transaction".  Re-running it brings the same problem.
+
+### What steps will reproduce the problem?
+
+See below
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+(master_env_v156_py36) 14:22  [viral-ngs-benchmarks] $ git annex version
+git-annex version: 7.20190819-ge4cecf8
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sql\
+ite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_2\
+24 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE\
+2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224\
+ BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 5
+(master_env_v156_py36) 14:24  [viral-ngs-benchmarks] $ uname -a
+Linux ip-172-31-81-103.ec2.internal 4.14.138-114.102.amzn2.x86_64 #1 SMP Thu Aug 15 15:29:58 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
+(master_env_v156_py36) 14:24  [viral-ngs-benchmarks] $
+
+"""]]
+
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+(master_env_v156_py36) 14:18  [viral-ngs-benchmarks] $ git annex --debug --verbose copy -J1 --not --in dnanexus --and --not --in mygs \
+--to viral-ngs-benchmarks-s3 --json --json-error-messages > tmp/copy.out.txt 2> tmp/copy.err.txt
+  C-c C-c
+(master_env_v156_py36) 14:22  [viral-ngs-benchmarks] $ git annex copy -J1 --not --in dnanexus --and --not --in mygs --to viral-ngs-ben\
+chmarks-s3 --json --json-error-messages > tmp/copy.out.txt 2> tmp/copy.err.txt
+(master_env_v156_py36) 14:22  [viral-ngs-benchmarks] $ echo $?
+1
+(master_env_v156_py36) 14:22  [viral-ngs-benchmarks] $ cat tmp/copy.err.txt
+git-annex: thread blocked indefinitely in an STM transaction
+git-annex: thread blocked indefinitely in an STM transaction
+(
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/git-annex-copy_fails_with___34__thread_blocked_indefinitely_in_an_STM_transaction__34__/comment_1_c9d7057b9c7b7811a29dcc59b98f97d0._comment b/doc/bugs/git-annex-copy_fails_with___34__thread_blocked_indefinitely_in_an_STM_transaction__34__/comment_1_c9d7057b9c7b7811a29dcc59b98f97d0._comment
new file mode 100644
index 0000000000..ebb66fef09
--- /dev/null
+++ b/doc/bugs/git-annex-copy_fails_with___34__thread_blocked_indefinitely_in_an_STM_transaction__34__/comment_1_c9d7057b9c7b7811a29dcc59b98f97d0._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-20T17:13:13Z"
+ content="""
+You seem to be the only one reporting this problem, and you have mentioned
+seeing it multiple times. There must be something unusual in how you are
+using git-annex.
+
+A recent similar problem that was fixed in 
+[[!commit 667d38a8f11c1ee8f256cdbd80e225c2bae06595]]
+involved having multiple files with the same key. It would be good
+to verify if the bug still occurs with the fixed git-annex, assuming you
+have a way to reproduce this bug.
+
+Without a way to reproduce it, all I can suggest is building git-annex with
+the DebugLocks build flag (`stack build --flag DebugLocks`). That will make
+it display a backtrace when the error occurs, assuming it's happening in
+one of the places where debugging is enabled. If not, we'll have to
+instrument more places in the code that use STM.
+
+Also, redirecting all the output like you have done just risks hiding
+a useful clue, so you should show the full regular console output
+ideally w/o json enabled.
+
+I have merged your other bug report about of `git annex fsck` with this one.
+"""]]
diff --git a/doc/bugs/git-annex-enableremote_confusing_behavior_when_there_is_a_git_remote_with_same_name_as_special_remote.mdwn b/doc/bugs/git-annex-enableremote_confusing_behavior_when_there_is_a_git_remote_with_same_name_as_special_remote.mdwn
new file mode 100644
index 0000000000..84ac671cee
--- /dev/null
+++ b/doc/bugs/git-annex-enableremote_confusing_behavior_when_there_is_a_git_remote_with_same_name_as_special_remote.mdwn
@@ -0,0 +1,13 @@
+If there's a git remote named "foo", and a special remote with the same
+name, `git annex enableremote foo` just prints "ok" and silently does
+nothing.
+
+Perhaps worse, passing enableremote the uuid of the special remote causes
+it to *modify* the same named git remote's config, adding/replacing
+annex-uuid and adding whatever other git configs the special remote uses.
+--[[Joey]]
+
+(initremote does check if there's already a remote with the same name, and
+refuses to overwrite it).
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/git-annex-enableremote_confusing_behavior_when_there_is_a_git_remote_with_same_name_as_special_remote/comment_1_7f28aecc6ecefd7d47979f73330759d2._comment b/doc/bugs/git-annex-enableremote_confusing_behavior_when_there_is_a_git_remote_with_same_name_as_special_remote/comment_1_7f28aecc6ecefd7d47979f73330759d2._comment
new file mode 100644
index 0000000000..d70e00024e
--- /dev/null
+++ b/doc/bugs/git-annex-enableremote_confusing_behavior_when_there_is_a_git_remote_with_same_name_as_special_remote/comment_1_7f28aecc6ecefd7d47979f73330759d2._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-09-22T17:05:28Z"
+ content="""
+The behavior in the first case has changed, it now displays:
+
+	enableremote (normal) foo ok
+
+And the normal git remote is left as-is. Which seems more or less
+reasonable.
+
+The behavior in the second case (passing the uuid) is still as described.
+
+I've fixed that to instead fail with:
+
+	git-annex: Not overwriting currently configured git remote named "foo"
+"""]]
diff --git a/doc/bugs/git-annex-import_imports_outside_of_directory.mdwn b/doc/bugs/git-annex-import_imports_outside_of_directory.mdwn
new file mode 100644
index 0000000000..0adc7e253d
--- /dev/null
+++ b/doc/bugs/git-annex-import_imports_outside_of_directory.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+When using `git-annex-import` to import from a directory remote, if the directory tree has directory symlinks pointing to directories outside the directory tree of the directory remote, the targets of these symlinks get imported.  This can lead to importing much more than was intended; such symlinks should probably get imported as symlinks by default, with a command-line option to import their targets.   There might even be a security issue with unexpectedly importing and sharing content outside the explicitly specified directory tree.
+
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+$ git annex version
+git-annex version: 10.20220322-g7b64dea
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+$ uname -a
+Linux ctchpcpx163.merck.com 3.10.0-1160.6.1.el7.x86_64 #1 SMP Tue Nov 17 13:59:11 UTC 2020 x86_64 GNU/Linux
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+That I use it enough to run into corner-case issues shows its continued usefulness :)
+
+[[!meta title="git-annex import follows symlinks"]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/git-annex-import_imports_outside_of_directory/comment_10_30dab036949bd35e026a31974c4e5164._comment b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_10_30dab036949bd35e026a31974c4e5164._comment
new file mode 100644
index 0000000000..02b24b3103
--- /dev/null
+++ b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_10_30dab036949bd35e026a31974c4e5164._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="imports and symlinks"
+ date="2022-08-22T20:40:41Z"
+ content="""
+> the old git-annex import already skipped symlinks to files
+
+Then the old import was problematic as well :)
+
+Sorry for harping on this, but since this affects my use cases (and I suspect others' as well), what's the rationale for not doing what `tar` does?
+I assumed that an import is similar to doing a `tar` or a `cp -pr`, except that the files get annexed and a connection to the files' origin is recorded.
+
+For things like song collections the symlinks might not matter, but for datasets they do.  E.g. symlinks are used to ensure tools that expect certain filenames at certain paths can find them.  The tools are often written by other people, so as a user you might not know all details of these expectations.  Files from related analyses are symlinked to keep the relation explicit.
+Absolute symlinks are used to point to large shared resources (e.g. genome files) on a filesystem that all users of the repo share.   I can give more detailed illustrations if it would help.  But I'm not sure I understand the downside of importing symlinks the way tar does.
+"""]]
diff --git a/doc/bugs/git-annex-import_imports_outside_of_directory/comment_1_376302b0bac94ee81c0dfdcb647f3b3b._comment b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_1_376302b0bac94ee81c0dfdcb647f3b3b._comment
new file mode 100644
index 0000000000..56f6972056
--- /dev/null
+++ b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_1_376302b0bac94ee81c0dfdcb647f3b3b._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-03T16:15:38Z"
+ content="""
+`git-annex import $dir` also follows symlinks inside $dir.
+So importing has been behaving this way since long before the directory
+special remote supported importtree.
+
+This is not a security hole, because if an attacker wants to make you 
+import `/foo` when importing `/bar`, and they have write access to bar,
+they are not limited to making a `/bar/foo -> /foo` symlink. They can just
+`cp -a /foo /bar` instead.
+
+I don't really think it would make much sense for any import to import
+symlinks as symlinks. If the symlink points outside the imported directory,
+that would result in a symlink that points outside the git repository,
+which is not something one often wants to check into a git repository.
+
+I don't know if I would really consider this a bug either. It at least
+seems plausible that there might be users who import from `~/disk`
+which is a symlink to `/media/somethinglong`, and rely on it following
+the symlink. I often make symlink aliases for mount points like that,
+though I have not imported from them.
+"""]]
diff --git a/doc/bugs/git-annex-import_imports_outside_of_directory/comment_2_e74c71a5574a8e99503ac83a27d48533._comment b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_2_e74c71a5574a8e99503ac83a27d48533._comment
new file mode 100644
index 0000000000..b27d15a896
--- /dev/null
+++ b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_2_e74c71a5574a8e99503ac83a27d48533._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="should import follow symlinks?"
+ date="2022-05-03T19:36:10Z"
+ content="""
+I meant \"security hole\" more in the sense of the user themselves inadvertently importing (and then sharing) more than they meant to.
+E.g. I was importing a large subtree created by others, and had no clue it included symlinks outside the subtree; I only noticed this by accident, when the import started taking too long.
+
+>git-annex import $dir also follows symlinks inside $dir.
+
+In conjunction with the `mv` semantics, this seems risky... had I been using the original directory import, I'd have inadvertently deleted a large dataset (to which there was a symlink in the imported tree) from a place others expect to find it.  The unix `mv` command doesn't even have a flag to follow symlinks (nevermind defaulting to that).
+
+>It at least seems plausible that there might be users who import from ~/disk which is a symlink to /media/somethinglong, and rely on it following the symlink.
+
+It's certainly plausible; question is, should it be the default?   It's not the default in `cp` (you have to use `-L`) or in `tar` (have to use `-h`).  I think most people assume that importing from a directory remote is akin to doing a `cp -r` or `tar cf` from it.
+"""]]
diff --git a/doc/bugs/git-annex-import_imports_outside_of_directory/comment_3_778e176a44aa57e9223aab1a45c931f3._comment b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_3_778e176a44aa57e9223aab1a45c931f3._comment
new file mode 100644
index 0000000000..59910a05ec
--- /dev/null
+++ b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_3_778e176a44aa57e9223aab1a45c931f3._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="interaction of out-of-tree symlinks with exporttree"
+ date="2022-05-09T19:21:15Z"
+ content="""
+One other scenario where the result might not be what users expect is the following: if a [[directory special remote|/special_remotes/directory]] is configured with both [[`importtree=yes`|git-annex-import]] and [[`exporttree=yes`|git-annex-export]], and the directory contains symlinks pointing outside the tree, then an import followed by an export will replace the symlink in the original directory with a copy of the content.
+
+>a symlink that points outside the git repository, which is not something one often wants to check into a git repository
+
+Such a symlink is already not something one often has :)  But if one does, then the repo is likely for one's own usage, or for the usage by people with access to the shared filesystem where the link works, so adding the link to git as-is makes sense.  Logically, it's likely that the out-of-tree link target represents some separate tree of files that you don't think of as part of the tree (or you'd have put them under the tree); if you did want to import them, you'd make a separate repo for them and import them as a submodule.
+
+Also, what happens if the target tree of the out-of-tree link has a symlink back to the original tree -- could this cause infinite recursion?
+
+The [[`git-annex-import` man page|git-annex-import]] says the command imports \"a tree of files\".  It seems simplest if this description was always strictly true, regardless of what's in the tree.  But if you decide to keep the current default, maybe clarify the web page?
+
+Thanks again for all your work.
+
+"""]]
diff --git a/doc/bugs/git-annex-import_imports_outside_of_directory/comment_4_3406ba56525cb59b8b1b366e2b3dc291._comment b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_4_3406ba56525cb59b8b1b366e2b3dc291._comment
new file mode 100644
index 0000000000..0b95faefc5
--- /dev/null
+++ b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_4_3406ba56525cb59b8b1b366e2b3dc291._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="skcin"
+ avatar="http://cdn.libravatar.org/avatar/11a5a31cf0943808f44edb7154d32bd1"
+ subject="Option to not follow symlinks?"
+ date="2022-08-18T15:32:43Z"
+ content="""
+Hey,
+I just got bitten by this. Is there an option to not follow symlinks?
+If not(and I couldn't find an option), it would be nice to add that. I have no strong opinion on wether it should be a default or not.
+
+Maybe it is stupid and there is a much better way, but here is what I did.
+I decided to move all my data into git annex. I had a total mess of old hard drives with data, backups or both. Some 10+ years old.
+So I started to use the directory import with deduplication to import each Hdd into a separate folder of my annex. That worked very well and left me with a much smaller amount of data to organize and empty Hdds ready to wipe+dispose.
+
+Where things went wrong was when I imported an old external Hdd with a backup of a home directory from 2011 on it. Apparently I had wine installed at that time which had created symlinks in .wine to the following directories.
+
+* `/`
+* `/home/USERNAME`
+
+Conveniently I use the same username now as I used back then. ;) 
+I noticed that something was wrong because the import took very long and the KDE desktop started to misbehave. Probably git annex deleted some files KDE needed. I don't know why but at first glance there is not much data missing from my home directory. But now there are a lot of files in my annex that I don't want.
+
+I think it is not too painful to sort this out but it would have been easy to avoid. My use case for this will probably go away once all the old Hdds are gone. But scenarios like this might not be that rare for new users coming from a world without numcopies and location tracking.
+
+I have been eyeing git-annex for a couple of years now and finally got around to actually use it. I am very impressed and a huge fan. Thanks for all the work.
+"""]]
diff --git a/doc/bugs/git-annex-import_imports_outside_of_directory/comment_5_5b41c061786fd49c75d49aa2cc70bb9f._comment b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_5_5b41c061786fd49c75d49aa2cc70bb9f._comment
new file mode 100644
index 0000000000..b48f19276a
--- /dev/null
+++ b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_5_5b41c061786fd49c75d49aa2cc70bb9f._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-08-19T17:01:42Z"
+ content="""
+@skcin I'm very sorry that happened to you. I suppose it's not data loss,
+but it sounds like a mess. You should be able to examine `git log` to find
+what got imported, and run `git-annex unannex` on it, and then move it back
+to the right place.
+
+Seems like I underestimated the chance this would be a foot bomb.
+I now think that git-annex import and the directory special remote should
+skip over symlinks. Probably with an informative message to avoid silently
+doing nothing in cases where users had been using them intentionally to
+follow symlinks.
+
+Such a check will be race prone, but that is only likely to matter if an
+attacker is racing it to replace a file with a symlink, and as I discussed
+in previous comments, such an attacker seems like they would be able to
+accomplish the same thing with the write permission they must have.
+"""]]
diff --git a/doc/bugs/git-annex-import_imports_outside_of_directory/comment_6_6d559ba943ef2a8fed285c463eb2a641._comment b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_6_6d559ba943ef2a8fed285c463eb2a641._comment
new file mode 100644
index 0000000000..e6108a7083
--- /dev/null
+++ b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_6_6d559ba943ef2a8fed285c463eb2a641._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-08-19T17:20:24Z"
+ content="""
+Ok, I've changed `git-annex import` to skip symbolic links inside the
+directory being imported. The directory being imported can still itself be
+a symlink and that will be followed.
+"""]]
diff --git a/doc/bugs/git-annex-import_imports_outside_of_directory/comment_6_d6aaa0519faa596fa42d22fba405cbff._comment b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_6_d6aaa0519faa596fa42d22fba405cbff._comment
new file mode 100644
index 0000000000..a35b735fdb
--- /dev/null
+++ b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_6_d6aaa0519faa596fa42d22fba405cbff._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="git-annex-import and symlinks"
+ date="2022-08-19T17:18:37Z"
+ content="""
+>git-annex import and the directory special remote should skip over symlinks
+
+It should still import them as symlinks into git, just not change them to annexed files.  If these are relative symlinks pointing within the tree being imported, they'll still work in the repo.  If these are absolute symlinks to common files mounted on a filesystem shared by all users of the repo, you still want them in the imported repo as absolute symlinks.  Absolute symlinks that happen to point within the tree being imported should be imported as annexed files.
+
+"""]]
diff --git a/doc/bugs/git-annex-import_imports_outside_of_directory/comment_7_4f9816f7c9a61289bef98820b1ec25cc._comment b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_7_4f9816f7c9a61289bef98820b1ec25cc._comment
new file mode 100644
index 0000000000..0bc559ab0c
--- /dev/null
+++ b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_7_4f9816f7c9a61289bef98820b1ec25cc._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="imports and symlinks"
+ date="2022-08-19T20:19:50Z"
+ content="""
+Re: new manpage description that says
+
+>symbolic links in the directory being imported are skipped to avoid
+>accidentially importing things outside the directory that import was ran
+>on
+
+In my use cases, skipping symlinks (instead of importing them as git symlinks) would make the imported tree unusable by tools that expect specific filenames in specific subdirs of the tree,
+when these filenames were symlinks in the original tree.
+Could the symlinks be imported as standard git symlinks instead of skipping them?  Worst case, a checkout of the repo will have symlinks to non-existing targets -- this can be fixed by mounting volumes with the right paths.  OTOH, having filenames missing from the imported tree because they happened to be symlinks in the original tree can cause all sorts of errors.   Import is much simpler to think about if it's guaranteed to replicate the full original tree structure, like `tar` does.
+"""]]
diff --git a/doc/bugs/git-annex-import_imports_outside_of_directory/comment_9_372c44296c1a03778e201a47ec45bee6._comment b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_9_372c44296c1a03778e201a47ec45bee6._comment
new file mode 100644
index 0000000000..1394031592
--- /dev/null
+++ b/doc/bugs/git-annex-import_imports_outside_of_directory/comment_9_372c44296c1a03778e201a47ec45bee6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-08-22T15:58:12Z"
+ content="""
+@Ilya the old git-annex import already skipped symlinks to files.
+(Along with not importing sockets, device files, etc.)
+It only followed symlinks to directories.
+"""]]
diff --git a/doc/bugs/git-annex-import_stalls_and_uses_all_ram_available.mdwn b/doc/bugs/git-annex-import_stalls_and_uses_all_ram_available.mdwn
new file mode 100644
index 0000000000..3efe9ba570
--- /dev/null
+++ b/doc/bugs/git-annex-import_stalls_and_uses_all_ram_available.mdwn
@@ -0,0 +1,66 @@
+### Please describe the problem.
+
+I'm not sure if what I am experiencing is a bug, or just something I am doing incorrectly.
+
+I am running into an issue with git-annex-import where it seems to stall, and use all available ram it can until the system terminates the process.
+
+### What steps will reproduce the problem?
+
+Here are my prep steps:
+
+```sh
+git init
+
+git annex initremote s3-data type=S3 encryption=none port=443 protocol=https public=no \
+importtree=yes versioning=yes host=$S3HOST bucket=$BUCKET fileprefix=primary_folder/
+
+git annex wanted s3-data "exclude=subfolder-*/* and include=specialfilename1.*"
+
+git annex import main --from s3-data --skip-duplicates --backend MD5E --jobs=4
+```
+
+### What version of git-annex are you using? On what operating system?
+
+Originally, 10.20230321 on Debian Bookworm
+
+I also tried 10.20231129 on Debian Bookworm with the same results
+
+### Please provide any additional information below.
+
+There are around 22000 files under the prefix I am trying to import from , and it amounts to around 115 GB.  However, most of that data is part of many seperate subdatasets underneath this one.  These have all worked fine and without any issue.
+
+There are only 2 files I am actually trying to import, though there are several versions(about 70 each for a total of 140) of them at this location.  In this example, that is `specialfilename1.json` & `specialfilename1.csv`
+
+When I use debug mode on the import command a lot of information is printed, but it mostly seems to amount to filenames that I would think would be excluded based on my `git-annex-wanted` command.  That output looks like the following until it stops, and then uses up what's available for RAM before inevitably terminating the process.
+
+```
+[2023-12-18 23:47:54.924814306] (Utility.Process) process [11787] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2023-12-18 23:47:54.929719575] (Utility.Process) process [11787] done ExitSuccess
+[2023-12-18 23:47:54.930053775] (Utility.Process) process [11789] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2023-12-18 23:47:54.935010757] (Utility.Process) process [11789] done ExitSuccess
+[2023-12-18 23:47:54.935508638] (Utility.Process) process [11790] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..a6d7c6ae03747e23c2bedbecc8d1a5afeabe5220","--pretty=%H","-n1"]
+[2023-12-18 23:47:54.940887356] (Utility.Process) process [11790] done ExitSuccess
+[2023-12-18 23:47:54.941241371] (Utility.Process) process [11791] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..27a0dedea083605106c614a159d48fd3daa92284","--pretty=%H","-n1"]
+[2023-12-18 23:47:54.947198539] (Utility.Process) process [11791] done ExitSuccess
+[2023-12-18 23:47:54.949236306] (Utility.Process) process [11792] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2023-12-18 23:47:54.971233148] (Utility.Process) process [11793] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/remotes/s3-data/main"]
+[2023-12-18 23:47:54.97613841] (Utility.Process) process [11793] done ExitFailure 1
+...
+
+String to sign: "GET\n\n\nMon, 18 Dec 2023 23:47:57 GMT\n/bucketname/?versions"
+[2023-12-18 23:47:57.978207613] (Remote.S3) Host: "bucketname.s3-us-east-1.amazonaws.com"
+[2023-12-18 23:47:57.978237701] (Remote.S3) Path: "/"
+[2023-12-18 23:47:57.978260264] (Remote.S3) Query string: "versions&key-marker=primary_folder%subfolder-100101%2sessions.json&prefix=primary_folder%2F&version-id-marker=Xg1KUaCh6tpvJ2E1juz4qobn.w3.x9k"
+[2023-12-18 23:47:57.978337803] (Remote.S3) Header: [("Date","Mon, 18 Dec 2023 23:47:57 GMT"),("Authorization","AWS [Redacted]")]
+[2023-12-18 23:47:58.003376688] (Remote.S3) Response status: Status {statusCode = 200, statusMessage = "OK"}
+[2023-12-18 23:47:58.00343782] (Remote.S3)  Response header 'Transfer-Encoding': 'chunked'
+[2023-12-18 23:47:58.003472907] (Remote.S3) Response header 'x-amz-request-id': 'tx00000925b31abf8c9c162-006580da2d-19170577-default'
+[2023-12-18 23:47:58.003527331] (Remote.S3) Response header 'Content-Type': 'application/xml'
+[2023-12-18 23:47:58.003557859] (Remote.S3) Response header 'Date': 'Mon, 18 Dec 2023 23:47:58 GMT
+```
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+In the past, on smaller versions of data structured the same way, this setup has worked, and I don't run into this issue.
+
+I'm not exactly sure how to troubleshoot further and I am feeling stuck.  Is there something else I can be doing to see more info about what's happening behind the scenes?
diff --git a/doc/bugs/git-annex-import_stalls_and_uses_all_ram_available/comment_1_ca22165fc77a57979ad6e19c60693b21._comment b/doc/bugs/git-annex-import_stalls_and_uses_all_ram_available/comment_1_ca22165fc77a57979ad6e19c60693b21._comment
new file mode 100644
index 0000000000..fff51cddf7
--- /dev/null
+++ b/doc/bugs/git-annex-import_stalls_and_uses_all_ram_available/comment_1_ca22165fc77a57979ad6e19c60693b21._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-12-20T16:56:04Z"
+ content="""
+How much ram did it use up?
+
+The fact that the S3 bucket is versioned and that there are many versions
+seems very relevant to me. Importing lists all the files in the bucket, and
+traverses all versions and lists all the files in each version. That builds
+up a data structure in memory, which could be very large in this case. If
+you have around 150 versions total, the number of files in the data
+structure would be effectively three million.
+
+If the same thing works for you with `versioning=no` set, that will confirm
+the source of the problem.
+
+It only gets filtered down to the wanted files in a subsequent pass.
+Filtering on the fly would certainly help with your case, but not with a
+case where someone wants to import all 22000 files.
+
+Rather, I'd be inclined to try to fix this by making importableHistory into
+a callback so it can request one historical tree at a time. Similar to how
+ImportableContentsChunked works.
+"""]]
diff --git a/doc/bugs/git-annex-import_stalls_and_uses_all_ram_available/comment_2_2025b1662067bbfaab14576d9e20a6ab._comment b/doc/bugs/git-annex-import_stalls_and_uses_all_ram_available/comment_2_2025b1662067bbfaab14576d9e20a6ab._comment
new file mode 100644
index 0000000000..b3c0b13cc6
--- /dev/null
+++ b/doc/bugs/git-annex-import_stalls_and_uses_all_ram_available/comment_2_2025b1662067bbfaab14576d9e20a6ab._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-12-20T17:34:11Z"
+ content="""
+I looked into filtering to preferred content on the fly. I was able to
+adapt listImportableContents to allow that to be done optionally. But of
+the remotes that support tree import, only directory and S3 would be able
+to use it. And I've not yet managed to implement it for S3. My incomplete 
+work on this is in the `importtreefilter` branch.
+"""]]
diff --git a/doc/bugs/git-annex-import_stalls_and_uses_all_ram_available/comment_3_5943379450c860b2885121e7f0abd42a._comment b/doc/bugs/git-annex-import_stalls_and_uses_all_ram_available/comment_3_5943379450c860b2885121e7f0abd42a._comment
new file mode 100644
index 0000000000..a7806f550f
--- /dev/null
+++ b/doc/bugs/git-annex-import_stalls_and_uses_all_ram_available/comment_3_5943379450c860b2885121e7f0abd42a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="lemondata"
+ avatar="http://cdn.libravatar.org/avatar/481bf8163b175e5d0bdbef7d8c7fb3f4"
+ subject="comment 3"
+ date="2024-01-02T15:44:21Z"
+ content="""
+The first system I tried capped out at 8GB of ram, and it used around 7 before ending the process with `error: git-annex died of signal 9`.  Since I initially thought it might just be a ram problem I attempted the same on a system with 32GB of ram, but arrived at the same results after the system used around 31GB of ram.  I was not able to try any higher due to my own physical hardware restrictions.
+
+Just to help confirm the suspicion of the problem I tried the same thing with `versioning=no` set, and the import worked great.
+
+Since I do not want to import all 22000 files and I just need two items at this prefix(and their historical versions), I think some way to filter on the fly would make a huge difference.  Alternatively, like you mentioned, importing one historical tree at a time sounds like it would ease the ram requirements here too.
+
+Is there anything I can do to help further with testing?  Or is there any more information I can give about the issue that would be helpful to you?
+"""]]
diff --git a/doc/bugs/git-annex-install_for_Android_crashes_on___34__arm7el__34__.mdwn b/doc/bugs/git-annex-install_for_Android_crashes_on___34__arm7el__34__.mdwn
new file mode 100644
index 0000000000..aa29752bd9
--- /dev/null
+++ b/doc/bugs/git-annex-install_for_Android_crashes_on___34__arm7el__34__.mdwn
@@ -0,0 +1,90 @@
+### Please describe the problem.
+
+I am trying to install git-annex on the Fairphone with Android/Termux. 
+
+
+### What steps will reproduce the problem?
+
+Running 
+
+$ source git-annex-install
+
+
+### What version of git-annex are you using? On what operating system?
+
+Fairphone Open Android 6.0, Marshmallow 
+
+$ uname -a
+Linux localhost 3.4.0-gcde0e65 #1 SMP PREEMPT Wed Apr 11 16:49:55 BST 2018 armv7l Android
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+$ source git-annex-install
+unknown architecture armv7l, cannot install
+Connection to [host] closed.
+
+
+# End of transcript or log.
+"""]]
+
+after changing the line
+
+    arm)
+
+to
+
+    arm|armv7l)
+
+I get:
+
+[[!format sh """
+
+$ sh git-annex-install > out 2> out.err
+
+$ cat out
+Installing dependencies with termux pkg manager...
+Hit:1 https://termux.net stable InRelease
+Reading package lists...
+Building dependency tree...
+Reading state information...
+All packages are up to date.
+Reading package lists...
+Building dependency tree...
+Reading state information...
+coreutils is already the newest version (8.30-1).
+git is already the newest version (2.19.1).
+proot is already the newest version (5.1.107-18).
+tar is already the newest version (1.30-1).
+wget is already the newest version (1.19.5-1).
+0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
+Downloading git-annex...
+
+$ tail -n 15 out.err
+ 59450K .......... .......... .......... .......... .......... 99%  734K 0s
+ 59500K .......... .......... .......... .......... .......... 99%  846K 0s
+ 59550K .......... .......... .......... .......... ...       100%  759K=95s
+
+2018-10-31 16:42:08 (630 KB/s) - written to stdout [61023751/61023751]
+
+Running on Android.. Adding git-annex to PATH for you, and tuning for optimal behavior.
+proot error: execve("/data/data/com.termux/files/home/git-annex.linux/bin/git-annex"): No such file or directory
+proot info: possible causes:
+  * the program is a script but its interpreter (eg. /bin/sh) was not found;
+  * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
+  * the program is a foreign binary but qemu was not specified;
+  * qemu does not work correctly (if specified);
+  * the loader was not found or doesn't work.
+fatal error: see `proot --help`.
+
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! I use git-annex for many years now under Debian with no problems. Back when I recorded TV with my DVB-T card I used it to pushed files on external hard drives while being able to find them. I just now noticed 
+
+
diff --git a/doc/bugs/git-annex-install_for_Android_crashes_on___34__arm7el__34__/comment_1_af1de40a3c83f8632f98ecde5a5271f5._comment b/doc/bugs/git-annex-install_for_Android_crashes_on___34__arm7el__34__/comment_1_af1de40a3c83f8632f98ecde5a5271f5._comment
new file mode 100644
index 0000000000..139966de66
--- /dev/null
+++ b/doc/bugs/git-annex-install_for_Android_crashes_on___34__arm7el__34__/comment_1_af1de40a3c83f8632f98ecde5a5271f5._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-31T17:46:49Z"
+ content="""
+The arm build does seem the closest match for this architecture, that's
+what I would have tried too.
+
+If you can find a way to get a debian chroot working in termux, that would
+point the way to getting git-annex working.
+<https://wiki.termux.com/wiki/PRoot>
+
+Some Raspberry Pis seem to use arm7el, so maybe Raspbian if Debian doesn't
+work?
+"""]]
diff --git a/doc/bugs/git-annex-move_not_using_parallelism__63__.mdwn b/doc/bugs/git-annex-move_not_using_parallelism__63__.mdwn
new file mode 100644
index 0000000000..ad90d1468d
--- /dev/null
+++ b/doc/bugs/git-annex-move_not_using_parallelism__63__.mdwn
@@ -0,0 +1,15 @@
+### Please describe the problem.
+git-annex-move does not seem to be using parallelism.  i'm running
+(master_env_py27_v28) [02:30 PM ~]$ ps -w -w -w -F 12231
+UID        PID  PPID  C    SZ   RSS PSR STIME TTY      STAT   TIME CMD
+ilya     12231 12230 99 271873062 1018700 26 14:15 pts/2 Sl+ 506:13 /data/vngs/viral-ngs-etc/mc3/envs/master_env_py27_v28/bin/git-annex move -J48 --all --to ilya-s3
+
+and there is only one thread with git-annex.
+ On what operating system?
+
+git-annex version: 6.20180926-gc906aaf build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser MagicMime Feed\ s Testsuite dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-s\ qlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5 key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_2\ 24 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE\ 2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256\ BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external operating system: linux x86_64 supported repository versions: 3 5 6 upgrade supported from repository versions: 0 1 2 3 4 5 local repository version: 5
+
+(master_env_py27_v28) [01:05 PM /data/ilya-work]$ uname -a Linux ip-172-31-87-156 4.14.72-68.55.amzn1.x86_64 #1 SMP Fri Sep 28 21:14:54 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
+
+> While this might be a bug, there is not enough information to know, and
+> so after 3 years, I'm going to close it. [[done]] --[[Joey]]
diff --git a/doc/bugs/git-annex-move_not_using_parallelism__63__/comment_1_1080a771213dc524cbd072591030c98c._comment b/doc/bugs/git-annex-move_not_using_parallelism__63__/comment_1_1080a771213dc524cbd072591030c98c._comment
new file mode 100644
index 0000000000..6940ad8bb5
--- /dev/null
+++ b/doc/bugs/git-annex-move_not_using_parallelism__63__/comment_1_1080a771213dc524cbd072591030c98c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-29T19:05:21Z"
+ content="""
+Do you see git-annex displaying multiple concurrent actions at the same
+time?
+
+Is annex.pidlock set?
+
+You mention threads, which makes me think you may be examining the
+processes's OS threads. But haskell uses green threads. Perhaps I should
+not try to guess what you are talking about with the mention of "threads",
+but the bug report is very much not clear about what the problem looks
+like or how to reproduce it, and I am grasping at straws.
+"""]]
diff --git a/doc/bugs/git-annex-move_not_using_parallelism__63__/comment_2_a83e833b329df094e1bc7945db9686b0._comment b/doc/bugs/git-annex-move_not_using_parallelism__63__/comment_2_a83e833b329df094e1bc7945db9686b0._comment
new file mode 100644
index 0000000000..7bceb5124c
--- /dev/null
+++ b/doc/bugs/git-annex-move_not_using_parallelism__63__/comment_2_a83e833b329df094e1bc7945db9686b0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2018-10-29T21:10:29Z"
+ content="""
+\"Do you see git-annex displaying multiple concurrent actions at the same time?\" -- displaying where? I was just looking at 'top', which seemed to be showing only one git-annex process, and showing that the processors are mostly idle.
+"""]]
diff --git a/doc/bugs/git-annex-move_not_using_parallelism__63__/comment_3_bdd1aabe7120c4e6b5999aaf396067bc._comment b/doc/bugs/git-annex-move_not_using_parallelism__63__/comment_3_bdd1aabe7120c4e6b5999aaf396067bc._comment
new file mode 100644
index 0000000000..483b31558c
--- /dev/null
+++ b/doc/bugs/git-annex-move_not_using_parallelism__63__/comment_3_bdd1aabe7120c4e6b5999aaf396067bc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 3"
+ date="2018-11-12T03:17:47Z"
+ content="""
+I would try adding `--debug`, so `git-annex move -J48 --all --to ilya-s3 --debug` that should give you some insight into the number of simultaneous connections. Seems to be moving concurrently for me, I tried on an s3 remote and a googledrive remote, I saw multiple interleaved uploads in the debug logs as well as multiple simultaneous `git … cat-file` in my processes.
+"""]]
diff --git a/doc/bugs/git-annex-repair_claims_success_then_failure.mdwn b/doc/bugs/git-annex-repair_claims_success_then_failure.mdwn
new file mode 100644
index 0000000000..e08d986593
--- /dev/null
+++ b/doc/bugs/git-annex-repair_claims_success_then_failure.mdwn
@@ -0,0 +1,52 @@
+Hello.
+
+What does this log mean?  It seems to tell" "success", then "openDirStream" fails, then "1 failed".  What failed?
+
+Context is in [todo/git annex repair: performance can be abysmal, huge improvements possible](https://git-annex.branchable.com/ikiwiki.cgi?do=goto&page=todo%2Fgit_annex_repair__58___performance_can_be_abysmal__44___huge_improvements_possible)
+
+    fatal: bad object refs/heads/git-annex
+    fatal: bad object refs/heads/git-annex
+    fatal: bad object refs/heads/git-annex
+    error: Could not read somehashA
+    fatal: Failed to traverse parents of commit somehashB
+    error: Could not read somehashA
+    fatal: Failed to traverse parents of commit somehashB
+    error: Could not read somehashA
+    fatal: Failed to traverse parents of commit somehashB
+    error: Could not read somehashA
+    fatal: Failed to traverse parents of commit somehashB
+    Deleted these local branches, which could not be recovered due to missing objects:
+    	refs/heads/master
+    	refs/heads/git-annex
+    You currently have refs/heads/master checked out. You may have staged changes in the index that can be committed to recover the lost state of this branch!
+    Successfully recovered repository!
+    Please carefully check that the changes mentioned above are ok..
+
+    git-annex: .git/annex/journal/: openDirStream: does not exist (No such file or directory)
+    failed
+    git-annex: repair: 1 failed
+
+The fact is: this repo is a plain git clone of a git annex repository.
+
+There is no `.git/annex` directory there before `git-annex-repair` is run.
+
+After it ran, there is a `.git/annex` directory with that content:
+
+    total 24
+    drwxrwxr-x 3 4096 Jul 22 15:41 .
+    drwxrwxr-x 9 4096 Jul 23 07:24 ..
+    -rw-rw-r-- 1   65 Jul 20 11:59 index
+    -rw-rw-r-- 1   41 Jul 20 11:59 index.lck
+    -rw-rw-r-- 1    0 Jul 22 15:41 journal.lck
+    -rw-rw-r-- 1  211 Jul 20 11:59 mergedrefs
+    drwxrwxr-x 2 4096 Jul 22 15:41 misctmp
+
+Perhaps git-annex-repair gets confused when recovering a repository that is a plain git clone of a git annex repository?
+
+I did that because annexed objects are 1.7TB big here, so I wanted a local copy of pure git part only to perform repair of the repo, and propagate things somehow the objects at a later stage.
+
+I'll keep the repo lying around for a few days, maybe weeks, if some experiment or further feedback is needed.
+
+Thank you for your attention.
+
+> [[fixed|done]].. sorry for the delay and thanks for reporting --[[Joey]]
diff --git a/doc/bugs/git-annex-repair_claims_success_then_failure/comment_1_de8dfda0bc321e573ab9d17aec1ecb84._comment b/doc/bugs/git-annex-repair_claims_success_then_failure/comment_1_de8dfda0bc321e573ab9d17aec1ecb84._comment
new file mode 100644
index 0000000000..1f3c26a3b2
--- /dev/null
+++ b/doc/bugs/git-annex-repair_claims_success_then_failure/comment_1_de8dfda0bc321e573ab9d17aec1ecb84._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-06-21T18:53:31Z"
+ content="""
+I was able to reproduce this bug!
+
+	git-annex init
+	rm -rf .git/annex
+	git-annex repair
+
+	git-annex: .git/annex/journal/: openDirStream: does not exist (No such file or directory)
+
+That's with Annex.Repair modified to always run commitindex. Having a
+repository with a git-annex branch that is corrupt, would have the same effect
+as that modification.
+
+Fixed this.
+"""]]
diff --git a/doc/bugs/git-annex-shell/comment_1_3d2c3827de34509c0a5595eda07dd18f._comment b/doc/bugs/git-annex-shell/comment_1_3d2c3827de34509c0a5595eda07dd18f._comment
new file mode 100644
index 0000000000..6123471eb6
--- /dev/null
+++ b/doc/bugs/git-annex-shell/comment_1_3d2c3827de34509c0a5595eda07dd18f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T17:48:20Z"
+ content="""
+GIT_SSH is set to the full path of the binary, unless
+~/.config/git-annex/program overrides it.
+
+Finding the full path to the binary is not a trivial or error-free
+operation.
+
+Could you please follow up to this bug or close it?
+"""]]
diff --git a/doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to.mdwn b/doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to.mdwn
new file mode 100644
index 0000000000..53124ee040
--- /dev/null
+++ b/doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to.mdwn
@@ -0,0 +1,29 @@
+### Please describe the problem.
+git-annex-shell -c git-annex-shell errors, and git-annex interprets this as meaning that git-annex-shell is normal git-shell.
+
+### What steps will reproduce the problem?
+Running git-annex-shell -c git-annex-shell.
+
+### What version of git-annex are you using? On what operating system?
+NixOS, 6.20180529.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+[leo60228@nixos:~/test]$ git-annex-shell -c git-annex-shell
+fatal: unrecognized command 'git-annex-shell'
+git-annex-shell: git-shell failed
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Yes.
+
+[[moreinfo]]
+
+> Gonna assume this was operator error after 5 years of no information.
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/comment_1_b0a4f459d40bca7a0b24d1bec1e0f4a8._comment b/doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/comment_1_b0a4f459d40bca7a0b24d1bec1e0f4a8._comment
new file mode 100644
index 0000000000..de19505f5e
--- /dev/null
+++ b/doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/comment_1_b0a4f459d40bca7a0b24d1bec1e0f4a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-08-03T18:18:34Z"
+ content="""
+Why are you trying to do this? Is there a normal git-annex use case that
+involves that happening?
+"""]]
diff --git a/doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/comment_3_335fea47cef83b6dfad7ce8c53193f82._comment b/doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/comment_3_335fea47cef83b6dfad7ce8c53193f82._comment
new file mode 100644
index 0000000000..7140359949
--- /dev/null
+++ b/doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/comment_3_335fea47cef83b6dfad7ce8c53193f82._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-08-08T15:04:09Z"
+ content="""
+In what configuration?
+
+This clearly does not affect the general case, or everyone who is happily
+using git-annex would have reported the bug.
+
+Please provide enough information to reproduce your problem.
+"""]]
diff --git a/doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/comment_3_abaeb3d5c0322deeec790d80b2948549._comment b/doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/comment_3_abaeb3d5c0322deeec790d80b2948549._comment
new file mode 100644
index 0000000000..a02a758689
--- /dev/null
+++ b/doc/bugs/git-annex-shell_-c_git-annex-shell_doesn__39__t_work__44___while_git-annex_expects_it_to/comment_3_abaeb3d5c0322deeec790d80b2948549._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://openid-provider.appspot.com/iakornfeld"
+ nickname="iakornfeld"
+ avatar="http://cdn.libravatar.org/avatar/c0369f5727cad81d1ecf6c2e657b42a1b756284aad0229351f9027a2cfcb2037"
+ subject="Yes"
+ date="2018-08-07T14:07:56Z"
+ content="""
+git-annex does this when checking remotes for git-annex support.
+"""]]
diff --git a/doc/bugs/git-annex-shell_fails_to_run_true.mdwn b/doc/bugs/git-annex-shell_fails_to_run_true.mdwn
new file mode 100644
index 0000000000..230a94a340
--- /dev/null
+++ b/doc/bugs/git-annex-shell_fails_to_run_true.mdwn
@@ -0,0 +1,166 @@
+### Please describe the problem.
+
+I have what I speculate is an interoperability problem with two git-annex versions: on one end, it's trying to run `true` over SSH and on the other end `git-annex-shell` is saying that's not a valid command.
+
+I have a rather gnarly git-remote-gcrypt setup (is there one that isn't?) with a gcrypt remote for the git history and annex content. I honestly barely remember how I set this up, and I'm constantly battling to remember how it works (not great, I know), but here are the notes I have so far:
+
+https://anarc.at/services/backup/#encrypted-remotes
+
+Obviously, I have tried to follow the [[tips/fully_encrypted_git_repositories_with_gcrypt/]] tutorial, but I might have drifted off at some point. I often get confused between the builtin [[encryption]] features and the [[special_remotes/gcrypt]] special remote.
+
+### What steps will reproduce the problem?
+
+I think the trick is to setup a remote gcrypt repo with a hardcoded `command="GIT_ANNEX_SHELL_APPENDONLY=true git-annex-shell -c \"$SSH_ORIGINAL_COMMAND\""` entry in `authorized_keys`. If I drop the `command` parameter from the line, the command goes through fine.
+
+### What version of git-annex are you using? On what operating system?
+
+The "client" end is 8.20210223-2 on Debian bullseye, the remote is 7.20190129-3 on Debian buster.
+
+### Please provide any additional information below.
+
+ I suspect that something was introduced after the buster release that runs this extra command on start:
+
+    ssh remote true
+
+Which SSH turns into:
+
+    ssh remote git-annex-shell -c true
+
+Even with a non-restricted SSH key, the above fails with:
+
+    fatal: unrecognized command 'true'
+    git-annex-shell: git-shell failed
+
+... which is, for me, the smoking gun here.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+anarcat@curie:maison(master)$ LANG=C.UTF-8 git annex sync --content -J2  --debug
+[2021-08-19 10:39:04.710287879] process [2036863] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2021-08-19 10:39:04.71270528] process [2036863] done ExitSuccess
+[2021-08-19 10:39:04.713060458] process [2036864] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2021-08-19 10:39:04.715240868] process [2036864] done ExitSuccess
+[2021-08-19 10:39:04.71580494] process [2036865] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..0134b426eaca4932d9bcc381bcb2c62609563651","--pretty=%H","-n1"]
+[2021-08-19 10:39:04.71856682] process [2036865] done ExitSuccess
+[2021-08-19 10:39:04.719607238] process [2036868] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2021-08-19 10:39:04.720334517] process [2036869] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-19 10:39:04.738790271] process [2036872] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit","-a","-m","git-annex in anarcat@curie:/srv/video/maison"]
+On branch master
+nothing to commit, working tree clean
+[2021-08-19 10:39:04.770958097] process [2036872] done ExitFailure 1
+[2021-08-19 10:39:04.771335463] process [2036893] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+commit ok
+[2021-08-19 10:39:04.773190824] process [2036893] done ExitSuccess
+[2021-08-19 10:39:04.773504032] process [2036895] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2021-08-19 10:39:04.775743665] process [2036895] done ExitSuccess
+[2021-08-19 10:39:04.776052102] process [2036896] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/heads/synced/master"]
+[2021-08-19 10:39:04.777934271] process [2036896] done ExitSuccess
+[2021-08-19 10:39:04.778257724] process [2036897] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/heads/synced/master","--pretty=%H","-n1"]
+[2021-08-19 10:39:04.781046264] process [2036897] done ExitSuccess
+[2021-08-19 10:39:04.781665586] process [2036898] read: ssh ["-o","BatchMode=true","-S",".git/annex/ssh/anarc.at","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","anarc.at","true"]
+[2021-08-19 10:39:05.937301502] process [2036898] done ExitSuccess
+[2021-08-19 10:39:05.938577543] process [2036926] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","fetch","origin"]
+[2021-08-19 10:39:06.108005272] process [2036926] done ExitSuccess
+[2021-08-19 10:39:06.108743728] process [2036944] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
+[2021-08-19 10:39:06.113172855] process [2036944] done ExitSuccess
+[2021-08-19 10:39:06.113913765] process [2036945] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/origin/master"]
+[2021-08-19 10:39:06.118235086] process [2036945] done ExitSuccess
+[2021-08-19 10:39:06.118916295] process [2036946] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/remotes/origin/master","--pretty=%H","-n1"]
+[2021-08-19 10:39:06.124140634] process [2036946] done ExitSuccess
+[2021-08-19 10:39:06.124791141] process [2036947] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/origin/synced/master"]
+[2021-08-19 10:39:06.128491407] process [2036947] done ExitSuccess
+[2021-08-19 10:39:06.129062268] process [2036948] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/synced/master..refs/remotes/origin/synced/master","--pretty=%H","-n1"]
+[2021-08-19 10:39:06.134308196] process [2036948] done ExitSuccess
+pull origin ok
+[2021-08-19 10:39:06.135431262] process [2036949] read: ssh ["-o","BatchMode=true","-S",".git/annex/ssh/anarcat@remote-annex","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","anarcat@remote-annex","true"]
+[2021-08-19 10:39:06.5226911] process [2036949] done ExitFailure 1
+[2021-08-19 10:39:06.524455991] process [2036956] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","fetch","offsite-git"]
+git-annex-shell: git-shell failed
+rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
+rsync error: error in rsync protocol data stream (code 12) at io.c(228) [Receiver=3.2.3]
+gcrypt: Repository not found: rsync://anarcat@remote-annex:/home/anarcat/offsite/Videos.git/
+gcrypt: ..but repository ID is set. Aborting.
+[2021-08-19 10:39:07.057455548] process [2036956] done ExitFailure 128
+pull offsite-git ok
+[2021-08-19 10:39:07.058197157] process [2037001] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2021-08-19 10:39:07.063254024] process [2037001] done ExitSuccess
+[2021-08-19 10:39:07.064018134] process [2037002] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2021-08-19 10:39:07.069653083] process [2037002] done ExitSuccess
+[2021-08-19 10:39:07.07062786] process [2037003] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..0134b426eaca4932d9bcc381bcb2c62609563651","--pretty=%H","-n1"]
+[2021-08-19 10:39:07.076284072] process [2037003] done ExitSuccess
+[2021-08-19 10:39:07.077172323] process [2037004] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--"]
+[2021-08-19 10:39:07.078079618] process [2037005] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-19 10:39:07.078694043] process [2037006] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-19 10:39:07.079965189] process [2037007] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-19 10:39:07.103420306] process [2037009] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2021-08-19 10:39:07.107225054] process [2037010] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-19 10:39:07.108049882] process [2037011] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.largefiles","annex.numcopies","annex.mincopies","--"]
+[2021-08-19 10:39:07.110542203] process [2037012] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.largefiles","annex.numcopies","annex.mincopies","--"]
+[2021-08-19 10:39:07.365098056] process [2037013] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2021-08-19 10:39:07.365245774] process [2037011] done ExitSuccess
+[2021-08-19 10:39:07.365363864] process [2037014] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2021-08-19 10:39:07.36572593] process [2037015] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-19 10:39:07.36730392] process [2037012] done ExitSuccess
+[2021-08-19 10:39:07.367432763] process [2037016] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.largefiles","annex.numcopies","annex.mincopies","--"]
+[2021-08-19 10:39:07.367787144] process [2037007] done ExitSuccess
+[2021-08-19 10:39:07.367891318] process [2037017] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-19 10:39:07.368118899] process [2037006] done ExitSuccess
+[2021-08-19 10:39:07.368213522] process [2037005] done ExitSuccess
+[2021-08-19 10:39:07.368287754] process [2037004] done ExitSuccess
+[2021-08-19 10:39:07.369558345] process [2037018] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.largefiles","annex.numcopies","annex.mincopies","--"]
+[2021-08-19 10:39:07.370572764] process [2037019] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2021-08-19 10:39:07.371432055] process [2037020] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-19 10:39:07.374759264] process [2037021] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2021-08-19 10:39:07.375304372] process [2037022] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-19 10:39:07.378100534] process [2037023] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
+[2021-08-19 10:39:07.380269305] process [2037023] done ExitSuccess
+[2021-08-19 10:39:07.380584318] process [2037024] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2021-08-19 10:39:07.38084529] process [2037025] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2021-08-19 10:39:07.383152906] process [2037025] done ExitSuccess
+[2021-08-19 10:39:07.383152909] process [2037024] done ExitSuccess
+[2021-08-19 10:39:07.383556344] process [2037026] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2021-08-19 10:39:07.38382986] process [2037027] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2021-08-19 10:39:07.385869655] process [2037026] done ExitSuccess
+[2021-08-19 10:39:07.385998224] process [2037027] done ExitSuccess
+[2021-08-19 10:39:07.386579545] process [2037028] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/origin/synced/master"]
+[2021-08-19 10:39:07.386748615] process [2037029] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/offsite-git/synced/master"]
+[2021-08-19 10:39:07.388481211] process [2037028] done ExitSuccess
+[2021-08-19 10:39:07.388627634] process [2037029] done ExitSuccess
+[2021-08-19 10:39:07.389087617] process [2037030] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/remotes/origin/synced/master..refs/heads/synced/master","--pretty=%H","-n1"]
+[2021-08-19 10:39:07.389447787] process [2037031] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/remotes/offsite-git/synced/master..refs/heads/synced/master","--pretty=%H","-n1"]
+[2021-08-19 10:39:07.391475061] process [2037030] done ExitSuccess
+[2021-08-19 10:39:07.391885609] process [2037032] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/origin/git-annex"]
+[2021-08-19 10:39:07.392072048] process [2037031] done ExitSuccess
+[2021-08-19 10:39:07.392422194] process [2037033] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/offsite-git/git-annex"]
+[2021-08-19 10:39:07.393853689] process [2037032] done ExitSuccess
+[2021-08-19 10:39:07.394223125] process [2037034] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/remotes/origin/git-annex..git-annex","--pretty=%H","-n1"]
+[2021-08-19 10:39:07.394252126] process [2037033] done ExitSuccess
+[2021-08-19 10:39:07.394616572] process [2037035] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/remotes/offsite-git/git-annex..git-annex","--pretty=%H","-n1"]
+[2021-08-19 10:39:07.396719833] process [2037034] done ExitSuccess
+[2021-08-19 10:39:07.396989352] process [2037035] done ExitSuccess
+[2021-08-19 10:39:07.397288729] process [2037019] done ExitSuccess
+[2021-08-19 10:39:07.397649558] process [2037020] done ExitSuccess
+[2021-08-19 10:39:07.397943289] process [2037021] done ExitSuccess
+[2021-08-19 10:39:07.398193463] process [2037022] done ExitSuccess
+[2021-08-19 10:39:07.398430683] process [2037018] done ExitSuccess
+[2021-08-19 10:39:07.398671489] process [2037016] done ExitSuccess
+[2021-08-19 10:39:07.399335705] process [2037036] read: ssh ["-O","stop","-S","anarcat@remote-annex","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
+[2021-08-19 10:39:07.405590596] process [2037036] done ExitSuccess
+[2021-08-19 10:39:07.406058089] process [2037037] read: ssh ["-O","stop","-S","anarc.at","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
+[2021-08-19 10:39:07.412095481] process [2037037] done ExitSuccess
+
+# End of transcript or log.
+"""]]
+
+Key part above:
+
+    [2021-08-19 10:39:06.135431262] process [2036949] read: ssh ["-o","BatchMode=true","-S",".git/annex/ssh/anarcat@remote-annex","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","anarcat@remote-annex","true"]
+    [2021-08-19 10:39:06.5226911] process [2036949] done ExitFailure 1
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I'm a long time git-annex user (early adopter, even?) and git-annex is generally serving my uses very well, both as a backup and archival system. The encryption features, however, are a bit more obscure than my tolerance level right now. Thankfully, there is the [[special_remotes/borg/]] I'm thinking of using to replace all this complexity in the future... 
+
+-- [[done]], problem was with a configuration in the gcrypt remote sandbox. -- [[anarcat]]
diff --git a/doc/bugs/git-annex-shell_fails_to_run_true/comment_1_7573eb95bdecc3ecc9b31599bd309d3d._comment b/doc/bugs/git-annex-shell_fails_to_run_true/comment_1_7573eb95bdecc3ecc9b31599bd309d3d._comment
new file mode 100644
index 0000000000..431e869990
--- /dev/null
+++ b/doc/bugs/git-annex-shell_fails_to_run_true/comment_1_7573eb95bdecc3ecc9b31599bd309d3d._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-08-24T16:28:40Z"
+ content="""
+git-annex-shell is not supposed to run true. That would be a security hole
+if it did.
+
+However, what's actually being done here is that git-annex is probing
+to see if it can ssh without a password prompt. It needs to run some
+command in the probe, without doing anything, so it uses true.
+This code was written with the knowledge that a restricted shell might not
+allow true to be run. It doesn't care if ssh exits 1 in such a situation.
+The only exit status it cares about is 255, which is what ssh uses if it
+was unable to ssh to the host due to needing a password.
+
+So, your smoking gun is actually a red herring.
+
+Your actual failure may be here:
+
+	["--git-dir=.git","--work-tree=.","--literal-pathspecs","fetch","offsite-git"]
+	git-annex-shell: git-shell failed
+	rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
+	rsync error: error in rsync protocol data stream (code 12) at io.c(228) [Receiver=3.2.3]
+	gcrypt: Repository not found: rsync://anarcat@remote-annex:/home/anarcat/offsite/Videos.git/
+	gcrypt: ..but repository ID is set. Aborting.
+
+That looks like something is set up incorrectly, but I don't really know what.
+It seems to prevent `git fetch` from working though, so currently it does not look
+like a git-annex problem.
+"""]]
diff --git a/doc/bugs/git-annex-shell_fails_to_run_true/comment_2_5be34b5ffaee39013d24daf83a8dd437._comment b/doc/bugs/git-annex-shell_fails_to_run_true/comment_2_5be34b5ffaee39013d24daf83a8dd437._comment
new file mode 100644
index 0000000000..a9d422e054
--- /dev/null
+++ b/doc/bugs/git-annex-shell_fails_to_run_true/comment_2_5be34b5ffaee39013d24daf83a8dd437._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="indeed."
+ date="2022-01-12T15:56:25Z"
+ content="""
+the problem was that i had a `~/git-shell-commands/rsync` overriding the rsync command to try to restrict *that*, since i'm using a gcrypt remote... it was clunky and badly designed and, ultimately, insecure. i replaced it with `rrsync /home/anarcat/offsite/` but even that is not the best either, as the script says it \"assumes someone will not subvert the rsync protocol\" which hardly seems reassuring.
+
+i also had to change my remotes to follow the \"chroot\" of sorts:
+
+    git config remote.offsite-annex.annex-rsyncurl anarcat@remote-annex:Videos.annex/
+    git remote set-url offsite-git gcrypt::rsync://anarcat@remote-annex:Videos.git/
+
+Running `git fetch` by hand convinced me the problem wasn't git-annex related... From there I reread the git-annex-shell and git-shell commands and noticed that bit about the obscure `git-shell-commands` directory, and found that jem. I even had an error in `journalctl -f` that confirm the problem, something i overlooked as well...
+
+so this indeed seems like a problem on my end. sorry for the delay and the noise!
+"""]]
diff --git a/doc/bugs/git-annex-sync_not_quite_idempotent__63__.mdwn b/doc/bugs/git-annex-sync_not_quite_idempotent__63__.mdwn
new file mode 100644
index 0000000000..4aea13c626
--- /dev/null
+++ b/doc/bugs/git-annex-sync_not_quite_idempotent__63__.mdwn
@@ -0,0 +1,90 @@
+### Please describe the problem.
+I had thought that, after running git-annex-sync in a repo, running it again should always do nothing (if no remote has changed).
+But I'm seeing an example where I have to run git-annex-sync twice for subsequent runs to do nothing.
+
+### What steps will reproduce the problem?
+See below.  The repo has one submodule, in the directory viral-ngs/ .
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+(master_env_v150_py36) 16:44  [viral-ngs-benchmarks] $ uname -a
+Linux ip-172-31-80-189.ec2.internal 4.14.133-113.112.amzn2.x86_64 #1 SMP Tue Jul 30 18:29:50 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
+(master_env_v150_py36) 16:46  [viral-ngs-benchmarks] $ git annex version
+git-annex version: 7.20190730-g1030771
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sql\
+ite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_2\
+24 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE\
+2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224\
+ BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 5
+"""]]
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+(master_env_v150_py36) 16:44  [viral-ngs-benchmarks] $ git annex sync
+On branch is-import-rabies200
+Your branch is up to date with 'origin/is-import-rabies200'.
+
+
+It took 5.25 seconds to enumerate untracked files. 'status -uno'
+may speed it up, but you have to be careful not to forget to add
+new files yourself (see 'git help status').
+nothing to commit, working tree clean
+commit ok
+remote: Enumerating objects: 1, done.
+remote: Counting objects: 100% (1/1), done.
+remote: Total 1 (delta 0), reused 1 (delta 0), pack-reused 0
+Unpacking objects: 100% (1/1), done.
+From github.com:broadinstitute/viral-ngs-benchmarks
+   1d808d3a08c..de7758ca784  is-import-rabies200        -> origin/is-import-rabies200
+   1d808d3a08c..de7758ca784  synced/is-import-rabies200 -> origin/synced/is-import-rabies200
+Updating 1d808d3a08c..de7758ca784
+Fast-forward
+ viral-ngs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+Already up to date.
+pull origin ok
+(master_env_v150_py36) 16:44  [viral-ngs-benchmarks] $ git annex sync
+[is-import-rabies200 f3e0898cd33] git-annex in viral-ngs-benchmarks copy on /ilya
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+commit ok
+pull origin ok
+Enumerating objects: 3, done.
+Counting objects: 100% (3/3), done.
+Delta compression using up to 8 threads
+Compressing objects: 100% (2/2), done.
+Writing objects: 100% (2/2), 946 bytes | 946.00 KiB/s, done.
+Total 2 (delta 1), reused 0 (delta 0)
+remote: Resolving deltas: 100% (1/1), completed with 1 local object.
+To github.com:broadinstitute/viral-ngs-benchmarks.git
+   63fe6905f53..1d808d3a08c  is-import-rabies200 -> synced/is-import-rabies200
+push origin ok
+(master_env_v150_py36) 16:42  [viral-ngs-benchmarks] $ git annex sync
+On branch is-import-rabies200
+Your branch is up to date with 'origin/is-import-rabies200'.
+
+
+It took 5.36 seconds to enumerate untracked files. 'status -uno'
+may speed it up, but you have to be careful not to forget to add
+new files yourself (see 'git help status').
+nothing to commit, working tree clean
+commit ok
+pull origin ok
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_1_d90a0f326840137872f551e54c2d2a53._comment b/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_1_d90a0f326840137872f551e54c2d2a53._comment
new file mode 100644
index 0000000000..90271cec69
--- /dev/null
+++ b/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_1_d90a0f326840137872f551e54c2d2a53._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-08-13T16:39:00Z"
+ content="""
+sync should be idempotent as long as the remote it's syncing with is not
+getting other changes made/pushed to it at the same time
+
+There are things in your transcript that are hard to understand:
+
+* The first sync does not have a "push origin" line, or any git output
+* indicating it pushed, but it made a commit and so it would normally
+  then try to push it.
+* The first sync does not have a "pull origin" line
+  at the beginning, but it does say 
+  "Your branch is up to date"
+  so it must have tried to pull from origin at the start,
+  which sync always does do.
+* Several other parts of the output appear to be
+  in a different order than could have occurred.
+  For example, the first thing sync does is "pull origin", but the
+  transcript has that as the last thing output by the first sync.
+* The highest bit of weirdness is that the first sync seems to pull
+  commit 1d808d3a08c..de7758ca784 from github, but the second sync
+  pushes 63fe6905f53..1d808d3a08c to github. Which kind of appears
+  as if the two syncs have been pasted in the opposite order than they were
+  run.
+
+This makes me suspect you didn't paste the output exactly as it appeared,
+and perhaps left part of it out.
+"""]]
diff --git a/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_2_ba60267d8b34ae9e277ae992dcfcde96._comment b/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_2_ba60267d8b34ae9e277ae992dcfcde96._comment
new file mode 100644
index 0000000000..7f8cb74b5b
--- /dev/null
+++ b/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_2_ba60267d8b34ae9e277ae992dcfcde96._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-08-14T18:40:49Z"
+ content="""
+It's possible that I didn't paste the output correctly (it was more than a screenful, so was pasted in two parts).  I'll post again if I see this happen again.
+"""]]
diff --git a/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_3_2381583c924561cbe46186fbd8fbf654._comment b/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_3_2381583c924561cbe46186fbd8fbf654._comment
new file mode 100644
index 0000000000..35e0feef63
--- /dev/null
+++ b/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_3_2381583c924561cbe46186fbd8fbf654._comment
@@ -0,0 +1,120 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="another instance of git-annex-sync not being idempotent"
+ date="2019-08-20T17:08:45Z"
+ content="""
+Here it is again:
+
+[[!format sh \"\"\"
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+(master_env_v152_py36) 13:01  [viral-ngs-benchmarks] $ git annex sync
+On branch is-import-rabies200
+Your branch is up to date with 'origin/is-import-rabies200'.
+
+
+It took 6.38 seconds to enumerate untracked files. 'status -uno'
+may speed it up, but you have to be careful not to forget to add
+new files yourself (see 'git help status').
+nothing to commit, working tree clean
+commit ok
+remote: Enumerating objects: 2, done.
+remote: Counting objects: 100% (2/2), done.
+remote: Compressing objects: 100% (2/2), done.
+remote: Total 2 (delta 0), reused 1 (delta 0), pack-reused 0
+Unpacking objects: 100% (2/2), done.
+From github.com:broadinstitute/viral-ngs-benchmarks
+   456ce673f18..c365f519845  is-import-rabies200        -> origin/is-import-rabies200
+   456ce673f18..c365f519845  synced/is-import-rabies200 -> origin/synced/is-import-rabies200
+Updating 456ce673f18..c365f519845
+Fast-forward
+ viral-ngs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+Already up to date.
+pull origin ok
+(master_env_v152_py36) 13:01  [viral-ngs-benchmarks] $ git annex sync
+[is-import-rabies200 fe351a22089] git-annex in viral-ngs-benchmarks copy at /data/ilya-work/benchmarks/viral-ngs-benchmarks
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+commit ok
+pull origin ok
+Enumerating objects: 3, done.
+Counting objects: 100% (3/3), done.
+Delta compression using up to 8 threads
+Compressing objects: 100% (2/2), done.
+Writing objects: 100% (2/2), 959 bytes | 959.00 KiB/s, done.
+Total 2 (delta 1), reused 0 (delta 0)
+remote: Resolving deltas: 100% (1/1), completed with 1 local object.
+To github.com:broadinstitute/viral-ngs-benchmarks.git
+   c365f519845..fe351a22089  is-import-rabies200 -> synced/is-import-rabies200
+push origin ok
+(master_env_v152_py36) 13:02  [viral-ngs-benchmarks] $ git annex sync
+On branch is-import-rabies200
+Your branch is up to date with 'origin/is-import-rabies200'.
+
+
+It took 6.40 seconds to enumerate untracked files. 'status -uno'
+may speed it up, but you have to be careful not to forget to add
+new files yourself (see 'git help status').
+nothing to commit, working tree clean
+commit ok
+pull origin ok
+(master_env_v152_py36) 13:04  [viral-ngs-benchmarks] $ uname -a
+Linux ip-172-31-93-72.ec2.internal 4.14.133-113.112.amzn2.x86_64 #1 SMP Tue Jul 30 18:29:50 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
+(master_env_v152_py36) 13:05  [viral-ngs-benchmarks] $ git annex version
+git-annex version: 7.20190819-ge4cecf8
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sql\
+ite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_2\
+24 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE\
+2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224\
+ BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 5
+
+(master_env_v152_py36) 13:05  [viral-ngs-benchmarks] $ git remote -vv
+dnanexus
+from-ilya-work
+from-ilya-work-01
+from-ilya-work-02
+from-ilya-work-03
+ilya-work       /data/ilya-work (fetch)
+ilya-work       /data/ilya-work (push)
+my-ldir
+mygs
+origin  git@github.com:broadinstitute/viral-ngs-benchmarks.git (fetch)
+origin  git@github.com:broadinstitute/viral-ngs-benchmarks.git (push)
+s3-viral-ngs-benchmarks-web
+viral-ngs-benchmarks-s3
+
+(master_env_v152_py36) 13:06  [viral-ngs-benchmarks] $ git annex info --fast
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 11
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        0928dfcc-4dbe-4c24-a5a0-ac05c4a2c829 -- ilya-work
+        0f104e0a-7126-4a4a-a342-e1bb049643f0 -- [from-ilya-work-03]
+        1a276c39-67e3-4098-b469-747ab29fb97e -- viral-ngs-benchmarks copy on /ilya
+        380286ac-2e8f-4285-94da-406eca323411 -- [dnanexus]
+        40d047cf-3548-42d4-bdb6-e1e89a83b6df -- viral-ngs-benchmarks in broad laptop vm clone
+        449efa47-a0e1-4376-a17f-42c7a1f509d1 -- Benchmarks for viral-ngs, stored on Amazon S3 [viral-ngs-benchmarks-s3]
+        6b9993bb-df07-4409-be5e-05c1cd528165 -- [mygs]
+        7205b5c0-4475-47c1-bfc1-39f57a487ac4 -- Website displaying benchmark summaries, stored on AWS S3 [s3-viral-ngs-benchmarks-web]
+        b11d667d-2f3a-432a-a167-d90a1b0559cf -- viral-ngs-benchmarks copy at /data/ilya-work/benchmarks/viral-ngs-benchmarks [here]
+untrusted repositories: 1
+        b9f389c1-2a37-4200-96d9-0f07d97b5417 -- [my-ldir]
+transfers in progress: none
+available local disk space: 427.31 gigabytes (+10 gigabytes reserved)
+
+
+# End of transcript or log.
+\"\"\"]]
+
+
+"""]]
diff --git a/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_4_44c082a9321806ca2a60debf829f9c39._comment b/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_4_44c082a9321806ca2a60debf829f9c39._comment
new file mode 100644
index 0000000000..5c7a6e3233
--- /dev/null
+++ b/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_4_44c082a9321806ca2a60debf829f9c39._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-09-06T16:08:19Z"
+ content="""
+The second transcript seems to show that the first sync never
+tries to push to origin. Then the second sync does push to origin. Then the
+third sync doesn't push to origin. Since sync always pushes to origin
+unless remote.name.annex-push or remote.name.annex-readonly are set,
+I remain confused why successive runs would sometimes push and other times
+not push.
+
+(It also appears as if stderr output is sometimes appearing before
+stdout output that actually comes first. Which makes me not trust this
+transcript's paste accuracy either, or maybe something to do with the
+terminal is resulting in this unusual output ordering.)
+
+Also, the second sync found one modified file to commit, so something must
+have modified that file in between the two sync runs. If a file gets
+modified in between two sync runs, they will of course not do the same
+thing.
+"""]]
diff --git a/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_5_86187583d3128f2d64d1c5d58b31283c._comment b/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_5_86187583d3128f2d64d1c5d58b31283c._comment
new file mode 100644
index 0000000000..9a615e680e
--- /dev/null
+++ b/doc/bugs/git-annex-sync_not_quite_idempotent__63__/comment_5_86187583d3128f2d64d1c5d58b31283c._comment
@@ -0,0 +1,63 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="git and submodule configs"
+ date="2019-09-09T18:47:41Z"
+ content="""
+Here is the git config:
+[[!format sh \"\"\"
+(master_env_v156_py36) 14:35  [viral-ngs-benchmarks] $ git config -l | grep annex- | grep -v uuid
+remote.origin.annex-ignore=true
+remote.ilya-work.annex-speculate-present=true
+remote.ilya-work.annex-readonly=true
+remote.ilya-work.annex-sync=false
+remote.dnanexus.annex-externaltype=dnanexus
+remote.dnanexus.annex-cost=100.0
+remote.dnanexus.annex-availability=GloballyAvailable
+remote.dnanexus.annex-security-allow-unverified-downloads=ACKTHPPT
+remote.dnanexus.annex-sync=false
+remote.dnanexus.annex-ignore=false
+remote.viral-ngs-benchmarks-s3.annex-s3=true
+remote.my-ldir.annex-externaltype=ldir
+remote.my-ldir.annex-cost=200.0
+remote.my-ldir.annex-availability=LocallyAvailable
+remote.from-ilya-work.annex-externaltype=canget
+remote.from-ilya-work.annex-readonly=true
+remote.from-ilya-work.annex-sync=false
+remote.from-ilya-work.annex-ignore=true
+remote.from-ilya-work-01.annex-externaltype=canget
+remote.from-ilya-work-01.annex-ignore=true
+remote.from-ilya-work-01.annex-cost=200.0
+remote.from-ilya-work-01.annex-availability=LocallyAvailable
+remote.from-ilya-work-01.annex-readonly=true
+remote.from-ilya-work-01.annex-sync=false
+remote.from-ilya-work-02.annex-externaltype=canget
+remote.from-ilya-work-02.annex-readonly=true
+remote.from-ilya-work-02.annex-sync=false
+remote.from-ilya-work-02.annex-ignore=true
+remote.from-ilya-work-03.annex-externaltype=canget
+remote.from-ilya-work-03.annex-cost=200.0
+remote.from-ilya-work-03.annex-availability=GloballyAvailable
+remote.from-ilya-work-03.annex-speculate-present=true
+remote.mygs.annex-externaltype=gs_uri
+remote.mygs.annex-cost=400.0
+remote.mygs.annex-availability=GloballyAvailable
+remote.s3-viral-ngs-benchmarks-web.annex-s3=true
+\"\"\"]]
+
+\"stderr output is sometimes appearing before stdout output that actually comes first\" -- probably from running in an Emacs shell terminal.  But the `git-annex-sync` commands were entered by hand, not in a script, so earlier commands' output is earlier.
+
+\"the second sync found one modified file to commit, so something must have modified that file in between the two sync runs\" -- could the first sync run have somehow modified it?
+
+If relevant, this git-annex repo has one submodule, configured as
+
+[[!format sh \"\"\"
+[submodule \"viral-ngs\"]
+        path = viral-ngs
+        url = git@github.com:broadinstitute/viral-ngs.git
+        branch = is-dx-benchmarks
+
+\"\"\"]]
+
+Maybe, add test cases for `git-annex-sync` on repos with submodules?
+"""]]
diff --git a/doc/bugs/git-annex.linux.6.20180914_-__62___assistant_requires_s3_bucket.mdwn b/doc/bugs/git-annex.linux.6.20180914_-__62___assistant_requires_s3_bucket.mdwn
new file mode 100644
index 0000000000..536af21ec0
--- /dev/null
+++ b/doc/bugs/git-annex.linux.6.20180914_-__62___assistant_requires_s3_bucket.mdwn
@@ -0,0 +1,14 @@
+### Please describe the problem.
+
+[[!format sh """
+$ git annex assistant
+git-annex: S3 bucket not configured
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex.linux.6.20180914 - the one i had gotten after autoupdate
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+yes
diff --git a/doc/bugs/git-annex.linux.6.20180914_-__62___assistant_requires_s3_bucket/comment_1_5ec1d63e8f2896876fc88d53b6170b74._comment b/doc/bugs/git-annex.linux.6.20180914_-__62___assistant_requires_s3_bucket/comment_1_5ec1d63e8f2896876fc88d53b6170b74._comment
new file mode 100644
index 0000000000..1a147ffa59
--- /dev/null
+++ b/doc/bugs/git-annex.linux.6.20180914_-__62___assistant_requires_s3_bucket/comment_1_5ec1d63e8f2896876fc88d53b6170b74._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-08T16:01:21Z"
+ content="""
+It seems to me this must depend on the repository that you have the
+assistant configured to run in. If that repository has a S3 remote set up
+in the git config, but is somehow missing the bucket name configuration,
+that would explain this error message.
+
+Or, the S3 remote in question might have been configured with
+autoenable=true, so git-annex tries to enabled it on a new clone?
+
+So please show your repository's .git/config file, and also
+the output of this command run in the repository:
+
+`git show git-annex:remote.log | grep autoenable | cut -d" " -f1`
+"""]]
diff --git a/doc/bugs/git-annex__58___.git__47__annex__47__keys.tmp__47__db__58___setFileMode__58___permission_denied___40__Operation_not_permitted__41__.mdwn b/doc/bugs/git-annex__58___.git__47__annex__47__keys.tmp__47__db__58___setFileMode__58___permission_denied___40__Operation_not_permitted__41__.mdwn
new file mode 100644
index 0000000000..a47eecd321
--- /dev/null
+++ b/doc/bugs/git-annex__58___.git__47__annex__47__keys.tmp__47__db__58___setFileMode__58___permission_denied___40__Operation_not_permitted__41__.mdwn
@@ -0,0 +1,46 @@
+### Please describe the problem.
+
+Trying to do a "git-annex reinit" on Android (sdcard) fails with an error about failing to set a permission. I tried "git-annex init" as well, and that gave the same error.
+
+### What steps will reproduce the problem?
+
+```
+$ git clone ssh://user@host/Westerley-Board.git
+⋮
+$ cd Westerley-Board/
+$ git-annex reinit bc11f6b5-753c-4aeb-88e2-0c2f582e9901
+reinit bc11f6b5-753c-4aeb-88e2-0c2f582e9901 warning: Cannot protect .git/config on this file system - do not store sensitive information here.
+
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+warning: Cannot protect .git/config on this file system - do not store sensitive information here.
+
+  Detected a crippled filesystem.
+warning: Cannot protect .git/config on this file system - do not store sensitive information here.
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+warning: Cannot protect .git/config on this file system - do not store sensitive information here.
+warning: Cannot protect .git/config on this file system - do not store sensitive information here.
+warning: Cannot protect .git/config on this file system - do not store sensitive information here.
+(scanning for unlocked files...)
+
+git-annex: .git/annex/keys.tmp/db: setFileMode: permission denied (Operation not permitted)
+failed
+git-annex: reinit: 1 failed
+```
+
+`git-annex init` fails with the same error.
+
+### What version of git-annex are you using? On what operating system?
+
+OS: Android, on a Amazon Fire Tablet 10. Installed in Termux via the new method (the script); edited the script to tell it to use armel on armv8l. (Supposedly a 64-bit chip, but the Android build is apparently 32-bit).
+
+git-annex version: 7.20190504-g5638ae968
+
+### Please provide any additional information below.
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! I have been using it on this tablet for a while, using the previous Android install steps. That was always a bit buggy, was hoping to upgrade to the new method. I also use git-annex on a bunch of Debian boxes, where it is wonderful. Have somewhere between ½ and ¾ TB data in git-annex, in enough repositories and copied to enough machines that I'd have to sit down and think about it to count them all.
diff --git a/doc/bugs/git-annex__58___.git__47__annex__47__keys.tmp__47__db__58___setFileMode__58___permission_denied___40__Operation_not_permitted__41__/comment_1_2d68f1f5019621bccfd59be5066fdcbe._comment b/doc/bugs/git-annex__58___.git__47__annex__47__keys.tmp__47__db__58___setFileMode__58___permission_denied___40__Operation_not_permitted__41__/comment_1_2d68f1f5019621bccfd59be5066fdcbe._comment
new file mode 100644
index 0000000000..fb7121c560
--- /dev/null
+++ b/doc/bugs/git-annex__58___.git__47__annex__47__keys.tmp__47__db__58___setFileMode__58___permission_denied___40__Operation_not_permitted__41__/comment_1_2d68f1f5019621bccfd59be5066fdcbe._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-05-23T18:06:39Z"
+ content="""
+I remeber that git message, it's trying to remove the world read bit
+from .git/config and the hack that is /sdcard does not support that.
+
+On my phone (Android 8.1), neither git nor git-annex has the problem.
+/sdcard still doesn't really support unix file permissions, but chmod on 
+it no longer fails, just silently leaves wrong permissions.
+
+Given that there are plenty of places in git-annex that set file modes,
+I'd rather not complicate it by ignoring a failure to do so.
+It would not be a problem to fix this one specific case of it, which
+is in Database/Init.hs's callto setFileMode, but I don't know if fixing
+that won't just expose lots of other problems.
+"""]]
diff --git a/doc/bugs/git-annex__58___.git__47__annex__47__keys.tmp__47__db__58___setFileMode__58___permission_denied___40__Operation_not_permitted__41__/comment_2_89b9f0cabdfac72ce6b0b9461672705f._comment b/doc/bugs/git-annex__58___.git__47__annex__47__keys.tmp__47__db__58___setFileMode__58___permission_denied___40__Operation_not_permitted__41__/comment_2_89b9f0cabdfac72ce6b0b9461672705f._comment
new file mode 100644
index 0000000000..2208609791
--- /dev/null
+++ b/doc/bugs/git-annex__58___.git__47__annex__47__keys.tmp__47__db__58___setFileMode__58___permission_denied___40__Operation_not_permitted__41__/comment_2_89b9f0cabdfac72ce6b0b9461672705f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="anthony@ad39673d230d75cbfd19d2757d754030049c7673"
+ nickname="anthony"
+ avatar="http://cdn.libravatar.org/avatar/05b48b72766177b3b0a6ff4afdb70790"
+ subject="comment 2"
+ date="2019-06-10T16:52:23Z"
+ content="""
+I worked around that one (I think I fully checked it out to Termux's $HOME, then moved it to sdcard. If I recall correctly, adjusted mode failed with more permission issues. But direct mode works... (I don't have the device in front of me, but it may be an actual SD card, not the fake sdcard. Which of course doesn't support permissions either.)
+
+I wonder if it'd be easy enough to do a LD_PRELOAD hack to \"fix\" chmod. 
+"""]]
diff --git a/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__.mdwn b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__.mdwn
new file mode 100644
index 0000000000..6374844a1d
--- /dev/null
+++ b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+git-annex will randomly crash.
+
+### What steps will reproduce the problem?
+Unknown. Keeping git-annex running for an extended period, failing to sync properly on XMPP(not sure if that is relevant, but given this haven't been found before it might be)
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 4.20130521-g20710d4 (And multiple prior versions)
+
+### Please provide any additional information below.
+
+.git/annex/daemon.log upload: http://paste.ubuntu.com/5694813/
+
+I could find no debug.log?
+
+> [[!taglink moreinfo]] until it's reproduced with a current version.. --[[Joey]] 
+
+>> Note that this seems like a similar untrappable crash as [[git_annex_daemon_crashes_when_authenticating_with_jabber.de]]. --[[Joey]] 
diff --git a/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_1_e962317a939bf76097ae1a3b53b146e6._comment b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_1_e962317a939bf76097ae1a3b53b146e6._comment
new file mode 100644
index 0000000000..3300f17b96
--- /dev/null
+++ b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_1_e962317a939bf76097ae1a3b53b146e6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-24T15:50:45Z"
+ content="""
+I have seen this once on a similar system (family computer; XMPP being used). Unfortunatly it could be coming from anywhere -- and it's not at all clear how a crash in one thread could take it all down, since there are global top-level per-thread exception handlers that should run and log which thread crashed -- and normally seem to do this quite well.
+
+I may need to make a management process that ensures the assistant stays alive.
+
+I have also seen this happen when a computer is shutting down. But presumably in that case it's not really a bug.
+
+One thing you might try is see what is using socket 16 when it's running, assuming the socket will be the same. (Also, if you've had repeated crashes, it would be good to know if it's 16 each time..). You could do this by looking at `/proc/$pid/fd/16` Also, check the old logs, `.git/annex/daemon.log.*`
+"""]]
diff --git a/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_2_b32472b4c9b61e7a33dca802ecafb05b._comment b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_2_b32472b4c9b61e7a33dca802ecafb05b._comment
new file mode 100644
index 0000000000..b575ce977a
--- /dev/null
+++ b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_2_b32472b4c9b61e7a33dca802ecafb05b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="It did it again."
+ date="2013-05-25T09:31:23Z"
+ content="""
+And this time it was socket 27.
+
+Sadly happened during the night and I didn't monitor the socket when it happened.
+
+"""]]
diff --git a/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_3_fcfea3216831df9afbd855fbd842c27e._comment b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_3_fcfea3216831df9afbd855fbd842c27e._comment
new file mode 100644
index 0000000000..bccfae0d94
--- /dev/null
+++ b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_3_fcfea3216831df9afbd855fbd842c27e._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-05-27T05:03:05Z"
+ content="""
+I got a similar crash:
+
+<pre>
+fd:19: hGetLine: end of file
+fd:18: hFlush: resource vanished (Broken pipe)
+fd:18: hFlush: resource vanished (Broken pipe)
+</pre>
+
+I was able to determine that fd 18/19 is reliably used for one of the git cat-file processes on this system. It's quite likely that fd 16/17 would be similar. fd 27 less likely. (But could easily be some other less long running git command.)
+
+This would be consistent with git cat-file crashing as it's trying to write to it and read from it. 
+
+This took down the transferscanner thread, but the assistant continued running. 
+"""]]
diff --git a/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_4_30d0b40efa59eeecb8a4be6d1baa1520._comment b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_4_30d0b40efa59eeecb8a4be6d1baa1520._comment
new file mode 100644
index 0000000000..aa3a2a3075
--- /dev/null
+++ b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_4_30d0b40efa59eeecb8a4be6d1baa1520._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-05-27T15:31:53Z"
+ content="""
+I tried, as an experiment, killing on of the `git cat-file` child processes of the assistant. As hypothesized, that led to the same thing I saw logged before.
+
+So, why might git commands be dying, and which commands? It would be pretty easy for git-annex to detect git cat-file dying, and restart it. Other commands would be more difficult. Still this might be a git bug which would best be fixed there. It would be good to get a core dump from git.
+"""]]
diff --git a/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_5_4af107f3184bc2abd2c9693167018628._comment b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_5_4af107f3184bc2abd2c9693167018628._comment
new file mode 100644
index 0000000000..2288b1d846
--- /dev/null
+++ b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_5_4af107f3184bc2abd2c9693167018628._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 5"
+ date="2013-05-31T18:17:59Z"
+ content="""
+It will now detect if any of the long-running git processes crash, and automatically restart them. I don't know if this addresses the crash that was originally reported.
+"""]]
diff --git a/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_6_f96027f1e3c405809fae42ce8533c6d1._comment b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_6_f96027f1e3c405809fae42ce8533c6d1._comment
new file mode 100644
index 0000000000..447e9d80eb
--- /dev/null
+++ b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_6_f96027f1e3c405809fae42ce8533c6d1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 6"
+ date="2013-06-14T18:15:27Z"
+ content="""
+Tobias, have you seen this at all since the last release.
+"""]]
diff --git a/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_7_b6fe89deb468a7e4f63f7faab147e3fb._comment b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_7_b6fe89deb468a7e4f63f7faab147e3fb._comment
new file mode 100644
index 0000000000..5d567ae8ee
--- /dev/null
+++ b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_7_b6fe89deb468a7e4f63f7faab147e3fb._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="comment 7"
+ date="2013-06-14T21:26:25Z"
+ content="""
+I'm sure i can still provoke it on some of my machines. But this weekend is completely blocked for me.
+
+I'll update everything to latest and give you an updated log. But will probably not happen till the middle of next week.
+
+
+"""]]
diff --git a/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_8_ebec5d9266604f03959dc16d933ff4a4._comment b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_8_ebec5d9266604f03959dc16d933ff4a4._comment
new file mode 100644
index 0000000000..b44164a896
--- /dev/null
+++ b/doc/bugs/git-annex__58_____60__socket__58___16__62____58___hPutBuf__58___resource_vanished___40__Broken_pipe__41__/comment_8_ebec5d9266604f03959dc16d933ff4a4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="comment 8"
+ date="2013-06-29T09:34:02Z"
+ content="""
+I haven't been able to replicate this on two of my computers with the latest git-annex(as of this message).
+
+It seemed to happen more on my Mac OS X Lion though. And nightlies haven't been build for some time.
+
+So i'm waiting for a updated package for OS X. If you would rather clean up feel free to close this, I can just open it again if i hit it again.
+
+"""]]
diff --git a/doc/bugs/git-annex__58___fd__58__14__58___hGetLine__58___end_of_file.mdwn b/doc/bugs/git-annex__58___fd__58__14__58___hGetLine__58___end_of_file.mdwn
new file mode 100644
index 0000000000..0d773b52cf
--- /dev/null
+++ b/doc/bugs/git-annex__58___fd__58__14__58___hGetLine__58___end_of_file.mdwn
@@ -0,0 +1,51 @@
+[[!tag moreinfo]]
+
+### Please describe the problem.
+
+git-annex webapp won't run 
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+arthur@machine:~/annex$ git-annex --debug webapp
+[2013-07-29 15:02:15 CEST] read: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","show-ref","git-annex"]
+[2013-07-29 15:02:15 CEST] read: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","show-ref","--hash","refs/heads/git-annex"]
+[2013-07-29 15:02:15 CEST] read: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","log","refs/heads/git-annex..a2b8f10ef258dff1a91e0354b2e2a58241631c9a","--oneline","-n1"]
+error: object file /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a is empty
+fatal: loose object a2b8f10ef258dff1a91e0354b2e2a58241631c9a (stored in /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a) is corrupt
+[2013-07-29 15:02:15 CEST] read: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","log","refs/heads/git-annex..8d4b8e04ccf0092d625f680b42e73d7bf15c6517","--oneline","-n1"]
+error: object file /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a is empty
+fatal: loose object a2b8f10ef258dff1a91e0354b2e2a58241631c9a (stored in /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a) is corrupt
+[2013-07-29 15:02:15 CEST] read: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","log","refs/heads/git-annex..6b2665208c11c9ecf969294bf45baac31894d8a7","--oneline","-n1"]
+error: object file /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a is empty
+fatal: loose object a2b8f10ef258dff1a91e0354b2e2a58241631c9a (stored in /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a) is corrupt
+[2013-07-29 15:02:15 CEST] read: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","log","refs/heads/git-annex..9d8429668f2148ea43760fb430e5950fbf42751e","--oneline","-n1"]
+error: object file /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a is empty
+fatal: loose object a2b8f10ef258dff1a91e0354b2e2a58241631c9a (stored in /home/arthur/annex/.git/objects/a2/b8f10ef258dff1a91e0354b2e2a58241631c9a) is corrupt
+[2013-07-29 15:02:15 CEST] chat: git ["--git-dir=/home/arthur/annex/.git","--work-tree=/home/arthur/annex","cat-file","--batch"]
+
+git-annex: fd:14: hGetLine: end of file
+failed
+[2013-07-29 15:02:15 CEST] read: ssh ["-O","stop","-S","/home/arthur/annex/.git/annex/ssh/arthur@git-annex-hostname-arthur_annex","-o","ControlMaster=auto","-o","ControlPersist=yes","arthur@git-annex-hostname-arthur_annex"]
+git-annex: webapp: 1 failed
+"""]]
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+$ git-annex version
+git-annex version: 4.20130516.1
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+local repository version: 3
+default repository version: 3
+supported repository versions: 3 4
+upgrade supported from repository versions: 0 1 2
+
+$ git --version
+git version 1.7.9.5
+
+
+### Please provide any additional information below.
+
+
diff --git a/doc/bugs/git-annex__58___fd__58__14__58___hGetLine__58___end_of_file/comment_1_36756f5d9d591cc52113c5cc0c1eae91._comment b/doc/bugs/git-annex__58___fd__58__14__58___hGetLine__58___end_of_file/comment_1_36756f5d9d591cc52113c5cc0c1eae91._comment
new file mode 100644
index 0000000000..b7fc68ffd5
--- /dev/null
+++ b/doc/bugs/git-annex__58___fd__58__14__58___hGetLine__58___end_of_file/comment_1_36756f5d9d591cc52113c5cc0c1eae91._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 1"
+ date="2013-07-30T19:00:43Z"
+ content="""
+You have a somewhat out of date version there. Can you please try again with a newer version? There have been several fixes to bugs that could present like this.
+"""]]
diff --git a/doc/bugs/git-annex__58___readDirStream__58___inappropriate_type.mdwn b/doc/bugs/git-annex__58___readDirStream__58___inappropriate_type.mdwn
new file mode 100644
index 0000000000..58a3dd93fc
--- /dev/null
+++ b/doc/bugs/git-annex__58___readDirStream__58___inappropriate_type.mdwn
@@ -0,0 +1,33 @@
+### Please describe the problem.
+I'm not entirely sure what I did. Maybe add files with weird names and I copied a lot of files with cp -rL
+
+### What steps will reproduce the problem?
+No idea.
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 8.20210803-g9cae7c5bb
+Archlinux, up to date.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+Basically, everything I do is answered with the error mentioned in the title.
+
+[alex@proliant bannex]$ git annex fix 
+[alex@proliant bannex]$ git annex add .
+git-annex: readDirStream: inappropriate type (Bad message)
+[alex@proliant bannex]$ git annex sync
+git-annex: readDirStream: inappropriate type (Bad message)
+[alex@proliant bannex]$ git annex fsck
+git-annex: readDirStream: inappropriate type (Bad message)
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes. This is my third attempt at getting git-annex running. Conceptually, I think it's the best thing out there. I've had some success at moving around data. But I tend to end up in these dead ends...
diff --git a/doc/bugs/git-annex__58___readDirStream__58___inappropriate_type/comment_1_1b988c92ae79e6d9ddc487bea358dec1._comment b/doc/bugs/git-annex__58___readDirStream__58___inappropriate_type/comment_1_1b988c92ae79e6d9ddc487bea358dec1._comment
new file mode 100644
index 0000000000..7a2d8199e1
--- /dev/null
+++ b/doc/bugs/git-annex__58___readDirStream__58___inappropriate_type/comment_1_1b988c92ae79e6d9ddc487bea358dec1._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-08-09T16:52:53Z"
+ content="""
+It seems likely to me that the directory you're trying to use git-annex in
+either no longer exists, or is in some other strange state.
+
+I can get close to this error message by asking for 
+the contents of the directory "/etc/passwd". Of course,
+that file is not a directory.
+
+	ghci> System.Directory.getDirectoryContents "/etc/passwd"
+	*** Exception: /etc/passwd: getDirectoryContents:openDirStream: inappropriate type (Not a directory)
+
+I have not found a way to make readDirStream throw the error, but this
+shows that the problem is basically something to do with getting directory
+contents.
+
+stracing git-annex might shed some more light on how the `readdir()`
+syscall is failing.
+"""]]
diff --git a/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget.mdwn b/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget.mdwn
new file mode 100644
index 0000000000..688b1ef7bf
--- /dev/null
+++ b/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+I have a repository that is being synced with a normal Bitbucket git repository (with `annex-ignore = true`). It's been created with the webapp in direct mode and I'm using the assistant.
+
+Everything is working fine, but after running `git annex forget` the git-annex branch in Bitbucket stopped being pushed. git-annex is still working correctly, but I have a lot of useless commits in the history.
+
+So currently I have this branches:
+
+    # git branch -a
+    * annex/direct/master
+      git-annex
+      master
+      synced/master
+      remotes/bitbucket/git-annex
+      remotes/bitbucket/master
+      remotes/bitbucket/synced/git-annex
+      remotes/bitbucket/synced/master
+
+And `remotes/bitbucket/git-annex` isn't being updated with the content of `git-annex`
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150812 and 5.20150731 in Debian Sid and Testing
+
+### Please provide any additional information below.
+
+As I've said, git-annex is still working normally, so the solution might be to simply remove that branch.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I use `git-annex` daily with 3 repositories with a total of ~112GB, and I'm really happy with it. Thank you very much for the effort.
diff --git a/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_1_babea9a16f25b471026732ea63dd78a8._comment b/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_1_babea9a16f25b471026732ea63dd78a8._comment
new file mode 100644
index 0000000000..437613ee75
--- /dev/null
+++ b/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_1_babea9a16f25b471026732ea63dd78a8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-15T15:56:46Z"
+ content="""
+"You may need to force git to push the branch to any git repositories not
+running git-annex." -- git-annex-forget man page
+
+I guess bitbucket doesn't accept pushes that replace an existing branch
+with one with a disconnected history. git push --force should sort it out.
+
+I'm not clear how this is a bug. Is there some change needed in the 
+documentation or perhaps in git-annex sync?
+"""]]
diff --git a/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_2_dd24434631ae3898e8f5c1f878d1965f._comment b/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_2_dd24434631ae3898e8f5c1f878d1965f._comment
new file mode 100644
index 0000000000..264a1daf32
--- /dev/null
+++ b/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_2_dd24434631ae3898e8f5c1f878d1965f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Jonan"
+ subject="comment 2"
+ date="2015-09-15T16:13:20Z"
+ content="""
+Ok, sorry, must have miss that info.
+
+Couldn't git-annex take care of the `push -f`?
+"""]]
diff --git a/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_3_70f2b9e61e90528fdbef4d8a6e8dd972._comment b/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_3_70f2b9e61e90528fdbef4d8a6e8dd972._comment
new file mode 100644
index 0000000000..be0e490943
--- /dev/null
+++ b/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_3_70f2b9e61e90528fdbef4d8a6e8dd972._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-09-15T17:34:15Z"
+ content="""
+What git-annex command? 
+
+`git-annex sync` should already deal with this, AFAICS. It forces the push
+to the remote's synced/git-annex branch.
+
+Some remote's may have receive.denyNonFastForwards set, which will prevent
+even a forced push. git-annex sync prints out some hints if this happens.
+"""]]
diff --git a/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_4_11e9ceb40aa5492a1a3e9ebfbd246832._comment b/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_4_11e9ceb40aa5492a1a3e9ebfbd246832._comment
new file mode 100644
index 0000000000..3233e932f2
--- /dev/null
+++ b/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_4_11e9ceb40aa5492a1a3e9ebfbd246832._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Jonan"
+ subject="comment 4"
+ date="2015-09-16T11:15:11Z"
+ content="""
+Yes, the `synced/git-annex` branch is being pushed correctly, it's the `git-annex` branch the one giving trouble.
+"""]]
diff --git a/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_5_20ee285d62c35e18b78b121d8e4de81b._comment b/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_5_20ee285d62c35e18b78b121d8e4de81b._comment
new file mode 100644
index 0000000000..0285ebbed6
--- /dev/null
+++ b/doc/bugs/git-annex_branch_not_being_pushed_after_git-annex_forget/comment_5_20ee285d62c35e18b78b121d8e4de81b._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-09-18T16:27:37Z"
+ content="""
+For all git-annex knows, the remote repository may be actively making
+changes to its own git-annex branch. So, forcing pushes of it could lose
+data, and are not a good idea, and so not done, whereas synced/git-annex
+is force pushed.
+
+If git-annex is indeed being run in the remote repository, it will eventually
+try to merge the newly pushed synced/git-annex with its local git-annex
+branch, notice the forget operation has started, and automatically handle
+updating its git-annex branch appropriatly to be a child of the new
+synced/git-annex branch. At that point, pushes of the git-annex branch will
+work again.
+
+Since your remote is on a hosting service that doesn't use git-annex, that
+doesn't happen, and you'll need to force push to get that branch to update.
+(Although it's somewhat optional to do so; other clients using that remote
+with git-annex sync will pull down the synced/git-annex branch and keep
+working fine even if you never force push the git-annex branch.)
+
+Clearly all this is pretty complicated, but I don't see a good way to improve
+the behavior, unless there's some way to detect that the remote repository
+is not running git-annex, and so assume it's safe to auto-force-push that
+branch. I suppose it could check to see if the remote repository has an
+annex.uuid set, and if not, assume it's not using git-annex. But, if this
+assumption turns out to be wrong (due to a race, or a problem communicating
+the annex.uuid, etc), data loss could result.
+
+Maybe a better fix would be to improve the note about this on git-annex
+forget's man page, and perhaps also make git-annex sync print some helpful
+message when it detects this situation.
+"""]]
diff --git a/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog.mdwn b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog.mdwn
new file mode 100644
index 0000000000..718170a989
--- /dev/null
+++ b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog.mdwn
@@ -0,0 +1,74 @@
+### Please describe the problem.
+
+I have found a really weird commit in my git-annex branch:
+
+    * a59dd1c update (il y a 8 heures) <Antoine Beaupré>
+    * 57f887a update (recovery from race) (recovery from race) (recovery from race) [...]
+
+it repeats that for a looong time. about 12 000 times, to be more precise:
+
+[[!format sh """
+anarcat@marcos:video$ git show 57f887a | wc
+      5   12686   88850
+"""]]
+
+### What steps will reproduce the problem?
+
+Now i have absolutely no idea how I managed that. I got through some pretty dark moments last night trying various levels of git-annex voodoo (including a duplicate repo which was rsync'd to a backup drive so the unique identifier applied to two distinct paths), so I have no idea exactly what happened here.
+
+### What version of git-annex are you using? On what operating system?
+
+debian jessie amd64 5.20140412
+
+### Please provide any additional information below.
+
+[[!format sh """
+anarcat@marcos:video$ git show 57f887a | tail -c 100
+very from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+anarcat@marcos:video$ git show 57f887a | head -c 512
+commit 57f887a9d766829d00832ad1ee23b2785212d055
+Author: Antoine Beaupré <anarcat@koumbit.org>
+Date:   Sat Apr 19 01:48:18 2014 -0400
+
+    update (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery
+"""]]
+
+that's 80KB for only one commit here - maybe that should be cleaned up? --[[anarcat]]
+
+Ah! more information: it seems that 01:48 was the moment i shutdown the assistant in yet another panic... 
+
+[[!format sh """
+anarcat@marcos:video$ ls -al .git/annex/daemon.log*
+-rw-r--r-- 1 anarcat anarcat  17075 avril 19 09:28 .git/annex/daemon.log
+-rw-r--r-- 1 anarcat anarcat 128367 avril 19 01:48 .git/annex/daemon.log.1
+"""]]
+
+an extract from that second logfile:
+
+[[!format sh """
+19/Apr/2014:01:31:38 -0400 [Error#yesod-core] unknown response from git cat-file ("9a73bf01-ed01-450d-a0ab-f20fff47ed32 encryption=none name=stephc rsyncurl=192.168.0.104:video/ type=rsync timestamp=1397865844.925354s","refs/heads/git-annex:remote.log") @(yesod-core-1.2.3:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5)
+19/Apr/2014:01:31:50 -0400 [Error#yesod-core] unknown response from git cat-file ("fe428a7a-25a2-4c2e-b01f-315c490cbe45 encryption=none name=myrsync rsyncurl=/home/anarcat/video/ type=rsync timestamp=1397868063.038898s","refs/heads/git-annex:remote.log") @(yesod-core-1.2.3:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5)
+19/Apr/2014:01:31:57 -0400 [Error#yesod-core] unknown response from git cat-file ("","refs/heads/git-annex:remote.log") @(yesod-core-1.2.3:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5)
+[2014-04-19 01:32:03 EDT] TransferScanner: Syncing with test, mnt
+Depuis /mnt/video
+ * [nouvelle branche] synced/git-annex -> test/synced/git-annex
+ * [nouvelle branche] synced/master -> test/synced/master
+fatal: 'mnt' does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+Already up-to-date.
+[2014-04-19 01:32:21 EDT] main: warning git-annex has been shut down
+
+(Recording state in git...)
+(Recording state in git...)
+(Recording state in git...)
+(Recording state in git...)
+"""]]
+
+the last line repeats about 4000 times.
+
+i would love to paste the daemon.log.1 file, but it seems like it containts encryption credentials... which i have no idea how to get rid of or change.
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_1_b83888a98075125dd043f323c99da03b._comment b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_1_b83888a98075125dd043f323c99da03b._comment
new file mode 100644
index 0000000000..75bfd73685
--- /dev/null
+++ b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_1_b83888a98075125dd043f323c99da03b._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 1"
+ date="2014-04-20T17:11:02Z"
+ content="""
+Is there one commit with this long message, or 12 thousand commits each adding another (recovery from race) to the pyramid?
+
+<pre>
+ - Also safely handles a race that can occur if a change is being pushed
+ - into the branch at the same time. When the race happens, the commit will
+ - be made on top of the newly pushed change, but without the index file
+ - being updated to include it. The result is that the newly pushed
+ - change is reverted. This race is detected and another commit made
+ - to fix it.
+</pre>
+
+If there is only one message, then it must have tried 12k times to commit to the git-annex branch and each time something else pushed or commited to the git-annex branch and overwrote its commit. This seems statistically unlikely. (Also there's locking to prevent multiple local git-annex processes from committing at the same time.)
+
+There have been a few other unexplained reports of this race detection code repeatedly triggering.
+
+> \"shutdown the assistant in yet another panic\"
+
+This implies some hasty, perhaps unusual shutdown method, and some unusual situation. I think you could tell me more about what was going on.
+"""]]
diff --git a/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_2_4a7d824b6e75693cf47f6efbf2c99e2e._comment b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_2_4a7d824b6e75693cf47f6efbf2c99e2e._comment
new file mode 100644
index 0000000000..0eeabf070d
--- /dev/null
+++ b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_2_4a7d824b6e75693cf47f6efbf2c99e2e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 2"
+ date="2014-04-20T23:58:00Z"
+ content="""
+this was a single commit.
+
+i am not sure i can extract much more information from my memory: details are hazy as i was working late on a problem that night... sorry!
+"""]]
diff --git a/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_3_cbbeaa691d102bd7d29f5e9bad9d6f53._comment b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_3_cbbeaa691d102bd7d29f5e9bad9d6f53._comment
new file mode 100644
index 0000000000..8651405091
--- /dev/null
+++ b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_3_cbbeaa691d102bd7d29f5e9bad9d6f53._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="Francois"
+ ip="2001:788:5:1:29c2:de49:9811:51c8"
+ subject="comment 3"
+ date="2014-08-15T20:45:38Z"
+ content="""
+I've been experiencing the exact same problem and searching for **recovery from race** lead me to this bug report. Thanks for reporting it!
+
+For a few months, a repo storing ~19'000 files (mostly immutable pictures) started to launch memory hungry \"git log\" processes. For example:
+
+    4797 francois  20   0 8118296 7.719g   2032 D  22.3 50.2   0:11.61 git                                                                                                   
+
+    4797 pts/1    D+     0:12 git --git-dir=~/Pictures/.git --work-tree=~/Pictures -c core.bare=false log refs/heads/git-annex..52e44b967ad5d316d832562be02c5555c1f6d2a4 --oneline -n1
+
+Thanks to the hints found in this report, I was able to find many huge commit messages such as this one:
+
+    $ git show 6357b208 
+    commit 6357b2081e7c85dfe1ccc10824b75f3e212e6386
+    Author: Francois Deppierraz <francois@ctrlaltdel.ch>
+    Date:   Sat Jun 14 10:38:46 2014 +0200
+
+        update (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) [...]
+
+    $ git show 6357b208 | wc 
+      5  444026 3108236
+
+There were probably many new files added on Jun 14th and looking for a way to increase to sync speed, especially to a S3-like remote, I found the solution on this wiki for [multiple concurrent transfers](https://git-annex.branchable.com/forum/Feature_request:_Multiple_concurrent_transfers/).
+
+This looks like a likely culprit for generating race conditions. What do you think?
+
+    git-annex version: 5.20140412ubuntu1
+"""]]
diff --git a/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_4_094191b806ac76b2aef325733fe37136._comment b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_4_094191b806ac76b2aef325733fe37136._comment
new file mode 100644
index 0000000000..e80d66b5a3
--- /dev/null
+++ b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_4_094191b806ac76b2aef325733fe37136._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Francois"
+ ip="2001:788:5:1:29c2:de49:9811:51c8"
+ subject="comment 4"
+ date="2014-08-15T20:51:12Z"
+ content="""
+Bonus question: is there any way to bring this repo back into a working state (for instance with git-filter-branch?) ?
+"""]]
diff --git a/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_5_c97926b15ba320f57a6441f9844cb139._comment b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_5_c97926b15ba320f57a6441f9844cb139._comment
new file mode 100644
index 0000000000..62903f1f16
--- /dev/null
+++ b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_5_c97926b15ba320f57a6441f9844cb139._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-02-09T21:10:58Z"
+ content="""
+I guess the thing to do in this case is to run `git annex forget`
+"""]]
diff --git a/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_6_3b70a60ef1c47871a3933176eac38174._comment b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_6_3b70a60ef1c47871a3933176eac38174._comment
new file mode 100644
index 0000000000..25e6059f10
--- /dev/null
+++ b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_6_3b70a60ef1c47871a3933176eac38174._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2015-02-09T21:59:31Z"
+ content="""
+[[forum/repair_stuck_on_ls-tree_command]] is another case of that, and I got ahold of
+that repository for analysis.
+
+In that case, there was indeed an inverse pyramid effect where each commit
+added one more " (recovery from race)" to its parent commit.
+
+The code can clearly loop 
+if it keeps detecting a race and somehow fails to recover from it. Leading
+to a whole stack of commits with progressively longer messages.
+I don't see any way to get just one commit with a long message, which
+comment #1 seems to say happened.
+
+Apparently loops for a while and then succeeds in recovering from
+the race, since it then stops looping.
+
+I have added additional debug info to the commit message, in hopes of detecting
+what might be going wrong that causes it to loop.
+
+Seems to me there are two possibilities.
+
+One is that something else is continually changing the git-annex
+branch in a way that keeps triggering the race. If so, it might make
+sense for git-annex to do a brief random sleep (a few hundredths of a
+second) before recovering, to let whatever it is quiet down. I've done so.
+
+The other is some kind of bug where it detects a race when none
+occurred. Perhaps it's misparsing the commit or git cat-file is failing
+to output it, and so it's not finding the expected parent refs, for example.
+But in that case, why would it detect a race for many commits
+in a row, and then eventually not detect a race anymore?
+
+Also, I've made these messages no longer stack up even if it does go into a
+loop, which will at least help with the object size bloat, though not with the
+number of commits bloat.
+"""]]
diff --git a/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_7_fc56ec87725c7427794b70ee2ba2822a._comment b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_7_fc56ec87725c7427794b70ee2ba2822a._comment
new file mode 100644
index 0000000000..cd7510140a
--- /dev/null
+++ b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_7_fc56ec87725c7427794b70ee2ba2822a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2015-02-09T22:44:50Z"
+ content="""
+The only other thing I can think to do about this is to make git-annex block
+direct pushes to the git-annex branch, by setting up a pre-receive hook.
+
+Then, there should be no way for the race to occur
+(except for a locking failure, or a pull into the branch?),
+and git-annex wouldn't need to check for it
+"""]]
diff --git a/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__.mdwn b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__.mdwn
new file mode 100644
index 0000000000..bc7c3e4292
--- /dev/null
+++ b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+git-annex's WebDAV support does not like (aka it does not work) the WebDAV server of the freenet cloud.
+    
+### What steps will reproduce the problem?
+
+My first attempt was:
+
+    WEBDAV_USERNAME='XXX' WEBDAV_PASSWORD='XXX' git annex initremote webdav type=webdav url='https://webmail.freenet.de/webdav' encryption=none
+    initremote webdav (testing WebDAV server...) 
+    git-annex: WebDAV test failed: StatusCodeException (Status {statusCode = 401, statusMessage = "Unauthorized"}) [("Date","Fri, 04 Dec 2015 12:20:57 GMT"),("Server","Apache/2.2.16 (Debian)"),("WWW-Authenticate","Basic realm=\"MD-Cloud\""),
+    ("Vary","Accept-Encoding"),("Content-Encoding","gzip"),("Content-Length","20"),("Connection","close"),("Content-Type","text/html; charset=iso-8859-15"),("X-Response-Body-Start",""),("X-Request-URL","MKCOL https://webmail.freenet.de:443/webdav/tmp")]
+    (CJ {expose = []}): user error failed
+    git-annex: initremote: 1 failed
+
+Ok this fails (what is the error?). However, it does create a folder "tmp" in the "cloud". A second attempt yields another error:
+
+    WEBDAV_USERNAME='XXX' WEBDAV_PASSWORD='XXX' git annex initremote webdav type=webdav url='https://webmail.freenet.de/webdav' encryption=none
+    initremote webdav (testing WebDAV server...) 
+    git-annex: WebDAV test failed: StatusCodeException (Status {statusCode = 501, statusMessage = "Not Implemented"}) [("Date","Fri, 04 Dec 2015 12:21:22 GMT"),("Server","Apache/2.2.16 (Debian)"),("Content-Length","349"),("Connection","close"),
+    ("Content-Type","application/xml; charset=utf-8"),("X-Response-Body-Start","<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<d:error xmlns:d=\"DAV:\" xmlns:s=\"http://sabredav.org/ns\">\n  <s:exception>Sabre\\DAV\\Exception\\NotImplemented</s:exception>\n  
+    <s:message>This server is not compatible with OS/X finder. Consider using a different WebDAV client or webserver.</s:message>\n  <s:sabredav-version>1.8.6</s:sabredav-version>\n</d:error>\n"),("X-Request-URL","PUT https://webmail.freenet.de:443/webdav
+    /tmp/git-annex-test")] (CJ {expose = []}): user error failed
+    git-annex: initremote: 1 failed
+
+which is I guess the same. The WebDAV server does support writing and locking files. I tried writing using davfs2 and locking-unlocking using cadaver. I guess in the end that it's the server's fault, but it would be great to know what exactly fails at this point :).
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20151116-gbe86081
+
+Gentoo Linux
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+First time trying WebDAV support.
diff --git a/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_1_db7b584c1e932d24e0dcf464b023a659._comment b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_1_db7b584c1e932d24e0dcf464b023a659._comment
new file mode 100644
index 0000000000..a4028e4823
--- /dev/null
+++ b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_1_db7b584c1e932d24e0dcf464b023a659._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="sts"
+ subject="comment 1"
+ date="2015-12-07T08:12:26Z"
+ content="""
+ok, I could find the source of the problem: they use sabredav as WebDAV server and sabredav does not support chunked transfers:
+
+        // Intercepting the Finder problem
+        if (($expected = $request->getHeader('X-Expected-Entity-Length')) && $expected > 0) {
+
+            /*
+            Many webservers will not cooperate well with Finder PUT requests,
+            because it uses 'Chunked' transfer encoding for the request body.
+
+            The symptom of this problem is that Finder sends files to the
+            server, but they arrive as 0-length files in PHP.
+
+            If we don't do anything, the user might think they are uploading
+            files successfully, but they end up empty on the server. Instead,
+            we throw back an error if we detect this.
+
+            The reason Finder uses Chunked, is because it thinks the files
+            might change as it's being uploaded, and therefore the
+            Content-Length can vary.
+
+            Instead it sends the X-Expected-Entity-Length header with the size
+            of the file at the very start of the request. If this header is set,
+            but we don't get a request body we will fail the request to
+            protect the end-user.
+            */
+
+            // Only reading first byte
+            $firstByte = fread($body, 1);
+            if (strlen($firstByte) !== 1) {
+                throw new Exception\Forbidden('This server is not compatible with OS/X finder. Consider using a different WebDAV client or webserver.');
+            }
+          
+            ...
+
+Although, I did not told git-annex to chunk the transfer :-/, because I did not append a 'chunk' parameter. Any ideas how to fix that?
+"""]]
diff --git a/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_2_72e9ecc6acdc555e36f5588120d070fa._comment b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_2_72e9ecc6acdc555e36f5588120d070fa._comment
new file mode 100644
index 0000000000..8df1c736dd
--- /dev/null
+++ b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_2_72e9ecc6acdc555e36f5588120d070fa._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-12-11T15:08:30Z"
+ content="""
+The first failure is git-annex sending MKCOL (make directory basically).
+The server fails with "Unauthorized". You say it also made the directory.
+That's got to be a bug in the server, no? It can't sanely have an
+authorization problem and also go on and do the unathorized action.
+(Sounds rather like a security hole..)
+
+As to the PUT failure, the chunked transfer encoding mentioned in that
+comment is a regular part of the HTTP protocol (this is not connected
+to git-annex's own chunking).
+<https://en.wikipedia.org/wiki/Chunked_transfer_encoding>
+
+Looks like this PHP webdav server might be delegating the actual HTTP
+to whatever web server it's running on somehow. Since chunked transfer
+encoding might not be supported by some web server, they are left trying to
+detect that. I don't know if their check for that is accurate.
+
+As to the implementation in git-annex,
+Network.Http.Client.RequestBodyStreamChunked is documented to be the only
+thing that causes a chunked request body to be sent, and git-annex is using
+RequestBodyLBS instead. Unless the documentation is wrong (and I also 
+looked at the http-client source code and the documentation seems accurate),
+I am doubtful that the chunked transfer encoding is actually being used by
+git-annex. If eg a protocol dump shows that it is in fact using chunked
+transfer encoding (ie, contains "Transfer-Encoding: chunked"),
+that would be grounds to file a bug on the http-client library.
+
+Aah, but.. git-annex is sending an empty file. And the webdav server's
+check consists of reading 1 byte. 
+Of course there's not a byte to read if an empty file is being sent!
+So that code you showed is certianly buggy.
+
+I've changed git-annex to send a non-empty file when testing the webdav
+server to work around this.
+"""]]
diff --git a/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_3_b2ef283a3933e22542e05ce9a1acef7d._comment b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_3_b2ef283a3933e22542e05ce9a1acef7d._comment
new file mode 100644
index 0000000000..3403a59fc8
--- /dev/null
+++ b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_3_b2ef283a3933e22542e05ce9a1acef7d._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="sts"
+ subject="comment 3"
+ date="2015-12-20T19:49:26Z"
+ content="""
+hey joey!
+
+thanks, it (kinda) worked :). At least the initialization works now pretty fine. But uploading files does not work as expected. It does upload  some data, but does not move the data to the corresponding folder (from 'tmp' to $hash):
+
+    git annex copy --debug --to webdav 1354580391258.jpg
+    [2015-12-20 20:31:36.985579] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+    [2015-12-20 20:31:36.990098] process done ExitSuccess
+    [2015-12-20 20:31:36.990584] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2015-12-20 20:31:36.993635] process done ExitSuccess
+    [2015-12-20 20:31:36.994311] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..2ff0c487bc1c92c11a45131b55f6fb2ba034071d\",\"-n1\",\"--pretty=%H\"]
+    [2015-12-20 20:31:36.998675] process done ExitSuccess
+    [2015-12-20 20:31:36.999747] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+    [2015-12-20 20:31:37.003483] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"1354580391258.jpg\"]
+    copy 1354580391258.jpg (checking webdav...) (to webdav...) 
+    100%        564.6KB/s 0s
+    DAV failure: 409 \"Conflict\"
+    failed
+    git-annex: copy: 1 failed
+
+In the 'tmp'-folder on the server I can find the file ('SHA256E-s1156230--...'), but this file is not 100% identical to the one I uploaded. Well, it seems that the first byte is missing ;) at least if I compare the files via vimdiff:
+
+    0000000: d8ff e000 104a 4649 4600 0101 0100 4800  .....JFIF.....H.               |  0000000: ffd8 ffe0 0010 4a46 4946 0001 0101 0048  ......JFIF.....H               
+    0000010: 4800 00ff db00 4300 0101 0101 0101 0101  H.....C.........               |  0000010: 0048 0000 ffdb 0043 0001 0101 0101 0101  .H.....C........               
+    0000020: 0101 0101 0102 0203 0202 0202 0204 0303  ................               |  0000020: 0101 0101 0101 0202 0302 0202 0202 0403  ................               
+    0000030: 0203 0504 0505 0504 0404 0506 0706 0505  ................               |  0000030: 0302 0305 0405 0505 0404 0405 0607 0605  ................               
+    0000040: 0706 0404 0609 0607 0808 0808 0805 0609  ................               |  0000040: 0507 0604 0406 0906 0708 0808 0808 0506  ................               
+    0000050: 0a09 080a 0708 0808 ffdb 0043 0101 0101  ...........C....               |  0000050: 090a 0908 0a07 0808 08ff db00 4301 0101  ............C...               
+    0000060: 0202 0204 0202 0408 0504 0508 0808 0808  ................               |  0000060: 0102 0202 0402 0204 0805 0405 0808 0808  ................
+
+As you can see, on the left side (aka 'the uploaded file') the first two hexadecimal values are missing in comparison to the right side (the source), so the first byte is missing.
+
+I guess in the end it is still the same problem, right :)?
+"""]]
diff --git a/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_4_7a139eb2c11ab2e32d22ca0f8bb648a5._comment b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_4_7a139eb2c11ab2e32d22ca0f8bb648a5._comment
new file mode 100644
index 0000000000..d12f6cbc52
--- /dev/null
+++ b/doc/bugs/git-annex_cannot_connect_to_freenet_cloud___40__webdav__41__/comment_4_7a139eb2c11ab2e32d22ca0f8bb648a5._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-01-20T19:22:36Z"
+ content="""
+As to where the first byte went, it seems rather suggestive that the part
+of the server's code you pasted earlier reads out `$firstByte`. Perhaps it
+forgot to preserve that first byte in the file.
+
+Which is horrible, but then there's the "Conflict" error. All I can make of
+this is that the server is probably rejecting the MOVE request for some reason.
+That might be reasonable if the destination file already existed, 
+but I don't think it does in this case, so who knows.
+
+Only thing I'm sure of is, I never want to entrust this particular webdav
+server with any of my data!
+"""]]
diff --git a/doc/bugs/git-annex_died_of_signal_11_when_syncing_content.mdwn b/doc/bugs/git-annex_died_of_signal_11_when_syncing_content.mdwn
new file mode 100644
index 0000000000..d0781d2816
--- /dev/null
+++ b/doc/bugs/git-annex_died_of_signal_11_when_syncing_content.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+
+git-annex dies of signal 11 when syncing content with Box.
+
+I noticed that the assistant stopped syncing after a few files, so I tried to sync manually through the terminal and saw the error.
+
+### What steps will reproduce the problem?
+
+    $ git annex sync box.com --content
+    commit  ok
+    copy myfile1 (checking box.com...) (to box.com...) 
+    ok                      
+    copy myfile2 (checking box.com...) (to box.com...) 
+    ok                      
+    copy myfile3 (checking box.com...) (to box.com...) 
+    ok                      
+    copy myfile4 (checking box.com...) (to box.com...) 
+    ok                      
+    copy myfile5 (checking box.com...) error: git-annex died of signal 11
+
+The number of files that are copied correctly is quite random, some times it syncs 200 files and other times only 2 or 3.
+
+
+### What version of git-annex are you using? On what operating system?
+
+5.20141125 on Debian Sid (everything install from official packages)
+
+### Please provide any additional information below.
+
+I don't know how to get more details of the problem, I haven't manage to get a more precise error activating logs or verbose mode, if there's anything I can do to debug the problem I'll be more than willing.
diff --git a/doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_1_e982f985e5ca57454725e9e9a482e30c._comment b/doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_1_e982f985e5ca57454725e9e9a482e30c._comment
new file mode 100644
index 0000000000..f81f1d7328
--- /dev/null
+++ b/doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_1_e982f985e5ca57454725e9e9a482e30c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-04T18:38:09Z"
+ content="""
+Well, a signal 11 can be caused by several different things, including
+some messed up pointer stuff in a C library, or just bad memory on your
+computer. I think a memory test would be a good first step. 
+
+If the memory checks clean, running git-annex in gdb and getting a stack
+trace after a crash may help.
+"""]]
diff --git a/doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_2_e920f624ccf2e3a9c71a00105ebc3595._comment b/doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_2_e920f624ccf2e3a9c71a00105ebc3595._comment
new file mode 100644
index 0000000000..83bbe81afc
--- /dev/null
+++ b/doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_2_e920f624ccf2e3a9c71a00105ebc3595._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="git-annex.visiteur@e9d364191d2ffc1b163c8d9e4c57dbadf58aad8e"
+ nickname="git-annex.visiteur"
+ avatar="http://cdn.libravatar.org/avatar/59640df9d44f100f0bf98c1cbb430037"
+ subject="Same problem with git-annex 8.20210223"
+ date="2021-10-20T19:09:29Z"
+ content="""
+I have exactly the same problem with Debian 11 and git-annex 8.20210223. In kernel.log I can see 
+
+> traps: git-annex[91341] general protection fault ip:3c6be67 sp:7ffd7afd26f8 error:0 in git-annex[400000+3a78000]
+
+I've done a memtest86 on my memory and nothing appended.
+
+Oddly, I have another machin with same versions of OS and git-annex, but it does not reproduce the problem. The bigger difference between the two machines is that machine with problem run on ZFS. Is it possible that the problem comes from that?
+
+"""]]
diff --git a/doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_3_373e63d55e07cb5cdecc4e01d5d52b79._comment b/doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_3_373e63d55e07cb5cdecc4e01d5d52b79._comment
new file mode 100644
index 0000000000..d73ed01f4e
--- /dev/null
+++ b/doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_3_373e63d55e07cb5cdecc4e01d5d52b79._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-10-20T19:18:17Z"
+ content="""
+Since the vast number of places git-annex runs do not have this problem, I
+don't think we can draw any conclusions about differences between your 2
+machines.
+
+Memory issue still seems like the most likely bet.
+
+Are you able to reproduce the problem repeatedly?
+"""]]
diff --git a/doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_4_678a0136f143d2d7874226b3fc744eb2._comment b/doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_4_678a0136f143d2d7874226b3fc744eb2._comment
new file mode 100644
index 0000000000..2665ce27e8
--- /dev/null
+++ b/doc/bugs/git-annex_died_of_signal_11_when_syncing_content/comment_4_678a0136f143d2d7874226b3fc744eb2._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="git-annex.visiteur@e9d364191d2ffc1b163c8d9e4c57dbadf58aad8e"
+ nickname="git-annex.visiteur"
+ avatar="http://cdn.libravatar.org/avatar/59640df9d44f100f0bf98c1cbb430037"
+ subject="comment 4"
+ date="2021-10-21T08:24:55Z"
+ content="""
+Yes the problem occurs each time I want to do git annex get . on a repository with about 20 000 files. 
+
+As i say, I've perfom memtest86 (several times) and memtester (several times) without any problem. Do you think it could be hardware problem despite these results ?
+
+You suggest using gdb. I get
+
+Thread 1 \"git-annex\" received signal SIGSEGV, Segmentation fault.
+0x0000000003c6be67 in ?? ()
+
+(gdb) backtrace
+
+#0  0x0000000003c6be67 in ?? ()
+#1  0x0000000000000000 in ?? ()
+
+which is not very helpful. Do you have any advices to investigate?
+
+"""]]
diff --git a/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights.mdwn b/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights.mdwn
new file mode 100644
index 0000000000..58b11deb32
--- /dev/null
+++ b/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+Installing on Windows requires installing git followed by git-annex.
+Installing the former works without admin rights, but the latter cannot be
+installed afterwards.
+
+### What steps will reproduce the problem?
+
+1. Create a Windows account without admin rights
+2. Install git
+3. Install git-annex
+
+### What version of git-annex are you using? On what operating system?
+
+Latest release on MS Windows.
+
+### Please provide any additional information below.
+
+
+Installing git creates read-only directories that cannot be used by the
+git-annex install afterwards. Without admin rights, the read-only flag of
+the git dir cannot be altered.
+
+[[!tag confirmed]]
diff --git a/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_1_2533800ab5a95c5d71c3b47a630e751a._comment b/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_1_2533800ab5a95c5d71c3b47a630e751a._comment
new file mode 100644
index 0000000000..32fc0311e7
--- /dev/null
+++ b/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_1_2533800ab5a95c5d71c3b47a630e751a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 1"
+ date="2013-11-26T16:19:41Z"
+ content="""
+Thanks, this had been reported in the forum before, but they did not point at the directory permissions as the problem.
+
+It would be possible to modify the installer to install git-annex somewhere else and add it to the PATH, but it seems this is a utter nightmare on windows and I'd have to pull in enormous NSIS scripts from their wiki, of unknown provenance. Which is why I am piggybacking on the git installation's PATH.
+"""]]
diff --git a/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_2_5b71785acf16a8d9ea457726599daef3._comment b/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_2_5b71785acf16a8d9ea457726599daef3._comment
new file mode 100644
index 0000000000..4bd5c2c0ed
--- /dev/null
+++ b/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_2_5b71785acf16a8d9ea457726599daef3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7"
+ nickname="Frederik Vanrenterghem"
+ subject="comment 2"
+ date="2013-11-26T21:57:28Z"
+ content="""
+Just wondering how git succeeds in installing as non-admin user. The folder it goes in is also read-only.
+"""]]
diff --git a/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_3_63e4ff79bc683a70dd9a85c66e26e56a._comment b/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_3_63e4ff79bc683a70dd9a85c66e26e56a._comment
new file mode 100644
index 0000000000..ac5e77d08d
--- /dev/null
+++ b/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_3_63e4ff79bc683a70dd9a85c66e26e56a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 3"
+ date="2013-12-12T19:33:50Z"
+ content="""
+I've made the installer now request admin rights if run by a non-admin. Hopefully good enough. However, the NSIS docs say that only works on Vista or higher. The old XP I'm using (that will be completely EOLed soon IIRC) still has the problem.
+"""]]
diff --git a/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows.mdwn b/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows.mdwn
new file mode 100644
index 0000000000..6f46c6f6ea
--- /dev/null
+++ b/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+
+If I addurl file pointing to file:///C:/... it seems to work just fine, but then refuses to drop it stating that can't verify its presence.
+
+Please see two screenshots (sorry for not cut/paste here since it was already was painful -- debugging under Virtualbox in remote vnc through debconf internet which for some reason drops for me quite often):
+
+http://www.onerussian.com/tmp/gkrellShoot_08-19-15_220150.png
+http://www.onerussian.com/tmp/gkrellShoot_08-19-15_184052.png
+
+as screenshot shows, apparently wget is clueless about file:// targets on windows (while curl does fine) -- may be related ;-)
+
+### What steps will reproduce the problem?
+
+addurl some file:///C:/ under windows pointing to existing file, and then try to drop that annexed file
+
+### What version of git-annex are you using? On what operating system?
+
+windows
+20150805 or so
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_1_f0d30a953f072f8d9a929a4a6ba69914._comment b/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_1_f0d30a953f072f8d9a929a4a6ba69914._comment
new file mode 100644
index 0000000000..c7de2eb6db
--- /dev/null
+++ b/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_1_f0d30a953f072f8d9a929a4a6ba69914._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="seems just ignore errors while adding urls to &quot;unsupported&quot; urls"
+ date="2015-08-19T21:59:09Z"
+ content="""
+actually situation is somewhat similar on linux as well in a sense that annex manages to addurl a file using e.g. file:///./data   url (not sure even if legit) without puking but contains wrong content (empty):
+
+[[!format  sh \"\"\"
+
+% mkdir XXX
+% cd XXX
+% git init; git annex init
+Initialized empty Git repository in /tmp/XXX/.git/
+init  ok
+(recording state in git...)
+% echo 123 > data
+% git annex addurl --file=annexed file:///./data
+addurl annexed (downloading file:///./data ...) 
+
+ok
+(recording state in git...)
+% cat annexed 
+% git annex drop annexed
+drop annexed (checking file:///./data...) (unsafe) 
+  Could only verify the existence of 0 out of 1 necessary copies
+
+  Rather than dropping this file, try using: git annex move
+
+  (Use --force to override this check, or adjust numcopies.)
+failed
+git-annex: drop: 1 failed
+% git annex addurl --file=annexedfull file://$PWD/data
+addurl annexedfull (downloading file:///tmp/XXX/data ...) 
+######################################################################## 100.0%
+ok
+(recording state in git...)
+% cat annexedfull
+123
+% git annex drop annexedfull                          
+drop annexedfull (checking file:///tmp/XXX/data...) ok
+(recording state in git...)
+% annex version
+zsh: command not found: annex
+% git annex version
+git-annex version: 5.20150812-2
+
+\"\"\"]]
+"""]]
diff --git a/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_2_504ea07f798838710cdbf6133135c815._comment b/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_2_504ea07f798838710cdbf6133135c815._comment
new file mode 100644
index 0000000000..5097e2e16a
--- /dev/null
+++ b/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_2_504ea07f798838710cdbf6133135c815._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-09-09T16:36:13Z"
+ content="""
+I can't reproduce that behavior on linux. 
+
+	joey@darkstar:~/tmp/xx>git annex addurl  --file=annexed file:///./data
+	addurl annexed (downloading file:///./data ...) 
+	curl: (37) Couldn't open file /data
+
+Here, curl seems to be doing the right thing; the url is not relative; it's 
+for `/./data`, which doesn't exist.
+
+Relative `file:` urls shouldn't be valid at all, I think?
+
+---
+
+For checking if a file: url exits, git-annex parses the url and stats
+the file itself. The first screenshot
+shows this check for file: url existance failing on Windows for 
+the url `file:///C:/tmp/test/test.dat`
+
+I guess this might come down to problems with parsing file: urls on
+Windows; seems especially complicated by drive letters. git-annex and curl
+seem to parse this url in different ways.
+
+Checking how that url parses, the uriScheme is "file:" and the uriPath is
+"/C:/tmp/test/test.dat". So, it seems clear why it fails to stat that file.
+
+Is there actually a valid way to produce a file: url that refers to a drive
+letter? curl seems to think so, since it found the file when `git annex
+addurl` ran it. I don't know if the above parse is valid, but it's not
+git-annex's code doing the parse, but the URI parsing library.
+
+(Possibly related bug report: 
+<http://git-annex.branchable.com/bugs/git_annex_test_fails_when_run_through_powershell/>
+)
+"""]]
diff --git a/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_3_a9bd50ebe805afefab103da31b88cf89._comment b/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_3_a9bd50ebe805afefab103da31b88cf89._comment
new file mode 100644
index 0000000000..3e3f19d19d
--- /dev/null
+++ b/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_3_a9bd50ebe805afefab103da31b88cf89._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="file:/// must be forced to file:// on windows"
+ date="2023-01-27T09:19:10Z"
+ content="""
+I just want to leave a note that the `file:` URL scheme handling on windows is still problematic. A file URL (e.g. generated by Python's `pathlib.as_uri()`) like the following does not work:
+
+```
+file:///C:/DLTMP/myarchive.zip
+```
+
+it is parsed to the path `/C:/DLTMP/myarchive.zip` (as reported by OP), which is invalid.
+
+A workaround is to replace `file:///` with `file://` (remove one slash). This makes git-annex accept the URL and parse it to the correct path `C:/DLTMP/myarchive.zip`.
+
+However, such a \"double-slash\" URL is invalid. [Wikipedia](https://en.wikipedia.org/wiki/File_URI_scheme) has a dedicated bit on \"How many slashes?\" which states
+
+> file://path (i.e. two slashes, without a hostname) is never correct, but is often used
+"""]]
diff --git a/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_4_f2bd555ca36b42dac6a213e7c947f1f9._comment b/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_4_f2bd555ca36b42dac6a213e7c947f1f9._comment
new file mode 100644
index 0000000000..df17624c7b
--- /dev/null
+++ b/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_4_f2bd555ca36b42dac6a213e7c947f1f9._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-03-13T18:54:33Z"
+ content="""
+Wikipedia seems to be wrong about that.
+I took a quick look at <https://datatracker.ietf.org/doc/html/rfc8089#appendix-E.2>
+and it says that "file:c:/path/to/file" is a valid URI on Windows. And it will be
+parsed ok by git-annex. So you could just use those.
+
+The RFC does say that "file:///c:/path/to/file" should also be supported.
+(Though I don't understand its reference to the "path-absolute" rule.)
+
+I don't know if network-uri could be made to support that, it seems that
+it would have to handle windows and non-windows differently. Because on linux,
+"file:///c:/path/to/file" should parse to a path "/c:/path/to/file",
+which is after all a valid path if you choose to have a `/c:` directory!
+
+But network-uri is a pure uri parser and it does not seem right for it to parse
+the same uri two different ways depending on the OS it's running on. And it doesn't
+special-case handling of file urls at all, it only implements RFC3986.
+We could try opening an issue at <https://github.com/haskell/network-uri/issues>
+and find out what its maintainer thinks.
+
+I suppose that git-annex, when running on windows, every place after it parses an
+url could:
+
+1. Check if it's a file: url
+2. If the path starts with "/DRIVE:", remove the leading "/"
+
+Yugh.
+"""]]
diff --git a/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_5_e00d70ba6b88d9cf60fcb183f7ea4980._comment b/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_5_e00d70ba6b88d9cf60fcb183f7ea4980._comment
new file mode 100644
index 0000000000..96e0489914
--- /dev/null
+++ b/doc/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/comment_5_e00d70ba6b88d9cf60fcb183f7ea4980._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-03-27T17:57:52Z"
+ content="""
+Ok, put in that ugly fix.
+"""]]
diff --git a/doc/bugs/git-annex_findkeys_does_not_know_--largerthan.mdwn b/doc/bugs/git-annex_findkeys_does_not_know_--largerthan.mdwn
new file mode 100644
index 0000000000..591564f055
--- /dev/null
+++ b/doc/bugs/git-annex_findkeys_does_not_know_--largerthan.mdwn
@@ -0,0 +1,50 @@
+### Please describe the problem.
+
+The man page of  [git-annex findkeys](https://git-annex.branchable.com/git-annex-findkeys/) says: 
+
+> OPTIONS
+>
+>  *  matching options
+>     The git-annex-matching-options(1) can be used to specify which keys to list.
+
+However, this is not true for the options that match file size. Being able to do for example `git-annex findkeys --largerthan 100M`
+is important for me as it allows me to track down the files that occupy most of my storage, allowing me to move them to some
+archive. However, if I try to call the above command, it does not show me a list of keys matching the criterion, but a help page
+as if I have misspelled the option:
+
+>     $ git annex findkeys --largerthan 1
+>     Invalid option `--largerthan'
+>     
+>     Usage: git-annex COMMAND
+>       git-annex - manage files with git, without checking their contents in
+>     
+>     Commonly used commands:
+>
+>     add             add files to annex
+>     [...]
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+    echo hi > file
+    git annex init
+    git annex add file
+    git commit -m "Test commit"
+    git annex find --largerthan 1   # << this lists "file"
+    git annex findkeys --largerthan 1   # << this fails
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+* git-annex version: 10.20230926-g44a7b4c9734adfda5912dd82c1aa97c615689f57
+* Rocky Linux 9.2
+* git 2.40.1
+
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I am using it for my research project (data science/predictions in plant breeding) and it allows me to keep track of the
+current model iteration and associated results. Thank you for this! 
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/git-annex_findkeys_does_not_know_--largerthan/comment_1_f6484f69669439ef49513b84d3bd91cf._comment b/doc/bugs/git-annex_findkeys_does_not_know_--largerthan/comment_1_f6484f69669439ef49513b84d3bd91cf._comment
new file mode 100644
index 0000000000..05ea2c90a0
--- /dev/null
+++ b/doc/bugs/git-annex_findkeys_does_not_know_--largerthan/comment_1_f6484f69669439ef49513b84d3bd91cf._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-11-28T15:48:09Z"
+ content="""
+Not all options in git-annex-matching-options can be used by findkeys. It
+mentions this when it says "Some of these options can also be used by
+commands to specify which keys they act on."
+
+However in this case, --largerthan and --smallerthan could in fact be made
+to operate on keys, and I've done so.
+"""]]
diff --git a/doc/bugs/git-annex_fsck_in_quiet_mode_don__39__t_report_the_files_it_failed_to_download.mdwn b/doc/bugs/git-annex_fsck_in_quiet_mode_don__39__t_report_the_files_it_failed_to_download.mdwn
new file mode 100644
index 0000000000..31da88a6ce
--- /dev/null
+++ b/doc/bugs/git-annex_fsck_in_quiet_mode_don__39__t_report_the_files_it_failed_to_download.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+
+When running 'git annex fsck --from $i --quiet' when $i is a special remote, git annex will report failure to download as 'failed to download file from remote' without telling me which file it failed to download.
+
+### What steps will reproduce the problem?
+
+Just running 'git annex fsck --from remote --quiet' on some special remote with connexion problem
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170101-1+b1 from Debian stretch
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git annex is very efficient to sync my usb key, laptops and servers together.
+
+> [[fixed|done]]. Sorry for the 4 year delay, seems I missed this bug
+> report. --[[Joey]]
diff --git a/doc/bugs/git-annex_fsck_in_quiet_mode_don__39__t_report_the_files_it_failed_to_download/comment_1_074e49431bd18c43164872de3733b0e8._comment b/doc/bugs/git-annex_fsck_in_quiet_mode_don__39__t_report_the_files_it_failed_to_download/comment_1_074e49431bd18c43164872de3733b0e8._comment
new file mode 100644
index 0000000000..7465aae6f4
--- /dev/null
+++ b/doc/bugs/git-annex_fsck_in_quiet_mode_don__39__t_report_the_files_it_failed_to_download/comment_1_074e49431bd18c43164872de3733b0e8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Rémi"
+ avatar="http://cdn.libravatar.org/avatar/0f25950c04685d6c7ccb22215268d6a7"
+ subject="comment 1"
+ date="2017-08-21T14:17:14Z"
+ content="""
+Running 'git annex fsck --more --from remote' allowed me to try again and find which file had the problem. 
+"""]]
diff --git a/doc/bugs/git-annex_get_with_umlaut_characters_in_filenames.mdwn b/doc/bugs/git-annex_get_with_umlaut_characters_in_filenames.mdwn
new file mode 100644
index 0000000000..c05130a694
--- /dev/null
+++ b/doc/bugs/git-annex_get_with_umlaut_characters_in_filenames.mdwn
@@ -0,0 +1,59 @@
+### Please describe the problem.
+
+Files with umlauts were not copied from local system, all other files were copied successfully.
+
+### What steps will reproduce the problem?
+
+Trying to sync content from a repository on the same machine.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20150727 / Darwin tba.lan 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64
+
+### Please provide any additional information below.
+
+[[!format sh """
+$ git annex get .
+get Die Sterne/Flucht in die Flucht (Bonus Track Version)/03 Ihr wollt mich töten.m4a
+  Unable to access these remotes: tba
+
+  Try making some of these repositories available:
+  	2cabf5e0-00ae-4cc6-b9b7-5d303a7f3f06 -- Music [tba]
+   	8e315ed0-f318-45f7-98ca-1a791f9c92df -- jan@hostname:/srv/annex-Music
+failed
+get Die Sterne/Flucht in die Flucht (Bonus Track Version)/03 Ihr wollt mich töten.m4a
+  Unable to access these remotes: tba
+
+  Try making some of these repositories available:
+  	2cabf5e0-00ae-4cc6-b9b7-5d303a7f3f06 -- Music [tba]
+   	8e315ed0-f318-45f7-98ca-1a791f9c92df -- jan@hostname:/srv/annex-Music
+failed
+get Die Sterne/Flucht in die Flucht (Bonus Track Version)/10 Der Bär.m4a
+  Unable to access these remotes: tba
+
+  Try making some of these repositories available:
+  	2cabf5e0-00ae-4cc6-b9b7-5d303a7f3f06 -- Music [tba]
+   	8e315ed0-f318-45f7-98ca-1a791f9c92df -- jan@hostname:/srv/annex-Music
+failed
+get Die Sterne/Flucht in die Flucht (Bonus Track Version)/10 Der Bär.m4a
+  Unable to access these remotes: tba
+
+  Try making some of these repositories available:
+  	2cabf5e0-00ae-4cc6-b9b7-5d303a7f3f06 -- Music [tba]
+   	8e315ed0-f318-45f7-98ca-1a791f9c92df -- jan@hostname:/srv/annex-Music
+failed
+"""]]
+
+the *tba* repository is accessible since all the other files were synced correctly.
+
+Git status reports untracked files which look like they were renamed.
+
+[[!format sh """
+$ git status
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+
+	"Ant\303\263nio Varia\303\247\303\265es/"
+	"B Fachada/B Fachada/01 sozinho no r\303\263que.mp3"
+	"B Fachada/B Fachada/03 D\303\241 mais m\303\272sica \303\240 b\303\263fia.mp3"
+"""]]
diff --git a/doc/bugs/git-annex_get_with_umlaut_characters_in_filenames/comment_1_0724d70364f7067d864a80a39e2e609a._comment b/doc/bugs/git-annex_get_with_umlaut_characters_in_filenames/comment_1_0724d70364f7067d864a80a39e2e609a._comment
new file mode 100644
index 0000000000..b5e8f21f52
--- /dev/null
+++ b/doc/bugs/git-annex_get_with_umlaut_characters_in_filenames/comment_1_0724d70364f7067d864a80a39e2e609a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-13T21:29:41Z"
+ content="""
+`git annex get` only acts on files that are present in the working tree of
+the git repo, and which `git ls-files` lists. So, if git is somehow
+confused about these filenames, which is appears to be, it makes sense that
+git-annex wouldn't be operating on them.
+
+I don't know why git would have such a problem with files with umlaut in
+their names. AFAIK, git is quite agnostic about filename encodings.
+However, your git status seems to be the smoking gun; the files are either
+not known to git at all, or it thinks they were renamed. Does the git
+log --stat show the files being deleted. Have you tried (re)adding the
+files to git?
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content.mdwn b/doc/bugs/git-annex_is_slow_at_reading_file_content.mdwn
new file mode 100644
index 0000000000..f87496718d
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content.mdwn
@@ -0,0 +1,55 @@
+### Please describe the problem.
+
+Any time git-annex reads a file (and presumably hashes it), it is about half as fast as just reading the file or `sha256sum`ing it on my hardware.
+
+The repo I'm reading from is inside a btrfs on top of an HDD but the same happens in a btrfs image inside a tmpfs and inside a tmpfs directly, just to a lesser degree as there is no IO or filesystem overhead.
+
+My CPU is pretty slow but reading a 1.7GiB file normally or even checksumming it is about an order of magnitude faster:
+
+|Command|Time|
+|:--|--:|
+|`git-annex fsck file`| 21s |
+|`sha256sum file`| 5s |
+|`cat file > /dev/null`| 2s |
+
+(Tested inside a btrfs image in tmpfs with same settings (compress etc.))
+
+This also happens on `add`, `copy`, `get` etc. but it's even worse there because of higher IO overhead which results in average speeds of ~70MiB/s.  
+I'm currently in the process of transferring a few terabytes worth from multiple relatively slower drives onto one very fast drive and would like to parallelise the transfer. Unfortunately though, this issue seems to scale anti-proportionally with the level of parallelism. If I'd get 70MiB/s from each drive individually at `-J1`, I'd get ~35MiB/s from both at `-J2`.
+
+I had to resort to `rsync`ing the objects dirs manually as that's faster than any method of git-annex-internal transfers.
+
+### What steps will reproduce the problem?
+
+Compare runtime of `git-annex fsck` vs. `sha256sum` and `cat`.
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 10.20220127
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.6.4.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+```
+
+NixOS 21.11
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
+[[!meta title="cryptonite does not use SHA instructions for sha256"]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_10_d04b5bc031f73363d44b81f436b59781._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_10_d04b5bc031f73363d44b81f436b59781._comment
new file mode 100644
index 0000000000..02d122e32f
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_10_d04b5bc031f73363d44b81f436b59781._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2023-09-22T16:57:14Z"
+ content="""
+crytonite has been forked to crypton, which git-annex can build with as an
+option. It may be that the maintainer of that
+will be more open to this kind of optimisation.
+<https://github.com/kazu-yamamoto/crypton/issues>
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_11_cab37d851237a7798f74867e08aaafb9._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_11_cab37d851237a7798f74867e08aaafb9._comment
new file mode 100644
index 0000000000..5cffc2f2bf
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_11_cab37d851237a7798f74867e08aaafb9._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2024-03-01T18:53:39Z"
+ content="""
+My laptop now has SHA256 in hardware I assume, as I'm seeing similar speed
+differences. Eg:
+
+	joey@darkstar:~/tmp/x3>time sha256sum x
+	e1f21b651362cf2f86ccc14a7376c33a49f30d7d14afe1ec6993eead5e8cfe41  x
+	0.53user 0.17system 0:00.71elapsed 99%CPU (0avgtext+0avgdata 3712maxresident)k
+	32inputs+0outputs (1major+239minor)pagefaults 0swaps
+	joey@darkstar:~/tmp/x3>time git-annex fsck x
+	fsck x (checksum...) ok
+	(recording state in git...)
+	3.22user 0.40system 0:03.63elapsed 100%CPU (0avgtext+0avgdata 61180maxresident)k
+	0inputs+144outputs (0major+8547minor)pagefaults 0swaps
+
+I agree that this bug should be left open since even a relatively low-end laptop
+now has this, git-annex shouldn't leave so much performance on the table.
+
+I've opened an issue on crypton:
+<https://github.com/kazu-yamamoto/crypton/issues/31>
+
+If it's rejected from crypton, I'm open to considering another library. 
+I'd rather avoid OpenSSL wrappers because adding a C library dependency on openssl
+will complicate building git-annex in some situations. It would be better to
+have a haskell library that, like cryptonite, embeds the necessary C code.
+
+Also, whatever library git-annex uses needs to support incremental hashing,
+otherwise git-annex has to pay a performance penalty of re-reading a file to hash
+it after download, rather than hashing while downloading.
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_12_466a365bca48065cc6b9e280b5c385a5._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_12_466a365bca48065cc6b9e280b5c385a5._comment
new file mode 100644
index 0000000000..e7078e5a92
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_12_466a365bca48065cc6b9e280b5c385a5._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/86b8c2d893dfdf2146e1bbb8ac4165fb"
+ subject="comment 12"
+ date="2024-03-02T08:32:40Z"
+ content="""
+Thank you for looking into this again.
+
+> I'd rather avoid OpenSSL wrappers because adding a C library dependency on openssl will complicate building git-annex in some situations.
+
+Would it be possible to make this a build-time option perhaps?
+
+git-annex without SIMD hashing obviously still *works* fast enough for many purposes as its the status quo but having it would be a greatly appreciated optimisation by many. It'd be great to have the option to enable it wherever possible and simply fall back to non-SIMD where it isn't.
+
+> Also, whatever library git-annex uses needs to support incremental hashing, otherwise git-annex has to pay a performance penalty of re-reading a file to hash it after download, rather than hashing while downloading.
+
+Agreed. Incremental hashing is too important to lose over a general optimisation like this.
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_13_0eb12582a3e182b697a07b833cfbe384._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_13_0eb12582a3e182b697a07b833cfbe384._comment
new file mode 100644
index 0000000000..91690fe040
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_13_0eb12582a3e182b697a07b833cfbe384._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2024-03-11T13:43:19Z"
+ content="""
+<https://hackage.haskell.org/package/botan-low> is another possibility.
+There is a significant effort ongoing to build up this library stack in
+haskell. It does need the botan C library to be installed separately
+unfortunately (I've suggested they embed it).
+
+I have not benchmarked it yet but the docs say it supports hardware
+accellerated SHA1, SHA2, SHA3 on x86 and also SHA1, SHA2 on arm64.
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_1_ed54af250541e2add89938b939016659._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_1_ed54af250541e2add89938b939016659._comment
new file mode 100644
index 0000000000..0e44a2de3e
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_1_ed54af250541e2add89938b939016659._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 1"
+ date="2022-03-04T14:16:53Z"
+ content="""
+To expand on this, results from my more powerful machine reading a 14G file (all in tmpfs):
+
+|Command|Time|
+|:--|--:|
+|`git-annex fsck file`| 45s |
+|`sha256sum file`| 7s |
+|`cat file > /dev/null`| 1s |
+
+(5800X with dual channel quad rank 3600MT/s CL16 RAM)
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_2_786b21544854ad719eac07d08ba8d206._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_2_786b21544854ad719eac07d08ba8d206._comment
new file mode 100644
index 0000000000..a5f1f5d019
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_2_786b21544854ad719eac07d08ba8d206._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 2"
+ date="2022-03-04T14:44:29Z"
+ content="""
+(Sorry, command used on the more powerful machine was `git annex add`, not `fsck`.)
+
+The read speed here (~320MiB/s) is pretty close to the `openssl speed sha256` result for 16B block size (~360MiB/s) or 64B blocks with SHA256 acceleration disabled (~300MiB/s, `OPENSSL_ia32cap=:~0x20000000`).
+
+What block size is used here and does git-annex use SHA instructions for hashing?
+
+
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_3_190a153449f7bb07fb4aca89db236881._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_3_190a153449f7bb07fb4aca89db236881._comment
new file mode 100644
index 0000000000..79c1d8d903
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_3_190a153449f7bb07fb4aca89db236881._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-03-07T19:09:17Z"
+ content="""
+Cannot reproduce that:
+
+	joey@darkstar:/tmp/rr>/usr/bin/time git-annex fsck bigfile 
+	fsck bigfile (checksum...) ok
+	(recording state in git...)
+	10.08user 0.35system 0:10.40elapsed 100%CPU (0avgtext+0avgdata 43500maxresident)k
+	joey@darkstar:/tmp/rr>/usr/bin/time sha256sum bigfile
+	7219108977be820830169fc13fded5000e9db329fab4e687fc14236f932d4060  bigfile
+	11.00user 0.28system 0:11.29elapsed 99%CPU (0avgtext+0avgdata 1956maxresident)k
+	120inputs+0outputs (2major+105minor)pagefaults 0swaps
+
+(1 gb file; tmpfs)
+
+git-annex simply uses
+[cryptonite](https://hackage.haskell.org/package/cryptonite) for hashing.
+Which is a thin wrapper around C code, and contains optimised routines for
+some processors, generally copied from the reference C implementations.
+
+The block size is 32 kb. This can be changed in Utility/Metered.hs 
+in defaultChunkSize.
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_4_492a11bcabc20b02239bc3b12438a51a._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_4_492a11bcabc20b02239bc3b12438a51a._comment
new file mode 100644
index 0000000000..0f28b7732b
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_4_492a11bcabc20b02239bc3b12438a51a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 4"
+ date="2022-03-08T11:56:42Z"
+ content="""
+I found the issue, cryptonite doesn't make use of SHA instructions which both of my machines have. I'm going to open an issue upstream.
+
+Is there an alternative crypto library that can make use of these perhaps? The speedup/efficiency gain is **>5x** on my 5800X.
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_5_1367e6e461a9a049527197c262635c2f._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_5_1367e6e461a9a049527197c262635c2f._comment
new file mode 100644
index 0000000000..ef61f61182
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_5_1367e6e461a9a049527197c262635c2f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 5"
+ date="2022-03-08T13:24:21Z"
+ content="""
+Upstream bug report: https://github.com/haskell-crypto/cryptonite/issues/361
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_6_123c81ad10aef15814f1c831e18c0a23._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_6_123c81ad10aef15814f1c831e18c0a23._comment
new file mode 100644
index 0000000000..f221fc5f39
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_6_123c81ad10aef15814f1c831e18c0a23._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-03-08T16:26:55Z"
+ content="""
+Awesome that you were able to reproduce it in cryptonite and file that. 
+Thank you!
+
+I'm inclined to close this, because it seems unlikely there will be a fix
+for it in git-annex. One fix that would be possible here is for
+git-annex to use the exteneral sha256sum command. But, that would prevent
+git-annex from displaying progress while hashing, which is why it moved
+away from it in the first place.
+
+Of course, you could also try using a different kind of hash that is
+faster for new content.
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_7_2885c2f164dbe59234568966e901bdd7._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_7_2885c2f164dbe59234568966e901bdd7._comment
new file mode 100644
index 0000000000..86034e2417
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_7_2885c2f164dbe59234568966e901bdd7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-03-08T17:47:37Z"
+ content="""
+I don't know of anything else in the haskell space that is likely to be
+better, cryptonite is basically the standard library for this. There is
+certianly precident in it for using optimised instructions, like SSE.
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_8_559e5c3b5ea9c166b3aa4a2e975643c6._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_8_559e5c3b5ea9c166b3aa4a2e975643c6._comment
new file mode 100644
index 0000000000..dbe6a0e207
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_8_559e5c3b5ea9c166b3aa4a2e975643c6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 8"
+ date="2022-03-09T11:40:28Z"
+ content="""
+SHA256 is by far the fastest hash on my Celeron J4105 with acceleration. Seconds is BLAKE at around half the speed of accelerated SHA256 or over twice the speed of unaccelerated SHA256.
+
+Seems like coreutils simply uses openssl when available and openssl handles HW acceleration. I just tried using two Haskell OpenSSL wrappers (hopenssl and HsOpenSSL) in my minimal example and it was actually *faster* than the openssl CLI utility by almost 100MiB/ (though still a bit slower than `sha256sum`).
+
+Would using those be an option?
+"""]]
diff --git a/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_9_c8b4c2e955b4ef5caaaaf2f834fb37f8._comment b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_9_c8b4c2e955b4ef5caaaaf2f834fb37f8._comment
new file mode 100644
index 0000000000..fc6e9d34ad
--- /dev/null
+++ b/doc/bugs/git-annex_is_slow_at_reading_file_content/comment_9_c8b4c2e955b4ef5caaaaf2f834fb37f8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 9"
+ date="2022-05-25T12:22:58Z"
+ content="""
+Upstream does not seem interested in improving performance. Are there alternative libraries that could be used instead?
+
+Would it be possible to use OpenSSL somehow perhaps?
+
+AFAICT git-annex hooks into the hashing routine for things like progress monitoring. Perhaps those could be re-architected to work with an external \"black box\" library or process?
+"""]]
diff --git a/doc/bugs/git-annex_merge_stalls.mdwn b/doc/bugs/git-annex_merge_stalls.mdwn
new file mode 100644
index 0000000000..80330a822a
--- /dev/null
+++ b/doc/bugs/git-annex_merge_stalls.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+
+Running git-annex merge shows the output "git-annex merge ", followed by a blinking cursor. The command never seems to end.
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+4.20130827-gd04d9bb on MacOS X Mountain Lion
+
+### Please provide any additional information below.
+
+dtruss output at https://www.dropbox.com/s/4b3yqn7ajfz5el2/annex-merge.log
+
+[[!meta title="no indication when git-annex is stuck waiting for a lock"]]
+
+[[!tag confirmed]]
diff --git a/doc/bugs/git-annex_merge_stalls/comment_1_31578a754945bdcb902c62ff58704bcb._comment b/doc/bugs/git-annex_merge_stalls/comment_1_31578a754945bdcb902c62ff58704bcb._comment
new file mode 100644
index 0000000000..123212d5d4
--- /dev/null
+++ b/doc/bugs/git-annex_merge_stalls/comment_1_31578a754945bdcb902c62ff58704bcb._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.255.110"
+ subject="comment 1"
+ date="2013-09-09T15:45:17Z"
+ content="""
+The relevant part of the log is:
+
+<pre>
+65332/0x53591a:  open(\"/Users/gsolsberry/annex/.git/annex/journal.lck\0\", 0x601, 0x1B6)          = 8 0
+65332/0x53591a:  fcntl(0x8, 0x9, 0x107009D60)            = -1 Err#-1
+</pre>
+
+waitToSetLock thinks fcntl is failing to lock the file due to something else having it locked, and retries, leading to the hang.
+
+I'm told on irc that this was installed using the prebuilt image, and that a previous version of it didn't have the problem.
+"""]]
diff --git a/doc/bugs/git-annex_merge_stalls/comment_2_f3b6bf180466b5931bfd20b2f0229422._comment b/doc/bugs/git-annex_merge_stalls/comment_2_f3b6bf180466b5931bfd20b2f0229422._comment
new file mode 100644
index 0000000000..2fe9b8ac04
--- /dev/null
+++ b/doc/bugs/git-annex_merge_stalls/comment_2_f3b6bf180466b5931bfd20b2f0229422._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl8B4Ima-VCCJ4y32Gvfii8EmvTyN9tFGM"
+ nickname="Glendon"
+ subject="comment 2"
+ date="2013-09-09T15:54:59Z"
+ content="""
+With latest 20130909 version, the following log from git-annex merge:
+
+https://www.dropbox.com/s/3hklzfsflpxuk5s/annex-merge.log.1
+"""]]
diff --git a/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment b/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment
new file mode 100644
index 0000000000..a0f452b5dc
--- /dev/null
+++ b/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.255.110"
+ subject="comment 3"
+ date="2013-09-09T19:35:25Z"
+ content="""
+This problem cleared up after a reboot (and a crash, apparently).
+
+<pre>
+joeyh so, my thought is that perhaps you had a git-annex process before that was holding the lock.
+joeyh for example, if you ran it and ctrl-z'd at just the right time, it could be suspended and holding the lock
+joeyh (or the kernel coud have gotten confused, which given you also had a crash, who knows..)
+dp sounds logical
+joeyh forcing locks is always a problematic thing
+joeyh but git-annex could certainly notice if it seems to be stalled and print some useful messages
+joeyh and maybe have a way to run with locks forced
+</pre>
+"""]]
diff --git a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
new file mode 100644
index 0000000000..96033a8ed3
--- /dev/null
+++ b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
@@ -0,0 +1,243 @@
+### Please describe the problem.
+
+I want to start git-annex remotedaemon on login as a systemd user service. And I want to have logs in journald, not in .git/annex/daemon.log. Thus I use this service definition:
+
+```
+[Unit]
+Description=remotedaemon running in ~/annex
+
+[Service]
+ExecStart=%h/.local/bin/git-annex remotedaemon --verbose --debug --foreground
+WorkingDirectory=%h/annex
+```
+
+Unfortunately, the git-annex process exits immediately. So I added strace:
+
+    ExecStart=/usr/bin/strace %h/.local/bin/git-annex remotedaemon --verbose --debug --foreground
+
+And got (journald logs; removed time, username and "strace[$PID]" from line beginnings):
+
+```
+systemd[1644]: Started remotedaemon running in ~/annex.
+execve("/home/thk/.local/bin/git-annex", ["/home/thk/.local/bin/git-annex", "remotedaemon", "--verbose", "--debug", "--foreground"], 0x7fff95d3eda0 /* 42 vars */) = 0
+brk(NULL)                               = 0x4f44000
+access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
+openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
+fstat(3, {st_mode=S_IFREG|0644, st_size=148740, ...}) = 0
+mmap(NULL, 148740, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f63b2a9f000
+close(3)                                = 0
+
+<<<<<<<<< cut library loading >>>>>>>>>
+
+mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f63b252d000
+mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f63b252a000
+arch_prctl(ARCH_SET_FS, 0x7f63b252a740) = 0
+mprotect(0x7f63b2720000, 12288, PROT_READ) = 0
+mprotect(0x7f63b2540000, 4096, PROT_READ) = 0
+mprotect(0x7f63b2829000, 4096, PROT_READ) = 0
+mprotect(0x7f63b2568000, 4096, PROT_READ) = 0
+mprotect(0x7f63b2732000, 4096, PROT_READ) = 0
+mprotect(0x7f63b27b5000, 4096, PROT_READ) = 0
+mprotect(0x7f63b27ba000, 4096, PROT_READ) = 0
+mprotect(0x7f63b27c7000, 4096, PROT_READ) = 0
+mprotect(0x7f63b27e4000, 4096, PROT_READ) = 0
+mprotect(0x7f63b280b000, 8192, PROT_READ) = 0
+mprotect(0x7f63b2a9b000, 4096, PROT_READ) = 0
+mprotect(0x7f63b2951000, 16384, PROT_READ) = 0
+mprotect(0x388b000, 77824, PROT_READ)   = 0
+mprotect(0x7f63b2aec000, 4096, PROT_READ) = 0
+munmap(0x7f63b2a9f000, 148740)          = 0
+set_tid_address(0x7f63b252aa10)         = 144630
+set_robust_list(0x7f63b252aa20, 24)     = 0
+rt_sigaction(SIGRTMIN, {sa_handler=0x7f63b28156b0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f63b2821520}, NULL, 8) = 0
+rt_sigaction(SIGRT_1, {sa_handler=0x7f63b2815750, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7f63b2821520}, NULL, 8) = 0
+rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
+prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
+brk(NULL)                               = 0x4f44000
+brk(0x4f65000)                          = 0x4f65000
+openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
+fstat(3, {st_mode=S_IFREG|0644, st_size=3031632, ...}) = 0
+mmap(NULL, 3031632, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f63b2245000
+close(3)                                = 0
+clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=10054427}) = 0
+sysinfo({uptime=38828, loads=[21056, 51328, 54784], totalram=16756289536, freeram=1420591104, sharedram=967385088, bufferram=867651584, totalswap=34099687424, freeswap=34099687424, procs=1643, totalhigh=0, freehigh=0, mem_unit=1}) = 0
+prlimit64(0, RLIMIT_AS, NULL, {rlim_cur=RLIM64_INFINITY, rlim_max=RLIM64_INFINITY}) = 0
+mmap(0x4200000000, 1099512676352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x4200000000
+madvise(0x4200000000, 1099512676352, MADV_DONTNEED) = 0
+madvise(0x4200000000, 1099512676352, MADV_DONTDUMP) = 0
+mmap(0x4200000000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4200000000
+madvise(0x4200000000, 1048576, MADV_WILLNEED) = 0
+madvise(0x4200000000, 1048576, MADV_DODUMP) = 0
+mmap(0x4200100000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4200100000
+madvise(0x4200100000, 1048576, MADV_WILLNEED) = 0
+madvise(0x4200100000, 1048576, MADV_DODUMP) = 0
+mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f63b1a44000
+mprotect(0x7f63b1a45000, 8388608, PROT_READ|PROT_WRITE) = 0
+clone(child_stack=0x7f63b2243fb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f63b22449d0, tls=0x7f63b2244700, child_tidptr=0x7f63b22449d0) = 144633
+openat(AT_FDCWD, "/proc/self/task/144633/comm", O_RDWR) = 4
+write(4, "ghc_ticker", 10)              = 10
+close(4)                                = 0
+rt_sigaction(SIGINT, {sa_handler=0x36a9820, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
+rt_sigaction(SIGINT, NULL, {sa_handler=0x36a9820, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, 8) = 0
+rt_sigaction(SIGINT, {sa_handler=0x36a9820, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b25a4100}, NULL, 8) = 0
+rt_sigaction(SIGPIPE, {sa_handler=0x36a9780, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=0}, 8) = 0
+rt_sigaction(SIGQUIT, {sa_handler=0x36a9800, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
+rt_sigaction(SIGTSTP, {sa_handler=0x36a9840, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, NULL, 8) = 0
+epoll_create(256)                       = 4
+fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
+pipe([5, 6])                            = 0
+fcntl(6, F_GETFL)                       = 0x1 (flags O_WRONLY)
+fcntl(6, F_SETFL, O_WRONLY|O_NONBLOCK)  = 0
+fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
+fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
+eventfd2(0, 0)                          = 7
+fcntl(7, F_GETFL)                       = 0x2 (flags O_RDWR)
+fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
+fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
+epoll_ctl(4, EPOLL_CTL_ADD, 5, {EPOLLIN, {u32=5, u64=5}}) = 0
+epoll_ctl(4, EPOLL_CTL_ADD, 7, {EPOLLIN, {u32=7, u64=7}}) = 0
+mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f63b1243000
+mprotect(0x7f63b1244000, 8388608, PROT_READ|PROT_WRITE) = 0
+clone(child_stack=0x7f63b1a42fb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f63b1a439d0, tls=0x7f63b1a43700, child_tidptr=0x7f63b1a439d0) = 144635
+openat(AT_FDCWD, "/proc/self/task/144635/comm", O_RDWR) = 8
+write(8, "git-annex:w", 11)             = 11
+close(8)                                = 0
+futex(0x4f63820, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x4f636f8, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
+futex(0x4f63700, FUTEX_WAKE_PRIVATE, 1) = 0
+pipe([8, 9])                            = 0
+fcntl(9, F_GETFL)                       = 0x1 (flags O_WRONLY)
+fcntl(9, F_SETFL, O_WRONLY|O_NONBLOCK)  = 0
+fcntl(8, F_SETFD, FD_CLOEXEC)           = 0
+fcntl(9, F_SETFD, FD_CLOEXEC)           = 0
+eventfd2(0, 0)                          = 10
+fcntl(10, F_GETFL)                      = 0x2 (flags O_RDWR)
+fcntl(10, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
+fcntl(10, F_SETFD, FD_CLOEXEC)          = 0
+futex(0x4f63818, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x4f63820, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x3eea308, FUTEX_WAKE_PRIVATE, 1) = 1
+clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=11616402}) = 0
+futex(0x3eea308, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)
+futex(0x3eea308, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
+futex(0x3eea308, FUTEX_WAKE_PRIVATE, 1) = 0
+rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
+rt_sigaction(SIGINT, {sa_handler=0x36a98c0, sa_mask=[], sa_flags=SA_RESTORER|SA_RESETHAND|SA_SIGINFO, sa_restorer=0x7f63b2821520}, NULL, 8) = 0
+rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
+ioctl(0, TCGETS, 0x7ffec62b8ec0)        = -1 ENOTTY (Inappropriate ioctl for device)
+ioctl(1, TCGETS, 0x7ffec62b8ec0)        = -1 ENOTTY (Inappropriate ioctl for device)
+ioctl(2, TCGETS, 0x7ffec62b8ec0)        = -1 ENOTTY (Inappropriate ioctl for device)
+getcwd("/home/thk/annex", 4096)         = 16
+stat("/home/thk/annex/.git/config", {st_mode=S_IFREG|0640, st_size=958, ...}) = 0
+pipe([11, 12])                          = 0
+pipe([13, 14])                          = 0
+rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
+vfork()                                 = 144638
+close(12)                               = 0
+fcntl(11, F_SETFD, FD_CLOEXEC)          = 0
+close(14)                               = 0
+fcntl(13, F_SETFD, FD_CLOEXEC)          = 0
+read(13, "", 4)                         = 0
+close(13)                               = 0
+rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
+fcntl(11, F_GETFL)                      = 0 (flags O_RDONLY)
+fcntl(11, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
+ioctl(11, TCGETS, 0x7ffec62b8ec0)       = -1 ENOTTY (Inappropriate ioctl for device)
+read(11, 0x42001de010, 8192)            = -1 EAGAIN (Resource temporarily unavailable)
+epoll_ctl(4, EPOLL_CTL_MOD, 11, {EPOLLIN|EPOLLONESHOT, {u32=11, u64=11}}) = -1 ENOENT (No such file or directory)
+epoll_ctl(4, EPOLL_CTL_ADD, 11, {EPOLLIN|EPOLLONESHOT, {u32=11, u64=11}}) = 0
+futex(0x4f636fc, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
+futex(0x4f63700, FUTEX_WAKE_PRIVATE, 1) = 0
+read(11, "include.path\n/usr/share/git-core"..., 8192) = 4547
+read(11, "", 8192)                      = 0
+close(11)                               = 0
+futex(0x4f6381c, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x4f63820, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x3eea308, FUTEX_WAKE_PRIVATE, 1) = 1
+wait4(144638, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 144638
+getcwd("/home/thk/annex", 4096)         = 16
+stat(".git", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0
+dup(0)                                  = 11
+ioctl(11, TCGETS, 0x7ffec62b8ec0)       = -1 ENOTTY (Inappropriate ioctl for device)
+dup(1)                                  = 12
+ioctl(12, TCGETS, 0x7ffec62b8ec0)       = -1 ENOTTY (Inappropriate ioctl for device)
+openat(AT_FDCWD, "/dev/null", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 13
+fstat(13, {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x3), ...}) = 0
+ioctl(13, TCGETS, 0x7ffec62b8ec0)       = -1 ENOTTY (Inappropriate ioctl for device)
+close(0)                                = 0
+dup2(13, 0)                             = 0
+ioctl(0, TCGETS, 0x7ffec62b8ec0)        = -1 ENOTTY (Inappropriate ioctl for device)
+close(1)                                = 0
+dup2(2, 1)                              = 1
+ioctl(1, TCGETS, 0x7ffec62b8ec0)        = -1 ENOTTY (Inappropriate ioctl for device)
+futex(0x7f63a4000be8, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x7f63a4000bf0, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x3eea308, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x4f636f8, FUTEX_WAIT_PRIVATE, 0, NULL
+strace[144630]: futex(0x4f636f8, FUTEX_WAIT_PRIVATE, 0, NULL
+strace[144630]: 2020-03-11 20:32:43.838670
+2020-03-11 20:32:43.838670
+ = 0
+futex(0x4f63) = 0
+futex(0x7f63a4000bec, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x7f63a4000bf0, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x3eea308, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x4f636fc, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
+futex(0x4f63700, FUTEX_WAKE_PRIVATE, 1) = 0
+wait4(-1, 0x42000abc68, WNOHANG|WSTOPPED, NULL) = 0
+clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=15617173}) = 0
+write(9, "\376", 1)                     = 1
+write(6, "\376", 1)                     = 1
+openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 4
+read(4, "0-7\n", 8192)                  = 4
+close(4)                                = 0
+rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
+clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=15818971}) = 0
+rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
+futex(0x4f63818, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x4f63820, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x3eea308, FUTEX_WAKE_PRIVATE, 1) = 1
+sched_yield()                           = 0
+futex(0x7f63b22449d0, FUTEX_WAIT, 144633, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=144642, si_uid=350977, si_status=SIGPIPE, si_utime=0, si_stime=0} ---
+futex(0x7f63b22449d0, FUTEX_WAIT, 144633, NULL) = 0
+munmap(0x7f63b0241000, 8392704)         = 0
+rt_sigprocmask(SIG_BLOCK, [TTOU], [], 8) = 0
+rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
+rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, NULL, 8) = 0
+rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, NULL, 8) = 0
+rt_sigaction(SIGTSTP, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, NULL, 8) = 0
+clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=16548690}) = 0
+exit_group(0)                           = ?
++++ exited with 0 +++
+systemd[1644]: annex-remotedaemon.service: Succeeded.
+```
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 8.20200227-gf56dfe791 on Debian testing
+
+### 2020-03-14 Update
+
+I added some log statements and found out that in module **RemoteDaemon.Core** in function **runInteractive** the expression
+
+    reader `concurrently` writer `concurrently` controller
+
+exits with an exception saying
+
+    <stdin>: hGetLine: end of file
+
+### 2020-03-14 Update with workaround
+
+So **man systemd.exec** says in section **StandardInput=**:
+
+> If null is selected, standard input will be connected to /dev/null, i.e. all read attempts by the process will result in immediate EOF.
+
+and
+
+> This setting defaults to null.
+
+My current workaround is this ExecStart line in my systemd service definition:
+
+    ExecStart=/bin/sh -c 'sleep infinity | git-annex remotedaemon --verbose --debug --foreground'
+
diff --git a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_1_8573d3bb5ae9f3490265767128027ed1._comment b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_1_8573d3bb5ae9f3490265767128027ed1._comment
new file mode 100644
index 0000000000..25d398f514
--- /dev/null
+++ b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_1_8573d3bb5ae9f3490265767128027ed1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-14T19:47:45Z"
+ content="""
+remotedaemon --foreground speaks a line-based API over stdio.
+So it does not make sense to use it the way you're using it.
+
+It may be that --foreground should be renamed to something else, and a new
+--foreground option added that just runs the daemon in its usual mode w/o
+backgrounding. I think only the assistant uses --foreground, although it is
+a documented option and there's always the possibility someone has found a
+use for it.
+"""]]
diff --git a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_2_34fa48bba13bf896e6b3809ec22fc58e._comment b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_2_34fa48bba13bf896e6b3809ec22fc58e._comment
new file mode 100644
index 0000000000..5efe2585ad
--- /dev/null
+++ b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_2_34fa48bba13bf896e6b3809ec22fc58e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="thk"
+ avatar="http://cdn.libravatar.org/avatar/bfef10a428769701aeee1db978951461"
+ subject="Tor remote does not use stdin"
+ date="2020-03-15T09:35:18Z"
+ content="""
+Hi Joey,
+
+I use the remotedaemon only for tor remotes and it works the way I documented above. So it does not need stdin and stdout at all?
+"""]]
diff --git a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_3_9b3040c521ec1992ec03c06a579dd627._comment b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_3_9b3040c521ec1992ec03c06a579dd627._comment
new file mode 100644
index 0000000000..cbafe31281
--- /dev/null
+++ b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_3_9b3040c521ec1992ec03c06a579dd627._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-05-05T16:40:36Z"
+ content="""
+As I said, the purpose of the --foreground option is to enable a line-based
+protocol using stdin. The assistant uses that. Other things could too, I
+don't know. It's a documented interface.
+
+Yes, if you run the remotedaemon for tor, you typically don't pass that
+option, and so it does not use stdin. But an option to run in the foreground
+like that would need to be a different option than the already existing,
+documented, and used --foreground option.
+
+So, this is not a bug report, it's a feature request.
+"""]]
diff --git a/doc/bugs/git-annex_sometimes_messes_up___126____47__.git-credentials.mdwn b/doc/bugs/git-annex_sometimes_messes_up___126____47__.git-credentials.mdwn
new file mode 100644
index 0000000000..819fff495d
--- /dev/null
+++ b/doc/bugs/git-annex_sometimes_messes_up___126____47__.git-credentials.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+
+My ~/.git-credentials file has several lines like this
+
+    https://xxx:yyy@api-zzz.falsifian.sandcats.io
+
+which git uses to access some remotes at falsifian.sandcats.io over https, including remotes for some git-annex repositories. (The use of https is due to technical limitation in the Sandstorm software that is hosting the git repositories.)
+
+Ocasionally, running a git-annex command will cause one of those lines to disappear, which breaks my access to all the git remotes under the corresponding hostname (git starts asking for a password).
+
+I think the command that most recently caused it is `git annex sync sandstorm`; `sandstorm` is the name of one of those remotes. In fact, maybe that's the only command that causes this behaviour; I'm not sure. It only happens once in a while.
+
+Even when git-annex doesn't _delete_ one of those lines, I still sometimes see the lines get re-ordered, so `~/.git-credentials` is being edited for some reason unknown to me.
+
+I have this in ~/.gitconfig:
+
+    [credential]
+	    helper = store
+
+### What steps will reproduce the problem?
+
+I haven't been able to reproduce it consistently. My best guess is it occasionally happens when I run `git annex sync sandstorm` where "sandstorm" is a remote depending on some line in `~/.git-credentials`.
+
+If someone could give me a clue about why `git annex sync` would result in `~/.git-credentials` being edited, that might help me dig deeper.
+
+### What version of git-annex are you using? On what operating system?
+
+Most recently observed with git-annex 8.20201116 on NixOS. I think I've also seen it on OpenBSD with git-annex 8.20200815-g55c156a53 (built from source).
+
+### Please provide any additional information below.
+
+I don't have a transcript that would illustrate the problem, but the behaviour is visible as a git prompt appearing (graphical or on CLI) asking me for a password to log into the git remote.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+It works beautifully, other than occasionally clobbering `~/.git-credentials` :-)
+
+> [[done]] as this is apparently not a git-annex bug and the submitter
+> never followed up with any info about what caused it. --[[Joey]]
diff --git a/doc/bugs/git-annex_sometimes_messes_up___126____47__.git-credentials/comment_1_5fafcc62656bdec4eecdf35cee4c6a8f._comment b/doc/bugs/git-annex_sometimes_messes_up___126____47__.git-credentials/comment_1_5fafcc62656bdec4eecdf35cee4c6a8f._comment
new file mode 100644
index 0000000000..8902c9de9b
--- /dev/null
+++ b/doc/bugs/git-annex_sometimes_messes_up___126____47__.git-credentials/comment_1_5fafcc62656bdec4eecdf35cee4c6a8f._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-12-01T16:28:36Z"
+ content="""
+git-annex does not contain the name of this file in its source code.
+
+In a few places git-annex uses `git credential` to ask for a credential.
+Only in the git-lfs special remote does it ever `git credential reject` if
+the provided credential does not work, which would remove it. Since you are
+apparently not using that special remote, it does not seem relevant, but
+also when git-annex does that, it's using it correctly to reject a
+non-working credential.
+
+It may be that git-annex ought to be calling `git credential approve` after
+it's used the credential. It seems possible git might in some situation or
+configuration choose to delete a credential that has not been recently
+approved. The docs are not very clear about this, but I have not been able
+to reproduce it behaving that way in some tests.
+
+Or this deletion could be a git bug, or git could be sometimes seeing the
+credential not work, for whatever reason, and so removing it.
+"""]]
diff --git a/doc/bugs/git-annex_sometimes_messes_up___126____47__.git-credentials/comment_2_f8435628336b472107b478fe11628186._comment b/doc/bugs/git-annex_sometimes_messes_up___126____47__.git-credentials/comment_2_f8435628336b472107b478fe11628186._comment
new file mode 100644
index 0000000000..98c4a25b50
--- /dev/null
+++ b/doc/bugs/git-annex_sometimes_messes_up___126____47__.git-credentials/comment_2_f8435628336b472107b478fe11628186._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="falsifian"
+ avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae"
+ subject="comment 2"
+ date="2020-12-02T16:52:10Z"
+ content="""
+Thanks for the info. So I guess some combination of `git credential fill` and `git credential approve` is causing this. If I have more time I'll fiddle with those commands.
+"""]]
diff --git a/doc/bugs/git-annex_stack.yml_misses_extra-deps..mdwn b/doc/bugs/git-annex_stack.yml_misses_extra-deps..mdwn
new file mode 100644
index 0000000000..56674eeeab
--- /dev/null
+++ b/doc/bugs/git-annex_stack.yml_misses_extra-deps..mdwn
@@ -0,0 +1,92 @@
+### Please describe the problem.
+
+extra-deps in stack.yaml seems to miss a few packages? I am pretty new to stack, so maybe
+I am misinterpreting, but following stacks suggestion below and adding 
+
+- bloomfilter-2.0.1.0
+- network-multicast-0.2.0
+- torrent-10000.0.1
+
+to my stack.yaml lets me build the latest master branch on jessie.
+
+### What steps will reproduce the problem?
+
+Checking out the latest commit (661dae3649f10a07ba6091a9a376ae1049fed716) and running "stack setup && stack install"
+should reproduce it? See transcript below.
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170101-android on Debian Jessie. Stack Version 1.3.2
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+$ git clone git://git-annex.branchable.com/ git-annex                                                                                                                                
+Cloning into 'git-annex'...
+remote: Counting objects: 178001, done.
+remote: Compressing objects: 100% (49612/49612), done.
+remote: Total 178001 (delta 127721), reused 178001 (delta 127721)
+Receiving objects: 100% (178001/178001), 43.14 MiB | 1.47 MiB/s, done.
+Resolving deltas: 100% (127721/127721), done.
+Checking connectivity... done.
+$ cd git-annex
+$ stack setup
+Downloaded lts-7.18 build plan.    
+Fetching package index ...remote: Counting objects: 1887, done.
+remote: Compressing objects: 100% (164/164), done.
+remote: Total 1887 (delta 676), reused 641 (delta 641), pack-reused 1079
+Receiving objects: 100% (1887/1887), 1.59 MiB | 904.00 KiB/s, done.
+Resolving deltas: 100% (757/757), completed with 311 local objects.
+From https://github.com/commercialhaskell/all-cabal-hashes
+   3ae7c75..ca0bc8e  hackage    -> origin/hackage
+ - [tag update]      current-hackage -> current-hackage
+Fetched package index.    
+Populated index cache.    
+stack will use a sandboxed GHC it installed
+For more information on paths, see 'stack path' and 'stack exec env'
+To use this GHC and packages outside of a project, consider using:
+stack ghc, stack ghci, stack runghc, or stack exec
+$ stack install
+Cabal file warning in /home/phaer/projects/external/git-annex/git-annex.cabal: Ignoring unknown section type: custom-setup
+
+Error: While constructing the build plan, the following exceptions were encountered:
+
+In the dependencies for git-annex-6.20170101(-android
+-androidsplice
++assistant
++concurrentoutput
++cryptonite
+-dbus
+-magicmime
++network-uri
++pairing
++production
++s3
++testsuite
++torrentparser
++webapp
++webdav):
+    bloomfilter must match -any, but the stack configuration has no specified version (latest applicable is 2.0.1.0)
+    network-multicast must match -any, but the stack configuration has no specified version (latest applicable is 0.2.0)
+    torrent must match (>=10000.0.0), but the stack configuration has no specified version
+            (latest applicable is 10000.0.1)
+
+Recommended action: try adding the following to your extra-deps in /home/phaer/projects/external/git-annex/stack.yaml:
+- bloomfilter-2.0.1.0
+- network-multicast-0.2.0
+- torrent-10000.0.1
+
+You may also want to try the 'stack solver' command
+Plan construction failed.
+
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, I am using it since a few years to manage my videos, photos and music. Thanks so much for this outstanding piece of software!
+
+> Seems that, since I have those packages globally installed, stack solver 
+> did not notice that they needed to be listed there. Hrm. Ok well, added
+> them by hand. [[done]] --[[Joey]] 
diff --git a/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup.mdwn b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup.mdwn
new file mode 100644
index 0000000000..69383666c2
--- /dev/null
+++ b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup.mdwn
@@ -0,0 +1,49 @@
+Hi.
+
+trying to manage my collection of digital music files using git-annex. The collection (113 gigs of flac files ripped from my CDs) should be stored on my three different machines and updated on all of them, if I add or change a file on only one of the machines.
+
+### Please describe the problem.
+
+Added a new external USB disk for sneaker transfer via web app, yesterday.
+
+Now for no apparent reason, after startup/login, git-annex would start and quickly suck up all available RAM. This is on a fairly well equipped machine (16G physical RAM, i5-2400), yet "top" tells me that there is one git process that sucks up more than 20G and climbing. It looked like this:
+
+    git --git-dir=/home/user/Sync/Audio/.git --work-tree=/home/user/Sync/Audio -c core.bare=false log refs/heads git-annex..13d365f16ffdb5a393f66362b840d3f21bb4c59c --oneline -n1
+
+The computer then slows down, grinds to halt, becomes unresponsive and it's difficult to even login on the console.
+
+Then, the OOM killer kicks in and kicks the git process, but git-annex quickly starts another which does the same.
+
+### What steps will reproduce the problem?
+
+I don't know what caused it. The symptoms remained after a reboot, "git annex watch --stop" didn't help either, since I'm a dumb web app user, I'm not sure if that's the right command to use anyway.
+
+For now, I have removed git-annex from the system.
+
+### What version of git-annex are you using? On what operating system?
+
+Last installed version: git-annex 5.20140127.1 on Ubuntu 13.10, amd64.
+
+### Please provide any additional information below.
+
+I'm fairly unsure where to look for the cause and what logs to provide you with to help fix this. Just guessing that it could be a symptom, but the daemon.log is full of entries like this:
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+("race detected",ca2cbdb84bcbd4aab895284b16fc72f693fbba90,[4a2e7c1d7d286a4da9e816b20368ce2f9b4177c4],"committing",(ca2cbdb84bcbd4aab895284b16fc72f693fbba90,[ca2cbdb84bcbd4aab895284b16fc72f693fbba90]))
+(Recording state in git...)
+("race detected",28c835634e65ced0e532c1a0e4f34dd0344193bc,[19597be0f49fb859fafa51e006459d5a95e3d005],"committing",(28c835634e65ced0e532c1a0e4f34dd0344193bc,[28c835634e65ced0e532c1a0e4f34dd0344193bc]))
+(Recording state in git...)
+("race detected",1f2b06c7001be38bd9595eb2205c91454597edaa,[398660279436246a698d6bd55eb06998999ed64f],"committing",(1f2b06c7001be38bd9595eb2205c91454597edaa,[1f2b06c7001be38bd9595eb2205c91454597edaa]))
+(Recording state in git...)
+("race detected",4c1510c3db41ff400526d5753c03bddc48f5c37e,[1989177cf24ec9151058ed99f05117e48c239001],"committing",(4c1510c3db41ff400526d5753c03bddc48f5c37e,[4c1510c3db41ff400526d5753c03bddc48f5c37e]))
+(Recording state in git...)
+("race detected",b82f41fcbf24c43fe9f1f9d6fb54ba5ef9ff8de0,[799e4434447b18be63bd097120e1fbf56eac48ce],"committing",(b82f41fcbf24c43fe9f1f9d6fb54ba5ef9ff8de0,[b82f41fcbf24c43fe9f1f9d6fb54ba5ef9ff8de0]))
+(Recording state in git...)
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_1_b550f292359b44977481bf69abad4012._comment b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_1_b550f292359b44977481bf69abad4012._comment
new file mode 100644
index 0000000000..662141d64a
--- /dev/null
+++ b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_1_b550f292359b44977481bf69abad4012._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkVnM7Ol2kr_jfLg6h_oXpmNdxWHIiL9mk"
+ nickname="Hanno"
+ subject="comment 1"
+ date="2014-01-30T11:18:15Z"
+ content="""
+In case it helps:
+
+    $ grep \"race detected\" daemon.log.5 | wc -l
+    234986
+
+
+
+"""]]
diff --git a/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_2_76e6c1d4db27bcc1767ba34e13e8211c._comment b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_2_76e6c1d4db27bcc1767ba34e13e8211c._comment
new file mode 100644
index 0000000000..dacaac9421
--- /dev/null
+++ b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_2_76e6c1d4db27bcc1767ba34e13e8211c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.199"
+ subject="comment 2"
+ date="2014-01-30T17:39:47Z"
+ content="""
+How many files are in the repository?
+"""]]
diff --git a/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_3_14007c8e927b75c5706e80cc4242fae4._comment b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_3_14007c8e927b75c5706e80cc4242fae4._comment
new file mode 100644
index 0000000000..90101155d5
--- /dev/null
+++ b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_3_14007c8e927b75c5706e80cc4242fae4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Hanno"
+ ip="85.183.3.94"
+ subject="comment 3"
+ date="2014-01-31T10:39:47Z"
+ content="""
+The folder contains a bit more than 15000 files (counted with find -type f)
+"""]]
diff --git a/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_4_f3266b74517b421e5310e67818fe3969._comment b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_4_f3266b74517b421e5310e67818fe3969._comment
new file mode 100644
index 0000000000..faaa7ed09a
--- /dev/null
+++ b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_4_f3266b74517b421e5310e67818fe3969._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkVnM7Ol2kr_jfLg6h_oXpmNdxWHIiL9mk"
+ nickname="Hanno"
+ subject="comment 4"
+ date="2014-01-31T23:17:49Z"
+ content="""
+I have no idea if it is related to this problem, but allow me to add that the \"Consistency check\" (that the web app specifically recommended me to activate) makes my computers unreasonably slow immediately after each bootup. This is both at the fairly fast computer at the office and the ok-ish old laptop at home.
+
+Also, the check will kick in and suck up the systems responsiveness right after connecting the external USB sneaker disk, making any regular file transfer to the disk extremely slow (more than once I was stung because I just wanted to quickly move a bigger file to the disk and walk home at the end of an office day but git-annex would go into its check after mounting).
+
+Thanks!
+"""]]
diff --git a/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_5_1a07f15eb0353768c1e67a1e47e2e494._comment b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_5_1a07f15eb0353768c1e67a1e47e2e494._comment
new file mode 100644
index 0000000000..d94eda8168
--- /dev/null
+++ b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_5_1a07f15eb0353768c1e67a1e47e2e494._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Hanno"
+ ip="85.183.3.94"
+ subject="comment 5"
+ date="2014-02-27T16:10:54Z"
+ content="""
+Is there anything I can do to help making progress on this issue?
+Right now I'm afraid to reinstall git-annex on this machine.
+"""]]
diff --git a/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_6_7d0d49fd165af5e30606982e05335d34._comment b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_6_7d0d49fd165af5e30606982e05335d34._comment
new file mode 100644
index 0000000000..bd6fcad6ab
--- /dev/null
+++ b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_6_7d0d49fd165af5e30606982e05335d34._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 6"
+ date="2014-03-10T19:24:45Z"
+ content="""
+I suppose it would be useful to look at the output of `git log git-annex..13d365f16ffdb5a393f66362b840d3f21bb4c59c --oneline -n1`
+
+Either than command is outputting a huge amount of stuff, or it's actually causing git (not git-annex) to use a lot of memory. Not sure which it is from the description.
+"""]]
diff --git a/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_7_2b0ba2a15af04731a966a029be9b81aa._comment b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_7_2b0ba2a15af04731a966a029be9b81aa._comment
new file mode 100644
index 0000000000..39e0e44e9e
--- /dev/null
+++ b/doc/bugs/git-annex_sucking_up_all_available_RAM_after_startup/comment_7_2b0ba2a15af04731a966a029be9b81aa._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="comment 7"
+ date="2017-07-20T06:16:46Z"
+ content="""
+Hello.
+
+Any progress on this? (With regular git annex I now have a big repository with some corruption and `git annex repair` causes oom-kill.)
+"""]]
diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS.mdwn b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS.mdwn
new file mode 100644
index 0000000000..abda583809
--- /dev/null
+++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS.mdwn
@@ -0,0 +1,58 @@
+### Please describe the problem.
+
+I'm trying to get git-annex running on a WD MyCloud EX2 NAS.
+
+There are a number of issues, I imagine to overcome, a few of which I've already managed to overcome.
+
+
+### What steps will reproduce the problem?
+
+I've managed to get it to work as special remote via rsync. But, it's nowhere near ideal. I was hoping to get working properly by installing git-annex locally on the machine.
+
+FYI, git 2.6.1 is already installed on the NAS.
+
+I can ssh into the NAS no problem. Only user sshd is allowed to ssh, but that's ok. Furthermore, the which command is missing, which prevented webapp lunched on my Mac from creating an rsync remote. Overcame that hurdle by "faking" it:
+[[!format sh """
+    > echo \#\!\/bin\/sh > /usr/bin/which
+    > echo command \-v \$\@ >> /usr/bin/which
+    > chmod +x /usr/bin/which
+"""]]
+
+I've downloaded the latest arm build. After untaring and running runshell successfully, I can't get through the next step, which is running git annex. It results in the following error:
+[[!format sh """
+    > git annex
+    /mnt/HD/HD_a2/git-annex/shimmed/git-annex/git-annex: error while loading shared libraries: /mnt/HD/HD_a2/git-annex/shimmed/git-annex/git-annex: ELF load command alignment not page-aligned
+    fatal: 'annex' appears to be a git command, but we were not able to execute it. Maybe git-annex is broken?
+"""]]
+
+same goes for
+[[!format sh """
+    > runshell git-annex-shell -c git annex:
+    /mnt/HD/HD_a2/Nas_Prog/git-annex/shimmed/git-annex-shell/git-annex-shell: error while loading shared libraries: /mnt/HD/HD_a2/Nas_Prog/git-annex/shimmed/git-annex-shell/git-annex-shell: ELF load command alignment not page-aligned
+"""]]
+
+and pretty much any of the git-annex binaries.
+
+Compiling from source is not an option.
+Any ideas? Thanks.
+
+### What version of git-annex are you using? On what operating system?
+
+I'm trying the latest version of git-annex-standalone-armel.tar.gz downloaded 2015-10-10.
+
+uname -a:  Linux WDMyCloudEX2 3.2.40 #4 Fri Jul 31 16:04:18 CST 2015 armv7l GNU/Linux
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sure, runs on my Mac laptop
diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_1_b87b50ca08bf90ecb7d741a6baa1dc4d._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_1_b87b50ca08bf90ecb7d741a6baa1dc4d._comment
new file mode 100644
index 0000000000..00f2c08060
--- /dev/null
+++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_1_b87b50ca08bf90ecb7d741a6baa1dc4d._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-10-15T17:04:07Z"
+ content="""
+I wonder if this ELF issue extends to other binaries included in the
+git-annex bundle, or does it only affect the git-annex (and
+git-annex-shell) binary?
+
+It looks like git is working when used inside runshell, and that is using a
+git binary from the git-annex bundle.
+
+If so, it could have something to do with how the haskell binary is being
+linked. I found this thread about fixing this problem in the gold linker:
+<https://sourceware.org/ml/binutils/2012-08/msg00486.html>. IIRC
+the arm build is currently using the bfd linker, not gold.
+"""]]
diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_2_6c95d0fd70fbf41eea4e6575486af3f5._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_2_6c95d0fd70fbf41eea4e6575486af3f5._comment
new file mode 100644
index 0000000000..a161f6da71
--- /dev/null
+++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_2_6c95d0fd70fbf41eea4e6575486af3f5._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="PaulK"
+ subject="comment 2"
+ date="2015-10-16T01:32:37Z"
+ content="""
+Yup. It seems to affect mainly git-annex binaries...
+
+[[!format  sh \"\"\"
+
+# ./git-annex
+/mnt/HD/git-annex/shimmed/git-annex/git-annex: error while loading shared libraries: /mnt/HD/git-annex/shimmed/git-annex/git-annex: ELF load command alignment not page-aligned
+
+# ./git-annex-shell 
+/mnt/HD/git-annex/shimmed/git-annex-shell/git-annex-shell: error while loading shared libraries: /mnt/HD/git-annex/shimmed/git-annex-shell/git-annex-shell: ELF load command alignment not page-aligned
+
+# ./git-annex-webapp 
+/mnt/HD/git-annex/shimmed/git-annex/git-annex: error while loading shared libraries: /mnt/HD/git-annex/shimmed/git-annex/git-annex: ELF load command alignment not page-aligned
+
+# ./git-shell
+fatal: Interactive git shell is not enabled.
+hint: ~/git-shell-commands should exist and have read and execute access.
+
+# ./git-upload-pack
+usage: git upload-pack [--strict] [--timeout=<n>] <dir>
+
+# ./shimmed/wget/wget
+./shimmed/wget/wget: error while loading shared libraries: libpcre.so.3: cannot open shared object file: No such file or directory
+
+# ./runshell which wget
+/mnt/HD/git-annex/bin/wget
+
+# ./runshell wget
+wget: missing URL
+Usage: wget [OPTION]... [URL]...
+
+Try `wget --help' for more options.
+
+# ./runshell which git 
+/mnt/HD/git-annex/bin/git
+
+# ./runshell git annex
+/mnt/HD/git-annex/shimmed/git-annex/git-annex: error while loading shared libraries: /mnt/HD/git-annex/shimmed/git-annex/git-annex: ELF load command alignment not page-aligned
+fatal: 'annex' appears to be a git command, but we were not
+able to execute it. Maybe git-annex is broken?
+
+\"\"\"]]
+
+"""]]
diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_3_6dd54179aad379bb22638db518bd377f._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_3_6dd54179aad379bb22638db518bd377f._comment
new file mode 100644
index 0000000000..73eea64896
--- /dev/null
+++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_3_6dd54179aad379bb22638db518bd377f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="sts"
+ subject="comment 3"
+ date="2016-06-23T12:07:10Z"
+ content="""
+Is there a way to link the objects with the gold linker? I am running into the same issue. Currently I am doing a workaround with mounting the drive via NFS, but that has quite poor performance (all git-related things).
+"""]]
diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_4_614da8cad46df5c71539cc5a8ed11831._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_4_614da8cad46df5c71539cc5a8ed11831._comment
new file mode 100644
index 0000000000..6481abb733
--- /dev/null
+++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_4_614da8cad46df5c71539cc5a8ed11831._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="PaulK"
+ subject="comment 4"
+ date="2016-09-19T04:39:07Z"
+ content="""
+So, does anyone out there have access to this gold linker, and could they please try to link it for the armv7l architecture?
+Thanks.
+"""]]
diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_5_5fa9d10ebd639eb1a836866b99e90aab._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_5_5fa9d10ebd639eb1a836866b99e90aab._comment
new file mode 100644
index 0000000000..a4784ced58
--- /dev/null
+++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_5_5fa9d10ebd639eb1a836866b99e90aab._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-09-21T16:44:08Z"
+ content="""
+I've updated the [arm daily build](https://downloads.kitenet.net/git-annex/autobuild/armel/git-annex-standalone-armel.tar.gz) to use ld.gold temporarily. 
+
+Please give it a try and report back if it works and if so I'll
+make the change permanant.
+"""]]
diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_6_8e05f8769870b3f1aec77fca06f37284._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_6_8e05f8769870b3f1aec77fca06f37284._comment
new file mode 100644
index 0000000000..d56e90c83a
--- /dev/null
+++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_6_8e05f8769870b3f1aec77fca06f37284._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="PaulK"
+ subject="comment 6"
+ date="2016-09-24T04:16:51Z"
+ content="""
+Nope, no difference. Same \"ELF load command alignment not page-aligned\" errors as before.
+"""]]
diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment
new file mode 100644
index 0000000000..05fe1010a8
--- /dev/null
+++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="PaulK"
+ subject="comment 7"
+ date="2016-09-25T03:08:40Z"
+ content="""
+As an aside, just tried syncthing's arm verion, and I get a \"runtime: kernel page size (32768) is larger than runtime page size (4096)\" error. While their arm64 version also won't run.  
+
+Perhaps it's a similar issue with git-annex? Seems the page-size comes up in a number of contexts of people trying to get software running on the WD NAS.
+
+Is there any way to adjust  this page-size in the linker?
+
+Thanks
+"""]]
diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_8_48026cf7c187e97d53d15d35ed2c3670._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_8_48026cf7c187e97d53d15d35ed2c3670._comment
new file mode 100644
index 0000000000..493031115a
--- /dev/null
+++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_8_48026cf7c187e97d53d15d35ed2c3670._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2016-11-16T21:48:49Z"
+ content="""
+The arm daily build now uses a 32kb page size. So try
+<https://downloads.kitenet.net/git-annex/autobuild/armel/git-annex-standalone-armel.tar.gz>
+
+That has been verified to fix the problem on a Drobo 5N.
+
+This may still not be enough for some of the affected NAS devices, which
+use a 64kb page size. Unfortunately, gold fails to link with a 64kb page
+size: <http://bugs.debian.org/844467>
+"""]]
diff --git a/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory.mdwn b/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory.mdwn
new file mode 100644
index 0000000000..13ac5a98f6
--- /dev/null
+++ b/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory.mdwn
@@ -0,0 +1,43 @@
+### Please describe the problem.
+
+Adding my 43GB Music Studio folder with 85K files causes out of memory or file not found errors. I subsequently tried on a very small folder but it still fails. --debug gives nothing useful that I can see.
+
+
+### What steps will reproduce the problem?
+
+cd Studio
+git init
+git annex init
+git annex add
+
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 5.20140613-g5587055
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 2 3 4
+
+Running on Windows 8.1 x64, Git Bash, Direct Mode, WORM backend
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+fatal: Out of memory? mmap failed: No such file or directory
+git-annex: add: 8562 failed
+
+Phil@DESKTOP /c/Studio (annex/direct/master)
+$ git annex add audacity
+fatal: Out of memory? mmap failed: No such file or directory
+(Recording state in git...)
+
+
+# End of transcript or log.
+"""]]
+
+[[!meta title="msysgit failure on Windows: mmap failed: No such file or directory "]]
diff --git a/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_1_984f75d8078f2809486f38ecb3b16be3._comment b/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_1_984f75d8078f2809486f38ecb3b16be3._comment
new file mode 100644
index 0000000000..3662fe04fc
--- /dev/null
+++ b/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_1_984f75d8078f2809486f38ecb3b16be3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnOSgFb3l7nL3Fs7Y9gPGJJjFiV7aJ1tek"
+ nickname="Phil"
+ subject="comment 1"
+ date="2014-07-04T16:25:53Z"
+ content="""
+Looks like it might be related to msysGit:
+
+[bug on msysgit](http://osdir.com/ml/msysgit/2009-12/msg00007.html)
+"""]]
diff --git a/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_2_c0f07e2d4bb142389629050479dd1465._comment b/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_2_c0f07e2d4bb142389629050479dd1465._comment
new file mode 100644
index 0000000000..0601b0a7de
--- /dev/null
+++ b/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_2_c0f07e2d4bb142389629050479dd1465._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 2"
+ date="2014-07-04T17:58:10Z"
+ content="""
+If you run git-annex with the --debug flag, you can see the git command that is presumably what is failing. You could then probably run the same git command manually and see if it fails that way too.
+
+Does your git repository have a large pack file (in `.git/objects/pack`) as mentioned in the msysgit bug report?
+"""]]
diff --git a/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_3_7a58a884aaacedca9697b17cd5248214._comment b/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_3_7a58a884aaacedca9697b17cd5248214._comment
new file mode 100644
index 0000000000..c6aa8360a5
--- /dev/null
+++ b/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_3_7a58a884aaacedca9697b17cd5248214._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnOSgFb3l7nL3Fs7Y9gPGJJjFiV7aJ1tek"
+ nickname="Phil"
+ subject="comment 3"
+ date="2014-07-04T22:28:27Z"
+ content="""
+I thought it might be related to using WORM but I've just hit it again on the default backend.
+
+--debug just seems to fail on the folder I tried to add:
+
+[[!format sh \"\"\"
+
+git annex --debug add samples
+
+[2014-07-04 23:24:42 GMT Summer Time] read: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"ls-files\",\"--others\",\"--exclude-standard\",\"-z\",\"--\",\"samples\"]
+[2014-07-04 23:24:42 GMT Summer Time] chat: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
+add samples/cr_info.sh [2014-07-04 23:24:42 GMT Summer Time] chat: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.numcopies\",\"--\"]
+[2014-07-04 23:24:42 GMT Summer Time] chat: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"hash-object\",\"-t\",\"blob\",\"-w\",\"--stdin\",\"--no-filters\"]
+[2014-07-04 23:24:42 GMT Summer Time] chat: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
+ok
+[2014-07-04 23:24:42 GMT Summer Time] read: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"ls-files\",\"--modified\",\"-z\",\"--\",\"samples\"]
+fatal: Out of memory? mmap failed: No such file or directory
+(Recording state in git...)
+[2014-07-04 23:25:39 GMT Summer Time] feed: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+[2014-07-04 23:25:39 GMT Summer Time] chat: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2014-07-04 23:25:39 GMT Summer Time] feed: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+[2014-07-04 23:25:39 GMT Summer Time] read: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-04 23:25:39 GMT Summer Time] read: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"write-tree\"]
+[2014-07-04 23:25:39 GMT Summer Time] chat: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"commit-tree\",\"447be0c8a000f98e3c580c6dede7f0ba2208963d\",\"-p\",\"refs/heads/git-annex\"]
+[2014-07-04 23:25:39 GMT Summer Time] call: git [\"--git-dir=c:\\Studio\\.git\",\"--work-tree=c:\\Studio\",\"-c\",\"core.bare=false\",\"update-ref\",\"refs/heads/git-annex\",\"8551a4e2f5c4f42823f7da3169d1f630622359ef\"]
+
+\"\"\"]]
+"""]]
diff --git a/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_aa4f1806207138115d2a95935bb0546b._comment b/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_aa4f1806207138115d2a95935bb0546b._comment
new file mode 100644
index 0000000000..8e98152420
--- /dev/null
+++ b/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_aa4f1806207138115d2a95935bb0546b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnOSgFb3l7nL3Fs7Y9gPGJJjFiV7aJ1tek"
+ nickname="Phil"
+ subject="comment 4"
+ date="2014-07-04T22:30:45Z"
+ content="""
+There is no pack file, .git/objects/pack is empty. This is the first commit. I've queued up a load of files to commit, could this be it?
+"""]]
diff --git a/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_5_fa95f93416e3d6e66af557df6562f1e5._comment b/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_5_fa95f93416e3d6e66af557df6562f1e5._comment
new file mode 100644
index 0000000000..749ee44ad9
--- /dev/null
+++ b/doc/bugs/git_annex_add_out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_5_fa95f93416e3d6e66af557df6562f1e5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 5"
+ date="2014-07-10T19:59:15Z"
+ content="""
+For some reason, this bug is also being discussed in the forum. This makes it hard for me to keep up with what's going on, and generally is not a good idea. Currently, the forum currently seems to have better information. <http://git-annex.branchable.com/forum/fatal:_Out_of_memory__63___mmap_failed:_No_such_file_or_directory/>
+"""]]
diff --git a/doc/bugs/git_annex_assist_adds_gitignored_files.mdwn b/doc/bugs/git_annex_assist_adds_gitignored_files.mdwn
new file mode 100644
index 0000000000..30b1e4c213
--- /dev/null
+++ b/doc/bugs/git_annex_assist_adds_gitignored_files.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+
+The new `git annex assist` adds `.gitignore`ed files
+
+### What steps will reproduce the problem?
+
+```
+git init
+git annex init
+echo bla > .gitignore
+touch bla
+git annex assist
+git ls-files
+# bla  # 👈 shouldn't be here!
+# .gitignore
+```
+
+### What version of git-annex are you using? On what operating system?
+
+Manjaro Linux
+
+```
+❯ git annex version
+git-annex version: 10.20230408-g250194b7d
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git-annex is awesome!
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/git_annex_assistant_adds_dotfiles_to_the_annex.mdwn b/doc/bugs/git_annex_assistant_adds_dotfiles_to_the_annex.mdwn
new file mode 100644
index 0000000000..31a2d6ec67
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_adds_dotfiles_to_the_annex.mdwn
@@ -0,0 +1,35 @@
+### Please describe the problem.
+
+Running `git add` or `git annex add` does not add dotfiles to the annex. However, the git annex assistant appears to add dotfiles to the annex.
+
+### What steps will reproduce the problem?
+
+1. Initialize a new repository (`git init` and `git annex init`).
+
+2. Create a dotfile: `echo "foo" > .somedotfile`
+
+3. Run `git annex assistant`
+
+The file will then be added to the annex.
+
+### What version of git-annex are you using? On what operating system?
+
+Operating system: Arch Linux x86_64
+
+git-annex version: 10.20230329
+
+### Please provide any additional information below.
+
+[[!format sh """
+# Begin .git/annex/daemon.log
+
+  No known volume monitor available through dbus; falling back to mtab polling
+(scanning...) (started...) 
+add .somedotfile ok
+(recording state in git...)
+(recording state in git...)
+
+# End of transcript or log.
+"""]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/git_annex_assistant_exits_with_failure.mdwn b/doc/bugs/git_annex_assistant_exits_with_failure.mdwn
new file mode 100644
index 0000000000..934149eaa0
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_exits_with_failure.mdwn
@@ -0,0 +1,161 @@
+### Please describe the problem
+Git annex assistant on windows exits with a failure upon large sync. It has done so about 6 times while messing with it. (I've been seeing if it is a good solution for my photos or not before taking the leap.) I am syncing between windows 10 and debian servers using the backup group and assistant/webapp. Debian is quite out of date, so I first used stable, then upped it to jessie-backports. Jessie backports is still, however, major version 5, so I upped it to neuro debian's build to see if it needed to match version numbers. I haven't quite matched the date though, so don't know if that could be an issue. I have tried the webapp as well, and it goes down during this issue. I have also had failures on the linux side. The second to last run git annex was using 85% of my system memory and the load was 2.5. I had to kill git annex assistant and restart. The Windows git annex assistant just became unresponsive that time and I had to reboot the system to get it to sense any files again. These could be separate issues, but it involved the same data set.
+
+### What steps will reproduce the problem?
+Setup git annex with assistant on windows 10 as a client and debian 8 latest neurodebian build running assistant. Copy in a lightroom catalog with previews, smart previews, and photos. Mine amounted to about 39 GB, 22k files, and 17k folders
+### What version of git-annex are you using? On what operating system?
+client, windows 10 running git bash window: 
+
+git-annex version: 6.20161231-gc8eeb17
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV ConcurrentOutput TorrentParser Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 2 3 4 5
+operating system: mingw32 i386
+
+server Debian 8:
+
+git-annex version: 6.20170209+gitg16be7b5cc-1~ndall+1
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux x86_64
+
+### Please provide any additional information below.
+This is happens for both my large and smaller lightroom catalogs. I'm wondering if it is a peculiarity with how some of the files are formatted or the fact that it is a huge GUID for a file name. I can fairly consistently reproduce this issue on my setup, and I'm a software engineer (just don't know haskell yet.) So, I'm willing to do further debugging steps to help out.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+$ git annex assistant --debug
+[2017-02-12 15:10:11.3151425] logging to .git\annex\daemon.log
+[2017-02-12 15:10:11.3151425] chat: C:\Program Files (x86)\Git\usr\bin\git-annex.exe ["assistant","--debug"]
+[2017-02-12 15:25:00.1479375] process done ExitFailure (-1073741819)
+
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+I assume you don't want the entire log in here right? It is 40k lines. I searched for ExitFailure and found only 3 instances, but none of them were at the end of the log.
+
+[2017-02-12 15:10:29.0507794] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","show-ref","--verify","-q","refs/remotes/origin/annex/direct/master"]
+[2017-02-12 15:10:29.1132817] process done ExitFailure 1
+
+[2017-02-12 15:10:30.1769265] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","push","origin","git-annex","master"]
+[2017-02-12 15:10:30.5990043] process done ExitFailure 1
+
+Last error:
+[2017-02-12 15:20:07.8259699] Watcher: add .\LR Main\LR Main Previews.lrdata\6\6D0A\6D0A45BF-E2F7-4094-A3C5-C0659456A383-05daea287739b47c27cea4102e72ecd9.lrprev
+[2017-02-12 15:20:07.8259699] process done ExitFailure 1
+
+
+Here are the last 100 or so lines, let me know if you want more:
+add .\LR Main\LR Main Previews.lrdata\5\5E0E\5E0EACCF-16F7-4D95-A01F-BA17EA4BFA48-05daea287739b47c27cea4102e72ecd9.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5E05\5E05C2FD-107F-4CC8-8B22-375F0B09F43F-a1140a4f04c71f00fb85fd8ac71d471c.lrfprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5E05\5E05C2FD-107F-4CC8-8B22-375F0B09F43F-269826a76ee94c785b873f891dc7aa04.lrfprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5E05\5E05C2FD-107F-4CC8-8B22-375F0B09F43F-05daea287739b47c27cea4102e72ecd9.lrprev [2017-02-12 15:24:05.2466023] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5E05\\5E05C2FD-107F-4CC8-8B22-375F0B09F43F-05daea287739b47c27cea4102e72ecd9.lrprev"]
+[2017-02-12 15:24:05.293479] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5DF5\5DF55627-D6A1-4E4D-96F3-00BFFBE07DE3-1c47c3bee58f7f7ae5b0b166edb1df35.lrprev [2017-02-12 15:24:05.3091052] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5DF5\\5DF55627-D6A1-4E4D-96F3-00BFFBE07DE3-1c47c3bee58f7f7ae5b0b166edb1df35.lrprev"]
+[2017-02-12 15:24:05.355981] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5DB9\5DB91865-DCDD-4987-8FBE-126861B802FC-05daea287739b47c27cea4102e72ecd9.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5DB3\5DB317AF-CE90-4B37-A65A-E7394E0D8364-d28c9daea957f6c969fa48154e27ccfa.lrfprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5DB3\5DB317AF-CE90-4B37-A65A-E7394E0D8364-0dcfb6f1963162fa2616cf6950b64f23.lrfprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5DB3\5DB317AF-CE90-4B37-A65A-E7394E0D8364-05daea287739b47c27cea4102e72ecd9.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5DAF\5DAFD546-32A8-4087-9DA9-E0C13C2EDE0E-077b070982fd42045ed5e932196fb988.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5D9E\5D9E0F0C-082F-4A2B-AF9C-3A3288B3A2AE-91a29824ad0a349e888a7db35e28325f.lrfprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5D9E\5D9E0F0C-082F-4A2B-AF9C-3A3288B3A2AE-05daea287739b47c27cea4102e72ecd9.lrprev [2017-02-12 15:24:05.5123925] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5D9E\\5D9E0F0C-082F-4A2B-AF9C-3A3288B3A2AE-05daea287739b47c27cea4102e72ecd9.lrprev"]
+[2017-02-12 15:24:05.559269] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5D71\5D71BB4D-8322-47C0-B779-3542311E59DE-077b070982fd42045ed5e932196fb988.lrprev [2017-02-12 15:24:05.5748955] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5D71\\5D71BB4D-8322-47C0-B779-3542311E59DE-077b070982fd42045ed5e932196fb988.lrprev"]
+[2017-02-12 15:24:05.6217725] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5D6C\5D6C374E-FA1E-4526-A215-63B315BA82B2-9453b0b0faf115dd4cbf4a4ca3fd5ee7.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5D69\5D69C130-CDB9-4B67-8061-C0C0EF345D26-077b070982fd42045ed5e932196fb988.lrprev [2017-02-12 15:24:05.6842751] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5D69\\5D69C130-CDB9-4B67-8061-C0C0EF345D26-077b070982fd42045ed5e932196fb988.lrprev"]
+[2017-02-12 15:24:05.7155263] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5D47\5D479A01-2B69-4B85-AF2C-2CA2BF6BA66D-dfea411588b2a11b7e314d4691ee3d2f.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5D43\5D43DB0F-30D9-4071-B96C-25D2D82F6E40-05daea287739b47c27cea4102e72ecd9.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5D42\5D42D098-917E-46F6-AE24-2FB6242BE60D-05daea287739b47c27cea4102e72ecd9.lrprev [2017-02-12 15:24:05.7936545] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5D42\\5D42D098-917E-46F6-AE24-2FB6242BE60D-05daea287739b47c27cea4102e72ecd9.lrprev"]
+[2017-02-12 15:24:05.8092806] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5D3D\5D3DF631-9D24-446F-84F9-C858F398B23B-05daea287739b47c27cea4102e72ecd9.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5D36\5D3642E1-BBA6-4C0B-89B6-9451B375D47A-05daea287739b47c27cea4102e72ecd9.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5D29\5D29AB0B-E5A7-4930-BA0E-592675856EE8-b422a73fe8f4257d07ddd8c5d62692c9.lrfprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5D29\5D29AB0B-E5A7-4930-BA0E-592675856EE8-05daea287739b47c27cea4102e72ecd9.lrprev [2017-02-12 15:24:05.9066036] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5D29\\5D29AB0B-E5A7-4930-BA0E-592675856EE8-05daea287739b47c27cea4102e72ecd9.lrprev"]
+[2017-02-12 15:24:05.9509479] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5D21\5D21CA81-F662-4566-8E69-B7587441A60B-c55693145cbd7408f494d96dc6feac77.lrfprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5D21\5D21CA81-F662-4566-8E69-B7587441A60B-05daea287739b47c27cea4102e72ecd9.lrprev [2017-02-12 15:24:05.9978244] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5D21\\5D21CA81-F662-4566-8E69-B7587441A60B-05daea287739b47c27cea4102e72ecd9.lrprev"]
+[2017-02-12 15:24:06.0134498] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5D21\5D2174E4-5440-46C9-B852-0164DFB9912A-05daea287739b47c27cea4102e72ecd9.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5CF0\5CF09660-99B4-409F-8CF7-ADE34A6785B3-05daea287739b47c27cea4102e72ecd9.lrprev [2017-02-12 15:24:06.0603269] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5CF0\\5CF09660-99B4-409F-8CF7-ADE34A6785B3-05daea287739b47c27cea4102e72ecd9.lrprev"]
+[2017-02-12 15:24:06.1072033] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5CDA\5CDA3518-0AC4-4B77-9485-AC40246094C9-05daea287739b47c27cea4102e72ecd9.lrprev [2017-02-12 15:24:06.1228291] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5CDA\\5CDA3518-0AC4-4B77-9485-AC40246094C9-05daea287739b47c27cea4102e72ecd9.lrprev"]
+[2017-02-12 15:24:06.1384542] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5CCE\5CCE8E71-8668-45D7-9053-DBC59DBECEDA-05daea287739b47c27cea4102e72ecd9.lrprev [2017-02-12 15:24:06.1697055] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5CCE\\5CCE8E71-8668-45D7-9053-DBC59DBECEDA-05daea287739b47c27cea4102e72ecd9.lrprev"]
+[2017-02-12 15:24:06.2165819] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5CB2\5CB2A82E-E4E4-4999-B976-2650F63003D4-05daea287739b47c27cea4102e72ecd9.lrprev [2017-02-12 15:24:06.2322077] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5CB2\\5CB2A82E-E4E4-4999-B976-2650F63003D4-05daea287739b47c27cea4102e72ecd9.lrprev"]
+[2017-02-12 15:24:06.2790841] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5C8B\5C8BBE9D-4E0C-429E-BB54-0B39AA043ABA-05daea287739b47c27cea4102e72ecd9.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5C55\5C553361-7EF4-4B77-B568-FEAD5381CFCC-05daea287739b47c27cea4102e72ecd9.lrprev [2017-02-12 15:24:06.3103357] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5C55\\5C553361-7EF4-4B77-B568-FEAD5381CFCC-05daea287739b47c27cea4102e72ecd9.lrprev"]
+[2017-02-12 15:24:06.3415866] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5C2E\5C2EAB4B-3986-4038-855D-F9DB3A5EE390-05daea287739b47c27cea4102e72ecd9.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5C2D\5C2DE3F6-D523-4729-81E2-34DA2D66843D-05daea287739b47c27cea4102e72ecd9.lrprev [2017-02-12 15:24:06.3728379] read: sha256sum [".\\LR Main\\LR Main Previews.lrdata\\5\\5C2D\\5C2DE3F6-D523-4729-81E2-34DA2D66843D-05daea287739b47c27cea4102e72ecd9.lrprev"]
+[2017-02-12 15:24:06.4036538] process done ExitSuccess
+ok
+add .\LR Main\LR Main Previews.lrdata\5\5C21\5C21C472-7230-464F-ADFA-8F93D30280F1-05daea287739b47c27cea4102e72ecd9.lrprev ok
+add .\LR Main\LR Main Previews.lrdata\5\5C1C\5C1C2A2C-BFA9-42EA-A647-6F5138F5CEB4-077b070982fd42045ed5e932196fb988.lrprev ok
+[2017-02-12 15:24:06.449992] Committer: committing 5214 changes
+[2017-02-12 15:24:06.449992] Committer: Committing changes to git
+(recording state in git...)
+[2017-02-12 15:24:06.449992] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","update-index","-z","--index-info"]
+[2017-02-12 15:24:06.6687496] process done ExitSuccess
+[2017-02-12 15:24:06.6687496] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","symbolic-ref","-q","HEAD"]
+[2017-02-12 15:24:06.6843757] process done ExitSuccess
+[2017-02-12 15:24:06.6843757] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","show-ref","--hash","refs/heads/annex/direct/master"]
+[2017-02-12 15:24:06.7156263] process done ExitSuccess
+[2017-02-12 15:24:06.7156263] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","write-tree"]
+[2017-02-12 15:24:18.823257] process done ExitSuccess
+[2017-02-12 15:24:18.823257] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","rev-parse","e27617a27919a1942924c791c7963898b558f9c2:"]
+[2017-02-12 15:24:18.8388825] process done ExitSuccess
+[2017-02-12 15:24:18.8388825] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","commit-tree","c3f9659d704711122cfd83d3f4742635116ca96d","-p","e27617a27919a1942924c791c7963898b558f9c2"]
+[2017-02-12 15:24:19.0888926] process done ExitSuccess
+[2017-02-12 15:24:19.0888926] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","update-ref","refs/heads/annex/direct/master","8af641f066e30426a591bcf51a4244f127847431"]
+[2017-02-12 15:24:19.338833] process done ExitSuccess
+[2017-02-12 15:24:19.338833] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","symbolic-ref","-q","HEAD"]
+[2017-02-12 15:24:19.3700836] process done ExitSuccess
+[2017-02-12 15:24:19.3700836] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","show-ref","refs/heads/annex/direct/master"]
+[2017-02-12 15:24:19.3857092] process done ExitSuccess
+[2017-02-12 15:24:19.3857092] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","branch","-f","synced/master","refs/heads/annex/direct/master"]
+[2017-02-12 15:24:19.6400219] process done ExitSuccess
+[2017-02-12 15:24:19.6400219] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","branch","-f","master","refs/heads/annex/direct/master"]
+[2017-02-12 15:24:19.9025509] process done ExitSuccess
+[2017-02-12 15:24:19.9025509] Pusher: Syncing with origin 
+[2017-02-12 15:24:19.9025509] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","update-index","-z","--index-info"]
+[2017-02-12 15:24:34.1218776] process done ExitSuccess
+[2017-02-12 15:24:34.1218776] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","show-ref","--hash","refs/heads/git-annex"]
+[2017-02-12 15:24:34.1531288] process done ExitSuccess
+(recording state in git...)
+[2017-02-12 15:24:34.1531288] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","write-tree"]
+[2017-02-12 15:24:57.3948994] process done ExitSuccess
+[2017-02-12 15:24:57.3948994] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","commit-tree","df397eef838882ccb0cba9d6ceca056aad905520","-p","refs/heads/git-annex"]
+[2017-02-12 15:24:57.6449095] process done ExitSuccess
+[2017-02-12 15:24:57.6449095] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","update-ref","refs/heads/git-annex","14b3e08b23f938d901447b1b7fcbf020a8bc517c"]
+[2017-02-12 15:24:57.8960758] process done ExitSuccess
+[2017-02-12 15:25:00.0854341] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","symbolic-ref","-q","HEAD"]
+[2017-02-12 15:25:00.1010592] process done ExitSuccess
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I have had luck in manual mode using only linux. I only shied away from it, because I am chained to Windows in order to use some tools, e.g. lightroom, and it wasn't so nice there. Seeing support grow in Windows and the automatic features are amazing. It looks exactly like what I want, knowing where any of my files are at any given time and be able to setup more complicated transfer schemes to fit my needs exactly. Not to mention the ease of backing up over ssh to any of my linux boxes or offsite, etc. Oh and being able to checksum all of my photos and know they are all present and intact and being able to remove duplicate unorganized backups all over the place would be so great. I also need to work on a small subset on my macbook, so great solution for that as well.
+
diff --git a/doc/bugs/git_annex_assistant_exits_with_failure/comment_1_247d4da208cd700851d48f13534d5f7c._comment b/doc/bugs/git_annex_assistant_exits_with_failure/comment_1_247d4da208cd700851d48f13534d5f7c._comment
new file mode 100644
index 0000000000..f791798864
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_exits_with_failure/comment_1_247d4da208cd700851d48f13534d5f7c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-13T20:08:32Z"
+ content="""
+"ExitFailure (-1073741819)" looks kind of like an overflow of the exit
+status code, which is very strange.
+
+Is there an error message output anywhere when this happens?
+
+It looks like you might have a ton of files in this repository, and that
+might have something to do with the memory use and load.
+"""]]
diff --git a/doc/bugs/git_annex_assistant_exits_with_failure/comment_2_c6c04006b1d9aa6be92f5a970ba60618._comment b/doc/bugs/git_annex_assistant_exits_with_failure/comment_2_c6c04006b1d9aa6be92f5a970ba60618._comment
new file mode 100644
index 0000000000..987c928383
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_exits_with_failure/comment_2_c6c04006b1d9aa6be92f5a970ba60618._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="lasitus"
+ avatar="http://cdn.libravatar.org/avatar/dfe778f28027aeb75876172022aa5de3"
+ subject="comment 2"
+ date="2017-02-14T18:46:22Z"
+ content="""
+\"\"ExitFailure (-1073741819)\" looks kind of like an overflow of the exit status code, which is very strange.\"
+It isn't the only number I have received. I believe it was 5 on one run and 3 on another, but that is just from memory. I don't think the error was ever printed to the daemon.log. I can try and run it again and get more definite results.
+
+\"Is there an error message output anywhere when this happens?\"
+I gave you the end of daemon.log and everything that was printed after the crash. Any other logs you would like?
+
+\"It looks like you might have a ton of files in this repository, and that might have something to do with the memory use and load.\"
+After restarting and getting it going again, it was happily moving along with not much memory usage and 0.5 load. It seemed like both the client and the server were hung up on something that time. I had left it to chew on the files for quite some time. (That time the client didn't crash, but it stopped sensing any changes. Restarts of the assistant also didn't fix the issue, only a reboot on the Windows side.) I suppose I could have found whatever was running instead in task manager, but I'm saying a ctrl-c and apparent restart didn't help.
+"""]]
diff --git a/doc/bugs/git_annex_assistant_exits_with_failure/comment_3_eabad530a55adfa4be3eae0f743d3309._comment b/doc/bugs/git_annex_assistant_exits_with_failure/comment_3_eabad530a55adfa4be3eae0f743d3309._comment
new file mode 100644
index 0000000000..5cf9b66004
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_exits_with_failure/comment_3_eabad530a55adfa4be3eae0f743d3309._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-02-14T18:50:02Z"
+ content="""
+With a weird crash like this, I was thinking there might be an error message
+output to the console. I guess you showed the full console output though.
+
+Was the 85% of system memory happening on Windows or on Linux?
+
+I have no clues how to debug this. If there's useful information anywhere,
+it's probably in some windows crash log or system log thing that I know
+nothing about.
+"""]]
diff --git a/doc/bugs/git_annex_assistant_exits_with_failure/comment_4_204764bb40509d8650386227ea166a6e._comment b/doc/bugs/git_annex_assistant_exits_with_failure/comment_4_204764bb40509d8650386227ea166a6e._comment
new file mode 100644
index 0000000000..6aae58109a
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_exits_with_failure/comment_4_204764bb40509d8650386227ea166a6e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="lasitus"
+ avatar="http://cdn.libravatar.org/avatar/dfe778f28027aeb75876172022aa5de3"
+ subject="comment 4"
+ date="2017-02-14T19:08:38Z"
+ content="""
+The high memory use and load were on the Linux side.
+
+Again these were two different behaviors on separate runs. Most runs, the linux side was fine and the windows side crashed. This one I can reproduce easily by just copying my data into an empty repo. I'll try it a few times later tonight and see if it always happens on a particular file.
+
+One time, the windows side stopped sensing files and the Linux side had heavy cpu usage and high memory usage) Sadly, I don't recall the exact time as the hang up happened over night, so hard to find in the log file. So, I guess I will focus on the first one.
+"""]]
diff --git a/doc/bugs/git_annex_assistant_exits_with_failure/comment_5_0453ae9123b359757e63c6eb5f12811b._comment b/doc/bugs/git_annex_assistant_exits_with_failure/comment_5_0453ae9123b359757e63c6eb5f12811b._comment
new file mode 100644
index 0000000000..fe27fba426
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_exits_with_failure/comment_5_0453ae9123b359757e63c6eb5f12811b._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="lasitus"
+ avatar="http://cdn.libravatar.org/avatar/dfe778f28027aeb75876172022aa5de3"
+ subject="comment 5"
+ date="2017-02-15T02:17:25Z"
+ content="""
+Got a decent result this last run:
+
+Console output
+
+```
+[2017-02-14 20:40:25.3493472] logging to .git\annex\daemon.log
+[2017-02-14 20:40:25.3493472] chat: C:\Program Files (x86)\Git\usr\bin\git-annex.exe [\"assistant\",\"--debug\"]
+[2017-02-14 20:47:21.2931135] process done ExitFailure 1
+```
+
+daemon.log ending
+
+```
+[2017-02-14 20:47:17.4915947] process done ExitSuccess
+[2017-02-14 20:47:19.7279831] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2017-02-14 20:47:19.7436092] process done ExitSuccess
+[2017-02-14 20:47:19.7436092] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2017-02-14 20:47:19.7748596] process done ExitSuccess
+[2017-02-14 20:47:19.7748596] Pusher: pushing to [Remote { name =\"origin\" }]
+[2017-02-14 20:47:19.8217363] Committer: queued Upload UUID \"b77aaec0-e75b-4eec-a08c-b09cbe2947d5\" LR Main\LR Main Smart Previews.lrdata\1\117C\117C0B4F-1D99-4DF6-9E7B-7C0B655876D9.dng Nothing : new file created
+[2017-02-14 20:47:19.8529873] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"origin\",\"+git-annex:synced/git-annex\",\"annex/direct/master:synced/master\"]
+[2017-02-14 20:47:19.9154902] Transferrer: Transferring: Upload UUID \"b77aaec0-e75b-4eec-a08c-b09cbe2947d5\" LR Main\LR Main Smart Previews.lrdata\1\117C\117C0B4F-1D99-4DF6-9E7B-7C0B655876D9.dng Nothing
+[2017-02-14 20:47:19.9154902] Watcher: add LR Main\LR Main Smart Previews.lrdata\1\162B\162B90D0-CC7C-4BD9-AC2B-BA2D4C72B555.dng
+
+117C0B4F-1D99-4DF6-9E7B-7C0B655876D9.dng
+      1,792,000 100%  152.52MB/s    0:00:00 (xfr#1, to-chk=0/1)
+git-annex.exe: out of memory
+(recording state in git...)
+To storage.lan:/srv/annex/pictures
+   0623558..669c99c  git-annex -> synced/git-annex
+   6309934..b8e043d  annex/direct/master -> synced/master
+
+```
+"""]]
diff --git a/doc/bugs/git_annex_assistant_exits_with_failure/comment_6_5b0310038a8b45d2083f39ea75c1a979._comment b/doc/bugs/git_annex_assistant_exits_with_failure/comment_6_5b0310038a8b45d2083f39ea75c1a979._comment
new file mode 100644
index 0000000000..36a16339de
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_exits_with_failure/comment_6_5b0310038a8b45d2083f39ea75c1a979._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="lasitus"
+ avatar="http://cdn.libravatar.org/avatar/dfe778f28027aeb75876172022aa5de3"
+ subject="comment 6"
+ date="2017-02-15T16:01:38Z"
+ content="""
+Note: The last run was the Windows side
+"""]]
diff --git a/doc/bugs/git_annex_assistant_exits_with_failure/comment_7_63b3ec113d52501237abbe6ee1ef5fa5._comment b/doc/bugs/git_annex_assistant_exits_with_failure/comment_7_63b3ec113d52501237abbe6ee1ef5fa5._comment
new file mode 100644
index 0000000000..9206ba3139
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_exits_with_failure/comment_7_63b3ec113d52501237abbe6ee1ef5fa5._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="lasitus"
+ avatar="http://cdn.libravatar.org/avatar/dfe778f28027aeb75876172022aa5de3"
+ subject="comment 7"
+ date="2017-02-17T03:23:46Z"
+ content="""
+Ok, I have a script that generates the error. This generates a repository and 30 GB of random binary files with many folders 2 layers deep. Just put in an empty folder and run with python. No remotes are necessary. This was run in Windows 10 in a git bash window.
+
+```
+#!/usr/bin/env python
+
+import logging
+import os
+import shutil
+import subprocess
+import uuid
+
+logging.basicConfig(level=logging.DEBUG)
+
+repositoryPath = os.path.abspath(\"./bigRepoTest\")	
+os.makedirs(repositoryPath)
+
+subprocess.call(\"git init\", cwd=repositoryPath)
+subprocess.call(\"git annex init pc\", cwd=repositoryPath)
+
+def makeRandomDirectories(level1FolderCount, level2FolderCount, fileCount):
+	for directoryIndex in range(0, level1FolderCount):
+		logging.info(\"Adding top level folder \" + str(directoryIndex + 1) + \" of \" + str(level1FolderCount))
+		newDirectory = os.path.join(repositoryPath, str(uuid.uuid1()))
+		os.makedirs(newDirectory)
+		for directoryIndex in range(0, level2FolderCount):
+			newNestedDirectory = os.path.join(newDirectory, str(uuid.uuid1()))
+			os.makedirs(newNestedDirectory)
+			for fileIndex in range(0, fileCount):
+				newFile = os.path.join(newNestedDirectory, str(uuid.uuid1()) + \".bin\")
+				with open(newFile, 'wb') as fileOut:
+					fileOut.write(os.urandom(500000))
+
+makeRandomDirectories(32, 1000, 1)
+with open(os.path.join(repositoryPath, \"assistant.log\"), 'w') as output:
+	subprocess.Popen([\"git\", \"annex\", \"assistant\", \"--debug\"], cwd=repositoryPath, stdout=output, stderr=output)
+	makeRandomDirectories(32, 1000, 1)
+	subprocess.call(\"tail -f daemon.log\", cwd=os.path.join(repositoryPath, \".git\", \"annex\"))
+```
+"""]]
diff --git a/doc/bugs/git_annex_assistant_failing_with_ARM_NAS.mdwn b/doc/bugs/git_annex_assistant_failing_with_ARM_NAS.mdwn
new file mode 100644
index 0000000000..83b963343b
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_failing_with_ARM_NAS.mdwn
@@ -0,0 +1,29 @@
+I'm trying to use a Synology NAS (ARM architecture, DiskStation 214+) as a remote repository for my laptop, but I'm failing to get a convenient configuration to work.
+
+I already set-up git-annex on the NAS following the explanations found [here](http://git-annex.branchable.com/tips/Synology_NAS_and_git_annex/). I installed version **5.20150714-g8695533**.
+
+On my laptop I have the version provided with Ubuntu 14.04: **5.20140412ubuntu1**.
+
+If calling git annex from my laptop's command line and doing everything manually (git remote add, copy file to the dir, git annex add, git commit, git push, git annex copy), then it works properly.
+
+But when trying with the assistant I get this error:
+
+```
+fatal: unrecognized command 'sh -c 'mkdir -p '"'"'annex'"'"'&&cd '"'"'annex'"'"'&&if [ ! -d .git ]; then git init --bare --shared && git config receive.denyNonFastforwards false; fi&&git annex init''
+git-annex-shell: git-shell failed
+```
+
+This is the content of daemon.log:
+[[!format sh """
+[2015-08-04 00:51:41 CEST] main: starting assistant version 5.20140412ubuntu1
+[2015-08-04 00:51:41 CEST] Cronner: You should enable consistency checking to protect your data. 
+(Recording state in git...)
+(scanning...) [2015-08-04 00:51:41 CEST] Watcher: Performing startup scan
+(started...) [2015-08-04 00:52:41 CEST] Cronner: Consistency check in progress
+[2015-08-04 00:59:12 CEST] read: ssh-keygen ["-F","git-annex-trusted"]
+[2015-08-04 00:59:12 CEST] read: ssh ["-oNumberOfPasswordPrompts=0","-oStrictHostKeyChecking=no","-n","-p","22","git-annex@git-annex-trusted","sh -c 'echo git-annex-probe loggedin;if which git-annex-shell; then echo git-annex-probe git-annex-shell; fi;if which git; then echo git-annex-probe git; fi;if which rsync; then echo git-annex-probe rsync; fi;if which ~/.ssh/git-annex-shell; then echo git-annex-probe ~/.ssh/git-annex-shell; fi;cd '\"'\"'annex'\"'\"' && git config --list'"]
+[2015-08-04 00:59:13 CEST] read: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--with-colons","--list-secret-keys","--fixed-list-mode"]
+[2015-08-04 00:59:15 CEST] read: ssh ["-p","22","git-annex@git-annex-trusted","sh -c 'mkdir -p '\"'\"'annex'\"'\"'&&cd '\"'\"'annex'\"'\"'&&if [ ! -d .git ]; then git init --bare --shared && git config receive.denyNonFastforwards false; fi&&git annex init'"]
+"""]]
+
+Is there any problem with the version provided by Ubuntu that is producing this strange behavior?
diff --git a/doc/bugs/git_annex_assistant_failing_with_ARM_NAS/comment_1_00ca17dca9da3ddb81514d319cae0ef4._comment b/doc/bugs/git_annex_assistant_failing_with_ARM_NAS/comment_1_00ca17dca9da3ddb81514d319cae0ef4._comment
new file mode 100644
index 0000000000..0999585abe
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_failing_with_ARM_NAS/comment_1_00ca17dca9da3ddb81514d319cae0ef4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-04T20:09:36Z"
+ content="""
+The assistant's automation for setting up a remote ssh server is what looks
+to be failing. It seems that this NAS has a problem with ssh being used to
+run a sh -c command. Probably the NAS's shell is not POSIX compliant
+in some way.
+
+The best thing to do in this situation is to set up the git remote
+on the NAS manually. Once it's set up, the assistant should be able to use
+it.
+"""]]
diff --git a/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory.mdwn b/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory.mdwn
new file mode 100644
index 0000000000..3f701b788b
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory.mdwn
@@ -0,0 +1,9 @@
+Hi,
+
+I have a git-annex repository on a server managed by git annex assistant in indirect mode and as a backup group serving my org-mode files (organizer module for emacs) which are plain text files no more than a 100kb.
+
+I also have 2 clients in direct mode to sync the files across my computers.
+
+I save my files fairly often so the assistant might be a bit overwhelmed but I think it can managed that. At least it used to.
+
+Since maybe a couple months, the assistant running on the server has been leaking nearly 1Gb each day and I suspect it rises whenever I push files to it.
diff --git a/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_1_a4805854c448e4bc70a47f5555e0f73c._comment b/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_1_a4805854c448e4bc70a47f5555e0f73c._comment
new file mode 100644
index 0000000000..198731df9b
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_1_a4805854c448e4bc70a47f5555e0f73c._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-11-06T19:53:02Z"
+ content="""
+Does the assistant's memory use go back to being small when you stop 
+and restart the daemon, or does it immediately go back up?
+
+Are there a lot of files in `.git/annex/transfer`? One possibility
+is it might be getting flooded with failed/pending file transfers.
+
+If you feel up to building git-annex from source, you could
+enable the EKG remote monitoring interface. This would let you see
+graphs of the memory use, and probably get a good idea of what's
+using memory. Or, you could do a full memory profiling build of
+git-annex, which will let us nail down exactly what's using the memory.
+
+See [[this_page|ekg]] for instructions for building git-annex for EKG
+and memory profiling. If it's too hard for you to do that, I can 
+probably provide you with a prebuilt version with memory profiling.
+"""]]
diff --git a/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_2_e9dca04e0456ca7356996365a4b87d59._comment b/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_2_e9dca04e0456ca7356996365a4b87d59._comment
new file mode 100644
index 0000000000..d7d4dec394
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_2_e9dca04e0456ca7356996365a4b87d59._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://renaud.casenave.fr/"
+ subject="comment 2"
+ date="2014-11-08T07:18:48Z"
+ content="""
+Hi,
+
+Yes, the assistant memory goes back to normal when I do `git annex assistant --stop && git annex assistant`. But when I look at htop the next day, it has already taken 1Gb.
+
+There are quite a lot of files in `.git/annex/transfer`… wc reports more than 200 entries, mainly in the upload folder, although the repository only manages 10 or so files.
+
+I tried building git-annex using cabal but `cabal configure -fEKG` exits with the code 9 and even without `-fEKG` cabal refuses to install some of the dependencies. I'll try again some other time…
+
+"""]]
diff --git a/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_3_45ae862d4f940341d48d179583e65d66._comment b/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_3_45ae862d4f940341d48d179583e65d66._comment
new file mode 100644
index 0000000000..294ca5f982
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_3_45ae862d4f940341d48d179583e65d66._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="https://renaud.casenave.fr/"
+ subject="comment 3"
+ date="2014-11-15T02:07:38Z"
+ content="""
+Well it's been a week and still no luck compiling git-annex using cabal :(
+
+I'm blocked here (at pretty much the start):
+
+    % cabal install --only-dependencies
+    Resolving dependencies...
+    cabal: Could not resolve dependencies:
+    trying: git-annex-5.20141125 (user goal)
+    trying: git-annex-5.20141125:+tahoe
+    trying: git-annex-5.20141125:+dns
+    trying: aeson-0.6.0.2/installed-5b6... (dependency of
+    git-annex-5.20141125:+tahoe)
+    trying: vector-0.9.1/installed-5fe... (dependency of
+    aeson-0.6.0.2/installed-5b6...)
+    trying: dns-1.4.4 (dependency of git-annex-5.20141125:+dns)
+    next goal: network (dependency of dns-1.4.4)
+    rejecting: network-2.3.0.13/installed-0e3... (conflict:
+    git-annex-5.20141125:network-uri => network(>=2.6))
+    trying: network-2.6.0.2
+    next goal: conduit-extra (dependency of dns-1.4.4)
+    rejecting: conduit-extra-1.1.4.2, 1.1.4.1, 1.1.4, 1.1.3.4, 1.1.3.3, 1.1.3.2,
+    1.1.3.1, 1.1.3, 1.1.2, 1.1.1, 1.1.0.4 (conflict: vector =>
+    primitive==0.4.1/installed-505..., conduit-extra => primitive>=0.5)
+    rejecting: conduit-extra-1.1.0.3, 1.1.0.2, 1.1.0.1 (conflict: vector =>
+    primitive==0.4.1/installed-505..., conduit-extra => primitive>=0.5 && <0.6)
+    rejecting: conduit-extra-1.1.0 (conflict: network==2.6.0.2, conduit-extra =>
+    network>=2.3 && <2.5)
+    rejecting: conduit-extra-1.0.0.1, 1.0.0, 0.1.7, 0.1.6, 0.1.5, 0.1.4, 0.1.3,
+    0.1.2, 0.1.1, 0.1.0 (conflict: dns => conduit-extra>=1.1)
+    zsh: exit 1     cabal install --only-dependencies
+
+Should I just wait for the maintainers to fix the dependencies? Or is there another way?
+"""]]
diff --git a/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_4_d597e15e9693ce6e8c1ca80cb225b044._comment b/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_4_d597e15e9693ce6e8c1ca80cb225b044._comment
new file mode 100644
index 0000000000..ccd35305bc
--- /dev/null
+++ b/doc/bugs/git_annex_assistant_leaks_a_lot_of_memory/comment_4_d597e15e9693ce6e8c1ca80cb225b044._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawntodrSgODU27WUCyN2PV7TC14YMkyaoxQ"
+ nickname="Dennis"
+ subject="comment 4"
+ date="2014-12-11T10:58:21Z"
+ content="""
+I suffer from the same issue.
+
+In ~/.profile I put the line `git-annex assistant --quiet --autostart --startdelay=5s > /dev/null &`.
+
+Htop shows:
+
+    26291 xxx      20   0 6584M 3123M  9864 S  0.0 81.6 29h29:17 git-annex assistant --startdelay=5s
+    26292 xxx      20   0 6584M 3123M  9864 S  0.0 81.6 12h38:32 git-annex assistant --startdelay=5s
+    26293 xxx      20   0 6584M 3123M  9864 S  0.0 81.6 21h45:49 git-annex assistant --startdelay=5s
+    26321 xxx      20   0 6584M 3123M  9864 D  0.0 81.6 18:34.12 git-annex assistant --startdelay=5s
+    21019 xxx      20   0 6584M 3123M  9864 S  0.0 81.6  0:00.08 git-annex assistant --startdelay=5s
+    21908 xxx      20   0 6584M 3123M  9864 S  0.0 81.6  0:00.00 git-annex assistant --startdelay=5s
+    26290 xxx      20   0 6584M 3123M  9864 S  0.0 81.6 64h33:50 git-annex assistant --startdelay=5s
+
+"""]]
diff --git a/doc/bugs/git_annex_cannot_get_my_files_after_clone.mdwn b/doc/bugs/git_annex_cannot_get_my_files_after_clone.mdwn
new file mode 100644
index 0000000000..764e7b1df3
--- /dev/null
+++ b/doc/bugs/git_annex_cannot_get_my_files_after_clone.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+git annex cannot get me my file contents from my remotes
+
+### What steps will reproduce the problem?
+
+```
+git clone myserver:/path/to/repo
+cd repo
+git annex get
+```
+
+### What version of git-annex are you using? On what operating system?
+Using git-annex-5.20150327 on gentoo linux
+
+### Please provide any additional information below.
+
+The error messages I get egenrally look like:
+
+```
+get 2att/photos-glasgow/male/patrik.jpg (from clusterhost...) 
+git-annex: ../chymera/data/.git/annex/transfer/upload/b8415264-4b9a-40ca-b450-7e57507cdc06/lck.SHA256E-s814245--9dc6f1287ba683cae030e04ba7f94a73e566ce392c2d032f171094ddc342fa60.jpg: openFd: does not exist (No such file or directory)
+git-annex-shell: sendkey: 1 failed
+protocol version mismatch -- is your shell clean?
+(see the rsync man page for an explanation)
+rsync error: protocol incompatibility (code 2) at compat.c(176) [Receiver=3.1.1]
+
+  rsync failed -- run git annex again to resume file transfer
+
+  Unable to access these remotes: clusterhost
+
+  Try making some of these repositories available:
+  	809074b6-e079-4ea1-b2f8-2d7840deda7d -- zenbookhost
+   	a1ed6786-8b93-4a14-b00d-877b741e34da -- [clusterhost]
+failed
+```
diff --git a/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_1_52c91f8d2e8086b26a078a02d036c197._comment b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_1_52c91f8d2e8086b26a078a02d036c197._comment
new file mode 100644
index 0000000000..2a375c56c1
--- /dev/null
+++ b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_1_52c91f8d2e8086b26a078a02d036c197._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-19T16:12:12Z"
+ content="""
+From the rsync man page that the error directs you to:
+
+> rsync occasionally produces error messages that may seem a little cryp‐
+> tic. The one that seems to cause the most confusion is  "protocol  ver‐
+> sion mismatch -- is your shell clean?".
+
+> This  message is usually caused by your startup scripts or remote shell
+> facility producing unwanted garbage on the stream that rsync  is  using
+> for  its  transport.  The  way  to diagnose this problem is to run your
+> remote shell like this:
+
+>        ssh remotehost /bin/true > out.dat
+
+
+> then look at out.dat. If everything is working correctly  then  out.dat
+> should  be  a zero length file. If you are getting the above error from
+> rsync then you will probably find that out.dat contains  some  text  or
+> data.  Look  at  the contents and try to work out what is producing it.
+> The most common cause is incorrectly configured shell  startup  scripts
+> (such  as  .cshrc  or  .profile)  that  contain  output  statements for
+> non-interactive logins.
+
+"""]]
diff --git a/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_2_545c9daafc63c5cdb80763b929c8d622._comment b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_2_545c9daafc63c5cdb80763b929c8d622._comment
new file mode 100644
index 0000000000..efbb2327e7
--- /dev/null
+++ b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_2_545c9daafc63c5cdb80763b929c8d622._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/yx5Y6EI1t.759Jsu63ZWqYclCmpOmxxd.ramtw--#7114a"
+ nickname="Ioanas"
+ subject="comment 2"
+ date="2015-08-20T09:37:21Z"
+ content="""
+Doesn't seem to be the case. I get nothing in my out.dat file, but still the same rsync complaint from git annex. 
+
+```
+guest@labhost ~ $ ssh clusterhost /bin/true > out.dat
+guest@labhost ~ $ cat out.dat
+guest@labhost ~ $ ls -l out.dat 
+-rw-r--r-- 1 guest guest 0 20. Aug 11:31 out.dat
+guest@labhost ~ $ cd /mnt/data/data/                
+guest@labhost /mnt/data/data $ git annex get gt.ep/pcr/
+get gt.ep/pcr/pcr_0000.csv (from clusterhost...) 
+protocol version mismatch -- is your shell clean?
+(see the rsync man page for an explanation)
+rsync error: protocol incompatibility (code 2) at compat.c(176) [Receiver=3.1.1]
+git-annex: ../chymera/data/.git/annex/transfer/upload/b8415264-4b9a-40ca-b450-7e57507cdc06/lck.SHA256E-s960--4689d3b876dfeabb3d9578204c8df7c4af0fd6c0f09691cffb3dfd86130e6a27.csv: openFd: does not exist (No such file or directory)
+git-annex-shell: sendkey: 1 failed
+
+  rsync failed -- run git annex again to resume file transfer
+
+  Unable to access these remotes: clusterhost
+
+  Try making some of these repositories available:
+  	809074b6-e079-4ea1-b2f8-2d7840deda7d -- zenbookhost
+   	a1ed6786-8b93-4a14-b00d-877b741e34da -- [clusterhost]
+failed
+```
+"""]]
diff --git a/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_3_ef9b32d9ba1b80c313db48be36cc90d1._comment b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_3_ef9b32d9ba1b80c313db48be36cc90d1._comment
new file mode 100644
index 0000000000..4dc1985bff
--- /dev/null
+++ b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_3_ef9b32d9ba1b80c313db48be36cc90d1._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-08-20T14:58:32Z"
+ content="""
+The error message about the transfer lock file is probably relevant, and
+seems to be coming from git-annex-shell on the clusterhost server.
+
+Since this code has recently been changed and partly rewritten,
+you ought to try upgrading git-annex on clusterhost to a more recent
+version.
+
+If that doesn't help, check if the specified lock file exists,
+and if its parent directory exists. It's possible that the directory it's
+trying to put the lock file in doesn't exist and this is causing the
+problem. If so, manually creating the directory would solve it.
+
+The other possibility seems to be that it's trying to open a lock file for
+read that doesn't exist. But I don't see how that can happen, at least
+not with the current code which catches any such exception.
+
+Stracing git-annex-shell would help narrow this down. 
+The git-annex-shell command that's failing is something like this:
+
+git-annex-shell sendkey ../chymera/data SHA256E-s814245--9dc6f1287ba683cae030e04ba7f94a73e566ce392c2d032f171094ddc342fa60.jpg
+"""]]
diff --git a/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_4_d1d13d1f3366026957d572b930cafa4b._comment b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_4_d1d13d1f3366026957d572b930cafa4b._comment
new file mode 100644
index 0000000000..29853c313b
--- /dev/null
+++ b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_4_d1d13d1f3366026957d572b930cafa4b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anntzer.lee@b6e099b6ef8ba8b53005ca7f0e473e825001129b"
+ nickname="anntzer.lee"
+ subject="comment 4"
+ date="2016-01-08T07:35:21Z"
+ content="""
+I got the same error (with the same no-output from `ssh remote /bin/true`) with a fresh install of git annex, *when I did not have write rights to the remote's .git folder*.  I temporarily solved the issue by giving myself write rights to that folder, but can this be avoided?
+"""]]
diff --git a/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_5_f8b58f9c5acb509871cc4a64b66de6f3._comment b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_5_f8b58f9c5acb509871cc4a64b66de6f3._comment
new file mode 100644
index 0000000000..e23ad93b7c
--- /dev/null
+++ b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_5_f8b58f9c5acb509871cc4a64b66de6f3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-01-11T16:36:01Z"
+ content="""
+git-annex needs write access to the repository it's running in. This is a
+fairly pervasive assumption and it would not be at all easy to fix.
+"""]]
diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn b/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn
new file mode 100644
index 0000000000..586650e5de
--- /dev/null
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn
@@ -0,0 +1,82 @@
+### Please describe the problem.
+attempting to the use feature which allows me to connect to a friends remote repository results in failure, in which i have tested using multiple methods
+
+### What steps will reproduce the problem?
+#### WEBAPP
+* open the webapp
+* add repository
+* choose "share with a friend"
+* click "lets get started"
+* encounter the error found in the transcript below
+
+
+#### COMMAND LINE
+##### enable tor
+* git annex enable tor
+* encounter error found in the transcript below
+
+##### p2p --pair
+* git annex p2p --pair
+* encounter the error found in the transcript
+
+### What version of git-annex are you using? On what operating system?
+
+
+
+### Please provide any additional information below.
+
+### external dependency version info
+* git annex: using git annex found in nixos repositories
+* python version: attempted both python3 and python2.7
+* magic-wormhole version: attempted both 0.12.0 under python3, and version 0.10.0 under python2.7
+* tor version information: Tor version 0.4.7.10.
+Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1q, Zlib 1.2.12, Liblzma 5.2.5, Libzstd 1.5.2 and Glibc 2.34 as libc.
+Tor compiled with GCC version 11.3.0
+
+
+### transcript
+
+[[!format sh """
+
+#### WEBAPP
+##### error output after following steps as described above
+
+Failed to enable tor
+
+enable-tor 
+  You may be prompted for a password
+git-annex: This can only be run in a git-annex repository.
+
+git-annex: Failed to run as root: /nix/store/c42x83x25df9xd053xiii24mawnrlvrd-git-annex-10.20220504/bin/git-annex enable-tor 1000
+failed
+enable-tor: 1 failed
+
+#### COMMAND LINE
+##### enable tor
+git annex enable-tor
+Failed to enable tor
+
+enable-tor 
+  You may be prompted for a password
+git-annex: This can only be run in a git-annex repository.
+
+git-annex: Failed to run as root: /nix/store/c42x83x25df9xd053xiii24mawnrlvrd-git-annex-10.20220504/bin/git-annex enable-tor 1000
+failed
+enable-tor: 1 failed
+##### git annex p2p --pair
+git annex p2p --pair
+
+p2p pair peer1 (using Magic Wormhole) 
+
+  Failed sending data to pair.
+failed
+p2p: 1 failed
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git annex has been awesome so far in helping track and backup my data, also for allowing me to output podcasts/audiobooks to a small mp3 player, as well as ebooks and pdfs to a kindle paper ewhite, which has made using my ereader no longer an inconvinient endeavour 
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment
new file mode 100644
index 0000000000..289688d5bb
--- /dev/null
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-26T17:20:05Z"
+ content="""
+I can reproduce this by running eg:
+
+	joey@darkstar:~/tmp/torrepo>git-annex init
+	init  ok
+	joey@darkstar:~/tmp/torrepo>su -c "git-annex --debug enable-tor 1000"
+	Password:
+	git-annex: This can only be run in a git-annex repository.
+
+This was broken by git's security fix for CVE-2022-24765. Now when the root
+process tries to run `git config --list`, git does not display the local
+.git/config, because it is owned by another user.
+"""]]
diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment
new file mode 100644
index 0000000000..6261bfc7f2
--- /dev/null
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-26T17:24:23Z"
+ content="""
+Note that when git-annex uses sudo to gain root, git does not behave that
+way. But it can also use su or other methods.
+"""]]
diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_3_9fa2fb82ae3d17a77a9645870e1e12e5._comment b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_3_9fa2fb82ae3d17a77a9645870e1e12e5._comment
new file mode 100644
index 0000000000..3a688a3f5a
--- /dev/null
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_3_9fa2fb82ae3d17a77a9645870e1e12e5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-09-26T18:51:25Z"
+ content="""
+Fixed `git-annex enable-tor`
+
+The `git-annex p2p --pair` failing is unrelated. It seems that
+`wormhole` has either changed its syntax for --appid, or git-annex has
+never passed --appid to it correctly. I've fixed it to use the current
+syntax.
+"""]]
diff --git a/doc/bugs/git_annex_copy_fails_without_error_message_on_macOS___40__but_works_on_Linux__41__.mdwn b/doc/bugs/git_annex_copy_fails_without_error_message_on_macOS___40__but_works_on_Linux__41__.mdwn
new file mode 100644
index 0000000000..c971feb821
--- /dev/null
+++ b/doc/bugs/git_annex_copy_fails_without_error_message_on_macOS___40__but_works_on_Linux__41__.mdwn
@@ -0,0 +1,21 @@
+I have a git repository with a webdav annex remote. I have used this remote to store a few large files, and transfer them to other computers.
+
+I have done this on three Linux computers on different networks, and it works beautifully! Truly a life-saver!
+
+However, I today tried setting up a macOS computer, and 
+
+    git annex copy --from=myremote
+
+fails with the simple error message "failed". It downloads about ten megabytes without issue before failing. It then continues with the next file and again downloads a bit (ca. 10 Mb), then fails. The JSON error message has an empty error message field, and the JSON progress messages only contain business-as-usual before the error. 
+
+On the computer that has this problem, I am running macOS 10.15.2 and git-annex 7.20191230. 
+
+I tried WiFi and wired network connections, which doesn't make a difference. The hard drive has enough space for the files. I tried manually selecting various annexed files, but all fail after 10 Mb.
+
+The same command worked on the linux boxes I set up a few days ago.
+
+The problem really is that I am getting no meaningful error message for triaging this problem.
+
+Any help would be appreciated!
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/git_annex_copy_fails_without_error_message_on_macOS___40__but_works_on_Linux__41__/comment_1_6c044f007e66b951cf08b86f9be49ed3._comment b/doc/bugs/git_annex_copy_fails_without_error_message_on_macOS___40__but_works_on_Linux__41__/comment_1_6c044f007e66b951cf08b86f9be49ed3._comment
new file mode 100644
index 0000000000..eeecd6a2d7
--- /dev/null
+++ b/doc/bugs/git_annex_copy_fails_without_error_message_on_macOS___40__but_works_on_Linux__41__/comment_1_6c044f007e66b951cf08b86f9be49ed3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-23T20:28:20Z"
+ content="""
+Adding --debug might provide more information.
+
+`git annex version` will certianly provide useful information, including
+the version of the DAV library git-annex was built with.
+"""]]
diff --git a/doc/bugs/git_annex_copy_to_s3_out_of_memory.mdwn b/doc/bugs/git_annex_copy_to_s3_out_of_memory.mdwn
new file mode 100644
index 0000000000..9ac3d1d24e
--- /dev/null
+++ b/doc/bugs/git_annex_copy_to_s3_out_of_memory.mdwn
@@ -0,0 +1,63 @@
+### Please describe the problem.
+When using `git annex copy` to copy ~4M files to s3 I am running into what appears to be a bug in the library used to access s3. 
+
+### What steps will reproduce the problem?
+I am using git annex initially through datalad. The problem occurs when running these commands run from inside a clone of a repository that exists as a RIA store on the local file system. The RIA store remote is named `output-storage`. The s3 special remote is named `fcp-indi`. The command producing the error is `git annex copy --all --from output-storage --to fcp-indi -J 9`. 
+
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 10.20230330-g98a3ba0ea
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+```
+
+The OS is Centos7 x86_64, with 10 CPUs available and 64GB RAM. Reducing the available RAM will cause the error to happen earlier.
+
+### Please provide any additional information below.
+
+The error can appear as :
+
+```
+S3Error {s3StatusCode = Status {statusCode = 500, statusMessage = "Internal Server Error"}, s3ErrorCode = "InternalError", s3ErrorMessage = "We encountered an internal error. Please try again.", s3ErrorResource = Nothing, s3ErrorHostId = Just "[shasum redacted]=", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+ok
+git-annex: out of memory
+```
+
+or 
+
+```
+copy MD5E-s874193--d602a02b0cfebc008f9da8b02ade0114.nii.gz (from output-storage..
+.) (checksum...) (to fcp-indi...)
+  HttpExceptionRequest Request {
+    host                 = "fcp-indi.s3.amazonaws.com"
+    port                 = 80
+    secure               = False
+    requestHeaders       = [("Date","Wed, 24 May 2023 19:19:47 GMT"),("Content-Ty
+pe","application/gzip"),("Authorization","<REDACTED>"),("x-amz-acl","public-rea
+d"),("x-amz-storage-class","STANDARD")]
+    path                 = "/data/Projects/RBC/HBN_CPAC/MD5E-s874193--d602a02b0cfebc008f9da8b02ade0114.nii.gz"
+    queryString          = ""
+    method               = "PUT"
+    proxy                = Nothing
+    rawBody              = False
+    redirectCount        = 10
+    responseTimeout      = ResponseTimeoutDefault
+    requestVersion       = HTTP/1.1
+    proxySecureMode      = ProxySecureWithConnect
+  }
+   (ConnectionFailure Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [], addrFamily = AF_UNSPEC, addrSocketType = Stream, addrProtocol = 6, addrAddress = 0.0.0.0:0, addrCanonName = Nothing}, host name: Just "fcp-indi.s3.amazonaws.com", service name: Just "80"): does not exist (Temporary failure in name resolution))
+failed
+```
+
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Lots of luck, it's a main part of our workflow!
diff --git a/doc/bugs/git_annex_copy_to_s3_out_of_memory/comment_1_5c0b73214c8f0ecb197cf0e109ff2729._comment b/doc/bugs/git_annex_copy_to_s3_out_of_memory/comment_1_5c0b73214c8f0ecb197cf0e109ff2729._comment
new file mode 100644
index 0000000000..643ece91a7
--- /dev/null
+++ b/doc/bugs/git_annex_copy_to_s3_out_of_memory/comment_1_5c0b73214c8f0ecb197cf0e109ff2729._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-09-26T16:56:06Z"
+ content="""
+Is chunking or partsize configured on the S3 special remote?
+The output of `git-annex info fcp-indi` will tell us that.
+
+How large are the files you're sending? Are any particularly large, eg
+larger than available ram?
+
+Am I understanding correctly that you're sending 4 million files to S3?
+And do these failures happen after a significant number of those files have
+been sent, or more randomly?
+
+Does git-annex's memory use show a trend of increasing the more files are
+sent?
+"""]]
diff --git a/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de.mdwn b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de.mdwn
new file mode 100644
index 0000000000..cc38813557
--- /dev/null
+++ b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+In the webapp, I enter my credentials for my jabber.de account.  When I hit "use this account" the daemon and webapp crash.
+
+### What steps will reproduce the problem?
+Presumably, authenticate with a jabber.de account.
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 5.20140517-g0aed6d9
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+
+### Please provide any additional information below.
+
+[[!format sh """
+[2014-05-25 18:11:02 EDT] 127.0.0.1 POST /config/xmpp Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36
+git-annex: <socket: 44>: hGetBuf: resource vanished (Connection reset by peer)
+git-annex: interrupted
+"""]]
+
+[[!tag confirmed forwarded]]
+
+[[!meta title="OSX xmpp crash with jabber.de"]]
diff --git a/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_1_5ba4f22bda2f5438fb08753cf149b649._comment b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_1_5ba4f22bda2f5438fb08753cf149b649._comment
new file mode 100644
index 0000000000..003b60b9fb
--- /dev/null
+++ b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_1_5ba4f22bda2f5438fb08753cf149b649._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 1"
+ date="2014-05-27T18:45:35Z"
+ content="""
+I was able to use that server from git-annex on Linux successfully.
+
+I also tried on OSX, which appears to be the OS you're using. The assistant didn't crash. I may not have exactly replicated what you did though.
+
+Can you enable debug logging in Configuration -> Preferences and try to do this again, and send any parts of the log that mention XMPP?
+"""]]
diff --git a/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_2_b096cfdf26bfedfff16d882d7b2e060d._comment b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_2_b096cfdf26bfedfff16d882d7b2e060d._comment
new file mode 100644
index 0000000000..87e6b746eb
--- /dev/null
+++ b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_2_b096cfdf26bfedfff16d882d7b2e060d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmZilYULa6CDEGfuagoDlesyakBgnf-dF8"
+ nickname="Maarten"
+ subject="comment 2"
+ date="2014-05-27T18:59:08Z"
+ content="""
+This was debug logging enabled, it appeared to be the only relevant parts in the log but I can try again and post more verbosely.
+
+If nothing more comes up, what else could I do to get you diagnostic data?
+"""]]
diff --git a/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_3_210be77aabb0ef5b85865cd08c51861e._comment b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_3_210be77aabb0ef5b85865cd08c51861e._comment
new file mode 100644
index 0000000000..c2db30db0d
--- /dev/null
+++ b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_3_210be77aabb0ef5b85865cd08c51861e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 3"
+ date="2014-05-27T19:03:20Z"
+ content="""
+Hmm, so it was.. There was so little logged that I missed it.
+
+Can you reproduce the crash?
+
+I think that OSX has some ways to get a dump of information about a crash, but I don't know details.
+"""]]
diff --git a/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_4_bb974d882fbb31aa54e6de38410a2318._comment b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_4_bb974d882fbb31aa54e6de38410a2318._comment
new file mode 100644
index 0000000000..059eec0500
--- /dev/null
+++ b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_4_bb974d882fbb31aa54e6de38410a2318._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmZilYULa6CDEGfuagoDlesyakBgnf-dF8"
+ nickname="Maarten"
+ subject="comment 4"
+ date="2014-05-27T19:07:45Z"
+ content="""
+I might attach wireshark but I don't know if it'll help much seeing as jabber.de as most XMPP services just went SSL only.
+"""]]
diff --git a/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_5_be655cbea27b6c87d298a75e1697a87d._comment b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_5_be655cbea27b6c87d298a75e1697a87d._comment
new file mode 100644
index 0000000000..f6aa9d45b2
--- /dev/null
+++ b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_5_be655cbea27b6c87d298a75e1697a87d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 5"
+ date="2014-05-30T19:09:31Z"
+ content="""
+If you can reproduce the crash, I can provide some debug program that will narrow down where the bug is..
+"""]]
diff --git a/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_6_72d1dac6627bbe22d5bd140215d82c47._comment b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_6_72d1dac6627bbe22d5bd140215d82c47._comment
new file mode 100644
index 0000000000..909fdd3ae8
--- /dev/null
+++ b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_6_72d1dac6627bbe22d5bd140215d82c47._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmZilYULa6CDEGfuagoDlesyakBgnf-dF8"
+ nickname="Maarten"
+ subject="comment 6"
+ date="2014-05-30T19:37:03Z"
+ content="""
+I can definitely reproduce it on my end
+"""]]
diff --git a/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_7_8a8dfb15684525e156d6334e9f67a55c._comment b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_7_8a8dfb15684525e156d6334e9f67a55c._comment
new file mode 100644
index 0000000000..8e862d468f
--- /dev/null
+++ b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_7_8a8dfb15684525e156d6334e9f67a55c._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 7"
+ date="2014-05-30T20:47:02Z"
+ content="""
+I wrote a test program to try to connect to this server, using a test account, and dump some events. This works on linux. Then I tried it on mac, and I think I have reproduced the same failure!
+
+<pre>
+oberon:~ joeyh$ ./xmpp
+xmpp: <socket: 3>: hGetBuf: resource vanished (Connection reset by peer)
+</pre>
+
+Note that this exception is unable to be caught, it seems. Which would explain why the whole git-annex assistant crashes.
+
+Also, the same program, when modified to use some other xmpp server, does not crash.
+
+At this point, I think I need to forward this bug to network-protocol-xmpp author John Millikin. Which I've now done.
+
+My advice for the bug submitter: git-annex is going to be deprecating XMPP in the not too distant future anyway. If you have your own server, a much nicer way to use git-annex is to install it on the server and use ssh remotes. Recent versions do not need xmpp to sync between clients in such a configuration.
+
+Test program:
+
+[[!format haskell \"\"\"
+{-# LANGUAGE OverloadedStrings #-}
+
+import Network.Protocol.XMPP
+import Data.Maybe
+import Data.Either
+import Network
+import Control.Monad
+import Control.Monad.IO.Class
+import Control.Exception
+
+main = do
+        catch test
+                (\e -> do
+                        let err = show (e :: IOException)
+                        print (\"caught: \", err)
+                        return (Right ())
+                )
+        print \"clean exit\"
+
+test :: IO (Either Error ())
+test = runClient server (getjid jid) username password $ do
+        liftIO $ print \"connected to server\"
+        jid <- bindJID (getjid jid)
+        liftIO $ print (\"bound to jid\", jid)
+        forever $ do
+                s <- getStanza
+                liftIO $ print (\"got\", s)
+  where
+        getjid t = fromMaybe (error \"jid parse error\") (parseJID t)
+        server = Server
+                (getjid serverjid)
+                servername
+                (PortNumber port)
+
+        servername = \"jabber.de\"
+        serverjid = \"jabber.de\"
+        port = 5222
+        jid = \"haskellxmpptest@jabber.de\"
+        username = \"haskellxmpptest\"
+        password = \"stupidpassword\"
+\"\"\"]]
+"""]]
diff --git a/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_8_f1a6e413756066659020e20147373a11._comment b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_8_f1a6e413756066659020e20147373a11._comment
new file mode 100644
index 0000000000..c4a8749543
--- /dev/null
+++ b/doc/bugs/git_annex_daemon_crashes_when_authenticating_with_jabber.de/comment_8_f1a6e413756066659020e20147373a11._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 8"
+ date="2014-07-11T19:57:35Z"
+ content="""
+Unfortunately, this seems to be somewhat intermittent, so while I had a test case that worked once, John never saw it fail and has not been able to debug it. The test case has successfully connected every time I've tried it recently too. Perhaps jabber.de has changed whatever was causing the problem..
+"""]]
diff --git a/doc/bugs/git_annex_enableremote_gcrypt_failure_leaves_a_remote.mdwn b/doc/bugs/git_annex_enableremote_gcrypt_failure_leaves_a_remote.mdwn
new file mode 100644
index 0000000000..021d782deb
--- /dev/null
+++ b/doc/bugs/git_annex_enableremote_gcrypt_failure_leaves_a_remote.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+
+Running `git-annex enableremote remote` without a suitable key available leaves a partially unconfigured git remote.
+
+Subsequently making the key available and running `git-annex enableremote remote` a second time fails as the remote now partially exists.
+
+Removing the remote with `git remote remove remote` and then re-running `git-annex enable remote` seems to do the trick.
+
+However, I notice that even after syncing my special remotes are missing some details in the git config file - namely the `annex-gcrypt` and `annex-uuid` (there may have been more).  I fixed by adding the details from a working repo.
+
+Finally, when I initially created the gcrypt repo (by hand) I specified the remote as a local directory on the machine in question i.e. `gcrypt::/matt/mnt/isilon/rss/zzalsmf3/git-annex/mus` I then decided to make it available and changed it (via `git remote rename` to `gcrypt::ssh://rss/home/matt/mnt/isilon/rss/zzalsmf3/git-annex/mus`.  Unfortunately on other machines when I `git enableremote` it recovers the original remote which obviously doesn't work - how can I update this setting?
+
+Phew!
+
+
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/git_annex_enableremote_locking_issue.mdwn b/doc/bugs/git_annex_enableremote_locking_issue.mdwn
new file mode 100644
index 0000000000..0fc2ca3f25
--- /dev/null
+++ b/doc/bugs/git_annex_enableremote_locking_issue.mdwn
@@ -0,0 +1,56 @@
+### Please describe the problem.
+
+When enabling an S3 remote with hybrid encryption, I get a file locking error:
+
+```
+$ git annex enableremote s3remote
+git-annex: .git/annex/creds/__S3_REMOTE_UUID_REDACTED__: openFile: resource busy (file is locked)
+```
+
+I can confirm that this happens when no previous process is running (and lsof shows nothing open before running enableremote), for example in the motivating case here of cloning to a new, freshly-mounted HDD.
+
+If I copy the `.git/annex/creds/__S3_REMOTE_UUID_REDACTED__` file from an existing clone of the repository to this new one, then enableremote works fine.
+
+```
+$ git annex enableremote s3remote              
+enableremote s3remote (encryption update) (to gpg keys: HEXREDACTED) ok
+(recording state in git...)
+```
+
+### What steps will reproduce the problem?
+
+For me, with a source a repository that has a pre-configured S3 special remote:
+
+```
+$ git show git-annex:remote.log
+__UUID__ bucket=bucket-name cipher=__base64_jibberish__ cipherkeys=GPGKEY_HEX datacenter=US host=s3.eu-central-003.backblazeb2.com name=s3remote partsize=512MiB port=80 protocol=https s3creds=__base64_jibberish__ signature=v4 storageclass=STANDARD type=S3 timestamp=168000000.0s
+```
+
+Then, to reproduce this:
+
+```
+git clone /path/to/established-repo new_clone
+cd new_clone
+git annex init new_clone
+git annex enableremote s3remote
+```
+
+
+
+### What version of git-annex are you using? On what operating system?
+
+The latest:
+
+```
+$ git annex version
+git-annex version: 10.20230926-g44a7b4c9734adfda5912dd82c1aa97c615689f57
+```
+
+### Please provide any additional information below.
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+A great deal, we use it daily in our research and I also use it on some personal files -- thanks for all your efforts Joey et al.!
+
+> Reproduced and fixed. [[done]] --[[Joey]]
diff --git a/doc/bugs/git_annex_forget_does_not_propagate.mdwn b/doc/bugs/git_annex_forget_does_not_propagate.mdwn
new file mode 100644
index 0000000000..82b4c5df53
--- /dev/null
+++ b/doc/bugs/git_annex_forget_does_not_propagate.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+When using git annex forget to clear the git-annex branch, syncing these changes does not result in clearing the git-annex branches of other remotes. Instead, these branches are only appended to with the commit starting the new branch, and when sync is run on the originating repo, the forget is undone.
+
+### What steps will reproduce the problem?
+1. `git annex forget --drop-dead`
+2. (on remote) `git annex sync (repo where forget was run)`
+3. (on starting repo) `git annex sync *remote*`
+
+### What version of git-annex are you using? On what operating system?
+
+    git-annex version: 8.20210223
+    build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+    dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+    operating system: linux x86_64
+    supported repository versions: 8
+    upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+    local repository version: 8
+
+### Please provide any additional information below.
+
+`git annex sync --cleanup` before sync was ineffective
+
+There is no error log per se, git annex thinks everything went well.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Aside from this, best thing ever.
+
+> [[fixed|done]] back in 2022 --[[Joey]]
diff --git a/doc/bugs/git_annex_forget_does_not_propagate/comment_1_591c3c59d831ed94268f90505a8baaee._comment b/doc/bugs/git_annex_forget_does_not_propagate/comment_1_591c3c59d831ed94268f90505a8baaee._comment
new file mode 100644
index 0000000000..7231d606ee
--- /dev/null
+++ b/doc/bugs/git_annex_forget_does_not_propagate/comment_1_591c3c59d831ed94268f90505a8baaee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Too old?"
+ date="2023-04-17T01:43:36Z"
+ content="""
+Have you tried with latest git annex? Yours is two major versions behind and two years old...
+"""]]
diff --git a/doc/bugs/git_annex_forget_does_not_propagate/comment_2_9026452178c82d0661acc96d009e3764._comment b/doc/bugs/git_annex_forget_does_not_propagate/comment_2_9026452178c82d0661acc96d009e3764._comment
new file mode 100644
index 0000000000..8f39274b00
--- /dev/null
+++ b/doc/bugs/git_annex_forget_does_not_propagate/comment_2_9026452178c82d0661acc96d009e3764._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-04-17T17:34:16Z"
+ content="""
+Look what I found in the changelog:
+
+	git-annex (10.20220222) upstream; urgency=medium
+	
+	  * Fix git-annex forget propagation between repositories.
+	    (reversion introduced in version 7.20190122)
+	
+	 -- Joey Hess <id@joeyh.name>  Tue, 22 Feb 2022 13:01:20 -0400
+"""]]
diff --git a/doc/bugs/git_annex_get_--batch_does_not_work.mdwn b/doc/bugs/git_annex_get_--batch_does_not_work.mdwn
new file mode 100644
index 0000000000..d6aaea3f2a
--- /dev/null
+++ b/doc/bugs/git_annex_get_--batch_does_not_work.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+
+`git annex get foo` does work.
+
+`echo "foo" | git annex get --batch` does not.
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 8.20210223
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+
+
+I use it on Debian 11
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+YES! Git annex is a wonderful tool! I use it for synchronising TB of data
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/git_annex_get_--batch_does_not_work/comment_1_52311b95bf29706d2b1afb3904428047._comment b/doc/bugs/git_annex_get_--batch_does_not_work/comment_1_52311b95bf29706d2b1afb3904428047._comment
new file mode 100644
index 0000000000..c81bd49ad6
--- /dev/null
+++ b/doc/bugs/git_annex_get_--batch_does_not_work/comment_1_52311b95bf29706d2b1afb3904428047._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="git-annex.visiteur@e9d364191d2ffc1b163c8d9e4c57dbadf58aad8e"
+ nickname="git-annex.visiteur"
+ avatar="http://cdn.libravatar.org/avatar/59640df9d44f100f0bf98c1cbb430037"
+ subject="comment 1"
+ date="2022-03-06T14:37:42Z"
+ content="""
+When I say \"It dos not work\", I mean \"It only returns blank line\"
+"""]]
diff --git a/doc/bugs/git_annex_get_--batch_does_not_work/comment_2_b4fa614626393e01c51b937401bbaa23._comment b/doc/bugs/git_annex_get_--batch_does_not_work/comment_2_b4fa614626393e01c51b937401bbaa23._comment
new file mode 100644
index 0000000000..6a20bbf351
--- /dev/null
+++ b/doc/bugs/git_annex_get_--batch_does_not_work/comment_2_b4fa614626393e01c51b937401bbaa23._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-03-07T16:01:56Z"
+ content="""
+A blank line means that the file's content is already
+present, or it is not an annexed file. This is documented under --batch in
+the man page of git-annex get.
+"""]]
diff --git a/doc/bugs/git_annex_get_--batch_does_not_work/comment_3_e972b9fb5c6af4ecd295dc954bb2f55a._comment b/doc/bugs/git_annex_get_--batch_does_not_work/comment_3_e972b9fb5c6af4ecd295dc954bb2f55a._comment
new file mode 100644
index 0000000000..03451cdfdc
--- /dev/null
+++ b/doc/bugs/git_annex_get_--batch_does_not_work/comment_3_e972b9fb5c6af4ecd295dc954bb2f55a._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="git-annex.visiteur@e9d364191d2ffc1b163c8d9e4c57dbadf58aad8e"
+ nickname="git-annex.visiteur"
+ avatar="http://cdn.libravatar.org/avatar/59640df9d44f100f0bf98c1cbb430037"
+ subject="comment 3"
+ date="2022-03-07T19:22:54Z"
+ content="""
+I already see in the manual that blank line means the file is not in annex. But it is NOT the case here.
+
+I do think it's is a bug. See the result of the following commands executed in a row:
+
+
+    > echo \"Wasabi\" | git annex info --batch
+    directory: Wasabi
+    local annex keys: 0
+    local annex size: 0 bytes
+    annexed files in working tree: 4
+    size of annexed files in working tree: 733.1 megabytes
+    numcopies stats:
+    	numcopies +3: 4
+    repositories containing these files: 4
+    	733.1 MB: 2a15d9f9-eb82-4b20-8b4d-2ae1e0da4eee -- freenas
+     	733.1 MB: 7c082253-61af-45e1-b68d-381d2516a626 -- passport
+     	733.1 MB: c6634036-e251-425e-a075-1ec4e08b0a78 -- pomme
+     	733.1 MB: d58b0ca5-becd-416e-b1cd-e6fefca3685f -- intenso [osmc]
+    combined size of repositories containing these files: 2.93 gigabytes
+
+
+    > echo \"Wasabi\" | git annex get --batch
+    (blank line)
+
+    > git annex get Wasabi
+    get Wasabi/Wasabi-fanart.jpg (from osmc...)
+    ...
+"""]]
diff --git a/doc/bugs/git_annex_get_--batch_does_not_work/comment_4_f0c498dad3f4d51e33de863165f29410._comment b/doc/bugs/git_annex_get_--batch_does_not_work/comment_4_f0c498dad3f4d51e33de863165f29410._comment
new file mode 100644
index 0000000000..e8ad2fb746
--- /dev/null
+++ b/doc/bugs/git_annex_get_--batch_does_not_work/comment_4_f0c498dad3f4d51e33de863165f29410._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-03-07T19:27:35Z"
+ content="""
+You have added single quotes around the file name `Wasabi`,
+so you have told it to get a file with those quotes in its name. No such
+file exists.
+
+You do not need to single quote anything in the batch interface.
+"""]]
diff --git a/doc/bugs/git_annex_get_--batch_does_not_work/comment_5_603adcb0b5091ac2fb3c9225d2925dc3._comment b/doc/bugs/git_annex_get_--batch_does_not_work/comment_5_603adcb0b5091ac2fb3c9225d2925dc3._comment
new file mode 100644
index 0000000000..7fdf3e69ec
--- /dev/null
+++ b/doc/bugs/git_annex_get_--batch_does_not_work/comment_5_603adcb0b5091ac2fb3c9225d2925dc3._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="git-annex.visiteur@e9d364191d2ffc1b163c8d9e4c57dbadf58aad8e"
+ nickname="git-annex.visiteur"
+ avatar="http://cdn.libravatar.org/avatar/59640df9d44f100f0bf98c1cbb430037"
+ subject="comment 5"
+ date="2022-03-07T19:59:17Z"
+ content="""
+It is exactely the same with the following
+
+    > echo Wasabi | git annex get --batch
+    (blank line)
+
+Moreover, it would be strange that quote works with \"info\" but not with \"get\"
+"""]]
diff --git a/doc/bugs/git_annex_get_--batch_does_not_work/comment_6_56716644ee1534b8fe90ba502856455c._comment b/doc/bugs/git_annex_get_--batch_does_not_work/comment_6_56716644ee1534b8fe90ba502856455c._comment
new file mode 100644
index 0000000000..c38749162e
--- /dev/null
+++ b/doc/bugs/git_annex_get_--batch_does_not_work/comment_6_56716644ee1534b8fe90ba502856455c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-03-08T17:56:54Z"
+ content="""
+According to the git-annex info output, `Wasabi` is a directory.
+
+Since a directory is not an annexed file, git-annex get --batch will
+not get it, so it outputs a blank line. If you tell it to get a specific file
+within that directory, it will.
+
+Since git-annex info --batch can operate on directories as well as on files,
+it does. That is the reason for the inconsistency.
+"""]]
diff --git a/doc/bugs/git_annex_get_--batch_does_not_work/comment_7_b0588132d02f982da7c7208087b0afe2._comment b/doc/bugs/git_annex_get_--batch_does_not_work/comment_7_b0588132d02f982da7c7208087b0afe2._comment
new file mode 100644
index 0000000000..1d2b8369c2
--- /dev/null
+++ b/doc/bugs/git_annex_get_--batch_does_not_work/comment_7_b0588132d02f982da7c7208087b0afe2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="git-annex.visiteur@e9d364191d2ffc1b163c8d9e4c57dbadf58aad8e"
+ nickname="git-annex.visiteur"
+ avatar="http://cdn.libravatar.org/avatar/59640df9d44f100f0bf98c1cbb430037"
+ subject="comment 7"
+ date="2022-03-09T06:33:51Z"
+ content="""
+Ok, using file name directly instead of parent directory is working. 
+
+Is there a good reason explaining why `git annex get <DIR>` works wherease `echo <DIR> | git annex get --batch` doesn't?
+"""]]
diff --git a/doc/bugs/git_annex_get_--batch_does_not_work/comment_8_0e776c598c5e0f4f51f5e9ade8c3f0e2._comment b/doc/bugs/git_annex_get_--batch_does_not_work/comment_8_0e776c598c5e0f4f51f5e9ade8c3f0e2._comment
new file mode 100644
index 0000000000..eba5b62a3a
--- /dev/null
+++ b/doc/bugs/git_annex_get_--batch_does_not_work/comment_8_0e776c598c5e0f4f51f5e9ade8c3f0e2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-03-10T17:09:26Z"
+ content="""
+Other features like --json when used with --batch would
+not work well if it recursed through directories. There would be no way to
+know which output corresponded with which input.
+"""]]
diff --git a/doc/bugs/git_annex_get_--batch_does_not_work/comment_9_0c802c9c5734e7dfc8cd72962fcf2983._comment b/doc/bugs/git_annex_get_--batch_does_not_work/comment_9_0c802c9c5734e7dfc8cd72962fcf2983._comment
new file mode 100644
index 0000000000..81d692d0cf
--- /dev/null
+++ b/doc/bugs/git_annex_get_--batch_does_not_work/comment_9_0c802c9c5734e7dfc8cd72962fcf2983._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="git-annex.visiteur@e9d364191d2ffc1b163c8d9e4c57dbadf58aad8e"
+ nickname="git-annex.visiteur"
+ avatar="http://cdn.libravatar.org/avatar/59640df9d44f100f0bf98c1cbb430037"
+ subject="comment 9"
+ date="2022-03-11T18:46:40Z"
+ content="""
+Ok thank you, i understand the reason.
+
+Very good job by the way.
+"""]]
diff --git a/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects.mdwn b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects.mdwn
new file mode 100644
index 0000000000..4c0cf29231
--- /dev/null
+++ b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects.mdwn
@@ -0,0 +1,42 @@
+### Please describe the problem.
+`git annex import` is dangerous when you have unused git objects in your git store. You have the potential to lose your filenames and only be left with git objects containing the data.
+
+
+### What steps will reproduce the problem?
+```
+echo "foo" > /tmp/foo
+echo "bar" > /tmp/bar
+echo "baz" > /tmp/baz
+cd ~/annex
+cp /tmp/{foo,bar,baz} .
+git annex add ./{foo,bar,baz}
+# I decide I want to abort this particular commit, so I reset
+git reset --hard
+# At this point, git reset removed the symlinks from our index, but the objects containing the file content still exist in the git store.
+
+# A few days later I decide to import another backup of my data from this location: /tmp/myotherbackup/files/{foo,bar,baz}
+
+# This command removes foo, bar and baz from the source directory, but does not add symlinks for them. They were considered duplicates because we had git objects associated with their content (even though they are unused git objects).
+git annex import --deduplicate
+
+# This command considers foo, bar and baz duplicates and removes them from the source directory. We are left with unused objects in the git store, but no idea what the filenames were.
+git annex import --clean-duplicates
+```
+
+### What version of git-annex are you using? On what operating system?
+$ ga version
+git-annex version: 5.20140717
+build flags: Assistant Inotify DBus TDFA
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+remote types: git gcrypt bup directory rsync web glacier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+
+OS: Fedora 25
+
+### Please provide any additional information below.
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I love git-annex! I used it to manage my Pictures.
diff --git a/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_1_9f9d5c18c27dfd33a5bf2c593ee65b58._comment b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_1_9f9d5c18c27dfd33a5bf2c593ee65b58._comment
new file mode 100644
index 0000000000..aac409e983
--- /dev/null
+++ b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_1_9f9d5c18c27dfd33a5bf2c593ee65b58._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-02T21:20:02Z"
+ content="""
+A simpler way to get to the same end result, without using git-annex
+import:
+
+	mv ~/foo .
+	git annex add foo
+	git reset --hard
+
+Now "foo" is only present in the git-annex object store, and we don't
+know what its filename(s) were. 
+
+A way to get to the same end result, without using git-annex:
+
+	mv ~/foo .
+	git add foo
+	git reset --hard
+
+Now "foo" is only present in the git object store, and we don't
+know what its filename(s) were.
+
+So, it's not `git-annex import`, or `git-annex add`, or `git add`
+that is dangerous here. It's `git reset --hard`.
+
+git will happily lose lots of data until you commit it. Once it's
+committed, it's safe. That's the rule of thumb. Nothing much that git-annex
+can do about that.
+"""]]
diff --git a/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_2_f64891ff6fe0cd0be6a356ab8fe42817._comment b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_2_f64891ff6fe0cd0be6a356ab8fe42817._comment
new file mode 100644
index 0000000000..0b459529bc
--- /dev/null
+++ b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_2_f64891ff6fe0cd0be6a356ab8fe42817._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-03-02T21:26:57Z"
+ content="""
+One way to fix this would be to make `git reset --hard` first make a commit
+of the current state of the index, and store that commit in the reflog. 
+
+Of course, that's quite similar to `git stash` and probably most of us have
+just gotten in the habit of running `git stash` instead.
+"""]]
diff --git a/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_3_d980c1e2d788324049475e468a0d6fab._comment b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_3_d980c1e2d788324049475e468a0d6fab._comment
new file mode 100644
index 0000000000..e86ff13de2
--- /dev/null
+++ b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_3_d980c1e2d788324049475e468a0d6fab._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="mbroadhead"
+ avatar="http://cdn.libravatar.org/avatar/f3d801c0c943caab1152c4ebe8c99d51"
+ subject="comment 3"
+ date="2017-03-02T22:48:08Z"
+ content="""
+Thanks for the insight.
+
+The `git stash` solution works assuming you are either:
+
+ a. Going to keep it in your stash forever
+ b. You are going to commit your stash eventually
+
+I think there are situations where I want to completely abort a commit and not have to worry about it biting me down the road.
+
+IMO from a end user perspective I think the best solution would be to have data only count as duplicate if it has a reachable file in your annex for options `--deduplicate`, `--clean-duplicates` and `--skip-duplicates` of `git annex import`.
+
+What would be the downside to this?
+
+Worst case scenario this re-wires up some symlinks to once dangling git objects. They still aren't duplicates, there will only be one symlink per formerly dangling git object. This seems better than data loss.
+
+Thoughts?
+"""]]
diff --git a/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_4_09b860a14bb8bd49f2067e8ddb0aacfc._comment b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_4_09b860a14bb8bd49f2067e8ddb0aacfc._comment
new file mode 100644
index 0000000000..877c0ff182
--- /dev/null
+++ b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_4_09b860a14bb8bd49f2067e8ddb0aacfc._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="mbroadhead"
+ avatar="http://cdn.libravatar.org/avatar/f3d801c0c943caab1152c4ebe8c99d51"
+ subject="comment 4"
+ date="2017-03-03T16:59:52Z"
+ content="""
+> I think there are situations where I want to completely abort a commit and
+> not have to worry about it biting me down the road.
+
+If you don't want to have to worry about a `git reset --hard` biting you down
+the road the way that it works now, just make sure you clean up after yourself.
+Example:
+
+```
+cd ~/annex
+cp /tmp/foo .
+git annex add foo
+
+# Oh, I decided I don't want \"foo\" in my annex right now, so I do a reset.
+# This will leave the data associated with \"foo\" in a git object in the git
+# store.  When running 'git annex import' sometime in the future, this will
+# make any files that contain the same data as \"foo\" to be considered
+# duplicate.  This will cause \"foo\" to be considered a duplicate by git annex
+# import, which we don't want in this scenario.
+git reset --hard
+
+# In order to avoid \"foo\" being a duplicate, find the dangling git object:
+git annex unused
+
+# And drop it:
+git annex dropunused N
+
+# Now \"foo\" won't be marked as a duplicate if you run any of the following
+# commands:
+git annex import /tmp/backup/foo --skip-duplicates
+git annex import /tmp/backup/foo --clean-duplicates
+git annex import /tmp/backup/foo --deduplicate
+```
+"""]]
diff --git a/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_5_1e737b740bc7d95f3329e3481d55fd35._comment b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_5_1e737b740bc7d95f3329e3481d55fd35._comment
new file mode 100644
index 0000000000..89b088f145
--- /dev/null
+++ b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_5_1e737b740bc7d95f3329e3481d55fd35._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-03-06T16:25:53Z"
+ content="""
+The difficulty with checking if the content to be imported is referred to
+somewhere in the working tree is that there's no inexpensive way to
+determine that. It would have to run `git log -n1 -S$KEY` for each file.
+That can take quite a long time in repositories with a lot of history.
+I clocked it at 12 seconds per file on an SSD; will be quite a
+lot slower on a disc.
+
+I suppose that check could be added with a --fast to skip the check.
+
+PS, mbroadhead's is a good approach. Note though that the dropunused content
+will be considered a duplicate by import since git-annex
+version 6.20170214. Still, --deduplicate and --clean-duplicates won't
+delete the files from the import location in this case, since there
+are no copies of the content in the annex.
+"""]]
diff --git a/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_6_6def3c88ced56753e4b12ce221d33769._comment b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_6_6def3c88ced56753e4b12ce221d33769._comment
new file mode 100644
index 0000000000..905b6ca6a2
--- /dev/null
+++ b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_6_6def3c88ced56753e4b12ce221d33769._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-01-29T18:38:41Z"
+ content="""
+To the extent that this is a bug in git-annex import, it's solved
+by using the new feature of importing a tree from a directory special
+remote. When used that way, there's no --deduplicate or --clean-duplicates
+option that causes this problem. Instead it makes git commits tracking the
+content of the remote directory, and as long as you merge that remote into
+your master branch, the original filename will be preserved in git.
+
+So once [[todo/remove_legacy_import_directory_interface]] happens, I
+guess this could be considered fixed, to the extent it's a bug in git-annex
+at all and not with using `git reset --hard` as I showed could lead to the
+same thing in vanilla git.
+"""]]
diff --git a/doc/bugs/git_annex_move_--unused_not_moving_some_files.mdwn b/doc/bugs/git_annex_move_--unused_not_moving_some_files.mdwn
new file mode 100644
index 0000000000..aa754b64be
--- /dev/null
+++ b/doc/bugs/git_annex_move_--unused_not_moving_some_files.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+`git annex move --unused` is not moving some of the files `git annex unused` reports:
+
+```
+Calibre Library % git annex unused 
+unused . (checking for unused data...) (checking master...) (checking refs/annex/last-index...) 
+  Some annexed data is no longer used by any files:
+    NUMBER  KEY
+    1       SHA256E-s182401--1c42279d1ea477f2a1831a3f7543481e7d5c72cbbeffdd0442918253b4f3ecc9.jpg
+    2       SHA256E-s127374--17bfedf7453382df04a58d9c508d82285970148e49a84c488a728f7f770d8cc3.jpg
+[...]
+    56      SHA256E-s427315--3617fae344fb4fbc825963ee0ddfc5a31f1000c8d1c61ce3955bc16ae625e207.epub
+  (To see where this data was previously used, run: git annex whereused --historical --unused
+  
+  To remove unwanted data: git-annex dropunused NUMBER
+  
+ok
+Calibre Library % git annex move --unused -t bims 
+Calibre Library %
+```
+
+Is there anything that explains this behavior?
+
+### What steps will reproduce the problem?
+I am not sure how to reproduce this in another repo.
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 8.20210803
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Sure, I use it every day for various tasks! Great software!
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_1_3fe94ad69d28f16598fdb8f98d7ffa54._comment b/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_1_3fe94ad69d28f16598fdb8f98d7ffa54._comment
new file mode 100644
index 0000000000..8490c48cf5
--- /dev/null
+++ b/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_1_3fe94ad69d28f16598fdb8f98d7ffa54._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="mike@2d6d71f56ce2a992244350475251df87c26fe351"
+ nickname="mike"
+ avatar="http://cdn.libravatar.org/avatar/183fa439752e2f0c6f39ede658d81050"
+ subject="comment 1"
+ date="2021-09-10T14:28:23Z"
+ content="""
+May be fixed in 8.20210903 (\"unused: Skip the refs/annex/last-index ref that git-annex recently started creating.\") - I'm compiling it to confirm.
+"""]]
diff --git a/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_2_91cdee93a29eefca78c1e49878b71574._comment b/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_2_91cdee93a29eefca78c1e49878b71574._comment
new file mode 100644
index 0000000000..36833b19e4
--- /dev/null
+++ b/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_2_91cdee93a29eefca78c1e49878b71574._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="mike@2d6d71f56ce2a992244350475251df87c26fe351"
+ nickname="mike"
+ avatar="http://cdn.libravatar.org/avatar/183fa439752e2f0c6f39ede658d81050"
+ subject="comment 2"
+ date="2021-09-10T14:41:17Z"
+ content="""
+It's not fixed in 8.20210903, it just isn't `(checking refs/annex/last-index...)` anymore.
+"""]]
diff --git a/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_3_40d839105047f4ac2996b53705601cc4._comment b/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_3_40d839105047f4ac2996b53705601cc4._comment
new file mode 100644
index 0000000000..c1fe123305
--- /dev/null
+++ b/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_3_40d839105047f4ac2996b53705601cc4._comment
@@ -0,0 +1,62 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-09-21T17:34:08Z"
+ content="""
+I have not been able to reproduce this, it works for me.
+
+	joey@darkstar:~/tmp>git init a1
+	Initialized empty Git repository in /home/joey/tmp/a1/.git/
+	joey@darkstar:~/tmp>cd a1
+	joey@darkstar:~/tmp/a1>git annex init
+	init  ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/a1>date > foo
+	joey@darkstar:~/tmp/a1>date > bar
+	joey@darkstar:~/tmp/a1>git annex add
+	add bar
+	ok
+	add foo
+	ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/a1>git commit -m add
+	[master (root-commit) fdd215f] add
+	 2 files changed, 2 insertions(+)
+	 create mode 120000 bar
+	 create mode 120000 foo
+	joey@darkstar:~/tmp/a1>rm foo
+	joey@darkstar:~/tmp/a1>git commit -a -m rm
+	[master 1f84de1] rm
+	 1 file changed, 1 deletion(-)
+	 delete mode 120000 foo
+	joey@darkstar:~/tmp/a1>git annex unused
+	unused . (checking for unused data...) (checking master...) 
+	  Some annexed data is no longer used by any files:
+	    NUMBER  KEY
+	    1       SHA256E-s30--11de88d41da5962620f4a0590a577710e067d72e0f24220c4a4d2e81d594388a
+	  (To see where this data was previously used, run: git annex whereused --historical --unused
+	  
+	  To remove unwanted data: git-annex dropunused NUMBER
+	  
+	ok
+	joey@darkstar:~/tmp/a1>cd ..
+	joey@darkstar:~/tmp>git clone a1 a2
+	Cloning into 'a2'...
+	done.
+	joey@darkstar:~/tmp>cd a1
+	joey@darkstar:~/tmp/a1>git remote add a2 ../a2
+	joey@darkstar:~/tmp/a1>git annex move --unused --to a2
+	move SHA256E-s30--11de88d41da5962620f4a0590a577710e067d72e0f24220c4a4d2e81d594388a (to a2...) 
+	ok
+
+You did say it's not moving "some files" which suggests maybe it is moving
+other ones? Do you see it move any unused files at all?
+
+Do other commands that use the same --unused option work? Eg, does 
+`git annex whereis --unused` list them?
+
+The only way I can reproduce this behavior is if the remote has
+the same uuid as the current repository. Then any move is a no-op
+and it avoids operating on the files at all, the same as your output shows.
+So it seems possible that could be your real problem.
+"""]]
diff --git a/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_4_023fb25740f8363f8e72c12f020aa0f4._comment b/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_4_023fb25740f8363f8e72c12f020aa0f4._comment
new file mode 100644
index 0000000000..35b861e00e
--- /dev/null
+++ b/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_4_023fb25740f8363f8e72c12f020aa0f4._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="mike@2d6d71f56ce2a992244350475251df87c26fe351"
+ nickname="mike"
+ avatar="http://cdn.libravatar.org/avatar/183fa439752e2f0c6f39ede658d81050"
+ subject="comment 4"
+ date="2021-09-22T21:18:10Z"
+ content="""
+> You did say it's not moving \"some files\" which suggests maybe it is moving other ones? Do you see it move any unused files at all?
+                                                                                                                        
+It's moving most of it, just not all of them!                                                                           
+                                                                                                                        
+> Do other commands that use the same --unused option work? Eg, does git annex whereis --unused list them?              
+                                                                                                                        
+`git annex whereis --unused` lists the files. `git annex copy --unused -t bims` OTOH does not do anything. I also tried `git annex drop --unused --in=bims` in an attempt to emulate `git annex move --unused -t bims`, but this also does not do anything.                                                                                                            
+                                                                                                                        
+~~~                                                                                                                     
+% git annex whereis --unused                                                                                            
+whereis SHA256E-s24643--167c39a6ca9aacb7d4a111ce58cb65405e9f43e0b0f686108fbbaf201e0561aa.jpg (2 copies)                 
+  ▹‧87f95204-e2d7-41bc-bf24-29c43c4a95d4 -- orange@leguin:~/Calibre Library [here]                                      
+   ▹994901a8-670e-403e-9a72-aff9ce07556a -- bims:/srv/annex/Calibre Library.git [bims]                                  
+[... more files ...]                                                                                                    
+~~~                                                                                                                     
+                                                                                                                        
+> The only way I can reproduce this behavior is if the remote has the same uuid                                         
+> as the current repository. Then any move is a no-op and it avoids operating on                                        
+> the files at all, the same as your output shows. So it seems possible that                                            
+> could be your real problem.                                                                                           
+                                                                                                                        
+I don't think that's the issue: If you look above, `here` and `bims` have different UUIDs. (I also notice the files are already on the `bims` remote.)              
+"""]]
diff --git a/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_5_85ef3d6a4f2e67f16ee4bd30e58ef4fc._comment b/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_5_85ef3d6a4f2e67f16ee4bd30e58ef4fc._comment
new file mode 100644
index 0000000000..687ed85429
--- /dev/null
+++ b/doc/bugs/git_annex_move_--unused_not_moving_some_files/comment_5_85ef3d6a4f2e67f16ee4bd30e58ef4fc._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-09-27T16:20:19Z"
+ content="""
+Well it's not surprising that `git annex copy -t bims` does nothing when
+the files are in the remote. Although it would normally display 
+each unused key and just say "ok" when it verifies that the remote has the
+content.
+
+But move and drop doing nothing while whereis does is strange. It
+must not be a problem with getting the list of unused keys, since whereis
+works.
+
+You showed `git annex move` not displaying any output, which is what's
+really weird. Does `git annex drop --unused --in bims` display any output?
+What about `git annex copy -t bims`?
+"""]]
diff --git a/doc/bugs/git_annex_push_fails_on_Windows.mdwn b/doc/bugs/git_annex_push_fails_on_Windows.mdwn
new file mode 100644
index 0000000000..21a7d7c50d
--- /dev/null
+++ b/doc/bugs/git_annex_push_fails_on_Windows.mdwn
@@ -0,0 +1,107 @@
+### Please describe the problem.
+
+After adding a directory special remote to a git annex repository, the git annex push push-win-remote fails with the following error:
+
+Not updating export to push-win-remote because adjusted/main(unlocked) does not exist. (As configured by remote.push-win-remote.annex-tracking-branch)
+
+The problem does *not* occur on Linux or macOS.
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+mkdir push-win-repo
+mkdir push-win-rmt
+cd push-win-repo
+git init --initial-branch main
+git annex init push-win-repository
+git annex config --set annex.largefiles include=*.xtx
+echo "push test file" >> push-test.xtx
+git annex add .
+git commit -m "add push test file"
+git annex initremote push-win-remote type=directory directory=../push-win-rmt autoenable=true encryption=none exporttree=yes importtree=yes
+git config remote.push-win-remote.annex-tracking-branch adjusted/main(unlocked)
+git annex group push-win-remote manual
+git annex wanted push-win-remote include=*.xtx
+git annex push push-win-remote
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+* git-annex version: 10.20230803-gd467c70ef7
+* git version 2.41.0.windows.2
+* OS Name:                   Microsoft Windows 10 Pro
+* OS Version:                10.0.19045 N/A Build 19045
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+C:\win-push-bug>mkdir push-win-repo
+
+C:\win-push-bug>mkdir push-win-rmt
+
+C:\win-push-bug>cd push-win-repo
+
+C:\win-push-bug\push-win-repo>git init --initial-branch main
+Initialized empty Git repository in C:/win-push-bug/push-win-repo/.git/
+
+C:\win-push-bug\push-win-repo>git annex init push-win-repository
+init push-win-repository
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Switched to branch 'adjusted/main(unlocked)'
+ok
+(recording state in git...)
+
+C:\win-push-bug\push-win-repo>git annex config --set annex.largefiles include=*.xtx
+annex.largefiles include=*.xtx ok
+(recording state in git...)
+
+C:\win-push-bug\push-win-repo>echo "push test file"  1>>push-test.xtx
+
+C:\win-push-bug\push-win-repo>git annex add .
+add push-test.xtx
+ok
+(recording state in git...)
+
+C:\win-push-bug\push-win-repo>git commit -m "add push test file"
+[adjusted/main(unlocked) f3262a2] add push test file
+ 1 file changed, 1 insertion(+)
+ create mode 100644 push-test.xtx
+
+C:\win-push-bug\push-win-repo>git annex initremote push-win-remote type=directory directory=../push-win-rmt autoenable=true encryption=none exporttree=yes importtree=yes
+initremote push-win-remote ok
+(recording state in git...)
+
+C:\win-push-bug\push-win-repo>git config remote.push-win-remote.annex-tracking-branch adjusted/main(unlocked)
+
+C:\win-push-bug\push-win-repo>git annex group push-win-remote manual
+group push-win-remote ok
+(recording state in git...)
+
+C:\win-push-bug\push-win-repo>git annex wanted push-win-remote include=*.xtx
+wanted push-win-remote ok
+(recording state in git...)
+
+C:\win-push-bug\push-win-repo>git annex push push-win-remote
+
+  Not updating export to push-win-remote because adjusted/main(unlocked) does not exist. (As configured by remote.push-win-remote.annex-tracking-branch)
+
+C:\win-push-bug\push-win-repo>
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes. I am developing the easy-git-annex api.
+
+> [[fixed|done]] --[[Joey]] 
diff --git a/doc/bugs/git_annex_push_fails_on_Windows/comment_1_a7866c2131df8132e9aecebda085294c._comment b/doc/bugs/git_annex_push_fails_on_Windows/comment_1_a7866c2131df8132e9aecebda085294c._comment
new file mode 100644
index 0000000000..bf46c03f93
--- /dev/null
+++ b/doc/bugs/git_annex_push_fails_on_Windows/comment_1_a7866c2131df8132e9aecebda085294c._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="jstritch"
+ avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
+ subject="git annex pull is also broken"
+ date="2023-09-09T14:49:35Z"
+ content="""
+If I put the same file in the remote under the name pull-test.xtx and invoke the command git annex pull push-win-remote, git annex outputs:
+
+list push-win-remote ok
+
+import push-win-remote pull-test.xtx
+
+ok
+
+update refs/remotes/push-win-remote/adjusted/main(unlocked) ok
+
+(recording state in git...)
+
+But the file is not present in the repository.
+"""]]
diff --git a/doc/bugs/git_annex_push_fails_on_Windows/comment_2_d5c9fd2acdd5b320563a708889e82852._comment b/doc/bugs/git_annex_push_fails_on_Windows/comment_2_d5c9fd2acdd5b320563a708889e82852._comment
new file mode 100644
index 0000000000..49c8b772ac
--- /dev/null
+++ b/doc/bugs/git_annex_push_fails_on_Windows/comment_2_d5c9fd2acdd5b320563a708889e82852._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-09-11T17:23:12Z"
+ content="""
+The same behavior can be observed on linux. I just ran `git annex adjust
+--unlock` after committing to get into the same state as on Windows.
+
+It's actually not supported to set annex-tracking-branch to an adjusted
+branch. Instead, you ought to set:
+
+	git config remote.push-win-remote.annex-tracking-branch main
+
+When pulling a new file, as in comment #1, that results in the change
+getting merged into main, and then the adjusted branch is automatically
+updated as well.
+
+When pushing a newly added file, I first had to run 
+`git-annex adjust --unlock` in order to update main. That was a 
+bug in `git-annex push`; it ought to update main for you in this case;
+it already does when pushing to a regular git remote. Fixed that.
+
+The "Not updating export to push-win-remote because adjusted/main(unlocked)
+does not exist" message is misleading. I've improved that to be 
+"Not updating export to push-win-remote because tracking branch name is not valid"
+which at least hints in the right direction.
+"""]]
diff --git a/doc/bugs/git_annex_push_fails_on_Windows/comment_3_fe3818a184e723f86d094253461d8f44._comment b/doc/bugs/git_annex_push_fails_on_Windows/comment_3_fe3818a184e723f86d094253461d8f44._comment
new file mode 100644
index 0000000000..5b2387b8c7
--- /dev/null
+++ b/doc/bugs/git_annex_push_fails_on_Windows/comment_3_fe3818a184e723f86d094253461d8f44._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jstritch"
+ avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
+ subject="comment 3"
+ date="2023-09-12T16:36:26Z"
+ content="""
+Thanks!
+"""]]
diff --git a/doc/bugs/git_annex_repair_failed__58___missing_objects.mdwn b/doc/bugs/git_annex_repair_failed__58___missing_objects.mdwn
new file mode 100644
index 0000000000..687a81e903
--- /dev/null
+++ b/doc/bugs/git_annex_repair_failed__58___missing_objects.mdwn
@@ -0,0 +1,48 @@
+### Please describe the problem.
+
+Git annex finds problems with the repository after only adding and syncing a single empty file to the repository.
+
+### What steps will reproduce the problem?
+
+* Create one repository each on devices `A` and `B` via webapp
+* Pair with a passphrase via webapp
+* Wait until full sync
+* Make sure `git annex repair` finds no problems
+* Create an empty file `test.sh` on device `A`
+* Wait until both webapps show sync and transfer has completed
+
+Both repositories are now in a bad state.
+
+* `git annex repair` reports error code `repair: 1 failed`, `--force` seems to repair, but the next `git annex repair` always fails again with `repair: 1 failed`
+* This is true for both repositories
+
+
+### What version of git-annex are you using? On what operating system?
+
+`Linux 5.17.3-arch1-1 #1 SMP PREEMPT x86_64 GNU/Linux` device `A`
+
+`Linux 5.17.4-arch1-1 #1 SMP PREEMPT x86_64 GNU/Linux` device `B`
+
+Version provided from package manager:
+
+```
+git-annex version: 10.20220322-g959beeea9
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.11 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+```
+
+
+### Please provide any additional information below.
+
+The bug is very easy to reproduce. This happens in a bigger repository of mine, where I `git annex repair` doesn't seem to do anything. I narrowed it down to this example and I hope it's the same cause.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Using it daily, with small-sized repositories.
+
+> [[fixed|done]] --[[Joey]] 
diff --git a/doc/bugs/git_annex_repair_failed__58___missing_objects/comment_1_9f2166545159890b05ea061e2ab21a4f._comment b/doc/bugs/git_annex_repair_failed__58___missing_objects/comment_1_9f2166545159890b05ea061e2ab21a4f._comment
new file mode 100644
index 0000000000..29fbc25774
--- /dev/null
+++ b/doc/bugs/git_annex_repair_failed__58___missing_objects/comment_1_9f2166545159890b05ea061e2ab21a4f._comment
@@ -0,0 +1,166 @@
+[[!comment format=mdwn
+ username="Albert"
+ avatar="http://cdn.libravatar.org/avatar/79aaf48dabedd7cd96a9117685fbe2cc"
+ subject="Minimal Example"
+ date="2022-04-29T15:14:20Z"
+ content="""
+I have managed to further reduce the setup to generate this bug. No connection to another device necessary.
+
+Steps:
+
+* Create a fresh repository with `git annex webapp`
+* Add an empty file to the repository named `exec.zip`
+
+Now the repository is broken.
+
+```bash
+❯ ls
+exec.zip
+❯ git annex repair
+repair Running git fsck ...
+Fsck found no problems. Checking for broken branches.
+Found problems, attempting repair.
+Some git branches refer to missing objects:
+	refs/annex/last-index
+To force a recovery to a usable state, retry with the --force parameter.
+failed
+repair: 1 failed
+❯ git annex repair --force
+repair Running git fsck ...
+Fsck found no problems. Checking for broken branches.
+Found problems, attempting repair.
+Successfully recovered repository!
+You should run \"git fsck\" to make sure, but it looks like everything was recovered ok.
+ok
+❯ git fsck
+Checking object directories: 100% (256/256), done.
+❯ git annex fsck
+fsck exec.zip (checksum...) ok
+(recording state in git...)
+❯ git annex repair
+repair Running git fsck ...
+Fsck found no problems. Checking for broken branches.
+Found problems, attempting repair.
+Some git branches refer to missing objects:
+	refs/annex/last-index
+To force a recovery to a usable state, retry with the --force parameter.
+failed
+repair: 1 failed
+```
+
+The log shows nothing interesting, as far as errors go.
+
+```bash
+[2022-04-29 16:52:08.770880358] (Utility.Process) process [8244] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2022-04-29 16:52:08.773934773] (Utility.Process) process [8245] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--stage\",\"-z\",\"--\",\".\"]
+[2022-04-29 16:52:08.775028928] (Utility.Process) process [8245] done ExitSuccess
+[2022-04-29 16:52:08.775560498] (Utility.Process) process [8246] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--stage\",\"-z\",\"--\",\".\"]
+[2022-04-29 16:52:08.77720598] (Utility.Process) process [8246] done ExitSuccess
+[2022-04-29 16:52:08.77980743] (Utility.Process) process [8247] chat: nice [\"ionice\",\"-c3\",\"/usr/bin/git-annex\",\"remotedaemon\",\"--foreground\"]
+[2022-04-29 16:52:08.831064871] (NetWatcher) Using running DBUS service org.freedesktop.NetworkManager to monitor network connection events.
+[2022-04-29 16:52:08.83204466] (MountWatcher) Using running DBUS service org.freedesktop.UDisks2 to monitor mount events.
+[2022-04-29 16:52:08.834446186] (Utility.Process) process [8248] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"mincopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+[2022-04-29 16:52:08.835869051] (Utility.Process) process [8248] done ExitSuccess
+[2022-04-29 16:52:08.83662762] (Utility.Process) process [8249] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2022-04-29 16:52:08.836789466] (TransferWatcher) watching for transfers
+[2022-04-29 16:52:08.837846991] (Utility.Process) process [8249] done ExitSuccess
+[2022-04-29 16:52:08.838365064] (Utility.Process) process [8250] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2022-04-29 16:52:08.839508977] (Utility.Process) process [8250] done ExitSuccess
+[2022-04-29 16:52:08.83982672] (Utility.Process) process [8251] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..8d3e39db152fe946720fc814daaa892ea9b5ae56\",\"--pretty=%H\",\"-n1\"]
+[2022-04-29 16:52:08.841105024] (Utility.Process) process [8251] done ExitSuccess
+[2022-04-29 16:52:08.841851852] (Utility.Process) process [8252] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"mincopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+[2022-04-29 16:52:08.843105261] (Utility.Process) process [8252] done ExitSuccess
+[2022-04-29 16:52:08.843428605] (Utility.Process) process [8253] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2022-04-29 16:52:08.844400262] (Utility.Process) process [8253] done ExitSuccess
+[2022-04-29 16:52:08.844653432] (Utility.Process) process [8254] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/adjusted/master(unlocked)\"]
+[2022-04-29 16:52:08.845849783] (Utility.Process) process [8254] done ExitSuccess
+(scanning...) [2022-04-29 16:52:08.848533041] (Merger) watching .git/refs
+[2022-04-29 16:52:08.848937085] (Utility.Process) process [8255] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"-z\",\"--deleted\",\"--\",\".\"]
+[2022-04-29 16:52:08.850610811] (Utility.Process) process [8255] done ExitSuccess
+(started...) 
+[2022-04-29 16:52:08.85076117] (Watcher) watching .
+[2022-04-29 16:52:10.784464555] (TransferScanner) starting scan of [Remote { name =\"bittorrent\" },Remote { name =\"web\" }]
+[2022-04-29 16:52:10.786005379] (Utility.Process) process [8266] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"-z\",\"--cached\",\"--\"]
+[2022-04-29 16:52:10.78835403] (Utility.Process) process [8266] done ExitSuccess
+[2022-04-29 16:52:10.788482208] (TransferScanner) finished scan of [Remote { name =\"bittorrent\" },Remote { name =\"web\" }]
+[2022-04-29 16:52:38.780947807] (Utility.Process) process [8244] done ExitSuccess
+[2022-04-29 16:52:48.957820025] (Utility.Process) process [8373] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2022-04-29 16:52:48.961668832] (Utility.Process) process [8374] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"check-ignore\",\"-z\",\"--stdin\",\"--verbose\",\"--non-matching\"]
+[2022-04-29 16:52:48.96311124] (Watcher) add exec.zip
+[2022-04-29 16:52:48.963830706] (Watcher) add exec.zip
+[2022-04-29 16:52:48.974374383] (Utility.Process) process [8380] read: lsof [\"-F0can\",\"+d\",\".git/annex/watchtmp/\"]
+lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
+      Output information may be incomplete.
+[2022-04-29 16:52:49.063916257] (Utility.Process) process [8380] done ExitFailure 1
+[2022-04-29 16:52:49.0643913] (Utility.Process) process [8391] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.largefiles\",\"annex.numcopies\",\"annex.mincopies\",\"--\"]
+add exec.zip [2022-04-29 16:52:49.067319092] (Utility.Process) process [8392] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"filter.annex.smudge=\",\"-c\",\"filter.annex.clean=\",\"-c\",\"filter.annex.process=\",\"write-tree\"]
+[2022-04-29 16:52:49.068674137] (Utility.Process) process [8392] done ExitSuccess
+[2022-04-29 16:52:49.069809159] (Utility.Process) process [8393] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/annex/last-index\"]
+[2022-04-29 16:52:49.071868139] (Utility.Process) process [8393] done ExitFailure 1
+[2022-04-29 16:52:49.086327935] (Utility.Process) process [8394] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2022-04-29 16:52:49.089453108] (Utility.Process) process [8395] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+ok
+[2022-04-29 16:52:49.091145891] (Committer) committing 1 changes
+(recording state in git...)
+[2022-04-29 16:52:49.091604661] (Utility.Process) process [8396] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+[2022-04-29 16:52:49.093194636] (Utility.Process) process [8396] done ExitSuccess
+[2022-04-29 16:52:49.093559897] (Utility.Process) process [8397] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2022-04-29 16:52:49.094699948] (Utility.Process) process [8397] done ExitSuccess
+[2022-04-29 16:52:49.095498501] (Utility.Process) process [8398] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/adjusted/master(unlocked)\"]
+[2022-04-29 16:52:49.096545809] (Utility.Process) process [8398] done ExitSuccess
+[2022-04-29 16:52:49.096818906] (Utility.Process) process [8399] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2022-04-29 16:52:49.098254637] (Utility.Process) process [8399] done ExitSuccess
+[2022-04-29 16:52:49.099010966] (Utility.Process) process [8400] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"rev-parse\",\"--verify\",\"--quiet\",\"fe77efb32c94158eff6697b39cb344f45584102a:\"]
+[2022-04-29 16:52:49.100061557] (Utility.Process) process [8400] done ExitSuccess
+[2022-04-29 16:52:49.100317245] (Utility.Process) process [8401] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"5234be1a3bf0adce43729baa1497a560b7cbebd7\",\"--no-gpg-sign\",\"-p\",\"fe77efb32c94158eff6697b39cb344f45584102a\"]
+[2022-04-29 16:52:49.101685356] (Utility.Process) process [8401] done ExitSuccess
+[2022-04-29 16:52:49.102371807] (Utility.Process) process [8402] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/adjusted/master(unlocked)\",\"4be985a06abd216c02f2fdd03ca40a85807bb96b\"]
+[2022-04-29 16:52:49.103729957] (Utility.Process) process [8402] done ExitSuccess
+[2022-04-29 16:52:49.10456259] (Utility.Process) process [8403] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/basis/adjusted/master(unlocked)\"]
+[2022-04-29 16:52:49.105752856] (Utility.Process) process [8403] done ExitSuccess
+[2022-04-29 16:52:49.106040828] (Utility.Process) process [8404] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2022-04-29 16:52:49.107590591] (Utility.Process) process [8405] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/basis/adjusted/master(unlocked)..refs/heads/adjusted/master(unlocked)\",\"--pretty=%H\",\"--reverse\"]
+[2022-04-29 16:52:49.108889132] (Utility.Process) process [8405] done ExitSuccess
+[2022-04-29 16:52:49.110083161] (Utility.Process) process [8406] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"--no-abbrev\",\"--pretty=\",\"--raw\",\"4be985a06abd216c02f2fdd03ca40a85807bb96b\"]
+[2022-04-29 16:52:49.113120499] (Utility.Process) process [8407] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"mktree\",\"--batch\",\"-z\"]
+[2022-04-29 16:52:49.113389197] (Utility.Process) process [8408] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-tree\",\"--full-tree\",\"-z\",\"-r\",\"-t\",\"--\",\"c57819725af0809e4a82dd79efc9cb398e9b5f5e\"]
+[2022-04-29 16:52:49.115008909] (Utility.Process) process [8408] done ExitSuccess
+[2022-04-29 16:52:49.115220429] (Utility.Process) process [8407] done ExitSuccess
+[2022-04-29 16:52:49.115274136] (Utility.Process) process [8406] done ExitSuccess
+[2022-04-29 16:52:49.116504243] (Utility.Process) process [8409] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"1ea671eeef97631e93e128bf3ebe8a6d26ea5c26\",\"--no-gpg-sign\",\"-p\",\"c57819725af0809e4a82dd79efc9cb398e9b5f5e\"]
+[2022-04-29 16:52:49.118748333] (Utility.Process) process [8409] done ExitSuccess
+[2022-04-29 16:52:49.119085462] (Utility.Process) process [8410] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/basis/adjusted/master(unlocked)\",\"c5dc2761bf626f373d382e2e137a030d54cb830f\"]
+[2022-04-29 16:52:49.120787007] (Utility.Process) process [8410] done ExitSuccess
+[2022-04-29 16:52:49.121084941] (Utility.Process) process [8411] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/master\",\"c5dc2761bf626f373d382e2e137a030d54cb830f\"]
+[2022-04-29 16:52:49.122396315] (Utility.Process) process [8411] done ExitSuccess
+[2022-04-29 16:52:49.123421452] (Utility.Process) process [8412] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"5234be1a3bf0adce43729baa1497a560b7cbebd7\",\"--no-gpg-sign\",\"-p\",\"c5dc2761bf626f373d382e2e137a030d54cb830f\"]
+[2022-04-29 16:52:49.125285001] (Utility.Process) process [8412] done ExitSuccess
+[2022-04-29 16:52:49.125594743] (Utility.Process) process [8413] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"-m\",\"rebasing adjusted branch on top of updated original branch\",\"refs/heads/adjusted/master(unlocked)\",\"5e2aa046891e88e6272556602fd783df737dd96b\"]
+[2022-04-29 16:52:49.127414941] (Utility.Process) process [8413] done ExitSuccess
+[2022-04-29 16:52:49.127755666] (Utility.Process) process [8414] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"branch\",\"-f\",\"synced/master\",\"refs/heads/master\"]
+[2022-04-29 16:52:49.129567194] (Utility.Process) process [8414] done ExitSuccess
+[2022-04-29 16:52:49.130874993] (Utility.Process) process [8415] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+[2022-04-29 16:52:49.13224422] (Utility.Process) process [8415] done ExitSuccess
+[2022-04-29 16:52:49.132752938] (Utility.Process) process [8416] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2022-04-29 16:52:49.134298542] (Utility.Process) process [8416] done ExitSuccess
+(recording state in git...)
+[2022-04-29 16:52:49.134910162] (Utility.Process) process [8417] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2022-04-29 16:52:49.136629434] (Utility.Process) process [8417] done ExitSuccess
+[2022-04-29 16:52:49.137062879] (Utility.Process) process [8418] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"fdebaeafd3e1ebbc439d1a74184ff97e53071472\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"]
+[2022-04-29 16:52:49.138527773] (Utility.Process) process [8418] done ExitSuccess
+[2022-04-29 16:52:49.13896562] (Utility.Process) process [8419] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"127321afb17f5281528fc71d54c9166ce177596c\"]
+[2022-04-29 16:52:49.140314152] (Utility.Process) process [8419] done ExitSuccess
+[2022-04-29 16:52:49.143236655] (Utility.Process) process [8420] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/master..refs/heads/synced/master\",\"--pretty=%H\",\"-n1\"]
+[2022-04-29 16:52:49.144619131] (Utility.Process) process [8420] done ExitSuccess
+[2022-04-29 16:52:49.144959688] (Utility.Process) process [8421] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2022-04-29 16:52:49.146275708] (Utility.Process) process [8421] done ExitSuccess
+[2022-04-29 16:52:49.146554643] (Utility.Process) process [8422] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2022-04-29 16:52:49.147803214] (Utility.Process) process [8422] done ExitSuccess
+[2022-04-29 16:52:49.148107921] (Utility.Process) process [8423] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..127321afb17f5281528fc71d54c9166ce177596c\",\"--pretty=%H\",\"-n1\"]
+[2022-04-29 16:52:49.149518193] (Utility.Process) process [8423] done ExitSuccess
+[2022-04-29 16:53:08.845070487] (Utility.Process) process [8451] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"mincopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+[2022-04-29 16:53:08.848424429] (Utility.Process) process [8451] done ExitSuccess
+```
+
+Why causes a single file `git annex repair` to fail?
+"""]]
diff --git a/doc/bugs/git_annex_repair_failed__58___missing_objects/comment_2_7571de4a3ab7030a877fa198fe4810b1._comment b/doc/bugs/git_annex_repair_failed__58___missing_objects/comment_2_7571de4a3ab7030a877fa198fe4810b1._comment
new file mode 100644
index 0000000000..c9d2685b28
--- /dev/null
+++ b/doc/bugs/git_annex_repair_failed__58___missing_objects/comment_2_7571de4a3ab7030a877fa198fe4810b1._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="Albert"
+ avatar="http://cdn.libravatar.org/avatar/79aaf48dabedd7cd96a9117685fbe2cc"
+ subject="Reproducible Example"
+ date="2022-04-29T15:57:34Z"
+ content="""
+Fast reproducible example:
+
+```bash
+❯ mkdir annextest && cd annextest
+❯ git init
+Initialized empty Git repository in ./annextest/.git/
+❯ git annex init
+init  ok
+(recording state in git...)
+❯ echo \"some data\" > testfile
+❯ git status
+On branch master
+
+No commits yet
+
+Untracked files:
+  (use \"git add <file>...\" to include in what will be committed)
+	testfile
+
+nothing added to commit but untracked files present (use \"git add\" to track)
+❯ git annex add .
+add testfile 
+ok                                
+(recording state in git...)
+❯ git annex sync --content
+commit 
+[master (root-commit) d5dfa14] git-annex in user@dev:~/annextest
+ 1 file changed, 1 insertion(+)
+ create mode 120000 testfile
+ok
+❯ git annex repair
+repair Running git fsck ...
+Fsck found no problems. Checking for broken branches.
+Found problems, attempting repair.
+Some git branches refer to missing objects:
+	refs/annex/last-index
+To force a recovery to a usable state, retry with the --force parameter.
+failed
+repair: 1 failed
+```
+
+"""]]
diff --git a/doc/bugs/git_annex_repair_failed__58___missing_objects/comment_3_317bee33fe675a5abb6fe65540a33d25._comment b/doc/bugs/git_annex_repair_failed__58___missing_objects/comment_3_317bee33fe675a5abb6fe65540a33d25._comment
new file mode 100644
index 0000000000..3e971faa3b
--- /dev/null
+++ b/doc/bugs/git_annex_repair_failed__58___missing_objects/comment_3_317bee33fe675a5abb6fe65540a33d25._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-05-04T15:06:31Z"
+ content="""
+Thank you, your "Reproducible Example" worked for me to reproduce it!
+Great work finding this and tracking down an easy way to reproduce it.
+
+So the root of the problem is refs/annex/last-index,
+which contains a tree object, not a commit object. That is unusual for a ref,
+but git-annex has a good reason to record a tree's ref there. 
+
+Fixed
+"""]]
diff --git a/doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress.mdwn b/doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress.mdwn
new file mode 100644
index 0000000000..87ffd321b3
--- /dev/null
+++ b/doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress.mdwn
@@ -0,0 +1,33 @@
+### Please describe the problem.
+
+git annex reports progress the same when when stdout is a terminal or not.
+This is fine when stdout is actually a terminal, but produce lots of annoying characters when stdout is just a regular file.
+This is problematic mostly when running git-annex with cron.
+
+### What steps will reproduce the problem?
+
+    git annex copy --to myrepo > log
+
+then look at the content of `log`.
+
+### What version of git-annex are you using? On what operating system?
+
+git annex 5.20151019
+
+Mac OS X 10.10.5
+
+Ubuntu 14.04
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress/comment_1_6c7f745ee77e9b7502cb13d3babf211b._comment b/doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress/comment_1_6c7f745ee77e9b7502cb13d3babf211b._comment
new file mode 100644
index 0000000000..94307fec01
--- /dev/null
+++ b/doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress/comment_1_6c7f745ee77e9b7502cb13d3babf211b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-11-30T19:01:16Z"
+ content="""
+If you have a recent version of git-annex that's built with the
+ConcurrentOutput flag, pass -J1 and it will do what you want. 
+"""]]
diff --git a/doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress/comment_2_e2139a3d1d06772d06992a38140e51d3._comment b/doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress/comment_2_e2139a3d1d06772d06992a38140e51d3._comment
new file mode 100644
index 0000000000..a98761ecb6
--- /dev/null
+++ b/doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress/comment_2_e2139a3d1d06772d06992a38140e51d3._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-09-22T19:56:06Z"
+ content="""
+Nowadays, -J1 does not have that behavior but eg -J2 still does. But I'd
+probably just use --quiet in my cron job, or for that matter use `chronic`.
+
+I do think it would be better for git-annex to be consistent and not
+display progress when not at a tty. However, the work required to do that
+is nontrivial. A lot of commands git-annex runs can themselves display
+progress. And all that nontrivial work has in fact been done in order to
+support -J. It's just not enabled by default or for -J1.
+
+The reason git-annex has not yet switched to the concurrent output by
+default is that it assumes a VT100 compatable terminal.
+"""]]
diff --git a/doc/bugs/git_annex_still_deleting_content_when_merging.mdwn b/doc/bugs/git_annex_still_deleting_content_when_merging.mdwn
new file mode 100644
index 0000000000..872b699c0d
--- /dev/null
+++ b/doc/bugs/git_annex_still_deleting_content_when_merging.mdwn
@@ -0,0 +1,97 @@
+**Premise:**
+
+I've had this problem before 5.20140709-gc75193e and when the [ugly bug](http://git-annex.branchable.com/devblog/day_193-194__ugly_bug/) was discovered and fixed, I updated and thought it was gone.
+Yet, I'm still experiencing a content removal bug, so it might be something different altogether.
+I should also add that I don't know much about git log history and git-annex inner workings. I might need some help with finding the necessary information for debugging.
+
+**Bug description:**
+
+Two local computers, running Ubuntu-14.04 and Fedora-20 respectively, are paired through the assistant and functional with git annex 5.20140709. In direct mode. Most of the time, everything seems to work fine. Sometimes, *Computer A* will modify one file in its repository while *B* is offline. When *B* comes back online both repositories will lose their copy of the modified file (I'm not sure whether this also happens when they're both online when the change happens; it doesn't look like it anyway). The rest of the data in the repository is intact. This does not happen every time and I haven't been able to reproduce it consistently. Since 5.20140709 came out, it happened 2 or 3 times.
+
+Looking at 'git log --stat' in *B*:
+
+    commit d9eb9e94a39
+    Author: COMPUTER B
+    Date:   Thu Jul 17 18:17:16 2014 +0200
+      shared.skg | 1 -
+      1 file changed, 1 deletion(-)
+
+    commit 6fa27f08492
+    Author: COMPUTER A
+    Date:   Thu Jul 17 18:17:14 2014 +0200
+      shared.skg | 1 +
+      1 file changed, 1 insertion(+)
+
+    commit d25cc793739
+    Author: COMPUTER A
+    Date:   Thu Jul 17 18:17:12 2014 +0200
+      shared.skg | 1 -
+      1 file changed, 1 deletion(-)
+
+A change is apparently deleting and rewriting the whole file (maybe that's normal because it's a binary (encrypted) file?). The third most recent deletion is probably the one that shouldn't happen.
+
+Reverting "d9eb9e94a39" will only recover a placeholder, not really the original file. I can get the content back by going through *git annex unused* with *git log -S'key'*, then going to indirect mode, and then using *addunused*. This can only be done in the repository that changed the file in the first place (repo A), as the other repository only has the older version of the file in its unused list. This probably means that the change did not propagate before the file was deleted.
+
+**daemon.log transcript**
+
+[[!format sh """
+
+[2014-07-17 18:13:17 CEST] main: starting assistant version 5.20140709-gc75193e
+[2014-07-17 18:13:17 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2014-07-17 18:13:55 CEST] TransferScanner: Syncing with asus.local_sincro 
+(scanning...) [2014-07-17 18:13:55 CEST] Watcher: Performing startup scan
+p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so: cannot open shared object file: No such file or directory
+p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory
+(started...) p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so: cannot open shared object file: No such file or directory
+p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory
+gpg: Signature made gio 17 lug 2014 18:02:09 CEST using DSA key ID 89C809CB
+gpg: /tmp/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>"
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2014-07-17 18:13:58 CEST] Upgrader: An upgrade of git-annex is available.  (version 5.20140716)
+Everything up-to-date
+git-annex-shell: key is already present in annex
+rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0]
+
+########## SYNCING STARTS HERE ###########
+
+[2014-07-17 18:17:12 CEST] RemoteControl: Syncing with asus.local_sincro 
+From ssh://git-annex-asus.local-USER-A_22_sincro/~/sincro
+   51815ea..d25cc79  annex/direct/master -> asus.local_sincro/annex/direct/master
+   0391880..49efa5f  git-annex  -> asus.local_sincro/git-annex
+   51815ea..d25cc79  master     -> asus.local_sincro/master
+   51815ea..d25cc79  synced/master -> asus.local_sincro/synced/master
+[2014-07-17 18:17:15 CEST] RemoteControl: Syncing with asus.local_sincro 
+Automatic merge went well; stopped before committing as requested
+Removing shared.skg
+From ssh://git-annex-asus.local-USER-A_22_sincro/~/sincro
+   d25cc79..6fa27f0  annex/direct/master -> asus.local_sincro/annex/direct/master
+   d25cc79..6fa27f0  master     -> asus.local_sincro/master
+   d25cc79..6fa27f0  synced/master -> asus.local_sincro/synced/master
+[2014-07-17 18:17:16 CEST] Committer: Committing changes to git
+[2014-07-17 18:17:16 CEST] Pusher: Syncing with asus.local_sincro 
+To ssh://USER-A@git-annex-asus.local-USER-A_22_sincro/~/sincro/
+   0391880..8d1c927  git-annex -> synced/git-annex
+   6fa27f0..d9eb9e9  annex/direct/master -> synced/master
+[2014-07-17 18:17:17 CEST] RemoteControl: Syncing with asus.local_sincro 
+From ssh://git-annex-asus.local-USER-A_22_sincro/~/sincro
+   49efa5f..e328661  git-annex  -> asus.local_sincro/git-annex
+[2014-07-17 18:17:20 CEST] RemoteControl: Syncing with asus.local_sincro 
+From ssh://git-annex-asus.local-USER-A_22_sincro/~/sincro
+   6fa27f0..d9eb9e9  annex/direct/master -> asus.local_sincro/annex/direct/master
+   e328661..32e44ce  git-annex  -> asus.local_sincro/git-annex
+
+# End of transcript or log.
+"""]]
+
+> [[Deleted_files_during_merge]] seems like much the same problem.
+> In both that bug report and this one, the file that gets deleted on B was
+> earlier modifed on A. There is a small difference, in that in this bug
+> report, A made 2 commits, first deleting the file and then adding back a
+> new version. In the other bug report, A made just 1 commit, changing the
+> file. --[[Joey]]
+
+[[!meta title="Assistant deleted file when merging"]]
diff --git a/doc/bugs/git_annex_still_deleting_content_when_merging/comment_1_cb51e25c5e1656dcbb73b3ff680341f0._comment b/doc/bugs/git_annex_still_deleting_content_when_merging/comment_1_cb51e25c5e1656dcbb73b3ff680341f0._comment
new file mode 100644
index 0000000000..76db9bcc55
--- /dev/null
+++ b/doc/bugs/git_annex_still_deleting_content_when_merging/comment_1_cb51e25c5e1656dcbb73b3ff680341f0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-21T17:37:22Z"
+ content="""
+Well, this is definitely a different bug or issue than the \"ugly bug\". In particular, it only affects a single file. Also, based on the commits, this may not be occuring in a merge commit at all (although I am not sure; I am not familiar with the log syntax shown).
+
+AFAICS, the problem occurs on machine B. Which machine is the transcript from?
+
+The \"Removing shared.skg\" is a good clue. This seems to be printed by `git`, in merge-recursive.c's `process_entry`. What is puzzling to me is that it's printed after the \"Automatic merge went well; stopped before committing as requested\", which  AFAICS is printed out by git last thing. Is this \"Removing\" message then printed out by another git command?
+
+Enabling debug logging would probably help a lot, to narrow that down the next time this occurs.
+"""]]
diff --git a/doc/bugs/git_annex_still_deleting_content_when_merging/comment_2_bbbcce7fc5f34d733126c42be8ec0a1d._comment b/doc/bugs/git_annex_still_deleting_content_when_merging/comment_2_bbbcce7fc5f34d733126c42be8ec0a1d._comment
new file mode 100644
index 0000000000..b8748318ef
--- /dev/null
+++ b/doc/bugs/git_annex_still_deleting_content_when_merging/comment_2_bbbcce7fc5f34d733126c42be8ec0a1d._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmMLeU-zCzx2mc5pL2XT8a1UNkQwHAHjg8"
+ nickname="daniele"
+ subject="comment 2"
+ date="2014-07-22T01:47:29Z"
+ content="""
+> I am not familiar with the log syntax shown
+
+You mean the \"git log --stat\" part? Which git command would yield the most helpful syntax in this case?
+
+> AFAICS, the problem occurs on machine B. Which machine is the transcript from?
+
+Sorry I forgot to mention it: yes, it's from machine B.
+
+> Is this \"Removing\" message then printed out by another git command?
+
+Sorry I have no clue here. I didn't issue any git command from the terminal (nor did the user on computer A) if that was part of the question. It was all done in automatic.
+
+> Enabling debug logging would probably help a lot, to narrow that down the next time this occurs.
+
+Will do. I'll set 'annex.debug' to true in .git/config. Sadly, computer A is (a laptop) on vacation at the moment (well outside the local network), so I'll have to wait a couple of weeks to get back to debugging this. I'll have the logs with debug enabled when it happens again.
+
+Thanks again for your support and for developing git-annex.
+
+
+
+"""]]
diff --git a/doc/bugs/git_annex_still_deleting_content_when_merging/comment_3_f31a73e0e2c43f6a7f158455eadaa56c._comment b/doc/bugs/git_annex_still_deleting_content_when_merging/comment_3_f31a73e0e2c43f6a7f158455eadaa56c._comment
new file mode 100644
index 0000000000..04621df63b
--- /dev/null
+++ b/doc/bugs/git_annex_still_deleting_content_when_merging/comment_3_f31a73e0e2c43f6a7f158455eadaa56c._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmMLeU-zCzx2mc5pL2XT8a1UNkQwHAHjg8"
+ nickname="daniele"
+ subject="comment 3"
+ date="2014-07-22T02:10:14Z"
+ content="""
+I was unsure as to what git-log command would best describe the problematic commits but in the meantime I did a:
+    
+     git log --graph --decorate=full --full-diff
+
+These are the only three commits of that afternoon (the surrounding history is from completely different hours and very likely unrelated, so it wasn't posted)
+
+    * commit d9eb9e94a3973598a847a5bdab1b65e459c1588a
+    | Author: COMPUTER B
+    | Date:   Thu Jul 17 18:17:16 2014 +0200
+    |  
+    * commit 6fa27f0849227c490ac4d4d62ca86e4befe5121e
+    | Author: COMPUTER A
+    | Date:   Thu Jul 17 18:17:14 2014 +0200
+    |  
+    * commit d25cc793739573057e475c92c8d37ce4ecc7bc9b
+    | Author: COMPUTER A
+    | Date:   Thu Jul 17 18:17:12 2014 +0200
+
+
+It's a straight line (fast forward?), I don't see any merging either. Is this normal? Shouldn't a change in Repo A bring a merge in Repo B (where everything stayed the same) when things are synchronized? I don't fully understand how annex syncs happen so don't mind this question if it's all normal.
+"""]]
diff --git a/doc/bugs/git_annex_sync_remove_all_recently_added_files.mdwn b/doc/bugs/git_annex_sync_remove_all_recently_added_files.mdwn
new file mode 100644
index 0000000000..62d1b88203
--- /dev/null
+++ b/doc/bugs/git_annex_sync_remove_all_recently_added_files.mdwn
@@ -0,0 +1,61 @@
+### Please describe the problem.
+
+
+
+since a bit of time i have a strange probleme. My git annex environement look like this :
+
+A E  
+|\ /  
+| C--D  
+|/ \  
+B F.....G  
+
+the dot point because G is an external drive and can be plug anywhere else. let's say my last comit is **db1a9a** If i add some file on the repo from G and sync point to point like : i'm in G : git annex sync F a new commit is created say **61dacd** go F git annex sync D go D git annex sync E ...etc
+
+at some point my commit **61dacd** becomme the parent of a new commit i dono the source ... let's say **4fcdae**
+
+in git log i found
+
+commit 4fcdae... (HEAD -> master, B/synced/ma ster, B/master, C/synced/master, C/master, synced/master)
+
+and that commit just undo all the change done by the previous one, indeed :
+
+git diff **4fcdae** **db1a9a** -> nothing
+
+this... force me to play with branch like every time and anoyed me alot. I don't understand what's happening here. Does any one have any clue/insight on what i can do to fix this/investigate ?
+
+All repo are at the commit **db1a9a** before i start...
+
+best regards
+
+
+### What steps will reproduce the problem?
+
+i'm not sur on how i can reproduce it. It happens time to time.
+
+### What version of git-annex are you using? On what operating system?
+
+Ubuntu 18.04.4 LTS -> git-annex version: 6.20180227  
+Ubuntu 14.04.6 LTS -> git-annex version: 5.20140412ubuntu1  
+freebsd 12.1-RELEASE-p3 -> git-annex version: 7.20190626    
+debian 10.4 -> git-annex version: 7.20190129  
+debian 8.11 -> git-annex version: 5.20141125+oops-1+deb8u2  
+Ubuntu 18.04.4 LTS -> git-annex version: 6.20180227  
+
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+nope allways have this weird bug who come to haunt me time to time.
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_1_58faf8b37bb276e6176233d3daa24db9._comment b/doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_1_58faf8b37bb276e6176233d3daa24db9._comment
new file mode 100644
index 0000000000..0b96fe0dda
--- /dev/null
+++ b/doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_1_58faf8b37bb276e6176233d3daa24db9._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-08-06T15:23:48Z"
+ content="""
+Is this repository using an adjusted branch?
+
+Does the problem commit have a commit message like "git-annex automatic
+merge conflict fix"?
+
+I'm asking, because other than those two things, `git annex sync` is 
+really the same as `git merge`, in fact that's what it does.
+
+(It's also a bit of a red flag to me that you're using a mix of git-annex
+versions going back to 6 years old! So some bug fixed in those
+6 years could be affecting you.)
+"""]]
diff --git a/doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_2_a39ce4a60c1dc7817c84f90eac7251a6._comment b/doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_2_a39ce4a60c1dc7817c84f90eac7251a6._comment
new file mode 100644
index 0000000000..8031695d3f
--- /dev/null
+++ b/doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_2_a39ce4a60c1dc7817c84f90eac7251a6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 2"
+ date="2021-05-11T08:50:36Z"
+ content="""
+Similar to [[bugs/OSX\_\_58\_\_\_Pushed_changes_are_autocommited/]], I guess the `receive.denyCurrentBranch` git config could be at play here too.
+"""]]
diff --git a/doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_3_3cb07eabd0e1802dbe477bdc88f647fb._comment b/doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_3_3cb07eabd0e1802dbe477bdc88f647fb._comment
new file mode 100644
index 0000000000..2e2b36dab2
--- /dev/null
+++ b/doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_3_3cb07eabd0e1802dbe477bdc88f647fb._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2021-05-11T09:21:37Z"
+ content="""
+And indeed, I can reproduce it like this:
+
+    mkdir test
+    cd test
+    git init a
+    cd a
+    git checkout -b master
+    git annex init a
+    touch file
+    git annex add .
+    git annex sync
+    git config receive.denyCurrentBranch warn
+    cd ..
+    git clone a b
+    cd b
+    git annex init b
+    git annex sync
+    touch new-file
+    git annex add .
+    git annex sync
+    cd ../a
+    git annex sync
+    cd ../b
+    git annex sync
+    ls
+    # new-file was deleted
+
+So this is definitely a user error. But on the other hand I think that `git annex sync` maybe should only push to the `synced/` branches.
+"""]]
diff --git a/doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_4_65c5f5f34eb8535d244d6075caf57c21._comment b/doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_4_65c5f5f34eb8535d244d6075caf57c21._comment
new file mode 100644
index 0000000000..7849d628d0
--- /dev/null
+++ b/doc/bugs/git_annex_sync_remove_all_recently_added_files/comment_4_65c5f5f34eb8535d244d6075caf57c21._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-05-12T15:19:45Z"
+ content="""
+Sure, if you set receive.denyCurrentBranch that way, you let git update
+the repo's master branch while the index has not been updated. The result
+is the same as if you had run "git rm" on all newly added files. Same
+happens when using regular "git push origin master" as well.
+
+git-annex sync tries to push the master branch because
+
+1. The remote may be a bare repository, and then you certianly *do* want
+   the master branch to be pushed. Note that there is, generally, no way
+   to tell if a given git remote is a bare repository or not.
+2. The user may have some config like receive.denyCurrentBranch=updateInstead
+   which will work fine if the master branch is pushed.
+
+So if the original bug reporter had a setting like
+receive.denyCurrentBranch=warn, then yes it would be user error.
+Unfortunately, they didn't say how they had things configured. I still
+await a followup from them.
+"""]]
diff --git a/doc/bugs/git_annex_test_fails_when_run_through_powershell.mdwn b/doc/bugs/git_annex_test_fails_when_run_through_powershell.mdwn
new file mode 100644
index 0000000000..fd9e2af990
--- /dev/null
+++ b/doc/bugs/git_annex_test_fails_when_run_through_powershell.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+
+When running "git annex test" in a Powershell window, two tests fail (listed in additional details). I am assuming it is because it is using powershell internal commands instead of msys utilities, at least in the case of the "mv" failure. Specifying "mv.exe" instead of just "mv" on Windows should work.
+
+### What steps will reproduce the problem?
+
+Run "git annex test" from the powershell prompt. Two tests fail. All tests pass when run through cmd.
+
+### What version of git-annex are you using? On what operating system?
+
+Windows 7 Enterprise SP1
+Powershell version 4.0
+git version 1.9.5.msysgit.1
+git annex I *think* is 5.20150617, but I don't know for sure.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+addurl failed on file:///ws/wcs-project-new/.t/tmprepo5/myurl
+
+"mv": cannot move `C:\\Users\\duffrw\\LOCALS~1\\Temp\\importtest.0\\import1\\f' to `import1\\f12956.tmp'
+git-annex: MoveFileEx "C:\\Users\\duffrw\\LOCALS~1\\Temp\\importtest.0\\import1\\f" "import1\\f": unsupported operation (The system cannot move the file to a different disk drive.)
+
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/git_annex_test_fails_when_run_through_powershell/comment_1_014466c5da1922d34a498648baeeba26._comment b/doc/bugs/git_annex_test_fails_when_run_through_powershell/comment_1_014466c5da1922d34a498648baeeba26._comment
new file mode 100644
index 0000000000..f4d67c7551
--- /dev/null
+++ b/doc/bugs/git_annex_test_fails_when_run_through_powershell/comment_1_014466c5da1922d34a498648baeeba26._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-07T17:23:51Z"
+ content="""
+The "cannot move" message is not an error message from an external "mv"
+command. This error comes from Win32.moveFileEx, which fails on cross-device
+renames.
+"""]]
diff --git a/doc/bugs/git_annex_test_fails_when_run_through_powershell/comment_2_241ab999007eecaa2cd5a854e722e315._comment b/doc/bugs/git_annex_test_fails_when_run_through_powershell/comment_2_241ab999007eecaa2cd5a854e722e315._comment
new file mode 100644
index 0000000000..157fed799e
--- /dev/null
+++ b/doc/bugs/git_annex_test_fails_when_run_through_powershell/comment_2_241ab999007eecaa2cd5a854e722e315._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-07T18:15:21Z"
+ content="""
+The import problem can be reproduced by running git annex import on a different
+drive in Windows. No powershell needed; it does fall back to the external
+mv command, but that fails for some reason. Was unable to determine why
+(running the same mv at the command line works ok). Fixed for Windows by
+avoiding using the external mv command there.
+
+Still need more details about the addurl failure. AFAICS, it does not
+involve "mv" at all. Probably it involves
+the generated file:// url not working for some reason. 
+What drive and path did you run the test suite in?
+"""]]
diff --git a/doc/bugs/git_annex_upgrade_fails.mdwn b/doc/bugs/git_annex_upgrade_fails.mdwn
new file mode 100644
index 0000000000..7da298a468
--- /dev/null
+++ b/doc/bugs/git_annex_upgrade_fails.mdwn
@@ -0,0 +1,35 @@
+### Please describe the problem.
+
+I have an old (broken) annex that I would like to revive. I'm unable to upgrade the annex.
+
+### What steps will reproduce the problem?
+
+git annex sync
+git-annex: Repository /mnt/sdc/annex/.git is at unsupported version 9. Automatic upgrade exception! .git/annex: createDirectory: does not exist (No such file or directory)
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20230626-g55fef4fb81
+running on Archlinux (up to date)
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+[alex@proliant .git]$ git annex sync
+git-annex: Repository /mnt/sdc/annex/.git is at unsupported version 9. Automatic upgrade exception! .git/annex: createDirectory: does not exist (No such file or directory)
+[alex@proliant .git]$ git annex upgrade
+upgrade  (v9 to v10...) 
+git-annex: .git/annex: createDirectory: does not exist (No such file or directory)
+failed
+upgrade: 1 failed
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I'm starting to get the hang of git-annex (after about three years ;-). I started with an annex which I somehow broke. Then I opened a "bannex", which I thought I broke. Therefore I started "cannex", only to realize that bannex wasn't broke. Now I'm using bannex, but my data is scattered around a-,b-,c-annex. I think I made Napoleon somewhere in between (because he annexed Europe). But my brain is slowly wrapping around git and the annex. I'd like to create an annex to rule them all ;-)
+Thanks to the developers!
diff --git a/doc/bugs/git_annex_upgrade_fails/comment_1_26e3224b9aad57837969c309ae4bdcd2._comment b/doc/bugs/git_annex_upgrade_fails/comment_1_26e3224b9aad57837969c309ae4bdcd2._comment
new file mode 100644
index 0000000000..5784ae2e6c
--- /dev/null
+++ b/doc/bugs/git_annex_upgrade_fails/comment_1_26e3224b9aad57837969c309ae4bdcd2._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-21T16:51:35Z"
+ content="""
+Please strace `git-annex upgrade` and display the end part of the strace,
+before it displays this error message:
+
+	git-annex: .git/annex: createDirectory: does not exist (No such file or directory)
+
+I have not been able to find a situation where it can fail like that.
+If .git/annex somehow doesn't exist (which would be very strange to start
+with), it will be created during the upgrade.
+
+The closest I've gotten is making .git/annex a symlink to a directory that
+doesn't exist, which causes the upgrade to fail like this:
+
+	git-annex: .git/annex: createDirectory: already exists (File exists)
+
+Now, if .git didn't exist, it would make sense that creating .git/annex
+would fail like that. But of course, if .git doesn't exist, it's not a git
+repository. Unless, I suppose, you have done something to make git use a
+different directory than .git?
+
+(I thought .git might be a gitlink file as used for a submodule, 
+but testing `git-annex upgrade` in a submodule with a gitlink file,
+it does convert it to a symlink and creating .git/annex succeeds.)
+"""]]
diff --git a/doc/bugs/git_annex_upgrade_loses_track_of_files_with___34____38____34___character___40__and_probably_others__41__.mdwn b/doc/bugs/git_annex_upgrade_loses_track_of_files_with___34____38____34___character___40__and_probably_others__41__.mdwn
new file mode 100644
index 0000000000..9daf8a0cb4
--- /dev/null
+++ b/doc/bugs/git_annex_upgrade_loses_track_of_files_with___34____38____34___character___40__and_probably_others__41__.mdwn
@@ -0,0 +1,33 @@
+"git annex upgrade" has lost track of some of my files.  Most of them have "&" characters.  The others contain "%" characters (I haven't tried the testcase below with "%" however).
+
+Testcase:
+
+    # (With git annex v2)
+    mkdir ~/testannex1
+    cd ~/testannex1
+    git init
+    git annex init "testannex1"
+    touch '02 - Afternoons & Coffeespoons.mp3'
+    touch 'no ampersand.mp3'
+    git annex add '02 - Afternoons & Coffeespoons.mp3'
+    git annex add 'no ampersand.mp3'
+    git commit -m added
+    git annex whereis '02 - Afternoons & Coffeespoons.mp3'
+    git annex whereis 'no ampersand.mp3'
+    # (Upgrade git-annex binary to v3 and then...)
+    git annex upgrade
+    git annex whereis '02 - Afternoons & Coffeespoons.mp3'
+    git annex whereis 'no ampersand.mp3'
+
+This produces:
+
+    12:38:40 ~/testannex1 (master)$ git annex whereis '02 - Afternoons & Coffeespoons.mp3'
+    whereis 02 - Afternoons & Coffeespoons.mp3 (0 copies) 
+    failed
+    git-annex: 1 failed
+    12:38:40 ~/testannex1 (master)$ git annex whereis 'no ampersand.mp3'
+    whereis no ampersand.mp3 (1 copy) 
+      	a7b680fc-a8d0-11e0-b0fe-4f94e86d1fb7  -- testannex1 <-- here
+    ok
+
+[[!tag done]]
diff --git a/doc/bugs/git_annex_upgrade_loses_track_of_files_with___34____38____34___character___40__and_probably_others__41__/comment_1_861506e40e0d04d2be98bbfe9188be89._comment b/doc/bugs/git_annex_upgrade_loses_track_of_files_with___34____38____34___character___40__and_probably_others__41__/comment_1_861506e40e0d04d2be98bbfe9188be89._comment
new file mode 100644
index 0000000000..194b36ac10
--- /dev/null
+++ b/doc/bugs/git_annex_upgrade_loses_track_of_files_with___34____38____34___character___40__and_probably_others__41__/comment_1_861506e40e0d04d2be98bbfe9188be89._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-07-07T21:04:23Z"
+ content="""
+What an evil little bug. In retrospect, this probably bit my own test upgrades, but I ran `git annex fsck` everywhere and so avoided the location log breakage.
+
+I've fixed the bug, which also involved files with other punctuation in their names [&:%] when using the WORM backend. 
+
+The only way I have to recover repos that have already been upgraded is to run `git annex fsck --fast` in each clone of such a repo, which will let it rebuild the location log information. I think that is the best way to recover; ie I can't think of a way to recover that doesn't need to do everything fsck does anyway.
+"""]]
diff --git a/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree.mdwn b/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree.mdwn
new file mode 100644
index 0000000000..0ac3eacfaf
--- /dev/null
+++ b/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree.mdwn
@@ -0,0 +1,29 @@
+### Please describe the problem.
+If using git annex with external .git dir webapp report a tread crashed and ever trying to restart it crash again and webapp is not able to upload/download/sync (also the download of git-annex updates is affected)
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20150113-gcf247cf
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+
+Precompiled tarball from official git-annex download site
+
+Gentoo linux
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+Launching web browser on file://../.git_annex_repos/pippo.git/annex/webapp.html      <-- note wrong path! should be /home/gioacchino/.git_annex_repos/pippo.git/annex/webapp.html
+
+RemoteControl crashed: user error (nice ["ionice","-c3","/home/gioacchino/opt/git-annex.linux/git-annex","remotedaemon"] exited 1)
+
+WebApp crashed: <file descriptor: 11>: hPutStr: illegal operation (handle is closed
+"""]]
+
+[[!meta title="assistant does not support nonstandard --git-dir"]]
diff --git a/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_1_cc3ea43301cd17b55794f9b9dd1e91cf._comment b/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_1_cc3ea43301cd17b55794f9b9dd1e91cf._comment
new file mode 100644
index 0000000000..2e76dda05b
--- /dev/null
+++ b/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_1_cc3ea43301cd17b55794f9b9dd1e91cf._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-09T17:54:00Z"
+ content="""
+I've confirmed this behavior. Normally git-annex propigates --git-dir
+to git commands it runs, but this is not done in a few cases in the
+assistant, including when it starts `git-annex remotedaemon` but also
+`git-annex fsck`, `git annex unused`, and `git annex transferkeys`.
+
+(Just search for readProgramFile; Remote.Git.fsckOnRemote is the only
+place outside the assistant that uses it, and it does take care to
+propigate --git-dir and --work-tree.)
+
+Also, restarting the assistant, either in the web ui or automatically due to
+an upgrade also doesn't propigate --git-dir.
+
+And, the assistant's autostart file doesn't support --git-dir.
+
+All of which could be fixed, but I have to wonder, why? What's the use case
+for a separate --git-dir with the assistant? I guess not vcsh because the
+assistant would watch for all changes to the home directory, and add them,
+and that's not how vcsh is used.
+
+I'm tempted to just make the assistant refuse to start when given a
+nonstandard --git-dir..
+"""]]
diff --git a/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_2_fb75f5941d355947b3f06165825dd012._comment b/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_2_fb75f5941d355947b3f06165825dd012._comment
new file mode 100644
index 0000000000..b716500997
--- /dev/null
+++ b/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_2_fb75f5941d355947b3f06165825dd012._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlvmWVPaSpWJO5_rimCL0lEoJRoKOIjhHE"
+ nickname="Gioacchino"
+ subject="Why shoul git-annex support --git-dir"
+ date="2015-03-01T10:10:31Z"
+ content="""
+Hi!
+
+There are multiple use case as I explained on IRC and it is why I and probably more users need it, there are some git-annex repository that i share also with other programs like RetroShare and apache USERDIR (like http://efesto.eigenlab.org/~gioacchino/) i don't like .git directory to be shared by these programs as the file are publics but not the metadata stored on the .git ( http://efesto.eigenlab.org/~gioacchino/.git/config ) i know i can do that with other tricks like htaccess but it is application specific hack while the real solution is to keep the .git in a private place
+
+Another use case is when you are grepping or doing scripty stuff on your dir having the .git in another place allow you to do stuff without concern about what there is inside .git without using options like --exclude and similar
+
+The list of use cases can grow as they are all the one caused git to support --git-dir so for the sake of consistence and for your donors please propagate --git-dir on all git-annex components ;)
+
+P.S. I am not native english speaker so sorry if something sounds bad
+"""]]
diff --git a/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_3_8c7b21c8e500de719fc2909d0c9027e0._comment b/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_3_8c7b21c8e500de719fc2909d0c9027e0._comment
new file mode 100644
index 0000000000..dc9d1b6b01
--- /dev/null
+++ b/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_3_8c7b21c8e500de719fc2909d0c9027e0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-06T19:47:47Z"
+ content="""
+@Gioacchino, git-annex already fully supports --git-dir. It's only the
+assistant that does not. If you're doing "scripty stuff", you are, 
+I'd guess, not using the assistant...
+"""]]
diff --git a/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_4_423126c9884267b3466470d4ec7301ce._comment b/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_4_423126c9884267b3466470d4ec7301ce._comment
new file mode 100644
index 0000000000..b0f44c6c5d
--- /dev/null
+++ b/doc/bugs/git_annex_wont_work_with_git-dir_and_work-tree/comment_4_423126c9884267b3466470d4ec7301ce._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="gmazzurco89@89ed4f74a057a9c71b2a00000fdb201a88f81bcd"
+ nickname="gmazzurco89"
+ subject="comment 4"
+ date="2015-11-05T07:28:02Z"
+ content="""
+The \"scripty stuff\" may be a simple find or grep on the annexed dir, that doesn't actually involve git-annex, but those simple and usual commands are fooled by the content of .git, because of that it would be nice to have git-annex-{assistant, webapp, ...} work in this setup, it is not only a matter of scripts, other applications may have unexpected behavior in presence of .git -_-
+
+To make the usage of other apps more complicated doesn't seems an objective of git-annex-webapp, am I wrong?
+"""]]
diff --git a/doc/bugs/git_checkout_slow_with_unlocked_files/comment_1_80d9a46c608117fb9a381c59d4605ff4._comment b/doc/bugs/git_checkout_slow_with_unlocked_files/comment_1_80d9a46c608117fb9a381c59d4605ff4._comment
new file mode 100644
index 0000000000..693da1161a
--- /dev/null
+++ b/doc/bugs/git_checkout_slow_with_unlocked_files/comment_1_80d9a46c608117fb9a381c59d4605ff4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-11-02T17:58:27Z"
+ content="""
+This is due to [[todo/git_smudge_clean_interface_suboptiomal]].
+"""]]
diff --git a/doc/bugs/git_commit_smudges_unncessarily.mdwn b/doc/bugs/git_commit_smudges_unncessarily.mdwn
new file mode 100644
index 0000000000..47f990de75
--- /dev/null
+++ b/doc/bugs/git_commit_smudges_unncessarily.mdwn
@@ -0,0 +1,22 @@
+### Please describe the problem.
+
+git commit smudges unlocked files in the index when they were already smudged with git status.
+
+### What steps will reproduce the problem?
+
+```
+for i in {1..200}; do echo $i > $i; done
+git init; git annex init; git config annex.thin true; git config annex.crippledfilesystem true; git config annex.addunlocked true; git annex add .; git status; time git commit -m .
+```
+
+git commit should take less than a second but takes several seconds to smudge the files in the index.
+
+### What version of git-annex are you using? On what operating system?
+
+Through bisection, the problem was found to be introduced in [[!commit 428c91606b434512d1986622e751c795edf4df44]]. Problem occurs both in Linux and WSL1.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git-annex has worked wonderfully for managing my files across different machines and cloud storage services.
+
+[[done]]
diff --git a/doc/bugs/git_commit_smudges_unncessarily/comment_1_202cb8adc7a7b1119f5b4c1f5c6e9c7e._comment b/doc/bugs/git_commit_smudges_unncessarily/comment_1_202cb8adc7a7b1119f5b4c1f5c6e9c7e._comment
new file mode 100644
index 0000000000..b31e0002b5
--- /dev/null
+++ b/doc/bugs/git_commit_smudges_unncessarily/comment_1_202cb8adc7a7b1119f5b4c1f5c6e9c7e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-11-02T19:11:51Z"
+ content="""
+I doubt this bisection was correct. Whether git commit decides to smudge a
+file is entirely an internal decision on the part of git; the only way
+git-annex can affect it is by updating the mtime etc of the file.
+
+Even small things like variations in timing can change git's smudging
+behavior. It may unncessarily re-smudge a file when its timestamp is
+sufficiently close to the current time. For whatever internal value
+of "sufficiently close" it happens to pick for a given
+OS/filesystem/whatever.
+"""]]
diff --git a/doc/bugs/git_commit_smudges_unncessarily/comment_2_5b230c4b74da48099e8be0e264bbf3e6._comment b/doc/bugs/git_commit_smudges_unncessarily/comment_2_5b230c4b74da48099e8be0e264bbf3e6._comment
new file mode 100644
index 0000000000..1e61d6251f
--- /dev/null
+++ b/doc/bugs/git_commit_smudges_unncessarily/comment_2_5b230c4b74da48099e8be0e264bbf3e6._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-11-09T20:03:33Z"
+ content="""
+While I still need to investigate if there is really a reversion here,
+it's worth noting that you can probably avoid the slow speed by running:
+
+git config filter.annex.process 'git-annex filter-process'
+
+That needs a current daily build of git-annex, the feature will also be in
+the next release.
+"""]]
diff --git a/doc/bugs/git_commit_smudges_unncessarily/comment_3_c30e84ae438810cbab70c401fd5125c0._comment b/doc/bugs/git_commit_smudges_unncessarily/comment_3_c30e84ae438810cbab70c401fd5125c0._comment
new file mode 100644
index 0000000000..3e03ba3035
--- /dev/null
+++ b/doc/bugs/git_commit_smudges_unncessarily/comment_3_c30e84ae438810cbab70c401fd5125c0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 3"
+ date="2022-09-24T19:43:47Z"
+ content="""
+This seems to be fixed now, maybe due to the changes made related to [[todo/git_status_smudges_unncessarily_after_unlock]].
+"""]]
diff --git a/doc/bugs/git_error___34__update__95__ref_failed_for_ref__34__.mdwn b/doc/bugs/git_error___34__update__95__ref_failed_for_ref__34__.mdwn
new file mode 100644
index 0000000000..4b0021bf87
--- /dev/null
+++ b/doc/bugs/git_error___34__update__95__ref_failed_for_ref__34__.mdwn
@@ -0,0 +1,38 @@
+Notice that the problem is due to the fact that the remote name has spaces. I have only tested it with adb special remote, but since it is a `git` error It will likely happen with any remote.
+
+Sorry I you don't consider this a bug or if it is documented somewhere and I haven't read it.
+
+### Please describe the problem.
+following [Android sync tip](https://git-annex.branchable.com/tips/android_sync_with_adb/), It fails with 
+
+```
+update refs/remotes/Redmi Note 8/master fatal: update_ref failed for ref'refs/remotes/Redmi Note 8/master': refuse to update ref with bad name 'refs/remotes/Redmi Note 8/master'
+
+git-annex: git [Param "update-ref",Param "refs/remotes/Redmi Note 8/master",Param "389056e22b21972da562d1f1c5ce7af2447523b7"] failed
+CallStack (from HasCallStack):
+  error, called at ./Git/Command.hs:42:17 in main:Git.Command
+failed
+```
+
+The error happens after executing `git annex sync --content "Redmi Note 8"` and pulling all files. 
+
+### What steps will reproduce the problem?
+Once you have conected to an adb special remote (probably any remote can trigger the error) run the following
+
+```bash
+#                        |- Notice the space
+git-annex initremote "Bad Remote" type=adb androiddirectory=/sdcard encryption=none exporttree=yes importtree=yes
+git config "remote.Bad Remote.annex-tracking-branch" master:android
+git annex sync --content "Bad Remote"
+```
+
+It will download the content and fail afterwards
+
+### What version of git-annex are you using? On what operating system?
+- git-annex version 8.20200226
+- OS: Ubuntu 20.04.3 LTS
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I am not an experienced user but after using non-space-remotes-names I've been able to sync my phone with no major problems following the documentation in this page. So great work!
+
+[[!meta title="importtree remote with spaces in its name causes ref update failure with unncessarily ugly message; could fail earlier with a better message"]]
diff --git a/doc/bugs/git_error___34__update__95__ref_failed_for_ref__34__/comment_1_60ea64baccef82dc03ab300ca9b5e2b5._comment b/doc/bugs/git_error___34__update__95__ref_failed_for_ref__34__/comment_1_60ea64baccef82dc03ab300ca9b5e2b5._comment
new file mode 100644
index 0000000000..e7e96c8569
--- /dev/null
+++ b/doc/bugs/git_error___34__update__95__ref_failed_for_ref__34__/comment_1_60ea64baccef82dc03ab300ca9b5e2b5._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-02T18:29:05Z"
+ content="""
+This is similar to configuring git with a remote that has spaces in its
+name:
+
+	joey@darkstar:/tmp/z>git remote add "My Remote" ../x
+	fatal: 'My Remote' is not a valid remote name
+
+Or configuring a remote.foo.fetch with spaces in the name of the rev:
+
+	joey@darkstar:/tmp/y>git config remote.origin.fetch
+	+refs/heads/*:refs/remotes/Redmi Note 8/*
+	joey@darkstar:/tmp/y>git fetch origin
+	fatal: invalid refspec '+refs/heads/*:refs/remotes/Redmi Note 8/*'
+
+Importing from a special remote with importtree=yes is equivilant from
+pulling from a git remote, and needs to update a branch with a similar
+name as origin/master. And with a remote name with spaces, there is
+no legal branch name that will work.
+
+So, this has to fail. It could fail earlier, or with a better error
+message.
+"""]]
diff --git a/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch.mdwn b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch.mdwn
new file mode 100644
index 0000000000..079b915a8a
--- /dev/null
+++ b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch.mdwn
@@ -0,0 +1,69 @@
+### Please describe the problem.
+
+`git fsck` gives many duplicateEntries errors.  One of my repository's two clones is using an adjusted branch on MacOS.
+
+It's hard to say exactly what created this problem, because you don't see the error immediately after it happens.  But I believe all I did was add some files to the repo with the adjusted branch, run `git annex add` (I think), and git annex sync.  I believe this is all I did because when I have a remote that is apparently running `git fsck` and is rejecting pushes, and I think I'd pushed to this remote before I did the above.
+
+    $ git fsck
+    Checking object directories: 100% (256/256), done.
+    error in tree 85dfa00afd3a57a2981dfe9c0bf489288a3822ae: duplicateEntries: contains duplicate file entries
+    error in tree b30abe06ad503de3515269b657330ae6f4bef059: duplicateEntries: contains duplicate file entries
+    error in tree 9a3143961333528bfe0a8997413f3952a9892b90: duplicateEntries: contains duplicate file entries
+    error in tree c544533d9f4d802574ca3024249ae8171ebc7906: duplicateEntries: contains duplicate file entries
+    error in tree a906491c49fd46cc48a8a8ad2e5c059b9909418d: duplicateEntries: contains duplicate file entries
+    error in tree 45e22b842e07260b464306fd54daaddb00fe8689: duplicateEntries: contains duplicate file entries
+    error in tree 14a7cd8bc15738a61800485f63664d598fa5e100: duplicateEntries: contains duplicate file entries
+    [...]
+
+What's particularly interesting is that the duplicate objects appear to be the same blobs.
+
+    $ git ls-tree 7171d50e236e541b03faacb3b7113858a3640c4c
+    120000 blob 52f9ac67c8e73aa22057ecb5a195ebc51f0df5ea    General Clarification.docx
+    120000 blob 52f9ac67c8e73aa22057ecb5a195ebc51f0df5ea    General Clarification.docx
+    120000 blob 19b187309ddedd120791d3b9e0779f8ec7a21c9e    Mockumentary_Classic Story Synopses.doc
+    120000 blob 19b187309ddedd120791d3b9e0779f8ec7a21c9e    Mockumentary_Classic Story Synopses.doc
+    120000 blob 9c3d92e749e34dd1ec43a2c0b36425ae1ff7b01f    Worksheet 2018.pdf
+    120000 blob 9c3d92e749e34dd1ec43a2c0b36425ae1ff7b01f    Worksheet 2018.pdf
+    120000 blob 8445929b506f916f885018bb5a4a170f3901b7fb    Worksheet 2018.xls
+    120000 blob 8445929b506f916f885018bb5a4a170f3901b7fb    Worksheet 2018.xls
+
+We can check systematically:
+
+    $ git fsck  |& grep duplicateEntries | cut -f 4 -d ' ' | xargs git ls-tree | uniq -u
+    (No output)
+
+I see two previous bugs about this bug and an open question for more information.
+
+ * <https://git-annex.branchable.com/bugs/git-annex_wants_to_repair_because_of_duplicateEntries_in_git_fsck/>
+ * <https://git-annex.branchable.com/forum/how_to_disaster_recovery/>
+
+### What steps will reproduce the problem?
+
+Don't really know, sadly.
+
+### What version of git-annex are you using? On what operating system?
+
+Both machines show the following:
+
+    $ git --version
+    git version 2.18.0
+
+    $ git annex version
+    git-annex version: 6.20180626
+    build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+    dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.13 persistent-sqlite-2.6.4 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+    operating system: darwin x86_64
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+
+However I just recently ran brew update on the two machines.  I don't know what versions of git and git-annex they were running before.
+
+### Please provide any additional information below.
+
+I'm happy to help debug this if I can.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I <3 git-annex.
diff --git a/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_1_1a6674245aed0c325361043d1100daec._comment b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_1_1a6674245aed0c325361043d1100daec._comment
new file mode 100644
index 0000000000..6d1685d5f4
--- /dev/null
+++ b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_1_1a6674245aed0c325361043d1100daec._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="justin.lebar@7a36fcafc322d9a381e89f08ab6289033c6dde91"
+ nickname="justin.lebar"
+ avatar="http://cdn.libravatar.org/avatar/9fca4b61a1ab555f231851e7543f9a3e"
+ subject="comment 1"
+ date="2018-07-08T19:53:08Z"
+ content="""
+OK, that systematic check for duplicates is not right.  A better check is, how many blobs are not duplicated, and how many are duplicated, in the `git ls-tree` output?
+
+    # Not duplicated blobs
+    $ git fsck  |& grep duplicateEntries | cut -f 4 -d ' ' | sed -e 's/://' | xargs -n1 git ls-tree | grep -v ' tree ' | uniq -u | wc -l
+    324
+
+    # Duplicated blobs
+    $ git fsck  |& grep duplicateEntries | cut -f 4 -d ' ' | sed -e 's/://' | xargs -n1 git ls-tree | grep -v ' tree ' | uniq -u | wc -l
+    416
+"""]]
diff --git a/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_2_ccadd646ec0fe7abec461c110bfb7ae7._comment b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_2_ccadd646ec0fe7abec461c110bfb7ae7._comment
new file mode 100644
index 0000000000..f18935274d
--- /dev/null
+++ b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_2_ccadd646ec0fe7abec461c110bfb7ae7._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-07-16T15:27:13Z"
+ content="""
+Something more is involved than git annex add and sync on an adjusted
+branch, because when I try that the problem does not appear.
+(Also tried on OSX in case it was somehow OSX specific.)
+
+I see that the mode of the files in the problem tree you showed
+is 120000, which tells me that tree is one that was committed to the master
+branch, not the adjusted unlocked branch. That suggests that the problem is
+in reverseAdjustedTree. But I don't think I will be able to find it by
+staring at the code; I need a way to reproduce the problem.
+
+What *might* help is if you can show the full directory tree in the
+repository (with names mangled for privacy as needed). It may be that it's
+somehow caused by adding a file at a particular location in the tree,
+since a lot of the complication in the code is around handling such things.
+"""]]
diff --git a/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_3_2a6ef51c96a914be5d248b526ad37394._comment b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_3_2a6ef51c96a914be5d248b526ad37394._comment
new file mode 100644
index 0000000000..d2edf68b24
--- /dev/null
+++ b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_3_2a6ef51c96a914be5d248b526ad37394._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="jlebar"
+ avatar="http://cdn.libravatar.org/avatar/9fca4b61a1ab555f231851e7543f9a3e"
+ subject="comment 3"
+ date="2018-07-17T05:12:03Z"
+ content="""
+Thanks a lot, Joey.
+
+I wrote a script that replaces each directory or filename with a salted hash:
+
+	#!/usr/bin/env python
+
+	import sys
+	import hashlib
+
+	def hash(s):
+	  m = hashlib.sha256()
+	  m.update(s)
+	  m.update('<secret>')
+	  return m.hexdigest()
+
+	for line in sys.stdin:
+	  print '/'.join(hash(p) for p in line.split('/'))
+
+Then I ran
+
+	$ git ls-files | python hash_paths.py | bzip2 > repo_paths.bz2  # attached
+
+To make something you can correlate with the git fsck errors, I ran
+
+	$ git fsck  |& grep duplicateEntries | cut -f 4 -d ' ' | sed -e 's/://' | xargs -n1 git ls-tree | grep -v ' tree '  > blobs
+	$ paste <(cut -f 1 blobs) <(cut -f 2 blobs | python hash_paths.py) | bzip2 > fsck_errors.bz2  # attached
+
+So the second column in fsck_errors is the salted+hashed filename like in the comment above.  You should be able to correlate the \"filenames\" in fsck_errors with the paths in repo_paths.
+
+I'll email you the relevant files.
+"""]]
diff --git a/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_4_f9588887f75c0d17b87f2718b0584a94._comment b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_4_f9588887f75c0d17b87f2718b0584a94._comment
new file mode 100644
index 0000000000..675ac64b84
--- /dev/null
+++ b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_4_f9588887f75c0d17b87f2718b0584a94._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-07-17T14:59:26Z"
+ content="""
+Looking at those files, all the duplicated files
+are located at least 2 subdirectories deep, and most more like 5-7
+deep. But, almost all of the repo is inside such
+subdirectories, so that is not conclusive.
+
+Aha! I managed to reproduce it:
+
+	joey@darkstar:~/tmp/t#master(unlocked)>mkdir ook
+	joey@darkstar:~/tmp/t#master(unlocked)>cd ook
+	joey@darkstar:~/tmp/t/ook#master(unlocked)>mkdir boop
+	joey@darkstar:~/tmp/t/ook#master(unlocked)>cd boop
+	joey@darkstar:~/tmp/t/ook/boop#master(unlocked)>mkdir beep
+	joey@darkstar:~/tmp/t/ook/boop#master(unlocked)>cd beep
+	joey@darkstar:~/tmp/t/ook/boop/beep#master(unlocked)>mkdir yeep
+	joey@darkstar:~/tmp/t/ook/boop/beep#master(unlocked)>cd yeep
+	joey@darkstar:~/tmp/t/ook/boop/beep/yeep#master(unlocked)>date > X
+	joey@darkstar:~/tmp/t/ook/boop/beep/yeep#master(unlocked)>git annex add
+	add X ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/t/ook/boop/beep/yeep#master(unlocked)>git annex sync
+	commit
+	[adjusted/master(unlocked) fe11872] git-annex in joey@darkstar:~/tmp/t
+	 1 file changed, 1 insertion(+)
+	 create mode 100644 ook/boop/beep/yeep/X
+	ok
+	joey@darkstar:~/tmp/t/ook/boop/beep/yeep#master(unlocked)>git fsck
+	error in tree a5fcd5b3aa5189ed8916f025cf035fce74098a1a: duplicateEntries: contains duplicate file entries
+	Checking object directories: 100% (256/256), done.
+
+Ok, it seems it's simply caused by deep paths in the tree and nothing
+else. Will debug from here.
+"""]]
diff --git a/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_5_a9d6cf6cd38bfa6f391beaf6831b0ef4._comment b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_5_a9d6cf6cd38bfa6f391beaf6831b0ef4._comment
new file mode 100644
index 0000000000..92c96f6dfd
--- /dev/null
+++ b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_5_a9d6cf6cd38bfa6f391beaf6831b0ef4._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-07-17T15:12:12Z"
+ content="""
+I wrote a reproduction script, which worked several times, and then stopped
+working. Now I can't reproduce it using that script. Some kind of race condition?
+Only happens before coffee o-clock? I don't know. :-/
+
+The script:
+
+	#!/bin/sh
+	sudo rm -rf /tmp/repo
+	git init /tmp/repo
+	cd /tmp/repo
+	git annex init
+	date > foo
+	git annex add foo
+	git annex sync
+	git annex upgrade
+	git annex adjust --unlock
+	mkdir -p ook/boop/beep/yeep
+	date > ook/boop/beep/yeep/x
+	git annex add
+	git annex sync
+	git fsck
+
+I also noticed that, once a tree gets duplicate entries in it, they are
+carried forward into the new trees when other commits are made to that
+directory. This may explain why fsck is finding so many trees to complain
+about in your repsitory.
+
+The commit made to the adjusted branch does not have a duplicate in the tree.
+The reverse adjusted commit made to master does. So it must involve
+adjustTree somehow.
+
+I don't see anything likely to cause a race condition in adjustTree.
+However, I do think that v6 mode has many bugs some of which may be
+race conditions, and perhaps the root cause is not adjustTree.
+
+This seems likely related in some way to
+[[bugs/add_fails_with_v6_repo_when_four_levels_deep]],
+which I incidentially reproduced for the first time (and then fixed) while
+trying again to reproduce this bug.
+"""]]
diff --git a/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_6_cfefa7ac1f538566ee028aa3996e22cd._comment b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_6_cfefa7ac1f538566ee028aa3996e22cd._comment
new file mode 100644
index 0000000000..f43289611b
--- /dev/null
+++ b/doc/bugs/git_fsck_duplicateEntries_errors_when_using_adjusted_branch/comment_6_cfefa7ac1f538566ee028aa3996e22cd._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-01-29T19:23:19Z"
+ content="""
+An older bug [[git-annex_wants_to_repair_because_of_duplicateEntries_in_git_fsck]]
+also had duplicate directory entries. I'm not clear if adjusted branches
+were involved there.
+
+I can't reproduce it using that script that was working to reproduce it for
+a while for me.
+"""]]
diff --git a/doc/bugs/git_init_fails_on_a_worktree_branch.mdwn b/doc/bugs/git_init_fails_on_a_worktree_branch.mdwn
new file mode 100644
index 0000000000..511d405c4d
--- /dev/null
+++ b/doc/bugs/git_init_fails_on_a_worktree_branch.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+I tried git annex init on a worktree checkout of a branch, but got an error (see below).
+The worktree is for a repo that is itself a submodule of another repo.
+
+### What steps will reproduce the problem?
+I can try later to make an isolated reproducible example, but I think the above scenario describes it.
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+[bpb23-acc /data/ilya/iwork/marti/tmp/wtree/is-231002-1155-marti-cpp]$ git annex version
+git-annex version: 10.20230626-g801c4b7
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+(pbase-025-env) Wed 15 Nov 2023 01:37:24 PM EST
+[bpb23-acc /data/ilya/iwork/marti/tmp/wtree/is-231002-1155-marti-cpp]$ uname -a
+Linux bpb23-acc 5.4.0-136-generic #153-Ubuntu SMP Thu Nov 24 15:56:58 UTC 2022 x86_64 GNU/Linux
+(pbase-025-env) Wed 15 Nov 2023 01:37:25 PM EST
+[bpb23-acc /data/ilya/iwork/marti/tmp/wtree/is-231002-1155-marti-cpp]$ 
+"""]]
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+[bpb23-acc /data/ilya/iwork/marti/tmp/wtree/is-231002-1155-marti-cpp]$ git annex init
+init  
+git-annex: worktrees/is-231002-1155-marti-cpp/info/attributes: openFile: does not exist (No such file or directory)
+failed
+init: 1 failed
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Well I keep coming back to it as a solution :)  Right now I'm trying to set up proper test cases for a tool that processes sequencing data, and even moderate-size test files break github's size limits.  I'm also planning to demo git-annex to others in my group so they can start using it.
+
diff --git a/doc/bugs/git_init_fails_on_a_worktree_branch/comment_1_6614fc4b8f191702c1b78c5a3ce5de50._comment b/doc/bugs/git_init_fails_on_a_worktree_branch/comment_1_6614fc4b8f191702c1b78c5a3ce5de50._comment
new file mode 100644
index 0000000000..37dfc93118
--- /dev/null
+++ b/doc/bugs/git_init_fails_on_a_worktree_branch/comment_1_6614fc4b8f191702c1b78c5a3ce5de50._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-11-21T20:01:25Z"
+ content="""
+I don't use worktrees or submodules much so it's not entirely apparent to
+me how to reproduce this. To avoid flailing at it, a recipe would be great.
+"""]]
diff --git a/doc/bugs/git_keeps_refreshing_index.mdwn b/doc/bugs/git_keeps_refreshing_index.mdwn
new file mode 100644
index 0000000000..c69844ccd1
--- /dev/null
+++ b/doc/bugs/git_keeps_refreshing_index.mdwn
@@ -0,0 +1,12 @@
+Since upgrading to git-annex 7.20190912, when doing `git status` I keep getting the message `Refresh index:`, and there is a delay until it turns into something like `Refresh index: 100% (601422/601422), done.`.  I don't recall this happening with earlier `git-annex` versions.  Have others seen this?  (Not a "bug" in terms of correctness, but posting here as it affects usability and speed.)
+
+> This was fixed in [[!commit faf84aa5c2b963a41e56d02d6bbd2fbda7da9ceb]],
+> as far as handling of unlocking of many files goes.
+> 
+> For other cases where git needs to smudge a lot of files, 
+> in v9 and above repos, `git-annex filter-process` is used, 
+> which can speed it up significantly.
+> 
+> While it seems that the bug submitter never followed up with
+> what they were doing that caused the problem, this seems likely enough
+> fixed to call it [[done]]. --[[Joey]]
diff --git a/doc/bugs/git_keeps_refreshing_index/comment_1_bc76561ae4aaf932217c40109a8d04bd._comment b/doc/bugs/git_keeps_refreshing_index/comment_1_bc76561ae4aaf932217c40109a8d04bd._comment
new file mode 100644
index 0000000000..3dbdc4bd41
--- /dev/null
+++ b/doc/bugs/git_keeps_refreshing_index/comment_1_bc76561ae4aaf932217c40109a8d04bd._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-10-08T16:22:16Z"
+ content="""
+When using v7 repositories, git will do this when there are unlocked files
+that have had their content changed.
+
+git only displays that message when it thinks its going to have to
+do a lot of work (re-smudging a lot of files), so you'd mostly see this
+happen in a larger repository that has had a lot of (unlocked) files change
+in some way.
+"""]]
diff --git a/doc/bugs/git_keeps_refreshing_index/comment_2_a4c9ccb93a809aff61ae208d31ba0363._comment b/doc/bugs/git_keeps_refreshing_index/comment_2_a4c9ccb93a809aff61ae208d31ba0363._comment
new file mode 100644
index 0000000000..0770a76e32
--- /dev/null
+++ b/doc/bugs/git_keeps_refreshing_index/comment_2_a4c9ccb93a809aff61ae208d31ba0363._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-10-08T16:37:49Z"
+ content="""
+I noticed that `git annex drop` of an unlocked file causes the next `git
+status` to re-smudge the file. That's surprising because git-annex
+internally updates the index using git update-index, so git should not see
+any need to revisit it.
+
+So my guess is you were getting or dropping a lot of unlocked files when
+you saw that.
+"""]]
diff --git a/doc/bugs/git_keeps_refreshing_index/comment_3_919fb06b3fc7fe9b54797a805873e3c8._comment b/doc/bugs/git_keeps_refreshing_index/comment_3_919fb06b3fc7fe9b54797a805873e3c8._comment
new file mode 100644
index 0000000000..9ef2fd1544
--- /dev/null
+++ b/doc/bugs/git_keeps_refreshing_index/comment_3_919fb06b3fc7fe9b54797a805873e3c8._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-10-08T16:43:49Z"
+ content="""
+Dropping a single unlocked file and then running git
+status with `GIT_TRACE=1` replicates the additional smudge every time.
+
+The index before and after git status smudging have identical content, so
+git-annex seems to have updated it correctly already. It seems that the
+mtime of the index file is causing git to do that one additional smudge.
+
+Eg, the file git-annex dropped had a mtime of 13:02:43.716964483. The
+~/index file that git-annex generated has a mtime of 13:02:43.752964130
+which is newer, but only by a fraction of a second. So, git probably
+assumes the mtimes are sufficiently close that it can't trust that the
+index file really reflects the current content of the work tree file. And
+so it re-smudges the work tree file unncessarily.
+
+I have not been able to find a number of files to drop that replicates
+the bug report. When a lot of files are dropped, it starts taking
+sufficiently long to update the index file that it ends up with a newer
+timestamp, which avoids the unnecessary additional smudging. The worse
+case I have found here is dropping 9 files causes all 9 to get re-smudged,
+but that's not enough to get git to use the progress display.
+"""]]
diff --git a/doc/bugs/git_keeps_refreshing_index/comment_4_b73f9c5603bc69867e1619d871a8abb7._comment b/doc/bugs/git_keeps_refreshing_index/comment_4_b73f9c5603bc69867e1619d871a8abb7._comment
new file mode 100644
index 0000000000..7104488322
--- /dev/null
+++ b/doc/bugs/git_keeps_refreshing_index/comment_4_b73f9c5603bc69867e1619d871a8abb7._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-10-08T17:32:52Z"
+ content="""
+Anyway, if git-annex could preserve the mtime of an unlocked file when
+writing its pointer file or when populating it with content, that would
+avoid the unnecessary smudging. (Which seems better than adding a delay when
+updating the index file, or setting the index's mtime ahead of the current
+time..)
+
+That's easier done for pointer files than populated files, because
+with annex.thin the content is a hard link and it would probably not be
+good to change its mtime.
+
+For now, I didn't do it extensively, but only in depopulatePointerFile.
+That was enough to eliminate the unnecessary smudging after drop that I was
+seeing.
+"""]]
diff --git a/doc/bugs/git_keeps_refreshing_index/comment_5_f1b07147627b087231c776522ddc2826._comment b/doc/bugs/git_keeps_refreshing_index/comment_5_f1b07147627b087231c776522ddc2826._comment
new file mode 100644
index 0000000000..f7e525ea64
--- /dev/null
+++ b/doc/bugs/git_keeps_refreshing_index/comment_5_f1b07147627b087231c776522ddc2826._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-10-22T17:10:01Z"
+ content="""
+There is not enough information in this bug report for me to know if the
+problem I fixed was the problem that was reported.
+
+I'm going to assume so, if there is no followup soon.
+"""]]
diff --git a/doc/bugs/git_keeps_refreshing_index/comment_6_e0bfde0d53042ce8d310f356f88c610b._comment b/doc/bugs/git_keeps_refreshing_index/comment_6_e0bfde0d53042ce8d310f356f88c610b._comment
new file mode 100644
index 0000000000..b561288e73
--- /dev/null
+++ b/doc/bugs/git_keeps_refreshing_index/comment_6_e0bfde0d53042ce8d310f356f88c610b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="t+gitannex@1d62779e8b54f30a854739f61542a6885167b01f"
+ nickname="t+gitannex"
+ avatar="http://cdn.libravatar.org/avatar/87c7f62c00e4a744aa500423e421120f"
+ subject="comment 6"
+ date="2020-02-06T11:07:34Z"
+ content="""
+I'm able to reproduce this with git annex 7.20191230 and git 2.25.0 on Arch Linux, but I've had it on OSX in the past as well. The annex uses a v7 repository. I don't need to do anything besides unlocking some files and running git status. Unlocking 10 files, git status takes 3s and with 85 files it takes 20s, so it seems to scale linearly with the no of files. Happy to share more details about the repository if it's useful.
+"""]]
diff --git a/doc/bugs/git_keeps_refreshing_index/comment_7_35dff672dfd3c6fdc2b9fcdb9a58e154._comment b/doc/bugs/git_keeps_refreshing_index/comment_7_35dff672dfd3c6fdc2b9fcdb9a58e154._comment
new file mode 100644
index 0000000000..ccfafef49d
--- /dev/null
+++ b/doc/bugs/git_keeps_refreshing_index/comment_7_35dff672dfd3c6fdc2b9fcdb9a58e154._comment
@@ -0,0 +1,59 @@
+[[!comment format=mdwn
+ username="jasonb@ab4484d9961a46440958fa1a528e0fc435599057"
+ nickname="jasonb"
+ avatar="http://cdn.libravatar.org/avatar/c7330f4da122c671b935fc1d58bb02b1"
+ subject="I have this behavior consistently on the 2 repos I use"
+ date="2021-08-11T18:49:41Z"
+ content="""
+Here's the one. Now that a dozen changed files are committed, it doesn't happen. As long as they were modified, it happened every time. (On the other repo with 100,000+ files, it takes several minutes to complete this check. Absolutely kills my git aware shell prompt.)
+
+```
+git status
+Refresh index: 100% (1453/1453), done.
+
+git annex info
+trusted repositories: 0
+semitrusted repositories: 4
+...
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 56.15 gigabytes (+1 megabyte reserved)
+local annex keys: 2159
+local annex size: 16.89 gigabytes
+annexed files in working tree: 1437
+size of annexed files in working tree: 11.29 gigabytes
+bloom filter size: 32 mebibytes (0.4% full)
+backend usage:
+	SHA256E: 1437
+
+
+cat .git/config
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+	ignorecase = true
+	precomposeunicode = true
+[annex]
+	uuid = abc
+	version = 8
+	thin = true
+[filter \"annex\"]
+	smudge = git-annex smudge %f
+	clean = git-annex smudge --clean %f
+[merge]
+	renameLimit = 1000
+
+git annex version
+git-annex version: 8.20210428
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.28 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.4 http-client-0.7.8 persistent-sqlite-2.12.0.0 torrent-10000.1.1 uuid-1.3.14 yesod-1.6.1.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+```
+"""]]
diff --git a/doc/bugs/git_proxy_uses_ls-files_without_--exclude-standard.mdwn b/doc/bugs/git_proxy_uses_ls-files_without_--exclude-standard.mdwn
new file mode 100644
index 0000000000..85bf7089ea
--- /dev/null
+++ b/doc/bugs/git_proxy_uses_ls-files_without_--exclude-standard.mdwn
@@ -0,0 +1,40 @@
+### Please describe the problem.
+
+I'm starting to slowly migrate my personal data collection (530GB 3.7M files) under git-annex.  I'm going piece by piece, and not yet giving up my other synchronization methods (yet); thus I need to stay in direct mode.  
+
+I initially found that `git annex` commands [were quite slow](https://github.com/datalad/datalad/issues/17), but I was able to address that by adding all my "not yet included" directories to `.gitignore` at the root of the working tree.  Unfortunately, `git annex proxy` remains super slow, because I notice that it does not include `--exclude-standard` in its calls to ls-files, and thus does not respect `.gitignore`.  Here's an example from the `--debug` log:
+
+```
+ read: git ["--git-dir=../../../../../.git","--work-tree=../../../../..","--literal-pathspecs","-c","core.bare=false","ls-files","--others","-z","--","../../../../.."]
+```
+
+As a result, I was very shocked to learn that (25 min later), `git annex proxy` was still setting up, and had duplicated 140GB of untracked files!
+
+My end goal is actually just to add files directly to the git repo, bypassing the annex, in spite of being in direct mode.  (I can do this with the largefiles attribute, but I'd like to be able to control it directly irrespective of size.)
+
+### What steps will reproduce the problem?
+
+```
+git annex proxy --debug -- git commit myfile -m foo
+```
+
+### What version of git-annex are you using? On what operating system?
+
+Version 6.20170520 on Mac OS 10.13.4.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Today is my first day trying it out!  It's fabulous so far, but I'm at the beginning of the learning curve.
+
+> Yay, git-annex proxy is deprecated and just passes through to git, since
+> direct mode was eliminated. [[done]] --[[Joey]]
diff --git a/doc/bugs/git_proxy_uses_ls-files_without_--exclude-standard/comment_1_81383cf73102346fa8d537e1dde30353._comment b/doc/bugs/git_proxy_uses_ls-files_without_--exclude-standard/comment_1_81383cf73102346fa8d537e1dde30353._comment
new file mode 100644
index 0000000000..d0bb11b071
--- /dev/null
+++ b/doc/bugs/git_proxy_uses_ls-files_without_--exclude-standard/comment_1_81383cf73102346fa8d537e1dde30353._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-05-21T15:46:22Z"
+ content="""
+It wouldn't have actually copied 140 gb of files, unless you're using git-annex
+on a filesystem that does not support hard links. If it used hard links,
+it would not waste much space while running.
+
+There may be edge cases where, if git-annex proxy did not copy/hard link
+ignored files from the work tree to its temporary directory, the proxied
+git command would not behave the same as an unproxed git command.
+
+Let's see, such edge cases would have to involve a gitignored file that
+is still somehow affected by the proxied git command.
+
+The obvious case is, you have `.*` gitignored, and you run `git annex proxy
+-- git add .foo --force` to add the ignored file. If git-annex didn't copy
+`.foo`, that would fail, albeit in a fairly obvious way.
+
+Another problem case: You have `.*` gitignored, and you have a local
+file `.foo` which is not checked in. You run 
+`git annex proxy -- git merge branch`, and the branch happens to add
+`.foo` with different contents. The merge would normally fail, because
+there are conflicting changes in the working tree. If proxy were
+changed, the proxied merge would succeed. The local changes in this
+case get lost. I've verified that this change causes data loss in this
+situation.
+
+So, the current behavior is the safe and right behavior; git-annex should
+not lose data by default to optimise for an unusual edge case.
+
+It could be an option, but it would have to be flagged as causing data
+loss in some situations involving local modifications to gitignored files,
+and causing proxied git behavior to differ from non-proxied git behavior
+in other situations. I don't know if the potential benefit is worth the
+foot-gun potential.
+
+The code change is very simple if you want to play with it. In
+Command/Proxy.hs find the Git.LsFiles line and change "True" to "False".
+"""]]
diff --git a/doc/bugs/git_rename_detection_on_file_move.mdwn b/doc/bugs/git_rename_detection_on_file_move.mdwn
new file mode 100644
index 0000000000..306641cc2c
--- /dev/null
+++ b/doc/bugs/git_rename_detection_on_file_move.mdwn
@@ -0,0 +1,14 @@
+It's unfortunate that git-annex sorta defeats git's rename detection.
+
+When an annexed file is moved to a different directory (specifically, a
+directory that is shallower or deeper than the old directory),
+the symlink often has to change. And so git log cannot --follow back
+through the rename history, since all it has to go on is that symlink,
+which it effectively sees as a one line file containing the symlink target.
+
+One way to fix this might be to do the `git annex fix` *after* the rename
+is committed. This would mean that a commit would result in new staged
+changes for another commit, which is perhaps startling behavior.
+
+The other way to fix it is to stop using symlinks, see [[todo/smudge]].
+[[!tag confirmed]]
diff --git a/doc/bugs/git_rename_detection_on_file_move/comment_10_5ec2f965c80cc5dd31ee3c4edb695664._comment b/doc/bugs/git_rename_detection_on_file_move/comment_10_5ec2f965c80cc5dd31ee3c4edb695664._comment
new file mode 100644
index 0000000000..6ea2677289
--- /dev/null
+++ b/doc/bugs/git_rename_detection_on_file_move/comment_10_5ec2f965c80cc5dd31ee3c4edb695664._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"
+ nickname="Rafael"
+ subject="comment 10"
+ date="2012-05-15T07:36:25Z"
+ content="""
+Won't git itself be fixed on this issue? It was on my plans to look into that, however I don't know how difficult it will be.
+"""]]
diff --git a/doc/bugs/git_rename_detection_on_file_move/comment_1_0531dcfa833b0321a7009526efe3df33._comment b/doc/bugs/git_rename_detection_on_file_move/comment_1_0531dcfa833b0321a7009526efe3df33._comment
new file mode 100644
index 0000000000..8fec6bad72
--- /dev/null
+++ b/doc/bugs/git_rename_detection_on_file_move/comment_1_0531dcfa833b0321a7009526efe3df33._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="use mini-branches"
+ date="2011-03-09T23:47:48Z"
+ content="""
+if you go for the two-commits version, small intermediate branches (or git-commit-tree) could be used to create a tree like this:
+
+
+    *   commit 106eef2
+    |\  Merge: 436e46f 9395665
+    | | 
+    | |     the main commit
+    | |   
+    | * commit 9395665
+    |/  
+    |       intermediate move
+    |  
+    * commit 436e46f
+    | 
+    |     ...
+
+while the first commit (436e46f) has a \"`/subdir/foo → ../.git-annex/where_foo_is`\", the intermediate (9395665) has \"`/subdir/deeper/foo → ../.git-annex/where_foo_is`\", and the inal commit (106eef2) has \"`/subdir/deeper/foo → ../../.git-annex/where_foo_is`\".
+
+`--follow` uses the intermediate commit to find the history, but the intermediate commit would neither show up in `git log --first-parent` nor affect `git diff HEAD^..` & co. (there could still be confusion over `git show`, though).
+"""]]
diff --git a/doc/bugs/git_rename_detection_on_file_move/comment_2_7101d07400ad5935f880dc00d89bf90e._comment b/doc/bugs/git_rename_detection_on_file_move/comment_2_7101d07400ad5935f880dc00d89bf90e._comment
new file mode 100644
index 0000000000..7d50c58d1b
--- /dev/null
+++ b/doc/bugs/git_rename_detection_on_file_move/comment_2_7101d07400ad5935f880dc00d89bf90e._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="praet"
+ ip="81.240.159.215"
+ subject="Use variable symlinks, relative to the repo's root ?"
+ date="2011-03-10T16:50:28Z"
+ content="""
+It all boils down to the fact that the path to a relative symlink's target is determined relative to the symlink itself.
+
+Now, if we define the symlink's target relative to the git repo's root (eg. using the $GIT_DIR environment variable, which can be a relative or absolute path itself), this unfortunately results in an absolute symlink, which would -for obvious reasons- only be usable locally:
+
+    user@host:~$ mkdir -p tmp/{.git/annex,somefolder}
+    user@host:~$ export GIT_DIR=~/tmp
+    user@host:~$ touch $GIT_DIR/.git/annex/realfile
+    user@host:~$ ln -s $GIT_DIR/.git/annex/realfile $GIT_DIR/somefolder/file
+    user@host:~$ ls -al $GIT_DIR/somefolder/
+    total 12
+    drwxr-x--- 2 user group 4096 2011-03-10 16:54 .
+    drwxr-x--- 4 user group 4096 2011-03-10 16:53 ..
+    lrwxrwxrwx 1 user group   33 2011-03-10 16:54 file -> /home/user/tmp/.git/annex/realfile
+    user@host:~$
+
+So, what we need is the ability to record the actual variable name (instead of it's value) in our symlinks.
+
+It *is* possible, using [variable/variant symlinks](http://en.wikipedia.org/wiki/Symbolic_link#Variable_symbolic_links), yet I'm unsure as to whether or not this is available on Linux systems, and even if it is, it would introduce compatibility issues in multi-OS environments.
+
+Thoughts on this?
+"""]]
diff --git a/doc/bugs/git_rename_detection_on_file_move/comment_3_57010bcaca42089b451ad8659a1e018e._comment b/doc/bugs/git_rename_detection_on_file_move/comment_3_57010bcaca42089b451ad8659a1e018e._comment
new file mode 100644
index 0000000000..534723254a
--- /dev/null
+++ b/doc/bugs/git_rename_detection_on_file_move/comment_3_57010bcaca42089b451ad8659a1e018e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-03-16T03:03:19Z"
+ content="""
+Interesting, I had not heard of variable symlinks before. AFAIK linux does not have them.
+"""]]
diff --git a/doc/bugs/git_rename_detection_on_file_move/comment_4_79d96599f757757f34d7b784e6c0e81c._comment b/doc/bugs/git_rename_detection_on_file_move/comment_4_79d96599f757757f34d7b784e6c0e81c._comment
new file mode 100644
index 0000000000..c265b58995
--- /dev/null
+++ b/doc/bugs/git_rename_detection_on_file_move/comment_4_79d96599f757757f34d7b784e6c0e81c._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="praet"
+ ip="81.240.27.89"
+ subject="Brainfart"
+ date="2011-03-20T20:11:27Z"
+ content="""
+Haven't given these any serious thought (which will become apparent in a moment) but hoping they will give birth to some less retarded ideas:
+
+---
+
+### Bait'n'switch
+
+- pre-commit: Replace all staged symlinks (when pointing to annexed files) with plaintext files containing the key of their respective annexed content, re-stage, and add their paths (relative to repo root) to .gitignore.
+- post-commit: Replace the plaintext files with (git annex fix'ed) symlinks.
+
+In doing so, the blobs to be committed can remain unaltered, irrespective of their related files' depth in the directory hierarchy.
+
+To prevent git from reporting ALL annexed files as unstaged changes after running post-commit hook, their paths would need to be added to .gitignore.
+
+This wouldn't cause any issues when adding files, very little when modifying files (would need some alterations to \"git annex unlock\"), BUT would make git totally oblivious to removals...
+
+---
+
+### Manifest-based (re)population
+- Keep a manifest of all annexed files (key + relative path)
+- DON'T track the symlinks (.gitignore)
+- Populate/update the directory structure using a post-commit hook.
+
+... thus circumventing the issue entirely, yet diffstats (et al.) would be rather uninformative.
+
+---
+
+***Wide open to suggestions, criticism, mocking laughter and finger-pointing :)***
+"""]]
diff --git a/doc/bugs/git_rename_detection_on_file_move/comment_5_d61f5693d947b9736b29fca1dbc7ad76._comment b/doc/bugs/git_rename_detection_on_file_move/comment_5_d61f5693d947b9736b29fca1dbc7ad76._comment
new file mode 100644
index 0000000000..93db97e704
--- /dev/null
+++ b/doc/bugs/git_rename_detection_on_file_move/comment_5_d61f5693d947b9736b29fca1dbc7ad76._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="praet"
+ ip="81.242.56.203"
+ subject="comment 5"
+ date="2011-03-21T19:58:34Z"
+ content="""
+In the meantime, would it be acceptable to split the pre-commit hook
+into two discrete parts?
+
+This would allow to (if preferred) defer \"git annex fix\" until
+post-commit while still keeping the safety net for unlocked files.
+"""]]
diff --git a/doc/bugs/git_rename_detection_on_file_move/comment_6_f63de6fe2f7189c8c2908cc41c4bc963._comment b/doc/bugs/git_rename_detection_on_file_move/comment_6_f63de6fe2f7189c8c2908cc41c4bc963._comment
new file mode 100644
index 0000000000..7398ac5614
--- /dev/null
+++ b/doc/bugs/git_rename_detection_on_file_move/comment_6_f63de6fe2f7189c8c2908cc41c4bc963._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="extra level of indirection"
+ date="2011-12-19T12:45:18Z"
+ content="""
+Surely this could be handled with an extra layer of indirection?
+
+git-annex would ensure that every directory containing annexed data contains a new symlink `.git-annex` which points to `$git_root/.git/annex`.  Then every symlink to an annexed object uses a relative symlink via this: `.git_annex/objects/xx/yy/ZZZZZZZZZZ`.  Even though this symlink is relative, moving it to a different directory would not break anything: if the move destination directory already contained other annexed data, it would also already contain `.git-annex` so git-annex wouldn't need to do anything.  And if it didn't, git-annex would simply create a new `.git-annex` symlink there.
+
+These `.git-annex` symlinks could either be added to `.gitignore`, or manually/automatically checked in to the current branch - I'm not sure which would be best.  There's also the option of using multiple levels of indirection:
+
+    foo/bar/baz/.git-annex -> ../.git-annex
+    foo/bar/.git-annex -> ../.git-annex
+    foo/.git-annex -> ../.git-annex
+    .git-annex -> .git/annex
+
+I'm not sure whether this would bring any advantages.  It might bring a performance hit due to the kernel having to traverse more symlinks, but without benchmarking it's difficult to say how much.  I'd expect it only to be an issue with a large number of deep directory trees.
+"""]]
diff --git a/doc/bugs/git_rename_detection_on_file_move/comment_7_7f20d0b2f6ed1c34021a135438037306._comment b/doc/bugs/git_rename_detection_on_file_move/comment_7_7f20d0b2f6ed1c34021a135438037306._comment
new file mode 100644
index 0000000000..0a045feb63
--- /dev/null
+++ b/doc/bugs/git_rename_detection_on_file_move/comment_7_7f20d0b2f6ed1c34021a135438037306._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 7"
+ date="2011-12-19T18:22:25Z"
+ content="""
+That seems an excellent idea, also eliminating the need for git annex fix after moving. 
+
+However, I think CVS and svn have taught us the pain associated with a version control system putting something in every subdirectory. Would this pain be worth avoiding the minor pain of needing git annex fix and sometimes being unable to follow renames?
+"""]]
diff --git a/doc/bugs/git_rename_detection_on_file_move/comment_8_6a00500b24ba53248c78e1ffc8d1a591._comment b/doc/bugs/git_rename_detection_on_file_move/comment_8_6a00500b24ba53248c78e1ffc8d1a591._comment
new file mode 100644
index 0000000000..d53022302d
--- /dev/null
+++ b/doc/bugs/git_rename_detection_on_file_move/comment_8_6a00500b24ba53248c78e1ffc8d1a591._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="comment 8"
+ date="2011-12-20T12:00:11Z"
+ content="""
+Personally I'd rather have working rename detection but I agree it's not 100% ideal to be littering multiple directories like this, so perhaps you could make it optional, e.g. based on a git config setting?
+
+Here are a few more considerations, some in defence of the approach, some against it:
+
+* `.git-annex` is hidden; `CVS/` is not.
+* Unlike `CVS/` and `.svn/`, it's only a symlink, not a directory containing other files.
+* It doesn't contain any data specific to that directory and could easily be regenerated if deleted accidentally or otherwise.
+* If a whole directory containing `.git-annex` was moved within the repository:
+    * git-annex would need to fix up these symlinks if and only if it's moved to a different depth within the tree.
+    * However, if the multi-level indirection approach is used, `.git-annex` in any subdirectory is *always* a symlink to `../.git-annex` so instead you would need to check that all of the new ancestors contain this symlink too, and optionally remove any no longer needed symlinks.
+    * In either case, git-annex already goes to the trouble of fixing symlinks, and if anything, I *think* this approach would reduce the number of symlinks which need checking (right?)
+* find `$git_root/foo -follow`, `diff -r` etc. would traverse into `$git_root/.git/annex`
+
+This last point is the only downside to this approach I can think of which gives me any noticeable cause for concern.  However, people are already use to working around this from CVS and svn days, e.g. `diff -r -x .svn` so I don't think it's anywhere near bad enough to rule it out.
+"""]]
diff --git a/doc/bugs/git_rename_detection_on_file_move/comment_9_75e0973f6d573df615e01005ebcea87d._comment b/doc/bugs/git_rename_detection_on_file_move/comment_9_75e0973f6d573df615e01005ebcea87d._comment
new file mode 100644
index 0000000000..919455bdcc
--- /dev/null
+++ b/doc/bugs/git_rename_detection_on_file_move/comment_9_75e0973f6d573df615e01005ebcea87d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 9"
+ date="2011-12-20T14:56:12Z"
+ content="""
+Git can follow the rename fine if the file is committed before `git annex fix` (you can git commit -n to see this), so 
+making git-annex pre-commit generate a fixup commit before the staged commit would be one way. Or the other two ways I originally mentioned when writing down this minor issue. I like all those approaches better than .git-annex clutter.
+"""]]
diff --git a/doc/bugs/git_worktree_remove_fails.mdwn b/doc/bugs/git_worktree_remove_fails.mdwn
new file mode 100644
index 0000000000..d4c2e660fb
--- /dev/null
+++ b/doc/bugs/git_worktree_remove_fails.mdwn
@@ -0,0 +1 @@
+"git worktree remove" fails if git-annex has operated on the worktree, because git expects .git in a worktree to be a file, while git-annex changes it to a symlink ([[tips/Using_git-worktree_with_annex/]]).  Also, git-annex-test does not currently seem to test git-annex operation on worktrees added by git-worktree?
diff --git a/doc/bugs/git_worktree_remove_fails/comment_1_e980c49fb53a785337e206feae34d032._comment b/doc/bugs/git_worktree_remove_fails/comment_1_e980c49fb53a785337e206feae34d032._comment
new file mode 100644
index 0000000000..50dbddf65e
--- /dev/null
+++ b/doc/bugs/git_worktree_remove_fails/comment_1_e980c49fb53a785337e206feae34d032._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-03-18T17:35:20Z"
+ content="""
+This seems like something the git developers might consider a bug in git
+worktree, since generally git doesn't care if .git is a symlink or a
+pointer file. 
+
+Although perhaps the reason it checks is to avoid deleting something it
+didn't set up.
+
+I don't see any way to improve this in git-annex though, if .git is not a
+symlink then every git-annex symlink in the repository will need to change
+to point to the real path to .git/annex/objects, which is not practical.
+"""]]
diff --git a/doc/bugs/git_worktree_remove_fails/comment_2_2c6ce2244c885bb21ca82a841987dd47._comment b/doc/bugs/git_worktree_remove_fails/comment_2_2c6ce2244c885bb21ca82a841987dd47._comment
new file mode 100644
index 0000000000..3432119722
--- /dev/null
+++ b/doc/bugs/git_worktree_remove_fails/comment_2_2c6ce2244c885bb21ca82a841987dd47._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-03-18T19:54:04Z"
+ content="""
+Maybe git considers .git an internal detail, so they might not guarantee things working correctly if it's changed to a symlink?
+A clean way to handle this would be to add a 'git annex worktree' command, which normally just passes the rest of the command line to 'git worktree', but handles any git-annex-specific details as needed: e.g. 'git annex worktree add' calls 'git worktree add' then replaces the .git pointer file with symlink; 'git annex worktree remove' puts the .git pointer back then calls 'git worktree remove', etc. 
+"""]]
diff --git a/doc/bugs/glacier_from_multiple_repos.mdwn b/doc/bugs/glacier_from_multiple_repos.mdwn
new file mode 100644
index 0000000000..3b6bb57f72
--- /dev/null
+++ b/doc/bugs/glacier_from_multiple_repos.mdwn
@@ -0,0 +1,16 @@
+glacier-cli currently relies on a local cache of
+inventory information, and so other git-annexes using the same glacier
+repository are not able to access stuff in it, unless and until
+`glacier vault sync` is run.
+
+An example of this causing trouble is with the assistant. When a file is
+moved into archive/, the assistant that sends it to glacier is able to
+trust that it's in glacier and remove the local copy. But other assistants
+that also have a copy cannot trust that, and so don't remove their copies.
+
+I've discussed with glacier-cli's author making git-annex store enough info
+in its branch to be able to bootstrap glacier-cli to know about a file.
+This seems doable and he had a design; waiting on movement 
+on the glacier-cli side.
+
+[[!tag confirmed]]
diff --git a/doc/bugs/gpg-agent.mdwn b/doc/bugs/gpg-agent.mdwn
new file mode 100644
index 0000000000..df5106a8c6
--- /dev/null
+++ b/doc/bugs/gpg-agent.mdwn
@@ -0,0 +1,5049 @@
+### Please describe the problem.
+I'm running git-annex on OSX 10.9.3. The problem is that during sync with an git-annex remote the system gets flooded with gpg-agent processes which are never stopped, eventually running out of user processes.
+
+[[!tag moreinfo]]
+
+### What steps will reproduce the problem?
+Any synchronization of a lot of files with a git-annex remote.
+
+### What version of git-annex are you using? On what operating system?
+5.20140517-g0aed6d9.
+
+The problem did not appear on any older version.
+
+### Please provide any additional information below.
+
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+[2014-05-25 18:15:53 CEST] main: starting assistant version 5.20140517-g0aed6d9
+[2014-05-25 18:16:02 CEST] main: Syncing with diskstation 
+Everything up-to-date
+[2014-05-25 18:16:16 CEST] UpgradeWatcher: Finished upgrading git-annex to version 5.20140517-g0aed6d9 
+[2014-05-25 18:16:16 CEST] TransferScanner: Syncing with diskstation 
+Already up-to-date.
+Already up-to-date.
+Everything up-to-date
+[2014-05-25 18:16:36 CEST] main: Syncing with diskstation 
+remote: merge git-annex (merging synced/git-annex into git-annex...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   95ae98a..16f51d5  git-annex -> synced/git-annex
+
+WORM-s196517551-m1400608062--An Introduction to d3.js - From Scattered to Scatterplot%01_introduction.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3670016   1%    3.40MB/s    0:00:55
+     6750208   3%    3.17MB/s    0:00:58
+     9830400   5%    3.09MB/s    0:00:59
+    12976128   6%    3.03MB/s    0:00:59
+    15990784   8%    2.90MB/s    0:01:00
+    18644992   9%    2.79MB/s    0:01:02
+    21528576  10%    2.75MB/s    0:01:02
+    24543232  12%    2.73MB/s    0:01:01
+    27557888  14%    2.72MB/s    0:01:00
+    30834688  15%    2.85MB/s    0:00:56
+    33980416  17%    2.89MB/s    0:00:55
+    36995072  18%    2.88MB/s    0:00:54
+    40108032  20%    2.91MB/s    0:00:52
+    42991616  21%    2.83MB/s    0:00:52
+    45875200  23%    2.79MB/s    0:00:52
+    48857088  24%    2.78MB/s    0:00:51
+    51740672  26%    2.72MB/s    0:00:51
+    54755328  27%    2.75MB/s    0:00:50
+    57638912  29%    2.74MB/s    0:00:49
+    59998208  30%    2.60MB/s    0:00:51
+    62947328  32%    2.61MB/s    0:00:49
+    65961984  33%    2.60MB/s    0:00:49
+    68845568  35%    2.60MB/s    0:00:48
+    71729152  36%    2.73MB/s    0:00:44
+    74743808  38%    2.74MB/s    0:00:43
+    77627392  39%    2.72MB/s    0:00:42
+    80642048  41%    2.76MB/s    0:00:41
+    83656704  42%    2.78MB/s    0:00:39
+    86540288  44%    2.76MB/s    0:00:38
+    89292800  45%    2.72MB/s    0:00:38
+    91389952  46%    2.51MB/s    0:00:40
+    94404608  48%    2.50MB/s    0:00:39
+    97288192  49%    2.49MB/s    0:00:38
+   100040704  50%    2.49MB/s    0:00:37
+   102924288  52%    2.66MB/s    0:00:34
+   105807872  53%    2.65MB/s    0:00:33
+   108691456  55%    2.67MB/s    0:00:32
+   111443968  56%    2.65MB/s    0:00:31
+   114196480  58%    2.63MB/s    0:00:30
+   117342208  59%    2.66MB/s    0:00:29
+   120225792  61%    2.66MB/s    0:00:27
+   123109376  62%    2.70MB/s    0:00:26
+   125992960  64%    2.73MB/s    0:00:25
+   128745472  65%    2.67MB/s    0:00:24
+   131760128  67%    2.70MB/s    0:00:23
+   134643712  68%    2.70MB/s    0:00:22
+   137396224  69%    2.65MB/s    0:00:21
+   140410880  71%    2.72MB/s    0:00:20
+   143294464  72%    2.70MB/s    0:00:19
+   145915904  74%    2.60MB/s    0:00:19
+   148275200  75%    2.50MB/s    0:00:18
+   150896640  76%    2.41MB/s    0:00:18
+   153780224  78%    2.41MB/s    0:00:17
+   157057024  79%    2.60MB/s    0:00:14
+   160202752  81%    2.79MB/s    0:00:12
+   163217408  83%    2.87MB/s    0:00:11
+   166100992  84%    2.86MB/s    0:00:10
+   168984576  85%    2.75MB/s    0:00:09
+   171737088  87%    2.68MB/s    0:00:09
+   174817280  88%    2.68MB/s    0:00:07
+   177831936  90%    2.71MB/s    0:00:06
+   180846592  92%    2.75MB/s    0:00:05
+   183730176  93%    2.77MB/s    0:00:04
+   186875904  95%    2.80MB/s    0:00:03
+   190021632  96%    2.84MB/s    0:00:02
+   192970752  98%    2.85MB/s    0:00:01
+   195854336  99%    2.87MB/s    0:00:00
+   196517551 100%    2.72MB/s    0:01:08 (xfer#1, to-check=0/1)
+
+sent 196541725 bytes  received 42 bytes  2787826.48 bytes/sec
+total size is 196517551  speedup is 1.00
+[2014-05-25 18:17:58 CEST] Transferrer: Uploaded 01_introduction.mp4
+[2014-05-25 18:17:58 CEST] Pusher: Syncing with diskstation 
+
+WORM-s57838296-m1400607924--An Introduction to d3.js - From Scattered to Scatterplot%02_setting-up.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4030464   6%    3.75MB/s    0:00:14
+     6782976  11%    3.15MB/s    0:00:15
+     9535488  16%    2.96MB/s    0:00:15
+    12288000  21%    2.88MB/s    0:00:15
+    15040512  26%    2.58MB/s    0:00:16
+    17793024  30%    2.60MB/s    0:00:15
+    20545536  35%    2.61MB/s    0:00:13
+    23560192  40%    2.66MB/s    0:00:12
+    26705920  46%    2.76MB/s    0:00:11
+    29720576  51%    2.80MB/s    0:00:09
+    32604160  56%    2.81MB/s    0:00:08
+remote: merge git-annex (merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   16f51d5..b142966  git-annex -> synced/git-annex
+    35356672  61%    2.76MB/s    0:00:07
+    38371328  66%    2.73MB/s    0:00:06
+[2014-05-25 18:18:14 CEST] RemoteControl: Syncing with diskstation 
+    41648128  72%    2.79MB/s    0:00:05
+    44761088  77%    2.86MB/s    0:00:04
+    47841280  82%    2.92MB/s    0:00:03
+    50855936  87%    2.92MB/s    0:00:02
+    53870592  93%    2.86MB/s    0:00:01
+    56885248  98%    2.81MB/s    0:00:00
+    57838296 100%    2.80MB/s    0:00:19 (xfer#1, to-check=0/1)
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   95ae98a..5809ceb  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at b1429660ab35f95d5bc54e4d8b4f39a19fe66998 but expected 16f51d51d23bf026556435a5cea88488ae0ab108
+ ! 16f51d5..b142966  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+sent 57845539 bytes  received 42 bytes  2690492.14 bytes/sec
+total size is 57838296  speedup is 1.00
+[2014-05-25 18:18:22 CEST] Transferrer: Uploaded 02_setting-up.mp4
+[2014-05-25 18:18:23 CEST] Pusher: Syncing with diskstation 
+
+WORM-s149069061-m1401033118--An Introduction to d3.js - From Scattered to Scatterplot%03_selecting-and-creating-elements.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4063232   2%    3.60MB/s    0:00:39
+remote: merge git-annex      6815744   4%    3.12MB/s    0:00:44
+     9568256   6%    2.96MB/s    0:00:46
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+[2014-05-25 18:18:28 CEST] RemoteControl: Syncing with diskstation 
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   b142966..7713a32  git-annex -> synced/git-annex
+    12582912   8%    2.93MB/s    0:00:45
+    15466496  10%    2.70MB/s    0:00:48
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   5809ceb..19d05e5  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 7713a32f85cf1d993948f15859f0d035d63aa6e0 but expected b1429660ab35f95d5bc54e4d8b4f39a19fe66998
+ ! b142966..7713a32  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    18448384  12%    2.75MB/s    0:00:46
+    21594112  14%    2.83MB/s    0:00:44
+    24477696  16%    2.80MB/s    0:00:43
+    27492352  18%    2.84MB/s    0:00:41
+    30375936  20%    2.80MB/s    0:00:41
+    33587200  22%    2.83MB/s    0:00:39
+    36601856  24%    2.85MB/s    0:00:38
+    39616512  26%    2.82MB/s    0:00:37
+    42041344  28%    2.73MB/s    0:00:38
+    45056000  30%    2.67MB/s    0:00:37
+    48037888  32%    2.66MB/s    0:00:37
+    50855936  34%    2.64MB/s    0:00:36
+    52756480  35%    2.52MB/s    0:00:37
+    54853632  36%    2.26MB/s    0:00:40
+    56950784  38%    2.02MB/s    0:00:44
+    58916864  39%    1.81MB/s    0:00:48
+    61669376  41%    2.00MB/s    0:00:42
+    64552960  43%    2.23MB/s    0:00:36
+    67567616  45%    2.48MB/s    0:00:32
+    70713344  47%    2.77MB/s    0:00:27
+    73859072  49%    2.84MB/s    0:00:25
+    76873728  51%    2.85MB/s    0:00:24
+    79888384  53%    2.85MB/s    0:00:23
+    82903040  55%    2.81MB/s    0:00:22
+    85786624  57%    2.77MB/s    0:00:22
+    88571904  59%    2.73MB/s    0:00:21
+    91422720  61%    2.70MB/s    0:00:20
+    94502912  63%    2.73MB/s    0:00:19
+    97288192  65%    2.68MB/s    0:00:18
+   100335616  67%    2.72MB/s    0:00:17
+   103350272  69%    2.77MB/s    0:00:16
+   106364928  71%    2.73MB/s    0:00:15
+   109379584  73%    2.82MB/s    0:00:13
+   112394240  75%    2.79MB/s    0:00:12
+   115376128  77%    2.76MB/s    0:00:11
+   118390784  79%    2.76MB/s    0:00:10
+   121536512  81%    2.80MB/s    0:00:09
+   124682240  83%    2.85MB/s    0:00:08
+   127827968  85%    2.90MB/s    0:00:07
+   130842624  87%    2.91MB/s    0:00:06
+   133988352  89%    2.91MB/s    0:00:05
+   137003008  91%    2.88MB/s    0:00:04
+   140017664  93%    2.86MB/s    0:00:03
+   142901248  95%    2.85MB/s    0:00:02
+   145588224  97%    2.71MB/s    0:00:01
+   148537344  99%    2.71MB/s    0:00:00
+   149069061 100%    2.71MB/s    0:00:52 (xfer#1, to-check=0/1)
+
+sent 149087462 bytes  received 42 bytes  2786682.32 bytes/sec
+total size is 149069061  speedup is 1.00
+[2014-05-25 18:19:18 CEST] Transferrer: Uploaded 03_select..ments.mp4
+[2014-05-25 18:19:18 CEST] Pusher: Syncing with diskstation 
+
+WORM-s36798210-m1400608746--An Introduction to d3.js - From Scattered to Scatterplot%04_exercise-1.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4227072  11%    3.89MB/s    0:00:08
+     7143424  19%    3.32MB/s    0:00:08
+    10158080  27%    3.15MB/s    0:00:08
+remote: merge git-annex     13172736  35%    3.07MB/s    0:00:07
+[2014-05-25 18:19:24 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   7713a32..c892127  git-annex -> synced/git-annex
+    16187392  43%    2.81MB/s    0:00:07
+    19136512  52%    2.83MB/s    0:00:06
+    22282240  60%    2.88MB/s    0:00:04
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   19d05e5..928f25d  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at c8921270e51c1eb7f5f88a288adbd778711d0ff0 but expected 7713a32f85cf1d993948f15859f0d035d63aa6e0
+ ! 7713a32..c892127  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    25296896  68%    2.88MB/s    0:00:03
+    28442624  77%    2.88MB/s    0:00:02
+    31457280  85%    2.88MB/s    0:00:01
+    34603008  94%    2.84MB/s    0:00:00
+    36798210 100%    2.94MB/s    0:00:11 (xfer#1, to-check=0/1)
+
+sent 36802881 bytes  received 42 bytes  2538132.62 bytes/sec
+total size is 36798210  speedup is 1.00
+[2014-05-25 18:19:32 CEST] Transferrer: Uploaded 04_exercise-1.mp4
+[2014-05-25 18:19:32 CEST] Pusher: Syncing with diskstation 
+
+WORM-s272759172-m1400608447--An Introduction to d3.js - From Scattered to Scatterplot%05_svg.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4227072   1%    3.97MB/s    0:01:06
+     7241728   2%    3.39MB/s    0:01:16
+    10256384   3%    3.17MB/s    0:01:20
+remote: merge git-annex     13402112   4%    3.11MB/s    0:01:21
+    16416768   6%    2.83MB/s    0:01:28
+[2014-05-25 18:19:38 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   c892127..ff739c0  git-annex -> synced/git-annex
+    19431424   7%    2.83MB/s    0:01:27
+    22446080   8%    2.85MB/s    0:01:25
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   928f25d..383d246  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at ff739c08bd8881b7d1c3fd6c305b0d80b3213b0d but expected c8921270e51c1eb7f5f88a288adbd778711d0ff0
+ ! c892127..ff739c0  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    25591808   9%    2.83MB/s    0:01:25
+    28606464  10%    2.81MB/s    0:01:24
+    31621120  11%    2.82MB/s    0:01:23
+    34766848  12%    2.83MB/s    0:01:22
+    37781504  13%    2.83MB/s    0:01:21
+    40927232  15%    2.87MB/s    0:01:18
+    44072960  16%    2.89MB/s    0:01:17
+    47087616  17%    2.89MB/s    0:01:16
+    50397184  18%    2.95MB/s    0:01:13
+    53411840  19%    2.93MB/s    0:01:13
+    56295424  20%    2.89MB/s    0:01:13
+    59146240  21%    2.84MB/s    0:01:13
+    62160896  22%    2.78MB/s    0:01:13
+    65306624  23%    2.82MB/s    0:01:11
+    68321280  25%    2.84MB/s    0:01:10
+    71335936  26%    2.86MB/s    0:01:08
+    74350592  27%    2.85MB/s    0:01:07
+    77365248  28%    2.80MB/s    0:01:08
+    80379904  29%    2.80MB/s    0:01:07
+    83394560  30%    2.82MB/s    0:01:05
+    86540288  31%    2.84MB/s    0:01:04
+    89554944  32%    2.85MB/s    0:01:02
+    92569600  33%    2.86MB/s    0:01:01
+    95453184  34%    2.81MB/s    0:01:01
+    98336768  36%    2.76MB/s    0:01:01
+   101220352  37%    2.74MB/s    0:01:01
+   104103936  38%    2.70MB/s    0:01:00
+   107118592  39%    2.75MB/s    0:00:58
+   110002176  40%    2.74MB/s    0:00:58
+   113016832  41%    2.75MB/s    0:00:56
+   115113984  42%    2.57MB/s    0:00:59
+   117342208  43%    2.37MB/s    0:01:04
+   120356864  44%    2.40MB/s    0:01:02
+   123371520  45%    2.41MB/s    0:01:00
+   126386176  46%    2.61MB/s    0:00:54
+   129335296  47%    2.77MB/s    0:00:50
+   132481024  48%    2.80MB/s    0:00:48
+   135626752  49%    2.83MB/s    0:00:47
+   138772480  50%    2.86MB/s    0:00:45
+   141656064  51%    2.88MB/s    0:00:44
+   144572416  53%    2.83MB/s    0:00:44
+   147456000  54%    2.78MB/s    0:00:43
+   150732800  55%    2.84MB/s    0:00:41
+   153845760  56%    2.89MB/s    0:00:40
+   156860416  57%    2.88MB/s    0:00:39
+   159875072  58%    2.89MB/s    0:00:38
+   162889728  59%    2.83MB/s    0:00:37
+   165904384  60%    2.79MB/s    0:00:37
+   168919040  61%    2.80MB/s    0:00:36
+   172064768  63%    2.82MB/s    0:00:34
+   175079424  64%    2.79MB/s    0:00:34
+   178094080  65%    2.79MB/s    0:00:33
+   180977664  66%    2.77MB/s    0:00:32
+   183861248  67%    2.74MB/s    0:00:31
+   186875904  68%    2.76MB/s    0:00:30
+   190152704  69%    2.81MB/s    0:00:28
+   193298432  70%    2.86MB/s    0:00:27
+   196313088  71%    2.87MB/s    0:00:26
+   199458816  73%    2.92MB/s    0:00:24
+   202473472  74%    2.86MB/s    0:00:23
+   205455360  75%    2.82MB/s    0:00:23
+   208207872  76%    2.76MB/s    0:00:22
+   211091456  77%    2.69MB/s    0:00:22
+   214237184  78%    2.74MB/s    0:00:20
+   217251840  79%    2.77MB/s    0:00:19
+   220266496  80%    2.81MB/s    0:00:18
+   223019008  81%    2.77MB/s    0:00:17
+   225247232  82%    2.54MB/s    0:00:18
+   228261888  83%    2.54MB/s    0:00:17
+   231145472  84%    2.52MB/s    0:00:16
+   234160128  85%    2.58MB/s    0:00:14
+   237043712  86%    2.74MB/s    0:00:12
+   240091136  88%    2.76MB/s    0:00:11
+   243073024  89%    2.78MB/s    0:00:10
+   246087680  90%    2.79MB/s    0:00:09
+   248971264  91%    2.81MB/s    0:00:08
+   251723776  92%    2.71MB/s    0:00:07
+   254738432  93%    2.73MB/s    0:00:06
+   257884160  94%    2.75MB/s    0:00:05
+   261029888  95%    2.80MB/s    0:00:04
+   263913472  96%    2.85MB/s    0:00:03
+   266928128  97%    2.87MB/s    0:00:01
+   269942784  98%    2.83MB/s    0:00:00
+   272759172 100%    2.80MB/s    0:01:32 (xfer#1, to-check=0/1)
+
+sent 272792641 bytes  received 42 bytes  2886695.06 bytes/sec
+total size is 272759172  speedup is 1.00
+[2014-05-25 18:21:07 CEST] Transferrer: Uploaded 05_svg.mp4
+[2014-05-25 18:21:07 CEST] Pusher: Syncing with diskstation 
+
+WORM-s29712591-m1400608733--An Introduction to d3.js - From Scattered to Scatterplot%06_exercise-2.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4259840  14%    4.00MB/s    0:00:06
+     7274496  24%    3.44MB/s    0:00:06
+    10289152  34%    3.24MB/s    0:00:05
+remote: merge git-annex     13434880  45%    3.17MB/s    0:00:05
+    16678912  56%    2.92MB/s    0:00:04
+[2014-05-25 18:21:13 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   ff739c0..07153a2  git-annex -> synced/git-annex
+    19693568  66%    2.89MB/s    0:00:03
+    22740992  76%    2.86MB/s    0:00:02
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   383d246..1749643  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 07153a2d49264b9792593fc016c00499ce87f70b but expected ff739c08bd8881b7d1c3fd6c305b0d80b3213b0d
+ ! ff739c0..07153a2  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    25624576  86%    2.81MB/s    0:00:01
+    28639232  96%    2.75MB/s    0:00:00
+    29712591 100%    2.94MB/s    0:00:09 (xfer#1, to-check=0/1)
+
+sent 29716398 bytes  received 42 bytes  2584038.26 bytes/sec
+total size is 29712591  speedup is 1.00
+[2014-05-25 18:21:18 CEST] Transferrer: Uploaded 06_exercise-2.mp4
+[2014-05-25 18:21:18 CEST] Pusher: Syncing with diskstation 
+
+WORM-s276749404-m1400608181--An Introduction to d3.js - From Scattered to Scatterplot%07_binding-data-and-creating-elements-from-data.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4030464   1%    3.60MB/s    0:01:13
+     7307264   2%    3.29MB/s    0:01:19
+remote: merge git-annex     10190848   3%    3.11MB/s    0:01:23
+    13336576   4%    3.06MB/s    0:01:24
+[2014-05-25 18:21:24 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   07153a2..0a42aa9  git-annex -> synced/git-annex
+    16482304   5%    2.89MB/s    0:01:27
+    19496960   7%    2.85MB/s    0:01:28
+    22642688   8%    2.89MB/s    0:01:25
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   1749643..e6798ff  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 0a42aa9412e0a0f03e8edaa7a37eb0d6273bc4d9 but expected 07153a2d49264b9792593fc016c00499ce87f70b
+ ! 07153a2..0a42aa9  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    25788416   9%    2.88MB/s    0:01:25
+    28803072  10%    2.84MB/s    0:01:25
+    31817728  11%    2.84MB/s    0:01:24
+    34832384  12%    2.83MB/s    0:01:23
+    37978112  13%    2.84MB/s    0:01:22
+    40828928  14%    2.82MB/s    0:01:21
+    43974656  15%    2.83MB/s    0:01:20
+    46956544  16%    2.84MB/s    0:01:18
+    50233344  18%    2.88MB/s    0:01:16
+    53248000  19%    2.91MB/s    0:01:15
+    56262656  20%    2.88MB/s    0:01:14
+    59146240  21%    2.84MB/s    0:01:14
+    62291968  22%    2.81MB/s    0:01:14
+    65699840  23%    2.89MB/s    0:01:11
+    68812800  24%    2.91MB/s    0:01:09
+    71892992  25%    2.97MB/s    0:01:07
+    75038720  27%    2.95MB/s    0:01:06
+    78020608  28%    2.87MB/s    0:01:07
+    81166336  29%    2.88MB/s    0:01:06
+    84049920  30%    2.83MB/s    0:01:06
+    86769664  31%    2.76MB/s    0:01:07
+    89653248  32%    2.73MB/s    0:01:06
+    92536832  33%    2.66MB/s    0:01:07
+    95420416  34%    2.66MB/s    0:01:06
+    98304000  35%    2.69MB/s    0:01:04
+   101187584  36%    2.69MB/s    0:01:03
+   104202240  37%    2.75MB/s    0:01:01
+   107216896  38%    2.76MB/s    0:00:59
+   110100480  39%    2.77MB/s    0:00:58
+   113016832  40%    2.78MB/s    0:00:57
+   115867648  41%    2.74MB/s    0:00:57
+   118620160  42%    2.71MB/s    0:00:57
+   121503744  43%    2.69MB/s    0:00:56
+   124452864  44%    2.67MB/s    0:00:55
+   127467520  46%    2.70MB/s    0:00:53
+   130220032  47%    2.69MB/s    0:00:53
+   132972544  48%    2.68MB/s    0:00:52
+   135987200  49%    2.70MB/s    0:00:50
+   138870784  50%    2.68MB/s    0:00:50
+   141754368  51%    2.72MB/s    0:00:48
+   144474112  52%    2.71MB/s    0:00:47
+   147357696  53%    2.68MB/s    0:00:47
+   150372352  54%    2.70MB/s    0:00:45
+   153387008  55%    2.71MB/s    0:00:44
+   156401664  56%    2.76MB/s    0:00:42
+   159416320  57%    2.79MB/s    0:00:41
+   162299904  58%    2.78MB/s    0:00:40
+   165445632  59%    2.80MB/s    0:00:38
+   168460288  60%    2.82MB/s    0:00:37
+   171343872  61%    2.79MB/s    0:00:36
+   174227456  62%    2.78MB/s    0:00:36
+   177373184  64%    2.78MB/s    0:00:34
+   180387840  65%    2.79MB/s    0:00:33
+   183533568  66%    2.86MB/s    0:00:31
+   186548224  67%    2.87MB/s    0:00:30
+   189562880  68%    2.81MB/s    0:00:30
+   192446464  69%    2.75MB/s    0:00:29
+   195461120  70%    2.71MB/s    0:00:29
+   198475776  71%    2.73MB/s    0:00:28
+   201359360  72%    2.74MB/s    0:00:26
+   204308480  73%    2.78MB/s    0:00:25
+   207060992  74%    2.72MB/s    0:00:24
+   210206720  75%    2.77MB/s    0:00:23
+   212828160  76%    2.64MB/s    0:00:23
+   215318528  77%    2.54MB/s    0:00:23
+   218333184  78%    2.58MB/s    0:00:22
+   221347840  79%    2.53MB/s    0:00:21
+   224362496  81%    2.67MB/s    0:00:19
+   227377152  82%    2.77MB/s    0:00:17
+   230129664  83%    2.74MB/s    0:00:16
+   233078784  84%    2.74MB/s    0:00:15
+   236093440  85%    2.74MB/s    0:00:14
+   239108096  86%    2.76MB/s    0:00:13
+   242122752  87%    2.83MB/s    0:00:11
+   245006336  88%    2.81MB/s    0:00:11
+   247824384  89%    2.77MB/s    0:00:10
+   250707968  90%    2.70MB/s    0:00:09
+   253460480  91%    2.63MB/s    0:00:08
+   256606208  92%    2.69MB/s    0:00:07
+   259620864  93%    2.73MB/s    0:00:06
+   262504448  94%    2.75MB/s    0:00:05
+   264994816  95%    2.63MB/s    0:00:04
+   266960896  96%    2.37MB/s    0:00:04
+   268795904  97%    2.11MB/s    0:00:03
+   271155200  97%    1.99MB/s    0:00:02
+   274038784  99%    2.14MB/s    0:00:01
+   276749404 100%    2.75MB/s    0:01:36 (xfer#1, to-check=0/1)
+
+sent 276783402 bytes  received 42 bytes  2838804.55 bytes/sec
+total size is 276749404  speedup is 1.00
+[2014-05-25 18:22:56 CEST] Transferrer: Uploaded 07_bindin..-data.mp4
+[2014-05-25 18:22:56 CEST] Pusher: Syncing with diskstation 
+
+WORM-s58893321-m1400608603--An Introduction to d3.js - From Scattered to Scatterplot%08_exercise-3.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4227072   7%    3.98MB/s    0:00:13
+     7241728  12%    3.38MB/s    0:00:14
+    10125312  17%    3.14MB/s    0:00:15
+    13139968  22%    3.05MB/s    0:00:14
+    16023552  27%    2.74MB/s    0:00:15
+remote: merge git-annex     18907136  32%    2.72MB/s    0:00:14
+[2014-05-25 18:23:04 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   0a42aa9..961714e  git-annex -> synced/git-annex
+    21790720  37%    2.72MB/s    0:00:13
+    24870912  42%    2.72MB/s    0:00:12
+    27754496  47%    2.72MB/s    0:00:11
+    30638080  52%    2.70MB/s    0:00:10
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   e6798ff..c074ab0  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 961714e5af3653435346ed0f7ae7e19efb899c6f but expected 0a42aa9412e0a0f03e8edaa7a37eb0d6273bc4d9
+ ! 0a42aa9..961714e  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    33980416  57%    2.81MB/s    0:00:08
+    36864000  62%    2.78MB/s    0:00:07
+    39616512  67%    2.76MB/s    0:00:06
+    42369024  71%    2.75MB/s    0:00:05
+    45252608  76%    2.64MB/s    0:00:05
+    48136192  81%    2.64MB/s    0:00:03
+    51150848  86%    2.67MB/s    0:00:02
+    53903360  91%    2.65MB/s    0:00:01
+    56655872  96%    2.63MB/s    0:00:00
+    58893321 100%    2.76MB/s    0:00:20 (xfer#1, to-check=0/1)
+
+sent 58900692 bytes  received 42 bytes  2617810.40 bytes/sec
+total size is 58893321  speedup is 1.00
+[2014-05-25 18:23:18 CEST] Transferrer: Uploaded 08_exercise-3.mp4
+[2014-05-25 18:23:18 CEST] Pusher: Syncing with diskstation 
+
+WORM-s134947390-m1400608565--An Introduction to d3.js - From Scattered to Scatterplot%09_transitions.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4161536   3%    3.82MB/s    0:00:33
+     7045120   5%    3.24MB/s    0:00:38
+remote: merge git-annex      9928704   7%    3.04MB/s    0:00:40
+    13205504   9%    3.05MB/s    0:00:38
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   961714e..dbdf944  git-annex -> synced/git-annex
+[2014-05-25 18:23:24 CEST] RemoteControl: Syncing with diskstation 
+    16220160  12%    2.79MB/s    0:00:41
+    19103744  14%    2.80MB/s    0:00:40
+    21856256  16%    2.79MB/s    0:00:39
+    24576000  18%    2.66MB/s    0:00:40
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   c074ab0..1e5f9f1  git-annex  -> diskstation/git-annex
+    27459584  20%    2.64MB/s    0:00:39
+    30474240  22%    2.68MB/s    0:00:38
+    33357824  24%    2.70MB/s    0:00:36
+    36372480  26%    2.76MB/s    0:00:34
+    39256064  29%    2.76MB/s    0:00:33
+    42139648  31%    2.73MB/s    0:00:33
+    45023232  33%    2.73MB/s    0:00:32
+    47775744  35%    2.66MB/s    0:00:31
+    50659328  37%    2.66MB/s    0:00:30
+    53542912  39%    2.65MB/s    0:00:29
+    56557568  41%    2.66MB/s    0:00:28
+    59310080  43%    2.67MB/s    0:00:27
+    62029824  45%    2.64MB/s    0:00:26
+    64782336  48%    2.62MB/s    0:00:26
+    67665920  50%    2.61MB/s    0:00:25
+    70680576  52%    2.64MB/s    0:00:23
+    73695232  54%    2.70MB/s    0:00:22
+    76709888  56%    2.77MB/s    0:00:20
+    79593472  58%    2.76MB/s    0:00:19
+    82608128  61%    2.79MB/s    0:00:18
+    85622784  63%    2.81MB/s    0:00:17
+    88506368  65%    2.76MB/s    0:00:16
+    91619328  67%    2.81MB/s    0:00:15
+    94502912  70%    2.78MB/s    0:00:14
+    97255424  72%    2.72MB/s    0:00:13
+   100270080  74%    2.76MB/s    0:00:12
+   102760448  76%    2.61MB/s    0:00:12
+   105349120  78%    2.54MB/s    0:00:11
+   108232704  80%    2.57MB/s    0:00:10
+   111247360  82%    2.56MB/s    0:00:09
+   114262016  84%    2.68MB/s    0:00:07
+   117145600  86%    2.76MB/s    0:00:06
+   120029184  88%    2.75MB/s    0:00:05
+   123043840  91%    2.76MB/s    0:00:04
+   125927424  93%    2.74MB/s    0:00:03
+   128942080  95%    2.76MB/s    0:00:02
+   131694592  97%    2.74MB/s    0:00:01
+   134447104  99%    2.64MB/s    0:00:00
+   134947390 100%    2.72MB/s    0:00:47 (xfer#1, to-check=0/1)
+
+sent 134964047 bytes  received 42 bytes  2726547.25 bytes/sec
+total size is 134947390  speedup is 1.00
+[2014-05-25 18:24:08 CEST] Transferrer: Uploaded 09_transitions.mp4
+[2014-05-25 18:24:08 CEST] Pusher: Syncing with diskstation 
+
+WORM-s106802484-m1399168180--An Introduction to d3.js - From Scattered to Scatterplot%10_scales-2.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4128768   3%    3.75MB/s    0:00:26
+     7143424   6%    3.27MB/s    0:00:29
+    10027008   9%    3.10MB/s    0:00:30
+remote: merge git-annex     13008896  12%    3.01MB/s    0:00:30
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+[2014-05-25 18:24:13 CEST] RemoteControl: Syncing with diskstation 
+   dbdf944..cef70b3  git-annex -> synced/git-annex
+    16154624  15%    2.81MB/s    0:00:31
+    19169280  17%    2.81MB/s    0:00:30
+    22183936  20%    2.83MB/s    0:00:29
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   1e5f9f1..af18e69  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at cef70b30ddce59c2b22b370b25420da2fa7e2b49 but expected dbdf94438b7e48971a594c7647721f4821c8cff2
+ ! dbdf944..cef70b3  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    24936448  23%    2.78MB/s    0:00:28
+    27688960  25%    2.70MB/s    0:00:28
+    30834688  28%    2.73MB/s    0:00:27
+    32899072  30%    2.50MB/s    0:00:28
+    35749888  33%    2.53MB/s    0:00:27
+    38764544  36%    2.56MB/s    0:00:25
+    41779200  39%    2.53MB/s    0:00:25
+    44072960  41%    2.60MB/s    0:00:23
+    47415296  44%    2.71MB/s    0:00:21
+    50036736  46%    2.65MB/s    0:00:20
+    52789248  49%    2.59MB/s    0:00:20
+    55672832  52%    2.72MB/s    0:00:18
+    58687488  54%    2.64MB/s    0:00:17
+    61571072  57%    2.69MB/s    0:00:16
+    64585728  60%    2.75MB/s    0:00:14
+    67207168  62%    2.65MB/s    0:00:14
+    69304320  64%    2.44MB/s    0:00:14
+    72318976  67%    2.46MB/s    0:00:13
+    75071488  70%    2.42MB/s    0:00:12
+    78020608  73%    2.53MB/s    0:00:11
+    80904192  75%    2.71MB/s    0:00:09
+    83787776  78%    2.68MB/s    0:00:08
+    86540288  81%    2.66MB/s    0:00:07
+    89423872  83%    2.64MB/s    0:00:06
+    92372992  86%    2.67MB/s    0:00:05
+    95256576  89%    2.68MB/s    0:00:04
+    98140160  91%    2.72MB/s    0:00:03
+   101154816  94%    2.74MB/s    0:00:02
+   104169472  97%    2.73MB/s    0:00:00
+   106802484 100%    2.70MB/s    0:00:37 (xfer#1, to-check=0/1)
+
+sent 106815702 bytes  received 42 bytes  2704196.05 bytes/sec
+total size is 106802484  speedup is 1.00
+[2014-05-25 18:24:47 CEST] Transferrer: Uploaded 10_scales-2.mp4
+[2014-05-25 18:24:47 CEST] Pusher: Syncing with diskstation 
+
+WORM-s106802484-m1399168180--An Introduction to d3.js - From Scattered to Scatterplot%10_scales.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3964928   3%    3.74MB/s    0:00:26
+     6848512   6%    3.19MB/s    0:00:30
+     9994240   9%    3.08MB/s    0:00:30
+remote: merge git-annex     12877824  12%    2.97MB/s    0:00:30
+    15892480  14%    2.74MB/s    0:00:32
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+[2014-05-25 18:24:53 CEST] RemoteControl: Syncing with diskstation 
+   cef70b3..bc92e4a  git-annex -> synced/git-annex
+    18644992  17%    2.71MB/s    0:00:31
+    20873216  19%    2.51MB/s    0:00:33
+    23429120  21%    2.39MB/s    0:00:34
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   af18e69..7b0c500  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at bc92e4a867338760dec749af77a9262591b9c43a but expected cef70b30ddce59c2b22b370b25420da2fa7e2b49
+ ! cef70b3..bc92e4a  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    27099136  25%    2.52MB/s    0:00:30
+    29982720  28%    2.56MB/s    0:00:29
+    32866304  30%    2.72MB/s    0:00:26
+    35880960  33%    2.88MB/s    0:00:24
+    38633472  36%    2.69MB/s    0:00:24
+    41517056  38%    2.68MB/s    0:00:23
+    44662784  41%    2.74MB/s    0:00:22
+    47546368  44%    2.72MB/s    0:00:21
+    50298880  47%    2.72MB/s    0:00:20
+    53182464  49%    2.72MB/s    0:00:19
+    56066048  52%    2.66MB/s    0:00:18
+    58949632  55%    2.67MB/s    0:00:17
+    61308928  57%    2.59MB/s    0:00:17
+    63799296  59%    2.51MB/s    0:00:16
+    66781184  62%    2.54MB/s    0:00:15
+    69697536  65%    2.53MB/s    0:00:14
+    72712192  68%    2.67MB/s    0:00:12
+    75595776  70%    2.77MB/s    0:00:10
+    78479360  73%    2.74MB/s    0:00:10
+    81428480  76%    2.75MB/s    0:00:09
+    84312064  78%    2.73MB/s    0:00:08
+    87195648  81%    2.73MB/s    0:00:07
+    90210304  84%    2.77MB/s    0:00:05
+    93192192  87%    2.76MB/s    0:00:04
+    96075776  89%    2.74MB/s    0:00:03
+    98959360  92%    2.71MB/s    0:00:02
+   101974016  95%    2.68MB/s    0:00:01
+   104857600  98%    2.68MB/s    0:00:00
+   106802484 100%    2.71MB/s    0:00:37 (xfer#1, to-check=0/1)
+
+sent 106815700 bytes  received 42 bytes  2704196.00 bytes/sec
+total size is 106802484  speedup is 1.00
+[2014-05-25 18:25:26 CEST] Transferrer: Uploaded 10_scales.mp4
+[2014-05-25 18:25:26 CEST] Pusher: Syncing with diskstation 
+
+WORM-s132805496-m1399168071--An Introduction to d3.js - From Scattered to Scatterplot%11_axes.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4096000   3%    3.82MB/s    0:00:32
+     7110656   5%    3.32MB/s    0:00:37
+     9863168   7%    3.07MB/s    0:00:39
+remote: merge git-annex     12877824   9%    3.01MB/s    0:00:38
+    15826944  11%    2.76MB/s    0:00:41
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+[2014-05-25 18:25:33 CEST] RemoteControl: Syncing with diskstation 
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   bc92e4a..cf6d3d1  git-annex -> synced/git-annex
+    18710528  14%    2.74MB/s    0:00:40
+    21594112  16%    2.78MB/s    0:00:39
+    24477696  18%    2.75MB/s    0:00:38
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   7b0c500..8393191  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at cf6d3d1e7ec71ad4d9c4a0e5256f361c58ca5e75 but expected bc92e4a867338760dec749af77a9262591b9c43a
+ ! bc92e4a..cf6d3d1  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    27230208  20%    2.70MB/s    0:00:38
+    29949952  22%    2.63MB/s    0:00:38
+    32964608  24%    2.64MB/s    0:00:36
+    35848192  26%    2.64MB/s    0:00:35
+    38862848  29%    2.69MB/s    0:00:34
+    41877504  31%    2.77MB/s    0:00:32
+    44761088  33%    2.73MB/s    0:00:31
+    47513600  35%    2.71MB/s    0:00:30
+    50135040  37%    2.61MB/s    0:00:30
+    53280768  40%    2.66MB/s    0:00:29
+    56164352  42%    2.67MB/s    0:00:28
+    59179008  44%    2.71MB/s    0:00:26
+    62062592  46%    2.79MB/s    0:00:24
+    64946176  48%    2.73MB/s    0:00:24
+    68091904  51%    2.82MB/s    0:00:22
+    71106560  53%    2.84MB/s    0:00:21
+    74055680  55%    2.83MB/s    0:00:20
+    77070336  58%    2.85MB/s    0:00:19
+    79953920  60%    2.77MB/s    0:00:18
+    82837504  62%    2.74MB/s    0:00:17
+    85590016  64%    2.72MB/s    0:00:16
+    88342528  66%    2.63MB/s    0:00:16
+    91095040  68%    2.60MB/s    0:00:15
+    94044160  70%    2.62MB/s    0:00:14
+    97058816  73%    2.66MB/s    0:00:13
+    99549184  74%    2.60MB/s    0:00:12
+   101515264  76%    2.41MB/s    0:00:12
+   103481344  77%    2.18MB/s    0:00:13
+   105578496  79%    1.93MB/s    0:00:13
+   107806720  81%    1.89MB/s    0:00:12
+   110821376  83%    2.12MB/s    0:00:10
+   113704960  85%    2.34MB/s    0:00:07
+   116719616  87%    2.60MB/s    0:00:06
+   119603200  90%    2.77MB/s    0:00:04
+   122486784  92%    2.73MB/s    0:00:03
+   125435904  94%    2.74MB/s    0:00:02
+   128450560  96%    2.74MB/s    0:00:01
+   131268608  98%    2.70MB/s    0:00:00
+   132805496 100%    2.67MB/s    0:00:47 (xfer#1, to-check=0/1)
+
+sent 132821882 bytes  received 42 bytes  2683271.19 bytes/sec
+total size is 132805496  speedup is 1.00
+[2014-05-25 18:26:16 CEST] Transferrer: Uploaded 11_axes.mp4
+[2014-05-25 18:26:16 CEST] Pusher: Syncing with diskstation 
+
+WORM-s120549770-m1399667258--An Introduction to d3.js - From Scattered to Scatterplot%12_advanced-techniques.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4096000   3%    3.77MB/s    0:00:30
+     7110656   5%    3.31MB/s    0:00:33
+    10125312   8%    3.15MB/s    0:00:34
+remote: merge git-annex     13008896  10%    3.04MB/s    0:00:34
+[2014-05-25 18:26:22 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   cf6d3d1..fef357a  git-annex -> synced/git-annex
+    15892480  13%    2.78MB/s    0:00:36
+    18776064  15%    2.75MB/s    0:00:36
+    21659648  17%    2.72MB/s    0:00:35
+    24608768  20%    2.73MB/s    0:00:34
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   8393191..9ef8d81  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at fef357aaed77f1b94344c0aeea71b30a50de247d but expected cf6d3d1e7ec71ad4d9c4a0e5256f361c58ca5e75
+ ! cf6d3d1..fef357a  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    27623424  22%    2.75MB/s    0:00:33
+    30507008  25%    2.74MB/s    0:00:32
+    33390592  27%    2.72MB/s    0:00:31
+    36405248  30%    2.74MB/s    0:00:30
+    39419904  32%    2.73MB/s    0:00:29
+    42434560  35%    2.76MB/s    0:00:27
+    45580288  37%    2.83MB/s    0:00:25
+    48594944  40%    2.83MB/s    0:00:24
+    51576832  42%    2.83MB/s    0:00:23
+    54231040  44%    2.76MB/s    0:00:23
+    57245696  47%    2.74MB/s    0:00:22
+    60260352  49%    2.73MB/s    0:00:21
+    63275008  52%    2.73MB/s    0:00:20
+    66289664  54%    2.80MB/s    0:00:18
+    69304320  57%    2.80MB/s    0:00:17
+    72187904  59%    2.77MB/s    0:00:17
+    75071488  62%    2.74MB/s    0:00:16
+    78086144  64%    2.73MB/s    0:00:15
+    80969728  67%    2.70MB/s    0:00:14
+    84115456  69%    2.75MB/s    0:00:12
+    87130112  72%    2.79MB/s    0:00:11
+    90013696  74%    2.77MB/s    0:00:10
+    92766208  76%    2.73MB/s    0:00:09
+    95780864  79%    2.70MB/s    0:00:08
+    98664448  81%    2.68MB/s    0:00:07
+   101679104  84%    2.71MB/s    0:00:06
+   104693760  86%    2.78MB/s    0:00:05
+   107511808  89%    2.74MB/s    0:00:04
+   110526464  91%    2.74MB/s    0:00:03
+   113508352  94%    2.75MB/s    0:00:02
+   116654080  96%    2.77MB/s    0:00:01
+   119668736  99%    2.82MB/s    0:00:00
+   120549770 100%    2.79MB/s    0:00:41 (xfer#1, to-check=0/1)
+
+sent 120564675 bytes  received 42 bytes  2771602.69 bytes/sec
+total size is 120549770  speedup is 1.00
+[2014-05-25 18:26:59 CEST] Transferrer: Uploaded 12_advanc..iques.mp4
+[2014-05-25 18:27:00 CEST] Pusher: Syncing with diskstation 
+
+WORM-s17591948-m1399167639--An Introduction to d3.js - From Scattered to Scatterplot%13_conclusion.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3997696  22%    3.68MB/s    0:00:03
+     6881280  39%    3.16MB/s    0:00:03
+     9764864  55%    2.99MB/s    0:00:02
+remote: merge git-annex     12910592  73%    2.99MB/s    0:00:01
+    15794176  89%    2.74MB/s    0:00:00
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+[2014-05-25 18:27:07 CEST] RemoteControl: Syncing with diskstation 
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+    17591948 100%    2.92MB/s    0:00:05 (xfer#1, to-check=0/1)
+   fef357a..28d7559  git-annex -> synced/git-annex
+
+sent 17594275 bytes  received 42 bytes  2345908.93 bytes/sec
+total size is 17591948  speedup is 1.00
+[2014-05-25 18:27:08 CEST] Transferrer: Uploaded 13_conclusion.mp4
+
+WORM-s1250093-m1389398522--C,43,43 Memory Management%01_introduction.mp4
+       32768   2%    0.00kB/s    0:00:00
+     1250093 100%   25.24MB/s    0:00:00 (xfer#1, to-check=0/1)
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   9ef8d81..740fecd  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 28d7559836e91e16f98a532c30e5a4cbaef12250 but expected fef357aaed77f1b94344c0aeea71b30a50de247d
+ ! fef357a..28d7559  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+sent 1250398 bytes  received 42 bytes  833626.67 bytes/sec
+total size is 1250093  speedup is 1.00
+[2014-05-25 18:27:10 CEST] Transferrer: Uploaded 01_introduction.mp4
+[2014-05-25 18:27:11 CEST] Pusher: Syncing with diskstation 
+
+WORM-s4072461-m1389398387--C,43,43 Memory Management%02_leaks-and-overruns.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3801088  93%    3.52MB/s    0:00:00
+     4072461 100%    3.35MB/s    0:00:01 (xfer#1, to-check=0/1)
+remote: merge git-annex 
+sent 4073116 bytes  received 42 bytes  1629263.20 bytes/sec
+total size is 4072461  speedup is 1.00
+[2014-05-25 18:27:17 CEST] Transferrer: Uploaded 02_leaks-..rruns.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+
+WORM-s10885066-m1389398446--C,43,43 Memory Management%03_stl-vector-methods-range-checking-and-sentinels.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 18:27:18 CEST] RemoteControl: Syncing with diskstation 
+   28d7559..d7a7f79  git-annex -> synced/git-annex
+     3964928  36%    3.71MB/s    0:00:01
+     6979584  64%    3.28MB/s    0:00:01
+     9797632  90%    3.08MB/s    0:00:00
+    10885066 100%    3.07MB/s    0:00:03 (xfer#1, to-check=0/1)
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   740fecd..8700b31  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at d7a7f7988fd67d9cd827311157f7633da55d2e85 but expected 28d7559836e91e16f98a532c30e5a4cbaef12250
+ ! 28d7559..d7a7f79  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+sent 10886583 bytes  received 42 bytes  1979386.36 bytes/sec
+total size is 10885066  speedup is 1.00
+[2014-05-25 18:27:22 CEST] Transferrer: Uploaded 03_stl-ve..inels.mp4
+
+WORM-s6830209-m1389398548--C,43,43 Memory Management%04_memory-leaks-part-1.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 18:27:23 CEST] Pusher: Syncing with diskstation 
+     3964928  58%    3.72MB/s    0:00:00
+     6830209 100%    3.23MB/s    0:00:00
+     6830209 100%    3.23MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 6831201 bytes  received 42 bytes  1951783.71 bytes/sec
+total size is 6830209  speedup is 1.00
+[2014-05-25 18:27:25 CEST] Transferrer: Uploaded 04_memory..art-1.mp4
+
+WORM-s4500501-m1389398494--C,43,43 Memory Management%05_memory-leaks-part-2.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      3833856  85%    3.57MB/s    0:00:00
+     4500501 100%    3.39MB/s    0:00:01 (xfer#1, to-check=0/1)
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   d7a7f79..963ef9d  git-annex -> synced/git-annex
+[2014-05-25 18:27:28 CEST] RemoteControl: Syncing with diskstation 
+
+sent 4501209 bytes  received 42 bytes  1286071.71 bytes/sec
+total size is 4500501  speedup is 1.00
+[2014-05-25 18:27:28 CEST] Transferrer: Uploaded 05_memory..art-2.mp4
+
+WORM-s4479532-m1389398463--C,43,43 Memory Management%06_pointers-pitfalls-and-best-practices.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4292608  95%    4.06MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   8700b31..8a3838b  git-annex  -> diskstation/git-annex
+     4479532 100%    4.05MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 4480253 bytes  received 42 bytes  1280084.29 bytes/sec
+total size is 4479532  speedup is 1.00
+[2014-05-25 18:27:31 CEST] Transferrer: Uploaded 06_pointe..tices.mp4
+
+WORM-s9775707-m1389398514--C,43,43 Memory Management%07_initialize-everything-trust-but-verify.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 18:27:32 CEST] Pusher: Syncing with diskstation 
+     4096000  41%    3.77MB/s    0:00:01
+     7241728  74%    3.37MB/s    0:00:00
+     9775707 100%    3.22MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 9777078 bytes  received 42 bytes  2793462.86 bytes/sec
+total size is 9775707  speedup is 1.00
+[2014-05-25 18:27:34 CEST] Transferrer: Uploaded 07_initia..erify.mp4
+remote: merge git-annex 
+WORM-s15498925-m1389398484--C,43,43 Memory Management%08_reading-and-writing-shared-assets.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3964928  25%    3.69MB/s    0:00:03
+[2014-05-25 18:27:36 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   963ef9d..d7cb480  git-annex -> synced/git-annex
+     6848512  44%    3.21MB/s    0:00:02
+     9863168  63%    3.07MB/s    0:00:01
+    13008896  83%    3.05MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   8a3838b..9dc2149  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at d7cb4801b1d5172fa94c5ef5b952650404806c5e but expected 963ef9d37e0ca48e88afccc16e3d53a7dbe94a15
+ ! 963ef9d..d7cb480  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    15498925 100%    3.04MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 15500988 bytes  received 42 bytes  2818369.09 bytes/sec
+total size is 15498925  speedup is 1.00
+[2014-05-25 18:27:41 CEST] Transferrer: Uploaded 08_readin..ssets.mp4
+[2014-05-25 18:27:41 CEST] Pusher: Syncing with diskstation 
+
+WORM-s7479394-m1389398424--C,43,43 Memory Management%09_undefined-behaviour-and-other-bad-practices.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4030464  53%    3.77MB/s    0:00:00
+remote: merge git-annex      7045120  94%    3.28MB/s    0:00:00
+     7479394 100%    3.24MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 7480490 bytes  received 42 bytes  2137294.86 bytes/sec
+total size is 7479394  speedup is 1.00
+[2014-05-25 18:27:47 CEST] RemoteControl: Syncing with diskstation 
+[2014-05-25 18:27:47 CEST] Transferrer: Uploaded 09_undefi..tices.mp4
+
+WORM-s5620037-m1389398373--C,43,43 Memory Management%10_the-heap-and-stl-wrappers.mp4
+       32768   0%    0.00kB/s    0:00:00
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   d7cb480..cebe41e  git-annex -> synced/git-annex
+     4390912  78%    4.02MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   9dc2149..2c100e7  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at cebe41ecefec0ba03838b77300b8213abff6e46f but expected d7cb4801b1d5172fa94c5ef5b952650404806c5e
+ ! d7cb480..cebe41e  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 18:27:48 CEST] RemoteControl: Syncing with diskstation 
+     5620037 100%    3.71MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 5620887 bytes  received 42 bytes  2248371.60 bytes/sec
+total size is 5620037  speedup is 1.00
+[2014-05-25 18:27:50 CEST] Transferrer: Uploaded 10_the-he..ppers.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   2c100e7..7d585c6  git-annex  -> diskstation/git-annex
+
+WORM-s1014080-m1389398563--C,43,43 Memory Management%11_about-the-author.mp4
+       32768   3%    0.00kB/s    0:00:00
+     1014080 100%   20.80MB/s    0:00:00 (xfer#1, to-check=0/1)
+
+sent 1014357 bytes  received 42 bytes  676266.00 bytes/sec
+total size is 1014080  speedup is 1.00
+[2014-05-25 18:27:51 CEST] Transferrer: Uploaded 11_about-..uthor.mp4
+[2014-05-25 18:27:52 CEST] Pusher: Syncing with diskstation 
+remote: merge git-annex (merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+[2014-05-25 18:27:56 CEST] RemoteControl: Syncing with diskstation 
+   cebe41e..1f16e00  git-annex -> synced/git-annex
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   7d585c6..25d816f  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 1f16e00081100c31ba110cc6655ba98ce9c3ccf9 but expected cebe41ecefec0ba03838b77300b8213abff6e46f
+ ! cebe41e..1f16e00  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 19:02:45 CEST] main: Syncing with diskstation 
+remote: merge git-annex ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   1f16e00..25d816f  git-annex -> synced/git-annex
+[2014-05-25 19:16:16 CEST] NetWatcherFallback: Syncing with diskstation 
+Everything up-to-date
+[2014-05-25 19:44:23 CEST] main: Syncing with diskstation 
+remote: merge git-annex (merging synced/git-annex into git-annex...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   25d816f..af358a2  git-annex -> synced/git-annex
+
+WORM-s311796310-m1396397568--Lean UX Workshop%01_introduction.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3440640   1%    3.23MB/s    0:01:33
+     6062080   1%    2.75MB/s    0:01:48
+    10518528   3%    3.15MB/s    0:01:33
+    13926400   4%    3.15MB/s    0:01:32
+    16023552   5%    2.73MB/s    0:01:45
+    20611072   6%    3.22MB/s    0:01:28
+    22315008   7%    2.58MB/s    0:01:49
+    26509312   8%    2.76MB/s    0:01:40
+    29655040   9%    3.10MB/s    0:01:28
+    33325056  10%    2.61MB/s    0:01:44
+    36470784  11%    2.96MB/s    0:01:30
+    40402944  12%    2.88MB/s    0:01:32
+    44072960  14%    2.96MB/s    0:01:28
+    47218688  15%    3.17MB/s    0:01:21
+    49840128  15%    3.04MB/s    0:01:24
+    54296576  17%    3.12MB/s    0:01:20
+    58228736  18%    3.20MB/s    0:01:17
+    61636608  19%    3.23MB/s    0:01:15
+    64782336  20%    3.40MB/s    0:01:11
+    66879488  21%    2.92MB/s    0:01:21
+    71335936  22%    3.07MB/s    0:01:16
+    75005952  24%    3.15MB/s    0:01:13
+    78151680  25%    3.14MB/s    0:01:12
+    80510976  25%    3.01MB/s    0:01:15
+    83918848  26%    2.76MB/s    0:01:20
+    86540288  27%    2.48MB/s    0:01:28
+    91291648  29%    2.83MB/s    0:01:15
+    92831744  29%    2.75MB/s    0:01:17
+    95977472  30%    2.66MB/s    0:01:19
+   100433920  32%    3.08MB/s    0:01:06
+   103841792  33%    2.77MB/s    0:01:13
+   107446272  34%    3.30MB/s    0:01:00
+   109608960  35%    3.12MB/s    0:01:03
+   113803264  36%    3.09MB/s    0:01:02
+   115900416  37%    2.68MB/s    0:01:11
+   119308288  38%    2.62MB/s    0:01:11
+   123240448  39%    2.97MB/s    0:01:01
+   126648320  40%    2.61MB/s    0:01:09
+   130580480  41%    3.09MB/s    0:00:57
+   134643712  43%    3.26MB/s    0:00:52
+   135561216  43%    2.65MB/s    0:01:04
+   140017664  44%    3.11MB/s    0:00:53
+   142639104  45%    2.82MB/s    0:00:58
+   146866176  47%    2.87MB/s    0:00:56
+   150241280  48%    3.46MB/s    0:00:45
+   152338432  48%    2.80MB/s    0:00:55
+   157220864  50%    3.31MB/s    0:00:45
+   160464896  51%    2.88MB/s    0:00:51
+   165085184  52%    3.14MB/s    0:00:45
+   167542784  53%    3.35MB/s    0:00:42
+   171638784  55%    3.18MB/s    0:00:43
+   172785664  55%    2.78MB/s    0:00:48
+   176979968  56%    2.67MB/s    0:00:49
+   179601408  57%    2.48MB/s    0:00:52
+   184254464  59%    2.60MB/s    0:00:47
+   187432960  60%    3.16MB/s    0:00:38
+   190742528  61%    2.96MB/s    0:00:39
+   194412544  62%    3.48MB/s    0:00:32
+   197525504  63%    3.12MB/s    0:00:35
+   201064448  64%    3.19MB/s    0:00:33
+   203980800  65%    3.01MB/s    0:00:35
+   208699392  66%    3.25MB/s    0:00:31
+   212369408  68%    3.36MB/s    0:00:28
+   215515136  69%    3.27MB/s    0:00:28
+   217350144  69%    3.04MB/s    0:00:30
+   221806592  71%    2.99MB/s    0:00:29
+   225378304  72%    2.94MB/s    0:00:28
+   228622336  73%    2.98MB/s    0:00:27
+   231243776  74%    3.13MB/s    0:00:25
+   233603072  74%    2.59MB/s    0:00:29
+   237273088  76%    2.35MB/s    0:00:30
+   239894528  76%    2.22MB/s    0:00:31
+   242515968  77%    2.07MB/s    0:00:32
+   244350976  78%    1.97MB/s    0:00:33
+   246448128  79%    1.87MB/s    0:00:34
+   250118144  80%    1.73MB/s    0:00:34
+   253263872  81%    2.00MB/s    0:00:28
+   254312448  81%    1.80MB/s    0:00:31
+   255885312  82%    1.58MB/s    0:00:34
+   257720320  82%    1.33MB/s    0:00:39
+   259817472  83%    1.01MB/s    0:00:50
+   261914624  84%    1.06MB/s    0:00:45
+   264011776  84%    1.08MB/s    0:00:43
+   265584640  85%    1.16MB/s    0:00:39
+   267419648  85%    1.21MB/s    0:00:35
+   272662528  87%    2.00MB/s    0:00:19
+   276856832  88%    2.77MB/s    0:00:12
+   278953984  89%    2.81MB/s    0:00:11
+   283410432  90%    3.51MB/s    0:00:07
+   288358400  92%    3.47MB/s    0:00:06
+   292323328  93%    3.32MB/s    0:00:05
+   296714240  95%    3.93MB/s    0:00:03
+   300908544  96%    3.95MB/s    0:00:02
+   303333376  97%    3.30MB/s    0:00:02
+   307789824  98%    3.53MB/s    0:00:01
+   310673408  99%    2.89MB/s    0:00:00
+   311796310 100%    2.73MB/s    0:01:48 (xfer#1, to-check=0/1)
+
+sent 311834516 bytes  received 42 bytes  2822032.20 bytes/sec
+total size is 311796310  speedup is 1.00
+[2014-05-25 19:46:46 CEST] Transferrer: Uploaded 01_introduction.mp4
+[2014-05-25 19:46:46 CEST] Pusher: Syncing with diskstation 
+
+WORM-s197776451-m1396396404--Lean UX Workshop%02_nordstrom-case-study.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5177344   2%    4.78MB/s    0:00:39
+     8683520   4%    3.74MB/s    0:00:49
+    13139968   6%    3.33MB/s    0:00:54
+remote: merge git-annex     18382848   9%    3.63MB/s    0:00:48
+    22315008  11%    3.16MB/s    0:00:54
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   af358a2..3b93fc5  git-annex -> synced/git-annex
+[2014-05-25 19:46:54 CEST] RemoteControl: Syncing with diskstation 
+    26902528  13%    3.47MB/s    0:00:48
+    29917184  15%    3.51MB/s    0:00:46
+    31653888  16%    2.82MB/s    0:00:57
+    33849344  17%    2.64MB/s    0:01:00
+    36995072  18%    2.30MB/s    0:01:08
+    41189376  20%    2.62MB/s    0:00:58
+    44859392  22%    2.97MB/s    0:00:50
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   25d816f..b7c06ab  git-annex  -> diskstation/git-annex
+    50102272  25%    3.67MB/s    0:00:39
+    52199424  26%    3.41MB/s    0:00:41
+    56655872  28%    3.47MB/s    0:00:39
+    60719104  30%    3.64MB/s    0:00:36
+    64520192  32%    3.31MB/s    0:00:39
+    68714496  34%    3.85MB/s    0:00:32
+    72876032  36%    3.79MB/s    0:00:32
+    76054528  38%    3.60MB/s    0:00:32
+    80216064  40%    3.70MB/s    0:00:31
+    83656704  42%    3.25MB/s    0:00:34
+    88899584  44%    3.48MB/s    0:00:30
+    92995584  47%    3.69MB/s    0:00:27
+    96763904  48%    3.62MB/s    0:00:27
+   100925440  51%    4.08MB/s    0:00:23
+   104628224  52%    3.73MB/s    0:00:24
+   109084672  55%    3.80MB/s    0:00:22
+   111443968  56%    3.40MB/s    0:00:24
+   116752384  59%    3.66MB/s    0:00:21
+   119046144  60%    3.33MB/s    0:00:23
+   124026880  62%    3.44MB/s    0:00:20
+   128483328  64%    3.98MB/s    0:00:16
+   132710400  67%    3.73MB/s    0:00:17
+   136871936  69%    4.17MB/s    0:00:14
+   141131776  71%    4.00MB/s    0:00:13
+   145522688  73%    4.01MB/s    0:00:12
+   149716992  75%    4.02MB/s    0:00:11
+   154173440  77%    4.08MB/s    0:00:10
+   158433280  80%    4.11MB/s    0:00:09
+   162758656  82%    4.08MB/s    0:00:08
+   166952960  84%    4.08MB/s    0:00:07
+   170459136  86%    3.85MB/s    0:00:06
+   174817280  88%    3.87MB/s    0:00:05
+   179011584  90%    3.85MB/s    0:00:04
+   183238656  92%    3.86MB/s    0:00:03
+   187367424  94%    4.01MB/s    0:00:02
+   191561728  96%    3.96MB/s    0:00:01
+   195887104  99%    3.98MB/s    0:00:00
+   197776451 100%    3.62MB/s    0:00:52 (xfer#1, to-check=0/1)
+
+sent 197800745 bytes  received 42 bytes  3697210.97 bytes/sec
+total size is 197776451  speedup is 1.00
+[2014-05-25 19:47:40 CEST] Transferrer: Uploaded 02_nordst..study.mp4
+[2014-05-25 19:47:40 CEST] Pusher: Syncing with diskstation 
+
+WORM-s401429383-m1396397422--Lean UX Workshop%03_assumptions-and-hypotheses.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5472256   1%    5.18MB/s    0:01:14
+remote: merge git-annex      9895936   2%    4.61MB/s    0:01:22
+    14188544   3%    4.41MB/s    0:01:25
+[2014-05-25 19:47:45 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   3b93fc5..02a8a6a  git-annex -> synced/git-annex
+    18808832   4%    4.39MB/s    0:01:25
+    22315008   5%    3.92MB/s    0:01:34
+    26935296   6%    3.98MB/s    0:01:31
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   b7c06ab..c1859f2  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 02a8a6a6016fd1f36acc39b27cd9e2f1b24fd394 but expected 3b93fc5ace21818579a161200a925cf8e2120c4d
+ ! 3b93fc5..02a8a6a  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    31752192   7%    4.10MB/s    0:01:28
+    36110336   8%    4.04MB/s    0:01:28
+    39616512   9%    4.02MB/s    0:01:27
+    44826624  11%    4.13MB/s    0:01:24
+    47742976  11%    3.71MB/s    0:01:33
+    52854784  13%    3.89MB/s    0:01:27
+    57180160  14%    3.87MB/s    0:01:26
+    62423040  15%    3.92MB/s    0:01:24
+    66617344  16%    4.20MB/s    0:01:17
+    71008256  17%    4.04MB/s    0:01:19
+    75333632  18%    4.30MB/s    0:01:14
+    79659008  19%    4.08MB/s    0:01:17
+    83918848  20%    4.07MB/s    0:01:16
+    88375296  22%    4.07MB/s    0:01:15
+    92700672  23%    4.04MB/s    0:01:14
+    97058816  24%    4.05MB/s    0:01:13
+   101253120  25%    4.06MB/s    0:01:12
+   104759296  26%    3.84MB/s    0:01:15
+   109084672  27%    3.84MB/s    0:01:14
+   112820224  28%    3.70MB/s    0:01:16
+   117473280  29%    3.79MB/s    0:01:13
+   120094720  29%    3.53MB/s    0:01:17
+   125435904  31%    3.79MB/s    0:01:11
+   128483328  32%    3.46MB/s    0:01:17
+   133988352  33%    3.67MB/s    0:01:11
+   137134080  34%    3.68MB/s    0:01:10
+   142639104  35%    3.70MB/s    0:01:08
+   145522688  36%    3.72MB/s    0:01:07
+   150962176  37%    3.69MB/s    0:01:06
+   154435584  38%    3.72MB/s    0:01:04
+   159875072  39%    3.73MB/s    0:01:03
+   163610624  40%    3.76MB/s    0:01:01
+   168755200  42%    3.72MB/s    0:01:01
+   172523520  42%    3.67MB/s    0:01:00
+   177995776  44%    3.66MB/s    0:00:59
+   181960704  45%    3.69MB/s    0:00:58
+   187400192  46%    3.74MB/s    0:00:55
+   191397888  47%    3.79MB/s    0:00:54
+   196739072  49%    3.77MB/s    0:00:53
+   200310784  49%    3.72MB/s    0:00:52
+   205553664  51%    3.69MB/s    0:00:51
+   209780736  52%    4.06MB/s    0:00:46
+   213778432  53%    3.76MB/s    0:00:48
+   217088000  54%    3.72MB/s    0:00:48
+   222560256  55%    3.76MB/s    0:00:46
+   225214464  56%    3.09MB/s    0:00:55
+   227573760  56%    2.76MB/s    0:01:01
+   232816640  57%    3.35MB/s    0:00:49
+   236486656  58%    2.94MB/s    0:00:54
+   241336320  60%    3.77MB/s    0:00:41
+   243826688  60%    3.50MB/s    0:00:44
+   249069568  62%    3.47MB/s    0:00:42
+   253001728  63%    3.18MB/s    0:00:45
+   258146304  64%    3.23MB/s    0:00:43
+   262438912  65%    3.84MB/s    0:00:35
+   263487488  65%    3.00MB/s    0:00:44
+   267943936  66%    3.41MB/s    0:00:38
+   271876096  67%    2.87MB/s    0:00:44
+   277118976  69%    3.07MB/s    0:00:39
+   281542656  70%    3.77MB/s    0:00:31
+   285507584  71%    3.74MB/s    0:00:30
+   290226176  72%    4.25MB/s    0:00:25
+   293371904  73%    3.74MB/s    0:00:28
+   298614784  74%    3.64MB/s    0:00:27
+   304119808  75%    4.00MB/s    0:00:23
+   307527680  76%    3.39MB/s    0:00:27
+   312508416  77%    3.67MB/s    0:00:23
+   317882368  79%    3.97MB/s    0:00:20
+   320372736  79%    3.32MB/s    0:00:23
+   325550080  81%    4.07MB/s    0:00:18
+   329842688  82%    4.06MB/s    0:00:17
+   333217792  83%    3.54MB/s    0:00:18
+   338460672  84%    4.23MB/s    0:00:14
+   342949888  85%    4.06MB/s    0:00:14
+   346062848  86%    3.50MB/s    0:00:15
+   350519296  87%    3.72MB/s    0:00:13
+   355926016  88%    3.75MB/s    0:00:11
+   360185856  89%    3.70MB/s    0:00:10
+   364380160  90%    4.24MB/s    0:00:08
+   368607232  91%    4.26MB/s    0:00:07
+   372015104  92%    3.72MB/s    0:00:07
+   377520128  94%    3.97MB/s    0:00:05
+   381976576  95%    4.03MB/s    0:00:04
+   386236416  96%    4.03MB/s    0:00:03
+   389578752  97%    4.10MB/s    0:00:02
+   394330112  98%    3.97MB/s    0:00:01
+   398589952  99%    3.94MB/s    0:00:00
+   401429383 100%    3.77MB/s    0:01:41 (xfer#1, to-check=0/1)
+
+sent 401478543 bytes  received 42 bytes  3879020.14 bytes/sec
+total size is 401429383  speedup is 1.00
+[2014-05-25 19:49:23 CEST] Transferrer: Uploaded 03_assump..heses.mp4
+[2014-05-25 19:49:23 CEST] Pusher: Syncing with diskstation 
+
+WORM-s341574274-m1396396677--Lean UX Workshop%04_personas.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5013504   1%    3.92MB/s    0:01:23
+    10452992   3%    4.49MB/s    0:01:12
+remote: merge git-annex     14778368   4%    4.38MB/s    0:01:12
+    18382848   5%    4.15MB/s    0:01:16
+[2014-05-25 19:49:29 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   02a8a6a..399d085  git-annex -> synced/git-annex
+    22577152   6%    4.16MB/s    0:01:14
+    26509312   7%    3.60MB/s    0:01:25
+    31293440   9%    3.70MB/s    0:01:21
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   c1859f2..5a46cc4  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 399d0856bfb9fef74a18eb9d1d57c0151267323d but expected 02a8a6a6016fd1f36acc39b27cd9e2f1b24fd394
+ ! 02a8a6a..399d085  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    35684352  10%    3.88MB/s    0:01:17
+    40108032  11%    3.92MB/s    0:01:15
+    43352064  12%    3.95MB/s    0:01:13
+    46956544  13%    3.67MB/s    0:01:18
+    51675136  15%    3.55MB/s    0:01:19
+    57180160  16%    3.80MB/s    0:01:13
+    61472768  17%    4.03MB/s    0:01:07
+    65044480  19%    4.00MB/s    0:01:07
+    70057984  20%    4.29MB/s    0:01:01
+    74383360  21%    4.03MB/s    0:01:04
+    78675968  23%    4.03MB/s    0:01:03
+    82739200  24%    4.18MB/s    0:01:00
+    86999040  25%    4.01MB/s    0:01:02
+    90734592  26%    3.76MB/s    0:01:05
+    95977472  28%    3.96MB/s    0:01:00
+   100433920  29%    4.04MB/s    0:00:58
+   104792064  30%    4.04MB/s    0:00:57
+   108986368  31%    4.24MB/s    0:00:53
+   111443968  32%    3.60MB/s    0:01:02
+   116686848  34%    3.74MB/s    0:00:58
+   120487936  35%    3.62MB/s    0:00:59
+   123764736  36%    3.25MB/s    0:01:05
+   128974848  37%    3.88MB/s    0:00:53
+   132415488  38%    3.52MB/s    0:00:58
+   136347648  39%    3.31MB/s    0:01:00
+   141721600  41%    3.92MB/s    0:00:49
+   144998400  42%    3.48MB/s    0:00:55
+   147619840  43%    3.27MB/s    0:00:57
+   152862720  44%    3.81MB/s    0:00:48
+   156008448  45%    3.29MB/s    0:00:55
+   160464896  46%    3.25MB/s    0:00:54
+   165904384  48%    3.88MB/s    0:00:44
+   169246720  49%    3.48MB/s    0:00:48
+   172523520  50%    3.36MB/s    0:00:49
+   178028544  52%    3.92MB/s    0:00:40
+   181600256  53%    3.51MB/s    0:00:44
+   184582144  54%    3.28MB/s    0:00:46
+   188514304  55%    3.60MB/s    0:00:41
+   192970752  56%    3.36MB/s    0:00:43
+   196902912  57%    3.19MB/s    0:00:44
+   202113024  59%    3.81MB/s    0:00:35
+   205684736  60%    3.72MB/s    0:00:35
+   208175104  60%    3.27MB/s    0:00:39
+   213581824  62%    3.87MB/s    0:00:32
+   216825856  63%    3.41MB/s    0:00:35
+   219709440  64%    3.22MB/s    0:00:36
+   225083392  65%    3.91MB/s    0:00:29
+   228622336  66%    3.48MB/s    0:00:31
+   232292352  68%    3.31MB/s    0:00:32
+   237666304  69%    3.89MB/s    0:00:26
+   241139712  70%    3.48MB/s    0:00:28
+   245137408  71%    3.29MB/s    0:00:28
+   250380288  73%    3.49MB/s    0:00:25
+   255361024  74%    3.42MB/s    0:00:24
+   258899968  75%    3.43MB/s    0:00:23
+   262176768  76%    3.38MB/s    0:00:22
+   267452416  78%    3.79MB/s    0:00:19
+   270434304  79%    3.36MB/s    0:00:20
+   274235392  80%    3.24MB/s    0:00:20
+   279478272  81%    3.89MB/s    0:00:15
+   282886144  82%    3.45MB/s    0:00:16
+   286818304  83%    3.38MB/s    0:00:15
+   292061184  85%    3.50MB/s    0:00:13
+   297304064  87%    3.50MB/s    0:00:12
+   300711936  88%    3.49MB/s    0:00:11
+   304152576  89%    3.66MB/s    0:00:09
+   308543488  90%    3.86MB/s    0:00:08
+   312770560  91%    3.60MB/s    0:00:07
+   316178432  92%    3.63MB/s    0:00:06
+   319586304  93%    3.44MB/s    0:00:06
+   325025792  95%    3.66MB/s    0:00:04
+   328466432  96%    3.50MB/s    0:00:03
+   331120640  96%    3.24MB/s    0:00:03
+   336592896  98%    3.87MB/s    0:00:01
+   340000768  99%    3.42MB/s    0:00:00
+   341574274 100%    3.66MB/s    0:01:29 (xfer#1, to-check=0/1)
+
+sent 341616112 bytes  received 42 bytes  3733509.88 bytes/sec
+total size is 341574274  speedup is 1.00
+[2014-05-25 19:50:54 CEST] Transferrer: Uploaded 04_personas.mp4
+[2014-05-25 19:50:54 CEST] Pusher: Syncing with diskstation 
+
+WORM-s112588009-m1396396463--Lean UX Workshop%05_outcomes-and-features.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5537792   4%    5.11MB/s    0:00:20
+     8683520   7%    3.73MB/s    0:00:27
+    14057472  12%    4.16MB/s    0:00:23
+remote: merge git-annex     17334272  15%    3.90MB/s    0:00:23
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+[2014-05-25 19:51:00 CEST] RemoteControl: Syncing with diskstation 
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+    21266432  18%    3.26MB/s    0:00:27
+   399d085..8395b06  git-annex -> synced/git-annex
+    26509312  23%    3.85MB/s    0:00:21
+    29655040  26%    3.34MB/s    0:00:24
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   5a46cc4..c29a46c  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 8395b065d53211a1d1da518dafd09a81ba42f11c but expected 399d0856bfb9fef74a18eb9d1d57c0151267323d
+ ! 399d085..8395b06  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    33062912  29%    3.16MB/s    0:00:24
+    38502400  34%    3.76MB/s    0:00:19
+    41910272  37%    3.36MB/s    0:00:20
+    45121536  40%    3.21MB/s    0:00:20
+    50561024  44%    3.88MB/s    0:00:15
+    53772288  47%    3.36MB/s    0:00:17
+    57442304  51%    3.22MB/s    0:00:16
+    62881792  55%    3.88MB/s    0:00:12
+    66093056  58%    3.39MB/s    0:00:13
+    70451200  62%    3.69MB/s    0:00:11
+    72908800  64%    3.15MB/s    0:00:12
+    77627392  68%    2.87MB/s    0:00:11
+    83132416  73%    3.33MB/s    0:00:08
+    84541440  75%    2.75MB/s    0:00:09
+    89423872  79%    3.71MB/s    0:00:06
+    90570752  80%    3.08MB/s    0:00:06
+    95911936  85%    3.02MB/s    0:00:05
+    97550336  86%    3.06MB/s    0:00:04
+   102531072  91%    2.60MB/s    0:00:03
+   107872256  95%    3.43MB/s    0:00:01
+   109871104  97%    2.78MB/s    0:00:00
+   112588009 100%    3.35MB/s    0:00:31 (xfer#1, to-check=0/1)
+
+sent 112601904 bytes  received 42 bytes  3361252.12 bytes/sec
+total size is 112588009  speedup is 1.00
+[2014-05-25 19:51:27 CEST] Transferrer: Uploaded 05_outcom..tures.mp4
+[2014-05-25 19:51:27 CEST] Pusher: Syncing with diskstation 
+
+WORM-s78565449-m1396396837--Lean UX Workshop%06_writing-hypotheses.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5275648   6%    4.94MB/s    0:00:14
+     6848512   8%    3.18MB/s    0:00:22
+remote: merge git-annex     11796480  15%    3.64MB/s    0:00:17
+    13402112  17%    3.12MB/s    0:00:20
+[2014-05-25 19:51:32 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   8395b06..bbec44b  git-annex -> synced/git-annex
+    17858560  22%    2.94MB/s    0:00:20
+    19693568  25%    3.01MB/s    0:00:19
+    24412160  31%    2.96MB/s    0:00:17
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   c29a46c..d52fe33  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at bbec44b1f18107dc3aaab411ddf2ada1aa273741 but expected 8395b065d53211a1d1da518dafd09a81ba42f11c
+ ! 8395b06..bbec44b  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    27033600  34%    3.00MB/s    0:00:16
+    31490048  40%    2.69MB/s    0:00:17
+    36470784  46%    2.96MB/s    0:00:13
+    41910272  53%    3.09MB/s    0:00:11
+    43286528  55%    2.97MB/s    0:00:11
+    48529408  61%    3.00MB/s    0:00:09
+    53510144  68%    3.06MB/s    0:00:07
+    58753024  74%    2.78MB/s    0:00:06
+    64159744  81%    3.51MB/s    0:00:04
+    67141632  85%    3.23MB/s    0:00:03
+    72548352  92%    3.61MB/s    0:00:01
+    76840960  97%    3.79MB/s    0:00:00
+    78565449 100%    3.17MB/s    0:00:23 (xfer#1, to-check=0/1)
+
+sent 78575188 bytes  received 42 bytes  3081381.57 bytes/sec
+total size is 78565449  speedup is 1.00
+[2014-05-25 19:51:52 CEST] Transferrer: Uploaded 06_writin..heses.mp4
+[2014-05-25 19:51:52 CEST] Pusher: Syncing with diskstation 
+
+WORM-s237023281-m1396397192--Lean UX Workshop%07_design-studio.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3964928   1%    3.16MB/s    0:01:12
+remote: merge git-annex      9207808   3%    3.35MB/s    0:01:06
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+[2014-05-25 19:51:57 CEST] RemoteControl: Syncing with diskstation 
+    14712832   6%    3.19MB/s    0:01:08
+   bbec44b..423bfb2  git-annex -> synced/git-annex
+    19169280   8%    2.99MB/s    0:01:11
+    23887872  10%    3.20MB/s    0:01:05
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   d52fe33..b408181  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 423bfb2586ebc18e8149998862ee1d0060d962ec but expected bbec44b1f18107dc3aaab411ddf2ada1aa273741
+ ! bbec44b..423bfb2  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    26771456  11%    2.98MB/s    0:01:08
+    30965760  13%    2.91MB/s    0:01:09
+    35946496  15%    3.04MB/s    0:01:04
+    40927232  17%    2.76MB/s    0:01:09
+    45187072  19%    3.01MB/s    0:01:02
+    48005120  20%    3.04MB/s    0:01:00
+    50364416  21%    2.73MB/s    0:01:06
+    55607296  23%    2.77MB/s    0:01:03
+    60948480  25%    3.01MB/s    0:00:57
+    62423040  26%    2.75MB/s    0:01:01
+    66355200  27%    2.96MB/s    0:00:56
+    71335936  30%    2.89MB/s    0:00:55
+    76742656  32%    2.90MB/s    0:00:53
+    79200256  33%    3.06MB/s    0:00:50
+    82870272  34%    3.28MB/s    0:00:45
+    86802432  36%    3.60MB/s    0:00:40
+    91521024  38%    3.44MB/s    0:00:41
+    95191040  40%    3.74MB/s    0:00:37
+    97026048  40%    3.23MB/s    0:00:42
+   100171776  42%    2.87MB/s    0:00:46
+   104628224  44%    2.80MB/s    0:00:46
+   109903872  46%    3.14MB/s    0:00:39
+   113541120  47%    3.66MB/s    0:00:32
+   116686848  49%    3.89MB/s    0:00:30
+   121667584  51%    3.68MB/s    0:00:30
+   126386176  53%    3.51MB/s    0:00:30
+   131530752  55%    3.83MB/s    0:00:26
+   135823360  57%    4.07MB/s    0:00:24
+   140214272  59%    4.31MB/s    0:00:21
+   144474112  60%    4.26MB/s    0:00:21
+   148144128  62%    3.82MB/s    0:00:22
+   153124864  64%    3.97MB/s    0:00:20
+   154959872  65%    3.40MB/s    0:00:23
+   160071680  67%    3.59MB/s    0:00:20
+   161513472  68%    3.14MB/s    0:00:23
+   166494208  70%    3.15MB/s    0:00:21
+   169639936  71%    3.11MB/s    0:00:21
+   175046656  73%    3.17MB/s    0:00:19
+   178028544  75%    3.30MB/s    0:00:17
+   183271424  77%    3.33MB/s    0:00:15
+   186941440  78%    3.34MB/s    0:00:14
+   191922176  80%    3.25MB/s    0:00:13
+   195330048  82%    3.22MB/s    0:00:12
+   200835072  84%    3.27MB/s    0:00:10
+   202211328  85%    3.22MB/s    0:00:10
+   207585280  87%    3.31MB/s    0:00:08
+   210534400  88%    3.58MB/s    0:00:07
+   215154688  90%    3.40MB/s    0:00:06
+   215777280  91%    3.21MB/s    0:00:06
+   221020160  93%    3.03MB/s    0:00:05
+   225738752  95%    2.96MB/s    0:00:03
+   230227968  97%    2.94MB/s    0:00:02
+   235175936  99%    3.25MB/s    0:00:00
+   237023281 100%    3.26MB/s    0:01:09 (xfer#1, to-check=0/1)
+
+sent 237052360 bytes  received 42 bytes  3315418.21 bytes/sec
+total size is 237023281  speedup is 1.00
+[2014-05-25 19:53:03 CEST] Transferrer: Uploaded 07_design..tudio.mp4
+[2014-05-25 19:53:04 CEST] Pusher: Syncing with diskstation 
+
+WORM-s113325561-m1396396724--Lean UX Workshop%08_experiments-and-mvp-s.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4227072   3%    3.88MB/s    0:00:27
+remote: merge git-annex      7897088   6%    3.69MB/s    0:00:27
+[2014-05-25 19:53:08 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   423bfb2..e9861a8  git-annex -> synced/git-annex
+    13139968  11%    4.11MB/s    0:00:23
+    16023552  14%    3.39MB/s    0:00:28
+    21266432  18%    3.62MB/s    0:00:24
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   b408181..6b97695  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at e9861a8445e7859f23e90dbc1e6113af547c0515 but expected 423bfb2586ebc18e8149998862ee1d0060d962ec
+ ! 423bfb2..e9861a8  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    23101440  20%    3.22MB/s    0:00:27
+    28082176  24%    3.16MB/s    0:00:26
+    31490048  27%    3.25MB/s    0:00:24
+    35946496  31%    3.09MB/s    0:00:24
+    41189376  36%    3.80MB/s    0:00:18
+    42500096  37%    3.03MB/s    0:00:22
+    47972352  42%    3.88MB/s    0:00:16
+    51675136  45%    3.70MB/s    0:00:16
+    55345152  48%    3.13MB/s    0:00:18
+    60948480  53%    4.11MB/s    0:00:12
+    63209472  55%    3.10MB/s    0:00:15
+    67698688  59%    3.28MB/s    0:00:13
+    72646656  64%    3.26MB/s    0:00:12
+    78315520  69%    3.26MB/s    0:00:10
+    81297408  71%    3.36MB/s    0:00:09
+    86900736  76%    3.55MB/s    0:00:07
+    90472448  79%    3.68MB/s    0:00:06
+    94928896  83%    3.23MB/s    0:00:05
+   100433920  88%    3.87MB/s    0:00:03
+   104628224  92%    3.40MB/s    0:00:02
+   110067712  97%    3.85MB/s    0:00:00
+   113325561 100%    3.52MB/s    0:00:30 (xfer#1, to-check=0/1)
+
+sent 113339548 bytes  received 42 bytes  3487372.00 bytes/sec
+total size is 113325561  speedup is 1.00
+[2014-05-25 19:53:36 CEST] Transferrer: Uploaded 08_experi..mvp-s.mp4
+[2014-05-25 19:53:37 CEST] Pusher: Syncing with diskstation 
+
+WORM-s171315323-m1396397078--Lean UX Workshop%09_research.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      3964928   2%    3.72MB/s    0:00:43
+     9469952   5%    4.48MB/s    0:00:35
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   e9861a8..0967b9e  git-annex -> synced/git-annex
+[2014-05-25 19:53:41 CEST] RemoteControl: Syncing with diskstation 
+    12353536   7%    3.86MB/s    0:00:40
+    16252928   9%    3.83MB/s    0:00:39
+    19693568  11%    3.50MB/s    0:00:42
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   6b97695..b05c1b5  git-annex  -> diskstation/git-annex
+    25198592  14%    3.50MB/s    0:00:40
+    29392896  17%    3.78MB/s    0:00:36
+    31227904  18%    3.31MB/s    0:00:41
+    35979264  21%    3.82MB/s    0:00:34
+    38043648  22%    2.87MB/s    0:00:45
+    43548672  25%    3.18MB/s    0:00:39
+    47218688  27%    3.16MB/s    0:00:38
+    52723712  30%    3.26MB/s    0:00:35
+    55607296  32%    3.33MB/s    0:00:33
+    59801600  34%    3.09MB/s    0:00:35
+    65208320  38%    3.87MB/s    0:00:26
+    66879488  39%    3.10MB/s    0:00:32
+    72122368  42%    3.87MB/s    0:00:25
+    75530240  44%    3.32MB/s    0:00:28
+    80510976  46%    3.20MB/s    0:00:27
+    84180992  49%    3.32MB/s    0:00:25
+    89686016  52%    3.39MB/s    0:00:23
+    93880320  54%    3.59MB/s    0:00:21
+    99483648  58%    3.74MB/s    0:00:18
+   103317504  60%    3.83MB/s    0:00:17
+   108822528  63%    3.85MB/s    0:00:15
+   112754688  65%    3.82MB/s    0:00:14
+   118292480  69%    3.81MB/s    0:00:13
+   121405440  70%    3.93MB/s    0:00:12
+   126124032  73%    3.76MB/s    0:00:11
+   128745472  75%    3.68MB/s    0:00:11
+   133988352  78%    3.59MB/s    0:00:10
+   138182656  80%    3.53MB/s    0:00:09
+   143687680  83%    3.66MB/s    0:00:07
+   146833408  85%    3.70MB/s    0:00:06
+   152338432  88%    3.77MB/s    0:00:04
+   155484160  90%    3.70MB/s    0:00:04
+   160989184  93%    3.65MB/s    0:00:02
+   164397056  95%    3.71MB/s    0:00:01
+   169639936  99%    3.67MB/s    0:00:00
+   171315323 100%    3.60MB/s    0:00:45 (xfer#1, to-check=0/1)
+
+sent 171336377 bytes  received 42 bytes  3607082.51 bytes/sec
+total size is 171315323  speedup is 1.00
+[2014-05-25 19:54:24 CEST] Transferrer: Uploaded 09_research.mp4
+[2014-05-25 19:54:24 CEST] Pusher: Syncing with diskstation 
+
+WORM-s254857031-m1396396965--Lean UX Workshop%10_combining-lean-and-agile.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5275648   2%    4.91MB/s    0:00:49
+    10027008   3%    4.72MB/s    0:00:50
+remote: merge git-annex     13139968   5%    3.93MB/s    0:01:00
+    18710528   7%    4.26MB/s    0:00:54
+[2014-05-25 19:54:30 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+    22052864   8%    3.51MB/s    0:01:04
+   0967b9e..8e9de0b  git-annex -> synced/git-annex
+    27033600  10%    3.53MB/s    0:01:02
+    30441472  11%    3.72MB/s    0:00:58
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   b05c1b5..9285684  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 8e9de0bb0562a8c9e6a72dcff4ad92f93403ad43 but expected 0967b9e587fc2d85662e7b0c1d047ea77bd1e540
+ ! 0967b9e..8e9de0b  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    35815424  14%    3.66MB/s    0:00:58
+    39092224  15%    3.99MB/s    0:00:52
+    43286528  16%    3.83MB/s    0:00:54
+    45645824  17%    3.39MB/s    0:01:00
+    50888704  19%    3.34MB/s    0:00:59
+    54034432  21%    3.04MB/s    0:01:04
+    57966592  22%    3.00MB/s    0:01:04
+    63373312  24%    3.79MB/s    0:00:49
+    64520192  25%    2.95MB/s    0:01:02
+    67403776  26%    3.06MB/s    0:00:59
+    72908800  28%    3.40MB/s    0:00:52
+    76840960  30%    3.06MB/s    0:00:56
+    79986688  31%    3.51MB/s    0:00:48
+    85196800  33%    4.18MB/s    0:00:39
+    87326720  34%    3.20MB/s    0:00:51
+    92831744  36%    3.55MB/s    0:00:44
+    95977472  37%    3.15MB/s    0:00:49
+   100696064  39%    2.97MB/s    0:00:50
+   105676800  41%    3.27MB/s    0:00:44
+   110395392  43%    3.13MB/s    0:00:45
+   115376128  45%    3.84MB/s    0:00:35
+   116686848  45%    3.27MB/s    0:00:41
+   121667584  47%    3.72MB/s    0:00:34
+   125861888  49%    3.56MB/s    0:00:35
+   129007616  50%    2.92MB/s    0:00:42
+   134250496  52%    3.74MB/s    0:00:31
+   137396224  53%    3.01MB/s    0:00:38
+   142835712  56%    3.30MB/s    0:00:33
+   146571264  57%    3.21MB/s    0:00:32
+   150765568  59%    3.02MB/s    0:00:33
+   156270592  61%    3.80MB/s    0:00:25
+   158072832  62%    3.08MB/s    0:00:30
+   163282944  64%    3.87MB/s    0:00:23
+   165445632  64%    2.81MB/s    0:00:31
+   169279488  66%    2.52MB/s    0:00:33
+   173572096  68%    2.96MB/s    0:00:26
+   177242112  69%    2.28MB/s    0:00:33
+   179601408  70%    2.36MB/s    0:00:31
+   183959552  72%    2.44MB/s    0:00:28
+   187203584  73%    2.27MB/s    0:00:29
+   191135744  74%    2.68MB/s    0:00:23
+   196640768  77%    3.84MB/s    0:00:14
+   197427200  77%    2.79MB/s    0:00:20
+   200310784  78%    2.76MB/s    0:00:19
+   205815808  80%    3.13MB/s    0:00:15
+   207650816  81%    2.33MB/s    0:00:19
+   213123072  83%    3.64MB/s    0:00:11
+   217579520  85%    3.99MB/s    0:00:09
+   219185152  86%    3.08MB/s    0:00:11
+   222068736  87%    3.17MB/s    0:00:10
+   227508224  89%    3.15MB/s    0:00:08
+   230457344  90%    2.83MB/s    0:00:08
+   234389504  91%    3.27MB/s    0:00:06
+   238583808  93%    3.81MB/s    0:00:04
+   243204096  95%    3.63MB/s    0:00:03
+   247496704  97%    3.94MB/s    0:00:01
+   249593856  97%    3.61MB/s    0:00:01
+   254312448  99%    3.71MB/s    0:00:00
+   254857031 100%    3.29MB/s    0:01:13 (xfer#1, to-check=0/1)
+
+sent 254888297 bytes  received 42 bytes  3376004.49 bytes/sec
+total size is 254857031  speedup is 1.00
+[2014-05-25 19:55:40 CEST] Transferrer: Uploaded 10_combin..agile.mp4
+[2014-05-25 19:55:40 CEST] Pusher: Syncing with diskstation 
+
+WORM-s67182998-m1396396768--Lean UX Workshop%11_tools-and-techniques.mp4
+       32768   0%    0.00kB/s    0:00:00
+     2392064   3%    2.20MB/s    0:00:28
+remote: merge git-annex      7897088  11%    3.69MB/s    0:00:15
+    12353536  18%    3.75MB/s    0:00:14
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   8e9de0b..10f88fb  git-annex -> synced/git-annex
+[2014-05-25 19:55:45 CEST] RemoteControl: Syncing with diskstation 
+    13664256  20%    3.12MB/s    0:00:16
+    18644992  27%    3.71MB/s    0:00:12
+    20217856  30%    2.79MB/s    0:00:16
+    24510464  36%    2.82MB/s    0:00:14
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   9285684..b2bad3b  git-annex  -> diskstation/git-annex
+    27557888  41%    3.04MB/s    0:00:12
+    32931840  49%    3.15MB/s    0:00:10
+    34373632  51%    3.09MB/s    0:00:10
+    38830080  57%    3.12MB/s    0:00:08
+    44072960  65%    3.80MB/s    0:00:05
+    45907968  68%    2.96MB/s    0:00:07
+    50626560  75%    3.81MB/s    0:00:04
+    53248000  79%    3.15MB/s    0:00:04
+    57442304  85%    2.95MB/s    0:00:03
+    62717952  93%    3.72MB/s    0:00:01
+    64520192  96%    3.07MB/s    0:00:00
+    67182998 100%    3.28MB/s    0:00:19 (xfer#1, to-check=0/1)
+
+sent 67191351 bytes  received 42 bytes  3125181.07 bytes/sec
+total size is 67182998  speedup is 1.00
+[2014-05-25 19:56:01 CEST] Transferrer: Uploaded 11_tools-..iques.mp4
+[2014-05-25 19:56:01 CEST] Pusher: Syncing with diskstation 
+remote: merge git-annex (merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   10f88fb..aa5471b  git-annex -> synced/git-annex
+[2014-05-25 19:56:06 CEST] RemoteControl: Syncing with diskstation 
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   b2bad3b..34ef046  git-annex  -> diskstation/git-annex
+[2014-05-25 20:16:23 CEST] NetWatcherFallback: Syncing with diskstation 
+remote: merge git-annex ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   aa5471b..34ef046  git-annex -> synced/git-annex
+[2014-05-25 21:01:01 CEST] main: Syncing with diskstation 
+remote: merge git-annex (merging synced/git-annex into git-annex...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   34ef046..2f32e55  git-annex -> synced/git-annex
+
+WORM-s14123840-m1398381779--Learning Corel Painter X3%01_a-quick-tour-of-painter.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5799936  41%    5.46MB/s    0:00:01
+     9994240  70%    4.70MB/s    0:00:00
+    14123840 100%    4.71MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 14125729 bytes  received 42 bytes  4035934.57 bytes/sec
+total size is 14123840  speedup is 1.00
+[2014-05-25 21:01:34 CEST] Transferrer: Uploaded 01_a-quic..inter.mp4
+[2014-05-25 21:01:34 CEST] Pusher: Syncing with diskstation 
+
+WORM-s23356431-m1398381923--Learning Corel Painter X3%02_brushes-and-custom-palettes.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5275648  22%    4.47MB/s    0:00:03
+    10715136  45%    4.81MB/s    0:00:02
+    15237120  65%    4.65MB/s    0:00:01
+    19955712  85%    4.60MB/s    0:00:00
+remote: merge git-annex     23356431 100%    4.51MB/s    0:00:04 (xfer#1, to-check=0/1)
+[2014-05-25 21:01:40 CEST] RemoteControl: Syncing with diskstation 
+
+sent 23359448 bytes  received 42 bytes  4247180.00 bytes/sec
+total size is 23356431  speedup is 1.00
+[2014-05-25 21:01:40 CEST] Transferrer: Uploaded 02_brushe..ettes.mp4
+
+WORM-s16835823-m1398381229--Learning Corel Painter X3%03_managing-layers.mp4
+       32768   0%    0.00kB/s    0:00:00
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   2f32e55..f2e1569  git-annex -> synced/git-annex
+     6094848  36%    5.76MB/s    0:00:01
+    11010048  65%    5.22MB/s    0:00:01
+    15761408  93%    4.99MB/s    0:00:00
+    16835823 100%    4.96MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 16838032 bytes  received 42 bytes  3741794.22 bytes/sec
+total size is 16835823  speedup is 1.00
+[2014-05-25 21:01:45 CEST] Transferrer: Uploaded 03_managi..ayers.mp4
+
+WORM-s26947174-m1398380993--Learning Corel Painter X3%04_project-red-chairs.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:01:46 CEST] Pusher: Syncing with diskstation 
+     5799936  21%    5.47MB/s    0:00:03
+     8421376  31%    3.79MB/s    0:00:04
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   34ef046..28ecf68  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at f2e15690121bf48eba8288426bf72c0661ea444a but expected 2f32e55b5e8bd953707452ada9ad57fbeb20b7b1
+ ! 2f32e55..f2e1569  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 21:01:48 CEST] RemoteControl: Syncing with diskstation 
+    13139968  48%    3.94MB/s    0:00:03
+    17956864  66%    4.10MB/s    0:00:02
+    22577152  83%    3.83MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   28ecf68..644a4ea  git-annex  -> diskstation/git-annex
+    25460736  94%    3.94MB/s    0:00:00
+    26947174 100%    3.97MB/s    0:00:06 (xfer#1, to-check=0/1)
+
+sent 26950622 bytes  received 42 bytes  3593421.87 bytes/sec
+total size is 26947174  speedup is 1.00
+remote: merge git-annex [2014-05-25 21:01:52 CEST] Transferrer: Uploaded 04_projec..hairs.mp4
+
+WORM-s14550387-m1398382074--Learning Corel Painter X3%05_the-toolbox-part-1.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:01:53 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   f2e1569..7bf9116  git-annex -> synced/git-annex
+     5668864  38%    5.09MB/s    0:00:01
+    10289152  70%    4.74MB/s    0:00:00
+    14550387 100%    4.56MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 14552323 bytes  received 42 bytes  3233858.89 bytes/sec
+total size is 14550387  speedup is 1.00
+[2014-05-25 21:01:57 CEST] Transferrer: Uploaded 05_the-to..art-1.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   644a4ea..f3817af  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 7bf9116bbeb90b398ac29d7b38e78dbe493f081f but expected f2e15690121bf48eba8288426bf72c0661ea444a
+ ! f2e1569..7bf9116  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+WORM-s5537051-m1398381582--Learning Corel Painter X3%06_the-toolbox-part-2.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4227072  76%    4.00MB/s    0:00:00
+[2014-05-25 21:01:58 CEST] Pusher: Syncing with diskstation 
+     5537051 100%    4.47MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 5537882 bytes  received 42 bytes  3691949.33 bytes/sec
+total size is 5537051  speedup is 1.00
+[2014-05-25 21:02:00 CEST] Transferrer: Uploaded 06_the-to..art-2.mp4
+
+WORM-s16270822-m1398381489--Learning Corel Painter X3%07_color-panels.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4882432  30%    4.62MB/s    0:00:02
+remote: merge git-annex      7634944  46%    3.29MB/s    0:00:02
+[2014-05-25 21:02:03 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   7bf9116..a826827  git-annex -> synced/git-annex
+     9994240  61%    2.94MB/s    0:00:02
+    13369344  82%    3.01MB/s    0:00:00
+    15761408  96%    2.44MB/s    0:00:00
+    16270822 100%    2.91MB/s    0:00:05 (xfer#1, to-check=0/1)
+
+sent 16272960 bytes  received 42 bytes  2503538.77 bytes/sec
+total size is 16270822  speedup is 1.00
+[2014-05-25 21:02:06 CEST] Transferrer: Uploaded 07_color-panels.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   f3817af..bff569c  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at a8268279606cf4fdee4e0fabeef0c9075d840f71 but expected 7bf9116bbeb90b398ac29d7b38e78dbe493f081f
+ ! 7bf9116..a826827  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+WORM-s21555439-m1398381255--Learning Corel Painter X3%08_paper-and-media-libraries.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5111808  23%    4.81MB/s    0:00:03
+[2014-05-25 21:02:08 CEST] Pusher: Syncing with diskstation 
+     9175040  42%    4.29MB/s    0:00:02
+    13369344  62%    4.18MB/s    0:00:01
+    17563648  81%    4.10MB/s    0:00:00
+    21555439 100%    4.05MB/s    0:00:05 (xfer#1, to-check=0/1)
+
+sent 21558234 bytes  received 42 bytes  3316657.85 bytes/sec
+total size is 21555439  speedup is 1.00
+[2014-05-25 21:02:12 CEST] Transferrer: Uploaded 08_paper-..aries.mp4
+remote: merge git-annex 
+WORM-s24881920-m1398382026--Learning Corel Painter X3%09_menu-commands-part-1.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5210112  20%    4.80MB/s    0:00:03
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+[2014-05-25 21:02:14 CEST] RemoteControl: Syncing with diskstation 
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   a826827..e65041f  git-annex -> synced/git-annex
+     9142272  36%    4.28MB/s    0:00:03
+    13041664  52%    4.08MB/s    0:00:02
+    17235968  69%    4.03MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   bff569c..b552f10  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at e65041fc45b14af68426581456deb8d3e9efa1d9 but expected a8268279606cf4fdee4e0fabeef0c9075d840f71
+ ! a826827..e65041f  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    21397504  85%    3.81MB/s    0:00:00
+    24881920 100%    4.05MB/s    0:00:05 (xfer#1, to-check=0/1)
+[2014-05-25 21:02:19 CEST] Pusher: Syncing with diskstation 
+
+sent 24885118 bytes  received 42 bytes  3318021.33 bytes/sec
+total size is 24881920  speedup is 1.00
+[2014-05-25 21:02:20 CEST] Transferrer: Uploaded 09_menu-c..art-1.mp4
+
+WORM-s29078392-m1398382059--Learning Corel Painter X3%10_menu-commands-part-2.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      5210112  17%    4.81MB/s    0:00:04
+     9437184  32%    4.41MB/s    0:00:04
+[2014-05-25 21:02:24 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   e65041f..530d23c  git-annex -> synced/git-annex
+    13762560  47%    4.30MB/s    0:00:03
+    17924096  61%    4.20MB/s    0:00:02
+    22970368  78%    4.16MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   b552f10..4dc60d5  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 530d23cf75a7f936041cdb408fd4f3516fe1514b but expected e65041fc45b14af68426581456deb8d3e9efa1d9
+ ! e65041f..530d23c  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    27688960  95%    4.26MB/s    0:00:00
+    29078392 100%    4.33MB/s    0:00:06 (xfer#1, to-check=0/1)
+
+sent 29082102 bytes  received 42 bytes  3421428.71 bytes/sec
+total size is 29078392  speedup is 1.00
+[2014-05-25 21:02:29 CEST] Transferrer: Uploaded 10_menu-c..art-2.mp4
+
+WORM-s18704564-m1398381759--Learning Corel Painter X3%11_cloner-brushes.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:02:29 CEST] Pusher: Syncing with diskstation 
+     5996544  32%    5.68MB/s    0:00:02
+    10321920  55%    4.86MB/s    0:00:01
+    14581760  77%    4.55MB/s    0:00:00
+    18704564 100%    4.39MB/s    0:00:00
+    18704564 100%    4.39MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 18707000 bytes  received 42 bytes  4157120.44 bytes/sec
+total size is 18704564  speedup is 1.00
+[2014-05-25 21:02:33 CEST] Transferrer: Uploaded 11_cloner..ushes.mp4
+
+WORM-s16483665-m1398381099--Learning Corel Painter X3%12_project-clone-painting-a-pear.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      3964928  24%    3.69MB/s    0:00:03
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+[2014-05-25 21:02:36 CEST] RemoteControl: Syncing with diskstation 
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   530d23c..821b643  git-annex -> synced/git-annex
+     8683520  52%    3.90MB/s    0:00:01
+    12877824  78%    3.90MB/s    0:00:00
+    16483665 100%    4.01MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 16485848 bytes  received 42 bytes  2997434.55 bytes/sec
+total size is 16483665  speedup is 1.00
+[2014-05-25 21:02:38 CEST] Transferrer: Uploaded 12_projec..-pear.mp4
+
+WORM-s13729745-m1398381011--Learning Corel Painter X3%13_dab-stroke-and-method.mp4
+       32768   0%    0.00kB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   4dc60d5..b35b714  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 821b643cf14025648cceac17c2de27e1a17840e3 but expected 530d23cf75a7f936041cdb408fd4f3516fe1514b
+ ! 530d23c..821b643  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     5013504  36%    4.35MB/s    0:00:01
+[2014-05-25 21:02:41 CEST] Pusher: Syncing with diskstation 
+     9469952  68%    4.23MB/s    0:00:00
+    13402112  97%    4.06MB/s    0:00:00
+    13729745 100%    3.98MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 13731580 bytes  received 42 bytes  3923320.57 bytes/sec
+total size is 13729745  speedup is 1.00
+[2014-05-25 21:02:43 CEST] Transferrer: Uploaded 13_dab-st..ethod.mp4
+
+WORM-s15796088-m1398381069--Learning Corel Painter X3%14_advanced-controls.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5013504  31%    4.63MB/s    0:00:02
+     9207808  58%    4.25MB/s    0:00:01
+    13664256  86%    4.21MB/s    0:00:00
+    15796088 100%    4.21MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 15798175 bytes  received 42 bytes  3510714.89 bytes/sec
+total size is 15796088  speedup is 1.00
+[2014-05-25 21:02:47 CEST] Transferrer: Uploaded 14_advanc..trols.mp4
+
+WORM-s14529732-m1398382119--Learning Corel Painter X3%15_custom-variants.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5996544  41%    5.49MB/s    0:00:01
+remote: merge git-annex     10551296  72%    4.90MB/s    0:00:00
+    14529732 100%    4.82MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 14531661 bytes  received 42 bytes  2235646.62 bytes/sec
+total size is 14529732  speedup is 1.00
+[2014-05-25 21:02:54 CEST] RemoteControl: Syncing with diskstation 
+[2014-05-25 21:02:54 CEST] Transferrer: Uploaded 15_custom..iants.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   821b643..d1a88a1  git-annex -> synced/git-annex
+
+WORM-s20256713-m1398381124--Learning Corel Painter X3%16_abstract-painting.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5242880  25%    4.82MB/s    0:00:03
+     9437184  46%    4.38MB/s    0:00:02
+    13729792  67%    4.28MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   b35b714..5d9e777  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at d1a88a1d1fb37d139753d3b96cbd570810a61a51 but expected 821b643cf14025648cceac17c2de27e1a17840e3
+ ! 821b643..d1a88a1  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    17924096  88%    4.19MB/s    0:00:00
+    20256713 100%    4.15MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 20259344 bytes  received 42 bytes  3116828.62 bytes/sec
+total size is 20256713  speedup is 1.00
+[2014-05-25 21:03:00 CEST] Transferrer: Uploaded 16_abstra..nting.mp4
+
+WORM-s15821561-m1398381954--Learning Corel Painter X3%17_tonal-controls.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:03:01 CEST] Pusher: Syncing with diskstation 
+     3964928  25%    3.50MB/s    0:00:03
+     6848512  43%    3.13MB/s    0:00:02
+    11829248  74%    3.62MB/s    0:00:01
+    15821561 100%    3.70MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 15823645 bytes  received 42 bytes  2877034.00 bytes/sec
+total size is 15821561  speedup is 1.00
+[2014-05-25 21:03:05 CEST] Transferrer: Uploaded 17_tonal-..trols.mp4
+remote: merge git-annex 
+WORM-s27686314-m1398381815--Learning Corel Painter X3%18_surface-controls.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5210112  18%    4.91MB/s    0:00:04
+[2014-05-25 21:03:08 CEST] RemoteControl: Syncing with diskstation 
+     9142272  33%    4.29MB/s    0:00:04
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   d1a88a1..2f6a023  git-annex -> synced/git-annex
+    12943360  46%    4.06MB/s    0:00:03
+    17104896  61%    4.01MB/s    0:00:02
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   5d9e777..5732a07  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 2f6a0230e37a27a287290d40a66a61284abd958e but expected d1a88a1d1fb37d139753d3b96cbd570810a61a51
+ ! d1a88a1..2f6a023  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    21266432  76%    3.76MB/s    0:00:01
+    25591808  92%    3.85MB/s    0:00:00
+[2014-05-25 21:06:06 CEST] Pusher: Syncing with diskstation 
+    26640384  96%   73.39kB/s    0:00:14
+    27686314 100%  145.74kB/s    0:03:05 (xfer#1, to-check=0/1)
+
+sent 27689848 bytes  received 42 bytes  148471.26 bytes/sec
+total size is 27686314  speedup is 1.00
+[2014-05-25 21:06:11 CEST] Transferrer: Uploaded 18_surfac..trols.mp4
+remote: merge git-annex 
+WORM-s20041059-m1398382199--Learning Corel Painter X3%19_esoterica.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:06:13 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+     5013504  25%    4.74MB/s    0:00:03
+   2f6a023..3de6568  git-annex -> synced/git-annex
+     8421376  42%    3.99MB/s    0:00:02
+    12681216  63%    4.01MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   5732a07..22c09fa  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 3de6568fc3634c50a42c935f315c763106a22e3c but expected 2f6a0230e37a27a287290d40a66a61284abd958e
+ ! 2f6a023..3de6568  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    17596416  87%    4.18MB/s    0:00:00
+    20041059 100%    4.24MB/s    0:00:04 (xfer#1, to-check=0/1)
+[2014-05-25 21:06:17 CEST] Pusher: Syncing with diskstation 
+
+sent 20043654 bytes  received 42 bytes  3083645.54 bytes/sec
+total size is 20041059  speedup is 1.00
+[2014-05-25 21:06:18 CEST] Transferrer: Uploaded 19_esoterica.mp4
+
+WORM-s20049901-m1398382237--Learning Corel Painter X3%20_esoterica-mosaic.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4227072  21%    3.93MB/s    0:00:03
+remote: merge git-annex      7372800  36%    3.43MB/s    0:00:03
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+[2014-05-25 21:06:22 CEST] RemoteControl: Syncing with diskstation 
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   3de6568..91bf58d  git-annex -> synced/git-annex
+    11042816  55%    3.45MB/s    0:00:02
+    14712832  73%    3.45MB/s    0:00:01
+    17858560  89%    3.20MB/s    0:00:00
+    20049901 100%    3.44MB/s    0:00:05 (xfer#1, to-check=0/1)
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   22c09fa..f2cac44  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 91bf58d7240d46f8eee363bd3b56dde6deefc012 but expected 3de6568fc3634c50a42c935f315c763106a22e3c
+ ! 3de6568..91bf58d  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+sent 20052503 bytes  received 42 bytes  2673672.67 bytes/sec
+total size is 20049901  speedup is 1.00
+[2014-05-25 21:06:25 CEST] Transferrer: Uploaded 20_esoter..osaic.mp4
+
+WORM-s18181651-m1398381889--Learning Corel Painter X3%21_selection-tools-and-commands.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:06:26 CEST] Pusher: Syncing with diskstation 
+     4751360  26%    4.38MB/s    0:00:02
+     8421376  46%    3.89MB/s    0:00:02
+    12091392  66%    3.71MB/s    0:00:01
+    15761408  86%    3.64MB/s    0:00:00
+    18181651 100%    3.65MB/s    0:00:04 (xfer#1, to-check=0/1)
+remote: merge git-annex 
+sent 18184037 bytes  received 42 bytes  2797550.62 bytes/sec
+total size is 18181651  speedup is 1.00
+[2014-05-25 21:06:31 CEST] Transferrer: Uploaded 21_select..mands.mp4
+
+WORM-s16431574-m1398381365--Learning Corel Painter X3%22_text-properties.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5013504  30%    4.71MB/s    0:00:02
+[2014-05-25 21:06:32 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   91bf58d..9341c6c  git-annex -> synced/git-annex
+     8355840  50%    3.82MB/s    0:00:02
+    11763712  71%    3.60MB/s    0:00:01
+    15466496  94%    3.57MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   f2cac44..70eb4e9  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 9341c6cf9e5fe11181099779b7248a9debecaa26 but expected 91bf58d7240d46f8eee363bd3b56dde6deefc012
+ ! 91bf58d..9341c6c  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    16431574 100%    3.62MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 16433735 bytes  received 42 bytes  2987959.45 bytes/sec
+total size is 16431574  speedup is 1.00
+[2014-05-25 21:06:36 CEST] Transferrer: Uploaded 22_text-p..rties.mp4
+
+WORM-s17364419-m1398381850--Learning Corel Painter X3%23_text-effects.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:06:37 CEST] Pusher: Syncing with diskstation 
+     5046272  29%    4.76MB/s    0:00:02
+     8421376  48%    3.97MB/s    0:00:02
+    12255232  70%    3.87MB/s    0:00:01
+    16023552  92%    3.79MB/s    0:00:00
+remote: merge git-annex     17364419 100%    3.71MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 17366689 bytes  received 42 bytes  3157587.45 bytes/sec
+total size is 17364419  speedup is 1.00
+[2014-05-25 21:06:42 CEST] RemoteControl: Syncing with diskstation 
+[2014-05-25 21:06:42 CEST] Transferrer: Uploaded 23_text-effects.mp4
+
+WORM-s19708183-m1398382290--Learning Corel Painter X3%24_postcard-graphic-part-1.mp4
+       32768   0%    0.00kB/s    0:00:00
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   9341c6c..08cb8d8  git-annex -> synced/git-annex
+     4489216  22%    3.60MB/s    0:00:04
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   70eb4e9..dce2d61  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 08cb8d8ba4b56c67984027263d5213133dcdaad2 but expected 9341c6cf9e5fe11181099779b7248a9debecaa26
+ ! 9341c6c..08cb8d8  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 21:06:44 CEST] RemoteControl: Syncing with diskstation 
+     9469952  48%    4.08MB/s    0:00:02
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   dce2d61..ac9201d  git-annex  -> diskstation/git-annex
+    13664256  69%    3.97MB/s    0:00:01
+    17301504  87%    3.86MB/s    0:00:00
+[2014-05-25 21:06:47 CEST] Pusher: Syncing with diskstation 
+    19708183 100%    3.96MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 19710752 bytes  received 42 bytes  3032429.85 bytes/sec
+total size is 19708183  speedup is 1.00
+[2014-05-25 21:06:48 CEST] Transferrer: Uploaded 24_postca..art-1.mp4
+
+WORM-s21565207-m1398381554--Learning Corel Painter X3%25_postcard-graphic-part-2.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5439488  25%    5.07MB/s    0:00:03
+remote: merge git-annex      9306112  43%    4.32MB/s    0:00:02
+[2014-05-25 21:06:51 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   08cb8d8..1212159  git-annex -> synced/git-annex
+    13107200  60%    4.05MB/s    0:00:02
+    16449536  76%    3.84MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   ac9201d..a885109  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 12121595714360b6216de28d0beef79305ec276d but expected 08cb8d8ba4b56c67984027263d5213133dcdaad2
+ ! 08cb8d8..1212159  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    20250624  93%    3.46MB/s    0:00:00
+    21565207 100%    3.75MB/s    0:00:05 (xfer#1, to-check=0/1)
+
+sent 21568004 bytes  received 42 bytes  2875739.47 bytes/sec
+total size is 21565207  speedup is 1.00
+[2014-05-25 21:06:55 CEST] Transferrer: Uploaded 25_postca..art-2.mp4
+
+WORM-s20239101-m1398380964--Learning Corel Painter X3%26_dynamic-layers.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:06:56 CEST] Pusher: Syncing with diskstation 
+     5275648  26%    4.78MB/s    0:00:03
+     9404416  46%    4.35MB/s    0:00:02
+    12943360  63%    4.03MB/s    0:00:01
+    16384000  80%    3.85MB/s    0:00:00
+remote: merge git-annex     20152320  99%    3.52MB/s    0:00:00
+    20239101 100%    3.77MB/s    0:00:05 (xfer#1, to-check=0/1)
+[2014-05-25 21:07:01 CEST] RemoteControl: Syncing with diskstation 
+
+sent 20241725 bytes  received 42 bytes  3114118.00 bytes/sec
+total size is 20239101  speedup is 1.00
+[2014-05-25 21:07:02 CEST] Transferrer: Uploaded 26_dynami..ayers.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   1212159..4c20688  git-annex -> synced/git-annex
+
+WORM-s17613999-m1398382264--Learning Corel Painter X3%27_auto-painting.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5275648  29%    4.78MB/s    0:00:02
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   a885109..ac9fbda  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 4c206880fc1f99dd380b0fb28ebb780b72171633 but expected 12121595714360b6216de28d0beef79305ec276d
+ ! 1212159..4c20688  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     9175040  52%    4.26MB/s    0:00:01
+    12845056  72%    4.00MB/s    0:00:01
+    16384000  93%    3.82MB/s    0:00:00
+[2014-05-25 21:07:07 CEST] Pusher: Syncing with diskstation 
+    17613999 100%    3.79MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 17616302 bytes  received 42 bytes  3202971.64 bytes/sec
+total size is 17613999  speedup is 1.00
+[2014-05-25 21:07:08 CEST] Transferrer: Uploaded 27_auto-p..nting.mp4
+
+WORM-s15562581-m1398381274--Learning Corel Painter X3%28_smart-stroke-cloning.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      5275648  33%    4.77MB/s    0:00:02
+     9469952  60%    4.34MB/s    0:00:01
+[2014-05-25 21:07:11 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   4c20688..f7be7ec  git-annex -> synced/git-annex
+    13139968  84%    4.06MB/s    0:00:00
+    15562581 100%    3.89MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 15564639 bytes  received 42 bytes  3458818.00 bytes/sec
+total size is 15562581  speedup is 1.00
+[2014-05-25 21:07:13 CEST] Transferrer: Uploaded 28_smart-..oning.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   ac9fbda..4f23f91  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at f7be7ececec0dd7a424dfc71571fc2a6cfc63bea but expected 4c206880fc1f99dd380b0fb28ebb780b72171633
+ ! 4c20688..f7be7ec  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+WORM-s28205928-m1398382150--Learning Corel Painter X3%29_mirror-and-kaleidoscope.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5537792  19%    4.94MB/s    0:00:04
+[2014-05-25 21:07:15 CEST] Pusher: Syncing with diskstation 
+     9994240  35%    4.54MB/s    0:00:03
+    14155776  50%    4.34MB/s    0:00:03
+    17956864  63%    4.16MB/s    0:00:02
+    21725184  77%    3.79MB/s    0:00:01
+remote: merge git-annex     25198592  89%    3.58MB/s    0:00:00
+    28205928 100%    3.85MB/s    0:00:06 (xfer#1, to-check=0/1)
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+[2014-05-25 21:07:21 CEST] RemoteControl: Syncing with diskstation 
+
+sent 28209533 bytes  received 42 bytes  3761276.67 bytes/sec
+total size is 28205928  speedup is 1.00
+   f7be7ec..5c452a1  git-annex -> synced/git-annex
+[2014-05-25 21:07:21 CEST] Transferrer: Uploaded 29_mirror..scope.mp4
+
+WORM-s21976288-m1398382005--Learning Corel Painter X3%30_introduction-to-mixed-media.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5406720  24%    5.07MB/s    0:00:03
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   4f23f91..1ca4624  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 5c452a15506c41b30a4ff7099c02f5dae74db8db but expected f7be7ececec0dd7a424dfc71571fc2a6cfc63bea
+ ! f7be7ec..5c452a1  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 21:22:27 CEST] Pusher: Syncing with diskstation 
+remote: merge git-annex (merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   5c452a1..de02d45  git-annex -> synced/git-annex
+     8486912  38%    9.03kB/s    0:24:53
+[2014-05-25 21:22:35 CEST] RemoteControl: Syncing with diskstation 
+    12353536  56%   13.15kB/s    0:12:11
+    15761408  71%   16.76kB/s    0:06:10
+    18644992  84%   14.11kB/s    0:03:56
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   1ca4624..0fddca6  git-annex  -> diskstation/git-annex
+    21921792  99%    3.02MB/s    0:00:00
+    21976288 100%   23.34kB/s    0:15:18 (xfer#1, to-check=0/1)
+
+sent 21979137 bytes  received 42 bytes  23903.40 bytes/sec
+total size is 21976288  speedup is 1.00
+[2014-05-25 21:22:40 CEST] Transferrer: Uploaded 30_introd..media.mp4
+[2014-05-25 21:22:40 CEST] Pusher: Syncing with diskstation 
+
+WORM-s20759393-m1398382174--Learning Corel Painter X3%31_portrait-of-stephen.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4194304  20%    3.79MB/s    0:00:04
+     6815744  32%    3.15MB/s    0:00:04
+remote: merge git-annex      9306112  44%    2.89MB/s    0:00:03
+    12320768  59%    2.87MB/s    0:00:02
+[2014-05-25 21:22:45 CEST] RemoteControl: Syncing with diskstation 
+/Applications/git-annex.app/Contents/MacOS/git-annex: fork: Resource temporarily unavailable
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   de02d45..251064b  git-annex -> synced/git-annex
+    15073280  72%    2.55MB/s    0:00:02
+    17563648  84%    2.52MB/s    0:00:01
+    20316160  97%    2.56MB/s    0:00:00
+    20759393 100%    2.71MB/s    0:00:07 (xfer#1, to-check=0/1)
+
+sent 20762086 bytes  received 42 bytes  2185487.16 bytes/sec
+total size is 20759393  speedup is 1.00
+[2014-05-25 21:22:49 CEST] Transferrer: Uploaded 31_portra..ephen.mp4
+
+WORM-s25441460-m1398381650--Learning Corel Painter X3%32_cel-animation.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:22:50 CEST] Pusher: Syncing with diskstation 
+Pusher crashed: git: createProcess: resource exhausted (Resource temporarily unavailable)
+[2014-05-25 21:22:50 CEST] Pusher: warning Pusher crashed: git: createProcess: resource exhausted (Resource temporarily unavailable)
+     4096000  16%    3.83MB/s    0:00:05
+     6979584  27%    3.27MB/s    0:00:05
+     9469952  37%    2.97MB/s    0:00:05
+    12091392  47%    2.78MB/s    0:00:04
+    13664256  53%    2.19MB/s    0:00:05
+    16023552  62%    2.04MB/s    0:00:04
+    18644992  73%    2.07MB/s    0:00:03
+    21266432  83%    2.10MB/s    0:00:01
+    23625728  92%    2.25MB/s    0:00:00
+    25441460 100%    2.36MB/s    0:00:10 (xfer#1, to-check=0/1)
+
+sent 25444719 bytes  received 42 bytes  2212587.91 bytes/sec
+total size is 25441460  speedup is 1.00
+[2014-05-25 21:23:00 CEST] Transferrer: Uploaded 32_cel-an..ation.mp4
+
+WORM-s23123916-m1398381154--Learning Corel Painter X3%33_rotoscope-techniques.mp4
+       32768   0%    0.00kB/s    0:00:00
+     2129920   9%    1.98MB/s    0:00:10
+     5275648  22%    2.45MB/s    0:00:07
+     8945664  38%    2.77MB/s    0:00:04
+    12353536  53%    2.89MB/s    0:00:03
+    15269888  66%    3.06MB/s    0:00:02
+    18022400  77%    2.99MB/s    0:00:01
+    20742144  89%    2.78MB/s    0:00:00
+    23123916 100%    2.74MB/s    0:00:08 (xfer#1, to-check=0/1)
+
+sent 23126898 bytes  received 42 bytes  2434414.74 bytes/sec
+total size is 23123916  speedup is 1.00
+[2014-05-25 21:23:10 CEST] Transferrer: Uploaded 33_rotosc..iques.mp4
+
+WORM-s16168686-m1398381345--Learning Corel Painter X3%34_portrait-of-hines-part-1.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4194304  25%    3.85MB/s    0:00:03
+     7340032  45%    3.40MB/s    0:00:02
+    10256384  63%    3.19MB/s    0:00:01
+    13500416  83%    3.16MB/s    0:00:00
+    16168686 100%    3.09MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 16170824 bytes  received 42 bytes  2940157.45 bytes/sec
+total size is 16168686  speedup is 1.00
+[2014-05-25 21:23:16 CEST] Transferrer: Uploaded 34_portra..art-1.mp4
+
+WORM-s16185635-m1398381044--Learning Corel Painter X3%35_portrait-of-hines-part-2.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4390912  27%    4.09MB/s    0:00:02
+     7372800  45%    3.37MB/s    0:00:02
+    10518528  64%    3.23MB/s    0:00:01
+    13139968  81%    3.02MB/s    0:00:00
+    16185635 100%    3.13MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 16187773 bytes  received 42 bytes  2490433.08 bytes/sec
+total size is 16185635  speedup is 1.00
+[2014-05-25 21:23:22 CEST] Transferrer: Uploaded 35_portra..art-2.mp4
+
+WORM-s30681625-m1398381209--Learning Corel Painter X3%36_portrait-of-hines-part-3.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4489216  14%    4.25MB/s    0:00:06
+     7798784  25%    3.65MB/s    0:00:06
+    11206656  36%    3.49MB/s    0:00:05
+    14483456  47%    3.40MB/s    0:00:04
+    17858560  58%    3.14MB/s    0:00:03
+    21299200  69%    3.17MB/s    0:00:02
+    24576000  80%    3.12MB/s    0:00:01
+    27951104  91%    3.15MB/s    0:00:00
+    30681625 100%    3.26MB/s    0:00:08 (xfer#1, to-check=0/1)
+
+sent 30685535 bytes  received 42 bytes  3230060.74 bytes/sec
+total size is 30681625  speedup is 1.00
+[2014-05-25 21:23:32 CEST] Transferrer: Uploaded 36_portra..art-3.mp4
+
+WORM-s22528765-m1398382099--Learning Corel Painter X3%37_digital-watercolor.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4390912  19%    4.08MB/s    0:00:04
+     7536640  33%    3.55MB/s    0:00:04
+    10813440  47%    3.39MB/s    0:00:03
+    14090240  62%    3.30MB/s    0:00:02
+    17334272  76%    3.02MB/s    0:00:01
+    21495808  95%    3.25MB/s    0:00:00
+    22528765 100%    3.39MB/s    0:00:06 (xfer#1, to-check=0/1)
+
+sent 22531673 bytes  received 42 bytes  3004228.67 bytes/sec
+total size is 22528765  speedup is 1.00
+[2014-05-25 21:23:39 CEST] Transferrer: Uploaded 37_digita..color.mp4
+
+WORM-s26374030-m1398381726--Learning Corel Painter X3%38_real-watercolor-part-1.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5210112  19%    4.87MB/s    0:00:04
+     8945664  33%    4.18MB/s    0:00:04
+    13074432  49%    4.08MB/s    0:00:03
+    16547840  62%    3.89MB/s    0:00:02
+    20676608  78%    3.65MB/s    0:00:01
+    24412160  92%    3.63MB/s    0:00:00
+    26374030 100%    3.82MB/s    0:00:06 (xfer#1, to-check=0/1)
+
+sent 26377410 bytes  received 42 bytes  3103229.65 bytes/sec
+total size is 26374030  speedup is 1.00
+[2014-05-25 21:23:47 CEST] Transferrer: Uploaded 38_real-w..art-1.mp4
+
+WORM-s19723496-m1398381429--Learning Corel Painter X3%39_real-watercolor-part-2.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4751360  24%    4.50MB/s    0:00:03
+     8683520  44%    4.11MB/s    0:00:02
+    12517376  63%    3.96MB/s    0:00:01
+    16384000  83%    3.88MB/s    0:00:00
+    19723496 100%    3.86MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 19726064 bytes  received 42 bytes  3586564.73 bytes/sec
+total size is 19723496  speedup is 1.00
+[2014-05-25 21:23:53 CEST] Transferrer: Uploaded 39_real-w..art-2.mp4
+
+WORM-s19493451-m1398381312--Learning Corel Painter X3%40_caricature-part-1.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4980736  25%    4.62MB/s    0:00:03
+     8683520  44%    4.04MB/s    0:00:02
+    12615680  64%    3.91MB/s    0:00:01
+    16547840  84%    3.84MB/s    0:00:00
+    19493451 100%    3.84MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 19495986 bytes  received 42 bytes  2999388.92 bytes/sec
+total size is 19493451  speedup is 1.00
+[2014-05-25 21:23:59 CEST] Transferrer: Uploaded 40_carica..art-1.mp4
+rsync: fork: Resource temporarily unavailable (35)
+rsync error: error in IPC code (code 14) at /SourceCache/rsync/rsync-42/rsync/pipe.c(65) [sender=2.6.9]
+rsync: fork: Resource temporarily unavailable (35)
+rsync error: error in IPC code (code 14) at /SourceCache/rsync/rsync-42/rsync/pipe.c(65) [sender=2.6.9]
+[2014-05-25 21:36:13 CEST] NetWatcherFallback: Syncing with diskstation 
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   0fddca6..08995a9  git-annex  -> diskstation/git-annex
+remote: merge git-annex (merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+[2014-05-25 21:36:38 CEST] RemoteControl: Syncing with diskstation 
+   251064b..9043046  git-annex -> synced/git-annex
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   08995a9..d2359ee  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 90430461e599b7aad5bc8f4891f1e0eac38766b0 but expected 251064bd591813a5e813bd9cefafb8b4e6788f77
+ ! 251064b..9043046  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+
+  rsync failed -- run git annex again to resume file transfer
+
+
+  rsync failed -- run git annex again to resume file transfer
+
+
+  rsync failed -- run git annex again to resume file transfer
+
+WORM-s14012455-m1398381979--Learning Corel Painter X3%41_caricature-part-2.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4227072  30%    3.81MB/s    0:00:02
+     8159232  58%    3.69MB/s    0:00:01
+     9994240  71%    3.04MB/s    0:00:01
+    11829248  84%    2.67MB/s    0:00:00
+    13664256  97%    2.15MB/s    0:00:00
+    14012455 100%    2.50MB/s    0:00:05 (xfer#1, to-check=0/1)
+
+sent 14014322 bytes  received 42 bytes  1868581.87 bytes/sec
+total size is 14012455  speedup is 1.00
+[2014-05-25 21:37:01 CEST] Transferrer: Uploaded 41_carica..art-2.mp4
+
+WORM-s2813795-m1398381163--Learning Corel Painter X3%42_about-the-author.mp4
+       32768   1%    0.00kB/s    0:00:00
+     2813795 100%    6.18MB/s    0:00:00 (xfer#1, to-check=0/1)
+
+sent 2814292 bytes  received 42 bytes  1125733.60 bytes/sec
+total size is 2813795  speedup is 1.00
+[2014-05-25 21:37:03 CEST] Transferrer: Uploaded 42_about-..uthor.mp4
+
+WORM-s15151010-m1398381679--Learning Corel Painter X3%43_painter-resources-and-the-painter-community.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5111808  33%    4.69MB/s    0:00:02
+     9109504  60%    4.20MB/s    0:00:01
+    12779520  84%    3.97MB/s    0:00:00
+    15151010 100%    3.95MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 15153043 bytes  received 42 bytes  3367352.22 bytes/sec
+total size is 15151010  speedup is 1.00
+[2014-05-25 21:37:07 CEST] Transferrer: Uploaded 43_painte..unity.mp4
+Watcher crashed: ResumeWatcher
+[2014-05-25 21:39:08 CEST] Watcher: warning Watcher crashed: ResumeWatcher
+
+
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(scanning...) [2014-05-25 21:39:16 CEST] Watcher: Performing startup scan
+[2014-05-25 21:39:20 CEST] Pusher: Syncing with diskstation 
+remote: merge git-annex (merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   9043046..57f7b8b  git-annex -> synced/git-annex
+[2014-05-25 21:39:28 CEST] RemoteControl: Syncing with diskstation 
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   d2359ee..e459e2f  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 57f7b8bb8d2dd5418eda74deef4a0338b00390d9 but expected 90430461e599b7aad5bc8f4891f1e0eac38766b0
+ ! 9043046..57f7b8b  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(started...) [2014-05-25 21:39:46 CEST] Committer: Committing changes to git
+[2014-05-25 21:39:46 CEST] Pusher: Syncing with diskstation 
+Already up-to-date.
+remote: merge git-annex ok        
+remote: merge synced/master Updating 53c007f..6f2044d        
+remote: Fast-forward        
+remote:  .../01_introduction.mp4                                                  | 1 +        
+remote:  .../02_setting-up.mp4                                                    | 1 +        
+remote:  .../03_selecting-and-creating-elements.mp4                               | 1 +        
+remote:  .../04_exercise-1.mp4                                                    | 1 +        
+remote:  An Introduction to d3.js - From Scattered to Scatterplot/05_svg.mp4      | 1 +        
+remote:  .../06_exercise-2.mp4                                                    | 1 +        
+remote:  .../07_binding-data-and-creating-elements-from-data.mp4                  | 1 +        
+remote:  .../08_exercise-3.mp4                                                    | 1 +        
+remote:  .../09_transitions.mp4                                                   | 1 +        
+remote:  An Introduction to d3.js - From Scattered to Scatterplot/10_scales-2.mp4 | 1 +        
+remote:  An Introduction to d3.js - From Scattered to Scatterplot/10_scales.mp4   | 1 +        
+remote:  An Introduction to d3.js - From Scattered to Scatterplot/11_axes.mp4     | 1 +        
+remote:  .../12_advanced-techniques.mp4                                           | 1 +        
+remote:  .../13_conclusion.mp4                                                    | 1 +        
+remote:  C++ Memory Management/01_introduction.mp4                                | 1 +        
+remote:  C++ Memory Management/02_leaks-and-overruns.mp4                          | 1 +        
+remote:  .../03_stl-vector-methods-range-checking-and-sentinels.mp4               | 1 +        
+remote:  C++ Memory Management/04_memory-leaks-part-1.mp4                         | 1 +        
+remote:  C++ Memory Management/05_memory-leaks-part-2.mp4                         | 1 +        
+remote:  C++ Memory Management/06_pointers-pitfalls-and-best-practices.mp4        | 1 +        
+remote:  C++ Memory Management/07_initialize-everything-trust-but-verify.mp4      | 1 +        
+remote:  C++ Memory Management/08_reading-and-writing-shared-assets.mp4           | 1 +        
+remote:  C++ Memory Management/09_undefined-behaviour-and-other-bad-practices.mp4 | 1 +        
+remote:  C++ Memory Management/10_the-heap-and-stl-wrappers.mp4                   | 1 +        
+remote:  C++ Memory Management/11_about-the-author.mp4                            | 1 +        
+remote:  Lean UX Workshop/01_introduction.mp4                                     | 1 +        
+remote:  Lean UX Workshop/02_nordstrom-case-study.mp4                             | 1 +        
+remote:  Lean UX Workshop/03_assumptions-and-hypotheses.mp4                       | 1 +        
+remote:  Lean UX Workshop/04_personas.mp4                                         | 1 +        
+remote:  Lean UX Workshop/05_outcomes-and-features.mp4                            | 1 +        
+remote:  Lean UX Workshop/06_writing-hypotheses.mp4                               | 1 +        
+remote:  Lean UX Workshop/07_design-studio.mp4                                    | 1 +        
+remote:  Lean UX Workshop/08_experiments-and-mvp-s.mp4                            | 1 +        
+remote:  Lean UX Workshop/09_research.mp4                                         | 1 +        
+remote:  Lean UX Workshop/10_combining-lean-and-agile.mp4                         | 1 +        
+remote:  Lean UX Workshop/11_tools-and-techniques.mp4                             | 1 +        
+remote:  Learning Corel Painter X3/01_a-quick-tour-of-painter.mp4                 | 1 +        
+remote:  Learning Corel Painter X3/02_brushes-and-custom-palettes.mp4             | 1 +        
+remote:  Learning Corel Painter X3/03_managing-layers.mp4                         | 1 +        
+remote:  Learning Corel Painter X3/04_project-red-chairs.mp4                      | 1 +        
+remote:  Learning Corel Painter X3/05_the-toolbox-part-1.mp4                      | 1 +        
+remote:  Learning Corel Painter X3/06_the-toolbox-part-2.mp4                      | 1 +        
+remote:  Learning Corel Painter X3/07_color-panels.mp4                            | 1 +        
+remote:  Learning Corel Painter X3/08_paper-and-media-libraries.mp4               | 1 +        
+remote:  Learning Corel Painter X3/09_menu-commands-part-1.mp4                    | 1 +        
+remote:  Learning Corel Painter X3/10_menu-commands-part-2.mp4                    | 1 +        
+remote:  Learning Corel Painter X3/11_cloner-brushes.mp4                          | 1 +        
+remote:  Learning Corel Painter X3/12_project-clone-painting-a-pear.mp4           | 1 +        
+remote:  Learning Corel Painter X3/13_dab-stroke-and-method.mp4                   | 1 +        
+remote:  Learning Corel Painter X3/14_advanced-controls.mp4                       | 1 +        
+remote:  Learning Corel Painter X3/15_custom-variants.mp4                         | 1 +        
+remote:  Learning Corel Painter X3/16_abstract-painting.mp4                       | 1 +        
+remote:  Learning Corel Painter X3/17_tonal-controls.mp4                          | 1 +        
+remote:  Learning Corel Painter X3/18_surface-controls.mp4                        | 1 +        
+remote:  Learning Corel Painter X3/19_esoterica.mp4                               | 1 +        
+remote:  Learning Corel Painter X3/20_esoterica-mosaic.mp4                        | 1 +        
+remote:  Learning Corel Painter X3/21_selection-tools-and-commands.mp4            | 1 +        
+remote:  Learning Corel Painter X3/22_text-properties.mp4                         | 1 +        
+remote:  Learning Corel Painter X3/23_text-effects.mp4                            | 1 +        
+remote:  Learning Corel Painter X3/24_postcard-graphic-part-1.mp4                 | 1 +        
+remote:  Learning Corel Painter X3/25_postcard-graphic-part-2.mp4                 | 1 +        
+remote:  Learning Corel Painter X3/26_dynamic-layers.mp4                          | 1 +        
+remote:  Learning Corel Painter X3/27_auto-painting.mp4                           | 1 +        
+remote:  Learning Corel Painter X3/28_smart-stroke-cloning.mp4                    | 1 +        
+remote:  Learning Corel Painter X3/29_mirror-and-kaleidoscope.mp4                 | 1 +        
+remote:  Learning Corel Painter X3/30_introduction-to-mixed-media.mp4             | 1 +        
+remote:  Learning Corel Painter X3/31_portrait-of-stephen.mp4                     | 1 +        
+remote:  Learning Corel Painter X3/32_cel-animation.mp4                           | 1 +        
+remote:  Learning Corel Painter X3/33_rotoscope-techniques.mp4                    | 1 +        
+remote:  Learning Corel Painter X3/34_portrait-of-hines-part-1.mp4                | 1 +        
+remote:  Learning Corel Painter X3/35_portrait-of-hines-part-2.mp4                | 1 +        
+remote:  Learning Corel Painter X3/36_portrait-of-hines-part-3.mp4                | 1 +        
+remote:  Learning Corel Painter X3/37_digital-watercolor.mp4                      | 1 +        
+remote:  Learning Corel Painter X3/38_real-watercolor-part-1.mp4                  | 1 +        
+remote:  Learning Corel Painter X3/39_real-watercolor-part-2.mp4                  | 1 +        
+remote:  Learning Corel Painter X3/40_caricature-part-1.mp4                       | 1 +        
+remote:  Learning Corel Painter X3/41_caricature-part-2.mp4                       | 1 +        
+remote:  Learning Corel Painter X3/42_about-the-author.mp4                        | 1 +        
+remote:  .../43_painter-resources-and-the-painter-community.mp4                   | 1 +        
+remote:  79 files changed, 79 insertions(+)        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/01_introduction.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/02_setting-up.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/03_selecting-and-creating-elements.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/04_exercise-1.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/05_svg.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/06_exercise-2.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/07_binding-data-and-creating-elements-from-data.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/08_exercise-3.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/09_transitions.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/10_scales-2.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/10_scales.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/11_axes.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/12_advanced-techniques.mp4        
+remote:  create mode 120000 An Introduction to d3.js - From Scattered to Scatterplot/13_conclusion.mp4        
+remote:  create mode 120000 C++ Memory Management/01_introduction.mp4        
+remote:  create mode 120000 C++ Memory Management/02_leaks-and-overruns.mp4        
+remote:  create mode 120000 C++ Memory Management/03_stl-vector-methods-range-checking-and-sentinels.mp4        
+remote:  create mode 120000 C++ Memory Management/04_memory-leaks-part-1.mp4        
+remote:  create mode 120000 C++ Memory Management/05_memory-leaks-part-2.mp4        
+remote:  create mode 120000 C++ Memory Management/06_pointers-pitfalls-and-best-practices.mp4        
+remote:  create mode 120000 C++ Memory Management/07_initialize-everything-trust-but-verify.mp4        
+remote:  create mode 120000 C++ Memory Management/08_reading-and-writing-shared-assets.mp4        
+remote:  create mode 120000 C++ Memory Management/09_undefined-behaviour-and-other-bad-practices.mp4        
+remote:  create mode 120000 C++ Memory Management/10_the-heap-and-stl-wrappers.mp4        
+remote:  create mode 120000 C++ Memory Management/11_about-the-author.mp4        
+remote:  create mode 120000 Lean UX Workshop/01_introduction.mp4        
+remote:  create mode 120000 Lean UX Workshop/02_nordstrom-case-study.mp4        
+remote:  create mode 120000 Lean UX Workshop/03_assumptions-and-hypotheses.mp4        
+remote:  create mode 120000 Lean UX Workshop/04_personas.mp4        
+remote:  create mode 120000 Lean UX Workshop/05_outcomes-and-features.mp4        
+remote:  create mode 120000 Lean UX Workshop/06_writing-hypotheses.mp4        
+remote:  create mode 120000 Lean UX Workshop/07_design-studio.mp4        
+remote:  create mode 120000 Lean UX Workshop/08_experiments-and-mvp-s.mp4        
+remote:  create mode 120000 Lean UX Workshop/09_research.mp4        
+remote:  create mode 120000 Lean UX Workshop/10_combining-lean-and-agile.mp4        
+remote:  create mode 120000 Lean UX Workshop/11_tools-and-techniques.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/01_a-quick-tour-of-painter.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/02_brushes-and-custom-palettes.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/03_managing-layers.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/04_project-red-chairs.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/05_the-toolbox-part-1.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/06_the-toolbox-part-2.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/07_color-panels.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/08_paper-and-media-libraries.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/09_menu-commands-part-1.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/10_menu-commands-part-2.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/11_cloner-brushes.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/12_project-clone-painting-a-pear.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/13_dab-stroke-and-method.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/14_advanced-controls.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/15_custom-variants.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/16_abstract-painting.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/17_tonal-controls.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/18_surface-controls.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/19_esoterica.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/20_esoterica-mosaic.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/21_selection-tools-and-commands.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/22_text-properties.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/23_text-effects.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/24_postcard-graphic-part-1.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/25_postcard-graphic-part-2.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/26_dynamic-layers.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/27_auto-painting.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/28_smart-stroke-cloning.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/29_mirror-and-kaleidoscope.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/30_introduction-to-mixed-media.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/31_portrait-of-stephen.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/32_cel-animation.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/33_rotoscope-techniques.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/34_portrait-of-hines-part-1.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/35_portrait-of-hines-part-2.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/36_portrait-of-hines-part-3.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/37_digital-watercolor.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/38_real-watercolor-part-1.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/39_real-watercolor-part-2.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/40_caricature-part-1.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/41_caricature-part-2.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/42_about-the-author.mp4        
+remote:  create mode 120000 Learning Corel Painter X3/43_painter-resources-and-the-painter-community.mp4        
+remote: 
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   57f7b8b..e459e2f  git-annex -> synced/git-annex
+   53c007f..6f2044d  master -> synced/master
+Already up-to-date.
+[2014-05-25 21:41:22 CEST] Committer: Adding 01_introduction.mp4 02_settin..plate.mp4 03_settin..lbars.mp4 04_how-to..files.mp4 05_line-tool.mp4 06_rectan..-tool.mp4 07_circle-tool.mp4 08_polygon-tool.mp4 09_arc-tool.mp4 and 34 other files
+
+(Recording state in git...)
+
+
+add Learning SketchUp 2013/01_introduction.mp4 ok
+add Learning SketchUp 2013/02_setting-up-the-template.mp4 ok
+add Learning SketchUp 2013/03_setting-up-the-toolbars.mp4 ok
+add Learning SketchUp 2013/04_how-to-access-your-working-files.mp4 ok
+add Learning SketchUp 2013/05_line-tool.mp4 ok
+add Learning SketchUp 2013/06_rectangle-tool.mp4 ok
+add Learning SketchUp 2013/07_circle-tool.mp4 ok
+add Learning SketchUp 2013/08_polygon-tool.mp4 ok
+add Learning SketchUp 2013/09_arc-tool.mp4 ok
+add Learning SketchUp 2013/100_adding-lighting.mp4 ok
+add Learning SketchUp 2013/101_add-reflections-to-existing-textures.mp4 ok
+add Learning SketchUp 2013/102_model-presets-create-a-preview-rendering.mp4 ok
+add Learning SketchUp 2013/103_rendering-a-high-quality-image.mp4 ok
+add Learning SketchUp 2013/104_post-processing-in-photoshop.mp4 ok
+add Learning SketchUp 2013/105_what-is-layout.mp4 ok
+add Learning SketchUp 2013/106_adjusting-the-model-settings.mp4 ok
+add Learning SketchUp 2013/108_adding-additional-pages-and-content.mp4 ok
+add Learning SketchUp 2013/109_updating-the-model-references.mp4 ok
+add Learning SketchUp 2013/10_freehand-tool.mp4 ok
+add Learning SketchUp 2013/111_about-dan-brown.mp4 ok
+add Learning SketchUp 2013/11_navigating-in-3d.mp4 ok
+add Learning SketchUp 2013/12_push-pull-and-move-tool.mp4 ok
+add Learning SketchUp 2013/13_using-follow-me-complex-roof-pitches.mp4 ok
+add Learning SketchUp 2013/14_creating-a-mansard-roof.mp4 ok
+add Learning SketchUp 2013/15_creating-a-gambrel-roof.mp4 ok
+add Learning SketchUp 2013/16_measurements.mp4 ok
+add Learning SketchUp 2013/18_extruding-your-walls-push-pull-and-offset.mp4 ok
+add Learning SketchUp 2013/19_creating-doors-and-openings.mp4 ok
+add Learning SketchUp 2013/20_clean-up-using-the-eraser-to-remove-unwanted-edges.mp4 ok
+add Learning SketchUp 2013/21_why-groups.mp4 ok
+add Learning SketchUp 2013/22_creating-the-second-floor.mp4 ok
+add Learning SketchUp 2013/23_creating-additional-openings.mp4 ok
+add Learning SketchUp 2013/24_hide-model-and-other-useful-shortcuts.mp4 ok
+add Learning SketchUp 2013/25_using-the-outliner.mp4 ok
+add Learning SketchUp 2013/26_using-layers-to-control-visibility.mp4 ok
+add Learning SketchUp 2013/27_viewing-layer-states-of-the-model.mp4 ok
+add Learning SketchUp 2013/28_field-of-view.mp4 ok
+add Learning SketchUp 2013/29_dividing-faces-to-create-your-rooms.mp4 ok
+add Learning SketchUp 2013/30_area-tool-for-calculations.mp4 ok
+add Learning SketchUp 2013/31_using-paint-bucket-for-floor-texture-2.mp4 ok
+add Learning SketchUp 2013/31_using-paint-bucket-for-floor-texture.mp4 ok
+add Learning SketchUp 2013/32_importing-and-applying-a-texture.mp4 ok
+add Learning SketchUp 2013/33_positioning-an-imported-texture.mp4 [2014-05-25 21:41:29 CEST] Committer: Adding 34_editin..tchup.mp4 35_editin..oshop.mp4 36_hide-e..-tool.mp4 37_creati..iling.mp4 38_assign..roups.mp4 39_adding..ter-7.mp4 40_creati..lding.mp4 41_copy-a..place.mp4 42_why-we..nents.mp4 and 57 other files
+ok
+add Learning SketchUp 2013/34_editing-texture-colour-in-sketchup.mp4 ok
+add Learning SketchUp 2013/35_editing-a-texture-in-photoshop.mp4 ok
+add Learning SketchUp 2013/36_hide-edges-and-lines-with-the-eraser-tool.mp4 ok
+add Learning SketchUp 2013/37_creating-the-ceiling.mp4 ok
+add Learning SketchUp 2013/38_assigning-layers-within-groups.mp4 ok
+add Learning SketchUp 2013/39_adding-detail-chapter-7.mp4 ok
+add Learning SketchUp 2013/40_creating-crown-moulding.mp4 ok
+add Learning SketchUp 2013/41_copy-and-paste-in-place.mp4 ok
+add Learning SketchUp 2013/42_why-we-use-groups-and-components.mp4 ok
+add Learning SketchUp 2013/43_creating-the-staircase.mp4 ok
+add Learning SketchUp 2013/44_adding-riser-detail.mp4 ok
+add Learning SketchUp 2013/45_making-a-unique-bottom-step.mp4 ok
+add Learning SketchUp 2013/46_adding-spindles-with-move-and-copy.mp4 ok
+add Learning SketchUp 2013/47_adding-railing.mp4 ok
+add Learning SketchUp 2013/48_review-of-components-and-nested-groups.mp4 ok
+add Learning SketchUp 2013/49_creating-doors.mp4 ok
+add Learning SketchUp 2013/50_creating-the-front-window-frame.mp4 ok
+add Learning SketchUp 2013/51_double-hung-windows.mp4 ok
+add Learning SketchUp 2013/52_installing-bit-tools-plugins.mp4 ok
+add Learning SketchUp 2013/53_creating-walls-and-door-openings.mp4 ok
+add Learning SketchUp 2013/54_using-the-window-feature.mp4 ok
+add Learning SketchUp 2013/55_starting-at-the-base.mp4 ok
+add Learning SketchUp 2013/56_building-the-mantle.mp4 ok
+add Learning SketchUp 2013/57_mantle-columns.mp4 ok
+add Learning SketchUp 2013/58_mantle-support.mp4 ok
+add Learning SketchUp 2013/59_adding-textures.mp4 ok
+add Learning SketchUp 2013/60_base-cabinets.mp4 ok
+add Learning SketchUp 2013/61_wall-cabinets.mp4 ok
+add Learning SketchUp 2013/62_cabinet-doors.mp4 ok
+add Learning SketchUp 2013/63_creating-the-countertop.mp4 ok
+add Learning SketchUp 2013/64_adding-materials.mp4 ok
+add Learning SketchUp 2013/65_adding-appliances.mp4 ok
+add Learning SketchUp 2013/66_adding-the-fridge-and-sink.mp4 ok
+add Learning SketchUp 2013/67_using-the-3d-warehouse.mp4 ok
+add Learning SketchUp 2013/68_using-form-fonts.mp4 ok
+add Learning SketchUp 2013/69_using-the-podium-browser.mp4 ok
+add Learning SketchUp 2013/70_creating-a-library.mp4 ok
+add Learning SketchUp 2013/71_setting-up-to-match-a-new-photo.mp4 ok
+add Learning SketchUp 2013/72_creating-the-massing-model.mp4 ok
+add Learning SketchUp 2013/73_applying-textures.mp4 ok
+add Learning SketchUp 2013/74_adding-detail-chapter-13.mp4 ok
+add Learning SketchUp 2013/75_saving-and-placing-into-the-model.mp4 ok
+add Learning SketchUp 2013/76_creating-the-exterior.mp4 ok
+add Learning SketchUp 2013/77_setting-the-building-in-place-geolocation.mp4 ok
+add Learning SketchUp 2013/78_reset-axis-to-align-building.mp4 ok
+add Learning SketchUp 2013/79_creating-the-front-facade.mp4 ok
+add Learning SketchUp 2013/80_adding-context.mp4 ok
+add Learning SketchUp 2013/81_get-photo-google-street-view.mp4 ok
+add Learning SketchUp 2013/82_using-3d-text.mp4 ok
+add Learning SketchUp 2013/83_add-solar-panels-with-skelion-plugin.mp4 ok
+add Learning SketchUp 2013/84_creating-scenes-and-updating.mp4 ok
+add Learning SketchUp 2013/85_styles.mp4 ok
+add Learning SketchUp 2013/86_scenes-for-animation.mp4 ok
+add Learning SketchUp 2013/87_section-cut-for-interior-elevations.mp4 ok
+add Learning SketchUp 2013/88_creating-a-group.mp4 ok
+add Learning SketchUp 2013/89_creating-the-animation.mp4 ok
+add Learning SketchUp 2013/90_jpeg-and-png-files.mp4 ok
+add Learning SketchUp 2013/91_dwg-elevation-and-plan-pro-feature.mp4 ok
+add Learning SketchUp 2013/92_kmz-for-google-earth.mp4 ok
+add Learning SketchUp 2013/93_collada-files.mp4 ok
+add Learning SketchUp 2013/94_animation-options.mp4 ok
+add Learning SketchUp 2013/95_add-final-touches.mp4 ok
+add Learning SketchUp 2013/96_export-display-options.mp4 ok
+add Learning SketchUp 2013/97_stacking-images-in-photoshop.mp4 ok
+add Learning SketchUp 2013/98_multiply-and-opacity.mp4 ok
+add Learning SketchUp 2013/99_saving-the-image.mp4 [2014-05-25 21:41:31 CEST] Committer: Committing changes to git
+[2014-05-25 21:41:32 CEST] Pusher: Syncing with diskstation 
+
+WORM-s8756441-m1398385688--Learning SketchUp 2013%34_editing-texture-colour-in-sketchup.mp4
+       32768   0%    0.00kB/s    0:00:00
+     2654208  30%    1.97MB/s    0:00:03
+     5734400  65%    2.32MB/s    0:00:01
+Already up-to-date.
+     8756441 100%    2.66MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 8757681 bytes  received 42 bytes  1592313.27 bytes/sec
+total size is 8756441  speedup is 1.00
+[2014-05-25 21:41:37 CEST] Transferrer: Uploaded 34_editin..tchup.mp4
+
+WORM-s16632826-m1398386674--Learning SketchUp 2013%33_positioning-an-imported-texture.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4423680  26%    4.12MB/s    0:00:02
+     8486912  51%    3.96MB/s    0:00:02
+    12517376  75%    3.90MB/s    0:00:01
+remote: merge git-annex     16580608  99%    3.87MB/s    0:00:00
+    16632826 100%    3.89MB/s    0:00:04 (xfer#1, to-check=0/1)
+[2014-05-25 21:41:42 CEST] RemoteControl: Syncing with diskstation 
+
+sent 16635024 bytes  received 42 bytes  3024557.45 bytes/sec
+total size is 16632826  speedup is 1.00
+[2014-05-25 21:41:43 CEST] Transferrer: Uploaded 33_positi..xture.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: merge synced/master 
+WORM-s13603741-m1398386183--Learning SketchUp 2013%32_importing-and-applying-a-texture.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3244032  23%    3.06MB/s    0:00:03
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   e459e2f..297826c  git-annex  -> diskstation/git-annex
+   e459e2f..26c6449  synced/git-annex -> diskstation/synced/git-annex
+   6f2044d..7500a88  synced/master -> diskstation/synced/master
+Already up-to-date.
+Updating 6f2044d..7500a88        
+remote: Fast-forward        
+     6520832  47%    3.08MB/s    0:00:02
+remote:  Learning SketchUp 2013/01_introduction.mp4                               | 1 +        
+remote:  Learning SketchUp 2013/02_setting-up-the-template.mp4                    | 1 +        
+remote:  Learning SketchUp 2013/03_setting-up-the-toolbars.mp4                    | 1 +        
+remote:  Learning SketchUp 2013/04_how-to-access-your-working-files.mp4           | 1 +        
+remote:  Learning SketchUp 2013/05_line-tool.mp4                                  | 1 +        
+remote:  Learning SketchUp 2013/06_rectangle-tool.mp4                             | 1 +        
+remote:  Learning SketchUp 2013/07_circle-tool.mp4                                | 1 +        
+remote:  Learning SketchUp 2013/08_polygon-tool.mp4                               | 1 +        
+remote:  Learning SketchUp 2013/09_arc-tool.mp4                                   | 1 +        
+remote:  Learning SketchUp 2013/100_adding-lighting.mp4                           | 1 +        
+remote:  Learning SketchUp 2013/101_add-reflections-to-existing-textures.mp4      | 1 +        
+remote:  Learning SketchUp 2013/102_model-presets-create-a-preview-rendering.mp4  | 1 +        
+remote:  Learning SketchUp 2013/103_rendering-a-high-quality-image.mp4            | 1 +        
+remote:  Learning SketchUp 2013/104_post-processing-in-photoshop.mp4              | 1 +        
+remote:  Learning SketchUp 2013/105_what-is-layout.mp4                            | 1 +        
+remote:  Learning SketchUp 2013/106_adjusting-the-model-settings.mp4              | 1 +        
+remote:  Learning SketchUp 2013/108_adding-additional-pages-and-content.mp4       | 1 +        
+remote:  Learning SketchUp 2013/109_updating-the-model-references.mp4             | 1 +        
+remote:  Learning SketchUp 2013/10_freehand-tool.mp4                              | 1 +        
+remote:  Learning SketchUp 2013/111_about-dan-brown.mp4                           | 1 +        
+remote:  Learning SketchUp 2013/11_navigating-in-3d.mp4                           | 1 +        
+remote:  Learning SketchUp 2013/12_push-pull-and-move-tool.mp4                    | 1 +        
+remote:  Learning SketchUp 2013/13_using-follow-me-complex-roof-pitches.mp4       | 1 +        
+remote:  Learning SketchUp 2013/14_creating-a-mansard-roof.mp4                    | 1 +        
+remote:  Learning SketchUp 2013/15_creating-a-gambrel-roof.mp4                    | 1 +        
+remote:  Learning SketchUp 2013/16_measurements.mp4                               | 1 +        
+remote:  Learning SketchUp 2013/18_extruding-your-walls-push-pull-and-offset.mp4  | 1 +        
+remote:  Learning SketchUp 2013/19_creating-doors-and-openings.mp4                | 1 +        
+remote:  .../20_clean-up-using-the-eraser-to-remove-unwanted-edges.mp4            | 1 +        
+remote:  Learning SketchUp 2013/21_why-groups.mp4                                 | 1 +        
+remote:  Learning SketchUp 2013/22_creating-the-second-floor.mp4                  | 1 +        
+remote:  Learning SketchUp 2013/23_creating-additional-openings.mp4               | 1 +        
+remote:  Learning SketchUp 2013/24_hide-model-and-other-useful-shortcuts.mp4      | 1 +        
+remote:  Learning SketchUp 2013/25_using-the-outliner.mp4                         | 1 +        
+remote:  Learning SketchUp 2013/26_using-layers-to-control-visibility.mp4         | 1 +        
+remote:  Learning SketchUp 2013/27_viewing-layer-states-of-the-model.mp4          | 1 +        
+remote:  Learning SketchUp 2013/28_field-of-view.mp4                              | 1 +        
+remote:  Learning SketchUp 2013/29_dividing-faces-to-create-your-rooms.mp4        | 1 +        
+remote:  Learning SketchUp 2013/30_area-tool-for-calculations.mp4                 | 1 +        
+remote:  Learning SketchUp 2013/31_using-paint-bucket-for-floor-texture-2.mp4     | 1 +        
+remote:  Learning SketchUp 2013/31_using-paint-bucket-for-floor-texture.mp4       | 1 +        
+remote:  Learning SketchUp 2013/32_importing-and-applying-a-texture.mp4           | 1 +        
+remote:  Learning SketchUp 2013/33_positioning-an-imported-texture.mp4            | 1 +        
+remote:  Learning SketchUp 2013/34_editing-texture-colour-in-sketchup.mp4         | 1 +        
+remote:  Learning SketchUp 2013/35_editing-a-texture-in-photoshop.mp4             | 1 +        
+remote:  Learning SketchUp 2013/36_hide-edges-and-lines-with-the-eraser-tool.mp4  | 1 +        
+remote:  Learning SketchUp 2013/37_creating-the-ceiling.mp4                       | 1 +        
+remote:  Learning SketchUp 2013/38_assigning-layers-within-groups.mp4             | 1 +        
+remote:  Learning SketchUp 2013/39_adding-detail-chapter-7.mp4                    | 1 +        
+remote:  Learning SketchUp 2013/40_creating-crown-moulding.mp4                    | 1 +        
+remote:  Learning SketchUp 2013/41_copy-and-paste-in-place.mp4                    | 1 +        
+remote:  Learning SketchUp 2013/42_why-we-use-groups-and-components.mp4           | 1 +        
+remote:  Learning SketchUp 2013/43_creating-the-staircase.mp4                     | 1 +        
+remote:  Learning SketchUp 2013/44_adding-riser-detail.mp4                        | 1 +        
+remote:  Learning SketchUp 2013/45_making-a-unique-bottom-step.mp4                | 1 +        
+remote:  Learning SketchUp 2013/46_adding-spindles-with-move-and-copy.mp4         | 1 +        
+remote:  Learning SketchUp 2013/47_adding-railing.mp4                             | 1 +        
+remote:  Learning SketchUp 2013/48_review-of-components-and-nested-groups.mp4     | 1 +        
+remote:  Learning SketchUp 2013/49_creating-doors.mp4                             | 1 +        
+remote:  Learning SketchUp 2013/50_creating-the-front-window-frame.mp4            | 1 +        
+remote:  Learning SketchUp 2013/51_double-hung-windows.mp4                        | 1 +        
+remote:  Learning SketchUp 2013/52_installing-bit-tools-plugins.mp4               | 1 +        
+remote:  Learning SketchUp 2013/53_creating-walls-and-door-openings.mp4           | 1 +        
+remote:  Learning SketchUp 2013/54_using-the-window-feature.mp4                   | 1 +        
+remote:  Learning SketchUp 2013/55_starting-at-the-base.mp4                       | 1 +        
+remote:  Learning SketchUp 2013/56_building-the-mantle.mp4                        | 1 +        
+remote:  Learning SketchUp 2013/57_mantle-columns.mp4                             | 1 +        
+remote:  Learning SketchUp 2013/58_mantle-support.mp4                             | 1 +        
+remote:  Learning SketchUp 2013/59_adding-textures.mp4                            | 1 +        
+remote:  Learning SketchUp 2013/60_base-cabinets.mp4                              | 1 +        
+remote:  Learning SketchUp 2013/61_wall-cabinets.mp4                              | 1 +        
+remote:  Learning SketchUp 2013/62_cabinet-doors.mp4                              | 1 +        
+remote:  Learning SketchUp 2013/63_creating-the-countertop.mp4                    | 1 +        
+remote:  Learning SketchUp 2013/64_adding-materials.mp4                           | 1 +        
+remote:  Learning SketchUp 2013/65_adding-appliances.mp4                          | 1 +        
+remote:  Learning SketchUp 2013/66_adding-the-fridge-and-sink.mp4                 | 1 +        
+remote:  Learning SketchUp 2013/67_using-the-3d-warehouse.mp4                     | 1 +        
+remote:  Learning SketchUp 2013/68_using-form-fonts.mp4                           | 1 +        
+remote:  Learning SketchUp 2013/69_using-the-podium-browser.mp4                   | 1 +        
+remote:  Learning SketchUp 2013/70_creating-a-library.mp4                         | 1 +        
+remote:  Learning SketchUp 2013/71_setting-up-to-match-a-new-photo.mp4            | 1 +        
+remote:  Learning SketchUp 2013/72_creating-the-massing-model.mp4                 | 1 +        
+remote:  Learning SketchUp 2013/73_applying-textures.mp4                          | 1 +        
+remote:  Learning SketchUp 2013/74_adding-detail-chapter-13.mp4                   | 1 +        
+remote:  Learning SketchUp 2013/75_saving-and-placing-into-the-model.mp4          | 1 +        
+remote:  Learning SketchUp 2013/76_creating-the-exterior.mp4                      | 1 +        
+remote:  Learning SketchUp 2013/77_setting-the-building-in-place-geolocation.mp4  | 1 +        
+remote:  Learning SketchUp 2013/78_reset-axis-to-align-building.mp4               | 1 +        
+remote:  Learning SketchUp 2013/79_creating-the-front-facade.mp4                  | 1 +        
+remote:  Learning SketchUp 2013/80_adding-context.mp4                             | 1 +        
+remote:  Learning SketchUp 2013/81_get-photo-google-street-view.mp4               | 1 +        
+remote:  Learning SketchUp 2013/82_using-3d-text.mp4                              | 1 +        
+remote:  Learning SketchUp 2013/83_add-solar-panels-with-skelion-plugin.mp4       | 1 +        
+remote:  Learning SketchUp 2013/84_creating-scenes-and-updating.mp4               | 1 +        
+remote:  Learning SketchUp 2013/85_styles.mp4                                     | 1 +        
+remote:  Learning SketchUp 2013/86_scenes-for-animation.mp4                       | 1 +        
+remote:  Learning SketchUp 2013/87_section-cut-for-interior-elevations.mp4        | 1 +        
+remote:  Learning SketchUp 2013/88_creating-a-group.mp4                           | 1 +        
+remote:  Learning SketchUp 2013/89_creating-the-animation.mp4                     | 1 +        
+remote:  Learning SketchUp 2013/90_jpeg-and-png-files.mp4                         | 1 +        
+remote:  Learning SketchUp 2013/91_dwg-elevation-and-plan-pro-feature.mp4         | 1 +        
+remote:  Learning SketchUp 2013/92_kmz-for-google-earth.mp4                       | 1 +        
+remote:  Learning SketchUp 2013/93_collada-files.mp4                              | 1 +        
+remote:  Learning SketchUp 2013/94_animation-options.mp4                          | 1 +        
+remote:  Learning SketchUp 2013/95_add-final-touches.mp4                          | 1 +        
+remote:  Learning SketchUp 2013/96_export-display-options.mp4                     | 1 +        
+remote:  Learning SketchUp 2013/97_stacking-images-in-photoshop.mp4               | 1 +        
+remote:  Learning SketchUp 2013/98_multiply-and-opacity.mp4                       | 1 +        
+remote:  Learning SketchUp 2013/99_saving-the-image.mp4                           | 1 +        
+remote:  109 files changed, 109 insertions(+)        
+remote:  create mode 120000 Learning SketchUp 2013/01_introduction.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/02_setting-up-the-template.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/03_setting-up-the-toolbars.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/04_how-to-access-your-working-files.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/05_line-tool.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/06_rectangle-tool.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/07_circle-tool.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/08_polygon-tool.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/09_arc-tool.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/100_adding-lighting.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/101_add-reflections-to-existing-textures.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/102_model-presets-create-a-preview-rendering.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/103_rendering-a-high-quality-image.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/104_post-processing-in-photoshop.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/105_what-is-layout.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/106_adjusting-the-model-settings.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/108_adding-additional-pages-and-content.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/109_updating-the-model-references.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/10_freehand-tool.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/111_about-dan-brown.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/11_navigating-in-3d.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/12_push-pull-and-move-tool.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/13_using-follow-me-complex-roof-pitches.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/14_creating-a-mansard-roof.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/15_creating-a-gambrel-roof.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/16_measurements.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/18_extruding-your-walls-push-pull-and-offset.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/19_creating-doors-and-openings.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/20_clean-up-using-the-eraser-to-remove-unwanted-edges.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/21_why-groups.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/22_creating-the-second-floor.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/23_creating-additional-openings.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/24_hide-model-and-other-useful-shortcuts.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/25_using-the-outliner.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/26_using-layers-to-control-visibility.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/27_viewing-layer-states-of-the-model.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/28_field-of-view.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/29_dividing-faces-to-create-your-rooms.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/30_area-tool-for-calculations.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/31_using-paint-bucket-for-floor-texture-2.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/31_using-paint-bucket-for-floor-texture.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/32_importing-and-applying-a-texture.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/33_positioning-an-imported-texture.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/34_editing-texture-colour-in-sketchup.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/35_editing-a-texture-in-photoshop.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/36_hide-edges-and-lines-with-the-eraser-tool.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/37_creating-the-ceiling.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/38_assigning-layers-within-groups.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/39_adding-detail-chapter-7.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/40_creating-crown-moulding.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/41_copy-and-paste-in-place.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/42_why-we-use-groups-and-components.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/43_creating-the-staircase.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/44_adding-riser-detail.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/45_making-a-unique-bottom-step.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/46_adding-spindles-with-move-and-copy.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/47_adding-railing.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/48_review-of-components-and-nested-groups.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/49_creating-doors.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/50_creating-the-front-window-frame.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/51_double-hung-windows.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/52_installing-bit-tools-plugins.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/53_creating-walls-and-door-openings.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/54_using-the-window-feature.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/55_starting-at-the-base.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/56_building-the-mantle.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/57_mantle-columns.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/58_mantle-support.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/59_adding-textures.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/60_base-cabinets.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/61_wall-cabinets.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/62_cabinet-doors.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/63_creating-the-countertop.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/64_adding-materials.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/65_adding-appliances.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/66_adding-the-fridge-and-sink.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/67_using-the-3d-warehouse.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/68_using-form-fonts.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/69_using-the-podium-browser.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/70_creating-a-library.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/71_setting-up-to-match-a-new-photo.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/72_creating-the-massing-model.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/73_applying-textures.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/74_adding-detail-chapter-13.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/75_saving-and-placing-into-the-model.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/76_creating-the-exterior.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/77_setting-the-building-in-place-geolocation.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/78_reset-axis-to-align-building.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/79_creating-the-front-facade.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/80_adding-context.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/81_get-photo-google-street-view.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/82_using-3d-text.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/83_add-solar-panels-with-skelion-plugin.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/84_creating-scenes-and-updating.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/85_styles.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/86_scenes-for-animation.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/87_section-cut-for-interior-elevations.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/88_creating-a-group.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/89_creating-the-animation.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/90_jpeg-and-png-files.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/91_dwg-elevation-and-plan-pro-feature.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/92_kmz-for-google-earth.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/93_collada-files.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/94_animation-options.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/95_add-final-touches.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/96_export-display-options.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/97_stacking-images-in-photoshop.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/98_multiply-and-opacity.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/99_saving-the-image.mp4        
+     8224768  60%    2.54MB/s    0:00:02
+remote: 
+remote: ok        
+remote: (Recording state in git...)        
+[2014-05-25 21:41:47 CEST] RemoteControl: Syncing with diskstation 
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   e459e2f..26c6449  git-annex -> synced/git-annex
+   6f2044d..7500a88  master -> synced/master
+    10911744  80%    2.52MB/s    0:00:01
+    13603741 100%    2.69MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 13605572 bytes  received 42 bytes  2473748.00 bytes/sec
+total size is 13603741  speedup is 1.00
+[2014-05-25 21:41:49 CEST] Transferrer: Uploaded 32_import..xture.mp4
+
+WORM-s13731971-m1398386799--Learning SketchUp 2013%31_using-paint-bucket-for-floor-texture.mp4
+       32768   0%    0.00kB/s    0:00:00
+     2752512  20%    2.48MB/s    0:00:04
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   297826c..ee2d7a6  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/master is at 7500a886b58db7f0a3d2d279a946215525109cd2 but expected 6f2044d781d283993104edb9f8b96041801c1e76
+ ! 6f2044d..7500a88  master     -> diskstation/master  (unable to update local ref)
+[2014-05-25 21:41:51 CEST] Pusher: Syncing with diskstation 
+     5373952  39%    2.45MB/s    0:00:03
+     9404416  68%    2.88MB/s    0:00:01
+    12681216  92%    2.63MB/s    0:00:00
+    13731971 100%    2.84MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 13733822 bytes  received 42 bytes  2497066.18 bytes/sec
+total size is 13731971  speedup is 1.00
+[2014-05-25 21:41:54 CEST] Transferrer: Uploaded 31_using-..xture.mp4
+
+WORM-s13731971-m1398386799--Learning SketchUp 2013%31_using-paint-bucket-for-floor-texture-2.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      3211264  23%    2.96MB/s    0:00:03
+     7634944  55%    3.55MB/s    0:00:01
+[2014-05-25 21:41:57 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   26c6449..9d66740  git-annex -> synced/git-annex
+    11370496  82%    3.54MB/s    0:00:00
+    13731971 100%    3.62MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 13733824 bytes  received 42 bytes  2497066.55 bytes/sec
+total size is 13731971  speedup is 1.00
+[2014-05-25 21:41:59 CEST] Transferrer: Uploaded 31_using-..ure-2.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   ee2d7a6..be030de  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 9d667409bdd47098b595460d26a4a47a7477b602 but expected 26c64492572c692eb6c5e3af0922849d42142cc5
+ ! 26c6449..9d66740  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+WORM-s6958518-m1398385748--Learning SketchUp 2013%30_area-tool-for-calculations.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4096000  58%    3.77MB/s    0:00:00
+[2014-05-25 21:42:01 CEST] Pusher: Syncing with diskstation 
+     5505024  79%    2.56MB/s    0:00:00
+     6958518 100%    2.63MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 6959530 bytes  received 42 bytes  1988449.14 bytes/sec
+total size is 6958518  speedup is 1.00
+[2014-05-25 21:42:02 CEST] Transferrer: Uploaded 30_area-t..tions.mp4
+
+WORM-s17894336-m1398385618--Learning SketchUp 2013%29_dividing-faces-to-create-your-rooms.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      5210112  29%    4.90MB/s    0:00:02
+     8617984  48%    3.99MB/s    0:00:02
+    10715136  59%    3.34MB/s    0:00:02
+[2014-05-25 21:42:07 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   9d66740..2f65ea4  git-annex -> synced/git-annex
+    13336576  74%    3.11MB/s    0:00:01
+    16842752  94%    2.72MB/s    0:00:00
+    17894336 100%    3.16MB/s    0:00:05 (xfer#1, to-check=0/1)
+
+sent 17896694 bytes  received 42 bytes  2753344.00 bytes/sec
+total size is 17894336  speedup is 1.00
+[2014-05-25 21:42:09 CEST] Transferrer: Uploaded 29_dividi..rooms.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   be030de..afc435c  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 2f65ea464ab39db40b09478a6857d41450b394d3 but expected 9d667409bdd47098b595460d26a4a47a7477b602
+ ! 9d66740..2f65ea4  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 21:42:10 CEST] Committer: Adding 107_addin..sions.mp4 110_prese..aving.mp4
+ok
+(Recording state in git...)
+(Recording state in git...)
+
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+(merging diskstation/git-annex into git-annex...)
+(Recording state in git...)
+add Learning SketchUp 2013/107_adding-annotations-and-dimensions.mp4 ok
+add Learning SketchUp 2013/110_presenting-and-saving.mp4 [2014-05-25 21:42:10 CEST] Committer: Committing changes to git
+
+WORM-s16183756-m1398386984--Learning SketchUp 2013%28_field-of-view.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:42:11 CEST] Pusher: Syncing with diskstation 
+     5177344  31%    4.80MB/s    0:00:02
+Already up-to-date.
+     9306112  57%    4.38MB/s    0:00:01
+    13434880  83%    4.21MB/s    0:00:00
+remote: merge git-annex     16183756 100%    3.91MB/s    0:00:03 (xfer#1, to-check=0/1)
+[2014-05-25 21:42:16 CEST] RemoteControl: Syncing with diskstation 
+
+sent 16185880 bytes  received 42 bytes  2942894.91 bytes/sec
+total size is 16183756  speedup is 1.00
+[2014-05-25 21:42:16 CEST] Transferrer: Uploaded 28_field-..-view.m(merging synced/git-annex into git-annex...)        
+premote: (Recording state in git...)        
+4remote: ok        
+remote: merge synced/master 
+
+WORM-s8653832-m1398386968--Learning SketchUp 2013%110_presenting-and-saving.mp4
+       32768   0%    0.00kB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   afc435c..2feeb97  git-annex  -> diskstation/git-annex
+   2f65ea4..de80d6d  synced/git-annex -> diskstation/synced/git-annex
+   7500a88..af4c173  synced/master -> diskstation/synced/master
+     4390912  50%    4.13MB/s    0:00:01
+Already up-to-date.
+     7045120  81%    3.30MB/s    0:00:00
+Updating 7500a88..af4c173        
+remote: Fast-forward        
+remote:  Learning SketchUp 2013/107_adding-annotations-and-dimensions.mp4 | 1 +        
+remote:  Learning SketchUp 2013/110_presenting-and-saving.mp4             | 1 +        
+remote:  2 files changed, 2 insertions(+)        
+remote:  create mode 120000 Learning SketchUp 2013/107_adding-annotations-and-dimensions.mp4        
+remote:  create mode 120000 Learning SketchUp 2013/110_presenting-and-saving.mp4        
+     8653832 100%    3.26MB/s    0:00:02 (xfer#1, to-check=0/1)
+remote: 
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   2f65ea4..de80d6d  git-annex -> synced/git-annex
+   7500a88..af4c173  master -> synced/master
+
+sent 8655048 bytes  received 42 bytes  1923353.33 bytes/sec
+total size is 8653832  speedup is 1.00
+[2014-05-25 21:42:20 CEST] Transferrer: Uploaded 110_prese..aving.mp4
+[2014-05-25 21:42:20 CEST] RemoteControl: Syncing with diskstation 
+
+WORM-s12740321-m1398386533--Learning SketchUp 2013%107_adding-annotations-and-dimensions.mp4
+       32768   0%    0.00kB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   2feeb97..c393949  git-annex  -> diskstation/git-annex
+   7500a88..af4c173  master     -> diskstation/master
+     4685824  36%    4.30MB/s    0:00:01
+     7667712  60%    3.56MB/s    0:00:01
+    10518528  82%    3.25MB/s    0:00:00
+[2014-05-25 21:42:24 CEST] Pusher: Syncing with diskstation 
+    12740321 100%    3.20MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 12742046 bytes  received 42 bytes  2316743.27 bytes/sec
+total size is 12740321  speedup is 1.00
+[2014-05-25 21:42:25 CEST] Transferrer: Uploaded 107_addin..sions.mp4
+
+WORM-s21683651-m1398384839--Learning SketchUp 2013%27_viewing-layer-states-of-the-model.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      4358144  20%    4.11MB/s    0:00:04
+     7438336  34%    3.47MB/s    0:00:04
+[2014-05-25 21:42:29 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   de80d6d..da93668  git-annex -> synced/git-annex
+     9273344  42%    2.81MB/s    0:00:04
+    12189696  56%    2.78MB/s    0:00:03
+    15532032  71%    2.54MB/s    0:00:02
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   c393949..9f19ee8  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at da936685ca807cb619e2d6073c857cdcdc345dde but expected de80d6dd537ca7e4bfade9d40eade18afc58878b
+ ! de80d6d..da93668  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    19300352  89%    2.70MB/s    0:00:00
+    21683651 100%    2.95MB/s    0:00:06 (xfer#1, to-check=0/1)
+[2014-05-25 21:42:33 CEST] Pusher: Syncing with diskstation 
+
+sent 21686467 bytes  received 42 bytes  2551354.00 bytes/sec
+total size is 21683651  speedup is 1.00
+[2014-05-25 21:42:33 CEST] Transferrer: Uploaded 27_viewin..model.mp4
+
+WORM-s16669986-m1398385184--Learning SketchUp 2013%26_using-layers-to-control-visibility.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      4259840  25%    3.95MB/s    0:00:03
+     7274496  43%    3.37MB/s    0:00:02
+[2014-05-25 21:42:37 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   da93668..fc553e7  git-annex -> synced/git-annex
+    10387456  62%    3.21MB/s    0:00:01
+    13500416  80%    3.14MB/s    0:00:00
+    16613376  99%    2.87MB/s    0:00:00
+    16669986 100%    3.09MB/s    0:00:05 (xfer#1, to-check=0/1)
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   9f19ee8..a8b9203  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at fc553e72a5ea5a077a254df3f557b3d6241d9342 but expected da936685ca807cb619e2d6073c857cdcdc345dde
+ ! da93668..fc553e7  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+sent 16672191 bytes  received 42 bytes  2564958.92 bytes/sec
+total size is 16669986  speedup is 1.00
+[2014-05-25 21:42:40 CEST] Transferrer: Uploaded 26_using-..ility.mp4
+
+WORM-s8161367-m1398386819--Learning SketchUp 2013%25_using-the-outliner.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4620288  56%    4.32MB/s    0:00:00
+[2014-05-25 21:42:41 CEST] Pusher: Syncing with diskstation 
+     8161367 100%    3.89MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 8162519 bytes  received 42 bytes  3265024.40 bytes/sec
+total size is 8161367  speedup is 1.00
+[2014-05-25 21:42:42 CEST] Transferrer: Uploaded 25_using-..liner.mp4
+
+WORM-s26081165-m1398387035--Learning SketchUp 2013%24_hide-model-and-other-useful-shortcuts.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4620288  17%    4.27MB/s    0:00:04
+remote: merge git-annex      6193152  23%    2.82MB/s    0:00:06
+     9568256  36%    2.93MB/s    0:00:05
+    13631488  52%    3.16MB/s    0:00:03
+[2014-05-25 21:42:47 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   fc553e7..7eccd72  git-annex -> synced/git-annex
+    17203200  65%    2.92MB/s    0:00:02
+    21561344  82%    3.62MB/s    0:00:01
+    25362432  97%    3.72MB/s    0:00:00
+    26081165 100%    3.37MB/s    0:00:07 (xfer#1, to-check=0/1)
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   a8b9203..829ce2e  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 7eccd720d952d1ec3a1ee00cc524732ec970285f but expected fc553e72a5ea5a077a254df3f557b3d6241d9342
+ ! fc553e7..7eccd72  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+sent 26084521 bytes  received 42 bytes  2745743.47 bytes/sec
+total size is 26081165  speedup is 1.00
+[2014-05-25 21:42:51 CEST] Transferrer: Uploaded 24_hide-m..tcuts.mp4
+
+WORM-s24710536-m1398386140--Learning SketchUp 2013%23_creating-additional-openings.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:42:52 CEST] Pusher: Syncing with diskstation 
+     5111808  20%    4.80MB/s    0:00:03
+     9142272  36%    4.25MB/s    0:00:03
+    12648448  51%    3.92MB/s    0:00:03
+    16023552  64%    3.71MB/s    0:00:02
+remote: merge git-annex     19365888  78%    3.27MB/s    0:00:01
+    22478848  90%    3.05MB/s    0:00:00
+[2014-05-25 21:42:58 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   7eccd72..5dd7ceb  git-annex -> synced/git-annex
+    24710536 100%    3.34MB/s    0:00:07 (xfer#1, to-check=0/1)
+
+sent 24713719 bytes  received 42 bytes  2907501.29 bytes/sec
+total size is 24710536  speedup is 1.00
+[2014-05-25 21:42:59 CEST] Transferrer: Uploaded 23_creati..nings.mp4
+
+WORM-s27007278-m1398386399--Learning SketchUp 2013%22_creating-the-second-floor.mp4
+       32768   0%    0.00kB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   829ce2e..432e319  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 5dd7ceb17a57b1f11edb692c3c20eb05f7c89aa7 but expected 7eccd720d952d1ec3a1ee00cc524732ec970285f
+ ! 7eccd72..5dd7ceb  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     4194304  15%    3.94MB/s    0:00:05
+     6946816  25%    3.24MB/s    0:00:06
+[2014-05-25 21:43:02 CEST] Pusher: Syncing with diskstation 
+     9830400  36%    3.06MB/s    0:00:05
+    12582912  46%    2.96MB/s    0:00:04
+remote: merge git-annex     15761408  58%    2.73MB/s    0:00:04
+    18481152  68%    2.71MB/s    0:00:03
+[2014-05-25 21:43:06 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   5dd7ceb..114c7a8  git-annex -> synced/git-annex
+    21889024  81%    2.82MB/s    0:00:01
+    24805376  91%    2.86MB/s    0:00:00
+    27007278 100%    2.89MB/s    0:00:08 (xfer#1, to-check=0/1)
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   432e319..ee3c95a  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 114c7a8e0d0873ea44ebfd8a5989b7e4f6fe300d but expected 5dd7ceb17a57b1f11edb692c3c20eb05f7c89aa7
+ ! 5dd7ceb..114c7a8  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+sent 27010738 bytes  received 42 bytes  2572455.24 bytes/sec
+total size is 27007278  speedup is 1.00
+[2014-05-25 21:43:09 CEST] Transferrer: Uploaded 22_creati..floor.mp4
+
+WORM-s11952523-m1398387004--Learning SketchUp 2013%21_why-groups.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3538944  29%    3.13MB/s    0:00:02
+[2014-05-25 21:43:11 CEST] Pusher: Syncing with diskstation 
+     4849664  40%    2.11MB/s    0:00:03
+     8257536  69%    2.44MB/s    0:00:01
+    11272192  94%    2.54MB/s    0:00:00
+remote: merge git-annex     11952523 100%    2.56MB/s    0:00:04 (xfer#1, to-check=0/1)
+[2014-05-25 21:43:15 CEST] RemoteControl: Syncing with diskstation 
+
+sent 11954128 bytes  received 42 bytes  2173485.45 bytes/sec
+total size is 11952523  speedup is 1.00
+[2014-05-25 21:43:15 CEST] Transferrer: Uploaded 21_why-groups.mp4
+
+WORM-s14698958-m1401045757--Learning SketchUp 2013%20_clean-up-using-the-eraser-to-remove-unwanted-edges.mp4
+       32768   0%    0.00kB/s    0:00:00
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   114c7a8..70d2843  git-annex -> synced/git-annex
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   ee3c95a..292456c  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 70d2843ca3fd83291be9e3a83c8a2b1d393344fc but expected 114c7a8e0d0873ea44ebfd8a5989b7e4f6fe300d
+ ! 114c7a8..70d2843  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 21:43:17 CEST] RemoteControl: Syncing with diskstation 
+     4489216  30%    4.09MB/s    0:00:02
+     7634944  51%    3.53MB/s    0:00:01
+    10715136  72%    3.32MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   292456c..489a02f  git-annex  -> diskstation/git-annex
+    14254080  96%    3.32MB/s    0:00:00
+    14698958 100%    3.27MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 14700939 bytes  received 42 bytes  2261689.38 bytes/sec
+total size is 14698958  speedup is 1.00
+[2014-05-25 21:43:21 CEST] Transferrer: Uploaded 20_clean-..edges.mp4
+[2014-05-25 21:43:21 CEST] Pusher: Syncing with diskstation 
+
+WORM-s53078315-m1401045818--Learning SketchUp 2013%19_creating-doors-and-openings.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5046272   9%    4.66MB/s    0:00:10
+     9109504  17%    4.21MB/s    0:00:10
+remote: merge git-annex     12779520  24%    3.96MB/s    0:00:09
+    16187392  30%    3.76MB/s    0:00:09
+    20676608  38%    3.66MB/s    0:00:08
+[2014-05-25 21:43:27 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   70d2843..0d8c767  git-annex -> synced/git-annex
+    24739840  46%    3.67MB/s    0:00:07
+    28573696  53%    3.71MB/s    0:00:06
+    32243712  60%    3.76MB/s    0:00:05
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   489a02f..7a7f5ca  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 0d8c76720fa6b51cf2cf5edf847e732dd550ab40 but expected 70d2843ca3fd83291be9e3a83c8a2b1d393344fc
+ ! 70d2843..0d8c767  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    36765696  69%    3.74MB/s    0:00:04
+    40697856  76%    3.72MB/s    0:00:03
+    44564480  83%    3.73MB/s    0:00:02
+    47316992  89%    3.53MB/s    0:00:01
+    50331648  94%    3.18MB/s    0:00:00
+    53078315 100%    3.62MB/s    0:00:13 (xfer#1, to-check=0/1)
+
+sent 53084957 bytes  received 42 bytes  3424838.65 bytes/sec
+total size is 53078315  speedup is 1.00
+[2014-05-25 21:43:36 CEST] Transferrer: Uploaded 19_creati..nings.mp4
+[2014-05-25 21:43:36 CEST] Pusher: Syncing with diskstation 
+
+WORM-s30352251-m1398385646--Learning SketchUp 2013%18_extruding-your-walls-push-pull-and-offset.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4784128  15%    4.50MB/s    0:00:05
+remote: merge git-annex      8159232  26%    3.81MB/s    0:00:05
+    10256384  33%    3.17MB/s    0:00:06
+[2014-05-25 21:43:40 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   0d8c767..6f8ae3d  git-annex -> synced/git-annex
+    13271040  43%    3.06MB/s    0:00:05
+    16318464  53%    2.65MB/s    0:00:05
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   7a7f5ca..bef94a6  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 6f8ae3d49d1006e2d5cf957d7539c0818db4df12 but expected 0d8c76720fa6b51cf2cf5edf847e732dd550ab40
+ ! 0d8c767..6f8ae3d  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    19070976  62%    2.51MB/s    0:00:04
+    21954560  72%    2.71MB/s    0:00:03
+    24969216  82%    2.72MB/s    0:00:01
+    27852800  91%    2.69MB/s    0:00:00
+    30352251 100%    2.87MB/s    0:00:10 (xfer#1, to-check=0/1)
+
+sent 30356135 bytes  received 42 bytes  2639667.57 bytes/sec
+total size is 30352251  speedup is 1.00
+[2014-05-25 21:43:48 CEST] Transferrer: Uploaded 18_extrud..ffset.mp4
+[2014-05-25 21:43:48 CEST] Pusher: Syncing with diskstation 
+
+WORM-s14102612-m1398386513--Learning SketchUp 2013%16_measurements.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4554752  32%    4.23MB/s    0:00:02
+     7634944  54%    3.59MB/s    0:00:01
+remote: merge git-annex     10584064  75%    3.29MB/s    0:00:01
+[2014-05-25 21:43:52 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   6f8ae3d..32eee1a  git-annex -> synced/git-annex
+    13434880  95%    3.13MB/s    0:00:00
+    14102612 100%    3.14MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 14104483 bytes  received 42 bytes  2564459.09 bytes/sec
+total size is 14102612  speedup is 1.00
+[2014-05-25 21:43:53 CEST] Transferrer: Uploaded 16_measurements.mp4
+
+WORM-s16792198-m1398384994--Learning SketchUp 2013%15_creating-a-gambrel-roof.mp4
+       32768   0%    0.00kB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   bef94a6..10025f1  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 32eee1aff2a03a33e7cc200fefcef41ce775767e but expected 6f8ae3d49d1006e2d5cf957d7539c0818db4df12
+ ! 6f8ae3d..32eee1a  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     4128768  24%    3.88MB/s    0:00:03
+     7012352  41%    3.26MB/s    0:00:02
+[2014-05-25 21:43:56 CEST] Pusher: Syncing with diskstation 
+     9895936  58%    3.07MB/s    0:00:02
+    12648448  75%    2.95MB/s    0:00:01
+remote: merge git-annex     14745600  87%    2.48MB/s    0:00:00
+    16416768  97%    2.20MB/s    0:00:00
+    16792198 100%    2.58MB/s    0:00:06 (xfer#1, to-check=0/1)
+[2014-05-25 21:44:01 CEST] RemoteControl: Syncing with diskstation 
+
+sent 16794408 bytes  received 42 bytes  1975817.65 bytes/sec
+total size is 16792198  speedup is 1.00
+[2014-05-25 21:44:01 CEST] Transferrer: Uploaded 15_creati..-roof.mp4
+
+WORM-s33139501-m1398386446--Learning SketchUp 2013%14_creating-a-mansard-roof.mp4
+       32768   0%    0.00kB/s    0:00:00
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   32eee1a..cc461b8  git-annex -> synced/git-annex
+     4685824  14%    4.39MB/s    0:00:06
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   10025f1..f39db09  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at cc461b8c48eb38d8f0b020a9c22440dada4973f0 but expected 32eee1aff2a03a33e7cc200fefcef41ce775767e
+ ! 32eee1a..cc461b8  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 21:44:03 CEST] RemoteControl: Syncing with diskstation 
+     8159232  24%    3.84MB/s    0:00:06
+    11730944  35%    3.67MB/s    0:00:05
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   f39db09..d356ca4  git-annex  -> diskstation/git-annex
+    16351232  49%    3.85MB/s    0:00:04
+[2014-05-25 21:44:07 CEST] Pusher: Syncing with diskstation 
+    20119552  60%    3.63MB/s    0:00:03
+    23265280  70%    3.52MB/s    0:00:02
+    25952256  78%    3.31MB/s    0:00:02
+remote: merge git-annex     28803072  86%    2.89MB/s    0:00:01
+(merging synced/git-annex into git-annex...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   cc461b8..f90e094  git-annex -> synced/git-annex
+    31653888  95%    2.67MB/s    0:00:00
+    33139501 100%    3.28MB/s    0:00:09 (xfer#1, to-check=0/1)
+
+sent 33143707 bytes  received 42 bytes  2882065.13 bytes/sec
+total size is 33139501  speedup is 1.00
+[2014-05-25 21:44:12 CEST] Transferrer: Uploaded 14_creati..-roof.mp4
+
+WORM-s32543230-m1398386371--Learning SketchUp 2013%13_using-follow-me-complex-roof-pitches.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4718592  14%    4.45MB/s    0:00:06
+[2014-05-25 21:44:14 CEST] Pusher: Syncing with diskstation 
+     7340032  22%    3.45MB/s    0:00:07
+    10125312  31%    3.18MB/s    0:00:06
+    12877824  39%    3.03MB/s    0:00:06
+remote: merge git-annex     15892480  48%    2.64MB/s    0:00:06
+    18579456  57%    2.64MB/s    0:00:05
+    21561344  66%    2.67MB/s    0:00:04
+[2014-05-25 21:44:20 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   f90e094..795020d  git-annex -> synced/git-annex
+    24412160  75%    2.70MB/s    0:00:02
+    27164672  83%    2.61MB/s    0:00:02
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   d356ca4..7d763cd  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 795020d6aa856441f602de8d1f2f7efb98c00f20 but expected f90e0945bc55e8e50115bccec9672d1df7c23e69
+ ! f90e094..795020d  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    28737536  88%    2.28MB/s    0:00:01
+    30703616  94%    2.05MB/s    0:00:00
+    32543230 100%    2.58MB/s    0:00:12 (xfer#1, to-check=0/1)
+
+sent 32547377 bytes  received 42 bytes  2410919.93 bytes/sec
+total size is 32543230  speedup is 1.00
+[2014-05-25 21:44:25 CEST] Transferrer: Uploaded 13_using-..tches.mp4
+[2014-05-25 21:44:25 CEST] Pusher: Syncing with diskstation 
+
+WORM-s22461160-m1401045786--Learning SketchUp 2013%12_push-pull-and-move-tool.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4161536  18%    3.80MB/s    0:00:04
+remote: merge git-annex      6782976  30%    3.13MB/s    0:00:04
+     9666560  43%    2.95MB/s    0:00:04
+[2014-05-25 21:44:29 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   795020d..496b7bd  git-annex -> synced/git-annex
+    12681216  56%    2.91MB/s    0:00:03
+    15859712  70%    2.70MB/s    0:00:02
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   7d763cd..2bf57cb  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 496b7bd40f4c979efdd6196eccadeeb370bb4ec3 but expected 795020d6aa856441f602de8d1f2f7efb98c00f20
+ ! 795020d..496b7bd  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    18579456  82%    2.72MB/s    0:00:01
+    20414464  90%    2.50MB/s    0:00:00
+    22461160 100%    2.69MB/s    0:00:07 (xfer#1, to-check=0/1)
+
+sent 22464062 bytes  received 42 bytes  2364642.53 bytes/sec
+total size is 22461160  speedup is 1.00
+[2014-05-25 21:44:34 CEST] Transferrer: Uploaded 12_push-p..-tool.mp4
+[2014-05-25 21:44:34 CEST] Pusher: Syncing with diskstation 
+
+WORM-s15320679-m1398386653--Learning SketchUp 2013%11_navigating-in-3d.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4587520  29%    4.18MB/s    0:00:02
+remote: merge git-annex      7471104  48%    3.45MB/s    0:00:02
+    10223616  66%    3.16MB/s    0:00:01
+[2014-05-25 21:44:38 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   496b7bd..eefc387  git-annex -> synced/git-annex
+    12976128  84%    3.00MB/s    0:00:00
+    15320679 100%    2.92MB/s    0:00:04 (xfer#1, to-check=0/1)
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   2bf57cb..310d31e  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at eefc387772b3e6ba46f51fbecd86cdabcd27db96 but expected 496b7bd40f4c979efdd6196eccadeeb370bb4ec3
+ ! 496b7bd..eefc387  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+sent 15322702 bytes  received 42 bytes  2357345.23 bytes/sec
+total size is 15320679  speedup is 1.00
+[2014-05-25 21:44:40 CEST] Transferrer: Uploaded 11_naviga..in-3d.mp4
+
+WORM-s6065317-m1398386928--Learning SketchUp 2013%111_about-dan-brown.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4292608  70%    3.98MB/s    0:00:00
+[2014-05-25 21:44:42 CEST] Pusher: Syncing with diskstation 
+     6065317 100%    3.02MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 6066211 bytes  received 42 bytes  1733215.14 bytes/sec
+total size is 6065317  speedup is 1.00
+[2014-05-25 21:44:43 CEST] Transferrer: Uploaded 111_about..brown.mp4
+
+WORM-s2764724-m1398386941--Learning SketchUp 2013%10_freehand-tool.mp4
+       32768   1%    0.00kB/s    0:00:00
+     2764724 100%    5.18MB/s    0:00:00 (xfer#1, to-check=0/1)
+
+sent 2765211 bytes  received 42 bytes  1843502.00 bytes/sec
+total size is 2764724  speedup is 1.00
+[2014-05-25 21:44:45 CEST] Transferrer: Uploaded 10_freeha..-tool.mp4
+remote: merge git-annex 
+WORM-s6834151-m1398385049--Learning SketchUp 2013%109_updating-the-model-references.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4227072  61%    3.81MB/s    0:00:00
+     6834151 100%    3.46MB/s    0:00:01 (xfer#1, to-check=0/1)
+[2014-05-25 21:44:47 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   eefc387..dc4c11c  git-annex -> synced/git-annex
+
+sent 6835151 bytes  received 42 bytes  1952912.29 bytes/sec
+total size is 6834151  speedup is 1.00
+[2014-05-25 21:44:48 CEST] Transferrer: Uploaded 109_updat..ences.mp4
+
+WORM-s6878166-m1398386493--Learning SketchUp 2013%108_adding-additional-pages-and-content.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4259840  61%    3.87MB/s    0:00:00
+     6878166 100%    3.80MB/s    0:00:01 (xfer#1, to-check=0/1)
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   310d31e..e2f5d0d  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at dc4c11c618002775bb0e8dcf4b132113c40875ed but expected eefc387772b3e6ba46f51fbecd86cdabcd27db96
+ ! eefc387..dc4c11c  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+sent 6879176 bytes  received 42 bytes  1965490.86 bytes/sec
+total size is 6878166  speedup is 1.00
+[2014-05-25 21:44:51 CEST] Transferrer: Uploaded 108_addin..ntent.mp4
+
+WORM-s8253246-m1398386838--Learning SketchUp 2013%106_adjusting-the-model-settings.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:44:52 CEST] Pusher: Syncing with diskstation 
+     2588672  31%    2.32MB/s    0:00:02
+     4554752  55%    2.10MB/s    0:00:01
+     8093696  98%    2.51MB/s    0:00:00
+     8253246 100%    2.52MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 8254417 bytes  received 42 bytes  1834324.22 bytes/sec
+total size is 8253246  speedup is 1.00
+[2014-05-25 21:44:55 CEST] Transferrer: Uploaded 106_adjus..tings.mp4
+
+WORM-s5364896-m1398386068--Learning SketchUp 2013%105_what-is-layout.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      4816896  89%    4.56MB/s    0:00:00
+     5364896 100%    4.39MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 5365701 bytes  received 42 bytes  2146297.20 bytes/sec
+total size is 5364896  speedup is 1.00
+[2014-05-25 21:44:58 CEST] RemoteControl: Syncing with diskstation 
+[2014-05-25 21:44:58 CEST] Transferrer: Uploaded 105_what-..ayout.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   dc4c11c..a19dfa9  git-annex -> synced/git-annex
+
+WORM-s7390741-m1398386693--Learning SketchUp 2013%104_post-processing-in-photoshop.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4227072  57%    3.91MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   e2f5d0d..73400d3  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at a19dfa9bd0b4aee28bf67773a9f578a9bb94f2e9 but expected dc4c11c618002775bb0e8dcf4b132113c40875ed
+ ! dc4c11c..a19dfa9  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     7241728  97%    3.34MB/s    0:00:00
+     7390741 100%    3.35MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 7391808 bytes  received 42 bytes  1642633.33 bytes/sec
+total size is 7390741  speedup is 1.00
+[2014-05-25 21:45:02 CEST] Transferrer: Uploaded 104_post-..oshop.mp4
+
+WORM-s12544086-m1398385948--Learning SketchUp 2013%103_rendering-a-high-quality-image.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:45:03 CEST] Pusher: Syncing with diskstation 
+     4292608  34%    3.96MB/s    0:00:02
+     7307264  58%    3.39MB/s    0:00:01
+     9535488  76%    2.97MB/s    0:00:00
+remote: merge git-annex     12419072  99%    2.91MB/s    0:00:00
+    12544086 100%    2.90MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 12545784 bytes  received 42 bytes  2281059.27 bytes/sec
+total size is 12544086  speedup is 1.00
+[2014-05-25 21:45:07 CEST] RemoteControl: Syncing with diskstation 
+[2014-05-25 21:45:07 CEST] Transferrer: Uploaded 103_rende..image.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   a19dfa9..96ceb2c  git-annex -> synced/git-annex
+
+WORM-s6567293-m1398384854--Learning SketchUp 2013%102_model-presets-create-a-preview-rendering.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4128768  62%    3.83MB/s    0:00:00
+     6567293 100%    3.26MB/s    0:00:01 (xfer#1, to-check=0/1)
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   73400d3..3e5d1b8  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 96ceb2c0e06ff0f1372950ab38c2aa2ebb0f00d7 but expected a19dfa9bd0b4aee28bf67773a9f578a9bb94f2e9
+ ! a19dfa9..96ceb2c  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+sent 6568272 bytes  received 42 bytes  1876661.14 bytes/sec
+total size is 6567293  speedup is 1.00
+[2014-05-25 21:45:11 CEST] Transferrer: Uploaded 102_model..ering.mp4
+
+WORM-s8030582-m1398385367--Learning SketchUp 2013%101_add-reflections-to-existing-textures.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4423680  55%    4.18MB/s    0:00:00
+[2014-05-25 21:45:12 CEST] Pusher: Syncing with diskstation 
+     7569408  94%    3.54MB/s    0:00:00
+     8030582 100%    3.53MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 8031737 bytes  received 42 bytes  2294794.00 bytes/sec
+total size is 8030582  speedup is 1.00
+[2014-05-25 21:45:14 CEST] Transferrer: Uploaded 101_add-r..tures.mp4
+
+WORM-s13509940-m1398384818--Learning SketchUp 2013%100_adding-lighting.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4587520  33%    4.25MB/s    0:00:02
+remote: merge git-annex      7831552  57%    3.62MB/s    0:00:01
+    10420224  77%    3.24MB/s    0:00:00
+[2014-05-25 21:45:18 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   96ceb2c..a5f9c8b  git-annex -> synced/git-annex
+    13509940 100%    3.28MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 13511743 bytes  received 42 bytes  2456688.18 bytes/sec
+total size is 13509940  speedup is 1.00
+[2014-05-25 21:45:19 CEST] Transferrer: Uploaded 100_addin..hting.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   3e5d1b8..6ea05e0  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at a5f9c8b9874d4d3fe571687365c391050325bc87 but expected 96ceb2c0e06ff0f1372950ab38c2aa2ebb0f00d7
+ ! 96ceb2c..a5f9c8b  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+WORM-s6047748-m1398386548--Learning SketchUp 2013%09_arc-tool.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4751360  78%    4.47MB/s    0:00:00
+     6047748 100%    4.50MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 6048630 bytes  received 42 bytes  2419468.80 bytes/sec
+total size is 6047748  speedup is 1.00
+[2014-05-25 21:45:22 CEST] Pusher: Syncing with diskstation 
+[2014-05-25 21:45:22 CEST] Transferrer: Uploaded 09_arc-tool.mp4
+
+WORM-s7257160-m1398385203--Learning SketchUp 2013%08_polygon-tool.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5079040  69%    4.65MB/s    0:00:00
+remote: merge git-annex      7257160 100%    4.35MB/s    0:00:01 (xfer#1, to-check=0/1)
+[2014-05-25 21:45:25 CEST] RemoteControl: Syncing with diskstation 
+
+sent 7258194 bytes  received 42 bytes  2073781.71 bytes/sec
+total size is 7257160  speedup is 1.00
+[2014-05-25 21:45:25 CEST] Transferrer: Uploaded 08_polygon-tool.mp4
+
+WORM-s6789048-m1398386463--Learning SketchUp 2013%07_circle-tool.mp4
+       32768   0%    0.00kB/s    0:00:00
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   a5f9c8b..05787b8  git-annex -> synced/git-annex
+     2654208  39%    2.46MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   6ea05e0..b78228d  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 05787b8b7c6dd1aad45fdb0a019a2ed5e56b26bb but expected a5f9c8b9874d4d3fe571687365c391050325bc87
+ ! a5f9c8b..05787b8  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 21:45:28 CEST] RemoteControl: Syncing with diskstation 
+     5013504  73%    2.35MB/s    0:00:00
+     6789048 100%    2.62MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 6790025 bytes  received 42 bytes  1940019.14 bytes/sec
+total size is 6789048  speedup is 1.00
+[2014-05-25 21:45:29 CEST] Transferrer: Uploaded 07_circle-tool.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   b78228d..f1fd60c  git-annex  -> diskstation/git-annex
+
+WORM-s3766669-m1398384958--Learning SketchUp 2013%06_rectangle-tool.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:45:31 CEST] Pusher: Syncing with diskstation 
+     3702784  98%    2.95MB/s    0:00:00
+     3766669 100%    3.00MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 3767277 bytes  received 42 bytes  1506927.60 bytes/sec
+total size is 3766669  speedup is 1.00
+[2014-05-25 21:45:31 CEST] Transferrer: Uploaded 06_rectan..-tool.mp4
+
+WORM-s5571735-m1398386867--Learning SketchUp 2013%05_line-tool.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5144576  92%    4.78MB/s    0:00:00
+     5571735 100%    4.70MB/s    0:00:01 (xfer#1, to-check=0/1)
+remote: merge git-annex 
+sent 5572562 bytes  received 42 bytes  2229041.60 bytes/sec
+total size is 5571735  speedup is 1.00
+[2014-05-25 21:45:33 CEST] Transferrer: Uploaded 05_line-tool.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+[2014-05-25 21:45:35 CEST] RemoteConTo joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+trol: Syncing with diskstati   05787b8..2a723a6  ogit-annex -> synced/git-annexn
+ 
+
+WORM-s13796050-m1398386633--Learning SketchUp 2013%04_how-to-access-your-working-files.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4915200  35%    4.65MB/s    0:00:01
+     8159232  59%    3.77MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   f1fd60c..bdd7ed6  git-annex  -> diskstation/git-annex
+    11304960  81%    3.45MB/s    0:00:00
+    13796050 100%    3.57MB/s    0:00:03 (xfer#1, to-check=0/1)
+[2014-05-25 21:45:38 CEST] Pusher: Syncing with diskstation 
+
+sent 13797905 bytes  received 42 bytes  2508717.64 bytes/sec
+total size is 13796050  speedup is 1.00
+[2014-05-25 21:45:39 CEST] Transferrer: Uploaded 04_how-to..files.mp4
+
+WORM-s5852944-m1398386582--Learning SketchUp 2013%03_setting-up-the-toolbars.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4947968  84%    4.65MB/s    0:00:00
+     5852944 100%    4.42MB/s    0:00:01 (xfer#1, to-check=0/1)
+remote: merge git-annex [2014-05-25 21:45:42 CEST] RemoteControl: Syncing with diskstation 
+
+sent 5853817 bytes  received 42 bytes  2341543.60 bytes/sec
+total size is 5852944  speedup is 1.00
+[2014-05-25 21:45:42 CEST] Transferrer: Uploaded 03_settin..lbars.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   2a723a6..dc76c23  git-annex -> synced/git-annex
+
+WORM-s3829366-m1398386198--Learning SketchUp 2013%02_setting-up-the-template.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3829366 100%    4.68MB/s    0:00:00 (xfer#1, to-check=0/1)
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   bdd7ed6..84f8e25  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at dc76c234409bd5cfac50be70dd21ef8be88aed9b but expected 2a723a6697455228d8b2e95a7015aafb4be4f003
+ ! 2a723a6..dc76c23  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+sent 3829991 bytes  received 42 bytes  1532013.20 bytes/sec
+total size is 3829366  speedup is 1.00
+[2014-05-25 21:45:45 CEST] Transferrer: Uploaded 02_settin..plate.mp4
+
+WORM-s6528377-m1398386753--Learning SketchUp 2013%01_introduction.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4718592  72%    4.42MB/s    0:00:00
+[2014-05-25 21:45:47 CEST] Pusher: Syncing with diskstation 
+     6528377 100%    3.21MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 6529323 bytes  received 42 bytes  2611746.00 bytes/sec
+total size is 6528377  speedup is 1.00
+[2014-05-25 21:45:48 CEST] Transferrer: Uploaded 01_introduction.mp4
+
+WORM-s5900041-m1398386278--Learning SketchUp 2013%99_saving-the-image.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5079040  86%    4.72MB/s    0:00:00
+     5900041 100%    4.60MB/s    0:00:01 (xfer#1, to-check=0/1)
+remote: merge git-annex 
+sent 5900915 bytes  received 42 bytes  2360382.80 bytes/sec
+total size is 5900041  speedup is 1.00
+[2014-05-25 21:45:50 CEST] Transferrer: Uploaded 99_saving..image.mp4
+
+WORM-s7221607-m1398385119--Learning SketchUp 2013%98_multiply-and-opacity.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:45:52 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   dc76c23..60c1e82  git-annex -> synced/git-annex
+     4456448  61%    4.07MB/s    0:00:00
+     7221607 100%    4.25MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 7222645 bytes  received 42 bytes  2889074.80 bytes/sec
+total size is 7221607  speedup is 1.00
+[2014-05-25 21:45:54 CEST] Transferrer: Uploaded 98_multip..acity.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   84f8e25..3261510  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 60c1e827e829b642d4618889b425c0bfc259b2c9 but expected dc76c234409bd5cfac50be70dd21ef8be88aed9b
+ ! dc76c23..60c1e82  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+WORM-s6262129-m1398386258--Learning SketchUp 2013%97_stacking-images-in-photoshop.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4947968  79%    4.69MB/s    0:00:00
+     6262129 100%    4.40MB/s    0:00:01 (xfer#1, to-check=0/1)
+[2014-05-25 21:45:56 CEST] Pusher: Syncing with diskstation 
+
+sent 6263059 bytes  received 42 bytes  2505240.40 bytes/sec
+total size is 6262129  speedup is 1.00
+[2014-05-25 21:45:56 CEST] Transferrer: Uploaded 97_stacki..oshop.mp4
+
+WORM-s9298049-m1398385793--Learning SketchUp 2013%96_export-display-options.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5177344  55%    4.84MB/s    0:00:00
+remote: merge git-annex      8519680  91%    4.01MB/s    0:00:00
+     9298049 100%    3.97MB/s    0:00:02 (xfer#1, to-check=0/1)
+[2014-05-25 21:46:00 CEST] RemoteControl: Syncing with diskstation 
+
+sent 9299341 bytes  received 42 bytes  2656966.57 bytes/sec
+total size is 9298049  speedup is 1.00
+[2014-05-25 21:46:00 CEST] Transferrer: Uploaded 96_export..tions.mp4
+
+WORM-s7895136-m1398385533--Learning SketchUp 2013%95_add-final-touches.mp4
+       32768   0%    0.00kB/s    0:00:00
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   60c1e82..f08968c  git-annex -> synced/git-annex
+     4325376  54%    4.06MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   3261510..c9b4dc3  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at f08968c15cbe86c49c1fb71f22f578ad7cecd680 but expected 60c1e827e829b642d4618889b425c0bfc259b2c9
+ ! 60c1e82..f08968c  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 21:46:02 CEST] RemoteControl: Syncing with diskstation 
+     7895136 100%    3.99MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 7896251 bytes  received 42 bytes  2256083.71 bytes/sec
+total size is 7895136  speedup is 1.00
+[2014-05-25 21:46:03 CEST] Transferrer: Uploaded 95_add-fi..uches.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   c9b4dc3..78519cd  git-annex  -> diskstation/git-annex
+
+WORM-s13569035-m1398385318--Learning SketchUp 2013%94_animation-options.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5373952  39%    5.00MB/s    0:00:01
+[2014-05-25 21:46:05 CEST] Pusher: Syncing with diskstation 
+     9437184  69%    4.45MB/s    0:00:00
+    13565952  99%    4.26MB/s    0:00:00
+    13569035 100%    4.26MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 13570847 bytes  received 42 bytes  3015753.11 bytes/sec
+total size is 13569035  speedup is 1.00
+[2014-05-25 21:46:07 CEST] Transferrer: Uploaded 94_animat..tions.mp4
+
+WORM-s8278464-m1398386213--Learning SketchUp 2013%93_collada-files.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      5341184  64%    4.98MB/s    0:00:00
+     8278464 100%    4.37MB/s    0:00:01 (xfer#1, to-check=0/1)
+[2014-05-25 21:46:10 CEST] RemoteControl: Syncing with diskstation 
+
+sent 8279623 bytes  received 42 bytes  2365618.57 bytes/sec
+total size is 8278464  speedup is 1.00
+[2014-05-25 21:46:10 CEST] Transferrer: Uploaded 93_collad..files.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   f08968c..f99a466  git-annex -> synced/git-annex
+
+WORM-s8934010-m1398386414--Learning SketchUp 2013%92_kmz-for-google-earth.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4784128  53%    4.43MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   78519cd..e30d06f  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at f99a466d7568addbbc99cb058f66a2c03c571fba but expected f08968c15cbe86c49c1fb71f22f578ad7cecd680
+ ! f08968c..f99a466  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     8934010 100%    4.24MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 8935256 bytes  received 42 bytes  2552942.29 bytes/sec
+total size is 8934010  speedup is 1.00
+[2014-05-25 21:46:13 CEST] Transferrer: Uploaded 92_kmz-fo..earth.mp4
+
+WORM-s9716042-m1398384915--Learning SketchUp 2013%91_dwg-elevation-and-plan-pro-feature.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5341184  54%    5.00MB/s    0:00:00
+[2014-05-25 21:46:15 CEST] Pusher: Syncing with diskstation 
+     9371648  96%    4.39MB/s    0:00:00
+     9716042 100%    4.44MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 9717398 bytes  received 42 bytes  2776411.43 bytes/sec
+total size is 9716042  speedup is 1.00
+[2014-05-25 21:46:16 CEST] Transferrer: Uploaded 91_dwg-el..ature.mp4
+
+WORM-s14343030-m1398386888--Learning SketchUp 2013%90_jpeg-and-png-files.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      5079040  35%    4.81MB/s    0:00:01
+     9535488  66%    4.50MB/s    0:00:01
+[2014-05-25 21:46:19 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   f99a466..af84b87  git-annex -> synced/git-annex
+    13565952  94%    4.25MB/s    0:00:00
+    14343030 100%    3.99MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 14344935 bytes  received 42 bytes  2608177.64 bytes/sec
+total size is 14343030  speedup is 1.00
+[2014-05-25 21:46:21 CEST] Transferrer: Uploaded 90_jpeg-a..files.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   e30d06f..c6bcde6  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at af84b876d0902aa7da89ca414becf5b9d98d8a19 but expected f99a466d7568addbbc99cb058f66a2c03c571fba
+ ! f99a466..af84b87  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+WORM-s10692771-m1398385558--Learning SketchUp 2013%89_creating-the-animation.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5341184  49%    4.94MB/s    0:00:01
+[2014-05-25 21:46:23 CEST] Pusher: Syncing with diskstation 
+     9535488  89%    4.43MB/s    0:00:00
+    10692771 100%    4.41MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 10694236 bytes  received 42 bytes  3055508.00 bytes/sec
+total size is 10692771  speedup is 1.00
+[2014-05-25 21:46:24 CEST] Transferrer: Uploaded 89_creati..ation.mp4
+
+WORM-s14320839-m1398385514--Learning SketchUp 2013%88_creating-a-group.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5308416  37%    5.02MB/s    0:00:01
+remote: merge git-annex      9469952  66%    4.47MB/s    0:00:01
+    13631488  95%    4.28MB/s    0:00:00
+    14320839 100%    4.31MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 14322742 bytes  received 42 bytes  3182840.89 bytes/sec
+total size is 14320839  speedup is 1.00
+[2014-05-25 21:46:28 CEST] RemoteControl: Syncing with diskstation 
+[2014-05-25 21:46:28 CEST] Transferrer: Uploaded 88_creati..group.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   af84b87..7f1137a  git-annex -> synced/git-annex
+
+WORM-s20730987-m1398385414--Learning SketchUp 2013%87_section-cut-for-interior-elevations.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5341184  25%    4.91MB/s    0:00:03
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   c6bcde6..a8341a2  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 7f1137a28d8b17c5cdc10e856578da6337d1143c but expected af84b876d0902aa7da89ca414becf5b9d98d8a19
+ ! af84b87..7f1137a  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     9371648  45%    4.38MB/s    0:00:02
+    13860864  66%    4.33MB/s    0:00:01
+[2014-05-25 21:46:33 CEST] Pusher: Syncing with diskstation 
+    18055168  87%    4.23MB/s    0:00:00
+    20730987 100%    4.19MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 20733689 bytes  received 42 bytes  3189804.77 bytes/sec
+total size is 20730987  speedup is 1.00
+[2014-05-25 21:46:35 CEST] Transferrer: Uploaded 87_sectio..tions.mp4
+
+WORM-s21661288-m1398385144--Learning SketchUp 2013%86_scenes-for-animation.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      5177344  23%    4.89MB/s    0:00:03
+     9404416  43%    4.46MB/s    0:00:02
+[2014-05-25 21:46:38 CEST] RemoteControl: Syncing with diskstation 
+    13631488  62%    4.28MB/s    0:00:01
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   7f1137a..9338de4  git-annex -> synced/git-annex
+    17170432  79%    4.04MB/s    0:00:01
+    20905984  96%    3.69MB/s    0:00:00
+    21661288 100%    3.90MB/s    0:00:05 (xfer#1, to-check=0/1)
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   a8341a2..72c4e65  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 9338de4e5a82415622d40ef588287666f8757fc0 but expected 7f1137a28d8b17c5cdc10e856578da6337d1143c
+ ! 7f1137a..9338de4  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+sent 21664091 bytes  received 42 bytes  3332943.54 bytes/sec
+total size is 21661288  speedup is 1.00
+[2014-05-25 21:46:41 CEST] Transferrer: Uploaded 86_scenes..ation.mp4
+
+WORM-s23994784-m1398385930--Learning SketchUp 2013%85_styles.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5177344  21%    4.83MB/s    0:00:03
+[2014-05-25 21:46:42 CEST] Pusher: Syncing with diskstation 
+     9371648  39%    4.39MB/s    0:00:03
+    13565952  56%    4.26MB/s    0:00:02
+    17661952  73%    4.17MB/s    0:00:01
+remote: merge git-annex     21856256  91%    3.94MB/s    0:00:00
+    23994784 100%    4.08MB/s    0:00:05 (xfer#1, to-check=0/1)
+
+sent 23997857 bytes  received 42 bytes  3691984.46 bytes/sec
+total size is 23994784  speedup is 1.00
+[2014-05-25 21:46:48 CEST] RemoteControl: Syncing with diskstation 
+[2014-05-25 21:46:48 CEST] Transferrer: Uploaded 85_styles.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   9338de4..47c3025  git-annex -> synced/git-annex
+
+WORM-s9421737-m1398386334--Learning SketchUp 2013%84_creating-scenes-and-updating.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4128768  43%    3.80MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   72c4e65..3862dfd  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 47c3025b26597ab96c6553b17d40df2473761367 but expected 9338de4e5a82415622d40ef588287666f8757fc0
+ ! 9338de4..47c3025  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     7045120  74%    3.29MB/s    0:00:00
+     9421737 100%    3.42MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 9423051 bytes  received 42 bytes  2094020.67 bytes/sec
+total size is 9421737  speedup is 1.00
+[2014-05-25 21:46:52 CEST] Transferrer: Uploaded 84_creati..ating.mp4
+
+WORM-s15890796-m1398387058--Learning SketchUp 2013%83_add-solar-panels-with-skelion-plugin.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3932160  24%    3.64MB/s    0:00:03
+[2014-05-25 21:46:54 CEST] Pusher: Syncing with diskstation 
+     8093696  50%    3.80MB/s    0:00:02
+    11304960  71%    3.54MB/s    0:00:01
+    14516224  91%    3.40MB/s    0:00:00
+    15890796 100%    3.45MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 15892907 bytes  received 42 bytes  2889627.09 bytes/sec
+total size is 15890796  speedup is 1.00
+[2014-05-25 21:46:58 CEST] Transferrer: Uploaded 83_add-so..lugin.mp4
+remote: merge git-annex 
+WORM-s9278449-m1398386852--Learning SketchUp 2013%82_using-3d-text.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5439488  58%    5.07MB/s    0:00:00
+     9278449 100%    4.51MB/s    0:00:01 (xfer#1, to-check=0/1)
+[2014-05-25 21:47:00 CEST] RemoteControl: Syncing with diskstation 
+
+sent 9279732 bytes  received 42 bytes  3711909.60 bytes/sec
+total size is 9278449  speedup is 1.00
+[2014-05-25 21:47:00 CEST] Transferrer: Uploaded 82_using-..-text.mp4
+
+WORM-s11983231-m1398385259--Learning SketchUp 2013%81_get-photo-google-street-view.mp4
+       32768   0%    0.00kB/s    0:00:00
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   47c3025..a7b0dc9  git-annex -> synced/git-annex
+     5079040  42%    4.63MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   3862dfd..5f94bb2  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at a7b0dc9c64973369eb06a57d14ed6e64ec20fa07 but expected 47c3025b26597ab96c6553b17d40df2473761367
+ ! 47c3025..a7b0dc9  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 21:47:03 CEST] RemoteControl: Syncing with diskstation 
+     9404416  78%    4.32MB/s    0:00:00
+    11983231 100%    4.36MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 11984858 bytes  received 42 bytes  2663311.11 bytes/sec
+total size is 11983231  speedup is 1.00
+[2014-05-25 21:47:04 CEST] Transferrer: Uploaded 81_get-ph..-view.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   5f94bb2..521740c  git-annex  -> diskstation/git-annex
+
+WORM-s10154793-m1398385298--Learning SketchUp 2013%80_adding-context.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5242880  51%    4.94MB/s    0:00:00
+[2014-05-25 21:47:06 CEST] Pusher: Syncing with diskstation 
+     9437184  92%    4.40MB/s    0:00:00
+    10154793 100%    4.41MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 10156182 bytes  received 42 bytes  2901778.29 bytes/sec
+total size is 10154793  speedup is 1.00
+[2014-05-25 21:47:07 CEST] Transferrer: Uploaded 80_adding..ntext.mp4
+
+WORM-s15455988-m1398386244--Learning SketchUp 2013%79_creating-the-front-facade.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5308416  34%    4.93MB/s    0:00:02
+remote: merge git-annex      9306112  60%    4.38MB/s    0:00:01
+    12124160  78%    3.73MB/s    0:00:00
+[2014-05-25 21:47:12 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   a7b0dc9..7a6f85f  git-annex -> synced/git-annex
+    13434880  86%    3.11MB/s    0:00:00
+    15455988 100%    3.14MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 15458036 bytes  received 42 bytes  2810559.64 bytes/sec
+total size is 15455988  speedup is 1.00
+[2014-05-25 21:47:13 CEST] Transferrer: Uploaded 79_creati..acade.mp4
+
+WORM-s7511926-m1398385903--Learning SketchUp 2013%78_reset-axis-to-align-building.mp4
+       32768   0%    0.00kB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   521740c..57437fb  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 7a6f85f7864920fbcac361f47558fc352f1d2d16 but expected a7b0dc9c64973369eb06a57d14ed6e64ec20fa07
+ ! a7b0dc9..7a6f85f  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     4554752  60%    4.27MB/s    0:00:00
+     7511926 100%    4.13MB/s    0:00:01 (xfer#1, to-check=0/1)
+[2014-05-25 21:47:16 CEST] Pusher: Syncing with diskstation 
+
+sent 7513008 bytes  received 42 bytes  2146585.71 bytes/sec
+total size is 7511926  speedup is 1.00
+[2014-05-25 21:47:16 CEST] Transferrer: Uploaded 78_reset-..lding.mp4
+
+WORM-s9197360-m1398386099--Learning SketchUp 2013%77_setting-the-building-in-place-geolocation.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4521984  49%    4.04MB/s    0:00:01
+remote: merge git-annex      7962624  86%    3.66MB/s    0:00:00
+     9197360 100%    3.73MB/s    0:00:02 (xfer#1, to-check=0/1)
+[2014-05-25 21:47:21 CEST] RemoteControl: Syncing with diskstation 
+
+sent 9198659 bytes  received 42 bytes  2628200.29 bytes/sec
+total size is 9197360  speedup is 1.00
+[2014-05-25 21:47:21 CEST] Transferrer: Uploaded 77_settin..ation.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   7a6f85f..7457693  git-annex -> synced/git-annex
+
+WORM-s11971891-m1398387083--Learning SketchUp 2013%76_creating-the-exterior.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4784128  39%    4.52MB/s    0:00:01
+     8355840  69%    3.95MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   57437fb..394b254  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 7457693b085f06be2a38cfaafb7c76b34eb62960 but expected 7a6f85f7864920fbcac361f47558fc352f1d2d16
+ ! 7a6f85f..7457693  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    11971891 100%    4.15MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 11973511 bytes  received 42 bytes  3421015.14 bytes/sec
+total size is 11971891  speedup is 1.00
+[2014-05-25 21:47:25 CEST] Transferrer: Uploaded 76_creati..erior.mp4
+[2014-05-25 21:47:26 CEST] Pusher: Syncing with diskstation 
+
+WORM-s6407146-m1398386568--Learning SketchUp 2013%75_saving-and-placing-into-the-model.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4390912  68%    4.14MB/s    0:00:00
+     6324224  98%    2.99MB/s    0:00:00
+     6407146 100%    3.02MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 6408097 bytes  received 42 bytes  1830896.86 bytes/sec
+total size is 6407146  speedup is 1.00
+[2014-05-25 21:47:28 CEST] Transferrer: Uploaded 75_saving..model.mp4
+
+WORM-s8962345-m1398386088--Learning SketchUp 2013%74_adding-detail-chapter-13.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      5144576  57%    4.78MB/s    0:00:00
+     8962345 100%    4.67MB/s    0:00:01 (xfer#1, to-check=0/1)
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+
+sent 8963599 bytes  received 42 bytes  2561040.29 bytes/sec
+total size is 8962345  speedup is 1.00
+   7457693..ea4b518  git-annex -> synced/git-annex
+[2014-05-25 21:47:31 CEST] RemoteControl: Syncing with diskstation 
+[2014-05-25 21:47:31 CEST] Transferrer: Uploaded 74_adding..er-13.mp4
+
+WORM-s7160845-m1398385888--Learning SketchUp 2013%73_applying-textures.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4816896  67%    4.45MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   394b254..c52b780  git-annex  -> diskstation/git-annex
+     7160845 100%    4.44MB/s    0:00:01 (xfer#1, to-check=0/1)
+
+sent 7161872 bytes  received 42 bytes  2046261.14 bytes/sec
+total size is 7160845  speedup is 1.00
+[2014-05-25 21:47:34 CEST] Transferrer: Uploaded 73_applyi..tures.mp4
+
+WORM-s11661338-m1398385993--Learning SketchUp 2013%72_creating-the-massing-model.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:47:35 CEST] Pusher: Syncing with diskstation 
+     5341184  45%    4.97MB/s    0:00:01
+     8028160  68%    3.71MB/s    0:00:00
+     9601024  82%    2.97MB/s    0:00:00
+    11661338 100%    3.00MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 11662923 bytes  received 42 bytes  2120539.09 bytes/sec
+total size is 11661338  speedup is 1.00
+[2014-05-25 21:47:39 CEST] Transferrer: Uploaded 72_creati..model.mp4
+
+WORM-s18351413-m1398385439--Learning SketchUp 2013%71_setting-up-to-match-a-new-photo.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      4816896  26%    4.56MB/s    0:00:02
+     8945664  48%    4.23MB/s    0:00:02
+[2014-05-25 21:47:42 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   ea4b518..d1f5994  git-annex -> synced/git-annex
+    13467648  73%    4.25MB/s    0:00:01
+    17104896  93%    4.04MB/s    0:00:00
+    18351413 100%    4.03MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 18353823 bytes  received 42 bytes  3337066.36 bytes/sec
+total size is 18351413  speedup is 1.00
+[2014-05-25 21:47:44 CEST] Transferrer: Uploaded 71_settin..photo.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   c52b780..c25cca9  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at d1f5994466b35d4c32ad5a9bbb9dd071e461e3e2 but expected ea4b518d3f3234433b2819aa9965b5613366f1bb
+ ! ea4b518..d1f5994  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+WORM-s13344990-m1398385353--Learning SketchUp 2013%70_creating-a-library.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3506176  26%    3.17MB/s    0:00:03
+[2014-05-25 21:47:47 CEST] Pusher: Syncing with diskstation 
+     6914048  51%    3.20MB/s    0:00:01
+    11337728  84%    3.52MB/s    0:00:00
+    13344990 100%    3.56MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 13346775 bytes  received 42 bytes  2426694.00 bytes/sec
+total size is 13344990  speedup is 1.00
+[2014-05-25 21:47:49 CEST] Transferrer: Uploaded 70_creati..brary.mp4
+
+WORM-s9842222-m1398386008--Learning SketchUp 2013%69_using-the-podium-browser.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      5275648  53%    4.88MB/s    0:00:00
+     8323072  84%    3.89MB/s    0:00:00
+     9842222 100%    3.92MB/s    0:00:02 (xfer#1, to-check=0/1)
+[2014-05-25 21:47:52 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   d1f5994..33198fa  git-annex -> synced/git-annex
+
+sent 9843584 bytes  received 42 bytes  2812464.57 bytes/sec
+total size is 9842222  speedup is 1.00
+[2014-05-25 21:47:53 CEST] Transferrer: Uploaded 69_using-..owser.mp4
+
+WORM-s11662587-m1398385968--Learning SketchUp 2013%68_using-form-fonts.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4653056  39%    4.33MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   c25cca9..2496e60  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 33198fa7a8195245180bb53efbdec32359506368 but expected d1f5994466b35d4c32ad5a9bbb9dd071e461e3e2
+ ! d1f5994..33198fa  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     9437184  80%    4.41MB/s    0:00:00
+    11662587 100%    4.32MB/s    0:00:02 (xfer#1, to-check=0/1)
+[2014-05-25 21:47:57 CEST] Pusher: Syncing with diskstation 
+
+sent 11664162 bytes  received 42 bytes  3332629.71 bytes/sec
+total size is 11662587  speedup is 1.00
+[2014-05-25 21:47:57 CEST] Transferrer: Uploaded 68_using-..fonts.mp4
+
+WORM-s8289672-m1398385702--Learning SketchUp 2013%67_using-the-3d-warehouse.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5439488  65%    4.99MB/s    0:00:00
+remote: merge git-annex      8289672 100%    4.48MB/s    0:00:01 (xfer#1, to-check=0/1)
+[2014-05-25 21:48:00 CEST] RemoteControl: Syncing with diskstation 
+
+sent 8290840 bytes  received 42 bytes  3316352.80 bytes/sec
+total size is 8289672  speedup is 1.00
+[2014-05-25 21:48:00 CEST] Transferrer: Uploaded 67_using-..house.mp4
+
+WORM-s12841748-m1398385284--Learning SketchUp 2013%66_adding-the-fridge-and-sink.mp4
+       32768   0%    0.00kB/s    0:00:00
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   33198fa..f4258a2  git-annex -> synced/git-annex
+     3899392  30%    3.62MB/s    0:00:02
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   2496e60..8f91b25  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at f4258a2cd12ee4f23f3a9c9b9c635b9d59075f21 but expected 33198fa7a8195245180bb53efbdec32359506368
+ ! 33198fa..f4258a2  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 21:48:03 CEST] RemoteControl: Syncing with diskstation 
+     7897088  61%    3.69MB/s    0:00:01
+    11698176  91%    3.66MB/s    0:00:00
+    12841748 100%    3.72MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 12843477 bytes  received 42 bytes  2335185.27 bytes/sec
+total size is 12841748  speedup is 1.00
+[2014-05-25 21:48:05 CEST] Transferrer: Uploaded 66_adding..-sink.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   8f91b25..c4dc443  git-annex  -> diskstation/git-annex
+
+WORM-s15640646-m1398385334--Learning SketchUp 2013%65_adding-appliances.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5505024  35%    5.08MB/s    0:00:01
+[2014-05-25 21:48:07 CEST] Pusher: Syncing with diskstation 
+     9601024  61%    4.50MB/s    0:00:01
+    13860864  88%    4.32MB/s    0:00:00
+    15640646 100%    4.28MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 15642710 bytes  received 42 bytes  3476167.11 bytes/sec
+total size is 15640646  speedup is 1.00
+[2014-05-25 21:48:09 CEST] Transferrer: Uploaded 65_adding..ances.mp4
+
+WORM-s14906076-m1398385849--Learning SketchUp 2013%64_adding-materials.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      4620288  30%    4.38MB/s    0:00:02
+[2014-05-25 21:48:12 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   f4258a2..89ce825  git-annex -> synced/git-annex
+     7700480  51%    3.61MB/s    0:00:01
+    10649600  71%    3.30MB/s    0:00:01
+    13467648  90%    3.13MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   c4dc443..6fdf232  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 89ce825f4a57b9bc5490b2c0f7dc77e9b3cf0016 but expected f4258a2cd12ee4f23f3a9c9b9c635b9d59075f21
+ ! f4258a2..89ce825  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    14906076 100%    3.07MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 14908047 bytes  received 42 bytes  2293552.15 bytes/sec
+total size is 14906076  speedup is 1.00
+[2014-05-25 21:48:15 CEST] Transferrer: Uploaded 64_adding..rials.mp4
+
+WORM-s9700735-m1398385733--Learning SketchUp 2013%63_creating-the-countertop.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4554752  46%    4.18MB/s    0:00:01
+[2014-05-25 21:48:17 CEST] Pusher: Syncing with diskstation 
+     7569408  78%    3.53MB/s    0:00:00
+     9700735 100%    3.40MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 9702080 bytes  received 42 bytes  2156027.11 bytes/sec
+total size is 9700735  speedup is 1.00
+[2014-05-25 21:48:19 CEST] Transferrer: Uploaded 63_creati..ertop.mp4
+
+WORM-s15089043-m1398386778--Learning SketchUp 2013%62_cabinet-doors.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      4456448  29%    4.05MB/s    0:00:02
+     7340032  48%    3.36MB/s    0:00:02
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   89ce825..be1967a  git-annex -> synced/git-annex
+[2014-05-25 21:48:22 CEST] RemoteControl: Syncing with diskstation 
+    10223616  67%    3.12MB/s    0:00:01
+    13369344  88%    3.08MB/s    0:00:00
+    15089043 100%    3.02MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 15091035 bytes  received 42 bytes  2321704.15 bytes/sec
+total size is 15089043  speedup is 1.00
+[2014-05-25 21:48:25 CEST] Transferrer: Uploaded 62_cabine..doors.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   6fdf232..5d94435  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at be1967a15a951b38c76e4e8f674812a01df4c8c8 but expected 89ce825f4a57b9bc5490b2c0f7dc77e9b3cf0016
+ ! 89ce825..be1967a  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+WORM-s10872872-m1398384973--Learning SketchUp 2013%61_wall-cabinets.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4194304  38%    3.90MB/s    0:00:01
+[2014-05-25 21:48:27 CEST] Pusher: Syncing with diskstation 
+     7208960  66%    3.34MB/s    0:00:01
+    10190848  93%    3.16MB/s    0:00:00
+    10872872 100%    3.14MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 10874348 bytes  received 42 bytes  2416531.11 bytes/sec
+total size is 10872872  speedup is 1.00
+remote: merge git-annex [2014-05-25 21:48:29 CEST] Transferrer: Uploaded 61_wall-c..inets.mp4
+
+WORM-s14169006-m1398385488--Learning SketchUp 2013%60_base-cabinets.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4292608  30%    3.96MB/s    0:00:02
+[2014-05-25 21:48:31 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   be1967a..0c0e83a  git-annex -> synced/git-annex
+     7143424  50%    3.29MB/s    0:00:02
+    10289152  72%    3.16MB/s    0:00:01
+    13139968  92%    3.03MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   5d94435..c7aef43  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 0c0e83a4b729ed1ef86e4854405ec752226bbd09 but expected be1967a15a951b38c76e4e8f674812a01df4c8c8
+ ! be1967a..0c0e83a  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    14169006 100%    3.08MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 14170886 bytes  received 42 bytes  2180142.77 bytes/sec
+total size is 14169006  speedup is 1.00
+[2014-05-25 21:48:35 CEST] Transferrer: Uploaded 60_base-c..inets.mp4
+[2014-05-25 21:48:35 CEST] Pusher: Syncing with diskstation 
+
+WORM-s13699702-m1398385658--Learning SketchUp 2013%59_adding-textures.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4063232  29%    3.80MB/s    0:00:02
+remote: merge git-annex      7503872  54%    3.54MB/s    0:00:01
+    11599872  84%    3.65MB/s    0:00:00
+    13699702 100%    3.75MB/s    0:00:03 (xfer#1, to-check=0/1)
+[2014-05-25 21:48:41 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   0c0e83a..cd5b9c0  git-annex -> synced/git-annex
+
+sent 13701528 bytes  received 42 bytes  3044793.33 bytes/sec
+total size is 13699702  speedup is 1.00
+[2014-05-25 21:48:42 CEST] Transferrer: Uploaded 59_adding..tures.mp4
+
+WORM-s10444949-m1398386483--Learning SketchUp 2013%58_mantle-support.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5177344  49%    4.89MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   c7aef43..e499593  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at cd5b9c01988d7c7b10730356ed55cc8b1422ce52 but expected 0c0e83a4b729ed1ef86e4854405ec752226bbd09
+ ! 0c0e83a..cd5b9c0  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     9175040  87%    4.34MB/s    0:00:00
+    10444949 100%    3.92MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 10446374 bytes  received 42 bytes  2984690.29 bytes/sec
+total size is 10444949  speedup is 1.00
+[2014-05-25 21:48:46 CEST] Transferrer: Uploaded 58_mantle..pport.mp4
+[2014-05-25 21:48:46 CEST] Pusher: Syncing with diskstation 
+
+WORM-s24021797-m1398385079--Learning SketchUp 2013%57_mantle-columns.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5079040  21%    4.81MB/s    0:00:03
+     9011200  37%    4.25MB/s    0:00:03
+    13041664  54%    4.09MB/s    0:00:02
+remote: merge git-annex     17006592  70%    3.97MB/s    0:00:01
+    20643840  85%    3.61MB/s    0:00:00
+[2014-05-25 21:48:52 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   cd5b9c0..7f4755f  git-annex -> synced/git-annex
+    23887872  99%    3.44MB/s    0:00:00
+    24021797 100%    3.69MB/s    0:00:06 (xfer#1, to-check=0/1)
+
+sent 24024882 bytes  received 42 bytes  3203323.20 bytes/sec
+total size is 24021797  speedup is 1.00
+[2014-05-25 21:48:53 CEST] Transferrer: Uploaded 57_mantle..lumns.mp4
+
+WORM-s20301926-m1398385822--Learning SketchUp 2013%56_building-the-mantle.mp4
+       32768   0%    0.00kB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   e499593..a7e1df5  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 7f4755fe1b2fbe86253a5854d83948a479df1302 but expected cd5b9c01988d7c7b10730356ed55cc8b1422ce52
+ ! cd5b9c0..7f4755f  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     4358144  21%    4.07MB/s    0:00:03
+[2014-05-25 21:48:55 CEST] Pusher: Syncing with diskstation 
+     7241728  35%    3.34MB/s    0:00:03
+    10125312  49%    3.14MB/s    0:00:03
+    13271040  65%    3.10MB/s    0:00:02
+remote: merge git-annex     16154624  79%    2.73MB/s    0:00:01
+    18972672  93%    2.74MB/s    0:00:00
+[2014-05-25 21:49:00 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   7f4755f..367f02c  git-annex -> synced/git-annex
+    20301926 100%    2.92MB/s    0:00:06 (xfer#1, to-check=0/1)
+
+sent 20304560 bytes  received 42 bytes  2388776.71 bytes/sec
+total size is 20301926  speedup is 1.00
+[2014-05-25 21:49:01 CEST] Transferrer: Uploaded 56_buildi..antle.mp4
+
+WORM-s15278630-m1398386298--Learning SketchUp 2013%55_starting-at-the-base.mp4
+       32768   0%    0.00kB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   a7e1df5..200c73f  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 367f02ceec6d27fdb719156715a8a24a9f0cc149 but expected 7f4755fe1b2fbe86253a5854d83948a479df1302
+ ! 7f4755f..367f02c  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     4653056  30%    4.41MB/s    0:00:02
+     7733248  50%    3.61MB/s    0:00:02
+[2014-05-25 21:49:04 CEST] Pusher: Syncing with diskstation 
+    10616832  69%    3.32MB/s    0:00:01
+    13500416  88%    3.14MB/s    0:00:00
+    15278630 100%    3.14MB/s    0:00:04 (xfer#1, to-check=0/1)
+remote: merge git-annex 
+sent 15280653 bytes  received 42 bytes  2350876.15 bytes/sec
+total size is 15278630  speedup is 1.00
+[2014-05-25 21:49:07 CEST] Transferrer: Uploaded 55_starti..-base.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   367f02c..e9cb764  git-annex -> synced/git-annex
+
+WORM-s17900868-m1398386914--Learning SketchUp 2013%54_using-the-window-feature.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:49:08 CEST] RemoteControl: Syncing with diskstation 
+     4718592  26%    4.44MB/s    0:00:02
+     8290304  46%    3.92MB/s    0:00:02
+    12189696  68%    3.85MB/s    0:00:01
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   200c73f..e2eb7b5  git-annex  -> diskstation/git-annex
+    16482304  92%    3.88MB/s    0:00:00
+    17900868 100%    3.91MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 17903215 bytes  received 42 bytes  2754347.23 bytes/sec
+total size is 17900868  speedup is 1.00
+[2014-05-25 21:49:13 CEST] Pusher: Syncing with diskstation 
+[2014-05-25 21:49:13 CEST] Transferrer: Uploaded 54_using-..ature.mp4
+
+WORM-s13516185-m1398386734--Learning SketchUp 2013%53_creating-walls-and-door-openings.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5242880  38%    4.94MB/s    0:00:01
+     9273344  68%    4.36MB/s    0:00:00
+remote: merge git-annex     13369344  98%    4.17MB/s    0:00:00
+    13516185 100%    4.17MB/s    0:00:03 (xfer#1, to-check=0/1)
+[2014-05-25 21:49:18 CEST] RemoteControl: Syncing with diskstation 
+
+sent 13518004 bytes  received 42 bytes  3004010.22 bytes/sec
+total size is 13516185  speedup is 1.00
+[2014-05-25 21:49:18 CEST] Transferrer: Uploaded 53_creati..nings.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+
+WORM-s18590095-m1398385163--Learning SketchUp 2013%52_installing-bit-tools-plugins.mp4
+   e9cb764..c7f1783  git-annex -> synced/git-annex
+       32768   0%    0.00kB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   e2eb7b5..ff506d2  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at c7f178361d32682b60332b5c508a3ce0aec3925c but expected e9cb7644b684d418952b4132c725211eb045b260
+ ! e9cb764..c7f1783  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+[2014-05-25 21:49:19 CEST] RemoteControl: Syncing with diskstation 
+     4259840  22%    3.88MB/s    0:00:03
+     6684672  35%    3.09MB/s    0:00:03
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   ff506d2..ff2bd4c  git-annex  -> diskstation/git-annex
+    10813440  58%    3.36MB/s    0:00:02
+[2014-05-25 21:49:23 CEST] Pusher: Syncing with diskstation 
+    14876672  80%    3.46MB/s    0:00:01
+    18590095 100%    3.53MB/s    0:00:05 (xfer#1, to-check=0/1)
+
+sent 18592530 bytes  received 42 bytes  2860395.69 bytes/sec
+total size is 18590095  speedup is 1.00
+[2014-05-25 21:49:24 CEST] Transferrer: Uploaded 52_instal..ugins.mp4
+
+WORM-s28284719-m1398385600--Learning SketchUp 2013%51_double-hung-windows.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5046272  17%    4.72MB/s    0:00:04
+remote: merge git-annex      9076736  32%    4.27MB/s    0:00:04
+    13303808  47%    4.16MB/s    0:00:03
+[2014-05-25 21:49:29 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   c7f1783..a39803a  git-annex -> synced/git-annex
+    16711680  59%    3.89MB/s    0:00:02
+    18841600  66%    3.14MB/s    0:00:02
+    21331968  75%    2.78MB/s    0:00:02
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   ff2bd4c..338767b  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at a39803aef5ce739ae6a6472a7de156efac31bebc but expected c7f178361d32682b60332b5c508a3ce0aec3925c
+ ! c7f1783..a39803a  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    26050560  92%    2.89MB/s    0:00:00
+    28284719 100%    3.45MB/s    0:00:07 (xfer#1, to-check=0/1)
+
+sent 28288329 bytes  received 42 bytes  2977723.26 bytes/sec
+total size is 28284719  speedup is 1.00
+[2014-05-25 21:49:34 CEST] Transferrer: Uploaded 51_double..ndows.mp4
+
+WORM-s16987083-m1398385579--Learning SketchUp 2013%50_creating-the-front-window-frame.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:49:35 CEST] Pusher: Syncing with diskstation 
+     5144576  30%    4.85MB/s    0:00:02
+     9371648  55%    4.39MB/s    0:00:01
+    11468800  67%    3.58MB/s    0:00:01
+    15859712  93%    3.72MB/s    0:00:00
+    16987083 100%    3.75MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 16989325 bytes  received 42 bytes  3088975.82 bytes/sec
+total size is 16987083  speedup is 1.00
+[2014-05-25 21:49:39 CEST] Transferrer: Uploaded 50_creati..frame.mp4
+remote: merge git-annex 
+WORM-s19055363-m1398385037--Learning SketchUp 2013%49_creating-doors.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5013504  26%    4.68MB/s    0:00:02
+[2014-05-25 21:49:41 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   a39803a..8462dc1  git-annex -> synced/git-annex
+     9011200  47%    4.21MB/s    0:00:02
+    13041664  68%    4.05MB/s    0:00:01
+    16351232  85%    3.83MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   338767b..47c33b6  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 8462dc1c099c64ff94d5d35cb2f2efaff89b028e but expected a39803aef5ce739ae6a6472a7de156efac31bebc
+ ! a39803a..8462dc1  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    19055363 100%    3.97MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 19057840 bytes  received 42 bytes  2931981.85 bytes/sec
+total size is 19055363  speedup is 1.00
+[2014-05-25 21:49:46 CEST] Pusher: Syncing with diskstation 
+[2014-05-25 21:49:46 CEST] Transferrer: Uploaded 49_creati..doors.mp4
+
+WORM-s11184398-m1398385463--Learning SketchUp 2013%48_review-of-components-and-nested-groups.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3375104  30%    2.72MB/s    0:00:02
+     5603328  50%    2.38MB/s    0:00:02
+remote: merge git-annex      9371648  83%    2.75MB/s    0:00:00
+    11184398 100%    2.89MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 11185939 bytes  received 42 bytes  2033814.73 bytes/sec
+total size is 11184398  speedup is 1.00
+[2014-05-25 21:49:52 CEST] RemoteControl: Syncing with diskstation 
+[2014-05-25 21:49:52 CEST] Transferrer: Uploaded 48_review..roups.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   8462dc1..877c07a  git-annex -> synced/git-annex
+
+WORM-s19612237-m1398385719--Learning SketchUp 2013%47_adding-railing.mp4
+       32768   0%    0.00kB/s    0:00:00
+     3997696  20%    3.75MB/s    0:00:04
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   47c33b6..bb182f5  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 877c07ad78a25ddf859ac96049ec938fa9b0b5f3 but expected 8462dc1c099c64ff94d5d35cb2f2efaff89b028e
+ ! 8462dc1..877c07a  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     8257536  42%    3.88MB/s    0:00:02
+    12845056  65%    4.02MB/s    0:00:01
+    17039360  86%    4.00MB/s    0:00:00
+[2014-05-25 21:49:57 CEST] Pusher: Syncing with diskstation 
+    19612237 100%    3.99MB/s    0:00:04 (xfer#1, to-check=0/1)
+
+sent 19614782 bytes  received 42 bytes  3017665.23 bytes/sec
+total size is 19612237  speedup is 1.00
+[2014-05-25 21:49:58 CEST] Transferrer: Uploaded 47_adding..iling.mp4
+
+WORM-s23427266-m1398386041--Learning SketchUp 2013%46_adding-spindles-with-move-and-copy.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4128768  17%    3.80MB/s    0:00:04
+remote: merge git-annex      7176192  30%    3.33MB/s    0:00:04
+    11304960  48%    3.53MB/s    0:00:03
+[2014-05-25 21:50:02 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   877c07a..873eda1  git-annex -> synced/git-annex
+    15138816  64%    3.53MB/s    0:00:02
+    18644992  79%    3.42MB/s    0:00:01
+    21135360  90%    3.29MB/s    0:00:00
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   bb182f5..470a1af  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 873eda1fd0b52f509bbd03a02ec5a3d6d8085488 but expected 877c07ad78a25ddf859ac96049ec938fa9b0b5f3
+ ! 877c07a..873eda1  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+    23427266 100%    3.17MB/s    0:00:07 (xfer#1, to-check=0/1)
+
+sent 23430295 bytes  received 42 bytes  2756510.24 bytes/sec
+total size is 23427266  speedup is 1.00
+[2014-05-25 21:50:06 CEST] Transferrer: Uploaded 46_adding..-copy.mp4
+
+WORM-s28584390-m1398385775--Learning SketchUp 2013%45_making-a-unique-bottom-step.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:50:07 CEST] Pusher: Syncing with diskstation 
+     5472256  19%    4.96MB/s    0:00:04
+     9895936  34%    4.53MB/s    0:00:04
+    14221312  49%    4.40MB/s    0:00:03
+remote: merge git-annex     18055168  63%    4.21MB/s    0:00:02
+    22609920  79%    4.05MB/s    0:00:01
+[2014-05-25 21:50:12 CEST] RemoteControl: Syncing with diskstation 
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   873eda1..274fd99  git-annex -> synced/git-annex
+    26279936  91%    3.88MB/s    0:00:00
+    28584390 100%    4.06MB/s    0:00:06 (xfer#1, to-check=0/1)
+
+sent 28588044 bytes  received 42 bytes  3363304.24 bytes/sec
+total size is 28584390  speedup is 1.00
+[2014-05-25 21:50:14 CEST] Transferrer: Uploaded 45_making..-step.mp4
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   470a1af..989e8b5  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at 274fd99803c01b7911e45dcb050480eb4bfe2a82 but expected 873eda1fd0b52f509bbd03a02ec5a3d6d8085488
+ ! 873eda1..274fd99  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+
+WORM-s24162552-m1398385100--Learning SketchUp 2013%44_adding-riser-detail.mp4
+       32768   0%    0.00kB/s    0:00:00
+     5341184  22%    5.06MB/s    0:00:03
+[2014-05-25 21:50:17 CEST] Pusher: Syncing with diskstation 
+     9240576  38%    4.38MB/s    0:00:03
+    13959168  57%    4.38MB/s    0:00:02
+    18153472  75%    4.28MB/s    0:00:01
+remote: merge git-annex     22347776  92%    4.00MB/s    0:00:00
+    24162552 100%    4.15MB/s    0:00:05 (xfer#1, to-check=0/1)
+[2014-05-25 21:50:22 CEST] RemoteControl: Syncing with diskstation 
+
+sent 24165658 bytes  received 42 bytes  3222093.33 bytes/sec
+total size is 24162552  speedup is 1.00
+[2014-05-25 21:50:22 CEST] Transferrer: Uploaded 44_adding..etail.mp4
+(merging synced/git-annex into git-annex...)        
+remote: (Recording state in git...)        
+remote: ok        
+remote: (Recording state in git...)        
+To joern@annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   274fd99..baa9cda  git-annex -> synced/git-annex
+
+WORM-s14814183-m1398385868--Learning SketchUp 2013%43_creating-the-staircase.mp4
+       32768   0%    0.00kB/s    0:00:00
+     4947968  33%    4.69MB/s    0:00:02
+From annex.diskstation.local:/volume1/homes/joern/Annex.movies
+   989e8b5..c15470f  git-annex  -> diskstation/git-annex
+error: Ref refs/remotes/diskstation/synced/git-annex is at baa9cdae739f6bc1f928d9abe82c0f83b6645093 but expected 274fd99803c01b7911e45dcb050480eb4bfe2a82
+ ! 274fd99..baa9cda  synced/git-annex -> diskstation/synced/git-annex  (unable to update local ref)
+     9011200  60%    4.25MB/s    0:00:01
+    13729792  92%    4.31MB/s    0:00:00
+    14814183 100%    4.30MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 14816152 bytes  received 42 bytes  2693853.45 bytes/sec
+total size is 14814183  speedup is 1.00
+[2014-05-25 21:50:27 CEST] Transferrer: Uploaded 43_creati..rcase.mp4
+
+WORM-s14506973-m1398386318--Learning SketchUp 2013%42_why-we-use-groups-and-components.mp4
+       32768   0%    0.00kB/s    0:00:00
+[2014-05-25 21:50:27 CEST] Pusher: Syncing with diskstation 
+     5341184  36%    5.04MB/s    0:00:01
+     9633792  66%    4.55MB/s    0:00:01
+    13926400  95%    4.37MB/s    0:00:00
+    14506973 100%    4.38MB/s    0:00:03 (xfer#1, to-check=0/1)
+
+sent 14508912 bytes  received 42 bytes  3224212.00 bytes/sec
+total size is 14506973  speedup is 1.00
+[2014-05-25 21:50:31 CEST] Transferrer: Uploaded 42_why-we..nents.mp4
+
+WORM-s11494983-m1398385388--Learning SketchUp 2013%41_copy-and-paste-in-place.mp4
+       32768   0%    0.00kB/s    0:00:00
+remote: merge git-annex      5210112  45%    4.82MB/s    0:00:01
+     9404416  81%    4.37MB/s    0:00:00
+    11494983 100%    4.21MB/s    0:00:02 (xfer#1, to-check=0/1)
+
+sent 11496545 bytes  received 42 bytes  3284739.14 bytes/sec
+total size is 11494983  speedup is 1.00
+[2014-05-25 21:50:34 CEST] RemoteControl: Syncing with diskstation 
+[2014-05-25 21:50:34 CEST] Transferrer: Uploaded 41_copy-a..place.mp4
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/gpg-agent/comment_1_86860841aaa38541968693ec02f6a506._comment b/doc/bugs/gpg-agent/comment_1_86860841aaa38541968693ec02f6a506._comment
new file mode 100644
index 0000000000..382b3a8b77
--- /dev/null
+++ b/doc/bugs/gpg-agent/comment_1_86860841aaa38541968693ec02f6a506._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 1"
+ date="2014-05-30T19:15:33Z"
+ content="""
+What I see in the log is git-annex is syncing files to/from the remote \"diskstation\". This remote is not encrypted at all, so git-annex is not using gpg. There is no mention of gpg in the log at all.
+
+So, I don't see any indication that whatever is causing too many gpg-agent processes to be spawned is git-annex. Can you share more information that would point toward git-annex being the cause of this problem?
+"""]]
diff --git a/doc/bugs/gpg-agent/comment_2_de6f9b8f20e44e93759b9bf0db695def._comment b/doc/bugs/gpg-agent/comment_2_de6f9b8f20e44e93759b9bf0db695def._comment
new file mode 100644
index 0000000000..8158500ae2
--- /dev/null
+++ b/doc/bugs/gpg-agent/comment_2_de6f9b8f20e44e93759b9bf0db695def._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~r0lf"
+ nickname="Rolf Leggewie"
+ avatar="http://cdn.libravatar.org/avatar/aa82122557e706df7ba83bd1983eb79ef1ba2e51350217850176d4f9a1bb2bc0"
+ subject="comment 2"
+ date="2016-12-24T17:56:13Z"
+ content="""
+time to trim the list of open bugs and close this ticket as unreproducible?
+"""]]
diff --git a/doc/bugs/gpg_goes_to_100__37___cpu_on_bad_input_data.mdwn b/doc/bugs/gpg_goes_to_100__37___cpu_on_bad_input_data.mdwn
new file mode 100644
index 0000000000..5f36a7cd0d
--- /dev/null
+++ b/doc/bugs/gpg_goes_to_100__37___cpu_on_bad_input_data.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+Bad input data given to gpg will make it lock.
+
+### What steps will reproduce the problem?
+Trying to download gpg encrypted data from remote with bad/incorrect data
+
+### What version of git-annex are you using? On what operating system?
+4.20130501-gd9e288b, on ubuntu 13.04
+
+### Please provide any additional information below.
+Transcript
+http://paste.ubuntu.com/5626517/
+
+Note: The problem is most likely caused by bad data from either the nntp hooks program, or the nntp server itself.
+
+I also have one file with bad data that consistently is NOT a problem for gpg to handle(lines 24-25 of log).
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/gpg_goes_to_100__37___cpu_on_bad_input_data/comment_1_889218fb7c0115b03d9bad0c07296097._comment b/doc/bugs/gpg_goes_to_100__37___cpu_on_bad_input_data/comment_1_889218fb7c0115b03d9bad0c07296097._comment
new file mode 100644
index 0000000000..43211bdd89
--- /dev/null
+++ b/doc/bugs/gpg_goes_to_100__37___cpu_on_bad_input_data/comment_1_889218fb7c0115b03d9bad0c07296097._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-06T17:09:58Z"
+ content="""
+What version of gnupg do you have installed?
+
+<pre>
+gpg: block_filter 0x946320: read error (size=12864,a->size=12864)
+gpg: [don't know]: invalid packet (ctb=68)
+gpg: [don't know]: invalid packet (ctb=21)
+gpg: mdc_packet with invalid encoding
+gpg: decryption failed: invalid packet
+gpg: [don't know]: invalid packet (ctb=00)
+gpg: block_filter: pending bytes!
+</pre>
+
+I don't see how git-annex can possibly guard against gpg behaving this way when given bad data. So the best thing to do would be to get a test case file that causes gpg to behave this way, and then I could file a bug on gpg and get it fixed to immediately exit.
+
+I tried to reproduce this by encrypting a 1 mb file with gpg. This yeilded a 1.1 mb file. I then truncated it back to 1 mb, and tried to decrypt it.
+
+[[!format sh \"\"\"
+joey@gnu:~>gpg --decrypt me2.gpg > x
+gpg: encrypted with 1 passphrase
+gpg: block_filter 0x9d6fda0: read error (size=15680,a->size=15680)
+gpg: Problem reading source (8570 bytes remaining)
+gpg: handle plaintext failed: file read error
+gpg: mdc_packet with invalid encoding
+gpg: decryption failed: invalid packet
+gpg: block_filter: pending bytes!
+zsh: exit 2     gpg --decrypt 
+\"\"\"]]
+
+gpg exited immediately on error, which is what it should do. So it doesn't seem likely I can guess at a test case file that causes gpg to behave this way. You will need to provide one for me to help.
+"""]]
diff --git a/doc/bugs/high_cpu_usage_in_cat-file_and_webapp.mdwn b/doc/bugs/high_cpu_usage_in_cat-file_and_webapp.mdwn
new file mode 100644
index 0000000000..d2dd2bbce9
--- /dev/null
+++ b/doc/bugs/high_cpu_usage_in_cat-file_and_webapp.mdwn
@@ -0,0 +1,314 @@
+### Please describe the problem.
+
+I've been running git-annex in the background for a few weeks now (my laptop is at home, occasionally gets suspended, but not for the past few days), and this morning (around 9:30am), I noticed I could hear its fan. Looking at CPU usage in htop, "git-annex webapp" was using ~18% and "git --git-dir=/home/flowblok/annex/.git --work-tree=/home/flowblok/annex -c core.bare=false cat-file --batch" was using ~46%.
+
+The repository is in direct mode.
+It has one remote which it copies to over the network with "annex-rsync-upload-options = --bwlimit 10".
+The last fsck ran at 4am, and finished (with one failure, which I can easily recover from) by 4:30am (I guess I should find out why it didn't notify me in any way).
+
+### What steps will reproduce the problem?
+
+Not a clue!
+Though hopefully I've given enough information below for you to figure out what went wrong: let me know if you need anything else.
+
+### What version of git-annex are you using? On what operating system?
+
+Debian Jessie
+
+$ uname -a
+Linux moash 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux
+
+$ git-annex version
+git-annex version: 5.20141125
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+
+### Please provide any additional information below.
+
+[[!format sh """
+# strace -p $PIDOF_GIT_CATFILE
+open("/home/flowblok/annex/.git/objects/04/13fe78e4f9b37348b5fd03cbe5eabdbcaec068", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=683, ...}) = 0
+mmap(NULL, 683, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 683)             = 0
+open("/home/flowblok/annex/.git/objects/c0/4c0a1d5b43f82c50cf095e42d28d74f0cfc494", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=132, ...}) = 0
+mmap(NULL, 132, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 132)             = 0
+brk(0x1b5b000)                          = 0x1b5b000
+open("/home/flowblok/annex/.git/objects/25/21eb645b1fcac7b6b55551114fe2d69e095896", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=70, ...}) = 0
+mmap(NULL, 70, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 70)              = 0
+write(1, "2521eb645b1fcac7b6b55551114fe2d6"..., 49) = 49
+open("/home/flowblok/annex/.git/objects/25/21eb645b1fcac7b6b55551114fe2d69e095896", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=70, ...}) = 0
+mmap(NULL, 70, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 70)              = 0
+open("/home/flowblok/annex/.git/objects/25/21eb645b1fcac7b6b55551114fe2d69e095896", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=70, ...}) = 0
+mmap(NULL, 70, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+write(1, "1435997202.486434s 0 5c33e13f-ed"..., 58) = 58
+munmap(0x7f9ead5a0000, 70)              = 0
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:eec/e95/SHA"..., 4096) = 116
+lstat("/home/flowblok/annex/.git/refs/heads/git-annex", {st_mode=S_IFREG|0600, st_size=41, ...}) = 0
+open("/home/flowblok/annex/.git/refs/heads/git-annex", O_RDONLY) = 3
+read(3, "f9d2dc8d54151d01a27c7989a1fc7983"..., 255) = 41
+read(3, "", 214)                        = 0
+close(3)                                = 0
+lstat("/home/flowblok/annex/.git/refs/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/tags/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/heads/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/remotes/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/remotes/refs/heads/git-annex/HEAD", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+open("/home/flowblok/annex/.git/objects/f9/d2dc8d54151d01a27c7989a1fc798320034a69", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=207, ...}) = 0
+mmap(NULL, 207, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 207)             = 0
+open("/home/flowblok/annex/.git/objects/65/dd2889161d7002f1d5f94587ab9bd0746d6f61", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=98827, ...}) = 0
+mmap(NULL, 98827, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ea4c03000
+close(3)                                = 0
+brk(0x1b81000)                          = 0x1b81000
+munmap(0x7f9ea4c03000, 98827)           = 0
+open("/home/flowblok/annex/.git/objects/d7/bc8b27aad64c59effa77eae026778582761fae", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=550, ...}) = 0
+mmap(NULL, 550, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 550)             = 0
+open("/home/flowblok/annex/.git/objects/d8/00f4d59828022b9ee556b6f3758832da6bfb71", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=131, ...}) = 0
+mmap(NULL, 131, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 131)             = 0
+brk(0x1b5b000)                          = 0x1b5b000
+open("/home/flowblok/annex/.git/objects/ac/9ee326d36283143f9b3b38687870df6a888938", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=71, ...}) = 0
+mmap(NULL, 71, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 71)              = 0
+write(1, "ac9ee326d36283143f9b3b38687870df"..., 49) = 49
+open("/home/flowblok/annex/.git/objects/ac/9ee326d36283143f9b3b38687870df6a888938", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=71, ...}) = 0
+mmap(NULL, 71, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 71)              = 0
+open("/home/flowblok/annex/.git/objects/ac/9ee326d36283143f9b3b38687870df6a888938", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=71, ...}) = 0
+mmap(NULL, 71, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+write(1, "1435997292.091244s 0 5c33e13f-ed"..., 58) = 58
+munmap(0x7f9ead5a0000, 71)              = 0
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:c54/719/SHA"..., 4096) = 116
+lstat("/home/flowblok/annex/.git/refs/heads/git-annex", {st_mode=S_IFREG|0600, st_size=41, ...}) = 0
+open("/home/flowblok/annex/.git/refs/heads/git-annex", O_RDONLY) = 3
+read(3, "f9d2dc8d54151d01a27c7989a1fc7983"..., 255) = 41
+read(3, "", 214)                        = 0
+close(3)                                = 0
+lstat("/home/flowblok/annex/.git/refs/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/tags/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/heads/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/remotes/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/remotes/refs/heads/git-annex/HEAD", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+open("/home/flowblok/annex/.git/objects/f9/d2dc8d54151d01a27c7989a1fc798320034a69", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=207, ...}) = 0
+mmap(NULL, 207, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 207)             = 0
+open("/home/flowblok/annex/.git/objects/65/dd2889161d7002f1d5f94587ab9bd0746d6f61", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=98827, ...}) = 0
+mmap(NULL, 98827, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ea4c03000
+close(3)                                = 0
+brk(0x1b81000)                          = 0x1b81000
+munmap(0x7f9ea4c03000, 98827)           = 0
+open("/home/flowblok/annex/.git/objects/04/13fe78e4f9b37348b5fd03cbe5eabdbcaec068", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=683, ...}) = 0
+mmap(NULL, 683, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 683)             = 0
+open("/home/flowblok/annex/.git/objects/c0/4c0a1d5b43f82c50cf095e42d28d74f0cfc494", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=132, ...}) = 0
+mmap(NULL, 132, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 132)             = 0
+brk(0x1b5b000)                          = 0x1b5b000
+open("/home/flowblok/annex/.git/objects/25/21eb645b1fcac7b6b55551114fe2d69e095896", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=70, ...}) = 0
+mmap(NULL, 70, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 70)              = 0
+write(1, "2521eb645b1fcac7b6b55551114fe2d6"..., 49) = 49
+open("/home/flowblok/annex/.git/objects/25/21eb645b1fcac7b6b55551114fe2d69e095896", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=70, ...}) = 0
+mmap(NULL, 70, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 70)              = 0
+open("/home/flowblok/annex/.git/objects/25/21eb645b1fcac7b6b55551114fe2d69e095896", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=70, ...}) = 0
+mmap(NULL, 70, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+write(1, "1435997202.486434s 0 5c33e13f-ed"..., 58) = 58
+munmap(0x7f9ead5a0000, 70)              = 0
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:eec/e95/SHA"..., 4096) = 116
+lstat("/home/flowblok/annex/.git/refs/heads/git-annex", {st_mode=S_IFREG|0600, st_size=41, ...}) = 0
+open("/home/flowblok/annex/.git/refs/heads/git-annex", O_RDONLY) = 3
+read(3, "f9d2dc8d54151d01a27c7989a1fc7983"..., 255) = 41
+read(3, "", 214)                        = 0
+close(3)                                = 0
+lstat("/home/flowblok/annex/.git/refs/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/tags/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/heads/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/remotes/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/remotes/refs/heads/git-annex/HEAD", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+open("/home/flowblok/annex/.git/objects/f9/d2dc8d54151d01a27c7989a1fc798320034a69", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=207, ...}) = 0
+mmap(NULL, 207, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 207)             = 0
+open("/home/flowblok/annex/.git/objects/65/dd2889161d7002f1d5f94587ab9bd0746d6f61", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=98827, ...}) = 0
+mmap(NULL, 98827, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ea4c03000
+close(3)                                = 0
+brk(0x1b81000)                          = 0x1b81000
+munmap(0x7f9ea4c03000, 98827)           = 0
+open("/home/flowblok/annex/.git/objects/d7/bc8b27aad64c59effa77eae026778582761fae", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=550, ...}) = 0
+mmap(NULL, 550, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 550)             = 0
+open("/home/flowblok/annex/.git/objects/d8/00f4d59828022b9ee556b6f3758832da6bfb71", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=131, ...}) = 0
+mmap(NULL, 131, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 131)             = 0
+brk(0x1b5b000)                          = 0x1b5b000
+open("/home/flowblok/annex/.git/objects/ac/9ee326d36283143f9b3b38687870df6a888938", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=71, ...}) = 0
+mmap(NULL, 71, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 71)              = 0
+write(1, "ac9ee326d36283143f9b3b38687870df"..., 49) = 49
+open("/home/flowblok/annex/.git/objects/ac/9ee326d36283143f9b3b38687870df6a888938", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=71, ...}) = 0
+mmap(NULL, 71, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 71)              = 0
+open("/home/flowblok/annex/.git/objects/ac/9ee326d36283143f9b3b38687870df6a888938", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=71, ...}) = 0
+mmap(NULL, 71, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+write(1, "1435997292.091244s 0 5c33e13f-ed"..., 58) = 58
+munmap(0x7f9ead5a0000, 71)              = 0
+write(1, "\n", 1)                       = 1
+read(0, "refs/heads/git-annex:c54/719/SHA"..., 4096) = 116
+lstat("/home/flowblok/annex/.git/refs/heads/git-annex", {st_mode=S_IFREG|0600, st_size=41, ...}) = 0
+open("/home/flowblok/annex/.git/refs/heads/git-annex", O_RDONLY) = 3
+read(3, "f9d2dc8d54151d01a27c7989a1fc7983"..., 255) = 41
+read(3, "", 214)                        = 0
+close(3)                                = 0
+lstat("/home/flowblok/annex/.git/refs/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/tags/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/heads/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/remotes/refs/heads/git-annex", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+lstat("/home/flowblok/annex/.git/refs/remotes/refs/heads/git-annex/HEAD", 0x7ffc82e9e580) = -1 ENOENT (No such file or directory)
+stat("/home/flowblok/annex/.git/packed-refs", {st_mode=S_IFREG|0600, st_size=1049, ...}) = 0
+open("/home/flowblok/annex/.git/objects/f9/d2dc8d54151d01a27c7989a1fc798320034a69", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=207, ...}) = 0
+mmap(NULL, 207, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ead5a0000
+close(3)                                = 0
+munmap(0x7f9ead5a0000, 207)             = 0
+open("/home/flowblok/annex/.git/objects/65/dd2889161d7002f1d5f94587ab9bd0746d6f61", O_RDONLY|O_NOATIME) = 3
+fstat(3, {st_mode=S_IFREG|0400, st_size=98827, ...}) = 0
+mmap(NULL, 98827, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9ea4c03000
+close(3)                                = 0
+brk(0x1b81000)                          = 0x1b81000
+munmap(0x7f9ea4c03000, 98827)           = 0
+# (truncated, since it just repeats over and over for a total of 613759 lines)
+
+# strace -p $PIDOF_GITANNEX_WEBAPP
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+futex(0x417c1dc, FUTEX_WAIT_PRIVATE, 65, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
+rt_sigreturn()                          = 202
+# (ands lots more of the same)
+"""]]
diff --git a/doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_1_7fee933eb54272a0447851279d31825b._comment b/doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_1_7fee933eb54272a0447851279d31825b._comment
new file mode 100644
index 0000000000..d926d72d25
--- /dev/null
+++ b/doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_1_7fee933eb54272a0447851279d31825b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-16T17:36:07Z"
+ content="""
+The most likely reason for the assistant to use CPU like this is when it's running
+the expensive transfer scan to find files that need to be copied from/to
+remotes. That has to consider every file in your repository's work
+tree, and uses git cat-file to extract information from the git
+repository to see where the file is currently located. This is normally
+only done when the assistant starts up.
+
+.git/annex/daemon.log will show when the expensive transfer scan starts and
+finishes. Look for "starting scan" and "finished scan" lines. Or, open the
+webapp and look to see what activities it says it's performing.
+"""]]
diff --git a/doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_2_f26b8846e1651c507d259b9891d26136._comment b/doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_2_f26b8846e1651c507d259b9891d26136._comment
new file mode 100644
index 0000000000..f650709e58
--- /dev/null
+++ b/doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_2_f26b8846e1651c507d259b9891d26136._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ subject="Still seeing this"
+ date="2016-06-08T18:03:51Z"
+ content="""
+This is on jessie with 5.20151208-1~bpo8.
+
+git-annex webapp and git --git-dir=.git --work-tree=. --literal-pathspecs -c core.bare=false cat-file --batch are using considerable CPU time.  The strace appears to be this:
+
+[[!format text \"\"\"
+[pid 29222] open(\".git/annex/journal/1e9_9e8_SHA256E-s109439--4df4c11870535f09bea79e309ac1d3de0e3ed5054900257c212277c0dc84290e.odt.log\", O_RDONLY|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
+[pid 29222] write(15, \"refs/heads/git-annex:1e9/9e8/SHA\"..., 119) = 119
+[pid 29222] write(7, \"\1\0\0\0\0\0\0\0\", 8) = 8
+[pid 29161] read(7, \"\1\0\0\0\0\0\0\0\", 8) = 8
+[pid 29222] read(18, \"fb6b750de51cf247dae90279745c2478\"..., 8096) = 341
+\"\"\"]]
+
+What's more, the webapp shows that it's only synced to one of the two remotes, despite both being available.  The log has nothing about kicking off a sync run.
+
+I also wonder if this is and [[bugs/Assistant_having_a_child_git_cat-file_--batch_do_the_same_thing_over_and_over_and_using_a_lot_of_memory]] are the same issue.
+"""]]
diff --git a/doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_3_89dbc16c9c1b74ccb3f46d3c558e0c8d._comment b/doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_3_89dbc16c9c1b74ccb3f46d3c558e0c8d._comment
new file mode 100644
index 0000000000..46f8f4cbe1
--- /dev/null
+++ b/doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_3_89dbc16c9c1b74ccb3f46d3c558e0c8d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ subject="Seeing this everywhere"
+ date="2016-06-10T16:59:46Z"
+ content="""
+I am now seeing this pattern on every machine I use.
+"""]]
diff --git a/doc/bugs/how_to_copy_tp_multiple_remotes_simultaneously__63__.mdwn b/doc/bugs/how_to_copy_tp_multiple_remotes_simultaneously__63__.mdwn
new file mode 100644
index 0000000000..555a8bce2d
--- /dev/null
+++ b/doc/bugs/how_to_copy_tp_multiple_remotes_simultaneously__63__.mdwn
@@ -0,0 +1,43 @@
+### Please describe the problem.
+
+I would like to make multiple copies of precious data and I would like these copies to run simultaneously to minimise the elapsed time taken.  Ideally, I would like to specify multiple `--to` options to `git annex copy`.  I have tried running multiple processes simultaneously but these start to fail with lock contention on `.git/config`.
+
+### What steps will reproduce the problem?
+
+Running four simultaneous `git annex copy --to=` commands.
+
+### What version of git-annex are you using? On what operating system?
+
+OS is debian jessie, using `git-annex-standalone` from NeuroDebian.
+
+```
+git-annex version: 6.20160923+gitgd1dabb3-1~ndall+1
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotif
+y XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi                                                         
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_51
+2 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL         
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 6
+supported repository versions: 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux x86_64
+```
+
+### Please provide any additional information below.
+
+What I have is a python script and its output which I can't imagine is that helpful, but if you want it I'll upload it.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Usng it regularly and like it - many thanks.  This is a wishlist item, not a bug, as far as I'm concerned.
+
+
+> [[done]], no response to my question... --[[Joey]] 
diff --git a/doc/bugs/how_to_copy_tp_multiple_remotes_simultaneously__63__/comment_1_311a8a43d360074abd522fff14bfcb45._comment b/doc/bugs/how_to_copy_tp_multiple_remotes_simultaneously__63__/comment_1_311a8a43d360074abd522fff14bfcb45._comment
new file mode 100644
index 0000000000..9661ac5f1f
--- /dev/null
+++ b/doc/bugs/how_to_copy_tp_multiple_remotes_simultaneously__63__/comment_1_311a8a43d360074abd522fff14bfcb45._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-10-26T18:02:43Z"
+ content="""
+You need to provide more detail about "lock contention on `.git/config`".
+Ideally an actual error message.
+
+Normally it's perfectly fine to run multiple `git annex copy`, or any
+other git-annex command for that matter.
+
+And the only thing I know of that locks .git/config is when the
+configuration is being changed, which doesn't normally happen when
+copying to a remote, unless perhaps this remote has never been used before.
+"""]]
diff --git a/doc/bugs/http_remotes_ignore_annex.web-options_--netrc.mdwn b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc.mdwn
new file mode 100644
index 0000000000..389a95bd94
--- /dev/null
+++ b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc.mdwn
@@ -0,0 +1,294 @@
+### Please describe the problem.
+
+The documentation for `git config annex.web-options` says that I should be able to use it to set up HTTP credentials in a ~/.netrc file, but it doesn't work.
+
+I have been given some repos that are password-protected, I want to be able to download them non-interactively in a CI system. I won't sit there typing in the password 500 times for 500 files, and ideally I don't want to even type it once.
+
+`git` reads `~/.netrc` if it exists, and does so consistently enough that http://droneci.com/ has built that in as the default way it passes CI credentials to workers. It would be really great if `git-annex` did the same, and did it instead of spawning `curl`. When using an ssh remote, git and git-annex already share the same ssh credentials; it would be awesome if the same could be transparently true for http remotes as well :)
+
+
+### What steps will reproduce the problem?
+
+1. Set up an HTTP server following https://git-annex.branchable.com/tips/setup_a_public_repository_on_a_web_site/, but password-protect it.
+
+    I set up my server on Arch, but I tested the client from both Arch and Ubuntu. Here's the server set up; it should adapt to Debian or Fedora easily enough:
+
+    1. `sudo pacman -S --noconfirm apache`
+    2. `echo 'Include conf/extra/git-annex.conf' | sudo tee -a /etc/httpd/conf/httpd.conf`
+    3. `sudo mkdir -p /srv/http/annex && sudo chown -R http:http /srv/http/annex`
+    4.  ```
+        cat <<EOF | sudo tee /etc/httpd/conf/extra/git-annex.conf
+        DocumentRoot "/srv/http/annex"
+        <Directory "/srv/http/annex">
+                AllowOverride All
+                Options FollowSymlinks Indexes
+                Require all granted
+        </Directory>
+        ```
+    5. Set up a repo:
+
+        1. Switch to `http`: `sudo -u http bash`; `cd /srv/http/annex`
+        2. `git config user.name httpd; git config user.email httpd@httpd`
+        3. `git init; git annex init`
+        4. `git config core.sharedrepository world; git config receive.denyCurrentBranch updateInstead`
+        5. `mv .git/hooks/post-update.sample .git/hooks/post-update`
+        6. `echo Hello > README.md && git add README.md && git commit -m "README.md"`
+        7. `dd if=/dev/urandom of=large.bin bs=1M count=1 && git annex add large.bin && git add large.bin && git commit -m "large.bin"`
+    5. (optional): verify the repo is functional:
+
+        1. `git clone http://localhost/.git annex-test; cd annex-test`
+        2. `git config annex.security.allowed-ip-addresses all`
+        3. `sha256sum large.bin` should fail
+        4. `git annex get`
+        3. `sha256sum large.bin` should succeed, and match the value shown in the symlink in `ls -l large.bin`
+    6. Password protect the repo
+
+        While still in `/srv/http/annex`:
+
+        1. ```
+            cat <<EOF | tee .htaccess
+            AuthType Basic
+            AuthName gitannex
+            AuthUserFile /srv/http/annex/.htpasswd
+            Require valid-user
+            ```
+        2. `htpasswd -bc .htpasswd user4 password`
+
+2. Download the password-protected repo
+
+    0. If the test server is on the same machine: `git config --global annex.security.allowed-ip-addresses all`
+
+    1. Download the repo without any password helper: 🫤🫤🫤
+        1. `git clone http://localhost/.git annex-test; cd annex-test`; this will prompt for the password set above, e.g.
+
+            ```
+            $ git clone http://localhost/.git annex-test
+            Cloning into 'annex-test'...
+            Username for 'http://localhost': user4
+            Password for 'http://user4@localhost':
+            ```
+        2. `git annex get`; this will prompt for the password **twice**: once for the implicit `git annex init` (that needs to read the remote `.git/config`) and once for downloading large.bin.
+
+        Running `pstree` while the prompts are waiting, or using `git config annex.debug true`, reveals that the prompts are coming from [`git credential fill`](https://git-scm.com/docs/git-credential).
+    8. Drop the annoying redundant password prompts using [git-credential-store(1)](https://git-scm.com/docs/git-credential-store): ✔️✔️✔️
+
+        1. `cd $(mktemp -d)`
+        2. `git config --global credential.helper store`
+        3. `git clone http://localhost/.git annex-test; cd annex-test`; this will prompt for the password
+        4. `git annex get`; but this will not prompt for any passwords
+
+        This works. So that's awesome, I can use `credential.helper store` to make my passworded downloads non-interactive by filling in `~/.git-credentials`, which, for the record, has one credential per line in this format:
+
+        ```
+        $ cat ~/.git-credentials
+        http://user4:password@localhost
+        ```
+
+        or if a non-standard port is involved:
+
+        ```
+        $ cat ~/.git-credentials
+        http://user4:password@localhost%3a8080
+        ```
+
+        5. (Undo: `git config --global --unset credential.helper` to avoid contaminating the next test)
+
+    9. Attempt to drop the redundant password prompts using `annex.web-options`: ❌❌❌
+
+        1. `cd $(mktemp -d)`
+        2. `git config --global annex.web-options --netrc`
+        3. Set up a `~/.netrc`:
+
+            ```
+            cat <<EOF | tee -a ~/.netrc
+            machine localhost
+            login user4
+            password password localhost
+            ```
+        4. (optional) verify it works as expected with directly through curl:
+
+            ```
+            $ curl --no-progress-meter -f -o /dev/null http://localhost/.git; echo $?         # fails
+            curl: (22) The requested URL returned error: 401
+            22
+            $ curl --netrc --no-progress-meter -f -o /dev/null http://localhost/.git; echo $? # works
+            0
+            ```
+       5. `git clone http://localhost/.git annex-test; cd annex-test`; this will **not** prompt for a password because `git` picks up `~/.netrc` automatically.
+       6. `git annex get`; this **will** prompt for passwords, n+1 times in fact for n=the number of annexed files
+
+I don't understand why this isn't working. The docs say
+
+> Setting this option makes git-annex use curl, but only when annex.security.allowed-ip-addresses is configured in a specific way.
+
+and I set `allowed-ip-addressess` in the specific way, so why is this no bueno?
+
+I've searched the wiki and all I've found is:
+
+* https://git-annex.branchable.com/news/security_fix_release/
+* https://git-annex.branchable.com/devblog/day_494__url_download_changes/
+* https://git-annex.branchable.com/forum/Use_addurl_with_a_file_on_an_HPC_cluster/
+
+From these, I understand I need to `git config --global annex.security.allowed-ip-addresses all`, which I did, but otherwise my best guess is that `web-options` only works when [using the web as as _special remote_](https://git-annex.branchable.com/tips/using_the_web_as_a_special_remote/) with `addurl`. But here I'm using the web as a _regular remote_, something which [git-annex has support for](https://git-annex.branchable.com/tips/setup_a_public_repository_on_a_web_site/). But seemingly this corner case isn't working.
+
+I can work around it by rewriting the contents of `~/.netrc` into `~/.git-credentials` and setting `git config --global credential.helper store`, but I don't want to duplicate the credentials every time I'm in this situation.
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex 10.20220504-g4e4c44ed8 on ArchLinux, and git-annex 8.20210223 on Ubuntu 22.04.
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+[kousu@nigiri tmp.ztnHTYA3ZC]$ cd $(mktemp -d)
+[kousu@nigiri tmp.H5EkrNMUPc]$ git config --global annex.security.allowed-ip-addresses all
+[kousu@nigiri tmp.H5EkrNMUPc]$ git config --global annex.web-options --netrc
+[kousu@nigiri tmp.H5EkrNMUPc]$ cat <<EOF | tee ~/.netrc
+machine localhost
+login user4
+password password
+EOF
+machine localhost
+login user4
+password password
+[kousu@nigiri tmp.H5EkrNMUPc]$
+[kousu@nigiri tmp.H5EkrNMUPc]$ # demonstrate that curl respects --netrc and behaves as expected:
+[kousu@nigiri tmp.H5EkrNMUPc]$ curl -v -o /dev/null -f --no-progress-meter http://localhost:80
+*   Trying 127.0.0.1:80...
+* Connected to localhost (127.0.0.1) port 80 (#0)
+> GET / HTTP/1.1
+> Host: localhost
+> User-Agent: curl/7.84.0
+> Accept: */*
+>
+* Mark bundle as not supporting multiuse
+< HTTP/1.1 401 Unauthorized
+< Date: Thu, 08 Sep 2022 00:49:44 GMT
+< Server: Apache/2.4.54 (Unix)
+< WWW-Authenticate: Basic realm="gitannex"
+< Vary: accept-language,accept-charset
+< Accept-Ranges: bytes
+< Transfer-Encoding: chunked
+< Content-Type: text/html; charset=utf-8
+< Content-Language: en
+* The requested URL returned error: 401
+* Closing connection 0
+curl: (22) The requested URL returned error: 401
+[kousu@nigiri tmp.H5EkrNMUPc]$ curl --netrc -v -o /dev/null -f --no-progress-meter http://localhost:80
+*   Trying 127.0.0.1:80...
+* Connected to localhost (127.0.0.1) port 80 (#0)
+* Server auth using Basic with user 'user4'
+> GET / HTTP/1.1
+> Host: localhost
+> Authorization: Basic dXNlcjQ6cGFzc3dvcmQ=
+> User-Agent: curl/7.84.0
+> Accept: */*
+>
+* Mark bundle as not supporting multiuse
+< HTTP/1.1 200 OK
+< Date: Thu, 08 Sep 2022 00:49:41 GMT
+< Server: Apache/2.4.54 (Unix)
+< Content-Length: 693
+< Content-Type: text/html;charset=ISO-8859-1
+<
+{ [693 bytes data]
+* Connection #0 to host localhost left intact
+[kousu@nigiri tmp.H5EkrNMUPc]$
+[kousu@nigiri tmp.H5EkrNMUPc]$ # demonstrate git respects .netrc:
+[kousu@nigiri tmp.H5EkrNMUPc]$ git clone http://localhost/.git annex-test
+Cloning into 'annex-test'...
+[kousu@nigiri tmp.H5EkrNMUPc]$ cd annex-test/
+[kousu@nigiri tmp.H5EkrNMUPc]$
+[kousu@nigiri tmp.H5EkrNMUPc]$ # demonstrate that git-annex *does not* respect .netrc
+[kousu@nigiri annex-test]$ git annex get
+Username for 'http://localhost': ^C
+[kousu@nigiri tmp.H5EkrNMUPc]$
+[kousu@nigiri tmp.H5EkrNMUPc]$
+[kousu@nigiri tmp.H5EkrNMUPc]$
+[kousu@nigiri annex-test]$ git annex version
+git-annex version: 10.20220504-g4e4c44ed8
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.11 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+[kousu@nigiri annex-test]$ cat /etc/os-release
+NAME="Arch Linux"
+PRETTY_NAME="Arch Linux"
+ID=arch
+BUILD_ID=rolling
+ANSI_COLOR="38;2;23;147;209"
+HOME_URL="https://archlinux.org/"
+DOCUMENTATION_URL="https://wiki.archlinux.org/"
+SUPPORT_URL="https://bbs.archlinux.org/"
+BUG_REPORT_URL="https://bugs.archlinux.org/"
+LOGO=archlinux-logo
+
+"""]]
+
+With the older git-annex, I set up a proxy so I could reuse the same server, which changed the port, but otherwise everything else is the same:
+
+[[!format sh """
+
+$ ssh -R 8080:localhost:80 joplin
+p115628@joplin:~$ cd $(mktemp -d)
+p115628@joplin:/tmp/tmp.glF9EdYhnR$ git config --global annex.security.allowed-ip-addresses all
+p115628@joplin:/tmp/tmp.glF9EdYhnR$ git config --global annex.web-options "--netrc"
+p115628@joplin:/tmp/tmp.glF9EdYhnR$ git clone http://localhost:8080/.git annex-test   # verify it's password protected
+Cloning into 'annex-test'...
+Username for 'http://localhost:8080': ^C
+p115628@joplin:/tmp/tmp.glF9EdYhnR$ cat <<EOF | tee ~/.netrc
+machine localhost
+login user4
+password password
+EOF
+machine localhost
+login user4
+password password
+p115628@joplin:/tmp/tmp.glF9EdYhnR$ git clone http://localhost:8080/.git annex-test  # verify the .netrc file works with git
+Cloning into 'annex-test'...
+p115628@joplin:/tmp/tmp.glF9EdYhnR$ cd annex-test/
+p115628@joplin:/tmp/tmp.glF9EdYhnR/annex-test$ git annex get                         # but does not work with git-annex
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+Username for 'http://localhost:8080': ^C
+p115628@joplin:/tmp/tmp.glF9EdYhnR/annex-test$
+p115628@joplin:/tmp/tmp.glF9EdYhnR/annex-test$
+p115628@joplin:/tmp/tmp.glF9EdYhnR/annex-test$
+p115628@joplin:/tmp/tmp.glF9EdYhnR/annex-test$ git annex version
+git-annex version: 8.20210223
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+p115628@joplin:/tmp/tmp.glF9EdYhnR/annex-test$ cat /etc/os-release
+PRETTY_NAME="Ubuntu 22.04.1 LTS"
+NAME="Ubuntu"
+VERSION_ID="22.04"
+VERSION="22.04.1 LTS (Jammy Jellyfish)"
+VERSION_CODENAME=jammy
+ID=ubuntu
+ID_LIKE=debian
+HOME_URL="https://www.ubuntu.com/"
+SUPPORT_URL="https://help.ubuntu.com/"
+BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
+PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
+UBUNTU_CODENAME=jammy
+
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sure! Lots! We use it to share a large open access dataset at https://github.com/spine-generic, and [I'm working on](https://github.com/neuropoly/gitea/pull/1) helping other researchers share their datasets on their own infrastructure using git-annex + gitea.
+
+[[done]]
diff --git a/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_1_314bf6c825c8b4cd49de210f20f6cde2._comment b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_1_314bf6c825c8b4cd49de210f20f6cde2._comment
new file mode 100644
index 0000000000..ff6af3c708
--- /dev/null
+++ b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_1_314bf6c825c8b4cd49de210f20f6cde2._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="git-credential-netrc"
+ date="2022-09-08T02:02:39Z"
+ content="""
+I've found a different workaround. `git` ships with an unmaintained(?) alternate netrc parser written in perl. You just need to install it:
+
+```
+[kousu@nigiri ~]$ sudo cp -p /usr/share/git/credential/netrc/git-credential-netrc.perl /usr/lib/git-core/git-credential-netrc  # install
+[sudo] password for kousu: 
+[kousu@nigiri ~]$ chmod 600 ~/.netrc                                                   # it's rightly picky about permissions
+[kousu@nigiri ~]$ git config --global credential.helper \"netrc -v\"
+[kousu@nigiri tmp.HBEKK9D4TS]$ cd $(mktemp -d)
+[kousu@nigiri tmp.oZpfrzbN2N]$ git clone http://localhost/.git annex-test              # this use ~/.netrc *directly*
+Cloning into 'annex-test'...
+[kousu@nigiri tmp.oZpfrzbN2N]$ cd annex-test/
+[kousu@nigiri annex-test]$ git annex get                                               # this uses ~/.netrc indirectly via git-credential
+get large.bin (from origin...) 
+using gpg for GPG operations
+Unable to read /home/kousu/.authinfo.gpg; skipping it
+Unable to read /home/kousu/.netrc.gpg; skipping it
+Unable to read /home/kousu/.authinfo; skipping it
+Opening /home/kousu/.netrc...
+ok
+(recording state in git...)
+```
+
+
+This seems to sidestep the problem! It's weird that `git clone` will read netrc directly, but `git credential fill` won't? Oh well.
+
+There's a [SO post](https://stackoverflow.com/a/31609584/2898673) about this script.
+
+
+I still think it would be good for the docs and the code to be made consistent: if `web-options` is supposed to invoke curl then make it invoke curl, or else not the corner cases where it won't invoke curl.
+
+Hope this helps someone out down the road.
+"""]]
diff --git a/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_2_599a66a1833000dc0e54a33511891b36._comment b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_2_599a66a1833000dc0e54a33511891b36._comment
new file mode 100644
index 0000000000..55807793f0
--- /dev/null
+++ b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_2_599a66a1833000dc0e54a33511891b36._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-09T19:19:44Z"
+ content="""
+Confirmed this behavior.
+
+It is due to withUrlOptionsPromptingCreds, which forces use of conduit
+rather than curl. The idea there was to use git credentials when basic
+auth is needed. Since those can be provided to conduit but not to curl
+(securely).
+
+But I do think that, if the user has forced use of curl, it ought to use curl.
+Even if the user only set options to `-4`, and so curl is not going to use
+the netrc and will fail the download. I have changed it to do so.
+
+----
+
+This bug report also suggests making git-annex read the netrc file itself.
+Note that git does *not* read the netrc file itself. What it does do is use
+libcurl. git-annex has good reasons to not use libcurl though.
+
+I am not thrilled by the prospect of implementing a parser for netrc
+in git-annex. The file is not even documented on my debian system;
+curl's man page links to a `netrc(5)` but that does not exist.
+
+Aside from git-credential-netrc, there is not a single mention of 
+the netrc file in git's documentation. This is arguably surprising behavior
+on the part of git. 
+
+I feel that git's support for netrc is vestigal and mostly supersceded by
+git credentials.
+"""]]
diff --git a/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_3_bed5008a429dd85dbb3389994f6d6295._comment b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_3_bed5008a429dd85dbb3389994f6d6295._comment
new file mode 100644
index 0000000000..7451b662a3
--- /dev/null
+++ b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_3_bed5008a429dd85dbb3389994f6d6295._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="comment 3"
+ date="2022-09-09T20:45:13Z"
+ content="""
+Thanks for your attention and for confirming there's an issue!
+
+> Aside from git-credential-netrc, there is not a single mention of the netrc file in git's documentation.
+
+I did notice this. It is a surprising behaviour! I only discovered it because DroneCI discovered it.
+
+If that's your opinion, I would rather make `git config credential.helper store` the canonical solution for noninteractive passworded HTTP, since it works consistently with both `git` and `git-annex`. I think everyone would find it easier to wrap our heads around if the docs dropped the mention of netrc and instead explained that git-annex hooks into git-credential(1) and that everyone should use that.
+"""]]
diff --git a/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_4_a67253e52fa4510073d7df60d2bd4adb._comment b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_4_a67253e52fa4510073d7df60d2bd4adb._comment
new file mode 100644
index 0000000000..48914d7414
--- /dev/null
+++ b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_4_a67253e52fa4510073d7df60d2bd4adb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="comment 4"
+ date="2022-09-09T20:46:31Z"
+ content="""
+Sorry, this was a typo:
+
+> or else not[e] the corner cases where it won't invoke curl.
+"""]]
diff --git a/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_5_d81762737f3854c75e804bad1697b517._comment b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_5_d81762737f3854c75e804bad1697b517._comment
new file mode 100644
index 0000000000..d81ec78951
--- /dev/null
+++ b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_5_d81762737f3854c75e804bad1697b517._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-09-13T16:47:27Z"
+ content="""
+I did rework the annex.web-options documentation earlier, 
+it now has:
+
+	Setting this option prevents git-annex from using git-credential
+	for prompting for http passwords. Instead, you can include "--netrc"
+	to make curl use your ~/.netrc file and record the passwords there.
+"""]]
diff --git a/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_6_e13932ead5920c7599031e85127317bb._comment b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_6_e13932ead5920c7599031e85127317bb._comment
new file mode 100644
index 0000000000..14182c2689
--- /dev/null
+++ b/doc/bugs/http_remotes_ignore_annex.web-options_--netrc/comment_6_e13932ead5920c7599031e85127317bb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="comment 6"
+ date="2022-09-13T23:32:01Z"
+ content="""
+That's awesome! Thanks very much joey.
+
+I'll mark this done now :)
+"""]]
diff --git a/doc/bugs/identically_configured_remotes_behave_differently.mdwn b/doc/bugs/identically_configured_remotes_behave_differently.mdwn
new file mode 100644
index 0000000000..2bd85d3758
--- /dev/null
+++ b/doc/bugs/identically_configured_remotes_behave_differently.mdwn
@@ -0,0 +1,134 @@
+### Please describe the problem.
+
+Identically configured remotes behave differently in the "git annex push" command after "git annex sync" to only one of them.
+
+### What steps will reproduce the problem?
+
+I have a repository on Linux and two USB backup sticks, all Ext4 file system. At one point I accidentally did "git annex sync music-backup-one".
+
+When I now "git annex push music-backup-two" it works as expected and I see the correct files on the stick and "git annex list" shows the content correctly. This is not true for "git annex push music-backup-one" as I must also issue "git annex mirror . --to=music-backup-one" for the content and "git annex list" to be correct (both commands are required in either order).
+
+How do I diagnose the problem so push works without the need for mirror on music-backup-one?
+
+During my investigation, I noticed the filemode (executable) bit for annexed files is not transferred to either USB drive if that is the only change (perhaps a separate issue).
+
+### What version of git-annex are you using? On what operating system?
+
+10.20231130-g0e9bc415882a5e3a285e004cf9f80936e5762a07
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+All three repos have:
+'annex.largefiles' set to 'mimeencoding=binary',
+'group' set to 'manual'
+'wanted' set to 'standard' and
+'numcopies' set to 3.
+
+desktop-music has adjust option --unlock and the two backups have option --lock.
+
+Here is the contents of .git/config for desktop-music:
+
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+[annex]
+	uuid = 0045d866-c80e-43c1-9b1b-b15a8c97c1aa
+	version = 10
+	adjustedbranchrefresh = true
+[filter "annex"]
+	smudge = git-annex smudge -- %f
+	clean = git-annex smudge --clean -- %f
+	process = git-annex filter-process
+[push]
+	followTags = true
+[receive]
+	denyCurrentBranch = updateInstead
+[remote "music-backup-one"]
+	url = /media/juanito/music-backup-one/music-library
+	fetch = +refs/heads/*:refs/remotes/music-backup-one/*
+	annex-uuid = 0b439b9f-16c7-4945-8cb2-9d6084677af3
+[remote "music-backup-two"]
+	url = /media/juanito/music-backup-two/music-library
+	fetch = +refs/heads/*:refs/remotes/music-backup-two/*
+	annex-uuid = 74a6b33c-fea2-45ef-a0c5-b677b43bc85f
+[remote "github"]
+	url = git@github.com:not-for-you.git
+	fetch = +refs/heads/*:refs/remotes/github/*
+	annex-ignore = true
+[remote "itunes-media"]
+	annex-directory = /home/juanito/annex-remotes/itunes-media
+	annex-uuid = e18dbc8e-8e0f-47f2-8f33-e8eb9da97a62
+	skipFetchAll = true
+	annex-tracking-branch = main:Music
+[remote "linux-media"]
+	annex-directory = /home/juanito/annex-remotes/linux-media
+	annex-uuid = b4efca25-5be6-4ea5-b0f9-207770abf21b
+	skipFetchAll = true
+	annex-tracking-branch = main:Music
+
+Here is the contents of .git/config for music-backup-one:
+
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+[remote "desktop-music"]
+	url = /home/juanito/git/music-library
+	fetch = +refs/heads/*:refs/remotes/desktop-music/*
+	annex-uuid = 0045d866-c80e-43c1-9b1b-b15a8c97c1aa
+[branch "adjusted/main(unlocked)"]
+	remote = desktop-music
+	merge = refs/heads/adjusted/main(unlocked)
+[annex]
+	uuid = 0b439b9f-16c7-4945-8cb2-9d6084677af3
+	version = 10
+	adjustedbranchrefresh = true
+[filter "annex"]
+	smudge = git-annex smudge -- %f
+	clean = git-annex smudge --clean -- %f
+	process = git-annex filter-process
+[push]
+	followTags = true
+[receive]
+	denyCurrentBranch = updateInstead
+
+Here is the contents of .git/config for music-backup-two:
+
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+[remote "desktop-music"]
+	url = /home/juanito/git/music-library
+	fetch = +refs/heads/*:refs/remotes/desktop-music/*
+	annex-uuid = 0045d866-c80e-43c1-9b1b-b15a8c97c1aa
+[branch "adjusted/main(unlocked)"]
+	remote = desktop-music
+	merge = refs/heads/adjusted/main(unlocked)
+[annex]
+	uuid = 74a6b33c-fea2-45ef-a0c5-b677b43bc85f
+	version = 10
+	adjustedbranchrefresh = true
+[filter "annex"]
+	smudge = git-annex smudge -- %f
+	clean = git-annex smudge --clean -- %f
+	process = git-annex filter-process
+[push]
+	followTags = true
+[receive]
+	denyCurrentBranch = updateInstead
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/identically_configured_remotes_behave_differently/comment_1_14fa5263ee9feedff8c36f86e4c33fd8._comment b/doc/bugs/identically_configured_remotes_behave_differently/comment_1_14fa5263ee9feedff8c36f86e4c33fd8._comment
new file mode 100644
index 0000000000..40bbc863db
--- /dev/null
+++ b/doc/bugs/identically_configured_remotes_behave_differently/comment_1_14fa5263ee9feedff8c36f86e4c33fd8._comment
@@ -0,0 +1,351 @@
+[[!comment format=mdwn
+ username="jstritch"
+ avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
+ subject="comment 1"
+ date="2024-02-16T17:48:55Z"
+ content="""
+I have attached a script and log file demonstrating the problem. The script:
+
+1) sets up an integration repository and two backup repositories each containing one file.
+
+2) adds another file to the integration repository, pushes it to both backups, and does a `git annex list` which shows correctly.
+
+3) does a `git annex sync music-backup-one` to introduce the problem.
+
+4) adds another file to the integration repository, pushes it to both backups, and does a `git annex list` which shows the file missing from `music-backup-one`.
+
+5) does `git annex mirror . --to=music-backup-one` then another `git annex list` which shows the files as expected.
+
+If the sync command is commented out, the last two lines are unnecessary. The sync command should not change the behavior of other commands.
+
+[[!format sh \"\"\"
+mkdir music-repo
+mkdir music-backup-one
+mkdir music-backup-two
+
+cd music-repo
+git init --initial-branch main
+git annex init music-repo
+git config annex.adjustedbranchrefresh true
+git config receive.denyCurrentBranch updateInstead
+git annex config --set annex.largefiles include=*.xtx
+git annex group here manual
+git annex wanted here standard
+echo \"test file one\" >> test-file-one.xtx
+git annex add .
+git commit -m \"add test file one\"
+git annex adjust --unlock
+
+cd ../music-backup-one
+git clone --origin music-repo ../music-repo .
+git annex init music-backup-one
+cd ../music-repo
+git remote add music-backup-one ../music-backup-one
+git annex push music-backup-one
+
+cd ../music-backup-two
+git clone --origin music-repo ../music-repo .
+git annex init music-backup-two
+cd ../music-repo
+git remote add music-backup-two ../music-backup-two
+git annex push music-backup-two
+
+cd ../music-backup-one
+git config annex.adjustedbranchrefresh true
+git config receive.denyCurrentBranch updateInstead
+git annex config --set annex.largefiles include=*.xtx
+git annex group here manual
+git annex wanted here standard
+git annex adjust --lock
+
+cd ../music-backup-two
+git config annex.adjustedbranchrefresh true
+git config receive.denyCurrentBranch updateInstead
+git annex config --set annex.largefiles include=*.xtx
+git annex group here manual
+git annex wanted here standard
+git annex adjust --lock
+
+cd ../music-repo
+echo \"test file two\" >> test-file-two.xtx
+git annex add .
+git commit -m \"add test file two\"
+git annex push music-backup-one
+git annex push music-backup-two
+git annex list
+
+# *** comment out line below to fix ***
+git annex sync music-backup-one
+
+echo \"test file three\" >> test-file-three.xtx
+git annex add .
+git commit -m \"add test file three\"
+git annex push music-backup-one
+git annex push music-backup-two
+git annex list
+
+# *** lines below only needed if sync is not commented out ***
+git annex mirror . --to=music-backup-one
+git annex list
+\"\"\"]]
+
+Here's the log file:
+
+[[!format sh \"\"\"
+Initialized empty Git repository in /home/juanito/Documents/music-repo/.git/
+init music-repo ok
+(recording state in git...)
+annex.largefiles include=*.xtx ok
+(recording state in git...)
+group here ok
+(recording state in git...)
+wanted here ok
+(recording state in git...)
+add test-file-one.xtx 
+ok                                
+(recording state in git...)
+[main (root-commit) 3358556] add test file one
+ 1 file changed, 1 insertion(+)
+ create mode 120000 test-file-one.xtx
+adjust  
+Switched to branch 'adjusted/main(unlocked)'
+ok
+Cloning into '.'...
+done.
+init music-backup-one (merging music-repo/git-annex into git-annex...)
+ok
+(recording state in git...)
+copy test-file-one.xtx (to music-backup-one...) 
+(recording state in git...)       
+ok
+(recording state in git...)
+push music-backup-one 
+Enumerating objects: 9, done.
+Counting objects: 100% (9/9), done.
+Delta compression using up to 12 threads
+Compressing objects: 100% (4/4), done.
+Writing objects: 100% (5/5), 422 bytes | 422.00 KiB/s, done.
+Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
+To ../music-backup-one
+ * [new branch]      main -> synced/main
+ * [new branch]      git-annex -> synced/git-annex
+ok
+Cloning into '.'...
+done.
+init music-backup-two (merging music-repo/git-annex into git-annex...)
+(recording state in git...)
+ok
+(recording state in git...)
+copy test-file-one.xtx (to music-backup-two...) 
+(recording state in git...)       
+ok
+(recording state in git...)
+push music-backup-two 
+Enumerating objects: 9, done.
+Counting objects: 100% (9/9), done.
+Delta compression using up to 12 threads
+Compressing objects: 100% (4/4), done.
+Writing objects: 100% (5/5), 447 bytes | 447.00 KiB/s, done.
+Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
+To ../music-backup-two
+ * [new branch]      main -> synced/main
+ * [new branch]      git-annex -> synced/git-annex
+ok
+annex.largefiles include=*.xtx (merging synced/git-annex into git-annex...)
+(recording state in git...)
+ok
+group here ok
+(recording state in git...)
+wanted here ok
+(recording state in git...)
+adjust  
+Switched to branch 'adjusted/main(locked)'
+ok
+annex.largefiles include=*.xtx (merging synced/git-annex into git-annex...)
+(recording state in git...)
+ok
+group here ok
+(recording state in git...)
+wanted here ok
+(recording state in git...)
+adjust  
+Switched to branch 'adjusted/main(locked)'
+ok
+add test-file-two.xtx 
+ok                                
+(recording state in git...)
+[adjusted/main(unlocked) e5a8b04] add test file two
+ 1 file changed, 1 insertion(+)
+ create mode 100644 test-file-two.xtx
+copy test-file-two.xtx (to music-backup-one...) 
+ok                                
+(recording state in git...)
+push music-backup-one 
+Enumerating objects: 23, done.
+Counting objects: 100% (23/23), done.
+Delta compression using up to 12 threads
+Compressing objects: 100% (15/15), done.
+Writing objects: 100% (18/18), 1.49 KiB | 1.49 MiB/s, done.
+Total 18 (delta 6), reused 0 (delta 0), pack-reused 0
+remote: merge synced/main (Merging into main...) 
+remote: Updating 3358556..e4f11f9
+remote: Fast-forward
+remote:  test-file-two.xtx | 1 +
+remote:  1 file changed, 1 insertion(+)
+remote:  create mode 120000 test-file-two.xtx
+remote: (Merging into adjusted branch...) 
+remote: Updating a49a4c5..526277a
+remote: Fast-forward
+remote:  test-file-two.xtx | 1 +
+remote:  1 file changed, 1 insertion(+)
+remote:  create mode 120000 test-file-two.xtx
+remote: ok
+To ../music-backup-one
+   49a54e0..73ea4dc  git-annex -> synced/git-annex
+   3358556..e4f11f9  main -> synced/main
+ok
+copy test-file-two.xtx (to music-backup-two...) 
+ok                                
+(recording state in git...)
+push music-backup-two 
+Enumerating objects: 20, done.
+Counting objects: 100% (20/20), done.
+Delta compression using up to 12 threads
+Compressing objects: 100% (15/15), done.
+Writing objects: 100% (18/18), 1.44 KiB | 1.44 MiB/s, done.
+Total 18 (delta 7), reused 0 (delta 0), pack-reused 0
+remote: merge synced/main (Merging into main...) 
+remote: Updating 3358556..e4f11f9
+remote: Fast-forward
+remote:  test-file-two.xtx | 1 +
+remote:  1 file changed, 1 insertion(+)
+remote:  create mode 120000 test-file-two.xtx
+remote: (Merging into adjusted branch...) 
+remote: Updating a49a4c5..526277a
+remote: Fast-forward
+remote:  test-file-two.xtx | 1 +
+remote:  1 file changed, 1 insertion(+)
+remote:  create mode 120000 test-file-two.xtx
+remote: ok
+To ../music-backup-two
+   cb6fd7f..db606aa  git-annex -> synced/git-annex
+   3358556..e4f11f9  main -> synced/main
+ok
+here
+|music-backup-one
+||music-backup-two
+|||web
+||||bittorrent
+|||||
+XXX__ test-file-one.xtx
+XXX__ test-file-two.xtx
+git-annex sync will change default behavior in the future to send content to repositories that have preferred content configured. If you do not want this to send any content, use --no-content (or -g) to prepare for that change. (Or you can configure annex.synccontent)
+commit  
+On branch adjusted/main(unlocked)
+nothing to commit, working tree clean
+ok
+pull music-backup-one 
+remote: Enumerating objects: 33, done.
+remote: Counting objects: 100% (29/29), done.
+remote: Compressing objects: 100% (19/19), done.
+remote: Total 21 (delta 6), reused 0 (delta 0), pack-reused 0
+Unpacking objects: 100% (21/21), 2.15 KiB | 2.15 MiB/s, done.
+From ../music-backup-one
+ * [new branch]      adjusted/main(locked)   -> music-backup-one/adjusted/main(locked)
+ * [new branch]      adjusted/main(unlocked) -> music-backup-one/adjusted/main(unlocked)
+ * [new branch]      git-annex               -> music-backup-one/git-annex
+ok
+(merging music-backup-one/git-annex into git-annex...)
+(recording state in git...)
+push music-backup-one 
+Enumerating objects: 15, done.
+Counting objects: 100% (15/15), done.
+Delta compression using up to 12 threads
+Compressing objects: 100% (6/6), done.
+Writing objects: 100% (7/7), 733 bytes | 733.00 KiB/s, done.
+Total 7 (delta 3), reused 0 (delta 0), pack-reused 0
+To ../music-backup-one
+   73ea4dc..c7e0b7c  git-annex -> synced/git-annex
+ok
+add test-file-three.xtx 
+ok                                
+(recording state in git...)
+[adjusted/main(unlocked) 823aa04] add test file three
+ 1 file changed, 1 insertion(+)
+ create mode 100644 test-file-three.xtx
+push music-backup-one 
+Enumerating objects: 10, done.
+Counting objects: 100% (10/10), done.
+Delta compression using up to 12 threads
+Compressing objects: 100% (7/7), done.
+Writing objects: 100% (8/8), 844 bytes | 844.00 KiB/s, done.
+Total 8 (delta 1), reused 0 (delta 0), pack-reused 0
+remote: merge synced/main (Merging into main...) 
+remote: Updating e4f11f9..5659d23
+remote: Fast-forward
+remote:  test-file-three.xtx | 1 +
+remote:  1 file changed, 1 insertion(+)
+remote:  create mode 120000 test-file-three.xtx
+remote: (Merging into adjusted branch...) 
+remote: Updating 36d4013..7ab1f09
+remote: Fast-forward
+remote:  test-file-three.xtx | 1 +
+remote:  1 file changed, 1 insertion(+)
+remote:  create mode 120000 test-file-three.xtx
+remote: ok
+To ../music-backup-one
+   c7e0b7c..a80e236  git-annex -> synced/git-annex
+   e4f11f9..5659d23  main -> synced/main
+ok
+copy test-file-three.xtx (to music-backup-two...) 
+ok                                
+(recording state in git...)
+push music-backup-two 
+Enumerating objects: 48, done.
+Counting objects: 100% (42/42), done.
+Delta compression using up to 12 threads
+Compressing objects: 100% (29/29), done.
+Writing objects: 100% (32/32), 2.99 KiB | 2.99 MiB/s, done.
+Total 32 (delta 12), reused 0 (delta 0), pack-reused 0
+remote: merge synced/main (Merging into main...) 
+remote: Updating e4f11f9..5659d23
+remote: Fast-forward
+remote:  test-file-three.xtx | 1 +
+remote:  1 file changed, 1 insertion(+)
+remote:  create mode 120000 test-file-three.xtx
+remote: (Merging into adjusted branch...) 
+remote: Updating 36d4013..7ab1f09
+remote: Fast-forward
+remote:  test-file-three.xtx | 1 +
+remote:  1 file changed, 1 insertion(+)
+remote:  create mode 120000 test-file-three.xtx
+remote: ok
+To ../music-backup-two
+   db606aa..c67fdd4  git-annex -> synced/git-annex
+   e4f11f9..5659d23  main -> synced/main
+ok
+here
+|music-backup-one
+||music-backup-two
+|||web
+||||bittorrent
+|||||
+XXX__ test-file-one.xtx
+X_X__ test-file-three.xtx
+XXX__ test-file-two.xtx
+copy test-file-one.xtx ok
+copy test-file-three.xtx (to music-backup-one...) 
+ok                                
+copy test-file-two.xtx ok
+(recording state in git...)
+here
+|music-backup-one
+||music-backup-two
+|||web
+||||bittorrent
+|||||
+XXX__ test-file-one.xtx
+XXX__ test-file-three.xtx
+XXX__ test-file-two.xtx
+\"\"\"]]
+"""]]
diff --git a/doc/bugs/import_tree_on_adjusted_unlocked_branch_issues.mdwn b/doc/bugs/import_tree_on_adjusted_unlocked_branch_issues.mdwn
new file mode 100644
index 0000000000..e668942315
--- /dev/null
+++ b/doc/bugs/import_tree_on_adjusted_unlocked_branch_issues.mdwn
@@ -0,0 +1,11 @@
+The test suite spits this out during the export import test:
+
+	unable to propigate merge commit Ref "4475560d4e3958521ad12e2715aeee244ea0cf78" back to Ref "refs/heads/master"
+
+It does not fail, but I think this is actually an indication of a bug.
+
+The ref is a merge commit, because it's imported a tree from a special remote,
+and merged it. Which is a reasonable thing to want to do, even when on an
+adjusted branch. So, this needs to be dealt with somehow. --[[Joey]]
+
+> [[done]] I think? --[[Joey]]
diff --git a/doc/bugs/import_tree_on_adjusted_unlocked_branch_issues/comment_1_a6aed4a1d1958e4734684b78b0f0a3de._comment b/doc/bugs/import_tree_on_adjusted_unlocked_branch_issues/comment_1_a6aed4a1d1958e4734684b78b0f0a3de._comment
new file mode 100644
index 0000000000..5a91c15923
--- /dev/null
+++ b/doc/bugs/import_tree_on_adjusted_unlocked_branch_issues/comment_1_a6aed4a1d1958e4734684b78b0f0a3de._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="B"
+ avatar="http://cdn.libravatar.org/avatar/f9b0137cb32be76e5a171bff7ce98da7"
+ subject="Workaround"
+ date="2020-07-02T12:51:41Z"
+ content="""
+Is there any workaround in the meantime? (I'm seeing this, too). 
+"""]]
diff --git a/doc/bugs/import_tree_on_adjusted_unlocked_branch_issues/comment_2_7fc16d6ff0f1a61907bc34e8f8b71add._comment b/doc/bugs/import_tree_on_adjusted_unlocked_branch_issues/comment_2_7fc16d6ff0f1a61907bc34e8f8b71add._comment
new file mode 100644
index 0000000000..08ff5c8e8f
--- /dev/null
+++ b/doc/bugs/import_tree_on_adjusted_unlocked_branch_issues/comment_2_7fc16d6ff0f1a61907bc34e8f8b71add._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-07-02T18:36:55Z"
+ content="""
+There's a simple workaround, in fact. Make a git commit, any git commit.
+An empty commit will do:
+
+	git commit --allow-empty -m "git-annex is a little bit buggy"
+
+git annex sync will be able to handle that commit, because it's not a
+merge commit.
+
+It looks to me like this bug does not happen when `git annex merge` or `git
+annex sync --content` are used. There needs to have been a manual
+`git merge`.
+
+In the test suite, it happens after a merge conflict occurs, and
+git add is run to resolve the conflict. When git-annex sync
+is then run, it results in the problem merge commit.
+
+Do you have another way to reproduce this bug?
+"""]]
diff --git a/doc/bugs/import_tree_on_adjusted_unlocked_branch_issues/comment_3_c75eee397fc6a53aa0ff55f993b790a7._comment b/doc/bugs/import_tree_on_adjusted_unlocked_branch_issues/comment_3_c75eee397fc6a53aa0ff55f993b790a7._comment
new file mode 100644
index 0000000000..304967ade9
--- /dev/null
+++ b/doc/bugs/import_tree_on_adjusted_unlocked_branch_issues/comment_3_c75eee397fc6a53aa0ff55f993b790a7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-06-21T18:44:09Z"
+ content="""
+The test suite doesn't output that any more, so I'm going to assume this is
+fixed.
+"""]]
diff --git a/doc/bugs/importtree_replaces_files_with_identical_size.mdwn b/doc/bugs/importtree_replaces_files_with_identical_size.mdwn
new file mode 100644
index 0000000000..bf0b78cd29
--- /dev/null
+++ b/doc/bugs/importtree_replaces_files_with_identical_size.mdwn
@@ -0,0 +1,65 @@
+### Please describe the problem.
+
+I've been managing my about 50k photos (around 72k files) using git-annex. Recently I've decided to add a directory remote using importtree/exporttree in order to synchronize it with Nextcloud. To start slowly, I've first exported the files, then let Nextcloud upload them and then imported the files again. During the import, some files were re-imported, I think Nextcloud re-synced those files due to some errors that occurred during uploading. I've then compared the freshly create git branch to the current branch and found that while those re-imported files were not different, some other files had differences. On closer inspection, I found that these files have been replaced by identically sized files, leading, e.g., to the following diff:
+
+```diff
+diff --git a/Profiles/Sony DSC-RX100M5A Camera Portrait.dcp b/Profiles/Sony DSC-RX100M5A Camera Portrait.dcp
+index 918bbfcc8ff..8c163b32ae2 120000
+--- a/Profiles/Sony DSC-RX100M5A Camera Portrait.dcp    
++++ b/Profiles/Sony DSC-RX100M5A Camera Portrait.dcp    
+@@ -1 +1 @@
+-../.git/annex/objects/Pj/xF/SHA256E-s278110--e4a0dcd12fa02840605dbc4f7c6e258ff3002faf3fc3dc2ca262e8bbf1cf542f.dcp/SHA256E-s278110--e4a0dcd12fa02840605dbc4f7c6e258ff3002faf3fc3dc2ca262e8bbf1cf542f.dcp
+\ No newline at end of file
++../.git/annex/objects/5f/Kg/SHA256E-s278110--82041bcc454f77ee5b4a55522178cdc9d5aa2d78b03176236add7e28dfac2b63.dcp/SHA256E-s278110--82041bcc454f77ee5b4a55522178cdc9d5aa2d78b03176236add7e28dfac2b63.dcp
+\ No newline at end of file
+```
+
+These are camera profiles, and the file it has been replaced with is a different camera profile in the same directory. I've checked in the  exported directory and the two camera files have the correct SHA256 hash there. To be precise, the file there has hash `e4a0dcd12fa02840605dbc4f7c6e258ff3002faf3fc3dc2ca262e8bbf1cf542f` while the commit created during import claims it has the hash `82041bcc454f77ee5b4a55522178cdc9d5aa2d78b03176236add7e28dfac2b63`. I have similar changes in Audacity project files that I also have in the same repository where 8 out of 22 files have been replaced by others. Of these 22 files, 20 have the same size. I have seen one case where two files were replaced by the same target file, apart from that from a manual inspection, the hashes of the files in the diff seem to be disjoint.
+
+The problem remains when running the import command again and when merging the remote, there are actually duplicates in the affected directories. I've rolled back the merge using `git reset --merge`. I assume touching the affected files in the export and re-importing could solve the problem, but I would like to preserve any state that could help with debugging for now as I would really like to know the root cause of this to avoid that this happens again.
+
+### What steps will reproduce the problem?
+
+I have tried reproducing the problem using the set of camera profiles in a new git-annex repository, but without any luck. I've also tried generating equally-sized random files, again without any luck. In theory, the steps to reproduce should be the following, but the resulting diff is always empty:
+
+```sh
+mkdir annex-test
+cd annex-test/
+git init .
+git annex init
+mkdir ../d
+git annex initremote d type=directory directory=../d exporttree=yes importtree=yes encryption=none
+# create some files
+for i in $(seq 32); do dd if=/dev/urandom of=file${i}.test bs=200k count=10; done
+git annex add .
+git commit -m "initial commit"
+git annex export master --to d
+git annex import master --from d
+git diff d/master
+```
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 10.20220222-g1c4b0b4c2
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-9.0.2 http-client-0.7.10 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+```
+
+I'm using Arch Linux.
+
+### Please provide any additional information below.
+
+Unfortunately, I don't have the output of git-annex anymore. However, the used commands, in particular for setting up the remote, exporting and importing were identical to those listed above (apart from the name of the directory and the name of the remote). I'm also quite certain that the files that are now listed as different were not listed in the output of the import command.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I've been successfully using git-annex to manage the growing collection of photos I take for several years now. Synchronizing the collection across several disks while files are renamed and some disks are only rarely synchronized and some contain only a subset of the photos wouldn't have been possible without git-annex. Also, using git-annex gives me the safety that the original photos will never be modified. There is nothing better than using git-annex to verify that all photos have been copied unmodified from a memory card before wiping it.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/importtree_replaces_files_with_identical_size/comment_1_2742c2cbde12aa85b8254dd6907fcfc1._comment b/doc/bugs/importtree_replaces_files_with_identical_size/comment_1_2742c2cbde12aa85b8254dd6907fcfc1._comment
new file mode 100644
index 0000000000..b2637e54cc
--- /dev/null
+++ b/doc/bugs/importtree_replaces_files_with_identical_size/comment_1_2742c2cbde12aa85b8254dd6907fcfc1._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-03-21T16:20:27Z"
+ content="""
+The directory special remote use the size and mtime as the
+ContentIdentifier of a file. It used to use inode number as well, but
+some filesystems make up new inodes on each mount so that was dropped.
+
+So when two files have the same size and mtime, it will import one of them,
+and then when it comes to the other one, see that it already has that
+ContentIdentifier and use the content it already imported.
+
+For example:
+
+	joey@darkstar:/tmp/t>git-annex initremote d type=directory directory=../d importtree=yes exporttree=yes encryption=none
+	joey@darkstar:/tmp/t>echo hi > ../d/1
+	joey@darkstar:/tmp/t>echo no > ../d/2
+	joey@darkstar:/tmp/t>touch --reference=../d/1 ../d/2
+	joey@darkstar:/tmp/t>git-annex import master --from d
+	joey@darkstar:/tmp/t>git merge d/master 
+	joey@darkstar:/tmp/t>cmp 1 2
+	joey@darkstar:/tmp/t>
+
+Perhaps NextCloud is for some reason giving multiple files the same mtime?
+
+This is rather unlikely to happen naturally, especially on modern
+filesystems that have high resolution mtimes. Even "echo 1> 1; echo 2>2"
+generates files with 2 different mtimes. To get the same mtime, the two
+files have to be written by the same process at very close to the same
+time.
+
+Probably that's why NextCloud managed to get the same mtime, although why
+it would be rewriting the content of the file when the content had not
+changed I don't know and perhaps that's a bug of some kind in it.
+"""]]
diff --git a/doc/bugs/importtree_replaces_files_with_identical_size/comment_2_46336dc995a7cefb8ebbfe98f098e258._comment b/doc/bugs/importtree_replaces_files_with_identical_size/comment_2_46336dc995a7cefb8ebbfe98f098e258._comment
new file mode 100644
index 0000000000..3ce0061a02
--- /dev/null
+++ b/doc/bugs/importtree_replaces_files_with_identical_size/comment_2_46336dc995a7cefb8ebbfe98f098e258._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-03-21T16:38:43Z"
+ content="""
+So this makes me think that [[!73df633a6215faa093e4a7524c6d328aa988aed1]]
+needs to be reverted and the inode number used again. But that did fix a
+bug of a sort, that importing from a fat filesystem after it was remounted
+would re-import everything. So I suppose the best that can be done is to
+make it configurable whether inodes should be ignored or not when importing
+from a directory special remote. And presumably default to not ignoring
+them.
+
+done
+"""]]
diff --git a/doc/bugs/importtree_replaces_files_with_identical_size/comment_3_2b9bdb906043aa84ea6cf0d74a685769._comment b/doc/bugs/importtree_replaces_files_with_identical_size/comment_3_2b9bdb906043aa84ea6cf0d74a685769._comment
new file mode 100644
index 0000000000..28e0eff04f
--- /dev/null
+++ b/doc/bugs/importtree_replaces_files_with_identical_size/comment_3_2b9bdb906043aa84ea6cf0d74a685769._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="michael@ff03af62c7fd492c75066bda2fbf02370f5431f4"
+ nickname="michael"
+ avatar="http://cdn.libravatar.org/avatar/125bdfa8a2b91432c072615364bc3fa1"
+ subject="comment 3"
+ date="2022-03-21T19:10:35Z"
+ content="""
+First of all, thank you very much for the quick fix!
+
+I don't think that Nextcloud rewrote these files as otherwise git-annex would have re-imported them instead of recognizing the exported files. Using stat, I confirm that the replaced files have indeed the exactly same modify time - `Modify: 2021-12-19 22:47:35.988712668 +0100`. I think this is the time when I copied these files from a different directory, as this does not correspond to the modify time of the original files (that I still have). Quite interestingly, the access time of both original files is also the exactly same time, which supports this hypothesis. I can reproduce that copying a couple of small files using cp gives me target files with exactly identical modify times (in fact, all time stamps stat displays are identical). Steps to reproduce:
+
+```
+for i in $(seq 32); do dd if=/dev/urandom of=file${i}.test bs=20k count=1; done
+mkdir d
+cp *.test d/
+stat d/*.test
+```
+
+For me, this reproduces both on ext4 and on tmpfs.
+"""]]
diff --git a/doc/bugs/importtree_replaces_files_with_identical_size/comment_4_9363ed782b5dc8d70a323fbc2574e7c7._comment b/doc/bugs/importtree_replaces_files_with_identical_size/comment_4_9363ed782b5dc8d70a323fbc2574e7c7._comment
new file mode 100644
index 0000000000..bdbf6ca127
--- /dev/null
+++ b/doc/bugs/importtree_replaces_files_with_identical_size/comment_4_9363ed782b5dc8d70a323fbc2574e7c7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-03-21T19:59:42Z"
+ content="""
+Makes sense, cp is just the kind of program that can write 2 files at very
+close to the same time, and when small enough, get the same mtime.
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb.mdwn b/doc/bugs/importtree_spends_hours_reading_cidsdb.mdwn
new file mode 100644
index 0000000000..8a7594c2b9
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb.mdwn
@@ -0,0 +1,50 @@
+### Please describe the problem.
+
+Hi!
+
+I've got a directory special remote set up, with importtree.  After scanning through it (import filename... ok), it stops reading from the filesystem and spends hours just reading from cidsdb.  Verifying with strace, there is not reading from the filesystem here.
+
+### What steps will reproduce the problem?
+
+Here are my prep steps:
+
+```
+git init
+git config annex.thin true
+git annex init 'local hub'
+git annex wanted . "include=* and exclude=testdata/*"
+touch mtree
+git annex add mtree
+git annex sync
+git annex adjust --unlock-present
+git annex initremote source type=directory directory=/acrypt/git-annex/bind-ro/testdata importtree=yes encryption=none
+git annex enableremote source directory=/acrypt/git-annex/bind-ro/testdata
+git config remote.source.annex-readonly true
+git config remote.source.annex-tracking-branch main:testdata # (says to put the files in the "$REPO" directory)
+git config annex.securehashesonly true
+git config annex.genmetadata true
+git config annex.diskreserve 100M
+git annex sync
+```
+
+It is that last sync that runs into this problem.
+
+### What version of git-annex are you using? On what operating system?
+
+10.20230407 on Debian bullseye
+
+### Please provide any additional information below.
+
+There are about 150,000 files in that tree.  This problem occurs *after* git-annex is done scanning the tree (verified with strace and lsof).  This problem does not occur with the same number of files in a local/standard git-annex repo (as opposed to the directory special remote).
+
+.git/annex/cidsdb/db is only 51M so it is certainly entirely cached.  git-annex is entirely CPU-bound at this point.
+
+I can rerun the sync with an unchanged import directory.  It still takes 107 minutes, the majority of which is spent reading cidsdb.  Only the first minute or two are spent scanning the source area.
+
+I have tested this on a source directory that's 2.2G and another that's 1.1T, both with about 150,000 files.  After the first import, the subsequent syncs are similar in performance.  In other words, this behavior appears to be related to the number of files, not the size of files.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, and I hope to use it for a project to archive family photos and videos to BD-R (that's what this is about here)
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_10_a2724ab85bc91fba3bb6e55d2b1e3878._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_10_a2724ab85bc91fba3bb6e55d2b1e3878._comment
new file mode 100644
index 0000000000..d8ca8820a6
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_10_a2724ab85bc91fba3bb6e55d2b1e3878._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: comment 8"""
+ date="2023-06-02T16:49:35Z"
+ content="""
+What's the last thing output before it enters this state? I know it's at some
+point after the last "import filename... ok" but I haven't a clue what it
+could be.
+
+For what it's worth, I straced the importing stage, and there are no reads
+from the database FDs at all. Presumably sqlite realizes its empty and
+doesn't need to keep re-reading to respond to the queries done in that
+stage. Each file imported took 113 syscalls (there are small files, so only
+1 syscall needed to read the content).
+
+I also attached a strace immediately after it finished the importing stage,
+and straced all the way to the end (importing 1000 files). There was not a
+single `pread64`. FD #14 was already closed at that point, and the cidsdb
+was never accessed again. 
+
+Which matches my reading of the code that it never accesses the cidsdb after
+that point. Which makes what you're seeing very strange indeed.
+
+Something is missing to let me reproduce this. Can you reproduce it with
+the script I posted in comment #1?
+
+----
+
+Also straced an entire import of 1000 files, and this is all the preads
+from fd 14 (there were a similar amount with 3 other fds)
+
+	joey@darkstar:~/tmp>egrep 'pread64.14' /tmp/strace
+	pread64(14, "", 8, 512)                 = 0
+	pread64(14, "", 100, 0)                 = 0
+	pread64(14, "", 16, 24)                 = 0
+	pread64(14, "\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0", 16, 24) = 16
+	pread64(14, "SQLite format 3\0\20\0\2\2\0@  \0\0\0\1\0\0\0\1"..., 4096, 0) = 4096
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_11_a3fc6b67529ddce9e79c0e72996259ad._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_11_a3fc6b67529ddce9e79c0e72996259ad._comment
new file mode 100644
index 0000000000..8f771e2921
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_11_a3fc6b67529ddce9e79c0e72996259ad._comment
@@ -0,0 +1,136 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 11"
+ date="2023-06-02T21:44:53Z"
+ content="""
+So I ran your script on the same dataset that I was using.
+
+I was rather surprised that it rocketed through in 15 minutes.  I then ran a subsequent git annex sync, which after a few minutes started showing the same pread64 behavior as before.
+
+Perhaps your improvements have been helping here?
+
+I went back to my original full script and thought: let's time each git-annex call.
+
+```
+#!/bin/bash
+
+set -euo pipefail
+
+if [ -z \"$2\" ]; then
+        echo \"Syntax: $0 REPO DRIVE\"
+        exit 5
+fi
+
+REPO=\"$1\"
+DRIVE=\"$2\"
+DRIVEBASE=\"/acrypt/no-backup/jgoerzen/git-annex-testing\"
+
+set -x
+cd /acrypt/git-annex/repos
+mkdir $REPO
+cd $REPO
+git init
+git config annex.thin true
+git annex init 'local hub'
+# use newer belowgit annex wanted . \"include=mtree exclude=$REPO/*\"
+git annex wanted . \"include=* and exclude=$REPO/*\"
+
+# Now initialize things.
+touch mtree
+time git annex add mtree
+time git annex sync
+time git annex adjust --unlock-present
+
+time git annex initremote source type=directory directory=/acrypt/git-annex/bind-ro/$REPO importtree=yes encryption=none
+
+time git annex enableremote source directory=/acrypt/git-annex/bind-ro/$REPO
+git config remote.source.annex-readonly true
+git config remote.source.annex-tracking-branch main:$REPO # (says to put the files in the \"$REPO\" directory)
+git config annex.securehashesonly true
+git config annex.genmetadata true
+git config annex.diskreserve 100M
+
+time git annex sync
+
+# Now set up the clone
+
+cd $DRIVEBASE/$DRIVE/git-annex
+time git clone /acrypt/git-annex/repos/$REPO
+cd $REPO
+git config annex.thin true
+git annex init \"alexandria:Goerzen3\"
+time git annex adjust --unlock  # NTFS doesn't like symlinks
+time git annex sync
+
+cd /acrypt/git-annex/repos/$REPO
+git remote add $DRIVE $DRIVEBASE/$DRIVE/git-annex/$REPO
+time git annex sync $DRIVE
+git annex group $DRIVE archivedrive
+git annex wanted $DRIVE 'include=mtree* or standard' # 'standard and include=mtree*'
+time git annex sync
+
+cd $DRIVEBASE/$DRIVE/git-annex/$REPO
+time git annex sync
+git annex enableremote source directory=/acrypt/git-annex/bind-ro/$REPO
+git config remote.source.annex-readonly true
+git config remote.source.annex-tracking-branch main:$REPO # (says to put the files in the \"$REPO\" directory)
+git config annex.securehashesonly true
+git config annex.genmetadata true
+git config annex.diskreserve 100M
+
+time git annex sync --content
+time git annex get --auto
+
+cd /acrypt/git-annex/repos/$REPO
+time git annex sync
+```
+
+In this script:
+
+First sync (this is before the initremote so it is doing pretty much nothing):
+
+real    0m0.075s
+user    0m0.027s
+sys     0m0.045s
+
+Second sync (this is after initremote/enableremote):
+
+real    15m1.417s
+user    7m10.770s
+sys     5m59.405s
+
+[ that correlates closely with how long it took to run your script ]
+
+Third sync (this is after the clone/init/adjust):
+
+real    0m6.606s
+user    0m1.908s
+sys     0m4.632s
+
+Fourth sync (git annex sync $DRIVE):
+real    0m1.066s
+user    0m0.634s
+sys     0m0.647s
+
+Fifth sync (after the group/wanted):
+real    113m32.988s
+user    55m21.012s
+sys     58m40.752s
+
+Sixth sync:
+real    0m1.180s
+user    0m0.819s
+sys     0m0.514s
+
+Seventh sync (git annex sync --content):
+real    112m29.594s
+user    55m13.650s
+sys     57m52.259s
+
+Eigth sync (back at the original repo):
+real    110m3.099s
+user    51m32.468s
+sys     58m53.885s
+
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_12_c1865c88d23873eb4b32489fc387f40c._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_12_c1865c88d23873eb4b32489fc387f40c._comment
new file mode 100644
index 0000000000..ce05ecb617
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_12_c1865c88d23873eb4b32489fc387f40c._comment
@@ -0,0 +1,121 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2023-06-05T16:28:05Z"
+ content="""
+That is a significant move of the goal posts. I don't know if that even
+involves importtree being slow anymore. 
+
+You've apparently got a lot of stuff going on in the directories used by 
+that script, NTFS, acrypt, some kind of removable drive, ...?
+
+I tried to adapt the script to a simple test case that I can run, but had
+to leave all that stuff out, since I don't know anything about it. The
+script I ran is below. 
+
+I ran it with 10000 files, and the timings of the syncs were:
+
+1. 0m0.154s  
+2. 2m5.719s
+3. 0m3.088s
+4. 0m15.240s
+5. 0m34.297s
+6. 0m1.244s
+7. 2m7.648s
+8. 0m35.378s
+ 
+So I have not reproduced the (new) problem, #5 and #8 are not slow.
+
+Your 5th sync taking a long time is particularly strange because the only
+difference between it and the 4th sync is that `git annex wanted` is
+configured. But, `git-annex sync` does not do anything with that
+configuration unless it is syncing content. That made me think you might
+have annex.synccontent set in gitconfig globally. It seems to me that would
+also make the 3rd sync slow, but I suppose you could have a complex git
+config that sets it for some repos but not other ones or something like
+that.
+
+Otherwise I'm out of ideas about how to reproduce your problem.
+
+I'll reiterate that it would be helpful to see the last output of the sync
+command before it does whatever is being slow.
+
+-----
+
+	#!/bin/bash
+	
+	set -euo pipefail
+	set -x
+	
+	NFILES=$1
+	
+	REPO=repo
+	DRIVE=drive
+	REPOBASE=`pwd`/bench/repo
+	DRIVEBASE=`pwd`/bench/drive
+	SRBASE=`pwd`/bench/sr
+	
+	mkdir -p $REPOBASE
+	mkdir -p $SRBASE/$REPO
+	perl -e 'for(1..'$NFILES') { open(OUT,">", "'$SRBASE/$REPO'/f$_"); print OUT $_; close OUT }'
+	
+	set -x
+	cd $REPOBASE
+	mkdir $REPO
+	cd $REPO
+	git init
+	git config annex.thin true
+	git annex init 'local hub'
+	# use newer belowgit annex wanted . "include=mtree exclude=$REPO/*"
+	git annex wanted . "include=* and exclude=$REPO/*"
+	
+	# Now initialize things.
+	touch mtree
+	git annex add mtree
+	time git annex sync
+	git annex adjust --unlock-present
+	
+	git annex initremote source type=directory directory=$SRBASE/$REPO importtree=yes encryption=none
+	
+	git annex enableremote source directory=$SRBASE/$REPO 
+	git config remote.source.annex-readonly true
+	git config remote.source.annex-tracking-branch master:$REPO # (says to put the files in the "$REPO" directory)
+	git config annex.securehashesonly true
+	git config annex.genmetadata true
+	git config annex.diskreserve 100M
+	
+	time git annex sync
+	
+	# Now set up the clone
+	
+	mkdir -p $DRIVEBASE/$DRIVE/git-annex
+	cd $DRIVEBASE/$DRIVE/git-annex
+	git clone $REPOBASE/$REPO
+	cd $REPO
+	git config annex.thin true
+	git annex init "alexandria:Goerzen3"
+	git annex adjust --unlock  # NTFS doesn't like symlinks
+	time git annex sync
+	
+	cd $REPOBASE/$REPO
+	git remote add $DRIVE $DRIVEBASE/$DRIVE/git-annex/$REPO
+	time git annex sync $DRIVE
+	git annex group $DRIVE archivedrive
+	git annex wanted $DRIVE 'include=mtree* or standard' # 'standard and include=mtree*'
+	time git annex sync
+	
+	cd $DRIVEBASE/$DRIVE/git-annex/$REPO
+	time git annex sync
+	git annex enableremote source directory=$SRBASE/$REPO
+	git config remote.source.annex-readonly true
+	git config remote.source.annex-tracking-branch master:$REPO # (says to put the files in the "$REPO" directory)
+	git config annex.securehashesonly true
+	git config annex.genmetadata true
+	git config annex.diskreserve 100M
+	
+	time git annex sync --content
+	git annex get --auto
+	
+	cd $REPOBASE/$REPO
+	time git annex sync
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_13_6043be5152ba2d44fb9aac4063060b56._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_13_6043be5152ba2d44fb9aac4063060b56._comment
new file mode 100644
index 0000000000..f119c7d78b
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_13_6043be5152ba2d44fb9aac4063060b56._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 13"
+ date="2023-06-05T19:32:28Z"
+ content="""
+My apologies for forgetting that.
+
+So initially I thought it was after the last \"import source... ok\".  I'm no longer convinced that it happens after the last one.  There is clearly a phase before this starts, and a separate phase exhibiting this behavior.
+
+The last output from one of these runs was:
+
+
+```
+/acrypt/git-annex/bind-ro/testdata/dvd/var..redacted..: openBinaryFile: permission denied (Permission denied)
+^Mok
+
+  Failed to import some files from source. Re-run command to resume import.
+```
+
+And indeed there were about 2 dozen files out of that source set that it didn't have the permission to read.
+
+I'm sorry it looked like expansion of scope.  This is not really on NTFS; it's still on ZFS as it has been from the beginning.  I had been testing with one of the repos on NTFS previously but in an effort to rule that out, I've been 100% on ZFS since before reporting this issue.  \"acrypt\" is just the name of my ZFS pool and that refers to that it's atop LUKS (I don't believe this to be relevant, since the CPU time is in git-annex, not kcryptd)
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_14_e961d2b508e3260670bb61a5ae51d109._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_14_e961d2b508e3260670bb61a5ae51d109._comment
new file mode 100644
index 0000000000..42efb8208e
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_14_e961d2b508e3260670bb61a5ae51d109._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2023-06-06T17:11:35Z"
+ content="""
+There's only one import in the sync, and your output shows it completed
+(with error).
+
+The only other phase of sync that could be run after that and take a lot of
+time is content syncing. You would have to have annex.synccontent set
+somewhere for sync to do that. Do you?
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_15_35d233db5f7410048bd0cf9f5b4fd5cc._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_15_35d233db5f7410048bd0cf9f5b4fd5cc._comment
new file mode 100644
index 0000000000..2073dca187
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_15_35d233db5f7410048bd0cf9f5b4fd5cc._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2023-06-06T17:31:49Z"
+ content="""
+It would make a lot of sense for --content syncing to be what remains slow.
+That has to scan over all the files and when it decides that it does not
+need to copy the content anywhere, that's a tight loop with no output.
+
+In my repo with 10000 files that was set up by the latest test case,
+`git-annex sync` takes 13 seconds, and with --content it takes 61 seconds.
+
+I optimised a numcopies/mincopies lookup away, and that got it
+down to 28 seconds. 
+
+The cidsdb does not get accessed by the --content scan
+in my testing, although there may be other situations where it does.
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_16_d0a7af6aecf8cb070c34edec1b3e2ecb._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_16_d0a7af6aecf8cb070c34edec1b3e2ecb._comment
new file mode 100644
index 0000000000..0973a756c5
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_16_d0a7af6aecf8cb070c34edec1b3e2ecb._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2023-06-06T18:43:50Z"
+ content="""
+I did try making the permissions of a file not allow it to be read, and so
+reproduced the "Failed to import some files from source." That didn't
+change the sync time appreciably (with or without content syncing).
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_17_8fe8c0747a69ea977942a399ac929e77._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_17_8fe8c0747a69ea977942a399ac929e77._comment
new file mode 100644
index 0000000000..90fbd5e7a7
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_17_8fe8c0747a69ea977942a399ac929e77._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 17"""
+ date="2023-06-06T19:07:25Z"
+ content="""
+Another expensive thing sync has to do, due to the adjusted branch
+being checked out, is Command.Sync.updateBranches. In my repo with 10000
+files, when not using --content, that is responsible for most of the run
+time of a sync when there is nothing new to import or pull.
+
+That happens because `git-annex adjust --unlock-present` was used. So sync
+needs to update the branch if there have been any changes to the content
+that is present. Currently when in such an adjusted branch, it re-builds
+the branch every time it's run. 
+
+It would be possible to avoid that when there have been no changes to the
+content that is present, but it would need to deal with eg a previous sync
+command having transferred some content before it was interrupted. So it
+would need some kind of flag file to be written when content changes.
+
+(With the master branch checked out instead, `git-annex sync --content` is
+now as fast as `git-annex find --not --in source`.)
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_18_b5ea8e5a761b254672171c3ab41e09f9._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_18_b5ea8e5a761b254672171c3ab41e09f9._comment
new file mode 100644
index 0000000000..e49fcdf700
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_18_b5ea8e5a761b254672171c3ab41e09f9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: comment 17"""
+ date="2023-06-08T20:56:25Z"
+ content="""
+I've fixed that, now `git-annex sync` avoids updating the adjusted branch
+when there have been no changes to available content.
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_19_238c26c1a3f4ab7dd6ea3b2f26febaef._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_19_238c26c1a3f4ab7dd6ea3b2f26febaef._comment
new file mode 100644
index 0000000000..fc1804db8a
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_19_238c26c1a3f4ab7dd6ea3b2f26febaef._comment
@@ -0,0 +1,52 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2023-06-08T21:14:35Z"
+ content="""
+I ran the second test case with 150000 files, and here's how long the syncs
+took:
+
+1. 0m0.170s
+2. 33m37.810s
+3. 0m36.644s
+4. 2m58.773s
+5. 13m38.126s
+6. 0m3.933s
+7. still running after 85 minutes
+8. tbd
+
+Sync 2 took longer than your results in comment #11, but consistent with my
+laptop being slower. And I think 33 minutes to import 150k files is fine.
+
+Still not seeing sync 5 take as long as it did for you.
+Nowhere in the same ballpark. 13 minutes seems ok for a sync --content
+that has to scan 150000 files.
+
+The 7th sync is seeming too slow to me. For you it took equally long as the
+5th sync, and both are --content syncs. So maybe I'm seeing the same
+problem but only on the 7th for some reason?
+
+For me it seemed to take a long time after outputting "list source ok". At
+that point strace showed only a lot of futex(). And the cpu was pegged. And
+it had the cidsdb open. Hmmm.. This is feeling a bit like the problem you
+originally reported.
+
+Interrupted the 7th sync and ran again...
+
+The "list source" takes more than 15 minutes. It's bottlenecked on checking
+git ignores. Bottleneck that I didn't notice with a smaller
+number of files. Fixed that by making sure the export db was
+populated, which it usually is, but not in the 7th sync's situation.
+Now "list source" completes in less than 2 minutes.
+
+And.. after that, it was back to the tight futex() loop.. And this time I
+had intrumented the cidsdb, and it was importKeys
+calling getContentIdentifierKeys.
+
+Here's the kicker: It's only running getContentIdentifierKeys 15 times 
+per second. So that will take 166 minutes for all 150000 files.
+
+Each call to getContentIdentifierKeys is taking 0.05 seconds.
+So, this bug is back to the original problem of being bottlenecked on the
+cidsdb. And it is smelling like a lack of indexes. Yay!
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_1_41ca70e65a59d620cedc7cf46a8305fc._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_1_41ca70e65a59d620cedc7cf46a8305fc._comment
new file mode 100644
index 0000000000..067697755a
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_1_41ca70e65a59d620cedc7cf46a8305fc._comment
@@ -0,0 +1,257 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-05-30T17:53:48Z"
+ content="""
+Hm. I have tried to reproduce this with a git-annex instrumented to log
+each time it accesses the cidsdb. 
+
+I have not tried with the full 150k files, only with 10000, but have no
+reason to think it wouldn't have the same cidsbd access pattern with more
+files.
+
+What I found is, there was no access to the cidsdb after it finished the
+"import source" part of the sync.
+
+But, if I then run git-annex sync a second time, it behaves much more
+like you describe. It does not display "import source" for any files,
+because no files have changed. And it hits the cidsdb twice per file.
+Once is the necessary call to getContentIdentifierKeys, which is how it
+determines it's seen a file before and doesn't need to import it a second
+time. 
+
+The other hit is recordContentIdentifier, which happens for
+each recorded cid, due to updateFromLog. That seems unnecessary, because
+the previous sync already recorded all the cids.
+
+So I think a 2x speedup should be possible to repeated syncs when most of
+the files have not changed, but either I am missing something to reproduce
+your problem, or half the overhead is due to git-annex determining when it's
+already imported files before, which is unavoidable.
+
+Importing trees from special remotes is simply not going to be able to
+scale to huge numbers of files. Using a git repository is always gonna be
+able to perform better. (But of course hits its own scalability limits
+eventually.) This is a more general mechanism, and so many of
+the approaches git uses to speed up are not available.
+
+Here's the script I used.
+
+	#!/bin/sh
+	NFILES=$1
+	mkdir bench
+	cd bench
+	mkdir d
+	perl -e 'for(1..'$NFILES') { open(OUT,">", "d/f$_"); print OUT $_; close OUT }'
+	git init r
+	cd r
+	git config annex.thin true
+	git annex init 'local hub'
+	git annex wanted . "include=* and exclude=testdata/*"
+	touch mtree
+	git annex add mtree
+	git annex sync
+	git annex adjust --unlock-present
+	git annex initremote source type=directory directory=../d importtree=yes encryption=none
+	git annex enableremote source directory=../d
+	git config remote.source.annex-readonly true
+	git config remote.source.annex-tracking-branch master:testdata
+	git config annex.securehashesonly true
+	git config annex.genmetadata true
+	git config annex.diskreserve 100M
+	git annex sync
+	echo sync complete
+
+Here's the output when run with just 10 files, which shows that cidsdb
+access stops after it finishes "import source":
+
+	May 30 13:56:57 Initialized empty Git repository in /home/joey/tmp/bench/r/.git/
+	May 30 13:56:57 init local hub ok
+	May 30 13:56:57 (recording state in git...)
+	May 30 13:56:57 wanted . ok
+	May 30 13:56:57 (recording state in git...)
+	May 30 13:56:57 add mtree 
+	May 30 13:56:57 

ok
+	May 30 13:56:57 (recording state in git...)
+	May 30 13:56:57 commit  
+	May 30 13:56:57 [master (root-commit) 5ae9d8a] git-annex in local hub
+	May 30 13:56:57  1 file changed, 1 insertion(+)
+	May 30 13:56:57  create mode 120000 mtree
+	May 30 13:56:57 ok
+	May 30 13:56:57 adjust  
+	May 30 13:56:57 Switched to branch 'adjusted/master(unlockpresent)'
+	May 30 13:56:57 ok
+	May 30 13:56:58 initremote source ok
+	May 30 13:56:58 (recording state in git...)
+	May 30 13:56:58 enableremote source ok
+	May 30 13:56:58 (recording state in git...)
+	May 30 13:56:58 commit  
+	May 30 13:56:58 On branch adjusted/master(unlockpresent)
+	May 30 13:56:58 nothing to commit, working tree clean
+	May 30 13:56:58 ok
+	May 30 13:56:58 list source ok
+	May 30 13:56:58 "getAnnexBranchTree"
+	May 30 13:56:58 "updateFromLog"
+	May 30 13:56:58 "recordAnnexBranchTree"
+	May 30 13:56:58 ("getContentIdentifierKeys",ContentIdentifier "13243577 1 1685469417 098840021")
+	May 30 13:56:58 import source f1 
+	May 30 13:56:58 
100%  1 B               2 KiB/s 0s("recordContentIdentifier",MkKey {keyData = Key {keyName = "6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 1, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s1--6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b"})
+	May 30 13:56:58 
                                  
ok
+	May 30 13:56:58 ("getContentIdentifierKeys",ContentIdentifier "13285646 1 1685469417 098840021")
+	May 30 13:56:58 import source f8 
+	May 30 13:56:58 
100%  1 B               2 KiB/s 0s("recordContentIdentifier",MkKey {keyData = Key {keyName = "2c624232cdd221771294dfbb310aca000a0df6ac8b66b696d90ef06fdefb64a3", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 1, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s1--2c624232cdd221771294dfbb310aca000a0df6ac8b66b696d90ef06fdefb64a3"})
+	May 30 13:56:58 
                                  
ok
+	May 30 13:56:58 ("getContentIdentifierKeys",ContentIdentifier "13285641 1 1685469417 098840021")
+	May 30 13:56:58 import source f4 
+	May 30 13:56:58 
100%  1 B               3 KiB/s 0s("recordContentIdentifier",MkKey {keyData = Key {keyName = "4b227777d4dd1fc61c6f884f48641d02b4d121d3fd328cb08b5531fcacdabf8a", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 1, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s1--4b227777d4dd1fc61c6f884f48641d02b4d121d3fd328cb08b5531fcacdabf8a"})
+	May 30 13:56:58 
                                  
ok
+	May 30 13:56:58 ("getContentIdentifierKeys",ContentIdentifier "13285642 1 1685469417 098840021")
+	May 30 13:56:58 import source f5 
+	May 30 13:56:58 
100%  1 B               3 KiB/s 0s("recordContentIdentifier",MkKey {keyData = Key {keyName = "ef2d127de37b942baad06145e54b0c619a1f22327b2ebbcfbec78f5564afe39d", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 1, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s1--ef2d127de37b942baad06145e54b0c619a1f22327b2ebbcfbec78f5564afe39d"})
+	May 30 13:56:58 
                                  
ok
+	May 30 13:56:58 ("getContentIdentifierKeys",ContentIdentifier "13285648 2 1685469417 098840021")
+	May 30 13:56:58 import source f10 
+	May 30 13:56:58 
100%  2 B               6 KiB/s 0s("recordContentIdentifier",MkKey {keyData = Key {keyName = "4a44dc15364204a80fe80e9039455cc1608281820fe2b24f1e5233ade6af1dd5", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 2, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s2--4a44dc15364204a80fe80e9039455cc1608281820fe2b24f1e5233ade6af1dd5"})
+	May 30 13:56:58 
                                  
ok
+	May 30 13:56:58 ("getContentIdentifierKeys",ContentIdentifier "13285647 1 1685469417 098840021")
+	May 30 13:56:58 import source f9 
+	May 30 13:56:58 
100%  1 B               4 KiB/s 0s("recordContentIdentifier",MkKey {keyData = Key {keyName = "19581e27de7ced00ff1ce50b2047e7a567c76b1cbaebabe5ef03f7c3017bb5b7", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 1, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s1--19581e27de7ced00ff1ce50b2047e7a567c76b1cbaebabe5ef03f7c3017bb5b7"})
+	May 30 13:56:58 
                                  
ok
+	May 30 13:56:58 ("getContentIdentifierKeys",ContentIdentifier "13285640 1 1685469417 098840021")
+	May 30 13:56:58 import source f3 
+	May 30 13:56:58 
100%  1 B               5 KiB/s 0s("recordContentIdentifier",MkKey {keyData = Key {keyName = "4e07408562bedb8b60ce05c1decfe3ad16b72230967de01f640b7e4729b49fce", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 1, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s1--4e07408562bedb8b60ce05c1decfe3ad16b72230967de01f640b7e4729b49fce"})
+	May 30 13:56:58 
                                  
ok
+	May 30 13:56:58 ("getContentIdentifierKeys",ContentIdentifier "13285643 1 1685469417 098840021")
+	May 30 13:56:58 import source f6 
+	May 30 13:56:58 
100%  1 B               4 KiB/s 0s("recordContentIdentifier",MkKey {keyData = Key {keyName = "e7f6c011776e8db7cd330b54174fd76f7d0216b612387a5ffcfb81e6f0919683", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 1, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s1--e7f6c011776e8db7cd330b54174fd76f7d0216b612387a5ffcfb81e6f0919683"})
+	May 30 13:56:58 
                                  
ok
+	May 30 13:56:58 ("getContentIdentifierKeys",ContentIdentifier "13285644 1 1685469417 098840021")
+	May 30 13:56:58 import source f7 
+	May 30 13:56:58 
100%  1 B               4 KiB/s 0s("recordContentIdentifier",MkKey {keyData = Key {keyName = "7902699be42c8a8e46fbbb4501726517e86b22c56a189f7625a6da49081b2451", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 1, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s1--7902699be42c8a8e46fbbb4501726517e86b22c56a189f7625a6da49081b2451"})
+	May 30 13:56:58 
                                  
ok
+	May 30 13:56:58 ("getContentIdentifierKeys",ContentIdentifier "13285639 1 1685469417 098840021")
+	May 30 13:56:58 import source f2 
+	May 30 13:56:58 
100%  1 B               3 KiB/s 0s("recordContentIdentifier",MkKey {keyData = Key {keyName = "d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 1, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s1--d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35"})
+	May 30 13:56:58 
                                  
ok
+	May 30 13:56:58 update refs/remotes/source/master ok
+	May 30 13:56:58 (Merging into master...) 
+	May 30 13:56:58 Merge made by the 'ort' strategy.
+	May 30 13:56:58  testdata/f1  | 1 +
+	May 30 13:56:58  testdata/f10 | 1 +
+	May 30 13:56:58  testdata/f2  | 1 +
+	May 30 13:56:58  testdata/f3  | 1 +
+	May 30 13:56:58  testdata/f4  | 1 +
+	May 30 13:56:58  testdata/f5  | 1 +
+	May 30 13:56:58  testdata/f6  | 1 +
+	May 30 13:56:58  testdata/f7  | 1 +
+	May 30 13:56:58  testdata/f8  | 1 +
+	May 30 13:56:58  testdata/f9  | 1 +
+	May 30 13:56:58  10 files changed, 10 insertions(+)
+	May 30 13:56:58  create mode 120000 testdata/f1
+	May 30 13:56:58  create mode 120000 testdata/f10
+	May 30 13:56:58  create mode 120000 testdata/f2
+	May 30 13:56:58  create mode 120000 testdata/f3
+	May 30 13:56:58  create mode 120000 testdata/f4
+	May 30 13:56:58  create mode 120000 testdata/f5
+	May 30 13:56:58  create mode 120000 testdata/f6
+	May 30 13:56:58  create mode 120000 testdata/f7
+	May 30 13:56:58  create mode 120000 testdata/f8
+	May 30 13:56:58  create mode 120000 testdata/f9
+	May 30 13:56:58 (Merging into adjusted branch...) 
+	May 30 13:56:58 Updating ce828a9..f420a76
+	May 30 13:56:58 Fast-forward
+	May 30 13:56:58  testdata/f1  | 1 +
+	May 30 13:56:58  testdata/f10 | 1 +
+	May 30 13:56:58  testdata/f2  | 1 +
+	May 30 13:56:58  testdata/f3  | 1 +
+	May 30 13:56:58  testdata/f4  | 1 +
+	May 30 13:56:58  testdata/f5  | 1 +
+	May 30 13:56:58  testdata/f6  | 1 +
+	May 30 13:56:58  testdata/f7  | 1 +
+	May 30 13:56:58  testdata/f8  | 1 +
+	May 30 13:56:58  testdata/f9  | 1 +
+	May 30 13:56:58  10 files changed, 10 insertions(+)
+	May 30 13:56:58  create mode 120000 testdata/f1
+	May 30 13:56:58  create mode 120000 testdata/f10
+	May 30 13:56:58  create mode 120000 testdata/f2
+	May 30 13:56:58  create mode 120000 testdata/f3
+	May 30 13:56:58  create mode 120000 testdata/f4
+	May 30 13:56:58  create mode 120000 testdata/f5
+	May 30 13:56:58  create mode 120000 testdata/f6
+	May 30 13:56:58  create mode 120000 testdata/f7
+	May 30 13:56:58  create mode 120000 testdata/f8
+	May 30 13:56:58  create mode 120000 testdata/f9
+	May 30 13:56:59 (recording state in git...)
+
+Here's the patch I used for git-annex to instrument it:
+
+	diff --git a/Database/ContentIdentifier.hs b/Database/ContentIdentifier.hs
+	index e304dca58f..0d0dcdcdf1 100644
+	--- a/Database/ContentIdentifier.hs
+	+++ b/Database/ContentIdentifier.hs
+	@@ -109,11 +109,14 @@ flushDbQueue (ContentIdentifierHandle h) = H.flushDbQueue h
+	 
+	 -- Be sure to also update the git-annex branch when using this.
+	 recordContentIdentifier :: ContentIdentifierHandle -> RemoteStateHandle -> ContentIdentifier -> Key -> IO ()
+	-recordContentIdentifier h (RemoteStateHandle u) cid k = queueDb h $ do
+	-	void $ insertUniqueFast $ ContentIdentifiers u cid k
+	+recordContentIdentifier h (RemoteStateHandle u) cid k = do
+	+	liftIO $ hPutStrLn stderr $ show ("recordContentIdentifier", k)
+	+	queueDb h $ do
+	+		void $ insertUniqueFast $ ContentIdentifiers u cid k
+	 
+	 getContentIdentifiers :: ContentIdentifierHandle -> RemoteStateHandle -> Key -> IO [ContentIdentifier]
+	-getContentIdentifiers (ContentIdentifierHandle h) (RemoteStateHandle u) k = 
+	+getContentIdentifiers (ContentIdentifierHandle h) (RemoteStateHandle u) k = do
+	+	liftIO $ hPutStrLn stderr $ show ("getContentIdentifiers", k)
+	 	H.queryDbQueue h $ do
+	 		l <- selectList
+	 			[ ContentIdentifiersKey ==. k
+	@@ -122,7 +125,8 @@ getContentIdentifiers (ContentIdentifierHandle h) (RemoteStateHandle u) k =
+	 		return $ map (contentIdentifiersCid . entityVal) l
+	 
+	 getContentIdentifierKeys :: ContentIdentifierHandle -> RemoteStateHandle -> ContentIdentifier -> IO [Key]
+	-getContentIdentifierKeys (ContentIdentifierHandle h) (RemoteStateHandle u) cid = 
+	+getContentIdentifierKeys (ContentIdentifierHandle h) (RemoteStateHandle u) cid = do
+	+	liftIO $ hPutStrLn stderr $ show ("getContentIdentifierKeys", cid)
+	 	H.queryDbQueue h $ do
+	 		l <- selectList
+	 			[ ContentIdentifiersCid ==. cid
+	@@ -131,16 +135,20 @@ getContentIdentifierKeys (ContentIdentifierHandle h) (RemoteStateHandle u) cid =
+	 		return $ map (contentIdentifiersKey . entityVal) l
+	 
+	 recordAnnexBranchTree :: ContentIdentifierHandle -> Sha -> IO ()
+	-recordAnnexBranchTree h s = queueDb h $ do
+	-        deleteWhere ([] :: [Filter AnnexBranch])
+	-        void $ insertUniqueFast $ AnnexBranch $ toSSha s
+	+recordAnnexBranchTree h s = do
+	+	liftIO $ hPutStrLn stderr $ show ("recordAnnexBranchTree")
+	+	queueDb h $ do
+	+		deleteWhere ([] :: [Filter AnnexBranch])
+	+		void $ insertUniqueFast $ AnnexBranch $ toSSha s
+	 
+	 getAnnexBranchTree :: ContentIdentifierHandle -> IO Sha
+	-getAnnexBranchTree (ContentIdentifierHandle h) = H.queryDbQueue h $ do
+	-        l <- selectList ([] :: [Filter AnnexBranch]) []
+	-        case l of
+	-                (s:[]) -> return $ fromSSha $ annexBranchTree $ entityVal s
+	-                _ -> return emptyTree
+	+getAnnexBranchTree (ContentIdentifierHandle h) = do
+	+	liftIO $ hPutStrLn stderr $ show ("getAnnexBranchTree")
+	+	H.queryDbQueue h $ do
+	+		l <- selectList ([] :: [Filter AnnexBranch]) []
+	+		case l of
+	+			(s:[]) -> return $ fromSSha $ annexBranchTree $ entityVal s
+	+			_ -> return emptyTree
+	 
+	 {- Check if the git-annex branch has been updated and the database needs
+	  - to be updated with any new content identifiers in it. -}
+	@@ -155,6 +163,7 @@ needsUpdateFromLog db = do
+	 {- The database should be locked for write when calling this. -}
+	 updateFromLog :: ContentIdentifierHandle -> (Sha, Sha) -> Annex ()
+	 updateFromLog db (oldtree, currtree) = do
+	+	liftIO $ hPutStrLn stderr $ show ("updateFromLog")
+	 	(l, cleanup) <- inRepo $
+	 		DiffTree.diffTreeRecursive oldtree currtree
+	 	mapM_ go l
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_20_d6d3db42bda1fe094140d54a458157b1._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_20_d6d3db42bda1fe094140d54a458157b1._comment
new file mode 100644
index 0000000000..15a68b211b
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_20_d6d3db42bda1fe094140d54a458157b1._comment
@@ -0,0 +1,67 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 20"""
+ date="2023-06-09T16:01:06Z"
+ content="""
+The sqlite schema is:
+
+	CREATE TABLE IF NOT EXISTS "content_identifiers"("id" INTEGER
+	PRIMARY KEY,"remote" BLOB NOT NULL,"cid" BLOB NOT NULL,"key" BLOB
+	NOT NULL,CONSTRAINT "content_indentifiers_key_remote_cid_index"
+	UNIQUE ("key","remote","cid"));
+
+According to the sqlite docs:
+
+	In most cases, UNIQUE and PRIMARY KEY constraints are implemented by
+	creating a unique index in the database. (The exceptions are INTEGER
+	PRIMARY KEY and PRIMARY KEYs on WITHOUT ROWID tables.)
+	Hence, the following schemas are logically equivalent:
+	
+	    CREATE TABLE t1(a, b UNIQUE);
+	
+	    CREATE TABLE t1(a, b PRIMARY KEY);
+	
+	    CREATE TABLE t1(a, b);
+	    CREATE UNIQUE INDEX t1b ON t1(b); 
+
+But, that index is not used for a cid query:
+
+	sqlite> EXPLAIN QUERY PLAN SELECT key FROM content_identifiers WHERE cid = "foo";
+	QUERY PLAN
+	`--SCAN content_identifiers
+
+Aha, it does use the UNIQUE index for queries going the other way:
+
+	sqlite> EXPLAIN QUERY PLAN SELECT cid FROM content_identifiers WHERE key = "foo";
+	QUERY PLAN
+	`--SEARCH content_identifiers USING COVERING INDEX sqlite_autoindex_content_identifiers_1 (key=?)
+
+Even a query using the "remote" column seems to use the UNIQUE index:
+
+	sqlite> EXPLAIN QUERY PLAN SELECT cid FROM content_identifiers WHERE key = "foo" and remote = "bar";
+	QUERY PLAN
+	`--SEARCH content_identifiers USING COVERING INDEX sqlite_autoindex_content_identifiers_1 (key=? AND remote=?)
+
+Here's a thread on mastodon about this, with some ideas about why sqlite3 behaves this way.
+<https://octodon.social/@joeyh/110515161416516029>.
+Also, see this commit where I added a second index to a database, that was the same columns
+as an existing index, only in a different order, and it did speed up a query.
+[[!commit ca2a527e93ca22548983a7285fc6e0a892ca44a4]].
+Oh and there was a uniqueness constraint with the cid first, but it was broken and got removed
+in [[!commit c6e693b25de49d4d3b2fedb49ffb42f04f5fd544]]. So probably it got slower at that point
+(Dec 2020).
+
+So probably most other tables used by git-annex do have usable indexes, for
+most queries. But not this one. Gonna need to manually add an index.
+
+(Or possibly redo the schema to have `UNIQUE ("key","cid","remote")`, it may be
+that sqlite only creates an index for up to 2 columns or something like that.)
+
+	sqlite> CREATE INDEX idx_content_identifiers_cid on content_identifiers (cid);
+	sqlite> EXPLAIN QUERY PLAN SELECT key FROM content_identifiers WHERE cid = "foo";
+	QUERY PLAN
+	`--SEARCH content_identifiers USING INDEX idx_content_identifiers_cid (cid=?)
+
+After modifying the database this way, I re-ran the slow sync and it's now able
+to run getContentIdentifierKeys 2858 times a second. What an improvement!
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_21_9320fcfb8bd47d4ee547e81fb9e01f38._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_21_9320fcfb8bd47d4ee547e81fb9e01f38._comment
new file mode 100644
index 0000000000..4e81590c22
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_21_9320fcfb8bd47d4ee547e81fb9e01f38._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 21"""
+ date="2023-06-09T17:54:29Z"
+ content="""
+Here's the final timing from the second test case with 
+150000 files after all of the above optimisation:
+
+1. 0m0.131s
+2. 33m40.490s
+3. 0m41.027s
+4. 2m59.070s
+5. 14m5.679s
+6. 0m3.673s
+7. 17m39.271s
+8. 11m15.317s
+
+(git-annex get from an importtree remote was also sped up a lot;
+it makes the same cid queries as sync #7)
+
+I'm satisfied with this, considering this bug done, unless it's
+somehow still being slow for you.
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_22_333907125ccf24c2ad8286cd40a35b16._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_22_333907125ccf24c2ad8286cd40a35b16._comment
new file mode 100644
index 0000000000..89841e3b6b
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_22_333907125ccf24c2ad8286cd40a35b16._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 22"
+ date="2023-06-11T02:18:22Z"
+ content="""
+WOW!  That was it!
+
+I ran the index-creation command on my cidsdb/db, then reran git-annex sync - the very long one.  Down to 1m48s!  A HUGE improvement!
+
+Thanks Joey!
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_2_8f609e231fdf315d2b658d30d708d471._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_2_8f609e231fdf315d2b658d30d708d471._comment
new file mode 100644
index 0000000000..133b943ac0
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_2_8f609e231fdf315d2b658d30d708d471._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-05-30T18:49:34Z"
+ content="""
+> The other hit is recordContentIdentifier, which happens for
+> each recorded cid, due to updateFromLog. That seems unnecessary, because
+> the previous sync already recorded all the cids.
+
+I was able to eliminate that extra work. Now the first sync does not write
+to the cidsdb but only to the git-annex branch, and the second sync does
+the necessary work of updating the cidsdb from the git-annex branch.
+
+I'm not sure that extra work is what the bug reporter was complaining
+about though.
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_3_d54f2c81763b4119c881e283cff80d44._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_3_d54f2c81763b4119c881e283cff80d44._comment
new file mode 100644
index 0000000000..4ad5f9c730
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_3_d54f2c81763b4119c881e283cff80d44._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-05-30T19:25:11Z"
+ content="""
+See [[todo/speed_up_import_tree]] for a few ideas of things that would
+speed it up.
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_4_76fe32e5ecbf37b0f173de987c59e39f._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_4_76fe32e5ecbf37b0f173de987c59e39f._comment
new file mode 100644
index 0000000000..761b2d00fc
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_4_76fe32e5ecbf37b0f173de987c59e39f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 4"
+ date="2023-05-30T20:58:20Z"
+ content="""
+Hi Joey,
+
+Would it be helpful for you if I ran the instrumented version here?
+
+Also I suspect that the time spent reading cidsdb scales exponentially rather than linearly with the number of files.  Or perhaps there's a magic spot somewhere (an in-memory cache limit?) that causes the excessive time.  Anyhow, I'm happy to do whatever I can to help.
+
+Thanks!
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_5_512996afefabc75a0b2258fc05ccbfdd._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_5_512996afefabc75a0b2258fc05ccbfdd._comment
new file mode 100644
index 0000000000..ef285146db
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_5_512996afefabc75a0b2258fc05ccbfdd._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-06-01T17:47:31Z"
+ content="""
+As far as how reads from the cidsdb scale, I think that sqlite databases
+like this do slow down somewhat when tables get massive, but I don't really
+know the details. And it's of course possible that something could be
+improved in the schema or queries.
+
+I've been working on that todo I linked above, and the speed gain is
+impressive when there are few or no changed files in the remote. With 20,000
+unchanged files, re-running git-annex import[1] sped up from 125.95 to 3.84
+seconds. With 40,000 unchanged files, it sped up from 477 to 8.13 seconds. I
+haven't tried with 150000 files yet but the pattern is clear.
+
+> I can rerun the sync with an unchanged import directory.  It still takes
+> 107 minutes, the majority of which is spent reading cidsdb.  Only the
+> first minute or two are spent scanning the source area.
+
+Well, I think I've certianly solved that problem. But I don't know if there's
+something else that is making the initial sync slower than it needs to
+be.
+
+[1] More accurately, re-running it a second time, both to get a warm cache
+result, and because the first time, it is busy updating the cidsdb with
+the files that were imported earlier, as described in comment #2.
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_6_1b6ff858daf39dd84d4ef39a162ca914._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_6_1b6ff858daf39dd84d4ef39a162ca914._comment
new file mode 100644
index 0000000000..bfa6fa3625
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_6_1b6ff858daf39dd84d4ef39a162ca914._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 6"
+ date="2023-06-01T21:26:23Z"
+ content="""
+That's great news!  I will rerun my test against master and see what it does.
+
+If you happen to be able to point me at the sqlite queries that are being run, I could see if I could tease out any optimizations there.
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_6_b8b3eb5fff4ad3478dfbbd2120d4b00a._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_6_b8b3eb5fff4ad3478dfbbd2120d4b00a._comment
new file mode 100644
index 0000000000..3543623b2e
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_6_b8b3eb5fff4ad3478dfbbd2120d4b00a._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Results with 150000 files"""
+ date="2023-06-01T18:17:34Z"
+ content="""
+Initial sync: 39:01.37
+
+Then `git-annex import master:testdata --from source` 
+with no changed files: 8:36.30  
+(This is writing the cidsdb since the initial sync no 
+longer does, see comment #2)
+
+Subsequent imports with no changed files: 0:37.21
+
+Subsequent syncs with no changed files: 3:18.61
+
+Subsequent syncs with no changed files, when not on an adjusted branch: 0:38.40
+
+That 37 second run time for an import with no changed files seems to
+indicate that my optimisation so far was successful at eliminating all
+cidsdb reading. It's bottlenecked on git operations now.
+
+I also tried an initial import of 150000 files to see how much of that
+initial sync was other work than the import (updating adjusted branch,
+checking out files, etc).
+
+Initial import: 38:24.36
+
+So the initial sync is mostly spending time on imports, not other stuff.
+It could perhaps be sped up some. Of course it does support -J2 which may
+speed it up throuh parallism.
+
+Seems like a sync with no changed files on an adjusted branch is doing
+unncessary work to update the adjusted branch when nothing has changed.
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_8_1389db945973ed42b8ddd0de3cc8889c._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_8_1389db945973ed42b8ddd0de3cc8889c._comment
new file mode 100644
index 0000000000..e30e0932dc
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_8_1389db945973ed42b8ddd0de3cc8889c._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-06-02T15:25:12Z"
+ content="""
+@jgoerzen if you want to take a look at the sql, see
+`Database/ContentIdentifier.hs`. `getContentIdentifierKeys` is the query
+that it's running on each file. I'm not really sure right now if the 
+persistent schema in there actually creates an index that is used for that
+query. persistent's documentation of indexes is lacking and I may have
+misunderstood that uniqueness constraints result in indexes being created.
+
+Dumping the database shows this, which really doesn't seem to have an index
+after all:
+
+	CREATE TABLE IF NOT EXISTS "content_identifiers"("id" INTEGER
+	PRIMARY KEY,"remote" BLOB NOT NULL,"cid" BLOB NOT NULL,"key" BLOB
+	NOT NULL,CONSTRAINT "content_indentifiers_key_remote_cid_index"
+	UNIQUE ("key","remote","cid"));
+
+May need some raw sql to add it, like:
+	
+	CREATE INDEX cidindex ON "content_identifiers" ("cid");
+
+Also, I re-ran the 150000 file sync benchmark with `getContentIdentifierKeys` 
+disabled and it took 29:56.78, so 25% faster.
+
+That gives me the idea for an optimisation -- it could check if the
+database is empty at start and if so, avoid calling that at all. (It also
+maintains a map in memory which will still allow it to detect duplicate files.)
+Speeding up initial imports of a lot of files, but not later imports of a lot
+of files is kind of a cop out, but..
+"""]]
diff --git a/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_8_58155dba65976fd92cd212e13f87b888._comment b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_8_58155dba65976fd92cd212e13f87b888._comment
new file mode 100644
index 0000000000..9dc1abf12a
--- /dev/null
+++ b/doc/bugs/importtree_spends_hours_reading_cidsdb/comment_8_58155dba65976fd92cd212e13f87b888._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 8"
+ date="2023-06-02T03:25:27Z"
+ content="""
+I recompiled git-annex with the latest master, and I'm seeing the same behavior as before.
+
+I attached strace to the process for 10 seconds and ran some statistics:
+
+```
+wc -l /tmp/foo
+106710 /tmp/foo
+egrep 'pread64.14' /tmp/foo | wc -l
+103228
+```
+
+fd 14 corresponds to the db file.  These preads are all 4k, which matches the Sqlite page size on this database.
+
+There were about a dozen writes; they were to an `[eventfd]` fd.  I'm not sure what that is used for here.
+
+The rest were mainly calles to futex, reads from the timerfd 4, and epolls.
+
+If it were doing one pread64 per file, at a rate of roughly 10,000 per second, it should query for every file in about 15 seconds.  But as I write this, the process has used 84 minutes of CPU time.  Either it is making many queries for each file, or there is some pathology in sqlite causing the queries to explode into a vast number of individual reads.
+
+It seems to me there is some meaningful difference between my situation and yours.
+
+One thing I have noticed is that it is getting permission denied on about a dozen files out of the test set.  However, I don't believe this could have been the case with my original test set (consisting of about 150,000 photos).
+
+I am happy to do any kind of debugging I can that would be helpful.
+
+I note that the Sqlite default cache is about 2MB; I don't know if a larger cache may be helpful.  I suspect doing fewer syscalls may help, but the underlying problem of numerous queries would still exist.
+"""]]
diff --git a/doc/bugs/in_case_of___34__incomplete__34_____40__no_rmets__41___export_to_versioned_S3__44___fails_on_initial___96__get_-J__96___call__44___but_then___34__succeeds__34___on_subsequent.mdwn b/doc/bugs/in_case_of___34__incomplete__34_____40__no_rmets__41___export_to_versioned_S3__44___fails_on_initial___96__get_-J__96___call__44___but_then___34__succeeds__34___on_subsequent.mdwn
new file mode 100644
index 0000000000..b35f5b2dee
--- /dev/null
+++ b/doc/bugs/in_case_of___34__incomplete__34_____40__no_rmets__41___export_to_versioned_S3__44___fails_on_initial___96__get_-J__96___call__44___but_then___34__succeeds__34___on_subsequent.mdwn
@@ -0,0 +1,92 @@
+Not sure actually if anything could be done on git annex side, and I am still waiting for it to be fixed in the "source".  But since it succeeds in serial (no `-J 5`) mode (not shown here), I thought it might be something to look for to fixup in git-annex
+
+[[!format sh """
+$> git clone http://github.com/OpenNeuroDatasets/ds000201
+...
+$> cd ds000201
+$> git annex enableremote s3-PUBLIC
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+enableremote s3-PUBLIC ok
+(recording state in git...)
+
+$> git annex get -J5 code
+get code/convert_physio_files.py (from s3-PUBLIC...)
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+
+  unknown export location
+
+  Unable to access these remotes: s3-PUBLIC
+  
+  Try making some of these repositories available:
+        251a9a3d-4684-43b2-94d9-7079346f9a5b -- root@197dae0f1c68:/datalad/ds000201
+        d46236ce-1f9e-4216-9676-35f10fd6c553 -- [s3-PUBLIC]
+  
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+get code/convert_emb_dataset.R (from s3-PUBLIC...)
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  
+  unknown export location
+  
+  Unable to access these remotes: s3-PUBLIC
+  
+  Try making some of these repositories available:
+        251a9a3d-4684-43b2-94d9-7079346f9a5b -- root@197dae0f1c68:/datalad/ds000201
+        d46236ce-1f9e-4216-9676-35f10fd6c553 -- [s3-PUBLIC]
+  
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+...
+get code/plot_event_file.R (from s3-PUBLIC...)
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  
+  unknown export location
+  
+  Unable to access these remotes: s3-PUBLIC
+  
+  Try making some of these repositories available:
+        251a9a3d-4684-43b2-94d9-7079346f9a5b -- root@197dae0f1c68:/datalad/ds000201
+        d46236ce-1f9e-4216-9676-35f10fd6c553 -- [s3-PUBLIC]
+  
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+get code/create_mosaic_for_image_file.sh (from s3-PUBLIC...)
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+(recording state in git...)
+git-annex: get: 5 failed
+
+# and then "succeeds" on subsequent call since I guess load was already downloaded
+$> git annex get -J5 code
+get code/convert_edf_dataset.R (from s3-PUBLIC...)
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+get code/convert_emb_dataset.R (from s3-PUBLIC...)
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+get code/convert_physio_files.py (from s3-PUBLIC...)
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+get code/plot_event_file.R (from s3-PUBLIC...)
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+get code/BIDS_WalkerToGetScans.ipynb (from s3-PUBLIC...)
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+(recording state in git...)
+
+$> git annex version
+git-annex version: 7.20190322+git133-g59922f1f4-1~ndall+1
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 5
+"""]]
+
diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs.mdwn b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs.mdwn
new file mode 100644
index 0000000000..d111c58ccd
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+
+There appears to be some locking-related pain with git annex v10 on NFS.
+
+Specifically, git status, git annex status, and seemingly everything that uses git-annex filter-process will hang forever.
+
+### What steps will reproduce the problem?
+
+(approximately)
+```
+git init && git annex init --version 10
+(add some large file, commit)
+git annex sync
+git status # hangs forever
+git annex status # hangs forever
+git annex info # actually works, and produces typical output
+git diff path/to/normal-file.txt # also hangs
+git annex version # actually works, and produces typical output
+```
+
+### What version of git-annex are you using? On what operating system?
+
+Git annex installed from the latest standalone amd64 tarball. I verified that both `which git` and `which git-annex` point to the scripts/binaries in that tarball.
+
+```
+$ git annex version
+git-annex version: 10.20220725-g9ac72bff2
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+Running Ubuntu 20.04, with ~/ (where binaries are) and /workspaces (where the repo is) on NFS. `mount -v` shows the following (clipped and IPs obscured)
+
+```
+srv:/path on /workspaces type nfs4 (rw,noatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=XXXX,local_lock=none,addr=XXXX)           
+```
+
+.git/config contains (anonymised)
+```
+[annex]
+        uuid = UUID_HERE
+        version = 10
+        pidlock = true
+```
+
+
+### Please provide any additional information below.
+
+
+As a workaround, I deleted all files from .git/annex EXCEPT for the objects directory, then did `git annex init --version=9`, and reset the UUID to what it was before. I then ran git annex fsck, and it all seemed to function correctly with no hangs. But, a few commands later, I noticed we were back at version=10, and the problem recurred. I set `annex.autoupgraderepository = false`, again nuked .git/annex, set version=8 this time in the config file and with git annex init --version 8 and it seems were good and stable for now.
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+A great deal! We're managing tens of TB of plant genomics data with git annex, and it's a life saver, so many many thanks Joey et al. I know NFS is a bit of an edge case in git-annex land, but for the majority of git-annex's scientific users, NFS is all we have.
+
diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_1_be44453dee893cc99759f90e660c0a66._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_1_be44453dee893cc99759f90e660c0a66._comment
new file mode 100644
index 0000000000..91d49307d8
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_1_be44453dee893cc99759f90e660c0a66._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="comment 1"
+ date="2022-09-27T17:49:53Z"
+ content="""
+(many apologies, I buggered up the markdown formatting of the following section. Fixed below)
+
+### What steps will reproduce the problem?
+
+(approximately)
+
+```
+git init && git annex init --version 10
+(add some large file, commit)
+git annex sync
+git status # hangs forever
+git annex status # hangs forever
+git annex info # actually works, and produces typical output
+git diff path/to/normal-file.txt # also hangs
+git annex version # actually works, and produces typical output
+```
+
+"""]]
diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_2_e262ec0e438557b8d70a6adc50545ac1._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_2_e262ec0e438557b8d70a6adc50545ac1._comment
new file mode 100644
index 0000000000..b200189dbc
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_2_e262ec0e438557b8d70a6adc50545ac1._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-27T18:21:12Z"
+ content="""
+If filter-process is the problem, it does not make sense that repo v9
+v9 would not have the problem, because v9 enables filter-process.
+If v9 is ok and only v10 has the problem then it must have something to
+do with the locking changes in v10.
+
+Also, you can upgrade to v9/v10 and still disable git-annex filter-process,
+by running this after the upgrade:
+
+	git config --unset filter.annex.process
+
+(Note that git-annex had a bug that caused v9 to upgrade to v10
+without waiting the year it was supposed to. That bug is why your v9 repo
+upgraded. That was fixed in today's git-annex release.)
+"""]]
diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_c863d6940528fcc543815da44e7997d5._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_c863d6940528fcc543815da44e7997d5._comment
new file mode 100644
index 0000000000..cc71a56e3e
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_c863d6940528fcc543815da44e7997d5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="comment 3"
+ date="2022-09-27T18:40:40Z"
+ content="""
+Thanks for that Joey, I'll upgrade to today's release and let you know if the problem persists. Regarding filter-process, I think I was unclear: it stalls *during* filter-process, not *because of* filter-process. I gather filter-process gets stuck waiting for a lock. 
+"""]]
diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_4_d54eb28d30d91088de019b761a340fd3._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_4_d54eb28d30d91088de019b761a340fd3._comment
new file mode 100644
index 0000000000..3d0ae56df3
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_4_d54eb28d30d91088de019b761a340fd3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-09-27T18:54:32Z"
+ content="""
+FWIW, I don't see this problem in a v10 repo on ext4. I set annex.pidlock in
+case it being set somehow causes a locking problem.
+
+Try running this, in a repo where it hangs, to debug at what
+point in the git-annex filter-process it is hanging.
+
+	GIT_TRACE_PACKET=1 GIT_TRACE=1 git status
+
+Then try disabling filter-process and confirm if it hangs or not:
+
+	git config --unset filter.annex.process
+	git status
+"""]]
diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_5_6439cb8500ad225fc4ef43a18582b18a._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_5_6439cb8500ad225fc4ef43a18582b18a._comment
new file mode 100644
index 0000000000..1ffab986a0
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_5_6439cb8500ad225fc4ef43a18582b18a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="comment 5"
+ date="2022-09-28T12:55:49Z"
+ content="""
+So I think I have this issue completely wrong, apologies.
+
+
+The problem recurred again today, on a v8 repo, and with yesterday's release of git-annex. There is definitely a problem with locking, but it can't be due to the changes in version 10.
+
+To debug further, I removed only some files at a time from the .git/annex directory. The offending files were the keysdb (I did `rm -rf keysdb*`, so I'm not sure which of the specific files were the offenders).
+
+I'll keep you posted as I debug it further, but I thought I should let you know immediately that my original diagnosis was wrong.
+"""]]
diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_6_a959fa6cb5b4cda423b7e75aeec2eb1c._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_6_a959fa6cb5b4cda423b7e75aeec2eb1c._comment
new file mode 100644
index 0000000000..e0e05d74be
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_6_a959fa6cb5b4cda423b7e75aeec2eb1c._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-09-30T17:34:34Z"
+ content="""
+Thanks for confirming my feeling that something about the bug as reported
+was not quite right.
+
+It it was keysdb.cache or keysdb.lck, then it might be a locking problem in
+git-annex.
+
+But it seems more likely it was `keysdb/*`.. And that is a sqlite database.
+And if sqlite has problems with its internal locking that don't work on
+your filesystem, it would be hard to fix that in git-annex. Not using
+sqlite or switching the database from WAL mode to non-WAL mode are about
+all git-annex could do and both would be major undertakings.
+
+A recently added feature to git-annex is the annex.dbdir git config.
+That can be set to a directory on another filesystem, and git-annex will
+store all its sqlite databases in that directory. I think this option is
+your best chance of avoiding the problem.
+"""]]
diff --git a/doc/bugs/info_regression__58___exits_on_first_bad_path.mdwn b/doc/bugs/info_regression__58___exits_on_first_bad_path.mdwn
new file mode 100644
index 0000000000..73c880c766
--- /dev/null
+++ b/doc/bugs/info_regression__58___exits_on_first_bad_path.mdwn
@@ -0,0 +1,59 @@
+### Please describe the problem.
+
+Initially filed/expressed myself [on datalad issues](https://github.com/datalad/datalad/issues/7286#issuecomment-1434042685) but decided to duplicate here.
+
+Since git-annex [10.20230126-78-g452b080db AKA 10.20230214~12](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=452b080dba11f0d9d5251061acfc50729bf6f633)
+ (so rapidly released after introduction while datalad testing just got a chance to start breaking/me report): behavior change was not just about a nonzero exit but rather that git-annex no longer bothers to output any info for any file as soon as it encounters the path it doesn't know. 
+
+<details>
+<summary>In the case of untracked , completely wrong, and annexed file:</summary> 
+
+```shell
+❯ git status
+On branch dl-test-branch
+Your branch is up to date with 'dl-test-remote/dl-test-branch'.
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+	not-committed.txt
+
+nothing added to commit but untracked files present (use "git add" to track)
+❯ ls -l
+total 8
+-rw------- 1 yoh yoh   3 Feb 16 22:10 not-committed.txt
+lrwxrwxrwx 1 yoh yoh 186 Feb 16 22:10 test-annex.dat -> .git/annex/objects/Gm/mv/SHA256E-s7--ed7002b439e9ac845f22357d822bac1444730fbdb6016d3ec9432297b9ec9f73.dat/SHA256E-s7--ed7002b439e9ac845f22357d822bac1444730fbdb6016d3ec9432297b9ec9f73.dat
+
+```
+</details>
+
+ Compare behavior before:
+
+```shell
+❯ ( source ~/git-annexes/10.20230126.env; git annex version | head -n 1; git annex info --json --json-error-messages not-committed.txt INFO.txt test-annex.dat; echo exit $?)
+git-annex version: 10.20230126-1~ndall+1
+fatal: Not a valid object name not-committed.txt
+{"command":"info","note":"not a directory or an annexed file or a treeish or a remote or a uuid","success":false,"input":["not-committed.txt"],"error-messages":[],"file":"not-committed.txt"}
+fatal: Not a valid object name INFO.txt
+{"command":"info","note":"not a directory or an annexed file or a treeish or a remote or a uuid","success":false,"input":["INFO.txt"],"error-messages":[],"file":"INFO.txt"}
+{"command":"info test-annex.dat","size":"7 bytes","success":true,"input":["test-annex.dat"],"key":"SHA256E-s7--ed7002b439e9ac845f22357d822bac1444730fbdb6016d3ec9432297b9ec9f73.dat","error-messages":[],"present":false,"file":"test-annex.dat"}
+exit 0
+```
+
+where it did spit out errors to stderr but nevertheless trustfully returned json records for all files and eventually for the one it knows about (and we rely on such behavior!) to now
+
+```shell
+❯ ( source ~/git-annexes/10.20230214.env; git annex version | head -n 1; git annex info --json --json-error-messages not-committed.txt INFO.txt test-annex.dat ; echo exit $?)
+git-annex version: 10.20230214-1~ndall+1
+fatal: Not a valid object name not-committed.txt
+git-annex: not a directory or an annexed file or a treeish or a remote or a uuid
+exit 1
+```
+
+where we get only immediate error message to stderr and not a single record is output.
+
+IMHO prior behavior is "more correct" and we rely on it in datalad - get responses per each path. If it exits with non-0 after, that is ok with me. If it stops producing results completely, it would be an extra effort first sort out paths first.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/info_regression__58___exits_on_first_bad_path/comment_1_360a45c65c76e71c967afee1e3d355a1._comment b/doc/bugs/info_regression__58___exits_on_first_bad_path/comment_1_360a45c65c76e71c967afee1e3d355a1._comment
new file mode 100644
index 0000000000..ed5cb94cab
--- /dev/null
+++ b/doc/bugs/info_regression__58___exits_on_first_bad_path/comment_1_360a45c65c76e71c967afee1e3d355a1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-02-20T17:56:39Z"
+ content="""
+Fixed this. Note that with the fix, it will still exit nonzero at the end
+when given a path that does not exist, but it will first process the other
+inputs.
+
+Also I've added a test case.
+"""]]
diff --git a/doc/bugs/info_tries_to_scan_ignored_dirs_without_permission.mdwn b/doc/bugs/info_tries_to_scan_ignored_dirs_without_permission.mdwn
new file mode 100644
index 0000000000..cb60111696
--- /dev/null
+++ b/doc/bugs/info_tries_to_scan_ignored_dirs_without_permission.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+`git annex info` prints several warnings:
+
+```
+annexed files in working tree: warning: could not open directory '.Spotlight-V100/': Operation not permitted
+warning: could not open directory '.Trashes/': Operation not permitted
+warning: could not open directory '.fseventsd/': Permission denied
+```
+
+### What steps will reproduce the problem?
+
+1. Create an APFS volume on MacOS
+2. Initialize a git repo and annex in that volume dir (e.g. `/Volumes/my-annex`)
+3. Add a `.gitignore` as seen below
+4. `git annex info`
+
+.gitignore:
+
+```
+.Spotlight-V100
+.Trashes
+.fseventsd
+```
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20230407
+MacOS 12.6.2
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, lots! :)
diff --git a/doc/bugs/info_tries_to_scan_ignored_dirs_without_permission/comment_1_621066a2d1e8ff9f5edc41001dc4072f._comment b/doc/bugs/info_tries_to_scan_ignored_dirs_without_permission/comment_1_621066a2d1e8ff9f5edc41001dc4072f._comment
new file mode 100644
index 0000000000..addc457b44
--- /dev/null
+++ b/doc/bugs/info_tries_to_scan_ignored_dirs_without_permission/comment_1_621066a2d1e8ff9f5edc41001dc4072f._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-08-08T17:21:19Z"
+ content="""
+It's actually git that is displaying that message.
+Specifically `git ls-files --others`
+
+Note that command is specifically supposed to list files that have been
+gitignored. And unfortunately there's no way to get a similar list of
+files while honoring .gitignore.
+
+`git-annex add` behaves the same way, and obviously it does need to
+use `git ls-files --others` or some equivilant, since it needs a way to
+list untracked files.
+
+The reason why `git-annex info` does is because it reuses some code from
+`git-annex unused`. In the latter case, [[!commit 6fd2935a5af196d22e27c423acac67b5d79ea6a6]]
+gives a rationalle, to look for unstaged annex symlinks. That certianly makes
+sense for `git-annex unused`, because running `mv foo bar` on an annexed
+file shouldn't make the annex content be considered unused, unlike `rm foo`.
+
+And it also means that `git-annex info` knows about unstaged symlinks to
+annexed files, eg:
+
+	git init foo
+	cd foo
+	git-annex init
+	date > bar
+	git annex add
+	mv bar baz
+	git-annex unused
+	...
+	annexed files in working tree: 1
+
+So, while it would be possible to change `git annex info` to not behave
+this way, `git-annex unused` and `git-annex add` still would.
+
+So I'm inclinded not to change this. It would, I think be
+reasonable to talk to the git developers about whether git ls-files needs
+to display permission denied errors in this situation. Or perhaps there
+could be a mode added to ls-files that lists untracked files but honors
+gitignores.
+"""]]
diff --git a/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10.mdwn b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10.mdwn
new file mode 100644
index 0000000000..e2072e1287
--- /dev/null
+++ b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10.mdwn
@@ -0,0 +1,69 @@
+### Please describe the problem.
+
+Our [datalad tests started to fail](https://github.com/datalad/datalad/issues/6369) 2 days ago in [datalad/git-annex](https://github.com/datalad/git-annex/) .
+
+one relates to the fact that git-annex, if `init` is provided with `--version=6` would auto upgrade all the way to 10, not `8` which is the "default" version of annex:
+
+```
+lena:/tmp
+$> mkdir r && cd r && git init && git annex init --version=6 && git config annex.version
+hint: Using 'master' as the name for the initial branch. This default branch name
+hint: is subject to change. To configure the initial branch name to use in all
+hint: of your new repositories, which will suppress this warning, call:
+hint: 
+hint: 	git config --global init.defaultBranch <name>
+hint: 
+hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
+hint: 'development'. The just-created branch can be renamed via this command:
+hint: 
+hint: 	git branch -m <name>
+Initialized empty Git repository in /tmp/r/.git/
+init  ok
+(recording state in git...)
+10
+```
+
+<details>
+<summary>and it would stay at 8 if --version=8</summary> 
+
+```
+$> mkdir r && cd r && git init && git annex init --version=8 && git config annex.version
+hint: Using 'master' as the name for the initial branch. This default branch name
+hint: is subject to change. To configure the initial branch name to use in all
+hint: of your new repositories, which will suppress this warning, call:
+hint: 
+hint: 	git config --global init.defaultBranch <name>
+hint: 
+hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
+hint: 'development'. The just-created branch can be renamed via this command:
+hint: 
+hint: 	git branch -m <name>
+Initialized empty Git repository in /tmp/r/.git/
+init  ok
+(recording state in git...)
+8
+
+```
+</details>
+
+
+which makes it a bit odd. 
+
+Anyways -- thought to mention this and seek feedback so either git-annex adjusts its ways or we adjust our tests to expect annex auto-upgrade any non-default version to the highest one it supports.
+
+### What version of git-annex are you using? On what operating system?
+
+```
+$> git annex version
+git-annex version: 8.20211231+git126-gf7a3c1355-1~ndall+1
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+```
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_1_5b9ba56f682a991a57872d021f2ff08e._comment b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_1_5b9ba56f682a991a57872d021f2ff08e._comment
new file mode 100644
index 0000000000..3d0e73c52d
--- /dev/null
+++ b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_1_5b9ba56f682a991a57872d021f2ff08e._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-24T19:11:03Z"
+ content="""
+Hmm, the git-annex-upgrade man page says "Upgrades the repository to the latest version"
+and v10 is the latest version now. --version=8 will do what you want.
+I think that people would generally be surprised if `git-annex upgrade` did
+not upgrade to the latest supported version.
+
+As for `git-annex init --version=6`, v6 is not a supported version, so that
+was upgrading to v8 before. The git-annex-init man page says
+"When the version given is one that automatically upgrades to a newer
+version, it will automatically use the newer version instead."
+and v6 does automatically upgrade to v10 now, so again this behavior is
+following the documentation. Although so I suppose would be using v8 in the
+brief amount of time v10 is not upgraded to by default.
+"""]]
diff --git a/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_2_419bf4e6ebce4bcaae3afc6420da80b8._comment b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_2_419bf4e6ebce4bcaae3afc6420da80b8._comment
new file mode 100644
index 0000000000..47f4635f65
--- /dev/null
+++ b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_2_419bf4e6ebce4bcaae3afc6420da80b8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-01-25T17:42:32Z"
+ content="""
+Scratch that about `git-annex init --version`; v8 does not automatically
+upgrade to v10 yet, so why should v6? I agree that seems like a bug.
+
+fixed
+"""]]
diff --git a/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_3_425e81639f39d723b390d114a6d9e24b._comment b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_3_425e81639f39d723b390d114a6d9e24b._comment
new file mode 100644
index 0000000000..53a77b4c1e
--- /dev/null
+++ b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_3_425e81639f39d723b390d114a6d9e24b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2022-01-25T18:00:17Z"
+ content="""
+will next (10.?) release  support multiple (8 9 10) versions as it now states in \"supported repository versions:\" or 8 9 will become just \"upgradeable from\"?
+"""]]
diff --git a/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_4_a24860bb39cf920e34fac9ee6154b69e._comment b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_4_a24860bb39cf920e34fac9ee6154b69e._comment
new file mode 100644
index 0000000000..8bfc9b29bf
--- /dev/null
+++ b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_4_a24860bb39cf920e34fac9ee6154b69e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-01-25T18:02:16Z"
+ content="""
+v8 will remain supported for at least 1 year, probably a bit longer than
+that. And it will still be default in the next release, and probably next
+several releases on top of that.
+"""]]
diff --git a/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_5_3293f29b78d10aaf9254ddba1af6731d._comment b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_5_3293f29b78d10aaf9254ddba1af6731d._comment
new file mode 100644
index 0000000000..c4dbf5b443
--- /dev/null
+++ b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_5_3293f29b78d10aaf9254ddba1af6731d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2022-01-25T18:37:56Z"
+ content="""
+cool, so I think there is one missing (from documentation) notion of the \"default\" version (in addition to \"supported\", \"upgradeable\" and \"latest\" which is = max(\"supported\")). If so -- I think 
+- the \"default\" version should be listed in `git annex version` as \"default version:\" in addition to \"supported\" and \"upgradable\"
+- `git-annex-init` man page could say \"When the version given is older than default version, it will automatically use the newer default version instead.\"
+- may be `git-annex-upgrade` man page would say \"Upgrades the repository to a supported version.\", and allow for upgrade to `default` or `latest` (probably get `--version` option to specify which?) with \"default\" being the default version to upgrade to (thus staying consistent with git-annex-init upgrading to default, not latest)?
+
+I think that might make present difference between \"default\" and \"latest\" clearer.
+"""]]
diff --git a/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_6_f09aa0ebe68b5db72d466ae802ce20d5._comment b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_6_f09aa0ebe68b5db72d466ae802ce20d5._comment
new file mode 100644
index 0000000000..20c1f636c8
--- /dev/null
+++ b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_6_f09aa0ebe68b5db72d466ae802ce20d5._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-01-26T17:05:34Z"
+ content="""
+I think you are making this a lot more complex than it will appear to any
+user. These versions are almost indistinguishable by the user; v9 is
+literally one git config change from v8.
+
+And also, I reserve the right to make it do *anything that makes sense*
+around upgrades. Overspecifying the behavior will constrain future
+upgrades. Repository upgrades often already involve threading a very fine
+needle, making the hole artificially smaller does not seem wise.
+
+I suspect your test suite is unncessarily fragile around git-annex
+repository version numbers, perhaps that is the real root of your
+problem?
+"""]]
diff --git a/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_7_2d354e2c1fc2f1f6397fd89f71bf29ca._comment b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_7_2d354e2c1fc2f1f6397fd89f71bf29ca._comment
new file mode 100644
index 0000000000..187116d459
--- /dev/null
+++ b/doc/bugs/init__58___autoupgrade___60__8_annex_version_to_8_not_10/comment_7_2d354e2c1fc2f1f6397fd89f71bf29ca._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment regarding &quot;default&quot; version of the repo etc"
+ date="2022-01-26T18:40:50Z"
+ content="""
+> I think you are making this a lot more complex than it will appear to any user. These versions are almost indistinguishable by the user; v9 is literally one git config change from v8.
+
+well, to me as a user those upgrades become immediately visible whenever older (not yet supporting v9) version of git-annex tries to operate on v9 repository (regardless how trivial the change between 8 and 9 is).
+
+I recommended adding explicit \"default\" primarily because you cited man pages as the operational/design guide, and I felt that it is incomplete.
+
+> I suspect your test suite is unncessarily fragile around git-annex repository version numbers, perhaps that is the real root of your problem?
+
+might be... although I can proudly state that may be not -- we had only 2 (out of many 100s) tests failing, so at least that check seems to be quite nicely isolated in our tests.  And insofar seems have pointed to a defect in git-annex (they are all back to green, woohoo! ;) ). Having stated that -- we might indeed want to adjust them.
+
+"""]]
diff --git a/doc/bugs/init_fails_in_a_folder_with_newline_in_its_name.mdwn b/doc/bugs/init_fails_in_a_folder_with_newline_in_its_name.mdwn
new file mode 100644
index 0000000000..0a071a6357
--- /dev/null
+++ b/doc/bugs/init_fails_in_a_folder_with_newline_in_its_name.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+ref: [https://github.com/datalad/datalad/issues/7173#issuecomment-1314968568](https://github.com/datalad/datalad/issues/7173#issuecomment-1314968568)
+
+```
+❯ mkdir "/tmp/new
+dquote> line"
+❯ cd "/tmp/new
+line"
+❯ git init
+Initialized empty Git repository in /tmp/new
+line/.git/
+❯ git annex init
+init  ok
+fatal: Cannot open '/tmp/new': No such file or directory
+fatal: Cannot open '/tmp/new': No such file or directory
+fatal: Cannot open '/tmp/new': No such file or directory
+fatal: Cannot open '/tmp/new': No such file or directory
+fatal: Cannot open '/tmp/new': No such file or directory
+fatal: Cannot open '/tmp/new': No such file or directory
+fatal: Cannot open '/tmp/new': No such file or directory
+fatal: Cannot open '/tmp/new': No such file or directory
+fatal: Cannot open '/tmp/new': No such file or directory
+fatal: Cannot open '/tmp/new': No such file or directory
+fatal: Cannot open '/tmp/new': No such file or directory
+git-annex: fd:19: Data.ByteString.hGetLine: end of file
+
+❯ git annex version
+git-annex version: 10.20230214+git26-g8f2829e646-1~ndall+1
+```
+
+as `git` doesn't mind, and now annex batched commands support `-z` already for filenames with newlines in them, I think git-annex should tolerate repository folders with newlines in them too.
+
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/init_fails_in_a_folder_with_newline_in_its_name/comment_1_2690ed9441685068c291a182d39c2616._comment b/doc/bugs/init_fails_in_a_folder_with_newline_in_its_name/comment_1_2690ed9441685068c291a182d39c2616._comment
new file mode 100644
index 0000000000..284eea755d
--- /dev/null
+++ b/doc/bugs/init_fails_in_a_folder_with_newline_in_its_name/comment_1_2690ed9441685068c291a182d39c2616._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-13T16:20:54Z"
+ content="""
+Unfortunately, `git hash-object --stdin-paths` does not support
+-z or anything like that. It is a newline based protocol.
+
+Ok, made git-annex fall back to running git hash-object once
+per file when the filenames contain newlines to work around that.
+
+BTW, another problem I noticed is that the repository decription
+written to uuid.log contains a newline, which prevents parsing that line of
+the log correctly. This can also be seen by passing a value
+with a newline to `git-annex describe`. It would also happen in the
+case with the newline directory if it didn't fail earlier.
+
+Also fixed this, though, with a one-way escaping, 
+see [[!commit 38e9ea8497bb2ab058e5bd46a666857789c0a84d]].
+"""]]
diff --git a/doc/bugs/introduction_of_aws-0.23_causes_stack_bld_to_fail.mdwn b/doc/bugs/introduction_of_aws-0.23_causes_stack_bld_to_fail.mdwn
new file mode 100644
index 0000000000..6f31c3303e
--- /dev/null
+++ b/doc/bugs/introduction_of_aws-0.23_causes_stack_bld_to_fail.mdwn
@@ -0,0 +1,53 @@
+### Please describe the problem.
+
+After aws-0.23 was introduced into extra-deps of `stack.yaml`, a stack build fails
+in the dependency resolution phase (a plan construction problem). Adding `aeson-2.1.1.0`
+into extra-deps as advised leads to a dependency hell with conflicting versions of
+attoparsec being required amongst other troubles.
+
+### What steps will reproduce the problem?
+
+`stack setup && stack build`. Observe the following output:
+
+[[!format sh """
+Error: While constructing the build plan, the following exceptions were encountered:
+
+In the dependencies for aws-0.23:
+    aeson-1.5.6.0 from stack configuration does not match >=2.0.0.0  (latest matching version
+                  is 2.1.1.0)
+needed due to git-annex-10.20221103 -> aws-0.23
+
+Some different approaches to resolving this:
+
+  * Set 'allow-newer: true'
+    in C:\hs-stack\config.yaml to ignore all version constraints and build anyway.
+
+  * Recommended action: try adding the following to your extra-deps
+    in C:\Projektit\git-annex.branchable.com\git-annex--BUILD-221108-4f6c6114f\stack.yaml:
+
+- aeson-2.1.1.0@sha256:103ceb1421cd0ffa810bfb1acb1261d60addbde1a041fb5cce0056ff7d7dcdc2,5980
+
+Plan construction failed.
+# End of transcript or log.
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+I was trying to build master or [[!commit 4f6c6114fb487b5f84aa7e6922786b0e19806525]], but alas no luck.
+
+Windows 10 version 22H2 (build 19045.2130), 64 bit.
+
+Stack version 2.9.1, Git revision 409d56031b4240221d656db09b2ba476fe6bb5b1 x86_64 hpack-0.35.0 .
+
+### Please provide any additional information below.
+
+.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sure, I use it several times a week with my multigigabyte backups, where it gives structure to my image-based backup routines, so you could say I'm a believer. :)
+
+[[!meta author=jkniiv]]
+[[!meta title="introduction of aws-0.23 causes stack build to fail"]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/keeps_demanding_ssh_key_even_if_all_sync__39__s_turned_down.mdwn b/doc/bugs/keeps_demanding_ssh_key_even_if_all_sync__39__s_turned_down.mdwn
new file mode 100644
index 0000000000..adeb531e1a
--- /dev/null
+++ b/doc/bugs/keeps_demanding_ssh_key_even_if_all_sync__39__s_turned_down.mdwn
@@ -0,0 +1,60 @@
+### Please describe the problem.
+
+May be I was simply wrong to assume that if I disable all sync'ing for all the repos, assistant wouldn't try to contact those remote hosts. But it still does
+
+In the logs, since no time stamp per each line, hard to say either recent ones just continuation of previous entries, or new ones:
+
+[[
+
+[2015-05-18 10:29:39 EDT] Watcher: Performing startup scan
+(started...) ssh: connect to host vagus.cns.dartmouth.edu port 22: No route to host^M
+ssh: connect to host vagus.cns.dartmouth.edu port 22: No route to host^M
+ssh: connect to host vagus.cns.dartmouth.edu port 22: No route to host^M
+ssh: connect to host vagus.cns.dartmouth.edu port 22: No route to host^M
+ssh: connect to host vagus.cns.dartmouth.edu port 22: No route to host^M
+ssh: connect to host vagus.cns.dartmouth.edu port 22: No route to host^M
+...
+]]
+
+and in another
+
+[[
+fsck xppaut_6.11b+1.dfsg.orig.tar.gz ok
+fsck xserver-xorg-input-synaptics_1.6.2+git44-ge28575b.orig.tar.gz ok
+fsck xserver-xorg-video-intel_2.99.917.orig.tar.gz (checksum...)
+ok
+(recording state in git...)
+  ** No known copies exist of python-mne_0.8.3+dfsg.orig.tar.gz
+git-annex: fsck: 1 failed
+
+(process:3954): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+Write failed: Broken pipe^M
+
+(process:20140): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+
+(process:20178): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+git-annex: Daemon is already running.
+
+(process:29035): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+
+(process:29184): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+
+(process:30127): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+
+(process:30817): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+Write failed: Broken pipe^M
+]]
+
+that host (vagus) is RIP (need to remove from syncs)
+btw which are falling into daemon.log.1 not .log
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150509+gitga10e45d-1~ndall+1
diff --git a/doc/bugs/keeps_demanding_ssh_key_even_if_all_sync__39__s_turned_down/comment_1_e4b110f61502b5d37117ec65ec39896b._comment b/doc/bugs/keeps_demanding_ssh_key_even_if_all_sync__39__s_turned_down/comment_1_e4b110f61502b5d37117ec65ec39896b._comment
new file mode 100644
index 0000000000..faaa831ddc
--- /dev/null
+++ b/doc/bugs/keeps_demanding_ssh_key_even_if_all_sync__39__s_turned_down/comment_1_e4b110f61502b5d37117ec65ec39896b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-06T20:03:32Z"
+ content="""
+I'm having a hard time following what you're trying to say here.
+
+What is the bad behavior you are seeing? How does the fsck output you
+posted relate the the problem? What git remotes are configured? What is the
+contents of your .git/config? How did you disable the vagus repository?
+Have you restarted the assistant after disabling it?
+"""]]
diff --git a/doc/bugs/leaves_many_stray_processes_on_remote_server.mdwn b/doc/bugs/leaves_many_stray_processes_on_remote_server.mdwn
new file mode 100644
index 0000000000..4bad284ba8
--- /dev/null
+++ b/doc/bugs/leaves_many_stray_processes_on_remote_server.mdwn
@@ -0,0 +1,240 @@
+### Please describe the problem.
+
+git-annex leaves many stray processes around on a remote SSH server.
+
+### What steps will reproduce the problem?
+
+I'm not exactly sure, to be honest. I have setup a user for a friend on my home server with the following SSH key:
+
+    command="git-annex-shell -c \"$SSH_ORIGINAL_COMMAND\"",restrict ssh-rsa AAAAB[...]
+
+They use that access to synchronize a repository in `/srv/media` which is read-only for them, thanks to simple file permissions (files are owned by another user and another group).
+
+The friend uses the assistant to see progress of their transfers and regularly keep their local copy up to date. I suspect what is happening is the assistant is trying to *push* local changes to the remote server, and fails to do so.
+
+### What version of git-annex are you using? On what operating system?
+
+The remote git-annex client is, I believe, the `6.20170101-1+deb9u2` version shipped in Debian stable. The server is running 7.20190122-1~bpo9+1 on Debian stretch.
+
+### Please provide any additional information below.
+
+Here's a dump of the stray processes:
+
+[[!format sh """
+# ps axfu | grep friend
+root      8493  0.0  0.0 114176  7272 ?        Ss   12:24   0:00  \_ sshd: friend [priv]
+friend    8502  0.0  0.0 114360  4536 ?        S    12:24   0:00  |   \_ sshd: friend@notty
+friend    8511  0.0  0.0 1074101432 7760 ?     Ssl  12:24   0:00  |       \_ git-annex-shell -c git-receive-pack '/srv/media'
+friend    8520  0.0  0.0  39356  3248 ?        Sl   12:24   0:00  |           \_ git receive-pack /srv/media
+root     16282  0.0  0.0 114176  7240 ?        Ss   12:51   0:00  \_ sshd: friend [priv]
+friend   16291  0.0  0.0 115036  5292 ?        S    12:51   0:00  |   \_ sshd: friend@notty
+friend   16298  0.0  0.0 1074101432 7792 ?     Ssl  12:51   0:00  |       \_ git-annex-shell -c git-receive-pack '/srv/media'
+friend   16302  0.0  0.0  39356  3280 ?        Sl   12:51   0:00  |       |   \_ git receive-pack /srv/media
+friend   16312  0.0  0.0 1074101432 7720 ?     Ssl  12:52   0:00  |       \_ git-annex-shell -c git-receive-pack '/srv/media'
+friend   16317  0.0  0.0  39356  3276 ?        Sl   12:52   0:00  |       |   \_ git receive-pack /srv/media
+friend   16324  0.0  0.0 1074101432 7828 ?     Ssl  12:52   0:00  |       \_ git-annex-shell -c git-receive-pack '/srv/media'
+friend   16328  0.0  0.0  39356  3336 ?        Sl   12:52   0:00  |       |   \_ git receive-pack /srv/media
+friend   20296  0.0  0.0 1074101432 7680 ?     Ssl  13:06   0:00  |       \_ git-annex-shell -c git-receive-pack '/srv/media'
+friend   20300  0.0  0.0  39356  3260 ?        Sl   13:06   0:00  |           \_ git receive-pack /srv/media
+root     32041  0.0  0.0  14004   972 pts/5    S+   13:49   0:00      \_ grep friend
+friend   25870  0.0  0.0  65116  4560 ?        Ss   fév02   0:00 /lib/systemd/systemd --user
+friend   25874  0.0  0.0 244548   720 ?        S    fév02   0:00  \_ (sd-pam)
+friend   25952  0.0  0.0 1074101432 2088 ?     Ssl  fév02   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   25956  0.0  0.0  39172   564 ?        Sl   fév02   0:00  \_ git receive-pack /srv/media
+friend   26062  0.0  0.0 1074101432 2196 ?     Ssl  fév02   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   26066  0.0  0.0  39172   548 ?        Sl   fév02   0:00  \_ git receive-pack /srv/media
+friend   29069  0.0  0.0 1074101432 2188 ?     Ssl  fév02   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   29073  0.0  0.0  39172   608 ?        Sl   fév02   0:00  \_ git receive-pack /srv/media
+friend   30475  0.0  0.0 1074101432 2140 ?     Ssl  fév02   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   30488  0.0  0.0  39172   568 ?        Sl   fév02   0:00  \_ git receive-pack /srv/media
+friend   30476  0.0  0.0 1074101432 2196 ?     Ssl  fév02   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   30492  0.0  0.0  39172   780 ?        Sl   fév02   0:00  \_ git receive-pack /srv/media
+friend   30477  0.0  0.0 1074101432 2244 ?     Ssl  fév02   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   30485  0.0  0.0  39172   544 ?        Sl   fév02   0:00  \_ git receive-pack /srv/media
+friend   30478  0.0  0.0 1074101432 2140 ?     Ssl  fév02   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   30495  0.0  0.0  39172   740 ?        Sl   fév02   0:00  \_ git receive-pack /srv/media
+friend   30499  0.0  0.0 1074101432 2220 ?     Ssl  fév02   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   30503  0.0  0.0  39172   628 ?        Sl   fév02   0:00  \_ git receive-pack /srv/media
+friend   30505  0.0  0.0 1074101432 2096 ?     Ssl  fév02   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   30510  0.0  0.0  39172   588 ?        Sl   fév02   0:00  \_ git receive-pack /srv/media
+friend   30506  0.0  0.0 1074101432 2140 ?     Ssl  fév02   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   30514  0.0  0.0  39172   728 ?        Sl   fév02   0:00  \_ git receive-pack /srv/media
+friend   30546  0.0  0.0 1074101432 2076 ?     Ssl  fév02   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   30550  0.0  0.0  39172   588 ?        Sl   fév02   0:00  \_ git receive-pack /srv/media
+friend   16664  0.0  0.0 1074101432 2144 ?     Ssl  fév02   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   16668  0.0  0.0  39172   756 ?        Sl   fév02   0:00  \_ git receive-pack /srv/media
+friend    5225  0.0  0.0 1074101432 2520 ?     Ssl  fév03   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    5229  0.0  0.0  39324   904 ?        Sl   fév03   0:00  \_ git receive-pack /srv/media
+friend   25302  0.0  0.0 1074101432 2256 ?     Ssl  fév03   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   25337  0.0  0.0  39356   328 ?        Sl   fév03   0:00  \_ git receive-pack /srv/media
+friend   25304  0.0  0.0 1074101432 2408 ?     Ssl  fév03   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   25342  0.0  0.0  39356   376 ?        Sl   fév03   0:00  \_ git receive-pack /srv/media
+friend   25305  0.0  0.0 1074101432 2248 ?     Ssl  fév03   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   25336  0.0  0.0  39356   340 ?        Sl   fév03   0:00  \_ git receive-pack /srv/media
+friend   25307  0.0  0.0 1074101432 2432 ?     Ssl  fév03   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   25341  0.0  0.0  39356   364 ?        Sl   fév03   0:00  \_ git receive-pack /srv/media
+friend   25362  0.0  0.0 1074101432 2392 ?     Ssl  fév03   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   25366  0.0  0.0  39356   400 ?        Sl   fév03   0:00  \_ git receive-pack /srv/media
+friend   25386  0.0  0.0 1074101432 2136 ?     Ssl  fév03   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   25399  0.0  0.0  39356   564 ?        Sl   fév03   0:00  \_ git receive-pack /srv/media
+friend   25387  0.0  0.0 1074101432 2440 ?     Ssl  fév03   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   25400  0.0  0.0  39356   500 ?        Sl   fév03   0:00  \_ git receive-pack /srv/media
+friend   25388  0.0  0.0 1074101432 2136 ?     Ssl  fév03   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   25394  0.0  0.0  39356   420 ?        Sl   fév03   0:00  \_ git receive-pack /srv/media
+friend    1181  0.0  0.0 1074101432 2308 ?     Ssl  fév03   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    1186  0.0  0.0  39356   380 ?        Sl   fév03   0:00  \_ git receive-pack /srv/media
+friend    6483  0.0  0.0 1074101432 2336 ?     Ssl  fév03   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    6487  0.0  0.0  39356   436 ?        Sl   fév03   0:00  \_ git receive-pack /srv/media
+friend    9714  0.0  0.0 1074101432 2340 ?     Ssl  fév03   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    9718  0.0  0.0  39356   360 ?        Sl   fév03   0:00  \_ git receive-pack /srv/media
+friend    9117  0.0  0.0 1074101432 2392 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    9121  0.0  0.0  39356   536 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   13542  0.0  0.0 1074101432 2264 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   13558  0.0  0.0  39356   436 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   13543  0.0  0.0 1074101432 2328 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   13553  0.0  0.0  39356   532 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   13544  0.0  0.0 1074101432 2272 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   13561  0.0  0.0  39356   540 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   13545  0.0  0.0 1074101432 2380 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   13560  0.0  0.0  39356   592 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend    1940  0.0  0.0 1074101432 2264 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    1944  0.0  0.0  39356   468 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend    8515  0.0  0.0 1074101432 2348 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    8519  0.0  0.0  39356   520 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   11968  0.0  0.0 1074101432 2424 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   11972  0.0  0.0  39356   640 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   24944  0.0  0.0 1074101432 2264 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   24948  0.0  0.0  39356   504 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   25327  0.0  0.0 1074101432 2416 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   25335  0.0  0.0  39356   668 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   10241  0.0  0.0 1074101432 2272 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   10245  0.0  0.0  39356   552 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   15442  0.0  0.0 1074101432 2272 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   15446  0.0  0.0  39356   524 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   16915  0.0  0.0 1074101432 2248 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   16919  0.0  0.0  39356   592 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   29211  0.0  0.0 1074101432 2420 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   29215  0.0  0.0  39356   552 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend    1623  0.0  0.0 1074101432 2220 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    1630  0.0  0.0  39356   312 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend    1624  0.0  0.0 1074101432 2360 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    1632  0.0  0.0  39356   268 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   11255  0.0  0.0 1074101432 2312 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   11259  0.0  0.0  39356   340 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   29421  0.0  0.0 1074101432 2424 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   29425  0.0  0.0  39356   260 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend    8089  0.0  0.0 1074101432 2220 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    8100  0.0  0.0  39356   372 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend    8090  0.0  0.0 1074101432 2024 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    8101  0.0  0.0  39356   432 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend    8091  0.0  0.0 1074101432 2048 ?     Ssl  fév04   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    8103  0.0  0.0  39356   500 ?        Sl   fév04   0:00  \_ git receive-pack /srv/media
+friend   32567  0.0  0.0 1074101432 2680 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   32571  0.0  0.0  39356   588 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend    3556  0.0  0.0 1074101432 2672 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    3561  0.0  0.0  39356   632 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend    3557  0.0  0.0 1074101432 2688 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    3565  0.0  0.0  39356   656 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend    3566  0.0  0.0 1074101432 2816 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    3578  0.0  0.0  39356   680 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend    3567  0.0  0.0 1074101432 2656 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    3577  0.0  0.0  39356   916 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend    3587  0.0  0.0 1074101432 2880 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    3591  0.0  0.0  39356   956 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   14117  0.0  0.0 1074101432 3444 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   14121  0.0  0.0  39356   984 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   20449  0.0  0.0 1074101432 3464 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   20453  0.0  0.0  39356   888 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   20469  0.0  0.0 1074101432 3528 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   20480  0.0  0.0  39356   904 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   20483  0.0  0.0 1074101432 3140 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   20492  0.0  0.0  39356  1056 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   20484  0.0  0.0 1074101432 3168 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   20491  0.0  0.0  39356  1040 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   20498  0.0  0.0 1074101432 3348 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   20502  0.0  0.0  39356   848 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   32112  0.0  0.0 1074101432 3360 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   32116  0.0  0.0  39356   768 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   28244  0.0  0.0 1074101432 3452 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   28248  0.0  0.0  39356   936 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   28266  0.0  0.0 1074101432 3352 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   28276  0.0  0.0  39356   976 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   28267  0.0  0.0 1074101432 3332 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   28273  0.0  0.0  39356  1016 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   28284  0.0  0.0 1074101432 3388 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   28289  0.0  0.0  39356   900 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   28285  0.0  0.0 1074101432 3328 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   28293  0.0  0.0  39356   748 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   31816  0.0  0.0 1074101432 3384 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   31827  0.0  0.0  39356   852 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   31822  0.0  0.0 1074101432 2612 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   31835  0.0  0.0  39356   780 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   31823  0.0  0.0 1074101432 2496 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   31832  0.0  0.0  39356   748 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   31842  0.0  0.0 1074101432 3272 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   31846  0.0  0.0  39356   964 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend    9226  0.0  0.0 1074101432 3416 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    9230  0.0  0.0  39356   508 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   13564  0.0  0.0 1074101432 3456 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   13568  0.0  0.0  39356   708 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend    4424  0.0  0.0 1074101432 3348 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    4433  0.0  0.0  39356   788 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend    4425  0.0  0.0 1074101432 3500 ?     Ssl  fév05   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend    4432  0.0  0.0  39356   664 ?        Sl   fév05   0:00  \_ git receive-pack /srv/media
+friend   12235  0.0  0.0 1074101432 7784 ?     Ssl  08:37   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   12239  0.0  0.0  39356  3172 ?        Sl   08:37   0:00  \_ git receive-pack /srv/media
+friend   15636  0.0  0.0 1074101432 7600 ?     Ssl  08:50   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   15640  0.0  0.0  39356  3248 ?        Sl   08:50   0:00  \_ git receive-pack /srv/media
+friend   17626  0.0  0.0 1074101432 7560 ?     Ssl  09:00   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   17638  0.0  0.0  39356  3232 ?        Sl   09:00   0:00  \_ git receive-pack /srv/media
+friend   17628  0.0  0.0 1074101432 7660 ?     Ssl  09:00   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   17633  0.0  0.0  39356  3240 ?        Sl   09:00   0:00  \_ git receive-pack /srv/media
+friend   20252  0.0  0.0 1074101432 7820 ?     Ssl  11:10   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   20258  0.0  0.0  39356  3228 ?        Sl   11:10   0:00  \_ git receive-pack /srv/media
+friend   20253  0.0  0.0 1074101432 7884 ?     Ssl  11:10   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   20263  0.0  0.0  39356  3320 ?        Sl   11:10   0:00  \_ git receive-pack /srv/media
+friend   20287  0.0  0.0 1074101432 7684 ?     Ssl  11:10   0:00 git-annex-shell -c git-receive-pack '/srv/media'
+friend   20291  0.0  0.0  39356  3224 ?        Sl   11:10   0:00  \_ git receive-pack /srv/media
+"""]]
+
+Notice how many processes are orphaned there: they are not owned by
+any process and will seemingly never terminate. They are fairly
+harmless as I do not believe they are holding a lock (they can't: the
+repo is readonly) and will probably get swapped to disk. But
+eventually they *will* overrun even the swap if I wait long enough. :)
+I can kill the processes, but then it means I might kill a running
+transfer which is too bad - it's hard to tell which of those processes
+are valid.
+
+I have also seen such behavior when *I* connect to my remote SSH
+server but switch networks (say between wired and wireless) on my
+laptop: the SSH process would hang on the older connection and the
+sshd-managed process would keep a lock on the repository, keeping me
+from making further connections to the repository. I'd then have to
+login to the server and kill those pesky git-annex process to resume
+my work.
+
+I've seen this behavior with more recent versions in buster, so I
+doubt this problem is fixed in later versions. I'm also unsure it's
+git-annex's fault, to be fair: we might want SSH to fail earlier here
+which would make git-annex recover. But then on the other hand, we
+often *like* SSH to hang on through network failure and recover when
+the network comes back...
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I have, of course. :) You'd be happy to know this attempt at making
+this friend use git-annex is proving more successful than last time
+(the now deleted [[bugs/flooding_me_with_ssh_password_prompts]] which
+led to the also deleted [[bugs/kill_git-annex_assistant_on_logout]]),
+mainly because I got my head out of my figurative bottom and properly
+configured SSH to never ever prompt for passwords. What we're seeing
+now is a different problem than the original flood of passwords, of
+course, but it might be related to the latter bug.
+
+In general, the user is quite happy about git-annex now that they
+understood how to fetch files through their file manager and see
+progress through the GUI. I'm similarly happy to have less
+hand-holding to do myself. :)
+
+Thanks again for your great work! -- [[anarcat]]
diff --git a/doc/bugs/leaves_many_stray_processes_on_remote_server/comment_1_b66015587ccd3ca81de52271979bd026._comment b/doc/bugs/leaves_many_stray_processes_on_remote_server/comment_1_b66015587ccd3ca81de52271979bd026._comment
new file mode 100644
index 0000000000..17d8ecb47c
--- /dev/null
+++ b/doc/bugs/leaves_many_stray_processes_on_remote_server/comment_1_b66015587ccd3ca81de52271979bd026._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-02-07T19:58:58Z"
+ content="""
+There is not much git-annex involved here; git receive-pack is being run in the
+usual way by a git push, and git-annex-shell only forks off a git-shell to
+handle it in the usual way.
+
+If you change the ssh command to git-shell then git-annex would be out of
+the picture, and so you could then tell if git-annex is somehow involved in
+the problem at all on the server.
+
+But I think that upgrading the client is the first step, or checking to
+see if it has corresponding git processes that are keeping those git
+receive-pack's going.
+
+It could be that the client is losing connection with the server in a way
+that doesn't cause the TCP connection to be closed on the server, and so it
+waits around for whatever TCP timeout might eventually close it.
+"""]]
diff --git a/doc/bugs/leaves_many_stray_processes_on_remote_server/comment_2_4f417206d5d83bd456c8e501ae272cba._comment b/doc/bugs/leaves_many_stray_processes_on_remote_server/comment_2_4f417206d5d83bd456c8e501ae272cba._comment
new file mode 100644
index 0000000000..279605be7e
--- /dev/null
+++ b/doc/bugs/leaves_many_stray_processes_on_remote_server/comment_2_4f417206d5d83bd456c8e501ae272cba._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="comment 2"
+ date="2019-02-07T21:10:19Z"
+ content="""
+you'll notice that some of those processes have been hanging out there for days. i believe the TCP sockets are long gone, at least their parent SSH process are gone. this is why i related this to the \"kill git-annex assistant on logout\" - but since git-annex doesn't do setsid anymore (right?) I don't understand why those process could be left there without a parent... especially since that's on the server-side, which has a (relatively) up to date git-annex version...
+"""]]
diff --git a/doc/bugs/list__58___escaped_characters_not_accepted_as_input.mdwn b/doc/bugs/list__58___escaped_characters_not_accepted_as_input.mdwn
new file mode 100644
index 0000000000..96fd9067f8
--- /dev/null
+++ b/doc/bugs/list__58___escaped_characters_not_accepted_as_input.mdwn
@@ -0,0 +1,157 @@
+### Please describe the problem.
+
+FTR, I can work around this specific problem (somehow, not sure how yet); I also didn't intend to report two bugs in 10.20230626 today, but I found them both in a specific repo while trying to work around new error output from 10.20230626, and both of them seemed to justify being reported.  (To avoid future confusion, [other bug, relating to change in meaning of sync](https://git-annex.branchable.com/bugs/Changing_sync_to_include_content_breaks_UX/).)
+
+In short, I've ended up with the "same" podcast known in git-annex by two different encodings of the filename, both of which appear in `git annex list`, but only one of which appears in the checked out annex file system. 
+
+While `git annex list` can *show* these uniquely, there doesn't appear to be a way to identify the relevant file to operate on uniquely to, eg, `git annex drop`, or `git annex whereis`, or even `git annex list` being more specific.  They do not appear to accept the "encoded format" that is output by `git annex list`, which makes roundtriping filenames printed out difficult.  And since the files just differ by encoding, I'm not even sure if there is *any* way to specify one of them.
+
+I found this while trying to debug what had happened with a podcast downloaded from:
+
+https://popculturedetective.agency/feed/podcast/
+
+with git-annex; specifically the episode with the title starting "A Conversation with Artist Simon ...", where the artists surname has a latin accented character in it.
+
+My git-annex list is showing two references to that podcast, with subtly different names:
+
+```
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git annex list | grep "A_Conv"
+XXXX_ "A_Conversation_with_Artist_Simon_Sta\314\212lenhag.mp3"
+XXXX_ "A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3"
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ 
+```
+
+one of which matches the file now checked out on disk in that directory:
+
+```
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ LANG=C ls -B | grep A_Conv
+A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ 
+```
+
+and the other does not.  As best I can tell `\303\245` is the UTF-8 for U+00E5 ("a" with small ring above), and `\314\212` is the UTF-8 for U+030A (combining character, small ring above; after an "a").  So both are somewhat legitimate ways to encode that particular accented "a".
+
+The podcast feed (now?) has the `61 cc  8a` varient in the title of the podcast episode (ie, a, plus combining ring; equivalent to `a\314\212` as git annex now encodes it).
+
+Digging back through the git history, it appears I had the `archive/Pop_Culture_Detective__Audio_Files/A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3` variant by 2022-11-04, and downloaded the `archive/Pop_Culture_Detective__Audio_Files/A_Conversation_with_Artist_Simon_Sta\314\212lenhag.mp3` version on 2022-11-03, the day before.  (My commit comment from that date implies I was fixing libsyn filenames, I think to remove a URL suffix on them and/or avoid duplicate downloads; so I may also have upgraded git annex around that timeframe.)
+
+I also have a file hard linked to this podcast (from when it was first downloaded, 2022-11-03) which has the other encoding, implying that at one point git-annex put the other variation into the checked out files (since I hard link all "newly downloaded" files into another directory, targetted at the content file inside the annex, to make them easier to play back).
+
+```
+ewen@basadi:~/Music/podcasts$ ls -ilB A_Conversation_with_Artist_Simon_Stålenhag.mp3
+19692405 -r--r--r--  2 ewen  staff  42854272  3 Nov  2022 A_Conversation_with_Artist_Simon_Stålenhag.mp3
+ewen@basadi:~/Music/podcasts$ ls -ilBL archive/Pop_Culture_Detective__Audio_Files/A_Conversation_with_Artist_Simon_Stålenhag.mp3 
+19692405 -r--r--r--  2 ewen  staff  42854272  3 Nov  2022 archive/Pop_Culture_Detective__Audio_Files/A_Conversation_with_Artist_Simon_Stålenhag.mp3
+ewen@basadi:~/Music/podcasts$ ls -ilB archive/Pop_Culture_Detective__Audio_Files/A_Conversation_with_Artist_Simon_Stålenhag.mp3 
+19757493 lrwxr-xr-x  1 ewen  staff  206  4 Nov  2022 archive/Pop_Culture_Detective__Audio_Files/A_Conversation_with_Artist_Simon_Stålenhag.mp3 -> ../../.git/annex/objects/Xm/3v/SHA256E-s42854272--5b156789d2152e69dd0738bb75d42ddd9172a891e9646cc53d86963bd6014dc2.mp3/SHA256E-s42854272--5b156789d2152e69dd0738bb75d42ddd9172a891e9646cc53d86963bd6014dc2.mp3
+ewen@basadi:~/Music/podcasts$ ls -il .git/annex/objects/Xm/3v/SHA256E-s42854272--5b156789d2152e69dd0738bb75d42ddd9172a891e9646cc53d86963bd6014dc2.mp3/SHA256E-s42854272--5b156789d2152e69dd0738bb75d42ddd9172a891e9646cc53d86963bd6014dc2.mp3
+19692405 -r--r--r--  2 ewen  staff  42854272  3 Nov  2022 .git/annex/objects/Xm/3v/SHA256E-s42854272--5b156789d2152e69dd0738bb75d42ddd9172a891e9646cc53d86963bd6014dc2.mp3/SHA256E-s42854272--5b156789d2152e69dd0738bb75d42ddd9172a891e9646cc53d86963bd6014dc2.mp3
+ewen@basadi:~/Music/podcasts$ 
+```
+
+Given the Podcast feed itself (still) contains the UTF-8 (hex) `61 cc  8a`, which is the version I seem to have from first download, it feels like git annex might have changed to canonicalisng the UTF-8 in a way that it didn't previously *and* handled having files with the "old" encoding by (a) changing to the new coding (eg, in the checked out file) *and* (b) retaining the old *and* new encodings in the list of files.  (And it seems like this would have happened in a 2022 release of git-annex.)
+
+What seems to have changed with 10.20230626 is (from the [10.20230626 changelog](https://hackage.haskell.org/package/git-annex-10.20230626/changelog)):
+
+```
+* Many commands now quote filenames that contain unusual characters the
+  same way that git does, to avoid exposing control characters to the
+  terminal.
+```
+
+which makes sense as far as it it goes, so now the two different encodings known to git annex are visible in the "list".
+
+But the format in the output for filenames containing UTF-8 is not accepted by, eg, "git annex drop", which threw error messages, which I noticed today.
+
+In particular (a) commands *receiving* file names do not seem to understand these escaped versions, which makes round tripping of filenames (eg "git annex list" filtered and then handed back to "git annex drop") more difficult than all previous versions of git annex, (b) the UTF-8 characters are output as octal escapes of each individual byte, which makes matching them against filenames in the file system more difficult (although it seems usually they should match `LANG=C ls -B` output -- I just got unlucky here with git annex learning about two variations on the name...).
+
+
+### What steps will reproduce the problem?
+
+Something like:
+
+```
+git annex importfeed --template='archive/${feedtitle}/${itemtitle}${extension}' https://popculturedetective.agency/feed/podcast/
+git annex list archive/Pop_Culture_Detective__Audio_Files
+LANG=C ls -B archive/Pop_Culture_Detective__Audio_Files/*
+git annex list "A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3"
+```
+
+but it may require first importing the feed with git-annex older than 10.20230626 and then again with git annex 10.20230626 (I'm not entirely clear how I ended up in this exact state; but that specific feed definitely was imported with an older git-annex first, I'm just not 100% certain how old).
+
+### What version of git-annex are you using? On what operating system?
+
+Now git-annex 10.20230626, on macOS, installed from Home Brew; before git-annex 10.2022xxxx, on macOS, installed from Home Brew (around early November 2022):
+
+```
+ewen@basadi:~$ git annex version
+git-annex version: 10.20230626
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24.1 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.4.4 http-client-0.7.13.1 persistent-sqlite-2.13.1.1 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+ewen@basadi:~$ 
+```
+
+### Please provide any additional information below.
+
+Additional example of the "cannot use output name as input" problem:
+
+```
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git annex list | grep A_Conv                                           
+XXXX_ "A_Conversation_with_Artist_Simon_Sta\314\212lenhag.mp3"
+XXXX_ "A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3"
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git annex list "A_Conversation_with_Artist_Simon_Sta\314\212lenhag.mp3"
+here
+|bethel
+||nas01
+|||web
+||||bittorrent
+|||||
+error: pathspec 'A_Conversation_with_Artist_Simon_Sta\314\212lenhag.mp3' did not match any file(s) known to git
+Did you forget to 'git add'?
+list: 1 failed
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git annex list "A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3"
+here
+|bethel
+||nas01
+|||web
+||||bittorrent
+|||||
+error: pathspec 'A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3' did not match any file(s) known to git
+Did you forget to 'git add'?
+list: 1 failed
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ 
+```
+
+And proof that the actual downloaded file origin is the same:
+
+```
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git annex whereis | sed -n '/A_Conv/,/ok/p'
+whereis "A_Conversation_with_Artist_Simon_Sta\314\212lenhag.mp3" (4 copies) 
+  	00000000-0000-0000-0000-000000000001 -- web
+   	4e10813c-063b-4cd9-9680-db6685b1c5e8 -- bethel_data_drive [bethel]
+   	680fc999-1dc8-465d-b5ae-5defdb18d019 -- basadi (Mac Mini 2020) [here]
+   	9f693b73-3283-45fa-83d3-251d57da7cd3 -- Synology DS216+ [nas01]
+
+  web: https://popculturedetective.agency/podcast-download/18821/a-conversation-with-artist-simon-sta%cc%8alenhag.mp3
+ok
+whereis "A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3" (4 copies) 
+  	00000000-0000-0000-0000-000000000001 -- web
+   	4e10813c-063b-4cd9-9680-db6685b1c5e8 -- bethel_data_drive [bethel]
+   	680fc999-1dc8-465d-b5ae-5defdb18d019 -- basadi (Mac Mini 2020) [here]
+   	9f693b73-3283-45fa-83d3-251d57da7cd3 -- Synology DS216+ [nas01]
+
+  web: https://popculturedetective.agency/podcast-download/18821/a-conversation-with-artist-simon-sta%cc%8alenhag.mp3
+ok
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ 
+```
+
+(where I had to use that command variant, as there doesn't seem to be any input method to specify those two encodings separately :-/ )
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Thanks again for writing git-annex.  It's been mostly trouble free for 10 years as a "podcatcher".  Today seems to be something of a "find all the surprises" day, having upgraded git-annex (from Home Brew) earlier this week.
diff --git a/doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_1_823458893eb87f1331da050d68486209._comment b/doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_1_823458893eb87f1331da050d68486209._comment
new file mode 100644
index 0000000000..1e6bef1699
--- /dev/null
+++ b/doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_1_823458893eb87f1331da050d68486209._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-12T17:38:43Z"
+ content="""
+git-annex doesn't mess with filename encodings except for the new escaping
+on output. But as far as the path from podcast to disk, it's bytes in and
+bytes out with no concern for encoding. So I don't know how you got these
+two files, but it seems a reasonable hypotehesis that the podcast changed
+the title encoding (and perhaps then changed it back).
+
+It's strange to me that you don't have two separate files visible on disk.
+These are different filenames after all. I wonder if you are using a filesystem
+or OS that treats those as the same filename. That would certianly make
+it harder to list the files some other way and choose one to paste to `git rm`.
+
+Note that git has the same problem of many commands not accepting filenames
+output by other commands.
+
+	joey@darkstar:~/tmp/demo>touch foö
+	joey@darkstar:~/tmp/demo>git add foö
+	joey@darkstar:~/tmp/demo>git status
+	On branch master
+
+	No commits yet
+	
+	Changes to be committed:
+	  (use "git rm --cached <file>..." to unstage)
+		new file:   "fo\303\266"
+	joey@darkstar:~/tmp/demo>git rm --cached "fo\303\266"
+	fatal: pathspec 'fo\303\266' did not match any files
+
+The best workaround I know of is to use `git -c core.quotePath=false`
+to get it to output the actual filenames.
+
+I do think it might be worth adding an option to git-annex to make it 
+accept the quotepath formatted filenames. I don't think it can by default.
+"""]]
diff --git a/doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_2_bc1f89afe38c5136beb74160ff26e519._comment b/doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_2_bc1f89afe38c5136beb74160ff26e519._comment
new file mode 100644
index 0000000000..3827221ff5
--- /dev/null
+++ b/doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_2_bc1f89afe38c5136beb74160ff26e519._comment
@@ -0,0 +1,62 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="comment 2"
+ date="2023-07-13T00:54:34Z"
+ content="""
+Yes, it's also somewhat strange to me that I ended up with two variations of this filename (by UTF-8 encoding) on disk.
+
+The filesystem is the default modern macOS one (APFS, case preserving but case insensitive).  From a quick experiement, it looks like the encoding of \"a with circle above\" is one of the \"case preserving but case insensitive\" things of the APFS file system.  Ie, I can create either variation, but which ever variation is created first is treated the same as the other variation when it comes to opening/updating the file.  Which I guess makes sense, as they're two different UTF-8 encodings of ultimately the same glyph.
+
+FWIW, I also noticed while investigating this, this morning, that the encoding on disk in my annex had switched back to consistently encoding in both my linked copy (2023-11-03) and the annex archive directory (2023-11-04).  So with the two versions known to the annex, it feels like I might be seeing a \"first to be created\" race in the UTF-8 encoding used when sync runs.
+
+Also FTR, in addition to the possibility that the podcast RSS changed encoding between the two runs, it's also possible that this got canonicalised by, eg, shell expansion, around 2023-11-03 / 2023-11-04; it definitely looks like I did a bunch of automated \"git mv ...\" to fix up filenames around that point.  (And then possibly the next git annex podcast fetch re-learnt the other name.)
+
+Since I seem to have stablised on one encoding no disk right now, I'm going to try to make git-annex forget about the other encoding of the name, to tidy up this particular confusion for now.
+
+But I agree it would be helpful to have a command variant that can accept the octal-encoded byte sequences (now) output by `git annex list`.  Both for cases like this, and in general for round tripping output back to input (something I do in some cases to handle scripted checks on annexed files against other things).
+
+Thanks for the reply,
+
+Ewen
+
+```
+ewen@basadi:/tmp$ mkdir encoding
+ewen@basadi:/tmp$ cd encoding
+ewen@basadi:/tmp/encoding$ df -Pm .
+Filesystem   1M-blocks   Used Available Capacity  Mounted on
+/dev/disk1s2   1908108 991091    900870    53%    /System/Volumes/Data
+ewen@basadi:/tmp/encoding$ mount | grep /System/Volumes/Data
+/dev/disk1s2 on /System/Volumes/Data (apfs, local, journaled, nobrowse)
+map auto_home on /System/Volumes/Data/home (autofs, automounted, nobrowse)
+ewen@basadi:/tmp/encoding$ touch A_Conversation_with_Artist_Simon_Stålenhag.mp3
+ewen@basadi:/tmp/encoding$ LANG=C ls -lB
+total 0
+-rw-r--r--  1 ewen  wheel  0 Jul 13 12:40 A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3
+ewen@basadi:/tmp/encoding$ touch A_Conversation_with_Artist_Simon_Stålenhag.mp3
+ewen@basadi:/tmp/encoding$ LANG=C ls -lB                                       
+total 0
+-rw-r--r--  1 ewen  wheel  0 Jul 13 12:41 A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3
+ewen@basadi:/tmp/encoding$ touch A_Conversation_with_Artist_Simon_Stålenhag.mp3-new
+ewen@basadi:/tmp/encoding$ LANG=C ls -lB
+total 0
+-rw-r--r--  1 ewen  wheel  0 Jul 13 12:41 A_Conversation_with_Artist_Simon_Sta\314\212lenhag.mp3-new
+-rw-r--r--  1 ewen  wheel  0 Jul 13 12:41 A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3
+ewen@basadi:/tmp/encoding$ touch A_Conversation_with_Artist_Simon_Stålenhag.mp3-new
+ewen@basadi:/tmp/encoding$ LANG=C ls -lB
+total 0
+-rw-r--r--  1 ewen  wheel  0 Jul 13 12:43 A_Conversation_with_Artist_Simon_Sta\314\212lenhag.mp3-new
+-rw-r--r--  1 ewen  wheel  0 Jul 13 12:41 A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3
+ewen@basadi:/tmp/encoding$ 
+```
+
+```
+ewen@basadi:~/Music/podcasts$ date
+Thu 13 Jul 2023 12:44:54 NZST
+ewen@basadi:~/Music/podcasts$ LANG=C ls -lB A_Conv*
+-r--r--r--  2 ewen  staff  42854272 Nov  3  2022 A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3
+ewen@basadi:~/Music/podcasts$ LANG=C ls -lB archive/Pop_Culture_Detective__Audio_Files/A_Conv*
+lrwxr-xr-x  1 ewen  staff  206 Nov  4  2022 archive/Pop_Culture_Detective__Audio_Files/A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3 -> ../../.git/annex/objects/Xm/3v/SHA256E-s42854272--5b156789d2152e69dd0738bb75d42ddd9172a891e9646cc53d86963bd6014dc2.mp3/SHA256E-s42854272--5b156789d2152e69dd0738bb75d42ddd9172a891e9646cc53d86963bd6014dc2.mp3
+ewen@basadi:~/Music/podcasts$ 
+```
+"""]]
diff --git a/doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_3_3aafdcc1b32439ec577fb090b94c6ac1._comment b/doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_3_3aafdcc1b32439ec577fb090b94c6ac1._comment
new file mode 100644
index 0000000000..0c358b7549
--- /dev/null
+++ b/doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_3_3aafdcc1b32439ec577fb090b94c6ac1._comment
@@ -0,0 +1,147 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="git mv to temporary name, commit, git mv back, commit, can resolve duplicates"
+ date="2023-07-13T01:12:34Z"
+ content="""
+Interestingly, just renaming the file on disk (`git mv`) is sufficient to make the second (duplicate) entry go away, as the second one gets flagged as \"deleted\".  And if I commit both changes, then it seems to be persistent.  Ie, *after* the commit, I can `git mv` the file back to the original on-disk name, and commit that, and `git annex list` only shows the one name.  That seems to survive `git annex sync --no-content` and even another run of my podcast fetching.  So I think that dance solves my immediate \"cannot reference by name\" problem -- ie, move the one on disk aside, commit, move back, commit.
+
+(I still have a problem with my auto-cleanup automation for this repository -- `git annex drop ...` if it's no longer linked into the \"postcasts to play\" repo -- but I'm fairly sure I can fix the detection of that somehow.  And the few special cases that no longer auto-drop by \"name from `git annex list`\" I can drop by hand via wildcards or tab-completion.)
+
+Other than the feature request (some way to feed the escaped output back in as input) I think this bug is resolved.  Thanks for your comments.
+
+Ewen
+
+```
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git annex list
+here
+|bethel
+||nas01
+|||web
+||||bittorrent
+|||||
+XXXX_ \"A_Conversation_with_Artist_Simon_Sta\314\212lenhag.mp3\"
+XXXX_ \"A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\"
+_XXX_ Demystifying_Fair_Use__Copyright__and_Content_ID.mp3
+XXXX_ Indiana_Jones_and_The_Case_of_The_Ancient_Aliens.mp3
+_XXX_ Solarpunk_and_How_We_Escape_Dystopia.mp3
+_XXX_ The_Case_of_Boba_Fett_and_the_Hollywood_Western.mp3
+XXXX_ The_Case_of_The_Cursed_Jungle_Cruise.mp3
+_XXX_ The_Case_of_The_Falcon_and_The_Winter_Soldier.mp3
+XXXX_ The_Continuing_Case_of_Ted_Lasso.mp3
+_XXX_ The_Curious_Case_of_Ted_Lasso.mp3
+XXXX_ The_Multiversal_Case_of_Everything_Everywhere.mp3
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ LANG=C ls -B *Conversation_*
+A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git mv A_Conversation_with_Artist_Simon_Stålenhag.mp3 keep-A_Conversation_with_Artist_Simon_Stålenhag.mp3 
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ LANG=C ls -B *Conversation_*
+keep-A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git annex list              
+here
+|bethel
+||nas01
+|||web
+||||bittorrent
+|||||
+_XXX_ Demystifying_Fair_Use__Copyright__and_Content_ID.mp3
+XXXX_ Indiana_Jones_and_The_Case_of_The_Ancient_Aliens.mp3
+_XXX_ Solarpunk_and_How_We_Escape_Dystopia.mp3
+_XXX_ The_Case_of_Boba_Fett_and_the_Hollywood_Western.mp3
+XXXX_ The_Case_of_The_Cursed_Jungle_Cruise.mp3
+_XXX_ The_Case_of_The_Falcon_and_The_Winter_Soldier.mp3
+XXXX_ The_Continuing_Case_of_Ted_Lasso.mp3
+_XXX_ The_Curious_Case_of_Ted_Lasso.mp3
+XXXX_ The_Multiversal_Case_of_Everything_Everywhere.mp3
+XXXX_ \"keep-A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\"
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git status
+On branch master
+Changes to be committed:
+  (use \"git restore --staged <file>...\" to unstage)
+	renamed:    \"A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\" -> \"keep-A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\"
+
+Changes not staged for commit:
+  (use \"git add/rm <file>...\" to update what will be committed)
+  (use \"git restore <file>...\" to discard changes in working directory)
+	deleted:    \"A_Conversation_with_Artist_Simon_Sta\314\212lenhag.mp3\"
+
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git commit -am 'Consolidate on one UTF-8 encoding of A Conversation with Simon Stalenhag'
+[master 05d2c2c50] Consolidate on one UTF-8 encoding of A Conversation with Simon Stalenhag
+ 2 files changed, 1 deletion(-)
+ delete mode 120000 \"archive/Pop_Culture_Detective__Audio_Files/A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\"
+ rename \"archive/Pop_Culture_Detective__Audio_Files/A_Conversation_with_Artist_Simon_Sta\314\212lenhag.mp3\" => \"archive/Pop_Culture_Detective__Audio_Files/keep-A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\" (100%)
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git status
+On branch master
+nothing to commit, working tree clean
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ LANG=C ls -B *Conversation_*
+keep-A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git annex list
+here
+|bethel
+||nas01
+|||web
+||||bittorrent
+|||||
+_XXX_ Demystifying_Fair_Use__Copyright__and_Content_ID.mp3
+XXXX_ Indiana_Jones_and_The_Case_of_The_Ancient_Aliens.mp3
+_XXX_ Solarpunk_and_How_We_Escape_Dystopia.mp3
+_XXX_ The_Case_of_Boba_Fett_and_the_Hollywood_Western.mp3
+XXXX_ The_Case_of_The_Cursed_Jungle_Cruise.mp3
+_XXX_ The_Case_of_The_Falcon_and_The_Winter_Soldier.mp3
+XXXX_ The_Continuing_Case_of_Ted_Lasso.mp3
+_XXX_ The_Curious_Case_of_Ted_Lasso.mp3
+XXXX_ The_Multiversal_Case_of_Everything_Everywhere.mp3
+XXXX_ \"keep-A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\"
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git mv keep-A_Conversation_with_Artist_Simon_Stålenhag.mp3 A_Conversation_with_Artist_Simon_Stålenhag.mp3 
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ LANG=C ls -B *Conversation*
+A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git annex list
+here
+|bethel
+||nas01
+|||web
+||||bittorrent
+|||||
+XXXX_ \"A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\"
+_XXX_ Demystifying_Fair_Use__Copyright__and_Content_ID.mp3
+XXXX_ Indiana_Jones_and_The_Case_of_The_Ancient_Aliens.mp3
+_XXX_ Solarpunk_and_How_We_Escape_Dystopia.mp3
+_XXX_ The_Case_of_Boba_Fett_and_the_Hollywood_Western.mp3
+XXXX_ The_Case_of_The_Cursed_Jungle_Cruise.mp3
+_XXX_ The_Case_of_The_Falcon_and_The_Winter_Soldier.mp3
+XXXX_ The_Continuing_Case_of_Ted_Lasso.mp3
+_XXX_ The_Curious_Case_of_Ted_Lasso.mp3
+XXXX_ The_Multiversal_Case_of_Everything_Everywhere.mp3
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git status
+On branch master
+Changes to be committed:
+  (use \"git restore --staged <file>...\" to unstage)
+	renamed:    \"keep-A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\" -> \"A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\"
+
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git commit -m 'Restore canonical name for A Conversation with Simon Stalenhag podcast'
+[master 8c7249dae] Restore canonical name for A Conversation with Simon Stalenhag podcast
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ rename \"archive/Pop_Culture_Detective__Audio_Files/keep-A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\" => \"archive/Pop_Culture_Detective__Audio_Files/A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\" (100%)
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ LANG=C ls -B *Conversation*
+A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ LANG=C ls -B ../../*Conversation*Simon*
+../../A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ git annex list
+here
+|bethel
+||nas01
+|||web
+||||bittorrent
+|||||
+XXXX_ \"A_Conversation_with_Artist_Simon_St\303\245lenhag.mp3\"
+_XXX_ Demystifying_Fair_Use__Copyright__and_Content_ID.mp3
+XXXX_ Indiana_Jones_and_The_Case_of_The_Ancient_Aliens.mp3
+_XXX_ Solarpunk_and_How_We_Escape_Dystopia.mp3
+_XXX_ The_Case_of_Boba_Fett_and_the_Hollywood_Western.mp3
+XXXX_ The_Case_of_The_Cursed_Jungle_Cruise.mp3
+_XXX_ The_Case_of_The_Falcon_and_The_Winter_Soldier.mp3
+XXXX_ The_Continuing_Case_of_Ted_Lasso.mp3
+_XXX_ The_Curious_Case_of_Ted_Lasso.mp3
+XXXX_ The_Multiversal_Case_of_Everything_Everywhere.mp3
+ewen@basadi:~/Music/podcasts/archive/Pop_Culture_Detective__Audio_Files$ 
+```
+"""]]
diff --git a/doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_4_73c1495abff5284c42a8cf0537b19df4._comment b/doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_4_73c1495abff5284c42a8cf0537b19df4._comment
new file mode 100644
index 0000000000..6c05d50aa8
--- /dev/null
+++ b/doc/bugs/list__58___escaped_characters_not_accepted_as_input/comment_4_73c1495abff5284c42a8cf0537b19df4._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-07-21T19:20:54Z"
+ content="""
+Interestingly, `git rm` does have a way to make it accept quotepath
+formatted filenames:
+
+       --pathspec-from-file=<file>
+           Pathspec is passed in <file> instead of commandline args. If <file>
+           is exactly - then standard input is used. Pathspec elements are
+           separated by LF or CR/LF. Pathspec elements can be quoted as
+           explained for the configuration variable core.quotePath (see git-
+           config(1)). See also --pathspec-file-nul and global
+           --literal-pathspecs.
+
+I don't think that's the first thing I would have reached for though.
+It's not a common option supported by other git commands. I would have
+probably instead used `git ls-files -c core.quotePath=false`, filtered
+the output to only have one of the two related filenames, and passed it to
+`git rm` as a parameter.
+
+If git had a common way to accept quotepath input, I'd think that git-annex
+should support it, but since it doesn't, I'm unsure that it's worth complicating
+git-annex, since core.quotePath=false can already be used.
+"""]]
diff --git a/doc/bugs/loadlocale_error_with_standalone_build.mdwn b/doc/bugs/loadlocale_error_with_standalone_build.mdwn
new file mode 100644
index 0000000000..fd9f32e08e
--- /dev/null
+++ b/doc/bugs/loadlocale_error_with_standalone_build.mdwn
@@ -0,0 +1,44 @@
+### Please describe the problem.
+
+git annex version
+
+sh: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
+Aborted
+
+### What steps will reproduce the problem?
+
+git annex version
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+
+Synology NAS, 32-bit prebuilt version
+
+wget https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386.tar.gz
+--2018-04-08 04:26:29--  https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386.tar.gz
+Resolving downloads.kitenet.net... 66.228.36.95, 2600:3c03::f03c:91ff:fe73:b0d2
+Connecting to downloads.kitenet.net|66.228.36.95|:443... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 60787901 (58M) [application/x-gzip]
+Saving to: 'git-annex-standalone-i386.tar.gz'
+
+100%[================================================================================================================================================================================================================================================>] 60,787,901  1.52MB/s   in 39s    
+
+2018-04-08 04:27:09 (1.49 MB/s) - 'git-annex-standalone-i386.tar.gz' saved [60787901/60787901]
+
+"""]]
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/loadlocale_error_with_standalone_build/comment_1_96a809060ed05100b6f8e5198ec699be._comment b/doc/bugs/loadlocale_error_with_standalone_build/comment_1_96a809060ed05100b6f8e5198ec699be._comment
new file mode 100644
index 0000000000..6db8c24c81
--- /dev/null
+++ b/doc/bugs/loadlocale_error_with_standalone_build/comment_1_96a809060ed05100b6f8e5198ec699be._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="ga@2217a6e07239bc6b36af2a9134b2647fdebcabcd"
+ nickname="ga"
+ avatar="http://cdn.libravatar.org/avatar/d077d3b19ca11c2036b4870e4340c7d1"
+ subject="Same error"
+ date="2018-05-05T05:28:35Z"
+ content="""
+I'm getting the same error on my Synology device.
+
+$ uname -a
+Linux xxxx 3.10.102 #15266 SMP Mon Mar 26 15:10:20 CST 2018 armv7l GNU/Linux synology_armada38x_ds216j
+
+"""]]
diff --git a/doc/bugs/loadlocale_error_with_standalone_build/comment_2_e1c443ba943a5883ca63fbf05d3e5b41._comment b/doc/bugs/loadlocale_error_with_standalone_build/comment_2_e1c443ba943a5883ca63fbf05d3e5b41._comment
new file mode 100644
index 0000000000..d44460d2ae
--- /dev/null
+++ b/doc/bugs/loadlocale_error_with_standalone_build/comment_2_e1c443ba943a5883ca63fbf05d3e5b41._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-05-08T18:28:59Z"
+ content="""
+The synology NAS has a very old linux kernel IIRC, so you will probably
+have better luck with the tarball targeting ancient kernels, 
+<https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386-ancient.tar.gz>
+"""]]
diff --git a/doc/bugs/loadlocale_error_with_standalone_build/comment_3_acb934b9e7d91aa59f49926e658c4bbe._comment b/doc/bugs/loadlocale_error_with_standalone_build/comment_3_acb934b9e7d91aa59f49926e658c4bbe._comment
new file mode 100644
index 0000000000..0fc39f5333
--- /dev/null
+++ b/doc/bugs/loadlocale_error_with_standalone_build/comment_3_acb934b9e7d91aa59f49926e658c4bbe._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="ga@2217a6e07239bc6b36af2a9134b2647fdebcabcd"
+ nickname="ga"
+ avatar="http://cdn.libravatar.org/avatar/d077d3b19ca11c2036b4870e4340c7d1"
+ subject="Arm processor on Synology device"
+ date="2018-05-10T11:07:44Z"
+ content="""
+Unfortunately the processor is an Arm processor, so the ancient build you linked won't work:
+
+$ grep model /proc/cpuinfo
+
+model name      : ARMv7 Processor rev 1 (v7l)
+
+(I have a DS216j)
+
+I see you have an outstanding issue about providing an ancient armel build, maybe that would help?
+
+https://git-annex.branchable.com/todo/add_ancient_armel_build/
+"""]]
diff --git a/doc/bugs/loadlocale_error_with_standalone_build/comment_4_39366d601e4200a953fe375c7c96f106._comment b/doc/bugs/loadlocale_error_with_standalone_build/comment_4_39366d601e4200a953fe375c7c96f106._comment
new file mode 100644
index 0000000000..17ae553b47
--- /dev/null
+++ b/doc/bugs/loadlocale_error_with_standalone_build/comment_4_39366d601e4200a953fe375c7c96f106._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="Synology NAS"
+ date="2018-07-08T06:52:08Z"
+ content="""
+I can confirm I got the same error message trying the 2018-06-26 amd64 standalone build on a Synology DS216+ NAS (installed via the [same instructions that I used last year](http://ewen.mcneill.gen.nz/blog/entry/2017-05-28-git-annex-on-synology-ds216+/), after creating the directory to allow the locale to be generated.  But if I instead installed the `i386-ancient` version, and let that generate the locales, then that seems to work okay. Eg, I can then run `git annex version` to completion:
+
+<pre>
+ewen@nas01:/volume1/thirdparty$ git annex version
+git-annex version: 6.20180626-gb091dac
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux i386
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+ewen@nas01:/volume1/thirdparty$ 
+</pre>
+
+(I haven't tried the non-archaic i386 version.)
+
+Since the locales *should* be user space only, I'm assuming that the issue isn't \"archaic kernel\" -- although the Synology DS216+ NAS kernel is based on a fairly old version:
+
+    ewen@nas01:/volume1/thirdparty$ uname -a
+    Linux nas01 3.10.105 #23739 SMP Fri Jun 8 12:51:05 CST 2018 x86_64 GNU/Linux synology_braswell_216+II
+    ewen@nas01:/volume1/thirdparty$ 
+
+but probably related to the `libc` version `git-annex` was compiled against, and the version of the tools being used to generate the locales.
+
+I've not tested the new version much on the Synology DS216+ NAS, but I'm expecting that it should work now that \"`git annex version`\" works (and \"`git annex sync`\" works from another machine to it), with the `i386` \"archaic\" build, the rest should work for my purposes (basically `ssh` remote).
+
+Ewen
+"""]]
diff --git a/doc/bugs/loadlocale_error_with_standalone_build/comment_5_ce08bf5b13ae0db7fa06196f56a26e8a._comment b/doc/bugs/loadlocale_error_with_standalone_build/comment_5_ce08bf5b13ae0db7fa06196f56a26e8a._comment
new file mode 100644
index 0000000000..d0a6177847
--- /dev/null
+++ b/doc/bugs/loadlocale_error_with_standalone_build/comment_5_ce08bf5b13ae0db7fa06196f56a26e8a._comment
@@ -0,0 +1,57 @@
+[[!comment format=mdwn
+ username="g@aaed65f19d6c3a2a18c33da828e66c7bb915e65a"
+ nickname="g"
+ avatar="http://cdn.libravatar.org/avatar/10470d6f8a18833e04dee17126d53372"
+ subject="workaround: setting LC_ALL=C"
+ date="2018-10-18T08:55:19Z"
+ content="""
+I had a similar problem yesterday with the latest [x86-64 standalone build](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz), git-annex ver. 6.20180927-g897e5ba57
+
+# Short story
+
+I solved this adding this to my `.bashrc`
+
+    export LC_ALL=C
+
+# Non so short story
+
+I need the standalone version for I'm using an hosting service with ssh connection; it's just a \"classic\" LAMP hosting space, not a full VM, so I cannot install any package on it
+
+In 2016 I was able to install the standalone git-annex version 6.20161231-gc8eeb17da, along with gitolite for access control, and all was working well until recently on one of my machines I upgraded to ver. 6.20180913-1 amd64: trying to get some content always failed with
+
+      [2018-10-17 17:56:52.199123421] P2P > ERROR auth failed
+
+      fd:19: hClose: resource vanished (Broken pipe)
+      failed
+
+After a brief search I found [get over ssh fails with fd:19: hClose: resource vanished - comment 1](http://git-annex.branchable.com/bugs/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/#comment-f9a93468be4a799e1e79e97941449d67) and decidet to upgrade git-annex server side
+
+After upgrade I got the error reported in this bug report subject and after a quick research I found a [similar report on askubuntu](https://askubuntu.com/questions/1081901/right-way-to-fix-assertion-in-loadlocale-c)
+
+The first thing I tried was 
+
+    LC_ALL=C git annex version
+
+and I the error \"disappeared\": bingo!
+
+I realized that `LC_ALL` was *unset* in my gitolite user profile, so I added it to my `.bashrc` and now all is working (almost) fine.
+
+# Why almost?
+
+Well: it's surely not related to git-annex but to my hosting server.
+
+Every time I get some file from the remote on that hosting space I get an error
+     
+     ERROR: ld.so: object '/lib/security/hosting-securize.so' from /etc/ld.so.preload cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
+
+but fortunately it is ignored and the files are downloaded as expected
+
+I still had no time to investigate why I get a ELFCLASS32 (I'm sure I installed the amd64 standalone)... but since it works I leave it as a background wishlist
+
+# The end
+
+That's all, I hope this will help others with similar issues
+
+Bye!
+Giovanni Biscuolo  
+"""]]
diff --git a/doc/bugs/loadlocale_error_with_standalone_build/comment_6_a852f4b40506edf9948c7953b01aa340._comment b/doc/bugs/loadlocale_error_with_standalone_build/comment_6_a852f4b40506edf9948c7953b01aa340._comment
new file mode 100644
index 0000000000..ff0771f3b0
--- /dev/null
+++ b/doc/bugs/loadlocale_error_with_standalone_build/comment_6_a852f4b40506edf9948c7953b01aa340._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2018-12-03T17:41:43Z"
+ content="""
+Same problem reported in another bug, the bug sumitter was using Ubuntu
+14.04.5 LTS. Which also makes me think it's related to kernel version.
+"""]]
diff --git a/doc/bugs/loadlocale_error_with_standalone_build/comment_6_b387cdacf97c476284640195e9fd03c9._comment b/doc/bugs/loadlocale_error_with_standalone_build/comment_6_b387cdacf97c476284640195e9fd03c9._comment
new file mode 100644
index 0000000000..cb8c24fdc4
--- /dev/null
+++ b/doc/bugs/loadlocale_error_with_standalone_build/comment_6_b387cdacf97c476284640195e9fd03c9._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="StéphaneGL"
+ avatar="http://cdn.libravatar.org/avatar/a12e6e0852d5a1985b8684b17202561c"
+ subject="comment 6"
+ date="2018-12-03T18:22:10Z"
+ content="""
+I had the same error message when trying to run the standalone, version 7.20181106, on my raspberry pi. For some reason, the stand-alone version of git-annex handles and compiles its own locales in 
+
+`~/.cache/git-annex/locales/[SOME_DIRECTORY]/`
+
+For some unknown reason, the locale that git-annex compiled in that directory, namely en_GB.UTF-8 for me, was different from the one from my system, which is kept in `/usr/lib/locales/`.
+Every command that git-annex uses, even just rm, was systematically failing with error `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))` after git-annex loaded its own locale instead of the system's (technically, after the runshell script exports LOCPATH=`~/.cache/git-annex/locales/[SOME_DIRECTORY]/`).
+
+Solution I found:
+I erased the version that git-annex compiled and instead placed a symbolic link `~/.cache/git-annex/locales/[SOME_DIRECTORY]/en_GB.UTF-8` towards my system's locale in `/usr/lib/locale/`.
+Then LC_TIME was correctly defined and I got rid of the error `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))'
+
+Hope this helps.
+
+It looks like the runshell script is doing something incorrect with the compilation of locales, but I'm not sure what.
+
+
+"""]]
diff --git a/doc/bugs/loadlocale_error_with_standalone_build/comment_8_7820a310f6bf5f6f4c6c58fbfea8c85f._comment b/doc/bugs/loadlocale_error_with_standalone_build/comment_8_7820a310f6bf5f6f4c6c58fbfea8c85f._comment
new file mode 100644
index 0000000000..ce9a53cda2
--- /dev/null
+++ b/doc/bugs/loadlocale_error_with_standalone_build/comment_8_7820a310f6bf5f6f4c6c58fbfea8c85f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="ga@2217a6e07239bc6b36af2a9134b2647fdebcabcd"
+ nickname="ga"
+ avatar="http://cdn.libravatar.org/avatar/d077d3b19ca11c2036b4870e4340c7d1"
+ subject="Worked around"
+ date="2018-12-19T21:09:43Z"
+ content="""
+Setting LC_ALL=C appears to have worked around this for me.
+"""]]
diff --git a/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped.mdwn b/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped.mdwn
new file mode 100644
index 0000000000..fb3f414c04
--- /dev/null
+++ b/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped.mdwn
@@ -0,0 +1,33 @@
+### Please describe the problem.
+
+Using the SHA256E backend should preserve file extensions. This works for most of my files, but not files with a `.numbers` extension. Without the extension in the filename, Numbers (Excel of Apple) can not open the file (as described elsewhere in the forums). Copying the file from the `.git/annex/objects` and re-adding the extension allows me to open the file again, so the file is intact.
+
+I think it might be that git annex does not recognize `.numbers` as an extension because of its length? 
+
+### What steps will reproduce the problem?
+
+Adding a file with `.numbers` extension (e.g. `git annex add bids.numbers`) will drop the extension in the `.git/annex/objects`
+
+[[!format sh """
+bids.numbers -> ../.git/annex/objects/Xp/xZ/SHA256E-s225502--a420fa2986ddd5e4fad39758e91bc753f5f1199a64c47c84b5bd5b9c288b66c2/SHA256E-s225502--a420fa2986ddd5e4fad39758e91bc753f5f1199a64c47c84b5bd5b9c288b66c2
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20221103
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-8.10.7 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git annex makes me so happy. As I had mentioned in a previous post some years ago, it solves problems that I have not anticipated and teaches me new concepts that I then apply across my work. Thank you so much Joey! :bow:
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_1_0e3e0966f06ded18ecfd41f8084b4658._comment b/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_1_0e3e0966f06ded18ecfd41f8084b4658._comment
new file mode 100644
index 0000000000..78008ecc56
--- /dev/null
+++ b/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_1_0e3e0966f06ded18ecfd41f8084b4658._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-11-29T16:44:07Z"
+ content="""
+What is an extension and what is not is ambiguous
+to a computer. Eg, the filename "mr.toadswildride"
+does not have an extension.
+
+So git-annex has a heuristic, that an extension has
+a maximum length of 4. Which works for the vast
+majority of extensions in use. You can override
+that to some other value:
+
+	git config annex.maxextensionlength 7
+"""]]
diff --git a/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_2_2836fe9dfa7b5140df1ce893044c254b._comment b/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_2_2836fe9dfa7b5140df1ce893044c254b._comment
new file mode 100644
index 0000000000..128336acf6
--- /dev/null
+++ b/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_2_2836fe9dfa7b5140df1ce893044c254b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-11-29T16:47:44Z"
+ content="""
+Also you might want to consider unlocking files,
+either generally or on the OSX systems with this problem.
+Only locked files use symlinks that cause problems for these programs.
+
+	git-annex adjust --unlock
+"""]]
diff --git a/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_3_1f4bc975621d24e6e43d887693ada800._comment b/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_3_1f4bc975621d24e6e43d887693ada800._comment
new file mode 100644
index 0000000000..a2c7877140
--- /dev/null
+++ b/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_3_1f4bc975621d24e6e43d887693ada800._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="cnjr2"
+ avatar="http://cdn.libravatar.org/avatar/f7e9654cc967c8815947b19829bfd746"
+ subject="found related bug"
+ date="2022-11-29T16:51:44Z"
+ content="""
+I have searched around some more and found a related bug report. As per [your comment](https://git-annex.branchable.com/bugs/Wrong_backend_extension_in_files_with_multiple_dots/#comment-1e0885e62a9c22baae6300d2312c5163) what constitutes a file extension is determined by heuristics. So I guess my question would become: Would it be a bad idea to have long (and ugly) file extensions (i.e. `.numbers`) be recognized as as extensions? What would be situations where that would go wrong?
+"""]]
diff --git a/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_4_2cded724d1a4368dca475b89010c23e2._comment b/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_4_2cded724d1a4368dca475b89010c23e2._comment
new file mode 100644
index 0000000000..e2e4b5abfa
--- /dev/null
+++ b/doc/bugs/long_file_extensions___40__e.g._.numbers__41___dropped/comment_4_2cded724d1a4368dca475b89010c23e2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="cnjr2"
+ avatar="http://cdn.libravatar.org/avatar/f7e9654cc967c8815947b19829bfd746"
+ subject="comment 4"
+ date="2022-11-29T16:53:39Z"
+ content="""
+Thank you Joey - I wrote my previous comment as your answer was coming in. Much obliged!
+"""]]
diff --git a/doc/bugs/make___39__find__39___clear__40__er__41___on_what_is_unlocked_.mdwn b/doc/bugs/make___39__find__39___clear__40__er__41___on_what_is_unlocked_.mdwn
new file mode 100644
index 0000000000..3624584ce9
--- /dev/null
+++ b/doc/bugs/make___39__find__39___clear__40__er__41___on_what_is_unlocked_.mdwn
@@ -0,0 +1,65 @@
+`git annex find --unlocked` reports also not just files which are known to `git-annex` as unlocked, but also files which were regular "locked" (symlinks) but are modified in the tree:
+
+
+<details>
+<summary>here is a reproducer script</summary> 
+
+```shell
+#!/bin/bash
+
+cd "$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)"
+set -eu
+
+git init
+git annex init
+
+echo 123 > 123
+git annex add 123
+git commit -m 'commit 123 locked'
+git annex unlock 123 
+git commit -m 'commit 123 unlocked' 123
+
+set -x
+git annex find --unlocked  # should show 123
+
+git status  # should show all clean
+
+# let's create another file which we just modify
+
+echo 124 > 124
+git annex add 124
+git commit -m 'committing 124 locked' 124
+rm 124
+touch 124
+
+git annex find --unlocked  # will report both 123 and 124
+git status
+
+```
+</details>
+
+which with git-annex `8.20211231+git140-gc3817495f-1~ndall+1` would produce at the end
+
+```
++ git commit -m 'committing 124 locked' 124
+[master b58274c] committing 124 locked
+ 1 file changed, 1 insertion(+)
+ create mode 120000 124
++ rm 124
++ touch 124
++ git annex find --unlocked
+123
+124
++ git status
+On branch master
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git restore <file>..." to discard changes in working directory)
+	typechange: 124
+
+no changes added to commit (use "git add" and/or "git commit -a")
+```
+
+and I do not think it should report `124` as unlocked.  Or is there some `find` way to search only for "truly unlocked" files?
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/make___39__find__39___clear__40__er__41___on_what_is_unlocked_/comment_1_b855c810464bb22bd76681d669313ae5._comment b/doc/bugs/make___39__find__39___clear__40__er__41___on_what_is_unlocked_/comment_1_b855c810464bb22bd76681d669313ae5._comment
new file mode 100644
index 0000000000..8ab89d2846
--- /dev/null
+++ b/doc/bugs/make___39__find__39___clear__40__er__41___on_what_is_unlocked_/comment_1_b855c810464bb22bd76681d669313ae5._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-21T19:16:13Z"
+ content="""
+The only difference between those two is that git-annex unlock stages the
+unlocking, while replacing the file with unlocked content does not stage
+it yet.
+
+Both files are unlocked in the working tree though. One is unlocked in
+the index, and the other one is not yet. But git-annex find examines the
+working tree.
+
+What you are looking for is a a way to have `git-annex find`
+ignore the working tree and find files that are unlocked in the index.
+That is doable:
+
+	git-annex find --branch=$(git write-tree) --unlocked
+"""]]
diff --git a/doc/bugs/make___39__find__39___clear__40__er__41___on_what_is_unlocked_/comment_2_71b7b4417aa63e469636a03e460c2427._comment b/doc/bugs/make___39__find__39___clear__40__er__41___on_what_is_unlocked_/comment_2_71b7b4417aa63e469636a03e460c2427._comment
new file mode 100644
index 0000000000..4c1abdd7f7
--- /dev/null
+++ b/doc/bugs/make___39__find__39___clear__40__er__41___on_what_is_unlocked_/comment_2_71b7b4417aa63e469636a03e460c2427._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-02-21T21:48:59Z"
+ content="""
+`--branch` should be the one to remember indeed and would fulfill my desires (I think ;) ).  thank you Joey!
+"""]]
diff --git a/doc/bugs/make_install_doesn__39__t_create_git-annex-shell.mdwn b/doc/bugs/make_install_doesn__39__t_create_git-annex-shell.mdwn
new file mode 100644
index 0000000000..471c91e9d4
--- /dev/null
+++ b/doc/bugs/make_install_doesn__39__t_create_git-annex-shell.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+There is no git-annex-shell command in path and thus sync with ssh server fails. If I symlink /usr/bin/git-annex-shell -> /usr/bin/git-annex, it complains that key is already present in annex and errors out. There is executable git-annex-shell in server's ~/.ssh/
+
+### What steps will reproduce the problem?
+Start webapp to sync local repo with ssh server.
+
+### What version of git-annex are you using? On what operating system?
+git-annex 4.20130627 on Gentoo
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+[2013-07-08 17:28:48 EEST] main: starting assistant version 4.20130627
+[2013-07-08 17:28:49 EEST] TransferScanner: Syncing with netbook_Lit, sigma_Lit 
+
+  dbus failed; falling back to mtab polling (SocketError {socketErrorMessage = "connect: does not exist (Connection refused)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:abstract=/tmp/dbus-HBxh6EyMJ3,guid=adc3101676daede2a128013351daa535")})
+Already up-to-date.
+
+(scanning...) [2013-07-08 17:28:49 EEST] Watcher: Performing startup scan
+Already up-to-date.
+Already up-to-date.
+
+
+(started...) Everything up-to-date
+Everything up-to-date
+bash: git-annex-shell: command not found
+rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+rsync error: remote command not found (code 127) at io.c(605) [sender=3.0.9]
+bash: git-annex-shell: command not found
+rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+rsync error: remote command not found (code 127) at io.c(605) [sender=3.0.9]
+
+
+[2013-07-08 17:50:23 EEST] main: starting assistant version 4.20130627
+[2013-07-08 17:50:23 EEST] TransferScanner: Syncing with netbook_Lit, sigma_Lit 
+
+  dbus failed; falling back to mtab polling (SocketError {socketErrorMessage = "connect: does not exist (Connection refused)", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:abstract=/tmp/dbus-HBxh6EyMJ3,guid=adc3101676daede2a128013351daa535")})
+Already up-to-date.
+
+(scanning...) [2013-07-08 17:50:23 EEST] Watcher: Performing startup scan
+Already up-to-date.
+Already up-to-date.
+
+
+(started...) Everything up-to-date
+Everything up-to-date
+git-annex-shell: key is already present in annex
+rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]
+git-annex-shell: key is already present in annex
+rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]
+
+
+
+# End of transcript or log.
+"""]]
+
+[[!tag done]]
diff --git a/doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_1_8c20edd8c6483500f807528d616c6dfd._comment b/doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_1_8c20edd8c6483500f807528d616c6dfd._comment
new file mode 100644
index 0000000000..ad32737237
--- /dev/null
+++ b/doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_1_8c20edd8c6483500f807528d616c6dfd._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.254.222"
+ subject="comment 1"
+ date="2013-07-08T16:14:37Z"
+ content="""
+The Makefile contains, for the install target:
+
+[[!format sh \"\"\"
+        ln -sf git-annex $(DESTDIR)$(PREFIX)/bin/git-annex-shell
+\"\"\"]]
+
+How was git-annex installed on your server?
+"""]]
diff --git a/doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_2_8b2cf0fe7219e0bc83fd326adbf26c8a._comment b/doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_2_8b2cf0fe7219e0bc83fd326adbf26c8a._comment
new file mode 100644
index 0000000000..452b55d40e
--- /dev/null
+++ b/doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_2_8b2cf0fe7219e0bc83fd326adbf26c8a._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm01ida6POv7vqyUYtOlymEbJTbrImAIzM"
+ nickname="Reinis"
+ subject="comment 2"
+ date="2013-07-08T18:09:50Z"
+ content="""
+That is Gentoo box and git-annex is installed using the following ebuild:
+
+[[https://github.com/gentoo-haskell/gentoo-haskell/blob/master/dev-vcs/git-annex/git-annex-4.20130627.ebuild]]
+
+which uses cabal to install it. It uses also the following eclass:
+
+[[http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/haskell-cabal.eclass?revision=1.40&view=markup]]
+
+The main functions of interest there are cabal-bootstrap(), cabal-copy() and cabal_src_install(). I'm not familiar enough with haskell nor with cabal to follow trough in detail how the setup program is constructed and how it works, but the end result is that this is all that is installed. I don't know if normal cabal installs work as intended, maybe something there needs to be adjusted?
+
+[[!format sh \"\"\"
+ * Contents of dev-vcs/git-annex-4.20130627:
+/usr
+/usr/bin
+/usr/bin/git-annex
+/usr/lib64
+/usr/lib64/ghc-7.6.3
+/usr/lib64/ghc-7.6.3/gentoo
+/usr/lib64/ghc-7.6.3/gentoo/git-annex-4.20130627.conf
+/usr/share
+/usr/share/doc
+/usr/share/doc/git-annex-4.20130627
+/usr/share/doc/git-annex-4.20130627/COPYRIGHT.bz2
+\"\"\" ]]
+"""]]
diff --git a/doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_3_25fe06eb127e59a4a07aeb52a5cfeabe._comment b/doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_3_25fe06eb127e59a4a07aeb52a5cfeabe._comment
new file mode 100644
index 0000000000..fd97f6a21d
--- /dev/null
+++ b/doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_3_25fe06eb127e59a4a07aeb52a5cfeabe._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 3"
+ date="2013-07-08T18:22:18Z"
+ content="""
+`cabal install` also creates the git-annex-shell symlink. I have filed a bug on the ebuild: <https://github.com/gentoo-haskell/gentoo-haskell/issues/247>
+"""]]
diff --git a/doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_4_ec78032ba62d6918baa2c0b07ead5b50._comment b/doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_4_ec78032ba62d6918baa2c0b07ead5b50._comment
new file mode 100644
index 0000000000..86f1b46f0b
--- /dev/null
+++ b/doc/bugs/make_install_doesn__39__t_create_git-annex-shell/comment_4_ec78032ba62d6918baa2c0b07ead5b50._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm01ida6POv7vqyUYtOlymEbJTbrImAIzM"
+ nickname="Reinis"
+ subject="comment 4"
+ date="2013-07-08T18:44:59Z"
+ content="""
+Thanks! That leaves the issue that even when manually creating the symlink it still errors out (second half of the log in original report), but that probably is another issue. Should I open separate report for it? There was something similar in [[http://git-annex.branchable.com/bugs/Rsync_remote_created_via_webapp_remains_empty/]], but the command= part was in the file on my local computer only and removing it didn't make any difference.
+"""]]
diff --git a/doc/bugs/matching_option_--onlyingroup_works_only_partially.mdwn b/doc/bugs/matching_option_--onlyingroup_works_only_partially.mdwn
new file mode 100644
index 0000000000..706c36b6e7
--- /dev/null
+++ b/doc/bugs/matching_option_--onlyingroup_works_only_partially.mdwn
@@ -0,0 +1,541 @@
+### Please describe the problem.
+
+Thanks for implementing the `--onlyingroup=` matching option and the corresponding
+preferred content expression but it seems that at least the matching option does not work
+quite all the way how it was intended (as far as I understand).
+
+### What steps will reproduce the problem?
+
+Consider the following facts:
+
+  - there is a single file 'a-1' added to the repo annex-a;
+  - annex-b, annex-c, annex-d are git clones of annex-a;
+  - the file 'a-1' is not present in annex-d as an annex object;
+  - annex-a is in group 'main'; 
+  - annex-c and annex-d are in group 'backup'; and also
+  - annex-b, annex-c, and annex-d are in group 'offline'.
+
+Also there is no such group as 'foo'. Then the following `list` and `find` commands are issued:
+
+[[!format sh """
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex list
+here
+|annex-b
+||annex-c
+|||annex-d
+||||web
+|||||bittorrent
+||||||
+XXX___ a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --inallgroup=main
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroup=main
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --inallgroup=backup
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroup=backup
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --inallgroup=offline
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroup=offline
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --inallgroup=foo
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroup=foo
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex version --raw
+10.20230802-gd19139a10d
+"""]]
+
+Using the notation introduced by `--explain`, I would personally evaluate the above propositions as:
+
+  - --inallgroup=main[TRUE] ok
+  - --onlyingroup=main[FALSE] (is present also in groups 'backup' and 'offline'), yet find considers this TRUE
+  - --inallgroup=backup[FALSE] (is not present in annex-d which is in 'backup') ok
+  - --onlyingroup=backup[FALSE] (is also present in the disjoint group 'main'), yet find considers this TRUE
+  - --inallgroup=offline[FALSE] (is not present in annex-d which is in 'offline') ok
+  - --onlyingroup=offline[FALSE] (is also present in the disjoint group 'main'), yet find considers this TRUE
+  - --inallgroup=foo[FALSE] (there is no such group 'foo' so how can the file be present?), yet find considers this TRUE
+  - --onlyingroup=foo[FALSE] ok
+
+So, what gives? It seems that `--onlyingroup` only makes sure that the first part of the following specification
+matches:
+
+    Matches only when git-annex believes content is present in at least one
+    repository that is in the specified group, and is not present in any
+    repositories that are not in the specified group.
+
+Notice that (in at least the particular case above) it doesn't make sure that
+the content should not be present in any repositories that are in disjoint groups.
+So the "only" meaning seems to be missing here making this effectively into a (lax)
+`--ingroup=` matching option.
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20230802-gd19139a10d
+build flags: Assistant Webapp Pairing TorrentParser Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+local repository version: 10
+"""]]
+
+This is a build that has been attained by using the Windows-specific stack.yaml
+(by giving the option `--stack-yaml stack-lts-18.13.yaml` for stack).
+
+Windows 10 version 22H2 (build 19045.3208), 64 bit.
+
+### Please provide any additional information below.
+
+My apologies in advance for the long transcript :)
+
+[[!format sh """
+PowerShell 7.3.6
+* Istunto aloitettu hetkellä la 05.08.2023 klo 00:28:40 +03:00. Session started on Sat 05-Aug-2023 @ 00:28:41 +03:00.
+Loading personal and system profiles took 2630ms.
+C:\Users\jkniiv> cd e:\git-annex-tests
+E:\git-annex-tests> mkdir test-onlyingroup-matching2
+
+    Directory: E:\git-annex-tests
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+d----            5.8.2023     0:29                test-onlyingroup-matching2
+
+E:\git-annex-tests> cd .\test-onlyingroup-matching2\
+E:\git-annex-tests\test-onlyingroup-matching2> git init annex-a
+Initialized empty Git repository in E:/git-annex-tests/test-onlyingroup-matching2/annex-a/.git/
+E:\git-annex-tests\test-onlyingroup-matching2> cd annex-a
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [master]> git annex init annex-a
+init annex-a
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Switched to branch 'adjusted/master(unlocked)'
+ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> cd ..
+E:\git-annex-tests\test-onlyingroup-matching2> git clone annex-a annex-b
+Cloning into 'annex-b'...
+done.
+E:\git-annex-tests\test-onlyingroup-matching2> git clone annex-a annex-c
+Cloning into 'annex-c'...
+done.
+E:\git-annex-tests\test-onlyingroup-matching2> git clone annex-a annex-d
+Cloning into 'annex-d'...
+done.
+E:\git-annex-tests\test-onlyingroup-matching2> ls
+
+    Directory: E:\git-annex-tests\test-onlyingroup-matching2
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+d----            5.8.2023     0:29                annex-a
+d----            5.8.2023     0:32                annex-b
+d----            5.8.2023     0:32                annex-c
+d----            5.8.2023     0:32                annex-d
+
+E:\git-annex-tests\test-onlyingroup-matching2> cd annex-b
+E:\git-annex-tests\test-onlyingroup-matching2\annex-b [adjusted/master(unlocked) ≡]> git config --add remote.origin.fetch '^refs/heads/adjusted/*'
+E:\git-annex-tests\test-onlyingroup-matching2\annex-b [adjusted/master(unlocked) ≡]> cat .git\config
+[core]
+        repositoryformatversion = 0
+        filemode = false
+        bare = false
+        logallrefupdates = true
+        symlinks = false
+        ignorecase = true
+[remote "origin"]
+        url = E:/git-annex-tests/test-onlyingroup-matching2/annex-a
+        fetch = +refs/heads/*:refs/remotes/origin/*
+        fetch = ^refs/heads/adjusted/*
+[branch "adjusted/master(unlocked)"]
+        remote = origin
+        merge = refs/heads/adjusted/master(unlocked)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-b [adjusted/master(unlocked) ≡]> git annex init annex-b
+init annex-b
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-b [adjusted/master(unlocked) ≡]> cd ..\annex-c
+E:\git-annex-tests\test-onlyingroup-matching2\annex-c [adjusted/master(unlocked) ≡]> git config --add remote.origin.fetch '^refs/heads/adjusted/*'
+E:\git-annex-tests\test-onlyingroup-matching2\annex-c [adjusted/master(unlocked) ≡]> git annex init annex-c
+init annex-c
+[...snip...]
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-c [adjusted/master(unlocked) ≡]> cd ..\annex-d
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ≡]> git config --add remote.origin.fetch '^refs/heads/adjusted/*'
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ≡]> git annex init annex-d
+init annex-d
+[...snip...]
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ≡]> cd ..\annex-a
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git remote add annex-b ..\annex-b
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git remote add annex-c ..\annex-c
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git remote add annex-d ..\annex-d
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git config --add remote.annex-b.fetch '^refs/heads/adjusted/*'
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git config --add remote.annex-c.fetch '^refs/heads/adjusted/*'
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git config --add remote.annex-d.fetch '^refs/heads/adjusted/*'
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex sync -g
+commit
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+ok
+pull annex-d
+remote: Enumerating objects: 5, done.
+remote: Counting objects: 100% (5/5), done.
+remote: Compressing objects: 100% (2/2), done.
+remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
+Unpacking objects: 100% (3/3), 332 bytes | 30.00 KiB/s, done.
+From ..\annex-d
+ * [new branch]      git-annex  -> annex-d/git-annex
+ * [new branch]      master     -> annex-d/master
+ok
+pull annex-c
+[...snip...]
+pull annex-b
+[...snip...]
+(merging annex-b/git-annex annex-c/git-annex annex-d/git-annex into git-annex...)
+(recording state in git...)
+push annex-d
+Enumerating objects: 13, done.
+Counting objects: 100% (13/13), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (6/6), done.
+Writing objects: 100% (9/9), 843 bytes | 421.00 KiB/s, done.
+Total 9 (delta 4), reused 0 (delta 0), pack-reused 0
+To ..\annex-d
+ * [new branch]      master -> synced/master
+ * [new branch]      git-annex -> synced/git-annex
+ok
+push annex-c
+[...snip...]
+push annex-b
+[...snip...]
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex wanted . present
+wanted . ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex group . main
+group . ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> cd ..\annex-b
+E:\git-annex-tests\test-onlyingroup-matching2\annex-b [adjusted/master(unlocked) ≡]> git annex group . offline
+group . ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-b [adjusted/master(unlocked) ≡]> cd ..\annex-c
+E:\git-annex-tests\test-onlyingroup-matching2\annex-c [adjusted/master(unlocked) ≡]> git annex wanted . standard
+wanted . ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-c [adjusted/master(unlocked) ≡]> git annex group . backup
+group . ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-c [adjusted/master(unlocked) ≡]> git annex group . offline
+group . ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-c [adjusted/master(unlocked) ≡]> git annex group .
+backup offline
+E:\git-annex-tests\test-onlyingroup-matching2\annex-c [adjusted/master(unlocked) ≡]> cd ..\annex-d
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ≡]> git annex wanted . standard
+wanted . ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ≡]> git annex group . backup
+group . ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ≡]> git annex group . offline
+group . ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ≡]> git annex group .
+backup offline
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ≡]> cd ..\annex-a
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> ls
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> echo aaa-1 > a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked) +1 ~0 -0 !]> ls
+
+    Directory: E:\git-annex-tests\test-onlyingroup-matching2\annex-a
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---            5.8.2023     0:45              7 a-1
+
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked) +1 ~0 -0 !]> git annex add .\a-1
+add a-1
+ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked) +1 ~0 -0 ~]> git status
+On branch adjusted/master(unlocked)
+Changes to be committed:
+  (use "git restore --staged <file>..." to unstage)
+        new file:   a-1
+
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked) +1 ~0 -0 ~]> git commit -m 'add a-1'
+[adjusted/master(unlocked) 1fad99e] add a-1
+ 1 file changed, 1 insertion(+)
+ create mode 100644 a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> ls
+
+    Directory: E:\git-annex-tests\test-onlyingroup-matching2\annex-a
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---            5.8.2023     0:45              7 a-1
+
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex sync --content
+commit
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+ok
+pull annex-d
+remote: Enumerating objects: 10, done.
+remote: Counting objects: 100% (10/10), done.
+remote: Compressing objects: 100% (9/9), done.
+remote: Total 9 (delta 1), reused 0 (delta 0), pack-reused 0
+Unpacking objects: 100% (9/9), 1008 bytes | 56.00 KiB/s, done.
+From ..\annex-d
+   ee601cf..9c59e4d  git-annex  -> annex-d/git-annex
+ok
+pull annex-c
+[...snip...]
+pull annex-b
+[...snip...]
+(merging annex-b/git-annex annex-c/git-annex annex-d/git-annex into git-annex...)
+(recording state in git...)
+copy a-1 (to annex-d...)
+ok
+copy a-1 (to annex-c...)
+ok
+copy a-1 (to annex-b...)
+ok
+pull annex-d
+ok
+pull annex-c
+ok
+pull annex-b
+ok
+(recording state in git...)
+push annex-d
+Enumerating objects: 40, done.
+Counting objects: 100% (40/40), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (32/32), done.
+Writing objects: 100% (35/35), 3.65 KiB | 623.00 KiB/s, done.
+Total 35 (delta 7), reused 0 (delta 0), pack-reused 0
+To ..\annex-d
+   ee601cf..7a0c374  git-annex -> synced/git-annex
+   c9731e7..6e57e3e  master -> synced/master
+ok
+push annex-c
+[...snip...]
+push annex-b
+[...snip...]
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> cd ..
+E:\git-annex-tests\test-onlyingroup-matching2> ls
+
+    Directory: E:\git-annex-tests\test-onlyingroup-matching2
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+d----            5.8.2023     0:45                annex-a
+d----            5.8.2023     0:32                annex-b
+d----            5.8.2023     0:32                annex-c
+d----            5.8.2023     0:32                annex-d
+
+E:\git-annex-tests\test-onlyingroup-matching2> cd annex-b
+E:\git-annex-tests\test-onlyingroup-matching2\annex-b [adjusted/master(unlocked) ≡]> git annex sync -g
+commit
+On branch adjusted/master(unlocked)
+Your branch is up to date with 'origin/adjusted/master(unlocked)'.
+
+nothing to commit, working tree clean
+ok
+merge synced/master master (Merging into master...)
+Updating c9731e7..6e57e3e
+Fast-forward
+ a-1 | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 a-1
+(Merging into adjusted branch...)
+Updating bffc83c..4daa3a7
+Fast-forward
+ a-1 | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 a-1
+
+Already up to date.
+(Merging into adjusted branch...)
+Updating 76cec61..68d290a
+Fast-forward
+ok
+pull origin
+[...snip...]
+push origin
+[...snip...]
+E:\git-annex-tests\test-onlyingroup-matching2\annex-b [adjusted/master(unlocked) ↓1 ↑2]> ls
+
+    Directory: E:\git-annex-tests\test-onlyingroup-matching2\annex-b
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---            5.8.2023     0:47              7 a-1
+
+E:\git-annex-tests\test-onlyingroup-matching2\annex-b [adjusted/master(unlocked) ↓1 ↑2]> cat a-1
+aaa-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-b [adjusted/master(unlocked) ↓1 ↑2]> cd ..\annex-c
+E:\git-annex-tests\test-onlyingroup-matching2\annex-c [adjusted/master(unlocked) ≡]> git annex sync -g
+commit
+[...snip...]
+merge synced/master master (Merging into master...)
+[...snip...]
+(Merging into adjusted branch...)
+[...snip...]
+Already up to date.
+(Merging into adjusted branch...)
+[...snip...]
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+[...snip...]
+E:\git-annex-tests\test-onlyingroup-matching2\annex-c [adjusted/master(unlocked) ↓1 ↑2]> ls
+
+    Directory: E:\git-annex-tests\test-onlyingroup-matching2\annex-c
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---            5.8.2023     0:47              7 a-1
+
+E:\git-annex-tests\test-onlyingroup-matching2\annex-c [adjusted/master(unlocked) ↓1 ↑2]> cd ..\annex-d
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ≡]> git annex sync -g
+commit
+[...snip...]
+merge synced/master master (Merging into master...)
+[...snip...]
+(Merging into adjusted branch...)
+[...snip...]
+Already up to date.
+(Merging into adjusted branch...)
+[...snip...]
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+[...snip...]
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ↓1 ↑2]> ls
+
+    Directory: E:\git-annex-tests\test-onlyingroup-matching2\annex-d
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---            5.8.2023     0:47              7 a-1
+
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ↓1 ↑2]> cd ..\annex-a
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex list
+here
+|annex-b
+||annex-c
+|||annex-d
+||||web
+|||||bittorrent
+||||||
+XXXX__ a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --inallgroup=main
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroup=main
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --inallgroup=backup
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroup=backup
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --inallgroup=offline
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroup=offline
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --inallgroup=foo
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroup=foo
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroups=foo
+Invalid option `--onlyingroups=foo'
+
+Usage: git-annex COMMAND
+[...snip...]
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> cd ..\annex-d
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ↓1 ↑2]> ls
+
+    Directory: E:\git-annex-tests\test-onlyingroup-matching2\annex-d
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---            5.8.2023     0:47              7 a-1
+
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ↓1 ↑2]> git annex drop a-1
+drop a-1 ok
+(recording state in git...)
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ↓1 ↑2]> git annex sync -g
+commit
+On branch adjusted/master(unlocked)
+Your branch and 'origin/adjusted/master(unlocked)' have diverged,
+and have 2 and 1 different commits each, respectively.
+  (use "git pull" to merge the remote branch into yours)
+
+nothing to commit, working tree clean
+ok
+pull origin
+ok
+push origin
+[...snip...]
+E:\git-annex-tests\test-onlyingroup-matching2\annex-d [adjusted/master(unlocked) ↓1 ↑2]> cd ..\annex-a
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex sync -g
+commit
+[...snip...]
+pull annex-d
+[...snip...]
+pull annex-c
+[...snip...]
+pull annex-b
+[...snip...]
+push annex-c
+[...snip...]
+push annex-b
+[...snip...]
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex list
+here
+|annex-b
+||annex-c
+|||annex-d
+||||web
+|||||bittorrent
+||||||
+XXX___ a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --inallgroup=main
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroup=main
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --inallgroup=backup
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroup=backup
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --inallgroup=offline
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroup=offline
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --inallgroup=foo
+a-1
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex find --onlyingroup=foo
+E:\git-annex-tests\test-onlyingroup-matching2\annex-a [adjusted/master(unlocked)]> git annex version --raw
+10.20230802-gd19139a10d
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sure, Git Annex is great as always. I use it several times a week with my multigigabyte
+backups, where it gives structure to my image-based backup routines, so you could
+say I'm a believer. :)
+
+[[!meta author=jkniiv]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/matching_option_--onlyingroup_works_only_partially/comment_1_001927fce7b1c194076f76a092af414e._comment b/doc/bugs/matching_option_--onlyingroup_works_only_partially/comment_1_001927fce7b1c194076f76a092af414e._comment
new file mode 100644
index 0000000000..de3c4841fe
--- /dev/null
+++ b/doc/bugs/matching_option_--onlyingroup_works_only_partially/comment_1_001927fce7b1c194076f76a092af414e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 1"
+ date="2023-08-08T16:38:53Z"
+ content="""
+That repair was quick and to the point, thanks. It seems to work now as specified.
+
+"""]]
diff --git a/doc/bugs/merge_causes_out_of_memory_on_large_repos.mdwn b/doc/bugs/merge_causes_out_of_memory_on_large_repos.mdwn
new file mode 100644
index 0000000000..c081f9799e
--- /dev/null
+++ b/doc/bugs/merge_causes_out_of_memory_on_large_repos.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+
+`git annex merge` goes out of memory on a large repo.
+
+
+### What steps will reproduce the problem?
+
+    $ git annex merge
+    merge git-annex git-annex: out of memory (requested 1048576 bytes)
+
+### What version of git-annex are you using? On what operating system?
+
+    git-annex version: 4.20130827
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS
+
+On debian wheezy i386
+
+### Please provide any additional information below.
+
+The repository contains a lot of files:
+
+    $ cd .git/objects
+    $ find . -type f | wc -l 
+    1091548
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_1_6d47485728ea65a9b555f8be7159dea5._comment b/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_1_6d47485728ea65a9b555f8be7159dea5._comment
new file mode 100644
index 0000000000..f87a9a84d1
--- /dev/null
+++ b/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_1_6d47485728ea65a9b555f8be7159dea5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnxlx1UrzVhdy6_gFjzmF42x6QXxBUxg00"
+ nickname="Jakukyo"
+ subject="pre-commit hook of git annex"
+ date="2013-09-11T00:58:09Z"
+ content="""
+The pre-commit hook of git annex throws an 'out of memory' error, too.
+
+As a workaround, I've deleted ~/.git/hooks/pre-commit, and use `git merge` manually.
+"""]]
diff --git a/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_2_06723d13ecdaf87de5ff2b209e3c5198._comment b/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_2_06723d13ecdaf87de5ff2b209e3c5198._comment
new file mode 100644
index 0000000000..76a0d2fd48
--- /dev/null
+++ b/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_2_06723d13ecdaf87de5ff2b209e3c5198._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.2.134"
+ subject="comment 2"
+ date="2013-09-13T18:38:11Z"
+ content="""
+Can you run this so I can get a better idea of the size of this repository:
+
+git ls-tree -r git-annex | wc -l
+"""]]
diff --git a/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_3_9f83ef190547b291a715cda55b7977d4._comment b/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_3_9f83ef190547b291a715cda55b7977d4._comment
new file mode 100644
index 0000000000..11f03b39d9
--- /dev/null
+++ b/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_3_9f83ef190547b291a715cda55b7977d4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.105"
+ subject="comment 3"
+ date="2013-09-19T18:53:14Z"
+ content="""
+I just fixed a memory leak that occurred when large files were checked directly into git (perhaps by accident by committing files manually when using direct mode). However, I don't think it affected `git annex merge`. 
+
+Still need information about how to reproduce this bug...
+"""]]
diff --git a/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_4_0e32ae0300472c56079cfbcd78a3e386._comment b/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_4_0e32ae0300472c56079cfbcd78a3e386._comment
new file mode 100644
index 0000000000..d1c447980c
--- /dev/null
+++ b/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_4_0e32ae0300472c56079cfbcd78a3e386._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnxlx1UrzVhdy6_gFjzmF42x6QXxBUxg00"
+ nickname="Jakukyo"
+ subject="size of repo"
+ date="2013-09-21T09:32:03Z"
+ content="""
+    $ git ls-tree -r git-annex | wc -l
+    29273
+"""]]
diff --git a/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_5_e8998716107e7ae8d0e8d332812517ad._comment b/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_5_e8998716107e7ae8d0e8d332812517ad._comment
new file mode 100644
index 0000000000..272dc2fd2d
--- /dev/null
+++ b/doc/bugs/merge_causes_out_of_memory_on_large_repos/comment_5_e8998716107e7ae8d0e8d332812517ad._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.220"
+ subject="comment 5"
+ date="2013-09-25T18:36:39Z"
+ content="""
+That doesn't look very big, I merge one 3x that large on a 128 mb machine.
+
+I think you will need to either email me privately so I can get a copy of your repository to investigate with ... or you can try to investigate on your own. 
+
+I think the first things I would try to debug this are to look over `git annex merge --debug` and see if I see anything unusual, and then I would probably `git checkout git-annex` in the repository, and wc -l on all the files and see if any file has a lot of lines, or is otherwise very large.
+
+If that found nothing, my next step would be to rebuild git-annex from source with memory profiling enabled, as explained in this book, and try to get a memory profiling graph that explained what was using up the memory. <http://book.realworldhaskell.org/read/profiling-and-optimization.html>
+"""]]
diff --git a/doc/bugs/metadata_view_does_not_vpop_to_original_view.mdwn b/doc/bugs/metadata_view_does_not_vpop_to_original_view.mdwn
new file mode 100644
index 0000000000..1d51181647
--- /dev/null
+++ b/doc/bugs/metadata_view_does_not_vpop_to_original_view.mdwn
@@ -0,0 +1,41 @@
+### Please describe the problem.
+
+I added some metadata to my music repository and tried a metadata-driven view. 
+
+    git annex view composer=* performer=
+
+When I wanted to return to the original list of directories and files, that fails. I now only see a list of directories that contain files which are actually on my laptop, and the generated views.
+
+When I did git annex vpop, I got the following:
+
+    frederik@freo:~/Music$ git annex vpop
+    vpop 1 
+    error: Your local changes to the following files would be overwritten by checkout:
+      Mozart, Wolfgang Amadeus/Academy of St. Martin in the Fields/01. Wolfgang Amadeus Mozart - Serenade No. 10 in B-flat major, KV 361 _Gran Partita_ - Ia. Largo_%Wolfgang Amadeus Mozart - Serenade No. 10 in B-flat major, KV 361 _Gran Partita_ (Academy of St. Martin in the Fields feat. conductor - Sir Neville Marriner)%.flac
+        Mozart, Wolfgang Amadeus/Academy of St. Martin in the Fields/02. Wolfgang Amadeus Mozart - Serenade No. 10 in B-flat major, KV 361 _Gran Partita_ - Ib. Allegro molto_%Wolfgang Amadeus Mozart - Serenade No. 10 in B-flat major, KV 361 _Gran Partita_ (Academy of St. Martin in the Fields feat. conductor - Sir Neville Marriner)%.flac
+
+I had not actually altered any of these files. I merely cd'd into the directory and did an ls to see what it looked like.
+
+The view is also not generated correctly, as re-running 
+
+    git annex view composer=* performer=
+
+gives me a list of directories with several directories that should not be present in the view.
+
+So far, I'm unable to go back to the original state.
+
+
+
+### What version of git-annex are you using? On what operating system?
+
+Debian/Jessie
+
+git-annex version: 5.20141125
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+
+
diff --git a/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_1_91c69150533cb6c2147dcf2eb480ef39._comment b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_1_91c69150533cb6c2147dcf2eb480ef39._comment
new file mode 100644
index 0000000000..bd66cb8e1b
--- /dev/null
+++ b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_1_91c69150533cb6c2147dcf2eb480ef39._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2015-06-03T14:33:35Z"
+ content="""
+You should be able to get back to the original state (in terms of working directory) by checking out the 'master' branch (or whatever branch you started the view from):
+
+    git checkout master
+"""]]
diff --git a/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_2_ca1cc0b0e5c53daffd0b5ca78a6ac43f._comment b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_2_ca1cc0b0e5c53daffd0b5ca78a6ac43f._comment
new file mode 100644
index 0000000000..a38b27f9e3
--- /dev/null
+++ b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_2_ca1cc0b0e5c53daffd0b5ca78a6ac43f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2015-06-03T14:40:12Z"
+ content="""
+Oh, you may also need to clean up directories files left over from the view with:
+
+    git clean -fd
+
+This will remove everything not ignored or tracked!
+"""]]
diff --git a/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_3_63bef9006a1e4ba2ebbfafbdf605a9e1._comment b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_3_63bef9006a1e4ba2ebbfafbdf605a9e1._comment
new file mode 100644
index 0000000000..dffc6e2d5c
--- /dev/null
+++ b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_3_63bef9006a1e4ba2ebbfafbdf605a9e1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-06-03T17:25:28Z"
+ content="""
+The only way I can reproduce this is if I use `git annex edit` while inside
+the view.
+
+It might be that there's some kind of unclean git tree that can cause a
+problem when entering a view, but I was not able to find one.
+
+Please provide clear instructions how to reproduce this problem.
+"""]]
diff --git a/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_4_4873f0bc670b193cec3be327ee178a13._comment b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_4_4873f0bc670b193cec3be327ee178a13._comment
new file mode 100644
index 0000000000..7dbdaf0fa9
--- /dev/null
+++ b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_4_4873f0bc670b193cec3be327ee178a13._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="frederik@ffbea6a549cb3f460d110386c0f634c1ddc6a68a"
+ nickname="frederik"
+ subject="file name too long"
+ date="2015-06-04T04:49:23Z"
+ content="""
+OK, when I try git checkout master, it fails with some of these errors:
+
+    frederik@freo:~/Music$ git checkout master
+    error: cannot stat 'Händel, Georg Friedrich/Oregon Bach Festival Choir & Orchestra/09. George Frideric Handel - O Thou That Tellest Good Tidings to Zion--Air (Alto)_\%George Frideric Handel - The Messiah (feat. Oregon Bach Festival Choir & Orchestra -Rilling) (Disc 1 of 2)\%_%Händel, Georg Friedrich%Oregon Bach Festival Choir & Orchestra%.flac': File name too long
+
+These filenames have been created by git annex when creating the view. The original one is rather long too:
+
+    09. George Frideric Handel - O Thou That Tellest Good Tidings to Zion--Air (Alto).flac
+
+In directory:
+
+    Music/George Frideric Handel - The Messiah (feat. Oregon Bach Festival Choir & Orchestra -Rilling) (Disc 1 of 2)
+
+It looks like this has something to do with the problem.
+
+When I do git clean -fd, I only have the 2 directories left as created by the view. I still can't do git annex vpop anymore, as the reply is that I'm not in a view anymore.
+
+Some more info on that one file:
+
+    frederik@freo:~/Music/Händel, Georg Friedrich/Oregon Bach Festival Choir & Orchestra$ git annex metadata 09.\ George\ Frideric\ Handel\ -\ O\ Thou\ That\ Tellest\ Good\ Tidings\ to\ Zion--Air\ \(Alto\)_%George\ Frideric\ Handel\ -\ The\ Messiah\ \(feat.\ Oregon\ Bach\ Festival\ Choir\ \&\ Orchestra\ -Rilling\)\ \(Disc\ 1\ of\ 2\)%.flac
+    metadata 09. George Frideric Handel - O Thou That Tellest Good Tidings to Zion--Air (Alto)_%George Frideric Handel - The Messiah (feat. Oregon Bach Festival Choir & Orchestra -Rilling) (Disc 1 of 2)%.flac 
+      album=The Messiah
+      album-lastchanged=2015-06-03@13-27-45
+      codec=flac
+      codec-lastchanged=2015-06-03@13-27-45
+      composer=Händel, Georg Friedrich
+      composer-lastchanged=2015-06-03@13-27-45
+      genre=classical
+      genre-lastchanged=2015-06-03@13-27-45
+      lastchanged=2015-06-03@13-27-45
+      performer=Oregon Bach Festival Choir & Orchestra
+      performer-lastchanged=2015-06-03@13-27-45
+      tag=music
+      tag-lastchanged=2015-06-03@13-27-45
+    ok
+
+
+
+"""]]
diff --git a/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_5_bf63c9d3e0de468ffa5856dcf7c313b7._comment b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_5_bf63c9d3e0de468ffa5856dcf7c313b7._comment
new file mode 100644
index 0000000000..2681d3aa87
--- /dev/null
+++ b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_5_bf63c9d3e0de468ffa5856dcf7c313b7._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 5"
+ date="2015-06-04T09:05:18Z"
+ content="""
+I can at least reproduce the error.
+
+http://stackoverflow.com/questions/6571435/limit-on-file-name-length-in-bash
+
+    mkdir /tmp/pathtest
+    cd /tmp/pathtest
+    mkdir 'Händel, Georg Friedrich/Oregon Bach Festival Choir & Orchestra/'
+    mkdir: created directory ‘Händel, Georg Friedrich’
+    mkdir: created directory ‘Händel, Georg Friedrich/Oregon Bach Festival Choir & Orchestra/’
+    touch 'Händel, Georg Friedrich/Oregon Bach Festival Choir & Orchestra/09. George Frideric Handel - O Thou That Tellest Good Tidings to Zion--Air (Alto)_\%George Frideric Handel - The Messiah (feat. Oregon Bach Festival Choir & Orchestra -Rilling) (Disc 1 of 2)\%_%Händel, Georg Friedrich%Oregon Bach Festival Choir & Orchestra%.flac'
+    touch: cannot touch ‘Händel, Georg Friedrich/Oregon Bach Festival Choir & Orchestra/09. George Frideric Handel - O Thou That Tellest Good Tidings to Zion--Air (Alto)_\\%George Frideric Handel - The Messiah (feat. Oregon Bach Festival Choir & Orchestra -Rilling) (Disc 1 of 2)\\%_%Händel, Georg Friedrich%Oregon Bach Festival Choir & Orchestra%.flac’: File name too long
+
+In my case, I cannot create the file because the filename is 262 bytes long, and either ext3 or bash have a filename limit of 255 bytes.
+
+You may have to delete it using its inode or the \"rsync --delete with empty directory\" trick to get rid of it. Odd how git-annex managed to create it in the first place though..
+
+"""]]
diff --git a/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_6_83e389f5fdd58ffd62ead898ddbb5279._comment b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_6_83e389f5fdd58ffd62ead898ddbb5279._comment
new file mode 100644
index 0000000000..ea507f001f
--- /dev/null
+++ b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_6_83e389f5fdd58ffd62ead898ddbb5279._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="frederik@ffbea6a549cb3f460d110386c0f634c1ddc6a68a"
+ nickname="frederik"
+ subject="comment 6"
+ date="2015-06-04T11:54:20Z"
+ content="""
+I'm not really comfortable deleting anything at the moment, without knowing I'll be able to get the data back on my local annex. Having to transfer everything back from the remote will take a long while. I guess I could tar it up first.
+"""]]
diff --git a/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_7_a5511e21ee6c09d8edf2bca48482d848._comment b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_7_a5511e21ee6c09d8edf2bca48482d848._comment
new file mode 100644
index 0000000000..cbfa90038d
--- /dev/null
+++ b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_7_a5511e21ee6c09d8edf2bca48482d848._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 7"
+ date="2015-06-04T12:18:20Z"
+ content="""
+If I were in this situation, I would clone the broken repo, check the symlinks look correct in the clone, 'git annex reinit' it with the broken repos UUID, move .git/annex/objects to the clone, fsck and replace the broken one with the clone (just move the broken one aside if you want to keep it around).
+
+I don't think you can lose any data this way. Though any files you added while in the view (which you shouldn't do anyway) will be present in the annex, but have no symlink (they will show up in 'unused').
+"""]]
diff --git a/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_8_ef3e8e1c47984fc674e58646052205ef._comment b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_8_ef3e8e1c47984fc674e58646052205ef._comment
new file mode 100644
index 0000000000..df5515ff14
--- /dev/null
+++ b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_8_ef3e8e1c47984fc674e58646052205ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="frederik@ffbea6a549cb3f460d110386c0f634c1ddc6a68a"
+ nickname="frederik"
+ subject="Any more info needed"
+ date="2015-07-27T13:47:11Z"
+ content="""
+Hi Joey, while I was able to recover from the issue mentioned above, I have yet to try using the metadata views again out of uncertainty about the root cause of the problem I encountered. Is there anything more I could provide to determine what caused this problem and how to avoid it next time I try?
+"""]]
diff --git a/doc/bugs/migrate_and_move_duplicates_data.mdwn b/doc/bugs/migrate_and_move_duplicates_data.mdwn
new file mode 100644
index 0000000000..4f962cdb26
--- /dev/null
+++ b/doc/bugs/migrate_and_move_duplicates_data.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+I have a main annex with ~2TB of data. In the past is was using SHA256 then I migrated to SHA256E . Recently it was becoming quite full so I took some spare HD and cloned it and moved data from the main to the spares. To my surprise, the main annex disk usage did not go down a bit.
+
+It took me some time to understand why . The problem is exemplified by the  shell script  <http://mennucc1.debian.net/git-annex/git-annex-no-dedup.sh> .
+
+In short, if a annex is migrated to a new backend and afterwards files are moved, then the hardlinks are broken, and disk usage doubles.
+
+### What steps will reproduce the problem?
+
+run above script
+
+### What version of git-annex are you using? On what operating system?
+
+ 5.20141125  on Debian Jessie amd64
+
+### Please provide any additional information below.
+
+Of course a simple solution would be to drop all unused files. This is ugly , though, because it does not distinguish between
+(1) unused files that are previous copies of files I care about (2) unused files that are due to the problem described in the example, and that I do not care about.
+
+A more complex but more elegant solution would be:
+
+(a) when a file is migrated , the old and new objects in the annex are hardlinked; moreover two symlinks should be creates, so that git-annex knows at a glance which two files are hardlinked (see <http://mennucc1.debian.net/git-annex/cross_links.txt> for example)
+
+(b) when moving of copying files, all hardlinked versions whould be move/copied
+
+(c) when dropping , an option may be used to specify if all hardlinked versions should be dropped alltogether
+
+### bye
+
+and thanks, A.
+
+### ps
+
+I tried to attach two files to this bug report but failed
diff --git a/doc/bugs/migrate_and_move_duplicates_data/comment_1_ac3c5c141992c7b5d2cc36e085b0cba8._comment b/doc/bugs/migrate_and_move_duplicates_data/comment_1_ac3c5c141992c7b5d2cc36e085b0cba8._comment
new file mode 100644
index 0000000000..83af05970b
--- /dev/null
+++ b/doc/bugs/migrate_and_move_duplicates_data/comment_1_ac3c5c141992c7b5d2cc36e085b0cba8._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-17T15:41:53Z"
+ content="""
+I don't feel that migration is an important enough feature to complicate
+the rest of git-annex with special handling of multiple keys that point to
+the same content.
+
+You could have used `mv` in your use case to move the repo to the new drive
+while preseving hard links.
+
+What might be useful is for `git annex migrate` to write a list of the old keys
+someplace. These could then be dropped when the user wants to get rid of them,
+with mixing them up with other unused files. Although if you care about old
+versions of files and don't want to drop them as unused, it seems to me you'd
+also want to be able to access the old keys from before the migration.
+"""]]
diff --git a/doc/bugs/migrate_and_move_duplicates_data/comment_2_68a876f2eed5c446d92367aae4070408._comment b/doc/bugs/migrate_and_move_duplicates_data/comment_2_68a876f2eed5c446d92367aae4070408._comment
new file mode 100644
index 0000000000..8163bc212d
--- /dev/null
+++ b/doc/bugs/migrate_and_move_duplicates_data/comment_2_68a876f2eed5c446d92367aae4070408._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="mennucc1@6758d6a3817a0a6b29e8adbdb068c5ba35f6992b"
+ nickname="mennucc1"
+ subject="hack"
+ date="2015-07-18T09:16:03Z"
+ content="""
+hi  Joey, thanks for your interest;
+
+I created a script to address this problem
+
+<http://mennucc1.debian.net/git-annex/git-annex_de-re-link_hash-E>
+
+it can relink keys that are not hardlinked anymore (-L option) ; it can use an unsed key to recreate a missin key (-R option) ; it can also drop redundant keys (-D option)
+
+a.
+"""]]
diff --git a/doc/bugs/migrate_removes_associated_URLs_with_custom_scheme.mdwn b/doc/bugs/migrate_removes_associated_URLs_with_custom_scheme.mdwn
new file mode 100644
index 0000000000..7ebff66146
--- /dev/null
+++ b/doc/bugs/migrate_removes_associated_URLs_with_custom_scheme.mdwn
@@ -0,0 +1,142 @@
+### Please describe the problem.
+
+With URLs that are handled by the web remote the URL will be kept through a migration, i.e.
+
+```
+git annex addurl --relaxed <some-http-url>
+git annex get <the-added-file>
+git annex migrate
+```
+
+will migrate the key of the file to be hash based, and keep the URL associated to that key.
+If I do the same with a URL whose scheme is handled by a custom special remote (this one specifically is what I got the issue with: <https://github.com/matrss/datalad-cds/blob/main/src/datalad_cds/cds_remote.py>, it registers itself for the `cds:` scheme), the URL seems to be dropped from the key (i.e. whereis no longer shows it and git annex can no longer fetch it from the special remote).
+
+### What steps will reproduce the problem?
+
+The steps mentioned above for a URL whose scheme is handled by an (external?) special remote. Specifically, I saw it with datalad-cds, it might happen for other special remotes as well.
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 10.20231129
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24.1 bloomfilter-2.0.1.2 crypton-0.32 DAV-1.3.4 feed-1.3.2.1 ghc-9.4.8 http-client-0.7.15 persistent-sqlite-2.13.3.0 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+Installed with nix from nixpkgs on an ubuntu system.
+
+### Please provide any additional information below.
+
+It works with the web remote:
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+$ datalad create test-ds
+create(ok): [...] (dataset)
+$ cd test-ds/
+$ git annex addurl --relaxed "https://git-annex.branchable.com/"
+addurl https://git-annex.branchable.com/ (to git-annex.branchable.com_) ok
+(recording state in git...)
+$ git annex whereis git-annex.branchable.com_ 
+whereis git-annex.branchable.com_ (1 copy) 
+  	00000000-0000-0000-0000-000000000001 -- web
+
+  web: https://git-annex.branchable.com/
+ok
+$ ls -l
+[...] git-annex.branchable.com_ -> '.git/annex/objects/pJ/v4/URL--https&c%%git-annex.branchable.com%/URL--https&c%%git-annex.branchable.com%'
+$ git annex get git-annex.branchable.com_ 
+get git-annex.branchable.com_ (from web...) 
+ok
+(recording state in git...)
+$ git annex migrate
+migrate git-annex.branchable.com_ (checksum...) ok
+(recording state in git...)
+$ ls -l
+[...] git-annex.branchable.com_ -> .git/annex/objects/31/qv/MD5E-s12462--6b956d66f8352205df79936ada326ec3/MD5E-s12462--6b956d66f8352205df79936ada326ec3
+$ git annex whereis git-annex.branchable.com_ 
+whereis git-annex.branchable.com_ (2 copies) 
+  	00000000-0000-0000-0000-000000000001 -- web
+   	60079e0e-42e4-492e-a7b1-dde764d069eb -- [here]
+
+  web: https://git-annex.branchable.com/
+ok
+# End of transcript or log.
+"""]]
+
+It doesn't work with the custom special remote:
+[[!format sh """
+$ datalad create test-ds
+create(ok): [...] (dataset)
+$ cd test-ds/
+$ datalad download-cds --lazy --nosave --path "2022-01-01.grib" "$(cat <<EOF
+{
+    "dataset": "reanalysis-era5-complete",
+    "sub-selection": {
+        "class": "ea",
+        "date": "2022-01-01",
+        "expver": "1",
+        "levelist": "1",
+        "levtype": "ml",
+        "param": "130",
+        "stream": "oper",
+        "time": "00:00:00/06:00:00/12:00:00/18:00:00",
+        "type": "an",                                 
+        "grid": ".3/.3"
+    }
+}
+EOF
+)"
+cds(ok): [...] (dataset)
+$ ls -l
+[...] 2022-01-01.grib -> '.git/annex/objects/Mx/4G/URL--cds&cv1-eyJkYXRhc2V0IjoicmVhbmFs-162a71d794c333f5e04b13283421a49a/URL--cds&cv1-eyJkYXRhc2V0IjoicmVhbmFs-162a71d794c333f5e04b13283421a49a'
+$ git annex whereis 2022-01-01.grib 
+whereis 2022-01-01.grib (1 copy) 
+  	923e2755-e747-42f4-890a-9c921068fb82 -- [cds]
+
+  cds: {"dataset":"reanalysis-era5-complete","sub-selection":{"class":"ea","date":"2022-01-01","expver":"1","levelist":"1","levtype":"ml","param":"130","stream":"oper","time":"00:00:00/06:00:00/12:00:00/18:00:00","type":"an","grid":".3/.3"}}
+  cds: cds:v1-eyJkYXRhc2V0IjoicmVhbmFseXNpcy1lcmE1LWNvbXBsZXRlIiwic3ViLXNlbGVjdGlvbiI6eyJjbGFzcyI6ImVhIiwiZGF0ZSI6IjIwMjItMDEtMDEiLCJleHB2ZXIiOiIxIiwibGV2ZWxpc3QiOiIxIiwibGV2dHlwZSI6Im1sIiwicGFyYW0iOiIxMzAiLCJzdHJlYW0iOiJvcGVyIiwidGltZSI6IjAwOjAwOjAwLzA2OjAwOjAwLzEyOjAwOjAwLzE4OjAwOjAwIiwidHlwZSI6ImFuIiwiZ3JpZCI6Ii4zLy4zIn19
+ok
+$ git config --local remote.cds.annex-security-allow-unverified-downloads ACKTHPPT
+$ git annex get 2022-01-01.grib 
+get 2022-01-01.grib (from cds...) 
+2024-04-06 11:37:05,250 INFO Welcome to the CDS
+2024-04-06 11:37:05,251 INFO Sending request to https://cds.climate.copernicus.eu/api/v2/resources/reanalysis-era5-complete
+2024-04-06 11:37:05,340 INFO Request is queued
+2024-04-06 11:37:06,400 INFO Request is running
+2024-04-06 11:37:26,399 INFO Request is completed
+2024-04-06 11:37:26,399 INFO Downloading https://download-0017.copernicus-climate.eu/cache-compute-0017/cache/data9/adaptor.mars.external-1712396225.5545986-18258-18-822e5b91-cf60-4dbd-a808-a1253d4fe109.grib to .git/annex/tmp/URL--cds&cv1-eyJkYXRhc2V0IjoicmVhbmFs-162a71d794c333f5e04b13283421a49a (5.5M)
+  0%|          | 0.00/5.51M [00:00<?, ?B/s]  2%|▏         | 104k/5.51M [00:00<00:06, 866kB/s] 17%|█▋        | 942k/5.51M [00:00<00:00, 5.00MB/s] 57%|█████▋    | 3.15M/5.51M [00:00<00:00, 13.0MB/s] 99%|█████████▉| 5.48M/5.51M [00:00<00:00, 17.3MB/s]                                                    2024-04-06 11:37:27,322 INFO Download rate 6M/s
+ok
+(recording state in git...)
+$ git annex migrate
+migrate 2022-01-01.grib (checksum...) ok
+(recording state in git...)
+$ ls -l
+[...] 2022-01-01.grib -> .git/annex/objects/KJ/6K/MD5E-s5774880--94a848eefd02d72952c8541c52a93550.grib/MD5E-s5774880--94a848eefd02d72952c8541c52a93550.grib
+$ git annex whereis 2022-01-01.grib 
+whereis 2022-01-01.grib (1 copy) 
+  	5dfef0c9-8e18-4ea2-9ee1-646830b5749b --  [here]
+ok
+$ git annex drop 2022-01-01.grib 
+drop 2022-01-01.grib (unsafe) 
+  Could only verify the existence of 0 out of 1 necessary copy
+
+  Rather than dropping this file, try using: git annex move
+
+  (Use --force to override this check, or adjust numcopies.)
+failed
+drop: 1 failed
+"""]]
+
+I know that this is sort of abusing the URL handling in git-annex, but it was super easy to implement. You recommended me to use SETSTATE/GETSTATE from the external special remote protocol instead already at some point, but I didn't get around to reworking it for that yet.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! It is absolutely great, thank you for it.
diff --git a/doc/bugs/migrate_removes_associated_URLs_with_custom_scheme/comment_1_6e9a2b3ff2be4e2b3ff5b67ac913efb8._comment b/doc/bugs/migrate_removes_associated_URLs_with_custom_scheme/comment_1_6e9a2b3ff2be4e2b3ff5b67ac913efb8._comment
new file mode 100644
index 0000000000..5f493c6841
--- /dev/null
+++ b/doc/bugs/migrate_removes_associated_URLs_with_custom_scheme/comment_1_6e9a2b3ff2be4e2b3ff5b67ac913efb8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="m.risse@77eac2c22d673d5f10305c0bade738ad74055f92"
+ nickname="m.risse"
+ avatar="http://cdn.libravatar.org/avatar/59541f50d845e5f81aff06e88a38b9de"
+ subject="comment 1"
+ date="2024-04-06T10:05:04Z"
+ content="""
+Looking at this again I am also surprised that I didn't need to set the equivalent of `git config --local remote.cds.annex-security-allow-unverified-downloads ACKTHPPT` for the web special remote when get'ing a file with just a URL key.
+"""]]
diff --git a/doc/bugs/migrated_files_not_showing_up_in_unused_list.mdwn b/doc/bugs/migrated_files_not_showing_up_in_unused_list.mdwn
new file mode 100644
index 0000000000..33776d13af
--- /dev/null
+++ b/doc/bugs/migrated_files_not_showing_up_in_unused_list.mdwn
@@ -0,0 +1,62 @@
+Word summary: After migrating from SHA256 to SHA256E I still have a ton of SHA256 files around that aren't being found by unused.
+
+Command outputs (see, specifically, the output of status showing number of SHA256 and SHA256E files):
+
+
+    greg@eeepc:/mnt/blackbox/Media/Pictures/Photos$ less .gitattributes
+    * annex.backend=SHA256E
+
+    greg@eeepc:/mnt/blackbox/Media/Pictures/Photos$ git-annex migrate .
+    (Recording state in git...)
+
+    greg@eeepc:/mnt/blackbox/Media/Pictures/Photos$ git-annex unused
+    unused . (checking for unused data...) (checking master...) (checking rose/master...) (checking x200s/master...)
+      Some partially transferred data exists in temporary files:
+        NUMBER  KEY
+        1       SHA256E-s15766010--8132a02a8b245eb9842e89c5e696df4e9c82d676f8dec3c6bb96892c19f99d51.jpg
+
+      To remove unwanted data: git-annex dropunused NUMBER
+
+    ok
+    (Recording state in git...)
+
+    greg@eeepc:/mnt/blackbox/Media/Pictures/Photos$ git-annex status
+    supported backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+    supported remote types: git S3 bup directory rsync web hook
+    trusted repositories: 1
+            c0e4106e-2631-11e2-9749-1bfa37a61069 -- rose
+    semitrusted repositories: 3
+            00000000-0000-0000-0000-000000000001 -- web
+            9bd4077e-196c-11e2-9cc9-9faafb3e34ee -- x200s
+            c69d6fcc-18d1-11e2-9487-2fe6dbf0516b -- here (photos on eeepc)
+    untrusted repositories: 0
+    dead repositories: 1
+            3ebd5ac2-2092-11e2-856a-bb0203cce179 -- Photos on Rose
+    transfers in progress: 
+            downloading 2011/06/30/IMG_8180.jpg
+     from rose
+    available local disk space: 2 terabytes (+1 megabyte reserved)
+    temporary directory size: 9 megabytes (clean up with git-annex unused)
+    local annex keys: 36210
+    local annex size: 136 gigabytes
+    known annex keys: 23388
+    known annex size: 102 gigabytes
+    bloom filter size: 16 mebibytes (7.2% full)
+    backend usage: 
+            SHA256E: 37453
+            SHA256: 22145
+    (Recording state in git...)
+
+    greg@eeepc:/mnt/blackbox/Media/Pictures/Photos$ apt-cache policy git-annex
+    git-annex:
+      Installed: 3.20121017
+      Candidate: 3.20121017
+      Version table:
+     *** 3.20121017 0
+            600 http://ftp.us.debian.org/debian/ unstable/main i386 Packages
+            100 /var/lib/dpkg/status
+         3.20120629 0
+            650 http://ftp.us.debian.org/debian/ wheezy/main i386 Packages
+
+
+As Joey predicted, this took care of itself over time. Marking as [[bugs/done]].
diff --git a/doc/bugs/migrated_files_not_showing_up_in_unused_list/comment_1_2cfbf6693b051c758fe5efa5ee885829._comment b/doc/bugs/migrated_files_not_showing_up_in_unused_list/comment_1_2cfbf6693b051c758fe5efa5ee885829._comment
new file mode 100644
index 0000000000..ee5f056175
--- /dev/null
+++ b/doc/bugs/migrated_files_not_showing_up_in_unused_list/comment_1_2cfbf6693b051c758fe5efa5ee885829._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 1"
+ date="2012-11-07T19:02:45Z"
+ content="""
+Notice where it says:
+
+> (checking master...) (checking rose/master...) (checking x200s/master...)
+
+AFAICS, every one of those branches still refers to the migrated keys. For one thing, `git annex migrate` makes changes, but it doesn't commit them to master. And then you need to wait until the other remote are updated to.
+
+Also, there's not really any point in worrying about getting rid of migrated keys, since `git-annex migrate` hard links the new key to the old key, so the old ones don't take up any additional disk space.
+
+In other words: This should take care of itself as you continue to use the repository.
+"""]]
diff --git a/doc/bugs/migrated_files_not_showing_up_in_unused_list/comment_2_acb1abeb32c3aba8ba65151afbea753c._comment b/doc/bugs/migrated_files_not_showing_up_in_unused_list/comment_2_acb1abeb32c3aba8ba65151afbea753c._comment
new file mode 100644
index 0000000000..ccb7115887
--- /dev/null
+++ b/doc/bugs/migrated_files_not_showing_up_in_unused_list/comment_2_acb1abeb32c3aba8ba65151afbea753c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://grossmeier.net/"
+ nickname="greg"
+ subject="comment 2"
+ date="2012-11-15T04:11:55Z"
+ content="""
+You were right, this has taken care of itself.
+
+Thanks much for the solid piece of software.
+"""]]
diff --git a/doc/bugs/mimeencoding_detection_is_not_working.mdwn b/doc/bugs/mimeencoding_detection_is_not_working.mdwn
new file mode 100644
index 0000000000..e0f67d779a
--- /dev/null
+++ b/doc/bugs/mimeencoding_detection_is_not_working.mdwn
@@ -0,0 +1,43 @@
+### Please describe the problem.
+
+Mimeencoding detection doesn't work for files with Cyrillic filenaes.
+
+### What steps will reproduce the problem?
+
+I have
+
+```
+git annex config --set annex.largefiles 'mimeencoding=binary and largerthan=0'
+```
+
+So I expect all binary files to be annexed.
+
+But I have some jpg file with Cyrillic letters in filename: привет.jpg
+
+```
+$ file --mime-encoding привет.jpg
+привет.jpg: binary
+
+$ git annex add привет.jpg --verbose
+add привет.jpg (non-large file; adding content to git repository) ok
+(recording state in git...)
+
+$ mv привет.jpg hello.jpg
+
+$ git annex add hello.jpg --verbose
+add hello.jpg
+ok
+(recording state in git...)
+```
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex 10.20220223-g8f6b52b77
+
+Windows 11
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I just started using it and I love it. I like it more than git LFS
+
+[[!meta title="mimeencoding detection is not working on windows"]]
diff --git a/doc/bugs/mimeencoding_detection_is_not_working/comment_1_dbcdb6ae6fb1d06f4d5cf27cba4c69be._comment b/doc/bugs/mimeencoding_detection_is_not_working/comment_1_dbcdb6ae6fb1d06f4d5cf27cba4c69be._comment
new file mode 100644
index 0000000000..1e6e1a153d
--- /dev/null
+++ b/doc/bugs/mimeencoding_detection_is_not_working/comment_1_dbcdb6ae6fb1d06f4d5cf27cba4c69be._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-05T14:50:13Z"
+ content="""
+Is your git-annex built with support for mime type 
+detection? Post the output of `git-annex version`
+
+I don't think it's possible that a filename can affect this.
+I'd only believe that if you showed me the same content in a file without a
+cryllic filename being treated differently.
+
+Also, when I try feeding all the data into `git-annex matchexpression`,
+it behaves as expected:
+
+	joey@darkstar:~/lib/tmp> if git-annex matchexpression --file=привет.jpg --size=100 --mimeencoding=binary --largefiles 'mimeencoding=binary and largerthan=0'; then echo match; fi
+	match
+
+You could try the same command to see if your git-annex behaves differently.
+"""]]
diff --git a/doc/bugs/mimeencoding_detection_is_not_working/comment_2_b9df7eb812a4a2fba4b1273fbffe8375._comment b/doc/bugs/mimeencoding_detection_is_not_working/comment_2_b9df7eb812a4a2fba4b1273fbffe8375._comment
new file mode 100644
index 0000000000..cfaa5e9caa
--- /dev/null
+++ b/doc/bugs/mimeencoding_detection_is_not_working/comment_2_b9df7eb812a4a2fba4b1273fbffe8375._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="mnaoumov"
+ avatar="http://cdn.libravatar.org/avatar/6e35380ce54f8cdce1e5466df77f2208"
+ subject="comment 2"
+ date="2022-05-05T22:44:01Z"
+ content="""
+Thanks for your response.
+
+Your test for matchexpression doesn't show anything because you put `--mimeencoding=binary` part in it. So obviously expression will match.
+
+```
+$ git annex version
+git-annex version: 10.20220223-g8f6b52b77
+build flags: Assistant Webapp Pairing TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+I prepared a simple script to reproduce the bug
+
+```
+mkdir bug
+cd bug
+git init
+git annex init --version=10
+git annex config --set annex.largefiles 'mimeencoding=binary and largerthan=0'
+wget https://picsum.photos/id/237/200/300.jpg -O hello.jpg
+wget https://picsum.photos/id/237/200/300.jpg -O привет.jpg
+git annex add hello.jpg --verbose
+git annex add привет.jpg --verbose
+```
+
+It behaves as I described before. The file with Cyrillic letters is added as non-binary.
+
+I think it proves that something is not right with MagicMime library dealing with Cyrillic filenames
+"""]]
diff --git a/doc/bugs/mimeencoding_detection_is_not_working/comment_3_b02a321a1fd8aaeca1680cec96055172._comment b/doc/bugs/mimeencoding_detection_is_not_working/comment_3_b02a321a1fd8aaeca1680cec96055172._comment
new file mode 100644
index 0000000000..396d3ed2c9
--- /dev/null
+++ b/doc/bugs/mimeencoding_detection_is_not_working/comment_3_b02a321a1fd8aaeca1680cec96055172._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-05-09T15:21:59Z"
+ content="""
+Thanks, I think you must be right that there is some form of mojibake
+involved here, that is preventing cryllic filenames being sent through
+to libmagic, but only on Windows.
+
+[[todo/windows_support]] talks about filename encoding problems on windows,
+and this is probably one of those.
+"""]]
diff --git a/doc/bugs/moreinfo.mdwn b/doc/bugs/moreinfo.mdwn
new file mode 100644
index 0000000000..579707dab1
--- /dev/null
+++ b/doc/bugs/moreinfo.mdwn
@@ -0,0 +1,2 @@
+This tags is for bugs needing more information from their submitter.
+Please respond to the bug and provide the requested information.
diff --git a/doc/bugs/move_from_ssh_when_not_present_displays_misleading.mdwn b/doc/bugs/move_from_ssh_when_not_present_displays_misleading.mdwn
new file mode 100644
index 0000000000..a98e7e6114
--- /dev/null
+++ b/doc/bugs/move_from_ssh_when_not_present_displays_misleading.mdwn
@@ -0,0 +1,35 @@
+When a file is not present on a ssh remote, a move of that file fails
+like this:
+
+	move foo (from r...) 
+	  verification of content failed
+	  failed
+	move bar (from r...) 
+	  Lost connection (fd:24: hGetChar: illegal operation (handle is closed))
+	  failed
+
+Both files were not present, so two different failures, and neither message
+bears on the real reason why the move failed.
+
+(Despite the connection having closed, it then was able to move a third file
+that was still present.)
+
+IIRC there was a clear message displayed before git-annex-shell p2pstdio 
+got implemented. --[[Joey]]
+
+> Still a problem with 10.20220625, although the messages are
+> different and perhaps improved a bit:
+> 
+> 	move a (from b...) 
+> 
+>	  Transfer failed
+	failed
+> 	(from b...) 
+> 
+>	  Transfer failed
+> 	failed
+> 	(from b...) 
+> 
+>	  Transfer failed
+> 	failed
+> 	move: 3 failed
diff --git a/doc/bugs/move_that_fails_at_drop_stage_does_not_resume_correctly.mdwn b/doc/bugs/move_that_fails_at_drop_stage_does_not_resume_correctly.mdwn
new file mode 100644
index 0000000000..437f140be0
--- /dev/null
+++ b/doc/bugs/move_that_fails_at_drop_stage_does_not_resume_correctly.mdwn
@@ -0,0 +1,14 @@
+git-annex move takes care to handle resuming an interrupted move, where the
+dest received the object, but the drop did not happen before it was
+interrupted.
+
+But, the more common case than being interrupted with ctrl-c or power loss
+is the drop failing due to a network issue. In this case, re-running move
+does not let the drop succeed in cases where the original move would have
+let the drop succeed.
+
+The problem is that logMove runs its cleanup action in this case.
+So the move.log gets the record of the move cleaned from it. It seems that
+the cleanup action should avoid doing that when the move failed. --[[Joey]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/need_more_debug_for_failing_to_get_uuid_or_key_.mdwn b/doc/bugs/need_more_debug_for_failing_to_get_uuid_or_key_.mdwn
new file mode 100644
index 0000000000..9ba5498631
--- /dev/null
+++ b/doc/bugs/need_more_debug_for_failing_to_get_uuid_or_key_.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+
+Original case has more in [datalad github issue](https://github.com/datalad/datalad/issues/7371). 
+In a nutshell in my words: a user has a repository which is v9, under ACL (but git annex works fine as is). A user clones from another user locally. `git annex init` fails to determine (doesn't record) UUID of the `origin` remote but also does not make it `git-annex` ignore.  If we manually set `origin` uuid within .git/config of the clone, then `git annex whereis` reports presence fine. But if we do `git annex get` (see [here](https://github.com/datalad/datalad/issues/7371#issuecomment-1546158732)), it says that it is unable to access remote origin, and suggests two other remotes (not available).
+
+The sad part is that `git-annex` did not really give any reason ( in --debug) on why it didn't discover UUID or why it is unable to access it, e.g. here is output from `git annex init` in the clone when I think it should have discovered/recorded UUID
+
+```
+[2023-05-12 11:26:12.750934374] (Annex.Branch) read uuid.log
+[2023-05-12 11:26:12.753755353] (Annex.Branch) set uuid.log
+[2023-05-12 11:26:12.7539016] (Annex.Branch) read remote.log
+[2023-05-12 11:26:12.755652872] (Utility.Process) process [43725] read: git ["config","--null","--list"]
+[2023-05-12 11:26:12.763856026] (Utility.Process) process [43725] done ExitSuccess
+[2023-05-12 11:26:12.76467482] (Utility.Process) process [43726] call: /usr/local/miniconda3/share/git-annex-10.20220927-0/bin/git-annex ["upgrade","--quiet","--autoonly"]
+[2023-05-12 11:26:12.794100842] (Utility.Process) process [43726] done ExitSuccess
+[2023-05-12 11:26:12.79481645] (Utility.Process) process [43733] read: git ["config","--null","--list"]
+[2023-05-12 11:26:12.802972197] (Utility.Process) process [43733] done ExitSuccess
+[2023-05-12 11:26:12.803473974] (Annex.Branch) read trust.log
+ok
+```
+from [this comment](https://github.com/datalad/datalad/issues/7371#issuecomment-1545929998).
+
+
+So what we really need is some debug logging to tell us more.
+
+### What steps will reproduce the problem?
+
+we failed to create  a reproducer. So it is something about that user + original location.
+
+`git annex upgrade` from v9 to v10 somehow resolved it in one sample case. We have more cases like that we are not upgrading yet to reproduce again.
+
+
+### What version of git-annex are you using? On what operating system?
+
+originally in some older 8.2022  but now in 10.20230407
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> Hard to know when there is *enough* debugging, but with what I've added,
+> I can't think of any more I could add that would help with a problem of
+> this kind. Unless of course git-annex has a deep dark bug where it reads
+> an annex.uuid from git config, but then somehow misplaces it. But I can't
+> imagine such a bug so it's hard to add debugging for it. So, I suppose
+> this is [[done]] --[[Joey]]
diff --git a/doc/bugs/need_more_debug_for_failing_to_get_uuid_or_key_/comment_1_6c3efd1922015a20daf93bea54fc6431._comment b/doc/bugs/need_more_debug_for_failing_to_get_uuid_or_key_/comment_1_6c3efd1922015a20daf93bea54fc6431._comment
new file mode 100644
index 0000000000..9c4abc90eb
--- /dev/null
+++ b/doc/bugs/need_more_debug_for_failing_to_get_uuid_or_key_/comment_1_6c3efd1922015a20daf93bea54fc6431._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-05-15T17:43:21Z"
+ content="""
+Something that prevents `git config` from working, or prevents it from
+listing an annex.uuid for the remote, seems like the overridingly likely
+reason for their problem. (You were asking the right questions 
+[here](https://github.com/datalad/datalad/issues/7371#issuecomment-1545975295)
+and I don't think they really answered them, unless it happened in your office
+hours.)
+
+I've made --debug include the output of `git config --list`,
+which allows seeing if a problem prevents git from reading the config of
+the remote.
+
+I also made the debug output tell what directory it's running a command in
+when it's not the pwd.
+
+So, for example:
+
+	[2023-05-15 15:16:01.414302245] (Utility.Process) process [59665] read: git ["config","--null","--list"] in "/home/joey/tmp/a"
+	[2023-05-15 15:16:01.419396816] (Git.Config) git config read: [("",[]),("annex.uuid",["9553f51c-87ad-4321-86fb-de4aa630e997"]) [...]
+"""]]
diff --git a/doc/bugs/new_repo_with_git-lfs_as_only_annex_remote.mdwn b/doc/bugs/new_repo_with_git-lfs_as_only_annex_remote.mdwn
new file mode 100644
index 0000000000..2336128889
--- /dev/null
+++ b/doc/bugs/new_repo_with_git-lfs_as_only_annex_remote.mdwn
@@ -0,0 +1,42 @@
+### Please describe the problem.
+
+Setting up a new repo with an existing git-lfs as its only annex remote doesn't find the annex files.
+
+### What steps will reproduce the problem?
+
+This is all with encryption=none
+
+* set up repo w/ lfs-enabled origin.
+* annex a file, commit, push.
+* set up git-lfs special remote, and git annex copy --to it.
+
+Now
+
+* clone origin.
+* set up the same git-lfs special remote.
+* oops: git annex get says no available copies!
+
+### What version of git-annex are you using? On what operating system?
+
+* Debian GNU/Linux (testing)
+* git 1:2.27.0-1
+* git-annex 8.20200330-1
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I use it all the time for lots of files, git-annex is great! Hoping to migrate off my own ancient server to a gitlab one maintained by somebody else, mainly because it's backed up. But would prefer to stick with git-annex instead of having to migrate to horrible git-lfs.
+
+[[!tag moreinfo]]
+
+> [[closing|done]] as the bug reporter did not follow up with information
+> about how to reproduce it. --[[Joey]]
diff --git a/doc/bugs/new_repo_with_git-lfs_as_only_annex_remote/comment_1_804ecf5218ce147767352fea8ea5eae8._comment b/doc/bugs/new_repo_with_git-lfs_as_only_annex_remote/comment_1_804ecf5218ce147767352fea8ea5eae8._comment
new file mode 100644
index 0000000000..67f7252d1e
--- /dev/null
+++ b/doc/bugs/new_repo_with_git-lfs_as_only_annex_remote/comment_1_804ecf5218ce147767352fea8ea5eae8._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-07-10T20:05:09Z"
+ content="""
+It seems to me there are two possible mistakes you could have made, both
+of which are much more likely than a bug in git-annex. They are:
+
+1. You forgot to push the git-annex branch to origin, so your clone was not
+   able to see it.
+
+2. When you say you "set up the same git-lfs special remote" again,
+   you mean you used `git-annex initremote` again. Which sets up a
+   *different* remote with a different uuid. The right thing to do would be
+   to use `git annex enableremote`. (Or indeed to get git-annex
+   auto-enable the git-lfs special remote when it sees you cloned the same
+   url that was used to set it up)
+
+If you still think you have a bug, you'll need to show me a list of
+commands that I can use to reproduce the bug.
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows.mdwn b/doc/bugs/no_git-annex_shell_on_Windows.mdwn
new file mode 100644
index 0000000000..60a67eae9e
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+
+git annex installer on Windows only installs git-annex-licenses.txt  git-annex-uninstall.exe  git-annex.exe
+
+This makes git-annex unusable over ssh (Windows box runs cygwin sshd).
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+Windows 7 64bit
+
+git annex version
+git-annex version: 5.20140421-g78d6aa1
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows/comment_10_72b2277c3728f02e4d158ebbd7db41b2._comment b/doc/bugs/no_git-annex_shell_on_Windows/comment_10_72b2277c3728f02e4d158ebbd7db41b2._comment
new file mode 100644
index 0000000000..93a27d7544
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows/comment_10_72b2277c3728f02e4d158ebbd7db41b2._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="timotejs@7102fe834ef5514c095ceb7e09b525bafa7b1af4"
+ nickname="timotejs"
+ avatar="http://cdn.libravatar.org/avatar/3b2d892080bb891056a77a0be9ee8176"
+ subject="Did' nyone make it work?"
+ date="2018-02-06T08:15:06Z"
+ content="""
+I try to use SSH to connect to Win10 machine with annex repo.
+I am using the OpenSSH integrated into the Windows 10 (one you can install from Windows additional features thingy).
+
+it didn't know git-annex-shell so i created symlink
+
+    mklink \"C:\Program Files (x86)\Git\bin\git-annex-shell\" \"C:\Program Files (x86)\Git\bin\git-annex.exe\"
+
+and added ';.' to PATHEX
+
+Currently git-annex-shell is found but i get error:
+
+    Invalid argument `'configlist''
+
+when i try to sync remote on that W10 machine
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows/comment_11_b212c8b8cf361745f35a9f7ff6fee1f5._comment b/doc/bugs/no_git-annex_shell_on_Windows/comment_11_b212c8b8cf361745f35a9f7ff6fee1f5._comment
new file mode 100644
index 0000000000..c052520abc
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows/comment_11_b212c8b8cf361745f35a9f7ff6fee1f5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2018-02-06T17:04:51Z"
+ content="""
+If you copy git-annex.exe to git-annex-shell.exe, it should work.
+
+The installer doesn't do it, because doubling the installation size footprint
+for a feature that involves sshing into a Windows machine (not very common
+I suspect) didn't seem worth it.
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows/comment_12_9d445ddf84e15a59cdc2aa2b8dc30c44._comment b/doc/bugs/no_git-annex_shell_on_Windows/comment_12_9d445ddf84e15a59cdc2aa2b8dc30c44._comment
new file mode 100644
index 0000000000..cebd4b950d
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows/comment_12_9d445ddf84e15a59cdc2aa2b8dc30c44._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2018-02-08T17:13:41Z"
+ content="""
+That error message seems to indicate that git-annex does not realize it's
+being run with the git-annex-shell program name. When I run "git-annex -c
+configlist /path/to/repo" I get that error message; when I run
+git-annex-shell with the same parameters, I get the expected repository
+config output.
+
+I'm guessing that the windows symlink thing you tried to use confuses the
+program path name lookup that it tries to do. I'm pretty sure that a copy
+of the file would work.
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows/comment_1_988768c3e4f30c751034a0b0390cdd88._comment b/doc/bugs/no_git-annex_shell_on_Windows/comment_1_988768c3e4f30c751034a0b0390cdd88._comment
new file mode 100644
index 0000000000..fc58c35dd2
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows/comment_1_988768c3e4f30c751034a0b0390cdd88._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-05-16T18:12:34Z"
+ content="""
+You should be able to copy git-annex.exe to git-annex-shell.exe and that will be usable as git-annex-shell. I could make the windows installer do this, but without the ability to easily hard or symlink the files, it would double the disk space for what seems an unusual use case..
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows/comment_2_70a6c9af57eed4f8ceb3de63cbf8a5e6._comment b/doc/bugs/no_git-annex_shell_on_Windows/comment_2_70a6c9af57eed4f8ceb3de63cbf8a5e6._comment
new file mode 100644
index 0000000000..dd8a5ef679
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows/comment_2_70a6c9af57eed4f8ceb3de63cbf8a5e6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 2"
+ date="2014-05-16T18:58:13Z"
+ content="""
+Hmm, I don't understand the double disk space issue.
+If direct mode is used, files are stored once, right?
+
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows/comment_3_7f48959c6242c5cc52e9d0a79fd3f85d._comment b/doc/bugs/no_git-annex_shell_on_Windows/comment_3_7f48959c6242c5cc52e9d0a79fd3f85d._comment
new file mode 100644
index 0000000000..634c0d8b64
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows/comment_3_7f48959c6242c5cc52e9d0a79fd3f85d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-05-16T20:36:02Z"
+ content="""
+I mean that copying git-annex.exe to git-annex-shell.exe doubles the disk space needed to install git-annex.
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows/comment_4_04b30dd9e510762ee547e7b45bdba660._comment b/doc/bugs/no_git-annex_shell_on_Windows/comment_4_04b30dd9e510762ee547e7b45bdba660._comment
new file mode 100644
index 0000000000..4a6fd402d3
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows/comment_4_04b30dd9e510762ee547e7b45bdba660._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 4"
+ date="2014-05-24T21:26:24Z"
+ content="""
+I tried copying git-annex.exe to git-annex-shell.exe, but it doesn't behave as git-annex-shell:
+
+git-annex-shell -c configlist
+git-annex-shell.exe: unknown command configlist
+
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows/comment_5_beebbd4a41cccfc7aac3c19d76c3b978._comment b/doc/bugs/no_git-annex_shell_on_Windows/comment_5_beebbd4a41cccfc7aac3c19d76c3b978._comment
new file mode 100644
index 0000000000..9d9acf54f3
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows/comment_5_beebbd4a41cccfc7aac3c19d76c3b978._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 5"
+ date="2014-05-24T21:45:55Z"
+ content="""
+Looks like .exe prefix confuses detection logic. If I remove extension, it does behave as git-annex-shell.
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows/comment_6_957c5da5f336c7ef59e4149602471888._comment b/doc/bugs/no_git-annex_shell_on_Windows/comment_6_957c5da5f336c7ef59e4149602471888._comment
new file mode 100644
index 0000000000..c9d4c3a6a5
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows/comment_6_957c5da5f336c7ef59e4149602471888._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 6"
+ date="2014-05-24T21:49:47Z"
+ content="""
+However, it's still not usable remotely over ssh:
+
+git annex sync kpf
+
+git-annex-shell: git: createProcess: invalid argument (Invalid argument)
+
+  Remote kpf does not have git-annex installed; setting annex-ignore
+
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows/comment_7_a8654cf656de55ccdcf40270a1ef4ca9._comment b/doc/bugs/no_git-annex_shell_on_Windows/comment_7_a8654cf656de55ccdcf40270a1ef4ca9._comment
new file mode 100644
index 0000000000..1733b29dd6
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows/comment_7_a8654cf656de55ccdcf40270a1ef4ca9._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 7"
+ date="2014-05-24T22:07:15Z"
+ content="""
+OK thought I'd use it with annex-ignore set, but:
+
+    git annex copy --to=kpf file.jpg
+    copy file.jpg (checking kpf...) git-annex-shell: git: createProcess: invalid argument (Invalid argument)
+(to kpf...) 
+    git-annex-shell: git: createProcess: invalid argument (Invalid argument)
+    rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+    rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0]
+
+    rsync failed -- run git annex again to resume file transfer
+    failed
+git-annex: copy: 1 failed
+
+
+For reference, here's the .git/config section.
+
+I can either set receivepack/uploadpack like below or add /cygdrive/c/Program Files (x86)/Git/libexec/git-core to PATH in cygwin shell.
+
+Also, if I set url to kp:/cygdrive/f/backup/f, git complains that it's not a git repository (msysgit doesn't understand cygwin stuff?)
+
+    [remote \"kpf\"]
+            url = kp:f:/backup/ph
+            fetch = +refs/heads/*:refs/remotes/kpf/*
+            receivepack = git receive-pack
+            uploadpack = git upload-pack
+            annex-uuid = 99c498fc-e38e-11e3-8bb0-5368a291bd90
+            annex-ignore = true
+
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows/comment_8_3c8bb1b1d67ca1a6e568e381d24a2574._comment b/doc/bugs/no_git-annex_shell_on_Windows/comment_8_3c8bb1b1d67ca1a6e568e381d24a2574._comment
new file mode 100644
index 0000000000..ba7fadc23f
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows/comment_8_3c8bb1b1d67ca1a6e568e381d24a2574._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 8"
+ date="2014-05-24T22:58:16Z"
+ content="""
+Another data point.  If I install cygwin's git (so references like kp:/cygdrive/f would be understood) and remove annex-ignore setting, I get:
+
+    git annex sync kpf
+    commit  ok
+    pull kpf 
+    git-annex: Unknown command 'kp'
+
+Looks like hostname (kp) is taken as a command somehow.
+
+"""]]
diff --git a/doc/bugs/no_git-annex_shell_on_Windows/comment_9_03646c9df9d4f4ea27459660fe65a976._comment b/doc/bugs/no_git-annex_shell_on_Windows/comment_9_03646c9df9d4f4ea27459660fe65a976._comment
new file mode 100644
index 0000000000..7a5152b590
--- /dev/null
+++ b/doc/bugs/no_git-annex_shell_on_Windows/comment_9_03646c9df9d4f4ea27459660fe65a976._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnOSgFb3l7nL3Fs7Y9gPGJJjFiV7aJ1tek"
+ nickname="Phil"
+ subject="comment 9"
+ date="2014-07-05T22:29:01Z"
+ content="""
+Copying the `git-annex.exe` does work but you can also create a symlink and tell Windows to execute symlinks by doing the following.
+
+On the remote machine (the one you are connecting to)
+
+## Create a symlink:
+
+    mklink \"C:\Program Files (x86)\Git\bin\git-annex-shell\" \"C:\Program Files (x86)\Git\bin\git-annex.exe\"
+
+## Tell Windows to run files with no extension:
+
+* Open Environment Variables
+* At the end of `PATHEXT` add `;.`
+
+## A problem with rsync
+
+Unfortunately I now get `Access is denied` and `rsync: connection unexpectedly closed`. I think this is due to path issues on Windows. Trying rsync manually I need to use the `/cygdrive/c/rest/of/path` syntax otherwise I get `No such file or directory.`
+
+
+"""]]
diff --git a/doc/bugs/no_way_to_disable_repository_auto_upgrade.mdwn b/doc/bugs/no_way_to_disable_repository_auto_upgrade.mdwn
new file mode 100644
index 0000000000..0e2db6464b
--- /dev/null
+++ b/doc/bugs/no_way_to_disable_repository_auto_upgrade.mdwn
@@ -0,0 +1,49 @@
+### Please describe the problem.
+
+git-annex upgrades the repository before I could set the annex.autoupgraderepository to false
+
+### What steps will reproduce the problem?
+
+Its not trivial to reproduce. After an auto upgrade at one repo from v5 to v8 crashed, I decided to freeze all my v5 repositories first. By requiring the repo version and then immediately setting autoupgrade to false I realized the repo was upgraded during the command `git annex config --set autoupgraderepository false`
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 8.20200226
+ubuntu 20.04
+
+### Please provide any additional information below.
+
+[[!format sh """
+$ git annex version
+git-annex version: 8.20200226
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 5
+$ git annex config --set autoupgraderepository false
+autoupgraderepository false ok
+(recording state in git...)
+$ git annex version
+git-annex version: 8.20200226
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I am using it since v5 and only v5 for repos like more 100k filecount and size ~800GB. Worked perfectly on Linux desktop, android, phone, tab, raspberry. The greatest sync tool I ever had. I am a little bit worried about the upgrade to v8 from v5 now :) 
+
+
+> seems like this was a mistake not a bug, so [[done]] --[[Joey]]
diff --git a/doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_1_aab2cb260b68c25facd652946ea2aff7._comment b/doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_1_aab2cb260b68c25facd652946ea2aff7._comment
new file mode 100644
index 0000000000..fe7ef63172
--- /dev/null
+++ b/doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_1_aab2cb260b68c25facd652946ea2aff7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="zsolt1"
+ avatar="http://cdn.libravatar.org/avatar/ef26f34d5d953cf139c58e5dc4b5fe73"
+ subject="reproduce"
+ date="2021-02-20T19:06:44Z"
+ content="""
+disabling auto-upgrade was successful by 4 repos before I experienced this problem by the 5th one 
+"""]]
diff --git a/doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_2_dc24c6c0c60bb11d6d871fa62585276d._comment b/doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_2_dc24c6c0c60bb11d6d871fa62585276d._comment
new file mode 100644
index 0000000000..221c1c84da
--- /dev/null
+++ b/doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_2_dc24c6c0c60bb11d6d871fa62585276d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 2"
+ date="2021-02-20T21:35:05Z"
+ content="""
+You're supposed to use `git config annex.autoupgraderepository false`.
+"""]]
diff --git a/doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_3_f3c10f35956dff886d961f1351af71ef._comment b/doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_3_f3c10f35956dff886d961f1351af71ef._comment
new file mode 100644
index 0000000000..45e0ee3de5
--- /dev/null
+++ b/doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_3_f3c10f35956dff886d961f1351af71ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="zsolt1"
+ avatar="http://cdn.libravatar.org/avatar/ef26f34d5d953cf139c58e5dc4b5fe73"
+ subject="comment 3"
+ date="2021-02-21T18:11:33Z"
+ content="""
+@Lukey , thanks for pointing it out! Layer 8.
+"""]]
diff --git a/doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_4_7ea295a6c113ea0cc3e4e5ae28769190._comment b/doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_4_7ea295a6c113ea0cc3e4e5ae28769190._comment
new file mode 100644
index 0000000000..7945b1f8b4
--- /dev/null
+++ b/doc/bugs/no_way_to_disable_repository_auto_upgrade/comment_4_7ea295a6c113ea0cc3e4e5ae28769190._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-02-22T16:35:40Z"
+ content="""
+Yeah, that command you say you ran makes no sense.
+
+Now, running that command *does* upgrade the repo, if
+upgrading has not already been disabled in the git config.
+Because git-annex auto-upgrades on the first command run,
+and the fact that the command just errors out due to being
+used incorrectly doesn't prevent that from happening.
+
+But I get the feeling that command is not what you actually did?
+
+You can run `git config --global annex.autoupgraderepository false`
+and you only have to set it that one time for that machine and it will
+avoid all upgrades.
+"""]]
diff --git a/doc/bugs/non-git-annex_symlinks_not_perserved_when_exporting_tree_via_rsync.mdwn b/doc/bugs/non-git-annex_symlinks_not_perserved_when_exporting_tree_via_rsync.mdwn
new file mode 100644
index 0000000000..793b2daea1
--- /dev/null
+++ b/doc/bugs/non-git-annex_symlinks_not_perserved_when_exporting_tree_via_rsync.mdwn
@@ -0,0 +1,15 @@
+### Please describe the problem.
+
+non-git-annex symlinks are not perserved when exporting tree via rsync. instead of symlinks on the remote destination, there are files that that contain text that describe the path of the local symlink.
+
+### What steps will reproduce the problem?
+
+add an ssh-based rsync remote with exporttree=yes and run `git annex export master --to test-rsync-remote`
+
+### What version of git-annex are you using? On what operating system?
+
+6.20180529 on Trisquel 8 GNU/Linux
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, Git Annex has allowed us to transfer Gigabytes of data without a need for 7 GB of swap space and a git push command that takes hours to complete. :)
diff --git a/doc/bugs/non-git-annex_symlinks_not_perserved_when_exporting_tree_via_rsync/comment_1_b92c67f7d2f0424ce399ca4659e6c805._comment b/doc/bugs/non-git-annex_symlinks_not_perserved_when_exporting_tree_via_rsync/comment_1_b92c67f7d2f0424ce399ca4659e6c805._comment
new file mode 100644
index 0000000000..1ad0e16d5b
--- /dev/null
+++ b/doc/bugs/non-git-annex_symlinks_not_perserved_when_exporting_tree_via_rsync/comment_1_b92c67f7d2f0424ce399ca4659e6c805._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-06-12T16:46:43Z"
+ content="""
+Yes, neither are execute bits preserved. Most kinds of special remotes that
+an export could be done to don't support such things, and it seemed like it
+would unduely complicate the export interface to support them.
+"""]]
diff --git a/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status.mdwn b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status.mdwn
new file mode 100644
index 0000000000..a66d8635a0
--- /dev/null
+++ b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status.mdwn
@@ -0,0 +1,89 @@
+### Please describe the problem.
+
+when running ```git annex status``` i get 'alien' content in the list of repositories (some timestamps, something looking like git status messages, and a long list of ```(recovery from race)``` messages. the actual content seems fine and the list of repositories in the assistant looks ok, but the CLI status messages show this unusual content (full dump below).
+
+### What steps will reproduce the problem?
+
+not sure how i would go about reproducing this: i only noticed this weird output just now and i'm pretty sure it was fine 24h ago - in the meanwhile the single non-ordinary operation was deleting via the assistant's webapp an SSH remote, rsync+encryption, then creating it again as bare repo without encryption.
+
+after the assistant finished removing all the content from the previous annex directory, it stalled reporting deletion in progress (the annex directory's parent on the remote server was not writeable for the user used for the ssh connection - perhaps that was the cause). even after chowning the parent dir and restarting the assistant on my local workstation, the assistant would still show the remote as pending deletion.
+
+after a while i could add the remote again, setting it to be a git bare repo, and content was copied over.
+
+from the assistant's webapp, i still see the correct list of remotes, but the output of ```git annex status``` is as below.
+
+```.git/config``` also looks ok, listing some core settings, some annex settings and my three real remotes for this annex.
+
+the part of logs relevant to the above change (deletion of remote, creation of new one + content sync) is unfortunately gone from the annex logs (including the rotated ones in ```.git/annex/daemon.log*```).
+
+### What version of git-annex are you using? On what operating system?
+
+4.20130709:amd64 on Debian testing (linux 3.9.8-1)
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+$ git annex status
+supported backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+supported remote types: git S3 bup directory rsync web webdav glacier hook
+repository mode: direct
+trusted repositories: 7
+        1359161911.638435s -- 1
+        1359161913.173474s -- 1
+        1359161913.288686s -- 1
+        1359332402.294867s -- 1
+        1359332406.839623s -- 1
+        1359332407.454511s -- 1
+        1359332411.932021s -- 1
+semitrusted repositories: 36
+        00000000-0000-0000-0000-000000000001 -- web
+        00511808-8d7c-11e2-a252-43e07a9aaa3c -- client
+        12527a3a-a21d-4cc7-a7ea-074e8fd0260f -- annex_on_rpi00 (standard)
+        12a7b66c-e681-4dcc-bf75-b995512e5e76 -- client
+        1359159154.357141s -- 1 2ce1be52-6745-11e2-83e5-e7d111798afd
+        1359159155.817851s -- 1 2ce1be52-6745-11e2-83e5-e7d111798afd
+        1359159155.931382s -- 1 e08336a0-6742-11e2-8a53-17c5ab00507f
+        1359161255.198519s -- 1 2ce1be52-6745-11e2-83e5-e7d111798afd
+        1359161256.72633s -- 1 2ce1be52-6745-11e2-83e5-e7d111798afd
+        1359161256.952372s -- 1 e08336a0-6742-11e2-8a53-17c5ab00507f
+        1359332437.573825s -- 1 2e71af50-674c-11e2-b542-6397738d1182
+        1359332440.782882s -- 0 2e71af50-674c-11e2-b542-6397738d1182
+        1359332441.153755s -- 1 42c358c4-6741-11e2-ba3f-8bdecec02757
+        1359332448.091981s -- 0 2ce1be52-6745-11e2-83e5-e7d111798afd
+        1359332507.354892s -- 1 2e71af50-674c-11e2-b542-6397738d1182
+        1359332512.553832s -- 1 2e71af50-674c-11e2-b542-6397738d1182
+        1359332512.666779s -- 1 42c358c4-6741-11e2-ba3f-8bdecec02757
+        1359332517.773994s -- 1 42c358c4-6741-11e2-ba3f-8bdecec02757
+        1359332523.112182s -- 0 2ce1be52-6745-11e2-83e5-e7d111798afd
+        1374091795.70517s -- 1 2e71af50-674c-11e2-b542-6397738d1182
+        1374507271.515001s -- 0 8d243fde-0c4c-4a19-8bce-ac1beb48eef0
+        1374507272.066961s -- 0 8d243fde-0c4c-4a19-8bce-ac1beb48eef0
+        1a76c11b-b359-4606-be1d-cc3b17dc684e -- client
+        2ce1be52-6745-11e2-83e5-e7d111798afd -- git.services__data_annex_ (transfer)
+        2e71af50-674c-11e2-b542-6397738d1182 -- here (client)
+        42c358c4-6741-11e2-ba3f-8bdecec02757 -- x11miel.local_data_annex (em@10.10.10.100:~/data/annex)
+        4eb75def-169c-45f8-b9b0-a0aa52017bd6 -- client
+        92aa538c-8d7b-11e2-9ae1-3fd2531928c1 -- client
+        author -- nnnn nnnn <em@a.il> 1374509958 +0100
+        committer -- nnnn nnnn <em@a.il> 1374509958 +0100
+        d83e4134-8d7a-11e2-8822-7f2218f2cc42 -- client
+        e08336a0-6742-11e2-8a53-17c5ab00507f -- backup
+        f7969bd0-d5dc-11e2-b362-cbb323f72415 -- transfer
+        merging -- 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+        parent -- fcde6fd44ff2ad2aaca895bca1b32fb398d76545
+        tree -- b6d4b49d9b67b296b0a0d9a800b96f88d480f923
+untrusted repositories: 2
+        1359332417.999925s -- 0
+        1374507270.94356s -- 0
+transfers in progress: none
+available local disk space: 6 gigabytes (+1 megabyte reserved)
+local annex keys: 1984
+local annex size: 6 gigabytes
+known annex keys: 1989
+known annex size: 6 gigabytes
+bloom filter size: 16 mebibytes (0.3% full)
+backend usage:
+        SHA256E: 3973
+$ 
+"""]]
diff --git a/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_1_fcd230cbb2ac363c469b98021042c011._comment b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_1_fcd230cbb2ac363c469b98021042c011._comment
new file mode 100644
index 0000000000..c9aa34806b
--- /dev/null
+++ b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_1_fcd230cbb2ac363c469b98021042c011._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://mey.vn/"
+ ip="46.65.14.106"
+ subject="git annex status output on connected nodes"
+ date="2013-07-25T16:42:04Z"
+ content="""
+i have now updated the git-annex package to the latest 4.20130723:amd64 still on Debian testing (linux 3.9.8-1) - i see the same issue (while files keep synchronising fine across the various connected nodes).
+
+i have noticed that the same output appears when i issue ```git annex status``` on the other nodes (an Ubuntu 13.04 with kernel 3.9.7 amd64 and a Debian stable with 3.10.1-1 amd64, all with latest Debian 4.20130723:amd64 package).
+"""]]
diff --git a/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_2_23207ecabd4b41d9551d0491fa71e96b._comment b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_2_23207ecabd4b41d9551d0491fa71e96b._comment
new file mode 100644
index 0000000000..3c9d1f36f9
--- /dev/null
+++ b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_2_23207ecabd4b41d9551d0491fa71e96b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 2"
+ date="2013-07-25T20:12:06Z"
+ content="""
+Please paste the output of: `git show git-annex:uuid.log`
+
+The file seems to have a lot of garbage in it. The \"merging -- 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race)\" in particular is only ever passed to git as the commit message. It should not be possible for it to appear in a file unless data has somehow become corrupted.
+
+So, I think you should also run `git fsck`. You may also find that it helps to shut down any running git-annex, and move `.git/annex/index` away to a backup location. A corrupted index file would be kind of be the best scenario since git-annex can automatically rebuild it from the git repository..
+"""]]
diff --git a/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_3_6ea92adfe955b6a5cd2a39fea78b3bf6._comment b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_3_6ea92adfe955b6a5cd2a39fea78b3bf6._comment
new file mode 100644
index 0000000000..56ae258a7c
--- /dev/null
+++ b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_3_6ea92adfe955b6a5cd2a39fea78b3bf6._comment
@@ -0,0 +1,119 @@
+[[!comment format=mdwn
+ username="http://mey.vn/"
+ ip="46.65.14.106"
+ subject="comment 3"
+ date="2013-07-26T14:54:23Z"
+ content="""
+thanks Joey.
+
+output from ```git show git-annex:uuid.log``` is below.
+
+```git fsck``` shows me 4201 lines of ```dangling blob <sha>```.
+
+```git annex fsck``` instead checksums all the files and only reports a single error about no known copies of an individual file. i guess this can be relied upon to confirm that the actual data is fine?
+
+i have also tried shutting down any running git-annex and moving the index file away - it was rebuilt when i restarted the assistant, but i still get the same output from ```git annex status```.
+
+i should probably work around this by just copying the annex folder's contents to a new folder and create a new annex there (perhaps in indirect mode rather than direct as it is now, as this is mostly a document archive with no further changes to files except some occasional renaming) and create my remotes from scratch, but now i'm quite curious about trying to track down what happened and to understand if the annex is reliably storing and syncing content even though the status message contains alien data.
+
+
+(output from ```git show git-annex:uuid.log``` follows)
+
+    00511808-8d7c-11e2-a252-43e07a9aaa3c client timestamp=1363357452.108251s
+    12527a3a-a21d-4cc7-a7ea-074e8fd0260f pi@pi0:/mnt/annex/00/annex timestamp=1374508625.460693s
+    12527a3a-a21d-4cc7-a7ea-074e8fd0260f standard timestamp=1374508627.738835s
+    12527a3a-a21d-4cc7-a7ea-074e8fd0260f transfer timestamp=1374508627.731088s
+    12a7b66c-e681-4dcc-bf75-b995512e5e76 client timestamp=1363469702.545491s
+    1359159154.357141s 1 2ce1be52-6745-11e2-83e5-e7d111798afd
+    1359159155.817851s 1 2ce1be52-6745-11e2-83e5-e7d111798afd
+    1359159155.931382s 1 e08336a0-6742-11e2-8a53-17c5ab00507f
+    1359161255.198519s 1 2ce1be52-6745-11e2-83e5-e7d111798afd
+    1359161256.72633s 1 2ce1be52-6745-11e2-83e5-e7d111798afd
+    1359161256.952372s 1 e08336a0-6742-11e2-8a53-17c5ab00507f
+    1359161911.638435s 1
+    1359161913.173474s 1
+    1359161913.288686s 1
+    1359332402.294867s 1
+    1359332406.839623s 1
+    1359332407.454511s 1
+    1359332411.932021s 1
+    1359332417.999925s 0
+    1359332437.573825s 1 2e71af50-674c-11e2-b542-6397738d1182
+    1359332440.782882s 0 2e71af50-674c-11e2-b542-6397738d1182
+    1359332441.153755s 1 42c358c4-6741-11e2-ba3f-8bdecec02757
+    1359332448.091981s 0 2ce1be52-6745-11e2-83e5-e7d111798afd
+    1359332507.354892s 1 2e71af50-674c-11e2-b542-6397738d1182
+    1359332512.553832s 1 2e71af50-674c-11e2-b542-6397738d1182
+    1359332512.666779s 1 42c358c4-6741-11e2-ba3f-8bdecec02757
+    1359332517.773994s 1 42c358c4-6741-11e2-ba3f-8bdecec02757
+    1359332523.112182s 0 2ce1be52-6745-11e2-83e5-e7d111798afd
+    1374091795.70517s 1 2e71af50-674c-11e2-b542-6397738d1182
+    1374507270.94356s 0
+    1374507271.515001s 0 8d243fde-0c4c-4a19-8bce-ac1beb48eef0
+    1374507272.066961s 0 8d243fde-0c4c-4a19-8bce-ac1beb48eef0
+    1a76c11b-b359-4606-be1d-cc3b17dc684e client timestamp=1370536281.421365s
+    2ce1be52-6745-11e2-83e5-e7d111798afd  timestamp=1359155758.081281s
+    2ce1be52-6745-11e2-83e5-e7d111798afd transfer timestamp=1359155760.243544s
+    2e71af50-674c-11e2-b542-6397738d1182 em@x12yad:~/data/annex timestamp=1359158766.916677s
+    2e71af50-674c-11e2-b542-6397738d1182 client timestamp=1359158766.994574s
+    42c358c4-6741-11e2-ba3f-8bdecec02757 em@10.10.10.100:~/data/annex timestamp=1359314998.998417s
+    42c358c4-6741-11e2-ba3f-8bdecec02757 em@x11miel:~/data/annex timestamp=1359154076.554768s
+    42c358c4-6741-11e2-ba3f-8bdecec02757 client timestamp=1359154076.649004s
+    4eb75def-169c-45f8-b9b0-a0aa52017bd6 client timestamp=1363467301.827658s
+    8d243fde-0c4c-4a19-8bce-ac1beb48eef0 X timestamp=1374508357.215776s
+    8d243fde-0c4c-4a19-8bce-ac1beb48eef0 backup on rPi Zero timestamp=1374398146.433271s
+    8d243fde-0c4c-4a19-8bce-ac1beb48eef0 standard timestamp=1374508303.429835s
+    8d243fde-0c4c-4a19-8bce-ac1beb48eef0 unwanted timestamp=1374506712.447376s
+    8d243fde-0c4c-4a19-8bce-ac1beb48eef0 unwanted timestamp=1374508303.426075s
+    92aa538c-8d7b-11e2-9ae1-3fd2531928c1 client timestamp=1363357265.665495s
+    author nnnn nnnn <em@a.il> 1374508641 +0100
+    author nnnn nnnn <em@a.il> 1374508642 +0100
+    author nnnn nnnn <em@a.il> 1374508643 +0100
+    author nnnn nnnn <em@a.il> 1374508644 +0100
+    author nnnn nnnn <em@a.il> 1374508645 +0100
+    author nnnn nnnn <em@a.il> 1374509958 +0100
+    committer nnnn nnnn <em@a.il> 1374508641 +0100
+    committer nnnn nnnn <em@a.il> 1374508642 +0100
+    committer nnnn nnnn <em@a.il> 1374508643 +0100
+    committer nnnn nnnn <em@a.il> 1374508644 +0100
+    committer nnnn nnnn <em@a.il> 1374508645 +0100
+    committer nnnn nnnn <em@a.il> 1374509958 +0100
+    d83e4134-8d7a-11e2-8822-7f2218f2cc42 em@x11miel:~/data/photos timestamp=1363356952.82141s
+    d83e4134-8d7a-11e2-8822-7f2218f2cc42 client timestamp=1363356952.865265s
+    e08336a0-6742-11e2-8a53-17c5ab00507f backup timestamp=1359154795.94703s
+    f7969bd0-d5dc-11e2-b362-cbb323f72415  timestamp=1371315579.82712s
+    f7969bd0-d5dc-11e2-b362-cbb323f72415 transfer timestamp=1371315580.420388s
+    merging 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+    merging 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+    merging 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+    merging 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+    merging 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+    merging 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+    merging 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+    merging 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+    merging 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+    merging 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+    merging 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+    merging 10.10.10.10__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+    parent 02683b204119ba5668286ef6aa803bb52d3515d0
+    parent 07e2a9755790cefa6004496570bc8094aa757afa
+    parent 09199d3870ae53d6a602c26f4b9d59f62411236c
+    parent 0d436b9b3c3766dec276f32fdb80251c2159c154
+    parent 5aca77f1f93d2f34b521e7844b0608242a70f68f
+    parent 5e3331cc8f28603e4cb8ce890fbe221d3857717c
+    parent 92b9cacae1f40a23a2e8d5feea2b058e39806bd4
+    parent bc52e17b49503d598347bc7ddb1fa05a1ca6eba2
+    parent bfc242d6cfc27ec5fb7ec5fdb745ef8e08028fd9
+    parent d7867e1afaa32a829cb875589764e921a92bde5b
+    parent ecab3543a69ac98a1509933fa25600ac3f9c091b
+    parent fcde6fd44ff2ad2aaca895bca1b32fb398d76545
+    tree 14dc2bb1ff7682d7c2f4d14ae1e5c378b0b89d47
+    tree 59d730a282fa721332a4a2686061d6ee11024e72
+    tree 5a452c8e00eb1d1fb67ef63ed74381b8f80b2ae0
+    tree 80cc5887614c1d5dd200b2ea6a90ee6b881b966b
+    tree af2b572801e828df16c195d4dfd368a1f37db33f
+    tree b026659bb4b1bf02bf146c0b873244230c7cea06
+    tree b33eaa96e7f04c014c93b4e388d831d6ec7c3746
+    tree b6d4b49d9b67b296b0a0d9a800b96f88d480f923
+
+"""]]
diff --git a/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_4_d0e55585f1612148163039d157253258._comment b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_4_d0e55585f1612148163039d157253258._comment
new file mode 100644
index 0000000000..1e2a8fe247
--- /dev/null
+++ b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_4_d0e55585f1612148163039d157253258._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 4"
+ date="2013-07-26T16:52:26Z"
+ content="""
+The 4201 dangling blobs is a little bit strange, although it could certainly happen in some normal scenarios.
+Overall, your repository seems to be ok except for this weird data in the one file. I do not anticipate the extra garbage causing any problems at all.
+
+To track this down, we need to find the commit that added the garbage. One way, assuming you're using indirect mode, is to `git checkout git-annex; git blame uuid.log` and `git show` the commit that added the garbage. If you're using direct mode, you should first `git clone` the repository and do that in the clone.
+"""]]
diff --git a/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_6_5506dc1b08516677886da4aa97263864._comment b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_6_5506dc1b08516677886da4aa97263864._comment
new file mode 100644
index 0000000000..1aaeff404f
--- /dev/null
+++ b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_6_5506dc1b08516677886da4aa97263864._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 6"
+ date="2013-07-26T20:59:42Z"
+ content="""
+I think that the whole `git show $sha` for each commit will provide useful context.
+
+I want to understand what happened here, because there are multiple weird things going on, and it's important to root cause this sort of bug.
+
+What version of git-annex is on the rPi and how was it installed? Is there a simple operation you can do that segfaults every time?
+"""]]
diff --git a/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_7_073449cc2cb73efd2b2d3d778a5573de._comment b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_7_073449cc2cb73efd2b2d3d778a5573de._comment
new file mode 100644
index 0000000000..f7046a3496
--- /dev/null
+++ b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_7_073449cc2cb73efd2b2d3d778a5573de._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://mey.vn/"
+ ip="46.65.14.106"
+ subject="comment 7"
+ date="2013-07-26T22:31:15Z"
+ content="""
+thanks Joey. i'm sending the output of ```git show $sha``` separately as it contains some non-public data; according to apt/dpkg logs, the rPi was actually using git-annex:armhf 4.20130521 from Debian testing at the time these commits were done. i did in fact install 4.20130709 and then 4.20130723 a couple of days after the issue showed up, but only yesterday i realised that both versions were segfaulting all the time (just invoking ```git-annex``` would segfault); 4.20130521 works reliably, instead (i have just downgraded to test), so my previous question about an interrupted operation possibly causing the metadata corruption is not valid as the git-annex executable in use at the time of the issue was not segfaulting (at least not under every circumstance as the more recent versions *in my setup* - but i'll dig into this separately - probably some library issue or so).
+
+the only change i can't really trace in terms of timing is when i deleted the remote i had originally set up on my rPi (using encrypted rsync) via the assistant's web interface on my laptop, and set it up again as plain unencrypted ssh remote (bare repo). i'm pretty sure this operation was done the day the commits in the ```git blame``` for ```uuid.log``` were done, but i'm not sure about the time and don't have logs going back to that moment.
+
+i could disconnect all the remotes from my laptop and redo the setup on the rPi to see if i can reproduce the issue, but i would need some pointers on how to revert my main annex on my laptop to the state it was in before i first started using the rPi as remote: can i just ```git reset --hard <some_sha>``` while on the ```git-annex``` branch? the annex is currently in direct mode (and as been so for a few months now).
+
+otherwise, i could easily copy all the data (or a subset, to start with) to a clean folder, set up a fresh annex there and pair the rPi again - if the corruption was due to some issue on the rPi it may not depend on the exact status the annex was at when the metadata corruption happened (although my full setup includes other remotes and i see some back-and-forth of merging going on throughout the history of the annex around the time the metadata issue started, so it may be hard to reproduce the exact same context).
+"""]]
diff --git a/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_7_3516e71ba3b07427a10cbb4965712aa6._comment b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_7_3516e71ba3b07427a10cbb4965712aa6._comment
new file mode 100644
index 0000000000..d8e91fdd4b
--- /dev/null
+++ b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_7_3516e71ba3b07427a10cbb4965712aa6._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="http://mey.vn/"
+ ip="46.65.14.106"
+ subject="comment 7"
+ date="2013-07-26T18:11:25Z"
+ content="""
+thanks; the current ```uuid.log``` file carries content from 8 distinct commits :
+
+    335cb49c  2013-07-22 16:57:32 +0100
+    4ec397f7  2013-07-22 16:57:26 +0100
+    50542096  2013-07-22 17:19:21 +0100
+    621a1a03  2013-07-22 16:57:28 +0100
+    63dd4509  2013-07-22 16:57:26 +0100
+    8c2d3ff7  2013-07-22 16:57:19 +0100
+    9ba4166d  2013-07-22 18:38:29 +0100
+    e182ee60  2013-07-22 16:57:26 +0100
+
+would the whole diff for each commit be useful, or just the part related to uuid.log?
+
+all these commits were done by git-annex on my laptop; the earliest of these commits come seconds after two commits done on another node - a raspberry pi running armhf Raspbian, although i now see that ```git-annex``` and ```git-annex-shell``` on this rPi are constantly segfaulting (though i can't understand the reason from the strace output): perhaps a segfault while dealing with a git operation on the rPi started the metadata corruption somehow?
+
+btw - if this could be useful to track down a possible bug in git-annex (although only involving some metadata, not the actual data), i am happy to dig further to provide all the information needed to understand what might have happened, but if it's not something worth investigating further in the bigger scheme of things, from my point of view i'm ok with restarting a fresh annex with content moved from this annex, and pristine metadata :)
+
+"""]]
diff --git a/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_8_ea2e4704adb2f304f9c11c61eb62e919._comment b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_8_ea2e4704adb2f304f9c11c61eb62e919._comment
new file mode 100644
index 0000000000..a87e4cab2b
--- /dev/null
+++ b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_8_ea2e4704adb2f304f9c11c61eb62e919._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://mey.vn/"
+ ip="46.65.14.106"
+ subject="comment 8"
+ date="2013-07-26T22:38:51Z"
+ content="""
+forgot to mention - git-annex:armhf 4.20130521 was installed on the rPi via apt-get after having added testing as extra source besides the base stable of Raspbian; the other two versions (the segfaulting ones) were installed via ```dpkg -i``` on the packages downloaded directly from packages.d.o.
+"""]]
diff --git a/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_9_4d17fedead7977541371a3f2c192e030._comment b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_9_4d17fedead7977541371a3f2c192e030._comment
new file mode 100644
index 0000000000..f2d9f56d84
--- /dev/null
+++ b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_9_4d17fedead7977541371a3f2c192e030._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 9"
+ date="2013-07-27T17:37:11Z"
+ content="""
+Here's an excerpt of the first commit where uuid.log got garbage into it. It seems that some other log files got garbage put in them before this point, and it will be interesting to see if every time new garbage gets in it's doing a \"(recovery from race)\" commit. If so, that would point pretty strongly at that code as a culprit.
+
+(Of course, it's intriguing that the race recovery commit itself seemed to encounter a race and this repeated dozens of times. An exceptionally unlikely thing to happen if everything is behaving correctly.)
+
+<pre>
+commit 8c2d3ff75431873d99c512bcae007d68ff0b565e 
+Author: REDACTED AUTHOR
+Date:   Mon Jul 22 16:57:19 2013 +0100
+
+    merging 10.4.10.106__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
+
+diff --git a/uuid.log b/uuid.log
+index 7e7e0f9..0423e02 100644
+--- a/uuid.log
++++ b/uuid.log
+@@ -1,4 +1,6 @@
++
+ 00511808-8d7c-11e2-a252-43e07a9aaa3c client timestamp=1363357452.108251s
++12527a3a-a21d-4cc7-a7ea-074e8fd0260f pi@pi0:/mnt/annex/00/annex timestamp=1374508625.460693s
+ 12527a3a-a21d-4cc7-a7ea-074e8fd0260f transfer timestamp=1374508627.731088s
+ 12a7b66c-e681-4dcc-bf75-b995512e5e76 client timestamp=1363469702.545491s
+ 1359159154.357141s 1 2ce1be52-6745-11e2-83e5-e7d111798afd
+@@ -28,6 +30,13 @@
+ 8d243fde-0c4c-4a19-8bce-ac1beb48eef0 unwanted timestamp=1374506712.447376s
+ 8d243fde-0c4c-4a19-8bce-ac1beb48eef0 unwanted timestamp=1374508303.426075s
+ 92aa538c-8d7b-11e2-9ae1-3fd2531928c1 client timestamp=1363357265.665495s
++author REDACTED AUTHOR 1374508635 +0100
++committer REDACTED AUTHOR 1374508635 +0100
+ d83e4134-8d7a-11e2-8822-7f2218f2cc42 client timestamp=1363356952.865265s
+ e08336a0-6742-11e2-8a53-17c5ab00507f backup timestamp=1359154795.94703s
+ f7969bd0-d5dc-11e2-b362-cbb323f72415 transfer timestamp=1371315580.420388s
++merging 10.4.10.106__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
++merging 10.4.10.106__mnt_annex_00_annex/git-annex into git-annex (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race)
++parent 059104588cc3c45a762586843e8ae375473993af
++parent 21a14d1ed6ea5afa11eb07c7f16fb2dd03f5d64c
++tree c4ebf18a3d1d7862484b1378124c8cb7d2c704da
+</pre>
+
+Looks a lot like a whole git commit object was union merged into the file, doesn't it?
+"""]]
diff --git a/doc/bugs/oldkeys_not_in_Windows_release_10.20230803.mdwn b/doc/bugs/oldkeys_not_in_Windows_release_10.20230803.mdwn
new file mode 100644
index 0000000000..7292c9f6f5
--- /dev/null
+++ b/doc/bugs/oldkeys_not_in_Windows_release_10.20230803.mdwn
@@ -0,0 +1,38 @@
+### Please describe the problem.
+
+The new oldkeys command is not included in the latest Windows release.
+
+The problem does not occur on Linux or macOS.
+
+Also, the man page summary (on https://git-annex.branchable.com/git-annex/) does not include a link to the documentation page (https://git-annex.branchable.com/git-annex-oldkeys/).
+
+### What steps will reproduce the problem?
+
+git annex oldkeys
+
+### What version of git-annex are you using? On what operating system?
+
+* git-annex version: 10.20230803-gd467c70ef7
+* git version 2.41.0.windows.2
+* OS Name: Microsoft Windows 10 Pro
+* OS Version: 10.0.19045 N/A Build 19045
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+git-annex: Unknown command 'oldkeys'
+
+Did you mean one of these?
+        findkeys
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes. I am developing the easy-git-annex API.
+
+> Closing as it will be fixed by the next release. [[done]] --[[Joey]]
diff --git a/doc/bugs/oldkeys_not_in_Windows_release_10.20230803/comment_1_9969cdc389617f4df2ee286e8d28176e._comment b/doc/bugs/oldkeys_not_in_Windows_release_10.20230803/comment_1_9969cdc389617f4df2ee286e8d28176e._comment
new file mode 100644
index 0000000000..a8b6e4fbd6
--- /dev/null
+++ b/doc/bugs/oldkeys_not_in_Windows_release_10.20230803/comment_1_9969cdc389617f4df2ee286e8d28176e._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-09-11T17:15:45Z"
+ content="""
+Added the missing link.
+"""]]
diff --git a/doc/bugs/oldkeys_not_in_Windows_release_10.20230803/comment_2_b265af06b8edda75d305fd836f6c5242._comment b/doc/bugs/oldkeys_not_in_Windows_release_10.20230803/comment_2_b265af06b8edda75d305fd836f6c5242._comment
new file mode 100644
index 0000000000..b83eaf104e
--- /dev/null
+++ b/doc/bugs/oldkeys_not_in_Windows_release_10.20230803/comment_2_b265af06b8edda75d305fd836f6c5242._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-09-11T17:17:47Z"
+ content="""
+d467c70ef7 is before the oldkeys command got added, apparently the windows
+build was lagging at the time of release.
+
+If you need the command, the windows autobuild is up-to-date and includes
+it.
+
+So this will get fixed on the next release.
+"""]]
diff --git a/doc/bugs/on_encfs__44___.fuse__95__hiddenXXXXX_files_left_behind.mdwn b/doc/bugs/on_encfs__44___.fuse__95__hiddenXXXXX_files_left_behind.mdwn
new file mode 100644
index 0000000000..6c8f73f5e9
--- /dev/null
+++ b/doc/bugs/on_encfs__44___.fuse__95__hiddenXXXXX_files_left_behind.mdwn
@@ -0,0 +1,52 @@
+### Please describe the problem.
+
+When git annex is used on a encfs mount, ``.fuse_hiddenXXXX`` files are left behind in ``.git/annex/objects/*/*/`` when I ``git annex move`` files off the encfs
+
+### What steps will reproduce the problem?
+
+    mkdir normal plain enc
+    encfs -o kernel_cache "$(realpath enc)" "$(realpath plain)"
+
+    cd normal
+    git init
+    git annex init normal
+
+    cd ../plain
+    git init
+    git annex init enc
+    dd if=/dev/urandom bs=1M count=11 of=11m
+    git annex add 11m
+    git remote add normal "$(realpath ../normal)"
+    du -hscL *
+        << 11MB-ish >>
+    du -hsc .git/annex/objects
+        << 11MB-ish >>
+    git annex move --to=normal 11m
+    du -hscL *
+        << 0 >>
+    du -hsc .git/annex/objects
+        << 11MB-ish but should be 0-ish >>
+    tree -a .git/annex/objects
+        << ??/??/SHA1-*/.fuse_hidden??????? >>
+    lsof .git/annex/objects/??/??/SHA*/.fuse_hidden*
+        << shows no programs have this file open >>
+
+
+### What version of git-annex are you using? On what operating system?
+
+5.20131221 on debian unstable (installed by aptitude from debian/main)
+
+### Please provide any additional information below.
+
+I did a couple quick internet searches on these .fuse_hidden files, and (if a random person on the internet is correct) they are created by enfs (or maybe fuse itself) when a file is unlinked while open. It is supposed to be deleted when the file is closed.
+
+Possibilities come to mind:
+
+*    There's a bug in encfs/fuse
+*    git annex fails to close the file, and whatever cleanup happens when the linux kernel closes git annex fails to trigger encfs/fuse's real unlinking/cleanup thing
+
+
+
+I'm happy to help with further testing, experimenting, etc. I'm good at git, the commandline, programming, etc but I don't know Haskell.
+
+- Jason <jason@jasonwoof.com>
diff --git a/doc/bugs/on_encfs__44___.fuse__95__hiddenXXXXX_files_left_behind/comment_1_b96ea3ece44d42e79e4d903ca66065ee._comment b/doc/bugs/on_encfs__44___.fuse__95__hiddenXXXXX_files_left_behind/comment_1_b96ea3ece44d42e79e4d903ca66065ee._comment
new file mode 100644
index 0000000000..bf7aaedeee
--- /dev/null
+++ b/doc/bugs/on_encfs__44___.fuse__95__hiddenXXXXX_files_left_behind/comment_1_b96ea3ece44d42e79e4d903ca66065ee._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2013-12-31T19:35:20Z"
+ content="""
+When git-annex is deleting an object's content, it opens the object, locks it, unlinks it, and closes it. This is necessary in order to avoid various race conditions that could cause data loss (ie, another repository might be in the process of verifying that the object that is being deleted is present).
+
+I suspect that is what causes the problem with encfs. Since it is entirely a valid POSIX operation to do this, and since not doing it could cause data loss in some situations, I am very reluctant to change anything in git-annex in this area.
+
+It's unfortunate that encfs seems to cause so many problems for POSIX filesystem semantics. Luckily, there are other ways to encrypt filesystems that do not suffer from such problems.
+"""]]
diff --git a/doc/bugs/openTempFile.mdwn b/doc/bugs/openTempFile.mdwn
new file mode 100644
index 0000000000..c3f7ff1fb4
--- /dev/null
+++ b/doc/bugs/openTempFile.mdwn
@@ -0,0 +1,59 @@
+### Please describe the problem.
+On Windows, failure trying to initialize a remote repository over a Samba share.
+
+### What steps will reproduce the problem?
+
+On Windows:
+
+go to a new directory on a network share.
+
+git init
+
+git annex init, observe output:
+
+[[!format sh """
+Microsoft.PowerShell.Core\FileSystem::\\pudelvault\project\annextest❯ git annex init "pudelvault"
+init pudelvault
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+git-annex: .git\hooks\: openTempFile: does not exist (No such file or directory)
+failed
+git-annex: init: 1 failed
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+Windows 10
+
+git version 2.30.1.windows.1
+
+[[!format sh """
+git-annex version: 8.20210128-g4407ade4c
+build flags: Assistant Webapp Pairing TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 2 3 4 5 6 7
+"""]]
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Work without problem on local drive.
+
+[[!meta title="Windows: .git\\hooks: openTempFile: does not exist"]]
diff --git a/doc/bugs/openTempFile/comment_1_48b9ab6e3d4b24ec34d2a99b5a4ff619._comment b/doc/bugs/openTempFile/comment_1_48b9ab6e3d4b24ec34d2a99b5a4ff619._comment
new file mode 100644
index 0000000000..cc0ae530c2
--- /dev/null
+++ b/doc/bugs/openTempFile/comment_1_48b9ab6e3d4b24ec34d2a99b5a4ff619._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="arelius@a7e47ae13cb3452464261e3a99bfe6d2c25895fd"
+ nickname="arelius"
+ avatar="http://cdn.libravatar.org/avatar/f89b3d8d61a90fed8f52ac7ea9dd4456"
+ subject="comment 1"
+ date="2021-02-24T04:32:05Z"
+ content="""
+Sorry for the page URL, wasn't clear that I was creating a bug with that name.
+"""]]
diff --git a/doc/bugs/openTempFile/comment_2_a09c4a7d346c3b0f7025e6f3a276adb8._comment b/doc/bugs/openTempFile/comment_2_a09c4a7d346c3b0f7025e6f3a276adb8._comment
new file mode 100644
index 0000000000..5c21c147f9
--- /dev/null
+++ b/doc/bugs/openTempFile/comment_2_a09c4a7d346c3b0f7025e6f3a276adb8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-02-24T17:13:43Z"
+ content="""
+Does this only happen when the directory is on the network share, or also
+on a local disk?
+
+Does the .git/hooks directory exist? What happens if you mkdir that
+directory and then re-run git-annex init?
+
+This does not seem to happen on windows generally, and git-annex creates
+the directory if it does not exist, so failing this way is surprising.
+"""]]
diff --git a/doc/bugs/openTempFile/comment_3_9b9f35c8ed31ca62b34d216c6906304c._comment b/doc/bugs/openTempFile/comment_3_9b9f35c8ed31ca62b34d216c6906304c._comment
new file mode 100644
index 0000000000..b07bbf6675
--- /dev/null
+++ b/doc/bugs/openTempFile/comment_3_9b9f35c8ed31ca62b34d216c6906304c._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="arelius@a7e47ae13cb3452464261e3a99bfe6d2c25895fd"
+ nickname="arelius"
+ avatar="http://cdn.libravatar.org/avatar/f89b3d8d61a90fed8f52ac7ea9dd4456"
+ subject="comment 3"
+ date="2021-02-25T21:46:20Z"
+ content="""
+Yeah, this is only happening on the network share.
+
+The Network share does have a .git/hooks/ already.
+
+To add more info, I also tried to create a specialremote on the same network share:
+
+git annex initremote pudelvault type=directory directory=//pudelvault/project/annextestspecialremote/ encryption=none
+
+and when I try to sync content with it with:
+git annex sync --content
+
+I get a long list of somewhat similar errors:
+//pudelvault/project/annextestspecialremote\tmp\SHA256E-s5930--76c659680c2488528a0efbf315f52781df2fe3082e2cd87db87ebe487c3d85e5.hx\SHA256E-s5930--76c659680c2488528a0efbf315f52781df2fe3082e2cd87db87ebe487c3d85e5.hx: openBinaryFile: does not exist (No such file or directory)
+failed
+"""]]
diff --git a/doc/bugs/openTempFile/comment_4_3397f9ddb94d4acb8af778ec15487022._comment b/doc/bugs/openTempFile/comment_4_3397f9ddb94d4acb8af778ec15487022._comment
new file mode 100644
index 0000000000..b117a2ee4c
--- /dev/null
+++ b/doc/bugs/openTempFile/comment_4_3397f9ddb94d4acb8af778ec15487022._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-06-21T18:32:35Z"
+ content="""
+I suspect that this might be fixed in a current release of git-annex.
+
+[[!commit 54ad1b4cfb1c8302f1b862cb2699ab9351e3eb5b]] made git-annex
+fully support long filenames on windows. Some of the filenames in this bug
+look long, and also it involved a network share path that I think that
+commit would have likely improved git-annex's handling of.
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more.mdwn b/doc/bugs/performance_regression__63___init_takes_times_more.mdwn
new file mode 100644
index 0000000000..349fd48937
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more.mdwn
@@ -0,0 +1,57 @@
+### Please describe the problem.
+
+I was trying to see/measure effect from using `annex.supportunlocked` to overcome significant IO due to `git annex init` while working on some glorious collection of thousands of git-annex repos with thousands of files in them.  But I came to realization that it seems that the setting is of no effect (I still see "scanning for unlocked, timing is the same) and that prior version of git-annex is **considerably** faster:
+
+```
+$> builtin cd /tmp; rm -rf 6e387cd5-fa41-495a-928e-49a0c0b0a35f; git clone https://github.com/dandizarrs/6e387cd5-fa41-495a-928e-49a0c0b0a35f >&/dev/null && cd 6e387cd5-fa41-495a-928e-49a0c0b0a35f && time git annex init; git annex version | head -n 1
+0/  1/  2/  3/  4/  5/  6/
+init  (scanning for annexed files...)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+
+  https://github.com/dandizarrs/6e387cd5-fa41-495a-928e-49a0c0b0a35f/config download failed: Not Found
+ok
+(recording state in git...)
+git annex init  10.23s user 1.48s system 109% cpu 10.701 total
+git-annex version: 10.20220624-g769be12
+```
+
+and with that config `annex.supportunlocked` set before `annex init`:
+
+```
+$> builtin cd /tmp; rm -rf 6e387cd5-fa41-495a-928e-49a0c0b0a35f; git clone https://github.com/dandizarrs/6e387cd5-fa41-495a-928e-49a0c0b0a35f >&/dev/null && cd 6e387cd5-fa41-495a-928e-49a0c0b0a35f && git config annex.supportunlocked false && time git annex init; git annex version | head -n 1
+0/  1/  2/  3/  4/  5/  6/
+init  (scanning for annexed files...)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+
+  https://github.com/dandizarrs/6e387cd5-fa41-495a-928e-49a0c0b0a35f/config download failed: Not Found
+ok
+(recording state in git...)
+git annex init  9.94s user 1.22s system 109% cpu 10.219 total
+git-annex version: 10.20220624-g769be12
+```
+
+so took over 10 seconds (conda env built version) whenever if I use some 1.5 years old (neurodebian standalone) version -- only under 3 seconds:
+
+```
+$> builtin cd /tmp; rm -rf 6e387cd5-fa41-495a-928e-49a0c0b0a35f; git clone https://github.com/dandizarrs/6e387cd5-fa41-495a-928e-49a0c0b0a35f >&/dev/null && cd 6e387cd5-fa41-495a-928e-49a0c0b0a35f && time git annex init; git annex version | head -n 1
+0/  1/  2/  3/  4/  5/  6/
+init  (merging origin/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+ok
+(recording state in git...)
+git annex init  1.57s user 0.66s system 103% cpu 2.149 total
+git-annex version: 8.20210223-1~ndall+1
+```
+
+while even "scanning for unlocked files".
+
+Since difference is quite substantial I have decided to file this issue.
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_10_7aed761c4843217ea4c90491897224c1._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_10_7aed761c4843217ea4c90491897224c1._comment
new file mode 100644
index 0000000000..0412582bdc
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_10_7aed761c4843217ea4c90491897224c1._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 10"
+ date="2022-08-01T18:51:59Z"
+ content="""
+didn't have time yet to look at that :-/ as for \"where\"
+
+- don't even know myself now how to lookup for those older github actions runs on github interface;
+
+- they all are fetched to smaug within con/tinuous archive of build logs/artifacts. So for this PR:
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2022/07[master]
+$> /usr/bin/find pr-128/build-ubuntu.yaml-7* -iname *deb
+pr-128/build-ubuntu.yaml-761-ebf2f1b0-failed/git-annex-debianstandalone-packages_10.20220624+git120-gc3df38dd1_amd64/git-annex-standalone_10.20220624+git120-gc3df38dd1-1~ndall+1_amd64.deb
+
+```
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_11_847e04bbe9c59700249136b7fef4d0b7._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_11_847e04bbe9c59700249136b7fef4d0b7._comment
new file mode 100644
index 0000000000..5a3c443721
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_11_847e04bbe9c59700249136b7fef4d0b7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 11"
+ date="2022-08-01T18:55:38Z"
+ content="""
+figured out some what to lookup on github
+- go to Actions for the entire repo
+- [filter only for pull requests:](https://github.com/datalad/git-annex/actions?query=event%3Apull_request)
+- select [most recent one for that PR and architecture](https://github.com/datalad/git-annex/actions/runs/2672648689)
+- build artifacts are at the bottom of that page
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_12_603d7228668a36dc848e706cdff64035._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_12_603d7228668a36dc848e706cdff64035._comment
new file mode 100644
index 0000000000..cd013fdacb
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_12_603d7228668a36dc848e706cdff64035._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2022-11-17T17:43:27Z"
+ content="""
+With --debug, it shows when it enters and leaves commitDb.
+
+commitDb is run around 70 times in this repository. Making it queue
+more changes into each commitDb, so it runs an order of magnitude fewer,
+did speed it up by around 1 second (from 24).
+
+Summing up the time spent in commitDb according to --debug, it is around 6.5
+seconds, out of the 24 second run. That is close to the actual time sqlite is
+taking.
+
+But per my comment above, with commitDb stubbed out, the whole run takes
+only 6 seconds. (I've re-verified that to be sure.) Why is it so much faster then?
+After doing some profiling and looking at flame graphs, I think it comes 
+down to allocations:
+
+(For future reference, here is a flame graph measuring runtimes
+of unmodified git-annex:  <https://tmp.joeyh.name/git-annex-flame-1.svg>  
+Shows the majority of time in commitDb as expected, and that it's due to 
+addAssociatedFile. The resulting upsert spends about 1/4th of its time reading
+and 3/4 writing. All unsurprising.. But also a sizable amount of time is
+spent in GC, and in IDLE, whatever that is.)
+
+Without it stubbed out:
+
+        total alloc = 6,385,408,240 bytes  (excludes profiling overheads)
+
+With it stubbed out:
+
+        total alloc = 1,714,898,200 bytes  (excludes profiling overheads)
+
+Here is a flame graph measuring allocations, not runtime, of unmodified git-annex:  
+https://tmp.joeyh.name/git-annex-flame-3.svg>  
+By far the main allocation is by mkSqlBackend, which is surprising because
+that represents a database handle. Why would it need to spend tons of memory
+making database handles?
+
+Starting to think this could be a bug in persistent or persistent-sqlite. I've
+tried disabling the lowlevel persistent parts of Database.Handle in case there
+was a bug in there, and using persistent more typically, but that didn't change
+the mkSqlBackend allocations. Next step might be a simpler test case.
+
+OTOH, it may be that the way that persistent uses the SqlBackend as a dictionary
+of functions, that calls to individual functions in it confuse the profiler,
+and allocation done to build SQL statements is being misattributed?
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_13_a79fcbe80060d11582989a9fc31d4a92._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_13_a79fcbe80060d11582989a9fc31d4a92._comment
new file mode 100644
index 0000000000..36474beabe
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_13_a79fcbe80060d11582989a9fc31d4a92._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2022-11-17T20:20:16Z"
+ content="""
+An idea from looking at the flame graphs, is that if
+reconcileStaged knew it was run on an empty keys db (or was doing a full
+scan of the tree, not an incremental updte), it could avoid doing the
+upsert, and do a blind insert instead.
+
+This will need some care to be implemented safely... 
+
+I benchmarked it, and using insertUnique is no faster, but using insert is.
+This would be a 15% speed up.
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_14_8c3b13806adb731435b346a64990527b._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_14_8c3b13806adb731435b346a64990527b._comment
new file mode 100644
index 0000000000..eedca77d66
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_14_8c3b13806adb731435b346a64990527b._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2022-11-18T17:26:03Z"
+ content="""
+Implemented the two optimisations discussed above, and init in that
+repository dropped from 24 seconds to 19 seconds, a 21% speedup.
+
+I think that's as fast as reconcileStaged is likely to get without
+some deep optimisation of the persistent library.
+
+Then I realized that `git-annex init` does not really need to scan for
+associated files. That can be done later, when running a command that needs
+to access the keys database. Indeed, when git-annex is used in a clone of
+an annexed repo without explicitly running `git-annex init`, that's what
+it already did. I've implemented that, so now `git-annex init` takes 3
+seconds or so. The price will be paid later, the first time running a
+`git-annex add` or `git-annex unlock` or `git-annex get`.
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_15_145e29b42c46f15efc21c6d1ef9dd82d._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_15_145e29b42c46f15efc21c6d1ef9dd82d._comment
new file mode 100644
index 0000000000..379aafa328
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_15_145e29b42c46f15efc21c6d1ef9dd82d._comment
@@ -0,0 +1,62 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2022-11-18T19:37:46Z"
+ content="""
+I wrote a standalone test program that uses persistant-sqlite to populate a
+database with the same data. It runs in 4.12 seconds. Which is sufficiently
+close to the 6 seconds I measured before for actual sqlite runtime in
+git-annex init.
+
+So, reconcileStaged is not slow only due to persistent-sqlite overhead, but
+something else. Weird!
+
+However, I also dumped the database to a sql script. Running that script
+with sqlite3 takes only 2.39 seconds. So, persistent-sqlite does have some
+performance overhead. Opened an issue: 
+<https://github.com/yesodweb/persistent/issues/1441>
+
+The test program:
+
+	{-# LANGUAGE EmptyDataDecls             #-}
+	{-# LANGUAGE FlexibleContexts           #-}
+	{-# LANGUAGE GADTs                      #-}
+	{-# LANGUAGE GeneralizedNewtypeDeriving #-}
+	{-# LANGUAGE MultiParamTypeClasses      #-}
+	{-# LANGUAGE OverloadedStrings          #-}
+	{-# LANGUAGE QuasiQuotes                #-}
+	{-# LANGUAGE TemplateHaskell            #-}
+	{-# LANGUAGE TypeFamilies               #-}
+	{-# LANGUAGE DerivingStrategies #-}
+	{-# LANGUAGE StandaloneDeriving #-}
+	{-# LANGUAGE UndecidableInstances #-}
+	{-# LANGUAGE DataKinds #-}
+	{-# LANGUAGE FlexibleInstances #-}
+	{-# LANGUAGE BangPatterns #-}
+	import           Control.Monad.IO.Class  (liftIO)
+	import           Database.Persist
+	import           Database.Persist.Sqlite
+	import           Database.Persist.TH
+	import           Data.Text
+	import           Data.Text.IO
+	import Control.Monad
+	
+	share [mkPersist sqlSettings, mkMigrate "migrateAll"] [persistLowerCase|
+	Val
+	    foo Text
+	    bar Text
+	    FooBarIndex foo bar
+	    BarFooIndex bar foo
+	|]
+	
+	main :: IO ()
+	main = runSqlite "sqlitedb" $ do
+	    runMigration migrateAll
+	    forM_ [1..(172156/2)] $ \x -> do
+	    	f <- liftIO Data.Text.IO.getLine
+	    	b <- liftIO Data.Text.IO.getLine
+	    	_ <- insert $ Val f b
+		return ()
+
+(Feed on stdin a series of pairs of lines of key and filename.)
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_16_783ada9438a00c0a23357bea2f19d0a1._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_16_783ada9438a00c0a23357bea2f19d0a1._comment
new file mode 100644
index 0000000000..7a8c66fed3
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_16_783ada9438a00c0a23357bea2f19d0a1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2022-12-05T17:29:11Z"
+ content="""
+<https://github.com/yesodweb/persistent/issues/1441> is having some useful
+discussion. There are changes that would speed it up 2x. The best path may
+be improving sqlite to optimise `insert_`.
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_17_d13e85f691165b533d6630a93111c786._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_17_d13e85f691165b533d6630a93111c786._comment
new file mode 100644
index 0000000000..b3a3534625
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_17_d13e85f691165b533d6630a93111c786._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 17"""
+ date="2022-12-26T19:10:04Z"
+ content="""
+<https://github.com/yesodweb/persistent/issues/1441> got fixed in 
+persistent-2.14.4.1. git-annex will get that speed improvement when it's
+built with that version. I'd anticipate it improving from 19 seconds
+to around 16 seconds.
+
+(I further opened <https://github.com/yesodweb/persistent/issues/1457>
+that would speed up some other parts of git-annex if implemented.)
+
+---
+
+The only reason to leave this bug open is that reconcileStaged is still
+somehow slower than only the persistent-sqlite overhead can explain.
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_18_13ce5ec87207d553388ec23663d9abcb._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_18_13ce5ec87207d553388ec23663d9abcb._comment
new file mode 100644
index 0000000000..0ce3682574
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_18_13ce5ec87207d553388ec23663d9abcb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 18"""
+ date="2023-03-31T18:36:56Z"
+ content="""
+Implemented support for
+<https://github.com/yesodweb/persistent/issues/1457> in git-annex,
+which does speed up sqlite inserts 2x. That will affect the scan in
+question, since that inserts to the keys database. It also will speed up
+some unrelated parts of git-annex.
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_1_3f32fa3c6de412bfdab8a4e67a30012c._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_1_3f32fa3c6de412bfdab8a4e67a30012c._comment
new file mode 100644
index 0000000000..6cbf062cd8
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_1_3f32fa3c6de412bfdab8a4e67a30012c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-07-12T20:34:02Z"
+ content="""
+Notice that it says "scanning for annexed files", not "unlocked files"
+anymore.
+
+The reason it's slower is explained by [[!commit 428c91606b]].
+And that was necessary to fix the bad, longstanding bug
+[[bugs/indeterminite_preferred_content_state_for_duplicated_file]].
+It has to scan every annexed file, not only the unlocked ones,
+in order to collect the data to not have that bug.
+
+And the scan got optimised as well as possible, I think, at the time,
+see the old issue you filed @yoh, 
+<https://git-annex.branchable.com/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/>
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_1_5e0a9e36870cd21bed351ca37ffe9914._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_1_5e0a9e36870cd21bed351ca37ffe9914._comment
new file mode 100644
index 0000000000..33111f986c
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_1_5e0a9e36870cd21bed351ca37ffe9914._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2022-07-12T20:47:22Z"
+ content="""
+FTR, on the target server where I spotted that long running `annex init` process, and which is likely to be a bit \"overloaded\" ATM bottlenecking in IO, timing is quite sad
+
+```
+(dandisets) dandi@drogon:/mnt/backup/dandi/tmp$ builtin cd /mnt/backup/dandi/tmp; rm -rf 6e387cd5-fa41-495a-928e-49a0c0b0a35f; git clone https://github.com/dandizarrs/6e387cd5-fa41-495a-928e-49a0c0b0a35f >&/dev/null && cd 6e387cd5-fa41-495a-928e-49a0c0b0a35f && git config annex.supportunlocked false && time git annex init; git annex version | head -n 1
+init  (scanning for annexed files...)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+
+  https://github.com/dandizarrs/6e387cd5-fa41-495a-928e-49a0c0b0a35f/config download failed: Not Found
+ok
+(recording state in git...)
+
+real	23m53.851s
+user	0m14.184s
+sys	0m13.692s
+git-annex version: 10.20220525-gf1fdc90
+```
+so it took 23m... but since user/sys are not as bad I guess it is indeed due to IO bottlenecking...
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_3_d92bd84ab3f218eb6ad38fcc7f54c223._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_3_d92bd84ab3f218eb6ad38fcc7f54c223._comment
new file mode 100644
index 0000000000..1e3e52d3a4
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_3_d92bd84ab3f218eb6ad38fcc7f54c223._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-07-12T20:51:05Z"
+ content="""
+The last time I worked on optimising this, 
+in [[todo/speed_up_keys_db_update_with_git_streaming]],
+it looked like writing to sqlite was probably a large part of the remaining
+time. Processing 100k new files took 41 seconds, and processing 100k
+removed files took only 17 seconds. And the only difference as far as what
+git-annex is doing in those cases is adding to sqlite vs removing from
+sqlite.
+
+[This comment](https://git-annex.branchable.com/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/#comment-5d4037307a3e66304cc0e8ce137e1693)
+suggests using multi-value sqlite inserts as perhaps a way to speed it up.
+Perhaps.
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_4_a3a5c3182ecb9fdef82f4959af516d9a._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_4_a3a5c3182ecb9fdef82f4959af516d9a._comment
new file mode 100644
index 0000000000..e1576a58fd
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_4_a3a5c3182ecb9fdef82f4959af516d9a._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-07-13T16:15:10Z"
+ content="""
+I see that repo's master branch has only 86k files in it. On my laptop,
+`git-annex init --no-autoenable` takes 24 seconds, and is mostly CPU bound.
+(Autoenabling adds another 6 seconds to that.)
+
+A local `git clone` of the repo, by the way, takes 7 seconds; so git-annex
+init is 4x as slow as clone.
+
+After stubbing out sqlite writes, `git-annex init --no-autoenable` took
+6 seconds. (2 seconds of that is building up the database write queue.) 
+This is consistent with my earlier benchmarking that sqlite
+writes are most of the work here. If you would like to try to reproduce
+that on the slow machine to see how much of the overhead is sqlite writes,
+here is a quick and dirty patch:
+
+	diff --git a/Database/Queue.hs b/Database/Queue.hs
+	index f4882d2fa..2fbd522f6 100644
+	--- a/Database/Queue.hs
+	+++ b/Database/Queue.hs
+	@@ -55,7 +55,7 @@ flushDbQueue :: DbQueue -> IO ()
+	 flushDbQueue (DQ hdl qvar) = do
+	 	q@(Queue sz _ qa) <- debugLocks $ takeMVar qvar
+	 	if sz > 0
+	-		then tryNonAsync (commitDb hdl qa) >>= \case
+	+		then tryNonAsync (pure ()) >>= \case
+	 			Right () -> debugLocks $ putMVar qvar =<< emptyQueue
+	 			Left e -> do
+	 				debugLocks $ putMVar qvar q
+	@@ -105,7 +105,7 @@ queueDb (DQ hdl qvar) commitchecker a = do
+	 	let enqueue = debugLocks . putMVar qvar
+	 	ifM (commitchecker sz' lastcommittime)
+	 		( do
+	-			r <- commitDb' hdl qa'
+	+			r <- pure (Right ()) -- commitDb' hdl qa'
+	 			case r of
+	 				Left _ -> enqueue $ Queue sz' lastcommittime qa'
+	 				Right _ -> enqueue =<< emptyQueue
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_5_652424afbe5484a679c55d437cf1e7a1._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_5_652424afbe5484a679c55d437cf1e7a1._comment
new file mode 100644
index 0000000000..5a007e9278
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_5_652424afbe5484a679c55d437cf1e7a1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2022-07-13T19:27:05Z"
+ content="""
+submitted a PR with that patch [datalad/git-annex/pull/128](https://github.com/datalad/git-annex/pull/128/files) to get a build to try (I don't remember if we archive such PR builds on smaug...)
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_6_3961ac7f22f42886f0e30f62f1cb0c5d._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_6_3961ac7f22f42886f0e30f62f1cb0c5d._comment
new file mode 100644
index 0000000000..f6baf36516
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_6_3961ac7f22f42886f0e30f62f1cb0c5d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-07-13T21:24:51Z"
+ content="""
+It probably goes without saying, but that patch should never reach a
+production system's git-annex. It will break repositories that it's used in
+for anything except testing this one thing.
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_7_0894259447bde6d676c629d5bce2a6ba._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_7_0894259447bde6d676c629d5bce2a6ba._comment
new file mode 100644
index 0000000000..19c7fdf171
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_7_0894259447bde6d676c629d5bce2a6ba._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2022-07-13T22:05:46Z"
+ content="""
+sure thing.  converted PR to draft just to be sure.  But its build failed with 
+
+```
+Annex/Branch.hs:442:52: error:
+    * Variable not in scope: tforceCommit :: String -> Annex ()
+    * Perhaps you meant `forceCommit' (line 447)
+    |
+442 | commit = whenM (journalDirty gitAnnexJournalDir) . tforceCommit
+    |                                                    ^^^^^^^^^^^^
+make[3]: *** [Makefile:58: git-annex] Error 1
+```
+
+anyways
+
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_8_7ce86149c0d839f6d2b14f76bab288be._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_8_7ce86149c0d839f6d2b14f76bab288be._comment
new file mode 100644
index 0000000000..66ecae1d3e
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_8_7ce86149c0d839f6d2b14f76bab288be._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-07-14T17:54:20Z"
+ content="""
+That was fixed in [[!commit 1b680d330b902e01bbe01e3e7dc1bde2fe512c0b]]
+"""]]
diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_9_d4ba8c726e8b74d4692caf0d4afd214c._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_9_d4ba8c726e8b74d4692caf0d4afd214c._comment
new file mode 100644
index 0000000000..7b054cacda
--- /dev/null
+++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_9_d4ba8c726e8b74d4692caf0d4afd214c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-08-01T17:06:50Z"
+ content="""
+Looks like that PR build did succeed later. I don't know where the 
+resulting artifact would have ended up.
+"""]]
diff --git a/doc/bugs/poor_choice_of_name_for_adjusted_branches.mdwn b/doc/bugs/poor_choice_of_name_for_adjusted_branches.mdwn
new file mode 100644
index 0000000000..80412fad1f
--- /dev/null
+++ b/doc/bugs/poor_choice_of_name_for_adjusted_branches.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+
+The naming conventions for adjusted branches are poorly chosen (adjusted/master(unlocked) or adjusted/master(hidemissing)).  The parentheses cause problems when checking out the branch without protecting the name by way of quotation marks.  This problem is exacarbated at least on my Ubuntu Focal system by the fact that the provided bash-completion completes the branch name without those marks.
+
+### What version of git-annex are you using? On what operating system?
+8.20200226-1 on Ubuntu Focal
+
+### What steps will reproduce the problem?
+
+    git annex adjust --hide-missing 
+    git checkout master
+    #git checkout adjTABusted/master(hidemissing)
+    git checkout adjusted/master(hidemissing)
+
+Result:
+
+    $ git checkout adjusted/master(hidemissing) 
+    bash: syntax error near unexpected token `('
+    $ git checkout "adjusted/master(hidemissing)"
+    Switched to branch 'adjusted/master(hidemissing)'
+
+The problem is easy to fix, I think, by choosing a different naming convention. I'm not sure how to deal with legacy-named branches going forward, though.
+
+Thank you very much for making git-annex available, much appreciated.
+
+> I disagree that this needs fixing, so [[wontfix|done]] --[[Joey]]
diff --git a/doc/bugs/poor_choice_of_name_for_adjusted_branches/comment_1_adbbc90054eafefa7de58663868986a3._comment b/doc/bugs/poor_choice_of_name_for_adjusted_branches/comment_1_adbbc90054eafefa7de58663868986a3._comment
new file mode 100644
index 0000000000..7389cfcd5e
--- /dev/null
+++ b/doc/bugs/poor_choice_of_name_for_adjusted_branches/comment_1_adbbc90054eafefa7de58663868986a3._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-20T15:43:03Z"
+ content="""
+One of the constraints on naming these is that the name needs to not be one
+that is likely to get in the way of something the user is doing with
+other branches, eg conflicting with another branch they have for
+something unrelated to git-annex.
+
+Another constraint is that the name of the branch (either the whole thing
+or sometimes just the part after the slash) often appears in the
+user's prompt and so it would be good if it were reasonably short and also
+reasonably human readable and clear about what thing is checked out.
+
+Those constraints are what led to this name choice. I am well aware there
+are reasons people won't typically use () in branch names, which along with
+the "adjusted/", helps make a naming conflict unlikely. And it avoids needing
+to also put "git-annex" in the branch name to avoid conflicts, so keeps it
+short, and the parens imply a relationship to master rather clearly.
+
+I decided that needing to properly quote a shell parameter in the (somewhat
+uncommon) case of manually checking the branch out was a reasonable
+tradeoff.
+
+It does seem like a bug in bash completion that it doesn't tab complete
+this correctly. I notice that tab completing a similar filename does escape
+the parens,  so it may be that the bug can be fixed in the git completion
+file somehow.
+"""]]
diff --git a/doc/bugs/poor_choice_of_name_for_adjusted_branches/comment_2_dc7b2ae4971324d34f6a8d89e888f598._comment b/doc/bugs/poor_choice_of_name_for_adjusted_branches/comment_2_dc7b2ae4971324d34f6a8d89e888f598._comment
new file mode 100644
index 0000000000..dc269631b0
--- /dev/null
+++ b/doc/bugs/poor_choice_of_name_for_adjusted_branches/comment_2_dc7b2ae4971324d34f6a8d89e888f598._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~r0lf"
+ nickname="r0lf"
+ avatar="http://cdn.libravatar.org/avatar/aa82122557e706df7ba83bd1983eb79ef1ba2e51350217850176d4f9a1bb2bc0"
+ subject="try to find a better solution"
+ date="2021-04-24T11:03:28Z"
+ content="""
+Thank you for the your comment. It certainly explains your situation back when you coded this up. I'm not sure I'm convinced it is good justification to keep things the way they are going forward.
+
+1. The branch names aren't short
+2. The branch names aren't clash-free (see my other report)
+3. I switch between branches all the time, that's their purpose.
+
+For #3, I usually rely on either mark-copy'ing the characters off the terminal with the mouse or via bash-completion. Both are broken.
+
+Isn't it that people aren't using () for branch or filenames precisely because of the problems you will almost certainly run into?  I'm certain there is a better way.
+
+Personally, I see the act of hiding non-local files as a temporary measure.  Maybe creating a branch for that isn't even the right thing.  Maybe \"git stash\" or a tag is a better solution.  Or maybe just remove broken links without committing the result at all. 
+
+To expand on that idea, https://unix.stackexchange.com/a/49470 discusses how to use find and I found \"find . -maxdepth 1 -type l -exec test ! -e {} \; -delete\" to work just fine.  \"git checkout .\" then brought back those links for non-local files just fine.  How about going without any branch at all?  Obviously, in git-annex there are still some corner cases to consider.  Like making sure not to continue on master while the links to non-local files are still removed.  I haven't considered all potential pitfalls, but I feel this might be a better way to handle this need.
+"""]]
diff --git a/doc/bugs/poor_choice_of_name_for_adjusted_branches/comment_3_19ce066c0b912398300caf8520f70eb3._comment b/doc/bugs/poor_choice_of_name_for_adjusted_branches/comment_3_19ce066c0b912398300caf8520f70eb3._comment
new file mode 100644
index 0000000000..127a097bad
--- /dev/null
+++ b/doc/bugs/poor_choice_of_name_for_adjusted_branches/comment_3_19ce066c0b912398300caf8520f70eb3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="sparse checkouts to hide non-present files"
+ date="2021-04-24T22:00:14Z"
+ content="""
+Could [sparse checkouts](https://git-scm.com/docs/git-read-tree#_sparse_checkout) be used to hide non-present files, as an alternative to adjusted branches?
+"""]]
diff --git a/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames.mdwn b/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames.mdwn
new file mode 100644
index 0000000000..14f007292a
--- /dev/null
+++ b/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames.mdwn
@@ -0,0 +1,33 @@
+### Please describe the problem.
+Filenames for the *include* statement for [preferred content](http://git-annex.branchable.com/preferred_content/) can not contain spaces.
+
+### What steps will reproduce the problem?
+
+* Create an annex repo
+* Run `git annex vicfg`
+* Enter expression *include='pictures/dir with spaces'*
+* git annex complains: # ** Parse error in next line: Parse failure: near "with" Parse failure: near "spaces'"
+
+(The *'* is interpreted as part of the filepath.)
+
+### What version of git-annex are you using? On what operating system?
+
+I am using the current binaries from Debian stable amd64.
+
+<pre>
+git-annex version: 5.20140320~bpo70+1
+build flags: Assistant Webapp Pairing S3 Inotify DBus XMPP Feeds Quvi TDFA
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+remote types: git gcrypt S3 bup directory rsync web tahoe glacier hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+</pre>
+
+### Please provide any additional information below.
+
+The only workaround I found is to use a glob for the filepath which only works for the first space: *include='pictures/dir\*'*.
+
+[[!tag confirmed]]
+
+> [[fixed|done]] by documenting the `[[:space:]]` workaround. --[[Joey]]
diff --git a/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_1_ca10638d4b4b178cfd0de8736542c4dc._comment b/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_1_ca10638d4b4b178cfd0de8736542c4dc._comment
new file mode 100644
index 0000000000..a7438c559e
--- /dev/null
+++ b/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_1_ca10638d4b4b178cfd0de8736542c4dc._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 1"
+ date="2014-04-02T18:45:36Z"
+ content="""
+A better workaround is:
+
+include='pictures/dir?with?spaces'
+
+Tokenizing text with embedded quotes is a bit of a PITA, certianly doable I suppose..
+"""]]
diff --git a/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_2_986a393a512229d35e529ba242b77b1e._comment b/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_2_986a393a512229d35e529ba242b77b1e._comment
new file mode 100644
index 0000000000..7dbeb3d088
--- /dev/null
+++ b/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_2_986a393a512229d35e529ba242b77b1e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://ypid.wordpress.com/"
+ ip="213.153.84.215"
+ subject="comment 2"
+ date="2014-04-02T21:29:54Z"
+ content="""
+Thanks for your workaround ... Works for me after removing the single quote signs.
+
+With this workaround on hand one could include/match any filename. Works for me ;)
+"""]]
diff --git a/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_3_a66be1cc2c4ca7e470be1248dcbbe885._comment b/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_3_a66be1cc2c4ca7e470be1248dcbbe885._comment
new file mode 100644
index 0000000000..038e47386b
--- /dev/null
+++ b/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_3_a66be1cc2c4ca7e470be1248dcbbe885._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="aurtzy"
+ avatar="http://cdn.libravatar.org/avatar/7d44f9b718a534ada04551ee8c72e07f"
+ subject="comment 3"
+ date="2023-05-14T02:52:38Z"
+ content="""
+Encountered this issue the other day, and just wanted to mention a more explicit alternative: it looks like matchexpression file globs support POSIX character classes, so one could also use \"\\[[:blank:]]\" which matches a space or tab.
+"""]]
diff --git a/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_4_7a8f1ba849f6e6f6072c39bdbff49405._comment b/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_4_7a8f1ba849f6e6f6072c39bdbff49405._comment
new file mode 100644
index 0000000000..214c1c8603
--- /dev/null
+++ b/doc/bugs/preferred_content__58___include_statement_does_not_allow_spaces_in_filenames/comment_4_7a8f1ba849f6e6f6072c39bdbff49405._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-05-15T19:40:59Z"
+ content="""
+Thanks @aurtzy, that is a great observation! And a feature I was not
+actually aware of.
+
+So, I think that documenting this should be sufficient.
+
+(The `glob(7)` man page does document POSIX character classes as working in
+globs, so this is a fairly standard thing.)
+"""]]
diff --git a/doc/bugs/present_files__47__directories_are_dropped_after_a_sync.mdwn b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync.mdwn
new file mode 100644
index 0000000000..69c029cd99
--- /dev/null
+++ b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync.mdwn
@@ -0,0 +1,41 @@
+### Please describe the problem.
+
+This is a followup from the discussion on <https://git-annex.branchable.com/forum/Standard_groups__47__preferred_contents/> where I unfortunately did not get a complete answer.
+I don't know if it is really a bug but at least it does not work as I would expect and the documentation provides no clear discussion on that.
+
+Now to the problem:
+My annex is in "manual" mode (or equivalently "exclude="*" and present" or an expression which contains "present".
+Then I get a file using "git annex get file".
+I would expect that this file is now synced because it is "present".
+But it is not. When I change the file it is synced to the remotes. This is what it should be.
+However, when a remote changes that file, the content is NOT synced, the file is silently dropped.
+
+Similarly, when I get a complete directory tree in manual mode, I would expect that it is synced. That means, when a remote adds a file or changes a file in that directory, it is also synced to the local machine. But it is not. If it is changed, it is silently dropped (as written above). If a file is added, only the metadata is added but the content is not synced.
+
+### What steps will reproduce the problem?
+
+ - Create a file 'file' on the server, git annex add/sync etc.
+ - On the client: git annex wanted here 'exclude="*" and present'
+ - On the client: git annex get file . The file is now present on the client
+ - Change the file on the server, git annex sync
+ - git annex sync --content on the client
+ - Result: File is dropped again on client
+
+Similarly for directories:
+
+ - Create a (sub-)directory 'subdir' with files and sync everything
+ - On the client: git annex get subdir . The subdirectory is now present, all files under it downloaded.
+ - On the server create a new file in 'subdir' and git annex add; git annex sync --content
+ - git annex sync --content on the client
+ - Result: Content of the files is not synced to client
+
+### What version of git-annex are you using? On what operating system?
+
+    git-annex version: 5.20140717-g5a7d4ff
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+
+
+[[!meta title="manual mode preferred content expression does not want newer versions of present files"]]
+[[!tag confirmed]]
diff --git a/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_1_9d7591faf99ce48b1e5753c80306ae8b._comment b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_1_9d7591faf99ce48b1e5753c80306ae8b._comment
new file mode 100644
index 0000000000..bb81333545
--- /dev/null
+++ b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_1_9d7591faf99ce48b1e5753c80306ae8b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlM_DRhi_5pJrTA0HbApHR25iAgy-NBXTY"
+ nickname="Tor Arne"
+ subject="comment 1"
+ date="2014-10-01T22:25:24Z"
+ content="""
+Have you found a solution for this? This seems useful if you're only interested in a subset of files/directories on your laptop, eg, but those that are fetched (present) that you are interested you'd want to keep up to date (in sync) with other computers?
+
+Btw, the link to the previous discussion didnt work for me.
+"""]]
diff --git a/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_2_7316cba69b9dc0415fea1389238edf25._comment b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_2_7316cba69b9dc0415fea1389238edf25._comment
new file mode 100644
index 0000000000..194f7a3d9f
--- /dev/null
+++ b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_2_7316cba69b9dc0415fea1389238edf25._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.96"
+ subject="comment 2"
+ date="2014-10-21T20:20:25Z"
+ content="""
+The problem is that there's no way for preferred content expressions to specify that a file is wanted just because some old version of the file is (or was) present.
+
+It's not clear to me how that could be added to the preferred content expressions in an efficient way.
+
+It might be possible to hack `git annex sync --content` and the assistant to look at incoming merges, and queue downloads of newer versions of files before merging.
+
+Also being discussed at <https://github.com/datalad/datalad/issues/6>.
+"""]]
diff --git a/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_3_0d53226a3991e3685d1311e4b19c4023._comment b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_3_0d53226a3991e3685d1311e4b19c4023._comment
new file mode 100644
index 0000000000..a048d31b5d
--- /dev/null
+++ b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_3_0d53226a3991e3685d1311e4b19c4023._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""complications"""
+ date="2015-09-22T18:34:43Z"
+ content="""
+* The "look at incoming merges, and queue downloads of newer versions of
+  present files" approach needs to do something about the case where
+  it's not able to successfully download a newer version immediately.
+  
+  If it let the merge proceed, the file would end up not being present
+  anymore, and so a later sync wouldn't know it had been present.
+  
+  Failing to get the contents of all changed files could just make the
+  sync fail before it merges, keeping the tree at the earlier version.
+  This might be desirable.
+
+  But, implementing that means changing sync to download file contents
+  before merging, rather than the current merge-first. I'm sure a lot of
+  people *won't* want that. (Ie, I certianly don't.) So, this seems to need
+  to be a new mode for syncing. 
+  
+  (Such a mode is probably generally useful, aside from this use case.)
+
+* If this was implemented, then when a file is modified, the content
+  of the new file would be present. git-annex already makes it so that,
+  when a file is moved, the content of the file is still present. But,
+  what if a file were first moved and then modified? If that happened in
+  multiple commits, they could be examined in turn (with additional
+  complication and slowdown) to conclude that the content is wanted. But if
+  that happened in a single commit, there's no way to tell that from
+  deleting the old file and adding a new file, whose content would not be
+  automatically wanted.
+
+* The bug report wants git-annex to somehow detect when the user has
+  manually gotten an entire directory tree and start getting new files in
+  that directory too, which seems pretty infeasible. How is git-annex
+  supposed to guess whether you want new files in a directory tree,
+  or just the files that are currently there? What if some files
+  are duplicated amoung 2 directory trees, and one tree ends up complete
+  while the other one doesn't? This seems like a request for mindreading
+  ponies.
+
+* There are many preferred content expressions that fully specify what
+  files are wanted, without using the "present" token. AFAICS,
+  there's no reason to do any of this work when the preferred content
+  expression doesn't include "present".
+
+TBH, I am not at all sure this is implementable anywhere near sanely.
+If I were you, I'd use preferred content to specify the files I want,
+which avoids these complexities and works great. Using metadata to tag
+files and making all tagged files be wanted in the preferred content
+expression is one nice way to go. And metadata is copied over when adding
+a new version of a file, so this tagging approach works across file
+modifications.
+"""]]
diff --git a/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_4_68bd50c6aeffc06d53eda7f38b06edee._comment b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_4_68bd50c6aeffc06d53eda7f38b06edee._comment
new file mode 100644
index 0000000000..2b35b662d0
--- /dev/null
+++ b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_4_68bd50c6aeffc06d53eda7f38b06edee._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-09-22T19:18:09Z"
+ content="""
+Broke part out into [[todo/deferred_update_mode]]
+"""]]
diff --git a/doc/bugs/problem_commit_normal_links.mdwn b/doc/bugs/problem_commit_normal_links.mdwn
new file mode 100644
index 0000000000..6dbd41fb4e
--- /dev/null
+++ b/doc/bugs/problem_commit_normal_links.mdwn
@@ -0,0 +1,59 @@
+Dear All,
+
+thank you for this wonderful tool!
+
+I am having an issue when I try to commit a normal link
+
+diokletian*194-> mkdir test
+
+diokletian*195-> cd test
+
+diokletian*196-> git init
+
+Initialized empty Git repository in /home/henrus/test/.git/
+
+diokletian*197-> git annex init new
+
+init new [master (root-commit) 49f5f91] git-annex setup
+
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+ create mode 100644 .gitattributes
+
+[master 76496ff] git annex init
+
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+ create mode 100644 .git-annex/uuid.log
+
+ok
+
+diokletian*198-> mkdir subdir
+
+diokletian*199-> ln -s subdir link
+
+diokletian*200-> git add link
+
+diokletian*201-> git commit -m "ok"
+
+[master f12f62d] ok
+
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+ create mode 120000 link
+
+diokletian*202-> ln -s subdir/ link2
+
+diokletian*203-> git add link2
+
+diokletian*204-> git commit -m "not ok"
+
+git-annex: Prelude.head: empty list
+
+The trailing slash seems to make a difference!
+
+Best Regards,
+
+Henrik
+
+> Thanks for the bug report. This is fixed in 0.17. --[[Joey]]  [[!tag done]]
diff --git a/doc/bugs/problem_with_upgrade_v2_-__62___v3.mdwn b/doc/bugs/problem_with_upgrade_v2_-__62___v3.mdwn
new file mode 100644
index 0000000000..7f37668ad1
--- /dev/null
+++ b/doc/bugs/problem_with_upgrade_v2_-__62___v3.mdwn
@@ -0,0 +1,3 @@
+On several of my repos, the upgrade to v3 seemed to take forever. A Crl-C followed by another "git annex upgrade" "solved" the problem in some cases. Sometimes, I had to also delete the .git/annex/journal dir to have the upgrade. I didn't notice anything special about the non-working repos to help diagnose the problem.
+
+[[!tag done]]
diff --git a/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_1_5f60006c9bb095167d817f234a14d20b._comment b/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_1_5f60006c9bb095167d817f234a14d20b._comment
new file mode 100644
index 0000000000..0cf0ad4618
--- /dev/null
+++ b/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_1_5f60006c9bb095167d817f234a14d20b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-07-04T22:58:46Z"
+ content="""
+Well if it happens again why don't you use `ps` or `strace` to see what it's doing.
+"""]]
diff --git a/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_2_cd0123392b16d89db41b45464165c247._comment b/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_2_cd0123392b16d89db41b45464165c247._comment
new file mode 100644
index 0000000000..4bef5f6454
--- /dev/null
+++ b/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_2_cd0123392b16d89db41b45464165c247._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://lithitux.org/openidserver/users/pavel"
+ nickname="pavel"
+ subject="&quot;Me too&quot;"
+ date="2011-07-05T15:54:19Z"
+ content="""
+I've also seen this apparent hang during upgrade to v3. A few more details:
+
+The annex in question has just under 18k files (and hence that many log files), which can slow down directory operations when they're all in the same place (like, for example, .git/annex/journal).
+
+git-annex uses virtually no CPU time and disk IO when it's hanging like this; the first time it happened, 'ps' showed three defunct git processes, with two \"git-annex\" processes and three \"git\" procs:
+
+ * git --git-dir=/mnt/annex/.git --work-tree=/mnt/annex cat-file --batch
+ * git --git-dir=/mnt/annex/.git --work-tree=/mnt/annex hash-object -w --stdin-paths
+ * git --git-dir=/mnt/annex/.git --work-tree=/mnt/annex update-index -z --index-info
+
+I Ctrl+C'd that and tried again, but it hung again -- this time without the defunct gits.
+
+An strace of the process and its children at the time of hang can be found at http://pastebin.com/4kNh4zEJ . It showed somewhat weird behaviour: When I attached with strace, it would scroll through a whole bunch of syscalls making up the open-fstat-read-close-write loop on .git/annex/journal files, but then would block on a write (sorry, don't have that in my scrollback any more so can't give more details) until I Ctrl+C'd strace; when attaching again, it would again scroll through the syscalls for a second or so and then hang with no output.
+
+Ultimately I detached/reattached with strace about two dozen times and that caused it (?) to finish the upgrade; not really sure how to explain it, but it seems like too much of a timing coincidence.
+
+"""]]
diff --git a/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_3_86d9e7244ae492bcbe62720b8c4fc4a9._comment b/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_3_86d9e7244ae492bcbe62720b8c4fc4a9._comment
new file mode 100644
index 0000000000..e314e73fa0
--- /dev/null
+++ b/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_3_86d9e7244ae492bcbe62720b8c4fc4a9._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-07-05T17:31:22Z"
+ content="""
+I've seen this kind of piping stall that is unblocked by strace before. It can vary with versions of GHC, so it would be good to know what version built git-annex (and on what OS version). I filed a bug report upstream before at <http://bugs.debian.org/624389>.
+
+I really need a full strace -f from the top, or at least a complete `strace -o log` of git-annex from one hang through to another hang. The strace you pastebinned does not seem complete. If I can work out which specific git command is being written to when it hangs I can lift the writing out into a separate thread or process to fix it.
+
+@pavel, you mentioned three defunct git processes, and then showed ps output for 3 git processes. Were there 6 git processes in total? And then when you ran it again you said there were no defunct gits -- where the other 3 git processes running once again?
+
+As best I can make out from the (apparently) running git processes, it seems like the journal files for the upgrade had all been written, and the hang occurred when staging them all into the index in preparation for a commit. I have committed a change that lifts the code that does that write out into a new process, which, if I am guessing right on the limited info I have, will avoid the hang.
+
+However, since I can't reproduce it, even when I put 200 thousand files in the journal and have git-annex process them, I can't be sure.
+"""]]
diff --git a/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_4_91439d4dbbf1461e281b276eb0003691._comment b/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_4_91439d4dbbf1461e281b276eb0003691._comment
new file mode 100644
index 0000000000..7bc32c259f
--- /dev/null
+++ b/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_4_91439d4dbbf1461e281b276eb0003691._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 4"
+ date="2011-07-05T18:37:21Z"
+ content="""
+I've managed to reproduce this and confirmed my fix works.
+"""]]
diff --git a/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_5_ca33a9ca0df33f7c1b58353d7ffb943d._comment b/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_5_ca33a9ca0df33f7c1b58353d7ffb943d._comment
new file mode 100644
index 0000000000..8649dc77a8
--- /dev/null
+++ b/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_5_ca33a9ca0df33f7c1b58353d7ffb943d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 5"
+ date="2011-07-05T19:06:48Z"
+ content="""
+By the way, the original bug reporter mentioned deleting .git/annex/journal. This is not recommended, and doing it during an upgrade can result in git-annex losing location tracking information. You should probably run `git annex fsck` or reset to the old git tree (and `git config annex.version 2`) and upgrade again.
+"""]]
diff --git a/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_6_f360f0006bc9115bc5a3e2eb9fe58abd._comment b/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_6_f360f0006bc9115bc5a3e2eb9fe58abd._comment
new file mode 100644
index 0000000000..0852db0795
--- /dev/null
+++ b/doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_6_f360f0006bc9115bc5a3e2eb9fe58abd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://lithitux.org/openidserver/users/pavel"
+ nickname="pavel"
+ subject="comment 6"
+ date="2011-07-06T08:14:26Z"
+ content="""
+Ah, great, thanks very much for the quick fix!
+
+Yes, when I mentioned three defunct git processes, there were three processes shown as \"git [defunct]\", plus the three git processes I listed, plus two \"git-annex\" processes. Upon cancel/resume, there were no defunct git processes when I checked, but by the time I found the bug report on the forum and commented I'd already successfully upgraded by annex (by repeatedly attaching strace) and couldn't really easily get at either additional 'ps' info or a fuller strace than what I posted (that was just the log from one of the attach/detach cycles), so it's a relief you managed to pinpoint the problem.
+"""]]
diff --git a/doc/bugs/proposal_for_timestamp_semantics.mdwn b/doc/bugs/proposal_for_timestamp_semantics.mdwn
new file mode 100644
index 0000000000..cea7dd1914
--- /dev/null
+++ b/doc/bugs/proposal_for_timestamp_semantics.mdwn
@@ -0,0 +1,13 @@
+# High level overview:
+* This only concerns mtime (and its equivalents on other systems, if applicable). atime, ctime and permissions are out of scope.
+* An object added to an annex and later retrieved from it via `mv`, `cp -L`, `git annex unannex` and such should always keep its mtime, even if retrieved on an entirely different machine and/or from a backend that doesn't support timestamps natively.
+* If an added/reinjected object is already known to the annex, use the older mtime by default, since that's probably the version that's had its metadata preserved better.
+  * If that's too much of an assumption, provide a switch to use the older/newer/known/unknown mtime, or add a git-annex-touch command.
+* symlink and object file mtimes should reflect the mtime tracked by the annex.
+* ideally, directory mtimes would also be preserved, or failing that, `git-annex-fix`, `git-annex-add` and `git-checkout` should leave them untouched.
+
+# open questions/ideas:
+* What if the user `touch`es a file/symlink, bypassing git-annex? Should the data be reconciled or ignored?
+* preserving directory mtimes looks tricky, but could it maybe be done from a hook or two?
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/proposal_for_timestamp_semantics/comment_1_a54fc1bda24e04b15490d0eaa1838d28._comment b/doc/bugs/proposal_for_timestamp_semantics/comment_1_a54fc1bda24e04b15490d0eaa1838d28._comment
new file mode 100644
index 0000000000..8fe2f552b3
--- /dev/null
+++ b/doc/bugs/proposal_for_timestamp_semantics/comment_1_a54fc1bda24e04b15490d0eaa1838d28._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-04-04T18:01:01Z"
+ content="""
+This is lacking a lot of detail about how this would be accomplished. 
+
+Assuming it's to be accomplished using git-annex metadata, it seems likely
+to signficantly slow down some git-annex operations (which would need to do
+an expensive git-annex branch lookup).
+
+There's also the complication of merging a git-annex
+branch that contains changes to the timestamp metadata. Would git-annex
+need to look over all the merged changes and go off and frob timestamps?
+
+[[todo/does_not_preserve_timestamps]] already contains discussion of this
+topic. I'm not sure that it's productive to discuss it in two different
+places. (Nor does this really seem like a bug report.)
+"""]]
diff --git a/doc/bugs/proposal_for_timestamp_semantics/comment_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment b/doc/bugs/proposal_for_timestamp_semantics/comment_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment
new file mode 100644
index 0000000000..b7edd53e40
--- /dev/null
+++ b/doc/bugs/proposal_for_timestamp_semantics/comment_2_8ba9e0c35e7761b99feb55bcdd6065cf._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="vrs+annex@ea5fa24dbb279be61a8e50adb638bf8366300717"
+ nickname="vrs+annex"
+ avatar="http://cdn.libravatar.org/avatar/74219abcec6eece8e2c9d4351c2c912c"
+ subject="comment 2"
+ date="2018-04-05T21:01:51Z"
+ content="""
+I have no opinion about what backend to use. If doing it via the metadata system significantly slows down things though and is generally awkward, why not build a separate subsystem?
+
+I don't know what you mean by \"look over all the merged changes and go off and frob timestamps\", but as long as n is on the order of [number of files changed in the commit], updating n files' timestamps sounds reasonable? There's the question of which timestamp has preference in a merge, but that sounds solvable.
+
+I made this a separate bug because it's a specific design proposal; I consider [[todo/does_not_preserve_timestamps]] a tracking bug/user story.
+
+proposal re [[/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/#comment-2ea94161228f0653917b91d4f999153f]]: File and symlink timestamps, after `git-annex-get` or `git-checkout`, are set to whatever's in the repo and then considered immutable. The user can of course change them with `touch`, but if the file is locked while that happens, that's considered a corruption like editing an object file and will be caught by `git-annex-fsck`.
+"""]]
diff --git a/doc/bugs/pull_doesn__39__t_work_on_adjusted_branches.mdwn b/doc/bugs/pull_doesn__39__t_work_on_adjusted_branches.mdwn
new file mode 100644
index 0000000000..0198cae250
--- /dev/null
+++ b/doc/bugs/pull_doesn__39__t_work_on_adjusted_branches.mdwn
@@ -0,0 +1,29 @@
+### Please describe the problem.
+
+Pull works fine if both the source and destination repositories are on unadjusted branches.
+
+If either of the repositories is on an adjusted branch, the pull operation does not copy anything.
+
+### What steps will reproduce the problem?
+
+git annex pull --allow-unrelated-histories pull-remote
+
+### What version of git-annex are you using? On what operating system?
+
+10.20231228-g5540f42e21afce6947d5410c5f18b178de6c336a
+
+on Linux
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, I am developing the easy-git-annex interface.
diff --git a/doc/bugs/pull_doesn__39__t_work_on_adjusted_branches/comment_1_2c5f51483b2f2521d98f943d8ded3acd._comment b/doc/bugs/pull_doesn__39__t_work_on_adjusted_branches/comment_1_2c5f51483b2f2521d98f943d8ded3acd._comment
new file mode 100644
index 0000000000..7c90cfe3c9
--- /dev/null
+++ b/doc/bugs/pull_doesn__39__t_work_on_adjusted_branches/comment_1_2c5f51483b2f2521d98f943d8ded3acd._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-02-05T17:26:48Z"
+ content="""
+Works for me. Also if pull didn't work, sync wouldn't work and surely
+someone would have reported such a problem?
+
+But, you left out information including what kind of adjusted branch.
+Please provide the details needed to reproduce your problem.
+
+Here it is working:
+
+	joey@darkstar:~/tmp/bench/y#master(unlocked)>git-annex pull --allow-unrelated-histories origin
+	pull origin
+	remote: Enumerating objects: 10, done.
+	remote: Counting objects: 100% (10/10), done.
+	remote: Compressing objects: 100% (7/7), done.
+	remote: Total 8 (delta 0), reused 0 (delta 0), pack-reused 0
+	Unpacking objects: 100% (8/8), 794 bytes | 397.00 KiB/s, done.
+	From /home/joey/tmp/bench/x
+	   2722cc7..f380042  git-annex  -> origin/git-annex
+	   3960dff..ae25b27  master     -> origin/master
+	(Merging into master...)
+	Updating 3960dff..ae25b27
+	Fast-forward
+	 x | 1 +
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 x
+	(Merging into adjusted branch...)
+	Updating 6c80746..7a752e3
+	Fast-forward
+	 x | 1 +
+	 1 file changed, 1 insertion(+)
+	 create mode 100644 x
+	ok
+	(merging origin/git-annex into git-annex...)
+	(recording state in git...)
+	get x (from origin...)
+	ok
+	pull origin
+	ok
+	(recording state in git...)
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/y#master(unlocked)>cat x
+	hello, world
+"""]]
diff --git a/doc/bugs/pull_doesn__39__t_work_on_adjusted_branches/comment_2_632a3616516605de477930ae09d4ca60._comment b/doc/bugs/pull_doesn__39__t_work_on_adjusted_branches/comment_2_632a3616516605de477930ae09d4ca60._comment
new file mode 100644
index 0000000000..a2c32b66c2
--- /dev/null
+++ b/doc/bugs/pull_doesn__39__t_work_on_adjusted_branches/comment_2_632a3616516605de477930ae09d4ca60._comment
@@ -0,0 +1,131 @@
+[[!comment format=mdwn
+ username="jstritch"
+ avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
+ subject="comment 2"
+ date="2024-02-06T18:27:33Z"
+ content="""
+If I commit a change, setting annex.adjustedbranchrefresh to true is not working as I *expected*. I want to pull to one specified remote only. I do not want to sync with any other repositories or special remotes that may happen to be available at the moment. This is possibly another manifestation of the issue I submitted about export not copying.
+
+The `git annex sync` command is not happy with `here` as a remote name.
+
+I see the same result if I change both `git annex adjust` from `--unlock` to `--lock`. If both adjust statements are commented out, pull-repo1 ends up with a broken link to the second file. The workflow should be the same for all cases.
+
+Here's a script reproducing what I have:
+[[!format sh \"\"\"
+mkdir pull-repo1
+mkdir pull-repo2
+
+cd pull-repo1
+git init --initial-branch main
+git annex init pull-repo1
+git config annex.adjustedbranchrefresh true
+git config receive.denyCurrentBranch updateInstead
+git annex config --set annex.largefiles include=*.xtx
+git annex group here manual
+git annex wanted here standard
+echo \"test file one\" >> test-file-one.xtx
+git annex add .
+git commit -m \"add test file one\"
+git annex adjust --unlock
+
+cd ../pull-repo2
+git clone --origin pull-repo1 ../pull-repo1 .
+git annex init pull-repo2
+cd ../pull-repo1
+git remote add pull-repo2 ../pull-repo2
+git annex push pull-repo2
+
+cd ../pull-repo2
+git config annex.adjustedbranchrefresh true
+git config receive.denyCurrentBranch updateInstead
+git annex config --set annex.largefiles include=*.xtx
+git annex group here manual
+git annex wanted here standard
+git annex adjust --unlock
+echo \"test file two\" >> test-file-two.xtx
+git annex add .
+git commit -m \"add test file two\"
+
+cd ../pull-repo1
+git annex pull --allow-unrelated-histories --content pull-repo2
+git annex list
+\"\"\"]]
+
+And here's its output:
+[[!format sh \"\"\"
+Initialized empty Git repository in /home/juanito/Documents/pull-repo1/.git/
+init pull-repo1 ok
+(recording state in git...)
+annex.largefiles include=*.xtx ok
+(recording state in git...)
+group here ok
+(recording state in git...)
+wanted here ok
+(recording state in git...)
+add test-file-one.xtx 
+ok                                
+(recording state in git...)
+[main (root-commit) 6eff4e8] add test file one
+ 1 file changed, 1 insertion(+)
+ create mode 120000 test-file-one.xtx
+adjust  
+Switched to branch 'adjusted/main(unlocked)'
+ok
+Cloning into '.'...
+done.
+init pull-repo2 (merging pull-repo1/git-annex into git-annex...)
+(recording state in git...)
+ok
+(recording state in git...)
+copy test-file-one.xtx (to pull-repo2...) 
+(recording state in git...)       
+ok
+(recording state in git...)
+push pull-repo2 
+Enumerating objects: 9, done.
+Counting objects: 100% (9/9), done.
+Delta compression using up to 12 threads
+Compressing objects: 100% (4/4), done.
+Writing objects: 100% (5/5), 426 bytes | 426.00 KiB/s, done.
+Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
+To ../pull-repo2
+ * [new branch]      main -> synced/main
+ * [new branch]      git-annex -> synced/git-annex
+ok
+annex.largefiles include=*.xtx (merging synced/git-annex into git-annex...)
+(recording state in git...)
+ok
+group here ok
+(recording state in git...)
+wanted here ok
+(recording state in git...)
+adjust  ok
+add test-file-two.xtx 
+ok                                
+(recording state in git...)
+[adjusted/main(unlocked) 57a9dab] add test file two
+ 1 file changed, 1 insertion(+)
+ create mode 100644 test-file-two.xtx
+pull pull-repo2 
+remote: Enumerating objects: 32, done.
+remote: Counting objects: 100% (29/29), done.
+remote: Compressing objects: 100% (21/21), done.
+remote: Total 23 (delta 8), reused 0 (delta 0), pack-reused 0
+Unpacking objects: 100% (23/23), 2.24 KiB | 1.12 MiB/s, done.
+From ../pull-repo2
+ * [new branch]      adjusted/main(unlocked) -> pull-repo2/adjusted/main(unlocked)
+ * [new branch]      git-annex  -> pull-repo2/git-annex
+ok
+(merging pull-repo2/git-annex into git-annex...)
+here
+|pull-repo2
+||web
+|||bittorrent
+||||
+XX__ test-file-one.xtx
+\"\"\"]]
+
+Please observe test-file-two.xtx is not listed and also not in the first repository.
+
+How should I proceed?
+"""]]
diff --git a/doc/bugs/ran_once_then_stopped_running_opensuse_13.1.mdwn b/doc/bugs/ran_once_then_stopped_running_opensuse_13.1.mdwn
new file mode 100644
index 0000000000..271b429bf7
--- /dev/null
+++ b/doc/bugs/ran_once_then_stopped_running_opensuse_13.1.mdwn
@@ -0,0 +1,13 @@
+Installed stand-alone tarball amd64.
+I was able to launch webapp. (on laptop)
+Created a repository to local home directory.
+Then ceated another repository to invite local desktop pc.(this one had all the files i wanted to sync) 
+Went to dektop and accepted invitation.  But both machines never stopped synching?  and nothing really happened.
+so I removed repository on laptop to start fresh.
+But now webapp does nothing.  I removed and re-installed a few times but still nothing.
+Only as superuser will the webapp attempt to load but fails because it is super user running.
+As far as version of git-annex...  it prompted to upgrade and i think i saw a 5 in there somewhere.
+
+and since it won't load anymore i guess there is no log.
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/ran_once_then_stopped_running_opensuse_13.1/comment_1_a9daf9e8f968b32f25e236f53ea4b845._comment b/doc/bugs/ran_once_then_stopped_running_opensuse_13.1/comment_1_a9daf9e8f968b32f25e236f53ea4b845._comment
new file mode 100644
index 0000000000..604da40227
--- /dev/null
+++ b/doc/bugs/ran_once_then_stopped_running_opensuse_13.1/comment_1_a9daf9e8f968b32f25e236f53ea4b845._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="71.80.94.56"
+ subject="comment 1"
+ date="2014-02-07T19:14:47Z"
+ content="""
+There's a bit of a dearth of information here. I think I need to know:
+
+* What the version is (output of `git annex version`)
+
+* What happens when you run `git annex webapp` (\"does nothing\" is very vague. Does it sit there forever without returning to the prompt? Print an error message? Open a web browser that's not usable somehow?)
+
+You might take a look at the file `~/.config/git-annex/autostart` and remove any repository you deleted from there, although normally git-annex will ignore entries that no longer exist.
+"""]]
diff --git a/doc/bugs/random_files_vanishing_when_assistant_gets_restarted.mdwn b/doc/bugs/random_files_vanishing_when_assistant_gets_restarted.mdwn
new file mode 100644
index 0000000000..aa34a8056a
--- /dev/null
+++ b/doc/bugs/random_files_vanishing_when_assistant_gets_restarted.mdwn
@@ -0,0 +1,34 @@
+#What steps will reproduce the problem?
+
+Running assistant in foreground on one repository that is paired to another repository, than killing it using CTRL-C and restarting it
+
+
+#What is the expected output? What do you see instead?
+
+I get messages like:
+
+    (Recording state in git...)
+    # Auf Zweig master
+    # Änderungen, die nicht zum Eintragen bereitgestellt sind:
+    #   (benutze "git add/rm <Datei>..." zum Bereitstellen)
+    #   (benutze "git checkout -- <Datei>..." um die Änderungen im Arbeitsverzeichnis zu verwerfen)
+    #
+    #       gelöscht:    "path/to/file"
+    #
+    keine Änderungen zum Eintragen hinzugefügt (benutze "git add" und/oder "git commit -a")
+    Total 0 (delta 0), reused 0 (delta 0)
+    To ssh://stormking@git-annex-volyova-stormking/data/repository/
+       4e2c631..911b80c  git-annex -> synced/git-annex
+    
+    Already up-to-date.
+
+Sorry for the german language, I'll try to reproduce it in english, later.
+After that, the symlinks for the file in the repository are gone. I can get
+them back by reverting the commit but things like that make me very nervous.
+
+
+#What version of git-annex are you using? On what operating system?
+
+3.20130102 on Arch Linux x64
+
+[[!tag /design/assistant moreinfo]]
diff --git a/doc/bugs/random_files_vanishing_when_assistant_gets_restarted/comment_1_53b4f388c47c1b3f6ffa4fc2155b30fc._comment b/doc/bugs/random_files_vanishing_when_assistant_gets_restarted/comment_1_53b4f388c47c1b3f6ffa4fc2155b30fc._comment
new file mode 100644
index 0000000000..aafd426499
--- /dev/null
+++ b/doc/bugs/random_files_vanishing_when_assistant_gets_restarted/comment_1_53b4f388c47c1b3f6ffa4fc2155b30fc._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 1"
+ date="2013-01-17T18:30:06Z"
+ content="""
+AFAICS, the German message is the equivilant of `git status` when a file has been deleted:
+
+<pre>
+# On branch master
+# Changes not staged for commit:
+#   (use \"git add/rm <file>...\" to update what will be committed)
+#   (use \"git checkout -- <file>...\" to discard changes in working directory)
+#
+#	deleted:    bigfile
+#
+no changes added to commit (use \"git add\" and/or \"git commit -a\")
+</pre>
+
+There's no indication here of when the file was deleted, or what deleted it. I need a way to reproduce this to be able to help. At this point it's not clear if the file is deleted by the old assistant that you ctrl-c'd, or if it was deleted while the assistant was not running, or if it somehow gets deleted when the new assistant is started up.
+"""]]
diff --git a/doc/bugs/random_files_vanishing_when_assistant_gets_restarted/comment_2_e66532b23b089c9ea61122d6664cddb9._comment b/doc/bugs/random_files_vanishing_when_assistant_gets_restarted/comment_2_e66532b23b089c9ea61122d6664cddb9._comment
new file mode 100644
index 0000000000..66c038f617
--- /dev/null
+++ b/doc/bugs/random_files_vanishing_when_assistant_gets_restarted/comment_2_e66532b23b089c9ea61122d6664cddb9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnjjCyhVEcTRM5m4iIBqL3ZCooPx7ZYB_E"
+ nickname="Marcus"
+ subject="comment 2"
+ date="2013-01-18T09:08:05Z"
+ content="""
+>  At this point it's not clear if the file is deleted by the old assistant that you ctrl-c'd, or if it was deleted while the assistant was not running, or if it somehow gets deleted when the new assistant is started up.
+
+So how can I help to track this down? So far I can only rule out the file being deleted by some other process.
+"""]]
diff --git a/doc/bugs/random_files_vanishing_when_assistant_gets_restarted/comment_3_c9d692c867acc076f64f1213ea03ca11._comment b/doc/bugs/random_files_vanishing_when_assistant_gets_restarted/comment_3_c9d692c867acc076f64f1213ea03ca11._comment
new file mode 100644
index 0000000000..65dcb6b006
--- /dev/null
+++ b/doc/bugs/random_files_vanishing_when_assistant_gets_restarted/comment_3_c9d692c867acc076f64f1213ea03ca11._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.194"
+ subject="comment 3"
+ date="2013-01-18T20:18:36Z"
+ content="""
+If you can reproduce the problem, you should be able to see if the file is there when you've ctrl-c the assistant.
+"""]]
diff --git a/doc/bugs/redundant_transfer_not_prevented.mdwn b/doc/bugs/redundant_transfer_not_prevented.mdwn
new file mode 100644
index 0000000000..b3335efe4b
--- /dev/null
+++ b/doc/bugs/redundant_transfer_not_prevented.mdwn
@@ -0,0 +1,56 @@
+Copying the same file from 2 repositories into another repository at the
+same time, the redundant transfer is not prevented.
+
+This was surprising to me! I would have expected it to prevent starting an
+upload when another transfer of that key is already running. The same as
+it does when starting 2 copies of the same file to the same remote.
+
+I'm easily able to reproduce this in a bench test with 2 clones of a repo.
+
+    git init a
+    cd a
+    git-annex init
+    dd if=/dev/urandom of=big bs=1M count=1000
+    git-annex add
+    git commit -m add
+    cd ..
+    git clone a b
+    git clone a c
+    cd b; git-annex get
+    cd ../c; git-annex move --from orgin
+    (cd b; git-annex copy --to origin) &
+    (cd c; git-annex copy --to origin) &
+
+Also same happens when running `git-annex get --from` two different remotes
+concurrently in the same repo.
+
+Aha... Looking at the code, this seems like a fundamental oversight.
+The `transferFile` depends on the uuid of the remote being transfered
+to/from, so there are two different ones in this case. And the transfer
+lock file that is checked derives from those files, so there are two
+seperate lock files.
+
+That is actually what we want when eg, uploading content from the same
+repo into two different repos. It would not do for an upload to one repo
+to block uploading to another repo. So a per-uuid lock file makes sense for
+uploads. But not for downloads.
+
+It seems that it does make sense to have different transfer information
+files for downloads from different uuids. Because the filename is parsed
+to determine the uuid.
+
+Perhaps the fix is just for `transferLockFile` to take a Transfer parameter,
+and return the same lock file for all Downloads of a key, no matter the
+uuid.
+
+There is the issue that renaming the lock file would break interoperability 
+with old git-annex. In this case, since this bug prevents noticing multiple
+downloads from different uuids, interoperability would only prevent
+noticing multiple downloads from the same uuid. Which is not a great
+behavior to break either, even if it would usually only break transiently.
+
+Of course that could be avoided by keeping the current lock file, and
+adding a second lock file. [[done]] this, with plans in
+[[todo/v11_changes]] to transition to use only the new lock file in
+the future.
+--[[Joey]]
diff --git a/doc/bugs/registerurl_does_not_register_if_external_remote.mdwn b/doc/bugs/registerurl_does_not_register_if_external_remote.mdwn
new file mode 100644
index 0000000000..529d21941a
--- /dev/null
+++ b/doc/bugs/registerurl_does_not_register_if_external_remote.mdwn
@@ -0,0 +1,106 @@
+### Please describe the problem.
+
+Reference: issue/discovery in [repronim/containers while adding neurodesk images](https://github.com/ReproNim/containers/issues/64#issuecomment-1492256561)
+
+- apparently we had no URLs made registered with images despite running `registerurl KEY ANNEX`
+- some images do have urls
+
+took awhile to grasp what is going on and then I found an unfinished reproducer from `Mar 15  2021 annex-claimurl.sh` without recollection why I have not finished it, but it seems that it might be "operator error" somehow? but seems unlikely... might be datalad special remote bug?
+
+Summary of the problem: if there is an external git-annex-remote which CLAIMURL - git-annex registerurl does **not** associate that URL with any (that external or web) remote and thus does not make that key available to the user despite knowing the url.
+
+Should it btw default to `web` if no remote is associated with it?
+
+Filed complimentary [registerurl --remote REMOTE](https://git-annex.branchable.com/todo/registerurl_--remote_REMOTE/) TODO since in this case I would have preferred to just register against web remote.
+
+### What steps will reproduce the problem?
+
+Here is a new "quick" reproducer but you need datalad being installed to get `git-annex-remote-datalad`.
+
+```
+#!/bin/bash
+
+export PS4='> '
+
+set -eu
+set -x
+
+cd "$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)"
+
+git init
+git annex init
+
+# It works fine if we do not enable  datalad  special remote!
+# so it is something about interaction there
+git annex initremote datalad externaltype=datalad type=external encryption=none autoenable=true uuid=65b6c36b-debd-4a23-8fa3-675cbd200496
+git annex enableremote datalad
+
+git annex info
+
+# so it seems that addurl does it right 
+git annex addurl --debug --file 123.dat http://www.oneukrainian.com/tmp/123.dat
+
+# but if I do via registerurl -- not quite so
+echo 124 > 124.dat
+git annex add 124.dat
+key=$(readlink -f 124.dat | xargs basename)
+git annex registerurl --debug "$key" http://www.oneukrainian.com/tmp/124.dat
+
+git commit -m 'added those two files with urls'
+
+git annex whereis --debug 123.dat
+git annex whereis --debug 124.dat
+
+git checkout git-annex
+: # URLs are known for both
+git grep oneukrainian
+: # but only 123.dat would be associated with datalad remote
+git grep 65b6c36b-debd-4a23-8fa3-675cbd200496
+```
+
+With [full log here](http://www.oneukrainian.com/tmp/annex-claimurl-2023.sh.log) and without `--debug` ending up like
+
+```
+❯ grep -v '^\[' annex-claimurl-2023.sh.log | tail -n 29
+(recording state in git...)
+> git commit -m 'added those two files with urls'
+ 2 files changed, 2 insertions(+)
+ create mode 120000 123.dat
+ create mode 120000 124.dat
+> git annex whereis --debug 123.dat
+whereis 123.dat [2023-03-31 18:29:27.56573965] (Utility.Process) process [1429290] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+(2 copies) 
+  	62c53770-5274-40d4-a45a-de308c234ea9 -- yoh@bilena:~/.tmp/dl-FbOrptq [here]
+   	65b6c36b-debd-4a23-8fa3-675cbd200496 -- [datalad]
+
+  datalad: http://www.oneukrainian.com/tmp/123.dat
+ok
+> git annex whereis --debug 124.dat
+whereis 124.dat [2023-03-31 18:29:27.857735575] (Utility.Process) process [1429322] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+(1 copy) 
+  	62c53770-5274-40d4-a45a-de308c234ea9 -- yoh@bilena:~/.tmp/dl-FbOrptq [here]
+ok
+> git checkout git-annex
+Switched to branch 'git-annex'
+> :
+> git grep oneukrainian
+060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log.web:1680301767.477711756s 1 :http://www.oneukrainian.com/tmp/124.dat
+ae1/21c/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat.log.web:1680301767.037966322s 1 :http://www.oneukrainian.com/tmp/123.dat
+> :
+> git grep 65b6c36b-debd-4a23-8fa3-675cbd200496
+ae1/21c/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat.log:1680301767.038748415s 1 65b6c36b-debd-4a23-8fa3-675cbd200496
+remote.log:65b6c36b-debd-4a23-8fa3-675cbd200496 autoenable=true encryption=none externaltype=datalad name=datalad type=external timestamp=1680301766.517251391s
+uuid.log:65b6c36b-debd-4a23-8fa3-675cbd200496 datalad timestamp=1680301765.789226249s
+```
+
+so - both keys have urls, but only 123.dat one is associated with datalad special remote, and only it has url reported by whereis
+
+### What version of git-annex are you using? On what operating system?
+
+10.20230126  but tried with older 8.20210803 since thought it must be regression -- the same result
+
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/registerurl_does_not_register_if_external_remote/comment_1_124bbd63a2a85004ff9cf965ad984fb4._comment b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_1_124bbd63a2a85004ff9cf965ad984fb4._comment
new file mode 100644
index 0000000000..30e101f365
--- /dev/null
+++ b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_1_124bbd63a2a85004ff9cf965ad984fb4._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-04-04T17:07:37Z"
+ content="""
+This is intentional, see [[!commit 451171b7c1eaccfd0f39d4ec1d64c6964613f55a]] 
+which changed setUrlPresent to only update presence info when the url
+belongs to the web but not when it's claimed by other special remotes.
+
+It makes sense for registerurl to be symmetric with rmurl, and rmurl only
+updates presence info when the url is a web url.
+
+To the extent I've been able to follow the complex reasoning there for why,
+part of it is clear: The web special remote is different from other special
+remotes in that content cannot be dropped from it by git-annex, and the url is
+the only pointer to content. So when rmurl removes the last web url, it makes
+sense to treat the content as no longer present on the web. But if the url is
+claimed by another special remote, which does support dropping content, the
+content would still be present on it after removing its url, and would be
+accessible w/o using that url, and `git-annex fsck --fast --from` would notice
+it was present and fix up the location log if it didn't show it as content.
+
+Also note that the rmurl man page documents this when it says:
+
+	Removing the last web url will make git-annex no longer treat content as being
+	present in the web special remote.
+
+All you need to do is use `git-annex setpresentkey` along with registerurl.
+"""]]
diff --git a/doc/bugs/registerurl_does_not_register_if_external_remote/comment_2_0f4d7c7f208b965ece8f017a38d7d0f1._comment b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_2_0f4d7c7f208b965ece8f017a38d7d0f1._comment
new file mode 100644
index 0000000000..1c6e9a2453
--- /dev/null
+++ b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_2_0f4d7c7f208b965ece8f017a38d7d0f1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2023-04-04T20:15:59Z"
+ content="""
+yet to re-review that reasoning, but does it mean that to merely register a URL client needs to
+- call `annex registerurl`
+- inspect to which remote URL was added/was claimed (is there a way? `whois` is silent)
+- if it was claimed by some special remote other than web -- use `annex setpresentkey`?
+
+Sounds like too much / too fragile, and somewhat different from how `addurl` behaves which does it all just fine regardless either it is web or some claimurl'ed remote.
+"""]]
diff --git a/doc/bugs/registerurl_does_not_register_if_external_remote/comment_3_31330afe2ea5e543219edb9e8071239b._comment b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_3_31330afe2ea5e543219edb9e8071239b._comment
new file mode 100644
index 0000000000..fab8aa8c7e
--- /dev/null
+++ b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_3_31330afe2ea5e543219edb9e8071239b._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2023-04-05T00:30:00Z"
+ content="""
+So to some degree it is a regression / broken behavior which initially worked just fine with registerurl -- tried the 6.20180913+git149-g23bd27773 version and it performed \"as expected\". Eh, never enough tests ;)
+
+I have looked at that commit changelog and [detailed description](http://source.git-annex.branchable.com/?p=source.git;a=blob;f=doc/bugs/suggests_to_enable_web_remote_even_when_there_is_no_web_urls_for_the_file/comment_4_6dff7befbaacbff573c5f72688966af5._comment;h=c636b09291a23bbce52b0367a767717137f99a21;hb=451171b7c1eaccfd0f39d4ec1d64c6964613f55a)  . Not fully grasping yet why `registerurl` should not behave symmetrically with `addurl` in being sufficient by itself to add a url to content so it becomes usable for `get` right away, without some other dances like `setpresentkey`.  I think I do get `rmurl` \"ambiguity\" but here on that more reflected below.
+
+Rereading your comment [above](https://git-annex.branchable.com/bugs/registerurl_does_not_register_if_external_remote/#comment-ba9d6517d8f8c10167da95b122a022b3):
+
+> part of it is clear: The web special remote is different from other special remotes in that content cannot be dropped from it by git-annex, and the url is the only pointer to content.
+
+This is just an assumption on some \"special nature of web remote\", e.g. the `datalad` remote also doesn't support dropping, and URL is also just the pointer to content. And CLAIMURL functionality came IIRC exactly for that use case and before adding some kind of duality for having content accessible directly from special remote and via url.
+
+> But if the url is claimed by another special remote, which does support dropping content, the content would still be present on it after removing its url, and would be accessible w/o using that url, 
+
+that is yet another assumption, since e.g. in the case of datalad remote `rmurl` effect would be identical to `web` remote, and there is no other way to get content from that remote. (so there is no duality mentioned above)
+
+> All you need to do is use git-annex setpresentkey along with registerurl.
+
+this somewhat contradicts above \"the content would still be present on it after removing its url\" which suggests that presence of URL for the remote already sufficient indication of being present on the remote.
+
+Overall, there is seems some assumptions about URLs and external remotes which ideally should be avoided.  May be it it should somehow be reflected in the external remote protocol to indicate that CLAIMing URL indicates that it is present at that URL, and that there is no other way to access that content from the remote besides via URL.
+
+As a workaround I of cause will now either `setpresentkey` or will just reassign all urls to be handled directly by web remote somehow.  But in the long run I think it is problematic design since even `registerurl` doesn't even report to which remote that URL was registered to
+
+```
+> git annex registerurl --json SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat http://www.oneukrainian.com/tmp/124.dat
+{\"command\":\"registerurl\",\"error-messages\":[],\"file\":null,\"input\":[\"SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat\",\"http://www.oneukrainian.com/tmp/124.dat\"],\"success\":true}
+```
+so how could I generally to know proper invocation for `setpresent` key to follow it up?
+
+"""]]
diff --git a/doc/bugs/registerurl_does_not_register_if_external_remote/comment_4_4f2c98add8a4f7b9f49e54e12fd79f10._comment b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_4_4f2c98add8a4f7b9f49e54e12fd79f10._comment
new file mode 100644
index 0000000000..6ef9e536ef
--- /dev/null
+++ b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_4_4f2c98add8a4f7b9f49e54e12fd79f10._comment
@@ -0,0 +1,64 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-04-05T17:25:48Z"
+ content="""
+Whups, I forgot about the newish unregisterurl! That's the true inverse of
+registerurl. So rmurl is really more the inverse of addurl.
+
+I think I've fully understood the situation that led to this reversion now.
+I do think it was a reversion. That change was all about SETURLPRESENT and
+SETURLMISSING in the external special remote protocol, as well as rmurl;
+I think that the effect on registerurl was not considered.
+
+So while I'd like to simplify registerurl to as basic a plumbing command as
+possible, and would prefer it not to update location tracking, there's the
+matter of backward compatability. Especially for simple cases like adding
+regular web urls with it. It would be ok to change it back to update location
+tracking for remotes that claim an url. As long as unregisterurl can be
+symmetric with it --- can it?
+
+rmurl also has its own wacky behavior in this area:
+
+	# git-annex addurl --fast https://cdimage.debian.org/debian-cd/current/i386/bt-cd/debian-11.6.0-i386-netinst.iso.torrent
+	(downloading torrent file...) addurl https://cdimage.debian.org/debian-cd/current/i386/bt-cd/debian-11.6.0-i386-netinst.iso.torrent (from bittorrent) (to debian-11.6.0-i386-netinst.iso) ok
+	(recording state in git...)
+	# git-annex rmurl debian-11.6.0-i386-netinst.iso https://cdimage.debian.org/debian-cd/current/i386/bt-cd/debian-11.6.0-i386-netinst.iso.torrent
+	rmurl debian-11.6.0-i386-netinst.iso ok
+	(recording state in git...)
+	# git-annex whereis debian-11.6.0-i386-netinst.iso
+	whereis debian-11.6.0-i386-netinst.iso (1 copy)
+	  	00000000-0000-0000-0000-000000000002 -- bittorrent
+	ok
+	# git-annex get debian-11.6.0-i386-netinst.iso
+	(fails)
+
+Is that a bug? It's certianly not ideal for the bittorrent special
+remote, which can't download the file once the url is removed. (It is
+documented behavior though.)
+
+While thinking about those questions, I thought of this situation:
+
+	# git-annex initremote s3 type=S3 ..
+	# git-annex copy --key $key --to s3
+	# git-annex registerurl $key $url
+	# git-annex unregisterurl $key $url
+	# git-annex drop --key $key --from s3
+
+At the end there, it's still able to drop the content from s3.
+
+Now, consider hypothetically, if I decide to make the S3 remote CLAIMURL
+urls that are in the S3 bucket. As things stand, that won't change the
+above scenario. (Although the key won't be recorded as located in the web
+after registerurl.)
+
+But... If unregisterurl is changed to update remote tracking for other remotes
+than web, after the S3 CLAIMURL change, the behavior of that scenario will not
+be the same! After unregisterurl, it will no longer consider the content to be
+present in S3. Now you're racking up S3 charges with content that git-annex
+stored in S3, but that it refuses to delete. That seems bad.
+
+So, that scenario is leading me to think that I should not change 
+unregisterurl (or rmurl) to update location tracking of remotes other than web.
+And so changing registerurl is also looking like a bad idea.
+"""]]
diff --git a/doc/bugs/registerurl_does_not_register_if_external_remote/comment_5_b9057ce47bb57b3a3dbe390672310898._comment b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_5_b9057ce47bb57b3a3dbe390672310898._comment
new file mode 100644
index 0000000000..dc0dda563f
--- /dev/null
+++ b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_5_b9057ce47bb57b3a3dbe390672310898._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-04-05T18:47:51Z"
+ content="""
+What I'm inclined to do is is add a --remote= parameter to registerurl and
+unregisterurl. If the specified remote does not claim the url, have it fail
+to add it. (See also [[todo/registerurl_--remote_REMOTE]])
+
+So, you can then use registerurl with --remote=$uuid, check that it
+succeeded, and then use setpresentkey to mark it present on that uuid.
+Without the fragility you complained of.
+
+Update: The --remote parameter is implemented now.
+
+(Could registerurl with --remote update location tracking itself? Maybe,
+but I'd worry about a scenario like in the previous comment.)
+"""]]
diff --git a/doc/bugs/registerurl_does_not_register_if_external_remote/comment_6_7a96a8a05e4a45477ec8b4eaea9374b1._comment b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_6_7a96a8a05e4a45477ec8b4eaea9374b1._comment
new file mode 100644
index 0000000000..c5ffb6758a
--- /dev/null
+++ b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_6_7a96a8a05e4a45477ec8b4eaea9374b1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2023-04-05T19:36:40Z"
+ content="""
+Obviously, as the author of the referenced wishlist, I would welcome addition of `--remote` option to both those commands. 
+
+But IMHO addition of the option doesn't solve initial/naive/programmable user oriented use case where user doesn't know which remote could or should handle the URL, and just wants, analogously or complimentary to `addurl`, to extend the list of the urls available for some key. There is even no user level interface to ask for \"what remotes can handle this url\" to erect some tandem of commands to register extra URLs for a key. So I don't see how addition of the option would solve the problem.
+"""]]
diff --git a/doc/bugs/registerurl_does_not_register_if_external_remote/comment_7_649f04c1909ab803eabe2eea7f37c6fd._comment b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_7_649f04c1909ab803eabe2eea7f37c6fd._comment
new file mode 100644
index 0000000000..3e01ef10f2
--- /dev/null
+++ b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_7_649f04c1909ab803eabe2eea7f37c6fd._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2023-04-05T19:57:37Z"
+ content="""
+Well, unregisterurl and rmurl can't safely update location tracking for remotes
+other than the web. Unless there were some way to know that simply removing an
+url was *sufficient*, like it is for the web, and unlike how it would be
+with my S3 remote scenario above.
+
+But, the only issue with registerurl updating location tracking is that it's
+not symmetric with unregisterurl.
+
+So is that symmetry more important than comment 6? I don't know. In both
+cases, some users are going to be surprised by inconsistent behavior.
+
+The only way to avoid all user surprise would be to go back in time and 
+make these plumbing commands not update location tracking from the start.
+"""]]
diff --git a/doc/bugs/registerurl_does_not_register_if_external_remote/comment_8_542bd923122ba24fe9cb14d36b97f15d._comment b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_8_542bd923122ba24fe9cb14d36b97f15d._comment
new file mode 100644
index 0000000000..b839dd2a70
--- /dev/null
+++ b/doc/bugs/registerurl_does_not_register_if_external_remote/comment_8_542bd923122ba24fe9cb14d36b97f15d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-04-05T21:00:04Z"
+ content="""
+Guess I'll come down on the side of restoring old behavior which was
+changed w/o warning (and without the new behavior ever being documented).
+
+And on the side of user experience showing the current behavior is surprising.
+
+The future users who get surprised by the resulting inconsistency 
+of unregisterurl not unsetting location tracking will just have to
+live with it.. Sigh.
+"""]]
diff --git a/doc/bugs/regression_with_S3_creds_not_used.mdwn b/doc/bugs/regression_with_S3_creds_not_used.mdwn
new file mode 100644
index 0000000000..b5ca1d181a
--- /dev/null
+++ b/doc/bugs/regression_with_S3_creds_not_used.mdwn
@@ -0,0 +1,59 @@
+### Please describe the problem.
+
+I am having a problem on Windows in which the AWS access credentials are stored but not used. When I have the ```AWS_ACCESS_KEY_ID``` and ```AWS_SECRET_ACCESS_KEY``` variables are set, everything works correctly. However if I open a new window that doesn't have envs set, git annex sync --content fails with a Forbidden message. Looking in the creds directory, I see plaintext creds stored.
+
+### What steps will reproduce the problem?
+
+```
+# set AWS_ACCESS_KEY_ID=thing1
+# set AWS_SECRET_ACCESS_KEY=thing2
+# git init test
+# cd test
+# git annex init
+# git annex initremote s3cloud type=S3 encryption=pubkey keyid=key embedcreds=yes
+ ... everything works, annex-uuid is created, etc ...
+
+# now open a new window, navigate to proper repo
+
+# git annex sync --content
+
+... forbidden messages
+
+# Reset the env vars
+... sync works as normal ...
+```
+
+Note that this fails *silently* when using the webapp. The app shows percentage of upload, and the uploads "complete" but the log shows:
+
+```
+  S3Error {s3StatusCode = Status {statusCode = 403, statusMessage = "Forbidden"}, s3ErrorCode = "InvalidAccessKeyId", s3ErrorMessage = "The AWS Access Key Id you provided does not exist in our records.", s3ErrorResource = Nothing, s3ErrorHostId = Just "/MfOhrvmoi1uTsuJDaV2c+3jxqt+/cAC8KBvGkbE+os1BAPAw/bLeNHiUF8kbSJ+2cMuNO+0mzQ=", s3ErrorAccessKeyId = Just "redacted", s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+```
+
+### What version of git-annex are you using? On what operating system?
+
+I'm on Windows:
+
+```
+git-annex version: 5.20151019-gcc50c00
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feed
+s Quvi TDFA TorrentParser Database
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384
+SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEI
+N256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glac
+ier ddar hook external
+```
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I have successfully used git annex on linux and mac, and it is great!
diff --git a/doc/bugs/regression_with_S3_creds_not_used/comment_1_df5416ee63c8f026f3b3c77c74b67ce4._comment b/doc/bugs/regression_with_S3_creds_not_used/comment_1_df5416ee63c8f026f3b3c77c74b67ce4._comment
new file mode 100644
index 0000000000..dbfb7c0db1
--- /dev/null
+++ b/doc/bugs/regression_with_S3_creds_not_used/comment_1_df5416ee63c8f026f3b3c77c74b67ce4._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-12-02T17:11:47Z"
+ content="""
+I tried reproducing this with the current version of git-annex on windows,
+and didn't see the problem. The creds file was used when the AWS_*
+environment variables were not set.
+
+What was the version of git-annex that was working before this reversion?
+
+Does the creds files corresponding to the uuid of your S3 remote exist?
+Does it contain 2 lines, for the access key and secret key, respectively?
+
+The webapp failure message seems to indicate that git-annex is has found
+creds, but they somehow have the wrong values. Does the s3ErrorAccessKeyId
+that you redacted match the access key that you told git-annex to use?
+(Note that it should be ok to show the s3 access key as long as you don't
+also show what the secret key is AFAIK.)
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist.mdwn b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist.mdwn
new file mode 100644
index 0000000000..3bfdf9e1d9
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist.mdwn
@@ -0,0 +1,67 @@
+### Please describe the problem.
+
+I created somelargefile on host1. A file with that name appears in the right place on host2 but I can't use it:
+
+
+    host2:~/annex% cat somelargefile
+    cat: somelargefile: No such file or directory
+
+
+### What steps will reproduce the problem?
+
+I am running http://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz and I connected two hosts with the 'Local computer' workflow. I run assistant on both sides.
+
+I make a file on either side, wait a minute for it to sync, and then observe this on the remote side:
+
+    lrwxrwxrwx 1 drewp drewp 178 Jul  9 23:58 somelargefile -> .git/annex/objects/Pw/vw/SHA256E-s8--bf87165d313027621936809a01da1994f9bd20ff9580c1380e7636e2443fe4ed/SHA256E-s8--bf87165d313027621936809a01da1994f9bd20ff9580c1380e7636e2443fe4ed
+
+    host2:~/annex% ls -l .git/annex/objects/Pw/vw/SHA256E-s8--bf87165d313027621936809a01da1994f9bd20ff9580c1380e7636e2443fe4ed/              
+    total 4                                                                                                                            
+    -rw------- 1 drewp drewp 14 Jul  9 23:58 SHA256E-s8--bf87165d313027621936809a01da1994f9bd20ff9580c1380e7636e2443fe4ed.map
+
+My "large file" is in fact 8 bytes long. The .map file contains the string "somelargefile\n"
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 4.20130709-g339d1e0
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+local repository version: 3
+default repository version: 3
+supported repository versions: 3 4
+upgrade supported from repository versions: 0 1 2
+
+ubuntu 12.10 64-bit
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+New lines in .git/annex/daemon.log when I add another new file:
+
+
+    (merging synced/git-annex into git-annex...)
+
+    Updating bac8b65..0422d27
+    Fast-forward
+     newfile2 |    1 +
+     1 file changed, 1 insertion(+)
+     create mode 120000 newfile2
+    [2013-07-10 00:08:38 PDT] Committer: Committing changes to git
+    (Recording state in git...)
+    [2013-07-10 00:08:38 PDT] Pusher: Syncing with host1.local_annex 
+    To ssh://drewp@git-annex-host1.local-drewp_annex/~/annex/
+       a80b6f5..72c0865  git-annex -> synced/git-annex
+
+    Already up-to-date.
+
+
+# End of transcript or log.
+"""]]
+
+[[!meta title="local pairing git-annex-shell issue when using standalone tarball"]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_10_8a1d16b2aaba224e94be3d9dcc036d91._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_10_8a1d16b2aaba224e94be3d9dcc036d91._comment
new file mode 100644
index 0000000000..9cfc0ebeec
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_10_8a1d16b2aaba224e94be3d9dcc036d91._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://bigasterisk.com/"
+ nickname="Drew Perttula"
+ subject="comment 10"
+ date="2013-07-27T07:42:26Z"
+ content="""
+Sorry, I meant to get those logs earlier but I got distracted.
+
+One confounding thing in the previous runs is that I may have had accidental instances of git-annex assistant running on at least one of the machines. I killed them all for this next attempt, and named the dir annex2 just in case.
+
+daemon.log files are now at http://bigasterisk.com/post/git-annex/logs1/
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_11_434ed328a22a6657dba3b2929a56e499._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_11_434ed328a22a6657dba3b2929a56e499._comment
new file mode 100644
index 0000000000..13bfc4468b
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_11_434ed328a22a6657dba3b2929a56e499._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 11"
+ date="2013-07-28T00:06:53Z"
+ content="""
+From the log on bang:
+
+<pre>
+[2013-07-27 00:33:15 PDT] read: ssh [\"-S\",\"/home/drewp/annex2/.git/annex/ssh/drewp@git-annex-dash.local-drewp_annex2\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"drewp@git-annex-dash.local-drewp_annex2\",\"git-annex-shell 'configlist' '/~/annex2/'\"]
+zsh:1: command not found: git-annex-shell
+Remote dash.local_annex2 does not have git-annex installed; setting remote.dash.local_annex2.annex-ignore
+</pre>
+
+You said you're running from the standalone tarball. I think that's the problem, probably if you get git-annex-shell into your path it'll just work.
+
+Can you paste the line git-annex added to \"dash\"'s .ssh/authorized_keys?
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_12_1837b70ace42882db3ab82e001680934._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_12_1837b70ace42882db3ab82e001680934._comment
new file mode 100644
index 0000000000..54ba310b54
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_12_1837b70ace42882db3ab82e001680934._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="http://bigasterisk.com/"
+ nickname="Drew Perttula"
+ subject="comment 12"
+ date="2013-07-28T05:36:39Z"
+ content="""
+Thanks for finding that. I added git-annex-shell to my path and ran again. The repo lists look good now. 
+
+For the record, here's what I am getting in authorized_keys on dash:
+
+    command=\"GIT_ANNEX_SHELL_DIRECTORY='/home/drewp/annex2' ~/.ssh/git-annex-shell\",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB3NzaC1y.......0c2ilnh drewp@bang
+
+
+When I went to the settings on each box, all 4 repository group select boxes were blank. I set them all to 'client'.
+
+How do we make this long ticket worth your time by improving the code so people don't hit the same trap in the future? I think I would have looked in the right direction if, instead of saying nothing and not having a uuid to make the links work, the web ui said something like this:
+
+    'command not found: git-annex-shell' on remote host. Sync disabled with this host.
+
+
+--------
+
+Next, I ran \"date > annex2/file1\" on bang. The web consoles said they synced, but no file appeared on dash. There was a ~/annex2/.git/annex/objects/../../SHA256.../SHA256... file on dash with the right contents, but no symlink showed up in dash:~/annex2. 
+
+I ran \"date > annex2/file2\" on dash, and then I got both file1 and file2 on both boxes.
+
+In the new logs at http://bigasterisk.com/post/git-annex/logs2/, the surprise is at [2013-07-27 22:10:49 PDT] where I thought dash would make a symlink called 'file1' but instead it reports no attempt or error. Later at [2013-07-27 22:12:08 PDT], while dealing with the upload of file2, dash finally makes the symlink for file1. 
+
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_13_ca9c87a10f29e41572540edeb99652f2._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_13_ca9c87a10f29e41572540edeb99652f2._comment
new file mode 100644
index 0000000000..07cf648653
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_13_ca9c87a10f29e41572540edeb99652f2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 13"
+ date="2013-07-30T18:51:38Z"
+ content="""
+I'm more interested in fixing core problems, like why it was not able to find git-annex-shell, than in fixing bugs in the web UI that follow on from those problems. 
+
+When you're using the standalone tarball, it's supposed to set up `~/.ssh/git-annex-shell` to point to wherever you've unpacked the tarball. The assistant does this the first time you run it, and any time it sees the file is out of date.
+I've tested this, and it appears to be working ok. I don't understand what happened in your case to prevent this from happening.
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_1_69eafc4201e3014ef1b5d74fe319e462._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_1_69eafc4201e3014ef1b5d74fe319e462._comment
new file mode 100644
index 0000000000..03d14c5860
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_1_69eafc4201e3014ef1b5d74fe319e462._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 1"
+ date="2013-07-10T16:31:40Z"
+ content="""
+Everything you've described is expected behavior, when the content of the file has not yet been transferred to the repository.
+
+There should be something in daemon.log about the transfer of the file. If there's an error message for the transfer, it will certainly show up there. You can enable debugging to get more information in daemon.log about file transfers.
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_2_b7a64db9abe006af8c30169ad849efe9._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_2_b7a64db9abe006af8c30169ad849efe9._comment
new file mode 100644
index 0000000000..954d6e375f
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_2_b7a64db9abe006af8c30169ad849efe9._comment
@@ -0,0 +1,76 @@
+[[!comment format=mdwn
+ username="http://bigasterisk.com/"
+ nickname="Drew Perttula"
+ subject="debug log"
+ date="2013-07-16T04:02:40Z"
+ content="""
+receiver side logs again, with --debug mode on. I don't see anything weird. 
+
+
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"git-annex\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"log\",\"refs/heads/git-annex..a7cb1b3f2a3f2a7d24827e10f9f3ac5848fd11d9\",\"--oneline\",\"-n1\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"log\",\"refs/heads/git-annex..4a2771e15cb5c7a0a8d70443e76b65c12115a8cd\",\"--oneline\",\"-n1\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"log\",\"refs/heads/git-annex..ddf6aa74d771521b11657edfae558858b60e8368\",\"--oneline\",\"-n1\"]
+    (merging synced/git-annex into git-annex...)
+    [2013-07-15 20:53:02 PDT] feed: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"update-index\",\"-z\",\"--index-info\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"4a2771e15cb5c7a0a8d70443e76b65c12115a8cd\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"log\",\"4a2771e15cb5c7a0a8d70443e76b65c12115a8cd..refs/heads/git-annex\",\"--oneline\",\"-n1\"]
+    [2013-07-15 20:53:02 PDT] call: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"update-ref\",\"refs/heads/git-annex\",\"4a2771e15cb5c7a0a8d70443e76b65c12115a8cd\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"symbolic-ref\",\"HEAD\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"refs/heads/master\"]
+    [2013-07-15 20:53:02 PDT] Merger: merging refs/heads/synced/master into refs/heads/master
+
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"symbolic-ref\",\"HEAD\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"refs/heads/master\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"--hash\",\"refs/heads/master\"]
+    [2013-07-15 20:53:02 PDT] call: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex/.git/annex/merge/\",\"merge\",\"--no-edit\",\"refs/heads/synced/master\"]
+    Updating 6f8cbe0..18cea18
+    Fast-forward
+     test-2013-07-15e |    1 +
+     1 file changed, 1 insertion(+)
+     create mode 120000 test-2013-07-15e
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"--hash\",\"refs/heads/master\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"diff-tree\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"-r\",\"6f8cbe0a34d70e70a6365385bbd4338d97047d4b\",\"18cea18855143095a872a463eb0a7cf5dd81de4c\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"git-annex\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"log\",\"refs/heads/git-annex..4a2771e15cb5c7a0a8d70443e76b65c12115a8cd\",\"--oneline\",\"-n1\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"log\",\"refs/heads/git-annex..ddf6aa74d771521b11657edfae558858b60e8368\",\"--oneline\",\"-n1\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"log\",\"refs/heads/git-annex..a7cb1b3f2a3f2a7d24827e10f9f3ac5848fd11d9\",\"--oneline\",\"-n1\"]
+    [2013-07-15 20:53:02 PDT] feed: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"update-index\",\"-z\",\"--index-info\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"refs/heads/git-annex\"]
+    [2013-07-15 20:53:02 PDT] Watcher: add symlink test-2013-07-15e
+    [2013-07-15 20:53:02 PDT] chat: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"hash-object\",\"-t\",\"blob\",\"-w\",\"--stdin\",\"--no-filters\"]
+    [2013-07-15 20:53:02 PDT] Committer: committing 1 changes
+    [2013-07-15 20:53:02 PDT] Committer: Committing changes to git
+    (Recording state in git...)
+    [2013-07-15 20:53:02 PDT] feed: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"update-index\",\"-z\",\"--index-info\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"commit\",\"--allow-empty-message\",\"--no-edit\",\"-m\",\"\",\"--quiet\",\"--no-verify\"]
+    [2013-07-15 20:53:02 PDT] Pusher: Syncing with host1.local_annex 
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"symbolic-ref\",\"HEAD\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"refs/heads/master\"]
+    [2013-07-15 20:53:02 PDT] Pusher: pushing to [Remote { name =\"host1.local_annex\" }]
+    [2013-07-15 20:53:02 PDT] call: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"branch\",\"-f\",\"synced/master\"]
+    [2013-07-15 20:53:02 PDT] call: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"push\",\"host1.local_annex\",\"git-annex:synced/git-annex\",\"master:synced/master\"]
+    To ssh://drewp@git-annex-host1.local-drewp_annex/~/annex/
+       a7cb1b3..4a2771e  git-annex -> synced/git-annex
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"git-annex\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"push\",\"host1.local_annex\",\"git-annex:synced/git-annex\",\"master\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"log\",\"refs/heads/git-annex..4a2771e15cb5c7a0a8d70443e76b65c12115a8cd\",\"--oneline\",\"-n1\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"log\",\"refs/heads/git-annex..ddf6aa74d771521b11657edfae558858b60e8368\",\"--oneline\",\"-n1\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"symbolic-ref\",\"HEAD\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"refs/heads/master\"]
+    [2013-07-15 20:53:02 PDT] Merger: merging refs/remotes/host1.local_annex/synced/master into refs/heads/master
+
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"symbolic-ref\",\"HEAD\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"refs/heads/master\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"--hash\",\"refs/heads/master\"]
+    [2013-07-15 20:53:02 PDT] call: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex/.git/annex/merge/\",\"merge\",\"--no-edit\",\"refs/remotes/host1.local_annex/synced/master\"]
+    Already up-to-date.
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"show-ref\",\"--hash\",\"refs/heads/master\"]
+    [2013-07-15 20:53:02 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"diff-tree\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"-r\",\"18cea18855143095a872a463eb0a7cf5dd81de4c\",\"18cea18855143095a872a463eb0a7cf5dd81de4c\"]
+    [2013-07-15 20:53:28 PDT] read: git [\"--git-dir=/home/drewp/annex/.git\",\"--work-tree=/home/drewp/annex\",\"ls-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"preferred-content.log\"]
+
+I also noticed on host1 where the file was made, there is a git node in gitk that says 'Local uncommitted changes, not checked in to index' and this node appears to have all my file contents as diffs. So the problem is maybe not the transfer, but the failure of the originating side to commit the file contents properly?
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_3_197ac6070f256131c6e18a07aa3834fa._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_3_197ac6070f256131c6e18a07aa3834fa._comment
new file mode 100644
index 0000000000..d772de5af1
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_3_197ac6070f256131c6e18a07aa3834fa._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 3"
+ date="2013-07-16T18:03:40Z"
+ content="""
+It's normal for git diff and gitk to look like that in a repository that's using direct mode.
+
+In your log, I see you added a file \"test-2013-07-15e\". And I don't see any indication that it tried to transfer it.
+
+There are a few reasons that could happen. If you've \"paused\" syncing with a remote in the webapp, it could do that.
+
+I think more likely would be if you've put the remote repository in a repository group that doesn't want the file. If it's configured to be in the Manual group or the Source group (or the Transfer, Public, or Small Archive group for that matter), the assistant won't try to send files to it. You can check this by editing the repository in the webapp. It should probably be set to be in the Client group.
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_4_fe07832333b536c71b7dcb46a4a44bd0._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_4_fe07832333b536c71b7dcb46a4a44bd0._comment
new file mode 100644
index 0000000000..2201db88e6
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_4_fe07832333b536c71b7dcb46a4a44bd0._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://bigasterisk.com/"
+ nickname="Drew Perttula"
+ subject="comment 4"
+ date="2013-07-25T05:02:16Z"
+ content="""
+I saw the 'syncing enabled'/'syncing disabled' switch in the webapp, which I think is what you're calling pause. That was always enabled.
+
+I never adjusted the groups, but I see in the webapp that my remote is busted in other ways. It has no title, and settings->edit makes an error page. The edit link is like this:
+
+http://127.0.0.1:38187/config/repository/edit/NoUUID?auth=4294a...333c
+
+and the error is 
+
+    Internal Server Error
+    Unknown UUID
+
+I'll try re-configuring that remote. I wish the webapp could tell me more about what is broken with the remote repo and where I might go to repair it. 
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_5_540bca4e6fdfc10eeab875ecc0f2b3f3._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_5_540bca4e6fdfc10eeab875ecc0f2b3f3._comment
new file mode 100644
index 0000000000..8e00198efa
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_5_540bca4e6fdfc10eeab875ecc0f2b3f3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://bigasterisk.com/"
+ nickname="Drew Perttula"
+ subject="comment 5"
+ date="2013-07-25T05:14:12Z"
+ content="""
+BTW \"go enter it into the computer you want to pair with\" is a very frustrating instruction to read. Every time I try to do a pairing and I encounter that, it's telling me \"now it's time for you to guess what to do, so this is probably where you'll screw things up.\" I have no idea where to enter that secret phrase. I would also like to know if 'asdfasdf' is a good secret phrase or not, presuming the two computers are both on my internal network. Does the secret matter later or is it just used for a minute?
+
+So far, I keep getting blank repo names with the NoUUID edit url, or I fail to accomplish a pairing at all.
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_6_3f236b35e9820cd88bb77fcd57d6975e._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_6_3f236b35e9820cd88bb77fcd57d6975e._comment
new file mode 100644
index 0000000000..63261fb9dc
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_6_3f236b35e9820cd88bb77fcd57d6975e._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="http://bigasterisk.com/"
+ nickname="Drew Perttula"
+ subject="comment 6"
+ date="2013-07-25T05:36:07Z"
+ content="""
+Here's how little it takes for things to go wrong:  
+  
+----
+First host:  
+
+bang(pts/17):~/annex% git init  
+Initialized empty Git repository in /home/drewp/annex/.git/  
+
+bang(pts/17):~/annex% git-annex init  
+init  ok  
+(Recording state in git...)
+
+bang(pts/17):~/annex% git-annex webapp --listen 10.1.0.1:9999    
+http://10.1.0.1:9999/?auth=6f9a8b...
+
+
+----
+Second host:
+
+dash(pts/34):~/annex% git init  
+Initialized empty Git repository in /home/drewp/annex/.git/
+
+dash(pts/34):~/annex% git-annex init  
+init  ok  
+(Recording state in git...)
+
+dash(pts/34):~/annex% git-annex webapp --listen 10.1.0.229:9999  
+http://10.1.0.229:9999/?auth=f28bd56b456....
+
+
+Browse to first URI. Add another repo. Local computer. Enter 'qwerty'.   
+Browse to second URI. Respond to pairing request. Enter 'qwerty' again.  
+View both dashboards: http://bigasterisk.com/post/git-annex-bad-pair.png  
+
+
+
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_7_3cc5dae0351201522711a7caeecd60d5._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_7_3cc5dae0351201522711a7caeecd60d5._comment
new file mode 100644
index 0000000000..832f38fa5d
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_7_3cc5dae0351201522711a7caeecd60d5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 7"
+ date="2013-07-25T20:02:18Z"
+ content="""
+What settings does `.git/config` have for the git remote created by the local pairing process?
+
+Since I can't reproduce any problems with local pairing -- it works great on this network -- you will need to enable debugging, reproduce the bug, and send a debug log for me to debug this any further.
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_8_3c3883cb66d02a15d5de84d22aa113da._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_8_3c3883cb66d02a15d5de84d22aa113da._comment
new file mode 100644
index 0000000000..bf14ad573e
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_8_3c3883cb66d02a15d5de84d22aa113da._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="http://bigasterisk.com/"
+ nickname="Drew Perttula"
+ subject="~/annex/.git/config files (after running the steps above)"
+ date="2013-07-26T13:20:29Z"
+ content="""
+    dash(pts/32):~/annex% cat .git/config 
+    [core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = false
+        logallrefupdates = true
+    [annex]
+        uuid = ddbb5112-3cff-46d3-b42a-f3a6826827a5
+        version = 3
+    [remote \"bang.local_annex\"]
+        url = ssh://drewp@git-annex-bang.local-drewp_annex/~/annex/
+        fetch = +refs/heads/*:refs/remotes/bang.local_annex/*
+        annex-ignore = true
+        annex-cost = 175.0
+
+
+    bang(pts/16):~/annex% cat .git/config
+    [core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = false
+        logallrefupdates = true
+    [annex]
+        uuid = c8a6c420-0567-4f33-8abb-e44b2012ad55
+        version = 3
+    [remote \"dash.local_annex\"]
+        url = ssh://drewp@git-annex-dash.local-drewp_annex/~/annex/
+        fetch = +refs/heads/*:refs/remotes/dash.local_annex/*
+        annex-ignore = true
+        annex-cost = 175.0
+        
+"""]]
diff --git a/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_9_c8cece9559bd2dc6154cd28772369e48._comment b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_9_c8cece9559bd2dc6154cd28772369e48._comment
new file mode 100644
index 0000000000..0fd052a4cb
--- /dev/null
+++ b/doc/bugs/remote_files_appear_but_are_unreadable_because_their_symlink_targets_don__39__t_exist/comment_9_c8cece9559bd2dc6154cd28772369e48._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 9"
+ date="2013-07-26T16:55:08Z"
+ content="""
+Like I sort of expected, this is missing a remote.$foo.annex-uuid setting. But I don't know why yet. I need a debug log to figure this out.
+
+Can you enable debugging (run git-annex webapp --debug), reproduce the problem again, and send me the log?
+"""]]
diff --git a/doc/bugs/remote_not_showing_up_in_webapp.mdwn b/doc/bugs/remote_not_showing_up_in_webapp.mdwn
new file mode 100644
index 0000000000..f2f83f064f
--- /dev/null
+++ b/doc/bugs/remote_not_showing_up_in_webapp.mdwn
@@ -0,0 +1,100 @@
+### Please describe the problem.
+
+This is a followup on [[bugs/internal_server_error:_unknown_UUID_on_webapp]]. In that issue, webapps previous to 20130929 would crash with `internal server error: unknown UUID`. This was fixed at that date, but some problems remain, namely that the remote that is recognized on the commandline doesn't show up in the webapp.
+
+`markov` is able to push to `marcos`, but not the reverse because `markov` is hidden behind a NAT. `git annex sync` seems to do the right thing accordingly on both ends (which is: `marcos` doesn't try to push to `markov` but `markov` pushes to `marcos`).
+
+### What steps will reproduce the problem?
+
+See [[bugs/internal_server_error:_unknown_UUID_on_webapp]]. I didn't do any further changes other than upgrade `git-annex` on both ends.
+
+### What version of git-annex are you using? On what operating system?
+
+`marcos` is now running `Version: 4.20131105-g8efdc1a Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS Feeds Quvi TDFA CryptoHash`
+
+`markov` is now running the wheezy backport, `4.20131002~bpo70+1`.
+
+### Please provide any additional information below.
+
+#### On `marcos`
+
+Here's the output of `git annex status` on `marcos`:
+
+[[!format sh """
+anarcat@marcos:books$ git annex status
+repository mode: direct
+trusted repositories: 0
+semitrusted repositories: 3
+        00000000-0000-0000-0000-000000000001 -- web
+        a75cbbf7-e055-423e-b375-443e0552c9e2 -- here (anarcat@marcos:/srv/books)
+        aa500f29-42d9-4777-ae02-4a2c3d47db44 -- anarcat@markov:~/books
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 7.04 gigabytes (+1 megabyte reserved)
+local annex keys: 736
+local annex size: 3.92 gigabytes
+annexed files in working tree: 721
+size of annexed files in working tree: 3.92 gigabytes
+bloom filter size: 16 mebibytes (0.1% full)
+backend usage:
+        SHA256E: 1457
+# End of transcript or log.
+"""]]
+
+Here's a screenshot of the idle webapp on marcos:
+
+<img src="http://i.imgur.com/3HFgj3w.png" />
+
+You can clearly see that the webapp doesn't see the `markov` remote.
+
+When `markov` transfers stuff, `marcos` sees the transfers happening, but marks it as going to the `unknown` remote:
+
+<img src="http://i.imgur.com/YOu9GbA.png" />
+
+Clicking on that link is what was previously triggering [[bugs/internal_server_error:_unknown_UUID_on_webapp]] but now yields a "Unknown remote" error.
+
+<img src="http://i.imgur.com/y7JxULi.png" />
+
+#### On `markov`:
+
+Here is a screenshot from `markov` that shows *it* knows about both repositories and seem to behave properly:
+
+<img src="http://i.imgur.com/fTMslVT.png" />
+
+And here's the output of `git annex status` on markov:
+
+[[!format sh """
+anarcat@desktop008:books$ git annex status
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 3
+        00000000-0000-0000-0000-000000000001 -- web
+        a75cbbf7-e055-423e-b375-443e0552c9e2 -- origin (anarcat@marcos:/srv/books)
+        aa500f29-42d9-4777-ae02-4a2c3d47db44 -- here (anarcat@markov:~/books)
+untrusted repositories: 0
+transfers in progress:
+        downloading Patrick K. O'Brien/Philip's Atlas of World History, Concise Edition (115)/Philip's Atlas of World History, Concise Edition - Patrick K. O'Brien.pdf from origin
+available local disk space: 93.25 gigabytes (+1 megabyte reserved)
+temporary directory size: 50.07 megabytes (clean up with git-annex unused)
+local annex keys: 708
+local annex size: 3.81 gigabytes
+known annex keys: 721
+known annex size: 3.92 gigabytes
+bloom filter size: 16 mebibytes (0.1% full)
+backend usage:
+        SHA256E: 1429
+"""]]
+
+Finally, note that you sometimes see `desktop008` above: it turns out I am running `git annex` from my workstation, which NFS-mounts the `/home` directory of `markov` into `/srv/musique`.  --[[anarcat]]
+
+Yesterday, I made the webapp register ssh remotes it creates. 
+They then show up in the webapp when run in a repository where that ssh
+remote is not enabled.
+
+You can also manually register a ssh remote. First set up the git remote
+as usual. Then run `git annex initremote type=git name=foo
+location=$url`.
+
+[[!meta title="webapp shows transfer from 'unknown' when no remote is configured for a system that is downloading files"]]
+
+[[!tag confirmed]]
diff --git a/doc/bugs/remote_not_showing_up_in_webapp/comment_1_2a269732fd528f505777542d3556437a._comment b/doc/bugs/remote_not_showing_up_in_webapp/comment_1_2a269732fd528f505777542d3556437a._comment
new file mode 100644
index 0000000000..4582a30715
--- /dev/null
+++ b/doc/bugs/remote_not_showing_up_in_webapp/comment_1_2a269732fd528f505777542d3556437a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-06T16:38:47Z"
+ content="""
+marcov does not show up in the webapp because there is no configured git remote for it.
+
+This is a slightly confusing corner of the webapp. The webapp will show repositories that do not have a configured remote, but it only does it for special remotes. ssh repos, being regular git remotes, don't currently show up in the webapp unless that repository is actually set up as a remote.
+
+It should certainly not show it as \"unknown\"; it would be much better to use the full repo description here, since it does not have a remote name.
+(Unless the description is really long!)
+
+I think you'll also get the \"unknown uuid\" screen even for a special remote that is not configured in the local repository. So that needs to be fixed.
+
+Finally, it would probably be good for the webapp to show ssh repos that don't have remotes as existing, and let the user enter a ssh address to configure them. The problem with trying to do this is it actually has no idea that this is a ssh repo. It could just as easily be a local directory. The UI to configure  it would be pretty elaborate.
+"""]]
diff --git a/doc/bugs/remote_not_showing_up_in_webapp/comment_2_10638e99e2e11460f99266f56adbc1db._comment b/doc/bugs/remote_not_showing_up_in_webapp/comment_2_10638e99e2e11460f99266f56adbc1db._comment
new file mode 100644
index 0000000000..fb2976657e
--- /dev/null
+++ b/doc/bugs/remote_not_showing_up_in_webapp/comment_2_10638e99e2e11460f99266f56adbc1db._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 2"
+ date="2014-04-19T04:26:57Z"
+ content="""
+i hit that thing again, utterly confused. it happens all the time with my laptop, which has access to my workstation, but not the other way around. so from the POV of my laptop, things make sense somehow, but from the workstation, the laptop doesn't show up at all, and when there's a transfer, it says it's into the unknown.
+
+really confusing... surely there's a way to show the remote name at least...
+"""]]
diff --git a/doc/bugs/remote_not_showing_up_in_webapp/comment_3_4aa72acc0938f7f824ba10f3f102e8bc._comment b/doc/bugs/remote_not_showing_up_in_webapp/comment_3_4aa72acc0938f7f824ba10f3f102e8bc._comment
new file mode 100644
index 0000000000..c0280b48bc
--- /dev/null
+++ b/doc/bugs/remote_not_showing_up_in_webapp/comment_3_4aa72acc0938f7f824ba10f3f102e8bc._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="comment 3"
+ date="2014-05-23T14:57:43Z"
+ content="""
+Yesterday, I made the webapp register ssh remotes it creates.  
+They then show up in the webapp when run in a repository where that ssh
+remote is not enabled.
+ 
+You can also manually register a ssh remote. First set up the git remote
+as usual. Then run `git annex initremote type=git name=foo
+location=$url`.
+
+So, this bugs titular issue is fixed, but the issue of it displaying \"unknown\" rather than the remote description is not yet fixed. Will retitle this bug appropriately, and leave open until that gets fixed.
+"""]]
diff --git a/doc/bugs/remotes_disappeared.mdwn b/doc/bugs/remotes_disappeared.mdwn
new file mode 100644
index 0000000000..918dc04337
--- /dev/null
+++ b/doc/bugs/remotes_disappeared.mdwn
@@ -0,0 +1,300 @@
+### Please describe the problem.
+
+Some remotes disappeared from `git annex info` after synchronising with a new repo.
+
+### What steps will reproduce the problem?
+
+1. have a nice repository full of remotes and special remotes
+2. create a new repository with `git init; git annex init; git reinit <some UUID from a previously lost repository>`
+3. sync the two repositories
+
+Expected the result: restore the lost repository the its previous state.
+
+Actual result: previous state available, but lost track of other repositories.
+
+I suspect there may be a relation to an old "forget history" transition at play here, as the last commit on the git-annex branch is:
+
+```
+commit 266099a48af81eab71d27741b43776372aa519c4
+Merge: 13ed0a6 05681b9
+Author: Antoine Beaupré <anarcat@debian.org>
+Date:   Wed Mar 30 12:49:55 2016 -0400
+
+    continuing transition ["forget git history","forget dead remotes","forget git history","forget dead remotes","forget git history","forget git history","forget dead remotes","forget git history","forget dead remotes","forget git history","forget dead remotes","forget git history","forget dead remotes"]
+```
+
+So in short, some remotes that i never marked as dead seem to be caught in the whirlpool of `forget` transitions.
+
+### What version of git-annex are you using? On what operating system?
+
+ 5.20151208-1~bpo8+1 on debian jessie.
+
+### Please provide any additional information below.
+
+So here's what i could salvage from my terminal history. Note that window resizing may have truncated some lines. Apologies for the mess...
+
+    [1077]anarcat@angela:cb39412b-d221-4846-a9dd-cdbabd9958f1$ sudo mkdir Music
+    [1078]anarcat@angela:cb39412b-d221-4846-a9dd-cdbabd9958f1$ sudo chown anarcat Music
+    [1079]anarcat@angela:cb39412b-d221-4846-a9dd-cdbabd9958f1$ cd Music/
+    [1082]anarcat@angela:Music$ git init
+    Dépôt Git vide initialisé dans /media/anarcat/cb39412b-d221-4846-a9dd-cdbabd9958f1/Music/.gi
+    [1083]anarcat@angela:Music$ git annex init
+    init  ok
+    (recording state in git...)
+    [1084]anarcat@angela:Music130$ git annex reinit 6f812272-18c8-4346-b68a-f57ae50f657e
+    reinit 6f812272-18c8-4346-b68a-f57ae50f657e ok
+    [1086]anarcat@angela:Music$ git remote add origin ~/mp3
+    [1087]anarcat@angela:Music$ git remote update # 12:44
+    Récupération de origin
+    warning: no common commits
+    remote: Décompte des objets: 819312, fait.
+    remote: Compression des objets: 100% (368189/368189), fait.
+    Réception d'objets: 100% (819312/819312), 64.97 MiB | 5.19 MiB/s, fait.
+    remote: Total 819312 (delta 653024), reused 588679 (delta 449859)
+    Depuis /home/anarcat/mp3
+     * [nouvelle branche] git-annex  -> origin/git-annex
+     * [nouvelle branche] master     -> origin/master
+     * [nouvelle branche] synced/git-annex -> origin/synced/git-annex
+     * [nouvelle branche] synced/master -> origin/synced/master
+     * [nouvelle étiquette] bak        -> bak
+    [1089]anarcat@angela:Music$ git annex merge
+    merge git-annex (merging origin/git-annex origin/synced/git-annex into git-annex...)
+    (recording state in git...)
+    [1092]anarcat@angela:Music$ git co master
+    Extraction des fichiers: 100% (22187/22187), fait.
+    La branche master est paramétrée pour suivre la branche distante master depuis origin.
+    Déjà sur 'master'
+    [1099]anarcat@angela:Music130$ date; time git annex get --quiet --in here; date
+    mercredi 30 mars 2016, 12:53:29 (UTC-0400)
+    sha256sum: .git/annex/tmp/SHA256E-s4476433--bb954dfe81f3d0906a18e53d02040d1d8f8e78917552e0033b056bbf885710d9.mp3: Aucun fichier ou dossier de ce type
+      sha256sum failed
+    git-annex: .git/annex/tmp/SHA256E-s4476433--bb954dfe81f3d0906a18e53d02040d1d8f8e78917552e0033b056bbf885710d9.mp3: openBinaryFile: does not exist (No such file or directory)
+    git-annex: get: 1 failed
+    Command exited with non-zero status 1
+    156.09user 39.26system 36:44.62elapsed 8%CPU (0avgtext+0avgdata 44900maxresident)k
+    8775224inputs+5811728outputs (51major+281689minor)pagefaults 0swaps
+    mercredi 30 mars 2016, 13:30:36 (UTC-0400)
+
+... in the last step, the external device disappeared and the transfer failed.
+
+After reconnecting the device, I tried to synchronise its content with the content of another device, but that device is gone!
+
+[[!format sh """
+[1013]anarcat@angela:Music1$ git annex info --fast # first notice how the remotes are not the same on the two repositories
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 5
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        0f9185ea-8462-4230-8cae-462a1ad0df36 -- origin
+        45124790-dbb7-4e2e-bc0a-acfb618a01e0 -- anarcat@angela:/media/anarcat/cb39412b-d221-4846-a9dd-cdbabd9958f1/Music
+        6f812272-18c8-4346-b68a-f57ae50f657e -- here
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 4.68 gigabytes (+1 megabyte reserved)
+[1014]anarcat@angela:Music$ cd ~/mp3
+[1015]anarcat@angela:mp3$ git annex info --fast # here there is a lot more remotes!
+repository mode: indirect
+trusted repositories: 4
+        22921df6-ff75-491c-b5d9-5a2aab33a689 -- anarcat@marcos:/media/anarcat/79884590-6445-4a6f-ae12-050b9a7c1912/mp3
+        b7802161-c984-4c9f-8d05-787a29c41cfe -- anarcat@marcos:/srv/mp3 [marcos]
+        c2ca4a13-9a5f-461b-a44b-53255ed3e2f9 -- anarcat@desktop008:/srv/musique/anarcat/mp3 [markov]
+        f8818d12-9882-4ca5-bc0f-04e987888a8d -- anarcat@marcos:/media/anarcat/green_crypt/mp3/
+semitrusted repositories: 8
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        0f9185ea-8462-4230-8cae-462a1ad0df36 -- anarcat@angela:~/mp3 [here]
+        3f6d8082-6f4b-4faa-a3d9-bd5db1891077 -- anarcat@lab-sc.no-ip.org:mp3
+        4249a4ea-343a-43a8-9bba-457d2ff87c7d -- rachel@topcrapn:~/Musique/MUSIC/anarcat
+        487dda55-d164-4bf1-9d85-66caaa9c0743 -- 300GB hard drive labeled VHS [VHS]
+        6f812272-18c8-4346-b68a-f57ae50f657e -- htcones
+        f867da6f-78cb-49be-a0db-d1c8e5f53664 -- n900
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 13.51 gigabytes (+1 megabyte reserved)
+[1016]anarcat@angela:mp3$ cd -
+/media/anarcat/cb39412b-d221-4846-a9dd-cdbabd9958f1/Music
+[1017]anarcat@angela:Music$ git annex find --in f867da6f-78cb-49be-a0db-d1c8e5f53664 --not --in here # trying to sync with the n900 remote
+git-annex: there is no available git remote named "f867da6f-78cb-49be-a0db-d1c8e5f53664"
+[1018]anarcat@angela:Music1$ git annex sync # maybe some data is missing?
+commit  ok
+pull origin
+ok
+push origin
+Décompte des objets: 6368, fait.
+Delta compression using up to 2 threads.
+Compression des objets: 100% (6361/6361), fait.
+Écriture des objets: 100% (6368/6368), 693.21 KiB | 565.00 KiB/s, fait.
+Total 6368 (delta 5030), reused 11 (delta 3)
+To /home/anarcat/mp3
+   05681b9..266099a  git-annex -> synced/git-annex
+ok
+[1019]anarcat@angela:Music$ git annex find --in f867da6f-78cb-49be-a0db-d1c8e5f53664 --not --in here # trying again
+git-annex: there is no available git remote named "f867da6f-78cb-49be-a0db-d1c8e5f53664"
+[1020]anarcat@angela:Music1$ git annex find --in n900 --not --in here # of course, n900 is not a git remote locally
+git-annex: there is no available git remote named "n900"
+[1021]anarcat@angela:Music1$ git annex info --fast # and it's still not there
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 5
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        0f9185ea-8462-4230-8cae-462a1ad0df36 -- origin
+        45124790-dbb7-4e2e-bc0a-acfb618a01e0 -- anarcat@angela:/media/anarcat/cb39412b-d221-
+        6f812272-18c8-4346-b68a-f57ae50f657e -- here
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 4.68 gigabytes (+1 megabyte reserved)
+[1022]anarcat@angela:Music$ cd -
+/home/anarcat/mp3
+[1023]anarcat@angela:mp3$ git annex info --fast # worse: it's gone from my main repo!!
+repository mode: indirect
+trusted repositories: 2
+        b7802161-c984-4c9f-8d05-787a29c41cfe -- marcos
+        c2ca4a13-9a5f-461b-a44b-53255ed3e2f9 -- markov
+semitrusted repositories: 6
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        0f9185ea-8462-4230-8cae-462a1ad0df36 -- here
+        45124790-dbb7-4e2e-bc0a-acfb618a01e0 -- anarcat@angela:/media/anarcat/cb39412b-d221-4846-a9dd-cdbabd9958f1/Music
+        487dda55-d164-4bf1-9d85-66caaa9c0743 -- VHS
+        6f812272-18c8-4346-b68a-f57ae50f657e -- htcones
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 13.74 gigabytes (+1 megabyte rese
+"""]]
+
+In my opinion, git-annex shouldn't have lost the following repositories:
+
+        22921df6-ff75-491c-b5d9-5a2aab33a689 -- anarcat@marcos:/media/anarcat/79884590-6445-4a6f-ae12-050b9a7c1912/mp3
+        f8818d12-9882-4ca5-bc0f-04e987888a8d -- anarcat@marcos:/media/anarcat/green_crypt/mp3/
+        3f6d8082-6f4b-4faa-a3d9-bd5db1891077 -- anarcat@lab-sc.no-ip.org:mp3
+        4249a4ea-343a-43a8-9bba-457d2ff87c7d -- rachel@topcrapn:~/Musique/MUSIC/anarcat
+        f867da6f-78cb-49be-a0db-d1c8e5f53664 -- n900
+
+Those are repositories that are in the git-annex history, but that don't have git remotes associated with them, for various reasons. I do *not* believe I have marked any of those as "dead" except maybe 3f6d8082-6f4b-4faa-a3d9-bd5db1891077. f8818d12-9882-4ca5-bc0f-04e987888a8d was used during the weekend to do my backups, so it's definitely not dead.
+
+It is also interesting to note that even though `git annex info` doesn't know about the remotes, there is still tracking information about all of them (except the 3f one):
+
+[[!format txt """
+$ git cat-file -p git-annex:001/694/SHA256E-s6732474--e084001bc23a90bfd65d9a3fa20b7bf878be6a49fce7e5a9846efeeba8815516.mp3.log
+1376877225.866849s 1 b7802161-c984-4c9f-8d05-787a29c41cfe
+1378838314.653241s 1 c2ca4a13-9a5f-461b-a44b-53255ed3e2f9
+1379790798.215871s 1 0f9185ea-8462-4230-8cae-462a1ad0df36
+1391065040.28672s 1 22921df6-ff75-491c-b5d9-5a2aab33a689
+1397893686.079999s 1 487dda55-d164-4bf1-9d85-66caaa9c0743
+1398657510.376249s 1 4249a4ea-343a-43a8-9bba-457d2ff87c7d
+1407479149.838437s 1 f8818d12-9882-4ca5-bc0f-04e987888a8d
+1407479149.929843s 1 f8818d12-9882-4ca5-bc0f-04e987888a8d
+1407510928.457047s 1 487dda55-d164-4bf1-9d85-66caaa9c0743
+1424134721.290026s 1 b7802161-c984-4c9f-8d05-787a29c41cfe
+1424227570.153123s 1 487dda55-d164-4bf1-9d85-66caaa9c0743
+1445468844.056214s 1 f867da6f-78cb-49be-a0db-d1c8e5f53664
+1458775384.454193s 0 6f812272-18c8-4346-b68a-f57ae50f657e
+"""]]
+
+it's a mystery to me why that stuff disappeared from `git-annex info`. it's especially confusing since some commands seem to recognize there *was* a remote there:
+
+    $ git annex enableremote f867da6f-78cb-49be-a0db-d1c8e5f53664
+    git-annex: Unknown special remote.
+            f867da6f-78cb-49be-a0db-d1c8e5f53664 -- n900
+
+Notice how `n900` was shown here: that metadata obviously *is* somewhere! The uuid.log file is obviously damaged:
+
+    [1036]anarcat@angela:mp31$ git cat-file -p git-annex:uuid.log
+    45124790-dbb7-4e2e-bc0a-acfb618a01e0 anarcat@angela:/media/anarcat/cb39412b-d221-4846-a9dd-cdbabd9958f1/Music timestamp=1459356223.537195s
+
+... and it clearly looks like the file was damaged on that new repo:
+
+[[!format txt """
+*   266099a N (synced/git-annex, git-annex) continuing transition ["forget git history","forget dead remotes","forget git history","forget dead remotes","forget git history","forget git history","forget dead remotes","forget git history","forget dead remotes","forget git history","forget dead remotes","forget git history","forget dead remotes"] (il y a 75 minutes) <Antoine Beaupré>
+|\
+* | 298cc10 N (htcones/synced/git-annex) continuing transition ["forget git history","forget dead remotes","forget git history","forget dead remotes","forget git history","forget git history","forget dead remotes","forget git history","forget dead remotes","forget git history","forget dead remotes","forget git history","forget dead remotes"] (il y a 13 jours) <Antoine Beaupré>| |
+| | diff --git a/uuid.log b/uuid.log
+| | index 656b369..a730ad0 100644
+| | --- a/uuid.log
+| | +++ b/uuid.log
+| | @@ -1,14 +1,9 @@
+| |  0f9185ea-8462-4230-8cae-462a1ad0df36 anarcat@angela:~/mp3 timestamp=1376882226.164478s
+| |  22921df6-ff75-491c-b5d9-5a2aab33a689 anarcat@marcos:/media/anarcat/79884590-6445-4a6f-ae12-050b9a7c1912/mp3 timestamp=1397741440.125973s
+| | -2fec390f-f21b-4293-be50-f219be10ea02 anarcat@marcos:/media/anarcat/Nokia N900/.sounds/mp3-test timestamp=1444709804.587901s
+| |  3f6d8082-6f4b-4faa-a3d9-bd5db1891077 anarcat@lab-sc.no-ip.org:mp3 timestamp=1397882243.602438s
+| | -3f6d8082-6f4b-4faa-a3d9-bd5db1891077 anarcat@serveur-maison:~/mp3 timestamp=1397870776.162703s
+| |  4249a4ea-343a-43a8-9bba-457d2ff87c7d rachel@topcrapn:~/Musique/MUSIC/anarcat timestamp=1398631775.545666s
+| |  487dda55-d164-4bf1-9d85-66caaa9c0743 300GB hard drive labeled VHS timestamp=1397880144.616515s
+| | -509d1cd7-ecd1-4e2f-803d-575d9c56a5bc anarcat@angela:/media/anarcat/Nokia N900/.sounds/mp3 timestamp=1444483581.960103s
+| |  b7802161-c984-4c9f-8d05-787a29c41cfe anarcat@marcos:/srv/mp3 timestamp=1376874943.951103s
+| |  c2ca4a13-9a5f-461b-a44b-53255ed3e2f9 anarcat@desktop008:/srv/musique/anarcat/mp3 timestamp=1410989161.237514s
+| | -c2ca4a13-9a5f-461b-a44b-53255ed3e2f9 anarcat@desktop008:/srv/musique/anarcat/musique/mp3 timestamp=1384884883.106166s
+| | -f641e18f-7cb1-49ba-abe1-7544b435b67f anarcat@marcos:/media/anarcat/Nokia N900/.sounds/mp3-init timestamp=1444708760.468268s
+| |  f867da6f-78cb-49be-a0db-d1c8e5f53664 n900 timestamp=1445438785.796624s
+| |  f8818d12-9882-4ca5-bc0f-04e987888a8d anarcat@marcos:/media/anarcat/green_crypt/mp3/ timestamp=1407470841.967597s
+"""]]
+
+So i guess i could manually edit that uuid.log file to restore my metadata, but i'm puzzled as to where my data went or how!
+
+### Workaround
+
+The workaround is to, of course, restore a known sane `uuid.log`:
+
+[[!format sh """
+[1048]anarcat@angela:~128$ git clone -b git-annex mp3 mp3.annex
+Clonage dans 'mp3.annex'...
+fait.
+Extraction des fichiers: 100% (32234/32234), fait.
+[1049]anarcat@angela:~$ cd mp3.annex/
+[1067]anarcat@angela:mp3.annex$ git co dfe1b77 uuid.log
+[1068]anarcat@angela:mp3.annex$ git status
+Sur la branche git-annex
+Votre branche est à jour avec 'origin/git-annex'.
+Modifications qui seront validées :
+  (utilisez "git reset HEAD <fichier>..." pour désindexer)
+
+        modifié :         uuid.log
+
+[1069]anarcat@angela:mp3.annex$ git commit -m"restore broken uuid.log"
+[git-annex 9628f3b] restore broken uuid.log
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+ rewrite uuid.log (100%)
+[1070]anarcat@angela:mp3.annex$ git push
+Décompte des objets: 2, fait.
+Delta compression using up to 2 threads.
+Compression des objets: 100% (2/2), fait.
+Écriture des objets: 100% (2/2), 262 bytes | 0 bytes/s, fait.
+Total 2 (delta 1), reused 0 (delta 0)
+To /home/anarcat/mp3
+   266099a..9628f3b  git-annex -> git-annex
+[1071]anarcat@angela:mp3.annex$ cd -
+/home/anarcat
+[1072]anarcat@angela:~$ git ^C
+[1072]anarcat@angela:~130$ cd -
+/home/anarcat/mp3.annex
+[1072]anarcat@angela:mp3.annex$ cd ../mp3
+[1073]anarcat@angela:mp3$ git annex merge
+merge git-annex ok
+[1074]anarcat@angela:mp3$ git annex info --fast
+repository mode: indirect
+trusted repositories: 4
+        22921df6-ff75-491c-b5d9-5a2aab33a689 -- anarcat@marcos:/media/anarcat/79884590-6445-4a6f-ae12-050b9a7c1912/mp3
+        b7802161-c984-4c9f-8d05-787a29c41cfe -- anarcat@marcos:/srv/mp3 [marcos]
+        c2ca4a13-9a5f-461b-a44b-53255ed3e2f9 -- anarcat@desktop008:/srv/musique/anarcat/mp3 [markov]
+        f8818d12-9882-4ca5-bc0f-04e987888a8d -- anarcat@marcos:/media/anarcat/green_crypt/mp3/
+semitrusted repositories: 8
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        0f9185ea-8462-4230-8cae-462a1ad0df36 -- anarcat@angela:~/mp3 [here]
+        3f6d8082-6f4b-4faa-a3d9-bd5db1891077 -- anarcat@lab-sc.no-ip.org:mp3
+        4249a4ea-343a-43a8-9bba-457d2ff87c7d -- rachel@topcrapn:~/Musique/MUSIC/anarcat
+        487dda55-d164-4bf1-9d85-66caaa9c0743 -- 300GB hard drive labeled VHS [VHS]
+        6f812272-18c8-4346-b68a-f57ae50f657e -- htcones
+        f867da6f-78cb-49be-a0db-d1c8e5f53664 -- n900
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 13.44 gigabytes (+1 megabyte reserved)
+"""]]
+
+But it seems to me there is a weird interaction between transitions and fresh new git repo syncs... that could be fixed...
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! Git-annex works generally well and, even though i often report bugs here, i am still quite happy with it. :) --[[anarcat]]
diff --git a/doc/bugs/remotes_disappeared/comment_1_7b7bfa0b2c9e66edd92c076e5c6ccdd7._comment b/doc/bugs/remotes_disappeared/comment_1_7b7bfa0b2c9e66edd92c076e5c6ccdd7._comment
new file mode 100644
index 0000000000..8252020d35
--- /dev/null
+++ b/doc/bugs/remotes_disappeared/comment_1_7b7bfa0b2c9e66edd92c076e5c6ccdd7._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-04T19:45:03Z"
+ content="""
+I see that you're using `reinit` .. so are you sure that the UUID you
+reused there or at some other time did not belong to a remote that had
+previously been marked dead? 
+
+I mean, reusing UUIDs of dead remotes (or just generally reusing UUIDS at
+all) seems like the most obvious way to shoot yourself in the foot and get
+into something resembling this sitation.
+
+Your transcript seems to show one git-annex info in the ~/mp3 repository
+listing the remotes, and a subsquent git-annex info in the ~/mp3 repository
+not listing the remotes, with no commands in between that touch that
+repository in any way. This makes me suspect something is being left out
+somehow. Are you using the assistant or something?
+
+You can see which remotes have been marked dead by `git show git-annex:trust.log | grep X`
+"""]]
diff --git a/doc/bugs/remotes_disappeared/comment_2_b9dae978aeeee5e5d246192fed813b3f._comment b/doc/bugs/remotes_disappeared/comment_2_b9dae978aeeee5e5d246192fed813b3f._comment
new file mode 100644
index 0000000000..2edc1a852a
--- /dev/null
+++ b/doc/bugs/remotes_disappeared/comment_2_b9dae978aeeee5e5d246192fed813b3f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-04-04T19:56:42Z"
+ content="""
+I see no ecidence of a file being damanged. I see evidence of the
+dead remote removal code removing dead remotes from uuid.log, which
+is what it's supposed to do, if enabled by 
+`git annex forget --drop-dead` having been run at some point.
+
+Based on the number of transitions listed in the commit message,
+you've run it repeatedly, even.
+"""]]
diff --git a/doc/bugs/remotes_disappeared/comment_3_794372fb37621f37478313abc4ee92cf._comment b/doc/bugs/remotes_disappeared/comment_3_794372fb37621f37478313abc4ee92cf._comment
new file mode 100644
index 0000000000..2fa413cc02
--- /dev/null
+++ b/doc/bugs/remotes_disappeared/comment_3_794372fb37621f37478313abc4ee92cf._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""comment 3"""
+ date="2016-04-04T20:39:24Z"
+ content="""
+No trust information was ever assigned to that remote:
+
+    [1012]anarcat@angela:mp31$ git show git-annex:trust.log | grep 6f812272-18c8-4346-b68a-f57ae50f657e
+    [1013]anarcat@angela:mp31$ git log -p  git-annex -- trust.log | grep 6f812272-18c8-4346-b68a-f57ae50f657e
+    [1014]anarcat@angela:mp31$
+
+None of the repositories removed from the `git annex info` display
+were ever marked as dead, in fact, two of those were marked as
+`trusted`, from what I can see here:
+
+    [1018]anarcat@angela:mp31$ for repo in 22921df6-ff75-491c-b5d9-5a2aab33a689 f8818d12-9882-4ca5-bc0f-04e987888a8d 3f6d8082-6f4b-4faa-a3d9-bd5db1891077 4249a4ea-343a-43a8-9bba-457d2ff87c7d f867da6f-78cb-49be-a0db-d1c8e5f53664 ; do
+    >  git log -p  git-annex -- trust.log | grep $repo
+    > done
+     22921df6-ff75-491c-b5d9-5a2aab33a689 1 timestamp=1400247400.46351s
+    +22921df6-ff75-491c-b5d9-5a2aab33a689 1 timestamp=1400247400.46351s
+     f8818d12-9882-4ca5-bc0f-04e987888a8d 1 timestamp=1424140026.947448s
+     f8818d12-9882-4ca5-bc0f-04e987888a8d 1 timestamp=1424140026.947448s
+    +f8818d12-9882-4ca5-bc0f-04e987888a8d 1 timestamp=1424140026.947448s
+
+And yes, I did run a transition a while back. I don't remember if I
+ran it multiple times: this is one of my first git-annex repos, so a
+lot of stuff may have happened to it its 3 years of existence:
+
+    $ git log  | tail -5
+    commit 2400a4b46bc2b1a015e6881ef0c331c519016b64
+    Author: Antoine Beaupré <anarcat@koumbit.org>
+    Date:   Sun Aug 18 22:14:47 2013 -0400
+    
+        enter git annex
+
+It seems to me that the transition mechanism *may* be triggered before
+the `uuid.log` or `trust.log` files be fully merged - is that possible?
+"""]]
diff --git a/doc/bugs/repair_on_Windows_reports_ambiguous_argument_error.mdwn b/doc/bugs/repair_on_Windows_reports_ambiguous_argument_error.mdwn
new file mode 100644
index 0000000000..fb4c594f46
--- /dev/null
+++ b/doc/bugs/repair_on_Windows_reports_ambiguous_argument_error.mdwn
@@ -0,0 +1,77 @@
+### Please describe the problem.
+
+On Windows only the git annex repair command reports an error.
+
+### What steps will reproduce the problem?
+
+Following are the minimum steps to reproduce the problem. The problem occurs with any number of files in the repository. The --force option does not correct the problem. The problem does not occur on Linux or macOS.
+
+[[!format sh """
+mkdir repair-ambiguous-argument-bug
+pushd repair-ambiguous-argument-bug
+git init
+git annex init
+git annex repair
+popd
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20230330-g98a3ba0ea5
+
+git version 2.40.0.windows.1
+
+Microsoft Windows [Version 10.0.19045.2846]
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+repair Running git fsck ...
+Fsck found no problems. Checking for broken branches.
+fatal: ambiguous argument 'refs\heads\master': unknown revision or path not in the working tree.
+Use '--' to separate paths from revisions, like this:
+'git <command> [<revision>...] -- [<file>...]'
+fatal: ambiguous argument 'refs\heads\git-annex': unknown revision or path not in the working tree.
+Use '--' to separate paths from revisions, like this:
+'git <command> [<revision>...] -- [<file>...]'
+fatal: ambiguous argument 'refs\heads\adjusted\master(unlocked)': unknown revision or path not in the working tree.
+Use '--' to separate paths from revisions, like this:
+'git <command> [<revision>...] -- [<file>...]'
+fatal: ambiguous argument 'refs\basis\adjusted\master(unlocked)': unknown revision or path not in the working tree.
+Use '--' to separate paths from revisions, like this:
+'git <command> [<revision>...] -- [<file>...]'
+Found problems, attempting repair.
+fatal: ambiguous argument 'refs\heads\master': unknown revision or path not in the working tree.
+Use '--' to separate paths from revisions, like this:
+'git <command> [<revision>...] -- [<file>...]'
+fatal: ambiguous argument 'refs\heads\git-annex': unknown revision or path not in the working tree.
+Use '--' to separate paths from revisions, like this:
+'git <command> [<revision>...] -- [<file>...]'
+fatal: ambiguous argument 'refs\heads\adjusted\master(unlocked)': unknown revision or path not in the working tree.
+Use '--' to separate paths from revisions, like this:
+'git <command> [<revision>...] -- [<file>...]'
+fatal: ambiguous argument 'refs\basis\adjusted\master(unlocked)': unknown revision or path not in the working tree.
+Use '--' to separate paths from revisions, like this:
+'git <command> [<revision>...] -- [<file>...]'
+Some git branches refer to missing objects:
+        refs\heads\master
+        refs\heads\git-annex
+        refs\heads\adjusted\master(unlocked)
+        refs\basis\adjusted\master(unlocked)
+To force a recovery to a usable state, retry with the --force parameter.
+failed
+repair: 1 failed
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes. I am developing the easy-git-annex API for git-annex.
+
+> Should be [[fixed|done]] now... It was reading the contents of the refs/
+> directory recursively, and treating those names as refs, which is wrong
+> on Windows due to path separator being different. --[[Joey]]
diff --git a/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist.mdwn b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist.mdwn
new file mode 100644
index 0000000000..6033e01e84
--- /dev/null
+++ b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist.mdwn
@@ -0,0 +1,171 @@
+### Please describe the problem.
+
+Causing a file conflict with an unlocked empty file in the repository results in resolvemerge failing.
+
+This can be quirky at times when a resolvemerge unexpectedly fails due to some program inconspicuously creating an empty file, since the repositories I regularly work with have annex.addunlocked set to true.
+
+### What steps will reproduce the problem?
+
+1. With two repositories,
+2. Add an empty file to one repository.
+3. Sync repositories.
+4. Unlock the empty file.
+5. Sync repositories.
+6. Add a file to both repositories with the same name but different contents.
+7. Sync repositories, expecting resolvemerge to automatically fix the conflict, but see it fail instead.
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20230321
+build flags: Assistant Webapp Pairing Inotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.23 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.2.5 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+"""]]
+
+Running git-annex on Fedora 37, with git-annex installed via Guix.
+
+### Please provide any additional information below.
+
+<details>
+<summary>The following script reliably produces the issue on my end:</summary>
+
+[[!format bash """
+# [1] Set up two connected repositories
+create-repo () {
+    git init "$1"
+    cd "$1"
+    git-annex init "$1"
+    cd -
+}
+create-repo repo1
+create-repo repo2
+cd repo1
+git remote add repo2 ../repo2
+cd ../repo2
+git remote add repo1 ../repo1
+cd ..
+
+# [2-5] Syncing unlocked empty file seems fine
+cd repo1
+touch emptyfile
+git-annex add
+git-annex unlock
+git-annex sync --content
+# Syncing other repository succeeds, albeit with an odd error message
+# (probably unrelated since it happens without an emptyfile; different bug?)
+cd ../repo2
+git-annex sync --content
+cd ..
+
+# [6-7] Causing a resolvemerge at this point results in the operation failing
+cd repo2
+echo repo2 line > testfile
+git-annex add
+git-annex sync --content
+cd ../repo1
+echo repo1 line > testfile
+git-annex add
+# Error here
+git-annex sync --content
+
+# resolvemerge works again once emptyfile is locked
+git-annex lock
+git-annex sync --content
+"""]]
+</details>
+
+<details>
+<summary>The `git-annex sync --content` command marked with "Error here" in the script produces the following output:</summary>
+
+[[!format sh """
+commit 
+[master 5c0fd88] git-annex in repo1
+ 1 file changed, 1 insertion(+)
+ create mode 120000 testfile
+ok
+merge synced/master 
+fatal: stash failed
+failed
+pull repo2 
+From ../repo2
+   a951533..20ed66d  git-annex     -> repo2/git-annex
+ * [new branch]      master        -> repo2/master
+   560d494..69204c4  synced/master -> repo2/synced/master
+
+fatal: stash failed
+
+fatal: stash failed
+failed
+copy testfile (to repo2...) 
+(checksum...) ok
+pull repo2 
+
+fatal: stash failed
+
+fatal: stash failed
+failed
+(recording state in git...)
+push repo2 
+Enumerating objects: 23, done.
+Counting objects: 100% (23/23), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (15/15), done.
+Writing objects: 100% (18/18), 1.65 KiB | 1.65 MiB/s, done.
+Total 18 (delta 4), reused 0 (delta 0), pack-reused 0
+To ../repo2
+   a951533..34ec971  git-annex -> synced/git-annex
+ ! [rejected]        master -> synced/master (non-fast-forward)
+error: failed to push some refs to '../repo2'
+hint: Updates were rejected because a pushed branch tip is behind its remote
+hint: counterpart. Check out this branch and integrate the remote changes
+hint: (e.g. 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+To ../repo2
+ ! [rejected]        master -> master (non-fast-forward)
+error: failed to push some refs to '../repo2'
+hint: Updates were rejected because the tip of your current branch is behind
+hint: its remote counterpart. Integrate the remote changes (e.g.
+hint: 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+
+  Pushing to repo2 failed.
+failed
+sync: 4 failed
+"""]]
+</details>
+
+Curiously, I only managed to stumble on this using magit with Emacs on my repository.
+
+`git status` and `git-annex status` don't output any changes, but for some reason magit reports that there are unstaged changes to remove the empty file symlinks.
+
+<details>
+<summary>For example, this is what magit shows before [6-7] in the script:</summary>
+
+[[!format diff """
+Head:     master git-annex in repo1
+
+Unstaged changes (1)
+modified   emptyfile
+@@ -1 +0,0 @@
+-/annex/objects/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+
+Recent commits
+eac97cf master synced/master repo2/synced/master git-annex in repo1
+"""]]
+</details>
+
+[[This other bug report|bugs/Empty_files_make_git_status_slow]] mentions a different problem but also caused by empty unlocked files; might be related?
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I have been incorporating git-annex into my backup system for the past year now, and it has been absolutely wonderful to work with.
+
+> Since this is a git bug, and since I don't think there's a reasonable
+> workaround in git-annex, I'm closing this as forwarded to git. [[done]]
+> --[[Joey]]
diff --git a/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_1_66ff5ff20c4a1561943f8fc144a4dfb5._comment b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_1_66ff5ff20c4a1561943f8fc144a4dfb5._comment
new file mode 100644
index 0000000000..2a9b666993
--- /dev/null
+++ b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_1_66ff5ff20c4a1561943f8fc144a4dfb5._comment
@@ -0,0 +1,70 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-05-01T19:50:46Z"
+ content="""
+I was able to reproduce the problem using the script.
+
+This does not actually involve resolvemerge at all AFAICS. The pull does
+not result in the repo getting into a conflicted state, because
+`git merge` is failing before that point.
+
+	joey@darkstar:~/tmp/c/repo1>git --git-dir=.git --work-tree=. -c merge.directoryRenames=false --literal-pathspecs merge --no-edit refs/remotes/repo2/master
+	fatal: stash failed
+
+Strange error message... That seems like it could be a bug in git.
+Certianly an unusual code path in it.
+
+If I disable filter.annex.process and filter.annex.clean, the merge
+"succeeds":
+
+	error: Merging is not possible because you have unmerged files.
+	hint: Fix them up in the work tree, and then use 'git add/rm <file>'
+	hint: as appropriate to mark resolution and make a commit.
+	fatal: Exiting because of an unresolved conflict.
+
+I see that it's asking git-annex to clean emptyfile:
+
+	joey@darkstar:~/tmp/c/repo1>GIT_TRACE=1 git --git-dir=.git --work-tree=. -c merge.directoryRenames=false --literal-pathspecs merge --no-edit refs/remotes/repo2/master
+	16:36:51.406445 git.c:439               trace: built-in: git merge --no-edit refs/remotes/repo2/master
+	16:36:51.409519 run-command.c:655       trace: run_command: 'git-annex smudge --clean -- '\''emptyfile'\'''
+	16:36:51.427425 git.c:439               trace: built-in: git config --null --list
+	16:36:51.432485 git.c:439               trace: built-in: git cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)'
+	16:36:51.435775 git.c:439               trace: built-in: git cat-file --batch
+	16:36:51.444646 git.c:439               trace: built-in: git show-ref --hash refs/annex/last-index
+	16:36:51.461672 run-command.c:655       trace: run_command: git stash create
+	16:36:51.464416 git.c:439               trace: built-in: git stash create
+	16:36:51.465753 run-command.c:655       trace: run_command: 'git-annex smudge --clean -- '\''emptyfile'\'''
+	16:36:51.475280 git.c:439               trace: built-in: git config --null --list
+	16:36:51.480984 git.c:439               trace: built-in: git cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)'
+	16:36:51.484934 git.c:439               trace: built-in: git cat-file --batch
+	16:36:51.493965 git.c:439               trace: built-in: git show-ref --hash refs/annex/last-index
+	16:36:51.498182 git.c:439               trace: built-in: git cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)' --buffer
+	16:36:51.499385 git.c:439               trace: built-in: git cat-file '--batch=%(objectname) %(objecttype) %(objectsize)' --buffer
+	16:36:51.500025 git.c:439               trace: built-in: git diff 06f9e23961782cde731bc7ed3e9fb16a930398e1 --staged --raw -z --no-abbrev -G/annex/objects/ --no-renames --ignore-submodules=all --no-textconv --no-ext-diff
+	fatal: stash failed
+
+Since it asks git-annex to clean emptyfile twice, I'm guessing that it's
+cleaning two different versions of the file. Perhaps for the locked and the
+unlocked versions? (But the locked version is a symlink, so why would it
+clean it?)
+
+I instrumented `git-annex smudge --clean` to see what git is feeding it on
+stdin. In both calls shown above, git-annex is fed "". That seems odd,
+I'd have expected at least one of them to be an annex pointer file.
+
+At this point, my suspicion is that git is cleaning at least one
+emptyfile version that is not the one in the working tree. But
+`git-annex smudge --clean` assumes it's always being used to clean
+the one in the working tree. And it has various behaviors based on
+that assumption (which is necessary for good performance). So it may
+be outputting something that git is not prepared for somehow,
+which is causing git merge to fail in this unusual way. But,
+it does not really seem right to me that any output from the clean
+filter should cause git merge to fail like this. Still thinking
+it might be a git bug, or a combination of bugs.
+
+Also, this does only happen when emptyfile is in fact empty.
+Which is interesting... that should not affect the behavior
+of `git-annex smudge --clean` at all.
+"""]]
diff --git a/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_2_28e204f5db91eaa258428d89cbb9f6c9._comment b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_2_28e204f5db91eaa258428d89cbb9f6c9._comment
new file mode 100644
index 0000000000..851ad4c39d
--- /dev/null
+++ b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_2_28e204f5db91eaa258428d89cbb9f6c9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-05-01T21:08:48Z"
+ content="""
+I think what needs to be done here is write a simple smudge
+filter script that mocks `git-annex smuge --clean`, and see if the problem can be
+reproduced with that. That should pin down what about the behavior of that
+might be triggering what problem in git.
+"""]]
diff --git a/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_3_68ddf1256149eec1ac01fb915d26bac3._comment b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_3_68ddf1256149eec1ac01fb915d26bac3._comment
new file mode 100644
index 0000000000..fb599f3010
--- /dev/null
+++ b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_3_68ddf1256149eec1ac01fb915d26bac3._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-05-02T16:44:03Z"
+ content="""
+Here's a simplified test case that does not use `git-annex sync` but still
+uses git-annex.
+
+	#!/bin/sh
+	git init repo1
+	cd repo1
+	git-annex init
+	git commit --allow-empty -m foo
+	git remote add repo2 ../repo2
+	cd ..
+	git clone repo1 repo2
+	cd repo2
+	git remote add repo1 ../repo1
+	cd ..
+	cd repo1
+	touch emptyfile
+	git-annex add
+	git-annex unlock
+	git commit -m add
+	cd ../repo2
+	git pull
+	echo repo2 line > testfile
+	git-annex add
+	git commit -m add
+	cd ../repo1
+	echo repo1 line > testfile
+	git-annex add
+	git commit -m foo
+	git pull repo2 master
+"""]]
diff --git a/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_4_785200bbdc9efabed141ecd51cb015a4._comment b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_4_785200bbdc9efabed141ecd51cb015a4._comment
new file mode 100644
index 0000000000..afc2c2f61c
--- /dev/null
+++ b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_4_785200bbdc9efabed141ecd51cb015a4._comment
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-05-02T16:56:12Z"
+ content="""
+This is a git bug. The test case below does not use git-annex, but causes the
+same merge problem.
+
+I've reported the bug to the git developers 
+<https://lore.kernel.org/git/ZFFGi9i7JGL9xNx5@kitenet.net/T/#u>
+
+	#!/bin/bash
+	setup_smudge_clean() {
+		cat <<'EOF' > .git/test-clean
+	#!/bin/sh
+	mkdir -p ../content
+	cat > ../content/new.content
+	v=$(sha1sum ../content/new.content | cut -d ' ' -f 1)
+	mv ../content/new.content ../content/$v.content
+	echo "$v"
+	EOF
+		cat <<'EOF' > .git/test-smudge
+	#!/bin/sh
+	v=$(cat)
+	cat ../content/$v.content
+	EOF
+		chmod +x .git/test-clean
+		chmod +x .git/test-smudge
+		git config filter.foo.smudge .git/test-smudge
+		git config filter.foo.clean .git/test-clean
+		echo "* filter=foo" > .git/info/attributes
+	}
+	
+	git init repo1
+	cd repo1
+	setup_smudge_clean
+	git commit --allow-empty -m foo
+	git remote add repo2 ../repo2
+	cd ..
+	git clone repo1 repo2
+	cd repo2
+	git remote add repo1 ../repo1
+	setup_smudge_clean
+	cd ..
+	
+	cd repo1
+	touch emptyfile
+	git add emptyfile
+	git commit -m add
+	cd ../repo2
+	git pull
+	
+	echo foo > testfile
+	git add testfile
+	git commit -m foo
+	cd ../repo1
+	echo bar > testfile
+	git add testfile
+	git commit -m bar
+	git pull repo2 master
+"""]]
diff --git a/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_5_3b5f7c44de6b17e042adaa77a8bed2f8._comment b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_5_3b5f7c44de6b17e042adaa77a8bed2f8._comment
new file mode 100644
index 0000000000..f4604748ab
--- /dev/null
+++ b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_5_3b5f7c44de6b17e042adaa77a8bed2f8._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="aurelien@f0d0a0c7da69eff6badf0464898f0a859f69114d"
+ nickname="aurelien"
+ avatar="http://cdn.libravatar.org/avatar/2cbf28821cf4b36380554c22f0b8b809"
+ subject="comment 5"
+ date="2024-01-14T23:18:43Z"
+ content="""
+I think I have been hit by this bug as well with getting \"fatal: stash failed\" after importing some files and trying to sync.
+
+Indeed, temporarily deactivating filter.annex.process and filter.annex.clean allowed to sync. 
+
+And the problem didn't reappear after so far. 
+Is there a reliable workaround (the bug report seem to have no responses?). 
+
+git version 2.43.0
+git-annex version: 10.20230926-g4ac2758ba589562e427a66437b9fdcd5172357e1
+"""]]
diff --git a/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_6_baa4f1e895ff351b16f54d59851d2a6f._comment b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_6_baa4f1e895ff351b16f54d59851d2a6f._comment
new file mode 100644
index 0000000000..f31a66c28f
--- /dev/null
+++ b/doc/bugs/resolvemerge_fails_when_unlocked_empty_files_exist/comment_6_baa4f1e895ff351b16f54d59851d2a6f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2024-01-18T17:13:40Z"
+ content="""
+Unfortunately I never heard back from the git developers about the bug.
+"""]]
diff --git a/doc/bugs/rsync__58___protocol_version_mismatch.mdwn b/doc/bugs/rsync__58___protocol_version_mismatch.mdwn
new file mode 100644
index 0000000000..fb5500601a
--- /dev/null
+++ b/doc/bugs/rsync__58___protocol_version_mismatch.mdwn
@@ -0,0 +1,38 @@
+### Please describe the problem.
+This is a weird one. I'm getting rsync `protocol version mismatch -- is your shell clean?` on a particular file.
+
+I have tried to reproduce it but not been able.
+
+ * First time it happened, I went to the problem repo and did a `get`, which worked, destroying the evidence. "Luckily", this happened again a few days later.
+ * I thought maybe it was because there was a partial transfer in `.git/annex/tmp` with some specific characteristics. Nope, if I remove the file in `tmp` the problem remains.
+ * I made another clone think it was the problem repo, transferred the file to that repo, no problem. Dropped it, pointed everything back to the original bad repo. Still bad.
+ * Both sides are running `rsync  version 3.1.0  protocol version 31`.
+
+
+### What steps will reproduce the problem?
+
+Working on it. But I want to put the preliminaries here, in case someone else has seen this.
+
+### What version of git-annex are you using? On what operating system?
+
+Both sides are running `git-annex version: 5.20150508-g883d57f`, on Ubuntu 14.04.2 LTS.
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+$ git annex copy --to acozed claes/colt/20150511_174818.jpg 
+copy claes/colt/20150511_174818.jpg (checking acozed...) (to acozed...) 
+protocol version mismatch -- is your shell clean?
+(see the rsync man page for an explanation)
+rsync error: protocol incompatibility (code 2) at compat.c(176) [sender=3.1.1]
+
+  rsync failed -- run git annex again to resume file transfer
+failed
+git-annex: copy: 1 failed
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/rsync__58___protocol_version_mismatch/comment_1_672d89a7d06d5ec336381b670a41a9c7._comment b/doc/bugs/rsync__58___protocol_version_mismatch/comment_1_672d89a7d06d5ec336381b670a41a9c7._comment
new file mode 100644
index 0000000000..8379a7d826
--- /dev/null
+++ b/doc/bugs/rsync__58___protocol_version_mismatch/comment_1_672d89a7d06d5ec336381b670a41a9c7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-22T19:12:37Z"
+ content="""
+I think I've seen this where the shell was running some command
+at (non-interactive) login that output stuff and so screwed up the rsync
+protocol.
+
+rsync with sufficient -vvvv will print out a lot of debugging info about
+the protocol.
+"""]]
diff --git a/doc/bugs/rsync__58___protocol_version_mismatch/comment_2_531b85c911d390b1b93ee55a8cf5d47e._comment b/doc/bugs/rsync__58___protocol_version_mismatch/comment_2_531b85c911d390b1b93ee55a8cf5d47e._comment
new file mode 100644
index 0000000000..268f369936
--- /dev/null
+++ b/doc/bugs/rsync__58___protocol_version_mismatch/comment_2_531b85c911d390b1b93ee55a8cf5d47e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="clacke"
+ subject="comment 2"
+ date="2015-05-22T21:08:26Z"
+ content="""
+It's weirder than that. I add a cow union mount over it, it works fine.
+
+I copy the file, I drop the file, I remove the union mount. Again it's back in the broken state. Rebooting does not help, so it's not some very insistent lock.
+
+Next I will try a copy of the repo, to see if that is able to carry over whatever strange state this thing is in.
+"""]]
diff --git a/doc/bugs/rsync__58___protocol_version_mismatch/comment_3_eff8f33134157635387ee681805ff7a8._comment b/doc/bugs/rsync__58___protocol_version_mismatch/comment_3_eff8f33134157635387ee681805ff7a8._comment
new file mode 100644
index 0000000000..b2a335a0bc
--- /dev/null
+++ b/doc/bugs/rsync__58___protocol_version_mismatch/comment_3_eff8f33134157635387ee681805ff7a8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="clacke"
+ subject="comment 3"
+ date="2015-05-22T22:16:45Z"
+ content="""
+Note that a thousand files went over without a hitch, but this particular file consistently fails.
+"""]]
diff --git a/doc/bugs/rsync__58___protocol_version_mismatch/comment_4_77e59a25c859b6afec8b75f74885ef5e._comment b/doc/bugs/rsync__58___protocol_version_mismatch/comment_4_77e59a25c859b6afec8b75f74885ef5e._comment
new file mode 100644
index 0000000000..cad761d149
--- /dev/null
+++ b/doc/bugs/rsync__58___protocol_version_mismatch/comment_4_77e59a25c859b6afec8b75f74885ef5e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="clacke"
+ subject="comment 4"
+ date="2015-05-24T17:41:17Z"
+ content="""
+Hm, not so sure that \"rebooted, did not help\" was actually true. I take that back.
+
+Now I saw a stray `git-annex-shell recv-key` process mentioning that file. I killed it and now everything seems fine. I will keep this in mind for next time, to see if I can verify that this was actually the cause of the message, but maybe it's a clue.
+"""]]
diff --git a/doc/bugs/rsync__58___protocol_version_mismatch/comment_5_7d819c3e4af2b8044a52fa6131f36187._comment b/doc/bugs/rsync__58___protocol_version_mismatch/comment_5_7d819c3e4af2b8044a52fa6131f36187._comment
new file mode 100644
index 0000000000..85af7d2215
--- /dev/null
+++ b/doc/bugs/rsync__58___protocol_version_mismatch/comment_5_7d819c3e4af2b8044a52fa6131f36187._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-05-26T14:52:11Z"
+ content="""
+The stray recv-key is a good clue. git-annex-shell only allows one upload
+of a given file to run at a time. So if you get a transfer stalled out,
+it will reject another transfer attempt. This can sometimes happen when eg,
+migrating between networks and restarting an upload when the old one is
+still running on the server.
+
+However, normally there is an error message "transfer already in progress".
+
+It may be that your rsync is not forwarding that stderr through to display
+it, for some reason.
+
+It would probably help if you can run the same git-annex shell command line
+on the server, verify that it fails with "transfer already in progress"
+when an recvkey of that key is already running. Then you could try sshing
+to the server noninteractively and having it run the same git-annex-shell
+command, and see if the error makes it through that.
+"""]]
diff --git a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_.mdwn b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_.mdwn
new file mode 100644
index 0000000000..09c79d78dd
--- /dev/null
+++ b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_.mdwn
@@ -0,0 +1,85 @@
+### Please describe the problem.
+
+i tried to sync my home music annex to a server. Half the files worked nicely, but on the rest it fails with rsync errors.
+
+### What steps will reproduce the problem?
+
+git annex -d sync --content
+
+### What version of git-annex are you using? On what operating system?
+
+Client:
+
+ubuntu trusty
+Version: 5.20140517.4
+
+Server:
+
+ubuntu trusty
+Version: 5.20140412ubuntu1
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+dirus-dom:/music$ git annex -d sync --content
+[2014-10-28 19:18:28 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","show-ref","git-annex"]
+[2014-10-28 19:18:28 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","show-ref","--hash","refs/heads/git-annex"]
+[2014-10-28 19:18:29 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","log","refs/heads/git-annex..1599d29eba7a0ec50217c2b4a3f4cc1ecc8b2116","--oneline","-n1"]
+[2014-10-28 19:18:29 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","log","refs/heads/git-annex..27b47301dcb5007705d1dcd5a414df964b840467","--oneline","-n1"]
+[2014-10-28 19:18:29 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","log","refs/heads/git-annex..a95ca0282fefcd774ec8a00b6f33c11f08f789d8","--oneline","-n1"]
+[2014-10-28 19:18:29 CET] chat: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","cat-file","--batch"]
+commit  [2014-10-28 19:18:29 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","commit","-a","-m","git-annex automatic sync"]
+ok
+[2014-10-28 19:18:31 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","symbolic-ref","HEAD"]
+[2014-10-28 19:18:31 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","show-ref","refs/heads/master"]
+[2014-10-28 19:18:31 CET] call: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","show-ref","--verify","-q","refs/heads/synced/master"]
+[2014-10-28 19:18:31 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","log","refs/heads/master..refs/heads/synced/master","--oneline","-n1"]
+pull sync.poelzi.org__music
+[2014-10-28 19:18:31 CET] read: ssh ["-O","stop","-S","poelzigit@sync.poelzi.org","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
+[2014-10-28 19:18:31 CET] call: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","fetch","sync.poelzi.org__music"]
+[2014-10-28 19:18:33 CET] call: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","show-ref","--verify","-q","refs/remotes/sync.poelzi.org__music/master"]
+[2014-10-28 19:18:33 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","log","refs/heads/master..refs/remotes/sync.poelzi.org__music/master","--oneline","-n1"]
+[2014-10-28 19:18:33 CET] call: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","show-ref","--verify","-q","refs/remotes/sync.poelzi.org__music/synced/master"]
+[2014-10-28 19:18:33 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","log","refs/heads/synced/master..refs/remotes/sync.poelzi.org__music/synced/master","--oneline","-n1"]
+ok
+[2014-10-28 19:18:33 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","show-ref","git-annex"]
+[2014-10-28 19:18:33 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","show-ref","--hash","refs/heads/git-annex"]
+[2014-10-28 19:18:33 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","log","refs/heads/git-annex..1599d29eba7a0ec50217c2b4a3f4cc1ecc8b2116","--oneline","-n1"]
+[2014-10-28 19:18:33 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","log","refs/heads/git-annex..27b47301dcb5007705d1dcd5a414df964b840467","--oneline","-n1"]
+[2014-10-28 19:18:33 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","log","refs/heads/git-annex..a95ca0282fefcd774ec8a00b6f33c11f08f789d8","--oneline","-n1"]
+[2014-10-28 19:18:33 CET] read: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","ls-files","--cached","-z","--"]
+[2014-10-28 19:18:33 CET] chat: git ["--git-dir=/exports/music/.git","--work-tree=/exports/music","check-attr","-z","--stdin","annex.backend","annex.numcopies","--"]
+copy Alan Parsons Project/Eye In The Sky/.07 - Psychobabble.mood copy Alan Parsons Project/Eye In The Sky/.07 - Psychobabble.mood (checking sync.poelzi.org__music...) [2014-10-28 19:18:43 CET] call: ssh ["-S",".git/annex/ssh/poelzigit@sync.poelzi.org","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","poelzigit@sync.poelzi.org","git-annex-shell 'inannex' '/music/' 'SHA256E-s3000--da8a3336a484a171a438c99660260cc35cbd37c339dd2c18447cd025064bc00b.mood' --uuid 35a89672-4ff5-4d9a-9bf2-cedb272bb7cb"]
+(to sync.poelzi.org__music...)
+[2014-10-28 19:18:43 CET] read: rsync ["--progress","--inplace","--perms","-e","'ssh' '-S' '.git/annex/ssh/poelzigit@sync.poelzi.org' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'poelzigit@sync.poelzi.org' 'git-annex-shell ''recvkey'' ''/music/'' ''SHA256E-s3000--da8a3336a484a171a438c99660260cc35cbd37c339dd2c18447cd025064bc00b.mood'' --uuid 35a89672-4ff5-4d9a-9bf2-cedb272bb7cb ''--'' ''remoteuuid=97a3cd71-ee6c-4437-8740-253cde0d32ae'' ''direct='' ''associatedfile=Alan Parsons Project/Eye In The Sky/.07 - Psychobabble.mood'' ''--'''","--","/exports/music/.git/annex/objects/20/Z4/SHA256E-s3000--da8a3336a484a171a438c99660260cc35cbd37c339dd2c18447cd025064bc00b.mood/SHA256E-s3000--da8a3336a484a171a438c99660260cc35cbd37c339dd2c18447cd025064bc00b.mood","dummy:"]
+rsync error: syntax or usage error (code 1) at main.c(1183) [sender=3.1.1]
+
+  rsync failed -- run git annex again to resume file transfer
+failed
+copy Alessandro Scarlatti/Motets - Gérard Lesne, Veronique Gens (1993) [300]/06 - Infirmata, Vulnerata - VI Semper Gratus.ogg copy Alessandro Scarlatti/Motets - Gérard Lesne, Veronique Gens (1993) [300]/06 - Infirmata, Vulnerata - VI Semper Gratus.ogg (checking sync.poelzi.org__music...) [2014-10-28 19:18:48 CET] call: ssh ["-S",".git/annex/ssh/poelzigit@sync.poelzi.org","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","poelzigit@sync.poelzi.org","git-annex-shell 'inannex' '/music/' 'SHA256E-s3847396--05c5498f08c727645ba84270cb8d82da69a3c9bede35520aa3128b938d003a3d.ogg' --uuid 35a89672-4ff5-4d9a-9bf2-cedb272bb7cb"]
+(to sync.poelzi.org__music...)
+[2014-10-28 19:18:48 CET] read: rsync ["--progress","--inplace","--perms","-e","'ssh' '-S' '.git/annex/ssh/poelzigit@sync.poelzi.org' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'poelzigit@sync.poelzi.org' 'git-annex-shell ''recvkey'' ''/music/'' ''SHA256E-s3847396--05c5498f08c727645ba84270cb8d82da69a3c9bede35520aa3128b938d003a3d.ogg'' --uuid 35a89672-4ff5-4d9a-9bf2-cedb272bb7cb ''--'' ''remoteuuid=97a3cd71-ee6c-4437-8740-253cde0d32ae'' ''direct='' ''associatedfile=Alessandro Scarlatti/Motets - G\233rard Lesne, Veronique Gens (1993) [300]/06 - Infirmata, Vulnerata - VI Semper Gratus.ogg'' ''--'''","--","/exports/music/.git/annex/objects/XJ/f9/SHA256E-s3847396--05c5498f08c727645ba84270cb8d82da69a3c9bede35520aa3128b938d003a3d.ogg/SHA256E-s3847396--05c5498f08c727645ba84270cb8d82da69a3c9bede35520aa3128b938d003a3d.ogg","dummy:"]
+rsync error: syntax or usage error (code 1) at main.c(1183) [sender=3.1.1]
+
+  rsync failed -- run git annex again to resume file transfer
+failed
+^C
+
+
+Calling this through python gives:
+
+In [5]: subprocess.call(["rsync", "--debug=all", "--progress","--inplace","--perms","-e","'ssh' '-S' '.git/annex/ssh/poelzigit@sync.poelzi.org' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'poelzigit@sync.poelzi.org' 'git-annex-shell ''recvkey'' ''/music/'' ''SHA256E-s3000--da8a3336a484a171a438c99660260cc35cbd37c339dd2c18447cd025064bc00b.mood'' --uuid 35a89672-4ff5-4d9a-9bf2-cedb272bb7cb ''--'' ''remoteuuid=97a3cd71-ee6c-4437-8740-253cde0d32ae'' ''direct='' ''associatedfile=Alan Parsons Project/Eye In The Sky/.07 - Psychobabble.mood'' ''--'''","--","/exports/music/.git/annex/objects/20/Z4/SHA256E-s3000--da8a3336a484a171a438c99660260cc35cbd37c339dd2c18447cd025064bc00b.mood/SHA256E-s3000--da8a3336a484a171a438c99660260cc35cbd37c339dd2c18447cd025064bc00b.mood","dummy:"])
+opening connection using: ssh -S .git/annex/ssh/poelzigit@sync.poelzi.org -o ControlMaster=auto -o ControlPersist=yes -T poelzigit@sync.poelzi.org "git-annex-shell 'recvkey' '/music/' 'SHA256E-s3000--da8a3336a484a171a438c99660260cc35cbd37c339dd2c18447cd025064bc00b.mood' --uuid 35a89672-4ff5-4d9a-9bf2-cedb272bb7cb '--' 'remoteuuid=97a3cd71-ee6c-4437-8740-253cde0d32ae' 'direct=' 'associatedfile=Alan Parsons Project/Eye In The Sky/.07 - Psychobabble.mood' '--'" dummy rsync --server -pe.Lsfx --log-format=X --debug=ALL --inplace . .  (19 args)
+(Client) Protocol versions: remote=31, negotiated=31
+[sender] change_dir(/exports/music/.git/annex/objects/20/Z4/SHA256E-s3000--da8a3336a484a171a438c99660260cc35cbd37c339dd2c18447cd025064bc00b.mood)
+send_files starting
+send_files phase=1
+send_files phase=2
+send files finished
+total: matches=0  hash_hits=0  false_alarms=0 data=0
+rsync error: syntax or usage error (code 1) at main.c(1183) [sender=3.1.1]
+[sender] _exit_cleanup(code=1, file=main.c, line=1183): about to call exit(1)
+
+
+"""]]
diff --git a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_/comment_1_464d733de18f6ca438ebd84e88b8cee2._comment b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_/comment_1_464d733de18f6ca438ebd84e88b8cee2._comment
new file mode 100644
index 0000000000..672a3a5600
--- /dev/null
+++ b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_/comment_1_464d733de18f6ca438ebd84e88b8cee2._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-31T20:45:41Z"
+ content="""
+This is a rsync protocol level error; one side is sending something
+that the other side fails to deal with. We can see in your log that the
+two rsync are communicating successfully over the ssh connection
+at first.
+
+This could be something not clean about your ssh connection, or some incompatibility
+in the versions of rsync or git-annex between the client and the server.
+It probably wouldn't hurt to make sure client and server have the same rsync
+version, and perhaps upgrade them both to the newest git-annex in case this
+problem is somehow fixed there.
+
+Then, seems to me that the next step is to get git-annex-shell out of the
+picture and see if you can still reproduce the problem. You can find the rsync
+command that git-annex-shell runs by passing --debug to it. The just replace
+the git-annex-shell command in your python code with the rsync command it runs.
+
+Here's a shell command line I came up with by doing that. It will have
+different paths for your repo, and localhost will need to be changed to your
+server's name.
+
+<pre>
+rsync --progress --inplace --perms --debug=all -e 'ssh  -4 -T localhost "rsync --server -t --inplace -e.Lsf . //home/joey/annex/.git/annex/tmp/SHA256E-s30--bdce956a335681853344fce6f1f940a5c8b7061007398661a3b14f2037843744" dummy rsync --server -pe.Lsfx --log-format=X --debug=ALL --inplace . .'  /tmp/annex/.git/annex/objects/Wx/Mf/SHA256E-s30--bdce956a335681853344fce6f1f940a5c8b7061007398661a3b14f2037843744/SHA256E-s30--bdce956a335681853344fce6f1f940a5c8b7061007398661a3b14f2037843744 dummy:
+</pre>
+"""]]
diff --git a/doc/bugs/s3_InternalIOException__63__.mdwn b/doc/bugs/s3_InternalIOException__63__.mdwn
new file mode 100644
index 0000000000..5a5674f663
--- /dev/null
+++ b/doc/bugs/s3_InternalIOException__63__.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+
+I got the following errors from the assistant, in `.git/annex/daemon.log`:
+
+    InternalIOException send: resource vanished (Broken pipe)
+
+Then subsequent transfers seem to fail with:
+
+    InternalIOException send: resource vanished (Connection reset by peer)
+
+Workaround: restart the assistant.
+
+### What steps will reproduce the problem?
+
+It's unclear. The assistant is trying to sync a lot of stuff to S3 right now, as files are regularly added into the repository and the assistant migrates them all there. The repository is setup as a "source" repository to make sure it doesn't keep files and send them all to s3.
+
+### What version of git-annex are you using? On what operating system?
+
+standalone tarball `5.20150508-g883d57f` on Ubuntu Precise.
+
+### Please provide any additional information below.
+
+here are the two latest log files, but all previous logfiles available are similar...
+
+http://paste.ubuntu.com/11721025/
+http://paste.ubuntu.com/11721028/
+
+-- [[anarcat]]
diff --git a/doc/bugs/s3_InternalIOException__63__/comment_1_42bd2d1e364203f1b34efcc34ac795b8._comment b/doc/bugs/s3_InternalIOException__63__/comment_1_42bd2d1e364203f1b34efcc34ac795b8._comment
new file mode 100644
index 0000000000..544c8998f8
--- /dev/null
+++ b/doc/bugs/s3_InternalIOException__63__/comment_1_42bd2d1e364203f1b34efcc34ac795b8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-06-15T18:57:07Z"
+ content="""
+Are you sure that it was subsequent transfers of other keys that failed,
+and not subsequent transfers of chunks of the same key?
+
+The latter seems more likely. There is a cached connection to S3 that is
+reused when uploading chunks of a key. But, each transfer of a key
+currently runs using its own individual connection. Difficulties with
+connections that close or are left running too long are why the S3 remote
+doesn't yet reuse connections.
+"""]]
diff --git a/doc/bugs/s3_InternalIOException__63__/comment_2_994dd3ebcf7eaacb0b9e06f1bc14a2d4._comment b/doc/bugs/s3_InternalIOException__63__/comment_2_994dd3ebcf7eaacb0b9e06f1bc14a2d4._comment
new file mode 100644
index 0000000000..4d3172ea30
--- /dev/null
+++ b/doc/bugs/s3_InternalIOException__63__/comment_2_994dd3ebcf7eaacb0b9e06f1bc14a2d4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 2"
+ date="2015-06-15T19:15:12Z"
+ content="""
+i have no idea, really. i probably did *not* disable chunking explicitely on the repo, if that's any help..
+"""]]
diff --git a/doc/bugs/s3_InternalIOException__63__/comment_3_a69927ec705efa31aacb5941bf8d8f9d._comment b/doc/bugs/s3_InternalIOException__63__/comment_3_a69927ec705efa31aacb5941bf8d8f9d._comment
new file mode 100644
index 0000000000..c32621d6e3
--- /dev/null
+++ b/doc/bugs/s3_InternalIOException__63__/comment_3_a69927ec705efa31aacb5941bf8d8f9d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 3"
+ date="2015-06-15T20:02:56Z"
+ content="""
+okay, after disabling chunking, it still doesn't work.
+
+it seems that it's completely stuck: i haven't seen the assistant transfer any new files yet. using `git annex move` seems to work:
+
+<pre>
+www-data@ip-10-87-135-88:/persistent/media$ git annex move --to s3
+move video/mp4_sd/-_cineastas_indigenas_ntsc_-_eng_0.mov.mp4 (checking s3...) ok
+</pre>
+"""]]
diff --git a/doc/bugs/s3_InternalIOException__63__/comment_4_ee791ad24d5d2c0ad4f82ecf6fc434a9._comment b/doc/bugs/s3_InternalIOException__63__/comment_4_ee791ad24d5d2c0ad4f82ecf6fc434a9._comment
new file mode 100644
index 0000000000..fd65fa8f81
--- /dev/null
+++ b/doc/bugs/s3_InternalIOException__63__/comment_4_ee791ad24d5d2c0ad4f82ecf6fc434a9._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 4"
+ date="2015-06-15T20:05:13Z"
+ content="""
+nevermind that: `move` doesn't actually work either, it just skipped files that seemed to have already been transfered. the remaining files are still untransferable:
+
+<pre>
+www-data@ip-10-87-135-88:/persistent/media$ git annex move --to s3
+move video/original/a_gente_luta_-_eng_0.mov (checking s3...) (to s3...)
+0%            0.0 B/s 0s
+  InternalIOException send: resource vanished (Broken pipe)
+failed
+move video/original/a_gente_luta_-_esp_0.mov (checking s3...) (to s3...)
+0%       255.9KB/s 9h23m
+  InternalIOException send: resource vanished (Broken pipe)
+failed
+move video/original/kinja_iakaha_-_dvcam_en.mov (checking s3...) (to s3...)
+0%            0.0 B/s 0s
+  InternalIOException send: resource vanished (Broken pipe)
+failed
+move video/original/quartet_for_deafblind_h264kbs18000_24.mov (checking s3...) (to s3...)
+0%            0.0 B/s 0s
+  InternalIOException send: resource vanished (Broken pipe)
+failed
+git-annex: move: 4 failed
+</pre>
+"""]]
diff --git a/doc/bugs/s3_InternalIOException__63__/comment_5_134d1d0ad9f59a2b7498d1ed335cf91a._comment b/doc/bugs/s3_InternalIOException__63__/comment_5_134d1d0ad9f59a2b7498d1ed335cf91a._comment
new file mode 100644
index 0000000000..59f6c1bd09
--- /dev/null
+++ b/doc/bugs/s3_InternalIOException__63__/comment_5_134d1d0ad9f59a2b7498d1ed335cf91a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 5"
+ date="2015-07-23T19:44:10Z"
+ content="""
+any update of this?
+
+i still can't upload those files, while *other* files get uploaded to S3 fine. really strange. how can i reset the state of this?
+"""]]
diff --git a/doc/bugs/s3_remote__58___public__61__yes_sets_disabled_ACLs.mdwn b/doc/bugs/s3_remote__58___public__61__yes_sets_disabled_ACLs.mdwn
new file mode 100644
index 0000000000..e2e4f98828
--- /dev/null
+++ b/doc/bugs/s3_remote__58___public__61__yes_sets_disabled_ACLs.mdwn
@@ -0,0 +1,41 @@
+### Please describe the problem.
+
+
+### What steps will reproduce the problem?
+I followed the [s3 special remote tip](https://git-annex.branchable.com/tips/public_Amazon_S3_remote/) to setup a public S3 special remote: 
+
+```
+export AWS_ACCESS_KEY_ID...
+export AWS_SECTRET_ACCESS_KEY...
+git annex initremote pubs3 type=S3 encryption=none public=yes
+initremote pubs3 (checking bucket...) (creating bucket in US...) 
+git-annex: S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, s3ErrorCode = "InvalidBucketAclWithObjectOwnership", s3ErrorMessage = "Bucket cannot have ACLs set with ObjectOwnership's BucketOwnerEnforced setting", s3ErrorResource = Nothing, s3ErrorHostId = Just "CvCxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx8ic=", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+failed
+initremote: 1 failed
+```
+
+The ``public`` parameter is documented with 
+> "Set to "yes" to allow public read access to files sent to the S3 remote. This is accomplished by setting an ACL when each file is uploaded to the remote. So, changes to this setting will only affect subseqent uploads."
+
+This [AWS post](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-s3-automatically-enable-block-public-access-disable-access-control-lists-buckets-april-2023/) says that it disables setting ACLs for S3 buckets from April 2023 onward following their previous [recommendation to do so](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ensure-object-ownership.html), so this may be the issue. I know too little about AWS S3 to suggest an alternative approach, so this is just a bug report that the "public" parameter causes trouble when set to "yes".
+There is no issue if I set ``public=no``. 
+
+### What version of git-annex are you using? On what operating system?
+```
+$ git annex version                                                                                    255 !
+git-annex version: 10.20221003
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+```
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I work daily with git-annex and I never fail to be amazed by it. Thank you for your work!
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/s3_remote__58___public__61__yes_sets_disabled_ACLs/comment_1_0bf1f463133476727129ddf15f24983b._comment b/doc/bugs/s3_remote__58___public__61__yes_sets_disabled_ACLs/comment_1_0bf1f463133476727129ddf15f24983b._comment
new file mode 100644
index 0000000000..655556998f
--- /dev/null
+++ b/doc/bugs/s3_remote__58___public__61__yes_sets_disabled_ACLs/comment_1_0bf1f463133476727129ddf15f24983b._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-21T17:04:19Z"
+ content="""
+This only affects new S3 buckets. Existing S3 buckets that were
+created before April 2023 and were set up to allow public access should
+keep working, including ACL settings when storing new files in them.
+Per Amazon's announcement, "There is no change for existing buckets."
+
+So users who create new buckets will need to set `public=no` 
+(the default) and set a bucket policy instread. See 
+[this comment](https://git-annex.branchable.com/special_remotes/S3/#comment-fcfba0021592de4c1425d3bf3c9563d3)
+for an example policy.
+
+That comment also suggests:
+
+* If public=yes, instead of trying to set an ACL, first try HEAD on the
+  newly uploaded object without using the AWS_ACCESS_KEY. Only if that
+  fails, fall over to trying to set an ACL. And if you get
+  AccessControlListNotSupported (i.e. the error due to
+  BucketOwnerEnforced), then give a warning that the bucket policy is not
+  configured for public access.
+
+However, the ACL is currently sent at past of the PutObject request. And 
+either there is not a way to change the ACL later, or the aws haskell library
+is missing support for the API to do that.
+
+I think what needs to be done is discourage initializing new S3 remotes
+with public=yes, since it won't work. (Assuming some other S3
+implementation than Amazon doesn't keep on supporting ACLs.)
+
+And allow setting publicurl=yes without public=yes, so users who create
+new buckets and configure a bucket policy to allow public access can tell
+git-annex it's set up that way, so it will download from the bucket w/o S3
+credentials.
+
+While git-annex could HEAD without creds when publicyes=yes to verify that
+the user has configured the bucket correctly, that would add some overhead,
+and I guess if the user has not configured the bucket correctly, they will
+notice in some other way eventually and can fix its bucket policy after the
+fact. So I'm inclined not to do that.
+"""]]
diff --git a/doc/bugs/safe.bareRepository_breaks_git-annex_uuid.mdwn b/doc/bugs/safe.bareRepository_breaks_git-annex_uuid.mdwn
new file mode 100644
index 0000000000..8ba730ba8a
--- /dev/null
+++ b/doc/bugs/safe.bareRepository_breaks_git-annex_uuid.mdwn
@@ -0,0 +1,21 @@
+Turns out that git-annex breaks badly when git is configured with
+`safe.bareRepository = explicit`.
+
+The breakage starts with git-annex init:
+
+	joey@darkstar:~/tmp>git init g
+	Initialized empty Git repository in /home/joey/tmp/g/.git/
+	joey@darkstar:~/tmp>cd g
+	joey@darkstar:~/tmp/g>git-annex init
+	init  ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/g>git show git-annex | tail
+	+ joey@darkstar:~/tmp/g timestamp=1688579729.946567508s
+
+uuid.log has a NoUUID item logged to it. This is despite annex.uuid being set.
+
+This is because git-annex runs `git config --list`
+inside `.git`.. Which with that config set, omits looking at
+`config` because it thinks it's in a bare repository.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/safe.bareRepository_breaks_git-annex_uuid/comment_1_0a5faade2dfbb0dfe5d94d37450ba06c._comment b/doc/bugs/safe.bareRepository_breaks_git-annex_uuid/comment_1_0a5faade2dfbb0dfe5d94d37450ba06c._comment
new file mode 100644
index 0000000000..97b5e5de97
--- /dev/null
+++ b/doc/bugs/safe.bareRepository_breaks_git-annex_uuid/comment_1_0a5faade2dfbb0dfe5d94d37450ba06c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2024-04-29T13:13:48Z"
+ content="""
+> fixed in [10.20230626-58-ga05bc6a314 AKA 10.20230802~99](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=a05bc6a31459dedd5d199fbc864af2e9d7d1f6d1) --[[yarikoptic]]
+"""]]
diff --git a/doc/bugs/schedule.log_added_to_annex__63_____58____47____47____47__.mdwn b/doc/bugs/schedule.log_added_to_annex__63_____58____47____47____47__.mdwn
new file mode 100644
index 0000000000..eaf1157f95
--- /dev/null
+++ b/doc/bugs/schedule.log_added_to_annex__63_____58____47____47____47__.mdwn
@@ -0,0 +1,58 @@
+### Please describe the problem.
+
+Look at this diff:
+
+```
+diff --git a/schedule.log b/schedule.log
+index 29c727f8c1..2f6d2f0858 100644
+--- a/schedule.log
++++ b/schedule.log
+@@ -1,19 +1 @@
+-0e6c5057-a323-4bec-b6d2-98bae312e7cd  timestamp=1518571009.042438126s
+-0e6c5057-a323-4bec-b6d2-98bae312e7cd fsck self 15m every day at any time timestamp=1503189066.20635041s
+-179b6e7f-0b2f-43b9-a95d-39df5b52d2fc  timestamp=1518565854.651788575s
+-179b6e7f-0b2f-43b9-a95d-39df5b52d2fc  timestamp=1518565869.769672252s
+-179b6e7f-0b2f-43b9-a95d-39df5b52d2fc fsck self 15m every day at any time timestamp=1503191937.325891749s
+-668bdeb3-a3e2-4a9f-ae1c-bae1880c62b8  timestamp=1516100332.848743619s
+-668bdeb3-a3e2-4a9f-ae1c-bae1880c62b8  timestamp=1518305729.698369069s
+-668bdeb3-a3e2-4a9f-ae1c-bae1880c62b8  timestamp=1518565670.560184121s
+-668bdeb3-a3e2-4a9f-ae1c-bae1880c62b8  timestamp=1518868059.554534192s
+-668bdeb3-a3e2-4a9f-ae1c-bae1880c62b8 fsck self 15m every day at any time timestamp=1504318394.78758178s
+-7f0bbee7-826f-4021-a774-0569ff58ed54 fsck self 10m every day at any time timestamp=1514213643.848668933s
+-7f0bbee7-826f-4021-a774-0569ff58ed54 fsck self 15m every day at any time timestamp=1504177427.472846327s
+-7f0bbee7-826f-4021-a774-0569ff58ed54 fsck self 1h every day at any time timestamp=1496609751.566017331s
+-83ffd5ab-40b3-4950-b437-87339242be57 fsck self 15m every day at any time timestamp=1503175558.988571178s
+-ba3a1e0a-9191-43b4-a324-1fee91a9bb8f  timestamp=1503184784.521086496s
+-ba3a1e0a-9191-43b4-a324-1fee91a9bb8f  timestamp=1518566966.391960267s
+-ba3a1e0a-9191-43b4-a324-1fee91a9bb8f fsck self 15m every day at any time timestamp=1503183823.810567346s
+-ba3a1e0a-9191-43b4-a324-1fee91a9bb8f fsck self 15m every day at any time timestamp=1503185213.589823679s
+-ba3a1e0a-9191-43b4-a324-1fee91a9bb8f fsck self 5m every day at any time timestamp=1514056713.473067585s
++/annex/objects/SHA256E-s1676--4e76f9f5e9c5eafe53367a6c493d7618366bcfea6ac8a859fcbaba55ed31f349.log
+```
+
+### What steps will reproduce the problem?
+
+Absolutely no idea.
+
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 6.20170818
+operating system: linux x86_64
+```
+
+
+### Please provide any additional information below.
+
+None
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Considering my two other issues »WHICH LOSE DATA«, I can only conclude it’s too complicated, cf.
+
+* https://git-annex.branchable.com/bugs/Data_loss_when_copying_files_with_running_assistant/
+* https://git-annex.branchable.com/bugs/Infinite_loop_when_synchronizing_between_many_machines/
+
+> I guess this was fixed in the intervening time. With no way to reproduce
+> it, it's hard to tell. [[done]] --[[Joey]]
diff --git a/doc/bugs/securehashesonly_conflicts_with_addurl.mdwn b/doc/bugs/securehashesonly_conflicts_with_addurl.mdwn
new file mode 100644
index 0000000000..39953a6dae
--- /dev/null
+++ b/doc/bugs/securehashesonly_conflicts_with_addurl.mdwn
@@ -0,0 +1,17 @@
+Turning on `securehashesonly` seems to disable the `addurl` command:
+
+```console
+% git config --get annex.securehashesonly
+true
+% git annex addurl https://www.gutenberg.org/cache/epub/2591/pg2591-images.html
+addurl https://www.gutenberg.org/cache/epub/2591/pg2591-images.html
+  annex.securehashesonly blocked transfer of URL key
+failed
+addurl: 1 failed
+% git annex addurl https://www.gutenberg.org/cache/epub/2591/pg2591-images.html --relaxed
+addurl https://www.gutenberg.org/cache/epub/2591/pg2591-images.html (to www.gutenberg.org_cache_epub_2591_pg2591-images.html) ok
+(recording state in git...)
+% ls -l www.gutenberg.org_cache_epub_2591_pg2591-images.html
+www.gutenberg.org_cache_epub_2591_pg2591-images.html -> .git/annex/objects/gg/kG/URL--https&c%%www.gutenberg.org%cache%epub%2591%pg2591-images.html/URL--https&c%%www.gutenberg.org%cache%epub%2591%pg2591-images.html
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/securehashesonly_conflicts_with_addurl/comment_1_808e276381f98b4ebb7d61628db703d9._comment b/doc/bugs/securehashesonly_conflicts_with_addurl/comment_1_808e276381f98b4ebb7d61628db703d9._comment
new file mode 100644
index 0000000000..bf5ae10626
--- /dev/null
+++ b/doc/bugs/securehashesonly_conflicts_with_addurl/comment_1_808e276381f98b4ebb7d61628db703d9._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-27T18:03:11Z"
+ content="""
+I think that git-annex addurl without --fast or --relaxed should
+work with annex.securehashesonly set. (Unless annex.backend is set 
+to something it prevents adding.) It is currently failing because
+of a temporary URL key that never reaches the repository. So the check
+should be disabled for that.
+
+Arguably with --relaxed (or --fast) it should also fail. However,
+that does not actually download the content, so it does not technically
+add content to the repository that is not using a cryptographically
+signed hash. That's how it manages to skate by without failing.
+Of course git-annex get will later fail, git-annex fsck 
+will complain, etc.
+"""]]
diff --git a/doc/bugs/shared_encryption_bypassed_if_gpg_error_on_init.mdwn b/doc/bugs/shared_encryption_bypassed_if_gpg_error_on_init.mdwn
new file mode 100644
index 0000000000..2162f5b3ed
--- /dev/null
+++ b/doc/bugs/shared_encryption_bypassed_if_gpg_error_on_init.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+
+When there is a gpg error upon initializing a special remote with shared encryption, the error is effectively skipped and unencrypted content is synced.
+
+### What steps will reproduce the problem?
+
+- configure a broken/weird version of gpg (e.g. `git config gpg.program echo` reproduces this but I used the [`ots-git-gpg-wrapper.sh` from OpenTimeStamps](https://github.com/opentimestamps/opentimestamps-client/blob/master/doc/git-integration.md) - that's probably an upstream error but I'd consider a broken gpg not-so-uncommon problem)
+- in an annex repo, run `git annex initremote testrepo type=rsync rsyncurl=ssh://... encryption=shared`
+  - `Not enough bytes returned from gpg [Param "--gen-random",Param "--armor",Param "2",Param "512"] (got 56 ; ex
+pected 682 )`
+  - exits with code 1
+  - puts nothing in `git show git-annex:remote.log` but leaves behind a working local git remote that looks to git-annex as an unencrypted remote
+- `git annex sync --content` happily syncs unencrypted content
+
+I guess a sane behaviour would be to not add the local git remote and stop right after encountering the error.
+
+### What version of git-annex are you using? On what operating system?
+
+tried with `10.20230329` and `10.20230408+gc70677e31` on Manjaro
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+It's awesome 👍
+
+> Indeed, there was a laziness bug that prevented it from exiting early
+> enough. [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/should_be_possible_to_use_ssh_hosts_from_.ssh__47__config.mdwn b/doc/bugs/should_be_possible_to_use_ssh_hosts_from_.ssh__47__config.mdwn
new file mode 100644
index 0000000000..d016038bc1
--- /dev/null
+++ b/doc/bugs/should_be_possible_to_use_ssh_hosts_from_.ssh__47__config.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+
+I am using a ssh-host configured in .ssh/config in a corporate-environment like this:
+
+[[!format sh """
+  Host home
+        Hostname 1.2.3.4
+        Port 443
+        ProxyCommand corkscrew proxy.fqdn 8080 %h %p ~/.authfile
+        # http://www.agroman.net/corkscrew/
+"""]]
+
+I now want to be able to add this host as a remote repository, but don't have the ability to add it. A tunnel to localhost would be possible but then I would have to setup this portforwarding for git-annex separately every time it is started.
+
+### What steps will reproduce the problem?
+
+Add a remote host that is only reachable through a proxy.
+
+### What version of git-annex are you using? On what operating system?
+
+gentoo
+git-annex-5.20141125 {+assistant +cryptohash +dbus +desktop-notify +dns +feed +inotify +pairing +production +quvi +s3 +tahoe +tdfa +testsuite +webapp +webapp-secure +webdav +xmpp}
+
+
+
+Is it possible to use this predefined host, or add the possibility to configure git-annex like above?
diff --git a/doc/bugs/should_be_possible_to_use_ssh_hosts_from_.ssh__47__config/comment_1_3dac095b7cf799e31925868d13888970._comment b/doc/bugs/should_be_possible_to_use_ssh_hosts_from_.ssh__47__config/comment_1_3dac095b7cf799e31925868d13888970._comment
new file mode 100644
index 0000000000..8fb2ae19cb
--- /dev/null
+++ b/doc/bugs/should_be_possible_to_use_ssh_hosts_from_.ssh__47__config/comment_1_3dac095b7cf799e31925868d13888970._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="gregor"
+ subject="workaround:"
+ date="2014-12-02T18:04:16Z"
+ content="""
+my workaround is to setup the remote with the local port-forward end then edit the .ssh/config to use the needed ProxyCommand
+"""]]
diff --git a/doc/bugs/should_be_possible_to_use_ssh_hosts_from_.ssh__47__config/comment_2_342b4913a063184650cdf4f541f7ea02._comment b/doc/bugs/should_be_possible_to_use_ssh_hosts_from_.ssh__47__config/comment_2_342b4913a063184650cdf4f541f7ea02._comment
new file mode 100644
index 0000000000..82108d0cda
--- /dev/null
+++ b/doc/bugs/should_be_possible_to_use_ssh_hosts_from_.ssh__47__config/comment_2_342b4913a063184650cdf4f541f7ea02._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2014-12-02T18:51:44Z"
+ content="""
+That will work fine as a git remote using that hostname. `git remote add home home:path`
+
+The webapp isn't currently aware of hostnames configured via .ssh/config,
+so it cannot be set up using the webapp.
+"""]]
diff --git a/doc/bugs/should_create_leading_dirs_for_annex.dbdir.mdwn b/doc/bugs/should_create_leading_dirs_for_annex.dbdir.mdwn
new file mode 100644
index 0000000000..da5d43fddb
--- /dev/null
+++ b/doc/bugs/should_create_leading_dirs_for_annex.dbdir.mdwn
@@ -0,0 +1,73 @@
+### Please describe the problem.
+
+Had some datalad command failing at either `annex add` or `commit` and tried to reproduce with minimal example but failed, overall:  if config is set to use
+
+```
+❯ git config  annex.dbdir
+/tmp/cache/git-annex
+```
+
+and leading `/tmp/cache` does not exist then in some (e.g. whatever happens during `git pull --ff-only`):
+
+```
+❯ git pull --ff-only
+...
+ create mode 100644 cron-20221228/build-windows.yaml-896-ef8b9610-success/test-datalad (release)/8_Install.txt
+ create mode 100644 cron-20221228/build-windows.yaml-896-ef8b9610-success/test-datalad (release)/9_Configure service.txt
+git-annex: /tmp/cache/git-annex: createDirectory: does not exist (No such file or directory)
+
+❯ git annex version
+git-annex version: 10.20221003
+```
+
+or could be even more fun:
+
+```
+❯ git pull --ff-only
+You are not currently on a branch.
+Please specify which branch you want to merge with.
+See git-pull(1) for details.
+
+    git pull <remote> <branch>
+
+❯ git co master
+Previous HEAD position was 3855af5 [tinuous] 20 logs added
+Switched to branch 'master'
+Your branch is up to date with 'origin/master'.
+git-annex: /tmp/cache/git-annex: createDirectory: does not exist (No such file or directory)
+❯ echo $?
+1
+❯ git co master
+git-annex: /tmp/cache/git-annex: createDirectory: does not exist (No such file or directory)
+error: packet write failed: Broken pipe
+error: external filter 'git-annex filter-process' failed
+git-annex: /tmp/cache/git-annex: createDirectory: does not exist (No such file or directory)
+error: external filter 'git-annex filter-process' failed
+git-annex: /tmp/cache/git-annex: createDirectory: does not exist (No such file or directory)
+error: packet write failed: Broken pipe
+error: external filter 'git-annex filter-process' failed
+git-annex: /tmp/cache/git-annex: createDirectory: does not exist (No such file or directory)
+error: external filter 'git-annex filter-process' failed
+git-annex: /tmp/cache/git-annex: createDirectory: does not exist (No such file or directory)
+error: packet write failed: Broken pipe
+error: external filter 'git-annex filter-process' failed
+git-annex: /tmp/cache/git-annex: createDirectory: does not exist (No such file or directory)
+error: packet write failed: Broken pipe
+error: external filter 'git-annex filter-process' failed
+... pressed Ctrl-C
+```
+
+and if I precreate leading one -- seems to be feeling ok
+
+```
+❯ mkdir /tmp/cache
+❯ git co master
+Already on 'master'
+Your branch is up to date with 'origin/master'.
+```
+
+
+NB IIRC: originally came up within reproin-ification effort on rolando and its NFS mounted partition.
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
diff --git a/doc/bugs/should_create_leading_dirs_for_annex.dbdir/comment_1_20cbcee65bccc3213e437ef347b52612._comment b/doc/bugs/should_create_leading_dirs_for_annex.dbdir/comment_1_20cbcee65bccc3213e437ef347b52612._comment
new file mode 100644
index 0000000000..febb5ac8c9
--- /dev/null
+++ b/doc/bugs/should_create_leading_dirs_for_annex.dbdir/comment_1_20cbcee65bccc3213e437ef347b52612._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-01-02T19:14:25Z"
+ content="""
+I took a look at why it does this, and it's because git-annex takes a lot
+of care to avoid doing things like creating /mnt/repo/.git/ when /mnt is not
+mounted. To the directory creating code, the parent directory of 
+annex.dbdir is treated as an alternate top-level directory, which it can
+only create subdirectories of, but not create itself. So the directory
+creating code would need to become somewhat more complicated to support
+the possibility of creating parent directories of one but not of the other.
+
+Maybe the prospect of such complexity is coloring my thinking, but it seems
+like similar concerns about mount points may affect annex.dbdir. After all,
+the point of it is to provide a path on some other filesystem. When
+that filesystem is not currently mounted, it would be better for it to
+error out like this than to create a directory structure inside its mount
+point.
+"""]]
diff --git a/doc/bugs/should_error_on_whereis_--batch-keys_--all.mdwn b/doc/bugs/should_error_on_whereis_--batch-keys_--all.mdwn
new file mode 100644
index 0000000000..0ee8f21ebb
--- /dev/null
+++ b/doc/bugs/should_error_on_whereis_--batch-keys_--all.mdwn
@@ -0,0 +1,25 @@
+### Please describe the problem.
+
+AFAIK `--all` option for `whereis` is "incompatible" with operation on keys, so `git-annex` does still error out on `--all --key KEY`:
+
+```
+$> git annex whereis --json --json-error-messages --key MD5E-s5663237--4608ffbd6b78ce3a325eb338fa556589.nii.gz --all             
+Invalid option `--all'
+...
+```
+
+but it does not error out if I specify `--all` with `--batch-keys`:
+
+```
+$> git annex whereis --json --json-error-messages  --all --batch-keys          
+MD5E-s5663237--4608ffbd6b78ce3a325eb338fa556589.nii.gz
+{"command":"whereis","note":"2 copies\n\t8d2b6e96-ad81-44a5-99b4-0ec37d6b3800 -- [s3-PUBLIC]\n \tb5dd2e3d-825f-4bc2-b719-cba1059f6bfc -- root@93184394ac19:/datalad/ds000001\n\ns3-PUBLIC: https://s3.amazonaws.com/openneuro.org/ds000001/sub-01/anat/sub-01_T1w.nii.gz?versionId=SHOhSfza0LCFpgctRH3sMZ8iwAGSUwIy\n","success":true,"input":["MD5E-s5663237--4608ffbd6b78ce3a325eb338fa556589.nii.gz"],"untrusted":[],"key":"MD5E-s5663237--4608ffbd6b78ce3a325eb338fa556589.nii.gz","whereis":[{"here":false,"uuid":"8d2b6e96-ad81-44a5-99b4-0ec37d6b3800","urls":["https://s3.amazonaws.com/openneuro.org/ds000001/sub-01/anat/sub-01_T1w.nii.gz?versionId=SHOhSfza0LCFpgctRH3sMZ8iwAGSUwIy"],"description":"[s3-PUBLIC]"},{"here":false,"uuid":"b5dd2e3d-825f-4bc2-b719-cba1059f6bfc","urls":[],"description":"root@93184394ac19:/datalad/ds000001"}],"error-messages":[],"file":null}
+^C
+```
+
+
+### What version of git-annex are you using? On what operating system?
+
+`8.20211231+git140-gc3817495f-1~ndall+1`
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/should_error_on_whereis_--batch-keys_--all/comment_1_724ae0427fb306352ff9b26d9fdef27a._comment b/doc/bugs/should_error_on_whereis_--batch-keys_--all/comment_1_724ae0427fb306352ff9b26d9fdef27a._comment
new file mode 100644
index 0000000000..0a5878b4fa
--- /dev/null
+++ b/doc/bugs/should_error_on_whereis_--batch-keys_--all/comment_1_724ae0427fb306352ff9b26d9fdef27a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-26T15:58:12Z"
+ content="""
+More generally, --all and --key are ignored when using --batch or
+--batch-keys, by probably all commands that implement them.
+
+Mixing --batch options with file names also ignores the file names.
+"""]]
diff --git a/doc/bugs/silently_failing_when_attempting_to_add_ignored_files.mdwn b/doc/bugs/silently_failing_when_attempting_to_add_ignored_files.mdwn
new file mode 100644
index 0000000000..d9b5f67486
--- /dev/null
+++ b/doc/bugs/silently_failing_when_attempting_to_add_ignored_files.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+When attempting to add a file listed in .gitignore, git annex exits silently. I would expect to see an error message a la plain git: "The following paths are ignored by one of your .gitignore files: _that file_"
+
+### What steps will reproduce the problem?
+1. Add a file to .gitignore
+2. git annex add _that file_
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 6.20160613
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: darwin x86_64
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/silently_failing_when_attempting_to_add_ignored_files/comment_1_f1208fda822d17a3a9e5457324fdd1df._comment b/doc/bugs/silently_failing_when_attempting_to_add_ignored_files/comment_1_f1208fda822d17a3a9e5457324fdd1df._comment
new file mode 100644
index 0000000000..10a9330a7f
--- /dev/null
+++ b/doc/bugs/silently_failing_when_attempting_to_add_ignored_files/comment_1_f1208fda822d17a3a9e5457324fdd1df._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-12T17:13:37Z"
+ content="""
+This is due to git-annex using `git ls-files --others --exclude-standard`
+to find files to add. Since that silently skips ignored files, so does
+git-annex.
+
+Now that git has `git check-ignore --stdin`, it would be possible for
+git-annex to not run `git ls-files` with `--exclude-standard`, and
+instead check each file it returns to see if it's ignored, and print out 
+a warning message.
+
+But, that would mean a round-trip through the pipe for each filename.
+When operating on a directory containing a lot of new 
+files, it would probably slow down the processing somewhat.
+
+Hmm, but, `git add somedir` does not warn if there are gitignored files in
+somedir; it silently skips them while adding the rest of the directory.
+The warning comes only when explicitly listing an ignored file.
+
+So, git-annex could do the same, only passing the filename through
+checkingnore when it's a normal file and not a directory. This does
+entail statting every command-line parameter though, and passing through
+checkignore would still slow things down. Particularly when `git annex add`
+is run with a huge list of files to add.
+
+I don't know if it's super-important for `git annex add` to mirror every
+behavior of `git add` anyway. Other differences include `git annex add`
+with no parameters defaulting to adding ".", and `git annex add`
+skipping dotfiles by default.
+
+In v6 mode, you can use `git add` to do the same thing as `git annex add`,
+only more slowly. So it could be argued that `git annex add` will remain
+separate from `git add` only because its different behavior can be more
+useful, and for performance reasons. Which makes slowing `git annex add`
+down in order to make it behave more like `git add` seem counterproductive.
+"""]]
diff --git a/doc/bugs/silently_failing_when_attempting_to_add_ignored_files/comment_2_9fe7fd6296db34ee8ee07fe68459e74b._comment b/doc/bugs/silently_failing_when_attempting_to_add_ignored_files/comment_2_9fe7fd6296db34ee8ee07fe68459e74b._comment
new file mode 100644
index 0000000000..fca560ce41
--- /dev/null
+++ b/doc/bugs/silently_failing_when_attempting_to_add_ignored_files/comment_2_9fe7fd6296db34ee8ee07fe68459e74b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="dermungo@19d0cb1f22d4169b48363cfff60c9ede2c14fffa"
+ nickname="dermungo"
+ avatar="http://cdn.libravatar.org/avatar/4f4b91e2275a6673506e2990a4f96270"
+ subject="Work around"
+ date="2017-01-13T14:54:40Z"
+ content="""
+Perhaps other people knew this already, but I thought I would post it here in case someone else has trouble finding a solution to this issue.
+
+I use a global gitignore that ignores most of the files I want to have in my annex.
+The solution was to override my global .gitignore according to this answer at SO <http://stackoverflow.com/questions/26678955/un-ignore-all-files-in-global-gitignore> by creating a .gitignore in the annexed repo with the pattern
+```
+!*
+```
+
+Now it automatically adds everything (except dotfiles) when running `git annex add $DIRPATH`.
+"""]]
diff --git a/doc/bugs/some_conflict_resolution_tests_fail_some_time.mdwn b/doc/bugs/some_conflict_resolution_tests_fail_some_time.mdwn
new file mode 100644
index 0000000000..54cc7166dd
--- /dev/null
+++ b/doc/bugs/some_conflict_resolution_tests_fail_some_time.mdwn
@@ -0,0 +1,57 @@
+### Please describe the problem.
+
+once in a while we have those two tests failing in daily testing of git-annex on ndoli under tmp.  The test configuration is "prescribed" [here](https://github.com/datalad/git-annex/blob/master/clients/clients.yaml#L10) but overall -- we run `git annex test` under POSIX partition on that host.  As a result we get sometimes (not daily!)
+
+```
+❯ grep FAIL git-annex-tmp.log
+    conflict resolution (removed file): FAIL (1003.88s)
+    conflict resolution (mixed directory and file): FAIL (1380.03s)
+❯ grep -3 FAIL git-annex-tmp.log
+    Init Tests
+      init:                             OK (56.99s)
+      add:                              OK (127.60s)
+    conflict resolution (removed file): FAIL (1003.88s)
+      ./Test/Framework.hs:72:
+      sync failed (transcript follows)
+      commit 
+--
+    Init Tests
+      init:                                         OK (44.72s)
+      add:                                          OK (136.98s)
+    conflict resolution (mixed directory and file): FAIL (1380.03s)
+      ./Test/Framework.hs:72:
+      sync in mixed conflict failed (transcript follows)
+      commit 
+```
+
+and among clients it happens only on ndoli and only rarely:
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex-ci-client-jobs[master]builds/2022
+$> datalad foreach-dataset -J0 -s git grep 'conflict resolution.*FAIL'
+foreach-dataset(error): /mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/02 (dataset) [CommandError: 'git grep 'conflict resolution.*FAIL'' failed with exitcode 1 under /mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/02]
+result-ndoli-629/handle-result.yaml-30-52d367ab-success/result-ndoli-629/git-annex-tmp.log:    conflict resolution: FAIL (565.53s)
+foreach-dataset(ok): /mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/03 (dataset)
+foreach-dataset(error): /mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/04 (dataset) [CommandError: 'git grep 'conflict resolution.*FAIL'' failed with exitcode 1 under /mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/04]
+result-ndoli-684/handle-result.yaml-102-394daed9-success/result-ndoli-684/git-annex-tmp.log:    conflict resolution (nonannexed file): FAIL (715.11s)
+foreach-dataset(ok): /mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/05 (dataset)
+result-ndoli-719/handle-result.yaml-162-09b2e6d0-success/result-ndoli-719/git-annex-tmp.log:    conflict resolution (mixed directory and file): FAIL (741.11s)
+result-ndoli-741/handle-result.yaml-204-97aee562-success/result-ndoli-741/git-annex-tmp.log:    conflict resolution (nonannexed file): FAIL (775.03s)
+foreach-dataset(ok): /mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/06 (dataset)
+result-ndoli-770/handle-result.yaml-244-2fbd8878-success/result-ndoli-770/git-annex-tmp.log:    conflict resolution (nonannexed symlink): FAIL (339.79s)
+result-ndoli-778/handle-result.yaml-258-a5ab40e5-success/result-ndoli-778/git-annex-tmp.log:    conflict resolution (removed file): FAIL (917.26s)
+foreach-dataset(ok): /mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/07 (dataset)
+result-ndoli-785/handle-result.yaml-272-e409ca97-success/result-ndoli-785/git-annex-tmp.log:    conflict resolution (mixed directory and file): FAIL (954.74s)
+result-ndoli-786/handle-result.yaml-274-ff6d0e55-success/result-ndoli-786/git-annex-tmp.log:    conflict resolution (mixed directory and file): FAIL (770.95s)
+result-ndoli-788/handle-result.yaml-278-310c87a2-success/result-ndoli-788/git-annex-tmp.log:    conflict resolution (nonannexed file): FAIL (438.90s)
+result-ndoli-788/handle-result.yaml-278-310c87a2-success/result-ndoli-788/git-annex-tmp.log:    conflict resolution (nonannexed symlink): FAIL (441.32s)
+result-ndoli-788/handle-result.yaml-278-310c87a2-success/result-ndoli-788/git-annex-tmp.log:    conflict resolution (mixed directory and file): FAIL (526.07s)
+result-ndoli-788/handle-result.yaml-278-310c87a2-success/result-ndoli-788/git-annex-tmp.log:    conflict resolution movein regression: FAIL (691.90s)
+result-ndoli-802/handle-result.yaml-302-f1034ff8-success/result-ndoli-802/git-annex-tmp.log:    conflict resolution (mixed directory and file): FAIL (811.06s)
+foreach-dataset(ok): /mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/08 (dataset)
+result-ndoli-820/handle-result.yaml-324-d9b34ab5-success/result-ndoli-820/git-annex-tmp.log:    conflict resolution (removed file): FAIL (1003.88s)
+result-ndoli-820/handle-result.yaml-324-d9b34ab5-success/result-ndoli-820/git-annex-tmp.log:    conflict resolution (mixed directory and file): FAIL (1380.03s)
+foreach-dataset(ok): /mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/09 (dataset)
+action summary:
+  foreach-dataset (error: 2, ok: 6)
+```
diff --git a/doc/bugs/some_conflict_resolution_tests_fail_some_time/comment_1_bd9963c2a40b55bf745ce3d801a5da19._comment b/doc/bugs/some_conflict_resolution_tests_fail_some_time/comment_1_bd9963c2a40b55bf745ce3d801a5da19._comment
new file mode 100644
index 0000000000..53e6535f91
--- /dev/null
+++ b/doc/bugs/some_conflict_resolution_tests_fail_some_time/comment_1_bd9963c2a40b55bf745ce3d801a5da19._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-13T17:10:07Z"
+ content="""
+So `git-annex sync` is failing and somehow the failure is silent and all it
+prints is "commit". Not "commit ok" or "commit failed" or an error.
+
+This reminds me of another bug you filed,
+<https://git-annex.branchable.com/bugs/export__95__import__95__subdir_started_to_fail_some_times/>
+In both cases a git-annex command seems to crash in the middle.
+
+The other one is also intermittent. Are both running on the same machine?
+"""]]
diff --git a/doc/bugs/some_conflict_resolution_tests_fail_some_time/comment_2_f7b38a6da0ce74c1d4224a37aad9246a._comment b/doc/bugs/some_conflict_resolution_tests_fail_some_time/comment_2_f7b38a6da0ce74c1d4224a37aad9246a._comment
new file mode 100644
index 0000000000..165c25c986
--- /dev/null
+++ b/doc/bugs/some_conflict_resolution_tests_fail_some_time/comment_2_f7b38a6da0ce74c1d4224a37aad9246a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-09-13T18:02:35Z"
+ content="""
+> Are both running on the same machine?
+
+
+no. This one -- `ndoli` server. [the other one](https://git-annex.branchable.com/bugs/export__95__import__95__subdir_started_to_fail_some_times/) seems to fail on github actions of [datalad/git-annex](https://github.com/datalad/git-annex) itself.
+"""]]
diff --git a/doc/bugs/special_remote_adb_-_Argument_list_too_long.mdwn b/doc/bugs/special_remote_adb_-_Argument_list_too_long.mdwn
new file mode 100644
index 0000000000..6ce054d537
--- /dev/null
+++ b/doc/bugs/special_remote_adb_-_Argument_list_too_long.mdwn
@@ -0,0 +1,56 @@
+### Please describe the problem.
+When using the adb special remote to sync content from my android phone to the local annex, the command fails with an error of "Argument list too long".
+
+### What steps will reproduce the problem?
+
+I'm using Google Pixel 3 with Android 12 on it, installed the `adb` package, and attempted to add the special remote with the path "/sdcard", then checking out the remote tracking branch to "master:android" (since changed to master:android-buggy). The command fails with.
+
+
+### What version of git-annex are you using? On what operating system?
+- Debian Linux 11.2
+- git-annex version: 8.20210223
+- Android OS 12
+- Linux strigo 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 GNU/Linux
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+git annex initremote android type=adb androiddirectory=/sdcard encryption=none exporttree=yes importtree=yes
+git annex wanted android 'include=*.mp3 or include=*.ogg or include=*.jpg or include=*.png or include=*.mp4 or include=*.pdf'
+git annex import --from android master:android
+
+# on subsequent attempts to sync
+git annex sync --content android
+commit
+On branch master
+nothing to commit, working tree clean
+ok
+list android find: exec stat: Argument list too long
+find: exec stat: Argument list too long
+
+git-annex: Unable to list contents of android: adb find failed
+failed
+
+  Not updating export to android to reflect changes to the tree, because export tracking is not enabled.  (Set remote.android.annex-tracking-branch to enable it.)
+    git-annex: sync: 1 failed
+
+# Version information
+git-annex version: 8.20210223
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+This is the first time I've tried it. However, when I restricted the path to /sdcard/DCIM or /sdcard/Music, I didn't have any problems. I could use some assistance regarding how to "copy" a file from one path to another inside an annex. It appears that I could try to resolve and then symlink to the same file, or maybe unlock, copy, and commit both copies of the file. E.g. I'd like to have a copy of the music from my primary "annex/Music" into the "annex/android/Music" tree, then "git rm" the file from "annex/android/Music" when I'm done with it.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/special_remote_adb_-_Argument_list_too_long/comment_1_34f202f91a16dd4d2bb557aee6fd5a3e._comment b/doc/bugs/special_remote_adb_-_Argument_list_too_long/comment_1_34f202f91a16dd4d2bb557aee6fd5a3e._comment
new file mode 100644
index 0000000000..d8d07e4efd
--- /dev/null
+++ b/doc/bugs/special_remote_adb_-_Argument_list_too_long/comment_1_34f202f91a16dd4d2bb557aee6fd5a3e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-31T16:45:55Z"
+ content="""
+Ah so unfortunately android's `find` does not break the command
+runs by arrgument size like xargs does. So the `+` argument
+can't be used, instead I'll make it pipe through xargs.
+
+(To copy a file, you can use `cp -a` or just `cp`, followed by `git-annex
+add`. either will work.)
+"""]]
diff --git a/doc/bugs/special_remote_protocol__58___adding_local_state_variables___40__not_under_git__41__.mdwn b/doc/bugs/special_remote_protocol__58___adding_local_state_variables___40__not_under_git__41__.mdwn
new file mode 100644
index 0000000000..9b87d77c7d
--- /dev/null
+++ b/doc/bugs/special_remote_protocol__58___adding_local_state_variables___40__not_under_git__41__.mdwn
@@ -0,0 +1,17 @@
+### Please describe the feature request.
+It would be useful in the special remote protocol to add commands to store or retrieve local key / value pairs (not stored under git, but only in local files). At the time of writing it seems to me that there are no ways for a special remote to store key / value pairs that are not so relevant to be stored in the git-annex branch but may be of great relevance for other uses (such as optimization).
+
+More on my specific use of the feature: Resumable uploads
+Use case: while uploading a file to a remote which allow resumable uploads (giving you a token to resume at each uploaded chunk), the network connection may drop. The special remote then may need to store the token value under a local file in order to try resume the upload at a later time.
+
+Since the token is not relevant to the story of the git-annex branch (not regarding the user or the repository itself) but of great relevance for optimization (and may also expire after some time) the addition of commands such as SETCONFIG and GETCONFIG (maybe with names like SETLOCALCONFIG and GETLOCALCONFIG) seems natural to me. They could be also useful to save other optimization values (settings that may need to vary from a repository to another one).
+
+### What version of git-annex are you using? On what operating system?
+git-annex 6.20170101 on Debian stretch (from debian archives)
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I'm using (and enjoying) it a lot :)
+
+> Seems like my comment is reasonable, so no change to git-annex is needed.
+> I would be open to being convinced otherwise though... [[wontfix|done]]
+> for now. --[[Joey]]
diff --git a/doc/bugs/special_remote_protocol__58___adding_local_state_variables___40__not_under_git__41__/comment_1_3d162dce2af8d84c5582cf63624e9310._comment b/doc/bugs/special_remote_protocol__58___adding_local_state_variables___40__not_under_git__41__/comment_1_3d162dce2af8d84c5582cf63624e9310._comment
new file mode 100644
index 0000000000..6fdd1e6ad9
--- /dev/null
+++ b/doc/bugs/special_remote_protocol__58___adding_local_state_variables___40__not_under_git__41__/comment_1_3d162dce2af8d84c5582cf63624e9310._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-07T16:49:40Z"
+ content="""
+A reasonable use case indeed.
+
+My initial feeling is, this can be handled well by storing the data
+yourself in the filesysystem. You only need to pick a place for your
+special remote to store the data. Presumably somewhere under `.git`
+or under `.git/annex`. (The protocol's GETGITDIR can be used to
+get the path to `.git`.)
+
+And you need to pick a filename that won't be used by something else.
+
+You can use the protocol's GETUUID to get the uuid of special remote,
+and using that in the path to the data pretty well guarantees nothing
+else is going to use that filename.
+"""]]
diff --git a/doc/bugs/started_to_escape_characters_in_the_output.mdwn b/doc/bugs/started_to_escape_characters_in_the_output.mdwn
new file mode 100644
index 0000000000..e5fdc7f213
--- /dev/null
+++ b/doc/bugs/started_to_escape_characters_in_the_output.mdwn
@@ -0,0 +1,66 @@
+### Please describe the problem.
+
+our datalad tests started to fail recently (in [this PR](https://github.com/datalad/datalad/pull/7372) is the effort to troubleshoot etc).
+
+Here is what we see with recent version using  such simple script:
+
+```
+#!/bin/bash
+
+export PS4='> '
+
+set -eu
+set -x
+
+cd "$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)"
+
+git init
+git annex init
+
+n='gl\orious'
+# touch "$n"
+git annex add --json --json-error-messages "$n"
+```
+
+that now 
+
+```
+❯ ( source /home/yoh/git-annexes/10.20230407+git63-g3d1d77a1bb.env ; bash escaped.sh )
+>> mktemp -d /home/yoh/.tmp/dl-XXXXXXX
+> cd /home/yoh/.tmp/dl-OAXQ1CE
+> git init
+Initialized empty Git repository in /home/yoh/.tmp/dl-OAXQ1CE/.git/
+> git annex init
+init  ok
+(recording state in git...)
+> n='gl\orious'
+> git annex add --json --json-error-messages 'gl\orious'
+git-annex: "gl\\orious" not found
+add: 1 failed
+```
+
+so we get `\\` instead of `\` in the output printed by git-annex
+
+<details>
+<summary>previously was all fine</summary> 
+
+```shell
+❯ ( source /home/yoh/git-annexes/10.20230407.env ; bash escaped.sh )
+>> mktemp -d /home/yoh/.tmp/dl-XXXXXXX
+> cd /home/yoh/.tmp/dl-1TzrWdi
+> git init
+Initialized empty Git repository in /home/yoh/.tmp/dl-1TzrWdi/.git/
+> git annex init
+init  ok
+(recording state in git...)
+> n='gl\orious'
+> git annex add --json --json-error-messages 'gl\orious'
+git-annex: gl\orious not found
+add: 1 failed
+```
+</details>
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[closed|done]] --[[Joey]]
diff --git a/doc/bugs/started_to_escape_characters_in_the_output/comment_1_1d0f25da3af46d211445d10f0d6c143e._comment b/doc/bugs/started_to_escape_characters_in_the_output/comment_1_1d0f25da3af46d211445d10f0d6c143e._comment
new file mode 100644
index 0000000000..77e22a3955
--- /dev/null
+++ b/doc/bugs/started_to_escape_characters_in_the_output/comment_1_1d0f25da3af46d211445d10f0d6c143e._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-04-24T15:13:35Z"
+ content="""
+The next release is going to escape and quote filenames that contain
+special characters similarly to how git does. (But json will not be affected due
+to already being escaped.)
+
+This will affect filenames output in error messages. So if you are
+parsing error messages or non-json output with filenames that contain
+characters that need to be escaped, you will need to deal with the
+change.
+
+See [[todo/terminal_escapes_in_filenames]] for the full details of this
+change.
+
+One thing I noticed about your example is that git-annex add doesn't display
+that particular filename the same as git add does:
+
+	joey@darkstar:~/tmp/xxx>git-annex add 'gl\orious'
+	git-annex: "gl\\orious" not found
+	joey@darkstar:~/tmp/xxx>git add 'gl\orious'
+	fatal: pathspec 'gl\orious' did not match any files
+
+But, that is an inconsistency in git itself. More commonly it uses the same
+display as git-annex for this filename:
+
+	joey@darkstar:~/tmp/xxx>touch 'gl\orious'
+	joey@darkstar:~/tmp/xxx>git add 'gl\orious'
+	joey@darkstar:~/tmp/xxx>git diff --cached
+	diff --git "a/gl\\orious" "b/gl\\orious"
+	new file mode 100644
+	index 0000000..e69de29
+
+So I don't think there's a problem with git-annex's behavior here. With
+that said, we can talk about adding something to make back-compatability
+easy for you, or whatever. An config like core.quotePath but that also
+affects special characters, not just unicode, for example.
+"""]]
diff --git a/doc/bugs/started_to_escape_characters_in_the_output/comment_2_76c80e98cc2d26e4cebaac6e40e76df9._comment b/doc/bugs/started_to_escape_characters_in_the_output/comment_2_76c80e98cc2d26e4cebaac6e40e76df9._comment
new file mode 100644
index 0000000000..f0ab0baa69
--- /dev/null
+++ b/doc/bugs/started_to_escape_characters_in_the_output/comment_2_76c80e98cc2d26e4cebaac6e40e76df9._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2023-04-24T19:23:22Z"
+ content="""
+hm, I didn't look inside `git` but `git diff` is likely to have it escaped because `patch` (and/or other unified diff operating tools) expect it such. In other words -- `git diff` must encode paths escaped because the \"diff standard\" expects it such.
+
+On the other hand, as you confirmed, `git add` just displays the name on the screen, and as such it does not bother escaping it since may be I just cut/paste it as a string which is \"raw\" and thus not expecting any escape characters.
+
+RTFMing [git-config on core.quotePath](https://git-scm.com/docs/git-config#Documentation/git-config.txt-corequotePath)  I  spotted 
+
+> ... enclosing the pathname in double-quotes and escaping ...
+
+so it talks about double-quotes.  `git` `status`, `diff` report paths in double (`\"`) not single (`'`) quotes. I wonder if that is where/how `git` is consistent since in your example that is the difference too:
+
+```
+# current master git-annex
+joey@darkstar:~/tmp/xxx>git-annex add 'gl\orious'
+git-annex: \"gl\\orious\" not found
+joey@darkstar:~/tmp/xxx>git add 'gl\orious'
+fatal: pathspec 'gl\orious' did not match any files
+```
+
+that git uses `'` (and does not escape) while git annex uses `\"` (and escapes)?  Did you see git doing escaping in paths where it reports them within single (`'`) quotes?
+
+and thus git-annex should have just wrapped in `'` to become consistent with git in :
+
+```shell
+# released git-annex
+> git annex add --json --json-error-messages '\e[31mfo\o\e[0m'
+git-annex: \e[31mfo\o\e[0m not found
+add: 1 failed
+> git add '\e[31mfo\o\e[0m'
+fatal: pathspec '\e[31mfo\o\e[0m' did not match any files
+> git rm '\e[31mfo\o\e[0m'
+fatal: pathspec '\e[31mfo\o\e[0m' did not match any files
+```
+
+
+"""]]
diff --git a/doc/bugs/started_to_escape_characters_in_the_output/comment_3_0fe421cd62c36804a78e4b424302e3d7._comment b/doc/bugs/started_to_escape_characters_in_the_output/comment_3_0fe421cd62c36804a78e4b424302e3d7._comment
new file mode 100644
index 0000000000..439130d7c9
--- /dev/null
+++ b/doc/bugs/started_to_escape_characters_in_the_output/comment_3_0fe421cd62c36804a78e4b424302e3d7._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-04-24T19:25:12Z"
+ content="""
+git escapes filenames like this extensively:
+
+	joey@darkstar:~/tmp/xxx>git ls-files
+	"gl\\orious"
+	joey@darkstar:~/tmp/xxx>git status
+	Changes to be committed:
+	  (use "git restore --staged <file>..." to unstage)
+		new file:   "gl\\orious"
+	joey@darkstar:~/tmp/xxx>git grep hi
+	"gl\\orious":hi
+
+This message from `git add` escapes slightly differently, but it still escapes
+some characters:
+
+	joey@darkstar:~/tmp/xxx>git add $(echo -e "\e[31mfoo\e[0m")
+	fatal: pathspec '?[31mfoo?[0m' did not match any files
+
+Git only does this type of escaping when displaying a fatal error
+(it's `vreportf` in the git source, used by things like `die`).
+It's basically a last-ditch filtering of a string, which may contain a filename
+or other untrusted data, to avoid displaying escape characters. git-annex does
+contain such a last-ditch filtering too (safeOutput) but type safety let me avoid
+needing to use it to handle this filename here. I don't think it's at all necessary
+for git-annex to be bug-for-bug equivilant with git in its display of error
+messages; but it is important that it escape somehow. Git's double-quoted escaping
+is documented, and this other escaping is not.
+
+Since either behavior would be a behavior change from before when git-annex didn't
+escape the filename in the error message with either method, it seems to me either
+one would likely break your assumption. So I don't know why you're arguing for
+one way over the other way.
+"""]]
diff --git a/doc/bugs/started_to_escape_characters_in_the_output/comment_4_d3c423c3faecc115bb5bab3471226ee5._comment b/doc/bugs/started_to_escape_characters_in_the_output/comment_4_d3c423c3faecc115bb5bab3471226ee5._comment
new file mode 100644
index 0000000000..cf6fa62a55
--- /dev/null
+++ b/doc/bugs/started_to_escape_characters_in_the_output/comment_4_d3c423c3faecc115bb5bab3471226ee5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2023-04-24T21:25:08Z"
+ content="""
+I am \"arguing\" because ideally I prefer not to handle some not quite standardized un-escaping.
+
+1. Which characters I should expect to be escaped? [Here](https://github.com/datalad/datalad/blob/maint/datalad/support/network.py#L925) is the ones we have for SSH: `_SSH_ESCAPED_CHARACTERS = '\\#&;`|*?~<>^()[]{}$\'\" '`. The same here?
+2. Would it be sensible to request `add --json --json-error-messages` to produce a proper machine readable json record  for \"unknown\" input, or there is a reason why there is no json record here in `--json` mode?
+
+Also I just wanted to make sure that we are not missing some aspect, like what I felt was an unnoticed (to me at least) difference between `'` and `\"` escaping methods, and possibly some original reason on why `git` has them different in those cases -- may be there is some good reason?
+
+"""]]
diff --git a/doc/bugs/started_to_escape_characters_in_the_output/comment_6_783b2bdf1826f472d8f39d01e81adf20._comment b/doc/bugs/started_to_escape_characters_in_the_output/comment_6_783b2bdf1826f472d8f39d01e81adf20._comment
new file mode 100644
index 0000000000..b570bec9ae
--- /dev/null
+++ b/doc/bugs/started_to_escape_characters_in_the_output/comment_6_783b2bdf1826f472d8f39d01e81adf20._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-04-25T17:18:23Z"
+ content="""
+Note that I should avoid releasing git-annex with the added escaping until
+this is addressed.
+"""]]
diff --git a/doc/bugs/started_to_escape_characters_in_the_output/comment_6_b8da1f30c5bc88f4ddb7878d790823cd._comment b/doc/bugs/started_to_escape_characters_in_the_output/comment_6_b8da1f30c5bc88f4ddb7878d790823cd._comment
new file mode 100644
index 0000000000..308e55ee1e
--- /dev/null
+++ b/doc/bugs/started_to_escape_characters_in_the_output/comment_6_b8da1f30c5bc88f4ddb7878d790823cd._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-04-25T16:31:44Z"
+ content="""
+I dug into your code, and datalad is parsing git-annex's (and perhaps 
+git's in some cases) stderr to find error messages like this one for files
+that don't exist, and then it internally dummies up something as if git-annex
+were outputting a --json-error-messages record for the file. See
+`./datalad/support/annex_utils.py` `_get_non_existing_from_annex_output`
+
+Ok, I can understand now how needing to do an additional form of unescaping
+on top of that existing pain point would cause the reaction I have seen in
+this bug report.
+
+[[todo/api_for_telling_when_nonexistant_or_non_git_files_passed]] is a todo
+item I opened the last time I became aware of this error message parsing ugliness.
+(Also relevant is [this closed todo](https://git-annex.branchable.com/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output/)
+where I discuss why --json-error-messages cannot include these errors
+as-is.)
+
+So the choice is between implementing 
+[[todo/api_for_telling_when_nonexistant_or_non_git_files_passed]]
+and changing datalad to use that. Or adding a git config
+that avoids escaping filenames. The latter would be easy
+to do (and easier for datalad to use), but it kicks the can down the road.
+Datalad parsing error messages would continue to be a problem going
+forward. (Imagine if git-annex gets localized error messages..)
+"""]]
diff --git a/doc/bugs/started_to_escape_characters_in_the_output/comment_7_c855cc0728c71e9a4696a192cd331213._comment b/doc/bugs/started_to_escape_characters_in_the_output/comment_7_c855cc0728c71e9a4696a192cd331213._comment
new file mode 100644
index 0000000000..7db7d1bf2c
--- /dev/null
+++ b/doc/bugs/started_to_escape_characters_in_the_output/comment_7_c855cc0728c71e9a4696a192cd331213._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2023-04-25T23:27:25Z"
+ content="""
+[[todo/api_for_telling_when_nonexistant_or_non_git_files_passed]] is
+implemented now.
+
+In datalad, all you should need to do now is check for a json object with
+`errorid:"FileNotFound"` and the `file` field is the name of the file.
+
+Note that the parser for error messages like "did not match any file(s)
+known to git" from `git ls-files --error-unmatch` will still be needed in
+datalad.
+
+I'm going to leave this open as a git-annex release blocker until the
+necessary changes get made to datalad.
+"""]]
diff --git a/doc/bugs/started_to_escape_characters_in_the_output/comment_8_ee066c129d808ac511c0efce9a644ab9._comment b/doc/bugs/started_to_escape_characters_in_the_output/comment_8_ee066c129d808ac511c0efce9a644ab9._comment
new file mode 100644
index 0000000000..e2b725f3f2
--- /dev/null
+++ b/doc/bugs/started_to_escape_characters_in_the_output/comment_8_ee066c129d808ac511c0efce9a644ab9._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-04-25T23:33:56Z"
+ content="""
+Also yarik mentioned this change
+<https://github.com/datalad/datalad/pull/7372/commits/45ddd4b12ff637c6c77e982225c0e9d9eb53c1b6>
+which was caused by [[!commit a0e6fa18eb3c16c3c8079bb41c18151e6ea8b554]],
+which was part of my series for escaping control characters.
+
+I think git-annex needs to be returned to the old behavior there, even
+though `git-annex info dne` is not technically operating on a file when it
+doesn't exist.
+
+Update: Fixed this.
+"""]]
diff --git a/doc/bugs/started_to_escape_characters_in_the_output/comment_9_41bac25db7cc8978659c2e202960a2a4._comment b/doc/bugs/started_to_escape_characters_in_the_output/comment_9_41bac25db7cc8978659c2e202960a2a4._comment
new file mode 100644
index 0000000000..025c8acfe1
--- /dev/null
+++ b/doc/bugs/started_to_escape_characters_in_the_output/comment_9_41bac25db7cc8978659c2e202960a2a4._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2023-06-05T19:06:30Z"
+ content="""
+This has been blocking git-annex release for the past month.
+
+Apparently datalad has mostly been updated now. 
+<https://github.com/datalad/datalad/pull/7372> is still not merged, but I'm
+not clear if the 2 failed tests there are caused by this change or
+something else.
+
+I'm feeling now that I've waited long enough for datalad. I've closed this
+bug and don't consider it as blocking release.
+"""]]
diff --git a/doc/bugs/startup_scan_extremely_slow.mdwn b/doc/bugs/startup_scan_extremely_slow.mdwn
new file mode 100644
index 0000000000..449c88e94d
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow.mdwn
@@ -0,0 +1,69 @@
+### Please describe the problem.
+
+When the assistant starts it takes several hours to do the startup scan, even when there are no files to add.
+
+The repo contains many small files but it is configured to add the smaller ones via gitattributes. In particular there are: 91949 files added to git repo and 1029 annexed.
+This is my gitattributes
+
+    * annex.largefiles=(largerthan=500kb)
+
+annex.addunlocked is set to true
+
+### What steps will reproduce the problem?
+
+Create a repo with ~90000 files smaller than 500k and ~1000 files larger (in my case ranging from 500k to 32M). Set addunlocked to true and annex.largefiles to largerthan=500kb. Start the assistant and let it finish adding the files. Restart the assistant.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 6.20160318
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 6
+
+I'm running it on Arch Linux (packaged version)
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+[2016-03-29 22:08:26.356586] main: starting assistant version 6.20160318
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2016-03-29 22:08:41.426049] Watcher: Performing startup scan
+[2016-03-29 23:05:40.533113] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 00:10:07.085051] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 01:23:29.784236] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 02:43:02.048312] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 03:37:53.273057] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 04:04:56.875573] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 04:31:14.370618] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 04:56:12.467889] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 05:21:09.021728] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 05:43:11.111616] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 06:14:38.096425] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 06:49:54.730879] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 07:26:47.721929] Committer: Committing changes to git
+(recording state in git...)
+
+
+# End of transcript or log.
+"""]]
+
+At this point I stopped the assistant that was still doing the startup scan...
+
+### Have you had any luck using git-annex before?
+
+Sure!
diff --git a/doc/bugs/startup_scan_extremely_slow/comment_1_68f88f04c179800c0ce1ff6925d4c6ab._comment b/doc/bugs/startup_scan_extremely_slow/comment_1_68f88f04c179800c0ce1ff6925d4c6ab._comment
new file mode 100644
index 0000000000..ea3347db7f
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow/comment_1_68f88f04c179800c0ce1ff6925d4c6ab._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="zarel"
+ subject="comment 1"
+ date="2016-04-02T20:22:23Z"
+ content="""
+I suppose that the problem is strictly assistant related since both \"git annex status\" and \"git status\" give me the correct status when new files are present in a couple of seconds the first time and in a fraction of a second in the subsequent calls
+"""]]
diff --git a/doc/bugs/startup_scan_extremely_slow/comment_2_116e850299372027481c9d0a1667d5af._comment b/doc/bugs/startup_scan_extremely_slow/comment_2_116e850299372027481c9d0a1667d5af._comment
new file mode 100644
index 0000000000..03683dea1b
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow/comment_2_116e850299372027481c9d0a1667d5af._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-04-04T20:23:19Z"
+ content="""
+Note that v6 is still an experimental feature. I have not tested the
+assistant with it much.
+
+There is an issue documented on [[smudge]] where git can end up
+unncessarily running the smudge filter after git-annex eg, gets a file,
+or adds a file.
+
+This could be related to that; after the assistant added a lot of
+files here, the first `git status` run was quite slow as it ran the clean
+filter on every file. Subsequent `git status` runs then went fast.
+
+But, I don't know why this would make the startup scan slow; it
+doesn't seem to use any git commands that would need to smudge files.
+I tested by exporting `GIT_TRACE=1` and starting the assistant; the
+startup scan went fast and there was nothing in .git/annex/daemon.log
+about smudging.
+
+Also, what are these changes that are apparently being committed to git
+during your startup scan? I don't see such commits, either here.
+"""]]
diff --git a/doc/bugs/startup_scan_extremely_slow/comment_3_3eb4c2290e560451e7341b85b58212b0._comment b/doc/bugs/startup_scan_extremely_slow/comment_3_3eb4c2290e560451e7341b85b58212b0._comment
new file mode 100644
index 0000000000..a2ac70fae1
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow/comment_3_3eb4c2290e560451e7341b85b58212b0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="zarel"
+ subject="comment 3"
+ date="2016-04-05T17:24:06Z"
+ content="""
+You're right, after the initial run there is no smudge filter overhead. I ran htop in tree view and got this result:
+
+    git-annex-assistant (55-60%)
+      |--> git-annex-assistant (six instances, a couple of those with load 20-40%, the others idling at 0%)
+      |--> git ls-files (mostly idle)
+      |--> git check-attr (mostly idle)
+      |--> git check-ignore (mostly idle)
+      |--> git cat-file (stuck at 40-60%)
+"""]]
diff --git a/doc/bugs/startup_scan_extremely_slow/comment_4_ade878000a050c87a345e8bc9914deba._comment b/doc/bugs/startup_scan_extremely_slow/comment_4_ade878000a050c87a345e8bc9914deba._comment
new file mode 100644
index 0000000000..76cf8faedf
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow/comment_4_ade878000a050c87a345e8bc9914deba._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="zarel"
+ subject="comment 4"
+ date="2016-04-22T15:27:20Z"
+ content="""
+git-annex updated to the last version. .git removed, repo recreated from scratch in v5 direct mode and it still happens. I'll try to export GIT_TRACE and understand why the \"cat-file\" is taking 50% of a cpu
+"""]]
diff --git a/doc/bugs/startup_scan_extremely_slow/comment_5_4ee924e70d5a8e35e706eaaff4cc76e1._comment b/doc/bugs/startup_scan_extremely_slow/comment_5_4ee924e70d5a8e35e706eaaff4cc76e1._comment
new file mode 100644
index 0000000000..d0fa0720ed
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow/comment_5_4ee924e70d5a8e35e706eaaff4cc76e1._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="zarel"
+ subject="comment 5"
+ date="2016-04-24T15:31:05Z"
+ content="""
+I exported GIT_TRACE and discovered that the assistant is re-adding to git the small files everytime I run it.
+Below there's a link to the trace (with filenames removed). All the files are not matching the annex.largefiles expression (which is okay), there are no duplicates (i.e. it's not a \"I'm adding the same files in the same run\" problem) and all of them were already added the first time I ran the assistant and are not new to git and git-annex as they are not shown in \"git status\" or in \"git annex status\".
+
+The daemon.log is pretty brief:
+
+    [2016-04-24 12:49:31.129582] main: starting assistant version 6.20160418
+    
+      No known network monitor available through dbus; falling back to polling
+    (scanning...) [2016-04-24 12:49:55.098167] Watcher: Performing startup scan
+    [2016-04-24 12:58:51.667861] Committer: Committing changes to git
+    (recording state in git...)
+    [2016-04-24 13:08:25.154713] Committer: Committing changes to git
+    (recording state in git...)
+
+You can find the trace here: <https://gist.github.com/zarelit/815de89d972314f2e6495a2cdab91aca>
+
+As you can see it almost takes ten minutes before reaching the first git-add.
+
+My git-annex version is now 6.20160418 and the git one is 2.8.0, what version of git did you use when tracing? I can try to reproduce in a different environment (e.g. Debian stable with backports) if it can be useful.
+
+Cheers,
+David
+"""]]
diff --git a/doc/bugs/still_seeing_errors_with_parallel_git-annex-add.mdwn b/doc/bugs/still_seeing_errors_with_parallel_git-annex-add.mdwn
new file mode 100644
index 0000000000..282cb558d1
--- /dev/null
+++ b/doc/bugs/still_seeing_errors_with_parallel_git-annex-add.mdwn
@@ -0,0 +1,17 @@
+It seems that the [[issue with parallel git-annex-add|bugs/withOtherTmp_file_escapes]] is not yet quite fixed; I'm seeing it in the git-annex version 7.20190507-g0c2cc3d .  Repeating the git-annex-add command succeeds in adding the files that failed the first time.
+
+[[!format sh """
+add benchmarks/rabies200/analysis-FK7BF7Q0761xKv6V3z3gzZgK/benchmark_variants/v1.23.0_spades-3.13.0-trinity-metaspades-01/inputs-local.json
+git-annex: .git/annex/othertmp/inge11793-2931: rename: permission denied (Permission denied)
+failed
+add benchmarks/rabies200/analysis-FK7BKGj0761VgPb22550gfBX/benchmark_variants/v1.23.0_spades-3.13.0-trinity-metaspades-01/inputs-local.json
+git-annex: .git/annex/othertmp/inge11793-3330: rename: permission denied (Permission denied)
+failed
+git-annex: add: 2 failed
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git-annex has become an essential tool for organizing my bioinformatics data analyses.  It scales well to large repos.  It lets me keep track of analyses without
+locking myself into any specific cloud platform.  It lets me quickly free up space on demand by moving data to cheaper storage, with the assurance that nothing will get lost.
+Thanks @joeyh for all your work on it.
diff --git a/doc/bugs/still_seeing_errors_with_parallel_git-annex-add/comment_1_b38f13a4c28ad8ce26aef72e7d6fcb11._comment b/doc/bugs/still_seeing_errors_with_parallel_git-annex-add/comment_1_b38f13a4c28ad8ce26aef72e7d6fcb11._comment
new file mode 100644
index 0000000000..e9b4702eb9
--- /dev/null
+++ b/doc/bugs/still_seeing_errors_with_parallel_git-annex-add/comment_1_b38f13a4c28ad8ce26aef72e7d6fcb11._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-05-23T16:18:23Z"
+ content="""
+This may be somehow related to the other bug in that it might also have to
+do with the same temp file, but it does not seem to be the same problem.
+
+Why would rename() be failing with a permissions problem due to a temp
+directory cleanup?
+
+It would be helpful to see a strace of the failed `rename()` call, because
+I can't immadiately see where a temp file with that name would be exposed
+to `rename()` in a way that could crash like that.
+"""]]
diff --git a/doc/bugs/still_seeing_errors_with_parallel_git-annex-add/comment_2_96312bab546412b1eecfa74aec1d7fee._comment b/doc/bugs/still_seeing_errors_with_parallel_git-annex-add/comment_2_96312bab546412b1eecfa74aec1d7fee._comment
new file mode 100644
index 0000000000..14598c58c3
--- /dev/null
+++ b/doc/bugs/still_seeing_errors_with_parallel_git-annex-add/comment_2_96312bab546412b1eecfa74aec1d7fee._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-05-23T17:07:40Z"
+ content="""
+I'll try to reproduce this and re-run under `strace`.  Maybe also, take another look at [[todo/add_tests_under_concurrency]]?  I think that re-running concurrent operations on a small repo many times should test all relevant operation interleavings, and bring out the concurrency-specific bugs.
+
+With large repos, concurrency is the only way to make operations run in sane time.  So fixing this would help a lot.
+
+"""]]
diff --git a/doc/bugs/still_seeing_errors_with_parallel_git-annex-add/comment_3_e76ddebaf9d248c02d16a6914973d7d0._comment b/doc/bugs/still_seeing_errors_with_parallel_git-annex-add/comment_3_e76ddebaf9d248c02d16a6914973d7d0._comment
new file mode 100644
index 0000000000..14afe6cec5
--- /dev/null
+++ b/doc/bugs/still_seeing_errors_with_parallel_git-annex-add/comment_3_e76ddebaf9d248c02d16a6914973d7d0._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-10-20T17:33:03Z"
+ content="""
+This seems to be the same error message as in these 2 bugs:
+
+OSX: <https://git-annex.branchable.com/bugs/__34__rename__58___permission_denied__34__/>
+
+Windows: <https://git-annex.branchable.com/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/>
+
+So it would be especially helpful if I could reproduce it on Linux. Is
+anything else needed other than running git-annex add concurrently? And is that
+multiple processes, or with -J? 
+"""]]
diff --git a/doc/bugs/support_bare_git_repo__44___with_the_annex_directory_exposed_to_http.mdwn b/doc/bugs/support_bare_git_repo__44___with_the_annex_directory_exposed_to_http.mdwn
new file mode 100644
index 0000000000..ba7dcad300
--- /dev/null
+++ b/doc/bugs/support_bare_git_repo__44___with_the_annex_directory_exposed_to_http.mdwn
@@ -0,0 +1,20 @@
+Let's say that http://people.collabora.com/~alsuren/git/fate-suite.git/ is a bare git repo. It has been 'git update-server-info'd so that it can be served on a dumb http server.
+
+The repo is also a git annex remote, created using the following commands:
+
+* git remote add alsuren git+ssh://people.collabora.co.uk/user/alsuren/public_html/fate-suite.git
+* git push alsuren --all
+* git annex copy --to=alsuren
+
+so http://people.collabora.com/~alsuren/git/fate-suite.git/annex is a valid git annex (though listing dirs is forbidden, so you need to know the filenames ahead of time).
+
+I would like to be able to use the following commands to get a clone of the repo:
+
+* git clone http://people.collabora.com/~alsuren/git/fate-suite.git/
+* cd fate-suite
+* git annex get
+
+This would allow contributors to quickly get a copy of our upstream repo and start contributing with minimal bandwidth/effort.
+
+> This is now supported.. I look forward to seeing your project using it!
+> --[[Joey]] [[!tag done]]
diff --git a/doc/bugs/surprising_import_tree_merge_result.mdwn b/doc/bugs/surprising_import_tree_merge_result.mdwn
new file mode 100644
index 0000000000..2476944794
--- /dev/null
+++ b/doc/bugs/surprising_import_tree_merge_result.mdwn
@@ -0,0 +1,18 @@
+Had a surprising result of an import tree merge. I am importing photos
+from my phone. I had earlier imported some photos and moved the whole tree
+containing them from  phone/DCIM to raw/photos/something. Then I took a new photo,
+and imported again.
+
+one. In commit cd55a5be377020b7261c3a737b5e32a01e22f4b8 "import from phone"
+that added a `phone/DCIM/Camera/IMG_20190516_111640.jpg`.
+
+But then in the merge commit a548a51de2566c26f74b5791eb0660e4d79e2cb7
+that merged phone/master into master, the new photo moved into
+raw/photos/something
+
+This is quite surprising. It seems somehow when it modified the old
+tree, it rooted the new at the location the old had been moved to in
+master.
+
+> Gonna close this old bug since I suspect it's been fixed. [[done]]
+> --[[Joey]]
diff --git a/doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant.mdwn b/doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant.mdwn
new file mode 100644
index 0000000000..d7c679e22b
--- /dev/null
+++ b/doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant.mdwn
@@ -0,0 +1,49 @@
+### Please describe the problem.
+
+It seems that the `synced/git-annex` branch (which I am a little confused about in the first place), doesn't get synced automatically by the assistant.
+
+I was expecting the assistant to regularly do the equivalent of `git annex sync`. However, after a client pushed changes to the `git-annex` branch, I had to manually do a `git annex sync` for the changes of the `synced/git-annex` branch to be merged down into the local `git-annex`.
+
+### What steps will reproduce the problem?
+
+I have 3 machines in this setup (to simplify: there are more, but those are sufficient). Let's call them foo, bar and quux. foo and quuex are connected to bar through password-less SSH connexions.
+
+foo commits a file to git-annex. the assistant syncs that to bar in the `synced/git-annex` branch.
+
+quux syncs with bar, and seems to ignore the `synced/git-annex` branch.
+
+git-annex sync on quux syncs the `synced/git-annex` branch into the local `git-annex`, working around the issue.
+
+### What version of git-annex are you using? On what operating system?
+
+foo is 5.20150610+gitg608172f-1~ndall+1 on Debian 7.8 (wheezy).
+
+bar and quux are 5.20150409+git126-ga29f683-1~ndall+1 and 5.20150610+gitg608172f-1~ndall+1 (respectively) on Ubuntu 12.04 (precise) .
+
+### Please provide any additional information below.
+
+I guess a more general question is how and how often do those branches get merged by the assistant... it's still unclear to me how this works.
+
+[[!format sh """
+$ sudo -u www-data -H git annex sync
+(merging origin/synced/git-annex into git-annex...)
+(recording state in git...)
+commit  ok
+pull origin
+Auto packing the repository in background for optimum performance.
+See "git help gc" for manual housekeeping.
+
+Already up-to-date.
+ok
+push origin
+Counting objects: 373637, done.
+# End of transcript or log.
+"""]]
+
+This was started at 20:23 UTC. Note that the sync had run previously under the assistant:
+
+<pre>
+[2015-07-22 20:09:06 UTC] RemoteControl: Syncing with origin
+</pre>
+
+Available, as usual, for further debugging. :) -- [[anarcat]]
diff --git a/doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant/comment_1_b832288844a3e7e944fa08a6edb97d29._comment b/doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant/comment_1_b832288844a3e7e944fa08a6edb97d29._comment
new file mode 100644
index 0000000000..f06ebdaa77
--- /dev/null
+++ b/doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant/comment_1_b832288844a3e7e944fa08a6edb97d29._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-21T19:08:28Z"
+ content="""
+The assistant merges the synced/git-annex branch whenever it detects (via
+inotify) that a change has been made to that git ref. 
+
+I can't reproduce a problem from the information you've given. With
+`foo -> bar <- quux`, and assistants running on foo and quux, any file
+written to foo more or less immediately syncs to quux, and the git-annex
+branch is merged.
+
+Even when I stop the assistant running on foo, and manually run
+`git push bar git-annex:synced/git-annex`, quux immediately notices that
+bar has received that synced/git-annex, and fetches and merges it into its
+own git-annex branch.
+"""]]
diff --git a/doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant/comment_2_fbfc8929497f609916d9f3e5a0a9b531._comment b/doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant/comment_2_fbfc8929497f609916d9f3e5a0a9b531._comment
new file mode 100644
index 0000000000..d21e584a69
--- /dev/null
+++ b/doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant/comment_2_fbfc8929497f609916d9f3e5a0a9b531._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-09-21T19:21:30Z"
+ content="""
+Note that I'm assuming that bar is a remote of both foo and of quux.
+That seems like a reasonable reading of what you described, and is a
+reasonable configuration, but perhaps you were trying to describe some
+other configuration. 
+
+In [[forum/mesh_configurations]] you seem to instead
+describe a chain of remotes, where bar is a remote of foo, and quux is a
+remote of bar: `foo -> bar -> quux`. In this configuration, running the assistant on 
+foo and quux, but not on bar, would not result in changes made on quux
+ever getting to foo, because quux has no way to push objects to bar. So, I
+don't think that's the configuration you meant either. But lack of clarity
+in bug report makes it hard to know.
+"""]]
diff --git a/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files.mdwn b/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files.mdwn
new file mode 100644
index 0000000000..cea39699d2
--- /dev/null
+++ b/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files.mdwn
@@ -0,0 +1,101 @@
+### Please describe the problem.
+I had assumed that [[`git-annex-sync --content`|git-annex-sync]], if it succeeds, guarantees that there are no broken symlinks to the annex.  But there is one circumstance when that's not true: if some of the files exist only on remotes that have not yet been enabled.  This still holds under `git annex required here anything`.
+
+This could of course be avoided with `autoenable=true`, but this doesn't work for [[external special remotes|special_remotes/external]].  [[todo/dockerized_external_special_remotes]], if doable, would address this.
+
+
+### What steps will reproduce the problem?
+See below
+
+### What version of git-annex are you using? On what operating system?
+[[!format sh """
+git-annex version: 8.20210224-gf951847c6
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+
+Linux New-VirtualBox 5.8.0-48-generic #54~20.04.1-Ubuntu SMP Sat Mar 20 13:40:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
+
+"""]]
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+(ga-env-05) /data/tmp [10:27:08]$ mkdir t
+(ga-env-05) /data/tmp [10:27:09]$ cd t
+(ga-env-05) /data/tmp/t [10:27:10]$ git init
+Initialized empty Git repository in /data/tmp/t/.git/
+(ga-env-05) /data/tmp/t [10:27:54]$ touch README
+(ga-env-05) /data/tmp/t [10:27:59]$ git annex init
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
+(ga-env-05) /data/tmp/t [10:28:04]$ git annex add README 
+add README ok
+(recording state in git...)
+(ga-env-05) /data/tmp/t [10:28:10]$ git commit -m 'checking in README' .
+[master (root-commit) e3e6ecf] checking in README
+ 1 file changed, 1 insertion(+)
+ create mode 120000 README
+(ga-env-05) /data/tmp/t [10:28:19]$ mkdir /data/tmp/dirremote
+(ga-env-05) /data/tmp/t [10:29:09]$ git annex initremote dirremote type=directory directory=/data/tmp/dirremote encryption=none 
+initremote dirremote ok
+(recording state in git...)
+(ga-env-05) /data/tmp/t [10:30:00]$ git annex required dirremote anything
+required dirremote ok
+(recording state in git...)
+(ga-env-05) /data/tmp/t [10:30:37]$ git annex sync --content
+On branch master
+nothing to commit, working tree clean
+commit ok
+copy README (to dirremote...) ok
+(recording state in git...)
+(ga-env-05) /data/tmp/t [10:31:51]$ git annex drop .
+drop README ok
+(recording state in git...)
+(ga-env-05) /data/tmp/t [10:31:59]$ cd ..
+(ga-env-05) /data/tmp [10:32:00]$ git clone t t3
+Cloning into 't3'...
+done.
+(ga-env-05) /data/tmp [10:32:06]$ cd t3
+(ga-env-05) /data/tmp/t3 [10:32:08]$ git annex init
+init  (merging origin/git-annex origin/synced/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+ok
+(recording state in git...)
+(ga-env-05) /data/tmp/t3 [10:32:10]$ git annex sync --content
+On branch master
+Your branch is up to date with 'origin/master'.
+
+nothing to commit, working tree clean
+commit ok
+pull origin ok
+Enumerating objects: 20, done.
+Counting objects: 100% (19/19), done.
+Delta compression using up to 8 threads
+Compressing objects: 100% (8/8), done.
+Writing objects: 100% (10/10), 974 bytes | 974.00 KiB/s, done.
+Total 10 (delta 5), reused 0 (delta 0), pack-reused 0
+To /data/tmp/t
+   9726f90..f4f2f6c  git-annex -> synced/git-annex
+push origin ok
+(ga-env-05) /data/tmp/t3 [10:32:19]$ echo $?
+0
+(ga-env-05) /data/tmp/t3 [10:32:23]$ cat README
+cat: README: No such file or directory
+(ga-env-05) /data/tmp/t3 [10:32:26]$ 
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+git-annex is versatile and reliable, and reflects a crazy amount of work by @joeyh.   Thanks again for it!
+
+> I think the documentation is reasonably clear now, so [[done]] --[[Joey]]
diff --git a/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_1_500bc8f48ae80841e0db21ee0de76c50._comment b/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_1_500bc8f48ae80841e0db21ee0de76c50._comment
new file mode 100644
index 0000000000..c372a93e52
--- /dev/null
+++ b/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_1_500bc8f48ae80841e0db21ee0de76c50._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-03-30T16:51:53Z"
+ content="""
+This is expected. git annex sync --content only returns an error if copying annexed files to/from a remote failed. If there are no remotes configured or enabled, there is nothing to copy, so it returns success.
+"""]]
diff --git a/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_1_9581f8135c6eb2ed2135f83a266e5306._comment b/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_1_9581f8135c6eb2ed2135f83a266e5306._comment
new file mode 100644
index 0000000000..b968ee2376
--- /dev/null
+++ b/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_1_9581f8135c6eb2ed2135f83a266e5306._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-30T16:07:30Z"
+ content="""
+I don't think the `git-annex sync` documentation says in what situation
+it will exit nonzero, so the extent this is really a bug is debatable.
+
+The general rule is that, if git-annex looks at a file or other item,
+decides it needs to take some action, and then that action fails, it will
+later exit nonzero. And sync does behave that way: When it determines a
+file is not in any of the remotes it's syncing with, it does not try to
+download it from anywhere, so no action fails.
+
+The counterargument to that would be by analogy to `git-annex get`
+which does exit nonzero when no available remotes contain
+a file (because it acts on every file that's not already present).
+We could say that sync is currently behaving more like `git-annex get --from
+foo` which skips files not on the specified remote, and that it's
+doing it even when no particular remotes are specified, and that it would
+be better, when no particular remotes are specified, for it to behave like
+`git-annex get`. 
+
+I don't know if most users would come up with this analogy though..
+I also wonder if you would not be better off just using `git-annex get`
+if you want to check exit status based on if all files are present.
+"""]]
diff --git a/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_3_dbc8ad383c4968b1ab78ac86bab06329._comment b/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_3_dbc8ad383c4968b1ab78ac86bab06329._comment
new file mode 100644
index 0000000000..00a6af3e01
--- /dev/null
+++ b/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_3_dbc8ad383c4968b1ab78ac86bab06329._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2021-03-30T19:17:06Z"
+ content="""
+I guess the \"sync\" in `git-annex-sync` made me think of file synchronizers like `rsync`, which do bring in all remote files not currently local. Maybe just change the manpage to clarify that `git-annex-sync` only synchronizes with [[_enabled_|git-annex-enableremote]] remotes.
+"""]]
diff --git a/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_4_23a16e94a0f18126caa6cb2f94131277._comment b/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_4_23a16e94a0f18126caa6cb2f94131277._comment
new file mode 100644
index 0000000000..e8d972db4d
--- /dev/null
+++ b/doc/bugs/sync_--content_succeeds_w__47__o_fetching_all_files/comment_4_23a16e94a0f18126caa6cb2f94131277._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-04-01T16:36:11Z"
+ content="""
+It would be impossible to sync with a remote that is not enabled,
+so I don't know if that is a useful distinction to draw.
+
+Also, if a file is not present in any remotes yet either, syncing will
+not get it, and not fail, and leave the local repo without the file's
+content. And this is not happening because a remote is not enabled,
+but because there is no path to get the data from the repo that contains
+it.
+
+I did change the man page to say "The --content option causes the content of annexed files
+to also be uploaded and downloaded as necessary, to sync the content between the repository and its remotes."
+
+Which may be explcit enough to remove the ambiguity that surprised you,
+but I'm not sure if I've hit on the right wording.
+"""]]
diff --git a/doc/bugs/sync_-C_can_export_other_files.mdwn b/doc/bugs/sync_-C_can_export_other_files.mdwn
new file mode 100644
index 0000000000..db63c9d7c5
--- /dev/null
+++ b/doc/bugs/sync_-C_can_export_other_files.mdwn
@@ -0,0 +1,17 @@
+When an exporttree=yes remote has had a tree exported to it, but eg with
+`git-annex export master --to foo --fast`, so not all the files have been
+sent to it yet, `git-annex sync -Cfoo` will also export files in other
+directories to it.
+
+This seems like a bug, it ought to only export any files in the specified
+directory.
+
+Another way this can happen is `git-annex sync -Cfoo`, when file bar
+has changed. Currently this exports bar to the export remote, but does
+not send it to any other remotes, since it's not in directory foo.
+
+Also this affects `git-annex satisfy`, and other related commands too.
+--[[Joey]]
+
+> Decided to just document this behavior since there does not seem to be
+> any good alternative behavior. [[done]] --[[Joey]]
diff --git a/doc/bugs/sync_-C_can_export_other_files/comment_1_7a6ab3ee25f0d09df4d7478d26ea2d37._comment b/doc/bugs/sync_-C_can_export_other_files/comment_1_7a6ab3ee25f0d09df4d7478d26ea2d37._comment
new file mode 100644
index 0000000000..03193f7e13
--- /dev/null
+++ b/doc/bugs/sync_-C_can_export_other_files/comment_1_7a6ab3ee25f0d09df4d7478d26ea2d37._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-09-22T16:26:17Z"
+ content="""
+If files foo and bar have changed, and `git-annex sync -Cfoo` committed
+those changes and only exported foo to an exporttree remote, then that
+remote would end up with content that does not correspond to any git tree
+that the user has constructed.
+
+While it's possible for that to also happen when an export of a tree gets
+interrupted in the middle, git-annex recovers from that when the export is
+re-run. But here the user might have a workflow where they are only running
+that command.
+
+So this would be a new case, and to handle this case it seems it would have
+to dummy up a tree representing the changed foo and old bar, in order to
+record the export in the git-annex branch and sync it so other repos know
+what the content of the export remote is.
+
+So doing that is not feeling like an entirely good idea..
+
+I suppose the alternative would be for `git-annex sync -C` to not send
+anything to export remotes. But that also seems potentially confusing.
+(Especially as a behavior change.) If I've asked git-annex to sync with an
+exporttree remote, shouldn't it do it? Even if it has to do some additional
+transferring in the process.
+
+So it may be that the current behavior of sending additional files is better.
+"""]]
diff --git a/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking.mdwn b/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking.mdwn
new file mode 100644
index 0000000000..e596e8424b
--- /dev/null
+++ b/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking.mdwn
@@ -0,0 +1,218 @@
+### Please describe the problem.
+Sync / Assistant between a `source` and `transfer` repo results in zero copies for whereis, but data is available.
+
+
+### What steps will reproduce the problem?
+See a script below...
+
+``` sh
+#!/bin/sh
+
+TMP=$(mktemp -d)
+
+
+##########################################
+# Set up the repos
+##########################################
+
+
+###
+# Create working directories
+cd ${TMP}
+mkdir source transfer
+
+
+###
+# Set up the source repo
+cd ${TMP}/source
+git init
+git annex init source
+git-annex group here source
+git annex wanted here standard
+
+
+###
+# Set up the transfer repo
+# N.B. It can see the source repo
+cd ${TMP}/transfer
+git init
+git remote add source ${TMP}/source
+git annex init transfer
+git-annex group here transfer
+git annex wanted here \
+  'not (inallgroup=client and copies=client:1) and ((include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1)'
+
+
+##########################################
+# Add some files and run the assistant
+##########################################
+
+###
+# Make sure it works by adding some files to the source...
+cd ${TMP}/source
+date > file.1
+date > file.2
+date > file.3
+
+# Run the assistant in the source...
+(cd ${TMP}/source && \
+    git annex assistant && \
+    sleep 30 && \
+    git annex assistant --stop && \
+    git annex whereis file.*)
+# PASS: All files are in source.
+
+# Now run it in the transfer group
+(cd ${TMP}/transfer && \
+    git annex assistant && \
+    sleep 30 && \
+    git annex assistant --stop && \
+    git annex whereis file.*)
+# PASS: All files are in transfer
+
+# Check the source
+(cd ${TMP}/source && \
+    git annex whereis file.*)
+# FAIL: Only file.1 was updated to be in source.
+
+# whereis file.1 (1 copy)
+#        64b193e0-86f0-4349-b073-70af919ce628 -- transfer
+# ok
+# whereis file.2 (0 copies) failed
+# whereis file.3 (0 copies) failed
+# git-annex: whereis: 2 failed
+
+
+##########################################
+# Start to scratch head and ask 'Why?'
+##########################################
+
+##########
+# What's happening???
+
+cd ${TMP}/source && git annex sync
+# Source thinks it is updated - working tree clean
+
+cd ${TMP}/transfer && git annex sync
+# Transfer pulls from source, so run again
+git annex sync
+# OK... working tree clean
+
+
+# Check again
+cd ${TMP}/source && git annex whereis file.*
+# whereis file.1 (1 copy)
+#         64b193e0-86f0-4349-b073-70af919ce628 -- transfer
+# ok
+# whereis file.2 (0 copies) failed
+# whereis file.3 (0 copies) failed
+# git-annex: whereis: 2 failed
+
+cd ${TMP}/transfer && git annex whereis file.*
+# whereis file.1 (1 copy)
+#         64b193e0-86f0-4349-b073-70af919ce628 -- transfer [here]
+# ok
+# whereis file.2 (0 copies) failed
+# whereis file.3 (0 copies) failed
+# git-annex: whereis: 2 failed
+
+
+# HOWEVER...  Files are definitely in the transfer repo
+
+cd ${TMP}/source && cat file.*
+# cat: file.1: No such file or directory
+# cat: file.2: No such file or directory
+# cat: file.3: No such file or directory
+
+
+cd ${TMP}/transfer && cat file.*
+# Sun May 14 21:22:02 PDT 2017
+# Sun May 14 21:22:03 PDT 2017
+# Sun May 14 21:22:06 PDT 2017
+```
+
+
+
+### What version of git-annex are you using? On what operating system?
+
+#### Version:
+```
+git-annex version: 6.20170510
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.6.1 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: darwin x86_64
+```
+
+#### OS:
+MacOS 10.12.4, but seems to apply to Debian Jessie too.
+
+
+### Please provide any additional information below.
+
+Annex assistant daemon.log for `source` repo:
+
+``` sh
+[2017-05-15 14:11:24.150202] main: starting assistant version 6.20170510
+[2017-05-15 14:11:24.196597] Cronner: You should enable consistency checking to protect your data.
+(scanning...) [2017-05-15 14:11:24.257123] Watcher: Performing startup scan
+(started...)
+[2017-05-15 14:11:45.505855] Committer: Adding file.1 file.2 file.3
+add file.1 ok
+add file.2 ok
+add file.3 ok
+[2017-05-15 14:11:45.544277] Committer: Committing changes to git
+(recording state in git...)
+(recording state in git...)
+```
+
+Annex assistant daemon.log for `transfer` repo:
+
+``` sh
+[2017-05-15 14:12:09.127406] main: starting assistant version 6.20170510
+[2017-05-15 14:12:09.157611] Cronner: You should enable consistency checking to protect your data.
+[2017-05-15 14:12:09.177452] TransferScanner: Syncing with source
+(scanning...) [2017-05-15 14:12:09.210605] Watcher: Performing startup scan
+(started...)
+warning: no common commits
+From /Users/olaf/tmp/git-annex/play/bug-play/source
+ * [new branch]      git-annex     -> source/git-annex
+ * [new branch]      master        -> source/master
+ * [new branch]      synced/master -> source/synced/master
+(merging source/git-annex into git-annex...)
+(recording state in git...)
+
+
+Already up-to-date.
+[2017-05-15 14:12:10.256195] Committer: Committing changes to git
+(recording state in git...)
+(checksum...) [2017-05-15 14:12:10.425494] Transferrer: Downloaded file.1
+[2017-05-15 14:12:11.17664] Pusher: Syncing with source
+(recording state in git...)
+[2017-05-15 14:12:11.356447] Committer: Committing changes to git
+(recording state in git...)
+To /Users/olaf/tmp/git-annex/play/bug-play/source
+ * [new branch]      git-annex -> synced/git-annex
+(checksum...) [2017-05-15 14:12:11.428676] Transferrer: Downloaded file.2
+(checksum...) [2017-05-15 14:12:11.451457] Transferrer: Downloaded file.3
+drop source file.1 ok
+drop source file.2 ok
+drop source file.3 ok
+[2017-05-15 14:12:13.477636] Pusher: Syncing with source
+(recording state in git...)
+To /Users/olaf/tmp/git-annex/play/bug-play/source
+   825d3dd..60c96cb  git-annex -> synced/git-annex
+```
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes.  Love it.  Donated.  Have been using it for years.  Recommend it and get(/force) my collaborators to use it.  ;-)
+
+> Since this bug involved direct mode, and direct mode was known to be
+> rather buggy and has been removed, I think it's best to close it.
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_1_562cf3ab3398c1ef874c0bfe5d89e47b._comment b/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_1_562cf3ab3398c1ef874c0bfe5d89e47b._comment
new file mode 100644
index 0000000000..7511c36898
--- /dev/null
+++ b/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_1_562cf3ab3398c1ef874c0bfe5d89e47b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="leavingchicago@c04c893e78d1c4c76cb3e32b5c227cf42bbf7682"
+ nickname="leavingchicago"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="Related..."
+ date="2017-05-15T04:43:44Z"
+ content="""
+I think this bug is related to the problems that I'm having with [/forum/Get source group to automatically drop with assistant](https://git-annex.branchable.com/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/)
+
+"""]]
diff --git a/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_2_f686273c6be899d2a8bbaabd03a47fbf._comment b/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_2_f686273c6be899d2a8bbaabd03a47fbf._comment
new file mode 100644
index 0000000000..34ed9f1d7d
--- /dev/null
+++ b/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_2_f686273c6be899d2a8bbaabd03a47fbf._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-06-09T17:25:23Z"
+ content="""
+I have not had any luck with reproducing the problem, using
+your script, on Debian unstable. The transfer repo gets
+the file contents and both it and the source repo knows where they are.
+
+Do you see the same behavior if, rather than running the assistant
+for 30 seconds, you run `git annex sync --content` ?
+
+Are you using git-annex in direct mode and/or on an unusual filesystem?
+"""]]
diff --git a/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_3_fd518d0601587dc5c718944d0b6f51fc._comment b/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_3_fd518d0601587dc5c718944d0b6f51fc._comment
new file mode 100644
index 0000000000..79e388a4dc
--- /dev/null
+++ b/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_3_fd518d0601587dc5c718944d0b6f51fc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-06-09T17:33:17Z"
+ content="""
+I tried the script with `git annex direct` added at initialization,
+and didn't see the problem as described, but the assistant
+did fail to get the content into the transfer repo at all
+when using direct mode. `git annex sync --content` had no difficulty.
+"""]]
diff --git a/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_4_a6074b68754b0d773385a1e406043952._comment b/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_4_a6074b68754b0d773385a1e406043952._comment
new file mode 100644
index 0000000000..9eb06cf992
--- /dev/null
+++ b/doc/bugs/sync_claims_data_loss_but_seems_to_just_lose_tracking/comment_4_a6074b68754b0d773385a1e406043952._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="olaf"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="comment 4"
+ date="2017-06-22T04:55:35Z"
+ content="""
+So, you're suggesting manually running `git annex sync --content`?  I can `cron` that up, so I can live with it.
+
+Do you need any more info to identify the issue you found with the assistant?
+"""]]
diff --git a/doc/bugs/sync_does_not_merge_after_branch_rollback.mdwn b/doc/bugs/sync_does_not_merge_after_branch_rollback.mdwn
new file mode 100644
index 0000000000..5ecc54a4c7
--- /dev/null
+++ b/doc/bugs/sync_does_not_merge_after_branch_rollback.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+I did an interactive rebase of the git-annex branch and rolled back the remote git-annex branch. Afterwards `git annex sync` did not merge the remote git-annex branch.
+
+### What steps will reproduce the problem?
+
+```
+git init a
+cd a
+git annex init
+git commit -m . --allow-empty
+
+cd ..
+git clone a b
+cd b
+git annex init
+git remote rename origin a
+cd ../a
+git annex fsck
+cd ../b
+git annex sync
+
+git push a :synced/git-annex
+git push -f a 'git-annex^2:git-annex'
+git branch -f git-annex 'git-annex^1'
+git annex sync
+```
+
+After the second sync, `a/git-annex` did not get merged.
+
+### What version of git-annex are you using? On what operating system?
+
+8.20211011 linux
+
diff --git a/doc/bugs/sync_does_not_merge_after_branch_rollback/comment_1_8c5f4787a6156802d00cfad1f7d2ee31._comment b/doc/bugs/sync_does_not_merge_after_branch_rollback/comment_1_8c5f4787a6156802d00cfad1f7d2ee31._comment
new file mode 100644
index 0000000000..d483e881e3
--- /dev/null
+++ b/doc/bugs/sync_does_not_merge_after_branch_rollback/comment_1_8c5f4787a6156802d00cfad1f7d2ee31._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-10-27T17:02:18Z"
+ content="""
+This kind of thing generally doesn't work because you have not updated
+.git/annex/index, so the next time git-annex updates the git-annex branch
+after that branch has been manually modified, it merges in the contents of
+that index, which tends to roll back the modifications. So I am doubtful
+that whatever you were trying to do would really have worked.
+
+What is happening here is that .git/annex/mergedrefs is used to keep 
+track of refs that have previously been merged into the git-annex branch.
+And it contains the hash of a/git-annex. So, git-annex knows it's merged
+that before and avoids merging it again. But of course, you fooled it by
+forcing the local git-annex branch to back before that merge happened.
+
+If you delete .git/annex/mergedrefs file, it will merge. Or the problem
+will self-correct after some more changes to the git-annex branch happen in
+the a repo, causing a/git-annex to get ahead of the previous merge point.
+
+The mergedrefs file is a speed hack, see
+[[!commit 154c9398309b52789bf15f6f6204cb22b0ffec82]].
+
+I suppose this problem could be avoided by recording the sha of the
+git-annex branch that the mergedrefs were merged into, and ignoring
+mergedrefs if the branch sha is not the same. Although it would then need to
+advance that recorded sha every time it modified the git-annex branch,
+which would be extra work.
+"""]]
diff --git a/doc/bugs/sync_does_not_propagate_forgetfulness.mdwn b/doc/bugs/sync_does_not_propagate_forgetfulness.mdwn
new file mode 100644
index 0000000000..ebc018cbcb
--- /dev/null
+++ b/doc/bugs/sync_does_not_propagate_forgetfulness.mdwn
@@ -0,0 +1,35 @@
+After a `git-annex forget`, syncing with a remote that still has the
+forgotten data in its git-annex branch merges that data right back in.
+
+Reproduction script:
+
+	chmod -R +w bench 2>/dev/null
+	rm -rf bench 2>/dev/null
+	mkdir bench
+	cd bench
+	git init a
+	cd a
+	git-annex init
+	touch foo
+	git-annex add foo
+	git commit -m add
+	cd ..
+	git clone a b
+	cd b
+	git-annex get
+	git-annex drop
+	git-annex get
+	git-annex drop
+	cd ../a
+	git-annex sync
+	git-annex forget --force
+	git-annex sync
+	git-annex log foo
+	cd ../b
+	git-annex sync
+	cd ../a
+	git-annex log foo
+
+--[[Joey]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/sync_does_not_propagate_forgetfulness/comment_1_acc9744be183c297c6410f9b0a30b46b._comment b/doc/bugs/sync_does_not_propagate_forgetfulness/comment_1_acc9744be183c297c6410f9b0a30b46b._comment
new file mode 100644
index 0000000000..2646ff3212
--- /dev/null
+++ b/doc/bugs/sync_does_not_propagate_forgetfulness/comment_1_acc9744be183c297c6410f9b0a30b46b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-07T17:49:37Z"
+ content="""
+Reversion introduced in [[!commit 2eadb6cd68073a905e8ff32cc8093a43d0b05c81]].
+Parsing of the transitions log silently failed, so all propagation of
+transitions was broken. 
+"""]]
diff --git a/doc/bugs/sync_does_not_sync_content_with_new_remote_on_first_run.mdwn b/doc/bugs/sync_does_not_sync_content_with_new_remote_on_first_run.mdwn
new file mode 100644
index 0000000000..8de0d7c637
--- /dev/null
+++ b/doc/bugs/sync_does_not_sync_content_with_new_remote_on_first_run.mdwn
@@ -0,0 +1,23 @@
+	joey@darkstar:~/tmp/bench/me>git init ../other
+	Initialized empty Git repository in /home/joey/tmp/bench/other/.git/
+	joey@darkstar:~/tmp/bench/me>git remote add other ../other
+	joey@darkstar:~/tmp/bench/me>ls
+	joey@darkstar:~/tmp/bench/me>date > foo
+	joey@darkstar:~/tmp/bench/me>git-annex add foo
+
+With this setup, `git-annex sync --content` does not send foo to other
+the first time run. However, on the second run it, does.
+
+If the other repo had `git-annex init` ran in it first, it would sync content
+to it on the first run.
+
+Auto-init only happens once the git-annex branch gets pushed to the remote
+and git-annex enumerates that remote.
+So after the first sync in this situation, the remote has a synced/git-annex 
+branch, but no uuid yet. The second sync then auto-inits.
+
+To fix this, sync could re-enumerate remotes after pushing, I suppose. But
+re-enumerating remotes is some work so it would need to do it only for ones that
+have no uuid. 
+
+Saw this happening in yann's talk. --[[Joey]]
diff --git a/doc/bugs/sync_does_not_sync_content_with_new_remote_on_first_run/comment_1_c1df7f51ac724400dbef664ce10784a8._comment b/doc/bugs/sync_does_not_sync_content_with_new_remote_on_first_run/comment_1_c1df7f51ac724400dbef664ce10784a8._comment
new file mode 100644
index 0000000000..4458913735
--- /dev/null
+++ b/doc/bugs/sync_does_not_sync_content_with_new_remote_on_first_run/comment_1_c1df7f51ac724400dbef664ce10784a8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Similar to initremote type=git"
+ date="2023-12-07T08:31:08Z"
+ content="""
+Cool, this would reduce surprises for sure! 😀
+
+On that note, IIRC `initremote type=git` straight up refuses to proceed if the remote does not have a UUID (i.e. has had `git annex init` run in it). Might be worth auto-init-ing here as well when you're already at it.
+"""]]
diff --git a/doc/bugs/sync_with_export_remote_deletes_files_from_it_when_ran_in_other_than_tracking_branch.mdwn b/doc/bugs/sync_with_export_remote_deletes_files_from_it_when_ran_in_other_than_tracking_branch.mdwn
new file mode 100644
index 0000000000..c5621e674b
--- /dev/null
+++ b/doc/bugs/sync_with_export_remote_deletes_files_from_it_when_ran_in_other_than_tracking_branch.mdwn
@@ -0,0 +1,18 @@
+	git-annex initremote d type=directory directory=../d exporttree=yes importtree=yes encryption=none
+	git config remote.d.annex-tracking-branch master
+	date > ../d/foo
+	git checkout -b bar
+	git-annex sync --content d
+
+This will import foo from d, but then it unexports foo from d.
+
+Not quite data loss, because it does honor numcopies and the local copy
+remains. But bad. 
+
+The problem seems to be that it assumes it's merged d/master into master, but
+that does not happen since master is not the current branch. And so it then
+updates d to look like master. --[[Joey]]
+
+> [[fixed|done]] by avoiding updating export remotes when
+> the current branch tree is not the same as the tracking branch tree.
+> --[[Joey]]
diff --git a/doc/bugs/tahoe_remote_has_no_repair.mdwn b/doc/bugs/tahoe_remote_has_no_repair.mdwn
new file mode 100644
index 0000000000..1f34767a8e
--- /dev/null
+++ b/doc/bugs/tahoe_remote_has_no_repair.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+
+The tahoe-lafs remote has no built-in way to perform the repair operation.
+This results to data loss if expiration is enabled on the Tahoe grid.
+
+For the current tahoe-lafs release (1.10.0), the only way storage space is freed
+is via garbage collection. Garbage collection removes shares whose lease has expired.
+Data loss will occur if leases are not periodically renewed via
+"tahoe repair --add-lease WRITECAP".
+
+The current implementation of the Tahoe remote in git-annex does not offer a way to
+run lease renewal, and cannot be used on grids where GC is enabled. (GC is not enabled
+in the default configuration, but on private grids it is a sensible option.)
+
+One way renewal could be made easier to do is to add the uploaded files to a directory
+in Tahoe, so that the leases could be easily updated if the directory writecap is known,
+without needing to go through the full list of writecaps for each file stored.
+
+### What steps will reproduce the problem?
+
+1. Use tahoe remote on a tahoe grid where GC is enabled.
+
+2. After GC expiration period, data loss ensues.
+
+### What version of git-annex are you using? On what operating system?
+
+Seems to affect current git master (as of 2014-08-24).
diff --git a/doc/bugs/tasty_test_limiting_broken_by_concurrency.mdwn b/doc/bugs/tasty_test_limiting_broken_by_concurrency.mdwn
new file mode 100644
index 0000000000..d557dac36e
--- /dev/null
+++ b/doc/bugs/tasty_test_limiting_broken_by_concurrency.mdwn
@@ -0,0 +1,19 @@
+The changes to make `git-annex test` concurrent have
+broken using eg `git-annex test -p 'concurrent get of dup key regression'`
+
+It looks like the repo setup test is not being run, even though it's
+supposed to be a dependency of the test it was limited to.
+--[[Joey]]
+
+> Oh, that seems to be a limitation of tasty. From its docs:
+	
+	If Test B depends on Test A, remember that either of them may be 
+	filtered out using the --pattern option. Collecting the dependency
+	info happens after filtering. Therefore, if Test A is filtered out,
+	Test B will run unconditionally, and if Test B is filtered out,
+	it simply won't run.
+
+> This works: `git-annex test -p '/concurrent get of dup key regression/ || /Init Tests/'`
+> 
+> Ok, I was able to work around this by having git-annex test add the latter
+> pattern automatically. [[done]] --[[Joey]]
diff --git a/doc/bugs/tasty_test_limiting_broken_by_concurrency/comment_1_e043a71b60999cf97bd872d8b32fcac9._comment b/doc/bugs/tasty_test_limiting_broken_by_concurrency/comment_1_e043a71b60999cf97bd872d8b32fcac9._comment
new file mode 100644
index 0000000000..592b8a45fa
--- /dev/null
+++ b/doc/bugs/tasty_test_limiting_broken_by_concurrency/comment_1_e043a71b60999cf97bd872d8b32fcac9._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 1"
+ date="2022-05-24T02:46:17Z"
+ content="""
+Well done. Btw if somebody (like me) wonders why their tasty awk patterns '/like this/' don't work with `git-annex test -p`
+in Windows Git Bash, one has to remember that Git Bash is based on Cygwin/Msys and there's a Unix -> Windows
+path conversion at work. You can stop that conversion by prepending a space to the awk pattern ' /like this/'
+or by setting the env var MSYS_NO_PATHCONV=1. So basically the above should be formulated as follows in this arguably hobbled environment:
+
+[[!format sh \"\"\"
+$ MSYS_NO_PATHCONV=1 git-annex test -p '/concurrent get of dup key regression/ || /Init Tests/'
+\"\"\"]]
+
+"""]]
diff --git a/doc/bugs/test__58___posix__95__spawnp_broken_10_on_darwin.mdwn b/doc/bugs/test__58___posix__95__spawnp_broken_10_on_darwin.mdwn
new file mode 100644
index 0000000000..81fef53a53
--- /dev/null
+++ b/doc/bugs/test__58___posix__95__spawnp_broken_10_on_darwin.mdwn
@@ -0,0 +1,25 @@
+### Please describe the problem.
+
+We observer error in our CI:
+
+```
+      ./Test/Framework.hs:86:
+      addurl on file:///private/tmp/nix-build-git-annex-10.20231129.drv-0/git-annex-10.20231129-src/.t/25/tmprepo0/myurl failed with unexpected exit code (transcript follows)
+      addurl file:///private/tmp/nix-build-git-annex-10.20231129.drv-0/git-annex-10.20231129-src/.t/25/tmprepo0/myurl 
+      git-annex: security: createProcess: posix_spawnp: does not exist (No such file or directory)
+      failed
+      addurl: 1 failed
+```
+
+https://github.com/cachix/pre-commit-hooks.nix/actions/runs/8355807260/job/22871621632
+
+### What steps will reproduce the problem?
+
+build git-annex and run tests on darwin
+
+### What version of git-annex are you using? On what operating system?
+
+10.20231129
+
+
+
diff --git a/doc/bugs/test__58___posix__95__spawnp_broken_10_on_darwin/comment_1_5741fabaa561b81989cc176e9acb4a99._comment b/doc/bugs/test__58___posix__95__spawnp_broken_10_on_darwin/comment_1_5741fabaa561b81989cc176e9acb4a99._comment
new file mode 100644
index 0000000000..ecf25cd9c3
--- /dev/null
+++ b/doc/bugs/test__58___posix__95__spawnp_broken_10_on_darwin/comment_1_5741fabaa561b81989cc176e9acb4a99._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-03-22T14:47:02Z"
+ content="""
+This error message seems to indicate that git-annex tried to run a program
+named "security", which does not exist.
+
+I can reproduce the error message like so:
+
+	ghci> createProcess (proc "security" [])
+	*** Exception: security: createProcess: posix_spawnp: does not exist (No such file or directory)
+
+Since git-annex definitely does not normally try to run a program named
+"security" -- it doesn't even contain any String with that value -- I am
+puzzled by what could be causing it to do so. My best guess is something in
+your git configuration might be set. For example:
+
+	joey@darkstar:~/tmp/xx>git config annex.freezecontent-command security
+	joey@darkstar:~/tmp/xx>git-annex addurl file:///bin/sh
+	addurl file:///bin/sh
+	(to _bin_sh) sh: 1: security: not found
+
+Which well, rules out that particular git config, but there are several git
+configs that specify a command to run, so some other one.
+
+However, the test suite also runs with `GIT_CONFIG_NOSYSTEM` set, so git won't read
+the system gitconfig file, and it also sets HOME to a temp directory to avoid reading
+`~/.gitconfig`. So normally even such a git config setting should not affect the test suite.
+"""]]
diff --git a/doc/bugs/test__58___posix__95__spawnp_broken_10_on_darwin/comment_2_3fb2b47ade727a1bc6a99120b68d98b7._comment b/doc/bugs/test__58___posix__95__spawnp_broken_10_on_darwin/comment_2_3fb2b47ade727a1bc6a99120b68d98b7._comment
new file mode 100644
index 0000000000..de30ce0b65
--- /dev/null
+++ b/doc/bugs/test__58___posix__95__spawnp_broken_10_on_darwin/comment_2_3fb2b47ade727a1bc6a99120b68d98b7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Happens on nix on MacOS as well"
+ date="2024-04-13T15:51:54Z"
+ content="""
+I just had the same problem. An `addurl` test failing while building on MacOS with `nix-shell -p git-annex`. I recorded a video of it coincidentally. I don't know what's with the `security` program it tries to call. I was using a MacOS VM via [Docker-OSX](https://github.com/sickcodes/Docker-OSX?tab=readme-ov-file#big-sur-).
+"""]]
diff --git a/doc/bugs/test_prop__95__relPathDirToFileAbs__95__basics_fails_again.mdwn b/doc/bugs/test_prop__95__relPathDirToFileAbs__95__basics_fails_again.mdwn
new file mode 100644
index 0000000000..ddf04529cf
--- /dev/null
+++ b/doc/bugs/test_prop__95__relPathDirToFileAbs__95__basics_fails_again.mdwn
@@ -0,0 +1,55 @@
+### Please describe the problem.
+
+There was this springy little one that sprung -- just like a seedling :)
+
+Running the test QuickCheck.prop_relPathDirToFileAbs_basics fails (again) in a particular case (but only occasionally).
+
+Running the following fails:
+
+[[!format sh """
+jkniiv@AINESIS MINGW64 /c/annx
+$ ./git-annex test --jobs=1 -p QuickCheck.prop_relPathDirToFileAbs_basics --quickcheck-replay=586868 2>&1 | tee git-annex.test--p-QuickCheck_prop_relPathDirToFileAbs_basics.LOG~201
+Tests
+  QuickCheck
+    prop_relPathDirToFileAbs_basics: FAIL (0.03s)
+      *** Failed! Falsified (after 711 tests):
+      TestableFilePath {fromTestableFilePath = ":/"}
+      Use --quickcheck-replay=586868 to reproduce.
+
+1 out of 1 tests failed (0.03s)
+
+All 0 tests passed (0.00s)
+
+All 0 tests passed (0.01s)
+
+All 0 tests passed (0.00s)
+  Test subprocesses exited with unexpected exit codes: [ExitSuccess,ExitSuccess,ExitSuccess]
+
+# End of transcript.
+"""]]
+
+If you remove the option `--quickcheck-replay=586868`, the test usually passes.
+
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20220223-g8f6b52b77
+build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+"""]]
+
+Windows 10 version 21H2 (build 19044.1586), 64 bit.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Git Annex is great. I use it several times a week with my multigigabyte backups, where it gives structure to my image-based backup routines, so you could say I'm a believer. :)
+
+[[!meta author=jkniiv]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/testremote_failure_with_s3.mdwn b/doc/bugs/testremote_failure_with_s3.mdwn
new file mode 100644
index 0000000000..5cfa419b5f
--- /dev/null
+++ b/doc/bugs/testremote_failure_with_s3.mdwn
@@ -0,0 +1,79 @@
+### Please describe the problem.
+[[git-annex-testremote]] reports a failure with a newly created AWS S3 bucket
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+(master_env_v163_py36) 17:17  [diagnostic-guide-design-analysis] $ git annex testremote --fast s3-ilya-dgda
+...
+    remove export when not present:                    Remote is configured to use versioning, but no S3 version ID is recorded for th\
+is key, so it cannot safely be modified.
+FAIL
+      ./Command/TestRemote.hs:240:
+      failed
+
+
+(master_env_v163_py36) 17:17  [diagnostic-guide-design-analysis] $ git annex info --fast s3-ilya-dgda
+uuid: 6eb1eba8-1bd0-48f9-b407-50872099ae4f
+description: [s3-ilya-dgda]
+trust: semitrusted
+remote: s3-ilya-dgda
+cost: 250.0
+type: S3
+creds: embedded in git repository (gpg encrypted)
+bucket: ilya-dgda
+endpoint: s3.amazonaws.com
+port: 80
+protocol: http
+storage class: STANDARD
+partsize: unlimited
+public: no
+versioning: yes
+encryption: hybrid (to gpg keys: 1044376D260343BB)
+chunking: 33.55 megabyteschunks
+
+""]]
+
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+(master_env_v163_py36) 17:14  [diagnostic-guide-design-analysis] $ git annex version
+git-annex version: 7.20191009-g02c955b
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sql\
+ite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_2\
+24 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE\
+2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224\
+ BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 7
+(master_env_v163_py36) 17:17  [diagnostic-guide-design-analysis] $ uname -a
+Linux ip-172-31-91-26.ec2.internal 4.14.146-119.123.amzn2.x86_64 #1 SMP Mon Sep 23 16:58:43 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
+(master_env_v163_py36) 17:17  [diagnostic-guide-design-analysis] $
+
+"""]]
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+    remove export when not present:                    Remote is configured to use versioning, but no S3 version ID is recorded for th\
+is key, so it cannot safely be modified.
+FAIL
+      ./Command/TestRemote.hs:240:
+      failed
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/bugs/testremote_is_not_honoring_--backend.mdwn b/doc/bugs/testremote_is_not_honoring_--backend.mdwn
new file mode 100644
index 0000000000..b04c304553
--- /dev/null
+++ b/doc/bugs/testremote_is_not_honoring_--backend.mdwn
@@ -0,0 +1,41 @@
+### Please describe the problem.
+
+I am running `testremote` on a windows CI system to test a special remote implementation for dataverse.org. I run into this error:
+
+```
+git-annex: MoveFileEx "C:\\DLTMP\\ran2133" Just ".git\\annex\\objects\\f76\\373\\SHA256E-s1048576--813fea02438e9569e6222f802958fcd89bee742d06ffe9aabe27fd940ef01196.this-is-a-test-key\\SHA256E-s1048576--813fea02438e9569e6222f802958fcd89bee742d06ffe9aabe27fd940ef01196.this-is-a-test-key": does not exist (The system cannot find the path specified.)
+```
+
+I suspect this could be a path-length issue (the system reports a max length of 285, and the relative path given above is already 230 chars.
+
+I thought to run `git annex testremote --backend=MD5E` instead, to shorten the key length, but this options is not honored (enough), the error showing a SHA256 key remains the same.
+
+`testremote` man page says "Also the git-annex-common-options(1) can be used." and `--backend` is explicitly listed in the help output, hence I assumed this should work.
+
+
+### What steps will reproduce the problem?
+
+It happens when running the https://github.com/datalad/datalad-dataverse tests on a windows appveyor worker. Running on a crippled FS is not enough to trigger the initial `testremote` error, it only happens on windows proper. However, I assume that `--backend` not having the effect that I assumed it should have, is not platform specific.
+
+Here is a demo test log: https://ci.appveyor.com/project/mih/datalad-dataverse/builds/44079592/job/b38woai0ekmq7bn5#L856
+
+The corresponding datalad issue is https://github.com/datalad/datalad-dataverse/issues/127
+
+
+### What version of git-annex are you using? On what operating system?
+
+CI used
+
+- annex: 8.20211117-gc3af94eff
+- git: 2.37.0.windows.1
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+All the time! Sorry to mostly show up when there is an issue!
+
+[[!tag projects/datalad]]
+
+[[!meta title="testremote failure on windows due to long filename issues"]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/testremote_is_not_honoring_--backend/comment_1_2b119f8bce39266630dd7c0f4d8add98._comment b/doc/bugs/testremote_is_not_honoring_--backend/comment_1_2b119f8bce39266630dd7c0f4d8add98._comment
new file mode 100644
index 0000000000..c14740668a
--- /dev/null
+++ b/doc/bugs/testremote_is_not_honoring_--backend/comment_1_2b119f8bce39266630dd7c0f4d8add98._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Recent version tested"
+ date="2022-07-06T12:18:36Z"
+ content="""
+The behavior is the same for the more recent git-annex 10.20220624-g17e4081d4
+"""]]
diff --git a/doc/bugs/testremote_is_not_honoring_--backend/comment_2_f804c33243606cab4495238511e59743._comment b/doc/bugs/testremote_is_not_honoring_--backend/comment_2_f804c33243606cab4495238511e59743._comment
new file mode 100644
index 0000000000..dc1c8d1198
--- /dev/null
+++ b/doc/bugs/testremote_is_not_honoring_--backend/comment_2_f804c33243606cab4495238511e59743._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-07-12T16:50:16Z"
+ content="""
+Actually testremote will not accept --backend in current master, since that
+is no longer a global option and is accepted only by commands that can
+actually use it.
+
+testremote cannot support an arbitrary backend here, because it needs to
+generate a test key that cannot possibly be used for real data. The only
+backend that has a way implemented to do that is SHA256. It would not,
+for example, be possible to make the WORM backend support that, since every
+possible WORM key could be used by real data.
+
+It would be possible to add support for --backend=MD5 and have it reject
+other backends. But this does not strike me as solving the real problem.
+
+Also, in [[bugs/tests_fail_on_windows:_retrieveKeyFile_resume]]
+I ran into this same problem, when `git-annex test` was ran, and
+worked around it by disabling that part of the test suite on windows.
+If this is fixed, it would be worth re-enabling that, although it may have
+also been failing for other reasons on windows.
+"""]]
diff --git a/doc/bugs/testremote_is_not_honoring_--backend/comment_3_1261222f79d9dbc8cf92f6466361e113._comment b/doc/bugs/testremote_is_not_honoring_--backend/comment_3_1261222f79d9dbc8cf92f6466361e113._comment
new file mode 100644
index 0000000000..9915571ebe
--- /dev/null
+++ b/doc/bugs/testremote_is_not_honoring_--backend/comment_3_1261222f79d9dbc8cf92f6466361e113._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-07-12T17:42:51Z"
+ content="""
+ghc's IO manager tries to support Windows long paths by normalizing to
+an UNC-style path in many system calls. However, when git-annex calls
+rename, on windows that ends up in Win32's moveFileEx (via unix-compat),
+and that does not do UNC-style normalization. And given the description of
+the Win32 package, I think it's intended to pass data directly through
+to the API without anything fancy.
+
+System.Directory.renamePath could be used instead of Win32. 
+While it still uses Win32 moveFileEx, it first does an UNC-style
+normalization. Filed an issue:
+<https://github.com/jacobstanley/unix-compat/issues/56>
+
+Rather than waiting for that to be fixed, I've made git-annex
+use System.Directory.renamePath instead itself. But I don't know
+if it will be enough to make testremote work, or if it will fall over
+on a later operation on the same too-long path.
+getFileStatus/getSymbolicLinkStatus seem like the main things in
+unix-compat that would still be a problem.
+"""]]
diff --git a/doc/bugs/testremote_is_not_honoring_--backend/comment_4_b6b4e0b7446f445591ac617e28e249e3._comment b/doc/bugs/testremote_is_not_honoring_--backend/comment_4_b6b4e0b7446f445591ac617e28e249e3._comment
new file mode 100644
index 0000000000..181fe8c92c
--- /dev/null
+++ b/doc/bugs/testremote_is_not_honoring_--backend/comment_4_b6b4e0b7446f445591ac617e28e249e3._comment
@@ -0,0 +1,245 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Update for git-annex 10.20230227-ga206cdddb4"
+ date="2023-02-28T15:35:50Z"
+ content="""
+Sorry for the long silence. Coming back to this issue I find the behavior changed, but not sufficiently to get the test suite to run in full on windows.
+
+I ran `git annex testremote --fast` on Windows `msys_nt-10.0-17763` with git-annex 10.20230227-ga206cdddb4 and git 2.38.1.windows.1
+
+[[!toggle  id=\"ipsum\" text=\"Show test output\"]]
+
+[[!toggleable  id=\"ipsum\" text=\"\"\"
+```
+[00:14:23] E             unavailable remote
+[00:14:23] E               removeKey:                                       OK (0.02s)
+[00:14:23] E               storeKey:                                        OK
+[00:14:23] E               checkPresent:                                    OK
+[00:14:23] E               retrieveKeyFile:                                 OK (0.03s)
+[00:14:23] E               retrieveKeyFileCheap:                            OK
+[00:14:23] E             key size Just 1048576; remote chunksize=0 encryption=none
+[00:14:23] E               removeKey when not present:                      OK (2.53s)
+[00:14:23] E               present False:                                   OK (0.31s)
+[00:14:23] E               storeKey:                                        FAIL
+[00:14:23] E                 Exception: content not available to send
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048576; remote chunksize=0 encryption=none.storeKey\"' to rerun this test only.
+[00:14:23] E               present True:                                    FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048576; remote chunksize=0 encryption=none.present True\"' to rerun this test only.
+[00:14:23] E               storeKey when already present:                   FAIL
+[00:14:23] E                 Exception: content not available to send
+[00:14:23] E                 Use -p '/key size Just 1048576; remote chunksize=0 encryption=none.storeKey when already present/' to rerun this test only.
+[00:14:23] E               present True:                                    FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048576; remote chunksize=0 encryption=none.present True\"' to rerun this test only.
+[00:14:23] E               retrieveKeyFile:                                 FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048576; remote chunksize=0 encryption=none.retrieveKeyFile\"' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               retrieveKeyFile resume from 0:                   FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '/key size Just 1048576; remote chunksize=0 encryption=none.retrieveKeyFile resume from 0/' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               retrieveKeyFile resume from 33%:                 FAIL
+[00:14:23] E                 Exception: .git\annex\objects\86a\533\SHA256E-s1048576--38d246a8a1798726446526c42d4603e4d4ceecc7a2030b774c4bfb89588a3591.this-is-a-test-key\SHA256E-s1048576--38d246a8a179
+8726446526c42d4603e4d4ceecc7a2030b774c4bfb89588a3591.this-is-a-test-key: openBinaryFile: does not exist (No such file or directory)
+[00:14:23] E                 Use -p '/key size Just 1048576; remote chunksize=0 encryption=none.retrieveKeyFile resume from 33%/' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               retrieveKeyFile resume from end:                 FAIL (0.07s)
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '/key size Just 1048576; remote chunksize=0 encryption=none.retrieveKeyFile resume from end/' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               removeKey when present:                          OK
+[00:14:23] E               present False:                                   OK
+[00:14:23] E             key size Just 1048576; remote chunksize=0 encryption=shared
+[00:14:23] E               removeKey when not present:                      OK (2.61s)
+[00:14:23] E               present False:                                   OK (0.31s)
+[00:14:23] E               storeKey:                                        FAIL
+[00:14:23] E                 Exception: content not available to send
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048576; remote chunksize=0 encryption=shared.storeKey\"' to rerun this test only.
+[00:14:23] E               present True:                                    FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048576; remote chunksize=0 encryption=shared.present True\"' to rerun this test only.
+[00:14:23] E               storeKey when already present:                   FAIL
+[00:14:23] E                 Exception: content not available to send
+[00:14:23] E                 Use -p '/key size Just 1048576; remote chunksize=0 encryption=shared.storeKey when already present/' to rerun this test only.
+[00:14:23] E               present True:                                    FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048576; remote chunksize=0 encryption=shared.present True\"' to rerun this test only.
+[00:14:23] E               retrieveKeyFile:                                 FAIL (0.01s)
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048576; remote chunksize=0 encryption=shared.retrieveKeyFile\"' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               retrieveKeyFile resume from 0:                   FAIL (0.05s)
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '/key size Just 1048576; remote chunksize=0 encryption=shared.retrieveKeyFile resume from 0/' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               retrieveKeyFile resume from 33%:                 FAIL
+[00:14:23] E                 Exception: .git\annex\objects\86a\533\SHA256E-s1048576--38d246a8a1798726446526c42d4603e4d4ceecc7a2030b774c4bfb89588a3591.this-is-a-test-key\SHA256E-s1048576--38d246a8a1798726446526c42d4603e4d4ceecc7a2030b774c4bfb89588a3591.this-is-a-test-key: openBinaryFile: does not exist (No such file or directory)
+[00:14:23] E                 Use -p '/key size Just 1048576; remote chunksize=0 encryption=shared.retrieveKeyFile resume from 33%/' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               retrieveKeyFile resume from end:                 FAIL (0.08s)
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '/key size Just 1048576; remote chunksize=0 encryption=shared.retrieveKeyFile resume from end/' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               removeKey when present:                          OK
+[00:14:23] E               present False:                                   OK
+[00:14:23] E             key size Just 1048575; remote chunksize=0 encryption=none
+[00:14:23] E               removeKey when not present:                      OK
+[00:14:23] E               present False:                                   OK
+[00:14:23] E               storeKey:                                        FAIL
+[00:14:23] E                 Exception: content not available to send
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048575; remote chunksize=0 encryption=none.storeKey\"' to rerun this test only.
+[00:14:23] E               present True:                                    FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048575; remote chunksize=0 encryption=none.present True\"' to rerun this test only.
+[00:14:23] E               storeKey when already present:                   FAIL
+[00:14:23] E                 Exception: content not available to send
+[00:14:23] E                 Use -p '/key size Just 1048575; remote chunksize=0 encryption=none.storeKey when already present/' to rerun this test only.
+[00:14:23] E               present True:                                    FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048575; remote chunksize=0 encryption=none.present True\"' to rerun this test only.
+[00:14:23] E               retrieveKeyFile:                                 FAIL (0.03s)
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048575; remote chunksize=0 encryption=none.retrieveKeyFile\"' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               retrieveKeyFile resume from 0:                   FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '/key size Just 1048575; remote chunksize=0 encryption=none.retrieveKeyFile resume from 0/' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               retrieveKeyFile resume from 33%:                 FAIL
+[00:14:23] E                 Exception: .git\annex\objects\8c4\c61\SHA256E-s1048575--79c930fcd7d08355513f158bbf82532eb6a25d5c8688f4504ac1e240e35e7dc5.this-is-a-test-key\SHA256E-s1048575--79c930fcd7d08355513f158bbf82532eb6a25d5c8688f4504ac1e240e35e7dc5.this-is-a-test-key: openBinaryFile: does not exist (No such file or directory)
+[00:14:23] E                 Use -p '/key size Just 1048575; remote chunksize=0 encryption=none.retrieveKeyFile resume from 33%/' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               retrieveKeyFile resume from end:                 FAIL (0.07s)
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '/key size Just 1048575; remote chunksize=0 encryption=none.retrieveKeyFile resume from end/' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               removeKey when present:                          OK
+[00:14:23] E               present False:                                   OK
+[00:14:23] E             key size Just 1048575; remote chunksize=0 encryption=shared
+[00:14:23] E               removeKey when not present:                      OK
+[00:14:23] E               present False:                                   OK
+[00:14:23] E               storeKey:                                        FAIL
+[00:14:23] E                 Exception: content not available to send
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048575; remote chunksize=0 encryption=shared.storeKey\"' to rerun this test only.
+[00:14:23] E               present True:                                    FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048575; remote chunksize=0 encryption=shared.present True\"' to rerun this test only.
+[00:14:23] E               storeKey when already present:                   FAIL
+[00:14:23] E                 Exception: content not available to send
+[00:14:23] E                 Use -p '/key size Just 1048575; remote chunksize=0 encryption=shared.storeKey when already present/' to rerun this test only.
+[00:14:23] E               present True:                                    FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048575; remote chunksize=0 encryption=shared.present True\"' to rerun this test only.
+[00:14:23] E               retrieveKeyFile:                                 FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '$0==\"Remote Tests.key size Just 1048575; remote chunksize=0 encryption=shared.retrieveKeyFile\"' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               retrieveKeyFile resume from 0:                   FAIL
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '/key size Just 1048575; remote chunksize=0 encryption=shared.retrieveKeyFile resume from 0/' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               retrieveKeyFile resume from 33%:                 FAIL
+[00:14:23] E                 Exception: .git\annex\objects\8c4\c61\SHA256E-s1048575--79c930fcd7d08355513f158bbf82532eb6a25d5c8688f4504ac1e240e35e7dc5.this-is-a-test-key\SHA256E-s1048575--79c930fcd7d08355513f158bbf82532eb6a25d5c8688f4504ac1e240e35e7dc5.this-is-a-test-key: openBinaryFile: does not exist (No such file or directory)
+[00:14:23] E                 Use -p '/key size Just 1048575; remote chunksize=0 encryption=shared.retrieveKeyFile resume from 33%/' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               retrieveKeyFile resume from end:                 FAIL (0.06s)
+[00:14:23] E                 .\Command\TestRemote.hs:292:
+[00:14:23] E                 failed
+[00:14:23] E                 Use -p '/key size Just 1048575; remote chunksize=0 encryption=shared.retrieveKeyFile resume from end/' to rerun this test only.
+[00:14:23] E               fsck downloaded object:                          OK
+[00:14:23] E               removeKey when present:                          OK
+[00:14:23] E               present False:                                   OK
+[00:14:23] E             exporttree=yes; key size Just 1048576; key size Just 1048575
+[00:14:23] E               check present export when not present:           OK
+[00:14:23] E               remove export when not present:                  OK
+[00:14:23] E               store export:                                    OK
+[00:14:23] E               check present export after store:                OK
+[00:14:23] E               store export when already present:               OK
+[00:14:23] E               retrieve export:                                 OK
+[00:14:23] E               store new content to export:                     OK
+[00:14:23] E               check present export after store of new content: OK
+[00:14:23] E               retrieve export new content:                     OK
+[00:14:23] E               remove export:                                   OK
+[00:14:23] E               check present export after remove:               OK
+[00:14:23] E               retrieve export fails after removal:             OK
+[00:14:23] E               remove export directory:                         OK
+[00:14:23] E               remove export directory that is already removed: OK
+[00:14:23] E             exporttree=yes; key size Just 1048576; key size Just 1048576
+[00:14:23] E               check present export when not present:           OK
+[00:14:23] E               remove export when not present:                  OK
+[00:14:23] E               store export:                                    OK
+[00:14:23] E               check present export after store:                OK
+[00:14:23] E               store export when already present:               OK
+[00:14:23] E               retrieve export:                                 OK
+[00:14:23] E               store new content to export:                     OK
+[00:14:23] E               check present export after store of new content: OK
+[00:14:23] E               retrieve export new content:                     OK
+[00:14:23] E               remove export:                                   OK
+[00:14:23] E               check present export after remove:               OK
+[00:14:23] E               retrieve export fails after removal:             OK
+[00:14:23] E               remove export directory:                         OK
+[00:14:23] E               remove export directory that is already removed: OK
+[00:14:23] E             exporttree=yes; key size Just 1048575; key size Just 1048575
+[00:14:23] E               check present export when not present:           OK
+[00:14:23] E               remove export when not present:                  OK
+[00:14:23] E               store export:                                    OK
+[00:14:23] E               check present export after store:                OK
+[00:14:23] E               store export when already present:               OK
+[00:14:23] E               retrieve export:                                 OK
+[00:14:23] E               store new content to export:                     OK
+[00:14:23] E               check present export after store of new content: OK
+[00:14:23] E               retrieve export new content:                     OK
+[00:14:23] E               remove export:                                   OK
+[00:14:23] E               check present export after remove:               OK
+[00:14:23] E               retrieve export fails after removal:             OK
+[00:14:23] E               remove export directory:                         OK
+[00:14:23] E               remove export directory that is already removed: OK
+[00:14:23] E             exporttree=yes; key size Just 1048575; key size Just 1048576
+[00:14:23] E               check present export when not present:           OK
+[00:14:23] E               remove export when not present:                  OK
+[00:14:23] E               store export:                                    OK
+[00:14:23] E               check present export after store:                OK
+[00:14:23] E               store export when already present:               OK
+[00:14:23] E               retrieve export:                                 OK
+[00:14:23] E               store new content to export:                     OK
+[00:14:23] E               check present export after store of new content: OK
+[00:14:23] E               retrieve export new content:                     OK
+[00:14:23] E               remove export:                                   OK
+[00:14:23] E               check present export after remove:               OK
+[00:14:23] E               retrieve export fails after removal:             OK
+[00:14:23] E               remove export directory:                         OK
+[00:14:23] E               remove export directory that is already removed: OK
+[00:14:23] E           
+[00:14:23] E           32 out of 125 tests failed (6.39s)
+```
+[[!toggle id=\"ipsum\" text=\"hide\"]]
+\"\"\"]]
+
+Right now, I cannot say whether this is pointing to a problem in my implementation or still to something in git-annex. However, the same implementation passes the test suite on linux.
+
+Sidenote: I am not sure of you have access to a windows system for debugging. If this is needed or helpful, please let me know.
+
+Thanks!
+"""]]
diff --git a/doc/bugs/testremote_is_not_honoring_--backend/comment_5_96a03ff1d7339643e8f74e6e536e8f83._comment b/doc/bugs/testremote_is_not_honoring_--backend/comment_5_96a03ff1d7339643e8f74e6e536e8f83._comment
new file mode 100644
index 0000000000..f73521c52d
--- /dev/null
+++ b/doc/bugs/testremote_is_not_honoring_--backend/comment_5_96a03ff1d7339643e8f74e6e536e8f83._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-03-01T16:39:39Z"
+ content="""
+Seems like my renamePath fix did work, because looking back at the origianl
+failure log, it was failing to generate test keys, before it got to run the
+test cases at all.
+
+The new failures seem likely to be due to getFileStatus/getSymbolicLinkStatus 
+failing on the long filename on windows, as I suspected might happen in
+comment #3. I've updated the issue at
+<https://github.com/jacobstanley/unix-compat/issues/56>. And maybe that
+will get fixed, my understanding is that unix-compat has a new maintainer
+recently. But, git-annex does contain a convertToNativeNamespace function
+that it could use to work around the problem itself.
+
+(I am able to run Windows in emulation, but it's sufficiently slow and disk
+hog that I generally am not in a position to do it easily and appreciate
+users who can save me the bother.)
+"""]]
diff --git a/doc/bugs/testremote_is_not_honoring_--backend/comment_6_7a9cb82671ff8a459886a84e66cb2417._comment b/doc/bugs/testremote_is_not_honoring_--backend/comment_6_7a9cb82671ff8a459886a84e66cb2417._comment
new file mode 100644
index 0000000000..d6d62a7837
--- /dev/null
+++ b/doc/bugs/testremote_is_not_honoring_--backend/comment_6_7a9cb82671ff8a459886a84e66cb2417._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-03-01T19:56:27Z"
+ content="""
+In [[!commit 54ad1b4cfb1c8302f1b862cb2699ab9351e3eb5b]] I fully worked
+around this class of problems with unix-compat.
+
+I think it's reasonably likely that every access of a file in git-annex
+on Windows now goes through UNC-style normalization, allowing long
+filenames to be used. Assuming that everything in ghc base does it, which I
+think it does.
+
+So good chance this is fixed now..
+"""]]
diff --git a/doc/bugs/testremote_is_not_honoring_--backend/comment_7_ed8668ea11a905b90892eb684f93a4ed._comment b/doc/bugs/testremote_is_not_honoring_--backend/comment_7_ed8668ea11a905b90892eb684f93a4ed._comment
new file mode 100644
index 0000000000..f7dc5c61f8
--- /dev/null
+++ b/doc/bugs/testremote_is_not_honoring_--backend/comment_7_ed8668ea11a905b90892eb684f93a4ed._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2023-03-06T16:26:17Z"
+ content="""
+I'm informed that this this fix, `git-annex test` now succeeds when run in
+a deep and long directory path on Windows. It used to fail in that
+situation. A good indication that long filenames are fully supported now.
+"""]]
diff --git a/doc/bugs/testremote_is_not_honoring_--backend/comment_8_3f17e1804ff779c5f9d00e56daf18ee3._comment b/doc/bugs/testremote_is_not_honoring_--backend/comment_8_3f17e1804ff779c5f9d00e56daf18ee3._comment
new file mode 100644
index 0000000000..a47ece5db7
--- /dev/null
+++ b/doc/bugs/testremote_is_not_honoring_--backend/comment_8_3f17e1804ff779c5f9d00e56daf18ee3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="adina.wagner@2a4cac6443aada2bd2a329b8a33f4a7b87cc8eff"
+ nickname="adina.wagner"
+ avatar="http://cdn.libravatar.org/avatar/80b124ad61d6008fa0f6f0b4b0f7c2ef"
+ subject="comment 8"
+ date="2023-04-21T07:08:35Z"
+ content="""
+I can confirm that the original linked issue in the report is fixed with 54ad1b4cfb1. 
+"""]]
diff --git a/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS.mdwn b/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS.mdwn
new file mode 100644
index 0000000000..f078a181ab
--- /dev/null
+++ b/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS.mdwn
@@ -0,0 +1,38 @@
+### Please describe the problem.
+
+Tests started to exit with 124 in that testing scenario recently, e.g. [see this log](https://github.com/datalad/git-annex/runs/4294679306?check_suite_focus=true#step:7:29) which also available on smaug under `/mnt/datasets/datalad/ci/git-annex/builds/2021/11/cron-20211123` 
+
+started to fail 3 days ago but passed ones between :
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2021/11[master]cron-20211123
+$> cd ..
+cron-20211101/  cron-20211103/  cron-20211105/  cron-20211107/  cron-20211109/  cron-20211111/  cron-20211113/  cron-20211115/  cron-20211117/  cron-20211119/  cron-20211121/  cron-20211123/
+cron-20211102/  cron-20211104/  cron-20211106/  cron-20211108/  cron-20211110/  cron-20211112/  cron-20211114/  cron-20211116/  cron-20211118/  cron-20211120/  cron-20211122/  manual-20211117/
+
+$> git grep 'exit code 124'
+cron-20211121/build-ubuntu.yaml-490-280a49ed-failed/4_test-annex (nfs-home).txt:2021-11-21T03:23:49.4599000Z ##[error]Process completed with exit code 124.
+cron-20211121/build-ubuntu.yaml-490-280a49ed-failed/test-annex (nfs-home)/7_Run tests.txt:2021-11-21T03:23:49.4598983Z ##[error]Process completed with exit code 124.
+cron-20211123/build-ubuntu.yaml-492-280a49ed-failed/4_test-annex (nfs-home).txt:2021-11-23T03:27:04.5604733Z ##[error]Process completed with exit code 124.
+cron-20211123/build-ubuntu.yaml-492-280a49ed-failed/test-annex (nfs-home)/7_Run tests.txt:2021-11-23T03:27:04.5604714Z ##[error]Process completed with exit code 124.
+
+$> tail cron-20211122/build-ubuntu.yaml-491-280a49ed-failed/test-annex\ \(nfs-home\)/7_Run\ tests.txt
+2021-11-22T03:11:27.7277096Z     rsync remote:                                         OK (2.96s)
+2021-11-22T03:11:28.6641235Z     bup remote:                                           OK (0.94s)
+2021-11-22T03:11:28.6647373Z     borg remote:                                          OK
+2021-11-22T03:11:40.5680103Z     crypto:                                               OK (11.90s)
+2021-11-22T03:11:44.8147237Z     preferred content:                                    OK (4.24s)
+2021-11-22T03:11:47.0298718Z     required_content:                                     OK (2.22s)
+2021-11-22T03:11:49.3941918Z     add subdirs:                                          OK (2.36s)
+2021-11-22T03:11:50.8879458Z     addurl:                                               OK (1.50s)
+2021-11-22T03:11:50.8880438Z
+2021-11-22T03:11:50.8881162Z All 991 tests passed (978.21s)
+
+```
+
+
+### What version of git-annex are you using? On what operating system?
+
+8.20211118-g5a7f25397  linux ubuntu on github actions
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_1_dd4734cec6290cd3eacd58545ef039e4._comment b/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_1_dd4734cec6290cd3eacd58545ef039e4._comment
new file mode 100644
index 0000000000..9f978ec8a6
--- /dev/null
+++ b/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_1_dd4734cec6290cd3eacd58545ef039e4._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-11-23T19:14:47Z"
+ content="""
+124 is SIGTERM, and the test process does not complete, the last line
+output is:
+
+	    migrate (via gitattributes):                        
+
+I can reproduce that behavior exactly with `killall -TERM git-annex`.
+
+I think something is timing out on your CI system and it's sending a
+TERM signal.
+"""]]
diff --git a/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_2_da46fc7a6bbdae0c3b44d241bc527b55._comment b/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_2_da46fc7a6bbdae0c3b44d241bc527b55._comment
new file mode 100644
index 0000000000..0f35fd7057
--- /dev/null
+++ b/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_2_da46fc7a6bbdae0c3b44d241bc527b55._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2021-11-23T23:12:47Z"
+ content="""
+I see that. But the entire run was not prohibitively long - just 30m 21s... previous succesful though ran total 22m 14s (see eg [here](https://github.com/datalad/git-annex/runs/4271323847?check_suite_focus=true)) so may be test started to stall?
+"""]]
diff --git a/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_3_82b8570c9496ee1b111dbd1ea53e823c._comment b/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_3_82b8570c9496ee1b111dbd1ea53e823c._comment
new file mode 100644
index 0000000000..b2ad0e8ffb
--- /dev/null
+++ b/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_3_82b8570c9496ee1b111dbd1ea53e823c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2021-11-23T23:22:36Z"
+ content="""
+oh that [successful log](https://github.com/datalad/git-annex/runs/4271323847?check_suite_focus=true) doesn't even have any line with `migrate`, so some new test stalling on NFS HOME/CWD?
+"""]]
diff --git a/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_4_e854aae525b7d4902fe2bc0f2c11ae5a._comment b/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_4_e854aae525b7d4902fe2bc0f2c11ae5a._comment
new file mode 100644
index 0000000000..d2a18ea048
--- /dev/null
+++ b/doc/bugs/tests___34__exit_code_124__34___with_HOME_and_PWD_on_NFS/comment_4_e854aae525b7d4902fe2bc0f2c11ae5a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-11-29T16:57:32Z"
+ content="""
+The successful test log you linked to does have the "migrate" 
+tests in it. Those tests are not new.
+
+Is the test suite being run under a timeout?
+"""]]
diff --git a/doc/bugs/tls__58___peer_does_not_support_Extended_Main_Secret.mdwn b/doc/bugs/tls__58___peer_does_not_support_Extended_Main_Secret.mdwn
new file mode 100644
index 0000000000..5723e07957
--- /dev/null
+++ b/doc/bugs/tls__58___peer_does_not_support_Extended_Main_Secret.mdwn
@@ -0,0 +1,101 @@
+### Please describe the problem.
+
+On the current [macOS `HomeBrew` build of the current git-annex](https://formulae.brew.sh/formula/git-annex) (10.20240227), it appears that the build dependencies have dragged in the [latest Haskell `tls` 
+package](https://hackage.haskell.org/package/tls-2.0.1/docs/Network-TLS.html).  Which now defaults `supportedExtendedMainSecret` to `RequireEMS` (previously it seems to have been `AllowEMS`; see eg [darcs bug report of similar error](https://bugs.darcs.net/issue2715)).
+
+The result of this is that some podcast feeds, from webservers which do not support EMS, fail with an error, eg:
+
+```
+importfeed https://risky.biz/feeds/risky-business
+  download failed: HandshakeFailed (Error_Protocol "peer does not support Extended Main Secret" HandshakeFailure)
+
+  warning: downloading the feed failed (feed: https://risky.biz/feeds/risky-business)
+ok
+```
+
+(And presumably this will also affect some non-podcast HTTPS downloads; I found it in a podcast download context.)
+
+I believe this "Extended Main Secret" is also known as "Extended Master Secret", aka [RFC 7627](https://www.ietf.org/rfc/rfc7627.html), which was written up in 2015.  So I can understand why ~9 years later the Haskell `tls` library is defaulting to insisting on EMS in a new major version.  Unfortunately not all webservers, especially podcast feed webservers, have caught up with this.
+
+As best I can tell git annex is getting this `tls` dependency via [`http-client`](https://hackage.haskell.org/package/http-client) which uses [`http-client-tls`](https://hackage.haskell.org/package/http-client-tls-0.3.6.3), and `http-client-tls` appears to just have a `tls (>=1.2)` dependency, which is presumably how `tls-2.0.0` / `tls-2.0.1` got dragged in, with these new defaults.
+
+I'm unclear if git-annex is in a position to pass `AllowEMS` to the TLS library (and thus restore to the old default).  But at least in the short term it might be worth considering doing that if possible.
+
+### What steps will reproduce the problem?
+
+Currently I have three podcast feeds (two from the same webserver) which fail:
+
+```
+git annex importfeed https://risky.biz/feeds/risky-business
+```
+
+```
+git annex importfeed https://risky.biz/feeds/risky-business-news
+```
+
+```
+git annex importfeed https://www.thecultureoftech.com/index.php/feed/podcast/ 
+```
+
+(Given the irony that the first two are are an InfoSec podcast, I have also reported this missing EMS extension support to them as well, so it may get fixed before you try it.)
+
+It looks like I've also had one media file download fail repeatedly for the same reason (but the podcast feed itself downloads okay):
+
+```
+git annex addurl https://traffic.omny.fm/d/clips/53b6fe2a-4ef6-4356-ae92-a61500df6da0/40b3f537-c161-4823-ae44-af3a007e121b/b2682900-b36c-447b-812d-b1290049fea8/audio.mp3
+```
+
+### What version of git-annex are you using? On what operating system?
+
+git annex 10.20240227, on macOS Ventura (13.6.3).  With git annex installed from HomeBrew.
+
+```
+ewen@basadi:~$ git annex version
+git-annex version: 10.20240227
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24.1 bloomfilter-2.0.1.2 crypton-0.34 DAV-1.3.4 feed-1.3.2.1 ghc-9.6.3 http-client-0.7.16 persistent-sqlite-2.13.3.0 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+ewen@basadi:~$ 
+```
+
+### Please provide any additional information below.
+
+[[!format sh """
+ewen@basadi:~/Music/podcasts$ git annex importfeed https://www.thecultureoftech.com/index.php/feed/podcast/ 
+importfeed gathering known urls ok
+importfeed https://www.thecultureoftech.com/index.php/feed/podcast/ 
+  download failed: HandshakeFailed (Error_Protocol "peer does not support Extended Main Secret" HandshakeFailure)
+
+  warning: downloading the feed failed (feed: https://www.thecultureoftech.com/index.php/feed/podcast/)
+ok
+ewen@basadi:~/Music/podcasts$ 
+ewen@basadi:~/Music/podcasts$ git annex addurl https://traffic.omny.fm/d/clips/53b6fe2a-4ef6-4356-ae92-a61500df6da0/40b3f537-c161-4823-ae44-af3a007e121b/b2682900-b36c-447b-812d-b1290049fea8/audio.mp3
+addurl https://traffic.omny.fm/d/clips/53b6fe2a-4ef6-4356-ae92-a61500df6da0/40b3f537-c161-4823-ae44-af3a007e121b/b2682900-b36c-447b-812d-b1290049fea8/audio.mp3 
+git-annex: HttpExceptionRequest Request {
+  host                 = "traffic.omny.fm"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding",""),("User-Agent","git-annex/10.20240227")]
+  path                 = "/d/clips/53b6fe2a-4ef6-4356-ae92-a61500df6da0/40b3f537-c161-4823-ae44-af3a007e121b/b2682900-b36c-447b-812d-b1290049fea8/audio.mp3"
+  queryString          = ""
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+  proxySecureMode      = ProxySecureWithConnect
+}
+ (InternalException (HandshakeFailed (Error_Protocol "peer does not support Extended Main Secret" HandshakeFailure)))
+failed
+addurl: 1 failed
+ewen@basadi:~/Music/podcasts$ 
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Absolutely, I've been using git-annex as my podcatcher (among other reasons) for about a decade at this point.  Thanks for developing it!
diff --git a/doc/bugs/tls__58___peer_does_not_support_Extended_Main_Secret/comment_1_731db4542017bef831bc7a06b70f79fb._comment b/doc/bugs/tls__58___peer_does_not_support_Extended_Main_Secret/comment_1_731db4542017bef831bc7a06b70f79fb._comment
new file mode 100644
index 0000000000..88e84961b9
--- /dev/null
+++ b/doc/bugs/tls__58___peer_does_not_support_Extended_Main_Secret/comment_1_731db4542017bef831bc7a06b70f79fb._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="TLS v1.2 EMS (Extended Master/Main Secret)"
+ date="2024-03-07T03:01:20Z"
+ content="""
+From some more research it seems that Extended Master Secret (aka Extended Main Secret) is a TLS 1.2 only extension, to work around a problem with TLS 1.2 (eg, [2015 post about the problem](https://www.tripwire.com/state-of-security/tls-extended-master-secret-extension-fixing-a-hole-in-tls)).
+
+TLS v1.3 doesn't have this problem, by design, AFAIK.  And thus clients/servers supporting TLS v1.3 entirely avoids the problem (possibly why I have only found it on a few servers; the one I looked into in detail definitely won't connect with TLS v1.3 right now, but they're looking into it).
+
+The webserver support can be confirmed with, eg forced TLS v1.2:
+
+```
+echo \"\" | openssl s_client -tls1_2 -connect WEBSERVER:443 2>&1 | egrep \"Protocol|Extended master\"
+```
+
+and forced TLS v1.3 to check if that will work:
+
+```
+echo \"\" | openssl s_client -tls1_3 -connect WEBSERVER:443
+```
+
+Hopefully that means the number of impacted sites is *relatively* small (eg, ones that haven't enabled TLS v1.3 support in the last 5+ years).
+
+Ewen
+"""]]
diff --git a/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__.mdwn b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__.mdwn
new file mode 100644
index 0000000000..af10cc024d
--- /dev/null
+++ b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__.mdwn
@@ -0,0 +1,73 @@
+### Please describe the problem.
+
+Doing backup of data using `git annex move` from local to dropbox via `git-annex-remote-rclone`.
+
+Full invocation here is
+
+```shell
+( source ~/git-annexes/10.20231227+git24-gd37dbd62b8.env; OUR_LOG_FILE=~/.cache/rclone/logs/`date --iso-8601=seconds`-movedebug; RCLONE_LOG_LEVEL=DEBUG RCLONE_LOG_FILE=${OUR_LOG_FILE}_rclone.log git annex --debug move --to dandi-dandisets-dropbox sub-484677/sub-484677_ses-20210419T161140_behavior+ecephys+ogen.nwb 2>&1 | tee ${OUR_LOG_FILE}_git-annex.log ; )
+```
+under `/mnt/backup/dandi/dandisets/000363` . On git-annex side we see
+
+```shell
+dandi@drogon:~/.cache/rclone/logs$ grep -4 'Transfer stalled' 2024-01-04T14:28:29-05:00-movedebug_git-annex.log
+[2024-01-04 14:43:24.5722525] (Annex.TransferrerPool) < op 295000000000
+75%   274.74 GiB        7 MiB/s 3h46m2024/01/04 14:44:49 DEBUG : Setting --log-level "DEBUG" from environment variable RCLONE_LOG_LEVEL="DEBUG"
+2024/01/04 14:44:49 DEBUG : Setting --log-file "/home/dandi/.cache/rclone/logs/2024-01-04T14:28:29-05:00-movedebug_rclone.log" from environment variable RCLONE_LOG_FILE="/home/dandi/.cache/rclone/logs/2024-01-04T14:28:29-05:00-movedebug_rclone.log"
+
+  Transfer stalled
+[2024-01-04 14:45:40.042053663] (Utility.Process) process [2329029] chat: /home/dandi/git-annexes/10.20231227+git24-gd37dbd62b8/usr/lib/git-annex.linux/git-annex ["transferrer","-c","annex.debug=true"]
+
+```
+
+and rclone logs for around that time point(s):
+
+```
+2024/01/04 14:44:49 DEBUG : rclone: Version "v1.61.1-DEV" starting with parameters ["rclone" "copy" ".git/annex/tmp/SHA256E-s393314879887-S1000000000-C296--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb" "dandi-dandisets-dropbox:dandi-dandisets/annexstore/b4f/757/"]
+2024/01/04 14:44:49 DEBUG : Creating backend with remote ".git/annex/tmp/SHA256E-s393314879887-S1000000000-C296--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb"
+2024/01/04 14:44:49 DEBUG : Using config file from "/home/dandi/.rclone.conf"
+2024/01/04 14:44:49 DEBUG : fs cache: adding new entry for parent of ".git/annex/tmp/SHA256E-s393314879887-S1000000000-C296--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb", "/mnt/backup/dandi/dandisets/000363/.git/annex/tmp"
+2024/01/04 14:44:49 DEBUG : Creating backend with remote "dandi-dandisets-dropbox:dandi-dandisets/annexstore/b4f/757/"
+2024/01/04 14:44:49 DEBUG : fs cache: renaming cache item "dandi-dandisets-dropbox:dandi-dandisets/annexstore/b4f/757/" to be canonical "dandi-dandisets-dropbox:dandi-dandisets/annexstore/b4f/757"
+2024/01/04 14:44:49 DEBUG : SHA256E-s393314879887-S1000000000-C296--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb: Need to transfer - File not found at Destination
+2024/01/04 14:44:50 DEBUG : SHA256E-s393314879887-S1000000000-C296--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb: Uploading chunk 1/20
+...
+2024/01/04 14:45:36 DEBUG : SHA256E-s393314879887-S1000000000-C296--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb: Uploading chunk 19/20
+2024/01/04 14:45:38 DEBUG : SHA256E-s393314879887-S1000000000-C296--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb: Uploading chunk 20/20
+2024/01/04 14:45:39 INFO  : Signal received: interrupt
+2024/01/04 14:45:39 INFO  : Dropbox root 'dandi-dandisets/annexstore/b4f/757': Committing uploads - please wait...
+2024/01/04 14:45:39 INFO  : Exiting...
+```
+
+<details>
+<summary>using older git-annex I got similar crash but on earlier chunk, so it is not pertinent to last chunk</summary> 
+
+```shell
+2024/01/04 13:56:29 DEBUG : rclone: Version "v1.61.1-DEV" starting with parameters ["rclone" "copy" ".git/annex/tmp/SHA256E-s393314879887-S1000000000-C287--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb" "dandi-dandisets-dropbox:dandi-dandisets/annexstore/b4f/757/"]
+2024/01/04 13:56:29 DEBUG : Creating backend with remote ".git/annex/tmp/SHA256E-s393314879887-S1000000000-C287--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb"
+2024/01/04 13:56:29 DEBUG : Using config file from "/home/dandi/.rclone.conf"
+2024/01/04 13:56:29 DEBUG : fs cache: adding new entry for parent of ".git/annex/tmp/SHA256E-s393314879887-S1000000000-C287--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb", "/mnt/backup/dandi/dandisets/000363/.git/annex/tmp"
+2024/01/04 13:56:29 DEBUG : Creating backend with remote "dandi-dandisets-dropbox:dandi-dandisets/annexstore/b4f/757/"
+2024/01/04 13:56:30 DEBUG : fs cache: renaming cache item "dandi-dandisets-dropbox:dandi-dandisets/annexstore/b4f/757/" to be canonical "dandi-dandisets-dropbox:dandi-dandisets/annexstore/b4f/757"
+2024/01/04 13:56:30 DEBUG : SHA256E-s393314879887-S1000000000-C287--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb: Need to transfer - File not found at Destination
+2024/01/04 13:56:30 DEBUG : SHA256E-s393314879887-S1000000000-C287--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb: Uploading chunk 1/20
+...
+2024/01/04 13:57:08 DEBUG : SHA256E-s393314879887-S1000000000-C287--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb: Uploading chunk 17/20
+2024/01/04 13:57:10 DEBUG : SHA256E-s393314879887-S1000000000-C287--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb: Uploading chunk 18/20
+2024/01/04 13:57:11 DEBUG : SHA256E-s393314879887-S1000000000-C287--38c8c93c66ece7cbe8eeca9621ab72bf3968873e842f3e376ddda012eb0a0e5f.nwb: Uploading chunk 19/20
+2024/01/04 13:57:14 INFO  : Signal received: interrupt
+2024/01/04 13:57:14 INFO  : Dropbox root 'dandi-dandisets/annexstore/b4f/757': Committing uploads - please wait...
+2024/01/04 13:57:14 INFO  : Exiting...
+```
+</details>
+
+So it seems that stall detection (I didn't look how it even decides on that) is flawed in case of large (chunked) files being transferred through external custom remotes which have no way to report progress as it is the case here in https://github.com/git-annex-remote-rclone/git-annex-remote-rclone/blob/master/git-annex-remote-rclone (filed [a bug report](https://github.com/git-annex-remote-rclone/git-annex-remote-rclone/issues/76) to see that addressed).
+
+
+### What version of git-annex are you using? On what operating system?
+
+first was a year old version, then tried with bleeding edge 10.20231227+git24-gd37dbd62b8
+
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
diff --git a/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_1_db83f6a38cae36da89f0ab4ef83021d8._comment b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_1_db83f6a38cae36da89f0ab4ef83021d8._comment
new file mode 100644
index 0000000000..4c2ccc7292
--- /dev/null
+++ b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_1_db83f6a38cae36da89f0ab4ef83021d8._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-01-18T17:18:07Z"
+ content="""
+It looks like you must have annex.stalldetection (or the per-remote config)
+set. git-annex does not behave this way without that configuration.
+What is it set to?
+
+You are probably right in that it involves rclone special remote not
+reporting transfer progress back to git-annex.
+
+Normally, when a special remote does not do progress reporting,
+git-annex does not do any stall detection, because there must have been
+at least some previous progress update in order for it to detect a stall.
+
+But when chunking is enabled (as it was in your case with 1 gb chunks),
+git-annex itself updates the progress after each chunk. When the special
+remote does not do any progress reporting, and chunk size is large, that
+means that the progress will be updated very infrequently. 
+
+So for example, if it takes 2 minutes to upload a chunk, and you had
+annex.stalldetection set to eg "10mb/1m", then in a chunk after the 1st one,
+git-annex would wake up after 1 minute, see that no data seemed to have
+been sent, and conclude there was a stall. You would need to change the
+time period in the config to something less granular eg "100mb/10m"
+to avoid that.
+
+This might be a documentation problem, it may not be clear to the user
+that "10mb/1m" is any different than "100mb/10m". And finding a value that
+works depends on knowing details of how often the progress gets updated
+for a given remote.
+
+But, your transcript show that the stall was detected on chunk 296.
+(git-annex's chunk, rclone is doing its own chunking to dropbox)
+So the annex.stalldetection configuration must have been one that
+worked most of the time, for it to transfer the previous 295 chunks
+without a stall having been detected. Unless this was a resume after
+previous command(s) had uploaded those other chunks.
+"""]]
diff --git a/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_2_2aeb065a257729e852055533aff04650._comment b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_2_2aeb065a257729e852055533aff04650._comment
new file mode 100644
index 0000000000..5d8e3863e2
--- /dev/null
+++ b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_2_2aeb065a257729e852055533aff04650._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2024-01-18T17:50:21Z"
+ content="""
+I think that what git-annex could do is detect when progress updates are
+happening with too low a granularity for the annex.stalldetection
+configuration.
+
+When waiting for the first progress update, it can keep track of how much time
+has elapsed. If annex.stalldetection is "10mb/2m" and it took 20 minutes to
+get the first progress update, the granularity is clearly too low.
+
+And then it could disregard the configuration, or suggest a better
+configuration value, or adjust what it's expecting to match the
+observed granularity.
+
+(The stall detection auto-prober uses a similar heuristic to that already.
+It observes the granularity and only if it's sufficiently low (an update
+every 30 seconds or less) does it assume that 60 seconds without an update
+may be a stall.)
+"""]]
diff --git a/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_3_f8bd6a233d835bdc413bbf0127608431._comment b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_3_f8bd6a233d835bdc413bbf0127608431._comment
new file mode 100644
index 0000000000..dd93371133
--- /dev/null
+++ b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_3_f8bd6a233d835bdc413bbf0127608431._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-01-18T19:04:26Z"
+ content="""
+To reproduce this (more or less), I modified the example.sh external
+special remote to sleep for 10 seconds before each key store.
+Set up a remote with chunk=1mb, and annex.stalldetection = "0.001mb/1s".
+
+Uploading a 100 mb file, a stall is detected after the first chunk is
+uploaded. As expected, since 1 second passed with no update.
+
+When I resume the upload, the second chunk is uploaded and then a stall is
+detected on the third. And so on.
+
+I've implemented dynamic granularity scaling now, and in this test case, it notices
+it took 11 seconds for the first chunk, and behaves as if it were
+configured with annex.stalldetection of "0.022mb/22s". Which keeps it from
+detecting a stall.
+"""]]
diff --git a/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_4_320828c8d39d1f030d1797b539dbb22e._comment b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_4_320828c8d39d1f030d1797b539dbb22e._comment
new file mode 100644
index 0000000000..c3a991d4b1
--- /dev/null
+++ b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_4_320828c8d39d1f030d1797b539dbb22e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2024-01-18T21:32:30Z"
+ content="""
+Thank you Joey for looking into it!  FWIW, indeed I had `stalldetection = 1KB/120s` .  But I believe I introduced it primarily for data \"download\", where git-annex actually IIRC keeps its monitoring of the file size as it is arriving.  For the `copy` out, situation is indeed different and in case of assymmetric connections I even wondered if worth allowing different values for stalldetection-get and -put?
+
+In this particular case, since original report we did adjust rclone special remote to report PROGRESS back.  I think it completed fine on few 1 large file uploads.  I will tomorrow (after we get daily git-annex build in) run it \"on full\" for a good number of files and see what happens.
+"""]]
diff --git a/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_5_9fc2d7f4b39615e43bce3993e0a6e647._comment b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_5_9fc2d7f4b39615e43bce3993e0a6e647._comment
new file mode 100644
index 0000000000..993ea416a1
--- /dev/null
+++ b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_5_9fc2d7f4b39615e43bce3993e0a6e647._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2024-01-19T17:31:41Z"
+ content="""
+Re asymmetric connections, stall detection doesn't need to be
+configured anywhere near the total available bandwidth, so generally it
+would be ok to configure it for a slow uplink even when a fast downlink is
+available. And if you're only interested in detecting total stalls
+(as opposed to some kind of "too slow" condition), "1k" per some unit of
+time is sufficient.
+
+But maybe it does make sense to be able to configure it to abandon slow
+downloads but allow slow uploads. For example, `git-annex get` with
+the content on several remotes, where the download speed from one
+remote is often fast but occasionally slows down, and another remote
+is consistently medium speed.
+
+So you might set "10gb/1m" for downloads from remote, knowing that if it is
+slow it will abort the download from it and fall back to the medium speed
+remote. But when sending content *to* the variable speed remote, would not
+want to give up only because it was a little slow.
+
+Ok, added annex.stalldetection-download, annex.stalldetection-upload, etc.
+"""]]
diff --git a/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_6_1b2eb9993e220082f3be5dd568deef3e._comment b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_6_1b2eb9993e220082f3be5dd568deef3e._comment
new file mode 100644
index 0000000000..d3df8542ec
--- /dev/null
+++ b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__/comment_6_1b2eb9993e220082f3be5dd568deef3e._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2024-01-19T17:01:27Z"
+ content="""
+> "download", where git-annex actually IIRC keeps its monitoring of the file size as it is arriving
+
+git-annex does do file size monitoring
+in a few cases (when running `cp`, and when downloading
+an url with `curl`), but it does not do it for downloads
+in general, and not for external special remotes specifically.
+
+If it did for external special remotes, and if rclone grows the 
+destination file as it downloads, rather than atomically at the end
+(which I have not verified), that would have avoided this problem.
+Probably it will avoids this type of problem for downloads
+from the majority of external special remotes. Though of course not for
+uploads.
+
+Ok, implemented that for external special remotes.
+"""]]
diff --git a/doc/bugs/too_many_ssh_connections_during_sync_of_gcrypt_remotes.mdwn b/doc/bugs/too_many_ssh_connections_during_sync_of_gcrypt_remotes.mdwn
new file mode 100644
index 0000000000..079c9025a9
--- /dev/null
+++ b/doc/bugs/too_many_ssh_connections_during_sync_of_gcrypt_remotes.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+`git-annex sync gcryptremote` makes too many ssh connections one after another for each sub-task involved, potentially triggering firewall rate-limits on the SSH server.
+
+### What steps will reproduce the problem?
+sync with gcrypt remote while watching sshd logs on the server (I was getting >=5 connections per single sync in quick succession)
+
+### What version of git-annex are you using? On what operating system?
+Fedora 19, installed through cabal (without s3 and webapp support as the deps were failing to build)
+
+    $ git annex version
+    git-annex version: 5.20150205
+    build flags: Assistant Pairing WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA TorrentParser
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+    remote types: git gcrypt bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/too_many_ssh_connections_during_sync_of_gcrypt_remotes/comment_1_8522285987f6d231c851861418af633a._comment b/doc/bugs/too_many_ssh_connections_during_sync_of_gcrypt_remotes/comment_1_8522285987f6d231c851861418af633a._comment
new file mode 100644
index 0000000000..133b3ac8ea
--- /dev/null
+++ b/doc/bugs/too_many_ssh_connections_during_sync_of_gcrypt_remotes/comment_1_8522285987f6d231c851861418af633a._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-12T18:27:26Z"
+ content="""
+Are you sure it's git-annex that's making the connections, and not
+git-remote-gcrypt? What kind of uri are you using?
+
+I tried to reproduce such a problem, making this gcrypt special remote:
+
+git annex initremote gcrypt type=gcrypt gitrepo=ssh://localhost/tmp/r encryption=shared --fast
+
+When I `git annex sync gcrypt`, only 1 ssh connection is made:
+
+joey@darkstar:~/tmp/meep>systemctl status ssh.socket | grep Accepted  
+ Accepted: 80; Connected: 1  
+joey@darkstar:~/tmp/meep>git annex sync gcrypt >/dev/null 2>&1  
+joey@darkstar:~/tmp/meep>systemctl status ssh.socket | grep Accepted  
+ Accepted: 81; Connected: 1  
+
+git-annex's ssh connection caching code is working for this gcrypt remote,
+because git-annex's `GIT_SSH=` is being propigated through gcrypt to git
+push and pull.
+"""]]
diff --git a/doc/bugs/too_many_ssh_connections_during_sync_of_gcrypt_remotes/comment_2_f87b3ba05c0cdfadd4d5da894dea0abb._comment b/doc/bugs/too_many_ssh_connections_during_sync_of_gcrypt_remotes/comment_2_f87b3ba05c0cdfadd4d5da894dea0abb._comment
new file mode 100644
index 0000000000..ee52566a44
--- /dev/null
+++ b/doc/bugs/too_many_ssh_connections_during_sync_of_gcrypt_remotes/comment_2_f87b3ba05c0cdfadd4d5da894dea0abb._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="sairon"
+ subject="comment 2"
+ date="2015-02-17T15:04:55Z"
+ content="""
+looks like it was the assistant
+"""]]
diff --git a/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems.mdwn b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems.mdwn
new file mode 100644
index 0000000000..116f1496f9
--- /dev/null
+++ b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems.mdwn
@@ -0,0 +1,20 @@
+It seems that commit bc5c54c987f548505a3877e8a0e460abe0b2a081 introduced some linux specific things...
+
+<pre>
+hsc2hs Touch.hsc
+Touch.hsc: In function ‘main’:
+Touch.hsc:46: error: ‘UTIME_OMIT’ undeclared (first use in this function)
+Touch.hsc:46: error: (Each undeclared identifier is reported only once
+Touch.hsc:46: error: for each function it appears in.)
+Touch.hsc:48: error: ‘UTIME_NOW’ undeclared (first use in this function)
+Touch.hsc:67: error: ‘AT_FDCWD’ undeclared (first use in this function)
+Touch.hsc:68: error: ‘AT_SYMLINK_NOFOLLOW’ undeclared (first use in this function)
+compiling Touch_hsc_make.c failed
+command was: /usr/bin/gcc -c -m32 -I/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.3/include/ Touch_hsc_make.c -o Touch_hsc_make.o
+make: *** [Touch.hs] Error 1
+</pre>
+
+I dug around the OSX documentation and fcntl.h header file and it seems that UTIME_OMIT, UTIME_NOW, AT_FDCWD and AT_SYMLINK_NOFOLLOW aren't defined (at least on OSX). I suspect the BSD's in general will have problems compiling git-annex.
+
+[[!meta title="annexed symlink mtime matching code is disabled on non-linux systems; needs testing"]]
+[[!tag confirmed]]
diff --git a/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_1_1d38283c9ea87174f3bbef9a58f5cb88._comment b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_1_1d38283c9ea87174f3bbef9a58f5cb88._comment
new file mode 100644
index 0000000000..f26239c3e9
--- /dev/null
+++ b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_1_1d38283c9ea87174f3bbef9a58f5cb88._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-03-16T16:07:26Z"
+ content="""
+Hmm.. is utimensat available at all?
+
+I've committed an update that may convince at least some compilers to expose this newer POSIX stuff. I don't know if it will help, please let me know.
+"""]]
diff --git a/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_2_bf112edd075fbebe4fc959a387946eb9._comment b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_2_bf112edd075fbebe4fc959a387946eb9._comment
new file mode 100644
index 0000000000..0222e645b9
--- /dev/null
+++ b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_2_bf112edd075fbebe4fc959a387946eb9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2011-03-16T16:49:18Z"
+ content="""
+Just pulled the changes, it still fails to build. utimensat doesn't seem to exist on OSX 10.6.6.
+"""]]
diff --git a/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_3_a46080fbe82adf0986c5dc045e382501._comment b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_3_a46080fbe82adf0986c5dc045e382501._comment
new file mode 100644
index 0000000000..7e79dea881
--- /dev/null
+++ b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_3_a46080fbe82adf0986c5dc045e382501._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-03-16T17:46:40Z"
+ content="""
+Alright, I've added #idefs and the symlink timestamp mirroring feature will be unavailable on OSX until I get a version that works there.
+"""]]
diff --git a/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_4_760437bf3ba972a775bb190fb4b38202._comment b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_4_760437bf3ba972a775bb190fb4b38202._comment
new file mode 100644
index 0000000000..6b1e03b026
--- /dev/null
+++ b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_4_760437bf3ba972a775bb190fb4b38202._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 4"
+ date="2011-03-16T20:32:01Z"
+ content="""
+Just tried it out on my mac and it's working again. I guess this issue could be closed for now.
+"""]]
diff --git a/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_5_060ba5ea88dcab2f4a0c199f13ef4f67._comment b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_5_060ba5ea88dcab2f4a0c199f13ef4f67._comment
new file mode 100644
index 0000000000..aeb576be37
--- /dev/null
+++ b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_5_060ba5ea88dcab2f4a0c199f13ef4f67._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 5"
+ date="2011-03-20T18:12:59Z"
+ content="""
+I'm leaving this bug open because this feature, however minor is not available on OSX and BSD. 
+
+I have added a partial implementation using lutimes(3), which should be available on the BSDs. However, it's ifdefed out due to a casting problem: The TimeSpec uses a CTime, while lutimes uses a CLong. These data types may be internally the same on some or all platforms, so if you want this feature you can try changing the \"ifdef 0\" in Touch.hsc to 1 and try it, see if \"git annex add\" mirrors file modification time in created symlinks, and let me know.
+"""]]
diff --git a/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_6_548303d6ffb21a9370b6904f41ff49c1._comment b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_6_548303d6ffb21a9370b6904f41ff49c1._comment
new file mode 100644
index 0000000000..cd116c232d
--- /dev/null
+++ b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_6_548303d6ffb21a9370b6904f41ff49c1._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 6"
+ date="2011-03-20T20:48:41Z"
+ content="""
+ok, pulling the latest master and building on OSX now does this...
+
+<pre>
+ghc -O2 -Wall -ignore-package monads-fd --make git-annex
+[ 1 of 63] Compiling Touch            ( Touch.hs, Touch.o )
+
+Touch.hsc:24:0:
+    The type signature for `touchBoth' lacks an accompanying binding
+
+Touch.hsc:27:26: Not in scope: `touchBoth'
+make: *** [git-annex] Error 1
+</pre>
+
+changing the #if 0 to 1 gives this...
+
+<pre>
+ghc -O2 -Wall -ignore-package monads-fd --make git-annex
+[ 1 of 63] Compiling Touch            ( Touch.hs, Touch.o )
+
+Touch.hsc:95:43:
+    Couldn't match expected type `CLong' against inferred type `CTime'
+    In the second argument of `(\ hsc_ptr
+                                    -> pokeByteOff hsc_ptr 0)', namely
+        `(sec :: CLong)'
+    In a stmt of a 'do' expression:
+        (\ hsc_ptr -> pokeByteOff hsc_ptr 0) ptr (sec :: CLong)
+    In the expression:
+        do { (\ hsc_ptr -> pokeByteOff hsc_ptr 0) ptr (sec :: CLong);
+             (\ hsc_ptr -> pokeByteOff hsc_ptr 4) ptr (0 :: CLong) }
+make: *** [git-annex] Error 1
+</pre>
+
+
+it seems that commit 6634b6a6b84a924f6f6059b5bea61f449d056eee has broken support for OSX.
+
+"""]]
diff --git a/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_7_7ca00527ab5db058aadec4fe813e51fd._comment b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_7_7ca00527ab5db058aadec4fe813e51fd._comment
new file mode 100644
index 0000000000..e35dc8a827
--- /dev/null
+++ b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_7_7ca00527ab5db058aadec4fe813e51fd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 7"
+ date="2011-03-20T22:06:25Z"
+ content="""
+Fixed that, and removed the impossible cast so it can be built with #if 1
+"""]]
diff --git a/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_8_881aecb9ae671689453f6d5d780d844b._comment b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_8_881aecb9ae671689453f6d5d780d844b._comment
new file mode 100644
index 0000000000..56a7eb360e
--- /dev/null
+++ b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_8_881aecb9ae671689453f6d5d780d844b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 8"
+ date="2011-03-21T08:52:18Z"
+ content="""
+Just tried building both of the code paths, and they seem to build and somewhat function on OSX. I have yet to confirm the functionality is working correctly, but so far it's looking good. (I somewhat care less about the utimes/mtimes of my files since I care more about the content :) )
+"""]]
diff --git a/doc/bugs/uftp_5__58___invalid_key_type.mdwn b/doc/bugs/uftp_5__58___invalid_key_type.mdwn
new file mode 100644
index 0000000000..440c040133
--- /dev/null
+++ b/doc/bugs/uftp_5__58___invalid_key_type.mdwn
@@ -0,0 +1,55 @@
+### Please describe the problem.
+
+git annex multicast --send quits with error "Invalid keytype"
+
+
+### What steps will reproduce the problem?
+
+Follow the example in the multicast command help page, the send operation fails when uftp version is 5.0.
+
+Probably the reason is the removal of aes256-cbc in version 5.0 where they left aes256-gcm
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 8.20211028
+OS is nixos-21.11 with uftp installed
+uftp 5.0
+
+### Operation log
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+$ git annex multicast --send --debug
+sending files [2022-04-17 00:15:46.699593866] (Utility.Process) process [60540] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2022-04-17 00:15:46.701266922] (Utility.Process) process [60540] done ExitSuccess
+[2022-04-17 00:15:46.701754626] (Utility.Process) process [60541] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","refs/heads/master"]
+[2022-04-17 00:15:46.703889652] (Utility.Process) process [60541] done ExitSuccess
+[2022-04-17 00:15:46.70436486] (Utility.Process) process [60542] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-files","-z","--cached","--"]
+[2022-04-17 00:15:46.706736386] (Utility.Process) process [60543] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2022-04-17 00:15:46.709237395] (Utility.Process) process [60544] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2022-04-17 00:15:46.729027634] (Utility.Process) process [60542] done ExitSuccess
+[2022-04-17 00:15:46.729292044] (Utility.Process) process [60545] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2022-04-17 00:15:46.730468539] (Utility.Process) process [60545] done ExitSuccess
+[2022-04-17 00:15:46.730735082] (Utility.Process) process [60546] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2022-04-17 00:15:46.73204795] (Utility.Process) process [60546] done ExitSuccess
+[2022-04-17 00:15:46.732421746] (Utility.Process) process [60547] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..fd32a06095805399cdaf708cd294158b8d05027b","--pretty=%H","-n1"]
+[2022-04-17 00:15:46.733706532] (Utility.Process) process [60547] done ExitSuccess
+[2022-04-17 00:15:46.735507734] (Utility.Process) process [60548] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2022-04-17 00:15:46.737226695] (Utility.Process) process [60549] call: uftp ["-c","-Y","aes256-cbc","-h","sha512","-e","ecdh_ecdsa","-k",".git/annex/creds/multicast","-U","0x1de1f677","-H","@/tmp/authlist60534-1","-i","/tmp/send60534-0"]
+Invalid keytype
+[2022-04-17 00:15:46.748492634] (Utility.Process) process [60549] done ExitFailure 1
+failed
+ok
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Of course! I'm using it to track assets in an infrastructure repository
+
+> I've changed it to use aes256-gcm. I have not verified if there
+> is other breakage from the new version, so file a bug if you find any.
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn
new file mode 100644
index 0000000000..e25c72095d
--- /dev/null
+++ b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+
+I understand that `git annex unannex` is essentially there for undoing an accidental `git annex add`. Unfortunately it doesn't do that.
+
+If I have uncommitted changes, which is the case after a `git annex add`, it tells me:
+
+    git-annex: Cannot proceed with uncommitted changes staged in the index. Recommend you: git commit
+    CallStack (from HasCallStack):
+      error, called at ./Command/Unannex.hs:48:19 in main:Command.Unannex
+
+But I would expect it to `git reset` the file and then replace the symlink by the actual file content.
+
+### What steps will reproduce the problem?
+
+    > git init
+    Initialized empty Git repository in /somewhere/.git
+    > git annex init
+    init  ok
+    (recording state in git...)
+    > touch foo
+    > git annex add foo
+    add foo ok
+    (recording state in git...)
+    > git annex unannex foo
+    git-annex: Cannot proceed with uncommitted changes staged in the index. Recommend you: git commit
+    CallStack (from HasCallStack):
+      error, called at ./Command/Unannex.hs:48:19 in main:Command.Unannex
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 6.20160527-gf21a425
+
+Installed from the Arch Linux repository.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Sure, I'm using it for photos, music and videos
+
+> This got fixed in v7 repositories. [[done]] --[[Joey]]
diff --git a/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_1_1c0cad1076d5d4d908b8297e7c13ea33._comment b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_1_1c0cad1076d5d4d908b8297e7c13ea33._comment
new file mode 100644
index 0000000000..4b54996eb4
--- /dev/null
+++ b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_1_1c0cad1076d5d4d908b8297e7c13ea33._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-12T16:23:51Z"
+ content="""
+In v5 mode, there is a complex interaction between unannex and the
+pre-commit hook. An unannexed file looks quite a lot like an unlocked file,
+so the pre-commit hook is prone to want to lock it, and so add it back to
+the annex as an annexed file.
+
+To avoid that problem, unannex needs to commit the unannexing of the
+files.
+
+However, if you have other staged changes, they'll also be included in that
+commit. Which would be a bug if it were allowed to happen. This is why
+it checks for a clean index first.
+
+It would be possible to improve the behavior by explicitly committing only
+the files that got unannexed, rather than all staged changes. Why didn't I
+do that?
+
+Well, `git commit $file` stages any changes to the file's content before
+committing. When the file has been unannexed, this stages the entire large
+file content into git, and adds it back. Not the desired behavior!
+
+Git in fact has no interface to make it commit only staged changes to
+only specific files. I can't get there from here. It would certianly
+be nice if git got the ability to do that, if someone wants a project to
+improve git.
+
+It's very nice that v6 mode avoids this problem entirely!
+"""]]
diff --git a/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_2_4609f9a1545b08e08021bf786561f5e5._comment b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_2_4609f9a1545b08e08021bf786561f5e5._comment
new file mode 100644
index 0000000000..1c3169e70f
--- /dev/null
+++ b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_2_4609f9a1545b08e08021bf786561f5e5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tom.prince@6bf26c878bf6103667f28d70cf49d4fb74d33df7"
+ nickname="tom.prince"
+ avatar="http://cdn.libravatar.org/avatar/e81edff3af564b86f4c9d780a8023299"
+ subject="comment 2"
+ date="2017-07-21T18:22:28Z"
+ content="""
+As far as I can tell, from looking at the code, the pre-commit hook only looks at files in the index. Thus, if unannexing an uncommited file removed it from the index, the pre-commit will do the right thing. This would be nice to have, at least for the case where the files have never been committed.
+"""]]
diff --git a/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_3_6c99a97d56b1a3b12092c15fafcf8761._comment b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_3_6c99a97d56b1a3b12092c15fafcf8761._comment
new file mode 100644
index 0000000000..47d417cec0
--- /dev/null
+++ b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_3_6c99a97d56b1a3b12092c15fafcf8761._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="User expectations and what git annex unannex does."
+ date="2017-07-24T08:06:55Z"
+ content="""
+# Where we are
+
+@joey thank you for these explanations, more detailed than when I reported the same problem 8 months ago commenting https://git-annex.branchable.com/git-annex-unannex/ (@tom.prince had already written this page but I did not find it).
+
+Yet all this happens in a git world, where private history can be rewritten, so *there must be a simpler way*.
+
+# What people expect from \"undo accidental add command\"
+
+@tom.prince thanks for explaining what you expected `unannex` to do. Looks like I expected exactly the same behavior.
+
+IMHO current behavior of `git annex unannex` does not match what people expect of \"undo accidental add command\".
+
+# What current `git-annex unannex` actually does
+
+If behavior does not match words, perhaps behavior is interesting but should be matched with different words?
+
+Looking at what `git-annex unannex`, here are the words that came to mind:
+
+> git-annex unannex - turn a path which points to annexed content into a plain file that is store in regular git.
+
+Notice that:
+
+* `git-annex` retains history
+* other paths may still refer to the same content, so the annex may still contain a copy of the same data.  Else it becomes unused content subject to `git-annex dropunused`.
+
+Thank you for your attention.
+
+"""]]
diff --git a/doc/bugs/uninit_fails_when_I_symlink_your_symlink.mdwn b/doc/bugs/uninit_fails_when_I_symlink_your_symlink.mdwn
new file mode 100644
index 0000000000..1e3506cb40
--- /dev/null
+++ b/doc/bugs/uninit_fails_when_I_symlink_your_symlink.mdwn
@@ -0,0 +1,39 @@
+```
+$ mkdir annex-test
+$ cd annex-test/
+$ git init
+Initialized empty Git repository in /home/me/annex-test/.git/
+$ git annex init
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
+$ cat > .gitignore
+*
+$ cat > exampyle.txt
+hello
+$ git annex add --no-check-gitignore
+add .gitignore (non-large file; adding content to git repository) ok
+add exampyle.txt
+ok
+(recording state in git...)
+$ git commit -m \"added\"
+[master (root-commit) 2734615] added
+ 2 files changed, 2 insertions(+)
+ create mode 100644 .gitignore
+ create mode 120000 exampyle.txt
+$ ln -rs exampyle.txt what.foo
+$ git status
+On branch master
+nothing to commit, working tree clean
+$ git annex uninit
+git-annex: what.foo points to annexed content, but is not checked into git.
+Perhaps this was left behind by an interrupted git annex add?
+Not continuing with uninit; either delete or git annex add the file and retry.
+```
+What should I do?
+
+Honestly, I'm happy with git-annex so far, I'm just thinking that I need to re-init with `annex.tune.objecthashlower=true` because my other computer is windows.
+
+Thanks!
+
+> I see this was resolved as ok behavior, so [[done]] --[[Joey]]
diff --git a/doc/bugs/uninit_fails_when_I_symlink_your_symlink/comment_5_3fe7520813dee36ffb5419ed70ea43b5._comment b/doc/bugs/uninit_fails_when_I_symlink_your_symlink/comment_5_3fe7520813dee36ffb5419ed70ea43b5._comment
new file mode 100644
index 0000000000..7514aa5e68
--- /dev/null
+++ b/doc/bugs/uninit_fails_when_I_symlink_your_symlink/comment_5_3fe7520813dee36ffb5419ed70ea43b5._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="forgot to add the new ignored link + shortcoming of 'ln' command"
+ date="2023-11-20T10:25:52Z"
+ content="""
+You forgot to add your (gitignore'd) `what.foo` to git. Another `git annex add --no-check-gitignore;git commit -m \"add link\"` will make the subsequent `git annex uninit` work properly. This is also what the error message says, btw.
+
+But there's another problem underneath: Why is `what.foo` an annex-style symlink anyway? It should just point to `example.txt`, right?
+
+```
+🐟 ❯ ln -nrs example.txt what.foo
+yann in yann-desktop-nixos in …/uninit-test on  main 
+🐟 ❯ ls -l
+lrwxrwxrwx 186 yann users 20 Nov 11:08  example.txt -> .git/annex/objects/mK/4w/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.txt/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.txt
+lrwxrwxrwx 186 yann users 20 Nov 11:08  what.foo -> .git/annex/objects/mK/4w/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.txt/SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.txt
+```
+
+For some reason `ln` dereferences `example.txt` before linking, resulting in `what.foo` pointing to the same as `example.txt` -- not just to `example.txt` -- causing `what.foo` to look exactly like an annex link. I thought `-n` could fix this, but it would operate on the target `what.foo`, not the source `example.txt` 🤦. I couldn't make `ln` do this properly, except for renaming/removing `example.txt`, then `ln -rsf example.txt what.foo`, then restoring `example.txt`. Not viable. A better solution is `cp -s example.txt what.foo`. That will make `what.foo` point properly to just `example.txt` and not *its* target.
+
+BTW you can still just `git add` things like normal non-annex symlinks like `what.foo`, no need for `git annex add` here.
+
+Also, joey prefers to have bug reports/questions and the like in either [[todo]], [[bugs]] or [[forum]], because it's clear those are the places to look through for issues. Comments below random manpages are quick to be forgotten about. 🙂
+"""]]
diff --git a/doc/bugs/uninit_fails_when_I_symlink_your_symlink/comment_6_3afdea4f3705a9cfaa971ed3aa9f114c._comment b/doc/bugs/uninit_fails_when_I_symlink_your_symlink/comment_6_3afdea4f3705a9cfaa971ed3aa9f114c._comment
new file mode 100644
index 0000000000..d1109eb926
--- /dev/null
+++ b/doc/bugs/uninit_fails_when_I_symlink_your_symlink/comment_6_3afdea4f3705a9cfaa971ed3aa9f114c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="NewUser"
+ nickname="dont.post.me"
+ avatar="http://cdn.libravatar.org/avatar/90f59ddc341eaf9b2657422206c06901"
+ subject="comment 6"
+ date="2023-11-20T13:17:03Z"
+ content="""
+Thank you for the illuminating comment!
+
+> This is also what the error message says, btw.
+
+    Not continuing with uninit; either delete or git annex add the file and retry.
+
+You&rsquo;re right! I thought I only had a relative symlink pointing to the other symlink and not pointing into .git/annex/objects. It turns out that this is true for most of my symlinks but, just like you pointed out, some of them were pointing into .git/annex and the right thing to do there is to `add` them.
+
+Also, thank you for pointing me towards todo/bugs/forum!
+
+"""]]
diff --git a/doc/bugs/unlocked_files_feel_too_slow_.mdwn b/doc/bugs/unlocked_files_feel_too_slow_.mdwn
new file mode 100644
index 0000000000..cf9ba5162f
--- /dev/null
+++ b/doc/bugs/unlocked_files_feel_too_slow_.mdwn
@@ -0,0 +1,35 @@
+### Please describe the problem.
+
+I recently switched a large (~6TiB) video repository from "normal" to "unlocked" mode, mainly because some external tool was getting confused by symlinks.
+
+As a result, all remotes related to that repositories have this painful, multi-hour process by which they convert their work tree to follow the new layout. That, in itself, is disturbingly slow, with little progress shown to the user. In fact, I often fear that git-annex is messing up and actually adding files as git blobs itself, which makes me interrupt it and start over again, which, obviously, makes things much worse.
+
+But there are other weird things. At the moment, I'm copying files from my laptop with:
+
+    git annex copy --from angela -J2
+
+Being worried about the lack of progress, I interrupted it and ran instead:
+
+    git annex copy --from angela -J2 --not --in here --in angela
+
+That command generated zero output for 12 minutes straight. Looking at strace, it seemed to have read a large number of files in `.git/annex/objects`, which is slow.
+
+Another example is, after the above command completed, i ran `git annex sync -g`, which i expected to take a handful of seconds, but the first line was a `commit` that took nearly a minute.
+
+### What steps will reproduce the problem?
+
+It's not quite clear to me how to reproduce this from scratch. I guess convert an existing large repo?
+
+### What version of git-annex are you using? On what operating system?
+
+10.20230802-1~bpo12+1 on debian bookworm.
+
+### Please provide any additional information below.
+
+Not sure what could help here. Maybe having more feedback on what's actually happening in those minutes-long stretches would help. Git, for example, has a percentage/object count thing that pops up when things like `git status` take too long. I would love to see something similar here.
+
+Also, I understand the [[todo/git_smudge_clean_interface_suboptiomal]] problem, and this might just be a specific manifestation of it. It still seems to me having some feedback, if even around the git filter boundaries, would alleviate some of those problems.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I use git-annex daily, and it's a lifesaver. :)
diff --git a/doc/bugs/unnecessary_work_when_drop_cannot_possibly_succeed.mdwn b/doc/bugs/unnecessary_work_when_drop_cannot_possibly_succeed.mdwn
new file mode 100644
index 0000000000..d8d5f49cc7
--- /dev/null
+++ b/doc/bugs/unnecessary_work_when_drop_cannot_possibly_succeed.mdwn
@@ -0,0 +1,30 @@
+When annex.numcopies is 4, and there are only 4 copies of a file,
+`git-annex drop` behaves like this:
+
+	drop me (locking a2...) (locking a3...) (locking a4...) (unsafe)
+	  Could only verify the existence of 3 out of 4 necessary copies
+
+That is unnecessary work, because the drop cannot possibly succeed when
+there are not more than numcopies. It should be able to skip locking the
+content on remotes and immediately fail. 
+
+A user reported a situation where this happened to a lot of files and
+caused rate limiting and slowed down git-annex sync. --[[Joey]]
+
+> I started to implement making `git-annex drop` check if it could
+> possibly succeed before starting locking content, and found that
+> it was complicating it with a lot of fairly redundant code.
+> 
+> And since this command is run usually by the user when they really
+> want to drop something, not in a more general situation like git-annex
+> sync is, it seems ok for it to do a little bit of extra work,
+> showing what remotes it's able to lock, before failing, even though it
+> was always going to fail in the end. And if the user wants it to avoid
+> that, they can use `--auto`, which already avoids doing anything when it
+> cannot succeed.
+> 
+> So, I've decided to leave git-annex drop as it is. But what about
+> git-annex sync? I tried it, and when there are not enough copies it does
+> not appear to try to drop at all. 
+> 
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD.mdwn b/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD.mdwn
new file mode 100644
index 0000000000..7059e00c06
--- /dev/null
+++ b/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD.mdwn
@@ -0,0 +1,46 @@
+On DragonflyBSD with git-annex built with ghc 8.10.7, a simple `git annex add` puts strange entries in the index, as shown:
+
+```
+copter-dfly tmp $ mkdir d
+copter-dfly tmp $ cd d
+copter-dfly d $ git init
+Initialized empty Git repository in /home/falsifian/tmp/d/.git/
+copter-dfly d $ git annex init
+init  ok
+(recording state in git...)
+copter-dfly d $ echo test>f
+copter-dfly d $ git annex add f
+add f
+ok
+(recording state in git...)
+copter-dfly d $ git status
+On branch master
+
+No commits yet
+
+Changes to be committed:
+  (use "git rm --cached <file>..." to unstage)
+        new file:   30d/f3a/SHA256-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2.log
+        new file:   f
+        new file:   uuid.log
+
+Changes not staged for commit:
+  (use "git add/rm <file>..." to update what will be committed)
+  (use "git restore <file>..." to discard changes in working directory)
+        deleted:    30d/f3a/SHA256-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2.log
+        deleted:    uuid.log
+
+copter-dfly d $
+```
+
+Digging into it further with dfly people over IRC, it's been discovered:
+
+* The bug does not appear with ghc 8.10.5, with git-annex 20210903 or 20210223.
+* But it consistently happens with ghc 8.10.7, with all the versions I tried.
+* I also noticed that `git annex init` does not create the file `.git/annex/index` when the bug is present.
+
+Has anyone tried git-annex with ghc 8.10.7 on a different OS?
+
+I tried to figure out why `.git/annex/index` was not being created, but I had some trouble figuring out which line of code is supposed to create it. If someone could point me there I could do some further debugging to see why it isn't created.
+
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_1_70b807c69be263fd53c578fe6ec84561._comment b/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_1_70b807c69be263fd53c578fe6ec84561._comment
new file mode 100644
index 0000000000..2481394326
--- /dev/null
+++ b/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_1_70b807c69be263fd53c578fe6ec84561._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-12-31T15:05:40Z"
+ content="""
+It seems that somehow it is failing to set environment variables. Eg,
+`GIT_INDEX_FILE` is what makes git use `.git/annex/index` and if it was not
+set it would behave as you describe.
+
+This strongly suggests that there is a bug in the compiler/libraries.
+
+Here is a small test program:
+
+	import System.Environment
+	import System.Process
+	
+	main = do
+		let p = (proc "sh" ["-c", "echo testing: $TEST"])
+		let p' = p { env = Just [("TEST", "foo")] } 
+		withCreateProcess p' $ \_ _ _ pid -> waitForProcess pid
+		setEnv "TEST" "bar"
+		withCreateProcess p $ \_ _ _ pid -> waitForProcess pid
+
+If run with "runghc foo.hs", that should output "testing: foo" and then 
+"testing: bar".
+"""]]
diff --git a/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_2_eeff3cb51df849b783446e238de002a8._comment b/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_2_eeff3cb51df849b783446e238de002a8._comment
new file mode 100644
index 0000000000..da0d68bd57
--- /dev/null
+++ b/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_2_eeff3cb51df849b783446e238de002a8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-12-31T15:54:25Z"
+ content="""
+On Linux this problem does not occur. 
+
+I built git-annex with ghc-8.10.7 by changing the
+stack.yaml to use "resolver: lts-18.20" and running
+"stack build".
+"""]]
diff --git a/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_3_641473e43c8da7e7be02658cf8d3bd3e._comment b/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_3_641473e43c8da7e7be02658cf8d3bd3e._comment
new file mode 100644
index 0000000000..0e689741e4
--- /dev/null
+++ b/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_3_641473e43c8da7e7be02658cf8d3bd3e._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="falsifian"
+ avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae"
+ subject="comment 3"
+ date="2021-12-31T16:03:33Z"
+ content="""
+Looks like you are right. Thanks for the help! On DragonFlyBSD with ghc 8.10.7 I see:
+
+```
+copter-dfly tmp $ runghc foo.hs
+testing:
+testing: bar
+```
+
+I guess it is time to look at the `System.Process` module.
+"""]]
diff --git a/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_4_59e2ea4d59d5f4a8472cc8c945b8a419._comment b/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_4_59e2ea4d59d5f4a8472cc8c945b8a419._comment
new file mode 100644
index 0000000000..75d4e2c10c
--- /dev/null
+++ b/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_4_59e2ea4d59d5f4a8472cc8c945b8a419._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-12-31T19:00:10Z"
+ content="""
+Upstream bug report: <https://github.com/haskell/process/issues/223>
+"""]]
diff --git a/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_5_27a017a942f805e9b0216e77d4890c86._comment b/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_5_27a017a942f805e9b0216e77d4890c86._comment
new file mode 100644
index 0000000000..3b9278918a
--- /dev/null
+++ b/doc/bugs/unusable_with_ghc_8.10.7_on_DragonFlyBSD/comment_5_27a017a942f805e9b0216e77d4890c86._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="falsifian"
+ avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae"
+ subject="comment 5"
+ date="2022-01-03T19:06:11Z"
+ content="""
+This turned out to a bug in DragonFlyBSD. It is [now fixed](https://gitweb.dragonflybsd.org/dragonfly.git/commit/8202da125af7f265528f7844bdc98d544a320bd1). Thanks for your help finding the problem!
+"""]]
diff --git a/doc/bugs/use_reflink_to_export_to_directory_special_remote.mdwn b/doc/bugs/use_reflink_to_export_to_directory_special_remote.mdwn
new file mode 100644
index 0000000000..e716fceb22
--- /dev/null
+++ b/doc/bugs/use_reflink_to_export_to_directory_special_remote.mdwn
@@ -0,0 +1,44 @@
+I'm using version `10.20230321-gb624394c7` on Arch Linux and BTRFS.
+I'd love to have the directory special remote using `cp --reflink=auto` to export to a directory on the same file system.
+
+My use case is using syncthing as a way to export (parts of my repo) to my phone.
+I'm deliberately not using `adb` as this needs my phone to be connected to the computer somehow.
+I basically want to do what's described on [syncthing special remote](/todo/syncthing_special_remote/#index2h2) under “Copying objects”.
+
+The main drawback, as also noted in the linked document, is that all files are duplicated.
+As I'm using BTRFS it would really help if the `export` were to use `cp --reflink=auto` instead of its own copying mechanism.
+I've read [here](/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/) that you suggested (albeit 7 years ago) using a shared clone instead.
+However, this does not work for me as syncthing does not synchronize symlinks to Android (they are ignored even if they point to something).
+(Trying with a shared repo and `adjust --unlock-present` gives merge problems when dropping files from the directory.)
+
+Nearly two years ago, you wrote [here](/todo/import_from_directory_does_not_use_cp_--reflink__63___/) that you “Implemented CoW for directory special remote, comprehensively”.
+It seems to me that this is only true for importing files which, as I checked, actually uses cow.
+
+Since I want to manage relatively many files of decent size (music, audio books, pictures, videos / movies) it would be much better if the tree export would also use reflink.
+Maybe having this as an option, for the cost of not having a nice progress bar, would be something worth considering.
+
+A test script to show that an export does indeed use cow is the following:
+
+```bash
+mkdir export import
+git init repo
+cd repo
+git annex init
+git annex initremote import type=directory directory=../import encryption=none importtree=yes
+git annex initremote export type=directory directory=../export encryption=none exporttree=yes
+git config remote.import.annex-tracking-branch main
+git config remote.export.annex-tracking-branch main
+
+for i in {1..100}; do
+    dd if=/dev/urandom bs=1M count=10 of=../import/file$i
+done
+    
+git annex sync --content
+```
+After running, a `btrfs filesystem du ...` tells me that the `repo` and `import` files point to the same file, whereas `export` does not.
+
+---
+
+In general: Thank you so much for this wonderful piece of software, I'm using it for years now and manage virtually everything with it (audio, video, pictures, important documents, papers, …).
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/using_old_remote_format_generates_irritating_output.mdwn b/doc/bugs/using_old_remote_format_generates_irritating_output.mdwn
new file mode 100644
index 0000000000..1809ade37e
--- /dev/null
+++ b/doc/bugs/using_old_remote_format_generates_irritating_output.mdwn
@@ -0,0 +1,30 @@
+a special remote (encrypted rsync) that got copied to long ago (not sure when, there are old files that already have sizes in their unencrypted file names) seems to use the aa/bb/GPGHMACSHA1-- format instead of aaa/bbb/GPGHMACSHA1-. ``git annex fsck`` over such files produces very irritating output:
+
+<code>
+fsck L1100423.JPG (gpg) (checking …remote…...) 
+rsync: change_dir "…somewhere…/0a0/8cd/GPGHMACSHA1--91234b770b34eeff811d09c97ce94bb2398b3d72" failed: No such file or directory (2)
+
+sent 8 bytes  received 12 bytes  40.00 bytes/sec
+total size is 0  speedup is 0.00
+rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1536) [Receiver=3.0.9]
+
+  rsync failed -- run git annex again to resume file transfer
+
+GPGHMACSHA1--91234b770b34eeff811d09c97ce94bb2398b3d72
+     3922730 100%  623.81kB/s    0:00:06 (xfer#1, to-check=0/1)
+
+sent 30 bytes  received 3923328 bytes  523114.40 bytes/sec
+total size is 3922730  speedup is 1.00
+(checksum...) ok
+</code>
+
+(observed with debian's git-annex 3.20121017).
+
+while this does output an "ok" at th end and a zero exit status, having such messages in an fsck is highly irritating.
+
+i see two ways to enhance the situation:
+
+* silence the "not found" error when the file is found in another location
+* a way to rename the files in the remote (i guess the aaa/bbb part can be derived from the file name; in that case, that could even be done w/o network interaction).
+
+[[!tag confirmed]]
diff --git a/doc/bugs/using_old_remote_format_generates_irritating_output/comment_1_fceba878f1097e27f056580e8d6d5b31._comment b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_1_fceba878f1097e27f056580e8d6d5b31._comment
new file mode 100644
index 0000000000..d2208b57b4
--- /dev/null
+++ b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_1_fceba878f1097e27f056580e8d6d5b31._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="also affects `git annex get`"
+ date="2012-11-12T23:11:36Z"
+ content="""
+the same problem also shows up with `git annex get`:
+
+    get …filename… (from prometheus...) 
+    rsync: change_dir \"/home/shared/photos/encrypted_storage/63e/50b/GPGHMACSHA1--b83e8aaf05918ae2fc81652368f9d4068f938625\" failed: No such file or directory (2)
+    
+    sent 8 bytes  received 12 bytes  8.00 bytes/sec
+    total size is 0  speedup is 0.00
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1536) [Receiver=3.0.9]
+    
+      rsync failed -- run git annex again to resume file transfer
+    
+    GPGHMACSHA1--b83e8aaf05918ae2fc81652368f9d4068f938625
+          513214 100%   95.68kB/s    0:00:05 (xfer#1, to-check=0/1)
+    
+    sent 30 bytes  received 513396 bytes  44645.74 bytes/sec
+    total size is 513214  speedup is 1.00
+    ok
+
+again, it says \"ok\", but the \"no such file or directory\" / \"rsync failed\" is visually more prominent.
+"""]]
diff --git a/doc/bugs/using_old_remote_format_generates_irritating_output/comment_2_416992874813f120721a56d88b2bef65._comment b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_2_416992874813f120721a56d88b2bef65._comment
new file mode 100644
index 0000000000..1dfd0bde72
--- /dev/null
+++ b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_2_416992874813f120721a56d88b2bef65._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.11.120"
+ subject="comment 2"
+ date="2012-11-13T17:27:31Z"
+ content="""
+So, I don't know how to suppress this message without causing worse problems, like suppressing real error messages, and even password prompts.
+
+"""]]
diff --git a/doc/bugs/using_old_remote_format_generates_irritating_output/comment_3_a20f470c5226ac5693eb15146a02b3f5._comment b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_3_a20f470c5226ac5693eb15146a02b3f5._comment
new file mode 100644
index 0000000000..8ee00709d8
--- /dev/null
+++ b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_3_a20f470c5226ac5693eb15146a02b3f5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="comment 3"
+ date="2012-11-14T07:31:11Z"
+ content="""
+how about renaming the stored files, them? if you give me a pointer on how the directory names are generated, i can write a script that does the migration (some hash of the file name?). i suppose that's just a relic from another naming scheme, isn't it?
+"""]]
diff --git a/doc/bugs/using_old_remote_format_generates_irritating_output/comment_4_a81f06191bc03a7aad5929af99f0634e._comment b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_4_a81f06191bc03a7aad5929af99f0634e._comment
new file mode 100644
index 0000000000..9ea8047678
--- /dev/null
+++ b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_4_a81f06191bc03a7aad5929af99f0634e._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.11.120"
+ subject="comment 4"
+ date="2012-11-14T17:31:38Z"
+ content="""
+The new hash directory tree is generated in a simple to explain way. Take the md5sum of the key and the first 3 characters are the first directory, and the next 3 characters are the second directory.
+
+The old hash directory tree is rather harder to explain. It takes the md5sum of the key, but rather than a string, represents it as 4 32bit words. Only the first word is used. It is converted into a string by the same mechanism that would be used to encode a normal md5sum value into a string, but where that would normally encode the bits using the 16 characters 0-9a-f, this instead uses the 32 characters \"0123456789zqjxkmvwgpfZQJXKMVWGPF\". The first 2 letters of the resulting string are the first directory, and the second 2 are the second directory.
+
+There's probably a 1:1 mapping between this special md5 encoding an a regular md5 encoding. But it's certainly easier just to use the existing Haskell implementation of the hash. The following program, which needs to be built inside a git-annex source tree, reads keys on stdin, and outputs their old hash directory tree values, and their new values on stdout.
+
+<pre>
+import Locations
+import Types.Key
+import Utility.Misc
+
+main = interact $ \s -> case file2key $ firstLine s of
+        Nothing -> \"bad key\"
+        Just k -> hashDirMixed k ++ \" \" ++ hashDirLower k ++ \"\n\"
+</pre>
+
+<pre>
+joey@gnu:~/src/git-annex>ghc --make convert.hs
+joey@gnu:~/src/git-annex>echo WORM--foo | ./ convert
+jq/8w/ 2b1/ba3/
+</pre>
+"""]]
diff --git a/doc/bugs/using_old_remote_format_generates_irritating_output/comment_5_7438caecf78b4fb5d21f9f31dff95cf2._comment b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_5_7438caecf78b4fb5d21f9f31dff95cf2._comment
new file mode 100644
index 0000000000..707ea52cf9
--- /dev/null
+++ b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_5_7438caecf78b4fb5d21f9f31dff95cf2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="single-line migration"
+ date="2012-11-22T03:14:45Z"
+ content="""
+i've successfully applied this monster to migrate my repository (as always with such expressions, use it only if you know what it does, and have a backup):
+
+    find . -path './??/??/*' -type d \( -exec python -c 'import sys, hashlib, os; hash = hashlib.md5(sys.argv[1][8:]).hexdigest(); h1 = hash[:3]; h2 = hash[3:6]; os.mkdir(h1) if not os.path.exists(h1) else None; os.mkdir(h1+\"/\"+h2) if not os.path.exists(h1+\"/\"+h2) else None; os.rename(sys.argv[1], h1+\"/\"+h2+\"/\"+sys.argv[1][8:])' '{}' ';' -o -print \) -prune
+
+when executed in an encrypted git annex object directory, it takes all two-letter directories, executes a python expression on them (in case of failure, printing the file name it failed on), and doesn't continue searching there (-prune avoids error messages about moved-away directories).
+
+the python expression itself generates the hash described above, generates the required directories (put awkwardly in an `a if b else c` expression to avoid ifs (which wouldn't fit in a single line) and because python still doesn't have a proper mkdir-p function), and moves the found object there. (nb: using the system's `mkdir -p` would trigger [[another bug|bugs/using_old_remote_format_generates_irritating_output]]).
+"""]]
diff --git a/doc/bugs/v6_appears_to_not_thin.mdwn b/doc/bugs/v6_appears_to_not_thin.mdwn
new file mode 100644
index 0000000000..7ccf06d026
--- /dev/null
+++ b/doc/bugs/v6_appears_to_not_thin.mdwn
@@ -0,0 +1,80 @@
+[[!meta title="v6 does not thin on hyperv"]]
+
+### Please describe the problem.
+
+First of all, I don't really believe the following is a good bug report, from my own career in SW development. I know what to do. However, this is a start to test the waters; I received no response in the general forum (not a complaint), but I am not sure if this is simply one of those issues for which the solution is so simple, that no one can bring themselves to reply.
+
+I can provide further detail, like console copies, but I figured that providing the config output to be a good first step. Apologies for the format of the config file: it was copied fine, but pasted on one line.
+
+
+It seems thinning is not doing what I expected:
+
+Which is: unlocking a file creates a hard link in the working directory, linked to the annex file, with the resulting dir size being the size of the one big file.
+
+Are my expectations correct?
+
+Is there something I am missing?
+
+
+
+### What steps will reproduce the problem?
+
+copied a big file to the working directory
+
+git add; git commit
+
+Locking the big file creates the symlink, with the file in the annex.
+
+Unlocking the big file creates a real file in the working dir, and the annex file stays there.
+
+The total dir is therefore twice the size of the big file.
+
+ls -li shows a unique inode for each file. Therefore it appears to not be a hard link.
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 6.20160524+gitg2b7b2c4-1~ndall+1
+
+Debian 8.5
+
+
+### Please provide any additional information below.
+
+repo config file:
+
+[core] 
+repositoryformatversion = 0 
+filemode = true 
+bare = false 
+logallrefupdates = true 
+
+[annex] 
+uuid = c5c203ec-9353-4213-8af5-6fcb8de36ca2 
+version = 6 
+thin = true 
+
+[filter "annex"] 
+smudge = git-annex smudge %f 
+clean = git-annex smudge --clean %f
+
+
+
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+You bet. It is simply great. I am in the process of migrating all my big data. I have roughly 6TB, and it is taking me many weeks.
+
+I am creating a typical duplicate topology. 2 remotes, 2 backup nodes. Multiple clients, each connected to the 2 remotes. Each client will only clone the repos or parts thereof that are relevant to that client.
+
+I have multiple clients on multiple VMs. I generally separate functions to VMs. I.e. postgresql to a pair of VMs; etc. Poorly behaving apps like iTunes to its very own penalty box win VM. HA to its own VM. etc.
+
+
diff --git a/doc/bugs/v6_appears_to_not_thin/comment_1_d62791da504f6cf9bb26fa588756234c._comment b/doc/bugs/v6_appears_to_not_thin/comment_1_d62791da504f6cf9bb26fa588756234c._comment
new file mode 100644
index 0000000000..c2d5a804e1
--- /dev/null
+++ b/doc/bugs/v6_appears_to_not_thin/comment_1_d62791da504f6cf9bb26fa588756234c._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-06T18:42:47Z"
+ content="""
+annex.thin can only work on filesystems that support hard links,
+so the most likely reason, from the information you have given,
+is that the repository is on a FAT or other non-hard-link supporting
+filesystem.
+
+	joey@darkstar:~/tmp/xxx>date > bigfile
+	joey@darkstar:~/tmp/xxx>git annex add bigfile
+	add bigfile ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/xxx>git commit -m add
+	[master 39d19a4] add
+	 1 file changed, 1 insertion(+), 1 deletion(-)
+	 rewrite bigfile (100%)
+	 mode change 100644 => 120000
+	joey@darkstar:~/tmp/xxx>git annex unlock bigfile
+	unlock bigfile ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/xxx>ls -l bigfile
+	-rw-r--r-- 2 joey joey 30 Jul  6 14:46 bigfile
+
+It's working fine here as seen by the fact that bigfile
+has a link count of 2 after being unlocked.
+
+Other possibilies:
+
+* If the repository was cloned using `git clone --shared`,
+  annex.thin is not supported.
+* If there are multiple files in the working tree that have the same
+  content, annex.thin will only hard link one of them; the others
+  will be non-thin copies.
+"""]]
diff --git a/doc/bugs/v6_appears_to_not_thin/comment_2_82ff17c4063791d91a4fbe4e31802595._comment b/doc/bugs/v6_appears_to_not_thin/comment_2_82ff17c4063791d91a4fbe4e31802595._comment
new file mode 100644
index 0000000000..e6093c2159
--- /dev/null
+++ b/doc/bugs/v6_appears_to_not_thin/comment_2_82ff17c4063791d91a4fbe4e31802595._comment
@@ -0,0 +1,82 @@
+[[!comment format=mdwn
+ username="Stan"
+ subject="Success / failure scenarios"
+ date="2016-07-07T23:29:19Z"
+ content="""
+Thanks again Joey. My progress is detailed below. I can run/collect more detailed scenarios if it will help.
+
+Summary:
+
+Success with a VM on qemu.
+Failure with VMs on hyperv.
+
+* Hardlinks are not created for the VMs on hyperv, in spite of the VM filesystems being ext4.
+* This may only be associative, and not causal, but it is somewhat surprising. Yet, I am no hardlink expert.
+* I can however make it work if I use a VM on qemu, so far; so that is very good.
+
+Setup:
+
+* mkdir gitx1
+* git init
+* git annex init --version=6
+* git config annex.thin true
+* git annex fix
+* copy bigfile to gitx1
+* git annex add bigfile
+* git commit -m add
+* ls -li
+
+Test Procedure:
+
+* unlock bigfile
+* ls -li
+
+Pass criteria:
+
+* ls -li shows 2 links and the inode matches the SHA file inode in annex/objects/
+* gitx1 dir size is equal to one bigfile
+
+
+Fail criteria:
+
+* ls -li shows 1 link and the inode numbers are different: working dir compared to annex/objects
+* gitx1 dir size is equal to 2 bigfiles.
+
+
+Scenario 1:
+
+* VM arch linux
+* git-annex: 6.20160613-g1e4e6f4
+* Host: Centos, qemu
+* gnome-disk-utility: QEMU HARDDISK (1.5.3)
+* partition: MBR
+* file system: ext4
+* Result: Pass
+
+
+Scenario 2:
+
+* VM arch linux
+* git-annex: 6.20160613-g1e4e6f4
+* Host: Win10, hyperv
+* gnome-disk-utility: Msft Virtual Disk (1.0)
+* partition: MBR
+* file system: ext4
+* Result: Fail
+
+
+Scenario 3:
+
+* VM Debian 8.5
+* git-annex: 6.20160524+gitg2b7b2c4-1~ndall+1
+* Host: Win10, hyperv
+* gnome-disk-utility: /dev/...vg/root
+* partition: lvm
+* file system: ext4
+* Result: Fail
+
+
+
+
+
+"""]]
diff --git a/doc/bugs/v6_appears_to_not_thin/comment_3_69afd9bc3f250418ba33cb1abeb2078d._comment b/doc/bugs/v6_appears_to_not_thin/comment_3_69afd9bc3f250418ba33cb1abeb2078d._comment
new file mode 100644
index 0000000000..2c95022290
--- /dev/null
+++ b/doc/bugs/v6_appears_to_not_thin/comment_3_69afd9bc3f250418ba33cb1abeb2078d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Stan"
+ subject="Hardlinks on hyperv VM"
+ date="2016-07-08T00:27:11Z"
+ content="""
+I am actually able to manually create hardlinks on all of the VMs in the tests.
+I did so with files I created outside any git dirs.
+"""]]
diff --git a/doc/bugs/v6_appears_to_not_thin/comment_4_bba7ba9c5b93fa33fc728daa0bb89497._comment b/doc/bugs/v6_appears_to_not_thin/comment_4_bba7ba9c5b93fa33fc728daa0bb89497._comment
new file mode 100644
index 0000000000..c3d4833c62
--- /dev/null
+++ b/doc/bugs/v6_appears_to_not_thin/comment_4_bba7ba9c5b93fa33fc728daa0bb89497._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-07-11T16:23:57Z"
+ content="""
+Well, certinaly seems that hyperv is doing something to the environment
+that causes the problem. 
+
+I don't know anything about hyperv, so cannot venture an educated guess.
+But there are only three reasons that git-annex might not make hard links,
+assuming it's seeing the annex.thin setting:
+
+1. It thinks that the file already has a link count of more than 1.
+2. It tries to create a hard link, but that fails for some reason,
+   and so it falls back to a copy.
+3. It successfully creates a hard link, but code that tries to preserve
+   the mode of the file fails for some reason, and so it falls back to a
+   copy.
+
+Getting a `strace -v` might help narrow it down. Here for reference is a
+strace of the hard link successfully being made:
+
+	32624 stat(".git/annex/objects/P7/mF/SHA256E-s30--c5e0f3090f3658e908aa0a02bfc7eeb3e203c67c8ecd86c7acd501a32454ed6a/SHA256E-s30--c5e0f3090f3658e908aa0a02bfc7eeb3e203c67c8ecd86c7acd501a32454ed6a", {st_dev=makedev(8, 3), st_ino=3675012, st_mode=S_IFREG|0444, st_nlink=1, st_uid=1000, st_gid=1000, st_blksize=4096, st_blocks=8, st_size=30, st_atime=2016/07/11-12:30:25.203217806, st_mtime=2016/07/11-12:27:58.523091486, st_ctime=2016/07/11-12:30:25.207217809}) = 0
+	32624 link(".git/annex/objects/P7/mF/SHA256E-s30--c5e0f3090f3658e908aa0a02bfc7eeb3e203c67c8ecd86c7acd501a32454ed6a/SHA256E-s30--c5e0f3090f3658e908aa0a02bfc7eeb3e203c67c8ecd86c7acd501a32454ed6a", ".git/annex/misctmp/foo.0/foo") = 0
+	32624 stat(".git/annex/misctmp/foo.0/foo", {st_dev=makedev(8, 3), st_ino=3675012, st_mode=S_IFREG|0444, st_nlink=2, st_uid=1000, st_gid=1000, st_blksize=4096, st_blocks=8, st_size=30, st_atime=2016/07/11-12:30:25.203217806, st_mtime=2016/07/11-12:27:58.523091486, st_ctime=2016/07/11-12:30:49.819239094}) = 0
+	32624 stat(".git/annex/misctmp/foo.0/foo", {st_dev=makedev(8, 3), st_ino=3675012, st_mode=S_IFREG|0444, st_nlink=2, st_uid=1000, st_gid=1000, st_blksize=4096, st_blocks=8, st_size=30, st_atime=2016/07/11-12:30:25.203217806, st_mtime=2016/07/11-12:27:58.523091486, st_ctime=2016/07/11-12:30:49.819239094}) = 0
+	32624 chmod(".git/annex/misctmp/foo.0/foo", 0100644) = 0
+	32624 stat(".git/annex/objects/P7/mF/SHA256E-s30--c5e0f3090f3658e908aa0a02bfc7eeb3e203c67c8ecd86c7acd501a32454ed6a/SHA256E-s30--c5e0f3090f3658e908aa0a02bfc7eeb3e203c67c8ecd86c7acd501a32454ed6a", {st_dev=makedev(8, 3), st_ino=3675012, st_mode=S_IFREG|0644, st_nlink=2, st_uid=1000, st_gid=1000, st_blksize=4096, st_blocks=8, st_size=30, st_atime=2016/07/11-12:30:25.203217806, st_mtime=2016/07/11-12:27:58.523091486, st_ctime=2016/07/11-12:30:49.819239094}) = 0
+	32624 stat(".git/annex/misctmp/foo.0/foo", {st_dev=makedev(8, 3), st_ino=3675012, st_mode=S_IFREG|0644, st_nlink=2, st_uid=1000, st_gid=1000, st_blksize=4096, st_blocks=8, st_size=30, st_atime=2016/07/11-12:30:25.203217806, st_mtime=2016/07/11-12:27:58.523091486, st_ctime=2016/07/11-12:30:49.819239094}) = 0
+	32624 rename(".git/annex/misctmp/foo.0/foo", "foo") = 0
+"""]]
diff --git a/doc/bugs/v8_repo_auto_upgrades_to_v10.mdwn b/doc/bugs/v8_repo_auto_upgrades_to_v10.mdwn
new file mode 100644
index 0000000000..c9f294ed92
--- /dev/null
+++ b/doc/bugs/v8_repo_auto_upgrades_to_v10.mdwn
@@ -0,0 +1,19 @@
+### Please describe the problem.
+
+v8 repo automatically upgrades to v10 which is contrary to what the changelog states here [[news/version_10.20220822]].
+
+### What steps will reproduce the problem?
+
+```
+git init
+git annex init --version 8
+git config annex.version
+git annex info > /dev/null
+git config annex.version
+```
+
+### What version of git-annex are you using? On what operating system?
+
+10.20220822 Linux
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/v8_repo_auto_upgrades_to_v10/comment_1_446aa74f0b54918dc8737483e3e8564a._comment b/doc/bugs/v8_repo_auto_upgrades_to_v10/comment_1_446aa74f0b54918dc8737483e3e8564a._comment
new file mode 100644
index 0000000000..c9f786c0bd
--- /dev/null
+++ b/doc/bugs/v8_repo_auto_upgrades_to_v10/comment_1_446aa74f0b54918dc8737483e3e8564a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-26T16:15:41Z"
+ content="""
+This was broken in [[!commit 0d2e3058ee01d55dc3b929ddf8e0573a95a2ca85]]
+which was included in version 10.20220822.
+
+I've reverted the commit as a first step. This means repos initialized
+at v9 will never autoupgrade to v10, which will need to be fixed
+somehow. (Update: Fixed that now.)
+
+Gonna need to make a git-annex release ASAP to get this fix out there.
+"""]]
diff --git a/doc/bugs/vicfg_and_description_often_not_propagated.mdwn b/doc/bugs/vicfg_and_description_often_not_propagated.mdwn
new file mode 100644
index 0000000000..7e6dd9269e
--- /dev/null
+++ b/doc/bugs/vicfg_and_description_often_not_propagated.mdwn
@@ -0,0 +1,154 @@
+### Please describe the problem.
+
+I can change the settings in one repo and sync it everywhere. Just to be surprised that one repo starts syncing to the transfer, every time it turns out that this repo lost its vicfg settings. Especially the Repository preferred contents are all back on standard. It was even once that it had the current settings and after the change and sync it goes back to some older state instead of the new one.
+
+### What steps will reproduce the problem?
+
+Well that is very hard. I have 8 repos and it happens randomly to some of them. I recreated all of them recently because I thought they are corrupt, that didn't help, just took me one week of time. It is also very hard to find a way to reproduce this because every vicfg causes a merge which takes minutes to hours.
+
+### What version of git-annex are you using? On what operating system?
+
+Linux: git-annex version: 5.20140412ubuntu1
+
+Mac OS: git-annex version: 5.20140717
+
+### Please provide any additional information below.
+
+Layout:
+
+transfer on rsync.net, conntented to that:
+
+ - Two OS X Clients
+
+ - Two Linux Archives
+
+My settings:
+
+
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+# git-annex configuration
+# 
+# Changes saved to this file will be recorded in the git-annex branch.
+# 
+# Lines in this file have the format:
+#   setting field = value
+
+# Repository trust configuration
+# (Valid trust levels: trusted semitrusted untrusted dead)
+# (for Music bei Pirmin)
+trust 0734498b-817c-419f-a0c0-660854dc7cbe = trusted
+# (for Music bei Jean (Willikins) [willikins])
+trust 20e9d2e5-9563-4507-82d5-bf8e23be29a5 = trusted
+# (for Music bei Jean (Willikins Clone))
+trust 6e3431e9-8ec2-404a-9c35-b967db63147d = trusted
+# (for Music bei Jean (Watson))
+trust a6febfa0-9fe5-4a65-95bb-dc255d87c2e2 = trusted
+# (for )
+trust dafe9a64-2480-40e2-9688-9f783577ef72 = dead
+# (for web)
+#trust 00000000-0000-0000-0000-000000000001 = semitrusted
+# (for music transfer via rsync.net [music_rsync])
+#trust 83c42610-42ad-459d-92a4-1aca2dfb97e1 = semitrusted
+
+# Repository groups
+# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted)
+# (Separate group names with spaces)
+# (for Music bei Jean (Willikins) [willikins])
+group 20e9d2e5-9563-4507-82d5-bf8e23be29a5 = archive
+# (for Music bei Jean (Willikins Clone))
+group 6e3431e9-8ec2-404a-9c35-b967db63147d = archive
+# (for )
+group 26d38f31-cb6c-412c-84ef-597d7959a680 = backup
+# (for Music bei Pirmin)
+group 0734498b-817c-419f-a0c0-660854dc7cbe = client
+# (for Music bei Jean (Watson))
+group a6febfa0-9fe5-4a65-95bb-dc255d87c2e2 = client
+# (for music transfer via rsync.net [music_rsync])
+group 83c42610-42ad-459d-92a4-1aca2dfb97e1 = transfer
+# (for )
+group dafe9a64-2480-40e2-9688-9f783577ef72 = unwanted
+# (for web)
+#group 00000000-0000-0000-0000-000000000001 = 
+
+# Repository preferred contents
+# (Set to "standard" to use a repository's group's preferred contents)
+# (for Music bei Jean (Willikins) [willikins])
+wanted 20e9d2e5-9563-4507-82d5-bf8e23be29a5 = (not (copies=archive:2 or copies=smallarchive:2)) or approxlackingcopies=2
+# (for Music bei Jean (Willikins Clone))
+wanted 6e3431e9-8ec2-404a-9c35-b967db63147d = (not (copies=archive:2 or copies=smallarchive:2)) or approxlackingcopies=2
+# (for music transfer via rsync.net [music_rsync])
+wanted 83c42610-42ad-459d-92a4-1aca2dfb97e1 = not (inallgroup=client and copies=archive:2 and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
+# (for Music bei Pirmin)
+wanted 0734498b-817c-419f-a0c0-660854dc7cbe = standard
+# (for )
+wanted 26d38f31-cb6c-412c-84ef-597d7959a680 = standard
+# (for )
+wanted dafe9a64-2480-40e2-9688-9f783577ef72 = standard
+# (for web)
+#wanted 00000000-0000-0000-0000-000000000001 = 
+# (for Music bei Jean (Watson))
+wanted a6febfa0-9fe5-4a65-95bb-dc255d87c2e2 = standard
+
+# Group preferred contents
+# (Used by repositories with "groupwanted" in their preferred contents)
+#groupwanted archive = 
+#groupwanted backup = 
+#groupwanted client = 
+#groupwanted incrementalbackup = 
+#groupwanted manual = 
+#groupwanted public = 
+#groupwanted smallarchive = 
+#groupwanted source = 
+#groupwanted transfer = 
+#groupwanted unwanted = 
+
+# Standard preferred contents
+# (Used by wanted or groupwanted expressions containing "standard")
+# (For reference only; built-in and cannot be changed!)
+# standard client = (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1
+# standard transfer = (not (inallgroup=client and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)) or approxlackingcopies=1
+# standard backup = include=* or unused
+# standard incrementalbackup = ((include=* or unused) and (not copies=incrementalbackup:1)) or approxlackingcopies=1
+# standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1
+# standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1
+# standard source = not (copies=1)
+# standard manual = present and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
+# standard public = inpreferreddir
+# standard unwanted = exclude=*
+
+# Repository required contents
+# (for web)
+#required 00000000-0000-0000-0000-000000000001 = 
+# (for Music bei Pirmin)
+#required 0734498b-817c-419f-a0c0-660854dc7cbe = 
+# (for Music bei Jean (Willikins) [willikins])
+#required 20e9d2e5-9563-4507-82d5-bf8e23be29a5 = 
+# (for Music bei Jean (Willikins Clone))
+#required 6e3431e9-8ec2-404a-9c35-b967db63147d = 
+# (for music transfer via rsync.net [music_rsync])
+#required 83c42610-42ad-459d-92a4-1aca2dfb97e1 = 
+# (for Music bei Jean (Watson))
+#required a6febfa0-9fe5-4a65-95bb-dc255d87c2e2 = 
+
+# Scheduled activities
+# (Separate multiple activities with "; ")
+# (for web)
+#schedule 00000000-0000-0000-0000-000000000001 = 
+# (for Music bei Pirmin)
+#schedule 0734498b-817c-419f-a0c0-660854dc7cbe = 
+# (for Music bei Jean (Willikins) [willikins])
+#schedule 20e9d2e5-9563-4507-82d5-bf8e23be29a5 = 
+# (for Music bei Jean (Willikins Clone))
+#schedule 6e3431e9-8ec2-404a-9c35-b967db63147d = 
+# (for music transfer via rsync.net [music_rsync])
+#schedule 83c42610-42ad-459d-92a4-1aca2dfb97e1 = 
+# (for Music bei Jean (Watson))
+#schedule a6febfa0-9fe5-4a65-95bb-dc255d87c2e2 =
+# End of transcript or log.
+"""]]
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/vicfg_and_description_often_not_propagated/comment_1_60c5ba2de0c8b9b4538a4abd146007f6._comment b/doc/bugs/vicfg_and_description_often_not_propagated/comment_1_60c5ba2de0c8b9b4538a4abd146007f6._comment
new file mode 100644
index 0000000000..47c2de6f14
--- /dev/null
+++ b/doc/bugs/vicfg_and_description_often_not_propagated/comment_1_60c5ba2de0c8b9b4538a4abd146007f6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.132"
+ subject="comment 1"
+ date="2014-09-11T18:11:43Z"
+ content="""
+vicfg makes changes to files in the git-annex branch, so you can use regular git commands to examine those changes, and look through the history to find any changes that are contrary to the settings you want, and see when and where they were committed. That should provide a strong pointer to what is causing this to happen.
+"""]]
diff --git a/doc/bugs/vicfg_and_description_often_not_propagated/comment_2_d56aed617e0791aa17d9f37c8d3fd317._comment b/doc/bugs/vicfg_and_description_often_not_propagated/comment_2_d56aed617e0791aa17d9f37c8d3fd317._comment
new file mode 100644
index 0000000000..cb485362bf
--- /dev/null
+++ b/doc/bugs/vicfg_and_description_often_not_propagated/comment_2_d56aed617e0791aa17d9f37c8d3fd317._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.96"
+ subject="comment 2"
+ date="2014-10-21T20:02:40Z"
+ content="""
+Can you please provide more information, like showing the commits made to the git-annex branch when the configuration was reverted?
+
+Also, might some of the clocks of computers where you're using git-annex be set wrong?
+
+I have tagged this report moreinfo because I don't have enough information to do anything else.
+"""]]
diff --git a/doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync.mdwn b/doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync.mdwn
new file mode 100644
index 0000000000..bda167a806
--- /dev/null
+++ b/doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync.mdwn
@@ -0,0 +1,149 @@
+### Please describe the problem.
+
+Release 10.20230214 was supposed to give the ability to refresh the view branch with `sync` to
+reflect any changes made to metadata or parent branch, yet for users of crippled filesystems
+(for whom the view branches are a bit marginal anyway considering that symbolic or hard links
+are not employed) who are dependent on adjusted branches this does not work. It seems git annex
+tries to reach for the parent branch in the form of `adjusted/master` but normally it should be
+similar to `adjusted/master(unlocked)` with the parenthesized portion at the end.
+
+[[!format sh """
+X:\git-annex-tests\annex-view-test-a [views/adjusted/master(unlocked)(subdir_=_)]> git status
+On branch views/adjusted/master(unlocked)(subdir_=_)
+nothing to commit, working tree clean
+X:\git-annex-tests\annex-view-test-a [views/adjusted/master(unlocked)(subdir_=_)]> git annex sync --no-commit
+fatal: not a valid object name: 'adjusted/master'
+git-annex: failed to update refs/heads/synced/adjusted/master
+"""]]
+
+### What steps will reproduce the problem?
+
+Use a crippled filesystem on Windows with adjusted unlocked branches and enter a view branch
+and then try to `git annex sync --no-commit` -- the sync at least partially fails.
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20230214-gf3019d7e2
+build flags: Assistant Webapp Pairing TorrentParser Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+local repository version: 10
+"""]]
+
+Windows 10 version 22H2 (build 19045.2486), 64 bit.
+
+### Please provide any additional information below.
+
+[[!format sh """
+X:\> cd git-annex-tests
+X:\git-annex-tests> git init annex-view-test-a
+X:\git-annex-tests> cd .\annex-view-test-a\
+X:\git-annex-tests\annex-view-test-a [master]> git config annex.thin true
+X:\git-annex-tests\annex-view-test-a [master]> git annex init Annex-view-test-a
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked)]> echo Aaa > a
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +1 ~0 -0 !]> mkdir subdir
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +1 ~0 -0 !]> echo Bbb > subdir\b
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +2 ~0 -0 !]> echo Ccc > subdir\c
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +2 ~0 -0 !]> mkdir subdir\subsubdir
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +2 ~0 -0 !]> echo Ddd > .\subdir\subsubdir\d
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +2 ~0 -0 !]> git annex add .
+add a
+ok
+add subdir/b
+ok
+add subdir/c
+ok
+add subdir/subsubdir/d
+ok
+(recording state in git...)
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +4 ~0 -0 ~]> ls -r
+
+    Directory: X:\git-annex-tests\annex-view-test-a
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+d----           15.2.2023    12:37                subdir
+-a---           15.2.2023    12:31              5 a
+
+    Directory: X:\git-annex-tests\annex-view-test-a\subdir
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+d----           15.2.2023    12:38                subsubdir
+-a---           15.2.2023    12:34              5 b
+-a---           15.2.2023    12:37              5 c
+
+    Directory: X:\git-annex-tests\annex-view-test-a\subdir\subsubdir
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           15.2.2023    12:38              5 d
+
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +4 ~0 -0 ~]> fsutil hardlink list a
+\git-annex-tests\annex-view-test-a\.git\annex\objects\b29\a20\SHA256E-s5--e3c555b2205407e76d3a460513cf44c1c62e48ba83ec4948ed05d0f87b957051\SHA256E-s5--e3c555b2205407e76d3a460513cf44c1c62e48ba83ec4948ed05d0f87b957051
+\git-annex-tests\annex-view-test-a\a
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +4 ~0 -0 ~]> git commit -m 'Add test files'
+[adjusted/master(unlocked) 56b11c9] Add test files
+ 4 files changed, 4 insertions(+)
+ create mode 100644 a
+ create mode 100644 subdir/b
+ create mode 100644 subdir/c
+ create mode 100644 subdir/subsubdir/d
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked)]> git annex metadata -t test subdir\b
+metadata subdir/b
+  lastchanged=2023-02-15@10-52-31
+  tag=test
+  tag-lastchanged=2023-02-15@10-52-31
+ok
+(recording state in git...)
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked)]> git annex metadata -t test subdir\subsubdir\d
+metadata subdir/subsubdir/d
+  lastchanged=2023-02-15@10-53-00
+  tag=test
+  tag-lastchanged=2023-02-15@10-53-00
+ok
+(recording state in git...)
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked)]> git annex metadata subdir\c
+metadata subdir/c
+
+ok
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked)]> git annex view 'subdir\=*'
+view (searching...)
+Switched to branch 'views/adjusted/master(unlocked)(subdir_=_)'
+ok
+X:\git-annex-tests\annex-view-test-a [views/adjusted/master(unlocked)(subdir_=_)]> ls -r
+
+    Directory: X:\git-annex-tests\annex-view-test-a
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+d----           15.2.2023    12:55                subsubdir
+-a---           15.2.2023    12:55            178 b_%subdir%
+
+    Directory: X:\git-annex-tests\annex-view-test-a\subsubdir
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           15.2.2023    12:55            181 d_%subdir%subsubdir%
+
+X:\git-annex-tests\annex-view-test-a [views/adjusted/master(unlocked)(subdir_=_)]> git annex sync --no-commit
+fatal: not a valid object name: 'adjusted/master'
+git-annex: failed to update refs/heads/synced/adjusted/master
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Git Annex is great. I use it several times a week with my multigigabyte backups, where it gives structure to my image-based backup routines, so you could say I'm a believer. :)
+
+Big thanks, Joey!
+
+[[!meta author=jkniiv]]
+
+> Closing as a dup with a todo item;[[done]] --[[Joey]]
diff --git a/doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync/comment_1_3c0be3ff163aae411f323e3445af94b1._comment b/doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync/comment_1_3c0be3ff163aae411f323e3445af94b1._comment
new file mode 100644
index 0000000000..2fdf2b2ea6
--- /dev/null
+++ b/doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync/comment_1_3c0be3ff163aae411f323e3445af94b1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-02-16T18:17:33Z"
+ content="""
+This is kind of a duplicate of[[todo/unify_adjust_with_view]].
+
+I think it's best to keep it as a todo item, not a bug, since this is a
+desired new behavior.
+"""]]
diff --git a/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to.mdwn b/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to.mdwn
new file mode 100644
index 0000000000..815d5f569b
--- /dev/null
+++ b/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to.mdwn
@@ -0,0 +1,37 @@
+### Please describe the problem.
+My whole setup on all of my systems is with iso-8859-1. There is no use of UFT-8 (simply as my brain is not compatible to it).
+
+I have metadata with `:` in it. That works perfect and ad it is a low char 0x3a, it should be displayed correctly. Unfortunately, when I create a view, that char gets displayed as `ï¹?`, which is fully unlogical.
+
+### What steps will reproduce the problem?
+* Create metadata with : in it
+* create a view with that metadata
+
+### What version of git-annex are you using? On what operating system?
+10.20230126, Devuan
+
+### Please provide any additional information below.
+
+[[!format sh """
+~> locale
+LANG=de_DE
+LANGUAGE=de_DE:de:en
+LC_CTYPE=de_DE
+LC_NUMERIC=de_DE
+LC_TIME=de_DE
+LC_COLLATE=de_DE
+LC_MONETARY=de_CH
+LC_MESSAGES=de_DE
+LC_PAPER=de_DE
+LC_NAME=de_DE
+LC_ADDRESS=de_CH
+LC_TELEPHONE=de_DE
+LC_MEASUREMENT=de_DE
+LC_IDENTIFICATION=de_DE
+LC_ALL=
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+yes, that worked in the past (I think)
+
+> [[wontfix|done]] --[[Joey]]
diff --git a/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_1_a6014d95b0ac0dc20e9495a717d6d615._comment b/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_1_a6014d95b0ac0dc20e9495a717d6d615._comment
new file mode 100644
index 0000000000..f025d1b2b7
--- /dev/null
+++ b/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_1_a6014d95b0ac0dc20e9495a717d6d615._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-05-23T15:50:51Z"
+ content="""
+The character is actually `﹕`
+
+That is used in views because on windows colon is a special character
+and putting it in the name of a viewed file would prevent checking out the
+view.
+
+It would be possible to skip that on linux, but note that it also 
+escapes `/` on linux with a unicode equivilant (for similar reasons).
+
+Also, the linux executable can sometimes be run on a windows system through
+WSL. I'm not sure how a `:` in a filename would be handled in that situation.
+"""]]
diff --git a/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_2_323f1be80e2422e73ebd99b702a28e80._comment b/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_2_323f1be80e2422e73ebd99b702a28e80._comment
new file mode 100644
index 0000000000..345414088e
--- /dev/null
+++ b/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_2_323f1be80e2422e73ebd99b702a28e80._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Mowgli"
+ avatar="http://cdn.libravatar.org/avatar/17ab194dddf7b7da59ec039cbb3ac252"
+ subject="Use locales for that porpose"
+ date="2023-05-29T22:42:13Z"
+ content="""
+That is what locales are for.
+
+Why not use them just correctly? It is just wrong to use utf8 characters in non-utf8 environments.
+
+I think, the correct handling would be to stay with the user choice (locales and the raw text, a user used for the metadata) and mangle that chars just on such broken systems like windows.
+"""]]
diff --git a/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_3_576c31b2cc5031cfb64ff58a1866b3b5._comment b/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_3_576c31b2cc5031cfb64ff58a1866b3b5._comment
new file mode 100644
index 0000000000..c522b41dad
--- /dev/null
+++ b/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_3_576c31b2cc5031cfb64ff58a1866b3b5._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-06-05T18:10:23Z"
+ content="""
+> That is what locales are for.
+> 
+> Why not use them just correctly? It is just wrong to use utf8 characters in non-utf8 environments.
+
+It's perfectly find to use unicode in filenames at any time. Files have the
+name they have no matter how you configure your locale.
+
+If git renamed unicode files when cloning a repository, just because the
+current locale did not support unicode, it would be broken.
+
+If git-annex metadata contains unicode and you enter a view, git-annex is
+operating acceptably when it preserves that unicode in the viewed filename.
+
+Maybe git-annex could try to transliterate unicode in viewed filenames 
+in some way to work better non-unicode locales. But the locale can change.
+And git-annex needs to be able to reverse view filenames back to the
+filename used on the viewed branch. So it's not practical to vary the view
+filenames to fit the locale, because that would prevent that reversing
+from working unless it had a way to determine that locale that was in use
+when the view was generated.
+
+git-annex has to replace the `/` character with *something* when generating
+a viewed file from metadata that contains that character. It used to
+use `%`, since that at least contains a slash, but I didn't think that was
+very readable. The unicode slash character it uses is very readable for the
+vast percentage of users who are not stuck with 1980's era displays.
+
+Sorry, it's simply a tradeoff between you and everyone else. 
+"""]]
diff --git a/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_4_4097e8dde9d9fe29b540112f7400689a._comment b/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_4_4097e8dde9d9fe29b540112f7400689a._comment
new file mode 100644
index 0000000000..c8547ce29e
--- /dev/null
+++ b/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_4_4097e8dde9d9fe29b540112f7400689a._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="Mowgli"
+ avatar="http://cdn.libravatar.org/avatar/17ab194dddf7b7da59ec039cbb3ac252"
+ subject="comment igendwas"
+ date="2023-06-05T20:33:42Z"
+ content="""
+> If git-annex metadata contains unicode and you enter a view, git-annex is operating acceptably when it preserves that unicode in the viewed filename.
+
+But in this case, the metadata does NOT contain unicode/utf-8/whatever exotic charset. It contains ASCII, plain ASCII and git-annex is doing something with it that is not expetable.
+
+> Maybe git-annex could try to transliterate unicode in viewed filenames in some way to work better non-unicode locales. But the locale can change. And git-annex needs to be able to reverse view filenames back to the filename used on the viewed branch. So it's not practical to vary the view filenames to fit the locale, because that would prevent that reversing from working unless it had a way to determine that locale that was in use when the view was generated.
+
+It gets even more strange. I tried to rename the files, replacing the strange chars with just a `:`. Git was happy with it, my eyes was happy with it, my filesystem was happy with it but git-annex added now a second tag, additional to the content `:`, that is already there, it created the same key with a value of `ï¹?`. So it is even inconsistent in that case of renaming.
+
+> git-annex has to replace the / character with something when generating a viewed file from metadata that contains that character. It used to use %, since that at least contains a slash, but I didn't think that was very readable. The unicode slash character it uses is very readable for the vast percentage of users who are not stuck with 1980's era displays.
+
+Another opportunity is to abort and tell the user that this char is not allowed in current filesystem. Or give the user a opportunity to replace it with his own choice.
+
+But I did not speak of the slash, I spoke about a double point (`:`). That is a fully legal character in mature filesystems (the most). With that windows filesystems, you mentioned, you have even other troubles that is more important like symlinks...
+"""]]
diff --git a/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_5_5e5441cca2f3bbc252029aca358e9a47._comment b/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_5_5e5441cca2f3bbc252029aca358e9a47._comment
new file mode 100644
index 0000000000..39fd026c01
--- /dev/null
+++ b/doc/bugs/views_do_use_utf8_for_chars_that_does_not_need_to/comment_5_5e5441cca2f3bbc252029aca358e9a47._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Mowgli"
+ avatar="http://cdn.libravatar.org/avatar/17ab194dddf7b7da59ec039cbb3ac252"
+ subject="comment 5"
+ date="2023-06-05T20:35:19Z"
+ content="""
+> Sorry, it's simply a tradeoff between you and everyone else.
+
+Well, the majority would use git-annex on proper filesystems. It is only a minority that still uses such broken filesystems that do not allow a double point.
+"""]]
diff --git a/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_.mdwn b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_.mdwn
new file mode 100644
index 0000000000..ec55838884
--- /dev/null
+++ b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_.mdwn
@@ -0,0 +1,41 @@
+### Please describe the problem.
+I have a git-annex repo as a submodule. When adding a file using git-annex, I get the error message:
+
+warning: unable to convert submodule to form that will work with git-annex
+
+This I seem to get for every file, i.e. thousands of error messages sometimes. But the repo in the submodule seems to work fine,
+the .git symlink is there.
+
+I am not able to spot the problem in Annex/Fixup.hs, maybe you have an idea what could go wrong?
+
+### What steps will reproduce the problem?
+
+mike@leguin experiments % date > test2     
+mike@leguin experiments % git annex add test2             
+add test2 (non-large file; adding content to git repository) ok
+(recording state in git...)
+warning: unable to convert submodule to form that will work with git-annex
+mike@leguin experiments % ls -l ../.git                                   
+lrwxrwxrwx. 1 mike mike 53 Nov 16 17:31 ../.git -> ../../../.git/modules/experiments/ocr-evaluation/data
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 8.20201127
+Fedora 32
+
+Also the same on CentOS 7, I was just able to reproduce it on my F32 workstation. ext4 filesystem.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Besides this problem, I am super happy with git-annex and use it at work and at home daily :-)
+
+> [[fixed|done]] although w/o a way to reproduce it I can't be 100% sure
+> --[[Joey]]
diff --git a/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_2_1d3214382c2bb604101a835c0bb7f146._comment b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_2_1d3214382c2bb604101a835c0bb7f146._comment
new file mode 100644
index 0000000000..6262203742
--- /dev/null
+++ b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_2_1d3214382c2bb604101a835c0bb7f146._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="mike@2d6d71f56ce2a992244350475251df87c26fe351"
+ nickname="mike"
+ avatar="http://cdn.libravatar.org/avatar/183fa439752e2f0c6f39ede658d81050"
+ subject="comment 2"
+ date="2021-01-19T12:21:07Z"
+ content="""
+
+In the submodule:
+
+```
+% git rev-parse --git-dir
+.git
+```
+
+If I understand needsSubmoduleFixup correctly, this should not need fixing anymore, is that correct?
+
+"""]]
diff --git a/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_2_7f4800ee68c98606bc8a3ce959646014._comment b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_2_7f4800ee68c98606bc8a3ce959646014._comment
new file mode 100644
index 0000000000..723169a9b4
--- /dev/null
+++ b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_2_7f4800ee68c98606bc8a3ce959646014._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-01-19T16:14:38Z"
+ content="""
+Hmm, that happens if it somehow gets an exception while fixing up the .git
+file and unsetting core.worktree in the git config. I've modified the code
+so it now will display the exception as part of that message.
+
+If by "get for every file" you mean the same run of git-annex is displaying
+it repeatedly, that would be weird -- it's run in early startup not later.
+
+One way I can see this failing is if core.worktree is not actually set.
+Then unsetting it would fail and it would display this message. But it
+would not even try to unset core.worktree unless something tells
+git-annex that the git directory is located under the parent repo's
+.git/modules/ Despite the `git rev-parse` you show, something is
+making git-annex still think that is the case. Likely because .git
+is not a symlink.
+"""]]
diff --git a/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_3_54c9716cd5cab7b196549af2f90bed0a._comment b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_3_54c9716cd5cab7b196549af2f90bed0a._comment
new file mode 100644
index 0000000000..7097de329d
--- /dev/null
+++ b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_3_54c9716cd5cab7b196549af2f90bed0a._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="mike@2d6d71f56ce2a992244350475251df87c26fe351"
+ nickname="mike"
+ avatar="http://cdn.libravatar.org/avatar/183fa439752e2f0c6f39ede658d81050"
+ subject="comment 3"
+ date="2021-01-19T18:16:27Z"
+ content="""
+> I've modified the code so it now will display the exception as part of that message.
+
+I'll try to compile from source and get the exact exception then! I'll also check if I can come up with a minimal repo that reproduces the problem.
+
+> If by \"get for every file\" you mean the same run of git-annex is displaying it repeatedly, that would be weird -- it's run in early startup not later.
+
+I do get thousands of those error messages and on the occasion that I noticed this problem I was checking in thousands of files, and I also get the message once(!) when I `git annex add` a single test file, so this only my suspicion.
+
+> One way I can see this failing is if core.worktree is not actually set. Then unsetting it would fail and it would display this message. But it would not even try to unset core.worktree unless something tells git-annex that the git directory is located under the parent repo's .git/modules/ Despite the git rev-parse you show, something is making git-annex still think that is the case. Likely because .git is not a symlink.
+
+See above, it's a symlink to the directory under the parent repo's ./git/modules. Is this how it is intended?
+"""]]
diff --git a/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_4_864988b3ebc11ea9e92c55ee765d6d5c._comment b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_4_864988b3ebc11ea9e92c55ee765d6d5c._comment
new file mode 100644
index 0000000000..3f403db0dd
--- /dev/null
+++ b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_4_864988b3ebc11ea9e92c55ee765d6d5c._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="mike@2d6d71f56ce2a992244350475251df87c26fe351"
+ nickname="mike"
+ avatar="http://cdn.libravatar.org/avatar/183fa439752e2f0c6f39ede658d81050"
+ subject="comment 4"
+ date="2021-01-20T15:41:50Z"
+ content="""
+For some reason, I couldn't reproduce it easily using `git annex add` on my F32 workstation, but I got it on a `git annex get`:
+
+```
+% git annex get model_strukturerkennung.h5
+get model_strukturerkennung.h5 (from qurator-box...)
+(checksum...) ok
+(recording state in git...)
+warning: unable to convert submodule to form that will work with git-annex: unset core.worktree failed
+CallStack (from HasCallStack):
+  error, called at ./Annex/Fixup.hs:119:24 in main:Annex.Fixup
+% ls -ld ../.git
+lrwxrwxrwx. 1 mike mike 53 Nov 16 17:31 ../.git -> ../../../.git/modules/experiments/ocr-evaluation/data
+
+
+% git config --unset core.worktree; echo $?
+5
+% git config --get core.worktree; echo $?
+1
+```
+"""]]
diff --git a/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_5_06d31ed5a8c187cec7bc90339550b5e8._comment b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_5_06d31ed5a8c187cec7bc90339550b5e8._comment
new file mode 100644
index 0000000000..8655215084
--- /dev/null
+++ b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_5_06d31ed5a8c187cec7bc90339550b5e8._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-01-21T18:14:09Z"
+ content="""
+Thanks Mike, that confirms it's failing to unset the config that's not set.
+
+The .git symlink is what git-annex is supposed to set up, so it should not
+need to do anything else and the question is, why does it still think it 
+needs to change something?
+
+I was able to reproduce the warning, just run `git submodule add foo
+/path/to/annexrepo` and then in foo, `git-annex init` and then it
+happens part-way through. Due to two different git-annex processes both
+trying to do the same conversion, with the second one failing.
+I've fixed that. 
+
+My fix will also fix your problem. But, I don't actually
+understand how to reproduce your problem. I was only able to make it happen
+when running `git-annex init` (or letting it auto-init), 
+not running other git-annex commands in a repo it's already initialized.
+
+Maybe you have `GIT_DIR` set to "../../../.git/modules/..."?
+"""]]
diff --git a/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_6_5e7007182372d28ceb11a8692e2cf801._comment b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_6_5e7007182372d28ceb11a8692e2cf801._comment
new file mode 100644
index 0000000000..1b434ce221
--- /dev/null
+++ b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_6_5e7007182372d28ceb11a8692e2cf801._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="mike@2d6d71f56ce2a992244350475251df87c26fe351"
+ nickname="mike"
+ avatar="http://cdn.libravatar.org/avatar/183fa439752e2f0c6f39ede658d81050"
+ subject="comment 6"
+ date="2021-01-22T11:08:38Z"
+ content="""
+First a side note about the thousands of error messages: This seems to be happening when I change thousands of files and a subsequent `git annex add` runs a `git ls-files` which in turn runs `git-annex smudge` for every file, which probably each outputs the error message. 
+"""]]
diff --git a/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_7_4de04de71792801f50256214f4b5fe9f._comment b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_7_4de04de71792801f50256214f4b5fe9f._comment
new file mode 100644
index 0000000000..eed218c7b9
--- /dev/null
+++ b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_7_4de04de71792801f50256214f4b5fe9f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-01-22T18:33:01Z"
+ content="""
+Makes sense that `git-annex smudge` being called repeatedly would output
+the message like that. And unfortunately, yes, when a file is unlocked and
+gets modified, git ls-files --modified does need to smudge it. Thanks
+for clearing that part up.
+"""]]
diff --git a/doc/bugs/webapp_--listen_port_is_not_used__63__.mdwn b/doc/bugs/webapp_--listen_port_is_not_used__63__.mdwn
new file mode 100644
index 0000000000..bf9f80a68d
--- /dev/null
+++ b/doc/bugs/webapp_--listen_port_is_not_used__63__.mdwn
@@ -0,0 +1,23 @@
+### Please describe the problem.
+
+```
+reprostim@reproiner:/data/reprostim/Videos$ ps auxw | grep webapp
+reprost+   25249  0.0  0.0   9892  2100 pts/5    S+   Jan05   0:00 git annex --debug webapp --listen 0.0.0.0:8888
+reprost+   25250  5.4  0.2 1074346616 65556 ?    Ssl  Jan05  60:39 /usr/bin/git-annex --debug webapp --listen 0.0.0.0:8888
+reprost+  224039  0.0  0.0   6332  2116 pts/6    S+   10:55   0:00 grep webapp
+
+reprostim@reproiner:/data/reprostim/Videos$ lsof -i :8888
+
+reprostim@reproiner:/data/reprostim/Videos$ lsof -i | grep git-annex
+git-annex  25250 reprostim   14u  IPv4 129033      0t0  UDP *:55556
+git-annex 221230 reprostim   14u  IPv4 129033      0t0  UDP *:55556
+
+reprostim@reproiner:/data/reprostim/Videos$ git annex version
+git-annex version: 10.20230126
+
+```
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_1_275507b26ca13e5d55deec4b7af60699._comment b/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_1_275507b26ca13e5d55deec4b7af60699._comment
new file mode 100644
index 0000000000..b05edeb28a
--- /dev/null
+++ b/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_1_275507b26ca13e5d55deec4b7af60699._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-01-18T16:47:15Z"
+ content="""
+--listen takes an IP address (or hostname),
+it does not let you specify the port. I've clarified the documentation
+about this.
+
+I don't reproduce the behavior you show, when I try that the process
+runs but does not bind to any port, and in .git/annex/daemon.log, I see:
+
+	WebApp crashed: Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [], addrFamily = AF_UNSPEC, addrSocketType = Stream, addrProtocol = 0, addrAddress = 0.0.0.0:0, addrCanonName = Nothing}, host name: Just "0.0.0.0:8888", service name: Nothing): does not exist (Name or service not known)
+
+This may be an OS or resolver difference. If "0.0.0.0:8888" somehow
+resolves to an IP address on your system, then the webapp will listen
+on that IP address I suppose. But it's not expecting that to specify a
+port.
+
+The webapp outputs the full url, including the port it chose. 
+Since that url also includes an auth token that is required to use the
+webapp, specifying the port for it to listen on does not seem very useful.
+
+What's your use case for wanting to specify a port?
+"""]]
diff --git a/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_2_55315d9013fc6acbde9f8b419757d949._comment b/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_2_55315d9013fc6acbde9f8b419757d949._comment
new file mode 100644
index 0000000000..8af5ad882b
--- /dev/null
+++ b/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_2_55315d9013fc6acbde9f8b419757d949._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2024-01-18T19:00:50Z"
+ content="""
+> What's your use case for wanting to specify a port?
+
+it was to have some static port I could keep an ssh redirect pointing to so I could investigate behavior of the remote running annex webapp.
+
+My 1c: Since AFAIK no ADDRESS could have `:` (unless some `ssh` based \"server:/path/to/socket\" which I do not think supported) so might be better to just crash (not just have it a matter of documentation) if `:\d+` part is found to be specified?
+"""]]
diff --git a/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_3_2d18df9587b52cbb7c34bfce2e0f2fb2._comment b/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_3_2d18df9587b52cbb7c34bfce2e0f2fb2._comment
new file mode 100644
index 0000000000..d1bd57feac
--- /dev/null
+++ b/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_3_2d18df9587b52cbb7c34bfce2e0f2fb2._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-01-18T21:13:42Z"
+ content="""
+IPv6 would beg to differ about `:\d+` ;-)
+
+Actually, it may be that your address:port was treated as some IPv6 mixed
+IPv4, iirc something like that is a thing.
+
+> it was to have some static port I could keep an ssh redirect pointing to so I could investigate behavior of the remote running annex webapp.
+
+You would still need to copy over the url though to get the access key
+for the webapp..
+"""]]
diff --git a/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_4_ba217465bfa738b77ea9417a33810d75._comment b/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_4_ba217465bfa738b77ea9417a33810d75._comment
new file mode 100644
index 0000000000..74c0a7b39f
--- /dev/null
+++ b/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_4_ba217465bfa738b77ea9417a33810d75._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2024-01-25T17:29:08Z"
+ content="""
+I found an old todo about the same thing,
+[[todo/Make_webapp_port_configurable]].
+
+The idea there was, they were using docker and wanted to open only a
+specific port selected for the webapp. So basically the same kind of thing.
+
+I think that this should be a separate --port option, to avoid needing to
+try to parse something that may be an ipv6 address or hostname, or
+whatever.
+
+I don't think that using --port should prevent the webapp from needing
+the `?auth=' part of the url, as output when using --listen.
+
+Probably it does not make sense to use --port without also using --listen,
+but if the user does use it, I don't think --port needs to output the url
+the way --listen does.
+"""]]
diff --git a/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_5_99a6933f30649bc33ee5c74b33fc7046._comment b/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_5_99a6933f30649bc33ee5c74b33fc7046._comment
new file mode 100644
index 0000000000..cdd59cf4dd
--- /dev/null
+++ b/doc/bugs/webapp_--listen_port_is_not_used__63__/comment_5_99a6933f30649bc33ee5c74b33fc7046._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2024-01-25T18:06:15Z"
+ content="""
+Implemented --port.
+"""]]
diff --git a/doc/bugs/webapp__58___difficult_to_abort_adding_a_repository.mdwn b/doc/bugs/webapp__58___difficult_to_abort_adding_a_repository.mdwn
new file mode 100644
index 0000000000..41007dbb45
--- /dev/null
+++ b/doc/bugs/webapp__58___difficult_to_abort_adding_a_repository.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+I could not find a way to abort the addition of a new remote repository.
+
+### What steps will reproduce the problem?
+- start adding a remote repository (unencrypted, with git-annex installed);
+- forget to create the folder on the remote host;
+- navigate away from the repository page;
+- the dashboard says the repository is partially set-up, and the only thing one can do is look at the log (which says the folder is missing).
+
+I was able to solve it by creating another repository with the exact same data.
+
+### What version of git-annex are you using? On what operating system?
+
+Version: 4.20131002-gf25991c on OS X 10.8.5
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
diff --git a/doc/bugs/webdav_fails___40__server__58___radicale_0.9-1__41__.mdwn b/doc/bugs/webdav_fails___40__server__58___radicale_0.9-1__41__.mdwn
new file mode 100644
index 0000000000..8da66a810a
--- /dev/null
+++ b/doc/bugs/webdav_fails___40__server__58___radicale_0.9-1__41__.mdwn
@@ -0,0 +1,45 @@
+The current command fails (git-annex 5.20141125, debian sid, DAV server: radicale 0.9-1):
+
+    $ WEBDAV_USERNAME=user WEBDAV_PASSWORD=password git annex --debug initremote dav.example.com type=webdav url=https://dav.example.com encryption=none
+    [2014-11-28 16:53:29 CET] read: git ["--git-dir=/home/user/test-annex/.git","--work-tree=/home/user/test-annex","show-ref","git-annex"]
+    [2014-11-28 16:53:29 CET] read: git ["--git-dir=/home/user/test-annex/.git","--work-tree=/home/user/test-annex","show-ref","--hash","refs/heads/git-annex"]
+    [2014-11-28 16:53:29 CET] read: git ["--git-dir=/home/user/test-annex/.git","--work-tree=/home/user/test-annex","log","refs/heads/git-annex..f60365a0d5333e1aefe80a3fe747e2cb3d5c8162","-n1","--pretty=%H"]
+    [2014-11-28 16:53:29 CET] chat: git ["--git-dir=/home/user/test-annex/.git","--work-tree=/home/user/test-annex","cat-file","--batch"]
+    initremote dav.example.com (testing WebDAV server...)
+
+    git-annex: WebDAV test failed: StatusCodeException (Status {statusCode = 500, statusMessage = "Internal Server Error"}) [("Server","nginx/1.2.1"),("Date","Fri, 28 Nov 2014 15:53:37 GMT"),("Content-Type","text/plain"),("Content-Length","59"),("Connection","keep-alive"),("Keep-Alive","timeout=75"),("X-Response-Body-Start","A server error occurred. Please contact the administrator."),("X-Request-URL","MKCOL https://dav.example.com:443/tmp")] (CJ {expose = []}): user error
+    failed
+    git-annex: initremote: 1 failed
+
+server log:
+
+    ::ffff:192.168.1.6 - user [28/Nov/2014:16:53:17 +0100] "MKCOL / HTTP/1.1" 500 59 "-" "hDav-using application"
+    ::ffff:192.168.1.6 - user [28/Nov/2014:16:53:18 +0100] "PROPFIND /tmp HTTP/1.1" 500 59 "-" "hDav-using application"
+    ::ffff:192.168.1.6 - user [28/Nov/2014:16:53:21 +0100] "MKCOL /tmp HTTP/1.1" 500 59 "-" "hDav-using application"
+    ::ffff:192.168.1.6 - user [28/Nov/2014:16:53:32 +0100] "MKCOL / HTTP/1.1" 500 59 "-" "hDav-using application"
+    ::ffff:192.168.1.6 - user [28/Nov/2014:16:53:34 +0100] "PROPFIND /tmp HTTP/1.1" 500 59 "-" "hDav-using application"
+    ::ffff:192.168.1.6 - user [28/Nov/2014:16:53:37 +0100] "MKCOL /tmp HTTP/1.1" 500 59 "-" "hDav-using application"
+    ::ffff:192.168.1.6 - user [28/Nov/2014:16:58:31 +0100] "PROPFIND / HTTP/1.1" 207 1035 "-" "cadaver/0.23.3 neon/0.30.1"
+    ::ffff:192.168.1.6 - user [28/Nov/2014:16:59:19 +0100] "MKCOL / HTTP/1.1" 500 59 "-" "hDav-using application"
+    ::ffff:192.168.1.6 - user [28/Nov/2014:16:59:21 +0100] "PROPFIND /tmp HTTP/1.1" 500 59 "-" "hDav-using application"
+    ::ffff:192.168.1.6 - user [28/Nov/2014:16:59:23 +0100] "MKCOL /tmp HTTP/1.1" 500 59 "-" "hDav-using application"
+
+
+cadaver works:
+
+    $ cadaver https://dav.example.com
+    Authentication required for Radicale - Password Required on server `dav.example.com':
+    Username: user
+    Password: 
+    dav:/> ls
+    Listing collection `/': succeeded.
+    Coll:   user                                  0  Jan  1  1970
+
+server log:
+
+    ::ffff:192.168.1.6 - - [28/Nov/2014:17:01:31 +0100] "OPTIONS / HTTP/1.1" 200 0 "-" "cadaver/0.23.3 neon/0.30.1"
+    ::ffff:192.168.1.6 - - [28/Nov/2014:17:01:31 +0100] "PROPFIND / HTTP/1.1" 401 0 "-" "cadaver/0.23.3 neon/0.30.1"
+    ::ffff:192.168.1.6 - user [28/Nov/2014:17:01:42 +0100] "PROPFIND / HTTP/1.1" 207 579 "-" "cadaver/0.23.3 neon/0.30.1"
+    ::ffff:192.168.1.6 - user [28/Nov/2014:17:01:42 +0100] "PROPFIND / HTTP/1.1" 207 579 "-" "cadaver/0.23.3 neon/0.30.1"
+    ::ffff:192.168.1.6 - user [28/Nov/2014:17:02:01 +0100] "PROPFIND / HTTP/1.1" 207 1035 "-" "cadaver/0.23.3 neon/0.30.1"
+
diff --git a/doc/bugs/webdav_fails___40__server__58___radicale_0.9-1__41__/comment_1_487bf264afeef2a3b0a61d306ebfc3c5._comment b/doc/bugs/webdav_fails___40__server__58___radicale_0.9-1__41__/comment_1_487bf264afeef2a3b0a61d306ebfc3c5._comment
new file mode 100644
index 0000000000..56e34a09d3
--- /dev/null
+++ b/doc/bugs/webdav_fails___40__server__58___radicale_0.9-1__41__/comment_1_487bf264afeef2a3b0a61d306ebfc3c5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-12-02T19:02:10Z"
+ content="""
+The webdav server seems to have rejected the MKCOL command,
+which makes a collection (subdirectory) on the server.
+
+Is radicale intended to be a general-purpose webdav server?
+The description of the debian package says it's a CalDAV and CardDAV
+server. Perhaps it simply doesn't support generic top-level collections.
+"""]]
diff --git a/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links.mdwn b/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links.mdwn
new file mode 100644
index 0000000000..c5fe398bfc
--- /dev/null
+++ b/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links.mdwn
@@ -0,0 +1,76 @@
+### Please describe the problem.
+
+when unlocking multiple files, files are not hard linked, but they are if unlocked individually
+
+
+### What steps will reproduce the problem?
+
+I don't really know. 
+Currently I have a repository that exhibits the problem:
+
+    %git status --> all clean
+    
+    # this works as expected
+    %git annex unlock bucket/tata
+    %ls -li bucket/tata
+    33292697 -rw-rw-r-- 2 karl qbstaff 102400000 Dec  7 19:02 bucket/tata
+    %find . -inum 33292697
+    ./bucket/tata
+    ./.git/annex/objects/V0/3Z/SHA256E-s102400000--c50bbc52a81112507134d764ec570ab373be5c4a3b1dd1d87ce609d14d031a17/SHA256E-s102400000--c50bbc52a81112507134d764ec570ab373be5c4a3b1dd1d87ce609d14d031a17
+    git annex lock bucket/tata
+
+
+
+This does not:
+
+    %git annex unlock bucket/
+    %ls -li bucket/tata 
+    33292708 -rw-rw-r-- 1 karl qbstaff 102400000 Dec  7 19:02 bucket/tata
+    %find . -inum 33292708
+    ./bucket/tata
+
+As you can see, now the inode is wrong (different from the annex object file), and the unlocked file is not a hard link. The only difference is the argument to git annex unlock
+This is really annoying, I switched to V6 for this particular feature, I have a large repository to update and it takes ages since files are copied instead of hard linked.
+
+
+### What version of git-annex are you using? On what operating system?
+
+    %git config annex.thin 
+    true
+
+    %git annex version
+    git-annex version: 6.20171018+gitgbb20b1ed3-1~ndall+1
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 6
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
+    %lsb_release -a
+    No LSB modules are available.
+    Distributor ID:	Ubuntu
+    Description:	Ubuntu 14.04.5 LTS
+    Release:	14.04
+    Codename:	trusty
+
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, we use it on a daily basis and love it.
+Note that we will have to switch to LFS for a lot of use cases because gitlab no longer supports git annex from v9 release.
+
+
diff --git a/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_1_cb6c6e7bcbbe3006dd80e89fa545016d._comment b/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_1_cb6c6e7bcbbe3006dd80e89fa545016d._comment
new file mode 100644
index 0000000000..c60dbbfa9d
--- /dev/null
+++ b/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_1_cb6c6e7bcbbe3006dd80e89fa545016d._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/x4ddlZwKw9O9IsCHmNZz7tSJn2h0H3vX#23f03"
+ nickname="Karl"
+ avatar="http://cdn.libravatar.org/avatar/7bc6190890ad7485f9913c49aa13165cecf2d98a54bc7934749771a1b91290f6"
+ subject="additional information"
+ date="2017-12-08T10:17:40Z"
+ content="""
+in the same git repository, some files will not be hardlinked even if unlocked individually, e.g.
+
+    ll -i bucket/dev/nkt-16-358-01/data/nkt-16-358-01_flow_annotation.csv
+    33292708 lrwxrwxrwx 1 karl qbstaff 208 Nov 29 14:19 bucket/dev/nkt-16-358-01/data/nkt-16-358-01_flow_annotation.csv -> ../../../../.git/annex/objects/74/mK/SHA256E-s798268--3ae6c93d5b03cae3b7fb3d9920a4728e3ba572419f8918a938ef50efccdcfc1b.csv/SHA256E-   s798268--3ae6c93d5b03cae3b7fb3d9920a4728e3ba572419f8918a938ef50efccdcfc1b.csv*
+    
+    ll -i .git/annex/objects/74/mK/SHA256E-s798268--3ae6c93d5b03cae3b7fb3d9920a4728e3ba572419f8918a938ef50efccdcfc1b.csv/SHA256E-s798268--3ae6c93d5b03cae3b7fb3d9920a4728e3ba572419f8918a938ef50efccdcfc1b.csv
+    33161645 -rwxrw---- 1 karl qbstaff 798268 Nov 29 14:19 .git/annex/objects/74/mK/SHA256E-s798268--3ae6c93d5b03cae3b7fb3d9920a4728e3ba572419f8918a938ef50efccdcfc1b.csv/SHA256E-s798268--3ae6c93d5b03cae3b7fb3d9920a4728e3ba572419f8918a938ef50efccdcfc1b.csv*
+    # so the inode of the object is 33161645
+    # unlock it
+    git annex unlock bucket/dev/nkt-16-358-01/data/nkt-16-358-01_flow_annotation.csv
+    # check the inum of the unlocked file
+    # ll -i bucket/dev/nkt-16-358-01/data/nkt-16-358-01_flow_annotation.csv
+    33292719 -rwxrwx--x 1 karl qbstaff 798268 Nov 29 14:19 bucket/dev/nkt-16-358-01/data/nkt-16-358-01_flow_annotation.csv
+    # inodes do not match
+
+
+
+"""]]
diff --git a/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_2_146ed4bf42ce1979815db82bbf9a5b86._comment b/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_2_146ed4bf42ce1979815db82bbf9a5b86._comment
new file mode 100644
index 0000000000..dd059a2b78
--- /dev/null
+++ b/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_2_146ed4bf42ce1979815db82bbf9a5b86._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrey_utkin@49e37627b3060c40292113d73d7ffbf317233e62"
+ nickname="andrey_utkin"
+ avatar="http://cdn.libravatar.org/avatar/95bb7f4f7647cc24c1cf635b61578842"
+ subject="comment 2"
+ date="2018-07-21T23:41:34Z"
+ content="""
+Hit this, too. dev-vcs/git-annex-6.20180529.
+All files which are successfully hardlinked have executability bit not set. `chmod a-x *` eventually fixes hardlinking for almost all files, but interestingly, not for all. Also as I see executability permissions bit does not propagate through git commits with modechange.
+"""]]
diff --git a/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_3_57924a0a08da3cafe78b95bf22ae89fd._comment b/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_3_57924a0a08da3cafe78b95bf22ae89fd._comment
new file mode 100644
index 0000000000..88d0134c2e
--- /dev/null
+++ b/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_3_57924a0a08da3cafe78b95bf22ae89fd._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-03-22T13:25:22Z"
+ content="""
+annex.thin will only make one hard link to a given annex object file, so if
+the file that is not getting hard linked has the same content as another
+file in the repository that is getting hard linked, that explains why.
+
+It would be very susprising for two different files in the repo to end up
+hard linked together and then a modification to one change both files.
+
+You should really upgrade to git-annex 7.x when using v7 mode. You
+are both using versions that are missing quite a lot of the fixes needed to
+get v7 to release quality. 
+So please upgrade to a current version and see if your execute bit problems
+persist there.
+"""]]
diff --git a/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_4_4a7ec33d4470714c9fb4271d214b3d1f._comment b/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_4_4a7ec33d4470714c9fb4271d214b3d1f._comment
new file mode 100644
index 0000000000..813c3c11fe
--- /dev/null
+++ b/doc/bugs/weird_bug_with_annex_unlock_with_annex.thin_true_about_hard_links/comment_4_4a7ec33d4470714c9fb4271d214b3d1f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jeanpmbox-456@7222359de8d1f37a7cf25a519e8faf90a9517b50"
+ nickname="jeanpmbox-456"
+ avatar="http://cdn.libravatar.org/avatar/164eb4254c5f83d95d3e0b810ff7aab9"
+ subject="comment 4"
+ date="2020-05-15T21:21:29Z"
+ content="""
+Is there an option for git-annex to recognize hard links inside a repository?
+
+I have a repository where I want a file to be in different places but when I git-annex this file I can't preserve the hard link structure.
+"""]]
diff --git a/doc/bugs/weird_interaction_between___34__required__34___and___34__numcopies__34___on_duplicate_files.mdwn b/doc/bugs/weird_interaction_between___34__required__34___and___34__numcopies__34___on_duplicate_files.mdwn
new file mode 100644
index 0000000000..c44df8cc89
--- /dev/null
+++ b/doc/bugs/weird_interaction_between___34__required__34___and___34__numcopies__34___on_duplicate_files.mdwn
@@ -0,0 +1,299 @@
+### Please describe the problem.
+
+I have a central repo that holds all my content. I keep a second copy of the content split across two hard drives (each of those being too small to hold the whole content), in bare repositories.
+
+I use  "git annex sync --content" with "git annex required" to control which sub-tree goes to which of the smaller hard-drive.
+
+I noticed that some files, which I did not modify, where copied then dropped by git annex at each sync.
+
+I eventually understood that 
+
+* those file are duplicates: the same contents appears at several paths in my repo,
+* my "required" rules match the same content differently depending on the path.
+* this seems to confuse git annex, which will copy a file to remote, only to drop it from that remote just afterward.
+
+### What steps will reproduce the problem?
+
+This script illustrates the issue
+
+[[!format sh """
+set -x
+chmod +rwX -R /tmp/test_dupe
+rm -rf /tmp/test_dupe
+mkdir /tmp/test_dupe
+cd /tmp/test_dupe
+
+# create repo
+mkdir main
+cd main
+git init
+git annex init
+git annex numcopies 2
+
+# populate repo
+mkdir private public
+echo "my private file" > private/private_file
+echo "my public file" > public/public_file
+echo "my dupe file" | tee public/dupe_file > private/dupe_file
+git annex add .
+git commit -m "populate repo"
+tree
+
+# create 2 partial archives
+for x in public private
+do
+  cd ..
+  git clone main --bare archive_$x.git
+  cd archive_$x.git
+  git annex init "archive $x"
+  git annex required . "include=$x/*"
+  cd ../main
+  git remote add archive_$x "../archive_$x.git"
+done
+
+git annex sync
+git annex whereis
+git annex sync --content
+git annex whereis
+git annex sync --content
+git annex whereis
+
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 6.20170101.1, on debian stretch
+
+
+### Please provide any additional information below.
+
+Here is the transcript of running the script above
+
+[[!format sh """
++ chmod +rwX -R /tmp/test_dupe
++ rm -rf /tmp/test_dupe
++ mkdir /tmp/test_dupe
++ cd /tmp/test_dupe
++ mkdir main
++ cd main
++ git init
+Initialized empty Git repository in /tmp/test_dupe/main/.git/
++ git annex init
+init  ok
+(recording state in git...)
++ git annex numcopies 2
+numcopies 2 ok
+(recording state in git...)
++ mkdir private public
++ echo 'my private file'
++ echo 'my public file'
++ echo 'my dupe file'
++ tee public/dupe_file
++ git annex add .
+add private/dupe_file ok
+add private/private_file ok
+add public/dupe_file ok
+add public/public_file ok
+(recording state in git...)
++ git commit -m 'populate repo'
+[master (root-commit) 75d8a5c] populate repo
+ 4 files changed, 4 insertions(+)
+ create mode 120000 private/dupe_file
+ create mode 120000 private/private_file
+ create mode 120000 public/dupe_file
+ create mode 120000 public/public_file
++ tree
+.
+├── private
+│   ├── dupe_file -> ../.git/annex/objects/ZP/1X/SHA256E-s13--a1786172085dbc6d805c9e311fe636cd36709a24eceb00017408dbe75cff24db/SHA256E-s13--a1786172085dbc6d805c9e311fe636cd36709a24eceb00017408dbe75cff24db
+│   └── private_file -> ../.git/annex/objects/Gk/mx/SHA256E-s16--2cdc2a8328f83bf817e7e8c305f9c8afda7ead5e447bac99ac250dfb7bdb8839/SHA256E-s16--2cdc2a8328f83bf817e7e8c305f9c8afda7ead5e447bac99ac250dfb7bdb8839
+└── public
+    ├── dupe_file -> ../.git/annex/objects/ZP/1X/SHA256E-s13--a1786172085dbc6d805c9e311fe636cd36709a24eceb00017408dbe75cff24db/SHA256E-s13--a1786172085dbc6d805c9e311fe636cd36709a24eceb00017408dbe75cff24db
+    └── public_file -> ../.git/annex/objects/M9/8P/SHA256E-s15--fb55ed5db2dc55ef8442f515c008fe89ae2a428652b468ab132065d09402be2d/SHA256E-s15--fb55ed5db2dc55ef8442f515c008fe89ae2a428652b468ab132065d09402be2d
+
+2 directories, 4 files
++ for x in public private
++ cd ..
++ git clone main --bare archive_public.git
+Cloning into bare repository 'archive_public.git'...
+done.
++ cd archive_public.git
++ git annex init 'archive public'
+init archive public ok
+(recording state in git...)
++ git annex required . 'include=public/*'
+required . ok
+(recording state in git...)
++ cd ../main
++ git remote add archive_public ../archive_public.git
++ for x in public private
++ cd ..
++ git clone main --bare archive_private.git
+Cloning into bare repository 'archive_private.git'...
+done.
++ cd archive_private.git
++ git annex init 'archive private'
+init archive private ok
+(recording state in git...)
++ git annex required . 'include=private/*'
+required . ok
+(recording state in git...)
++ cd ../main
++ git remote add archive_private ../archive_private.git
++ git annex sync
+commit  
+On branch master
+nothing to commit, working tree clean
+ok
+pull archive_public 
+From ../archive_public
+ * [new branch]      git-annex  -> archive_public/git-annex
+ * [new branch]      master     -> archive_public/master
+ok
+pull archive_private 
+From ../archive_private
+ * [new branch]      git-annex  -> archive_private/git-annex
+ * [new branch]      master     -> archive_private/master
+ok
+(merging archive_private/git-annex archive_public/git-annex into git-annex...)
+(recording state in git...)
+push archive_public 
+To ../archive_public.git
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+ok
+push archive_private 
+To ../archive_private.git
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+ok
++ git annex whereis
+whereis private/dupe_file (1 copy) 
+  	aaa3a2b2-d354-4ca0-857d-ae51762f69de -- seb@navi:/tmp/test_dupe/main [here]
+ok
+whereis private/private_file (1 copy) 
+  	aaa3a2b2-d354-4ca0-857d-ae51762f69de -- seb@navi:/tmp/test_dupe/main [here]
+ok
+whereis public/dupe_file (1 copy) 
+  	aaa3a2b2-d354-4ca0-857d-ae51762f69de -- seb@navi:/tmp/test_dupe/main [here]
+ok
+whereis public/public_file (1 copy) 
+  	aaa3a2b2-d354-4ca0-857d-ae51762f69de -- seb@navi:/tmp/test_dupe/main [here]
+ok
+"""]]
+
+
+now let do a sync --content
+
+
+[[!format sh """
++ git annex sync --content
+commit  
+On branch master
+nothing to commit, working tree clean
+ok
+pull archive_public 
+ok
+pull archive_private 
+ok
+copy private/dupe_file (to archive_private...) (checksum...) ok ################################## copied
+copy private/private_file (to archive_private...) (checksum...) ok
+copy public/dupe_file (to archive_public...) (checksum...) ok
+drop archive_private public/dupe_file ok ################################## dropped
+copy public/public_file (to archive_public...) (checksum...) ok
+pull archive_public 
+ok
+pull archive_private 
+ok
+(recording state in git...)
+push archive_public 
+To ../archive_public.git
+   cacaf8b..1d5c278  git-annex -> synced/git-annex
+ok
+push archive_private 
+To ../archive_private.git
+   cacaf8b..1d5c278  git-annex -> synced/git-annex
+ok
++ git annex whereis
+whereis private/dupe_file (2 copies) ################################## missing from archive_private
+  	02ee663d-8956-4ad5-9165-0e82314f00f1 -- archive public [archive_public]
+   	aaa3a2b2-d354-4ca0-857d-ae51762f69de -- seb@navi:/tmp/test_dupe/main [here]
+ok
+whereis private/private_file (2 copies) 
+  	551ffe45-f46d-4c37-8c59-eff4e8ec8bfe -- archive private [archive_private]
+   	aaa3a2b2-d354-4ca0-857d-ae51762f69de -- seb@navi:/tmp/test_dupe/main [here]
+ok
+whereis public/dupe_file (2 copies) 
+  	02ee663d-8956-4ad5-9165-0e82314f00f1 -- archive public [archive_public]
+   	aaa3a2b2-d354-4ca0-857d-ae51762f69de -- seb@navi:/tmp/test_dupe/main [here]
+ok
+whereis public/public_file (2 copies) 
+  	02ee663d-8956-4ad5-9165-0e82314f00f1 -- archive public [archive_public]
+   	aaa3a2b2-d354-4ca0-857d-ae51762f69de -- seb@navi:/tmp/test_dupe/main [here]
+ok
+"""]]
+
+We've seen that git-annex
+
+* did not honor the "required" command: "private/dupe_file" is missing from private_archive
+* wasted some bandwidth: it copied the file only to drop it
+* did enforce the "numcopies=2" quite literally 
+* did not loose any data (thank you Joey!)
+
+The same happens if we sync again
+
+[[!format sh """
++ git annex sync --content
+commit  
+On branch master
+nothing to commit, working tree clean
+ok
+pull archive_public 
+From ../archive_public
+   1d5c278..4b9583f  git-annex  -> archive_public/git-annex
+ok
+pull archive_private 
+From ../archive_private
+   1d5c278..7aec3eb  git-annex  -> archive_private/git-annex
+ok
+(merging archive_private/git-annex archive_public/git-annex into git-annex...)
+(recording state in git...)
+copy private/dupe_file (to archive_private...) (checksum...) ok ################################## copied again
+drop archive_public private/dupe_file ok
+copy public/dupe_file (to archive_public...) (checksum...) ok
+drop archive_private public/dupe_file ok ################################## dropped again
+pull archive_public 
+ok
+pull archive_private 
+ok
+(recording state in git...)
+push archive_public 
+To ../archive_public.git
+   1d5c278..51d259c  git-annex -> synced/git-annex
+ok
+push archive_private 
+To ../archive_private.git
+   1d5c278..51d259c  git-annex -> synced/git-annex
+ok
++ git annex whereis
+whereis private/dupe_file (2 copies) ################################## still missing from archive_private
+  	02ee663d-8956-4ad5-9165-0e82314f00f1 -- archive public [archive_public]
+   	aaa3a2b2-d354-4ca0-857d-ae51762f69de -- seb@navi:/tmp/test_dupe/main [here]
+ok
+whereis private/private_file (2 copies) 
+  	551ffe45-f46d-4c37-8c59-eff4e8ec8bfe -- archive private [archive_private]
+   	aaa3a2b2-d354-4ca0-857d-ae51762f69de -- seb@navi:/tmp/test_dupe/main [here]
+ok
+whereis public/dupe_file (2 copies) 
+  	02ee663d-8956-4ad5-9165-0e82314f00f1 -- archive public [archive_public]
+   	aaa3a2b2-d354-4ca0-857d-ae51762f69de -- seb@navi:/tmp/test_dupe/main [here]
+ok
+whereis public/public_file (2 copies) 
+  	02ee663d-8956-4ad5-9165-0e82314f00f1 -- archive public [archive_public]
+   	aaa3a2b2-d354-4ca0-857d-ae51762f69de -- seb@navi:/tmp/test_dupe/main [here]
+ok
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! I use git-annex almost every day, and I'm very happy to do so.
diff --git a/doc/bugs/weird_interaction_between___34__required__34___and___34__numcopies__34___on_duplicate_files/comment_1_169d4f769e4ba6a81aaa7ed32c789b50._comment b/doc/bugs/weird_interaction_between___34__required__34___and___34__numcopies__34___on_duplicate_files/comment_1_169d4f769e4ba6a81aaa7ed32c789b50._comment
new file mode 100644
index 0000000000..c5dbc294c1
--- /dev/null
+++ b/doc/bugs/weird_interaction_between___34__required__34___and___34__numcopies__34___on_duplicate_files/comment_1_169d4f769e4ba6a81aaa7ed32c789b50._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~barthelemy"
+ nickname="barthelemy"
+ avatar="http://cdn.libravatar.org/avatar/e99cb15f6029de3225721b3ebdd0233905eb69698e9b229a8c4cc510a4135438"
+ subject="cannot reproduce on git-annex 6.20180913"
+ date="2018-11-13T09:32:54Z"
+ content="""
+I tested with a more recent git-annex version 6.20180913, from debian backports,
+and cannot reproduce the issue. The script above ends with
+
+    + git annex whereis
+    whereis private/dupe_file (3 copies)
+            3098d3d7-e4fc-4860-90e1-f7e0ccd71242 -- seb@navi:/tmp/test_dupe/main [here]
+            89a591d2-5744-4e31-ba8a-92693cdc858a -- archive private [archive_private]
+            ae3085ab-456b-4eab-bb9c-7e31877d0d52 -- archive public [archive_public]
+    ok
+    whereis private/private_file (2 copies)
+            3098d3d7-e4fc-4860-90e1-f7e0ccd71242 -- seb@navi:/tmp/test_dupe/main [here]
+            89a591d2-5744-4e31-ba8a-92693cdc858a -- archive private [archive_private]
+    ok
+    whereis public/dupe_file (3 copies)
+            3098d3d7-e4fc-4860-90e1-f7e0ccd71242 -- seb@navi:/tmp/test_dupe/main [here]
+            89a591d2-5744-4e31-ba8a-92693cdc858a -- archive private [archive_private]
+            ae3085ab-456b-4eab-bb9c-7e31877d0d52 -- archive public [archive_public]
+    ok
+    whereis public/public_file (2 copies)
+            3098d3d7-e4fc-4860-90e1-f7e0ccd71242 -- seb@navi:/tmp/test_dupe/main [here]
+            ae3085ab-456b-4eab-bb9c-7e31877d0d52 -- archive public [archive_public]
+    ok
+
+I had a look at the changelog, but could not find in which precise version it was fixed.
+
+Thank you!  
+
+"""]]
diff --git a/doc/bugs/weird_interaction_between___34__required__34___and___34__numcopies__34___on_duplicate_files/comment_2_d20cb1d0abc9823aa557dcd698e735b2._comment b/doc/bugs/weird_interaction_between___34__required__34___and___34__numcopies__34___on_duplicate_files/comment_2_d20cb1d0abc9823aa557dcd698e735b2._comment
new file mode 100644
index 0000000000..17a5709604
--- /dev/null
+++ b/doc/bugs/weird_interaction_between___34__required__34___and___34__numcopies__34___on_duplicate_files/comment_2_d20cb1d0abc9823aa557dcd698e735b2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-11-13T17:46:43Z"
+ content="""
+This looks like the same problem as
+<http://git-annex.branchable.com/bugs/indeterminite_preferred_content_state_for_duplicated_file/>.
+
+I can't think of any change between those versions of git-annex that would
+have fixed it, in any case the general case of the problem still certianly
+exists.
+"""]]
diff --git a/doc/bugs/weird_unicode_bug_on_windows.mdwn b/doc/bugs/weird_unicode_bug_on_windows.mdwn
new file mode 100644
index 0000000000..f1f0377f89
--- /dev/null
+++ b/doc/bugs/weird_unicode_bug_on_windows.mdwn
@@ -0,0 +1,17 @@
+### Please describe the problem.
+
+My repo contains more than 1000 files, many are unicode filenames. Now that [this bug](http://git-annex.branchable.com/bugs/fails_to_get_content_from_bare_repo_on_windows/) is resolved, almost all files are fetched, except one file named '移动硬盘 1T Buffalo USB3.0 白色.rtf'. 
+
+### What steps will reproduce the problem?
+
+I reproduced this problem by creating a repo containing only this file with no content. If anyone wants to reproduce this, just create an empty file by copy and paste the above filename in the quote.
+
+I created the repo on mac, synced with a usb drive, then on windows machine try to sync it back.
+
+* When run git-annex webapp in the newly created windows repo, after the usb drive is added as a remote, an error popups up: http://imgur.com/5ZfIeGQ  although the remote is added successfully (http://imgur.com/04O8kaC)
+* On the command line, git annex sync runs successfully, but git annex get . failed: http://imgur.com/bIVrbe2
+* The file is there (http://imgur.com/URGwWWt) with correct filename, just that the content is not there. 
+
+### What version of git-annex are you using? On what operating system?
+
+Latest release of git-annex on both mac and windows. The initial repo on mac is indirect repo, the one on usb drive is a bare repo, the one on windows is direct repo.
diff --git a/doc/bugs/weird_unicode_bug_on_windows/comment_1_69af9bd8c7898fccc2219edd860d547b._comment b/doc/bugs/weird_unicode_bug_on_windows/comment_1_69af9bd8c7898fccc2219edd860d547b._comment
new file mode 100644
index 0000000000..b16155c5f0
--- /dev/null
+++ b/doc/bugs/weird_unicode_bug_on_windows/comment_1_69af9bd8c7898fccc2219edd860d547b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.203"
+ subject="comment 1"
+ date="2014-06-19T22:39:46Z"
+ content="""
+I don't quite reproduce this on windows. Instead of the file showing up and `git annex get` not getting it, the file never shows up at all. It seems that the direct mode merge code fails to create the file in the work tree. This also means that another sync will commit the deletion of the file.
+
+Based on the screenshot, I do have the identical filename checked into git, which git ls-files etc represents as \"\347\247\273\345\212\250\347\241\254\347\233\230 1T Buffalo USB3.0 \347\231\275\350\211\262.rtf\"
+
+Anyway, the root cause is probably the same. See [[todo/windows_support]] for a discussion of several issues with filename encodings and windows.
+"""]]
diff --git a/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote.mdwn b/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote.mdwn
new file mode 100644
index 0000000000..98ee21d161
--- /dev/null
+++ b/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote.mdwn
@@ -0,0 +1,30 @@
+`git annex whereis` claims that I have zero copies of two particular files. However, it is wrong; both files are present:
+
+[[!format txt """
+[jkt@vorvan fotky]$ git annex whereis '2011-08-13 Svatba Anička Fellnerová a výlet s Julií/IMG_4301'*
+(merging synced/git-annex into git-annex...)
+whereis 2011-08-13 Svatba Anička Fellnerová a výlet s Julií/IMG_4301.CR2 (0 copies) failed
+whereis 2011-08-13 Svatba Anička Fellnerová a výlet s Julií/IMG_4301.JPG (0 copies) failed
+git-annex: whereis: 2 failed
+[jkt@vorvan fotky]$ ll 2011-08-13\ Svatba\ Anička\ Fellnerová\ a\ výlet\ s\ Julií/IMG_4301*
+lrwxrwxrwx. 1 jkt jkt 331 Aug 13  2011 2011-08-13 Svatba Anička Fellnerová a výlet s Julií/IMG_4301.CR2 -> ../.git/annex/objects/mg/qq/SHA512E-s19424303--9bdd6917fe85a450b50233a444c1814d407d41b550b66661272728aaf139576cc7c09de158f47a33ff263d7d25253cec193d0e44ed5fb4a1581c28a9a05e75e1.CR2/SHA512E-s19424303--9bdd6917fe85a450b50233a444c1814d407d41b550b66661272728aaf139576cc7c09de158f47a33ff263d7d25253cec193d0e44ed5fb4a1581c28a9a05e75e1.CR2
+lrwxrwxrwx. 1 jkt jkt 329 Aug 13  2011 2011-08-13 Svatba Anička Fellnerová a výlet s Julií/IMG_4301.JPG -> ../.git/annex/objects/zG/xq/SHA512E-s4744850--da9b1e19f0ecdf08d2f5564232a9c7d4b5ec9fbc9c67033121e5c90468e09e5573ddac42469cfd51fb0d8328dff925830e2d753022365df6d92b115b77831228.JPG/SHA512E-s4744850--da9b1e19f0ecdf08d2f5564232a9c7d4b5ec9fbc9c67033121e5c90468e09e5573ddac42469cfd51fb0d8328dff925830e2d753022365df6d92b115b77831228.JPG
+"""]]
+
+Looking at another repo, the situation is the same:
+
+[[!format txt """
+jkt@svist /mnt/storage5/fotky[master] $ git annex whereis '2011-08-13 Svatba Anička Fellnerová a výlet s Julií/IMG_4301'*
+whereis 2011-08-13 Svatba Anička Fellnerová a výlet s Julií/IMG_4301.CR2 (0 copies) failed
+whereis 2011-08-13 Svatba Anička Fellnerová a výlet s Julií/IMG_4301.JPG (0 copies) failed
+git-annex: whereis: 2 failed
+jkt@svist /mnt/storage5/fotky[master] $ ll '2011-08-13 Svatba Anička Fellnerová a výlet s Julií/IMG_4301'*
+lrwxrwxrwx 1 jkt jkt 331 Mar  3 02:08 2011-08-13 Svatba Anička Fellnerová a výlet s Julií/IMG_4301.CR2 -> ../.git/annex/objects/mg/qq/SHA512E-s19424303--9bdd6917fe85a450b50233a444c1814d407d41b550b66661272728aaf139576cc7c09de158f47a33ff263d7d25253cec193d0e44ed5fb4a1581c28a9a05e75e1.CR2/SHA512E-s19424303--9bdd6917fe85a450b50233a444c1814d407d41b550b66661272728aaf139576cc7c09de158f47a33ff263d7d25253cec193d0e44ed5fb4a1581c28a9a05e75e1.CR2
+lrwxrwxrwx 1 jkt jkt 329 Mar  3 02:08 2011-08-13 Svatba Anička Fellnerová a výlet s Julií/IMG_4301.JPG -> ../.git/annex/objects/zG/xq/SHA512E-s4744850--da9b1e19f0ecdf08d2f5564232a9c7d4b5ec9fbc9c67033121e5c90468e09e5573ddac42469cfd51fb0d8328dff925830e2d753022365df6d92b115b77831228.JPG/SHA512E-s4744850--da9b1e19f0ecdf08d2f5564232a9c7d4b5ec9fbc9c67033121e5c90468e09e5573ddac42469cfd51fb0d8328dff925830e2d753022365df6d92b115b77831228.JPG
+"""]]
+
+The directory names are valid UTF-8. These are very common on my machine and there is a ton of directories with these funny names here -- all working without any real trouble.
+
+As far as I know, the file which the links point to is absolutely correct and not corrupted. Looking at the files in the directory chronologically, it also appears that the symlinks point to a correct file.
+
+[[!tag moreinfo]]
diff --git a/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_1_d823b7ee32183fbadd4a49f65e1a3a8b._comment b/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_1_d823b7ee32183fbadd4a49f65e1a3a8b._comment
new file mode 100644
index 0000000000..11c55bb5b1
--- /dev/null
+++ b/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_1_d823b7ee32183fbadd4a49f65e1a3a8b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.146"
+ subject="comment 1"
+ date="2014-03-05T03:14:09Z"
+ content="""
+Have you tried running `git annex fsck`?
+"""]]
diff --git a/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_2_f430538101f0ef6114b5e953248fa599._comment b/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_2_f430538101f0ef6114b5e953248fa599._comment
new file mode 100644
index 0000000000..e78971a90e
--- /dev/null
+++ b/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_2_f430538101f0ef6114b5e953248fa599._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.102"
+ subject="ping?"
+ date="2014-03-19T20:24:23Z"
+ content="""
+Have you tried running git-annex fsck?
+"""]]
diff --git a/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_3_d96ded3c27c705789e5689f19dbcabcb._comment b/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_3_d96ded3c27c705789e5689f19dbcabcb._comment
new file mode 100644
index 0000000000..3f38426f68
--- /dev/null
+++ b/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_3_d96ded3c27c705789e5689f19dbcabcb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jhannwong@c9c7a67b5632a4bbc0c959cfeb3d340e02f28565"
+ nickname="jhannwong"
+ subject="git annex fsck didn't solve this problem"
+ date="2015-11-20T01:49:03Z"
+ content="""
+Same problem here.
+"""]]
diff --git a/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_4_b70e83a44a85b006c2c6105660cd6a7a._comment b/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_4_b70e83a44a85b006c2c6105660cd6a7a._comment
new file mode 100644
index 0000000000..68e414e53d
--- /dev/null
+++ b/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote/comment_4_b70e83a44a85b006c2c6105660cd6a7a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-11-30T20:08:10Z"
+ content="""
+@jhannwong you had [2 repos with the same annex.uuid](http://git-annex.branchable.com/bugs/remote_repo_marked_as___34__here__34__)
+so if you had the same problem, it was a misconfiguration on your part.
+"""]]
diff --git a/doc/bugs/whereis_outputs_no_informaiton_for_unlocked_files.mdwn b/doc/bugs/whereis_outputs_no_informaiton_for_unlocked_files.mdwn
new file mode 100644
index 0000000000..d4d4826ff5
--- /dev/null
+++ b/doc/bugs/whereis_outputs_no_informaiton_for_unlocked_files.mdwn
@@ -0,0 +1,46 @@
+What steps will reproduce the problem?
+
+    ...:/tmp$ mkdir repro
+    ...:/tmp$ cd repro/
+    ...:/tmp/repro$ git init
+    Initialized empty Git repository in /tmp/repro/.git/
+    ...:/tmp/repro$ git annex init test
+    init test ok
+    ...:/tmp/repro$ echo "A" > a.txt
+    ...:/tmp/repro$ git annex add a.txt
+    add a.txt (checksum...) ok
+    (Recording state in git...)
+    ...:/tmp/repro$ git commit -m "add file"
+    [master (root-commit) bf53ce2] add file
+     1 file changed, 1 insertion(+)
+     create mode 120000 a.txt
+    ...:/tmp/repro$ git annex whereis a.txt
+    whereis a.txt (1 copy) 
+      	5c028c6a-2c5e-11e2-bb9c-17bd7ce81377 -- here (test)
+    ok
+    ...:/tmp/repro$ git annex unlock a.txt
+    unlock a.txt (copying...) ok
+    ...:/tmp/repro$ git annex whereis a.txt
+
+What is the expected output? What do you see instead?
+
+    I'd expect that whereis executed on an unlocked file would behave like whereis executed on a locked file.
+
+What version of git-annex are you using? On what operating system?
+
+    $ cat /etc/issue
+    Ubuntu 12.04.1 LTS \n \l
+
+    $ git-annex version
+    git-annex version: 3.20120406
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3
+    upgrade supported from repository versions: 0 1 2
+
+    $ uname -a
+    Linux ... 3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:16:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
+
+Please provide any additional information below.
+
+[[!tag confirmed]]
diff --git a/doc/bugs/whereis_outputs_no_informaiton_for_unlocked_files/comment_1_47bd0fc8d1c65f8a868d9722e66c71db._comment b/doc/bugs/whereis_outputs_no_informaiton_for_unlocked_files/comment_1_47bd0fc8d1c65f8a868d9722e66c71db._comment
new file mode 100644
index 0000000000..e92ec33f99
--- /dev/null
+++ b/doc/bugs/whereis_outputs_no_informaiton_for_unlocked_files/comment_1_47bd0fc8d1c65f8a868d9722e66c71db._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.102"
+ subject="comment 1"
+ date="2014-03-19T20:52:08Z"
+ content="""
+The reason this doesn't work is that, in indirect mode, git-annex looks at the current state of the symlink in the work tree to know what key is associated with a file. And an unlocked file has no symlink.
+
+Direct mode avoids this problem, but at the expense of being less flexible and well, doing more work.
+"""]]
diff --git a/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals.mdwn b/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals.mdwn
new file mode 100644
index 0000000000..b16aa13b52
--- /dev/null
+++ b/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals.mdwn
@@ -0,0 +1,66 @@
+In DataLad, there's a spot where we set `alwayscommit=false` when
+doing bulk setting of metadata.  When debugging a test failure related
+to this, Adina, who was testing on Windows, reported that the script
+below shows two commits rather than the one commit I see on my end and
+would expect.  Here's the good output on my Debian system:
+
+[[!format sh """
+set -eu
+
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/ga-XXXXXXX)"
+
+alwayscommit=false
+
+git init && git annex init
+echo foo >foo && git annex add foo
+git -c annex.alwayscommit=$alwayscommit annex metadata --set a=b foo
+git -c annex.alwayscommit=$alwayscommit annex metadata --set c=d foo
+git commit -mc
+
+git annex version
+echo "-----"
+git log --oneline --stat git-annex -- '*.met'
+"""]]
+
+```
+[... 23 lines ...]
+git-annex version: 8.20201128-g2878ab456
+build flags: Assistant Webapp Pairing Inotify TorrentParser Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+-----
+9436e93 update
+ ...9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.log.met | 2 ++
+ 1 file changed, 2 insertions(+)
+```
+
+And here's the output Adina reported on Windows:
+
+```
+c44294d (git-annex) update
+ ...b9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.log.met | 1 +
+ 1 file changed, 1 insertion(+)
+2395118 update
+ ...b9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.log.met | 1 +
+ 1 file changed, 1 insertion(+)
+```
+
+Adina saw this behavior on two Windows machines, one with
+8.20201008-g65c1687 and the other with 8.20201008-g7e24b2587.
+
+I realize this issue probably isn't something you can debug on your
+end, but perhaps you can think of an obvious culprit or another
+Windows user has ideas.
+
+Thanks.
+
+Related discussion on DataLad issue tracker:
+https://github.com/datalad/datalad/pull/5202#discussion_r536178860
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
diff --git a/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_1_57c55f62ced563f70612cba994b1ea8b._comment b/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_1_57c55f62ced563f70612cba994b1ea8b._comment
new file mode 100644
index 0000000000..4d9e200cf2
--- /dev/null
+++ b/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_1_57c55f62ced563f70612cba994b1ea8b._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-12-11T19:52:36Z"
+ content="""
+My guess would be there could be some place where git-annex runs git-annex
+as a child process, itself, but does not pass along the git config set with -c.
+
+So you might try setting annex.alwayscommit=false in .git/config
+and overriding it true when you do want to commit and see if that avoids
+the problem.
+
+Just thinking about it, I noticed that new code in Annex.TransferrerPool to
+run [[todo/git-annex_transferrer_does_not_propigate_-c]]. That's certainly
+not what you ran into, but there are probably others, and maybe one of them
+is somehow windows specific. git-annex smudge which gets run indirectly
+by git would be the obvious guess, although it does avoid committing on
+shutdown at least.
+
+However, the other thing is that "alwayscommit=false" does not really imply
+"never commit in any circumstances". It just means, don't commit every time
+some new data has been logged. In particular, Annex.Branch.updateTo' may
+need to update the index due to the git-annex branch having gotten ahead of
+the index. If there are uncommitted journalled changes, it unconditionally
+commits in that situation. I don't know if I would consider that a bug.
+Since you have a new repo, it's not that either. There might be other cases
+like that, although I don't know why you'd only see it happening on windows.
+"""]]
diff --git a/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_2_fcdc6ef1dd464d25ec3e26dac828830e._comment b/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_2_fcdc6ef1dd464d25ec3e26dac828830e._comment
new file mode 100644
index 0000000000..dcdf47855f
--- /dev/null
+++ b/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_2_fcdc6ef1dd464d25ec3e26dac828830e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 2"
+ date="2020-12-11T20:56:04Z"
+ content="""
+Thanks for response.
+
+> However, the other thing is that \"alwayscommit=false\" does not
+> really imply \"never commit in any circumstances\". [...] I don't know
+> if I would consider that a bug.
+
+Fair point.  At least for the spots I'm aware of, DataLad's use of
+alwayscommit=false aligns fine with that.  We're performing operations
+where we'd _like_ to reduce the number of commits, but that being
+effective is in no way relied on.
+"""]]
diff --git a/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_3_0460c7476fae95048f87cb6dd9d4a2ae._comment b/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_3_0460c7476fae95048f87cb6dd9d4a2ae._comment
new file mode 100644
index 0000000000..dca229f7c2
--- /dev/null
+++ b/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_3_0460c7476fae95048f87cb6dd9d4a2ae._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="adina.wagner@2a4cac6443aada2bd2a329b8a33f4a7b87cc8eff"
+ nickname="adina.wagner"
+ avatar="http://cdn.libravatar.org/avatar/80b124ad61d6008fa0f6f0b4b0f7c2ef"
+ subject="comment 3"
+ date="2020-12-12T20:32:05Z"
+ content="""
+Thanks a lot for the issue and the response!
+
+> So you might try setting annex.alwayscommit=false in .git/config and overriding it true when you do want to commit and see if that avoids the problem.
+
+I have tried this, in a couple of flavors, just to be sure (running from bash, sh, cmd, Anaconda prompt; with local, global configuration scopes of annex.alwayscommit=false) and I couldn't yet convince the computer to create only one instead of two commits with the [test script from Kyle](https://github.com/datalad/datalad/pull/5202#discussion_r536178860). But as both you and Kyle said its not a bug or problematic behavior, I also personally do not care much about it. :) If I ever stumble across any possible explanation or workaround for this, I'll comment here.
+
+> However, the other thing is that \"alwayscommit=false\" does not really imply \"never commit in any circumstances\". It just means, don't commit every time some new data has been logged. In particular, Annex.Branch.updateTo' may need to update the index due to the git-annex branch having gotten ahead of the index. If there are uncommitted journalled changes, it unconditionally commits in that situation. I don't know if I would consider that a bug. Since you have a new repo, it's not that either. There might be other cases like that, although I don't know why you'd only see it happening on windows.
+
+That makes sense, thanks for the discussion! I also don't know why I am seeing it on Windows only. Just as an FYI on the machines I have used: I have observed the behavior described in this issue on two different Windows machines, and all machines I have tried annex.alwayscommit=false and observed the expected behavior ran Debian (including in WSL2 on Windows 10).
+
+PS: thanks for git-annex! :)
+
+
+
+"""]]
diff --git a/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_4_65647b8423127d450b0d1753767943d6._comment b/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_4_65647b8423127d450b0d1753767943d6._comment
new file mode 100644
index 0000000000..5733ae85cd
--- /dev/null
+++ b/doc/bugs/windows__58___commits_created_despite_alwayscommit__61__fals/comment_4_65647b8423127d450b0d1753767943d6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-01-11T18:47:54Z"
+ content="""
+The script only makes one commit of the metadata when I run it on linux.
+(Including in an adjusted unlocked branch like windows uses.)
+
+Since you're using `git -c`, git uses an env var to propagate that setting
+on to child processes. So it's possible something on windows prevents that
+working.
+"""]]
diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__.mdwn b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__.mdwn
new file mode 100644
index 0000000000..4b4c10d4d4
--- /dev/null
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__.mdwn
@@ -0,0 +1,182 @@
+### Please describe the problem.
+
+After release 10.20220927 any get or drop command that changes availability of content causes git-annex
+to issue the following notice:
+
+```
+  git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
+``` 
+
+Yet git status is clean and no `git-annex restage` is needed.
+
+### What steps will reproduce the problem?
+
+Use a crippled filesystem on Windows with adjusted unlocked branches and try to get content from a remote or drop content locally.
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20220927-g26dea5641
+build flags: Assistant Webapp Pairing TorrentParser Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+"""]]
+
+The above is for all practical purposes the released version 10.20220927, just a few commits before the release with no code changes.
+
+Windows 10 version 21H2 (build 19044.2006), 64 bit.
+
+### Please provide any additional information below.
+
+[[!format sh """
+C:\Users\jkniiv> k:
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B\arkistoidut [adjusted/master(unlocked)]> cd ..
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> duf .
+╭─────────────────────────────────────────────────────────────────────╮
+│ 1 local device                                                      │
+├────────────┬──────┬──────┬───────┬────────┬──────┬──────────────────┤
+│ MOUNTED ON │ SIZE │ USED │ AVAIL │  USE%  │ TYPE │ FILESYSTEM       │
+├────────────┼──────┼──────┼───────┼────────┼──────┼──────────────────┤
+│ K:\        │ 3.6T │ 3.6T │ 34.9G │  99.1% │ NTFS │ Jibun.Tila2109kc │
+╰────────────┴──────┴──────┴───────┴────────┴──────┴──────────────────╯
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex-sync --content
+merge synced/master (Merging into master...)
+Updating 6d4e731..05224ad
+Fast-forward
+ Jarkon ThinkPad T450s (Win10 v21H1) . B/79698DAC29A079D3-06-06.mrimg | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/79698DAC29A079D3-06-06.mrimg
+(Merging into adjusted branch...)
+Updating 51cb822..f175b90
+Fast-forward
+ Jarkon ThinkPad T450s (Win10 v21H1) . B/79698DAC29A079D3-06-06.mrimg | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 Jarkon ThinkPad T450s (Win10 v21H1) . B/79698DAC29A079D3-06-06.mrimg
+ok
+pull origin
+From G:\Reflect-varmistukset
+   f984af1..013ea2d  git-annex     -> origin/git-annex
+   6d4e731..05224ad  master        -> origin/master
+   6d4e731..05224ad  synced/master -> origin/synced/master
+ok
+get Jarkon ThinkPad T450s (Win10 v21H1) . B/79698DAC29A079D3-06-06.mrimg (from origin...)
+ok
+pull origin
+ok
+(recording state in git...)
+push origin
+Enumerating objects: 9, done.
+Counting objects: 100% (9/9), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (5/5), done.
+Writing objects: 100% (5/5), 476 bytes | 238.00 KiB/s, done.
+Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
+To G:\Reflect-varmistukset
+   f984af1..3ebe493  git-annex -> synced/git-annex
+ok
+(recording state in git...)
+
+  git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex version --raw
+10.20220927-g26dea5641
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex drop 79698DAC29A079D3-06-06.mrimg
+drop 79698DAC29A079D3-06-06.mrimg (unsafe)
+  Could only verify the existence of 1 out of 2 necessary copies
+
+  Rather than dropping this file, try using: git annex move
+
+  (Use --force to override this check, or adjust numcopies.)
+failed
+drop: 1 failed
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex drop --force 79698DAC29A079D3-06-06.mrimg
+drop 79698DAC29A079D3-06-06.mrimg ok
+(recording state in git...)
+
+  git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> echo "Installing version 10.20220823-g34e313f78 in the background"
+Installing version 10.20220823-g34e313f78 in the background
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex version --raw
+10.20220823-g34e313f78
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls 79698DAC29A079D3-06-06.mrimg
+
+    Directory: K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           30.9.2022    14:53             87 79698DAC29A079D3-06-06.mrimg
+
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex get 79698DAC29A079D3-06-06.mrimg
+get 79698DAC29A079D3-06-06.mrimg (from origin...)
+ok
+(recording state in git...)
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex drop --force 79698DAC29A079D3-06-06.mrimg
+drop 79698DAC29A079D3-06-06.mrimg ok
+(recording state in git...)
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls 79698DAC29A079D3-06-06.mrimg
+
+    Directory: K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           30.9.2022    15:01             87 79698DAC29A079D3-06-06.mrimg
+
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> head 79698DAC29A079D3-06-06.mrimg
+/annex/objects/BLAKE2B160E-s8305341589--ab8ca27391c2f68c1c4d677942deaf5022498752.mrimg
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> cat ..\.git\config
+[core]
+        repositoryformatversion = 0
+        filemode = false
+        bare = false
+        logallrefupdates = true
+        symlinks = false
+        ignorecase = true
+[interactive]
+        diffFilter = delta --color-only
+[remote "origin"]
+        url = G:\\Reflect-varmistukset
+        fetch = +refs/heads/*:refs/remotes/origin/*
+        fetch = ^refs/heads/adjusted/*
+        annex-uuid = redacted1-1789-4471-96a0-redactedabcd
+[annex]
+        thin = true
+        backend = MD5E
+        maxextensionlength = 8
+        uuid = redacted2-45c8-4a86-b348-redactedabcd
+        sshcaching = false
+        crippledfilesystem = true
+        version = 10
+        diskreserve = 1000M
+[filter "annex"]
+        smudge = git-annex smudge -- %f
+        clean = git-annex smudge --clean -- %f
+[merge]
+        renames = true
+        directoryRenames = false
+
+# End of transcript or log.
+"""]]
+
+Btw. the git `annex-sync` alias above is defined to be `annex sync --no-commit`.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Git Annex is great. I use it several times a week with my multigigabyte backups, where it gives structure to my image-based backup routines, so you could say I'm a believer. :)
+
+Big thanks, Joey!
+
+[[!meta author=jkniiv]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_1_e738eb3d45bb7c4baa0a5c88cdf7a40a._comment b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_1_e738eb3d45bb7c4baa0a5c88cdf7a40a._comment
new file mode 100644
index 0000000000..a5594e67c0
--- /dev/null
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_1_e738eb3d45bb7c4baa0a5c88cdf7a40a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1t"""
+ date="2022-09-30T17:24:27Z"
+ content="""
+Not sure this is quite the same situation, but on linux, I am seeing
+`git-annex unlock` of a locked file display the warning.
+
+Also, .git/annex/restage.log is left empty after the command completes.
+Which seems to indicate it managed to restage the file after all. Is that
+file empty for you on windows after it displays the warning and before
+running other commands?
+"""]]
diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_2_8ecb958a1a2c8cd9fd37798c0d4eb0cf._comment b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_2_8ecb958a1a2c8cd9fd37798c0d4eb0cf._comment
new file mode 100644
index 0000000000..c371e292bc
--- /dev/null
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_2_8ecb958a1a2c8cd9fd37798c0d4eb0cf._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-30T17:43:13Z"
+ content="""
+Found the bug: "fd:16: hFlush: illegal operation (handle is closed)"
+This exception gets caught after it's actually finished restaging
+everything, so it displays the warning unncessarily.
+
+Pretty sure the problem on Windows will have the same cause.
+"""]]
diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_3_aed127be0616464fda064f00de954fc2._comment b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_3_aed127be0616464fda064f00de954fc2._comment
new file mode 100644
index 0000000000..30745fff7d
--- /dev/null
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_3_aed127be0616464fda064f00de954fc2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-09-30T17:55:20Z"
+ content="""
+I've fixed this, and I'm planning to make a minor release on Monday for it.
+"""]]
diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_4_42ef3d3d157a97a202718f3b768916f8._comment b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_4_42ef3d3d157a97a202718f3b768916f8._comment
new file mode 100644
index 0000000000..ac5bc2b181
--- /dev/null
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_4_42ef3d3d157a97a202718f3b768916f8._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="restage.log was empty indeed"
+ date="2022-10-01T05:14:17Z"
+ content="""
+Just for completeness sake:
+
+[[!format sh \"\"\"
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git-annex version --raw
+10.20220927-g26dea5641
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex drop --force 79698DAC29A079D3-06-06.mrimg
+drop 79698DAC29A079D3-06-06.mrimg ok
+(recording state in git...)
+
+  git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls ..\.git\annex\restage.log
+
+    Directory: K:\Reflect-varmistukset\.git\annex
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           1.10.2022     7:47              0 restage.log
+
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> time git annex get 79698DAC29A079D3-06-06.mrimg
+get 79698DAC29A079D3-06-06.mrimg (from origin...)
+ok
+(recording state in git...)
+
+  git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
+00:01:53.0001475
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls ..\.git\annex\restage.log
+
+    Directory: K:\Reflect-varmistukset\.git\annex
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           1.10.2022     8:02              0 restage.log
+
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+\"\"\"]]
+
+"""]]
diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_5_8f71510a7547db8d0c63e4a4e3ddbd65._comment b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_5_8f71510a7547db8d0c63e4a4e3ddbd65._comment
new file mode 100644
index 0000000000..d81bf9b141
--- /dev/null
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_5_8f71510a7547db8d0c63e4a4e3ddbd65._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 5"
+ date="2022-10-01T08:23:43Z"
+ content="""
+Yes, thank you, Joey! The annoying (but sometimes necessary) reminder is gone now in regular get/drop
+circumstances:
+
+[[!format sh \"\"\"
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex drop --force 79698DAC29A079D3-06-06.mrimg
+drop 79698DAC29A079D3-06-06.mrimg ok
+(recording state in git...)
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls ..\.git\annex\restage.log
+
+    Directory: K:\Reflect-varmistukset\.git\annex
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           1.10.2022    11:08              0 restage.log
+
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> time git annex get 79698DAC29A079D3-06-06.mrimg
+get 79698DAC29A079D3-06-06.mrimg (from origin...)
+ok
+(recording state in git...)
+00:01:50.7710391
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls ..\.git\annex\restage.log
+
+    Directory: K:\Reflect-varmistukset\.git\annex
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           1.10.2022    11:11              0 restage.log
+
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex version --raw
+10.20220928-g49ee07f93
+\"\"\"]]
+
+:)
+
+"""]]
diff --git a/doc/bugs/windows__58___two_repo_tests_fail_after_commit_5a98f2d5.mdwn b/doc/bugs/windows__58___two_repo_tests_fail_after_commit_5a98f2d5.mdwn
new file mode 100644
index 0000000000..a359ca8bee
--- /dev/null
+++ b/doc/bugs/windows__58___two_repo_tests_fail_after_commit_5a98f2d5.mdwn
@@ -0,0 +1,217 @@
+### Please describe the problem.
+
+Recently I found that two repo tests, namely 'concurrent get of dup key regression'
+and 'import', fail due to locking problems. I bisected this on my Windows laptop and
+found that [[!commit 5a98f2d50913682c4ebe0e0c4ce695c450a96091]] is the first bad commit.
+
+### What steps will reproduce the problem?
+
+`stack setup && stack build`. Then copy git-annex.exe to `C:\annx` and in (Git) Bash say:
+
+[[!format sh """
+$ ./git-annex test -p 'Repo Tests' 2>&1 | tee git-annex.test--p-Repo_Tests.LOG~202
+$ grep -E '(concurrent get of dup key regression|import):' git-annex.test--p-Repo_Tests.LOG~202
+"""]]
+
+Observe two FAILs.
+
+(It is unfortunate that you can't call for instance `./git-annex.exe test -p 'concurrent get of dup key regression'`
+directly because of an unrelated setup issue with Tasty. I guess this would warrant a separate bug report.)
+
+### Please provide any additional information below.
+
+_Under Windows with 10.20220505-g5a98f2d50:_
+
+[[!format sh """
+jkniiv@AINESIS MINGW64 /c/annx
+$ cat git-annex.test--p-Repo_Tests.LOG~202
+
+All 0 tests passed (0.00s)
+Tests
+  Repo Tests v8 adjusted unlocked branch
+    Init Tests
+      init:                                         OK (10.30s)
+      add:                                          OK (14.20s)
+    borg remote:                                    OK
+    uninit:                                         OK (15.54s)
+    conflict resolution (mixed directory and file): OK (154.59s)
+    concurrent get of dup key regression:           FAIL (18.41s)
+      .\\Test\\Framework.hs:70:
+      drop with dup failed (transcript follows)
+      drop foo ok
+      drop foo2
+      failed
+      (recording state in git...)
+      git-annex: content is locked
+      drop: 1 failed
+
+      Use -p '/Repo Tests/&&/concurrent get of dup key regression/' to rerun this test only.
+    migrate (via gitattributes):                    OK (35.88s)
+    fsck (basics):                                  OK (33.18s)
+    copy:                                           OK (29.05s)
+    drop (no remote):                               OK (18.30s)
+    shared clone:                                   OK (8.98s)
+
+1 out of 11 tests failed (338.52s)
+
+All 0 tests passed (0.03s)
+Tests
+  Repo Tests v8 adjusted unlocked branch
+    Init Tests
+      init:                          OK (10.26s)
+      add:                           gpg testing not implemented on Windows
+OK (13.95s)
+    crypto:                          OK
+    uninit (in git-annex branch):    OK (12.13s)
+    conflict resolution symlink bit: OK
+    union merge regression:          OK (148.89s)
+    unused:                          OK (59.95s)
+    fsck (bare):                     OK (5.63s)
+    lock:                            OK (29.89s)
+    drop (with remote):              OK (22.18s)
+    log:                             OK (10.16s)
+    add dup:                         OK (15.61s)
+
+All 12 tests passed (328.74s)
+Tests
+  Repo Tests v8 adjusted unlocked branch
+    Init Tests
+      init:                                               OK (10.27s)
+      add:                                                OK (14.07s)
+    rsync remote:                                         OK (8.80s)
+    conflict resolution (mixed locked and unlocked file): OK (70.62s)
+    conflict resolution (adjusted branch):                OK (92.89s)
+    version:                                              OK (10.99s)
+    conversion annexed to git:                            OK (18.28s)
+    fix:                                                  OK (9.54s)
+    move (ssh remote):                                    OK
+    unannex (no copy):                                    OK (12.49s)
+    export_import:                                        OK (88.90s)
+
+All 11 tests passed (336.95s)
+Tests
+  Repo Tests v8 adjusted unlocked branch
+    Init Tests
+      init:                                OK (9.80s)
+      add:                                 OK (13.22s)
+    add subdirs:                           OK (21.85s)
+    hook remote:                           OK (9.82s)
+    conflict resolution (nonannexed file): OK (133.39s)
+    transition propagation:                OK (139.19s)
+    merge:                                 OK (11.89s)
+    fsck --from remote:                    OK (10.01s)
+    edit (pre-commit):                     OK (15.37s)
+    get (ssh remote):                      OK
+    import:                                FAIL (20.87s)
+      .\\Test\\Framework.hs:70:
+      drop failed (transcript follows)
+      drop import1/f ok
+      drop import2/f
+      failed
+      drop import5/f
+      failed
+      (recording state in git...)
+      git-annex: content is locked
+      git-annex: content is locked
+      drop: 2 failed
+
+      Use -p '/Repo Tests/&&/import/' to rerun this test only.
+    ignore deleted files:                  OK (8.43s)
+
+1 out of 12 tests failed (393.92s)
+Tests
+  Repo Tests v8 adjusted unlocked branch
+    Init Tests
+      init:                                OK (10.27s)
+      add:                                 OK (14.14s)
+    bup remote:                            OK (8.85s)
+    map:                                   OK (12.69s)
+    conflict resolution movein regression: OK (92.81s)
+    sync:                                  OK (58.83s)
+    migrate:                               OK (35.32s)
+    trust:                                 OK (30.37s)
+    move (numcopies):                      OK (40.73s)
+    unannex (with copy):                   OK (14.55s)
+    export_import_subdir:                  OK (56.87s)
+
+All 11 tests passed (375.49s)
+Tests
+  Repo Tests v8 adjusted unlocked branch
+    Init Tests
+      init:                                       OK (8.97s)
+      add:                                        OK (13.79s)
+    preferred content:                            OK (63.02s)
+    upgrade:                                      OK (10.77s)
+    conflict resolution (uncommitted local file): OK (101.39s)
+    adjusted branch merge regression:             OK (19.12s)
+    describe:                                     OK (12.57s)
+    fsck (local untrusted):                       OK (26.13s)
+    lock --force:                                 OK (16.35s)
+    drop (untrusted remote):                      OK (24.97s)
+    view:                                         OK (15.62s)
+    add extras:                                   OK (13.99s)
+
+All 12 tests passed (326.79s)
+Tests
+  Repo Tests v8 adjusted unlocked branch
+    Init Tests
+      init:                                   OK (10.67s)
+      add:                                    OK (13.44s)
+    addurl:                                   OK (16.86s)
+    directory remote:                         OK (32.54s)
+    conflict resolution (nonannexed symlink): OK (40.41s)
+    conflict resolution:                      OK (86.32s)
+    info:                                     OK (13.57s)
+    conversion git to annexed:                OK (19.97s)
+    partial commit:                           OK (20.86s)
+    move:                                     OK (41.33s)
+    reinject:                                 OK (16.08s)
+    metadata:                                 OK (23.76s)
+
+All 12 tests passed (335.87s)
+Tests
+  Repo Tests v8 adjusted unlocked branch
+    Init Tests
+      init:                             OK (9.19s)
+      add:                              OK (13.38s)
+    required_content:                   OK (31.54s)
+    whereis:                            OK (25.92s)
+    conflict resolution (removed file): OK (203.83s)
+    adjusted branch subtree regression: OK (30.38s)
+    find:                               OK (26.15s)
+    fsck (remote untrusted):            OK (18.86s)
+    edit (no pre-commit):               OK (17.01s)
+    get:                                OK (13.68s)
+    magic:                              OK (5.86s)
+    readonly remote:                    OK
+
+All 12 tests passed (395.88s)
+  (Failures above could be due to a bug in git-annex, or an incompatibility
+   with utilities, such as git, installed on this system.)
+
+# End of transcript.
+"""]]
+
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20220505-g5a98f2d50
+build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+"""]]
+
+Windows 10 version 21H2 (build 19044.1706), 64 bit.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Git Annex is great. I use it several times a week with my multigigabyte backups, where it gives structure to my image-based backup routines, so you could say I'm a believer. :)
+
+[[!meta author=jkniiv]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/windows__58___two_repo_tests_fail_after_commit_5a98f2d5/comment_1_af091a5799ac0445033c05173e25a4af._comment b/doc/bugs/windows__58___two_repo_tests_fail_after_commit_5a98f2d5/comment_1_af091a5799ac0445033c05173e25a4af._comment
new file mode 100644
index 0000000000..0328e72957
--- /dev/null
+++ b/doc/bugs/windows__58___two_repo_tests_fail_after_commit_5a98f2d5/comment_1_af091a5799ac0445033c05173e25a4af._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-23T16:57:34Z"
+ content="""
+Thanks for another fine bug report.
+
+I took a look at that commit, and it seems that reverting it for Windows
+makes the most sense. There were two places where it changed behavior on
+Windows, that were both separated from the code paths for other OS's.
+
+I've made that change, which should fix it. I'm going to close this bug
+report, but please follow up if you still see the issue.
+
+(Also, I've opened [[tasty_test_limiting_broken_by_concurrency]]
+"""]]
diff --git a/doc/bugs/windows__58___two_repo_tests_fail_after_commit_5a98f2d5/comment_2_5c7ec0d8520f957ec4f6a4df30941cd8._comment b/doc/bugs/windows__58___two_repo_tests_fail_after_commit_5a98f2d5/comment_2_5c7ec0d8520f957ec4f6a4df30941cd8._comment
new file mode 100644
index 0000000000..3d80885926
--- /dev/null
+++ b/doc/bugs/windows__58___two_repo_tests_fail_after_commit_5a98f2d5/comment_2_5c7ec0d8520f957ec4f6a4df30941cd8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 2"
+ date="2022-05-23T19:41:27Z"
+ content="""
+That did seem to do the trick as the testsuite passes fully again. Thanks for the quick fix, Joey!
+"""]]
diff --git a/doc/bugs/windows_autostart.mdwn b/doc/bugs/windows_autostart.mdwn
new file mode 100644
index 0000000000..f5b7a10f75
--- /dev/null
+++ b/doc/bugs/windows_autostart.mdwn
@@ -0,0 +1,4 @@
+I installed git-annex in windows using the file git-annex-installer.exe, and now each time I'm starting my computer I get a message telling me that "C:\Program Files\Git\cmd\git-annex-autostart.vbs" cannot be found.
+
+This is very annoying and I don't need git-annex to be started at startup. I looked in msconfig.exe and I didn't find any entry for git-annex. Is there a way to disable this?
+
diff --git a/doc/bugs/windows_autostart/comment_1_80a2561901554ddb45db719c086629b2._comment b/doc/bugs/windows_autostart/comment_1_80a2561901554ddb45db719c086629b2._comment
new file mode 100644
index 0000000000..f529a22c84
--- /dev/null
+++ b/doc/bugs/windows_autostart/comment_1_80a2561901554ddb45db719c086629b2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jeanpmbox-456@7222359de8d1f37a7cf25a519e8faf90a9517b50"
+ nickname="jeanpmbox-456"
+ avatar="http://cdn.libravatar.org/avatar/164eb4254c5f83d95d3e0b810ff7aab9"
+ subject="comment 1"
+ date="2020-02-01T11:35:37Z"
+ content="""
+I finally saw thanks to the file `Build/NullSoftInstaller.hs` and to NirSoft Program WhatInStartup that the startup script is located in `%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup`.
+
+It would be nice to have an option to activate this or not in the installation.
+"""]]
diff --git a/doc/bugs/windows_autostart/comment_2_89078768dc9d9efd2d237fff5c7320ad._comment b/doc/bugs/windows_autostart/comment_2_89078768dc9d9efd2d237fff5c7320ad._comment
new file mode 100644
index 0000000000..71e05088b3
--- /dev/null
+++ b/doc/bugs/windows_autostart/comment_2_89078768dc9d9efd2d237fff5c7320ad._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-02-25T20:37:20Z"
+ content="""
+It seems to me that the real bug here is that somehow 
+"C:\Program Files\Git\cmd\git-annex-autostart.vbs" either
+does not exist, or it fails to run it.
+
+Does that file actually exist? It's supposed to be installed the same
+as git-annex.exe gets installed, in the same directory.
+"""]]
diff --git a/doc/bugs/windows_autostart/comment_3_393899b1630cce0dc6b12ec7d29b81ca._comment b/doc/bugs/windows_autostart/comment_3_393899b1630cce0dc6b12ec7d29b81ca._comment
new file mode 100644
index 0000000000..85ac68e457
--- /dev/null
+++ b/doc/bugs/windows_autostart/comment_3_393899b1630cce0dc6b12ec7d29b81ca._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jeanpmbox-456@7222359de8d1f37a7cf25a519e8faf90a9517b50"
+ nickname="jeanpmbox-456"
+ avatar="http://cdn.libravatar.org/avatar/164eb4254c5f83d95d3e0b810ff7aab9"
+ subject="comment 3"
+ date="2020-05-15T21:14:53Z"
+ content="""
+It came when I installed git-annex, I did not ask nor tick a box to have this script loaded at startup. I installed git-annex in a different directory but the entry which was added to the start menu did not take that into account, and pointed to the default installation directory.
+"""]]
diff --git a/doc/bugs/windows_autostart/comment_4_b8d0b38aa7363e97c295b049bd939ad1._comment b/doc/bugs/windows_autostart/comment_4_b8d0b38aa7363e97c295b049bd939ad1._comment
new file mode 100644
index 0000000000..a6f775d8a2
--- /dev/null
+++ b/doc/bugs/windows_autostart/comment_4_b8d0b38aa7363e97c295b049bd939ad1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="scy"
+ avatar="http://cdn.libravatar.org/avatar/f5a8df59fb198cf762f77aa239193e20"
+ subject="comment 4"
+ date="2021-09-02T08:17:02Z"
+ content="""
+I’ve also encountered this problem. Found it weird that git-annex on Windows (according to the installation manual) requires Git for Windows to be installed and then defaults to installing itself into the same directory (`C:\Program Files\Git`). Is this required? Won’t this cause problems when Git for Windows updates? That’s why I installed it to `C:\Program Files\git-annex`, but yeah, the link that gets put into `Startup` apparently doesn’t take the real installation directory into account and just uses a hard-coded path…?
+"""]]
diff --git a/doc/bugs/windows_autostart/comment_5_43077649e3ca6a132958c2a2b4914c3b._comment b/doc/bugs/windows_autostart/comment_5_43077649e3ca6a132958c2a2b4914c3b._comment
new file mode 100644
index 0000000000..4493f16f8f
--- /dev/null
+++ b/doc/bugs/windows_autostart/comment_5_43077649e3ca6a132958c2a2b4914c3b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-09-03T15:42:41Z"
+ content="""
+The autostart file is generated by the nullsoft installer, and
+uses `$INSTDIR/cmd`, it does not hard code any path.
+
+It's installed into `Program Files/Git/cmd` because that is the only
+way to make sure that git finds the git-annex command when you run
+"git annex".
+"""]]
diff --git a/doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf.mdwn b/doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf.mdwn
new file mode 100644
index 0000000000..3a84a49494
--- /dev/null
+++ b/doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf.mdwn
@@ -0,0 +1,122 @@
+### Please describe the problem.
+
+Thanks for the improvements in Windows long file support but it turns out that Git-annex
+commit 54ad1b4cf doesn't quite compile on Windows without a small fix to Remote.Git and
+Utility.DirWatcher.Win32Notify regarding imports.
+
+### What steps will reproduce the problem?
+
+`stack setup && stack build`
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20230228-g54ad1b4cf
+build flags: Assistant Webapp Pairing TorrentParser Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+"""]]
+
+A successful build that passes the testsuite on Windows is achieved with the patch below.
+
+Windows 10 version 22H2 (build 19045.2486), 64 bit.
+
+### Please provide any additional information below.
+
+Relevant parts of the build log:
+
+[[!format sh """
+jkniiv@AINESIS MINGW64 /c/annx
+$ tail -n 35 stack.build.LOG~102
+[143 of 676] Compiling Types.Backend
+[144 of 676] Compiling Database.Handle
+[145 of 676] Compiling Database.Queue
+[146 of 676] Compiling Database.Keys.Handle
+[147 of 676] Compiling Utility.Gpg
+[148 of 676] Compiling Types.Crypto
+[149 of 676] Compiling Utility.DirWatcher.Types
+[150 of 676] Compiling Utility.DirWatcher.Win32Notify
+
+Utility\DirWatcher\Win32Notify.hs:54:51: error:
+    * Variable not in scope: isRegularFile :: FileStatus -> Bool
+    * Perhaps you meant `System.PosixCompat.Files.isRegularFile' (imported from System.PosixCompat.Files)
+   |
+54 |                                                 | isRegularFile s ->
+
+   |                                                   ^^^^^^^^^^^^^
+
+Utility\DirWatcher\Win32Notify.hs:62:36: error:
+    Variable not in scope: getFileStatus :: a -> m a1
+   |
+62 |         getstatus = catchMaybeIO . getFileStatus
+
+   |                                    ^^^^^^^^^^^^^
+
+
+Error: [S-7282]
+       Stack failed to execute the build plan.
+
+       While executing the build plan, Stack encountered the following errors:
+
+       [S-7011]
+       While building package git-annex-10.20230227 (scroll up to its section to see the error)
+       using:
+       C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-230302-54ad1b4cf\.stack-work\dist\274b403a\setup\setup --verbose=1 --builddir=.stack-work\dist\274b403a build exe:git-annex --ghc-options " -fdiagnostics-color=always"
+       Process exited with code: ExitFailure 1
+
+# End of transcript.
+"""]]
+
+The change I made was the following:
+
+[[!format diff """
+diff --git a/Remote/Git.hs b/Remote/Git.hs
+index c65d1388d..0e5fbe8df 100644
+--- a/Remote/Git.hs
++++ b/Remote/Git.hs
+@@ -65,9 +65,7 @@ import Types.ProposedAccepted
+ import Annex.Action
+ import Messages.Progress
+
+-#ifndef mingw32_HOST_OS
+ import qualified Utility.RawFilePath as R
+-#endif
+
+ import Control.Concurrent
+ import qualified Data.Map as M
+diff --git a/Utility/DirWatcher/Win32Notify.hs b/Utility/DirWatcher/Win32Notify.hs
+index 7eba40de9..acc6bd3af 100644
+--- a/Utility/DirWatcher/Win32Notify.hs
++++ b/Utility/DirWatcher/Win32Notify.hs
+@@ -11,7 +11,7 @@ import Common hiding (isDirectory)
+ import Utility.DirWatcher.Types
+
+ import System.Win32.Notify
+-import qualified System.PosixCompat.Files (isRegularFile)
++import System.PosixCompat.Files (isRegularFile, getFileStatus)
+
+ watchDir :: FilePath -> (FilePath -> Bool) -> Bool -> WatchHooks -> IO WatchManager
+ watchDir dir ignored scanevents hooks = do
+ """]]
+
+This then compiled cleanly and completed the test suite ok.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Git Annex is great. I use it several times a week with my multigigabyte backups, where it gives structure to my image-based backup routines, so you could say I'm a believer. :)
+
+[[!meta author=jkniiv]]
+[[!meta title="windows: build fails starting from commits 54ad1b4cf, 398633c12"]]
+
+> Kind of expected there would be something! The patch is almost right,
+> but we're avoiding using System.PosixCompat.Files.getFileStatus 
+> since it doesn't support long paths, so have to use
+> Utility.RawFilePath.getFileStatus instead. \[\[done\]\] --[[Joey]]
+
+>> Sorry, I had to reopen the bug as Joey's commit didn't quite compile. See page comments for details. --[[jkniiv]]
+
+>>> Should be fully fixed now. [[done]] --[[Joey]]
diff --git a/doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf/comment_1_c353c67f06f40c84b956990160205e0a._comment b/doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf/comment_1_c353c67f06f40c84b956990160205e0a._comment
new file mode 100644
index 0000000000..34fcf6b8a5
--- /dev/null
+++ b/doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf/comment_1_c353c67f06f40c84b956990160205e0a._comment
@@ -0,0 +1,84 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="ok, that didn't quite resolve it"
+ date="2023-03-04T19:15:31Z"
+ content="""
+@Joey, unfortunately commit [[!commit 398633c12bfb6201ba1fcd9b50e5e8055bfff89e]] wasn't quite enough to
+resolve my issue. :) First of all I wondered why you would employ `fromRawFilePath` instead of `toRawFilePath`
+considering that the argument of `getstatus` seems to be a FilePath, and indeed Utility.DirWatcher.Win32Notify
+didn't compile without replacing the former with the latter. Also you didn't notice that I had changed a qualified
+import into a regular one because otherwise `isRegularFile` wouldn't be available.
+
+Here's the tail end of my build log trying to build commit 398633c12:
+
+[[!format sh \"\"\"
+jkniiv@AINESIS MINGW64 /c/annx
+$ tail -n 35 stack.build.LOG~102
+[150 of 676] Compiling Utility.DirWatcher.Win32Notify
+
+Utility\DirWatcher\Win32Notify.hs:55:51: error:
+    * Variable not in scope: isRegularFile :: FileStatus -> Bool
+    * Perhaps you meant `System.PosixCompat.Files.isRegularFile' (imported from System.PosixCompat.Files)
+   |
+55 |                                                 | isRegularFile s ->
+
+   |                                                   ^^^^^^^^^^^^^
+
+Utility\DirWatcher\Win32Notify.hs:63:54: error:
+    * Couldn't match type `[Char]'
+                     with `Data.ByteString.Internal.ByteString'
+      Expected type: RawFilePath -> RawFilePath
+        Actual type: RawFilePath -> FilePath
+    * In the second argument of `(.)', namely `fromRawFilePath'
+      In the second argument of `(.)', namely
+        `R.getFileStatus . fromRawFilePath'
+      In the expression: catchMaybeIO . R.getFileStatus . fromRawFilePath
+   |
+63 |         getstatus = catchMaybeIO . R.getFileStatus . fromRawFilePath
+
+   |                                                      ^^^^^^^^^^^^^^^
+
+
+Error: [S-7282]
+       Stack failed to execute the build plan.
+
+       While executing the build plan, Stack encountered the following errors:
+
+       [S-7011]
+       While building package git-annex-10.20230227 (scroll up to its section to see the error)
+       using:
+       C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-230304-398633c12\.stack-work\dist\274b403a\setup\setup --verbose=1 --builddir=.stack-work\dist\274b403a build exe:git-annex --ghc-options \" -fdiagnostics-color=always\"
+       Process exited with code: ExitFailure 1
+
+\"\"\"]]
+
+So, I ended up with the following simple fix (although this situation left me wondering if `watchDir` ought to
+be rewritten to deal with RawFilePaths directly but then that's beyond my abilities):
+
+[[!format diff \"\"\"
+diff --git a/Utility/DirWatcher/Win32Notify.hs b/Utility/DirWatcher/Win32Notify.hs
+index a6a7e4ce9..0b02053c9 100644
+--- a/Utility/DirWatcher/Win32Notify.hs
++++ b/Utility/DirWatcher/Win32Notify.hs
+@@ -12,7 +12,7 @@ import Utility.DirWatcher.Types
+ import qualified Utility.RawFilePath as R
+
+ import System.Win32.Notify
+-import qualified System.PosixCompat.Files (isRegularFile)
++import System.PosixCompat.Files (isRegularFile)
+
+ watchDir :: FilePath -> (FilePath -> Bool) -> Bool -> WatchHooks -> IO WatchManager
+ watchDir dir ignored scanevents hooks = do
+@@ -60,7 +60,7 @@ watchDir dir ignored scanevents hooks = do
+                  where
+                        runhook h s = maybe noop (\a -> a f s) (h hooks)
+
+-       getstatus = catchMaybeIO . R.getFileStatus . fromRawFilePath
++       getstatus = catchMaybeIO . R.getFileStatus . toRawFilePath
+
+ {- Check each component of the path to see if it's ignored. -}
+ ignoredPath :: (FilePath -> Bool) -> FilePath -> Bool
+\"\"\"]]
+
+"""]]
diff --git a/doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf/comment_2_bd9a77da095bffdcd3ed30e08192b9d2._comment b/doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf/comment_2_bd9a77da095bffdcd3ed30e08192b9d2._comment
new file mode 100644
index 0000000000..1def6c13e9
--- /dev/null
+++ b/doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf/comment_2_bd9a77da095bffdcd3ed30e08192b9d2._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 2"
+ date="2023-03-05T20:18:01Z"
+ content="""
+On a positive note I can confirm that my compiled versions of commits 54ad1b4cf and 398633c12
+pass their test suite even in a subdirectory some 64 characters deep (for instance in a directory
+named like `c:/Users/jkniiv/annx/annx.10.20230228-g505f1a654--test-test-test`) whereas the commit
+just prior to \"Windows: Support long filenames in more (possibly all) of the code\" (54ad1b4cf), or
+505f1a654, fails some one third to one half of its tests in said directory. Shortening the test
+directory name to say `c:/Users/jkniiv/annx/annx` allows the test suite to pass in older versions
+of git-annex all other things considered equal. So far I have been running the built-in tests
+always in 'c:/annx' (/c/annx in Git Bash) but here on forward I'll probably start using a deeper
+path somewhere in my user folder / home directory just to catch possible future regressions in long
+path handling. In any case, @Joey, congratulations 🎉 are in order for your fine achievement from
+a Windows user point of view. :)
+
+"""]]
diff --git a/doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf/comment_3_c46e7c7f3870b54563eb8e94d451fded._comment b/doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf/comment_3_c46e7c7f3870b54563eb8e94d451fded._comment
new file mode 100644
index 0000000000..efc9c195c9
--- /dev/null
+++ b/doc/bugs/windows_build_fails_starting_from_commit_54ad1b4cf/comment_3_c46e7c7f3870b54563eb8e94d451fded._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-03-06T16:17:37Z"
+ content="""
+That's great news about the test suite in a deep directory. That was a
+longstanding problem indeed and a good indication it's fully supporting
+long filenames now.
+
+I often mix up fromRawFilePath/toRawFilePath. Luckily the compiler will
+notice. Should be fixed now.
+
+As for converting the whole `watchDir` to RawFilePath, there is probably
+not much benefit in doing that in such windows-specific code, but the goal
+is to do such a conversion in as much of git-annex as possible, since it is
+faster on unix to use RawFilePath end-to-end.
+
+Doing it is as simple as juggling the use of fromRawFilePath/toRawFilePath
+as the compiler allows, while converting code to use functions from
+Utility.RawFilePath or System.FilePath.ByteString or that otherwise
+use RawFilePath. I think you would be capable of that for sure!
+"""]]
diff --git a/doc/bugs/windows_ftbfs.mdwn b/doc/bugs/windows_ftbfs.mdwn
new file mode 100644
index 0000000000..77d3a8c926
--- /dev/null
+++ b/doc/bugs/windows_ftbfs.mdwn
@@ -0,0 +1,44 @@
+### Please describe the problem.
+
+Started to happen recently (0924):
+
+```shell
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2022/09[master]git
+$> git grep -l 'Couldn.t match expected type '
+cron-20220924/build-windows.yaml-788-e26581b6-failed/1_build-package (1).txt
+cron-20220924/build-windows.yaml-788-e26581b6-failed/build-package/18_Build git-annex.txt
+cron-20220925/build-windows.yaml-790-e26581b6-failed/1_build-package (1).txt
+cron-20220925/build-windows.yaml-790-e26581b6-failed/build-package/18_Build git-annex.txt
+cron-20220926/build-windows.yaml-791-40917e42-failed/1_build-package (1).txt
+cron-20220926/build-windows.yaml-791-40917e42-failed/build-package/18_Build git-annex.txt
+pr-133/build-windows.yaml-789-06e70ac7-failed/1_build-package (1).txt
+pr-133/build-windows.yaml-789-06e70ac7-failed/build-package/18_Build git-annex.txt
+```
+
+
+
+```
+Annex\PidLock.hs:130:48: error:
+    * Couldn't match expected type `IO a' with actual type `Annex a'
+    * In the second argument of `($)', namely `a r'
+      In the expression: liftIO $ a r
+      In an equation for runsGitAnnexChildProcessViaGit':
+          runsGitAnnexChildProcessViaGit' r a = liftIO $ a r
+    * Relevant bindings include
+        a :: Repo -> Annex a (bound at Annex\PidLock.hs:130:35)
+        runsGitAnnexChildProcessViaGit' :: Repo
+                                           -> (Repo -> Annex a) -> Annex a
+          (bound at Annex\PidLock.hs:130:1)
+    |
+130 | runsGitAnnexChildProcessViaGit' r a = liftIO $ a r
+
+    |                                                ^^^
+
+
+Warning: Failed to decode module interface:
+         D:\a\git-annex\git-annex\.stack-work\dist\274b403a\build\git-annex\git-annex-tmp\Annex.hi
+         Decoding failure: Invalid magic: e49ceb0f
+...
+```
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/windows_started_to_FTBFS.mdwn b/doc/bugs/windows_started_to_FTBFS.mdwn
new file mode 100644
index 0000000000..858d435e53
--- /dev/null
+++ b/doc/bugs/windows_started_to_FTBFS.mdwn
@@ -0,0 +1,35 @@
+### Please describe the problem.
+
+Spotted today
+
+```
+[695 of 696] Compiling CmdLine.GitAnnex
+runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20221216\mingw64\bin (Win32 error 3): The system cannot find the path specified.
+ghc.exe: addLibrarySearchPath: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20221216\mingw64\lib (Win32 error 3): The system cannot find the path specified.
+ghc.exe: addLibrarySearchPath: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20221216\mingw64\bin (Win32 error 3): The system cannot find the path specified.
+ghc.exe: addLibrarySearchPath: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20221216\mingw64\lib (Win32 error 3): The system cannot find the path specified.
+ghc.exe: addLibrarySearchPath: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20221216\mingw64\bin (Win32 error 3): The system cannot find the path specified.
+ghc.exe: addLibrarySearchPath: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20221216\mingw64\lib (Win32 error 3): The system cannot find the path specified.
+ghc.exe: addLibrarySearchPath: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20221216\mingw64\bin (Win32 error 3): The system cannot find the path specified.
+ghc.exe: addLibrarySearchPath: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20221216\mingw64\lib (Win32 error 3): The system cannot find the path specified.
+ghc.exe: addLibrarySearchPath: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20221216\mingw64\bin (Win32 error 3): The system cannot find the path specified.
+ghc.exe: addLibrarySearchPath: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20221216\mingw64\lib (Win32 error 3): The system cannot find the path specified.
+ghc.exe: addLibrarySearchPath: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\msys2-20221216\mingw64\bin (Win32 error 3): The system cannot find the path specified.
+
+Error: [S-7282]
+       Stack failed to execute the build plan.
+       
+       While executing the build plan, Stack encountered the error:
+       
+       [S-7011]
+       While building package git-annex-10.20231227 (scroll up to its section to see the error)
+       using:
+       D:\a\git-annex\git-annex\.stack-work\dist\274b403a\setup\setup --verbose=1 --builddir=.stack-work\dist\274b403a build exe:git-annex --ghc-options ""
+       Process exited with code: ExitFailure 1 
+Error: Process completed with exit code 1.
+```
+
+https://github.com/datalad/git-annex/actions/runs/7516705948/job/20462067511
+
+> Fixed the Test.hs problem, which if I understand correctly was the root
+> cause of all of this, so [[done]] --[[Joey]]
diff --git a/doc/bugs/windows_started_to_FTBFS/comment_1_094012512e6c267f05d3d61c0ed638a0._comment b/doc/bugs/windows_started_to_FTBFS/comment_1_094012512e6c267f05d3d61c0ed638a0._comment
new file mode 100644
index 0000000000..3b0ae2a717
--- /dev/null
+++ b/doc/bugs/windows_started_to_FTBFS/comment_1_094012512e6c267f05d3d61c0ed638a0._comment
@@ -0,0 +1,52 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="I can confirm"
+ date="2024-01-16T22:28:21Z"
+ content="""
+but the true point of error seems to be this (line 1167 in the log):
+
+```
+[605 of 696] Compiling Test
+D:\a\git-annex\git-annex\Test.hs:1850:1: error:
+[606 of 696] Compiling Assistant.Pairing
+    The type signature for `test_gpg_crypto'
+      lacks an accompanying binding
+[607 of 696] Compiling Assistant.Types.DaemonStatus
+      Perhaps you meant one of these:
+[608 of 696] Compiling Assistant.Monad
+        `test_sop_crypto' (Defined at Test.hs:1833:1),
+[609 of 696] Compiling Assistant.Types.NamedThread
+        `test_crypto' (Defined at Test.hs:1944:1)
+```
+
+In fact if you do a non-parallelbuild, stack bails out already @ Test.hs:
+
+```
+[603 of 696] Compiling CmdLine.GitAnnexShell
+[604 of 696] Compiling Utility.Verifiable
+[605 of 696] Compiling Test
+
+C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-240116-c15fa1763\Test.hs:1850:1: error:
+    The type signature for `test_gpg_crypto'
+      lacks an accompanying binding
+      Perhaps you meant one of these:
+        `test_sop_crypto' (Defined at Test.hs:1833:1),
+        `test_crypto' (Defined at Test.hs:1944:1)
+     |
+1850 | test_gpg_crypto :: Assertion
+     | ^^^^^^^^^^^^^^^
+
+Error: [S-7282]
+       Stack failed to execute the build plan.
+
+       While executing the build plan, Stack encountered the error:
+
+       [S-7011]
+       While building package git-annex-10.20231227 (scroll up to its section to see the error)
+       using:
+       C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-240116-c15fa1763\.stack-work\dist\ed8db9df\setup\setup --verbose=1 --builddir=.stack-work\dist\ed8db9df build exe:git-annex --ghc-options \"\"
+       Process exited with code: ExitFailure 1
+```
+
+"""]]
diff --git a/doc/bugs/windows_started_to_FTBFS/comment_2_1ad4a7da4dd4353838fd5c1f9610ee32._comment b/doc/bugs/windows_started_to_FTBFS/comment_2_1ad4a7da4dd4353838fd5c1f9610ee32._comment
new file mode 100644
index 0000000000..80c7140938
--- /dev/null
+++ b/doc/bugs/windows_started_to_FTBFS/comment_2_1ad4a7da4dd4353838fd5c1f9610ee32._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 2"
+ date="2024-01-16T23:23:27Z"
+ content="""
+The compilation error turned out to be a typo / small neglect. The following quick fix makes it go away
+(at least with build flag `--flag 'git-annex:-ParallelBuild'`):
+
+[[!format diff \"\"\"
+diff --git a/Test.hs b/Test.hs
+index c8db8147a4..b752d4dc22 100644
+--- a/Test.hs
++++ b/Test.hs
+@@ -1941,7 +1941,7 @@ test_gpg_crypto = do
+                        Annex.Locations.keyPaths .
+                        Crypto.encryptKey Types.Crypto.HmacSha1 cipher
+ #else
+-test_crypto = putStrLn \"gpg testing not implemented on Windows\"
++test_gpg_crypto = putStrLn \"gpg testing not implemented on Windows\"
+ #endif
+
+ test_add_subdirs :: Assertion
+\"\"\"]]
+
+"""]]
diff --git a/doc/bugs/wrong_modes_for_some_lock_files_withcoresharedrepository.mdwn b/doc/bugs/wrong_modes_for_some_lock_files_withcoresharedrepository.mdwn
new file mode 100644
index 0000000000..1067470b4c
--- /dev/null
+++ b/doc/bugs/wrong_modes_for_some_lock_files_withcoresharedrepository.mdwn
@@ -0,0 +1,24 @@
+With core.sharedRepository=0666, some lock files get created mode 644
+(with umask 0022).
+
+With core.sharedRepository=group, some lock files get created mode 660,
+rather than 664 (with umask 0022).
+
+Root of the problem is uses of annexFileMode. 
+
+Some callers use noUmask with it, which works in cases other than these (at
+least with umask 0022). But in the core.sharedRepository=group case, the
+umask is cleared by noUmask, which is why the o+r bit is not set.
+
+Some callers don't use noUmask with it, and when
+core.sharedRepository=0666, that results in the umask being applied
+to the mode. Which it's not supposed to with an octal mode configured.
+
+The affected files are all lock files.
+
+Fix will probably involve getting rid of annexFileMode, and noUmask, and
+creating the lock file with default umask, then fixing up the mode if necessary,
+before using it. Ie, the same pattern used everywhere else in git-annex.
+--[[Joey]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/builds.mdwn b/doc/builds.mdwn
new file mode 100644
index 0000000000..1f1df94037
--- /dev/null
+++ b/doc/builds.mdwn
@@ -0,0 +1,65 @@
+[[!meta title="git-annex autobuild overview"]]
+
+[[!sidebar content="""
+# last uploaded build-versions
+
+<h2>Linux i386</h2>
+<iframe width=1024 height=40em scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/i386/build-version">
+</iframe>
+<h2>Linux amd64</h2>
+<iframe width=1024 height=40em scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/amd64/build-version">
+</iframe>
+<h2>Linux armel</h2>
+<iframe width=1024 height=40em scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/armel/build-version">
+</iframe>
+<h2>Linux arm64</h2>
+<iframe width=1024 height=40em scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/arm64/build-version">
+</iframe>
+<h2>Linux i386-ancient</h2>
+<iframe width=1024 height=40em scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/i386-ancient/build-version">
+</iframe>
+<h2>Linux arm64-ancient</h2>
+<iframe width=1024 height=40em scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/arm64-ancient/build-version">
+</iframe>
+<h2>OSX</h2>
+<iframe width=1024 height=40em scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/x86_64-apple-catalina/build-version">
+</iframe>
+<h2>Windows</h2>
+<iframe width=1024 height=40em scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/windows/build-version">
+</iframe>
+"""]]
+
+# build logs
+
+<h2>Linux i386</h2>
+<iframe width=1024 scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/i386/">
+</iframe>
+<h2>Linux amd64</h2>
+<iframe width=1024 scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/amd64/">
+</iframe>
+<h2>Linux armel</h2>
+<iframe width=1024 scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/armel/">
+</iframe>
+<h2>Linux arm64</h2>
+<iframe width=1024 scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/arm64/">
+</iframe>
+<h2>Linux i386-ancient</h2>
+<iframe width=1024 scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/i386-ancient/">
+</iframe>
+<h2>Linux arm64-ancient</h2>
+<iframe width=1024 scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/arm64-ancient/">
+</iframe>
+<h2>OSX</h2>
+<a href="https://github.com/datalad/git-annex/actions?query=workflow%3A%22Build+git-annex+on+macOS%22">
+<img src="https://github.com/datalad/git-annex/workflows/Build%20git-annex%20on%20macOS/badge.svg">
+</a>
+<h2>Windows</h2>
+<a href="https://github.com/datalad/git-annex/actions?query=workflow%3A%22Build+git-annex+on+Windows%22">
+<img src="https://github.com/datalad/git-annex/workflows/Build%20git-annex%20on%20Windows/badge.svg">
+</a>
+<h2>Debian standalone packages</h2>
+<a href="https://github.com/datalad/git-annex/actions?query=workflow%3A%22Build+git-annex+on+Ubuntu%22">
+<img src="https://github.com/datalad/git-annex/workflows/Build%20git-annex%20on%20Ubuntu/badge.svg">
+</a>
+<h2>Appveyor</h2>
+<a href="https://ci.appveyor.com/project/mih/git-annex">here</a>
diff --git a/doc/chunking.mdwn b/doc/chunking.mdwn
new file mode 100644
index 0000000000..43e604f232
--- /dev/null
+++ b/doc/chunking.mdwn
@@ -0,0 +1,43 @@
+Most [[special_remotes]] have support for breaking large files up into
+chunks that are stored on the remote.
+
+This can be useful to work around limitations on the size of files
+on the remote.
+
+Chunking also allows for resuming interrupted downloads and uploads.
+
+Note that git-annex has to buffer chunks in memory before they are sent to
+a remote. So, using a large chunk size will make it use more memory.
+
+To enable chunking, pass a `chunk=nnMiB` parameter to `git annex
+initremote`, specifying the chunk size. 
+
+Good chunk sizes will depend on the remote, but a good starting place
+is probably `1MiB`. Very large chunks are problematic, both because
+git-annex needs to buffer one chunk in memory when uploading, and because
+a larger chunk will make resuming interrupted transfers less efficient.
+On the other hand, when a file is split into a great many chunks,
+there can be increased overhead of making many requests to the remote.
+
+To disable chunking of a remote that was using chunking,
+pass `chunk=0` to `git annex enableremote`. Any content already stored on
+the remote using chunks will continue to be accessed via chunks, this
+just prevents using chunks when storing new content.
+
+To change the chunk size, pass a `chunk=nnMiB` parameter to
+`git annex enableremote`. This only affects the chunk sized used when
+storing new content.
+
+# old-style chunking
+
+Note that older versions of git-annex used a different chunk method, which
+was configured by passing `chunksize=nnMib` when initializing a remote.
+
+The old-style chunking had a number of problems, including being less
+efficient, and not allowing resumes of encrypted uploads.
+
+It's not possible to change a remote using that old chunking method to the
+new one, but git-annex continues to support the old-style chunking to
+support such remotes.
+
+See also: [[design document|design/assistant/chunks]]
diff --git a/doc/chunking/comment_1_ddbc7a66de2def23cbf1e1de7defde08._comment b/doc/chunking/comment_1_ddbc7a66de2def23cbf1e1de7defde08._comment
new file mode 100644
index 0000000000..e04a830769
--- /dev/null
+++ b/doc/chunking/comment_1_ddbc7a66de2def23cbf1e1de7defde08._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="buffering chunks in memory when uploading to remote"
+ date="2019-09-04T19:50:42Z"
+ content="""
+\"git-annex has to buffer chunks in memory before they are sent to a remote\" -- would it be hard to remove this restriction?  I want to have a non-chunked S3 remote, so that files in it can be accessed through a URL.  But if some files are 50GB, then git-annex running on a 16GB machine would fail when talking to this repo?
+"""]]
diff --git a/doc/chunking/comment_2_d43c297db9a31d1c896b48f0e3757229._comment b/doc/chunking/comment_2_d43c297db9a31d1c896b48f0e3757229._comment
new file mode 100644
index 0000000000..1ee6a5d84a
--- /dev/null
+++ b/doc/chunking/comment_2_d43c297db9a31d1c896b48f0e3757229._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="mike@2d6d71f56ce2a992244350475251df87c26fe351"
+ nickname="mike"
+ avatar="http://cdn.libravatar.org/avatar/183fa439752e2f0c6f39ede658d81050"
+ subject="comment 2"
+ date="2023-02-05T22:41:27Z"
+ content="""
+Is there a way to show the chunking parameters used for a remote? In particular I would like to know if I had used the old-style chunking for a remote.
+"""]]
diff --git a/doc/chunking/comment_3_7305da05dff79b9cabc59af162db9925._comment b/doc/chunking/comment_3_7305da05dff79b9cabc59af162db9925._comment
new file mode 100644
index 0000000000..8cd86a449e
--- /dev/null
+++ b/doc/chunking/comment_3_7305da05dff79b9cabc59af162db9925._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="MatusGoljer1"
+ avatar="http://cdn.libravatar.org/avatar/8152eed1d594c570563ed46e7fd8356f"
+ subject="comment 3"
+ date="2023-02-06T19:30:02Z"
+ content="""
+I always use this
+
+    git show git-annex:remote.log
+
+to print the current configurations of all remotes.   It should have all the arguments you passed to `initremote` or `enableremote`.  If there is a better way, I would also like to know.
+
+(the git command prints the content of the file `remote.log` from branch `git-annex`)
+"""]]
diff --git a/doc/chunking/comment_4_f098bf5a5d07b10d5be41658790547ad._comment b/doc/chunking/comment_4_f098bf5a5d07b10d5be41658790547ad._comment
new file mode 100644
index 0000000000..49347a6022
--- /dev/null
+++ b/doc/chunking/comment_4_f098bf5a5d07b10d5be41658790547ad._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-02-27T16:01:49Z"
+ content="""
+@mike, you can use `git-annex info $remotename`
+
+The output will include a "chunking" line which ends
+in "(old style)" when applicable.
+"""]]
diff --git a/doc/coding_style.mdwn b/doc/coding_style.mdwn
new file mode 100644
index 0000000000..425665e377
--- /dev/null
+++ b/doc/coding_style.mdwn
@@ -0,0 +1,113 @@
+If you do nothing else, avoid use of partial functions from the Prelude!
+`import Utility.PartialPrelude` helps avoid this by defining conflicting
+functions for all the common ones. Also avoid `!!`, it's partial too.
+
+Use tabs for indentation. The one exception to this rule are
+the Hamlet format files in `templates/*`. Hamlet, infuriatingly, refuses
+to allow tabs to be used for indentation.
+
+Code should make sense with any tab stop setting, but 8 space tabs are
+the default. With 8 space tabs, code should not exceed 80 characters
+per line. (With larger tabs, it may of course.)
+
+Use spaces for layout. For example, here spaces (indicated with `.`)
+are used after the initial tab to make the third test line up with
+the others.
+
+		when (foo_test || bar_test ||
+		......some_other_long_test)
+			print "hi"
+
+As a special Haskell-specific rule, "where" clauses are indented with two
+spaces, rather than a tab. This makes them stand out from the main body
+of the function, and avoids excessive indentation of the where cause content.
+The definitions within the where clause should be put on separate lines,
+each indented with a tab.
+
+	main = do
+		foo
+		bar
+		foo
+	  where
+		foo = ...
+		bar = ...
+
+Where clauses for instance definitions and modules tend to appear at the end
+of a line, rather than on a separate line.
+
+	module Foo (Foo, mkFoo, unFoo) where
+	instance MonadBaseControl IO Annex where
+
+When a function's type signature needs to be wrapped to another line,
+it's typical to switch to displaying one parameter per line.
+
+	foo :: Bar -> Baz -> (Bar -> Baz) -> IO Baz
+
+	foo'
+		:: Bar
+		-> Baz
+		-> (Bar -> Baz)
+		-> IO Baz
+ 
+Note that the "::" then starts its own line. It is not put on the same
+line as the function name because then it would not be guaranteed to line
+up with the "->" at all tab width settings. Similarly, guards are put
+on their own lines:
+
+	splat i
+		| odd i = error "splat!"
+		| otherwise = i
+
+Multiline lists and record syntax are written with leading commas,
+that line up with the open and close punctuation.
+
+	list =
+		[ item1
+		, item2
+		, item3
+		]
+
+	foo = DataStructure
+		{ name = "bar"
+		, address = "baz"
+		}
+
+Similarly, data structures line up the leading `=` with the following `|`
+
+	data Foo
+		= Bar
+		| Baz
+		| Quux Foo
+		deriving (Eq, Ord)
+
+Module imports are separated into two blocks, one for third-party modules,
+and one for modules that are part of git-annex. (Additional blocks can be used
+if it makes sense.)
+
+Using tabs for indentation makes use of `let .. in` particularly tricky.
+There's no really good way to bind multiple names in a let clause with
+tab indentation. Instead, a where clause is typically used. To bind a single
+name in a let clause, this is sometimes used:
+
+	foo = let x = 42
+		in x + (x-1) + x
+
+-----
+
+If you feel that this coding style leads to excessive amounts of horizontal
+or vertical whitespace around your code, making it hard to fit enough of it
+on the screen, consider finding a better abstraction, so the code that
+does fit on the screen is easily understandable. ;)
+
+-----
+
+Note for emacs users: You can put the following snippet into a file called 
+`.dir-locals.el` at root of git-annex's source tree to use tabs for indentation:
+
+	((nil . ((indent-tabs-mode . t)
+	         (tab-width . 8)
+	         (fill-column . 80)))
+	 ;; Warn about spaces used for indentation:
+	 (haskell-mode . ((eval . (highlight-regexp "^ *")))))
+
+Also consider [haskell-tab-indent-mode](https://spwhitton.name/tech/code/haskell-tab-indent/).  The standard indentation modes that come with haskell-mode do not work well with tabs for indentation.  This mode works well for hacking on git-annex.
diff --git a/doc/coding_style/comment_1_70521cf79ad06832b1d73fc2c20c68ec._comment b/doc/coding_style/comment_1_70521cf79ad06832b1d73fc2c20c68ec._comment
new file mode 100644
index 0000000000..a8200f856c
--- /dev/null
+++ b/doc/coding_style/comment_1_70521cf79ad06832b1d73fc2c20c68ec._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnq-RfkVpFN15SWvQ2lpSGAi0XpNQuLxKM"
+ nickname="Yuval"
+ subject="What about safe?"
+ date="2014-07-06T10:45:59Z"
+ content="""
+https://hackage.haskell.org/package/safe
+
+> A library wrapping Prelude/Data.List functions that can throw exceptions, such as head and !!. Each unsafe function has up to four variants, e.g. with tail:
+> 
+>     tail :: [a] -> [a], raises an error on tail [].
+
+>     tailMay :: [a] -> Maybe [a], turns errors into Nothing.
+
+>     tailDef :: [a] -> [a] -> [a], takes a default to return on errors.
+
+>     tailNote :: String -> [a] -> [a], takes an extra argument which supplements the error message.
+
+>     tailSafe :: [a] -> [a], returns some sensible default if possible, [] in the case of tail.
+"""]]
diff --git a/doc/coding_style/comment_2_a820b7c8ae7c2290eb000f61bdb5c514._comment b/doc/coding_style/comment_2_a820b7c8ae7c2290eb000f61bdb5c514._comment
new file mode 100644
index 0000000000..9f9d961962
--- /dev/null
+++ b/doc/coding_style/comment_2_a820b7c8ae7c2290eb000f61bdb5c514._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 2"
+ date="2014-07-10T20:24:03Z"
+ content="""
+safe does not prevent using the unsafe prelude functions. Utility.PartialPrelude does, and provides a few safe wrappers like lastMaybe. 
+"""]]
diff --git a/doc/coding_style/comment_3_61c178b997dd044f3531303913f8fa91._comment b/doc/coding_style/comment_3_61c178b997dd044f3531303913f8fa91._comment
new file mode 100644
index 0000000000..c0a5661587
--- /dev/null
+++ b/doc/coding_style/comment_3_61c178b997dd044f3531303913f8fa91._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Don"
+ subject="Style for man pages?"
+ date="2015-09-28T10:00:45Z"
+ content="""
+Could you add some suggestions for editing the .mdwn files?  I'd like to help clean up a few (really minor) things I noticed, but I don't want to make more work for you with the changes I make.  One thing I'm not sure about is where to set my fill column when editing--I can't seem to pick any single value (79? 80?) that doesn't make some paragraphs change when I rewrap them.  Also, it might be helpful to have a quick guide for when you surround commands and other computer-y words with quotes, backticks, or nothing at all.
+   
+"""]]
diff --git a/doc/coding_style/comment_4_433b7ba5e51e746f6b033ebb5c0e50a2._comment b/doc/coding_style/comment_4_433b7ba5e51e746f6b033ebb5c0e50a2._comment
new file mode 100644
index 0000000000..118a20caf2
--- /dev/null
+++ b/doc/coding_style/comment_4_433b7ba5e51e746f6b033ebb5c0e50a2._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""man page style"""
+ date="2015-09-29T15:20:10Z"
+ content="""
+Well, I don't always word-wrap paras when re-editing them, and several
+people have had their hands on the man page and may have different wrapping
+settings. 
+
+My suggestion would be, if you need to re-wrap, or generally make
+whitespace changes, do it in a separate commit from other changes. 
+Similarly, make spelling corrections in a separate commit from any
+substance changes.
+
+Note that you can push man page commits directly to this site via git://
+protocol, so it's not going to use my time as long as there's a reasonable
+commit message.
+
+Use backticks around any command name or fragment of a command line. 
+Use quotes around program output, or other values that are not command
+names or switch names.
+"""]]
diff --git a/doc/comments.mdwn b/doc/comments.mdwn
new file mode 100644
index 0000000000..e19962b92a
--- /dev/null
+++ b/doc/comments.mdwn
@@ -0,0 +1,9 @@
+[[!sidebar content="""
+[[!inline pages="comment_pending(*)" feedfile=pendingmoderation
+description="comments pending moderation" show=-1]]
+Comments in the [[!commentmoderation desc="moderation queue"]]:
+[[!pagecount pages="comment_pending(*)"]]
+"""]]
+
+Recent comments posted to this site:
+[[!inline pages="comment(*)" template="comment"]]
diff --git a/doc/contact.mdwn b/doc/contact.mdwn
new file mode 100644
index 0000000000..db9914d50f
--- /dev/null
+++ b/doc/contact.mdwn
@@ -0,0 +1,11 @@
+Joey Hess <id@joeyh.name> is the author of git-annex. If you need to
+talk about something privately, email me.
+
+The [[forum]] is the best place to discuss git-annex.
+
+For realtime chat, use the `#git-annex` channel on irc.oftc.net.
+You can also watch incoming commits there.
+
+The [VCS-home mailing list](http://lists.madduck.net/listinfo/vcs-home)
+is a good mailing list for users who want to use git-annex in the context
+of managing their large personal files.
diff --git a/doc/contribute.mdwn b/doc/contribute.mdwn
new file mode 100644
index 0000000000..54bf3b8f1c
--- /dev/null
+++ b/doc/contribute.mdwn
@@ -0,0 +1,77 @@
+Help make git-annex better!
+
+## user support
+
+Hang out in git-annex support areas and answer users' questions.
+Don't be afraid to get an answer not 100% right, but avoid wild guesses.
+If you understand the basics of how git-annex works and know how to use it,
+you are ahead of many users, and can help them out tremendously.
+
+## wiki gardening
+
+This website is a wiki, so you can edit and improve any page.
+
+Or, write a [[new_tip|tips]] explaining how to accomplish something with
+git-annex.
+
+## advanced wiki editing
+
+To make larger changes to the website, you can 
+`git clone git://git-annex.branchable.com/ git-annex` and will find the
+whole website source in `doc/`.
+
+You can even `git push` doc-only changes back without authentication,
+since it is a wiki!
+
+## bug triage
+
+People often file [[bugs]] on git-annex that are easily resolved by helping
+them with a problem, and perhaps writing some documentation.
+
+Many bugs are also filed without enough information
+to reproduce the problem, and need to be tagged moreinfo and a comment
+posted asking the submitter for details.
+
+Once a bug is confirmed to be reproducible, it becomes a lot easier to fix.
+So it's very helpful to highlight such bugs.
+
+Joey spends a lot of time dealing with this kind of bug triage. If you can
+take the time to pick a bug that is not tagged as "confirmed" or "moreinfo"
+from the list of [[bugs]], try to reproduce it and follow up either
+confirming that the problem exists, or asking the submitter for more info,
+you'll make Joey more productive!
+
+You can add and modify tags by editing the bug's page with this wiki code:
+
+	\[[!taglink confirmed]]
+	\[[!taglink moreinfo]]
+
+## code contributions
+
+[[download]] the source code, [[build|install/fromsource]] it
+and send patches!
+
+If you know Haskell, git-annex has lots of Haskell code that
+could be improved. See the [[coding_style]] and have at it.
+
+If you don't know Haskell, git-annex has many other coding opportunities.
+You could work to improve the Javascript and CSS of the git-annex webapp,
+or work on porting libraries needed by the Windows port.
+
+To send patches, either include the patch in a [[bug|bugs]] report (small
+patch) or put up a branch in a git repository containing your changes.
+
+[Policy on AI generated content](https://joeyh.name/blog/entry/policy_on_adding_AI_generated_content_to_my_software_projects/)
+(Summary: It's welcome! But see the page for important details.)
+
+## learning some Haskell
+
+Want to learn some Haskell to get hacking on git-annex?
+
+As Haskell programs go, git-annex does not use too many advanced features.
+[Learn You A Haskell](http://learnyouahaskell.com/) will teach you enough
+to get started.
+
+Of course git-annex does use monads, and particularly the `Annex` monad
+which gives access to its state about the git repository as well as
+lower-level IO.
diff --git a/doc/contribute/comment_10_0b07e1baa5e89ba24f66c077719985e9._comment b/doc/contribute/comment_10_0b07e1baa5e89ba24f66c077719985e9._comment
new file mode 100644
index 0000000000..8ad9c06bc1
--- /dev/null
+++ b/doc/contribute/comment_10_0b07e1baa5e89ba24f66c077719985e9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-03-29T17:38:41Z"
+ content="""
+I have, at least temporarily, fixed the ACL breakage that was causing this
+anonymous push problem. I say temporarily because apparently a chmod messed
+up the existing ACLs and so it seems ACLs are pretty fragile.
+"""]]
diff --git a/doc/contribute/comment_1_c61530e14bdbd7c5ec8b0137c0da92f8._comment b/doc/contribute/comment_1_c61530e14bdbd7c5ec8b0137c0da92f8._comment
new file mode 100644
index 0000000000..0b43b3f0ae
--- /dev/null
+++ b/doc/contribute/comment_1_c61530e14bdbd7c5ec8b0137c0da92f8._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="ggreif@8132a868199b4ffec14150c87f538dc06a538220"
+ nickname="ggreif"
+ subject="GHC HEAD warnings"
+ date="2016-05-27T14:21:11Z"
+ content="""
+I have a patch:
+
+https://github.com/ggreif/git-annex/tree/patch-1
+
+It heals e.g.
+
+    Assistant/WebApp/Form.hs:52:1: warning: [-Wredundant-constraints]
+        ? Redundant constraint: Monad m
+        ? In the type signature for:
+               withNote :: (Monad m, ToWidget (HandlerSite m) a) =>
+                           Field m v -> a -> Field m v
+
+"""]]
diff --git a/doc/contribute/comment_2_637b05cfd48d2e337c3192989356d183._comment b/doc/contribute/comment_2_637b05cfd48d2e337c3192989356d183._comment
new file mode 100644
index 0000000000..c57755a687
--- /dev/null
+++ b/doc/contribute/comment_2_637b05cfd48d2e337c3192989356d183._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-27T15:45:49Z"
+ content="""
+Please open [[todo]] items for patches, don't send them as comments here.
+
+(I suspect that the patch as provided might break compilation with old
+versions of ghc, or old versions of yesod..)
+"""]]
diff --git a/doc/contribute/comment_3_e7219514f52207fcfb97aeec03241e8d._comment b/doc/contribute/comment_3_e7219514f52207fcfb97aeec03241e8d._comment
new file mode 100644
index 0000000000..4e1087a768
--- /dev/null
+++ b/doc/contribute/comment_3_e7219514f52207fcfb97aeec03241e8d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="Editing Comments?"
+ date="2020-02-14T01:22:46Z"
+ content="""
+Is it possible to edit comments on the branchable wiki? I realized there was a sentence I failed to finish when posting [this comment](https://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/#comment-19feab1afb2e0b33315a8368a7cdebf7) and I'd love to go back and finish the thought. The \"Edit\" button at the top of the page lets me edit the content of the page, but not any of the comments.
+
+I tried cloning the wiki, editing the file corresponding to my comment, and then pushing, but the push was rejected (the changes were in doc tree so I expected it to be accepted, but perhaps comments are more locked down).
+
+Update: It seems I am able to edit comments by cloning the wiki, editing (comments are located in a folder with the same name as the associated page), committing, and then pushing. Yay!
+"""]]
diff --git a/doc/contribute/comment_4_21a75c774757f27911a9249f9b42368d._comment b/doc/contribute/comment_4_21a75c774757f27911a9249f9b42368d._comment
new file mode 100644
index 0000000000..fe091d91db
--- /dev/null
+++ b/doc/contribute/comment_4_21a75c774757f27911a9249f9b42368d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""@Dan"""
+ date="2020-02-17T17:05:03Z"
+ content="""
+That might be an ikiwiki issue, because you're supposed to be able to git
+push any change that a user could make on the web, and I think anyone can
+delete a comment and then make a new comment in its place. Probably
+two pushes would work ... or just copy and then delete the comment and paste
+into a new comment.
+"""]]
diff --git a/doc/contribute/comment_5_c5f7f809da5829f4c259d0a630f0f722._comment b/doc/contribute/comment_5_c5f7f809da5829f4c259d0a630f0f722._comment
new file mode 100644
index 0000000000..72378f3e7c
--- /dev/null
+++ b/doc/contribute/comment_5_c5f7f809da5829f4c259d0a630f0f722._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="Thanks"
+ date="2020-02-17T17:52:20Z"
+ content="""
+Got it! In this case, since the [conversation](https://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/#comment-a232b074bb04a942903468cf0d7a13b1) has now moved on, I'll just complete my thought in reply to your most recent comment, but I'll use the workflow you suggested in the future if I need to edit a comment.
+"""]]
diff --git a/doc/contribute/comment_6_7b53ed13f455879a7462d74571283063._comment b/doc/contribute/comment_6_7b53ed13f455879a7462d74571283063._comment
new file mode 100644
index 0000000000..b3f9aa9780
--- /dev/null
+++ b/doc/contribute/comment_6_7b53ed13f455879a7462d74571283063._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="mzimann"
+ avatar="http://cdn.libravatar.org/avatar/7fd54a1212458d60d3963c7fbb7ce294"
+ subject="push doc-only changes"
+ date="2020-06-18T15:54:49Z"
+ content="""
+First of all I just want to say that I'm really impressed by git-annex. I was
+looking for such a tool for a long time and I'm really happy that I finally
+found it. It really does the trick for me to handle all my data.
+
+My problem is now that I wanted to push some changes to doc/, this page says
+that it shouldn't be a problem even without authentication. But I get following
+error:
+
+```
+Enumerating objects: 7, done.
+Counting objects: 100% (7/7), done.
+Delta compression using up to 8 threads
+Compressing objects: 100% (4/4), done.
+Writing objects: 100% (4/4), 460 bytes | 460.00 KiB/s, done.
+Total 4 (delta 3), reused 0 (delta 0), pack-reused 0
+remote: error: cannot lock ref 'HEAD': Unable to create '/home/b-git-annex/source.git/./HEAD.lock': Permission denied
+To git://git-annex.branchable.com/
+ ! [remote rejected]     master -> master (failed to update ref)
+error: failed to push some refs to 'git://git-annex.branchable.com/'
+```
+
+Seems to me that I'm not permitted, or am I doing something wrong? Or is the
+information on this page not up-to-date anymore?
+"""]]
diff --git a/doc/contribute/comment_7_a721a4abf10ae3a1e591f81b9069387f._comment b/doc/contribute/comment_7_a721a4abf10ae3a1e591f81b9069387f._comment
new file mode 100644
index 0000000000..cbed134976
--- /dev/null
+++ b/doc/contribute/comment_7_a721a4abf10ae3a1e591f81b9069387f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: push doc-only changes"""
+ date="2020-06-30T15:02:20Z"
+ content="""
+Turns out that anonymous git push had been broken for some time.
+
+I've fixed the permissions problem, but I'm not entirely sure what caused
+it in the first place, so not positive my fix will last.
+"""]]
diff --git a/doc/contribute/comment_8_1b6c02d7ca6a36e4b1ce2bc52570c7fb._comment b/doc/contribute/comment_8_1b6c02d7ca6a36e4b1ce2bc52570c7fb._comment
new file mode 100644
index 0000000000..217f0bf925
--- /dev/null
+++ b/doc/contribute/comment_8_1b6c02d7ca6a36e4b1ce2bc52570c7fb._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="Re: push doc-only changes"
+ date="2021-03-22T18:58:31Z"
+ content="""
+> I've fixed the permissions problem, but I'm not entirely sure what caused
+> it in the first place, so not positive my fix will last.
+
+I tried to push a doc/ change today and saw the same error, so it
+looks like the issue has resurfaced.
+
+"""]]
diff --git a/doc/contribute/comment_9_62f827dd014481f41d77f4afec0b1de2._comment b/doc/contribute/comment_9_62f827dd014481f41d77f4afec0b1de2._comment
new file mode 100644
index 0000000000..80fa7732bc
--- /dev/null
+++ b/doc/contribute/comment_9_62f827dd014481f41d77f4afec0b1de2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-03-22T19:11:46Z"
+ content="""
+Kyle, this is being discussed at <http://ikiwiki.info/bugs/anonymous_git_push_broken_again/>
+but unfortunately I don't think it's the same problem and am becoming
+doubtful I can keep whack-a-moleing this particular problem source.
+"""]]
diff --git a/doc/copies.mdwn b/doc/copies.mdwn
new file mode 100644
index 0000000000..f79e94d009
--- /dev/null
+++ b/doc/copies.mdwn
@@ -0,0 +1,48 @@
+Annexed data is stored inside  your git repository's `.git/annex` directory.
+Some [[special_remotes]] can store annexed data elsewhere.
+
+It's important that data not get lost by an ill-considered `git-annex drop`
+command.  So, git-annex can be configured to try to keep a number of copies
+of a file's content available across all repositories. 
+
+By default, it keeps 1 copy; this is configured by running `git-annex
+numcopies N`, or can be overridden on a per-file-type basis by the
+annex.numcopies setting in `.gitattributes` files. The --numcopies switch
+allows temporarily using a different value.
+
+When dropping content, git-annex checks with remotes to make sure If enough
+other repositories cannot be verified to have copies, it will refuse to
+drop it, avoid data loss.
+
+In unusual situations, involving special remotes that do not support
+locking, and concurrent drops of the same content from multiple
+repositories, git-annex may violate the numcopies setting. It still
+guarantees at least 1 copy is preserved. This can be configured by
+running `git-annex mincopies N` or can be overridden on a per-file-type
+basis by the annex.mincopies setting in `.gitattributes` files. 
+The --mincopies switch allows temporarily using a different value.
+
+Note that [trusted repositories|trust]] are assumed to
+continue to contain content, so checking them is skipped. So dropping
+content from trusted repositories does risk numcopies and mincopies 
+later being violated.
+
+To express more detailed requirements about which repositories contain which
+content, see [[required_content]].
+
+## example
+
+For example, consider three repositories: Server, Laptop, and USB. Both
+Server and USB have a copy of a file, and numcopies is 1. If on Laptop, you
+`git-annex get $file`, this will transfer it from either Server or USB
+(depending on which is available), and there are now 3 copies of the file.
+
+Suppose you want to free up space on Laptop again, and you `git-annex drop`
+the file there. If USB is connected, or Server can be contacted, git-annex
+can check that it still has a copy of the file, and the content is removed
+from Laptop. But if USB is currently disconnected, and Server also cannot
+be contacted, it can't verify that it is safe to drop the file, and will
+refuse to do so.
+
+With numcopies of 2, in order to drop the file content from Laptop, it
+would need access to both USB and Server.
diff --git a/doc/copies/comment_1_af9bee33777fb8a187b714fc8c5fb11d._comment b/doc/copies/comment_1_af9bee33777fb8a187b714fc8c5fb11d._comment
new file mode 100644
index 0000000000..45e5722604
--- /dev/null
+++ b/doc/copies/comment_1_af9bee33777fb8a187b714fc8c5fb11d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://olivier.berger.myopenid.com/"
+ nickname="obergix"
+ subject="See also section on backups in walthroug"
+ date="2013-08-25T05:37:04Z"
+ content="""
+See also [walthrough/backups](/walkthrough/backups/) for some details about copies. 
+"""]]
diff --git a/doc/copies/comment_2_1214610c03193cb9dd76dc24e5b7fd76._comment b/doc/copies/comment_2_1214610c03193cb9dd76dc24e5b7fd76._comment
new file mode 100644
index 0000000000..8f250b9de7
--- /dev/null
+++ b/doc/copies/comment_2_1214610c03193cb9dd76dc24e5b7fd76._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="tomdhunt"
+ avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
+ subject="Differing reliability among remotes"
+ date="2023-06-12T22:58:41Z"
+ content="""
+I'm looking for a way to express that remotes may be of differing reliability. E.g. some remotes are on RAIDs that are robust to disk failures, but others are on single, possibly external disks. I would like copies of a file on a reliable remote to count for more than those on an unreliable one, so that e.g. git-annex requires two copies on single disks but allows one on a RAID.
+
+Is there a way to do this via the copies logic? Or some other method?
+"""]]
diff --git a/doc/copies/comment_3_5beb9a5b87dd6775f9b921ad1e9bc610._comment b/doc/copies/comment_3_5beb9a5b87dd6775f9b921ad1e9bc610._comment
new file mode 100644
index 0000000000..287e89e25f
--- /dev/null
+++ b/doc/copies/comment_3_5beb9a5b87dd6775f9b921ad1e9bc610._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 3"
+ date="2023-06-13T06:42:47Z"
+ content="""
+git annex can't have multiple copies of the same file in one repo. And if your disk fails, a second copy doesn't really help, does it? But you can achieve what you want with either:
+
+- kinda with `git annex untrust repo-on-normal-disk`, this will assume your normal disks might fail anytime and will put files elsewhere as well
+- with [groups](https://git-annex.branchable.com/preferred_content/standard_groups/)
+  - make another, second repo on your normal disks (that alone could help)
+  - put all repos on your normal disks into one group: `git annex group mydisk1 baddisks` and `git annex group mydisk2 baddisks`
+  - specify that all your normal disks want to have the same content as the raid ones with some expression: https://git-annex.branchable.com/preferred_content/   `git annex groupwanted baddisks ...`    `git annex wanted myrepo1 groupwanted`
+"""]]
diff --git a/doc/copies/comment_4_0daa1b3ecc2a4cf844b8f1b98a883e67._comment b/doc/copies/comment_4_0daa1b3ecc2a4cf844b8f1b98a883e67._comment
new file mode 100644
index 0000000000..4825b572b1
--- /dev/null
+++ b/doc/copies/comment_4_0daa1b3ecc2a4cf844b8f1b98a883e67._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 4"
+ date="2023-06-14T10:42:40Z"
+ content="""
+A quick thought: Perhaps it might be worth exploring if `trust` could be like implemented in a way similar to `cost`. It might open up possibilities for setting a required level of trust for a given file, adding up the various remotes  to a sum.
+"""]]
diff --git a/doc/copies/comment_5_cc4cd8f739d4e72614c0b98f00e3510d._comment b/doc/copies/comment_5_cc4cd8f739d4e72614c0b98f00e3510d._comment
new file mode 100644
index 0000000000..6bec76be12
--- /dev/null
+++ b/doc/copies/comment_5_cc4cd8f739d4e72614c0b98f00e3510d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-06-19T15:36:07Z"
+ content="""
+@strmd, there is a todo relevant to this,
+[[todo/repositories_that_count_as_more_than_one_copy]].
+
+I think it's a reasonable idea, but there are probably details that need to
+be thought through.
+"""]]
diff --git a/doc/design.mdwn b/doc/design.mdwn
new file mode 100644
index 0000000000..e4f0e5c2a9
--- /dev/null
+++ b/doc/design.mdwn
@@ -0,0 +1,6 @@
+git-annex's high-level design is mostly inherent in the data that it
+stores in git, and alongside git. See [[internals]] for details.
+
+Here's the other design documents we have:
+
+[[!map pages="page(design/*) and !design/*/*"]]
diff --git a/doc/design/adjusted_branches.mdwn b/doc/design/adjusted_branches.mdwn
new file mode 100644
index 0000000000..608c04c9a7
--- /dev/null
+++ b/doc/design/adjusted_branches.mdwn
@@ -0,0 +1,316 @@
+Consider two use cases:
+
+1. Using a v6 repo with locked files on a crippled filesystem not
+   supporting symlinks. For the files to be usable, they need to be
+   unlocked. But, the user may not want to unlock the files everywhere,
+   just on this one crippled system.
+2. [[todo/hide_missing_files]]
+
+Both of these could be met by making `git-annex sync` maintain an adjusted
+version of the original branch, eg `adjusted/master`.
+
+There would be a adjustment function. For #1 above it would simply convert all
+annex symlinks to annex file pointers. For #2 above it would omit files
+whose content is not currently in the annex. Sometimes, both #1 and #2 would
+be wanted. The function is currently implemented as the [[git-annex-adjust]] command.
+
+[Alternatively, it could stay on the master branch, and only adjust the
+work tree and index. See WORKTREE notes below for how this choice would
+play out.]
+
+[[!toc]]
+
+## adjusting
+
+	master           adjusted/master
+	A
+	|--------------->A'
+	|                |
+
+When generating commit A', reuse the date of A and use a standard author,
+committer, and message. This means that two users with the adjusted branch
+checked out and using the same adjustments will get identical shas for A', and
+so can collaborate on them.
+
+## commit
+
+When committing changes, a commit is made as usual to the adjusted branch.
+So, the user can `git commit` as usual. This does not touch the
+original branch yet. 
+
+Then we need to get from that commit to one with the adjustments reversed,
+which should be the same as if the adjusted branch had not been used.
+This commit gets added onto the original branch.
+
+So, the branches would look like this:
+
+	master           adjusted/master
+	A
+	|--------------->A'
+	|                |
+	|                C (new commit)
+	B < - - - - - - -
+	|                
+	|--------------->B'
+	|                |
+
+Note particularly that B does not have A' or C in its history;
+the adjusted branch is not evident from outside.
+
+Also note that B gets adjusted and the adjusted branch is rebased on top of
+it, so C does not remain in the adjusted branch history either. This will
+make other checkouts that are in the same adjusted branch end up with the
+same B' commit when they pull B.
+
+There may be multiple commits made to the adjusted branch before any get
+applied back to the original branch. This is handled by reverse adjusting
+commits one at a time and rebasing the others on top.
+
+	master           adjusted/master
+	A
+	|--------------->A'
+	|                |
+	|                C1
+	|                |
+	|                C2
+
+
+	master           adjusted/master
+	A
+	|--------------->A'
+	|                |
+	|                C1
+	B1< - - - - - - -
+	|
+	|--------------->B1'
+	|                |
+	|                C2'
+	B2< - - - - - - -
+	|
+	|--------------->B2'
+
+
+[WORKTREE: A pre-commit hook would be needed to update the staged changes, 
+reversing the adjustment before the commit is made. All the other complications
+above are avoided.]
+
+## merge
+
+This would be done by `git annex merge` and `git annex sync`, with the goal
+of merging origin/master into master, and updating adjusted/master.
+
+Note that the adjusted files db needs to be updated to reflect the changes
+that are merged in, for object add/remove to work as described below.
+
+When merging, there should never be any commits present on the
+adjusted/master branch that have not yet been propigated back to the master
+branch. If there are any such commits, just propigate them into master
+before beginning the merge. There may be staged changes, or changes in the
+work tree.
+
+First, merge origin/master into master. This is done in a temp work
+tree and with a temp index, so does not affect the checked out adjusted
+branch.
+
+(Note that the reason this is done, rather than adjusting origin/master
+and merging it into the work tree, is that merge conflicts would be very
+common with the naive approach, because the adjusted branch often changes
+files, and origin/master may change the same files.)
+
+	origin/master  master   adjusted/master
+	A------------->A- - - ->A'
+	|              |
+	B------------->C
+
+While a fast-forward merge is shown here, other merges work the same way.
+There may be merge conflicts; if so they're auto-resolved.
+
+Then, adjust merge commit C, and merge that into adjusted/master.
+	
+	origin/master  master   adjusted/master
+	A------------->A- - - ->A'
+	|              |        |
+	B------------->C- - C'->D'
+
+This merge is done in-worktree, so the work tree gets updated.
+There may be more merge conflicts here; they're also auto-resolved.
+
+Now, D' is a merge commit, between A' and C'. 
+To finish, change that commit so it does not have A' as its parent.
+
+This can be accomplished by propigating the reverse-adjusted D'
+back to master, and then adjusting master to yield the final
+adjusted/master.
+	
+	origin/master  master   adjusted/master
+	A------------->A
+	|              |         
+	B------------->C         
+	               |         
+		       D - - -> D'
+
+Notice how similar this is to the commit graph. Indeed, "fast-forward" 
+merging the same B commit from origin/master will lead to an identical
+sha for B' as the original committer got!
+
+Since the adjusted/master branch is not present on the remote, if the user
+does a `git pull`, it won't merge in changes from origin/master. Which is
+good because the adjustment needs to be applied first.
+
+However, if the user does `git merge origin/master`, they'll get into a
+state where the adjustment has not been applied. The post-merge hook could be
+used to clean up after that. Or, let the user foot-shoot this way; they can
+always reset back once they notice the mistake.
+
+[WORKTREE: `git pull` would update the work tree, and may lead to conflicts
+between the adjusted work tree and pulled changes. A post-merge hook would
+be needed to re-adjust the work tree, and there would be a window where eg,
+not present files would appear in the work tree.]
+
+## annex object add/remove
+
+When objects are added/removed from the annex, the associated file has to
+be looked up, and the adjustment applied to it. So, dropping a file with the
+missing file adjustment would cause it to be removed from the adjusted branch,
+and receiving a file's content would cause it to appear in the adjusted
+branch. TODO
+
+These changes would need to be committed to the adjusted branch, otherwise
+`git diff` would show them.
+
+How to avoid making a new commit each time a single object is
+added/removed? That seems too expensive in both CPU and dangling git
+objects for old versions of the adjusted branch. It would be fine if
+`git annex get` and `git annex drop` only re-adjusted the branch one time
+at the end. OTOH, when should the assistant re-adjust the branch?
+
+Maybe instead of re-adjusting the branch after each file, stage the
+worktree change, and hold off on committing. Then when a commit is
+eventually made, the reverse adjusting to propigate it to master would need
+to make sure to not remove files that were deleted as part of the commit,
+if their content is not present.
+
+[WORKTREE: Simply adjust the work tree (and index) per the adjustment.]
+
+## reverse adjusting commits
+
+A user's commits on the adjusted branch have to be reverse adjusted
+to get changes to apply to the master branch.
+
+This reversal of one adjustment can be done as just another adjustment.
+Since only files touched by the commit will be reverse adjusted, it doesn't
+need to reverse all changes made by the original adjustment.
+
+For example, reversing the unlock adjustment might lock the file. Or, it might
+do nothing, which would make all committed files remain unlocked.
+
+## push
+
+The new master branch can then be pushed out to remotes. The
+adjusted/master branch is not pushed to remotes. `git-annex sync` should
+automatically push master when adjusted/master is checked out.
+
+When push.default is "simple" (the new default), running `git push` when in
+adjusted/master won't push anything. It would with "matching". Pity. (I
+continue to feel git picked the wrong default here.) Users may find that
+surprising. Users of `git-annex sync` won't need to worry about it though.
+
+[WORKTREE: push works as usual]
+
+## acting on filtered-out files
+
+If a file is filtered out due to not existing, there should be a way
+for `git annex get` to get it. Since the filtered out file is not in the
+index, that would not normally work. What to do?
+
+Maybe instead of making a branch where the file is deleted, it would be
+better to delete it from the work tree, but keep the branch as-is. Then
+`git annex get` would see the file, as it's in the index. 
+
+But, not maintaining an adjusted branch complicates other things. See
+WORKTREE notes throughout this page. Overall, the WORKTREE approach seems
+too problematic.
+
+Ah, but we know that when adjustment #2 is in place, any file that `git annex
+get` could act on is not in the index. So, it could look at the master branch
+instead. (Same for `git annex move --from` and `git annex copy --from` and
+the assistant.)
+
+OTOH, if adjustment #1 is in place and not #2, a file might be renamed in the
+index, and `git annex get $newname` should work. So, it should look at the
+index in that case.
+
+## problems
+
+Using `git checkout` when in an adjusted branch is problematic, because a
+non-adjusted branch would then be checked out. But, we can just say, if
+you want to get into an adjusted branch, you have to run git annex adjust
+Or, could make a post-checkout hook. This is would mostly be confusing when
+git-annex init switched into the adjusted branch due to lack of symlink
+support.
+
+After a commit to an adjusted branch, `git push` won't do anything. The
+user has to know to git-annex sync. (Even if a pre-commit hook propigated
+the commit back to the master branch, `git push` wouldn't push it with the
+default "matching" push strategy.)
+
+Tags are bit of a problem. If the user tags an ajusted branch, the tag
+includes the local adjustments.  
+[WORKTREE: not a problem]
+
+If the user refers to commit shas (in, eg commit messages), those won't be
+visible to anyone else.  
+[WORKTREE: not a problem]
+
+When a pull modifies a file, its content won't be available, and so it
+would be hidden temporarily by adjustment #2. So the file would seem to vanish,
+and come back later, which could be confusing. Could be fixed as discussed
+in [[todo/deferred_update_mode]]. Arguably, it's just as confusing for the
+file to remain visible but have its content temporarily replaced with a
+annex pointer.
+
+### master push overwrite race (fixed)
+
+There are potentially races in code that assumes a branch like
+master is not being changed by someone else. 
+  
+In particular, if propigateAdjustedCommits rebases the adjusted branch on
+top of master. That is called by sync. The assumption is that any changes
+in master have already been handled by updateAdjustedBranch. But, if
+another remote pushed a new master at just the right time, the adjusted
+branch could be rebased on top of a master that it doesn't incorporate,
+which is wrong.
+
+Best fix seems to be to maintain a basis ref, that is not a branch,
+like refs/adjusted/master(unlocked). Copy master's ref to it when
+entering the view branch. Then, make all adjustments via the basis
+ref, and propigate back to refs/heads/master.
+
+It's fine to overwrite changes that were pushed to master when
+propigating from the adjusted branch. Synced changes also go to
+synced/master so won't be lost. Pushes not made using git-annex sync
+of master are not really desired, just a possibility.
+
+## integration with view branches
+
+Entering a view from an adjusted branch should probably carry the adjusting
+over into the creation/updating of the view branch.
+
+Could go a step further, and implement view branches as another branch
+adjustment, albeit an extreme one. This might improve view branches.
+For example, it's not currently possible to update a view branch with
+changes fetched from a remote, and this could get us there.
+
+This would need the reverse adjust to be able to change metadata,
+so that a commit that moved files in the view updates their metadata.
+
+[WORKTREE: Wouldn't be able to integrate, unless view branches are changed
+into adjusted view worktrees.]
+
+## TODOs
+
+* Interface in webapp to enable adjustments.
+* Honor annex.thin when entering an adjusted branch. git checkout
+  will make copies of the content of annexed files, so this would need
+  to checkout the adjusted branch some other way. Maybe generalize so this
+  more efficient checkout is available as a git-annex command?
diff --git a/doc/design/adjusted_branches/comment_1_5bdbf54ae75f77c69c8f557f4dbac13d._comment b/doc/design/adjusted_branches/comment_1_5bdbf54ae75f77c69c8f557f4dbac13d._comment
new file mode 100644
index 0000000000..36f2db3065
--- /dev/null
+++ b/doc/design/adjusted_branches/comment_1_5bdbf54ae75f77c69c8f557f4dbac13d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="would it be possible to get a branch only with annexed content?"
+ date="2016-02-25T03:04:26Z"
+ content="""
+I am yet to grasp all the glorious plans here, but wondered to ask:  it seems like it then should be possible to establish a branch only with annexed archive? may be matching some preferred content expression?
+Usecase:  a relatively large git/annex repository mixing in code, large data files, and some pre-built binaries.  If I could seamlessly and reproducibly (with the progress of their master) tease those apart (for separate Debian packaging ;)), that would be really handy
+
+[[!meta author=yoh]]
+"""]]
diff --git a/doc/design/adjusted_branches/comment_2_ff7cbdf93f0be5886f212bdd411efb5b._comment b/doc/design/adjusted_branches/comment_2_ff7cbdf93f0be5886f212bdd411efb5b._comment
new file mode 100644
index 0000000000..6a3502997e
--- /dev/null
+++ b/doc/design/adjusted_branches/comment_2_ff7cbdf93f0be5886f212bdd411efb5b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-03-14T20:38:09Z"
+ content="""
+Yes, lots of things are possible with this. Filtering to only annexed files
+probably. May be some hairyness around updating the branch when files are
+got or dropped. Matching a preferred content expression, maybe..
+"""]]
diff --git a/doc/design/adjusted_branches/comment_3_e2a4b1719ba9860da711b802de64daf5._comment b/doc/design/adjusted_branches/comment_3_e2a4b1719ba9860da711b802de64daf5._comment
new file mode 100644
index 0000000000..a30f4c50c7
--- /dev/null
+++ b/doc/design/adjusted_branches/comment_3_e2a4b1719ba9860da711b802de64daf5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="thowz"
+ subject="adjusting symlink paths"
+ date="2016-05-13T22:32:33Z"
+ content="""
+Another good use case for this would be adjusting the target paths of symlinks for non-standard locations of the .git/annex/objects folder, such as when cloning into a repo where the GIT_DIR is outside the worktree folder, or when someone is using multiple worktrees and the links in other worktrees need to point to the GIT_COMMON_DIR.
+
+[[https://git-scm.com/docs/git-worktree]]<br>
+[[https://stacktoheap.com/blog/2016/01/19/using-multiple-worktrees-with-git/]]
+"""]]
diff --git a/doc/design/adjusted_branches/comment_4_adfcbfa7a9193318cba459766a60c072._comment b/doc/design/adjusted_branches/comment_4_adfcbfa7a9193318cba459766a60c072._comment
new file mode 100644
index 0000000000..2037a5f32b
--- /dev/null
+++ b/doc/design/adjusted_branches/comment_4_adfcbfa7a9193318cba459766a60c072._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-05-16T20:34:28Z"
+ content="""
+@thowz great idea! And not hard at all to implement! I've done so:
+`git annex adjust --fix`
+"""]]
diff --git a/doc/design/adjusted_branches/comment_5_882520747d41500d0ea8a18ab817121c._comment b/doc/design/adjusted_branches/comment_5_882520747d41500d0ea8a18ab817121c._comment
new file mode 100644
index 0000000000..91f5d824c1
--- /dev/null
+++ b/doc/design/adjusted_branches/comment_5_882520747d41500d0ea8a18ab817121c._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="zack"
+ subject="adjusted branche to &quot;focus&quot; on a specific subtree"
+ date="2016-08-22T14:19:57Z"
+ content="""
+I'm having hard time supporting the following use case with git-annex:
+
+* using git annex so that \"git annex sync --content\" import in batch pictures from a camera SD card
+* destination of the import is a \"pictures/INCOMING\" subdir of a larger \"multimedia archive\" annex
+* I do not want to have all the other folders of the annex (parent and siblings of pictures/INCOMING) present on the SD card
+
+I wonder if adjusted branches might be a solution to this.
+Do I get it right that \"unlocked\" is currently the only supported kind of adjustment?
+
+If so, I'm not sure what would be needed to make the above use case feasible.
+At first sight though, commits int the adjusted branch that \"mounts\" pictures/INCOMING/ are conceptually easy to translate to the main branch: the changes would be the same, only they'll have to be applied in a specific subtree.
+They won't merge cleanly though.
+
+Is this an interesting/worthwhile use case for adjusted branches, or am I looking into the wrong part of git-annex design?
+
+Thanks for this amazing tool!
+"""]]
diff --git a/doc/design/assistant.mdwn b/doc/design/assistant.mdwn
new file mode 100644
index 0000000000..052c536782
--- /dev/null
+++ b/doc/design/assistant.mdwn
@@ -0,0 +1,45 @@
+These are the design pages for the git-annex [[/assistant]].
+
+Parts of the design is still being fleshed out, still many ideas
+and use cases to add. Feel free to chip in with comments! --[[Joey]]
+
+See [[roadmap]] for current plans, as this list was mostly completed.
+
+## initial development kickstarter year overview (2012-2013)
+
+* Month 1 "like dropbox": [[!traillink inotify]] [[!traillink syncing]]
+* Month 2 "shiny webapp": [[!traillink webapp]] [[!traillink progressbars]]
+* Month 3 "easy setup": [[!traillink configurators]] [[!traillink pairing]]
+* Month 4 "cloud": [[!traillink cloud]] [[!traillink transfer_control]]
+* Month 5 "cloud continued": [[!traillink xmpp]] [[!traillink more_cloud_providers]]
+* Month 6 "9k bonus round": [[!traillink desymlink]]
+* Month 7: user-driven features and polishing;
+  [presentation at LCA2013](http://mirror.linux.org.au/linux.conf.au/2013/mp4/gitannex.mp4)
+* Month 8: [[!traillink Android]]
+* Month 9: [[screencasts|videos]] and polishing
+* Month 10: bugfixing, [[Android]] webapp
+* Month 11: [[!traillink Windows]] porting, finishing touches
+* Month 12: [presentation at SELF2013](http://www.southeastlinuxfest.org/), finishing touches
+
+## porting
+
+* [[OSX]] port is in fairly good shape, but still has some room for improvement
+* [[android]] port is zooming along
+* [[Windows]] port is barely getting started
+
+## not yet on the map:
+
+* [[rate_limiting]]
+* [[partial_content]]
+* [[deltas]]
+* [[leftovers]]
+* [[other todo items|todo]]
+
+## polls
+
+I post [[polls]] occasionally to make decisions. You can vote!
+
+## blog
+
+I'm blogging about my progress in the [[devblog]] on a semi-daily basis.
+Follow along!
diff --git a/doc/design/assistant/OSX.mdwn b/doc/design/assistant/OSX.mdwn
new file mode 100644
index 0000000000..400e517bf4
--- /dev/null
+++ b/doc/design/assistant/OSX.mdwn
@@ -0,0 +1,13 @@
+Misc OSX porting things:
+
+* autostart the assistant on OSX, using launchd **done**
+* icon to start webapp **done**
+* use FSEvents to detect file changes (better than kqueue) **done**
+* Use OSX's "network reachability functionality" to detect when on a network
+  <http://developer.apple.com/library/mac/#documentation/Networking/Conceptual/SystemConfigFrameworks/SC_Intro/SC_Intro.html#//apple_ref/doc/uid/TP40001065>
+* Switch from gpg to <https://gpgtools.org/>. According to a user,
+  this is better because it can show a dialog window for password prompts.
+
+Bugs:
+
+[[!inline pages="tagged(design/assistant/OSX) and !link(bugs/done)" show=0 archive=yes]]
diff --git a/doc/design/assistant/OSX/comment_1_9290f6e6f265e906b08631224392b7bf._comment b/doc/design/assistant/OSX/comment_1_9290f6e6f265e906b08631224392b7bf._comment
new file mode 100644
index 0000000000..633dd01b45
--- /dev/null
+++ b/doc/design/assistant/OSX/comment_1_9290f6e6f265e906b08631224392b7bf._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlu-fdXIt_RF9ggvg4zP0yBbtjWQwHAMS4"
+ nickname="Jörn"
+ subject="Mount detection"
+ date="2012-09-21T09:23:34Z"
+ content="""
+regarding the current mount polling on OSX: why not use the NSNotificationCenter for being notified on mount events on OSX?
+
+Details see:
+
+1. <http://stackoverflow.com/questions/12409458/detect-when-a-volume-is-mounted-on-os-x>
+2. <http://stackoverflow.com/questions/6062299/how-to-add-an-observer-to-nsnotificationcenter-in-a-c-class-using-objective-c>
+3. <https://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFNotificationCenterRef/Reference/reference.html#//apple_ref/doc/uid/20001438>
+"""]]
diff --git a/doc/design/assistant/android.mdwn b/doc/design/assistant/android.mdwn
new file mode 100644
index 0000000000..8beaffabc3
--- /dev/null
+++ b/doc/design/assistant/android.mdwn
@@ -0,0 +1,42 @@
+The Android port is just about usable. Still, we have some fun todo items
+to improve it.
+
+## high-priority TODO
+
+* [[bugs/Android_app_permission_denial_on_startup]]
+* S3 doesn't work (at least to Internet Archive: 
+  "connect: does not exist (connection refused)")
+* Get app into Google Play and/or FDroid
+
+## TODO
+
+* Don't make app initially open terminal + webapp, but go to a page that
+  allows opening the webapp or terminal.  
+  Possibly, switch from running inside terminal app to real standalone app.
+  See <https://github.com/neurocyte/android-haskell-activity>
+  and <https://github.com/neurocyte/foreign-jni>.
+
+* I have seen an assistant thread crash with an interrupted system call
+  when the device went to sleep while it was running. Auto-detect and deal with
+  that somehow.
+* Make git stop complaining that "warning: no threads uspport, ignoring --threads"
+* git does not support http remotes. To fix, need to port libcurl and
+  allow git to link to it.
+* getEnvironment is broken on Android <https://github.com/neurocyte/ghc-android/issues/7>
+  and a few places use it. I have some horrible workarounds in place.
+* Get local pairing to work. network-multicast and network-info don't
+  currently install.
+* Get test suite to pass. `git clone` of a local repo fails on android
+  for some reason.
+* Make app autostart on boot, optionally. <http://stackoverflow.com/questions/1056570/how-to-autostart-an-android-application>
+* The app should be aware of power status, and avoid expensive background
+  jobs when low on battery or run flat out when plugged in.
+* The app should be aware of network status, and avoid expensive data
+  transfers when not on wifi. This may need to be configurable.
+* glacier and local pairing are not yet enabled for Android.
+* The "Files" link doesn't start a file browser. Should be possible to do
+  on Android via intents, I suppose?
+* Adding removable drives would work, but the android app is not in the 
+  appropriate group to write to them. `WRITE_MEDIA_STORAGE` permission
+  needed. Added to AndroidManifest, but did not seem to be used.
+  Googleing for it will find a workaround that needs a rooted device.
diff --git a/doc/design/assistant/android/comment_10_316bde8d22628e5e9d4f8dabce1d2ad4._comment b/doc/design/assistant/android/comment_10_316bde8d22628e5e9d4f8dabce1d2ad4._comment
new file mode 100644
index 0000000000..89f23d72ca
--- /dev/null
+++ b/doc/design/assistant/android/comment_10_316bde8d22628e5e9d4f8dabce1d2ad4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="87.194.19.134"
+ subject="comment 10"
+ date="2013-05-06T12:18:39Z"
+ content="""
+One of the points is:
+
+* The app should be aware of power status, and avoid expensive background jobs when low on battery or run flat out when plugged in.
+
+This isn't good for situations where the device is plugged in and charging, but will only be so for a limited time (such as charging during a car journey) as the device would charge slower.
+
+Could this behaviour be configurable too?
+"""]]
diff --git a/doc/design/assistant/android/comment_11_cf801ce1f49f0201681f0c9f69a62aae._comment b/doc/design/assistant/android/comment_11_cf801ce1f49f0201681f0c9f69a62aae._comment
new file mode 100644
index 0000000000..7098514441
--- /dev/null
+++ b/doc/design/assistant/android/comment_11_cf801ce1f49f0201681f0c9f69a62aae._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="pweemeeuw@86491f921da15d6a4dc6e1878fd42750b33f6963"
+ nickname="pweemeeuw"
+ subject="Is android 6.0 supported?"
+ date="2015-11-30T16:05:13Z"
+ content="""
+I tried to install the version for android 5 on my nexus 5 with the most recent firmware. The initial sync (git clone) succeeds, the git annex stuff fails with \"remote origin does not have git-annex installed; setting annex-ignore\".
+
+I have the android 4 version working on my tablet for the same ssh remote, so I think the remote is OK.
+
+I can provide full logs of the terminal session if needed (I didn't use the assistant front end).
+
+BTW: this is great software, thanks you so very much! I hope to have it up and running on all my devices soon as a replacement for Google Drive. I happen to care about privacy.
+"""]]
diff --git a/doc/design/assistant/android/comment_1_8be9a74e5fc4641c2bf2e1bb7673dd59._comment b/doc/design/assistant/android/comment_1_8be9a74e5fc4641c2bf2e1bb7673dd59._comment
new file mode 100644
index 0000000000..389eac026d
--- /dev/null
+++ b/doc/design/assistant/android/comment_1_8be9a74e5fc4641c2bf2e1bb7673dd59._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~gdr-go2"
+ nickname="gdr-go2"
+ subject="FAT symlinks"
+ date="2012-05-28T18:12:10Z"
+ content="""
+It's a linux kernel so perhaps another option would be to create a big file and mount -o loop
+"""]]
diff --git a/doc/design/assistant/android/comment_2_3dd386ac1b757c73d14f14377b9eedd4._comment b/doc/design/assistant/android/comment_2_3dd386ac1b757c73d14f14377b9eedd4._comment
new file mode 100644
index 0000000000..3ff46ca060
--- /dev/null
+++ b/doc/design/assistant/android/comment_2_3dd386ac1b757c73d14f14377b9eedd4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlhIMPGF1E0XEJKV6j6-PFzAxA1-nIlydo"
+ nickname="Bernhard"
+ subject="re @  gdr-go2 "
+ date="2012-09-10T19:34:00Z"
+ content="""
+`mount` requires root and you'll have still the 4gb limit for your image by FAT. some phones (e.g. galaxy nexus) already use `ext4` for `/sdcard` though.
+"""]]
diff --git a/doc/design/assistant/android/comment_3_5dca47a4599d6e88d19193701c5a571b._comment b/doc/design/assistant/android/comment_3_5dca47a4599d6e88d19193701c5a571b._comment
new file mode 100644
index 0000000000..8f60efdb06
--- /dev/null
+++ b/doc/design/assistant/android/comment_3_5dca47a4599d6e88d19193701c5a571b._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlhIMPGF1E0XEJKV6j6-PFzAxA1-nIlydo"
+ nickname="Bernhard"
+ subject="GHC and Android"
+ date="2012-09-10T21:58:28Z"
+ content="""
+I played around a bit with GHC and Android today. It isn't really a result, but maybe useful for someone out there.
+
+I have a Debian `chroot` environment on my Android device (howto: <http://www.saurik.com/id/10/>). In the Debian box:
+
+    $ cat arm.hs
+    main = do
+      putStrLn \"Hello ARM\"
+    $ ghc -static --make arm.hs
+    Linking arm ...
+    $ ldd arm
+	libgmp.so.3 => /usr/lib/libgmp.so.3 (0x40233000)
+	libm.so.6 => /lib/libm.so.6 (0x400c8000)
+	libffi.so.5 => /usr/lib/libffi.so.5 (0x401b1000)
+	librt.so.1 => /lib/librt.so.1 (0x40171000)
+	libdl.so.2 => /lib/libdl.so.2 (0x40180000)
+	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4018b000)
+	libc.so.6 => /lib/libc.so.6 (0x40282000)
+	/lib/ld-linux.so.3 (0x400a2000)
+	libpthread.so.0 => /lib/libpthread.so.0 (0x4007e000)
+
+well, that isn't really static. tell the linker to build a static binary (those are arguments to `ld`):
+
+    $ ghc --make arm.hs -optl-static -optl-pthread
+    [1 of 1] Compiling Main             ( arm.hs, arm.o )
+    Linking arm ...
+    $ file arm
+    arm: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, not stripped
+    $ ldd arm
+    	not a dynamic executable
+    $ ./arm
+    Hello ARM
+
+now, get this (quite big) binary into the normal android environment, using `adb`, `SSHDroid` or whatever:
+
+    % cd /data/local/tmp # assuming destination of file transfer
+    % ./arm
+    arm: mkTextEncoding: invalid argument (Invalid argument)
+
+looking in the source of `System.IO` it seems like an `iconv` issue. So, there's still some dynamic dependency in there... *sigh*
+"""]]
diff --git a/doc/design/assistant/android/comment_4_054f06311e2b51d73be569f181eb004f._comment b/doc/design/assistant/android/comment_4_054f06311e2b51d73be569f181eb004f._comment
new file mode 100644
index 0000000000..76c32908a6
--- /dev/null
+++ b/doc/design/assistant/android/comment_4_054f06311e2b51d73be569f181eb004f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.30"
+ subject="comment 4"
+ date="2012-09-11T02:12:45Z"
+ content="""
+Thanks Bernard, that's really massively useful. It makes sense -- statically building with libc should work, the Android kernel is still Linux after all. 
+
+To get past the iconv problem, I think all you need is part of the `locales` package from your linux system installed on the Android. Probably just a few of the data files from /usr/share/i18n/charmaps/
+"""]]
diff --git a/doc/design/assistant/android/comment_5_bb3d36e9d29f2fa77bee6d47ef9917fe._comment b/doc/design/assistant/android/comment_5_bb3d36e9d29f2fa77bee6d47ef9917fe._comment
new file mode 100644
index 0000000000..be1e3e9e81
--- /dev/null
+++ b/doc/design/assistant/android/comment_5_bb3d36e9d29f2fa77bee6d47ef9917fe._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlhIMPGF1E0XEJKV6j6-PFzAxA1-nIlydo"
+ nickname="Bernhard"
+ subject="comment 5"
+ date="2012-09-11T09:34:42Z"
+ content="""
+`/usr/share/i18n/` does not exists on my Debian ARM system :/
+
+however, `strace ./arm` in the debian chroot reveals that some files from `/usr/lib/gconv/` are loaded:
+
+    [...]
+    open(\"/usr/lib/gconv/UTF-32.so\", O_RDONLY) = 3
+    read(3, \"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\4\4\0\0004\0\0\0\"..., 512) = 512
+    [...]
+
+full log: <http://wien.tomnetworks.com/strace_arm>.  Unfortunately, I don't have `strace` in the android userland for comparison.
+
+Just copying the related `gconv` files didn't work. I don't have so much time at the moment, I'll investigate further in some days or so.
+
+At least, output using `error :: String -> a` does work :-)
+"""]]
diff --git a/doc/design/assistant/android/comment_6_fee32a831eeb5736fe1dce52e30320c8._comment b/doc/design/assistant/android/comment_6_fee32a831eeb5736fe1dce52e30320c8._comment
new file mode 100644
index 0000000000..9dfe5670de
--- /dev/null
+++ b/doc/design/assistant/android/comment_6_fee32a831eeb5736fe1dce52e30320c8._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 6"
+ date="2012-10-30T08:44:32Z"
+ content="""
+Just so this does not get lost: For better or for worse, the vanilla Android devices stopped shipping with micro-SD support in 2011 (or 2010 if the Nexus S does not support them either; on sketchy GPRS so not googling around). Most higher-end Android devices ship with at least 8 GiB of on-board Flash storage, some even go up to 64 GiB.
+
+IMHO, this would make it viable to first get git-annex working on Android without regard for FAT.
+
+The obvious advantage is that porting should be easier and quicker.
+
+The obvious downside is that this may mean revisiting some parts of the code later.
+
+-- Richard
+"""]]
diff --git a/doc/design/assistant/android/comment_7_d8e9b0a5287fc96b19dc2cb9da3586ce._comment b/doc/design/assistant/android/comment_7_d8e9b0a5287fc96b19dc2cb9da3586ce._comment
new file mode 100644
index 0000000000..0419b1d1b0
--- /dev/null
+++ b/doc/design/assistant/android/comment_7_d8e9b0a5287fc96b19dc2cb9da3586ce._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 7"
+ date="2012-10-30T08:51:17Z"
+ content="""
+Actually, this is something that would be ideal for a poll:
+
+Should FAT-based Android repos be implemented:
+
+* Immediately
+* After the initial release of the Android app is working
+* Before the kickstarter ends
+* Not at all
+
+Also, as another data point, the FAT-based SD card can be mounted as USB storage by any computer an Android device is connected to whereas the EXT4-based root FS can only be accessed via MTP.
+"""]]
diff --git a/doc/design/assistant/android/comment_8_79a7b5bb5f4aaeea4a4e8ced0561701a._comment b/doc/design/assistant/android/comment_8_79a7b5bb5f4aaeea4a4e8ced0561701a._comment
new file mode 100644
index 0000000000..91db74ec65
--- /dev/null
+++ b/doc/design/assistant/android/comment_8_79a7b5bb5f4aaeea4a4e8ced0561701a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="Terminal IDE"
+ date="2012-11-21T21:46:19Z"
+ content="""
+I use Terminal IDE on android, which is 'sort of a shell environment'.
+
+It has bash, git, dropbear ssh, and vim. It is a bit limited, but it does feel like a linux shell.
+
+"""]]
diff --git a/doc/design/assistant/android/comment_9_55ea70a6929523d26248ff6409b04a6e._comment b/doc/design/assistant/android/comment_9_55ea70a6929523d26248ff6409b04a6e._comment
new file mode 100644
index 0000000000..d371c5fedb
--- /dev/null
+++ b/doc/design/assistant/android/comment_9_55ea70a6929523d26248ff6409b04a6e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl7ciFZWmffuw6sLRww3CcL_F5ItsttL9w"
+ nickname="Aaron"
+ subject="Feature request: Events triggered on wifi SSID or connection state"
+ date="2013-01-08T13:04:05Z"
+ content="""
+I'd like to have my phone sync a bunch of files when I'm at home and when I get to work, have them synced to my work machine, deleted off my phone and when I get home, also deleted off my home machine.
+
+This will allow incremental backups to a local folder at home and I can then \"mule\" my files, sneaker-net style, to work with zero user intervention. It only works if events can be triggered or I can combine a triggering app with a special android intent for both ends of my trip.
+"""]]
diff --git a/doc/design/assistant/blog.mdwn b/doc/design/assistant/blog.mdwn
new file mode 100644
index 0000000000..561173d27b
--- /dev/null
+++ b/doc/design/assistant/blog.mdwn
@@ -0,0 +1,11 @@
+This blog was updated on a semi-daily basis by Joey during the year of work
+concentrating on the git-annex assistant that was funded by his kickstarter
+campaign.
+
+Post-kickstarter work will instead appear on the [[devblog]]. However,
+this page's RSS feed will continue to work, so you don't have to migrate
+your RSS reader.
+
+[[!inline pages="page(devblog/*)" show=-1 feedshow=7]]
+
+[[!inline pages="page(design/assistant/blog/*)" show=0 feeds=no]]
diff --git a/doc/design/assistant/blog/day_100__cursed_clouds.mdwn b/doc/design/assistant/blog/day_100__cursed_clouds.mdwn
new file mode 100644
index 0000000000..7ac38f4634
--- /dev/null
+++ b/doc/design/assistant/blog/day_100__cursed_clouds.mdwn
@@ -0,0 +1,19 @@
+Preferred content control is wired up to `--auto` and working for `get`,
+`copy`, and `drop`. Note that `drop --from remote --auto` drops files that
+the remote's preferred content settings indicate it doesn't want;
+likewise `copy --to remote --auto` sends content that the remote does want.
+
+Also implemented `smallerthan`, `largerthan`, and `ingroup` limits,
+which should be everything needed for the scenarios described in
+[[transfer_control]].
+
+Dying to hook this up to the assistant, but a cloudy day is forcing me to
+curtail further computer use.
+
+----
+
+Also, last night I developed a patch for the hS3 library, that should let
+git-annex upload large files to S3 without buffering their whole content in
+memory. I have a `s3-memory-leak` in git-annex that uses the new API I
+developed. Hopefully hS3's maintainer will release a new version with that
+soon.
diff --git a/doc/design/assistant/blog/day_102__very_high_level_programming.mdwn b/doc/design/assistant/blog/day_102__very_high_level_programming.mdwn
new file mode 100644
index 0000000000..4e29cc65df
--- /dev/null
+++ b/doc/design/assistant/blog/day_102__very_high_level_programming.mdwn
@@ -0,0 +1,37 @@
+## today
+
+Came up with four groups of repositories that it makes sense to
+define standard preferred content expressions for.
+
+[[!format haskell """
+	preferredContent :: StandardGroup -> String
+	preferredContent ClientGroup = "exclude=*/archive/*"
+	preferredContent TransferGroup = "not inallgroup=client and " ++ preferredContent ClientGroup
+	preferredContent ArchiveGroup = "not copies=archive:1"
+	preferredContent BackupGroup = "" -- all content is preferred
+"""]]
+
+[[preferred_content]] has the details about these groups, but
+as I was writing those three preferred content expressions,
+I realized they are some of the highest level programming I've ever done,
+in a way.
+
+Anyway, these make for a very simple repository configuration UI:
+
+[[!img /assistant/repogroups.png alt="form with simple select box"]]
+
+## yesterday (forgot to post this)
+
+Got the assistant honoring preferred content settings. Although so far that
+only determines what it transfers. Additional work will be needed to make
+content be dropped when it stops being preferred.
+
+----
+
+Added a "configure" link next to each repository on the repository config
+page. This will go to a form to allow setting things like repository
+descriptions, groups, and preferred content settings.
+
+----
+
+Cut a release.
diff --git a/doc/design/assistant/blog/day_102__very_high_level_programming/comment_1_c028b403261dd66bcf83e6ffd134b80b._comment b/doc/design/assistant/blog/day_102__very_high_level_programming/comment_1_c028b403261dd66bcf83e6ffd134b80b._comment
new file mode 100644
index 0000000000..d9be239bd5
--- /dev/null
+++ b/doc/design/assistant/blog/day_102__very_high_level_programming/comment_1_c028b403261dd66bcf83e6ffd134b80b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlVwbp82f-7rNOyEpvqc9A8FEfn7wl2Akw"
+ nickname="Jos"
+ subject="Works for me"
+ date="2012-10-11T13:40:08Z"
+ content="""
+These categories make it much clearer to me how I will be able to use git annex assistant
+"""]]
diff --git a/doc/design/assistant/blog/day_103__bugfix_day.mdwn b/doc/design/assistant/blog/day_103__bugfix_day.mdwn
new file mode 100644
index 0000000000..7c08a2065e
--- /dev/null
+++ b/doc/design/assistant/blog/day_103__bugfix_day.mdwn
@@ -0,0 +1,25 @@
+Bugfixes all day.
+
+The most amusing bug, which I just stumbled over randomly on my own,
+after someone on IRC yesterday was possibly encountering the same issue,
+made `git annex webapp` go into an infinite memory-consuming loop on
+startup if the repository it had been using was no longer a valid git
+repository.
+
+Then there was the place where HOME got unset, with also sometimes amusing
+results.
+
+Also fixed several build problems, including a threaded runtime hang
+in the test suite. Hopefully the next release will build on all Debian
+architectures again.
+
+I'll be cutting that release tomorrow. I also updated the linux
+prebuilt tarballs today.
+
+----
+
+Hmm, not entirely bugfixes after all. Had time (and power) to work
+on the repository configuration form too, and added a check box to it that
+can be unchecked to disable syncing with a repository. 
+Also, made that form be displayed after the webapp creates a new
+repository.
diff --git a/doc/design/assistant/blog/day_104__misc.mdwn b/doc/design/assistant/blog/day_104__misc.mdwn
new file mode 100644
index 0000000000..bda802bfe5
--- /dev/null
+++ b/doc/design/assistant/blog/day_104__misc.mdwn
@@ -0,0 +1,18 @@
+Switched the OSX standalone app to use `DYLD_ROOT_PATH`.
+This is the third `DYLD_*` variable I've tried; neither
+of the other two worked in all situations. This one may do better.
+If not, I may be stuck modifying the library names in each executable
+using `install_name_tool`
+([good reference for doing that](http://www.mikeash.com/pyblog/friday-qa-2009-11-06-linking-and-install-names.html)).
+As far as I know, every existing dynamic library lookup system is broken
+in some way other other; nothing I've seen about OSX's so far
+disproves that rule.
+
+Fixed a nasty utf-8 encoding crash that could occur when merging the
+git-annex branch. I hope I'm almost done with those.
+
+Made git-annex auto-detect when a git remote is on a sever like github
+that doesn't support git-annex, and automatically set annex-ignore.
+
+Finished the UI for pausing syncing of a remote. Making the syncing
+actually stop still has some glitches to resolve.
diff --git a/doc/design/assistant/blog/day_104__misc/comment_1_13d7fad2d3f8eab10314784c035e2a16._comment b/doc/design/assistant/blog/day_104__misc/comment_1_13d7fad2d3f8eab10314784c035e2a16._comment
new file mode 100644
index 0000000000..67e342a4ba
--- /dev/null
+++ b/doc/design/assistant/blog/day_104__misc/comment_1_13d7fad2d3f8eab10314784c035e2a16._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmubB1Sj2rwFoVdZYvGV0ACaQUJQyiJXJI"
+ nickname="Paul"
+ subject="Thank you for stickers"
+ date="2012-10-14T13:59:55Z"
+ content="""
+Mail received in Finland.
+"""]]
diff --git a/doc/design/assistant/blog/day_105__lazy_Sunday.mdwn b/doc/design/assistant/blog/day_105__lazy_Sunday.mdwn
new file mode 100644
index 0000000000..eb25ddacef
--- /dev/null
+++ b/doc/design/assistant/blog/day_105__lazy_Sunday.mdwn
@@ -0,0 +1,43 @@
+Did a fair amount of testing and bug fixing today. 
+
+There is still some buggy behavior around pausing syncing to a remote,
+where transfers still happen to it, but I fixed the worst bug there.
+
+Noticed that if a non-bare repo is set up on a removable drive,
+its file tree will not normally be updated as syncs come in -- because the
+assistant is not running on that repo, and so incoming syncs are not
+merged into the local master branch. For now I made it always use bare
+repos on removable drives, but I may want to revisit this.
+
+The repository edit form now has a field for the name of the repo,
+so the ugly names that the assistant comes up with for ssh remotes
+can be edited as you like. `git remote rename` is a very nice thing.
+
+Changed the preferred content expression for transfer repos to this:
+"not (inallgroup=client **and copies=client:2)**". This way, when there's
+just one client, files on it will be synced to transfer repos, even
+though those repos have no other clients to transfer them to. Presumably,
+if a transfer repo is set up, more clients are coming soon, so this avoids
+a wait. Particularly useful with removable drives, as the drive will start
+being filled as soon as it's added, and can then be brought to a client
+elsewhere. The "2" does mean that, once another client is found,
+the data on the transfer repo will be dropped, and so if it's brought
+to yet another new client, it won't have data for it right away.
+I can't see way to generalize this workaround to more than 2 clients;
+the transfer repo has to start dropping apparently unwanted content at
+some point. Still, this will avoid a potentially very confusing behavior
+when getting started.
+
+----
+
+I need to get that dropping of non-preferred content to happen still.
+Yesterday, I did some analysis of all the events that can cause previously
+preferred content to no longer be preferred, so I know all the places
+I have to deal with this.
+
+The one that's giving me some trouble is checking in the transfer scan. If it
+checks for content to drop at the same time as content to transfer, it could
+end up doing a lot of transfers before dropping anything. It'd be nicer to
+first drop as much as it can, before getting more data, so that transfer
+remotes stay as small as possible. But the scan is expensive, and it'd also
+be nice not to need two passes.
diff --git a/doc/design/assistant/blog/day_106__lazy_Monday.mdwn b/doc/design/assistant/blog/day_106__lazy_Monday.mdwn
new file mode 100644
index 0000000000..84b96f6350
--- /dev/null
+++ b/doc/design/assistant/blog/day_106__lazy_Monday.mdwn
@@ -0,0 +1,10 @@
+I was mostly working on other things today, but I did do some bug fixing.
+The worst of these is a bug introduced in 3.20121009 that breaks
+`git-annex-shell configlist`. That's pretty bad for using git-annex
+on servers, although you mostly won't notice unless you're just getting
+started using a ssh remote, since that's when it calls configlist.
+I will be releasing a new version as soon as I have bandwidth (tomorrow).
+
+Also made the standalone Linux and OSX binaries build with ssh connection
+caching disabled, since they don't bundle their own ssh and need to work
+with whatever ssh is installed.
diff --git a/doc/design/assistant/blog/day_107__memory_leak.mdwn b/doc/design/assistant/blog/day_107__memory_leak.mdwn
new file mode 100644
index 0000000000..e33008f97e
--- /dev/null
+++ b/doc/design/assistant/blog/day_107__memory_leak.mdwn
@@ -0,0 +1,11 @@
+More bugfixes today. The assistant now seems to have enough users that
+they're turning up interesting bugs, which is good. But does keep me too
+busy to add many more bugs\^Wcode.
+
+The fun one today made it bloat to eat all memory when logging out of a
+Linux desktop. I tracked that back to a bug in the Haskell DBUS library
+when a session connection is open and the session goes away. Developed a
+test case, and even profiled it, and sent it all of to the library's
+author. Hopefully there will be a quick fix, in the meantime today's
+release has DBUS turned off. Which is ok, it just makes it a little bit
+slower to notice some events.
diff --git a/doc/design/assistant/blog/day_108__another_zombie_outbreak.mdwn b/doc/design/assistant/blog/day_108__another_zombie_outbreak.mdwn
new file mode 100644
index 0000000000..ee46073bd2
--- /dev/null
+++ b/doc/design/assistant/blog/day_108__another_zombie_outbreak.mdwn
@@ -0,0 +1,33 @@
+I released git-annex an unprecidented two times yesterday, because just
+after the first release, I learned of a another zombie problem. Turns out
+this zombie had existed for a while, but it was masked by zombie reaping
+code that I removed recently, after fixing most of the other zombie
+problems. This one, though, is not directly caused by git-annex. When rsync
+runs ssh, it seems to run two copies, and one is left unwaited on as a
+zombie. Oddly, this only happens when rsync's stdout is piped into
+git-annex, for progress bar handling. I have not source-dived rsync's code
+to get to the bottom of this, but I put in a workaround.
+
+I did get to the bottom of yesterday's runaway dbus library. Got lucky and
+found the cause of the memory leak in that library on the first try, which
+is nice since each try involved logging out of X. I've been corresponding
+with its author, and a fix will be available soon, and then git-annex will
+need some changes to handle dbus reconnection.
+
+-----
+
+For the first time, I'm starting to use the assistant on my own personal
+git-annex repo. The preferred content and group settings let me configure it
+use the complex system of partial syncing I need. For example, I have this
+configured for my sound files, keeping new podcasts on a server until they land
+somewhere near me. And keeping any sound files that I've manually put on my
+laptop, and syncing new podcasts, but not other stuff.
+
+	# (for my server)
+	preferred-content 87e06c7a-7388-11e0-ba07-03cdf300bd87 = include=podcasts/* and (not copies=nearjoey:1)
+	# (for my laptop)
+	preferred-content 0c443de8-e644-11df-acbf-f7cd7ca6210d = exclude=*/out/* and (in=here or (include=podcasts/*))
+
+Found and fixed a bug in the preferred content matching code, where
+if the assistant was run in a subdirectory of the repo, it failed to
+match files correctly.
diff --git a/doc/design/assistant/blog/day_108__another_zombie_outbreak/comment_1_194c48d65993462f809a2cfaa774a3e2._comment b/doc/design/assistant/blog/day_108__another_zombie_outbreak/comment_1_194c48d65993462f809a2cfaa774a3e2._comment
new file mode 100644
index 0000000000..690d59d17c
--- /dev/null
+++ b/doc/design/assistant/blog/day_108__another_zombie_outbreak/comment_1_194c48d65993462f809a2cfaa774a3e2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://a-or-b.myopenid.com/"
+ ip="203.45.2.230"
+ subject="comment 1"
+ date="2012-10-19T01:21:42Z"
+ content="""
+Can you elaborate on the \"nearjoey\" option below?
+> (not copies=nearjoey:1)
+
+Are you able to assign a \"nearjoey\" flag to multiple annexes?
+"""]]
diff --git a/doc/design/assistant/blog/day_108__another_zombie_outbreak/comment_2_ef5ee5933fcadcb81cc81b816db14bda._comment b/doc/design/assistant/blog/day_108__another_zombie_outbreak/comment_2_ef5ee5933fcadcb81cc81b816db14bda._comment
new file mode 100644
index 0000000000..0da13b7351
--- /dev/null
+++ b/doc/design/assistant/blog/day_108__another_zombie_outbreak/comment_2_ef5ee5933fcadcb81cc81b816db14bda._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.23"
+ subject="comment 2"
+ date="2012-10-19T17:07:08Z"
+ content="""
+Yes, using the group command.
+"""]]
diff --git a/doc/design/assistant/blog/day_109__dropping.mdwn b/doc/design/assistant/blog/day_109__dropping.mdwn
new file mode 100644
index 0000000000..210f71f553
--- /dev/null
+++ b/doc/design/assistant/blog/day_109__dropping.mdwn
@@ -0,0 +1,16 @@
+Got unwanted content to be dropped from the local repo, as well as remotes
+when doing the expensive scan. I kept the scan a single pass for now,
+need to revisit that later to drop content before transferring more.
+Also, when content is downloaded or uploaded, this can result in it
+needing to be dropped from somewhere, and the assistant handles that too.
+
+There are some edge cases with hypothetical, very weird preferred
+content expressions, where the assistant won't drop content right away.
+(But will later in the expensive scan.) Other than those, I think I have
+nearly all content dropping sorted out. The only common case I know of where
+unwanted content is not dropped by the assistant right away is when a file
+is renamed (eg, put in a "Trash" directory).
+
+In other words, repositories put into the transfer group will now work as
+described, only retaining content as long as is needed to distribute it to
+clients. Big milestone!
diff --git a/doc/design/assistant/blog/day_10__lsof.mdwn b/doc/design/assistant/blog/day_10__lsof.mdwn
new file mode 100644
index 0000000000..d4217677f0
--- /dev/null
+++ b/doc/design/assistant/blog/day_10__lsof.mdwn
@@ -0,0 +1,54 @@
+A rather frustrating and long day coding went like this:
+
+## 1-3 pm
+
+Wrote a single function, of which all any Haskell programmer needs to know
+is its type signature:
+
+	Lsof.queryDir :: FilePath -> IO [(FilePath, LsofOpenMode, ProcessInfo)]
+
+When I'm spending another hour or two taking a unix utility like lsof and
+parsing its output, which in this case is in a rather complicated
+machine-parsable output format, I often wish unix streams were strongly
+typed, which would avoid this bother.
+
+## 3-9 pm
+
+Six hours spent making it defer annexing files until the commit thread
+wakes up and is about to make a commit. Why did it take so horribly long?
+Well, there were a number of complications, and some really bad bugs
+involving races that were hard to reproduce reliably enough to deal with.
+
+In other words, I was lost in the weeds for a lot of those hours...
+
+At one point, something glorious happened, and it was always making exactly
+one commit for batch mode modifications of a lot of files (like untarring
+them). Unfortunately, I had to lose that gloriousness due to another
+potential race, which, while unlikely, would have made the program deadlock
+if it happened. 
+
+So, it's back to making 2 or 3 commits per batch mode change. I also have a
+buglet that causes sometimes a second empty commit after a file is added.
+I know why (the inotify event for the symlink gets in late,
+after the commit); will try to improve commit frequency later.
+
+## 9-11 pm
+
+Put the capstone on the day's work, by calling lsof on a directory full
+of hardlinks to the files that are about to be annexed, to check if any
+are still open for write.
+
+This works great! Starting up `git annex watch` when processes have files
+open is no longer a problem, and even if you're evil enough to try having
+multiple processes open the same file, it will complain and not annex it
+until all the writers close it.
+
+(Well, someone really evil could turn the write bit back on after git annex
+clears it, and open the file again, but then really evil people can do
+that to files in `.git/annex/objects` too, and they'll get their just
+deserts when `git annex fsck` runs. So, that's ok..)
+
+----
+
+Anyway, will beat on it more tomorrow, and if all is well, this will finally
+go out to the beta testers.
diff --git a/doc/design/assistant/blog/day_10__lsof/comment_1_9b8c28c85c979f32e5c295b6a03c048e._comment b/doc/design/assistant/blog/day_10__lsof/comment_1_9b8c28c85c979f32e5c295b6a03c048e._comment
new file mode 100644
index 0000000000..9d970da22e
--- /dev/null
+++ b/doc/design/assistant/blog/day_10__lsof/comment_1_9b8c28c85c979f32e5c295b6a03c048e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://dieter-be.myopenid.com/"
+ nickname="dieter"
+ subject="comment 1"
+ date="2012-06-16T09:14:26Z"
+ content="""
+maybe at some point, your tool could show \"warning, the following files are still open and are hence not being annexed\"
+to avoid any nasty surprises of a file not being annexed and the user not realizing it.
+"""]]
diff --git a/doc/design/assistant/blog/day_110__more_dropping.mdwn b/doc/design/assistant/blog/day_110__more_dropping.mdwn
new file mode 100644
index 0000000000..71fb01ab12
--- /dev/null
+++ b/doc/design/assistant/blog/day_110__more_dropping.mdwn
@@ -0,0 +1,55 @@
+Got preferred content checked when files are moved around.
+So, in repositories in the default client group, if you make a
+"archive" directory and move files to it, the assistant will drop
+their content (when possible, ie when it's reached an archive or backup).
+Move a file out of an archive directory, and the assistant will get its
+content again. Magic.
+
+Found an intractable bug, obvious in retrospect, with the git-annex branch
+read cache, and had to remove that cache. I have not fully determined
+if this will slow down git-annex in some use cases; might need to add more
+higher-level caching. It was a very minimal cache anyway, just of one file.
+
+Removed support for "in=" from preferred content expressions. That was
+problematic in two ways. First, it referred to a remote by name, but
+preferred content expressions can be evaluated elsewhere, where that remote
+doesn't exist, or a different remote has the same name. This name lookup
+code could error out at runtime. Secondly, "in=" seemed pretty useless, and
+indeed counterintuitive in preferred content expressions. "in=here" did not
+cause content to be gotten, but it did let present content be dropped.
+Other uses of "in=" are better handled by using groups.
+
+In place of "in=here", preferred content expressions can now use "present",
+which is useful if you want to disable automatic getting or dropping of
+content in some part of a repository. Had to document that "not present"
+is not a good thing to use -- it's unstable. Still, I find "present" handy
+enough to put up with that wart.
+
+Realized last night that the code I added to the TransferWatcher
+to check preferred content once a transfer is done is subject to a race;
+it will often run before the location log gets updated. Haven't found a good
+solution yet, but this is something I want working now, so I did put in a
+quick delay hack to avoid the race. Delays to avoid races are never a real
+solution, but sometimes you have to TODO it for later.
+
+----
+
+Been thinking about how to make the assistant notice changes to configuration
+in the git-annex branch that are merged in from elsewhere while it's running.
+I'd like to avoid re-reading unchanged configuration files after each merge
+of the branch.
+
+The most efficient way would be to reorganise the git-annex branch, moving
+config files into a configs directory, and logs into a logs directory. Then it
+could `git ls-tree git-annex configs` and check if the sha of the configs
+directory had changed, with git doing minimal work 
+(benchmarked at 0.011 seconds).
+
+Less efficiently, keep the current git-annex branch layout, and 
+use: `git ls-tree git-annex uuid.log remote.log preferred-content.log group.log trust.log`
+(benchmarked at 0.015 seconds)
+
+Leaning toward the less efficient option, with a rate limiter so it
+doesn't try more often than once every minute. Seems reasonable for it to
+take a minute for config changes take effect on remote repos, even
+if the assistant syncs file changes to them more quickly.
diff --git a/doc/design/assistant/blog/day_111__config_monitor.mdwn b/doc/design/assistant/blog/day_111__config_monitor.mdwn
new file mode 100644
index 0000000000..8addf54ae8
--- /dev/null
+++ b/doc/design/assistant/blog/day_111__config_monitor.mdwn
@@ -0,0 +1,18 @@
+Added yet another thread, the ConfigMonitor. Since that thread needs to run
+code to reload cached config values from the git-annex branch when files
+there change, writing it also let me review where config files are cached,
+and I found that every single config file in the git-annex branch does
+get cached, with the exception of the uuid.log. So, added a cache for that,
+and now I'm more sanguine about yesterday's removal of the lower-level
+cache, because the only thing not being cached is location log information.
+
+The ConfigMonitor thread seems to work, though I have not tested it
+extensively. The assistant should notice and apply config changes
+made locally, as well as any config changes pushed in from remotes.
+So, for example, if you add a S3 repo in the webapp, and are paired with
+another computer, that one's webapp will shortly include the new repo in
+its list. And all the preferred content, groups, etc settings will
+propigate over and be used as well.
+
+Well ... almost. Seems nothing causes git-annex branch changes to be
+pushed, until there's some file change to sync out.
diff --git a/doc/design/assistant/blog/day_112__and_now_for_something_completely_different.mdwn b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different.mdwn
new file mode 100644
index 0000000000..b7d72a2759
--- /dev/null
+++ b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different.mdwn
@@ -0,0 +1,50 @@
+Time to solve the assistant's [[cloud]] notification problem. This is
+really the last big road-bump to making it be able to sync computers
+across the big, bad internet.
+
+So, IRC still seems a possibility, but I'm going to try XMPP first. Since
+Google Talk uses XMPP, it should be easy for users to get an account, and
+it's also easy to run your own XMPP server.
+
+Played around with the Haskell XMPP library. Clint helpfully showed me an
+example of a simple client, which helped cut through that library's thicket
+of data types. In short order I had some clients that were able to see each
+other connecting to my personal XMPP server. On to some design..
+
+1. I want to avoid user-visible messages.
+   (dvcs-autosync also uses XMPP, but I checked the code and it
+   seems to send user-visible messages, so I diverge from its lead here.)
+   This seems very possible, only a matter of finding the right
+   way to use the protocol, or an appropriate and widely deployed extension.
+   The only message I need to send with XMPP, really, is "I have pushed to our
+   git repo". One bit of data would do; being able to send a UUID of the repo
+   that did the update would be nice.
+
+2. I'd also like to broadcast my notification to a user's buddies.
+   dvcs-autosync sends only self-messages, but that requires every node
+   have the same XMPP account configured. While I want to be able to run
+   in that mode, I also want to support pairs of users who have their own XMPP
+   accounts, that are buddied up in XMPP.
+
+3. To add to the fun, the assistant's use of XMPP should not make that XMPP
+   account appear active to its buddies. Users should not need a dedicated
+   XMPP account for git-annex, and always seeming to be available when
+   git-annex is running would not be nice.
+
+The first method I'm trying out is to encode the notification
+data inside a XMPP presence broadcast. This should meet all three
+requirements. The plan is two send two
+presence messages, the first marks the client as available, and the second
+as unavailable again.
+The "id" attribute will be set to some
+value generated by the assistant. That attribute is allowed on presence
+messages, and servers are [required to preserve it](http://xmpp.org/rfcs/rfc6121.html#presence-probe-inbound-id)
+while the client is connected.
+(I'd only send unavailable messages, but while
+that worked when I tested it using the prosody server, with google talk,
+repeated unavailable messages were suppressed. Also, google talk does not
+preserve the "id" attribute of unavailable presence messages.)
+
+If this presence hackery doesn't work out, I could try
+[XEP-0163: Personal Eventing Protocol](http://xmpp.org/extensions/xep-0163.html).
+But I like not relying on any extensions.
diff --git a/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_1_5e4fe1538d9ae1c450b0a6602fc6d29b._comment b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_1_5e4fe1538d9ae1c450b0a6602fc6d29b._comment
new file mode 100644
index 0000000000..26514601b5
--- /dev/null
+++ b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_1_5e4fe1538d9ae1c450b0a6602fc6d29b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmQ4Oe5-qOANRuZel9kDvtBfQG1zlEcIzw"
+ nickname="Dominik"
+ subject="PEP is ok"
+ date="2012-10-24T05:15:38Z"
+ content="""
+PEP and pubsub are really widely used. You will have a hard time finding a server that doesn't support it.
+
+Also note XMPPs ability to send status to only selected buddies and even resources. You can globally appear as offline while sending availability to myownjid@example.com/thatannexthere.
+"""]]
diff --git a/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_2_c5a734f611ecc95729904e645583ee43._comment b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_2_c5a734f611ecc95729904e645583ee43._comment
new file mode 100644
index 0000000000..2b85707a91
--- /dev/null
+++ b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_2_c5a734f611ecc95729904e645583ee43._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmQ4Oe5-qOANRuZel9kDvtBfQG1zlEcIzw"
+ nickname="Dominik"
+ subject="Remote control clients"
+ date="2012-10-24T05:18:02Z"
+ content="""
+Then of course there is XEP-0146, which has some advantages to it, like controlling annex from the context menu of another Jabber client. 
+"""]]
diff --git a/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_3_46b16dcd0fce07036cd8ed6ed9d2b055._comment b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_3_46b16dcd0fce07036cd8ed6ed9d2b055._comment
new file mode 100644
index 0000000000..5c6c161ffc
--- /dev/null
+++ b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_3_46b16dcd0fce07036cd8ed6ed9d2b055._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.23"
+ subject="comment 3"
+ date="2012-10-24T22:44:41Z"
+ content="""
+Google talk does not seem to support PEP. At least, I'm sending something that prosody accepts and that looks like the example at <http://xmpp.org/extensions/xep-0163.html#howitworks>, and it replies with an IQ Error.
+"""]]
diff --git a/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_4_1fe036e4c65fb4211aa2c394f535344a._comment b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_4_1fe036e4c65fb4211aa2c394f535344a._comment
new file mode 100644
index 0000000000..d19b70189d
--- /dev/null
+++ b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_4_1fe036e4c65fb4211aa2c394f535344a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmaM3-vbAh5B8tY_IL3yh31ik6cAVsgoPw"
+ nickname="IC"
+ subject="Haskell XMPP"
+ date="2012-10-27T05:54:53Z"
+ content="""
+Which xmpp library you've decided to use?
+"""]]
diff --git a/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_5_e4ba3568c4efd98f212dd47427a1cf47._comment b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_5_e4ba3568c4efd98f212dd47427a1cf47._comment
new file mode 100644
index 0000000000..272970caa2
--- /dev/null
+++ b/doc/design/assistant/blog/day_112__and_now_for_something_completely_different/comment_5_e4ba3568c4efd98f212dd47427a1cf47._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 5"
+ date="2012-10-27T06:08:44Z"
+ content="""
+I'm using http://hackage.haskell.org/package/network-protocol-xmpp
+
+While its author thinks \"its current design (session in an XMPP monad) is a failed mistake\", I've found it pretty good. Aside from the segfault problem, which we got fixed today.
+"""]]
diff --git a/doc/design/assistant/blog/day_113__notifier_work.mdwn b/doc/design/assistant/blog/day_113__notifier_work.mdwn
new file mode 100644
index 0000000000..920b48dfeb
--- /dev/null
+++ b/doc/design/assistant/blog/day_113__notifier_work.mdwn
@@ -0,0 +1,22 @@
+Built out the XMPP push notifier; around 200 lines of code.
+Haven't tested it yet, but it just might work. It's in the `xmpp` branch
+for now.
+
+I decided to send the UUID of the repo that was pushed to, otherwise
+peers would have to speculatively pull from every repo. A wrinkle in this
+is that not all git repos have a git-annex UUID. So it might notify that
+a push was sent to an unidentified repo, and then peers need to pull from
+every such repo. In the common case, there will only be one or a few such
+repos, at someplace like at github that doesn't support git-annex. I could
+send the URL, but there's no guarantee different clients have the same
+URLs for a git remote, and also sending the URL leaks rather more data than
+does a random UUID.
+
+Had a bit of a scare where it looked like I couldn't use the haskell
+`network-protocol-xmpp` package together with the `mtl` package that
+git-annex already depends on. With help from #haskell I found the way
+to get them co-existing, by using the PackageImports extension. Whew!
+
+Need to add configuration of the XMPP server to use in the webapp, and
+perhaps also a way to create `.git/annex/creds/notify-xmpp` from the
+command line.
diff --git a/doc/design/assistant/blog/day_114__xmpp.mdwn b/doc/design/assistant/blog/day_114__xmpp.mdwn
new file mode 100644
index 0000000000..617824d48e
--- /dev/null
+++ b/doc/design/assistant/blog/day_114__xmpp.mdwn
@@ -0,0 +1,56 @@
+Had to toss out my XMPP presence hack. Turns out that, at least in Google
+Talk, presence info is not sent to clients that have marked themselves
+unavailable, and that means the assistant would not see notifications, as it
+was nearly always marked unavailable as part of the hack.
+
+I tried writing a test program that uses XMPP personal eventing, only
+to find that Google Talk rejected my messages. I'm not 100% sure my
+messages were right, but I was directly copying the example in the RFC,
+and prosody accepted them. I could not seem to get a list of extensions out
+of Google Talk either, so I don't know if it doesn't support personal
+eventing, or perhaps only supports certian specific types of events.
+
+So, plan C... using XMPP [presence extended content](http://xmpp.org/rfcs/rfc6121.html#presence-extended).
+The assistant generates a presence message tagged "xa" (Extended Away),
+which hopefully will make it not seem present to clients.
+And to that presence message, I add my own XML element:
+
+	<git-annex xmlns='git-annex' push="uuid,uuid" />
+
+This is all entirely legal, and not at all a hack.
+(Aside from this not really being presence info.) Isn't XML fun?
+
+And plan C works, with Google Talk, and prosody. I've successfully gotten
+push notifications flowing over XMPP!
+
+----
+
+Spent some hours dealing with an unusual probolem: git-annex started
+segfaulting intermittently on startup with the new XMPP code. 
+
+Haskell code is not supposed to segfault..
+
+I think this was probably due to not using a bound thread for XMPP,
+so if haskell's runtime system recheduled its green thread onto a different
+OS thread during startup, when it's setting up TLS, it'd make gnuTLS very
+unhappy.
+
+So, fixed it to use a bound thread. Will wait and see if the crash is gone.
+
+----
+
+Re-enabled DBUS support, using a new version of the library that avoids the
+memory leak. Will need further changes to the library to support
+reconnecting to dbus.
+
+----
+
+Next will be a webapp configuration UI for XMPP. Various parts of the
+webapp will direct the user to set up XMPP, when appropriate, especially
+when the user sets up a cloud remote.
+
+To make XMPP sufficiently easy to configure, I need to check SRV records to
+find the XMPP server, which is an unexpected PITA because `getaddrinfo`
+can't do that. There are several haskell DNS libraries that I could use for
+SRV, or I could use the `host` command: 
+`host -t SRV _xmpp-client._tcp.gmail.com`
diff --git a/doc/design/assistant/blog/day_114__xmpp/comment_1_c2b0617a2fc3dc4f19a6be6947913842._comment b/doc/design/assistant/blog/day_114__xmpp/comment_1_c2b0617a2fc3dc4f19a6be6947913842._comment
new file mode 100644
index 0000000000..a391435c4d
--- /dev/null
+++ b/doc/design/assistant/blog/day_114__xmpp/comment_1_c2b0617a2fc3dc4f19a6be6947913842._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://phil.0x539.de/"
+ nickname="Philipp Kern"
+ subject="How to deal with offline messages being eaten?"
+ date="2012-11-09T14:05:30Z"
+ content="""
+How do you avoid eating up normal text messages when git-annex is the only client left? Granted, Google Talk does some additional magic so that it shows you the history when connecting with the web page client. But with other servers it would be inconvenient if new messages weren't saved as offline messages but sent to the dæmon instead.
+"""]]
diff --git a/doc/design/assistant/blog/day_114__xmpp/comment_2_d14375dfb5791615802dab3c5438f8e2._comment b/doc/design/assistant/blog/day_114__xmpp/comment_2_d14375dfb5791615802dab3c5438f8e2._comment
new file mode 100644
index 0000000000..716f7d99ad
--- /dev/null
+++ b/doc/design/assistant/blog/day_114__xmpp/comment_2_d14375dfb5791615802dab3c5438f8e2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 2"
+ date="2012-11-09T21:55:42Z"
+ content="""
+It does try to mark itself as extended away, but yes, I think this is a potential concern. If you find the assistant interacts badly with your other clients, you can certainly give it its own XMPP account.
+"""]]
diff --git a/doc/design/assistant/blog/day_114__xmpp/comment_3_6d72ea32c111e605be30ad2153fc71c9._comment b/doc/design/assistant/blog/day_114__xmpp/comment_3_6d72ea32c111e605be30ad2153fc71c9._comment
new file mode 100644
index 0000000000..6d2147d375
--- /dev/null
+++ b/doc/design/assistant/blog/day_114__xmpp/comment_3_6d72ea32c111e605be30ad2153fc71c9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://phil.0x539.de/"
+ nickname="Philipp Kern"
+ subject="comment 3"
+ date="2012-11-10T18:50:46Z"
+ content="""
+Sure, I could, as I'm operating my own server anyway. Others might not be willing to go to some random server and create another account, though.
+
+Reviewing RFC 6121: Did you try negative priorities for your resources already? It's possible that Gtalk does something weird but in theory they should be ignored for messages directed to non-qualified JIDs (i.e. without an explicit resource setting). Setting \"xa\" alone won't help you anything, it will only cause the others to see you as \"xa\" but that's a perfectly valid common chat status where you expect messages to be queued in the client until the user returns.
+"""]]
diff --git a/doc/design/assistant/blog/day_114__xmpp/comment_4_e51d6f854db5f9e74a1aa58bd8923795._comment b/doc/design/assistant/blog/day_114__xmpp/comment_4_e51d6f854db5f9e74a1aa58bd8923795._comment
new file mode 100644
index 0000000000..7320d03654
--- /dev/null
+++ b/doc/design/assistant/blog/day_114__xmpp/comment_4_e51d6f854db5f9e74a1aa58bd8923795._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 4"
+ date="2012-11-10T19:48:01Z"
+ content="""
+I hadn't tried it, but it looks like a very good idea. I will have to change my protocol a little bit as I currently sometimes send chat messages not directed to a specific client, in order to reach any clients using an account. To reach clients with a negative priority, chat messages have to be directed at the client.
+
+Ok, done; priority is set to -1 and all the XMPP messaging in git-annex still seems to work!
+
+I don't know though, that this entirely solves the problem. In particular, a regular xmpp client may decide to direct a chat message at a git-annex client, due to that being the only client connected. If this does become a problem, I suppose git-annex could buffer and re-send such messages when it sees a regular client connect. Or it could show them in the webapp, but that seems feature creep.
+"""]]
diff --git a/doc/design/assistant/blog/day_115__my_new_form.mdwn b/doc/design/assistant/blog/day_115__my_new_form.mdwn
new file mode 100644
index 0000000000..d44565084a
--- /dev/null
+++ b/doc/design/assistant/blog/day_115__my_new_form.mdwn
@@ -0,0 +1,17 @@
+Built a SRV lookup library that can use either `host` or ADNS.
+
+Worked on DBUS reconnection some more; found a FD leak in the dbus library,
+and wrote its long-suffering author, John Millikin (also the XMPP library
+author, so I've been bothering him a lot lately), who once again came
+through with a quick fix.
+
+Built a XMPP configuration form, that tests the connection to the server.
+Getting the wording right on this was hard, and it's probably still not
+100% right.
+
+[[!img /assistant/xmpp.png]]
+ 
+Pairing over XMPP is something I'm still thinking about. It's
+contingent on tunneling git over XMPP (actually not too hard),
+and getting a really secure XMPP connection (needs library improvements,
+as the library currently accepts any SSL certificate).
diff --git a/doc/design/assistant/blog/day_116__the_segfault.mdwn b/doc/design/assistant/blog/day_116__the_segfault.mdwn
new file mode 100644
index 0000000000..47633454a1
--- /dev/null
+++ b/doc/design/assistant/blog/day_116__the_segfault.mdwn
@@ -0,0 +1,25 @@
+Continuing to flail away at this XMPP segfault, which turned out not to be
+fixed by bound threads. I managed to make a fairly self-contained and small
+reproducible test case for it that does not depend on the network.
+Seems the bug is gonna be either in the Haskell binding for GNUTLS,
+or possibly in GNUTLS itself.
+
+Update: John was able to fix it using my testcase! It was a GNUTLS
+credentials object that went out of scope and got garbage collected.
+I think I was seeing the crash only with the threaded runtime because
+it has a separate garbage collection thread.
+
+----
+
+Arranged for the XMPP thread to restart when network connections
+change, as well as when the webapp configures it.
+
+Added an alert to nudge users to enable XMPP. It's displayed after adding a
+remote in the cloud.
+
+[[!img /assistant/xmppnudge.png]]
+
+----
+
+So, the first stage of XMPP is done. But so far all it does is push
+notification. Much more work to do here.
diff --git a/doc/design/assistant/blog/day_117__new_topologies.mdwn b/doc/design/assistant/blog/day_117__new_topologies.mdwn
new file mode 100644
index 0000000000..f62da3c5bb
--- /dev/null
+++ b/doc/design/assistant/blog/day_117__new_topologies.mdwn
@@ -0,0 +1,41 @@
+Back in [[day_85__more_foundation_work]], I wrote:
+
+> I suspect, but have not proven,
+> that the assistant is able to keep repos arranged in any shape of graph in
+> sync, as long as it's connected (of course) and each connection is
+> bi-directional. [And each node is running the assistant.]
+
+After today's work, many more graph topologies can be kept in sync -- the
+assistant now can keep repos in sync that are not directly connected, but
+must go through a central transfer point, which does not run the assistant
+at all. Major milestone!
+
+To get that working, as well as using XMPP push notifications, it turned
+out to need to be more agressive about pushing out changed location log
+information. And, it seems, that was the last piece that was missing.
+Although I narrowly avoided going down a blind alley involving sending
+transfer notifications over XMPP. Luckily, I came to my senses.
+
+----
+
+This month's focus was the cloud, and the month is almost done. And now
+the assistant can, indeed be used to sync over the cloud! I would have
+liked to have gotten on to implementing Amazon Glacier or Google Drive
+support, but at least the cloud fundamentals are there.
+
+Now that I have XMPP support, I'm tending toward going ahead and adding
+XMPP pairing, and git push over XMPP. This will open up lots of excellent
+use cases.
+
+So, how to tunnel git pushes over XMPP? Well, `GIT_SHELL` can be set to
+something that intercepts the output of `git-send-pack` and
+`git-receive-pack`, and that data can be tunneled through XMPP to connect
+them. Probably using XMPP ping.
+(XEP-0047: In-Band Bytestreams would be the right way ...
+but of course Google Talk doesn't support that extension.)
+
+XMPP requires ugly encoding that will bloat the data, but the data
+quantities are fairly small to sync up a few added or moved files
+(of course, we'll not be sending file contents over XMPP). Pairing with
+an large git repository over XMPP will need rather more bandwidth,
+of course.
diff --git a/doc/design/assistant/blog/day_118__monadic_discontinuity.mdwn b/doc/design/assistant/blog/day_118__monadic_discontinuity.mdwn
new file mode 100644
index 0000000000..758b26974a
--- /dev/null
+++ b/doc/design/assistant/blog/day_118__monadic_discontinuity.mdwn
@@ -0,0 +1,15 @@
+Spent most of the past day moving the assistant into a monad of its own
+that encapsulates all the communications channels for its threads. This
+involved modifiying nearly every line of code in the whole assistant.
+
+Typical change:
+
+[[!format haskell """
+handleConnection threadname st dstatus scanremotes pushnotifier = do
+        reconnectRemotes threadname st dstatus scanremotes (Just pushnotifier)
+                =<< networkRemotes st
+
+handleConnection = reconnectRemotes True =<< networkRemotes
+"""]]
+
+So, it's getting more readable..
diff --git a/doc/design/assistant/blog/day_119__time_for_testing.mdwn b/doc/design/assistant/blog/day_119__time_for_testing.mdwn
new file mode 100644
index 0000000000..adf1d0d411
--- /dev/null
+++ b/doc/design/assistant/blog/day_119__time_for_testing.mdwn
@@ -0,0 +1,12 @@
+Finished working the new assistant monad into all the assistant's code.
+I've changed 1870 lines of code in the past two days. It feels like more.
+While the total number of lines of code has gone up by around 100, the
+actual code size has gone *down*; the monad allowed dropping 3.4 kilobytes
+of manual variable threading complications. Or around 1% of a novel edited
+away, in other words.
+
+I don't seem to have broken anything, but I'm started an extensive test
+of all the assistant and webapp. So far, the bugs I've found were not
+introduced by my monadic changes. Fixed several bugs around adding
+removable drives, and a few other minor bugs. Plan to continue testing
+tomorrow.
diff --git a/doc/design/assistant/blog/day_11__freebsd.mdwn b/doc/design/assistant/blog/day_11__freebsd.mdwn
new file mode 100644
index 0000000000..92a3ef2896
--- /dev/null
+++ b/doc/design/assistant/blog/day_11__freebsd.mdwn
@@ -0,0 +1,50 @@
+I've been investigating how to make `git annex watch` work on
+FreeBSD, and by extension, OSX.
+
+One option is kqueue, which works on both operating systems, and allows
+very basic monitoring of file changes. There's also an OSX specific
+hfsevents interface.
+
+Kqueue is far from optimal for `git annex watch`, because it provides even
+less information than inotify (which didn't really provide everything I
+needed, thus the lsof hack). Kqueue doesn't have events for files being
+closed, only an event when a file is created. So it will be difficult for
+`git annex watch` to know when a file is done being written to and can be
+annexed. git annex will probably need to run lsof periodically to check when
+recently added files are complete. (hsevents shares this limitation)
+
+Kqueue also doesn't provide specific events when a file or directory is
+moved. Indeed, it doesn't provide specific events about what changed at
+all. All you get with kqueue is a generic "oh hey, the directory you're
+watching changed in some way", and it's up to you to scan it to work out
+how. So git annex will probably need to run `git ls-tree --others`
+to find changes in the directory tree. This could be expensive with large
+trees. (hsevents has per-file events on current versions of OSX)
+
+Despite these warts, I want to try kqueue first, since it's more portable
+than hfsevents, and will surely be easier for me to develop support for,
+since I don't have direct access to OSX.
+
+So I went to a handy Debian kFreeBSD porter box, and tried some kqueue
+stuff to get a feel for it. I got a python program that does basic
+directory monitoring with kqueue to work, so I know it's usable there.
+
+Next step was getting kqueue working from Haskell. Should be easy, there's
+a Haskell library already. I spent a while trying to get it to work on
+Debian kFreeBSD, but ran into a
+[problem](https://github.com/hesselink/kqueue/issues/1) that could be
+caused by the Debian kFreeBSD being different, or just a bug in the Haskell
+library. I didn't want to spend too long shaving this yak; I might install
+"real" FreeBSD on a spare laptop and try to get it working there instead.
+
+But for now, I've dropped down to C instead, and have a simple C program
+that can monitor a directory with kqueue. Next I'll turn it into a simple
+library, which can easily be linked into my Haskell code. The Haskell code
+will pass it a set of open directory descriptors, and it'll return the
+one that it gets an event on. This is necessary because kqueue doesn't
+recurse into subdirectories on its own.
+
+I've generally had good luck with this approach to adding stuff in Haskell;
+rather than writing a bit-banging and structure packing low level interface
+in Haskell, write it in C, with a simpler interface between C and
+Haskell.
diff --git a/doc/design/assistant/blog/day_120__test_day.mdwn b/doc/design/assistant/blog/day_120__test_day.mdwn
new file mode 100644
index 0000000000..548222989d
--- /dev/null
+++ b/doc/design/assistant/blog/day_120__test_day.mdwn
@@ -0,0 +1,2 @@
+Did a lot of testing, found and fixed 4 bugs with repository setup
+configurators. None of them were caused by the recent code reworking.
diff --git a/doc/design/assistant/blog/day_121__buddy_list.mdwn b/doc/design/assistant/blog/day_121__buddy_list.mdwn
new file mode 100644
index 0000000000..48ea1ffda3
--- /dev/null
+++ b/doc/design/assistant/blog/day_121__buddy_list.mdwn
@@ -0,0 +1,10 @@
+Got the XMPP client maintaining a list of buddies, including tracking which
+clients are present and away, and which clients are recognised as other
+git-annex assistant clients. This was fun, it is almost all pure
+functional code, which always makes me happy.
+
+Started building UI for XMPP pairing. So far, I have it showing a list of
+buddies who are also running git-annex (or not). The list even refreshes
+in real time as new buddies come online.
+
+[[!img /assistant/buddylist.png]]
diff --git a/doc/design/assistant/blog/day_122__xmpp_pairing.mdwn b/doc/design/assistant/blog/day_122__xmpp_pairing.mdwn
new file mode 100644
index 0000000000..8683827255
--- /dev/null
+++ b/doc/design/assistant/blog/day_122__xmpp_pairing.mdwn
@@ -0,0 +1,29 @@
+Reworked my XMPP code, which was still specific to push notification, into
+a more generic XMPP client, that's based on a very generic NetMessager
+class, that the rest of the assistant can access without knowing anything
+about XMPP.
+
+Got pair requests flowing via XMPP ping, over Google Talk! And when the
+webapp receives a pair request, it'll pop up an alert to respond. The rest
+of XMPP pairing should be easy to fill in from here.
+
+To finish XMPP pairing, I'll need git pull over XMPP, which is nontrivial,
+but I think I know basically how to do. And I'll need some way to represent
+an XMPP buddy as a git remote, which is all that XMPP pairing will really
+set up.
+
+It could be a git remote using an `xmpp:user@host` URI for the git url, but
+that would confuse regular git to no end (it'd think it was a ssh host),
+and probably need lots of special casing in the parts of git-annex that
+handle git urls too. Or it could be a git remote without an url set, and
+use another config field to represent the XMPP data. But then git wouldn't
+think it was a remote at all, which would prevent using "git pull
+xmppremote" at all, which I'd like to be able to use when implementing git
+pull over XMPP.
+
+Aha! The trick seems to be to leave the url unset in git config,
+but temporarily set it when pulling:
+
+	GIT_SSH=git-annex git git -c remote.xmppremote.url=xmpp:client pull xmppremote
+
+Runs git-annex with "xmpp git-upload-pack 'client'".. Just what I need.
diff --git a/doc/design/assistant/blog/day_122__xmpp_pairing/comment_1_e95efb23eb2e67e3f11a5c7de56424a7._comment b/doc/design/assistant/blog/day_122__xmpp_pairing/comment_1_e95efb23eb2e67e3f11a5c7de56424a7._comment
new file mode 100644
index 0000000000..990fa816ee
--- /dev/null
+++ b/doc/design/assistant/blog/day_122__xmpp_pairing/comment_1_e95efb23eb2e67e3f11a5c7de56424a7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://meep.pl/"
+ ip="193.219.28.34"
+ subject="git-remote-helpers"
+ date="2012-11-09T08:54:11Z"
+ content="""
+It seems that xmpp::user@host (with double colon) would cause git to try to use a remote-xmpp helper.
+Wouldn't it be a way to have the remote address (if not really URL) set and not be treated as ssh?
+
+"""]]
diff --git a/doc/design/assistant/blog/day_122__xmpp_pairing/comment_2_30e251e73146512bde8b2f69eddeef2e._comment b/doc/design/assistant/blog/day_122__xmpp_pairing/comment_2_30e251e73146512bde8b2f69eddeef2e._comment
new file mode 100644
index 0000000000..256b912426
--- /dev/null
+++ b/doc/design/assistant/blog/day_122__xmpp_pairing/comment_2_30e251e73146512bde8b2f69eddeef2e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 2"
+ date="2012-11-09T17:41:08Z"
+ content="""
+Thanks, I think that's exactly what I should do.
+"""]]
diff --git a/doc/design/assistant/blog/day_123__xmpp_insanity.mdwn b/doc/design/assistant/blog/day_123__xmpp_insanity.mdwn
new file mode 100644
index 0000000000..bfbc306690
--- /dev/null
+++ b/doc/design/assistant/blog/day_123__xmpp_insanity.mdwn
@@ -0,0 +1,49 @@
+Spent about 5 hours the other night in XMPP hell. At every turn Google Talk
+exhibited behavior that may meet the letter of the XMPP spec (or not), but
+varies between highly annoying and insane.
+
+By "insane", I mean this: If a presence message is directed from one client
+to another client belonging to that same user, randomly leaking that message
+out to other users who are subscribed is just a security hole waiting to
+happen. 
+
+Anyway, I came out of that with a collection of hacks that worked, but I
+didn't like. I was using directed presence for buddy-to-buddy pairing, and
+an IQ message hack for client-to-client pairing. 
+
+Today I got chat messages working instead, for both sorts of pairing. These
+chat messages have an empty body, which *should* prevent clients from
+displaying them, but they're sent directed to only git-annex clients
+anyway.
+
+----
+
+And XMPP pairing 100% works now! Of course, it doesn't know how to git pull
+over XMPP yet, but everything else works.
+
+Here's a real `.git/config` generated by the assistant after XMPP pairing.
+
+	[remote "joey"]
+	        url = 
+	        fetch = +refs/heads/*:refs/remotes/joey/*
+	        annex-uuid = 14f5e93e-1ed0-11e2-aa1c-f7a45e662d39
+	        annex-xmppaddress = joey@kitenet.net 
+
+----
+
+Fixed a typo that led to an infinite loop when adding a ssh git repo with the
+assistant. Only occurred when an absolute directory was specified, which 
+is why I didn't notice it before.
+
+----
+
+Security fix: Added a `GIT_ANNEX_SHELL_DIRECTORY` environment variable that
+locks down git-annex-shell to operating in only a single directory. The
+assistant sets that in ssh `authorized_keys` lines it creates. This
+prevents someone you pair with from being able to access any other git or
+git-annex repositories you may have.
+
+----
+
+Next up, more craziness. But tomorrow is Nov 6th, so you in the US already
+knew that..
diff --git a/doc/design/assistant/blog/day_124__git_push_over_xmpp_groundwork.mdwn b/doc/design/assistant/blog/day_124__git_push_over_xmpp_groundwork.mdwn
new file mode 100644
index 0000000000..ecb6023f20
--- /dev/null
+++ b/doc/design/assistant/blog/day_124__git_push_over_xmpp_groundwork.mdwn
@@ -0,0 +1,28 @@
+Laying the groundwork for git push over XMPP. BTW, the motivation for doing
+this now is that if the assistant can push git data peer-to-peer, users
+who are entirely using the cloud don't need to set up a git repo in the
+cloud somewhere. Instead, a single special remote in the cloud will be all
+they need. So this is a keystone in the assistant's cloud support.
+
+I'm building the following pipeline:
+
+	git push <--> git-annex xmppgit <--> xmppPush <-------> xmpp
+	                                                         |
+	git receive-pack <--> xmppReceivePack <---------------> xmpp
+
+A tricky part of this is `git-annex xmppgit`, which is run by `git push`
+rather than the usual `ssh`. Rather than speak XMPP itself, that feeds the
+data through the assistant daemon, using some special FDs that are set
+up by the assistant when it runs `git push`, and communicated via
+environment variables. I hoped to set up a pipe and not need it to do any
+work on its own, but short of using the linux-specific `splice(2)`, that
+doesn't seem possible. It also will receive the exit status of
+`git receive-pack` and propigate it to `git push`.
+
+Also built the IO sides of `xmppPush` and `xmppReceivePack` although these
+are not tested. The XMPP sides of them come next.
+
+----
+
+Stuffing lots of git-annex branded USB keys into envelopes tonight, while
+watching the election coverage.
diff --git a/doc/design/assistant/blog/day_125__xmpp_push_continues.mdwn b/doc/design/assistant/blog/day_125__xmpp_push_continues.mdwn
new file mode 100644
index 0000000000..010ab14dad
--- /dev/null
+++ b/doc/design/assistant/blog/day_125__xmpp_push_continues.mdwn
@@ -0,0 +1,15 @@
+I've finished building the XMMP side of git push over XMPP. Now I only
+have to add code to trigger these pushes. And of course, fix all the bugs,
+since none of this has been tested at all.
+
+Had to deal with some complications, like handling multiple clients that
+all want to push at the same time. Only one push is handled at a time;
+messages for others are queued. Another complication I don't deal with yet
+is what to do if a client stops responding in the middle of a push. It
+currently will wait forever for a message from the client; instead it
+should time out.
+
+----
+
+Jimmy got the OSX builder working again, despite my best attempts to add
+dependencies and break it.
diff --git a/doc/design/assistant/blog/day_126__mr_watson_come_here.mdwn b/doc/design/assistant/blog/day_126__mr_watson_come_here.mdwn
new file mode 100644
index 0000000000..0dd600cc89
--- /dev/null
+++ b/doc/design/assistant/blog/day_126__mr_watson_come_here.mdwn
@@ -0,0 +1,52 @@
+I'm stunned and stoked to have gotten git push over XMPP working today.
+And am nearly out of steam, it was a wild ride..
+
+	To xmpp::joey@kitenet.net
+	  * [new branch]      master -> refs/xmpp/newmaster
+
+The surprising part is how close my initial implementation came to just
+working on the first try. It had around 3 bugs, which took hours of staring
+at debugging output to find:
+
+1. The git push action was run in the same thread as the XMPP
+   client, which prevented the client from continuing to run and relaying
+   messages.
+2. The git-receive-pack side waited on the wrong thread, so didn't
+   notice when the program was done.
+3. I accidentally used the wrong attribute name when sending a ReceivePackDone
+   message.
+
+But all in all, it just worked.
+
+Here's a sample of the actual data sent when one file is added to the
+repository (also includes the corresponding update to the git-annex branch):
+
+	MDA4NjhhMmNmOGZjMWE3MTlkOGVjOWVmOWZiMGZiNjVlODc2NjQ1NDAyMTAgODIwNTZjMDM4
+	ZjU2YzE1ODdjYzllOWRhNzQzMzU0YjE4NzNjZWJlOSByZWZzL3htcHAvbmV3bWFzdGVyACBy
+	ZXBvcnQtc3RhdHVzIHNpZGUtYmFuZC02NGswMDAw
+
+	UEFDSwAAAAIAAAADnAx4nJXLTQ4CIQxA4T2n4AKaAqVAYoxL4y2gU+Jo5iczdeHtnSu4eMm3
+	ebqJ2NwgSCLmNkTBlKFCYwwhoHOtQ+scqZCwWesms9pcPffc2dXkypCFi/TSG/RGUXIiwojg
+	HZj60eey2cciX3uXfbeX18Hbe1SZRc9HV+tC9FgyJW9PgACGl2kaVeXfz/wArHQ81qMGeJwz
+	NDIAAoVUI4ZZB9RW1E8NtXp5t77/fn3hw41cl2MNIbIZqTk5+Qwerw+aJX2INjsffYndtdCz
+	5mZWLDdUQV5qeVpmDtCQnx/3/6s40+Q4P/7O+Y4ShS+1Ad83AwC6CirftAt4nK3MsRGDMAwF
+	0IkcSVgSdpkidzRUmcDWBy4pSAEFl+mzRN4A77a9Tmr7vlz06e8lzoPmmb5Mz+k+mD/SkTkl
+	eFHPq9eqQ+nSzFsWaDFnFmCMCEOvHgLrCrQxS7AWdvUVhv9uPwHxMbfumlvWdco1RLL4wSQF
+	g0uFFOKu3Q==
+
+Git said this push took 385 bytes; after base64 encoding to transport it over
+XMPP as shown above, it needs 701 bytes, and the XMPP envelope and encryption
+adds more overhead (although the XMPP connection may also be compressed?)
+
+Not the most efficient git transport, but still a practical one!
+
+----
+
+Big thanks by the way to meep, who posted a comment reminding me about
+`git-remote-helpers`. This was the right thing to use for XMPP over git,
+it lets the git remote be configured with `url = xmpp::user@host`.
+
+----
+
+Next, I need to get the assistant to use this for syncing. Currently, it only
+pushes a test branch.
diff --git a/doc/design/assistant/blog/day_126__mr_watson_come_here/comment_1_ee1361e6b235f4e1c00596ba516b519a._comment b/doc/design/assistant/blog/day_126__mr_watson_come_here/comment_1_ee1361e6b235f4e1c00596ba516b519a._comment
new file mode 100644
index 0000000000..47766dc778
--- /dev/null
+++ b/doc/design/assistant/blog/day_126__mr_watson_come_here/comment_1_ee1361e6b235f4e1c00596ba516b519a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5vDem1yeIu6uith5pxfb4mdKdIWVJpCs"
+ nickname="Louis"
+ subject="Base64 vs. yEnc"
+ date="2012-11-12T02:02:17Z"
+ content="""
+Would yEnc be a suitable alternative to base64 for encoding the binary transfers over XMPP?  Or why not?
+
+Thanks!
+"""]]
diff --git a/doc/design/assistant/blog/day_126__mr_watson_come_here/comment_2_8eb366ae7efb347bd3bbd9a98e0821b3._comment b/doc/design/assistant/blog/day_126__mr_watson_come_here/comment_2_8eb366ae7efb347bd3bbd9a98e0821b3._comment
new file mode 100644
index 0000000000..6f76ec4c8e
--- /dev/null
+++ b/doc/design/assistant/blog/day_126__mr_watson_come_here/comment_2_8eb366ae7efb347bd3bbd9a98e0821b3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 2"
+ date="2012-11-12T02:39:19Z"
+ content="""
+AFAIK, yenc can use xml characters like &lt; and &gt; in its encoding.
+"""]]
diff --git a/doc/design/assistant/blog/day_127__xmpp_syncs.mdwn b/doc/design/assistant/blog/day_127__xmpp_syncs.mdwn
new file mode 100644
index 0000000000..7f95f87e39
--- /dev/null
+++ b/doc/design/assistant/blog/day_127__xmpp_syncs.mdwn
@@ -0,0 +1,35 @@
+I got full-on git-annex assistant syncing going over XMPP today!
+
+How well does it work? Well, I'm at the cabin behind a dialup modem. I have
+two repos that can only communicate over XMPP. One uses my own XMPP server,
+and the other uses a Google Talk account. I make a file in one repo, and
+switch windows to the other, and type `ls`, and the file (not its content
+tho..) has often already shown up. So, it's about as fast as syncing over
+ssh, although YMMV.
+
+----
+
+Refactored the git push over XMPP code rather severely. It's quite a
+lot cleaner now.
+
+----
+
+Set XMPP presence priority to a negative value, which will hopefully
+prevent git-annex clients that share a XMPP account with other clients from
+intercepting chat messages. Had to change my XMPP protocol some to deal
+with this.
+
+----
+
+Some webapp UI work. When showing the buddy list, indicate which buddies
+are already paired with. 
+
+After XMPP pairing, it now encourages setting up a shared cloud repository.
+
+[[!img /assistant/xmpppairingend.png]]
+
+I still need to do more with the UI after XMPP pairing, to help the paired
+users configure a shared cloud transfer remote. Perhaps the thing to do is
+for the ConfigMonitor to notice when a git push adds a new remote,
+and pop up an alert suggesting the user enable it. Then one user
+can create the repository, and the other one enable it.
diff --git a/doc/design/assistant/blog/day_128__last_xmpp_day.mdwn b/doc/design/assistant/blog/day_128__last_xmpp_day.mdwn
new file mode 100644
index 0000000000..2c7d70accc
--- /dev/null
+++ b/doc/design/assistant/blog/day_128__last_xmpp_day.mdwn
@@ -0,0 +1,49 @@
+I hope I'm nearly at the end of this XMPP stuff after today. Planning a new
+release tomorrow.
+
+----
+
+Split up the local pairing and XMPP pairing UIs, and wrote a
+[[/assistant/share_with_a_friend_walkthrough]].
+
+----
+
+Got the XMPP push code to time out if expected data doesn't arrive within
+2 minutes, rather than potentially blocking other XMPP push forever if 
+the other end went away. 
+
+I pulled in the Haskell
+[async](http://hackage.haskell.org/package/async) library for this,
+which is yes, yet another library, but one that's now in the haskell platform.
+It's worth it, because of how nicely it let me implement IO actions that
+time out.
+
+[[!format haskell """
+runTimeout :: Seconds -> IO a -> IO (Either SomeException a)
+runTimeout secs a = do
+        runner <- async a
+        controller <- async $ do
+                threadDelaySeconds secs
+                cancel runner
+        cancel controller `after` waitCatch runner
+"""]]
+
+This would have been 20-50 lines of gnarly code without async, and I'm sure
+I'll find more uses for async in the future.
+
+----
+
+Discovered that the XMPP push code could deadlock, if both clients started
+a push to the other at the same time. I decided to fix this by allowing
+each client to run both one push and one receive-pack over XMPP at the same
+time.
+
+----
+
+Prevented the transfer scanner from trying to queue transfers to XMPP remotes.
+
+----
+
+Made XMPP pair requests that come from the same account we've already
+paired with be automatically accepted. So once you pair with one device,
+you can easily add more.
diff --git a/doc/design/assistant/blog/day_128__last_xmpp_day/comment_1_fd8c1d6358cb50f4dad8ba11d33d861f._comment b/doc/design/assistant/blog/day_128__last_xmpp_day/comment_1_fd8c1d6358cb50f4dad8ba11d33d861f._comment
new file mode 100644
index 0000000000..add2cf313a
--- /dev/null
+++ b/doc/design/assistant/blog/day_128__last_xmpp_day/comment_1_fd8c1d6358cb50f4dad8ba11d33d861f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqVi9eQjkZt8EC-byTXJ8TnY7VyOHzW2s"
+ nickname="Zahary"
+ subject="Pairing on the local network"
+ date="2012-11-12T11:39:17Z"
+ content="""
+Joey, How does pairing on the local network work btw?
+Now that you have experience intercepting and relaying the git pack output maybe you can use UDP broadcast on the local network for a truly fast sync.
+With dropbox, I'm often syncing working copies of software projects between several VMs so I can test the code on all platforms before committing. I've found that to be faster (for builds) then using a VM shared folders, network shares, etc.
+"""]]
diff --git a/doc/design/assistant/blog/day_128__last_xmpp_day/comment_2_43664b73c71c41d71bc95e665f128106._comment b/doc/design/assistant/blog/day_128__last_xmpp_day/comment_2_43664b73c71c41d71bc95e665f128106._comment
new file mode 100644
index 0000000000..3a83186184
--- /dev/null
+++ b/doc/design/assistant/blog/day_128__last_xmpp_day/comment_2_43664b73c71c41d71bc95e665f128106._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://phil.0x539.de/"
+ nickname="Philipp Kern"
+ subject="comment 2"
+ date="2012-11-12T11:50:42Z"
+ content="""
+Developing something new based on IPv4 UDP broadcast seems to be insane. IPv6 link-local multicast should be available virtually anywhere. XMPP relies on TCP and a central server to guarantee that a single packet is not split up, which would need quite some protocol engineering to get right over lossy UDP (e.g. segmentation, flow control, congestion avoidance). But TCP as discovered using mDNS might work… Still needs some kind of authentication / encryption, though.
+"""]]
diff --git a/doc/design/assistant/blog/day_128__last_xmpp_day/comment_3_d369b04f686009a9dbb57b999107a55e._comment b/doc/design/assistant/blog/day_128__last_xmpp_day/comment_3_d369b04f686009a9dbb57b999107a55e._comment
new file mode 100644
index 0000000000..951cc7e057
--- /dev/null
+++ b/doc/design/assistant/blog/day_128__last_xmpp_day/comment_3_d369b04f686009a9dbb57b999107a55e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqVi9eQjkZt8EC-byTXJ8TnY7VyOHzW2s"
+ nickname="Zahary"
+ subject="Jingle"
+ date="2012-11-12T12:00:50Z"
+ content="""
+Also, you probably know about Jingle:
+http://en.wikipedia.org/wiki/Jingle_(protocol)
+
+What are you thoughts about it? I guess it would have been harder to use the Google C++ library from Haskell and full mesh peer-to-peer is certainly more complicated than using the XMPP server to effectively multicast to all paired clients.
+"""]]
diff --git a/doc/design/assistant/blog/day_128__last_xmpp_day/comment_4_095855d301e7ccd3689ffe507cfb63ee._comment b/doc/design/assistant/blog/day_128__last_xmpp_day/comment_4_095855d301e7ccd3689ffe507cfb63ee._comment
new file mode 100644
index 0000000000..0e5295ad2e
--- /dev/null
+++ b/doc/design/assistant/blog/day_128__last_xmpp_day/comment_4_095855d301e7ccd3689ffe507cfb63ee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqVi9eQjkZt8EC-byTXJ8TnY7VyOHzW2s"
+ nickname="Zahary"
+ subject="@Philipp Kern"
+ date="2012-11-12T12:13:33Z"
+ content="""
+Alright, I stand corrected, although I'm aware of some libraries that have already solved the problem so you don't really have to implement reliable UDP from scratch: http://code.google.com/p/openpgm/
+"""]]
diff --git a/doc/design/assistant/blog/day_128__last_xmpp_day/comment_5_da7b0586b0b28e1e0fe4126f6543a7bc._comment b/doc/design/assistant/blog/day_128__last_xmpp_day/comment_5_da7b0586b0b28e1e0fe4126f6543a7bc._comment
new file mode 100644
index 0000000000..f10326a3c9
--- /dev/null
+++ b/doc/design/assistant/blog/day_128__last_xmpp_day/comment_5_da7b0586b0b28e1e0fe4126f6543a7bc._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://phil.0x539.de/"
+ nickname="Philipp Kern"
+ subject="comment 5"
+ date="2012-11-12T12:50:26Z"
+ content="""
+To quote the website (emphasis mine):
+> PGM is appropriate for applications that require duplicate-free multicast data delivery from multiple sources to multiple receivers. *PGM does not support acknowledged delivery, nor does it guarantee ordering of packets from multiple senders.*
+"""]]
diff --git a/doc/design/assistant/blog/day_128__last_xmpp_day/comment_6_2f9ba367e19d77bf52f372b6f0f5938a._comment b/doc/design/assistant/blog/day_128__last_xmpp_day/comment_6_2f9ba367e19d77bf52f372b6f0f5938a._comment
new file mode 100644
index 0000000000..e73c4c071d
--- /dev/null
+++ b/doc/design/assistant/blog/day_128__last_xmpp_day/comment_6_2f9ba367e19d77bf52f372b6f0f5938a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 6"
+ date="2012-11-12T14:43:32Z"
+ content="""
+For local pairing, multicast UDP is used for discovery and authentication, and then all data transfers take place over ssh.
+"""]]
diff --git a/doc/design/assistant/blog/day_129__release.mdwn b/doc/design/assistant/blog/day_129__release.mdwn
new file mode 100644
index 0000000000..553b0e91f3
--- /dev/null
+++ b/doc/design/assistant/blog/day_129__release.mdwn
@@ -0,0 +1,4 @@
+Cut a new release today. It's been nearly a month since the last one, and a
+large number of improvements.. Be sure to read the
+[[/assistant/release_notes]] if upgrading. All the standalone builds are
+updated already.
diff --git a/doc/design/assistant/blog/day_12__freebsd_redux.mdwn b/doc/design/assistant/blog/day_12__freebsd_redux.mdwn
new file mode 100644
index 0000000000..5ec446c9de
--- /dev/null
+++ b/doc/design/assistant/blog/day_12__freebsd_redux.mdwn
@@ -0,0 +1,23 @@
+Followed my plan from yesterday, and wrote a simple C library to interface
+to `kqueue`, and Haskell code to use that library. By now I think I
+understand kqueue fairly well -- there are some very tricky parts to the
+interface.
+
+But... it still didn't work. After building all this, my code was
+failing the same way that the
+[haskell kqueue library failed](https://github.com/hesselink/kqueue/issues/1)
+yesterday. I filed a [bug report with a testcase]().
+
+Then I thought to ask on #haskell. Got sorted out in quick order! The
+problem turns out to be that haskell's runtime has a periodic SIGALARM,
+that is interrupting my kevent call. It can be worked around with `+RTS -V0`,
+but I put in a fix to retry to kevent when it's interrupted.
+
+And now `git-annex watch` can detect changes to directories on BSD and OSX!
+
+Note: I said "detect", not "do something useful in response to". Getting
+from the limited kqueue events to actually staging changes in the git repo
+is going to be another day's work. Still, brave FreeBSD or OSX users
+might want to check out the `watch` branch from git and see if 
+`git annex watch` will at least *say* it sees changes you make to your
+repository.
diff --git a/doc/design/assistant/blog/day_12__freebsd_redux/comment_1_5da32cf53f1de27bfe6cec2d294db3e1._comment b/doc/design/assistant/blog/day_12__freebsd_redux/comment_1_5da32cf53f1de27bfe6cec2d294db3e1._comment
new file mode 100644
index 0000000000..253af9e7c5
--- /dev/null
+++ b/doc/design/assistant/blog/day_12__freebsd_redux/comment_1_5da32cf53f1de27bfe6cec2d294db3e1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2012-06-19T06:53:26Z"
+ content="""
+heh, yea, it's detecting changes on OSX ;)
+"""]]
diff --git a/doc/design/assistant/blog/day_12__freebsd_redux/comment_2_696d6e22034acf5bb60d80124b72ef2f._comment b/doc/design/assistant/blog/day_12__freebsd_redux/comment_2_696d6e22034acf5bb60d80124b72ef2f._comment
new file mode 100644
index 0000000000..9f3e34adb9
--- /dev/null
+++ b/doc/design/assistant/blog/day_12__freebsd_redux/comment_2_696d6e22034acf5bb60d80124b72ef2f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2012-06-19T07:01:26Z"
+ content="""
+issues with the watch command on OSX, it seems that there is a race condition somewhere. I dumped a few iso's into an annex and it only annexed the smaller files (checksums) and the bigger ones (the iso's) just got made read only. also do you want these bugs to be logged here or in the bugs section?
+"""]]
diff --git a/doc/design/assistant/blog/day_12__freebsd_redux/comment_3_5ab7808595e3b51ca4141d15fdd44743._comment b/doc/design/assistant/blog/day_12__freebsd_redux/comment_3_5ab7808595e3b51ca4141d15fdd44743._comment
new file mode 100644
index 0000000000..6bcba4d3e9
--- /dev/null
+++ b/doc/design/assistant/blog/day_12__freebsd_redux/comment_3_5ab7808595e3b51ca4141d15fdd44743._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="chris"
+ subject="Thanks"
+ date="2014-12-25T11:58:55Z"
+ content="""
+Thanks
+"""]]
diff --git a/doc/design/assistant/blog/day_130__what_now.mdwn b/doc/design/assistant/blog/day_130__what_now.mdwn
new file mode 100644
index 0000000000..4fc3fe53ca
--- /dev/null
+++ b/doc/design/assistant/blog/day_130__what_now.mdwn
@@ -0,0 +1,36 @@
+Dealt with post-release feedback deluge. There are a couple weird bugs that
+I don't understand yet. OSX app is still not working everywhere.
+
+----
+
+Got the list of repositories in the webapp to update automatically when
+repositories are added, including when syncing with a remote causes
+repositories to be discovered.
+
+----
+
+I need a plan for the rest of the month. It feels right to focus on more
+cloud storage support. Particularly because all the cloud providers
+supported so far are ones that, while often being best of breed, also cost
+money. To finish up the cloud story, need support for some free ones.
+
+Looking at the results of the [[polls/prioritizing_special_remotes]]
+poll, I suspect that free storage is a large part of why Google Drive got
+so many votes. Soo, since there is not yet a Haskell library for Google
+Drive, rather than spending a large chunk of time writing one, I hope to
+use a [Haskell WebDAV library](http://hackage.haskell.org/package/DAV)
+that my friend Clint recently wrote. A generic
+WebDAV special remote in git-annex will provide much better support for
+box.com (which has 5 to 50 gb free storage), as well as all the 
+[OwnCloud providers](http://owncloud.org/providers/), at least one of which
+provides 5 gb free storage.
+
+If I have time left this month after doing that, I'd be inclined to do
+Amazon Glacier. People have already gotten that working with git-annex, but
+a proper special remote should be better/easier, and will allow integrating
+support for it into the assistant, which should help deal with its long
+retrieval delays. And since, if you have a lot of data
+archived in Glacier, you will only want to pull out a few files at a time,
+this is another place besides mobile phones where a [[partial_content]]
+retrieval UI is needed. Which is on the roadmap to be worked on next
+month-ish. Synergy, here I come. I hope.
diff --git a/doc/design/assistant/blog/day_130__what_now/comment_1_402f00cc034351d8253a797dd4de55bf._comment b/doc/design/assistant/blog/day_130__what_now/comment_1_402f00cc034351d8253a797dd4de55bf._comment
new file mode 100644
index 0000000000..ec2158c226
--- /dev/null
+++ b/doc/design/assistant/blog/day_130__what_now/comment_1_402f00cc034351d8253a797dd4de55bf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7AuSfii_tCkLyspL6Mr0ATlO6OxLNYOo"
+ nickname="Georg"
+ subject="definitely glacier would be cool"
+ date="2012-11-14T08:51:40Z"
+ content="""
+Because having it available as an archival system to move stuff over that you don't expect to constantly need available. But what would be needed is a way to prevent the assistant to pull all the data from there back on your clients. This probably allready is doable with preferred content, but probably needs an easier way to set up - when I tried the new version it immediately started to pull all the stuff from my server repository that I moved there to get my disk space free. So my scenario would be \"move stuff to archives and when I drop it afterwards, keep it dropped locally if at least one archival server has it\".
+"""]]
diff --git a/doc/design/assistant/blog/day_131__webdav_groundwork.mdwn b/doc/design/assistant/blog/day_131__webdav_groundwork.mdwn
new file mode 100644
index 0000000000..795acfea10
--- /dev/null
+++ b/doc/design/assistant/blog/day_131__webdav_groundwork.mdwn
@@ -0,0 +1,28 @@
+Read up on WebDAV, and got the haskell library working. Several hours
+were wasted by stumbling over a bug in the library, that requires a
+carefully crafted XML document to prevent. Such a pity about things
+like DAV (and XMPP) being designed back when people were gung-ho about
+XML.. but we're stuck with them now.
+
+Now I'm able to send and receive files to box.com using the library. Trying to
+use an OwnCloud server, though, I get a most strange error message, which
+looks to be coming from deep in the HTTPS library stack: "invalid IV length"
+
+The haskell DAV library didn't have a way to delete files. I've added one
+and sent off a patch.
+
+Roughed in a skeleton of a webdav special remote. Doesn't do anything yet.
+Will soon.
+
+Factored out a Creds module from parts of the S3 special remote and XMPP
+support, that all has to do with credentials storage. Using this for webdav
+creds storage too.
+
+Will also need to factor out the code that's currently in the directory
+special remote, for chunking of files.
+
+----
+
+PS: WebDAV, for all its monstrously complicated feature set, lacks one obvious
+feature: The ability to check how much free space is available to store
+files. Eyeroll.
diff --git a/doc/design/assistant/blog/day_132__webdav_continued.mdwn b/doc/design/assistant/blog/day_132__webdav_continued.mdwn
new file mode 100644
index 0000000000..075a5d8c41
--- /dev/null
+++ b/doc/design/assistant/blog/day_132__webdav_continued.mdwn
@@ -0,0 +1,22 @@
+Two releases of the Haskell DAV library today. First release had my changes
+from yesterday. Then I realized I'd also need support for making WebDAV
+"collections" (subdirectories), and sent Clint a patch for that too, as
+well as a patch for querying DAV properties, and that was 0.2.
+Got it into Debian unstable as well. Should have everything I'll need now.
+
+The webdav special remote is now working! Still todo:
+Encryption support, progress bars, large file chunking, and webapp
+configurators. But already, it's a lot nicer than the old approach of using
+davfs2, which was really flakey and slow with large data volumes.
+
+I did notice, though, that uploading a 100 mb file made the process use 100
+mb of memory. This is a problem I've struggled with earlier with S3, the
+Haskell http libraries are prevented from streaming data by several parts
+of the protocol that cause the data to be accessed more than once. I guess
+this won't be a problem for DAV though, since it'll probably be chunking
+files anyway.
+
+---
+
+Mailed out all my Kickstarter USB key rewards, and ordered
+the T-shirts too.
diff --git a/doc/design/assistant/blog/day_133__webdav_working.mdwn b/doc/design/assistant/blog/day_133__webdav_working.mdwn
new file mode 100644
index 0000000000..d71f258520
--- /dev/null
+++ b/doc/design/assistant/blog/day_133__webdav_working.mdwn
@@ -0,0 +1,31 @@
+Worked on webdav special remotes all day. 
+
+* Got encryption working,
+  after fixing an amusing typo that made `initremote` for webdav throw away the
+  encryption configuration and store files unencrypted.
+* Factored out parts of the directory special remote that had to do with file
+  chunking, and am using that for webdav. This refactoring was painful.
+
+At this point, I feel the webdav special remote works better than the old
+davfs2 + directory special remote hack. While webdav doesn't yet have
+progress info for uploads, that info was pretty busted anyway with
+davfs2 due to how it buffers files. So ... I've merged webdav into master!
+
+-----
+
+Tomorrow, webapp configurators for Box.com and any other webdav supporting
+sites I can turn up and get to work..
+
+-----
+
+A while ago I made git-annex not store login credentials in git for special
+remotes, when it's only encrypting them with a shared cipher. The
+rationalle was that you don't want to give everyone who gets ahold of your
+git repo (which includes the encryption key) access to your passwords,
+Amazon S3 account, or whatever. I'm now considering adding a checkbox (or
+command-line flag) that allows storing the login credentials in git,
+if the user wants to. While using public key crypto is the real solution
+(and is fully supported by git-annex (but not yet configurable in the
+webapp)), this seems like a reasonable thing to do in some circumstances,
+like when you have a Box.com account you really do want to share with
+the people who use the git repo.
diff --git a/doc/design/assistant/blog/day_134__box.com_configurator.mdwn b/doc/design/assistant/blog/day_134__box.com_configurator.mdwn
new file mode 100644
index 0000000000..1156336404
--- /dev/null
+++ b/doc/design/assistant/blog/day_134__box.com_configurator.mdwn
@@ -0,0 +1,8 @@
+I needed an easy day, and I got one. Configurator in the webapp for Box.com
+came together really quickly and easily, and worked on the first try.
+
+Also filed a [bug](https://github.com/vincenthz/hs-cryptocipher/issues/21)
+on the Haskell library that is failing on portknox.com's SSL certificate.
+That site is the only OwnCloud provider currently offering free WebDAV
+storage. Will hold off on adding OwnCloud to the webapp's cloud provider lists
+until that's fixed.
diff --git a/doc/design/assistant/blog/day_135__progress_revisited.mdwn b/doc/design/assistant/blog/day_135__progress_revisited.mdwn
new file mode 100644
index 0000000000..63e3c4bf24
--- /dev/null
+++ b/doc/design/assistant/blog/day_135__progress_revisited.mdwn
@@ -0,0 +1,37 @@
+Unexpectedly today, I got progress displays working for uploads via WebDAV.
+
+The roadblock had been that the interface of for uploading to S3 and WebDAV
+is something like `ByteString -> IO a`. Which doesn't provide any hook to
+update a progress display as the ByteString is consumed.
+
+My solution to this was to create a `hGetContentsObserved`, that's similar
+to `hGetContents`, but after reading each 64kb chunk of data from the
+Handle to populate the ByteString, it runs some observing action. So when
+the ByteString is streamed, as each chunk is consumed, the observer
+runs. I was able to get this to run in constant space, despite not having
+access to some of the ByteString internals that `hGetContents` is built
+with.
+
+So, a little scary, but nice. I am curious if there's not a better way
+to solve this problem hidden in a library somewhere. Perhaps it's another
+thing that conduit solves somehow? Because if there's not, my solution
+probably deserves to be put into a library. Any Haskell folk know?
+
+----
+
+Used above to do progress displays for uploads to S3. Also did progress
+display to console on download from S3. Now very close to being done
+with [[progressbars]]. Finally. Only bup and hook remotes need progress
+work.
+
+----
+
+Reworked the core crypto interface, to better support streaming data through
+gpg. This allowed fixing both the directory and webdav special remotes to
+not buffer whole files in memory when retrieving them as chunks from the
+remote.
+
+-----
+
+Spent some time dealing with API changes in Yesod and Conduit. Some of them
+annoyingly gratuitous.
diff --git a/doc/design/assistant/blog/day_136__misc.mdwn b/doc/design/assistant/blog/day_136__misc.mdwn
new file mode 100644
index 0000000000..5a14156d58
--- /dev/null
+++ b/doc/design/assistant/blog/day_136__misc.mdwn
@@ -0,0 +1,14 @@
+Changed how the directory and webdav special remotes store content.
+The new method uses less system calls, is more robust, and leaves any
+partially transferred key content in a single tmp directory, which
+will make it easier to clean that out later.
+
+Also found & fixed a cute bug in the directory special remote when the
+chunksize is set to a smaller value than the ByteString chunk size, that
+caused it to loop forever creating empty files.
+
+----
+
+Added an embedcreds=yes option when setting up special remotes. 
+Will put UI for it into the webapp later, but rather than work on that
+tomorrow, I plan to work on glacier.
diff --git a/doc/design/assistant/blog/day_137__Glacier.mdwn b/doc/design/assistant/blog/day_137__Glacier.mdwn
new file mode 100644
index 0000000000..4e6787eb5c
--- /dev/null
+++ b/doc/design/assistant/blog/day_137__Glacier.mdwn
@@ -0,0 +1,30 @@
+Got Amazon Glacier working as a full-fledged special remote.
+
+(Well, I think it works... Since it takes 4 hours to get data out,
+which is longer than the time it took me to sign up for Glacier and
+write the special remote ... I've yet to fully test it!)
+
+Thanks to Robie Basak for writing glacier-cli, and developing the intial
+hook remote support. Also thanks to Peter Todd for pointing out that
+Glacier cannot store empty files, which had to be worked around in the
+special remote.
+
+Of course the 4 hour delay on retreval makes Glacier interesting. For now,
+you have to run "git annex get" twice, once to queue the retrieval, and a
+second time in 4 hours to get the file(s). There is a helpful example in
+[[tips/using_Amazon_Glacier]].
+
+The real complication though, is that Glacier's inventories take a long
+time to get, and can be out of date. So glacier-cli caches inventory info.
+I didn't feel comfortable making git-annex trust that information,
+so it'll refuse to trust that Glacier has a copy of a file when dropping
+it. There's a `--trust-glacier` switch to override this default paranoid
+behavior when dropping files.
+
+----
+
+Tomorrow ... er, tomorrow is Thanksgiving trip start.
+
+Next weekend: Webapp configurator for glacier, and maybe something
+to get the assistant to detect when jobs are complete and finish
+retrievals from Glacier, automatically.
diff --git a/doc/design/assistant/blog/day_138__back.mdwn b/doc/design/assistant/blog/day_138__back.mdwn
new file mode 100644
index 0000000000..7c2b4ec459
--- /dev/null
+++ b/doc/design/assistant/blog/day_138__back.mdwn
@@ -0,0 +1,25 @@
+Added a configurator for Glacier repositories to the webapp. That was the last
+cloud repository configurator that was listed in the webapp and wasn't
+done. Indeed, just two more repository configurators remain to be filled in:
+phone and NAS.
+
+By default, Glacier repositories are put in a new "small archive" group.
+This makes only files placed in "archive" directories be sent to Glacier
+(as well as being dropped from clients), unlike the full archive group
+which archives all files. Of course you can change this setting, but
+avoiding syncing all data to Glacier seemed like a good default, especially
+since some are still worried about Glacier's pricing model.
+
+Fixed several bugs in the handling of archive directories, and 
+the webapp makes a toplevel archive directory when an archive remote is
+created, so the user can get on with using it.
+
+Made the assistant able to drop local files immediately after transferring
+them to glacier, despite not being able to trust glacier's inventory.
+This was accomplished by making the transferrer, after a successful upload,
+indicate that it trusts the remote it just uploaded to has the file,
+when it checks if the file should be dropped.
+
+Only thing left to do for glacier is to make the assistant retry failed
+downloads from it after 4 hours, or better, as soon as they become
+available.
diff --git a/doc/design/assistant/blog/day_138__back/comment_1_65a8499b284bed38d2bde1886a54a311._comment b/doc/design/assistant/blog/day_138__back/comment_1_65a8499b284bed38d2bde1886a54a311._comment
new file mode 100644
index 0000000000..5bd94d13eb
--- /dev/null
+++ b/doc/design/assistant/blog/day_138__back/comment_1_65a8499b284bed38d2bde1886a54a311._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmnG4EuvZWse5hvgrl0XAK-U61e-0iGaao"
+ nickname="David"
+ subject="NAS?"
+ date="2012-11-25T12:27:50Z"
+ content="""
+What are you planning to support with the NAS repository type?  Will the assistant sync over NFS? I wanted to read more about this but I couldn't find anything on the design pages.
+"""]]
diff --git a/doc/design/assistant/blog/day_139__catch_up.mdwn b/doc/design/assistant/blog/day_139__catch_up.mdwn
new file mode 100644
index 0000000000..fc1e572b02
--- /dev/null
+++ b/doc/design/assistant/blog/day_139__catch_up.mdwn
@@ -0,0 +1,11 @@
+Got progress bars working for glacier. This needed some glacier-cli
+changes, which Robie helpfully made earlier.
+
+Spent some hours getting caught up and responding to bug reports, etc.
+
+Spent a while trying to make git-annex commands that fail to find
+any matching files to act on print a useful warning message,
+rather than the current nothing. Concluded this will be surprisingly
+hard to do, due to the multiple seek passes some commands perform. Update:
+Thought of a non-invasive and not too ugly way to do this while on my
+evening walk, and this wart is gone.
diff --git a/doc/design/assistant/blog/day_13__kqueue_continued.mdwn b/doc/design/assistant/blog/day_13__kqueue_continued.mdwn
new file mode 100644
index 0000000000..fd0cbb372b
--- /dev/null
+++ b/doc/design/assistant/blog/day_13__kqueue_continued.mdwn
@@ -0,0 +1,34 @@
+Good news! My beta testers report that the new kqueue code works on OSX.
+At least "works" as well as it does on Debian kFreeBSD. My crazy
+development strategy of developing on Debian kFreeBSD while targeting Mac
+OSX is vindicated. ;-)
+
+So, I've been beating the kqueue code into shape for the last 12 hours,
+minus a few hours sleep.
+
+First, I noticed it was seeming to starve the other threads. I'm using
+Haskell's non-threaded runtime, which does cooperative multitasking between
+threads, and my C code was never returning to let the other threads run.
+Changed that around, so the C code runs until SIGALARMed, and then that
+thread calls `yield` before looping back into the C code. Wow, cooperative
+multitasking.. I last dealt with that when programming for Windows 3.1!
+(Should try to use Haskell's -threaded runtime sometime, but git-annex
+doesn't work under it, and I have not tried to figure out why not.)
+
+Then I made a [single commit](http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=2bfcc0b09c5dd37c5e0ab65cb089232bfcc31934),
+with no testing, in which I made the kqueue code maintain a cache of what
+it expects in the directory tree, and use that to determine what files
+changed how when a change is detected. Serious code. It worked on the
+first go. If you were wondering why I'm writing in Haskell ... yeah,
+that's why.
+
+And I've continued to hammer on the kqueue code, making lots of little
+fixes, and at this point it seems *almost* able to handle the changes I
+throw at it. It does have one big remaining problem; kqueue doesn't tell me
+when a writer closes a file, so it will sometimes miss adding files. To fix
+this, I'm going to need to make it maintain a queue of new files, and
+periodically check them, with `lsof`, to see when they're done being
+written to, and add them to the annex. So while a file is being written
+to, `git annex watch` will have to wake up every second or so, and run
+`lsof` ... and it'll take it at least 1 second to notice a file's complete.
+Not ideal, but the best that can be managed with kqueue.
diff --git a/doc/design/assistant/blog/day_140__release_monday.mdwn b/doc/design/assistant/blog/day_140__release_monday.mdwn
new file mode 100644
index 0000000000..9c9ccd166f
--- /dev/null
+++ b/doc/design/assistant/blog/day_140__release_monday.mdwn
@@ -0,0 +1,25 @@
+New release today, the main improvements in this one being WebDAV,
+Box.com, and Amazon glacier support. [[/assistant/release_notes]]
+
+Collected together all the OSX problem reports into one place
+at [[/assistant/OSX]], to make it easier to get an overview of them.
+
+Did some testing of the OSX standalone app and found that it was missing
+some libraries. It seems some new libraries it's using themselves depend on
+other libraries, and `otool -L` doesn't recursively resolve this. 
+
+So I converted the simplistic shell script it was using to install
+libraries into a haskell progream that recursively adds libraries until
+there are no more to add. It's pulling in quite a lot more libraries now.
+This may fix some of the problems that have been reported with the
+standalone app; I don't really know since I can only do very limited
+testing on OSX.
+
+Still working on getting the standalone builds for this release done,
+should be done by the end of today.
+
+Also found a real stinker of a bug in `dirContentsRecursive`, which was
+just completely broken, apparently since day 1. Fixing that has certainly
+fixed buggy behavior of `git annex import`. It seems that the other
+user of it, the transfer log code, luckily avoided the deep directory
+trees that triggered the bug.
diff --git a/doc/design/assistant/blog/day_141__release_tuesday.mdwn b/doc/design/assistant/blog/day_141__release_tuesday.mdwn
new file mode 100644
index 0000000000..41c323f01e
--- /dev/null
+++ b/doc/design/assistant/blog/day_141__release_tuesday.mdwn
@@ -0,0 +1,6 @@
+I had planned to do nothing today; I can't remember the last time I did
+that. Twas not to be; instead I had to make a new release to fix
+a utterly stupid typo in the rsync special remote. I'm also seeing
+some slightly encouraging signs of the OSX app being closer to working
+and this release has a further fix toward that end; unsetting all the
+environment variables before running the system's web browser.
diff --git a/doc/design/assistant/blog/day_141__release_tuesday/comment_1_a5adea7a726df12f9121c744a036f08d._comment b/doc/design/assistant/blog/day_141__release_tuesday/comment_1_a5adea7a726df12f9121c744a036f08d._comment
new file mode 100644
index 0000000000..69fb647781
--- /dev/null
+++ b/doc/design/assistant/blog/day_141__release_tuesday/comment_1_a5adea7a726df12f9121c744a036f08d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnbBRfl5F8gKRr1ko8Ai6FbEZStXXNF1S4"
+ nickname="Áron"
+ subject="deb package for amd64"
+ date="2012-12-04T08:51:55Z"
+ content="""
+Hey, great work!
+Will we also have 64bit binaries in debian unstable soon?
+
+"""]]
diff --git a/doc/design/assistant/blog/day_142__filling_in.mdwn b/doc/design/assistant/blog/day_142__filling_in.mdwn
new file mode 100644
index 0000000000..d7f5c84bf0
--- /dev/null
+++ b/doc/design/assistant/blog/day_142__filling_in.mdwn
@@ -0,0 +1,9 @@
+Just filling in a few remaining bits and pieces from this month's work.
+
+* Made the assistant periodically check glacier-cli for archives that are
+  ready, and queue downloads of them.
+* The box.com configurator defaults to embedding the account info, allowing
+  one-click enabling of the repository. There's a check box to control this.
+* Fix some bugs with how the standalone images run git-annex.
+* Included ssh in the standalone images.
+* Various other bug fies.
diff --git a/doc/design/assistant/blog/day_143__what_next.mdwn b/doc/design/assistant/blog/day_143__what_next.mdwn
new file mode 100644
index 0000000000..6c277f7a26
--- /dev/null
+++ b/doc/design/assistant/blog/day_143__what_next.mdwn
@@ -0,0 +1,22 @@
+Yesterday, I woke up and realized I didn't know what I needed to work on in
+git-annex. Added a poll, [[polls/Android]] to help me decide what major
+thing to work on next.
+
+----
+
+More flailing at the OSX monster. (A species of gelatinous cube?)
+Current fun seems to involve git processes spinning if git-annex
+was started without a controlling TTY. I'm befuddled by this.
+
+----
+
+Made the S3 and Glacier configurators have a list of regions, rather than
+requiring a the region's code be entered correctly. I could not find a list of
+regions, or better, an API to get a list, so I'll have to keep updating as
+Amazon adds services in new regions.
+
+----
+
+Spent some time trying to get WebDAV to work with livedrive.com.
+It doesn't like empty PROPPATCH. I've developed a change to the haskell DAV
+library that will let me avoid this problem.
diff --git a/doc/design/assistant/blog/day_143__what_next/comment_1_40cf25a2ebdd43d8974a28e180e100e5._comment b/doc/design/assistant/blog/day_143__what_next/comment_1_40cf25a2ebdd43d8974a28e180e100e5._comment
new file mode 100644
index 0000000000..28ef42975d
--- /dev/null
+++ b/doc/design/assistant/blog/day_143__what_next/comment_1_40cf25a2ebdd43d8974a28e180e100e5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://1id.com/contact/=tp"
+ nickname="Tom"
+ subject="In case it might be helpful"
+ date="2012-12-04T14:25:14Z"
+ content="""
+S3 and Glacier regions.  
+<http://docs.amazonwebservices.com/general/latest/gr/rande.html#s3_region>  
+<http://docs.amazonwebservices.com/general/latest/gr/rande.html#glacier_region>
+
+(EC2) Region list API - likely a superset of the other service regions, could be used for sanity checks.  
+<http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeRegions.html>
+"""]]
diff --git a/doc/design/assistant/blog/day_143__what_next/comment_2_af9ccbbc5131e6333c029415141bdb51._comment b/doc/design/assistant/blog/day_143__what_next/comment_2_af9ccbbc5131e6333c029415141bdb51._comment
new file mode 100644
index 0000000000..b9df466cf7
--- /dev/null
+++ b/doc/design/assistant/blog/day_143__what_next/comment_2_af9ccbbc5131e6333c029415141bdb51._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5vDem1yeIu6uith5pxfb4mdKdIWVJpCs"
+ nickname="Louis"
+ subject="AWS regions in JSON"
+ date="2012-12-05T03:27:52Z"
+ content="""
+Mitch Garnaat maintains a json data file with AWS service regions & other useful data...
+
+https://github.com/garnaat/missingcloud/blob/master/aws.json
+"""]]
diff --git a/doc/design/assistant/blog/day_144__webapp_work.mdwn b/doc/design/assistant/blog/day_144__webapp_work.mdwn
new file mode 100644
index 0000000000..4e0c8287fa
--- /dev/null
+++ b/doc/design/assistant/blog/day_144__webapp_work.mdwn
@@ -0,0 +1,8 @@
+Made the webapp show runtime errors on a prettified page that includes version
+info, a bug reporting link, etc.
+
+Dealt with a bad interaction between required fields and the bootstrap modals
+displayed when submitting some configuration forms. This was long, complex,
+and had lots of blind alleys. In the end, I had to derive new password and
+text fields in yesod that don't set the required attribute in the generated
+html.
diff --git a/doc/design/assistant/blog/day_145__more_webapp_work.mdwn b/doc/design/assistant/blog/day_145__more_webapp_work.mdwn
new file mode 100644
index 0000000000..f9649be39d
--- /dev/null
+++ b/doc/design/assistant/blog/day_145__more_webapp_work.mdwn
@@ -0,0 +1,12 @@
+One problem with the current configurators for remotes is they have a lot
+of notes and text to read at the top. I've worked on cut that down somewhat,
+mostly by adding links and help buttons next to fields in the form.
+
+I also made each form have a check box controlling whether encryption is
+enabled. Mostly as a way to declutter the text at the top, which always had
+to say encryption is enabled.
+
+---
+
+I have a fairly well worked out design for [[desymlink]]. Will wait a few
+days to work on it to let it jell.
diff --git a/doc/design/assistant/blog/day_146__meanwhile.mdwn b/doc/design/assistant/blog/day_146__meanwhile.mdwn
new file mode 100644
index 0000000000..8ff8b1d723
--- /dev/null
+++ b/doc/design/assistant/blog/day_146__meanwhile.mdwn
@@ -0,0 +1,22 @@
+Biding my time while [[desymlink]] gells in my head..
+
+Fixed a bug in the assistant's local pairing that rejected ssh keys with a
+period in the comment.
+
+Fixed a bug in the assistant that made it try to drop content from remotes
+that didn't have it, and avoided a drop failure crashing a whole assistant
+thread.
+
+Made --auto behave better when preferred content is set.
+
+Looked into making the transfer queue allow running multiple transfers at
+the same time, ie, one per remote. This seems to essentially mean splitting
+the queue into per remote queues. There are some complexities, and I
+decided not to dive into working through it right now, since it'd be
+a distraction from thinking about [[desymlink]]. Will revisit it later.
+
+Allow specifying a port when setting up a ssh remote.
+
+While doing that, noticed that the assistant fails to transfer files to
+sync to a ssh remote that was just added. That got broken while optimising
+reconnecting with a remote; fixed it.
diff --git a/doc/design/assistant/blog/day_147__direct_mode.mdwn b/doc/design/assistant/blog/day_147__direct_mode.mdwn
new file mode 100644
index 0000000000..1a7523785b
--- /dev/null
+++ b/doc/design/assistant/blog/day_147__direct_mode.mdwn
@@ -0,0 +1,36 @@
+Started laying the groundwork for [[desymlink]]'s direct mode.
+I got rather far!
+
+A git repo can be configured with `annex.direct` and all actions that
+transfer objects to it will replace the symlinks with regular files.
+Removing objects also works (and puts back a broken symlink),
+as does checking if an object is present, which even detects if a file
+has been modified.
+
+So far, this works best when such a direct mode repository is used as a git
+remote of another repository. It is also possible to run a few git-annex
+commands, like "get" in a direct mode repository, though others, like
+"drop" won't work because they rely on the symlink to map back to the key.
+
+Direct mode relies on map files existing for each key in the repository, that tell
+what file(s) use it. It also relies on cache files, that contain the last
+known mtime, size, and inode of the file. So far, I've been setting these
+files up by hand.
+
+The main thing that's missing is support for transferring objects from
+direct mode repositories. There's no single place I can modify to support
+that (like I could for the stuff mentioned above), and also it's difficult
+to do safely, since files could be modified at any time. 
+
+So it'll need to quarantine files, to prevent a modified version from
+getting sent out. I could either do this by copying the file, or by
+temporarily `git annex lock`ing it. Unsure which choice would be less
+annoying..
+
+----
+
+Also did some investigation with Jimmy of the OSX app git-config hang.
+Seems to be some kind of imcompatability between the 10.7 autobuilder and
+10.8. Next step is probably to try to build on 10.8. Might also
+be worth trying <http://macdylibbundler.sourceforge.net/>, although my
+own scripts do more or less the same thing to build the app.
diff --git a/doc/design/assistant/blog/day_147__direct_mode/comment_1_0bd69532afce9dc04e3d88bfd0aed4b2._comment b/doc/design/assistant/blog/day_147__direct_mode/comment_1_0bd69532afce9dc04e3d88bfd0aed4b2._comment
new file mode 100644
index 0000000000..567c094c9f
--- /dev/null
+++ b/doc/design/assistant/blog/day_147__direct_mode/comment_1_0bd69532afce9dc04e3d88bfd0aed4b2._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://lj.rossia.org/users/imz/"
+ ip="79.165.59.119"
+ subject="&quot;removing&quot;  vs drop"
+ date="2012-12-12T13:20:42Z"
+ content="""
+I don't understand the difference behind:
+
+> Removing objects also works (and puts back a broken symlink)
+
+and
+
+> \"drop\" won't work because they rely on the symlink to map back to the key.
+
+If a file is removed (its content, which is replaced by a symlink), then it's not present there, so effectively it should be counted as \"dropped\" at this place. So, removing a file without counting it as dropped is something inconsistent, isn't it? Do I misunderstand something?
+"""]]
diff --git a/doc/design/assistant/blog/day_147__direct_mode/comment_2_3b26f0d081c3bf1037bb872d529ce825._comment b/doc/design/assistant/blog/day_147__direct_mode/comment_2_3b26f0d081c3bf1037bb872d529ce825._comment
new file mode 100644
index 0000000000..b29d453909
--- /dev/null
+++ b/doc/design/assistant/blog/day_147__direct_mode/comment_2_3b26f0d081c3bf1037bb872d529ce825._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.117"
+ subject="comment 2"
+ date="2012-12-12T23:45:42Z"
+ content="""
+`git annex drop` is a user-level operation built on top of lower-level object removal functions that are also used by other things.
+"""]]
diff --git a/doc/design/assistant/blog/day_148__direct_mode.mdwn b/doc/design/assistant/blog/day_148__direct_mode.mdwn
new file mode 100644
index 0000000000..14f1f889f8
--- /dev/null
+++ b/doc/design/assistant/blog/day_148__direct_mode.mdwn
@@ -0,0 +1,42 @@
+Got object sending working in direct mode. However, I don't yet have a
+reliable way to deal with files being modified while they're being
+transferred. I have code that detects it on the sending side, but the
+receiver is still free to move the wrong content into its annex, and record
+that it has the content. So that's not acceptable, and I'll need to work
+on it some more. However, at this point I can use a direct mode repository
+as a remote and transfer files from and to it.
+
+----
+
+Automated updating of the cached mtime, etc data. Next I need to automate
+generation of the key to filename mapping files. I'm thinking that I'll make
+`git annex sync` do it. Then, once I get committing and 
+merging working in direct mode repositories (which is likely to be a
+good week's worth of work), the workflow for using these repositories
+will be something like this:
+
+	git config annex.direct true
+	git annex sync # pulls any changes, merges, updates maps and caches
+	git annex get
+	# modify files
+	git annex sync # commits and pushes changes
+
+And once I get direct mode repositories working to this degree at the
+command line, I can get on with adding support to the assistant.
+
+----
+
+Also did some more work today on the OSX app. Am in the middle of getting
+it to modify the binaries in the app to change the paths to the libraries they
+depend on. This will avoid the hacky environment variable it is currently
+using, and make runshell a much more usable environment. It's the right way
+to do it. (I can't believe I just said RPATH was the right way to do
+anything.)
+
+In the middle of this, I discovered
+<http://hackage.haskell.org/package/cabal-macosx>, which does the same
+type of thing.
+
+Anyway, I have to do some crazy hacks to work around short library name
+fields in executables that I don't want to have to be specially rebuilt in
+order to build the webapp. Like git.
diff --git a/doc/design/assistant/blog/day_149__rainy_day.mdwn b/doc/design/assistant/blog/day_149__rainy_day.mdwn
new file mode 100644
index 0000000000..eb42108843
--- /dev/null
+++ b/doc/design/assistant/blog/day_149__rainy_day.mdwn
@@ -0,0 +1,15 @@
+Made `git annex sync` update the file mappings in direct mode.
+To do this efficiently, it uses `git diff-tree` to find files that are
+changed by the sync, and only updates those mappings. I'm rather happy
+with this, as a first step to fully supporting sync in direct mode.
+
+Finished the overhaul of the OSX app's library handling. It seems to work
+well, and will fix a whole class of ways the OSX app could break.
+
+Fixed a bug in the preferred content settings for backup repositories,
+introduced by some changes I made to preferred content handling 4 days ago.
+
+Fixed the Debian package to build with WebDAV support, which I forgot to
+turn on before.
+
+Planning a release tomorrow.
diff --git a/doc/design/assistant/blog/day_14__kqueue_kqueue_kqueue.mdwn b/doc/design/assistant/blog/day_14__kqueue_kqueue_kqueue.mdwn
new file mode 100644
index 0000000000..d7dab36117
--- /dev/null
+++ b/doc/design/assistant/blog/day_14__kqueue_kqueue_kqueue.mdwn
@@ -0,0 +1,23 @@
+... I'm getting tired of kqueue.
+
+But the end of the tunnel is in sight. Today I made git-annex handle files
+that are still open for write after a kqueue creation event is received.
+Unlike with inotify, which has a new event each time a file is closed,
+kqueue only gets one event when a file is first created, and so git-annex
+needs to retry adding files until there are no writers left.
+
+Eventually I found an elegant way to do that. The committer thread already
+wakes up every second as long as there's a pending change to commit. So for
+adds that need to be retried, it can just push them back onto the change
+queue, and the committer thread will wait one second and retry the add. One
+second might be too frequent to check, but it will do for now.
+
+This means that `git annex watch` should now be usable on OSX, FreeBSD, and
+NetBSD! (It'll also work on Debian kFreeBSD once [lsof is ported to it](http://bugs.debian.org/589103).)
+I've meged kqueue support to `master`.
+
+I also think I've squashed the empty commits that were sometimes made.
+
+Incidentally, I'm 50% through my first month, and finishing [[inotify]]
+was the first half of my roadmap for this month. Seem to be right on
+schedule.. Now I need to start thinking about [[syncing]].
diff --git a/doc/design/assistant/blog/day_14__thinking_about_syncing.mdwn b/doc/design/assistant/blog/day_14__thinking_about_syncing.mdwn
new file mode 100644
index 0000000000..4173fbf777
--- /dev/null
+++ b/doc/design/assistant/blog/day_14__thinking_about_syncing.mdwn
@@ -0,0 +1,44 @@
+Pondering [[syncing]] today. I will be doing syncing of the git repository
+first, and working on syncing of file data later.
+
+The former seems straightforward enough, since we just want to push all
+changes to everywhere. Indeed, git-annex already has a [[sync]] command
+that uses a smart technique to allow syncing between clones without a
+central bare repository. (Props to Joachim Breitner for that.)
+
+But it's not all easy. Syncing should happen as fast as possible, so
+changes show up without delay. Eventually it'll need to support syncing
+between nodes that cannot directly contact one-another. Syncing needs to
+deal with nodes coming and going; one example of that is a USB drive being
+plugged in, which should immediately be synced, but network can also come
+and go, so it should periodically retry nodes it failed to sync with. To
+start with, I'll be focusing on fast syncing between directly connected
+nodes, but I have to keep this wider problem space in mind.
+
+One problem with `git annex sync` is that it has to be run in both clones
+in order for changes to fully propagate. This is because git doesn't allow
+pushing changes into a non-bare repository; so instead it drops off a new
+branch in `.git/refs/remotes/$foo/synced/master`. Then when it's run locally
+it merges that new branch into `master`. 
+
+So, how to trigger a clone to run `git annex sync` when syncing to it?
+Well, I just realized I have spent two weeks developing something that can
+be repurposed to do that! [[Inotify]] can watch for changes to
+`.git/refs/remotes`, and the instant a change is made, the local sync
+process can be started. This avoids needing to make another ssh connection
+to trigger the sync, so is faster and allows the data to be transferred
+over another protocol than ssh, which may come in handy later.
+
+So, in summary, here's what will happen when a new file is created:
+
+1. inotify event causes the file to be added to the annex, and
+   immediately committed.
+2. new branch is pushed to remotes (probably in parallel)
+3. remotes notice new sync branch and merge it
+4. (data sync, TBD later)
+5. file is fully synced and available
+
+Steps 1, 2, and 3 should all be able to be accomplished in under a second.
+The speed of `git push` making a ssh connection will be the main limit
+to making it fast. (Perhaps I should also reuse git-annex's existing ssh
+connection caching code?)
diff --git a/doc/design/assistant/blog/day_150__12__58__12.mdwn b/doc/design/assistant/blog/day_150__12__58__12.mdwn
new file mode 100644
index 0000000000..8e1f192dba
--- /dev/null
+++ b/doc/design/assistant/blog/day_150__12__58__12.mdwn
@@ -0,0 +1,53 @@
+Yesterday I cut another release. However, getting an OSX build took until
+12:12 pm today because of a confusion about the location of lsof on OSX. The
+OSX build is now available, and I'm looking forward to hearing if it's working!
+
+----
+
+Today I've been working on making `git annex sync` commit in direct mode.
+
+For this I needed to find all new, modified, and deleted files, and I also
+need the git SHA from the index for all non-new files. There's not really
+an ideal git command to use to query this. For now I'm using
+`git ls-files --others --stage`, which works but lists more files than I
+really need to look at. It might be worth using one of the Haskell libraries
+that can directly read git's index.. but for now I'll stick with `ls-files`.
+
+It has to check all direct mode files whose content is present, which means
+one stat per file (on top of the stat that git already does), as well as one
+retrieval of the key per file (using the single `git cat-file` process that
+git-annex talks to).
+
+This is about as efficient as I can make it, except that unmodified
+annexed files whose content is not present are listed due to --stage,
+and so it has to stat those too, and currently also feeds them into `git add`.
+
+The assistant will be able to avoid all this work, except once at startup.
+
+Anyway, direct mode committing is working!
+
+For now, `git annex sync` in direct mode also adds new files. This because
+`git annex add` doesn't work yet in direct mode.
+
+It's possible for a direct mode file to be changed during a commit,
+which would be a problem since committing involves things like calculating
+the key and caching the mtime/etc, that would be screwed up. I took
+care to handle that case; it checks the mtime/etc cache before and after
+generating a key for the file, and if it detects the file has changed,
+avoids committing anything. It could retry, but if the file is a VM disk
+image or something else that's constantly modified, commit retrying forever
+would not be good.
+
+----
+
+For `git annex sync` to be usable in direct mode, it still needs
+to handle merging. It looks like I may be able to just enhance the automatic
+conflict resolution code to know about typechanged direct mode files.
+
+The other missing piece before this can really be used is that currently
+the key to file mapping is only maintained for files added locally, or
+that come in via `git annex sync`. Something needs to set up that mapping
+for files present when the repo is initally cloned. Maybe the thing
+to do is to have a `git annex directmode` command that enables/disables
+direct mode and can setup the the mapping, as well as any necessary unlocks
+and setting the trust level to untrusted.
diff --git a/doc/design/assistant/blog/day_151__direct_mode_toggle.mdwn b/doc/design/assistant/blog/day_151__direct_mode_toggle.mdwn
new file mode 100644
index 0000000000..c0b3f32459
--- /dev/null
+++ b/doc/design/assistant/blog/day_151__direct_mode_toggle.mdwn
@@ -0,0 +1,59 @@
+Built `git annex direct` and `git annex indirect` to toggle back and forth
+between direct mode. Made `git annex status` show if the repository is in
+direct mode. Now *only* merging is needed for direct mode to be basically
+usable. 
+
+I can do a little demo now. Pay attention to the "@" ls shows at the end
+of symlinks.
+
+	joey@gnu:~/tmp/bench/rdirect>ls
+	myfile@  otherfile@
+	joey@gnu:~/tmp/bench/rdirect>git annex find
+	otherfile
+	# So, two files, only one present in this repo.
+
+	joey@gnu:~/tmp/bench/rdirect>git annex direct
+	commit  
+	# On branch master
+	# Your branch is ahead of 'origin/master' by 7 commits.
+	#
+	nothing to commit (working directory clean)
+	ok
+	direct myfile ok
+	direct otherfile ok
+	direct  ok
+
+	joey@gnu:~/tmp/bench/rdirect>ls
+	myfile@  otherfile
+	# myfile is still a broken symlink because we don't have its content
+	joey@gnu:~/tmp/bench/rdirect>git annex get myfile
+	get myfile (from origin...) ok
+	(Recording state in git...)
+	joey@gnu:~/tmp/bench/rdirect>ls
+	myfile  otherfile
+
+	joey@gnu:~/tmp/bench/rdirect>echo "look mom, no symlinks" >> myfile
+	joey@gnu:~/tmp/bench/rdirect>git annex sync
+	add myfile (checksum...) ok
+	commit  
+	(Recording state in git...)
+	[master 0e8de9b] git-annex automatic sync
+	...
+	ok
+
+	joey@gnu:~/tmp/bench/rdirect>git annex indirect
+	commit  ok
+	indirect myfile ok
+	indirect otherfile ok
+	indirect  ok
+	joey@gnu:~/tmp/bench/rdirect>ls
+	myfile@  otherfile@
+
+I'd like `git annex direct` to set the repository to untrusted, but
+I didn't do it. Partly because having `git annex indirect` set it back to
+semitrusted seems possibly wrong -- the user might not trust a repo even in
+indirect mode. Or might fully trust it. The docs will encourage users to
+set direct mode repos to untrusted -- in direct mode you're operating
+without large swathes of git-annex's carefully constructed safety net.
+(When the assistant later uses direct mode, it'll untrust the repository
+automatically.)
diff --git a/doc/design/assistant/blog/day_152__bugfixes.mdwn b/doc/design/assistant/blog/day_152__bugfixes.mdwn
new file mode 100644
index 0000000000..da70fd1565
--- /dev/null
+++ b/doc/design/assistant/blog/day_152__bugfixes.mdwn
@@ -0,0 +1,18 @@
+Fixed a bug in the kqueue code that made the assistant not notice when a
+file was renamed into a subdirectory. This turned out to be because the
+symlink got broken, and it was using `stat` on the file. Switching to
+`lstat` fixed that.
+
+Improved installation of programs into standalone bundles. Now it uses
+the programs detected by configure, rather than a separate hardcoded list.
+Also improved handling of lsof, which is not always in PATH.
+
+Made a OSX 10.8.2 build of the app, which is nearly my last gasp attempt
+at finding a way around this crazy `git init` spinning problem with Jimmy's
+daily builds are used with newer OSX versions. Try it here:
+<http://downloads.kitenet.net/tmp/git-annex.dmg.bz2>
+
+----
+
+Mailed out the Kickstarter T-shirt rewards today, to people in the US.
+Have to fill out a bunch of forms before I can mail the non-US ones.
diff --git a/doc/design/assistant/blog/day_152__bugfixes/comment_1_46863a875f9daa6f2c9248b66ff91929._comment b/doc/design/assistant/blog/day_152__bugfixes/comment_1_46863a875f9daa6f2c9248b66ff91929._comment
new file mode 100644
index 0000000000..9199f3768e
--- /dev/null
+++ b/doc/design/assistant/blog/day_152__bugfixes/comment_1_46863a875f9daa6f2c9248b66ff91929._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmYiJgOvC4IDYkr2KIjMlfVD9r_1Sij_jY"
+ nickname="Douglas"
+ subject="OSX troubles"
+ date="2012-12-17T16:07:41Z"
+ content="""
+Have you considered making a homebrew installable version of git-annex? It may make things easier for you when it comes to build dependencies. 
+
+"""]]
diff --git a/doc/design/assistant/blog/day_152__bugfixes/comment_2_a586e617bc024c8a9ff60f1b8345d74d._comment b/doc/design/assistant/blog/day_152__bugfixes/comment_2_a586e617bc024c8a9ff60f1b8345d74d._comment
new file mode 100644
index 0000000000..af7a901a9b
--- /dev/null
+++ b/doc/design/assistant/blog/day_152__bugfixes/comment_2_a586e617bc024c8a9ff60f1b8345d74d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.117"
+ subject="comment 2"
+ date="2012-12-17T16:16:47Z"
+ content="""
+I would *love* *love* *love* for there to be a homebrew for git-annex. But I know nothing about homebrew so am not in a very good position to do it.
+"""]]
diff --git a/doc/design/assistant/blog/day_153__hibernation.mdwn b/doc/design/assistant/blog/day_153__hibernation.mdwn
new file mode 100644
index 0000000000..5406fcb868
--- /dev/null
+++ b/doc/design/assistant/blog/day_153__hibernation.mdwn
@@ -0,0 +1,26 @@
+As winter clouds set in, I have to ration my solar power and have been less
+active than usual.
+
+It seems that the OSX 10.8.2 `git init` hanging issue has indeed been
+resolved, by building the app on 10.8.2. Very good news!  Autobuilder setup is
+in progress.
+
+----
+
+Finally getting stuck in to direct mode git-merge handling. It's
+not possible to run `git merge` in a direct mode tree, because it'll
+see typechanged files and refuse to do anything.
+
+So the only way to use `git merge`, rather than writing my own merge engine,
+is to use `--work-tree` to make it operate in a temporary work tree directory
+rather than the real one.
+
+When it's run this way, any new, modified, or renamed files will be added
+to the temp dir, and will need to be moved to the real work tree.
+To detect deleted files, need to use `git ls-files --others`, and
+look at the old tree to see if the listed files were in it.
+
+When a merge conflict occurs, the new version of the file will be in the temp
+directory, and the old one in the work tree. The normal automatic merge
+conflict resolution machinery should work, with just some tweaks to handle
+direct mode.
diff --git a/doc/design/assistant/blog/day_154__direct_mode_merging.mdwn b/doc/design/assistant/blog/day_154__direct_mode_merging.mdwn
new file mode 100644
index 0000000000..c3233c36dd
--- /dev/null
+++ b/doc/design/assistant/blog/day_154__direct_mode_merging.mdwn
@@ -0,0 +1,21 @@
+Got merging working in direct mode!
+
+Basically works as outlined yesterday, although slightly less clumsily.
+Since there was already code that ran `git diff-tree` to update the
+associated files mappings after a merge, I was able to adapt that same code
+to also update the working tree.
+
+An important invariant for direct mode merges is that they should never
+cause annexed objects to be dropped. So if a file is deleted by a merge,
+and was a direct mode file that was the only place in the working copy
+where an object was stored, the object is moved into `.git/annex/objects`.
+This avoids data loss and any need to re-transfer objects after a merge.
+It also makes renames and other move complex tree manipulations always end
+up with direct mode files, when their content was present.
+
+Automatic merge conflict resoltion doesn't quite work right yet in direct
+mode.
+
+Direct mode has landed in the `master` branch, but I still consider it
+experimental, and of course the assistant still needs to be updated to
+support it.
diff --git a/doc/design/assistant/blog/day_155__bugfixes.mdwn b/doc/design/assistant/blog/day_155__bugfixes.mdwn
new file mode 100644
index 0000000000..42a95cc5a8
--- /dev/null
+++ b/doc/design/assistant/blog/day_155__bugfixes.mdwn
@@ -0,0 +1,15 @@
+Finished getting automatic merge conflict resolution working in direct
+mode. Turned out I was almost there yesterday, just a bug in a filename
+comparison needed to be fixed.
+
+Fixed a bug where the assistant dropped a file after transferring it,
+despite the preferred content settings saying it should keep its copy of
+the file. This turned out to be due to it reading the transfer info
+incorrectly, and adding a "\n" to the end of the filename, which caused the
+preferred content check to think it wasn't wanted after all. (Probably
+because it thought 0 copies of the file were wanted, but I didn't look into
+this in detail.)
+
+Worked on my test suite, particularly more QuickCheck tests. I need to
+use QuickCheck more, particularly when I've pairs of functions, like encode
+and decode, that make for easy QuickCheck properties.
diff --git a/doc/design/assistant/blog/day_156_and_157__direct_mode_assistant.mdwn b/doc/design/assistant/blog/day_156_and_157__direct_mode_assistant.mdwn
new file mode 100644
index 0000000000..f49d2914f6
--- /dev/null
+++ b/doc/design/assistant/blog/day_156_and_157__direct_mode_assistant.mdwn
@@ -0,0 +1,45 @@
+Over Christmas, I'm working on making the assistant support direct
+mode. I like to have a fairly detailed plan before starting this kind of
+job, but in this case, I don't. (Also I have a cold so planning? Meh.)
+This is a process of seeing what's broken in direct mode and fixing it.
+I don't know if it'll be easy or hard. Let's find out..
+
+* First, got direct mode adding of new files working. This was not hard, all the
+  pieces I needed were there. For now, it uses the same method as in
+  indirect mode to make sure nothing can modify the file while it's being
+  added.
+
+* An unexpected problem is that in its startup scan, the assistant runs
+  `git add --update` to detect and stage any deletions that happened
+  while it was not running. But in direct mode that also stages the full file
+  contents, so can't be used. Had to switch to using git plumbing to only
+  stage deleted files. Happily this also led to fixing a bug; deletions
+  were not always committed at startup when using the old method; with the
+  new method it can tell when there are deletions and trigger a commit.
+
+* Next, got it to commit when direct mode files are modified. The Watcher
+  thread gets a inotify event when this happens, so that was easy. (Although
+  in doing that I had to disable a guard in direct mode that made annexed
+  files co-exist with regular in-git files, so such mixed repositories
+  probably won't work in direct mode yet.)
+
+  However, naughty kqueue is another story, there are no kqueue events for
+  file modifications. So this won't work on OSX or the BSDs yet. I tried
+  setting some more kqueue flags in hope that one would make such events
+  appear, but no luck. Seems I will need to find some other method to detect
+  file modifications, possibly an OSX-specific API.
+
+* Another unexpected problem: When an assistant receives new files from one
+  of its remotes, in direct mode it still sets up symlinks to the content.
+  This was because the Merger thread didn't use the `sync` command's direct
+  mode aware merge code.. so fixed that.
+
+* Finally there was some direct mode bookeeping the assistant has
+  to get right. For example, when a file is modified, the old object has
+  to be looked up, and be marked as not locally present any longer. That
+  lookup relies on the already running `git cat-file --batch`, so it's
+  not as fast as it could be, if I kept a local cache of the mapping
+  between files and objects. But it seems fast enough for now.
+
+At this point the assistant seems to work in direct mode on Linux!
+Needs more testing..
diff --git a/doc/design/assistant/blog/day_158__fsevents.mdwn b/doc/design/assistant/blog/day_158__fsevents.mdwn
new file mode 100644
index 0000000000..472b6c2be5
--- /dev/null
+++ b/doc/design/assistant/blog/day_158__fsevents.mdwn
@@ -0,0 +1,20 @@
+Investigated using the OSX fsevents API to detect when files are modified,
+so they can be committed when using direct mode. There's a
+[haskell library](http://hackage.haskell.org/package/hfsevents-0.1.3)
+and even a [sample directory watching program](http://hackage.haskell.org/package/hobbes).
+Initial tests look good...
+
+Using fsevents will avoid kqueue's problems with needing enough file
+descriptors to open every subdirectory. kqueue is a rather poor match for
+git-annex's needs, really. It does not seem to provide events for file
+modifications at all, unless every *file* is individually opened. While I
+dislike leaving the BSD's out, they need a better interface to be perfectly
+supported by git-annex, and kqueue will still work for indirect mode
+repositories.
+
+----
+
+Got the assistant to use fsevents. It seems to work well!
+
+The only problem I know of is that it doesn't yet handle whole directory
+renames. That should be easy to fix later.
diff --git a/doc/design/assistant/blog/day_158__fsevents/comment_1_b278372ac6399f64d5fa9da178278a6d._comment b/doc/design/assistant/blog/day_158__fsevents/comment_1_b278372ac6399f64d5fa9da178278a6d._comment
new file mode 100644
index 0000000000..a13936ed55
--- /dev/null
+++ b/doc/design/assistant/blog/day_158__fsevents/comment_1_b278372ac6399f64d5fa9da178278a6d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkey8WuXUh_x5JC2c9_it1CYRnVTgdGu1M"
+ nickname="Dustin"
+ subject="Linux Support"
+ date="2012-12-27T21:37:45Z"
+ content="""
+Does this mean Linux will not support Direct mode?
+"""]]
diff --git a/doc/design/assistant/blog/day_158__fsevents/comment_2_2d5ce9b2807068c3517e185945662bd2._comment b/doc/design/assistant/blog/day_158__fsevents/comment_2_2d5ce9b2807068c3517e185945662bd2._comment
new file mode 100644
index 0000000000..edd63b1251
--- /dev/null
+++ b/doc/design/assistant/blog/day_158__fsevents/comment_2_2d5ce9b2807068c3517e185945662bd2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.127"
+ subject="comment 2"
+ date="2012-12-28T02:46:23Z"
+ content="""
+No, linux's inotify has everything I need for direct mode.
+"""]]
diff --git a/doc/design/assistant/blog/day_159__fsevents_and_assistant.mdwn b/doc/design/assistant/blog/day_159__fsevents_and_assistant.mdwn
new file mode 100644
index 0000000000..754e2c91fb
--- /dev/null
+++ b/doc/design/assistant/blog/day_159__fsevents_and_assistant.mdwn
@@ -0,0 +1,16 @@
+Short day today, but I spent it all on testing the new FSEvents code,
+getting it working with the assistant in direct mode. This included fixing
+its handling of renaming, and various other bugs.
+
+The assistant in direct mode now seems to work well on OSX. So I made
+the assistant *default* to making direct mode repositories on OSX.
+
+That'll presumably flush out any bugs. :) More importantly,
+it let me close several OSX-specific bugs to do with interactions between
+git-annex's symlinks and OSX programs that were apparently written under the
+misprehension that it's a user-mode program's job to manually follow symlinks.
+
+Of course, defaulting to direct mode also means users can just modify files
+as they like and the assistant will commit and sync the changed files.
+I'm waiting to see if direct mode becomes popular enough to make it the
+default on all OS's.
diff --git a/doc/design/assistant/blog/day_159__fsevents_and_assistant/comment_1_b85f446c3fa8d703a2a8882825c6f33f._comment b/doc/design/assistant/blog/day_159__fsevents_and_assistant/comment_1_b85f446c3fa8d703a2a8882825c6f33f._comment
new file mode 100644
index 0000000000..8bc089857c
--- /dev/null
+++ b/doc/design/assistant/blog/day_159__fsevents_and_assistant/comment_1_b85f446c3fa8d703a2a8882825c6f33f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 1"
+ date="2012-12-28T23:53:22Z"
+ content="""
+Make a release please, Im eager to try it out!:)
+"""]]
diff --git a/doc/design/assistant/blog/day_159__fsevents_and_assistant/comment_2_a150b404e0c39e0bb2f7dd00cda63cdc._comment b/doc/design/assistant/blog/day_159__fsevents_and_assistant/comment_2_a150b404e0c39e0bb2f7dd00cda63cdc._comment
new file mode 100644
index 0000000000..bc9c7031b0
--- /dev/null
+++ b/doc/design/assistant/blog/day_159__fsevents_and_assistant/comment_2_a150b404e0c39e0bb2f7dd00cda63cdc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnFhHPFP7j3wGNgBxEJoA8LcBJ4Xd1tTMY"
+ nickname="Joe"
+ subject="Release + Version Number"
+ date="2012-12-29T11:16:05Z"
+ content="""
+I second Laszlo's request for a release! Also, could you include a version number of some sort on the download (and binary if there isn't one there) to make it easy to tell what is available for download vs. what is installed?
+"""]]
diff --git a/doc/design/assistant/blog/day_159__fsevents_and_assistant/comment_3_37abc41bae23a1d7de0d19d952aec492._comment b/doc/design/assistant/blog/day_159__fsevents_and_assistant/comment_3_37abc41bae23a1d7de0d19d952aec492._comment
new file mode 100644
index 0000000000..b08636fd8e
--- /dev/null
+++ b/doc/design/assistant/blog/day_159__fsevents_and_assistant/comment_3_37abc41bae23a1d7de0d19d952aec492._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 3"
+ date="2012-12-29T13:26:30Z"
+ content="""
+There are daily/hourly builds at the [[install/OSX]] install page, try out the new features from there
+"""]]
diff --git a/doc/design/assistant/blog/day_15__its_aliiive.mdwn b/doc/design/assistant/blog/day_15__its_aliiive.mdwn
new file mode 100644
index 0000000000..10ef4ffe56
--- /dev/null
+++ b/doc/design/assistant/blog/day_15__its_aliiive.mdwn
@@ -0,0 +1,33 @@
+Syncing works! I have two clones, and any file I create in the first
+is immediately visible in the second. Delete that file from the second, and
+it's immediately removed from the first.
+
+Most of my work today felt like stitching existing limbs onto a pre-existing
+monster. Took the committer thread, that waits for changes and commits them,
+and refashioned it into a pusher thread, that waits for commits and pushes
+them. Took the watcher thread, that watches for files being made,
+and refashioned it into a merger thread, that watches for git refs being
+updated. Pulled in bits of the `git annex sync` command to reanimate this.
+
+It may be a shambling hulk, but it works.
+
+Actually, it's not much of a shambling hulk; I refactored my code after
+copying it. ;)
+
+I think I'm up to 11 threads now in the new
+`git annex assistant` command, each with its own job, and each needing
+to avoid stepping on the other's toes. I did see one MVar deadlock error
+today, which I have not managed to reproduce after some changes. I think
+the committer thread was triggering the merger thread, which probably
+then waited on the Annex state MVar the committer thread had held.
+
+Anyway, it even pushes to remotes in parallel, and keeps track of remotes
+it failed to push to, although as of yet it doesn't do any attempt at
+periodically retrying.
+
+One bug I need to deal with is that the push code assumes any change
+made to the remote has already been pushed back to it. When it hasn't, 
+the push will fail due to not being a fast-forward. I need to make it
+detect this case and pull before pushing.
+
+(I've pushed this work out in a new `assistant branch`.)
diff --git a/doc/design/assistant/blog/day_160__finishing_up_direct_mode.mdwn b/doc/design/assistant/blog/day_160__finishing_up_direct_mode.mdwn
new file mode 100644
index 0000000000..c789ca2f61
--- /dev/null
+++ b/doc/design/assistant/blog/day_160__finishing_up_direct_mode.mdwn
@@ -0,0 +1,10 @@
+A few final bits and pieces of direct mode. Fixed a few more bugs in the
+assistant. Made all git-annex commands that don't work at
+all, or only partially work in direct mode, refuse to run at all. Also,
+some optimisations.
+
+I'll surely need to revisit direct mode later and make more commands
+support it; `fsck` and `add` especially.
+But the only thing I'd like to deal with before I make a release with direct
+mode is the problem of files being able to be modified while they're
+being transferred, which can result in data loss.
diff --git a/doc/design/assistant/blog/day_161__release_day.mdwn b/doc/design/assistant/blog/day_161__release_day.mdwn
new file mode 100644
index 0000000000..5e3a621683
--- /dev/null
+++ b/doc/design/assistant/blog/day_161__release_day.mdwn
@@ -0,0 +1,8 @@
+Released the first git-annex with direct mode today. Notably, the assistant
+enables direct mode in repositories it creates. All builds are updated to
+3.20130102 now.
+
+My plan for this month is to fix whatever things currently might be
+preventing you from using the git-annex assistant. So bugfixes and
+whatever other important gaps need to be filled, but no major new
+feature developments.
diff --git a/doc/design/assistant/blog/day_161__release_day/comment_1_e82c67f3ce216618149537bba1e0b850._comment b/doc/design/assistant/blog/day_161__release_day/comment_1_e82c67f3ce216618149537bba1e0b850._comment
new file mode 100644
index 0000000000..f697d12dcc
--- /dev/null
+++ b/doc/design/assistant/blog/day_161__release_day/comment_1_e82c67f3ce216618149537bba1e0b850._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 1"
+ date="2013-01-02T21:26:32Z"
+ content="""
+1. Im not able to set direct mode (linux build, Version: 3.20130102 in about page).
+Is there something specific needed? I started fresh. I added a new directory (empty), once 
+git annex assistant started, I copied files to that directory, and the assistant 
+replaced all files with symlinks, just as before.
+What am I missing here?
+
+2. It is just minor usability remark:
+ I would like to see in the gui somewhere shown where the actual config is stored (~/.config/git-annex), 
+and an option to wipe it out and start fresh. Also a restart button.
+
+Best, Laszlo
+
+"""]]
diff --git a/doc/design/assistant/blog/day_161__release_day/comment_2_b1fe96fd818935c0497b78bb8ad32ffa._comment b/doc/design/assistant/blog/day_161__release_day/comment_2_b1fe96fd818935c0497b78bb8ad32ffa._comment
new file mode 100644
index 0000000000..1e44738a15
--- /dev/null
+++ b/doc/design/assistant/blog/day_161__release_day/comment_2_b1fe96fd818935c0497b78bb8ad32ffa._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.211"
+ subject="comment 2"
+ date="2013-01-03T17:59:22Z"
+ content="""
+\"I added a new directory (empty)\"
+
+Sounds like you set up the repository yourself, rather than letting the assistant do it. If so, it won't be in direct mode. You can `git annex assistant--stop`, and then `git annex direct` to enable direct mode.
+
+Restart/shutdown in the UI coming soon, I think.
+
+The entire git-annex configuration, include that of the assistant, is stored in the `.git/config` of your reposository, and on its `git-annex` branch. Deleting the repository is thus all that's needed to start over.
+"""]]
diff --git a/doc/design/assistant/blog/day_161__release_day/comment_3_40bac0e1756aa77bb966c4654857141c._comment b/doc/design/assistant/blog/day_161__release_day/comment_3_40bac0e1756aa77bb966c4654857141c._comment
new file mode 100644
index 0000000000..5bb35353b3
--- /dev/null
+++ b/doc/design/assistant/blog/day_161__release_day/comment_3_40bac0e1756aa77bb966c4654857141c._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 3"
+ date="2013-01-03T22:23:36Z"
+ content="""
+>> I added a new directory (empty)
+
+> Sounds like you set up the repository yourself, rather than letting the assistant do it. 
+> If so, it won't be in direct mode. You can git annex assistant--stop, 
+> and then git annex direct to enable direct mode.
+
+I added like this:
+0. no git-annex or git-annex-assistant is running
+1. create directory (/mnt/dxd/annex)
+2. launch git-annex-assistant
+3. add repository via the webbrowser
+4. copy a file over this(/mnt/dxd/annex) directory (via command line or nautilus)
+
+The file is replaced with symlink.
+
+This fix the issue:
+0. stop git-annex-assistant
+1. Go in the shell to that directory (cd /mnt/dxd/annex)
+2. switch to direct mode (/home/looser/Desktop/download/git-annex.linux/git-annex direct)
+3. start git-annex-assistant
+4. create a new repository(/mnt/dxd/annex2) via the webbrowser (add repository in top right corner)
+5. Now:
+/mnt/dxd/annex - NOT in direct mode (symlinks created instantly)
+/mnt/dxd/annex2 - in direct mode
+
+Im really happy I have finally direct mode running. 
+I will surely stress-test git-annex in the coming weeks.
+
+> Restart/shutdown in the UI coming soon, I think.
+
+Awesome.
+
+> The entire git-annex configuration, include that of the assistant, 
+> is stored in the .git/config of your reposository, and on its git-annex branch. 
+> Deleting the repository is thus all that's needed to start over.
+
+Thank you for the answer.
+"""]]
diff --git a/doc/design/assistant/blog/day_161__release_day/comment_4_af65656b0d1179636937595868bb97b0._comment b/doc/design/assistant/blog/day_161__release_day/comment_4_af65656b0d1179636937595868bb97b0._comment
new file mode 100644
index 0000000000..178e2ead4e
--- /dev/null
+++ b/doc/design/assistant/blog/day_161__release_day/comment_4_af65656b0d1179636937595868bb97b0._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 4"
+ date="2013-01-03T22:33:54Z"
+ content="""
+Usecase:
+Keep two directories in sync on the same computer.
+
+\"Removable drive\" almost covers this, except you need an usb thumbdrive 
+permanently plugged into the computer.
+
+Would be nice, if I could select a \"sync to this local folder\" option 
+alongside the \"Select drive:\" option.
+
+So it is my choice if I want to sync to a partition or to a folder.
+
+Bug(?):
+I created two repositories:
+/mnt/dxd/annex 
+/mnt/dxd/annex2
+
+And I added a \"Removable drive\" syncing option to /mnt/dxd/annex2, and I selected the \"/mnt/dxd\" drive as removable drive.
+The two repositories got mixed together 
+(ie. broken symlinks pointing to nonexistent .git/annex/objects/.. file)
+
+Best, 
+ Laszlo
+
+"""]]
diff --git a/doc/design/assistant/blog/day_161__release_day/comment_5_0c05caaaf9588e124585041bf5f45d75._comment b/doc/design/assistant/blog/day_161__release_day/comment_5_0c05caaaf9588e124585041bf5f45d75._comment
new file mode 100644
index 0000000000..e461bfdc4e
--- /dev/null
+++ b/doc/design/assistant/blog/day_161__release_day/comment_5_0c05caaaf9588e124585041bf5f45d75._comment
@@ -0,0 +1,20 @@
+[[!comment format=c
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 5"
+ date="2013-01-03T22:49:41Z"
+ content="""
+Ok, I think I figured it out. I have quit from git-annex-assistant (Ctrl-C in terminal window).
+
+And launched this command:
+$ ps -e |grep git-ann
+ 1782 ?        00:01:00 git-annex
+20144 pts/0    00:00:00 git-annex-webap
+20148 pts/0    00:00:00 git-annex
+20178 pts/0    00:00:00 git-annex <defunct>
+20508 pts/0    00:00:00 git-annex <defunct>
+20528 ?        00:00:02 git-annex
+21132 ?        00:00:00 git-annex <defunct>
+
+I will be more cautious in future.
+"""]]
diff --git a/doc/design/assistant/blog/day_161__release_day/comment_6_5dfb5f428633d6062925f61af2b8829b._comment b/doc/design/assistant/blog/day_161__release_day/comment_6_5dfb5f428633d6062925f61af2b8829b._comment
new file mode 100644
index 0000000000..f9683c820c
--- /dev/null
+++ b/doc/design/assistant/blog/day_161__release_day/comment_6_5dfb5f428633d6062925f61af2b8829b._comment
@@ -0,0 +1,23 @@
+[[!comment format=c
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 6"
+ date="2013-01-03T22:55:41Z"
+ content="""
+another problem:
+1. If you add a removable drive via the gui, you can not remove it anymore (from the gui)
+2. If you delete the directory on the removable drive, git-annex assistant silently fails
+to recreate the directory and start fresh.
+2/a. on the gui, there is no indication something is wrong with the removable drive repository
+2/b on the terminal it shows only this: 
+fatal: Not a git repository: '/mnt/dxd/annex/.git'
+
+On the main page it shows the two repositories, but on the upper right corner, the dropdown menu
+contains only the original repository and not the removeable drive repository.
+
+I stop spaming now...
+
+Laszlo
+
+
+"""]]
diff --git a/doc/design/assistant/blog/day_161__release_day/comment_7_ac4effb381b08d94d4a2d2482e92c89a._comment b/doc/design/assistant/blog/day_161__release_day/comment_7_ac4effb381b08d94d4a2d2482e92c89a._comment
new file mode 100644
index 0000000000..359947a5a9
--- /dev/null
+++ b/doc/design/assistant/blog/day_161__release_day/comment_7_ac4effb381b08d94d4a2d2482e92c89a._comment
@@ -0,0 +1,13 @@
+[[!comment format=c
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 7"
+ date="2013-01-03T23:07:27Z"
+ content="""
+Can not withstand myself.
+
+1. If you add a Removable drive repository, only the *new* files are copied over to the removable drive.
+2. Removable drive repository is not in direct mode. 
+Would be nice if it could be kept the same mode as the original repository.
+It is some kind of special repsoitory, I do not see any seemlinks either.
+"""]]
diff --git a/doc/design/assistant/blog/day_161__release_day/comment_8_32600e89e3098e52a1280895e03b3f86._comment b/doc/design/assistant/blog/day_161__release_day/comment_8_32600e89e3098e52a1280895e03b3f86._comment
new file mode 100644
index 0000000000..c220fc826b
--- /dev/null
+++ b/doc/design/assistant/blog/day_161__release_day/comment_8_32600e89e3098e52a1280895e03b3f86._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://csights.myopenid.com/"
+ ip="70.226.161.163"
+ subject="walkthroughs?"
+ date="2013-01-04T02:39:59Z"
+ content="""
+Could you post some walk-throughs?
+Is it possible to set up a direct mode repository using git-annex webapp ?
+
+Thanks for your work!  Sad to hear you had to get a generator.  :)
+C.
+
+"""]]
diff --git a/doc/design/assistant/blog/day_161__release_day/comment_9_07e5d0c3cad0ce2bd4943e53b61f1767._comment b/doc/design/assistant/blog/day_161__release_day/comment_9_07e5d0c3cad0ce2bd4943e53b61f1767._comment
new file mode 100644
index 0000000000..fc8c9c4b1b
--- /dev/null
+++ b/doc/design/assistant/blog/day_161__release_day/comment_9_07e5d0c3cad0ce2bd4943e53b61f1767._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="163.1.166.255"
+ subject="comment 9"
+ date="2013-01-04T20:26:46Z"
+ content="""
+You noted in a recent blog post that direct mode won't work with mixed repositories, that is, those that have files checked into git alongside annexed ones.  Is this still the case?  Thanks.
+"""]]
diff --git a/doc/design/assistant/blog/day_162__UI.mdwn b/doc/design/assistant/blog/day_162__UI.mdwn
new file mode 100644
index 0000000000..8994835c62
--- /dev/null
+++ b/doc/design/assistant/blog/day_162__UI.mdwn
@@ -0,0 +1,17 @@
+[Installed a generator](http://joeyh.name/blog/entry/overcast/),
+so I'll have more power and less hibernation.
+
+Added UI in the webapp to shut down the daemon. Would like to also have
+restart UI, but that's rather harder to do, seems it'd need to start
+another copy of the webapp (and so, of the assistant), and redirect the
+browser to its new url. ... But running two assistants in the same repo at
+the same time isn't good. Anyway, users can now use the UI to shut it down,
+and then use their native desktop UI to start it back up.
+
+[[!img /assistant/controlmenu.png]]
+
+Spiffed up the control menu. Had to stop listing other local repositories
+in the menu, because there was no way to notice when a new one was added
+(without checking a file on every page load, which is way overkill for this
+minor feature). Instead added a new page that lists local repositories it
+can switch to.
diff --git a/doc/design/assistant/blog/day_163__free_features.mdwn b/doc/design/assistant/blog/day_163__free_features.mdwn
new file mode 100644
index 0000000000..444b6cc30c
--- /dev/null
+++ b/doc/design/assistant/blog/day_163__free_features.mdwn
@@ -0,0 +1,32 @@
+There was a typo in cabal file that broke building the assistant on OSX.
+This didn't affect the autobuilds of the app, but several users building by
+hand reported problems. I made a new minor release fixing that typo, and
+also a resouce leak bug.
+
+Got a restart UI working after all. It's a hack though. It
+opens a new tab for the new assistant instance, and as most web browsers
+don't allow javascript to close tabs, the old tab is left open. At some
+point I need to add a proper thread manager to the assistant, which the
+restart code could use to kill the watcher and committer threads, and then
+I could do a clean restart, bringing up the new daemon and redirecting the
+browser to it.
+
+Found a bug in the assistant in direct mode -- the expensive transfer scan
+didn't queue uploads needed to sync to other repos in direct mode, although
+it did queue downloads. Fixing this laid some very useful groundwork for
+making more commands support direct mode, too. Got stuck for a long time
+dealing with some very strange `git-cat-file` behavior while making this
+work. Ended up putting in a workaround.
+
+After that, I found that these commands work in direct mode, without
+needing any futher changes!
+
+* `git annex find`
+* `git annex whereis`
+* `git annex copy`
+* `git annex move`
+* `git annex drop`
+* `git annex log`
+
+Enjoy! The only commands I'd like to add to this are `fsck`, `add`,
+and `addurl`...
diff --git a/doc/design/assistant/blog/day_164__bugfixes.mdwn b/doc/design/assistant/blog/day_164__bugfixes.mdwn
new file mode 100644
index 0000000000..1edca3d19d
--- /dev/null
+++ b/doc/design/assistant/blog/day_164__bugfixes.mdwn
@@ -0,0 +1,17 @@
+Several bugfixes from user feedback today.
+
+Made the assistant detect misconfigured systems where git will fail to
+commit because it cannot determine the user's name or email address, and
+dummy up enough info to get git working. It makes sense for git and
+git-annex to fail at the command line on such a misconfigured system, so
+the user can fix it, but for the assistant it makes sense to plow on and just
+work.
+
+I found a big gap in direct mode -- all the special remotes expected to find
+content in the indirect mode location when transferring to the remote. It
+was easy to fix once I noticed the problem. This is a big enough bug that
+I will be making a new release in a day or so.
+
+Also, got fsck working in direct mode. It doesn't check as many things
+as in indirect mode, because direct mode files can be modified at any time.
+Still, it's usable, and useful.
diff --git a/doc/design/assistant/blog/day_165__release_day.mdwn b/doc/design/assistant/blog/day_165__release_day.mdwn
new file mode 100644
index 0000000000..f29c6e589a
--- /dev/null
+++ b/doc/design/assistant/blog/day_165__release_day.mdwn
@@ -0,0 +1,16 @@
+(Posted a day late.) [[!meta date="Mon Jan  7 16:05:13 JEST 2013"]]
+
+Got `git annex add` (and `addurl`) working in direct mode. This allowed me
+to make `git annex sync` in direct mode no longer automatically add new
+files.
+
+It's also now safe to mix direct mode annexed files with regular files in
+git, in the same repository. Might have been safe all along, but I've
+tested it, and it certainly works now. You just have to be careful to not
+use `git commit -a` to commit changes to such files, since that'll also 
+stage the entire content of direct mode files.
+
+Made a minor release for these recent changes and bugfixes. Recommended if
+you're using direct mode. Had to chase down a stupid typo I made yesterday
+that caused fsck to infinite loop if it found a corrupted file. Thank
+goodness for test suites.
diff --git a/doc/design/assistant/blog/day_166__a_short_long_day.mdwn b/doc/design/assistant/blog/day_166__a_short_long_day.mdwn
new file mode 100644
index 0000000000..5f03fd1cf5
--- /dev/null
+++ b/doc/design/assistant/blog/day_166__a_short_long_day.mdwn
@@ -0,0 +1,25 @@
+I was up at the crack of dawn wrestling 100 pound batteries around for 3
+hours and rewiring most of my battery bank, so today is a partial day...
+but a day with power, which is always nice.
+
+Did some design work on finally making transfers of files from direct mode
+repositories safe, even if a file is modified as it's being uploaded.
+This seems easily doable for special remotes; git to git repository
+transfers are harder, but I think I see how to do it without breaking
+backwards compatability. 
+
+(An unresolved problem is that a temp file would be left behind when a
+transfer failed due to a file being changed. What would really be nice to
+do is to use that temp file as the rsync basis when transferring the new
+version of a file. Although this really goes beyond direct mode, and into
+[[deltas]] territory.)
+
+Made fsck work better in direct mode repositories. While it's expected for
+files to change at any time in direct mode, and so fsck cannot complain
+every time there's a checksum mismatch, it is possible for it to detect
+when a file does not *seem* to have changed, then check its checksum,
+and so detect disk corruption or other data problems.
+
+Also dealt with several bug reports. One really weird one involves `git
+cat-file` failing due to some kind of gpg signed data in the git-annex
+branch. I don't understand that at all yet.
diff --git a/doc/design/assistant/blog/day_167__safe_direct_mode_transfers.mdwn b/doc/design/assistant/blog/day_167__safe_direct_mode_transfers.mdwn
new file mode 100644
index 0000000000..8aa15fb13a
--- /dev/null
+++ b/doc/design/assistant/blog/day_167__safe_direct_mode_transfers.mdwn
@@ -0,0 +1,12 @@
+Well underway on making direct mode transfers roll back when the file is
+modified while it's transferred.
+
+As expected, it was easy to do for all the special remotes ... Except for
+bup, which does not allow deleting content. For bup it just removes the git
+ref for the bad content, and relies on bup's use of git delta compression
+to keep space use sane.
+
+The problem is also handled by `git-annex-shell sendkey`.
+But not yet for downloads from other git repositories. Bit stuck on that.
+
+Also: A few minor bug fixes.
diff --git a/doc/design/assistant/blog/day_167__safe_direct_mode_transfers/comment_1_f1aa64fe803d8c14b250a4e98b88142a._comment b/doc/design/assistant/blog/day_167__safe_direct_mode_transfers/comment_1_f1aa64fe803d8c14b250a4e98b88142a._comment
new file mode 100644
index 0000000000..4b5092036c
--- /dev/null
+++ b/doc/design/assistant/blog/day_167__safe_direct_mode_transfers/comment_1_f1aa64fe803d8c14b250a4e98b88142a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7AuSfii_tCkLyspL6Mr0ATlO6OxLNYOo"
+ nickname="Georg"
+ subject="comment 1"
+ date="2013-01-10T08:49:20Z"
+ content="""
+hmm, wouldn't it make sense to do the downloads into the annex object space, just like with indirect annexes? Then when the download is complete, with indirect annexes you create a soft link and with direct annexes you move the file (or create a hardlink and remove the directory entry in the annex object space)? Actually when you started to talk about direct I first envisioned it to be exactly like indirect, only with hard links instead of soft links.
+"""]]
diff --git a/doc/design/assistant/blog/day_167__safe_direct_mode_transfers/comment_2_5ce1db84c9ead713f1272c4975645b93._comment b/doc/design/assistant/blog/day_167__safe_direct_mode_transfers/comment_2_5ce1db84c9ead713f1272c4975645b93._comment
new file mode 100644
index 0000000000..c1b2724cb0
--- /dev/null
+++ b/doc/design/assistant/blog/day_167__safe_direct_mode_transfers/comment_2_5ce1db84c9ead713f1272c4975645b93._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 2"
+ date="2013-01-10T16:06:28Z"
+ content="""
+That is how direct mode works. (Although without the hard links, since maintaining them doesn't have any benefits.) And that's how downloading into a direct mode repo works. The issue I'm dealing with, though, is uploading from a direct mode repo, where the file that's being uploaded can be modified at the same time.
+"""]]
diff --git a/doc/design/assistant/blog/day_168__back_to_theme.mdwn b/doc/design/assistant/blog/day_168__back_to_theme.mdwn
new file mode 100644
index 0000000000..ff230e7642
--- /dev/null
+++ b/doc/design/assistant/blog/day_168__back_to_theme.mdwn
@@ -0,0 +1,18 @@
+This month's theme is supposed to be fixing up whatever might prevent users
+from using the assistant. To that end, I've posted an open-ended poll,
+[[polls/what is preventing me from using git-annex assistant]]. Please go
+fill it out so I can get an idea of how many people are using the
+assistant, and what needs to be done to get the rest of you, and your
+friends and family able to use it.
+
+In the meantime, today I fixed several bugs that were recently reported in
+the webapp and assistant. Getting it working as widely as possible, even on
+strange IPv6 only systems, and with browsers that didn't like my generated
+javascript code is important, and fits right into this month's theme. I'm
+happy to see lots of bugs being filed, since it means more users are trying
+the assistant out.
+
+Also continued work on making direct mode transfers safe. All transfers to
+local git remotes (wish I had a better phrase!) are now safe in direct mode.
+Only uploading from a direct mode repository over ssh to another git
+repository is still potentially unsafe.
diff --git a/doc/design/assistant/blog/day_168__back_to_theme/comment_1_f248780bfcbd0384d9d72c2633a4ea46._comment b/doc/design/assistant/blog/day_168__back_to_theme/comment_1_f248780bfcbd0384d9d72c2633a4ea46._comment
new file mode 100644
index 0000000000..eaa098d692
--- /dev/null
+++ b/doc/design/assistant/blog/day_168__back_to_theme/comment_1_f248780bfcbd0384d9d72c2633a4ea46._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://jasonwoof.com/"
+ nickname="JasonWoof"
+ subject="phrase suggestion"
+ date="2013-01-11T00:24:39Z"
+ content="""
+I suggest using the term \"repository\" not \"remote\". Two reasons: 1: it's a noun in *English. 2: it works for both local and remote repositories.
+
+Both get +1 because they match git terminology. (I have a secret dream that the assistant might bring people to git, maybe that's silly.)
+
+\* OK, so \"remote\" is also a noun in English, but it means the widget with buttons that controls the tv/whatever.
+"""]]
diff --git a/doc/design/assistant/blog/day_168__back_to_theme/comment_2_5beba073373b8e75a32d1fcfdc1a0782._comment b/doc/design/assistant/blog/day_168__back_to_theme/comment_2_5beba073373b8e75a32d1fcfdc1a0782._comment
new file mode 100644
index 0000000000..6308920256
--- /dev/null
+++ b/doc/design/assistant/blog/day_168__back_to_theme/comment_2_5beba073373b8e75a32d1fcfdc1a0782._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://csights.myopenid.com/"
+ ip="70.226.161.163"
+ subject="&quot;local git remotes&quot;"
+ date="2013-01-13T02:36:48Z"
+ content="""
+I am not quite sure how git-annex works and I do not know what a \"local git remote\" functionality is.
+
+How about this: call a \"git remote\" a \"git-annex store\" or just \"store\".  Then instead of a remote git remote it would be a remote git-annex store or just remote store.  :)
+
+
+
+"""]]
diff --git a/doc/design/assistant/blog/day_169__direct_mode_is_safe.mdwn b/doc/design/assistant/blog/day_169__direct_mode_is_safe.mdwn
new file mode 100644
index 0000000000..c3f569bd8d
--- /dev/null
+++ b/doc/design/assistant/blog/day_169__direct_mode_is_safe.mdwn
@@ -0,0 +1,24 @@
+I've finished making direct mode file transfers safe. The last piece of the
+puzzle was making `git-annex-shell recv-key` check data it's received from
+direct mode repositories. This is a bit expensive, but avoids adding
+another round-trip to the protocol. I might revisit this later, this was
+just a quick fix.
+
+---
+
+The [[poll|polls/what is preventing me from using git-annex assistant]] was 
+quite useful. Some interesting points:
+
+* 14% have been reading this blog, and rightly don't trust direct mode to
+  be safe. Which is why I went ahead with a quick fix to make it safe.
+* 6% want an Ubuntu PPA. I don't anticipate doing this myself, but
+  if anyone who develops for Ubuntu wants to put together a PPA with a
+  newer version, I can help you pick the newer haskell packages you'll
+  need from Debian, etc.
+* 9% just need me to update the amd64 build in Debian sid. I forgot to
+  include it in the last release, and the Debian buildds cannot currently
+  autobuild git-annex due to some breakage in the versions of haskell
+  libraries in unstable. Hopefully I'll remember to include an amd64 build
+  in my next release.
+
+And lots of other interesting stuff, I have a nice new TODO list now. :)
diff --git a/doc/design/assistant/blog/day_169__direct_mode_is_safe/comment_1_65f87656c4e6bc7cdb614f53961341c9._comment b/doc/design/assistant/blog/day_169__direct_mode_is_safe/comment_1_65f87656c4e6bc7cdb614f53961341c9._comment
new file mode 100644
index 0000000000..b51153cad5
--- /dev/null
+++ b/doc/design/assistant/blog/day_169__direct_mode_is_safe/comment_1_65f87656c4e6bc7cdb614f53961341c9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="163.1.166.255"
+ subject="comment 1"
+ date="2013-01-11T20:25:48Z"
+ content="""
+If you have time, an updated sid package for armel would be much appreciated.
+"""]]
diff --git a/doc/design/assistant/blog/day_169__direct_mode_is_safe/comment_2_a116a402a126c62be54c06afd82439ab._comment b/doc/design/assistant/blog/day_169__direct_mode_is_safe/comment_2_a116a402a126c62be54c06afd82439ab._comment
new file mode 100644
index 0000000000..7afd951e17
--- /dev/null
+++ b/doc/design/assistant/blog/day_169__direct_mode_is_safe/comment_2_a116a402a126c62be54c06afd82439ab._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://csights.myopenid.com/"
+ ip="70.226.161.163"
+ subject="use debian repos instead of Ubuntu PPA?"
+ date="2013-01-12T13:43:44Z"
+ content="""
+Maybe Ubuntu users would be satisfied with tweaks to their sources.list and preferences?
+
+/etc/apt/sources.list.d/git-annex.sources.list
+deb http://ftp.us.debian.org/debian unstable main
+
+/etc/apt/preferences.d/git-annex.preferences
+Package: *
+Pin: release a=unstable,o=Debian
+Pin-Priority: 400
+
+
+Not sure how that will work out in Ubuntu package manager.  In aptitude you'll get warning about untrusted repos (maybe install Debian's gpg keys) and will probably have to manually select dependencies from Debian repos.
+"""]]
diff --git a/doc/design/assistant/blog/day_16__more_robust_syncing.mdwn b/doc/design/assistant/blog/day_16__more_robust_syncing.mdwn
new file mode 100644
index 0000000000..e9343f846d
--- /dev/null
+++ b/doc/design/assistant/blog/day_16__more_robust_syncing.mdwn
@@ -0,0 +1,44 @@
+I released a version of git-annex over the weekend that includes the `git
+annex watch` command. There's a minor issue installing it from cabal on
+OSX, which I've fixed in my tree. Nice timing: At least the watch command
+should be shipped in the next Debian release, which freezes at the end of
+the month.
+
+Jimmy found out how kqueue [[blows
+up|bugs/Issue_on_OSX_with_some_system_limits]] when there are too many
+directories to keep all open. I'm not surprised this happens, but it's nice
+to see exactly how. Odd that it happened to him at just 512 directories;
+I'd have guessed more. I have plans to fork watcher programs that each
+watch 512 directories (or whatever the ulimit is), to deal with this. What
+a pitiful interface is kqueue.. I have not thought yet about how the watcher
+programs would communicate back to the main program.
+
+----
+
+Back on the assistant front, I've worked today on making git syncing more
+robust. Now when a push fails, it tries a pull, and a merge, and repushes.
+That ensures that the push is, almost always, a fast-forward. Unless
+something else gets in a push first, anyway!
+
+If a push still fails, there's Yet Another Thread, added today, that will
+wake up after 30 minutes and retry the push. It currently keeps retrying
+every 30 minutes until the push finally gets though. This will deal, to
+some degree, with those situations where a remote is only sometimes
+available.
+
+I need to refine the code a bit, to avoid it keeping an ever-growing queue
+of failed pushes, if a remote is just dead. And to clear old failed pushes
+from the queue when a later push succeeds.
+
+I also need to write a git merge driver that handles conflicts in the tree.
+If two conflicting versions of a file `foo` are saved, this would merge
+them, renaming them to `foo.X` and `foo.Y`. Probably X and Y are the
+git-annex keys for the content of the files; this way all clones will
+resolve the conflict in a way that leads to the same tree. It's also
+possible to get a conflict by one repo deleting a file, and another
+modifying it. In this case, renaming the deleted file to `foo.Y` may
+be the right approach, I am not sure.
+
+I glanced through some Haskell dbus bindings today. I belive there are dbus
+events available to detect when drives are mounted, and on Linux this would
+let git-annex notice and sync to usb drives, etc.
diff --git a/doc/design/assistant/blog/day_16__more_robust_syncing/comment_1_23e7a90429e4431f90787cd016ebe188._comment b/doc/design/assistant/blog/day_16__more_robust_syncing/comment_1_23e7a90429e4431f90787cd016ebe188._comment
new file mode 100644
index 0000000000..fece5c9aff
--- /dev/null
+++ b/doc/design/assistant/blog/day_16__more_robust_syncing/comment_1_23e7a90429e4431f90787cd016ebe188._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2012-06-27T12:46:31Z"
+ content="""
+can X and Y be the names of the git-annex remotes?
+"""]]
diff --git a/doc/design/assistant/blog/day_16__more_robust_syncing/comment_2_8e7e7cd27791bb47625e60a284e9c802._comment b/doc/design/assistant/blog/day_16__more_robust_syncing/comment_2_8e7e7cd27791bb47625e60a284e9c802._comment
new file mode 100644
index 0000000000..09613cc906
--- /dev/null
+++ b/doc/design/assistant/blog/day_16__more_robust_syncing/comment_2_8e7e7cd27791bb47625e60a284e9c802._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.189"
+ subject="comment 2"
+ date="2012-07-26T17:27:39Z"
+ content="""
+That's a good question. Unfortunatly they cannot; X and Y need to be stable across repositories, and git remotes can have different names in different repositories.
+
+Even using the description that git-annex stores for each repository for X and Y is problematic, since that description can change, and so could be different in two repos that are each trying to resolve the same merge conflict.
+"""]]
diff --git a/doc/design/assistant/blog/day_170__bugfixes_and_release.mdwn b/doc/design/assistant/blog/day_170__bugfixes_and_release.mdwn
new file mode 100644
index 0000000000..251ee7636d
--- /dev/null
+++ b/doc/design/assistant/blog/day_170__bugfixes_and_release.mdwn
@@ -0,0 +1,8 @@
+Fixed a goodly amount of bugs today.
+
+The most interesting change was that in direct mode, files using the same
+key are no longer hardlinked, as that could cause a surprising behavior if
+modifying one, where the other would also change.
+
+Made a release, which is almost entirely bug fixes. Debian amd64 build
+included this time. :)
diff --git a/doc/design/assistant/blog/day_171__logs.mdwn b/doc/design/assistant/blog/day_171__logs.mdwn
new file mode 100644
index 0000000000..7c7a4c821d
--- /dev/null
+++ b/doc/design/assistant/blog/day_171__logs.mdwn
@@ -0,0 +1,23 @@
+I've noticed people have some problems getting me logs when there'a a bug,
+so I worked on improving the logging of the assistant.
+
+While the assistant logged to `.git/annex/daemon.log` when started as a
+daemon, when the webapp ran it didn't log there. It's somewhat tricky to
+make the webapp redirect messages to the log, because it may start a web
+browser that wants to write to the console. Took some file descriptor
+juggling, but I made this work. Now the log is even used when the assistant
+is started for the first time in a newly created repository. So, we have
+total log coverage.
+
+Next, I made a simple page in the webapp to display the accumulated logs.
+It does not currently refresh as new things are logged. But it's easier
+for me to tell users to click on `Current Repository -> View log` than
+ask for them to look for the daemon.log file.
+
+Finally, I made all the webapp's alerts also be written to the log.
+
+---
+
+Also did the requisite bug fixes.
+
+[[!img /assistant/logs.png alt="screenshot of logs page"]]
diff --git a/doc/design/assistant/blog/day_172__short_day.mdwn b/doc/design/assistant/blog/day_172__short_day.mdwn
new file mode 100644
index 0000000000..80a32d87ec
--- /dev/null
+++ b/doc/design/assistant/blog/day_172__short_day.mdwn
@@ -0,0 +1,22 @@
+Only one bug fix today, but it was a doozie. It seems that gpg2 has an
+incompatibility with the gpg 1.x that git-annex was written for, that
+causes large numbers of excess passphrase prompts, when it's supposed to be
+using a remote's symmetric encryption key. Adding the --batch parameter
+fixed this.
+
+I also put together a page listing [[related_software]] to git-annex.
+
+I've also updated [[direct_mode]]'s documentation, about when it's safe to
+use direct mode. The intuition I've developed about direct mode is that if
+you don't need full versioning of files (with the ability to get back old
+versions), direct mode is fine and safe to use. If you want full
+versioning, it's best to not use direct mode. Or a reasonable compromise is
+to `git annex untrust` the direct mode repository and set up a backup remote.
+With this compromise, only if you edit a file twice in a row might the old
+version get lost before it can be backed up.
+
+Of course, it would be possible to make direct mode fully version
+preserving, but it'd have to back up every file in the repository locally
+to do so. Going back to two local copies of every file, which is part of
+git that git-annex happily avoids. Hmm, it might be possible to only back
+up a file locally until it reaches the backup remote..
diff --git a/doc/design/assistant/blog/day_172__short_day/comment_1_b75e26b77a23a45da1c4c3bca1399246._comment b/doc/design/assistant/blog/day_172__short_day/comment_1_b75e26b77a23a45da1c4c3bca1399246._comment
new file mode 100644
index 0000000000..c7d4c74ca2
--- /dev/null
+++ b/doc/design/assistant/blog/day_172__short_day/comment_1_b75e26b77a23a45da1c4c3bca1399246._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~rubiojr"
+ nickname="rubiojr"
+ subject="comment 1"
+ date="2013-01-18T18:42:35Z"
+ content="""
+Awesome @joey, crisp clear. 
+
+I guess that most people used to the Dropbox way of doing things will not miss versioning that much, which is not very useful for medium/large binary files in most cases I'd say. 
+
+Being able to choose the mode for power users is pretty cool though.
+"""]]
diff --git a/doc/design/assistant/blog/day_173__snow_day.mdwn b/doc/design/assistant/blog/day_173__snow_day.mdwn
new file mode 100644
index 0000000000..9b07a8c5f7
--- /dev/null
+++ b/doc/design/assistant/blog/day_173__snow_day.mdwn
@@ -0,0 +1,22 @@
+When I wasn't dealing with the snowstorm today, I was fixing more bugs.
+Rather serious bugs.
+
+One actually involved corruption to git-annex's location tracking info, due
+to a busted three-way merge. Takes an unusual set of circumstances for that
+bug to be triggered, which is why it was not noticed before now. Also,
+since git-annex is designed to not trust its location tracking info, and
+recover from it becoming inconsistent, someone could have experienced the
+bug and not really noticed it. Still it's a serious problem and I'm in debt
+to user a-or-b for developing a good test case that let me reproduce it and
+fix it. (Also added to the test suite.)
+[[This is how to make a perfect bug report|bugs/Annex_thinks_file_exists_afer_being_dropped]]
+
+Another bug made `git add; git commit` cause data loss in direct mode.
+I was able to make that not lose data, although it still does something
+that's unlikely to be desired, unless the goal is to move a file from an
+annexed direct mode file to having its entire contents stored in git.
+
+Also found a bug with sync's automatic resolution of git conflicts. It
+failed when two repositories both renamed a file to different names.
+I had neglected to explicitly `git rm` the old file name, which is
+necessary to resolve such a conflict.
diff --git a/doc/design/assistant/blog/day_174__last_weekend_before_AU.mdwn b/doc/design/assistant/blog/day_174__last_weekend_before_AU.mdwn
new file mode 100644
index 0000000000..b86a39d660
--- /dev/null
+++ b/doc/design/assistant/blog/day_174__last_weekend_before_AU.mdwn
@@ -0,0 +1,25 @@
+On Friday, worked on several bugs in direct mode mapping code. Fixed it
+to not crash on invalid unicode in filenames. Dealt with some bugs when
+mappings were updated in subdirectories of the repository.
+
+Those bugs could result in inconsistent mapping files, so today I
+made `fsck` check mapping files for consistency.
+
+Leaving for Australia tomorrow, but I also hope to get another bugfix
+release out before my flight leaves. Then will be on vacation for several
+days, more or less. Then at Linux Conf Australia, where there will
+be a git-annex presentation on February 1st.
+
+----
+
+BTW, I've lined up my Android development hardware for next month. I will
+be using an [Asus Transformer](http://en.wikipedia.org/wiki/ASUS_Eee_Pad_Transformer),
+kindly lent to me by Mark H. This has the advantage
+of having a real keyboard, and running the (currently) second most widely used
+version of Android, 4.0.x. I have already experienced frustration getting photos
+off the thing and into my photo annex; the file manager is the worst I've
+seen since the 80's. I understand why so many want an Android port!
+
+Interestingly, its main user filesystem is a FUSE mount point on `/sdcard`
+backed by an ext4 filesystem on `/data` that a regular user is not allowed
+to access. Whatever craziness this entails does not support symlinks.
diff --git a/doc/design/assistant/blog/day_174__last_weekend_before_AU/comment_1_05a8fd47f54373331741cc869a53b0c3._comment b/doc/design/assistant/blog/day_174__last_weekend_before_AU/comment_1_05a8fd47f54373331741cc869a53b0c3._comment
new file mode 100644
index 0000000000..f2a51310d0
--- /dev/null
+++ b/doc/design/assistant/blog/day_174__last_weekend_before_AU/comment_1_05a8fd47f54373331741cc869a53b0c3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2013-01-19T20:40:52Z"
+ content="""
+The Nexus devices all come without support for SD cards and without FAT anywhere to be seen. Indirect mode should work nicely on those.
+
+-- Richard
+"""]]
diff --git a/doc/design/assistant/blog/day_174__last_weekend_before_AU/comment_2_fc8e65eef954c4caa8321c2fe8b711b7._comment b/doc/design/assistant/blog/day_174__last_weekend_before_AU/comment_2_fc8e65eef954c4caa8321c2fe8b711b7._comment
new file mode 100644
index 0000000000..b84ad4e3e0
--- /dev/null
+++ b/doc/design/assistant/blog/day_174__last_weekend_before_AU/comment_2_fc8e65eef954c4caa8321c2fe8b711b7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="84.48.83.221"
+ subject="Presentation video"
+ date="2013-01-19T22:09:50Z"
+ content="""
+Any chance your presentation will be filmed and made available?
+"""]]
diff --git a/doc/design/assistant/blog/day_174__last_weekend_before_AU/comment_3_399534f540d85cac067fbb7be9d373b4._comment b/doc/design/assistant/blog/day_174__last_weekend_before_AU/comment_3_399534f540d85cac067fbb7be9d373b4._comment
new file mode 100644
index 0000000000..ebce958a75
--- /dev/null
+++ b/doc/design/assistant/blog/day_174__last_weekend_before_AU/comment_3_399534f540d85cac067fbb7be9d373b4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="hamish"
+ ip="203.0.139.23"
+ subject="AU"
+ date="2013-01-24T12:50:06Z"
+ content="""
+I dont know how busy your LCA week is looking, but I'd love to shout you a beer one evening - perhaps there would also be other git-annex people hanging around the conference and interested too
+"""]]
diff --git a/doc/design/assistant/blog/day_175__pacific_features.mdwn b/doc/design/assistant/blog/day_175__pacific_features.mdwn
new file mode 100644
index 0000000000..403088ec84
--- /dev/null
+++ b/doc/design/assistant/blog/day_175__pacific_features.mdwn
@@ -0,0 +1,15 @@
+15 hours in a plane with in-seat power. Ok, time for some new features!
+
+Added two new repository groups. 
+
+"manual" can be used to avoid the assistant downloading any file contents
+on its own. It'll still upload and otherwise sync data. To download files,
+you can use `git annex get` while the assistant is running. You can also
+drop files using the command line.
+
+"source" is for repositories that are the source of new files, but don't
+need to retain a copy once the file has been moved to another repository.
+A camera would be a good example.
+
+Ok, those were easy features to code; I suck at being productive on planes.
+Release coming up with those, once I find enough bandwidth here in AU.
diff --git a/doc/design/assistant/blog/day_175__pacific_features/comment_1_c3ee4386f872b7c76aaecfa638b368cb._comment b/doc/design/assistant/blog/day_175__pacific_features/comment_1_c3ee4386f872b7c76aaecfa638b368cb._comment
new file mode 100644
index 0000000000..0f2708005c
--- /dev/null
+++ b/doc/design/assistant/blog/day_175__pacific_features/comment_1_c3ee4386f872b7c76aaecfa638b368cb._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlyFDd2xkx0uj738OArDj10CqEkVfWu_mQ"
+ nickname="Johann"
+ subject="comment 1"
+ date="2013-01-24T15:36:34Z"
+ content="""
+Regarding 'manual': Maybe it is necessary to adjust the other standard settings for preferred content then.
+For the 'transfer' for example it would still make sense to treat a manual repository as a client.
+"""]]
diff --git a/doc/design/assistant/blog/day_176__thread_management.mdwn b/doc/design/assistant/blog/day_176__thread_management.mdwn
new file mode 100644
index 0000000000..38f043fcfb
--- /dev/null
+++ b/doc/design/assistant/blog/day_176__thread_management.mdwn
@@ -0,0 +1,13 @@
+Got back to hacking today, and did something I've wanted to do for some
+time. Made all the assistant's threads be managed by a thread manager. This
+allows restarting threads if they crash, by clicking a button in the
+webapp. It also will allow for other features later, like stopping and
+starting the watcher thread, to pause the assistant adding local files.
+
+[[!img /assistant/crashrecovery.png]]
+
+I added the haskell async library as a dependency, which made this pretty
+easy to implement. The only hitch is that async's documentation is not
+clear about how it handles asyncronous exceptions. It took me quite a while
+to work out why the errors I'd inserted into threads to test were crashing
+the whole program rather than being caught!
diff --git a/doc/design/assistant/blog/day_178__bus_hacking.mdwn b/doc/design/assistant/blog/day_178__bus_hacking.mdwn
new file mode 100644
index 0000000000..738afd2c9e
--- /dev/null
+++ b/doc/design/assistant/blog/day_178__bus_hacking.mdwn
@@ -0,0 +1,10 @@
+Hacking on a bus to Canberra for [LCA2013](https://lca2013.linux.org.au/),
+I made the webapp's UI for pausing syncing to a repository also work for
+the local repository. This pauses the watcher thread. (There's also an
+annex.autocommit config setting for this.)
+
+Ironically, this didn't turn out to the use the thread manager I built
+yesterday. I am not sure that a ThreadKilled exception would never be
+masked in the watcher thread. (There is some overly broad exception
+handling in git-annex that dates to back before I quite understood haskell
+exceptions.)
diff --git a/doc/design/assistant/blog/day_179__brief_updates.mdwn b/doc/design/assistant/blog/day_179__brief_updates.mdwn
new file mode 100644
index 0000000000..e755ca8aea
--- /dev/null
+++ b/doc/design/assistant/blog/day_179__brief_updates.mdwn
@@ -0,0 +1,19 @@
+Not doing significant coding here at LCA2013, but stuff is still happening:
+
+* I'll be giving a talk and demo of git-annex and the assistant tomorrow.
+  Right after a keynote by Tim Berners-Lee! There's no streaming, but
+  a recording will be available later.
+* I've met numerous git-annex users and git-annex curious folk from down
+  under.
+* I had a suggestion that direct mode rename the `.git` directory to
+  something else, to prevent foot-shooting git commands being used.
+  A wrapper around git could be used to run git commands, and limit
+  to safe ones. Under consideration.
+* I finally updated the OSX 10.8.2 build to last week's release.
+  Been having some problems with the autobuilder, but it finally spat out
+  a build. Hopefully this build is good, and it should fix the javascript
+  issues with Safari and the webapp.
+* Ulrik Sverdrup has written <https://github.com/blake2-ppc/git-remote-gcrypt>,
+  which allows using gpg encrypted ssh remotes with git. The same idea
+  could be expanded to other types of remotes, like S3. I'm excited
+  about adding encrypted git remote support to the assistant!
diff --git a/doc/design/assistant/blog/day_179__brief_updates/comment_1_920a84457d40358507a3eb817a4568d9._comment b/doc/design/assistant/blog/day_179__brief_updates/comment_1_920a84457d40358507a3eb817a4568d9._comment
new file mode 100644
index 0000000000..c58529cf1f
--- /dev/null
+++ b/doc/design/assistant/blog/day_179__brief_updates/comment_1_920a84457d40358507a3eb817a4568d9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmnG4EuvZWse5hvgrl0XAK-U61e-0iGaao"
+ nickname="David"
+ subject="git commit in direct mode"
+ date="2013-01-31T08:30:19Z"
+ content="""
+How about creating a .git/hooks/pre-commit script that warns the user or checks the commit before anything goes wrong? 
+"""]]
diff --git a/doc/design/assistant/blog/day_17__push_queue_prune.mdwn b/doc/design/assistant/blog/day_17__push_queue_prune.mdwn
new file mode 100644
index 0000000000..54ee75fb8d
--- /dev/null
+++ b/doc/design/assistant/blog/day_17__push_queue_prune.mdwn
@@ -0,0 +1,19 @@
+Not much available time today, only a few hours.
+
+Main thing I did was fixed up the failed push tracking to use a better data
+structure. No need for a queue of failed pushes, all it needs is a map of
+remotes that have an outstanding failed push, and a timestamp. Now it
+won't grow in memory use forever anymore. :)
+
+Finding the right thread mutex type for this turned out to be a bit of a
+challenge. I ended up with a STM TMVar, which is left empty when there are
+no pushes to retry, so the thread using it blocks until there are some. And,
+it can be updated transactionally, without races.
+
+I also fixed a bug outside the git-annex assistant code. It was possible to
+crash git-annex if a local git repository was configured as a remote, and
+the repository was not available on startup. git-annex now ignores such
+remotes. This does impact the assistant, since it is a long running process
+and git repositories will come and go. Now it ignores any that
+were not available when it started up. This will need to be dealt with when
+making it support removable drives.
diff --git a/doc/design/assistant/blog/day_180__back.mdwn b/doc/design/assistant/blog/day_180__back.mdwn
new file mode 100644
index 0000000000..adb336244b
--- /dev/null
+++ b/doc/design/assistant/blog/day_180__back.mdwn
@@ -0,0 +1,7 @@
+Back from Australia. Either later today or tomorrow I'll dig into the
+messages I was not able to get to while traveling, and then the plan is to
+get into the Android port.
+
+Video of my LCA2013 [git-annex talk](http://mirror.linux.org.au/linux.conf.au/2013/mp4/gitannex.mp4)
+is now available. I have not watched it yet, hope it turned out ok despite
+some technical difficulties!
diff --git a/doc/design/assistant/blog/day_181__triage.mdwn b/doc/design/assistant/blog/day_181__triage.mdwn
new file mode 100644
index 0000000000..9c5e92280c
--- /dev/null
+++ b/doc/design/assistant/blog/day_181__triage.mdwn
@@ -0,0 +1,23 @@
+Got fairly far along in my triage of my backlog, looking through everything
+that happened after January 23rd. Still 39 or so items to look at.
+
+There have been several reports of problems with ssh password prompts.
+I'm beginning to think the assistant may need to prompt for the password
+when setting up a ssh remote. This should be handled by `ssh-askpass` or
+similar, but some Linux users probably don't have it installed, and there
+seems to be no widely used OSX equivalent.
+
+---
+
+Fixed several bugs today, all involving (gasp) direct mode.
+
+The tricky one involved renaming or deleting files in direct mode.
+Currently nothing removes the old filename from the direct mode
+mapping, and this could result in the renamed or deleted file
+unexpectedly being put back into the tree when content is downloaded.
+
+To deal with this, it now assumes that direct mode mappings may be out of
+date compared to the tree, and does additional checks to catch
+inconsistencies. While that works well enough for the assistant,
+I'd also like to make the `pre-commit` hook update the mappings for files
+that are changed. That's needed to handle things like `git mv`.
diff --git a/doc/design/assistant/blog/day_182__it_begins.mdwn b/doc/design/assistant/blog/day_182__it_begins.mdwn
new file mode 100644
index 0000000000..48daea78fc
--- /dev/null
+++ b/doc/design/assistant/blog/day_182__it_begins.mdwn
@@ -0,0 +1,50 @@
+I need an Android development environment. I briefly looked into rooting
+the Asus Transformer so I could put a Debian chroot on it and build
+git-annex in there, but this quickly devolved to the typical maze of
+forum posts all containing poor instructions and dead links. Not worth it.
+
+Instead, I'm doing builds on my Sheevaplug, and once I have a static armel
+binary, will see what I need to do to get it running on Android.
+
+Fixed building with the webapp disabled, was broken by recent improvements.
+I'll be building without the webapp on arm initially, because ghci/template
+haskell on arm is still getting sorted out. (I tried ghc 7.6.2 and ghci is
+available, but doesn't quite work.)
+
+From there, I got a binary built pretty quickly (well, it's arm, so not *too*
+quickly). Then tried to make it static by appending 
+`-optl-static -optl-pthread` to the ghc command line.
+This failed with a bunch of errors:
+
+<pre>
+/usr/lib/gcc/arm-linux-gnueabi/4.6/../../../arm-linux-gnueabi/libxml2.a(nanohttp.o): In function `xmlNanoHTTPMethodRedir': (.text+0x2128): undefined reference to `inflateInit2_'
+/usr/lib/gcc/arm-linux-gnueabi/4.6/../../../arm-linux-gnueabi/libxml2.a(xzlib.o): In function `xz_decomp': (.text+0x36c): undefined reference to `lzma_code'
+...
+</pre>
+
+Disabling DBUS and (temporarily) XMPP got around that.
+
+Result!
+
+<pre>
+joey@leech:~/git-annex>ldd tmp/git-annex 
+        not a dynamic executable
+joey@leech:~/git-annex>ls -lha tmp/git-annex 
+-rwxr-xr-x 1 joey joey 18M Feb  6 16:23 tmp/git-annex*
+</pre>
+
+Next: Copy binary to Android device, and watch it fail in some interesting way.  
+Repeat.
+
+---
+
+Also more bug triage this morning...
+
+Got the pre-commit hook to update direct mode mappings.
+Uses `git diff-index HEAD` to find out what's changed. The only
+tricky part was detecting when `HEAD` doesn't exist yet. Git's
+plumbing is deficient in this area. Anyway, the mappings get updated
+much better now.
+
+Fixed a wacky bug where `git annex uninit` behaved badly on a filesystem
+that does not support hardlinks.
diff --git a/doc/design/assistant/blog/day_183__plan_b.mdwn b/doc/design/assistant/blog/day_183__plan_b.mdwn
new file mode 100644
index 0000000000..b310d0412e
--- /dev/null
+++ b/doc/design/assistant/blog/day_183__plan_b.mdwn
@@ -0,0 +1,19 @@
+Have not tried to run my static binary on Android yet, but I'm already
+working on a plan B in case that doesn't work. Yesterday I stumbled upon
+<https://github.com/neurocyte/ghc-android>, a ghc cross-compiler for
+Android that uses the Android native development kit. 
+It first appeared on February 4th. Good timing!
+
+I've gotten it to build and it emits arm executables, that seem to use the
+Android linker. So that's very promising indeed. 
+
+I've also gotten cabal working with it, and have it chewing through
+installing git-annex's build dependencies.
+
+----
+
+Also made a release today, this is another release that's mostly bugfixes,
+and a few minor features. Including one bug fixed at 6 am this morning, urk.
+
+I think I will probably split my days between working on Android porting
+and other git-annex development.
diff --git a/doc/design/assistant/blog/day_184__just_wanna_run_something.mdwn b/doc/design/assistant/blog/day_184__just_wanna_run_something.mdwn
new file mode 100644
index 0000000000..ac34293c3f
--- /dev/null
+++ b/doc/design/assistant/blog/day_184__just_wanna_run_something.mdwn
@@ -0,0 +1,46 @@
+Have been working on getting all the haskell libraries git-annex uses
+built with the android cross compiler. Difficulties so far are
+libraries that need tweaks to work with the new version of ghc, and some
+that use cabal in ways that break cross compilation. Haskell's network
+library was the last and most challenging of those.
+
+At this point, I'm able to start trying to build git-annex for android.
+Here's the first try!
+
+<pre>
+joey@gnu:~/src/git-annex>cabal install -w $HOME/.ghc-android-14-arm-linux-androideabi-4.7/bin/arm-unknown-linux-androideabi-ghc --with-ghc-pkg=$HOME/.ghc-android-14-arm-linux-androideabi-4.7/bin/arm-unknown-linux-androideabi-ghc-pkg --with-ld=$HOME/.ghc-android-14-arm-linux-androideabi-4.7/bin/arm-linux-androideabi-ld --flags="-Webapp -WebDAV -XMPP -S3 -Dbus"
+Resolving dependencies...
+Configuring git-annex-3.20130207...
+Building git-annex-3.20130207...
+Preprocessing executable 'git-annex' for git-annex-3.20130207...
+on the commandline: Warning:
+    -package-conf is deprecated: Use -package-db instead
+
+Utility/libdiskfree.c:28:26:
+     fatal error: sys/statvfs.h: No such file or directory
+compilation terminated.
+</pre>
+
+Should not be far from a first android build now..
+
+----
+
+While I already have Android "hello world" executables to try, I have not yet
+been able to run them. Can't seem to find a directory I can write to on the
+Asus Transformer, with a filesystem that supports the +x bit. Do you really
+have to root Android just to run simple binaries? I'm crying inside.
+
+It seems that the blessed Android NDK way would involve making a Java app,
+that pulls in a shared library that contains the native code. For haskell,
+the library will need to contain a C shim that, probably, calls an entry
+point to the Haskell runtime system. Once running, it can use the FFI to
+communicate back to the Java side, probably. The good news is that CJ van
+den Berg, who already saved my bacon once by developing ghc-android, tells
+me he's hard at work on that very thing.
+
+----
+
+In the meantime, downloaded the Android SDK. Have gotten it to build a
+`.apk` package from just javascript code, and managed to do it without
+using eclipse (thank god). Will need this later, but for now want to wash
+my brain out with soap after using it.
diff --git a/doc/design/assistant/blog/day_184__just_wanna_run_something/comment_1_689adac7e26cb0b0a4e7ecc787cfd716._comment b/doc/design/assistant/blog/day_184__just_wanna_run_something/comment_1_689adac7e26cb0b0a4e7ecc787cfd716._comment
new file mode 100644
index 0000000000..b6ad3ac7e0
--- /dev/null
+++ b/doc/design/assistant/blog/day_184__just_wanna_run_something/comment_1_689adac7e26cb0b0a4e7ecc787cfd716._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="hhm"
+ ip="108.17.80.177"
+ subject="Write and exec on unrooted Android."
+ date="2013-02-10T05:43:41Z"
+ content="""
+See <http://kevinboone.net/android_nonroot.html> for info on where in the android filesystem you have write, exec ability.
+
+Basically you have these abilities in `/data/local` from `adb shell` (and in debuggable app's folders using run-as with `adb shell`), and in `/data/data/<app_id>/` for each app (for example the terminal emulator's data dir when using the terminal emulator).
+
+It might be possible to just have temporary root using an old exploit and writing up a bit of code to just setuid on the process and exec sh (source for nachoroot exploit <https://github.com/CunningLogic/NachoRoot>).
+
+It *is* possible to install a distro without root using a chroot faker.
+
+I am working here <https://sites.google.com/site/taldewandroid/> on a way to install the OpenWrt distro on Android. This is working on my phone already for quite a while! So far only sketchy notes are up, but more to come, G-d willing.
+"""]]
diff --git a/doc/design/assistant/blog/day_185__android_liftoff.mdwn b/doc/design/assistant/blog/day_185__android_liftoff.mdwn
new file mode 100644
index 0000000000..88fc5635ca
--- /dev/null
+++ b/doc/design/assistant/blog/day_185__android_liftoff.mdwn
@@ -0,0 +1,20 @@
+Thanks to hhm, who pointed me at [KBOX](http://kevinboone.net/kbox.html),
+I have verified that I can build haskell programs that work on Android.
+
+After hacking on it all day, I've succeeded in making an initial build of
+git-annex for Android. It links! It runs!
+
+Which is not to say it's usable yet; for one thing I need to get a port
+of git before it can do anything useful. (Some of the other things git-annex
+needs, like ssh and sha256sum, are helpfully provided by KBOX.)
+
+Next step will be to find or built a git port for Android. I know there's
+one in the "Terminal IDE" app. Once I can use git-annex at the command line
+on Android, I'll be able to test it out some (I can also port the test
+suite program and run it on Android), and get a feeling for what is needed
+to get the port to a usable command-line state.
+
+And then on to the webapp, and an Android app, I suppose. So far, the port
+doesn't include the webapp, but does include the assistant. The webapp
+needs ghci/template haskell for arm. A few people have been reporting they
+have that working, but I don't yet.
diff --git a/doc/design/assistant/blog/day_185__android_liftoff/comment_1_b7d28010a72619a7e9a5ad4f2a0d6c07._comment b/doc/design/assistant/blog/day_185__android_liftoff/comment_1_b7d28010a72619a7e9a5ad4f2a0d6c07._comment
new file mode 100644
index 0000000000..c0d336b115
--- /dev/null
+++ b/doc/design/assistant/blog/day_185__android_liftoff/comment_1_b7d28010a72619a7e9a5ad4f2a0d6c07._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://mlinden.myopenid.com/"
+ ip="2001:470:d1c3:0:5c01:5562:e242:37b9"
+ subject="&quot;Build native GNU/Linux applications: the easy way&quot;"
+ date="2013-02-10T22:02:19Z"
+ content="""
+Maybe this helps:
+[[http://forum.xda-developers.com/showthread.php?t=1444792]]
+"""]]
diff --git a/doc/design/assistant/blog/day_185__android_liftoff/comment_2_ddeb24e86fafb7dae93142cc02767aad._comment b/doc/design/assistant/blog/day_185__android_liftoff/comment_2_ddeb24e86fafb7dae93142cc02767aad._comment
new file mode 100644
index 0000000000..ed0c3dc317
--- /dev/null
+++ b/doc/design/assistant/blog/day_185__android_liftoff/comment_2_ddeb24e86fafb7dae93142cc02767aad._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnbBRfl5F8gKRr1ko8Ai6FbEZStXXNF1S4"
+ nickname="Áron"
+ subject="another android git app"
+ date="2013-02-11T08:20:42Z"
+ content="""
+https://play.google.com/store/apps/details?id=com.madgag.agit&hl=en
+
+I used it and its decent and certainly runs git as a backend (although I havent seen its internals)
+"""]]
diff --git a/doc/design/assistant/blog/day_186__Android_success.mdwn b/doc/design/assistant/blog/day_186__Android_success.mdwn
new file mode 100644
index 0000000000..8ede7f29a5
--- /dev/null
+++ b/doc/design/assistant/blog/day_186__Android_success.mdwn
@@ -0,0 +1,33 @@
+I'm now successfully using git-annex at the command line on Android.
+`git annex watch` works too.
+
+For now, I'm using a git repository under `/data`, which is on a real,
+non-cripped filesystem, so symlinks work there.
+
+There's still the issue of running without any symlinks on `/mnt/sdcard`.
+While direct mode gets most of the way, it still uses symlinks in a few
+places, so some more work will be needed there. Also, git-annex uses hard
+links to lock down files, which won't work on cripped filesystems.
+
+Besides that, there's lots of minor porting, but no big show-stoppers
+currently.. Some of today's porting work:
+
+* Cross-compiled git for Android. While the Terminal IDE app has some git
+  stuff, it's not complete and misses a lot of plumbing commands git-annex
+  uses. My git build needs some tweaks to be relocatable without setting
+  `GIT_EXEC_PATH`, but it works.
+
+* Switched git-annex to use the Haskell glob library, rather than PCRE. This
+  avoids needing libpcre, which simplifies installation on several platforms
+  (including Android).
+
+* Made git-annex's `configure` hardcode some settings when cross-compiling
+  for Android, rather than probing the build system.
+
+* Android's built-in `lsof` doesn't support the -F option to use a
+  machine-readable output format. So wrote a separate lsof output parser for
+  the standard lsof output format. Unfortunatly, Android's lsof does not
+  provide any information about where a file is open for read or write, so
+  for safety, git-annex has to assume any file that's open might be written
+  to, and avoid annexing it. It might be better to provide my own lsof
+  eventually.
diff --git a/doc/design/assistant/blog/day_186__Android_success/comment_1_1629da240ca7db5f8a32059f561fd435._comment b/doc/design/assistant/blog/day_186__Android_success/comment_1_1629da240ca7db5f8a32059f561fd435._comment
new file mode 100644
index 0000000000..07ef87bb4f
--- /dev/null
+++ b/doc/design/assistant/blog/day_186__Android_success/comment_1_1629da240ca7db5f8a32059f561fd435._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2013-02-12T10:24:50Z"
+ content="""
+heh, +1 for removing the need for pcre
+"""]]
diff --git a/doc/design/assistant/blog/day_187__porting_utilities.mdwn b/doc/design/assistant/blog/day_187__porting_utilities.mdwn
new file mode 100644
index 0000000000..496c74a1f5
--- /dev/null
+++ b/doc/design/assistant/blog/day_187__porting_utilities.mdwn
@@ -0,0 +1,22 @@
+Ported all the utilities git-annex needs to run on Android: 
+git, rsync, gnupg, dropbear (ssh client), busybox. Built a
+Makefile that can download, patch, and cross build these from source.
+
+While all the utilities work, dropbear doesn't allow git-annex to use ssh
+connection caching, which is rather annoying especially since these systems
+tend to be rather slow and take a while to start up ssh connections.
+I'd sort of like to try to get openssh's client working on Android instead.
+Don't know how realistic that is.
+
+Dealt with several parts of git-annex that assumed `/bin/sh` exists,
+so it instead uses `/system/bin/sh` on Android. Also adapted `runshell`
+for Android.
+
+Now I have a 8 mb compressed tarball for Android.
+Uncompressed it's 25 mb. This includes a lot of git and busybox
+commands that won't be used, so it could be trimmed down further.
+16 mb of it is git-annex itself.
+
+[[Instructions for using the Android tarball|install/Android]]  
+This is for users who are rather brave, not afraid of command line and
+keyboard usage. Good first step.
diff --git a/doc/design/assistant/blog/day_187__porting_utilities/comment_1_0e6a3f4fe8e09f247fa04156bc60f8c7._comment b/doc/design/assistant/blog/day_187__porting_utilities/comment_1_0e6a3f4fe8e09f247fa04156bc60f8c7._comment
new file mode 100644
index 0000000000..e25ff1c15c
--- /dev/null
+++ b/doc/design/assistant/blog/day_187__porting_utilities/comment_1_0e6a3f4fe8e09f247fa04156bc60f8c7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://a-or-b.myopenid.com/"
+ ip="203.45.2.230"
+ subject="comment 1"
+ date="2013-02-13T22:16:17Z"
+ content="""
+In addition to dropbear, there is ConnectBot <https://code.google.com/p/connectbot/> which might make the ssh side of the equation simpler.  I prefer it because it is half the size of dropbear.
+"""]]
diff --git a/doc/design/assistant/blog/day_188__crippled_filesystem_support.mdwn b/doc/design/assistant/blog/day_188__crippled_filesystem_support.mdwn
new file mode 100644
index 0000000000..48f6069d45
--- /dev/null
+++ b/doc/design/assistant/blog/day_188__crippled_filesystem_support.mdwn
@@ -0,0 +1,37 @@
+There are at least three problems with using git-annex
+on `/sdcard` on Android, or on a FAT filesystem, or on (to a first
+approximation) Windows:
+
+1. symlinks
+2. hard links
+3. unix permissions
+
+So, I've added an `annex.crippledfilesystem` setting. `git annex init` now
+probes to see if all three are supported, and if not, enables that, as well
+as direct mode.
+
+In crippled filesystem mode, all the permissions settings are skipped.
+Most of them are only used to lock down content in the annex in indirect
+mode anyway, so no great loss.
+
+There are several uses of hard links, most of which can be dealt with by
+making copies. The one use of permissions and hard links I absolutely
+needed to deal with was that they're used to lock down a file as it's being
+ingested into the annex. That can't be done on crippled filesystems, so I
+made it instead check the metadata of the file before and after to detect
+if it changed, the same way direct mode detects when files are modified.
+This is likely better than the old method anyway.
+
+The other reason files are hardlinked while they're being ingested is that
+this allows running lsof on a single directory of files that are in the
+process of being added, to detect if anything has them open for write.
+I still need to adjust the lsof check to work in crippled filesystem mode.
+It seems this won't make it much slower to run lsof on the whole repository.
+
+At this point, I can use git-annex with a repository on `/sdcard` or a FAT
+filesystem, and at least `git annex add` works. 
+
+Still several things on the TODO list before crippled filesystem mode is
+complete. The only one I'm scared about is making `git merge` do something
+sane when it wants to merge two trees full of symlinks, and the filesystem
+doesn't let it create a symlink..
diff --git a/doc/design/assistant/blog/day_188__crippled_filesystem_support/comment_1_32a296fce23ae4b1e18bd5a9964bf619._comment b/doc/design/assistant/blog/day_188__crippled_filesystem_support/comment_1_32a296fce23ae4b1e18bd5a9964bf619._comment
new file mode 100644
index 0000000000..2796964e0e
--- /dev/null
+++ b/doc/design/assistant/blog/day_188__crippled_filesystem_support/comment_1_32a296fce23ae4b1e18bd5a9964bf619._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://nullroute.eu.org/~grawity/"
+ nickname="Mantas"
+ subject="comment 1"
+ date="2013-02-15T00:38:00Z"
+ content="""
+Windows supports hardlinks on NTFS filesystems. Not sure about the privileges needed; I think all users can create them.
+
+Recent versions also support symlinks, but that's limited to Administrators by default, so Cygwin-Git (like the rest of Cygwin) uses special files with the \"system\" flag.
+
+As far as I know, Git does not try to dereference symlinks when merging – it only tracks the paths they point to. Where symlinks are not supported (e.g. vfat filesystems in general, or msysGit on Windows) it simply creates regular files containing the target path (i.e. the raw contents of the respective blobs).
+
+Regarding the use of Unix permissions: The \"open file\" syscall on Windows has a \"share mode\" flag, which can be used to disallow other programs from opening the file for writing (and/or even reading) as long as git-annex keeps it open. (I guess this is similar to mandatory locks in Linux.)
+"""]]
diff --git a/doc/design/assistant/blog/day_189__more_crippling.mdwn b/doc/design/assistant/blog/day_189__more_crippling.mdwn
new file mode 100644
index 0000000000..f3ddad2667
--- /dev/null
+++ b/doc/design/assistant/blog/day_189__more_crippling.mdwn
@@ -0,0 +1,44 @@
+Finished crippled filesystem support, except for symlink handling.
+This was straightforward, just got lsof working in that mode, made
+`migrate` copy key contents, and adapted the rsync special remote to
+support it. Encrypted rsync special remotes have no more overhead on
+crippled filesystems than normally. Un-encrypted rsync special remotes
+have some added overhead, but less than encrypted remotes. Acceptable
+for now.
+
+I've now successfully run the assistant on a FAT filesystem.
+
+----
+
+Git handles symlinks on crippled filesystems by setting
+`core.symlinks=false` and checking them out as files containing the link
+text. So to finish up crippled filesystem support, git-annex needs to
+do the same whenever it creates a symlink, and needs to read file contents
+when it normally reads a symlink target.
+
+There are rather a lot of calls to `createSymbolicLink`,
+`readSymbolicLink`, `getSymbolicLinkStatus`, `isSymbolicLink`, and `isSymLink`
+in the tree; only ones that are used in direct mode
+need to be converted. This will take a while.
+
+Checking whether something is a symlink, or where it points is especially
+tricky. How to tell if a small file in a git working tree is intended to be
+a symlink or not? Well, it can look at the content and see if it makes
+sense as a link text pointing at a git-annex key. As long as the
+possibility of false positives is ok. It might be possible, in some cases,
+to query git to verify if the object stored for that file is really a
+symlink, but that won't work if the file has been renamed, for example.
+
+Converted some of the most commonly used symlink code to handle this.
+Much more to do, but it basically works; I can `git annex get` and `git
+annex drop` on FAT, and it works.
+
+-----
+
+Unfortunately, got side-tracked when I discovered that the last release
+introduced a bug in direct mode. Due to the bug, "git annex get file; git annex
+drop file; git annex get file" would end up with the file being an indirect
+mode symlink to the content, rather than a direct mode file. No data loss,
+but not right. So, spent several hours fixing that reversion, which was
+caused by me stupidly fixing another bug at 5 am in the morning last week.. 
+and I'll probably be pushing out another release tomorrow with the fix.
diff --git a/doc/design/assistant/blog/day_18__merging.mdwn b/doc/design/assistant/blog/day_18__merging.mdwn
new file mode 100644
index 0000000000..f963cf85dd
--- /dev/null
+++ b/doc/design/assistant/blog/day_18__merging.mdwn
@@ -0,0 +1,82 @@
+Worked on automatic merge conflict resolution today. I had expected to be
+able to use git's merge driver interface for this, but that interface is
+not sufficient. There are two problems with it:
+
+1. The merge program is run when git is in the middle of an operation
+   that locks the index. So it cannot delete or stage files. I need to
+   do both as part of my conflict resolution strategy.
+2. The merge program is not run at all when the merge conflict is caused
+   by one side deleting a file, and the other side modifying it. This is
+   an important case to handle.
+
+So, instead, git-annex will use a regular `git merge`, and if it fails, it
+will fix up the conflicts.
+
+That presented its own difficulty, of finding which files in the tree
+conflict. `git ls-files --unmerged` is the way to do that, but its output
+is a quite raw form:
+
+	120000 3594e94c04db171e2767224db355f514b13715c5 1	foo
+	120000 35ec3b9d7586b46c0fd3450ba21e30ef666cfcd6 3	foo
+	100644 1eabec834c255a127e2e835dadc2d7733742ed9a 2	bar
+	100644 36902d4d842a114e8b8912c02d239b2d7059c02b 3	bar
+
+I had to stare at the rather impenetrable documentation for hours and
+write a lot of parsing and processing code to get from that to these mostly
+self explanatory data types:
+
+	data Conflicting v = Conflicting
+	        { valUs :: Maybe v
+	        , valThem :: Maybe v
+	        } deriving (Show)
+
+	data Unmerged = Unmerged
+	        { unmergedFile :: FilePath
+	        , unmergedBlobType :: Conflicting BlobType
+	        , unmergedSha :: Conflicting Sha
+	        } deriving (Show)
+
+Not the first time I've whined here about time spent parsing unix command
+output, is it? :)
+
+From there, it was relatively easy to write the actual conflict cleanup
+code, and make `git annex sync` use it. Here's how it looks:
+
+	$ ls -1
+	foo.png
+	bar.png
+	$ git annex sync
+	commit  
+	# On branch master
+	nothing to commit (working directory clean)
+	ok
+	merge synced/master 
+	CONFLICT (modify/delete): bar.png deleted in refs/heads/synced/master and modified in HEAD. Version HEAD of bar.png left in tree.
+	Automatic merge failed; fix conflicts and then commit the result.
+	bar.png: needs merge
+	(Recording state in git...)
+	[master 0354a67] git-annex automatic merge conflict fix
+	ok
+	$ ls -1
+	foo.png
+	bar.variant-a1fe.png
+	bar.variant-93a1.png
+
+There are very few options for ways for the conflict resolution code to
+name conflicting variants of files. The conflict resolver can only use data
+present in git to generate the names, because the same conflict needs to 
+be resolved the same everywhere.
+
+So I had to choose between using the full key name in the filenames produced
+when resolving a merge, and using a shorter checksum of the key, that would be
+more user-friendly, but could theoretically collide with another key. 
+I chose the checksum, and weakened it horribly by only using 32 bits of it!
+
+Surprisingly, I think this is a safe choice. The worst that can
+happens if such a collision happens is another conflict, and the conflict
+resolution code will work on conflicts produced by the conflict resolution
+code! In such a case, it does fall back to putting the whole key in
+the filename:
+"bar.variant-SHA256-s2550--2c09deac21fa93607be0844fefa870b2878a304a7714684c4cc8f800fda5e16b.png"
+
+Still need to hook this code into `git annex assistant`.
diff --git a/doc/design/assistant/blog/day_18__merging/comment_1_7a553ad559519f3b3e3cd20115b4c44e._comment b/doc/design/assistant/blog/day_18__merging/comment_1_7a553ad559519f3b3e3cd20115b4c44e._comment
new file mode 100644
index 0000000000..94261f81eb
--- /dev/null
+++ b/doc/design/assistant/blog/day_18__merging/comment_1_7a553ad559519f3b3e3cd20115b4c44e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://droggl.myopenid.com/"
+ ip="2001:638:602:1181:a6ba:dbff:fedd:8041"
+ subject="comment 1"
+ date="2013-09-11T11:55:27Z"
+ content="""
+Nice!
+However I didnt find any documentation yet on how to actually resolve the situation as a user (sorry if I'm being blind).
+To be more specific: Say a conflict occurs on foo.txt and i now have two files foo.variant-dead.txt and foo.variant-beef.txt.
+Now what? Say I used my favorite merge diffmerge tool to create a merged version foo-merged.txt, should I rename that to foo.txt?
+Should I delete the variant files? Or drop them? Or would that lead to another merge for systems that still have the old foo.txt?
+(You see I'm kind of confused of what happens here ;))
+
+TIA for any helpers
+"""]]
diff --git a/doc/design/assistant/blog/day_190-191__weekend.mdwn b/doc/design/assistant/blog/day_190-191__weekend.mdwn
new file mode 100644
index 0000000000..21e46529a7
--- /dev/null
+++ b/doc/design/assistant/blog/day_190-191__weekend.mdwn
@@ -0,0 +1,28 @@
+Pushed out a release yesterday mostly for a bug fix. I have to build
+git-annex 5 times now when releasing. Am wondering if I could get rid of
+the Linux 64 bit standalone build. The 32 bit build should run ok on 64 bit
+Linux systems, since it has all its own 32 bit libraries. What I really
+need to do is set up autobuilders for Linux and Android, like we have for OSX.
+
+Today, dealt with all code that creates or looks at symlinks. Audited every
+bit of it, and converted all relevant parts to use a new abstraction layer
+that handles the pseudolink files git uses when core.symlinks=false.
+This is untested, but I'm quite happy with how it turned out.
+
+----
+
+Where next for Android? I want to spend a while testing command-line
+git-annex. After I'm sure it's really solid, I should try to get the webapp
+working, if possible.
+
+I've heard rumors that Ubuntu's version of ghc somehow supports template
+haskell on arm, so I need to investigate that. If I am unable to get
+template haskell on arm, I would need to either wait for further
+developments, or try to expand yesod's template haskell to regular haskell
+and then build it on arm, or I could of course switch away from hamlet
+(using blaze-html instead is appealing in some ways) and
+use yesod in non-template-haskell mode entirely. One of these will work,
+for sure, only question is how much pain.
+
+After getting the webapp working, there's still the issue of bundling it
+all up in an Android app that regular users can install.
diff --git a/doc/design/assistant/blog/day_190-191__weekend/comment_1_dbd692d12c14d08acd7d73a655b34e8b._comment b/doc/design/assistant/blog/day_190-191__weekend/comment_1_dbd692d12c14d08acd7d73a655b34e8b._comment
new file mode 100644
index 0000000000..965a762e6a
--- /dev/null
+++ b/doc/design/assistant/blog/day_190-191__weekend/comment_1_dbd692d12c14d08acd7d73a655b34e8b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://jasonwoof.com/"
+ nickname="JasonWoof"
+ subject="phonegap might help"
+ date="2013-02-17T22:43:06Z"
+ content="""
+In your research to see how to bundle up a graphical android app, I suggest you read up on phonegap: http://phonegap.com/
+
+Essentially they bundle webkit so you can turn a web app into an android app. Not sure if they help you ship native/binary stuff along side the html/javascript/css, but phonegap should at least be useful as a reference for how to do some of the bundling-related stuff.
+"""]]
diff --git a/doc/design/assistant/blog/day_190-191__weekend/comment_2_c813830e53471a9732e010a748d574fc._comment b/doc/design/assistant/blog/day_190-191__weekend/comment_2_c813830e53471a9732e010a748d574fc._comment
new file mode 100644
index 0000000000..bdda398b06
--- /dev/null
+++ b/doc/design/assistant/blog/day_190-191__weekend/comment_2_c813830e53471a9732e010a748d574fc._comment
@@ -0,0 +1,28 @@
+[[!comment format=c
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="Two direct mode repository on the same computer"
+ date="2013-02-19T09:24:21Z"
+ content="""
+Hi,
+
+I just tried the newest git annex webapp (20130216), 
+I am still not able to configure two direct mode repositories (one normal, one backup) on the same computer.
+
+It does recognize my other partition (/mnt/the) as a removable drive, but when I add it 
+it gives me internal server error:
+\"\"\"
+Internal Server Error
+
+there is no available git remote named \"the\"
+git-annex version 3.20130216
+\"\"\"
+
+Could you please (pretty please) add a possibility to specify the removable drive as a simple folder?
+So I could choose arbitrary folder(/mnt/the/annex-backup) on my computer and 
+it would treat it as a direct mode repository.
+
+Best, 
+ Laszlo
+
+"""]]
diff --git a/doc/design/assistant/blog/day_192_193__more_porting.mdwn b/doc/design/assistant/blog/day_192_193__more_porting.mdwn
new file mode 100644
index 0000000000..59f7cf8369
--- /dev/null
+++ b/doc/design/assistant/blog/day_192_193__more_porting.mdwn
@@ -0,0 +1,44 @@
+Felt spread thin yesterday, as I was working on multiple things
+concurrently & bouncing around as compiles finished. Been working to get
+openssh to build for Android, which is quite a pain, starting with getting
+openssl to build and then dealing with the Cyanogenmod patches, some of
+which are necessary to build on Android and some of which break builds
+outside Cyanogenmod. At the same time was testing git-annex on Android.
+Found and fixed several more portability bugs while doing that. And on the
+back burner I was making some changes to the webapp..
+
+(Forgot to commit my blog post yesterday too..)
+
+Today, that all came together.
+
+* When adding another local repository in the webapp, 
+  it now allows you to choose whether it should be combined with
+  your current repository, or kept separate. Several people had requested
+  a way to add local clones with the webapp, for various reasons, like
+  wanting a backup repository, or wanting to make a repository on a NFS
+  server, and this allows doing that.
+
+[[!img /assistant/combinerepos.png]]
+
+* More porting fun. FAT filesystems and other things used on Android can
+  get all new inode numbers each time mounted. Made git-annex use a
+  sentinal file to detect when this has happened, since in direct mode
+  it compares inodes. (As a bonus this also makes copying direct mode
+  repositories between filesystems work.)
+
+* Got openssh building for Android. Changed it to use $HOME/.ssh rather
+  than trusting pwent.
+
+* Got git-annex's ssh connection caching working on Android. That needs
+  a place where it can create a socket. When the
+  repository is on a crippled filesystem, it instead puts the socket
+  in a temporary directory set up on the filesystem where the git-annex
+  program resides.
+
+With ssh connection caching, transferring multiple files off my Android
+tablet *screams*! I was seeing 6.5 megabytes transferred per second,
+sustained over a whole month's worth of photos.
+
+Next problem: `git annex assistant` on Android is for some reason crashing
+with a segfault on startup. Especially odd since `git annex watch` works.
+I'm so close to snap-photo-and-it-syncs-nirvana, but still so far away...
diff --git a/doc/design/assistant/blog/day_194__nice_moment.mdwn b/doc/design/assistant/blog/day_194__nice_moment.mdwn
new file mode 100644
index 0000000000..1a5ee9b1ea
--- /dev/null
+++ b/doc/design/assistant/blog/day_194__nice_moment.mdwn
@@ -0,0 +1,37 @@
+<video controls src="http://downloads.kitenet.net/videos/git-annex-android.ogv" width="100%"></video>
+<a href="http://downloads.kitenet.net/videos/git-annex-android.ogv">video</a>
+
+Today's work:
+
+* Fixed `git annex add` of a modified file in direct mode.
+* Fixed bugs in the inode sentinal file code added yesterday.
+* With some help from Kevin Boone, I now understand how KBOX works and
+  how to use similar techniques to build my own standalone Android app
+  that includes git-annex.
+
+  Kevin is using a cute hack; he ships a tarball and some other stuff
+  as (pseudo-)library files (`libfoo.so`), which are the only files
+  the Android package manager deigns to install. Then the app runs one
+  of these, which installs the programs.
+
+  This avoids needing to write Java code that extracts the programs from
+  one of its assets and writes it to an executable file, which is the
+  canonical way to do this sort of thing. But I noticed it has a benefit too
+  (which KBOX does not yet exploit). Since the pseudo-library file is installed
+  with the X bit set, if it's really a program, such as busybox or git-annex,
+  that program can be run without needing to copy it to an executable file.
+  This can save a lot of disk space. So, I'm planning to include all
+  the binaries needed by git-annex as these pseudo-libraries.
+* Got the Android Terminal Emulator to build. I will be basing my first
+  git-annex Android app on this, since a terminal is needed until there's 
+  a webapp.
+* Wasted several hours fighting with `Android.mk` files to include
+  my pseudo shared library. This abuse of Makefiles by the NDK is what CDBS
+  wants to grow up to be.. or is it the other way around? Anyway, it
+  sucks horribly, and I finally found a way to do it without
+  modifying the file at all. Ugh.
+* At this point, I can build a `git-annex.apk` file containing a
+  `libgit-annex.so`, and a `libbusybox.so`, that can both be directly
+  run. The plan from here is to give git-annex the ability to
+  auto-install itself, and the other pseudo-libraries, when it's run as
+  `libgit-annex.so`.
diff --git a/doc/design/assistant/blog/day_195__real_android_app.mdwn b/doc/design/assistant/blog/day_195__real_android_app.mdwn
new file mode 100644
index 0000000000..f6a4eeebe3
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app.mdwn
@@ -0,0 +1,32 @@
+Well, it's built. [Real Android app for git-annex](http://downloads.kitenet.net/git-annex/android/current/).
+
+[[!img /android/appinstalled.png]]
+
+When installed, this will open a terminal in which you have access to
+git-annex and all the git commands and busybox commands as well. No webapp
+yet, but command line users should feel right at home.
+
+[[!img /android/terminal.png]]
+
+Please test it out, at least as far as installing it, opening the terminal,
+and checking that you can run `git annex`; I've only been able to test on
+one Android device so far. I'm especially keen to know if it works with
+newer versions of Android than 4.0.3. (I know it only supports arm based
+Android, no x86 etc.) Please comment if you tried it.
+
+----
+
+Building this went mostly as planned, although I had about 12 builds of
+the app in the middle which crashed on startup with no error message ora
+logs. Still, it took only one day to put it all together,
+ and I even had time to gimp up a quick icon. (Better icons welcome.)
+
+Kevin thinks that my space-saving hack won't work on all Androiden, and he
+may be right. If the `lib` directory is on a different filesystem on some
+devices, it will fail. But I used it for now anyhow. Thanks to the hack,
+the 7.8 mb compressed .apk file installs to use around 23 mb of disk space.
+
+----
+
+Tomorrow: Why does `git-annex assistant` on Android re-add all existing
+files on startup?
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_10_0112007552b30cd9bfeac614a1e399c4._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_10_0112007552b30cd9bfeac614a1e399c4._comment
new file mode 100644
index 0000000000..cc24c08c34
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_10_0112007552b30cd9bfeac614a1e399c4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.253.75"
+ subject="comment 10"
+ date="2013-02-22T17:30:59Z"
+ content="""
+@rillian could you try to install KBOX <http://kevinboone.net/Term-debug.apk> and see if its terminal accepts input? It's the same terminal app, so will be good to know if I broke it or this is a wider problem.
+
+Also, did you try the soft keyboard? There's a menu item to enable it.
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_11_230d3c169c713f613b9d607d84ce5092._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_11_230d3c169c713f613b9d607d84ce5092._comment
new file mode 100644
index 0000000000..a984dd339a
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_11_230d3c169c713f613b9d607d84ce5092._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="rillian"
+ ip="64.213.70.194"
+ subject="Re: no keybourd events on Galaxy Tab 10.1"
+ date="2013-02-22T18:28:11Z"
+ content="""
+KBOX has the same input problem so you didn't break anything with your changes.
+
+I was testing with the soft keyboard. Turns out the spacebar and number keys on the soft keyboard work, as well as return, just not the alphabetic keys.
+
+Trying on a hardware keyboard (Samsung docking station) is similar. Space, Enter and numbers work, but not letters. There's some additional confusion about shift state, where it gets confused and reports shifted digits from the hardware keys when the soft keyboard is in some shift states. E.g. switching the soft keyboard to numeric mode results in shift-digits (punctuation) from the hardware numeric keys.
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_12_8d74ad2a61c02272758d157282ad56ec._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_12_8d74ad2a61c02272758d157282ad56ec._comment
new file mode 100644
index 0000000000..76aee55fd6
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_12_8d74ad2a61c02272758d157282ad56ec._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.253.75"
+ subject="comment 12"
+ date="2013-02-22T18:35:35Z"
+ content="""
+@rillian the upstream for this terminal is <https://github.com/jackpal/Android-Terminal-Emulator/>
+and I found a bug that looks similar. <https://github.com/jackpal/Android-Terminal-Emulator/issues/129>
+You might add your info there, and try the workaround documented there.
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_13_4f6bc0680f2debd638933968a26975e0._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_13_4f6bc0680f2debd638933968a26975e0._comment
new file mode 100644
index 0000000000..455029a411
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_13_4f6bc0680f2debd638933968a26975e0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.253.75"
+ subject="comment 13"
+ date="2013-02-22T19:39:15Z"
+ content="""
+@Karsten does KBOX work on this version of Android? <http://kevinboone.net/Term-debug.apk>
+
+It may well be that this is just too old and incompatible for the terminal to work.
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_14_71539c62608866464e8faa76bc522a55._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_14_71539c62608866464e8faa76bc522a55._comment
new file mode 100644
index 0000000000..bfb12f24a6
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_14_71539c62608866464e8faa76bc522a55._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://meep.pl/"
+ ip="193.23.174.18"
+ subject="comment 14"
+ date="2013-02-22T21:45:54Z"
+ content="""
+On Android 2.3.3 (Samsung Galaxy S+) KBOX works, git-annex displays the \"Terminal session is running\" notification and dies immediately.
+
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_15_e1b205289721ae79ac7fbed2f44018b2._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_15_e1b205289721ae79ac7fbed2f44018b2._comment
new file mode 100644
index 0000000000..e48ee71349
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_15_e1b205289721ae79ac7fbed2f44018b2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.253.75"
+ subject="comment 15"
+ date="2013-02-22T22:26:22Z"
+ content="""
+I'm seeing a pattern with Android 2.3 failing.. 
+
+This failure mode suggests that the bug is in the installation script. The next build will make the terminal not exit immediately if that script fails, so you can go in to the shell and run it by hand to see what's going wrong.
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_1_4bc0aeae4fa1116944644c64feaf9697._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_1_4bc0aeae4fa1116944644c64feaf9697._comment
new file mode 100644
index 0000000000..05e3d298b5
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_1_4bc0aeae4fa1116944644c64feaf9697._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://andrew.aylett.co.uk/"
+ nickname="andrew"
+ subject="Works on Samsung Galaxy S3"
+ date="2013-02-21T23:23:08Z"
+ content="""
+Installed, executed and managed to get the help text on a Samsung Galaxy S3 running 4.1.2.  Not tried anything else yet, but looks good so far, thank you very much :).
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_2_17bb6e7565d4c757f6c1e3514c22f47d._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_2_17bb6e7565d4c757f6c1e3514c22f47d._comment
new file mode 100644
index 0000000000..138518bdb8
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_2_17bb6e7565d4c757f6c1e3514c22f47d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlmNbexnCgLywD0MKyT9mG9mWFb_qVj-8I"
+ nickname="Joshua"
+ subject="Toshiba Excite 7.7 (Android 4.1.1)"
+ date="2013-02-22T00:15:46Z"
+ content="""
+Seems to run fine. I managed to create a repository, git-annex init it (had to set email and name per repository). 
+
+The first time I tried git-annex init it said \"Detected a crippled file system.\" \"Enabling direct mode.\" The final try that actually worked only mentioned the crippled filesystem and not direct mode.
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_3_cd8a6bec0f7c6843dd11d3266f25f864._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_3_cd8a6bec0f7c6843dd11d3266f25f864._comment
new file mode 100644
index 0000000000..643605d5b6
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_3_cd8a6bec0f7c6843dd11d3266f25f864._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"
+ nickname="Jim"
+ subject="Installs and runs"
+ date="2013-02-22T00:17:30Z"
+ content="""
+No problem installing on a Galaxy Nexus with 4.2.2
+
+    1|u0_a162@android:/sdcard $ git clone https://git.jim.sh/jim/annex.git
+    Cloning into 'annex'...
+    fatal: Unable to find remote helper for 'https'
+
+Too much to hope for at this stage, I suppose :)
+
+    128|u0_a162@android:/sdcard $ git annex assistant
+    git-annex: Not in a git repository.
+    1|u0_a162@android:/sdcard $ git init test
+    Initialized empty Git repository in /storage/emulated/legacy/test/.git/
+    u0_a162@android:/sdcard $ cd test
+    u0_a162@android:/sdcard/test $ git annex init
+    init
+      Detected a crippled filesystem.
+    
+      Enabling direct mode.
+    
+    *** Please tell me who you are.
+    
+    Run
+    
+      git config --global user.email \"you@example.com\"
+      git config --global user.name \"Your Name\"
+    
+    to set your account's default identity.
+    Omit --global to set the identity only in this repository.
+    
+    fatal: unable to auto-detect email address (got 'u0_a162@localhost.(none)')
+    
+    git-annex: user error (git [\"--git-dir=/storage/emulated/legacy/test/.git\",\"--work-tree=/storage/emulated/legacy/test\",\"commit-tree\",\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\"] exited 128)
+    failed
+    git-annex: init: 1 failed
+    1|u0_a162@android:/sdcard/test $
+
+However, I get the same error even after setting `user.email` and `user.name` (which seems to work fine)
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_4_2d2eee4bcbbd1d069a80bff5edc90c3c._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_4_2d2eee4bcbbd1d069a80bff5edc90c3c._comment
new file mode 100644
index 0000000000..acb022e132
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_4_2d2eee4bcbbd1d069a80bff5edc90c3c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.253.75"
+ subject="comment 4"
+ date="2013-02-22T00:54:56Z"
+ content="""
+@jim git http support is disabled to save space
+
+What seems to work is: git config user.email \"you@example.com\" 
+
+It's probably looking in the wrong place for the global .gitconfig so --global doesn't work. The assistant
+also automates dealing with this problem BTW.
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_6_3d96568c469a8c53a982f304eae5e7d4._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_6_3d96568c469a8c53a982f304eae5e7d4._comment
new file mode 100644
index 0000000000..0fc0a5cecf
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_6_3d96568c469a8c53a982f304eae5e7d4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="rillian"
+ ip="174.6.6.167"
+ subject="no keybourd events on Galaxy Tab 10.1"
+ date="2013-02-22T06:54:54Z"
+ content="""
+Hey, thanks for working on this.
+
+I tried the Feb 21 apk on my Samsung galaxy Tab 10.1 with Android 4.0.4. It installed and launched fine, bringing up a terminal window, keyboard, etc, but only the return key works. It's not possible to type znything. The menus, new window button etc all seem to be functional.
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_6_e8667c47d07fc842cf0fe2ebbfbc1c58._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_6_e8667c47d07fc842cf0fe2ebbfbc1c58._comment
new file mode 100644
index 0000000000..8f1c71bad6
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_6_e8667c47d07fc842cf0fe2ebbfbc1c58._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 6"
+ date="2013-02-22T07:00:41Z"
+ content="""
+Installed on Cyanogenmod 7.2 (Android 2.3.7) on my HTC Desire. When starting the App \"Terminalsitzung wird ausgeführt\" (Terminalsession is started) shows in the statusline, then the app immediately closes.
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_7_cf8da7720ddc20b05955ee671ca4acd5._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_7_cf8da7720ddc20b05955ee671ca4acd5._comment
new file mode 100644
index 0000000000..b583d675bf
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_7_cf8da7720ddc20b05955ee671ca4acd5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7AuSfii_tCkLyspL6Mr0ATlO6OxLNYOo"
+ nickname="Georg"
+ subject="installed successfully on galaxy nexus stock 4.2.2 rom"
+ date="2013-02-22T08:28:36Z"
+ content="""
+could run git annex and get the help screen. didn't do much else after that since I am at work currently.
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_8_f4709bdbc739182819b648fd6aa00531._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_8_f4709bdbc739182819b648fd6aa00531._comment
new file mode 100644
index 0000000000..367e791ff2
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_8_f4709bdbc739182819b648fd6aa00531._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="nexus 4, android 4.2.2"
+ date="2013-02-22T11:59:13Z"
+ content="""
+Installs but can not detect email even when set:
+
+    --global user.name \"Your Name\"                               <
+    --global user.email \"you@example.com\"                         <
+    u0_a135@android:/sdcard/git-annex.home $ git annex init
+    init
+      Detected a crippled filesystem.
+
+    *** Please tell me who you are.
+    
+    Run
+    
+      git config --global user.email \"you@example.com\"
+      git config --global user.name \"Your Name\"
+    
+    to set your account's default identity.
+    Omit --global to set the identity only in this repository.
+    
+    fatal: unable to auto-detect email address (got 'u0_a135@localhost.(none)')
+    
+    git-annex: user error (git [\"--git-  dir=/storage/emulated/legacy/git-annex.home/.git\",\"--work-tree=/storage/emulated/legacy/git-annex.home\",\"commit-tree\",\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\"] exited 128)
+failed
+    git-annex: init: 1 failed
+    1|u0_a135@android:/sdcard/git-annex.home $
+
+
+Sorry for bad copy paste... On tour bus in Stockholm and only have phone, no laptop...
+
+RichiH
+"""]]
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_9_e66af12c7eca0d457b8406e9fb4b69be._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_9_e66af12c7eca0d457b8406e9fb4b69be._comment
new file mode 100644
index 0000000000..46a9eff3de
--- /dev/null
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_9_e66af12c7eca0d457b8406e9fb4b69be._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://ertai.myopenid.com/"
+ nickname="npouillard"
+ subject="comment 9"
+ date="2013-02-22T15:19:25Z"
+ content="""
+Same trouble with --global config, however local config works.
+"""]]
diff --git a/doc/design/assistant/blog/day_196__android_bugfixes.mdwn b/doc/design/assistant/blog/day_196__android_bugfixes.mdwn
new file mode 100644
index 0000000000..a78853f93e
--- /dev/null
+++ b/doc/design/assistant/blog/day_196__android_bugfixes.mdwn
@@ -0,0 +1,26 @@
+So it seems the Android app works pretty well on a variety of systems.
+Only report of 100% failure so far is on Cyanogenmod 7.2 (Android 2.3.7).
+
+Worked today on some of the obvious bugs.
+
+* Turns out that getEnvironment is broken on Android, returning no
+  environment, which explains the weird git behavior where it complains
+  that it cannot determine the username and email (because it sees no USER
+  or HOST), and suggests setting them in the global git config (which it
+  ignores, because it sees no HOME). Put in a work around for this
+  that makes `git annex init` more pleasant, and opened a bug report on
+  ghc-android.
+* Made the Android app detect when it's been upgraded, and re-link all
+  the commands, etc.
+* Fixed the bug that made `git-annex assistant` on Android re-add all
+  existing files on startup.
+* Enabled a few useful things in busybox. Including vi.
+* Replaced the service notification icon with one with the git-annex logo.
+* Made the terminal not close immediately when the shell exits, which
+  should aid in debugging of certain types of crashes.
+
+I want to set up an autobuilder for Android, but to do that I need to
+install all the haskell libraries on my server. Since getting them built
+for Android involved several days of hacking the first time, this will
+be an opportunity to make sure I can replicate that. Hopefully in less time.
+;)
diff --git a/doc/design/assistant/blog/day_197__template_haskell.mdwn b/doc/design/assistant/blog/day_197__template_haskell.mdwn
new file mode 100644
index 0000000000..cb42b08038
--- /dev/null
+++ b/doc/design/assistant/blog/day_197__template_haskell.mdwn
@@ -0,0 +1,36 @@
+Set up an autobuilder for the linux standalone binaries.
+Did not get an Android autobuilder set up yet, but I did update
+the Android app with recent improvements, so [[upgrade|install/Android]].
+
+----
+
+Investigated further down paths to getting the webapp built for Android.
+
+* Since recent ghc versions support ghci and thus template haskell on arm,
+  at least some of the time, I wonder what's keeping the ghc-android build
+  from doing so? It might be due to it being a cross compiler. I tried
+  recompiling it with the stage 2, native compiler enabled. While I was
+  able to use that ghc binary on Android, it refused to run --interactive,
+  claiming it was not built with that enabled. Don't really understand
+  the ghc build system, so might have missed something.
+
+  Maybe I need to recompile ghc using the native ghc running on Android.
+  But that would involve porting gcc and a lot of libraries and toolchain
+  stuff to Android.
+
+* [yesod-pure](http://hackage.haskell.org/package/yesod-pure) is an option,
+  and I would not mind making all the code changes to use it, getting
+  rid of template haskell entirely. (Probably around 1 thousand lines of
+  code would need to be written, but most of it would be trivial
+  conversion of hamlet templates.)
+  
+  Question is, will yesod install at all without template haskell? Not
+  easily. `vector`, `monad-logger`, `aeson`, `shakespeare`,
+  `shakespeare-css`, `shakespeare-js`, `shakespeare-i18n`, `hamlet`
+  all use TH at build time. Hacked them all to just remove the TH parts.
+
+  The hack job on `yesod-core` was especially rough, involving things like
+  404 handlers. Did get it to build tho!
+
+  Still a dozen packages before I can build yesod, and then will try 
+  building [this yesod-pure demo](https://gist.github.com/snoyberg/3870834/raw/212f0164de36524291df3ab35788e2b72d8d1e75/fib.hs).
diff --git a/doc/design/assistant/blog/day_197__template_haskell/comment_1_82d9f9508929d84abf7b718c59436ae8._comment b/doc/design/assistant/blog/day_197__template_haskell/comment_1_82d9f9508929d84abf7b718c59436ae8._comment
new file mode 100644
index 0000000000..95fcde0d6a
--- /dev/null
+++ b/doc/design/assistant/blog/day_197__template_haskell/comment_1_82d9f9508929d84abf7b718c59436ae8._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://meep.pl/"
+ ip="193.23.174.18"
+ subject="Android 2.3"
+ date="2013-02-24T15:16:51Z"
+ content="""
+The updated version lets me see the failure(s), and it looks like this:
+
+    cd: can't cd to /data/data/ga.androidterm/lib/lib.runshell.so/../..
+    [: not found
+    [: not found
+    could not open //installed-version, No such file or directory
+    /data/data/ga.androidterm/lib/lib.runshell.so: cannot create
+    /sdcard/git-annex.home/git-annex-install.log: directory nonexistent
+
+    [Terminal session finished]
+
+"""]]
diff --git a/doc/design/assistant/blog/day_198__bugfixes.mdwn b/doc/design/assistant/blog/day_198__bugfixes.mdwn
new file mode 100644
index 0000000000..ec8535ad1c
--- /dev/null
+++ b/doc/design/assistant/blog/day_198__bugfixes.mdwn
@@ -0,0 +1,11 @@
+Wrote a C shim to get the Android app started. This avoids it relying on
+the Android /system/bin/sh to run its shell script, or indeed relying on
+any unix utilities from Android at all, which may help on some
+systems. Pushed a new build of the Android app.
+
+Tracked down a failure a lot of people are reporting with WebDAV support
+to a backported security fix in the TLS library, and filed an upstream bug
+about it.
+
+Various other misc fixing and stuff.
+My queue of bug reports and stuff only has 47 items in it now. Urk..
diff --git a/doc/design/assistant/blog/day_198__bugfixes/comment_1_5a15b5bad0f9ba2423d2aebe440ac0ea._comment b/doc/design/assistant/blog/day_198__bugfixes/comment_1_5a15b5bad0f9ba2423d2aebe440ac0ea._comment
new file mode 100644
index 0000000000..279a53f044
--- /dev/null
+++ b/doc/design/assistant/blog/day_198__bugfixes/comment_1_5a15b5bad0f9ba2423d2aebe440ac0ea._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://meep.pl/"
+ ip="193.23.174.18"
+ subject="Android 2.3 again"
+ date="2013-02-24T23:07:28Z"
+ content="""
+I got _a lot_ further with the latest upgrade.
+
+* installation worked
+* `git init` worked
+* first `git annex init` asked to set user.{email,name}
+* `git config --global ...` worked
+* second `git annex init` segfaulted, but not immediately:
+
+      init
+        Detected a crippled filesystem.
+      error: git-annex died of signal 11
+
+"""]]
diff --git a/doc/design/assistant/blog/day_198__bugfixes/comment_2_36d94b838e5e65c85e7afaabe8a578f1._comment b/doc/design/assistant/blog/day_198__bugfixes/comment_2_36d94b838e5e65c85e7afaabe8a578f1._comment
new file mode 100644
index 0000000000..0a34148647
--- /dev/null
+++ b/doc/design/assistant/blog/day_198__bugfixes/comment_2_36d94b838e5e65c85e7afaabe8a578f1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 2"
+ date="2013-02-25T11:22:53Z"
+ content="""
+Is the autiobuilder for linux available already?
+I can't find it, and I'm eager to try the thumbdrive related fixes (where I can specify a simple folder).
+
+Best, 
+ Laszlo
+"""]]
diff --git a/doc/design/assistant/blog/day_198__bugfixes/comment_3_ae9b74341a3bc6e1e84d2c0ca4c5f612._comment b/doc/design/assistant/blog/day_198__bugfixes/comment_3_ae9b74341a3bc6e1e84d2c0ca4c5f612._comment
new file mode 100644
index 0000000000..39e017cebb
--- /dev/null
+++ b/doc/design/assistant/blog/day_198__bugfixes/comment_3_ae9b74341a3bc6e1e84d2c0ca4c5f612._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.210"
+ subject="comment 3"
+ date="2013-02-25T15:53:30Z"
+ content="""
+@meep try running it with --debug for some more hint of where it's crashing
+
+@Laszlo see [[install/Linux_standalone]]
+"""]]
diff --git a/doc/design/assistant/blog/day_198__bugfixes/comment_4_5a4827227c03bcff3b1e4c44b531f816._comment b/doc/design/assistant/blog/day_198__bugfixes/comment_4_5a4827227c03bcff3b1e4c44b531f816._comment
new file mode 100644
index 0000000000..fafb8fd274
--- /dev/null
+++ b/doc/design/assistant/blog/day_198__bugfixes/comment_4_5a4827227c03bcff3b1e4c44b531f816._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 4"
+ date="2013-02-25T18:28:09Z"
+ content="""
+joeyh: Is the 20130216 is the newest? Because you just wrote about two days ago of direct mode fixes, I'm interested in.
+I tried 20130216 already.
+
+Laszlo
+
+"""]]
diff --git a/doc/design/assistant/blog/day_198__bugfixes/comment_5_9c5f4c85217e898be4c57c615e53c36f._comment b/doc/design/assistant/blog/day_198__bugfixes/comment_5_9c5f4c85217e898be4c57c615e53c36f._comment
new file mode 100644
index 0000000000..221e28d25a
--- /dev/null
+++ b/doc/design/assistant/blog/day_198__bugfixes/comment_5_9c5f4c85217e898be4c57c615e53c36f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.210"
+ subject="comment 5"
+ date="2013-02-26T16:33:11Z"
+ content="""
+I have not made a release with those fixes yet, but they are available in the autobuilds.
+"""]]
diff --git a/doc/design/assistant/blog/day_198__bugfixes/comment_6_bccf1abfb7f56d97673158f3ccfce511._comment b/doc/design/assistant/blog/day_198__bugfixes/comment_6_bccf1abfb7f56d97673158f3ccfce511._comment
new file mode 100644
index 0000000000..22012c0cdf
--- /dev/null
+++ b/doc/design/assistant/blog/day_198__bugfixes/comment_6_bccf1abfb7f56d97673158f3ccfce511._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://meep.pl/"
+ ip="193.23.174.18"
+ subject="git annex init --debug"
+ date="2013-02-27T06:39:19Z"
+ content="""
+The last thing before the signal 11 error that I can see with `--debug` is `read: uname [\"-n\"]` after reports of running 5 git commands.
+
+"""]]
diff --git a/doc/design/assistant/blog/day_198__bugfixes/comment_7_6f1b51b002cc5d2b505d80e3e04bf6f3._comment b/doc/design/assistant/blog/day_198__bugfixes/comment_7_6f1b51b002cc5d2b505d80e3e04bf6f3._comment
new file mode 100644
index 0000000000..8adcd394d2
--- /dev/null
+++ b/doc/design/assistant/blog/day_198__bugfixes/comment_7_6f1b51b002cc5d2b505d80e3e04bf6f3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://meep.pl/"
+ ip="193.23.174.18"
+ subject="comment 7"
+ date="2013-02-27T06:53:15Z"
+ content="""
+But the error does not happen immediately after that. All the 6 log messages have the same timestamp and `git annex init --debug; date` prints a timestamp that is 3-4 seconds later.
+"""]]
diff --git a/doc/design/assistant/blog/day_198__bugfixes/comment_8_8a3542437663028b17442818eba3f7c5._comment b/doc/design/assistant/blog/day_198__bugfixes/comment_8_8a3542437663028b17442818eba3f7c5._comment
new file mode 100644
index 0000000000..f9a50b94e7
--- /dev/null
+++ b/doc/design/assistant/blog/day_198__bugfixes/comment_8_8a3542437663028b17442818eba3f7c5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://meep.pl/"
+ ip="193.23.174.18"
+ subject="comment 8"
+ date="2013-02-27T06:55:24Z"
+ content="""
+Also, this was after a reinstall. The next time I start the app the terminal opens but prompt does not appear (at least not for a very long time). Then after uninstall and reinstall I get to the prompt again.
+
+"""]]
diff --git a/doc/design/assistant/blog/day_199__wrapping_up_Android_for_now.mdwn b/doc/design/assistant/blog/day_199__wrapping_up_Android_for_now.mdwn
new file mode 100644
index 0000000000..7d37e8f948
--- /dev/null
+++ b/doc/design/assistant/blog/day_199__wrapping_up_Android_for_now.mdwn
@@ -0,0 +1,26 @@
+An Android autobuilder is now set up to run nightly. At this point
+I don't see an immediate way to getting the webapp working on Android, so
+it's best to wait a month or two and see how things develop in Haskell land.
+So I'm moving on to other things.
+
+Today:
+
+* Fixed a nasty regression that made `*` not match files in subdirectories.
+  That broke the preferred content handling, among other things. I will
+  be pushing out a new release soon.
+* As a last Android thing (for now), made the Android app automatically
+  run `git annex assistant --autostart` , so you can manually set up
+  an assistant-driven repository on Android, listing the repository in
+  `.config/git-annex/autostart`
+* Made the webapp display any error message from `git init` if it fails.
+  This was the one remaining gap in the logging.
+  One reason it could fail is if the system has a newer git in use, and
+  `~/.gitconfig` is configured with some options the older git bundled
+  with git-annex doesn't like.
+* Bumped the major version to 4, and annex.version will be set to 4 in
+  new direct mode repositories. (But version 3 is otherwise still used, to
+  avoid any upgrade pain.) This is to prevent old versions that don't
+  understand direct mode from getting confused. I hope direct mode is
+  finally complete, too, after the work to make it work on crippled
+  filesystems this month.
+* Misc other bugfixes etc. Backlog down to 43.
diff --git a/doc/design/assistant/blog/day_199__wrapping_up_Android_for_now/comment_1_ec57358afc7e78d2860aa4237793832d._comment b/doc/design/assistant/blog/day_199__wrapping_up_Android_for_now/comment_1_ec57358afc7e78d2860aa4237793832d._comment
new file mode 100644
index 0000000000..1d79237395
--- /dev/null
+++ b/doc/design/assistant/blog/day_199__wrapping_up_Android_for_now/comment_1_ec57358afc7e78d2860aa4237793832d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="Automagic photo backups"
+ date="2013-02-26T21:56:44Z"
+ content="""
+Did you investigate how hard it would be to only commit & upload once the phone is being charged _and_ on WiFi? That does not rely on the webapp, but it would make using git-annex on Android a lot more useful until you restart your work on this.
+
+
+RichiH
+"""]]
diff --git a/doc/design/assistant/blog/day_19__random_improvements.mdwn b/doc/design/assistant/blog/day_19__random_improvements.mdwn
new file mode 100644
index 0000000000..acb30bf934
--- /dev/null
+++ b/doc/design/assistant/blog/day_19__random_improvements.mdwn
@@ -0,0 +1,50 @@
+Random improvements day..
+
+Got the merge conflict resolution code working in `git annex assistant`.
+
+Did some more fixes to the pushing and pulling code, covering some cases
+I missed earlier. 
+
+Git syncing seems to work well for me now; I've seen it recover
+from a variety of error conditions, including merge conflicts and repos
+that were temporarily unavailable.
+
+----
+
+There is definitely a MVar deadlock if the merger thread's inotify event
+handler tries to run code in the Annex monad. Luckily, it doesn't
+currently seem to need to do that, so I have put off debugging what's going
+on there.
+
+Reworked how the inotify thread runs, to avoid the two inotify threads
+in the assistant now from both needing to wait for program termination,
+in a possibly conflicting manner.
+
+Hmm, that *seems* to have fixed the MVar deadlock problem.
+
+----
+
+Been thinking about how to fix [[bugs/watcher_commits_unlocked_files]].
+Posted some thoughts there.
+
+It's about time to move on to data [[syncing]]. While eventually that will
+need to build a map of the repo network to efficiently sync data over the
+fastest paths, I'm thinking that I'll first write a dumb version. So, two
+more threads:
+
+1. Uploads new data to every configured remote. Triggered by the watcher
+   thread when it adds content. Easy; just use a `TSet` of Keys to send.
+
+2. Downloads new data from the cheapest remote that has it. Could be 
+   triggered by the
+   merger thread, after it merges in a git sync. Rather hard; how does it
+   work out what new keys are in the tree without scanning it all? Scan
+   through the git history to find newly created files? Maybe the watcher
+   triggers this thread instead, when it sees a new symlink, without data,
+   appear.
+
+Both threads will need to be able to be stopped, and restarted, as needed
+to control the data transfer. And a lot of other control smarts will
+eventually be needed, but my first pass will be to do a straightforward
+implementation. Once it's done, the git annex assistant will be basically
+usable.
diff --git a/doc/design/assistant/blog/day_1__inotify.mdwn b/doc/design/assistant/blog/day_1__inotify.mdwn
new file mode 100644
index 0000000000..ca27a45861
--- /dev/null
+++ b/doc/design/assistant/blog/day_1__inotify.mdwn
@@ -0,0 +1,57 @@
+First day of [Kickstarter funded work](http://www.kickstarter.com/projects/joeyh/git-annex-assistant-like-dropbox-but-with-your-own/)! 
+
+Worked on [[inotify]] today. The `watch` branch in git now does a pretty
+good job of following changes made to the directory, annexing files
+as they're added and staging other changes into git. Here's a quick
+transcript of it in action:
+
+	joey@gnu:~/tmp>mkdir demo
+	joey@gnu:~/tmp>cd demo
+	joey@gnu:~/tmp/demo>git init
+	Initialized empty Git repository in /home/joey/tmp/demo/.git/
+	joey@gnu:~/tmp/demo>git annex init demo
+	init demo ok
+	(Recording state in git...)
+	joey@gnu:~/tmp/demo>git annex watch &
+	[1] 3284
+	watch . (scanning...) (started)
+	joey@gnu:~/tmp/demo>dd if=/dev/urandom of=bigfile bs=1M count=2
+	add ./bigfile 2+0 records in
+	2+0 records out
+	2097152 bytes (2.1 MB) copied, 0.835976 s, 2.5 MB/s
+	(checksum...) ok
+	(Recording state in git...)
+	joey@gnu:~/tmp/demo>ls -la bigfile
+	lrwxrwxrwx 1 joey joey 188 Jun  4 15:36 bigfile -> .git/annex/objects/Wx/KQ/SHA256-s2097152--e5ced5836a3f9be782e6da14446794a1d22d9694f5c85f3ad7220b035a4b82ee/SHA256-s2097152--e5ced5836a3f9be782e6da14446794a1d22d9694f5c85f3ad7220b035a4b82ee
+	joey@gnu:~/tmp/demo>git status -s
+	A  bigfile
+	joey@gnu:~/tmp/demo>mkdir foo
+	joey@gnu:~/tmp/demo>mv bigfile foo
+	"del ./bigfile"
+	joey@gnu:~/tmp/demo>git status -s
+	AD bigfile
+	A  foo/bigfile
+
+Due to Linux's inotify interface, this is surely some of the most subtle,
+race-heavy code that I'll need to deal with while developing the git annex
+assistant. But I can't start wading, need to jump off the deep end to make
+progress!
+
+The hardest problem today involved the case where a directory is moved
+outside of the tree that's being watched. Inotify will still send events
+for such directories, but it doesn't make sense to continue to handle them.
+
+Ideally I'd stop inotify watching such directories, but a lot of state
+would need to be maintained to know which inotify handle to stop watching.
+(Seems like Haskell's inotify API makes this harder than it needs to be...)
+
+Instead, I put in a hack that will make it detect inotify events from
+directories moved away, and ignore them. This is probably acceptable,
+since this is an unusual edge case.
+
+----
+
+The notable omission in the inotify code, which I'll work on next, is
+staging deleting of files. This is tricky because adding a file to the
+annex happens to cause a deletion event. I need to make sure there are no
+races where that deletion event causes data loss.
diff --git a/doc/design/assistant/blog/day_200__release_day.mdwn b/doc/design/assistant/blog/day_200__release_day.mdwn
new file mode 100644
index 0000000000..99aebcf700
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day.mdwn
@@ -0,0 +1,19 @@
+As well as making a new release, I rewrote most of the Makefile, so that it
+uses cabal to build git-annex. This avoids some duplication, and most
+importantly, means that the Makefile can auto-detect available libraries
+rather than needing to juggle build flags manually. Which was becoming a
+real pain.
+
+I had avoided doing this before because cabal is slow for me on my little
+netbook. Adding ten seconds to every rebuild really does matter! But I came
+up with a hack to let me do incremental development builds without the
+cabal overhead, by intercepting and reusing the ghc command that cabal
+runs.
+
+There was also cabal "fun" to get the Android build working with cabal.
+And more fun involving building the test suite. For various reasons, I
+decided to move the test suite into the git-annex binary. So you can run
+`git annex test` at any time, any place, and it self-tests. That's a neat
+trick I've seen one or two other programs do, and probably the nicest thing
+to come out of what was otherwise a pretty yak shaving change that involved
+babysitting builds all day.
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_10_40cfe9bfd9e611fd734dbb5aad348aa3._comment b/doc/design/assistant/blog/day_200__release_day/comment_10_40cfe9bfd9e611fd734dbb5aad348aa3._comment
new file mode 100644
index 0000000000..dfd4f32fed
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_10_40cfe9bfd9e611fd734dbb5aad348aa3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 10"
+ date="2013-03-01T04:23:48Z"
+ content="""
+@Brian, I follow your logic, it does seem that start.c is not finding itself. But, you checked the pid of the terminal, while start.c is the program it (usually) starts.
+
+Anyway, I have tried making start.c fall back to a hard coded path if it cannot find busybox. It'll also say what path it detected, which may help debug the underlying problem. You can pick up an app with this change from the autobuilder.
+"""]]
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_11_b26890fdae575d42170988073fb2e45d._comment b/doc/design/assistant/blog/day_200__release_day/comment_11_b26890fdae575d42170988073fb2e45d._comment
new file mode 100644
index 0000000000..164dce53fc
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_11_b26890fdae575d42170988073fb2e45d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmmLfBDEDFfEOba8Ra46nsnTmoNHFsLObo"
+ nickname="Brian"
+ subject="comment 11"
+ date="2013-03-01T12:02:09Z"
+ content="""
+Good point--it didn't occur to me start.c runs as a child process. Makes sense. How do I download the output of the autobuild? Size-wise and behavior-wise, http://downloads.kitenet.net/git-annex/android/current/git-annex.apk looks like the same file I already had.
+"""]]
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_13_710a30c5d31bf549833ecfe9a0997c94._comment b/doc/design/assistant/blog/day_200__release_day/comment_13_710a30c5d31bf549833ecfe9a0997c94._comment
new file mode 100644
index 0000000000..50b99a9658
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_13_710a30c5d31bf549833ecfe9a0997c94._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 13"
+ date="2013-03-01T16:36:58Z"
+ content="""
+@Brian the autobuild is linked to on [[install/Android]]
+"""]]
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_13_b6f62ab7e810ba6d3a43f0ead370c79a._comment b/doc/design/assistant/blog/day_200__release_day/comment_13_b6f62ab7e810ba6d3a43f0ead370c79a._comment
new file mode 100644
index 0000000000..efd38879fe
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_13_b6f62ab7e810ba6d3a43f0ead370c79a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmmLfBDEDFfEOba8Ra46nsnTmoNHFsLObo"
+ nickname="Brian"
+ subject="comment 13"
+ date="2013-03-01T23:52:53Z"
+ content="""
+I got the latest autobuild version installed and the fallback works for me--thanks. FYI, the fallback error message says: \"cannot find expected files in /data/app-lib\"
+"""]]
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_1_a68e1ed7829b49086c567d97ddc09912._comment b/doc/design/assistant/blog/day_200__release_day/comment_1_a68e1ed7829b49086c567d97ddc09912._comment
new file mode 100644
index 0000000000..51247f6b70
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_1_a68e1ed7829b49086c567d97ddc09912._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnxp2XU8gIribhhGhGuYtU6eMMwHv5gUGI"
+ nickname="Amitai"
+ subject="comment 1"
+ date="2013-02-28T02:53:53Z"
+ content="""
+That _is_ a neat trick, especially since you're deploying to odd platforms where you'll probably be even gladder of the in-app tests far in the future than you are now!
+"""]]
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_2_39d3ad0a029fe56e96f97d28d17fbbd2._comment b/doc/design/assistant/blog/day_200__release_day/comment_2_39d3ad0a029fe56e96f97d28d17fbbd2._comment
new file mode 100644
index 0000000000..f6aeb306de
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_2_39d3ad0a029fe56e96f97d28d17fbbd2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://meep.pl/"
+ ip="193.23.174.18"
+ subject="comment 2"
+ date="2013-02-28T06:13:21Z"
+ content="""
+Maybe it's the build changes? Android apk disappeared from <http://downloads.kitenet.net/git-annex/android/current/>
+"""]]
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_3_5b752d6a8d74e61190f09384b6108206._comment b/doc/design/assistant/blog/day_200__release_day/comment_3_5b752d6a8d74e61190f09384b6108206._comment
new file mode 100644
index 0000000000..066abd19ab
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_3_5b752d6a8d74e61190f09384b6108206._comment
@@ -0,0 +1,31 @@
+[[!comment format=c
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 3"
+ date="2013-02-28T08:40:46Z"
+ content="""
+Two suggestion:
+1. Possibility to restrict CPU usage (a 10-20% would be nice, or a slider)
+2. Pager on Dashboard
+
+I have a directory, it is 741MB, and contains 23381 files. 
+This directory is pretty much everything needed for my daily job.
+
+I added a copy of this directory to annex, then I created a backup dir of annex, 
+and my laptop is using almost 100%CPU al the time, it is running since 1 hour already, and 
+only 140MB was copied over to the backup directory.
+
+Don't get me wrong, this application just blows my mind, and it seems to *work* for the first time for real.
+
+The suggestion is simply a slider in resource manager (preferably inside dashboard):
+Restrict CPU usage [0---X---100]34%
+Restrict upload bandwith [0-X----800]9kB/s
+Restrict download bandwith [0-X----800]80kB/s
+
+Also the pager is musthave in dashboard, because it renders firefox unusable with that many entries (21000).
+
+Nice work, thank you for the release!
+
+Laszlo
+
+"""]]
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_4_881274ae0d6230bb4cafa4151ad72b49._comment b/doc/design/assistant/blog/day_200__release_day/comment_4_881274ae0d6230bb4cafa4151ad72b49._comment
new file mode 100644
index 0000000000..75d54e04e2
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_4_881274ae0d6230bb4cafa4151ad72b49._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="lot of stuck git processes"
+ date="2013-02-28T09:01:25Z"
+ content="""
+Oh, and here is how it looks 
+ps -e |grep git 
+command after git-annex has been stopped (from the gui):
+(54 process, from which 50 process <defunct>)
+http://pastebin.com/5u74qTNU
+"""]]
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_5_e220059be77cf0ef396f37a4f9ccf9b5._comment b/doc/design/assistant/blog/day_200__release_day/comment_5_e220059be77cf0ef396f37a4f9ccf9b5._comment
new file mode 100644
index 0000000000..bd518cc0a7
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_5_e220059be77cf0ef396f37a4f9ccf9b5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 5"
+ date="2013-02-28T19:42:09Z"
+ content="""
+@meep That's not the autobuild. I put the wrong file there! Fixed.
+"""]]
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_6_ec2152151188dd252cdb61c68cfc12e4._comment b/doc/design/assistant/blog/day_200__release_day/comment_6_ec2152151188dd252cdb61c68cfc12e4._comment
new file mode 100644
index 0000000000..43e676f609
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_6_ec2152151188dd252cdb61c68cfc12e4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 6"
+ date="2013-02-28T19:52:59Z"
+ content="""
+Lazlo, could you please file a proper [[bug|bugs]] report and include details like what version of git-annex you're using there when you get the zombies.
+
+I have modified the webapp to only ever show 10 queued transfers on the dashboard.
+"""]]
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_7_42572411617c287368482bb9dcf94324._comment b/doc/design/assistant/blog/day_200__release_day/comment_7_42572411617c287368482bb9dcf94324._comment
new file mode 100644
index 0000000000..409ade91db
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_7_42572411617c287368482bb9dcf94324._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmmLfBDEDFfEOba8Ra46nsnTmoNHFsLObo"
+ nickname="Brian"
+ subject="link busybox: No such file or directory"
+ date="2013-03-01T02:32:32Z"
+ content="""
+When I run the 28-Feb-2013 android version of git annex, I'm getting the error:
+
+    link busybox: No such file or directory
+
+Maybe this code is not finding the busybox.so file:
+
+    link(\"lib/lib.busybox.so\", \"busybox\")
+
+Any ideas how I can troubleshoot?
+
+I'm running Android 4.2.2.
+"""]]
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_8_6b69aa81a9ba4e07e547ed1869946d51._comment b/doc/design/assistant/blog/day_200__release_day/comment_8_6b69aa81a9ba4e07e547ed1869946d51._comment
new file mode 100644
index 0000000000..c375f3b844
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_8_6b69aa81a9ba4e07e547ed1869946d51._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 8"
+ date="2013-03-01T03:10:35Z"
+ content="""
+@Brian what you can do is go to the terminal's preferences menu and change the shell it runs to `/system/bin/sh` . This should let you open a new tab with a shell prompt. Then you can try to cd to `/data/data/ga.androidterm`, and see if both `lib/lib.start.so` and `lib/lib.busybox.so` exist.
+
+You could then try to do the same thing it does to set up the system:
+
+<pre>
+ln lib/lib.busybox.so busybox
+./busybox sh lib/lib.runshell.so
+</pre>
+"""]]
diff --git a/doc/design/assistant/blog/day_200__release_day/comment_9_b070a2e4151d9fbf43d7906efa78515f._comment b/doc/design/assistant/blog/day_200__release_day/comment_9_b070a2e4151d9fbf43d7906efa78515f._comment
new file mode 100644
index 0000000000..4acf003c86
--- /dev/null
+++ b/doc/design/assistant/blog/day_200__release_day/comment_9_b070a2e4151d9fbf43d7906efa78515f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmmLfBDEDFfEOba8Ra46nsnTmoNHFsLObo"
+ nickname="Brian"
+ subject="comment 9"
+ date="2013-03-01T03:55:46Z"
+ content="""
+@joey Both .so files were present and I was able to run the ln and busybox commands. And after that 'git annex' displayed the help screen. Thanks!
+
+Then I ran 'ps | grep ga.androidterm' to find the pid and then 'ls -l /proc/&lt;pid&gt;/exe' and it showed the symlink points at '/system/bin/app_process'.
+
+So the 'int n=readlink(\"/proc/self/exe\", buf, 1023);' in start.c isn't very useful in this case.
+"""]]
diff --git a/doc/design/assistant/blog/day_201__real_Android_wrapup.mdwn b/doc/design/assistant/blog/day_201__real_Android_wrapup.mdwn
new file mode 100644
index 0000000000..8ff743f68c
--- /dev/null
+++ b/doc/design/assistant/blog/day_201__real_Android_wrapup.mdwn
@@ -0,0 +1,38 @@
+[[!meta title="day 201  real Android wrapup"]]
+
+I got yesod-pure fully working on Android...
+
+[[!img fib.png size=400x]]
+
+As expected, this involved manually splicing some template haskell. I'm now
+confident I can port the git-annex webapp to Android this way, and that it
+will take about a week. Probably will start on that in a month or so. If
+anyone has some spare Android hardware they'd like to loan me, possibly
+sooner. (Returning loaner Asus Transformer tomorrow; thanks Mark.) Although
+I'm inclined to let the situation develop; we may just get a ghc-android
+that supports TH..
+
+Also:
+
+* Fixed several bugs in the Android installation process.
+* Committed patches for all Haskell libraries I've modified to
+  the git-annex git repo.
+* Ran the test suite on Android. It found a problem; seems `git clone`
+  of a local repository is broken in the Android environment.
+
+Non-Android:
+
+* Made the assistant check every hour if logs have grown larger than a
+  megabyte, and rotate them to avoid using too much disk space.
+* Avoided noise in log about typechanged objects when running
+  git commit in direct mode repositories. Seems `git commit`
+  has no way to shut that up, so I had to /dev/null it.
+* When run with `--debug`, the assistant now logs more information
+  about why it transfers or drops objects.
+* Found and fixed a case where moving a file to an archive directory would
+  not cause its content to be dropped.
+* Working on a bug with the assistant where moving a file out of an 
+  archive directory in direct mode sometimes ends up with a symlink
+  rather than a proper direct mode file. Have not gotten to the bottom
+  of it entirely, but it's a race, and I think the race is between
+  the direct mode mapping being updated, and the file being transferred.
diff --git a/doc/design/assistant/blog/day_201__real_Android_wrapup/comment_1_88b9950c51324f0bb89c5646b3170952._comment b/doc/design/assistant/blog/day_201__real_Android_wrapup/comment_1_88b9950c51324f0bb89c5646b3170952._comment
new file mode 100644
index 0000000000..b9edfc4b61
--- /dev/null
+++ b/doc/design/assistant/blog/day_201__real_Android_wrapup/comment_1_88b9950c51324f0bb89c5646b3170952._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://ao2.it/"
+ nickname="ao2"
+ subject="Using the Emulator?"
+ date="2013-03-04T13:58:18Z"
+ content="""
+Hi Joey,
+
+while you wait for some actual Android device have you tried the emulator?
+
+I've recently started playing with Android without any physical device, and the emulator is pretty responsive with hardware acceleration on (you need to run an x86 AVD).
+
+Here are some instructions: http://git.ao2.it/android/android-app-development-getting-started.git/blob/HEAD:/android-app-development-getting-started.sh
+
+Also, are you going to use a WebView connecting to the haskell web server for the WebApp?
+
+Ciao,
+   Antonio
+"""]]
diff --git a/doc/design/assistant/blog/day_201__real_Android_wrapup/fib.png b/doc/design/assistant/blog/day_201__real_Android_wrapup/fib.png
new file mode 100644
index 0000000000000000000000000000000000000000..f9b8c27fd4fa110c29a8d5d043b124e98fecadee
GIT binary patch
literal 69535
zcmd?Rdt6LwA2&RNoO8~pX4^&1ZA9p>HZ~*CkVAADgd{acI?gPF5RD2^G^ixWNF_Qg
zR6-av)pSs!<5W{kb3U!L=DDV__rCA<dEfVW-sjKP{uuYvwXSttzw3AW{=V0(t<nA@
zOxUu?ZWCe15CUNc_>Z8iCu{)U{?GpCCiy>`0X(gJOPDxP@3-Luy&=C7hE5!!H*tuz
zm_P*U96m5NVerq8p?brHkI)}EYV;T|AbSE~=ny@<p~Lis4<9xRjHZF#6NXJ3K55Rf
zbt5M4IH3Rg$tlavMLis8vOeS8RLAl@(-j9#ogX!Nn&I>rGw04To4;V8#mZHdtJkdE
z@Ylvoq|J6)cJA7}$7%0AXOBaNk9Z#SI_7uU|4cw&P;l6Vi<iPLU%46`bMw~i*gJRQ
z9wjCvKTdg)`t)UHR`#o$*Kcy)7ZsO$DE;{9a|Nfes+wC<Ti4Xw(%RO}@969ji6v5*
zT%lB{b^96u_WA42z{dV-UlYN;h7KF1H%wo*uOUMNz+b(I!-mgUHe%Ac9r_1OPX2xQ
zxsg-WM?K7VH_Bv%W8c(+r^-i9Gqq@%E7EPPe`o(|8$191X=i_L?4Nzr5yt8b0f(nI
zkpK~J)4JvQa2czSpW>4U3CC|*^GI;LbeLZxW_$97mhck7g3SC|R1PE7`m+zV*o1^B
z$4a8&q|{5$==$b;+_&6K5!lt!Mc?lD8)Rt-M~$|gsXQLaH0j=e2L~lk`;N~=TuMIQ
zHohisik&<El;79XJil!pEVoD8ei^*a%57DJFMil8q%?rj_VqDqTf9bH5Ni9E=^BD@
zLPC-;j(iaZnXTP>x#3)WrIzqYUy&<`#Ma*UP*_2&-5u%IQpv}Y!|L(&h0nlBBfGVP
zl3*(X)znY=!&UrZPl41X*onRCi<nDy-4dJzdARNK=G3y7Ap&m`ce^vFlZrX{rN?sv
zil7G%<X?SKeq*%}7KlUiwPVMsW%ZQfIo&r)Qy83UKjHU_xJ-(2bEz-vux$_Y(n<<V
zFw8+ehgY4|67I&<;Q5l6lEp_xJDp5d>`eE6mYp;2sn9pJ{QR}sWg>Svohs}K-BKQw
zkklHWxM8d%aAoaj7KeO|3f8c9%G5Hc(JAkqYAk9xpE$uOCc)aQS4)tsFmT09?zN{e
zYsXzS!KY0+q|g#BY~{1CYgL~XI~cm`Ci~djccG>4ZsI?Z1a}`}Rk`$L^4R5=`c>$k
zeKG;3&}zoo*3(eg%H4^2MpjZVC7n`T*ap4Sn+*h2?AkH|Ot>v?T91}6$`a8MSSu%D
zj9lHX+-<CXFVYguz@;pKYwvTS%PuY9lNpVt@X0RRmez2Led+2%p_Gl}<RHfrf_!Zd
z@)MaFFL2mKdkcGHY6%;s(viN)Q35StC&b}$DmiddWITR#xt7rMJ55XII;y~Fe*4yx
z!#<Ga417PHQvJ*zTyCxcOKd^a6+s@AcmmENbK^9Dcqvh~;|BaA2_`F_F2h6O4q%at
z)yha4q&aGJR}my$q0y7t1U+d_MA^NuU1ybyG6e>yrSS$&F!+68y_RrkEv%kj2DW-d
zOK5+@P<o_j36CNX<z^<Vj<Z3S*0Y}<qkPj6`ewkfvUdIAfhVtrSJIIt%5i3ml%aak
zMNgP$n*@I^?_oYP&f+OO_+XB!h|-RTdv&xYqe3lVNNjAZ%)j7%QS-o~n~J(1N*^m5
z?3uyDuPy}tn!>7-M0`5fX2&BIK8d6y#09TOg{`!Nw};!>FgL2_31!N_@`LDF0$8Ve
zVKvx*E!aRB*gzD}fK+Cuis`TupROjW=Yt(xh=(Qiq?P7;*pHHkXH|9Sm$*|>v1Ni@
z8sh90R*5s4DBf@p(GtF#2+n!AO$hvcD=kkAj^xHkrt)=SB-Fao_8HW1L`(3L8Mj9Q
zS>Sy9&rqiq!AuUi;EZ`n7YytTEMvV1Bs%d<%D!kI6<I3FwS=*k;Espp_@wJv!q=6y
z$Dl8GXHZZO-TVb{S~rCZ4EFlcDx>f=rh97)PD-YM_m8~-glVT#ZcpHIiyL|D=OdSZ
ziGd)VUI@qAOt4U}6=FMThEpKrZ=naybwG1A=|4a((wN}c$dJ%=6x8&i3`ijsZ540+
z)P(;|XIm!d^`-N#^q>y8&0Z4c^o9rJv&ct#eCMue@ARCRjZ0?t47J!aclcbdv7bFg
z%4RtFe%^u~3u&m|!=$o9EQ;FW7B!rvhRN0K5nk#0l#ljYlGlA*GRK(cv7|lQZ<bX@
zwUz90NqL62b!OzF(Y5=6oP17n-Cmoy?ip|BP%OnW;xGKKD6c-%%u#U9xFEEAX;g~m
zK1x=E`2sB=i;CO35SJ=?jzHbm{`%*^3vuabFX+@`b#gw1`n4gew_5{s;RS_)0>=Oq
zcbIe-uKxojQ`~<>?^hE)a?2TgGbZ=U3Uyy<eZ_;*tXXy5l_&UeWU|-HGyb<UPBnim
z^`9k-t}7-5$&tl-y+`Qhy#0%k)h#;7{CL}DEzx8h4|~YUxM82<^)5Tf^7pdOaL*Vm
z;dXWD=K{@vYn^I#Ezib)?*_H~K#@FwQjqjab+}&SW+7Cg^_8k3{qOjuv(G|^r3_y!
zfv@6LEDs&}m&So-sKU2Kb@olSn4~4t&6ET+`bMSrR!{hWU0V-+U|8egJ=y4I-pJFK
z$4AjN_|MoPbz|xy^2u?<xo)lUQ)ImnSNB}}Z0I^|(Y?^}49V}IB@3UW{vMIi-L)$9
z)2e8nQ+8e<lwG+glI(_tx=g&lxlYlk5+qXNY8shOw1k<fEK|Cm4=j~Q4Q|Fmad&Bu
zNxkG4w-$CSye;Tdj(nI=0PVmnj#J5%@O6rql+)gbYYF5p*F@2UTeO6GT7qa-l^Ia!
z`G`fXiXPliKeq3>R1Lh(72QYY8R8D`??sB(2?ch3HCY^6kE_&brliztN{AWw(b;S@
zB6vMR)9+&j%-z{|yIe~sBq=K{uj^!&!)iXNNa<!O3i)kVXtg|GY)`*K8So0}L=)hc
zW<OYObqzBle%BHbq#=fUh0Dt>Eg>!4E&jm$7itC<onJ#E3Gk`Ot&CpgM_6PLWTHtC
z6VYwPCBTL3!3*hI$2QIAh37E)v;><DF$VUC7aUdn8nqekM8ma&$)pTA97`1lxtm4=
z#0u50?AK7QAos5-SoTC*5HHpe1UuzWGisfWq=)>mA{2o+AR>_Z#|!K~%c;PFrju@U
z^J29GXNCuEUQ|}5=4R?y{-?jn%4Z!x5q0I@%>O@|F=4Y5`Y-ud4ag^9UpJ`>Dn-@R
zvC&X2JV#3?F8_6`1rZWF9ScS8%*gw<Lb?Baet$pFO<~HY0)Fe;ul<@a<+yDkaE7DH
z#Wskj&YD3*PcaUmxR5O1S3Mqarau5B9*_}P$~}xI5alBsgEjz7Cbp1X!i^ectW4rk
z`(uTCK-*{azdOtNAs86S5G8)5P&Irt-y*~e6TVTwl$9W~K?md*4J$x)ba)NeV3zeQ
zEn$t8(EQ|=t#mV)_)sn3%UJAsry5M-5ll}+y*GTKNSOG-m`}#M_z(>SEno4$Zg3=9
z-P`zJ`+r+DuxIP29#yvaVeFLJg_ZJi__%+~cT7u&wn0`UiEXq53jTp{Snbjvl}K|w
zQJzd$#oVAGp2VP7>()EA;o_C>M+F9JW|GYWDn?&&H#62DfyqxPbNe$ftOGXLWbhEZ
z?k*-H?eqIT<n|gQAVsDKI!DquziUJ=84OeTpWb~HnriTaF`uXs1}raRrkfweiFuqd
zH7EUT;zoC|3)%u)MUvQsCss2k)HXqMh&eDzin-v+=v{Y=!*m9wB`|{v+K8~G6@*6P
z9Uz()l9lD%aFJ34!e&UrkNH1?4L<JBMLnm`6fNO5jfSQZ)s~<o9gqn=r64vM4Mjd{
z33Ore=s+;%l>K1*Ze+gNyiI1Dz+*?RGZh!a>Rz>@J2bWt%?CF7XG#VQ+6lbjKty&O
z9N-v4>1J?vJX<Z{a@R)l!);2$91?6_I5=#UAx8$a?8#@zVG3Sg?4*HMARA$TVd@|i
z-Tdj$$0cC-kn<{oooe`^ix{cJV6`-14|D<dM9C^ya(5`RF+UbIFA*faP3uo3=GWMe
zJMpQWI$xqoxP@`n1HK}}+zfNUiS3#pE@j3kQiWVi&#(BE0Hp^}gmempO69Zl7Yw8%
zA?6}Fv2{4roCk7RL3x`7XJWw_1OHeL`mL8*f?<P}pr@7$Mf!c1mcS+lZ|nELdj_4G
zT^n<UT7%J$<yMDShXsmYb3v7FRgKes*jC2BJn@te$Wjp;gcmsGdA*t{x6DB4g^Bet
z<4ZC9T7K-q2PsBEkXP`;AA>O}HdBH^KhIJ6e}8mP$(i24L`f9T(C2nK6(nWSxGilM
zt#QB8J1G>EREx85D`3{p75<ueA4Yb=COE`zyz2f{L1CzdxEz%dfs1j!p4I`GvsCDt
z=4a(3(|jZiF2b-s)BfYEos-^5i8qoznRlvTO5oI2{i$5cK}}UUc=#L4ZsSgg?>}eK
z;yl=Ssg_V(5I^+QyDpgAmn1Gdc<ft=0>ujxQ4!DLI5-&KY4*^VKQNH5y46>XZloZc
zppr=vv!4K`P{_PHqh%huU)G)0nIQLtsVVK70zd6>Lk#Tw#gt3A$AHLkK;#1cLQpXf
zocGr7S}T008}L(5idY85#{M|V$`1Fy;mJ77>kpELiYU?&Y-Jw9&OlLG0#PE|xOA@^
z1&68beaqUoSGPf~L_jhPp__xBvbO*B=y6RUGgSeU(>kPLaMkW#1K@BK?7n~FMySl@
zGDcDYOLSiK&-o1;6HZ(t8*<a}XJlz4R<ITfVaIK8jTURPgrA|{?^#D+Z6FG=a9Zcl
z)HWJZmI4d%g3mTYbfOrDy=>!~@%jjm60w@O@weam#ex^|?i#(^=@9}}zH`T)Q~Q4H
zNV-e;k5AYZfx|=*?tXLM8A<>;Va}t3?P8KcgCEzJ$*8y+hQkvvh-rF$>uVA|OTB-}
zj*TP}E{kg8qb2Bbo(!KiVi`y#ShD0tiE2E1=<=|8!6%?;ir!UPf?Bfmw@8FfWT+IW
z9S;ni?prPY$cBV1F9ht)io$!?-CZV1;XRPsUGScLPT^8)!a-XlmCX1p6FJPcVBg`;
z4(>`RtNTZu%ZDExP+uf|oyBmkB{CfzBm0_Xp832i9=LkQTT3Va*+MwQzrM2Np@_xA
zTWudMCa1s@-Qh`ZI#m;2lDk7hdh!n<!{V=F-ZrjMy7l3lCd;C60nLiY{C%Q;VrNhY
zpeBh*Vo^?=TSE4eZBLKdP7)m#*_=P-1)uPJ_8^PlkW=_NTIN3GD*4Oo<MD+NXwUNk
zIHj`Nxd%JOg?kZ67w%w2V3I|pD!%MVgy(9h-UAujL88CuU8Bh<rerX}tPM}LMEFqU
zc}ijnw@>j7xQWoM->J|M%(59Sb(^(Qq#sUQ+_N}TuVu;3t$pN6hD{O5upaZ1`q%O|
zjK!yN(wmp0Hf%J#k#-2@QZfu9k;7w<OJcj!F3LpfH7(5Z#4)xjj=3+Zu%7(P%YAm=
zIpy7HNowkamG?I{9+NM6;+%ax$tl+Gwoj@>r<}HSIbz`kJGsSDVjFY2ikgr4R!NC`
z(etOUUSK2leRaZ`+&=2nCFm^pboDCZKbS>z#kSK53OC&{{>CYuwC{PW-|6&WpR4;C
z@;{e<PPW{nY8^AVlgCA2cEKNdl^P;;x0LmWA^K)_?ZKKgYoJ@U3<+ifvjkrWe{E;L
zbQ>35xt}ts%3&Wv64l#pfl={K^sgC^_YJ|8sUrP8MV_6$6Do#{y{t0@Y8oAAGe7ds
zld=<kep@#iUv5A-p!SRUs5kOM&}<r9Boe4ALf`}(=L3rbc5Yq%=Qy1)f{cCr1b@5$
z0Y<Ry_?d1i%?n^9o)9B@<Da9?NY3%XVmM3cjXrSH{$J-#sW@R^Vv^Gmd6(^QbO=wE
zgo0d&DXF>$uoq}2Mt~yMhV6(ZcR;_FR)Q>j>Cfn!gru0t3dc$MJ5db`3PrcS_TIZD
zN`QvqjTh*&Z%2o&f9qL!hR@}8vOBBq=1YLnVvGFLjE|?hZk{m%Z+Hp3g{N$`?13JW
zB4NML5=_Moc3aQ=fSIMJhP$q540+r!`uuVWEn&KMY~ifFsy1|5T{V)@xhUPObDCr3
z2lch!b@`dz(pLwgUDr+h{DXG)aLCceulM#aS)!D8tl3KQ4|M_OiDY1Cmn6mTf!BST
zlAF$|3u9Won(VooSiX`u(zV_M_TJa^cK+4Xm2P!ERIg@Uo2IB%oCs5+&KR^vc*fY7
z^4ta<|ICJVPE8Ch5sip3xP02kV}0&#>(acqXU3Oo2!fAZ+FWs1U)gjjhV<>PtK(1Q
zYbYg@@H)#PqYZX_FGM~$m-7#M?e7tdDB5y<RF=W0z>B?)Yn!~yCu|H^9vI=sSu)K+
zG*<qq+^c%#yVn)nLhAK=iNQScN`tq!Et3pa-=pSJTPtX@xI*}9)#G@BE4C9|8|(Hd
z!;73a+dKoB%Hlto<-b0>H{T}7rdXI3Kk~h=&z4@X$?W58&F9WHzK-&Vb;y;^FM6n2
z-+5$-RhwA=>ex7a+)|apm{BXSL(caLmUN>JW6qrZ1ZCw5O60`8E1@SZiLDMLa6W9W
z|FMp`m^JQfbxnMTS8tW8X&E)Geq-w9m!|AtG3h<`%%5yLTGnxL_&nkqmmLywYYlPr
zM1Xi07fdt`xNP1>chlb>Zqf{kh7-+WyfB8(oL7C}%-tSBN&3{yAC6VOdip53N*aLJ
zyXBSEEpPI+D#%+B5X(f3vQM>Tb(uPh_-a~|Lby8@X`0seafRL@KIVCOWz=zkV`#+W
z$&<K=TVpgEMfwc-=uUTs`(j#mpi>c{uygZocda)(qusf8l6q+3I?I%;9;wS$I!%lS
ztluf2j;)4{s>oMXc3fEzcpjZ*Wnnb=kWY#=v*YrCmw0i`tp|PK_l3+^QlCZkpd2;B
zt~~Z?6%dEv#@?JI$>{}mMDVrVSuTc+%eaN#o@UnVC3zn&=efo<`ecbxHZHElC+<77
zh06`0I9&Ox$fHFEIDEBgSXiXOjf4Grd<@-~ee5yYMXgUC-)ikFo)-X@ENZ&;s&l$g
z;}Ik+{@{Ai@H^pSxy;&U{s!^%l}CZJy__GptUH)fcY6Et`?IP1TIV{$aEG-wlN;RC
zT@5pmwwr7oO1n6&zOF3wt2Az*<*ioz%KZ9Q3B_fc;^5Z6Ny@P8H79bXT{XG3H~+%E
zu&GS>#{6{s3u7BYL@PFJb9u+DaIrHL9zNl3AHw+EGGAoWYC10`?bE!{==#ksGOj;-
zc{6KT<c-?ey_Y!T@V~IVq%!AmSvTXtI=b6dr!^EzWj%jdk>{|o%@m*E|1!6p62Z>e
zo!+qIjlqq4*5Ur5bZ=)4%CARTHSNj^A#_uXnodm7?CM7k6j+2r!)3;cQU4>xoH7u&
z&N@y^;EQKy2?mlz#z3xF#RG|k4@p;hB-W@g0a^(6ZKw;PLw%#&2eP5W{&G)tdIN)8
zYNldH1P<cx987G3;mo_zHVu(d5EKMEN8FcF7_m$pT-fm|(f#!bfJ%hGJQMV2|AWv6
zh6hIBs5NNVzn&RcdW!sbwJskL*!Sne3l%qQ5MdN<F<9Vj+m4`C(vEyY?9=-^GN6`j
z>kd}|6e988nRv)&W1iw8@XmkNd^NDMD##zB=?%W?bk4S1EB#aqdVjqiNpvdSe|ojr
z07q1^2b-*-Y0FCcGbx*J87nrH!u`I67yCm?Q2l<XKZi`*FN0E)d;a}pN4G6(*;X4&
z6VOwv#2VnNO+C8@Qp<r#;^<(?Ht-EP(29tu=1O8PFZCN*2#}XgGc^BNkMpd5eIdON
zQ&g6*s6hd>l251jX$h^@u>NIl>R(R!xPN^~tO+tl<I8aU#+)uc#2om1@h1BJ{i>~F
z@ojCOoDjOm2KQ(J_3v&+zd#pl_}7>Da${hw^FS4LPLZy@CoJoQ(J1D>1^@70U#5f@
z%+(TNg5bBBYRn;^O#$JX+5MH$ltEE^|Br9(MP(v@G`rc#xPJFlG&ZP&SIGN|umM?Q
z4M@&x0O*kus|(%TV9K9^0=fEcfjOa|SP}^FQ$d28zm)9&=H1rDl}X1BtmJ<~U#?>N
zNCQ%6W9(FifXdbV*nepy=>?uG77M5)f(L$uWuVc9KhMc5F!+x;4rw!>YFgpzf5T~V
zs0xEv$j3Fj!=Oyo5}aIW8^Z^7H;8yqel1>SI1mO)IF0>AQ^r@Q^sTxPqB+zh2(kJ;
zINW%^QqvlpGzj08$Bzt5(m{lkA%n&l{?8*7|Mf`WW;t5N==T8`G7T31{!g%!SWx&A
z65A5)PDg{#KVTOBtJ$q?1k`BG0HORF$2f@M(m}tn{a20N7Ge&RsyYqVO&i~;A%1~(
z>cF~SQ2YtL*bK~^JUA-xvz!8|k94Qd7@_K_weG_vLIUtQ9c0+u>-U_;<zYVbWTH8C
z12%^#k9Acjc@Y++Vu;dkI|W)|totxO2<jw*xjc0)cT?@RJgBP?u1+{?un1#vL8?W%
zg|h`9KT2zKfC|*`Igq|*B@6%+2*Qyi)*w(GhppziP4|1wR_A~c=&n7$BRoO53JP&J
zQ;orOa@;+?LCiofG5mosA5;-MGt?_&0XVv!wh3@`!A{~@uxu2wRn$8hJ7v;I>hiV_
z%YH#L?l5Av!XW9Y2=dGz0;pH#;A)UA^D_1)`siM+=URyd2-ehb5V73x>%o5mX8_!)
zfE(NjAhBEHLpBl0!wuN@C{h_{yYWpp^(ygZ)0Ep*lbz&5DwkLPPx<Z@Vm_CXf*QPD
z)4~T;J~+RdgFwLm3fd*tmG{c>>;i~wi}T77g51kKLjmXz2?_c6*>*syz{$CL6>bM2
z5vvD~g~tAReiK^`i+C(0Y#X@7z3dabEhvb_b#wc6RDoik)O4q9v2}WhQ?O&!{h_KV
zK<_(!eat~MJq0}~cee+kj^!hDq2;}WT7m>GJZxh40$mNHZW9vuI%xoXk%jaR_gZCM
z08letX&cJpI#n*sU8z9xz#FKJvAV+r&v@6Xg2lW=wTKCJ4F9{@2ixyON`Z2GMN2y|
zI>b$ABZ4vJc(&PX@Y0mm(*6z~WzZzdZUbyu*ds+hvS%!+4YKD_$fauT_7!OI01RF}
zXvas7Q>hXhIAiW(m8T|As!%|!33i_r)jk&jc+6aoH}o6`#fd7%{wR#JwJ1rgP_eE)
z_kC+c>@Q`^kL2M*uB_@D>60AwlgXeBY#XcIBrzSiqdqOb;h9JV{Edc@RV|G%06;=D
z9_sRLot7)1YHrsE_$EzDFcAVn!-6alerZ_sfDZvsMGd18X6O(rEujbtMV@z$#Rj1I
z4|0gXtptnvUWHxn1~rx0Z8#U2BNWO|%;6Y~sc>p)<Es@7Lzry|d8AGz*_A1g{R7{`
zTJP2p7W>!1uED^dnJkNj2%!q2kyI^(I$7i990Vo0y?yv%d?`2-P#f9xhlPcpKVvm{
zvxi!z|KJx)XXcUow~4^1>ZDkW1^<G^D5zAC_SpP@@}vL{Rv4Y!3XB59^;K~?xPuFx
z95y=MAP1aLkD9T;uD>O+@_1=4Jh7J~MJ1m;*oXeJbsk)##<L_tpX=aIGZpT^tyf8I
z*kuniQYs1)87ahKeKEwcZe^PyEaizs<vV*Q>r}97dwd2E?>AV@!(Sc?g7TE1v1CDk
zZ0N$R2H@9V73>200cg$_$dlig0+J`l-1Zf!&Y3q6bP4%FAs#4As<8noro^-70le!Q
z3I7Zi%NE!J9Z`#Ox`xq#ZOIgBx+mv$H`N2Dbsbw6MDz!#hdbQ&C+oZw5hO7H;&}AT
z(TB1Q_Y?NQw*0t+eP;%wFmk~kHu@^IlF3fBuB;zKXyRW;zMbqoMOVDRI{*xOwkP^*
z_(9;SnCX`PAVjhMpiYDh!0dr{Gp<ERe%pYR^W!q?&UHX6es#psvR*AA3=29peCnKa
z-)vSBBSI9jU@YkI1QJEU0N$+flsUu!3OQlY)%j0OdUFs5o;kBwMo6qj6~G>t&ht};
zT-5i4R$$&zPkhu_BvXi*17rdy<Yq15{R2=on&VSf<zct9gfXf46Ra13x@NP8dA5Wp
z4-&nbNs%k$`>OCVIjp<`JP&*<h|=+>kIUaikA&a-VS+JDfvlQEn#~3mNbfwFR^^^X
zly2jGCimr_bD_Sw%CY-sXO*>=VzE5z&Pw=YgddiO-N(|}j?}nEC$Qn$8Y%v2C{ekP
zfHCz;0qA5<i{MlB(K&G6lhec=iqbLVo&I~I53KI}Ns(a>Qm6m6wbO%wf5uBRPIU(I
zSh=U1bU&V);lv+Dzo8|(+x`e+{tnjkQ%g{SzO!-{)OV42!Ffm(Sl-XaeNRL?M5V=1
zA=rb^315@71ge&Bc<B}S!;_$yW!_z$6jYO~nZf$nwPitRYj%z@UrWf#Nl+7ZY@8Y&
z;nbar8%b4IPnSNoWS!Jlsn#f3I)yQm&Gc{H+4)}IfDw%ZQ_8d1!K$`LzZr)`)$o<2
zDH|9RhonQ8p~jjp>%#{8?d+E4vt0Qo?yoVMyz`aa_2_Dz6X=Yrd+q-`S9K<@s*7i2
za6ME@P|T60({tf>rud3bTji`EO^`CJG?(>0+Z(ANx9qvwWH21vUu6+N9f|G~#n$Do
zp(UcrW7k(^r%!A7@G>y3dr~LYctZJe<dy&ZwJrkt-(IfRMu|H8K?7Qx@?`q<DvnbF
z>%Ai#7}=7#fNp2loth2Y`L;}jp4<j|S~yeLMODrhUPZl{sI^S_!I%=HZyWm>WvsQ~
zPsXL&YvK3Ik;?iHIWyC5HO8iN%rv-+x;%9ajA<U9zjS89@ze2dWJ}hw$r<);D^_K0
z0r`dPd@Pwh)BOBO^2ERt`Df*jW@atPK}$Hl_b5-_`haE?0DWgzFKC8ldNZ>wCI5WF
z-I7&dYq+n>e=hr~?dS5&<$~(WvY^BUm#@iP<#k5O#opwWO$>?3(+Kzpve~`%&Uy8D
zE~nil*`LwSX|rBup|)py1T1D-l`H-fw?u=LJ}nfbnc-DwgQq-GNoiUYF5jg*{F6E)
zko;5efihOfe2+|DNgTJ~74cHxA}rE6q^ZEW1RjR}c2r?_hF{E_WNm1BG0@kvVx|54
z<6h1-x9>nVKZp23>$HT2n{8;}oxu6c-}Po^W`mrA>%(rV3<M%P3w0UorAf!(tM|7-
z{s>#-*an)W8+o9~xqrjPDULe8mnx`Mzls}jt=MC_P*5*=QUFe+guz0@{NG|04L!+#
zCDo5`W;2PUF+)S5*(oxh<8C#>=XCJM_!?n1<Pg~AWzawct)1DA*qIt;G>Cu&{#6%d
z10XAb##Wg{pR(IHMRm9qw09+VcK6%$f6h=FU}Ja~v(mr)p_wVu`R4g`#w}7_H;BIM
z*~Obi88i9S7e~QGz`cCN<Xy61kFG8d+kYJSHxM{?x=9Ag01IITFMMMdpoDJ>|Eq!g
z9qw@4mG%COux5P1MX&?a*U`(aQvKUm)jTF@lRdQedSX}MoT}59!3K_Sr5j~eUd{`S
z#aG)pmo$x_{_fU2@>jRNr<GYtHm@(8x!~Xzzq2zK9pM)X=LTBJgTJ2^o=x~e<er)q
zc)L3=k~kssufBV^N1nn*zB-l64CMHaGi+)ozRmgJy*6yE1w7T^`jfqNm*a%n`m&4T
zeps%(#!Lvd1rNiHS=FbP?9mcPRmTr4uRRv*)=+Zkq1PhQsI1%E+ZCnO<I6vGI9u+S
zFP?MoS?#xlc8gu39qfJsf6eAz`DA8#FFMFHdYjot>6x5u#){yc$M;tj$Z|KYs#l{h
z%QCftI2oUzWHg0ene`Vpu1;O8t{X=wqMKD5u}qjPg2Sm>*(rfBMR9j_7(aa6HSv0_
z$~S%K#t+OVMdKe*tyi`WRHE6!mG^-UBUeb{dv@-~=U7<eMQr5svV1*XR6HukyWK0Y
zD6>0s^thwABfF}i{`bX-@tn;ww`P>3w#UMq6t$|rIL81K!bd3vw4C?T+)Z+}aowj?
zK6rg_bCH*#B02s2&38*TR@5M_ri)JO+kCK!nbh@1SMFbH<A0Fa+`QBw$6nSvsXy$s
zcGGF#*^YKSoIzzZHbXgENb(Dp+NRZw*^~c0n%(H%GtVeweYJ)CwIJum_k#|8*|mzD
zwZX!BzP|F&5xebJ+lgn-i~@);xS?xf>4A`@Pc^WY(sMhKlX)rdeQigobq=L&ZIvYR
zW!cJ9@A#1UXOdW^66dti!?r235nZ<2u?@n7D<{FS-o!ILSv_8lg`7Pc@7oSbzdrB8
zPdU$1<lL8eSrvK+c%#uEQSAAwk=9l|N$A=Tqq(cPCU-$&^9@+XZlB?DxA`4t8e`+M
ztNc03oJBQ#bI~lWImp-gN>iA_tE{V<_0wPydK74L3wgZ3g*FQ)eBnyUdE)r&hM*Ls
z%TJqKo#JCJ1*7!CLf86c?W31WEsOA<Hf`OUi@wvn&a9$7>10v+EC|h<?vo??V#*TZ
zUqa;%Z*K92W_Vj6ZM{;vKQb;>u{^ymX%5|ftZ`lCX8Wd@Jwcg+PxO1*IEJO%6uQEr
z3D&1QAG11sYu~q9^6%Cgo~r(Me>nF5EpYMm^7!4kh9u4UuE_yu>9K3CcIO5KbT?$#
zmzQ+T9p&dH6Vg^8yLpKP*i7z0czR%>qv$d6ERaEoAaPi%Ih_66{e9oACwIghx$iYK
zYg(?;g{*Prn{zTVUKLb&cn4HI_h~W=h;a@2UNVfUUQsJCoRD5T^Hz3u;rdVB<DS1b
z{(c(gSuerO>b*1R_BumFb2G0efRNqV-emjEC?mhzwq)_blRomz?}ytZSJ>8Uk3X8U
z{5q*bopWb}Jdd@On(<zhf5#Q7YvlFBeaea^>`veK%-gss!OgT`Dm8P%0;a~kr0&IG
zf}7iwBdbnic;_**h}m|>s4HW<AMM$*r=mLh*0XBFixtMcT~Y1IsB^f_+_q9Epep@+
zstQf2EK;Rk$=f+8=Qk&3<|Z_>+(?bu>iF^O8q%R9*Cy@0>-X{Ccz$9l5#&-G?)Y6P
zyV)wt{hbKf6v=jH?8rISoK@B17-*WX$2%=2=l4e1`nJ(wQ*yc=3B5DF{{CgD?=`3B
zAI_!i_!b2Y%9S3_IJY{4B}{|%7F9fbrfQnj<6|0s?RKP#y}esjb4>m%-ikdwXFxM@
zX+t#XpSi6CyQhXb+*=Ti%J172?2g(%0}{jQ-l|2qw7X>coE@FYYg)pJQkB4MbeN>`
z)%}7He2IH+&y1lB;RlrWKuRbP+P7LNoTTaSe<67Lfpbnf!$@f?JP;%I`(f}gL`%p9
zl~YeN?Vj2IFne~Vx0#2+yx)Q~Olo!PXEOPF2xCJhsxqBKsp2tP_!zfdQdRq7x$QTa
zek-JWO34giVG?Kj|H=@N1+?P;%fbu({HU?a1+}*YExrL3#?|O5X0-;smq1=K*mlRC
zYajrDm6eHTXG=AZZZJfVD0RhID^Y0hu^Rcs_8BMxiB2?T3+_&daN4tVEaNvVA&|al
z@Skk-KUhC%g!KbOKyvrC@LW`@aW}L>Ad_QWp$r&c3>oRvf%$Z`KPY(NJ#?CtmJk3?
zg-kuO0kVem;K&2htd^<6ux08Bm4^mIO=AF7+CD?o0l1JUV;vbmiV}jzDYpm$zhG$z
z9?tk)9Hb|u$Opz^7`Ve0UJI#;$pqO;Lw`8^_=_-N!UL5_w>PDX*Z?UN%JMeAutG!7
zqv}jaCr?udP>MS<j7bQ9LTbueLvREGitzUetTQkUC^+Ej#D6c{<nN_R*f|_odv-pM
z$@Rfa{>P$k!1<5~ssGa%9}vRekrc87oJ0T|hG8~(CLf_jVpL-PXFB{JBC~yt;`}z8
z5>fZ|P>{Z+NNfwvoNt!!hTN|gE`u)}oRsD!hXF1c8{4cI!jMz_LAi5uKsQ!q4B{t=
zpN+4pXf%e(Ean?It&pvQFU4Y%vVR%iA_xIA1L|<Kl<8?32IyzIj|VO4fagf1IKr|>
za15r0p$lkkDjaGZL8@gx&{58&{{26k@qqz<L(E-5wn$7V>r_0?eeqFa6>Q!q6!wD%
zW;b{Zl!|QhZ~oCBIPLyUr6aou6IIXiE|F^M%V9DsQTdga)iOX~RLD?Pmkwgz30pKk
zp@MC~0G+ChkGTzrlKXW)D}*=^U^Qf*umM`a`gGXzOlcPcnv%9z{g8wEI|Z7L`~-^H
z?|LYF9?&H_@P+sV*#GhVF*+&|6TCH~LT-@L*2ZsBQGGTLKSDpCyFeq!zo{)d!CTld
zVfSIPF3_#t*blWCgYL3jP>{;J$O(-8WUD3I0Z>gN@Dvx1tIT+kDZKd_oWivRld7*u
zajGEq$5_T7<Z?5_7X>dT@o?4OhuhB?OzyTu#1yii*R5v8FAC8BB2XEufo)HXTHE+<
zAgQt-q8sTWZmd^xTpG^B^jG3KfHY=+7M2s!4Xpr#Y-0oqrba`rA&B*6p#AAy`Ux}*
z+?lY;s}b(~OtPe!Mo`OEKfC}3hzVN420+lTj>0%91AJa=hL{o}c0*YTnQznGzuA{<
zfVd*~di0LrcPyw>1T)!Tk&{1CD5Xr$U4fk4f#=bwdcf-$c~C8;|5^%=!#DH#figV%
zXpo+U$7g!<sG{mk2hBG2rI?<hf?e<jM*wnA365ugrsQmF58s1DyDm)wK#!n<hPWqQ
zV;ycY&%+5bG=`0Xy^H+YQeqU~uxyw(+lLsNHy)Mau5H`MFWmrAM1~TuJ?YPnObN}X
ziL)Ny5bZ&q!J|-s8%P9pz)o7>bn`>`g+ekU*cgyDlz9sn1~;Zhsc20I{6t<98G!|3
zt5NkyC+mzZ0AY}exZLPXTL!y3I;<wS+bOmMcOF9i1(;S$FJLsWb(y*In|_wj0zgRt
zdMUFlEfc|fAebrnFQ5V(HUQX=?&K(Nioog23jjqm!|e1q#)*uRvQimF>jVrckk=o3
z1p^2;pfK5d@gRE?0VEu1W$?^5*);t&%r9<RM5mew!;;bh@=KYfkiu1USrrO}bUIws
z$a3Kf@{_g#(%Z~8{b1ArYakEi;Z6liVWkl*VkrXO96YaJ3(Qvmk{kcqy14*bX><BF
z-^c5k<gG30r*2QF4KnY<iS#<xP_Y;`SI*s*Hb|72eb4bY1(wLt-1p8<k-1EHc&ZfB
zx3Tl>2P0GE?qtv#0PbhkXzEjPg+O+gy7<gI#$q*)04t|GsO2vD3%N=J%$ia`mknSf
z9;3y9)FCbCOpbdR-&K%_7sA|B7Y{hbE=y8sge{X8bifqX_*pLB0n8e_l_*g%`Xj7U
zCT%9T2?7eWQZ@)9VOqlSS31hM<p3Py@)+P;0AozBgWZB*3TLKQHwTXswyFFB{PT4u
z4UjLEvu{y13|xUtFrH042pGm19a*@*vP=q*B{<Ed%QYlDj}<FpwLJNpH;bbR(MWib
z&aW$u65m7SV8F4)55OWAE%nglUavoB2Cc_*ZU_8GP&qopkcVPkI-L{<rP#6ReuhX=
zO(F33y5@x{`C}d;D8oli9ZL%)7RBJfGR*6eEn@DQ*wq+r#Av$Kx8}_Yxrq^o?-%Dd
zLgP{O3oW76Pim5oZO!<EQ`J1Uc(m=_?roO+EG4HC;6Q=H2YM(4fF(}Pwr06mCnUgp
zrDFficSa1=NANgVnUMV2I7|(e-d@Cp9YPKl6b!{p)iVz`yrHC)A}ketYjzZlH1%Ks
z1608^phEzwKLHT<7qGwQ>iE)5ZdHNiI>HL&jE({qN|d`awrq|X&kH)|^bhv7_wg-#
zG>|QV8M-=q{1TY56u9U{+0dB_*WW)u4-?7QDNu^@fngxDSpy4y$&`G$9m7+rgqZ)3
z1<C8=Y7cZl<u36O*Z@Iu1G<K}7}#KIdTz_5W0Wx+UUy1$HS{yb{T@aL$R?b_rxjR9
zd&DZ-9I(lf7I2NjxHc5%0fqBs4dd@cIqHqp<LI%dc)_M!*VKB~)Z#`wf>~;`k-SM?
zh0>8$kY^EC8#nLTA9YVoj9lx%iDT%axQQCJwHtQ#1euGE(Gn~bf)k@L0E?WblxQG(
z;0;Rz8j`^UpPw0h@oqlmxS>_xlF%gp>?5J`=z1>TV#UlC94H6QgtGC^;OET;FeaAT
zrspFsqTJiHXQ}zF-h7+}CQSZeP%cz197f6PrV!EDNak7PChKYR2^~wG0+8+wb$HH2
zqzNF+7h0N^gMf6DIDCZ{vz}MGVWVdIYc1gl$P?tGd*hzGG?ScuQe?RXTicxU=)$w~
z*4T!xI9vs&cUzp+tm(E2o?(!_ktD;svEVNKy0$?6YMpju)c?>DZg_V<wW=-1HIP1U
zA4?DBOL}^E*4&D=D?gcS^|p<C;M6GI@h3gyw}%#vI^0-VAF`-g&C6<&?{0D0OWVV=
zv@~C+sAAEaGcK-O8lT6s#PWQjDPJ@^B;L0z*lWgg_DQv`4mgi{=`h5W*}@=yc(gRg
z=yGWn?+a19Ei@oYjKV)>-Mah^(Av}$yRTk*P&%D>1q7nArRbQ1HOIW9ud4GnXR>>8
znx9t$3|;#VlAJajWC;A*v;DwzANSW!KF^MZ#yh|}m15Z0eSjM<?DU0069xDhkVb-r
zPw_-9D%PRa?70`BzI(DflskH?5u%c?>Ca)9zT{*l{t;!*i?@&If>!`^`jd6Sshc5W
z^HQ8JeEqI#32PaYeFiGPnsS_cHdxesl4}H@Bo1rk48M=vo1i`Te$eDS%Gd1%W~L3v
zf|>mOrfu}q!4~1j&-d<)FXB{5cpPfyr{6057c_j+r;jIX%{d-0i`>bz_?q6&#qMV+
z5Pbe%jSXU_v_#$y_H*o^IwZ94co^^-uNYo!AQ-(JT4<m`Nm4vCdemG%urwk7>V%e1
ziJQd@zHW4@9vA%N`n(b;Mpjlu{|VYL0fNZ8DE;PpoLSaTfUUyUC{j;Ry;<@2jR}8;
zYW>KQ@Aw!C2Eima$W&%=^SK5oP^pm40{5JeBTc0EaT|~akWAa7lb4PNxp9(L6^@sw
zHAmv}H86#bLC$|}`qP9+<^*KOaMwP+iH<8etV99^MWU|MFhD{FT+C#Z%;Lu&aqIiA
zsbX@(qs%@^iJ<d&?ZfY=o5!?7iv^}<s&g!h*gL&pzg1QCA=e#h*k`t8{OOUmH+$49
zd&}>3vPMw{XehCDq2{&_I9Xc&?})c~Z+e>CGdbekv32i~m+mQOoBzpn-@cM3SqcYv
z@T*01FN~eTlrrKOSFD#sWcWAR7)uO%=B2eAt6u0I!e1aCH}m6|Yb6i7+K*l@T3YY)
zC2UXb9paRrOy<PE6Ifc0@oyF8n?nMsW-i%N412qO+*Nb5I_OT2^SHBd<~A|Y7`c=l
zm(+NC(vjGXYs{S(v>2oftp2^;V^HK|Ex}dn>bYfA{z9AV-HAqVIp`Z7pX3Ba?LOAw
zA&qX_1_588F3Yo?q6{laa-*db&)in~H7hPEeAml$Y3|EFVqCFA&ta>xQEVLZ=%Gc&
zi$7s0{tIm9O71oO)+hHZEN6K+1%`N576;#t106)Sk0(8noQ1E8osI6?8eTSUiRo}q
z(k?w@R-8c1qf-2o@Rg)S8t9V($#K)2(>B<br*V$;MgGXieo+@{+eI<x1?@I}hmy7i
zT4Ny$Kg-K(Gq@~1sxFL{)Cp#;ls`P+KP)zrMDw0oQu}6m#Nnj3vBTrZ70uDV|7B<D
zk`%XZZj7Vb5x=J9iIsXXJ)@dnBA*-ZhE?9sBTyTFOg-T19FK2gBUK9vuo)CAm*MwI
zhi|A^Z2EMg-Rn08cOAbUzbDeT8d+g~^uw0XT@!t0&+?Hh@sU#;eCSJ41&ZEY`l<iC
z9OKmSp-qO<Thy?*>&?bOK4@M}c7p|r;SO-yL16(Z{4S!J^MwhZz`O8Ib3o~U)(#e6
z0~4i5UB1WxNxm|k4VrQwlpoa+_IYRte-c#yhEUzJiN_BE(h-7hMY|@3EK`dF-8MEf
z=%>SAcUNszP*8|~n*+@Bd2$)14=!Iy_+c^FVFpHk+v>sH#*-my;I+VjX;49%vapm-
z9c<<&{z^Ex9hX409Ns>khjY7V7>2}JgJQE9EaW=^n3M%j*9<wT$a~Y>hJwm>h!j_V
znvr-P|Hb|vBneO+;`?zBtV*9WLiw;r2oji}MC=Fy10hW;;NTDQ5#!t+@>4j7$7j`W
z2mlxu?EhvMu)g<{3Dh(7&Xr$Qd!kUO=>K&F;(u`zSl_jTKj1)6<yY#nMa1H$9uRey
z)eKo2Bn9#>W0BRD#AvX<uht%?!>tj(i9*)a0~Z?RM}W+0HnH7X3c(s!sQ?Y8EwknO
z;R!SnoFe&o!w&klRA!Zl1nKO<<|>dSMw{cCQK6WvAa&vvg#)D)HsMDj@*ug9hM0g5
zz5~xB;TOS?`U5Cpdn1M6<{PpAX0y>KSWMyv401z2p$CKBI{gY&j?obcl^bK9AE1x&
zd7Zj~2dG9Out_Ze&6R2iPpIal&vR^UB78o+8Bv)?G6%UJ;67GA(FED3mnvjDQ8RXS
z^6I&B-^%Lfuc6x~bQ<>mG)>CjG<G22dkK+Y_&9FzdZqf08R33P395z@vVQUl4LSiu
zC{Xb~IUYwKZl>yYz_Vg}qnKk+YS_9x<{w>a*AjMsj;Wdlh;Q$10{tSnZ|){5$f{PR
zzyj`|XbG|IOxd_LrL3C&G8P3E^vMv^p7awcN;g1Uf(MU^eq$(UJ&6Og;L!EeRt6hn
z#GfPqN&S_m2BX`!DcFV}x{d#v?qm>&!Lj?YAV}bl16hXt=hYR&PEXA!6Lph~@)BCW
z#@^+^6gi^2C+oFp|DUK#nTm_+bz(yE5;?T$zo*&)u_Zud)>y|x?^-dQFXF4fA=&)5
zv|)3$Q-ELXzh_z*`gci5x(($5+YzxUzPG%#t>LS$(X;y2b-<;sWwy*Gd@~E=Zw=J7
zi5`I2(tHxWQNDp{o-72HY%^3$9csmb__`a@{TKPtq-7~&36}>5j&1KgD%5-%wVxCV
zF2`S%;%6Z-XkSWJWA~8zkR||JrdKiV(g)C|ZT-YJO3ILT-vXswe)tqMRJ|8C1%2EN
z!95NB<<gc7u*;11${>C{u^J%{S;Rply`UPkp=8qGh%?6Zpz)nJ=#&6T)(#6Q2R&Q1
zmXNbTtodx52rg4<m}0VNYs@bOBKFrX<9jUvz~PW34?GQ_3kNj6ME+|5Wg4E2!-(b%
z^1XDr763ra{yS3Su9XB&E#di}av=`iH<#UlzXNyl9%#jvA~_unM<<J0!0ofUiMkJP
zcm|*>#_Z}!AF!KkN?AE9)(Jbp;m(A{*VZ`?QS6n3r2dF>3<sCCotRh{Onw~#K}Gl|
zmA8)Mq`M<(ts`Jz+s1DS(Cax1&(`_n;OJQ0L;66~X;2rjOzfO}X7DkWHn;#kWn%+8
zZflB;k0Ol0SE^GS_AGkW*;$$f?qFfGH59>2aL`jhod#BZx2RTy6Z^=YnYy}nhoDD?
z2Jifbn}E4GPM>6TlC32?t0>1azyUkqQ-a}2D3;&wV{pR}{UFbdi~>fBOlHh`B3-G@
zf9ABhbhRLX$52*2eU~RDu=T6X38WPFl!Q^qcm@eS3ya%S=4yR0s(w{Fz@jm0<?4tp
zWRZ^B(qU7Yk^`>lU`HRERMT~>Lr|1O!_Rhrr4!LNbc(bE`1|dH`(C2+EZ_o@#lSry
zO8RFkVE^e4L-^b`sSDs|An$l!2KEbKLQp^$v)Lf3o~Lipfdfpcq%;)ZvO95F2IejM
zmT;YMv&9&>7S8QdMWVOx7htJ~xG6}tR7$va=76+5!t;X}WrALqweyq7+(9mt8vP@9
zHU?pysNzwq9ECeZ!A+zTY_%BG<RuKg6H?i}#m&@l8w@j01MVww3gQbFXhuBS<QH?#
z!&Jmzvs7QVteGJvYAiwES8E*cMg}$nZYu*mXvm<LT5@jTiZ*N+=2f^)h8et;wWJ{Q
zq(k@z$5fLyA2yxj-Bw6V(7<FYAL$qeG>fbyfJT5zP<a0(F=nLkz5ym(KitFYWpGe$
z`R=`|P9`klf+!7aY$?Dcbh$WS(P#qj2YK+9Exj`C`20Ahh61<eY)`%teh1Ce`OTfe
zdWg?BcHqjXKull8m#}IdJn+<Gak*VEJJ{LY#zD}vNA@gFN-x10vX0v@nN5H$gdY5Z
zr84G&u*!7&LvO2I1`Y#Ei}{Gr^8`2pGu#!zcVfYVtBv@eR|5uu%4%omV+G21tpJ`z
zY9@a;{Z)6%HIErUN&p~~BClexp$Ix(OXxL%lYX7>{5$ng42jeX#8X?Z$B-P9HNiv=
z;k83Q$Ko|R%QHT#jrvBb35GM7rFF4#F17(~qvFlKo;K~)fk(O<YTk13Rp^xy22wCE
zpao!G4+qbp+3;Wdv;`RmyN$C31c>YOpNSrG7}HxA>uLHAZD_$UjzdR&1aX>cf@o4u
z@nQZL{M@v7I{p>RNK62BIiSc&Kiy3|p%7T%&$dO1-)~NO^G?9+182cZC&^2(^$<GW
zohfNU*fN8GV;HxJ1>k826iL9@tdRp`BH$~%bEv_31K<^Phq;9GYhz&D2L_kjM2YR7
zGl54B;hZrB%0Vfp?_;AQ1Lh(Al|5?&xJx|`ZBO3$dNN0U3i8Sj8_GhB)S6j9i(U-a
zeBapzy~smi6HZ%@*Uybc0y~nibfS6$tc17)L~_CNSkD1{3v)4eA{TVg3YIC`V?1DH
z*<(L|b7Ad|;=XX4cEMs63$vmjQ-2&A=VM;PWve+EO7p+(qS;Xj^dg!3VE`)t{H7;%
z4ZuvMz(-lCKBUi+i3Q`Ys>Ura&xUsk_%Kp-hVgDTpo5L}eaD7U@<KF>x8t)l{EeR2
zLqxLz@PT+s3||5uDwV?Jx1)&BKIPOG8e%)lc1O}Jy>yThD6<a%iUe8s<M^_id-(lB
zwg_LAx)91jI!p0gGKxf4CaLaxMP$qWHj#c_8oL^Kur_#=rLWnm6)`ehMgx1n90m$J
z?vJ-PO>P{b_N!mg(_ttw`_4H*@+hS@-iO)zukgB-1SX%QB}{_Zj<NEq;GBU^9^tLf
zSe-)^Q}tDz2_*#>$Y5M&zesrqQWu9RY>dgo(%Dght`;s9C8(68KBX7t?tqnGe{asA
z!ds==t<-cIwo3Novwtb8sj8r$v`Nb9h`#0UL-Dax5Jv$CQ3^%16a1e>4EKG`TO^~?
zZsA_eoy>1<99Q)4^o@a91SJ8LVuScD;X>uX_ls;GOjk3rTY5I>L$^=%Lu6g+=2{<v
z#e9CxN-d!Rg1!{mr=`&AT#$I&Nfm_fS3j}kZG|sx+Qon$!|##A-;-z+G*xLu!bqEu
z5O7Jr3E5^7UBF^s6{ID2VF8D-s)2#XFjxE(NPLV7dF*@V?I`6X3-71cz-1voP4AV<
z5On~kc|dt_9=dnzAMPJa>IxVdyubOrqi76HtH*hq-c~);oB5=z2?Y#lF*w&XkAZO8
zZD<H{%`j%??~m7yd~1Dn1vld)M&k2gc7mkk4VV~~C)(LG6uSEah>@=WZ_pafmN2I4
ze&Y~Bg@VX(^}`lyU)_nHAOn_PfiX|RQ~@`A%=w}`wn+fGrx+EjoNB^BSjV>DvD;(v
z%vOI`AiaO6>Wyt^9cbJDuJwQi#63G$o#&ITBjLnITC44?LBjT+<AGPud3*$UgQ_bJ
z+vv04vQ$>*%U>AG;0!7}&S3=Yt*)X{GP!m4w;QK}J=P{YXA9I^wXE{Xs842GRPFQ{
z{|09Ud|=d-HkXDMjz;zSb}O!<LCtggS3bY*J-6Wg^-J-Gr^jsPuEdV0H=kx3betLO
z;gasM>-G6^U(d{pD{Yla)0ZS=YgW*|@Ma+1$Thm5(x}h;y_5SQ5$nnk^DM)h@=%*c
zE@h*;3KxrfpC61Kr&l!7)Q_|@`Kjx9XS*d9U)PQ)@Krc)Qt;%$Kj>^ID;Aw>4@!M3
z5)kv^;Y|Hf#ueBIpC1U@zs8;*zUE`mrJ`XGC*rPOECQL8ejnBO>W}OT&Y_O>-ah`1
zKh4bvTl_pFt`P^gq;F!HcioxgFDq8HOT6Z$IRyw);xk|R*j-;F3|VwMJNT0qD_Zb4
z_f-|Z33-NrPQ~s+MU*Sn6I;g36RZ=FE@XdoDRMV0H~;IP#EyH~MRVP9H^=wFa{CFd
zU*>1WHBy(_nKWMWh~kV7I$zvJ7WXizekuj45R@F}U4cKb^NebXmCwTxTcb$<(Ill?
zvu8lS!7sgEkM6sB=k}3<`@qLydt#ie1^!J-FhV@Xg>30VN?8{g*C@9&kE3p$i8CH4
zB}F;7ab>pA1YV<8;;zhWByxe-OUr7*Gv`kaw=Ex5e&}U3`75;P4#Fy9bA;}!52>Tx
znsLyRco61wY?8y?LoJ+pbYM=9`%%J@dq3~(H>kp}ks#4a`0!caSdhi(J`fULCWsHQ
zvJZT_ob2bf{N1nxug?|kn=$d!pFfKHhDi40gy%16CQox^dp4yTIC7V!KhW$ho_RPa
z=Ts53J;^ro%JjJ=5~ImMEg?_&W@ao(7&PtXdBh-e@5tZITX?@%H|)l`F*kxfnnZmV
zzv-ynEfF;g-SCrkN?24lpL3YwZ)I~$WVJZTe(bqx0jqMBt=Qo2Grwu+Z&58vjaU7?
z>-6l@(%;61KPRU}-W6sM1zaek!+5%gTEZL208L)Qe4}O`lj5~Yo`t`oOk!Esr+-)N
z$e8JQ*>~g@(dVf<5_Vo+zjAmIW8c+9sf9~LjIjK5KcNYfKx*;rZJtl|y;xYZ#5?GC
zk9ib);AGa4s#~8+b7#a3Gy48H_2g{P+41g-HeHimfEP-49WOp~@_VrQqYWTo6Na7p
zzCchzpW1_f=yQZorzdAr3Qsf6A)~ClMDzID#2-?jaEqWL6{llwP97Hgt>9F3-O{MJ
zZ)c@9SFRj6_kKXu{HEz#^FC_Rhh$MiGp`7`IP<UfyzR<}7S^c1dDYzy{9nct$H@|+
zx#Bq{p=TyG6trF*-yS({cbPFvMSebFzDl_Q;t@0v^mm7$*k%7&ymQQP_z17HOCwqs
zQv&}gNeL8`8n3LB+S_>VdYvnB^}<qyMA~d>kYSD=ylEb;qQ!B{dTRV%ITfd0@5wVq
zl3CtDC4IiZC+c-1BcR7kW7+v#0L>~Krj)!5HWiab2Z9K+EzGg+z3UduZ&`0dOV9Z|
z?YJEqJMP@@`wghmiV2Oo95xJ*jJb5}*8bgZcV61#KHYccB|=l|EgPT->qa2Qk^OAt
z!pCWSlAR*{dB_*Kf=stvjZPN*5BB~&9_sY}AIG&FbkZbB5mQOB7F&^ZoZ42BG)X1I
zw5fz-g$%|#Lz3fcY}trOPN_5%V>X9*I!|q@DaR0VQV!!V6UNgVp8LI2d+2rhz52Y~
z|Ns7wZpAg%^|-F<alAk7SH|Unm-f+BJAnhZRDSGXq+<64Pmp(LaP6}a&wl{xB+O5v
zmlA{bWgTdxyP0gvkv3V}Kidyo1Q1$$0%0-pTeK6>velETSDHgA)*gHntHYwK>;=O5
z6NdVtv2>N@v_bO&9?uF2v!hfRlP}y`UViA3S-Q=Q%ikOJz34g9K3ZKdB~%>4(S*_&
z?E35aFatU=JuQDUc)r`9;NsM{lx$jaaEA~u3;;EX6Ab^5e#}w3YGKQB(?^X<gJMpm
zIcy{femHR6t>?_)wb#G4u>SRY6#iY50)Q#gUtFjH5r(cwJUn8a4-M5>Dse!t;V+0~
zOV-Onjj%R~(4`XTB-;y*9Lf1^HWon-l|krH*CBijHNJ0&I4mK=9szs3$fzUfK5`Lp
zt<TXC5q~47B5=d={5QjaMP0|-iNTE-KXrFuM<TU;I~%g37w_CAx8wD0ec@!;A~+)6
zojpYvO^~fcbh(EZ73T5Ap=U_pg--ku@}EjSv~tA@?s4~2%~yHTO^uz*qAnL+*f8#d
z+$GIj%d`=bQ$mZkXDF`Ddv!*#>hZ2Xy?4hxwv*8|jDZmLJ&s!Ky{Fw&i~Z2AJjFNo
zZGN3OG5<*7_q>g%M^C01tjsh&=zTS&qGHRk`$f9?ZKw|iq{!03tp_@oTcM|H??07}
z8{!of{ww=WMt4eOve{sb)p>L{<F-5;B(PRaSO3vn>d%m4arg#z-{aect%8NZ$$?2B
zfgUSa6)WJ#)dtW-^#YU2)7VmW9bO$_G!n{<6U5v2j7H8C=0ap&&UYOpWFy4T9&zLu
zHV3+03#Dobe;$%B_2{A(Sw*jh0XLP{Z}<BE+wL>&XR%!Zbde#A*ae-#FCo8#mRDg#
z9{l)`M?A;+BE<C=QpBZVY6JMM1Fem0s7bc#m<4&l6WEvvW&(e;PfJyBftTCP$UCM7
z8pGp=H$0<W^o3QXc8<X-yW(J4n!>0kvqOe%&#+Ey@SX~Mhnd-wMF6hga+rJ5cBKd}
zSIeq}%JqODxU9)Yr4z37ZGJgLQ+X}-6rIlH8R6@s=Th=}hnPAdqwMn7RrLFE_p%B&
zEl>?{rYEFarl|EQQjJo!`3PZ=J)uYA`!=};&mz?1;xtFCY75VUs@+9WZMC%^8VdzJ
zDOD=Ix9v)LiKW0<Sf;s$-s`$I@#UM122l&Liv2WJh26`0?N#^i*q(Ok;pzvIU1ieA
z$AP~)j~U{gi+gB<A?&sOf3~bWOUjMHSSK?AZ@C~>pDn0%Y``uWv$heX^Tr#CkXRAJ
zH3@X*B$fSugx*5>T3rwZcR*CoTYW#1+F&x*{%i(W{gr(8=?S^sonvqIW%k~8-S+*}
zD=)|t<eA8Y2iH<wvm~CKX3dNFgl<DgQipZ8_}bJWdiH)b9;S=6w~|r=sgxC4n`TD0
z_&^D^dM(!80z=OTe$DW`eBW-*Y<k;;^KTk;8HJMSPAY&-_%)X+*Pl$!iI5Cn*>c4v
zzZUeI)UqcXWH#id*i!1nsteS)@-Pu=mzdIo#{jc#2%VvJZxdv*l9Ib8ZPy~z0>V;X
zFKfi^mOIh^U<I><WW*1=WIM0=Wxr)ky07n@H~yM$r<z9_T6Ugwc`xLejLZ?&3qV)J
zZ%ku1ViK2AN4VS#C+i`RTzCz@otN?`aTU0RK%Kf6N7_P?t!B@&aK6)i)(b|Wgs*jU
z(%=6^N`A$i3P#)d#B-JR^!-uKi1DF{CBD#Ak@&dPzz{`TIBrWFpaPsm2eV7$BUj@{
zZi@q(;3W8~DV*{kRYmS7!r*`FAX^|5J~gSzip!42EjC@4Ij_94%3F{nd=he|tohV~
z5=?wSOF`S|&XO_jHq)cVlds3dUGB8O+#3)*u80Kz^E;=Eia`t;rSXlJ`ETU=5lC!R
zhh1J}bYHF_HmS?r-uG^x0jm~3HYj;xxw7aIY0JuMuf+2^3Oh2d{gM#4*f-tj&Y*9|
zxX$>=zMeBQxP<93T=xN!K0Y*E;?a(h&jkW91SatAjq_a~_RKqY-#SGMQ;)O=>6B?B
z@qE2bVE>Y-bIGRi2$6DZ2z&)rCa)txe7G)fh1XHiZqd6N0u!ZS>4RUdly~1><(jfA
zH*dK7+xjS9Gyc)%M5E9j;>V-BC00lv$lk*uFRBvB1_=<Q*LRQC;gYEHL)bCy?1Tr_
zT3q~MlDepp++H!2k!mtYU4<kH_Pt_aiRU>yNlH{8t$Ahd<2OX|3n$}+#t(G5>s&Ie
zgy*I`TSj})r~`U4p)(*-<I_6^CLY;EvBWOuqF&j4(zggjWXPjmPT^sa7*JVBRWNC;
zm{5yddxo%_jFmfww!x3-hJh-?^4~oi=a|QjZ#TKpb4a%GK}x^|Kg+m3B92GC!m%Jk
zpTeSDq^ba4B}pS^Jz^sEsI^@vb}EWS4gCI8`if~nbmd2qHi&a_H@@`E(MGa;a-TB1
zG%MQ1N*;vB4B1}~*k`!Jl{K|>ppHlN9EwT_t^P0(&dC~njuQebL@CeRa54!5WHBz}
zjtWeDc3_ihpeRPrL|%<}C^vCdl3!GWH3ICn7uu?`25~UXUiPrhqJz1@&Z2E}QWmh{
zU5`g~E5Cx;u)TsLd1jlMnOuClFF|$)sx__JBGTd#M*PJl_0%$aZLjw+L{V5kOKClf
zv~w%jOX?r^d09RY^=0wl_!UDrI*%%u$YEZkx*KynQZ5~Eq10!*P4hjBd-Y32_n%7b
zRGQt)aCg`@=r{r@^PPP1z7<vdlpq9Dc%};9f(~^mjlmeUQ6XO>%@f&=q=+bd!l+sv
zxve}HZPU?1ywz=2A{wGBu5yaCU680#5`)AB@g2%i@NV$}OiYNlxacCuBCiJB&^i`^
ze@H+IElOIQvNIQ%3MntO?a@U-nVCFD0TM6V3@PCf8H)@^4z}RVQWwcjisPF=IZCrA
zi4FpeEFLuuRmSt9P7E}lYVD-p`O`^f%f^#!)kP2J!8~35ovAh7oGR1kkaYgMvHZOT
zK?JO|)d;QU)P>%jy|NGnzgvM@S)GNW_C8Z^UP38a88Z0Rv{Xj+$+1v`i}mXRUq6@J
zRs0N}#iUS6?MKFGXfya93LV54y0LhihIN40WG})HMe+kFf!1?ObM#|b8m=5s3c{%~
zH!MVA_=0-#3zm9{l14OpS;{vFOT~&{<q==m+?}$szL3ble>_&_TPRs0N9m!c7XY3!
zZNEX9%_?!-x(5(F&?n|+Fv?UdBx9e6TD152LkpPKjMMe6kXi4%sA@J1K1YA9=!`O#
zhjM;bOnH>m8jik2dQBAI7i+;_7L^JZK&@t;^-rXKC|b5l1w7hi>|^DTTp1SqgR>SS
z2H0JKW1v-NJ-OZ17U9j)SsR#?V}|^AOKyO8i_BRUI4bm}SJaxYBQC@wmhDEdu3y-N
zj0nZlbo~91`y~NAb_X|BRB+)lI7ELyzJV$_v=I6+FxIlXv;^^CF>MeJje6X2;fcP0
z6VG{YBYp|dgLOg5zCyY)l6S3YE|0d{i*Y5;y}Nbv+d&QK&-6IGLwX%d&&XLzS<ZOh
z-Z#P+D)PFnu$_vm2AD26I}l`1OYCoqf~4KlJ*g++Dzha2Zo3Qt`TF_ViihO+L@UV;
z;_`SdErG0s_{z2;VUnBTMp^^-XlxC-s=dlB7hyDbZ5FW;Lmk}6n@B(5m)i63aTQ1C
zVLwg7-4(}lG!lCp)10>Btr0Vso<CtZ9Pp=74~|O#*R!isa!$l<@Q091ga+y=(l*3j
z^ti6Bljj=G)a#R*AYNe8Y}cI$BOAeKt@SzEE21JeZXH!lp?BPShREyN%>2j8yStTt
z)*xgIwN8xQ4ZM>E1G{B{dn-ROHZbx0T_hO>{lg#ENg$xF2oF1(pssto=@`^l*tY?(
z7hCagsi6wT+HU(sTr@#lZYFlAxxln)G4h&r5g9*vaArk#L}0?`H@B}(x;bdM_qjFN
zyvU9UUFu?~P~ovJVjr8=V=rMJMsY^H?;x~V>A<M2fTm3fKnetyCAN?5AVsyf$N2c`
z!diG)m02FLy~SylQ^rB$xj<!ZgS0Q3-&N*Vf_H3L->RRI<&-LU;S<_QaEg>lWaE`i
zTYF|a#=4^ZRBDZ+W<;`n0uT&9nxXypkfl^GjG1gEzakw+w#hcg-4vIgGvnPJys(it
zz$s<cNuDovM7G_M8?{xri1B=rln_ccwjNRo9rf7L7Gf|$)-`>^5|}JJb72cI;POPY
zK6ZB!{?z3?eeIWMNFlb3OrV^=GsyiHo~>fM=ZGgjipf8uUJ7UjhOWmNjNx=Zi{^oy
zgFB^=6y)#j=61e`vL`&HcHI0|%B*b8>BNg$v=^adCOnY-Y`}O~<it1!sjflCg&fm4
zM(QtXrX>SwZ0y%k@dIr!j>Y$kS|Et(GlYyOEz(|u-3Jim2x=<o4;^Touto{3X?CXn
z)E0e*1;}p#8cqM<(A8LJ=%#Fe98UTG(LVH5y!LyXGlydne-0UO`fhndFog!Ha~;t!
z-}OUNPY0vgK;m?^RTVTY1F8r8jU`4M3bP}<;TPlq%v+l`hHQ-5hT;TBYyH)m6GJ^%
zwBnSyK*ztU#3qv7^Bg{0()!hLt}H5O*nX`7^OCyXv$F`-55S**qc+{^ngijW&DJ0}
zL4Z0muT4X#fI2by_zFwx09&8KdC#(Tsh?u=qUG<~7e726vFxV>5mVS!4t#Ktae=>Y
zk92GvH}+*LsPjz$knP^BmTRK`eZxSfb^A|y2KNA?0kOozSEE-CtXrBs_2Y1qJ<@;h
ztHbBNv!-}C4EGhiA!GLvk4MUalXLP?@kJBEJ2z=6YvW!ln#BQ4-&&%6>)H#97aZRy
zSNQ3jtE3bHcrN6gc2Uojt(?3pf2yC-84D5&o2dU@5mgIY*@Rm=_490QpJqB|v!H0E
z7RQHdC#Oh07x4RzV_3fxI`3Gu`HpkU*o*L{Eu#p4LhZ9yBZWr#24wJ^{)rvSJ}c{8
z+jD%+C<}*{9ynOc3QkU*nj%e4_DDn5y_`3Ban8#*lUM~LmY<oomOG#w0q}?JN}F#d
zDk)=&29HWXL}q+`(bjuD7VErMk5d0=J9J=v;sX0!lp=tDluHLP{T`kbSbKv+^?fj1
z_fVxhDb!yk#;M^p)$tI1|H-=wODKmq+Z@2z%1YDHw+6)sAnU%1*n@_lZvcPGK&!MZ
z<iPxBHmDneTt04~c;9aJ>Oo}-VN8812ZvTfDOs#e{jOHmLi%uOQVF#QFW#w~s|+e8
zLU6`z6*cYXO;g_I1B^W=&nr3ZEjkz3?>z-*yyjT`J3Z~_ynBC84o>=>j4N^6q4f8m
zYvab=Tq~dvga=%%{!5%nPIhyzQj5^$F{o0SiZ?wl$4>pgoP&8^ZDA{s<5<Oj(lqFg
zL;dR=*g>hbPk`rzD^YT?pFx3<9soU*d*}Xk63RIWjWDZOq?VWSu8<}8!mZGCCx^qs
zjY{gsYegSW1ovkTMtI@D*s^|zT8-kKzwG}i!r+eMS9tGKoZ@u$j%B--R9XzIW-$b)
z*|+^ZV9lkG)G;(Kz1g++m*i#kI|1ZLxmY4+xjcK}+)J~9vjIL@Jg2RH<4>4*$)KHP
zKQ4^|n$#Tvumdw-CvSq*8jI)?iK$!nkEBI-TYM;y`R$$E?v^Yh1K%MTSA+ptal;+@
z^K>p@!4`kmRQFVzK>qb!r2`jkQYNNh)=b3O-!DDfDESUVG97-Jq_ax8IeS>|>N^!w
za$a%szH6<mURj`1X`&O~Tv-%(sm$5##JoE-$-y<)+#qm?gm2DE6KzYtt?Rn$4$29C
zK^aaar&n&w`Sk_VFng3z|6Srz!rOr*0D`_*P7$e94WaZcH3`)qkUZO&TSzt{THItn
z1P()_;xqOkS$u*9vUhAmU<ZqL$MHY}Adzm5<)3bb<4JbGcT?03w6z2*<k;~S_Uv01
zs0gQXp1&UtdrHznwh3^_-Yh}g7B`065JWisD6Tzas@@~2{P_>xUd<ikR6?UBYQyMR
z_;rLjZm8nda_07{aMwH5FWxl9@YZno#qXw@&Z|WIXwryTOj;oth_<#6;hGK-;RZ{n
zQCpusoh<h?i3`Oq^L6c}#ata>Y7xI@;oE5oitY?{e@#G&Tsytcju)ImPsD3Ap{^Vw
zgLC<>vGd6)@>58{cB*I>e=3y{EC7HW$|BM>F|MAPi0!Ue>Yn6y$2?xYgQUmftnp2M
zO+2#wxAF?{#>YKF&-0El;k)#>+kL;r?y+efKP9CXovij8o9g>hN$ZuTYl?h}MvR=m
z$1U2$r!FD3;4pp}nyzv^uZ1w&CdWQ-@N2T5ku2`|S$bU!E*?64idZtGR#YDlap&CR
z^lz>GWz|{NZk0dC9Pb<;^S~uJ9!T`4C+mu-S3&|8BKAMDRoU}#s(u&TZR2y#NL)3f
z4@&M5-YoIAQnCHLYh&iSckhn;khuBfqthFCJAa%GWy#fK2VNTY)KQm%`U%{n4?HhD
zgZZpFwwnA<hw)Si=Fsu5GhW7Ge4Jd1kC{XCaF5y9@99QBZm~|`#^_73!rT%W=%VSM
zP#!oh{?L`am29~Y_A>k!*D$UoH?D|wrrRhVt?DFc^B^_k`S*Gt^+8)g)ITOxnM!HH
zRX=w9jk!Z}&Sqq>+o?<kz3cYZ9kg>CHl7&QEq%(~nB0&NhO??%@!}7+1nZwoOUDaf
zEjTA9bFga&Ud>!0--{><N_O!&8}TY^9$WQwPuK8r{qD0<+WPLV%vN^?0DR(_&X8wg
zWz-eKFxTjP(sPV_&o{4+JwPr!4_?`@=<VS5=~O&49t8|hIPE3jN>~IX3Fc;Ul;rk;
zv}sEaK>)NgAo_)ukXQOK#>Ve@lGbI^FqetRmA7}Aj<og-dZ~$-w}uK>)g@)cp-H2*
z?I(7hp$s(6EeE~cov1Q@|3Y0|aJ7$tD$5uEs=J?s!a)5nVsGgDR=B!n3ZC%?=eyvw
zr(gHA)N7|6_WHS&Utd+{s@inUcucoE_K&O43v*5;RX?qJ;PApi;g^ms%#sB)Jhr}0
zU8I}3ZggWB$)!~{WrdBbKP<}Vu<n7lt~Yn@p8ECT1N*n}(YXE#B8nop4-34kMk+k>
zY~TS@3?qiLQ7hRV(o!UpkBP6qMpvm~>S!s_(|KG^bADs|l~9(r{Hp0gyC6PIg@By%
zNOE*CKhSP^74r4I@3twg&?&d~1)tw~EM@d(Q=C2>Fgoa(kJ5NFjF7phZ3JDJVqV{E
zOr!Z31&X)r&kQOWlm>JZMI4U{sX3iB(vkM-iKR=^0(R6}-FyEFDSw&;(0Efosaw#5
zSrS7<Ar3fuk&@j=I-ii>HBYqtDi^niq$6fWn}YiM_MCMc@5HnQ6Ahvd?+=Oj^n2uF
zb7av_xwxk+%xitSu}`VFJH73|pnJ$mx}pL5^qH)A#|ncti-uwoL$~58IPOtOB!m;9
zut(eO+&!YK3}_dMK)dDI9MG`zS6On$fDNc@dMgUit>{zS8tW}$7S|`q*xE#ZTej!b
zcMa)-Il3<&oQ$IfE<zX%YIduh@UqWY5nG*GPltqDGcvQ;&Tn;p)JoqB7gLhqGM`Zs
z5Oe4%vcR{qFtUj?x>MZBV>H2+b+D}<V(`Ph_OGX^(P`VCg$UQ=+1eoHdAlr|@9c!s
zw|eagEUGKd+4_iaUCZAF$3IQIcSbWq{K`ux`;OcKYeFY!NtVh@@I};&DI%njtQiM(
zMxDFr>D!%?5vgSd<r0&2SFZ5wTmO>Q5cDiK-|uJq>2tZI%mm#wBO~J$y(PmX&F>!M
zlym{FvBa}$=t3*KGcus1xw0h6<Uz$S!}fAIy0`#L-yosS0v7;v8|ZA`JP1q~Y4?Ns
z1=p@!dk|~*RsPn8ON+j)`POeHOAt1yEfz|C=?tN$kw^$#KuNNc#O7x!+jUrn@|TQ8
z9%v2mhC++Ax4(ENaoBkIkG?)n&($kq!Y2T_D?EW_E)Gkwwij?#B3UdQllBLp9Cae>
z*<R(yck&Z81)2qfxwjdI8o3^<*s?KbW}1<)?U>`++lAA|6YuU=J8HJN=hXWn<DFzq
z>TML(<2)m4KY0CLHhZGk*zOz?hVYf_s2zjW7JPUGvU`|6U2oY}aNF}(k0OmPaH_oC
z;TurZpY`l2|9CU@hNf*@Q1#&_8!A^Kt>S<ybNL#H2^*Dg<;L$FzEM)L*qB{4C+)n_
zv*z$n_eWI~t$_h%OV;G{y>EKg_r8U{b>7c!diHIKIr&sK<owr`{i@g2%=6jyQ~?o$
z5V9`n6_2Bi)bq?^Tlv@~%o<{bYp2;gU)NfK%DJg~x26~Dd98wPSibH0<?rghDYRH%
zisX9=H$D1hyO=}};MO3qEarNqSU<tUeGDCmvpaCG<M(z=eCg|>JD*(de$ln|zO%u`
zw3gpnj#;;qT6+pGszl+jN--v3YE7v2-tiNrsVmpVtd2ffQeu?Xu>Jb0<i{R02|Ckh
zyHyN)F<TtdJmHdZ5LeTFRncFJ4+5}P?-}Ukg!2kKVIl@pUk2LR8cyv2mw1-ig4&V0
zj?y~wf%SE2ZF=T08e=Ll6s?j*4`CNDb%(LaOk>g(gjTS_n1-%JChBa>%S(-QJ%+5e
z(OwU~tL<N3Zco0BKQkV4c+&|B6>1L~*~}Sn=5xAP4L^g7#ZKr%isiJRs2-czZ5vM`
zKCdS)+cSk*i(s4FPse%R9+q@^t&Fj6dvK%EiQxq8ZRP#eF^OIA;ND6!(=<G!`3PZP
zxVncM50v2d<mSw4WA{WR{P7gB7Q6VYWdSWd^xl<_05|^X%bq^<(+dQ4?Qf&cm%krg
zrS^RB^`qIl%#7Va@M978iiRtty&-3DG<N56@f%sZ<N(Oo?I(pJwKNVwlO(<*Imy07
z*-T7ps1d}+0yirm!kxIwh29b(^DQ_-vdASCYI$T8{}HWM*=}a#5%5)AlU1pnTv|F*
z;lzGtpHjwIGT66GeC{fjx}uj@UuQ|ULNBqZL%*qhrB%-$ZxT)A6om!kAu&;N#-|KS
zT|2(H9ecp?7=xkKmC(@_zVA*=<NyoXLy$aD<WCMx;!|L4d8D9Z!J4#CQTy0^piUP*
z3s#T2Rr#B!DPdLCZBH+c#|s#hPaa+8FW6ZBwY-Pv@fZH&X8K+=;koO*VN9^UHIDb%
z&<FY_qLe}FFQ^@&%y!kYlBsdvpB6u=)v1C82?BZbvL8>)UCoACGGm3OK+HrK=%4E!
zSdV?b6^TUaBka+ey7%{{ttnt+8eZ9WrZ8sDyUU04yev-qBz~H_Y?toE-y>pE&u=As
zBvhB#$+n=a-IN*%24vJr3K~1(LosXI2dA0JNI|ZzG;}(Nyb^it(0>2iIWuj`KIzs>
z%4L#oft!AORbYPLM1E<kU56=B)E1Hzxu!Zx(uXKy=A=X7Bk5vgZV$q0fHceitDgtr
z%Aalsh^!aXWrCYg*kanO>>|F9&U<1udc+Cm+CHfju&dr&(}tcMA79qH#QCd+zTxFN
z!>~MO<c1*krvI+FMRLcG*q2xP8mR1?8~SSi*ro1;n5|gALYJ6Q&>i=qF3DKqkUW9*
ziP|oZbn;K7t2r#R<_J}KzQgdT#~2mB@4Bzi?g`xstBHYhe@4}l_bsZr8=dbqt~q~|
zrM`uwer8SY@3)mavwMvHU~Rrg#C4WK4QP~**!aC>ez!XvHS~=P>1m$|xWTx<0YEU3
zt%O#<8N!Sj2x#+!RFM+_(Hn>^Gg*UpyNW3n<#w{LW5j`4sq2-pq(7C^iQ7%o<?aXp
z;#q)-mdtU8j#nv4xPO)wNU}11<nLF}c#ZzH<NEaSok2$ADrA7quEiyB7-902P)*-z
zWJ=_DQc-|AfseJFhu8_4{rS|``?eZHm?hPyqh5@46Sc_qr60+td+6^NRW#fY+!%IO
z+0)gj<C}ACp-ZfOvw#2WBdz^>=a&!;asl*S`4i5>>Fc9Krz)v95cI_#nbO!@*&}+#
zAmE<6`arL34k36JEZW_S<&hJ_j=UdmssJkh#K_@8sq!eUiZ>q@7eZY*j4l;p<En5x
z1-5~(tgLc$w}I`3q3O&r;DRK`zYff9FyFSJYKsQ01eD8HBmO*n`KsGc4}*^xHIm^F
z49~m{w~X|y7~f!m;mF-ZqZup}OTm7{Rnj(I5_XO+yzs&A#Cr|hG|JWc<EFv6?w-Du
z@t5iTY~912<fe%|*r&cOFO*m7WM|@`9k~7Z!DDb4dsG8twH_gze3*h$Unf#9lH~+%
z?kMhXe4RA3<3?`2&JvM*eASXXEk~_t$3r;=*xjPHv3;d|PdCB-SywtX_a9xQ-4ii5
zj#LNG?#<-)(3`SpLM<@uiAi~={cpr25;uV8@`aPAb01i*1l8NcFrC6;uR>g%kRTqc
zIaEPw#9d<QFn|kGf)w#hqAz{>oENy%w{LAFQ@kMd&YNDxRi$}nq;ZX9ej65Y+*CzE
z2^T24yQlFRS|tt&>hXz9-Dmqn)A2ZOT9<C!*&U1DZC=-E9hi?e>t0pgv%6a06L@pa
zNm^5-|Gj$#E$@DR7wLGV{>qq9VcMdX4qA=t98QFWVzjEx%_Y4m&0BH5>#VEmh1-G=
zhWV;@?=<L7-fz0D8{}`W$v<4qAZ%Z>clXK5POqLE>brkvi_t&}hcXq|xCJ6mX&Hhi
zGDn#@+8$xv!0z#oC=|J<IZ;^0oc{#rlIfvcdAp%C#Ct!8(3_#0)n~2;Ay^(QKF}<y
z*;2*cnei~Svp#3#%d^Ru*G5Y&t?F2nz9(*1u84LC^ck2S`b8tVL=ca|Vqc^#Ms>;0
z`t%gJWthaiuMnQtr=GB|Y)Eb;#__dbiYYExN3&Y&*<MXc{3ameUB*6fqVF~@;q{F2
zAVr3~<B=<lNCpbAO`(syeb)Vq0jTzY0tOu5qc%pZ=we9bCl7m~up^yO6hS_??(rt9
z2w(-f@^~y3Mv3U{j=Tb!uua6S1y3HWknalMn#>~sHnx%K3onVBJz{LC8P7j|u)eW{
zP=zk2Y%h4&N-r+!3Gc5`edDo{um#}J=0HA_cvy$DQsgg*Q9QO)CBMqi6H!Kr#T0iW
zSd`TOYtXYbB)gDc*<Jz?yDy^#niC4AM3^)<RN?q0OOTv3p&+gr-!Ez*5_VLG)sOV8
zY13~vIhFB3jxo$Zt6}LB21JF{K>4$*UtUXhU}jFe@_0YPxkF&W4@zJdfBkycS(HjP
zmOCL1JWdxyVt_#RN%o3(Yb&ubZ(6P{tMM`eb-M|Pv-n)BuSf=9E0<m*@SgOGjbyz@
z)<H{2_9>rv`i)dI(|eWh+^*pth)2d7R`^SeANUWzso2%%^5IMk`C1#Dt6~DLBhRD>
zmjste@<cH<IF{F{%5;9=jeN9=f$Dacpqd5cG(+MT%TY9;66sPQs%a}3Dcht;fAeUF
zHL5St{5iQ;2NnR%cxj8Xqfh4)9!?i_MgcJLHFya`xS`NSpThK_8cZ~28O)83m~Ox(
z<Y-(riDLq+NlYpd#=jr2|4E^cY=#&V%1^b0fC2zftEq2;=mj+_@;>7J#~a~eBz^Cb
zcGHKMm*agO47(c@j6AZ=Yam(i2n)zH)JO4hb;CN`3J{ahF5*^`Tx3Vj5Ehfy$kjwX
zHRDOl)yO0Lgi&jA!KhE8CZowj!-II@og6XT^J?;SJ#qxU;*I+-qvCBxZoxC}wc`9{
z<mgUp(Zr8KD0|pK-xL5&L2FlVvsJi6zOh@*;Z*(zA=vYTG+9sk8??xJFIj~MjQ^iX
zs@4IrL*!TRBU%&fas)KO4)PXJC7p<?z$!3?BRZfG*d+C-PqM<#Cv6o2Fu`K^jt;ZH
zHU64WznjF;sY?)Hz4TI8j!xObPP3G#l>?=*6VD|#Tjlz)ooFpb<k)OqLs(5-($h=&
zMg*#?WF-<_)R{=uN4)EEwu&^8<v!xDgVitT@CxE?bR1o=1Oj_-%A@&#A9*Xi^+8CK
z`R-j&q3d=Z#-;S1JU;m%D80=mhY1>xov-QI-dMX-%Cw5`9?I#@RFAY8E_sZenHJIt
zD@Z$|Kwu8=fw-LV76ty*cvptx!b>%QG7CR%kW)^n$HrpI*tItJ-4%)(=q8XASZS)5
z%e8OBs15dgUC~nI$J9~W`s#J}nXnau2R-}<Dxvw2hWHhp4rckKwQA$ok}#NVUS|>m
z(ufrK3JBDQ=vWrO1FQzyNxiJ8JgUzP>@gG!)HO%iA#nvmI?BkSeB>T)pjO+YiLjhx
z=wm~nRP7Q~{vf_U59Vt<*Gj4!#W*>Pj<0J!SD5%7ddt2F$`K!Pq7Fjfj&*?+dSPtF
zQ%)45A39Agt{hsopA*mR86TJqFK73JiU_grap<+b1QlVEpfe^Q2;|cmFx_?dXq<|z
zGQdedje(0vhcXU}Oh9?N4-qzU)a6HVRNGAAV@$1jSNz_=ss|ByPS24ioyG-aS^GoF
zuL;Ml$Q?wB|5QR3C*(u5C-N0V<au_o?L~2>aFP^`0Vesft|Ip=bK?+PN)#=H=jI|C
zJ5vN6v{h_@qu#fkc7^4aP|X`tXQpl#9oKja8ODJ(>!cR|PWj2ZEbv$iXuV|T;^NyT
zI!%kMY>wPxmy8!s-%rb&0cFyDP8@STeo9V%#gX)ZLY}MSPbEbh&f8=T(O%G5gN>sC
zhxHUko80D(Yve2<okvP|gi9|?Vr<PxZn69qNn-OlbLO{g0qey_qJgrZ`?=d+DN|@h
z_C~yTXLZ=}bW;p}U??yZ)*-JwCieyRIvuLrW2+(bEkRs)1ND^4&_l*Ztl)C=Sv@hK
z38y93X#q9v9^iiTS1foNXuVRzu7g%sAI@iM-~Y-<zrkzmlf{&c$#8S(!V!CJlmd|K
z=x6@&=2#Ztp`uVQLWa7T&juVN1bR5xwc8GCt|9w995!%v!WvEw_cFNa(W~f0{VNB{
z{P$OcMZ^KvVAKlth%WPibKPhW$nd0q8{`P4`90bTa7T1Vo4CsfiRH7qmq<=^R2gxd
z>>D+;sVO9<{4*`Yi^5DeUTzW$t)iFscH^>C+i8<Rtt1c3R$O_r>Z#KT7qLbYrK`1x
zAaV)piID_$yKrfjtLBSc(M67T<*K5A#^;<XIcs5&5)#d)#t`OLX|GBNC^?gP{Z>T>
zJ>M^Z6l${U4DOtGqho=;Dyz_}G3AY;{O-s{O8BofPvHn?InLcCv(qhPl+y`McHDL+
zV`J0D2WI?3deAHKB{JOWGw>t(Xpp4q#A%^RNQaP7nHRYary>vLl_+z48nKJy$6ng5
zByD&_!UW_Iiv-FERd&3r;<A)gW5T^LpaWL6>fI>qT-Ey1nKysB|H$vcRnjgohp#ar
zmU)8ca?fRo0J<^_DdSF7Z#(jesRYWV<*`LOOWaA;h=HiJUPEUd;&IP?=pHuB)aZz8
zZ!5^T+S@^oJp3~y`Eh;Uj?N_bhlYAv9_s=)-k{Y#WvnW72((mA;s2D@Alwk2(q}%0
zd8X?X!*KhLi}5?4j62}zPU^80-q-F`M+MNk@wDl~jIiqQ$ap!XejqAB*cqUzSSSze
zAi0PDTCQ4VN77b2hR+5@Q|YdWbgUX_9{#oCP9#c9tH)_q{m7*vyX9^~+YQ8l{o)0g
znW?3sX&zcCYKM4h%UeQ+0y3P_)L-5&F)e=O1r0nqs#6^teKEYB;-Y9p!;KcQidn;v
zGTGct_~6c>yK&071F@;uQS6Dah?{9?boppY58)KKB20J>BLtzKN#moofBH4mZ>il3
zPKEn3kMBv|zjMTLA}2qBN_fjwm!2?w(+{33>zB$fY}x|q4&}d#H;(O(Zl(n%hoPr`
zwHQLfbvpq!fz2O@*<qM{!84P%7Z*3)PTV}_Rr<|Ycs2BVKhRNtY2GjK+u)o&I61Zx
zHy|!P1F9(JHwSdFS2y9F0X<RHTF&WEjQ1+I+Y_%|)>tdr@q&ojcHw%Ji-P;|N^Xx;
z8}-O~vqs7yW}t7sp29i<qEH8ywk2&*pp#b*zbi2k)a7V6W10EAhx0e<ML@G;om2S*
z2RyzT6;82oLHFmx(K0$`KZtm_d*cn$K`rfZko*@&`rffvJ>VF2;yINNB$b{lS-1Gn
zhZ>Z#z1L09)&Lrc6w7w#QN|b@)P2dzwXB0Vz~)dvPIBeetI<yfagtk8wwzyw!@q44
zPTRkPM)xYYZ@ztT<1C-&;<UVv-!3i&|1|scpZ|PVUpKui0wkArf?o2-(5AgEKdU_*
zT*&6K#|P~P-n_fGX;zftsX$O^JJ{y@@%zi!THE|YFq}3P6e)0%EroZyWt;&t^H3Y0
z*ad|>#j8oI?BMmQ<UznqTI{%EzPj^=FE#sVh&`QO<l+s8^<^zCca(~CH;z5iFWg2I
zgJNM`@qv}SIS7jf=1z@JiUPm2f;H_S#24Dn{+TCLSOF5Ap0=;3*dw5r+V(ps%44?X
zcI2GnHJUIIR4!v@qK(v@-J&-_EacF&wX=Wz0;aUdejjB5X-yTjLqmtH0pNr76A%*P
zt39BkE-L=|yAR(CJdG=%`T%$eKCt-kux%dbu1-t47C`~A^~?PGZzdnhq+@c0t)#;9
z(xfwZm*`U=b6?R<Y&>YM!r&#ri0sgwxoSD}j82_+`E>D)?r(AIZ=#|AwhZ)+&Th*$
zu6N{`VtY!Ji5OEqD&oI06EB0q19*BZ;7KXE6Q*&M*M`b?$0s6MLYda!gOG7mVx;Fb
zd;j9W%<PipYi~}4?HtH=!5BY~@d%Vnh?`iq7PrDE#74itHD{q%=NdoT%C3{#t4N8u
zdxqfv6%-a$gtljoTn{4b3=Fc~-g%+*k1Ibq-f>IjYP$9i@JA|{oc4Cby(VZ5>9AN?
zpxiVF`+y=|=8FO@sE^r+$#J<VTU~!^=~$v2e4xC=+Uk~HMEm<@z6x}h&XBoYmTP&3
z-y`-MZ2i3;`+AXH)pWo)a3b7A`XlrplS^e2JWr?rT4fy|dM-Hf@W&j?YQmZAIjcqI
zs=2iJPNCm9!po2o=v!;QzV)Kfv~I?gsQ}GByt>03kD&;gI9dwH4yhH4Cz?w%boATv
zlAJ(G1<|!GQ{`Gwe3b@Q=2qmNU}UY&bJDSL!tQc=yCG6o>G9)Tzs_8`&3ROI<T`&w
z2CJeieKultU5X1Yo>EeVTa6FrW0aB0oqS_jQM!1$0ZF?M$=d@GHy({Y@5vyWw4P|S
zcD>uxW1h6T_}<X<QD5(TKS`$3!`8LNORkSr66_+4OE{1bqkEJ<pu+44a04=w)$0Td
z+^@5}N~`n>?Y-V*?XVaRWO76yGeyGlK~LEafot`l-{<d3vGc|-Jl}R3aU5`RU*mBS
z3CqSuOGrC!Ii64PEp{u+yX7z4o)=(Cr4b1Y(jQ(t^taU#>tt9<z37GeYmT`cb9n2h
z(z5F(sz<X}8C_J&Z{ArI#K&CZlu@G1X8NOc9YUN%EI#ex0J1Bzxbm54M}-c|A79|7
zV=kh`kLw$sXlbV>Wp8S4ymtB4tNK7aa(F7xTC)jRkY1t$fBjWuDQC4Dhn*PT0pesx
z7%&3u2F%{JDx?L#IVdH~ZJoqpUQ@efi@}eF#QM=ybAjVfOWuHAjqD-fn--gmFGaE%
znA)AIv?KhJQqC><M(!i9^37|LyWQOtzU@s?bdm3M4hWRjk{8IG6gQcANIcKJk%Dmq
zUX=RaikL&&@C8E4L+|%j1YVI_+_}<XM5vcG{8ZL`A#b5p%yZwcmE{G2k!L7~s<@Ny
zGr|#D)pJ(asv|K0OB$r}8q@<Od^N|?x6LUg1~+5|-dJnd6n(GmwwA&+IC;kW`s3Q-
z?ykO~TWAMFr-C)~VELB_YRpabxkC)ib8)^rXc;lAemmoOg>rlq&NuSTu)(R56>(?*
z6l~LxTg)MFIGnyWo^Ou5S&7lk-`?>%#xb1pHUOt>G7&|&@kzlIKT>ce6hj7Wnzee`
zmcS4VLGnb%yttjHhS~=%{8Q<5Ggz#`+O2ciP39oCR%A@kMNlKueO11JWGG6UXfQ|D
z60S%a>5Tf<q0K~Jktbo;c5QXwBO>cqD#w9Q{>n7#j+tFT!Eb3j-~R?jM#iBkWzS{V
z`p%Eqzv((Mj<2FK>0v1+?S3o!&GCv`9_fDK#*`(xr29_}e!Iw)A<hB-O18|7SU%81
zT|-`n#5PG=%c$O(1p*cQ-HdBpIjs6j6-Ig<5{!R(@SBiGLyz;^r-Sb^uEtPCwdx2<
z(K+((6q)FE9CCBZnOI&?1Ec~X^Jw2d9#++!hAh+eKZy8;7x|q>%yOSpF<ynp2Fval
zj8)nAhMb+0wf*98)OUFNBrdLWI<uO^?Htt?!`vlA5CKz{o6(jHd41Co3bdk^rdrbY
zB80NPy{sqYYjG%bDJNkv>G`8mK^u=m<hiG~;*H+<PCwk6%f5X2;wM}A!D8;f;@ak|
zWhm2f(a9VDL75N|gbIlvZe|h`TWg3gl4#oq6rSyM4ua7DVXEifoq;}|`fX>FoKqK0
z0U!lvdBMIN3`XHUl}?lb`{WoXR|cuiD|sVFpot++le;K}#OjgI7}U>E-1*oPjN<m)
z@?JA8b@5k3qn~|{{cC{S7-;DM7zREFp*Dk{;|-v<fMo|hcInE=UvF4;R5B$G5>h7s
zoO(f2A{&h|f<-ze=myFoH}Gmg0Rx>2BEkme(Z3oX|7vYU5NE;&_6y6jXMhLXoj|hl
zQ>(V%^`Yb3;H$#c0XB3>VbT8%Hz5a<2NQry4XyjXtk*`p?#VOuk3BD+M)@l)GyiW(
zCT^yI?)jBexzq#VS`*}U*v|zGgcS^UM*)&`*T-Idao@V1?SE64%fS1@6Ra(&G4@3>
zQ#8q@|I-++^VjLXopOK0e;kGX=MF`ifYfMYWF$$9q|FTvwRyfvwPl~P>4cL(>efRm
zu6X#ZnDh0bbvi2hh`O>qeR&yGM3XG|?^DZlWpu&!tD(w)nG2sf#90G6%2Q(8+kB9}
zo{>&CFlsnc+sN+rpq5G)!F*wV9XcwI(7_pM=-Yl+xuWf_BefmTLJI?*1Fwhg8^nbO
zYN$IN21N7#jEEai`NDV~xXSE$W^1GDkIn0>mqjra>#O#MuU_2}Md%rlx@_T6J`4y@
zv&vsOth20Vb3R=z1QFCI%!$-Ll?-fA!1pHH_g=0d<WuBe#fNDU)&DN7ybnxeb3dH}
zVGs95P9x#^RTMkWmrT@<^%=;^C_vuo|LX`t2HagaB$sp!s;9&JbrKlzJAaTDteL4g
zxI-J_<A?kDK5+Lz4?F+k;{N*s{-YU~qGP>8F|Llf+am{8iq><f>VPspw>+wvJ<tcg
z4*N`Rd?vAvENg!q0wRm+^;4gLwFt*|ZZ#SmVgNmsd5$x88Tz$=X__1n+Jlm-I%TSg
z&ou<}w}OBGO7SC?+$XJMMHHDh^%;Qo0PJA~XjX2uhUZ9;dteu^?f!}cW<5xl*j|7U
z3<jt~``2foffpcLnFA~pP*gbtihNF_c`w<P(AoPAN`*7H=bHJ{=X+*fsi(R-<$xoL
zM-N&EM{~NsODKd97l{^jW`aJeZy}&>KOg)91E2C=?;HCdL%)dhEo=>@1$)>7$*m-K
z4q(7&B+TrY1|9q?Qm0HK>M{!@jY1+FEYO1wUjsduO+)9_13l<+*u5M4^blk+<PmaT
zXZA7V4Dd`hRgn7@Q7a|hd*6bqOMfmhpRNMI+b<M!6a2b<WIJwRz#r&t;JS#_|2=kQ
ziCzmz>jV%3s?)jHE~ZfY9%YVilLyP;xwCTuh0OUn=)Dgw=akl<%vovTz}a7|`0o>x
zyy$p~AMb=r0R7O9Bb-oV1|o#rKrMQ#F+x67o(EbFwf^}l^oa7g=w&Jt`3zVh*BU3c
z!<V7MGR~AD40BpWV*wJpDz^BADuV57)D<eOvipms3cy_g#}9g|3(Cke$+w^VI`+p$
zU}aVWxpF+PVFe$!2<QAWB}*MbbR?Vz8R>F*X6dH%ejv{q>-!pqY}SEC0Pe%;9sIiT
zzYFgZPvF0%*0PAZh0}<;(t?>-JIflyTwsGqq`dUSaskl=^oa0<mHu_B{@Kv`x+05l
z{?#e;>9j<@JX|ss{u8C9x~EaUN7G*BDVn7SET&2Hzp&uH)W_f3dZ7+cB`P=KX7-@B
zGj!&o)3a-r8!E1#pP$#y=lS6>C`ke<z@zK5%0ED(I1d}GARV-YyVjz6A@_))Xk{0E
zIx8seYTM)tnR?k@5&!@213p|Y*#{~i)S4*TJV<hx@zp^&1Nuyd10SRowJk-rjWR~v
zr&tJ#oz}k<(0>@r&vfKFRb;tOFjCZm?ZT#>hX?wyD{G)Wv9sKiGHj@b`{J|=?k3&$
z0OU+1oY~jxKk*KU-}Q36!o|C-g7PC6UYN6Fy(cz}__^jAks=+=YxIGoH+Wf&S^_;}
ze?euM9X7iCr;^A7KQ>j)q&@tkpltRs=N;G)s6GLXGPv2Zdga*vsMUKM+2fOdnS7R{
z4kSu2h(02jFWT|~lepjVPo<|=X(HH^&Rj8Wf3PBbIO@@mG<f=+;*#x`T$Qh*K0LHH
zS336B(#5P8Ts0qh?f{Z3N}`>piJAmEv1sZ?MXQ3-7HUD0Ec;)#MREwFn(zs!L8+$c
z@(wCx9ux`Idp#XpiPmsF_kTV!7@sM0+;<}T=_>q;FOGL`cg{jtPZfT$DP6d361X)N
znO|DkM}4mJ$wRmp#HEZAsqb5$y5xVnmMQdqT+I7<KZq=Pe?#)hx0>cojW+L9j%LlN
z0?CnIa=IkbII0UlIQj)I!~T;on2_VR)PA*pM4|qcFfS*Ve}2vyKn7udZ{Q99$DiM0
zhBB%DtAM_rLt18uRioT$0q@{In#caNxUv6rajO5?bKvZJk`vrn`PshwcSHWvUS}aX
zod8~G(wA@k*H{4mJ^r~v|Cx+FQL27o5BXDR{Y9qoF)l*Qf!{A0odW(&#y`UvD#HH{
zyM6h4WSs~DCiFgid>Ge-8@T_Jx$wYFTYVv5B?R8;6!(7>&H8^W=ij1<{9i?LL#>AE
z6P9Q(7mc=k09B$-$0BlyGRfAeit$+|6>*gcKNIZd^7>@GK3?}3bwMq*@1xfo=dfC2
z&z>Ms83Fo0nTLE?IDkKwq`>_}K?Pk+{rlsc|2c~*(I;QJmQNHAP-Z43jnkjpx2G+p
zBKy8xJ_&lGZ*vk0N-8+_&vq>6|1l|$kg2J*u7Wk*{Cxy;Z~lFLi@rwI4N%qAdebDX
zL(y`fBFOfO*WHB?HVhb7k@bItx7cWIZcQMl55G11;F-3yK#gjOSz4pFhCpOLk-s#Y
zL2xzXWI5d_9V`25xpJsZJ;FQz-zqbdV`j#8Td!1%uRz^h!4`7=`xd$+KXExyEmx4L
zaoR^e83B7l<T_pDIO9v;?Y9#->+3fZ%|&wweXOFQ8MYb9_|i5gKE90lx5PFcXD*(r
zgk)f+7f;#Vl2Tt}=qv_z5i*)x<GC-3?30oIzz`_ED(2G0i5c%(;JW+XwS+#g$=d=b
z4l0TNf{pvjf%!-z2c?n!mdU}ph(W43@fWhDtIUft0#I=%@RPrw)Pjc?FHjix-G31d
zrQM~){GwXfP^90w7ucc;e-G^{ZTs)yKD51We719l_U$Ldf9;=T6*+TD^4^I}cJ_b)
z3v=4hGTav?6#Fp(drx4+z}0-h^Vvyk;le;fAe!(J{03f7m`F#<uwNKL`6Jm_e*;w%
zXFS442yepmt4Bo5*OF_zMrMa0@CZVy&vfGF8+PdCkzv_68KIzJhBHt=`52%+yTphE
zCYn$$GvUagjDkI}wWq=ZS5N`sEMn)-h?O+rB<P;`QZ#2~T22uN-zt0`ME`YJwh8{;
z^3{JIPJ(dD7bb_#mY|>pEBr(ci8=*Q=92)idqU&|aE9{#B{o2;h51~seKu^;r(8`x
zhcX}d2=Mi5=*o@$+_Xjd4NsIQGxH_-J#PS@PvQN!aQ-8WVepr<$NwHh{a@$!{(t=V
z=6_p&zoPaT8*r<y&r~_Kw(dp2`(vN2;pmsvFz5STmnkoQw)9n)&kXJ#VSZf{)AL>6
z3UMmjMUVrZ%9f7O{^K4Lth(S`Q1Vc^Qv<}Lpp$H_bGZaO8DZ-ve$~s7=WgM0#)*{o
zEdV^3Of;AE>B`GsV8J3~dPQ<6NE~slz(}U;GhZ+^$ox(7P0&p-Esg;;fK}!Rdf-=4
z;B=M!j4#C7ZLOskS4G_kKwniW(pu3dkl7n=AjqAtCjsP->H*2bU<PVCmzfJ+8C6=?
z0<L@Z`%A1?sG5&^?g&ml-8+aYGkosYh+qEV>{!6q4<?EmZ+}0Y)vWsT`<olHRvzVM
z-zRQ74Y#vKu7jS&z(1A98$e)v=Chg3|NF$5>;$DW7r^<OiVvkt{rcHYeZHQHpYC#|
z2B7&>EZ&;~ckKGYM|{eiybrwn<)2${>-rd|+M2(Uq3(lF`u)F}QK0+wT}Gg2$3f+G
zz(;>2am3F|G5%D7RUxsdhT_wUA)ta;y<h2=0QRb8f_Ha2r8Qp=>JDuGpGtPnedYf?
z@Er8ORYixiRjBa#eD##a?jVwc6-W|@c0p&SGr<@D;hx}5V7f{h%b9Z&d7#O^E0}AN
zGG6A0Q*$Gl2<%5y05~r`3B1$?MHUZr=xm^i22!nkZw+^9>P?}PyRW;3#qPG$;K(As
z3qK#LZp`l9tlSpj%CZcTtLsbFidV&ngpIaJiaTUAl9!0ph^6RgDt?t~^C=fmeFh@t
z-C$Z1Y4s7b#7S&CbAwp9Hb~H`U&F|-)oC%NXH|Q%G%__Vmu0OneG*#j_jI^>-4lt)
zWkMOIc04&}E5ZRu2_7R^qk;U5B3mAHN>nM>^s^~e-B-UBwFV@Lmr3D1xlxs#uS}b9
z4Yq-CRUWteScgRPKHBX@$yDn=o68Xf^KtUruFbcZ&Nv2U<PL`(fi`T%uFUO(e2F2%
z(B5EPMqHJ)7}MxoYZ=-ZXNJ}EE#ilz0Bov_M-5?dU?_X3Z>c|7yM?Ta6xC<KSI!o-
zXw^$JT7;TQ!`5M4LA6)O`55SS0;pfy9K_#UoRLa$28p5th+}>EHou(pV%Nl}l5O><
z=F76@KdCh3mH1~?_vU039Ig5GbQQDWa^Je0X$LH<O=>~W37&&H17Z4zr4lmIE6NbW
z$4$xv1;c>$0Vg&D3}V(e@8bLZ>%qGR)cL}ScT|6puHpL9%(v&}oqgc_b=bGcCC+w4
zN($sl1E9wu(3LM=k5FVkkW@vOMx18W7B2g;tr=ickb#`Gs<nII*vYboIvS!Qm3%AA
za^XAauz}IprfWr>T3NrOEnJ$eTdX7*-V7Wz_8agh$Nps>`Y=DV-p;n){{O%Jf6Ksd
z<{>g9{t6!tiwJPC`6F^8tbsclZUXXFzY<D4A0xp$og|s{FkrJfV$vNb$-GKWIZlc~
zo{N&~%OADRS@rYw*y7>L{EX%Ep0wtb5$Kd5Tc*iN_#}3OfNTzIp!L+qe~|4FPmh#<
z1n+5lTx^|}LyH!V-H1=bsp3<$ng$vspfeB3;pH!qt+!emo(_4}x}cC`7h$q2d!ceI
zj?Nf8EQYw#7a?wj&IV+gh}y_`<cPLHqQlr|Z0P_CbBVBAK3`@{Aoj_4m_%z0+4pcl
zi066C91s|-CauhW#_zJlA}$S@gao;YV7{21le8@RM+ImUbSgO$`<Bzy$}<^#B6gLu
zf=Vg3QD#DZt)rp19->f_G>ZZ{QZ_57B&;~T!FKEHYs`Q$V|rbgxS7+SeZ*5^58~$k
zV*pR+TSi$hSP|Bsy??^Fb9}uRrOdy4!v{Bl8!eTsru1x>mTapGOt9zi$<F{&H=_>I
zvxu*Q0a(}KDl&B`X}#E`ZdAn6vo#QLMd|(mzIjhZ(*hfkuaBe5KvaTM%l2V6gHnC%
zHrN-QPx?_ow>2gIK@d6Pmy?t`p|b!)*}+k@_P*7JzR;P2<nc`A4OT#P*vrt;vS@CU
zRRg;9QS~FFxR4P`?{#D9JuhZlnsQX}sn=XqEebn8tu2pGAj+?(B1cS*7D#9?I3tT>
zIC5K`wJ0>>B6B@a;2`#iXKq4v?Q_d}H5r(QT?(p?r948zp2^L|p-!iVJL{*(Mj|iT
z9b!bw^x-y>(GaU_OE6>SimFupTVQAbTpyz;2f5rBGI0W3woOq=-au}_ssY^ke8mlG
z$P6Hu{#0tx`AU&ph4mGevMTfepNxJZ7DMtBVAbT?5EC9~+^{Uq%veQLF`9(uKF^g~
zJQh{A1ARuv&GGBo5^naRVlBCm^B7l$e{Ci4Kx|}sBn$;q-{L|=k@abVnKsi2CPp;5
zBW>9I`lDhZrP1~qvEJKjsW-fBVF5<nUz43cFK;aqs%!~$+COUAyS=5xqpOIW0|Ks?
zb0n)&A-Xs`pX4TXAvq(UxHaEU+}wGE6wU=S4}EGGwO*=iun+u|d`XA3t`FZMP)(@e
zK9(Em!!x9+zD6oqp4T%X4v*#e2AnEbQvJ2fY3^LW1t|w@3^CWpjeVMm6r3NRdy)Jq
z!i=hNvE6C{ctk96m1HP#OgYgyivX6N5~E6Pb?=S8L^9*EyBK`z<?+*Ev@$?MVMPqY
zn@0KDA=P(?!{dC7*s;(OKen@|kREs{(5qOsnRGw_?EM)|j|^Qrmsb)g$!@7Kl9`d8
z;^<Jk^&%cNPSd=W5U<g<UECMV$97fnGLp_!sq%3N84_D^Jl6@+V7nosp(3gSG!l^x
zwue4fxZs%x#fSUcNTc58mMBBMLcs5!6{F2w%N2KU=U^@L6@dFNM&bpWujF{ZW*Q;n
za-zvPNM!@l8gW+hkgw_l+aH*$xvKOoLGGK*b2BLMJwje9V$?g~8gjOjzN$JbUeMEE
z9szX~N~a|!6<4z)K}f6YCz4m-l_Y_x>^O<|lDu6%KBG>*et_3K$XRHMm2a`th&qbo
z0Yi7G_CZ#y(}R?=zI{5&AKb3MORP&yhB{tc)*~rUWH438?c}e(sk>}zO8VxN?KWSI
ziX1#*dqRY(C#)t?8zMC7;T0rj(YXv73oxi&DcAg-<4ZOa-4E-&=Mb9v|F!q#(NO>Y
z|98E$OOsv1R7m!+q$2ZHNeCf(OeM>hm?R9w%)7<Dg;2Ihk|d37$U51}nteBmB+D>E
zGhWQn@Adv(*XMh#>yPXF&biKYo%8*}A9G$g)j7P}pRd<rz1_jRG&c>#Tgeg+ntsw=
zpU}qSx4XFxyeO_bEnJl^D8TV>!8iftjCr;gub>{q5x}UzBme9Wz<FJ?H3#w-@-$cz
zPlmP{Upcut(P0ln=>5|u(#8~+m3(Y?0vYPnB171V##15B{4mOtD~vH$_qJMC?1Zl#
zTY&wImr?@mW5ai0E|v`#s-el?V5HR(lDL5$vxVZ-4%=y5;Bx{0n6HHPy3X7ahdfE5
zs$*xCTF8gFLNp=4)(LV{J(2=B+zL)>=$LQ1$8s!(OMds<g&YI~Ie&4lGL+~L@R8UL
z?onA)cMv9K+sQlVFi)$UT%&&e!C$xohGJYvK-+^BhX;3$Z-X#IR$)9B8C>k+b^?e|
z%!ucrKB4<)5_Mr8zvX*NABt|2`(Cm_SK7g;qe3Gw;S@py3Br{J=`P_N?YL;HEaP2F
zK0u~Tlb>?+DEfrxMy0Z{NU{Snt>cM-;!&&&XgJNAFvo5kdJ^{*(W5th|E5d(8`2IE
zr2wSZEQd4VC=j|G#{hgvSVYl}a30~B;D#r;c2BA5QEhhLxxviq;LH>u%2($aUlGAq
z#<$oaNkTC2?2SdWkj8V*4}9`H;VVc@d{wZJX_y)`qry~AuIKRp6Y6SoqcGqC$^?u<
zB(dP&yc>}58nC@GP#?y$>}ZlkwbW@sf%4vVDP00MkS}059GIimRJxQAqxc(pv~(Cn
z*CD=iY6{cw-w*krNZ^XPv$+fcJ%eM$A8*_R9{y;qKrM5$L;t;jCiO@o`08!C2o9|3
zwc-UxUJZNghlo%CJ~*}xvgQi-(@@AGx@J@6mFj$FX81}f)k2y>vq}=`NaT7Q+#;~=
zOT2~>aQiTlA27Or38R|YTSMz{>2U7*r%?_KZ3-nN>Mk6tU5yX45(K;~zOx__NSkzb
zjS`w_))C!svrFA>?3Exj(~}K{Y9LV)sKiI8ztERWK?Xz*q{9t1Sby=Y6MD2g_Xs1r
z;~(yMT9TN{Sc?Ra@C&=QmI+Vr!^jsbR(Gk-B}Msx?9d~X#Ubuxsqi5=i3V)re~&f(
zXS{Ly`hSdhZr_LhFYg0kZk0V7#eT+sawR6gScZsOCZDaQ;Y6{Wc!nkHNiGbCV@R4t
zUnf_Ze35lvCxJU&|8frxJ$m2DxMmRk)?4B*#t3j0u#(+KtXF^Qt%ayA_p!bVF9KJX
zQkX9Kw1Wx$8Um5Xxm!w^Ucf;&gi)VHcffr^J=HF)_$bME^haH_l*GVSKR;g=t5|j^
z%9yi!)9(2o($z{luCOJkop&`&rLjHm1yk%-=jotqM5nHoO{IJ1w27ry0n7u6EyzAL
zwOqivWDS4XC<-hv2s8p$A{Csr5~gTMIijCZp&-E`8ZXRO0>K>>2yBNxWr;Mwp&laf
z@-J3=n09h?c9e9rGH-~KwY}aLxpaNV_ZX@A^J8o<_==Wn_63(u95`3tz!F;|i4xTY
zO^`bbpm81-HD`yUljs}@B+~6H@PZ^%35}Oi8C1h~y+<RhnY&Zn5V*q_7ly4RLzcK2
zi4h727MgGU#`1;PrfAl+giF@n=)Lm<wDx^iZ;5neY#jP|zDiW`X|7#tCy*LlmhBqZ
z1!yj^kav-GJt`WIo_kF6R}bKT_`*jC4~N}xCFz5$4-M7@tniZ-msE((kLHeqT^q_b
zI~S~GF<@%T<H3Rq))6&EmMS)|cOO)lO6+v-(V2`Lz*j)qq48i~URBM&H5s1gy=l~3
zaytZLm|p|es`{d(ap1T?Vl6bm?+#-%=67HGD2$Q1L>`wOT`nq~^pQIUtQRBPjx&gn
z4UE{O7VuB(7;0FK(GNF0TFC}|(+iCAl6bKO$4D}UJ6fn0-Pw)+iGai&tpH4!@A_J{
zK4nmQkZe>rFf_U)f*rJ77@g4?!B_+rPje43FaEG`#++fKzvn}leo0Ko%|uSCq?@HR
zWv|HHUsUER@?l2bA&+r_05e$bK`%@)u5FguIu1L)NQB0o34B<4#8Xh*O$t%F{&mT{
z?0KHa{#GZr_z#f;Ft~{d=zf=*rtNd)VS<Y8l4Y(EB%)+rlW~7hbgSjFn^SXA>tVUW
zmozMIdR_Y9lja<NtCtK8N|(rR*ci2EgZ}R8t}||~J>m@o1qJn1x^2V5t-Z-ElTBhM
zwL!BbF>Cp6^3Uvjm`OXqT&n`s=6d<k09F#)58Y)bznFUxC8-oy*|(GH0)*4(ms>R{
zw)vWgsh7&Z*JLzHHNmxBB#?IyU2|VPr~X1<xD@j45P9qs?gEa|pa+vw!%<T4MAj-u
zp+R46NoQj8hI|_pan0sbvhdP{^lHYaoqs<1>E8@HcGRqupfMFE;$uS|%Nt=$T8Vil
zyiPz~tzlG-O0p+PKEeb8|9vg@;fa!5(KxmxxZgt>KVf0j0jnsa`_dA;I>>tr1(48#
zeNRsS0bvX`s31C+G8ai;s<w|d?*CqYnc63UNQa8j17#gtQ`;s+qbf_BJ6#VotA>lq
zN7gHJX_EvI{)4^qalPwmldarC@D@jv<Yp^@475A7Q6@29YF?{#_JO$fU8+qkBE30x
z@80PA=$m4BW}oCG<9{??7=N}fn=3i~elWt|V1cvgH%s)?{nE;XrmKiHg4fA8g;DL{
z_sy2@;+efnaI^*7f_n&&!sswNo;4l=Y<`0C*#jl@))bt`uSONdTze698hL}U8eKW2
z+pq`h{0+V%eb=R{+I%M#pIdRBHy`<^E2MNIQTEcv;&kW)-xhZVKLG{(<zC__>AA|h
zw}#RfWnMPMi=)TygNlQ|4=6C&lzWot&>GFZ$h84;jJ}D{SyHT_3Xs&~Jd^D1OF>0S
zM?F*PtwZK{%P9_E?qf`$QGTqt2HPu1wu6r%_^&~9?|KVP+)xgXp#?t$9TutZXhRVO
zIRT@KaZk|>evQsDsT_Hfm3s6;%JIz3wfzS!MB20pC#N>eLY~%SL}VMaik<p-?%+n`
z!<7rPmHl75q|`cg#<dN0pF>JoWeK!O8OWL%6rL?fzq_{FM17YlXG4f@vL>jtsP~ql
zeYygq+<y(EK3lL)mlTT0Ie*DNE+SC3&&-CesC(gIY}oR|j~AXCl~Zp>M=l-%HzdGi
zlI_p`?j8_Y;G$SCe=BonLIJ7{?WBplv<~__$UPTnhK|cq@ykuc;Pxl1gK+Q{UJ4}W
zn0z5gV^si-o18Kuy;!y&F)c4gw0$D5A-jZN_<5qz;k)avvm@3nWGhaZU1sOE@f^B(
z&R9zC2vhsaic@Tg>58e+R4#J$93)PwQ4B9S*t1qYtMi4aCv+F>C3#t~Ppdmg{HUC&
zc9-^nwXGSCX0DaRjFX2{yH4qg4{g<&AJ47ZVqSi{XttPCQDiBS?<P)Lw8?R-xuly1
z4U&q5_>_l!D}3X#IKSr30qa30t(L+1(C$kBm1Bms<sS&<2)SX~Vc^i82O*Ah0He-0
zw8TzkyZ}q7=3q(&Z(of96|MvzzigeT1A<y8<Y*QS0+8Cz2Bo{5D$QzXlxGH#BY#`%
z>c}@b*`SHws9}e|WDj-^zaOK;duag9b?pWxBA%S*8u4-)#nI`bRt!Q1BpO^ZwV!3j
zXHed{o$>X9{<TCF`Yr2j%D7rQOP6eMkd!;nZ+LQoYdWZdaq-So9^xMX*){NA4)CFl
zF*VqHCs?)GnfLFkA7^(Icheb1(E;bpup8Ooifeufd2pfDDf#xJmraCIAH1`3K3^^S
zzyo2|_8>^m;L8KBt~yd|)$~EP?3VFmp;o8PZhzoI+WYxoCh<(Y>9cPC@A)xNX;unF
z#zoexcNTQ*8;rk2w7yM0anr*-#Y)RZ$0g4y<v?#{Y=UyLdLb8&{SNk8VD~g9f@z~2
zq=|fR-kD(!mSUP<l}XKXRPzY<wYd!80DoB8vyk%dHfjrYM`Kd!Xf3(z+{x<idkSb)
z6L^>O^=5eG*<>&3s`x^tNpp0i)qXV2g?S}3G(TLP>BXMry{LBu9lKiKRsSyAQu1*O
z3w8Yt+`h)6=q0KoU53%oim#kYn14n9D{D_URKK!Wx(kJzR5|J5Y7Z`}GtQP!konYo
z26reqP%CCaLR+@;B;aiOaET`s{-lMEDS<Jh|7&8=5!aVi$QQT_woDuj@}Far?Q>0{
zO1{+FIqYqDB^T0Mb8-(RuxV8=<3XYDg9weoedkaRamr%RQNo#~4&kifxcAIQKpiyK
z9}AT<kFLlD9WL8!I#mnpKHBY8VIdrfbt75>EE|qqDHAJ(0oK)(&+rwNQv`_gxe()l
zLQ7Rf9RGk3=K-!sA9f!)X3l=edu1r~?+zpBPL50mT*?q?L4_Uk$vww=Yasp(Fzd1o
z_cA9r5xaN?P$G*}Ram<hu^wgpy8Bxbz+OjDh$OUwR0VqH^|isOQOh12iv=>n#%jz)
z^DllMNdSgGMPhXZR$&OuJsq@Z5IQe0NTC6DS6eP%H2n+Uh_fbNLTg6-bT0;&HB^Z%
z;KsMGuRZEdW4Cz!k9V#6N3I$J3i*L{lk57dmn5HY2O9k;-Umo(wnHk>y!Ol)2)AK|
z;ZG4=6F*)Vibx3(*akMaCy%aWr_Q{C#}?a-<SGgFX%<a?lsm4;R<pQnC#Xq>ZgOla
zaXoU5(;!(81z6GAA5+L<0UdCLRl;8W0kGb<E4~b{V)otqui!o!C;AiUFM?w%!D`Gb
z`!P_*RBh$!Gx}Pl4+(i)W30C2xY#fX6Z}XO#6GbZ^bU0Jtr6V>@nsfI^?E<+8?IP$
zJlGl#e~;}Y@1^iw)uX8RXq*5>pOPTj1U-nk1F|xN7qBXfpG8#MUz16@ClsTiAI01o
zBwihS`(0sR)syHOgF^%hyfI6;da-U<0=hm2_BQ_kj|)@WLq1VKxHU#vBk0YkD@Riv
z6#t`TswDgEyh2Jy{VitJPFkeE*c~)V>+2cEMD<=^@LZAFe5AkQ(Ir^lf^9*j=NMPc
z0&L+3(o}v16h?gc-h5ZZeerhbOCR*s^Dd9fpEbP*xANsG^pR?n?<L|<1(EO4RG4Wh
zH*ZZTH`|>F9Ec(*DRy=Lpsuc6IxTA~=0GX@AZBg6WBapx54JV1t$}R~Y-?a!1KS$d
z*1)y~wl%P=fo%<JYhYUg+Zx!`z_tdqHL$ILZ4GQ|U|R#*8rasrwg$E}u&se@4Qy**
zTLaq~*w(<d2DUY@t$}R~Y-?a!1KS$d*1)y~wl%P=f&WPw!2NUazpPFi!Wnhc;8sY2
zn<0bT0*#oF9IA)UT8YCu3V+qgWr$P`c3!R@)zkj^&9`u2<gkh2&%zJzo;^A5#!N1<
zctdB)EKY+av3*_Zqb31cTrQV%@li0vn}Fiw^96uHwmUF7i+Y@^Gpyt5-rBf3<4W}~
z3kop}(TMR6C<ag_%pI<VNRGZ>&E2XbJ9CG0TJQ9aOl1YfE7#*Omy(v&T^%;yn{ay^
zJads$3xbQc%41Kx{_Fqt*(zrH@KOwqVf)vSGxDzHCIA9-jEmMZRK}p0KN1Qt7a4}x
zPxMm8T(5nvj=|UkAAR1DkJi7MV&QV5?sK_$dRb`>Q2``Jc|*tA>UUG38!uw}aKiU-
z2*~)SHJZLMUlH)S)-b>|1{eICe3MC0hNscezf6nKBHZ3zwb+7C(%3{n{g!X%t;t(H
z&Vf$}OU&{ml1tEHTVPly7NOA)8ax{GiZLwyJA;0nA=1YVWm>f)9U2ERXIqzMlOF%s
zu^+467wG@4tx(o*g9eFAb*%5deT|^eHvBH@9GZ@DeUphkV(?4iiWe#ioSlc`v*??P
z%PS+KQ37ah_ObcDZ-*+#tf6cg9_L<RNVWi|LGz4uz7~V<ls2qTjr{z3!N8Q@_$vmd
z_@+m|RWZvoE~DCshDbYj$$Py1%U;$d=>9TCb~_u(y9zw!NP~8Dg4__$QFBHIT-`}o
zl19ZD?4|hzG|MRszTw64<;iXC1OR7SHxP)tw)zpPa?5E(v4Q@AsW|+0ZPN0C;uD9M
zw8>-;F#(dpo;<=0Txa!hjX+`vj=S#7ufpd1+3|^Yd24(tm|w?&o&QA`L|TpE*$&Lr
zfB0vCB#I_|5XW?B!|gE?Mi<YXETq(d&Lm##cnEcft4&3goap39wr+vjDRIRv=W|z`
z1}QOjOG!2A+Sk-3_7$e#w7mHwLq0wu+-hlkbzw7j=zq8N^*`?KYy18}YdZolvqF2D
zoCU@^iqTJgJC2*b?^A4ue;8uZy*6zj)X-gY(Erlf`Plsh@`6Wgt_9&=tCKtu!fr6;
zpL&*!E|aKgOuaTuag5gIft6(1_um}+!34DHqP$&<Qtjs`Luh@fU}03s`P+^(5qT7>
zU^5uRNZGR>miT#JLNGw;-n5MUU5t8477LU$X_XF&puk0e=K%87P`&<#86d!Dm>905
z?qXh(GO{wRS)!IJ8R*>_`|M-mmFJzz4`1IAaLthbxTA3;j;6#HZalU@=iyTamj*wD
zzzE-he{)7%op@Me9VqAt-_48S!PbMi>e5?F=EJ`^)0#HrX|L-Ci8AJKs!OIB`gygL
zHHpgfxm%e2F6qzn@=r5wf|f~EyGw@qJ&0Agl-Ijk4}Vj>VY;I<!STJq11sC)6e9&b
z33Rd=4Prr-ey{R^Q8ouuFLRW@O{mvydEgp~1DxxVpJ6$4ETJH`c}*%+W-fgMJ?q*n
z9IXG^ZfeXrwd-)c`nMg0ppVo}V{x|9KQMQ=1RC5zs@)r30v<HOLEk`*IH|g{Zb)}O
z%J*)Ff^p==G8-c1fG8D=3rxAZtKfBVchRvt)n6blGYa{eOLVA1oYyyT;5)zz=ZgJS
zXKPhgt$^EbX<WZG0G^b`p`dSv>U;3m>}D47#G#RYb^wyaAo{kpINcS`Lcx~Yx(Qye
zIoxPBpb<O4JQ)RxG%zNh{T3J7w`ProS+a6r(^_+Wzb9)dIbCt*HSYVpIF&o%`Omjq
z5q6npU72qmr<eKQ2z{i&IkF?4q&tiQw}{hN9{;`$#DBSo0~SoZjthr~w4}WN6y)A~
zH@M&>y;4?y7<6?+z&$HC;T@A+f7?S;`gn>Pa>tLa8SSZOCk^5T39O&ccYk&i!k4=L
z8#zX>0P!Jk+I%}N$V!L{ZXwh9qA%17e;f^Jl<G$XO8o|;%;)+(%oq!o58QtB2K^du
zT~i$ymXQ9vZpy&FIv4IZy^t|l>zB7Hy?P>ixGjPH@%4V+Pjt_e8QT6G3VS0RbM<yS
zmy)x57@RICZUr%yG|)xgLG~70ka}fZbo8Rni;#=N3wGJzIi>^iQI*dWl`m%=T?jb2
zsXWUNFMF9?o2b9v0s6GyQkABFmFOjOxB5}@_oc&S=NyLu-`liau)7#xRvNET8z_F>
zwE2FqvG@W`kS_$HZAMFOp>b5rmOgPb=Vo~|$1QJf<nORL;8C6S&)xMSnki@8^CzzL
z>-f9+1fLyQ>#Lekb_;SGzrz6HU478^6%UMM8#_I;$%`tmA^KEQ_~<Oy+GfvrS9gg`
zr_S_LC$v+_r_?b)?(xl((~jO@*RN{JMCV5|e=iJ_3k70X$IV`74E!w8m8q=B3dSOg
z!=HmBY7+5x#N8^uLWoCIA&pDJTT#y@J~ftW@49x6!OohkYw%GXFD*tXKIy&nOgLj{
zZ8aWrOom0}o)|JvoLxPDjsusW2c~Up7^|_5T+J_yEWc{<?&*E?!NqyHx%~C|@nqV5
z9S@I~+_MM6{A*4IrVl3E?>g1Z5G&NP6!)*eY6@Bgiug8b6U?$bblyzHrly!q>!0P;
z7sq~fFf6eZO7_>doJ~`<wfpeBvm(3tbctn>){|nJbcndygLglM>`XN*J@dPNtZZhU
zDj^&KP_5Y0BfmlR3)=ke5sVd0*4ZCf;0*!^39KBXO^r&o`fr}5WpzzMeb!y=O?w7N
zxAv{Gd%5}j*`lS+LOXajr7j(gdoh1rSE~I?te;J4dA!}EuR_)^Cs4&E-?G4G__$fx
zDa!(9qLP$tp{4M{9JAEy7kBnu)v$e$8GkqH#mDSib#XGr3~*seQs!d|876JeeT)19
zOgmy?PSGuI=^y)1?_1nIxTw$M_^T-^WJ#<{#kkuW-nO|C`$_8P>R*6hJ4v+Owg6C~
zu0{spB!EK45L=7yzs=8UtbW>c_?v&gnJY5Kh?Ui`=2??nk%<EX!-_R^xu---RhGV&
zM3gu{V)7jzZqMc{i3fhqn-Nu>`)L>2rx_m^%yzEK(<zXAG(3n>JE^%psrh@yZGT6M
zCq&##oH16f80r|WaU$Yck!{Ik;i~}!&S}?(r*0OWzhsSQx6p4ii{%7^PrxTA{^Zul
zgy2szm|dev6=jJCjl2N^V~T6AeZ0|uJ~h+4Us&a#z_7SH;X`V^9}61grK%J&U?Shd
zo_|x&zRENgt$)~dLd*1Mber6H;V<_dd8qvQqE)KW@<4%>8HNKf{2B8lgN+M?)xU|O
z49;rFpv4Po<1-QBEch4Av1)cCFQ53d0FY@44mHjPd{E-!==^rJH2CD>LO(26!x3y1
zoh0F|ylF=thhR-?s`KQeehmE>sn*n>*l8juiBuL$7v!8nLdUTe7_L7{kdl#9ro~1K
zSG*8-+Uf=wcvPdw(%)kNZ}tCWUnLzlSDAS))y-w<8p(_Jxh&J^?;K+=baNVI<Jg64
zH+>E)D|HEPU%Y(2E?|xBiy{(#Ru%UB*-?^xdOfOT$*>co*NKUnr1Ksojnv4dVEb}6
z{JJunTnqes`8VIhs&*Rw^Y3F%bwiuKFOTDj?Soa2TS3Ozd7yzxmu%)M0A=qH_J$Gw
z9eYQ3;Y`QT8*Pk@*5K;vd!r1_7yF!Pdq25kPY{n=(ukpr@Oy~^f%>qP3#a&`65J>H
zB6O5RU`;nzO``y1CAxbaSD#nisE<Co#5UqR=POv``{arx)cZ2!sq?Mj@b(ExEf7xC
zXJy<P*1^T`p@XP<M3+1dFU8zs#L-ZUMEaUS#^Iia;Lfr$b^^YS6*FiB#DJ@#Y~FJg
zc#eP777$u;^k$(gFsX};j;6e1(Ed2C@p!6f%~)%j^1!DzPFH-@>pw)eP<SS`L&UIZ
z(lAkQ+Ggt}sO9OaE3~zhYbCxkA~9jb&m-N-9O-?xy87zF(#Z}n;fNS9I~ASLtwoTa
z3a#;*6i;Kj@CjXm@LW3HgFk@V*(mKTw~wJmKhDuZVilNsmw8N0=V7iA@71hMx#2~?
zn0fgs(Zb3WxHFrTa|TzTd$PX2Fs{{5Xmt6dEb4C;5^>Tv<c@zJtUYaOKcy~&s}25O
z9l*kS;Qh--eX-EW(WV@E>cyOiM$mH)17qM?T}^0u(K<+kSb8O~zuxq<_l4ZD9TML{
z0#I*z0@$Th^Xn@~3s^(*t!kGiOCb5RZ;-VR92Nn-G5;&}Zlv<E`8zOTSzm%-l^Jvg
zrq*B!e9v#!p!LgO%Fs;S?Nb|+&+M3m$5s}jHCDK1s0|{@Q-EH}1Hrg!T%%c>a6>{v
zz1|Jyg~SZKs?bU}#33IednJRm(ft00amsl^d9=7f!jRSlz1ZJvj~?B&OM8*#aofno
zXqRXzm~(*=)eVBEvPU~tcwyMEY56H|nHe-y$5$S`0C`*)zV{kP!xH^+{X0ez*h>k{
zgzP~(PYVs06eG1y$IiE7b?XyDJVr3?pXA}wWLKXIi3g6x;UV{@B$rtnQ;ZYuWj#VO
z9xJ(I&ourp-k30}xfeNt_y`EnBqNoa?lv;26YDhtPK+ZbbeBb~b~+i<agG~|N?Y)9
zX2aiZIdH{}2*dnv6HV53JAqlI>{q)3f}|LhQt+`uPSdZZlhl^GyB*75ayE%GMex4a
zKRbRnY_0~%X1oE7?nY57ghe|4Gj=!_b^wQh?ZUO(z=(}<bs2pfq&--10NzX%CwUOW
z7DL@){NJLLn*47$B68IMMZ(lKFRxiV#A$M><xU9oU1VSD1S-{6+PTX=?5*Pz-(>Vx
z6jvNOGc(FRAk4YkgxqzOQLxd%d)_2sEaC^)QX+lJ+CRkA#CU$0i&02dOqvhZcU~f9
zc;sgeT2wBDxh_t+n~gd&e5|VKMOxMJ9m1wx|0jPS3@02Qvtht~jtur2Nuu!-_NzS^
zYJg)7I`CeTh+N|k=F+TW%jNtQMm6nFQl59|_(HDWFsb~V=-ASO$X9A~zq^_J@6wU4
zGz1IhE@Gqj{kXLx5Zi#~Mc{mscrLjD@2WCVz$f^Z23*11>yd#qGcq7a_+4MA(Z#XG
ze$nnyTL(kb(>fvVGELGE1-vp4HF#bz-NDl<#Yv8rYbqP3U00#4ea6#MF^dS?VG{WJ
znM_d{s)Y~*a;clNe*3Dxj-uzA<qoCZOk&sZ@>hNg<})=xvuI(~u1a6aX}{ba6n3Dh
z$G}`$>BV5XOgEu(k=-|*&$qN<hk-nzaYhzML)sg)=)1H*(u8UDh1K;mU^nLG=QdY^
zaRW)u<n}N~AX9EalrIQj%r@CW$8&`lddnRg7qofv*1hV`$TyGZ0+)b3%0<;{rAXe@
zu#!t`bA46EW0D!8l9IM&Pr|Z_?rB~Bvm+spW5E=ltuAjetY)pa;$b(Ks2B_`fSEtL
zr-5U`-N(R#$>#yYhTB0`fi}4CBXxI6rhOr8li1~wWj+}WzdZC2^*eCj=e5fB`RV)T
z>t3B8v}L-(hk4FC&0nJr{_|V?|MN;f09K4zayv*h91hHSRq`9DY(IUQI8hxudTxqh
zMk#5iH?4m3*!9QrO>fD2pD@l18B~Y1eOw5;N87F{eb%%g%}>JdkXJ>G-91m?Gp(h)
zZ!S{JzQ*VMld7<rk6a-UdNvWoqLw40ffXa8VOSwn)x@-9qbf#;$ndRnUWo`an7C5W
zfxK8Udv(J;;H%==^hs+d9(DFhomohkVX%JQwA&H4Nsw6h(M{(G*|?uxP(5%bO~Wg9
ze(rO9jnS!iHM2SQ>St%E^+)cdm0wc34U4gs&E=`h(2>CnoL|fAh0aqmy&FDDX$^Fb
zY51d!;lNsiR_v*FH~x#u{4bmN|J`TjDy*D0OvKX#7|mgI(Y|0#_blq$dSUX3xSr3Y
z^~CD<y3!l#RtgW=Yr48loOrUllLuw2K5bMnqOA%dg86@i>$iZfWF}LRW-z0j+8TPK
zvYxRK{g#OyjKAP~3+JtnqVc&z>+7pT#klSp17<P6_x(0UOzmwBlqwuH`g-i?bE6-J
zA3`2teK?7WivzfE848Z85c;kV^=2C5OCmDG=>^^IcshIWa0`pPAT7xh)#GZ<uP&Vk
zDVB48@L9>ODra?gQ@w-`UhO;PFkJY?d3D5W5;?$j{{1sJc#Uqw{s$<eK%_C(2eESK
z#d!+`y8!elcb+;t(e!pv!uDI(C-}}Vgd!`AdhJsQoj$cs_V)9gX9wjCB1Hc^xR;e-
zA_SL%g+lpgByvYzQ+wi}eK!sr@}D}IN|!ssi`JcXX_d?*G{eP!6Z2o3U)TrF91Tad
z1#7;KGtavAHZUd3LS#koW&P@z5--!~++nIn-StoOZp~$RX1p+77^5v9j|a>G4YTk{
zP)5R*a0kgI;A*ia2s=@BA(&6{Wmi@vEzJ?8A<Cv24Vow*c!a*dpA?dNM;5?1`TO3l
zosTs<GVZpN@%``T4ZQX){kMoG2T#YkEa6XO*LEC>t~g<m6p5tcCQa<VkJ^LJWeYvW
ziV<BfY5A)X<X7oFi&Ot7{iNXIe!qM6x2uI@lRu|S;kBgRRci_L!NqJ>e~~C4_P6Sn
z_*OXQ2olGL;`fn73@qFYU*#`4;EpsNLEl|%&B!!-RdmbI`$GPN5hgj|+DBC>^O&(C
z(5{$*kY<DTulct}7s$)67y-8cCP$GQ00dH}uXbD?)&whqT3do8#`n%X)|r&iFG}W;
zvb9@39!}It>%Hm|WI_Hg3jY}n7P?&B2rfO#S#|v-cB{;b;BT8aTGFS>G@<8lOueOh
zs}Y9^sV+ULR>P~mIqE);zkaPPWH4N2T#ZlxNX-4&NSgjjnv?vaW9O!BKDZo8ZpJ0f
z7y#f+#<4#Q7@jPQWFcWf7^z_vUCJ5oG9CO`F`Q>%lvkgK^nUil(M_r#;_;sI!be;l
z^jrb|({;_n6c_b)(&2g?wsqPWXM?T$$>TPy;?;<Q*KVe(*gX`~JC@?o$k@9~BJlg*
zf-vMP0qAS4<+1vjWW6lw2XypPwsMmdYCVhIJDV3x)F&ubI#e~iB_hNz!@G*))otch
zI(ufiyi`$sJQ6i^DDe?(;03{BBnYVg&0&#V0W4!NyUg9;PbtuNScT<d3J+q!^jhXm
zY(%TwfAiFCWYjj%=!4sFe_ghQm(vM7rH%HfonpJY5Azpw`Z|W`jpqT)KuS^sT#$dV
z>r)dB+In;7DB{fcH^BwC=cM9iJq!J~79IWgu~^}Qb=C)qU!AJrI5}^amP|Oq&hi=N
zK`BARl~m_y@wcC<eKo4X$hJ$eq8<2(ju?ZBG?chEuH25F{~EX?6P6_6bHhj4G3t6G
zHRo=M;}4SQPpO0-FI-HNpNJ#o_wUnk0MSN*vuu+;JMz6!LFCa#(xyrk%*zU7`|rjm
zb6^-SnU2@dKNXngrM0*PXD18=!$e9njprJZcGq59>p}&1=?*SrJ|DD`uN<5p+dWU&
z*onOk#%n*V;z^=9B!LO|B;X%dqic>Q3L*%%2kCURRieN_iN1iN6$zz+-dC!R|D&u>
zUSt0?1?dd}frMw)?1z=u!K~qll}aLg&lbT$urNeb^WiGBfnGA<Fz3s_9&Z>3gdRqQ
zMn=5-v*XUM(b@vuNb(!r2bY!tM1|{=xmRIU4JqWIulmfXgME?D-_3sg*8VB3jW3ID
z;%hJ+p80)}ud88@qKSQnrd%(@KcDJ*vsj&ZuUc5XLd(P;-B-=KwLCw<Q*FNiUC;^!
z$8YjoV~CaXcXhl1UZ_S<>6=*0L(_xFT?doI$}X6Sl~pJte~mw)kTCpIK7Ys8&S2Hs
zkyCnyA!DSmeGuRtVdCj{y+aa#t9nVBT>a}>pAGJ4l08`XT^?{)4*miGPLZEIf<zde
z7~r4&<%yF4u<d92e=yidzP^&JgD1PrQHCu_K8zuxhj!#IP9)F-Wg2un>#AcdEOiIw
zxh+5oGq?>ZUGIyV)fDL{9NT<c^2m4Z)r!atV+KDlLsHavAvCb^)Z=Gv0lIDUj#pt}
z5BmIrwX50==+*xoSnO-$s5XvnmQ37hU&^x348+0Iae9j(U^VUfYr-wSgob(wmOV#U
zq*&5HR#I%W1Uo3dX+|`z-9Zk*z|@v~em?C6LaR+n@vXI=(tQ7FWBZD>WWIYE81`T-
zoX{%4?hmmIkrnTcXzkk@T^LhvKwQPfxA|Q5S*WB@SGvFDI~h^1I?!n_)gR##5TzC8
z@2k)JDJ6YA{XpYi4YyoX&PBJ2``q>)>#mdhCY_v>a5U(zM(B~qK(P=dTOqd`l$Ub5
z?%l~$-ccSN=c5@975lTpr*B-fNz%FM6$KZ;##bhN*?iRZ6famAhWZPmR_f0*X)aeA
z0N}>=<c<&RDxN>vKwByaXnok-r?AzU*gD#R7X^d(cmH~Al#$y=ThD#Om%vn=n`^ZU
z+NXLQVZgx9FgRlAYoikABW&@n4Td`@4#zq+r24DkV36KvYPOubY%C$JgxBzL&`xzY
z$MkBpR(GClfz>ObWrEHo!WzW*Jg8J|K4S_MOu4sdY0~j3T~Mj3G{jGmXZg*iGZ6x@
zeCFeTKkTnWY_)$7n})IQS{-d2323#?3RJbrx%%S~Ns=2*K}Ac#Azlo<W}YTB-cTH{
zqre2v>67LSPgoelEKF!&Z~`4gGhV;^76JDfs&{|DoSAVptIjxl?Xl;u-&hQCh_A^-
zSJZ%Hr6h`EQ;)mjcdR5D_a$@>k*Rl;n7Dd1t^;&hWc{KIad9+F@!i=Lw5;$$KV>yr
z4269idddcM!X@@UazWm#$q3HC+yR?6tC1V<Llj1Eo2wx0h2d$ynxYvk&FhUodfd<5
z$Arf|T3BI`BSSxc-<aEaAZd@4h?7siv|(15T6s~;_xndfELPdM5CF>2MQegp_gJhJ
z_+Fn4ZimLW9qz{}fY?Uk(P&+(gCOG#@(=eCA&k-!Ml&p;)@7kYfx%Wc_0mZ7hh0q<
zPL@#VdS(pP@Y_a(;Z=>**@3&GLPvi(CLSwr5Y3oNE{<v$=v_a%a2ay>z>@VNMy1CK
z+fN@p2HF|jZ1xxnWg**N%-du?7%CgKKUc#b8bJ2mJ^lIUk|7%7sYN<)&){X|=Vi}3
z(vF|)y320RoIjgVXRI%wi~74OvOOgsPqu~-{lx};N@{twvwcE<I|%U~xzE+7tR7lw
zR32sR-xZ3DqBh7|kFc`F10KufzIx{}?Kbr-wfVAOmDTlZd>zbZ5-x^zV550ijnbIl
zVfjX0J_h;;b3J$6xN+E*g_p&^0O&^-;4FLxTApT^FSao%5n7IZGTJt=5m~QP<OBJD
zc4*0bGckjxz0;7`y_pe1@&mc_H~R?~C5kVqg|w3^8ZH$%-vqB9Kl=?<T8)QxH2w;7
zb!ia>V@nZ*&PhKQRf&1_<Ay4}vOaOWj+?Aj-lta4r<Q7=lLT@`=?djt^4j0j%JsFs
z$=7Mu)k%1Idfsh&xgH*-+@-}G6-c-5)|MXsB%KHmj%l+g_~%Q1feAFSz2?T3=0>eg
z8Wly)-j)I%EihX7W`Tr^&bmTp+3%g`R9Mg2(aGr3HHOAf)a7tY*UraXOuO}LvS@Ux
zM@XX6x451Ul=5yvr%3jZ2#18O(sQ@M+D0O!$Gaa4efVBH0G!0_c0m)ad<NnQ(Qyup
z`;vE2hY?tjVV!B2*3g6({$FWe=)-c=bSxW~t9xmDFk^ionCwv<;uYIYdvwj^7ahlL
zV5Vo~ExPUF;ko~+aJ=}7bNtCJn{vQQkqN}nO3rC(HGyEklLczI7nql75QhEloXEc#
zMUp*Iq`0aFcgjN*tliuodfi%E;_q)GdA5@^VYjZz<)}C=*uD@`G;*izjxUTT661Z6
z$U#$=0?a1|bCQ3b&k(v-)2j`M?_uC3;5XwXWCRjQz#m#{$+kpgh)FnEWbfpAKm7dX
zS}E>TiFeuu^TnT)n6Yj(_VYfw{$P^7j4K2M<Hpw6mx6=u_O6isGLUl`e-)>FX6|K*
zsY1Gv0uOAy?!r_z4qyT}moZnq*Ngfy1zKkg0Zwlxys=_~EFo?4k-&&ijH`!X;hjA4
zB4vT$Gw9^4srbS{NSbURvT*n3j5)E+Dg_66HEqfn?gsBo4i>cf%;Q4g&S2&Z^<yQN
zbigWMEnqo*++gP{R1%{yu)@`&RlGsW9Q)i4zr^%-A)Q|2{$?>lf_))^mzG|;=BPeN
zEGSr?^r?Peh4NAeoNUWv$_0-ATX-1O4I93-Las;8$Z7&#&`#>4@&`q#2tS_~RaeBj
z(eVab2SX;H%N%XZ)#6q0b;#WP!}aE~ctLbm2T3TS11}WVBVh9#1G-l2aN>$Fdb4Qo
zn61XL4^Ad}E%;c&1I+Z7GY7MpDvScdXOW+Y5FyidEgH!PS{S^AG+EqIB`3x!1zYQ`
zP>brsk#3C95bN6O7>RTF;n-8Uo6T2aq+8#Go7v8N^e$T&JG^@Wb{~6)3mL^6;h?y;
z2MzZw@HP5HzmSEovKC;9))&X>xqOQ;8pA)b1m9h+`2jupC0EOQa{w1j7Hd3#CR@Xg
zASRwEnc;T(ocOb&ZQaeN(7e!F9LV7Wq9a?{U{y+V!QzFAwg6AVV~e3TZJU2FzRo~n
zH6gw3$>KIwL=k@C{dTv6IzMQ`^=07Z_ZzSyB}i05!>7qI_6@SROZrw|-Sl)-7CmUB
zmxEWbHWv4cV)t<NzXpre=XlwN_JeLD)>OIE9VJ<^Q_ZtE^?JK@AG>}9_ZdZ>IKXcw
zSK<%u<*MK${yN=BVlL+wj?->&KQBT$B@tsMBFLqA)*Kmr?-A9GX52nK6|KEvU#CnX
zJ}aJ<xp<Sm86OgZul6GY?x+c?9sZyfOt{!V0iVxcl^tF7yk4l~xPRsH8jU|O$TNbo
zO<Pv^?MZliE~k1GI@c}Eb#!n+KcR!2KD&$N&P!adcvMYH%TA&_j6Fr5+48Rb2gGi;
z3>J%`+(1V@&Ncq@(;FOh(qvmSFGu>T+om}?&vUT6*Z0a~W3Q+6nK(q+m8=MFmn9s-
z9Cyepvkm_b&Q~)gILI<}5`eYKodr}WFhQiy5ruIi_8227s@{lZ?xLC~;-uq9C%m~;
zucz4P3>=EJU&jrTx|rc@C_SDFmt<H%{)GpvK$4hx^!*>vcaLDsQ^`>{A-=5l0N_Q{
zYXT49Wq%|EAC)Vcxj@iNY0~h_Ty<nZqETlTv6{@F5{26N7+vGou<?}M$?K(0=Y3AS
zOL0Lg@Nll}|L3*&KO+-$(5TSqq)5Z#XwlZ%ycdWWC^IR7*zosc$Io81M<t={{N*MI
z*1E@<`c#|T+ziJ7{Y@$H%|9?VlD8FjdYdjZ8iM&?3A2bqdE>kh0cj=6pr5wG840ju
z6w~~c?>=N`MBCzmiIbecKx83X{N>-8l9m-tPoi8LUu?Q};HY4o3<PohPQ4iLXUAb2
z4UCWsCb;u&QtbQn2CL0CLwT#N;sgKJFZf`U=*d5r+W?Na&Ta<!nC{e|{J>(gOq(QM
zLQZyQRi}7bI&9Kc^h={OgVol-cIEoJIkhRSq(1Pa)y69K)I|J<J?ops>=Co&lO*}5
zRVWJ}t>e)DslYgZ)-{JnzT`t_6b02{^%y4x^FTet$?8}=tBpz`VD^`w=dFRqg^OD^
z;fIMF++iSPJfj7xH0Y~gIQZUqa`&q|8+G50)bXDkx~=$K)+Ss?({$h}f%V|ms0ng&
zysCC%^ylwsQa=O$&3nel{Nx6XHs~K_!p!)yBdd1gJIt@|@r=Z1rIjdv<L@8moJC~L
zM+N%ox%TUxGPul)C>&&kpJdBkwrGs-WY(AIRAr<yrmiZQ#MhomKC;txv%*+abCIV$
z&l~=;W3S66$4~eHaJ0oCv}*Dqgf`!r;6AI=hKhkna4&lmE^Luo2{J%&hjSJFZHGaq
zU1T0D0c?x7)Rhm~{G|Q-;pE(dVK`?Mzgo!@yINC|8K6+uck0c{{}#}Hg!DiC+L+3O
zByyF)IVxO3AO!j0W3F0%<B6rr-h#K`nM^mb`RD4<U6P)2^pOGM=VX_NYlR_t`cG;S
zZ(+ub!QRt*U))8WD2rd;S6;8j@M4FP82se$aE{%C_h@xyctOv~3(R?c;lb6D5pF-b
z-%fOkc+T8quAr0gGR(*l0$@$9DCEhq@ce!EHva5*zfrx$ny1z(JHtBhIdk*8RajT4
zv+Nzo>1vzR@JDzTdex-kq5;_Mb%w^Wrj=UU6s;tGr8^`@<j@?K-<4W8LpAh}$q0iK
zbGdQzW~ZEI?PvUtto^XQ)$p&V4Oh1Y9d7^UN<aZ79AhpVkVKY@V|1D3-c{IRnFF&o
zD^uD#w`P!8x+&*0+|9pwtSPNcwJ9WvBTfi+9QQCL9DWn0xir7T(<>gC%V4du_*uhC
zxC&6I6d2KgC$<m9Fv`cR=|0Ro!>fRKC&>a{t#TqvNW$?{6Q*$n+pj)7R4&0ixCk--
zupy_7MSSC`BhuQltN7;}{pDoY+TUiIezB&C<>rH<U^07BQK}@xEq0pp4J$Kg16D>)
z6G&J|{t#|A9n2|QsPpaki0WK*)E<TO3E7@cQB=ZVr-r)v0xzU*nEk+{RlV?q$!_1C
z<|!4mcqV>&^vg|KXI#@#@%lQKSSyXGCg#w=ZgGXLtDY~*p&=(T*a2ovqJmA9JAZa;
z=@qYX&w`zH(k7v}7DvCsQ9@s(EY0i&BtIZ>PgX?w7fd%%!K&1C#q=Y0yx$I2u8P22
zCyXwfj}49-2s&dBd*{Ie+?i8v_~xT&;o!8*l!HDU;&yEsS=;|9F6=k>@9Ss@*wwaN
zC8km=aaW@Ls>o7pBPs0Y@n_1x#fy5G37uDt#DySrC-=38G+mmD>A7QVthuxf4&{NZ
zE%_}jhqPqj`lMkm=*wiFOd*Kke9;}$kyNIhDQEXEfh&KZx8wst0`Bv&?Z+bY{y-M}
zq|1#&5z&{~W^Mm?T$Kw4B@FM~5PSrhYJ%V1X2miJ@WzdE`0;hrRsK<kEG{90(54wn
z60G;9PP)p2G5vf5R$}pi&&b9)5OsxV5)&BLRV;O%B@^-}ia4CL%$%I+3G@wGf3K~U
z{-B+tkRr{vaEeHxl9zBx@14nvRThag^q(o11&rh@L<FPH%y`B>hSsy;e`Ug-U`+CW
z>gKKLvELl9l+h=Q4!cPl{_ShBEL~8tk`u;OztlN1yPO$O(38;KcXDk68JvFd>#(jW
z-OF|;Fu@X6xp<+3HB<2Z*5-{CcHHD-jD}y~+U>+sC)Pcaf2>gxj$2HgNVu`{rgw>~
z^QZU+D<vkEbQSG&Zp|;d+xtILve((n7B_9qIoF8@=sf+*<K!DKUOrf+)vk7NcU;Z^
zG=i2UjTAM|RY~(1Xz3(rR;C>Y^cgO;jLRxKkfzdm#x{HYL}N!KuaV?~v`{tb&uSw<
zh%#0}0M3Z<DM5q8(dYN%Dh#W0Vbqe7gIB&kS|E}Rb59KGCK%~VYqgJb?q|txvZ`Vg
zwQrdo4~8AJc71tpQnxe5A?;^K<gKOmDyusaTB))g7CnP@Sb{UY^5)b}N@35}IYWmK
zGpn8+ARr3;_|7c;$N95CrHLO)i}gAg=VM#U%Ab^|U1-1Y>HUQdIl6X(6`9Y(rfRI&
zUR=EmI*771>U%~4;-KY8e|DT#p&6dwkHTcJs=#F%hF${EDyrI0ZunklI$KtNqWJ}~
zd-3B|Ag?js+m~xf!AHu;GR0#{hAS-$f-Za%o^JZ-<o0pI_SWBIU2E6C&sj14Vm?&n
z(aSlbdCu7j_IWO6yH%`<&HNwaT&OIJd7)yP?GjJbnLSl~<YX4AyO|-mlj464<0<$A
zZM8qHd89D9nO0h_m-4-pS|;Wt{Q^l{8fdy&AU#yLuQ$gzAmN(jnHQb~;wQnFlLmDR
z$~^}}&1%L-PDm8Yy1H{b*ITfM7`PUm1ZtV5YQ>R!$`yJ&4xpMdO)?4`$JzpTY58N$
zAa&f^_3cE-Mg}{_W^0i(SL0p37i_u8U^JNa8MC-3?5SbyaaxJAsluS{^r1C#eGclZ
z(i58cub>{^K!I<&r*oRS5W&6*=^Ho91#0z<8zY=cZW)`75bO&=iTCDgN)Vj|W+@|U
z+4IU~55sR|g*Ld<q3<w0-<Ok17u_F~7twO#Nuh~QRK8`RT*5hWy4d@Hc*Nk71u0`=
z*Kxfd{?ssxl257{DS7MmtAZOitVR!n8jx>!V?}{5>a-ipCC<A<vF^gkW2(BIL(+}2
z45I^!&&ei5Z*MrCaNA9++|Sf0@6sv%H^DBi15@idgYvJ-PCt^TU*$~4cm>_<ZcV@2
zn$oGNkTQ;ggN@3l5qg$F+Hy)GKTNY9D?<zdgP`_s0tNJMETq3;3^su=)ZQo9(>XHD
zjUofSk2E0&IO8!_tC6!O%~Q&GQfAt`sXAlBS0v{RjlCFFWgG(zdA$)s&+`u`b3C|a
z46m3*&}3qEFS{=S<NDUs+wk}RXh$VAF2g&?*j-DMoIpMG)fI%Dx4YTr5xBeay<MWm
zUyY~UG>}*sF@^+|6)Wn(7NKm5G)y9v@mm(TvG`Ip-0=t7t><Bw{=<iE68?UFcBp)o
zd_1DLwDk0|hkIigtM3!&O6CD~-Xas(Waq7p;fsWki`A>))v!u-RZ;KHRAVt~x8p36
HKjZ%kHLnP9

literal 0
HcmV?d00001

diff --git a/doc/design/assistant/blog/day_201__working_web_server.mdwn b/doc/design/assistant/blog/day_201__working_web_server.mdwn
new file mode 100644
index 0000000000..c9e959a334
--- /dev/null
+++ b/doc/design/assistant/blog/day_201__working_web_server.mdwn
@@ -0,0 +1,31 @@
+Seems I am not done with the Android porting just yet after all. One more
+porting day..
+
+Last night I managed to get all of Yesod to build for Android.
+I even successfully expanded some Template Haskell used in yesod-form. And
+am fairly confident I could manually expand all the TH in there, so it's
+actually useable without TH. Most of the TH is just commented out for now.
+
+However, programs using Yesod didn't link; lots of missing symbols. I have
+been fighting to fix those all day today.
+
+Finally, I managed to build [the yesod-pure demo server](https://gist.github.com/snoyberg/3870834/raw/212f0164de36524291df3ab35788e2b72d8d1e75/fib.hs),
+and I have a working web server on Android! It listens for requests, it logs
+them correctly, and it replies to requests. I did cripple yesod's routing
+code in my hack-n-slash port of it, so it fails to *display* any pages,
+but never has "Internal Server Error" in a web browser been such a sweet
+sight. ;-)
+
+At this point, I estimate about 1 or 2 weeks work to get to an Android
+webapp. I'd need to:
+
+1. More carefully port Yesod, manually expanding all Template Haskell
+   as I went, rather than commenting it all out like I did this time.
+2. Either develop a tool to automatically expand Hamlet TH splices
+   (preferred; seems doable), or convert all the webapp's templates
+   to not use Hamlet.
+
+-----
+
+I've modified 38 Haskell libraries so far to port them to Android. Mostly
+small hacks, but eep this is a lot of stuff to keep straight.
diff --git a/doc/design/assistant/blog/day_203__procrastination.mdwn b/doc/design/assistant/blog/day_203__procrastination.mdwn
new file mode 100644
index 0000000000..b6eb262e96
--- /dev/null
+++ b/doc/design/assistant/blog/day_203__procrastination.mdwn
@@ -0,0 +1,25 @@
+Stuck on a bug or two, I instead built a new Preferences page:
+
+[[!img /assistant/preferences.png]]
+
+The main reason I wanted that was to allow enabling debug logging at
+runtime. But I've also wanted to expose annex.diskreserve and
+annex.numcopies settings to the webapp user. Might as well let them control
+whether it auto-starts too.
+
+Had some difficulty deciding where to put this. It could be considered
+additional configuration for the local repository, and so go in the
+local repository edit form. However, this stuff can only be configured for
+local repositories, and not remotes, and that same form is used to edit 
+remotes, which would lead to inconsistent UI and complicate the code.
+Also, it might grow to include things not tied to any repository,
+like choice of key/value backends. So, I put the preferences on their own
+page.
+
+---
+
+Also, based on some useful feedback from testing the assistant with a large
+number of files, I made the assistant disable git-gc auto packing in
+repositories it sets up. (Like fsck, git-gc always seems to run exactly
+when you are in a hurry.) Instead, it'll pack at most once a day, and with
+a rather higher threshold for the number of loose objects.
diff --git a/doc/design/assistant/blog/day_204__deprocrastination.mdwn b/doc/design/assistant/blog/day_204__deprocrastination.mdwn
new file mode 100644
index 0000000000..6299140e35
--- /dev/null
+++ b/doc/design/assistant/blog/day_204__deprocrastination.mdwn
@@ -0,0 +1,62 @@
+Tracked down the bug that's been eluding me for days. It was indeed a race, and
+could result in a file being transferred into a direct mode repository and
+ending up in indirect mode. Was easy to fix once understood, just needed to
+update the direct mode mapping before starting the transfer.
+
+While I was in there, I noticed another potential race, also in direct
+mode, where the watcher could decide to rewrite a symlink to fix its
+target, and at just the wrong time direct mode content could arrive in its
+place, and so get deleted. Fixed that too.
+
+Seems likely there are some other direct mode races. I spent quite a while
+hammering on dealing with the indirect mode races with the assistant 
+originally.
+
+-----
+
+Next on my list is revisiting XMPP.
+
+Verified that git push over XMPP works between multiple repositories that
+are sharing the same XMPP account. It does.
+
+Seeing the XMPP setup process with fresh eyes, I found several places
+wording could be improved. Also, when the user goes in and configures 
+(or reconfigures) an XMPP account, the next step is to do pairing,
+so it now redirects directly to there.
+
+Next I need to make XMPP get back into sync after a network disconnection
+or when the assistant is restarted. This currently doesn't happen until
+a XMPP push is received due to a new change being made.
+
+### back burner: yesod-pure
+
+Last night I made a yesod-pure branch, and did some exploratory conversion
+away from using Hamlet, of the Preferences page I built yesterday.
+
+I was actually finding writing pure Blaze worked *better* than Hamlet,
+at first. Was able to refactor several things into functions that in Hamlet
+are duplicated over and over in my templates, and built some stuff that makes
+rendering type safe urls in pure Blaze not particularly ungainly. For example,
+this makes a submit button and a cancel button that redirects to another page:
+
+[[!format haskell """
+        buttons = toWidget $ \redir ->
+               "Save Preferences" <>|<> redir ConfigurationR []
+"""]]
+
+The catch is how to deal with widgets that need to be nested inside other
+html. It's not possible to do this both cleanly and maximally
+efficiently, with Blaze. For max efficiency, all the html before the widget
+should be emitted, and then the widget run, and then all html after it be
+emitted. To use Blaze, it would have to instead generate the full html,
+then split it around the widget, and then emit the parts, which is less
+efficient, doesn't stream, etc.
+
+I guess that's the core of what Hamlet does; it allows a clean
+representation and due to running TH at build time, can convert this into
+an efficient (but ugly) html emitter.
+
+So, I may give up on this experiment. Or I may make the webapp less than
+maximally fast at generating html and go on with it. After all, these
+sorts of optimisations are mostly aimed at high-volume websites, not local
+webapps.
diff --git a/doc/design/assistant/blog/day_205_206__rainy_day__snow_day.mdwn b/doc/design/assistant/blog/day_205_206__rainy_day__snow_day.mdwn
new file mode 100644
index 0000000000..e1d07c8e42
--- /dev/null
+++ b/doc/design/assistant/blog/day_205_206__rainy_day__snow_day.mdwn
@@ -0,0 +1,12 @@
+Yesterday was all bug fixes, nothing to write about really.
+
+Today I've been working on getting XMPP remotes to sync more reliably.
+I left some big holes when I stopped work on it in November:
+
+1. The assistant did not sync with XMPP remotes when it started up.
+2. .. Or when it detected a network reconnection.
+3. There was no way to trigger a full scan for transfers
+   after receiving a push from an XMPP remote.
+
+The asynchronous nature of git push over XMPP complicated doing this, but
+I've solved all 3 issues today.
diff --git a/doc/design/assistant/blog/day_207__XMPP.mdwn b/doc/design/assistant/blog/day_207__XMPP.mdwn
new file mode 100644
index 0000000000..8419905f16
--- /dev/null
+++ b/doc/design/assistant/blog/day_207__XMPP.mdwn
@@ -0,0 +1,7 @@
+More XMPP fixes. The most important change is that it now stores important
+messages, like push requests, and (re)sends them when a buddy's client
+sends XMPP presence. This makes XMPP syncing much more robust, all the
+clients do not need to already be connected when messages are initially
+sent, but can come and go. Also fixed a bug preventing syncing from working
+immediately after XMPP pairing. XMPP seems to be working well now; I only
+know of one minor bug.
diff --git a/doc/design/assistant/blog/day_208__bugfixes.mdwn b/doc/design/assistant/blog/day_208__bugfixes.mdwn
new file mode 100644
index 0000000000..41874b9184
--- /dev/null
+++ b/doc/design/assistant/blog/day_208__bugfixes.mdwn
@@ -0,0 +1,17 @@
+Fixed the last XMPP bug I know of. Turns out it was not specific to XMPP at
+all; the assistant could forget to sync with any repository on startup
+under certain conditions.
+
+Also fixed bugs in `git annex add` and in the glob matching, and some more.
+
+I've been working on some screencasts. More on them later.. But while doing
+them I found a perfect way to reliably reproduce the webapp hang that
+I've been chasing for half a year, and last saw at my presentation in
+Australia. Seems the old joke about bugs only reproducible during
+presentations is literally true here!
+
+I have given this bug its [[own page|bugs/webapp_hang]] at last, and have a
+tcpdump of it happening and everything. Am working on an hypotheses that it
+might be caused by Warp's [slowloris](http://ha.ckers.org/slowloris/)
+attack prevention code being falsely triggered by the repeated hits the web
+browser makes as the webapp's display is updated.
diff --git a/doc/design/assistant/blog/day_209__The_Bug.mdwn b/doc/design/assistant/blog/day_209__The_Bug.mdwn
new file mode 100644
index 0000000000..b2e87fd8fd
--- /dev/null
+++ b/doc/design/assistant/blog/day_209__The_Bug.mdwn
@@ -0,0 +1,23 @@
+> And so we waited. Tick-tock, blink-blink, thirty seconds stretched
+> themselves out one by one, a hole in human experience. -- The Bug
+
+I *think* I've managed to fully track down the [[webapp_hang]]. It is,
+apparently, a bug in the Warp web server's code intended to protect against
+the [Slowloris](http://ha.ckers.org/slowloris/) attack. It assumes,
+incorrectly, that a web browser won't reuse a connection it's left idle for
+30 seconds. Some bad error handling keeps a connection open with no thread
+to service it, leading to the hang.
+<https://github.com/yesodweb/wai/issues/146>
+
+Have put a 30 minute timeout into place as a workaround, and, unless
+a web browser sits on an idle connection for a full 30 minutes and then
+tries to reuse it, this should be sufficient.
+
+I was chasing that bug, quietly, for 6 months. Would see it now and
+then, but not be able to reproduce it or get anywhere with analysis.
+I had nearly given up. If you enjoy stories like that, read Ellen
+Ullman's excellent book The Bug.
+
+> To discover that between the blinks of the machine’s shuttered eye—going
+> on without pause or cease; simulated, imagined, but still not caught—was
+> life.
diff --git a/doc/design/assistant/blog/day_20__data_transfer_design.mdwn b/doc/design/assistant/blog/day_20__data_transfer_design.mdwn
new file mode 100644
index 0000000000..4f47ae63c4
--- /dev/null
+++ b/doc/design/assistant/blog/day_20__data_transfer_design.mdwn
@@ -0,0 +1,22 @@
+Today is a planning day. I have only a few days left before I'm off to
+Nicaragua for [DebConf](http://debconf12.debconf.org/), where I'll only
+have smaller chunks of time without interruptions. So it's important to get
+some well-defined smallish chunks designed that I can work on later. See
+bulleted action items below (now moved to [[syncing]]. Each
+should be around 1-2 hours unless it turns out to be 8 hours... :)
+
+First, worked on writing down a design, and some data types, for data transfer
+tracking (see [[syncing]] page). Found that writing down these simple data
+types before I started slinging code has clarified things a lot for me.
+
+Most importantly, I realized that I will need to modify `git-annex-shell`
+to record on disk what transfers it's doing, so the assistant can get that
+information and use it to both avoid redundant transfers (potentially a big
+problem!), and later to allow the user to control them using the web app.
+
+While eventually the user will be able to use the web app to prioritize
+transfers, stop and start, throttle, etc, it's important to get the default
+behavior right. So I'm thinking about things like how to prioritize uploads
+vs downloads, when it's appropriate to have multiple downloads running at
+once, etc.
+
diff --git a/doc/design/assistant/blog/day_210__spring.mdwn b/doc/design/assistant/blog/day_210__spring.mdwn
new file mode 100644
index 0000000000..ff34cfbfe0
--- /dev/null
+++ b/doc/design/assistant/blog/day_210__spring.mdwn
@@ -0,0 +1,29 @@
+Trying to record screencasts demoing the assistant is really helping me
+see things that need to be fixed.
+
+Got the version of the haskell TLS library in Debian fixed, backporting
+some changes to fix a botched security fix that made it reject all
+certificates. So WebDAV special remotes will work again on the next release.
+
+Fixed some more problems around content being dropped when files are
+moved to archive directories, and gotten again when files are
+moved out.
+
+Fixed some problems around USB drives. One was a real jaw-dropping
+bug: "git annex drop --from usbdrive" when the drive was not
+connected still updated the location log to indicate it did not have
+the file anymore! (Thank goodness for fsck..)
+
+I've noticed that moving around files in direct mode repos is inneficient,
+because the assistant re-checksums the "new" file. One way to avoid
+that would be to have a lookup table from (inode, size, mtime) to
+key, but I don't have one, and would like to avoid adding one.
+
+Instead, I have a cunning plan to deal with this heuristically. If the
+assistant can notice a file was removed and another file added at the same
+time, it can compare the (inode, size, mtime) to see if it's a rename, and
+avoid the checksum overhead.
+
+The first step to getting there was to make the assistant better at
+batching together delete+add events into a single rename commit. I'm happy
+to say I've accomplished that, with no perceptable delay to commits.
diff --git a/doc/design/assistant/blog/day_211__zooming_along.mdwn b/doc/design/assistant/blog/day_211__zooming_along.mdwn
new file mode 100644
index 0000000000..fb87077bef
--- /dev/null
+++ b/doc/design/assistant/blog/day_211__zooming_along.mdwn
@@ -0,0 +1,24 @@
+Got renaming fully optimised in the assistent in direct mode. I even got it
+to work for whole directory renames. I can drag files around all day in the
+file manager and the assistant often finishes committing the rename before
+the file manager updates. So much better than checksumming every single
+renamed file! Also, this means the assistant makes just 1 commit when a
+whole directory is renamed.
+
+Last night I added a feature to `git annex status`. It can now be asked to
+only show the status of a single directory, rather than the whole annex.
+All the regular file filtering switches work, so some neat commands
+are possible. I like `git annex status . --in foo --not --in bar` to see
+how much data is in one remote but not another.
+
+This morning, an important thought about [[bugs/smarter_flood_filling]],
+that will avoid unnecessary uploads to transfer remotes when all that's
+needed to get the file to its destination is a transfer over the LAN.
+I found an easy way to make that work, at least in simple cases.
+Hoping to implement it soon.
+
+Less fun, direct mode turns out to be somewhat buggy when files with
+duplicate content are in the repository. Nothing fails, but `git annex
+sync` will re-checksum files each time it's run in this situation, and the
+assistant will re-checksum files in certian cases. Need to work on this
+soon too.
diff --git a/doc/design/assistant/blog/day_212__accidental_all_nighter.mdwn b/doc/design/assistant/blog/day_212__accidental_all_nighter.mdwn
new file mode 100644
index 0000000000..600522d14a
--- /dev/null
+++ b/doc/design/assistant/blog/day_212__accidental_all_nighter.mdwn
@@ -0,0 +1,24 @@
+Last night, revamped the web site, including making a [[/videos]]
+page, which includes a new screencast introducing the git-annex assistant.
+
+Worked on improving my Haskell development environment in vim.
+hdevtools is an excellent but tricky thing to get working. Where before
+it took around 30 seconds per compile for me to see type errors,
+I now see them in under a second each time I save, and can also look up
+types of any expression in the file. Since programming in Haskell is
+mostly driven by reacting to type errors ;) this should speed me up a lot,
+although it's not perfect. Unfortunatly, I got really caught up in tuning
+my setup, and only finished doing that at 5:48 am.
+
+Disasterously late this morning, fixed the assistant's
+`~/.ssh/git-annex-shell` wrapper so it will work when the ssh key does
+not force a command to be run. Also made the webapp behave better
+when it's told to create a git repository that already exists.
+
+After entirely too little sleep, I found a puzzling bug where copying files
+to a local repo fails once the inode cache has been invalidated. This
+turned out to involve running a check in the state monad of the wrong
+repository. A failure mode I'd never encountered before.
+
+Only thing I had brains left to do today was to record another screencast,
+which is rendering now...
diff --git a/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_1_6ee1f8056eedb6eb18013faf8f5ec212._comment b/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_1_6ee1f8056eedb6eb18013faf8f5ec212._comment
new file mode 100644
index 0000000000..6ad0ab2354
--- /dev/null
+++ b/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_1_6ee1f8056eedb6eb18013faf8f5ec212._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl1D_4vD5ueaDw8gRsIYPO3UHRKEpFfg9I"
+ nickname="Дмитрий"
+ subject="About development in Vim"
+ date="2013-03-13T02:18:20Z"
+ content="""
+Could you describe your vim configuration for haskell development, what plugins do you use, what is in you .vimrc file and maybe even record a screencast of typical \"session\" of work?
+"""]]
diff --git a/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_2_07c83d75bb105bb77ada07359ed0ea7a._comment b/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_2_07c83d75bb105bb77ada07359ed0ea7a._comment
new file mode 100644
index 0000000000..06aae6e1b7
--- /dev/null
+++ b/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_2_07c83d75bb105bb77ada07359ed0ea7a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmU_2tE75oyG0h2ZPN4lcroIKEMC8G-otE"
+ nickname="Michael"
+ subject="Global preferences?"
+ date="2013-03-13T08:00:55Z"
+ content="""
+I just did a \"cabal install git-annex --bindir=$HOME/bin\" on Ubuntu 12.10 and I don't see the global preferences (where you configure the autostart etc.) from the screencast. How can I enable this?
+"""]]
diff --git a/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_3_2c904d33f4f14807fbe718a01e98800a._comment b/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_3_2c904d33f4f14807fbe718a01e98800a._comment
new file mode 100644
index 0000000000..943bd52778
--- /dev/null
+++ b/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_3_2c904d33f4f14807fbe718a01e98800a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-03-13T16:08:35Z"
+ content="""
+The global preferences page is a new feature that will be in the next release. You can use a daily build or build from source to try it now.
+"""]]
diff --git a/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_4_59ec5c1cab75df87293800a7a03fe9c6._comment b/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_4_59ec5c1cab75df87293800a7a03fe9c6._comment
new file mode 100644
index 0000000000..c3e8f83515
--- /dev/null
+++ b/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_4_59ec5c1cab75df87293800a7a03fe9c6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmU_2tE75oyG0h2ZPN4lcroIKEMC8G-otE"
+ nickname="Michael"
+ subject="comment 4"
+ date="2013-03-13T16:34:46Z"
+ content="""
+Build from source is too hard for a non-haskell developer, I run into various errors I can not resolve. The daily build gives me \"git-annex: error while loading shared libraries: libyaml-0.so.2: cannot open shared object file: No such file or directory\". For Ubuntu a PPA with daily build would be handy.
+"""]]
diff --git a/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_5_13893f106e835dcc52e03c7c6740c35b._comment b/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_5_13893f106e835dcc52e03c7c6740c35b._comment
new file mode 100644
index 0000000000..8c6419b1c3
--- /dev/null
+++ b/doc/design/assistant/blog/day_212__accidental_all_nighter/comment_5_13893f106e835dcc52e03c7c6740c35b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 5"
+ date="2013-03-13T16:58:04Z"
+ content="""
+In the standalone linux daily build, you need to use the \"runshell\" script to start a shell environment in which you can run git-annex.
+"""]]
diff --git a/doc/design/assistant/blog/day_213__costs.mdwn b/doc/design/assistant/blog/day_213__costs.mdwn
new file mode 100644
index 0000000000..41517a7ab1
--- /dev/null
+++ b/doc/design/assistant/blog/day_213__costs.mdwn
@@ -0,0 +1,34 @@
+Got the assistant to check again, just before starting a transfer, if
+the remote still wants the object. This should be all that's needed to
+handle the case where there is a transfer remote on the internet somewhere,
+and a locally paired client on the LAN. As long as the paired repository
+has a lower cost value, it will be sent any new file first, and if that
+is the only client, the file will not be sent to the transfer remote at
+all.
+
+But.. locally paired repos did not have a lower cost set, at all.
+So I made their cost be set to 175 when they're created. Anyone
+who already did local pairing should make sure the Repositories
+list shows locally paired repositories above transfer remotes.
+
+Which brought me to needing an easy way to reorder that list of remotes,
+which I plan to do by letting the user drag and drop remotes around,
+which will change their cost accordingly. Implementing that has two
+pain points:
+
+1. Often a lot of remotes will have the same default cost value.
+   So how to insert a remote in between two that have cost 100?
+   This would be easy if git-annex didn't have these cost numbers,
+   and instead just had an ordered list of remotes.. but it doesn't.
+   Instead, dragging remotes in the list will sometimes need to change
+   the costs of others, to make room to insert them in. It's BASIC
+   renumbering all over again. So I wrote some code to do this with as
+   little bother as possible.
+
+2. Drag and drop means javascript. I got the basics going quickly with
+   jquery-ui, only to get stuck for over an hour on some CSS issue
+   that made lines from the list display all weird while being dragged.
+   It is always something like this with javascript..
+
+So I've got these 2 peices working, and even have the AJAX call
+firing, but it's not quite wired up just yet. Tomorrow.
diff --git a/doc/design/assistant/blog/day_214__release_day.mdwn b/doc/design/assistant/blog/day_214__release_day.mdwn
new file mode 100644
index 0000000000..2ada213086
--- /dev/null
+++ b/doc/design/assistant/blog/day_214__release_day.mdwn
@@ -0,0 +1,5 @@
+Fighting with javascript all day and racing to get a release out. Unstuck
+the OSX and Android autobuilders. Got drag and drop repository list
+reordering working great. Tons of changes in this release!
+
+Also put up a new podcast.
diff --git a/doc/design/assistant/blog/day_215__dashboard_UI_refresh.mdwn b/doc/design/assistant/blog/day_215__dashboard_UI_refresh.mdwn
new file mode 100644
index 0000000000..9381ebee20
--- /dev/null
+++ b/doc/design/assistant/blog/day_215__dashboard_UI_refresh.mdwn
@@ -0,0 +1,25 @@
+I've reworked the UI of the webapp's dashboard. Now the repository list is
+included, above the transfers. I found I was spending a lot of time
+switching between the dashboard and repository list, so might as well
+combine them into a single screen. Yesod's type safe urls and widgets
+made this quite easy to do, despite it being a thousand line commit.
+Liking the result ... Even though it does make all my screencasts dated.
+
+[[!img /assistant/dashboard.png]]
+
+----
+
+Rest of my time was spent on XMPP pairing UI. Using the same pages for both
+pairing with a friend and for self-pairing was confusing, so now the two
+options are split.
+
+Now every time an XMPP git push is received or sent, it checks if there's
+a cloud repository configured, which is needed to send the contents of
+files. If not, it'll display this alert. Hopefully this
+will be enough to get users fully set up.
+
+[[!img /assistant/cloudnudge.png]]
+
+At this point I'm finally happy enough with the XMPP pairing + cloud
+repository setup process to film a screencast of it. As soon as I have
+some time & bandwidth someplace quiet. Expect one by the end of the month.
diff --git a/doc/design/assistant/blog/day_216__more_bugfixes.mdwn b/doc/design/assistant/blog/day_216__more_bugfixes.mdwn
new file mode 100644
index 0000000000..a988643ff2
--- /dev/null
+++ b/doc/design/assistant/blog/day_216__more_bugfixes.mdwn
@@ -0,0 +1,42 @@
+A long time ago I made Remote be an instance of the Ord typeclass, with an
+implementation that compared the costs of Remotes. That seemed like a good
+idea at the time, as it saved typing.. But at the time I was still making
+custom Read and Show instances too. I've since learned that this is *not* a
+good idea, and neither is making custom Ord instances, without deep thought
+about the possible sets of values in a type.
+
+This Ord instance came around and bit me when I put Remotes into a Set,
+because now remotes with the same cost appeared to be in the Set even if 
+they were not. Also affected putting Remotes into a Map. I noticed this
+when the webapp got confused about which Remotes were paused.
+
+Rarely does a bug go this deep. I've fixed it comprehensively, first
+removing the Ord instance entirely, and fixing the places that wanted to
+order remotes by cost to do it explicitly. Then adding back an Ord instance
+that is much more sane. Also by checking the rest of the Ord (and Eq) 
+instances in the code base (which were all ok).
+
+While doing that, I found lots of places that kept remotes in Maps and
+Sets. All of it was probably subtly broken in one way or another before
+this fix, but it would be hard to say exactly how the bugs would
+manifest.
+
+-----
+
+Also fought some with Google Talk today. Seem to be missing presence
+messages sometimes. Ugh. May have fixed it, but I've thought that before..
+
+Made --debug include a sanitized dump of the XMPP protocol.
+
+Made UI changes to encourage user to install git-annex on the server when
+adding a ssh server, rather than just funneling them through to rsync.
+
+Fixed UI glitches in XMPP username/password prompt.
+
+Switched all forms in the webapp to use POST, to avoid sensitive
+information leaking on the url bar.
+
+----
+
+Added an incremental backup group. Repositories in this group only want
+files that have not been backed up somewhere else yet.
diff --git a/doc/design/assistant/blog/day_216__more_bugfixes/comment_1_299462bcdd0e4f6cd7895b5f40ca00ad._comment b/doc/design/assistant/blog/day_216__more_bugfixes/comment_1_299462bcdd0e4f6cd7895b5f40ca00ad._comment
new file mode 100644
index 0000000000..7d28cfdbf8
--- /dev/null
+++ b/doc/design/assistant/blog/day_216__more_bugfixes/comment_1_299462bcdd0e4f6cd7895b5f40ca00ad._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnR7hb8IaKB3IKZptRukje0yahmhfLOO98"
+ nickname="Adam"
+ subject="comment 1"
+ date="2013-03-17T00:30:26Z"
+ content="""
+> Made UI changes to encourage user to install git-annex on the server when adding a ssh server, rather than just funneling them through to rsync.
+
+What's the difference between having git-annex available versus not?
+"""]]
diff --git a/doc/design/assistant/blog/day_216__more_bugfixes/comment_2_1913d65dfe4ba08379d82a4a2ca91c40._comment b/doc/design/assistant/blog/day_216__more_bugfixes/comment_2_1913d65dfe4ba08379d82a4a2ca91c40._comment
new file mode 100644
index 0000000000..200846545c
--- /dev/null
+++ b/doc/design/assistant/blog/day_216__more_bugfixes/comment_2_1913d65dfe4ba08379d82a4a2ca91c40._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnxp2XU8gIribhhGhGuYtU6eMMwHv5gUGI"
+ nickname="Amitai"
+ subject="Google Talk silently drops non-Google invites (at least)"
+ date="2013-03-17T13:44:18Z"
+ content="""
+Have you seen <http://www.fsf.org/blogs/sysadmin/google-backslides-on-federated-instant-messaging-on-purpose>? Maybe they're also doing other funny stuff that gets in your way.
+"""]]
diff --git a/doc/design/assistant/blog/day_216__more_bugfixes/comment_3_92c774599a78540ad398afcd1d05f7ce._comment b/doc/design/assistant/blog/day_216__more_bugfixes/comment_3_92c774599a78540ad398afcd1d05f7ce._comment
new file mode 100644
index 0000000000..05847a73b7
--- /dev/null
+++ b/doc/design/assistant/blog/day_216__more_bugfixes/comment_3_92c774599a78540ad398afcd1d05f7ce._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnR7hb8IaKB3IKZptRukje0yahmhfLOO98"
+ nickname="Adam"
+ subject="comment 3"
+ date="2013-03-25T01:58:23Z"
+ content="""
+About the UI prompt for the webapp:
+
+> What's the difference between having git-annex available versus not?
+
+I can see from the UI that if you make it be a git repository, you get this:
+
+> All your data will be uploaded to the server, including the full git repository. This is a great choice if you want to set up other devices to use the same server, or share the repository with others.
+
+Versus an rsync repo:
+
+> The contents of your files will be stored, fully encrypted, on the server. The server will not store other information about your git repository. This is the best choice if you don't run the server yourself, or have sensitive data.
+
+Unfortunately I'm looking for a shared server (as per the git repo description), but **also fully encrypted** because I'll be storing sensitive data.
+"""]]
diff --git a/doc/design/assistant/blog/day_217__nothing.mdwn b/doc/design/assistant/blog/day_217__nothing.mdwn
new file mode 100644
index 0000000000..95deabd238
--- /dev/null
+++ b/doc/design/assistant/blog/day_217__nothing.mdwn
@@ -0,0 +1,2 @@
+Is what I planned to do on git-annex today. Instead I fixed several bugs,
+but I'm drawing the line at blogging. Oops.
diff --git a/doc/design/assistant/blog/day_219__bug_triage.mdwn b/doc/design/assistant/blog/day_219__bug_triage.mdwn
new file mode 100644
index 0000000000..82494ceca8
--- /dev/null
+++ b/doc/design/assistant/blog/day_219__bug_triage.mdwn
@@ -0,0 +1,14 @@
+Triaged some of the older bugs and was able to close a lot of them.
+
+-----
+
+Should mention that I will be in Boston this weekend, attending
+[LibrePlanet 2013](http://libreplanet.org/wiki/LibrePlanet:Conference/2013).
+Drop by and find me, I'll have git-annex stickers! ;)
+
+-----
+
+Did some UI work on the webapp. Minor stuff, but stuff that needed to be
+fixed up. Like inserting zero-width spaces into filenames displayed in it
+so very long filenames always get reasonably wrapped by the browser.
+(Perhaps there's a better way to do that with CSS?)
diff --git a/doc/design/assistant/blog/day_219__bug_triage/comment_1_c6b977a969cacdce62987a439b7686f5._comment b/doc/design/assistant/blog/day_219__bug_triage/comment_1_c6b977a969cacdce62987a439b7686f5._comment
new file mode 100644
index 0000000000..5722f7e19d
--- /dev/null
+++ b/doc/design/assistant/blog/day_219__bug_triage/comment_1_c6b977a969cacdce62987a439b7686f5._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://jasonwoof.com/"
+ nickname="JasonWoof"
+ subject="wrapping css"
+ date="2013-03-20T20:28:04Z"
+ content="""
+You can do this in css:
+
+    word-wrap: break-word;
+
+That should make the text not leave the box. Not sure if this makes it break \"reasonably\" though, eg a two letter word followed by an 200 letter \"word\" would probably leave the two letter word on a line by itself.
+
+Worth a try though.
+
+Seems to be well supported on browsers: [http://caniuse.com/#search=wrap](http://caniuse.com/#search=wrap)
+"""]]
diff --git a/doc/design/assistant/blog/day_21__transfer_tracking.mdwn b/doc/design/assistant/blog/day_21__transfer_tracking.mdwn
new file mode 100644
index 0000000000..79c0b64387
--- /dev/null
+++ b/doc/design/assistant/blog/day_21__transfer_tracking.mdwn
@@ -0,0 +1,28 @@
+Worked today on two action items from my last blog post:
+
+* on-disk transfers in progress information files (read/write/enumerate)
+* locking for the files, so redundant transfer races can be detected,
+  and failed transfers noticed
+
+That's all done, and used by the `get`, `copy`, and `move` subcommands.
+
+Also, I made `git-annex status` use that information to display any
+file transfers that are currently in progress:
+
+	joey@gnu:~/lib/sound/misc>git annex status
+	[...]
+	transfers in progress: 
+		downloading Vic-303.mp3 from leech
+
+(Webapp, here we come!)
+
+However... Files being sent or received by `git-annex-shell` don't yet
+have this transfer info recorded. The problem is that to do so,
+`git-annex-shell` will need to be run with a `--remote=` parameter. But
+old versions will of course fail when run with such an unknown parameter.
+
+This is a problem I last faced in December 2011 when adding the `--uuid=`
+parameter. That time I punted and required the remote `git-annex-shell` be
+updated to a new enough version to accept it. But as git-annex gets more widely
+used and packaged, that's becoming less an option. I need to find a real
+solution to this problem.
diff --git a/doc/design/assistant/blog/day_220__performance.mdwn b/doc/design/assistant/blog/day_220__performance.mdwn
new file mode 100644
index 0000000000..a1b7b329ac
--- /dev/null
+++ b/doc/design/assistant/blog/day_220__performance.mdwn
@@ -0,0 +1,40 @@
+I've been running some large transfers with the assistant, and looking at
+ways to improve performance. (I also found and fixed a zombie process
+leak.)
+
+----
+
+One thing I noticed is that the assistant pushes changes to the git-annex
+location log quite frequently during a batch transfer. If the files being
+transferred are reasonably sized, it'll be pushing once per file transfer. 
+It would be good to reduce the number of pushes, but the pushes are
+important in some network topologies to inform other nodes
+when a file gets near to them, so they can get the file too.
+
+Need to see if I can find a smart way to avoid some of the pushes.
+For example, if we've just downloaded a file, and are queuing uploads
+of the file to a remote, we probably don't need to push the git-annex
+branch to the remote.
+
+----
+
+Another performance problem is that having the webapp open while transfers
+are running uses significant CPU just for the browser to update the progress
+bar. Unsurprising, since the webapp is sending the browser a new `<div>`
+each time. Updating the DOM instead from javascript would avoid that;
+the webapp just needs to send the javascript either a full `<div>` or a
+changed percentage and quantity complete to update a single progress bar.
+
+I'd prefer to wait on doing that until I'm able to use Fay to generate
+Javascript from Haskell, because it would be much more pleasant.. will see.
+
+----
+
+Also a performance problem when performing lots of transfers, particularly
+of small files, is that the assistant forks off a `git annex transferkey`
+for each transfer, and that has to in turn start up several git commands.
+
+Today I have been working to change that, so the assistant maintains a
+pool of transfer processes, and dispatches each transfer it wants to make
+to a process from the pool. I just got all that to build, although untested
+so far, in the `transferpools` branch.
diff --git a/doc/design/assistant/blog/day_221__this_and_that.mdwn b/doc/design/assistant/blog/day_221__this_and_that.mdwn
new file mode 100644
index 0000000000..87406547e5
--- /dev/null
+++ b/doc/design/assistant/blog/day_221__this_and_that.mdwn
@@ -0,0 +1,28 @@
+Was unsure yesterday if my transferrer pools code would just work, or
+would be horribly broken and need a lot of work to get going. It was a
+complex change involving both high-level STM code and low-level pipes and
+fds. Well, it almost worked 100% first time, I just had a minor issue in
+my fd setup to fix. Everything else seems to work perfectly.
+Very happy how that went!
+
+----
+
+Improved support and documentation for using the OSX app and Linux
+standalone tarball at the command line. Now it's sufficient to just put
+their directory into `PATH`, rather than using `runshell`.
+
+----
+
+The webapp's form for adding a removable drive now allows specifying the
+directory to use within the drive (default "annex").
+
+When the drive's repository already exists, and it's not a repository
+that git-annex knows about, it confirms that the user wants
+to combine its contents into their repository.
+
+
+(Should probably implement this same check when adding a ssh remote.)
+
+----
+
+Off to Boston!
diff --git a/doc/design/assistant/blog/day_222__back.mdwn b/doc/design/assistant/blog/day_222__back.mdwn
new file mode 100644
index 0000000000..9c3c17094e
--- /dev/null
+++ b/doc/design/assistant/blog/day_222__back.mdwn
@@ -0,0 +1,16 @@
+Back from my trip. Spent today getting caught up.
+
+Didn't do much while I was away. Pushed out a new release on Saturday.
+Made `git annex` usage display nicer.
+
+Fixed some minor webapp bugs today. The interesting bug was a
+race that sometimes caused alerts or other notifications to be
+missed and not be immediately displayed if they occurred while
+a page was loading. You sometimes had to hit reload to see them,
+but not anymore!
+
+Checked if the `push.default=simple` change in upcoming git release will
+affect git-annex. It shouldn't affect the assistant, or `git annex sync`,
+since they always list all branches to push explicitly. But if you `git push`
+manually, when the default changes that won't include the git-annex branch
+in the push any longer.
diff --git a/doc/design/assistant/blog/day_222__back/comment_1_f05b48231a1ee0cffba7d66e112e5551._comment b/doc/design/assistant/blog/day_222__back/comment_1_f05b48231a1ee0cffba7d66e112e5551._comment
new file mode 100644
index 0000000000..f788cc283f
--- /dev/null
+++ b/doc/design/assistant/blog/day_222__back/comment_1_f05b48231a1ee0cffba7d66e112e5551._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7AuSfii_tCkLyspL6Mr0ATlO6OxLNYOo"
+ nickname="Georg"
+ subject="something for the wishlist maybe?"
+ date="2013-03-28T08:30:00Z"
+ content="""
+Something I was wondering with the assistant now getting really smart: would it be possible to have a cli-mode for the assistant that runs in the forground and only until there is nothing to do anymore? Something like a single-run-assistant`? Reason being that in my usecases most often I know exactly when the right moment for a run is - for example after processing a bunch of photographs - and I most definitely don't want a background process to work on those photographs while I do work on them. Or with archival media, I know when I will hook up the archive drives. In allmost all of my scenarios it would be much easier to not run the assistant in the background, but to fire it from the cli at the right moments, letting it work over night and have it shut down automatically when all is synced.
+"""]]
diff --git a/doc/design/assistant/blog/day_222__back/comment_2_4d5f003ccd81580017ebf0dc31bc9cda._comment b/doc/design/assistant/blog/day_222__back/comment_2_4d5f003ccd81580017ebf0dc31bc9cda._comment
new file mode 100644
index 0000000000..cc28d56086
--- /dev/null
+++ b/doc/design/assistant/blog/day_222__back/comment_2_4d5f003ccd81580017ebf0dc31bc9cda._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-03-28T15:50:47Z"
+ content="""
+That's an interesting thought. I think it would be hard to find a clear condition when it was done and could shut down. While there is easy visibility into the transfer queue to tell when file transfers are done, it's harder to tell when it's actively syncing git repositories or scanning for transfers to do, or finding new files to commit. Each thread knows what it's doing, but none of the other threads do. Maybe active threads could hold a lock to indicate they're busy, and this combined with visibility into the various work queues could do the job.
+"""]]
diff --git a/doc/design/assistant/blog/day_223__progress_revisited.mdwn b/doc/design/assistant/blog/day_223__progress_revisited.mdwn
new file mode 100644
index 0000000000..9f899899db
--- /dev/null
+++ b/doc/design/assistant/blog/day_223__progress_revisited.mdwn
@@ -0,0 +1,24 @@
+Went out and tried for the second time to record a screencast demoing
+setting up syncing between two computers using just Jabber and a cloud
+remote. I can't record this one at home, or viewers would think git-annex
+was crazy slow, when it's just my dialup. ;) But once again I encountered
+bugs, and so I found myself working on progress bars today, unexpectedly.
+
+Seems there was confusion in different parts of the progress bar code
+about whether an update contained the total number of bytes transferred, or
+the delta of bytes transferred since the last update. One way this bug
+showed up was progress bars that seemed to stick at 0% for a long time.
+Happened for most special remotes, although not for rsync or git remotes.
+In order to fix it comprehensively, I added a new BytesProcessed data type,
+that is explicitly a total quantity of bytes, not a delta. And checked and
+fixed all the places that used a delta as that type was knitted into
+the code.
+
+(Note that this doesn't necessarily fix every problem with progress bars.
+Particularly, buffering can now cause progress bars to seem to run ahead
+of transfers, reaching 100% when data is still being uploaded. Still,
+they should be a lot better than before.)
+
+I've just successfully run through the Jabber + Cloud remote setup process
+again, and it seems to be working great now. Maybe I'll still get the
+screencast recorded by the end of March.
diff --git a/doc/design/assistant/blog/day_224__annex.largefiles.mdwn b/doc/design/assistant/blog/day_224__annex.largefiles.mdwn
new file mode 100644
index 0000000000..4fab93fb65
--- /dev/null
+++ b/doc/design/assistant/blog/day_224__annex.largefiles.mdwn
@@ -0,0 +1,23 @@
+Built a feature for power users today. `annex.largefiles` can be
+configured to specify what files `git annex add` and the assistant should
+put into the annex. It uses the same syntax as [[/preferred_content]],
+so arbitrarily complex expressions can be built.
+
+For example, a game written in C with some large data files could
+include only 100kb or larger files, that are not C code:
+
+	annex.largefiles = largerthan=100kb and not (include=*.c or include=*.h) 
+
+The assistant will commit small files to git directly!
+`git annex add`, being a lower level tool, skips small files
+and leaves it up to you to `git add` them as desired.
+
+It's even possible to tell the assistant that no file is too large to be
+committed directly to git. `git config annex.largefiles 'exclude=*'`
+The result should be much like using SparkleShare or dvcs-autosync.
+
+-----
+
+Also today, made the remote ssh server checking code in the webapp
+deal with servers where the default shell is csh or some other non-POSIX
+shell.
diff --git a/doc/design/assistant/blog/day_224__annex.largefiles/comment_1_408e4021b18f7ff5548d2d19ab558922._comment b/doc/design/assistant/blog/day_224__annex.largefiles/comment_1_408e4021b18f7ff5548d2d19ab558922._comment
new file mode 100644
index 0000000000..370f599c27
--- /dev/null
+++ b/doc/design/assistant/blog/day_224__annex.largefiles/comment_1_408e4021b18f7ff5548d2d19ab558922._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7AuSfii_tCkLyspL6Mr0ATlO6OxLNYOo"
+ nickname="Georg"
+ subject="Great idea! "
+ date="2013-03-30T08:00:16Z"
+ content="""
+This will be perfect for my raw image pool! I use Lightroom, so my photos are only imported once and only in case of DNG are they actually changed, in all other formats LR creates little sidecar XML files with processing instructions. So with this change the side car files can actually be fully Versionen and lage files are kept out of the repo and handled by archiving with annex. Cool! 
+"""]]
diff --git a/doc/design/assistant/blog/day_224__annex.largefiles/comment_2_b24d1da2bc4307ded0216daffb8f9336._comment b/doc/design/assistant/blog/day_224__annex.largefiles/comment_2_b24d1da2bc4307ded0216daffb8f9336._comment
new file mode 100644
index 0000000000..14fdfed5ce
--- /dev/null
+++ b/doc/design/assistant/blog/day_224__annex.largefiles/comment_2_b24d1da2bc4307ded0216daffb8f9336._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWBvsZvSsAL8P2ye3F0OBStjFCVnOImzM"
+ nickname="Jarno"
+ subject="Making &quot;git-annex add&quot; commit largefiles, too?"
+ date="2013-10-31T00:26:21Z"
+ content="""
+Is it possible to make `git annex add` also *not* skip largefiles but do an automatic `git add` instead? I'd like to keep .txt, .sh and the like in git directly (for easier diffing) but having to add them separately sounds like trouble.
+"""]]
diff --git a/doc/design/assistant/blog/day_225__back_from_the_dead.mdwn b/doc/design/assistant/blog/day_225__back_from_the_dead.mdwn
new file mode 100644
index 0000000000..e550c6b8b8
--- /dev/null
+++ b/doc/design/assistant/blog/day_225__back_from_the_dead.mdwn
@@ -0,0 +1,47 @@
+I've posted a poll: [[polls/goals_for_April]]
+
+----
+
+Today added UI to the webapp to delete repositories, which many
+users have requested. It can delete the local repository,
+with appropriate cautions and sanity checks:
+
+[[!img /assistant/deleterepository.png]]
+
+More likely, you'll use it to remove a remote, which is done with no muss
+and no fuss, since that doesn't delete any data and the remote can always
+be added back if you change your mind.
+
+It also has an option to fully delete the data on a remote. This doesn't
+actually delete the remote right away. All it does is marks the remote
+as untrusted[1], and configures it to not want any content.
+This causes all the content on it to be sucked off to whatever
+other repositories can hold it.
+
+I had to adjust the preferred content expressions to make that work. For
+example, when deleting an archive drive, your local (client) repository
+does not normally want to hold all the data it has in "archive"
+directories. With the adjusted preferred content expressions, any data on
+an untrusted or dead repository is wanted. An interesting result is that
+once a client repository has moved content from an untrusted remote, it
+will decide it doesn't want it anymore, and shove it out to any other
+remote that will accept it. Which is just the behavior we want. All it took
+to get all this behavior is adding "or (not copies=semitrusted:1)" to the
+preferred content expressions!
+
+For most special remotes, just sucking the data from them is sufficient to
+pretty well delete them. You'd want to delete an Amazon bucket or glacier
+once it's empty, and git repositories need to be fully deleted. Since this
+would need unique code for each type of special remote, and it would be
+code that a) deletes possibly large quantities of data with no real way to
+sanity check it and b) doesn't get run and tested very often; it's not
+something I'm thrilled about fully automating. However, I would like to
+make the assistant detect when all the content has been sucked out of a
+remote, and pop up at least a message prompting to finish the deletion.
+Future work.
+
+-----
+
+[1] I really, really wanted to mark it dead, but letting puns drive code
+is probably a bad idea. I had no idea I'd get here when I started
+developing this feature this morning.. Honest!
diff --git a/doc/design/assistant/blog/day_225__back_from_the_dead/comment_1_9ac37c3b5c4c72ec8a39dce00bcbe420._comment b/doc/design/assistant/blog/day_225__back_from_the_dead/comment_1_9ac37c3b5c4c72ec8a39dce00bcbe420._comment
new file mode 100644
index 0000000000..325eff30ce
--- /dev/null
+++ b/doc/design/assistant/blog/day_225__back_from_the_dead/comment_1_9ac37c3b5c4c72ec8a39dce00bcbe420._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andy"
+ ip="99.65.214.16"
+ subject="Just wondering what I'm missing..."
+ date="2013-04-02T21:43:33Z"
+ content="""
+I haven't played around with the preferred content expressions, but what is is that keeps \"or (not copies=semitrusted:1)\" from grabbing all the content from trusted repositories, as well as untrusted or dead ones?
+"""]]
diff --git a/doc/design/assistant/blog/day_225__back_from_the_dead/comment_2_26125dd9ef2bd10b597d14b2c6180952._comment b/doc/design/assistant/blog/day_225__back_from_the_dead/comment_2_26125dd9ef2bd10b597d14b2c6180952._comment
new file mode 100644
index 0000000000..384d20f315
--- /dev/null
+++ b/doc/design/assistant/blog/day_225__back_from_the_dead/comment_2_26125dd9ef2bd10b597d14b2c6180952._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-04-03T03:42:40Z"
+ content="""
+That's some seriously sharp eyes, Andy. Nothing. I forgot it didn't work that way. Now it uses semitrusted+:1 which works the right way.
+"""]]
diff --git a/doc/design/assistant/blog/day_226__poll_results.mdwn b/doc/design/assistant/blog/day_226__poll_results.mdwn
new file mode 100644
index 0000000000..e79ff25859
--- /dev/null
+++ b/doc/design/assistant/blog/day_226__poll_results.mdwn
@@ -0,0 +1,28 @@
+Both the assistant and `git annex drop --auto` refused to drop files from
+untrusted repositories. Got that fixed.
+
+Finally recorded the xmpp pairing screencast. In one perfect take, which
+somehow `recordmydesktop` lost the last 3 minutes of.
+Argh! Anyway I'm editing it now, so, look for that screencast soon.
+
+The [[polls/goals_for_April]] poll results are in. 
+
+* There have been no votes at all for working on
+  cloud remotes. Seems that git-annex supports enough cloud remotes already.
+* A lot of people want the Android webapp port to be done, so I will
+  probably spend some time on that this month.
+* Interest in other various features is split. I am surprised how many 
+  want git-remote-gcrypt, compared to the features that would make
+  syncing use less bandwidth. Doesn't git push over xmpp cover most
+  of the use cases where git-remote-gcrypt would need to be used with the
+  assistant?
+* Nearly as many people as want features, want me to work on bug
+  fixing and polishing what's already there.
+  So I should probably continue to make screencasts, since they often force
+  me to look at things with fresh eyes and see and fix problems. And of course,
+  continue working on bugs as they're reported.
+* I'm not sure what to make of the 10% who want me to add direct mode support.
+  Since direct mode is already used by default, perhaps they want
+  me to take time off? :) (I certainly need to fix the
+  [[bugs/Direct_mode_keeps_re-checksuming_duplicated_files]] bug, and one other
+  direct mode bug I discovered yesterday.)
diff --git a/doc/design/assistant/blog/day_226__poll_results/comment_1_1ed980472214be6d0a8cf55f37797fda._comment b/doc/design/assistant/blog/day_226__poll_results/comment_1_1ed980472214be6d0a8cf55f37797fda._comment
new file mode 100644
index 0000000000..f936e68ed0
--- /dev/null
+++ b/doc/design/assistant/blog/day_226__poll_results/comment_1_1ed980472214be6d0a8cf55f37797fda._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://dzsino.myopenid.com/"
+ nickname="dzsino"
+ subject="I've voted for git-remote-gcrypt because.."
+ date="2013-04-02T09:07:23Z"
+ content="""
+... as important a Windows port seems for git-annex to really take off (IMO), I would welcome encrypted repos for storing stuff on external drives: directory special remotes feel kinda cumbersome for me, I would rather use full blown repos. 
+"""]]
diff --git a/doc/design/assistant/blog/day_226__poll_results/comment_2_6823b0a9a8037f1a5214db4db98fb16e._comment b/doc/design/assistant/blog/day_226__poll_results/comment_2_6823b0a9a8037f1a5214db4db98fb16e._comment
new file mode 100644
index 0000000000..c6e65adf2a
--- /dev/null
+++ b/doc/design/assistant/blog/day_226__poll_results/comment_2_6823b0a9a8037f1a5214db4db98fb16e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-04-02T21:36:50Z"
+ content="""
+Thanks for reminding me about that use case. I have created a page [[encrypted_git_remotes]] for this.
+"""]]
diff --git a/doc/design/assistant/blog/day_227__bigfixing_all_day_today.mdwn b/doc/design/assistant/blog/day_227__bigfixing_all_day_today.mdwn
new file mode 100644
index 0000000000..74e9fd82f7
--- /dev/null
+++ b/doc/design/assistant/blog/day_227__bigfixing_all_day_today.mdwn
@@ -0,0 +1,21 @@
+The [[xmpp screencast|videos/git-annex_assistant_remote_sharing]]
+is at long last done!
+
+----
+
+Fixed a bug that could cause the assistant to unstage files
+from git sometimes. This happened because of a bad optimisation; adding a
+file when it's already present and unchanged was optimised to do nothing.
+But if the file had just been removed, and was put back, this resulted
+in the removal being staged, and the add not being staged. Ugly bug,
+although the assistant's daily sanity check automatically restaged the
+files.
+
+Underlying that bug was a more important problem: git-annex does not always
+update working tree files atomically. So a crash at just the wrong instant
+could cause a file to be deleted from the working tree. I fixed that too;
+all changes to files in the working tree should now be staged in a temp
+file, which is renamed into place atomically.
+
+Also made a bunch of improvements to the dashboard's transfer display, and
+to the handling of the underlying transfer queue.
diff --git a/doc/design/assistant/blog/day_228__more_work_on_repository_removals.mdwn b/doc/design/assistant/blog/day_228__more_work_on_repository_removals.mdwn
new file mode 100644
index 0000000000..f8b4502169
--- /dev/null
+++ b/doc/design/assistant/blog/day_228__more_work_on_repository_removals.mdwn
@@ -0,0 +1,27 @@
+Getting back to the repository removal handling from Sunday, I made the
+assistant detect when a repository that has been marked as unwanted becomes
+empty, and finish the removal process.
+
+I was able to add this to the expensive transfer scan without making it any
+more expensive than it already was, since that scan already looks at the
+location of all keys. Although when a remote is detected as empty, it then
+does one more check, equivilant to `git annex unused`, to find any
+remaining objects on the remote, and force them off.
+
+I think this should work pretty well, but it needs some testing and
+probably some UI work.
+
+----
+
+Andy spotted a bug in the preferred content expressions I was using to
+handle untrusted remotes. So he saved me several hours dealing with an ugly
+bug at some point down the line. I had misread my own preferred content
+expression documentation, and `copies=semitrusted:1` was not doing what I
+thought it was. Added a new syntax that does what I need,
+`copies=semitrusted+:1`
+
+----
+
+The 64 bit linux standalone builds are back. Apparently the 32 bit builds
+have stopped working on recent Fedora, for reasons that are unclear. I set
+up an autobuilder to produce the 64 bit builds.
diff --git a/doc/design/assistant/blog/day_229__rainy_day_bugfixes.mdwn b/doc/design/assistant/blog/day_229__rainy_day_bugfixes.mdwn
new file mode 100644
index 0000000000..87611a97d1
--- /dev/null
+++ b/doc/design/assistant/blog/day_229__rainy_day_bugfixes.mdwn
@@ -0,0 +1,17 @@
+Got caught up on bug reports and made some bug fixes.
+
+The one bug I was really worried about, a strange file corruption problem
+on Android, turned out not to be a bug in git-annex. (Nor is it a bug that
+will affect regular users.)
+
+The only interesting bug fixed was a mixed case hash directory name
+collision when a repository is put on a VFAT filesystem (or other
+filesystem with similar semantics). I was able to fix that nicely; since
+such a repository will be in crippled filesystem mode due to other
+limitations of the filesystem, and so won't be using symlinks,
+it doesn't need to use the mixed case hash directory names.
+
+Last night, finished up the repository removal code, and associated UI
+tweaks. It works very well.
+
+Will probably make a release tomorrow.
diff --git a/doc/design/assistant/blog/day_22__horrible_option_parsing_hack.mdwn b/doc/design/assistant/blog/day_22__horrible_option_parsing_hack.mdwn
new file mode 100644
index 0000000000..8f6708e597
--- /dev/null
+++ b/doc/design/assistant/blog/day_22__horrible_option_parsing_hack.mdwn
@@ -0,0 +1,34 @@
+Well, sometimes you just have to go for the hack. Trying to find a way
+to add additional options to git-annex-shell without breaking backwards
+compatibility, I noticed that it ignores all options after `--`, because
+those tend to be random rsync options due to the way rsync runs it.
+
+So, I've added a new class of options, that come in between, like
+`-- opt=val opt=val ... --`
+
+The parser for these will not choke on unknown options, unlike normal
+getopt. So this let me add the additional info I needed to
+pass to git-annex-shell to make it record transfer information. And
+if I need to pass more info in the future, that's covered too.
+
+It's ugly, but since only git-annex runs git-annex-shell, this is an
+ugliness only I (and now you, dear reader) have to put up with.
+
+Note to self: Command-line programs are sometimes an API, particularly
+if designed to be called remotely, and so it makes sense consider
+whether they are, and design expandability into them from day 1.
+
+---
+
+Anyway, we now have full transfer tracking in git-annex! Both sides of
+a transfer know what's being transferred, and from where, and have
+the info necessary to interrupt the transfer.
+
+---
+
+Also did some basic groundwork, adding a queue of transfers to perform,
+and adding to the daemon's status information a map of currently running
+transfers. 
+
+Next up: The daemon will use inotify to notice new and deleted transfer
+info files, and update its status info.
diff --git a/doc/design/assistant/blog/day_230__Mom.mdwn b/doc/design/assistant/blog/day_230__Mom.mdwn
new file mode 100644
index 0000000000..66a0c864d1
--- /dev/null
+++ b/doc/design/assistant/blog/day_230__Mom.mdwn
@@ -0,0 +1,35 @@
+Made a release today. Releasing has sure gotten easier with all the
+autobuilds to use!
+
+I am now using git-annex to share files with my mom. Here's how the webapp
+looks for our family's repository. Soon several of us will be using this
+repository.
+
+[[!img assistant/example.png]]
+
+We're using XMPP and rsync.net, so pretty standard setup much like
+shown in my last screencast.
+
+Real-world deployments help find bugs, and I found a few:
+
+* If you're running the webapp in `w3m` on a remote computer to set it up,
+  some forms are lacking submit buttons. This must be a issue with
+  Bootstrap, or HTML5, I guess. I switched to `lynx` and it offers a
+  way to submit forms that lack an explicit button.
+
+* Progress bars for downloads from encrypted rsync repos don't update
+  during the actual download, but only when gpg is decrypting the
+  downloaded file.
+
+* XMPP pushes sometimes fail still. Especially when your mom's computer
+  is saturating its limited outgoing network connection uploading hundreds of
+  photos. I have not yet determined if this is a packet loss/corruption issue,
+  or if the XMPP messages are getting out of order. My gut feeling is it's
+  the latter, in which can I can fix this pretty easily by adding sequence
+  numbers and some buffering for out of order packets. Or perhaps just
+  make it retry failed pushes when this happens.
+  
+  Anyway, I found it was useful to set up a regular git repository on a
+  server to suppliment the git pushes over XMPP. It's helpful to have
+  such a git repository anyway, so that clients can push to there when the
+  other client(s) are not online to be pushed to directly over XMPP.
diff --git a/doc/design/assistant/blog/day_230__Mom/comment_1_696bba2246c8a9e6ce4aed3071bcc96c._comment b/doc/design/assistant/blog/day_230__Mom/comment_1_696bba2246c8a9e6ce4aed3071bcc96c._comment
new file mode 100644
index 0000000000..5b8b8187f1
--- /dev/null
+++ b/doc/design/assistant/blog/day_230__Mom/comment_1_696bba2246c8a9e6ce4aed3071bcc96c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="68.35.120.66"
+ subject="comment 1"
+ date="2013-04-05T23:50:14Z"
+ content="""
+This is probably a Dumb Git Question, but is there a tag in the repo for the new release?  I go into my clone and type \"git tag\" and the latest one I see is 4.20130323.
+"""]]
diff --git a/doc/design/assistant/blog/day_230__Mom/comment_2_2fa295ab6db0828cb725cfcfb6777822._comment b/doc/design/assistant/blog/day_230__Mom/comment_2_2fa295ab6db0828cb725cfcfb6777822._comment
new file mode 100644
index 0000000000..3f1666d891
--- /dev/null
+++ b/doc/design/assistant/blog/day_230__Mom/comment_2_2fa295ab6db0828cb725cfcfb6777822._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="deletions by mistake?"
+ date="2013-04-06T04:58:09Z"
+ content="""
+Let's say a family member deletes a file by mistake in a synced diretory?  Looks like this kind of error is easy to go unnoticed.  What would be a good way to handle this?
+"""]]
diff --git a/doc/design/assistant/blog/day_230__Mom/comment_3_fafd7abec629290418334ddb015bf62c._comment b/doc/design/assistant/blog/day_230__Mom/comment_3_fafd7abec629290418334ddb015bf62c._comment
new file mode 100644
index 0000000000..9cfa45acaa
--- /dev/null
+++ b/doc/design/assistant/blog/day_230__Mom/comment_3_fafd7abec629290418334ddb015bf62c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-04-06T16:26:57Z"
+ content="""
+Weird, I don't know where the tag went. I've pushed a new one.
+
+If a file is deleted, it's still there in git, and git-annex hangs onto its contents. You need a git history browser to get it back of course.
+"""]]
diff --git a/doc/design/assistant/blog/day_230__Mom/comment_4_450cac0f2e82c94fd34b527ae05ef1b8._comment b/doc/design/assistant/blog/day_230__Mom/comment_4_450cac0f2e82c94fd34b527ae05ef1b8._comment
new file mode 100644
index 0000000000..56c8d3204e
--- /dev/null
+++ b/doc/design/assistant/blog/day_230__Mom/comment_4_450cac0f2e82c94fd34b527ae05ef1b8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlUbH3eytydcwlWqv8oauE2Jg4NwcV9uA0"
+ nickname="Anna"
+ subject="me!"
+ date="2013-04-06T18:22:30Z"
+ content="""
+I want in on the family repository! :-)
+"""]]
diff --git a/doc/design/assistant/blog/day_231__insert_title.mdwn b/doc/design/assistant/blog/day_231__insert_title.mdwn
new file mode 100644
index 0000000000..6f91b2d363
--- /dev/null
+++ b/doc/design/assistant/blog/day_231__insert_title.mdwn
@@ -0,0 +1,26 @@
+Finally fixed the bug causing repeated checksumming when a direct mode file
+contains duplicate files. I may need to add some cleaning of stale inode
+caches eventually.
+
+Meanwhile, Guilhem made `git annex initremote` use higher quality entropy,
+with `--fast` getting back to the old behavior of urandom quality entropy.
+The assistant doesn't use high quality entropy since I have no way to
+prompt when the user would need to generate more. I did have a fun idea to
+deal with this: Make a javascript game, that the user can play while
+waiting, which would generate enropy nicely. Maybe one day.. ;)
+
+Also made a small but significant change to [[archive directory handling|todo/assistant_smarter_archive_directory_handling]].
+Now the assistant syncs files that are in `archive` directories like any
+other file, until they reach an archive repository. Then they get dropped
+from all the clients. This way, users who don't set up archive repositories
+don't need to know about this special case, and users who do want to use
+them can, with no extra configuration.
+
+After recent changes, the preferred content expression for transfer
+repositories is becoming a bit unweidly, at 212 characters. Probably
+time to add support for macros..
+
+`(not (inallgroup=client and copies=client:2) and (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) or (not copies=semitrusted+:1))) or (not copies=semitrusted+:1)`
+
+Still, it's pretty great how much this little language lets me express, so
+easily.
diff --git a/doc/design/assistant/blog/day_232__headless_webapp.mdwn b/doc/design/assistant/blog/day_232__headless_webapp.mdwn
new file mode 100644
index 0000000000..a60ab383db
--- /dev/null
+++ b/doc/design/assistant/blog/day_232__headless_webapp.mdwn
@@ -0,0 +1,22 @@
+Developed a way to run the webapp on a remote or headless computer.
+
+The webapp can now be started on a remote or headless computer, just
+specify `--listen=address` to make it listen on an address other than
+localhost. It'll print out the URL to open to access it.
+
+This doesn't use HTTPS yet, because it'd need to generate a
+certificate, and even if it generated a self-signed SSL certificate,
+there'd be no easy way for the browser to verify it and avoid a MITM.
+
+So `--listen` is a less secure but easier option; using ssh to forward
+the webapp's port to the remote computer is more secure.
+
+(I do have an idea for a way to do this entirely securely, making
+the webapp set up the ssh port forwarding, which I have written down
+in [[webapp]].. but it would be rather complicated to implement.)
+
+----
+
+Made the webapp rescan for transfers after it's been used to change a
+repository's group. Would have been easy, but I had to chase down a
+cache invalidation bug.
diff --git a/doc/design/assistant/blog/day_232__headless_webapp/comment_1_0fdd77d143ecba6fdb9f75cb6fc37bfb._comment b/doc/design/assistant/blog/day_232__headless_webapp/comment_1_0fdd77d143ecba6fdb9f75cb6fc37bfb._comment
new file mode 100644
index 0000000000..1b36a9ad89
--- /dev/null
+++ b/doc/design/assistant/blog/day_232__headless_webapp/comment_1_0fdd77d143ecba6fdb9f75cb6fc37bfb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="Certificate storage"
+ date="2013-04-09T00:43:12Z"
+ content="""
+Why not store the certificate within the repository? Either a common one in, e.g.
+
+    .git-annex.key-cert.pem
+
+or host-specific as per
+
+    .git-annex.key-cert.pem.$HOST
+
+-- Richard
+"""]]
diff --git a/doc/design/assistant/blog/day_232__headless_webapp/comment_2_0784a2a73c3e2945f3d3f2577b3b9c9c._comment b/doc/design/assistant/blog/day_232__headless_webapp/comment_2_0784a2a73c3e2945f3d3f2577b3b9c9c._comment
new file mode 100644
index 0000000000..67e7972434
--- /dev/null
+++ b/doc/design/assistant/blog/day_232__headless_webapp/comment_2_0784a2a73c3e2945f3d3f2577b3b9c9c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmU_2tE75oyG0h2ZPN4lcroIKEMC8G-otE"
+ nickname="Michael"
+ subject="comment 2"
+ date="2013-04-09T07:27:53Z"
+ content="""
+Can you also set the port via listen= ?
+"""]]
diff --git a/doc/design/assistant/blog/day_232__headless_webapp/comment_3_ccb9fa22422fb913b6a496ebe65c49fb._comment b/doc/design/assistant/blog/day_232__headless_webapp/comment_3_ccb9fa22422fb913b6a496ebe65c49fb._comment
new file mode 100644
index 0000000000..e2c00c59e3
--- /dev/null
+++ b/doc/design/assistant/blog/day_232__headless_webapp/comment_3_ccb9fa22422fb913b6a496ebe65c49fb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-04-09T18:58:40Z"
+ content="""
+@Richard besides the issues with where to store the private key part, that doesn't help with probably the most common use case for a headless webapp: Setting up a new repository on the remote system, which then might get joined into an existing repository network.
+"""]]
diff --git a/doc/design/assistant/blog/day_232__headless_webapp/comment_4_ceba4468760a2525960327698431cee2._comment b/doc/design/assistant/blog/day_232__headless_webapp/comment_4_ceba4468760a2525960327698431cee2._comment
new file mode 100644
index 0000000000..e953233ebe
--- /dev/null
+++ b/doc/design/assistant/blog/day_232__headless_webapp/comment_4_ceba4468760a2525960327698431cee2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-04-09T19:18:24Z"
+ content="""
+@Michael you can now! --listen=address:port
+"""]]
diff --git a/doc/design/assistant/blog/day_232__headless_webapp/comment_5_7e51a197ff9970ae50cf47bd3a922257._comment b/doc/design/assistant/blog/day_232__headless_webapp/comment_5_7e51a197ff9970ae50cf47bd3a922257._comment
new file mode 100644
index 0000000000..de4be2556b
--- /dev/null
+++ b/doc/design/assistant/blog/day_232__headless_webapp/comment_5_7e51a197ff9970ae50cf47bd3a922257._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 5"
+ date="2014-09-16T18:36:18Z"
+ content="""
+Note that --listen=address:port had to be removed.
+
+OTOH, the webapp can be run with a https certificate now, which makes remote access much more secure.
+
+The webapp will use HTTPS if it finds
+a .git/annex/privkey.pem and .git/annex/certificate.pem. Here's
+one way to generate those files, using a self-signed certificate:
+
+    openssl genrsa -out .git/annex/privkey.pem 4096
+    openssl req -new -x509 -key .git/annex/privkey.pem > .git/annex/certificate.pem
+
+"""]]
diff --git a/doc/design/assistant/blog/day_233__taxes.mdwn b/doc/design/assistant/blog/day_233__taxes.mdwn
new file mode 100644
index 0000000000..55273dd4b5
--- /dev/null
+++ b/doc/design/assistant/blog/day_233__taxes.mdwn
@@ -0,0 +1,11 @@
+Did my taxes today. Not very pretty. Planning to run them by a professional.
+
+Reproduced a bug that prevents git-annex from authenticating to the ejabberd
+server, and passed the buck upstream with a test case to the author of the
+haskell XMPP library.
+
+Added some animations to the webapp to show when it's busy doing things.
+
+Made `git annex webapp --listen=address:port` work.
+
+Added a `annex.web-download-command` setting.
diff --git a/doc/design/assistant/blog/day_233__taxes/comment_1_9473ffdc42595af9c293fbcd5a1cdb54._comment b/doc/design/assistant/blog/day_233__taxes/comment_1_9473ffdc42595af9c293fbcd5a1cdb54._comment
new file mode 100644
index 0000000000..a35e738c14
--- /dev/null
+++ b/doc/design/assistant/blog/day_233__taxes/comment_1_9473ffdc42595af9c293fbcd5a1cdb54._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 1"
+ date="2013-04-10T13:35:30Z"
+ content="""
+I don't really want to nagging you, but I'm impatiently waiting 
+for a new build (for linux) to be able to try out your duplicated file fix.
+
+Please don't delay your next release too much:)
+
+Laszlo
+
+"""]]
diff --git a/doc/design/assistant/blog/day_233__taxes/comment_2_5feed8d7053ba03812ccda8c61fd9775._comment b/doc/design/assistant/blog/day_233__taxes/comment_2_5feed8d7053ba03812ccda8c61fd9775._comment
new file mode 100644
index 0000000000..32e4f077fb
--- /dev/null
+++ b/doc/design/assistant/blog/day_233__taxes/comment_2_5feed8d7053ba03812ccda8c61fd9775._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-04-11T14:57:24Z"
+ content="""
+You can already try that fix out using the [[install/Linux_standalone]] autobuild.
+"""]]
diff --git a/doc/design/assistant/blog/day_234__clean_shutdown.mdwn b/doc/design/assistant/blog/day_234__clean_shutdown.mdwn
new file mode 100644
index 0000000000..61b765b593
--- /dev/null
+++ b/doc/design/assistant/blog/day_234__clean_shutdown.mdwn
@@ -0,0 +1,29 @@
+Short day because I spent 3 hours this morning explaining free software
+and kickstarter to an accountant. And was away until 3 pm, so how did I get
+all this done‽
+
+Eliot pointed out that shutting down the assistant could leave transfers
+running. This happened because `git annex transferkeys` is a separate
+process, and so it was left to finish up any transfer that was in
+process. I've made shutdown stop all transfers that the
+assistant started. (Other paired computers could still be connecting to
+make transfers even when the assistant is not running, and those are not
+affected.)
+
+Added sequence numbers to the XMPP messages used for git pushes. While
+these numbers are not used yet, they're available for debugging, and will
+help me determine if packets are lost or come out of order. So if you have
+experienced problems with XMPP syncing sometimes failing, run tonight's
+build of the assistant with `--debug` (or turn on debugging in the webapp
+configuration screen), and send me a log by email to
+<debuglogs201204@joeyh.name>
+
+Changed the way that autobuilds and manual builds report their version
+number. It now includes the date of the last commit, and the abbreviated
+commit ID, rather than being some random date after the last release.
+
+Frederik found a bug using the assistant on a FAT filesystem. It didn't
+properly handle the files that git uses to stand-in for symlinks in that
+situation, and annexed those files. I've fixed this, and even moving
+around symlink stand-in files on a FAT filesystem now results in correct
+changes to symlinks being committed.
diff --git a/doc/design/assistant/blog/day_235__birthday.mdwn b/doc/design/assistant/blog/day_235__birthday.mdwn
new file mode 100644
index 0000000000..2bd2b0d225
--- /dev/null
+++ b/doc/design/assistant/blog/day_235__birthday.mdwn
@@ -0,0 +1,31 @@
+Felt like spending my birthday working on git-annex. Thanks again to
+everyone who makes it possible for me to work on something I care about
+every day.
+
+----
+
+Did some work on `git annex addurl` today. It had gotten broken in direct
+mode (I think by an otherwise good and important bugfix). After fixing
+that, I made it interoperate with the webapp. So if you have the webapp
+open, it will display progress bars for downloads being run by `git annex
+addurl`.
+
+This enhancement meshes nicely with a FlashGot script Andy
+contributed, which lets you queue up downloads into your annex from a web
+browser. Andy described how to set it up in
+[[this_tip|tips/Using_Git-annex_as_a_web_browsing_assistant]].
+
+(I also looked briefly into ways to intercept a drag and drop of a link
+into the webapp and make it lauch a download for you. It doesn't seem that
+browsers allow javascript to override their standard behavior of loading
+links that are dropped into them. Probably good to prevent misuse, but it
+would be nice here...)
+
+----
+
+Also, I think I have fixed the progress bars displayed when downloading
+a file from an encrypted remote. I did this by hooking up existing
+download progress metering (that was only being used to display
+a download percentage in the console) into the location log, so the
+webapp can use it. So that was a *lot* easier than it could have been,
+but still a pretty large patch (500+ lines). Haven't tested this; should work.
diff --git a/doc/design/assistant/blog/day_235__birthday/comment_1_db558b071067c1e63cde05cca0551094._comment b/doc/design/assistant/blog/day_235__birthday/comment_1_db558b071067c1e63cde05cca0551094._comment
new file mode 100644
index 0000000000..32c2c5d50b
--- /dev/null
+++ b/doc/design/assistant/blog/day_235__birthday/comment_1_db558b071067c1e63cde05cca0551094._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawksoT5jmbiZ9UghROilchqy3kNJ1XGqCAo"
+ nickname="Rob"
+ subject="Drag and Drop"
+ date="2013-04-12T03:37:53Z"
+ content="""
+Is this along the lines of what you are looking for? http://www.dropzonejs.com/
+"""]]
diff --git a/doc/design/assistant/blog/day_235__birthday/comment_2_d1a2c1124781118267599457ae9e0512._comment b/doc/design/assistant/blog/day_235__birthday/comment_2_d1a2c1124781118267599457ae9e0512._comment
new file mode 100644
index 0000000000..e41c083ce5
--- /dev/null
+++ b/doc/design/assistant/blog/day_235__birthday/comment_2_d1a2c1124781118267599457ae9e0512._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="marvin"
+ ip="91.152.75.65"
+ subject="Happy Birthday"
+ date="2013-04-12T17:52:43Z"
+ content="""
+Great work!
+"""]]
diff --git a/doc/design/assistant/blog/day_235__birthday/comment_3_b853508d1d15234958b9f4a39277e45c._comment b/doc/design/assistant/blog/day_235__birthday/comment_3_b853508d1d15234958b9f4a39277e45c._comment
new file mode 100644
index 0000000000..350ac2bc2f
--- /dev/null
+++ b/doc/design/assistant/blog/day_235__birthday/comment_3_b853508d1d15234958b9f4a39277e45c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="robconnolly"
+ ip="118.90.78.117"
+ subject="comment 3"
+ date="2013-04-13T03:12:14Z"
+ content="""
+Thanks for fixing the addurl bug and Happy Birthday!
+"""]]
diff --git a/doc/design/assistant/blog/day_235__birthday/comment_5_73aad3398a43bc4d28bca9bf635fa757._comment b/doc/design/assistant/blog/day_235__birthday/comment_5_73aad3398a43bc4d28bca9bf635fa757._comment
new file mode 100644
index 0000000000..9692539714
--- /dev/null
+++ b/doc/design/assistant/blog/day_235__birthday/comment_5_73aad3398a43bc4d28bca9bf635fa757._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andy"
+ ip="99.48.75.171"
+ subject="Just in case it might be helpful..."
+ date="2013-04-14T05:56:47Z"
+ content="""
+For whatever reason, dragging links onto the page text in the \"Using drag and drop for selecting\" section of <http://www.html5rocks.com/en/tutorials/file/dndfiles/#toc-selecting-files-dnd> does not trigger the usual page change. I don't really know why--I couldn't get it to work on my own with Firebug. And thanks for git-annex--love it!
+"""]]
diff --git a/doc/design/assistant/blog/day_236__evil_splicer.mdwn b/doc/design/assistant/blog/day_236__evil_splicer.mdwn
new file mode 100644
index 0000000000..72c8f51a99
--- /dev/null
+++ b/doc/design/assistant/blog/day_236__evil_splicer.mdwn
@@ -0,0 +1,29 @@
+Spent today bulding the Evil Splicer, a program that parses `ghc -ddump-splices`
+output, and uses it to expand Template Haskell splices in source code.
+I hope to use this crazy hack to get the webapp working on Android.
+
+This was a good opportunity to use the
+[Parsec](http://hackage.haskell.org/package/parsec) library for parsing the
+ghc output. I've never really used it before, but found it quite nice to
+work with. The learning curve, if you already know monads and applicatives,
+is about 5 minutes. And instead of ugly regular expressions, you can work
+with nice code that's easily composable and refactorable. Even the ugly
+bits come out well:
+
+[[!format haskell """
+	{- All lines of the splice result will start with the same
+	- indent, which is stripped. Any other indentation is preserved. -}
+	i <- lookAhead indent
+	result <- unlines <$> many1 (string i >> restOfLine)
+"""]]
+
+Anyway, it works.. sorta. The parser works great! The splices that ghc
+outputs are put into the right places in the source files, and formatted in
+a way that ghc is able to build. Often though, they contain code that
+doesn't actually build as-is. I'm working to fix up the code to get closer
+to buildable.
+
+----
+
+Meanwhile, guilhem has made ssh connection caching work for rsync special
+remotes! It's very nice to have another developer working on git-annex. :)
diff --git a/doc/design/assistant/blog/day_237__gnome-keyring_craziness.mdwn b/doc/design/assistant/blog/day_237__gnome-keyring_craziness.mdwn
new file mode 100644
index 0000000000..01b8195b69
--- /dev/null
+++ b/doc/design/assistant/blog/day_237__gnome-keyring_craziness.mdwn
@@ -0,0 +1,29 @@
+Fixed a bug where the locked down ssh key that the assistant sets up to
+access the annex on a remote server was being used by ssh *by default* for
+all logins to that server.
+
+That should not have happened. The locked down key is written to a filename
+that ssh won't use at all, by default. But, I found code in gnome-keyring
+that watches for `~/.ssh/*.pub` to appear, and automatically adds all such
+keys to the keyring. In at least some cases, probably when it has no other
+key, it then tells ssh to go ahead and use that key. Astounding.
+
+To avoid this, the assistant will store its keys in <s>`~/.ssh/annex/`</s>
+`~/.ssh/git-annex/` instead. gnome-keyring does not look there (verified in
+the source). If you use gnome-keyring and have set up a repository on a
+remote server with the assistant, I'd recommend moving the keys it set up
+and editing `~/.ssh/config` to point to their new location.
+
+gnome-keyring is not the only piece of software that has a bad
+interaction with git-annex. I've been working on a bug that makes git-annex
+fail to authenticate to ejabberd. ejabberd 2.1.10 got support for
+SCRAM-SHA-1, but its code violates the RFC, and chokes on an address
+attribute that the haskell XMPP library provides. I hope to get this fixed
+in ejabberd.
+
+
+Also did some more work on the Evil Splicer today, integrating it into the
+build of the Android app, and making it support incremental building.
+Improved its code generation, and am at the milestone where it creates
+valid haskell code for the entire `Assistant/WebApp/Types.hs` file,
+where Template Haskell expands 2 lines into 2300 lines of code!
diff --git a/doc/design/assistant/blog/day_237__gnome-keyring_craziness/comment_1_0cb088b732881d1fa92493aa1fd93d43._comment b/doc/design/assistant/blog/day_237__gnome-keyring_craziness/comment_1_0cb088b732881d1fa92493aa1fd93d43._comment
new file mode 100644
index 0000000000..e8cc457821
--- /dev/null
+++ b/doc/design/assistant/blog/day_237__gnome-keyring_craziness/comment_1_0cb088b732881d1fa92493aa1fd93d43._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="Confusing name for storage directory"
+ date="2013-04-14T23:55:03Z"
+ content="""
+`~/.ssh/annex/` would make sense for ssh-annex. I would suggest using `~/.ssh/git-annex/` or similar, instead.
+"""]]
diff --git a/doc/design/assistant/blog/day_237__gnome-keyring_craziness/comment_2_b855fd710954beebaafe6d2bd03eb368._comment b/doc/design/assistant/blog/day_237__gnome-keyring_craziness/comment_2_b855fd710954beebaafe6d2bd03eb368._comment
new file mode 100644
index 0000000000..cf3e8fbbf2
--- /dev/null
+++ b/doc/design/assistant/blog/day_237__gnome-keyring_craziness/comment_2_b855fd710954beebaafe6d2bd03eb368._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-04-14T23:59:44Z"
+ content="""
+I agree, change made
+"""]]
diff --git a/doc/design/assistant/blog/day_238__back_to_Android.mdwn b/doc/design/assistant/blog/day_238__back_to_Android.mdwn
new file mode 100644
index 0000000000..b07d784fa3
--- /dev/null
+++ b/doc/design/assistant/blog/day_238__back_to_Android.mdwn
@@ -0,0 +1,11 @@
+Back to really working toward an Android webapp now. I have been improving
+the EvilSplicer, and the build machinery, and build environment all day.
+Slow but steady progress.
+
+First milestone of the day was when I got `yesod-form` to build with all
+Template Haskell automatically expanded by the EvilSplicer. (With a few
+manual fixups where it's buggy.)
+
+At this point the Android build with the webapp enabled successfully
+builds several files containing Yesod code.. And I suspect I am very close
+to getting a first webapp build for Android.
diff --git a/doc/design/assistant/blog/day_239__bugfixes_and_frustration.mdwn b/doc/design/assistant/blog/day_239__bugfixes_and_frustration.mdwn
new file mode 100644
index 0000000000..2ca62cfe67
--- /dev/null
+++ b/doc/design/assistant/blog/day_239__bugfixes_and_frustration.mdwn
@@ -0,0 +1,28 @@
+Several bug fixes today, and got mostly caught up on recent messages.
+Still have a backlog of two known bugs that I cannot reproduce well enough
+to have worked on, but I am thinking I will make a release tomorrow. There
+have been a lot of changes in the 10 days since the last release.
+
+----
+
+I am, frustratingly, stuck building the webapp on Android with no forward
+progress today (and last night) after such a productive day yesterday.
+
+The expanded Template Haskell code of the webapp fails to compile,
+whereever type safe urls are used.
+
+<pre>
+Assistant/WebApp/Types.hs:95:63:
+    Couldn't match expected type `Route WebApp -> t2'
+                with actual type `Text'
+    The function `urender_a1qcK' is applied to three arguments,
+    but its type `Route WebApp -> [(Text, Text)] -> Text' has only two
+    In the expression: urender_a1qcK u_a1qcL [] LogR
+    In the first argument of `toHtml', namely
+      `(\ u_a1qcL -> urender_a1qcK u_a1qcL [] LogR)'
+</pre>
+
+My best guess is this is a mismatch between the versions of yesod (or other
+libraries) used for the native and cross compiled ghc's. So I've been
+slowly trying to get a fully matched set of versions in between working on
+bugs.
diff --git a/doc/design/assistant/blog/day_23__transfer_watching.mdwn b/doc/design/assistant/blog/day_23__transfer_watching.mdwn
new file mode 100644
index 0000000000..3e4e27d479
--- /dev/null
+++ b/doc/design/assistant/blog/day_23__transfer_watching.mdwn
@@ -0,0 +1,25 @@
+Starting to travel, so limited time today.
+
+Yet Another Thread added to the assistant, all it does is watch for changes
+to transfer information files, and update the assistant's map of transfers
+currently in progress. Now the assistant will know if some other repository
+has connected to the local repo and is sending or receiving a file's
+content.
+
+This seemed really simple to write, it's just 78 lines of code. It worked
+100% correctly the first time. :) But it's only so easy because I've got
+this shiny new inotify hammer that I keep finding places to use in the
+assistant.
+
+Also, the new thread does some things that caused a similar thread (the
+merger thread) to go into a MVar deadlock. Luckily, I spent much of 
+[day 19](day_19__random_improvements) investigating and fixing that
+deadlock, even though it was not a problem at the time.
+
+So, good.. I'm doing things right and getting to a place where rather
+nontrivial features can be added easily.
+
+--
+
+Next up: Enough nonsense with tracking transfers... Time to start actually
+transferring content around!
diff --git a/doc/design/assistant/blog/day_240__it_builds.mdwn b/doc/design/assistant/blog/day_240__it_builds.mdwn
new file mode 100644
index 0000000000..dc975af817
--- /dev/null
+++ b/doc/design/assistant/blog/day_240__it_builds.mdwn
@@ -0,0 +1,37 @@
+Late last night, I successfully built the full webapp for Android!
+
+That was with several manual modifications to the generated code, which I
+still need to automate. And I need to set up the autobuilder properly
+still. And I need to find a way to make the webapp open Android's web browser
+to URL. So it'll be a while yet until a package is available
+to try. But what a milestone!
+
+The point I was stuck on all day yesterday was generated code that
+looked like this:
+
+[[!format haskell """
+(toHtml
+  (\ u_a2ehE -> urender_a2ehD u_a2ehE []
+    (CloseAlert aid)))));
+"""]]
+
+That just couldn't type check at all. Most puzzling. My best guess is that
+`u_a2ehE` is the dictionary GHC passes internally to make a typeclass work,
+which somehow leaked out and became visible. Although
+I can't rule out that I may have messed something up in my build environment.
+The EvilSplicer has a hack in it that finds such code and converts it to
+something like this:
+
+[[!format haskell """
+(toHtml
+  (flip urender_a2ehD []
+    (CloseAlert aid)))));
+"""]]
+
+I wrote some more about the process of the Android port in my personal blog:
+[Template Haskell on impossible architectures](http://joeyh.name/blog/entry/Template_Haskell_on_impossible_architectures/)
+
+----
+
+Release day today. The OSX builds are both not available yet for this
+release, hopefully will come out soon.
diff --git a/doc/design/assistant/blog/day_240__it_builds/comment_1_151840ae0020ea63b2f041488c905386._comment b/doc/design/assistant/blog/day_240__it_builds/comment_1_151840ae0020ea63b2f041488c905386._comment
new file mode 100644
index 0000000000..a8e4895827
--- /dev/null
+++ b/doc/design/assistant/blog/day_240__it_builds/comment_1_151840ae0020ea63b2f041488c905386._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="Duplicated files resolved"
+ date="2013-04-18T05:52:35Z"
+ content="""
+Hi,
+
+Seems like the duplicated file issue finally resolved in this release, 
+also the logging is not so detailed, so it does not explode the disk space either.
+
+I think a new bug introduced in this release, 
+namely if you create a repository and a backup repository of it (pendrive), then this repository is not in direct mode by default.
+(and there is a missing direct = True variable in that repository (/mnt/dat/annex_backup/.git/annex/config)).
+
+Also I run into resource exhausted bug, and every thread is crashed.
+Can git-annex only watch a directory, and not every file in it?
+
+I will create a bugreport for resource exhausted.
+
+Best, 
+ Laszlo
+
+
+"""]]
diff --git a/doc/design/assistant/blog/day_241__cleanup.mdwn b/doc/design/assistant/blog/day_241__cleanup.mdwn
new file mode 100644
index 0000000000..077922695e
--- /dev/null
+++ b/doc/design/assistant/blog/day_241__cleanup.mdwn
@@ -0,0 +1,14 @@
+Finished the last EvilSplicer tweak and other fixes to make the 
+Android webapp build without any hand-holding.
+
+Currently setting up the Android autobuilder to include the webapp in its
+builds. To make this work I had to set up a new chroot with all the right
+stuff installed.
+
+Investigated how to make the Android webapp open a web browser when run.
+As far as I can tell (without access to an Android device right now), 
+`am start -a android.intent.action.VIEW -d http://localhost/etc` should do
+it.
+
+Seems that git 1.8.2 broke the assistant. I've put in a fix but have not
+yet tested it.
diff --git a/doc/design/assistant/blog/day_241__cleanup/comment_1_0e283cdf66a25b3cc9423fe651084cb9._comment b/doc/design/assistant/blog/day_241__cleanup/comment_1_0e283cdf66a25b3cc9423fe651084cb9._comment
new file mode 100644
index 0000000000..d9e468f324
--- /dev/null
+++ b/doc/design/assistant/blog/day_241__cleanup/comment_1_0e283cdf66a25b3cc9423fe651084cb9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlJ2utMQgMEYAOs3Dfc6eZRyUzt4acNXUU"
+ nickname="David"
+ subject="am start -a android.intent.action.VIEW -d http://localhost/etc"
+ date="2013-04-18T22:39:50Z"
+ content="""
+Just tested the command on an Android device, it works well.
+"""]]
diff --git a/doc/design/assistant/blog/day_242__more_porting.mdwn b/doc/design/assistant/blog/day_242__more_porting.mdwn
new file mode 100644
index 0000000000..89fbfea0f1
--- /dev/null
+++ b/doc/design/assistant/blog/day_242__more_porting.mdwn
@@ -0,0 +1,4 @@
+Got WebDAV enabled in the Android build. Had to deal with some system calls
+not available in Android's libc.
+
+New poll: [[polls/Android_default_directory]]
diff --git a/doc/design/assistant/blog/day_243__in_the_field.mdwn b/doc/design/assistant/blog/day_243__in_the_field.mdwn
new file mode 100644
index 0000000000..b05ccac9e9
--- /dev/null
+++ b/doc/design/assistant/blog/day_243__in_the_field.mdwn
@@ -0,0 +1,21 @@
+Today was not a work day for me, but I did get a chance to install
+git-annex in real life while visiting. Was happy to download the standalone
+Linux tarball and see that it could be unpacked, and git-annex webapp
+started just by clicking around in the GUI. And in very short order got it
+set up.
+
+I was especially pleased to see my laptop noticed this new repository
+had appeared on the network via XMPP push, and started immediately
+uploading files to my rsync.net transfer repository so the new
+repository could get them.
+
+Did notice that the standalone tarball neglected to install a
+FDO menu file. Fixed that, and some other minor issues I noticed.
+
+
+I also got a brief chance to try the Android webapp. It fails to start;
+apparently `getaddrinfo` doesn't like the flags passed to it and is
+failing. As failure modes go, this isn't at all bad. I can certainly work
+around it with some hardcoded port numbers, but I want to fix it the right
+way. Have ordered a replacement battery for my dead phone so I can use it
+for Android testing.
diff --git a/doc/design/assistant/blog/day_244__android_porting.mdwn b/doc/design/assistant/blog/day_244__android_porting.mdwn
new file mode 100644
index 0000000000..e535c1054b
--- /dev/null
+++ b/doc/design/assistant/blog/day_244__android_porting.mdwn
@@ -0,0 +1,6 @@
+Ported all the C libraries needed for XMPP to Android. (gnutls,
+libgcrypt, libgpg-error, nettle, xml2, gsasl, etc). Finally
+got it all to link. What a pain.
+
+Bonus: Local pairing support builds for Android now, seems recent changes to
+the network library for WebDAV also fixed it.
diff --git a/doc/design/assistant/blog/day_245__misc.mdwn b/doc/design/assistant/blog/day_245__misc.mdwn
new file mode 100644
index 0000000000..8559ac4f10
--- /dev/null
+++ b/doc/design/assistant/blog/day_245__misc.mdwn
@@ -0,0 +1,15 @@
+Got the OSX autobuilder back running, and finally got a OSX build up for
+the 4.20130417 release. Also fixed the OSX app build machinery to handle
+rpath.
+
+Made the assistant (and `git annex sync`) sync with git remotes that have
+`annex-ignore` set. So, `annex-ignore` is only used to prevent using
+the annex of a remote, not syncing with it. The benefit of this change
+is that it'll make the assistant sync the local git repository with
+a git remote that is on a server that does not have git-annex installed.
+It can even sync to github.
+
+Worked around more breakage on misconfigured systems that don't have GECOS
+information.
+
+... And other bug fixes and bug triage.
diff --git a/doc/design/assistant/blog/day_245__misc/comment_1_3a2976617bb0cdc206fb1397a2ef1177._comment b/doc/design/assistant/blog/day_245__misc/comment_1_3a2976617bb0cdc206fb1397a2ef1177._comment
new file mode 100644
index 0000000000..4ee7612f11
--- /dev/null
+++ b/doc/design/assistant/blog/day_245__misc/comment_1_3a2976617bb0cdc206fb1397a2ef1177._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="192.76.7.217"
+ subject="comment 1"
+ date="2013-04-23T17:11:46Z"
+ content="""
+If I set my annex-ignore'd respository to `annex-sync = false` will this override the new behaviour?  My remote requires mounting a fuse mount, so this change will just result in my seeing lots of sync failure messages in the webapp.
+"""]]
diff --git a/doc/design/assistant/blog/day_245__misc/comment_2_e0f9704e91fedca8ff26356f354cc1c3._comment b/doc/design/assistant/blog/day_245__misc/comment_2_e0f9704e91fedca8ff26356f354cc1c3._comment
new file mode 100644
index 0000000000..545da72cdb
--- /dev/null
+++ b/doc/design/assistant/blog/day_245__misc/comment_2_e0f9704e91fedca8ff26356f354cc1c3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-04-23T20:16:26Z"
+ content="""
+Yes, setting that, or just clicking to pause syncing to a remote in the webapp will still work.
+
+Although I don't think you need to.. If the remote is on a filesystem mount point, the assistant will just ignore it when it's not mounted. And will automatically detect when it gets mounted and sync with it, too. Same as USB drives are handled.
+"""]]
diff --git a/doc/design/assistant/blog/day_245__misc/comment_3_93003a0d0983efbdc046d7459be194b0._comment b/doc/design/assistant/blog/day_245__misc/comment_3_93003a0d0983efbdc046d7459be194b0._comment
new file mode 100644
index 0000000000..45a3b6adc8
--- /dev/null
+++ b/doc/design/assistant/blog/day_245__misc/comment_3_93003a0d0983efbdc046d7459be194b0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="163.1.167.50"
+ subject="comment 3"
+ date="2013-04-24T17:09:50Z"
+ content="""
+It's a userspace fuse mount so the assistant won't know it's a mountpoint unless mounted.  Also I don't want the automatic sync since I like to keep this respository manual as a kind of backup.  Thanks for the info.
+"""]]
diff --git a/doc/design/assistant/blog/day_246__bug_treadmill.mdwn b/doc/design/assistant/blog/day_246__bug_treadmill.mdwn
new file mode 100644
index 0000000000..36ee0c6174
--- /dev/null
+++ b/doc/design/assistant/blog/day_246__bug_treadmill.mdwn
@@ -0,0 +1,18 @@
+There seem to be a steady state of enough bug reports coming in that I can
+work on them whenever I'm not working on anything else. As I did all day
+today.
+
+This doesn't bother me if the bug reports are of real bugs that I can
+reproduce and fix, but I'm spending a lot of time currently following up to
+messages and asking simple questions like "what version number" and "can I
+please see the whole log file". And just trying to guess what a vague
+problem report means and read people's minds to get to a definite bug
+with a test case that I can then fix.
+
+I've noticed the overall quality of bug reports nosedive over the past
+several months. My guess is this means that git-annex has found a less
+technical audience. I need to find something to do about this.
+
+With that whining out of the way ...
+I fixed a pretty ugly bug on FAT/Android today, and
+I am 100% caught up on messages right now!
diff --git a/doc/design/assistant/blog/day_246__bug_treadmill/comment_1_f76f653364fe2b97e85e8356c93b0fce._comment b/doc/design/assistant/blog/day_246__bug_treadmill/comment_1_f76f653364fe2b97e85e8356c93b0fce._comment
new file mode 100644
index 0000000000..33746ed4aa
--- /dev/null
+++ b/doc/design/assistant/blog/day_246__bug_treadmill/comment_1_f76f653364fe2b97e85e8356c93b0fce._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQafKy7hNSEolLs6TvbgUnkklTctUY9LI"
+ nickname="Zellyn"
+ subject="Bugs..."
+ date="2013-04-23T23:30:47Z"
+ content="""
+Perhaps if you made a bug report form that asked for the version number (with helpful command to get it printed below), and had a checkbox for \"full log attached\", etc. you might be able to weed out low-value bugs...  Not that adding UI to force good bugs really works, but there might be a couple of low-hanging fruit before the diminishing returns kick in.
+"""]]
diff --git a/doc/design/assistant/blog/day_247__performance_tuning.mdwn b/doc/design/assistant/blog/day_247__performance_tuning.mdwn
new file mode 100644
index 0000000000..964710b8ec
--- /dev/null
+++ b/doc/design/assistant/blog/day_247__performance_tuning.mdwn
@@ -0,0 +1,16 @@
+Working on assistant's performance when it has to add a whole lot of files
+(10k to 100k). 
+
+Improved behavior in several ways, including fixing display
+of the alert in the webapp when the default inotify limit of 8192
+directories is exceeded.
+
+Created a new TList data type, a transactional DList. Much nicer
+implementation than the TChan based thing it was using to keep track of the
+changes, although it only improved runtime and memory usage a little bit.
+The way that this is internally storing a function in STM and modifying
+that function to add items to the list is way cool.
+
+Other tuning seems to have decreased the time it would take to import 100k
+files from somewhere in the range of a full day (too long to wait to see),
+to around 3.5 hours. I don't know if that's good, but it's certainly better.
diff --git a/doc/design/assistant/blog/day_248__Internet_Archive.mdwn b/doc/design/assistant/blog/day_248__Internet_Archive.mdwn
new file mode 100644
index 0000000000..f002939f13
--- /dev/null
+++ b/doc/design/assistant/blog/day_248__Internet_Archive.mdwn
@@ -0,0 +1,28 @@
+Very productive & long day today, spent adding a new feature to the 
+webapp: Internet Archive support!
+
+[[!img /assistant/iaitem.png]]
+
+git-annex already supported using archive.org via its S3 special remotes,
+so this is just a nice UI around that.
+
+How does it decide which files to publish on archive.org? Well,
+the item has a unique name, which is based on the description
+field. Any files located in a directory with that name will be uploaded
+to that item. (This is done via a new preferred content expression I added.)
+
+So, you can have one repository with multiple IA items attached, and
+sort files between them however you like.
+I plan to make a screencast eventually demoing that. 
+
+Another interesting use case, once the Android webapp is done, would be add
+a repository on the DCIM directory, set the archive.org repository to
+prefer all content, and *bam*, you have a phone or tablet that
+auto-publishes and archives every picture it takes.
+
+Another nice little feature added today is that whenever a file is uploaded
+to the Internet Archive, its public url is automatically recorded, same
+as if you'd ran `git annex addurl`. So any users who can clone your
+repository can download the files from archive.org, without needing any
+login or password info. This makes the Internet Archive a nice way to
+publish the large files associated with a public git repository.
diff --git a/doc/design/assistant/blog/day_249__quiet_day.mdwn b/doc/design/assistant/blog/day_249__quiet_day.mdwn
new file mode 100644
index 0000000000..28c1e6f3d7
--- /dev/null
+++ b/doc/design/assistant/blog/day_249__quiet_day.mdwn
@@ -0,0 +1,7 @@
+Quiet day. Only did minor things, like adding webapp UI for changing the
+directory used by Internet Archive remotes, and splitting out an
+`enableremote` command from `initremote`.
+
+My Android development environment is set up and ready to go on my Motorola
+Droid. The current Android build of git-annex fails to link at run time, so
+my work is cut out for me. Probably broke something while enabling XMPP?
diff --git a/doc/design/assistant/blog/day_24__airport_digressions.mdwn b/doc/design/assistant/blog/day_24__airport_digressions.mdwn
new file mode 100644
index 0000000000..6952969748
--- /dev/null
+++ b/doc/design/assistant/blog/day_24__airport_digressions.mdwn
@@ -0,0 +1,99 @@
+In a series of airport layovers all day. Since I woke up at 3:45 am, 
+didn't feel up to doing serious new work, so instead I worked through some
+OSX support backlog.
+
+git-annex will now use Haskell's SHA library if the `sha256sum`
+command is not available. That library is slow, but it's guaranteed to be
+available; git-annex already depended on it to calculate HMACs.
+
+Then I decided to see if it makes sense to use the SHA library
+when adding smaller files. At some point, its slower implementation should
+win over needing to fork and parse the output of `sha256sum`. This was 
+the first time I tried out Haskell's 
+[Criterion](http://hackage.haskell.org/package/criterion) benchmarker,
+and I built this simple benchmark in short order.
+
+[[!format haskell """
+import Data.Digest.Pure.SHA
+import Data.ByteString.Lazy as L
+import Criterion.Main
+import Common
+
+testfile :: FilePath
+testfile = "/tmp/bar" -- on ram disk
+
+main = defaultMain
+        [ bgroup "sha256"
+                [ bench "internal" $ whnfIO internal
+                , bench "external" $ whnfIO external
+                ]
+        ]
+
+internal :: IO String
+internal = showDigest . sha256 <$> L.readFile testfile
+
+external :: IO String
+external = pOpen ReadFromPipe "sha256sum" [testfile] $ \h ->
+        fst . separate (== ' ') <$> hGetLine h
+"""]]
+
+The nice thing about benchmarking in Airports is when you're running a
+benchmark locally, you don't want to do anything else with the computer,
+so can alternate people watching, spacing out, and analizing results.
+
+100 kb file:
+
+	benchmarking sha256/internal
+	mean: 15.64729 ms, lb 15.29590 ms, ub 16.10119 ms, ci 0.950
+	std dev: 2.032476 ms, lb 1.638016 ms, ub 2.527089 ms, ci 0.950
+
+	benchmarking sha256/external
+	mean: 8.217700 ms, lb 7.931324 ms, ub 8.568805 ms, ci 0.950
+	std dev: 1.614786 ms, lb 1.357791 ms, ub 2.009682 ms, ci 0.950
+
+75 kb file:
+
+	benchmarking sha256/internal
+	mean: 12.16099 ms, lb 11.89566 ms, ub 12.50317 ms, ci 0.950
+	std dev: 1.531108 ms, lb 1.232353 ms, ub 1.929141 ms, ci 0.950
+
+	benchmarking sha256/external
+	mean: 8.818731 ms, lb 8.425744 ms, ub 9.269550 ms, ci 0.950
+	std dev: 2.158530 ms, lb 1.916067 ms, ub 2.487242 ms, ci 0.950
+
+50 kb file:
+
+	benchmarking sha256/internal
+	mean: 7.699274 ms, lb 7.560254 ms, ub 7.876605 ms, ci 0.950
+	std dev: 801.5292 us, lb 655.3344 us, ub 990.4117 us, ci 0.950
+
+	benchmarking sha256/external
+	mean: 8.715779 ms, lb 8.330540 ms, ub 9.102232 ms, ci 0.950
+	std dev: 1.988089 ms, lb 1.821582 ms, ub 2.181676 ms, ci 0.950
+
+10 kb file:
+
+	benchmarking sha256/internal
+	mean: 1.586105 ms, lb 1.574512 ms, ub 1.604922 ms, ci 0.950
+	std dev: 74.07235 us, lb 51.71688 us, ub 108.1348 us, ci 0.950
+
+	benchmarking sha256/external
+	mean: 6.873742 ms, lb 6.582765 ms, ub 7.252911 ms, ci 0.950
+	std dev: 1.689662 ms, lb 1.346310 ms, ub 2.640399 ms, ci 0.950
+
+It's possible to get nice graphical reports out of Criterion, but 
+this is clear enough, so I stopped here. 50 kb seems a reasonable
+cutoff point.
+
+I also used this to benchmark the SHA256 in Haskell's Crypto package.
+Surprisingly, it's a *lot* slower than even the Pure.SHA code.
+On a 50 kb file:
+
+	benchmarking sha256/Crypto
+	collecting 100 samples, 1 iterations each, in estimated 6.073809 s
+	mean: 69.89037 ms, lb 69.15831 ms, ub 70.71845 ms, ci 0.950
+	std dev: 3.995397 ms, lb 3.435775 ms, ub 4.721952 ms, ci 0.950
+
+
+There's another Haskell library, [SHA2](http://hackage.haskell.org/package/SHA2),
+which I should try some time.
diff --git a/doc/design/assistant/blog/day_250__stymied.mdwn b/doc/design/assistant/blog/day_250__stymied.mdwn
new file mode 100644
index 0000000000..f9d50b48c9
--- /dev/null
+++ b/doc/design/assistant/blog/day_250__stymied.mdwn
@@ -0,0 +1,23 @@
+Turns out my old Droid has such an old version of Android (2.2) that
+it doesn't work with any binaries produced by my haskell cross-compiler. I
+think it's using a symbol not in its version of libc. Since upgrading this
+particular phone is a ugly process and the hardware is dying anyway (bad
+USB power connecter), I have given up on using it, and ordered an Android
+tablet instead to use for testing. Until that arrives, no Android. Bah.
+Wanted to get the Android app working in April.
+
+Instead, today I worked on making the webapp require less redundant
+password entry when adding multiple repositories using the same cloud
+provider. This is especially needed for the Internet Archive, since users
+will often want to have quite a few repositories, for different IA items.
+Implemented it for box.com, and Amazon too.
+
+Francois Marier has built an Ubuntu PPA for git-annex, containing the
+current version, with the assistant and webapp. It's targeted at Precise,
+but I think will probably also work with newer releases.
+<https://launchpad.net/~fmarier/+archive/ppa>
+
+Probably while I'm waiting to work on Android again, I will try to
+improve the situation with using a single XMPP account for multiple
+repositories. Spent a while today thinking through ways to improve the
+design, and have some ideas.
diff --git a/doc/design/assistant/blog/day_250__stymied/comment_1_330a10d447ccc3db03fcbfe571dbb404._comment b/doc/design/assistant/blog/day_250__stymied/comment_1_330a10d447ccc3db03fcbfe571dbb404._comment
new file mode 100644
index 0000000000..26c7d7c7ff
--- /dev/null
+++ b/doc/design/assistant/blog/day_250__stymied/comment_1_330a10d447ccc3db03fcbfe571dbb404._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnLgNOfkl8c6oQu9b42U0Pm_uC4n3Gkgiw"
+ nickname="Mark"
+ subject="Thanks!"
+ date="2013-04-29T01:24:55Z"
+ content="""
+I was not looking forward to figuring out how to come up with all of those haskell build deps on Precise, so thanks to François Marier for putting this together.  (Does Ubuntu/launchpad autobuild all of the architectures, or do they need to be contributed? I see that `armhf` isn't there at the moment...)
+"""]]
diff --git a/doc/design/assistant/blog/day_251__xmpp_improvements.mdwn b/doc/design/assistant/blog/day_251__xmpp_improvements.mdwn
new file mode 100644
index 0000000000..7007d7c0d0
--- /dev/null
+++ b/doc/design/assistant/blog/day_251__xmpp_improvements.mdwn
@@ -0,0 +1,34 @@
+Took 2 days in a row off, because I noticed I have forgotten to do that
+since February, or possibly earlier, not counting trips. Whoops!
+
+Also, I was feeling overwhelmed with the complexity of fixing XMPP to not
+be buggy when there are multiple separate repos using the same XMPP
+account. Let my subconscious work on that, and last night it served up the
+solution, in detail. Built it today.
+
+It's only a partial solution, really. If you want to use the same XMPP
+account for multiple separate repositories, you cannot use the "Share with
+your other devices" option to pair your devices. That's because XMPP
+pairing assumes all your devices are using the same XMPP account, in order
+to avoid needing to confirm on every device each time you add a new device.
+The UI is clear about that, and it avoids complexity, so I'm ok with that.
+
+But, if you want to instead use "Share with a friend", you now can use the
+same XMPP account for as many separate repositories as you like. The
+assistant now ignores pushes from repositories it doesn't know about.
+Before, it would merge them all together without warning.
+
+----
+
+While I was testing that, I think I found out the real reason why XMPP
+pushes have seemed a little unreliable. It turns out to not be an XMPP
+issue at all! Instead, the merger was simply not always
+noticing when `git receive-pack` updated a ref, and not merging it into
+master. That was easily fixed.
+
+----
+
+Adam Spiers has been getting a `.gitignore` query interface suitable for
+the assistant to use into `git`, and he tells me it's landed in `next`.
+I should soon check that out and get the assistant using it. But first,
+Android app!
diff --git a/doc/design/assistant/blog/day_252__release_day.mdwn b/doc/design/assistant/blog/day_252__release_day.mdwn
new file mode 100644
index 0000000000..70c99760a8
--- /dev/null
+++ b/doc/design/assistant/blog/day_252__release_day.mdwn
@@ -0,0 +1,6 @@
+Pushed out a release today. Looking back over April, I'm happy with it as a
+bug fix and stabilization month. Wish I'd finished the Android app in April,
+but let's see what happens tomorrow.
+
+Recorded part of a screencast on using Archive.org, but `recordmydesktop`
+lost the second part. Grr. Will work on that later.
diff --git a/doc/design/assistant/blog/day_253__OMG.mdwn b/doc/design/assistant/blog/day_253__OMG.mdwn
new file mode 100644
index 0000000000..b1cc89fffd
--- /dev/null
+++ b/doc/design/assistant/blog/day_253__OMG.mdwn
@@ -0,0 +1,22 @@
+[[!img /android/webapp.png alt="git-annex webapp on Android"]]
+
+I fixed what I thought was keeping the webapp from working on Android, but
+then it started segfaulting every time it was started. Eventually I
+determined this segfault happened whenever haskell code called
+`getaddrinfo`. I don't know why. This is particularly weird since I had
+a demo web server that used `getaddrinfo` working way back in
+[[day_201__real_Android_wrapup]]. Anyway, I worked around it by not using
+`getaddrinfo` on Android.
+
+Then I spent 3 hours stuck, because the webapp seemed to run, but
+nothing could connect to the port it was on. Was it a firewall? Was
+the Haskell threaded runtime's use of `accept()` broken? I went all the way
+down to the raw system calls, and back, only to finally notice I had `netstat`
+available on my Android. Which showed it was not listening to the port I
+thought it was!
+
+Seems that `ntohs` and `htons` are broken somehow. To get the
+screenshot, I fixed up the port manually. Have a build running that
+should work around the issue.
+
+Anyway, the webapp works on Android!
diff --git a/doc/design/assistant/blog/day_253__OMG/comment_1_bbdc61092771163e65a90a4755a807d8._comment b/doc/design/assistant/blog/day_253__OMG/comment_1_bbdc61092771163e65a90a4755a807d8._comment
new file mode 100644
index 0000000000..0fa06b32ff
--- /dev/null
+++ b/doc/design/assistant/blog/day_253__OMG/comment_1_bbdc61092771163e65a90a4755a807d8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnxp2XU8gIribhhGhGuYtU6eMMwHv5gUGI"
+ nickname="Amitai"
+ subject="Woohoo!"
+ date="2013-05-03T03:13:25Z"
+ content="""
+(See above)
+"""]]
diff --git a/doc/design/assistant/blog/day_254__Android_app_polishing.mdwn b/doc/design/assistant/blog/day_254__Android_app_polishing.mdwn
new file mode 100644
index 0000000000..cbb6f7f15c
--- /dev/null
+++ b/doc/design/assistant/blog/day_254__Android_app_polishing.mdwn
@@ -0,0 +1,35 @@
+There's a new page [[/Android]] that documents using git-annex on Android
+in detail.
+
+The Android app now opens the webapp when a terminal window is opened.
+This is good enough for trying it out easily, but far from ideal.
+
+Fixed an EvilSplicer bug that corrupted newlines in 
+the static files served by the webapp. Now the icons in the webapp
+display properly, and the javascript works.
+
+Made the startup screen default to `/sdcard/annex` for the repository
+location, and also have a button to set up a camera repository. The camera
+repository is put in the "source" preferred content group, so it will only
+hang onto photos and videos until they're uploaded off the Android device.
+
+Quite a lot of other small fixes on Android. At this point I've tested the
+following works:
+
+* Starting webapp.
+* Making a repository, adding files.
+* All the basic webapp UI.
+
+However, I was not able to add any remote repository using only the webapp,
+due to some more problems with the network stack.
+
+* Jabber and Webdav don't quite work ("getProtocolByname: does not exist (no
+  such protocol name: tcp)").
+* SSH server fails.
+  ("Network/Socket/Types.hsc:(881,3)-(897,61): Non-exhaustive patterns in case")
+  I suspect it will work if I disable the DNS expansion code.
+
+So, that's the next thing that needs to be tackled.
+
+If you'd like to play with it in its current state, I've updated the
+Android builds to incorporate all my work so far.
diff --git a/doc/design/assistant/blog/day_254__Android_app_polishing/comment_1_37f4ff5227566ce4b3fa69fc32568841._comment b/doc/design/assistant/blog/day_254__Android_app_polishing/comment_1_37f4ff5227566ce4b3fa69fc32568841._comment
new file mode 100644
index 0000000000..7ba9f94205
--- /dev/null
+++ b/doc/design/assistant/blog/day_254__Android_app_polishing/comment_1_37f4ff5227566ce4b3fa69fc32568841._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkGCmVc5qIJaQQgG82Hc5zzBdAVdhe2JEM"
+ nickname="Bruno"
+ subject="comment 1"
+ date="2013-05-04T05:30:26Z"
+ content="""
+> The camera repository is put in the \"source\" preferred content group, so it will only hang onto photos and videos until they're uploaded off the Android device.
+
+This is very nice but I'm wondering if I take a picture that I want to share using an Android app like Facebook, would the picture get deleted before I could share it?
+
+Would there be a way to access old pictures? For example, to show them to people you meet.
+
+
+"""]]
diff --git a/doc/design/assistant/blog/day_254__Android_app_polishing/comment_2_58bbb105bdbb72bba85c3622195f43b9._comment b/doc/design/assistant/blog/day_254__Android_app_polishing/comment_2_58bbb105bdbb72bba85c3622195f43b9._comment
new file mode 100644
index 0000000000..7311b72e0f
--- /dev/null
+++ b/doc/design/assistant/blog/day_254__Android_app_polishing/comment_2_58bbb105bdbb72bba85c3622195f43b9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-05-06T15:08:19Z"
+ content="""
+As it stands, using the \"source\" repository type will tend to remove the picture from that repository pretty quickly, assuming a fast network connection. I think if you want to do things on your phone with pictures you take, it's best to use \"client\" instead. Perhaps with an archive repository set up, so you can move stuff to an \"archive\" folder when done with it to get it removed from the phone.
+
+Whether \"source\" is a good default in this case remains to be seen...
+
+It might also be possible to change \"source\" in some way to make it more useful. For example, if it held onto new files for a day after they were created, you'd have plenty of time to use them before they expire off your phone. I have posted some thoughts about this to [[partial_content]].
+"""]]
diff --git a/doc/design/assistant/blog/day_255__Debian_release_day.mdwn b/doc/design/assistant/blog/day_255__Debian_release_day.mdwn
new file mode 100644
index 0000000000..9c41ab2b2d
--- /dev/null
+++ b/doc/design/assistant/blog/day_255__Debian_release_day.mdwn
@@ -0,0 +1,26 @@
+Created a backport of the latest git-annex release for Debian 7.0 wheezy.
+Needed to backport a dozen haskell dependencies, but not too bad.
+This will be available in the backports repository once Debian
+starts accepting new packages again. I plan to keep the backport up-to-date
+as I make new releases.
+
+The cheap Android tablet I bought to do this last Android push with came
+pre-rooted from the factory. This may be why I have not seen this bug:
+[[bugs/Android_app_permission_denial_on_startup]]. If you have Android
+4.2.2 or a similar version, your testing would be helpful for me to know if
+this is a widespread problem. I have an idea about a way to work around the
+problem, but it involves writing Java code, and probably polling a file,
+ugh.
+
+Got S3 support to build for Android. Probably fails to work 
+due to the same network stack problems affecting WebDAV and Jabber.
+
+Got removable media mount detection working on Android. Bionic has an
+amusing stub for `getmntent` that prints out "FIX ME! implement
+getmntent()". But, `/proc/mounts` is there, so I just parse it.
+Also enabled the app's `WRITE_MEDIA_STORAGE` permission to allow
+access to removable media. However, this didn't seem to do anything. :(
+
+Several fixes to make the Android webapp be able to set up repositories on
+remote ssh servers. However, it fails at the last hurdle with what
+looks like a `git-annex-shell` communication problem. Almost there..
diff --git a/doc/design/assistant/blog/day_256__8bit.mdwn b/doc/design/assistant/blog/day_256__8bit.mdwn
new file mode 100644
index 0000000000..1155fd2f8c
--- /dev/null
+++ b/doc/design/assistant/blog/day_256__8bit.mdwn
@@ -0,0 +1,27 @@
+This seems a very auspicious day to have finally gotten the Android app
+doing something useful! I've fixed the last bugs with using it to set up a
+remote ssh server, which is all I need to make my Android tablet
+sync photos I take with a repository on my laptop.
+
+[[!img /android/DCIM.png alt="git-annex webapp running on Android"]]
+
+I set this up entirely in the GUI, except for needing to switch to the
+terminal twice to enter my laptop's password.
+
+How fast is it? Even several minute long videos transfer before I can
+switch from the camera app to the webapp. To get this screenshot with it in
+the process of syncing, I had to take a dozen pictures in a minute. Nice
+problem to have. ;)
+
+Have fun trying this out for yourself after tonight's autobuilds. But a
+warning: One of the bugs I fixed today had to be fixed in `git-annex-shell`,
+as run on the ssh server that the Android connects to. So the Android app
+will only work with ssh servers running a new enough version of git-annex.
+
+----
+
+Worked on geting git-annex into Debian testing, which is needed before
+the wheezy backport can go in. Think I've worked around most of the issues
+that were keeping it from building on various architectures.
+
+Caught up on some bug reports and fixed some of them.
diff --git a/doc/design/assistant/blog/day_256__8bit/comment_1_f9b50263e3997d4c5b9836a2e0a346d7._comment b/doc/design/assistant/blog/day_256__8bit/comment_1_f9b50263e3997d4c5b9836a2e0a346d7._comment
new file mode 100644
index 0000000000..b7c54ed58f
--- /dev/null
+++ b/doc/design/assistant/blog/day_256__8bit/comment_1_f9b50263e3997d4c5b9836a2e0a346d7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm8wY171R5c4u_jPmB6LU6n6Px2xePM4sE"
+ nickname="Efraim"
+ subject="comment 1"
+ date="2013-05-07T06:20:35Z"
+ content="""
+that's amazing.  I saw in one of the conference videos that you said you didn't use dropbox, and I wanted to let you know (in case you were curious) that this is one of the features that they have on their android app, that pictures and videos are uploaded to one's dropbox.  Two questions, is there a toggle or option somewhere to upload over wifi only? and did you set up the tablet's camera folder as a source directory?
+"""]]
diff --git a/doc/design/assistant/blog/day_257__rainy_day.mdwn b/doc/design/assistant/blog/day_257__rainy_day.mdwn
new file mode 100644
index 0000000000..871e5b8b56
--- /dev/null
+++ b/doc/design/assistant/blog/day_257__rainy_day.mdwn
@@ -0,0 +1,6 @@
+Put in a fix for `getprotobyname` apparently not returning anything for
+"tcp" on Android. This might fix all the special remotes there, but I don't
+know yet, because I have to rebuild a lot of Haskell libraries to try it.
+
+So, I spent most of today writing a script to build all the Haskell
+libraries for Android from scratch, with all my patches.
diff --git a/doc/design/assistant/blog/day_258__beginning_of_the_end.mdwn b/doc/design/assistant/blog/day_258__beginning_of_the_end.mdwn
new file mode 100644
index 0000000000..e2e544399f
--- /dev/null
+++ b/doc/design/assistant/blog/day_258__beginning_of_the_end.mdwn
@@ -0,0 +1,24 @@
+Fixed a nasty bug that affects at least some FreeBSD systems. It misparsed
+the output of `sha256`, and thought every file had a SHA256 of "SHA256".
+Added multiple layers of protection against checksum programs not having
+the expected output format.
+
+Lots more building and rebuilding today of Android libs than I wanted to do.
+Finally have a completly clean build, which might be able to open TCP
+connections. Will test tomorrow.
+
+In the meantime, I fired up the evil twin of my development laptop.
+It's identical, except it runs Windows.
+
+I installed the Haskell Platform for Windows on it, and removed
+some of the bloatware to free up disk space and memory for development.
+While a rather disgusting experience, I certainly have a usable Haskell
+development environment on this OS a lot faster than I did on Android!
+Cabal is happily installing some stuff, and other stuff wants me to install
+Cygwin.
+
+So, the clock on my month of working on a Windows port starts now. Since
+I've already done rather a lot of ground work that was necessary for a
+Windows port (direct mode, crippled filesystem support), and for general
+sanity and to keep everything else from screeching to a halt, I plan to
+only spend half my time messing with Windows over the next 30 days.
diff --git a/doc/design/assistant/blog/day_259__Android_dominos_toppling.mdwn b/doc/design/assistant/blog/day_259__Android_dominos_toppling.mdwn
new file mode 100644
index 0000000000..3f96b1fb0b
--- /dev/null
+++ b/doc/design/assistant/blog/day_259__Android_dominos_toppling.mdwn
@@ -0,0 +1,15 @@
+It all came together for Android today. Went from a sort of working app
+to a fully working app!
+
+* rsync.net works.
+* Box.com appears to work -- at least it's failing with the same
+  timeout I get on my linux box here behind the firewall of dialup doom.
+* XMPP is working too!
+
+These all needed various little fixes. Like loading TLS certificates from
+where they're stored on Android, and ensuring that totally crazy file
+permissions from Android (----rwxr-x for files?!) don't leak out into rsync
+repositories. Mostly though, it all just fell into place today.
+Wonderful..
+
+The Android autobuild is updated with all of today's work, so try it out.
diff --git a/doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_1_0b4a6e4893b0157e4768b46468dbbb87._comment b/doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_1_0b4a6e4893b0157e4768b46468dbbb87._comment
new file mode 100644
index 0000000000..9e1f666aa1
--- /dev/null
+++ b/doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_1_0b4a6e4893b0157e4768b46468dbbb87._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkGCmVc5qIJaQQgG82Hc5zzBdAVdhe2JEM"
+ nickname="Bruno"
+ subject="comment 1"
+ date="2013-05-10T23:52:43Z"
+ content="""
+I have a 'Connection timed out' when I try to set-up my Gtalk account on my Nexus 4 (4.2.2). I tested it at home without a web proxy.
+
+Here's a screen capture: [http://i.imgur.com/RBcNjSv.png](http://i.imgur.com/RBcNjSv.png).
+"""]]
diff --git a/doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_2_1ebc5aff5d217e1392cb7c8bb6c5156b._comment b/doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_2_1ebc5aff5d217e1392cb7c8bb6c5156b._comment
new file mode 100644
index 0000000000..cfe1347bdb
--- /dev/null
+++ b/doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_2_1ebc5aff5d217e1392cb7c8bb6c5156b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmmLfBDEDFfEOba8Ra46nsnTmoNHFsLObo"
+ nickname="Brian"
+ subject="I also see the connection timed out"
+ date="2013-05-15T00:19:34Z"
+ content="""
+Same Android device and same behavior as the above comment. While the connection attempt was being made, I switched to the terminal window and saw a connection to 173.194.46.86:5222 in the SYN_SENT state (and that connection wasn't there prior to the jabber configuration attempt).
+
+Even from my desktop, manual connection attempts to 173.194.46.86:5222 timed out.
+
+Then I ran the same jabber configuration from my desktop and it worked fin. Using netstat, I could see it connected to 74.125.133.125:5222.
+
+So is the Android version using the wrong address?
+"""]]
diff --git a/doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_3_eed7792f6142f3fc74d3c384bb16559b._comment b/doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_3_eed7792f6142f3fc74d3c384bb16559b._comment
new file mode 100644
index 0000000000..245ae7a06c
--- /dev/null
+++ b/doc/design/assistant/blog/day_259__Android_dominos_toppling/comment_3_eed7792f6142f3fc74d3c384bb16559b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-05-19T20:56:25Z"
+ content="""
+For the record, there was a bug with XMPP and SRV records. This got fixed in time for the last release.
+"""]]
diff --git a/doc/design/assistant/blog/day_25__transfer_queueing.mdwn b/doc/design/assistant/blog/day_25__transfer_queueing.mdwn
new file mode 100644
index 0000000000..b07e4592e9
--- /dev/null
+++ b/doc/design/assistant/blog/day_25__transfer_queueing.mdwn
@@ -0,0 +1,41 @@
+So as not to bury the lead, I've been hard at work on my first day in
+Nicaragua, and ** the git-annex assistant fully syncs files (including
+their contents) between remotes now !! **
+
+Details follow..
+
+Made the committer thread queue Upload Transfers when new files
+are added to the annex. Currently it tries to transfer the new content
+to *every* remote; this inefficiency needs to be addressed later.
+
+Made the watcher thread queue Download Transfers when new symlinks
+appear that point to content we don't have. Typically, that will happen
+after an automatic merge from a remote. This needs to be improved as it
+currently adds Transfers from every remote, not just those that have the
+content.
+
+This was the second place that needed an ordered list of remotes
+to talk to. So I cached such a list in the DaemonStatus state info.
+This will also be handy later on, when the webapp is used to add new
+remotes, so the assistant can know about them immediately.
+
+Added YAT (Yet Another Thread), number 15 or so, the transferrer thread
+that waits for transfers to be queued and runs them. Currently a naive
+implementation, it runs one transfer at a time, and does not do anything
+to recover when a transfer fails.
+
+Actually transferring content requires YAT, so that the transfer
+action can run in a copy of the Annex monad, without blocking
+all the assistant's other threads from entering that monad while a transfer
+is running. This is also necessary to allow multiple concurrent transfers
+to run in the future.
+
+This is a very tricky piece of code, because that thread will modify the
+git-annex branch, and its parent thread has to invalidate its cache in
+order to see any changes the child thread made. Hopefully that's the extent
+of the complication of doing this. The only reason this was possible at all
+is that git-annex already support multiple concurrent processes running
+and all making independent changes to the git-annex branch, etc.
+
+After all my groundwork this week, file content transferring is now
+fully working!
diff --git a/doc/design/assistant/blog/day_25__transfer_queueing/comment_1_59fd4f1ffe96c412f613dc86276e7dbd._comment b/doc/design/assistant/blog/day_25__transfer_queueing/comment_1_59fd4f1ffe96c412f613dc86276e7dbd._comment
new file mode 100644
index 0000000000..0a5b6c0991
--- /dev/null
+++ b/doc/design/assistant/blog/day_25__transfer_queueing/comment_1_59fd4f1ffe96c412f613dc86276e7dbd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawldKnauegZulM7X6JoHJs7Gd5PnDjcgx-E"
+ nickname="Matt"
+ subject="Source code"
+ date="2012-07-06T00:12:15Z"
+ content="""
+Hi Joey,
+
+Is the source code for git-annex assistant available somewhere?
+"""]]
diff --git a/doc/design/assistant/blog/day_25__transfer_queueing/comment_2_93bf768a67117e873af5732ecf08dc78._comment b/doc/design/assistant/blog/day_25__transfer_queueing/comment_2_93bf768a67117e873af5732ecf08dc78._comment
new file mode 100644
index 0000000000..6c0ca0781d
--- /dev/null
+++ b/doc/design/assistant/blog/day_25__transfer_queueing/comment_2_93bf768a67117e873af5732ecf08dc78._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 2"
+ date="2012-07-06T00:21:43Z"
+ content="""
+It's in the `assistant` branch of git://git-annex.branchable.com/
+"""]]
diff --git a/doc/design/assistant/blog/day_260__Windows_dev_environment.mdwn b/doc/design/assistant/blog/day_260__Windows_dev_environment.mdwn
new file mode 100644
index 0000000000..4fa2ccf5a6
--- /dev/null
+++ b/doc/design/assistant/blog/day_260__Windows_dev_environment.mdwn
@@ -0,0 +1,46 @@
+Set up my Windows development environment. For future reference, I've
+installed:
+
+* haskell platform for windows
+* cygwin
+* gcc and a full C toolchain in cygwin
+* git from upstream (probably git-annex will use this)
+* git in cygwin (the other git was not visible inside cygwin)
+* vim in cygwin
+* vim from upstream, as the cygwin vim is not very pleasant to use
+* openssh in cygwin (seems to be missing a ssh server)
+* rsync in cygwin
+* Everything that `cabal install git-annex` is able to install successfully.  
+  This includes all the libraries needed to build regular git-annex,
+  but not the webapp. Good start though.
+
+Result basically feels like a linux system that can't decide which way
+slashes in paths go. :P I've never used Cygwin before (I last used a
+Windows machine in 2003 for that matter), and it's a fairly impressive hack.
+
+----
+
+Fixed up git-annex's configure program to run on Windows (or, at least, in
+Cygwin), and have started getting git-annex to build.
+
+For now, I'm mostly stubbing out functions that use unix stuff. Gotten the
+first 44 of 300 source files to build this way.
+
+Once I get it to build, if only with stubs, I'll have a good
+idea about all the things I need to find Windows equivilants of.
+Hopefully most of it will be provided by
+<http://hackage.haskell.org/package/unix-compat-0.3.0.1>.
+
+----
+
+So that's the plan. There is a possible shortcut, rather than doing a full
+port. It seems like it would probably not be too hard to rebuild ghc inside
+Cygwin, and the resulting ghc would probably have a full POSIX emulation
+layer going through cygwin. From ghc's documentation, it looks like that's
+how ghc used to be built at some point in the past, so it would probably
+not be too hard to build it that way. With such a cygwin ghc, git-annex
+would probably build with little or no changes. However, it would be a
+git-annex targeting Cygwin, and not really a native Windows port. So
+it'd see Cygwin's emulated POSIX filesystem paths, etc. That
+seems probably not ideal for most windows users.. but if I get really stuck
+I may go back and try this method.
diff --git a/doc/design/assistant/blog/day_261__Windows_first_stage_complete.mdwn b/doc/design/assistant/blog/day_261__Windows_first_stage_complete.mdwn
new file mode 100644
index 0000000000..4d7c9582e1
--- /dev/null
+++ b/doc/design/assistant/blog/day_261__Windows_first_stage_complete.mdwn
@@ -0,0 +1,29 @@
+After working on it all day, git-annex now builds on Windows!
+
+Even better, `git annex init` works. So does `git annex status`, and
+probably more. Not `git annex add` yet, so I wasn't able to try much more.
+
+I didn't have to add many stubs today, either. Many of the missing Windows
+features were only used in code paths that made git-annex faster, but I
+could fall back to a slower code path on Windows.
+
+The things that are most problematic so far:
+
+* POSIX file locking. This is used in git-annex in several places to 
+  make it safe when multiple git-annex processes are running. I put in
+  really horrible dotfile type locking in the Windows code paths, but I
+  don't trust it at all of course.
+* There is, apparently, no way to set an environment variable in Windows
+  from Haskell. It is only possible to set up a new process' environment
+  before starting it. Luckily most of the really crucial environment
+  variable stuff in git-annex is of this latter sort, but there were
+  a few places I had to stub out code that tries to manipulate git-annex's
+  own environment.
+
+The `windows` branch has a diff of 2089 lines. It add 88 ifdefs to the code
+base. Only 12 functions are stubbed out on Windows. This could be so much
+worse.
+
+Next step: Get the test suite to build. Currently ifdefed out because it
+uses some stuff like `setEnv` and `changeWorkingDirectory` that I don't know
+how to do in Windows yet.
diff --git a/doc/design/assistant/blog/day_262__DOS_path_separators.mdwn b/doc/design/assistant/blog/day_262__DOS_path_separators.mdwn
new file mode 100644
index 0000000000..a7f6c07cca
--- /dev/null
+++ b/doc/design/assistant/blog/day_262__DOS_path_separators.mdwn
@@ -0,0 +1,14 @@
+It's remarkable that a bad decision made in 1982 can cause me to waste an
+entire day in 2013. Yes, `/` vs `\` fun time. Even though I long ago
+converted git-annex to use the haskell `</>` operator wherever it builds
+up paths (which transparently handles either type of separator), I still
+spent most of today dealing with it. Including some libraries I use that
+get it wrong. Adding to the fun is that git uses `/` internally, even on
+Windows, so Windows separated paths have to be converted when being fed
+into git.
+
+Anyway, `git annex add` now works on Windows. So does `git annex find`,
+and `git annex whereis`, and probably most query stuff.
+
+Today was very un-fun and left me with a splitting headache, so I will
+certainly *not* be working on the Windows port tomorrow.
diff --git a/doc/design/assistant/blog/day_262__DOS_path_separators/comment_1_45ecae90b22e31202c21083980d6b567._comment b/doc/design/assistant/blog/day_262__DOS_path_separators/comment_1_45ecae90b22e31202c21083980d6b567._comment
new file mode 100644
index 0000000000..a024103a77
--- /dev/null
+++ b/doc/design/assistant/blog/day_262__DOS_path_separators/comment_1_45ecae90b22e31202c21083980d6b567._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://jamesjustjames.wordpress.com/"
+ nickname="purpleidea"
+ subject="Isn't windows deprecated?"
+ date="2013-05-13T05:51:20Z"
+ content="""
+I feel bad for you, however I respect you for keeping your promise to try and hack on Windows. I had to port over some code than ran beautifully on GNU/Linux and it was more trouble than it was worth. In the end it was never used :P
+
+Cheers!
+"""]]
diff --git a/doc/design/assistant/blog/day_263_catching_up.mdwn b/doc/design/assistant/blog/day_263_catching_up.mdwn
new file mode 100644
index 0000000000..b8eadbc965
--- /dev/null
+++ b/doc/design/assistant/blog/day_263_catching_up.mdwn
@@ -0,0 +1,11 @@
+Spent some time today to get caught up on bug reports and website traffic.
+Fixed a few things.
+
+Did end up working on Windows for a while too. I got `git annex drop`
+working. But nothing that moves content quite works yet..
+
+I've run into a stumbling block with `rsync`. It thinks that
+`C:\repo` is a path on a ssh server named "C". Seems I will need to translate
+native windows paths to unix-style paths when running rsync.
+
+[[!meta date="13 May 2013"]]
diff --git a/doc/design/assistant/blog/day_263_catching_up/comment_1_9023da0573dfc81644d68128adb331a7._comment b/doc/design/assistant/blog/day_263_catching_up/comment_1_9023da0573dfc81644d68128adb331a7._comment
new file mode 100644
index 0000000000..83e7523ff9
--- /dev/null
+++ b/doc/design/assistant/blog/day_263_catching_up/comment_1_9023da0573dfc81644d68128adb331a7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkHscTHMCNvjJ6nLI1VpsBrJFI5FTwhUT4"
+ nickname="David"
+ subject="Just use Unix Paths like git does?"
+ date="2013-05-15T20:43:34Z"
+ content="""
+Can't you just use unix-style paths for your internal data structures, and wrap/patch the filesystem I/O code to convert between the two?
+"""]]
diff --git a/doc/design/assistant/blog/day_264__Windows_second_stage_complete.mdwn b/doc/design/assistant/blog/day_264__Windows_second_stage_complete.mdwn
new file mode 100644
index 0000000000..f34e8b15ed
--- /dev/null
+++ b/doc/design/assistant/blog/day_264__Windows_second_stage_complete.mdwn
@@ -0,0 +1,21 @@
+The Windows port can now do everything in the [[walkthrough]]. It can use
+both local and remote git repositories. Some special remotes work
+(directory at least; probably rsync; likely any other special remote that
+can have its dependencies built). Missing features include most special
+remotes, gpg encryption, and of course, the assistant.
+
+Also built a NullSoft installer for git-annex today. This was made very
+easy when I found the Haskell ncis library, which provides a DSL embedding
+the language used to write NullSoft installers into Haskell. So I didn't
+need to learn a new language, yay! And could pull in all my helpful
+Haskell utility libraries in the program that builds the installer.
+
+The only tricky part was: How to get git-annex onto PATH? The standard way
+to do this seems to be to use a multiple-hundred line include file. Of
+course, that file does not have any declared license..  Instead of that,
+I used a hack. The git installer for Windows adds itself to PATH, and is
+a pre-requisite for git-annex. So the git-annex installer just installs
+it into the same directory as git.
+
+So.. I'll be including this first stage Windows port, with installer in
+the next release. Anyone want to run a Windows autobuilder?
diff --git a/doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_1_42a7502d6ece75520eb59a76fdb1e2f0._comment b/doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_1_42a7502d6ece75520eb59a76fdb1e2f0._comment
new file mode 100644
index 0000000000..e7846d5fb0
--- /dev/null
+++ b/doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_1_42a7502d6ece75520eb59a76fdb1e2f0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlJ2utMQgMEYAOs3Dfc6eZRyUzt4acNXUU"
+ nickname="David"
+ subject="git on windows"
+ date="2013-05-15T04:26:48Z"
+ content="""
+Adding git to the PATH variable is an optional step in the msysgit installer, fyi.
+
+"""]]
diff --git a/doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_2_f2b11322ac87e2a36cddc035b2c3c1ea._comment b/doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_2_f2b11322ac87e2a36cddc035b2c3c1ea._comment
new file mode 100644
index 0000000000..1ff6bd542a
--- /dev/null
+++ b/doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_2_f2b11322ac87e2a36cddc035b2c3c1ea._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2013-05-15T22:30:05Z"
+ content="""
+I was thinking maybe migrating away from gitbuilder to using something like buildbot as it seems to be a better fit for this project than gitbuilder.
+"""]]
diff --git a/doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_3_ea6ee05acb946fc7e8d95e62647cfa2a._comment b/doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_3_ea6ee05acb946fc7e8d95e62647cfa2a._comment
new file mode 100644
index 0000000000..39d2a837d0
--- /dev/null
+++ b/doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_3_ea6ee05acb946fc7e8d95e62647cfa2a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-05-15T22:56:27Z"
+ content="""
+@Jimmy, would be fine with me if it works better
+"""]]
diff --git a/doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_4_9ce106baf28b7f75f7f6febd7bfcea70._comment b/doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_4_9ce106baf28b7f75f7f6febd7bfcea70._comment
new file mode 100644
index 0000000000..d3ac0df12f
--- /dev/null
+++ b/doc/design/assistant/blog/day_264__Windows_second_stage_complete/comment_4_9ce106baf28b7f75f7f6febd7bfcea70._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 4"
+ date="2013-05-16T17:31:40Z"
+ content="""
+joey, I'll poke at it on the weekend, been meaning to look for an excuse to learn a bit more about buildbot.
+"""]]
diff --git a/doc/design/assistant/blog/day_265__correctness.mdwn b/doc/design/assistant/blog/day_265__correctness.mdwn
new file mode 100644
index 0000000000..a4415b4446
--- /dev/null
+++ b/doc/design/assistant/blog/day_265__correctness.mdwn
@@ -0,0 +1,23 @@
+Laid some groundwork for porting the test suite to Windows, and getting it
+working in direct mode. That's not complete, but even starting to run the
+test suite in direct mode and looking at all the failures (many of them
+benign, like files not being symlinks) highlighted something
+I have been meaning to look into for quite a while: Why, in direct mode,
+`git-annex` doesn't operate on data staged in the index, but requires you
+commit changes to files before it'll see them. That's an annoying
+difference between direct and indirect modes.
+
+It turned out that I introduced this behavior back on
+[[January 5th|day_163__free_features]], working around a nasty
+bug I didn't understand. Bad Joey, should have root caused the bug at the
+time! But the commit says I was stuck on it for hours, and it was
+presenting as if it was a bug in `git cat-file` itself, so ok. Anyway,
+I quickly got to the bottom of it today, fixed the underlying bug (which 
+was in git-annex, not git itself), and got rid of the workaround and its
+undesired consequences. Much better.
+
+The test suite is turning up some other minor problems with direct mode.
+Should have found time to port it earlier.
+
+Also, may have fixed the issue that was preventing GTalk from working on
+Android. (Missing DNS library so it didn't do SRV lookups right.)
diff --git a/doc/design/assistant/blog/day_265__correctness/comment_1_e8959a6df87eb92310947e66c7471e97._comment b/doc/design/assistant/blog/day_265__correctness/comment_1_e8959a6df87eb92310947e66c7471e97._comment
new file mode 100644
index 0000000000..96731a43e3
--- /dev/null
+++ b/doc/design/assistant/blog/day_265__correctness/comment_1_e8959a6df87eb92310947e66c7471e97._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkF8_uQjLYm5Mf5F_JuVW-BxlvzpWjvR_o"
+ nickname="Andrew"
+ subject="Android success"
+ date="2013-05-16T04:14:09Z"
+ content="""
+I now have my android phone and laptop talking with GTalk and used a remote ssh server to synchronise files.
+
+Photos are flowing from my phone to my laptop quite happily. Magic.
+
+Would help to exclude .thumbnails from the DCIM directory on the phone though...
+"""]]
diff --git a/doc/design/assistant/blog/day_265__correctness/comment_2_0cb953fcc085eedb34e65c227309ede7._comment b/doc/design/assistant/blog/day_265__correctness/comment_2_0cb953fcc085eedb34e65c227309ede7._comment
new file mode 100644
index 0000000000..cf936cf2aa
--- /dev/null
+++ b/doc/design/assistant/blog/day_265__correctness/comment_2_0cb953fcc085eedb34e65c227309ede7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmubB1Sj2rwFoVdZYvGV0ACaQUJQyiJXJI"
+ nickname="Paul"
+ subject="GTalk/XMPP"
+ date="2013-05-19T09:58:51Z"
+ content="""
+Google seems to be deprecating XMPP and GTalk. Can git-annex assistant use other XMPP services? And does it handle federation correctly?
+"""]]
diff --git a/doc/design/assistant/blog/day_265__correctness/comment_3_df57628a8969af2995732e7ea2a0fae3._comment b/doc/design/assistant/blog/day_265__correctness/comment_3_df57628a8969af2995732e7ea2a0fae3._comment
new file mode 100644
index 0000000000..27bee6171b
--- /dev/null
+++ b/doc/design/assistant/blog/day_265__correctness/comment_3_df57628a8969af2995732e7ea2a0fae3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-05-19T19:12:59Z"
+ content="""
+git-annex can use any xmpp server.  The only thing that would need to be changed if google talk went away tomorrow is changing some text that suggests entering one's gmail address, to some other text that suggests some other xmpp server to use.
+
+However, I am skeptical about echo chamber conclusions (and/or tech press) about what google is, or is not doing, or is or is not planning to do.
+"""]]
diff --git a/doc/design/assistant/blog/day_266__release_day.mdwn b/doc/design/assistant/blog/day_266__release_day.mdwn
new file mode 100644
index 0000000000..8e373c94c5
--- /dev/null
+++ b/doc/design/assistant/blog/day_266__release_day.mdwn
@@ -0,0 +1,6 @@
+Made a release.
+
+I am firming up some ideas for post-kickstarter. More on that later.
+
+In the process of setting up a Windows autobuilder, using the same
+jenkins installation that is used to autobuild msysgit.
diff --git a/doc/design/assistant/blog/day_266__release_day/comment_1_92c8d1d9216b46b07dfe69bbc77a923e._comment b/doc/design/assistant/blog/day_266__release_day/comment_1_92c8d1d9216b46b07dfe69bbc77a923e._comment
new file mode 100644
index 0000000000..39ff885413
--- /dev/null
+++ b/doc/design/assistant/blog/day_266__release_day/comment_1_92c8d1d9216b46b07dfe69bbc77a923e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmubB1Sj2rwFoVdZYvGV0ACaQUJQyiJXJI"
+ nickname="Paul"
+ subject="Continued work"
+ date="2013-05-17T07:44:38Z"
+ content="""
+Can we continue to fund your work in some way?
+"""]]
diff --git a/doc/design/assistant/blog/day_267__windows_autobuilder.mdwn b/doc/design/assistant/blog/day_267__windows_autobuilder.mdwn
new file mode 100644
index 0000000000..b9e28438de
--- /dev/null
+++ b/doc/design/assistant/blog/day_267__windows_autobuilder.mdwn
@@ -0,0 +1,9 @@
+git-annex is now autobuilt for Windows on the same Jenkins farm that
+builds msysgit. Thanks for Yury V. Zaytsev for providing that! Spent about
+half of today setting up the build.
+
+Got the test suite to pass in direct mode, and indeed in direct mode
+on a FAT file system. Had to fix one corner case in direct mode `git annex
+add`. Unfortunately it still doesn't work on Android; somehow `git clone` 
+of a local repository is broken there. Also got the test suite to build,
+and run on Windows, though it fails pretty miserably.
diff --git a/doc/design/assistant/blog/day_267__windows_autobuilder/comment_1_978b584d86395f2f621b0e1f7c5e70d7._comment b/doc/design/assistant/blog/day_267__windows_autobuilder/comment_1_978b584d86395f2f621b0e1f7c5e70d7._comment
new file mode 100644
index 0000000000..ccda628ae8
--- /dev/null
+++ b/doc/design/assistant/blog/day_267__windows_autobuilder/comment_1_978b584d86395f2f621b0e1f7c5e70d7._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkDb5BRI8VzliQuKRVM7NwMdudvxiUNPHI"
+ nickname="Richard"
+ subject="git annex add on Win7 NTFS"
+ date="2013-06-14T09:26:24Z"
+ content="""
+Hello I took latest build from download #243.
+
+running in CMD or in GIT bash as admin user.
+
+git annex add, fails on all files.
+
+Example:
+add IS Breast/Changing IP Address of The Server/flowplayer-3.2.4.min.js (checksum...)
+git-annex: C:\development storage\.git\annex\objects\e4b\168\SHA256E-s15723--f6950
+bd995674741c600d0465a333f5491d5713e8ac2e3fc57d61cccadba522d.min.js\SHA256E-s15723--f6950bd995674741c600d0465a333f5491d57
+13e8ac2e3fc57d61cccadba522d.min.js.cache: openFile: does not exist (No such file or directory)
+
+Am I doing something wrong? I somehow understood that this should be ok now.
+Thanks for your kind answer
+"""]]
diff --git a/doc/design/assistant/blog/day_267__windows_autobuilder/comment_2_8f978d2811c8fbf11e3d12f245bdb52b._comment b/doc/design/assistant/blog/day_267__windows_autobuilder/comment_2_8f978d2811c8fbf11e3d12f245bdb52b._comment
new file mode 100644
index 0000000000..796dea21e7
--- /dev/null
+++ b/doc/design/assistant/blog/day_267__windows_autobuilder/comment_2_8f978d2811c8fbf11e3d12f245bdb52b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 2"
+ date="2013-06-25T17:12:17Z"
+ content="""
+That is the same problem that is currently making the test suite fail on the windows autobuilder.
+
+I don't know what is causing this problem, and have not been able to reproduce it locally in order to debug it.
+"""]]
diff --git a/doc/design/assistant/blog/day_268__core_monad_change.mdwn b/doc/design/assistant/blog/day_268__core_monad_change.mdwn
new file mode 100644
index 0000000000..2704bb090e
--- /dev/null
+++ b/doc/design/assistant/blog/day_268__core_monad_change.mdwn
@@ -0,0 +1,9 @@
+Today I had to change the implementation of the Annex monad. The old one
+turned out to be buggy around exception handling -- changes to state
+recorded by code that ran in an exception handler were discarded when it
+threw an exception. Changed from a StateT monad to a ReaderT with
+a MVar. Really deep-level change, but it went off without a
+hitch!
+
+Other than that it was a bug catch up day. Almost entirely caught up once
+more.
diff --git a/doc/design/assistant/blog/day_269__bugfixes.mdwn b/doc/design/assistant/blog/day_269__bugfixes.mdwn
new file mode 100644
index 0000000000..7cbdb58633
--- /dev/null
+++ b/doc/design/assistant/blog/day_269__bugfixes.mdwn
@@ -0,0 +1,14 @@
+Worked on several important bug fixes today. One affects automatic merge
+confict resolution, and can case data loss in direct mode, so I will be
+making a release with the fix tomorrow.
+
+Practiced TDD today, and good thing too. The new improved test suite
+turned up a really subtle bug involving the git-annex branch vector
+clocks-ish code, which I also fixed.
+
+Also, fixes to the OSX autobuilds. One of them had a broken gpg, which is
+now fixed. The other one is successfully building again. And, I'm switching
+the Linux autobuilds to build against Debian stable, since testing has a
+new version of libc now, which would make the autobuilds not work on older
+systems. Getting an amd64 chroot into shape is needing rather a lot
+of backporting of build dependencies, which I already did for i386.
diff --git a/doc/design/assistant/blog/day_26__dying_drives.mdwn b/doc/design/assistant/blog/day_26__dying_drives.mdwn
new file mode 100644
index 0000000000..109ceb19ec
--- /dev/null
+++ b/doc/design/assistant/blog/day_26__dying_drives.mdwn
@@ -0,0 +1,28 @@
+My laptop's SSD died this morning. I had some work from yesterday
+committed to the git repo on it, but not pushed as it didn't build.
+Luckily I was able to get that off the SSD, which is now a read-only
+drive -- even mounting it fails with fsck write errors.
+
+Wish I'd realized the SSD was dying before the day before my trip to
+Nicaragua..
+Getting back to a useful laptop used most of my time and energy today.
+
+I did manage to fix transfers to not block the rest of the assistant's
+threads. Problem was that, without Haskell's threaded runtime, waiting
+on something like a rsync command blocks all threads. To fix this,
+transfers now are run in separate processes.
+
+Also added code to allow multiple transfers to run at once. Each transfer
+takes up a slot, with the number of free slots tracked by a `QSemN`.
+This allows the transfer starting thread to block until a slot frees up,
+and then run the transfer.
+
+This needs to be extended to be aware of transfers initiated by remotes.
+The transfer watcher thread should detect those starting and stopping 
+and update the `QSemN` accordingly. It would also be nice if transfers
+initiated by remotes would be delayed when there are no free slots for them
+... but I have not thought of a good way to do that.
+
+There's a bug somewhere in the new transfer code, when two transfers are
+queued close together, the second one is lost and doesn't happen.
+Would debug this, but I'm spent for the day.
diff --git a/doc/design/assistant/blog/day_270__release_and_xmpp.mdwn b/doc/design/assistant/blog/day_270__release_and_xmpp.mdwn
new file mode 100644
index 0000000000..eb28f97bde
--- /dev/null
+++ b/doc/design/assistant/blog/day_270__release_and_xmpp.mdwn
@@ -0,0 +1,39 @@
+Got the bugfix release out.
+
+Tobias contributed [[tips/megaannex]], which allows using mega.co.nz as a
+special remote. Someone should do this with Flickr, using
+[filr](https://github.com/ricardobeat/filr). I have improved the
+[[special_remotes/hook]] special remote to make it easier to create
+and use reusable programs like megaannex.
+
+But, I am too busy rewriting lots of the XMPP code to join in the
+special remote fun. Spent all last night staring at protocol traces and
+tests, and came to the conclusion that it's working well at the basic
+communication level, but there are a lot of bugs above that level. This
+mostly shows up as one side refusing to push changes made to its tree,
+although it will happily merge in changes sent from the other side.
+
+The NetMessanger code, which handles routing messages to git commands and
+queuing other messages, seems to be just wrong. This is code I wrote in the
+fall, and have basically not touched since. And it shows. Spent 4 hours
+this morning rewriting it. Went all Erlang and implemented message inboxes
+using STM. I'm much more confident it won't drop messages on the
+floor, which the old code certainly did do sometimes.
+
+Added a check to avoid unnecessary pushes over XMPP. Unfortunately, this
+required changing the protocol in a way that will make previous versions of
+git-annex refuse to accept any pushes advertised by this version. Could not
+find a way around that, but there were so many unnecessary pushes happening
+(and possibly contributing to other problems) that it seemed worth the
+upgrade pain.
+
+Will be beating on XMPP a bit more. There is one problem I was seeing
+last night that I cannot reproduce now. It may have been masked or even
+fixed by these changes, but I need to verify that, or put in a workaround.
+It seemed that sometimes this code in `runPush` would run the setup
+and the action, but either the action blocked forever, or an exception
+got through and caused the cleanup not to be run.
+
+[[!format haskell """
+        r <- E.bracket_ setup cleanup <~> a
+"""]]
diff --git a/doc/design/assistant/blog/day_271__more_xmpp.mdwn b/doc/design/assistant/blog/day_271__more_xmpp.mdwn
new file mode 100644
index 0000000000..14e734a2d3
--- /dev/null
+++ b/doc/design/assistant/blog/day_271__more_xmpp.mdwn
@@ -0,0 +1,31 @@
+Tobias has been busy again today, creating a [[/tips/flickrannex]]
+special remote! Meanwhile, I'm thinking about providing a
+[[more complete interface|/todo/support_for_writing_external_special_remotes]]
+so that special remote programs not written in Haskell can do some of the
+things the hook special remote's simplicity doesn't allow.
+
+Finally realized last night that the main problem with the XMPP push code
+was an inversion of control. Reworked it so now there are two new threads,
+XMPPSendpack and XMPPReceivePack, each with their own queue of push
+initiation requests, that run the pushes. This is a lot easier to
+understand, probably less buggy, and lets it apply some smarts to squash
+duplicate actions and pick the best request to handle next.
+
+Also made the XMPP client send pings to detect when it has been disconnected
+from the server. Currently every 120 seconds, though that may change. Testing
+showed that without this, it did not notice (for at least 20 minutes) when 
+it lost routing to the server. Not sure why -- I'd think the TCP connections
+should break and this throw an error -- but this will also handle any idle
+disconnection problems that some XMPP servers might have.
+
+While writing that, I found myself writing this jem using
+[async](http://hackage.haskell.org/package/async), which has a comment
+much longer than the code, but basically we get 4 threads that are all
+linked, so when any dies, all do.
+
+[[!format haskell """
+pinger `concurrently` sender `concurrently` receiver
+"""]]
+
+Anyway, I need to run some long-running XMPP push tests to see if I've
+really ironed out all the bugs.
diff --git a/doc/design/assistant/blog/day_272__fuzz_tester.mdwn b/doc/design/assistant/blog/day_272__fuzz_tester.mdwn
new file mode 100644
index 0000000000..9d352f70a3
--- /dev/null
+++ b/doc/design/assistant/blog/day_272__fuzz_tester.mdwn
@@ -0,0 +1,37 @@
+The Android app should work on some more devices now, where hard linking to
+busybox didn't work. Now it installs itself using symlinks.
+
+Pushed a point release so `cabal install git-annex` works again. And,
+I'm really happy to see that the 4.20130521 release has autobuilt on all
+Debian architectures, and will soon be replacing the old 3.20120629 version
+in testing. (Well, once a libffi transition completes..)
+
+TobiasTheMachine has done it again: [[tips/googledriveannex]]  
+
+-----
+
+I spent most of today building a fuzz tester for the assistant. `git annex
+fuzztest` will (once you find the special runes to allow it to run) create
+random files in the repository, move them around, delete them, move
+directory trees around, etc. The plan is to use this to run some long
+duration tests with eg, XMPP, to make sure the assistant keeps things
+in shape after a lot of activity. It logs in machine-readable format, 
+so if it turns up a bug I may even be able to use it to reproduce the same
+bug (fingers crossed).
+
+I was able to use QuickCheck to generate random data for some parts of the fuzz
+tester. (Though the actual file names it uses are not generated using
+QuickCheck.) Liked this part:
+
+[[!format haskell """
+instance Arbitrary FuzzAction where
+        arbitrary = frequency
+                [ (100, FuzzAdd <$> arbitrary)
+                , (10, FuzzDelete <$> arbitrary)
+                , (10, FuzzMove <$> arbitrary <*> arbitrary)
+                , (10, FuzzModify <$> arbitrary)
+                , (10, FuzzDeleteDir <$> arbitrary)
+                , (10, FuzzMoveDir <$> arbitrary <*> arbitrary)
+                , (10, FuzzPause <$> arbitrary)
+                ]
+"""]]
diff --git a/doc/design/assistant/blog/day_273-274__fun.mdwn b/doc/design/assistant/blog/day_273-274__fun.mdwn
new file mode 100644
index 0000000000..2fa12003a5
--- /dev/null
+++ b/doc/design/assistant/blog/day_273-274__fun.mdwn
@@ -0,0 +1,19 @@
+Got caught up on some bug reports yesterday. The main one was odd behavior
+of the assistant when the repository was in manual mode. A recent change to
+the preferred content expression caused it. But the expression was not
+broken. The problem was in the parser, which got the parentheses wrong
+in this case. I had to mostly rewrite the parser, unfortunately. I've tested
+the new one fairly extensively -- on the other hand this bug lurked in the
+old parser for several years (this same code is used for matching files
+with command-line parameters).
+
+Just as I finished with that, I noticed another bug. Turns out git-cat-file
+doesn't reload the index after it's started. So last week's changes to make
+git-annex check the state of files in the index won't work when using the
+assistant. Luckily there was an easy workaround for this.
+
+Today I finished up some robustness fixes, and added to the test suite
+checks for preferred content expressions, manual mode, etc.
+
+I've started a stress test, syncing 2 repositories over XMPP, with the fuzz
+tester running in each to create lots of changes to keep in sync.
diff --git a/doc/design/assistant/blog/day_275__working_hard_or.mdwn b/doc/design/assistant/blog/day_275__working_hard_or.mdwn
new file mode 100644
index 0000000000..b667ba08a1
--- /dev/null
+++ b/doc/design/assistant/blog/day_275__working_hard_or.mdwn
@@ -0,0 +1,12 @@
+Fuzz tester has found several interesting bugs that I've now fixed. It's
+even found a bug in my fixes. Most of the problems the fuzz testing has
+found have had to do with direct mode merges, and automatic merge conflict
+resoltion. Turns out the second level of automatic merge conflict
+resolution (where the changes made to resolve a merge conflict themselves
+turn out conflict in a later merge) was buggy, for example.
+
+So, didn't really work a lot today -- was not intending to work at all
+actually -- but have still accomplished a lot.
+
+(Also, Tobias contributed [[tips/dropboxannex]] .. I'll be curious to see
+what the use case for that is, if any!)
diff --git a/doc/design/assistant/blog/day_276__fuzzing_continues.mdwn b/doc/design/assistant/blog/day_276__fuzzing_continues.mdwn
new file mode 100644
index 0000000000..d6fc88b057
--- /dev/null
+++ b/doc/design/assistant/blog/day_276__fuzzing_continues.mdwn
@@ -0,0 +1,12 @@
+The fuzz testing found a file descriptor leak in the XMPP git push code.
+The assistant seems to hold up under fuzzing for quite a while now.
+
+Have started trying to work around some versions of Android not letting 
+the `am` command be used by regular users to open a web browser on an URL.
+Here is my current crazy plan: Hack the terminal emulator's title setting
+code, to get a new escape sequence that requests an URL be opened. This
+assumes I can just use `startActivity()` from inside the app and it will
+work. This may sound a little weird, but it avoids me needing to set up a
+new communications channel from the assistant to the Java app. Best of all,
+I have to write very little Java code. I last wrote Java code in 1995, so
+writing much more is probably a good thing to avoid.
diff --git a/doc/design/assistant/blog/day_276__fuzzing_continues/comment_1_f5dd0658511a1063c2eb025b0fe98426._comment b/doc/design/assistant/blog/day_276__fuzzing_continues/comment_1_f5dd0658511a1063c2eb025b0fe98426._comment
new file mode 100644
index 0000000000..4a54fa1880
--- /dev/null
+++ b/doc/design/assistant/blog/day_276__fuzzing_continues/comment_1_f5dd0658511a1063c2eb025b0fe98426._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkGCmVc5qIJaQQgG82Hc5zzBdAVdhe2JEM"
+ nickname="Bruno"
+ subject="comment 1"
+ date="2013-05-28T03:23:50Z"
+ content="""
+Does the Android application use a [WakeLock](https://developer.android.com/reference/android/os/PowerManager.WakeLock.html) to ensure syncing happens even if the device screen goes off?
+
+I'm under the impression that it doesn't since it took a very long time to sync the first time (before I used the terminal's options to prevent the phone from sleeping).
+
+I think that option shouldn't be left on since it would waste the battery and I think the application should block sleep mode only when syncing.
+
+I might be wrong. I never had to use a WakeLock on Android yet.
+"""]]
diff --git a/doc/design/assistant/blog/day_276__fuzzing_continues/comment_2_a56c4c26a9e7bb8cfe3f598dbeed0813._comment b/doc/design/assistant/blog/day_276__fuzzing_continues/comment_2_a56c4c26a9e7bb8cfe3f598dbeed0813._comment
new file mode 100644
index 0000000000..3a98c8a092
--- /dev/null
+++ b/doc/design/assistant/blog/day_276__fuzzing_continues/comment_2_a56c4c26a9e7bb8cfe3f598dbeed0813._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-05-29T16:30:20Z"
+ content="""
+The terminal has options to take the wake lock, and also the wifi lock, in its menu.
+
+Currently this has to be managed manually. The assistant does not try to deal with this.
+"""]]
diff --git a/doc/design/assistant/blog/day_277__private_static_protected_void.mdwn b/doc/design/assistant/blog/day_277__private_static_protected_void.mdwn
new file mode 100644
index 0000000000..dbe2244a02
--- /dev/null
+++ b/doc/design/assistant/blog/day_277__private_static_protected_void.mdwn
@@ -0,0 +1,19 @@
+Yeah, Java hacking today. I have something that I think should deal with
+the [[bugs/Android_app_permission_denial_on_startup]] problem. Added a "Open
+WebApp" item to the terminal's menu, which should behave as advertised.
+This is available in the Android daily build now, if your device has that
+problem.
+
+I was not able to get the escape sequence hack to work. I had no difficulty
+modifying the terminal to send an intent to open an url when it received a
+custom escape sequence. But sending the intent just seemed to lock up the
+terminal for a minute without doing anything. No idea why. I had to propigate a
+context object in to the terminal emulator through several layers of objects.
+Perhaps that doesn't really work despite what I [read on stackoverflow](http://stackoverflow.com/questions/9051849/opening-a-link-in-the-browser/9052208#9052208).
+
+Anyway, that's all I have time to do. It would be nice if I, or some other
+interested developer who is more comfortable with Java, could write a custom
+Android frontend app, that embedded a web browser widget for the webapp,
+rather than abusing the terminal this way. OTOH, this way does provide the
+bonus of a pretty good terminal and git shell environment for Android to go
+with git-annex.
diff --git a/doc/design/assistant/blog/day_278__winding_down.mdwn b/doc/design/assistant/blog/day_278__winding_down.mdwn
new file mode 100644
index 0000000000..824feceaf5
--- /dev/null
+++ b/doc/design/assistant/blog/day_278__winding_down.mdwn
@@ -0,0 +1,11 @@
+Winding down work for now, as I prepare for a week at the beach starting in
+2 days. That will be followed by a talk about git-annex at
+[SELF2013](http://www.southeastlinuxfest.org/) in Charlotte NC on June 9th.
+
+Bits & pieces today.
+
+Want to get a release out RSN, but I'm waiting for the previous release
+to finally reach Debian testing, which should happen on Saturday. Luckily I
+hear the beach house has wifi, so I will probably end up cutting the
+release from there. Only other thing I might work on next week is updating
+to yesod 1.2.
diff --git a/doc/design/assistant/blog/day_279__final_release_prep.mdwn b/doc/design/assistant/blog/day_279__final_release_prep.mdwn
new file mode 100644
index 0000000000..f209c1ccb6
--- /dev/null
+++ b/doc/design/assistant/blog/day_279__final_release_prep.mdwn
@@ -0,0 +1,14 @@
+Landed two final changes before the release..
+
+First, made git-annex detect if any of the several long-running git process
+it talks to have died, and, if yes, restart them. My stress test is reliably
+able to get at least `git cat-file` to crash, and while I don't know why (and
+obviously should follow up by getting a core dump and stack trace of it),
+the assistant needs to deal with this to be robust.
+
+Secondly, wrote rather a lot of Java code to better open the web browser
+when the Android app is started. A thread listens for URLs to be written to
+a FIFO. Creating a FIFO from fortran&#94;Wjava code is .. interesting. Glad to
+see the back of the `am` command; it did me no favors.
+
+AFK
diff --git a/doc/design/assistant/blog/day_27__robust_transfers.mdwn b/doc/design/assistant/blog/day_27__robust_transfers.mdwn
new file mode 100644
index 0000000000..49ace417b7
--- /dev/null
+++ b/doc/design/assistant/blog/day_27__robust_transfers.mdwn
@@ -0,0 +1,31 @@
+Spent most of the day making file content transfers robust. There were lots
+of bugs, hopefully I've fixed most of them. It seems to work well now,
+even when I throw a lot of files at it.
+
+One of the changes also sped up transfers; it no longer roundtrips to the
+remote to verify it has a file. The idea here is that when the assistant is
+running, repos should typically be fairly tightly synced to their remotes
+by it, so some of the extra checks that the `move` command does are
+unnecessary.
+
+Also spent some time trying to use ghc's threaded runtime, but continue to
+be baffled by the random hangs when using it. This needs fixing eventually;
+all the assistant's threads can potentially be blocked when it's waiting on
+an external command it has run.
+
+Also changed how transfer info files are locked. The lock file is now
+separate from the info file, which allows the TransferWatcher thread to
+notice when an info file is created, and thus actually track transfers
+initiated by remotes.
+
+---
+
+I'm fairly close now to merging the `assistant` branch into `master`.
+The data syncing code is very brute-force, but it will work well enough
+for a first cut.
+
+Next I can either add some repository network mapping, and use graph
+analysis to reduce the number of data transfers, or I can move on to the
+[[webapp]]. Not sure yet which I'll do. It's likely that since DebConf
+begins tomorrow I'll put off either of those big things until after the
+conference.
diff --git a/doc/design/assistant/blog/day_28-35__threaded_runtime_tarpit.mdwn b/doc/design/assistant/blog/day_28-35__threaded_runtime_tarpit.mdwn
new file mode 100644
index 0000000000..612dfc514c
--- /dev/null
+++ b/doc/design/assistant/blog/day_28-35__threaded_runtime_tarpit.mdwn
@@ -0,0 +1,17 @@
+I didn't plan to work on git-annex much while at DebConf, because the conference
+always prevents the kind of concentration I need. But I unexpectedly also had to deal
+with [three dead drives](http://joeyh.name/blog/entry/I_am_become_Joey_destroyer_of_drives/)
+and illness this week. 
+
+That said, I have been trying to debug a problem with git-annex and Haskell's threaded
+runtime all week. It just hangs, randomly. No luck so far isolating why, although I now
+have a branch that hangs fairly reliably, and in which I am trying to whittle the entire
+git-annex code base (all 18 thousand lines!) into a nice test case.
+
+This threaded runtime problem doesn't affect the assistant yet, but if I want to use
+Yesod in developing the webapp, I'll need the threaded runtime, and using the threaded
+runtime in the assistant generally would make it more responsive and less hacky.
+
+Since this is a task I can work on without much concentration, I'll probably keep beating
+on it until I return home. Then I need to spend some quality thinking time on where
+to go next in the assistant.
diff --git a/doc/design/assistant/blog/day_280__yesod.mdwn b/doc/design/assistant/blog/day_280__yesod.mdwn
new file mode 100644
index 0000000000..ff02fd02ba
--- /dev/null
+++ b/doc/design/assistant/blog/day_280__yesod.mdwn
@@ -0,0 +1,7 @@
+Today marks 1 year since I started working on the git-annex assistant. 280
+solid days of work!
+
+As a background task here at the beach I've been porting git-annex to yesod
+1.2. Finished it today, earlier than expected, and also managed to keep it
+building with older versions. Some tricks kept the number of
+ifdefs reasonably low.
diff --git a/doc/design/assistant/blog/day_280__yesod/comment_1_a42213a8cef71f2b54db18606028136d._comment b/doc/design/assistant/blog/day_280__yesod/comment_1_a42213a8cef71f2b54db18606028136d._comment
new file mode 100644
index 0000000000..3a99c22108
--- /dev/null
+++ b/doc/design/assistant/blog/day_280__yesod/comment_1_a42213a8cef71f2b54db18606028136d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkGCmVc5qIJaQQgG82Hc5zzBdAVdhe2JEM"
+ nickname="Bruno"
+ subject="comment 1"
+ date="2013-06-04T12:51:20Z"
+ content="""
+Congrats on the first year Joey!
+"""]]
diff --git a/doc/design/assistant/blog/day_281__back.mdwn b/doc/design/assistant/blog/day_281__back.mdwn
new file mode 100644
index 0000000000..03e42c0a59
--- /dev/null
+++ b/doc/design/assistant/blog/day_281__back.mdwn
@@ -0,0 +1,37 @@
+Slowly getting through the bugs that were opened while I was on vacation and
+then I'll try to get to all the comments. 60+ messages to go.
+
+Got git-annex working better on encfs, which does not support hard links in
+paranoid mode. Now git-annex can be used in indirect mode, it doesn't force
+direct mode when hard links are not supported.
+
+Made the Android repository setup special case generate a .gitignore file
+to ignore thumbnails. Which will only start working once the assistant
+gets .gitignore support.
+
+-----
+
+Been thinking today about encrypting XMPP traffic, particularly git push
+data. Of course, XMPP is already encrypted, but that doesn't hide it from
+those entities who have access to the XMPP server or its encryption key.
+So adding client-to-client encryption has been on the TODO list all along.
+
+OTR would be a great way to do it. But I worry that the confirmation steps
+OTR uses to authenticate the recipient would make the XMPP pairing UI harder
+to get through.
+
+Particularly when pairing your own devices over XMPP, with several devices
+involved, you'd need to do a lot of cross-confirmations. It would be better
+there, I think, to just use a shared secret for authentication. (The need
+to enter such a secret on each of your devices before pairing them would
+also provide a way to use different repositories with the same XMPP
+account, so 2birds1stone.)
+
+Maybe OTR confirmations would be ok when setting up sharing with a friend.
+If OTR was not used there, and it just did a Diffie-Hellman key exchange
+during the pairing process, it could be attacked by an active MITM spoofing
+attack. The attacker would then know the keys, and could decrypt future
+pushes. How likely is such an attack? This goes far beyond what we're
+hearing about. Might be best to put in some basic encryption now, so
+we don't have to worry about pushes being passively recorded on the
+server. Comments appreciated.
diff --git a/doc/design/assistant/blog/day_281__back/comment_1_128809c5a2a9f5cc345a10fdbf55be01._comment b/doc/design/assistant/blog/day_281__back/comment_1_128809c5a2a9f5cc345a10fdbf55be01._comment
new file mode 100644
index 0000000000..a120cc2d32
--- /dev/null
+++ b/doc/design/assistant/blog/day_281__back/comment_1_128809c5a2a9f5cc345a10fdbf55be01._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlJ2utMQgMEYAOs3Dfc6eZRyUzt4acNXUU"
+ nickname="David"
+ subject="comment 1"
+ date="2013-06-10T23:42:20Z"
+ content="""
+If you do a D-H key exchange and display the key fingerprint on both devices, that would be a pretty strong disincentive against XMPP servers doing a MitM. You only need one victim to casually notice a discrepancy, and it leaves behind a strong proof of tampering.
+"""]]
diff --git a/doc/design/assistant/blog/day_281__back/comment_2_6d0bbdf6ebaff9da399804570f0e606d._comment b/doc/design/assistant/blog/day_281__back/comment_2_6d0bbdf6ebaff9da399804570f0e606d._comment
new file mode 100644
index 0000000000..884b2484ef
--- /dev/null
+++ b/doc/design/assistant/blog/day_281__back/comment_2_6d0bbdf6ebaff9da399804570f0e606d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-06-10T23:50:27Z"
+ content="""
+David, along those lines, if a value derived from the D-H key were committed to the git repo, then the MITM would need to maintain two distinct git trees, and translate between them on an ongoing basis. Which is harder. And then if both clients at any point communicated via another channel (ie, local pairing), the forgery would be very noticeable.
+
+Which is not to say that this is necessarily good enough..
+"""]]
diff --git a/doc/design/assistant/blog/day_282-283__caught_up.mdwn b/doc/design/assistant/blog/day_282-283__caught_up.mdwn
new file mode 100644
index 0000000000..b097e8d248
--- /dev/null
+++ b/doc/design/assistant/blog/day_282-283__caught_up.mdwn
@@ -0,0 +1,18 @@
+Got caught up on my backlog yesterday.
+
+Part of adding files in direct mode involved removing write permission from
+them temporarily. That turned out to cause problems with some programs that
+open a file repeatedly, and was generally against the principle that direct
+mode files are always directly available. Happily, I was able to get rid of
+that without sacrificing any safety.
+
+Improved syncing to bare repositories. Normally syncing pushes to a
+synced/master branch, which is good for non-bare repositories since git
+does not allow pushing to the currently checked out branch. But for bare
+repositories, this could leave them without a master branch, so cloning
+from them wouldn't work. A funny thing is that git does not really have any
+way to tell if a remote repository is bare or not. Anyway, I did put in a
+fix, at the expense of pushing twice (but the git data should only be
+transferred once anyway).
+
+
diff --git a/doc/design/assistant/blog/day_284__porting.mdwn b/doc/design/assistant/blog/day_284__porting.mdwn
new file mode 100644
index 0000000000..f0648b0e1a
--- /dev/null
+++ b/doc/design/assistant/blog/day_284__porting.mdwn
@@ -0,0 +1,13 @@
+Today I got to deal with bugs on Android (busted use of `cp` among other
+problems), Windows (fixed a strange hang when adding several files), and
+Linux (`.desktop` files suck and Wine ships a particularly nasty one).
+Pretty diverse!
+
+Did quite a lot of research and thinking on XMPP encryption yesterday, but
+have not run any code yet (except for trying out a D-H exchange in `ghci`).
+I have listed several options on the [[XMPP]] page.
+
+Planning to take a look at
+[[bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time]]
+tomorrow; maybe I can come up with a workaround to avoid it behaving so
+badly in that case.
diff --git a/doc/design/assistant/blog/day_285__fixed_the_archive_directory_loop.mdwn b/doc/design/assistant/blog/day_285__fixed_the_archive_directory_loop.mdwn
new file mode 100644
index 0000000000..252dc367f7
--- /dev/null
+++ b/doc/design/assistant/blog/day_285__fixed_the_archive_directory_loop.mdwn
@@ -0,0 +1,23 @@
+Yay, I fixed the
+[[bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time]]
+bug!
+At least in direct mode, which thanks to its associated files tracking
+knows when a given file has another file in the repository with the same
+content. Had not realized the behavior in direct mode was so bad, or the
+fix so relatively easy. Pity I can't do the same for indirect mode, but
+the problem is much less serious there.
+
+That was this weekend. Today, I nearly put out a new release (been 2 weeks
+since the last one..), but ran out of time in the end, and need to get the
+OSX autobuilder fixed first, so have deferred it until Friday.
+
+However, I did make some improvements today.
+Added an `annex.debug` git config setting, so debugging can
+be turned on persistently. People seem to expect that to happen when
+checking the checkbox in the webapp, so now it does.
+
+Fixed 3 or 4 bugs in the Windows port. Which actually, has users now, or
+at least one user. It's very handy to actually get real world testing of
+that port.
+
+[[!meta date="Mon, 17 Jun 2013 17:14:04 -0400"]]
diff --git a/doc/design/assistant/blog/day_285__fixed_the_archive_directory_loop/comment_1_1065e756dc6d66aefd214eb8ac5ebe1d._comment b/doc/design/assistant/blog/day_285__fixed_the_archive_directory_loop/comment_1_1065e756dc6d66aefd214eb8ac5ebe1d._comment
new file mode 100644
index 0000000000..41494c02f3
--- /dev/null
+++ b/doc/design/assistant/blog/day_285__fixed_the_archive_directory_loop/comment_1_1065e756dc6d66aefd214eb8ac5ebe1d._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2013-06-26T08:36:33Z"
+ content="""
+Been pretty bad with keeping the osx builder going, but this should fix it...
+
+
+<pre>
+[jtang@x00 build ((cfb577d...))]$ git diff
+diff --git a/.gitignore b/.gitignore
+index 93bd49e..717b58a 100644
+--- a/.gitignore
++++ b/.gitignore
+@@ -24,3 +24,5 @@ cabal-dev
+ .virthualenv
+ tags
+ Setup
++*.hi
++*.o
+</pre>
+
+The build on OSX leaves some stray files and it complains about it.
+"""]]
diff --git a/doc/design/assistant/blog/day_286__Windows_test_suite.mdwn b/doc/design/assistant/blog/day_286__Windows_test_suite.mdwn
new file mode 100644
index 0000000000..f62aa8eb26
--- /dev/null
+++ b/doc/design/assistant/blog/day_286__Windows_test_suite.mdwn
@@ -0,0 +1,19 @@
+One of my Windows fixes yesterday got the test suite close to sort of
+working on Windows, and I spent all day today pounding on it. Fixed
+numerous bugs, and worked around some weird Windows behaviors -- like
+recursively deleting a directory sometimes fails with a permission denied
+error about a file in it, and leaves behind an empty directory. (What!?)
+The most important bug I fixed caused CR to leak into files in the
+git-annex branch from Windows, during a union merge, which was not a good
+thing at all.
+
+At the end of the day, I only have 6 remaining failing test cases on
+Windows. Half of them are some problem where running `git annex sync`
+from the test suite stomps on PATH somehow and prevents xargs from working.
+The rest are probably real bugs in the directory (again something to do
+with recursive directory deletion, hmmm..), hook, and rsync
+special remotes on Windows. I'm punting on those 6 for now, they'll be
+skipped on Windows.
+
+Should be worth today's pain to know in the future when I break
+something that I've oh-so-painfully gotten working on Windows.
diff --git a/doc/design/assistant/blog/day_287__niceness.mdwn b/doc/design/assistant/blog/day_287__niceness.mdwn
new file mode 100644
index 0000000000..5fc193353d
--- /dev/null
+++ b/doc/design/assistant/blog/day_287__niceness.mdwn
@@ -0,0 +1,13 @@
+Pushed out a release today. While I've somewhat ramped down activity this
+month with the Kickstarter period over and summer trips and events ongoing,
+looking over the changelog I still see a ton of improvements in the 20 days
+since the last release.
+
+Been doing some work to make the assistant daemon be more `nice`. I don't
+want to nice the whole program, because that could make the web interface
+unresponsive. What I am able to do, thanks to Linux violating POSIX, is to
+`nice` certain expensive operations, including the startup scan and the daily
+sanity check. Also, I put in a call to `ionice` (when it's available) 
+when `git annex assistant --autostart` is run, so the daemon's
+disk IO will be prioritized below other IO. Hope this keeps it out of your
+way while it does its job.
diff --git a/doc/design/assistant/blog/day_288__success_stories.mdwn b/doc/design/assistant/blog/day_288__success_stories.mdwn
new file mode 100644
index 0000000000..c19f64e1ff
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories.mdwn
@@ -0,0 +1,32 @@
+Got caught up on a big queue of messages today. Mostly I hear from people
+when git-annex is not working for them, or they have a question about using
+it. From time to time someone does mention that it's working for them.
+
+> We have 4 or so machines all synching with each other via the local
+> network thing. I'm always amazed when it doesn't just explode :)
+
+Due to the nature of git-annex, a lot of people can be using it without
+anyone knowing about it. Which is great. But these little success stories
+can make all the difference. It motivates me to keep pounding out the
+development hours, it encourages other people to try it, and it'd be a good
+thing to be able to point at if I tried to raise more funding now that I'm
+out of Kickstarter money.
+
+I'm posting my own success story to my main blog:
+[git annex and my mom](http://joeyh.name/blog/entry/git_annex_and_my_mom)
+
+If you have a success story to share, why not blog about it, microblog it,
+or just post a comment here, or even send me a private message. Just a
+quick note is fine. Thanks!
+
+----
+
+Going through the bug reports and questions today, I ended up fixing
+three separate bugs that could break setting up a repo on a remote ssh
+server from the webapp.
+
+Also developed a minimal test case for some gnucash behavior that prevents
+the watcher from seeing files it writes out. I understand the problem,
+but don't have a fix for that yet. Will have to think about it. (A year ago
+today, my blog featured the
+[[first_release_of_the_watcher|day_16__more_robust_syncing]].)
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_10_9ddf57b8ae0241268bb33bec1b169e4c._comment b/doc/design/assistant/blog/day_288__success_stories/comment_10_9ddf57b8ae0241268bb33bec1b169e4c._comment
new file mode 100644
index 0000000000..f53f4b654d
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_10_9ddf57b8ae0241268bb33bec1b169e4c._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmnG4EuvZWse5hvgrl0XAK-U61e-0iGaao"
+ nickname="David"
+ subject="Nothing fancy but..."
+ date="2013-06-27T16:52:12Z"
+ content="""
+Hi Joey,
+
+First, thanks very much for your effort put into git-annex.  I store my photos in git-annex and I like it because:
+
+* I want to store multiple copies of the pictures and I can see where they are,
+* I can have a global view of the collection on my laptop without carrying all the files.
+* the indirect mode makes it difficult to me to do stupid things.
+
+So there's nothing fancy, but it works for me very well.  From time to time I try the assistant's new features and I'm planning to replace Dropbox eventually.
+
+Secondly, thanks very much for the dev blog!  I was looking forward every morning to see what's coming next, what problems you are facing and how you're planning to solve them.  It is simply amazing what you've achieved in the last year and your posts gave me a lot of motivation too (in finishing my thesis  :-))!
+
+Thanks!
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_11_50b8a597bd8677608f2ef176443f23f3._comment b/doc/design/assistant/blog/day_288__success_stories/comment_11_50b8a597bd8677608f2ef176443f23f3._comment
new file mode 100644
index 0000000000..219e1e651d
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_11_50b8a597bd8677608f2ef176443f23f3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 11"
+ date="2013-06-27T18:11:03Z"
+ content="""
+Excerpt from a [longer comment](http://git-annex.branchable.com/bugs/Problems_with_syncing_gnucash/#comment-7d70d822a0fdf672ba09535f943af7c9) by Florian:
+
+I know that my expectations in this project are a little bit high and I see how much work it was to get where we are now. Once again thank you for the excellent work done so far. I don't fear to synchronize important data with git-annex. I even use git-annex to backup and synchronize the member database for our club (wannabe hackerspace).
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_12_f2df427cf3608377e9a52d8bdeadb26f._comment b/doc/design/assistant/blog/day_288__success_stories/comment_12_f2df427cf3608377e9a52d8bdeadb26f._comment
new file mode 100644
index 0000000000..10699c9593
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_12_f2df427cf3608377e9a52d8bdeadb26f._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 12"
+ date="2013-06-27T18:11:45Z"
+ content="""
+From a mail I received: --[[Joey]]
+
+Git-annex makes it possible for me to have lots of data.  Before I
+started using it I had a music library and a few massive tar files,
+none of it properly backed up, and occasionally there would be random
+corruption (I still have broken mp3s which jump and stutter in places)
+because I would carelessly cp them from HDD to HDD.  So I'd avoid
+actually letting data accumulate; this was inconvenient in itself.
+Now git-annex does everything for me.
+
+Following your development blog, as a novice programmer, has been
+really enjoyable and interesting.  My only experience of professional
+IT has put me of but it's good to see you working through things
+methodically and properly.
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_13_8762efed97f21eeba8f0a7be45bd924a._comment b/doc/design/assistant/blog/day_288__success_stories/comment_13_8762efed97f21eeba8f0a7be45bd924a._comment
new file mode 100644
index 0000000000..3b18645e4c
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_13_8762efed97f21eeba8f0a7be45bd924a._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="http://julien.lefrique.name/"
+ nickname="jlefrique"
+ subject="Many thanks!"
+ date="2013-06-27T19:59:47Z"
+ content="""
+Hi Joey,
+
+More than ten years ago, I was looking for a software to index the content of all my
+CD-ROMs in order to create a kind of \"table of content\". Today there is
+git-annex!
+
+I discovered git-annex few months ago and it really helps me to keep my file
+well organized. I missed the first crowd funding campaign but would be happy
+to contribute to the next one :D
+
+I mainly use four different annexes for:
+
+* my private photos and videos,
+* my music collection,
+* my other multimedia files (movies...),
+* my other files that are too large to be commited into git directly (pdf, binaries...).
+
+I use git-annex manually via the command line. I started to play with the
+assistant on my Android tablet and I plan to install it on my wife's
+Macbook to synchronize her data with the NAS.
+
+A standalone build for arm to run git-annex on my NAS (QNAP 219 PII) would be perfect :-P
+
+Thank you very much for all your great softwares (yes I also use etckeeper,
+some moreutils tools and more recently ikiwiki).
+
+-Julien
+
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_14_55e1bb15c3a93d582d110f8173ceefc2._comment b/doc/design/assistant/blog/day_288__success_stories/comment_14_55e1bb15c3a93d582d110f8173ceefc2._comment
new file mode 100644
index 0000000000..f63dc7b9e0
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_14_55e1bb15c3a93d582d110f8173ceefc2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="EvanDeaubl"
+ ip="67.128.198.190"
+ subject="comment 14"
+ date="2013-06-28T18:35:55Z"
+ content="""
+git-annex has been working brilliantly for me. I have been slowly moving content out of the various places I've had it stored (file servers, folders hidden away on all my machines, Dropbox, Google Drive, etc.) into a single git-annex repo. The idea has been to mimic Dropbox's single folder, but with much more flexibility: I sync my working machines, my home fileserver, my VPS (for file access on the go), Android devices, and even a couple of dumb MP3 players from git-annex. Best of all, I have one place to go for all of my files, and if they're not on the device at the moment I need them, they're a download away. I didn't find git-annex until after the first crowdfunding campaign had completed, but if there's another, I would be a happy supporter.
+
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_15_5749aef8b585b293385b20b75c40f9d8._comment b/doc/design/assistant/blog/day_288__success_stories/comment_15_5749aef8b585b293385b20b75c40f9d8._comment
new file mode 100644
index 0000000000..cefc5045c6
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_15_5749aef8b585b293385b20b75c40f9d8._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="http://jasonwoof.com/"
+ nickname="JasonWoof"
+ subject="It's been great!"
+ date="2013-06-29T03:48:08Z"
+ content="""
+Looks like I started using git-annex in November 2010.
+
+I'd already been tracking lots of small files in my home directory (settings, scripts, notes, todo list, timesheets, invoices, etc) with git.
+
+So awesome to get backups, syncing and manual merge conflict resolution.
+
+git-annex extended that to handle my larger files. git-annex's ability to be selective about what is stored where, allowed my to still be able to git clone my home directory onto small devices (I've got a debian chroot with only 6GB or so, and I installed debian on my new chromebook, that's only got 16GB of disk space (for the whole system.))
+
+I love having the full catalog visible on my filesystem with symlinks, and I can just request a file, and git-annex will figure out where to get it from, even if I'm away from home on my laptop.
+
+I just got a 2nd external hard drive, and I'm delighted with how easy it was to get a backup of everything on there.
+
+I was able to quickly and safely clear up space on my desktop computer! I'm confident that my data is safe because I've got git-annex configured to make sure there's at least two copies of my videos, and 3 copies of everything else.
+
+I've finally gone from either keeping hard drives from my past computers or keeping a full copy of the data, to having a proper archiving and backup system for all files I care about.
+
+I've got over 12,000 files stored on my main annex, and it's perfectly responsive.
+
+Joey does a great job, and has been very responsive on the rare occasions where I needed help.
+
+Three cheers!
+
+-- 
+Jason
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_16_911c6d2764906cad7d6324835441ed34._comment b/doc/design/assistant/blog/day_288__success_stories/comment_16_911c6d2764906cad7d6324835441ed34._comment
new file mode 100644
index 0000000000..64d17f8721
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_16_911c6d2764906cad7d6324835441ed34._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://dzsino.myopenid.com/"
+ nickname="dzsino"
+ subject="thanks!"
+ date="2013-06-30T13:10:35Z"
+ content="""
+I'm using git-annex to consolidate all the stuff that accumulated for years on various drives I have. Music I downloaded and bought (don't wanna loose those), photos from 2003 and on, archives of school and work stuff etc. Using it for 6-7 months now, I came to trust git-annex, I very much like the command line robustness it has and I really like that all my files are accessible in a single tree. It would be cool to have some metadata storage (for file dates, tags and such) and maybe spotlight-like search (elastic-search comes to mind).. 
+Still, without these, it has a great problem-solution fit for me!
+
+Thanks Joey for all the great work, I really hope you can continue improving it, I would gladly join to a second kickstarter funding!
+
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_17_eb6aa8af5aa70877255a11d132d51aba._comment b/doc/design/assistant/blog/day_288__success_stories/comment_17_eb6aa8af5aa70877255a11d132d51aba._comment
new file mode 100644
index 0000000000..0586afab57
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_17_eb6aa8af5aa70877255a11d132d51aba._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="GLITTAH"
+ ip="50.23.191.90"
+ subject="Several annexes managing >3TB. No problems!"
+ date="2013-07-02T00:12:27Z"
+ content="""
+I've got an annex with all my DVD ISOs that's nearly 3TB alone, uses the SHA512 hash and gets split over three computers, 6 external SATA drives and 3 USB drives.  No errors so far, and the issues with git-annex I've had have all been addressed very quickly (thanks Joey!) and in a non-destructive manner so I don't have to re-init a repo.  I also use it to manage my music library, which allows to me to sleep at night without worrying about a corrupted file spreading through all my backups over time since git-annex has a fsck and hashing utility.  I can't imagine using anything else for managing collections of files: it offloads the task of keeping track of, getting, verifying, and general management of files so I don't even need to worry about the boring stuff, I just get around to watching/listening to my media collection.
+
+Thanks for all the work, it's changed my workflow and file management (I get more sleep too)!
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_18_9a57de4cea407a73b2d023d85afdccc6._comment b/doc/design/assistant/blog/day_288__success_stories/comment_18_9a57de4cea407a73b2d023d85afdccc6._comment
new file mode 100644
index 0000000000..1e42772772
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_18_9a57de4cea407a73b2d023d85afdccc6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 18"
+ date="2013-07-03T15:51:48Z"
+ content="""
+Another good tweet: --[[Joey]]
+
+My google Reader replacement: newsbeuter with the data directory stored in an autosynced git-annex repo.
+
+<https://twitter.com/JustinAzoff/status/352256199070199809>
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_19_1767c86067bee35941004282b96b8e95._comment b/doc/design/assistant/blog/day_288__success_stories/comment_19_1767c86067bee35941004282b96b8e95._comment
new file mode 100644
index 0000000000..93bfb03e6f
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_19_1767c86067bee35941004282b96b8e95._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="GLITTAH"
+ ip="176.31.181.25"
+ subject="Forgot to add..."
+ date="2013-07-03T19:28:42Z"
+ content="""
+Forgot to add: I'm horrible at keeping things organized.  Git-annex is a huge help with that -- it keeps track of files and the number of their copies.  When I first started using it, I had old songs duplicated across 4 drives, while 2 of those drives had old tags and were obsolete, and one drive had the correct tags, but not the correct filenames.  Every few years I'd have to go through several TB of media files, hand checking each of them to see what was old, what was unwanted, etc.  Once my media libraries got larger than consumer-grade HDD's, I had to find a better solution.  Git-annex removes that burden, and keeps things organized for me.  Once I get an album or movie I tag/rename it the way I want, throw it in the annex and let my computer do the boring and tedious parts like automatically verifying and making sure there's enough copies.  If I change a file, that change propagates through all my repo clones.  It wasn't until after I started using git-annex that I realized how stressed out I was getting over simply maintaining a media library.
+
+If you do another fundraiser you've got my support!
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_1_22b28ca3d4d3283ad8c21ae052fb9752._comment b/doc/design/assistant/blog/day_288__success_stories/comment_1_22b28ca3d4d3283ad8c21ae052fb9752._comment
new file mode 100644
index 0000000000..494cb798a5
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_1_22b28ca3d4d3283ad8c21ae052fb9752._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 1"
+ date="2013-06-25T22:26:27Z"
+ content="""
+I've been real quiet cause everything's been working great. :)
+
+One thing I have not messed with yet is the whole XMPP thing.  I mostly don't share between two machines that are online at the same time, I just use git annex for backups and to have content \"optionally\" available.  I should give XMPP a try sometime.
+
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_20_1d47f3e1b9f0081649cedae4288bac83._comment b/doc/design/assistant/blog/day_288__success_stories/comment_20_1d47f3e1b9f0081649cedae4288bac83._comment
new file mode 100644
index 0000000000..501cf561f8
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_20_1d47f3e1b9f0081649cedae4288bac83._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmhfodZquCI_EEl-f3h7HkROTszlsQL6yA"
+ nickname="Joe"
+ subject="comment 20"
+ date="2013-07-04T12:41:35Z"
+ content="""
+I'm using git-annex to make videos, pictures and music available on all my devices (windows, android, linux). It has saved me on trips with my 2yr daughter when she's had meltdowns; I have her favorite movie ready. I quickly exceeded the free dropbox quota and git-annex has replaced the need and gives me greater confidence and control over my data. Thank you!
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_21_31d3f58cad83cb1ecc4821a15ca258d8._comment b/doc/design/assistant/blog/day_288__success_stories/comment_21_31d3f58cad83cb1ecc4821a15ca258d8._comment
new file mode 100644
index 0000000000..99c6c14af4
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_21_31d3f58cad83cb1ecc4821a15ca258d8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm0sGxsiJ7yj5iQsF-A5tEl6XKOGQieqEo"
+ nickname="Matthew"
+ subject="Writing papers"
+ date="2013-07-04T15:32:24Z"
+ content="""
+I'm a graduate student, so I write a lot.  I started using git to manage my latex sources a while ago, but I didn't like gumming up my repository with a bunch of figures (large binaries). I was constantly forgetting to scp the latest versions of my figures from here to there (as I do my work on a number of different computers.)  Git annex gives me a good way to version the figures and manage them with the same tool I'm using for the text.  
+
+My use case seems pretty far from typical, judging from the other comments here, so I thought I should add my two cents!  I'm constantly trying to sell this approach to my fellow students.
+
+Also, I'm going to slip in a plug for another great Haskell project here -- Pandoc. I work with people who suggest changes to my drafts, but only using Word's \"Track Changes\".  So now I'm generating Word docs from Pandoc markdown for my collaborators to edit.  When it comes time to publish, I can convert my markdown to latex and clean up the formatting.  
+
+Why are all the really cool projects written in Haskell? :)  
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_22_b512bd2bf29dfaab6b36bf204518fdb6._comment b/doc/design/assistant/blog/day_288__success_stories/comment_22_b512bd2bf29dfaab6b36bf204518fdb6._comment
new file mode 100644
index 0000000000..e7a62fd019
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_22_b512bd2bf29dfaab6b36bf204518fdb6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://sunny256.sunbase.org/"
+ nickname="sunny256"
+ subject="git-annex is teh awesome"
+ date="2013-07-15T12:37:54Z"
+ content="""
+Just like Git, git-annex is teh awesome. I've used it for almost a year now, and I've never had more control of all my stuff. I store all my valuable (and also not so valuable) files in it, more than a terabyte, and it's rapidly growing. Movies, pictures, recordings, software, podcasts, DVDs and CDs, you name it. It's rock solid with a really good design. Joey says it isn't a backup solution, but I strongly disagree. My data have never been safer. git-annex ensures that I have several copies in different locations, I always know where all the copies are, and the disk space is used way more efficiently now that I don't have unnecessary duplicates everywhere anymore.
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_2_343333356de20e170edb8020faa7400d._comment b/doc/design/assistant/blog/day_288__success_stories/comment_2_343333356de20e170edb8020faa7400d._comment
new file mode 100644
index 0000000000..768469e3e0
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_2_343333356de20e170edb8020faa7400d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~subito"
+ nickname="subito"
+ subject="Big success!"
+ date="2013-06-26T07:00:15Z"
+ content="""
+Annex is working great for me since 8/2012 or something... Using it a lot and the Assistant is awesome!
+
+If you would raise some more funding, I'd be more than happy to support you once more - really great software!
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_3_4e4034bec789543b562ac263df3e21dd._comment b/doc/design/assistant/blog/day_288__success_stories/comment_3_4e4034bec789543b562ac263df3e21dd._comment
new file mode 100644
index 0000000000..c8ae3d7850
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_3_4e4034bec789543b562ac263df3e21dd._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl3A5oeZFLreGhDTFVMOJYIy1auKiTL_ZY"
+ nickname="Maggie"
+ subject=":)"
+ date="2013-06-26T15:04:45Z"
+ content="""
+Poets aren't humble people.
+We revel in our own narcissism.
+So being mentioned in my brother's blog
+was great for me.
+
+I am proud of the success of Git Annex.
+
+(My poems tend to be _much_ better than this.)
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_4_0c52794c77a9b7afc5112f5edf9cb793._comment b/doc/design/assistant/blog/day_288__success_stories/comment_4_0c52794c77a9b7afc5112f5edf9cb793._comment
new file mode 100644
index 0000000000..f285863f51
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_4_0c52794c77a9b7afc5112f5edf9cb793._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://nicolas-schodet.myopenid.com/"
+ ip="2a01:e35:8ae6:f130:1e4b:d6ff:fe78:1ddb"
+ subject="Thank you for this great tool!"
+ date="2013-06-26T18:10:05Z"
+ content="""
+I use git-annex for my picture collection. I can add pictures from my computers, or my FTP server when someone wants to send me their pictures. Then I push them to my online gallery. Git annex is great to keep all my repository synchronized while not requesting that all my pictures are present on my laptop.  Thank you!
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_5_7ca419aa3a187857b19268572d5df297._comment b/doc/design/assistant/blog/day_288__success_stories/comment_5_7ca419aa3a187857b19268572d5df297._comment
new file mode 100644
index 0000000000..1dd6fa4a98
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_5_7ca419aa3a187857b19268572d5df297._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 5"
+ date="2013-06-26T19:39:15Z"
+ content="""
+Excerpt from an email I received: --[[Joey]]
+
+Another story, but without the assistant this time: I've \"designed\" a
+small f2f file sharing network with it, I'm using it with a friend to
+share accross several computer. This is basically a workflow
+with git annex and gitoline, the flexibility of git and the capacities
+of git annex just gave us this out of the box. Some specs are here if
+you are curious
+http://worlddomination.be/ideas/2012/idea-n-21-build-a-f2f-sharing-network-using
+-git-annex.html
+
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_6_3edd56b3b04f19faba8d75cca285a662._comment b/doc/design/assistant/blog/day_288__success_stories/comment_6_3edd56b3b04f19faba8d75cca285a662._comment
new file mode 100644
index 0000000000..f08fce4b3a
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_6_3edd56b3b04f19faba8d75cca285a662._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andy"
+ ip="99.127.140.99"
+ subject="Another success story"
+ date="2013-06-27T02:03:00Z"
+ content="""
+I'm using Ubuntu, and I do a clean install about every 6 months when the new versions come out. I also have 2-3 systems I need to keep in sync. I use git annex to store files I want to keep between OS reinstalls, and to sync the various systems I need data on. I also use it to backup data to the cloud and to bup. I have 6+ repos, 235 GB of data, and 31,029 known annex keys (thanks `git annex map` and `git annex status`!); nevertheless git annex is generally pretty cooperative. I'm not using the assistant yet, but I'd like to eventually. I almost don't have to think about the stuff annex handles. It's really fun to install a fresh OS, clone the git annex repo, and have my entire annex directory tree available immediately.
+
+Thanks Joey! You've done a great job!
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_7_146331ae2de25a6dc3595dffab9514de._comment b/doc/design/assistant/blog/day_288__success_stories/comment_7_146331ae2de25a6dc3595dffab9514de._comment
new file mode 100644
index 0000000000..61d581380d
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_7_146331ae2de25a6dc3595dffab9514de._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 7"
+ date="2013-06-27T06:31:29Z"
+ content="""
+Amazing tweet I found! --[[Joey]]
+
+Git-annex now auto-syncing photos from my android phone to a Tor hidden SSH service I control (via @guardianproject's Orbot) #prismbreak
+
+<https://twitter.com/graphiclunarkid/status/347658443479449601>
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_8_72be9307e75eb120451f3d6ab7c8165e._comment b/doc/design/assistant/blog/day_288__success_stories/comment_8_72be9307e75eb120451f3d6ab7c8165e._comment
new file mode 100644
index 0000000000..ab482d179f
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_8_72be9307e75eb120451f3d6ab7c8165e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnAvbXOnK57sqgvZvxkbG74NUKBDwKDcuk"
+ nickname="Tim"
+ subject="Backups"
+ date="2013-06-27T13:14:43Z"
+ content="""
+We use rsync and tar to backup to a server on the local network, and since we discoverd git-annex, we use this mechanism to automatically put all this data in both a local bup repo and a remote one. This gives us a daily full backup, with history available, both locally and off-site. Thanks to bup our 4T of data gets deduplicated to about 270G, only a couple of megs get transferred every night, and thanks to git-annex everything just works, like it should!
+"""]]
diff --git a/doc/design/assistant/blog/day_288__success_stories/comment_9_c27eb0a4181e85a3eed41130402350bf._comment b/doc/design/assistant/blog/day_288__success_stories/comment_9_c27eb0a4181e85a3eed41130402350bf._comment
new file mode 100644
index 0000000000..cf77845b53
--- /dev/null
+++ b/doc/design/assistant/blog/day_288__success_stories/comment_9_c27eb0a4181e85a3eed41130402350bf._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlOc-EOD5ZyggsAp6lOnU7x5MxizwLtUXA"
+ nickname="Hendrik"
+ subject="more success"
+ date="2013-06-27T14:09:47Z"
+ content="""
+Hi,
+
+I have moved all my photographs to an annex running on a Ubuntu file server while doing photo editing, presenting etc. on my MacBook. The annex is great in selectively moving files between these machines for editing and presentation purposes. I started using it around christmas season last year and added a glacier \"backup\" recently. My statistics: 6 repositories in total, more than 300GB (dedup'd from 380GB), 60.000 local keys.
+
+What is missing from my point of view (and I would happily join crowd funding): stable windows and android versions, managing selective transfers from the assistant (select folders to be transferred from/to a specific repository), options for running the annex as a server daemon with web GUI (authentication to GUI + fixed URLs, status reports on GUI, etc.). All these would dramatically increase the WAF.
+"""]]
diff --git a/doc/design/assistant/blog/day_289__back_in_the_swing.mdwn b/doc/design/assistant/blog/day_289__back_in_the_swing.mdwn
new file mode 100644
index 0000000000..75923f8978
--- /dev/null
+++ b/doc/design/assistant/blog/day_289__back_in_the_swing.mdwn
@@ -0,0 +1,16 @@
+Came up with a fix for the gnucash hard linked file problem that makes the
+assistant notice the files gnucash writes. This is not full hard link support;
+hard linked files still don't cleanly sync around. But new hard links to
+files are noticed and added, which is enough to support gnucash.
+
+Spent around 4 hours on reproducing and trying to debug
+[[bugs/Hanging_on_install_on_Mountain_lion]]. It seems that recent upgrades
+of the OSX build machine led to this problem. And indeed, building with an
+older version of Yesod and Warp seems to have worked around the problem. So
+I updated the OSX build for the last release. I will have to re-install the
+new Yesod on my laptop and investigate further -- is this an OSX specific
+problem, or does it affect Linux? Urgh, this is the second hang I've
+encountered involving Warp..
+
+Got several nice [[success stories|day_288__success_stories]], but I don't
+think I've seen *yours* yet. ;) Please post!
diff --git a/doc/design/assistant/blog/day_290__https_release.mdwn b/doc/design/assistant/blog/day_290__https_release.mdwn
new file mode 100644
index 0000000000..ea017d2173
--- /dev/null
+++ b/doc/design/assistant/blog/day_290__https_release.mdwn
@@ -0,0 +1,17 @@
+Spent too many hours last night tracking down a bug that caused the webapp
+to hang when it got built with the new yesod 1.2 release. Much of that time
+was spent figuring out that yesod 1.2 was causing the problem. It turned out to
+be a stupid typo in my yesod compatability layer. `liftH = liftH` in
+Haskell is an infinite loop, not the stack overflow you get in most
+languages. ;)
+
+Even though it's only been a week since the last release,
+that was worth pushing a release out for, which I've just done.
+This release is essentially all bug fixes (aside from the automatic 
+ionice and nicing of the daemon).
+
+This website is now available over https. Perhaps more importantly, all the
+links to download git-annex builds are https by default.
+
+The [[success_stories|day_288__success_stories]] list is getting really
+nice. Only way it could possibly be nicer is if you added your story! Hint. ;)
diff --git a/doc/design/assistant/blog/day_291__--all.mdwn b/doc/design/assistant/blog/day_291__--all.mdwn
new file mode 100644
index 0000000000..0a5584182d
--- /dev/null
+++ b/doc/design/assistant/blog/day_291__--all.mdwn
@@ -0,0 +1,32 @@
+I've felt for a while that git-annex needed better support for managing
+the contents of past versions of files that are stored in the annex. I know
+some people get confused about whether git-annex even supports old versions
+of files (it does, but you should use indirect mode; direct mode doesn't
+guarantee old versions of files will be preserved).
+
+So today I've worked on adding command-line power for managing past
+versions: a new `--all` option.
+
+So, if you want to copy every version of every file in your repository to
+an archive, you can run `git annex copy --all --to archive`.
+Or if you've got a repository on a drive that's dying, you can run
+`git annex copy --all --to newdrive`, and then on the new drive, run `git
+annex fsck --all` to check all the data.
+
+In a bare repository, `--all` is default, so you can run `git annex get`
+inside a bare repository and it will try to get every version of every file
+that it can from the remotes.
+
+The tricky thing about `--all` is that since it's operating on objects and
+not files, it can't check `.gitattributes` settings, which are tied to the
+file name. I worried for a long time that adding `--all` would make
+annex.numcopies settings in those files not be honored, and that this would
+be a Bad Thing. The solution turns out to be simple: I just didn't
+implement `git annex drop --all`! Dropping is the only action that needs to
+check numcopies (move can also reduce the number of copies, but explicitly
+bypasses numcopies settings).
+
+I also added an `--unused` option. So if you have a repository that has
+been accumulating history, and you'd like to move all file contents not
+currently in use to a central server, you can run `git annex unused; git
+annex move --unused --to origin`
diff --git a/doc/design/assistant/blog/day_291__--all/comment_1_eaa9fef19a035bef9c439e87d47c834b._comment b/doc/design/assistant/blog/day_291__--all/comment_1_eaa9fef19a035bef9c439e87d47c834b._comment
new file mode 100644
index 0000000000..60cb4abb0d
--- /dev/null
+++ b/doc/design/assistant/blog/day_291__--all/comment_1_eaa9fef19a035bef9c439e87d47c834b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="comment 1"
+ date="2013-07-03T22:16:32Z"
+ content="""
+Excellent stuff!  Another thing I'd like to see is that I find myself doing the following all the time:
+
+    git annex copy --to titan --not --in titan
+
+Meaning: copy everything to titan that it doesn't already have.  This operation is very quick.  But I write just:
+
+    git annex copy --to titan
+
+This operation is extremely slow, since it appears to scan through every file in the repository.  Is there a way to have the latter imply the former?  I wouldn't ever want to copy a file that it already has anyway...
+
+"""]]
diff --git a/doc/design/assistant/blog/day_291__--all/comment_2_90bbc26bf92048de7cbaf5fb719c9593._comment b/doc/design/assistant/blog/day_291__--all/comment_2_90bbc26bf92048de7cbaf5fb719c9593._comment
new file mode 100644
index 0000000000..6838ac0700
--- /dev/null
+++ b/doc/design/assistant/blog/day_291__--all/comment_2_90bbc26bf92048de7cbaf5fb719c9593._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="sfs"
+ ip="65.204.1.102"
+ subject="See history of a file"
+ date="2013-07-07T00:49:35Z"
+ content="""
+It's great that you are addressing the management of older versions. I am new to git-annex but couldn't find much information about this topic. Is it also possible to make git-annex show you the history of files (with date, size, ...) and where (which repositories) they are stored? Or to retrieve a specific version from a remote repository?
+
+Thanks for this amazing peace of software!
+Stephan
+"""]]
diff --git a/doc/design/assistant/blog/day_291__--all/comment_3_75006e9909425dcbf86415a9f7c90372._comment b/doc/design/assistant/blog/day_291__--all/comment_3_75006e9909425dcbf86415a9f7c90372._comment
new file mode 100644
index 0000000000..748db49f38
--- /dev/null
+++ b/doc/design/assistant/blog/day_291__--all/comment_3_75006e9909425dcbf86415a9f7c90372._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.254.222"
+ subject="comment 3"
+ date="2013-07-07T17:20:05Z"
+ content="""
+@john I have considered making copy trust the location log for the remote (which is what your --not --in titan does), but this does change its behavior in a subtly way, and IIRC there were scenarios where this is not desirable.
+
+@sfs the best way to look at older versions of files is to use `git checkout` to check out an older version of the repository. You can then use `git annex get`, `git annex whereis`, etc like you usually would, on the old version of files.
+"""]]
diff --git a/doc/design/assistant/blog/day_291__--all/comment_4_5440449bbc5a353f7430f72e19c35e92._comment b/doc/design/assistant/blog/day_291__--all/comment_4_5440449bbc5a353f7430f72e19c35e92._comment
new file mode 100644
index 0000000000..a4739c5e7d
--- /dev/null
+++ b/doc/design/assistant/blog/day_291__--all/comment_4_5440449bbc5a353f7430f72e19c35e92._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 4"
+ date="2013-07-14T16:03:39Z"
+ content="""
+@john, @joeyh: I like the fact that normal copy takes some time, but that it _verifies_. Default to save, optimize to quick, imo.
+"""]]
diff --git a/doc/design/assistant/blog/day_292__bugfixes.mdwn b/doc/design/assistant/blog/day_292__bugfixes.mdwn
new file mode 100644
index 0000000000..a514afd0e0
--- /dev/null
+++ b/doc/design/assistant/blog/day_292__bugfixes.mdwn
@@ -0,0 +1,24 @@
+Actually spread out over several days..
+
+I think I have finally comprehensively dealt with all the wacky system
+misconfigurations that can make `git commit` complain and refuse to commit.
+The last of these is [a system with a FQDN that doesn't have a dot in it](http://git-annex.branchable.com/bugs/view_logs_fails:_Internal_Server_Error__internal_liftAnnex/). 
+I personally think git should just use the hostname as-is in the email
+address for commits here -- it's better to be robust. Indeed, I think it
+would make more sense if `git commit` never failed, unless it ran out of
+disk or the repo is corrupt. But anyway, `git-annex
+init` will now detect when the commit fails because of this and put a
+workaround in place.
+
+Fixed a bug in `git annex addurl --pathdepth` when the url's path was
+shorter than the amount requested to remove from it.
+
+Tracked down a bug that prevents git-annex from working on a system with an
+old linux kernel. Probably the root cause is that the kernel was built
+without EVENTFD support. Found a workaround to get a usable git-annex on
+such a system is to build it without the webapp, since that disables the
+threaded runtime which triggered the problem.
+
+Dealt with a lot of Windows bugs. Very happy that it's working well enough
+that some users are reporting bugs on it in Windows, and with enough detail
+that I have not needed to boot Windows to fix them so far. ;)
diff --git a/doc/design/assistant/blog/day_292__bugfixes/comment_1_bbac3878d80f7540d229183c56664784._comment b/doc/design/assistant/blog/day_292__bugfixes/comment_1_bbac3878d80f7540d229183c56664784._comment
new file mode 100644
index 0000000000..5aafab12d5
--- /dev/null
+++ b/doc/design/assistant/blog/day_292__bugfixes/comment_1_bbac3878d80f7540d229183c56664784._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://cweiske.de/"
+ nickname="cweiske"
+ subject="comment 1"
+ date="2013-07-09T06:52:11Z"
+ content="""
+Thanks for the quick bugfix!
+"""]]
diff --git a/doc/design/assistant/blog/day_292__bugfixes/comment_2_8c9e5291ceb257f3a938af0ad967c5d7._comment b/doc/design/assistant/blog/day_292__bugfixes/comment_2_8c9e5291ceb257f3a938af0ad967c5d7._comment
new file mode 100644
index 0000000000..adb161fd09
--- /dev/null
+++ b/doc/design/assistant/blog/day_292__bugfixes/comment_2_8c9e5291ceb257f3a938af0ad967c5d7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://nullroute.eu.org/~grawity/"
+ nickname="Mantas"
+ subject="comment 2"
+ date="2013-07-09T13:47:20Z"
+ content="""
+git **used to** use the hostname as-is, but that didn't work out well – many people just kept on committing as `joeyh@kremvax.(none)`, which doesn't make for a good email address or a globally-unique identifier (sometimes by being lazy; sometimes by forgetting to carry their Git config over to a new machine).
+
+The stricter check was implemented in [8c5b1ae1](https://github.com/gitster/git/commit/8c5b1ae1b26a7512eb29e75391b8b24c0d0439e7) for git v1.8.3. Setting `$EMAIL` or running `git -c user.email=foo@bar` should override it.
+"""]]
diff --git a/doc/design/assistant/blog/day_292__bugfixes/comment_3_02f875e8edd30f47939249f16d92712b._comment b/doc/design/assistant/blog/day_292__bugfixes/comment_3_02f875e8edd30f47939249f16d92712b._comment
new file mode 100644
index 0000000000..3d02b447bd
--- /dev/null
+++ b/doc/design/assistant/blog/day_292__bugfixes/comment_3_02f875e8edd30f47939249f16d92712b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://nullroute.eu.org/~grawity/"
+ nickname="Mantas"
+ subject="comment 3"
+ date="2013-07-09T13:48:49Z"
+ content="""
+(I was wrong about the version; it appears to be v1.7.11.)
+"""]]
diff --git a/doc/design/assistant/blog/day_293__gpg_builds.mdwn b/doc/design/assistant/blog/day_293__gpg_builds.mdwn
new file mode 100644
index 0000000000..eb3ccbd25c
--- /dev/null
+++ b/doc/design/assistant/blog/day_293__gpg_builds.mdwn
@@ -0,0 +1,32 @@
+Two gpg fixes today. The OSX Mtn Lion builds were pulling in a build of gpg
+that wanted a gpg-agent to be installed in /usr/local or it wouldn't work.
+I had to build my own gpg on OSX to work around this. I am pondering making
+the OSX dmg builds pull down the gpg source and build their own binary,
+so issues on the build system can't affect it. But would really rather not,
+since maintaining your own version of every dependency on every
+OS is hard (pity about there still being so many OS's without sane package
+management).
+
+On Android, which I have not needed to touch for a month, gpg was built
+with --enable-minimal, which turned out to not be necessary and was
+limiting the encryption algorythms included, and led to
+interoperability problems for some. Fixed that gpg build too.
+
+Also fixed an ugly bug in the webapp when setting up a rsync repository.
+It would configure `~/.ssh/authorized_keys` on the server to force
+git-annex-shell to be run. Which doesn't work for rsync. I didn't notice
+this before because it doesn't affect ssh servers that already have a ssh
+setup that allows accessing them w/o a password.
+
+Spent a while working on a bug that can occur in a non-utf8 locale
+when using special characters in the directory name of a ssh remote.
+I was able to reproduce it, but have not worked out how to fix it; encoding
+issues like this are always tricky.
+
+Added something to the walkthrough to help convince people that yes, you
+can use tags and branches with git-annex just like with regular git. One of
+those things that is so obvious to the developer writing the docs 
+that it's hard to realize it will be a point of concern.
+
+Seems like there is a release worth of changes already, so I plan to push
+it out tomorrow.
diff --git a/doc/design/assistant/blog/day_293__gpg_builds/comment_1_4f152de8ea5aca4ec381d439e2a821f7._comment b/doc/design/assistant/blog/day_293__gpg_builds/comment_1_4f152de8ea5aca4ec381d439e2a821f7._comment
new file mode 100644
index 0000000000..82563a41d3
--- /dev/null
+++ b/doc/design/assistant/blog/day_293__gpg_builds/comment_1_4f152de8ea5aca4ec381d439e2a821f7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
+ nickname="Matt"
+ subject="comment 1"
+ date="2013-07-09T07:18:09Z"
+ content="""
+Hi, glad you added the git history and branch info to the walk through.  With a 40,000 foot view some of the wording in the docs (whilst correct) may lead to the wrong impression.  For example, in the unused data section, there is a sense that it seems bad that data can accumulate and doing a \"git rm\" rather than doing a \"git annex drop\" is a naughty thing to do (I know you don't actually say this).
+
+I think it needs to made clear that \"removing\" files is more subtle than in a traditional file-system: that there is a choice of deleting from the working tree so that contents remain and can be recovered or removing the file and contents labeled together (a.k.a \"dropping\").  With dropping so pervasive in the docs its easy to think this \"right\" (and only) way.  
+
+I wonder if a \"git annex rm\" which is simply an alias for \"git rm\" might be a good idea for a UI perspective...
+"""]]
diff --git a/doc/design/assistant/blog/day_293__gpg_builds/comment_2_42f625638638bc875379f6c604d6f673._comment b/doc/design/assistant/blog/day_293__gpg_builds/comment_2_42f625638638bc875379f6c604d6f673._comment
new file mode 100644
index 0000000000..6f00552e25
--- /dev/null
+++ b/doc/design/assistant/blog/day_293__gpg_builds/comment_2_42f625638638bc875379f6c604d6f673._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="LP"
+ ip="72.227.131.46"
+ subject="Just to say.."
+ date="2013-07-10T23:01:56Z"
+ content="""
+These updates are fantastic. They're great demonstrations of transparency in work, fun to read as a kstarter contributor, and interesting as a copypasta coder. Bravo.
+"""]]
diff --git a/doc/design/assistant/blog/day_294__release_day.mdwn b/doc/design/assistant/blog/day_294__release_day.mdwn
new file mode 100644
index 0000000000..b64b91ae50
--- /dev/null
+++ b/doc/design/assistant/blog/day_294__release_day.mdwn
@@ -0,0 +1,7 @@
+Got the release out, after fixing test suite and windows build breakage.
+This release has all the features on the command line side (--all,
+--unused, etc), but several bugfixes on the assistant side, and a lot
+of Windows bug fixes.
+
+I've spent this evening adding icons to git-annex on Linux.
+Even got the Linux standalone tarball to automatically install icons.
diff --git a/doc/design/assistant/blog/day_295__balls_in_the_air.mdwn b/doc/design/assistant/blog/day_295__balls_in_the_air.mdwn
new file mode 100644
index 0000000000..ebbad2973a
--- /dev/null
+++ b/doc/design/assistant/blog/day_295__balls_in_the_air.mdwn
@@ -0,0 +1,13 @@
+Been keeping several non-coding balls in the air recently, two of which
+landed today.
+
+First, Rsync.net is [offering a discount to all git-annex users](http://www.rsync.net/products/git-annex-pricing.html),
+at one third their normal price.
+"People using git-annex are clueful and won't be a big support burden for us,
+so it's a win-win."
+The web app will be updated offer the discount when setting up a rsync.net
+repository.
+
+Secondly, I've recorded an interview today for the Git Minutes podcast,
+about git-annex. Went well, looking forward to it going up, probably on
+Monday.
diff --git a/doc/design/assistant/blog/day_296__new_crowdfunding_campaign.mdwn b/doc/design/assistant/blog/day_296__new_crowdfunding_campaign.mdwn
new file mode 100644
index 0000000000..759bde12f0
--- /dev/null
+++ b/doc/design/assistant/blog/day_296__new_crowdfunding_campaign.mdwn
@@ -0,0 +1,41 @@
+Surprise! I'm running a new crowdfunding campaign, which I hope will fund
+several more months of git-annex development.
+
+<https://campaign.joeyh.name/>
+
+Please don't feel you have to give, but if you do decide to, give
+generously. ;) I'm accepting both Paypal and Bitcoin (via CoinBase.com),
+and have some rewards that you might enjoy.
+
+----
+
+I came up with two lists of things I hope this campaign will fund.
+These are by no means complete lists. First, some general features and
+development things:
+
+* Integrate better with Android.
+* Get the assistant and webapp ported to Windows.
+* Refine the automated stress testing tools to find and fix more problems
+  before users ever see them.
+* Automatic recovery. Cosmic ray flipped a bit in a file? 
+  USB drive corrupted itself? The assistant should notice these problems,
+  and fix them.
+* Encourage more contributions from others. For example, improve the
+  special remote plugin interface so it can do everything the native Haskell
+  interface can do. Eight new cloud storage services were added this year
+  as plugins, but we can do better!
+* Use deltas to reduce bandwidth needed to transfer modified versions of files.
+
+Secondly, some things to improve security:
+
+* Add easy support for encrypted git repositories
+  using [git-remote-gcrypt](https://github.com/blake2-ppc/git-remote-gcrypt),
+  so you can safely push to a repository on a server you don't control.
+* Add support for setting up and using GPG keys in the webapp.
+* Add protection to the XMPP protocol to guard against man in the middle
+  attacks if the XMPP server is compromised. Ie, Google should not be able to
+  learn about your git-annex repository even if you're using their servers.
+* To avoid leaking even the size of your encrypted files to
+  cloud storage providers, add a mode that stores fixed size chunks.
+
+It will also, of course, fund ongoing bugfixing, support, etc.
diff --git a/doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_1_cccad1a5103c504d21d0f8e69bb39e1b._comment b/doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_1_cccad1a5103c504d21d0f8e69bb39e1b._comment
new file mode 100644
index 0000000000..71cfd60c4e
--- /dev/null
+++ b/doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_1_cccad1a5103c504d21d0f8e69bb39e1b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="80.202.103.73"
+ subject="Shipping costs"
+ date="2013-07-15T05:07:07Z"
+ content="""
+Hi, it doesn't mention anything about offsetting shipping costs for people located outside of the US (like I am). Any chance you could add that?
+"""]]
diff --git a/doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_2_4fef7bd9c8e15cd57df365fadb95717f._comment b/doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_2_4fef7bd9c8e15cd57df365fadb95717f._comment
new file mode 100644
index 0000000000..57df8f9956
--- /dev/null
+++ b/doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_2_4fef7bd9c8e15cd57df365fadb95717f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.187"
+ subject="comment 2"
+ date="2013-07-15T05:26:54Z"
+ content="""
+Shipping is minimal, either $1 or $1.50 outside the US. It's factored into the reward levels, basically.
+"""]]
diff --git a/doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_3_0b9258a1f5079e53c60138f06d0c63b1._comment b/doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_3_0b9258a1f5079e53c60138f06d0c63b1._comment
new file mode 100644
index 0000000000..fc8754502f
--- /dev/null
+++ b/doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_3_0b9258a1f5079e53c60138f06d0c63b1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm3RqHNOKdnMCRF5V4306ON55XyJtQNlpY"
+ nickname="Marco"
+ subject="BitSync"
+ date="2013-07-15T13:11:03Z"
+ content="""
+How about using torrent to retrive files from a annex, something like BitSync would be great. Nice job Joey! Thank you.
+"""]]
diff --git a/doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_4_46183b97ca904bc06e46569c30db2edc._comment b/doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_4_46183b97ca904bc06e46569c30db2edc._comment
new file mode 100644
index 0000000000..3febd091ec
--- /dev/null
+++ b/doc/design/assistant/blog/day_296__new_crowdfunding_campaign/comment_4_46183b97ca904bc06e46569c30db2edc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://dzsino.myopenid.com/"
+ nickname="dzsino"
+ subject="mo' stickers, less problems :)"
+ date="2013-07-16T09:56:03Z"
+ content="""
+Hi Joey, since shipping would burn 10-15% of my funding, I added another $10, so you can just batch the stickers together. I hope it's cheaper this way.. Thanks!
+"""]]
diff --git a/doc/design/assistant/blog/day_297__back_to_work.mdwn b/doc/design/assistant/blog/day_297__back_to_work.mdwn
new file mode 100644
index 0000000000..c8dbedc45f
--- /dev/null
+++ b/doc/design/assistant/blog/day_297__back_to_work.mdwn
@@ -0,0 +1,16 @@
+It looks like I'm funded for at least the next 9 months! It would still be
+nice to get to a year. ;) <https://campaign.joeyh.name/>
+
+Working to get caught up on recent bug reports..
+
+Made `git annex uninit` not nuke anything that's left over in
+`.git/annex/objects` after unannexing all the files. After all, that could
+be important old versions of files or deleted file, and just because the
+user wants to stop using git-annex, doesn't mean git-annex shouldn't try to
+protect that data with its dying breath. So it prints out some suggestions
+in this case, and leaves it up to the user to decide what to do with the
+data.
+
+Fixed the Android autobuilder, which had stopped including the webapp.
+
+Looks like another autobuilder will be needed for OSX 10.9.
diff --git a/doc/design/assistant/blog/day_297__back_to_work/comment_1_e300feb821bfe7b76b2cec4376d16ffa._comment b/doc/design/assistant/blog/day_297__back_to_work/comment_1_e300feb821bfe7b76b2cec4376d16ffa._comment
new file mode 100644
index 0000000000..4e0042ed53
--- /dev/null
+++ b/doc/design/assistant/blog/day_297__back_to_work/comment_1_e300feb821bfe7b76b2cec4376d16ffa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://grossmeier.net/"
+ nickname="greg"
+ subject="uninit"
+ date="2013-07-16T23:43:38Z"
+ content="""
+Hah, that bit me in the butt when I first started experimenting with git-annex. I didn't lose anything, but it taught me a very important lesson (that I've had to learn many a time).
+"""]]
diff --git a/doc/design/assistant/blog/day_298__exceptional.mdwn b/doc/design/assistant/blog/day_298__exceptional.mdwn
new file mode 100644
index 0000000000..6be34821e6
--- /dev/null
+++ b/doc/design/assistant/blog/day_298__exceptional.mdwn
@@ -0,0 +1,21 @@
+Theme today seems to be fun with exceptions. 
+
+Fixed an uncaught exception that could crash the assistant's Watcher thread
+if just the right race occurred.
+
+Also fixed it to not throw an exception if another process is
+already transferring a file. What this means is that if you run multiple 
+`git annex get` processes on the same files, they'll cooperate in each
+picking their own files to get and download in parallel. (Also works for
+copy, etc.) Especially useful when downloading from an encrypted remote,
+since often one process will be decrypting a file while the other is
+downloading the next file. There is still room for improvement here; 
+a -jN option could better handle ensuring N downloads ran concurrently, and
+decouple decryption from downloading. But it would need the output layer to
+be redone to avoid scrambled output. (All the other stuff to make parallel
+git-annex transfers etc work was already in place for a long time.)
+
+----
+
+Campaign update: Now funded for nearly 10 months, and aiming for a year.
+<https://campaign.joeyh.name/>
diff --git a/doc/design/assistant/blog/day_299__bugfixing.mdwn b/doc/design/assistant/blog/day_299__bugfixing.mdwn
new file mode 100644
index 0000000000..2746151914
--- /dev/null
+++ b/doc/design/assistant/blog/day_299__bugfixing.mdwn
@@ -0,0 +1,8 @@
+Succeeded fixing a few bugs today, and followed up on a lot of other ones..
+
+Fixed checking when content is present in a non-bare repository accessed via
+http.
+
+My changes a few days ago turned out to make uninit leave hard links behind
+in .git/annex. Luckily the test suite caught this bug, and it was easily
+fixed by making uninit delete objects with 2 or more hard links at the end.
diff --git a/doc/design/assistant/blog/day_2__races.mdwn b/doc/design/assistant/blog/day_2__races.mdwn
new file mode 100644
index 0000000000..19f868a712
--- /dev/null
+++ b/doc/design/assistant/blog/day_2__races.mdwn
@@ -0,0 +1,45 @@
+Last night I got `git annex watch` to also handle deletion of files.
+This was not as tricky as feared; the key is using `git rm --ignore-unmatch`,
+which avoids most problematic situations (such as a just deleted file
+being added back before git is run).
+
+Also fixed some races when `git annex watch` is doing its startup scan of
+the tree, which might be changed as it's being traversed. Now only one
+thread performs actions at a time, so inotify events are queued up during
+the scan, and dealt with once it completes. It's worth noting that inotify
+can only buffer so many events .. Which might have been a problem except
+for a very nice feature of Haskell's inotify interface: It has a thread
+that drains the limited inotify buffer and does its own buffering.
+
+----
+
+Right now, `git annex watch` is not as fast as it could be when doing
+something like adding a lot of files, or deleting a lot of files.
+For each file, it currently runs a git command that updates the index.
+I did some work toward coalescing these into one command (which `git annex`
+already does normally). It's not quite ready to be turned on yet,
+because of some races involving `git add` that become much worse
+if it's delayed by event coalescing.
+
+----
+
+And races were the theme of today. Spent most of the day really
+getting to grips with all the fun races that can occur between
+modification happening to files, and `git annex watch`. The [[inotify]]
+page now has a long list of known races, some benign, and several,
+all involving adding files, that are quite nasty.
+
+I fixed one of those races this evening. The rest will probably involve
+moving away from using `git add`, which necessarily examines the file
+on disk, to directly shoving the symlink into git's index.
+
+BTW, it turns out that `dvcs-autosync` has grappled with some of these same
+races: <http://comments.gmane.org/gmane.comp.version-control.home-dir/665>
+I hope that `git annex watch` will be in a better place to deal with them,
+since it's only dealing with git, and with a restricted portion of it
+relevant to git-annex.
+
+It's important that `git annex watch` be rock solid. It's the foundation
+of the git annex assistant. Users should not need to worry about races
+when using it. Most users won't know what race conditions are. If only I
+could be so lucky!
diff --git a/doc/design/assistant/blog/day_300__new_logo.mdwn b/doc/design/assistant/blog/day_300__new_logo.mdwn
new file mode 100644
index 0000000000..9e13c4b131
--- /dev/null
+++ b/doc/design/assistant/blog/day_300__new_logo.mdwn
@@ -0,0 +1,36 @@
+git-annex has a new nicer versions of its [[logo]], thanks to John Lawrence.
+
+Finally tracked down a week-old bug about the watcher crashing. It turned
+out to crash when it encountered a directory containing a character that's
+invalid in the current locale. I've noticed that 'ü' is often the character I
+get bug reports about. After reproducing the bug I quickly tracked it down
+to code in the haskell hinotify library, and sent in a patch.
+
+Also uploaded a fixed hinotify to Debian, and deployed it to all 3 of the
+autobuilder chroots. That took much more time than actually fixing the bug.
+Quite a lot of yak shaving went on actually. Oh well. The Linux
+autobuilders are updated to use Debian unstable again, which is nice.
+
+Fixed a bug that prevented annex.diskreserve to be honored when storing
+files encrypted in a directory special remote.
+
+Taught the webapp the difference between initializing a new special remote
+and enabling an existing special remote, which fixed some bad behavior when
+it got confused.
+
+----
+
+And then for the really fun bug of the day! A user sent me a large file
+which badly breaks git annex add. Adding the file causes a symlink to be
+set up, but the file's content is not stored in the annex. Indeed, it's
+deleted. This is the first data loss bug since January 2012.
+
+Turns out it was caused by the code that handles the dummy files git uses
+in place of symlinks on FAT etc filesystems. Code that had no business
+running when `core.symlinks=true`. Code that was prone to false positives
+when looking at a tarball of a git-annex repository. So I put in multiple
+fixes for this bug. I'll be making a release on Monday.
+
+----
+
+Today's work was sponsored by Mikhail Barabanov. Thanks, Mikhail!
diff --git a/doc/design/assistant/blog/day_300__new_logo/comment_1_9fc64e33863b9fce00f6a03417a91e36._comment b/doc/design/assistant/blog/day_300__new_logo/comment_1_9fc64e33863b9fce00f6a03417a91e36._comment
new file mode 100644
index 0000000000..714fbc8254
--- /dev/null
+++ b/doc/design/assistant/blog/day_300__new_logo/comment_1_9fc64e33863b9fce00f6a03417a91e36._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~mikapflueger"
+ nickname="mikapflueger"
+ subject="The dreaded &quot;ü&quot;"
+ date="2013-07-21T20:56:30Z"
+ content="""
+Yeah, with the last name of \"Pflüger\" I also usually find bugs having to do with the letter \"ü\". (-;
+I guess it is simply one of the more frequent german umlauts, especially in names (the classic \"Müller\", which is one of the most common last names in Germany). And apparently the German cabal strikes here again.
+"""]]
diff --git a/doc/design/assistant/blog/day_300__new_logo/comment_2_e8aac0298f90004e81492d2c7f85eda0._comment b/doc/design/assistant/blog/day_300__new_logo/comment_2_e8aac0298f90004e81492d2c7f85eda0._comment
new file mode 100644
index 0000000000..b4bd78e3c9
--- /dev/null
+++ b/doc/design/assistant/blog/day_300__new_logo/comment_2_e8aac0298f90004e81492d2c7f85eda0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="Horns?"
+ date="2013-07-31T19:53:51Z"
+ content="""
+I don't necessarily mean this as a criticism, just an observation. I wasn't a big fan of the old logo, but this new one looks like it has horns. Or a bit like a pitchfork. 
+"""]]
diff --git a/doc/design/assistant/blog/day_300__new_logo/comment_3_6308c767f6e4bf090102191c91520d04._comment b/doc/design/assistant/blog/day_300__new_logo/comment_3_6308c767f6e4bf090102191c91520d04._comment
new file mode 100644
index 0000000000..beb5e281e0
--- /dev/null
+++ b/doc/design/assistant/blog/day_300__new_logo/comment_3_6308c767f6e4bf090102191c91520d04._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 3"
+ date="2013-07-31T20:03:13Z"
+ content="""
+I think the arrows are a bit too pointy. If someone wants to adjust the svg to make the arrows have a bit more of a rounded feel like in the old logo, that'd be fine by me.
+"""]]
diff --git a/doc/design/assistant/blog/day_301__direct_unannex.mdwn b/doc/design/assistant/blog/day_301__direct_unannex.mdwn
new file mode 100644
index 0000000000..c227607d66
--- /dev/null
+++ b/doc/design/assistant/blog/day_301__direct_unannex.mdwn
@@ -0,0 +1,21 @@
+No release today after all. Unexpected bandwidth failure. Maybe in a few
+days..
+
+Got unannex and uninit working in direct mode. This is one of the more
+subtle parts of git-annex, and took some doing to get it right.
+Surprisingly, unannex in direct mode actually turns out to be faster than
+in indirect mode. In direct mode it doesn't have to immediately commit the
+unannexing, it can just stage it to be committed later.
+
+Also worked on the ssh connection caching code. The perrennial problem with
+that code is that the fifo used to communicate with ssh has a small limit
+on its path, somewhere around 100 characters. This had caused problems when
+the hostname was rather long. I found a way to avoid needing to be able to
+reverse back from the fifo name to the hostname, and this let me take the
+md5sum of long hostnames, and use that shorter string for the fifo.
+
+Also various other bug followups.
+
+----
+
+[Campaign](https://campaign.joeyh.name/) is almost to 1 year!
diff --git a/doc/design/assistant/blog/day_302_release_day.mdwn b/doc/design/assistant/blog/day_302_release_day.mdwn
new file mode 100644
index 0000000000..d9dd9ec559
--- /dev/null
+++ b/doc/design/assistant/blog/day_302_release_day.mdwn
@@ -0,0 +1,6 @@
+Got the release out.
+
+I've been working on fleshing out 
+the [[timeline|/design/assistant]] for the next year.
+Including a fairly detailed set of things I want to do around
+[[/design/assistant/disaster_recovery]] in the assistant.
diff --git a/doc/design/assistant/blog/day_302_release_day/comment_1_fe6e572ba706e95188463d9f3e004d03._comment b/doc/design/assistant/blog/day_302_release_day/comment_1_fe6e572ba706e95188463d9f3e004d03._comment
new file mode 100644
index 0000000000..86984c478b
--- /dev/null
+++ b/doc/design/assistant/blog/day_302_release_day/comment_1_fe6e572ba706e95188463d9f3e004d03._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmnG4EuvZWse5hvgrl0XAK-U61e-0iGaao"
+ nickname="David"
+ subject="Broken dependencies on Debian wheezy "
+ date="2013-07-24T07:21:18Z"
+ content="""
+Hi Joey,
+Having installed this release (x86_64) on Debian wheezy I get the following error when I try to run git-annex:
+    
+    git-annex: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by git-annex)
+    git-annex: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by $HOME/.local/share/git-annex//usr/lib/x86_64-linux-gnu/libidn.so.11)
+    
+etc. for at least a dozen libraries. Different libs try to find different glibc version (2.14, 2.15, 2.16, 2.17). Previous releases were linked with GLIBC_2.13.
+
+
+
+"""]]
diff --git a/doc/design/assistant/blog/day_303__oops.mdwn b/doc/design/assistant/blog/day_303__oops.mdwn
new file mode 100644
index 0000000000..639e96de8f
--- /dev/null
+++ b/doc/design/assistant/blog/day_303__oops.mdwn
@@ -0,0 +1,8 @@
+Seems I forgot why I was using debian stable chroots to make the
+autobuilds: Lots of people still using old glibc version. Had to rebuild
+the stable chroots that I had upgraded to unstable. Wasted several hours..
+I was able to catch up on recent traffic in between.
+
+Was able to reproduce a bug where `git annex initremote` hung with some
+encrypted special remotes. Turns out to be a deadlock when it's not built
+with the threaded GHC runtime. So I've forced that runtime to be used.
diff --git a/doc/design/assistant/blog/day_304__dropunused_safety.mdwn b/doc/design/assistant/blog/day_304__dropunused_safety.mdwn
new file mode 100644
index 0000000000..28f5dc13c2
--- /dev/null
+++ b/doc/design/assistant/blog/day_304__dropunused_safety.mdwn
@@ -0,0 +1,28 @@
+The big news: Important behavior change in `git annex dropunused`. Now it
+checks, just like `git annex drop`, that it's not dropping the last copy of
+the file. So to lose data, you have to use `--force`. This continues the
+recent theme of making git-annex hold on more tenaciously to old data, and
+AFAIK it was the last place data could be removed without `--force`.
+
+Also a nice little fix to `git annex unused` so it doesn't identify
+temporary files as unused if they're being used to download a file.
+Fixing it was easy thanks to all the transfer logs and locking
+infrastucture built for the assistant.
+
+Fixed a bug in the assistant where even though syncing to a network
+remote was disabled, it would still sync with it every hour, or whenever
+a network connection was detected.
+
+Working on some direct mode scalability problems when thousands of the
+identical files are added. Fixing this may involvie replacing the current
+simple map files with something more scalable like a sqllite database.
+
+While tracking that down, I also found a bug with adding a ton of files
+in indirect mode, that could make the assistant stall.
+Turned out to be a laziness problem. (Worst kind of Haskell bug.) Fixed.
+
+----
+
+Today's sponsor is my sister, Anna Hess, who incidentially just put
+the manuscript of her latest ebook in the family's annex prior to its
+publication on Amazon this weekend.
diff --git a/doc/design/assistant/blog/day_304__dropunused_safety/comment_1_1bbcf6c74b6437c44ff8604401fb1432._comment b/doc/design/assistant/blog/day_304__dropunused_safety/comment_1_1bbcf6c74b6437c44ff8604401fb1432._comment
new file mode 100644
index 0000000000..d697770903
--- /dev/null
+++ b/doc/design/assistant/blog/day_304__dropunused_safety/comment_1_1bbcf6c74b6437c44ff8604401fb1432._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlUbH3eytydcwlWqv8oauE2Jg4NwcV9uA0"
+ nickname="Anna"
+ subject="A good day to be the sponsor!"
+ date="2013-07-27T12:31:27Z"
+ content="""
+Thanks for mentioning me!  I like being responsible for not allowing things to be deleted accidentally --- just my kind of feature. :-)
+
+As a shameless plug, here's the ebook mentioned above for those of you not privy to the family annex: http://www.amazon.com/Root-Cellar-Vegetables-Simplicity-ebook/dp/B00E6EGS0M/
+"""]]
diff --git a/doc/design/assistant/blog/day_305__interesting_bugs.mdwn b/doc/design/assistant/blog/day_305__interesting_bugs.mdwn
new file mode 100644
index 0000000000..8b76c929d9
--- /dev/null
+++ b/doc/design/assistant/blog/day_305__interesting_bugs.mdwn
@@ -0,0 +1,21 @@
+Worked on 3 interesting bugs today. One I noticed myself while doing tests
+with adding many thousands of files yesterday. Assistant was delaying
+making a last commit of the batch of files, and would only wake up and
+commit them after a further change was made. Turns out this bug was
+introduced in April while improving commit batching when making very large
+commits. I seem to remember someone mentioning this problem at some point,
+but I have not been able to find a bug report to close.
+
+Also tried to reproduce [[this_bug|bugs/utf8]]. Frustrating, because I'm
+quite sure I have made changes that will avoid it happening again,
+but since I still don't know what the root cause was, I can't let it go.
+
+The last bug is
+[[non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status]]
+and is a most strange thing. Still trying to get a handle on multiple
+aspects of it.
+
+Also various other bug triage. Down to only 10 messages in my git-annex
+folder.  That included merging about a dozen bugs about
+local pairing, that all seem to involve git-annex-shell not being found in
+path. Something is up with that..
diff --git a/doc/design/assistant/blog/day_306__offtopic.mdwn b/doc/design/assistant/blog/day_306__offtopic.mdwn
new file mode 100644
index 0000000000..cf96401d57
--- /dev/null
+++ b/doc/design/assistant/blog/day_306__offtopic.mdwn
@@ -0,0 +1,2 @@
+Technically offtopic, but did a fun side project today:
+<http://joeyh.name/blog/entry/git-annex_as_a_podcatcher/>
diff --git a/doc/design/assistant/blog/day_307__buuuugs.mdwn b/doc/design/assistant/blog/day_307__buuuugs.mdwn
new file mode 100644
index 0000000000..9cc4cae587
--- /dev/null
+++ b/doc/design/assistant/blog/day_307__buuuugs.mdwn
@@ -0,0 +1,31 @@
+Back to bug squashing. Fixed several, including a long-standing problem on
+OSX that made the app icon seem to "bounce" or not work. Followed up on a
+bunch more.
+
+The 4.20130723 git-annex release turns out to have broken support for
+running on crippled filesystems (Android, Windows). `git annex sync` will
+add dummy symlinks to the annex as if they were regular files, which is
+not good!
+[Recovery instructions](http://git-annex.branchable.com/bugs/regression_in_direct_mode_on_windows_:_weird___96__git_annex_sync__96___behavior/#comment-5d80649f9da85ac2fb505445a41207f5)
+I've updated the Android and Windows builds and recommend an immediate upgrade.
+Will make a formal release on Friday. 
+
+Spent some time improving the test suite on Windows, to catch this bug,
+and fix a bug that was preventing it from testing `git annex sync` on
+Windows.
+
+----
+
+I am getting very frustrated with this "unknown UUID" problem that a dozen
+people have reported. So far nobody has given me enough information to
+reproduce the problem. It seems to have something to do with
+`git-annex-shell` not being found on the remote system that has been either
+local paired with or is being used as a ssh server, but I don't yet
+understand what. I have spent hours today trying various scenarios to break
+git-annex and get this problem to happen.
+
+I certainly can improve the webapp's behavior when a repository's UUID is
+not known. The easiest fix would be to simply not display such
+repositories. Or there could be a UI to try to get the UUID.
+But I'm more interested in fixing the core problem than putting
+in a UI bandaid.
diff --git a/doc/design/assistant/blog/day_308__ssh-agent.mdwn b/doc/design/assistant/blog/day_308__ssh-agent.mdwn
new file mode 100644
index 0000000000..e18ff2ec15
--- /dev/null
+++ b/doc/design/assistant/blog/day_308__ssh-agent.mdwn
@@ -0,0 +1,16 @@
+Turns out ssh-agent is the cause of the unknown UUID bug! I got a tip
+about this from a user, and was quickly able to reproduce the bug that had
+eluded me so long. Anyone who has run `ssh-add` and is using ssh-agent
+would see the bug.
+
+It was easy enough to fix as it turns out. Just need to set IdentitiesOnly
+in .ssh/config where git-annex has set up its own IdentityFile to ensure
+that its special purpose ssh key is used rather than whatever key the
+ssh-agent has loaded into it. I do wonder why ssh behaves this way -- why
+would I set an IdentityFile for a host if I didn't want ssh to use it?
+
+Spent the rest of the day cleaning up after the bug. Since this affects so
+many people, I automated the clean up process. The webapp will
+detect repositories with this problem, and the user just has to click to
+clean up. It'll then correct their .ssh/config and re-enable the
+repository.
diff --git a/doc/design/assistant/blog/day_308__ssh-agent/comment_1_5f0fc810cf1e1cd9b3ddba3cd19bb19d._comment b/doc/design/assistant/blog/day_308__ssh-agent/comment_1_5f0fc810cf1e1cd9b3ddba3cd19bb19d._comment
new file mode 100644
index 0000000000..a40921ef69
--- /dev/null
+++ b/doc/design/assistant/blog/day_308__ssh-agent/comment_1_5f0fc810cf1e1cd9b3ddba3cd19bb19d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~mikapflueger"
+ nickname="mikapflueger"
+ subject="Thank you so much!"
+ date="2013-08-01T01:13:51Z"
+ content="""
+This behaviour of ssh has bugged me for years now (I even think it is an information leak – ssh offers basically all my public ssh keys to every server I try to connect to, even though that public key might be confidential). Although it had nothing to do with git-annex, you helped me a _lot_ by pointing me towards IdentitiesOnly. Really a nice setting!
+
+Cheers,
+
+Mika
+"""]]
diff --git a/doc/design/assistant/blog/day_309__filenames.mdwn b/doc/design/assistant/blog/day_309__filenames.mdwn
new file mode 100644
index 0000000000..30c9b516cb
--- /dev/null
+++ b/doc/design/assistant/blog/day_309__filenames.mdwn
@@ -0,0 +1,17 @@
+Today was a nice reminder that there are no end of bugs lurking in filename
+handling code. 
+
+First, fixed a bug that prevented git-annex from adding
+filenames starting with ":", because that is a special character to git.
+
+Second, discovered that git 1.8.4 rc0 has changed `git-cat-file --batch` in
+a way that makes it impossible to operate on filenames containing spaces.
+This is, IMHO, a reversion, so hopefully my
+[bug report](http://bugs.debian.org/718517) will get it fixed.
+
+Put in a workaround for that, although using the broken version of git
+with a direct mode repository with lots of spaces in file or directory
+names is going to really slow down git-annex, since it often has to fork a
+new git cat-file process for each file.
+
+Release day tomorrow..
diff --git a/doc/design/assistant/blog/day_310__release_day.mdwn b/doc/design/assistant/blog/day_310__release_day.mdwn
new file mode 100644
index 0000000000..1a8a84a662
--- /dev/null
+++ b/doc/design/assistant/blog/day_310__release_day.mdwn
@@ -0,0 +1,18 @@
+Got the release out, with rather a lot of fiddling to fix broken builds on
+various platforms.
+
+Also released a backport to Debian stable. This backport has the assistant,
+although without WebDAV support. Unfortunately it's an old version from
+May, since ghc transitions and issues have kept newer versions out of
+testing so far. Hope that will clear up soon (probably by dropping haskell
+support for s390x), and I can update it to a newer version. 
+If nothing else it allows using direct mode with Debian stable.
+
+Pleased that the git-cat-files bug was quickly fixed by Peff and has
+already been pulled into Junio's release tree!
+
+----
+
+This evening, I've added an interface around the new improved 
+`git check-ignore` in git 1.8.4. The assistant can finally honor `.gitignore`
+files!
diff --git a/doc/design/assistant/blog/day_310__release_day/comment_1_1e008583cebd8e373e83729529914db7._comment b/doc/design/assistant/blog/day_310__release_day/comment_1_1e008583cebd8e373e83729529914db7._comment
new file mode 100644
index 0000000000..749f77d9d2
--- /dev/null
+++ b/doc/design/assistant/blog/day_310__release_day/comment_1_1e008583cebd8e373e83729529914db7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="This makes me happy :-)"
+ date="2013-08-04T00:46:25Z"
+ content="""
+Glad my work was worth the effort. Thanks for that.
+"""]]
diff --git a/doc/design/assistant/blog/day_311__Windows_porting.mdwn b/doc/design/assistant/blog/day_311__Windows_porting.mdwn
new file mode 100644
index 0000000000..fe14a6e4b6
--- /dev/null
+++ b/doc/design/assistant/blog/day_311__Windows_porting.mdwn
@@ -0,0 +1,10 @@
+Made two big improvements to the Windows port, in just a few hours.
+First, got gpg working, and encrypted special remotes work on Windows.
+Next, fixed a permissions problem that was breaking removing files
+from directory special remotes on Windows.
+(Also cleaned up a lot of compiler warnings on Windows.)
+
+I think I'm almost ready to move the Windows port from alpha to beta
+status. The only really bad problem that I know of with using it is that
+due to a lack of locking, it's not safe to run multiple git-annex
+commands at the same time in Windows.
diff --git a/doc/design/assistant/blog/day_311__Windows_porting/comment_1_8e738f54a72557bee1e19970472b925c._comment b/doc/design/assistant/blog/day_311__Windows_porting/comment_1_8e738f54a72557bee1e19970472b925c._comment
new file mode 100644
index 0000000000..9f4bf2284a
--- /dev/null
+++ b/doc/design/assistant/blog/day_311__Windows_porting/comment_1_8e738f54a72557bee1e19970472b925c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlpSOjMH7Iaz56v6Pr9KCFSpbvMXvg-y9o"
+ nickname="Dominik"
+ subject="That's amazing..."
+ date="2013-08-17T11:18:05Z"
+ content="""
+...so pretty soon my bi-directional Mac <-> Win Git-Annex-Assitant sync via rsync.net will work without a VM on Windows :-)
+"""]]
diff --git a/doc/design/assistant/blog/day_312__DebConf_midpoint.mdwn b/doc/design/assistant/blog/day_312__DebConf_midpoint.mdwn
new file mode 100644
index 0000000000..40c38aed4f
--- /dev/null
+++ b/doc/design/assistant/blog/day_312__DebConf_midpoint.mdwn
@@ -0,0 +1,30 @@
+Wow, 11 days off! I was busy with first dentistry and then DebConf.
+
+Yesterday I [visited CERN](http://joeyh.name/blog/entry/words_fail_me/) and
+got to talk with some of their IT guys about how they manage their tens of
+petabytes of data. Interested to hear they also have the equivilant of a
+per-subdirectory annex.numcopies setting. OTOH, they have half a billion
+more files than git's index file is likely to be able to scale to support. ;)
+
+Pushed a release out today despite not having many queued changes. 
+Also, I got git-annex migrated to Debian testing, and so was also
+able to update the wheezy backport to a just 2 week old version.
+
+Today is also the last day of the [campaign](https://campaign.joeyh.name/)!
+
+----
+
+There has been a ton of discussion about git-annex here at DebConf,
+including 3 BoF sessions that mostly focused on it, among other git stuff.
+Also, RichiH will be presenting his
+"[Gitify Your Life](http://penta.debconf.org/dc13_schedule/events/1025.en.html)"
+talk on Friday; you can catch it on the [live stream](http://blog.debconf.org/blog/2013/08/14#hl_dc13_recordings).
+
+I've also had a continual stream of in-person bug and feature requests.
+(Mostly features.)
+These have been added to the wiki and I look forward to working on that
+backlog when I get home.
+
+As for coding, I am doing little here, but I do have a branch cooking that
+adds some options to `git annex import` to control handling of duplicate
+files.
diff --git a/doc/design/assistant/blog/day_313__back.mdwn b/doc/design/assistant/blog/day_313__back.mdwn
new file mode 100644
index 0000000000..28c7f971d4
--- /dev/null
+++ b/doc/design/assistant/blog/day_313__back.mdwn
@@ -0,0 +1,34 @@
+Back home. I have some 170 messages of backlog to attend to. Rather than
+digging into that on my first day back, I spent some time implementing some
+new features.
+
+`git annex import` has grown three options that help managing importing of
+duplicate files in different ways. I started work on that last week, but
+didn't have time to find a way to avoid the `--deduplicate` option
+checksumming each imported file twice. Unfortunately, I have still not
+found a way I'm happy with, so it works but is not as efficient as it could
+be.
+
+`git annex mirror` is a new command suggested to me by someone at DebConf
+(they don't seem to have filed the requested todo). It arranges for two
+repositories to contain the same set of files, as much as possible (when
+numcopies allows). So for example, `git annex mirror --to otherdrive`
+will make the otherdrive remote have the same files present and not present
+as the local repository.
+
+I am thinking about expanding `git annex sync` with an option to also sync
+data. I know some find it confusing that it only syncs the git metadata
+and not the file contents. That still seems to me to be the best and most
+flexible behavior, and not one I want to change in any case since
+it would be most unexpected if `git annex sync` downloaded a lot of stuff
+you don't want. But I can see making `git annex sync --data` download
+all the file contents it can, as well as uploading all available file
+contents to each remote it syncs with. And `git annex sync --data --auto`
+limit that to only the preferred content. Although perhaps
+these command lines are too long to be usable?
+
+----
+
+With the campaign more or less over, I only have a little over a week
+before it's time to dive into the first big item on the roadmap. Hope
+to be through the backlog by then.
diff --git a/doc/design/assistant/blog/day_313__back/comment_1_fbf3fdf9688c18156753d446facd942d._comment b/doc/design/assistant/blog/day_313__back/comment_1_fbf3fdf9688c18156753d446facd942d._comment
new file mode 100644
index 0000000000..7230a15682
--- /dev/null
+++ b/doc/design/assistant/blog/day_313__back/comment_1_fbf3fdf9688c18156753d446facd942d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="GLITTAH"
+ ip="77.247.181.162"
+ subject="comment 1"
+ date="2013-08-20T22:42:46Z"
+ content="""
+I wouldn't worry about the commands being too long.  If they're used often enough, they'll get aliased.
+
+alias GASDA='git annex sync --data --auto'
+"""]]
diff --git a/doc/design/assistant/blog/day_314__quvi.mdwn b/doc/design/assistant/blog/day_314__quvi.mdwn
new file mode 100644
index 0000000000..3c38e427d8
--- /dev/null
+++ b/doc/design/assistant/blog/day_314__quvi.mdwn
@@ -0,0 +1,27 @@
+Made some good progress on the backlog today. Fixed some bugs, applied some
+patches. Noticing that without me around, things still get followed up
+on, to a point, for example incomplete test cases for bugs get corrected so
+they work. This is a very good thing. Community!
+
+I had to stop going through the backlog when I got to one message from
+Anarcat mentioning [quvi](http://quvi.sourceforge.net/). That turns
+out to be just what is needed to implement the often-requested feature
+of `git-annex addurl` supporting YouTube and other similar sites. So I
+spent the rest of the day making that work. For example:
+
+<pre>
+% git annex addurl --fast 'http://www.youtube.com/watch?v=1mxPFHBCfuU&list=PL4F80C7D2DC8D9B6C&index=1'
+addurl Star_Wars_X_Wing__Seth_Green__Clare_Grant__and_Mike_Lamond_Join_Wil_on_TableTop_SE2E09.webm ok
+</pre>
+
+Yes, that got the video title and used it as the filename, and yes,
+I can commit this file and run `git annex get` later, and it will be
+able to go download the video! I can even use `git annex fsck --fast`
+to make sure YouTube still has my videos. Awesome.
+
+The great thing about quvi is it takes the url to a video webpage, and
+returns an url that can be used to download the actual video file. So it
+simplifies ugly flash videos as far out of existence as is possible.
+However, since the direct url to the video file may not keep working for long.
+addurl actually records the page's url, with an added indication that quvi
+should be used to get it.
diff --git a/doc/design/assistant/blog/day_314__quvi/comment_1_3fdfb0742cb5422530ddd97b904f2a42._comment b/doc/design/assistant/blog/day_314__quvi/comment_1_3fdfb0742cb5422530ddd97b904f2a42._comment
new file mode 100644
index 0000000000..797d25101d
--- /dev/null
+++ b/doc/design/assistant/blog/day_314__quvi/comment_1_3fdfb0742cb5422530ddd97b904f2a42._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="New YouTube problems"
+ date="2013-09-05T03:45:16Z"
+ content="""
+Joey, you may notice eventually that YouTube is moving some videos, especially long ones, to a new format called DASH, which splits them up into smaller parts; unfortunately, it also delivers the audio as a separate file, requiring something like ffmpeg to merge it with the video.  I don't know anything about quvi, but youtube-dl recently added support for DASH.  It's a Python program that's packaged in Debian, but it can also update itself if you install it locally, which is helpful if Debian is frozen...  Anyway, if you need it in the future, youtube-dl might be helpful.
+"""]]
diff --git a/doc/design/assistant/blog/day_315__backlog.mdwn b/doc/design/assistant/blog/day_315__backlog.mdwn
new file mode 100644
index 0000000000..ec0ee33be3
--- /dev/null
+++ b/doc/design/assistant/blog/day_315__backlog.mdwn
@@ -0,0 +1,12 @@
+After a couple days plowing through it, my backlog is down to 30 messages
+from 150. And most of what's left is legitimate bugs and todo items.
+
+Spent a while today on an ugly file descriptor leak in the assistant's
+local pairing listener. This was an upstream bug in the network-multicast
+library, so while I've written a patch to fix it, the fix isn't quite 
+deployed yet. The file descriptor leak happens when the assistant is
+running and there is no network interface that supports multicast.
+I was able to reproduce it by just disconnecting from wifi.
+
+Meanwhile, guilhem has been working on patches that promise to massively
+speed up `git annex unused`! I will be reviewing them tonight.
diff --git a/doc/design/assistant/blog/day_316__day_off.mdwn b/doc/design/assistant/blog/day_316__day_off.mdwn
new file mode 100644
index 0000000000..b26118b17b
--- /dev/null
+++ b/doc/design/assistant/blog/day_316__day_off.mdwn
@@ -0,0 +1,6 @@
+Today was a day off, really. However, I have a job running to try to
+build get a version of ghc-android that works on newer Android releases.
+
+Also, guilhem's `git annex unused` speedup patch landed. The results are
+extrordinary -- speedups on the order of 50 to 100 times faster should
+not be uncommon. Best of all (for me), it still runs in constant memory!
diff --git a/doc/design/assistant/blog/day_317__misc.mdwn b/doc/design/assistant/blog/day_317__misc.mdwn
new file mode 100644
index 0000000000..e2acf21684
--- /dev/null
+++ b/doc/design/assistant/blog/day_317__misc.mdwn
@@ -0,0 +1,17 @@
+Spent a while tracking down a bug that causes a crash on OSX when setting
+up an XMPP account. I managed to find a small test case that reliably
+crashes, and sent it off to the author of the haskell-gnutls bindings,
+which had one similar segfault bug fixed before with a similar test case.
+Fingers crossed..
+
+Just finished tracking down a bug in the Android app that caused its
+terminal to spin and consume most CPU (and presumably a lot of battery).
+I introduced this bug when adding the code to open urls written to a fifo,
+due to misunderstanding how java objects are created, basically. This bug
+is bad enough to do a semi-immediate release for; luckily it's just about
+time for a release anyway with other improvements, so in the next few
+days..
+
+Have not managed to get a recent ghc-android to build so far.
+
+Guilhem fixed some bugs in `git annex unused`.
diff --git a/doc/design/assistant/blog/day_36__minimal_test_case.mdwn b/doc/design/assistant/blog/day_36__minimal_test_case.mdwn
new file mode 100644
index 0000000000..b77da14ddf
--- /dev/null
+++ b/doc/design/assistant/blog/day_36__minimal_test_case.mdwn
@@ -0,0 +1,9 @@
+Managed to find a minimal, 20 line test case for at least one of the ways
+git-annex was hanging with GHC's threaded runtime. Sent it off to
+haskell-cafe for analysis.
+[thread](http://thread.gmane.org/gmane.comp.lang.haskell.cafe/99334)
+
+Further managed to narrow the bug down to MissingH's use of logging code,
+that git-annex doesn't use. [bug report](http://bugs.debian.org/681621).
+So, I can at least get around this problem with a modified version of
+MissingH. Hopefully that was the only thing causing the hangs I was seeing!
diff --git a/doc/design/assistant/blog/day_37__back.mdwn b/doc/design/assistant/blog/day_37__back.mdwn
new file mode 100644
index 0000000000..7aef0b681a
--- /dev/null
+++ b/doc/design/assistant/blog/day_37__back.mdwn
@@ -0,0 +1,64 @@
+Back home and laptop is fixed.. back to work.
+
+Warmup exercises:
+
+* Went in to make it queue transfers when a broken symlink is received,
+  only to find I'd already written code to do that, and forgotten about it.
+  Heh. Did check that the git-annex branch is always sent first,
+  which will ensure that code always knows where to transfer a key from.
+  I had probably not considered this wrinkle when first writing the code;
+  it worked by accident.
+
+* Made the assistant check that a remote is known to have a key before
+  queueing a download from it.
+
+* Fixed a bad interaction between the `git annex map` command and the
+  assistant.
+
+----
+
+Tried using a modified version of `MissingH` that doesn't use `HSLogger`
+to make git-annex work with the threaded GHC runtime. Unfortunatly,
+I am still seeing hangs in at least 3 separate code paths when
+running the test suite. I may have managed to fix one of the hangs,
+but have not grokked what's causing the others.
+
+----
+
+I now have access to a Mac OSX system, thanks to Kevin M. I've fixed
+some portability problems in git-annex with it before, but today I tested
+the assistant on it:
+
+* Found a problem with the kqueue code that prevents incoming pushes from
+  being noticed.
+
+  The problem was that the newly added git ref file does not trigger an add
+  event. The kqueue code saw a generic change event for the refs directory,
+  but since the old file was being deleted and replaced by the new file,
+  the kqueue code, which already had the old file in its cache, did not notice
+  the file had been replaced.
+
+  I fixed that by making the kqueue code also track the inode of each file.
+  Currently that adds the overhead of a stat of each file, which could be
+  avoided if haskell exposed the inode returned by `readdir`. Room to
+  optimise this later...
+
+* Also noticed that the kqueue code was not separating out file deletions
+  from directory deletions. IIRC Jimmy had once mentioned a problem with file
+  deletions not being noticed by the assistant, and this could be responsible
+  for that, although the directory deletion code seems to handle them ok
+  normally. It was making the transfer watching thread not notice when
+  any transfers finished, for sure. I fixed this oversight, looking in the
+  cache to see if there used to be a file or a directory, and running the
+  appropriate hook.
+
+Even with these fixes, the assistant does not yet reliably transfer file
+contents on OSX. I think the problem is that with kqueue we're not
+guaranteed to get an add event, and a deletion event for a transfer
+info file -- if it's created and quickly deleted, the code that
+synthensizes those events doesn't run in time to know it existed.
+Since the transfer code relies on deletion events to tell when transfers
+are complete, it stops sending files after the first transfer, if the
+transfer ran so quickly it doesn't get the expected events. 
+
+So, will need to work on OSX support some more...
diff --git a/doc/design/assistant/blog/day_39__twice_is_enemy_action.mdwn b/doc/design/assistant/blog/day_39__twice_is_enemy_action.mdwn
new file mode 100644
index 0000000000..14896fcb1b
--- /dev/null
+++ b/doc/design/assistant/blog/day_39__twice_is_enemy_action.mdwn
@@ -0,0 +1,66 @@
+Beating my head against the threaded runtime some more. I can reproduce
+one of the hangs consistently by running 1000 git annex add commands
+in a loop. It hangs around 1% of the time, reading from `git cat-file`.
+
+Interestingly, `git cat-file` is not yet running at this point -- 
+git-annex has forked a child process, but the child has not yet exec'd it.
+Stracing the child git-annex, I see it stuck in a futex. Adding tracing,
+I see the child never manages to run any code at all.
+
+This really looks like the problem is once again in MissingH, which uses
+`forkProcess`. Which happens to come with a big warning about being very
+unsafe, in very subtle ways. Looking at the C code that the newer `process`
+library uses when sparning a pipe to a process, it messes around with lots of
+things; blocking signals, stopping a timer, etc. Hundreds of lines of C
+code to safely start a child process, all doing things that MissingH omits.
+
+That's the second time I've seemingly isolated a hang in the GHC threaded
+runtime to MissingH.
+
+And so I've started converting git-annex to use the new `process` library,
+for running all its external commands. John Goerzen had mentioned `process`
+to me once before when I found a nasty bug in MissingH, as the cool new
+thing that would probably eliminate the `System.Cmd.Utils` part of MissingH,
+but I'd not otherwise heard much about it. (It also seems to have the
+benefit of supporting Windows.)
+
+This is a big change and it's early days, but each time I see a hang, I'm
+converting the code to use `process`, and so far the hangs have just gone
+away when I do that.
+
+---
+
+Hours later... I've converted *all* of git-annex to use `process`.
+
+In the er, process, the `--debug` switch stopped printing all the commands
+it runs. I may try to restore that later.
+
+I've not tested everything, but the test suite passes, even when
+using the threaded runtime. **MILESTONE**
+
+Looking forward to getting out of these weeds and back to useful work..
+
+---
+
+Hours later yet.... The `assistant` branch in git now uses the threaded
+runtime. It works beautifully, using proper threads to run file transfers
+in.
+
+That should fix the problem I was seeing on OSX yesterday. Too tired to
+test it now.
+
+--
+
+Amazingly, all the assistant's own dozen or so threads and thread
+synch variables etc all work great under the threaded runtime. I had
+assumed I'd see yet more concurrency problems there when switching to it,
+but it all looks good. (Or whatever problems there are are subtle ones?)
+
+I'm very relieved. The threaded logjam is broken! I had been getting
+increasingly worried that not having the threaded runtime available would
+make it very difficult to make the assistant perform really well, and cause
+problems with the webapp, perhaps preventing me from using Yesod.
+
+Now it looks like smooth sailing ahead. Still some hard problems, but
+it feels like with inotify and kqueue and the threaded runtime all
+dealt with, the really hard infrastructure-level problems are behind me.
diff --git a/doc/design/assistant/blog/day_3__more_races.mdwn b/doc/design/assistant/blog/day_3__more_races.mdwn
new file mode 100644
index 0000000000..9c11828420
--- /dev/null
+++ b/doc/design/assistant/blog/day_3__more_races.mdwn
@@ -0,0 +1,26 @@
+Today I worked on the race conditions, and fixed two of them. Both
+were fixed by avoiding using `git add`, which looks at the files currently
+on disk. Instead, `git annex watch` injects symlinks directly into git's
+index, using `git update-index`.
+
+There is one bad race condition remaining. If multiple processes have a
+file open for write, one can close it, and it will be added to the annex.
+But then the other can still write to it.
+
+----
+
+Getting away from race conditions for a while, I made `git annex watch`
+not annex `.gitignore` and `.gitattributes` files.
+
+And, I made it handle running out of inotify descriptors. By default,
+`/proc/sys/fs/inotify/max_user_watches` is 8192, and that's how many
+directories inotify can watch. Now when it needs more, it will print
+a nice message showing how to increase it with `sysctl`.
+
+FWIW, DropBox also uses inotify and has the same limit. It seems to not
+tell the user how to fix it when it goes over. Here's what `git annex
+watch` will say:
+
+	Too many directories to watch! (Not watching ./dir4299)
+	Increase the limit by running:
+	  echo fs.inotify.max_user_watches=81920 | sudo tee -a /etc/sysctl.conf; sudo sysctl -p
diff --git a/doc/design/assistant/blog/day_3__more_races/comment_1_d6015338f602b574a3805de5481fc45e._comment b/doc/design/assistant/blog/day_3__more_races/comment_1_d6015338f602b574a3805de5481fc45e._comment
new file mode 100644
index 0000000000..2d330f3327
--- /dev/null
+++ b/doc/design/assistant/blog/day_3__more_races/comment_1_d6015338f602b574a3805de5481fc45e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkmtR6oVColYKoU0SjBORLDGrwR10G-mKo"
+ nickname="Jo-Herman"
+ subject="Dropbox Inotify"
+ date="2012-06-06T22:03:29Z"
+ content="""
+Actually, Dropbox giver you a warning via libnotify inotify. It tends to go away too quickly to properly read though, much less actually copy down the command...
+"""]]
diff --git a/doc/design/assistant/blog/day_3__more_races/comment_2_4d6b23fc6442e0ee0303523cb69d0fba._comment b/doc/design/assistant/blog/day_3__more_races/comment_2_4d6b23fc6442e0ee0303523cb69d0fba._comment
new file mode 100644
index 0000000000..523e6d85ff
--- /dev/null
+++ b/doc/design/assistant/blog/day_3__more_races/comment_2_4d6b23fc6442e0ee0303523cb69d0fba._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.8.36"
+ subject="comment 2"
+ date="2012-06-06T23:25:57Z"
+ content="""
+When I work on the [[webapp]], I'm planning to make it display this warning, and any other similar warning messages that might come up.
+"""]]
diff --git a/doc/design/assistant/blog/day_3__more_races/comment_3_03f5b2344c2a47dea60086f217d60f9b._comment b/doc/design/assistant/blog/day_3__more_races/comment_3_03f5b2344c2a47dea60086f217d60f9b._comment
new file mode 100644
index 0000000000..92f5dcbd62
--- /dev/null
+++ b/doc/design/assistant/blog/day_3__more_races/comment_3_03f5b2344c2a47dea60086f217d60f9b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"
+ nickname="Jim"
+ subject="Wording"
+ date="2012-06-07T03:43:19Z"
+ content="""
+For the unfamiliar, it's hard to tell if a command like that would persist.  I'd suggest being as clear as possible, e.g.:
+
+    Increase the limit for now by running:
+      sudo sysctl fs.inotify.max_user_watches=81920
+    Increase the limit now and automatically at every boot by running:
+      echo fs.inotify.max_user_watches=81920 | sudo tee -a /etc/sysctl.conf; sudo sysctl -p
+
+"""]]
diff --git a/doc/design/assistant/blog/day_3__more_races/comment_4_860e90e989ec022100001c65e353a91e._comment b/doc/design/assistant/blog/day_3__more_races/comment_4_860e90e989ec022100001c65e353a91e._comment
new file mode 100644
index 0000000000..05b601eafe
--- /dev/null
+++ b/doc/design/assistant/blog/day_3__more_races/comment_4_860e90e989ec022100001c65e353a91e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.8.36"
+ subject="comment 4"
+ date="2012-06-07T04:48:15Z"
+ content="""
+Good thought Jim. I've done something like that.
+"""]]
diff --git a/doc/design/assistant/blog/day_40__dbus.mdwn b/doc/design/assistant/blog/day_40__dbus.mdwn
new file mode 100644
index 0000000000..049c3ffe0d
--- /dev/null
+++ b/doc/design/assistant/blog/day_40__dbus.mdwn
@@ -0,0 +1,100 @@
+Really productive day today, now that I'm out of the threaded runtime
+tarpit!
+
+First, brought back `--debug` logging, better than before! As part of that, I
+wrote some 250 lines of code to provide a IMHO more pleasant interface to
+`System.Process` (itself only 650 lines of code) that avoids all the
+low-level setup, cleanup, and tuple unpacking. Now I can do things like
+write to a pipe to a process, and ensure it exits nonzero, this easily:
+
+	withHandle StdinHandle createProcessSuccess (proc "git" ["hash-object", "--stdin"]) $ \h ->
+		hHutStr h objectdata
+
+My interface also makes it easy to run nasty background processes,
+reading their output lazily.
+
+	lazystring <- withHandle StdoutHandle createBackgroundProcess (proc "find" ["/"]) hGetContents
+
+Any true Haskellers are shuddering here, I really should be using
+conduits or pipes, or something. One day..
+
+----
+
+The assistant needs to detect when removable drives are attached, and
+sync with them. This is a reasonable thing to be working on at this point,
+because it'll make the currently incomplete data transfer code fully usable
+for the sneakernet use case, and firming that up will probably be a good
+step toward handing other use cases involving data transfer over the
+network, including cases where network remotes are transientely available.
+
+So I've been playing with using dbus to detect mount events.
+There's a very nice Haskell library to use dbus.
+
+This simple program will detect removable drives being mounted, and
+works on Xfce (as long as you have automounting enabled in its
+configuration), and should also work on Gnome, and, probably, KDE:
+
+[[!format haskell """
+{-# LANGUAGE OverloadedStrings #-}
+
+import Data.List (sort)
+import DBus
+import DBus.Client
+import Control.Monad
+
+main = do
+	client <- connectSession
+    
+	listen client mountadded $ \s ->
+		putStrLn (show s)
+
+	forever $ getLine -- let listener thread run forever
+
+	where
+		mountadded = matchAny
+			{ matchInterface = Just "org.gtk.Private.RemoteVolumeMonitor"
+			, matchMember = Just "MountAdded"
+			}
+"""]]
+
+(Yeah... "org.gtk.Private.RemoteVolumeMonitor". There are so
+many things wrong with that string. What does gtk have to do with
+mounting a drive? Why is it Private? Bleagh. Should I only match
+the "MountAdded" member and not the interface? Seems everyone who does
+this relies on google to find other people who have cargo-culted it,
+or just runs `dbus-monitor` and picks out things.
+There seems to be no canonical list of events. Bleagh.)
+
+----
+
+Spent a while shaving a yak of needing a `getmntent` interface in Haskell.
+Found one in a hsshellscript library; since that library is not packaged
+in Debian, and I don't really want to depend on it, I extracted just
+the mtab and fstab parts of it into a little library in git-annex.
+
+----
+
+I've started putting together a MountWatcher thread. On systems without
+dbus (do OSX or the BSDs have dbus?), or if dbus is not running, it polls
+`/etc/mtab` every 10 seconds for new mounts. When dbus is available,
+it doesn't need the polling, and should notice mounts more quickly.
+
+Open question: Should it still poll even when dbus is available? Some of us
+like to mount our own drives, by hand and may have automounting disabled. It'd
+be good if the assistant supported that. This might need a
+`annex.no-dbus` setting, but I'd rather avoid needing such manual
+configuration.
+
+One idea is to do polling in addition to dbus, if `/etc/fstab` contains
+mount points that seem to be removable drives, on which git remotes lives.
+Or it could always do polling in addition to dbus, which is just some extra
+work. Or, it could try to introspect dbus to see if mount events will
+be generated.
+
+The MountWatcher so far only detects new mounts and prints out what
+happened. Next up: Do something in response to them. 
+
+This will involve manipulating the Annex state to belatedly add the Remote
+on the mount point.. tricky. And then, for Git Remotes, it should pull/push
+the Remote to sync git data. Finally, for all remotes, it will need to
+queue Transfers of file contents from/to the newly available Remote.
diff --git a/doc/design/assistant/blog/day_40__dbus/comment_1_43ed2a79629868b018ec9f54a32bcacc._comment b/doc/design/assistant/blog/day_40__dbus/comment_1_43ed2a79629868b018ec9f54a32bcacc._comment
new file mode 100644
index 0000000000..3670e7dd55
--- /dev/null
+++ b/doc/design/assistant/blog/day_40__dbus/comment_1_43ed2a79629868b018ec9f54a32bcacc._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="dbus vs polling"
+ date="2012-07-19T17:38:40Z"
+ content="""
+I am running KDE, dbus, and I like to mount drives by hand; all that without bothering to set up /etc/fstab... Often from CLI so I don't even see the notifications for new drives.
+
+Especially while on the road, I will use no KDE, but just a tty or three. Still, dbus will be running.
+
+Long story short, I would need polling for the assistant to work flawlessly in all use cases.
+"""]]
diff --git a/doc/design/assistant/blog/day_40__dbus/comment_2_6799f2baf6a6ce14b1fa76a8402840c0._comment b/doc/design/assistant/blog/day_40__dbus/comment_2_6799f2baf6a6ce14b1fa76a8402840c0._comment
new file mode 100644
index 0000000000..832be854a3
--- /dev/null
+++ b/doc/design/assistant/blog/day_40__dbus/comment_2_6799f2baf6a6ce14b1fa76a8402840c0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="hamish"
+ ip="203.0.139.24"
+ subject="dbus vs polling "
+ date="2012-07-22T07:13:37Z"
+ content="""
+I, too, am running a dbus but like to hand mount my filesystems.  However, I'd imagine that I am both a minority and that my minority could like the extra control, so perhaps even a \"re-read the mtab /now/\" command that can be manually run after something is  manually mounted would suffice
+
+Is it not possible to use inotify on the mtab?
+"""]]
diff --git a/doc/design/assistant/blog/day_40__dbus/comment_3_fa1d7444bdafcb990cacf2ace7ee6ef1._comment b/doc/design/assistant/blog/day_40__dbus/comment_3_fa1d7444bdafcb990cacf2ace7ee6ef1._comment
new file mode 100644
index 0000000000..a372670b86
--- /dev/null
+++ b/doc/design/assistant/blog/day_40__dbus/comment_3_fa1d7444bdafcb990cacf2ace7ee6ef1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.169"
+ subject="comment 3"
+ date="2012-07-22T16:03:52Z"
+ content="""
+How did I not think about using my favorite hammer on this problem too? But, no, /proc/mounts cannot be watched with inotify it seems, and of course the BSDs don't seem to have a file at all.
+
+I think the dbus stuff is sorted out for manual users, see later blog entries.
+"""]]
diff --git a/doc/design/assistant/blog/day_40__dbus/comment_4_3399ddad951c1a950281bb6941fc3f6f._comment b/doc/design/assistant/blog/day_40__dbus/comment_4_3399ddad951c1a950281bb6941fc3f6f._comment
new file mode 100644
index 0000000000..9007850e46
--- /dev/null
+++ b/doc/design/assistant/blog/day_40__dbus/comment_4_3399ddad951c1a950281bb6941fc3f6f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2012-07-19T18:43:30Z"
+ content="""
+Joey, yes dbus is available from macports and homebrew, it's not installed by default (or as a dependancy) for most packages in macports.
+"""]]
diff --git a/doc/design/assistant/blog/day_40__dbus/comment_5_40b6b9d741d3081203f0cc94eb8dc3ea._comment b/doc/design/assistant/blog/day_40__dbus/comment_5_40b6b9d741d3081203f0cc94eb8dc3ea._comment
new file mode 100644
index 0000000000..38916dd8c2
--- /dev/null
+++ b/doc/design/assistant/blog/day_40__dbus/comment_5_40b6b9d741d3081203f0cc94eb8dc3ea._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://smcv.pseudorandom.co.uk/"
+ nickname="smcv"
+ subject="comment 5"
+ date="2012-07-31T09:58:13Z"
+ content="""
+It's `org.gtk` because gvfs, GLib and Gtk are all products of gtk.org (there is no separate glib.org).
+
+It's `Private` because the gvfs developers don't consider its D-Bus interface to be stable API, I believe. The official API for it is the C API in GIO, part of GLib.
+
+To poll for changes to /proc/mounts on Linux, you open it for reading and poll() for POLLERR (not sure why it gets to be different, but it is). See gio/gunixmounts.c in recent GLib.
+"""]]
diff --git a/doc/design/assistant/blog/day_41__foo.mdwn b/doc/design/assistant/blog/day_41__foo.mdwn
new file mode 100644
index 0000000000..99a977f602
--- /dev/null
+++ b/doc/design/assistant/blog/day_41__foo.mdwn
@@ -0,0 +1,46 @@
+I made the MountWatcher only use dbus if it sees a client connected to dbus
+that it knows will send mount events, or if it can start up such a client
+via dbus. (Fancy!) Otherwise it falls back to polling. This should be enough
+to support users who manually mount things -- if they have gvfs
+installed, it'll be used to detect their manual mounts, even when a desktop
+is not running, and if they don't have gvfs, they get polling.
+
+Also, I got the MountWatcher to work with KDE. Found a dbus event that's
+emitted when KDE mounts a drive, and this is also used. If anyone with
+some other desktop environment wants me to add support for it, and it uses
+dbus, it should be easy: Run `dbus-monitor`, plug in a drive, get
+it mounted, and send me a transcript.
+
+Of course, it'd also be nice to support anything similar on OSX that can
+provide mount event notifications. Not a priority though, since the polling
+code will work.
+
+---
+
+Some OS X fixes today..
+
+* Jimmy pointed out that my `getmntent` code broke the build on OSX again.
+  Sorry about that.. I keep thinking Unix portability nightmares are a 80's
+  thing, not a 2010's thing. Anyway, adapted a lot of hackish C code
+  to emulate `getmntent` on BSD systems, and it seems to work. (I actually
+  think the BSD interface to this is saner than Linux's, but I'd rather have
+  either one than both, sigh..)
+* Kqueue was blocking all the threads on OSX. This is fixed, and the
+  assistant seems to be working on OSX again.
+
+----
+
+I put together a preliminary page thanking everyone who contributed to the
+git-annex Kickstarter. [[/assistant/thanks]] The wall-o-names is scary crazy humbling.
+
+----
+
+Improved `--debug` mode for the assistant, now every thread says whenever
+it's doing anything interesting, and also there are timestamps.
+
+----
+
+Had been meaning to get on with syncing to drives when they're mounted, but
+got sidetracked with the above. Maybe tomorrow. I did think through it
+in some detail as I was waking up this morning, and think I have a pretty
+good handle on it.
diff --git a/doc/design/assistant/blog/day_41__foo/comment_1_ace21fa257a4c2fd412b6ff2944a23e8._comment b/doc/design/assistant/blog/day_41__foo/comment_1_ace21fa257a4c2fd412b6ff2944a23e8._comment
new file mode 100644
index 0000000000..e27f7904ed
--- /dev/null
+++ b/doc/design/assistant/blog/day_41__foo/comment_1_ace21fa257a4c2fd412b6ff2944a23e8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnYD2ZzaOz-0anQDrN-Hg8Tvh5_C7wtStk"
+ nickname="roucaries"
+ subject="Portability"
+ date="2012-07-21T20:31:32Z"
+ content="""
+For portability why not using gnulib ? It will ease porting to windows BTW.
+
+Bastien
+"""]]
diff --git a/doc/design/assistant/blog/day_42__the_answer.mdwn b/doc/design/assistant/blog/day_42__the_answer.mdwn
new file mode 100644
index 0000000000..fd7c4ebb5a
--- /dev/null
+++ b/doc/design/assistant/blog/day_42__the_answer.mdwn
@@ -0,0 +1,27 @@
+Made the MountWatcher update state for remotes located in a drive that
+gets mounted. This was tricky code. First I had to make remotes declare
+when they're located in a local directory. Then it has to rescan git
+configs of git remotes (because the git repo mounted at a mount point may
+change), and update all the state that a newly available remote can affect.
+
+And it works: I plug in a drive containing one of my git remotes, and the
+assistant automatically notices it and syncs the git repositories.
+
+---
+
+But, data isn't transferred yet. When a disconnected remote becomes
+connected, keys should be transferred in both directions to get back into
+sync.
+
+To that end, added Yet Another Thread; the TransferScanner thread
+will scan newly available remotes to find keys, and queue low priority
+transfers to get them fully in sync.
+
+(Later, this will probably also be used for network remotes that become
+available when moving between networks. I think network-manager sends
+dbus events it could use..)
+
+This new thread is missing a crucial peice, it doesn't yet have a way to
+find the keys that need to be transferred. Doing that efficiently (without
+scanning the whole git working copy) is Hard. I'm considering design
+possibilities..
diff --git a/doc/design/assistant/blog/day_43__simple_scanner.mdwn b/doc/design/assistant/blog/day_43__simple_scanner.mdwn
new file mode 100644
index 0000000000..11ee3cca49
--- /dev/null
+++ b/doc/design/assistant/blog/day_43__simple_scanner.mdwn
@@ -0,0 +1,37 @@
+Milestone: I can run `git annex assistant`, plug in a USB drive, and it
+automatically transfers files to get the USB drive and current repo back in
+sync.
+
+I decided to implement the naive scan, to find files needing to be
+transferred. So it walks through `git ls-files` and checks each file
+in turn. I've deferred less expensive, more sophisticated approaches to later.
+
+I did some work on the TransferQueue, which now keeps track of the length
+of the queue, and can block attempts to add Transfers to it if it gets too
+long. This was a nice use of STM, which let me implement that without using
+any locking.
+
+[[!format haskell """
+atomically $ do
+        sz <- readTVar (queuesize q)
+        if sz <= wantsz
+                then enqueue schedule q t (stubInfo f remote)
+                else retry -- blocks until queuesize changes
+"""]]
+
+Anyway, the point was that, as the scan finds Transfers to do,
+it doesn't build up a really long TransferQueue, but instead is blocked
+from running further until some of the files get transferred. The resulting
+interleaving of the scan thread with transfer threads means that transfers
+start fairly quickly upon a USB drive being plugged in, and kind of hides
+the innefficiencies of the scanner, which will most of the time be
+swamped out by the IO bound large data transfers.
+
+---
+
+At this point, the assistant should do a good job of keeping repositories
+in sync, as long as they're all interconnected, or on removable media
+like USB drives. There's lots more work to be done to handle use cases
+where repositories are not well-connected, but since the assistant's
+[[syncing]] now covers at least a couple of use cases, I'm ready to move
+on to the next phase. [[Webapp]], here we come!
diff --git a/doc/design/assistant/blog/day_44__webapp_basics.mdwn b/doc/design/assistant/blog/day_44__webapp_basics.mdwn
new file mode 100644
index 0000000000..a8fdb131af
--- /dev/null
+++ b/doc/design/assistant/blog/day_44__webapp_basics.mdwn
@@ -0,0 +1,83 @@
+After an all-nighter, I have `git annex webapp` launching a WebApp!
+
+It doesn't do anything useful yet, just uses Yesod to display a couple of
+hyperlinked pages and a favicon, securely.
+
+The binary size grew rather alarmingly, BTW. :) Indeed, it's been growing
+for months..
+
+	-rwxr-xr-x 1 root root 9.4M Jul 21 16:59 git-annex-no-assistant-stripped
+	-rwxr-xr-x 1 joey joey  12M Jul 25 20:54 git-annex-no-webapp-stripped
+	-rwxr-xr-x 1 joey joey  17M Jul 25 20:52 git-annex-with-webapp-stripped
+
+----
+
+Along the way, some Not Invented Here occurred:
+
+I didn't use the yesod scaffolded site, because it's a lot of what
+seems mostly to be cruft in this use case. And because I don't like
+code generated from templates that people are then expected to edit. Ugh.
+That's my least favorite part of Yesod. This added some pain, since
+I had to do everything the hard way.
+
+I didn't use [wai-handler-launch](http://hackage.haskell.org/package/wai-handler-launch)
+because:
+
+  * It seems broken on IPv6 capable machines (it always opens
+    `http://127.0.0.1:port/` even though it apparently doesn't always
+    listen there.. I think it was listening on my machine's ipv6 address
+    instead. I know, I know; I should file a bug about this..)
+  * It always uses port 4587, which is **insane**. What if you have two
+    webapps?
+  * It requires javascript in the web browser, which
+    is used to ping the server, and shut it down when the web browser closes
+    (which behavior is wrong for git-annex anyway, since the daemon should
+    stay running across browser closes).
+  * It opens the webapp on web server startup, which is wrong for git-annex; 
+    instead the command `git annex webapp` will open the webapp,
+    after `git annex assistant` started the web server.
+
+Instead, I rolled my own WAI webapp laucher, that binds to any free port
+on localhost, It does use `xdg-open` to launch the web browser, 
+like wai-handler-launch (or just `open` on OS X).
+
+Also, I wrote my own WAI logger, which logs using System.Log.Logger,
+instead of to stdout, like `runDebug` does.
+
+----
+
+The webapp only listens for connections from localhost, but that's
+not sufficient "security". Instead, I added a secret token to
+every url in the webapp, that only `git annex webapp` knows about.
+
+But, if that token is passed to `xdg-open` on its command line,
+it will be briefly visible to local attackers in the parameters of
+`xdg-open`.. And if the web browser's not already running, it'll run
+with it as a parameter, and be *very* visible.
+
+So instead, I used a nasty hack. On startup, the assistant
+will create a html file, readably only by the user, that redirects
+the user to the real site url. Then `git annex webapp` will run
+xdg-open on that file.
+
+----
+
+Making Yesod check the `auth=` parameter (to verify that the secret token
+is right) is when using Yesod started to pay off. Yesod has a simple
+`isAuthorized` method that can be overridden to do your own authentication
+like this.
+
+But Yesod really started to shine when I went to add the `auth=` parameter
+to every url in the webapp. There's a `joinPath` method can can be used
+to override the default url builder. And every type-safe url in the
+application goes through there, so it's perfect for this.
+
+I just had to be careful to make it not add `auth=` to the url for the
+favicon, which is included in the "Permission Denied" error page. That'd be
+an amusing security hole..
+
+----
+
+Next up: Doing some AJAX to get a dynamic view of the state of the daemon,
+including currently running transfers, in the webapp. AKA stuff I've never
+done before, and that, unlike all this heavy Haskell Yesod, scares me. :)
diff --git a/doc/design/assistant/blog/day_44__webapp_basics/comment_1_d5fb67f373038e9f583cb2e1992bef67._comment b/doc/design/assistant/blog/day_44__webapp_basics/comment_1_d5fb67f373038e9f583cb2e1992bef67._comment
new file mode 100644
index 0000000000..bc1f259e85
--- /dev/null
+++ b/doc/design/assistant/blog/day_44__webapp_basics/comment_1_d5fb67f373038e9f583cb2e1992bef67._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://jasonwoof.com/"
+ nickname="JasonWoof"
+ subject="Your security solution is fine"
+ date="2012-07-27T06:37:03Z"
+ content="""
+I think making the html file redirect is just fine. desktopcouch does something like this. They talk about it being there to help you find the port number, but it contains the security token too.
+
+They also have some javascript to delay the redirect for a while so you can bookmark the redirect file. You can click to set a cookie to skip the delay in future.
+
+It's been a while since I used desktopcouch, but I found an old redirect file laying around. Here it is:
+
+http://jasonwoof.com/downloads/desktopcouch-redirect.txt
+
+The code is pretty short, you might find something useful there.
+
+      - Jason
+"""]]
diff --git a/doc/design/assistant/blog/day_45__long_polling.mdwn b/doc/design/assistant/blog/day_45__long_polling.mdwn
new file mode 100644
index 0000000000..380c55c127
--- /dev/null
+++ b/doc/design/assistant/blog/day_45__long_polling.mdwn
@@ -0,0 +1,66 @@
+The webapp now displays actual progress bars, for the actual transfers
+that the assistant is making! And it's seriously shiny.
+
+[[!img full.png]]
+
+Yes, I used Bootstrap. I can see why so many people are using it,
+that the common complaint is everything looks the same. I spent a few hours
+mocking up the transfer display part of the WebApp using Bootstrap, and
+arrived at something that doesn't entirely suck remarkably quickly.
+
+The really sweet thing about Bootstrap is that when I resized my browser to
+the shape of a cell phone, it magically redrew the WebApp like so:
+
+[[!img phone.png]]
+
+---
+
+To update the display, the WebApp uses two techniques. On noscript
+browsers, it just uses a meta refresh, which is about the best I can do. I
+welcome feedback; it might be better to just have an "Update" button in
+this case.
+
+With javascript enabled, it uses long polling, done over AJAX. There are
+some other options I considered, including websockets, and server-sent
+events. Websockets seem too new, and while there's a WAI module supporting
+server-sent events, and even an example of them in the Yesod book, the
+module is not packaged for Debian yet. Anyway, long polling is the most
+widely supported, so a good starting place. It seems to work fine too, I
+don't really anticipate needing the more sophisticated methods.
+
+(Incidentially, this's the first time I've ever written code that uses AJAX.)
+
+Currently the status display is rendered in html by the web server, and
+just updated into place by javascript. I like this approach since it
+keeps the javascript code to a minimum and the pure haskell code to a
+maximum. But who knows, I may have to switch to JSON that gets rendered by
+javascript, for some reason, later on.
+
+---
+
+I was very happy with Yesod when I managed to factor out a
+general purpose widget that adds long-polling and meta-refresh to any
+other widget. I was less happy with Yesod when I tried to include
+jquery on my static site and it kept serving up a truncated version of it.
+Eventually worked around what's seemingly a bug in the default WAI
+middleware, by disabling that middleware.
+
+----
+
+Also yesterday I realized there were about 30 comments stuck in moderation on
+this website. I thought I had a feed of those, but obviously I didn't. I've
+posted them all, and also read them all.
+
+----
+
+Next up is probably some cleanup of bugs and minor todos. Including
+figuring out why `watch` has started to segfault on OSX when it was
+working fine before.
+
+After that, I need to build a way to block the long polling request
+until the DaemonStatus and/or TransferQueue change from the version
+previously displayed by the WebApp. An interesting concurrency problem..
+
+Once I have that working, I can reduce the current 3 second delay between
+refreshes to a very short delay, and the WebApp will update in
+near-realtime as changes come in.
diff --git a/doc/design/assistant/blog/day_45__long_polling/comment_1_994bec0978324e268666073e8ff4f6ae._comment b/doc/design/assistant/blog/day_45__long_polling/comment_1_994bec0978324e268666073e8ff4f6ae._comment
new file mode 100644
index 0000000000..20d3a64e65
--- /dev/null
+++ b/doc/design/assistant/blog/day_45__long_polling/comment_1_994bec0978324e268666073e8ff4f6ae._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://jasonwoof.com/"
+ nickname="JasonWoof"
+ subject="auth token length"
+ date="2012-07-27T18:52:19Z"
+ content="""
+Your auth token looks a little short. Aren't you worried about people brute-forcing it? ;)
+"""]]
diff --git a/doc/design/assistant/blog/day_45__long_polling/comment_2_dfa164c86290899139491acccddd8b2b._comment b/doc/design/assistant/blog/day_45__long_polling/comment_2_dfa164c86290899139491acccddd8b2b._comment
new file mode 100644
index 0000000000..836fe89e9a
--- /dev/null
+++ b/doc/design/assistant/blog/day_45__long_polling/comment_2_dfa164c86290899139491acccddd8b2b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.20"
+ subject="comment 2"
+ date="2012-07-27T18:55:51Z"
+ content="""
+Heh, I consider it overflowing most address fields a bonus, as you don't have to worry when making screenshots. :)
+
+Of course, it changes each app run too..
+"""]]
diff --git a/doc/design/assistant/blog/day_45__long_polling/comment_3_5526c9dd4fd87da56cb8456083169f55._comment b/doc/design/assistant/blog/day_45__long_polling/comment_3_5526c9dd4fd87da56cb8456083169f55._comment
new file mode 100644
index 0000000000..7881bcda56
--- /dev/null
+++ b/doc/design/assistant/blog/day_45__long_polling/comment_3_5526c9dd4fd87da56cb8456083169f55._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmz8d2M0lQDYWLSbDQSjYRHfrQkWKgPu60"
+ nickname="Alex"
+ subject="long polling in Widget form"
+ date="2014-01-16T00:08:12Z"
+ content="""
+I've been hacking around for a couple days trying to get long polling into a Yesod web app, but I haven't found a composable solution yet. It seems like a thing worthy of generalization. Can you perhaps point me to source in git-annex that would help me take a shot at building a long polling library?
+"""]]
diff --git a/doc/design/assistant/blog/day_45__long_polling/comment_4_91630f5bf162dfd4fbb3920f1318535b._comment b/doc/design/assistant/blog/day_45__long_polling/comment_4_91630f5bf162dfd4fbb3920f1318535b._comment
new file mode 100644
index 0000000000..53b9f40983
--- /dev/null
+++ b/doc/design/assistant/blog/day_45__long_polling/comment_4_91630f5bf162dfd4fbb3920f1318535b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.43"
+ subject="comment 4"
+ date="2014-01-16T03:03:48Z"
+ content="""
+Alex, the long polling is done almost entirely on the javascript side; the yesod handler only needs to block until the next change it wants to display. So I doubt any of what I have would make a useful library. (Although it would be very useful to have a library!)
+"""]]
diff --git a/doc/design/assistant/blog/day_45__long_polling/comment_5_b3e41ba77f21e93a4e086483793bf5ce._comment b/doc/design/assistant/blog/day_45__long_polling/comment_5_b3e41ba77f21e93a4e086483793bf5ce._comment
new file mode 100644
index 0000000000..d9886216c9
--- /dev/null
+++ b/doc/design/assistant/blog/day_45__long_polling/comment_5_b3e41ba77f21e93a4e086483793bf5ce._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmz8d2M0lQDYWLSbDQSjYRHfrQkWKgPu60"
+ nickname="Alex"
+ subject="re: long polling"
+ date="2014-01-17T20:27:23Z"
+ content="""
+After poking through git-annex, I had the same realization. I hadn't realized that Yesod (or perhaps more accurately, Warp) is asynchronous above the Application level. I had feared I'd need to write some WAI middleware to accommodate the blocking nature of long polling requests. In retrospect it seems kind of silly: what kind of high-performance webserver doesn't handle requests concurrently?
+
+I do still think there's a pattern worth encapsulating, even if it won't be long until WebSockets and SSE are widespread enough to be developed against without fallbacks.
+"""]]
diff --git a/doc/design/assistant/blog/day_45__long_polling/full.png b/doc/design/assistant/blog/day_45__long_polling/full.png
new file mode 100644
index 0000000000000000000000000000000000000000..3963ae1dcb26d2590c08ab036d9ec68fe266bbe0
GIT binary patch
literal 55185
zcmYg%1z1yW-1cZCML{|Qm6Glj>6Y#ikZwjdQc^1Ah@nV#cL~CP0i(McM%U<l)BpQk
z?>8=XYR@^(Ip-JmbN}uq=DnIc0WKvj001CRRFKgG05DOj==zV)Q40@u3{TVo(?&{F
z3IM1|#JjV=LT#gYXv)6>ln+zyqBiI)6*N@=0KeA&K*%Qm;0CoTWCs8MasdE)<^X`m
zcL0FQHM3bm40QnegR;B~0QvXtM_WM>YR_X=1p^P%QsLjfT)%?^syRSWMoQafZhz6+
zSmy$Xb3EOY(MD{LBh(q1o5S2Fzr|cP5owrjU@*%?Ri9=cK;2R8VwVR>*-{!xiNPRC
zXC|a3BgT{xAUhO+BOnp*2!BrF$ehz4iGYcw>|5b%;BZrb#CE{2u*&iYEJq-R{!tG7
zX)7~s4)YXcHlI3vH&@)JuS%~_Ukd5XLZ6<zd-UQDw!sjMp9YDn)QT{p!-R)ic&A%f
zryvm2@1(@=RmqA6^o~WZFqa35@hcbp_(TN5zg9YZ_78?6m{Wy<w)}0s7_obLWV{nx
zHCZy62R8(C$|qmFD%hX%KHs?Z%&W;T{`nzyET4nq#owkyVKKow6#mOGVVzajfd;!*
z#P?typSaF5bX7D4{wJz>ai5NKADY;>4L0{UlGyAxp8Rdr=aiSv1_<k{!8UR9jAEjt
z?LHHOxp@)+ic*+AYcVAZ5A=&>yO}VgDB1zuK0>u{7p<BXeufpgtsh<<@ZK18elf^n
zboI92wMUT_YyL76o||Hj&tW4IJ^y<3LU5)Ho&J%S!wAGHerJ)<@QIH`>u5Zl%e;ma
z7Pi<+bn}pU5>{aqK^*1Wks4Pooa84j8FJ%{bJ{)Yi%JxoX(BDGcnkt6{GSribR?U+
zOz9sYLlgQH%D>msydXcUkgEwY&VR4CqlEtVatfA};(#ZzsLm}FQt_8|?0$Hg;(;^-
zYbd^u4b30v8HxaUPyO(`PXz*c<NZcdS2?0`jkWgIw;;z)ZFh^Lh6ua4+?yP2JHSP3
zf~QI;GOX6*j{#FZ4o2DMX8UJPay|V_f}}M3<RVqdzp?CKd!pX+r!SG!sEcBTS`rXD
zh55^PZwZ&*4AN=fqP3Dd6@)ofvfQP7kP9v<6Adxx;#aRKjIGT|%U~i>z<Qgz-N`44
z->r~0X1dtyxKPDeAj6r$ma7@V{5hWtYbRa~lJrf<njOQ?$JZ}YMYx+gPNm#-Z-Dsk
zRTpL*)k~iEB=GJ);>q9OhQ${lHKRo^m`*pjz|10uGc&lJBNE=(lZ-*8rHfkI?wHDE
z7SSVQWID|m29!Jm8!t<-6u|g&u{?d#eyz)ompyKvijiSR8Hgl`-o*C{-8T1A{jP1Q
zuWel5iK(&SWBT*GXWV`#1%avw`@h>31;?`ia_EoW;Dy2$8Rxb<BxkGLn_80MLV2yK
zOliV<Z#K?e-6l{2Mk@4LD<&8**)!?Ca%;-5SSv$a?6EFi@54oZWN*UrWqx-m*p~MV
z<xErI;^ARn7^O>>n?O%4FEv?9YK6PGG>dY*5rs#3$ex-~m3;G;PeH~S@AY@q*G;BX
zurxf~yqs6JlgzYP^@`J*3I5vXyF+t<a=;^WSWP6@gz?o=ITA;Fz(zaAd!^ivmQbRw
zm%Tdz3hVszFzdHqD1E$M+$j5_r`{NxSU-~c0!`jb2kzFnRBV%~e!sIQpj9t7J>v|S
zk+>%;ySJ5teW#`Q<<-hN`u=LU0MRQayHw+9Y!=$)Y{*ux-XXp$hWyh>5$LBnf4tDf
zU}mqz^}^yP<l$b$?ehNkG_Kup9cRdPPq!_D^!anJu)n~?9o9HRIc=f<mdV1wQI)`w
zqC|@8YvscXqg3Jik~*-_^Xe5fWRlTLiX=P?UHDgd5mm_F;Ic8S8wj9JKSc6V($acl
zGk+GyzAdtRuUQ_U@g+vdn5D7WnKQ#xV0eYb=J?~YVN-(!GCf?YoTqX>bB#+Zi%VOM
z&p;1BrVc^Ah`}m4x-70flB*@c>z3QZfZ(ecWh3Q$@l)XbUfZoYo!QZx_o8~q5F3XO
zUH$&@5rW3_A>4CjuVPy-S$E_>)U(`dnKnN$8%$_W>wW+5iBxs5*t@2)Gxf!b7a$NQ
zZG2o6Iag2MGTOB)^7`+~bR0ZJD;=djCiVWNkayaZlXGLup4NYNe`m|^FC-~Q>#L$Y
zl?7YsxGP3^l{qauIDAI$BXL)-=5p`R^SIo<lAo~Mq$UbUQKS&GIU3=DJxBY}Zxtua
zN$7J1()g{USgA=&Mm1Znl@=<Y1W3a17WUh_x*8Cw5aW^Q1$34q65P8VmO@OiLU`q$
z-HRelwR9G2j&CfbvtGtwP<+FV*%>h{(l&0+#ePCTOiWE}#Y@@E#RKB2HgRZ@*$~!!
ztrupI>n>{{^|K?}O#GBohP%@Gt?7e-AN7CzZ_}asYkU+0(zl*b%ya%n6(r`lJW?yK
zcw%f+ri-Lp6z=Xk$v95MTu6N6iabwT&{!~{m70uUlMl3o^oY+7nX&IEH+~iyr|!fF
zZhgkQ6#_kf7m!)L<)8|E{P-4!aNi-}*^XjOw@Y0*9gOoUDhMhfI1UoC+8Fdi6kk0p
zQYmL)o3yVR9tQf57lM@X+&w%-Yf80WyX+M|`xiUD7N0N4Xlw{4@KVYV?lMK^m~WrA
zX<{-)$EgfJD_67GEAA^_LiNut+J`FcPwwN8xBGDR;OD~1Lc#+CA}lMcWlK_4-)}N=
zIft9|tG)z|_B5;|*IZ)*+}TW;bK5-?X()(Ci!33$HZaq+bZgH1-8^&Y+a7nh@awQ|
zDnDCOlZ-k_u{0c4k04b*pD)b+Qbm=OIDku}#A>xnT2?CL{#sOwjokMIFQ?$DkLHee
zR*ETmE_>iQB>wQMGdf`Od%^VSm*UJ!3Sw#_abhOK^UWqExZwy8Y4no39JjYrvK>Sh
zyo?EWrKdG+uw3r6#|!#2F<<8(obQYL{aY$Dl%0{0VK^^;YnyB)&e8A1+m@-HxD-Ca
zwzL2e5)yL!i~T?Tetw_D*hKi6;{LkaCv80-pwmOlfts33tNV@)AV!p;)LZRn;cRN>
z{IE_WZfN{v{g*33qY>ugs^s%_r>>R_9}|$5X9#M&xqh%1m+*7H%)W1yak@M3hTySM
z-CL-1B>rkq72D#yElZ=r{!-~pm-Wzb(c0FQ)9h(S^ZertIW@JXx@T=mOGew((-@i8
zNxd?%r==PjY+IiFBx=*{?t6NG$K5{uzK^NrC)lO_#y)rXW;db`=FeiVD(rjdUr~=y
zSj7ugxfd^IV-r!Lw7a?XV)C^5sfmNlay>#4Jt3T)y)9E`ZS-B26l=K33$n7U+d&E{
z37dVtGe|cM0+dF^e%IA{x5N01F3>9HdVPX?Sv@hp2Bg*nZVN9MtO5}>`6eq_*V#N=
z-P}w(S@tA0A3T1*Nyyd_YErOrkF?lO(lHJC*^s73z=-27(>Xm|ppeCp*MR=d5+@e_
z<q+4>-}8&J%P@Ho%+5o=+s#rg@qY1I>-X@^m6T;<E|fE3_)!+O#khcF5yxv*!`EK{
zuI}HagYaAfN&mD?H+XAn3DOru><WYcf+h8sgdvnNKR+aXVM!*Nv@ffdfL$PtkDp*A
zd_?<~IVYrhNC6roz6qQ7H&sLgQMP{fX^TrKnC7`Fz8b~J1nu5e+3=}Bv(t+U_%xQ3
ztA_^_pOvd^OTD@4y<dBFN5!AfZxgcv1@nSHIB^sgK4TIT8-kdrW{S}h;(q!V6)Kv-
zp7ro<4@Y2P`TF@4YXg0%3)Bk8;QoTb|3C^a<d5VzJ|J|PpqWQfujiYu3-bm~LdouH
z=*kyDr95q$m1HGQ-w&07TX;o$=!@TPpmM;y{Uf*w7rAwu%+D{}3<Cq_O~Q7nCaPn9
zgc8`^u!2O9R0M1qB27xUq!rFw;$ErS`Wh=V>hWI{ta0;<rPKpo{ey_S6s)h2<nhg?
z<>I2n$)D5xk%01#;ELyC1x9+~Vdcz7C5<30z0V6?FQ3L_WGLTGy@*mX{W3t}F4wQ{
z67ceA(L0@NGW37m@a5(!U`79zhThbR(#`M0(wIN<=Yt;?(M4L2xL<!?#R$I_k8kEl
z;O7Iz{7cE{EFg`FNfJ|{)3bn;r3WeYd*6hz)l0K?dr=nTF)~k=L^j$(tAZWpbhMMV
z_jc$12N2sOd{1ygT<k4;Jnbf`cNqV?Eezh?U1i;P&3#~K12Z$Mahs1hqfj-W{)b7n
zqMJNdRZxNdUmu^i$1b!Mcs~7m=*c^0Q9c0u-^cJGm*Oiw5G`7ok8&txT|T{;<lkQJ
z8vkYlDpWe`X)bv30UCKTg@QJ~hi(6N{23(ioQf;ANZD<C6tJT9bTPgc@UN+$GB3zg
z3ISN~%wZ-WA;rxZnZWuN(_ZA7VuWbMM{fSn>9}{c!Yb4CPEvaPSwYNG!RE;&je_I3
z;4@obGaL)cplQ0?%DR|$tisBAi}d-<Icn$t6j|)yyU06-ZW=mu^R5YTuro@Rzt6Ka
zUKP50T}S%g6$p#Z06!XYWqx`pN`Owcs9cT~>Xccv7IMEGsH?OhA8^LU#$Kxh>=%%-
z`TlgnMiU8tuve>>VU68$SI?e#2*+L!bv%x4cMG43lqc6e{E%*#<<{hK*Vz|6tXIuL
z^*wFLyzx7Dsz(0EKga)kZ<Og`>{XU&a8i2gf6rKc;(#_J=i5^zrUqV{;RHI#pv7iM
zn?awg?nKG&4}X#~G^%OEKOhbl{g(p~PV@B#S>8**NB0c{s#&ZlTm*`|9fj|$zR!RI
zNpT}aZAak1{F+nurmpVpb?^=?HRNCsSrHpsGHT1r!C|LhN*VupeXj0jcq9wSz}VOa
zK|zFt^x=G!hmr03FHupqL$=)i>_9YY)K<*%yhF3hRMR)zkYr^m*V8*SHF@Lr!ZQ-t
zChesn2TpZ$nBn-{vbuwMRvY<b)#A7oL=brIj0YqKkfbCRYM0v#X9gbs#+fcR;q}^Y
z+=Qlyi=3=xXjfz0KBEn?8Z!%aq7-(YNT3mw@IkIOECpHip6~M5i60p;v$D8(dBGQ0
z25k9A$jJJwG-G6n-!oH0qK23S<B!pgHZ~TR>MK}+q(AO&kdlz3JYN=ceA)f>7t2>A
zYf9Cal9Ks8VuZ_lyN=BW)>VV;pZYQQMHCU8nwlC12Zum}kDs5Myga10w^+MaZZP`q
zd)UYq@x2+uDVXnHXvG3!(0^We!Eb*`*5L2)wuH@`A|$*|%Id|o*S`PO(rv+Xruj!*
zXM4l?j3{q=Lod|2!u$2}-%p8XB~si|*M$IK^nKRVGc(_v5uQ#9Q;h+_fd|=e<Si%2
zf}D=-s6B99F1{7k(~}q4FER(>VCB$YH5mqr+Z^6k=r`qfA1#%hd|brfvO4|&lgJjd
z9a&*Fs>i1iaD*h#WCw@^?;_i`uWlApjmjtOFK&jjay&)KOe^$QQ_^{c`ja>QNZ&qO
zdvAkkSYGA5!i~_Zn5K&N18<|bzR~OWW@BYCNkxDlq<Hb@odHPh=leYZzle7Ry7|PI
zK^xJd)`nR(r<=X@h3Dtz5qM+|w?`es#Khu$=Q}f1>)*L885kG{=_FcRSG!O@$f)-H
zFEE5vpSmY}rM&Q)GUrNv*acE2AF842iwj}s2lhysx=f@@rmqy$km)GtMAet+C~f9J
z39?q4P7iOhsYNn3wzjrbS62@Ymx^^th#BQ6<L(A@I{2L(FtM;AK7GRe_syJAyx8(g
z;>IV)*Vh*#31|y=uWg*8-IOV+mxoyX<?o$3>FeXe=Pd4$tkNZR{pZ=4#J%mv52-Eg
z&Vn<E+mE}Nsq66MWaiI$)#bgHalDlAZyb{Qa}^<pFKI;Ir17vDUESW^6my!*UBfP=
z<p~vEK1Csq9)N!NFa|*Ci6*CsC-7{4*}L+$`3SrYH-hKlZnmS|Q7pqx?sb~OfKr{v
z!N~7!lZAzE>IIM9Nz)M|gTW7HFiBBSQ3wRm(%g)VgCj31i-m(jL?;o@8%F^KgC&u7
zyzyxNFh{``t~iYX{ym^v)^OoCrKe$=8pIB25RO)=W(8y@!6=E)fTryTS6%k6+Gveq
zMO#K9h-Ik7gX&jbiKV#DEiRgn$d>75piY{S0^A+TLnYo4ZB{zEj?ByjIY)vNC1H;(
z-lKMevu(+Hl-vIJ@#EC};F6|=^1I`KRtRovY>HA^&GxYP`HD1Y8<JEKWrA6jK#8TL
zcztOH&BtdGwRUvDcdJG&Z8g4UTN=OQ4i=g$9}4hHv(5%ex3iO=xrF&z<>NQkS5T{J
zR9K042MXAe3^$z?&iRE(MQ3D3E#9>SQA_~vwrX3j)RRULLV$j%cvkvco`?3W7qOue
z1>}SWw0}G*jfFMskBAn|@+&VaEVM}ki#Sm@@SPu$2H)%#Nh``*9`5G9pE#4VZ!<-r
zj8k6b?*|nlJg9Bbk1f;jw+{|zXlMe@cSe_kk@tCNrqy7)T+O1-v9VM_@_m_)y170C
zW=|#GS*V=PN4+R&mwMKIf1@3fYn<$<YmY6-Ga<}{{Z?aO*{D8i$Rey+)aKIvR0E_{
zIrM#Vv$^7VMY)2)2wv;fP*Vk)Rou`dnz0a&k6&Jrp?&>pb{gH-l@Q)F5y8R!vZZzw
z>$e)jZAg%Ms09F(Mo^tawuiHwHjh1HYZujjIU4&}!t`baLYFEWHHVM+#lsPjjWp#*
ziEO`Hc+ZrwAX3+rWYpj&nKkqYGY0hQ5WYsr-*q=Ri;*#X_~5cPQS|fYPk_v*tKAuq
z=<p7{>)!Z48RAzWhCT}V1`%V(5t{e?0Jr%As~Xs;H_WwW=B)&vmM!<}hH`l%r6pdg
zu#_lHYh!`q@qAT0Lc)4e=tuuK$2_@GpDZs@c)Ts|h`#$tcJ@>@cciE8M?%oemj&?!
zQ}eRPhL1HAPS{hGY*Q&fwpr1)jvo!-a(64?L`(ih;xluTP9G<Z7bmy8ytzh97oD6x
zH~{UNBVF&jyZta`*{re>Aoh@mizVkXTl+T&N1q9<Ep1#Hsz5E_p_i1)->$z@f%1pw
zFf-(%tod=o5$VE#;c844zEV$Q-ae64`w}u4D~F*^BNRz&@YM!-(K<~3Ie<Md@vdua
ze<AF0^`|M=+2S|*a0%}zUTk2SI90V<gVXY>G`80&-$y!vkq*=4Lm*z8>(fnu#KYBk
zV`Jk+Qb8mRzEdfU;*(D~T>-&n6%g7$&y%%RtSJK!$oAW{RUAmXokDdTK0u`n=}}aa
z+J<yqY(B|c8XrG9q7n6j^fJ9Z>~Oi_Dw65K>)I*{MkK^5i`60@zA{>CMv3fLTU)c*
zG^BKtem|eFYHJ@{oGjD+^_49%$na!+0+P)~Sql@ppNOJsLtGjifevwInmiz3u#N!h
zOJ&XuA?R=Jw;CF5RuB#`nBvQ^yRf@Vhv^&<AWyIZALRgaKqiz-_Af(9A|pj28)^x6
zB?>|1Z7&|*<IbNb+RL6V4<94)cln|y#R{0igd%eH`6U15;4BStpL{0x$8X!dHt-@#
zb!<z??ecuXWnyfJ8K;=AFhwUS(xcMyN8JAY{;&O3DA0k`=|&B4qY?GuTcmwLMKvFC
zzp=G<vikVmSmPs5m^EOo6itaGgoY(euiOAJsLUOi<FM=~CVst{X4Eu*R7EA#t%|Bd
zSS`hPPtR_aU;$`MxZdS<7M}C2cgBe3t-Zay%+c*<AEN30iq^f?l4d_lE{DPdTb7|*
zguob;hcwrNtoEEwMQ3Gu)?pqG_b`~_?i=f4=y2}cg(yTN-I@1E=W@TEoVwo+9dqRj
z#Tc>M4pm6+U;zKv^ydCW^-=rnX}p>=MG<w#3*;I&wzZ(A@qQ(>j%kKNy?qI0(3QLE
zVyy4K*UycHhQ{v_E4NJG=*;84S=C={{Zz1`y4>(^BnCqc`nmm9(%)g$sv;%*(}i3u
zMWfe6{tt_!El+$UArIi<kpmt0q`Ixsu*7BPBd;M2%1Z=rGjO8YRA`o?r&^ka;wal&
z1pF2coYt@fOr!^PuZ|)wu&edtA%b}qZW>N54ZeK*sUin|-D2D45I~JzJAIX)H@;PY
zS(=bwKiT^AjrqtfIRz(fEB(7CzaQgs?qK~QEKOY{*D!~AzH<Zp;E$%(3Iw={UGED@
z-VJ|$c+UI2FNKvXt?#l7AXD!Ge8Ik+mDs^wjU5f3|Geg*F1{e%Y?)PGp_KQ*pj@X!
z7hr5`tbzwXM@Qdqzg}fj>^^e(gw}Z&jM&)ROr+)S>gnk*A0Z>%ta$_9*g(ZqC1qu*
z?>?#+A#2~BMl4(}G<gt-^DQmhc5H+FeU?_>2W{5335tno!mcZwmWiqc*HCq$ILanp
z=oE_<Sj^{mWj!hTZnwaiNLYXmHT-%_D|S8_br$q+T`)6a3fRCc=#EN!bG2WB0*@Da
zlUlD+1_QQ0L=pjrMQ@3j*6WI|jPj^dbXLMi)_%T*S7YX@$Wd|6ASb1P8ZbAE+9oUI
zf%JG$)EIdzhoQ{v<-E7^WO53q87UZv1{BT?ydFsLk6PG<!;K6L8B&xku)FIIjP3&i
z=jw}u(7L%)w71pBI85dm?beU|qm=W;;s(!Getc;^xmN=#9g=EgA8Nb1yL)=pD&_H*
zmA)_1&Jy)b?Y9C5C7hj~zhPrLLm(=A0j}2TaF|%zp3t~|HME0n-(Zzeg!1iS=(UTA
zab*PE9AOb#M{vo({d!0IQT3I3%Tvo)HVY;*r5QHwn8MWIRbR`3!0!HmL}b%>j921d
z4XC=)6!}r%+@@&My$P}LWrB!^CPT<6o<6$$U<>10DX&Lnik!j*{x86joKo_Yx@W^C
zo(=@`j1_|rSY1j9_1lViQ?pVSRoQf(w(}G>do=PsZDISNh`*Er7aOR%TWBu%7()^e
zQnB^M7(<nb^;>GNf8z|Klgi(J>yH|0&~dwWaU&c1yzSuz4#1SU+DKAg^4-p=%NPb+
zIi8?}_+B(g0Ll-Mf#Vud9|plfd$dO!;SMv&v>er|9Hjp4*<6ze(5L>PB}lOpU)3|X
z3zH$HamJ;7!)XbQcbTxel<g$0o?IM!bt<1T*L{@#W#4yPPofX780QyX2GF7zTI}vG
ziJyU&PN7H@J6y->rDuBurl6fS7JyofNxsbb*{)3r9IrCfR{Br=j4liJ_pPFy)y`~M
zgSEjyvwj1z{iYO>)xY$%{hjKIhg3f%0(;nvKJI-Y6eyXRmNsC|vOlmhVf8PwGVz8#
z$sqOSOTS31t0Q*8P9-x@XM0W;gO5H^VR_6H?AH7ZU23HaLvVkfxLQ=WUaBl()ayr<
z$>`U7kK7bTT6zKAx&~rAt$O4&Lim@Mr{{Tm#%!rKaGqk)+8cP+=*l(n@vEb=Hxm&Z
zJh1;H-{X#}fx`CIySrFSK=8}ZJCPtULpriaLaz+@r0|rwDu~FXmSe>o0n$=0u%QYO
z)minHh-_wI+liXTi>LaU&7#bZe`pn*Z4V#2vXve;j2@RkAG|87y8->3f+wd4Qe$R)
z77LZZV8bn+RG&5-8U}i~c>sX~_Pcl?7B2zKGWFc|i1Q{WKt==b1<2k}TDouV<!pij
zz(?^5)gOn_r%nA2V3NqzfNOVOUt!o;fm+t*xVU5mN;rSZH<an40NK(DX>1<+B%kBT
zmJCrqjLe6<U49u=ICMh|x&N@8M`mVPvz1t732~aOekF1PzH80AJeWh@c}C^E(iyti
z9py4p+3xK~9b(#cLoMdxdUd=CpRS0FKUg<^tXpb)(htclH)=Q>m8bK+%@WMcI+-}7
zOAEg4nTAi5W$@XZW=@;>`cC1wgU)9QvV%4!(}IjI&(isW<0$$4ZW9h_%mNSQ^N@(O
zGhT<GoKj=9r2e`&cNAFt3L1UIGj?i3<ei9i5=b?ZFzxPfe}B)Pt_f1nH8yUwp5Kc0
zIta(WD3Ntot}j!{Gi(T2JYMZyG+rDVo1_KPPM@8@)9lpLhEY4wzS}$$qN*u+dgBc!
z7%@F9C@I;YnjwHgNL`s0EdbX(&ovV)<Rq|NJ>PPPqN5h}k{{p?Txu%x?=Z~FywnmU
zQj<yjio>;^y#Zon39-Y|<Mi2%Z8BpoNu7wS6t=0pxyv$iMTSgm(}HYxH#-Cm=11ID
zCfhpD`vh<S5Bd@oi=XAsINL4eGW04;=j)y3!Q%euW5yl!_nUFhOfu2?6GgxRMwim*
zXZ#48<fSb4;eBG+s>;Se$<85>{Mier4W3Menv>x~<&Dlo#E;|4Et|o;ih|Oc`{NzE
zaaFX{L`f<}OMs(Dru*@7c;Hdn@<-)_;2+~S{lV=LY)b(f*=KS7&R%^z0gHRt?LqBO
zb3g~jZ5@5bkGan%Mmre<smgJE=sT=TkS_jH`6%H0XCd<bXas}E6YtTZm5T`I6xeU$
z+Q5=z%u&3<akMM#qqmLKa8iEH{qm{g;!HQC?8ycb9na*NcGt(WVQC}(rSC4OX=ZOc
z+}IWM>o-eB<uxT%Lcxaztf!03Yh-FG{#X6Y5(1`M69ZfIE4A0l5AMh9HfEITWh64T
zm{pPW%{z<R5qe#`bqfeQGMMwC>eiZ`bcvxePsV1Ifg3cnzb)0e!hTY}+`8sYz^K3Z
zP{63WdCi<$K8IVgXo%gRjo8U~_HK=blZb5m;f=-0=Aq_$&EB(C;1BByc&!x8Z@^Sb
z4x{R}x#fWIT`AF%43KF<9kGGxAtD1NaXD7{#AY`27a5?gY2z|T#gP_VcUTS-;n*Y5
zFH;a`@K=6i>0#zxxl6swwm(^AXgMe5<8Z}ZtgC>ND4zk5tqWfi2}8w)gsm&}6W}es
z(+Zs^T>Q@#9XbS~jB0u7MfXH&bBevZe4TwHg52rz*6u39sPVQnEd%T^IwlG?7JVBh
zA@RseTJ;0f)*8QICF2*-C<q^bRTy%Vy+gNl&-+T+WrUMRJ~n^KM&|<CE|9b}e7Mb)
zPU9_yZVc$Y2rXnJ&XHj_IXMAwTgq8j{8Y;GyIPG>O*BV)GGAh2@~pPV`)I~#-V0Ty
z4ZMAd=HufdBrJ^fM0RwxXLBGWPPc4N5?Gdx25=Z5+?PC#qH7Ocizz~3b>H(*$W*z>
zd^1o#Na|-rA|mup+p}KD8`MzhVt>{FnyR|qyAXW55-Lv%s`b0r`~LlVhk(oXtC8@8
zWb@P9e&vo^uYnCn$JN>yq(BVKeD9eS@(7tKcJgQ9Iy+D#a83)LpI~-6)UX`f;0Rwf
zl8+;A@;x&P$0i7Z9|$ge=Y@QILyk=i;f|9*ab7B~qY2tBrqUDByr=3M1@)%S*>)d4
zZt?eoAHvryc|Y2^Rx0H!+)d|8xVim&QO1!ed33O;16e3`K)E0a;JUh2HX&TTWoHxp
zC@syW+GsdXO`uqCc#FpbpcAKt^Qju8r?uT?TV~;0WX%j?gv3d)<&lI~?Cuzt(P{D0
z;Kki!mJ66#A1{4c0?5f+iRr&SmJ1(BHu|&Vy;_v$CAm<425mz>ynb33^s{vwV?A&~
zFmibPb^NnX_I?ASw6e_8E;#$brZ{cTDm?qLB?hU;xNe*YJB}OtsKP}WbLYJ#<JsVx
zpZ(Imq#!@vYi9(SxtmRexS)}&k2ULQeIsFaQ7>%}5tp61J%GN)W#I6(z#MQ8koCaz
znE}SDxobI2SK>x+($Nvz`m$sD`f9ii3%#>P86@X)UG5Sr7|7RE@uP2Lo!!y2*?A^8
z%@4ErrF9yz&U187xW>~L^w|F7+D?aKt};xfWHb|xS`erW*NTWl-fqE#Ipz8n@1rDz
z8C6)UWltK!Z8%Dek$vNw^Ny>rdvB0aWg`A;XbR*$3Lwh4;$UqDz>DGPAIDFCeri!_
zLHxDFo3Am<O=vSn5f>iib@p}6JaElfmA$bPhsnL5VO<A(J>w^s@;Na%<|a}$51%jO
zCblwb2sd7&tn^l7Vu}&55b5LS&SvdZOVPYIwMMxzkYk(rQB?z(0o~smUqkHiZmu5J
zEftNNoF*t>KK|SMHFs6u%c<s;solmxE%Q2t*@Z)X+BbEAS?m50Z6dnJ#Y!D8CD9CP
zgy*qOt*`Nf--?jF0o=A|oBE!m{AWJFou!@=ksaNtRhB3K2ZN%h1h{Ud)Zo@Pv*5(4
zS229EQ>d$YCeG$wv{B;FV)DvaF7z3e1_>qwlq_t~V6S<IX{0b}iJANy-DYFpVo;_e
z#(va9L?uN*uVTK=_x2%~ciYTo&%$P#Rnp9`EU2HTqrk@0+uPg!{I`FLm%UK|oghFd
zugi8Lfm-<V9<fYDLh>kVWqTWeVze5Z<}Xh-q4`mY0+|^l&~PI0M$215GBUDpgWxj?
zxhdPbwGvr%N&YgA?Pik}t`a-I%I2oQd+mufe*|5y;pLxo^@mgFXT_xaQj?a~Z{ED=
z_+h>gh`7JJEncc}GpcuN4L)ZE5G_dBPZpE5`9qxMY7c+AS<<`-mC{@4FzfJM4!-SY
z0$at46mE!>98FgoQMt6Ed>J3iTbX%R5)s?}U_Y8bGk<#l@9>3g{SL>5W!?5tRlqcu
zsnfyCX-Wig;o7XkvZIqdI=@C6g@oth?5t*!c?)W)YudzGo4pR!4)?aq+2`t<JT~5c
z_&B8l-Zn8d2}$qm)RbdL>3@287|vXa`*?Ts0DR*l#%pG_9334!UZ9S8FuJdknwp!_
zhx4N%B2rRPChx-H+#4Hzes~SS&*ZJ$j5DHG--=;?+S(xQ7mt|kNAae+bjE_~T{4k9
zNCT!#V__^^+{!Rp-p%jkX_nLKtsdpB%V|vLUS2aEuT*mic{KO-Gy^kuI-|=&>0Eg1
zp|!)#<<fIaL?H2}AsQa{<Lk%gCv{}cLON5yVo48wVxJAUIhJvlHhR__MMn*~;Tlxv
zf=N5feDydUe8Mug9TL*w6kC%0R#r5$P1X5`Wm_Okt*7be7{@ux7`hL~4(*eqA!Mdm
zENM^x_w~`{t<szXLP2sjei8D~94ox=5g{<x$~{F&*6U-wY2F_34m$no5$kLv;DO=E
zW}N%_MagnNJ^9<1pBpfp;3dJE_Ee`i9(>+hEj)n6(tu1bf=&39)8f4mTONP}pI4xM
za{5+TR)bF+RO4vD_)GieKt`EUeM$_v+*_=-kHd*SQ+_aX;ensdls3N7Q#Z@dk&bsv
z9r&m@1#BQhrRh*&n$NFsr$|-A3hS4mBPgkirkI3kTXP@f0OZg$nAupoE{<2Rev4FY
zu})NisNL9G`uy}fb9bp7RRB{s(L*XGZH6;5(eH&6SzoKClMR-lQZZdj!hZQRMH;mj
z#~!(Un?gCbeJZ1|QO0uH+^ukzdV$S;N#_mK_||VD<Ka1BbEk>Xuj?l=>GA6f)yh^w
z#MGswKt4$DXQ#u@TiN-McU2|zQ8NqaPh@d0Fv6Yo&jg4lGAOXH=V<{mck3SvR6Pd2
zb#)1BV!2m^koi19hv2<|u@a1ln^)KgRcUwaVd_FWL^L)&W#+)Ae1QiO0*!gg-jXhj
z-@Pt2o3exXT@qqzl6Fhn%MMeT@O(7JnsttO)#ENs%3<SgMCIf%m4w++lx$$&`@@!_
z=BB3m8+Zj7rzt)zF8UL?=@wc$!*yThnUUY+<>m7YM_iQnVz7+J=k84lJv|ZDvlZ>8
zVs>NQ;n;+Q@@sX2nx`kHPcbbK&f=-aM#sCW7&hHIzM#8L(6n)3Fw2`a)c(jFK=6^9
zB`w$D5nGZHlNcYz%fg=SXT4AwaOTG0;Z|<4IC5}&n6)XYMHGMvK7wSE`)Q`9t{z@)
zZufie2(#ci+uO^7laoL}mj{QDPAQkRi<`fGEHZVA^FzCkFI_WaRj6L8pl||@%t`JU
zrp3|2y@`l?2OoSgG(3`8+;8y2OPfW<q{TCpYY^iX#4GXeWVs&+FowaFA7JGvC3+QC
z7t`5#WplMa2WL~-kWcrwk<0#O%Z)-zOa)7Aek`Pfswp+kpFH`Jo^Ee=d2tb+kkIbA
ztLg538j68aZrX<1IXTHMAfQ_@J?$!Q=!v`~y!TM?cM=Sd?r1w$@N!i)YXD0h%_Cgw
z`>!Vf^pw7VbFx|f0kL7ODI}etk{w>TJ_1?-_6aw<5t1_3`42O^(yYdf9{}{;ms_=@
zutA>G!|ii2v`3CC1-z4LtwDYzgTilj_i#g|OVFaj4p$QR5B$%)zj0rFKvxh4?aww_
z;vuM7K40uz>v1+=*J~Ku>13Z&#x~gWl!l}0QtTC9eB%c24Ab&pu_oi1YM(X-0H!Ae
zFP{}HD4IL?@f{@>(E4u<8B9Ka{E$rb9Lmgu!G~WTPN@V7XYgBJFt-NIrF=UrWh7PA
z`-b^;b5XNkboUH~K4PLiYIn|B5z;6jzBL%=HbqtQv5gx#K7aO8kx14n=G^nEf0XBN
zhYvZxsF<V8bZ2i_X#?uBt^;@y;ed1ko;Y=L)f)*3wJxSWeIvt208f0svQ^LOzD`qr
z1z4%20PU5gTCDQ_DXs5!Ooe>xVV^BEEb}iNLgny*=EJEM0&Iuod>N#*O{g*Yjeipt
z*r^;mi${N^5;j<nl^B&Y^cK1|Z5J-mwN<{OFfKf!B=8r3&n-lwSvXbXnGs)W0%pnB
z5<ZAZzV=F#k@wPrB*r#l&M|)*QguZ6dF@|6cf_7^R6&gfJUZu?bHgFOhSs~PH=X2M
zE32nQsgW%81`l%Ae{(j9$zBf?_=~zNZGcpcv^0~&b_s(DR<GoK{$YMj*+Y#HJlSc=
z?M@L^Ra%)jv>t~gS3lDC+|BVZB-NcqG!gCM<kAP8!eqr0QBY9Ogdpndne87R*Ltnh
zdNJ_q0)CI7psb8T|5agOana0oGo=9Rw}&cpTpS;BMeHxswFLDWjwe4y9Fm?*>Y0fl
zyUsWV{Z_+?B%@<uxXJN(K!Z?d35vQwnf`22WdkkC^pYy#;&Paid4IGGQoSiDCJdab
zrVIWq0K7@B3;u)|WekHN5NAO8G`|nR53#5qaCNbEFyDYGYPrmwPOtoy-fq9|U6?lW
zZbcCNi0Cj|`}s!$5zoQKc5!y$Ktb-g-|=iQr$x6-Sz63}Umuc?HQ$if7$AGFwx4dM
z-|5ymxEd9Y&dkh;kB4`5d3oaieGP~rqyr0`XaskBZu&{anYG+*Igi08zeP%d62Wcn
z@3-z&s1n#^@9gY+`t%761N-|ST4gKM)mWbL_4W1W=%`<tgs`x0X9(Km(->TLaP^Iq
z&$LbR`l?I=OUcs*%#q*n*K@<qEHJjuw@n*6J#WmfVTi=IV7t+{#4c(5?eh6s@zn$~
z2X^pKa`61&{S==1rSu0}x~C#e4l*ro0n+)%nF`<$v+Szi-U85wXTDzNazExn*|;~9
zqlHTFjKR~Hn@GjKYeLrS#Kzfo3tL=!IO`~Iuf0BG@jF264q?{N$eo&3Z7R-x(P}pa
zp8ZD0sRCYr^4Z#x(Kg>JAlhQvpKhR$8OfG>K@UM|CdxjC3kJ)H#B9$mI+#|eBDf_v
z?q0ktrn+8pD2#<SO$)xV#$tBY9hL-i_6!}YZktt8*fynB)Oe0efMSsfk2WPZqdc1Q
z_Mz&(=Vhk?2L~gd4UsDqDxdzuW$Ye&KyU@Gtm5b*YXy&wU==TZKxekm#YiK1t`4It
z!3!1G8usULG=h0)ZO<>=zV)j5Uc$4zA|D5D^9EtikyDKh%Nc>FS@&G;pszrs)zEw1
z023?IRWD23c`I4U2%xW{ZtGMr+RW{Aud<CMpWJE%sbo>^H>PDDsC$Z+my$Jakv;He
z!qlGh!>_e^-CCNmDcq_32YE=v&2DyQS+)(EsO0%ZI6r2(aJ!U~z%SsBHj~lNe2+rz
zitQ~!I{HhVx+dc8qpWtn(R2=0OLzSqF~^J+KLYt2#ukSbSNTLd2!_+t;@0bW-^!WN
zui^91EmMn{1Ock?rQZ&1q5G4gRqIvG5aldFG`MZn-1KU}OmBtr<MCrjuc?;!p#>WJ
z+Sx1ig^j7GxHfx3B>jw-NU@GbNY55CKj2BNSi!n*c;~LKE@N~v`mfaOKkkvdxS3Kb
z@nOs%4amXE^?n;)a0?SF`r9U5#CY+A7E`>3n^!Xv>jy-;B_s(pb+KetQ(`dd?ChMw
z9Qo;!af{c``Abib%IimA85u@%n`{@#Q~A}^W7XA~!DgHQ>XK}slNVA?zJ2?KVz#5A
zaJsoV?&~j61UPSYmPUaUNSSO{=qYE%kC1f`qkN)@zxz$GSup5iVm$cnME?EzAF)YY
zknMc2cd_eNSZ0Au$8h9)yQP1C@g0gji^8W6K$J}{`<)GmTs){gEH=38tXLc#9)>ad
z_+L|txbIk<20L|kqblWi=w`;6?x*LwUQTlabP_y_XVs6AQ<D!DGr0EJSAheY1!h6M
z$i>9Zv3MPZSDUpEI^=3Ww#3a!Qdn33cw0rC+_2VXb&!Jh;iv^Ul#TG+nq*Uca5*Uj
z)h++QH#h5&M0g&NE|#TP|1hmEYjm~H*PrPol61rs_S*mM+uKo5;j%rPg{to&&d)tF
zj?m~|Lm!UdQTeb_?MaJVc~nXLOU6sLqleg<;0;+RC>2nwgiId;wukv5PhPhQ4wQl%
z%W0U)f=Ojoc5jz_+_p*t#;*?x>g3fkgM;RzS@ZUxNTZ+AHLNKCmuHD^f(0ZyvSwSH
z1`HBe@+->@(qC}t{6hH|aZMJRnVIPWMqFIbpo$rLlO?a7qO|9z_;`eRC!kzjhYq8R
zw4`mT$)nTDv!IWM=gudi1deo^F3Zb7MwXNqkHUV8@0Oc&EY&%r*?_@^J`4$J6DJoZ
z{ZQBuDj*X{21o|pXrXwFEl`0?5V9M2xI0%DI$3E0T@FUko;j#1UF<$<@P(R5N8$T>
z96GqbvWya!Bttl8L=PA00=urF>I@g_GWTb|ZH%IxDs5ky1y6ny6xf(UQxnzG_YM!i
zz=LAbiZm!Gm7o*(L`SfR$EuJTiEP5UiVN`;YR$rmz>L#a2p(aOUjcBXW_!2cQ%}oD
zRd3Y{zuV3ZUTSn(M^T<StU8Ib;wWWE=``G$$H3L~xHq0kOG_);XYKLc{j~Yb8K<Dw
zKk*<Rt{O?Xhr8NJZL187*N+w(%}{rOgzB7{bB7|76jP1FCnS`9Ca@YBlZ-dax|uS#
zFDZDK%!Wd7^^zII4;!)8MDY|`rJ7)cruQ9dAllxe)m3iC8Lo(Ts|N>J+1Z?*QF=|K
zyi?c_a(}MQVWsbF#Jf?3+=!AEhu$9isXp{Zcj5aC^@oOl`7!Kzbq$LL#zYl>IVA>)
zlB%;EUEAnSMyarXdnCK&3_zc_!t9Epi`Kit#TJycA@kLP?NQ<z(D_cX0jC6V)&GdE
z^0k1hJVHT1VQ0Q!IbW43lCTYd5(l)MO&OuGbp|eq1G<LHNy^1jzj_pQbBe{Op6xt}
zK<OEvXXp?&O4a_N@%~}8Vb+v!RBv-cya{nj&n$oHCt%1VSPG|_RG*6y=REqlE`-_w
zqh^g*H*r2^4`WWp#-N`6fd&YvtgK`L`>Y|BgVj}4QSj7xxjoR&PXrM0?qtz>8O>)c
zhN-Ko%efc(-|QGWPo<{n?--n1n_}mgg=CnFoVLQh@^dqv`Tp*F)XIFCLmy&6pEM`Y
zV^BW13w*-{$#=RHZ*8RuJYKq*DaRqqHg0qNyYH1I1+04d4DUV=E*5WnNL8bES1rQH
z8H_5?X%<aD$1Tl~KE!>4t<BcZ)I0b!SrR9BAzN&#zbeTLgugPes>Qh^i5F6kXrmaU
z_=`^i^%Cw8iG!`_pp2xF_sk@?5g8d7*LlzcS5H)x@`HxP*CeGp-RzizcAI`Ad(cA@
zS^L%LSwX%k=bJa@r>7tG9xk=~eZV#bUPnvfS_NwJjdtBXLc>vHe~NHL>$i-g^`j%E
zG-zHzn`L9Vf3sY+s;WuT>Gs!Oa<@LW_Dag-W-#t*xkw9?Xj6st?DDj~ukXqmc33$w
zQf|^b!QwXFmuM-hK_U#kz3TSm0Z~8E@RbT#*ViD~hTW=g=zZ@NPFVLfW%$aMdx3h`
zrhdDx#^FIIosT0fN+cB*|M!#Uf&43UYzp^`Is7J$SVEOc<*Wc2pE_f63erks^7>f%
zEII+`n9(`RdVTUsqH`Y^IEK~A-Wh$|eqM)5`2A+5Z)61kIH@v`4mY~1^>g^>W$Ie!
zBJPI-kVpD{_#6)z={euQHlIGt@+(tgNLfH$-OmTj*TZ31W@Wd{K#0H|ZyN3y9#vI}
z(A4o-Y|V3a!_15%wnts#>agR>%Qatl*c(w1z=-VtiIR11O5Bu1St7OgT!{^gLR~%h
zV=r%0(=18}MyU#FY5Ao-SV{`RyT-y|l*dQjz&VfF5beHa65#7|-aX~L%Y*q%GLoy?
z>uDE&ITty)Q9X$eO4C?px+HOcn#k~&@Z$7bVCQ0U?)2_1tXp0nCB<GuP7V{hcCf!+
zN4O|cn>BCjr~El8Hcr}$i;JmcE4q1mLz}&HNLZIxOVyOu^$*v2Vl6Bz(kcpNf3C&W
zLemx(7d=I?l9IIU?XB`Pi?H#@-*;!V|EEgDBqK|6OB6ZhC`u2!+8Qq+8)KY{GQf_+
z#%V>&@xhPfUcLo9856J?A5djV1Y<r~5ZGA*`3(zIXT;L))TNV|Wuo|ugo=s^<6c`R
zl-jI~kO)p9TO}QJxw$!KAsv;RoE&g`DEbCkk4xaV^4QS<H$se=Ys8jM;`UtY)vH$(
zt$Zb|t*u54{xTZJr>CW6ruikfa=%6w7u#$Q-%&@#Sy=oLhm%zJ_~amz%#rmjAfSsu
zv{+lIO$x>pC&T(xF%JdYzb-Y=KN4wc2kOsMl<1|T+W%1s+1Xv4ZFibCX?b8_Vd0L5
zW{}Z1zdUc=2HUnRy=B^c{8!*gnbl_cFoYU7aJ9MW{?x8SF?4+BUj|$TjBHgc0Vq_F
zz-vnY%+N87@<*A{SEams-g`AQ*0W$2>_`ihf~EVr05l;{QGPC|BJI7sy<*KG{9$ae
zw%^^0Z92BhP&af~hCmEz+Fq_EiXlhk5!?ur0-H63Cu;d4YM7F#T`XW>@j^<9K?eS4
z@i3;`RGuq8j?()|=AUvf9hVaqpcJc=wU}knwg5;bNjVm@007=T!3>u&OC*JJ0UGi8
zP&55hw$|3hc3712GzC$g2DuCz*?;X1g<AVC6z0<S_J3MPm4(O2Sq_|#XssMbj~&1K
z_k%|-@X6K8g+uQ<)Ke9#$9@yxgOPg$*S@~_Z?PMoxrtjqtbg-?P=Mi2_atKlb0XQb
zG8t$50dMaq8w(?WqsF%U;PT6a_Q&7(*yH6q)~>$hbNrJg_bu+Dw9S+}zit<Tw>yGt
z6jy;%>UZa-7k-;b245FN_<*Enlz{&vzGI~$;{OSqKk+gCe<Erc;q-|K>;E*>pB5NY
zP$J)qX8c?)Sy@?ClTWWv#OdUO?7zcJ^L;WJjy|lP7Vv95{^_y#M4EB_r|Ta-VgKLR
zv7#5+ZMR?kwS7BJ&;Px<kDtl`U*^dUGXMERd_wvE_AG9M6yScFla=(hr@5nxkM#f~
zfj@Ro^C|!9)`l~^!yfvC^X#Y#no44V^Iq70x8x3K!N><(ynR|ci2e8z1AcF~stJet
z_~L^o(_gFWquC~GL_c;M^n@m2m<60vF-55#&D9k_|9fwJS=*OQ=uaNWI&=coecxip
z61{zF$q*vLO$hiS(@F5T5Q0q@hbH4o2grYPdHr^j@;y2>c}?g()iU!M03#0a=Clo;
zMCjbf`X#dn;P5R=+-^ud4_Cgs3A8bP?<HDq##BgaPjxL?i~<dwV>0^mx6*FW0zh=U
z#z}^@)<1#se4mpWR%aPx9?`-3f`e<huzx9;vT=JIMpk~kFhnz+lLL4oSx?egTUc1h
zA#wC3kf+z=vH5j}I%QlWD14s)un-U#{2XBwka=Wn79oex@MnK&KJB4o_Keb8o0&v8
zk$nip8n`_xOB5hxXa2pnFm5hrpz=PC>8E1R_58rbx?k)4EC%-@?c8m~{R+#0KZ&N&
zziA`78eI=8(>t%Gqa<U(2Dn4i7rG9VNoR3PDYI=`?e2raM{wdW0T|&EJ{qi?pJYrE
zWs<)!CSVFEg;FsYn8GN<ePeJsp*_Y$xWI!yXL4Xt44nbvtQRASp!psCe{&d`%D7Oa
zdgr;P%w5<Ib-r$2UI2%Z5?`4JsFBltmvlM^lsW`7d+wsszk1bEyN@lya=ds#0)TlQ
zq0^751&i2^<<ObYeaeNk2l`K16BxEwY(bLnxho_uFVoLe=|E$AfS4kj>ZPC)?RvK@
z<!&Q&{o~pCq!QB%ZFs}`Pl4ytTijCDI9p=1ELAJ*%nee@_jT;ch&q4y?(Y&T0|yso
zh=9PiXX`Zx6zzL5mgt|~!z}6VxKgZ@?$_{5x1>zCi_^X?_na#Pj*U1-3-fMmd7Ae8
z?FZTw(C}AYo$Om}@nf<&KX)IW%^u7m9dq`Q`NySR?u#T+h9F1P%&aU2J2LPl#t~c~
zSG7=?7^0|d;@#2e)Di}B{lS$&O7c=7@byIkkMs2dqKdcI`6@_y61ZCp_-oUL0;)*z
z5ykP>IA~O4LARqU>s|z4<BY|d3HJ<c{^#NkGQSp4(A%4~Pm_{RjMru;adzg{@5EW3
ztpnA=P6$lGJmD862dCN1wJ)mWRzSuh^RXZ02?3(6V}smM3OClPHS>7&4#yvIwmLcS
zj?Q{I6~_UkB6-5s&{$5$Z6rZ3&D)vdX_Ry=`);!*^8A5j6z2*hSPVKu%#7m5!<LXM
zW*JOMbBQHa2{r~*Wm0iAJ@qSWhN>%Zr87-DU-+3AT;nw2xIc?yCNvTE)yQ#2lFq+d
zVI3p!8GiDCWL;SL5oUX2T-*mbunt9!k5+l<%oKBPhz-@|@A9$dCfStJ3_ByRBFTy&
z)7#rG)n(z4J|N}3y-b2gdfjbDj-S6rG|h#>e@6UX;jE+v#Q4MIEyae*7Km0x5GiEI
zm{Yc{g5-ve-q>)}wiZz({0$=;&mC^iIs;E=0Hxxt1Ju<4LmdPvX9p08?78h(ODrX3
zk+-85pBpXHnE@u@$*H4LFZ0u%bCB5rwC~3b8^&M%LDO$%>8JLX%zp_;I*Jtx3~;hw
z;BYZMKEafo$;F~m@7#>%3^F}y!;QDhCT`)oV#n)#NK5Uw%9>vC874WTMfSJc>LNj6
zw@Kab1)M+&+;h6y?p8)+qzZ~8ZwC%sc@M?Z`W?ev5(iCETlvnvB6)GJ<NSiJzcyu4
zn-<t3qFH2~a$W6yVlVk-Bbikx`&6XMSq}Hk^#gE_YPnnqOb}v+=wphSW|!od_SngY
z*W7G(6EELazY-nt8I4Y&yi5H8{0LDT*K5_XMeJ(P`u%i4Equ}h@;lvN>Yi|(5BoJ3
zbUv$SX=;pUasGU`Zzqz$0KYb_QIhzxoe5-7zhySf&eTb}8>eb3*8G1@HP!AWBZM(v
z5iQqxGXu|^j~`lVZcuN(*?OWutoKS76==1?-w~f3c7iO|4AX8{t5dj`o$``&?77&<
z_fDOr>Ae9=XCl$3Tv}KCVy{97iQDrZ8DO{a!@Jc5AjszHi$@zBBJl1zqoqE)se}8A
zx}z-&K+s($8$63xGP{pTknb+d#anX3jw56UFUrN2{$?90yN><o?&dd?h@eE@%{i^i
zDDsf<IaO`IYP<imF6J<yc(e5mlNQ|p|Is+i6jb@V)8T9>?smK9sC{1W0u&UK-Oe9;
zN;pqJ!M%X-tvWjx-aypZs-EqDIE$4mTS5%{x(~5&D3dJ{wP|^uSSMNm`bF_ZKzCu~
z!NP7nfd(3VNW3Rjd-PLv7cf^ye`DHutZe90IX|<i6)fIy-&cKM3C;jI&iZM{*jgt@
zM_!(`HNLvm@BJb1)uKB3wWQoXFhM!$<o1jU5Z@C3MpvbAPPyOhKpF&P&NcCdbgouZ
zJbZ|A*$u_;*t+vK&?*ikju!T8CdRv4-0I)bWChUoFRsn2rg2}tWN2R7P;~4FP&OLd
zSOEV1<?j1C8iX^@C1ZV8&i<aW@X<MJzQy7^^_k?|DPqcrThtVr^^n}O(pE1WyT!{o
zOKVZ#AQ*m`Z}+A3=Fjl-JCzsDu<HYNHoNU8Gj9)%v-_R4=V6aJ!+=rad;r&A#21Tk
zLK{0*=fzcsslzAx;t&RQhqHIOX|CCI%hse6UxVK`-0@08v33*DD*iv(-ZCn#VA~en
zjRyh*C%7cR-Q9u&cXxujJ2Xyk65QS0-4fgq+$C6WcYB@W+#~m$fA9Oo=pLg-@4ahR
zt+Kgh&00mnOhzYjp7s)8zQKQH3x9d`VC|?Hi<YvnS5=fPQ}y`A4mK$TolyE@VQ2W!
z1Ijnba5FxzByi&8Uvb))e&8et><8$5mZa&hLn>pF3F%}5hK#?O;Jy?qMZiMx3(yVw
zwHIC{(BhIl=ddO<|Lo%uzBrk0?D>mDW_ZWL>*3DSh`Y6vu8_0+aSfxhW0}WxICoJh
z^M3nMz^-R1B&4`dx7^VD)<f`f{*P36SR%m`F;s~OR*!RuuO?!^#2L+m5=f(<{_HYp
zD(5Qw3k}Xz24jLc%!`6kFd`)@F6cvccTtT*$#)W{wUPooYa!L<qk6-1k>0;3%aQdF
z3lK3+nBW_rtEzu@-$s?^{GL$vjBO*Mc*al18>DYE5efh78X9I>2DMX|eqlYyGDs(!
z+ibrIg{i=(Tj7Qe)(T<ZPxgOUmgBuyAJ_8lxG{t@P7Yzmr|ri4UET&tyPBqAN4bMV
z3q+lIFUgs-qy4Du{pPN@jSv#Mm;qH2XI-8RGuOfZIn)>0wR>yO>D#k06(h}9g))g;
zjZh;xhv>;ll!dKi=WS?aEV(6AyT)U5oYqkzr6Re?O(!MXlsR%UpCV(1NJ1eBz?08|
zL(=Yk_CZB{Bgl4UZ3cb;%CNc=&R4DG_<#1F<(Wf@44%qc)`6GXeZ}(5+(?wz>3d*u
z0jzihK)^UB&4zk1*&6%_Z}I_u_0xFrWSf0)wvQTcWvk6~6`#R(l=^U7qb9T7p@5<L
z^z>*AFH7Whi3VV-=uAu#X7WFE|4=+Fop;pJsJ4A*m6~bum^A&2D=oKRk7|D2m3OO@
zG#f(C90Z@K^(eph1uwv3ZPLC=CEz)C=z;B=-M8W6hwY9)Hi`-O45KNw!X?Lvb5EZY
zjQfGQk+085!c(5U`=<wup3ldNPvc|C$B*T~5ww%dK3AFa(O#Z6iCfV9s7`re^+#zG
zC=@8(W<y~Ur<#{kMasH_Mr0xtPmQ;FKv1F*lp#@**Dv`+{&u8Er82pzuTNOuvwbx$
zp2!hidot>VFXaDd9s#V6O5mrPb^NT0W{v_%vK8>6w;zU225zkKBx3#!aMRZYT4lP*
zNn1QY26x+fp*G&X;&lK1**QQmF<JE`!3EJ099v%3u<8?}3#@n<2WmZ_H!T;2x^1+-
zJ&tzfh~T;d0joEOtHfw=SJ(HQZ?>S-6XG)K?<cRtVQ%|6y}sa|LHhUjbMnK(nD^Jl
zh}&CVRQ@KKQp2?K)Ben3%~_lCgr=t4%;U$Sjr7)F=os3Jmi==7QSpq0dgU6MvE1$V
zv>0VKod(BQ!{Hpqp8C5=#o+=zi<k{->9A5Ew#!~0dwTfy1$?Z9kY8&Q+;+OIJe?L#
zjouT5wzlC0w<A|NN=A`do)5kDt}Wo5y&UZS`Yz~A!a;>wpz_a*Z}8mONoU%#3I;n@
zN2~%tyCuB~YKL@bbB&MP8OBN(Q3zv_O@msIf2Mv_BQkPwh_|Eeka@hO_RjRyWt3s`
zT4sUsIslp`Dh>8~wUIbrI{x%B%c!41I(8L*lgEB#SYs&b;h{`CxWkyG8v)kmiFt+3
zXXHabrLdz$^L;c<hh#cGr`>_)_!d<_jTD>C;}Y#;S%OqOLAi+G(n&9k!jO;=1C7?b
zFh*Rx?={Dw$#W?aHKu^A&cvh)i_Ndn;`s5$=(FDA)&zo4HD0DO*r{ukF1Uc~ZG=b6
zcqULi+O10GVLlin!QO-OtEh{g9C%N?2EPf~iQqt=H?6nQ{FN_QEGi9HgY{vj#6C_Z
z#Tus+NH6=5tFE&{LQ`;dA=xGR!=Jg~mi2_YDX$>-t14=*mojKE*m)RNl_<Z9*TGuS
z^|0^j2}0U$oc=r5ibz9tI4LD|BcE88Hxa<#f|bcx5gQ#TqI+U+UN55xwm|_X>Q30L
z)N62N;4ghC=#lb*FE*jg`@%j56ks8Pi}lQt3ykS!xHLm3!R&}PP;ex}p$9`<8Ho6>
z;R=E;2-tEmmVLX_S7W~t%4Ey4^2U0Edi`2I|J1usc7Aww*<PtKcHMbowU_W`j5KGJ
z@x`!v_>6@X8%tBj>&$fzh76M9)xa3x<Ko3BSY`G)4?5idIYv1Vi_Won><9NZguDer
zUVWPIyzM#9&VZn_o6_T7D{m)`o)&6bpSgehBhrnzv?4KaW&vF{k5D3UhihQneyB)4
zmt96!DAlp=trdQvV<!LkP%l}>`tB+rjF8zL87t^hp81i20#1#_pgC9nI1yiLdbVX0
zogBn)F|D|h*&-XfG1V(eU|X@9D=(k-DYoN^P4KU4mXw}vJKgVno1_azZ6V00IQ%=z
zrh~f@&YxY+n>JtTY*#yqhXFuHFa}C83sZtcc=81En4X}Y%^58PEIo6fH1(%$j+h&z
z;AxNsa#)`J_|<_+A7!42fZq-##093Cys(9O_l;<Q>n{;Qr~~@zQ|G<TrU5puME|<V
z61llFz~9GN$srE=e|O*i<>50Y82=#&M$glm{>cTr<Kby-YfIa?EujDNG6=SQ_gOL@
zvfGszBF$>nmWBRDu8wRJi<PtG843Dd_zOmB{mv-l-lIMU(L`oYwEx?5kT5{!LUN$L
z@suEW1^w}U5J*Q6kbys!5zNKR{suD=hM4AmQcgkpC*2Y89r$n5#6NeB|9_TbO#wYX
z>WUlC4dEHxGHm~n6L}gjlKGPPkaDuC`bSWP$>>lCAHDP^iHna{n9clM-o^}NYG-HX
zcnLg%Clp9@r*8^V_Y}X&t+ejmQC3!_@Hq!kXq0Sof#2pa*W?|?e;FKHC;}-e!31SL
z{vR8OKnfY76(almI}k(OAe&^!ztb@PrK}PndNA)ooAQ3(RBOMcV0G3(sP0yIclvpF
zp{4kZv=UCxpQ>R0o`vK0smpI459ibSx3Lp6L4${%pzEM2F#_Fu8-rhh!otE*TB!fj
z8-z}@&__g0fy$$w9)8^y@A16J{tkNSts>XgBB@Im9qivNF{WTP3nWN7>@HDsE_VbF
zp=*#1vpG}!smT=G05||oHfEyD!hs@&`TKY4zX@MplKg)3m2e8y|68Tn90K6s(x-9e
zC0(z6C7Y!r72LggRimvH+*?(BYfLarJr+hi%pXE4hUYsSAuytspV2AF_uQX%EATEk
zfu_e-I_25ubNfwH;ZhS5U4DUfokmZ~x|=6k`#d#^u@WlLjl=Y<#cIW}OAocl^z{CU
z;UCj%UcG6JPmataf?wOP<$!kc^dNw2ivr^lDnf`b!EF^ZUk9G>`uepYkl;2Hr<z=|
z50eZ<gR#$aVrhQY)?rJG_X=hq8B~c$Av8?tyo!l3VioODscU<;YMOUqGqgjv;s=s*
zkQx9m6NBN^tmc_rX6wJk*?#ajGA(o-m)TRUw-WsXyS35G+x3EZ_FT}|1w4WgqsgX;
z)&-IrSlVxT{L@b*CR_8N!6*cJ*2%Ru?9UVP_3#d$<y`0<-X3nK8^>ETpmH2HdsLRM
zN`Ovu2MR%F$qD*ie8^i%t3W$Csfc&+QEb|HAG2fWv**eHD5+EOu@6H94zN0nhi)Bz
zD71%Sa5`uGh8p$R6Hcv^t#ojuiR(5+fs1*ebqGh>d}!sXCv!dk*Ra|8GAd+bUK!n#
zf_I^HbOCy{YrpRr)j0BDA@|k+cZ3eQg4X!Bn=cv2JEfbq3ApE+Ak?ebq6YiU=3Tn=
ztP(UCYN>ugJ69{-$PL)Y)d6Yq_*!fz5Dr69xv-kAZY};HO_$*NbTgBiKkH^(lw&2m
zs=pHx)#&j2cLYLql_~`6vH5%|ERKl<{of3jn`P#T(avYuAbx;V1Oa;1QupOBI>ZN)
zdwx%ySod`NS)~aMe1=e*w)UspZC2_2yFIYfmHO(MDe^TnU4@6xk6KZCjWxiqOGZP*
z<w9V%Z(?_|Ugi5l_JnnKl(Z+wQLgL#xBIjEr8G;v;&Q1{4#FWYAEXMiy`#?5YdDM&
z-;5ZUJt&YT9E=yKUw_}NoJuRxD|77Bm8wASM420yT_B&_0C?5wu|<eNnN{d&EJLX_
z$9u9?zT9)8M(R0G&Muj~BR(E=#>0B<n(7d>f9&M`#`T%%PjQ>emnLWcHhiL=>(srv
zf;#P!C~U_tzZM8qCtCvaq6f=$RQO+6QT%k1_AFCEC~C9&;kQwG=?>8)br9#r-a*a8
zufh`0VQ17!GM;L3f%~;u@!WjIGw|1aOTt0CM9O`@hpvLU9vg3~Ix)CtE<#>y(KmpF
zj;Jxa4kZjD`IJr^8QP7O4zHcyp$dzRbFpf;ybvQSqO_<I-%4o^>P^zCtv4MWh;PSy
z?2F-hxI?a9n%h^)u-<U9)Bnl8xkcj-pi2kk$Cz4xSTAJTPf#?ycA{PrHfj5n`Z4ye
zxpqIMbvs>cW5gNLHl0b?gXPT2)*qkZx#y+ikpOu{`Juc7$j)`Z>q-lc1mwm1(nafQ
zy5E5EEqf+B&|EguuW8?4(X9pRA^9G=ip$Q!#jDc&9&w4Iz*VV8{2Ez|1Ttp-?&Zy2
zm&BmKc(U&VF!Y;z71w-QWLu|O;sQMR`C?kDj6{qy^);ZiIx+c|)14#x2TmV(n$I&C
zR*fkVUaq|#)88z;n#`A7b4HboQW@A(eByqe-#%0IgIST{g!@O9@hGuO$<ol$4Sr5#
znf{tYv~tIN3+r;>qKhwM<Ugik*Cd_|QGLsX4Bh4jd4bXSTcLSC5|bY}`i0=p0W68Y
zqnDV6m^GCIP}K_=SL`Cypxlz0$pkzR?Vtb=*?P_=At8Wy%5-{<b@*f~mJo2$=0;14
zuko3W-Qd|fDH<J%jRmH5cbKPkMu-ib{YvU%?y7n%aBD0hZyx(5)y6W+%13>AZw=wJ
z_tVh+Q8h9Suw8|HukeTanlhdb$GnWrotx_jbkhr7zNk+0hi0<HWzFi3@*VR^(Eo)!
zt9n#sTwm6X>EH70W4`vCnd525m(slN<$A}@=t?_Qv=^;~-j#k6<ezY`ZQJ-Q4Z+4~
zpP;$v=fRaIyW~ciAnx<mSA{?QxA9amiCbuQhR>mM;7|}9s@MQttXYQ&CYQnNVcN9`
z{;Oh6;!ra1c@@XnX?47Q&@P6DcinAW8iTi~LsmKg4fe-&!_`G!{xw05;vVPk-&Zb|
z|Aa;mmiS`uUZL!IsMS$QWHYR#BAz}G3c<)dm6Sa(9oGy~8g3jwh!3j}Q(#z-t({3y
z>U_rUl4B7A>=H;s$bLW@<k-QYtM<%E3B5C=7s^5Z1}<rAr_OI0k#Nf@rvwHJ-;{+W
zO#ftTqK`Ght-}rqM}N_kWI+M?=<rVFV}xMQdnZFtRi`30+F4`pOvFHSj((x_=%JD9
zw>vGY0IN^m5MWOHjbZld)7}o4yn%hWK^NAYBkv==44pQJ2j5uq+=}#PzJ~j^`C5h%
zVAOG1I|!W9N>G+nL${JqbY*;3+RVGr=m<V5d>tS|st5)(Ehy>(R3xe^%$5w6lQJDM
z_Ey`5vJILFgyzV@&hAT1I&&@7qwCt!u>0sKpKBuY9qE*Gtk`?4qyDzdW+YZG;5&>G
zxCu|>fDVamC2dcC#C3K{81H+tnx`Yeu{vT-x{qT$*5TzR>uo~@4ROt{vCh`Pi{bjU
zf$Xy_8+VU?^89VW`T{dcYpr<Ko;uX}y^!3p`X6X8LCaPN67-CM&$8V!{Eb`!Uri{d
z%mQFbH}pRb1}+UAMO^=5ok<uE_Fv#JWeb2z{1_RtW*?^MVq12!IxosuEc9n0=RW^=
zax=j!3L0F$C_DEuvr}?e{loO&1MwFd3-8h0alP1&$EA1Gi=R1~#s1u!w_-C7*{kZH
znnY8jK33}0)P}81lvRF*Wm%o00wY!6)C6S*tCFdz2S<-eSsI}lr!J2|kE*Rv57Q@S
zV;YNTMTg@z+-kqD=%Wa9#jAd@;t>Xc&sBu2*`a9nwgd@FnF}-D#ZM<W=hkn!pQ~2r
zKH@c!{2j$_^B^%DeA?AIv~5meBndxh7{2PfHP*{4B9Yi!s|#0qb5)}K<j~tKo4!yI
z0n78u-Eyj~k$k7<mPD~RwpQgft&1wM8|Hg{|2{-8RgF(rMXzFMQ8W9|+;lAVi<$^l
zuZ@o%pe{3Z71_`JtfuOuyUacJp~OL}TE)8~@6BZd5xS_EVElE@Qxz>~hbIqko_NSc
zr%u0<DbV54AAd+8#jH5l!-wpE+KKm>dXTr>XYsb2f_0C@yqs@HIRi8;IlQf>QNO;~
zF`0r8eRjB)!&Go!HGMi9@43ihu6EGm@@sQiUesPgcTA4Q(Xzs*zKxx*(@gStmG$vN
z!go=F!$Qi2+lOf-K&OF@=F&;?o+No`ep2_)CSTFdcB7>1de4K8PaxrU<B%C294z*u
zTFRjTG9-6ZDgkE?dcgUv9;5Ajx(~9T#a(@=E(mgEA+Q!cAU8z%(36qVV?X;GAo==&
z+=Z+DHB&tUfR9$fZT&6tt<WRIwKEZ3=carGmEGaf`3LJ()Z_(@X6x(vdj=@nGeJ!7
z>Es4kYp}8uX}v=?v-9~`zo%omSg!zMy{&@wb0vyB8%6!*D>eS2XK1DSgx+4?dY<8y
zIvSKboyemVUx!thw;kJpsm{FC-)!^gJmrq|d0C%Ip_@D71E(~_Jy&p7dv#|b7e52+
z@%LAmOV<`oBSX;UY*T;e_rN8?Ml*l}>NGt7W3mQ#quYi(RUq@T*An<VQPJy)g5?)j
zx>cKdLu55}K*>+qKG*hhgRm|4J<%1px<{K@IMG@rvVv}DTH|N8dM}qcHPl#N(gm8|
z^Srze@ZE3Y5w}`ah0^{iT#E0NipP57E0;U+A8ZtCTd_6_uy{FhX==j5ELQE#H@}>h
z4<ssy*2Kl#QlSsog&VP%ekZ*RJxN%U%jego&#*6MI|xti<q6It+&x`&))}oQ|I?=$
zC(1q1)K^vMwhy0e5!GDY)E)#;*-NSFru4)Uj?<>{44}TM@5&LNA0}A`d#&`hB@`<5
zKmiA$Rhv|38bD9vE4nq(_$qLrvSEsw&EEH!jY$3RsAD!;J-_?D3me4CUme{D2kIh<
zE4zh0E1BsAPR56MeNbb}FOY61Z6mr5*!?fW+6jtt`Pv@K@Y~<E$D=!nvCaO&ypoMJ
zz;{I|W}heVs0>vY7$<u}%nlIbx5)#P=Fod0AP!abs6w7QU?=|}GF6hUC98p49o;H$
z@MSP_^Tc!(U8#|=yWkL>&BrM<RYto!aq3lXos^?V>sEoJnd;zpoP&`QVrD0aDoN1c
z&amrZ7#S08okM=DkfnR7Re9uhO6R&{XY$66q8|f{Hy8eAFqpSlHWG9v;U{z2+U>as
z)mMG*_3^~E5NU(lUxwndR--wcfJ>c-dx7iTj}71S2Ho}<1a{bZL@615kcf-q*{3X3
z1FURC;s$kOk%r~zJlWgbLj3_*E+3<kyK8(oJuc6jdiHy)o$%Lo<y^&HovI8?#h$no
zq5X;=3bP93@U>n1EdIooA}&Kg!yNfhRricOsTv#}QUw`GUt`iej^cdf1w|}=OCuqY
zklFH9C_rBxzmx8TkGGaP^smJ}*I}PdA?pVKtt;<oUGIqw^@ff{e3$oQ=<ViR<R>y0
zGWD}+-Ha&#!$G|ou%iaoQFg6(BYXNn27mUfc&gm+?S$()_yt<iN}qOqS<W5uQRKbl
z7hz$w>ovO7$A<#Mb|me}>)d8$wn|y;c?JFABTqE*ItB-vBsHmRH_Ogy{9ZZn#)0<G
zt+ex>@nRgxb)IEo@GQ%6BR!@y#es8QX%C}5gwlE|)8zp=s!N`YWrK|r7Os;d7hmy^
z|EYpqT!pg5_NoMzorK^4tf>A(z}(>jC(Q{MQ-1iZwR-oIPCSSk_6sQ^KbdBjzbpWD
zYG#cnZ$g?jfssmx9UXRn>qUGQVk(@U^F@eNMqQ0*AVDHR5YT%YU%dMKI2nNk#3>fN
z{zO8C-t$@vz3&C^ACo@)R9xI=KTYb`PiAz8crU(y3Xs*_`iBWcy;nqhAKIhwK@_{5
z-G9URW4$PgYW@Rju3mlpf$?$^T{8U_C(J-)v7ab)5Z%kK@7Qhg%o-bO*hiPT?L|eu
zR1=eakD%Ye5);*+m74OQAwFmLqL{IYEonS}E?DPwsa%dm@L|3#LEc%nb$1IkVHbin
zP0P5RCnMIkF#$W3FQ1_zR6u24m<#p81_4Daj^Px=4XgMWU2;y{{`41xj#@#oHitIL
z5mz-fWeKd6Z)+_|QySMs#r{$|OR#wSKvTXFSiZhhqkNxAec4mf5=LCHp*g`B{$e@u
z_VE6qTGp@Bo^I}VI7JQfke527F-*hqcj^t$xxpV`l!#`U7e`vEH7D8<oPV;}3jKi#
z4oFLTpf2nE;@$RzPf)9G3JYxguX4K1i=KN4|K5<80}>3nO0#Qpdh+vV|MizsVufb~
ziUj#g{@gM_u+;KTjFCd{FN|Sx3V_Sq_{wkJ*0a%0p{iL_ThSB;7wBEH;wR+>Y!%o4
zbe1TIZTK5yu=#Om2n3{hoOC6YjzL4bXlq0W>7aNSG*r1~df0%mZS0tmfS1%U3W;vC
zxz>pMkzTGG%axaEKk`o|gpcqbLz4XG%=>wBo#z*apoq++F-*6PGp%#~TN*oe0JQ?p
z7K-m5b<D>io!KdD&iUr=VCTLzL_JxS(Gz(AvJ+i9D@o&Nl&sPWEGbQubjUpc0J<h#
zLCYuYQ#v(yKJtn>k0b4s$nZB<C8}R&itv&lN+oD4*ES0k4n)1TllZ+&sTs+CG*uH3
zOD&+T&va^_ht_w<U75qtbKxdWd&4RpX2&u#9~N(WOFvhp%do@N+^VToay8vFp3jbD
z-Z_X~o=?&=7{}u>`NrRM?HVc#)Snk7sLFJwL87s2(D+DYbngA!V+*NIHZ7MjWbt=*
zW`7<ETSZ}bI`sPBu@~uF=gu=r2q9y7)AvyXJ#$yne0L9iu8vjS99FSEhf(FdIltIr
z6W^(9Y5Ljt_3bVN2>kV@%7<ccS+C~39QR&y=nm~z7+EAB&E+(Ve0z&Q?M*x`_0Wby
zFJWcMTRIAzmUqo$N*J=OPNP(G6z!kx5&wcPbDL#gEq2!)AW9>GCz<wPJy$D?ys3Rt
z^t{<ICbE%8FvJF1!5QPyEF%3p=<PdvE@179;xPcN0QAX4hacb>BHq?A7P(Gij_mrj
zam<=4KR_S>cJJl$UQA>mcp*Yx*SpuRuJp(9z1&f2@weHwq5p+Z@NwY&0|petybWnO
z6M7_0T4<!De=1$p_%{$!=`Jdle^H_a=H|lzb3ZP;(9MzUgd<^lT!3IAxqQ~?^)Mb?
zHYs{$OxQ-b_81eC4_w|Av}NT;|G-h3V@~^b_Jo`(7kd4fP0wzX*!*jrfs_;~SC`Sc
zv))V#!|-js*Vt65riUW1-El!(f>jcvePpn;=%$@bQ_u$KBA&r@O>^(?+T;rn#4Go)
zqt6_miSgFk3(uz9d#2BBq1|oS3uQ2$*Y|$L#>WyzoLoY$l1>=Skfu|893o#P>s8FH
z=H$kV){HwmMOon|8&~zg^t&1B{$!5Rv)CZp=0;Z}llm=uwr4SzB3~!`n83j2hiy9b
zk;Jlr0{8=yP^UF7&W~zn5_q*MEr)IvjN@$Amw#g_XG1CyTzgX)!26aAsVm2I2r5JI
z1riL;A|;n?e2_Du$$vo*g$T53v|p;g(Pw=sm~>UYqKBC!I7u?EnL<2i-frJuk^U23
zl$z`n$0;N2E|&DRJwD5<4@G@UXlHzDGdLur)Ks&PZ0rbs3o_*Uol&}a`vkML9*FjL
zuEx6mSvE5fCIs@A9V^ry`o5WEd4`3{%31F%T!3nY(@Y%pG)EAkw=pcVxJTaE@@)Pt
z|8m29fH~nlZg$Qaxbm&?_91u*S2fD??sLVC5dsUwxWV`eIFaP$?*D}}X64rsBx6s{
z1spEw$VjrnF>+6kIUO!oH*mfyzMHWlwn4^n%{xlqM8oh5@x9)OLWO#K;?3aM$~N13
z{A<JJqbeLf_q)5&@pOOE`}Ynhhq!+sg-iJd@6OYU_*x20%UV7AjwH}*i`dBpvV5jg
zFe%SgkFlfvK709Af0PU5_=PN=$3x}h_Q{kZglbS4Pd`INWDMH8ulMMdS^jD#%A0`5
zDdgCz%k|&UPU-a%VMP<Ub7etlA?qr`$IFH{I)bJ28BX`dgcR_7Ul`wYyHylR{T?}E
z3S7f0ftxAI^}e&B4xL0R0gRZ>i!HVkX|?vA`xh_T`4_x2#}YeOxW1bpZo_I+&Rt(+
zqH@OQme>)p)-^^JR1;<!Uj8r8AmjJtF2wh?k$0`Jj3EC!hBUr#I^V~%jmJvc@f|$T
z<WVI;8WAzmedR~jpz00qfX&%Y*IAw0lTWHDNM2vF*nPCnAMP5?;J!CT9w$8d1S}-&
zJl}9?+l!Z)w0DKMy?JMKyFF6a-(a+R@l2S1u-V9iV=Xb{7b^-z+O}Gno_hP6nv%dU
zdSCrS*s|Q5PwEh~aXPs*!I)6F@4r<enKP=deJP0Vy}Oxt^~h@UzMfY3WzAc3@>g9*
z>`IIboKi8P5{S5cT9^T%*-I7^5u*qkl078iWK^(Z@7K%T|Hd63!Lr>S5h9{P6LPXx
z%E|s6J|F;+a2Cby-{sU(n!S;ROJdiKhtm4|pFl`R@bYX*+rGcl#1Z3TLHgsbrl*ik
z%imH=ahCi3g**nbHB1{*ar$1$&~eZO1N5yfbmn{LkWC!Te6PE4gz@yzdIA^#pcqx(
z{_$BXi|Y-%VkfmdK{pQcT?v<_NxJD}eEQiGX+Hta{IUT==8Tur1L5}vsBM+YC;hk1
zGDacMta;pT8#z55ell>a=tb`vriYtHuN~&;zovx66|8$!q}fN9DRoqVehdCKL(N<o
zF+%#1q+YULcXGN)+YvG^XkNmKplHS1&o@|li=p6RW;u8{uG*w*09{F}PMg}3KWn8{
zuN`{3z?|o<j3s`|U07kS=8|5hS_Wzr5edv+sWxl*KzR5(d#s}9f(KXQuA9?%kk@Wd
zU~MrkI0_B%`pR2|5ZPPR;q3IKAl@>I1lB8LFvIwVrE~%who&4^@3XTDrF*6D%QGJ%
zxW&6OJ4M9;QG<hoLRs{git?20^pbUGuogFLXz8r~mctz%Q|eXP^*Rf4x=6<B`2`bt
zuShDp2Ezp-!tU+81V8_2<fbbk-;XG0gl_NAce<GMv|!*%Rjt=^SDDXAQFmu;C9))&
zjO3m<<Z5Xkk*Co!y@|WJbXtKd#?#FSSe`FKjzjB*{suZ*Oblaw*IoFQGkEJWlIoqE
z6~D{+VJ?kZ|K)Fllt<lh;bvj*NmS5WOj5W->)Tp}A_?i~FCdZSNJs%dp(ssnMNNbX
ziMAzXWX9|2-P{NZO=`J(^7DQ%NY6yx!)Ki)KC_c1*+TR=M0!}zbF27ETY=5?V!!nx
zCW+;E$k1d)D78@%P`qZ1iOfp;xb5lW!Jw9vP8m1DtxwjNtP~0*t3eA54AFa^joiP$
znq?uA&q%S0IdpVbffs=5;+e=ssHe2N7>2#P8Ej~j{PqhJsl^Uyct{`f9tsg58?c`s
z&Fw8)sgkmG6B0mD;ysl7ttpEVaMxV-Bf$YuQ4oQM-d$5fZLz+)*`ziiFDgJ{8H5F#
zaJhRlWSWxZ0VSDnT+VzX4TaC!CDG#5Y8lkhEU~nvl=B%q$}fMBIzwxxw5+F&5MDvr
z6v(d);&v~;oVxE6<+c+h5pRFynP@B5)1*)3KT>aAnrgOXI+$+8PY8VJiPhEZV5QMK
zfmu6)z(&QBd~rw?g4n+^_c(w99tY`J)k`wn5M(X+<ZQ94ZdR^JU?2#hbg7NE=Kuxm
zO9)TgH~ZkzcUF+Wy!r6tZhvt1?w71kf}i`_1;CbL(g9qkrJFtT5Dz5=YkL>8sT7ro
z7#*d$?jfqSm{Lt*xjOc3l<J<n@Z+0<z*BB;;ApWwIIvR*gS}9*5{+=nmT$c&_$=vg
zv8|K$@n*f8>QgFeVgW^b$rp5);k~choLjFURW8tCd;a=z?C`rOoAV+^GLIGHa3J`m
zg$zeIJhYuIZ7K)PFa>1|cJHMay9vy*naw7@iX@iipB3Osc$yx|NPV@j1Y6Vg6ilKQ
zMxPITvC(Ia8*i(5`A%<UzP?Bue`71hxcw%TeCp{-`MARIO1<rQ^2TEH9!pe800zhL
zv?-xL%cEP*HcLT7L>sI9xdATS%9;V~a^r1PY+{dkT6`0Yy`{s?nYgrXI#`8ekfrMi
zm(v?xezYG)Dmy1tV5zM-qIgLQAF1M{a#3?t2XoaL$Pf3iUg;SM=@cKg^YyP<sQYw2
zb))nTt`8AXPTx<u4Zgw`dbr5RNQ!Os&V~Mfw$hEScXusrKT{tvj@8D)<n*dyH96_d
z8~G?B5o*qL+b1&drRI?r9u*0npL3dJd+JAAfzACp$B^Hv609*TML$hhc)O+_^nm2}
z^?I?YogfV!#qd`URsKPK14D^VGgDuiwslz4?Z#2w!FQqD#pdD($DwPA%-6haWV}?1
z3?J>vh+`b6b05qkl{>R6K0(e<8AI5^K-(UN3Xv=J3k&a`r@f&a&jKw6Y+}8p%A-UL
z9gvhmwpg9Sq@dwbA%2w|BkcX))}nQNas&cobq0P=JmbuG3o6+{f_pcA`rS3o-h4H(
zY~hl$uzy!2<1`+aI|wXXM99iMH5xUp4}Q=}H<EURJz!qO(x+l8&08HHk;4L-#9<B=
zJs6=7VxZ!m%i)V3S-$9y`7dE1AUbHEUhJwjTiGu(8701&yo9|j$_gA6-}A!nUiOF3
z(X2{{xS*h(r}v4P<jRi6Ki?KRb`r9qkwTl!v?{|HhsTU8^B?v=4roF0_el9_`8X&$
zI`cB})LsDqn-*62Rz8?MQRgUy`c9L6C=6vUzGsK8KSq%N@w2hjDs}z<#y(=B;958(
z?f@r9JJ-iUNc%qLjWDEvtm$zZgF<Kq^aI7el+U@qFp9o{WB9}Qh&Vu-F6yTxOaW>^
zELLW0FzfjZzq>?P=iX*yE0k3l1vA2lvdYB;pNgW$W1$@+Mkw16VwOWk=T=Q}XLyfx
zlBTTX^0Z9=2uOra&NO0@A}xJ3B6vXxZ0fFC#o`HSL@lt9)G%(OaV>QtTty%X4*X2k
zN_ZRD+W6GF&)&59w7FlhZ0;8}6>4K}63reod-uiK-FdFi!gaMj|L$^=M6TC9F>8XL
z-c#`YY=3u)UPved5r6}IXr+h98UWrb1HyZAvcMP~Rn6=|Eqi-mi|SpYo^9p$T56Z1
z&f3Pz0>)vMEI#m0e_D=l{6qw=JV3AGUfIN{6RjXq2R6b*Zb&MwtwX)!45n*8oK#_^
zGL0>+P}a@cPkC#yt7i!|<%tLkS$^ljb%Z#-GCJzQM{Z2e?^3YQeQ#lmJyD)&vNYYw
z(Ja1CV=;7KDp}S^V$EW^Jw|Hv_o%?;Zg{msM$jE`vKl;#IyP}dJ!V>Q*_Jg4%&F^c
z>9VHcBrl3PN%O@+b+EF%&G&x4<=Ogn>@c`Lr6Au0??>bDuV1N+q>z5?^4)a_{EG>C
zWb%|;4AqQ<6I)Q?{Y8*cF=Z$C3<*a`@hi8A`}u^kGvYo5+Fmh0V&7q}26nz%Ax%G<
z_+l^u=I5iiEOM1ETp0egqs&{<-6pT)PLSwB4eP-c@tO-K$^)j(c5mC3x$yxJP(#E8
z@^7`DZmIPwyW>TED+2n)14b~knMkB)DT&9oK(aB-P=FeYUBU-6VGB0*p{{@z@CtD!
zy<<ysJUc49zTK8{n^e$*5%MhJnE>@Qr3$eN>I-<Sj0}g3WZr&P;^<JjQ&fa=r@?s`
z4oA1U;<%HdR}!0CIEvO!A6x6ql+qG@VPJ!*lBtsGw^!c{cu(5PJ?A}|<2AzjQ~QXt
ziEtM)quz%EK~u_h#>8%*Gm=!y<Uy=7rs7Q2k$G!WNRs$?*UjTv2*`^f+u-Qio5yoJ
zB@T(B+L+!=Rd{acfU5b*C!?cK1k&;p^Gir$6Yib%aEv+vhL7IP42eVECSyx8*cKP_
zVsBL%YfR*jWO?2lDOYXbHJ;2hX;xUR_S)>Gf~A<{Y?m{?7&zHb(cw=v28pYy0gwf^
z`@+}cfM9B)<KidGNK2f?8iQ-+kXlquTHVX*Dv8zd9Zo&s>p;ubgqSO*Ke{2G+ns1z
zK248EwP5O@z6)d*l-*x$OcLi)1gkJFUlMXJ)>T=~MvD8t!#3=m__FmuOI{Zt5lCz@
zu$9@z+d%FoXI=V1>wR^~V&fmI=6?5HJdco{-$$ANyrFS7vdLmoCdS};zCTfHT7=lO
z;C!#y>ol8}<Wm!1xY1L-`XN1Ee1g9|l|4MMwaN9<fHXHmr0N6ARLI~8_<*@mw)%5%
zD)hMA+4C&lTiu6A4fgV)e{oQroqly=xC5r=`?}~kbN!ADGLTMgo=n@0w2z5cq?{Z1
z!Jn1%(XN3?%}hMHE*S0Qb|Wbs)OU<EUP>kW_#L+7)|x&Q8_}%_oO*%cgCzKM6~;>n
z9w4s#VDqC=$xCXw(_-|J?**|mJ}4a2wa|H;ar%h>f6?LVx+Rlwq8Q4N(OrX<)i|k+
zRujw5#Z_x}&uud~)f0nni5<_a<2TtlZ7R<Nmf=xpzMjIh?UAXRCGIG|XX@j%$YPJY
z1W<Bcn3_uvjTNtB`3wTG+K32h5g=zCuV*oAhXL<fGYmpT<ys>ze{!@nxm7^LJU@x+
zabPuo33Eqqy;+5W_-d}z!Ki@EE@l>0v{N{yRAk@JU-G;b&b1Q%7iq8_?Rs*B<}L&S
zk+m=|z5@Sm=7F~z7yJs}@Ze%e$8P|S=dxbRjC0s=Kf&8+-|?ux*4u&y=NPI<qLf1Y
z@a2~+@%ZwP?^J*<_bx=52AS+3Hv8wILH+G3)c<t)sUc3k_Et~rhUe&_+FA!wd#W&B
zi!CFRIpUv_r4UH#f6HxPc~~AoUJ|00DGJ`-o-M1c(h#RD>0~>>jZ57!I~I*P-v8g;
zJnR1mx?CDBn6hqt%609Ot{Jt_qVu6-ziU@NG&rZuoEeGp#F=^&67fCFn&a<FdCwWL
zy_^R+R^9G~<}u3a=PNn&MykAy5E9}4@`j;=jTeYr7dN5vzHeJ;A_(E%yL`dvY&{wZ
zk*kBEHo2GHBYxUiJp-@SIK+*K1SgIET1`S?^%ky-X3tDG&p(z%iMtH*wtc<@L+|Dz
z&I*Zmrfxt4R6ZLoJX}%#&|{<x%M*nF)$5{s^yJW)oUB;J*ZK=~!Y$f(eP{pSMq&V6
z4|Kpkm$YkP<|FdJ25q8D>X<_`J1>fjC+wnJ+a&UC%`*N<0|#`rQ9Kc2gx=#)go06G
zkPJOT3BD(6$uwR$fF~$jz-D3khELdF-9TanU=36b5F>Pe5#qEy{_tx>`y;{&e5E*A
z?t@X)>`JdnuXQyGTdL(#db#b+Gko>)51a8yn09#&qQl!%9r|9in#Q6#o&8<C5o<dC
zl2|6Bb@n+V=q%rhaM0EJfzI0>79wJV93m;49V3yl8~p;}<}_RCP#NoSn@r6<79{bs
zyGq=yT;4(s{J1NC@T9LqV|UyGy0et2Q+IH|5Qwr=|K#eIzap^ZskRLXZLNF^QFub4
zJ_@~x5F_umA9V!26YNV%u*7DUpHsVvAICsm4RIXd{v1BI%?n$UteP6Loz*4Z81lg0
zxI((+>AE9@K+5(-;?3`t!)iHN{yPK9x9GwW<+#BHxCO;hKUjaOD9v5kMTV}A#u6c<
z!6@DZQmH<!U*D@u*{*QA_#YJ(T8{gKiXE;(9ivxygb+`a=_PrXb1J>3tC@UaQNE<^
zyQxP~^1vmBEwW?sLX0r>rFckkjq}@(mw!V;#sdOdOP&0)(A+$p>6@+X1&h1(VMv$K
zi3oIc{wD1DdzUo9R92=YT<E!@lI2AZtzO@ce87RnA^t-<)`X1>J*!bx%JvLTp4aga
zq|AYw71^B)=x~R>zEP99{^LT8*Dgf%Dv_Jz32`q+dv#VJcc-fSPI@owH~wSzSMd>w
z;USVjhgn6*(h$~vSt`#5VvGTu(puAa=(grd6spx$9zBTml0*SBbq5(RyOHS%j9HwS
zJjAN~{L(}A{rMlWxOO;UFp}o2yJZyqZYVYwKdB%0hz5J|(((=*Dn`^h-wW&Hx72uG
zljN2?$-x(RQLW;gUsk%#1itDyZzDkvGva$@UV%;7{Thu>T$+=UQ$YXc9882id<E1p
z^q(U;|9@AxYCzB8h>|uQgw3d1tkuit;0RmEOQxq|9nooPF}*}~{Ua6Z3e8bJju#EZ
zIg9#`k65hS{k<2)K?|Mqq%C$Q^6=4vQGYL8RzX2QN$ro26h>E97g;)6sQqfGhUO)C
z><1Ny#<h_S4n0}9m+>>?zkid5MzzkUlO^(SIAb9cr)wXTu_dtnyFe69R%+*IkkHTX
zTi1_&2t=p6f9qu-R07xko0j*zODVHqw+>Vq2~sJ-nuDKk7jn(oP>hoxyoQ#b4G;1W
z0Wd&T%CNX0k=9b87#toGq!E_@n~0*(sx_V07>vDy)oMME-dfFt*O>mHHUZj*ULQs~
zJ2a4~m`oiFI_pl{p?3Ka*(aQ4E_8m{%WTQ!vSr`(jqnjAWQkrrr?&<oq`T*oArM%_
zthvv`8r;=L7j6rQ_8P}L>kmGz!2VSrciZ!IY&fV>`-%`eKTccHV1?g5LsWP~JNa;#
zd4BEE_7k7`+l7ix-wL7WWi)bUDjcwI{t3w?%{ApR?{MrfakzuUHmc9sbiyh={lR4?
z2l)dRV-12`cUoktNpza!-QF;S!BM`KuxV&*>yGTx((V=;sn{0TD3~3d%C0;ZolRNR
z=^&rhLy1TRvdln%?9K)fEDqstK*reFu+2IS;uHpQvwQ<k$1_nY2_8-k`r52Guw+1a
z(<n&cigfLi5DsL)Cc*+WBw2=ncHLy%NNgYbbYPum{mXvNNnk8-3Bqac*x`U~Batvs
z;<9(Lm`Z1TxoN5>J{}3~E(A~nM|k3VSMkY2s(8h0o7EfHHc~ivn9j_h16S-|@NGpC
zcCA9~lZIo~2=PfV6?tjb=Z8tXe9W;V-eFy)k#c)bl{YBwP840(;&j^+UvXF_oV0LA
zXB#MdW&C<wSt+rqxw#d8$!+*|1*Mlfoz4(a8NdE?EaORx-F~ZCTdK+n6^C`?#;_i(
z^nnWqKf%UjqvzFM;_YfJMiNU2(qaW(`4O%2p}s90H_bTu-XQ8z(E=0W>1-MvWol9w
z9C#%?%!`~Q?v{oCZuRgOe?A<J1O37oa3*4gXC{VcF=TtTezFve>bAb&oA$_QF1+??
zXTSiL$z{=d3=9|WA3^HR(V-`>=?VWT9|*#LySg^xLt%>(qJ|$&`5d8a=h-67mtIqF
z&Nn%psZM^#%%+&VK^<mqaXmAQQ%ASJvxCy%>c3QqUy|{z(S3;b`Jsj|q}IXhTHpBS
zR|j9ZNdLT!l&Agi)fPp#R-HU{1kv0i*NM-)-;Rr|j=k7q&KIqtwb;qEr7>Nx89%9K
zNvNvpXzS%nua21>ORn2W-!eCgpTivN*lH(ViA#x7Z!*s5Qq9B;hQLfXRj!{05pwY;
zp|!ISK-zR2Ogi<hL1gHZWxPsQx~~ggiLqr>AyiAVKvUM7mlO8o4Xp@d=x~n?V*%Tb
zr&Z*Z3!@bY)Je%ZgziE=t`h15NAdGbP~v9XUQpH~*(g-fDJlib+Ga9|^T5Xmp+UiP
zxuG*cIj0aPb{-n1dlK?!&77-Sjak`OxfGbm3;w825QLxd$y1K|HpPi0bjc&@tJiT6
zXM9<zHYzr}NTn+h<qvlp7^T)p)CrAMn$(cH%i3u?ys>nQWJ1SLpMwK7Y8LgSRT-yw
zcw=&x=xi0Dx!a8+viG70k7rBF0HzY8E(lfZIW4@`od^Y$X9Jc}N<6o5+;1^yUvS}%
zi`dwUL$QX>lo9}~W%F<NEP6bY-MyDE8{gP11YKAxg1WjNE!B#gt3?D1{ob~&xL*w{
z{Aw~K7%_g#IDEEv#dA^rwGHKFoWSQ~Ed|R$=Q{g%kW{N>KVAH~@=)N!I7wD#|GVO^
z4c3FFM=cYa11YcE%O<=blEfj64l)^(B(&+D8v@HbFco^KM^9HGbetVOTQBb$v=M!M
zoTU2?KbT5gRi?T5a&X$gZq)KoRd3)#U)V3E>ek(?W!eVztY|J?m-AttJv?r36Aew#
z%4l<Wwk>yEda|b>xqCQS&5nl1)qKJaLG_;h-A*<#J<iW<3;0i_v`_Nuu~$TcbJpO;
zGgp_hCt;KZcH@wZ%a2@Rh1!gHURRrp465JmjRk5u(*sV{ejrqFn25WJKE2|eZ(pQv
z4y38asX`i&f}P|0+c@D@ph38iZjPJU0EkrA5xX<~W-wJtwgypOJ%abByq9uh>2$Cy
zP?>TQ7iVX}dCXNFW=X>F)}QagR<h`cOLq}&Vg*A7?Ciq5%k~GTe-hX}nd)e`Mz-7F
z$AbfvYzx0(MAx>)^JpasM*y2t_jiZCSa%0sk6QR?a!AS$P#=an7JBixD%iZ{fAmxn
zX$W10tK8sMD))A9X}i5YGfEZ>Md~iP*3&-O%jqElZk+b%gL3ROvx1k9T-%y!n6C{S
zGs~5x%Xg~PLpXI?ZE+6dDXcE9dbBJXps-fyyi8n7-r>KRHXTcJ#s{Xn@^D#Pyv{~&
zjA?uNI|Lj}wp_}N?LCGJUr(D{#-+11J``~#CUJ#BIBSJAI6~OSDhzJjM~?@TB(>A4
zo-_vCB`#Zq9K03!BwjvhePz*SA0c6+fqO7p)Wc6Y+~J0?^q2ZS?vzRkX3cA7k6O4d
z4}5WWTr78piIxXGaHR25?A)wF0y(#nsC<|cboDlq=4c9pS_@~$BNj-_w}*bUS@t6Q
zkjxp?cJJqk3S<qHWMZ69ah2tDB8YwWOoLJr#bWCzb?RDud)~7<W3UM*w$01rd2jGF
z-wB9@HD>Ix*AKrlbV|!@CKwxoJyEx0AU|%ICG#4-l>!Qa?>;FKz`1Bk9t)iGHHv7$
zH%s<Dc5Q{R+*GN-nI>yn#?pR0Cx_#I_;Jh-;qLb0>-l!Z(fY^|>M`<}nE4!^&@th7
z`Y-i$sq|b!rB&4MuzjM1OT|?4S3?KAOR*XE>oFv@aaT6IX_l8|R0X45kIBu%C{u2Z
z;+o>s=e{z;HUi}PT_|2uV90kza9wn5J?Y5T<|bF9Pyx)+v{X+)FXQPJjF4^b`bLq$
z6T4l&)|4I~fng*X9@XifybQ0AYvF&O0^)S;Hj}S0!ldoV|8t>1F}tX#ta6O%%;Wrv
zfT9S94IBVJkAvfFfAq0$Y{^a#85<sBX!TkXlVdV&yIC&7OCWoRY&7sJc4xceVuOL>
z>0-eiQDM6nX8Q$ny)<1B6Hlv373E3uC6b9s+Nc!>HyR7eTD>Aet%1bku8^Y`)?%KL
z&7rEUk0IeLW{~m)6@Hbd6`Nc8)$8ypD&FR;L58Sg`n-&x2nmnNMI)@@Zod`Z_J%~2
zqpj_w9r{wGL%C^e#li*Hm-vmO1~g$O2hDGe2RMPg9w{vr4PYHweA;<<$|)}{{eE+r
z0i`BJobP^Sq$w;$j8Aqnq5XQ0xX`BVLAx>^+SJEFr!ANO7J2o>zVhG3Dugz~zq-l?
z0II4V-U}(~K3=ISz{G?(9B4RMs0?@<S8M<yI=r<6j8II7xRG;+z<}|-cSh^T%G_=a
zckWc>S5fB$YfeBymN#wdH9ixk;9GI7@VKe8w6Dc{@F7qVyqY7ysEDWzi9j(<#SXy|
zF-IC45V?!Z52uW|(6E;<PA+i&>()@G|HQ_hqz?HwAzReP<tH0C<Qkj;AU_1%rB?cU
z>);IaD%sp@-|bz&O0!~5>u{-ZIT#)YN>h_`I~Qj`<zk3c-Ys0930P_l*LL5ymW45F
z|E5hcBZXOt{Z*t7qDhSS(W5X)(N>pru*)&4cW*qJxT2;uqb;L!x8*-q;E<-zaFV+E
zoZjhh&Cz*0yhCm|Fu?tN>ew~!+IFH(gYptD&C#3(ycstteX_<rHg#`n817OcgEUV6
zY<TeVnB*8#85{nYdd%SvvNUudUe{Ztwqv7?&U~N(zz<g&8^<qKruE9s+E+fE>fFp-
z%aE=fDN_VVSHINgI8QP+7_Koc5GY;8*cn}}`i5y>NiTc!&^|LUws@DnRkJ1TNiZ_j
zg18OEFt-cqPE2C)^XIYH*nLIL@(gjSJDvQwSaEVdzRYJ-&(lO=y~mAKI2$y}%N5g+
z!`icJx`HSBaD&RRN23oWvn}Z-Wvf>;Bg<3!NUv}AmXM{GTgS@8$)~bp>+!KM5Zw{L
zfqXnNq!eG!0pLsl8t+tri>tGf>s}x2yW!kV)V}0x-sQFpr@|b`;pdw3q|x_y4w$T7
z6lHps`xiX=3G<h|kQK2y+$(ATTm9Cvx51`VPz}})Q&7WjY)nqtkJP(h$`+r(yA{EB
zr|he{x4p}YMHY7I*1(<1UTnQhfcIv9trFU6dJCToE)$v`p0ZrKG>h!pL#2O*gR}QE
zEzp7Mg>qv!=TIF(NO1W2$e#pup;h1R8pxaj6;zVJT@$=IA}SCrLVV<QH?b_@`7vO#
zdvGx4vdoZwxRlcLTCj3P2ly5&s?$>CX!O%$vJvYvuVd}JU)o)T-Z8;}3M{U}Y!6pQ
zre;x=R&1MGU`DAwN=!F5SAGy@Fayn3;v5>8WA;>O%=9u?ySXMvDAjW#*a*-Eaaj)3
zYg}+@NOmfe)1QpnNYdPT?b96dvW-1y62Tp+G&?c^QLXCk`{jpSOiCt0@f~X#RIZSH
z>jyhW^6MbGt^n^~TCMwuMZZ}5sC-^-pOlRNc!w`>Uy&%GUY+%S$?Zc4)nMx#W?QO1
zQ{D^?{8A9q_^w~Hg-qXJsVrR&Q1?CAEJ`fNW7(NEU|I?F;xt)+1N6&<nQ3;8D&>ke
z&)Hm+HHyfnywZMP8azfB=~(g<zRs;`*M{z|tyNp&3fE)K8Bs5YQb=R%@gl155R06H
zVzZ4);Zk3~F^$4kcPFYP)%vE{e*N0<o`6T~$9XCXS4Am@HU(-@YSq*!)Re7fvZH_-
zWReZpAk$grYaTCs5qS$!%RN1Y^^3`3sTw)_>J0$_2L^zS9tA?!WumR~yEapwt6iJk
zDyCgKd-};`P4lJQy?-}+GPrl%;@09H?aK9%@R^X&({e#@SeS^nxI$B`jq%ERQg&lv
zr<cpo!qWSkk3!{bkoddN6gJ0|aD<}I!m_~&<)Z3fL>syu2j(fELmF<)d-mgFqGjr>
zxL};2*7x@T;zP*}2wOTWH%%e^AV%!G0^-h?TxZZ)<wV`?jMzGHyccIJXJr$ac?T{O
zkN$%jE>aB&MFCFBiC~hcyIH0><pb!A&B`iYgN%iPP_^#fyB|(_L`8^u8tqGCe)&`{
zN}>p}PvDiQN!rfPLp!Imw`jc!G<RpaW4!}7j}lOToPYpT5Im9-zzqiv?Nt~v1AIp0
z1b&qJON)$05%y=u+;)pRrbnk<KR+$tqfgLSZRVnwtm9y&CSKYWcmyOk*1SBPv+tRY
zvz?saNRl;kJ>bmVb~=b(pWQ+NwJ9!=GeB!0bNd>K?sx{Lah=NPmkL2t#;Xs*op*3z
z>0DQtqxC)uRog3`ZCW80UMpOe=5=KT<*L?4GW-q91+ym)2hZ#TKLjrATJfN^`mtS_
zOeK8oVgp&c=9+d6jX(0Z)-E90PK-*O<?5{pH24%E;ZDs<^@OoLcYYF$@Md!UdJk+L
z(Oxe!v-KJ8&w+G7ES-#_Ln=5b7pXna+M~~~F&fJ40@G|$_<}`^Il(bu&NR<YbV<B&
z3ijvZK$`L*Avb&A#{4{uUEZnog#SE`Tuo=<s`|1fdBb0SB!T_iLmz8!-!d8Uys5MU
z%`nF6HH)b2CJ$Q%3`ZuJx6x%rNA)F^hkcQFc2-|=rpV&9(wvYH<hTpq7%h~S#Z9h~
zO%|H6cu^?)!tN1mR_yU6XIzHWCS!85)_DxtOOJ1k!5SaIJvA|^#_y@g0Jg5EA#F_E
zcOm=jY?%62FpIO4Ly=n+*n1kD9okC9I|_xS4ZEz6)sPcAXGwo|AZD1XnU(URo4kwe
zZFhh#Pvbs@i6;L;qj}C~_eTEb&~5_|JwRW8^O5ku^(3h%X3lJq0jZKf;=>%ni`Ot~
zJ-+>uIysBiFXMsYVvU8o&Cn(Tphlx=H^a}n^?opWjCMJ(&M0Xb$kJM!d%PdNDf%L^
zq~0kX?<v946bP+2%-PCOm>|Vg9YAKW%p{S%GywvKq+KK6s(jA9LO{5TJAqoG*-7(0
zp5FdH?7ekRn^E^J8fXhOpg?hJgL`p@7J`-HR=l`taSK%(io1KUqQNQd?i$=e&|ra(
zlYZxS&zvhWcg~%;f8Cp5@+M^a+IzpxyPmbzvi5%X-A}=LD&@Mwbp^`j9hh((oj%6>
zIC;@ajr%VE@W<b&5Y9X$CA^k%EcnUQOg%XHUC@4;n`WxfD&MeP>NUYLVMrFAK!x)5
zYiBWKKTBa}G3db;0)htcK2uRpjiSgA%6diWFT!D*7G;cb7^9P%oca>LBvUmgN@9Cx
zPj|fZ;*YaQNwp<9$2l3>vEt$+s3ROA3cnX9c}p?vyhlDIo<WKIV3cW_<pB;Jh4a(e
zl$epXpJxtVN>(povxgB}P}iPSqNaMIvRBdYwQnh|S>MsFc3tm^y<Wcduom%j;`FV$
zL#aEXY$%km=(E-4kJVVIAD1wZ5GGa)E-dQUB<ug%123MDa!7pSv43D=>dfXrUmx_1
zs^E2jN1b*9W|m#dTOXuK%jo}|SdO%;lP%N3oAE04<jJYvS`QeU!Hpxj1bK3@V*@I&
zcs!D?^_z=zb5=EsGn)b@zPi$Bp{J(y`bx}`jwsz<e%zWF&-ha@Q`vVMB&+V|2kwgH
z45jF6OTLt63R^W1-EB_A0T5JHN$~J~9)l>MLnwtS2jc~eO@0}4ULx3WD+w+(RqZ|+
zo4nH27B8t(0{v>ne)o<G_C=D0J&D~K<W9XjW%3&rO!ES}^Upp5;5ylN$KTd&($vQr
z+D0e|(5QKjjC_8kg%#un`rB5HJ7RRfHDM~rh9S|tpcb$#(}w10XYXlQ<)UzmqmO+N
zC+pE}Pi}XD@VW?M9$y!`gNyVn26P}jjlILhF9T7)iy)!iRTH+D=4a`z?37<St9UC6
z^)EltdBL8Uef*>=*3@)=;~B>b2A-xrI8(20c0N~Pj`iw0E@*HI)n5=t$Ma0Su?YsX
zKYUXtocSho(jrJFLS-#NI?`5D1E)qP%dcEt!J2ucPxI&2+0_pPJ!|uxj2=FEBQ7uh
zcQ1M#+uX{wJT%rUKhZScxl#!%`xWC8YWT)o|6MIa$M47e`IA<@ANR&UI+g<j&<+nl
zdXt#&MUW5UD!n3g#4NeJ&f$yBVyj!_Q7iUKARfT!!79t$*=luX!>_nrMlge+26q7I
z-|Fwf>dsg}%k1f#8V^{8)SGcYq*huVUMKj?ppDr-ryiqE6FUU}a`X|*Sh_4ugEGsM
znJa_eQVM@mg}1{NJFo9SxXz1};267AmPq48%xsGMGuGewmsBs`rCQ~Y&EDnj%-hDM
za^r!Ii8(HKoGlgtba_X0RDzz%Ke_RbJ_vu*`iTF^?C+n&(agCKI+N9AH>JH<*_uS!
zVH!`TaQiKm<+IIceT*jM=kfPC-S*Q}0|yTAqLcdhDML0BJd2ixf8Oe)+kY5t#iDNq
z1Z5nYi3k*0IXi8scnoj!@Wg0aM_F3tKX3|0w|%5oOH9b5rBvquxaa~Bn3p({l>PZj
z_WLwH4`xJutv%r1ce_~sribPF04T0}iia((O;YOnJ0B-}UNT`_;Bewd!~H70b4nH}
zdG|qOyrX-hs}vvb_2tRoR(n8eqA|lngVVY)W>=9?pG)MvAa-7+Skf4;-&R6_&Tng8
z0mS=$oThrV$Z0Q}<BTVAI~ptu)f(1YJoJC)NM5<_-NsqT)5lY^5H@#0%{-l0NN*V=
z`>E~)sf*Bo*a>BVx^pJ(*i&ipN?ZDP+ebO&+Q)Q3DlY;aIpVfWtB$84p_j88022GX
zzxH<z%iF56j6P>q%4Uy5IN+p~TGfyzD&qovYC2q2wjYU{sI`Y;48N2Qea>er;|e)b
zPwYM%K}-<E!n*p#H*dF-u}CtCx=keCEo6Rc=O`vMCNR2<5a48)ZKpF|CXPi6AVWVB
zXQn6I44kE@cl@-r&a4(&u`IIRF82ngC40w(X`Rd2A|?foNNukriHRsQQ#!F<9w}ZI
zIBA|xHMDj%UzViaer=k8GIk@-aqVL=>roj)rDScibyPxs*w@@X7}YYr#)_0c;|2-6
zvD9KP?8M^G|MQqdW)n_g$xN2(qAKxz=D**}%4f19+$#1>x|YCWXOCExKA%K~Ny}*+
zeHpSEyS3;n6Ote06l?s$vA+~HfA$NxeYP=t&<Y0Z+v?Ha;DwP({6$m_Wxw0s*TZLO
zka{gkBiQeJ^5=x`+Y(-Ri!5<(L|!l-%4`Ia;}^>agzOw?rV#JJB4pyw2LJd7<abV)
zQ*H8l><xGuyVYgr7UN3602Rix`sD>6w>)^v#WNAk_>oh^XsS#gaOBI^a=-9KO5LhC
zO2N76lr~IA4Zdpp+6Bo=(j7Ds4PWu|*Sg5KMqgR*^1T+qUgv%BAch5pP=O}fkTj%P
z4)V5izG6)$$4=I0yxyj{_xL_&<?G5*I3!#9#;!o0yEcgI@3w~0Q@lc^j$h;y()9E^
z<c}MFS;RJu9Y-rN#ihgz;1TuvNYIHd@@3r^u4eI>@3dG;?xshVGBVj7Ar0gS&b&oT
z(P4j>Zzgi@I0${VPQ6gjj(kq<PKYZM1)(01WUE`CB1m8Q{OQ|*t|-HK+pY6{$45y5
zNq4{d3ICFj(M99L`T&{6<B$>2v&<e<!>A{hfeo*1G1easfM@;RxOLvU4R1A<$sULG
zryf@tU9ER;c}|x9>TG985?@rh4MW^Z)VK@;aFfyyxjKofwe9}>SshaYYN|SFNvhP{
ziM=%$mKqO4<QdTg*zE+|96P;;DT7;<ED6o#uh2IcZ8#VRPkvjVxQG?CH(i*3@94)Q
zZy6N2qZi9EDA;0s(BE*4hX=Wm{4U$QSKz7_mqt7c%622bv%hhE@`J0KxXmcCJRvj*
z;$C@vAHlsI5D$(Ms^(M()oaM#7L~Hpq#Y5mzPZe4KbyYwyY}Km<hw%Znz+omm%Hn^
zp^>3T-i!&y^4VVZz|S*mMW*V@B`g{04l{|GDls-yi5XHJgG5=p%sqt{CTMvvcbl_r
zHl-ZbW#LnAw&4PqI3`bt!(4hs^N88+TUrycp;P)sR-v>DlXoulmS@7BJCjd|2-S6+
zLaBTL=9*=7U7~did7-!Kaa9}27lH!5!pL?F@$>mw=HNDc%)m8%wgdv{HRH&vBx@SB
z`I}*8mT;vp@v9AK`&HVSIytilo*KR^AD2N7M>?h)jO#j$$;sW)XXQS@!*$!a;R(|b
z&9rH#@$Xz*_IvK#NBDD!!O@cE-9O7LSjX7uMAj>c5<igVLVpQp*$qZfYI0A}K1Sz$
zpF`PjpR!NhUJZBJ_R2)JSp=f+ssvLtt)*fTPSbFY5A+$5)-LpgE%$Pmjd|NAd698?
zDO7YO+_Q3ouENyF(F*DFJsF6&F_rzu0{w<CAI5#?*s$?=zX+_6l8`W127%-nR#_Kl
zvUlz6&0CVSu<PwS;y|Y?Uj$!qrhBekJg=H{@UJ^7FrfSwV0EN<Bhxx_<$hVr?FdxP
zRX;0S!0soxXX<><zK2Tta|;$~LV5i?&WVH>8#c=iezs6JE0aHNZ@mad7SX0A3Lqk@
zjr{BkuHGJO{21eCv)DJ0mF>C?6~ZAYEG*F0nvS5zV&N6f{%GolsJ)@vP6YX=h~&we
zNCj*t7;S&~W=WQz{*9h3IvJ&ljz@^>@9&p1`lze#@P>}-6ElxyB<4>$?#U3wB&S(h
z(3OU8Nt9m9FB7Vd67KU^MVv@jrt^s15-TBgt!shxIjmEKURQDxd*2I%lmt}L(cZt-
ziA<!ibSo7IopIYa4WFdK1&HN_4_(g}7Z+(Ea4&1ns0auocfg2<w#idy%-iPTEkSyQ
z3!LkZ8Ju&A!{3L72!jSOu77gL6lay@&>!3v!Ct|z_kY_^n@|yJkR1)L26yjJBQ9on
zX0)XmMO?bI04JBOK12%JsqpJlnKLuME~*634KP|L+}j+V*8e#67^~-6RXAUrL62K5
zW-}^rim%ywdqFOSH&_AY^xSrJ;4pqu1hLd7)WQz5H}Utn^e}40wz)?0OXHpeixylk
z!cLnz(QJDKrGCb)8xr@GZ+%h0N=@fpdAML)r)IbywCfu#flgSwm_<mx$Lr&&)x$3*
z2P;H*j$jEILP*FA=c#^)dwA7FV^n?V%ErsksrL~f%K0k$Qvt;~2w?qeGc%*jl5xo2
z3TZmz&7v>J9q78~S(&Gu-@!=;Jk<|v$``W+kn>t7aQnT&3eqnY!D{&G?m`G7ZIy%`
z{hqtJEgF*-M<D2#2M0$52J=)$cvXgk5rb4zmx<vDXIqcjmk@b@fx!r0go+i}@6%t?
z@#TU3elgl+8hlVc*0q=8fy*SiH>EC&k3RsAVx-UCwyFX?Vn572c6TSV&r&`%qM?H)
zsX~vl+UR)v28rd*b;E_DorP05<PGNJidN6}%uz&R1uInR)@0oi^9{%fygE+nC(nKM
zLgl#~-=G@kDpn`364uB7#gEznhEML=W7!WjC?l}Sj;~aq(eo_TR$%3cONSD1u2H#A
zo&zR}W%OP=qdDS#lxn!J-T)iD*l>t{T|%MC;bZ05JT~>O(YKgJH^A#>+9JQ<3SCq%
zzx{$t1T?BBSoD`S7@8<<37E38ka)JDl_<b(i<3&Ug_xG|K2_*5VEhl{X>6s-Py?%g
z1HStQ)mNpUIqO}6q{;?SYTddw%v*rgx!Z?pY|Rx1g}TO1IhQZiVe9M;zNoy4OXzm0
z1Tp!6rCmV-E|=*Wz__1W46AQSVbYTaM|<rCHRsx!d*HQ{LgyP?!xW?-mP^J9TcRZN
zX!y*A=xdFYwozTowW3n`scNV~iF8)t^0VD;4{5_)eRkm<kN1W}ApMFF|6No#HjEts
z{as$j-CrO0_4egl=xk?p#b_uD)cj29)_O%!YkQ#HV@XuUru0v9DT?dqLYL`REQ}5L
zQ=2(VDA&zivNDr>Ag)JUy;9&Ua%>ZB4Mo=6q(PHem6;`dk0E|%Y*c91Ps?@YvPmpJ
zvM~oRx{Kh7PRtKkBV&%66;8>k2TCV%TV1#bZYRm2k!m>jw6HI$iDvvWCv-*4Q7)#5
zT#yY7QKn6(Wd=iQ8-7F3kiFv{bj+~!2pZR#5Qn8EtDR{uVazjT6Q3(^G&KhYw-6m=
zl3FDdb&FQ7$>;O>tRlI&mYeo0B+|A_^d5OXc7}~yzB?Gx#1(Q{GEmd^Uu#mYYMSQ(
zZaA=rULT=v-?Ud>Ze{f`;mzPvk_f}VTKqUae+w^+ECovHm|P(5f#{F#h@VI3R0T`i
z-0FL(@6jF!C*S*`FBp@WeY`&qI9Ia(1=GsgtpNbQt8X|SHz&;x0<NFE&8PP2&nXsj
z^7|ASawv*$ayko(z@6P<s+>=%>C@fr$y0%q!^p({6uMq6j)3pGb+32UquJW3&a#e7
zYIbuw;oH1zH6K7ncc!y=`=9+8k9EdU1JSAPQtVB{^$*!a7W8kx_$2b2hRthV1Uzcy
zoFxyQ!$(YNx?h8Tr|rP3&to>EjMJ}F;kO*FLw+;+Xm@mKnDZTCBt4+5(<u1rWq!r5
z_a|lbgFz$t%SR)kELuGSiNaee;WgNOPcyQ!%m@OX`Za8R!gMQ}C?J4hyuj8xSg}=e
zOW~#w-Bf^aH+MXz;(5QJJVXNox*fMh=lis~h)QMg>zu!ZaWbEc=}KL}^SzY=+!h<U
z8arsBP6b2z@s50><@_O8tygJ6cvI79y?b=e8*OC+5L*;Gb*ypLX}uqA`WkS1rpTG5
z{glg5A$Nyq#KE=)&Q8!>ufqJu*=ZB-W=K)g?CpEEp)u4PTv4V#a+^xg{^{t-RNyRa
z<wK0@^uTxbRnpA!IyK*D{a;?W$ai4+@RkuNibYOTa2jyB%5c^x2A)vN*WCKrY{{yU
zyFDXCeS=`X?f=WYn*rpBp)67`i)X5pfx1?*yF4!MVg=Iv=voZEzmOk8U1;4^eB1vi
z#hol>B*%?UW@lj_6&665*K$9f@1gOHUO*-0yMl7uWZ455?R1B|k2%EgqrNA&#7)6s
zPjN8qV4IkG^7bzwVomHA{K1->$*E}eqONjJ_cl7J!BMGKpvt#V4H<_186w);s&B1O
zD-<v@^7`vY6h~&Wi$lrn#8rF4^-!zS%@`fmkr}4u#lv0qpD~_(bqenGdbKOM^X^>P
zYK=a)aq!-&Q<{qxRs>$9U`)Nw#ZjIV<5inZbK7VrRcbY{>izGNZ&KG!?SDd>fcF7$
zo7r2(FDRJsM1Z{B$@}4BCS<o&v2no(x05O^v-f(3eWEmoIxqCcz>OLEwCIY6)tiKf
zgYB0pf%h@<(HVDl7wd9yl@^G31JyvJUlkqu4dN=VZ<SIKGp#)BzpneKEq6&QIb&Kv
z{swtX7F7R(MTvLEc~z|c+Q+z{!y6_A9)nO?E~Fn@v|j1AbfgL%XR^ka++Stk-|s%C
zX%84`Z*A}@swzHditv+NqF&su_6xiVUjdIdj^6iGr#%RMJnytHK6<@BM$m3A?%%Nb
z#%|RSO(-bc6S(L|hG*Qen*kXVU>#~}1$A=)m3Z4w8@JygvUat5$NcV=D1amHl(8`)
zE8F-8XC{Ah`bUE0Xg%ud{t^VU{{fK7S*uUxb0bw<A?e&ytdseC@qP%I)+6;*tF$?G
zpl{?(c*w`{IluC`#TPm3WL?5u-`?ewOh31K0mn0w$O%<+6?*7lKi;pWTq^^V^PzkY
zeByj7gd=M+I+#tVy!E0IMrrGG<}DVcR+aS^PQop5iZnM+dH*53LEblw+L(|qL!n&q
zAl)FT%tKDhq2kxhmmD?~9oMqII$tJ!9=~%X@OnAC?c-&n*MM<x4Il^jf|=JOl>xw|
zEDy@pM6Wj-CB|k<`gC&%C+cVC!fZf>uO+T+WkKC5ZC}A+f5zvu$Fqs*LpLtNk}|z-
zVxXX(?%Qec%%4gE)Q0cXNSK!<8orc&#m1kK*`viL9uAVn#*7J0&?++^py?sY-uz0Q
zyY%n&D4|bFEAI%1>c1+Lyt(VBV0Vy$Lzr25iA77YMV$(Y?&9D!%Tb;9P#MU-n~L2w
zsaJwc<m(?ZK;UBc?D6w}o_lGqVu4LCq;#r)2L^KJ_=bG?piX=5Ri;zKM+#o~gacS9
z0FPW1eXCmF!HEX|{GA!H8yFg5AG=<?!X8|{C|Jl!TLHS6r%DFiQA2qk<+*?UtVM(f
z2KZ{k^B94aX9v@xpIUP?$Uw`@-AW7gLK;U4)BLQP>CbZ0zoxQ5Y%cC&BNCqup1Lbt
zR?x$Di;Woo67Ctznc;g6070c0<<%_5{%#5JxTLdLtfTea1tVD%Bm<*24D^KzlD5?$
zTcnAyX-DH>Tcn3WAAfNHi=IA1*iJQhA-LUyo8MS1LNtgG@3s?^N2eo1c%JaQ+otK6
z;?zd9mR3^#Tb-pe@@N3y6M#k3Ih{v>wfN7xA&=|X^(jv*B|R~7G`AomA6HvB6Oo^+
zsK}$OOiSoGt@r-7`J|@&cbX2Sqw@_(XnlR3ksik30g+v7ZNfY44E$goIs54_w8^#i
zqN{FLgF&Ag1d3m#!+i9f&>nnzecz2a1quKhBuM&vm(2fjV5W&27lzjJysl^{96-k#
zQ<uw6A8mZiokldOyBRMpdRjla7WvKY_L)O~$0;WMAuL&s4<rTjgDh;u91@I7)^`^D
znA)7)ch4!J_#WDKd~!rzh^Xqp9BYX7&_F(RRdNm07N1p&BihuozCHLjwv`$VD_3#U
za5p+wrXWgS_zn6uwX%(U3#5w_KESFoi&@HR>I}(*s@rnamUF|YY|F*9k3I~K>$`bn
z#e~$?U}GoHvj6GMkIs^0lJ0h>uo-0kkd~2B&yr_1mo-Uh$r1rWU@X+1DLK$W{3g4L
zlcy=#0AgXx<03^bXPFtHG4Az)zKFfxiMg@&r;fXU-tu-z87(zkal2#WTpEV%y-3B=
ztwuKGf9Mqhgz#-2B#uWYWn~(z4R9eMlvKGn_@Ul4C4c^Km@WEeu+l^R5-rXey1F8}
z^W#}4h#9A*A_@}7Wc5ieA6A^$^7-qyejo5&y30A|i`HVAN!b1o&D@_~o6qB$lK67!
zRcxR+%=0fJp>ukCIwhlduEph6KKH0Vi2mube`5N&w~Sw^Lq`vEN>c{9w@nW87Uw_W
z1Az>TT|Op>n}eoLnZ~?g%|KhIyr<BiC5hM<Gj7RQFAD1XL@6%BC=@x{74|H@vocyA
zS3N3O-*`e)NoLzBuC`VW4IyupBJar})XH@R|3jCAt{Fsgtb|1&e4myo^$nRpzn6q+
zLtx(<+76`Gb!lE^61mntd|~wp)2NwnTG5uA!cK^ht`T9<c)f;{I(w)YCkvaZkn$Og
zF{~%YODtY2>`jBCN1HMP6W{82#&bj0kIS69Px};&;yhi7PTj+obXFoi;Z#VX9(_88
zaj#$yV{_wf#?e6!^aEjx(GA{4h4J0U%gyd!5GYl}zxL{i5s#j^HzTcm?OkY_F^DVO
z-xBO3TOf8%+0`ifxlle@Z&`i4hi~bMhV_0h(`Gu;K-g<?%^t1%4}W^Xq1x~!tJ8?r
zVDY>CO{qI&`3IN{sW_^+dgbRV3vj@8zd)8wIhvSIMB70{F^g_~!(Xq8kH_)DS7Q(`
zcWLzLW4Pb{Nv-iSdYgOa+7>UEShF|0f%8#OFD9g6LU42uj6=4kBrc9oT364G)`1!d
zZEk}iY_Zigeo4(Jr+J{K%}E5(uF3>ej8k0OOR{r!deBC#PPrld6*9+}3dU77z40rJ
zeHkLhE3Qk?vRfF`huQCT9)-Gs>!zI~n>M9-736<#(|SZTc%Z(jyMj@DHyA*<0KPwg
zg0@Dw=rZWgn_`8l*M03YtghgLaFFXivDFQ%I+7B`theDoEq$1ndZ?>Lq)ybULO{xy
z;8vcs&O4_*o*J=$z@em~xwJxSum%fo)9M2OTwFpzK!}@d(2$8x-+rUJaq5nF1z-2M
z)#M?9UL;ZYoWkq7q}@jP0xRd{&+wv=6P0>;IUOqH#OUFTTEXsu(c}y^yP3INz_NXl
zZF1o%zZ^Qdf2>W!HM#J9hX;vkFt#nM5qQ+@WJ`X4yseANX!o9S3l0gHmRHR*HBRI8
zska@D2S@m+iAU0qtoj|(+pcn_kB%`%&WMjMTHoIs;6YX1PfrsFt!QZwIsK=jr$&*?
z<pDW54D<p!{)5lU70hlu5KiTi0UZwLo96o(Y@&ptM~THrH#KnwD~iC_Y{%w}@$?>w
zunq=U#f`goQLnIyfMC-N!U9PW$nLVpTyeqyL!2gq3Oi4(aX<#(d8oUvZ1*N%%<IK^
z$1J88velb#6<`LCY?;{q2LTEeop}o@xi-R`!UG$>@oI`NURF2#pD?H9({$hy4Cd??
zn21@&#cY3SROWp`r!+Z;c)@%{v-u@}d?@IL)?+>!t-i6S$6{)q*n1qIa%Mu#`r@xH
zJh0dHKQ+(%@8P74r^V^=4|AoJ=r(jukI4~g0DSM_D*vN>5$xXWXuw+$Iy3ZRQa95M
zu4xU?g*^|&!z=0{!0c~;=ia)r0f649W}_rD*x6=KMf|3;li+@h-5<Upm6+vyvAC1R
zp63<FnAiDo_IbO9?A<L>-@5_mYu*o(ZXk=3KZ+*)_lfh-G-yQL$%9aZ+o6a5@Y4fj
zIyCm1*LRn(5jSa9_`HFcy0&jtkz-I|*U%8pUR7}5wbAB!*TqlubEjJZ6XhO^Pm8v=
zi&gtm9Q(x<zd}&p4HPVTokcKwpVUau(s1l(K4ERX>u(~7woU#5vY3L=l?Miqyu(yQ
z{)gYV64Do``cHLaYBL8js6AypLcUpw0V<2iG|Ed&!)Ui1>wQ{*ye!h6b#P{EfWh8I
za|)m1in^p*<<4b6WwWr>S$oHj@q}>G^yZH264tqhs!&6FDb#qW6efBM)SdrVNWAT)
zra@jOV9KE~<&BwDblTkP?B&&SOam<Xf4y!!%uxknHH;b^KW&B+g}N;|zi8I&o<%y;
z^oe~){Tc2po7zb#+Oqo6>sw{{Dx91fKdJxA71;Sb9k1`!*4-VNM%*FFUHn(b@{1QF
zm@?m-U^a}kgU)*S{jE<B4d<{Q_Z2PWOD2VAo3R`(;uZO!yj_V}m$ndz;kVSN2N)3X
z35LN+7p?LdKo#`bZDeYHjDDY5@W{k1Ek+(erL%uk0jc7v6O;Lbrwu>yz{MjeIJ?i7
zsZ9iwl!c%u%hr#0NtDoYDGtkvicRR`Rf7lsV3adqgYXRibtia83`_Ez5Cir<RlRt#
z7NB>0r{2~zi$VjCr+X$K%t;KS*)aexJqWvKT5)P#ae6~Oo${a<h=p;7x~;LRjln~}
zZ#Z~Ohs`*EY%}A^xy@5yYJ5zL$I*vxBR}J4ZG6y#q#<r6qyT`VG)%BPyE;2#?EFdF
z2X<<X$E!w?!bn^|u{;R$@Cg8bQH;<5ve_sjG3gLqFHw2APl5!28u`0IL^#L@U2z;o
zcd)$c_68;u;9_q^@$ad67ZuziCMLZqm_1|3GFpHElTEjn9lmE$2kpZ^{baekQ{S0u
zBhSh}EOH95*-ek8Wx>i$WsfiHUv<T~bZh!x)D&X%?dFX{Mz;R|+nO6}h8sXRVVGqj
zYArFf)nN141O1i$@3wVFM3ewSL<B`1VVf>~@4x=AO)uR7Z1@R#=i~1)9|bx6YdyeY
zL+(=$rO|*qIvpdrJu1xmTh5BDJTL&@(inq5XPy7aib37aKjJvLJo#5?&_m2jcY1Gg
zMJN34>$Oj-u}3E0RXXMj<|p=E7~NRSlA&?q@2Go`C**)}++`=BCxD<YOd>kBrOu!`
zXv<(rjgD?!o^?h<=!~Gy<(nYB$Ri9bwIXzj3&>V+f-L=$iNu`+H9*Vvls>!J&ffl3
z?B5PS@gJq(8a3u4;H|8}zYBom^}j_9(E9!_0YHrqV|Dg_`y<eAVHI{E2sYZU7Hoze
zv}W*DSm=L~<h2^lR+o#En}Swh%0Ng(&cWb5_LY!Pe>Q2V*D-|DM(cxH7rs5)rwtNM
zZ0D4?R}1Ru>QEB@R>^;F+TILNcH!VTQO?9(Ej4O0tYE^1U$h)#lgc)B<;8(XhN{HO
zk<tmuoT<yJmqDYld$kpE_F#ET7sk=P34jJTe%o!I_Pe|Zm(-`2fp#Hzg~{|*`+uRU
z`C~+YB4MR&AJOb=jdaEh4gwYt&e7P}RK|cNDs1`ZG)=f2EQ0&KQeT?4pU$Zl>rTAH
zR56_&O$3l{jlaA8F-4VimE@0FJboW|C*3n!ejkhZ5BJUKv$j-5slXiWE9te69GR<E
z<ULGA$Gbz&`wH$NC>6~QUlL{0pwC-%cQDsSj}kV7xuV2f)73B}1PwMIsEv3*sA~@w
zM)}i7*W@(XK8=lWk!4a#9g(1!zYg+<J<r|4QPT9Vl&!Iv_ds?u`GWbZOF~rK=Wr0y
z45O7Gko#N+$V=nsw%16=IK4;~CzPwP&aF<ET^8gn7Xu<JA=qPa5o_qyn_Nr_InpOI
zviE6JXjNzdhal^(aUYT4^o~=$6&sz>CfV&3RRR&oTE8TWdGD$d&ZXWx-+_NQ!h#91
z_P+e(=CO^&AYnb7!s}^TRjj0*gGYL8k=B?Xo3IO0HV0AfKkPJuv}pJjXiJ(dD}E8V
z`BuplKF-DX3O*L#EgdZH;oBD8!yRWGn(MwEV%cxXa!dP~Dug2}aaS;GSP3zY(5Q{D
zIs>rF>7MztzV;8v-TttcEO3Su+AfPZK?nqn4lW91ig`(c-03TvDUsib^a*4VhLkXp
z0Od#AM3vliY5wd-R;ezNnWpcHUKr1a;T{}B0!P2+%+Md-I&}*`!c>@5tc&7=V=klz
zA<8C!AL%O&s-P+q{JVsNuKxErJz}!TBcb1b?3H@Fm^uT&cZoElty)nxS7P*)DN_}B
z$k<AgYa^pb9#fm`Vz9~U)6EB2cN-9}m!P8JY{xoeggV9+p+$#ALMrFxs5Up*<xwuS
z-(BroK3)_g7?@N@SVvH5W%xrQ`eDZ}343(HPT5J><jHx})QTmtu({H5N7+9d=>)4*
z`ph|8I5LsxnP)!T&zT~`0_c)M8cJnBwV}YpATw}Id%i|(*V4?s#+3(9aDtKq^E_U<
zM(U;QLR=NvY}`%1_%NoJR=JipUp3*NIW8zzIfDZ@(-#KHueeSQ!5lhl25MZ{ehJYc
zBMa^SQ(}9M+^wytW4~ARs7YTA?ALV*+!fm~A0dRIQ!a0%#Pqg)`|oC)Y+nF9xJ1aV
zIN?`djfGc<aJsPmP%`|Fql%q;V<5Eqx9z*FxFr|}lsEOr|9mB<$?E2;^Dw5}u*j%t
zw54WScy~)B81@BEvE6vr@XUnSc<4g+{`XNKCdC|rTk6K__DgnPo4>jBOt*YQyRojo
zX-rtgF|LHzS&`I>n5|v3>K)Bz(AE(ASXb4^^6sK3wWPFd`QFq<i{!ZFbKnNsX62m7
z(UOaswb9Uve-l=hLo4Eqdv>;(pZFt0Lh7uC7(RI7CtS%Ny{PS;{z5)ep&+ET;&OnP
z&~>Yh7B!T|Et!1L8;kGvc;`i*RCf$>)Fv<z)k3wLkW{8f(1abt9^Tx>FXrWJdbHY!
zoWwlunUs|0zVUKaIa)O|uryVYu-{&9{ekZ#6n$TwnES0U*b6rcM=xIU7s^=u(y0b*
zax3Sv&>U48T|Im@(bm=cjNq87%D+~%%-Z+OOt$1q8Rp*hLQ#R1qsi2R(IiB;H2gh-
zZ@lZquc;=}8Ae9MjWTu-)+W;@15Y+CuMeU#lgp-j#=`mQxiW6pAX=b`G~xH|Ztu1n
zI&3!s)&~P(i;VI-1|P*dEBf6R%HQ-e)G%b_d}=;Li0OXJF~(IWWQC+;sxh~jKit(z
zCG3o!NrgOq(~h<AayOc>LDkQJ`KL<630YWw@&a+Lc%*BM{4Tmmv^efFGh2IA%fzQ!
zze9idQ@*0OMJXzKXVRFCk;pcv^l!<^yIy*8yrbUar9RT5@)kjc{IJ|XXL0`7H7Dx8
zy!xZUzV6kRh1xcEVL!qMf8xJ<X%}4-B)L{B?!ML-DPk2G8FPE2N>$?>7h()rZ7j0v
z8Lgcq5lgtu3f!H!JJV0e;CMDCdAc0eUQ$9r=;L|ZQDl&G6{0YjXD_>z_zhRa@3BtY
z=ewC*{B6A<drO-Lj&xGK?NDn5Pkk^v?9fP_x9zG`X_CPYBC@H{_5s_4q*O{X-7!=t
zP0ENpHsf4T?t`NLqy^ysCr7y8N)E{Y=X_GtD<hB!3F+Qc;eNBv9r%CK8hxG1))5rZ
z<lE_H=>9HPrA@k>p;{5^sY^UCQeIuKoGQv>3>s!km}$&P-ih8nvM5D*=$fb_xv*Y9
zn4Mxv*5?D4N|up>g&m)rNQ#(8E$sSNoW(ry8}&Av1aG46WkE$=O1GQuo0UKe(sLS4
zULG2&lhJeVTQ_LZWYpcn;^)fNTfHM!Wv7m{{;%=P%tPt&KpfR5n**CCYRzr|-={W7
zT<d#muMr8=UQbg~BQq~Y5Z}5t6Z#b*h4SSgAwKXddeAOmRWs8=2^ikBiHT)~&gN;D
zaj7f&(cJ7)+9Dy9)D}~NAH9_yi^)y*-oDGZ^nSYcpk43Q%+n_|M6WCsm3tGpCDCge
z&S=r2GIA<G;4pmEx*t9`b(VSO80a{p>D%gDr>gV}J(#63d&i&o5&d`ZFcFG3*=;vE
zTF-^qiu0hYuaOnhqC#Qa#*0Q1-w1-DQu8?n8)~bt-qNuP>V8NU7n|{-mh|y=RUAFc
z9{_61Y~846M1-_}r|E%FqDqP$!(S=rJ3V&{a_Ms;o%M1zE6S=xcA2I_biS%!yNgoy
zk~>Cdh^o7<3Y#NCR!r*ITLSMRK#oI;dF%UKQp=V?Kk5<XYEKOt^IK|5RJxfKg$aKk
zWEhceuwGC|2IzNHp-kZZs-T~$DL`OXQNGaDk<=!8%IZB;$N1*^l{c=&FYN33&~N-3
zqtA2u_K655@JM4$=d_K^!%GD4&^mf*nh?}LEL>J|xBvUhR4XN#CC@N{F{U@PO+KnJ
zN(td%nv3*@L33#XJA_}W&}(0m>f8=V%npXw<n`$<+*?>?bqur{QV>cQrbj)Vo6CUL
z?<H1nv3W8Aze$h{(Qm}bcEdPGR<2#jTi(;KykwIr7FN@B7ky;t$*gfaw%BqVse74p
zyut!>J`_EfuI<U0F$P;lAMb%JcH#&my>Cmok75tWP-9N>&8+qvj`#42i00h{U4MCW
z$(2Kc^*}AWayP!U+4ESWar>{BCh2`~TyJFGxiORvUS%yx$7G{ty(Z&T7oy4VzV-<`
zZQA1!>l2BWjEl^b&qS2XzNS6@`+|O#A3uIO4q4D_R1gzRFkJ__VFj_jpXn(?<hZsu
znoAqHD#xK&TZQ$>9yW$Q3)7g|l^gJJwO`60S=%kH=pU(??rxCPASyGr8hL>VIb5-d
zmamrL4_6pJE>MZqESh3Xw|W&T=>yu!8Y0BPJrT9H{BCMv^ElXxj;A1+lgrM<uPkm-
zKExnQscfT4B{iNrOLR%M&zEV=(9qe#E-n|Qu{-*!m_fZjvXyZD7gelm{z0h~Aw{~N
z90;eVAWY#xmy3|XP1Egq=iBZwJrJ))tgO%Tn(im-RTZhf4d?1>;I~Pukp3i02rR^J
zG==&_uTbwlt=0rFXe*pqFe9*K+s5j;9aX$RAXebk&QEjYe^JC&*(zaoBV(Fd9i0L0
z8owf@BCwO3$2_zDHb_h|8Wv$uz9IX(`sTyqQFV;#C>yEki?ss>nbAr+!M2?75~r_4
zn1Z&$`?CkmxoPh*__yb1?p82gWMI9?N5wZMUX$_8V)q*R-1<86UW;tvJ&#FnpFXea
z(|k+keb5$RV76Vt$O*<ek4j?I8In?;)dyd4%4~<;@?vLY6gopB%AeuZHdh-2zV6qb
z_YRljws#%c$8Emc^_r}98*`=u^KyGgFL}s*yMOdpe|8^iQ@8c<aAaiFNTY#!X`(4Y
z8&qcP_Utmi&D%?H;Y)y7sT%o;j^5=&M_04b)5`!evGdS&Ve2asN0LWbhwS~UMjKT9
z>$5wDqa^ZwwcDsKg1vS{m-StzwYR8;7YveXAPu~`pN7cH0WOTLVcoS{u+XqcWRk?*
zhTN>~OU&QFhMYdTYJwQCW^Ll~O5+#nM-SN~bkvCAGTr;`;>C8-h(GMKNZX=P_#M^d
z_Av9Ns828RcA%|ux%JU(b=Mc>B9F6$jSBWrPKC^}lLvqQqlu1eGjH=;yvy_1{((0z
z&<5|Uxfk`Z4rU%6`_O3KCSs~T!Q6vty}eb=y2s9*YxXD!Pq##m7evj38-Q{VT<~PE
zW$U)-0^=ew^x3b!+B}X+b0~XX)2T6)BjG*5iP7r?543MaL%Qi;09)Dl!DRqT7pajS
z8c3MrHxO-aETVr6Qx#}pqws*%5sVR?&f-S!2F|X<ono{e;A8n&^oWR!_jImxWfsx4
zqaJPEi+PVLF3I{+l9lY<jw@~oGvR<cGTb6@A$j*WZl)E~3>clG7Z;1%YAuI_=%*U`
zne2p)e8WM(k4Glx<xwXlGVNbfjcS^%b)7-NV=BI$2X$8~9&S_F@4&Zy=YM>Nb;bxJ
zE!*la`1WpvHiQ2x*z3j@mYuK>rOl!hq2`Kl*6|N(eR*R3Gfd%km8FQXBd*fwXkF%}
zSO+;fP_y?rTpGF_5AnQS4xmC{f!CswGM+(QW;Sm}>SB>;4@yn6?tcbO`8l>z;BZcy
zO5L#>A0``+8PSnhmekU+a-@Lem3&qg)(6h5pOdk2iJGJGz0a1{oP&lR{jiR;Dkz9>
z!LU3Dp|y7}17=x|!oKG}*Nm;OeATK`)?52DT*UUy-6Z2__=44kDf@!5?7u|T?*%Ai
z^NVXIb-X!x;wOesPXI~L^>Bp`y#=ac_xWm|US$lIa5oew1XWLl2>GTSmj!)m!_XTk
z>|CQpzv5po0*SJ$#9OXxQbW|)Cz0(PKgZaj6sQ9X;zwBJpAK0m7)!&F5bMHhBl42A
z3IoY;M3vWf7-qq{m4UJ6kSN9DAG6T8OU29>eey^|gw^i~+U)hZ1uI{b7;rk6k8T($
ziJWd+F>}65_;5ewXQ*F33McX#a$V1dN^k-vr^#!}y+o|V(-+rT)#-^!tNiqJ;a*xt
zahK&=y+2g<TAf<Ec24{2^0re=EIt~cIWRnWML$z;--^@A=q^6f+`^kAsJ*8xp0R2~
z-;ta5BDTHV^F>-g(aw{*Xnteo^wI^NDG<yE`pXKIpQJ<JDPYoa)8~5%5=oOd@>JgN
zxGX_Kr39LsL(hD18XcT;PXc+FL~+n=jRyQ?_LM~C%{O2tXE)A}NOxN*$JJlkqW7!M
zjaA+4ox}bMp#P6agVibwLLh@GKXN&uR8kl@PwZ*zt>;!+1I|f5&pPuR$7~tU!cMb2
zyZX1zqKPUoz6B|bGWb_aR`+p(ZXCKCr-;lEK;RQ%&HJ-$9<-({ah!ausv=WiBp=;s
z2LCEUE{SW}$TsmV7g0>?S!%=*^=Z?4LW;}-Nw+_2Jq!Ss9}|r<I^~jbpk=`{P_5xh
z*J>U%+m7di6NzNhvy5ZpgdQ#MGQf}aHP2`UP#yI?GsqU6sUn9`k<%EG|7t9ktl@S^
zYw&APFJEVfdEp0M$!Ff)J}-ARw-)1kk5=%1u{r&t+yE(;3rFl%M3#^nuH^%%$JARx
z53%2Gq*9^?9zbNfr?$dKl0qJ~R*JHb5k{}j(CawEG@T$qxgE6Jo+c350(C=`%2C_%
z)_2$hqnoLet*@78Awu;FY(S@&$4Pv~>Bcb)R;30Eqqca@2cX@sgb=yDPp%;$8;Vu5
z5Kv>90T7{J@h#xbd@Bv-n(l#eRf5?+Bp$#<@bblfkodUw4(KqMHPTw8Ry>NL#86cT
zlwJp%{HRB2pRV?K$D6xv22asrHZin+5k9tO9=YKXve}?ewkIZXVV9#GD<oCFo6yn&
zx$;M(?T$%kcuOASam&F*Y=w&YL)=Y#is%4e+C!P^qxpH5uIKji9|pYppb=oH*W%i8
z(b7X17ayNZM%XNWhMzfUR|ni6wROQi-X47zq{QXBck(ke?BS+2VM%F4h?0##Nmen5
ztAP|7n`+iACzP%`s0LdaM7~@v>ZtWK1Vd~QneJJvg>{*wb1kwEhQ>89!Pis{mPU8|
zwQQ7zlKCWa(#U{zeU7EGa*Un={a;E|$FN=yI>Xvkl%yeIZ2JxVU!9f1AvJ@mT+=bX
zm}nkRU$@f;JmDkUmtLw+ZdW?>66&OF2T~)iDi4J+<5Fcrma@(zKBVy~Rq3C7PxKHF
zaTaG52(E@+D|7c{@WQyDKLh6$ZKGrcd|+NHaS5ouo7*rGc#C71_-S5+31{tg-&06A
zytBDPeJ0$Bd9~$}+)5<Gl1^ls`)Y3g`oY^>&)PC$w~tFk1G=Z*to;`wcXG{K=hDK%
z`-)cPH7E%KP&9o0;U>(1_M_>t`>o3<0G9#AqJkvSlpcMy*-6cwo%ql=>?{crox=|w
zsN%B8VnX&XT&?siMXGq!pax46pIMDovJ^!sKhIqQn5R!SOO!(}e14GQk&pS5b*;p1
zg+t>|7+9wJPBC-DW>}$WKj6pF`<P5ay>SgKj(T3#^b!t~#h)rz5+8*P5=j=+_Ojs*
zu396MR&@nD_H*{Otb4f)bkk<^ENS`5Y~nTHZtsI_KYRxkDiNhE!#VjU7i%(*UAmE^
z#Y2o?we6BneE3J%?*ABbyBGNARsw!g8JZ+gWu>#Jlom9=cMKoVk>nTjM7$|v=+<iE
zcD;8~Qg=PrvIrg5PD~|{0&K`dmEHoGc^H+u^^6Ty_pdi&H=x`K<S|}b;XfOW8S2VD
z(4>m<{1*2Dz5gA8VeQAXddc~k{&bQ6kmKF?$@KL%xRPw7F~tMtl|ndod;6Z$e9cq4
zCdYp6ttA&_K@?Lmw~DH&BO~Eqyh)1RXH$h;kNDAz+JjPoDybQP41Gk_lABTE^2+Ia
zVg-)NvuR)Pt{ktq=(PN~m_$20w;YyGomR_<FG&0;Ce||?<Ri)iQ#t5TdTbp-lrngl
zr?llC%)V6td?mdE{N~pKfr`Lpn|xG4hcVUE6tUtL9k*mE<ck&3r9Y-3f@uQ=?vPYw
zj{HTVfk5_6A%fL{anpuaPlC$uggS1C^X2~w>uMz*<>9KSo%@1phKlQWF}Bw{0Zm$@
zwc<RkM;)E94dz7-O$}93y!ua@Pq5zDBDd&+%{PWgAzVy>ll&z%@Hf|SW!pK%77mN~
zEt^@)s*2~T!xrxc2ExNc)tG3#jNAwF_YY9{SS~%2VHWwl>8dF?7v(ok)@Bc;$c8Vo
zI$=`muhjRG#zC#aSs7Z#Dnv049hX>5K9gFrM5VoC3_aI8SY~bdg>O(nGu;+wBh~cl
z4K|F$X{_;cg*y9;B2$q<x=xQ5){6;mKiBtGaO<6Z@(Zr4&Y2#|I)X;l^1cy!dwaj-
zdb;hp%x*Dd?gZdAekjQk@k{)&S3sb^MzP3*jblW{ud=zm*}KgOKUz%q-Q;h$P|e?T
zhD7@BK-54>eA|~3;S8_>ND`@r#x7}^LcGFP9kvxmvW&+ZSEmvN@Wc~3fKCh!<XST2
zjt1wF8ZpkKv77j?{CG#mk+|}6xco&HKOjiS=0D_<=_@og;MEDsGK<-CaOo>xaOS9}
zx{hasI&FYmqN{#y&YZy!c8s`)OjV#w=*9>Z0$vj}^!g<K&tG%IcwCSF7?Y<bkzPay
z8e*BJgYha9to}Z!X$sQrgR!~M#l~p&9jlAPUHQRvA?MdW^9I~%J<2T)B%&|x^wTkP
zNZ2Gq7t1Ztz3xx=m~o*bR-Lci!1n>w`**Q)bq7`{met)B2Zc`FCo>}u6R(u^zqkNE
zK!GZ8P%K^hcuyynq+bg1p%%N2#S~lydcCp{d0f8q$7^awO7f!5x`>ma>mM2NKt78L
z>-QBZt47P>*Iw)rNxir>mj*Wx^j@z>ST#IkuYzRa;$2qIAZsQkMzxOfvrQ8Bug(ec
z5PrBZTi@MnM$Fvs6aT@}8v~N#mjVLJ_+e!&Rs%0l@wWlnBaM|w?IxS9+R-S_!EBLe
zgmM<9h`&M8b6(j0M>S%R%8`2m?ffqU%wv=h?Xgj32);=&8Kb=)@>nE+4U2^%%TzI$
zKfOJGnE-l+Ghb}mMx;rIqN8WtsT$p$_Yo}@Nz@a|Fw1Q<EDrXqh_DV$B@3IXeOli>
zBF5w+|Anzy948=()&<fF<Ur{7{E_b$#2zV+$f>HuJud2F-#{QNv;O{FJN2f<mv=t8
z!Ug>OoA=*oI*>`_k49+(h9Iuekpodl%)XD=%Px|HA|b`WCT~<irWCYMzh@j(-97i*
zM34`00MUKskR^J0`a1n`xxD>j7XY9E=-p}zS#pFd;o*D}{T$S$0^r)ArsnnQ>`9mT
z`J^zr=+Jyul>!+E+U#F!zmu^@)}o8)7717^ssXtZlhl7Hja!08g@v63biKn6+d<KD
zunUy*kz3<*3IG95_xSgyU~~uVQ=xfJ(TupCoqU4vhk3Nx(<i7+1FksS=w_554Mbma
zhhb;oEwmv55-n)7mT@XH2nh*&TQe)sSb)d*6E?N_<*ArxLB2J@4VQeMEh2JY7gV@C
z&oKyc8h<jJd2r#-H9Ul0uCG^6AWY%A&Qx~vtaqzxg_X5MzII-;eLXS@ugoU}Sw{Dg
z3R?Cj@=M46w5o6Ya8`CMeDiX1|B;Tb;^$y>3l6%QMO(jK%lIzHWHA9K2`fXKh5VMt
zkPwvW4Lkd63w3~}C~1Wq+Xn!MfsO5Vy9{PcJhiM@K#G0O+zY@SFWLooKe!hv{*wof
z%542lYK*8|>R_<AAS?t$q}*qL`|2lvx6pAL-#XHrgMvv-I!pq92Zlh!y#5EvHi`wn
z;lR8BUOoT!{*NWbkcF5R+hpm(SJI{0o0UurPcg(``8z079nn?x9|F&%XI~pTTPfs9
z)DR`{DEqT<kr=OFVSC<QbZ8ugea!BLUHrb(tkz}5lBbe4EGxYdT_K|AX#Cm0iz%sc
zijy`}Flz7kBhvJUHkz3?_A?42gdNXjMSw3TFI2U;qVX(!Xz{Rm;nt5U2-`9K9T}Za
zzp#c@O5P&evvQ7#kT7S)?pBNx0H}EUUo2zPJ$^nEaasB<QjS<+a2{F%7=JB*{(@;t
zPQ%j|nEqq~8UA%EDD2n23xG}fpN$xx_%Vk5{r`Xb|IQ$cGwPSu|65G}J1<3i1qDD5
z7Z3S!6o%Ras5L9Oy~Rum_t1_{Yx0;B<I%PHoKFDbMP}ya1DM6}wtd{LuBxgkDWClx
zqkOy%&?UwgCP0=}oV>vQjBd0#u6odnhLIosYi=n8VM_UbL~Q>r@WlTseEI)N#R6}|
z0H0n}(~)$Qc~TiUPx_3+nKk5m+Z_#C0mja^b?Q|abpHbKivA(1BKsauJa5?PVJWqE
z<g?BC-F@jor^D2sJ5c9&o~%X_rKv$_wlq4Eh1Aw2;En!sR=B=Llh8{x{*cxNRQ}6m
zyBB^XA;!<+M8g>lVMNH$(}aictu-U~vw>GXPl2x305#(Oh=x4qi&f8b3HR<Uu9JJK
zVo`lrgWt@Mn9LA7aYanm8ENk^cr85CWq%ySS58D|%d*;dFyJs$91&l6yjrcdp&#{X
z?8v0~C`IB6J)00g{`5>(1PSMuC|Ahl&^RlL=aMaZPZebt#L?jP(t0M(>3uDSNwc`q
z<XJ^+b=C^{^0)P~-<n@9gP?^ZSBa$Idz&DJ&+0oXrN^X%&6c}Mr4aw+)78f{%@`^U
zQR?A*%RKW=mn^En=+x8GFt?-HZ6w#UM#qa<k-1W7PpnUOvObRL8N=+>lE28UC84cw
zYTf6liLVDQTRW<3?iL~h>@7da>8|<#g0MQDWrsV67*~$i4_z$|!?T3pb=%&pMW|?H
zCe87mm^-I0drLiaB_uZ>%c_!7D&I=&M|wS>qio9g2V;Y%IZx5zjnsl?Nv%4ym8;EX
z-=+wx>k;+ls6orh?ZeV5$vgc~Tq<4UQ`kB5ZlE_kn~)?8SL2YaZ}!Z2(_YoO!k@D?
z!3>g7uR(3U-I>BJB^*%vpJLd_Mjg;i?(=r2>S4>Y^Q#%ZBu7a^2Qne2oRr(Jq04YP
ze7ClId!UHSn#-?dPp#E!8~?m3g-?e5(A#UK(y*Sx1<K}`&~A>JjJ&<n_5oK{nk`IT
zm;(0^9!~;xuixK^Em-j0Kw6ERweQnX_{h*(YN$5f<1~`hAFy*FNmL;jAe)H+@K(1x
z-S+o9<eoWYXx4hPjC*mNy;hsr*YUI^;XJXm-a8YHkTl7W##T!>-<kAb-{tiCyf5yo
z9jIh*9(9p&9vItLb}(+$^Dvvu8rAzFg<#B}Uh*@>EwO-cr5CCTrpz?ebxwP~R!8ua
zP3rEQcEZ0AhdEx{uO?cJ^6P40?tbU{zYCu2-aHj*)6=4JTPvOy|7E7jc`y>b%Q;-B
zF>kxx1aC;#_{bDjvZ_P3ID;t;ANso!10Py%cBYgb;BTYKd3Q(3eiNvy)2`~8(0Mw$
z^H)v<8yhqR$~T|HH|aO>^Fa;Q>$aC1c5-LU1GW`J{ftE414MlrcGiE`du~BmAAi9F
zE|~rj7xbk9IsbYrX>@S8s@#1)(OSsyf<zL1nD~H#iu7nTF{5hz#v0-|?K#w>?DxT*
z>}a*Vuhw&^vi|yMR)D9${v=+CSiNIi@=F7W#*!-JzEIN9s!prh(x#pt$YNrLgHW#?
zy{)K3_DDO>XX1}35U7DVo$XE|MLtz3rO6`>4(;Dl?|R?vgdmahKh7VQg@%nhVD;Rt
z@q?Y`k(Kk~X(mf2J9X7+P_v&F7Fb_dD9U(Ve5ng9w7ef2x@@Nwlt$Tzumkg+;}y(A
zjqBh=Mm;FiscZ^>)i)p4WvxJoF5#}Oz{y_$o~k-)A2UXV+ALv9LrIXdLNnb*1v6EN
zkeasE?VIEKPc4?#4gZFziM@FZwten&CKUm@c7F=^`?g2%?^_`b1JU!J!YS@o%Fuwe
zMcwM#O>T(en}Y5EydmWwXN*HKTs*J9yY2cSI4d$wh@-9&d1O5#3)=c?ZE`$sMoGgg
z#K8~uHO`s&4G~O!PFj^TI{a$^V|l<t0RmZ3h(?S%`Pjo3^Vm%ShfIj9ZEm57MEh=^
zp`rQZ)=@t(#F?2?vxnDy@5+B`@7jZ!KJqwdZEX<&&&aD(&LTb_F$D|=cTj;yF)9T$
zAw&`o0;G8fB|HR4p~oZiqyjY_<t3MfmWBX<gkUHHjYxPulvhH+$fH0^f<TQtLhO&3
z&duB(H*+(c{&RDG?e6S;cfPyxo!#$e_p{#>zVi*A$hNxc%hCCEg{|?IRt~>!B_PPh
zS6_WQE?ceaXtR)=T&eEM;-ahP5noNq{xm_ya7s!M_kzMayeTi3>L&DH44G&`*wDz^
z$LMX5az*%5c&v%;n<xElw~;BSS)znIefu*vYL`kV1l3~h37&IXB?13z*q!!cumk=d
zRj;=Jp9^@<@Ui<8w9ozsYj&T3T4W0knb~)w2vA+!63LRv(xzc~4<W0-G457It~3rO
z-@jk_<Pd3MRh>DKb1*lNu|0?R+Q*R8BO5=YFdwRFJG(FbI(6~v8c6sC>yI6%09A8l
z)VmqgeYU$A^Y0_`gR`68V>qVNs%gZodSy~_OwRxbp%cwFDSNc%Id_SbSb=I|C2hY0
zBpk9DANQ3XCM+S-7TK@Yf=AKDLEvdIdBM2XP&@C)=J_rNXuV7};xMI~t`30D=uzwM
zYCfA(%u@4;1I<d?x3^TLksk(UpuLpw<$tLU;^RCBR!M%AB7it|!P$71=%F&g!XizA
zE}R%^oM1jOVSe%GQ$}wxDHJgF++?cqr{!bZ?3+LX3m(p+X5#0SW65ZwHnb&5K4NF<
zX{LQN+=U|9z50bnbd@1T7XxmKUkc#<kaRM`j&?b@^pyNfBfaKAK)A;HPI*a*#l&TR
zs!IW3_5f=tiZGj#&9IJd{IhF3iV$Uq0o%NqBzht1HY1)&99th3gjlKP9H%?o1G>iz
zsG&v;mWPw(72h_w+Z9qaUIE;hHfihI^|75A@$}0%ZGmXySb@7+sDCuS3^bg}_>N^~
z1=a9OnaxfaSdS7g?>TmnSDkuz`Q2-r7|T{T;4|&GM}7|n$RiEnh}f|oN?p>AM#U<_
z8^8z~9bLaw%X9U*=H!y09BC0&md#I87HvmAEEcbV918~5NwG{f^_!GIc|Lcb0QVDY
zUL(f~4I1td)|~p1g+*I8Wzx}f>&uf=v~ZxJkT-Vaq>gpnN44dc67ytaFo{}}vt6lC
zM)zEkg$UTb9p~QZkF}ODdyXd`4S89DXA;sQ95T5FTd$HppTs+FAHV!6)0rUkPP0dx
z>nCv(o_jix=+_iR?|{o`HAK<2RNV*cJ{fmtx;aeHd5Pg`VciE_O?dop{_Ycds6Ho5
zCz*dm-(>R+E(p#n%-_uoE2_kA;jsLVIIOyu7>JYdL7<J!lGJa57kOQ9u+w}j?i(#_
z<|-VR<dHjMp9f1DwXv2yZLq$yb!9G!EZdyS-sXH4DK1kGCX<$%YY`2NdyQ^@o_hnE
z(#3L5+RCQcdAgwH$^jG=d+W97+ZNs4PDB(LQ3GlCd&PsuwYH|5jnC?&gY+{uW*7H#
z-%N<jKPo@quF?uP$dVcVIqpmjH;58gs0s|K&+vLNsb^ub&P|0+HPA+7k6S#RK6OHv
zcyp8w*0^dgwVc14noz79ZXv(P(LLu{vF{CYryc9*#O;P*$t9R{mXlP_7)`(B_j7Nl
zCELnB?34sIbi6vWaEvH%f|;ptJSU5i)5Ojy)~RGZjLo7*gn)Ts;w8<s<P)Zq03#%<
zJ#u4p%(Vm+UHkIlS>9-l+Jt^fw-KyUsn7@<*0om*gql?CD2>KkwmA=GEpQd-^~-6x
z@<Ut9QR??s=p=@%I9(#Cipri2H;lKj>YS6%E9=_eV`iZTE(TH2H@D*a0typ1MHBEb
zynESHBe+h)_oO^qobPp?R%o67))A3D_5oR{<h!y(9g%sQ_7iJM-@AHl(u|Fu_5jEY
zKTT6T)9dxSS|8`X1$ok(S0+H@S7~5P0U9vyO|`rKTy0(_grSjF@DZ%M?xDJv`@32f
z;f~gGS)UMy<;6+y{0eht<1gQKv3_h0rF@!_sjoT-Gdn1|I`qCD?HPF;X?J^GJ_@+C
z`!qRwW!-1F`I;GXYieAw?(+yvaZ=5pd0rN_z5@m8)4um@`E^vgWg@>y0Z;M$aH;3T
z$gp`N)*g4uPf9U1`oS20Ay?bqx-Vt{fMO8@Ky?uicoG5>HZ8@#P)3)21jwsjI34~C
z$pH%$Q1>sC|KD(F{~&De|89R5!})(``V91rSm3f^e_sP&npTPM(8MSznT)3-0#T=L
zoJz0<+xx{OP{{-u8RJXaG2f#*ZK8p%;XR`g@IYeZ0{zGZ40Q*)xL<*~c|y;4o`!*U
kGSF07n&ICB$kb>;OzM9Y*n3>!3kVnm!Y}#P`9@^@3Ik%-k^lez

literal 0
HcmV?d00001

diff --git a/doc/design/assistant/blog/day_45__long_polling/phone.png b/doc/design/assistant/blog/day_45__long_polling/phone.png
new file mode 100644
index 0000000000000000000000000000000000000000..389334d95a8f616818fdb63dd26c273331a689d1
GIT binary patch
literal 41602
zcmc$_WmH^2*DlytAV>lPcY<3WK!BhL!QI^w+zIZDgy0gK;2vmPgF^_x-L(nUc;nVU
z&&m6K_pUYf$IM#uXMpaas?MpitIn2Z@7fiqrXq`nO@R#pf$-$zq%=Sv)I#7RiG>QZ
z_-*Tx0R_7Cd*$~aP;ETU{YMO-j^d^vD+#I^quK*1bmnpz${>(0GYAy)1q8YSnu2yg
zAP*i8Xx|J35>5w!NL{j8)kT4hC!Z8$r9jAkzj+;{NkGd}7dd@5pp^U1M`qAo9Jn1M
zFZEu_d+Bi1%U^T*5%XkxaL{gA%qBln5~pFLPIl4oy)+eFR1{s@fybtH`{T-HYcPik
zG1ZR&8T4d&jVsndHEc^F1;zYgKg;Y(1OrpisQmY5Sh3LSVbUB?pRsfQTv*oDGG8K3
z=&>KR$2TeUWGQ)kM)_pMva!1@c;rX2uj)LU5Hq3}$-l=gSoB{&K~p|Esf_Z3(!qjm
zRt(Mpk)qsDA#LW&&8%S|+N>!GjWWe^bqa3^)p&3>kMpqTx8N#!_qOsxZ|f(Es&{kA
zBt*-+KEb@XEB~y%PBPR=SxZR#-sA!6F)yv>U+ZLVO#P_ug(;0i5B3`A_RDp@$YP8V
zwdU1Hg?b^@Wm#15G2R!|U;lnO==w~~=%>Z(oLHFwtwgcHhtkuh^uIf@sHdX~x-)Pe
z2t`DNeM0E4P{*e|d^K3)6HAm^83e1>-LJGUAQo)XFC-%j-};lLN~y2EP0F|P)^JwG
zN6#UZ4xSSIjM2-3=I8N-yc|6zNosQSFTUge^n0(luR4)XQmtw8&0`0lw0c6(0ersp
zGc}Wn1>HM(ROa2`eC;0B(wva6Z=ub!dBHytx_Q~9cUqE;X_#AlfMsM)K|^?|u6f<8
zY!m8~)zQqITfMLrP`GR<OH!|?&?wfjCw6xV!k46w5}#H~WIf3;6NsS|`|av&x@lv=
z&0|2q8O0vu(J4GO-iEquFHrG>=kvW-r=0{bkv4I0PiKBiUQo{QEOPlHnM|=p9K{NY
z`CxU348%<Tt2$_1>CQxqu%n~h*m=l|pNJ&I!qS>U+o1US@e`&m3BF0=7X_?mS!|t-
z7S+GUP{-%RZMkdl>1)((o)|qzV>aTnjDc<3gB*yf(dC$o7d(SIQBb?1f~34mkw-kZ
zy>$*y8sos#cE0M7f$|wnNCM;FS+HN>;-Rl5C&YoAhJ<V#%*mB)O;)UMblgKADaXeE
zmeC^eUbD#ZMqtSkS-u*tPrzk1AuKl&H*noYK<Dmj_L^6%r#*9(5g(_Wp~$8ko53>n
zbRT)(vIVBQqW8ViDn){`AY2SmLd>=I&Cgfth_Eq++54Xz^=HNuboZWh2v?N<ENU=0
zib(v86Jk(#oIVjOn7JaxDT!qpXc4!^1iZ{=FQHw!1&96nKZn>;a?=un1(P38MPyc}
zjaZY9L~AI!*E`WZ=pk9Z_`J`z(39zP-PRU#2Z<zlJ);m_xI*YNPX1=y<%h?9;{P5M
z9c|cXXUo;%%EZmes#aL`8iw0jQ&9jOuQKI+P+k`*))-|aQb=k2@l!}h=tpOERASNj
z)iWHtSDb9RwhhNQXaHR*0A14R_(GbwPEWBh7$SKyOo$6YWqMEpndwoZ)~uj^iGx4j
zxC4K^9H@So0StL3d`~$+v693E^~Tq?x;v&^tS#Vuk!)YFCigy5&>bFGyYqG%AL8P8
zw)S90kU1kN-e0K1bpFe+sR|XNt1g%QB_)qHLU&wL*kLEAb9(;KJccpZkWxuy?X~-W
znPPS}w4KLoVihfX-2J-3w{Bx&<06TLPbIfjRMhL$xs<Q3t!+kta;oL5owlSyLw5$J
zY2^UBcCn?U=(u2>se0nemj<U+p=~SxTYt}3$}p*0iLn+?&T+|Pl&_<O@bR!hrg}Nq
znebkb7#nqjDvD=VU@P!qd>&-su38I@mR68QtJl*h7M!^kp5c}VY?ZcIkD^6#KTI@h
z9@9Fp`McHcBR#2ae3AJu!Bl1NdUT+o*P-xd@7VFYStwUy)y?2ux->YT!wtFNyfCTQ
zb@M~mV6w&yTGkWlt4|Z?{nBnM?oC@F*yZ2kbSe#Gq@}mFwu}ab>h4KNNhwL@eswbU
z0_rb|$CK4sAX4&jm4*|-{))|3Z=SulPTGbwyO#wJpIQ+=Zh6#kTkWW4M@s`M(bi?C
zth4Mj3hB2~iayJNNH*<V?RHR*W?f9RmzulMJ3XOf1*Xj@%o9^TSN|dzf--fMOT~zT
z8B4vIC*3my#?NRZ{GpA)+~PbMgP`u==W%xqSM|?3aY1{S*A2TXf?9?F+}&L?RNKXQ
z+y-5LH$)odZDwF&mZ)+O@$oS+36+0%Vl)Ps8|(`;<WR@iv?+LSAsVEl#LZZEj_<k(
z7#r=#P1L*-oqn-=!JnTU17!ciYWfF?7?*?-L*|}-(8rVlR@UUGptaQ!>GpCgyf;~I
zIj}<XiO6DQ=3nA+qRCOD3=Pab^sx~H&N{CMzoGnF-O*IRlU|*>6N`IQ$0>#3XUslh
zn3|O2g-0ncU{I<JGVbYE%mR-X=c@riVV!mru41BP+pY(gjB<AN;Y;6+W-l>ud+Xv^
zyMO=>nK<(lcCY8z0Mmq1I8P@sJ{29$RNj<%M#3cT?((kcTXzIup#=uh++)k%6z84o
z?~0uZEsrVNrsMZ;aOXlz`ESD>h?*sDP0({gkr(`j*P{w<<2u|%;t-rN@rVYKA{N2v
z7Pkyw#h8Ehd+jg0e%KmROmn54ZSapC`_c2@T|ej>C090QG&t<6H($UQ)`+#;;_I&x
zk1zSSbI8}RXb6dMe8Cm@k}B7iRA`bj;w{GQV7O*Mo7Wur*IKR*PgL5?yN#Pk6?RYy
zO+b*#Gb_duqa&I2`(Nc}@w0*xv&c+_@2?_vR<=z8_)nS;D9Oe{0~?a9jgA98W>aRm
zRa^R1qp~tG4R*7<^x}_NGBO`Oesi!K#ynVVjMU+vKe4he;bv#&&7erHL_<Yo3@+rh
zV*Y|pIy-WK%I&g4Am5Rl)rv`nHDQ-R)lUo~O@@(*yTX&F3fj#YO>35%cf_9ef0Z?T
z3;q_2mDg@mtu-qiLM!&L+HYd;=BMJkDOi8UH*ZK}ZBOi`<2OyxGmNf_JDemGM)-m}
z=7pfCnwr`CE90f#zx8NjWMte`l`hWDJ+w^o)mT#;;8jmity91355HDuoKI<Q|B8`k
zmY&!B?i*}H?8O)SDN&;?6>j-Nx|6IyZ#Z?Kv^<e?c)yZN{o=CWQQ<85{=I%j9w%SJ
z>9feTbCeTNsiu2Lrwnj<2qxr<MrGom%ItWni09m@eZ})@_^PdO&iQuf+&0^DrSE6m
zj0e589UsI+YbKhqw~j<)L`4;ws9iU0_`e%?ErowU7b$aoTanA-IdI&|GHW6nrqRa}
zqfp4j%J~c%*Zqtogn<yBkkBYGqi^bZn?N!Gr;2vkFfdkpV7yJ*riL*ps8^}_QpZr7
zfO?g;Kp8T?WD2%s<qYq^4SnmgO1tCw0bUiU5QZ9*mbU-rAwgdqE{J&v-#>oJ=uu--
z{@j^hf3tYwZPI1wQL^3W;)qg5Cw*@G_4Rd{RF29z07f{<<M){43BBV4$>E(|oQ%WQ
z+d}@7+8|t<_X&EjuD{c3Av)DJHfyB1)h5K!lk@XlHv<HdM;qPi`?J3$NazKRF$Ypb
zC)ZZ%WsQCT;$KYlx@P|C5nISov^pz*KFVj>8H;m;iHQja@bU9z=Qcy#o`kB~?N(-g
z!9Vlr#cjWq2Nlqz<EG?`@B7fUm+P?ktSwTjep9FBr<gO_ctcVAJ8#PD=BU}!P+HoR
zYQ9kuMncb}#9W`K{$o}_M$)qQwFJDqEnI#j26nrVShq+Upxwj9Zz7J}bjN|unY&Nq
zUDYXJ3DL6Gvb$4bqW?0Z9JzmfWmTVFZkQWq5WD2_9n*yk=3beIBG#%;g3A;}s))TR
z#_Bq(&PvqT*?Q$za78WB%Rb94)5}T(BEr_GbR57ucuN1}ryNQUY{cq=Wq5k(3nyB(
zsIlWdhN6GK6{7Xx&$DO;0y6=vGpc|>F8VJkj0*MYrt1E0Uh=P3z5ejhpb6i5Y_P-o
z3qNiz4|dqgCgmB&-a9VS=EkC;ZWg-VtM3T_?1wu2datQ7ds!vhU$w2N5+j%tJ=n>X
zSunzKUfAbuCCU^j<SV@VUz~{QcC6IeW={770FAM(o8suQ0BFX)E>uzlN^f4v%}hGM
z_tMgRlf9TL)EGch^064=?rsht(vnF%bTQfsbhKU{9vrh`(f=-_67x4ZnfP`bxAC=5
z37W-tm1hBrqrBtnT9sTi4RuLmBuOEPo{B|O(n<o?=YO@hJBz}OOAEZS%*c2_d1Yu(
zmB4to*gS4V=ykj{y_I`1Pl>A=9p!pnZ8S1EI5O6no~fy3WWhthB+pBRYdvnAGu*0H
zJTKVEkOLdHwua0soiCF5+{t?Y!wVXB@CDfFXBZSJiltsHL6B>89vqN%^)7-=`|%tR
zcsuO=_B@GM>}K`3;uq$-IFrypZ#H;ch_>g^RKU9~`rhz3a<Pr8_wv1)pEi}Lz*qiO
zR##!~(ZZR2dv&H~P7id(Fi$U5oCo+`!gCfN&ebU7urczOKa~8&z-mTR+!>d0vvHiC
zohhqI_&@`$D@{7=c1BpBKJX**cyWJ*mj|;DXdJbOQ`=FK#N*9otl*mOc_mmiS0GlK
ze?MFSM=^@&>)yO|f<dJ~rm{?7k84(?M%lx|LmSK0hEHIBRhPRkZT+H_fx%pQCp$ZP
zU9}PU8~+A_N;Yop%gakjv9qR8!^eoYh?DE<HUd5wEc(&7MTa%76S<bPA3r_U*&<Ia
zr*3@eEiEx>I=2-QqqIHt=LG5K^2P*^*Q-ODEaRR>3&)YR*DZej&0l;i?h@;GE9Y3m
z9=61;SL$82quSs(KfO;2*pir`c>|tsg`E5D4_yyUPAfl8GX<Rk5tY{_$ZH6n^@v&>
zUVC$1QN_sea<f}$l~sLNLxWVA1u-BLb3C{VQ3X9__|iSY!+!6&-lyKhzFjm?)6&u~
z@m=2ij2jvi#ha?Fqm_Jna}(G0FeV}3$e)h;m+RMem#P?<&Bq6XrlzK%q9PX)3JOYO
zWaPu$<+R;isqs_#<|=cRDX93Q${r;nwkSwG1T<%)F4Vkg|H04{y&ojXNJEH8+~osH
zGC$7x+uoD4avyV^7Vr?tJ7zjII2s>i^IdRR%<r03Rb=p76r@h1tzg*|*x~06pKGZ9
z{8w^rNZUS+O5T!;SxCrcBCqIl(`kCoJ=S4vwnAUSpk#7aB}dd!`CNkYHXn?9%(|5^
zE~S0@=>{zRXm)c#Kq=rrCgyvwGnxqn!wWHxi0`BnuJ(p0Ce?xzB3}D;JiD<ng))U@
zKPrS$Q(LW}V-m=v#6aH4igu;SIRMzyFR}t|e$FN(iI3+oQ{f`N)z(n~tB#J&k6DVs
z!5=#I>>M0Y>SSIB>J;A(J7GA=Z`Aem^-TkBw@twh#I&?fh;B8&dn)NX^y1=y$j1ku
z%Th;Y4sTHuFndJokaF*@ZzyB41}&QIt@%$TZhRuwW7d_|V`h<0W$N?m#-7CIib7^>
zM1D6;+VR6)@n5~H=tFi~K6XB^b#`_>K0XEp238t2cLuBoCF$#(O>--YP!bRjsH;!@
z=Ubg3)^oXO%L|J5QC?pDZL~FcPf=l*-(a;&^Uaihb&lBEv2{2c+OXM9lM&)`I4LV}
zbF%ukH{3AkA)NLe2Eo7)GWnsanaF57(lJx5nz-n&BUG<3SVAS9;A+zqWohuW(T0F9
z(dX|<s)XQ?NR4W~8i<vf8>9R5@*jY-$`U!)q~x)fz)Bjl;NPFMQ~tA;)a7_{X(7|9
zQC$9mbDr{|P$p*f_O2vH?nU39wS?T1l*@-}sGpzTb1I>U{(cr--a7mFs&C)EnfJ$K
zzjd>E_pbXI3RWG=!FL_j;E7qx6Qsnm3hi;2$i($6?CCy$2qitudcT27Xbmb2*XK?q
z_bEHZ`N_gpCnX1{eS9V=QUAJA0vc73zc3i!|C>~g4-E~Cj*595uY7-F-(cYA;$mZB
z68K{5s}98HZjS{CA4NtxQB&jN;{(g8T?}pTv1iDvL>vZuwk?w>6!F=g>9}4o%-#Xt
zbXt$+h+1Pk!?ycHuw+g=vN>Jab-gB1-SznA?((2Np0>+!cqd-`ersEwTO2VWp`|d_
z=UI+>H?dBlP+ZsEu2nf#L?iKumqNJTt3fpL^WCAN`7zeXa}XU?2-9eE!N5G<v>TPz
zONK&4Sk=*T-@#>yC^u`$&;#Z*F|qLx6mlIIqshd?1Zc|FyBu%p%fQfJ78M$3nrn^M
zHI1DI8r+VbB6c{HD?0w)4>uRrw$GYt)tW0c2P-S<>({62J)uCa-{URpNOjY`acOF5
zN+xHmS>P9sQYaYX^=0;2By#P!^by{7QDpR{WfZ&oq`v0sjbQb)N?$Zqc|<@jEz5a&
zM9$jVP}<Cbi>TyEeQnDd|Kq9suTq7qTI~V|Q#&SxHsK(?{^wR(<j%AUr`^}l*V^cQ
z(P7td`zr<WH@<j`&i(U$LuoO4LEZ<I&1=2~T%@{0xZAQ|y`RleACqU$P-7oxGAb_O
zQn}C*yll?PyIv*NPjcUzC#UIHLJdx9V<`o)e~w5=%e~!nJ|JAU^gPgH@v1g$IT~oN
zoh~RWM3GC}Te))<D5X?7p_o`|MkdRGIQ44sYQCTpqVl+U=RO9s2`!Pla{bIs<;c6}
zy#<3>Sv62h2HIHba4mvgAwuNS#RGgTEQ%fs>dx6j6qSWee2>_#DAk)Lj6AQ#;d4cq
zg~Il(GAeDl+oT6SYR3L9CuPelO0u*Sa3%HRt)r_GF}+J>G|>v;Q?Pm=gy#MAn~?l^
zc}z$Tqr4=wGjCX5aoTzGQoju5lbb(MU$e(XUU9y{dy4H6;Cu8?YYR~*?nFK!!g0x6
zw}(>n>#ev<+R3{8;2mkn$;rNlHw!1~v9{1u)+naFFfK_{+ALnn;}svkx(Nw+U*|kr
zD`icjTOABsr1FE=8F~dquXiUutj7Xsy~}xRr3>0E=I6O8;K>hB!z%b0xCwtiFdZ#6
zAB=t8Os-JO_*qw{ad6bO)lW;~>ry_cw+GuaG*Qpj@C&%^ZJws_8F84Bxc$8eZ%6EO
znS!TXM+1jbM|1t}7o)kwkiXo<Thk8}6%<|wdlI0V<eT9{W1m+U?JbohUFriSR$HGf
zGK5h+kufrnH4^w1)r~*6u&TeEsGT9`m1)Fv)>l^_<1r(1SZxYJY4zIs!=n^mwK_GW
z>h$P#UPIrjWTp8yJDg3}dUJd8&}qAwP*n7_czI?<3-p3nNyvRSp_q}ITeVE<PhTI(
zx=#-57EsLwul`;i%vTd224iOrvJ3w#CQcorYaU)$hui6aGN)g0>et>4!u&E7s{Ahx
zBFnhjCzfO{bq&Vuh`UxF2Bz!YcnDVunq)fJ!Y0O)S*jK6m^N)ZK;-1)rw`5?1or_Y
zoi}yW`|jTYCv|h%=iG36e_pIvpLT6=IO8S~DRsapD~URA;Ql*%scW2}w9Q3CRg1iT
z^U3SNK!K_q-u)lE8l7e}n%LymADfRSzLc7(U`=MX8??CmwXXK0=&NA|mHet-9>+!z
z0O!G1YtC5bw`;+8S2{ef*m>0yvB!lkCnqkj<$^&kv_<6|RvP^#zIy8i)vFJ~v~O&8
zsfQB7kRA=GoU-*>B>x!LWqZnlppf?a?CY0rAEx##IatR1d(=N>_cpVL#9oD|cuE@*
zn(>m671KqAu)a_3j*g+Dkgi9`%K1w!zr~LC$+q~1puDK2$TY2r*zK&~FxhZ)T(Cj$
z<i7jUBSSPf8|dB0?V;dWrt^+c0_a_05m;2b#rjjf?`Vq-WLv1y<6sWtE}U(N^3L1)
zr$X@(n9lMroq6D5`EkiaP0hRiX4ykHd(eWDjcrS4Y<O4^GMk!~CRq2`I-|3pLaFjh
z+~c1%Ub9v{Uv2XuMc0&5oA|1nN&Efm<ao7>*8k)$lSH7`{LSYBK?nbvzx`LotB8S_
z{!WC`WJlElUcu?vV!ao%4eoyen4rspdD0+-qed_?SoQJzcB3!)?&_$}f>>4Jc54}a
z4@GvIUfo@G#Zn3aEY6h+zS=$?e>g8D&DAa27w1yf(x4(Dvk=JCPaSPZUVX`*T<gOf
z=L`*;PK_l_Nl6t2i$UjMSeL*0qRnO2NC*ivOicdNRZLpknNR;Aq3`+ZXwF4U_H}Qm
zWjezR7HE8Zu<+U(7;9`WDkg%0-{qusvn;?*a4UfC&6_u`U#mlA4OAs;8kfehML1Fv
zK%(QA=;&HHI!!i{zkEu%ZVtL~{5MK_m5^nvU2AKPp{f_upffM<#eR{h09N4=z4_pL
zb^odl^gh^l$HYe0s>=WM&cgYih*s;3!O<ad{dmvxbf~-+LL$0!9Q@qEkfa4-8mn}#
zDpR09%>RacGdm!hS=p36N<*$K9whB_$LSnPj!oSA14YWV9GPg(k|TVu{N$bIdrOxe
zs`j+RL7kt2bF0{X_Uh%&+%3&F&{Mxn6kZ>*RnbY4(zJ5Ay%|u$2vq~Ulk1beX{e);
zE#b`R>f&EuOh;gDU1kEnJ&Y{&&s(>h`vX%XDqYkD0^WuEL+M;$l=f_0!p#e9WEe>X
zTA!-2Ja`s`eZDQf*@o#s{?|hD?jYIRW7h91i0o(w2U|8wQI~qWMdS3GTekOCwGy~S
zcDA^~P?t)Gp~)#Wx>@ybd)X6TFJ<cm@y9WcuZ&A6Ba{`8xWwO;hV^?_h}?yfO(dsd
zl+kQlVMctH(4b)t$OhtZ<yC)(t7{2gYjqtbe=UH8@d8doHItw8V5D!CgFNq#?f0NK
z-U!$fe&R{PAOfk&93emiFOQ8hAVdb9IVN<K=!i7#OpCM2)>}w;A_y0Q+YA6LI^-y|
z_^Uh-0#hu;Bzy_NJtn(-bZ*bDkR!rC{Ax6Gvp-a+a#TauCUd*ja2WVzoJ@699fc?M
zSfH{*B(g>&vIf5(d%wY$kL{mgqoYOfJ5iymL4)^m;;tqFbU3x`@0?v7AFnDkj1R&s
z1WhpIS8hXJl)eHbFcQ2wPWc63B*nDzgUmg0z#sn97e!p%el}FD4S8ksQ%zf&3G3JC
zX8#L9LZYaWJ5=GmRIcU6JNy2DZ@pw+0g39$t)>NqNq+QEbjGzl;LtV!J0Z?*VJ3RD
zpKe#ZR99*~e)#n1`d3K%)zJnBcQ>uU@A|mbyuZr0tpwb~2ns+vTWIrwFVvdPSLm-+
zLqVhrHy;O|!@I8k?$1I>m3&U1&h1w-BmJb{wwrp@F1-%l%MZ_$voD9DxkVAGDTx95
zkt`<ux3|uu0bQT^&Q3Ss3k^Qgirihi;2v<U-_D+J+mDJVjuiHePKC-j3z&tMyj)Gd
z9CRGK+x<Q^tDoccmdl{w#}8Ir_LSn{V#-H7T4+^(1w^N@yfHp{+O82YUqK_{Sy3Gi
zzpYRLcJ3fyVR#4p+}zHG3$>sMmZL_4N&s(d>sRVf0)nomx6tIc3@9iOJE>eh(bN3g
zd8-^sik-_PZUmg%>w2ew<4=gDalgN~;N`v7(Y?>p7AutQT?x(HxjIk@xaA^AP(1tL
zw!lESGBzV6M`Zmvra&aT>Fs4VW*rx@(+Ree+WYG0hP>Od9?R@@1EGuLDLy%bq;~l1
zO{IMP{5jz6qPC%Br}PbJ9rsD_N{lQG>N+WnrjFVtc9nT_k0C|qD|wC2wwBQ@rikx4
zy4+cuiKrrtcy4uf#Up$KwMUh-fB8+65w?quA|>NBM8Cz)w49mH%vK*8I>1NN{5vX(
z8SU^Y73b2byZL&w%IbSf6nUgK+rC5o$2~7o(P>Ncpj^@iBP~5G`@T|BUjy5RP;Ek0
z+69v7+8xr*%S0+I%?HTGW_VSb@0aj!oIe}V9Ptt-BlRz44lN67Y{t^YyJnKqeI@wC
z_PU~VZ(R`_GsT*;ZS%ZQn}Y`)*|LpKe+HKQ$g9yRJ7-fgY4}_8R!{xSMU{BqQ8{Au
zrZ>Kw^#WVl)9*yQSl52hvF88>hWvTmRGO2EUqry96_J?KB23A@p3D7bXZN<cD+{5K
zNuyx=BT2t;)uQfn;Mt0&)minHFogkEll|ZyZV|;R^R#R{L~!Uwqq09W6^E&f(1<$2
zrkV!c2~+FETw+|*2X|@9ln}ZF(xqozCX_S8xMp1(27a|VI4ARL>{ZwbVEJ`vf&x}~
zLdai^C<ULjVfV&FuIfaE@*?a|3!ZnB6b6vAIrYk9_SlRU=F3uR;&oj|nmzAP#z%hk
z*WDv>5w9#vwafV{3k~vf80CO?6#(>hMl$;P`V1;P&$b3rDRWUS4wg$h@rL%HT~J!E
zgO$D~Y)lMv|M1Y!-VTyW+^U>5Zckrr^>7cR^h(`(n-sW^@Db{Nepwi=V%Xx^m(2FO
z%BZDIIWzrN!A8P*-m0JH3K*JfIUKk*T?+q-cfhRj(+$41`dsv6VyajXkl%;pyT+vB
zj{X#^5^;Wyo?o}mRRgxBRV4zq{>q{#`MEEFks|O(+0uZE+~?LxU@A~Q&Uxo|<mE4E
zN-)$LakM#CjdTPY_-Z6#R@ZvewHW6s%J?~MVFIIkvDR7ycM0Az+@TKF#rb}ggHJlH
zXH6zzzF*NXhv#DAVrJ~#9Dof4>DbtW%P%vgOG8o7C>Q;VjEsP|G=SRQj2aS=kf8pk
zaQAH9rxnrgi{BODAHnHvOG5Z4&!>?ZtzE(L$9gf9?O@N}4dyj|#V|8)>904X8nO^3
z$%yq?wdf>VA4MS0eu|0T<S3}~WLg+LJMdc0=!dQfysbLN3FvJDKba9{THdQdglNwr
zWpZvNq@FG$d~f?anHY||t>%%?t{z0*Z?qYAP7w&u%fqr?@hB{QH!G)n>w01HDV`?P
z0cLX<6BF}{x(Zp+U2f|2tQCIzDt|Uj>q~Mm_;8rZO7arbl-wl#fb)ZhG^!2hM&k;n
zd`NfAVJIJsd+S&Ct!wA;vQ`Pc8aLxGkjs@(oW5zJ$0P6X2R_MY1*M+%8+RBGS&4i9
zYMs{PVeKxi^z(}fYdnm%gBeqN)Am_k|4M~*7HnuiBB%c}zcq2VgX@}(_*OxNs{0oD
zt^U~PsU!w2<^);|e#gx5e((8p+-j%EX1dia;Ym<Pu*9%X287;t85D7*BlBCv(rVjd
zmuTNY$5D_Rgz&b&q#@ilhE43RSX`+O3V0lEq!^e>FbPs#p^-{Yrr0GiE<K+x{Atrg
zaOqQeh=WmsZ3Ir!e23qS9Te~}cC}0#5THag+b)i!t55l#h;vOBcM4D5M7J|4B(k!<
z%_mz)b<LFsG0ceN`7WKLzBTHf@-4%{>rA3nG29m0b8o-$K=4RGQQ~2|pT*B_K0>ov
za13FkuQR4CApvE(j@g@It1>AB<xTz=wR-FhMgzh)9_s4fSfldu^Pym5fRWKk7!E0C
z?yQ}tDebD*^;*5pv{kl>_1m~+8a@}R^U~aLpN-SKY>|1m!<UqLC0a5vH7$*)dh2oL
zF2jpmhWLk@&F9a>E>4D0I6i&)gdH9AXVr6=dpK|(%5B^G)fC=tE*jK!Ooaqw<pQ4D
z;Iz8$$Gmp*37z@FY(h^c5?%?GxY{+(S_D-ptjC06KKH$BOtV(XWjkSx(+zms&f*r&
zt@k-E=?M+5fYt>5J|U>L?z-FWvMQT>W&A<AwqnrXlYSVZytr^~R1|i0TC;;PUw?6N
z?m&nC+X;yp!{%3k;#H5|KeqjB!n`^f9PD7k3K^5d6l&8L=Ec@2Q(CKik+>ktUalK|
zjJNEqLr+hCdV0#Dk`)mht;wDuE-s$BxtX4xJ~X5NGv!yu$mTBRMrG^q`(WC4qr=;Y
z!dhGD=?a5~cJa}Ox-sbtKep`6$BREy2WYO%SC!X+SQP5GuH$B?TYWELHTy&)L?}9o
zd#|El#QPLrLXYX$wGvzxzh)hHCEo$Z<yxmW!}4vczbzHWt#9`Ea|Sx0-|EVsm%4$R
zVh58jX8nVK%2(NMy=*6rt_==|+=467%8^#=KfSM(3-3p)tufd$&SAWsaIpw`Yb-9t
z!M_Ja9!H!gXjq9w=&AnaZuzUPA0$iz4T?2THTL1rUa5T#o54MYm#eZ(HQ(hmWMvRy
zJdJ-$pQpLG#uzwO>j;B74EH?k8g;9ZO$MrXO*<}T!8@p|d?}T8wzH02D|2;@RJ}Y5
zB4H@I6h({Ezu=!t^s`K(1t>^@zJEMEp1+GW-cDrHul8IVtI3$OQQs7ywS)~x;_>BS
z<OL7nHYR<)${Z1=Sqxr2dy4gqnj$MPR-uUvQM;Tr@XW}9F|Ay_-~n`fINAV>=p*Je
z6cFNVEw4aN#F9agui)gkJbg|gHQ70Fi=XAdtZUR_^a+rmYYiQvm8NnzCgP_BAoVSb
zZ!d&mBUhgtD`0S^a0rDCkfX2B$+xHLy3TeMI%RLXH2nJNKJaMqJk2Ei;S@$YGUel^
zpHn_XX_EC2NyoO-5a)k3*%lf~arUt`?&)d&v`QT(VoH(w0g8Oct*(ZTOCbHP4i_UL
zus~=@cY=A!ej(lQG;e<O_ghbwj9Mkh<D(Bl@!3-pN~b?lUEh+r(fZn)oqYU2IpIxh
zjSNLY!-<aeyV`BMS(c7h&V1~B4i!5aXdvd$X>g)8HZt<R&h`SO3;nIyZ_>MZ^kYFy
z_Xmr0rVfmclXml|ilcxGh(Qt(5+EQHAqt8k6-RCib9bh<*-n?d4}DT;id>E$U;qT(
zwEFSDlwy8L6clS<sIGntJLo?*DpfIVc6j)36>Tr2zEW#HpU~5L+~%d=Io78PcA$Fe
zpB`;&^JdA(SQut9Mh)&?Wn$`M3%`!15kIs0`1jjPp>8#aUeyEUlP6aP(=43){66zz
z01##8<P>thQA2j(A$?j;PEG)wpPo(z0>lasrLr<0z)0}U$S7+Yzss~MFjK(M)m2b)
zBVpMj!2j#xkN`ZD;p*Yc8UB-i>w`ZcruC?APc<#uWFPtwo3Y-k)qQSVkf(xGXBc&%
zV;?8)creXz(dctcnC`N3>sLAGmF=>DsM{nF^cg#x&Lp?`A{u1&3R<id&e3=zRb{lr
z&C#)evbP@@s{nV2jeid6NguQ`XPT_>I*+>Q`0C9@F8c<>f=Ut3X8QFA+_&KhLTVy>
zFkN0b$NX(9t6~~mD_4hWgMU)|?i~{v9b!v72qSOq2ZlTY8Mc0P0wg26f}@U|`x`{V
zhUzi+=43N2G0EM1vw+(2Gt%2EV*gH=u`X<0`gaqw#>rg!7{yr16tq)E)ChKVR8#yA
z)}!aGK{++)@@7=+<IIz<EYdQ}c)OPR_G|4vUaKBy+s}^jevE}#U(0&XjHOtonsQy)
zP8txhOXnwR%SsYfQ!W0$u^r|)<D(*9b~<mxD=FYtb|IAuVN4z#OX&;S9IO@lb9Q%_
zHL~(?lZDiz<?x49r7|;R{9(7FHS@dDI$DElzY2%@I%N#I1q1WuTs#?a8wnSgo}U_c
zxaJbwMJOE>f&~urFD9-u?&1c<dR?cIQhJU;9y+Lq4QA~_TO~bpV{n@?P(YwUwbTsh
zl;7#ngPd40!Gcl#DXdx~x}OQTb%F$=veY+}3mD}TFmvm0o}Gao`ebwc_sqejm2XDT
zCVc!b(9x5%$xOkglfD?v2luy}AndST<Kyr?Qqu+^&)tb0jXKMNCcu8ouK#h=PENam
zFZ*5Ws*{tKl7D^r^yy+vU~e!QCO?I;nHk-1onl&*8JX3>1pTFB%kjZI{rmS}(tRDi
zR|X9?nf)corWZ$o)1{+&wXQx|7BjOUzew`wUtLVSqvH0zyCpRZeC;(|qKt<5Y^COJ
zGXaCl=;Jk{{vc@w<x3;hYQ6LL&GPY&3eM+vPaPN8HzvLniV?QWwkJsnyX>j~f&Jy?
z_%4^%ny@2HJ)_^}AyeDqXDF=fY;lp1PqDG@9eagAh%0z5zpX;_#C{k1SdK`C?K!Pi
zETyiR78U98*z&U9s`CK_p9HWoH8?o<A^cgRQE79>8~93#TUb~a&?-~-`pp}U-HH4-
ziam<I4<}RRwW~RYk%NBzw2y2)#6iz`zUwwo#gYryV<E@+luDaP!C=_W;PLT{TPFu1
z*sA07y6nS=TlU|<ru*TNym{p9g4v<`i-Lku=NRXC?Ct?_=rgD3E=cPQWaNI9(sg5l
zKj1D;3*P85i6L?B`#z+n`Pz7zwsC8NR%csxyW)-H!K%;5W^*6PGka7a-z~ZLqNh#j
zi`6;bJ}<d;jM}X=TbHOD+20=gFm|{oK@;;Dxi!)X%XQ5DAx!~#vitTbKex*uWt}P8
zN$^kWr{$a%oeyW3E^|D`ExP-SY}Gra#%YO^Rbz%{lTILEQ|REhD7T?an@)tFi2u^G
zTN;b(IjwF_8+#2DC!RsB^ziN9J#JFxm|xCsBlg8k_vo^F({7EE;0AZAaXMXKe~iDz
z$B(k!L9IWDaJt?Sbt4@T_1xZdMLxgw;P34*ahU2=4LDs*B|E*AWOiRL_Udm=%HW6&
zV4{8o7T^w_c5iXBicldZJE#GqNJk^TDPGod-QyWvcN{cOEG<XpBMBJsSA+}VeK<Ss
zsA~(OV_z(>i|x?#o2!ztT6g6b(uKGMjjg`j?#%5()X)Bj=e8GyA{N9{uq%zAd3Dn^
zrn@$}4Hswo!}Ahc`c9~H`xt9<C(Pdjv5mr5$)iSmgVV~%);Q0Y)p?>5v3gFebDx*y
z5TSSa&3l8ieS5tmDl@Joq_UfJud7a%J!yoqeCs*|H}s8%It~vGIOH|7v}RH`bUAZb
zb=ZL%sJpwnoGzEzkE2876`a)-oX!M<SV6FuB<59)s80$CQ8I<6*Voo$J87mmIl>-y
zd!<%$5dEE%40qjqViMw0RJZl@;Jx_Kn>`q<wfN)jv+ZGqmj-+7Gd(?mTbh@m-2P{`
z)~11{P~}WPJSB>spEvKmG02Vw0%ob}%AjMaz0Xv{D~{sz()hS)^6$Lv^#IH(YDF<Z
zQcB9Xf-qKWAkD5{CCg^MX?3A?v(D|6+&dqAAkaOy=}c)@ZPJN2?QedB13~kR@veJ^
zJBE1w^Hnc+=R=^ndOqDrD&h_{@^H47!G~-+0n-MYd>$)~K7SOsUMxN6EX3~~+mdLz
zJ~TYI-iwvlOfwB6fANCP$Mw>SkXG1zz*k$Gk+H}PHU`8)hlhp|A4J7!^)8^?$JwV2
zK}~`E9A6TcYpwgM>bV0r<O)o9DAC7QU73UVB0d>ZuV~~#3W5nn5(nf_SrocoG<V#s
zOmh!6)t|JbV8#Qk#$AU&>{&hX(Tv~KpmM+1n&$QQ8{{jK*;2o7mhDb7WSjHOGaBJ3
zd2d><a6b?l#{ZI#kO1f*PUBXsd^Nemna%(N5F9NnEvh#9Sw~mhJ$#HOz{<ZnxX9;=
ztK_hCkNza={%jaqv98(wGh!B^+vag_w)KL~$ocoI-}Q%(P#kO=zstkRQ9;x3^wXP=
zFjKMH-_xex^RDC7?>C0vN`d=Fgmv!NV#8iM3R>cv^Nr)oz-0Ak;5M}0T99rOZFj16
zGqp1FxXZcD#QA5USBq)x<5Oy3tE|C=T5IQb@7_UDxoCZCzUSte9;YbE6si|%AX}Y|
zPUtViKm0mxXOtHmH|#Wxhxy2dWbg%?Zl{eup6d^5g1mE*=uT1RgR1}5Tee_a{0oI%
z&YSkfQA1|!{4V!__;q06<PR-&1_lQ3!{t1HFl1>1lBe2V@a6dQtkUD3UH2(&Xq)s!
zx0|SuVf<n3W|SP4CoX1Y;Es@y*^>H}CWT_QzU3z!Uy^+~XZLEy$mH^XBt>Sq(h!kE
zo&g89?yfy8>}dR6XlqSDlC%Bc2-uV^l#SPc%)SRKNLU!Kk5lkt(ncqsquj9Bsq#;w
z24wc5`bY6V@kQ(Uw|toE8(|gIYe?vZ1PQ-uph6T5t@nB$DAfYKy-iF);(4fN;Col5
zl1*sjP(+hEg@gCB#XxNV@TY)nRcH)(JogP$_qnpq%_1zv2R155@s?0OGO{BvDG3vg
zqTOkANxkq7u<w{6Xaer|XuC$}uV&VLmNMKQPsttiX(x;?7^MfWMAz_TReY%&7zg`M
zT&~>Z)!Cd~hfbBzWTP7_Lg(_4=Sly0(C>4q@z3WZoXK?Z3Env{pEy!)AbmX!={`m!
zm&kM=cmuht1Ux#LfQw1X;Z#ct3r1$<CTHl{*=n<0qwn8eVIZJOeK^ct5~~HnR_nV4
zO~`=OQ=YR#b)wObAFxqkOYL^X2xb`~M)?FO0$emE4)BCVu^<^9Rq3x*3C~;1C(13>
zBi(_ko^XjK_sbm*@S#SHLhxo42}v_n*){p@Vs+<5Z@eN7Hg?)8<DohSvmj&*JsJ}o
z3vB8u9wl})Nsh9ZpM&oHm;U3NyA3T+|1~Z6c+46F9UU{7SYRJhy%Jb_c)Od?SaH^U
zyFU=L)PV#91XP+z?PBZlbuh{UTgxT}j#gH_K(y8enGNh<Ki=+H(@Ka3$N*tQ07GaZ
z;TUdG_~>z)o`(zKj!PG&^Oe-%4!?)1+l3DLNYBsD3>vVs%d{%&p`E&l*G`cve7vcg
zw}C4+A|auY>_fv<CZl|AR$o67VTUDZKf!onZEcNg3@}u3cW-`Wyg&PMTU9h?lSzI9
z<FUg_T#a2j=!<>$jp(?1;>9E;QoU?u&NT;y@m`IUC^n-5@Iqm^;I%VpZ^Sjcndk{R
z`o+O~eBf{#zH9VB;==aX;cGxu#{32)q61m`LGNh8bh34m`-4!VBK`%LbYdyp!W|fd
zovY_2xwv6z4RN@+0+vSZ7D7S653SO&Ujv%m&BwMw26hvk6#0N~dqwYRMq(Q}{4PN?
z9;YOQYk6kGUgEAW+OGRrkJ;35UGQXy`SQqxTVGh8vXG*vweN9@HEbj!GdGPpYU73K
z2rf1@5xQ<XvGM2yF>#7rEHmPhXJ)zp<};eZ<<jvH7Aw)W=Y#k6!+^gH^rsr`W`3cI
z2$PoHbfQJ{k><vdyDekVwqIYoP_@b#c7S#oe^ghGo*=;+zF<x&(;iNJ$z5U6!OO$?
z6L6HYEZoiBB@EhBOz8qLb|g_#Ro7l%F6j?BN%ir$HQ=sH(}7Id7}**TNq3mguEW7E
z#YV@+1+Ryg<SQOKJ4Vg{_LuOxa!^tl35(81)O+}Si$i*U?~nH+G%ZcHSH=R!*bRS1
zy}#8Y0&x4AJ@?i~O{2RrV%VC`QDh9C{^^mq15P1BFVx?%HNfWuAw6nDRJ1{}#cFM6
zKS=72be6L7dLL?dM?`_T>FJ8wxJgSQDIsBj2Jc;YD|l{vXjTahg8_y){Miwt{Gw1c
zmXm|S4}n};7pn4bhse+*E@?uv2`UXTMt4ecyxS`(4*OuamF4C8lZ9=Jk-@<zcn8C-
zIo%Edh}+xCy~Vb?ymcvqC15u=hWQ1WOqtm%g@=uci;|>lrH(m2Ir&%h8f>Ovz%A9C
zs$q?KQdq03G%~ITX6LR>s6r_MA%m_ye>QA>)Ys9mV*AD@mq<i}ztG`VFlkfJ>jWh5
zi^}fZ|0(tXrB;8^w4ce!;L98Z>CNKZ1_~(F0pMZaoVlYcP&e@4b9T;0vQ$g1{$mpp
zgM%(X)Lx#{(7lNXe9+pONvuPHr9Le!ZKaO=nZRBQGgzW)ZgP@pJUYZ|kr7)a-%LM6
zqfDc0#;)<-tK+W%FV{%spG?^;|M@K?EhU$5`|F-&^@V*rK}>OB$%9BFkcg<vAonup
zEYa0j!a4VyDaew^@)zE~1xQMrKO+WDueKJN32g_C?i6d3P49hgw@kGJv_U{X<{{w|
z`Y#EFxpYrK8lELFonG!znOOCUS)M}52`l%R;f?&W@hA8|W+0dwm&|0#`x^p|IM-tm
z*{C9*?YRH=@qKV{LQkb@=M~)JKk1MB#9&%vNFwTc!m(^Iuj`<vO{%rH%j^|vw6mS>
zjUM7eH%y3$iDjSDx_A+N!QW5^@*tPfAyuVuS&tjBK7G2D;%cO1gf|<AapsHN^<#R}
z<UJt&6MtN0{y(LvOhyhs&8fu@8m8t7H5$+*=|ofl<mw#91^*-Svc?al1ENIU@JV!a
zt7q5LOnh#RMGqK?13GQvIv*a>`e_2XQ-mELcSr$_f48r&a<<PFA&$%I4X%H`0`Amg
zlTXBPBm@TA()qhp)DfWEdi~#r^3Lx8Y3$pj*Z=Z8H%#mrmzI~?UUSWemk4GkCGP-)
zCK!HMbP&i;s+zgKLYP_%6Kg0x3GG=8efcj})Z<BLzD`|JwYmIx-C#}?a6So0FU)id
zX;!`Z&ny$HM#LNE+4G&p{?YZlR=7(dJnny{4bA!hJalEBBB^38{lC<>XLp*QXIeIW
zj;(o>Cg^i7*nk5JC>UC(I=)<}Wcr->GYG_k{e(H}Hbz4mHLUz&tPK&S5vTLnjk68u
zzjcc{ZH}+wo;kQ|RCrWa`;gH|qhq9p{Z75J3pXE}6>E&#5tIWz$3CEn3fdONHh0r6
z^2{&(R#saZWM(+6e*2~_e6vo>z#e;kKRO7#aXw0O?iE1ez3~LK&n0jij;9hH>iFSw
zdx|@E@#N;qYZg3MAR6c!tc6FN8qbDkr(Qu@oJawSYCJr8|0>9WtAYO|HdXa58rkf|
z=NfkV&6ndR4%|;H+4n{oyXd8QDu}hRK{ZCg5CI()k3|}kB%z>>N}Rd$tZk5t0DO!%
zTb3TEq0pP|)faMD^hF<c<JvRrO39(Hja9)%Qq1<VeF@GmrHkaj%x913ciZu$omuUB
zbT0w~LCV#-H1gs%=KISMC6BOgqnH_<(-pA|?VFXzlEAm{-6vgtofibw{?^8mP#d58
zd8~}ujZ7spArLcLdz6;#GIn?Gsd0`wQxahjL)H8IaZeDTdmVULn5$umnupc)kV0)p
zN^OjfT#!A^c?-NCr*|2h!2(pH=q~d$Lc_hcrdM~Wum|#Kr>^_0BjjF;Dk&I!y+1d{
zhvgaOaU1LxgZWzIa_x;oWhF$_QsAswDPuienpVtd`S2m7%LT6N*N(AvQ*-AW(FVP7
z*+U2Kbl9%=O?Og40@g#HXJ25Mfq0rQn28_id`~(+Cb#!})&<=if=7=9@KrJEfBYY`
zH&>Z?v<XCzy~5oOhDJuv@eKpA4M#@W%>vSY@cVIWG#7?FSsKxd=GxB45D6OaOHIo*
zs_lRk6ZbJ;s^TOTf9r{?-DWPzX<f@}T(S5SteIi?E`C7|G`N?cZg8O-6ZRBS#d3%2
zbwg4wjpLI1KqU{FP-4d3^9$vOS(_OVP1VKUK+1E`;>qP@V}Ov`j#4WF{Hx}^0ZPzm
z`S#!2BGueSo2lu?w1yJJIbld{J0iy`*Hp|l;`7v(fIm;2J6oPY%HwC;sPEsW7}6V%
z+*hYa*`nl~7_@BX7XlA_z1*Z}^JGNEYn&VqEJ3xI+YjEq<3Qiy_uim(4`x$xNprwd
zecLg3nW0T)H`8-=+)kG?eBPt|3}3e&t#5d^bRMi7vX!IPxKh^sc3*bUo3*3AyLi^6
z6F4Xz@2Z@Ng0BxQ_EPj3rvwzh6Fa5467xG>K6$jsm-}VSP!wL$z_Z$79u-5-mrh-G
z)p(I7ptK;ldaK{lQ1LafS}4vn*WKfIND@*q`s~3&V9oMEf{`Bm-A?d+7yVWB?N4ZO
zOSWt~hU4W27O`^W!A6Ra#je-o(Bz-XP~4L$_v;Y?NvzLktqj#BS7->`V)1&*gN3KW
z$j9THQ_6AOTt?{WF;RMx!y?Z*d3B57qZr;cB}sLc*hvyg|4wI{hj!Z~1e5N3HNI5L
z*70{!&%tmBHD7Pw?G^QtG?KtG84nro=4$LVWeKo#e}3*z;@{gKxVE}mB-<wN`a0H2
zy~ce{#3bJP0rjvZAnM;SN|fnFd)?*!loa<Z*o4{T<+c)^t7DD^+UhLGWd;{SJqt>(
zlR?LaRH;L!22|?r&jR^cA?hF_#0ylAfAt&hshFr%-v-C&m+$c;)_;&c9OeMpbBgok
z=4L_Me<P9wkZj6d@^SoVm<~D09Zgv{Ti>Y#UbgvnSEXUMNXm*WVfqZ6Y66@sN)sSU
z1H5rpNFjWH0ceO29lH2eu>7x7{r^=JIRg||f}yeI+BezAT)<Sc6!Y`GnIF4QU<&y4
zPusSH{kKjL`_)okxDGf}CAp%K$e3#RhC<n#;@d6X`@%{7I(0z2zpT96jS~g_`JFUb
zdI;3<|F_NhuPOWARrmi8w=uZ;Kl=Rt?9TqLn!oT9z@tMY?B>6Vi2#Aj97+C>$}E%7
znS-9Rc*tEF9ApxP8fLIq<IkNgWnzaBCRy0|iC-3VqP+U2pToapz_+~f#mA6eyjpwT
zYu?+ai>on=#=;TZj2x(A&Sbxmg*9Ow&rO3QA+^&8cN{gc>MFyZ7d@~iAiWN=#zxwA
z1?B<3e3V0Y1H`<gnN`|ENJu@8R(yXtYxLWS$yA#kx7L_rfZh=)t!KD^6xecSyAx+(
z|LDYo=+^2A(WCO%FQC@g6}~+Sc0vIOJl5cJuVJ)RU(;h-t(k_TDSQrl!N5ph;Mm#L
zuM8*w@<Nfb{f`6P#|G=o57xYpqJjtV=f7oe&%^>u5<w>guUzjL#LQ8!`d``A1tQ*;
zabliyL!Ogy)CM5__7rX~-Z(G2s0}Qhuh*k-;&}!Xjb~siKA3oey1#RGg6Q@?g{yqW
z&#PSWqbmirrYoCTv;F}Cvb$tsv4&VIkV{z})jN}xli_*8)XFX!ANIh71x#UEVv#uo
zk-4?`_lrIwdWt^wd7;mJe~il+>Ud0T<kX6Riu^l<&MGYP-%Q*YkoNw0cK8Bh+rM=D
zr;xf~e)u0O_?lmTeVK;=O8>GS?h|73plPc%KL={E+zFNqf4vKR{nC8-l6ac;TuD?I
zg+N>ZL|WZwW?ZwsAdLRb)hd|KLC`Bc4Pac%JS9_ZnRgt#3SqxL5DAF~Sw<1F69<8q
zK)cEX#U}4YeYgZ$mV&qApLRS2!H#<X5Oa#|e$`16<;sh)8}bq*=kgitT|7B`A#HhJ
z95)(W-5TzJW55EP4Cp1qLNB{5ToGX07yk^ni$ApLqk64zqSJEi<M{6$G{j9_aeAFb
zB511!9=9*>>c=S7u=R%Pl-IIK#lf)U+tP=^R*XjSLbJ;&kAEzBR{%`e<sz|jyR}dL
zLtB$iohHXt3iWM(n`_Q?nM9JRMBeLFiE<7cGQPR{j4ThwVyet1`zCAGFjI4Q+A-~R
zQj#m7ocnbIuzvi0N`MElLj8g71=dYH4=M(#1N_G{D4!EVgjHjb7XJ~2PSM39WAk28
zFSdHawR7uoJS_(!CKoIYU1b1{&AHn9TrFDnL&b+WjjHG8*>5>~o>NcH8$MNgIgp$g
zr0BV=FZqxfu0;M~f!FSVTNV|y0TlJB=%?RLKz_ap4qY^p^i@HHV~!{u-xVd2-ryWG
zJ>={iM*#EWcXpRutF)Xa-mHZ`ds2&e`&}31-}Jxco8K9#yj6R}-$@Qg4|?ACfAC&T
zEUy@#6E+4}|67eY{*Pu7C8z$M`v1}WKh^)OQeOYx@BTlo{(l+lzmPL0=6^tC$(GOB
z>T7`i>9=ImkD*;%<>d<a=w7lw!<Pi%8cxXc-dvUO!5zCowo0i+*?%c+7XNn?*rP*7
zecxS}o143p8#pqF)pGe7w@_^cP9wrJT*o=wD&qQYkQID)`2Qol{|EX1KUb5T4h@rC
zs($JHI!$TcJ@)x`z{_Z(Pz$|0`E#cM#^$k_(PonpH;NxNyE}GRwIulu*K7WN%UAU`
z*tNc<H1Crc4%F(~!K&w#c>T(cPh_+h2V?cvz$kKJY$y^KkWc9&u7z#ppCgxf177zd
zI9P`P7r-|4o_Od}oR=5TtIvid)$7tt`dOF%9(`DY%l>^(+3Nq(8h%$Tf#KL8tqqTV
zbRKXCI*w8(;Tb^6e4V2LA)k3sPPSd&sLTGX9PyNjrHUvl*`FW4%Xzn)rZMfg`i1YQ
z5%l2@&6D@b6HI>w&z&a?J|CJNFMS~P>z6j=kxdx38l%k9;0w(iSqaO)3&$Z@Xo+4b
zWVlQDc6XUb_R`q7#nyglNKS-<^5ervNa43Nn|a}F-mBxs!_w)-9OK)5^|tSCbgPju
zEony)6mRimm1l=z*LMFe_TDloj<#zPZJgi)3l0hHf#6PpdvJFN4Z)oT5-dT3y9bBH
zU4sUP;10pHahFp(@ArN)YtEcm-<oySnLp=G*Q&0nyQ=mrwfA*xnZ6XgrS2J5!(4Zu
zBmDzV^P`uwM&8+uf(sGL$rf7fBBZ=7`+Dm|&Z|&fi+0uDWm$7Rl!p+m7*GqZpRm8*
zs0=*F5ab|yb}Z=+KhUvvtF|y#T83hT1d=0PHE7-po~pU;DaI&k)h|J6Gu}@gEMRpl
zX3ny7M;41aJkpik1oizYcZ)>QdPr>egWYgRD((Z9<<I%b2N%Q;00-w&bU4JPKLaP<
zZV`0z#BXxl_deaGSF@_1a8INSbo}+t_B)3%K`~-bg<Gs9{INf>Tzg77>S|c|D7F!z
z#qk9$V*sem%hZlOl--{b<nt*a+5KH?f}2e*GN=&I-v1B!aV2H+{dE0O9CrdZa>P+>
zhNndKGn0+2J3|2Yv-_MZYHM910%%fLs__tgwdI1BVWatTRkD!X(tyeoSz8yYb@QDL
zZ}+Y)=Jc|Zlei`}YgX^0o81}r_{c$p#PF2Cd>hvGfbUb$gOgY~d&!=M{;P)l_a%+0
zh{t&|f~^$60haxk6SkZX6vM(=+dJ2;plv1SVmkJ#e2j>bs9jX!slN!INA5GXht2S%
z=8*zo7ysFw84g>SuS`E9>;^Flzk~fM+jO1h+JZ)THZpn6Kq9w{XH(MPmTHGQB6oXv
z(T{6L;s?0KBz!p~OjK3Vg^i(u?NH@b)9G+|jN%hSql`MUr%N)zj*0|{L|laI^STdz
z4}%yV7NCm|q_1mj)Z=M7+MX3ENU^S#9a{N^v(3UNAi)aS8MAIsh`k2SmR$qlYB|BS
zxA1(Y?sXSsqlKjpFi1PPe}DNd0)nQAJnoAl(7!s`#~Z6MQy%=OV_AB9z7~NpSdN-v
z?YbE#9=)teUUnFlT(MISmq<a3mdESyut<p|<ZX9TP5IGM=v}W7!|Z9_cnw-6TU&gt
z{r(G>@p00f+Q3fWkBEZnL<-EHWvGN==0hB3p7LOP2xi6ih?3t6r*|h90m>~}n>%mQ
zHQ>q)q|KWz%2JoBmh2J_rMG_;Ri)vPx^G&fw(3>I;~@v#^tqI@E}^rtJ*>MB`%n;@
zS1)b$Ue75rMx93iuRp-K4br6G;it^aRV+OVbC`9F9r?M5)a+tZB+3M9E(>s%0ZZq`
zE<Kczc4k~K-cX^lLl>QjRgRm>qh|grX&I&%=0@kwCzqfwX#Hwx+F#IegPLDv>awHE
z7;2XI@*S5a*Ee%I%!F9Vk5-G8%0TuW9~0c^L8}+&nq+<(k0#5*bY~vlES)bi>SYgo
zhTmaR>ENz$+jNL?Z5<9&#hHVMLH?spd{6SkO-o!^7Y6Tr88OqF7gS0%ktY!ynzoF}
z3&?AX`3b&&w`puyW!UsS;*+`0{76_wVQ1{jVWmHiZsoi=fW;qEEV@TQ%j|BBmgq%B
zH(F7yG_a2DZX_Rn|H7M=i6r?^YQ6h>Tevefb9;^M>nIYBv2f4ks*;%{_rGTfhWrhg
zSF3GjY@rM8gXdt_7h+k^Q4xP=w7Y9925YunT%Ngx<A<lBfEH=Yw0iaxflq|6!{1jV
zqQ}rr0dg_HK5gZ_$QWZ4iSS)q)u(XgmInMx44l<a(C^<(PK+EvVqH)Lkw#ul$Bi0s
z?>Bh7M}n9jIWlgu60L=W0!(-+wd{O6%TlJWS0B0R;+vHUx-ZE1?Nn^^N8_7E1|omE
z?d#DKyA59EI{%q$f%r@vQ@bmYswclYKC^4Q9Dl61yU**+c%P4@t3_y9&GkF{B#^j0
zuD)jIX1n>!k1?#+IXtq(%ZNzYfcH=VUR#TR(|j*W{(EcUfe6gprK;HonXF2LmUIKV
zdDLiU%=`DGcsqU#AN8bReUY0bJwa(na~s5BTh8*S=*Fp{@XR89?X<&yGKDq$C2jN}
z*GO7@!q0R*4Pv~4+;@Hxp1<RwB2KSNDiMB{rl&_UdcXzOh1A#Y;>?3>NGa_&$nI&r
z>~oV>+Ed@p7k$HOQQ3c3ZTtS+JxA!5cJ~dc-j{&9ziMunM~xqmR-<`D=)`B+9=vXf
zhdzR$KB#kwp;a9DI7Y#7R!6fMYohp3zUUXr&-UWjAHhdRB0i+AoJF|L&=Ih;UV2}h
zCSAlGYOPv>AF6PnF8qg=<&^}CVfeip?5D+Ywk&b8nSk`wcQnBT9^B50{&@c{>2I#m
zMDa*xEJx><aqSk4_`PX)*mySY<G-Y@(^B1hoRaPeq+%<#(^^Z<%Ug$*UCV@I8OyGc
zX;oN!FH2Ok^=8w6yrbigc{xvm+~(F`6T0|K-&|CHUQzg7EDEt`(Uwgyycb_QzcxS%
z)431jR^nSE_PlRa)7To#c>~XO2Ps?lc(mqM2ELu9eyh`r>mMqp<S*|tm#iE_1n8SH
zoiD{HT5PV*BRh;yS-pbu(n}56f&S5Angrj?kH+Ud^xgi`J5&B&nmOHO5sy`1-;8{P
z305i*vfzzw<ZZ@dW1HlucvC~ny+jGf4u!k=u<!TFxnLQM#RAT>8Lg+rPaL!9QN{L(
z4U0s6Wk`4K44G%r?gs+~mY09E*`+b};6OIWBo+~ax)$)D`|ZRte|Xdp9{w~;QRI)q
zD;O;JAhEpClM1DlMFzy?PEb%cT$Su;(cP_YMfGnO;3>a1B#11TqY;6Z5uh6aso4MB
z<+J%EZNN_??VWvpW5~@w7k_+pNC<okMN;+s*OzD%4EWH@8O$+;1~4A29-NZd1j1wK
zR|I(NpyglxAzCC0@+aS!P1|bh?JRDrV@)PLDsAV7($p?l<MOD%__qSD`Hlc-a?0dZ
zxNZ2jRD3EhT<8&zk@q0OVRS!gc;UV!!2I9K&*`zsrlZ4vxVfxuIW)8*iFtdZE_~l(
zqx+Mjxq_ZOl5){w{@D)&*v9dGzr#d2cCCQvP7UkCk2?3ekmj@YgW1^>9=?%o?$RLa
z`b|Szj-xi}^!valB70XA`4`78?K#o8@i_O9emRUz`r71$5<n&X@TFiTC!4fVy`qWD
zs1~UybTk4|9DNfX$T3;J=L*ay86_3DH(OYk04pfUM|20)@i`m^3JA4?5#?gN5Op|4
z#3Nb$$oK-3)o5j-T-!_fwF52QX{leUkeMg1U%lwhb<%nKg%2w#XfPS-4v3)Er;4_@
z=eO#cH?=l9qJ}Ms(9llvKPB&$=~@p_ruNbT>4<Y}XB35Er{Wds;`f)oUc4qUzZhd0
zkSCd!s1@LKHz3%ngdA=Uj6a%DIvB8*cwsNbS1$aeRoJ6!c9`0#*9(FQq&*$CevjK)
z%9+zIu&*E>Rc6s?v3Ka{k9y69z@Uc0+eQb9cc=32ES;FsnRBhp0(Hb27EW~%h$9$t
zI;*;#@~t9)@>_IWbw7Ln{T>lYPWD``YjKu90X=R<N^Rwr>A0*OZ+ZD#7dT76`wx|>
z%_SF<Vy|7Fg}NFCH2zUYVw=%9**8+w7xJu$csvbTwyHk-3{T|$<z!r52_HK=YJ&zt
z;oJS@hm($LnZY~N)H*x$5G=RCffoaO9@o6dr09F4RLnW93Q~KjNo)mq6cN_s>wDj{
z%R5WgISiBpeI87U?{~=FX}p@h&1_3<RUpcHPwY>`#5P@wgYz=OlZhaI@RJo3#-qqD
z#dqIO4aid@mbie^q$$mD&m-*Hac?-(5MDypJVO9$Vl%gBdlUR_d_><W$ji>?uCdtp
zsq)|B(3@2leztS0FwgJjt4=-l7g>5oOSyC86DWeL(K<Zz7yMPM+fx@>8ny)Rg2F<a
z1FGn3lP#aG#|%@S6rPl;iljfL4d{*T@=LRRaM?{ybvs(R$b%`AjY~xRdWbscPr3j*
zT3=m4LMl-%(~|G@r>y9M7N(Qm0b${_*FKqVv)#cR#t-1Tlb_$_ED!tc*a`!SJCC7V
z!O{(Uq#z1q8~%kw`{g!tvMlfl?Bu7h%uD|Xhx0_m3jKg7%f*$er3-p>i5pTiJ^r0a
zFY&qhmDFaX5ZDNl)*S}rl#!*}Lhxr9Eb>VK)Q+q=YEri#EPFjj<ViMlW#$7E?TMCG
zd0p7aT>8#~Ouf)d)YDq#zGWqDt-$H*KF6pjH^RaT94RBU@(Z#eFG4W1C4CM<tlcqp
ziA+g(%kh}E^6_DEEAl;_SE1aK{Y8&Eg`J(A$=?dLGamE60)tPyKk>AyC*Dq1_E_|N
zBgv#fg;wv=Wytcp6E5s3XZ~}xD*7-Id9m{KLbst!$XBJ_Gxbl`#OVUYUZ5K1RSNgo
z$U&BbLu-BcqCWqu--c1UlA-3b2B0OEystJ|r4bqvv^=>@qd)rGHxAdD$`P}X(YTUe
zM3MJ##=VS%0G%or&s^R-vGtXDVY2NPIGkZQ5zBst{(2p&;ZH_SSgXy+^$5qBRC?JQ
z@NZ*0aM6^0@!5zMnU08O6XYGI)I+Vc^^Ni2ap=E;oQRR=vn|R5FrZBM1Q_!&e|3W3
zjahQlKyn1mhNeSeH4>+PX$IvBN9HOF65-}KUXIG<1T@x;MAhQnS=C~&G2>fO>EqZj
z&z5hNby!HLc5{fw;4^;La4SG1=<tkxoq&hrkHo1FT9;;Bl!u66L#Jo{m9{4C!{BgG
z-BQ2i5AvYHs!;KwlzzM<Yt2(m*_NemHg=G~{F#d1=J+{*h~IX@Uk4MBM~tYdksv3R
zN-$<e&}cFw*>c$3kPy^hoZ^Q%Q5n8eW-4wjbbhH%`KEw9`9^KtoeO2bUULqb>PA-`
z7aEz9^o!x%pF{PX?8O4mBNYbIOy_gqQMlG%mdx9w5!itU!E~TtwQbOTbVD0tb4$+c
zDH`G_;HNX!yY90J#a48~+ej0=IWk%2jrEebXz9C|PV7pS4xD;m+$1%5yuVqur?fDF
z&djt?Z<lWf53@|@DTyCr$&s-#Lk;q9Hrd1*wPQ;fIL;E){I{Bu->}fKbbx#eSUEuG
zGBbceGFiJ>ngAi6Gb|mRMw^NUM6K0v;eB<mJ*_)3qhAp<_9xB`X|9&VEIJ)+Rs%Yf
zZeeOSQ&#<znN@GPxVG`I9!bl~WGi%HWtdD44BaD3&mAsq(VVDaJ)oa<Yn}<69;ay#
z>1FMwKh={~wp*uf*0E^*T%243&8taeCaO1XCA3YfFJD<;9%rtQoc+~h<u`<WYide#
zXPDw(Rab7@-W0Yl;|o2wqRd+tBs7?lO~YQi$euFf*mRV<dAeC2@OOM45&~XxOp(vG
zx3q$J7SKi}NETcrHE5qbX>JE#!WQdWYd<)YA@!dykJT-X-v!ySN2a)1@aXGk)h((b
z&7oS%6rb_<(Z5|#woNC{|D@x_ddK$!o9VnnK%T8v+1??;oNLO-UFzy-Eit+CTdaWQ
z66EAz-z}3LIw^9-PS+lgx;vszgMYd4mw3Zm7nD)Z=lGXZl_SA#7Uc1chAs)rwcIW4
z1UzfyBKLn^?px~=mV6C+Us8K~#Lge2B8f>MR28pz-hgmx`7_zVi`UCXDu(c*p6t7(
z%gT3uWhpYp>(gn_GOBhL<a4N2VQ$0c$<|Xh(#@Kj3Vh7S$+QzIcK1gd7E(r(S?M$h
z-UHx*<QxT9@ns9BW9NwDn_kVfq_S6mO$QOOhd&c;85O7h@2<(~t#9Z8$2o}adXxoX
zq_TnY+qYBSRA!aIh=q1XYc0PR^3|h`J_$YJTBq*+rlW_2CIqiD*c($^ioQK_AgX60
z=TJZI{Q=R)CP8fgBI?FW(a7H({6#cNkv?-z02aRf3Ko5`EHVN)tfF@$9xxWe8-X6@
zVN%DmwJFbRvCzlr#;Z1#?e1O!&pAt2f-PX5nmoQ;vJom{|6kakKaATsxd6M{+1PZW
z<3ncWL<lbhOZ#i<oGHMxl=PCGdI)oU2Bf&AY$JEK57$eAu^YkjSpz@6WZDmwT^tN-
z!~({Qv=V6zVA-s<O@OkxRk`ZCYFi=mS%Bq)<ggO{Gw`!2Xn7$T#_hXmFo7ITgL&ga
z3Bdqb{YDSw={v_39eX3r#G5LQm;1KoNUgFzu~>wJ4$;xmt{Dx+!b<L5b{~x;{wsz`
z4m9?K=mYX=l`Zm=xJto%XP3;vifTJN>aoOk&&ahlfHI-{r!q)?Rr=rQkWYV1{iRIG
z?1er2_S)Jg4_Hp`xJyC=&LYL5ttG8s0A}n_Y8ksLIv2BKx=|P%t;>B*$-ZoP)v}dQ
zBs@i8j|$JMt}Aa5HI2d;794RlisJ<pvA;f!va?q%cy?syHsem+KM%?-d)iH%8+1_>
zh=cRU{+n}HZ8u-1N-i*)%|y?zzPh%e^t*Hv**Pzn!vOjCqMV*BLug*g??w_<J$Kw_
z*mt44{SV3ip_)HG^MC#U!&J{K^s|;Zuxc;q^y?p<@Q5M<NR@V962IOD$cllV1Z`aV
z+uHal`*vRUbgY$h4d^AYNO61Z2!Oq{-C7qmqsTp@(6mx9i)RZF3#Ws*>NYd`;8*5V
zXnBD=G1}S2RljOBdsqlayIz3e{KbdO!xSn46Jo4!;5u$uK&%0SXhFoNL?7&t*tkMp
z2fv8<DI;6j<Q6Kb*57-2j`s@aR{fagb@iq(Z~x|OJE|QL2Wd1cFV{HLI?b?jR<Mu3
z=?Z&k3{uaTq<D$l?f7+5M37=EDG%!h3js^%C_IN8D!~U3d=?Qd##_W6{!FQC0>|)>
z4ZtDeTgWG#WC|YMQTdq!JG^RZ_a}q08dg4SH}z)<?gTWv^$(F2_zq;@^*n`QRr8;T
zHzDHx<!<r<XKRYdPM_&BZ=m)Sk<#LfPuEQ^j<vQ}F1pPt0T}$%>a;I@6>ps!I)5HK
zuk_UoV9@+_j#LA*oq|WfK!g;)(0lu7i9Aex@$w24fhOqIQu9?9e|C(oR`B!GS<5vK
zn6$+<B40m}(cc*1!bU?rOzEfm09+5uE1@I0XY^L4OXa`vwEydO`QJLqxHMZ&^Zh2C
z=wiz$Hp~4==ozAB8?RViwrS_coW__CicDBa*rk=RLc^{uP0=WBjnj1>eRie!`|^b;
zt(KvtM+3x~9XY(Yt0)yfs(m*lgH;)H22TEw4>B5U34x?Y`>APzGH?c*KW4i<K-&9Q
z#~i+|xA1ChRLDDZ(}F!qz^qVx*~>Y(Ik%AK@lrJbsnu}HreOj4HpxTy{S^W*!#`!b
zVo>loYv><Jci#Y5Z0esUpU11OfNN1dy{zAv^9KG3TtsyFmuHc^%jJJKzWlSjxy$+I
ze~&85=w1Hff(|PK_SLgrnecx7`84SFjQ-BE$bM+|i~w@H#~V-bHm!`973J{&GyQ}6
zm|*Jrg<;2u-<KL@(gK@%y3qQSxD%tMHSm;K1twZBj?)BpfPztepH&zkn^E(aZq?x^
zrHEdQ!^Bq4bj&80$hXegBzYaiacw)^IZDV{W0cV6>^f5<y1?W2c;;eqiM6j5G$-i$
zcy>OVGM@V0&uf(4IkD88leCubGyGiJ^nF{mXV7SZt#d6T5zG^ASIBG4I>Rg7^%Zzs
zpJA#A6ps?N>)uBVbALukP}WLXyf^af4>gQ7GLV9#9|19N4B4ZEg`gu7$&auh<7O0O
zwUGc`X9uD+zf_mJnV`E?n?m_}KSxqPrvEK_^!SDR6-8Mj<tFnL#Ua<dNb1zHm`=gx
zw9Wc&u34JZ$RnqjiVY?_sYCa6enTrtkGr=&^~lB^IpPN&Zv7C=Q@yJRu`pOTL#zV$
zz_7!ZJV^54h}9u`P1@^$a@=r57#>AiZe*pAb89~B@BPEc&(*j1_<qw+#yQ3E`n2gP
zOby?Pnbg+l#0Ooaf|4!#x#5afV;ehDdNcQi!@cEl{n>%EA*f-=8;M8DlwYk^FUOec
zM%yNbCiv+Ex`PO|tP<dgJ2Le9*U|=wRmUMC+i9RNW*%Ai4kLlehju~dI1qCEU%{v}
zB#VkLaz_H`>8H#08U60IS8m)Ht7po#Po`E_piO_x;O=O4G2$1i)spC~Ee?Kve$)z1
z`2W2N!920&!c{Ug*1#!VId}=UZm|KWhs$;rA-%h~%(HA0FDH@P1j5%Bc-Vw<vB9u(
zQPZJ^;tq<0HbXC`NI)<aC7lytJh0JWy!+SOH|`jF>*T`YYr419f;_Aunk0nzj7?_R
zlrT+q0XCspyLIec0+V!~GwJYDESOuQKoz_Gu^yT~`QX#e%`BHIa{0D~DErgei7dPR
zinh-<?_i<`->#zlKE;69V@%K+0XkcePac<*h;y?8Rf+cV@oxS2WFuQql#4y>!vUa%
zPGM#qDEs@_fB>^Y-rLdkg1F?9xfr{L<}2bcVGOb5-OL#n`&wYmcZgZ1;4rA-^Y}Kq
z2!G%Btep;c#GuMS?qg={UAgW&T*a0OlI?uj-BKrG7jo&W^BiU35ryEmAd9T;#6q|L
zAI%>g^|@cbCC86#OEY9lm6sNxV$5@dwsoOP7=l>6Zmj}+%SjId{hEf=o{G4X{FO$l
zq3P0@5TD50NYoor8|1!o&~2|PvI8F%W=BzJF6fAy1Gl4pC>Mlfl@1!?g(CR3HfxRy
zzVpEJl;q!t_tXiVL|`_6Sqxt)rZTT`Z^S<|Rn~2KUqO=+KdE4O_JDsgqgP#%Hy1Am
zA&_wyC-QZG&-X)yv@4vIT_GrM3$+Q1`S(E-Npsu>Gc2NPe!~MS?a2mR9^hAkykwCO
z%N;X&iYSQXFjR56t<+pu=HALX#qC~iox;2N-R?u9H$OetZobh;Ym)0drFXT<@g4eQ
z96zIeHRSNIkUm)Catqk-9L}x&d~?@%N8yLrVGuRyM(gp6sa~atKprNqzSq>om%%3I
z9;u7F-*VM~`y#y#6s0R!X9qPf{rncq>^13Hxvxe85;`;8KMx*04t0dAEUHZRx9w-U
z3&R_Cu2&1vU{%GHvXYE#ukp4@wbvTkr{r~e=}5XA)Rl5i3~TGmFZ>x<H2B0k5R6ee
zXW8U$6!sED<lgf0m6q>vb^ls^J+W(<iUmsQ=id1$xH`xj_Ly89QfgwrKYgZ|Ze~B^
zyJ^mBWc$<!+*{wV*1HKrPmX)aJBbmw3r7=p`vp^Wv<>9INTejO<m3TvH=6zNo}a$Y
zUw%{sfro~A5<8~hQlHQt<xLgwDn|wNnXPF|N$Wv-8uscho-dZatU?rTf+w~?3Sn6B
z+6O2+nS&&p2e;L47Cu~8{9#*_xOmG?*0WlsKDR8>f!cZ4Mc3YZkcme(YKACY6&xM=
zG?Mg<Dz48Z%Hz!8k!I#A`_<7r`+8XtR8}~*IUOuWZkm^yl3IPbLQISsc=}kDtX7s;
zH5tdc7!O=p5lZzamI_^z7PX3SU5tj9pk$MYp=77IQ+vEfT5R4ft{oI~A;I<t7&Y=d
zUp(*UqWxBDBZ9LcfVi0!Fq^O7$!RDs>PX*QV@c6`>E^d%GfwX=b^Ufz^~BEosC>z_
z=4X93Bj;4Q;_d=}AR~;pEQ4(ldT>jFko4zFSFoe~)(y>Mz<bj64Ep(`Ea}vZTyJPz
z@5pCDPl{Ep0#n1SV*0ua=#XPCMHE);-y;>d#(UhCy$4!Kb*CuqQixoe*}_1~%gkFu
ziO0_=()l4Yy|qV<NB0SxgDA?0Bm#68M3QgW>iQbF^w8L0jiyri3lu*-fHncQs<v}w
zu@^KONi;Kpl|M})B*vI*()Ji$g2c*R+EVJ?lmzNR_(H`umn1EkGOlT|jIz!}fgke(
zo4~blb3Q7u{)R^`S*|0$$5?W!hiO~I$$S3K4wN-1JB9hR5T&^JoEUfA>#3@CbrmPE
z>>tk)KtdiJ`qMM4ZrRjx^;?T`YUes#etwzNYw4N`!b2_WNzSzO*{{`vPc{2Hv})SJ
z%G_cFz>TyAXRnxNdx(Fh@Pl$7kHvj72&n3Y_R@934rS&M!#DZ$k@L^1&ioay)&Oyf
z+^_D4-GIznz5iNhuv9q7a6BKpqPl=k821SUPT{d~gHh-0dfUZn3b7R)1JHTcuGi5}
zg3(oJy^x+k6y_HdzO}VP4LSP+WrX|viSN8wiPuimDraTShZvGW`S#zFa=!Q_jxoAC
zRWdD@s}ocDG#_ljxmohggbpIIYNs{=$23CYZbb0orvj-^+XeAjk?Z!L$ny1H(kNw@
zmV|a$KiN(47yjF$5_2Q6Yk?t|nx7=799aB%WThj$-5EVVLJp(;(P5e*PcY3FVC+1_
zM*AjP!pda3<XMrGminGT&-ZU2lMF)D*3-2qOtD2Wc`tZ&4Q|zwcCHzTf*DsLZBwNN
zHF*f;Y%OjS*_)dJehGxF^bn>ERfHYRa9>ItYK_!8N%jN@goyoKQ9Nr<!lru53E#2&
z8o@s@IvOM(Sqt~$V>g0~ExAe2bmjUI=$?y6%HYxWA!k&L_vy%sC>!?yv|$bv_Jj6X
z<q5d8P<Gsu*75@|2&KRpLvSXMU!%`SqHFMY@x}3kw4eX3%<VX(ZY_nO!9Xy+;Wcso
zo86EN(fZ4!c>?|d!uq!dkY4W#+8UQC&HXyFkJzkVc4gLrBv(r34_Z`QcLuR;H&!Py
z3mz|HV<R`b>x-E^!YICk=8TCC^0K`P#D<Y+_hm4W>N)Nl)89{DytD7g)(}Hwx&$3#
z?|MFNyiAJxnYqlkLYUeSfB#}4T7XxPysNZeg1-Kj%f@*>ZT6aQx}6tF_5fC$A%e^D
z*8>b*+hzSZHz-UCtIjF$j6Si`Wn*^SZbT6N^N|)GjuW~yV9`D@{Sx)@(J{>T^KkK(
z!1;nh03+v=GD<q6q}VUVVF|&Si1BLsgm&#Sn#q)1!QeBWwFZI119e<3rr&$Ecn2>x
zJFspYG476e^Qo9TsEpP8WV27PWSu>uNAal7<Yp~mHFo=xpZiK_@Jg@Q;dD%psPqg?
zG&yFQcVkX41RfdGirjvmc{ms_hgXKI5Tv^W5XV;o-hwm1utgo{Cw}wEk_3slS~_g<
zx9+(!b(w0R?{EX86)V!dx_*4+%So$@C*rdK0ZxfDM=yKtjN>CwhNKj8bjan?Z{M81
z0uiL|H*{+h(W<Hx=G=kKwfk-t6opc97Nws4ZDy`-JJJ4=-bJBb;plpOGTD%=)<JSW
z3NinKPFeOO+hgQ=5lw+r_v!0|NoPNkQbN=nkORv06Bgdt@AOz!?{5eB^#(o9Q+D7|
z!`Yt)!F?VOx*%Hb2^(wm;_nAJo`VHs(K_P^_O(9c8j5oqrMAB=sMogrb%_+Yu{Rs`
zfzdy`^!q<c6hM#8{vb|)<4t=@^s`U#Zm5cGUvFsy)n};Qe%Jq@{(uDq;mcVhZ1lk4
zqE$z7>HKje+()63Vkob*mB-ZA@X+G4#W>$y#pFm3nC2nQ;x@zaG<2EIXMU?~QR!PN
zr!MwgH<i6GM|)(!wx)%@2tO1(Tq*9S$Br^*)2r+p&0|BfEzXuuVvDS9>CP-7T4^vN
zT&rB{n_>jo?09nyxsT~V;xS{Vy4kkURYB9){lO-XX*XoHbiKRrwa{`p(bvs-^V4w=
zio+b+1R|w0wb8{)_{C(_^JoMl!Tn|}OdW1wQ;dy86C4dg9;w;ZjGFUqCY0F+92Rfl
z?E2hpz6Xu6dU`E?+VP<dl=T{nAgM}Sc5__-KIF^`iHEw}ZXN}!|9mmX?C9n;rH-D5
zvm+Ls9pZcv+mQDC@>53Idf^*Ta;Z`2(qQHfWR9dzJl%75`I)or(fY^Y2-Z8J2EZ#$
z*?Hg`fI<J%riPo#g8(QLgkuNA)g3W7b{nh$eq2lK(EK+fQeAsNsS<ZG`2IOtO?4&A
z>BvT49`l*18l#f@{h%uHIimSXYf7m@qzOkT!{J$k^ljvmv9)}}0hS7QwW^Y_JYJgz
z&c0rUTru5ZeL6I`eqYP&z@aJh;1mx%^KK>9ISz}iW%{!jX*D-6as>8f+{$#}1V8=q
z4NgaV)0|Ak%4^vkgX!I8Z*;DJfq}a3wKGO3U+!{!z3iP1qk*n4%YDNerk&tTt-ku<
zof!kEkKZutZ3(cD#+)uzTjAL+g|(=}HAj7SZwk$w`(Yqo2bn>)5UgU4OQ)1Zr+jEB
zM{WA{3x;jKNh^2i4w)ipIMb<GLX6~LPSgC6E&w-jth7+nm_|h!^^j#Vg}aeag*C0(
z9@*)(EYbS42;AZd`@(jlRb^tN;N#nMS^KMVnG8nF)f?5|HVlnS5B$;oeJgJFJ4!R`
zBoRW@BX=t|ev#UjS~>H0g0_R`G~vl9<!CbhK0cf?oEs%M!qUC({cqMFPT@vc7aS&<
ztf~`CZahaQqyWb;+AvO6d=!)ek~<5Wlt|84eEInK6AZ?)oGNDRgBR#gXnE%O44wQx
zLMV-_6V+&W!--?h7{Ty&MAa@Y-nR7A4!h)KWzvB&DR=B=DCQID7hX^B-i33~XTSlD
za%)02j?a)o?&3OG5xA^-nC6?1Jq|6~P(kfK&TS&fqyC?W7P;D)^z7NVPH%g8frt#i
zjwi{hkD{YeAR6{}bZ236+~(cp2!Fju-@C*m1|0X`{CAkm|KJGy|Jkk_?<K2j%$gj9
zkp+%|<-Z{j&0NjBmKNP$E}+(tw*KEX1$J2rVk?4Dc)6gD1&;rLu0+#(FE3>p<Risd
z!5XHXYd$<^6@f9~W8|8q4z4@{L#Uu&lUD@jNV%iUd(X|(DU51qGOCw0hX7z>;JZMH
zp3``ZqsY!$m8GdlW6p_jA;1UIGSnmqz;K9{yq{0<;QY6{`oD0G|Ml)asEEVvD%&jn
z#us^%L^CxfIQ`q&lwDq4fmDja=FegrRV59}k%u*lf60P$%c<WPH|?bjk&e>=>Goy0
zexGkS{cJy;3Q~Rovo-=@ue<C%@pl(9(=q6okGu~-<t*G2M%R0m!Bz{okQq!=DK~<d
zg+{)og;f6gUI%=e*5EP!-C}1>`wyuAuEYjl8YK@J1k{e6jmSG^K-sLt^~8ZMX=;+I
z10XS@xI}Ov>UXufl7TNygEouFBn5CFG3+CZ1}^`$qtm@Nu2_r7DIrOcGZ{=(LT$^r
z!|(_4(0VuIRa=39B3Iu|x<|6#_4?+dVwj6TUl)CVw?2guYyxk6x~igjh(}We<aUEu
ztDNFaAIQ*624iF&?Z#x9%vIPM|MPH1_fxuBvZ%Y`^~QsZRcd_?-od2oX`7&Y3+3H`
zwc_dm7xFueGyyECpM7F7Q{Y$F<wJ&UWDKF6)=5nZ5KzZv{Qb4;BO|Do@bFxG!cv@I
z^QRCXA$++HD^pzCSJfmIp8MPROr3XUR(`D7b$K;HWUKIBLp$@AOTLj|#iQvj!43*6
z{Ro_`M#I{P0@!UJR^c;Q^l(YaY{Ld_`u3=oAGaixj`EK#E4Uv^HFRt?B%jQ_ayqF*
z1P@G<`&`(4a`X^WF&y+0f@{C5Q_jfr^PhMFxttzTeb5WXA_|K%NN)exBD6TlUcR}G
z&CuyRg;jE|usrj`+>bruMIfnoSYXQw=YODEbuvgeAZ<OPTBbrOf><!IX&sDtm$*^N
zOla5Db^?UNebajvVCDs)Zf$~R5O5+B`!tUWdV95mo^`%s0+RgH2N!rAT0cE%6+27+
zXkgy4ySczhtEI(0$Y-h|bk2U6?UybxvdyZu)zU)7uo(^W7Q7n^^CbAK`zYwIW@Oht
zAl<QF?%jSWK0O63NKAw`R%a5^*v65=Y|u`^zdTtuz_Yh175U64)H**TdMVybWbYii
z!hf;k3*MB^OYai#)$>~j+fKAEni}b$)FN{6;=B*5M;8!IZuT-Lv+6QTMyA?pf4U?U
zMD6I=+z<77-~x_^c|V-}JzY7>9Wbanuqp5h_B*Nb+(RkQO4M|xu1^5+!UR>}&bzBK
zPa<Rgx^dx8SqsyOkpKrn@aAa(aq6upl0~QnD2spmIX?qwxd@Rjvvvt0Nf3OD%fNET
z+bzgOd+`meV%mO+k%?ynU2L;f4VrkF35PRNWMONH>OUC5&c|N=ZI7IIp@`PMvsx0w
zbb|vDAvOHY_S7`!Csmsa5e4PR^?1yr@50rjkI`zE9{gCf*eH>oZ@F@j&=>!4A|_E_
zE9}>5>GDycLYp{qviMr!Q0@Gt;Pj=GIx;CXO?csusOJ7DqK^VH=rLHX%o<t6fs@@t
zVc$5rsw-(4$;x8HcblRdI#%>%;dZ!yH7IhrD$1x%g-7Bp(k5trm6|V;O`3~EFoAUG
zd2Nt%=JUoD!+|uPm-1E3dARv`W-R-SIXL9lk7f|u@sf@nalTqz$fZXd*EPr^EVVji
zRS*I(s84OuwMCxpxzYS`YG4C_Iy3y3pPFmwFDcC~DKE7sA{z^sk%fznVZ~#D0^UZs
z`emyhUaUg<iujutoaanhsr5@6Q|8fg5c6W94|MVU!|NZ_#c1K_M6#!=V}{!k2AC3X
zX$y6vex%QU2|g&D1{pdvB|!eizDqM{tX$mT0jkKcrpV@_NZg%6`KoUI>>0rYy6q!V
z)##b_JPyw##E7(lC+qyYHG}+_KWIc-Lv~sgzcS<TQ-IVTLGyhCAABcE8vg!j>FUWF
zG*UA1ZJD8>X_=I+dc1`e(`F_@F<|DN=4~z*%Z^Gp0yh_*4~NP-@qCE!<DSlF!HwGS
z1;<!KC8r?!=ICo_$bERHAby(8FQX#xd`n3xQ!JoiwQDEj9*4nGIa+1ez-(D%p>W9(
z039pnB$@u+fyW@yQrnk>w*mP0I)-gIUQ&n|hcJMU5-~vc>$z~(eSPo@P2C8n2V|Q*
zu215zAoZVR#R63Ww_~!6l2dCdC4V&GjzeKUu7)%tw)-<tRy5y(WnW&<h#*|Y&9+GM
z@qtysZ8o+@=G}zNhF$PulE){DOZWB~AD7_RLWMGE7gSv${l@qkI|7`qIR*)*Rl<7N
zqUv?q(uxwJx+ObakrsY;o$U-d)!S!(mHpyAsmD`o0nOlm%As!t>U_~3vj3E=c)60B
z7-`Ko+n&HyB>aAR*sdi<6_<aVX-sgg!X0okC$$L(S@mfm8+J%fDOFq;otv;adO>|O
z2C$Y>HsS={D2bj*1Pi*DaQ>RZ)#GMC2VupteB7m0Zg$GnMn;j%qHi^x$|p+dLO}~K
zBgd=0FWYHxdK;RUj7#T&5=Yi&$K)V(1>bCs@#RVONX}yTnzVV#Esz*f{chd^=xM^&
zp8UZwy~>Aoo1nOLy~}N>=Htb#esag(d<CJ?-PiG2c~4!j2;4-Gkeb>B`hcuGT|&pv
zJa<1%j<=QU%8hO>vb^GX)TA?0_BU(q{C^3SZmwS~P|EbS-F%$i7G-J}G!QwMvfNuL
z5IsAchjid@(yZm-`d4aN$b+?(g^W)lQN8a!%Y(6|W74(%)%8`FwZGmwh!~u59T?L$
z;@ahpF3<1ADqRi&(Jd3tz9`O-wDg>D0*bAgZ$H(Lm8ie?+G}1B_lnz4Xs{U3(5zSq
z6u&G2@;Q&MO@L!)i6@8&hVyw9Ywb)QZ+p{bm4W=@eE5lpK)05ra9BzeagZ~uzA01-
zevHvGZ<z({W0_$bQ*YMPD-X>#-v!3IQzgO1(*n~LNQ3Hyt;DjYo0w@Ib$SXRm>Thh
z0)ERXy<SDsHv9n$liEQhR6CRLU*(v;8@8yfg6&0+&;thKLF;yt%=jGp@4O6mb2sMX
zVjuGB>hhyMz`$kwP+HP<+icswQ}VgMf2}?@#0ltk$hA60o9k9Tbm#&-Ky3r~v;1u*
zhwnOodNltL*HeBG^!EB+Cd_on+D8N0m?ciKI6kI&^V`R#^wHU=at)n2#W^S~%3vLw
zJkL|-FD51AzYG%F3$x=md*PWyR)Ltyufr#P2|TZN2R}FIY^z7w0JT`lx&M54>p+-n
zrQoozJN`Cu5KrH>yJumNCNa^%Ud}ylB3Q%C5w+^AJao$4QI~`#P@q8GNmr-om)-On
z5uo{64>L}zC>XRsFhS=o(0G6vJCjN_%qVYr>4F24nE82=tH2)R1ZaFXqhq!r%FoK)
z59F->xt0fTY)FHD4D6rDI3Q46J7RuGwV~S%C?mK^pS<hd^2~b5zoch?xB%KDEx>Os
zudz}|{6%z!kh23f_yYn`xL8uWZt2o%5F|`&fSsLVtP@dM{T|#d!Dt!Z_>ZWUP8)6}
zQKRx>4i1HNz2+B-H^clGT^{uq?pGMkmO@7OQR{z!iv8cBFaJv<@BbSuGcJ*X6zG6j
zCNB|xE&Y=`z|~ksGZ)CWK;n+_5&LKesCfbuhxr%@yy+i()UR1H`-*h2K<;OWaiNj0
zW-d9v=mI+7jW`ZaH)e@EsAMr=cQ+jH3;D4nkAoQ7zj4H%|93<Ic2xQ71AsZB{}Q04
zg~`XBV}7Pn<X?j+-0_};`P1azv0(p)<DdTj$9Nvv3cE)jU;^TNv?ujl*)vuA$LNwd
zn<$fSVV;W2vl#n_mj1svBaFM=BL5EHr{q8oQK4@Td<8VsO+0XZq2_7(n7|KKJ2l?I
zfp(P|8MIzR1HJBu4jen1PX%)ovxKSkmAF(dl4Ap*m&w%l0hslSxK#LXAX1D9o}Ot5
zuq?&w7>TPsbsT(eitxOff$>#bfXCjrSw_H-%mk3>fpRMj{E0%DHHl(JZJj@f>x*0m
z${s^UpYLW9)8YqAj|hI<AVX;2yV{(g$(lDrA<OP7weZ>Z3a9-TaAJKPwMKX12^%&;
zii*N%K*S2<b<Ns$P+)P3@WRKt2+|U$)@j**KpS)JWFd(Vwf<2*P?&@))tIbTjlCc2
zHf0;TC>FQ7zn14%T{h^Q;f3B&QKko%<uO``lxZtlG*BY(11q<=$V-$LUAzlgu45IH
zS^`)8R=R|yeDsyT7huRMN;8P2sp?y*sbr)lq-~Ol=3t}K!1(#p6OV|-2|6Ap6<`@=
zI>t|Hitqbq;rUX%w8>YReLqpmCZ`qeL%ePM=N}o(mQUhJRFQsHvbx|ax8gT=r#xxy
zEZ=$YMMCQar?8nvTc0-c*y*+GiaH&;>9tHQ4UdNVM8r;t_KICK3*TGBV*mW-p}JSz
z*7SG1*?_SK9)9B~4zrWhmHJ!&)aTj9DR~cUCpe4GK7TP(2p@C(K1Q%33EKKodj8tL
z)E2#9n3P&S$bo=ElL*xlNeXHu=7^YTWpsBvb?ggyZ9^asT7XQAjRU=)oz$-@(?p}j
zE`)E4W|)}iLLn8cHmDO?Y%zCqdI1WI@b$c$_f*X_LawMsBTZnboGh*W$`#-Dack6(
zk&k+G?R_??1V!M-W{o|c2#x+y2L0A$IvlLQ{kbFI&Qk#t&{?fk!ws@6o`g`SaZ5^y
zg~EaQn?}O8-L3#1*1<KnHl!Y}eKnh;sjr*yv_Hv3C{mLOd#3i7cP@t{8wKkRbTaFl
zA-Zm-gh}P_GKQJdp)!xcZ#*Hv4<z3W^sEoj(!0%SogbjZrCoQt`G-2~?Ly3XLR=P6
z7W~fbwMrV7k6o!)NBWr=jTU&}jYk>YK)ib!g;xofMUMiiC}PRz39<RZK{=F?V(!^s
zY47TpPCz!W!0|MfsAh_1tQ7q;Ds`G-P=#GmbxF3|AnFP6+RHb0HY~1{SSo*OX1G;X
zCOA_-x$H8Q1R2w9v3kHVJ6a1!#iB1)u6HpfoE6@`>eBax7&zaIT-*)AqdR{($|&>Z
z$v>J)N~pJD4s^niAQSYymT~aOF&dtLk!3ZzNg0+{G=evoRw_;xCr=mE<L$LImgmUW
z_=1P$+kKxNBkm%2*xgFFq_GP2U%u&${6;MJ`c0OVlpGT@Jt3^!tnlE5KN;^fa=kKs
zl)6?ZXKEJL7KZDs=Jb&{Cx>OQD6!1-BU=b^_$zWQw+~WcuyvG)Md7QAaOecDrlstK
zF9qq5*#nW-NbRWrGvDc`6|YqsmD@-{BH@lXv(F{ie&4CAdVe}(;Uk+gc6)AmIS+HW
zjh4;rx5}wa#>DrzQs?MMe<H24$QAYl8ZKWng?AOr;UfGs({<>0Tu<(hl)tgSlK3pv
zJ(hu6ycapiQrx-jT+R7<{;G1ae|Uf+xUWRVoI)gRbAhYQiqC)D>NLDa+SCin^@{M#
z2B8JpupGNe_~G_JFVXbYf%`(YNI!}iT+Lx@Qp&AXABCBk8jsgioqpqrO{0@N^P76x
z<A!e_R?u}%2yC%|mjc!53;2l#q_=O|62W$Y>udAj!_G7aLBLRtuv}|rmUh6Yx1${V
z;q(^aqHR)H9~dhAg(k?8HhtTL`=u&_NsVWmmZOxyFI2lSK0Bz>DQc^a)UCQz;^LNt
zzP{BS-1mvF(1*U764Wk0_V-tM>t`Tj3SnwfQx8k=^L7cfPpx!@e7MU1p`#KL^QR-P
zz)=Yoc<eA#XEI@nS(jFT!Qu*|r0ukTBhnwN0;%r4ogZ51!a+h}aCJyoFNZWrby37P
zNU~LQ_S`XNq{8=6{D=8l)Ci`^gD#T{TbLzKjF$|P5njZ81KGLCVUJbOjmKx1_xGuV
zWs)?wskI$eX`rXilPHk)3IB9tnBYxd;z(fbM^s5p+{MdKNrMdN9+@IZ_lCT&Ihr6P
z%u^tnI6n3Yf7QZ#QS7#Gqq!G;P4U(`+M2QajN8)tD_eu5A@=l?NFEVxmPlzB!|32S
zy1kJrcZnPkE^ZdG@yqC{3zoqu5MtI>^j2BDpdXeyK92tOpFTNB6>XZF-eQ#1*RAXj
zE(7l7J&kZ{hj4L(o43gNqC41@aM?BsCu!Zk>h%nvHc8|Zmdx+IR>n;sgK)z0RIEt|
z3t~O?BsmBx=U1hW-|LGfw^e#!r`Nb2qJS>%uOE{N@?j5-m9>jKXi6?;;s<A~`=xFX
zb51&n9ER<b^qPA3vH1ElHNStC$t_>p?RdXr-DGR&g+9%Fh88;pL>+jxU7nD0McN<Y
zkz_<COpEw>xE6IbFU|VelwpAo;Y@pm7dQgn@dnUg)v^(l>Ja<&sSHM_tDbzfinQNf
zM+aF=aGJi9o`t${b48#>Mq#NSsCb0LZ|6(+5AY7PJ!BOsA?XyY*)2%mJ9CX7O1cya
z((Mn|B_Q#%jCklLx(WfMAMo*uTeyfH*AAEXFES!IA!dpYkJ;soRtDKe7x~9vR!a4i
zRuVq1y{<0(($%z*m5SU`_R&Qc5dk`siTUt0{WzqaJThvg7B%X{*k)Nkd2P$cOp?9!
z!k;tmuV#PY*yvdcMjjWWuFC|;#$H>@+@P&AzrJS)5?4*H;lI=C?uKU={xTlY1Oib@
z%YG177l=(SK&MP`QRBs?9+n;s+svL0Nq_Cq9R8-xRvsbiP$0*kVOW;umk-T*8M5(_
z(?Ww$u-4JtMWwyy+qZ6hp_-}DFOc*I7C$-I?=SIVDc2b^Q;SYk8Q+{@Se?vv8}(Ja
zE@f!3ny$le&>(25e2CfO>ysr3h^FahB?sz`HFzIjzO|W@PY5d0EBE{RS^2GqjzcMv
z1wwIXHu?;0gfGOaep%e1Rbridh}%#k?TA?ub>4rq`}*t-dxe+!MaP=HnUYNtyOxRi
zO|aYUB)u-W@#bE7nfFzxOm$1|>s#8M-~~tw-ORVR^yIc%eet}r{g;`sPS<VT$Ozhv
zoHuQE!MY`LB0?Tpdp&0KxlKJ+U?T`mxq3%NoY3Kv!Z(Q`caKDo%0mPauWf8<KYC9I
zpoke1&6u@d-wstwd^klC-dJmR05uMvuR09d%a_~O7dUL^G-D&Ad3@(A1|_0FSjQIB
zelw2FIImvqB=~NRX0ANzcid5V7ApDWnQ`Fyi3_M_QPa!cZ}r;t2rF%pqw*(pvQOlY
zUcs^AbWD4EnoH1YxF#uqXF@FWH?9NnfDc?|<1!H7baY;hB6F!QiP>(kTS}ltPqA<c
zr?-}8E@OSH!Tz!O&U*%E#x^R!F1GSPwPtf}wJ8$n>K|FQWL(z%U`J`QDN>S)tUG1`
zSc47N5NE7sx6J=c7V%#)5O&VaFJcXTL0kuX`u$C{{Gy?{mi#NLN@fovZOMf|9ynO#
zg8eZsJ<ea9=K{J@Xh`Iq%M8ytoGJg+J$1Ee;Z<n8#BH{(y>7d1SzR_O?rHrSpq?`-
zU94>GxJp&K__NmXG~y7qRkR{-cX4`Z;{Xo4Uy_NT3C#g&N_u8+K43~r=wi>^dX+ov
z|D@cz(%etPf%kvThqrt1fGNqPhb@_Z`#_@NtROlG8{SRCF_q6&QOR$2w6?U5+e-2U
zo^pbn`X?d4nFKq!<5PqIEsm2-U|)DU-_i#DNCmQHfW3y_KB%-S&a#uI09GwVm(0fp
z=#Q5~<8L8&%@)9^`<K4YI3KX?=KW`jfeq*uw{#Q#*%A(K&i=V#E`L7ojK~-AK#sXj
zpe7~1^)a9kYr@@-TUYsZK>luVyQC%moV0ZgBuJ@;2Xyx=6L8|YzVr7F%W1%UHVA=L
zkwO4vG70*hH~VQwBbyU;&Wp7at%a>zqa~VZ%6a-S#p+qIO6||te=cZI;Vo`SLx99O
zA8sl#-L-s@V-lSjL(AXsmPT7sPOHpyfU21HpK==~VTv#!>#5bL7dOqgh`&xtYLBp<
zO_1_T9=Lh_TvMRVaATf^hDM_xB9M$D^52O*{!8QK|CHGmcZB7?i0H|&jbI7bD~L&I
z#bHyeaFf0=pWj7g9;XU*&>f82$ggXXCicN(e(tK|Upd70ZP_PR^Uz{jVyy`b-Ma3}
zuUqP6+}iGIf@&#ZNQb-V7j4`65o|k;(%RpBzHVSizSEtDRtsXUM3b;#Z;^piLg2=a
zu(mYClb5?%FSq8ynFdWKPneciR{5IdHTjN?P@g^vd3O%;Li`nHmrmxf?U$MJIK4+x
zCsw{H0xdP`uHj}?d7P#84@MPiz>%4Darm0rUUy^rQ@NvT`2ypFj&#eXV>~m$^1s<(
zTf~Decqt3<{QrXeyn78x)G(asvg#Ns?YKx89FI#8{+s!R0HS2cJQzs9YA!KD)tr_`
z{-V;i6i4jPrkdtVt$W6w)xD+gDWL9K^$Yu15wkKkw8B6EG}MrrSH{SDu7>p{3xjP}
zUTr1wnO_rx84v&NuuNqIH|dcFu@&CMe<c5I;Zz((aw%X?=kd#NVQq#YWoSqcwft@Q
zS1DK^6uTV`hA>s4U6;GrvE;VpXfsDY%2qdIO6C9lhIWw1+*jq^7e<^p<xKHULMhH|
z3wBRWc_&{>5s(Xd*I56_+PY{<n;;>Kziu^_l~Kb}1ND!I3$F%j+mhP)6{woHJR%j7
zN{Go}dU58e1#qG=OCx!;q!)jFtB=2J>-!Y2fl;WDl=O3-2TVP=HnX6A-+viboc0oN
zm!qv7y5L;iRdB@XxPK!I`nQ#ts94N)aJcg`bNz@6GuyHwz9)5MvFiT1Qpo?kI#sW7
zctplM9F9w_W!6Z<-*EYH5#GDCo9gWit-oC>^*okgd}+sCM_jdA^!8`qK|;y_M)8mM
zz3mr^^z5UIY;gYAyq`5nQZ13w&J9~`YH4S@D24BeyfBv@@oOO8_j6O9`nQHQBE-LV
zKzgLIZX4M%eHiIO&|w0`(^eOQ=OadpTL;51(VI`SA+yaZUbnm8h05&miFKaALRX2l
z(<IleKKfm+(G+yo8U>FCFM@Z!ly+{9NsmR04QLr~szo552T`0a&0oue6mc~LN0lpW
zWYUC)bA!@67YoX}^cx*7)j`hFWKW-@T6vnSOlf4D<okf6zDE?^?`@wp`myWG;Q_}0
zt{>Q|6T7WViU9u31X#hdYW-7h!caIt7-MUP_S>%+;5rIbb3r@muP8|ygx;W5ybIcv
z>dO#FXr&dM*FBwHYK_ULtMS}>2+2@{7LRW=a0opeM$H(RVTF@i#0=|nKtXk%ABJ8c
z_ydKDb>CNslvWE$zpp^{u^CPsWt&9@p&|^4z3|7TyVw(6?;?GN;A)FspdVi6Uc<)E
zg{oq|)Ku|S@5AR#(uPs(?Skvs;1I)%E)8DF6=sezl^0sMVfjgL^sS<or)kB(mxkUv
z2Xa6po!tXB;~cuBGD?Ndk)HSqS<q0=cCVrrTF25T<oNu0`2wwXu4_QeUgYv%`DI~~
z$i;*eUVsCFQ9*1IGMlI`WXo!02|PPNIUh2Uq$R%Y-g%4lJou+iF45G<nZDP$WW)R3
zo)=|(#)C`a%0=TqXr1CnW$ue;CIw|JG+oRzS!LnEBOusY-$f2(ini+|dT7~D$PZ>I
z&rOY{?ajQ*(7oSXawd|PLjSV9^;5k)z}B#8_SEJD>BH$k?OBdgJBG160S}9g>4FSF
z2&)L5kzpIh<xxEg?ODBf{s&=Oy(*7E>cP%n$uO4k%vo8=Aw$8@k0xd!k#;(oRyCBi
z_d{-Tm)URF+^j?q!5x{lF9K~qW3GP|gVsf~wT11$SW6B6S~K3x<4^5u``%w}ZlaSm
zN*-`~WLA!h##oTD6tUZ$4^}6R4(@8UzfTIbV_#TiwTG#$8)me+87kEmkaE0GngqM#
zdP~12K%(-zBb4v21X6qW+uV=QwTKJ<UzJ^VR8viq4<MjOFVYcFia_W^x>OOQNR^Is
z2t_&}BoskGnuvmcB=p{tUP2HAq*v(>={<A;p>4iz&z`gU$L=}%{&{of+<V`fncv*G
zGv~c~y{19JyFh|=jUgx`XVs@O9+K(#a`Nl>{d%@f9(j0+(zO>!!3skzke2y0DM&+h
zTdGEciT;Lh_m$N9e`A>+-zX>H$F6vQ(FRPCe;40*Ia8@P?`;>7g{QoQ7p*47qaZGO
z2oB2Qn3Ki;N^g%t(Z2R=!(`eJYDLM-X&{2|RW)|%Y#mf1zFj<meEU(P5qn$<Xq*1B
zVkxI(o@{y5eZ6z=Wn}B~RE(2$lw<~#Kda5N8swkDKHY|e%-k^N0q8=Uman6e*NLcj
z6%F9y&>u|E9p|=l4e!BD7X&1DsS5OrCw`jil%)j^%=O{ot@<-F!{jF7pUzvu(>-@B
zsj~3acIINieli&G?epKaS;a)wx^Tliyr*oPdqfZ%j|g(v{kGc!;Z>vn^z^(3sGYE|
z&;P#QbH~rl)lO!%EC>iw)&Lq<Xqepe9ec*xGY|rd2Qx^(c-{B+twQft1w(Nnvz%Ct
zzB1;A*I=wgN~VVN-$t|Qt(){?HN3mVdyQEan`kArJxwWT1F}N4r4|$<L@qb=fTn|D
zm6@h-6xi?AcR365PFbDnH#h+!%5J>ef3~e>N0icV;Y~Q*M}Q|zjck+SmV1LQ+wQCx
zK1Q_EtTNS?ZQ-^~)8CMM^P*q>XQu9)h=0^+R%fXmdbMH`%llxi+kC*EV!`^}ga|N+
zcf1-a`zO$kuA54sCO}u?4*yZYd1QA1TkkCqScqZkd}tN-{V+=7=TAtCY%WmVm17Iu
zhvGKc_SVGl=sT?PA(Lp*GTQb(b;>iH(d55~(g4zm&bsdTWQz7Ijd$b$jyN3nVlxkG
zpL*Y>nK3Ox`{Va~G7G5`dDD}Lvq@BKdBHno{Ze+6Z;2IOF*ngcU2RE2lZneW*=Aq*
z{d7G=v#NSrqyY8W#<Gge6Cxqc&s}QU4;d}TJd;Rv#7{i3MaBQR?XC4{3`A5fHcK=u
zj3_ou5g4aI3_sQL`jrY2gtcWOmxm*pTI2dDjE$K=YawC>y9hUh>6J>uN!>2VEo0j;
zQ~Uq2AX3@A5YTQ51>^@6R2B-R)LJkX0X=XG#`}x(kxN5eM)!Et*~Nz};2}c3KMeu*
zxYy%C*#So3-z}f>g!Q((K<q~@?HH!i;%g`{BQt9jeKw{Sksa>u&YAua)nYWrs}AOY
z(;4<=4G>Jb=j*k49-XF<2Qp|r9S#qClX#|_jl%zGxtl*RsRXbzBi*pD5`ttvn`K)0
zX^fC!s=-AJF46ONo^BG>6sUc;@M(!3aG?5Z(qG<EsZWWu+ClZWO9pSXGn8=SB#6j^
zhRsSt$bVw8405J}jfbr*8E$cADCpn=K*sn2NR4>Tk1+~7A#;U*D(-5x37xN3794nY
zS83J;0v=HvTc5k}*}FVPoR%o!id9Y)<{&O7%`5Qx=x3{^NF|s-X$wIUMb(@#*-3hR
za7O*J{1%kc=*~(vd;lDJ5YJ@0++1yKl94^T<h$F-1mIineXHWr`Z8U9reK~c9_^e%
z8*Bqwq@(xJyZ#PK?O|<1+BH)YO<(Yyu%d)|4{z-I@JGCBz*rC|I&4ITZGvK$y;pD=
z{w=OR(VvR*c2H0Vq2G4^en?4+)W&uhzI3;$9h{P={rS&DLH7O4Xv1{M4U5vvEMsUy
z?=B?Ol$1HtgUa%Flynb$vjbXoGUd4VA?674_b@hEh8zR%v(j00+_3NHdum7WPz5v~
z_#{*LU>RO5_yQWlM0kTjUc|dD_a6bSJ0Hp!#uXC~m<U$4He^4tj25PMh<fOwtv&Y6
zB|~$5B@g81_Rxy9xJS#?#{Dn{$=KIAb?j%hISL;)`E%Oo8IZqY;u`D`?5a;49jm<(
zHhR_`yxOt;I}E_cv^B--D||`HN<I}P3Wq5zb?yhr4|%~4&ZNbM#O>w6?oK{ikRJzs
z2i*en&e+JE?v#K+md|2G9O2D7up|BTn85|F@NI*WUyI_6uYT5=nwm^<WIj3Qx<H+|
z7|c>%kOi&ZM-RNz?DP8UpBMnG|2?B5&i>4XXdED9iERbv9d%qxTRk;jK6O(H7R(R8
zCcIeqvj5@&G!o;RI?tP6*&sGXSsNS=avpB`QBM>Gq8(0$&m#}Z6Q}t}XA+SFS$(mn
zkQ2p;>tepxd7%@W#pHtgXyb>E6F(Tsu2dVAwy1vHOki?yaRaKEjFr!x0bJw~x-=%6
z0}(r)_JR9&e%)`el)z5$Zl6O1vo}E}igN3El1St0B<#`l!-t-LqPnlLGeh?i;=$mO
zTYIoK*OPmJnh8Tzqqk~EJhU&)r2~{Cl`w$^M1rP#F~Fl-${z1A$<3&yTlX%q4T0T(
z4ngWZoh;Smo>9bb`Ot!+Z+EQU*9UiJ*C%55#{A#{-I2|cwmmQJ3Zh=7q(W=9Thu46
z(>7hi=H$=Ax9brq>E34MgWsxcLYDQNlFB+xx2CLMNByJ~RQ9zf|B9>jO&gVT0&21-
z34!=4MeybHSTeW4(E3xCpuq0R!TJ_oJ2jRxK$!k*79A2$suL@_tUGEL!rUf)n&4hB
zC+%>(2V&Qm3<bTH@Lqg)Lpn4lZ*1@*MXxjI2-S4CjkaI8&TDcQt&&SlvDx1<KaHpj
zy<L5?@EZr=Ts(^k1>ejME$%9(x$gDY3uB_y&rc5ud{+@ol_84EUIcxM2}kcIZ=O_A
zAN0tSijv1g0<z4L*TR#<!=&k<d5;9sKNIjIoN<2og_KD947g2z(LYXti@5#>TH5%~
zH&oa3f-s>@FUR{`cn@`nq{zw-;uJKWfad^t?m*|gpXN&V0G~Q@h$JVifUgqipJGsK
zvb0crtAZhNv*lC5H%gJrZF%7Y4XhvHzx3{R4KlZ}6D|!jZ0rh@S>b{_t!3xWc>#N^
zH-#yMV#uGK=T`RK>M{C(-O|$~N(?dOS;_@KL_nu0lF@d+#`5<X#GV07)T2jsNVGuR
z8&-G^+BGpsSZYYEH~6|h_|1cEpUT5^LFrbgR7+O|>WMdcmm}?GPd%0;eMeg9vgRnA
zF|2s8t$XiEehBeVa<a931}NoAM~A5{6sFP~HlMk<R2~f~lb2Et_lg>@Jy@ofj*0kv
zjE~wiHF)jb_)H&(U2mUy@9Vrg>%0uwnSmByXRDu{c{*3#K~}u_zWTez5FFzSwXi?0
zwcwNx_dV5LcQ}4t#U}^jS$%K`cK@J)CNtUy(zTgl>szq;wzz6YJbQLJea7M(7TB83
z)G$YUV-@L~C0P_Wm6$mPt<gwM4VtKzOtEQ>5`VAq-uj%oU7W9aYKTn%{mJKCK2hi8
zhQ({~pv9=_k(f%<f+b4FlzRQR|5#1yFR6yg2tq&VdG!Q(c-~#irr8Azp5d_Mcj+Tf
z@2UK^QF?i|NZP7;S_zJR1T=q{y{+Vv0sP5$Z$VE_O)bv>uSHEwtLw%8hX~Q&pcyIP
zQssDS`^xAEB|wFk^AQ6t867w5_Ls*;4o1#^+d^d$=3m`m@3@zGax`vo{PQed7oatj
ze-qpee%c@S$Tf;nkLdMN;%o`Y-<&ItISG|XU5?m!lRiD?c;B&Di^91Xq{*LTZOf&S
z+d5|!)YM6)TfS8+tPW+OE*sDou_flzzJ{~v&W2y5mwl>SVcrNJj@W`$=H)Gf!>?mR
zncFXYU3R}Sk9H@2sSubi-qw`)^#bLsF<-HVA>W;=M)ukb1PaF9y1Kqr918Ll;fgNV
zpBS~(8RKvP0e***!msy2#$*9qORm)(srqg`femWC^v6_BG<59uc^Gvmr~<%#{vHE_
z!+(5dE0Csc?ttNSKSpT`V_568@GfZ?;N7>Y^rnKHQTaEeeZ?NZ(>XS04&WR2DLbz}
zTZ|lY!VG#QU5E4IO8h&8Hi6>WNRbr|cu7d`@7<ojNY^J298TTB(c<DXb+&i*lxoYp
z{^FViTD%_6W)G`y3e5nAX3SRAS5Btw*~ZX=Y{zXuQbK%ee&<`PZlKyKmzQXLxs4C(
zq;UfpWg5FexdHA{gq-yIbF7o*K;ym%>PUGqu;2BMmYw@|-?5(1Y5YXlPQ2lB7$zej
zh(WC`KYwsRAY+~SO*T{B0`TMh$HV!3vTk3T|5}6J_syx-pLbsA3y~60p{VLP+&5Zf
zACVG86eXhmzSmD1olYshYDdUZ08~WvSrEM643x{d1%lJqAE%;ouU>x_lBS8^h$YvF
zq?$Rgt5KnFW1&!d9Kc>#QQoK$9c5r#iNYx*h182C*_pAH+`Dm_ox)a6_*nVPWKB}&
z_VZYea?<N%;sd9JbvEh!;&XVAzpnT|0<*n+@WREhtt{2;bSA5Kt7+?l+VDx#-6O_z
z`}U+N^Kxr>dfT)hT2HH8&zft8H@4;pn$2a#A4P-oRMci_OLN9YX)~X(V0<ZbpTGY3
zimhs=T3I5(=WQCSRwbdPld_Mp8=rkycBpMQ$r5uvV7p|1gr>=@I&{jT%p)$PvOy`b
z%L;x?dTj;_<M$4pg?przkT@fxMeaod%_%u)>+o2fnP+;6-^OUnN~QYBQ`7sEY~s4g
zbH0OL&vjZ9k~IIyl*=wARHLc-RXJtMogl5!nl*{cKimwFR!FkTzjB=r$%?m0VpM<N
z9alMFtatwHWA=ox_Voj=hIXMKTm_}7B-$6T^D`5cIAK0(nM-IXgf8nan;f+c999fi
zP4p+-b={(P*1n*)j<i)v3H%dl9t&joYjE(0^-hP3qr|SXB3p7W1jV<|I?0xaxv&du
z!44f%jgC8&-XbA=mp}WK;^OP3Z&VuW%i#46*0nGH;|gU56t@Nm)$BR;OboO@vbRaa
zb}CGL`F$*ap+a66mNZFKE8n&KEsoi~D%kx(l03k|%0$O@e`m`i4c<Z9EE@Lyb)*8W
zygdGkTLaRtp3SCKxc3-h?lC`)<)70{7P2&Zn37(n3NjPvUF$MVee_}$UfLHpOLrA?
z=ea4W-YlcpQ;xtLR41E>-kGaLZ#J0B(eF0i$j<m8`d2StXo6hpTVbQJ9pxaTf3#Jy
zbl&bv<(ynm$rLVvi9C09v+iehA|jzM-Z|XLzsrCkPGgtBc5m>^Z&dPUX7dZ<5nGlx
zE7Kdf?Fv{gllT=s`&9?TwGSyRj0|mDoE|jniSl_9vU2gpH~*H*E5pa=Ov=8W-pX-S
z6c(`1sp$zz?pqHM32ELkBj$<2K5TeC)@x*gx@m(zR>Ub&@%F~A1{k;iM&?>d&B;9O
z+Qs^fsMjt{Fc*o9<1>FOW}1apYoKlgyhT~pXqgKu%ymPDhe#`pBz`cbd>)~3_bDYw
zw!t%PR`Q&KFp99hyQqAr>5^Z~)kz4JT7crVj&H#gUqlci`*F^`OMXHFVkZ7Oh@8bp
zG96MeFJo&a1Si&#e0u5k04$rWRr>r^@@YGuoY4tq>^7PwjKX;02E5V(KIhTn-YJAt
z?8RmWg%7SDjE{GUT^(MicGmQb?Hy`&W=DT)ve&}2S|hSMtqT(eQT?8lG{QDqZU8=p
z;UdPYNfHncd)c)BFTF4nN4_M2LjR<iI)OKIYLY(m2^8{%1giqW+8Xo<5qmn7)Bv+4
z(Z97Ah>T)CPtA&Jotw7Z$B%5}Piq~cK0xbjUEXmL4nGhPkZ-h;H+%kV-+`XIoIw0a
zR?fGi*x_aNdSz=NV%CNM71K$58_Z@iF)r!!qYYD`44#a2QY|hbX%GJ{+)4t7eCLG)
z3wWHGUtPXdu50!dlL06*Ds)j3fEq)%X;H!tpOB9*L7&IkMq)wKs|h=LY1HI^7yc8Z
zMAGU001=4|F^kzxXwfYWa?|lY8<GH{&LahEY^s%K$^D}z6ti^?Xb&1WKC^D8Ca$uY
zx{e)}llcNUA-MN2yLncijUv1sOhN*r;3*ovCavJ5s6F=#=C&`eagH5p5sW7_GQQwn
z(<`K4V5y(s)LxFLv+E>Ih^l8Br-*SQidcqci|CX0D9B2zJeI6af2*<tQRW*8kk*wN
zhE{fQZtC1CQjg5{t}kqmJw3Isg1_?+g6aT`O2Q^{OBdjKQalD_6{SLer;dJHvP`WD
zMZ1)BRw&WiPu*Q+JvEztT2an>_e|7HSvMj@7ks@y)-7*J|BS9vtEaN^E0+|ZCqFY0
zn5Id6wE|9HI1&dX1xqFDprBY8lRck<{!+`==Ee%1F2{3k9ti4e3)bCJ%zyYEZ!iYe
zGb+l_jakD6rt3#K<Kre}4NC4FZp|ZsdU51YvGtx_6_q9zm7%-Wih_#8hk?y&d!e;;
z=Hd(SV>^Fl6zVGET9-(vqBQkQVix&J2ktcsOxl7rn|2>xd%glhtgaQTrH9n>CE2NW
zw+S<y@B;#31IFFyXzl%$9F*-9hCeasrEWA<YD%|PsJyMaxBS`tRu<#h#i2RX>==nX
z{mT(2%HK}@TZE}Gq?;*e0Zk`gpd<v#U0otsbY~j_bNuNU8GYKF$;rv*)>sNLZdCz6
zwhvrHpW+M%U|`tzw!zr47_FQt_3gavNCCzyf{3=y<awB`o>=osFO_2?%~Ohv$j=<m
zJ6}_>@&6;~;5co#a$5KV1p2g*_`Gp5NP%3rYz$>nkS@YEe{-~iT3AoFNn3~azGSTS
zJQZE2vE}hr#Cd8kWCp9@O0Zi3>xhVsK1|3hjgF4~9G3=<j@In?x*79-6WB3l=OEe3
zJ*?^tmWW4X8abkH67=VbxfY{mfk5bxssxuobWRReyhg6U0SIXNb+dXOWw?k4WhLu1
zLwQ5T<ng(xbGM>3@2st@IhetYH%3x`7GHOKBhwV`-W+hYFptWI@xp_+(DBM@HI#TJ
zt|U!9`rykmQE_NOm07ije8!1|PtsaUG<|MSktX#mYvj=5I`?~B_Z_jIr!S7w)Y9~e
zjrxxpJ5mN13cy@B<oFC!_-j>;tkbSw=nlS$Yv$2cqX{%V_Z!D0ZBjcu1H-_8<D{w<
z^ODS!?DDic4UGqX|M7N=E51jhSe<bG9TIp?HiMe3A2;<^Vh9$@Wx#YgwoW;;IY}^t
ze-W24y8;`5e--!R+gqjn>Q(!{5^Unod)Fq2QOk3!BT#W_v<n>`0QS64%zlm7-5bkN
zncX1z5c&5Zh2VtW54pIL9MjSi1MwPc`Dw0C_Ka@U_T@OV5}j2_Ei`pv_B;CdiJ0Ke
zFI_MbA<`r?BeEYIWpJgn=ag#rQL8?Z4nA1AyB6|{;Q6ORc0w8&29nb;IvSeC%;E|(
zG)bRC|2yHW#z8~#a<NfvqxX%jQ!p1-PWur~=}MKS8hY8Y7j*K!LgC>d9xG&1bTfyY
zQA(P0_%8ZKEko5x9=tB{9|RRuaTlI;#vuMJ|5c~ET#}&r=K)-fni*?9|J@O||GPaP
zE@)~JJCaHJ2XAEk;i>SOvt)Gnli6;>C8kY#h;d+GV3oTUpAooaTw6`8#=5t+_t3!W
zO#p3M?agInQquSQwc?5j`TbG+@ydMydXr2w71#*?0ATV{f8}TI<>BGz=?C!hcq8n?
z3FK6D@$vF-_4lw)@h8OdaR0;O@Y>H&*51bve*@q@<QD^qNCU;BjYK45MPy_pq=5ev
kL~79x+y5cp;pO1!1peOzenoW5;ROKC)pgY>RBR*u1FBO?7ytkO

literal 0
HcmV?d00001

diff --git a/doc/design/assistant/blog/day_46__notification_pools.mdwn b/doc/design/assistant/blog/day_46__notification_pools.mdwn
new file mode 100644
index 0000000000..483ad95b1c
--- /dev/null
+++ b/doc/design/assistant/blog/day_46__notification_pools.mdwn
@@ -0,0 +1,68 @@
+Focus today was writing a notification broadcaster library. This is a way to
+send a notification to a set of clients, any of which can be blocked
+waiting for a new notification to arrive. A complication is that any number
+of clients may be be dead, and we don't want stale notifications for those
+clients to pile up and leak memory.
+
+It took me 3 tries to find the solution, which turns out to be head-smackingly
+simple: An array of SampleVars, one per client.
+
+Using SampleVars means that clients only see the most recent notification,
+but when the notification is just "the assistant's state changed somehow;
+display a refreshed rendering of it", that's sufficient.
+
+----
+
+First use of that was to make the thread that woke up every 10 minutes
+and checkpointed the daemon status to disk also wait for a notification
+that it changed. So that'll be more current, and use less IO.
+
+----
+
+Second use, of course, was to make the WebApp block long polling clients
+until there is really a change since the last time the client polled.
+
+To do that, I made one change to my Yesod routes:
+
+[[!format diff """
+	-/status StatusR GET
+	+/status/#NotificationId StatusR GET
+"""]]
+
+Now I find another reason to love Yesod, because after doing that,
+I hit "make".. and fixed the type error. And hit make.. and fixed
+the type error. And then it just freaking worked! Html was generated with
+all urls to /status including a `NotificationId`, and the handler for
+that route got it and was able to use it:
+
+[[!format haskell """
+	{- Block until there is an updated status to display. -}
+	b <- liftIO $ getNotificationBroadcaster webapp
+	liftIO $ waitNotification $ notificationHandleFromId b nid
+"""]]
+
+And now the WebApp is able to display transfers in realtime!
+When I have both the WebApp and `git annex get` running on the same screen,
+the WebApp displays files that git-annex is transferring about as fast
+as the terminal updates.
+
+The [[progressbars]] still need to be sorted out, but otherwise
+the WebApp is a nice live view of file transfers.
+
+---
+
+I also had some fun with Software Transactional Memory. Now when the
+assistant moves a transfer from its queue of transfers to do, to its map of
+transfers that are currently running, it does so in an atomic transaction.
+This will avoid the transfer seeming to go missing (or be listed twice) if
+the webapp refreshes at just the wrong point in time. I'm really starting
+to get into STM.
+
+----
+
+Next up, I will be making the WebApp maintain a list of notices, displayed
+on its sidebar, scrolling new notices into view, and removing ones the user
+closes, and ones that expire. This will be used for displaying errors, as
+well as other communication with the user (such as displaying a notice
+while a git sync is in progress with a remote, etc). Seems worth doing now,
+so the basic UI of the WebApp is complete with no placeholders.
diff --git a/doc/design/assistant/blog/day_47__alert_messages.mdwn b/doc/design/assistant/blog/day_47__alert_messages.mdwn
new file mode 100644
index 0000000000..81551fa95b
--- /dev/null
+++ b/doc/design/assistant/blog/day_47__alert_messages.mdwn
@@ -0,0 +1,14 @@
+Some days I spend 2 hours chasing red herrings (like "perhaps my JSON ajax
+calls arn't running asynchronoously?") that turn out to be a simple
+one-word typo. This was one of them.
+
+However, I did get the sidebar displaying alert messages, which can be
+easily sent to the user from any part of the assistant. This includes
+transient alerts of things it's doing, which disappear once the action
+finishes, and long-term alerts that are displayed until the user closes
+them. It even supports rendering arbitrary Yesod widgets as alerts, so
+they can also be used for asking questions, etc.
+
+Time for a screencast!
+
+<video controls src="http://joeyh.name/screencasts/git-annex-webapp.ogg"></video>
diff --git a/doc/design/assistant/blog/day_48__intro.mdwn b/doc/design/assistant/blog/day_48__intro.mdwn
new file mode 100644
index 0000000000..2cac85d4d1
--- /dev/null
+++ b/doc/design/assistant/blog/day_48__intro.mdwn
@@ -0,0 +1,8 @@
+Lots of WebApp UI improvements, mostly around the behavior when
+displaying alert messages. Trying to make the alerts informative
+without being intrusively annoying, think I've mostly succeeded now.
+
+Also, added an intro display. Shown is the display with only one repo;
+if there are more repos it also lists them all.
+
+[[!img screenshot/intro.png]]
diff --git a/doc/design/assistant/blog/day_49__first_run_experience.mdwn b/doc/design/assistant/blog/day_49__first_run_experience.mdwn
new file mode 100644
index 0000000000..437046d34d
--- /dev/null
+++ b/doc/design/assistant/blog/day_49__first_run_experience.mdwn
@@ -0,0 +1,39 @@
+Started work on the interface displayed when the webapp is started 
+with no existing git-annex repository. All this needs to do is walk the user
+through setting up a repository, as simply as possible.
+
+A tricky part of this is that most of git-annex runs in the Annex monad,
+which requires a git-annex repository. Luckily, much of the webapp
+does not run in Annex, and it was pretty easy to work around the parts that
+do. Dodged a bullet there.
+
+There will, however, be a tricky transition from this first run webapp,
+to a normally fully running git-annex assistant and webapp. I think the
+first webapp will have to start up all the normal threads once it makes the
+repository, and then redirect the user's web browser to the full webapp.
+
+Anyway, the UI I've made is very simple: A single prompt, for the
+directory where the repository should go. With, eventually, tab completion,
+sanity checking (putting the repository in "/" is not good, and making it
+all of "$HOME" is probably unwise).
+
+[[!img screenshot/firstrun.png]]
+
+Ideally most users will accept the default, which will be something
+like `/home/username/Desktop/Annex`, and be through this step in seconds.
+
+Suggestions for a good default directory name appreciated.. Putting it on a
+folder that will appear on the desktop seems like a good idea, when there's
+a Desktop directory. I'm unsure if I should name it something specific like
+"GitAnnex", or something generic like "Synced".
+
+Time for the first of probably many polls!
+
+What should the default directory name used by the git-annex assistant be?
+
+[[!poll open=no 19 "Annex" 7 "GitAnnex" 1 "~/git-annex/" 10 "Synced" 0 "AutoSynced" 1 "Shared" 10 "something lowercase!" 1 "CowboyNeal" 1 "Annexbox"]]
+
+(Note: This is a wiki. You can edit this page to add your own
+[[ikiwiki/directive/poll]] options!)
+
+[[!tag polls]]
diff --git a/doc/design/assistant/blog/day_49__first_run_experience/comment_1_e146cf06c8dd6303dd6a991f152a73fe._comment b/doc/design/assistant/blog/day_49__first_run_experience/comment_1_e146cf06c8dd6303dd6a991f152a73fe._comment
new file mode 100644
index 0000000000..9f1d74e677
--- /dev/null
+++ b/doc/design/assistant/blog/day_49__first_run_experience/comment_1_e146cf06c8dd6303dd6a991f152a73fe._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://nico.kaiser.me/"
+ nickname="Nico Kaiser"
+ subject="Directory location"
+ date="2012-08-01T07:51:36Z"
+ content="""
+I don't think the Annex directory (or whatever it will be called – \"Annex\" seems like a good choice in my opinion) should be inside the \"Desktop\" folder by default. All other xdg-user-dirs (Documents, Downloads, etc.) are in $HOME, and i think Desktop should not be cluttered with folders.
+"""]]
diff --git a/doc/design/assistant/blog/day_49__first_run_experience/comment_2_5d6adcf6782c02283bef6189582ee467._comment b/doc/design/assistant/blog/day_49__first_run_experience/comment_2_5d6adcf6782c02283bef6189582ee467._comment
new file mode 100644
index 0000000000..40f75ca0bd
--- /dev/null
+++ b/doc/design/assistant/blog/day_49__first_run_experience/comment_2_5d6adcf6782c02283bef6189582ee467._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.236"
+ subject="comment 2"
+ date="2012-08-01T14:04:08Z"
+ content="""
+Hmm, my thought on putting it under Desktop is that'll let me install git-annex and tell my mom (really!) that files dragged to there are shared. Don't the other xdg directories get used as default save/open locations for things like word processors, so not need to be on the desktop?
+
+Although that may not be necessary. I've realized I can, at least on linux, easily make a button on the webapp that pops open the directory in the desktop's file manager.
+
+I guess another way of looking at the question is: Where does dropbox put its folder?
+"""]]
diff --git a/doc/design/assistant/blog/day_49__first_run_experience/comment_3_7ac2e34c2a7bc9b57488ca0c91307d32._comment b/doc/design/assistant/blog/day_49__first_run_experience/comment_3_7ac2e34c2a7bc9b57488ca0c91307d32._comment
new file mode 100644
index 0000000000..22eff96b65
--- /dev/null
+++ b/doc/design/assistant/blog/day_49__first_run_experience/comment_3_7ac2e34c2a7bc9b57488ca0c91307d32._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawllHWUwOT-UVe5bGkk8G87bpeRAzy-5T7w"
+ nickname="Rick"
+ subject="Folder location"
+ date="2012-08-01T14:18:21Z"
+ content="""
+I'm of two minds about where the Annex folder should be.
+
+For beginners, the desktop is ideal. No doubt about it. And more experienced users can override the default path during the install.
+
+On the other hand, many of the other 'synced folder' services place their folder in the user's home. Both Dropbox and Skydrive do this. It's where I'd put it for consistency, and to keep my desktop free of clutter.
+
+It's a close call, but if push came to shove, I'd probably go with the user home folder.
+"""]]
diff --git a/doc/design/assistant/blog/day_49__first_run_experience/comment_4_549b07bb02c07a5b1b95445b01758db2._comment b/doc/design/assistant/blog/day_49__first_run_experience/comment_4_549b07bb02c07a5b1b95445b01758db2._comment
new file mode 100644
index 0000000000..f261d1c238
--- /dev/null
+++ b/doc/design/assistant/blog/day_49__first_run_experience/comment_4_549b07bb02c07a5b1b95445b01758db2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="dhess"
+ ip="173.247.200.7"
+ subject="Choose a friendly/unintimidating name"
+ date="2012-09-13T00:32:15Z"
+ content="""
+You've already decided to accommodate mom by choosing ~/Desktop as the default location, so you should be consistent: choose a name that means something to people. \"Annex\" and \"GitAnnex\" are good branding, but not very user-friendly. (Contrast with \"Dropbox\", the default folder name for Dropbox -- good branding *and* reasonably meaningful.)
+
+\"Shared\" is friendly, but implies that you're sharing with other people, which isn't necessarily the case. (You should reserve the name \"Shared\" for a sub-directory of the default directory, anyway, if/when the time comes to implement sharing URLs to your g-a-a objects with other users.)
+
+I think that \"Synced\" is fine. Most English-speakers will know what it means, and it's a good description of what g-a-a does.
+
+Don't worry whether we like it or not. Nobody who comments here, nor, likely, anyone who votes, will use the default name anyway ;)
+"""]]
diff --git a/doc/design/assistant/blog/day_4__speed.mdwn b/doc/design/assistant/blog/day_4__speed.mdwn
new file mode 100644
index 0000000000..085d9547b1
--- /dev/null
+++ b/doc/design/assistant/blog/day_4__speed.mdwn
@@ -0,0 +1,47 @@
+Only had a few hours to work today, but my current focus is speed, and I
+have indeed sped up parts of `git annex watch`.
+
+One thing folks don't realize about git is that despite a rep for being
+fast, it can be rather slow in one area: Writing the index. You don't
+notice it until you have a lot of files, and the index gets big. So I've
+put a lot of effort into git-annex in the past to avoid writing the index
+repeatedly, and queue up big index changes that can happen all at once. The
+new `git annex watch` was not able to use that queue. Today I reworked the
+queue machinery to support the types of direct index writes it needs, and
+now repeated index writes are eliminated.
+
+... Eliminated too far, it turns out, since it doesn't yet *ever* flush
+that queue until shutdown! So the next step here will be to have a worker
+thread that wakes up periodically, flushes the queue, and autocommits.
+(This will, in fact, be the start of the [[syncing]] phase of my roadmap!)
+There's lots of room here for smart behavior. Like, if a lot of changes are
+being made close together, wait for them to die down before committing. Or,
+if it's been idle and a single file appears, commit it immediately, since
+this is probably something the user wants synced out right away. I'll start
+with something stupid and then add the smarts.
+
+(BTW, in all my years of programming, I have avoided threads like the nasty
+bug-prone plague they are. Here I already have three threads, and am going to
+add probably 4 or 5 more before I'm done with the git annex assistant. So
+far, it's working well -- I give credit to Haskell for making it easy to
+manage state in ways that make it possible to reason about how the threads
+will interact.)
+
+What about the races I've been stressing over? Well, I have an ulterior
+motive in speeding up `git annex watch`, and that's to also be able to
+**slow it down**. Running in slow-mo makes it easy to try things that might
+cause a race and watch how it reacts. I'll be using this technique when
+I circle back around to dealing with the races.
+
+Another tricky speed problem came up today that I also need to fix. On
+startup, `git annex watch` scans the whole tree to find files that have
+been added or moved etc while it was not running, and take care of them.
+Currently, this scan involves re-staging every symlink in the tree. That's
+slow! I need to find a way to avoid re-staging symlinks; I may use `git
+cat-file` to check if the currently staged symlink is correct, or I may
+come up with some better and faster solution. Sleeping on this problem.
+
+----
+
+Oh yeah, I also found one more race bug today. It only happens at startup
+and could only make it miss staging file deletions.
diff --git a/doc/design/assistant/blog/day_4__speed/comment_1_bf3c9c33cc0dea5eaeb6f2af110b924b._comment b/doc/design/assistant/blog/day_4__speed/comment_1_bf3c9c33cc0dea5eaeb6f2af110b924b._comment
new file mode 100644
index 0000000000..fb5b95490f
--- /dev/null
+++ b/doc/design/assistant/blog/day_4__speed/comment_1_bf3c9c33cc0dea5eaeb6f2af110b924b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawldKnauegZulM7X6JoHJs7Gd5PnDjcgx-E"
+ nickname="Matt"
+ subject="open source?"
+ date="2012-06-09T22:34:30Z"
+ content="""
+Are you publishing the source code for git-annex assistant somewhere?
+"""]]
diff --git a/doc/design/assistant/blog/day_4__speed/comment_2_33aba4c9abaa3e6a05a2c87ab7df9d0e._comment b/doc/design/assistant/blog/day_4__speed/comment_2_33aba4c9abaa3e6a05a2c87ab7df9d0e._comment
new file mode 100644
index 0000000000..1fcc197ab7
--- /dev/null
+++ b/doc/design/assistant/blog/day_4__speed/comment_2_33aba4c9abaa3e6a05a2c87ab7df9d0e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.126"
+ subject="comment 2"
+ date="2012-06-09T23:01:29Z"
+ content="""
+Yes, it's in [[git|download]] with the rest of git-annex. Currently in the `watch` branch.
+"""]]
diff --git a/doc/design/assistant/blog/day_50__directory_name.mdwn b/doc/design/assistant/blog/day_50__directory_name.mdwn
new file mode 100644
index 0000000000..a0e57cae68
--- /dev/null
+++ b/doc/design/assistant/blog/day_50__directory_name.mdwn
@@ -0,0 +1,20 @@
+Based on the results of yesterday's poll, the WebApp defaults to
+`~/Desktop/annex` when run in the home directory. If there's no `Desktop`
+directory, it uses just `~/annex`. And if run from some other place than
+the home directory, it assumes you want to use cwd. Of course, you can
+change this default, but I think it's a good one for most use cases.
+
+----
+
+My work today has all been on making **one second** of the total lifetime
+of the WebApp work. It's the very tricky second in between clicking on
+"Make repository" and being redirected to a WebApp running in your new
+repository. The trickiness involves threads, and MVars, and
+multiple web servers, and I don't want to go into details here.
+I'd rather forget. ;-)
+
+Anyway, it works; you can run "git annex webapp" and be walked right
+through to having a usable repository! Now I need to see about adding
+that to the desktop menus, and making "git annex webapp", when run a second
+time, remembering where your repository is. I'll use
+`~/.config/git-annex/repository` for storing that.
diff --git a/doc/design/assistant/blog/day_50__directory_name/comment_1_782cec95a8558a05b2b38a2d2302214d._comment b/doc/design/assistant/blog/day_50__directory_name/comment_1_782cec95a8558a05b2b38a2d2302214d._comment
new file mode 100644
index 0000000000..be55932f13
--- /dev/null
+++ b/doc/design/assistant/blog/day_50__directory_name/comment_1_782cec95a8558a05b2b38a2d2302214d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2012-08-01T21:19:03Z"
+ content="""
+Please use `$XDG_CONFIG_HOME` and fall back to `~/.config` if that's not defined.
+"""]]
diff --git a/doc/design/assistant/blog/day_50__directory_name/comment_2_2b8ceb0a26f25e8ed2711bcbe7225a58._comment b/doc/design/assistant/blog/day_50__directory_name/comment_2_2b8ceb0a26f25e8ed2711bcbe7225a58._comment
new file mode 100644
index 0000000000..a09b721be9
--- /dev/null
+++ b/doc/design/assistant/blog/day_50__directory_name/comment_2_2b8ceb0a26f25e8ed2711bcbe7225a58._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://piotr.ozarowski.pl/"
+ nickname="POX"
+ subject="XDG"
+ date="2012-08-02T10:30:55Z"
+ content="""
+same for XDG_DESKTOP_DIR (for pl_PL ~/.config/user-dirs.dirs file contains XDG_DESKTOP_DIR=\"$HOME/Pulpit\" instead of Desktop)
+"""]]
diff --git a/doc/design/assistant/blog/day_51__desktop.mdwn b/doc/design/assistant/blog/day_51__desktop.mdwn
new file mode 100644
index 0000000000..c079a9a912
--- /dev/null
+++ b/doc/design/assistant/blog/day_51__desktop.mdwn
@@ -0,0 +1,34 @@
+Now installing git-annex automatically generates a freedesktop.org .desktop
+file, and installs it, either system-wide (root) or locally (user). So
+`Menu -> Internet -> Git Annex` will start up the web app.
+
+(I don't entirely like putting it on the Internet menu, but the
+Accessories menu is not any better (and much more crowded here), 
+and there's really no menu where it entirely fits.)
+
+I generated that file by writing a generic library to deal with
+freedesktop.org desktop files and locations. Which seemed like overkill at
+the time, but then I found myself continuing to use that library. Funny how
+that happens.
+
+So, there's also another .desktop file that's used to autostart the
+`git-annex assistant` daemon when the user logs into the desktop.
+
+This even works when git-annex is installed to the ugly non-PATH location
+`.cabal/bin/git-annex` by Cabal! To make that work, it records the path
+the binary is at to a freedesktop.org data file, at install time.
+
+---
+
+That should all work in Gnome, KDE, XFCE, etc. Not Mac OSX I'm guessing...
+
+---
+
+Also today, I added a sidebar notification when the assistant notices new
+files. To make that work well, I implemented merging of related sidebar
+action notifications, so the effect is that there's one notification that
+collectes a list of recently added files, and transient notifications that
+show up if a really big file is taking a while to checksum.
+
+I'm pleased that the notification interface is at a point where I was able
+to  implement all that, entirely in pure functional code.
diff --git a/doc/design/assistant/blog/day_52__file_browser.mdwn b/doc/design/assistant/blog/day_52__file_browser.mdwn
new file mode 100644
index 0000000000..a9762cc096
--- /dev/null
+++ b/doc/design/assistant/blog/day_52__file_browser.mdwn
@@ -0,0 +1,21 @@
+Today I added a "Files" link in the navbar of the WebApp. It looks like a
+regular hyperlink, but clicking on it opens up your desktop's native file
+manager, to manage the files in the repository!
+
+Quite fun to be able to do this kind of thing from a web page. :)
+
+---
+
+Made `git annex init` (and the WebApp) automatically generate a description
+of the repo when none is provided.
+
+---
+
+Also worked on the configuration pages some. I don't want to get ahead
+of myself by diving into the full configuration stage yet, but I am at
+least going to add a configuration screen to clone the repo to a removable
+drive.
+
+After that, the list of transfers on the dashboard needs some love.
+I'll probably start by adding UI to cancel running transfers, and then
+try to get drag and drop reordering of transfers working.
diff --git a/doc/design/assistant/blog/day_52__file_browser/comment_1_cd000c2d56b60cc1f17b221322a32aa7._comment b/doc/design/assistant/blog/day_52__file_browser/comment_1_cd000c2d56b60cc1f17b221322a32aa7._comment
new file mode 100644
index 0000000000..206b0c70e4
--- /dev/null
+++ b/doc/design/assistant/blog/day_52__file_browser/comment_1_cd000c2d56b60cc1f17b221322a32aa7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://cweiske.de/"
+ nickname="cweiske"
+ subject="comment 1"
+ date="2012-08-15T22:02:14Z"
+ content="""
+I thought that most (if not all) browsers prevent opening local files/directories via web pages. How did you solve that problem?
+"""]]
diff --git a/doc/design/assistant/blog/day_52__file_browser/comment_2_21d1da67cf9105a545583ba2302c10fb._comment b/doc/design/assistant/blog/day_52__file_browser/comment_2_21d1da67cf9105a545583ba2302c10fb._comment
new file mode 100644
index 0000000000..9ba5104e2a
--- /dev/null
+++ b/doc/design/assistant/blog/day_52__file_browser/comment_2_21d1da67cf9105a545583ba2302c10fb._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 2"
+ date="2012-08-16T23:34:12Z"
+ content="""
+Yes, it's surprising to me when I see it work, and I wrote it. :) Since git-annex is running locally on the same system as the browser, it can open the file manager when the user clicks on a link in the web browser. To the web browser, this is just an AJAX request.
+"""]]
diff --git a/doc/design/assistant/blog/day_54__adding_removable_drives.mdwn b/doc/design/assistant/blog/day_54__adding_removable_drives.mdwn
new file mode 100644
index 0000000000..8d57518bb5
--- /dev/null
+++ b/doc/design/assistant/blog/day_54__adding_removable_drives.mdwn
@@ -0,0 +1,99 @@
+Spent yesterday and today making the WebApp handle adding removable drives.
+
+While it needs more testing, I think that it's now possible to use the WebApp
+for a complete sneakernet usage scenario.
+
+* Start up the webapp, let it make a local repo.
+* Add some files, by clicking to open the file manager, and dragging them in.
+* Plug in a drive, and tell the webapp to add it.
+* Wait while files sync..
+* Take the drive to another computer, and repeat the process there.
+
+No command-line needed, and files will automatically be synced between
+two or more computers using the drive.
+
+Sneakernet is only one usage scenario for the git-annex assistant, but I'm
+really happy to have one scenario 100% working!
+
+Indeed, since the assistant and webapp can now actually do something
+useful, I'll probably be merging them into `master` soon.
+
+Details follow..
+
+---
+
+So, yesterday's part of this was building the configuration page to add
+a removable drive. That needs to be as simple as possible, and it currently
+consists of a list of things git-annex thinks might be mount points of
+removable drives, along with how much free space they have. Pick a drive,
+click the pretty button, and away it goes..
+
+(I decided to make the page so simple it doesn't even ask where you want
+to put the directory on the removable drive. It always puts it in
+a "annex" directory. I might add an expert screen later, but experts can
+always set this up themselves at the command line too.)
+
+I also fought with Yesod and Bootstrap rather a lot to make the form look good.
+Didn't entirely succeed, and had to file a bug on Yesod about its handling of
+check boxes. (Bootstrap also has a bug, IMHO; its drop down lists are not
+always sized wide enough for their contents.)
+
+Ideally this configuration page would listen for mount events, and refresh
+its list. I may add that eventually; I didn't have a handy channel it
+could use to do that, so defferred it. Another idea is to have the mount
+event listener detect removable drives that don't have an annex on them yet,
+and pop up an alert with a link to this configuration page.
+
+----
+
+Making the form led to a somewhat interesting problem: How to tell if a mounted
+filesystem is a removable drive, or some random thing like `/proc` or
+a fuse filesystem. My answer, besides checking that the user can
+write to it, was various heuristics, which seem to work ok, at least here..
+
+[[!format haskell """
+               sane Mntent { mnt_dir = dir, mnt_fsname = dev }
+                        {- We want real disks like /dev/foo, not
+                         - dummy mount points like proc or tmpfs or
+                         - gvfs-fuse-daemon. -}
+                        | not ('/' `elem` dev) = False
+                        {- Just in case: These mount points are surely not
+                         - removable disks. -}
+                        | dir == "/" = False
+                        | dir == "/tmp" = False
+                        | dir == "/run/shm" = False
+                        | dir == "/run/lock" = False
+"""]]
+
+----
+
+Today I did all the gritty coding to make it create a git repository on the
+removable drive, and tell the Annex monad about it, and ensure it gets synced.
+
+As part of that, it detects when the removable drive's filesystem doesn't
+support symlinks, and makes a bare repository in that case. Another expert
+level config option that's left out for now is to always make a bare
+repository, or even to make a directory special remote rather than a git
+repository at all. (But directory special remotes cannot support the
+sneakernet use case by themselves...)
+
+----
+
+Another somewhat interesting problem was what to call the git remotes
+that it sets up on the removable drive and the local repository.
+Again this could have an expert-level configuration, but the defaults
+I chose are to use the hostname as the remote name on the removable drive,
+and to use the basename of the mount point of the removable drive as the 
+remote name in the local annex.
+
+----
+
+Originally, I had thought of this as cloning the repository to the drive.
+But, partly due to luck, I started out just doing a `git init` to make
+the repository (I had a function lying around to do that..).
+
+And as I worked on it some more, I realized this is not as simple as a
+clone. It's a bi-directional sync/merge, and indeed the removable drive may
+have all the data already in it, and the local repository have just been
+created. Handling all the edge cases of that (like, the local repository
+may not have a "master" branch yet..) was fun!
diff --git a/doc/design/assistant/blog/day_54__adding_removable_drives/comment_1_5de4f220a3534f55b1f2208d1d812d63._comment b/doc/design/assistant/blog/day_54__adding_removable_drives/comment_1_5de4f220a3534f55b1f2208d1d812d63._comment
new file mode 100644
index 0000000000..56f513a38c
--- /dev/null
+++ b/doc/design/assistant/blog/day_54__adding_removable_drives/comment_1_5de4f220a3534f55b1f2208d1d812d63._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2012-08-05T23:50:57Z"
+ content="""
+Using `annex` as default is fine, but even non-technical users will need a way to create different annexes for different usage. Or if two users share one thumb drive and each has their own annex. Long story short, I don't think this is an expert option, but something every user should be able to change immediately.
+
+A pre-populated text area makes most sense, imo.
+"""]]
diff --git a/doc/design/assistant/blog/day_54__adding_removable_drives/comment_2_8dae1ed0a70acf9628b88692dc32ac5f._comment b/doc/design/assistant/blog/day_54__adding_removable_drives/comment_2_8dae1ed0a70acf9628b88692dc32ac5f._comment
new file mode 100644
index 0000000000..b26d9b85f7
--- /dev/null
+++ b/doc/design/assistant/blog/day_54__adding_removable_drives/comment_2_8dae1ed0a70acf9628b88692dc32ac5f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://dieter-be.myopenid.com/"
+ nickname="dieter"
+ subject="comment 2"
+ date="2012-08-06T08:30:47Z"
+ content="""
++1 on what Richard said
+about the correctly figuring out what are valid mountpoints / devices that can be used, your current code doesn't seem very robust.
+check this out https://github.com/Dieterbe/aif/blob/develop/src/core/libs/lib-blockdevices-filesystems.sh#L213
+"""]]
diff --git a/doc/design/assistant/blog/day_55__alerts.mdwn b/doc/design/assistant/blog/day_55__alerts.mdwn
new file mode 100644
index 0000000000..95e52e8ad6
--- /dev/null
+++ b/doc/design/assistant/blog/day_55__alerts.mdwn
@@ -0,0 +1,10 @@
+Nothing flashy today; I was up all night trying to download photos taken 
+by a robot lowered onto Mars by a skycrane.
+
+Some work on alerts. Added an alert when a file transfer succeeds or fails.
+Improved the alert combining code so it handles those alerts, and
+simplified it a lot, and made it more efficient.
+
+Also made the text of action alerts change from present to past tense when
+the action finishes. To support that I wrote a fun data type, a `TenseString`
+that can be rendered in either tense.
diff --git a/doc/design/assistant/blog/day_55__alerts/comment_1_6319045500a8a5e049304fdec5ff4cf4._comment b/doc/design/assistant/blog/day_55__alerts/comment_1_6319045500a8a5e049304fdec5ff4cf4._comment
new file mode 100644
index 0000000000..67259bf1e5
--- /dev/null
+++ b/doc/design/assistant/blog/day_55__alerts/comment_1_6319045500a8a5e049304fdec5ff4cf4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlJ2utMQgMEYAOs3Dfc6eZRyUzt4acNXUU"
+ nickname="David"
+ subject="comment 1"
+ date="2012-08-06T23:48:28Z"
+ content="""
+I see you are a regular XKCD reader
+"""]]
diff --git a/doc/design/assistant/blog/day_56__transfer_control.mdwn b/doc/design/assistant/blog/day_56__transfer_control.mdwn
new file mode 100644
index 0000000000..1ce9268974
--- /dev/null
+++ b/doc/design/assistant/blog/day_56__transfer_control.mdwn
@@ -0,0 +1,8 @@
+A bit under the weather, but got into building buttons to control running
+and queued transfers today. The html and javascript side is done, with
+each transfer now having a cancel button, as well as a pause/start button.
+
+Canceling queued transfers works. Canceling running transfers will
+need some more work, because killing a thread doesn't kill the processes
+being run by that thread. So I'll have to make the assistant run separate
+git-annex processes for transfers, that can be individually sent signals.
diff --git a/doc/design/assistant/blog/day_57__afk.mdwn b/doc/design/assistant/blog/day_57__afk.mdwn
new file mode 100644
index 0000000000..c72849ce73
--- /dev/null
+++ b/doc/design/assistant/blog/day_57__afk.mdwn
@@ -0,0 +1,40 @@
+Probably won't be doing any big coding on the git-annex assistant in the
+upcoming week, as I'll be traveling and/or slightly ill enough that I can't
+fully get into <a href="http://en.wikipedia.org/wiki/Flow_(psychology)">flow</a>.
+
+---
+
+There was a new Yesod release this week, which required minor changes to
+make the webapp build with it. I managed to keep the old version of Yesod
+also supported, and plan to keep that working so it can be built with the
+version of Yesod available in, eg, Linux distributions. TBD how much pain
+that will involve going forward.
+
+---
+
+I'm mulling over how to support stopping/pausing transfers. The problem
+is that if the assistant is running a transfer in one thread, and the
+webapp is used to cancel it, killing that thread won't necessarily stop the
+transfer, because, at least in Haskell's thread model, killing a thread
+does not kill processes started by the thread (like rsync).
+
+So one option is to have the transfer thread run a separate git-annex
+process, which will run the actual transfer. And killing that process will
+stop the transfer nicely. However, using a separate git-annex process means
+a little startup overhead for each file transferred (I don't know if it'd
+be enough to matter). Also, there's the problem that git-annex is sometimes
+not installed in PATH (wish I understood why cabal does that), which
+makes it kind of hard for it to run itself. (It can't simply fork, sadly.
+See past horrible pain with forking and threads.)
+
+The other option is to change the API for git-annex remotes, so that
+their `storeKey` and `retrieveKeyFile` methods return a pid of the program
+that they run. When they *do* run a program.. not all remotes do. This
+seems like it'd make the code in the remotes hairier, and it is also asking
+for bugs, when a remote's implementation changes. Or I could go
+lower-level, and make every place in the utility libraries that forks a
+process record its pid in a per-thread MVar. Still seems to be asking for
+bugs.
+
+Oh well, at least git-annex is already crash-safe, so once I figure out
+how to kill a transfer process, I can kill it safely. :)
diff --git a/doc/design/assistant/blog/day_57__afk/comment_1_70e1c9f925f040c1700d3e26bab373d5._comment b/doc/design/assistant/blog/day_57__afk/comment_1_70e1c9f925f040c1700d3e26bab373d5._comment
new file mode 100644
index 0000000000..c83403620a
--- /dev/null
+++ b/doc/design/assistant/blog/day_57__afk/comment_1_70e1c9f925f040c1700d3e26bab373d5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://claimid.com/strager"
+ nickname="strager"
+ subject="comment 1"
+ date="2012-08-11T04:50:52Z"
+ content="""
+What if `storeKey`, `retrieveKeyFile`, etc. return an `IO ()` which cancels the operation, if possible?  The implementation can be canceled regardless if it uses separate processes or Haskell threads.
+
+"""]]
diff --git a/doc/design/assistant/blog/day_57__afk/comment_2_c70d3faccfcebf47deb25e270498cb56._comment b/doc/design/assistant/blog/day_57__afk/comment_2_c70d3faccfcebf47deb25e270498cb56._comment
new file mode 100644
index 0000000000..7539ea2def
--- /dev/null
+++ b/doc/design/assistant/blog/day_57__afk/comment_2_c70d3faccfcebf47deb25e270498cb56._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://claimid.com/strager"
+ nickname="strager"
+ subject="comment 2"
+ date="2012-08-11T04:55:13Z"
+ content="""
+In fact, making a dedicated data type or some typeclasses may be more appropriate:
+
+    class Cancelable a where cancel :: a -> IO ()
+    class Pauseable a where pause :: a -> IO ()
+
+    -- Alternatively:
+
+    data Transfer = Transfer { cancel :: IO (), pause :: IO () }
+
+    -- Or both!
+
+"""]]
diff --git a/doc/design/assistant/blog/day_57__afk/comment_3_89020ebc6d31485339bdea41a872df3c._comment b/doc/design/assistant/blog/day_57__afk/comment_3_89020ebc6d31485339bdea41a872df3c._comment
new file mode 100644
index 0000000000..ed02b9dcee
--- /dev/null
+++ b/doc/design/assistant/blog/day_57__afk/comment_3_89020ebc6d31485339bdea41a872df3c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 3"
+ date="2012-08-11T14:41:51Z"
+ content="""
+That's the lines I was thinking along, and I even made a throwaway branch with some types. But the problem is reworking all the code to do that. Particularly since lots of the code uses generic utility functions that are reused in other, unrelated places and would have to be modified to pass back cancel actions.
+
+The first case the type checker landed me on when I changed the types was code that downloads an url from the web. Naturally that uses a Utility.Url.download. How to cancel `download`? Depends on its implementation -- it happens to currently shell out to curl, so you have to kill curl, but it could just as easily have used libcurl (other parts of my Utility.Url library do), and then it would need to fork its own thread. So it's an abstraction layer violation problem.
+
+If I had a month to devote to this one problem, I might manage to come up with some clean solution involving monads, or maybe convert all my code to use conduit or something that might allow managing these effects better. Just a guess..
+"""]]
diff --git a/doc/design/assistant/blog/day_57__afk/comment_4_8b1f65f141ffd9813e7f5a3380f7f520._comment b/doc/design/assistant/blog/day_57__afk/comment_4_8b1f65f141ffd9813e7f5a3380f7f520._comment
new file mode 100644
index 0000000000..c87e447d1c
--- /dev/null
+++ b/doc/design/assistant/blog/day_57__afk/comment_4_8b1f65f141ffd9813e7f5a3380f7f520._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="http://claimid.com/strager"
+ ip="173.228.13.253"
+ subject="comment 4"
+ date="2012-08-11T16:08:47Z"
+ content="""
+> How to cancel download?  Depends on its implementation ....  So it's an abstraction layer violation problem.
+
+Precisely why I suggested returning something as generic as `IO ()`:
+
+    -- Current
+    download :: URLString -> Headers -> [CommandParam] -> FilePath -> IO Bool
+
+    -- Suggestion
+    data Transfer a = Transfer { run :: IO a, cancel :: IO () }
+    download :: URLString -> Headers -> [CommandParam] -> FilePath -> Transfer
+
+    transfer <- download ...
+    -- You can pass `cancel transfer` to another thread
+    -- which you want to be able to cancel the transfer.
+    run transfer  -- blocking
+
+I realized while writing this that you may not get any result from e.g. a download while it is occurring (because the function is blocking).  Maybe that's where a misunderstanding occurred.  I separated the concepts of creating a transfer and starting/canceling it.
+
+(My idea is starting to feel a bit object-oriented...  ;P)
+
+"""]]
diff --git a/doc/design/assistant/blog/day_58__more_transfer_control.mdwn b/doc/design/assistant/blog/day_58__more_transfer_control.mdwn
new file mode 100644
index 0000000000..08b69a75d5
--- /dev/null
+++ b/doc/design/assistant/blog/day_58__more_transfer_control.mdwn
@@ -0,0 +1,26 @@
+Unexpectedly managed a mostly productive day today. 
+
+Went ahead with making the assistant run separate `git-annex` processes for
+transfers. This will currently fail if git-annex is not installed in PATH.
+(Deferred dealing with that.)
+
+To stop a transfer, the webapp needs to signal not just the git-annex
+process, but all its children. I'm using process groups for this, which is
+working, but I'm not extremely happy with.
+
+Anyway, the webapp's UI can now be used for stopping transfers, and it
+wasn't far from there to also implementing pausing of transfers. 
+
+Pausing a transfer is actually the same as stopping it, except a special
+signal is sent to the transfer control thread, which keeps running, despite
+the git-annex process having been killed, waits for a special resume
+signal, and restarts the transfer. This way a paused transfer continues to
+occupy a transfer slot, which prevents other queued transfers from running.
+This seems to be the behavior that makes sense.
+
+Still need to wire up the webapp's button for starting a transfer. For a
+paused transfer, that will just need to resume it. I have not decided what
+the button should do when used on a transfer that is queued but not running
+yet. Maybe it forces it to run even if all transfer slots are already in
+use? Maybe it stops one of the currently running transfers to free up a
+slot?
diff --git a/doc/design/assistant/blog/day_59__dinner.mdwn b/doc/design/assistant/blog/day_59__dinner.mdwn
new file mode 100644
index 0000000000..545125ac66
--- /dev/null
+++ b/doc/design/assistant/blog/day_59__dinner.mdwn
@@ -0,0 +1,10 @@
+Actually did do some work on the webapp today, just fixing a bug I noticed
+in a spare moment. Also managed a bit in the plane earlier this week,
+implementing resuming of paused transfers. (Still need to test that.)
+
+But the big thing today was dinner with one of my major Kickstarter
+backers, and as it turned out, "half the Haskell community of San
+Francisco" (3 people). Enjoyed talking about git-annex and haskell with
+them.
+
+I'm looking forward to getting back home and back to work on Monday..
diff --git a/doc/design/assistant/blog/day_59__dinner/comment_1_0c1e2d69496473e7e4a2956a2814f5dd._comment b/doc/design/assistant/blog/day_59__dinner/comment_1_0c1e2d69496473e7e4a2956a2814f5dd._comment
new file mode 100644
index 0000000000..1e10549d37
--- /dev/null
+++ b/doc/design/assistant/blog/day_59__dinner/comment_1_0c1e2d69496473e7e4a2956a2814f5dd._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://claimid.com/strager"
+ ip="173.228.13.253"
+ subject="comment 1"
+ date="2012-08-17T15:59:49Z"
+ content="""
+It was fun to have you here!  =]
+
+"""]]
diff --git a/doc/design/assistant/blog/day_5__committing.mdwn b/doc/design/assistant/blog/day_5__committing.mdwn
new file mode 100644
index 0000000000..5623873805
--- /dev/null
+++ b/doc/design/assistant/blog/day_5__committing.mdwn
@@ -0,0 +1,57 @@
+After a few days otherwise engaged, back to work today.
+
+My focus was on adding the committing thread mentioned in [[day_4__speed]].
+I got rather further than expected!
+
+First, I implemented a really dumb thread, that woke up once per second,
+checked if any changes had been made, and committed them. Of course, this
+rather sucked. In the middle of a large operation like untarring a tarball,
+or `rm -r` of a large directory tree, it made lots of commits and made
+things slow and ugly. This was not unexpected.
+
+So next, I added some smarts to it. First, I wanted to stop it waking up
+every second when there was nothing to do, and instead blocking wait on a
+change occurring. Secondly, I wanted it to know when past changes happened,
+so it could detect batch mode scenarios, and avoid committing too
+frequently. 
+
+I played around with combinations of various Haskell thread communications
+tools to get that information to the committer thread: `MVar`, `Chan`,
+`QSem`, `QSemN`. Eventually, I realized all I needed was a simple channel
+through which the timestamps of changes could be sent. However, `Chan`
+wasn't quite suitable, and I had to add a dependency on 
+[Software Transactional Memory](http://en.wikipedia.org/wiki/Software_Transactional_Memory),
+and use a `TChan`. Now I'm cooking with gas!
+
+With that data channel available to the committer thread, it quickly got
+some very nice smart behavior. Playing around with it, I find it commits
+*instantly* when I'm making some random change that I'd want the
+git-annex assistant to sync out instantly; and that its batch job detection
+works pretty well too.
+
+There's surely room for improvement, and I made this part of the code
+be an entirely pure function, so it's really easy to change the strategy.
+This part of the committer thread is so nice and clean, that here's the
+current code, for your viewing pleasure:
+
+[[!format haskell """
+{- Decide if now is a good time to make a commit.
+ - Note that the list of change times has an undefined order.
+ -
+ - Current strategy: If there have been 10 commits within the past second,
+ - a batch activity is taking place, so wait for later.
+ -}
+shouldCommit :: UTCTime -> [UTCTime] -> Bool
+shouldCommit now changetimes
+       | len == 0 = False
+       | len > 4096 = True -- avoid bloating queue too much
+       | length (filter thisSecond changetimes) < 10 = True
+       | otherwise = False -- batch activity
+       where
+               len = length changetimes
+               thisSecond t = now `diffUTCTime` t <= 1
+"""]]
+
+Still some polishing to do to eliminate minor inefficiencies and deal
+with more races, but this part of the git-annex assistant is now very usable,
+and will be going out to my beta testers soon!
diff --git a/doc/design/assistant/blog/day_60__taking_stock.mdwn b/doc/design/assistant/blog/day_60__taking_stock.mdwn
new file mode 100644
index 0000000000..040d0cd7c1
--- /dev/null
+++ b/doc/design/assistant/blog/day_60__taking_stock.mdwn
@@ -0,0 +1,40 @@
+As I prepare to dive back into development, now is a good time to review
+what I've built so far, and how well I'm keeping up with my planned
+[[roadmap|assistant]].
+
+I started working two and a half months ago, so am nearing the end of
+the three months I originally asked to be funded for on Kickstarter.
+
+I've built much of what I planned to build in the first three months --
+[[inotify]] is done (and kqueue is basically working, but needs scalability
+work), local [[syncing]] is done, the [[webapp]] works, and I've built some
+of the first [[configurators]]. It's all functional in a narrow use case
+involving syncing to removable drives. 
+
+[[progressbars]] still need to be dealt with, and network syncing needs to
+be revisited soon, so that I can start building easy configurators for
+further use cases, like using the cloud, or another machine on the local
+network.
+
+I think I'm a little behind my original schedule, but not too bad,
+and at the same time, I think I've built things rather more solidly than I
+expected them to be at this point. I'm particularly happy with how well
+the inotify code works, no matter what is thrown at it, and how nice
+the UI in the webapp is shaping up to be.
+
+----
+
+I also need to get started on fulfilling my Kickstarter rewards, and
+I was happy to spend some time in the airport working on the main
+blocker toward that, a lack of a scalable git-annex logo, which is needed
+for printing on swag.
+
+Turns out that inkscape has some amazing bitmap tracing capabilities.
+I was able to come up with this scalable logo in short order, it 
+actually took longer to add back the colors, as the tracer generated a
+black and white version.
+
+With that roadblock out of the way, I am moving toward ordering large
+quantities of usb drives, etc.
+
+[[logo.svg]]
diff --git a/doc/design/assistant/blog/day_60__taking_stock/comment_1_6722f81ee084f1ea9e8fe47f34576397._comment b/doc/design/assistant/blog/day_60__taking_stock/comment_1_6722f81ee084f1ea9e8fe47f34576397._comment
new file mode 100644
index 0000000000..cfe4fa300b
--- /dev/null
+++ b/doc/design/assistant/blog/day_60__taking_stock/comment_1_6722f81ee084f1ea9e8fe47f34576397._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://dieter-be.myopenid.com/"
+ nickname="dieter"
+ subject="better logo?"
+ date="2012-08-20T21:22:25Z"
+ content="""
+Maybe you should contact designers and see what kind of logo they can come up with.  Probably something better.
+"""]]
diff --git a/doc/design/assistant/blog/day_61__network_connection_detection.mdwn b/doc/design/assistant/blog/day_61__network_connection_detection.mdwn
new file mode 100644
index 0000000000..8ab40f5162
--- /dev/null
+++ b/doc/design/assistant/blog/day_61__network_connection_detection.mdwn
@@ -0,0 +1,36 @@
+Today, added a thread that deals with recovering when there's been a loss
+of network connectivity. When the network's down, the normal immediate
+syncing of changes of course doesn't work. So this thread detects when the
+network comes back up, and does a pull+push to network remotes, and
+triggers scanning for file content that needs to be transferred.
+
+I used dbus again, to detect events generated by both network-manager and
+wicd when they've sucessfully brought an interface up. Or, if they're not
+available, it polls every 30 minutes.
+
+When the network comes up, in addition to the git pull+push, it also
+currently does a full scan of the repo to find files whose contents
+need to be transferred to get fully back into sync.
+
+I think it'll be ok for some git pulls and pushes to happen when
+moving to a new network, or resuming a laptop (or every 30 minutes when
+resorting to polling). But the transfer scan is currently really too heavy
+to be appropriate to do every time in those situations. I have an idea for
+avoiding that scan when the remote's git-annex branch has not changed. But
+I need to refine it, to handle cases like this:
+
+1. a new remote is added
+2. file contents start being transferred to (or from it)
+3. the network is taken down
+4. all the queued transfers fail
+5. the network comes back up
+6. the transfer scan needs to know the remote was not all in sync
+   before #3, and so should do a full scan despite the git-annex branch
+   not having changed
+
+---
+
+Doubled the ram in my netbook, which I use for all development. Yesod needs
+rather a lot of ram to compile and link, and this should make me quite a
+lot more productive. I was struggling with OOM killing bits of chromium
+during my last week of development.
diff --git a/doc/design/assistant/blog/day_61__network_connection_detection/comment_1_09b58f41a8d48f218619711ee19511ac._comment b/doc/design/assistant/blog/day_61__network_connection_detection/comment_1_09b58f41a8d48f218619711ee19511ac._comment
new file mode 100644
index 0000000000..029aec7832
--- /dev/null
+++ b/doc/design/assistant/blog/day_61__network_connection_detection/comment_1_09b58f41a8d48f218619711ee19511ac._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmubB1Sj2rwFoVdZYvGV0ACaQUJQyiJXJI"
+ nickname="Paul"
+ subject="Amazon Glacier"
+ date="2012-08-23T06:32:24Z"
+ content="""
+Do you think git-annex could support [Amazon Glacier](http://aws.amazon.com/glacier/) as a backend?
+"""]]
diff --git a/doc/design/assistant/blog/day_62__smarter_syncing.mdwn b/doc/design/assistant/blog/day_62__smarter_syncing.mdwn
new file mode 100644
index 0000000000..28fa892d38
--- /dev/null
+++ b/doc/design/assistant/blog/day_62__smarter_syncing.mdwn
@@ -0,0 +1,21 @@
+Woke up this morning with most of the design for a smarter approach to
+[[syncing]] in my head. (This is why I sometimes slip up and tell people I
+work on this project 12 hours a day..)
+
+To keep the current `assistant` branch working while I make changes
+that break use cases that are working, I've started 
+developing in a new branch, `assistant-wip`.
+
+In it, I've started getting rid of unnecessary expensive transfer scans.
+
+First optimisation I've done is to detect when a remote that was
+disconnected has diverged its `git-annex` branch from the local branch.
+Only when that's the case does a new transfer scan need to be done, to find
+out what new stuff might be available on that remote, to have caused the
+change to its branch, while it was disconnected.
+
+That broke a lot of stuff. I have a plan to fix it written down in
+[[syncing]]. It'll involve keeping track of whether a transfer scan has
+ever been done (if not, one should be run), and recording logs when
+transfers failed, so those failed transfers can be retried when the
+remote gets reconnected.
diff --git a/doc/design/assistant/blog/day_63__transfer_retries.mdwn b/doc/design/assistant/blog/day_63__transfer_retries.mdwn
new file mode 100644
index 0000000000..d668f507ba
--- /dev/null
+++ b/doc/design/assistant/blog/day_63__transfer_retries.mdwn
@@ -0,0 +1,26 @@
+Implemented everything I planned out yesterday: Expensive scans are only
+done once per remote (unless the remote changed while it was disconnected),
+and failed transfers are logged so they can be retried later.
+
+Changed the TransferScanner to prefer to scan low cost remotes first,
+as a crude form of scheduling lower-cost transfers first.
+
+A whole bunch of interesting syncing scenarios should work now. I have not
+tested them all in detail, but to the best of my knowledge, all these
+should work:
+
+* Connect to the network. It starts syncing with a networked remote.
+  Disconnect the network. Reconnect, and it resumes where it left off.
+* Migrate between networks (ie, home to cafe to work). Any transfers
+  that can only happen on one LAN are retried on each new network you
+  visit, until they succeed.
+
+One that is not working, but is soooo close:
+
+* Plug in a removable drive. Some transfers start. Yank the plug.
+  Plug it back in. All necessary transfers resume, and it ends up
+  fully in sync, no matter how many times you yank that cable.
+
+That's not working because of an infelicity in the MountWatcher.
+It doesn't notice when the drive gets unmounted, so it ignores
+the new mount event.
diff --git a/doc/design/assistant/blog/day_63__transfer_retries/comment_1_990d4eb6066c4e2b9ddb3cabef32e4b9._comment b/doc/design/assistant/blog/day_63__transfer_retries/comment_1_990d4eb6066c4e2b9ddb3cabef32e4b9._comment
new file mode 100644
index 0000000000..119aee2c91
--- /dev/null
+++ b/doc/design/assistant/blog/day_63__transfer_retries/comment_1_990d4eb6066c4e2b9ddb3cabef32e4b9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2012-08-23T21:25:48Z"
+ content="""
+Do encrypted rsync remotes resume quickly as well?
+
+One thing I noticed was that if a copy --to an encrypted rsync remote gets interrupted it will remove the tmp file and re-encrypt the whole file before resuming rsync.
+"""]]
diff --git a/doc/design/assistant/blog/day_64__syncing_robustly.mdwn b/doc/design/assistant/blog/day_64__syncing_robustly.mdwn
new file mode 100644
index 0000000000..ab0090b92d
--- /dev/null
+++ b/doc/design/assistant/blog/day_64__syncing_robustly.mdwn
@@ -0,0 +1,33 @@
+Working toward getting the data syncing to happen robustly,
+so a bunch of improvements.
+
+* Got unmount events to be noticed, so unplugging and replugging
+  a removable drive will resume the syncing to it. There's really no
+  good unmount event available on dbus in kde, so it uses a heuristic
+  there.
+* Avoid requeuing a download from a remote that no longer has a key.
+* Run a full scan on startup, for multiple reasons, including dealing with
+  crashes.
+
+Ran into a strange issue: Occasionally the assistant will run `git-annex
+copy` and it will not transfer the requested file. It seems that
+when the copy command runs `git ls-files`, it does not see the file
+it's supposed to act on in its output.
+
+Eventually I figured out what's going on: When updating the git-annex
+branch, it sets `GIT_INDEX_FILE`, and of course environment settings are
+not thread-safe! So there's a race between threads that access
+the git-annex branch, and the Transferrer thread, or any other thread
+that might expect to look at the normal git index.
+
+Unfortunatly, I don't have a fix for this yet.. Git's only interface for
+using a different index file is `GIT_INDEX_FILE`. It seems I have a lot of
+code to tear apart, to push back the setenv until after forking every git
+command. :(
+
+Before I figured out the root problem, I developed a workaround for the
+symptom I was seeing. I added a `git-annex transferkey`, which is
+optimised to be run by the assistant, and avoids running `git ls-files`, so
+avoids the problem. While I plan to fix this environment variable problem
+properly, `transferkey` turns out to be so much faster than how it was
+using `copy` that I'm going to keep it.
diff --git a/doc/design/assistant/blog/day_65__transfer_polish.mdwn b/doc/design/assistant/blog/day_65__transfer_polish.mdwn
new file mode 100644
index 0000000000..af1c691621
--- /dev/null
+++ b/doc/design/assistant/blog/day_65__transfer_polish.mdwn
@@ -0,0 +1,33 @@
+Almost done with the data transfer code.. Today I filled in some bits and
+peices.
+
+Made the expensive transfer scan handle multiple remotes in one pass.
+So on startup, it only runs once, not N times. And when reconnecting to the
+network, when a remote has changed, it scans all network remotes in one
+pass, rather than making M redundant passes.
+
+Got syncing with special remotes all working. Pretty easy actually. Just
+had to avoid doing any git repo push/pull with them, while still queueing
+data transfers.
+
+It'll even download anything it can from the web special remote. To support
+that, I added generic support for readonly remotes; it'll only download from
+those and not try to upload to them.
+
+(Oh, and I properly fixed the nasty `GIT_INDEX_FILE` environment variable
+problem I had the other day.)
+
+I feel I'm very close to being able to merge the assistant branch into
+master now. I'm reasonably confident the data transfer code will work
+well now, and manage to get things in sync eventually in all circumstances.
+(Unless there are bugs.) All the other core functionality of the assistant
+and webapp is working. The only think I might delay because of is the
+missing [[progressbars]] in the webapp .. but that's a silly thing to
+block the merge on. 
+
+Still, I might spend a day and get a dumb implementation of progress bars
+for downloads working first (progress bars for uploads are probably rather
+harder). I'd spend longer on progress bars, but there are so many more
+exciting things I'm now ready to develop, like automatic configurators
+for using your git annex with Amazon S3, rsync.net, and the computer across
+the room..!
diff --git a/doc/design/assistant/blog/day_66__the_merge.mdwn b/doc/design/assistant/blog/day_66__the_merge.mdwn
new file mode 100644
index 0000000000..0442865ba3
--- /dev/null
+++ b/doc/design/assistant/blog/day_66__the_merge.mdwn
@@ -0,0 +1,19 @@
+It's done! The assistant branch is merged into master.
+
+Updated the [[assistant]] page with some screenshots and instructions for
+using it.
+
+Made some cosmetic fixes to the webapp.
+
+Fixed the transferrer to use `~/.config/git-annex/program`
+to find the path to git-annex when running it. (There are ways to find the
+path of the currently running program in unux, but they all suck, so I'm
+avoiding them this way.)
+
+Read some OSX launchd documentation, and it seems it'd be pretty easy to
+get the assistant to autostart on login on OSX. If someone would like to
+test launchd files for me, get in touch.
+
+-----
+
+AKA: Procrastinating really hard on those progress bars. ;)
diff --git a/doc/design/assistant/blog/day_66__the_merge/comment_10_eeccf4e73cc321542a1fe4780805a81e._comment b/doc/design/assistant/blog/day_66__the_merge/comment_10_eeccf4e73cc321542a1fe4780805a81e._comment
new file mode 100644
index 0000000000..2e787076d8
--- /dev/null
+++ b/doc/design/assistant/blog/day_66__the_merge/comment_10_eeccf4e73cc321542a1fe4780805a81e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://kevwalke.myopenid.com/"
+ ip="94.175.38.180"
+ subject="confirmed!"
+ date="2012-09-02T07:17:43Z"
+ content="""
+Got it built and running. Thanks for this.
+I can see already that this is going to be a fantastic application. 
+
+Good Work!
+-Kev
+"""]]
diff --git a/doc/design/assistant/blog/day_66__the_merge/comment_1_a34e89316d1662826848f31061c4e46b._comment b/doc/design/assistant/blog/day_66__the_merge/comment_1_a34e89316d1662826848f31061c4e46b._comment
new file mode 100644
index 0000000000..be612801e3
--- /dev/null
+++ b/doc/design/assistant/blog/day_66__the_merge/comment_1_a34e89316d1662826848f31061c4e46b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://kevwalke.myopenid.com/"
+ ip="94.175.38.180"
+ subject="well done!"
+ date="2012-08-27T22:08:23Z"
+ content="""
+absolutely fantastic news! I am itching to try this out now. Thank you!
+"""]]
diff --git a/doc/design/assistant/blog/day_66__the_merge/comment_2_09e244d23d05052fa2b11a7181888366._comment b/doc/design/assistant/blog/day_66__the_merge/comment_2_09e244d23d05052fa2b11a7181888366._comment
new file mode 100644
index 0000000000..874aa5ea6a
--- /dev/null
+++ b/doc/design/assistant/blog/day_66__the_merge/comment_2_09e244d23d05052fa2b11a7181888366._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://claimid.com/strager"
+ ip="173.228.13.253"
+ subject="comment 2"
+ date="2012-08-28T16:29:56Z"
+ content="""
+I have a few OS X machines I can test on.  Send me details at: strager.nds@gmail.com
+"""]]
diff --git a/doc/design/assistant/blog/day_66__the_merge/comment_3_3961a03e167903959b96b054835613f6._comment b/doc/design/assistant/blog/day_66__the_merge/comment_3_3961a03e167903959b96b054835613f6._comment
new file mode 100644
index 0000000000..4a4d0df409
--- /dev/null
+++ b/doc/design/assistant/blog/day_66__the_merge/comment_3_3961a03e167903959b96b054835613f6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 3"
+ date="2012-08-28T18:44:28Z"
+ content="""
+As per usual I'd volunteer to test on OSX as well.
+"""]]
diff --git a/doc/design/assistant/blog/day_66__the_merge/comment_4_12a57af9f580918818b4a9f68396d5c4._comment b/doc/design/assistant/blog/day_66__the_merge/comment_4_12a57af9f580918818b4a9f68396d5c4._comment
new file mode 100644
index 0000000000..6852a805a7
--- /dev/null
+++ b/doc/design/assistant/blog/day_66__the_merge/comment_4_12a57af9f580918818b4a9f68396d5c4._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://kevwalke.myopenid.com/"
+ ip="77.86.30.139"
+ subject="building and installing with cabal"
+ date="2012-08-29T18:15:07Z"
+ content="""
+So I got round to trying it out. I cloned the latest from the repository@ git://git-annex.branchable.com/ and then followed the instructions on the install page: http://git-annex.branchable.com/install/cabal/
+However I get a dependency problem:
+
+cabal install --only-dependencies
+Resolving dependencies...
+cabal: Could not resolve dependencies:
+trying: git-annex-3.20120825 (user goal)
+trying: git-annex-3.20120825:+oldyesod
+trying: git-annex-3.20120825:+currentyesod
+next goal: yesod-default (dependency of git-annex-3.20120825:+oldyesod)
+rejecting: yesod-default-1.1.0 (conflict: git-annex-3.20120825:oldyesod =>
+yesod-default(<=1.0.1.1))
+rejecting: yesod-default-1.0.1.1, 1.0.1, 1.0.0, 0.6.1, 0.5.0, 0.4.1, 0.4.0,
+0.3.1 (conflict: git-annex-3.20120825:currentyesod => yesod-default(>=1.1.0))
+
+I'm not sure how to proceed from here and would be grateful of any pointers to help get this built
+"""]]
diff --git a/doc/design/assistant/blog/day_66__the_merge/comment_5_8ce638960012367c888e018a5f05db19._comment b/doc/design/assistant/blog/day_66__the_merge/comment_5_8ce638960012367c888e018a5f05db19._comment
new file mode 100644
index 0000000000..f51f5ef528
--- /dev/null
+++ b/doc/design/assistant/blog/day_66__the_merge/comment_5_8ce638960012367c888e018a5f05db19._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.16"
+ subject="comment 5"
+ date="2012-08-29T22:17:01Z"
+ content="""
+@kevwalke: I fixed that problem today.
+"""]]
diff --git a/doc/design/assistant/blog/day_66__the_merge/comment_6_f461b856b940e6914bcd2b681cf9505f._comment b/doc/design/assistant/blog/day_66__the_merge/comment_6_f461b856b940e6914bcd2b681cf9505f._comment
new file mode 100644
index 0000000000..2232c426b8
--- /dev/null
+++ b/doc/design/assistant/blog/day_66__the_merge/comment_6_f461b856b940e6914bcd2b681cf9505f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://kevwalke.myopenid.com/"
+ ip="77.86.30.139"
+ subject="getting new error now."
+ date="2012-08-30T11:55:49Z"
+ content="""
+Seems there is still an issue here on fresh install...
+
+cabal: Error: some packages failed to install:
+dbus-0.10 depends on libxml-sax-0.7.2 which failed to install.
+libxml-sax-0.7.2 failed during the configure step. The exception was:
+ExitFailure 
+"""]]
diff --git a/doc/design/assistant/blog/day_66__the_merge/comment_7_6e73aca1fc1747d0e742e054b88b5d78._comment b/doc/design/assistant/blog/day_66__the_merge/comment_7_6e73aca1fc1747d0e742e054b88b5d78._comment
new file mode 100644
index 0000000000..0cb970a4cd
--- /dev/null
+++ b/doc/design/assistant/blog/day_66__the_merge/comment_7_6e73aca1fc1747d0e742e054b88b5d78._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.16"
+ subject="comment 7"
+ date="2012-08-30T17:15:58Z"
+ content="""
+It's hard to tell from that error message what's going on. I'd hope that there was actually a real error message printed earlier than that that.
+
+For now, I can only guess.. In order to install the haskell libxml-sax library, you need to have the GNOME XML2 library installed, including development headers. On Debian and derivatives, that is `apt-get install libxml2-dev`. 
+
+Alternatively, you can disable use of dbus by passing this to your cabal install: `--flags=-Dbus`
+"""]]
diff --git a/doc/design/assistant/blog/day_66__the_merge/comment_8_d85f1ce23ae16d5a8eb88d2c3999acb7._comment b/doc/design/assistant/blog/day_66__the_merge/comment_8_d85f1ce23ae16d5a8eb88d2c3999acb7._comment
new file mode 100644
index 0000000000..f2068146d0
--- /dev/null
+++ b/doc/design/assistant/blog/day_66__the_merge/comment_8_d85f1ce23ae16d5a8eb88d2c3999acb7._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://kevwalke.myopenid.com/"
+ ip="94.175.38.180"
+ subject="thanks"
+ date="2012-09-01T14:44:58Z"
+ content="""
+That got rid of that error. However now I get the following at the last step:
+
+Linking dist/build/git-annex/git-annex ...
+Installing executable(s) in /home/kev/bin
+setup: git-annex.1: does not exist
+cabal: Error: some packages failed to install:
+git-annex-3.20120826 failed during the final install step. The exception was:
+ExitFailure 1
+
+There doesn't seem to be any failures further up the output just some warnings. All the other steps complete fine
+Thanks for any advice/pointers here
+-Kevin
+"""]]
diff --git a/doc/design/assistant/blog/day_66__the_merge/comment_9_c06dab4d78122c85beeaf300ffc3e376._comment b/doc/design/assistant/blog/day_66__the_merge/comment_9_c06dab4d78122c85beeaf300ffc3e376._comment
new file mode 100644
index 0000000000..5a2b3c8d19
--- /dev/null
+++ b/doc/design/assistant/blog/day_66__the_merge/comment_9_c06dab4d78122c85beeaf300ffc3e376._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.16"
+ subject="comment 9"
+ date="2012-09-01T19:32:02Z"
+ content="""
+I think I've fixed that.
+"""]]
diff --git a/doc/design/assistant/blog/day_67__progress_bars.mdwn b/doc/design/assistant/blog/day_67__progress_bars.mdwn
new file mode 100644
index 0000000000..1110a3c3f5
--- /dev/null
+++ b/doc/design/assistant/blog/day_67__progress_bars.mdwn
@@ -0,0 +1,10 @@
+Got the webapp's progress bars updating for downloads. Updated
+[[progressbars]] with all the options for ways to get progress info. For
+downloads, it currently uses the easy, and not very expensive, approach of
+periodically polling the sizes of files that are being downloaded.
+
+For uploads, something more sophisticated will be called for..
+
+---
+
+The webapp really feels alive now that it has progress bars!
diff --git a/doc/design/assistant/blog/day_68__transfers.mdwn b/doc/design/assistant/blog/day_68__transfers.mdwn
new file mode 100644
index 0000000000..498f0eae4c
--- /dev/null
+++ b/doc/design/assistant/blog/day_68__transfers.mdwn
@@ -0,0 +1,15 @@
+More work on the display and control of transfers.
+
+* Hide redundant downloads from the transfer display. It seemed simplest
+  to keep the behavior of queuing downloads from every remote that has a
+  file, rather than going to some other data structure, but it's clutter
+  to display those to the user, especially when you often have 7 copies
+  of each file, like I do.
+* When canceling a download, cancel all other queued downloads of that
+  key too.
+* Fixed unsettting of the paused flag when resuming a paused transfer.
+* Implemented starting queued transfers by clicking on the start button.
+* Spent a long time debugging why pausing, then resuming, and then pausing
+  a transfer doesn't successfully pause it the second time. I see where
+  the code is seemingly locking up in a `throwTo`, but I don't understand
+  why that blocks forever. Urgh..
diff --git a/doc/design/assistant/blog/day_68__transfers/comment_1_5282960c0b553fbc0f411345b9745324._comment b/doc/design/assistant/blog/day_68__transfers/comment_1_5282960c0b553fbc0f411345b9745324._comment
new file mode 100644
index 0000000000..0921ae8559
--- /dev/null
+++ b/doc/design/assistant/blog/day_68__transfers/comment_1_5282960c0b553fbc0f411345b9745324._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2012-08-29T21:24:37Z"
+ content="""
+It seems to be a bad idea to cancel everything when I cancel a single transfer.
+
+I may not want to transmit videos and RAW files at the moment, but would still like to know my JPGs are stored in a second location.
+
+Two obvious approaches, ideally both offered at the same time would be to allow the user to cancel, cancel all to this remote, and cancel all plus allowing them to send transfers to the end of the queue.
+
+If this is implemented already then sorry; I did _not_ test if this is available before writing this comment.
+"""]]
diff --git a/doc/design/assistant/blog/day_69__build_fixes.mdwn b/doc/design/assistant/blog/day_69__build_fixes.mdwn
new file mode 100644
index 0000000000..c3ee34e27d
--- /dev/null
+++ b/doc/design/assistant/blog/day_69__build_fixes.mdwn
@@ -0,0 +1,7 @@
+Short day today.
+
+* Worked on fixing a number of build failures people reported.
+* Solved the problem that was making transfer pause/resume not always work.
+  Although there is another bug where pausing a transfer sometimes lets
+  another queued transfer start running. 
+* Worked on getting the assistant to start on login on OSX.
diff --git a/doc/design/assistant/blog/day_6__polish.mdwn b/doc/design/assistant/blog/day_6__polish.mdwn
new file mode 100644
index 0000000000..ebe8068c33
--- /dev/null
+++ b/doc/design/assistant/blog/day_6__polish.mdwn
@@ -0,0 +1,50 @@
+Since my last blog, I've been polishing the `git annex watch` command.
+
+First, I fixed the double commits problem. There's still some extra
+committing going on in the `git-annex` branch that I don't understand. It
+seems like a shutdown event is somehow being triggered whenever
+a git command is run by the commit thread.
+
+I also made `git annex watch` run as a proper daemon, with locking to
+prevent multiple copies running, and a pid file, and everything.
+I made `git annex watch --stop` stop it.
+
+---
+
+Then I managed to greatly increase its startup speed. At startup, it
+generates "add" events for every symlink in the tree. This is necessary
+because it doesn't really know if a symlink is already added, or was
+manually added before it starter, or indeed was added while it started up.
+Problem was that these events were causing a lot of work staging the
+symlinks -- most of which were already correctly staged.
+
+You'd think it could just check if the same symlink was in the index.
+But it can't, because the index is in a constant state of flux. The
+symlinks might have just been deleted and re-added, or changed, and
+the index still have the old value.
+
+Instead, I got creative. :) We can't trust what the index says about the
+symlink, but if the index happens to contain a symlink that looks right,
+we can trust that the SHA1 of its blob is the right SHA1, and reuse it
+when re-staging the symlink. Wham! Massive speedup!
+
+---
+
+Then I started running `git annex watch` on my own real git annex repos,
+and noticed some problems.. Like it turns normal files already checked into
+git into symlinks. And it leaks memory scanning a big tree. Oops..
+
+---
+
+I put together a quick screencast demoing `git annex watch`.
+
+<video controls src="http://joeyh.name/screencasts/git-annex-watch.ogg"></video>
+
+While making the screencast, I noticed that `git-annex watch` was spinning
+in strace, which is bad news for powertop and battery usage. This seems to
+be a [GHC bug](http://bugs.debian.org/677096) also affecting Xmonad. I
+tried switching to GHC's threaded runtime, which solves that problem, but
+causes git-annex to hang under heavy load. Tried to debug that for quite a
+while, but didn't get far. Will need to investigate this further.. 
+Am seeing indications that this problem only affects ghc 7.4.1; in
+particular 7.4.2 does not seem to have the problem.
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes.mdwn b/doc/design/assistant/blog/day_70__adding_ssh_remotes.mdwn
new file mode 100644
index 0000000000..be83daa31a
--- /dev/null
+++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes.mdwn
@@ -0,0 +1,66 @@
+Today I built the UI in the webapp to set up a ssh or rsync remote.
+
+This is the most generic type of remote, and so it's surely got the most
+complex description. I've tried to word it as clearly as I can; suggestions
+most appreciated. Perhaps I should put in a diagram?
+
+[[!img /assistant/addsshserver.png]]
+
+The idea is that this will probe the server, using ssh. If `git-annex-shell`
+is available there, it'll go on to set up a full git remote. If not, it'll
+fall back to setting up a rsync special remote. It'll even fall all the way
+back to using `rsync://` protocol if it can't connect by ssh. So the user
+can just point it at a server and let it take care of the details,
+generally.
+
+The trickiest part of this will be authentication, of course. I'm relying
+on ssh using `ssh-askpass` to prompt for any passwords, etc, when there's
+no controlling terminal. But beyond passwords, this has to deal with ssh
+keys.
+
+I'm planning to make it check if you have a ssh key configured already. If
+you do, it doesn't touch your ssh configuration. I don't want to get in the
+way of people who have a manual configuration or are using MonkeySphere.
+
+But for a user who has never set up a ssh key, it will prompt asking if
+they'd like a key to be set up. If so, it'll generate a key and configure
+ssh to only use it with the server.. and as part of its ssh probe, that key
+will be added to `authorized_keys`.
+
+(Obviously, advanced users can skip this entirely; `git remote add
+ssh://...` still works..)
+
+----
+
+Also today, fixed more UI glitches in the transfer display. I think
+I have them all fixed now, except for the one that needs lots of javascript
+to be written to fix it.
+
+Amusingly, while I was working on UI glitches, it turned out that all the
+fixes involved 100% pure code that has nothing to do with UI. The UI was
+actually just exposing bugs.
+
+For example, closing a running transfer
+had a bug that weirdly reordered the queue. This turned out to be
+due to the transfer queue actually maintaining two versions of the queue,
+one in a TChan and one a list. Some unknown bugs caused these to get out of
+sync. That was fixed very handily by deleting the TChan, so there's only
+one copy of the data.
+
+I had only been using that TChan because I wanted a way to block while the
+queue was empty. But now that I'm more comfortable with STM, I know how
+to do that easily using a list:
+
+[[!format haskell """
+	getQueuedTransfer q = atomically $ do
+		sz <- readTVar (queuesize q)
+		if sz < 1
+			then retry -- blocks until size changes
+			else ...
+"""]]
+
+Ah, the times before [STM](http://en.wikipedia.org/wiki/Software_transactional_memory)
+were dark times indeed. I'm writing more and more STM code lately, building
+up more and more complicated and useful transactions. If you use threads and
+don't know about STM, it's a great thing to learn, to get out of the dark ages
+of dealing with priority inversions, deadlocks, and races.
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_10_2fac85357ac8feccff82beabd3791439._comment b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_10_2fac85357ac8feccff82beabd3791439._comment
new file mode 100644
index 0000000000..1b4833b125
--- /dev/null
+++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_10_2fac85357ac8feccff82beabd3791439._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="comment 10"
+ date="2012-09-09T16:58:55Z"
+ content="""
+That's great news.
+
+I suggest we disregard this comment thread, i'll just follow the proper bug report(which i guess i should have made to begin with).
+
+Thanks for your good work.
+
+"""]]
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_11_e9e496005fd1bf5a10c9e286b83e51fa._comment b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_11_e9e496005fd1bf5a10c9e286b83e51fa._comment
new file mode 100644
index 0000000000..1477a71db7
--- /dev/null
+++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_11_e9e496005fd1bf5a10c9e286b83e51fa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.30"
+ subject="comment 11"
+ date="2012-09-09T17:12:55Z"
+ content="""
+That bug should be fixed now.
+"""]]
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_1_913e6ae7c8f7db90b9767ec35fc84205._comment b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_1_913e6ae7c8f7db90b9767ec35fc84205._comment
new file mode 100644
index 0000000000..f797a0249b
--- /dev/null
+++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_1_913e6ae7c8f7db90b9767ec35fc84205._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="gpg encryption on ssh remotes"
+ date="2012-09-01T08:25:17Z"
+ content="""
+I've been playing around with the Assistant in the last few days.
+
+And besides for gpg encryption it works great.
+
+But whenever i set up a special remote(done it manually since you hadn't made this yet) it will break, bad.
+
+Some files will transfer fine, but at some point it will still(the stdout from git-annex webapp shows gpg being stupid).
+
+I get a huge amount of [git] <defunct> in my ps auxw. And two git-annex transferkey <key> --to host --file <some file>
+
+It seems to consistently fall on a 9mb file i have. I have found no way to recover from this(killing and restarting git-annex will say 'transfer already in progress'. Deleting the file was to no avail, it still tries to transfer).
+
+I have done a lot of testing and i've only seen this on special remotes when gpg encryption is enabled(i haven't tried encryption=shared)
+
+Besides for this issue, the Assistant is looking great.
+
+"""]]
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_2_634ca3c236e2062289e7df5f0d77a3c5._comment b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_2_634ca3c236e2062289e7df5f0d77a3c5._comment
new file mode 100644
index 0000000000..84e780b4bf
--- /dev/null
+++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_2_634ca3c236e2062289e7df5f0d77a3c5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.236"
+ subject="comment 2"
+ date="2012-09-02T21:40:17Z"
+ content="""
+@tobias, when you say \"gpg being stupid\", what exactly do you see at that point? Please paste it.
+"""]]
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_3_e365bbcbb7f66ce2b35fcd5b969ab315._comment b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_3_e365bbcbb7f66ce2b35fcd5b969ab315._comment
new file mode 100644
index 0000000000..741cdfc63e
--- /dev/null
+++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_3_e365bbcbb7f66ce2b35fcd5b969ab315._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="comment 3"
+ date="2012-09-02T23:49:17Z"
+ content="""
+Updated to the latest trunk, and did some more testing.
+
+I'll retract the \"gpg being stupid\" comment. it just gives the normal \"(gpg)\".
+
+There really isn't anything interesting in the stdout(but a lot of defunct git's in ps auxw), but i still can't get any files larger than ~710kbyte to transfer. They just stall.
+
+http://pastebin.com/ZA8dzxZD <- stdout/stderr
+http://pastebin.com/f1J1T79E <- ps auxw | grep git
+
+"""]]
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_4_b15499722a655489f9ea60ff9d4c47c6._comment b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_4_b15499722a655489f9ea60ff9d4c47c6._comment
new file mode 100644
index 0000000000..d78f3d268d
--- /dev/null
+++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_4_b15499722a655489f9ea60ff9d4c47c6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="comment 4"
+ date="2012-09-03T08:12:39Z"
+ content="""
+So, i've let the assistant run since i posted my last message, while i slept.
+
+But 8 hours later, it still hasn't made any progress. :(
+
+Again, only see this with gpg encryption enabled, and on files >700kbyte.
+"""]]
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_5_8ea48276f060e75d9f40617d2a1ccd08._comment b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_5_8ea48276f060e75d9f40617d2a1ccd08._comment
new file mode 100644
index 0000000000..0cbf81e413
--- /dev/null
+++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_5_8ea48276f060e75d9f40617d2a1ccd08._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.236"
+ subject="comment 5"
+ date="2012-09-04T20:06:17Z"
+ content="""
+Can you try running the transfer command by hand? The command line is:
+
+`/home/alansmithee/bin/git-annex transferkey SHA256-s806100--ad2c33a88a665c56d97393fad99b37529afc5947694eab7d9c27f4d178d182f4 --to host1free --file 787kbyte.txt`
+
+Paste me the full output until it seems to hang (if it hangs this way), and if it does hang you may also need to strace it and send me that..
+"""]]
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_6_9b8bf7e9fa715977fbeb98087deefd1a._comment b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_6_9b8bf7e9fa715977fbeb98087deefd1a._comment
new file mode 100644
index 0000000000..c5c2aaa8a4
--- /dev/null
+++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_6_9b8bf7e9fa715977fbeb98087deefd1a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="comment 6"
+ date="2012-09-04T21:57:05Z"
+ content="""
+No joy.
+
+strace: http://pastebin.com/UYSrZZAg
+"""]]
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_7_42e09eacdc10c7cf579bfc6470b5117c._comment b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_7_42e09eacdc10c7cf579bfc6470b5117c._comment
new file mode 100644
index 0000000000..5a8e2f9f8d
--- /dev/null
+++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_7_42e09eacdc10c7cf579bfc6470b5117c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.236"
+ subject="comment 7"
+ date="2012-09-06T16:20:49Z"
+ content="""
+From the strace, I can see it reading the file and feeding it to gpg. Either gpg is stalling after a while, or perhaps it is not reading the output back from gpg. What type of special remote is this (rsync/directory/S3)? Can you provide `strace -f` output for the same command you straced before?
+"""]]
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_8_6c02f31063b3d399d1b4f823bd6543ce._comment b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_8_6c02f31063b3d399d1b4f823bd6543ce._comment
new file mode 100644
index 0000000000..391ec44379
--- /dev/null
+++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_8_6c02f31063b3d399d1b4f823bd6543ce._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="comment 8"
+ date="2012-09-06T18:41:47Z"
+ content="""
+I've tried with rsync and directory(real, mountpoint, and fuse mount), no S3. Same result on all of them.
+
+Here is an strace -f http://pastebin.com/YqCbi7Ue
+
+Funny thing is that now i hitting the failure on smaller files(<500kbyte).
+
+I even did a restart because of that. To see if a clean boot would increate it back to the ~700kbyte, but it made no difference.
+
+The annex hasn't been idle since last time, but i haven't done anything major in it. In total the annex is 204mb(up from 185mb at the time of my first post about this)
+"""]]
diff --git a/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_9_dd0447cb3b39d3a8c1a7cc00f17d8bc2._comment b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_9_dd0447cb3b39d3a8c1a7cc00f17d8bc2._comment
new file mode 100644
index 0000000000..cd879bcfd4
--- /dev/null
+++ b/doc/design/assistant/blog/day_70__adding_ssh_remotes/comment_9_dd0447cb3b39d3a8c1a7cc00f17d8bc2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.30"
+ subject="comment 9"
+ date="2012-09-09T16:52:33Z"
+ content="""
+Someone else reported what looks like the same problem, here: [[bugs/transferkey_fails_due_to_gpg]]
+
+I'mm be following up to that bug report. In fact, I think I just managed to replicate the bug!
+"""]]
diff --git a/doc/design/assistant/blog/day_71__ssh_probing.mdwn b/doc/design/assistant/blog/day_71__ssh_probing.mdwn
new file mode 100644
index 0000000000..ac5a473800
--- /dev/null
+++ b/doc/design/assistant/blog/day_71__ssh_probing.mdwn
@@ -0,0 +1,26 @@
+Got ssh probing implemented. It checks if it can connect to the server, and
+probes the server to see how it should be used. 
+
+Turned out to need two ssh probes. The first uses the system's existing ssh
+configuration, but disables password prompts. If that's able to get in
+without prompting for a password, then the user must have set that up,
+and doesn't want to be bothered with password prompts, and it'll respect
+that configuration.
+
+Otherwise, it sets up a per-host ssh key, and configures a hostname alias
+in `~/.ssh/config` to use that key, and probes using that. 
+Configuring ssh this way is nice because it avoids changing ssh's
+behavior except when git-annex uses it, and it does not open up the server
+to arbitrary commands being run without password.
+
+--
+
+Next up will be creating the repositories. When there's a per-host key,
+this will also involve setting up `authorized_keys`, locking down the ssh
+key to only allow running git-annex-shell or rsync.
+
+I decided to keep that separate from the ssh probing, even though it means
+the user will be prompted twice for their ssh password. It's cleaner and
+allows the probing to do other checks -- maybe it'll later check the amount
+of free disk space -- and the user should be able to decide after the probe
+whether or not to proceed with making the repository.
diff --git a/doc/design/assistant/blog/day_71__ssh_probing/comment_1_56a0c29f7454cfca5cc30b2849e6e942._comment b/doc/design/assistant/blog/day_71__ssh_probing/comment_1_56a0c29f7454cfca5cc30b2849e6e942._comment
new file mode 100644
index 0000000000..606037372d
--- /dev/null
+++ b/doc/design/assistant/blog/day_71__ssh_probing/comment_1_56a0c29f7454cfca5cc30b2849e6e942._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmRFKwny4rArBaz-36xTcsJYqKIgdDaw5Q"
+ nickname="Andrew"
+ subject="comment 1"
+ date="2013-01-19T07:23:38Z"
+ content="""
+I'm finding a few circumstances where the per-host key never gets setup. Is there a way to force this probing or key setup to happen?
+"""]]
diff --git a/doc/design/assistant/blog/day_71__ssh_probing/comment_2_f3bd3e366c92c833c7e217da125481b8._comment b/doc/design/assistant/blog/day_71__ssh_probing/comment_2_f3bd3e366c92c833c7e217da125481b8._comment
new file mode 100644
index 0000000000..3ce31969db
--- /dev/null
+++ b/doc/design/assistant/blog/day_71__ssh_probing/comment_2_f3bd3e366c92c833c7e217da125481b8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.194"
+ subject="comment 2"
+ date="2013-01-19T16:09:15Z"
+ content="""
+It'd be best to file a bug report with details.
+"""]]
diff --git a/doc/design/assistant/blog/day_72__remote_ssh_server_configurator_finished.mdwn b/doc/design/assistant/blog/day_72__remote_ssh_server_configurator_finished.mdwn
new file mode 100644
index 0000000000..4dfc297b2c
--- /dev/null
+++ b/doc/design/assistant/blog/day_72__remote_ssh_server_configurator_finished.mdwn
@@ -0,0 +1,34 @@
+Decided to only make bare git repos on remote ssh servers. This
+configurator is aimed at using a server somewhere, which is probably not
+going to be running the assistant. So it doesn't need a non-bare repo, and
+there's nothing to keep the checked out branch in a non-bare repo
+up-to-date on such a server, anyway. For non-bare repos on locally
+accessible boxes, the [[pairing]] configurator will be the thing
+to use, instead of this one.
+
+Note: While the remote ssh configurator works great, and you could even have the
+assistant running on multiple computers and use it to point them all at the
+same repo on a server, the assistant does not yet support keeping such a
+network topology in sync. That needs some of the ideas in [[cloud]] to
+happen, so clients can somehow inform each other when there are changes.
+Until that happens, the assistant polls only every 30 minutes, so it'll
+keep in sync with a 30 minute delay.
+
+---
+
+This configurator can also set up encryped rsync special remotes. Currently
+it always encrypts them, using the shared cipher mode of git-annex's
+encryption. That avoids issues with gpg key generation and distribution,
+and was easy to get working.
+
+---
+
+I feel I'm in a good place now WRT adding repository configurator wizards
+to the webapp. This one took about 2.5 days, and involved laying some
+groundwork that will be useful for other repository configurators. And it
+was probably one of the more complex ones. 
+
+Now I should be able to crank out configurators for things like Amazon S3,
+Bup, Rsync.net, etc fairly quickly. First, I need to do a beta release of
+the assistant, and start getting feedback from my backers to prioritize
+what to work on.
diff --git a/doc/design/assistant/blog/day_73__rsync.net_configurator.mdwn b/doc/design/assistant/blog/day_73__rsync.net_configurator.mdwn
new file mode 100644
index 0000000000..9000636a73
--- /dev/null
+++ b/doc/design/assistant/blog/day_73__rsync.net_configurator.mdwn
@@ -0,0 +1,17 @@
+Now finished building a special configurator for rsync.net. While
+this is just a rsync remote to git-annex, there are some tricky bits to
+setting up the ssh key using rsync.net's restricted shell. The configurator
+automates that nicely. It took about 3 hours of work, and 49 lines of
+rsync.net specific code to build this.
+
+[[!img /assistant/rsync.net.png]]
+
+Thanks to rsync.net who heard of my Kickstarter and gave me a really
+nice free lifetime account. BTW guys, I wish your restricted shell
+supported '&&' in between commands, and returned a nonzero exit status when
+the command fails. This would make my error handling work better.
+
+I've also reworked the repository management page. Nice to see those
+configurators start to fill in!
+
+[[!img /assistant/repositories.png]]
diff --git a/doc/design/assistant/blog/day_74__bits_and_peices.mdwn b/doc/design/assistant/blog/day_74__bits_and_peices.mdwn
new file mode 100644
index 0000000000..c3a71d7964
--- /dev/null
+++ b/doc/design/assistant/blog/day_74__bits_and_peices.mdwn
@@ -0,0 +1,7 @@
+* On OSX, install a launcher plist file, to run the assistant on login,
+  and a `git-annex-webapp.command` file in the desktop. This is not tested
+  yet.
+* Made the webapp display alerts when the inotify/kqueue layer has a
+  warning message.
+* Handle any crashes of each of the 15 or so named threads by displaying
+  an alert. (Of course, this should never happen.)
diff --git a/doc/design/assistant/blog/day_75__zeromq_and_pairing.mdwn b/doc/design/assistant/blog/day_75__zeromq_and_pairing.mdwn
new file mode 100644
index 0000000000..9f2ba48169
--- /dev/null
+++ b/doc/design/assistant/blog/day_75__zeromq_and_pairing.mdwn
@@ -0,0 +1,50 @@
+Started reading about ZeroMQ with the hope that it could do some firewall
+traversal thing, to connect mutually-unroutable nodes. Well, it could, but
+it'd need a proxy to run on a server both can contact, and lots of
+users won't have a server to run that on. The XMPP approach used by
+dvcs-autosync is looking like the likeliest way for git-annex to handle
+that use case.
+
+However, ZeroMQ did point in promising directions to handle another use
+case I need to support: Local [[pairing]]. In fairly short order, I got
+ZeroMQ working over IP Multicast (PGM), with multiple publishers sending
+messages that were all seen by multiple clients on the LAN (actually the
+WAN; works over OpenVPN too). I had been thinking about using
+Avahi/ZeroConf for discovery of systems to pair with, but ZeroMQ is rather
+more portable and easy to work with.
+
+Unfortunatly, I wasn't able to get ZeroMQ to behave reliably enough.
+It seems to have some timeout issues the way I'm trying to use it,
+or perhaps its haskell bindings are buggy? Anyway, it's really overkill
+to use PGM when all I need for git-annex pairing discovery is lossy
+UDP Multicast. Haskell has a simple `network-multicast` library for that,
+and it works great.
+
+With discovery out of the way (theoretically), the hard part about
+[[pairing]] is going to be verifying that the desired repository is being
+paired with, and not some imposter. My plan to deal with this involves a
+shared secret, that can be communicated out of band, and HMAC. The webapp
+will prompt both parties to enter the same agreed upon secret (which could
+be any phrase, ideally with 64 bytes of entropy), and will then use it as
+the key for HMAC on the ssh public key. The digest will be sent over the
+wire, along with the ssh public key, and the other side can use the shared
+secret to verifiy the key is correct.
+
+The other hard part about [[pairing]] will be finding the best address to
+use for git, etc to connect to the other host. If MDNS is available, it's
+ideal, but if not the pair may have to rely on local DNS, or even
+hard-coded IPs, which will be much less robust. Or, the assistant could
+broadcast queries for a peer's current IP address itself, as a poor man's
+MDNS.
+
+All right then! That looks like a good week's worth of work to embark on.
+
+---
+
+Slight detour to package the haskell network-multicast library and upload
+to Debian unstable.
+
+Roughed out a data type that models the whole pairing conversation,
+and can be serialized to implement it. And a state machine to run
+that conversation. Not yet hooked up to any transport such as multicast
+UDP.
diff --git a/doc/design/assistant/blog/day_76__pairing.mdwn b/doc/design/assistant/blog/day_76__pairing.mdwn
new file mode 100644
index 0000000000..0ebf55090f
--- /dev/null
+++ b/doc/design/assistant/blog/day_76__pairing.mdwn
@@ -0,0 +1,16 @@
+About half way done with implementing [[pairing]]. The webapp's interface
+to prompt for a secret and start pairing is done; the protocol is
+implemented; broadcasting of pairing requests is working; added Yet Another
+Thread to listen for incoming pairing traffic.
+
+Very happy with how this came together; starting with defining the protocol
+with data types let me rapidly iterate until I had designed a simple, clean,
+robust protocol. The implementation works well too; it's even possible to
+start pairing, and only then bring up the network interface to the machine
+you intended to pair with, and it'll detect the new interface and start
+sending requests to it.
+
+Next, I need to make alerts have a button that performs a stored
+IO action. So that the incoming pair request alert can have a button to
+respond to the pair request. And then I need to write the code to actually
+perform the pairing, including ssh key setup.
diff --git a/doc/design/assistant/blog/day_76__pairing/comment_1_09665f269343422cd18051fad1a8c19e._comment b/doc/design/assistant/blog/day_76__pairing/comment_1_09665f269343422cd18051fad1a8c19e._comment
new file mode 100644
index 0000000000..16956ead21
--- /dev/null
+++ b/doc/design/assistant/blog/day_76__pairing/comment_1_09665f269343422cd18051fad1a8c19e._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmubB1Sj2rwFoVdZYvGV0ACaQUJQyiJXJI"
+ nickname="Paul"
+ subject="Hogging memory"
+ date="2012-09-09T15:51:40Z"
+ content="""
+How do you prefer bugs to be reported?
+
+I'm having a problem where git-annex (from git, 1e41c0d85ecc24e8656bff79b2fba46c3663a054) is taking over 20GB of RAM after adding a single file.
+
+To reproduce:
+
+1. Create a new annex (I used the web app, created an annex at ~/annex)
+2. Add box.com as a remote, using encryption (followed <http://git-annex.branchable.com/tips/using_box.com_as_a_special_remote/>, basically `cd ~/annex; git annex initremote box.com type=directory directory=/media/box.com encryption=$GPGID`)
+3. copied a file into the annex (ok, I admit, the file was a bit large, 350MB, but still)
+4. refreshed the web app, nothing happened
+5. closed the web app
+6. started git annex assistant inside ~/annex
+7. git annex webapp
+8. noted that git annex noticed the file, and started transferring
+9. wait
+10. memory usage for the git-annex process goes beyond 21GB RAM
+11. oomkiller kills git-annex
+"""]]
diff --git a/doc/design/assistant/blog/day_76__pairing/comment_2_8e1b2233579bc26bfd758bbf6b3bdc07._comment b/doc/design/assistant/blog/day_76__pairing/comment_2_8e1b2233579bc26bfd758bbf6b3bdc07._comment
new file mode 100644
index 0000000000..a2e64671fe
--- /dev/null
+++ b/doc/design/assistant/blog/day_76__pairing/comment_2_8e1b2233579bc26bfd758bbf6b3bdc07._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.30"
+ subject="comment 2"
+ date="2012-09-09T16:25:52Z"
+ content="""
+The [[bugs]] page is the place to put bug reports like this so I won't forget them.
+
+This should certainly not be happening. There are actually two git-annex processes running in the situation you describe; I'd be most curious to know whether the `git annex transfer` process was the one that blew up, or if the `git annex assistant` blew up. Also, it's not clear to me if you enabled the chunksize parameter when setting up the special remote, which could well be a significant detail.
+"""]]
diff --git a/doc/design/assistant/blog/day_76__pairing/comment_3_a8b6a8432da20c468c633da8e7cbc2f3._comment b/doc/design/assistant/blog/day_76__pairing/comment_3_a8b6a8432da20c468c633da8e7cbc2f3._comment
new file mode 100644
index 0000000000..28439b34fc
--- /dev/null
+++ b/doc/design/assistant/blog/day_76__pairing/comment_3_a8b6a8432da20c468c633da8e7cbc2f3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmubB1Sj2rwFoVdZYvGV0ACaQUJQyiJXJI"
+ nickname="Paul"
+ subject="comment 3"
+ date="2012-09-09T17:34:07Z"
+ content="""
+I'm almost certain that I specified chunksize like in the tip. How do I check?
+"""]]
diff --git a/doc/design/assistant/blog/day_76__pairing/comment_4_36a428a2e1803f4391b821d1892f0cd7._comment b/doc/design/assistant/blog/day_76__pairing/comment_4_36a428a2e1803f4391b821d1892f0cd7._comment
new file mode 100644
index 0000000000..e462402652
--- /dev/null
+++ b/doc/design/assistant/blog/day_76__pairing/comment_4_36a428a2e1803f4391b821d1892f0cd7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.30"
+ subject="comment 4"
+ date="2012-09-09T18:00:48Z"
+ content="""
+You can see the full configuration with: git show git-annex:remote.log
+
+(You probably do not want to paste the cipher= part of that here, although it *is* encrypted with your gpg key, unless you are using the shared encryption mode.)
+"""]]
diff --git a/doc/design/assistant/blog/day_76__pairing/comment_5_11f332fe2050d8c1416e71f9e85ba280._comment b/doc/design/assistant/blog/day_76__pairing/comment_5_11f332fe2050d8c1416e71f9e85ba280._comment
new file mode 100644
index 0000000000..5c93d3d3e8
--- /dev/null
+++ b/doc/design/assistant/blog/day_76__pairing/comment_5_11f332fe2050d8c1416e71f9e85ba280._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmubB1Sj2rwFoVdZYvGV0ACaQUJQyiJXJI"
+ nickname="Paul"
+ subject="comment 5"
+ date="2012-09-10T14:54:17Z"
+ content="""
+chunksize=2m was defined. I tried again, and the transfers again didn't seem to start. Then I did `killall git-annex`, cleaned the files from the box.com account, and tried again. This time it seems to be working, but the webapp isn't showing progress. Memory usage also stays reasonable, and doesn't seem to grow. Maybe it was just bad handling of unexpected repository state?
+"""]]
diff --git a/doc/design/assistant/blog/day_76__pairing/comment_6_973aeb656b78eca97474ea1a3f5b57b7._comment b/doc/design/assistant/blog/day_76__pairing/comment_6_973aeb656b78eca97474ea1a3f5b57b7._comment
new file mode 100644
index 0000000000..120a87845e
--- /dev/null
+++ b/doc/design/assistant/blog/day_76__pairing/comment_6_973aeb656b78eca97474ea1a3f5b57b7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.30"
+ subject="comment 6"
+ date="2012-09-10T17:31:20Z"
+ content="""
+Re transfer progress not being shown, that's expected as upload progress displays are not yet implemented in the webapp.
+
+I can't think of a way git-annex would care what was in your box.com repo. It just makes directories as needed, and will overwrite existing files in the rare case they already exist. And ignore any non-git-annex files.
+
+Are you sure it was git-annex's memory use blowing up, and not the memory use of the davfs2 daemon?
+"""]]
diff --git a/doc/design/assistant/blog/day_76__pairing/comment_7_03d2b3343f34377a4d6171e06b7609f6._comment b/doc/design/assistant/blog/day_76__pairing/comment_7_03d2b3343f34377a4d6171e06b7609f6._comment
new file mode 100644
index 0000000000..5aea18576c
--- /dev/null
+++ b/doc/design/assistant/blog/day_76__pairing/comment_7_03d2b3343f34377a4d6171e06b7609f6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmubB1Sj2rwFoVdZYvGV0ACaQUJQyiJXJI"
+ nickname="Paul"
+ subject="comment 7"
+ date="2012-09-10T17:35:48Z"
+ content="""
+Positive. I was grepping for git-annex from ps for the mem usage.
+"""]]
diff --git a/doc/design/assistant/blog/day_77_alert_buttons.mdwn b/doc/design/assistant/blog/day_77_alert_buttons.mdwn
new file mode 100644
index 0000000000..2c05b495b5
--- /dev/null
+++ b/doc/design/assistant/blog/day_77_alert_buttons.mdwn
@@ -0,0 +1,21 @@
+Alerts can now have buttons, that go to some url when clicked. Yay.
+
+Implementing that was a PITA, because Yesod really only wants its type-safe
+urls to be rendered from within its Handler monad. Which most things that
+create alerts are not. I managed to work around Yesod's insistence on this
+only by using a MVar to store the pure function that Yesod uses internally.
+That function can only be obtained once the webapp is running.
+
+----
+
+Fixed a nasty bug where using gpg would cause hangs. I introduced this back
+when I was reworking all the code in git-annex that runs processes, so it
+would work with threading. In the process a place that had forked a process
+to feed input to gpg was lost. Fixed it by spawning a thread to feed gpg.
+Luckily I have never released a version of git-annex with that bug, but
+the many users who are building from the master branch should update.
+
+----
+
+Made alerts be displayed while pairing is going on, with buttons to cancel
+pairing or respond to a pairing request.
diff --git a/doc/design/assistant/blog/day_78__pairing_continued.mdwn b/doc/design/assistant/blog/day_78__pairing_continued.mdwn
new file mode 100644
index 0000000000..74f5107150
--- /dev/null
+++ b/doc/design/assistant/blog/day_78__pairing_continued.mdwn
@@ -0,0 +1,8 @@
+Worked on [[pairing]] all day. It's complicated and I was close to being in
+the weeds at times. I think it probably works now, but I have not tested it
+at all. Tomorrow, testing, and cleaning up known problems.
+
+----
+
+Also ordered 1.5 terabytes of USB keys and a thousand git-annex stickers
+today.
diff --git a/doc/design/assistant/blog/day_79__pairing_finished.mdwn b/doc/design/assistant/blog/day_79__pairing_finished.mdwn
new file mode 100644
index 0000000000..ca4bbc1257
--- /dev/null
+++ b/doc/design/assistant/blog/day_79__pairing_finished.mdwn
@@ -0,0 +1,33 @@
+Tons of pairing work, which culminated today in pairing fully working for
+the very first time. And it works great! Type something like "my
+hovercraft is full of eels" into two git annex webapps on the same LAN
+and the two will find each other, automatically set up ssh keys, and sync
+up, like magic. Magic based on math.
+
+* Revert changes made to `authorized_keys` when the user cancels
+  a pairing response. Which could happen if the machine that sent the
+  pairing request originally is no longer on the network.
+* Some fixes to handle lossy UDP better. Particularly tricky at the end
+  of the conversation -- how do both sides reliably know when a
+  conversation is over when it's over a lossy wire? My solution is just
+  to remember some conversatons we think are over, and keep saying
+  "this conversation is over" if we see messages in that conversation.
+  Works.
+* Added a UUID that must be the same in related pairing messages.
+  This has a nice security feature: It allows detection of brute-force
+  attacks to guess the shared secret, after the first wrong guess! 
+  In which case the pairing is canceled and a warning printed.
+* That led to a thorough security overview, which I've added to
+  the [[pairing]] page. Added some guards against unusual attacks,
+  like console poisioning attacks. I feel happy with the security
+  of pairing now, with the caveats that only I have reviewed it (and
+  reviewing your own security designs is never ideal), and that the
+  out-of-band shared secret communication between users is only as good
+  as they make it.
+* Found [a bug](https://github.com/yesodweb/yesod/issues/421) 
+  in Yesod's type safe urls. At least, I think it's a bug. Worked around it.
+* Got very stuck trying to close the sockets that are opened to send
+  multicast pairing messages. Nothing works, down to and including calling
+  C `close()`. At the moment I have a socket leak. :(
+  I need to understand the details of multicast sockets better to fix this.
+  Emailed the author of the library I'm using for help.
diff --git a/doc/design/assistant/blog/day_7__bugfixes.mdwn b/doc/design/assistant/blog/day_7__bugfixes.mdwn
new file mode 100644
index 0000000000..79f36fe98d
--- /dev/null
+++ b/doc/design/assistant/blog/day_7__bugfixes.mdwn
@@ -0,0 +1,45 @@
+Kickstarter is over. Yay!
+
+Today I worked on the bug where `git annex watch` turned regular files
+that were already checked into git into symlinks. So I made it check
+if a file is already in git before trying to add it to the annex.
+
+The tricky part was doing this check quickly. Unless I want to write my
+own git index parser (or use one from Hackage), this check requires running
+`git ls-files`, once per file to be added. That won't fly if a huge
+tree of files is being moved or unpacked into the watched directory.
+
+Instead, I made it only do the check during `git annex watch`'s initial
+scan of the tree. This should be OK, because once it's running, you
+won't be adding new  files to git anyway, since it'll automatically annex
+new files. This is good enough for now, but there are at least two problems
+with it:
+
+* Someone might `git merge` in a branch that has some regular files,
+  and it would add the merged in files to the annex.
+* Once `git annex watch` is running, if you modify a file that was
+  checked into git as a regular file, the new version will be added
+  to the annex.
+
+I'll probably come back to this issue, and may well find myself directly
+querying git's index.
+
+---
+
+I've started work to fix the memory leak I see when running `git annex
+watch` in a large repository (40 thousand files). As always with a Haskell
+memory leak, I crack open [Real World Haskell's chapter on profiling](http://book.realworldhaskell.org/read/profiling-and-optimization.html).
+
+Eventually this yields a nice graph of the problem:
+
+[[!img profile.png alt="memory profile"]]
+
+So, looks like a few minor memory leaks, and one huge leak. Stared
+at this for a while and trying a few things, and got a much better result:
+
+[[!img profile2.png alt="memory profile"]]
+
+I may come back later and try to improve this further, but it's not bad memory
+usage. But, it's still rather slow to start up in such a large repository,
+and its initial scan is still doing too much work. I need to optimize
+more..
diff --git a/doc/design/assistant/blog/day_7__bugfixes/profile.png b/doc/design/assistant/blog/day_7__bugfixes/profile.png
new file mode 100644
index 0000000000000000000000000000000000000000..702af1ca00367f5e4b6b8242b195ee3531b193f7
GIT binary patch
literal 47098
zcmaI82|QHq+dn>1c2P-VPYF{Z+1DwhLUzK)lF2fL(Af7PW&gy4>}1F?_9bLXQDiJr
zV-HDV-<K@I{~mpw=lOk~-|zK5y?V`<<(&K6=RVhUy_ajk^>l8tGI29OAP`oKJ2wp=
zkfY$~5mSaE-~scP)*U?1*=XIq2|1wt%WTMt2d^-?-Z8^~$2*7rZ+$_lLLk8qjhokv
zyocr~x=~^pfdbwLtb8F##>h01)3GYVk##uR^!Y`?@_5-me<%Wi9@USu*mxGK5PG6n
zg~3%|`5cGDqKJ$Krir60DRRUGVZFs3rXo{&%>}CPoGX(lQu^A_6-~9W4`CntI^nF1
z(phKkJ%AM;*_t%be)|&V&q<xXdbLr2z3VO;1|!w&`x-8F@OpbbvO7Zxj1dBP$KsM&
zM|1epRT+Bt2)WPB^7n~21Kr;zXMUa084bp)66%*S>KLi7xiULFmSUw1rrd$)j#8%v
zGHsxlR>x>hOB>vPzgK7|ceqnasgy3A(a?$~GSrViAZL!!9zF&$KmB{q=3^~~FF?kh
zTAx_9z@dC+g{d#x=XC0Ld<F^`q1_W<0DrqmCj~Z~&w(6%>;Eyp|Jkp4Gh~^SoGKY6
z$=SY=KTN$|Y{zsVI@Yo&DEtf>8CA9U?Xs_E{kr&j9(qH~F7n!-ljkh|Sc;HFNBPJc
zwp`4<B&D0|ldeR5`(cowEeTUB*17GUF2wk1UF65CW#H4p;dmc$J)*A9AUHi&F7`&W
zpkVe}v@iSZxio`|G06G$q1xfLq;fF@vN71EXm^A(3JM~!KPMK=)j1Du_-bPg5a^)?
zcvQ0C7IiuoxzZuZ@@Qv!;i`g*aLB;adic!uGT3I>q-y)*6W_YdyQNj0C9+E&6#8p%
zq@nQiFoEdN_<goVMPV~&?QcCxC6adSK3msQ*W~p$)Op*#Rf|UKt?bu058IjjmJ0eQ
zUtFLG^Vs5#ro79WcnPMYxwQo{PQ!)djQnI%meftQHQUKKo^kc1P&lcscuq(|SSJq~
zbw%)@Y|3|!22-(w&MBL+<&svY5&?=KT+q0h(Vf^i<*({8oFJKtP42Q&^}gKsxc0th
za@l?HHRY{ib``H<nJKqJv=_Dr&>O7h_v_ph1Ejq#<!&?U%SJXaZAeGi*jJbhS4Vz&
zijeo#6%KTzaJLnI{}RF2#J9_}opL3k+smivON`)EvVZ&V03#8Ht%vJ#?J>qs-ii3$
ztVz83Qt_Y*ET-lF>Y3nB-0dqH)UAqCCs3x}rmoL1x8b|IE*eo>Qc^SQtk2<L@f_3Y
zJY0OQaKW?QvgDOP<7(L?Dp`>%o5K1%fm};MXlhtVwN;YbALVhm@jk!Axp&a_QK5^A
zO}1)G$!dOQM=|1@z;BYr!mzUU8*n1dHRf$l5BrM2`&L$3FrqZ;jp1^!3b8lJuUq^c
z&#{RYJ=j4Yci`u_BmP7_Cb%>()<<FAt{8NfYuTCQViDqrwq||ZiTuLzf6hY>&nxeh
ztp;_y^lvok3W8NJeh&&!=D=aAstYa>6v%tQ>+Y}%X$0t{h^Gzdp675mypJ*}Roq6P
zZ>lWu_pl;2UJG&{POD#MzP6^!c19%h%&HkLVot2{t<H{BU5C3Ny$gdyWSF#B!ZYVa
zW_*=om~V%IOY$v-iM-7jgu4DseQ8hKN0gRr?ne!zkGj=sQrQ)I>TH%W*W;%x<Alr-
zY|T99!i|mfZx2=D^4NXSm(uHq2aGy<?_8W2jSV=SVNX(T?qI*?>dkD=?Aim4wBa=l
zDlOw1bB`q(8*lfN3eZJ=>Ii9vEzf?;<@llhD_Mw9g>^cENBxBM9mAv)+rh`RIWs}9
z3m&d@`Hdk)uS!U8u6HtvOC!8(rew?QI0TyD<6RSQ(w~e#Zv7$&q?SyO(9ttn{R(G(
zq&C=%DZz_em#@9nSM3c-#>S<eh9a>B&chdRvMJgk;cpKFX02m|14mB5Njk=A42Lmp
zk&g}%`;7fV`xu9zL8|ukO~<NPd-75-{1uP-%h>xcj`XC(R|b7Qzsbi?yw85UJXn@r
zPkuAzi%}fYf!0qCsMK~A7twpU-bTz_S!;Lk)2!7kl6#!Fei^^94rxXVSL4}Q-iStI
z-_fkSFaF9Pjh=y$@u|h@jo~X@6{gM+TMcP2V=Nya<5{i*CG)NkglbfuXhUdUi<d$`
zGFx(h`}gY0eC~uPpC8iN7X7wn$AvRKx}}m8)DPx`i*n`@M^lD0V#`RseHxL)T0yt`
zf6_4EuPv+aF$c9TYS<fQhATBqR(Wm@dhDYg$Vp98F722G$);?V<e?j@Xb81+#jxq6
zkqnDK&XBgikq3Eng-rAb>(;+WXb@+cElcUfv-H>}rFf4IcYl2T$ZO>Ig&3q@Xvs(D
zq}*oKXVuQD+_Wrqr61kqQ`dT(In<qp!@Ai$QI6!WN@peL<c|}!OYX&2p`|gS@uNYm
z#QxR7t6(e|FqF`5-P-ooOXeA<o`g&fi(Oe_IXhunocTq&@5kdiZo8iru|}S*)YW9o
zLI+_}XV5o3?aWncDmHBmhdmY6+?711T_cgGHIx^3&)|nGv=o7_BvnpLf%PL(!m-xd
zneG4`NA~=ak<WUnu~lWVJ(+tmhE%=7(^tJf+wd@=nv`V$o0(`Eh}sxe8C;>43%ESQ
z6fWEHP)Y1DyPCB24dct4%=nD})@X;?H9Ru-yW=N?Ef?nWZZZNyl>k=*VhemxG-5h%
zvGFMv80F^G-JfgZyhp8r-sI7(-IO<ZD8;f?wyAhm!W&T#9{05iLyqm_5u=LOpFSqy
ztGq@;M2eOJT?p2OyA5lMvJ*_be&mvJEnWJhFL?Mn^Ahz!;kLkXqVdA2VWUjN0c1j}
zei66Y5I9o#;X(Z<zv~=`4%sZXtO8NINS2iaX%@(4X+I?R$5VF?5B2MJE&4qywziC(
zw9~=g8LrR<8_Izc&9B4)S!9R|7SQBSSJxLy)JkU9^2^Ssvv6hJ8wV#bj%o#w)Y$ly
zE!UKhvO^p5h{WEwj?J<KHRrl6U4eL;vb}U>yB#brvck8wL#-bMm_2Ez2^RA1?0?q|
zIgrusA{qX1xik6Zhu?&$ZvToml$&_}0OD#gcCf!C@`HM1A&@O*Oo>-0$64z0|7Sr!
zeFGf&`jx*={*Qw=(e9KERewh)k+VfR%I`9inMmS2hN}s+@-dOw47z0`l7}<?v>J!H
zq$y^&S`!B1hda(_xcb4Df&wVg)@<{VSxNsyO<Pj9jTfqvq^J=GlEUtSOq(mAeR0<C
zm5>I9`uce=ObLyX_>J+~eiXOCPfoIzB7O!2oldlc;i9rX3k*s|B*_O{VVQnAm%M0B
zom5vs-T}$$uJq$`7okqejTT`c6O7HY7dx+ZV+3z<s3Yd49;5K14M_$UHBJ(IIMh8X
z$Ucj@l5OB(?2sp#7L8KKK4uB}9KACdaiMwU=r<5@syN4E!bV}5sAoH!fai0i^I*Nb
zGc`8GyR0__{ECtUX)TD?E9zXEP6h+58Y-FOq5WxkNj_!Id`z<UbNE~9(w1FMu0@;8
zPvmah(XfgYP{V1#lu9U?ME7NNYeMa|zoqdjfmLzNNcotQ+`%$a({#J`lHy{A%)1BK
z({+T}Pd54->hjgOXZ;#1+ugoGD@fv;%m<e#=jSVPTA?>gQu+O#e_HIb-rP9_!OO^a
zAcDk46mBC^bTsf)>^~PzF(NmjED{4T8=dB8l)SXJ7QFx(iVS5>UDGL9Dnvsdx?h}R
z*Mc@Yr8iUji}pt|Aa~&<x$Udc^h?9<ksOkqJMPeNkC@ogJj{%_JPMqrS!BIS#4BD-
zqp6YX#F$R&so>`}Q4gY?9fXFmQ=ZJ5N`l-N;>L?1%v?{$=%CYVxdJ{aG&MFZ(i0z4
zsl5QPJVYOTne1Oju{Dda<z(foM}{<1JCoOZ;)E&&qtf9Cwjf*w(BQr~$ySj1-dMs5
zCsMWI9;#+YB!W_KF@xm~)0s&1I3WrnOTj;Z?3B(89#X#jeBFAdms@N9Qmmm*oqAN+
zpwqp689pm9&IzUC(UOh+-g~5C8pt&V*_3ArYWu@wW52xe<F)r~*z|vD!zU6J*wv%b
zRQc!}@cC)j)Ki>1P7|hguKarq{XDo9kJAP}KiR(GS-%11bd3r5X}ampat4h`FjDS7
zEtK8XOjyGp!S*17{?pcjo71VxNIm3Nf7OgGyU0%;+B5lW=e2(^Z$^%mwOE=Z6n=NC
zAH4@^4RF^OXm*%oA3>mDIQFNxta}nKrM1&ADP4B;qnzq5L18q60LxOJV|c-{Vz5Us
zlyDk{HA)|ScxhAQwD2s~dvU(l?CBlq1`4DDzYOupK_^gj;jpOWo#I|x&G3S6!#&Ms
zK?y(Qa|`6j?*55j7MjJ|0^`R<$0at8M-Y_a7nN?EK<4Q_r%A;`e10Rk`s7_zwV0OT
zz|4pLYYLE=B37wuGym+6Y#xl<m1<lU#b*fJJ}9LyrPmcx;C`TBkHIurmVhPvQ(lKC
zz4z)@>YK8C_dHKnwO>d>LBVvQnm&htCeDaMU5x>*sjs;a1lD6EsqlNmZ;^=X7n7zi
zb(1VE2EmVxRjU;zva&_rDsdRF+0C<%q&zL^+>MPZ-#wkp5fN;IUhMw2fJ)v&h|Zp+
z=uI11y$Tw6kL(ATYiPh_)i2+F`OI#kXVf`0;seMh$^$2Dw)nZaT)5o+pBTZGnCOuJ
z#e-n+R?AZ6p4RLj1!}=g+P>{^txPY$cD*E9G-B$pS-(e;kVxp;f{v1xxYNq}L|3WM
zTvU{#^YG5wI%jjjHoo^)%qLH$(te-K+Y5OwujzBF<GY2KT+Y^qzfx)H@u|Jv=Ekdj
zLPc@f3Tv|>q%n=U*3@jOg6x-R>*;e0svEnIA5X{KUUq;}PAb%VBW!hAd-$$2z$Kek
zH&ga3FOH#4e6SwgWM%v84(+M2EJ?#S5C8Vz-*+3Ea-p<DE2}wQq0@!%v*R9_qrt2v
z=W^}FdS{!G&*=Rr=|4c{yeK^=yx3XZWp|@q;J$^$hQO>3sIPSyXRJo?4Lo9=iFCWV
zyYvB^>{AEp%<JekNlBPMkj9#>4^>-;aUx%*xzh_HWK6pUJlYk@kwIR{Ztc_+6dFGE
zE34W$b`R~@E^6~t`~jrPw6|Y+lwbU`wNmI&Vsz>YCjRWsQjqre^^$W9ItYf<e38BV
z6SPW0^Up?$dKnM&^)+=(MQm5MKdE5-)jTfZ6zBeN@H%qf@y^lyZqooC4{!Qu&Nq%Q
z<`<h%{7xxBkIY9iqum_7{$p!Kluqf&6^&?#j!wh)q|0gFIK@UeLXC7L3@3gtA<CVi
zvNF`=M^@p9l9d7&@^4-0gnCW{osOjlFJbf634C+!&wy1QBK#p(C$B9*xMEc8Y1u8E
zo5$F`*$yy+s^{6g%)UEAZ-N-Xg*J6Af|8XxufhlQ`m2KIZWr3`E!HB?8JtV#T-U)8
zrpuiM4A=7vIU5gN6i>HrsgfIsX{B8upN^wltxTitL5OZJTZ?`p<AWmk7}QJ20Cdz!
zq%UkWcM>@)Fy+JFE_sZYc2grLk#3HwUR-8a006tVr-~Y{-TilH%CK>5BKx;zmb%3)
zXd%J>WZ11XMYIRTd-eD^eef4NI8$InZm7hFMGSnp32lB9M$a)~j;4$~s*7N2Y*%|~
z!L4xOw6b2}0|`^wWxc(7S0-9O09J)mCS$Te9;+06j#)Ip8qjE(f=DS%yw7n=efdF`
zHnB&QPI`3FtNH|}$0pZ~;H%a@cgy*?4)Bqb@689(ZK>=3inKNR9oY-XT&r)DIQh1~
zu?m4hDQ0w2F1$6Y{5{b0F{fz>+Cbw5qE=dWxmfpFVPRqE-2~gid=w`^x%D=%rPa3~
zm-Q~nu?dwtLlb=9(;IYgpKI|ZAaktsz<s3DR6&^n_c5UsF}LlnbN-1~=XA}AX_}Yx
z3I2K0R#Rv*^iA~S+bW}|FeZ+Zf12LcsJ=;m^y{Y4@->UF(Ft{HzkxY*YoaH-vnj3q
zpgT-;Rym&qz3CUY5hSo3>lyU?Ta5FMnw9|RPkmqR<t(hprD%JLZ=4fT@MeVDOAQo^
zYJZdRwg`$>nqqsmjf8jX&T>PVpF#Id-SFH#|NV7jZ54r-4Dx=Z{Q*7z{`IDj>lyD8
z1AGr4rO$V{A)>e_Nu@^B<uCp3&ksp7NlCJSLh1|yZLpFWQx9XPkN4Z{d)RpbwDra{
z@J4VwsQ-@gFP@lCAieLz_0MhGP)?*$JMXSRA<am#RlqUu2gK{S^EGN+2l*d%=qT*k
zmi5oezSLJCu}pLjFOO!e!#^N8$6(hEpZ)(bKak~zFq{sRNAea$C4aT6FswNOA)KUx
z*ylT&qc0=DwG+~alB8UvR+-8u9Zk1cSxB=Pz)gEtTeE%{WKl67cCc49PLfCRhrux0
z-(YL~E<jvgUxCQO+mdooq3npcY|(PD$ZUsY!NUPvqX)bHqCie1B5v#7980fLr@rjU
zzbrhy7H?~oPNo(L&j8E?Rg2K!H?9D_YwbLaLrrfJj*Ozls80%Tk9z8R<1A;7O^Y!K
z%9ATO<U6klmYz5YX+EZ}`GEN>L>@{9A-5yy?~BjXJpzPD^?mWqa%GP<;9K6My;6{o
zW8nR~Vl-^(`}fmR6c<?@97hA^;SsI555LL-VsipUJhb`nMTqAUn&#~+ImjQEG)x;*
z?68;)wy=h{1{M_bApk5w-c2V*emXK2Oal>TN#8lrJW<Lzz3oQ8_oMML4HT~iOXBtU
zqk!8))hUk`eV?8E#!4SN33!yfN@s8^Y}^mpW~jM%qOtKaX0Z2hgWB(oO>lZt!PZ4K
z2>Ced8aYR-lUm()fO;ty173hY5`TXZaRCG%#5DoTxrni`bIours<^ng`bn2v2v{)9
zQ+geuwoSXgy>v&}A@W*xXcXaQ3Dj?Z&9!*>==k0@k2JCZ9&$)JQbQp5w&oWFU7~xL
zDb_aJ1e{HCtHP>(d=*K-Ys)tkgFxdwOnDj<>`Q;OoauYwhgus=IqG_e1wx2r&n_tF
zva3Mgp~y~v3h!4t`$;rOf>FFL7i)!!10YS8OQ@ZCJh<&p>YA4$DXb9(D8Af$wywE4
z)y%Ys3mxV6#W+0xj?#{|-GBVxODQY8mAFP+x!BCao|A0nn*UC>TN4c>fwxB}xB*Ok
zu>*IAo#ymtbL1yAn8&Oq80)F)K@JYFDCFJYYUknO31XdBQ_V6&c@x|Lfd<OBjSUYD
zbyV`zworD`P=LUr=SVtkZztK54OZN@n*)66CmQt0rJa&(1qFzb{*<oYJ3G`mY<rRX
zqwE6YIrU;W;EB>{0Ft728fp=Ma|P59vMHGcG9JD?PT%yWCo!|1(9^G(U#1|8GZL{B
zxHJMoMY$19tG56O=|elkKvUoXQE3U4kY-1UmP92BYy3=X?HyC?2(KblJJ%!dd!3SR
zL>-fb_jd2pqjv3&KWL1`#E2)7Yh4`kSSO|w`F^F!X;0P<mRwe@8GG6CRRCucC*;0C
zxc$xS;GK11o38sQaS#p2?F!_{eX-8HC3%>wv2orbJ_v-jl^pa(jxB%@4`yLqM*H!u
ziwfG=ECCxg%gVW!7zHYy?7HGAlC9Y-{hQ{9cDK8e^u9OGhKfc!E%%zfLj_wskL3%V
z6Mm*%!u^zAbc)t)g+}13NTi``(NK1cxSphzSh+Z%iB!WWjW~Jojx&Qqe-ldWg=mCm
z!D9dK?tsZ?xg9=6b2U-_?(!m0CY+Ida%@MUt%d~MC~gHg>OXyuFkaRon+X=7h7|j{
z#63-oCOvsF#i|Re*XO;6vE-L=WFKSWkgR3=1qHG}N4eOfJP83NBvz`esEVVDc>ajs
z(P*Z7g{P0Lt1&Po1{ifgc_M8oW4DuY@>biRIPAfT*}Qyd$CJ^ViePwhFEBdMOZ~TA
z`tr6DY6EZYL`kYKa67T=ixpLwn3zbf4pPUJ6V@`-3@(08tLjelwGclT?w|qOLaw~h
zZ@wzzeesC6M{jjk!8GowDX76=HkRUv>vw}CZ^chf_${KiQ$}-2qMSLUWjR)u**?53
z7mfI!>0p~?6`*CN=su&vlWT@XIa@Z#3fN-^c}i+ISk3%xfBtqi-u4iQBiZ6hKmN4D
zK_U0K!9AvH(QlTp?UYeaz!|BYV4Jj04+)-JtLWE+5w<@LUsSq)uc|DQssEC?vNjhY
zDap#es_c>+c7!zOM1tLj<q$o(lzOLPlo&9h`_|*?5^7`gCM(vE15km5vD)1zJUF_;
z&kPdXHvr_*l9q-WR+8k77SYJVE9shpv|hvSjDuQaS3Q3H)G^WijGh`~?}4?3re;=?
z6+xlHBx|*Dmz|aIZLq<`ZVV#f+V!>Z#xrU!#5((=H-b0=xK#oQt2Qq^YBeUz+trQM
z*sEsnAa|UT-U(J}(NB@sNSq0&iwrO-ZZEjpd3DFFr{bB;mr))#>57%J>A`r_IOE|p
zXtF=JtkT)K4u>?W`)p5XZ49<PqTDrGWits%uyx}FXi-RmGx8a>&qYBq=-V{IY0=KO
zFjg#miV&kVnP_-S@FQTXNV3|e+E@Hlb>l)UU!8gsCm5R9;Pv5BoM=S3n7J6I`#BZF
zQcV^{q0RIVomw7YZ<l<<Rn(QSTiCQy7{WI*b`FPaQe;KO3C+ZEdAjVGw)$5+poH{4
z6|w$bsNau|SNmO{6?!3Y&k_HO9aOM}s@g<DnbUwB(n-#hW)&Jk7Ltd5<VAkJ_@hFt
z0pYyUUPaQ(e@-}^mHOIs<(gT7^h@2bzDHU59Qx(#4Qavq3<eB3%ybUoUrT6~B`B<H
zVFJ&BZp8}?KB_@3%+zEB)sFg+yK#<6d^7!5dS6<I_q*)f{DL`SXCT;^7Dm&|ucHKk
z`ah}d*VXt4?yGSP#UV&=@ptJi@sz!hH$oaQo2p`(M+@et@G>bN^m#B%^I|E(A1A=H
zoZ$!Y{7M_qee8W&@1I7|h-zoA!JXfY4)|Cf1+?=!T3GY5X0T7l_>3vOc(F{jNrK$V
z>r-$kBKwVsGsIiDl;M!H0?HHhQ{W!D{?8Fmg182%{`n!*rn(@Y+myktH#~dFiJRtM
z5=tIk(&)RL=E54Ve8Kz+C41Y5@2VXnc<mXL#R^{g2}PDP2Kvm}L7HnnP<J{0{+*#5
z1VZ5XFCp!JbSf}-Nb_r-&3XJAi_WBgu}l6UBm|jXsQrsVUe%&N{}YRjCCjr9LBQ5d
z{h3-pO0Vv8RXAkA<l(Cg$on|4&MUkUosX|PbSGR+)H--6DXdLAOk!{g*efAMzMSjo
zW(gJjuWY|S3+HykS^0NAL*s=s4!q-pY|Tg@)oxQ0S?ZATy?qi>JGWibYx${h*FFAv
zmPA@=O%aUA#y*G&*qaEk`mA6d6+W3HX%~f}CbO0}j?o<#qV#DsCs`hXPjYUQB-%MS
zS6v?{A<Tl))(N(A5b}LZSZFDUU-?Ynz<5?c!G>?cAuWKf@=2F!%N7Mm?Uel}!n(w;
zl4Q_9^yCr;^%&T$WICHi>~kSCVYqMBk~kx1iD9vpv2p5JK|v*ngur|7wi}rn8yi_N
zoEYmt*qd>xpFrN#)VS_ETy4~cFi*G;pnc<n=US?uMx1gt>d*D|);OPZqLUZ-`pr0@
zkkJW{v2LiWZcCAds-1T$X3_xf;TT&oSkuFnnmf1d^|-XD#?z;?$<Jf^+rg)n6>I94
zAheYvj+YfFjK~B0?W|eHDsJUS41arBRf6#DjI~9-+6$cvn)%tH)5G#HFr$sK5`%(b
zG*j9u1L?LqaY7N<*`j+Gy1GZa?WvfH)D-psI=S|6TFs4@2n(QQq-ogE=o{0K<zh-w
z>uE<c^Tj&-yGV#JHN4EHIV3=(q3ow9wo%$%+tG4Apz}+X7OERTZm!DSr@(RmOK5ww
zB*yhLegh8^2dDb534ZmZc5ziM<5Di_!=#6Wp`O-Q-x<;n7~6f>wuff7+)7EwVN8JT
z;D<2?zD<e^%O}Xk<ma$|&<zBW(;654&4*B1CCiI5rNa3Sk33D$Gpc%B*d7U74joX5
zGP-y3{wU@f0`_!Y$IGXPI$5gwg-_N%g+?8a0s%-@9D0ulsNx|g@%7Nsi%IYLQG*{^
z9O@kJ`__Z(?_4|8CymlZNrAKmGIjaUWEn4@ai~_K|G^OC!hV0se|hTq`~L9#FL)78
zCMZ%-S4~(ai`4gi-!y2Ztj#oWmonNgg|rA0VL3z>uJ7uKQL+e_dhPxL@7cUE3a1>$
z&hFJiG9^D=75DD7L71pAel9ut0p25>?8aNtKL@a&IZy2_of3ABsOvdo0`Ec<<p^B7
zyY4k6zEqXf6X3x`_$z;336}l!TJ#z-Ekl47vk&U}MdV!&KxzK$ol5?`N$k_i-=BXs
z79bjfY~obdOTNdg=c@cp4p63=Fz!2|IM0!(FwWJm?K>g1o?j9ed9DOR7<Am;Mp7E8
zI-hUUjM<KTEA3M9{O^OEjhUqVapYFYK~J?*rCP9Lf-M)>zsyufquf+%FAOfdHNpi6
z{UT+cN#+gE>Sld=1^1a~>`<MOuErpk(0KvZ_0jG9eQ}ftuVY&hpnBAgN`DGOPn0d_
z-Kad9#QhI>`{SN(QlJ!R%)I`t`Nf5Sv2gL-AJ0Zd$~s+d*;)DT?|pNY=UIBc+lak7
zGB+-%MO?q143I)S-~*$|7Gg~c24=Ub*HAlwb#c3tRbAscUscx#Qe8$`)A<bJlR7x!
zqKayh?On43wHJYwde4L6*ws(48tpBr015b$j#LaPkuH=rUCDF%7e(drPTqBPz~7#;
z2I~fT4JJycrOp1*A{x|wr5}o!J1XlJV2dxQ#f-+2tCsqLM|phEiMl_m<bf{$Y|4Tz
z<?A9djd@Y9h-~L!SFP92ITw8yA#8^+HaHKt@g+bwXs1gt*3Py5F65n+=~1Bhx!MJ8
z<E<1uPC>?_9#D7VYWHJj(~Al|<&k%&YKA-y%2z8eXlLK4CfSlWrp*9Jzj7!Rrej}?
zl=v6ujM_lt#d9EO(Jfoc6I1@wos^zofyCg&w0xfkNVesm6jQqPA}M<<)Nl-IAf-qq
z2x*YNlo&8ckZA#&&S=_M|E3KImI4WI1&SQ1W}WmP-;Wd0=K!EdJ|<o$Yi3Vco0^})
zF#L2BLal3~6<URI^$?*39|woJ4Wc7DJfRILc(h?9M>Ik{=9R%Z|55?qR{?0#P&Mc%
zrNd#des;c8d8XMGAbamaAThyXoDE9)u*TfM0KrhwP-0eMAlq>W*1+2wTxDfx<X1@v
zd;CUiiIQxI)enJh2rpIE3RkwbJ|$rbjdzw}`iCMhkG4`Ex~J(Nc^?(>Ovk7>g}2?H
zBixEcpJQ9>EMA5h$CooZ%2^IBdL)#ASVF~FqGI<Grsh3t&B{~YL6yI|Vx?#6eiS~V
z2u8rcIwcc@G!_jodClv2^%8yc8wfA5xz^U+^^#+;0(20O->H{6uWG~r2tf>H+!utb
z27%OiU4a}WDLwejs*Q8@V+rMhSpuFm6_dQ2{iS4XZca49p(};`1HzA!XJkP}PeEa9
zNHl^pw~?PhD*~oH{DQ{M)L|!CvxMH4@-eM52?T5~w%pmg<6t5+qi!24i-+xzQNz_6
zvB|rg1IkqVv~-43?W0^J$t(eA<vtRDf~m2)IIJoH=e!ap^kr@2;QBg!t7O}FOK*z9
zWmbKM=M8-5<HOgEb(H6%;*`7duLVu3_4gqRFYFUoEDNnpN9Rr(;yn)Xu6Rbi<@XIE
zqAshvE+g%r^~WViM&7;vMPJyVAC%UHcHGu~h{pxBBG3pr_P`F1&AGSX)G7WTgQD0v
zeFRx=%CU-xE#`FYswRwShblO~Ee7EDP)Z_sR$icE-s}L7&m|IETKX!|I{ESP_|b@f
zDiYPf;&Am*X<UnJX$rhunk!L=k(|n;XPk!q?t#YwOcOI1Zh56`$Cy!YnzMHxvtoD5
zdTsjb!d087EWbH(t%a<j%XOUfU!u63E-GtypIV0LXTnn`dsPeS`bGedo~HO!lkORR
zSBT8L_0It)E7&yA0qEj8>Euf1(HIY)R%Km8MxA^DCaL|1DqDhT73nd-r0}%1w?6Mz
zD0=vw=FD^UwQc|Tap{6o;OLR;Dpw-YU7D$Ra*P(jUDzXlo_#^8Ta!!PPbNn3Uyjba
znud-x{w}SZP6jese7w$WIv0IVGSsrG!KTdTx(zfL1^22zO&%oHgSsfpn;``5rptS_
znq`4aEYa`rRbUN|6$~#_2i^1bwa?lA`6<$H3zWx;V-@x;0U4C_Z+Po@I|~>&)#mol
zu<y@fGSZYK+5oEf*x%nTeYxSj_{?iay$@7Jp$yA1nfE<fGOb~??YPdIQ^##){+(B@
zgk5Kb-be62v&-5G8zM7`$ec1umV4^dbV`U%DEr-uq1_o;lKpXD7U~r)E4Xga*nOZm
zt`E4bm&yBlif`BaXml4Lko1CBxUvWHkwAm{Fd$BA4efw10>{lbGs!(;2PaYM*c5J`
zPSz&sDQmNRRSM#T=?5-bTR~g4-fXvM(hc`qk6-s2tt_KsyJw5X3Em4*4NUwU-SyLJ
z5n_4SSHF~c6OTKIdc3#TM%_pcKZ2dpogNOK&e-^2ePa;D5oW;Dc!2d3$W~|I7}|MO
zDy_48{;1=`_;t?;OjwhRMZfA-nYKS-K^?ETiXN7-3J#@pZ`r73ER|=G$E(^3I@VIF
znbr$E@>0&+E5>%Ly&r>UT4rBuOENbM_;6`wm?w~x3`|>KvxeZ(M*2Tqab7)j>$O<|
z7c!v}$Nm9&W2QvxPVAR*r`r1lnk*`!nHP@ki*>wOFq&e!+LoNF5%;jn^iNAv5JEik
z4iPJ^jgobr3G51S&g4$$v?T%$3=sG=&AIOqmw246*lv3jWYdeet0RuyVLpcH9XDO8
zBsD(n;M~M-!0*FwP21YUyRln)rzvM9THfq!F>Im!6IktXdB++i=aT!3fF|DSB<lyN
zdR^5$7*fpGX~TaQ_D>_+e4$q3qqWMs9q~&*y!oa&ZOE0CDlsj=qbheZzxn&R2x~vz
zJ>#HA{_yHClAhvru&O<au;?%R-eIDu|HYK&?UYgZSfmAzKF10?->W}Bvo(^=pRv34
zFN&h#f?%TJZwM$Da#8jrv*+)`{mL3MQm2KyXPXOefmnO}&21tXfjfq>Wek71YKR&0
zW|JvzGC0(Gs~5&)ud;=1{tlWhbho3>h_fEn;=1j#@w+3mLra}L((S-Q@`rN7+o+V8
zoqApV598k1W5A&|K6A%Dl9qsQmdkr258-9|yMvC1g~VGKR|95+X`A&0sh<O%d}>X7
z03r6TurDv-65tmIY=6x@t<;ytQ}<TQfwu@yi9ZhUPOyGk64H`@m`nA0k(`D>u!(t*
z06Kz8lT(2!&hoDN!jnhBsX*od8zIDC_Ol7#+M>>Omh-Ymr(rs$`hp%tX%O92GxAVF
zjMtQ8<jJeb8Qo-!xIZs%S@e6MmIrQAYo(p`cp+G4dGVZbH?XFqlfV5gTV=z;Ik@JY
zEzRHTk5LW`!8|#vaDC)gA<h3A64{!CJ+Vv9ReRB8*9u5W?D6BIYZ;GZQ>gjejld{a
zRCUU5oOql^*~qxcvP3SW3wYJ4WV<nKrX1>X8#_sIsSbD?7MT%-uj{<SD9(F0f#hG`
zO(bG5K<0w&*hj%|ZD9hM`ByCE+T_Uv1wT_wjB!=Dy1O!_=x9l8qAMX1&}L6_f8ekj
z0NrQ-X0Wq7rv!Dj<x#qnkVYI?ffYXOZ3;+@<nb-Gb65k7I3bOz1AGJ@qV%`(874@)
z^RTCD!e~FIPTQ8mkjusI`Bk}-X>EVZhnC*C80S^gcwT<L@J;QY2w60^9QwC<(y<H(
z$e{@)0qu7u`S)i^4Zr$ZATBS95qx;tIkGm<nZUNy(fkFNG+LmMlSyi(0&|yevvs-6
zCNOnml#oWY=*5T+aQn=TN%`NYhBSgV^*P$00-2X^R4H}<o;=O2c2obRuAl?2nibY|
z@O4sNrb1_VwkXzsBW+7Ualoj+5cbN}Yyj|S>^9kxjm8h`z2>>=HAvYf&LE@0q>)=p
z=~vz}QcFf4t-EwR`LdQOyi0jGN{*djyk^l4(!}15Zv!~C^C3nWkfCBE446D7OOS|E
zGTGJKZEV_1E&APf4K)NqGdS|-kGt{ehSsKH(3hic`5PXBB!j|Gc8;gS=xlpoO5|pW
zrbi$CO`8LLQa<-buQS)2Jfl**U%x{zFfygpn~GJEu+!gNWR)KrR<g~4qCLM-i5xP=
zKKgwhzhU1tU{jXK<<<u6Y9T(9z0d$e)82D5NS3aT#3Mh;EJ7R<Xack`!{0vZu*2V;
zqU`2+#@vCuGFaPIj+vB?sSum9!s_s%9h-Ctp73+9c>3D}EXP<dx3j1*6qJrRc@G`Z
z9FXUQbIG}d0Hj9qh1H&_@1aioVC7z7V=lLYYJD+U@aU@|0GWdRH)IM+KZH!PZ+bfc
zhn-*x0ML6S3-_&DZsc^`DZZw9!r2`7H-#_1^IRYPJ-y&7=LBw|D4~sA<x#>*0VJkR
z<so^7ZOpG&@;14Ufm>NX5Jdc1MkC<Yrs%hXfn5%!-coE3A-h?78sC9?ND05{Zr)M;
zbuASmj{9036~;=5{4r#t3!7SMHf>*eK{ELhpo40bB{>}sx2&GiPZS-lO$hBzc~$E(
zK0|xYtKVduK62_pN^VvhaGcVyi6t@EM`^&)Fzdj!Mo@?dfk~wka9n6#Cc#is@kHqa
z09kAA_Yq`Iby-INziUd@^aY3;?-(NKr+4z7t;EmePRrRy?FDAT*fvG})wEF@x?)fa
z5X~_-?6(g>8p*jQ)L3MPy`=UOl^N`v|1(>(HXP@#kk;<T<pbalDXsm=z@_PnrT<4L
zGT#QUZ;xIN+I-qfxv2Bn(pio&i9q9wh|=`Z-$nXHl9O~U1QatPi>Qg?GF{R&HddfG
zg(Zy^@iLTX?H*g`i)z*5neN*^Nr^lzTV-V~zgjz%;y<SX|IncLbkON{(=C4`)<`N&
zCw$VEbIAL8iabJd;(^G!k-{8FJKy8!p<mQhA1!{XHc<`;ZaJE_uTGybRO5p7YWh;2
z`ln}$iU0K9F#G8^Erbi_7klc~`KD~qp=y=i)mPHG#A(I_t*K$yRY&x|{wqZ|=$5|w
zukZ;!vsoqx@sMvDcT)D-B;}_-AogrjmI>r7=BIzzv*qt5R-=gDl=bKI-}d}BCJnug
zLt^Nu9|~Su_G{X5@zS7)E2MZjnxLvpd?50FQ`&!+&;AasEiYsL5MWh2m!TfvN(U74
z)r7_rtw27t#P3NkLwlj(B-?6TeuP)|Yhi$jmeeA5Ql6ZOAsRpH-`EU5myqf(ztX&Z
zZ2ydu_$i<6@WVne5M8y5wWjV4(h9K6d9|Htf%A&wIHCLk$86W+Tus=)jAy-V6c-ZI
zvhOMiE;1R<)fE>w7HPC4)fEFZRXo~@;6?~=0K$rJ7$-3QdPGZV#OX0BRg$ESymrVk
z=z!kXa3$m$8gz&aBg=rcrqA&VPuZ|K*cjXE8XI|3bE>OetK9|9nSS!n2;Us+syP59
zQq`p;iJRBoA9$9QVu}IP#@d!tC981~Hf2|FLM;c?0X?N=ipE!M^&PAG`ThI%jSZP9
zOtz~<f6cwORS5<<iR+_Lz@e&PwRD=|H7j`VD`PL-B20zto13@I-vmqpEC}0vI3xKW
z0Rv5spBpV7sJ`N#JdHrrp(4&+?+{7OTLW!L(%SI=3Mum<fs{wR3-&XC)eU4Bx)2Mh
z->or?;)r@@kbskzyfnZ5tZ@T~1U~78#+0uaJ=PlN%d82Cqca%7#@f?VOe3L1-*8~1
zC1plw-#%#5{!~Ml2;Jd|fo4{1=5I>B8R>psLjqPU1pY$^<pal3f~^AI@4gklbM54O
z1(`4+dps40Fpf!8)uK#-fc_&PsLH5W!fEv^>?}M#bNY3;8(kre)aEvCXp1#a*9T74
zl0xiBwa^RHx*-l@$#Dz`?&`7>g?n+gjv>%vd~n$-ZPPq$P_%PUfvU#If_Myn`tZ`9
zfv)w@?fRgtrQ@62=|V-+Dj}E#F=vj^Sye76a6H$PsweBu+YWLK@0wl3O9NpIwbrO=
z=YZdA-)|K@p{5yecC|mtiI^YKtVppKBr?h%!e9X=$~Me<>sRI1;KoIhxk+oQMijSW
zMNrOotGgAzs)9$2dD>TO%6brN#cyyet=1Z|xl203)zWwLG`C>~q7gga`>uTH*SK*E
zHf7pQ?~=PDZ&5gg_Ky2|QE%u)eOAaD=!HsElkf7jW1|SrwfJ>)ePDmBmB#Y@65!S&
zF)euC_;Pt-#Pg4nV8l7{eQLA^K8S5~)rr6c%dJVf<k}^ZVF{8#-`K%(?wO|3YEi5Z
zVa?6@8&+PN##?Ja(`DEGTxo&cpbc(`5g`57vE_L{$wwI2$Twf%h9};YS_vt%Ksk=x
z?pE!<8W=QpK!NVj2vL8F0JRv1*;gwDor+kcS9E8@JuJ-8GbdUyM+;e_ou3ae=89~N
z@Lp1Acx;`FeVm==wIri#Y)V}vuCi2GC&u&g&_DLs*X&JzPSv(q*NfO?@o1|3N77C;
zgLu8eZsmmR>CE}FOs1`sfgRy_1r8V7%o2RkF$7di*Nk1Pv641ys{JDWWs^*Cy^j3>
z)tyrp0H9l(9}t4!N{9+_8Qmfzc5q&v6+g4rJiOTnCl1Rt`^h9)NJQ@vu0X6al)ZBb
za2LQuX>1G#(Ad5f<!*|m4ZJ_ymdja3SL@h77m;pA3R@6oU_gj9h$y(&`PjF+E8G!u
zSePc_s{#o>5~C&uya1t{i)u@U+{Mm&*|*notLrD&Mt(Y{5jXYtwe8@?-QG6eh5EJj
zpuP4G5uoJKv+U0;pG|!;cqRi5_uwJ4DJ?Zh;O6H&mK{KojkxwPNU#MkTCg>4&2I%w
z8t%vfr1E}uD0hn}(D6O+<!j9fa-qOhEE@mHK*=s?{^<|BVKb3y^sR}OuWVtVnP=1a
z&-7R(a3mW>@$lzW?1^WmZP~MO7bV;ij7{Uug?MQ8)zrVo)L6wmP5{buo>KiVWfm!i
zshhMH`ifQqSqM#yq=e>`8r!JJch2U%dGifM^3c&uHg4per%L5{?WTv`{_~$hTO9L{
z)627IarH;Xh!?gT_hLL22j&_agGK(T6e8+4zb1FjyZRh~CLNQRc-dIb+IS@=lE8S(
z;X0S+0d$*tU9<Jo?iNwQgCss>?{j;1`3{cLUJ*NTc(vY%9+oMf>F9qNpGefvDf2BI
zEdSH>H2nZNe2ezqchflr7teGR&JXZJ9ce}h9-DSzY4qe-`bpi@p%uUhg!W7C!v9;2
z!94nD9Ve7l(=3Wx7Jmc@j(jr14|yj5h498o<~k4Sya&DmcAJVpS3-b4-1{HN->J;x
z-71o|hX8d9^T%j|C-s3E^5J|NlzjiM5+a&mzkK#pqCuF9C@u$^w+P%Kys`dE118dK
zylan1h=b`}dBu42#L99w<wSB;Rp5)SKgy1OxbQzTAoD>bY2Tb$qmzbOLe`z-A$pn?
zLvtsAV`PNNbnH#&mzXBlLSwwjO;yMvk89`sIXJ~TA8*!`iw)lCKwI<^wd=-I4F*Qx
zkD@f<elf_smLyd#*p$5mNe|eZUz4|E(nhBqMR~A`a{;PQTK<cq<k|`Kmjdl*yd-t1
zo=>Jqwe^f8w}{;<5$jyOe!a={P&Z0Vx85?ed<IMr;aqbw6D>5AB$1$0ODe^codN;@
z$d+SXXnU_(p4hCA<pFCz;O^ak{5k-a4_nf>1JIw-FsWO5qrz0>f3tSd39A=z>u#5w
zy<P$V)`OUtEv9u5h3{HZJ`{^~zET@DGTwU;wvU_&VItH@hG}~8`~IQ(!{2MjTo50o
z;;xUE;af^H(yVgUVx5+wx`&tr_RpxdC@i^G2aW1H2`4-zD0!WvqPIMbcDFy~Vf!j<
z{OdVb=V60=HuBy#6>#R~w;RTGYi>8%B*hJN+gu<ak{gcyCGUWSG;oJsjG6%=vS6Zz
z#)OEhd}Ye9ocHIM61k8ZE9U6AI`Pi9-=E`zR#x1B1=)UH6DAmn5!X0*2%VCy+{^_D
z?Jk?>+lL(LMk0JUkr#30VmxAlpcjR>tNk<ewtgkmij)iAG1ASepv;9GYg5$Xn;-jf
z{-EY)EUV>FPfd`g3dTeuDoN{ev2p&2^sR<aq=$vQndj_pT1c~DE&#CoMB7#6JlG!J
z8~_RDjAYYSH8c7$)O_8W74i~#et50hmw^m*)7aP@Ffn?$^;Mg*vk|}Fb0HfcxDQ_Z
z>1aIcTI^&J-AT0<%PZ<c>GkIWu~e^w%r%CI45LHE3HZk)Z)wiV0VhsWS(z|!FZqV)
zB><DM&iabVXyLv`>k*`kAw6oid0FSfGqAR?(^(?XGc#W811;<-JPYIl_a7&h4;egQ
zd`rI?5w1Yy@G*R^S_YTVK9JMKpu5)3{8Mg8UQ?Jl?qSzhR5fw*HT#E>m^Xr<l5L2&
zGpl_sve){F3b%D3{uMI{!4f@O!#xj`rv}{VuB6405J4YJR7pa~wRv+Fano&pRsQIa
zht4h59@C&&=6KERe`&{V7adZH93k{I!<Pf}jb9z$*!MlBm7gp`(F3kyBw%MochJp?
zW=K7$q+20_L424><ApmOI47-YN{VZn5ciX)Nlz){xsK?FfZrXMNE^?3X+w~|O$sX&
zngOTeH5=KKXk*n)qnt6Jj`@v=C)l{^qa#~&l;i+<mxg#(6lmmG-!rT=X9H>gFRSxs
zDgEHb6vhB0m8y}!<{@&+)iy;~N#(8{HTMw{uA3!zaNp26=D=bdHFJAGdO`bGDrRka
z#4562br^M1|CiQ9+@5%9K;@$+gk(Zap3%7iVj{0oT=&2Vxvv7-P^@HHu{1uO#xkZb
z-W2%a%!%gnp(4~+b_IxAfkM7lhDM~KdfN>wDenP%1pEy2M*VtEP8GXN?R}~jq6`Zh
zTYcyHb5V-t6aIBU7{Q%YK0>wPfYwn^P*n9zspC~%0bRU{isMP!p&lU%i~f+<6Xjx3
zZF*^qO-OB^aCqLFN;NE0Oyhh1NS~vz*}BWag7}?&DW{2TqJQGL_lN%!yUOEHYyX`X
z&Gkv`o44WcxQo@kjSC!p2ha1JwsxmV%GbAJ>2<P3rv(&ELh0xpbX>X|ihItuE`Fpf
zNumd)JEl{lk|f%rL6hyQ(VD=LEvzrSG%V|F0T&QxUjaQ1`R|e1+0P*pE2R}7{b`Ln
z59oKjR%aNc-cUs_h&3BE4K?TU20@ykT10Ghi-MhQypYckrSCoU4AYCfg(uUm<?$=9
zKs=ux0wxi4+pTKGqs}k679-Yr9ELmISS(K5)c+>UIyH4$KNP0mZFHCcy%pPjud<y|
z@3ju>Y~>mbB=c&(cKtkQmFWilgOPLP2PM-URhY_y9O|m%3A{_t^Rl^_tIr#bo#dK@
zoB^ae2w-c=q?)GI0Ri1apW?=ZqEURKi)g}vF+YUBXAlfNz+d0`dxHi-_ZNl#7ti<K
zKrQuow^abO&$rp|P%(x?UHzN3$Rm{M0}>Oy3OM_!;6GEDn*tmN3g`tI5rfXHSwHW8
z>hh~p=VvLy9=~?!=v%>&AdoQ7u5=6dv5$v&{V$;@#@M`ngW~zXhGjBUi|Af^pX6bY
z0Gd|wK2X`d7|#r)*4WW0pLC%wru6i?i)_I1W-2xdvX^h|{og);uDg^4#nph2kbk*^
zRDcrYW4MrQNdRzpdWZDtWDZKC+72o<D<m2mPv8I$Ye`<Pp}wvdUj@X{21_do3u9xC
zxIe~dZMlaM(iE@;2D)t#)ZUATz;h{Gx6pWO9rE^}6{5Ws1)RH7doF~<VK^Z>s4dCB
z(J9#s_C36R_t`UcHHMu!u}-nhY*FsQdzzplfGEu|{+KXaJ(YS!{rc21c4K2V0(ES4
z#c3Ed1}i)qdh0u(wp<Jk`dz4oIBKt-Tnel4CunE6m{XiVgbe_2doOSp1;-rrY-e-w
z{icTrw$%QqnTRymKfm>PimIfAR|0qoGm=GcScBi71Cf=Fci!(H6GKqAT@zUhuu;`@
zAU)&>G*l%NgND}+CR)fi!-IC_n&wl~6QRO18XIHdxs9QqIp8Zhr=To<FKP5BR$c!t
zHfk~{H#`3^Ugj0BJ!R`M*>fQYwNx@Nd;Hap1nWbYN;P>a4?_TID4A#Cb7<&7RxZeE
zGO-rL#efn?unoB|T#d^NDrI#)?MQ2DpigsA`CgNYC14$iyGo>`-SO*G$cf#(dHZdk
zV^~m5PxWP$e_roj4~38Ic8x!!fBH8jT?2ZQ;_Y;Dn!-2=v?9L#Eg2}D3W~5b%rFVT
zbgh-~_jgD2F(yILbtj-kX<Pseecj}FVb$V-2%WrCKW@m~${ZATGV|6Y&Yi?JVZGX!
zaYhv`A?!9~rcqT-g!}V_qL2DN`DAmQnRaKR-OVYgjAXE``|1viepeM#d)1aD!=RB3
z^pu5WUd5)pBG-cUm11o6ZqOXt5dtv5f-QFJ<>Q}QY7ZpIsXxE9FmCkkSmW75^Yk6H
z$<{#w%?ecW1pgx6!ze~6^F3}l(ARf4Yl@Xp<b{lC(j!NNB=U%%@Ef=HSh<`+uyH3N
zrtd%vm<9b6wVRf{JwD)gdStz<af_`yrBVRCnVBIREe(8sFvZBWi$pksywYC|Z({GJ
z{8Ws+ne4rC=izYO8%m2u3#xM0y^<L~gOM1+yKsR!cVJ3LHox=A7qp2wp8M-lbkWZ~
zQ)EMXeVQguy@6$L{7M<EUa%gc2X|T_c2(Cq2Rjjy&9S~K!m_+>%?i%5+2@}nzKzF~
zg55W1I>trT7u@}I73S*i4=t%mN8f|#{WD7>y%9Cg)E8RtdY1=tR-8_Kv!IH)@F+P~
zb$(GIqhaGQvW8$q0Lh5<avAQ(`pu`nJtBOM=!j3l7#n|*6J>TNT?(NOIBwwGP0@Rj
zT(=wST>5Muo?ccm5xNY#U%<#srKj2j_Sch4a&E58h;5Jd-rp5}5MXcMuSQK)adD0g
zeQ6{p6bMllSgqd{{F|V#_kV3M111}x)js2Vzfx;vF_Fi~F~PQx)jgDRbaNQ=ZAjd3
zQ%<vuLM7Wdv2Y&e*{ek*8*u97Ej>W)T^GDbltv{p2|APrD*iOr>OOjWe?~;Zfa4h6
z9=gk|<M5vhqLLq<G6I#Hu4PCAu|_0|TfO&Q`7%cvY*hAr%{lMaZiRqm^;q$8gl%^X
zd{H1TdcsR%u*s@Y*kkLVV8>8w_6yI76{RPAvWX9*mre!lm`Mg&?v-|W{82wrNi*#v
zJN&37#CbZ_vyHp9zNL|k|6x?`jo|&MKI!PmKjR`0krTqU|EKO0pVVd7o!;Q_iw1&>
z5`Go?ep*T+4iog6qk%o~5nqGIM3gUR!IEj2;5kVEh^zhv6Fa!p@!10nT|<4cn}Ngo
z=a>C#(yK%xl5?}Z?uteb(5eI%lDlOu9H1X?QGl1jN&Mi7KF2~*OpsOjSJLWw%n!qw
zpFrnK>s@1#XF2Rbm8X@k+W$^v7IlyQMd1+e<#!T?!k4#V<H6_>zbi>Z!ZNjP0`l*V
zT`2QeHTu`O{H#^<NTC`3{FfO2zY^AeAj895A2N!aX6Q7`?fO*EVu-J*CjBUjTaGNV
z36TQ@V?(-pB5=#~KJjZ}^QxtF_52G(X{k!rUL^4JgiTUYR{GzR_0~{cn`joy^wrWN
z;R5Jon41wEHCa0Bexh2?fu_8s3@_qG-UWW<GssVLJi0WL_1bSM<zo3&?oz|m4JGC)
z>>*6vUrSj<!OU{~nX36=J5NMfzO*YUEU*ETB(+<t&22;iH1W&VsF)5Ym{7@x{W}S^
z51vSC<FINB;1upLNDdU#73XVsnH-`m*&gUE*oCRa;kWzusT!5<SVbl2+Z*$4d_l*U
zB#vWLlCVAM^2~+yK7%rq@$&xGC#~|uqm{uDxKoyyX|V=r^DhBah>rNfh`h@%(S*}Q
zd7s6tv(fyOp42d8X|hGa1&dy2d@d?Z$R~aG#0&UatmANkrXtYj^5XViU<hn?<jLy#
zdROq+RpJC`h?-sjm_qhR<7)j2F8izfBznJnPa3Mp!N|?l9cOz?@Pa4yTzlp_y2NMP
zSB-ZmU5b$y)TmkwU~`dIHvSvTAo!}-*g~qYeqv9hjMS&>>s@M<WTVZL-0J<!BpZ7%
z;%Q^_WKy=}fANLadzHU)wM(jh)rbRP)DtDv_zxj~6U|bK6H@)C8~0J6T_HBxfm&i{
zFRbVarD9a;!@}6VX@h>)zJ9wX##0FnmE%o%n)+#Jg7?$Ony|VAgNSsGdGBJAewpY@
zI=|abRAo#VuG7!J=wIbjyuCOUw$BRR2nt!&`@1HA1F=RJ_shr9_&eTAv<*r{?*Foh
zEB4<#7VO6cyNoKUNYERS;^b6>np*)IG2lon`_pW4wKLEI$C(5<BaZ<+>=gE=nl2C3
zb4mRfk_B5cCc){Ogj#Hz@Mi_GW_~Ve`tka)s%UY^B=)J!p0w~u`TNJOyKRHk6b~ZX
z#oX?VCxNE(v$KvxUa6oEVEqc3I-|r0wd@}f0Zapl@5Vt`tKqZ5)auI6aT56N-O*88
z!y3XdlXG)u&6PX_6ukZ}@c{e^#nc<oa+1N*T~LzUO(I+g;Xk6M7MUSjL)x(kJWV4b
zR(t&hvuFHfg(dX|JdBNjpH968xWv>y?db2vptdMB2y_#fjn9q1TI>mZe^llbhx+xx
zgm&LEs!zhRUlj9fsxwT;No3339dq^8{5QJ$@6W!y6zp~8_Z)_xl%<^Y<Vmc1>t~SC
z_F)_XL}lp<?S|(XGeYd6Q1~^fU%h++WuH}+WUR@RuGMd>x$W}^hN~iV6N&HTS=AO-
zEY<ZZ5qPRJ<=<clEaYa!N)eL-W7~mC4mrK>LW~~6iRuSCU`GBeHvU=(YxhGN`J#Zy
z6@k{gVK0}${H!x_*Kpn__=s(CECBsPC?fkBO<hp>*-$;r-e-H)lL=cUK(RIovR~5D
z3})2j;!Pbn7OfkRy<8Zvq}mLf=c^x#3?CIkWqu+x3N;u9$NZ6H`LVowfpLFMsZoJO
z=lH)~im8}b=l0q}u}-W3NM*UHl)%i&#%d|ZGNun$A`-O_aO<e7K?kZY{r_X^&Euim
z-}wKLijq{6HChOzP?BAngpjQ)*_wpx$G(oTl`JJ8dkT@sPKdD-McF1}iy>+3`_9b#
zu6uMopL0In@9**Z`J?lAoYQgNGjq@T{k~q;>-D^B<AW8_i#&GbSf9Kv9(?L@aocU8
zNE19n76(=*gTZ2f*JZ4c&J0&32cFwj!&>pQe;b6=$&r*cMVa@0xZt=4iyG5Kgo})0
zNl?YB45vp^GFv5>!)JZCw>y9b83G)QbW}t$Z9{NGDdo(TLrLz$SZ%i@8IK}ZNn$g$
zK*;ky?XiV5r%yLpN|S1*TkfuF2%o4=b|^)<W4NtLCLCy?J|CH}bb&I7#VKMkusck7
zY_aJMqdGfheGPFbOp!w#k_mPW<-biuTgznRw~p{>;w2)6)_u3M;tn%pqFi0Pl%?gs
zZ9z=Qk4lnUa9H7dDIxY?#f>W&7B*D1zf=SqHorMerPm$|Fs3ev*K<q;vifmd85_*h
zm9Eq*wdQK}gfryX+yMGWzb#SD5hmMaS~+Ky_md+R-(i;51Z3?v<hCXA(i&8}W#lMq
zhe^6%oBbNu_c&kkKuKK1<Fq%{T#YW7`%4*gFLJZC3H`J>h%-$xz#xV{_(_haxsx2A
z1pPFrxhZ^$cBAaOoba@fAMQ1Z6qeo1|5p+Ntjcn3ur)7!2~q4z|K*OK=DSXP+##4b
zb>u%5jRv(P0i($mbSeEq1?DIzddOvQ2RQWAy<LH8%B6p$ZK#mq5xgRMpoKIqp+4Hd
z?INbGBXd<$!W?>|ph|nZLx2X<Y-i*?{f&V0po$#ke@azVRYjzIZdhKJnnGL=ECGI`
zTT(<#(KQ8E+6pm{2=blkg0_p-kP4(N-Rx!b_4boKWM_+gQC7|R-g4&bb8Yt@W3Xs9
z*EYpsT#=d)f1j>exXoK;tegO+W=^H2doJ2cn)Y9C_{GZuiN~1&kXV_VYU%tnHRX5P
zU|W1E)e@#n9?>@GDsMfO%x7GAvEF5Bjv0u<4pzPbktQhm%9{(q#3g5Q#UaD4X>1dY
zY-n<CAT5SdwJ^AcUH_B_9if7GE&cZpeH(`sAM5--O(YIWAKwR^lCP15trONWT=U~k
zKM6V-LBT?Ta47<EsXrbu*hdSyuTgdQ|HsF82fX!ew!M#<iMf7*B25Ikc<Sx2Hks0I
zcUc>pqWGJo4{sItsBjBsf6%P8HHad^n*M!g*TZ503)`+Az8u>l5ta2a)gCcLBCLt%
zE>?|Fm*B11jU{$j97*83nc35W*cqQ|4<0FcqMgl}yUfIN_$N2g$%C@X!r?y#63T{(
zu<%+DA@~*J&YDrP-jX6|6HEHa=HDI^vt*KPl)}lTsGe()hu)wLzFfQc_Br(^w~`iK
z!sVygvtwi3>32S#(--b2!HPl^XX$zxw4(-`n&TAm790-L4y6d_*lY4MP~4Azk6OJ6
zwIN(2m-@~I5pb&mc6PqjL+ml+(qsStG<DqD&&zY-+VFGjqV;VZnr{b$SYk>_z(rEe
zqT7`+uDs0?bi~JLdoH#*)7#h~4O3|C6=&dH7Ip9*T&Nh+db`1I7{xEKF_5UEC-I5U
zeJ7IgyS;>me2ke;=&fRU%+?W@ARCBjPbB+(<B9Z<`(I|K+q0;>ffcn0{+f^gLVx|M
zjO`)^8Yo|;;?U{DU9o|^D5=ou-fQaT-1!)PcH}^bfrb;Hqu{eGhYsW4)<!3OblBaB
zvGRzthy9_Kx-U@h`KnSRiC+(g;@ZO#owZd%BWcy7?q9`*ZG1NlZ&j*SD6$CC`f&|o
zIokH|V-&Gwb{A)k<xKLfm<3ELxKS(jTogILgo)Wxn^LSVVs-G)r)BiHu?y4tqMoz>
z%1DqP!7L!V^YDfbefZW*;qg%KWK0#X10r|U4qmX_l5vI?9_;s~(RQ`cnXYf@<7ONT
z_`c~OsWr!DG6y<eUnt#5aaa5n?ze(rpRB!ip|4re%db87>t?;%fz$P^uirZ)i{G^s
zJClFaAuqXxVKG3!SIiE(c$3B9r~u=NgLU0`RgMfn6nx|yD8!Sc;V{!VyfA$o76#>7
z!BU}gDH2-^%e`L7jp$<(a;dq9Y|@=}YSBD9-XS)Y1WqJ2Z1dehKRxY6$Md!JQSnx{
zBl`G9+V@*iyz^AZUT&hJ>T*{{U0&>CIL50gw_yChd9%kK*(ZuyRBOPEe4IG_@)qVI
zQR6Z-XL&n!Xr}KmFR5IfDTT|*GLLVN4T`j1xV5D|>BOCXM&P)f6tK<?oijgye)!gg
za2Uj-TdOu$&&jIm5R3huZ6EJ`%U>*gi<3h#?toIO6MC0AH6($KmwL+e-V8M<(6kO6
zOk2nz`;3T`-Dr%@ugBU`E57m(89tqk;1Pop1mQ#5MXC7qCFkBEj#vUN7@V|lb~SJm
zPUkz`8ZV=oY7u5(0GVK6_n>>J`x$jD@e*2W@Ne`*goZw!OSR_mV(}-&M$X--kC(X7
zG9>^ewa~Qe<3uLR<B>FNRov}7Yp$^j(=)zN6~B5XaEvUxt2n)`&i~m{wI}(oe=H|r
z=8_4%GnJM&DtC%oL}n;9*`Xo`zubMVWn)6u?k0VWKcW0t0d>zB(;zH!)*i%NZiR=Q
zS7FD!iVd}@{NlD>$}M4zZD|YGcKpgbf$dZ9+le)1#+Gy)DFh=o+>~@I-1Sawl!ymY
zf%B<|A#k0<QWsmsz%V~{O8&SxW#7+UYYx-|9a7mz6(IY&ASbG|!#ah6c6(7m&$S+X
zvDc_nP)50E|Gqv)uZr55KA&25>;G1c_*qHsXX%RF^RLe}D5NrvS`U4OzTZi~oi4u%
zQ}%fcaR~fS)^dq8_#o&LJ78i4mqE>RRj!Q<M+lhaD3mpfBc>FoIYQ?xUYtq;fBJ{m
zgOVvr#t$m$PMwFp8`<|Z*Bv6Ns2@9#TZ9Mqk3l7KsDh~Y>+FoELQTfrKPW^0%%S1f
zurKnjJY7G>(V?2zX#(iK!tt~Uw&80sU>0Y-o6&wFRG6D)nEYqcNfYg0Z>-X8G;D%)
z(sY+3=@tn*XN>tn!$pLoqu&kC(423UUb`K;eZsHr(Y+++=CZzCjM%-ps#2!pU4JUC
zWO?uLAr?*NQP{B<D@2<7K7IvK-^tjfX62+>>-gp^F0EkH{{ksPeDqH(#LZ?d!1_%`
zwF4<I<1;|^?+iG}16F>}{;LhuuyfxMsuW$k3}R?4W{Ur7V(g=P#RT+ZO4WXE*r=eV
zgNbdjNG2`ook?V(9Z<~9OKI8t9T0;jVa7M-j~zt@93VUm;E&c~OaI%ALcTkENs41+
ze*YCM{`A+mg(AIg6U^Tta>|>aiWJD!yZZWmJ65+aTD1pT96dLHch{vAr4)NfZfvpk
zSk>{6!p*$V&?5MTlE&Jh9+TLg{#`%pP4wLC+GU9P#8}KSyFF9X0T%}(eEF8ugoV4(
z4_`KjaruEDZIFsn^I8#0Oc9|S6yc~D>$*dvTNti>Y0~(_LM+1WN{bAGV6?V*`Hf6b
zmsofiQLmkIg~(qpsz*a-7W{?>_dnN$>%Lt`P&c@ufPIWOMo71WhrR8vl?}7o<u20d
zO*s?XvNv@}H<n<yF81_y+4^HTP*;<9cqiC1gg!uykCIX5rrHC$P3RHTE6^3YeLMSb
z1iD$;f>W!gkt5;rS56U?OIxt6T5J~|irsABc;#@tZhIY(U&SX!E^h2n-FC1McRx&f
zxD)>@JWo{DL>P*DFunUnv>p_z|K*u%VW7pv*1C=-dJKglHw`_e5Ki)4{CVIULCH!^
zzyHFyS+QtG$etN~^Sy{xv8xpV&O4qV0q4?p-3S*8oP}u*f0uxW4ADN&5qKI5$1|+o
zh;`h>E^3LQbN<`yv%)fTwrO+p39EFpp9f-`s&?Ami&FFI=%^YQ=>KVOoxJ`|Ly8Ro
zg^f8kPTWh_^Pqm8x#?9nL1_9A_JnJWxa~M>Rdil)i=qUeuTD51vMULxUq87Nc8-J7
zUSewB#nv)yRWGxPn)Dly^vPi2ho6BxY-N8n3;So}xjL$GsxD;a))`Ee*yZNtN|OjZ
z!+(tqIW(s4cw0aSZY$h#+ZH8u<8;^rz=m{I^z_sx<}Zbb6Abyrb$E9(qX^@!R2S6`
z`2>yE#}}2={iuAx>Du=cQgq67--D?#*yVU8_L&dH!A?@1b!LcfP5OqOQs-o(-oR)L
z?M}4T7w{<stdm=cm{Lx@ivF3%@~$S`XCGgJc9Cjf+d}c42fVwlFGzEobKk9DYa*@x
zmsfW+_I0$ZMySnZ-Fb!4uj!Tbpxaw;y+|t+i9f|Hm<_XPnyr1a@4X>BoHBV;7+Wk6
z_$qTNp(j7+^UNKZfQs6c%ItY;r;FPnn9^(+c(KJT3CjsgI}S%{Q_Q5CiNs?m2ew}~
zZ|vbqNaH<W9riNXUDb_f6P%Dy@2f+aU;TLcwxR3=@rAA`6<<|hKDStl7bNNQs}=?a
zC~VtLuuR|a_*8Ru{njDVFy6kEIe73>j)pVHAdbsxgEWrAuGCwr-kxfp&Z}k(|0NtK
zR<En4)U8m@fq4>>R?tbR4FWezfpt9MldN*YOQ4y#MO1bG2BH0e@URKJ|KDP20yup?
zHnl+j`c!PR$0g@^Xx{xqk2MV#m^ZR^oM#ez!$i5U@fb5JY9;zgW0<0$&Aia2UkF|y
zqYGbdUSura$}C+Ap({i{Ju*YP!EaS78>?Bp;0y9x_7%3U%neXJp^kU9K8`|#z2u3U
zjNGoEy5C5i=+=ZwIbB8)#XPr9VM)B$TSpwaeZ6P7uu#L_jk=4ay-_zlFhdg_n-c-D
zK@Bdd+NZvOGvUozo;&xnpQ~5n1@<{3Ue~pDoOF`!vyDgQMDpX%x<+erRMLK=2?*M1
zsbm807MBQcqZ_z7Ua7S`@v#&yhU%h6ltsrof;<pvh7-cKdlB8k{3>o3md*$(;O})P
z>|3~JzNXS<!?}AT%Q@n}R{VDL%qjd~_+K~MZpjg)#5)s$qkg0h(rY^=PiXdj;t3({
zocB8@H;y?#i+#0|UkS<BuC*AdvG_Dgtc6rUke!z%jYQZI;UvS(qzT<cV}Il!{wLst
zX4c^?HuW2i<yapAyyWsaQGQ^bsDh`{n8}vv&6w=Wo65z>=?Mjt2SnjZrj2fOWO*~9
z8aA`h%BsR2f1@0!G$GXEHT=UL!rZj${D~3_Xn8MoG$G*NWH#FOnYZ|+Y06(HvoPu3
z!#TyxWtH)rqSGw*u(B!lu+!S}Cd`Edg&)O<&Mvtb-XKxm52&Em1Y9Kih~>bdDh5be
zv4==Fnzjixm&rl-3X8tqb#afpcjJ|YU3_UP0p`W9s8@XdAuL9QZ1b`!R$=EzxHw)O
zfK{7yp$6VXGGVg+xJNDR*8S<4rI8&uOdJ7wp!3m!eg{PoGlbE$h24PW<lhl~VvPZD
zuk?|cHLY^*H&)^e)r4Omd1t%;O>zXY|JoXyrG`EIVg<QpBnH3}@{ineR=)7PP2)-l
zfeS69douI^bfaF;T_M5dwAuPYu5H{YA@;dI1SFu;XhqC$%|H#TUS2XUVXa|T%2)el
z&TZwP6Jrr$kvRX~E+E-v$Kjq5*Jhw<JZCX!lJ3lE<UoggDG2MkBe6P{=$s7(^8B|h
zD{2i+KX8ODJA|XC4tM=CG37Vz>U%{GBuz+5LsRn;4DL{|mRNX`iw%Pq)`PN+W6!3)
zx?^xGkVEb>;`CoqbVW!fN?KZMiOycPke;3}!`+F2tu}Vah`Zirbg<4$Ai&NnOl$fl
zc>e`eE)Jgd?R#OGIbwh~`gs~yE6u_d-|oBk9a3VLWRlC{Xzhh<dJ1mOtIFR6?U8sl
zZfY}Aa@~*p`JMG&*K7V9#l?_@o|j58sp8rWJga~CJJ`jG78kwbJ)Ssg6dQmC82Ybi
zdZ7WFXuDojVPTH&G%JOa$b*Sjo}Z})H8W8l{?_!(b_aUsy-D22$_}kc|Gv>YQBfQ-
zrOne&B=Mlp<=xpEdUy%XWM!>iDT>#_`f*>9-maWi6mfHPJ?nO|d^M>TimOK$nfLl4
zKHnUxHlLeIt;hA7rH8{2^kLFgj!5UJ5LWP_Z)v4mXmov)_SsO)`nYFuh!H&}dZTdL
zPPc~L8cclGL2X{WN`|Tt8fjLge0+ECZ!%K+@SI1(7jNffgVmL1S<`UjOZ9;I6yL4f
zPD*ezEZLyeb_^5)6@_?!bjw3=v<>1sBrt3vHQ0C}p;r5+l+w&WiH2!hy30Jczlw<;
z&$P^ESPLa5f4i$YQOtd3va6;_?7_71e8BTvB`*VxjV_m4qnUYg8Z&?E{5rUscWFN$
zi98o`JBVjpXH3GwX9vRmY(R`h=PvkpbH;xH+pE}`<vEpO3UB*0ZI@ZJJ>$bOl;9jX
zEzG9$RJ$>9&zqnC22L~-dS{L_`Y*@M#AXaPBiB33pT1xzP5M2*dWzd?w~0+owp<Hv
zl`kJ6C2HS`4Qj>%C>nP%`uAmlQS27ztM?zl)Yat<iq|1+Xa9!r?!r=q)tOAeG6{7_
zVv~y~>4P<w;gYI%Pb<&Tzy-y+BpPT~V!x_=)_A$lPNc$Lh}`?;4mC9wLraadz<K4h
zwQBD~t5x8szFf~dX5BhO5IxpZ0DW9*wJLV}cJ6Bil%#B{+T?dv*N?W@%P~-|aiS#x
zM@%0t?HwZ?5EeMw!2wKYV|kURG{A$;nFccO{ZzdAUb#?I0pm9&nHcWg?`x{s-90|g
zrurvj9nkKw3U;M@y7RP@wX@?AC2UewHm9rPCJTrq*yx^fWfoiPW{3uYt%~|F0(S4e
z*eCA--(b}fK7J`cq3$f~XJA<y(tR}jKiRRr@@z`EY-g}~eFEF8)&x&G8SNe)cp9|B
z@S#H{ZRf5&N;^f*i~*FOUuwB{dfjZLOVKK9R_F6zXn*tCcRw=Pd=~83!?omEv>l_7
zpZ*=Wt~{f+<+&r63B!QW;in;#JkiZ{J1ZAQ@gnN<`_0=eJ(F+obY6IdWCSLsrB)rc
zpL_qoJ!#bL(EF2rFcZpSER+FFC}3=IbxeHbe)4kfQEGd7w03Ah)N{ixY1@yOru+Zi
zks>?)76WwxXik_08zNn`J8qp!|8DN*Cy+OVX!53IfE#Htr-n}s)Gzk&;U>{;x^@38
z)dClGwt^Mx?+}<f0~d6Y0Hg%G%4G+^{|K5<HSDak^$y`Pe-z3f+Dba{Ad8ejWuOCM
z*Q`q=O0!p)CuC4H`)HM-lpu(w0^n~1_eWtusgKUX>BLv=sk(Y+0ZONaONXvH?m~ff
zs7W*}2$y$Mjt-Fp5io3l2%<n<gAPy@sxrK#Wetz=uezan(6aCjvg9KD3$V9s=9M^s
z^aA)=g;AVn=n=2W=Z69vZQ<|C><JTRS@=r`$fk+TQ=-49TY}e(IM7n0g_GZ&uIh|1
zs)wj!zLyo{DsC|1?>S1tZ~Q1l8ec5W&hEH3oH)<Afd(Tbq{i2$=Hb`ng%pSg3-SFZ
zNZS-VdE`b;&`2YEZk?_NO&%wQ#99E6d87P&fe6`+9Xz0(yd`2PQN{{s@$y6zRV$eU
zk(ieGN7hnc)dc|mBSi0kMxz~1!(iZLeSh&|>8}N9fdo0v12@kPX9sC?r(ju;GZ5o#
z+Bc@y?0Uf_->ZAa;6QVHruFgk*S|WNFHivzMVaOzcg&Cf;6Q^QSJn*Q^QHpZ_ze7U
zY;j5tk$lv2{-d%>n_SDyw;d|>Qq^sU$n3<EX|1YxlRRy(7IYOd&`HGC3p_Cgb|oTV
z@0n;YbYlFsm*%7v@$gl^vDbo={FDp!F&$Oc(>K$j0jK=Rr`gjo;;T*kF&apaBGUCy
zxncltB8B=Qwc<Ofp9Lbi^mIHx7djKECk^!WAB4K{yV^rP<E43wjKdC(*`J@X))|1H
zw+Qwr=WIa~Y=X<=nEetbVYd^kEg>9F2VUB--AHWjLwPyaOse3Z;hDV5fC2=7TG$f^
zsP~q?W1uQT_<rY9bGgCf0luK2$8;z;I}qDA<Q3D2XDOZGiX4>S9{bV-B|SaLO`{dr
zck`bM5ZTY)d12GHmGZ0I&?bHnKHDR^Qo&9dn#QW_zWX;c7xglC`Hs`urxdrq4*s66
z0s69#m*r_7=OpJxMr)gUf%b_$kswX#GNVtH19eYy7daDLh1J9FU5y^1(@vfk8UJ*9
zZ`H%#yKAzAD@g%GyW^ZSwBC!?Q(rJy{y<VNMzf5EL(@`8J7oPN^0%kb<Ef52XqnP#
z^n%BB6l7k+#j$$xL~vP|#z=ZRaT_qtZE4^u8Q(2$#JJ4fGyKY^E$tUW&l20fEX`;H
zEB^e=l;p8?wh?@lGx_8RpM1&!hH9qo2cX^g+4{IT$pP4m%5F`qw{7(jwN#AV0c9Gp
zSD-imrG!mdG`c~<Yt)AOS~Y%PtzqHiafvMrgOtBbwEL<M2m>8k2XE6OPc$nN3o3aZ
zO>^<5TNqR6aj|!7+F2jBr*>LP+_#lUacAegm9yIq4$f*655D85z(^1{{G0C6G(vDc
zqDhG@ZJD=H*NqRU8JVS&ze2Gy&^mL-(cSM^e#(Srdjgt|mdMr5_;zr0c^9hssX211
zGcJh7L!NLzsjbfLk#kp%DeArKzvp4_3Vw(@fa2Xslc16#B-B}?Y>Ew&{^52IUcWLQ
z63&Sl@S$aK2WF$DlghWDW`3E`F5v;T?<^zmPwb|hq9dPb|AxI(qi-k5;{ojugIM@z
z6b;lXSZkI~<tfk>o2r{kL3<WJacGvlcgB~SV2ib=Vfy^$mo-uOH*|@$)*~IUewc9a
z<}wYH!yldEw`Trnha$&x8IdM!n?BLsiBRfMj-s!{XV8*#8ml!?5NK4_!MrSg=k8#h
z3==twAm$2*sU%45I*g`S$DfLY&P`K6VhgFB!*s65UEfCDLyhlZ7ZEUhOzFCyY#C=-
z$CIReeT$COWYJzDioSLS`oBoNsEhYxPN)ECtE3l}C1BBf@W%0@Mbvc;f4o~bn25K3
z4TxYp++%Po!Tb*3D!@5XKjWQ^&E(xeSb~9H1HAybsb!>}K6LBE2PMB~J-rUEO7KT(
zv8f1;LT^RG7d>FU`4L{N^jW<r_`$2UM8Wv7aC$VCNJjL|Ay?JU!f?jFfk-x#kA5nD
zoBY9jofREbt78LbBftJ0X;8<Zl`*V&a-l<pRG+Nz-L=vX>thHpkmy6di~w04#b1@Q
zaO=UTUyro_XS|?=%hS%bGrFgb%Nh*Yn2>!L%!wXhqkjKnIDTRlnc?8oE^)R#+M>*x
z4y5F&=N4t_=b4f@{%qm+-KZjh!g|W@M>Mqx(#^TNv=-%BkF+H=-FD9JOP(L%LQqgn
zskN~=DKOc}1NWCWpC%+lLWp}KE{C@QN@Cgj0)3Rm74I(gbT($)k-dSK2T&n9sJvQx
zu5A#*e89e!5b~Xzq3x4`h*T1~scJfPZ+N++w7zSUY3uIL8<~Dd=;3?4rJh6aPQ1{7
z!`?;th@nb?VYSW!rD}L;;kYj!qdPS0siCt%VFZJm+D=ah-Of~+7T}h?cLJaFYLB5e
zg6hmXd_hkyEFaFyuF3Zz(yWd==`hsHwX};54(9W_?FTKGS1gAwOTEb>XtTo~Jsd~V
zUt1Y5=Ie`apaay?pI5OtuUCv6b@l4{IsTG#5?q#FAg24po0Q0BYG5-O?PxrW-KGzi
z{A#M#fD`R7ijvx@^c9fS>fz!Fbit=Jp^0SXlJhH0DAb28<uDqnZr_?sH0B!R6A7%{
z?y{XF(K)4hD3e;JS?6Hga%8QC<;?bk<LSTP0e4nC0Mj@qii20qFYr_wa&I32zRm+Y
zc78c-AVhq#E(@7={>9dL*WikQcu|pi8vnP5b<H||znMY*==K)7>E_(yyHn_2TN|={
z8hA$c$2vX~)NL!NwW=Q|-}M~~AqFea;g{6*Zr5CXMox<0S(vBe@ZVg#{4bIoZSkY$
zY_!gTgwp9o`^*pVqfrvyG@WojliI3Vg)^><))rP0&v$Ni7%o#24NV)dJu{Zb-Rm84
z<5+7Zx`H?8`TC93+5mMR>a~D~9euj#v<+6fu@sVJm{7>OWp3<6hY{93bISUuyR9J3
zfd6*i$+9JG%HqCKP9U%j7r3|nR$O@R-#$LNGVrzm83AAmg7n~{(Rqc&H!q#7jpw{7
zc@sXgAb5!OG^67>oo6lDSq?}dpnXiN)sD-!ti*X>@rMm2a--ujW>5G-9ioao+i|J%
z0YRg6?{Unyhpp(vhXAgT_||22E$Sn6U;|v^Qa1lSy>m{P&BXm3r&0)gS*pl&@(Il}
z&ijKJOYIVd@a}gygLB?5HxeBWJ0MV`8tjPg=@z<GG4eUO$d~HgLeZI|U1+V-c8aQ*
zAD!e9zLoS&>g!|~x)t6lQ*3_et5s*@6ib=%?oIJ`?0WQXLxO9wyj56Nq<y$J+WD*d
zjv#l%bJwoK`!%2Mb=R(99iF^)>r{?g-fzm&5Joaz`CTcdO*LAki29X*=w08H8It5J
zYURD2zcnsoz`b6MX`!87l@OW6$kIP}i?&?OxcqR~#ii6Xm9@0|b3!sRRyzVKxZR`Z
z{~ZE>@20cF-sq)o-r|2I2+?<{pA}3W_g^<UvkOI{quI(Mzmsy8`nNFB2He2k_&@D+
za9rO6<#Aa2E&hbO>Hh!X;&}v4Ngt2{^pv?2#D&a0kNkH_+1yEF4kmuPs}kjMd{h^#
z;l^BYO90JNiJ|}#y|Ex?T&4v^LB)`yi#>BTu=^v<e&smh)L1jPBL81F-Ty&-_#Y6S
zuHHW>PTf;}#c<%AtZ^O;Vdnie$W<B*+70X`P6X_>B^f1~lj(AHv4ek^A#cYFhdh{2
zt+~OmtV9hH2mAHCJeU~~)+yYX4x@lTlQ*=1D&q>H7Ok@Z^rx(nntR~#`VQ2Gvqo@y
z+|{sa;`dW<r$J+9CLkh2U|ue>+g`B_8?A~oF>0n9n?Wn(UESbBb{BH@f(9M-Y;i;9
zgwcqy6y9}BR=NuSVRBu>%5t9`YX3kSZTt6lZQ|q7_|^ssl1i?1Z5L)->rMI2e)$8*
zpQIy)x(qjM08gU&g7%<0)&}oK`aahN{@h4Tbei~fd2ImS0q4OB(Ry^~xLi5VKFJVs
zy>e*u^Lk4lcsbj27`Z}P*<sAk-4WSs(Xc(N#$$`Cg1|u7*)XOH<ep<|O%F1K0*w6t
z-nxCg;%2Poswp=Qdp`p9ni=td5;oI*3m!TbKLK{3zO;Tcp!-*%^G-eM7#ZLgxv*z{
zGvsa%4{EB96KN9KO)$hi3j}jF3;5%8zbe;-<(I#Mts@Gy{M9}QW@fcx+9YX`-@}VE
z{;K&o*_>h*zBfSmjn&qsPeW|rWF4QR@51P>mob?Yas=efTBhC|`192n@gXmEX4=<I
z3Z(+v;nvyV)v*0;%^j|NC2)u~h*9sn_CFLnE;)ou!q<BioOs-q=6`<w{OC~s_+{!Z
z0;}w{F!3b8!>pOtZLCc&Ik*LVbWRhQGSxqqf2xi(nD#w;HP3*V5fn6~&pV1^)Du>E
zYX3eV+?40q=!v4!D+C$g>hzwm@&gyIdl+_}RjT_Ft#yF;RW3ml4tbZpC~C3wIZ^Q%
za`NK1sgRwl<i64-!||HK4KA_M?WR(IZ%3X@dMg?Ys0L_2B289v{h7Jfud8KEMn5iS
zN+(ZUa<Qk{7+RlyIWy1?JPF}+t3xlNdz@mq4L_@?EV2IoLf}QVA=Q1)_K!|J)gn@M
zluNzMtvl)JIhc3cy+7JFPPQ$IZkJXjUeN+mv45QQuhHWY6`CwZkeqE)``w>XfV?d_
zvHL9Imi>O*Fvaozg?=Xz*j0&RHD0P@swhLp4u*aGcYol0XAL?gW3)_SKMExyRD)iB
zm35kiXPBySDVd(8NLak>D8bwUQD&}UdE%4h^9iY8zT<%5cN&+WYmCes{v>gIwqki@
zyxs3Y$k`#2iFSX-YUhSiDIai|`!kdf|MVuCz+d}%qBFzgX9|zWDBvFn=5>#su<=Fp
zl}&w_?{T-To(lg^+$1<H`lrj999639=B)^CE=*f8YLqK->{LT}Y>wZNJNUNav3JhN
z(6pnP$ET~@nNd8uXt0O>X!((9D_l2`5nXJlg)fVza<jM)ZNzf&6urNT+vlDB9S17v
z>5!l+FSIeE_+i-B)GKi~?|Ox&VC;5QUYZ>nYfMRxPK$M)C@=zX<krLey`u4&-DE7+
zc7JDowp8Vpkma;Efmqo`d`GSG5(1o0`RwOYr>2xoLU&_Y1U-RufI&37P#*E%2!e<v
z2LW#+mz|v!D;zvcjL{Bm395??K~jcC1b(~2U@R!!Zxec;t$lOp9+sSJv(Ok>L+7u(
z(>opNUKLf&`Yy0uG-q*dL20sr0|wS_<cr^2mR}1LERjQohaG95#Y>+2^!{R(78!xV
zgJEz-u<th5x}HR5^3?S&0iv(zm)n0=oZErSTuX$NCrrFqnk;*+KCtY3z@K<&^(BDN
z?Mg+kLf8I*6_QL4P-&NzN@>AMEV}NF$r)escMA>|Zu%=<|2s6-7h!N-3KzOIiUJ|v
zKMZk@dggs36M%Rr?>~Ajl^8`IzZD?}YDD^760eWemdNF!OpSciyDAK(!;O@gGWdSW
zF<Zy03P%^X=Z-~KRsC?#?1TcjBtW1JD`I6@@!taG#|;eTaSg0tHj`Mq`N6@s`&Wb^
zj^uku`0QRch<=*nvQ+V)bN&rvo%WkLXtc!<&i)#Y{4DmYNj4P-h2|75B<TK+LrcyM
zVHXxLTlEsCSS{7?%A{1>^PoMTJl5-Lu{rUaNZ-C($|3TF<C*rFP&dajlJvI%`~-)*
z1aMGWoY#z0>Hwi`{j0TP5@xG7-_c?_tIoRHc&uC_iXR+>@?T4xn%jow<d&1hiVlCc
zMY@4(Q?ut@n;Lo8<BkTrP*lwVd1Wjq@=YPdspeF8%E+->&@19SxHf#1+G8DbJ`;|*
z9041AD1X7R{H=EeGuR~1!#J|1k++e-^=frfeEHeK9|tH00tA3N!+$=K(dx<hZduC9
z3tDUxl`S3DSn5Z2cv?o<a@AkARYyl6$*F~}HHPC2+$vFk=9uGGfd@u1Fm{|Mad@lx
zFJ{934J1z5vFo{LQxr1#LXq%Ihg!P5A(;KX{DIy{0w&4g1$B4?gIn1G6Y;bzNXao0
zVTOb^O&WsyiMLLpZ7C44`zy0$+Y!WgJF)SBvxfPpZMjZ7YQhX>9Ji~rI|1G!Ce0JU
zp{HuqK=aYxgz>^)L1cFK$`!7`nSd(?op`um^d04Bb_yjAGE?JT*y1F(Yi<BG)-T(<
z+O7T00e94Q;Yr|j?f^w5n@MnYhx@o$Z|I*Bf9qilCCux<J?mA!P9*x9SI)wsUrio!
zu(*Kvkm&4cTxzG5g=IY(_WZSq3n`JRGx97*$k)QQFg3r!$?ws{l|2DV1g0i^8}gV@
zN<^<iodmV@m1#m`p)?79@Nm(5gO5TaSP6z|5>$-)D`x`)#8K}hXy?-E!HtPx?NDdn
zA_$bWdYP_0yc<szR^XYA<p+Lv#}k@4EDy|K8k}A|1BH)jS;12atpWp;*YguU3G(lS
zGlfEr#NU|yet>YMZ|_A`YLO%u3vDL#gS^lBrI|Y(-h|raUssh+c1PiZ<yg0EFD*!w
zTLeySoS!4|wFz|NqtS-~=+bq;#~0)O;CIc*M}d35730R0F5$Iy!)Eg4kKnh7-QQef
zlSUF@P-uOeANMi)hXfgQoklEQ&PfsJzP&Jp35=3PF%}f1^W>DKsc=4<xLnB`%#7j8
zRx@N5ozV}QEOOo#Er6RgU>j-K0%4FT2XXx<@heYH0M3}RVHUvP>b6$?7ZUncmbbUg
zGyD%K{0<DLid7R%H$5$g;KIR{-7#&%yUB!jpz+#wb<J+%Rs?WIcNC}GIDP#^P0vOd
z(86&tT~8wr_cvus0%H5G74LRc&Z3#;JAxNkOqi1W|A!Xwx<~Qvn2|qlWa7-jDm`ZT
zO#PPd?0o76ZXj$sc`3D<wm4IYu-eVu`@nKm&GP=be|A(HKb<e!6m@KF)Trm;_Y@@u
z!PIRZfsZv5r16cCjw3e(oxOhU8UL)T9k3>!dn8FtbUj7xQP(c>D4FY+OhMD|T6l_(
z=Tz;r<Ns)n&!o1yeBltV?Sf8s=0RGc{NS}V&+95tJd?iq(TuvC$P7^Nbw(CCdjGyn
zkt_c?*i0fv<Rg`|c%<ns+f+7b$S!{}d|O-}s{dYs7J(gT^ITdgj5Xz5IA-=m+s&c(
zyt0-=T<n}<#6~jYks_9g=s;{lKDYrVt;WXXG)+qPVR{rlW=l2p-<cr~kqtG}cgsjC
z#p@`K+qC~SBZMG$bQ=9;0!%josH2*@bME{~D!||9ousp*tA0^S`@MU$8mrdkQ~J__
zec9=L^hSXdn{_j}#4kd|-NZO$!X{7+gZ|)$m&uTR=I1N+OnXL@oW*8Qw^Nl<I7oZx
zJ2RcX;BH#G-Yi=Dcii-rLI7$?liYI}09a=pw&QT%p5+cX=n&ZFT`a#%Qo0LNiA3sB
zzp3-@#Pww=g-9JXr3_#G#?rT4N|~lB%sljgJC}21^@BmUVs8JC>yjd6f?x#2wv9)g
zFdA{5Uq#5oGOWYZS6_$RY1a!A<q%&r9LGSyZu(*P<q%BLJ7@-JBmmWahu*Y7%=dle
z^me`dbu7oMT5yz3YLBUVjt)x?T$%Qw5=~%iQ>aA8MB9h0hZ5T*>tU?q0jU^^(YodQ
z+UBzCY{EI8TuyYtHwc&Tt62TjXJ|9o?|FSN4-O%4u4nJDm4pJEt=HVj$%YPGWPi;7
z8r26^>*WKUpxm2p^^!@0abpoh1nNc#)fv+#{@+W>9Z8`M65o)<0;c6<T`%cxN_I-(
zE-8p}n&kiiL5~y7!VLaN-b>RKPG?Eo9Ho(l#F$Q9Zed2)u!#|^X0JrlY))E?t`rGm
zCpz=S?67H`PrM?Uq$(3TBP5?i6eID-^NidQx*Whzev7(~V8|s!^VUmc6cE;Gle);3
zitC)lu^OF*>%q*F4;j5E_AQ$oT@s>xm+t^5b)8lG#VOJ4d4zTsZ(5*<0LP}*n6XYn
zod>EQ6B_Zspr_o;ob7R7CL8f-3#$CA^YXGk-x)d-M_{@92Mxj0R(({2l>h@J81|aq
zrwDKWj{V-CSsl36?01Zh{&+|0zf(p{AEf!vTxpCL<Ho$ST9+doS0-mW(?z4TznhNf
z5?#18$b1KRb{s&=o^soXA5G@uSLd2yGwpYwAz|b2?c|qvaQho|PH;h=iY@3wdK5qC
zQ43pB-vPi^=sqxp*7sKv4529%m1c7I<L!L2Fo4izAFtO3U{SPYVGqUg6HIU_n<)?p
z+N1j@vI&V1!$%JodYSv{T>?T9mSGSVbBJR%dAMy>rmVc2Ykb>c(iI(G`5n^(Q{2dU
zElg~&QMcT$w6_`NR*g37g_c0g%za9P9fz9Z13{Q<hJ54bmA(D_HU=BQ^4a;4%B5vf
z)88dJt6mVV4@-Xvg^I85Ntg@Nx*$3H#jzPYYI=H*C6Oi--T-I4w5wv#4EJ=aUKF=P
zC@ji%i=hqTR)K|)%pEFInIWiXa(jv}Uqv91YMEz_e#7}%Xs6**Ik!hM`7ni2Lcjsb
zTspP)Vk<M>k4P&=v67qI1N#OLw^jA1u*HqH6A8I|4MzqJu67wh8XM9>ror2{1C{vD
z^J5fW&c?ehbA@LPdgmQVw~fD>Bae*3-6&*&5K~E^Ya{_Aj|^+8+TLkZ38zPnvfl&T
zg~K7g^o}A>L_n)ZB@JDC7*J}NWdC=>&!5ixvcj9fx0*2bq)ice(g*Jr;eTI@cKa#V
z2^uFga3>>p&0J!LI#*RkS!AGx?`hfJV_CRz6zI0sq)#fQHZ7J)a(&o3d~{V7@6csZ
z?`0k~d+wuXZAK3NahRF*F*#2@gwrN~&_n$}MmP;y{<v<UgZ)JH+O`k@EyEAG>znN3
zp+^vKWi$rB=%A|#+bNc+KQ<T@Y22N*tqS40KIT^eR;=RVu}poK?j@m49=2j=N9KPO
zjU7_i$925*wbcGpHTP5I*u_^5Yl4Hwi|k`WZ6tV~#$FWCay$Qt_8OgkbkwO>eigig
zgrw}mHp|kI!z%j}vu6=U*^W5h+0}WS(m~q~^Hb|EUe1Ie^2Q$s>{WbF^iNYVi>VK(
zgF4mGDe6Z(XHVQFM8m<#OC?OMzg4ubE$&;2#4oKb#~rzt`+D+2eC%K3x`3j;&NZFx
zF?t53pU0c2rJioZ#}TdXYfDoqDaQu#cF8-Z?hR_eu`s!u+MDs?nuKkRcz{f7t05#s
zp&?LrY$vgkJ08dqK0#TxpuZ2pz!;EiW8m=S7Vb-Np#1Km{=`tfs1-LI83^G;U9YnO
z_jNyW&+dnPAB<wT&O30wcfFZ5<dGWO2HfF=SswT$vNT+hhlmOJQ%hH`JC?uFW}Bk&
z`VYKcY{Ot_&mCx(A?S%LWvvB|yT!b3%*l{lVxY}=ul_>ziDX}V(L))T3H<}3czUVb
z5vNuk7d_`Rb&a}*S(efl{5XiF=?gA@Lk)aV7S-t6hw@n4OzwS*KHY04nNU2j+ZmD~
zvbCFDkBhz;Fsy?%E-YD!)|P{ka)Lo|MQL&4-83pWJtT*&Um<?680ENib4y9qCVsfP
zIDfMgM>lW)+F=a;XoqR7Y_L#&BLIxes<~QNIQ{j;s+zvL=QbFDW^4xUBD9iK$#T=C
zzHXgJ{a#wj1%LYEbsFt4MM>nQ?kw(hi!jgBQXRx;l<184xVi1xNj!aqLY>>Ea`}QT
zY{4$B_4=6rh=bV=A8T|Hos(?ZGC^w@(#@pGe7H_MRL#06yJrqhnS7#$gVY0S668if
z##Gt2^Zh6uNg(k+d-_a05L{`c=h^SBler!LA~1nZ%?2oZ9IY_bh%Y=TEjsO}b^LEn
z4O5+wlue^I%MMTjO-*+pvfyjGULEQl)D#~r@s=3#Onb%HpO+>6R&I7EK!s_Dsv^4t
z{x3*l3^u=pe9@E)Xiz!#D~`Z$Q~<L;|KQ~+f*eF(gA$)Mkxf8XY#P=ELvj!S2o@RE
z9B5?n2159zvLs(*z6%MmeM(QMF}iyDC3EqnL=LwzWXu@fmg<1b<}T0>TaOIrrbmvQ
zG=to4jxF|Vy@Yz5H1rpQcE(4s{|Ct~;qj#Xuh2BJFqnYu1WS{u3JXjVZI(_MyTqO*
zgv-t@v9r#udS{dExfWe_RoK)h@?~`N+;_#T{tTP_S-~p~bm-ivApz8~vW@y-+2J4X
zG6)j0#7BkLV%01d7?B?UV;!_~JE2c7v=!NcKwWJ;5}G#rmx|_oqze%?_9*QQ;$eN8
zy)*Z;Q{&bY-(M$|eW8!)sbPFWHC$c@<+0`O=eZ!4vSFENuM|s=@!4`-XEC~wXkcN~
z>55sBm-`G%k+ltPzASv^f`nP6iKPKBmrljPAXiaHXzJ+=1JR^NC{*mE<<IC@BW&$i
zl#BH~rM(t(LB0%s_<mBAH!-tk>f?N-zfW@1NSo$%!qDIwCrG#Aj$b-MPU>E6zVOdP
zTC~Ne<xkLc;}ZVzfE<%sMfw+t<0D6yw33R?ex$P<Vp+RgmSCj(`Onn*narC<j|=ei
zqs)8{=lFTXjqzmvBGR;PsT}3`ZirtqlaUWSq8OMe?QLi@(WE9^D8htyl_Dhxl$9p`
zg%Y;tEs3T&#}02rMQ);w1&2)OMTp)m^WPL&GlxI08Q}@%2Pam{%6*VHgz&ICTQOlx
zGhE#7ljD0$9KcFhlj$|e_RH@{O|Q?aTt%_a(i;BH%2cHC`7kT9S-tK1;kZLigdGmi
zya7YiTCboRyfi-=*hCH}(r^cKIJ36u+IJXN!Pq9D9-mPa=KQWOz_NiZQ>;FUe+N-(
zkHV!xu&^^S42-_`_hR31&vh(#f`8LMT>VKEA1(eW+W1Qcu6%7}8H0{A_SdGRRRano
zEY>M=n)u09q#49!SKVS?yH@dmv()qw(hkxn*u!MfTJe}(<G!G^<ofF4B4nVkWGXBw
zf(z=WE4|)L-Dn|$7XuJ2i7kCNbYNd@4bDpB!wB7^+#+_1)S1m?EegXtQ(3w7koxpn
zJIEy4^>%xcs#gAMA8=IF-s#2ERoT^VGbdPCJ$_#%;)S=rP7PcKHE<{TwDs7O2@9$k
zQhM+sm46dMDO6lR7n9qvdg)NHP)s3mp=b(CE+hq+(EEtC2OL0|bxQd^egM-HIMG0K
zX3t<#8eCR-H*RQiu)zs0QACCYgch5zvGJ<&b8YMR14>TgB@M8G9%j?AC7MzC3A^a4
zJ*yvAYkZMbHYdAPgbzun?DHbs{+puBLi%fD@)5--o}!54MF%vZ3q%#XoW^d@=;Ppr
zN*^xT!KF?;0dp=FPF>n;jPNa}36CZ{y(}DbbN?2U99@>G;-4Mj6bxF-1n(iH?#Q<(
zro%-9zm~H|2Rncs)yO5|3iO=;zYh=-LK3gBTVQJX&qSRZ2Pl*IBhbR>&ac*MVCHC{
zzg19mmN&dh%R?QV@a9)PMHEVewFCK@g0G6qaRYo?4pA9U13R9~<%<q)vW<EkJ<2<1
zjg@_Fg`M`}gLSE_GJ8y<zoMd&E6>3O>H9d|M!M#b3F<KxF8mQgGo3d`=W@aE10yM3
z_T7hjyB5?`{>wYl{@W8c)hntXGYq2<e#EHaX=LOGZ5PNyPS7s{k`(Qd?v0mMp$nh!
zkKO`CWCd|2dY61Ykt~8;G(YTN5EIa_e6P9+8`N|kTua4vO&s&wzF>nuG(R;&^Q+b5
z1mfFK<YoK-r$PbW#sGVV<rqYa`r>&>iQ@IsntdfF$=zeG2D&i4#HMCLwe=gO$oQv?
z?e64zhyi*%>8#>mxLoA;w8G9UasF^2m<_=cZK0AtMa&9d(Iv}M(xdA+knCq76HL7<
z6HtF9VZ26MUD!I%kwWY>s-C(D=7)ku<zj>iF%!NYO%VjF7PL=R=K?ywySsr5DpbRF
zEdX1E^_R<an<V7Bjy^e&%D}du98-T1y|@w;aFh?(J9SwWg=`(E6#Y#o`mZxxu+=DD
z4GI@`c|K#kOJ1WpzlmH6W0&SC1aH+y*TQ3&m7QJV?g3`$1S(L^_;%Zt_EHQ6N0Ukw
zt32)-gZ><Gd_~?CW>t}WwB^1o6735I*vMZrDQn-E`7(+#!n3=-r6l+%?AV6P?*o8Z
zN(Zs&RMY8{Q9~Hw`{<ilu@esoxJu#0F+0^D&Y_x>w~y;;>(N<gPDL$YPBg@vYUTC-
z40_tbBb0A<&*(=M6JlTIRq5=X><60^GPNEyrMw!XLkJ@g&{(9TP)fOLkP)4>e;c_z
zFCmlc#Dkly=hpS#t^|p!_{V7@E}qvi#fEJx3~sP(3umr%533ETh9lm-ixcZnxy_G%
zuy}LJp-|VDj$sd??L``6wR3KC_ZKT3GlXobym4@{Zpfn?)-#Q4LTBnT&Q+%NY~&zp
z2$GM;v*g=0T-L3ITfCZ6qq$@)AS}pvIIyK?wDVH8ti;yPw9k=_jO26Y>4Bn^B}e*k
zF0L;uHB8)PKYACln7-J1F556ZRBK+KD#TaW6a-jwbR5XiZaeXLA4_5Wk(p@?Qy?fH
z5XDchj%J9QBl^uxy5r_0(NOy~c)#**S0*jEH9eYh;&CW7YJ38QYDJ-uSHq4Ai&$Bc
zT?e3E*mcjc@P+8LELrkou*@P%m5MwqlhS^4%UaA|u5ZF}8>B%=3)%zlA$UD@ltCTO
z1};{@c~gACrO_MH#Y|T-^NJ-Wm@55Yey$oa&=hs6DB(P&^K}wTfq6cylv|}R^jclf
z0UMomUOLfhnYBMmJoL2iLW+hw=KV((?Ac*<t&K^B?Y>Dh*D%Hf(FOBDukcP>immc5
zfAM7(zOyM`n+hN8#IPszRyfqt$<fh_R+_|bTtB8x|LC@@k2C)&_WSj(Uc28^hvHB&
zRo-P@0kg=FNu|x_fX&^ZwG<pRQx?i<FpD;xnw(s>1Ov_j7Cv>|y<Cwhu#?SEvy&AL
z31fJJB%=$t!!I?H0PFXm@aiESV@PECDY>pJV#9azrouoDpET2|ATlBNr__=w09hAs
ziZ;vH13ombu-w54kviWk-K$V5&teVaef>mbxprKCCw<Zz=5-ed#nkUWpA9TKXAVyH
zrs27WX`ufjb2`R$!@T)LGqjK?25cGU-{=78oko;!edfj1+zLaZvClv`RXN)lbvv|-
zfqUo-1tNxc2`8R)$zAq57p<^)rn-|j-i>@!;VcdGHJDnUfgw!k)vU(<dvk6!?EO32
zQ(d*4p4@EY8Y$+CaW6DDL420-L043vhk8t?#H+uL?ruzTR~2qur^J|fg8x<V4b{oH
zm^Fo-CPi3k`X=^xjh}*kbo&kI0QKAFvMw{sM;?NT-g<qs?V<BK{8No{4Biq_VcnJD
zgUpHcb>_zm{i<qt{wY{CuuYVr>&koxMvr=TkXt_65>D5bD9Zf$0aX_g^O^jBonwsR
zFLPZ!?62@Q*-t7z;XG0NN?9}U<C?iX&hQh7dzi16Jh{b~O{uqpVuw=RQ{@Aq1Z_T<
z<E}v$%D1P3=Tq`~Sq06$cHN?wXPg`NVeE?BH^7MO=l<S>LvI~9xA;PxLfi0{+=^oF
zz=Yb$I{2@sE8*Wp_(%c<u>%2o8%MlXm#1gXRujonhfknPK2-lF>B`8ufKkXIs`S)^
zQ7YAR$Q_uqvFRT+Nus8w-Kr(eqa0O`YrQ{|^!&YtCP78W;`!QLfdz!bK6wt~HFkim
z+5)-wfc4I00?)O+3#rue?Yhe>YY$VjdRWlNSvZ&S)3T-CZ)vW{yNODN>VoYWdXqWN
z%IkvL7xs=2a~&!Dd^>Q=L*8(z)kM@7+h2O7S*qgj5|1J;Wk7D%-Dxw2Z{D3RaMN3t
zCyrH7p`Z({dOrPSGE$+cX}_tD%a{Uvbr9`FoN9I_u-t1{_2wfwU?k>Duq;zq@+nz5
z#3*o0N35O_qj?(@Zh+?l+n25aIw_Cu$-q6gJI|@e0%Rc|mmjJNQpVezx#N=^(7Gk`
zT`q9%_ar?Qt%B(RX`b$*E7*=&9i#xR{(_X=I%CDSg{ysKkNqfQ?5cF#{PHpzF{J`_
z^M_BWCL10i!W=Y0A#&<!j109s6?!`@xF*Wg_@>@j0>6w!rO9-=2Z@LDBc$YQ$GzKD
zT7XXKL{hzOvSLekLp<Z1v>;Vs^sbIN>C6=))fX1t8_v*J3r))_#!<#`lmy&rLhq#8
zzweAb{&Sn<xqOACHe%nxhOgjz%jKsj&R>Ll7R2)rJaG-@Pw;{NvN#uTKTQZo&c>Z8
zQ84xK@MT<ZJ|IwSCQast(Hn6erDHR!!PI~c+n>zqu?GtZ7))(Sdrf`#V8v+sL-8!d
zjodCuZqJh0y_wN+FK+6O-zvRU8n00^{fi`4ui&-R*1&h<BW90z-jrqWdbBoyve9rS
zZ0|)j+Q8zA&}s+K(zH%r1({{fme=m1Xwi4a;P)8}f&y`d;U}p9s#zs=oag}Yb0oRY
zBSe3{Vi$XZ7{BEHn{gH|qEAocimKE-hgpFiwe>naUS3C#^A_tu>9tb}(j*95)5STz
z6H&`96bhxh5uR8X__lBmLnSW@dNFU_v+R!kM~^2q=od-T-F7-Fb+htw&JiFUwn<mK
z=+KCIty7PT;)3uEump}m_xa1+#+a9Hir|*NNJStxp?bw557Vx~DP{C-;mcsH4{wV#
zqJBY3U0ONQu^B8nsB^Z0N-b=2yKkuReR7&O>cItZA;<!LM24Fj5gA1cO)#;HF@)=k
z$C(CILz{Uys1v8)^SF0O$|TKZF>?%Xi4($@6Ea8l5NGofMl0s|s6!Z@iL-JlNTJ}e
zYVlq{7I)@p%ac;P^Z4&&TPq5$uuS9&!Wuz$U9LqI-!Cx?z9$F`^8&8&@|?bk;@M_t
zQ|t{1(#gO#<2@-?kA_G^go{hKp9)M(m9ur0>W3*U$}Qx3zC066c*i3VLl6gGo-Lfv
zg`;bHbLP><pVAanG_7XD^rOm0EAS;J!z-e-{e&Ial*so+4FYp@pvunhmf9r!Yjln+
z13(|-s)6>t!1WSbfI`|vYvnKzO`&9^ay)g`$UmCC05i+pmD}}ZXJ_23ig+G|WT#~N
ze|g$tnU_0uJiB9MFWYoF{X2XJ`|GP<@MvFTg0*C&sU1!qSDeJd4d4zSok^nNgu179
z`}P^ow-VVu!|7=;zY5`J{gYJhpDFse-<;KYjd8hqoOPAFx-M3QnQeQVA8S;jH0%6D
zf;Gj0^Q7NmmI!OTs&*g%5kK<ogkwgxzC4XqA8o0a|J!x>-X(PJOScE3kBXbn0)n-(
zMk>OBUS7*40Lp^JL2lcHhs5w{1JV1WDExwZ_qLQYAAS-~1I?m$)R$EZ>zMS=s?KMj
z+xE&CLQ$Yg>>HOfemfJ$U;|G+Puo1LIK%OWbSKhNPYV|nE_ZG26KUkTB0WpKmnodS
zrg`S4lm<RJ3JzO_<M|Pq(XYu*YiS63fypY>7755zgIm(*l8=6F_qR}{wU%nkLEb=T
z<g}IeLPFi4&z4k6niG_4N2ZE%WDKAW@EyCZx>j|8S0F8r^{bNBuBp?~H`-f@Eom5w
zPeHtUzq=j;F3%BlogPD7XlCZ`0kUs<)p~v0=wO3car6(|ty2xn%ncW-__0PXZsmI%
zknQa|FMsiKcl*%sH~j*A{D*+`vdQ|?Mj>XYWxM9<^g2K0bH2#ENv!{zCuQ2#b$gKd
zmeZpvSiWg)W_iyyMBrE7b_`eL7o2&jSV>r-sfZ>VG1&{7BJ6ITEr>z0zc155QjN2B
zITlmiw>$CT`d?FV=6^*t7A*9x0BpCmQiQCbK#@vPQhrm7%~B5NXkTZj*I?1{mk}U8
zX0kshvZ$ur+<vck%*E2Z!qj)-u7>+YSYUw4e_NHy>GNJWkHQWLD`6Ot1*ZuIU29!@
zJ}z5=Wb%Ff{)cEylWcar)zjCuVV>PAwX3DH(xdA2<1>m*eifev6Jf=Nk!9;ty6WMD
z<qL@R3Qqs(0LF_xl1cf_UpQCUMow6yvyl(FK6yJI7rt#_tZ;B*-qJx49agz92SF#(
zD!;_^P>nlb`KF%p4!E^Bc79e-;`%GuqEnT1Wx2wkwbQDeJcCUPr)ta#DJXa3!~XF_
zJvH*&K=AUN0oR+ha$1(_uTG+E4^=g|y=W-Dc}?*^Ylwo!x`TMViSH^C5q_-#W>x(>
zRdT)L&QJ7`Z+(|Tz9!{~@6u|M>B>Npd+Ee_nE2B0Ia0I2`m0pBF!5u=-Yj;s^J>VW
zw2{w)qf?wSnsu|&Vkl(i&T#$9waeoQW%$~!>4K-b$0r|BXG8c{GzX71Vy<R!B{5Bh
zEVAKYD6_A0V)Qh<SAAF0p;Sx_Wpw83M(aS+V2k2iqNOMfW5iy?iOTu)4h=^FfQ+DS
zrFAZU;)|H*ZXI{%wy@1(4PGIaZTR^$!>Eb1l}i(Gp8RNW@<%y&?nk4-sg_~BlsVj;
z3)iT7*Bz{at884}QSW;-ez%;s*}u_iw1inbx%9}3f;1<qE309RQYllr1IIJ=svm@g
zwZVP84s*_HaM08gawMKx4rczepa8$K65f5}Ei3)F(7-&hytvwgBk%QI9umd1aIDAq
zVwSr3vRdphj5B@He#`zgl^*xgf6@G}{%2;^9`ulF*P6b3-O*S6ID)kNslhvUs!jj2
zJh$eD7gsZuADv73k#Ikb;>57vz50+0V{g433LV~(Fs|dMf#D`W7k1Quxfw_<rz`W4
z)djmltkh3V@;Z<CC02iY{H{wqba$^W`@yfnnmsnb{hBR>vvK_`_>gA{udEj)RDu>O
z#ualt;9Z_5l+<I;V?gaeUi8Z!cZS|44ESYAuUEP?d3v>B;>S9UCr3<kqH%L-)I+yS
zWo4WrKl^>Ye4g*XjL$WU&3Wo-6SZBl1=MO*zCtR#dfTbfsW^6{nEaM5_iic~X<E;N
ziLtsaUtz(Ly@cg1aY`0V;iI%s*E>?c0sH&XMw^HaBhM4px?`mkFJ1FRu9jUmPrbU5
zDIkn@f4c*9iVe<+EK0)8JGg)69W42D=aRMboctG#OFiVkx{`{~7QDN*JqH>9p>5x8
zEKnzBiudB_QF6xcNy<I!bRUvd3mCWh(#3?`c$#G=E~;=claIjnM1|Omi|YG|$C*)G
z4rM4yU=-L2Lk;TV?p!QTemX>g`2}Jy$@*s^{sJ15Lmh3#!-1`aAz&>swDGEpC3ww5
z`vt`=$%xTTrvr``q8-*xxN9b-YMQT^{Z!XCdy<l8nTu-;RnN(&%=_$jWH>ndTKhAx
z_tb^qOq|5@2hk-GcRTTp*Dm$;qZyb5A0b8KyPs|!zd~IPa3FVLC|K$SJBFlK7`ya~
z9tLh3L({$e?Y(eugBXC_LUgU|O*IFc1rM3PS<oPge|%9UY=AbJeL>06_B@E3jRh{v
zZORfHR>1n(0<J*#2;LZ-BksDi5z=)TBjQk{b9csrqb9_8o>=7b^HUM~?<prAOfV&u
z<gid^{~=bCD%3Um8)wlOW=!;176`!i$iMYF@}62#3d2Ww6*rnq-FJQv#9TF%Lr-8<
zZYsV!t>`tIY5oEuy`C$BHOxnAhQ?Z0he69%;Z&wUWOlX{N45QJFX|*VJDV$^k3~^i
zH64O~yOfzwj;3M&;!%3)yN8Isv-+KqaPHY!#i?KEGsdb;%hDbMrk}zOsMwSZf`;^h
zrmwwU?yc2`N9zAib>AJ;ME9*dfPje7e+Wtw1yO-er3q1y-V{(!dhY}Tqyz{cQUpPy
z2}qGDqEx8@p@*(W2|XavOQ;DXklexd{nod>b=P<QzvrJ!=A5%;X3sf$?=xrb=UIV*
z8tV}kcG&fPcH=(lUK1xltT57M!m}&r_pt69X+S%0PVuOn5lV6+1mNfQM93s1(q^>8
zNHIc^?9yc%@HJiz+)uA@ThBwB67}f}=Q}mP>kwi$1Z?^_UYhd#1u?i2Boi$^!-V9;
zV6gO6jzCUQ!NcZ6b!FT*#$M<y$3PWS&&D&*(KS-@_P37%CYbb-UEkT9GN((;lAJ$+
zc~DmemTcS3yf=x_*`9|(J@E2X8}X*S->h*HY7+?j4vhS#HrV7u7v5iTx-2N1=J`>y
ztA|=l;{MjBmKn=ecFNV3`_En*=uDIjim)E3&895p;>tb@7SP2UFh+RZSsy?l557*E
zUVMLj6M|TN;{n&~=|Dl+TbeF*Al~qitY*^1yj(^GU#Np|K0*6!rj~7!$Tadnym^qM
z_0jeMh6Evv>isH<$1~+1yHbA!ggAlJZvmKA@V)K+M^J+$1x#9$*VUsCWugH|IofJn
zj_yLw?_h)Y$(EWERa%wVSuc&UZyaTD^_8T})^+K1MKa%6?cDitxfd}ojyA*=!+xes
zxlA3-RN0ZX6%Z%LqczyU^%+be^ms_8t$!;kplz}=D<~=GkT65kBcDWW_{P=lkd1dw
zIyRco8v7s+wGHp9wt{xMr%V2E;y?>k>nRq!Wf6B#lD*74$;Pkj2_mmwtcYwByvloL
zy1=QytQq2)=IubVZD&1)u?Rle-IT%LJ|07UU=C{$B=UyZb}X*MUql{dd;D@-APi&Y
zxt5Jshe~#J?b<2@SdA+#)wSPiCZ23zYr!$JNk$<_h=Ed*F}Uk4Q+|@&(`PR2!hGqC
z(EIkfTqqwi=>B6slpT~#Kp89znp{j~QrK*qeP`y|eEswTYdiXx4{r2P_KkE22ZbV3
z`BY8jj?)&~7sPQ7%GI_(@t6QLMXbBwHe2PLvRmUP@Q9coi4VH0TUuV+$B+$sRC4jV
z=%(k>6Y7V-X~hzHFEx?=-bZN!v#xRYE-!H)tP$LcCOd2=Me>D%*bzFz2LYSD6uo;~
zCSH_xD8L;~@y6!tB`5X;93xJP)C)Ozi9J4%8DFP=0h<u_3fwhNG*U|EH7NmMFJmjn
zqiBSKu)YIE*r+MG50>f9dmJ#0+91+m=8KlMh&|;q`crgYwN>Uweu0I-$EGKTIjjg@
zd>e*XjW|Re$CLNKdm4WF_wO3!qz4X7f)a*BY_w1IcxgsShxLRCQ*Iw-F`F+=>6OAD
zat9Y`U%ot7XseF;;q@VC+ydy>LsS_#lk~rFGXc|J>iJx7c=3^|MDulg9Y-xM2LF=i
z@tKrC!)52cMNT_;iLoQAb#*Nq%;b92jW)SrwvNV6#y$o4b|=<fR69F>#JiBij&UW(
zV@AX>_N2_><U2G?cCm>!m^EL2qd655-AoiFuC!yewpJD|fBChs4z}Fy+(7{#%dyH3
zg0&pYh*{0Fc&SF<-F(alOoIWvmN1aGXVT+>s6wxVDesE!Zz5yxc1&<vuyYM*Wha%O
z?Z%mv%s6HDI&+i#OQP9*9R3d@)Brkr%R_CXIq&7d^BOP5+2}rnLaP1vetH~2abh41
zm*78-d@><(^fvpX)LO>(U=&GAB$KWq_7gFruX<A$ISqO+KR1qbE*c#E?#$O#kSPsS
zGxqpO8sFb`AY|&dFStAh-b`mQG1`z6yhWOVHJ{j;Z#2Lgo3%t0;EIa&9_Sb6#<F`r
z_ibKDp+`G%1OC`&OUVFgAIr^@icLnfMcm&jBke-Px*TU4uuZ(ZKZ3uE4|E*O9pi28
zz6m5PWIn-akM4apkZ#1s7eMx!R?y~Y2s{sQK7Kr#q=mC6mO`WiT|?|HfE}BUhf_}n
zL0zA62$%#*906JXctGGl%lG=4#m{bdZI6(QZ86!%B8WV;=N+~ubJp`a45?%gTQT$U
z@F61c1Cpdiwjkih_-y;k=^#+0S!4;8ka%hXuFX#lBSG>!>#J28!9P&MUOU9+R)QJ3
z`&Ke)_jCk$air`0NC3S`2}tmD!j`9CpKt6TmM6@>@?;j8GW_T;2djb{liMB5CM}{7
zxKs=QLux7`Z$NyD=M{17j1#b`p34LTu?j)xJ^s#H0kw;*K+B9D+l${#2|jQ@v~mzL
zHZg(g*r2_k4ulHCyb*N85<xqbZJ_z;@~-*~!51^DuJ2hR4o+u3c@9BHY(-;cVaCu3
zr<1Sn(cwY4;0s%1WD_ykZJ}WgAQjkZ@Qg0LZXYkLN+fZPs$OwOQ0WrluzZwb!qVIk
zX)WF$T%Jn(sn5Lf;%=oeUeNs4x+cDpGD|sB5Pnw5k%=wFgI@1N%-DTCqr}3j@dH7A
zsxD@?NBOwzt7`3J<u%?L!BAQ&*+8ylnQNUG>;OC-a+4XjxwJ&Z`&#XgSV)V{@>QsN
zJG0ih+eH7ZUq0Ed$)ucN4magX{*NCv8_RIXIU5-&-u}jN;@j+jgGa=bc|R>v2Fv9I
z=uL>o{uacd!DhCZh|`E%VoA-`{oxzAXLEeWx_mPC0)945m5m|Cgs(YVA;Zss&KDS=
zTK5gTGH6zNu$9fV(;;<4yNqG{!7=L};tROuic|149gldHDtVHH*I_~7*(&B+ikDtT
zeJbnbt>O9L!`;<|hfPcA?9Dd89n2CQrlh8}8&!*c!KefU1tAdVqv|p<at-eUG+<p;
z;X{MZuiE2tkBL8Y%^vYXZYDIHM1|4s4fMFV2qBWzxQFKsaF*ON7hiDktMaO`yuwIf
z&nxyx2Fi+Z{~^7Ahl-snUiZ5hm$wZ6>5g?5$8Rk_fPUohJ6?Z0pH*!Krq&bxM|X&B
zM|nFj@O5GB3d`(19>Lfp%9FbDM`X?c2sxBKS!1ouHx)|8+jPYTzXzvtn>cW*>3A-4
z=TMVhp1L*rgH7PnW!4ai4{nqoBx~t<E3fTpjX}5`kdg|<QfeU(V!u=0SmrR^eNv58
zJcGoGW#HbmS^Sxe-#`YCCYCMG@R@?hU@QBzKFv)SuA1;m{-td6EAH<X%z4)>gH}Qp
z&VI2_TCt9r*;-Rfy0c>3wqvt;#KXVqE`K?b&={mJh_YhfZ^gsw;5Aq3@+mUj_%*;R
zgIIlOE;I|gPvK|~DCZf$H)uOgb}slg3SVCQC{M;v2G5Q=?(l50fscw{)N`jIW!SR<
zmXwTu-eb*Iga9ioSo#t{@k}ATBn98DIK|m`x)wlJgu;XCdTQT9O{TUWdTh*gqFVi$
zHHYf9?~q-GZtdeVq9E{V9UDoK$VXM0J{6Y?_F021AkgAJ8Fj-qWq%2d%aBL+egNuR
z<Xo1t47tP4cc@#i`HT}XkcCOOp4cXLGp!9C_egwqxX58ksMUARGa^2`;nhMAyraP8
zc}~TQY@Day0Tqwcw`gRMa)~nSH0gb!K}_Q!=hp>eCudfy=={J{nxC75h!N62DCK%V
zyE9sO4IeUPWpWNE!d2IDHpuDg8;JVt_&YvoWO-Fh2hd$O3V=q9aYP=PEvS*&q4nfe
zr|JmDk^lS1#-^rHI+BS!-9O6v*18kaAD|E3yt#lxBJAusYutvVBGrLob42|OPqIsL
zwq^&?RU|`ZU=C|ctzpy@wkj*yn}y>ux88Y6HBFlyNm$=4dbIg$TNEKn9QqO1ckVJN
zitRj4663`%UsIie<IYq?nke3^$gY-<DPPQNAWFWpg;1`d_Fnrb%naYW$-TT#xARi$
zs`fLJnW*~s5vj(POee!?vZNc-W7ZerDfStPPjZH_iL+;T0D-v+a}*wXY<adwO09YR
zrH@XUXeXF}-I519Sa4)Mz;B=3{7CMbkkYZ5aYi{$OXE{ypR-a~yyhf~Y^rasDf8P;
z;2ba}$a1Msf8<tjzrdZF^U=2tRuB{;&OcHo&C_X3g|k0}(%tpb253Cw=|UD{iw!?N
z6as|UV?KX&hr!kxc%mOjq-hJY_t{G5>w}xa8n{pvfbN9ieWCkPcYe>#sSiO!+|;jP
z2s6@q{<{MCt0m#t(;({9$@t-`&akKR%y(;xKXK%*o8|813CqL<d-{8r%F3VcymdWe
zv-69!Y>}_>lf^h8oI^C1yp7s|&0^u7W|h^}bR5qwF-%mL!I-zEyUbRdnxhqD=Zz<L
z2R&JWenl41cU|}RS(V!0dtOAVQFW+c%*BJQYh@=pd*RB*a-&%+Gb?Y6VHyRKh>>Qm
z_NTe=TlZqxZc*rPk4J_nuwDuY*nqR-^Uj!lhJ9c_hDI~pdQK2H@!HKiqclJj!rqA<
znkdV*sNd~GTMV+fU}Cq}b9-O4U;KSxbB+hu5xw>v2uFd*21SWL_Z%--hS{LlP%u$L
zFfl>>59x$>>((uabD$5{SNX^J?%|o1coK!<qs<GOAoO8j@=q2EMe;`L#rU7M`&D!O
z5#_|u8K(&{nv8>}o$sLKzOgmTqQh*`13#bh=YaG6PnJ~Prpr^=qEGMn)4V=*<9z(9
zn$A!05(lODcrkrP$IN}(AVQ@3flNC$(yPSE5CB?N%6^#^hNB8Ts;ax(WgB;Om6E}E
zG^(Xmc~;JJr9b~@lQi8>6?mvH+!~lOazpv7O4~hXVAAIHqg^MO@0-<|S`y)NIxy{E
ziFRJh$|5tz`nXz;vZ2DXJMv=i&$8mRQg85k86(S~EP1%2R;i9m9nuzj;ghuD?T_4n
z-73(3q+@qiO}D~$<3*|!N2m3W56B^A7ZI`^VfNsc#c#=kI!e7CaR0JDa(YVMF+4z8
z5Zr9E_f;;nZ%<&={)*>*aw^5~Gwc0I;d{Ouy-67N6Y=zS_&OLH&xi~G9UH#<$4(j7
ztz(!@<SQBen6+g_9}<C943z3vr@Z@ezLhTGFk2SuA_f>fOh7)%QK%0`v4E(dC3FFY
zXXigxoJo4d&UfMVXDwQPE%0+ij3gq!yp``;OQQ4Lf}!wPwFFBeD$SP<n#`wEy)F}F
zhaRGDVX3ywiDUDnsxofFgIk(+6&nun%ta<Y8Z^FQJIme&@8+#noVOV(yzK`tjXvC!
z?<jlpRoRUwKNW>RAo{uh=!azJoiJCTMwYEqK^G<^{$4Svr`~&2e?QIps68W__T0@7
zhbn_I$e-FA5<gj>oRRN^Q{my41R(G_1=n6!{sSqw_dqP?u#`w&udPIi-Ph96rRVix
z@w*Bn*63Sadi#ux1mAIUugabBIhAUcM-ODa`sPhaL&(gOt-f!U|1=%9RM`uJj0G@Q
zq~z3-&_`0QT?FnV)IndnJP!}JB$kx2f?S+Jj(GJ)&|de0v2Dv!;|B(u0-+`6F0K2W
zw>1cOtiX^9+-HzHG$@n&#qo6>-yI+TWNi%P0*#@R-?vsZjn;hnQS*xmu7`Mr?R|g8
z=zwgO@{AfAwp%j9H9s1fJ0hg|O(r4%*3lX^B&s<B3uq5|k<`w5_CLTw8nzrjNJyi=
z7odL6Xx8btr{mqjxo%bc`E%sSZ#6!Yzt21Y+Z6fv^XyM|*G>1CpYGv-b<6%|k4M~<
zFx?cBCD4}d3lk+}N>jZh)NG|xc8t_)fDpWQ@Pxin<mUI$iHTHTV>9TAO?W>=*JT!F
zZfi=h=kI#*-FQh|DGO4a;QpE@1hU?cr7dXZlQSE<n}|jnl#nTMoG?*J2)S&;SupKQ
z#44!~rC@=4C?@0OX--plE9!CM?s+!q0~mywUO_ilaC@}yOnm9h%xvjW%c8)#3*9;}
z(iOJR80c5pyDYu|0zx;<Gf*(!MdpG^Dix7VUTd}4Z08_ywfbuBuz6<A>vO>3{h+*z
z!wVa(J%vU$Y*gir3rpEG;UNLsi`@PFd4EP3r6m~wfigR9)Vu~=7f!@Mg<l});~CAH
zq2GH$I%*Z}a*ew&<lbRiVPn(WFQ(jUu_xw)bw!NbU~-yxdh_GR;pJ;(gVApWlnlp<
z9n^F#D}2R|DQoY?NK_Lv5?e<0GM-W9z7eWnc1iuY@>vD{=;XTk<HrC?L|5`*T!Z98
zvCmHFWb_`5o_gE4W+eT9!eSYET=W_Xz!&P7i#~{Wdwl}Jev^Q|<9O*#Su^uARktcd
z%K`=q2(g`GX+<v_dXz2%G+Xc#+)r*XQyC`b%Klauce-JEx3w=XgpwsXQvYDRMY%c_
z!n-AN;n4p{$*PeiV9JPwm_~tw0|dLn*R0Ikzqvp^ZICO(x}pv&6%|$-5pGkU%AJ~;
z0{9cUTfqd@&dyF_;S}AX;Z+b`QYBRmh`~Ib(Tf36*vm*(#JyV&UzAw{;Z|17H|20w
zqqMCWB2I#|2Y%lzTprAAh@^jB{PZhgW{?u@?A2IJ&&EW-ApgRU1`?T?j^{G_HnbV1
z`XJCRNb&fQsKpZ~xlvi{%12{3BoA{SL>*RGR8h_pk6JJ>If&)w0S|O$MommiWZb9U
zXSBy$%v_h0i7e7<dPRMqW$X#5_dgd}MoT8K!Dy&Zz2BoCQX|50-$=$DQCp3!HHIxp
z06h%r=ct9wu~9!CWGgVYKTCIQw>ytnPGfvTJbbOhCU(^Q(x(X7XHA<zdU>X=DDOJi
z`UM~K3Z;s>_QgkEI{TKGRVK?s`yzxpM__8)X;78;KGUtCzBY2=X_<e~^au|3443yX
z<kD91fmQ@U9lHQTp(?6|=SwZq^6q3J0*_!!@yaBXLz&Qa$}HN>c4cYXcf-F!N&seQ
z4~Bod2Iszz(y}s#s;BK@rf4u85zIObJ;RqV0P3gvADKWDM!JymI~P;zg2>-1pvM(H
z@~xfqeN~WNulMk{nM({yg*XQ1y@X;jU~$sbzx4KjHB5=c|F!}Z08iFxsX`vJE5R-l
zB{_e+qv*r`COe}uMzMe3_k^T2wP2$Tg#nPGYau-146=@W%^hQ(=@}{vSz*(Z4lfRt
z4s*_Th%O$J^G7|b?4&HG-|(44(r(c7ngZ9lCh1+fsj2Ia&ex5M*E7}CGxp2yRHIk<
zs?6L8h@s+G#Bs`|7~<vPP!$lN81^GR)Ff<np<!a7RAf$dD$9mrMIy}J!NH|^vcJDS
z<|3r9un>pG|3{_R@TP%*!SL{KvZkHAec`jOPi`iI)lW)B!NZc#rKP3(eiDf^J#AWV
z`s9+FBZwfCl~wwr1Sl*jI#H~=VwWFc;R=K4@oZs}c17UFHZ>dj^jgv&hFl-TOVke5
z8PQ;w`7)k+aBFMpDYE84Uf92`TRQU0#%V%WgjG1_GPt<5pybi{LQcDk7c3_^Y;j42
zMs=NK4cV5ZwS2JJutlD`$PAVtPr0;5Tn|o*)Vucp)9E=KCPCou8P@Q`5L%D)#E|Hy
zs3@U3x|9s@MgVvi6(x9<72pR;E?wK1kkb>6VPX_~{QQ@k;uhFqI`eoVqtwMHIN)&$
z!VpNw=Z40{>7C2Duu#b_FRrm@6zJEu#luWqcmDorQhWclRsNcVFuT!{Cx(x83iRU^
z!oSR~NVR%?FuW-s&H0@G4lA<a@Yg4K(<vzgn@@WCQH|_2S26|&u;=`_c{Y?{IB@Oh
zV}_ZXjq9}T>+4fylMU*$7EjjXjPUgEc&jaFP@J^hU^AJL0$G}s<|-y=QP<SgE(*Lo
z>uPFF=}#|^*mM7*B}ars;!qiKL3aIb338E6cUv_k&npc%ke)Fy>j;Zd$%inT(iqC$
zqklySYMxJ@*Kjy+oj6bbfo`g%YGUJrh+iyx@SH^^*2qM-@0o=~tsC6N=4zTYu5?~~
z6yq~vQtPf^2mE<1H!LL(dpRbxrDoIcrjLgQpUl;SZX6D0JYpfCit^l=`JSpR_<hvb
zcIuZo;`~80&nxtAp+8lOEn=~wqmP|bZfAfYE9e7l!K-cwfjvHE?P7nub1yTQ)IN<0
zu*rnY=>irkpcpcBGYW6S4=g?hU9eLeKd`Apnk&Mbf7g@q=e8fUW#dGR8%KmI%DTc<
z;s!VD^l{q7#=vDE$ky5GJ3n6C=`#ZcKxm(ZqdoH1Ajt_Juw-As@aj$g-T8L0^H;%Z
zvYv0}NF|h&mb$yT9*(X&DM@hCf}e<wTn}I~kNGGUS5;a0PPa%hEtWT-NWa)vSnyG^
zseYoc?k)w&vvT4~EJu>{E)(#M#W*Edw<xhE-}JnvnUUycTM15(fK$Q-wJgAYsqIx&
zDZs6P39ZVLtGvw~)8mT_%oa!lGlxLY`&HZ7*{R5H-yZ{S5!+C@54jX^C8*-^<;ynv
zFJ5<A?`DCHIT*>hFQ<BdH7VI~?qkYcN%&08;X)1hD5hz5SyzCIK_JDB;;pE^za9vs
z+2AgbmSk*!_Bn+qeiw(hQBzkZv?pMSPDTj!*y=ACjn}xP7v32YJOB8xf)a#z$it61
zWH7>1RIfmP)q4`Fz;%^ny2D!hi1dQXA(jAn)xiYDlH#{!Zn4L(w8qj;)qrsQ^sm~w
zy1H<<+ePYG^`7Jhj2%(~pmbPQMEXu|nwM{sj}Bx4*r%25@c}gGju*OpSSA==2ml^j
zD9qL9d#Gi_b;)}V7GBe}_-P3yw#I$KaeRV>R`I8H*Vfh!ukIh#2!Jg2&*i`;o2Z%j
z9&z<Cf>Uw<1L7v!PxSPs%SRYe@|mG8w3iFJ#I9j#pV**N?m>t0o{&S;cTI)Zeyx53
zgY&p8)0b40KR$Hi&4E+|_Z7su5A!_3X_4>$eJ_-(Av^XQ5#G`i<!)10p?4)e6wiGS
z;cRHAsbSw}y;N4yt?qb52DHLh!C1o+yQDC~LSte1IGgk(j;1pbIrpt^aC(C-7wQw~
z9=D6Mxf|ziRz>{-Uc=iNW>23ccshc@^f5~-T1Q?1$zHkCcJ(K~FsSo!yLj2St4%cA
z+5CsbWEB`<wn~ZhfmA7|+!{NrPv=0|Ex|l>JH*Xo&{vlD^vx!;O2Fc{b%LNj<>{*R
z5R+=-y~Z2U36Ar8iMR!I9HphHd6>8SrtBc7lDy4Q30i#8q6ds?#w9xhM@D=!PbPu!
zW~MHt!ADDVRW`1wrpBH_RX)?))HG?Sn^tpaqVK!mq)^q>WBlgiWcu{z&W&T=x<6Xn
z+4wI%&M?2Z^?$TSUFj_h(@aD-PDD(8@SaJ)KXVEkgtD`ivF2f(WeCi(H%=yPXpjAM
z%o|e~DyA=iD4Be1niZ2Tc{tRIKy!W;QyQr|f&dlA#9!6x*mnAn!|Q+6%l!Q5e5N$s
zVkvgiMeqMA`8OBMPZjoQh4z2z%S(CnpQ=X6yMIl?z5i|+=zzcW<BZk+@+RRiy#<Wq
zb*g`D-ZDmI@fQ(?;Njx>Yti`m<(H3F5UZo;e?^e#(7Hk{=ra=i;1hIe`Jz_x&*YI^
z(BHH$$MpZoR6hGzE}7~<@KFre@*nYdGgPaQKb+A%m8Q3nPYg+p?)~4+jjPNjUMymN
zWm*60Dq;DW<*Dd%y$XEye`vJ)wZqG5n3e2*tZ>v|^xGlmbqdzg4sV*ahsbUBWB+{>
z9Prg$X=pPt@Muj&ROS1Osc{s=A!2jdvF!0DhC%=U7`#=Cy=`D_Zg%e8fS<3ekDEsv
z_38;&BXC+{YvpYxZ}Z#^`~f7y#3e+;Zi|RZ7)prAi%H0fON)p}$%~1tx8BMAe>%9q
bY@O`=|NkA*KZIWeI{+Fgx(`b4TZa7?h~I)p

literal 0
HcmV?d00001

diff --git a/doc/design/assistant/blog/day_7__bugfixes/profile2.png b/doc/design/assistant/blog/day_7__bugfixes/profile2.png
new file mode 100644
index 0000000000000000000000000000000000000000..4d487d02a2b664eee6edbf3fc5135732eac25364
GIT binary patch
literal 230937
zcmagG2{e`M+dgdAA(@g8Vkb!wl8~7sNk~HGBuPTZT&5&Rl4J@ANs=U)GKD0`l+05S
zGS4&Lu|4m*{_Fp(^{sFJhNnl{-uHc9=XIXPc^t=i1!-%Zq^ISeB_kuFKc%LkLq<lx
zA1MrIDDV#_M@nb>gUaIcNfojU(tn;8rH11tTOHIcIN_gaoBva-z9vsb=0kQ$MM>AK
zeYER}`MHzrqN7QsZ-g&Yo*&=o>VMr>fGW0|@(zny+Zl=Eu#bgi5=EnSkN3CTc|>4l
zHXN$_qU)bUpSRF`z3r)G^}nK#mBV%EEt&K}r-%%qEg~y!&f-pdrw8NnuTV9&G(A*g
zA}EpmJ8Q0}<+_DP<G1<W<+V~Wvj6_*$4wL^^ZD;Do>SA%k^RqmhRFTm#%Vi`D3@On
zW&iHnLh;|*3l66?4KM9_>*Taelq}E0K**)$=^@tO%LNB1Hou2(=5Bf4{CL-hgVf7H
z-UTvtvQ-M!;DNE+9xGAyCX?;|UBJ+WuW}*-k31cvPX{@rkJ;Ta^LK5d!*93zcd_ET
zXai!#1v@!=`ON?4iamV(uPfd%)WXTlZFlu*n0m_pe(H1TU`67+;NWdEG*RRCJHyS%
zCP#8Ue0cES!KB-#;kPuKpIz^N+0qh!!gWcDk}b|9>l_HJGAi<zbJizp-r-Q0<L`>C
zQ2|rwWyi?=_u-NGl9T;+X#_b%b2763ZdHkqNs796;jgpwn2Su9+OzTdt9x2)B?w9m
zQl0jl`Q;W_c$QWD4MQt?Uf#?%b}8KLUuK?_yTU`;tuGu|<3tEh?wfL>qw*)->#}o|
z;<C&2Y)sM?VDVKXW2+r-jMm_vyw4P*!W-r$!`5V%Ti9hM#Omp7>`r<l9!#ZVy$dgO
z(%ReG|Ne*zCf=*HI-b<PPWQLCGw;W+bAhpNeQ9jOReSrBiP{%0UNki|Em;l{Vy&4Q
zX}KX~Y-=kNTp2U&(nIc1RGg7<hR8&qrtbNBJXz<et7~q9H9@~)%%!kvJSvJ^K0%8&
zY<YQE_2kLx60sd)R7w;Aszj#8j~^QdJ#8B1;^aJd@ZiY5f69s4Q&UrEX=z^aJb~q1
z%kC@7%d;N0bah!G)Z@l$s7TMO{<<%D=|o0K%D`NUS!QNtZpRok1J~r#RQ1=dc_Q}l
zF|o1utrtm2mo8nh*ZUi5U#!IRC#S`9+qP{h&04cdg9#gp{h`s((V4}||JJsX(b3U;
zn)_vR?bn;78nboBSjPO@Ys)1YYxZ%P)D~2+wZGciUpLz*EcW`R#(TVe@!~~Zo<W9Q
zZ0+B^zKen7+js2nC(^{$&d<+VWf_c(jm1jZyGU`_N^l02k9FkMwX`fW>zkQmSyW~u
zEcBN7$Hm1>e41g9+Oru7-d>2GqS~m#{XHA&l72+Z)a-ZfM0t66<>l9l>BtHS3hoC7
zZztrRAS080?cKj4=i|p82?`syhtPZXqQ+Hwc0EtHZ6RMbCVQvM{LkQE$@=n0@4ZTk
zrP(H}lEvS_Z{EDYS}Dxd9~X|i=HTG4GC$@~bbIhe9F5=e25aV^JH)TSBE>`f{WJ3&
z_JM(cdubXwI#vcE&A5*_^2y7a3b3rVyk4JY+fEAW=RNdvWaBStB1K$XUH8&3v$0(f
zi>|kJwzGTNU_Cl9QTO$$)a_L_d;82vi?r9TV<hdlLsVmD9RieZ^nDJ<$~sI?^15{^
zQrJX2QCl-!cGs?5Y0WkxBO@ll`fhG+R#q<~BO^6aJF>6TW!K4j&JLZ8)==eR&VK*?
z^XJc#ZnAzv$NW!k-@eVx4p-q#c}aTl(loZVwl*|`MMP|oXt1`m<>KOc5E8N_*N4Wh
zb!>iZWg+nHUH<+1!>j+?zkk1>p&>6X@9S5!5Y?vER)O$p3ENilECX6vT0Z8Wnt|U_
zZu$B7Uh*YrX~X}T)3H#-!jcja64KJ`*5a%?cLr5j<aWd*B=B%>s1un=cOWgWu(8Q-
zJ@oPM>FhM74RDOrZ|!q<ChPt_H8rr-D)Pyb`eA1?v!16<pSHIfhNxmM>zq5MwAkmE
zUyOCC;_?2JoLo^;b8yd|vW^Z<OUvYsA6*<A9+jCVzkK<nveNyB*LY|C`uc4;s_;jT
zp6jKj>DuV&>6w|C9Y0>~w`ChHoOkcubLY<0B`7F}ikfG)eJ(Fo`a$PM#I@sP?oSh0
zvoB1|=GrwUCnx-}l9H0O^{X=TSLx|a`Nn(p>^XMq81}SXu2E703k%DuW*f2S@8+VT
zE-NCpN)j8aDSQ=Eo60hE1#kX%cFc2Od~AID;lqc>!M#N8(5n8acnd{W*M(mhMwAp3
zrBise`%XXo@ZrPPfoUUZGDX~ZbGm+p-ob=Av-g%k`=4*wps>n5cKGn&W5?VZ!!^a_
z<+~djKM&4a7Q1li(q8{EH4P07b@k<pjXRqu^9+)D;XokIZK+$!;-OXL=AzBb&6Jds
z*tu9Ii>$@Pss31r>y6gpNHP{#Q5yWIO~;1&um#P$rYf<_%F3uWCm(X16^s~Z$rKR~
z5D*lkrK9^`AawlraW-LN?KE9ZNxPrJ&I#V@`DNy!v9&IRMepCgM`jsLP0-ZPu(h-6
zF7fuha^;Gx?VB?5RzxPUNpwO&-QbME`r@S=!y>yb={QZ-KVP@A&_;xZ_ow;S47`5*
z`rq*IRz^mIU8-iBprD|~R3+Qqy?aldJSk%O>7H`p-`d!PZqJFFoSc;8Wb>@n7cY3j
z)Mh8k8Dnd$!mBNF3~Q~jD=l_$a;}UQPJH|J4N-GhtgSMb&CGjk?!f~(f)cU<J=Jjs
zhj+SyhXe#3)eLwqHznB3@FKlu=v~Wh6JiZUD(M)*UAE@hCsbP^R$gah$ld(+b7Ns+
z&HKoe9|UqAW8sPMaZOE4hOJwN$H(OzdP^4<-K?#xPoAu5NIGeDYpxk_O;B<fZN2gL
z`>sUoA;)~dg9njZpB^%L8WGXl)3c$lF{6MdURzt6uAf=#GG?fxRQ6!kk#`28(MPU0
zIy!QDj%Gc7{`|*}AL0A8JSfP*)O2-q#jpJm5{&Rzp1m4bvy+9zQX=*QZ$rM*;7^;m
zmuF&~rMpgx6p4$9K6>`dRxBD-Ls~}0zF~4^u&%@Q<M;31jgn=3gOBrv@8#uPzot=X
zm0eR)gSeQPnQ60?;0`s*bGWFgN=3tIm+}66<Cx3I6DJNteA|2Sp&H-g>m47@tg<O4
zYG1y58K2kl$$h5Qf-G9YWq!16e%?i%w6aEqhCkxvR=(~HePfvO@8PO~GASJYkfQNL
zM#dPnt#P5tb$kOu;6Xt_tTrN$#?L^AHQ!j1j~P2HbhivE5)mh-%-p(0X3NOjatNp7
z%j9Gt4R2&krddgRWMrzYV4UU^>^+1$!V4So#EHr;A)LDzs)mM!kkj^t%2E_Os`>Wq
z?%lgcf9j`CdwO_q-(Kv)3NhXEns2+}H27n{K??t0<UIUXk;u-@&J<jUA{Omd9;lq?
z=kH&Kn?M;z*L{sbm1WS`(y~8HEm>!{v{cc><zutW&L9<pzlN4pmANQGU{X<$i4ZG7
zw5qZ)t@+=*do;d^^{uUL|9+;mn0g+<UbU4d*;rp07#P6S()fw8KbW1JMSNgI4Gda4
zJH1v~b_G`o8@%hS2-<<nDI?P{;E2_IuKfy+Ojb%NFDa>ivacL@B<`3KzaP;e%Rn$f
zes!{Z`}XZByjibasb#j<w|_VwE9>Rvw)iz{Z_llTuFia?j*br3vG%#|N9vN3lksT?
zBt2c-A!liV(s!$D10mH!ZIPnc$6a<CLrJ0B?tj8?QDV_vqpewAzI>USoP7SA7+#&M
zEg&0#o!@)@IFm}6ZcOdpPoF;FIggKzpG(y=DY<>C^8QXX5mO-%5fVB`dhvpbp(?lM
zc1L&j?GZ`#A-x24vZ&g>NaaPI3%oSH9rG>4+7PmOnWnp0SZ2-icX$j$=s)C9SVy(r
zE#o4DZ7(h^e&E0XLBVfF)Sb5J3LZt;8~7ICn9t>3_OqpBFO8VE_=hWX@h5^=Yom_@
zs_}74JHN`v$jHw>CL^<QcYju!?e5*XC1MZB$awyGa{&n?ARu66VWO_4W^Z`4>(B=C
zCe|bX4VgHOwI4-siin7ain^zogp7Li>Tm@GI~~8MXnjo$l7XkECuhhP)Xb@=8w4dF
zjNiY1D=RCTy7dJ-dc+i<d{Hd=fohUr2G!L)<mBW>tiIp7f1fwJ`sU4>xQKWsl%vXu
zibvI!5$ZRmexJxOloJzcY-k|28`w^mnx2l4^PFE_TftK8*s(+Zt#MmJLzd@)9n&Mr
z%a_j>XHf@N{v90jo~f18NprTeyrZ00QCYbw<jeTDU69I)rs2k>rVB#9K3?y@Mg4Ki
zZ?G2U2vJXIw8?pIAY^ZEFBn0q7nPQgaXGsU;Db8x2dDifU)3aFTR&o0SQrWdii!~H
zH59kEZ|xc@f7;|AA&EuPDLtyMug8W;OiX<GlvTSt;-J1xnyz%*_~4+VxHw;AO;b}7
zn~;Gbe|Wy}TV27f67Le7G{WvWAcYGTF4#&GW@TlirdHv$T3XnYm>2?gaB>#jTABa&
z@#FNgqY$gil^@S0CmmR5k4j5RPvro2S65eOTh&T?Exzj*GtII%0p!XWe6z3%<rry_
z%D?Z|1pVaniIXQi-QAB$Nc?JP0g(Ll>lbn);s7_!LYrgT_8yUI^sE9PGUUrC%99L%
zm%O~VKJh%$Ox55Y85%MGnjGt_5HTypwqk!E`_=M2uBa(hOT;+OVXQr;ySw}OgN`vh
z!HAtZcj~3@RC@H`gSfZ1H$lnI&ksr2!oq?;;j6|cC?KH7l>Fht&jH8UI2krN`mk!t
zd}D5Q_91uG$eN?_^0yIIqRnWt*h9V?bNVY}Qt+f^fNIN@>Vau3g*9huYXNELWxI`X
zQiiOj+(Jd>8lb^{Da*i8Y?shOVJ4b9<MBh^aD&)oWo1ePCG0t@aHrh@mL=_6DnMPd
zhMoXRe2OyG(m;GiU^x<1b{pM8JV`V#<Gt0E@4M`B+fW8<y}XS1!{g*{aj;|?W*|hR
z<9-Y{ZYB7k&R|#KqRyBc-w~pEQdJco27#4hNU!q`Me@?6q&8b%mcG6|V%?vFjn)0!
zp-6;DNlAFDIwPo*%89)*OYy!8k5(xG2}C!@JNdgOf6oHZ&(HIcny>QDpRpi{l1I2h
z6Y?}_TU*(&kTXlYvO=ueH1yeb?II^93$3CYF$6mL=Pd1CMmDauop3h282~Cn?=&AX
zVi?gVoR^s?5?DSZyTw;=64gdJ&fnjk!nd@egVXtKU_ij(Xbps+PMY0Xx49^Ld?aIF
zd33E+U^$Q&R_vY%ubYm7LP^@p=j#$3_4Q2mRR4{P;E!eg)NQsOOG*^J?%2yjgElRg
zO@wM7L^Y|_D*f$SQ?#WSM*?u0h8dctNiWV_yTa7?P%sC98@<;*WoAxH57fv7;8{62
zWj9!>F!9OCauLW-oy>b_{L9>)I_=)I3;DrWdbe@Hy?gggo%>)S45W_zMs|@-ZDC<*
zihSb$@?lF$q-s*xf26>;6gyexA-(kG?EBkV?+&vD6n*-{ykm#b#w%?B>`(nnQ#qGW
z1H2p@M8m7mJ+K8=mb~CVJE+EoT`x+}>zI#Dv*6|kveY|+H$X;ed|vWB1CAjNAGVLp
zpBgFNL38KNpFeo!*xo;X>LzNtP5rL?_wOI}($J7K9o0D_qm{LV9z0pRvJBp!vs_<a
zPiuC_H-6s1{s{3O@vW|I!X<``m$&{r4-=D5RX>pI-|x}>#IMPRSRACD)eKA<+eFrE
z`Ir+^P)orOxR*JI^b}aZUyO|%Vxh&`wFRCu+sp}Fb1H9P2vFW0R1s8ZD-m1X7Zr1r
z@-LZ2T>s&%Q3Tm3+jEg*j`_x_NjEmB111UdDF}MzAi~>2d1CQgoT*J|I%(bRgS(4N
zy@OL-@{IvfWn4zx=9=}_*4B>WDJUy9Ha5}_K8Ni+iFCtHMdmDh3%I5Cb+`1(6YD+R
z<PqxoB5Mw?+#ftaeO$4vt?hX;(P7IG)lvy}SIYo_O%mj#AF9Q6R#q2)uPg()@$ABa
z0xBvheiuG1<)jA1cxh1-jQV=?5~NGv4YST}EA@ye@hd6uHaCB6ER5m<oOL8xqb1W!
zKfPIAUfw`x{#(RB)Gag<ykW22zjyrdVAr|G(eKsO$GjFD^z~aBQ%*NEHUcQ2CL#ko
z6*03DWk>7+^x;;3%DU|AuU(5Zq!x=F?e9NlW+oD$zJ<cK)=I{GI=R8xINxz#Ox#yJ
z#qV;kED~7hs_!WZN=mRDW@ZV-!h??aV$p9B6U$m!Ty2uKGc%*3$TuFxm%7WwtEUv)
zUi0wwE=fo*Q&Ca5crnpH=<m#u0LyE@9X{qW1wsZw68!vDRS$P}b#-a*BgQ0-9=)2=
ze&-IMzQr!f;7e82F|LOV)<VL<RIcA8j}w`21;uOg9lpNgqOVW^58q%VN8Dg1^W0v%
zNKksCmtJXcA<H5_k@#FE%~rzm-_^4MPeMaOO*2bwPHsh;#kX(Yp$qTtl=q<n2jI^!
z%rY3QXgeUla=+U0N37(8i)jv4z|W7Ou0#<q)yZk*d-Re0RAgKX`$a?;SKI6BeTZsW
zTA^xu_wU^U(}TJKa_p{%_$H%JvIRZ*{m#x#lquk>FSZi?=Y7OEYJbw-xFPjSgMUYm
zN-uw-6IW=}5q7%V4wJKIm55BZOEmuo<DsEf)t1XAj&7$Rps=E7fiO6&rPX3B9>}o!
zv$^Q=9@mBOF6=i>30rn9E?F!vo+;9rTJ6HuZ{L=uYebZawav}Vv9XnuP&n>Acu-+3
z3VKR~7a%K6ga2T}x9)D!6rHVBG)QvUZL(rwza6B|b)m(~1~z>5j4MUQeRik;^~PtP
z`owcQi+AtdA;tSsGyaG=oRprPo|bmC;l&9&+r~2vii(OL4@^wD`pN_QfB#lhRmBJO
zkBx<t_f5~tkPvHsRcLy%ji{$mYLl<-+aM8Rb@lrR2|dNPR!Vsjkr|NZKsd3`1}G;=
z#r-G`WUQ*Hsu^$$Q*$1<`i6yeAK+KZTazB|jWzV#->r_&H1h8RONKn~N9=5xt~keT
zE-tT;qtZ8|xM%|&tMTE%?dUPzaZxnt)vH&CcXW4gnrxtn%FJ<fK=N0`+mq`@=4(OZ
zfDi%#JQ`a|py&f^21)aq<DBHr`g(12NwTt?9UVq`dJ;~5zXvr@fq@~?6znx8bI>Q{
z!&pfkDRgYUloGKaH3PtBz8bFl;agef$*+AU(H4@Dfp_j`d{XG2a>LFv-=~ct<X`qE
zBH|`M=-ao#-rgI%z2@5Nvs^|(tOTXf&l`Xn$%Wc!KPxI!czAeZxf7zJkAVZy)BDxh
ziq;Q#+jFAmBp<Vpkr8g;bHFy#5TvH6FJC-7JyUdslgShXSboGD4OZjxyEC!th?S68
zv9SOPZW^_EbaWI=xcB<fpe%Qttpu7f-?>wl#dfKMu?49h)!n#pqfUNh^x<xq<&~8I
zM|TH@Nu-sv)z#8?N^=oGpz*;OKw$6TW)cOFWdKIA%-pv1-9;=U_$<nBZD4i~I$)t`
z1JE-Ap%YIBDiVcEKed{R8W(#lwdY)82rLKD((&;+He0RL#;}&Rv_r2CQUFItad9y~
zFWIgoY_om)0#uVwby22&8QEXQH%xRFF$DT665kl-Gj|G~R8g_Cv}D=2^QgFZUf1~1
zYrno)iiz&PQwN@FnVH^#gv!U)JGBVt$p(ZynBdLL!O=J}2T-|<Rfz0@mL%crd<D(@
zngPxB58DEir<PXRvaf`OgzTcDnoQ<nMi0crH>EY(QnEe=wy!ShQdQ|2;}jiGX8Bi}
zUS7zy>RSGd-(#WOqO*a@mYXZdeh9RZNXhE-{8$GgmsGE_^j5;>*XPq8hlktW!u|b1
zhc?`}kD#P{{CKWy8%5+Mb^lz30R;bgN8L2>-h+odc{loTt>dS1TXU|l#nw{Q6lsYe
z0!&QC1_uY7rK>F+k<JHdA_1N@rXx$-zU6h<6`3+hWKB;^MHlD>n`R=&&`zSG(-q9g
z&yQA3T3TG}d~<Mtb=0NMSeOS;DcpKu^h-H-Y>jGqdiu*^(M3f?*5d6|Rn&pyr&4q>
z^hWyov46)Lq(G}jRWq@%xh~j^BCTS@t1UJ7XMTB78fEAK#!E<`^&=I8yT<qxKwU6e
zdg&4BDIY(4c=F^)a!QKa`eOgNI^-FU2tur<(Wh3(qWcn+lCsV*yyZoD*`>CF{{sKQ
z$IKgslr|cD#`Cy&$5DIxiH-|>gY&q?11z+G<;WiR1-mT!mg|pe2AG2?EV2kxRI~&?
zqbIi3)^5Wok)-Y%1Q^&?D*x?FOk@-5d%&5-9=q}Tj!v4_@^I>Y?qr>`_<_aVL*s`^
zxBC<-3rB9OO?Z3%jlRMvWZ+X~4(9r%bXT%1JqzuLq=r)KQu?!LKLOqAGR;#W&G3Ad
zmY2I<oLtH+?Q_^Max80`w?#NsAJC6oH7~ui^y}E4hdXEpiP}<GkIk1>L3R|OQX%NT
z`xh5?TV!><X=kAwxSNU4i9USki^yvU+JJ(!mLUoM`(`$c&5L6I?A~z)WveG<_<c!?
zFZHhF+ysgkL4N+fJR6Huj0&qvNDbS!pS^G)AJo@72m0BQ&|R#)M@_A-Ol++5Y&;AK
z3VQIs_S!Wg^wb_6%g*{^^57#N|0L(LZt{9v^bUkxy9+rs&5!q;E)~1SPDk~oO`$8o
z&#q>9ZbU!BaKL?R(rxwU*3SC4ojg3=^P?9Q6*h&T63WG!p1GiG-6Wkt{W7~I7(-P3
z^LzjM)awqVyEhwRn*Wy?_1$T4?t$v1bLW~s2K*m|21GX}E2~6TPM&@lS#Jx-*%G^c
z!A+1v9LlX9nREEuok=CqnR$}P1o(|&l3K{S`Bh4ctRNJ01yc)I7X+oK|9>?wia|2P
zrn&(~uv57m^tpb^nOqEk)s`=G(gav+3Px~ivw@eg@wc3<-)=F3x}Y9>AkD>)-8MQf
z5TIIKtUJ_A3G(R&sU1{Bq$X<H8Gx7_p7RJS_bu-O6B4Zv?`A*fQg~B3uF|5<L5iL3
zOP|BgoJUdv{&LDqHbix1db*(RDw+b&f^D`y+3G3igmXKti$$~0Rwh42HS5&&3zXtw
zprbktrq6jfx$bCT7l{1_s{IxI*5WY;dKv<nk!BmPlQjdpBqSV%OwZps<^s-9oCD3P
z)DbHGXt$t(!ooR^Tbi0buA81uZMrHEn`I#6cAxsre?pIlh*`E3y{}@__&*4XYkhR|
z^m7Xfu^Rjka-5}2gxR=5PclK)N=Z$1%I^&7kuSk_>j<y_3!$@tTIKqB8m*hH?Sq;D
zKWTq%9u(H>Ht<oAk!;W#ILdJoNhAtE=`d<~ijLCZ$eNU98+t0rAq)KcT!~DlU9M_U
z!^m9xtF3|MhuI$lxw2`dp37`OS`m(v$ywRzwU?8QD!9^5HL2QCEKakk&p|lyG>OUc
zNNqaB$4n~VcJhT?!eMF<G~_}GYWa_s?4~oCfFK8Uq*5Q$X=~OcNg-TUF%U?~=|~`~
zOt6XgDV6_43-Y9fMTjhRZSPNjdgvODkB`UJa_Ii#e(KaIKr6^7$gBw-hJ{_X0fp!}
zB>)=1yp46{pG$B4H@CcFzov>76UqTI^E9|>EM}0(`%6_1f%`yeL9N8cX(wu<I0dDS
zO-y)$o04S=g$8o(9$0p$Le5fLhYlUeELry;VG{Lk=d|R23w8#UlM6Qe`ZfP~n@B}P
z#rK$_BiQzVAS>OhpyB{+h!ijWo)>weleP*CD$}G;BJJ*iWO}oqzWze%rO@HI<>9y6
zzy<J}y>ewRXvcoEC)uDVL8N(({L1ho{p*#w?jldfGNrkV_Ja;m$ax7K{|<nHO|=<!
zmZqknLX%@?XjmGChJB)B<974w^I&(7#3qVY#(R5ve^N8h)87J>1kE@&C<uhhQm;Rw
z3h(yCaOK2BP=I1$VkmkEx8~c>3#MJ#3vk@CvF>VYYz#7H(a{W0AYdDt>=w`vi;Ig_
z@WzTATG$b3J3(&+GV*li-MF-=M0~3eDe3I$LQtL;1gm%JsQ3CR8qPyTAB_u~tB0LE
zxIsvv6NA(U-c*hn5ZV=jjYZ}CsHiC5orNB6Z)@uzO_Ph(yzIJNCg>3gUBS4I$Af;S
z-{u7@1b&{>;O$^$M%i|q{&R{p;JsBX$E1F6B}o67A2Jgl(Du++h_e6J8E#bXPk_kE
zbIkEiYQk+tDK0J9sfy&L@wV*2pK0d~>b+?NtVOs98|Q)4+L%pM82I})Ue>+w+?&Ee
zPXHM}cNW^qXm<d7jdJZwioM*yJVRs|a*&c=`m=+JVer7j#KgwG^h~?<4_jAlMA^}}
zK|T20-%n3f4*Fye?KMDhzeAo$q06n6v0UuMw)dBT1tGfxpyBdbdauT}+|jen&qNdN
zHGK*wDqZA_YSOV=%g#DFjiB7k#UNoY5daSXNm6M1)KVI;((7p1;_c<cIo1N#ib0=&
z!oxm_P)(ZR>MZfzz+L?UdG5Wj4giSDP{=HrZwHCQFE>w8(xBNwm6!$<85`?5+ByZ@
zms{4Ye!%h8Y{N+?Ezo$5affa!k7Rl;5AO$1fAU0pst<r0dIu=8rKKfv@p5Q!;^IHg
zl>#t=HfhpQh?BJMra$P7Jsl_G`uFc&EU%N7*J?&?x5sq#e$Z``(4ZrqK82E;j$Ro3
z%Nn+0l!ld+6}U;O?EJTH#}P#z+H7}d<>1mmUxMPkTK#w*8s?5%d++`bNsz|!U72;a
zXh5F<(=I~u0rH8hExr(q9i3rXB)xxsVBMg?%4l{<N=p1Q*1+-xC@-kDK;C|PYOb}s
zJ(bc3ZCX%40lDyvSqbPP<4<lkY{(p-yMF!pb#-+WEF}<)j}I9{Z5QEw2dNziw{R7p
zPSsN!!Q<`O(-*Wqp2!>o_VU}0AFM$t;ma*Ze(aKDCEymvyNg!hT)PvShEIlaHxD}_
zbk3YPbArio=5K9}*UTBv#J6wX2KYm_D%s-|{_NSaM~_6s#dQr03oNT2pCb3EwtStQ
zUg*$ALFGTSuwa&Jx0^du!E+wG)EPB3a6O0uzQ-VG1C;lKsezGzuI%pa4wZ#F)E)x!
zn>V_G5r7eLa&n+NjgMy;7#kS8Y8nP|gjT!cwO%o07Nnx1uOCSK3N~vyA<HmBVRiC2
zaJr!(N3_N~i8aIvyi-n_Ex<ljBDKM~S1TkW1jvyi1c03nA1*4&#HBA7f!zUSM(I(`
zwH7LBYJct5ko}8`O;ekI)FFF-UYgWfLM)lxUK%(a$bg!_8zzO#57m*v*F48iMp_y@
z2<SoovM7Ut{$&n`bF{tU9B}}qU@P~ZRb-m=L80wE&h203BeNcqumrNlAjf9s;yj2$
zTqz&(R<G+wsMvlnF&qRXq(!{!o?et`2IF_-d(?JL&TT)MnwwGEAUfq3j{S&}F>@b?
zNVvUxia$K8`p?qLAX1V)9S>lV6XXzN9gt4$Uj$$)K!(-P(c$)9y#Xq7Yz#19eYvIN
zV{R@onI~^Fwirlh)CpvUD9uzSDWK-bOz*YyqN2FEK{TFZvt>{!!>e_*wd*@OpFMd3
zG94BUPzVq=m1wnXY;0UyByjg`^jM3IF%%nwdr8~JRP=gy=7<)NPm>g2L+9p5Nd$?|
z;KBv>$=<RIqg-L5j}NLXd1)L``;f!Gf7d{Hzzv}MtMfe$%H8#xM6!EeW20X}1&`LS
zFPi(6%zxaKKr$$N{;V8c{Uj>tm0o)4I)e3Ab2B(Yt1DM7iAI5T#Xf)z;L$h^O%?fr
zf`S6@4h;em0reEY$HhSXXVP~oCGZh{IKWd~G!#L|aNw<eSY;O$7NQL@HRWE^P)cfu
zuZv4M87j^7(0%6b)&P9%ED8{WEeG$Q^1gd2zmwZ&fTFbpv;^ZpHy${!m4?RPqb;0C
z9PI1>2cTm*|AOrl=b*Q1Lg{;FV5_6Uj4rj$0WccHB0i>qR0ncP)(#yz)@GA4j)&;%
zJll39;e47d<f@832O`<4*RQ1=|EL)n##CB>gkT7ybmkt#8<Fl2=(5}sAPFGf)G2I`
z8lE#}YDY3lehkilQsm&^K$x!2WqJqPx#Jf9L^BoW0{WU`ekV%fHa1}|6esNXxW!@H
z978Zao|C;w@E`DpUpRmMyrJPT=+(V6)8#-Lt21?FWo6)G@UDIP_Mw-z#bbpB03AIC
zCnsDA`<SZ{8zfiCojZ3Rx{bAE2Ws%ItgPstKaVZAhE_=H%$cLn8mJ>%^7sK%!Joj3
zft!s(i;evM(Y|Ngr4Y?$Y)lLZB9Of;GbeRk=*6@JkYm9~PW=1l0dX{S#e@;Cx{8#;
z;nngXQ%uo0udjb3`a6i?NA8a3ghh=@ZjSsKjQ6x#Tb}Fg?#^{;$3+1=Ymq_s6o^pA
zrb0KyX6AJf6c0mS)37WG*y+>o2u()<1_Uvt>ZGOXWyC0W-@bWsZl+Fwk)hH012jRu
ziQSW3XZXV*<|cnKla7-IZh)SOjds8)x1-j|$<wp2!CFI2jqJ!W92<vNw+%ggTy1&c
z#0k=^!9FA%ho?)DksNx_T%ef-KNWwMk%7Uq!1;ibRFoPY10$o>^}@)=7Ept*IiZCH
z;Dv~*lLiYzZmxc66G>w7^hCrze@;Xmatv>^okx2GwM+Z#*~3%Uwuv7j63N7)6^TCl
zJ!ut(08zl#A3b^$mIXuDHIO7d=Kj&w_%H?lcxm#7qYLH;`DoV#M*bIQuN0jNKvZDZ
zkp<aUS^YR~pfM~mRgjjp5$6Ec|3rPDxA%Fq<zw}f9h79ybpDcYDctsQc7CG5dk7*i
z3CM)Wp*6pa&KN!s<Q;$SmM2eG2ud+AG5FzrG%HQRA8p$lvn%OGU2rp=Kq?4b%@iFt
zh7=WjuzP|l@pK3jN@(u+m^nh=)p^}uU2py2ilu*fpA^?ah@HWeVmD|-!mFRjxQ^eY
z=ftxJu3Sd(#FKaw6I0+i(GBzs5y?>K>Bo-}!IkgbrY!P}O;I(tx#OQbL*2n!;=;qT
z@pEjg_m7cg*|@kmySv|N3m_{gC2B()0(J@qB`lvXG2DV2vUTfL5C^0JKbF%1S}XfZ
zti;mFiq`01kO#<xwh}AIrU$9~hoSaoU(wRiVhm7jL$v`0VmoA5VJVgg;bwVu7;@R8
zM~_eguur{L`_X!D*Gr#6?;tEJtjhEU78sBoKmc=da~bLBC?T!jL9yA&ywJBS{0Y}W
z7USVbfY%{dg_l3v9f409Fb$d(2B0j1RRB!qn>Y8+H1_oLw6-n+2><!}7veZDJ8D{x
z3Q*sXu8CX7VG07MF!?ZN#PNs2P8ePL7k7;!S~B^0+tsUAY5YKUAr-z%P3^HFBm4Dl
z^4TxQAaEbfEH36je*PV_A0%056(GQ8K$2uKGXJu7ZMLkz`<R1dd*rzot^kF($-*(#
zF*c9dLrKlR$Ip+nt2r7wGe2)ya$7D)g`yI%@sL|C29`n=7J!R?E`_+5MM3K9tIak!
znyK(ac`OY?D#bxHEHg(%Hbz$L7?a1&RaX9t^aF|*76@2r;9?=g7Q`OTk8#zOe+LHg
zjfKTI0QR9E%CF5ffdv&25dke+)vpvRz(NZ<gtfR$P7JcY6c_lkmKMpZL(i)T6yzUL
z^7EI#<RWEbG2X3gJoJaia#&s-SbQF?DD*s_1$*A1UxgJ5t{gxvbTwQIsqf!U15l!&
zEWb++j0zr;gvp(qoiAS8<MtJM`<#vr?Y3>8NfYXj+5U}=sw6e&rQiG=jom;`<*%A_
zq1X$=Ea;Z>j0|u__Qgvt2h;Er1X$D^9mUwAD4XWPw(gjOc|=j6j2>b;Rt-%Q<c-Nm
z)T}tE8^1g3OU6b=vD%1B-Y_V-u)Ar-{L)BjKu@i~PZ_+|{UNAi+3Bx)A-ig(&SX__
zlZ++6IIJS3T)TH43R6Q9iO2xm5A)ry96n1u1u87+^}~=5lu$Y<_<zwV!-Iwd`t>Uf
z9_Gj#?iigNBHI4bl&Yd)X+`%fWLj3%r;(8hK+)?c2*`Q2N3*H~SiV)%aiFrn8mDs=
z8YUi*hev@TvDZNgNk6jMlERlPKzSG4T_9ZEuvXaZK=-t_b1*T9Uirc0a2{3?6978X
z$jdcPYh#XXqkA{IumFRePu%yj0=iJvU>%5z)Q2_>Im0l6o0IbhM+hisKqeFyV_{ct
z=IFnlFM&zR&OQPw885E|J_y{qW~$bLCyyU-h#T2gaY9E?k!<mE4AcwM+s?*DW>(g}
zrxsUlin7z?UE9x0>Q|9rVQt8rQIzFoESLw@)l85#F*SWy-e(HS)v1HDa3ablgc8+&
zr_Y{kKys|MoIX+~3(M0{j@k+WC$wa{vh#uw+5&{FuQXG4bRL3J3E~=Uh$<Tk3z}2#
z$DKVrB@iFrD4hG(j8<B58`(PpA+<wKYX(xa5{liXUZ^Iy55~FjXY5rb?erJAg1dQm
zs3o~`tsP+%IC~ZpA9UhQr2AUdvv+Q9LwVQ<6mjd;E!24|9il}i?L%>~ysWG&i0_%R
ze##KnSgHIk<l1$Ccph^008$~b*PtDc!;qvxLPP!IO+d9q*1()3W8eL$3jVO)mBFBI
zRg<=dR#9)+;_F!-RLAhN$1u;K4<;yxdDsKrt(-1gXv4qqve0fP+$ih<lTZyM60GwF
zq9LRLl=%!@L9KY%CH(1n_ot=12Vc(3&VKm#5nXI`xbrw1uI<+{VMhWzOGj01DYk`z
zeCT`pY-W1X@H5T*ku`BqKOPck0+fN!z)Ja-EiNx(WdtMCVXJxkSjW(?y{89GNQmTi
zcH_xA%Svr10a}P>X_c6uR(|0P4-e<@7)rz@{r%fwQ#%=+m{7QC;IF|C5DvbB8_Bt7
zp&ROHtZr#j(OF|-FKDn-{)f>vKr2BS1`z}kor|-x&ts3G?w%eqXex6a41xVui9<T*
zo*+I0o8FNFSiutP*L(&E8-GS_dJxV_gH<e(5^;-wBBKOW*w);fNTZ28$K$;^g$jo*
z<yhPgtizUVtakze&irr8HrwFpLcsBz5G(yt6jZ(c`IQjmL=7&@jZA2ZkiN|h@-bK2
z<@Pv?6?0N#+oR`w4#N&!O-*pW9LtF^%@jc_2n$1G0J%eTZR%K@CO}Wtks3>}3mJOc
zp^{VUoB_(<*-F;N5YT6d6OkJHEnt~uXMX~Yoj-pdLOsXO#Ml^-L?;#w!|x*cIS~ud
zJ389h#4t7BNPHQ7EDXcTRLxJ|Yav$J0I?gqzv*L*O-*n2ecn=JngHD`KAyqKTG5pY
zT>vQi?K^j(H;Rpo#nXoZ3bhLx3WQ7r8Ig|<OYE~MOHjI_yeG0|H#au~g<d-tH0t^s
z@IZ@9dw%|8;pPTR)_-F_uGf5&BLrTC0Y~4Vp7Nfa1Qp&Bs;YkdUh?qWzWemaI8hs+
z6Ig!M$VdjRFW4Kk0&l?AXJix$;n~AOI=B)$o;m0bkhoyP{i^;m1$(G&^@0BVU6N91
z0kxH6WF2;<@q4xD*5eLkV`3`ppF+k{O(N%s0WM^xyNh3o$%4NGmRes$hr%w_;7Xeu
zzr(cvqi9dReNzvwR^ek-dfli3UFf?e11&8Do0$O1^pY27j_fvA)iRofk*P^VHD2}<
zk?E<>1+gj0ufxuQEcfAb0xSp6fUxNATNAVeIuV*>dXA&GL;D_i>;!&ve2#F!!UF9_
zbSXryTwhlgT4{l}3JQ*+XJB}(D_FHb&d_cv0bTcoVWlqewndiD>H9<)SR57%TwGi<
zG`@qN1RDV%3H;zIT|xG6lG0#z9sZs)-S=&_TnrdC03A1Yy4E7gA-@w>6*S|6=15&#
z-Qv<EpmO^gh8cREslTX-;5S933{x{k)daOvVcZi0oP>M>S^(k#{3c~jjuDjL7HF{k
z0PBSmmw}L8qP7oRN6@88;;F5pPkV<=;6Iayt+mM!i`L){ZE0${BoPY@39V3OCiT^|
z9VPjOMn<9Ba)7naCeVlop#dT&t*))%<61*$LaU%I`<H<;G7$Qe5lh<CV$q*~lmGm&
z)G~s=HcsiF|2<yL6Ez;<-`5{M0N$@;w;?B^`oT40E(*`I&(AoNF4kZ;Zt1892v}Xg
zosl&m;5X~)yoVA4-)CcQ#n<*vf!cp_A-mPq1ujf|eSPTcK&p$O_a8p|(my2;i?Im2
zD(!N&5hx^LyWshZP~T2~m6&t)ZrDYM+`wGO;$Tt)1iohPxu>2Y?eteeNs0VbP_qqg
zJHGB7k_C8}x>o~G-my@m4O0qrWE9-9V1%F7&PVHz$zT)56F_M<FeF!c^yP~x<m9yU
zgRp+1_G*{I9S5~?`*tPXFgQ^moFRPyalv-@@^2pWRn!2m)9~wn+W!9R7;G0Wv;{WZ
z2n~&mk1@ajx92Bxiqdg!b8>Dru3i$2g;_=cARF}ujZ(PIYXtJQni>!e?=RQHgX|6D
z_OON_IwfV_fdfH`M8cLWhfE5b@zCMHB(|N!rY2B?sSzAs!BqsSBAnPm;5|Uq$jCtO
z$1}nx(6wvZFbs0ym;AkA^sHz}%5DoI%bRQG;Grfbs}PxNJM(UU$;NI0S>#Y;31n=9
zhf8^6pdEt~D=XUxaIhg0sqh}&v*#kd9c(@mZ2)9R;Dk<z)976aT{4oB!GAt_qHu%L
z98QS&SuS>V>+9Fo#^#==r{L~r11ykPVM1gLKEcNf?m~0<E{p}J+rLKUNM?Ws55!|@
zp#;H!$n_9@UhYtRGc(5N7_b;9^7nWlcVR^1+_`WlF5KMf0Bdrwe85bQgya)=*w}LM
z<Ppi1SFY4SuCEyYRs%@&q)I0T%fB=|0LBjt9s)S9d=Ibz?{;|jrrclzCDz__b8AJ`
zS$}UNc_Bq-;LjfwG;SX?u8TRJBx#zwe0&wzKObz)gM<bLQ<}73!QdUiCPU^29RY6o
zkf5L#M~EzUCZ-&0a$pSgS7E4+fPw^TM}+#o>e9>wp{Kfn8LwZXdBi-%+qYmu2Jkiu
ze2_BJpAgCJ-YGYdknY3?Z?v?G46=ixlT(>Oe0d)@11KENo_O=1LD1JHu^_;^*lfrO
zI}hqPNO6gC+#2sZ7Og?`lpS7R*ha-;AeaQ5!Tv!X4IW!3jU}`SvnU8yv@`uvi`WQI
zLoiJOfhe|C@BI0Q$VkZp*SFqL#o!S{11Jn=#4wbAC42rDZ2&MS$btBvbBMYSRYnM0
zv$J>Z-o^A29CzK;;(j%aU0w8#T~Jx4`m11agg*#I=A;H}>K*4opQvAk4g@L{4GVTX
zM&rO}lS>?*vh@Mr#jqAI>85@NgARl{6=!@eDL96m0SDj#hR|^OsSx>yCw$Ug3tg_m
z!^1#W;50*Jr`2q2Z4n8eTv&tYw{E?9{W^T$U|Qk2x0UFb41qz3g_G0Bz+e&F4!qzY
z4<5h?=|@&-lLPkQRGKa<#IWDN&dD80eTD2e6QN5P93W^9MVHH`Pj4Ga$5LZ^KxZzT
zD2`R|miHr4GjfBd3U|EeCL51>2(|>N-&Vp1cMG0;Q5hUyMrI}yO%49+moNW59BppJ
zjdXW2u(}uCUXzwmOVN?M-i{0Vv+E_s^)QbHMGkTxUcK;kcfPxL+}ykuJTMH6p=IVk
zo{)<$?POuW>qmq+?D=zuA!{RM8^33kux-JsQHA>i2M1pjH?*;N4HSK~{5g<Pk!faK
zU0s5>2Z}n00t!=umVlRB6%VEu0HzBHq*231M&QZ$Vkrji@WwR~$%D52tw|vjiTy#F
z4;oO4aq$PqXE!)968rcu#rux!1aO5&&S_~|SC_$*k!&y^$?S3==nf7H_-gSm3b7(X
zgET55#GK^0<qUj`g*0y;2brCnogKE3ZDW7t4E<uM$Dgp1Z}hG~c8prbhfmiZXY}3S
z=T!l&HfW>VOWqqyGnIcLtnz7Tr_!6@i!GY|cF_C*%%liHH`XKj!mHsCH7`2CC>Fi?
zJ6L4AJ!b??8>{RKL?)8G#jBn`Ajra&54=it{0?#%ZZA&i?MeP{An{V23Wbf;BYs2}
zmTDz?X8#;mURug(8wI$klddp77>)t0hYuMNwHLuXkPPh@lJYMD6NCIB0@qu$C8Vi$
zu$&GxBq=94I6I3UIdVin!P{azR5b~lJwg=;4oS!8qb=4MoDyal<H^XrGs`>v`HIaF
zt?^Pb)d;c`L;>($Xp5YN>JuM7W`1W`_UxDw1fWul%##=cz^DQImco%&tgPM|WPOHW
zGF8Q+;Lxjx(04O|NLYIJs0uGB+hNwwnIG^JJhSNS_vU330Hc5>9UUW%`M=(poaPOi
zbn`;FK|OGHU;6s>UehpNcr|udP;hYU_<{^c?}XDA&e*6APGi`!SUgW)QZ&;{G{7F%
zj=<xXX#h_O)xr&vZ3LxfnuAVta)V31sqQHE;rY*btbx`)#rGK2w1oB9{g2uU90$I^
z(@pA9bzi`A<1fMiU}4)PR>ws~<qvb-Sblo^{qjB`!w)pi!WD^-i0SF*uvtB5(QGn(
zaAOLp0KSIe7gU*NEUb3;)_DFPiR*>v2P*l!!5g?$zDFIVd_unU6+BQvLZeVQ<veBu
zzDn|ksWHmU)&ptqn*gvGpiQ}Hh@me?$P^>DHD%wnjPPL60=4YCo?iQy%cDf`8w`{j
zA*d3NWoKr;b-k-bX4MH#l%asZNWSZ4o}`Lum3?R46o}G=(SO)8!V<9%+5VY1bEh}A
zH#WZa-dHEedcF4=tXYCoz%pUN%<a>u6@QH_tbvdap36$X%>dKr3dBN?!oCC<(252B
zP%J`2>nhgQV-ItLfDE<CX@`!7u?r^{#>b$zH<pZ(JUnT-_mvY%8!O}cA@-*?Gtkiy
zX_$F<6mGco1;O;7ug^9_q&__*6{nfoaclZdHGG5ql^Xlwkw~<OOg<|Z&4MM*R+Rly
zQPGlD@s&>2HvtbeTgI(h^V`mC=%Z{~Thn~Ek6)aEo&uCzT2nRPC|7qaw*zJiW8s9K
zmhb4Y)l=Yi%w6P&`f4iy$JbSH4(T`sJ;iCD5l~q0<<|}N{B^turwOAN=5<I@fB!1>
zC5CM*cnYFzc@w8F*LSWYwe-fMuNEIOlrJ6|C5fa4DR`Q)3;?$5!@LzFB&a^_*+x&l
zb|U+keeF#1DCQlm7XP+)#Z+>N4rw@4OBP90?i%A~qfR3q^3t(_bL8;B6*~{>pl@uw
z{znt`2#n6bG93-xbgXk^gSRS_r^+G=v~)rLM$yL3)>$^&OC)Ha6-Q3DIhRWb1+!#}
z2KjQ4Z!_n_;?*?W*Qu_n4~_6ET}1+tlCrX^UpVd2;gF`V)TRH&taEz{JDH-lH42_N
zqsjl+Zyx&8_-syHk;V!LRAm3zZkT5OuMz5AE*~=yjL;+|_K{@i|KsfOEAPW#@k^3B
z2NT*JxChjl^kz-h6Pp%FKW-ruySh62f@?Q2k)|_oS9V#cRGao$7*fdpKWDaSN!Q_g
zkRwDjvjy`TWyvQ2|5hlu$n*4%aWSBLw2Z`Q4*o1bXqC2AqcUzsf!?yEDmKREKkra|
z966<r=K}*FZf@>hHaSQPn3Xwj=nyO#35K@NYw-RilM6I{<JA8CYXbu(AV`wt>I<|=
zS)O|a)mp6}tJ+F*yf_gIB2?I<0CXT=I5d@QvfK(?IsU|<+n1G?YMfihNnX)Qy)>mo
z$@%%%?Qbt+-&Ntocmc^2hJpZ@AS>%eK{}OE{Vm|XeB;0W4bD4PVI-Wpe83Sla?IuD
z8#`=lqw%{<y?b}#Lx$o1Cin|3nbX!6K`%{CO-)TtKb@!zmDM2Q7wF$_1Jf|;4!?z7
zxo{|#6HHB$34WhA^w5{Qv<NfGpYYu%+n9#hzrV^V8$}R$-$P(y*XI8g=eZ{(y7zrB
z9MxI@6(z{uGUN}h{PG2}=;*uXsE%}<$6XfhWKp4~eWB@kh~!d}q546d7m4vK_!2H<
zp}#c1{7|I@2y2kxwN_FJjDF7xe}iY*y*q@3*6zP!2D%R8?19J!P&z|H_w(~(<PWBO
z8Uh6x8NgJOz5nha6|8=cida_;mcehF4=mVeOr13iTV}VRMN<N{|7<CSnf7YSnDN($
zj*|C#?_DYwAx-ypopNBnP1g<X2&%Y$pB7&4+>Z3uuQ41GTnR5#lgUwhqP`UawGz{B
zXMM`e6@$B11V&DP+dQOyFr`%f4a3eF{7$G-vfTEY3%2%+bvOMLvYyiz#)Mr`<d!Z3
z{7xe(KW;AEQq^}%17llcWT2(S#1N_${HhwRDF_Jrt2z8;W<mkV?3}UVuN8BzOmvSK
zzx7vH-qJI1{P^-fO)lwxgw2nM1mOVngf%$FvYOcef&}yc1b(9S%R(32THx~XmoB@T
zmVDlLnq9?-hm0r!KATOZOg8Hur+E=QZgZSzb_HuL2htK^)^2$(DFp?Ey?ZISM#snB
zrl%VfIA3*ioOae{`Y#O>P$TZ*r=UkX!-}WqpzCsXS^wPUfH4M)8qGSlF#OLOB{$y)
z>_O@eAseHi#;ESIO*0uO4J~Z05e&X?rNd2Qm_eYpSddPsRKF%7AAg9c9<DvSt3Hl^
zow$`Y0HeA~n0-f!iVgx;1bZ^IPzQIIiw>~rOU3QmuW;;xc$|la2ZAG^j(Rsq9UX9-
zS_&TwaJ_kR3pF*$)Z|EOYm^G_p73g4UtcKqN=)bz%*?>yy17Y#mPu-WMGFuwM78eJ
zD_t9O?Pg{mQAm`PSBuOE!3Y?(`S<NR^Tr!}+u5_*7k6z=GGQEmQ5=NDhnyT34<MU#
zDD=@oJ;&tO^5WvF=6{^=^<ysh6)-c9p7I}*gc%6o>DK)CVI>y5Bh=N!1yF=_^+B0A
zCdDByY?EQ-5g^6Ao2RD&2z_9!VNBo;4G9PfV@3-9TK(e(#-8HG+extu-4SiE<|*Go
zAGvyxlTBf5SPKfX5=KpR3=A;JOfvXrkq1{!gLj2^2!hkoSeQ-e5tN|>>6@U8`W*7$
zg1!>(4#Z4yqk0s@*9|T#ERaqr0K1N8D25_5IVmay0GOzg25=7W0p)B1^Uz9vCWE=;
zy`swd5Y!uYy>|vzV#O!t=Hgh$xTGA2M~;MR@Z*FDh#IiUkiHyS7X~|&;ozd-+Q)k7
zW1ExM8<{&nF@W~~yo8_V?tbUOuKil^UJ#}1rko|OiGlw`nfti|)J(!LCo9qf3#AV%
zL+)^_fub33Y;I}c0W=~h-I*8ZoO@6+iwGdB2?P+uU>0&az_qj>^|ZBJfX!_8?zPC0
z)ykThYXu`T2)*N}7;t3Gqo1U#8Fqg9<O%xM&3Q{m8CoF!jg3E{@@nnEVH0g_OE~8Q
z5)-_g#CwJr@=ky00+cW0JEo}d!BioAdlm5nVhz?k=^&M5n1#TL!2}H<ISphQ`Ow6K
z$iag<Xalf+t1WHBW5DH5`1TGCR#}R{0!hONYOTy1b8euLJ3oEQ$pJ<twbzdDxIq@n
zH@4H&#kdNi9}##wHy2Y`c({J;p!VW4TY7rzv)drjK~s&^z+~$F{m7hO##~063mD}W
zdjVtrb7(@-fs>Oz990n`L|FzTmt-vti-4lyCTl9h3ja}X<%^aPjMiN7*Nm)bZf}Q@
zmt&Y=n1P8Xctg<qNyMIkuP{Roqkp38FljIm!fFQ4y=`7Uh>Q%qZ82|JMvijO$JT<G
zgk2ybqjt>2pEO~DtMJ={DZA&*Hq_MAATZc3f){ySgkOh|lgNZ~83;<4_Q90akt>?c
z&L2{%BSp+iKe<gMYm*n4m67$Df@DVbckS9We86_XDK)jPwY78e^B`dG0!M?UsHmUv
zB`KBoS8tyB;0Tu(j2udja2^D#H;i<2aK>tv4mbkTcNMyVX@S>_h6`F<lMTG_`J}zK
zIrfHqg9|oAPqXP7LsyJJ2fcI<uaC<6h%^=?i|&@ts*ZOTDQN@Xy9J;DY{01o=yLG_
z`3{l*b}XRr>z6L|4>zU4H+LRKl2o#p0WnL&%Ap*<Rp?(<k0Ga~rttW9cp#_IsX=4~
zl@1Fkus5c>ab65YzcJtp?1}}4Q3f-qduWu2OaK{jSC2u}hS3WRxV3meP7dr?n3n<d
zhjqU6<v|d+k51Z~^mO>F@GamQdcSmyxri9N!!A9?A5Jp)0Gw|kF+mnuaM%&*N`KD5
z#&Q09rMV~wY$&N}Oc+V6x5)w5X=i6A50wWRD4J^{Gc$N7mPokKW*Umr2gB<~dcXq^
z0fGI&CXBksU@|%17_%LeM>}(_MQRIR03X``#y+&WlD3Z5uU`idPe;bhG&KB{Y<3$e
z1hxjQgM}7pAIo2SqyGy?F-U1P_^x*=JOCE2N=iynQck4koN+zz{3^m05(F4E2Avx~
z+E_EXf<{ngXLWV&R9YZ24V^NEhX|7+Q1&2i8{m`!!N?j&LxZ)k`e)B(A!wlR;3xq6
zRh>H+L%iVRBIo~zGzrEHe~BFnk5YzS2b2+0)9&VG%$WRaYda<-1?37-O-FmX)sJV<
zj~^pIAvR$uG`yOQh6XqUj~ta2O(&vULIPH<1x&o4trv`F9G-<>j@eO+Kf=VAMz5u&
z25|>}m)U~nh)5O3FMRxn$r~teXN1xktigE$H^78|IKVjzNHBjK;S>#k*drp6nVudi
z=jj4z9dlCBalLo2u<$xU6vUK4U7ZLxK&xzYnaAYhcEh1h^Exr{qD8n8e<SE*d@2ZQ
zYb?j1Xblu8)JrL@x36ET3rD7=q=2KkiG?llfNkr3rG-T7Zcfgc!5KUz(6si8hWq*W
zz79Ad{dCz&54lpD1X4uDq{53tv*|$xagK$-w4oH2Cj4jce<xj3p+>d80h7=2vWJMs
z82W@5Ze)S<W@u(f4R%r=-!u(Fm&b#JApl9~?5mA9A-n80l>4YJ&}twZwAljE<MaRo
zHl!Gi5ULPW&*FFD9A_|G++h9v+c%1nqU;(NFvRf*z~=A-!|x5%9w8|m2PlIahLQpY
zqXxf-(MKWBOIF!9wP|zK`s=0>3qB8|8<@-RC`qylEzWF$*E~fB#(gjfEzQl~Z4@OM
zl3&8;1AmxfzU)c3#dLLlVv!F#;k3_sP}L9L2h1aUtid};!)&lCK(YoK3D%DW)*S;O
zNQP01OmtMR8^6c&21m%treQ2A@*nC9yqMNvA*z&TxOsTcm!@b7Sc<vBA_~nPBjn;2
zNJ0|H#<ZD&n3<XNG7K+^vSWB7OzlI*m^jCEn1Ip5K`Xblg?FIy-TJv$x~?7)pam>K
zz2IZMD9SFxI^rx1VpUhL8ApBayQGjt09;5KzIsYxVjc-<$-$nF2Tp3LpXtKqiF?Et
z+$JF-BP;s}gf1j103HmBXSXqt%!R^{7&!xwf1&*f_DUF@Fhc=~w~nZYvxqeKw{6`D
zg{}8HcDxGjRq+^DGB9uW@+Ch(3HO18yL@?Hkjl5}Y9*$MVP~{3II0M&VT1L(ij6Dp
zF_nqQErjW&#btHXi=YIl9SITMLn{BWJ_mEF8TwcNV~h*$Zwo3j?{&zF?ONMQ^SOTt
zPzklwT$H$o!yK?bAw@jLz+!3gv07(oIry(S-9dX}-hn?n{PE-4t5a3DDx4$}6-5(+
z@-&F-ms7n%>s8B0t<{lNdjgapdOH<%L5xsNe59G`Z`ftw0WlOa5t4<(`Za17_MX!y
z*Rb`$0gn@E`r!xp+aIcc7Dwd3fn6{HZT2W;Na1O4<6gM3XO^g#)PTkF^6CV8{0<6K
zO4G0qYdZMD#6(z|;Dg2p#})zs3q7eAp?+B`+D*0_XG(!!0S|&gg`hjZ8)lkGJqW%|
zk|QKsA`kmzv%>}#3$v?*XcU+=E`}D273Ub@K0&seI#rFN4c~<rio>~cB#PsRkFa-k
z+XLdg@;+FyhyMMexLAEC&-g9)E2Kq`Z%5c4a6Y{u9f#)_-`Z=1!vo+R^-@B)kCj7z
z0!)lI!DoW9P;Utz`_=cgR;OXIJ0pMdAC4$tx1O%>xueDh_9eafKJi|gt(~nc34X?L
z-@;)BQc`X(N}zRw<g_^~;?{sU7sCvk<pl-aC5Eo+I4P7tG2v_zF)`-Z7}02rL~SJH
zi#W=yemCZU(59S=u=&{$%fh8G;Lt0m$OyZ_mb-Ch_?ze__TmtM^`$y*ZlK8e#N#lm
z>OrxDmkd7#cH2r&MrOpLIDXt;Jw^S@ne!0eg-u>(X2Sh!cm4WYr)jLlOIV0;sW<kW
z!AVEb(i}T>U>+GFC)_;_QpPy$h&vS9h@DQA$h0|>6N{5Q*w|p2f$2@{Ax@z{1DB?Y
z_5~JxJXTbBIDz5ReDmVPZ>wYDIK>S={qSKHI1V;W$UU{+zdwWb*gB^j$LGL1+_gL(
zqf9!x171phJ<L0D(B0*Hie?)S2E78YnPhPtE$Y20#u_{)j^WYuyP&kI;f#kX0fsoF
zLO7-`U%x(f$Oh(Z%zy&`pH^2_3<t-3K}ZjAiTkg%RAx#BMT~|Ws&i6<4+-L5y=|uK
zN~1wuAjuA6U;|nYAWR%H2QeB@lq2N1LirI}m@#IJz;z;P7#bSuIJ(c<(gs($FZR`c
z*H}+GcL^=GH3tq{0<3|m24P(5<5ocbpP>(x6XBQw_4QR0`du(9Br3u7tV`5>M3B_|
zUqTS)U@h!R)+8d-&!;zI^nk-)QHMVq+Zq!?hkdK;aw8)maE_b58XwLZ181vp;sjbY
zC`S;Tp#E|yF>!=EjgG#cr{@B`IxK8E>L^SR5)zoyD*bB=JP6S9HY4NKMA3rc0HB3X
zm>PWhrJ2}n9UZY{=D@5JzNB%3y)>9hLQU?*L^4hT61_`gqJfUi5i<X$4l9MO<=DP`
zCx}cCrrv3%DH6%9?SrdTA{N%RU399z6mUOx!w)4LC(J^N0b3wIgWw&ZRhTym%9!_x
zNKH=0uEk!Oag(k8gX5;O!WEW>k}!Tva-G^vV@ABpJPJq&!Q11#aSJ+RiVpBoH%4V9
zCKz270Z~Dz3r$ms#qb|JCLzHJHSNh0OiLo*bkcqT+rwUnXGIxW<<GyexL8_AHNp6*
zIDUTkZF$iiG3ncQ;H0~VtzBPBSVMh7LBxnOjN=gJkXTR+1S3c(&FJH3mupX)?mGUz
zwx$N56iYfIuwJfw%mv3DVI+b!cz4F@f5+S$7<_&DrqsyEpPWlYg49WH|64o!cJFMD
z+{);vWH$}i;oOZ!nZ-8Swz}I){XP`_5W*^A9<yn3Qx!W(oP%M1#F013ykVs;!g1PD
z#;<?>YzRsi{fXB2duV(woWch)KfQ<I3oX%Tbjx4Ie82;2X-i9J1-AC~)RMm(^Pk}m
zgDnA2XEDBCX>m$RYoo|)D~Wgf{u>N2*nn`W18&&5_{_n<1+zM;7}!j?ckZmT6azfL
z31<v}D10a#0s?BOO=v`58G`%c>eY!4FrUSTvAP9&Zo_nCHxm=nqv&Y&@>v<FH8vdF
z$6%}L3`!d|P$ARNh4q!7?c3?>?W0zmM3j$l*%hv_2@U>s#JFmV2Ul<<=}e|j`DKCD
z^bs~3`w_19WIq!Pc$kejUohu5A2Q?%W+03v2skhZU2UronbM=YJgLd@inBKW4o_uo
zyL|;Vh3tZcTGYah{FMdqHmA=pl%F~S^a6~~)M`3pN@7C&OG-8>;!g5Uzxjlt9cR;#
zB8o6claj(#vgR^>f2XpD2vXPnpspnAiBC-%!K?uvJ4`NKT#Q|tONlgvyaVOcYIm#a
z(=Iy<Z6K$zsu}wdhwMn*IdFN|8yPTckI^roy?For_tH#$x<2(;0jbt3hl%B0e;)5j
zn{gJ}F)Qzw!<VQq3R_A0*p(GZPEZi^x=ABOzj1Dm(@X@pA;6?tYjb}r3nJN`YJB-z
zxZ%kWTU(gDpOD_ZVTZ~1iPZ<7r~USRLPN+Xoo{@5%+TGOIFQrwyTRIR1zvRL1pmDx
z9-Hw4{1xCSJ8TQ0kCeYiiY{5ZQ$M@h=g%|Cu?8yd$Ngs&Z-$=<ZBweB*t*GlGk(C1
zdH;SU+v*0J(B#_K75|qeCZ|kTj|87s-m<MCBIsN4lnySl-k<Wn_X|g;H@CH&;^SCf
z9sE#QYWB`icJ}1czJxuNH1;K4nXg?7(&_N&v_HtfX?i%Ia6XMNQB(i@{}6TVaW&=N
z|34)psZ^4Lq)AAUMlPX9k|ZHXk%l4(38m5vNvMRxluL+7k|dQRX_AmslUs<IbR|-`
zRNv=rK9Aq8e`eh3oU`{{@3mgHRsHY1W`E$+zC=g>b`G~vFELv2V#TSXjrmelo)x_T
z;K+Pc6cE?Gk(LSLv<;`~TD3K%mJ~(zwcNS=%q*SkRUG+@B%CvH_g&L6E1NH$3PQt1
zt!v#g>;We3qMDPLr#_trnJHhZM?c7)NcZ{Rks;j&{B!BpZ_7V<)@_->i2@b;!j1nz
zj@xQW81sLnb%cRTQGK%Hd7Y<<V9&hwq4VURrOZSq=sOUyb0AX$$35vqMN6}LyjG9S
z-6rujImw(FH#yHqJxKa4xwM;;S7+M|SFE<pu%1%6J+SL3FlsPy8{*=U5<x{Z_04z;
zD!FIk#F-M*BlQgoien}fkTJIn-m=&!MPu}6AM?yglB*EG>G`y|ZCRaYrIneL#nay6
z<qKV8Vj_XVg9x}`!yJ$?-hb8F?TYXn*hNb*zT`Q|KDyaw&v5lo;i3N!eZO$qv2fub
z>MB86_kH}L3Yq!F$cN&1^FLLLa0eF>evPN=TbnDh%3XhtG&4DCMIB($`0cm+iuQ|B
zw<8J#G74Bb_VQ9#wQ_Pa2zu@Ov7M&x(W6IiyXS^9`{?!-u=qfN3x}$V-8yBf$Mtru
z>yHl}S(UgGu>Svzt6e;Iz5W4{bI2VA4;r*kJD%)QI!U4htP{(Fg3nY#Q-)(%t8+W;
z`=u~?^=@Ko=)zyPA<p>Gp407zX-8-~L9v=Ye#EJcv>RpvMI+#h6PmTEEnb#2J>fq0
zgLh<g!rizqSXR0xCnX`fUWABKNIrzu9w@m-h-k&#rypa18;~Z0#2)B9x5?Mm=_!jn
zZRp<FwDhwl3RuJG2qW;4J$CLj0IAQS8G@3AcZEVxF!e+gT4*jgYt;zVje!8QS6sm^
zOUWl+f%6oVl#nwFy_xTnvOdiYf3x*v+7bjMuiXv2b|jYX%By(bo<6-xHo9nCnqBVm
zqWew;xA$@TI;H$N;1_@Pr%1KuF?t8pN+N`d^SR->w7hV2cWwpU;zLASgbYN&_<#8(
zDC}@<zFa~u%W@l=xM|zRs;l4I_L(#d!LEkG0m+bIUxry!61bC)Cr&{tQb`DkV{Q;`
z6<UNQE|d-@fVnwR3!DU;khBkyLHZ=u=$}OG!UTlt$8*{RK`Y&#)G|p45IHZyI}ESa
zuOA_l;m40vx3&<ev-@*yUj{tMphw`J;8);KanpBR#iKGUHZL#l%uo_wzjztShw?G~
zODMyRtV5<q@KRSL%l7MsYy%+|8b8-G#$&#ifM}o<rIrELFmHnaPjJXoG>+h-!8H5%
zJEM~zbq4(g@bvxevE?4)PH?WAy!`vxTC~xK#J~iAgor}TtD=7a)Z$sbfdn5jI8lF5
zg?rTYziI-6qZ#1M5Z%H^6*p1ID7gZE14Ux?S)i3;<|LKEUGb)AM1pgBFtoeBOEU*b
z?WLb0Ln=HR-~*=thCQU#`S*t2>)YQqn-g&Ol&l?1DkC-@*l$JvG{hvXnoE~HVty2>
zn}+gBU^7>4&h9<!o^c>xvwzpu(*z^TLZv@L)}BlQL`E}zd>n;W;V|eJM>^i;pQH~9
z*2gIyG4x|6=uT&}c;Tit5%U@fD!iH#XUyot5YoW4gY;TD_A#nI*!ruhbGo2JcuQC}
zkf4L`G5da^KbPA39xwH~4CluudpCFGzCf*sM8@-1$5xPN8l=UGbJyzqCO;q5LH`N2
z`Gh?nkm!7N;v@d#-|d5p5+M*dvV`s(*Kv60s4KwxoJ$xB2w&4z=|n9-l4dRjS`<XU
zj8Qr#fraU1Hf#_~2j&-kkoNGVtV|#5kH!x8a3Ku4$vL7vky^o35ceX)TezgyGK^t!
z;By75VzBT-{nAf@Y*xD@n3tRxz8zaol`_U!X(5e2+2P5>6$JZykvRnd*OUCghs|>!
z{JyWRp~|5yd{}yhhK&sk<CMZcJ#Ju2;!98v$cJj6S<T4shVTHg%+acn%B;wR*i!qL
zYwh4b8>jb2pGkU0P$f|P5n`aQ2L=CM>;Snvp{2f@DmkRDA}U1dzyAGJE06bzt3pk_
z2zjTxG2!m_oJ^IV2X04c0&Yc-(ARIJKcCmNNc0(dld7Q?xr*6*7hrF))-Z5P^J%+6
zE?}l-9l90VO<lGAT?ym^O`7x-!^6z2@9#$~nu#zMa`&S1^LVREfO6zPUtap-;kaZP
zz5OQVxCLTokyl$Ahl7U?kcS_<4>E%`6ZnsONLeW<lA3rr&=lL{?Div~w=iln*6A+P
zKD#l_3;L(*E(PSPfkw!uT6fKuQUz$t2)b-pIi8ito8RExl~YzG4#pHssP$#SFA(*U
z4!mC94*wvs5QH_Oe_kTtg%F+>*K11VjbL1y!5cWA06;<Mz*#(Q`BmaHcV^gA4bt+R
zcv8JPzf};!{hv(h?(c>io{JV0Q|78YrXsn=bdJ#rY~XEITRPqMYd1S_&(%RfZ2HsS
z8Y=fq+aJ-|{lfP<TI_V7-Czo)cZrA)T}-zeuXfBFN!LW>N4VS&ZEfB<mM*O8mv?m0
zH<+aK8#gQr^SID2+}i#KpD~#{Q^HMoq!4J5!_|}Q2H}Ugh%6mE(o+o`?*}|~9x;6f
zILxx8OR0|)O*<&$*AB~Fs=vSfelLA)GJ<4Iz@95h4-dyoe0MeO07P0cAwLO6=z$G|
zfe!U9jdG95Te{Dvkt4;<KMnBoMN#ujkn`JW6>hu7F~LKZ`oez6l2r1_kU%q3X~+)`
zCsG@W9Cm$vGC24tNUHOxdqIJl+JuQbJRGyqRRYpnv(Om<>&ZzB49izJ<ctDIEiWN6
z^JSeUw-CzmEd!zvdjq2LOYUDl6B-RNCKzXzEvt!%63tL^6e8(cMX;f=2md}kbsM?b
z7UE))D$4`AZqc|9*m2`}tqGnF&;!mJ;Gx8F?6}JkZJOR>PbWmpdOp56D=RBZpP1vy
zU9m5K)$ag_)6*kGkrAJ&!|;wD%cENI#AFh0NCnDwqSrnn4mfIlfuW9`gPv)PkZbq%
zPU|iBKYmwP$alOS48y~<A$GKB2L~E+0jG79p<k0_LaB2q<~qKDT}XZ&%&iYP#rdtA
z#%S#L{S0!%Qw|2uOBD^wyP9!wOTXZt12Al>Hiz(FD#F2tWxtPv1fH{?qn)9*?A<Lb
z1!BldgF|VYj!qZ8Ud;j1<s>E4BjHp4-Mq-3rG10;>V@Sy#n$k{WX>Pc_?|TWNh#Gh
zr_C<hJ9Kx1_J5716~=%Y=?0Fv$6GzuSjpMjt7Z-&=jVboaauEmbVngr&Tjd8DD4f`
zEIl3J!w+<Vsn8o`M_|O@`!Z>1GVD2pp?fN?uL~oSk7PT<Xpv^%Ojn|M9e*gc&4nme
zGc!rsl)lChTxgh9z?0nET(WNj4O!~KU046(0)T!{$>0GaUP51mgSzbH%S;#+np)-!
zsDHG-(M6cdYX6QlQtRNu^~8ZyQCW%626r8oLMg2GMhRs9FjrG`b+>?U8{F0e=%MK%
zsfn`^!^*oo939Hi7qhZfp0%>DUtu=(SlhR6d-v@_lP7-2H2vmH%NbRKSpw$j#o&$N
z-Jv^F9zGl;8DbdUnWrtgb5{6b^*m@s0fhX69nlpVMS(|5X`cr)C?g{S7or)pA^p`h
z4-W{Yl`CI?QM{rDXy%w@vIxsJ*N_j%%l*(oi%5dh*RKTVmUbTBBj`C8?<%`ryQ7va
zrOnq@p$ob*$z_+1cP_$v8*cpJ;j)sFkWwJq^<yVmXigeE8pTFdCHLJ%S650S(|Xww
z^n;C!Zi23FbZ{<7^dzy449P<wxN*aVsnj_<zqyVCbtAQv3_=e{pdC_WfT&?pwm9;*
z+Uul~<HTVDb~E<aj_uol*kom8Ay_V0kBKfqeGzE}yS8Bd{1qG@luQCcmakf6i8#Qn
ziHl441snpf6#<cfz4~(3q9%LcMw>VClExv^qDPOeT)o<b@pG!GB{mpr<}ntQW@hU*
zZ_e?odq&@38jq`&8r_4E$IkTIg+);^NJz6!N@5ygmBZL$CqdhW4?mpic(-3SeGlt4
zxK)se!(|tIfV=>t=utfLp8t~$z$Gx43!WdTFDTrbK7OQYWsZQHe(a2MyeeeG%(mx$
zD5Oh@))bP;Lc2eXBn5r_qtVf%Mj^>ST%Y?pr+k0zvm5INhMMpefe4Zxtn~os#fRS~
z_<Lh&v0!Dv={GHQH*rx&+$i~BCg(6cZK}-tT~E&=^X-wRv3tC$zSmyNl4;-9wAz0<
zeGAX8kGiDJxN&IZzG2Lw;UkOb-Ht3WLK1?46c$8VFTdJa+p_ybt?lyYT*uD~=NHB`
z?=b4FjG5u0=N%)h{-JGz^{A_B9y{*M4_P>k$&n!tM<MQHmxk2{K7itpEsyDQ@fWZw
z51y{W^Cfy{_4M^Ut>;6qk|aT?k1s(LS6auIgKq$5uYmzS?77=b`Z1iB+P2pMEEA9q
zC6;4ojEIdLHhA#73)Z>MzCky)-iH%I?+IC?Cbwty8t|s*BAlQMTJGuWJpjn()T4J+
zm7%ouZZ1RgY-%caNaQ3?L%<2Vy|F>zm^nln2RDW$bXgdjFxGo}W8{i20ce6Bb)nDP
zp^Y*F&k9~D{zkzEir`tR6R?{xF%VV!DmeFyHPfKtpIaDq;2P04lUdf$L1GPZIq#Qj
zj0jN^>|D&qD1RxIJ+1(H^hP@r+C0649S~@?bS%afC@vn8T*rXTzSCk4o5mAvdg}|3
z1Z1dD`z`*wW|ssh^A1g{1$>2-7G_l|tw%*gd{4a?Z9~I9i)-O)iQkPcfoCA4l|Y8j
z(2V6Cdu9^dUwmTF?fmTCOII)Yxp`Jmu-gAe9VPE{zXKkvMDL9+2SQ51xD->E=gyt8
zzLhPp+w?Ya)V4qVh{<V{POwCZb7AJ!N2f|F6+h<q?0A#9`F^&5vUHDJUG6*R`oy&@
z@nNHf?VJ|NUt~PqMOH!cs_-K{`cud52@GjFvT!_r9Dc!_IM>94DVBDtw9e>2|4YZv
z6S}6sB!?GZgJlZqQ9^LZgL6e;$5BS4*&#FKWokD6WOd7`<mHLwNRO%?ApssfYq!06
zq%Z9j;dVT?kDYnunHgfbX(!OFJ@@9UCl;$@eVOZa2&tsy#S*7R5CmD=?~v&zuN{+5
z4QNv<U9WFAJlsf4T1JL*M=!>3>zloKRa8RPG!>08l|P)Y%yUje7v+CwF`PIwNbQ{p
zSk0n;<g|crfD!H=X`eRs7zsjmi$5#1E4`D`rH}J_;+hsW(=QXt^k)AsFxgUvVIQw1
z4y=&A)Ym=d*NHXS68&O!5jVn(OKRf~jgO0B&+VEQ5OX<hH7N{sNjQoJ^zYxR9ecTt
zQ^io!KDx?k%0_bN5v%vrj+B#JQt?sZuCLSQRKf>}YVeh6pAVjW)_uw$;z$E3pNhDB
z5q!E-T3}IVXqeuzAFGGUBw#2+Ix`Gva&rxypO6j9x6Bkz7ikW+m@)I4w86N3|Lc!D
zXH7cwI4$k>Z{KR(yy=)XV!+q7JN}tJ&I~<Jd~omv6Lk~MpR#K-biKN6pX%I>{b!15
zb8~Oe5{3$_u5M0~OC07VlyZI#D0p<XuT&4t*6bpc-_h1|I<dUh_wRRBt=f`M{PXRk
zPcyc;EK*ih?(q3X*o1R!)Gr-i3}7j~a$JUvT>tW{|IaaJ-rmEKZlRf2E_G21Z+0o3
zdm%C!=@5{pmLi{y6KX@E=D^K8(?$6Bbx35>uW#J3eNLX^s<;XE-yu09XQLF=2QTUI
zTS54h)U}d9O5|m(BcL66Rb}NZ(_+N~)rj=bR{HchW72QGts`70ZqPr>Dy*a#!L)$4
zy3Son!r0%+{KC2O)pSJ<irb5ezK)Kna_Q<^lwf1oI6iZs#ssNA$=VR$O7Y!8EQTT-
zLn+nUZ9R{EDykH~k!e$=bbyC2Hz(y)albNI2+(d=zCZ<Vx?}5*6p`MAhFpkUpsmSc
zxI1%d@z~#%Uu~Qh|1E0Ag1yauY<7FHJUqPfT*a#z)8YPgP5BL{Pc~<wOPr1_v6b=x
zI}X6W=q4U`=FXknMBRd@BW>vkDz1l9K!m`h>g0F<5}zYsOv?lgY-L3dJi?%%s;aj~
z@6ZTPTc1gQRZvj>Z{K>2@Qnxpu~B{W-B(w6?dH)7#6RY|8#ujT;C<&mn|J+B6L|w(
zm6(q{<GP^fftB=P>~)q~SV;G5DIl_6P0dIrI`|6{6o?mPlro2jia(e<c}M0@G28}a
zjMsbnC%k-lKuP<v!yQ98WA;?t-I6t5xnjb}=D@ilCEv&WzaQ5M1_!YQ?hagn`V9{%
z)R~qd#*Oi-ZYzi76JG-+%{(DE2@Ew14ARe^UrPh7MsK8{u0C6kPA>ubrJXauQaf|z
z#oE)0&RM;CKTA+Qb@%QSP#0(#pS$}v!qardk4N%AEQ-0A8O^tZ_*rx)M3bSup@~I_
zupgh39IJ)8TI)*XLoulox~4(IW!TH~5=jPKR2eob8)V4e|Lc+8a=W@#Q5^)xGMsGr
z(!br)KfO$Y9r%qyNDxeF_G#QGsC{j1N&7<*1=QEiMr=06;8~Oyod39#sIhz%3hL1>
zB()>9Zf;0C5H`x$`HTP0egHmaeo9M=E+P|7ymAEr*n2QR!_99DmBPq??QsS2mdYEx
z(atWgu(<!B1#tN5CEPa9bto?dIfu6PmCVdtnXiN^W6AlyrfNf~_m+Gq|KYMajgp-<
z1P=%?gVGSmYWqoV$f`V3;HsWt`{+Z<wddX0$vwFeD&Yk}#7SE#e@r{8CTH<_>GQRE
zX!;UL3!PHv4?x7s2}?t77_|BC>GTXBZk()(u7HnhAc}n!BP3uiUh;r_AHV&8Vr0=l
zL&MK3hb=J{`(~eIY+;7`u{`}%lJ#YzJ}6CQYz%}{O0i`=1zpxWmcvJnDz~hn|E{~a
zBFA0OTu7F-qon!$cick(!Qg{%tvn`DdxLTvS$_l>iP}CY$~X|8F74KaG&@!UIj1IM
z4HU8+c`$mu!Q>~g3u2~5O=p;F?#mO${OCB)HLG&f;>DCIm)$Bo>^s)7(Q#hluh-*&
zrvW6=g-BK+Z?{y<=Iq)*sAMNbD-bKwgzisc=R(Q~i9bzEbLH-%I+``>bY2zQ6m75|
zQ#H8V>rNUZ-PmK?Q+|0l2lC$w3@iA_`vG{fYl$gSK*<#+bI24g`c+iuJ#tC(QOvh*
zCyBVm2lwy4^<sQhQ4Q%lxUra`*6L;4zRe~TCZeS_Hu92tE{ok2Xi%R|Gngcz?(&&I
zFVong6Y22-<Qhj6;(bH1_2Sj5aZ!bLal|6g>;~vAt@ES-L@8MO=hR6=ov^lJ-MYZo
z0Ny3~iqUb{{}=957%BN9n|QbD*ZaeQp0j$it#)5u2}IbYPqUHhA;;TJUO@R6=m&bu
z!>Uv1v1<E?0JSI);KW3j6N-#E8326EnyR~Z1FW=`CYB>DKnKCR#lJ_k1+4IkeqLH!
z#3iw}Cqoid5({eP&FdRpP*hwDhDRwvO4ozL@o6wzOg_c(1&&VG2o+TI2o!@y_D+Ab
z@T?X0YT?>x_=rvy3#$RrZ`&j;(}_lzftyRhxJSE}Zhk?f$J)hVj7Zkk_crq+0&yfU
ze|~253mQlsW~M#n=`A>N2zkFNKP<}qB1(I^q?<3?9DC2|QE*yc=8+^(dI@OeBcb74
z+vBf~wM^*AX+Z{-SdP}7;2v{sDuNGSqd4giw&+B&>OhF`t`z+5Qo7=tb-WtzFHRzy
zZu>$)c!M0N4d2Me$ae}%EiWtca-YP~hcMH4V>uLm-haFFs8VebkMRrd+>ANxQ<X&)
zvhtxf1PUf``J&DxsF%uuVM_XSR59$dsoIl$+L7y&Lf*qdZMH&O%nIc}dE@Fj_Nv3U
zcP(s;G49uION88yBqFcb!o(|q+z(Pi^#UFWGKxgwjL2*rdu70#;;K(`I-ul);-SG{
zKx_bw<US(Hn&yF#i%^etx24j@(<J-%e|6hC)iQydhm&J0Fj&k!3+8~8b)`0n<f9Z)
zZg9ateC-+>Hs=mTQ$n|n6jq~_BIkqlGyN6kA=Lw^8np_U9r7Kry4S6%Vc_Oopw<KQ
z_H67x(no+2mQ-+C$Ahuv7YGL5NZQUBC&qeSpreK8kSVK?I8&)qDu<9k@M8?42?;uO
z^e9tg>I-}p3>PdKgc-Bf!BC5i1T?|R@D7c6LPFm|rdjq^p_MrSvMO06##{wjhL){x
z?L%C8p`oA<c$Y)+*c*1X<RgJTAZ#mEAkku-4!0v4CQn60^}5-%k<)3@CT?SH2KV&v
zg9kz6OB{6(A5rJ|IELQ20;U8xP07T<I{PdkNkI|+0yOeo+|%)X5Wh}>n#H5Cpk{c+
zTO*Ly=d?aspb&l=__x$y3>KQ@h!?hR|4k|E<K=`Ph}=^+7TSA-<ZVT43i%RrxQT0s
zP>O~i#nwnHIM>R-!H-NND&l(tL+>1Ye2};fkd!1Bf}1z53SyExGl-QdE7O~KX5zl4
zr=@Z7drkxW0tP{7h9oFRZHlVS=+Q33vLQutP2&RFEMG3{I1&tup`onRnc?->arf>!
zw%UT5i~T*{eRmrhL-j+;!gIN&2d}IL(Wh|!rlCQ$7VbL~DX*MUDNEQbTU$LN{Hod1
zIoXhmTI{O3vRB2I*k^i%7Oq7eMEOUq#)2akr$P`nRw5SMzfZ_KzYhr$Wp*BFp14#X
zIvNltBJ4L%jn6RR78fVqz73s<&<z6(uoTwubuKQcwpaL{wDfc#ZJM*0PlO(kXM;u<
z>6pH-iiqz|%n4{Y;-*Ke_`n2+e!(sY&lRg28B=>=K@jjo6>^1-nrR4xW!XhGUUGQg
zxn$^;lib7MAs%=Qbc7ejYdVteM6mm+43Bjz94NiGP+^{KPwyc3g1qqsV{9BTEPI;&
z%<<Zd(T!sLjSZ@HWI^QN^a#rrFZCY{M+$=h#qkm)H%d#tXOclD9y>#U>&`+M${l&_
zc;!;mrLWfziANr^qSQAa`+uveIaA=!DCfKRxg>gV_RGjXLHC%^;qR4(4qcE?3TFYv
zDx~QuN)dd*5~$s~yJ(Ube}PBXRZ&t_hO(zE-2Yde+hjg^^3Ev9FaYF!(feIWP5sK9
z#<3drdT99FyGG!vaLn`2s}QjxVDj@7KGW_KBFJ?oiv#BfWgy?Fg~bR&FsuM@@AzDW
z%oYjbkt5e#%g6Q!4lMY<>msR?rmS!+$wvM^U%l-~+!3}dmDZ7y>)TNkg7}L{Ny&tV
zg(ttflxLlTiN_8Ghu~|AaDg?!eQ}LAQT`3LF;6~hR^Rgq!5j803H(zifxwrndLzcK
zllz-qMQ7~Tb0zD!b{<@^ty^2}-o1;}1%KHe|Jmwl{op_M?k!MIpgYc;J#srnp-Nev
zE_)rK2(w>Ukdfxg>bvw;GeC=o;q2L0anCsww6ABk={pVg^jA^C^f3}yk39xDAsnOd
zk7Vu?z+FpKr_<cAZtTPfUeK(z_I6}NP>zaH+rQN>%c_ivh+uaJY{_HiuYh(&!=Id&
zV6X?x;L{x_L9&Suk{P6iZjO79j4MKILhqmYec=UbMCK7Gy$&N;z;1B4Xft~bI$#7D
znl_<BCi^SWtgPXiT6bJg&CKp!UxfvA$LTdz<Ka)TS-y0sm*u@0kK8LLSVc#!@BwpT
zmaKO?_l}B>sDQuh(t3BjKB1XDPD!C$aq2P=({@RY_y65T=0Kldv27=bKqfjmG5HSW
z4IyF7H%RRPx5CA*v3)yr-aYxuc+h?ugm&NFHE(x~8#Ag`+jHZceQZPFBZ5|bzfABr
zQZ#xNvUpo5Jscn~L+I`I7S}SxUR!iwm9X43ZfdWnfSO(0#XQhfS{C!?w={14u!9Ii
zPs~-Qc3@UvN}fE?l#^thgUT5{{&CO7&Oq<2bP=>IQO!?;0Fb@n$NI((K?&!)DF#v>
z@EP~s%GahoI{l-II>`iF?N!x#cz8M-CCJ;#q<=ye(dMB17~$6nIC}Ev(Hpd)RH&hG
zrA<5d=YTSD$AQLSXP!2kj*Vp_5Y!VQbWq{VSOvR^h`y0@L(p7WCs8#-@|Dq$9@VnZ
zP-Dry=0W1=UJH!cStASvZ7ioh<itTA7H$ce194h2G=QojMns!wK>w_~=4i~wNplWU
zYJLHQ0*D@k;PO&Vp32YC;I?Yv7>YrRgWri6%hBVPyZ+(iBq=c)xDDalt-5(~=TX@w
zmhaoM2lN#h2wjB`;(Z!6v258!=78`5z}7i(_t)#+!KF!Xm;c>o2I-FJ!aj*>gdl=%
zTg6<y+bDi*#61{APL!c?a@XKpZ{Ie2no1gCPlBp9k;cM$QwlcHN5l5l+mKV9Jn3Fd
zH3a7dc9qsuVS^2cYc`3)l$FgEE@Yk{%16bvt2<pnq;`o0rO!7*VzH3Y)2+h7u#_!z
zy3BCHj@-T@*dNJMfp7rNb4npcJEeEuw$W#N5Qj44Wu^-(3cr^pyX3=%s)w_Hee<1A
z(H|9-BgNjb)d*l#HJ0uZEGYZ+Z6}2k5t03G+${e)DJdn+slboC?AM=vA@hZlC#C?~
z7$2BrLQdPujXi5+DSkY|aw65K9un1e*$YiOLUR!@N+_<-^$}+0<Kl)xpF|Zh8PP`5
z?oeMyKLU8offENPp*10XkthhC<Im&HlW~K3{>&hHIa<Z}7$hRiZm&U!`U}5r7g#n(
zEqx!%2y!ACRagn|RA_a|HMa=^1|i&7U#KL4FO00JvBw<uS_#|2`hR67Xr$Tw+OIRB
zr)g_5=~cCKFdH!OgRs%`%|8`SRxnzPw^#nUOK6f|EwGz6j$XPt#0(Te6LoHdu3*!6
z!HGkl^QKpmIkS>%vRupmLQBtiDddq87lKT15r_;DC9*M4aDK<z3p*+AHbAU0-pX%A
zQ>jCU&z!ZMzu0s+i=yP?)c5Mnw|)i_Cdjr%8{s#^Ou`uNU4J<N`RN1)J42Vl?{sFA
zpxpiAkITh|U;o`aYmjI9jOoSQhi)w%`C+hOb)t&K+7Gp1Bm6cz!))AzEfmQix1@LG
zRd5xG$Mflc@*vIDms>&38kMw#)g2Q<O{8RHYgyrTbC8?19NLzcWw=0?Zp<`TLCr^v
zzMh?$hyEt$8%xj%&Jq;<)|ZdwJCQa_g)Xh5D~~Gl%&;eH19D3}lGF^{m`6NUsBaR>
zVKeFXc-e@*$;Mz)Ri*nPFdj)slFb=W9y<rydneh1v9sK^5u5KN*&bg7e3ywjrTyBf
znYIHI_RbCrLo$!d0J}l%MG1(0?5XU~RZ~+_R~HY<hx#H6pWYT7Fw>Ln!;wm1WZ1xQ
zL#Z7yg=#0c8FvJW5^j=c8)I?&#EFkFF|d{RQy{1j2M<-jX+l1jzRI$(gCqyh*+VH~
z_d!K{iMVflWohCGs#Tc&*-Bm<hE>aGO4-}D0M`(WI34$oxbL)e`EqpUQj(IAva+PO
zaDt(p{O-$IM6$Z&<bd{R6R_yST6X`TBaff}BVxypH}Btw_h_dwM-$;dKR8H92?Ch9
zGjR6E*KPeX^Y~~Wkl*b7*%X>FZprd};AVu^JN<1KYe^7=RFBTVajF`F#G;q+(Wdc%
zM<j#D#Oo0h5=V)Q=FuZ$5rlzF+6&q2HSGyc{4sL^$0Y|0z~I6u_t+VdKv9Yx-RH|o
zMn>*?xErdqEDu%O4-hP!=!VOm2PBIm`)Cf+Akn^G0UV8{rY8AWRa?*~ZTU2uo>^5@
z+OF@*K@?C$MMBsJuHdtkZEdZ=A0)8CB@*D_kxJJTv^ru;)afIGPLE!-Y0EdNhl`x(
z-~}%`(&lESIe^Xo3ESp#aXls(sEt#PvDX>@e!}8n!l}2V)kEXtGHV5ow%W%yShpvC
z{@OI4RU`@!%{MV#I_5~Bor6w6eYvr?*!T3)3YjB1G(Ii)=`&<^?x-L8%_M93<jq6n
zt|kYeBzhzjd$PA@fAHyjVIh`#^PNWbk(CLV!vY@i<5`kqomo^?&+J`1?61+=cfWr*
z6GiW~Upg^A6qmd@obNPaXSKqpbMxI}3%AYjGVB_htz(dQHo-mp(s0jNfjxqa8HIH>
z!Vh{H80<8eTe4^N*uc;8R1b&j_8;1Pqsh5+$7bg~K{P6_8<PP*SQ(VF@=jkgh%H_W
zo(3xo6$R09*G|Dj9|h1qZ{Fa@j}MAv&sc9xOdPaJj^wJhFBF27HTfH`tzKzC4b@}b
zf1k@6$h6|q6Hs3g(Eg~yYx1GCux+B<1CKq_imJPqRq}Mx7<RdZP3=;TyRjX;m&AXq
zV7u9cBg3ZOk(Rkg($J6T8r=_Sev~Z!=4qgkIev84*EtcYXMY{})NW}K{Ng5Hq+IK}
zfS$LRU9essdM5k3vwELi?c4Trt$sX8_D~<GfyuA@?=OF#rq^elm)b`$aRJ>t<3p@@
zgqcZT;89kc?*93rM@l=OaT*{b>+XIIT9NZKn^PQpYFp*b?uQTFb+@Goo_1L^LEqbX
z2G*V3XPFztI)@`xfyY{X=unfQl<K{`e5c(5dj68Ak4RR2dUS*Dua?jLog4r0tdJ0n
z#nHJk8p10Gwbf4k%a!D(7|2dpV&ib=vj4qT+hu_P%&@2Ljygc+4M?}}_1@*0Q7@Wy
zP+EjtyW4ooE!%UJ9KtLw7(z$mgoF_UH2_$)NlZ&j>~9>wi88c#re<^zhP^RD2<?}o
zjW`4RSdm?vjL`^OgdfqpeMu_w2nI%Sfxdo^QfNA8`r+<fQB<KsQ|4KYK}I~3zw-;&
zzrb!t|5MSOtVcr}5J$>CDJ$!Vu)^xf1Wx2R7?zEVQgl&v)o+3y+Azmj>nOAsgL`+T
z!B@}$P!lA%zxHH&${i?@%p3u5ilctv&hclmuHOFjEMwa&_t(n5>Jzv8n9w@?#T~z_
zS519(wjnCv^cOsHws+ko`?K$XhAG9a)4$?Cnyoft+%&JxY8}hQ9%FVqwYqx*eS%$*
zl5qs{r(0#FkUZ|!kd(d(ze|QaPfVTX52DcBZ=P<USOa6Qvd%xrTS%Mm`^lqBWm1-A
zQZAm+{u&AA<A>uE4+!C@JF@)NuB`@D0Ri1tyc;o%e5f$5Q4xm571Vh`?a>HLp4>)u
z4=7a+hy`BOw7LznlO^2%$dn*}Eob;Jw&<YGfR-&|!g}*L#r(n-7Me$zUwG$DFom!I
zfN-<Q_jT+n>wQ^Ru!TnnH^=V6p%UCcJ)a${^eMj;v)d1G+0UK(s#*H9{{)TH7x(L~
z%6N8j+Mu}uHz4C;?`%Q)%qK|qLvjChl<}9f2B=(vlarH+YQ+1ZIq^g+j7+SW46IQc
zqzs@~-rg-|U))+f#1#yii1n1l+X)Upf<D2I&_A-cFeI<!=~LpnDP{yS+^`$ZhCN9M
zOodfjXk^*&WoW2PcBwc5H~ekFnEfv(Q<4o{Qa*r9lZUDtLK(592OmK>g4BVR#wu2@
zNG~t6By?9O6#0`BTb!_*qa=V$49iC-!(t;BmxR2k&n+$3592nTvq@xyCTG!b7L8z*
z5f9YW(<4k5V?=lX`&cPw$Z#+;GRh*nds0{!!}e<|Wi4KkL0GETvB7%dKFdgT>FAg;
z<vTeNJmp4ekT$0A6V=ol30!x)Bt}B3;9ENx83~KoxZ~&j{cI1zrimZ|5fBW6dIXWf
zkN%v>3S7eaXuKdu(0g)(V2?61v`~}7D9d+7;NH|Uqvx+~<D<HDlh31PN?$mvS75U&
z#qf;Jn|JTj8n1cFdG1U<e0cI)(_P<xbOrtP=9A>CSrZfwOs*U(`jL&enK_%oBF;2^
zq@+9m1aP(Bs2BDA4}7Mv6JiD_FvY!i?>xw?5HOw(`<Q0Oqs>m?p57mAJCOhy@-#8P
z=9eyM>BYP*FJH!fv2{gC>X9eN-bJfIo`R4z*4D<%!;)16g;e~j0st%!OPD;#Zstis
z*msiw?bPF&q(Q(;qdZTs<pyGQl?fq4Tt>+DWxPQ^zUA$0|L!iBKJp1BpBf_lx56Sr
z+6%Tb!p9Rha>FTK3K<D<PS6X2Yy*w1K~CawxnK>DU*w#cY@Y$NfCy*s(4ju;roc-s
zwf9`PEB;3MMHbi%Xg<X*D>9){Y`F&rO)!q2CC)f^PCUGT(UPehz?Kcwq~>5tB_rgl
z6*Ah%?ysl#cOjIffOYuJykvOEA5SrZJK_k<I~L^SP-dJ{hX~>6jZAQ=%#Fgc%~gb9
zQogLKatKX55sHYgK$&~Q*)y5J2qtGxAUA?gCm~G2H2y`_&do$U6t2DJlp^qTf_ZAE
zx@T=J29L~I@U=z1>i0G;cW}t2)Jym2YWH`Q>g|%=z^=!HpDIQ<;}S{*Nixl?d?>1H
zjEYP*_ZznW0+BKWvvK8$wsu?hjxhi=1O*As?A0{GJhpa8;Hr)F^_a?pl~gDidMw0_
z{r<4()4GoS9ehWq7;SBb4;~b@rLMX?1raWya6n&Uxzrb|pF$ZV%*TTVw=;K8Dmh8$
z+R;IQU+^)~a!DAs?jkBQ9}GQQb?O%uIih;!kLo=$tE#Htc=(%487LvSbVwvlp2ToY
z*srmM{C~P>(&Rt`QB-ss1VsNtmLHQc<!P~28HNp{PWVO`v4Pg)2MsF6)Pd?fwc!Ql
z&EmyXwYBL0hg5ntmjLyUa8^;Ve94kYWM1=giF%>q3~C@{@D}e>7@83Nz96g;9G&sL
zu8v_QZX0j^=&@sjfbmaAqQn5odr_BkN`FOd<S^Mm^~9(}^f1zq=S^)@RcmBIQqkkG
zMj^h$*1>@gBmnzEc~$Heq@b``9a|;u3*jHfIeIM5oB?OE#1GS4%vhA9gsDNI-)Z`S
zopf6ok*cNN8rkRzN~o>vmN}tU>-4P|_C0a~@Qw(_NugXwP<}KDfL^|Np5C(L=M%II
z)D?WEn&W4<p%;bNP)Fw~1puHmIa$`?YHz>t_4?BYkAkt<JDVk_BQ#Pl7o*NBcLnoQ
z3PXrR_}>s@cm4bSM1_tZ<$(+w9!uhY=6MfHxpW&jIU}l{1B_DY$mRnK-IDB<`l5AL
zHf+<_V;n#h)1N$kOynX>EJ2#2&I1$E2{`^>r8trt+7EOryaELEjM20(tVxA7AxS|1
z(f9&A9gsW+*qw!<Ow3Q7a6QV_>vNu|Enp}7P>JE(NW|pHnKeUBKyN#qoDi0Oa!T&5
z_fzMpFGjnLk0Qe!TP>8efk8!`C&L<fZ|F{TWC`(ktagN*96XrSrYzJZ@k3eKBLnFR
z_dIzJbVftF{M(*PQu}M;%DX<hK22&}qr59wJV;zgab?+wOA{xCYPMW#KjBf@urQ;<
zGs=FUlfLU!hsD}j&n}G0jt(3nZSkq*k@qaiH->TJZTfuk&3SjNc-qEKL!AG4=`$!k
zGOuc_vojlY|6pA&@Tl*qz7Lxu>P2VHyzXNwGRg|5{8#_?@-fF8h75VLVZ*A52~8?k
zQ1Ne;76s^Sy{p@}WeS?(g3V2Wd!2lzTmPZQ6e7k{6yM*3ctcvZH)br`LQbxtazG*%
zPClzSb3u{~fH2`k$t)s@FX7upn(bNoB-c@w#PH;bo`v!5@g<b)g_;U|f{i5*9&kn}
z-={Hz4A@r%*US!7X40~X3Ie|n(P=c3U?ej&jbI|ULpFk(wNm?MJT|I2&%xU_NBH*A
z_%eJ2IYm_C4&N@XIj<dcaaB}HIbEgzEErGX1?I8`Tcyy>JsBbrVG=1S>VG-3`qQV)
z>92;#^cA6e@r0?N>v_=BtYZGbSldfu>k!eqrlv#Z$5FEgIU*bZ#UIv7MnKlhj6Jq=
z?4}JH(6u7EIHy2=g4`QOeajS$hP$PoOpcxsuNQeKqvA@l1F?^_+*wfzz-s0VTRBIK
zm<Az|5DN9{*EvCwVj{2v@CVcQjAGlx&9;CKcALK3P|`ApW?zrlg+sElv>&4Ux}l@B
zQ-ZlR*YUyH>kG=SVrSweWy1tl7>3j}?O_cvpWRhvJq|NgGY;%4$`~9XWCzhTZLcpQ
zAs&}`VmW_LOr$Ff%1yX1U#nKd0d2;`Jz<Mz%3;EJFtRo6KoJyGD7V2iZ5pynq}h(T
zEP1)jF^MqV`~p+5^V+osD-tp?hJ4>hRtp<oM=ahpM93fy2`NqtryD@E9l3%G7K9DH
zT^BUyO9=tkW60~#C{hxkhod(}DjLaMbg#+7z8~zX`31^2a&2@^2pe9L=L1?!jLO72
z|88KD%GRwD(K*cUx%t?6&bjklN^6CPBd0*{Uv4EqE<65<=J!|E|I&(*D--*yEGGem
z$iS1UD{X8ASPG_b$doyLBk2IF#gLPneRc~g+W=mM8n|1)3gDBe9OU0nU*83M2Xz&_
zdiRUcCB`kv4+b(mIq9EFUaj)*{9KyNn!JGnP0D`Ei_t}(iP>8K0v4;u+22BF7sey9
zT@;X4#eLg_o>f>m(*I{Kl1`nsF&f~<;I0ca(i%IKd?y%enn45(MryoGR$!C4Ck*i-
z7N@bL02eawJv~qlbWuiGJ7k(<!zcU7?I!dq#2U^l*j$vlJ&Q|-feht3lg2_HiY|3o
z=#yUaf6bL&8+lEgh=&wgUM>=+O`Ep6ObvHgyOuD{$8?q}RK)|I;zu4b<OSj|2M35?
zWX1&GuFF(FZ$lgaU$f=VkrR3Y6BXH;(QOuiRi_@iuV2rTxqp=BZziUutWF6(d>9z$
zkm)1<B1J{d%eheKIEp$tKsE^}tZ0ZlVs3U5&85MSCcohx8NS_Jodk<2gqnx~AWLzP
z5pmOou88I#^hl=nr#VMYQM<hQ5Ragz_XRr&hdrK2Zd?NcgJfb%3Alkx1heh|`LI_L
z2*$R~>IaeZ4X<C@2O5D8p%p*!`VX}HGX^OxB9Qd7N5(Vfq5BUwO;X;|FnGV-R8li8
zS}%)?bPIQ_lDNCO)7r{?B)e+qw*cv2N!H)Uaa}|t+$gcJ?h&&M;8$yVU#99nmx$hd
z{Z8N+I)z_YBUyIG{*9`=gCl~DA<iOO^X>I@{gGswn+slK5vMihv?jPd01CJ(_o%Kk
z4557JT3uz42soK|Res-W**W5Zj~0Ablk%KGfU@!jERe1C<QX%B{r0ibP$tA0B*X86
zO!C#$wL2sa!v#37WrCoBzqoL^_m}E}LnhJd$kiYYHZ$9Aq=s}0B_YkcXupXQP6*bJ
z(4e407rq`or0=$|u_6EGr!jyWQyD7NeydLEtvg_^GmBk2WGR=sqTyx9@V-j-(UE2p
zZfF=?=}~FsSZ#S+8IR;ARPUZjo6C+NTGt+}Jlb8VH^VWB(GUQtk!J9mmJ1dHt7)+V
zv8X09_@W$qF^S*E0MVJfa6{m~e-S2%goUS|wL>&UtD!HN-A`KDWVSp#A#LKok>CTg
zzgY1giM5r+O`ZCp^wW}~8^uaX%Xf8JH%q9;D-dRrhS_Q7#CHw3&Z)7}w%4!j{!ziA
z((K!}=?n!&JUtky=C9}zpRLzt$KGZ03op@ASZJ=y@Tehrj>7+$z%7ue()BlRdD52*
zpX#A8X;NvW^EyLF^WBKm?J^tM0Fr<Ge4G5~wRc2u!CaGT&X4Vg80h|T!&=K=Z}ChY
z*?kM5C$vlTYq1#rq*vcQxFO6JI$Yb`nKL6>S<62!>fVOr0bxO+4-YqgSGuvs&DSlr
z|Hk4hcBcxfMNXc?qDbzvPwW9EwB}}aR=yuSS}o(!TO=(j%VS6Tp0!98p#y6ve_^s6
zdDG3`e-<jtwl+uuCW{u;h-*U#?`QeNTD^e_Dx6YqA`vsm*VQ=h#iZvG)<>7t-fj?M
zfi75EX_WDI;)uqKsk?VEgX`gxqBa@F7Jo!=XF&myoKO=zhS3i#JRmwJ|C&Dh{9C0X
z?-poA@yw8UGY``?m6WVP9#}#s5(oSRYe(4I{=%7WTyBx12$}?sPCv!)T3?UVk_X{|
zC#fj|(`*0Po9jp-NVQAZ{cP!v{Q?TuPC`Ge!Eu^lPxFpVT=z9g9rRV`K}n=V1%CLj
z;IzX;DJBvWVSoKKTgCu@8vmQU{htY=1K&@)V$(oX|Ngc+&T1@+Eq%qs#@G40!moYu
z)bxv%Y2FWi^c7iYd8rKOymM>r-8I{%B-Fbe-smP0Y5#k#!OL(r8Qi^l_vXWV5u7tT
z8xoF9ID0F4iHk?9S}rLkF*0rAMT?lAY9U%LbKc=-GVdbJC>khA{id$|-u&oUE3M`u
zHpC8Qr;UcRoLx0{GsigQ_~hUJuKHWx%)Gq)|1dPG)oV}YsPEBaX-37IJh^Mr#s)C5
zC&{-AIq`iDM)-7h875h|`#hEPEH+Y)jCe3Bq4cs%qJKwK-<hXza$wQ|=J+z7Z-L{9
zPS>M|>JfSTUuq(fQ(bAMHuc^LR?YhMIu%fU3{tA{K_lgqOG^Iyyyc&7VRK{t6h!7S
z^ER99zZ*QQx~8|BWc7jygLyF~?|ONi{t%MfcGXt%o3+2Nly8kP!ma&Ncc<b!Bq|!?
zckO+{Cm*iaUitISKU?OhYiTKnsNpA|uy#@JaqlvS3wyh8yXa8X^`4QXci|aX-}va1
z!b<*4-l@&U3`IWM@k|q|&I~rWhJ{w`*{3(bVV6wJKmYPxoKk+D((%vCXwKj+KabIk
zndh!g{xH)1rD*QWrU`a>Uz{N)kXDWU5*oL+aBW=0i^09ui5m?Qg#+%a@~#<_W+xb7
z5p|B5=#TB-^1*%5Mh8xg#QV^AV?!xtFN6t>8Z^Q6qSq-z)FXb|ob%Xh{y>e<U+1d-
z{Vn!Uyu~Vkfk)i9t|(}Ra(A#=<fV-pKS>5R+Jtz%ko&yR@%@07>Gxab8JWv^+x0&>
z{qXdU{%+Q=e{G-MzOAT8XSFSp0ygF9p`j+~oWcM6<2?BkKorP8M}0oZ7N{ohTDQs5
z`HV`Vj9LW8U|4uU?>>6_O&aUV*QC1qbjYzdS{Q0sp)h!!eCS87+aa^A##%;KHmA(I
zkLgHD%RsJG;_jsXj7hW#XieS>``*rTNj^QOL(|)wZnoaSzYBm%PUlU#B-1`*++Y#W
zj3PpG`phYCC)ND3;S>BF9q*PdG07OCmXSkY&^{Pa@P|m`+cj*UrjH8-TnFoCw{~nY
zGCwd{L1g7V{vZF&z5hCm|6@Y2-?rM?i!QtDb}A|!?I*rnWY}x(Y>cixoDc=+W7v8@
zH-;*jWq<0COn$Fl3yvCiNRXoQ(q9o+xTo1M9D=kW;yu_ZMkx@c&<U&KOT2a+&@vcK
zQv@vASv#xSyJJm?P1sGBoX)A+>lODp9XQ<Pl3F5Re01D}tMQLFuA01X%b-DtK8FVt
zF8d?SMzweEb?><=ijCCdn4S63`9<RT2@JOQ_#}+Y-mV7l@M+HI`@Nw<Wli&|NE_b|
zd+|;^6F!HQkDi%8KP%KDuQ+6tId1XtdHc?6_0ht=xv$@UC|tGb<4D<u<yBE~c{1{=
zzI%B)L?tXUH8zg1vg+%o_x`HHfuQ%K1>Cr4BQ4W5Z(eHNy%TPe>wc^|XW>D?9N}Y8
zU9)$WU{mHI%9n{58E5p?J@pt?owt6cL8s(>zPeQJ&f@IHfonRd3!}uvChHwpn4oZV
zwHm0Ul+=NtWe0_S!%~;mnctR6*84Uj(J0QeYyEnY_;SIlJ#*&g>bjf-2?`S8`pR{d
zCW+;UM<FqnCX$J#E1l)@J`;$UkYeAt3&Qf>dt`t&OBf@co^Q8}WYI_!Wn?BCCjU!y
zXWd|(r${6dvMn|{BpD~2yIzc$#xw6I+#^gm^u~p^>*jh<E?zY;P6Chi?07wE^}zA<
ziRKaTkuczwmm2QA?i+W;OSLsAAV}{8_9IL-^A0!qeK>UgsN$W3a^s9TNK7oL7z;cv
z8wBdEIPklVcVynZr~68Gssp2e0H{Yw(hkX$J$ojew}pPjhl2|OmG1;Awe!^#ISGI;
z^pP7%FJcWQwg@eB=4OBcKx<e8d}(BQ@>-Bd;RfzmJcBp^3p~;KYQ3))&q=c3%r%AQ
zy3`N#8@4`9#M8AROm?8Btdz0WU-Rj2039^IOBOF?Rzxx{6GDD3UC$q>FU&8{Y;cuV
z*S{f$S}&&Y!-s8`#ZV%`q0lK^>J{+b`MPf!XqLSq7*k0JXtmOy{M}y)*Dp#8_9zWh
zGt-Ig#%0gCCIf?jycm<h;XAS%{7G(D?C#*G%#n|1AK?s}5Kxw+q_hxMFn#y0TRto+
zgklo*{H43S;N*)Si>n?QB8TyZRBbU4BOu`@-4iG^g02)_q{<;7wwLCXn#jVWO!74U
z{nr_BZtd6hrdL2DBm;Zw;-N%tBs924yjcjqos+rUXj(1wvhqG)5NwNfNj(dh)K!@9
z;4(a?t?5voafEffY#Bj+SyaRQ!(A}sqD>-Q2|Pczk+SrD@#bU3rjXAj^Q%J%20Ay2
zaVxKiF<(wXOhiDaM|0q>dXEgI&sDxHbHnmIDjas=0eRtelYo=>t5=`6r=MmYBCJa|
z5oD&Br^B?ssxiJ}dknWwTA>r18(?M%MjfEGpV(o09gH=lb*NMm-r8#+S?RslN^`=F
ztZXQ{?yjcb;NQHx#o}!Gu2W~%A)gFeKndUVwK*;u_Is#Q06Vu3ydqQdvKx4`-@Q6d
z7IBQ5IFVqTULqD7vGHZGwe|H~-(1&<r1LbRE+aDG6d*d%?*qt?AmF59C$OWJ2x=Lz
zaby;PVGv<MlxpbQ05#cVx})hOViSf3_8`RHxZzn}cG*I+^wq1ZD_7j;W<jT^)!boy
z`f!gTccAiv$g)EVGU2Z76)P?7Cs6(L^qp|#G9g2imH9ZC$a|LB0lV^3vMP1tLlI|v
z^!(BBK)nawK$KSLj&O<lR6=|tERvSuJ*Mjjd`d}4<qg8NT`ZwJ%4-bdY*m4IaZ2Is
zh(tVm5Y1Ivs33txay`jcjJ7NTx_p@f5k4oe9ME=&)=?BTmzSEKwPF>HmDV1$OGMFU
zW&OOI5GN%q&F|q55!gEO3s}Gy?ok-=g^C8tNlFTv2I(_FDcI@@v4r!Ngf+gQlG0?t
zR@uxWlB6*9>xcf19uCD;imhZ2iziWW*d_hDWs0E16MN}c{iOGHkrmgRBT)dnt~yK~
ztSxt^RsLmsZ5z}a`|Xhbt|T3aG&gxk&E=iKjyg`Hb24{hgV`s{Mia&fU@<nMAZz?h
z$d|kRLR!R<B0NtpWqBKuvsrpPv;7d#LL9|a%z7Hf%nSOXJ3&gymw=Oh{fbi$#)=_}
zYwk9gJ5ys^fRP%b$cS0HSp?Zls|7qTIM4_KvViqlSdc;th)ef`6Ju9)7b`vSwb5|_
z7Ymw5ROd3orV&6pTv71`(bTFk?Ic>T-3z>f>qL?8X?~rte^&5Q7ROdp2>WnLN?N!l
zQ7v#Y-9hzC8lr-SNXP}J<gqx31>%ewl|G-cnPFjpxe0i|ESL7f6-j)_PNZ*aU&n|K
zU}kFC%t(cfhkg$^7M>T@l`y*+4yXKlYHw{-o#wgUOyiy|siK4(m(vHFwK6+vMRdh4
zUIpPQ(_*{u_`lzBi<ui7fsETfXZn#>i_zl=P&~G7L$A+5iah-V^{U3>J4^<1D<}j}
z9LU2UG%%98oc22&8M)Zj7LJ^)k%Of2N1yg(8zEjOZU{P_<*WT_>e7`D6wn?h9xW_7
zJ12z1gE5NFE?RyQ&^QHS0v0SSWsV(ixNUpGD`mgQJz6ovqZ|7Koq6`mI?(7{v#tMd
z&?O<QBhB>~Z_25A=B4M(soChwxV&@C9cVv$iI{wZfKb#{Wb_JA=OU4KU_?~ZS2S^K
zdZ8@w%Jim9`+*dkNdkW!k}}%tx7}UoCF`l&qa}<XAh~^+#OW4+T6LmX@C0o+&sMt)
z+W>?&LTOO|7kI**4s{ScmZ&5hp<pz8TXN9?jh7jbm0WvNOEZatViM=4a*86`?fx*L
zTj(Gll{Ri{_zw@k95Cx=<0Rxbr29mgA*W|=Fjf<?PevUxM^H#mO``Q>ZZxzncWC0c
z%kW6Bu00LT;rHL+eLBvD499MQHIF;$)9$YCE^HPOS~xUu0vtyy_md|=ayGCEFa-(z
zA$i_(ERn?_0x`lp=XD!6la(%PQy^%Q9X)`0XwOPfg(KKzgatGawwy1DoyLXQPQDCJ
zQd4CX<xAkrc<%Vte6_az?4KWXMn)v{P~!p*O?><u?Tg7P2Y+i!o!C?41J<0Fo%?2c
z^vA1NRt+Qa^VCWv(5q@Z%U4)@-nuU3j{@o%GbcOFx@{l^#*vINEmmj(O4f@+8jABY
z<k?qOR#cQoa1GNBsx$C#q%Vjaz@59h+H>BruN5F?%#w?ET^+jy_hjiZp#fSlqRWJw
z0{mh6M|D962T&k@po`0B`Cme|j5r6NkDp(schx6`y?iGa@*Ztgz|x7kh|HL%Y=OKK
zQ3YjwFA6xVrDFvb==vL|`&j|8p;R+_l|Q+a$Q(sR$aYvb0bVEM1TE~r>roR@PH_uE
zIAL|7C_H-x89Hv<I8u<0j2<6dBqq|3uj3j%DJtR=;Z11~2SXT51x|Dd%-TC3GsO89
z)d+G&DiSV5KAgG#$gT16x|Nf&I-%5$2UAy?ZEZx3O9nw10Sw4V0$>r(@#fl^JWfT(
zR}h~Wol0|BH0X_j^yY7Hb*&dt$OvnWGo3Ro_iY!p34eYrO+{{yk=~HBuEmDZ)>Bxo
zx9TsY1mG(+L=lU`rYTre(|B~aeBVV3p>qY+mYqOoSV`kl(?j1vtHL@nwAQDK(`~gW
zWe%8oM553Yq~;4jMFdh3ZzK36%FDmK3zj_`-Oo6J<r1(R=ylX!HPqyoev4|LVCm*K
zRvw&SYcQ}y#^!lajcR8<V?T1pQw$x*A`BR0wr3x569ts4$8spF?jpEJ1w$rE@RhGe
z<#tb-tSdd8TYVR>$5uO5L}Ifi_g17vRBX#Q_(ErWl@Y$5bJ1*)OG@W)n<|2X#r%SN
z#;_q@AyPSqG%%TheBYLzZ+3FR>Ed~s{qwf4=$)evDTVzMB&8Lre3Cd)p?jDnP^{q1
zWn*)6!rS#)abi6O;wb8j&X}og>EY|vdcEDY=<~P!CNaOjpO!B_UHJIh=~=5kZg9}q
zJ1Ah{qJ{uHW8{c^f)}q|4bw7V8p1{=eA5gJb)LY<&0uguiA7(wfvW($_38M$Mye*c
z`Z%0A)*<?GMq>IAH96QKk!ar<;we>B>{hHGFaz_@Bt1RUg9bhN&)4GM4oAivTzdQR
zrAq+kAme63#e_ZNER<-fuO|RHaLp|)0x5rWp6cOrA#@{98#87MBgWwScUIx483?y0
zP|Uf%Q!EoUx(g{WcQ}&3O%X@E>N|y{YO2c0&&$jA{;~rhFRf!%B#JIPd=Y1W^)j^g
z2tURi6V4bN+iQ2}I||o=?&H`l_)xj=f=wb@wZVo2?*veNS=pYl-X3`$T4;{@1amJM
zADBnir7+qO>Q24Of@z5uGj`wowJedo4M`FjXRH)F%RFG@kPsaF<qHEDyeHd93kqtj
zLuP5Ei}gGkLn6(8>Ywa7Hm>uy&Y&OP7bmY)d#FJMdrNhp!-^G+%U3Ua=P|k>y7}Fi
z#ba@QeiRE3U0a=FbaZ8JT$#g$LDvF~>S&KFcGQh{462M*1fdM3FrD%&*1q0INA&J_
z{<O$rqPqGy`c3eAU~UqkvB2gZ7$g$069a~e9?v;dXlGG$&OH5=sQYyf71^s@@PXhT
zDA?QHUzK$1@xQck&|yEKMaAg>AB%Xy<PJ5CW`Pclu6+?(#oxTS!@ipP1<!A88hXfd
zj*|}&ACAflWI}}?XMx0bwrB|ZLi?YJ6%(<G1@@DzZtyLjk?=}<H*&2fct(*l34VmZ
zG>1ecqSCD|6U#)YMQ%g$N=$KH6*CM^&;(F>3kz%s-V{;}@_rKcP~Sp9k?kj+4aN=_
zj9iYwPqZOHIRYgPn5D1JCP9D<nh!oRZW9^RDW6e~<6VNW!_+=vrmqlC_2B4yjc3##
z*%32URa9VBa3vb4SrI}^SPDnJV4k2i(?(21ONK-o?7sc2zrT^l&ae4q@AlWJi+t=t
zRtA5%(@nI9`<vU|gF8)5xZ&O9=s4G%nXUyQLpIydBD&Ylu~SPwnY-70e5!Kj&XS8~
zCdQ^~j2hL+`MZ9@)U@4x7EbELrS*R<T35p^zB&3TGshlCE=_THV&Ayokd;osKco6)
zCnOwsvAiU0p<Sh1!8c3E={adi(s_h}j5!mk94R7T95YJ|mh9pC1dh^!8bwB3$1O$8
zs3H7;jx34$AKt%*(yFYxC*3EnQucX8g~6mr+kUjx0f{=NHW5BRV=``BSY8#<W$r~x
z&rwkd=#0rczP0229HWDq#RKIO6zKf^gyTXOM1~sh+0mlv7BB8B60BjL$!adHh3iq?
zH&;FK^y$;&%voufm;zg$moGu)0iyt9EeGJ;KfK_p7ji;f5Qq;g5n7rQK@=9eU}!=<
z#*bJD*qef(fp{DV<DMid78$Qy#S1tX7B*+cKhzOCr8LzMH^fqGNfcvoE)sNU=|_(r
zFSM|LdS<M(Odt!{B1R8Dn~KP*=AeIC*NP-+=IKRetpJg1wZRZ*kI7|t?93KjvIDWH
zAu_4n`d~>!)Nx<{FfraTcPhc)^74cyiqzN(zqJjjp0CaM3IU`Hu6B2k{(b9&Uc1CO
zA~T3uhu>VXdGm)WD_#@Q>(c++Yw59L|6(K7@z}>F|BQ|MU1g<zj<L4$-v!(H_MMS5
z;GqO@URa1TnJrQI@R8bc`%m4h>~!St&VF(cjkXf^KT1nUO<S}Z#|le%EfesjV}FNO
z%I=L|&*rK<t50%xQenSSUjWm1+?G>Sy-n2%$rBT>0a_>4cEAcgb|xKORmR}XXdN_C
zZtjema+1_~`7^U{l86GbVwFSz`A*}Rj(Yg*%+$cj#YW7Qv1S~wHdky(3fL!!(2ipg
zvM>WzfByaZA`x9JQ}W%rMwr|C1dq|u!XHa%c1n3(P%tl{l!XD9NUdqKAT0URXUm}n
ze=R<6Xa9X`*tFEpkZ6+_d94fO0i?2;+{HzwhZD+!TGnj`N)on;7S+7}`W+OWDZ5!s
zowPT`^7H34$kT~0LD=;r(~$A*K>*{>;O`@+Pk&XqdB)LGGJ^cVLgzr(BDNkGsp;}v
zRR?Yz<m084F5s@~*11TCmp;2NKklEJ&AQ5N!ND?%HU@ramsUI$HMMcvh~%M10wX&5
zCnJgAjAx!fN#Qwd!a?!Ok=I_hrSB9I5#r&RwhI)1cH@CU!BDj0;(-Cm$?iIDpGt)n
zoF1Kf=%;NjvH4>=R_={#UEf}~55drdI0SHLCXe(1EGG+SU^uqu@K1B!u~E*!%X5)>
z<ZA^J!vWPUvvP8tghU!?w!drnq4x8~hh^CP%m&yTovtdtk})QvX~$04DjhQELV{0U
ziKjgWjtjl@+dF=}di_3b`HwJ@sMbNt6F0f04G^8FSo!0}ql)peHUD0Bw7dCcy@b?<
zV{he$s}33~eY<RR^!Szg+#W4@u8719)9HkA-*+}F0s+>WK}-(-o~|^Tm1aPw9N({Q
znxW7$p3T3HU~hrB>v8R>SuG}>Yc*b#)}MK8U*`HPa@0ILTfxEK=FeXfXH$E`?1JXy
zGS5yAE6sh&ZIZK7#79qwJ!qtM%b;TO_Rm7d@8@-6N1Z+6bs*={tB{}|J+ZsGhEU8j
z${};ocWu{l?R?ut82k0>rPFs3;D7aNd&0iGXRB8Az_bbyJx|^kqC=3&qB1QxXS8~C
z>%or6h{=^85fpz_)h5JFejM^RuI$3({SvB?0h2Ye)<u}Dvy{wyndPNAxj}xA;bJQ*
z_gPkbMZNRCg4I}Ge&h9Ffa;T!-JRN=lR9oDT>98b2Ax`TyI*%_>-qB^Ll0iPWB158
zAz+@uk4ZC<Bp)98@@V=9*Q6cV&0~EhhvffioYVexXNCBphQqueV`0=eP|NZ;AxyW@
z{pXK{%d@LA9!t#42vi(2%sTPdDTCVA+rpohX8syLhwIn){8~bqQHIn(orqt*Ub(G#
zdhD%rcFoFy>g}_I7i#!l&k;cCz`ecq^26q`EZw0)yvAH>>|cJ>151vMiAt&O-h0W^
zKF&rAT%vc4X^^H^{24Fh;M^^(A5#=Y+x`2vzhlaN<%0=>W@i*K%_ALhcKP{w?6FmA
z1_vx2>}YLmV{_B{t256;P>@GMU>pw<|J<0Dw%I1}kE(k{V+VCc-|l3L+G%sOdfvQk
zTW+n)d)2>YpSVbL%?B9nD=0ES#ie#aCEa!ApMA9$f&ix~|CZ%`1Zf;1Qe!KVg|K6a
zX_79Qsb^>ZyNo|z!xZ)Nr>8y~f50+f`nHR$t#v2sO8p4WRr1+ryGN@6CcL{oG5pff
z{OtC>e|EgqON;Xe@(_vSrqpeiYt=OZL?I!e;J=@J<cv%}$i!2Rh2-U6*_q0N2JN*+
zdq5P!h#^D7L=lD607tuE6_Ibpz*f`Qyx$?>P!vK-DamDGx8@=%pvZ<FmKi_3a;TDN
zR)fyK;o<wLEB}S$fqH8{p?oD=cCXp(-&Zx?ndujC{NLJnGs^$EnzUV9?eh&&E&r18
z^6mdAIZt(}g__J}DzVpjc5-=q$z9z?H6F!7Cr_F3v9^|zCSo<q!=67^j<INKX#q47
zTDvikW{;dFg%=Rj==H06g&LCXo~87H<b`;@J_rlcwcGl1pMo%>JwrP+JltT_SDL_T
z7wA3tP=O(}U<VE|P;8cwW}Y?T6AsuVHP_cuSQ!w{iLX&UZl*yt1E+6v%d{cGh6(X<
zW@e6h-K$3?gDpLLXkP8YSScThgxI}o&SLj|?uRy?c_p7v8gu$|_Zy#2^b$)hSdScx
z8V&vHZ}No<qgeKMH*AO}=@|J4A0n1v31d+JUD-bbg<REPTS=Yw8T(PF=UMyxv%R~b
zrk;`V{M<0{&Bp@dj&96bU$*&emqN%NS>0WZGA`DGyGDeY{!!Y{BnpTexWFgtAF9r;
zxyTY0m-GugU(xw(>(}SmKA<!vZs<N&EnVt~q@tx4GH<fBh2T}-_i^Bt$RfYPMiTUU
zgY~)Oi*N>wW9;m4JBNiKl+=4(wFQHu>hv9t#y_pvBKSLz_^8~NfhYr2(S<I2Y5k?7
zaNc%=G5L`~1pPg2XR|$K3Mi`YLM-N?Lt-KVf&?~L(|<8Q085VOO;)mm-~})STdOAg
zCbzE&i8V@{#O*$aafqkhvN#aaB|=Idr`xlb57`IQJH~@in#h$qzrHL;v-2C!|FB0`
zP@Kq18gbhNYZzt%rLo=VoV2)DQnHwRz+Np*duNvbAC#91OK=2z6NI*U<o@DX^a044
z=!5F!pRpfIM^#>)aQ*uJjEt_he|p#ai?GjiW5e!WTT2s@|9-tadjD+WSw4%ehS6BF
zx#F+#`gia4pK4b`@`Hr}<hW<4Gd&qDN3Jy;I01_L4zgZ`Hi_ANnCKmtXfKf<El_19
z<5|0rnMuF^9zVaIZ32u51%s(Dr@J%RN{iW+C_k+U6J~jRK4YcDklj}d5#jLfcOc~1
z+$7{!CZPK2k$K}L#YQMZ+(-4SWF@6Yc^{DasmHJwC|{7d%ScJhzFCdW&_WZz;Df`M
zof#{ix~8Gls`I3|#4KTxh%{YDJ;HmIcWw4rMxK=%rp%c<tWKV3cH<=wLgu=sfBoLQ
zJSS}SSx{6yrDNuM^Q!2@$Xz|UHF@N@vvx_tRaJ?SMW9H(jiUr`KhIb*id21%AE0}Y
zECWd>P4<1rL-#H>7@aHEgB*X0i&!dXzvbjaA{Y*sx?S0;#vZ$;`v_m$6qaZszogL{
zqZH<#Q^CAOZVyB*y0E&|mGM)=9&QiX-Orm)Bm==<nd&U~ubacjt<YBDv17|qrE41W
z7n9E@e=;3*Fr^Uue7cytA5@&+`*Cp+54WGKXqacZuUD@R!hyDMUgEOBgPQtFdA!*c
z-eJ?P%Q)r{Q6{!Y2hONvh8HhvETJ6&cZ@xGlE7;b6c$SY2!sjC50XZ=&NPkl`#1T}
z9Y0rZcn`SFTY_B2z~0>0_>0u+mA1B1HoeqOvAvD^Ktz&`FHY5n)c%;&3C!yg{KC!D
zecp}&PKE<vVGA{d<#tpaB#G<`q*gOjU=@K}5!zqRX$*9R`ubEjydC@zoiKP2<2*8Y
zeo1&P^f0Dn(ke>UlhqNphBzpcNq^xsO(;d)hO|;7V%I%0DTd*5b9kJ9F7cRh`7K;C
z>~ZlG5mNu_*Xy@M59A5E;1-KCJ7`KaIs6$AF+mTg3lqx;3%s3`C4gEB2#v*?@xl$w
zGNCf@@xel_jW_8X3CYRf+%~gz`!a_S$-vbh5s9n7jMMn>;}ll)VHS=ULuM11bNVX(
z<;3s-2zCL>SORuf^MkoDI2TFh&dTkBMPw3DrT}g(mAj(2+g`sE0e$;X9?8lj#Co6}
zGaeQ&U82=zy$6!~A<|^-V_UJ<w27yJ&{@;2qmhvldu%=!R{5Opy#zd6bo5k6$@)EO
zJ{%lEi0cn;yTM0Kv0eCT(hMxjnpG|7wr2(hTb^57@<uVLf12H){FkVaZ#XZ!Ve6}q
zHJ`wCpq2Xt1*1&YfEzBDkgfmb7ou!HF1l}7!_T54Bl*Z18`0pAnvcp@O%7!xVi}AF
zfZ)9VS+h*kp^F}LAW?=p*g;0#htnujucxL$@#20Ebd%+-==XO(@U2)ufHiw!S6f+$
z^7tN~fp6JJs1!C{Tie9VPkG-+N#;?W_3PI?Xp-e5&~%|oy3pfPFRb~3xrRvm`_+Vl
z*iUHz8^!@pZE**wJ!+Fnm(~NAQ7CJ_H61Ui0q1txv}uOtN2@h!s2zy#AprzH=9I8l
z0Z1Iugv@*r6u5wJ!F+M2C079Lk@uHM^HJjgRSE*if*`o>rOTFWNP9^}O8Zf?un`~6
za6Z2E?<PQJ)Dj(SZ5XV%7imgSuafWp1l78$Q$RwWJ>&nOPFAkusUboS63h(vX71_+
zUjEs$Bh!cO^LP~;C$iAdke?6AVx;B;ST=B8x6tqqr7aR+&CaW$;9^-;l^LxRh7-du
zX~M(b&n-1?s2|(n#W1iaJiK-lP*veUc*sJ<`1ty=vX$DwH*?+^Y07sPKKvFoTj*j3
z8AoUsRGc<DuW#`7O2S>xc6gwvA$dbiUu$3!21v2M2UC|Ywx8(U<itj4WLVZO*%rlJ
z9A9z*Wu50VP6yJ|+8bYB?lAQ4Ua)WG`<4!}iV=4~*MSBQITLEa#5_!9-nw-cW}n@E
z=n$MWaY|(D;d5kbC5m|-MwUKH@@Qerq})*pcoet`p#b+?LaGYKjS<xFvk~*9kIzq1
z#~{QzB8E%g&P*r`)u<ea1B8wg2~J#ImHko|vPu9z;LrweIK9axf0+UJzTXd^Hq=Xk
z$O`*NOFI7wFVf)EzL5nV>c0Kpu_u(H{@eetbmjpyuI(CMDTE{$N}44h6^bO4R6>*~
znJP(=gp4H`5J?h}qzp+rNl21Zri3JfBqWuDqEgCG=l6C#f1R_xy|r5FUC(ph*Z3QF
zO~X-;g3d)GP(Qrp(<hyUS0sW?!ISPbzf5N@3Sy=<a0(DP9u{~s(qiFTpy^z5gt$Cg
zTa13?5KnVls?0fu;HO)M$G?4lYMAJ7C?B<aa3TvXOy{6M(UFk`Cc4b8g39mGC4%m5
z*mkq?nt-D(Zc<qvr8k<gqwT(ST%%{}S99}=61l{4zCMehk_kG`xqm+<Zuvg%^s1Vg
z!BR^jBEH4^=9&jeB@g}W;y*RSFdR^xM0h=6V1k1+5en+WLsxYfNu8)(qlXd!xQy!N
z(z+Jpu`^-e-dr7SVzL8<k_$e{SD$ZRaqaYkF=}c86M@Gy=oFBQRJXZ~j>zX=9Qc*t
z3N0+|VdUf!ox5NGO}F=Zp=m{k{ZImdJh6ulI2}2wEi87y!zzbEhgtia=>>oUxC_#_
zovPrG2$$!)G8L(^BdV$fK<P+IQ0gLrapxl9v3L*w-PUwwb*tYFMC#%BQ)USx#?IR$
zXh0i2xNJtIE>OnEk??gWj~^TX_2mQzwek5IoQ-~5A<Vj7Y|q_=fPL_Xq4|}#mw+M&
zOga28DyeBK1$wG7_iYDNw{+Vi(v(9Cz4Nx}X%hw_%#rntr$hn7Qzgv<*Cu(6yui05
zh%-KS<ST`SjOj69-G^J}X6A}J7d~pt+_6gQup&J)RS(|({yoI_{iwNZD~<J}+WjAh
z@7wdN_Nq?QB%|Z~WWD>vcZi8P$DxHO_N}ttMcIz!Z{C33`!IqDJTx<MxM}-VJ~keu
zQcv=m^rXHv`vL+D3?*-xUa}#OhBO1@khbN&SiiX1n}8fn*)D<W8mp#hXt8BbpvuOB
zcH;2Ed3JU`;7u^G03kD3oLm_T0?07bs-`EEEL0r-%9!|8Pik=3eFBCst!Ok=oLMf^
z7B!FmcbWYTYvH1l2dPBJ%z^PC!<+U28F;ujC<v=_<mM5w$k&!0fXS0@3vhE{am4Vf
zxlGiCiqfHZ>fvVUL8RySb?wOJr$_~N#;xfY5h5m-OuUCkOeS8k+Iwlmk=b5qPi0h#
z7?a<bY(ZXuzKqKO0VW5Dnxw$l!DfV6-6byR_U(Bi47ka)`ZL~P#`7GD_d^J-xM}l3
z?ATR)`D@qgwe1@ok6j;b;@hua%PAXKPGC#RRa*^PKkOV1n)D?=RX#XyTA#%W^&)qK
zCg{Aq@A>BE+N^8?{TIL7OeI6}p1WTq{wSlzHf5ye%%~FlLI)s<1rVAOr=_WBFt&gj
zn^yBtf!bMXFii3NL0lBPtd$K`BvSqJ%6j8d%b`Q|^s$!qf=DJN1oR{3=uzyc@JqTv
zFvsO3I@Dw=y6hrky<T?kT)H&YKH1WSAaYenz$7Rez7fL{o9+)@yKB!LcyXtn#OGlU
ziGRjBkAxtd!4cudGh`jfFC7gTnFzSEjUH2d$4#;l6)kr)k{`;dRi*bJM#-L6=7yMz
zIvTe^1&tRYCQR_*sKhSD@k^ef`OOH@Jd)<^vuTT%s*HZ_=J2LAKb<H7noy}N(LvT(
zgy4|hRW~7S+asKp(06aK@lgw-5@@!LRl_J22?gFxIADNTrn7;eDgXUvcJAAOX7kL1
z$!H3R2&|G$C8q*S8Jd4LTiZThiqeX3vTN7sde6y3m@Xg8!$;CNXLnx}vRl32_HRCh
z;(kzEY@TVD`?s;+$GYYM-F(v@X2%jYO^%l2175Mha%*eKFYl<RkyYMlr5~=GSrvG=
z*IXC%CbzX6Lq0ULl0MIU#*;OpYnP?OAY<}*&mqP!tR~s`>z5NBgOIr8-_cH-<*!Rz
z{VP|lbeb1LL#U39;LVf`;c0+!Ao+toSfZn$pdqLcLJwRGs7$VPPthr=qN!)y5Bzx+
z4FKsm7!^K|y?fH+pHSa7af=Ss;_muF1{?R6<w=B{Cy0N~bBXA=O`uV!ZN8GXS&d~2
zb-??~4J+;KU#)lrVTM3pD`OGRi{+#4nKO2rgoHxjf~fCu3gjP;!vJ}C(l*0wCQO(x
zNOTLO*36h|&^hwK<k%b>o_OxujU^WeD!O;?9@7Vc_(uHd)?My{o4xj{RgB;YM{=fK
zqrn;^yb@9xqiqD+4=1b8eg%FENxh~#=U=F9j%tK8@7532U36Vf^-h<G+t@BhPTX|e
zVDJ7}4pak?dehPJq4D?nskZ9D?FQCcJO2G5nCKj|T|=+k-osISz4U12@3>X-EBEId
zn>o+JF1%a+;Z}fo#9zT6@KbyCla+Wr5IjG4lis)E_k!bzn=*||+Rj!)IT>vl()ugS
z^k={2TeNZyPM_)E=|Bj7;{2=)TnO9h(woCgrtkQCTF+Q{Lt~Zuh7GT0=x!gk<MD-b
z+xw<%3XA18R=Xr;_+^bSsk)ul>q%BUjgdIEGs*<x!dbgXt;s=y{2aG3Pa&Cr5?ST4
zdtSMUf&zkIG)>?M$c{qys9#^)OB`tZaB(g1M)g7sR5Qmc{b@k|F!n+%u^q>0r=g3?
z&>qtVDJbAaM<_-k7^5f4rL~$rPb60?U0ilrSUu`CZ{rC#)R*&s%pJZ}MzPji)wBmr
z+>r<;ja5k_rL=bABJF{QcKqaqSpGyXwkQQ7f`$4s;s6TWEEEpSqoR<=9aYKUEr2E?
zM~raLw&%8_My;C=QXCktYXL}Sr%SiSB$kLC?1pH^9#-{Aq=%CohL+arOX_(TsEH#I
zX^9SFh^4d@v8!Stv@wkQo#ERsp3wA<2}4C)6`D6D$EUP)`0DgUTru}FVPn`dC5B}s
zeyjBl$`u=aaNpnk$FE0;O%gk{U-jhFxK~}OyJ4((Ra`vfw0mRY-!o?nOLS#cG^X){
zhYc>DF)cH1Ux(_vdHbz3tc>ES1=KM7`Sayn0;g$J&9a%a&{)}@r!<?xfV`s36Gd_<
z{cJU4^J9Y1`e?|iDP1{Oxf)^QwePwTqc8O3*B}gZ@L)zBY_OQc>$i`;*V}BzeP=zE
zLpr?6%T;RUj$<+7)!%j|N%P8#nVnVeZGJfg)#l29cPrldaw`8?q7xZG0fg>j39>02
z9sR3+_LJPz^l7(4QGEms!SUlU7~*1X$|-%9#tOP@SqE}L4O!i>)!fwZsh#x^Q1$n1
z(E;;}kX0`q+*j#-u1;mm7{_lu`-?`(n?9bj;z*fzCy}7a4h^ZQKIEacy?*q5<<sxm
zrKF{au4rgGT4Z{1`sueWsjYoXuclw~p!MMQsL?*HC{I|p#%~)pTkGbMWKFfc|F!>}
zHdWo}va{K2sj-L6b#78Mz#w*IMZt+#iSN8}&%bk0l-@GDUsEGDH!c9Y>fVMYa^Llu
z;$78#Jg>vV%P(ax4SQ=m-fA7(XXQWf)0k!-ofB6Uf7m@Y=hKR*nZ;(NZxDnA1qXKv
zvA9z?Va^=Czkl6@&+|}mdAa|W7sC^-Of;A;({Dq8Vyj{7x=rb_qDyNQM=fdZaOs$8
zrLCm&X2w~&Gd2=zaNe0?CQQ)L`{CWKdWP+!^}RQ#!sqEWCz8mfF~`s49Mumzm*iS0
ztUeIr-PFl-gnS@jo4ikz4#}lgG|06YoKoJ7gp``PiLukAYwXXr*RH!Rt)lGdZf7ul
zb=(Y}q{-XI9f;B!;%+6UH97{OsIa)_`)B+okE4fB4>>m}>QDV<xwzcfdeQwN)_tRa
z@j$paL{jFUPFa-2I(Vfj*GEBJ&963<C<WnT|MpE<`kKv2ou5~A7VKKIX5wbg2VPs!
z^=lu$6PsrI?ELllJ_n-Bt?UdZo?m_89zU#>SQhYJlNN_d4v(+@eNdiTzWPPXMVl`j
zqbH3wFfsVz@tq%-Y00(O|47UeDx_i0O@C|Y>-R5Ayty-AS)v03YW2VeqH)nD=Ffkm
zo9ijt);MsTa>LBf`(6B0$LfU~uUhreuKnYm@3||-C}HF?`nNVHZ%g~SUFyAuh~1B*
za#PgR9rK4kS9sS17>Q8T$A%3a->v)d!-w0nU%Bd@3ighNekZ7Z$=jK!3Vu`UMvTfo
z&^tZj%g%@EJFI=g_e@@%I!sCEK1;MYy~L!o`|WdkhHT^l9&sRUqgk)h6-%|Ww#d4t
zOyhT;T>`9>1>DxS?+DqYdBKX0Ql1FmU2Zprs-uZoxh?D5S%=%2Kdu~`G5W*D=AqLx
zzLnQcihn!r<Hzgz3cqCqrb6_zpYVRrp}2O<8fr>Qva>JO*1osV{9U*`k^O^?2WQn$
zhFi_khNbpSdg1r+`bJk#mZ3|-hT5W~8~5jRsaPlP?|(iqGP_@(>VH5%d3R8@)z<9E
zkq}G;qMs6?uGMaU210nt@#9xA$`AZ%vFbIpeDb$<f69Y{(=0xYlCfSsX2Rk{FH&mu
zH@Ud|z5Y3WM(@Fj`d6>Idyb1rY|icnoALc-lbiRLrs*I35vbW+l=xXJ(Y5*<M>A25
znI}+7H+|}{O8=*So%Eer#jwyJ_wLVXX;qO7vW-2o<LB(1*TQ{lKRqt!V=oYdqf~Dd
zPcQemb*aE@Zo^hXMKARm9gcg8YwtPhanA0%EfS$N7k#)ha4C-Q+UZ|&J}URPdx>Lf
z$0q3d{61FqS>XkM#k||wy)SnnJO_wYkac2ptOnDWg<29$-a;L_c9nXdS!<b_>-f#F
zsi*%0zVjl+-Ar}Kbr<lM*e6YHVs|eU*X~*-U;B;LUoeC}wQ`%abM9;kR(&9>BNmcD
z7{5a-6gqyNu^DF<FZ|A^Kz_X4P&8nmveOlds#QzvG>`xGo#rv3sXl9`ams`8r_WAL
z+Pd!4MX!yH?vMJ-jr(!cNJ}o?Ym1`MJY%EZGAI296mDOu3N+5iuGJrfq$t4rG!Ukk
zTx-y%QKJy3RMve1o+U37u^ka|-Ma%8=ZD))n^v)|J#}gvS-9@{48!AM&~gnB9Xxhy
z>%VMbjurzzg4s{$GihVeXdH9!spK7S1R*{m>c9>%e~C`&g$o#=d-v>lJiwBEbnb2b
zLk-!bDK#570_yAQK`zfFB!uNk-~GV}PoW!v(5^upBd4A#`P%8+e8)ck6~;6#U_!57
zBi%*u0jImU_guoM`Ne3g06Syx<rN6ydSme9=o6>Z%y=G^6Xy8*_;CBtqp?V<I~oh5
zuC^8_<zd)cm9}ZmE}NFm9p^NgSDrMe??^Q+G+i_MwYuPiSbt<X$WZR3jjIlJAM%J$
zbW{U<3*Nh2CcLGRv0c%WUq4rn7w2~5(EIL$w*?*B`x~1^ipUUxl=U+>0LVv^-1Y7R
zs0!jaMql_lNr^zSAH*+}dX7IeCZf>o>$h*(T3Xj%1hB3M;}dn(_)mrIgFKgq1qHwl
zZ_yoq!Y$D`dCc;fgEq;HO$`m1i@rJ~%~Lj9_kpSSUE0d<QcsibsR)W7LwP-aEwdd#
z3Y|#If4hTg{$)uC<pY9>Uuadw&;W(=^2=I%1#J3Yt=#Tb@q^^$4Zq*&zT!$J7y5SV
zk?FP3W2f%5AWc*?EcoQHxliH9)ElCvD*N0kPRlL6T>3)fFlj)_`k|h0UK~9>;&sMa
z=Z^Nk6>7;Qam}L->zBTZoJi1?*X51<Bpt#f<^q^fT}N6nDYsJHHt?YcP6~Y1peOaC
zdA2Z=lsNg5HWs){K65K(YZ7|FjYokbi9S?Ur&C`E+NAC;nC#-uoB<>{=meb0L_B}V
zlKp}afbWxyCWHW~(LBeRhXG6x4xy(~lcZsn4Fn9@O9@RELyDQ|k6*tM=X5+e3}gkS
zhSRd|@CSKNc41cNgZP2eqKibr3m7%(d(Iy(E30lK$3A|1wX6<M<k92D*h(JU$E8S8
zFVXdrcd_Ghe~SVT2hq+2Lm6$uSZJ+5>K52XW#!Hj2MNT&!GH<w`}fp&BX*msop}%0
zfk!rS`hXA%uiXeIWXEDKK<SMCl|Q7|(#?`IPxEldtVDheRs`Ziw``obX3eNDD?YmC
z+`NT_m=#2#v{Eny$-9??)Ck4;l7!S$lt2t5t_z6?;161B6b(RwQg<1{Rd%#4BmLkc
zhMP9XI?r)H8kpr0<^VTR7KfXjGQ?lMR5~HI^|k|hjK5RapdJBj)n}pOk!igI^~qaj
zO6k_D8K9hsQq$>@+1|WaPk+&lJ7H~1_Z1%n`f<y56XQ)IwEI7wlu|JCnY(9dw*8u?
zlXcxD{j+Xu60_02=zj=X%&e0-7n8r5Z1%i3bxZ*76}ot3pQ^r^hkJ+w+nl@mXNqp$
z#$@fC(2is1qGR@rYu8?Fuf)<%o;2A}d-fCT&u5CtPLC)rxLIW5I~@=YHbc6ybfXZe
zFCz>NIT2r_;@Y?AtK}pn1It5AU|ij^2O<eEC<#H2#}@G+fyTdbOM}gzFhLN@HGIsY
z3J$@$a8WOlKPP~EvM6kqTx1bFck$vZRT;P=VzJ$k%<&&0sN~c}c4ieX=mx(C>F={@
zSXfEC;~7^%i2KrGmHr#VC}?B^aEh8KprN|DrSs>f<KbjjBSD!_9_W+UZIas37YP|g
zDk=gMEhgeMl1y8%ZtcwmD=JL@kcckg>4CsqX9x;rc(RCtm)C?6>3jAsN01gXRp=VT
z=m^!rS<1Dv3^#o_Vy23G47L~)V{z8zQ6DED^{Z@XWp{bxdIc#Hn=ZH&y_c*;ybhFW
z`U+wqenSMBU?bLhJBTpC));8!oL0(njmj5f;;fw(w~CNXOGzjnCLRd%Y`poHR8@$u
zan|EVCHVvtb_?t^YPmo&h^tEup5WEfr}u1p19t(@&jB!W*syq$Tdv)Di<wW(ybY3n
zV$!xTs-pH9Q$&}~(F$koM#KBD;RH2&wvAm*WoH|eNlrW-t$0tm5l4mG)D-)gnwqt5
zt}ZJ)e(;js(Wy_4s7e~a4LLij%04cvX#&@LJMouD1Wt{C0?j`&Y{TV|#>%=7xqq!C
z2#O`x3sh(*8u*amMv&vI9GJfyv^V!5vkkO>Hv-^3JA0CjPCdJWbdMgy*P%J43)cxM
z4_=;JUxLR<J$H~^PBn*8zkZDMP{E{UW7S|jKZ(c`8zAs)VzH14<>0WDkIm%g(<wZJ
zOnl6J)^1%0oVnmH5_Q{2HL=U(W7Zn@!k}}|e}cGUU4QWcyA^`&-R3^HKfY&uH;J%@
zDGPV_i^hp^8(v)8__fN19|{cGv}qxCE4B(rg?>M1zR{(vcidtYERcYcC(FrFC9Db^
z2i`I$IyflA@^q$hVIb!Fjj$Pb=T}P$4bV?2)<N+ABckvV;<wNm!bxt<QW8<KO0Ya%
zU&5KKHQ@07ahFY-)?;AkcG4__=rcNwU4IhBuw~;$(o~I!wt_?j^b`?wPWVIIj^DKa
z<tYxAT@ZG28S*{n$r=-VAt8Zo@Sn}i0wRR&F13W{4&6mpKl3ZH%@cdetKfRxVyK9r
zt-j<*wfCT~`+S)+4i8@OJg9S0Kg20GcIEUpZxo(CHyl0s1fd<?$)_v4N9W{RowoQ_
zZIS7=iEpGd%;LqQpX@&Od8VV4)!C`x^@Ek`9ka&W8PXGc>hfjcW6TnZbr%h^N|+OQ
z^eD*Hg+=L)l=8g?p{qn%4P6CceQ?NbzD9&Yz@Cu%cUHYO#!UiB;Elm>2@-sCWH>0i
z`Ds1W`aDrMa*(!rdP;@n^^^#rH8r~M6J!gopPKIUMc4__7u9k6u?JH?f*^q(wtoHP
zmmbg~q~y~L$ak7S%v$d;$tjS%LRT{ChJy!Ly20uL%^;5!UUCkclZ3eoBL&kNqp#>z
zwKqfvJTz!6*Cq#J-;%DSQ;P}<Ej{b;?~#e{(gWL8m3JH0(87g-WCh~n`HL5XGDae7
zI&p$lBo~cK$|AFbIlv%Dml@UgSLhA)zKWfjR#l>AFk<poqoHOX5%kP)LKMkQ&Kip7
z@A)JrB>}#2WIwoqX<SSMYJ*XS2US4P@ETIj2Mh-%g?)3m-Z2JKelmn2921Wh8lL_=
z1+J)HKfL<=fGn_~9X-l)K-|~V_h+<9?rQwo$6;d0CG52-NwSBU>&idAi{$$EdHQaW
zv)(b|lswCTWlx`<@me)oWs-KC=VhINDL>;S+MaGVPLX?*M+wHeOBLm@vCSjxB~T_B
zpAnb3t0#pXcgZ6YxKm(kueEFQE7s9|OaD6anGo%1aV9j%ByCX&AB6e0<yF^Df%{#*
ze#|O9mhd5@TpsCs(9mMiA~T{`H2X>21sO9xt*VSKi6fddB~vL#m0`A1Wwn;4F8-N}
zE`@HmtEr!QP|?&zFte-cJu+8l8L=TIf;hMV%F6Y1b%oA)FpG<)MHRfnMMgqm|NeZB
zWNHYQQVS)roezQ`3Y~RPCu_THJr07-CZfH*+^N(UMco1334tuv2iS?`d(Bfyi7Ogf
zlFc$7xLlTr_A@E3SO=^w9HhJ!i7sM6ryAns@Q6fM6IKc(j-|;hjqy`$;fn_%j!=u^
z4_!$`+<TI54w=qW1IbIV9n4DHz#WQnjg)96dZtz$XxFq-`l)!}sp~c{7%*JpQMEU6
z?n66xV2Q(04$p0$K2uA%(^29j&%?~vHm>YeKU)ilZnOL(4J88J6|Y`5b;I9Qwb)q^
zv2{cH``&lS>OU(nIc;vnvMF=t9yU5CA3f~YwGoYK($PEbo+*EOxGy3k^b4^QJNAdy
znEZCXk@y1RsZ=-mEo4e7a%2XE@<Rror<p9{(hJI?;K)H}9_S9Vx_#cgR0H;<$UC*<
z>n0<m5DTbzFier??j>^G2B${x$x)<(@1ZDWysh>?`0caqeUQ@Jc^fer0eom4`9|da
zz(i3OZKs6?9B!St(m|UB(qtwMf^L?*cGs^jO-qDsFDUqWXBcX%`S$jYgkF^>Iy4bJ
zsGl~JGgpsbGM$rTv4fIZt9=SkL3CaY3?(EI5Y$2)EgZ>Xlf92G)P4n+aOesqP~;n}
zBy63-u33V*3iTJo*&-xGJig~sQfAuPP91Uaj^4K&ZOo_w`;~&6$JEHEryv?;3&8*b
z(8-|15ewynSS&Hmg##|>;zbkRpZ{5FOeY)bTE<f*UyAIWxx==m*wZF}Vt;d%eR6eE
zTU71ifH7j7SW)jvycL*aLPE}-Pz?9%C==6j%Ec5Jk7(g;u>Z;x%(AbSFTNIa$8Cd>
zvEilF3v`tVe4Ky3`<4GLy#Al98!r$!R&jAQp-|MG7$<atr?u1CJJau(;UGMMB;<-j
z2StNPd>~xQQT|sr>pr1l{2{IT-L}_)Ie>sAkuwGaI0RJD1g(lhe4hv_c3coRgXVjT
z7a;u1ceDvH9QNEz(dgN;n03ekfCeY(m8Xfz9zz<CHUETpRpS~-jkrz!{{EWEv)<{l
zBpK^HM~3IPKWD<H?CVcd6T%HpYW#JJ>UNvRMiqpGhL&Y-`-RzwpUI>q(;d^+jmwwU
zvu|I%JUg|71CRnvDx}fsQCkxiM-p)6ojU?8h-6YBY@mvYe^Lm~)7+#Nn4;9$imkmi
zQr{J5_TR;e?=#lIMwxwV6%+A+LFS_TAbv~pFtx30lw=Unk|FH9yk_&$bTRY&lj_!Q
z;6NVd7jNG(esd{-E*_fZm+o11Z4~qE(4o6Y96NfHG)*d`k)j}+x!`d5<D6lZTK&X3
z7YX@p-F%BqJWMPeT5xoz&EMidQeF1!?E0bGkwUA?aXUJ;Z*X$T&ux!1D81mHR=RNZ
zX+uAUpzdeaIkukpVOiq#uUJxljB??i>$R!|Zz3N($yW~b`*zv7Xav3+C?p_xQm7Bg
zY!;c>*gW<rd(TnCoeSqwW3U4&l=t^|tZ)o^*zU&2@9#DEp8Du|uaU*14jefG5k+YS
z><`~yk=eR+dg1vb3W-Fzx~U|A_1ry%cw9OmSnD`4xjt;pz4RE+b2rx)7lDqJ78^e{
zF}?(VBFyunMvi1?)RWR(BJ`wp5pmHXb--_j@a2xP9vj%^%`G%5K*=!(hv$onRI@7i
zdeHI5o~s^#V3XDMY<~1ZSC=u-5dC|bc0S&X!$U)Z(H#j2P%6pIwBX*YfC)xQ6k*Pd
zLIN1sZ2IHIsc*mz1<jR8@PIoLw>B?7BrFVFiS<Jzk;wZ<L}a9;hAhIaZ39Ij(io2)
z_ed*ccw?5?vBM;$P#WvQI>XKki%T?!@zop?O>L6y=+UIr(PqIui<0Fh;y=!Od}QP_
zl7XC<_@}Mya_Kh^NbsI6B6JW8nWW;#n39CSs~b|k(8gx}OApHf25hg&;Zya=Zz0Cd
zU0=Pnr%^1&!$g4;XQ1$&a@_dTl0L`cF526EUAJ0hQ0yhTB|u%(Rk|NOft$&c6}2tb
zGFm>T{dZbpqY{VVC?{p(23r+{G0GFhxQt7@`Sbb8ILDBQM_2=+ZQiN)pXfjE)8$cR
zz32~1NjbjdeNv&RcF3=glX7FexBaZyK4`&q^X65hiKZq0z7_n)+jj|(S6tkyHF%r<
zOG;v<SNZw-ckjXH?%(&;HEpkY`0UfCOHJ)xSN15m-^cV}w>u;Ky$oJo@mT(Mr>?fi
z_ZztReHw+z4043mC#C!wEG>1H>n$P5kpPLMq@Y*#5p$LY+G22HjlkDSv6Y27=}RQ6
z&Ph5uXE;q@F%Lum#C)8cWl9x`(>0Rdk<)3^Kj22*P<yQxh0UGWwHQ0_2EKari7~(}
zt!VWJ)_b-NmIRmUa&mHn{_$z`FKw}s9?1lcCyAJY+KrVHn`uEuT_z)W@OsB;hbfTy
z&z?<AEJn$3zxxU(I5deGD?Z*a00imOSTQn$Sv3(UfqUj35wD8nmwX!UI_tfS)A0D{
z*sT*4?xtsCL|^=Ex3bEQ*M*EwnVz-iq?5nD-|H=I_HBUtxZi)~TAzJ5V1DYH(tWcE
zoFywQn-(c&|E+zISnAqh@Zk2c_3n3W6}q9Xy>{)!`7fuQy&l-_ZrkFo9dkZN-m;Ou
z9hj^&_>08A$9ay9#>%Gt?SG-6S?v+>Mz^*P20vE_3x4QI)MWb_NtsTuPQ79DhYuZP
z{*(#GdA$ZbTRKl#R%*jgq0WFZ4A0l%qWiyw{PCahWh4C=UYz@|>7oG0UV-=BF8AE6
zVA9r`6Qo6w>_AddH{%Rgej&Q$9Eo$Te0MtZqMGOwI@Ysi2}Wd@EnoD?^ikwaBT*a^
zBD8wLpWdBD+^B-xRVAE41X{l6z0SYgNKyLi)7z2#ou*_avFsPd<QBUt*r)W|zu$G+
z^xlcZD>5dgI!QlzNgPZcC8M(?F&)jR5>Dk0Wi=`{-jVLE5fw9Qz@y7nPsXka&pFZ1
zXpsNolC}1@=rw!LBQDh3I&m4nDfVA6$G><!=jfp>rcE}Vn<WnQi1!)tSA58V4ZXUG
z&INcU<(iN-$CsF}6S;~FhXYhGQ)Q!`$=G;Ei}YH0aB_1yutSQ8gjizcv$c`mR};KJ
zrMR{O<>Pgr)m{Vt6aTQxS>6kvC^XOd_83tBp)BtDTzCu(oelCK7LCYq&YeB`__#qq
z>`}p+$Q2>E`%ZTizo*5AuNNo%r)BE<laGCpdQjbPr4zHRr>?zlQTktai-@oq(~hT?
zm(O(DAbCu`rQyS=)90s`zQ33<e6(p)`|Fs6YaPR{N;>We7@_rf_%UVUcg16~db345
zW-TXp=E^#?<qaQSfBmb`HngLBynXh_w+gwlImfukL;OC@3^G5B(;_i(+l2$g26TY(
zr+(EaJ1-sgA$on{OTG#|djfcVMe-d3cWG7WXwB!zxXzQpgwL^$z(jyGEeQexO4&iQ
z8K-^IPboVy%e-kSDwT(Zo_Sy$-ql~Ozcn4k1;r!R=XVj)yY3v=an_@KXoS4~@1*T_
z<<?wwyqr37Tb)tDijXTut#q1yp72^M)BRRSNzT^G4|c8)NRoO*yY9D^Bhe#}!3A*{
zOAvVR14}xhs3kiq-GI>Kq)_}wta$J;$snY77+4Q3TFxcUNyErK?c&r1RUrI5(y@y!
z1&m*Pv|~l%eXnsc5>sTp)#hFAhbpYCt!rD`Od0)<_CdCBN087@S)QUZ)o?>ecGi#A
zUz=?%$wR2@aC+;^t=3ET<|VYfG`-@6CgLn;XSDKPd4UAnaLnS*{4EL+U6uj<B4xbJ
z=HuL|Tbz=ZxDu*eT^->Pkj1-AB};v?l_#iJBM(eT;abJ10ai=Bv60am!pp?)AxsE7
zB@^23fvdh{<18?Qs`L`aG>32Bb4_;_o$TLW+O_KxC;xYEU!8T5o!Iejzpli*+sy?Q
znbZDz`DJ;2i&kXgS&jNLmVuKek3SXo!L+e)9*4n~M+^Tv8X2m*^;Yp$>_LLRDIgyW
zG8jF7tShJN!hw)tU&i|W{CUt%Wq%Y_5vGN4ld@>HLY%3mcPS%7P9)Q}@A@^_6YRYD
z3n9^1Dz<&!t*P0V>hz{rPv7<1m*-2*<aB*hNJYhGtU0rjs@CSlDk?v@Q#mPj>id@o
z6W2MPy6NX?Z}xuiAeDWkF1D+8c~7JLnaIl}ifD}P#m8%oi?PsnAFzE_+_h_XPLijq
z*Ne=?8hxp4HX{?vkW4Ud&M`u89=bLH&m8RXm^Z8q^L`(Z_4Mf@w6uT(fsa8<XmQ!N
zu|F|tGp0^m=pe5)IwIe#-=yS_hgC1W)|KdXuYLr^T*`(0@Njo0ztQz79edSfC$0Ub
zVr<x2b22+GZ_I;za%tvwN@vHtlC1u?|G)ucM+w)i-7hI=c`-MlqT<`A#YSGI{B%U$
zk_VZ7uI<WW5bZ3yKy=Z>5AYsf-iG^%wsFkxQu-*uJAq;}#Dbzu=zk82sn2>3wgoL{
z`ml4dnwm|~`PuUmE+kDZm+H4~dcp{8?Z-vsgZqjpZ`1Z3v$3PFDC%$P^2OWI)Jj%P
zdvfHhyO@Hy;WTn01@+U~+%**qHoVy<4p&aqtgO#jO!jQsmcBiEK2i#*$+%#5pAZsq
zF;{1lMO+Zc2j`EMd;I7T+2vZ=+Ninln#S3;9OxFjl=6-}s!Oec<)Xe;xV&7t^hUi`
zY+_WEG?+)FDSaI6|0YhEQnB)6SdX4ATNe#^S{z??BRwtUp^RA%N7?nihD-~$>1{SR
z&{pV=B{@qyQhN6;y_H2RQ=jjdGpE(W<jB{fVbm*mTb`1>Rb@^?d)KbuI-sI;a8SlO
z{<b2`{Mt^_+m%jn2KK2M18IwBYgI|u^xusI{;3WX<9%|{7HXeK{hsn{#iyg^;^UVi
zw<YapVTzaSw2GqWejiqaiA1OVvwr`|b>FhY3;UNS<<IyDg&0NX`X9!rsD~(;zWFrm
z+WL2tT@w~eo8*`32A@SDE0U_8C9-VGNQC7wjIvGsS%8@Kr3YqlmX+2B5{xwuhaEV;
zWhNpljmb1=-i?CgOT@_o(>&Z;+Hv{1x#SX3W3lZ~6bU99H*Y?0@>4l*@mPHC?bO42
zq~AzLsJ_|trYwU-XPIxwO?#~^n(mSZYXtm?Cg8@gv^3eGo_YyL+L>39vM`Mdyi|wF
z)J|{p@mT>XLKcaoB}Mhvqy>;7;GygJ)KnGSxtxu@i!#Qta{j1LTE2Wr!O_B+24kmI
z%lOL^zFjihJ7LhZGi$ef`I=nt=)hs?8^h<`l$G6z=M!-F>ib={wwc?Hl6KNQbvjG@
zFj>SmR+qF85pQX6DN3ie?~mJyD^-7ih$kf_;U*S+*l2`IP$c5}TQ4>%F%2vp$}4VL
z{jxC~J*h=tlmvn$GGwp_FdelJ(xVIZBcpBNMlZJ_G%~^(Pe0o?0y)<)6Ik!Yj_tSS
zE^jX(I0DLK@zLPi0#w;(FXNwS$%g0{32M5Bu1wLP?agGQ5Pt$=bf&oDoX+8SBPNk3
zMJCvw{UiUij?&U1*Fq^bi~KY`Ja!^{DeJB$&yZN_<ptXz*HU+-td5%jY;wU!nQCc}
z7ULozK&-t4$Q;<M6PJY0dOqPV5>Ko4->;X4XHJExQD`I04_#%r+?kTElP0B<4T>rB
z{`~aGJ&SQ6RTX{g)8AN~{tz6ze_+}SZ5IMtAmFa<tek0?TJqfe+G~f@2^;=KjcRfY
zQ_52ESY3>(9D<*8u9aQipB(wbGNof$sJU8M+RFT#?f&=j)~onx8BcmwP^|E8k{)D1
zA4c4jZf=O9ljgl4SB1TmfaMHvtYTb!IjtW<+08h!?}>2`!Ub_xcc=Jo(l$6UAa+<0
ztcd01xoK$x$!C4fiOF+On&f*GW~I=Lq(5ZuWT_rH1T%I(#nc2=L04Bd>)ou=c0aZn
zOH9V+v-38w1Fm-m2QLfFGf$W^y#Kx|{~%$NPvLvRrTf59UKmQdiOhs5Y${M`j9Z-H
z#elsu+t(m+`X)m~Sg_z_NX&M<8>g>N2{S>k<}$A7i>MVXsOD3ly`XIlW()-6A_nX?
ze4Aop!;Eo6A#-D&jDMylzyFy#>(ql$L`#R}p;V(0@$kcq6&`GIogI@PO?fVX%YY*@
zm#WgbqOU+534(4J$@(l*Gh{4q29H^<9>M&lCV6Ojf*|F^3it2tUqSznNS6=aJoD4n
z*OF62vC*@qE|*E_N7zYd`~-lnP0C)&Iqb(E>C;JHwSG2H&W`B)8Wz0w@7Qi@`|(<y
zR|fj+%^Rgwx>{`g+nRHJ`n33pQEq!}?ud)f^+AKT0qy(xMtChgGM#4M#Ji^p3&R>N
zH1`obtyLuPD06(d&5e%sxkkNze%$G!-ZJ0M>y(WKSQI@fh%VRYA752^<>|_}kcO*P
z3wGVDc%8mFYTJ;T2?;9@@uC~>Yj@fmzD)kr*Jdy-kJYO;I7x_57?JMu3pRuAsz}rs
znz)|H3Qa2Be*k&F9O5RCB*U*!+X{I|RX0Y_v{R>44Gbc0I|Cg6e4uZDO3lyDCpj1)
zH;*_(YX6>?LBQeOd6jsi>nn^RIi^RblCrXwhlly&?f8w3rLjSyZh*J8P*)oQ=-(M&
zxR7jo2W^BC^<Te2^|BxeSwIWB2O)J?vnIW)PF~6?#h&J4vK}-Km!d{RGNB%U+vr{U
zg0ABtr@wsm44VThJ!vNNK5yBQ@z531+_i%05u--&I{WnQoxLs=ceA%5I6R~U>g`#H
zW20@jvPpd-)Y)C1xH^K;(8D`9mGg7%-Nw`hMlE_unPYJ=(cJF(q@AM7UBIV`<QamJ
zsRPCfmlujq@+^Av2-&+Ay%Ad&^CvnYq5pzlxM$e=FmSzkWshLpSq}^Y%$buyV|-_7
zJK>dGiA~IGdplJn`-bbZr+ZXpHGJz4koWPze|9fkhE2HOV7gYnwdP#>OAr4)bs6pL
zUkp~O*JrMr^P(i9bct@R-z(>J_k4!xS%2Q<e8?rO6ejXVWqA3hCGyw3mLAG4=(c2n
zjKqNc{XJh_5-Tk!0$D96*v4OklWdy@_%z(VFQH*rcq(&7LpqHg|0_P+gs%izf$4&=
zSxycJ4_RhE((wG+yhlX(ez+xePh)6=HRf>6lJn<#ibx+J>;g7^>S;S6%7q7q7I2K>
zK|x){#R&bubYE}Tw22RaHyDfv(S>W_aRUmz5Qy+hFosfHa@r0Qfm@GeB}eUn@G>MI
z{ei7?y5_l%5GJemXJ4B+)o>3H%7S$wzmiB&{Ivzvk7e)RAj4%zUML^WnsJK(2f=dw
zr+MZW!>e=PK<<}}H+3xx@JgmT6h|{CHc`yZWG`^oDk`bPwL*p-@adADy9O@2k0FLa
zvJFD~7`5QU+^k+bGSJK+&21*B20Y523TZitA_a^88%7*S!ZeLJmX=+K-!@dl4#q)X
zi#6uQk4sTeB^=e*JBZ-K9w|3!kq}#hDEPG9Yxp`v#lK{YPPMRr{1ghIc`%7tBDRiu
z5!M#jGar<7?E2Go*Ab0Cr`qQBp6%7MQ>Hh7Z)o=KFJDtq!bkxcCtdSU(f9B}pD#y#
z{#f=fbHfNH<%xO$mgnAeDczN!PcC6GTit`280)hVwqLtAlS-``nzwN4oNkkUe4pVT
z-f&}K%%gFMh0>)dvyu~sZBGUxEh{co8uSpwNW<T@J747tm+}3<s1j(VXY%P@SZAl!
zKV%H`sC}T+x5zx%t@`OYfu}isnbsN}o}PY4z4?t1MdQKxxb&&JzHA6BntenZ$6Vpt
z(Cp>oj)i09m(D2PL1i1X3XP|ap;?i-(hfFw?M)#=1niSxaZs35`l8sFm_N^F=n}y!
zAIwRDjZ}yQM1%vx$#lf#Iz(0VL+qCK?06i2zHry?8jL0P4rzEaGF2<`(YvfICns&Q
zPc0dyskws}C<+j+08U0xKub#t=~}qD3|7D5-$a+gx>Lsz{9j56@1HGkiF6<(BDTzF
zuCXNl`42ejxy}s!46NzgijmWqdhnkTeZ3*3a5Itseyxd<CdFE)r(eBFeAOe@F;d-{
zZi)BNUU=m!?w)JcjuzFJlHEb@el8qwA|xP1c+|y=)Ykq+JRx5StVkB>m#<tIGjilt
zOeH{_f>;99def$6P;(42<3Z&4A_>|H?tuTq*JX7Q!wYWn#4KIfwr{}gE$^x;96~eR
zpD)eH-sbtZr${fxIkfgo!HQE$)E>yyRE8&}IQ0FtYH5J|YSWGGKR!QGGYwYh=KSM&
zOzX0ojP2h84~YMJv%}W*w|&Ct)9i%p^;zO;BQH2fka-X}odtbIlIlUIORAd4tVG>3
zP)^Rt@pzug>=BXR?%bb%1?7HCg)8<g1a;<UFgEr}GBRe=E~*(4H^tr_Vh2GI-WY~|
zJTxK*<^cAl6#E#^m%2Kh6(@!&T<z*=)4cey<5+&^D$w_0BBR)gnVD@jzf9o;u+xwp
zPq4DPKK_a~Z*F*&j;Tr|6@uei6aWJeW;J)|(n$;;BC6Ov*VO?dhEHmF%>#gd!tKe4
zht=L4n@c(S8EUYfL{7Jq6~Sk43QbQiKXSFylb1Nfo@Qh&CdwA!qH$1MVe}%c3BIqg
ztCgi?%F?WBmoBa2vmjkjLw5MEVN)re2nz!?qY+c$&eARKNd2^%J6C-2Q-+VwefvZr
z@CD0W2g>hvGDVTkpFS0O6}B$wMJ-Ro?tMxVeH~ms=_Yr)es+E0BAL4HQ_IHwj!kU7
z5!;3_14z4{?AB$=wE1R>MB?JXC638wWdAb=f2sZY@+~2Ep*Pv}|7l%IOuuf#^Aox$
zb4!-_X+vzWEc2Y+N`f;!Bs6s5`i~ZroBIr*$~84rmoNyTqNF~d)cN-<tq2c;nJPAc
zdhg8$lFq0#N+Ru7^4&O_6kMNa$s-~?IGu$6SMff^WORz({jod0Kdl)WvcSw@B4>Ft
z8}BW{C*Cj0TUz_s7}){YPW$$C5!swHA&-xuoU@ww9GVm7e^5Y0gM@}tV#*O#R<1Xw
zJ02F&C$`?)^4=#gJNqBUBo=d!PIQ1>4-FQH{yTr(mmY4GRw2f!VjXI*70OkWm1D_P
z!!If_qdv#%)>*9$`@P4S{XzD%WH=99Qj+%@eHGi0U8K5Awb1Iwx_Qzq^ixEGYtJ}y
zHJhWGB{GHznihf*B)WV}PSvccp1E%=>ef-3QR53^W>nNWWja01sh!YcNzd_nm8xoe
z$`9#}pK<tb^o*!(K8qrf#X+2FH)>q`bVi)(kBdrhKF^zXm7HkocnArxbDiyK5T4IQ
z!<lLErFwzAy?R+0gd_RKSy^Qs>1Z)P7kBNF_>r5L$KZm+gXuNv9asV#h<*Pnu2oP_
zKnx)<S$K$ojzC(;x=V=I1W-<JDRO`aNxE5^*U%U`r;Gbd7v5SM&3@te93uFdZ|S{#
z|9(eXyEu+IRn=41t_^HU&&g39UR#Na=xzli3AA{FSyC<ZNQU=fB}@BXboS^(!(1(v
zj6!uuOUaUpgp4vxX%8#|rQc|T#)j?(Y7SA$5H!TpiC~C|GXj;@Rxg-8pFpY$j@iD?
zz^noT_l9GG;|Do8sR%(>Snl7trR@$5K3@0<H3T9uoD|R8WhP+J&&hf3tjDv%1%Ya%
z6a6E>?qYuO<Oc1}JxD4YFnht4&1Kh4{`)Jb;-{C8U|H8!>4itx0w)7;(X12lnnnwQ
zw)&5V`(0GqaaJ~I=$9!Xkw{T=Y*O~T3^n*(-qqEwc4=t*_`LB>bFZ7qN2V79ii<Dy
z{~Bj7w8d%KVoAe0_g+_T)sEYhwc^TxVSQ4wTNZ8G_V97Exn`5Xj5ph42&g@N{QNU_
zRs)^4a&X?<>LO96v4>$2e8_V7TcQ(rL#;J@t0JaiVt~l7M@^-uNW=_B50AoozowbV
zFFi8Ks7&iCqMP}``SWbE`}Xe#KVWpju7-<ciqUQ{fr6TqxQ$V6kQBE<4RNbJ#_#F2
z`SSH^E+wseR{e(iJ*-&AV}tvU1%%Tr-aZ+{DaUBnE@II(7h%H5beuM=6grm58yHg3
zV5k<Te?Ku-%g@B0RRN;3ovKMfF=A&8J2Rhg7C$!a7`#>ywn#79KmPpsPUR=1>S!&u
zGilONOO~?e115HJo6VvC2W{bo(`~Y-3UJ}15Y&A!g{0XC%_V_m9LEnHKR#PrYonP4
z2h2svU1(hw9}plSI3@nsHP2F61%*ZA#Gt6<o<TAOc&Qv7#Swh`_-{g7NI5=W6|Xjb
zDl`S*Ho^}>Riz*m%#8|OA`<p5;YJsJFhxp2$pWEBZjX;$=F8aH+KSp>$mj)H8H%0r
zmF33GEiXz=#+sIoR0|v|W0tieuq5D}boy2I^XIMl_Y9Sbte`B+OkP(?Bx?7brYMq6
z{U@f?p~7}T!ZIRZ7Mlmw_y4v9x?HXqStr#e=76%&`P8{9yM@m6n@bVFqe9y2Px|`q
zv%lECs;bp@QPgUT$_&TJ=g!?PDk@US%^?U~uCaEkmxGJTN4EBDj{E=c@kX3dx~Cxs
z&)7i-FX5v`MuaI^Iot`2GgU@Qbnxz@zUGT1Jb3GwLl7iISVMT|^4ThcQIQKbiZ;<P
zm9kKjYE%GnTwq!w)Deveq&=F~wVs~H!4a2oT(G;;o<^|+C`{Dm^5sLq^I2*T$HV7U
zcxR$V=3}GWFg(Azgv8l|1n7PuQw#I+_smM99RY6cNTHiJ56Y9EuDu`>kP0H_e#dq+
zE(WbvkGn!>>(1K_^wXM|-9o+*ZNufl7DW`Pfx&zsazfEUGjh6c{6uLl{OCAz%k7y=
zotXMjM}7a^M@TPUL=r8_{^5r}yz@q+XJ;#g<`FomI%LRBYYm$BictR`M1zh|-g+uN
z9z_t?18H_-+pROih&i~kdKGwsrw0&&Oavt*a%`~8X~;4oEFT!!wNob08ONtg-VHM8
z$mv7`q2dnOxl>F8O~N#J-a(s;UcN9U&o_Udl?!V{R3F(X(T_Xt_VOW71!xq`+18je
zT5BkWWBswY8CKZs<;$=~uAekco)x)?Vp}^F&Fd-Q+F{mB<X@hpT-}orO0X2BLCj6f
zC5bjC>!&36HjYg@=Z4S4BfaH@$0m*OzpJY<jI+(PqT-2DF1xn0m)xQ6Ig6{3`h<Oz
z2+tSZZ^4_$cJ%K4cJ>pWyUYS7i&V<Hi<bHI93E|RAT+dJXr7hOl1QVxh60N|Qe@JA
zka)Z<<&<~U!*XUqg(+cGLxxOAL|I_CWx)mH07M6pNQvzc-=9tt3~t|5e0Vq;H)o;w
z7*dzvEI&|ELg+6TNCR$Sal=+W<m)*45i{$_BQjw3*OTJOtLkgLSz8o9>fFxb5V={F
zWXM8?a6q7CslO-AMNahMV|r@<!<55ojv@;=@E1KXfBY*vhAghdi??YnL#DNnm?)so
zjf`u2;yr`#KJU~5<1*JgEGEM1N6Q#kI|4CljjG5y73%;V38U&SDPgQ^i-8?YYNW@w
z7+yTro_9C&2X&kO5Ri-v1n`T|9ob2#C+JiC31nNu`Dk18+Y;OWbvWr?i$$i65K&kC
zozPvw4WG8UX-*s+QPa08BgTx-8&~Ee6;E(*ef9TJTk)>qzn^zh=I^!md9VNE4QYvT
zU&r04_BLP{Z*Jbb>*+b$UwtJX#JybUe9La}#GVuMTo%3P^)OXOGUobQr-W%q*L*b_
z>jqZmcKlnra%JQ@ote}3{cJcr>ql{x==%Bb$)99P@RK9Lb#Xy{&vF`7bl~4&bcks2
z^q!bnO<A-t)1OK)g)mL_e^pgcZNav<)%<UurW_~~(dd1YY*4>%y78}Gh7VA8->-va
zi)x2#u2$`xsdIBy!koVOmBI8jK3Tk{p?3k_(a=1FT=MtR*BhSr<5;y1x~8E4iIVk`
zDWsMoAe9M}+aC761i$LF?yFZ%Bs<E!EGn)(dR?#V_l}Fszy7`W*MCwyUAm@7Zr9S)
z*L^jz<z|5Az|hY%Q!SMO1{1>crM_Oe=b2B{J$#J&ESC7GNg_~yXqv_3c^#5<YkUtF
zR8{ZaG$SZ#X4Qt51Dp4*+BN0VR$no%K_HtDvP|;s9}ipElkYb>HTO-H%bdA*3NeMN
z1-IS{xSF>V;b+3%-l$?YGOtdlYlZ_R9j$AZ$@tRAaShGmOJ4KR&O9@_(~ws{)Fy2O
zIlq55X4N-7deUOk|ND<itIBiQADI^%e=*<JDgSG+Q@)E%T)f+u(rWM6VI^NTlTX!0
zT6*KAbmo|;Dq$xGJuLclN&M8D(%*l2A2OLCZ|XAb$G#B1t8dP{axf^-t&v8Ug$xdd
z#+Qx9clX+<`F_)qU-t)(xBnoq(g!!{S*hv-I!2<B2JZ9TO;8?6^sCQ1lse4~OJspx
zTiGS|^x3v;G3l%)wssBPGZU-jqel^6(w3`Tcs;(@#AD95rRUzAvszyN%|a>QEAhk}
zHvbw6j{g3AD677wLx#@2{H7|$%Gbx{YmQwoZ@=Qi5s|%1Q?7=1{nj+F-qU<{NzamQ
zr5Byv)P)t-DgtaECeb)l|EIp+qy~$tsoyQ~JJ8IW`a7!ga-BwpBFn(rH*bFY{@P<h
zjqj=7+lbd4c2fVU{%Y~pJ3`|VBO0pobM<XgAJrA%m|}9Fz-!Mfv){GFBN-W#Ls#ox
zJ0#n7d*{yTgdvx954_jQ`OvWv-4+GCiH~PRjTPDK8z*^qV76l}N-bpnH-CHF>7{$m
zr|QFh7nAequYdXSZL*12j&W*8$v~j!A)QBa9@{Di>huKtA$La(5ApxkCAGJrH1CCO
zs8j3umi#!!Lle7(S<PR(cv`~81t~pmSLl`K{_xcrHDA%#aO*kiC;449_8t0X?P5D2
z&_40ym#dDsC(7j0O8uChicJ0-$y3ky?GcpNX!UB1-xMo7u{$pfFM1U0DLA<><AX`K
z)_xe;hW~#d0!GYJr7Zv1uVVMv-Mz$zwbpLVDsWl<rFpYL$e}8^Lyx2DYn!jnWgT0T
z^4u$`t<}z??cUv*QT8J@e%gQGl=Fi<AAi02xusrua$VZAnP{u;>;|oTdw#x}vaz8;
z*K-k3A1BNF8ByPM?Tv(D+#GqK?5XpCo*}kePjz^Rio%ybt6}Ns@q46uE1MW=ech=t
zZMv^&y_jw4eI+reyKJ^tMwTru`|v1IEpGn(>LA+_@=r{)XNQ;O-uNT_;`hnNB-|2V
z@gU^xvd<g;o}0N4LX~Z;+Pm{tOt3qf@GMHZ@9y0`s#P~GdR@J|Uh4G&+k}hTht(+A
z>gL6o1KeS`xREt@pssYI^(%T<g2R=SeCsoNChxnV?NRUaFK)KxNLC(vRBP4TH#WHR
z4IB4tlPSTQb{7W<p6N_UKFz5IUQ|^byywzw;KXOMKj4r3<d*I$vBU67ga18af5&Y9
zBQaBv;_qm0>8>K>Q<pALH16N-Wp;L|4b2IDNB*of9v^Ahcx&{L7_*}%_g0Vp@34>E
zo@vq&lVw95*M57K>p$-P-Bm+`gj4@Mf&y^KuHwW#1+G`Bs$TQ3N|^qRS-WU+-4}!Z
zChJYmITZasGmS>WEr@Q1>K}o&S+BhIPqlYo{M0?4EpEu=O*PBDp`0-OXv^izNjv1j
zr{rqugzvn&zUOYw@QhIEu_kBAJ}uhV|47GOkMtb`7c%JV>2p%1CrSGILyD>fE02Rx
zS~hmm%ujDuiMiK*zc<_7e%-g%{)41~@_S{(6h6_-F-){OCb#R!S(iz3e-_W&dGqv)
zchw7(G$-(Zns(gGt5#r@aJBvFJr{A^Fxe1d0!RZDkzyuw*RQ=T{TU)e7RvmL@AP|P
z{|8leOG6d`yb-2CyB`0jZ(z^eK^E$5fBujMkoC^Q&`?r@OdqqofAV`vh#^)i;?S`Q
zlxQwv4FYk?%%m^a5(+gxA6fmjZwA-(QRCHaBm|Rg_w-*7uhBNIh)G}hL{Z9j<EA}<
zg7cxHyToKnZSnDSp4ZkBrKWN+WSoS5TSC*%RjVW>g%mXGtH^KAGPc!y7<-3tY)93D
z)GmP@pKMOAG{C|YGk(j7QFBN4_%`)pd&QJrHXW<R`^GpfACxwsFmC?x=VX-&n?_Jj
z<)A@V56bk}wt9RBV0P-Fbeg%uM1YexvDs?vQ@r~SG|WOndG3<j9oc20`BDOjk!y$%
z=jGRC&=20+`o%Dzh@1R}YHA8`w*v;0)@_y#M$j3z^<xisG2@?M<KL?uPHnKTOf1Ie
z__g`>j0qwk8nL-~=8UYZ38{?v^q;Gmgkb#2_3vQX5|R*!0Igk6>Bm0ICh505wR-0r
zw>01`C8Ld6%n@g#&A<Ra-_cDNPnvOLaOY!sqNt&ArKA5O<Dt99M@+n}Blq_0h4(iz
zmtQJqd;jxKKR;P>L*<L+8*1#9_<8?naccWp;s1Atm3GV7-X&$p9iQWauUzRn;&Hob
zO}yvqabfFTX8Dd+44txe{pU$3c^cJ#19^FE8*dQwk~?R-qGS-qeeZ7K(Ketmn1Fz7
zShQI?>PJiOiO<OR1;)zMP6A=?2W+iG7;opD7iu@4BEt6VGjI7LCK@*D#Hl$+Ta9xd
z96R;Mg|v7RP6fts_N*($wk0}S5DurM%|(T7qsg=<$y<nG97m`WZbr0P9_jxNRTPm0
zijsG%ycEfx$uB!=Lg)h(i3Z^$LS!PO&J!fgI$qO+rUc2kF$L)^<6@vyr;>wy;)D>f
zj=>4xtiAnaDneLN$uk-gE!aa;vA7v1^geSM+QMBQf#QTwOz&=K3zJ`VlaRPRm88L*
zyXgtRDByk3Tz#oV!RoDBi7;gtM?8180;l5`N|i}RiinrJ=Spi&7uGm_cjh((fI`FQ
zwB(m)V=ayoF)kF0mHgArcGQh3STiohF%`Rko|L$Vbhf(96G<Ly*ota4wFL7n)nmwi
ziJB04osw`IHa8~}*OvGh?i@3%Gd&@f0WLOHNzYSFHnz0X#AWpIJIZw%Z@hV<@8q}s
zV$!tgnNl__GoDC3xV}j3-@k69d&NZcyDq*-v0b>Zl%-l?@}a!YJet#$U)*zEH_!gS
z-<<Ta&`-@juhx`kTo_t0%(6YBc*T|*7jL9}i#3}vrTO%fKc6?g99wkHFjmJlc|#>Z
zq-0SN_c-G4L+~rgXinOy%21p(MzBXjK4P0k0<ZpRT$c!IQtbgWJkq;}09D|iC?x3=
zpE7_Gt%<LUhiqWz3cOjwg5Vv&l!5r2%Bdb7_0YicAX1}FM$1&>?JvLJ2u2XDq_lL&
z5)!SE5y=F?DzE@+lPxx41Y!lIWFZZA8T$tgI|e?$r-7jqbY5}E+ebth*@G=Do0H}p
z$AI3y|GYVKI6o}npMmzm8Q?^RJV+}ti8*m%zs01GJeQb4k~?s*96EOF_51gZOPBtG
zI-|-XI9RB8M(>_tzj)!oReJK&irHzMFjze>aym)BTBAk@-GrANE}(k=^=J3T6HCCJ
zeKLSJxH+rXB;7a<x^w_c@$#Fgf<%CAAQWVq0ye>L(y12(ZyF^V!q0=@kDSg~&Jl%-
zjn*CeWG26K-0mRP;2e2f?p}K4e!^&z2Y?aYIxjDs5hH-t0mVrX?(>f9q+7QH%J6IR
zg9ku1P$-B>NeFtkp=c7=KMWRUrCZu47I8R@GZ%Y3O6l_DmX9*dulELn02s~8M{P2C
z$7u%f_x2?GG(MUI3rb2$YgaX|Re9{z#ORuJ!)VHsRTdw2wXc5d`4m7dYs)Y3iK~2m
zdi&o`w>aL?JZQwoshV@@$^rn%a5<yAOiNqY<n3*&=vn+OrR;M2p8dmYdmsCK=Y^bR
zNOQQiunxR`HajM|mXwpeBkkV?Pu(mdK~lTAre^T;1O)Asm0)iXq`&<VrPyz4ta=C}
zOWWm2zn}he#Sqn%cIC<UJ&0lG`O9~?%;5}iEOi%huk>N3jNt~kc>+TU!X!X2pfQb&
z-Won;c>D|uFyx}#<3FOP98FP|KpV}n8=I2Jdj9<R0g2a2N|cy*8^wZFxTQ7!{3$%M
z+_kjW@uXe9{@Pg&U4nW9tF)Tr2x!icBWX_DXp~Ks2wz3P-Hd3Y=kC4e3drVVa**h9
z`r<|D3AQ{!mhHRF_QbNIf&_$!)BMWYdcuf`vjP!-p`pXPdAq))QsHP1PMw|(WqLC$
z?QnkOGQDF+ax~69nhDH^>XfY9J$Ho~R7Bta$@a;khytd$`S8Q4rZ)6lQx7P@+wxq&
z7gLwE@C08FQNTMd6?u6>+^3MI*abK-sV|q8;zEEv2aktTA?dTAfX4fl=4Lg=w}8jU
zI=Cfx%s%#wcu1YQ75edc9yFB^2noj?9$o|q43mPeGO;{PtE8)Mmk-OJckvRhe0(fW
zvF{Cnj(89OEgpE?qrEKh`0*QnYiqyfZq_2mlk&1ba&mOe`Xb>N$96W}Aa-tY!bp3I
znXWyo4?kSEM7yXcN@jFb^|O(2Gq=4uIbqP;LN8MY2IxNph3RfZpR^rhK9{~N&oTK|
z-_cTHpS1n6iF<j*;-CWuuuB^0lnju|uU==Z_@wUBCAG5qzS(hwZj}vkZPr*EnVjG~
zAu3N6RR1p1o}&@$3i`=(O*nEl(XQRQ3G?HR2-L!I+qNvn)b64W>#n2g#fsTb=2%mE
zzorR}V&RzR6A=;XizfXthET+LiLsX|6>6m!27s=DR55t~|Ki(BeyJcMqo=Qr`Ubce
zm>x5oM3>tPG^i=u+|H3T?4T_`r5HGLj8=43KI)veh3F<JgXrDq(+MS~;E)fE%Fx_(
zt}swI;pj9W2Tfn0kk=L{-d!Mue+A%xgDRuX4t7?+^*zUli>kbR_`CSmX(J1-nvayT
zCUoE^t~3ZA_&)@Bb9$w3u3L230r$_(H>*=OZP~(|o;1&hGaN0o-Dx|Alvlu&@B@R!
zx~UFR=CtFnNU?{}V1_KHZsd-p-~|;~^w^c^F1i0&%FttkSeyyjG55?{1f{o@vwOdP
z{~qy+@J<^VZoMfE!UUw6^RH#GQLNCYgG=$-Yvxs&o+t#~ecKrznx~duO;P%)&!65B
znlhfDa-ng)BZ42ExNdLak=~rIQucNA%Yx-c{Y`2%m_+*j8#7yn)<e%#tJp1Z@Nz4q
zxjj4SJHlw(tHY<~PET0zrzI{sH`zY%-OiG2<%74UCd$=zOdi&yTaVA4CAzgOr!z7(
zlw3Ud;>)WOisi2z4kW(J9L{1DJ4;SUY0{3>{>Jp9Qhvu!<R%F5e3+-PlaV5_cfG$F
zVHDS|JE+Q_8B}{V1c;4)jTH=_o?=qeOd;>Vdh`|6V9*Ux{Z%I;k?Bvr85iz^C<?;~
zo<tGl?!NbKg=$43#>nz=vO2CfXd5e29TR@rnHeL(L36xNrIm5%l8nfCOf;ww5RkmQ
znLghBy3G*38D)fms{0vB?-38KxP5!FWDp~fItS*7U#bGJv1^%wdW2!@tZ180JJds)
zJ8t;Vm;v+Z>cOE^|5q&Q-GRUR?^a+B#<CqbeJB=mJ^7lp5mfL-_UYLZy=EsqyG)No
zo9JCtNpp+YT1Pk!5VcXLRqYK!f!KKQ;=zaZ)ZKR-(_2c4lhb0QNF=LMeR{m+qcA}O
z*iB+GcNNbwTyy1=0A?yCJZNK{YIF0TKQ{nHtu?T!Tg6k;hcmI4X^7oL6o9YF%UA19
zSN5^6(6n9hH$1OPZz*|v&0<qqi<Wkr?l<g4-7Tfv*qN1-R-}~*zF$__2d)lUXXy?c
z9+%$!(xZ$XkUcFA$7I)dT6Yu{hi>dEyInM>Pw+GS4;_dH{X72MkBHb8IdXebV;9Xa
zPVVaLQAn2r4ouE=Et?0^J;@Nb?Bi}b%j0Q-5XPviQ!Qfl<#N$peC=`U3DTyaY~uXe
zeY)*LG)3*lP}v@h!(5w)QZ<ty%S1IP+gQ1epzS1+Q(`h+3FI1*68DUVN`8=YjD+Jw
zDU{)obx-QG4-w!%gpdzDS#I22x1BGQegiL)4B{JNZr)|*ZNsfUoXK<y&nIS;<WXlm
z)$$immk+|cdM)N_tSC)nXPyg`JESNjeMB#p1uL6A_sU3f(5A;|z<|gTCkWyr-T#V$
z5E|O;UN7e6y~)eR#c=HitOn_GRV&dn-@kv%#*N&5+00!J_AHb4NkAaR#IEzD+4r91
z<S}B*w6ZUE?gfZ&*GB}&jf+|2XJB__5@gXbjVbN;`g_k?q7NdWtVMbXVW<dr@~9`w
zhc!T<m{Io7bxfzAv479%Gl^DOhr8=@d{9Cp7`gfGG4xcX4yk^=Xz}6&RPVI^24PP=
ze;#|2=u}1qc@>0fZ}XMS=tEZkE1rk@=aU8n;npWkz3GsV$hi7nxo`5hD}Md=#C{GI
z-=d1$cJMgQ03rCCzQS$SIs(NvB-;LJIAStx@Y!dt!4m$p#Mqzuxm5nf)8dgE*PrVi
zR2vv)?=ptwT<^bIlkE1!ns!`EZ@=B)bvGkDUF}-sZgH38%V|_tL`dtxg@S6H4J-T9
zDOE_YGtUq16Q;B@w?gk>;es>h^`&LpK5)-i7@VC^{|)%N)@wZ(o^!m(ph%u~9@Ssf
zV7}~n^4z{9Wo09y3c{5pYEoeBN*g+x1w8OPt^Vk>Sj}+8B)^1uS<8vU00f8Nk*?lt
zbhn+C7p1@|6xHB{Bda0MEa0sPLLW4^Lew|WtvXSZqzN^hs7TRh0CX^2?YRpDMF-=Y
zBp7d$1#m{h3e&`Un($<4CLSp%UY4SCVsY)k2(DG0bq$SOFjOF<rw+~=VL77z!jxC!
zdhRywJ9scJoWXoRPfOl%fp|ttP18V5j!EVc6Jz6>gh+E`u&#EMkWf|bOLMmXlw<NH
zS{k%m96^H#gF2HB)hN2U`IQZ{KEp84C^T`)EP(_$1V1Dh#A6`{WawQ6;OG}(fk2Se
z?vl>EK!k&2sv&&jona_XODlFABPK$p3bl)M{>u6!fekHYis32OsUCmEM%J#w(_3t^
z9e@?dN64f&30f7)nVp3Ur=Gjj$@XZw3D`1d(B#7=Yeho9@A)rZp6^ladDmsw#X<Y#
zdA!L;%{_0f^rY9Y3TubQn<iB0$VpB9+`Ya$z@dX$jiEA^Hhhv;m#G|Dw%Ldfmq+5=
zyEQfq?HRIqsrQq{W7TnvaiOBy2YUrybb7Leq<m<UR~|1PKD?|RQIpaUy71F@+6^+?
zpQ)4O4>Nb|jqait-jd?lpH0t2tRUOc%00(rT)T!*pPH+zk=E#!`BP6<G>@Hw_P9}_
z>Ht5x2~oS)l^GhSqarB*{TGVm{=-H4{+oQ-&RJflg(bzoMspi580b98JoHfG(HJpP
zAWuE~5Z##~K{yD9aL&2rE>Vy8`Rf<y2J154q6H-#1<NqG*Frxh{jf3;YY<BAxhs^c
zQWRs#W4MBqUMMc(Gb8bn<f5V)oYcTFP(_qosxMM|xruzm27X}Wy6fzK3mkp081vf@
zG=||orSuMNXP#WfjQ^E{v(3SRBT^B<Pby%bnfX@}K+8v5j&6_xmN|pI4S5?oyQh4-
zh&tE7+aa_@oF<TWoWDf8EnJ3(1fe5xs2uiG4*E_@Le+i#pKz=Aq?cbHG-gJR$tx;K
z#VCRN8}#HuQyU8+Cd_ANI+lIEDIQ~ZrJKo@Y=^=_+P~gUyzYFdR>|Bt0HfrL2MHUZ
zmOR>Bkf1a?N?G!tjJd4pM$h7y_209%6wJS(k-TM9^S{e&{Z(YlFOL%c^Jj)*;giQP
zkqN)t92edsI|Y=CuOj7V33CR?$jGRu^qJ^F_RuPh0Pt9(D3E@#|3}k#$7A{T@BcJH
z$w){PDp8V<l^v2KDl<C@NvN#sktF0(vR9HMD<La8vm{CON+O#g+xNJ-f4}~@@5g7A
z>pIW(`!$Z^c?4a7eZ%4BGu%*P3oAzr-vX@<!SU~k&2<o5)>a2LHxPLXZ6J@%*cB>a
zpt(^!0aSpu1&_sDtv!<P4Eu6h<A_496QGD}2xxhW+{*uMy_ha~>{wXMKCgABab<R*
zy?s7RKAUdjZo6&vNwTlToaBEN#|^qij$5jC{+T(0)HJB*2;%psyP)CEDcCZr6|d<=
zN*+1e+nze4wMBh@Tl@9f7B)O$Qo4Z|R>DE9BN2K(=DVLTmjng|A5o#eC@`*8<YCor
zxVbQml#sxg7>Ax}*W~~wK)CJdLUyB&aL5(n^Iq*4h|fWi4$5lQqXv%W;vkKHr!58t
z5G3j7k#u)w=^|ir8Z(1sj}5d(s7Ha$f;%KZ0}@*_Rd~)xz+K2!@em`77=G2>DU!zY
z>(}Sn{5Wx;tTSVH1{6P@7}5h-Wd=VrI%^2Mp>{PEV1>pVGb}KikT*=@hie@1d9ZLN
zXdtL52a=GXflHEf))2gz<N&FK+Ymkv?4I!u;};I$P)x{9YsQIZ;cin&!Qoi>^E}cx
zaR#9aD1+*ytPE%d+fg1qK6n(i1u!8iMVb~B9r6JF)r_X@Q({@Vw5P?swzs3tAeqr;
z@j-OsCusYH9|?~$>dW8BFfU?r11sfO!6>}Zv;m4)x}`V=@ZQQokBJXW5vxUJR4L5c
z&@FVM(tle}P+VFHHXDX$qU@gE-v>e2j_%mS1&AM1qgYJuLZ`;W1VtGd9ymNq3=NTL
zhXM*YPkSh4v9%&6aNNKSTEif}UA`QEgHF4cS#O%VJp}0~#5au3!#sBhPL+U`K}4qG
z2!IYG`8>X4So-i4;Y_ZtrxqsaD3>IiMnAQTHvf)RovL`M@W#`9C*_IrM8K)AD(`1C
z!sYJ1f2j?!R(gwT2%qKOvgz7UTXK!dq?YP9Miv$xq))e5PruS``Fiw>p;4K*_kD_G
zv(WE=2vSg#1v0e6iUf>~7Zas@Uc=gqGb7|5r)<mFGY3^Jso#|B#dreywam6(@g+a$
z3Y{*yL|qp&X`2u0hL9g;V5R$y!A<`#9ey2{^GSJ<s&jL5vt=nxYWTyC{ywpXKGR#;
z-CyDZW{xtfAT4YQKy_#bGy>)7EG9;-!R&&GTS_@mgpD%JhC2L|Mc}oABvc~3d{q87
zU0edQ=+l&uQU_qxA?E7!nswaE^nu5bUZ^i+H45{oha6XcVkqYh=UBvIl9EtSoWO;F
zIUYKD?E8D=k=b+oaOE3USJx1e%S=JcVA+k1QipA+*b=A$H&m70U@nqT6}aJn`D95D
z5)y@Q<X1C6HC7#tngG@2tOVh!fZz$IhhFOkoCUXhU-#DZk$K)&i<1=qYOMFcb%MAB
z4t5+n_Ew^r1_s^OG$OS$3F;vz&!AZ=!I46NjRpE9fym)Lmz~q)g@!+xBC1;CGA3?R
zX3?Bd%hcS1lY4EMmhlQTA)r5aCb?*mR*26^Rp1-1!$s5BH>WP2|IdMkXTyEoBJUD*
z02QjK{w*>)nf5kU4;jt$4?6T#%9Q3ig|#E;F`H6-nl7it@B@4fw&G!0LusuxqD!0X
zlE=#aJZ?)Hi@kds2_T0L2UVFtBx&`^i?8E)QcB#3QueIXhhCn|p%U5-Ilq2~Q5N?_
z3PFPbaJC{wACR+R1CQw_mN!F%=MQ}yOD%dq-KlcR1PC4Yya{6eBUjJ5#0jea#pHNB
zm7Jlm4%MGYt6Sd_(MFP5(V$%bWQJd0Tc(jQva>^*hPk@Of1~4#{e1daROBb);wJ@}
zH9q@#S*7tx8^%XTJb8a^^Ypm9!HB9@;nr%qLc^?kU$wn#Z0?szU)#^%k-d-4>hp^O
z+2>5-ro-(5GKsFsNq?+GW1$DTGElCC4=De#5@XVg+h)?ccgY_=3d)(fHZPbZ&vepL
zo-Wsjo`*OEBJJ1ulU(TyxE1@glA@Q@g`k~BQF7=Ia6Zs9@rK{AlK=bKly%8JnvRn4
zJ>eir(sM3c+X>YwRKMtm!JG%(4CAAJVmPnq;!y$CU=RdA9|NpuX#ZiH4p{GSc$OXy
zXRkhLRy!QJ^B1kxisMXcim~;P6aVdHs|lOC`mideKx68B<0G2ExYn+&m<T6H;YSlg
zCpSKrD&AL)y2c>wB3@9KVR~-m@0X{kj^yjp(#p|9rta;tA9Up9t5+6$vBYb9y?!hz
zE;cSgJPru95?GF|?jJ#Z@29Vk643CNR-}2!lLgN9U*&_QzLDjj!%jwu$_2@@6QNXL
z^<d@T7a0L)_p?(KBh=W*Ilc8=Cntk~`2^xU{!D!`x<=#uKrvY?Mij#>jgJl|PWY#3
z1RV%!8%=E)zTir^-S_lv3QcqIhg_B0-zd`UJWyM9-#}JIRJ+(bz}{A%zQ#h4g`H3L
zNWQ&kPvL<0qZ_@y`rG=_r?X91?i!lIwH#%-cscigeHn}Nnf%S~=GQD=6lI+|%4{+*
z^}9-<;$=bM4HkizgxE;QlcxT_=L_PToTdg@5MRY<)5ew-mxbrkbXd<Qf0-Ea)l~n{
z?`iMd)FNNFIe)ga)Uqi&{aD?s#UIvn{e?Zp?k5dP6l%50kzMRfu@)_Pw4?ER?VOia
z_L)BGT!n&y2RY?7Y>yOaJuL^0984;{63G#iEh<-ZwepXfC-AI^vID18x~)DkGSY-s
z|K^c5y*1*eom1k=(Q_<q8}*nL@yprSd-Z|GyD~-!f^4XYOqgKgv@R(@7F>pmET6Uf
z($d^?)3#dgFUP-lejy_)qL*9aekC+$O5Kw`A?(+C8<A#_PnaL6I_q8AB#5$pw?TzK
zkA@A~>f3pzf|r=1Sh!1%c3$C4Q1JYZ&IflZ0&vK<DJmmaQcfQiy<&as!WO1s%hPw-
z`mz`Hw_WnljV6nhD{M{4Z1H1uS5R>MPhmT8mpXQOI=iZ>?ouAFB1=Z*lej-VN@?Ns
zd_L0Adu2Yj=!(5eBrZ*#0I%oP?L5|F&M}{|+6{7yI0YKDWLY+&c3EtmtUqp4#zRx6
zj5`u2p0jF#H~QGaYM%*3pLx{1RvqA#`E{l?T~q7O6E}^rj5L2AABP!VHiCvh5GP4<
zGo4Yk(~x4$9Ore{&LWG`DWwOi>-!Rd=QzXmSyRSJ*Y4%+aqU1nA~^qIvA+5FqI%7j
z%@iuugCFkBylR+cTk~utM%!)bz?4Xt`q;{?!fb@F?L`RmOn(lSyTD+Km7=k1!a%W`
zlTh!<*ZKcOcC8AQxC!FP`OA|Xc12Oafdv@9R~e;DyCin>Z`MC_+BJGuZ<~a-^yccF
zjo)<^_uZ~}T3-K2*>J1n5hPm?PQCSktSlq!yXedMzx6(U>^vx^zP`fwWdj>VLyd2A
z9mQ^}f}pvs%??qdr%#)D#e5$xUeoZdFv$s+e&ZlXPF_txe~a8_)@Of&+CO9K86%_b
zu3;b?lrNVwHZxW8<{2OT>#qt<qT0cSA&$-T*(w&zEnMBJo_hDKL-O(tgdBlm0oWSX
zqT9c|FzU68cy|`&WaVrr<Mugm`2Z-ZMU)t1-}=URZxeoljwkzpk7uMrSPadItgx_=
zma}8vKXDfR3Wj5~=0i4Gtih)MmWfMlwT8s5qY3kLf*|(=Zw+yjQ2(&L6k*$rji~Z|
z{1c%n{wgULX&6=h53nZ64!}La48(3-NY_SPF3RpyGVquer4<Q)A^XzGgoc6XKAF!f
zH=>|O+)&)sF2~+63VW3T&><9Ki?L^fp4x8x#qKd3i^ua^LvMv*LZB53JFS&2*y)Cp
zmzWsYV`cg>NB4WMTlr?}8qQWo@tNRHEA~MW6sMFUW1y1Oq42TKDrtF5S6<K*7MVHE
z-la2uMtsOYMphP}Y>WsrHL)r}+6FM?z!ju?_=GYM6(4(O9V)xfpM{k-Y0z7-8a-(O
zzik1atP&_YG4U1>LPo`1#eMO=OF*%MiWV`O4rCZrzO(Im1F8(DV&~5TB#l87I&Z94
zATK4AtOU0BI87NTvA#$Dg+2u#<^SA*E(GR-pppWRf~pD2CP7;sNvl%Vx$me<;Sh%Y
zEnb1UQbhw7E=&pl>(X7PIKbU2!A(U}`>SFhf>-TJYJZq4tB_a9*uu91r%NzHW_aUI
zC(OaRbaY5-CiMNWzdQLfHxMS&a`-Tu$P7tKt)-=65fLJBTh3?s{i_JsT;6Z$9sc>B
zZx4mm1!jcBTqJ*bKWy~fyxNnDwBh&&SohQIu6@3-)i7p%G<OaUjUPZl6QmYVmB$1^
zTf`)xt|5GY`+_a+d2#UxKEC=c(EOIrexRTMCieAZ%*5f_EG?C`CCw92ee3Ay&2;Aa
zlgQh>*zy791GgLVw)VER+Yp&y&X1CjP(Xqxsxd5;cJAJNNk?Z30Z6gEwe=Db1+a63
zg!I6Y^0TK;kxo)uU*Be(kG-XsxVR!?KDIItXGVQMMhN@>SP`HJA_*iQ_53<{`FKip
z_B7N5*gBxK#-0Fu!wSNUfHkWb(YWh!h}<vZ-?8|pscCI`I#MU2^U<T>G3M-!o==HW
z{@jesVO}@7ulI-C3|c=`bfURg)-q2<{F~T@d|zMpB5N6SV9JI545wH+-H2;z*PAuO
z`>_PU&taA;PP}v(=+U41W;i0h(OGv_W@>G#2m(NQun2?v7lE$G*uu~g6(nkJ%n2}d
z27DWFdVjz?uL?zKQ_7DYR~Q(=u#Lqr*tzB9n>X`#JTN^ZIdTy&wT?jo=u%aM|H>8^
z<Ix`hX2?Kt(IfR{48<E62@?asA+W*q^;Ul}Gj*?{83Snx-&jskUaK`SYUsCbS65YK
z^V}Pth@Gn$HsGK3mum3shlvnPQgk%il8-s?KQLq&!kQi47$5DVq7d!+-%i21)Ue|`
z&`J{wSG_lA_H*gr!o*ZN><zz`Z?9MNuO)G=v<@_Lg(`0J@y5bS>Ey^PyJ|bOQ<L)C
z+Sq8zU+=Y>M^7=8UH{h7`0NbxDL2Ehta0jQq7zaTpmomirl=|hg(fI3bcd*v)|w}c
z$nsSlbud@K83!o{Ha~FNVrzx1vyjkd%RE31NM_O62P|k$NU<bWQZIJF(1pw*#M%QY
z4mZA90BHb#mlqT^)R*8&S6~i?Y2%BF-p7$wq^+RfW0GSJ=Br87@Eobl;pqmLug@;8
z3){i5OQ%#+K0!qSpQS<8;>ro2#Xnl+C1BHPEo$<c6&Ya<tFIBLvR%)^x}4Sq_Ajon
z1Ya`TJ_j4N64ex^Z_crhpIqs^os99p!#1cyme-ayK7Qm3C*z@RUNm1aYi-!<R@Oo&
z43fD5Q{;t(qpK=4*C^T9Rbs~r!tNDm?%>_>hWC?&yRGjY=fGhT+43R^(1j~JSDoW-
zI1JYfrfc1?{LQ15X?St}DZ`h$<#zXf+$yC3uN<~L;FIlmqzdQ<fQ=;M6>3<_5717-
zp*rMx$-inA)~)6w`2ke0={ghyx>Zagt(s#`rC!A7lavbj_%RdS&<huaY<IG;xnf@k
zkKB?b?hL%U$T=h`Vdg`Tjkf&Ilg;#Y!2N+PVdvlgPB-`Jhk`^W%*rv7zz7*`%Wbr@
zw@m`Mtue`i;mF4d&^XLFm|2{%ymzsOKK#c`1ZaF`UIQvWvI}aAoZR?8(Z~k}ANlg-
z5QFTG8q2V=Ck2Vh+1GRPBV<|K(~Yxht6w_~6>WVb8X^>ne3*OpFx*nzu|u$7qxibs
z?`-4d#`sI#p<a*fAKdnmTra2Ic+OhVfq0!$*Z!ML6Hh!gTF_J&Yia%dc${qF+ZHUT
z^6tE0lSl7w|Lwb6{KCfeq}`MsT|Hew>!8bJV8E~hPa7)lTzx7kDm04FbhLJK!0@|?
zkyIHxHJFZL3lFSFR$>1ww+;;RsHiZGX}EF=iwwo&hQ>w^T3}>VhtPl0g8@bZ$cS#2
z_F3k^UI;}6f!)J7blwofnQicmA}tnMDWf8XA$aky;k?tlOmK!l1%-9ACM-0dZkk~F
z1Cs_|H;C{f2!Jn{x7i;msu_CS!}n+?&_{@qbh%KxuMOUXZ)V>k(Ypc54wAzo%01n$
zRyJ0D_V(@*3|L+8%c+sPoZ>yj$a@d0zu%+BR#&=@i`*5BrF~PBpZ}8kgq7v|BzNKK
z(wXLwrDEUNRau@lAPbm1Jt<&kSomr5nD<ub(Fvam+nxtsvu4X36TZ1dDSqwyo2}3~
zVaGf%08vg~pDc0%K_z4lwS+*csECb}BaVeHth3d_b1K)z@zcAN$w6qLl7jg<a2&W)
zI6_sxw!jOH2_k6#i*pfD3Js2J1E*42vHcrLaL4i)H|O<yZ#MA!(4EJ|uD~RT`PlVx
z3yjNfFK8ypkifE50>>upF!qw@Rx9SD@q@hz1pvK7&>Q)E+#x6KYl-~tlfpc;BV>D1
zQQZbTL!1r2&VP}yht!Ss<hz>ZZ>|ijRF_w8Wg9a|emyG?EcVVh%f<W|?VoRJ9%r<|
zMQV><&E7Q9%Xx3ynl;HO3<<}0;K>U~8CJ(XAwjd_t7vht@2TK-7_J$~CS1Q}eLkDP
zOGR}d`t=TI!a`Lh#>RXKexsG%|HxWA?y@JIj4J*&Dk&$R>48o!yEPg!2!!c^Aw|j#
zCqX8=fZquV3p94zf8fC7zx#mU;0+(jhiHx57juzaSQ%iWfrsMddd=<OIaeU8Id<<x
zBV7D~m5j<i=)nUuRn;-DfUK>HoRHUW`@)4*oXXftJk+L8D5^NAK`>5xgPe^a9&+Fi
ze|`RbO9P{uYe<ylr-u8*8A|o1mSyFyMyel+6WV=t^=ykveA4S7Uip9kgsvCCi)m-K
zb4cJOU2W~fn`wuej~wz5dw9o^&u3rXf8Ci>gyTb>mCJf9mhn4+YsKT7`%298bV4=`
ze6)1ejnv<lo1<#bm@><2OM=VRF9G?%8McdwX+QHe1b1Vl^e@#RTG}PM%Xa$LFMNbp
zfTZjk#mfpEJw&4TUxEm$H!QGWS=xN+hi3;Ke$2H9A7#?M)S-K$haA?VEn8sCT|@;d
zZEG2Vhwog1Q~?T#_d%#qb`u1RAN^h_ZJdRo+K~T26G0G|=phdS))n!%8?LUBfLY_Y
z?x5u4=I*s3y>aUZtoZctBRGi9<2drYJYR>kxK2%kghU@RnUr^a-q9Dm*7>!*TwwWD
z^_3?aKm5B-KL13hU%2o{Tj~(Ai1D*^J?(~)QpZNWe4Y!BGxWY^AL2L^KK?vAv6d3=
z(T!Yv-K=@j3b}?Jcc#=0c$PyKZ}iysv0YZ4RQ663X8Q<P5Jtp6o`tFy!u*Ak7=Z^=
z{%2HGVWrwfc@oQgO#f48*GVGBRjfRE`}%TDuwq<^C$GwH%cu1PjDbP*;iFoZoAdom
zV=NyI4hBIaXoTIr?~?#}>J^bYP*>uWy?OKI>(WikABUc#5CrUGSe1m60CQO2)1)2Q
zYkW-~n#id|Y(j7hkyIWhsQkCm)0-et?;JfBBjYp!I_V)fVDkaYx58VmqthHWn(J0j
zp(<*!Ds}a0P2eKkg7zbFj}zK5Vj7I2Hov&eYb44jrjAE{?CICqvs2J$%>LSE`^8H#
zJ@#)&A6KVdUe2l3@8g$3q#a&0L2L5GdXeRb2VdNxy+~K^10D?jr)c%sW<$1e!VLB)
zNq!TkAcvSN?3EB=8KZs==y(~<%=^HO8in8FBB2QoRDH)Y5X)kcsC%q1{~c5mP)Svp
z-MxDkQ?h@*>?FgXsH;2%`46&FMVG`N4;6_4Da$*)IT2g_*6=X+UxQbt+?Pl>otIni
zC&PKZLU~Mp-0#ClH14a23dO-Zv-sz0bMz4B&KlnE`ibN6lGY7POh@AGwD4xmUvVwb
z>XmqJ>rn8AVL#^16cn=icT^ormzS0n^YnCk@*p%%BR^aGZT^w&4^$tXsHFBh5Axf~
zhnmoNG3fhut;WXftRJ?VR*^WJDl*gGr&!6P8<1npX!lF$R3*7z$==R_!Y@mkdM5+Q
zF1$v7bz?(Akt;}8)_1vS9&Te(8g<RmMTj%T<a93UI~W=37~T^KMM;P>f<{6|XJn#-
z8auLWzCtFaOGIMeczGLt_Dg`@atn{luuU<SHTWEPYirdM)Q^>vVs^@}Ae$_)Y20x1
zug5c?*7hSe`4s41YW9s14>x~orfGGZSUDQEH+s7C>wQK_3>zmWG2OTMw1+|5-H(5=
zf4^m3S)rc&XQ?k`Z8xJ0&#8qo^F9tUq8vB01(HjFkSY2j?{*tZ5m%XhSOz`q>$a7d
zB*n*n98!N~bDf5Ufd(C{gM3?8*K!p#7h_QL)ej!8JLj72AWyhrHG6rK%WYCEvO)8Q
zO){6`cB<ufcgS5_I&6*N)SX!$N$ZHV2M>*mM-<80{&()0Hhbp1U7yN*lq`-pnSL`A
zJ;cmyM$pp{!~tGzUEewW#L;b;x)bQCy7IaL0wPLXG~=Z8lv6dHeGFp_E-NvZ`xX~L
zvGC;Q=%>Dw&<c;amfVChW`nLQocD%(@Hz8xl0Ij9Uv9u|@SfapJ<lq@cDgLJNZ;+J
zW74ksbh8Z64a|KNXUBb>Qm5-qaG@i%701@-j^)p<m6bt@mBMjT;vCxg+*g$@3of(u
z()~waqm^IgG;%bs#!JV8zwtoq-GVo&3Re~DY4@D84gB(B{P05xoOBREG0==(D(}7C
zx<BVk>Uz)A!zQ(54*Mqsx>Dt)E2esy)MR8sUKALFO&dbejgnJ|olf4qf5}dSh2_iz
z@#>YkI$=~<N~O<`>XDgysb6MpSc5-AWf;BSn>=p~Rqo>VtD6D4wrR$X4Oy&lJ&5Of
zHej(DOIJgeW9lZW>ERS<`u_6(8ND&}32tVh-f)fL(kn?{fsFQctvy_S+-_gHcGi2-
zg6GSR6)}OskIENxPkEKU5BpWYZRY#G(Nu+Sarr!+RYn?-wqGyAuCEo|h!gQjvF*|Q
zUBi%Nuj09OzS3q-x0v+((3;S5Z+N4&%ie+J11lXqO%w1y*rfWlQ2DfPi&0+;i}Dm{
zzRte;Z22lZU&zTRGhIVnubBwO?2*9K0_J!Mf_m-S{GgoxyCP0Qg5mR%)tAoC)p@0z
z#<i7{8ga)stv&Of4mqMnCBO3WMUnn^^XwgoVPnzp#YoSlSBI6}B=_w7GtjcW+8CJh
zuCElE(&-DN^Ks*Oe*Pc0u%{+%y(e=U=FU=WR#CUR|9v~3Sw$AYxNF=)x51{skUF2@
zVws~_rKEv$`0hXok+?uDEhKBZY0hrNpMT`Xc7rU&z>h;0Tt(N)v=#F8`rMNz6ffKF
z+i^W{gtqg_hcTBkl5xMqwmm&>w!g_hlRy=|>zJjUUed>gLAkZpT<o&NKWuL3h>3<!
zuFluwo(cA69eC^bCfTdP%fXPV#_g$Cuf{iSO3J(Ldq~f#eCxzj-RmwF9~-)rIIO9h
z@Ooz`@U1M@;dTgjT{{y+aG!au;dFVD`;G*SC{p%@p70HJe+?k0cfM+gX<q!Op4*Or
zgY{`4>CX1xo9@hiSUvP-_pu)Imf0o~=kRyEk3(Bmw|sNswDzlw8E=M^Hoiv_@&wFB
zRha_0r_M%yKQR&UUSj5R;&XBb!wW)!lE;-46dVrTCmVEwObsuHQ7xlNMms$n-ATsx
zBe(i`dm&)9v&#m>2P%@7wH|Sjw$am5Hn{dyr1D7z;2NQWO>S-I$fjdYd*AO|YEg49
z<LFWTeW#e4wwBed_0kOAHOMNzHDYeYEqAyvK_U9Q1WQV*t}Z;GAy==y3DZ@+Fc+Qy
z3hs%151A)B)!y&;K;0B3zISTRFZBh=7GA>sMTV95KB(Pvw6*oK-qdr_LKjri-nJb2
zg7@m3V)bMpr~HZMo}Wd-b{~7cv7VU6htpx21q1(Dw$M6Q^|O)CacOrhDj1l%;JH!d
z0ht_WT|HBaq@;7il9AXXZN#C&hr0@{>me|~oG{X~vN~&McuJMVsXPDXVL=PgZm*T}
z^@c~;S?M#Kd!1cgUFZL_UlJu&)G^bL&{V-o-_P-Ayp%80u#$FCGtxQO(IoU)_Azh8
zss1lQz1*#5ny5eAINx%QZB~_y=3PD0uD%n-#-Tbo#U>_S@%k;Vo!ODq+MBuZGp?>$
z@i2X8+-TWSbEhL&KVOq<Q~Pg41srv_52G#@_T0X8OHED93t~`6R67Z1*$^CtdNumE
z6(HbXR`#M4LnZ*|VRTeAfDyoDEyVT_RWz1c=gx&Ha61(23EvTc9_jFxHZc6I%B*xu
z+%WaJq^YRYaVjfMdQxUvOFNVN=P}0;^lw#F8%`6?*4M8M>&*_iZKpDHDgf4^|C2_u
zz`!Nt$sha&oMdl25ZAoNM+_R(7oW_E4$=BZD`fwG>=DB~I%&*jdW}rApB!Zj$-K1l
z=a8`A07K!~>lvV+)LGP*998*xU<a+9o6O!12}U|Upaz2-L5K|_O43AuARJc;0%|Y|
zgP60I3Qr~m6QrD|*9KW=)_L3Pw_XMK8gELT62=_ByxEF#h5@gDzex}nfT#>i4&bRq
zssW4<*Rv6Q0c%8mi4RlI^XzQ9KP<>F8X3VH4b*;<9O$7WmJ5y^KJ42;N%+*7lju9Z
z+bqQu>-;ZGMwESOc=+~uDd3j@ikQ5_x!jU~d=s9l&dx(oA24f4Y6%Mpsv6>rlHOBY
z<i|#2BjbRKK;gJXPCV7-$Jhbs)|h-DBmypdG*)<g=t-^>sJgM+KvFJ994W2b2emh7
zQZFj;7`)IZ3+3`Ld~f#J$=Sx{`e|mSLv^zBVO77=!=L%dCMaBe#CD*rhkxTv60AWF
z9?VzQ^hFBHC92MNCwww6ka~CBD)?6C$(pteroX$WZqB>;o$yJy{rtB3@}lcWj|!FE
zj2+>*O(XkWiap|<kEGN8`r|=F*^TjWeyH`2OLorA*1W^xN!l$)dY5lvlQVRAxMWGE
zrM_%WZP4w7knDq?O95r~Z3#abqJ9W7SPDK-!5o2x_U&6VFix*a7zpSuAswXhzl;)@
z@PR`BT-x1!UK#pKd-o>9#)9_*c{yer7zjd@3K2Wtu$UF%;BZ?QNA(DQ2nH+=VJxk2
zc(fS^M8b&zrh$Vbd{B6T|DpI@Wj5Y!_d&l-5-M|ZSEf5a4T0=$p!zXRgn)T)a4?RI
zz={&$NkHlRs}OPp$OHZ~(1X|1L30cjp8_{5XG3#K9P9+9Y@j-H#ObT0V%qBpU5?A9
zdTB`sG+B_EQ-<BzSi6&Y@dOInv?#J_PX=?MX!~}m<G_$Z?#(6b{P7Nms2Gc5UqIuB
z^?|o{MPR+X;428SvtPc1h7SWv2(nQ^%gFS$E2^ttX%-hdeuk%^-fA*Dcl-7+I1S6w
zO?Do8V7&A7&G{ehHxIPlVP2%TPH5|a81{o@cVq19lTK3C&os_H+<R`<C)GCp7gQI_
zBLf5uTsGG7TGGtzJQ`3IaOuXSRhz{KI_76SLFc~QYOK?*nzG*f>&nU<qpqv3e_l`T
zWU2w-FqfVHVJ`jnzJ?3>hh*=(see{~-r-5A*AcV{3@6V+Gk)$|Ge)tX<|A|uNF>a3
zaUCX5k<1FPGGo9Dl@Lh}!a+DZ>4t<C;{;m*P#*Ama!e~Y%W3<&_4p$&#)Rq-&;!^Q
zl9PQKuR!>SNhJ#_E9w7eq|HFz1g=KXaVz>ghpj|n@(qrnZxCXW+#@I{8BKD2J*1$f
z2QD1;ZT^UDhP0M>yZfW@56<?#{l}&xh?G{Sv4LF7oI9KP1&;(45}GXoYAV&fci=|2
zA_7}UQE~D5rhnecb{iT$NPFVHk*~D@xT==Ys?D$C<+TAn1-vb1cpe)GQWNKqg&u*0
z@K>7!$YP&hI?Tm2084=M%DAJ{{zqe?@dN=$3w|cptl(}^=Y=oROb9*3?c2XGd}rUa
zi<<TjDRPSgh@Ok-pPHe(!~Y^*ItVLVXklnM5pxb{Kk|;N%%ItXOa}96Jo@kv;CBT=
zrebxv6l&{?_6IdX_m%gvhl2KvpBzcM4=*Se*(+@KX+*X(W*UI#{_oebXXZ8c=w=Nu
z-T+ba2@I;f3i}^nZ0@VT9ie6{JJJ|nkR|7}rh5AHMpHzu@QhI^47uCEN8^b4=;`)t
zrG3YBqll$Vc2UdFZ)-j;X0>2urxWAV8t5%Pyi*(s6aj%Jd*r?*xZLCk*;_7U);4@0
ztkmt`1|!Fn30<d|Lj#YxBF|Jl^^7sT65l`2Y#u;Noorf1N)X2QDyarcOhv=F(hd{W
z1>ff9hk|!e+ltrs&q#moY}_iN9`=elEXJ{=#xf6kPDwerM3UPGu3BKgplXGFYLJRP
zP$~5y=&h_9I=A{eA-hLfhN&roy%5y05H<?2eakk^z*t%a>g`H1A@t^W?x6L6_rnN5
zrg(g@$AZua>;kB<uu8#mfEBQyaS1bi3pO_VCkH-%#zzIAR$$E;4Gm|zeA2f7W(<57
z;0X{u7@^>Nfn=-Jyvx=Zv&v8v<XOSQfK_8ohY}+*CM0nCrnKTFlk&t+MC-*`qRO3r
z)A*3ZlNU)JC>;)g*M%2h&HJZbBYXe=2%z0HzwCh#JmkX|On>?EOgE#nwDb%Q6Xi*q
zA3uLDL$?e6*=x;5?KU6;1JnzwY=C0w^XHXmWVrp%kJ=SRMMS_vm(r@5()v#@ri-Tv
z&J1YKl3c$B0T=l5CnP}_Iir%;x)tkZT#K(>*}%(CWroKjLTv$yC@`(CVTn=ag+`5)
z^(SUyLTu2#{fk~NQRTTMxd&oH5||H*1Q2i7L+N2R$kj)&0WIB!4@Ynmw<jsz&4q-4
zcQ208r%wm5qCuu0ZVCjSs=_HpR6+}=k^&g%bx|O?Ac)2E{QG#Lh7?BS$4tvVj^Z__
zlY0)}(T~y@gLLJ`)O{9Ole~H#R-|QLC35O8Y?bKR`?=o#=g)f|qQV3Wendn|F7gi0
zJ^FACyY89ZF55l4^6Ys6LC3E@zP^cn#eadCMP&>9RP@y8b+gFssB08N{$axIR(l2e
zF+5}#{AqkT<>C^m`d&kI5XIfptHv?MZ_wAc3}o>i3*T|`?$zA9LaVjT<gvBqW8r74
zVdGfD7c<?NOY!Y7+(P)ZmC~;*VgO-W+S>8*-d-3mAtJ`PAL(RNNtV!H69iuScSk+(
zIY5MnFC88oyx9NT7$djtVBU*mZmacnT3QN{lL>zpD9>Yfe(`LP?3gzHsDGZgg&^JA
zPSw`iy9R0Er&zHGmEcSgLKlYygoZSf5H>Yu<dl<KLBLM!Vr4BUE{0eaIR<h`o4|QO
zf=EH&%z+a@fS0JOsZkPOO_I4IvTvyHM-luonVFMF(8W$1lJOTWRB}3w;SK3`1IHG;
z-Ph6ZD5#}^eYOGkBVG+qkpQ12d;&S$RQV&Sn+o9)u@=QW2qI~-CGfZpYQIbLyHXH<
z-(krN9WZt%Sd?Og4HOp4?I@1`iS(eyG`#RePaSC^bph)W50ACFP>xgkTTuyM^}`Uz
zj3B|CLGPhHCt<W~3c3Mdm5aOsF+8kVc%k>vkZ@Ok6`nz1=ePpVGxC9esP69V4XHJc
zQMW`p3xNwXqKp)S<&-4ZBFaJZ2pB?vrejj!B?}L$LDnZ1{DuC$zM~OpaBX1AgMXYI
z-8wEfDk>Wg=%sk>o_L#(p&c2^e#$Uh?tKjh+avGzGrq7cv$GgwiyyGqlOb!Q<owpP
ze(}Z7$)4D;JEkwZN5{pAc8fQBOZz3==`fqn>vEoW?&fRH$}h9wJtIBlduH`Fu%X{N
zV1sNg-zdq6+SOw1c<C)~1`EGnWOcVZ*;yLPz{wcT`ymH3=gj2yth|<}xoX)+=UX_1
zdYH6MuTer#h8S2FL%G~1N%Y#UT=n-Wg>!%mPS-|cJ)FYg5)$%&xFU*BMrIA^si=Y&
zDVHIA+$PH!jO9x==IkV<)}OJ~ij9RFsEMKQ19%vlXcA-!*{h)akeq2Km~aE)RKkpy
z)K8(shvX9?Tp_>+2p_dnH+XMwqv8}JVOFtF>m*=D0H7cCNMCo?pD|Vfk(-AzzI1c|
z?N?`>+wV4UG^I5f>m*3es}nB}KCo4WH{PuuhVQP+HW6muu=+T8?+p;x;3-Ff67U@;
zy|~=QlCkc-24o&Y<uLVux`h<w<Lse|$+H-1erl8lqzVg_e-LI*=#KH@@JFEfypFvd
z*tgwpZ;;0OMn=GZWMG>g7iWkU5gQw8QH&Q!KlrcIC}bwVj^ByG0l`Li^GMTj<UnL)
z-2l%L2tPVnTI>hfYznYIhN_)wvLYYKhlYj*1WX|^6|jQ;NwJ@{j=em@!_mIJ^;x~T
zAZ{P<Z`aq>NO`y<Up#xlTovI1?kz4n@W4QC1$=$fiN^1b+xnQ7%D}?ld0pM^o+G@B
zLX_2P_O=EBaQ*J}b}#-KI3$r!>Tq6q%;wS#_~O&jN}oNu-~2Z1xw<kdM;x6<T=EOv
zh+Ax~C0j4NIP*y9XV`1$N%Mjw*WYvT(|fjWW6b4tr!$kgp9Z?X%V*DeJ9fF=xq$7p
zV>{2J^Xcmu{KvJ><?@+rCCl^~+4muLY``l(?{uc~0>82R<x*{al0DtmVc3Qr@+X`-
z$gaie8bY8q23fF|%5d5{?&oIXk06~%n2fvn%fsu76B0@nu^4qUMK}@rUtg|){u)=|
zLr&QhK-sEJIN;(ry%||$MdKhO7}xyp{{5vN;hJ`m!UYC&R>P3=6&FK0f1|I2#p{TW
z(0?^UX1SgCz~CtQ*gp(B>Ni9CP-ikf3s5qF30hdVCK?M8**20(2jh<f;bzp9B>wdK
zEwrqpB(UY>^mZGdXrW?;TL9l%$itX>bF;JPwNOWz=T>s+5=2~c9sd38b>KE-8x_BS
zHy^A$Ou?T#VIBn+lo!#7%kv}9UtwK}mxq)+&mHxFj!Fq`p?8CLT~L_duvgwcH`ba$
zN)7z{?Hem2Ba#{s(T8AGpldrI5I%q20XGF6Kj{CFx%OCjKS~D_&FF@}fZ!2W^4dZ=
z!Vpah>k%Ixn0@`eIbgxV&0d{@ZvhZD1PUG(VS9o8iVL|lV#Y@e@*CQ}sEY#hZ+^4B
zO><Rl<>f%<qQ_75nO|++yS84Sy%d*t*5gyV-~KffO-;|MBgG93H`5oKWk*KdWD4B8
z?azBu(rdT(aO{1tY!jcj){N;so!p7=XPOSygSC`e0SpgnT0%dQncZHVF?KIq$;e@U
zxOd{=_Tfth<4;#}E_Z}@7rR}xqrwJM$S$%|ZU3VySFb`EG}B!`TTWWIgDL*xiQ~Dm
zxF}B-ReAFsJb023;5~kR{w0qMd>C-Xp(#XtjE%6V+pmLq!Cn^V8xc5oX8C9@$=~@}
zm+mYmqAFIe_G3Q`05Zw-o}QMdrm0CyR94kXAeRZQVTWQP*pfzWk@7+?A%Oi2QBtO5
zZVM#+Iu6sfc>mH8-Nqq&*En|$N+<Y9dHdX4U2%8T-28~0^X%{6NX>0(ZXTI)g$%_S
z*?~|PU_cpzpgbg|j*bEue~2|0mN!zn!SaA{TAn0Ig#|&fLK#74*q}>wPf_>NAOQ2O
z79}V$ql}c0Vu-S@V-{a&NDc`$OohAqMiIm?X_LzvOL91@&UiOAJUwbOCiYgAOZwY-
zBVPfQIa@Y_H9xt1A$@NQS}$f3J)Qmb@HKt73WeDluUR9-`3Ij_vRT&|u00k@n2>aN
zHKpCCu$6`3C$*2}Pag@vVmE_q<%wGqgR?`~$0{;sriE@DHZpauP7HPDORnD(!(@g(
z!r=UQGx0e4PVRmC@Hx|p$2Hp&u(GgBfk}@2KXToR%ddi`0vj-174OYeQ=$^DGInrq
zr-nEF%Xp(8aQkEAlc|J?y}$r8e7Tj`DkRig5kW0TK>*2tP7FRldr4v5@N0Qp_-c@;
zSyO`pB2nI3ZcP_RjnAL|D=c(5eLAqpY<97{-JSs&DAcuuJ@B-{?urT$2Qg&xIr7s4
zp_+OzM*S^7mR5;(sQjMdn=lk5J|)VcTrvVe2Y5~#JfL98;EE#mefs+K=a}CV;sm(1
zRIBIr%D6I$6aPeoxLL>u>w<15tWwUCdU?=!V5Y@31KsAcXZsP62<^8hJ1l>19flMk
z6LXLpytv&%E=hqKWbA|T@)b{?nqd($dj|=AHaBkIU4~x|w=XIkOo4K9cL;{fo~Bl&
z3CG;nK{h4ad&r@PW4h>dS4HuJ6vH+$LL(2`OlhSkGrOe-M{f%u$H0Kgh|b_NoY`Di
zc@)m)-pz6Dc-c=mmeM=7blv7HY09D%W4zwC?~Ji_b3e__LEZ4<rskN*dG2DzYlEG+
z(+}y-2^`z!xARP;djG&X-b-z{KP@7ZBBq&tzhIkHCm+06Ir^Jy*>_cUDYUv;qu2<E
zId8oCOG-$;mBDz(Va{vbLGHI+3B{bbQsSm#w^e{u8VMNzijWj#Gf?;_ogyQ2Ggvg5
z8qIU<mL_UOZiPR741Q}f>csmRX_zS3cfElVs|D-^7_^~{sn}S_s5Qr48hoGtX=Ko1
z23$KlhZB;16gz(K5kNvk79p&+z&(QbT{M)B1L66_U+CRQ7idvt=i3`SgN49p!ur!<
znTK?0hz+scwYzy3dB+ec;V>voJsTwwqh4%Oj-yt7B^_y`Fo5AVKeC4xJ0oaT218*V
zj}H&OUGqK`B%X|nv;XWgP>MksL`p8BB!`EKiRt^u2=slRRYQ!27y7MT-wKWokiSD!
zVDs|u@X*cF-@(edh_VhZ3T}6xniZ2-1&#Fe^hla4P!y2~fL;vr6v3#t#KivYZYleI
zna%^qin-SQN(X}~lpzBHNg8SJr@+5cNsjsrpWDcXV-+DmL8QPYR3(zA{YlyoIN5P|
z?A*pDNJ)En`<?UNn2R3+#yw-W{&tZOMZ|;J;rcg>lQ|X6iE@3V0%pw|ZT*a&c`f=z
zESl@psMH+bcl0h!OFNy;3`o^Xd4_zooy(6=hJ$>iqd&HDN`1Zd^=aR=-c!E8mdnj0
ztDoxQUnRe?Z>qQ!DfWSG{^ZnC>gIRCRBH$6i=fE!@$Q(oa#E?z{c{jD-{=f_rp~)c
zo&`Qr^TWB9*^v@rhXbzU)cT&aT>hB+-S~K@G=WWYv@j?}@A1YLGc2IJkX~<1XlB~E
z6BVSE730y5Xb6VR8vrHz-+!~f$vQeZV&sok8=wNV{;BTQmz8X6#s>$veHD;*gCm8S
z01yE$JwD@Y0rQJJ_8+c@0B*#?H2N`y)O8|uRwV`QFq9|>7E=QiKuuIX6ja_XEGuh#
zh}qf6iHyKS0Ce_{CD#0S`SI*QhY2KPb{e2t;2q6gw+TF@th|OyL<nCos@BMt2Ur`)
z9Npa*AmJfECr;9SnxRgFi>O$RAjIR!t~5Rd90}rN6wAEfmkbQH?GpDwnTe+l4F?jE
zhW4aDqyPaYw6xZuD?xmTJ~inm6gTF=ypf}XF_d5w$3LzZ8t;mgacEp3@S$Li2GIuw
zo*=2Q1|xU5W{8G?!F!=y51w(#ldlVq<b#Vd6{U570n}HR=fU0qA<X^zu2TgaKmlVU
z+iLv>gD6EsMcBmvS{ZUcQ6nfQC@#**%7?C@$G(D&h6X%p029FDgj?LcVjaOFWj})s
z^eV|Xs8Lj}*Q5K=x)d`rO`m1Bi;YE0Jmy^aYWCGC@|HJmF!@>CqQ4m<cig`-{42}F
zSK+Th)bv`ax8xUy<-gUv7Z_%7m@1A=%IQ_%OI5ce2ZXPPUwZPRYA$4`zGz3E(b4q+
z?X$1s1=p55M(+r8->dJWxKww#x^g92`15LlB=Oo`-o+wXMuAb=z+eS+I<CyWYm0`b
z6v^v5I>df$F1T@YYeWx8-@f+wi@WM7HG!fLJ*L-e6*Vf-+x$hJY%XaGzA@_HGL^1r
zhm|fsG3epL#oxb??~QLT#?<r>GjI=>IjW=p1%!BRZdI(%kPbOpO$(i-urOZr>g1PD
zouCzgi5U}7wbY0GJ{7!|0OAEg;@)pPpn{4Fmz-ef!Z3Sy&Y}1Ssj%eCDzB+*FI6%1
z{XK^_UWpN`r1;bOVcP1*;Yez6xqTaSE{C)K^0k04#q*EgD5ICOcH6DU1NcauQunWn
zLGO_e04FRIbx|wi#OGgsFaWBdIs;+@cu0>_aV0xnLCi14gaA1}e^GKVJu^N15|lBl
z!C>k*;&+K_c8C@c5J8X&4bAMIKVN@2zD^Ss(7=RUNy%TG_pGL-3#&YmqckkIg@t!`
z?O<mg9}nZJHYQmh{t7WtLc@Zr>d2^$rKQfAnm)<++!G`AHW!;lUSRS2IEbM+sZ{3i
zt~-A{A95K4S6jOeZu2cDaO$4&zdcG7Ho!<v&BiWr#VWY8v_M((>b1%TqB){Flz!N>
z+AC<deDZl4c(;J+b>{E2y<0iCqv>RRWhX{XU_}HYY*$yH`isT<{KKaoLdQZL@ZB%z
zU0a%aOXAeIn})MdvlZ$e5AXMH5OUmIc_V;rtcq@(V@L*Iylc3tvUj*k>|9NGX--na
zZpf81TS6;#sodj4QVYa6Y}+mWltM>w$?xw^qc)}h#Vyp-uu!vyig*8Be2dqi(Dm51
z0QRH1f)@-EZjt*s>`Ys3%{~dWo?wc&8yTLI$#q(3qpFUCd(fQSH^@Q~5IMnf@F3XM
zv~np${n5o<_k=La&B!={Rm8!ABZ6EK)jSxZF-~8G0u2)v9UT_dj7vpApWAK=v?1*F
zi&&?HvBUwVla=Ipv@3kkwr+XnG;41c{n*NXZ$uHML0C3hUtY5locmo97!W#aDMNW;
zeByLTNxq%vxat0+OPp_dTW*BxRPUpc3KlFqy4pH>T2nO1`iYpE@K;*$$swb&nS`tG
zbor_~M_yMvKHdl?er`hct(|XSZC9S>fLG6xq+?xDVmx0w{T6qac&|8>o%AksNqxV5
z`REjS7fb}>o-cD5BIG2l`5yJ&8oLXJv~6to-`$ZH_ESe}y_lSw2{$8>RRLrJy{xyo
z!U;DX_+6;?_x1)m*#G|riUi*(D7eu%Sm>B8kt84a>%r=ZW9vt4t`}h$sqb_eB;Rmc
z`%?TO<OBv!==GV-m|DNQv#}=pY3YY@)?1@;88eYCLj!GP(G#(|7W98~L&rfuh*~y#
z2X6$QyexNY*~qH(#={wRp57mFcC}m2qZN0zrzDGR{)rkCG7W#fr~ffh1^tLMEx{(#
zWk5`iIm60bK!fREpJ!lU!|;dtB2lq;ORs8#$WKoXU+fxo8%<r^j!qO(_4*6Fy8()c
z`N%x90n;|)v<|*c>{kFuP*skV(0p$mdP$cxSHGt#{bZK|AiZ~Q))*Z<R9%2bQJaFt
zsb?*AGS!_rCd_^#BH|5$+)HN#pZmP09S-PG$xUm-8m(ToEG@Qpo}zN`_vNZUs77=f
z*sCap)9@3XXWP#1&QL^&;1-MmlcXZ97A#iGH*Md)qvlEp_t4Mw3?(tK`G>6Q0xes-
z<5tw(ard{=!p!6|D@{@c<v{lYt*{RG7&+dx8gX@L7iV<Ea(nhFDNzxXiLzOA5xnsU
ztkqkG{+sb-rru7@Hql)lz6)N-j)}B$!+=bils*Qg;$uvCtj(5S6+@PCsSD9d)=Mej
zN9|LZo|kkw?YO1T{@8}_k>0|{J2>It=b<qDpo)~M+S}G|vNoAF6cl8%2Qs2Thx<Q*
z&iSwWZn-fv70diLBx?V__N(Wt8KKv_qmuH=dFH`Gdiw40Pam_>{Les#j~UP<xV!0y
z&UYsq)y=)>s0?)@*@)SZD7vbAYh0A9K_fPY?Sov&ggO;M-$NPg4H_ku1m}3$s{{6>
zrw`xKxFOynE%o(IF_TClv%qX$`7FoUbM@sMk#s>P<LajhuXep;CqGi-GicHzc>JM$
zmM*bfQ<eqOi;7Xpt+X6@+sP#A?OYm0c#C^^BG{=7giQs!Z}=5>6P3qX)=Db|ZpBs1
zbhpTR1J}@TZdMyo2BR(J1b1&Z22sh$`<S<VwqDBJcJ6r0Bs_@*S+#bja?ecO$a@>$
zpg3LLvz5Dc=UC=b^Us!V<7UbW8$bRXm;oJEU31sN8^scQQV9jwc0a}*CB85y%ZW1;
zI>EWch*f^&wEn(~y3Ai}zYa|uyUbLzTwk?jT6y+NrIk_S50^d8G;g|b$0nia8=tt&
z@*q;r<kIxxtuW*a*OzK0P98qOc}Hsegj~DM^w+I~kbRnGOz_VjAD=;Xl1wM@Ii?NJ
ze^;BgX6UVkt6B_hnCBrHvdhvx+az-9OLD=OV5I?y=}!a!@r!>Z;j?4-zW%|*E#(N~
z;ei1E*TS2x+KWG%<r*7@nGU!vjDMD%(S9q&PN7dmOTNoCuAsSHag#wMqm}#;kJK5<
zvzE?=;+z!w`^eb0L{d`Jxh7uJ-)9!!L-9uG+Zki(N?Y-(mYhfm+a+PQr~b!li7Inn
zDQPkE#k&Om91BZYzBo^-xa}ej3mMsE5$x~bpF{74Gyz8`uhm6u0q5<D*0tt+5PK!>
ziRNk5=ImOp>EhaU?Qh*Nm#qA6R8Dt3&xCgM3nTd@2_^VY4WIX#@Xh#q@6x{3uJm6!
zIkZwJQiN`kHmZbVyVon5mk&;vUoEg?SzvKHesY?MAeP+cmmc=;P@EGX&e@D`A(VYv
z_LZxsW%s#Ge3Oh)fBH%-G2R2$&5qpnGgh3I;q@;B_W@~I9qmv0<MLk-afU1{cYgCi
zx&R#bRKBh2<_opi!GCoNK2iH(j=zlQys+>U7nd)6f1Q;ylBQ)Hp8At*-ANOCQ8_(3
za;eVoNGYuw?W=<a<LA_uZqqf3{MSW3el?qQqlGc}Ak>vDGQ&+C()t4YmEor4C82&v
zm3((`LO8^cl)hzwz`Ptfgtv3RBm6;Ch%Xs;`0n4o168e?y6-zN@40%pQnC7Z$g0PG
zjZIA#GurLnJz`=JTP%GA<<@jxPxsg7U#tbrlD{Z>yvENt?DzhWMB0UKoiD5>E;<(+
zw%JA5xyeMm;pXOd@7|tDDzZ`vb?t*Mr4#rl=a%1JYcm>l_FkT^4CkQrJC!(nNd5|h
zcx0C!|NCIraP)q!&1-LudZD>1<jnMD^1hm6rG%b}Yq5!pf86FLteIo)C)~H)XHnfh
zUdH0jGW6GJ-L%YP^ON)p3brTAE}EL-uG&sV5APN{5}rjnuw?Z8ww<zsl<%}n@@619
zAETRgQExJAUcNfp^_u(h{E)5LTi<KLI#g4MS5WJ_FM5<X><b)x5MQLEbnm<Q;kNPH
zW62cy4iz`J02u_&4Z<oC!W4@)MoMGT4Dcm^x7`)C+2<PhVMI5h{gM`fxgq3+I1BU!
za31zd7fK>8R9r|%frkm39&lr7%`rWqB#;|<S;%`{bT57V;Gh|Xi*9aG2^*{4*}551
zlar$Cq0pLOhGJ4U{g?7IMh|Xf{pc!dmcs>FL}D_L9fLl+zJ8Sc+qraYR#w)!+S;uF
z-rt`AD}*W(ntM{Vgi)knGJ3<*i^$5roCo_Wj<;Q<E;%YGH#ZJ51!3{|uI$m190n=U
z#Stcqacq+JqsAv|3pu$KUoLxBVC8&r`9BNZV@3)IMzx6>%;_et^2Us0gXiEE+eEW>
z^X5mFfzZE;oWr5*Twd0D**-@_(hu+9k(a1o^9sqREwj7VE-%`|{=0U$Y}|xNV^l@t
zjcR2anN)<2SH-Uwmrr06$S?oc$*CC^J?6)~<V&_5am2r!g`Z4}yK_oTU@xhChcdb9
zL3)?1oYOe$)aV%f^Por|EshYp09)G)t1ieiJf?dQrS|t9d=z&G^c{fTV!@C9Pnz(>
z#sVzU0+Bg(aRml9^12XbOM-~`D)`h7yG(U2;2HW))%*KA^~v)<rJ-`ea>1GcduOQi
zFeL&C2&mLnDg_;#h=1l&ZyQXiz5o>lI)@Sk;rA3_PNOh!T*<Td5J<n64yR7@kOOwS
z&1E{+@nC6&UEgR+lD8pMC6sMg{>;t_g{rI`pcuqFV0Lj4()`zAI+!3D8kWL-DV=A-
zIL$#ipE+x6zh!9q+rIV8WI7qE?p*e*>V4kpx9-2bZlrZ5ZF8e-qH3CD6Ahe<98Wje
zbNAY#Qa1yO2O4P^FJD4x_Czfe3m*A{wF#<wJ~a2mve#~`@12^m$zv_uXIZ1PkD=J$
z`-J78^e)qi3ggy?iZPzivDW25clZ8vO!~VAI<*a8*y!$6{rNL^lb_ym=gP{TijD4@
zaDZ3tShVbp%QguSuCpryR*;N9Bq@8S;GsjL=>|$kc(+DvEec@NGQ=lbOA=cg@yLZM
z6XQaB63D~2w+a&l<UWR2<VAhRg5C=NKL!Ra2<93ap&7!iVG6eJ%*=NVL)B<-F&BW?
z5u7;WZE%Loz(7F?>O_Ly#X}Wa^rF#5EII?ICd76{1X4`Hhuvu9fU)(j!p#VI2#A|(
zY-~rLz=W}TH{{=-8=>tpMjRh-Ugqn%tEfb4Z3-}M2v8&|BqLCQZESd9>OABCG#f~+
zn3Tdy@j^3+o`WCwVZkU6mHwf9ktn9li~SWSVaewalnuTvK_ro^ou3--lOVa4LTreX
z-bdqi3WYUVeVCmcBr$Z-%|Ntkcq6QX7z*I=t{K7~6`OpfAmp&zkx6W~0nyenFGiK8
zn)P8+)Gp#_MTIv&J6L4jqkE1?$3t*ABUw91`YlXFu$le`9DUVpv$PN96S$#=9O5lm
z))?ui{L|9-LRFMf_>3Q1x!XfdDryhHC>+Kme@%q$m@&KK-?9@`Pd^JV9f{|dwpq4|
zSYKFmc{0QH)p@rqzhI1i&C_>mb%U!%hS3NK9y`|3)FkCHt!^v8cQ8QyZ8t!@d-*h-
z^>iAU5W>Uv(FE?JixHkadp`TFP{d@#+<3sBaH>G~o@B?sr!;cWak5t{9!HEy9Dm`y
zLoavd&xH!H>*TyIx}(B3yw<Dy_tuBGFl-+?Wfy`*5@t9yP+>LVC54esqEGwd7J`~{
z(KNuRWk;OE3hFaNKg>IJ0Qx%i4yiA2MSzNokDc%_$jZ*hK<pBpB|HGQZ7!xi(MUt2
zDxg~!2EjU%*EI?22oxfU$)JWJu^y{sWcOevizgQn0o@Fozs9f40M+_6HYVxz=cPKY
zg-Fb6aR#IhHe>UQPXm!8gb$#QrUP*aG$1PiFavSZKZ7Qeo!C-hcU}QYC!lQb%(wmG
zc|5=`030U>YoE+>(MqMXl9Dkoc|s+P#Rg_N!OG8I<p$%;zsje|3_TWLFY#x;c6HtP
zGY0vJ8gDqXl6V5}G+;2MWoYQW@(0KNxzvjz^8<_a2ztRX51Cq6q=R{EWAn-+=NLaf
z=BSuBhO4ELAY1@B1A32LG?HNY>~QYEoaZPdi_v#U3GDkyjFc1Ww5$RIQ3MuIKtL5A
z3*-c_TEEu8v=qw_q^rV5iHI%yfNr?Jq@{KESqKPuz`7yf8nGx&K2MTF;NJndl0O2w
zeJL!)RNq<kUfq#REj);4@V)s>C8gB!G<8Bdo;Qy(GI^Rr&sQ657H3D!wB&YY1#&PX
z-H<<W{0~)LbIU;~zfQIADY-x7$amc(82@W3>qYC=4^gWj#S@zmM<^l=j@SEd&by6I
z#O)LhyvY|e3SZ39i^;h0<awtH_gubIwavX)Ci})FcmEc3)gFT2zFg&LIp4QCCMM><
z0pl=v&Z0ZF^_B1TaEbk%OBQCc;OaEiOOtd`Q}4Jd!(I{_a-h^rxQ-L3BFH4+yMfG<
zprNPtLZXL-g||xuaDjLp-Wp^<eN=7kJ#Z0yvQe)2DUUV#-7ydt0^XURF_3FfkNx{R
zb}*P)fGIpYhshmi9GGZNz@Cq#1ug(G!a>pqA1Z8<Mr(16S5%a-=f&3uXCcl&+!NS|
zW16I|A8jNUDDeqe;vA!5Ka~`CxB-N*uK$Y=C{+lE@ZZJ3fH~xkTgza%nPN$a9SYVU
z4GoxqZHvP=<VAY=8NsO2r%vHv|Mu<MmoFDF-WFv?jGH=dIMT-jjf$QEEk%mbF@ahR
zv#FsAU>-t0fOnzK4sK;oSV8`ULKa^%?7XmGKm>z?J80~N9FR-QCF_Ql4v)~I#vhoL
zf@lh{Ud<4e>DcVJkAFQ(_y88TEdXmnKYu|;yRb#Z`t_ezOE~HS=E4%}q1e;=GpImW
zP0uL<&Jt2Whr_U~#Yp1NAsRc<sfcp`ibH%mFz|o>Zm!SxkI4A>%NLRm6d-aVBM<!S
z_@|)KD=;AGa+X9XhWfXhAX6xc0>RKa-*S6_cdovnF2B_Y@_&vc2k(bX&%2F_S3B;R
z?ydB#?_}MwTlaLQoM3(zw_b~FCI*LDS<SMtq3SOzN17V$)39>NQ?2&%hL`1OwY8`I
zn*1s%&hLNea*O62xoDPgo12@|!F^v+CvEidB^ucMx;U>N$Q_dTu+SW>EYxG~_ku@)
zC~j?^xOD(31H8X4)RQ;XXD$p4*-2cBdHns8W!TM+%1#9`(xruIZTWQ)*KTxn-y5PL
z9gq|!87E_r_+-x(0_D+>BS)Z+=*Tg(7h<#f{u4%VEb?##0Xm6DDz^pxJsg!+L{NP;
zG|(XSiETS0WmO~<Y;Ie(UbD5ur3x_sj$9xUG}8Y5`GeP7B*q9VwI@$VyV}kR)VjfN
zG&)H3!mtm+G?1LQ%Qm%DuvXi>yV$Nz3Oo1VITP2REpg4LPu~Jb%^r%EaZm$K4wytx
zuKoEl`Rf;UPZ!f2A%X<t8Q+Zn>jXBH5CLL<3K*t3Db7i{FUbsSBpiQmj20VB!yN7;
zWsJclz=4=M0jdy$OCF44R2^9CK?uqe1SWE`rL^N1V_5wMJm|m(u(9DK<pK^i_*glJ
zN&rXUAprlmO=&CP^KYd<N+`s|ED{4G<LM<KW&Q{V>j3XhY3*!l3;*xG!J(mKZGL<y
zV8epeN02D+_>Y0h1-T2>jo|a6o`AUE=#e9a`PLVloC*+|jIxC!BfAcP%k7^ZeT_r@
zpF1Y;q`<U|t$>Ay)0s0C!<z?KC+ImRWjxh|{bRn{3~f-RG)rc3v1Yu_F?ORP7#pZ8
zIaC+OJ^0PSXKKto<JHR0yS<(2*Z0~<><{*2*d1i5*=70_*KfwFAB2zQXn7s4M)r0!
z_PiHQ3kS7((wnN(!kd+=&Int7pfh}YliT*$Pr2t5N(Mf$SE%do?gr9NiN)Oe`H8Nm
z7>)1jU#{Vg8Vd^tAU{fy6&v#pjvW^kYm((}lC}B1i|m$ybAy~lLe2C73M_BtNGVXK
zSN{A;OiaXX7BFx8Ror1YCS@xtgQ!7J)ihk0M+7pEI9UIgc+AxvJd3=<$M~laiG)l&
z?d0?EvhIseR|EwGp_fC48leW`dR`aOKt5aJ1d({hmD4eSIEwgss!$c&eASDv#iG<h
zUMMm6^C!^Zm-Qm!6w=zjzvCpSY!#Ew^M+%m1a<^5jTm&?dDSUUkKnU|`~oEWvTIn>
zF_5}B{QQW{qz7zGMFM;eaG5bo46Cn6sOevH@Z*-@1lo;(z#kRSRPYR91w#;69IZ})
zAcuf0{KQyDE32rG6Hn9*qS{3H?}A%XKzfgtkd&8{u<%VN&LQ7J=A@h_)W^`Z?4Y@e
zVbPK@x!uo^kyHC04bo6!Q(>M92_B^R23hF$Vm_dL&&<iu%xHhuM$K^9oCE}Mr@)_l
zq$$0>{~fH#RaGBLXI@vBdJihpmzPZ$-FCH^70~<e*D6ov@237L=5;*gWW-?3+|x^B
zY?N58FHmOA@rRDEgB*o8)Ao!L9_2RcE9n-UdCKN%8>_5KV*Zu-oNwZle)bwiS%l~x
z^pYN(QaiIHoDlJ-tR@yb7ai&!!0Z9U(_v<(+oQMY__->xQqD&^PumJg=Fslvc_*|G
zaJA}#Q31VkoM--q#9I`!QVDV*BIbnyoppd1<D(5w+$-szkgkml%pPfHTc`^=IAG81
zs;@tt)>ida+05)IIL$p%xVRtzLwI{j3%*g*d+TUMW{>J-M5v^|YlL>r65=pyMUdH;
zl|@IO$%fbDw!PPtE0oS;KqERZ3lKQwemP1J1omr;H28qU*`V>ByulzX0PGuDv%;Qz
zG)Pp@=5O!o^TfZ{F9|W^?7Xv!3lx?YdBd|V<xvIJ7+3tngRGJQDqr3E_h>b6<XF9)
z=Q^2s5zk?!O3##Y>cy=jM-2YN`}S4!^%<wNK|of0&(}y0kI&!vd6ZtjXG4mMp*&;;
z>bzkgA#1;&CklW@`Snp@5s_P{D&XgVSO|KXye{M|kP+wkBM=gROZCMID!EW}EqL(4
z>Y+T_LqGa;3Agi@qg4D(<bXq<!4w4P4LGj>iYJrLJ2cGSNIk9??MiAQ`=6GVm!zh?
zZ)p+My(Fg*KZf9I%cnnNL`Rah_|h639pHK<lD;Cg9#tafdGQYy=kBFaGI@#FE4?$N
z8^7eT6Tj=Xeg5o#!ZTE5?W@)!i_R<)`-zFRWMW%j)&H?{-tkzs{Tsh*Arw&vl~5!*
zQK3X4Ns{bQlD)E5S=mWKRtQN*60#GLkc4cKWGj3Bj_ZDY{qsDp?z=l&-|u;T#&Nt4
z5<;fi<pfQ&UK}=;+pqT->Ydb-KkTdYp=NBJuy2*5f<CAg2PeSIA&LTheX76(?cIO6
zt%mW&ji2*l>zN{4J&(!{_nhtt$RSb6kGMKEC+Ufs2DBt8jxLWC=(IdBYbCN}(5|eb
z$DV?KCGg}d@;mkP^w6rq)q+H*#>RUtAFU<X$>s4=M(x8J4cI<P4iW-4HTpg*Rgpl0
zlL@S!J=ElQjnS-SwS$TubpdNfX{>;$??YlZ{80jT4}_=KhiMDGL!W^W3eRql_%8@_
z0EwUYIE2=HzWD})81Of|(Xc~73yf+E=Y59-^oJ1EO&~si$m+O$9cw5YVMAi%2;k<~
zjhhn14P>xn#~*ZCL6nB01f?8mejGvnSp`1WNa_hK{~q5ye-I8s$c8aa!mWa5pP%{Y
zfdi=+IoTA$LQtwV(A(QIY=;*a?GqTvVD1oAjvdzxE9P5d@Vr0^=VZq8{w~famQb81
zh`QwA`Gv+D=c^nym~KazX$rgPuJbTblRK0WW3n*-x|p%Hx~gAdmx|ov(7KtyDp~B1
zg~&lEfY1Wk&<qX8)2&hJ-;<N_T$#h2j6upnRr%<BMDOGYb8~*qy)O(a6Mdqks&tid
z-)UYK2wZ!0T=m9k@vo{<of6rPCdGPx%I8uxw!dGrJUu>?E%mJMzI7qN-GTLHg$i))
zVq%vC4QGHjG2Isj=0{Iy;Xc25>KCM!1IOy)!lSc>VmoY_nZ_!-7N;jtj~?YzT_!DK
zDRWng-h<~ODai{(1mFO0SdGo|^@PB}Xz1PjwL9Bwdw4akW9u$U{{#DvChYl4u)0$E
zVS_q6H1rIL*Y*rx+-u6F(lK^`3iYWv33^N0Crs4-7@MI<+=g5L*AN~dgw_Y5373<T
z!%zovrsH}g1bNgM9$?8=Z|gEc0)nM<Z;@peCO!a-H=DIjF5)Bunf#)Pih!V?CwBX=
zZNj*QMLtU?t^{{P=zyGzNKX8YUk%1tcql-R{6&n2fCM_L9bX|aAnxlq1~+$i)aVGO
z$34byW(8YJtdD^mR!~qNf>(%|!gg~={zc;vUZ{sk3IJxX&7&LP(89N>d2}ZY&F7XD
zBrw7UN9<=Eetp6hirq94o$+~c&{LHwGZ1`lQy-^*?6-XhF%&+?^gui`8%nug1u#!h
z>_7sB4pIW8V?r|!9kg_G{$lgE0^x;_1#KWB)&L>k-zOJe&+qO#z`;*f25A>Y9~g?$
z1OTTBH$jb&6xU9SI*3fTg6=8&jG-{9!b0Bjj3K&4{JdY~=Hg97mH`e-9EU)XFOBPf
z_XWYUWqyTXs`^KhzmQ%U&;Oq2$U#UIAki5aqr~;mjvc5Bko!SIU8J-s!FWUWGCjAg
z!?EN9^^Q;jd=wz&ZYdp>o!MK~PoI(|oe$x}%BMZJyVd!r??cRpNs389i`iT~12)9^
z&TWk{v*lv81Le=3^ISjPyBF9sU?>u7D_e#iTlKTKEbs5J`if-ksUK}q#-ZMaM`I4l
ztLPp387`s|zVl6BzDm_r#>{OFO4Vgb)~^0no6FaRvaKGXV2X|&nJ67R0G5+Q5so=l
zk7e(TFJh_3t4^8m5g32*3q)6J>D;*!C2GKE_&U3~<IPq?oz0!c5;OdRf3Hq+^0r0&
zAyLb<UrgMJJt5@BKue$rASECb=21$@?8|t3SEYJe7>dH)VD?*e8IjmD^k%BR$muA1
zX^%5=$_`kI4J{uVEI#NIkn`lj%xkVYr~Y9hdGF3Wgx>7ie3CWxWot{AU}JgfsO+}q
zbklLe^*v|{(1A%oOAVFYq{{ZdQsVRy#?|<R?hB`(rZTQ2cr;+ms;ZKmI+@;q9H-?f
z*?*r7p{pqDoyHLYsm0k;J9Bg7{@?>f7*3KJF-!fXD1<#q+r9vUz0^E<`EqL;`yA>a
zVkigq?qEzih6bC72RJh`vIzKic@dud>>2l1p!=08yY9)M6%RDUiw*0Fk&#@k7Rto5
zwm+ahNpY#66~xrg(-i-Uh_rG;`pHe75IrH=J9jXNJ8+;X>p-B`em7TFNX34%|8~a?
zdBt<9zpNWuJ)oB%ecZJRPlPl06YcGVz`{!=>||$9gAz~|`U;)gz>46lw-*X?PyoDM
zW+f1=*xQmikPf-ymcZ!dk6$^C1rVtSayTLb&Z3IkTpddp`S}w%)*(hNf*f8{HMIzJ
ze!U9!qMXBf4J(nU*wdp^rl0uqGe<PN%Edr2u{z#k?sq5N)ZL4ANnc!S${%wYGiuY`
zO)tnmB74kb(Z4<gf7{g5p-Y#pCqsJKeY?S7y(<55Y)r>hjprBsU8pSIdXq!3$rT~N
zwf=lAdMRqD=*p}9&^<32-OB+zCfJoY(`#fefac!x<%?d4`dg>$<v6~j(vw;OV82l)
zML3NwzH^Mc-Mr{{>*rAYaQ&;!SJHR%xl4>6Z*=rd&DLMWU^5S38fcoj#+_VjiK^}Y
z0*zBF%Yz|eNol1bNQ&O;x4BMq>m5CLa^D$eU#7?pYcC4-#az6kqT;wUPA>Goqxn2e
zA&>Wl+bo=s;9cVvr`LY9A+a?Y%<FS#s#&26gvtk4Fhom9`nmkg=laQOCzS{lucZ(K
zSs&uvY`#TiWsT{dq0d@@q^B$FJa07a+Wb;XV?oNbRgv~@q=Ow4nb3t072?bQ>WQRM
zLr<?9=PW*O<QO)LRIU7^EzmAEZHR!Z|36;v!<3XNumd5J9ayF$O#N)UX>sL6*`+ss
zdn_~1q?frA(=GkToQp2U_<AYS>iTG2s6J~iv$f`_iNE}FgQWz=Dy|IT+z;Y=fk`Vx
z%9SR=gKef`V{g4YMmlrhcHSSv`|rgmI(H2#y**2NlA-;5w`rA-7Oo~-DO|T@_LM~C
zNXi?AoulWdPP4IE5_zl!J{X`Nt-a&=5zjMjUvkd%k!O4>zoqgQR9|uC^)G?7jcGT#
zygfK<PI;EEmW(Kdcvw&Gkm6r@_e|ZU+!Rx2qA;8KJ`x)GS-scN&$D~sFv6Rat6MCc
z6p=V<;JCiiqb%lt5fqs~^+>$jKDI<xRawVw>vD;AC0)Y31a?bI56@t`VHs+799vl-
z<a)wsH3IY^L?Fj2R}Ok!$<>0fNtz=936=)wZ5&c|MuU~a;sp@0%1VQyF*q?y3x1%P
zg6#?UUEZr)yi9>#)pt{hQD)DyB#v*6XE~n<TC-X6*tb!qy0O=vDU52=ZxpoCi7&Ou
zPTwAJ_seFH_56qxe(D5A7li7lnp%_hi@rPW6RudMaVL}MPimjK%fGliQ6=nWj&A(H
zOy>qq=L35M%eMDd@A*=`aP6}Eaf00Mtg$+Q5Y*(efe0B&GOx8ekIH1+tYmq7Xvj&D
zTIxSKB&)cJ_%o3PJt_+UUyH>}MYv(A?t_P8{<XdvuSA?fLxO|v&AY0FIgyhhxP#oU
zCagF*7}|bJ@E^T06UP(jT(%jx5y3da2Zi}9$k|4lVzZt<f2Cj6S*qLK)+Tc56s~WC
zH>PPG#Y7L2Z;})T#L*#a4=hhu!~WZJi1gf=JCphD-TCw@(AlI!9Vjp46l8hvOzu&N
z?DxU^tX(gBLS0=7x-Rm1KYDVd|4QYE`ba99@=ki|AIy`k-ZXYueO~#|`%AbpY7gw9
zX;=x$%29!$<$y`B=TX_VL-s1)SgtqGK+nB4Ofv1;_w`7c?g6R`^OOR7*AM?3Y_uX-
zt;kD8Tj`4r4U%_`NF~`NZSH%*_8!|uV@5YtE2n!C{*d>i#sqD~-xJ*3RHS16dTZ$6
zyVXW*&d@yeXW?aek~I^E^LoFY9;i#Awk;c#cFCL9Y;+ed8Gsj}MlOn&@w9c{9}Y9M
z6QYpHK6|d#w&O6ke^``ZAE+610rT)3#1Sk)O7otWdb%OgAkU!LXXa#n0Bwa-qRgtv
zqozw9OK<7u*+j)WUTcf9eej6B&zHMYwfg;c;!L8!rTlI)Z^>O&5mW|DY(M{qhJ@x5
zzE;_%A5V%Hb7&A<^im0ZQ(*6Zd9-29^bh&_lwO6H){0%uK^0cdUU@#-(C9iGt~_t?
z(k)q5s+-i6nfuv$JA)IZ7pRz{pV8TY@>UGV)emhk(?H**!x5=LKT^JRWVmf_PRvNQ
zk6bn5qu#w^FRSH+hJ?uLDj{PlDq4a2*suLD{!*k;03(SE|2J_=jR3Oh3JLV}6*lIk
zto}vXLQQU4Tz!}f(~u3cKz)Ez;lf381ZF`{t$cdhas|mlAYhH+n3zguW?Wt{M})<>
zOj}SA78b{uDoi+Oy$(Ly1A~H%@BTL!6O0sOn$o2Iv~7HLiR6(&^<dq47!#s|;~SsT
z&@%Dz*zGqRqmGU};WWJQOzWQ7!Ua9f@^bmkAsvzFhnpBJeR-lv)3S0wYAuzKk&j@t
zyTsaOI{5r;g~>2NiOo|)gn}xXl_h?p(W{0uf5-f}Cry`NfN&gJbMFzH-(<C-apMei
zE-1SYTAtzg+Vi6nPnu<bxMlhT<(MDN4y@|Bu8+Lmfn_+tLGt$OgkIpFJkd%WtN@<4
z9i@QOSb-e3@1TRDBP})cA2fE8leNQkDB`syw)@)?rR>#HA0oS3?&h!kM?duU_gMG7
z^l%3o>CE}ZqP1e1QLmLKH1FjcE@Me=Ua_prH+<}wDq{J<^)(Omkg%^z@Jr3`<JQ)r
zjL&JPpS|f;I8iL(DEX<09gT@{&)K8~pPQ9q|I}?>@R?fuGwa(Y9Xf+|EczH<2XEsC
zxs5lB9^C8%!r6w*xBXHkZ=PKe3YVOiojoE{S$%UtOthT!*uST*FDMjfdko1bolo`l
zuHL9RylEZMz<fQAl#m<Jncq~&k|Q&=a);^ks}pxlqD$rCO3|GyE!frg<bm&;5!80k
zv?W>>;D4(#K}w-Xf$KuNm5z=MmRRUd(C)!lgkiA$>A}Cy1!H9Ld%m@bd-tN)ZN*Rp
zm!A~*?KeV0Gk}5(tTQ@g&Z+xo>-XgECLUq^V|_(&)4z3;r*GG#NHjkEBxU}DYe++G
z<@t4*h7bs=Z{ONH$o$l-W#RAN(&?8^d=%vG{pz(%0NKot$9*CAVKdHJh{Wn{?W*QY
z$kx%=Jl{BGakVgo{qDOI>H2;(`MyZod*JZHA+WagCV;k|MR1OeI<DlOwMjwV3%TDj
z)b7TgX&aLp^9**_WvpM+vSi^j^_Fg7Jbfgsn+TA(#z<!5aDb5-t2H3XfF;9P9~%Xh
z<6Eb%AdPqfwnt=x#Ww9vdUPYJ9X&+&j8eAdd!5H+r1zhtD=jzO?9b71TVLr5c6_U4
znVWl!nfbz3e(^m@^VL*>)OvCsA~GCT<DQ8h$zRet-R<zkzU1CHN`czy5cMH9B{upU
zRC||=eh0#xHi7md#dCM;<By!R)7wq4R2DBa3v3#54r<l(R9Qw%WUNoR91dmkij%W!
zQ!MrKP+8|QQFr$3?A0HlfV{wY;ZLeBp=o0^4Xj%KZ~>Odo5uaGaH<lN734KTLY}kj
zGjr4X<}^FbbbMt|Z~T3l_>r;I$pBNcBZs)TPd($N^qt%{{Yp7i9dt<vwo9;UW4b;!
z2XLM-4j}Y&SVaPR5*j+cyo_-IxIQRG?T#?|)z~%Psot;Pduca@lkngGd;eA4P<yXw
z|9iR1t-X>2p55mR2H@}8+`stsel^9R`duth0i;5$#;!@PC9l>Q)ls?47Ke+cUNOq#
zay>z2H}icyD3EF<TH@hCpd6zUX2Pg%v#-VjKyLbClYxQ#u1?vB_Q};DR@T*H4!LoM
z>Z4ksTHZx<rVW_h^`Rj6hRDlRWvNO?S39<u%Y4q{^1E4H9Hf<FZE0Dk6ExNwO1Cqq
zq`YG1&d*E@9zup}%vU_WQOxt|OtD`%mThz8`{lpFl_EQN`ivFD$w71)#Kg2~o(P=W
z5)%~sg7G3uQG!n(xFN{>FDYTzCB<Xr<n1OTpzZd?F2cZTv7;@i921m04CJryGaKSJ
znvTl?T(JHt`V7xEYafLS4Pd}3JSuH1t%aX^w5)lrE?0fu{3h~Er2A-GoK>duoqp`R
zkNtaZekR?(qK9$ki{<ZmbNxtDW@lp~x?T#qQJXU;DMj8e$b2VxS2_4?dN<>xq*;}n
z4n@zNDQXnv4#}#fnHqENBQOz`lb2YiejL;KN-fSL>!hM`?)Ggj?KoYBe;-TBK{_4q
zsd_1Bc<xa2|I~J><wITbEgddWJewzIg^l}y&jjI6uydvX;D)%Z9#Sj?j$}W0fxXqR
z98lj+j6b}eKB)2LecBM1D%%Dd({;}>KJS_&K~nnS+N?ElJh~=xwFDAQQyQ|NytgR&
zX;;$QOhwZK-T~rOSUmV%VzmePInX<og96D&k=7h~H)q%mlpu3+YN5naYiVj(IFQAA
ztT_&V^aF!%?eN2&gyntFZ>D~cF@R9ExEN5hO~sh2wKb6gvBkS%x(5S3^bRmodAf1S
z=&IH~x=oppN2l9(ut1W}%3yandFWGx-+A3OdC{HIuYQ!~FDadPWG(M&@{~1hnCwBc
zdBjMlVmdBa7f3<1@0u6OtgSE7Q@Jkp<FTo$KQnVMKd9DiIPY=WtMRML5={vLlq&oD
zD;aJN=3H4<u0Fk^Bwg>XUt5okb#XBWVz!#!6`p_mHff!d^t8+HxQz2#CEvy6hWhp$
zOso!bO8?RSu1l&X{t>C>(V4BR?ae?YS5?&@G1HlwdII!zTiflFeP@x|c1%zZIjQN#
z;ZrGk`?lJrXL<>_M7SVvp0YACW6M_7KV#JmG{N`p<lETh17;Hv5|X%65j`|EPeO*3
zr+Cw_4y_Gdv{_ax>mO)up9h$6tE~c}F1Q(aPm4=R8oYN>=8fJQ*M9v8x$32h<Bd1p
z5Esr*L(yDgV~W{L@!@f-#q{;}C#G`@dlSVVyu090NWWrUlmw5I;}}ijuU@U7TrDWp
zT<+eHIBg@a*(uAix|iVVd*I981V8!9=KWt2f_HR3z13VM;Ige*78^lzWo9UMeCUgg
z-Fnvk<)hAJ`ng*1%?_j_%_C8EB_b;aHL?ZsE3~AApH(^BQtz2uks1+;UAIn|lv@7T
z%^D%TrSM@Q&}rIbFjeKXeD$7WG&e@#Y&yE@{%03VBPmqBJfNU>bS+2dmf6zE965W|
zD}AntWO+OL!^8ozFn_Yld?KsgoYg_IpB3BTio^{uC>iMIUwtPIGR4Fk7w9C|nlV$G
zL+>rqp%C2&U+DsVe4Hm8$SV)VHdVoE=Cd`Q(h$kzGv9myVrYsJlJTn0C1Nv0MbF`@
z`_oQ}KB&-T)*wl347&{apbm>7ZNb;4u^0kN8lMn1_5I~prB>(w;WS8SMj#tEH5}Cl
z4XvE9f<F@fJRhmaMa9MNg^Zbzd$M}chT%T~h=F?&z7Irms%B!e2f510X!~9(N!K%s
z<noM~@Snj9r7Ku9)_R{EL@U=nGcz-9-iVg!(KFDr(#+KS-7bANtoz;KF4|m()CvV$
z<%f=RPdjT5v~5DjgoHJNd4BkZE@s?kU_#QDW3FOxso5ifFBTHenY0-PQ7=<5gw@}(
zJN|WGpz>Ce?B^yKm)T@`LJ1k!vrNUPn8Tc$uTP)2yEO5jBah{e4o5Y~$!BQ)opqhV
zp9fy1DD;&7rR|w7&0#e4W-L+$6Hl~#-vVgQL!L3!7hi7@UehQ_elkokA+nW(%KvF?
zf*OfX-Xi76XXu~m)Ej@3_pFQ61X1KAwIp2?ppa(Wug@X%I;&{$XWDtD>-6c*<V3}9
zetahE6W;ePc5aM>&~)xenc~W}l5NNBqFZLgw`3EjKQS5jSEKX9$9?oDEIgzHbWTKf
zB3`1~DPEo3$W6uK2)!rw(W9T;M6e_uYe|Co5}Fvlb>cJ><a=Y|1AaAFy?tqFYBv`L
zECa{_00JPMasL&iG~|I54`#HY@vwqo5Xuq?)fj+a5Okt5JIM#FC*0xqd$8%mc5-D~
zEC{+F`XHFwF$~5;3R(}4o{{yMtqF(PUb@Vpq8J!sT~A@5V<&}_@ak$`FhwxRx;BQ-
z7{^Djf{A1TPH8<MSfMdxvwJ&$tv!d+nD~yNE@&in2Y<vX-P_CVSA%i_`^1<hPckzy
zYIdR}K;$ISLN4&I>DzS?sonqZ#b9L#Bn}3|aHC~t?59_P&IvOyLbb@tQz3OGAe}*U
zhMfckv4SjkjPJ=|!J4VgkI4$$G&@re=d5<|;s+yPe8xx<#4=%F0lBF-P=46c-hYPH
zG+UEq><}jDuSq1kIm~y}Bd$m;j_3}(Wo9NRv1j&&h;_H9Ep~Dqz3jC`MKsgY50)R$
zK3C|UsbG@pmg`=3n;i>r%yrJ$^QL~TriWj+c6~;M^0st!q(mOeZ0EzKQ3!TMM@v1H
zzGzqW1zp@vmXTR}eR(41aF*I)&ve9M+vJwSreUS3VOPj%XG}5NBBvf$FFkK8`BmWd
znSpI_aX;b3!GpXu(=;?ZEE0d$GX`G;YmZor`<%0FOPQ78dw$O+v-Fwd1BeLjPJGAe
z8u`Km0#+(S$=aX2VmNt0V1=N-rvLpSo{yGEhSLjQAzeT`!XeinUEXLsX5bSb*o!zx
zT)`HL{Kv8vY}lAR6N4UxXqJWlm#N1pqzBwS5s3zMUaC5d=*ZJcKcJCZbl*g0*W1$r
zDIj*~?_uj80zPhvuEL%Qci->7uCQHVSp}^P)<-#7xo}di1H}vFtDdf|N>)2DAPSy%
z3&0Ja&9NwYdVwbyJ5wX0p^D`JSPoGWV@N&?m-@q)7<|DzF&DvGQ02umzpva4=DC4)
z)==gAoL_~mN3D1TP?&TiHegR`ZvF{588AD}RX~Sx$cjJ=Iutr`1mp#DVEXT@x+glS
zW-lYQ8k)`hGS0w0U~_6v>TvkvNjI3P5zvW8HluwUpp#rJOg;!iqd7680wYW;+JMKx
zPGfF$1G6_6tMIcu2gzt_bMt08w_Jht1`h2<7kK`I`mcDN@vC|9>Xlxl=c?@1Uk14G
z+myIQ$HtHk7_9IpDyqP^78|>70|PU&v$Aa|r~LmC9a_8;*nmTO+FQ1qusR>0^2Bv8
z{_>}p{$}*+;$JDOBQEK)m4E3F?f2b3Dg)<;38S6kef!3P(X3<`;`<k@9Jh+{3z28F
zVjLjBJe!!F5<lg-Vmv4#^{X`b!`a4(j@UgkVmFnn9}LXpFZj5%Rea@VT|dEQtti+d
z-pg=`<2Sca&2RE9wXuPbAg*^R8MkOz-3RRVSNGmpnrfHc^LBkW|98lfU9a;ZT{t=!
z45!}5^*VM?F2-(A%w-$>Ts8*Z2?>kPPwo(ygylW50czB&d>>3qkn33tzbbHg(4<J)
zejK(-uT>0J#O!+;d=pSGkVt~gz+<-J1oG>#F(~G!I7B~)b;K6dtBk=4!13`VyB@?M
z2aog|XSqQ>jEw6L^5H0gG!o-a(4w6dCpz#)SPeZzjvUE`rVGh+nVEr2qwk7~q0adq
z#Yp1BiT^y27~LaP05Jlbk<eZO+wijeI#q;Qz@{fOZpjF#Lj(?XQV@zQz$p#Zm9nbp
zM(^O3nP@z56yDjXMZms|DqhtayI|-YLE%R*$$zgT7FWbL7NjpD{tbC8__oHz#;zM0
z`XDwD3hk`dz>sCNgD3}*1E$1a0U&uZ5zBp{SlRWdLQEL2>jhSZlmMP4Xcd@d0bhr;
z8k!fxgCJWK4pA(E0Vt&pSA@*&TYvv%;N7#vtcL_y5Wc&Qt{(1n26k7FP2fHUXaL~b
znCk|?VPRG_Hbknr$C8z{_K#1W9?aWO{;%B9Q-+eRx>^pO7Iugj*8Fa{Rk3O|m2@Nk
znj35x`ubjl7}Y7*9Xe7Xlf7RuZ|c>L8-0d?&m58yO!W8hW{r^0i<w=i(vo@oW0r*M
zS!${=9%jh|p<~UKs&BV@bm}5y-<4j;_KsU={q0qM*zvSEr%>dw)OXhx&x(yMk+10f
zvyD%(%j@EsO`LxQ=={Clrsul)`iPpmL$9=d-;s|ad>@`PHL+V*UTqM`T)%Rbx3*ZR
z==oacqvIFXL+}3>ns@U%c-{XXgb&%8Y`b>JAB?j3Lyo;W;B4gbU!e%arrYLQOzrU3
z$wh3-(j(7+IfnSwAEl02>il655tYUsQ0I^Q#RHJ38c(FMKmzo!u8x9|5@!LTwedXR
z_WREl`*VDJhs*>Pu#TmASc+rqc<b|H;C8Slf}9T<cI@R6nx7;l>KPb7UJJJkiZeti
z86ib4UTwR!ZcnfR2?@!;s0R%rqhL>%nIX&@j~op-DXKuc1S{Xq^6bvlE=Yq`5|AaZ
zFcCs5B7(q{4>fd<j>yU)Mo+)ev$VXt55TZ%*Fa!`%2kT$;O=0YzbK+`lJV?LRewQL
zEPefo9usdEcE?bOV#3~G(e(NASMvqTBv3x+k^aFEg?tt>X!HQcfQAnE3*(>{3Dy4*
zeetqDfv3*zAD#jkBfc-_$i9C^pcVKf{LB{>6vzY4mM%`6qh4l&bz|rvWTB7?F1p9m
zd}ZQ{h(E3CM0I1EgfQsUrJ-|lKd0oD#8N=Vt{nZDE&J1DN1dnh`m77G=k_MBw+%JN
z&G}D6`{6zQ`BPwg`~yTqE`z$)Vm8LS_FIQ5z6q$}HMvyIy*0C5?!gww9wD)R^4f`9
zY6{Nf^EJE_!nMbF1zUdM=^t}A4EGo%Rip=9UgOQ}pP_3^eD2iz-_{=N+*0kzia5r_
zzYQJk)H|yKmo{ge5@nmF9^JvRRqEESKVOoGq4a=G0tJPm6a>1gtlQH)MZ^UzXb=*|
z0LB602`WBBveO5_EwG7}=Ve=;V1Xb4xU~gA<REf_Jv@-<IfrF7m{$;BpgsrN!blkF
z=IkjQK^6pmZtu_)oExu!02e>6|83teHrzu~ham|hgPKS0N^#Ipn!a_iqtwW%Jsouc
zM(_XR5=bBe*0IJ2lN160P><+4V5H%3H4=`)2aJ*2WV<_TB4<)sNB$1!BC3dqi|aT`
zs1mJ8dfQNAtphq`bP=aqLGZ&<X;Yk_$_q0iXJpXXRD>MDDdBhjJ~EY?&44X}z$c=!
z<m8+(9$?N2U#wsnMqnqZoq!)lVAZoyEep#!AB!v8eWCDk-50o$(}BnJ+__C-<L4PF
z6>xD5-jKzzuBa$mia(z&B`llss{XOg*&hcyGM>M&cx~Y_Y7<c4<5+$q@iyH^#EqFI
zk5EXu`ufC_mA}UtgfIrz8%1AB6&_!|!SGirXr)f^z0!M~%0d3|<57RyI~C-bIKL`X
zx*%G^6uO0;BBVhri|p7{x&xxu67BaME`{2!bQw?aC9*5mm1QOxgqEK-?IaM^#J#d~
zF6-|xJUC*->BO%##5Rqn^0TSnaRLh_5$~LcvY1%l0AOHKT>SQJB9Jeru$()KICetE
z@!)|J^qh%KKCZ4mvR@4{{%7>Sn}WUz3M`KI?|rttQ5h(0{Q-I}J9|e<BOv+NU6UZf
z;dYF=a0;#ze9So0&#X_0WoWE|R|Qp1U!NX<P`;C)Y?CO{RMFQ@YA2w#deV3k{cx(f
zd67=k1&n+kz!=uWUo|W>gqyCyKo(<pTqg+2vE1#4RBb#00N9q4NTsS%Qw{yJ^Z8c;
zhYzTvulZV07^A$N(ij~chCw0j$&<huBgnEbzDHOAVuSum#DO>htvUANWqu9Q<Kx|Z
zeH^%$kl%LOYx=)jBrJ{W$P$`6dwM3Or}34cL>iK_j#s6WXN+yC=s!#IUj`+ko-z(h
zOG^Rz+cZ0OCW@T<Go$w2PmO;6gq4NH%UdtPUS}K79lzeRAY=Dtd+N#5m(DL*=O=4Z
z<8IY-+6|Ds+ysaj_{pr26|`Mp$ZT>MJP^iOx4dh{o#AOizl#KKqK&NAtMRz{KCx>z
z8Ajf_OD^*w**mHB0IJ5!w)+08OZmk~XZkV5{2(=aSz#mK@~#qvU-(Ok_Y69RIS~lV
zis!p7u<ppxV+%`=l^?%sOIJQmwE1Y|K-{}Hng<xneF|CvSTraeiYqI<5uJ5HoPg&<
zLE$6bZXgE%%m%g}t(!~_)o(W3{Aha3&0l~#>%CEupP!FUOW`0AJ9wjQIcN|K_3iuj
z$4N>0T3VE4zgtseQ<}}-k~1uI7=>JBczzYSc7A4PW*`A&2}LNM+o@!P(zcHS`w1Xq
zpyQ*6mJjhUF&&+q=z`#>!F!1CYuwuhs6Ut#;19eeK>*wVYBmlI&~C5^1^LF#(b4bF
zVGL{%F>H;Bx`H|H#)>^>WLH-gA0zdUseghnt}r}5Q2e92pLCLj7KWMTj<^mK?rv_Y
zD9T|>hj|LRd!sQf`1gMN_<_g$)hof0E#y^qzqu7!Sc`b{&9-kfsz|X$)FXm}JkR(5
z4q9g-&-lE<0y_L*O6jB-Fm5o$ypBa8dWaaX&yrDbEnph40YTA@fMuO~wN#vF(d_oU
zUIMWX;wgi|`fYj(Z~2Gm8RzjQcUA|6@A7YEh?{LrRA|&fY-!_@=o`5=Xle<uCc2y^
ze;w>E+Q(kGdKJE;WR&d2!fb?kvpqLOubQT79Ak1_xkNJ!(7K7skK-=-GhLlu7Glmv
z#D|ZVNGUK!`)b7VecA-yMJznLwCPDf?T5G#>4yp?pIT#y`7<e8-U8N^{CrN8+n#JS
z6lZj;L*7l_>SZ{=DcLQ-oOrsecK2rzSGpCI#A7WIOP^-3OvRD|V=y?hvhqC@73(D$
zM-Y4n3ZQA^Y3ED9-H;m9dY^$59MN-|Ym4Ze;8PeJ^nrAYv}X1v2(9Gg8#Xfl(I7UN
z7g>T04WRzO(<N1K8H(}9$jE-1po*~9+E(bKz`|7K(ZK%!&>eR?Di;*jP?{uiI^nrR
zU4UP}!C>OV7j?nzq6e%MC`Y*&h4-qOm;g8U;6F1F#y!`vHSJy|q9laN6hK&>-KbHC
z`ySi~;%vZehSohr*@}A&F9N7*U?AsoD5i@5-rC=vgl*UA1~Lobo&!)D?v86YT6<Vo
z!I;4-gx(YRTP1Ifr?f)ijE1pgo)I$u{Ocd<>p@7vvYbEWVygOHJia$Yho2CcuXpZb
z_uH`21i*-g<Va{w$;pwpjr}|-aXQM{k-tQ&O_(=}!ojH4vDSDos?a)V>yrng_Co7#
z(Q$NTN1k>8X)+JecS1uCF;Zi)bw?7P3^*sa&lJ<a|1?U#yQGt=_58wI1+@u*yCe|e
zOlZoA@W%IuZ(Y3{z{}IuXqMgl`%?=`S6Af6f2P-|@-NL_bUgIFR7aFR5Z2y#?BA35
zq_NAzNl*T`Co5OKy!67A<XL!Y?DIaHGDdGn3DrD({`&we1LzW$J{{$GqoKHNIcw{Q
zKv7zyrqcDidjG=xw{`dAB1OaMk?|ej2PL+2gxw+cs9yeEK6h_KN=(crION0Wjn}hD
z0c8Es`uaVWWplHxUI;v})*1B9q>X9K@`Z#Y?K;i=Y6NKIaplSOxw?Lo+TE0Ob44!F
zpNxJV|E22D9$5mxuSQVk?H@!mLBDjDjeyUxyfPm7@OUmIy0R{BSM25bFZ-wlA2FUH
zkhufS?wj^x7%TC=x9NjXPO(+@&*|w3*e|j*EfD^8DjA*`f^YLy?q@110y$(aK6qF$
zVS@V)cc@vR@reXH>M~g((yL~uoL*7k<Adn|d~404H&73ehskkkS9+d&H7+fK5zf@)
zBy3$ROmuAFOX#QQ85m%BhW`T4tM>7s`-B!zV_bS@YQ9?(!NOQ$RQ=frrRc`YpDxH1
z?MlgT2clk=8jW()Le>)ACXkRI%j@soAMq6~iGacI;9z_Asq)RG-Y(g%mdQlL7OZtU
zcLr>K!9a_a7BEgcTNn&j6h#Qtt7d3GGfY#3<}hoRl@@ldxX6S5Gtmn@%glt|N36S>
zN|~qb-{_UAnSH4_{{8f~ZZEq(^m?+I=PvbY7w4@vfApYTNSXBBO8Z4C$QCm^vQ*4-
zEuZpdc*2=>9<pZ9XGMfu3jb1_rOE8Pyq2b>S|f2pk2KWTE2N2NQ^$Pn`yq9<ZB>v)
z@0Z0Y;g>JvTQZ4r60z@FORg%Ny7SflS8hD@FUn_yeO`FW`f)L?-BeN<5o?`uE0_68
zS$@~u{cU&m&wBT3Z>xF*!T);Yc=I*e`^WkxPoJckV8G_U;q|wmJH;}DeN^Ad7ZRA{
zzG^>yos*jj>s9&U(p=ugVi!Wa9UT6FfCevCzfDz>kvf{DQHRn#+0_q_$Y0DrFsv|O
zT1$dKUOF}u^g)j2xSmh$^U}UoV}v74qSR){8*S}{1=)SHus5oIEsFXHTk`nPk?&pk
z!3|)kd2UVDmG-~h5&~W?LgF{Pelk=Q1LL%4RNdZF3k^Y8+)C7gJzW2Ku0UDYMVq?I
z<lf7iJ%<l}W4OKLb?yr#%bhpBj)?Vy;dSgw))Qn~DdZ41t3<8Mcslvk_d1KOInG5t
zeB@xD#kUa{<Pj^h*!||PD7O*aw|$*mk-x@NK3`-Oc|3k+;7%UPE-am~KF@s^qjaF+
z)E@og0W+1Y%4f$3jF&$tVY--_S~E43e*XM1F0Ws$HzQ2tQfrK4yxuR5L{6+|dW+lt
z2I2g&Y6o@2`TQbt8AWO5Ycp#ZGpx)69*($iS{90XX8ZUj$O<>=71tSPX)Ud+%5!xe
zDEz#%@b5nbOT%CViCt)Q#3JOk&n-tTGBGh>m2m7S6QVLX&}<2}J*fK$G%iiudvC9y
zja8SDaAV0{OG~8z_nbuE+T2is6K-#Pif-sjXx@E0ZWo#+?Mq=0N17Z#^@pk?Yz?N;
zNY2v}v$p#0zO2s_`Q&z56w3F$>mV}P_wIcoe5?FjjSX!=|C8e_*W)!wUz&sjHPe$!
zZ2n{faANndI6_A2P0?Go_UGo?a!0AVsFQB6i0rijfnAcjn};}=Pifh7+6W*c5CX1T
z=`qwfq1ScL7P&2S0i>Fz;znud&ur+5Jd|jtw|d2D;A(8eH#;el8XWW2b>ojK;kvz-
z=v8w6^&P}%EpfS_C*(5{enRu*FmaX<Tsq&JH(<~|nIHRm^x~Mpr5aN{l~sY9e)rPJ
ze;#hLi!UrPJ^T*K4|OYCZ*A;Abi?i)pp$!>K3b7IZu_FjaIinuIQqxmumxe0mpP+k
z&Yy(DJ}qc@85?@{8(!M7;r?}|UqpdSSS_R!7$>&fW22k@zMey2W>iq$<oz<AD?5k1
z)Gl@Qdt)m6CA_NZT~CXsCK(`v9muxYr5?ZIY}>PUr^9H~UaeK^jP+z-{)gZkB6XkO
zzXQq#v~kz~ECFop_`3w5cFkjh&OKavsU1Gu%*;7?PW7Oehw=cq((LB&D-QMaS0ZJ{
z3XMz5@?@np<8t`Kcf8jAf;oTT?W>4wO;9+!y86g#y@zLat>EAd6~8Bna|iYKlMrHg
zR;%D*`RK+IvFY1s{S>ZYbiV7t%>uwZa5xd_51pqcmp^?v31n9>n4bz;%@~76?hY6g
zorN9-8SmzIv@S2lZ~gqv+Thr{6+}F?GN;(HD<upF2i;z}rcR7cT6B698GQ*9OYk{<
z>+a-`9fZ6h@{Ej}%)9}={pYx$^k(0^oAmY`>^l7)K9p&tZ2v0!Z@}Z4IO%j_2_Ij*
z+p^Y+=uR)a75mVQx%6RQkD$!v&3Y=X@+;S`uYNiN0gCC+8Ux`|E7zloI|;r4_h@gg
zH#_G#oqM0^RkS|P=+$6ROiFlk`Y_Lwf6V73^{2iXbQ~j(Yu^<Wp-ePvZaiX8>FMdX
zGSkyh?&V=>ne+61mcqY-(F)2V(tQ$NcU1e)Cx?(R1Vxlx9umk`hzz6ao6(=_^b*C|
zjj5EE$N>W8n~|3^<|4&d6oK$1Nx;GJP@jEIc#XW5S!PM)_kUI&3T@SV93Sl^fPKlu
z;)$uK#ksJ}lskF$YYk-LHszk;GmHtBVjfn{{Y#5begse)<sO<s_NbU&QOwPe&co@m
zn$F3yQa<lDosy+m>Erve352;$Cn`(Nt6e3O@oYKYPjXbdFYD`rDBbwwi{P<l{ell;
z3AP$L{O!B9wuk&IQXls9=8Opc*=rcm{ori+SEl*ZBY%#mKYiS7-L3z*g*Eg3=mEls
ztzCO06IK_yE)~b{nYD5f<d=ts_W%RKMI>a6fXqgmK0~2G>G$+x`$+rc=$U7~SygTG
zXR=ayoM+7$OzJm}t=fv0)4p8Ny9}*G5Cs>@a*B^=%YwshBSw8;ssj|aGSb&2qWSw)
zFkRan$_~bVwT#+=_*0+FoS%Q%@@8zT#rbTm_GRuEsNCN?zSJ%w;H*Wb6*p~0!^!oT
zLRJ>qJ<^HIebYPT`Ts0!D%(V1`razLo!DIOz0k%?X<DvP38;SSnVhUg)K;GwEDBrx
zDz7Sio*XGM*jA~O+BToRQgr7}2lIzaDR%obZ-+bL)i(zeJz_I^<q=v%LOd^Lu+M~H
zVQuYYcj4(Xt2{?|{M{OEoOxeXw7R-`m*hf|o1w!I7wywVR^9(|*=DT0yv=m?vI3dQ
z=YAJAzM-$azVQkZw~dX5G2?k}M8Yc-C!ZQtv-~CMkUl^bY!UK@zW(5mq!_y&VDngl
zWr>B;_RPSUZy&gyk#$d;Xcy)Yq~;9$9?rn4m>#7nS-E2JR$Z!+K@+$JyFU_to2W^7
zDU^1pH&lG;YzW|D&#nKQdND?MLo;zLcrVq@eGj0zb0eN1_DZ>0P^cRVzh53mVBJ;o
z-qiMC<r(lw$Z{7myEo=8EMK@DN<knDUiYdhb8yMe9IiX^n=kF2xfMshEqejY!pj<-
zE8EtRy6Ek|W9;wgS!<DLpOyOF8?0s7|90HMrMT0^#VV;t;!51!4|gxQSBBgR0fIqy
zG}kGuIn+3LX6ND1nUu%dOqad95LWzqs+*HR_SCK$ym#4x*q_LrFske~u38`1daQNc
zvQmnR^sCs8Oo?5RTPvLsiZH8`oQ4m~*z?Ho<J-Rzw(A?1Fy9vy`J1;irK@}Gu7rhc
z$Ts4G^H^x*=*?}L2c}1R!?l{5uC_%gm8ycc_@Y_Pn(|BI-$5(UcyQly;o=@LdYQsC
zZS&|oKvUrABjTnly<hd<d{TG5Ea&2iLZ?R{hkE#P-utZfZ$^JTu;(e1DAdsir~FNk
zJXAm(dcyGo?@v)_CEq?_q0=fnkI*{mmpZt0izb(?uTWkVmpCH9Ca^<lN-{|1E{Ekm
z<;8D>)3^P8$a`2Wu`IAGyzqFZ){qzemYOdh|7TMB;9z9!Fcd9Vv=d%v9u2A`VJ+K#
z2{tl>X+4R&h7_6rQokBdGNhBdF9l(*YG<qFB%M@a1oi?zf<mV7A_prDezUj7G8DhS
z`@?TjlZ&$<Gqcr75}V*~MHB;Mu;p{ui4|z0Q^EiYzIymrVaDU&fY}8$DWMw%|G{NY
zt#wZYOR0+QrNf>HUzLy(R>m*@jXJDKG{eZ8f7~_9PFCckCZ+%SE(8X{5QH8DT8|S0
z4{j8F-nMbidG$C&=Ct`EVY9U_YRk$lx#qkH<L2#c`4_7uy2R)CfoOZ!C3WjUY1eCQ
zL5xnZoZLa{=rNvgfg!T&-=zA{V@TFWk?x=+xSIB`1Bf6-&Gi1O<R@pqq&MxnDy6Cv
zH4cd_^d6X3m2J9eZ{+Zpo89HP`?I1juVTzoFshgGIU^v<ctY!l$@T+efyaMQ;5D`D
zw2xei`NNYE<N5pivUI<9PtsY2o87S#y0dpN(6d8C0oFqwCV*vcZiU`o@Wz{u-I!$P
zl{%n}G=nwjwXr%nP7Mtcakc~0uv=qC6_^u@yjAe-Fy^-EE3tQ)9>zxmGq)g18M;Y=
zZ{tmABnmsWo>t=S)41{g_);xm63-V%#Q|L{?8Xlk&US3NwFQyRjqm})9AJEibq_hI
zF(yO!o8dAA1pKQ-5tcm|{$Hac5)c5dM&JOSnN*TmS7#?BG3N{a7=t%7AwVGx+dYnr
z#V!lMlxR#w9d?lo{f7gr$3m(T+r!aczvfmyj<?VDjl8Qe%<t+2JpIu%w^z)^B8GX~
zzv*Xs?t2w@=2A+}^R4H9n1b`h8ntDTxE+<~mq`c&9E@0(&5vECq!ME}_D|>Cmxku)
z76Iw;MfBL$T!Nyk>GYq7PM02Oy;MFZ`^#5nPcB9-TAz9{rf7!ccm(5SHlLYqpZAhW
zV~<TnXfo_$N{T%xo}%t(pIzyU3r|W*e}`tNRW_gRY02e}f-dKF)EC+L52V?~6nCmj
zPG&3;e8(~gm!(U(ihQW=W4Z~s5%e-Fp|Ix&2?zl1V2(*c`~SmbAcc$Ru+Xpau1HAe
zMIY(xj4-Fr@Nm3b(CP9sPhiG@js&Y>s3pK_0Au|{J7A_x&_z%&aH^`R>LJz`vakYe
z2=g(UIvDlITpWS)h=4{|!_7DUL3&W9ZTd_l-8Is?)>++JV#zCMzg*v*X+7~az&(_i
zzeT9!gAgs(yOLwCosQ7!vS3b;C6ry)ug@nMA0M{<rEoT~YiGZPGFw2>pkZSIc1p`F
z3Ck^|%MW5%qZ@gsP0Y>B!TLhLP$E#97c)5M8^)dBL&lt!CA6crmzJQGH4ie!-BLX~
z1sL4nO_1H*a71tvT*+vlvNfT4(8{@%--U+)qdw8gNjkaC(n;W({0Et(tDSN#YZ`@6
z2!oC~6Re3I-o|Et`TVNq8R&S9UgKsY5bkqJC$&sFudl4&)y0C{xopwBqG=Q>?b<Rp
zi*hR}k~WI-^BEfKVOIL>^Yaa)Bi&Y+ZRSXF;mB_v2b&XggvWRXuqF$w`!MqNqlrkw
z2&OE<c6OzGaF%1C!i=b+bZitZW?(t2mIWMHRy$m+i}^mA0vIMEkO*xf0sL(iH11JR
zP|}i;HKaPF2aSg{5aJ?`=LdTz0fHp8EZy8rylGgxVGKDObYCs&YPP1Hkjtacw~-G)
zAcEQdx+b$a|JtVugD+l88kQV8awRsFVZTggmBIU^d(VTi?9_G2-j!6980ZgLPrWUp
z%HUW_F_W*h-Jp<-__Mf1M&&U7FXGJVO%02ev2u2s=L0m4dMF2Hrkz!B3E7ff&z~IW
zy!=o5m5pWiOU3$_#l0RA5{svJBhT75Gsxf6yO7N2b+_kAp8v6ouP-SGLnLHWCVCc$
zQF-)G$B>cj7rXtr{tt`m9z7we?XBcKz4NydHf#JnxZ?ksKeHp<!<NviC93|W%<V*E
zO{zMFsL-k8J5M&2+CQZ6zqjlX(l|s;00UxhP*zIHyx4G#?hy6a{4OpjJA%BoGINgR
zQF{(Us6w#uL}w1snYOm}$`8{>1Qz0iIGNNEI{7%2pGd(%o}@9Wi5Moxkqx0(XMkuA
z_wuDnJ8`EVMS+<m^qRi@X<=cUmO!LKRYE~3kA&@RD}2sS8to0lcsqE6F(eH)3Y^3}
z1*S^Kvsz`tGytl1{*Xs}czLj}1_%vEDWjVEuufy0O^lGLwm${M2x0&U$m7FV0TvyY
zRccuYVz(jXxp?EoJ~!UThI3cMVM52)5tbZ`njuW8Gr@`kum(&QF|dMw2mkG;3y)!b
zXJx%z+zZ(nxE-Z>xGS(Tf!OU}lsV2>*oko>WM<Zzi;M21!!zSH|J%N_4@*WwT>$M;
zrU(848WkWKzFSD7v|>7mv?c8E`2_@^;RhEO{&zV0%?fX%w_)svh;0OXaWq^zdQC}5
z3Heyq+;X}OkvOESczR<gfVGa$K;qvyk2+I=stn#SY;n$}5(uSw$w^80fzDx#gq5#N
zUrAfT*nKjmTen70<#KRwZI8)ryS+SLNry527XGE@8ptV9dj9-V{WneBggav`YDJ&x
zo}Q>Hwwza=FQb_4+2xV*&iI_3ROmoW+NIFF>YPa*Ox5{6YSxpmhu1^LiP^V~;AZ3*
zX^*hnqPKD08wIr%JaT(Vyq9iTZkxrfIxUY!s>mh}pGdcQ7N&N-&dTk5)#MTnkJpFj
z22~L$lA{8Qgl+!7^!-K-_sFYhwe_CesG$_@WUqYtR`Xz#_=yvaQcp5eZin5vGjtRv
z1?6Dr6W80mnFlY>R|vSZ`&(=izTTec?S4IP*IP+$D<4vI=ps$@lfRB<<*zJY0$M!a
zE&vmr?-cQuRaUz)3wY_FbsFmGuo=4{{>NspGU*im?qDJZfA{YD#&HPN=(fU5XjX_I
z6Hu-C+{TiK85c8YfF8>dHz}=2GO?NsB)&C9Uyw=;@y5cxe``=7VF?SR3Dj=baljSK
z1<R(9Fbv)R2CXel!l*CL2<==|)i&mMkWm~xI`Q)gBD%2fF4g1Y;*u?Y@C5p#m>3EI
z9(SCHc%p#mf`uJh4jjP%el1|Ffq^#u3S9rtNqsaaNJ%k7U=%!vPmUXMGBVoXVT784
zm^A>eF099RGNH;s8U@zNc%^^`!R|^Q<uL~M7!V^4(A9MXo??ji@B(1RbcH!QH1ujt
z2kHr+ap3Of0_+Jc3RvMl1dK>C$9|#GYaQPsVgTVAKKT~UI@Fy$8-E)hDpa{};YXzx
z(sr6#T6p=0q}6*=oRA2ttxe{4<>`Y5zt!rq<%lm6f;M=<el<o*MIgcpUo-#|II`(#
zfd$bVyv3OrI9PXR!o|OR9J)kYu;52P3xT@>Q7JziN^!wreydyVDpD$e#m?u?pPfNO
zykp>(o{^Q61#|!D(+e#!>AQFHn3^}FY4(Vm=m<T|?2siGnoMTTf9&)9%KK@R2Wco2
z1Q`o@&*)JyU43WnM5lA_d<MB)Hj7M>#QBT@XcLiteP(57R$9MzbGacb<4D>5>Dl6r
zuE}QU`y&esztrU4^95Y_dt>$XZTFVMYl(ly{K9Cd2j;uF=VUs!`uE1^6JXXVwSHDu
zJ8tv3?1d(`dbJ35oSZ3%^%SL?ib@k4>N@=*9`9@&{`vc#I!Hb6&BSvw=JOkk>H04*
zHD9C-oI7QIHB0!&nyOdPM32L*YzBskLydFaA9uXidz<<`YI8gq018RHT{gjujKwmN
zCTyxUo#}(b^aex_Q6VU(nvWe^SBk8ULAIvQjW^GMF-Mk#OP@VeY*R*?&?#vQ{NTnH
zp-VVnYhY=aW021m**=Z|`2s#=OcS1}X3B01GeB==fq$Bt3psYx@&FR)<^erKSbUSN
zZ3U4h>50HBPOpV4u}yco??GLFr}tZ6so>r~V924yZXzJJ5Cd+&bK)L75`{zv)dZzq
zTW6;vD0WaVIhO^T9X8xvyUrHQ8*{M=Q}fy&hWXVE#BuP8i2NO@@q2C!4hWuo5jqdR
zjg(`Pi4e-n1e=2~i!iK$3+Qkaq|V93HFld4W8kxljg5&`%>RH|#X7lIFaab7Q6nmD
zQ=HO3abY5H0(ll1zhQ_F<>5h|9~3ZoHwt+rC6}NXoSd5CkzHI`@<y=ONsbmUQz4>&
z6bzWCnfH@<(2RcnuK7>qqO$T4etuT~5i-{l=Y=I)>3qinfUHMFLrV*J)-sf&m8-uK
z5dCb^^L7W)cM-knqpiI+w#nMc3fADCSN6EaJ828*DEQk6_EhOiyUtcT^;&n|t9FMV
z>r2};_<ipk4vRj$H*PNTLTr0p5J*V1_mC}&N4Yo}iZL&dvflnjog5`CA+x)vNCK2!
zC7SaiBawXNb7v>CpIX>Rf~h4TyWO`(Ak@oy=9~-P;OTg>f>LY6*eljodv~$>(dbd0
zdPL%M^y6o44e9v%s*-H%9Mc4LQhv&@vg}*^bj)P?zJ?7skp8BmqxeAj>BnY2>c|>D
zOtweifHZMh@E6>+ENZC@T05!|9y}0icx<5Mmg>-ldyRM2UaX}1JlSF*luOxJ9^9~b
z3$V1kUQP!DyCV7Oe8iRFr>H~J_x%F`kh9cl^$xD_U<C{?(SYEo#Ps;Hk+2PZdSD!)
z4eA_s0vQhd6nyF^(NM{uGl%39q70mwZRTN$>1R{9y>!S)??K8WEQl&VP%x}^81ZJn
z-@rkQG+2V~f1#|0_ECeN3a|A*5jU<|D0`dD$b2=ABFSaUp;Rp^x^?U-KQr!BXhpTO
zK(r*r0pFGrWZ~oCfqc2R_magNZ0vy9KxsorOHWtM(nDL--yfdFf8;1J*8_4^qOP7O
zrWO!TQB@5K34!5(nFjnLWFE}S*x)Jn=5_}(Fv1*a@V~2`kT(#ZhR0?Q{46pAVX`nW
zA(HS@G-R@kpMD!3ILV>*ALD_q;wARls9A$*OL?Xr1#R1(qO4xH-!uw^7pfFsFDU&0
zU0tkr_|^uL9n5lJyg<K>6+Z+&FEv=g9>(nj#=a|GytIGCGXL64U-$Wp4{38ZE<fKo
zEW__{k<#RxRcUT%gG^+DE5+pg{k*IzbH?3q4s79KQY1D42^OOycWERY0WNAb`zWlU
z`FO65wc+`uOp>;BZeD5Qr&|u+Hrjb_tW)_Gh7=lJ^UiQFXAcV5?I|bZdwY!F$Tl^v
z%1=#CbI2;kFU^1^)`*;J+lJbNq=@nRPR%6N8kSwJykCc_7<P1Yh{l`Ng_P|0wsnPh
zcCwHqxhu1&opweb?oW1ad-<5c*beDEFPJ~k-*2^f`iGux4}@&HgBi&W<f+s27zyKG
zfZQP3%opPloIb%!eE7NHeel6>D;G^VvJDU-2`vlmN%#wnACEj$_~y+&oHmdULn#j%
zM74b%T4D0Gt}d59Uk||J^7D~375w~AI6181Hs5hyj`1cgSUga%P0e4vYz+A^d@&Ql
z>8g=UE)R)1k=%#-4omON#lsLy;zSrgxeJ9aG*jzqYkA+%k2lzJG}sg5t~_2aNz=%_
z>Cahe6v=%7n^COIq4SMIj1!*o{xTQXDXjZSu4HI5jyezlOi~fiS1$!>KiqzF%ye&H
z+Mi#RbHBcR+Rx5>9vmp3kr@3I)5C?&<pkXcMW17U2syOzo;cA|o(O_+gIy+a5ntry
zQuyL|wZ(G>)%J4|-x2J|AM4~MTSVnwPz{qhGA_LneOv^`_+2S=bh&ybnssHaVbNRe
zw$<!HJ3v9$rCTOV`NL_&Zaj{C|8*xb={nWeOKt5dSU~`$qGf0}=CvH&xJpIvUP;|d
zkDPdWbmKTJmz!5-P_*n5n{zHUmNu`c4L;vf5*ya$`?^InU_VMW=gFx_ul~mELsqU>
zmmKw|>@ZK+;SRT!)I!M-!jF$5-}NtsTvzz0kl~p7;_I1h&l|TTrrQ&e6a2FeDgR4)
zvwMh%Cgvh`evlencgR(~d|B51CpkVr2e9*+6HX9gXB<j5P${C`LHVLvwRM)z3dkPv
zk|+s#0})3#1Dx_|gX|UpM2OLV#FQ=qBr&)OpjU@bo`gUykBA?%9--~NpGO^#I%ZM;
z(GBQrs1z||d56Ztk{-03!+d;vhYwf$`z(O_@(ENG5ZimLz3rW*M>5$I@wvccXlsOP
zdoL$vC3Gb@dkN6sqN97xhl<b(cQ2GaIQE)G(f#1zX%L=*Y94<K@3c^?CDh3nHUU<G
zNdsm&^g*Wh9V<y0Ny&GwUq94b#yvNMa<HP}KT`~;FCKY3Ppk8MWt1%_LoQ~7L_|RD
zg9;QH2q3rsd-~5q*ie`;mr##J<2X8*%gLw4oy&*}Yr5K{nf`T9sS)o=OMs)sjsq$n
z^mq^<?x3YTRG4r{*Tl3=%uFvU@_0mT)S-&?<>fflnf~G#gFO`!Ydxhl2A@2JD<7|?
zm8T`2TKjeVn&IDg#sl|se-3BzuM~Jcx)tAv1^`S|a*8Y0Up??x>V8}xzBry09uQzb
zC^@~B%qlvV_~nWwy%y&k*>4%M7M+rgdxgaaoUNq1`?VBFtlg#D!;f>Z)K1CaaM(O%
z_l$y>mw$$eq$RAl@w%MwXqwSKiM4$e<|k?E?Way3KF_j8;=rwWW}3-+WTz=8UhY-y
z`}b*-NjhkjwQ^g3+NHnVhPQdqoVSm8$K9tprtK`Cm_ktmmKxHzt~-#gNdPTcUhav)
zqjvlj9)T*K?X9TgQ0`A4h@x%~k|f~hf%=zt`XEp+w1FtoL5pJPzmtaiJ{%Fh2Rvqp
znp<cjYK(}obj0aF8it>{kJlFTHiI6sr!j>o?zNUg0^slYReAYXWkR|4<{BzBR4^I{
zD!KlThK5F`+|?dPFEg`Dz}O}x)^H$!9YlM)95#871~2ipho2bWkGcREB(6^gMvoQu
zJxWL@a~Opz=0*EB5m}g+n2410SzKN?65ws)W+d7~M^;AB;)33bvOmY4BoU}xtaXTP
zfY3UGNw;GjK*V9AX8VIe{XL2vAAP!(T3hN!65$GSYwPojH<4+2^9(se7u9484=JH8
zZE9&j$BzdcnXlsFPEXlUAO%RePb=p-moI8bL@;?QITfn^-EQ{cK9^kcJba-}%s`5<
zA*hZ^^v;*|{;YV-uG)QbA5|HJ?=|_3jj6p6Y=4S|;#`oLxwtikTBb+VbhRYk`uJQ{
z4z8cB*Sh)o$6Mu#&$Rmt6T4zuUQZj9RqB7dIqZ9Ehu^Uiq@nbL>Xjtv?Gp7D9R6wE
zKL$x9j>_3T9GYV1w%fI<+IPF>pAn-tTUame1!d)69RPXvYEJn7xE2ub(puIjU&UZc
zzGaMVf;{h%xB5cOiH<??(D!dhzXlk;K1kzAcj0OE?%JzBIueU*=y(Cv91o)>pt}<<
zRX<Iaq?Q8IAjB*2XB_(9-vx}=uFNO<K*Q!`8mfQiF}U(k?&w9d0gQXLB{#_B(P&m7
z#TB0w`diT<48Z#BYIpwP#C-zV9_AN^Tlu0l7|H*B7RX1<Lh1MS)1gSCz0iq&+JGuX
zf}5L&V>h?4f$h(vKnlOOxltWKEr>p`|M?__Z91=w<e>snICvoR0l@kw+5y;4Rlk4#
z{!GaT{Tq2oKM{Q3(4#Y-Px1VxjL<3LIK^~uPB4<g-@wcJ8}=O=b8`e*qW*vy%Sn0@
z5{ucXskb`0sGu>LvniGl5{g*J_`9^U1=k<uHOE*~(B|6N2?y2QD08;f(0Ft<75fDI
zY2-PhfT_7pk)56WE3q7236ynVa;|?;gAh)6F@s&ws$@Jf;nO~%eFJ#0liOTg3%f8V
zbSQ;oiIISx#dubV!NxUCS#Ldl=0^oPd58!9o14L^ypRLoPF|j$N1Fj26zHhecf4Gh
zOQ<HEeivq?na^W9fDsW}I7iFzr(et6<}1;q;N62DTo&Ib?)0n2W>@^uN-o~wgH%#p
zOX+tXi%&x0@s!=lYR*Z&M5}`*xSIX>Zf|LPRg%0_`XDcmR8YrGjCYfD+TqUO-B;Dr
z=K5VCv(0YW7rf7D+AW}(sqw<|_s#O_|2*bfmlLnwxORKb?cTf7LSODWo|+zZ3h||=
z8u@I45lZiF5`y;&vZL|^z2j{*QPgpsM&&!=cbDi4OA7ez=f3HGT0i3ceNtOnq+cgL
zYwMmi7nGUrPi(G98w!3Z?_0&XRUzMQ<nXlfW@=8F{1?hy>;$2`;Z<UQD<dpr?E~%c
zSE!bV3CYJ7rx7HFaj13^D>XT*KvXQCY(n1oJ6*&RJ4qYt3%fCDgH~1LXnSqeU)OSI
zq`ukW1E9Oj#P*Inkm<*^yZuwebP95Ei2lCCCe@il#Uc(n>cYb0JrLEPyn~Mrx!04E
zp(9dA9AhzC`2s&9v6I6*0vN8!%4D^yhPpZuLUbd1gODyuMPN1{ntb5k!Gm~yJ?o-l
z>H<f3E-`DIa_}J|U}y$#BFg5Niy*B2lIM(6ve+O9Z)E75`V~4hIJh1A>lWtStSP}G
zuFlR&b`#eK+)W_Ys`GOQX-n!k{kiCUmD5{ygEK|D>K4Wxm@#5z*xuP0I8vgKT|SoV
z5h#nML5b1-%dYyQ_la>#;l1IpF?WQ+T=_>*&2NbNNlF+5n#JDuASwGWBsV;1X7p68
z+z_dGR__fu6VV(^Vs16xWgMJ&bDg^9e*F{ae|Y}9MNY($QT^I^<Iv}cjTcHBUv2)#
z%hcB@j%gDARFb#&cTSs^MeKmvku1&=lo@2|Jq)@zse^PDVjX|DKhoD&U-)&F+JrQm
z^09D9z5bacQ6o_G|Bt1!0IG8P+W4V61f)wqx<R^Ir33_|L8Mc<J0w-4q@*O25(K0X
zDQOYu5|mDnkowlS|BsnFbLY+-Jg;ZJd#}CL^ZcG}rm1b5XYZz3n;mD9b2eTKbSXc0
z?7DL(6k5oT9(<uOA*$bS6YFs(vBDS9?-P_S0?#W_gkGE0<<iH-HV$Gy*#invP<dj9
zH_q?A2tY~1AXD~|m<Qx9G>?Mm?BS-?^V47E&;Y>uG-j);DHx_{;68dXkOp^X5fKq!
zEy6`aS=HQ-;8p}Xuf2z%58E|ey=5f}eM*1!8+*WNXFr&~O&@Ij-whhNM;fB@Ea?MS
zSXdln_ki#LAjXt_WTrg81VP6I37bFzg|Q_3JA8<~78|3A<C47Krp6plp_b8q{X6=@
z#{cT<!#`>dK_9c*C4xO%(TaI3y(!aA7RIVqI_t37E6$Fyf6`)b+dn<|>4tq%>u-xm
z{2Aj3X3LA2Fbyl}QRwwU5{4<``pBR<Awg>}UfEj}zymt3jSyM6Xg=q+v*{Romh$My
z!ySj2C@Z_v^76*2sa2i*%ynie;@eTadyCEmS~+OJrBO0MtMv-WHw<??QS${%@o#)i
z{#-oGpP9?0iEv_?0oqg2$zs)xi%)Tp#`pU}oAp=kHqGJob@Do3{L-|6P2u<VZ4I-m
z^WA`vU(^qR2Q7iFyuZ)&Hq{s~h*b|Ko<*n>g5MRqI0NJi87?rU1@#$Zv%th8Ut6uM
zti*_&h`w^jb!qaiEJmUV9uZOcz%R^*|MDZ%#;+lW`nDG13W^%!g!aj*?RCV@BD424
z^AiYjh9^ef$ofD73*{<%-@ic1Dm~xvseX8jdwwMxzgf|*51anH-xU#=mzE?BXX7;P
z_a(uW8qeSoPK<*vQd;SzJWbKTyuG{(vA0zlQ2C$i?H#<un1303KU(UsLbv{-hsO6B
zEYN>ESw{_RpopM}xcPus@~zRtICUaHuuJ40T)R;OM#(Vh^w4kOTRoOP>oED%-?G5X
z3|z}^$A?yCoqQUK^X0EEPj)o^{y4k!#~^w^aQCJ0{0~eG#ZMnDYU8wS({6G78Pk)^
zxQT6bJT;q3{NaNO?II@Ir{DOG9y<yK&@w|Sf9hFZM9d;CJ(`6C$VvH*XPa4J?38dy
zg)HmJu>_dP%j=}*Bko0^VUgJmvp)>7d%d^aE69KrdUh-2_1@r;FzuGuZv|6^^dRn)
z{hzH5SP2SR<-Sk{%#y}`L!BGrIZi}t_TJgtdUteitDsPMVPUcmE1w;jeiFXgH6bBH
zzpYoltj*n7sWg1F{iWZ@%h<S%XXhVYeN8A%!)*k@_nMwmY?F5MZG=1?yZU|*L6laZ
z_j--et;<`n#!->aLU9nOZ=NKYhwj}G54o~7H652eK~H+pzCQUX)xO?&tF)BzHJ#Y`
z$aIJqZM|<`w@5R<&0eEbU?tTv(0}*{sfNkc>gE%RV4kN}iS0$~^QXQ_B{(~Cw-f$4
zoRf3sVYJwzxepn}Z07iqR#n>iP8_pL%dtUz&sP=i@8`3eUtwm4AS^mit<J4|0Q%bX
zYcuNeme1%@vFgk7X7hjwT;+q}8+iK4RfiM_pVwOnzw3Khn%_$9$EZf@K(lAGikRFR
zL#sC>D!zQah<EdzTO)^rG*{GZd@Q!E!EB<iA|Q2d@cYp)z~NG7bQ94x_bGUJc_js{
zu4-h{du3vx=~&<KCHq!?0$aK=H;s7>7B?E3gjV*t)YzM{aY<u1c_#!qa*oSJMy`Dq
zo_Hl5muH9zblxSUl-lWxh_R1CK5_T=iH!<<^x9fmjA0{+=H0Z&gT>Bv36U>9gui<h
zU8+?yvG$9uhv~&Wf6c`5e3K}=e^}<<>>G%{==U7T+Z(YNhiA@YM(>oA9Ks?x{waon
z$g*)VqHQz$^14*oGk!qOf{J~ehkcW4e_8PI)EnXJbrrSB)6Qm8_r|AVSww6ejhe;|
zKLP#udqg{B$tlZ`ZCElwrJ|L(V`J$XRfqicWbL?;KA+#oyr`mLqUii81ErV?4X>Xc
z+R#u>0h8AU;gzv3?ZbGKYmnh)H&GvKdgfJ<e;VzEeWNQYzNa+?XSrl81b3TgwUhmA
z6WxqKVBP1(2;cqv_6X$j-`YRJr{9|?kM8~n3`^rwwBbjG)7R;LLP$-U*FGF&oqHI2
z;0544G4YObopi(tx&JZGKfxly^EwX<%>0y1k7^5ATBo^xl&+x8yR@{<AMJ%Sq@~(N
za^J#W=LqH?h0H&>oVUBpGkbC8akHKT?h9@{f*pIj_JzYJiXx|Vw42{Yoe{;EOo$%t
z{a}2O9}1;6iSLNfN1%%&{5#)7jepSd6LsLbq#IrMEo_KSZ-c*i$vt($kDN*@)C}*M
z%KEkSMLgLX7PDd-ZI|<UOwSqW2pybfyn~wipTwO+GfXDC{vjRCakFKQOuD$>seV$f
ze7w}zRdjgnkL8~sqNIfF*WzfcKuP^nPv7AIm#vN3+|2$*-GWQB(4KM*?Nu&y9<Bnk
zwny`Vw*^hG(8%TZPmA!sranhu$NjQ;<S3E_t_T(qG=!3JqLCxp<W>9G+h4U>M!J`}
zq%EY}E_itYVRwbHOaG{!WL9ytzkLukg6_&IB~|mHCj~1m;v1?w)4FKan0Mb+bglH8
z+6TUJM5y|leY;`ncZhKjP}E_U=`!Am1ENZ<Y`g1@(b>z}VJiifD`I1lwm}=kPf<&h
z{$aMJ9b0O4d_K5o>^SN2Zq~a=Qp=u7+vv3oR$}X2B6=y`3^QMR1kp<J>`q%_ecuy-
zta<a0c^$L2rX<x@RUTK=Z1GtNVW03--Y2APpVN$9;UL&h3CYYP@gm4e^>jQ5?eZz-
zzOYasfV&J$)sbXxx+l3Pa%FYb`-<mjJOo!Qq2;prC~{^#xfDJH-}agXd|KbOxtG3B
zK*6CQ31r;#d9|^)6iV@DDN%X<r@hz|ZfO=Tx(avoxEwjoXT9eY)VkA^HQ@zzAR2_w
z7HHqLUOY`Qlp>swjlK~PalDqxCHb_7kK+fQs%N37qm-iRAa5-}jdR69(?@?UdAmmZ
znU`*-{u8f;@?k5JQYWTI>*zYw1^eE_M5g~Q3{|r3#gO*OH*(##l!VZ1HS>?Ph|vkf
zRK$vDck)>IQ7*;q;#sINHrym^=*$<XZeka-C{c44vf8X!x)y(eDo?z6eYJNDU443A
zMrlTi@56JeGtSE0&yy4GdzkGjQ=QcDw0o*9O_XoW{g_kHV9vwoWXd2#cfC}ZYpf!K
z-dgCAg}35rZ|Ds<w67J!hfGDcL#?-Wk|QF~!9D;<?^+O)<1pXE|5fbM1Pr0Cj!Kw7
zt5f=#eul1LL9{Ki@XGA;#MQCwq0uW(&WlA8?3-ORNo5&r_TY{~$eoQe`1ZF`<ar;+
zhcosuQ!spS&u%%Mv^5LNmfD$o*wOQZTP#Vp?E8K6j%ssGJrIU07ht8+b?+PU1_aJ^
zpWh)J`xtY5M+!4E=AZ;z$F;RWcmBrV{=CnZ8gd;ZY4!W!@kX-`%Yr~ufj3oi-1%Y3
zrKf8`Eoo=uo0`w0s<#?$rl~4K6W!6H`|9C=vBZz~fo3z9_;Wo{?-3LH-NE3Ql}m3h
zcPD@jvm;aJ>!f*=LxloGbY<L2O}$S)EWf7ys>%u2v0l5I&>?cW^Ks_$S&^|IO%fPN
zI7CELxHS^+qarMrm0Hm41^7*0zHk(N4V?-KioDieY5P@euX}BhwFo$}2p~of3*nMr
zcyN%&5EI+u7th=-8Zs(~jd10Tw6*D~WPN@`|3@hi$-4#K2qmQ&`4=!Hi6vp7qnkW6
zf|i@QI)1#@EuTX$DVduy{3l{y99U$+hIBbs!AxYHTuV!Is#EGc2w8{7CAhIdU7Dk5
z3-QE=!3=@NbMKM~@bSq&I$&!HJ{3X+82N)8ob60BQ3c%mMo2t_VWJAG%bUc+{EvG=
zZr)QQF3QiBXCZ-xWn!`5K{qk_*zByawsy7CG?>cc?l$q`L)smX4`4))qMJ3{wMUYS
zvSgVJ_P7B+BlIuZp}gch!&ZK_(tEC%yS@1F9o|PbS)+er{~G@aZ?Zg0Z;8az=z2Cx
zsw$cE!|`jH>QtsKbGI7R2l+A*J$<q7n7sI!p5X}=t&zPYp$QHw-ZxCoMzQ4(0uS&M
zFe8?Ml{?!S(9pG<Av&_y8zVIHv7}J-9H3nFZ$Gy%+8vaL2Hh*s-0oUq=)Sfa753be
z4Dz-6z{ianfw(nzwzDR-A@KQ`W~p}gS6sGc1X~A@7}*;sjJq!wi#j6b5NRkAc6?)Y
zuhxd?jt{K>OjO%@|J;E6Jzu+t{1TaY?%wYwSrN*edS87jiQD~;CqzuMG8C)r8Ew#V
za2>5I{8q(|_l@DU!80Or&RsSwNt*->TpjjTvX>iLU2Kqr0WDup+#y-pM}PjHg#xQ1
zFZds{EchuCpn(e)xg^F|<e(iK@lQVm0w5e3^^hcOTRRPHu*LQe+0=X8{P<nf&;_;u
zKMufy|4y1Oet3ch)V+#2b1-vNRqX*CkMDc~JZUg%fD0+K{Xk_Le08=4_4wggV8d)H
z5Orac1%h}PJRBSl?*X!~2*pDHrc%&qLjv}^UU9X>MZyY%`4`yce?P=W=zIq7gnM0d
zZyJv=+(FZLO(l%Nq%U|6C=v8M$R73TyQ(&;n!2ZF#Z=^UgxlMXp14#pi5i3%f67X~
z@_2G|kN5F+qLYIHGu`$QKdpE5UVbdUK1Qui(PT5?`ok-$r{A}SfsTcRi>M|csKTHl
zqO`I=B^-QqeQQMw5CdR3)lAA$@1b`_$hlNn4Wva^YC5XD$xwc*p^#`BKcMs7;QQn4
zXU{t{9#pfEpQ>k^%#NH-J4XibXn!N}#O=<zYf$**M&kj!7#9LF=ySRM^3=L_8o&b<
zLar|>E8kL>sims*l%$zCzB`!raU^2U-_K}yoRt(6r)dA`poUAER(jSW4PoUo?m|cx
z5CABnj$gfKh$X>bv`5!$WMs-jbP{C5!~hiFAo~hKaB#rA$jb|vb#5TYTk&q*+T5&n
znFqtFdebi0gFv^^-P6+s^mQ=cL(gZi!PVT!X&Z0_;5uW1=`+l$VfsAq>nWLXd|Vu)
z;EA}*i9vJnXnl+!<iZ^U3?LL!$cI5>wc&d}C4*KBI<x$gkqY?@4Gq&yKODf<*9L>Z
zuIjH}?}anM#sES=z?OoCcWq|}Jh~*bwD=IxQCwCAkwfr<hKRNV=NWv3b#*Y;18?xo
zP9h_A)(}u+o;-ajC{GMfCBBfe0a#W)Dovq{JO1q(nBsKGl!$>a2T~IF7~zZ%_K|w8
z;@vx7AEw_c21QZTWV{j+bnR05i^ezLV{CZ(BPCcMGlCx>$^?k~)A<Y}Y2b=SbRtns
z%Wi#im}JU#4*+Q4MoWZ?`%;b9Ym>RTvZ6vmO${Owz~g4Y54{_B=0jKDUF+~8fKc@G
zQ?^PW-1A|o?hTDQ=!x_5L&g*+z7EeW;O#1F8<0{bKpw=tfZ%^oUte!vu3;(2H=&G=
zIaxcBMo1v;mOa&SQF!wOSLFMHGAvKJZP)4ckN%E%Wseo5{;fF$^m!g+o$^T>X@AH1
zRG~eJ$BTcF^Rr#C$98lbW1E6;0%d*mGysM%O-&MjSJ%-w9Td8|^&`qn?5Mi>0h!0p
z(8Iug_K!_-WRxg>_hP?Z4^+O5cH8B<w8hS|)D4CqPg@MRSV|Tr1fs{)uc2ie5!LEe
zN)UJ6v0Q+udpb~hNI;y4Z)V=r!kE#aey_0GW?X{Sxz^_HWCb2wI_B2aUx<WuTh*4u
zyNT!b*>~^MeNJ47f7N2PGkgJ+;%$IeSkOaZrh~@I3oKZzz~oxX@d3{+Lhb(jKL-aW
zp_a*h_+0>XKr&i@(fxv&4FQu&W^57|azB3#3mYVLVCHtMorVS!*!rO}hwMNCDJrEO
z32B5G%*qN7k|47Jc8(`cZX;l60&TRVMe3tbtKC=u%$E%G^><-(1=BCk68Qi;26SN;
zJv6RjIm2*zP{||F4xrM73{uc1gVGVcB^X{n{{;qF!3W(G|7kd!rVmfrujzW-EA-F%
z+48_t3p_V4*usZK0oy06kgF>StFJ<Wf&l7(Ifz!iHmrJZfoqfTaBx767Nm7RQ3Yv!
za$Fqbcf*iPT|>hZBBVg523jVFg@-`*U3eZ4Xn^u0<P@610{DOa{;eo0^E(<-^?3Re
zHV!o$xChS8&Yr_aAHW0o+Nb{?27)ecC;S?+-()2un%diCSy-&0l@38mU5l~f8{8Zm
zVCkF#@e@!;D0qxOnEe4#SAj>p_;i2=wgOqd!&T^5U%_u(65EBOL6DGwY))KKvKa(#
z&CSNeIxsVipF4o@4`gNjdfEy@j=(En|4`oy+W$%>(0wT>xs89buBl<7-l3q8tMCpy
zh8WMnTT_!<dSrJb-G(E72ep$d>IIQ95iSdz$%<ahy?tj+vlYlaeq$v{{coLVbk|OG
zAxb%>ygf=GDWx0%>J=w84yFu^9S&ph^~`ic=re3o*kfQo1Hu-Goa2Q63MCa>)sGkL
zAt57cd7@rEGe3iVru9$8;4m9Uv$D*-r13C#S1$A`b8oeMrT4_~+pGB;ry1hwfYQIS
z@1qV;)<+dL5Z?(#15GcwiK~;a3BH`V18FsLNyxqR990#UTRNfq12;L{(5LfVH@+(O
zDUY)9Z^2i7<I53fCf_B6gj0G~6Yp;qj@fSuonYWZ$naeUh71JbPTA|JwlpYy?qqY|
z42iIy^ae<3x|#p8u4P2%e{NuNupU4_q!#QINa3-Yn;Xo$b#+Pow2O6K-2V&eMy3~_
z@r7CC^XJbY<Mo>*D<@}pbMvgjN7mc7@3N2pBcD+Xcru{HaB$#6z*&xgM=temy%46S
zu)Bk-8O#Eprh{n<jPzl4>fH?1HOLYKK{_&Ugq;i!CGhKEh!Pr#06@{vk!P{aBNLN^
zl~YrndF6a<B#{YR%plo@c?AKD2x$C^YHMp@qXrC-n2TiwkTF1Ynm!P<;u{juuEaz|
zO$|xXqKknZfq^aaE_@suk7{iQax|e|4j%!8c<_nf2Yy>oBq*aT_+cUq5^YGYgt88n
zHkFVK3maPs$-Uxlph*zP3L4;Pm~yIzYKC6YTb-L6A_%L@+k@d0g5LteUU<xON<>st
zl;e;00+je5=Ko)y59s}Xxd&ZyhzPQ7N4QOz`atx^e<Z~Zpr?TmFUX*#rVPX6w9U+T
z$#6lU=g3b<2z%4!_p&>VKYSJ9t|#}A6-FWy$yr0*lco=ZY}76<uLl}b3*9gF6(tiD
z1`e}YIgW#=dIJP86y1u<Oo<TJ<yVvVi&PRZl`0R(82N|sZdqB6Yo5FQP^iGIpHOT=
zRp+%p;i396!02|XZ(6Q7u3VK^Og$8@ap0E&998!A>i1JHFb-6<F2=uEIXMdX=_*V{
z&)0Kq+uSgIwVoqZPG0$}`^iSb(E!F_(9rpn>7Tup-4?^D=d&c|X{t>j%`>tn+9lD3
zRJ2=QBgozfGb3Hk2^A~*)3Jr47Mu0nNmlAja(!Tind`WN#<OQDOGf-+cCvwuC*PlS
zA~gFpPmL*Jc;4!6to-~}RbziFyt6FWxTqJRTzK3nn5<YL9-&OXb4}q!JBb8PXN;_w
zi`+{7FK!fA*CDV$JuEjzRn{hZ!cSRL2@!=5y$WGF?k0?l)gHh+1-xur0g$6uNWd2W
z<=tCIR2&%CN;7srL2#xb1Cu~C09hmO)q|90a_fm8RniK4xggC4;uq{WAVdMpkV``|
zgr${?qlAK%00ckqLqt?nUJguX80F_m`tZgTfaM2LfD={VYX-3%Of7U-NI+H!P+)T!
z1SDs5@qa6P7TLRUo0XN<tR<ss8RERs2b6aa);2a*a1EunZ>X&e8yyrtAaF8xZ)o|S
z2wJm*c_$mn4IKp-dFye)(SuB7brVx!x{=Zk#vmx3uP)9&M}Uu6_+Q4b*<mr1-=(Fc
z@F^fC;V}fER86M57>B0<rUOXxA$Ccg_}xVLnB9^8<>)B!G$<XCVq+OasYpmkK@8yx
zM_6m?-L2uSYieW-(dZ5#5OCJKe(m|}cyZbu;^E9HlzwB51Th|rMdjmV*7bXI^NVX>
z%@Wpc&7!<fp0)Baj(UG}N1!JY<+(^M&X?Xu(x?dMYF_drZ@CCeO;3dh#zs@&Tcb7+
zdzZvQq=Dg8n=7}_qsa{Yt@H-!m_NHTfbb?$Jpx93dy~1QlSK`a_ZaK^EaMHLU9i(5
z(LyO~vvm)MrenN?x2r!n$IKED85z@I%NKH{MN3AM6x&W>-@+FAM(D-Kz8$eCubo+j
z8e>7uT8GAoc3fnCP0>X=jaLZI*wT{GPa6}d2W^gvi_XsqH*J=A?wNhC?|IAbKGm2|
z+&fkK&VF(vQFdji=UJ{DpCN@UMUqzC=RK@&Mr|?zZ0trI&Rp18pov>wSLd|Y)(QnF
z?0b75*XQO}hZH*F;PpVr@fMt)ogMf}0eZs>zI6Cw)jq-j2M9S*n_6)sgHT#pMur{%
z>izg`AiBc&37A+Y`2c2CbPn?AOl|gTAzQ*|OQVW3&jDD?FxMp!H|0&AcVS!c+3@@a
z$|#gKrKNqny)nY}P^_dX_=2?v#;5V!OsXgdh=l9300ArL=>DCg9D+C|1i%MHk+3^@
zO2Ef4VIdjHku<2#Pk;5w*Ut|&dh&R$XE&ZS%$o92lm&W-WrHf71l=8EzfUXG4tS|<
zgfm+2qs4cFKor>3S|AAqL>bHz<%vPYrBf!%!2#pz7nd-}h7Gm<Tid*gPxHKWd!URg
zU{T9mg^6_kYk(5Mm3v~sYkNvSW^ricl0?{6xXIDcOVY=ie!)J_|HrsT_-}3kbBWCJ
z1k4!Akb$e@0U6e70@B%3^6m<pqySw;yRWFkyb+{PtwS9}oxe%=CGvHN$VKPSpE4|2
zho0~d2M>{-b`Ya^yb7kCgwhFWtk>#adl|G0n?*e9(kX71adE}i`13VN+dqyJwwhZT
zS{3x#l*IGL^A_25n)s;0@thRjf#!X3?b(%$w9!1}QPwRbbk*6;pO}QB=LE01eV3T9
z@iAV|o19ud48jb(H+meFc#(y|PZE<mJp8+}^Q+&Vz}|%b)10dg6bwb0e`+%tcnahR
z>Bp{~)LK4y3r4LEEw^8~F>)bXlF)t}4Wo(Ne%`hL*B1lM?Y^}?DJdx+Y@2WZb{Koy
zjFSj$FKkQ@t1TlY7F$rNSppnQICJ5&1>L;+CljDkeflKM$$5{F7(&=!>OSZ25vj11
zmJSjtyDd))<Y3km$V7thz~5_Yy<ffz=12lp@h!OFBqb%q#iwm*b7Vu>nwtJ)+U6n|
zM=R!h<e;7U<16(PgHHZAD53D8K3lF8bA_$=0wxjkY>+IZ#PrG6HsXu5;Kbx)N;ED4
zmYzAcC7hPZ%H0qW0J+Xu*<xc5AopEY3ntOPgNf;Kcb5d`P`4FOgc0D$D6)(&<y~3;
zSp+R8QUT@%)hzUUz;gooZE~^}Bo%*((FXU+qeq|ImK7jH8irj^R&blQ%|SF5h=1ju
z-~R_dTI+W3mz0;^<0c32C;UlZrbGtWNpH+36^_BI9KbX2-MN8<?Xt-7(LIzg7J2~X
z4M?rDpW8mh(Ea@Cv~)*8TJ7!GvKE2O9v|{{p-iSn^ZGf8ljY8rrK^QK`6?W$oGY8T
zeN5CbbB<PTUmWi#buOW^5;WoOd&_(;4-Fst9d^w)HK}Mwe%fe>s(Wsp1A7E`Q0c{A
zW~H$P{GB)&Gc$W2Q0M2-S}^ceX*k+552x(IkH_0*mB-DbIc!ad6%TYkM|InB^nFyb
zP3WTQID)_V%^M0$FU2@MJwjAG%Xw`1%#Jp^0znHMx-~V;E;*VE6|ZOAR;zB@wKj>0
z{|3WQjGZfXF+0Dmt;xt9|ETkJZvV9S^F!U%?8(RNdS<jt6n-}Bg4U&6vN!%0c_A24
z3ZPHqO^?^x3faLRBOy72I-Cj=9O5820fwA;z|I{=KLuJL$=%0~SAhKj`wIbP7igQ-
zfBk}uqCZ;!ym-jl#_=)u``%Sn9v>WR{AUJ1N5D-78Ztk{7A7WcGBAu-)j*m61R%wO
zU=&Ituq6JM=nHzek48MvmQO#KaHc{;*MAIc02JYbL%j-p8<;bLss)frNYxkrcJp2v
z;QCti{Ljd&{adf#q=V8-EJ;*E1hoT}U4I&%__&h@93;}93GGsaTO4$IxO4!)Nv@*+
zn=7<yr`PxP*lH<}bS!0{(}KWgd;`8JDB|Fc0EjKL+(EEHbNsR?1LRxqqGY)=;mAJ+
zJQ|>H<4jZ`|MwK6FQ8S-%*Zf=Aj5`Pkilf$QR7X=Ll1}B{(qUjpihmq^ppsKo4T|#
zY})XV09y-IfjlvHD=01?WE7cU1}P-D&z~cMFf-NDa&mac;~_mA8jw&49Bh3cq7U9e
z&JiAC$UooQ`~Y{!?fe)f`VgrHylbeT)7!%XG-6L1tJ+6yY~1v-{g#u$n%w=QhUo{0
zJ)=Gp42(XkDl5_5Sdgk>6a4FQoAkoIJ}&=bSH8%SKt5c;Low=}5Fd$H>xYTpqu=E(
z@XWMvGq$*hpn{$K>guEc>Rd&l#3nrtSW`JZ4sp2AIxMw{-T9=#0o3o_ni{Y!*S-G}
z<#%h}juj#IiA1Sg!<?{?RMV?d5<^>B?FL#3hMQ1iE4KZuah5J3j7lnNc*SRC&ox-@
zt0(v-w0ij%OGv1DM#>%+)$q)ai{xmeMeUCIu=CuL6s%@R@VX!F=ry=HwCH+6A_q{s
zhY+&+jW0@yl9UwMO?)zm3i-g22YT5DUx@yNR__xtvjylc0m}#+T!5K{ENbV5dGEtj
zB)|^Rpt=Y|`>X}S<cNuhM<*ukn8a|&$OHpa2r>(#1Jbz3o@Zu0GB8Nb&4oK@N=Ak+
z)bcNIq%lxCp$PycH?VZPo7{qL`qM1&&6~w~oRSg}NcJ1712|wH$P<ihfae5nTj|6m
zxE5**@exw=0QtTLCw$arSn`l9_AP}CLY|{2%m7~m#VhFXWMp#xlfi#82ev#M!=~9K
za9q9v$ECFN{OqhG7&CU8_lEoW;MNaBOSoOZ8wcGN)|3}<V&RNXHNbzu4j;^wHqO`H
z2GQf7H}Xk=Yzi%}6kQ%NTqqt<(a<2_+Q$d_%8&&~;RAwJQ?RnbqXOIe<x7Qo(AW?H
z789({)nC6h{`vz{41!;ev$C__>v7_QXTVhj+D?7Jz>Xv5F;dFc2KymA_}#Z&3J+dg
z#6h$=z<6#4P|yc6XiLmcml#DaV%8k=Lsro_q%p7lx-(2aNZJV@ivV)|09Q2)PgTn3
zzek?e2gwbh!osPq-ct<|LSLX`MAoOi!7!29f!5<#izfJWT}?XSEB$xnchNew1t-e5
zILL@=-fZ1n(h%BN+>G|X^<ANTMF_Z!uonbv<_emW2~7R0h>M%|+9E_)wXr(dKpPC(
zQ-Y~TtJyWQQZA0hRiVR|fW?qNcNQh4>FNDC&+qN(_p&g%y#0~1;FO&_p&PYpa&%Zm
zgk;C9ULg*O<%>#3{C;8&MkU{r5-sqAmdh`pt%$@TLK_&zvEB;G>;;ud6JGA9pEFKP
zmuB59{xbAB2l}GLf53qz0~a`n*25Tv9zEj#iw?-KBaq!&ziTlR<UL&bN8xv3@y9hS
zX(BRh%A3V#-PBpH8TVPtCp|nYcG!2f?7#NQn6>WZgan@t#1qMo9QAozjzlS}_sveD
z8Z*hnHExt;@roxEK$L(g1oANWujen5WirE&3}JXWA8&&U5sW{jI%N?1>wYtxB%Bcf
z*`Pp82W=ytkkFsW8%<qHVlK#ca+aBiNr~x!u`wXjtobRS;2c@Q!oWZY?OFyKCipR}
zgY#?PtxHs4&LsT1X+a4T<)-H5yCEfTYlZtHY^?7lz<0!swERM#^gFPKVE_E7Cu;zs
zJi*nI*O%1z(a^31gS<>0yp51wtmRKkKu8#;Q~)i3+UdF3+55#hF+rKZqChQO?z2yh
z3%DsIiJ-4!!0!^K{+q9OJ}}_8*U0>G<huL(y6?q;Yn%N6#i^>A!evoPc@C6s$qfv9
zBHni#Y5df=hZx?ws2yR>C_TK}q)Cgt%C(f}p)G>&e6xg@UiyQ^ebmYu<%*rnUnw3s
zoGTr)s^+2+eNqa}88@*}*~>C^K39Yy$MlEph4;^JKe~*6%vqO;UK(mQ-C2Bwnux1O
zR*tpo%eH!=Eg>u{qYdZ&BtL7aPvElOd0b}_!LjL|LFfR0p<h6s{M$x0G%dk=V(Qeq
z_wUu;$KS8+wpCpHSo+=@@TcoGib@GHo9~j(n@e*Hy7eh$-08+pG~V_vz*;w`F!F+9
zp?O}D_)95MV;{aO1w;Or9rQ0K(wACczDSd(!kUr^<i(qSNhsATS7Z6w*T;CBnAo~s
z>>qIblMmqjJqEo{A2E+z^&dd1!?L8%@+KhoQ;dlb{N*|(_?RoNXJn_V)LCg3*ctC9
zpoBtag_ldk#Xn)C&i8a^SpXqrA`8cCN0{{5@TKnn&+_%Dsz`dk#!lTWm##FL2KBdU
zE`vKtIXTgU6|IupT4X!L*A^TXg_Qn@y3&9Q?n3EAVP0|~YVjlFd_^Xr9T6srI6l9n
zj~Fl5WskOWY2aaxef>fJx7{Ngf!?XX3b`0EoKe)gH~}E+Q`-<b4L1+R^8jl|x%0zW
z387yKh_0#GY-?>=V*Gnp9r1X#FZbO!?B2inWVN73VqZv3*m+n+zE6S8h>Z|MNE9$y
zSS56`6QhTm@4U{d_lc$a(2&;NCUbavK&@6Jyzcs^V!kKo@y>IOywhh{WY~zG27iWb
zJe9c-A~^F_$B@I|-+E0iJsJWo?Ea_f!t8P2)Pot;?&eH8Ouc);LC)cJx$e1%h80|1
zX3s!7Cp_`N#KQ6K5Ab8@+A{cZ$De%-l=j;{`?TMeUzWBlt5?R@fMMh{>Ky4!a3^};
zsKIY1qS#e#LIV3qqTupB^s%Wa-=z+L6nlOyN3xoB|5h&11~yRx5S|9MKlY)|iXD_i
z>{peCQ01t^8;2;KcIegy2Y^K+dp8=bg5Np<_qHdEJOW?bjd>@3uQO8VeliAgV?|*s
zzX0mGN*eF_VYbwC$dVjUOwYC50o#D0e&ULp-VfdsQiO#!@th#xZQQpQyd?t;wPsKE
z84|B47tK`Kl%#o~%?%B>{_U}dm}_}t3B3jF@L#{_WrCVaI9pq|Y!eLBUuu0T>i^@?
z*}U`b_~jMY<Z=eS>`>TqGm!^=#5EjWvbiq8Z!3?~L~~o0%a=pv45GWAhj#^X3)GE4
z0mo|+94-m}_tSe&lOxfVF_9T&!QwnZ9z~J}hmR}pzJtkr!ToO+6_KM8wMdWxIo^G&
zdqj2gp!CTgT|HT?8&6aHx;QLXL5+>7O^aBfj}4|1><LCwM}G@KTbTOIwg6ge;$<4S
z*vmhBJ-<FDG3;T5cEtp2xa1Gvx=fy0OG;0B9m>sy-8z4s0d_I9o+oL8(!Tpk%OQ#O
zZ%F-4opp?j&xb^fAr-->o_qZR+i01mgx8@9zoeCHl~@%&hfZLPY*E+i_?H3N?2H+k
zIja|DV)F#eS#KWVIc497#ATAtAPB~LhTt7V2^FQ6RiRG(O7Br`Q!>txuA9#DXJqi`
z?YJtLc)s3D$VCm(ze6kXIhpimCVWzx_V03HpN4l`p#Ie(c~_J~hY`X}Q_6od1M};j
zmx{+jtwt>oY`A!GxoE-4Z*0&sP<4Zn%}_36acd*wJp?Ol3jXu4QIUPoxSx{ve#hKR
zq6Q7i9|6X|w&`zAh(<zKz>vmmWo(kxo^wWnpxqU7a{oJ8Mscs{X|O6^Yf4UaAw6D>
z^v>7Jfc+)Qe}5$X$^A2wz|9O_SKLb4N5^s3CJtYRsI!3O#R`|LtF%jOo7WWT%^sK^
zSTT#n3+u$=6y^Dd5mh-6B0T)=5?OJJF}-tIU);iY(OG>0Ln6q&PHnxvBPxoA{$tfz
zJWIL&W8<gQ->XY$0s_n&%*2zV#U`6A^s+0&{=;7e-9g>nU#`}iP9IZC%zu+Gr7I*|
z;0k4MxD`8O(QJ?JwurjC#VCw^I{xMF*1f6d?@S1en{|_YX?yqtPlmH7ggMbV>^v#R
zN{4eFz8ro`#&#X1Of*c8J7AfxA)0W*Fz-{<n}*QdFQP+?AiR1SK6&KJoq*RXxwIn4
zzRRZ1V$xK2(8+LR@nb_}b}8{>F|YOMFFm3GXa}W4A_ZO!AX_11kO@3o?Js3N{_rGB
zXM?QD#HDJnvc}$%aGvXrr5_79_iNsn_D&r0R}nKvad9Ck8?NivOCjt%HQ-SDrZN4&
zOcJf`SCV^deX`3CA3suM*qIcclHi$vY49lXZKWmyN8*K3x2^q^J*hw@Xp6HKv&;+2
z1wQ?IViJ2C9%`>Uw6lpnE$@s$MN$9iv(LxS>8ZweX;M<G2n+htGc=!@k?J0KWZ!oR
z5d71Vf#zaXkEb6!5)88-tJyZH@EFOh1bG98+_RrW>|>pBmP>|pAt?i%Z_fuQZkm5D
za}-b@WwohH?jmYHi9+rCS(f|N{imB`pc&yAZgpel**nhG9NXdd^punjIeteVqLt&{
z`WqreQBvTc^!&2n3FEBhdES(MFxYFBK!Q2=C=#DN1Ce_R#Z6pg4-dG7<wjaxr;m<}
z>F9ZanSwtvcws@e%#m5_5Jc2q6vE9oQ&&5PsC)KRTwFq(mwi2o!GVwEwAa*=UL}Z}
zMATBCbH(&~84Wk9n@7(|LkmcZLEkRH*dgO;HdyK@hM7aZc{79AR6^43_!MH4vr9c-
z-{#|Nvzu)2pjywfQFzH$lyI*(lZi9cLKV@uJa8}eAe`B2+vk04qukmXPd<zOP&$MZ
zB4bAVx)2eAcMC6l1&nwxggKg;JvM`s_Vbnbx7IR+&}1*aKYEnk%M<>|lFBpTJf=<-
z6DLAt>hqJanU7%qv<*n&BaD$uk#qKldKRV}LnTAZo4YAaD-`frzAt=UWAr`7t;8N%
zx1dMuf>EZGVkJVJ!b9Y!h`6NRxS+hcs0V$*coN)S!Dj@))Zon|#ujm!0xt)Y+AmX6
z|AIA=D18NP=jVV30Ouv^G@`V!64Vl=HXZ=EWP>hZD$W$VwZlC*u#nUXXYyX-v<1d8
zD1ZHm^JOV=e13mKr_TU!lRc~>ASqK0tH%NRFWPRSj{(7qCVygU4iq}!;ZiY*ep?k+
z%s$JdWn*;GGm}+rtns>gnr#7rF*d5(iHeC2BOb!9pUdA{609MUHKZbVG~UJ<RE5)s
z&#tRr$rn52)`XX>GOXaSDordsQILp|(0K2{3HnVzLB>x%*hLzLQzx#B<}dKI*>UnQ
z{1j~b6Rw-5b{;?EY)n=kJJ5KQ_v~}gY1viDhcKb|uH{eS(CQ##W$X%R_0wg*6IL<u
z+TWwDW*)67RBdkg9WnRCVt@K^;`s?k6R#OTk?bE<U<c6&(DQ`pFSq~|@<IHJkBeIl
z=^KXJ;39hmqfSsF*$Km_3mTp&CTWJnIy<usRc%+>1fpt?eZtCOolQ}znlxrVxA@_@
z@Mp5o$BMG6FK?-cWpt8LpLH)q9-{O)x4yZI52ZpYn4Pa7rTAHf+RG@0Et92D(#ihq
zj@eh3Y3b_ed9EZb+)o4l2J_4Mdi@4lAFXBa9FJIr<#gfQVOeO4`i$=?I>#7!Rg?w0
z>5{RWE0p?%vp$t7qejo6!}VYG#oEtUQYaNpSxP1rop@?WB#aqxZxlrtg{?AIu6Hth
z<(F6DcP%tD5&Gn@MOR5rH4sN@c@=l2@6qtZn^V@iS*~ZqVWEY7E}hbE-#MRgrK-y<
zvF&UjMr816MY}J1iheIe47NNWuEPzt4RfU%G1AH+?^cuomFp~sUDf%(fe$g}YAncv
zE9k%(RqSqVGRZ=K6%5M2&`t8J=+mcZJK>~y{_`nu2;Q|^?*FdWBYmQzm4Cb^M|<;Y
zTnO29;iFkf&S=S(yzlolc$_8HMI(AJ&ss-+^uET@VY3iln#9xp>YKLSiVuB@4fIrb
zte^h~LV;HUQF!26I^5sCAwKCS3>qa#E!v4leiBy=b1638VX-8;QHd$3@9*o&vxE~l
z9f^`rlAm-s<8)jnDqS9DT87}&Idty6sijrtd-Li2dqZNak0z67iTy=ZN7tt@CSwRn
zYU-bV1k4v58--F+?cwSKT6NjWx(CIc-CwO-H5%`Xu?d)v$f$@XYOeHGrZi{O|HEt2
z@9lV5Q!l!6T0@vrk2ci(8tp1s&P3w5WbO|Eku8u%Uuz&8<^?4sG2CHDntFWq&#kSj
zloVZKV>|>{iIL;{`1lkx7WgX!M%m$(FK8H(x*oVpJ*TDS%qZvhz<m5R|1I;5Ds{}}
z6BD(Q7%ZKVC=^gwc#ERYl}bor|1B`MHIJygNqiwLEMTG3FI+`~^#-#L2jTl+>nKN?
zGj%;yI&{Jz#&Ga`DP?*2_eT%6&-%G?U;q6sM%eqa{?$=>pz&qJLjKJU&jWM~^&2il
zi!M`+GUc4}F;Unszvx)p?r?Rz<&T|B*ug8|_K_|W9QX~h>}1hqtwTwKwVG?3T;oS4
zvw^-cqRR6}hb`&7yyc&Z#KwbuTNqcqDh##};byo#9M{D}%5?AHwRlI9Y`;{wHAur~
zF{k*fGO6Dh#0-FuRVhT?Oc9~Wp>>wPBY=5{PKe(ekc4P^p<Nkm3G?R`H%jONTMPDM
zLVRSR%F3TJPYLKBLQ^BxZK%!$T^=IuD)hJZ_C{LRaRkE|AtR%UKTK|Pagl-UGX5mT
ztV;EP9y^&?ZFSA~#`g_RAPX@z<{IP<`~qN?U}i$^is_{~Z7=vl_1_VIz1SC(4I5n^
znttJo!NIy4y<3(J$c-5fCT^2kpi268ex9jrqooBy=sCqJB@kAegO~#5mf$sn1U2$_
z5GcOUf5)a#-`2)U*xTmqyx!u+Jma?{*ckX*tiAY%FbHDI#*zwCzkVi@?IT2|qEJaI
z4^|izm-`ZqB7|?0|Ayl0ImZh|e9T~WZ1V7IsWpy_76-e@p_<3%RQLw^Y02r6A9F$=
z3J()~|K9y*x5#=i7jLkK1V)t^Oy+@v-*NLn#^zd7N6h^ae{YqDP8=i2qfCT+nLA@H
zLEBXa0ow9B@g3Nh38fp46}6<-Y4;fho-<aqrQUfQEzJ6x`fA;#_Pp<fjB-Qbz!K{j
z3lH`qeid;I-jw0WS+n-b+1IWWE|(GZKYzVwk5P7K!{x<q#0Mqz6?va?lpE_>a@wlV
zTn5U*LJEyoZeAV(un__11kyo#M;8}XY$oZ;birlHXb!SC@B{v*^rN6Z7fWiWuZIYD
zXeohn5L&d*id()9T$yMB8Zc1S899Se2l^9PLrHOQOz#L`uJ7aN2}Zk@osH2Er1Hct
z4+K<G8{F!k5zXh)4rx3NABQspR*)f>;OdQ*1+@Sea$(#L#z+HKlVY75nIH*h7T>=8
z>w_uuomG^TYYfvvoHqad1N;awP!rH5n`!vrjL?`v20y~kt;#+vAu22k1*8bpf?Hc#
z;17O%$C0&?k7%40>Dz_e8j&m>8JR2Bkn^m07vv}zke-(Zy$on_|4~dpJPW8vaC<_&
z<j<H57;BWuTwk<4e}2^+uSy0q!_k))D=C4!x+h-wmAa-S3p~Ch<Jx)K@j-R8zct)3
zP{k%Na3D5}b813Oz<5KTBLw@WOSIeVsS?8vHx!8@r=4W{J!cD)f3{!T7U15V!85fT
zA@ufs-Ptd&QQAND$RlDcDW1jqOVScHTsFlomAfefc|mmg>xQnhJaZ^x$2KOSx@pN;
zboE5;Aw`y@jWl+R)@N(i@x&VdxvoYd?#;iJF5N&Edi>?Z){7Sfj=KaR!jv;y9GwNH
zMQ(c!$KJUlG`T0BrW3u|vtRIdzhYQb#wLf&{o1{}#EsVN@n~g?2;J$yvJ(;6u{Lf1
zdr0UgEjBiK{vP@&Nh8UBfB^W*N3wFD$7LtXnfi6F{o0H*g@6W055SKGF_uBT_8`cL
zgkdV5qEj{pL3H2|zT=oSzTpJvCcM0?d>|@;D-E~{4o^;GK|+_W7~=-W2opwPsgpSm
z5WB$S3n?pwIRlJOq2n^Xq4WTmRZEHglmZpu29wquu_OpYCMP4C3;Z)wgtGMX6AU}I
z{=#x8s@h)eis2JMK$JFY27nuZ;f4S{bJl0~>`n{(SsIZn5F>(C`N4x_=#Eh%*yEtf
z3lCz!4|2*On*dlwAe<eC7TVKkdU?q31S%;=4t2^v;#ghH4+CXLsC>1!<BbLYE^2y=
z>9^3l+u8!{*Bq&qlsqAd@&g@u+^FyZc0brD!9Ba-`OQxFu+V&$3O=`YO7F&zxt`=x
zMiX9;H8#!ff(r8iI~fcTL9YnvwPn}mbMJ0pFk?eU4@7mu=p2|HgMV*Jt1JG;MHyLB
zRZ;@P3~*jVvT{;V{xq~-I-ib%<Od*a(9Ax}zAFTAI0G>ZZIDBMWni92^DG=2aZA47
zH1d_$w3w1~lYnUAJ!b3z_tFEmbIao5zrTIQS~>n@m;JcX&=gxhncaL-m-o5$&t%wQ
z5OFPH6|p4y%+-zrH`PDrP6si1|ImEMvD0Ju&chqQpSrs@qcOX}pGP^7$(yd|ca|$W
z%ID|Mrgf$+|0Q4%jJ@6Fb;#<*-6+uKjDZlFA?%f43>)}F@$4~TO?34r8Px@Y46z+5
zgA+wbY%6bHY$bPbBJG7i#0aBwP95gu35+V4jN_%LC*GF46q}seJW>np??>M6FLyG0
zTl(dvE0MgSRDwcS_qkKQl=4k%S%NjM=#6z(`83Lmlx$&g<uRxlVH}_05CkI&<kEzK
z5A5Isc>tFHBW@CdEIrj({MH001Fr#Pkm4_nI6Xa`1063?bce8@JO(o%NUix;SdfjF
zwY8GsV(Gu%bwQSdTq0p;SkTW0297!_+^t%cqiM9sKoter3Ya$lu8KDuUJ-P8pdP@W
z33|oRmgw>bggmkSyN@7^FC0U3REG!LhS?WnJa6P$e>8${4N&I6YXo^!92}ke_`L^~
zi)t}lV5OKJ8|$>H0eBg7kYT3;^q*#)%+AURGkH86p{lLzT1N*WZv>*L7#5Nku>lwf
z#q${;EQiy;Y7V{3|0t+P^Xi>D56bl3{rx-)h(LP>hi_Ydp<fJ@BFv1cCIKP@@mR3*
zW4ay~8G*={mYQ0^Nf`)0FxLZ4%gO<?ok5ui1frxB|JF7LTtR@W1t#hN{{BD}qQX}J
zXX`W>VhO3V1_2O=ts(sj_<(T*@C-%E`Jmhl3<TMC<6M7mnO}w-a#1shh}6SGr>$+l
zf*){OAnyS+4ME6jSlz&pNPYFn+S(elnJ{tBmePE^LD3Mga$5SYRU+hkb}{&$y@5J@
zP-NvbrHaLAW2y+}E*~K|#@2QdxB;n!z2dv*u8npm18OI+<PrA}si@eP$@F1!<kh#9
z2)08$Z$Bg!JU*_XX=~t1?*2Wcx<m5&srbp>b?}DH;tkd-RpM+$MnRp^?Ur616%%1i
z4(tcCJR5u*bnMR54kY}>^h1%28!x_lv50AlsZk^7mOORMy?IS=!*qGRPjrO6>EQd#
zM5sitz7SzVi;cd|T!#{_KrGhz_hsYz`WM26CMI*BfEpUtChP6p=nq}$E34FntE%b@
z(HMJ@9migq-j;c9J8t)C*iQ;3Znsc<p4ED}D3Xh?b2h1iM~;WD?nV_r{2@@C8$hsx
zaGI*Ngo!6IF}m6%kx|Xqcovulrx2F~?}6*-XBaL4*zfm{=prp8Wn-f}Z7=8&U<|ql
zXh0~Bz<MH-IS3|qk*uAyH40i<6H`+H#QzutaK4TV4<ohzK>2}?J{V=BKpIitVL#ZS
zLAZdNHv^&tJngl$DMw?XSwk@ScW`&FQD^OPpK}u7Giy2JEPPj5dJ0WP7;g7J`~zza
znLx?R{1{?I(d8iq1>#Shnnp3k0vagf^6w<9OFhny#l^qCw$I7QsqnxP=EgvlA;*n^
zKBJ`D61e7-9sqO<V!>*Q!jo2fL7I+Ce6^|pbps&YpypukTYUjH&0ToI!A${*vw;DC
z&uDRzuZST54Zs}+j|>PQpw3wUNHM|<L^x3j2cQaWEi7CCoyIhj2>a~V;ZrSsAjrsV
zZ*L#7W5NFUanfvHa1ioTxb)xeA0HDE5(XnN`aypmMsz}vq0Xx7V%rkk46|RvT_t%v
zmr9T>8C3wW6RKL+h+sabrmhY=zyOdU!>q5~b#Y;42ErHt?(pi~ubxC2<dmtb2}c^~
z__FZ7MIH~3;CJQaKu6>ydB%@F3$xPwLXrQnl3&JSQJ8}|<OIHG)4(q~-iy8~h9^H_
zz-|G)pUXs1L6wZt>#eFRtsK2dh7$bZ+d;R%(Dg@pZRCVr^GKyc<dbSVp$t!ic&A$t
z!Lf)Udse@NE-EbvheS6{PX+Z&I`-hnd!K!AU|n>Cfz`xATAJqaQnjw*&t!Yr(XkO#
zY=>ojWzr*YGn^zD?yLQQIKK12AhED(d)Ag3>{8M!ar?RI#%04^zUwyZvS<9??iuPT
z<Jg6VQXJ*UeG{bohfb}&B!LzoOfIw&rXg2sw`n{W^z{Zc0?u04S`d@_M1d#suQwg$
z%U`)ue%4jZ6O>3S2>`msyRO@CE9b_g33#X5AJaWrih{7C4)3|O^q_2v)~2Y-(IFz1
zAAewE1U9y|m!z=@`LIr*`n){8p;85B@AY~6bu*AJ`e}baSunDe@&hAp1WYn;^Fzp$
zjDv{!8diycfx*BpWXgyXRF1%S1M5GOoB$XHrvV$=8oW<R#H$cU1|Sb`#Pxy~@z}u3
z?+KtiAZZ%jy!N+Jpbg~W+M2e_^J<<4-NPObXn<5hLQK356iHpC7fz5y40ucg1j57?
ztV8TqtNr-fg@pyAex|MMsyN;3-vzKn;Lw5h4J5vBdL`0`x=dB)x3`DD#M~S>HxQB~
zG6zv!<Dfhj6cU2^3S_l~`tP6)h96MGo`XaPgcwM?GkgZnFhUj&kOyMp;~gQ17092U
zByxxIaR?BLC%f~=KijM-WcSk=G-{&LuVIUa$U~tKsagQFfOG+(R>5tdq^!I%-z+L6
zbpZrXz;;7a$0K+T!8-&iwpeEa=qvxh#(>`qL7_mf0;RVtKcy@vqyeHLPYm}4NC*l9
z<e(ns1StApODfrCJ>r)~k`q8UlX=Hc-_FhsX6oY`2|$7Y-4u2~Wu+!>I{5y8-bmEN
z4^)7X@$2J;_7}6e0Ko#idrM;u9NWo-dX&-9m!97SGi8KlVqbkYJj_ob6iP@z3B57Z
zUVb%UzaA(yf4QAqrjFrJK)Nf7V5Qi0LdQbQclzz!tI>v@9zFhrznk|Z<hZ9dIhy4D
zPk{6C-92~{R{K}(r(<HHC*1f)L?`~uR`65n6d53A=wh(?Hg?CU4)H~QAOAW)=YHE`
zQ}Q6}j!Tj<Y3vN9tmtPfWee4guuwjRNcM9~?EReM)S!5I4U|R3C5EttuF*+?-#VkQ
zjp5I;vmctbjgal5ENye`-T$meiNS+8xLjR3#hHkvXW&5Gg=srzVd@bxy3<qmxwvg%
zvM=_j7j5jyC*6@9ySZfrQ<JxU7Ram~P`XidT=2{Z8T`yaoiZYbAjc*_nHYNhCP5C@
zm6@asry!FwTXCDyf)WI<(6_84OOxQ|2OPXRL=u7P2#|qhwesl$4^2$A-Ne8`8S^-b
z<JI+{8B0SI+^h9C;a#|$qXQK^ti$_Fzo7Vs?9AuyR-l2<X#w*r;X8Lw<TNxAA)cC$
z5KzOg@dGMHWcCiXAxM`XSnNN!5Dd@9zJ1ft(-Q`aCFFP7)PfQo%ua|7I3mFm2%=!H
zrQLayXA9V+q6g5?hPs?e*H};QJ46T+*lB1CRo^GN3sfp?ZQ|r!Xx~8873dK%)j^a?
zOQ_13YGZ2);vk^mezU8CBL*0)pumJ%z{&~)If6$6{Gki5T49j^T9eT68bM4(RtHEb
zFulQ%`T;(6NeP>j)ZB(A6j4!;ks$dbkN=BgKfOR$KkslWjTqm6ib-8fjWGfpY;FI*
zQU_*9pgbz6s)BVXYY1WjfwiVLA4$(j2-nda(1?J#5Y9QVB=B4v`q0w`b}nE3{A#YV
z0dispJa9ioLs0fU&$+nBBPGqWv_$>U_v(XdyE6~Zgx#yiyQ&=-ldHQ6J}0o?6pwG+
zh`-6Ye0HE(M=!n`Xn+@x6{Z=50(p!BLox&dd!1SVkEO&D?q+2M(h_22S`ooT%13Nl
ziav;C8I3)z{Xhk%GQI9Uhm>81@u(PFw?HdrCVlQulAnSa&Hs$62T!LY$Vws#XPE1a
z3I?6O_9OOAC(N7qmlkH9doy1!7HGIl$JDH#I?;Hph8LhlbINaF(zc)v9x0i*g|e@H
z-u;<v%K-O|t6GL5<zGjdqBkqA{`Bs)NeZ&9Ik*^up%KE9pNtF81y9P#2K{dPDEZ@<
zG5}u_O`bTfGPL*x<Aw7NxOKZ}qO9EvU9N7XB2#%Tuuk+S#Z^v$|BWC{IsTMj##j7a
z5CIMR`Y^rCCC%{N!OO+P1%zvsmigUQ5Vs0B=qoUytbA24vjG`0?p7e~hG=0YUCvY{
zY^Z<{9iT-wsazhE(&N0TJO-pfFzx_na4187`S$H7^+45p?F@C+%m9dg#lP?C{)+$X
z<W8>`t;YTOXO@%^os`3F_j(RdL*d@r78C$W60Wcy3kr5NXq*QD2rWImrvDBU{AMr3
zJx`rwq%t8bxZnCEpW{=qRWeYHDk~{L1SA3*7nf<A2?eq7y=csi*S&XdclQd;El4>9
z8L*BHi8zlnBQg`PnG~1Ld_Ia18^0^McVO9#7`>A}q2HPii^|-<Ei+~jfdqgk*qG!x
zaPaPb<;uGLXW(bO8XKo5eP+G<f;q^BCsp1}`{-Xz5DsG;oGJg}fPaGhSwu9}N|APj
zLf_5#Ybx;$1`|1=W5Z=i9}A<k<KM_g6v}t?{pmQK?3qcSyIhp#9X)7e*p!I02WE+#
zsp(#PD(}1&yp7E~YCCNdZ#&(6&#ga5o~-Od@f$91f$i&;m>LmZ%fAvT?cI-}lIeI7
z>eTdFPeYN>Qn8l2ts?AOFn@DsM;T7!s?ekp8T+FQqM%K3$Et9GQ7dhVF1~|XSn^|d
z`iP}3QA3Sh%&98QvM(uodS^m2+rK|0$LvQ5-MsDDloQ$I_4j7fzkgxtc1kQwN8B-J
zT)g@>Z<gVp2LCH7EbQX8R;%6$62v#cynb+zT;9ov$e_daq%JzUWc?TtbwlP|=+oQy
z({hej;fNeGZCZL|n>iGBnN!ba_0R}F4TBWB=t0vzj^K)g6-7`xolszBYB~?c7uaw&
z;4Z^;$F5-(+*qyf&oYIHr{@t|7NKos!b?H*Qu1*RKA;<c%n}t71N6>=vkP!-jldcM
zF1JYwT>GtR8jFiD5MYrmD}xpU0u0$u&w5GFA)YrwRClb2Iruymo4mFV5MK(kSujAR
z2*S|_Fa_v2pvy~0O7@E_&CD1HzOQU;owpW5fe^QJ%@U|tO`5$cG)o*^UE8hgAXpnH
ziLeC$o(+2K<rNjJMeCha2Zx7{?qOX4mW)T{=31Kepd<n-8wi9U;nLKUPW%iIcTfaD
z0RkP{MYt}5&#qL@0p^M7tjJINz!To9cyb;GXJ^QmKy+9OLY6OVqkVL#a1$wHZvwU0
zeQOw<!FVD+KP;g@1|Z6AZq-nZkJ(*(?7$8e78ZtWbN}oD*voKpPQ3@tJ$G6Fnl<b2
z>Jg2TgH?PvjuHD1u#F^<60EF|y)+LZ?flN3D-#JOiT-RG_Gv-$5+=A){I8haS+=Rf
zk0>HeyKHLH@OzZiRf^%i-=3m<jf_^E2B|QtvilK^|BEeO2kQ;BTTv(l1|v-%o7Nky
z$C#phkqY~d9h{j(ft0BXeDcA}M-vmy$x<YDOU#`URZBeJ`ndwef494*FRNo+6h%`7
z^))7+i2+(f%PU90UGGbHfR2Ufb{+e=_oLwVXbkkigkkdp6P%@VMN8~F3%~zhe+fVd
zAcsKIPpS%Nl;swE42^f*&>+qcQ=FFA7z#Z%2&-}MqPqXQh?=hv{Ivj0{(El2>U)js
zxqDC2_H$H(y5r2|*@dX-G}nqBmO6_RH5#U5z3Us=>2$Y{u-0MST26>rLr-k7tNT$|
zLHk~6*2CMjOA{A^#mU!C2Kx~)Q|{&?dg&ei(+{Zi6A{CN0#-)lL)SJ;Kk?b|<WoZf
z&eZ);Yu<HP3ql4hi~y38N4ooO-vteuzCJmuVQ4gfG&3(HMN#7Dn!03sdS>P;0EaZq
zN&n*jB!Gnn*pH)DHPF;R#`GbeLsDK28Q$^Fo`HV(ePyMKgTv;=2H>m(Gr6JOzjNm=
z{C|NP#pz%ZQz^VP0Xyg#Og>$pKnBJ-XzY<TU=Xu~f=M$7Zi$efEkzHx!C87y&_0on
zkbs2<(s*bqYZ6BS)C@{QWEl_Gz?Op^8ijm_Yn}mF{PTWm(DOt18L0Z8S*QLRNO_Q7
z46VaG;9-Ly4vK7mBD{VL57lqMuU};r^!HODAf55>B!Rq|nPpzA^ML&oB<6?+3q$q(
z5R~zH<$Zm9Aj$?&8UX6x_y%PwjL6`U%mxl3pwL6F^eXNq7bJv6TY{s_ruGwPN88);
z246RUTod}}aDz-8S%WQM9@?7VE9tie=L=-kzYvV={t1d#cr99>_iDl`Dk~e(|ME7}
zB<WuN8VtFS;|@@Lrsd|g0nZX_gWSgT;Ft-5Oq3+a-9{GSv96<Dfa5eu!2t(UU~ufm
zKSRNMtTeN*J8udkWEJXmR)<ywgWRPYH@Zus`5#@*F*xC3Q{HZUKVICjt=`zRHs>}J
zF2iWoBcGZ@Cn3Br#Nv^_F5XX<JEg|n!Ps(NhX8q7I}kqfJ|U(JeQ>Hug&*D0k}^N9
zL7iy-cT@X!DqSfS*3M$c;_>B)v)TWVbl%}u{%sh4?9CIh_f9rtBztG?Y%(&k_ujH+
zr0m%sqeS)yp==S^gk+PE@m_wfKRPN72hVfg_xBp-`8kOP&l<cQbY&6zh+$%xOwTuW
zoHY7L=JL)bxAC1*!5_^T#)Njn!q5*_ofXgV%NsNwC#5TdNsq%i(b34N8>Q{As1y=Q
z_Oqngx%o=@Hw+Zek{%8FAW8Wd#L!d_42W?imGAlV`+Mmz{I4i53}sq(5_~NSBoWxC
z@78^yKHcCH7$wc`dj4%YF0K$H7-we{EiE4tW2v*sxJ$L{4`hE~#VcfW)WeW;ttWrz
zZ_d^ouY1GNk`m3IkYv%9wamg7eFmYlD5z5QVPxEY9)~jC?vCjkbnV-YUiq=`64%Vg
zb+l}rkQjntKRmuc8L1#vifD)QY2Lnjip3)^|DuC5f(IY2;JHuK)H(L}1DqL?W&w!<
ztAqj1s(<`}{|8qScvI-<=||n@udM<hm*)^)@M|!4!1g^i86FS=2?!<}>i)Ce0SCE&
z17<R}Q<ZH0vzS5bFz~dGz8k~L;HR^XlvF$5SD|Lk%9@0YjkN$g*XjQwYpMdfzrUZ!
z)N{rClO_ioAs=V9AZ_W(;NV}N#RHrk;u#=i8*WmFTUuUTwh{ONt^`Q528p-b*XOBu
zdFq(AB@ey|0wJK+4Lqk1P7It7M<FVx?XQ7}UTYAXz@T^t<l)rAX>fHJf~^2tC&0ub
z5dI0kMHr%}vJLe0)fiO*+56?)C!E~eUShdm5d6RS#=9v9Jb9{Yg5u&POsSAg87l`%
zLg$9XXqZ#N$%KI6`=c5|=*_@;edpyjPcg82U4qwI*3OPSt_Um!@XdjM2_aQ3Po6+B
z7~CAyGg~mNVq{zdk>Tsg%5J_t*X9El;KEC!#KLqt1*V{IAEnwLr=0%6F$;57$PI_I
z63G90$fXbAEgOzP6ZLOmv<_zc!u_9{{PF$=TMT#y@`L?9YWgNVMGX)AuD=ZaWg^1q
zogp*7fb(4Uut1g;P~Ed7-dgVG@r;{#8S{c#h~VhOne7t~Zw7xw;@<-?k9kwfH5mVn
zgjo#Rhf@5&Aljx)Y)AcF5c?}?EK_Qs1(}XWqpPOq$i<K#;raGiP(;M{?;jk_XYMzz
zAoa&ovj74rG9{vzB^az8b@s5#Q{w-A`Y|F{ExD##L64dIOWUiHBDF~|>m7V#=mf#$
zQhUf!+x#Y?Yf+Az#yLhE?Sn%YimtFaA777nN>y~q_+Fd`z2sSYKbC^z6k+HR;_ySb
zTgq>~xaSG3rxtoG;{FQ1FY42&u3ouDV0_vyhjbg5a3Rv-i5!Fm0WJqHuTY(38@FUT
ziM;Ln!J_18Ws5HofFJt;{kM%QCUG-k51y}T13QL7X7U2LjGWE}muCfu%2^mg`%;Mo
z_BX4-Gepqc#ef)YXS$QI&@|jy(p_RTFP<=SS&;5lnO#7)56T+5Da3QQIatfJUIYK3
z!2I5owe`6+8*F@_jF6KvY4k=y?ft8YhR~K78yt}E0lwpFumb?6>x>9vm`QQL69Vy1
z2d4l-`8eZDO+m5XDgwP(7umJX3UWnq)XSAvsJsIq3IQ5f0R18uh+~09yh|3T$?>(n
z->AX05G;dPrzi`*Ub?{NOT@cSykMaT8!dqFSE$|P<6}rw+HSiF2Cw2YF&LU54cJ<s
z#*pi^u8IN!e)%$W9t~XS>88G`@`{QunS@&$xTA|wt+02MS5Sb^ZLlXIvB87boew%=
z*j?tH2b>T=10B(UK)_G4<xP!`872imL@??t)_x5=xCsw?%w6yheEuxQmM%)8@x}H%
z&;l}2QWn6S*wWJX*y7W9Cv^^3XIV|Z$ab%~!_4%?{tjeeXqMW{HP6d$Bwi_Bi%|z6
z7(i@2UCnnnU02xVz12d2&n$NDoAE~>&yUmJ<(v)an}Q=jBs>1ffrSPqS7ma#4l(Sq
zef9B|ar(fpW5wF=$h~w6J$xlLN6V=sDd*c?`G6wnFg{!qg<Rn7JpW0-N)|{gg^Ccc
z;Eha8a`ul{ZpdX&U0gJX-`3>ZV%PZV<MXiF$qjLvY4F}<BS7K!MDT6UY=k(sDwYy5
z)WlOU{IQfo7+#v05g`y{<Qasa^z^{ks6<6aBOKNj3=e2$!`RkI5uz`f+v-Jm%=n5t
zEC)A3M)M(J12rD6+Gsd8JPf5;YePuqxxruB`q9q7p|&Fp%ak0IwmcJ2?B`Wh2yks^
zy|xWoAWs%49SuHwytB7_VM_Z^NqObP^9kiv<;g;z!oB@?l(Y0R)P`Y#=rV@@(cbXR
zYyXGz!ktg`59@F6(I5&Oko%2=ALyS;B^KkXX$R>elF<%zQ)XSYTAtoS(%>#zV|jd%
z4-6i7{7w^9&V<Jc9Z1(|YWIWAgdV>9J834hj0z8Tkv|0TS}kVz0ARUsL;B4K3JSTv
zR~44FDY$|Tmc&H6Owx!WfS4Z@W8P@aP8J^#9&Rm=4R*o?8w5p?JYBSUIT8CDBJ|q*
zyl>frjrcMftCg7ByS(R{<v(TW#FBuH83Dr)!Smy8f;7C-E?^g!XB`64|MF7jO6q{G
z@7ghCfLgBo?ba=`$-}FfAH&I#&L@*?Mp@lF{*O8~Q<v6Lk3sJ6WUTHe`|L&CH?b!5
zCpy2pXjKo0)Q{H!UdHHmBh$++jAu26v24()>nY#pN_9QfE%+S%hbUzj<=5iaN&C~6
z!K<cj!b@yl$5THcvcEx3Zc7-WTu6}@D6q%bms_D<@=o1AvmmXSm6}ADDkpk#@XW=P
z>P+ndX56+<nA77T<FkngFVAFvf^9u-pV2<Dgh`I;$w{*ls?pClg2jo2(iNr_!=dU+
zpH_epLpn7k4Y8TG3+82R({e;CoS;m5E}(`=H$G6C(&Fs6@w8NHQMtZK`QI453EA7S
zLU{^~au0=z_@dDbT`GciM(e^%G91q?i{^d2U-)eOrdn6XisXJs*&<+?H&|vm#QSh(
zIO{NLeTzVp5fJa+lMAbTS4zfhT`ddVN6^!seFYhj3B{|*>Lwf$g?IEwONM5&c#~)h
zg$^6f&!705e^k{vH>uePY$$ld(n!(Khm>jngkK*sLb@kboe<u6$giR4_4LkS6%a@}
zyz%0Lo8K;9&^7shhbY?8p{~Do%|Rouo_g{zO=V?|hU63U&>7~P<JANiei*7dycMgu
zM}*MTp9n3zuMH?FM#J$DA#`dIcHY&tZVbDC1$x%&Mm<`ki=(662TcO&JUq+=&GV0`
zDu?q+T5M`u{XuLdY(35i02fWqyv$bZBGLHTJZkSyS6r=G=i`&#7$eptya6+&*5K`<
z%>k@Q$KUs7gU%pcYw6M|v6A;&ev4R-wL8i))a)@Q;nEp|nrwSnSKFJyYI28Xx|r&g
zh>{Tu;TwyL&n-F*r>@*kY!O*>CeH2VVg1CKO(^C3lr*p9*fL}MVsA-UCF#<L+~(fu
zxQ7xtXw_Zu5Rgq5V%~^#F0#aqhBqh+=qFX9%Y;}e9yl(sZF?hM6$Mu)Cx0&rP~>3N
z>6!jC4{SbAiu7Da-bk+}5h24T1k-z8YjxYrM*M=0o$U<5!>l=2mz>q*;eYm&ap)U&
zjwXBSJKnPV&Bms{$NbbPF#@9_(^{!*P(Bh~d;M44#8Qij1}EOizH?79+xb~je6S#m
zk=}!kM7PGW!82r@?Sy<p`5^i7MvZ5G$<Z*TJe|Ce;?FVbSwlx~l4-7+N$c#Gp127D
zcq_gIJ|1pgvY2+tG>jrvj?B85@^E1p%cRXdGi$jm66-UDNRov}D1kza1aE3}QPI1P
z+j@qt{C8T!)UX_bznt?aQ^X8Dq<o*IPI*KkYoiyWbM(!pZl1sh^RceQFrUl2&7&xt
z`)+NWNuhXAJ&aRE7^DRvv!sMk#NAf^inMXtX9w3yksM+6scVC{N+cAwEtJp*X+`j)
zqR<v|k<2Oo`UTTI&6#z0yhjz#;Zk`Pv@UZ>N0oj<T-Y&uh5zNhA5M{d&DDDA?v}H&
zWFI90H*<}vn!csyvR`vK{|&}Zoi*9Hx`!*iocG3+;-jc;uOXb$Ct6i8q>^#e*4}ni
z6eo;bWDp^W81Lgm7HV?v;EdAZ2xL2b*uD)C=##CbYf}y2pAP-GqfqDO{@lLl)5|CG
z`UAaK2?x)(ZNK1E+6B4GyJPH`$$N)>vwpqzl5Qu&x#DEW$MD6juKJ~H6CtDu5m};s
zbs6A8x?tj<M@S_8(vHuowiOCxq>{svmQW*Y9T;M4ppfFm^rAOZ4B(C{f{sfiztQA*
zSC|p^s|@z1$?C={ZMBnA14Zx2qIen!McXRQ_d%oeEb|f@M^Z^{OjK3pzDFAsFRnK_
zCuX53)*5NbBmuF7LIlT6j*h#RKGiAw_ubz&peP~~QHHQ4)`qPyeQ><6nO!YiL%lRT
z4hDGxiLH1f%o&bJzOX;?dS6jtcjRDZ!9av?y88hhjYdU<+V9vkND(5)n8Ct-73c5I
z=R69ne3|gJRq`UGP1yB?MUVw!p$cJi%sK1m@zintw{TkJQuHz-b?8E;T#<<OW@S(6
ze=|)x4sJ9Gt5q&F=fL#1BRng#p|cKp%GVv&jU_35myyv6Gv7s=*vLA+1E;(H_9f5&
z{Q!Ov>DK9(HDlk9MQmzCKJ<=MgTdC?w{BU3g@xKr>&ZGQq$p}lhc8h=)gtcjw?DUN
zbH&H1t)+;A#9sSxUBWA6$M0&$W@4G1?|(msBa#r8#2Jd=)dZ>+7Sxr&u&M~Pj4mm8
zJ`ikVS~*)^RbJS`Bww7>KRK7@`OhmpZs{@T`9e$QU*aX(8s)#hU>CCt=+YfpkQdPc
ze8o?Fk)N1om{hc{v<oVuQd}%9b>lIy7d#8J5jmljQbM7vBwuMQB(URD-XskyVtTBi
z@pLV7pBmd$6{)Fuvf<b#E*nTN3Xa`l2*pAuCLOjOsH+(Wx*K<Lu%#eSyR|T%St|Yk
zg2vVSYrBAi`|c>sHOOtH7dd^c>cE43M2loYK_MZmmo3IzV(}Cmbf)-_A8K<IDt1>@
zI&{E3^b#C8T7Dx=Kis=k@P1#v)?L@Hbp{-QZRe{$Uc8vrkjxEuhP}`s9iSH_ahD}@
zgTlTRl~j@FBdz$9ziY_mC10$#OkCvC!`H!l>=X+{hG=B8`tn_J2J}^vQZXoqf}p2M
zAIDfJ#-7;BqIZlnuZyCdNNc7j({YC)q$sch!``C(^Yzj)tsMBK_q1Z<_-o@%=7}++
zEC#!@PQM|0zxd17kcJT9Dti(oS%%}XD%(V;f+b}cxn|j;jr|96z!ap6?kFgqwbqT%
z-6i<$$_8<-V<S)t&{QW1Zen2cRG21B(Uy61lU(Yc>|#oxU@8P&#=W|kUwPuRvIRbw
zgO;_dDBgfSyN?2l{<?1He?myK-uT{=(46>s#hQKmO&Eg|ZiTDY0@ngZM-S@s%M`y^
zw*$EUcliph%abd4NbQDMkeQB7v%Af1|Fez{x2<R9KD|Gv>BT)=@NyZw(6GMTc=3%Y
z7ed?r<qrkS#fq7}8i*Ce;{G1O)0-uah(RH37!L?q(xZB%(^b9-%xXRp5v*rb=yS{|
zd{5>ls9ZmU-9q}lw`jxTBezg*FX6xOeCC^G6Ad9XZj#m(8Vie3UWmkMExn$BqaW!=
zG2V^|ZS&b#Q83Da@7mrnZSN6b3$;O82-;6#A`?smB1+)q?V_uWg-EKKT=*D>lLI#p
zPdy{xqw%E}BU)#&u#IpbI~gtu8;wSz2{WT+xKl7gFx!7s;#;&oWi_Ajv=oo5b&m^)
z{!3w9wWloo-Vdh5DY0h!Ao-j6&oB|4D4L;j1G(v0S$0BHD3=2l$ts1T9LyJa#$J{5
zq`?+$#&lnUhW`lN(^{)_T^jn4@=KC(C~T9tjXddN#CJj)wBa`qA|{QY7Q*3+3fM*%
zjKWe3nCSErV|sztINs|*<MJgeuAv>5ldGQdWj;_Dl(ZY-Y`ggQ&4EckHl1!Durod&
zk;XwRX4`tQ?-6aUuKrB~{O-xN;q>$b$Z!ky&AFVNC{lA|twq57KrNIy2iHO*;V3y{
zE{blI{l;Dh9p-@L7wRd+f-0&H4z38q&`i8yX-{R_4G+ezMRyH!(x;prp@=B_<cg49
zJ>Vs=zBpNqYV!8tB{0kW^0K?kTx01b)^Fd9!v~<X5o_Yn<Vbo(X=S7HFk-{XAK&#V
z4DUxN=2r`M6!ms?zFw49G`<fQQ$#1WFBM#KQEcw4Ut-!T7VaPq#SnMUWJvbTwTU;l
z%CttvMFfK`=ksiFf^W6-9i=4{4h@VM=m!6NMx;AIAfhmQ<ru%+CgQhm?Zowf?Gc)k
z$NRm{vB7$60m?-uD&M}pa<DdeSio03GZh5(pX@xr(u-26m(eOHAt;+04+kqJK6hoO
zuwi}wpiCHm<B}7Bf|s+6Nu_Y?6<efb#fTmmk%F30&+q_&kD{t_hI;*8P@rAc93f#0
zN+vYNn^kLlt63UB9{bi;ncRubN_#l$$8!oq4RFr4?s_v*EOnaXX9T%7{`)XkSgd1d
z%GE4H1g}Z@*@ZRM<0r$8;ihW9a2|aa?)Ug42q{Q#a4r-sjh5tG{ok(7P)blhvz~n3
znCi*oZyEAIJ-x{o?iZUkNq#U*KQZvZ%9cjg6t3+F3KH$>%j%22{3guJu6`)_;xH>9
zZ3l-GGpVBHsxwSv-+#Zg>cVVico|)Sed^4DD)UbOEq5Y&5F5ujS|Y)^?mEAj2nX6n
zaw&A|F=;Xs8MfgvSz3MChQBgH%IlH@Dy&nQ44qjkn*XqLwwt*9R|!ZtZ@P(0$)L=K
z<Tz^GJH+&QLX!J!|A88(uMb|>a&GUCJ(Ur%DWYT5bX5l8m=`tIJvk8oPIqwdyo;CA
z@b0nVGr|nEGnTs!R4~wYpl|@(xqHDcDU`4H1=tT0nrxA<PR~-+*`n`WoJBn`Aej1T
z;oh++r-IK|hQf`}+%L6^MRQsrsr=KqewN>PI|SaBllkid^CSvD6KQF(9=}e?N=$;a
z+KRiHL)wZezC2&9U(tAfNy^e}<i4)|#8KKMY`Sc2zIOii_p+0Y0}n=3R5yVFjU|D%
zv|+U<90sU}KlahGTNd776a5Pa?wnmC%&-x@qwF20&|r*j$+D<uuj&fkqny!x$ZoI1
zGN62{x=_YXacQsoz}#1Ra&%FUS)Jjyj%edzENzPTh8~+-w(i{or6Udw4iOL#X(B_u
zS3IcO|Lw2^+1mYkk=>T@#Vrb2-=0vE%AeY-X2nbs+HV=%!Wz9;9KmO~=eqw})FhS=
zEoTd}6r(Yry+Hf?;RiFUe)Qi>e1gQ0H4Ha2UjME_Y$B$F7C11}MDZsg%pQ0Y-w-b|
zTOuLLIQopnmD+w=%w$1QD>}pUtw9d2{z}#oN9NUEGCeOelt{H=o9a(On0GrBrf1aP
z8mj+Dg_9Fye#-QI;O8s*3Vl6#r~8j(okT3v_rrcj?`n!k7dBj+>?*OH>?uyIMHYVy
z8^JLVbE*uZx`{+L{8>=jsXBgj_o*QoW1xj*7!v{$?bRaRrJ3O*Iy*K#^@fk<EKnsd
zBN)^BzVw^;x8yNAHJ=>%y}eC{kI&+GoCbA1seIpPGfx)C%7$#47QV8j_kqH_4-?G!
z3dPb|<GsC#Tx87Hqt^-L5aX%)+pCouiN3MD%>ytyDk@^!C=h7k0r=|7vV07Jy@5*<
zV(LESbQgAQAjfNHFn{yCkOMfcgfv&IaT4&hFfv*;c<)evjFTe{6!VD+vZdN2#60GX
zOuW1<77JNYbg^=2DJi>~zrWC3`ux}WY3k|K`Rp8<I8Sodn@H@xdp~ww6;el<|B(mJ
z<lu2nF`&cEO6zh7?zO!+>t7#VMvo(zUQOlWMc3DmSIY0ftjdcpV@62jQ#RnAFsBKj
zWsQUpW1pXFXniL~X{Hgnx$qvZ@s-pDx(ENOQX!r}+lFkKHb5LwlSlF7&^B5mnY%Z0
zi0n27jl-;Ydgg5=@A1n!o1;EMz4XGmdIT*QN1karuSlxaX&T?(xAVFCr$RGx<aJq<
zfpimHW@J}};}tH+_$#284|+z>V&pz!D&yPW&_n$&$?%9aa=(1gxcFwmodUto8N@q%
zzP}MquxY#s>~<Sc<H^eJ`(j!7xRxxnXWMg)C=EC!klDyr))tY~{Fw0i7I&@<F+c1Q
zSG-l)ug2eO%^OZc+_iq%ULEh1WnPFSg<^5My-mV?#!Y5z|G5*k167{h<*n~k^h!Uz
z@k&A=L<{tT9{w@~Gxq8e{i8B9J^g1l_X7(3uuUie&G9$|S<%t8On#X@pESaLi5E=n
zLV1cd88Vu6^;YU7QABg>kkLoL_X36yc2Wq}rda@vAY2Ey+pMwSA7Fg107xk4qM`}V
z>SuyLnD}<0(SD2#0ZJ;!r^5Mxjj*<{;eJ^A88nS8E!PReAU+1`0z_fK{E-kFyPfaP
zT7F0{q}fjW84+cIM-QZu0X^(>Ma7@?Ff>wJ*8jk^WH)cZsz&dvK0ieQ0G+>O3$Cfu
z^&rttL2*V8Vcm2)`vK-+x!W*i1$W+Nl_WsaK=Xqd#=ye^x<*(<UBS@7vuPIcskCfu
zA$pHxD;t1Jkf-MeVUo*MXc-X22XjUGeAu6{rTej>S%6f?zXisxDeC2Dq1{%uI5|P@
z7{gZn>qU(HbzX;S7^rd1&JK=$E@!>)KNa51yFUvCPyY0fv2?+F)nkn|e@8&xmN#hx
zxcOP#73`qC6vtahZxSo>3GF68M{&uE@wksbgvt1lrQz*{-9d`^5PP_r)7}x`w0KN-
zQYdv!>!2akM&ugZzW7TZ($YO#fgm<zXzGImgP<M-3l>7_OKG0yugi`_e~n4NpccGh
z<>Hze+G)#pc0ZsIk~oB^X8FzdnXA^MMvI<^j(PlQUOK=0-V%m-St0eOL+J6O?9;~%
zG%eA6J5d+hkZH8#KRgwR_Ca&ul*Hs#rx9-0O9qF19ib&Dp)h_-Irf4p#Nl{olIp6p
z)s3g2t0bhEnQp}zG708J+De08`H#J|+Bn`k+1O2rFFIGe_<j2g-`_*d!Dk$US%}aX
zTOWMNb7CExyK`BMd%?KR-c(fb#g;m$wY_d57dEdUG;nlWYxJ6P7p;HYH$3lhuzJda
z{V;|0c~I%W#9gmbDZl3wwph{`q_wCF(|ES3b?H;A8HW+HD7k3v#)UFC&XM8If5dle
z5<dO&e#SYxKqN&~Ie5tOtm8X+bkMK|t^rR68=oGi+aZ$x0BTNmUn&&q85oe0k^+8{
z;oiM~DF_4o@b>K{B*T`1o+T?@+z`|Vz)S`0aY~956+)qS4?yKr&HK21GN2WY?}l*M
z>ty;re^gaf;lctoV_6v+i10a|eS`>bPfvjSK(tn=c5KlrDFz1YaL9ZF*^CrYu2LT&
z>LHAlFa|VTAB?s@kpXb&NEu6r#Zpx41%n2pqk}sVu>fjH^G46tW>r_<{(;pkXb+?q
zhBuGk8Q*8E@*j-V61dnWz>c*0_5$ENoz?=dmV&gxJzwJ3$e%w!{soKUp|)zRQcaHk
zupofeT4BSC>8hF8f|uf27Xb@9*tLN&1eR{2V`C4w$PhI5{Xc*<9~Ra^2q+4SDix5Q
z=jS1g{iQ0~=*mZ<N>4FU;KYj1)bhH={d5-gW6LhFw6Kuke3o{P7=o*;1wi2ezh1B-
zaH_>C0UtX*9|A&8?boCTDr#zYz=9GF-Uc@sdKwy_W&*xioNlMl#}q8g*JlCZ`l}#3
zQARfQ@Nj@5<o^B4LG=R&id3g{Q65cmbhzr0Q+e{xo%$uAX!>(Qb4RRPv_^vAcUbpO
zuijuH3J`KSavCyA_;O_EBz1ZI_eaAI5Qon@W>I?-_!gw_T}Pfz+~!B$d!W4V&p%!U
zl{wRlyR^|ub8DDdaWu=Q5@L^uaR%nEMoas-jj7Hbr(Ry-^Bap#GkQ`s5`Lh0JXY6t
zy6btD?p7VDREFn=Zwb_<m{P9m!X4ioMCNd~u#$1wF$~1MWXfui8#+f<uOfy1CcQ%=
zeJWe<7;S`n*aY7pTw2j>Jc_Y{G8^Y@R$TbX{#RXl>-C01o8Pq6uVYrSZ}G&}ZI1gr
z(J}6=5lq{)h}Vt~GYyKeiGF8R-mx<L(v1`}0<C*}Zo-usP0P~z`|I7e`AD~T#6}$W
zkUh6ET{i#Fybu+f=#4=`1oGT7<UC$A*UH@yJOYlLxkN>L#3>_^DIAytx_7nx6NU?8
z2=BvK1q+vkvsC_p{m8OqdkE%IdWRzpx==VH=4Tx}>TP_E%24aDA+7Zb%0{a8g3hg5
zQ|LX20**#d%zpi<8YYDRcNO4$vj*;%C?k9KVC@eaESxBrrVDaqR~i6Wg8g&RHRTGN
zO!!@ZI0cDWXIB?UYk`ptYI{dVN3a@z;Ml6p2tce|iy%=44FLrGLGCKZe;|4l_6wjz
z`(|6r0hdRU@17NG7V`7wM@Ku?4%}$WTl~GGq@+Mer=yeJXN`-8Cz!1YVTXKteB$CX
zU3`GCDj!oWAG<!@r>E6(L{c*{Ry@TXJa_;OsQ+?nA*`H*I|h^y;4+AbiUN0GTpaFx
z=lc3OthS((d8Q)2?GBNKa9iFc#pTHwu;7EewWp_0I0HpAh?e0v=;`SJlKuR(Odm-}
zDQY)JGwKAmY(USF#baDYkwbYE5CAF9%-B`{wg$l{tjL_}({ED4@(%Xqo6F0v5mV0<
zyTixVzIL$X{qI_W4N<QmBA_1zjc8nv?fV~~kC+7ywFB(b;N^zTxy&^~B&9pEJWrOL
ztt}?dn!sqYv#~L<;Rzgjcmd&V2B`+aQ~7u@*wLj$$HmMGL+6EtXa`E#%NHunZKh<z
z?v%$f^udoMJrsUSY-5uElt`gQJm*%7ovmz^rFQSA2s*o1p&k||9zuE%B@vgDexc$H
zt817awTWHWs9P`UQ`Cy?f_Ipvlu$6|b*v6^WJDSptcqWin7&=>FByGR?e?bzJeiQ1
z&LrbolO0oZa(WPP=T4)6?S&psO3VX=MdCMgjsa>dH~Vp;UJoSU590LXeW^`2-`~UN
zhPXXOrjtfU^?XcQM0%{5OW2>tV27x~xXf=kNJ=hlJiBzU_5OHldNlXe=Arw}EGG4g
zMciwgu*ggmr2u;D6mc9@BJ?~`Vr*q>bTmx-?YrB0nUz*YX8NOl=LRy4lk1}Rw=sOf
zTj{SDhX#M%^Re~$l@l;@N_%{)DS;8YIeZ-T@XA^4p{v+a6uEY)g`KeDNBBySOPFE8
zNXuScBgAXh1w%*}{!J+vwDSA!_MeTNA0OG54q|e)f7NZ?k6_O1(GRkh9^Q^S3m5N=
zwT{b(`yJV--8Mn$es93woifi`n)}VJdjtp*wEHab<}190Y#B<Cc9>4C;==2cUv+J@
zS?cDi=T`)6IQWI}gad7aE=B1g=&avVzbA@`sV*jGmSB+;(<$I(n38zjD|<|#p2-Ze
zp|xpLYCd25kEcraxvD4ai*l4$lT}#z9Yu;eYXAJ*n%RMn5npjtz*_6+f!m7G3pjO9
z_ymA0(WPnYBNS7PhwUJwhg^m7G0Nn7L@`}t@lneSAWkMCAW$wH1;tNBRu<d^t~7Ra
zM#4^0$V3Hz(U+;`;)a%OfH3Ns=S{+<>I*sCV8en>fn^tXVU*F?5<zFz@d}m32EfBk
z?}ML)JXUVI<=E^+nQ~f*y;1SVXX<N{4cxJ5V13uo3E7J`e=5fWT6!e9+E|Ch?(Sk2
zShhf3W&8dV{to5_NM(*MXN50%`Ry;b1>SSP`3*5q1ehSv1w#Qm9e^8ZO;H9%z4_JI
zBv3k5-A_SL1uk5`1j-gdu{SU<K!T0VqMT$j3PIIEYP|$|pzy0R$_1enJ|qupPF9(l
z>+7=-#}d+sQzR;Yw++56Jfftf!zLWIHaD4--9cLjnWm?^T}12}c_8u@elpFH-gj;4
zfNzqko&^!Id%ge?H03dHci#svx-0mjfUsUyUk@*<p04iae^9={i(F+^g*7}m*<0%b
z*$!YCzYZsd$u?vU7Aq$Ex6FZGYGpM@&n)AS$-N$$P=18P<Ht|eX0x+@*j*g99G^AL
zph3DCxdYzK&iJ4oq?=l)k*YTZ+S*x+eJE(Xoqo%_jT*-7lZmw!O>?l!jf`|DUKud0
z!&;DILB|ZGuOV^$)4r=UWu#2bN=ke~CjDi$$wP_bjr>;v+Ewp1=<R@LiF73;d*kjd
z(Gt7J_wO@FFG<wK?Rb5&w4)u|Papp}&Hk+W<X!TeQXol#>{~y6$Ss3Aot-4n89lwZ
zUvwAi{1YB9yn5>DE~G`c!MQTbponb1_$2Z97xNL`y&9f|2n*bT-;s)Fi_~&H@xznv
znD3y5NmQW*p>-2gD06U+SI%&>y}@anvn(F6uKVasNGo>NbDaWlmrQWt&RfCvdN`ul
zBy0Qlz5EqY9GoVBvX{-JJhJ)k+t^(Omptx>1a7ycrLo8?_HFE%$h&2iX|rA)V$oYN
z9sN3+PMvl!2x=OdtFN>(X81LxBqz0k*Mzsm)Y(oQrI29Bd)M2_iu0pq7i~ei6zW&S
z-^tJ2xLuE!4{a*RbEVP#MC=}Q{VON6)=juQr2c5N==oUjkW!Pv{e5wIZ1g|gO-7Yu
zIhEs{9Hb7;&T~yZJJ5(IrHO0&Kt@}Fv7M7MZD19ohH$M3Qzc%%=`CheV;cY;;mNv9
zfe(=qf~2^WMs>jXg;W%9FFcuRe#nz`og)l567chc!0m<rPvmv>id7A@b3@p&NR8q7
zpZ7!W3~Q{Q76bA#s9#_3KT;46^93gjq)I!(scdDnbnU+z%)LHe6BRth)P!y9?5Goa
z04W3FKUi!Rk4(+aw}BQA90=N^*WQA0@OAzD`_8EDO>OO{)7@)WJ}?b@=KRVhH!CYD
z66Babh5Pl(7vF_2EO-RK<`rUf6nbA~XN!W{50dPz-K@cF^irm#xp2DMixI~{t_Xa4
zTU%S8tU<sC0)$a^6bekK;-KOJE1w<3FK8d(F$Dp^exSny;W5ZHA<7tJFCh?R)Eg0H
z7JRx2jyXaiqHEDIKfjxW1;gB(0q6_=c3{z$aHw!TYyCUzh~M>D5=JF+pFGM{*&b2!
zIM<h#mD$?ZKvfRaN`+Bf91DP~Pr+_&4-BVAgzb}I{8$$FCxNY+970cwmO7*C{8B}7
zZ$vM$m8%8&Z;w&cD9AkEsr_+h^~8IETo_k_f}bz|OH(jGDd9_)m5Ht~@q~D28vWuf
zxewi%4ZDKaBBn*?6~ouulB^O8;!k2vR3_Tzx-bUF2G37@x_>*a@pTIbcK`U1KiBa%
zV{_fL{-bX&|7i?WU$;XaQ3IA-#;ZZyW20F|%%L#+o9=b5l;Q$Y!_3Mb;aS+x6WbWh
zClzCIcD}z+^=deO|6(eVGq6mx4)qY-#A)&O?T)7mc&#@GNy3k+uPC3y$0pRTcG-B?
zCe!Crdo~`B4e?LhxizNq;q-@K$X?69W>kE)$%X86cuw^IiF>0+GzRhrtMTqOg}Cdu
zORY!~7DpkHK@OKynwVtAulnpA*603ob3R3La``cYQ1+)6UmuX6E&8>BoU}-WJAK5=
zMTo|BhokM$!^K((YBZ!x@nFjPp^4*v%xylAH1dr_MAMT`w&sem`f$CpD-Q>J5L_rU
zd<9A|iKZft+ZAaaQ!tV|+DFG$VQjtmi6oUTvYog@GBoY>&bD^!<Ubu53XDlC-cWWe
zAE{p|Y<k_o+`N7(JZWV(X@|#zaWApnjflF^ta&%}CQ_5<lU|8~2_I6zy_;rb3ae{s
zMpoS?zJKR2tY)C&^%R4REy(-e#&R2g8gCyMtgWD7P)@^-l7V}u5pJCd{mr(^qbl%j
zJeqi;hb|4l124aQpPx6^)`oy16mS>;;~y19CeZbuOFR8+;GYW)+z$EB<m>qjqETF$
z_W-h?X>J~}yU@X&=esn2b?F1`U?BY`6S`z7(5S;0?)pPA_<UpS=Z_!CTH|nZLJ7U}
zq^Bzpvb}XV6Y(x#*3wOa21xc~fVbwwUz3|5+(M~TyL{{uh?9M#fNl&GG}k~6R_8&p
z5=$IA4+zV`q*5|7*|G+fQ?)?3b^ktXs1(EVyHBPej?1xr2BL<vUyGai!Ce60WjOGG
zsF2>Le%udsS5O@1W@M0Jqc5T8LLdlysFb>om8tFB_sgSK8>d^Ae0hDdTt6R<j)K&O
z@x_VSB;i;N3g-Qn)!incVKr|M79mUFx?IUNPDmp5luqulijV(tM3R5!)_Bk@JyFqJ
z+sHJ=8s<OJhk74&I<e)`h%2L!ai4EIyUTmK@WbOhJdNP$Umc$`E)5wz<xCrsD~mWK
zE10&I6NZja25)~NnOIJz&p8i`Ypq6Gh(BBTa6Z&~$wktS`4f$~wGfLvO)|gFbhq76
zj=|gg+ghDJ4IL^<5jL)%%;~#?Uaj0Kn=b-Ar-+~~><{e|sO6YN5}n6o?!KMPrw5Z)
z_MZ7mdJlN3_6#{_@S;n^)V^%Z9&eJbT^$bv)NgOkcrh#yA*$;<{bSV7m5EtyeShrf
zhd~_0^SXI|O7haP@rXz&D?rq$s@Rq0cxL|cF47g{p<<F@Obi+vgF)`A{Z!ShV`qc!
z=1lR2XlO<K$C@UG`Z-Bc64=F?MUwOPY&2eDJzDo(>hcx|e?`kAD9Vb$(ZMCJfLk(<
zB1&k4_@o(lYbcSU!P)n0@oo5A(r!p`NAi^Pr+Z%88A^N^LA?ZLY2hb%mvbGCK2+$^
zpPBy+v7&+Y6iPoRn&<;}I{-J~{wa7rJ-_+t@}HgIC_*G@S;Se_fL&NPi>0rDKNkiP
zX=zNPxIn3g=kN99HXmd25UwJ!_+_mlMCYQbc;E9P4p4iM#jkzM?m7tMqu}D^zHh2k
z-qaKT))Ppsum9=(0J<Ve%S9-_%2l(8g?}vn1G4-1=}^co5od7H!OXE(xuqD2Iw&nI
zJ0n594j~Hk8GY7q#*2HjOsUvI2MEyHa*^E|>ITCy=!xTwp^XG*9;jV`9kWb!zAgnN
zEGYfKoCHGup@Y2|9a8x;7Ui_P#RKu3Jzp4s1O&jLERkh2vZk!2R{84H(=`O-I{Ti5
z$uTLbsJwurt)G;)fxG1RT%lMiZ_WP2FFy$gv$>xR!$jiP9`VR4{ObyAczj$)zzT^y
z7<kT)U+-)>KNRB4l|7g`W=?6pJ+zn@x?EFEf8`uKrePx`fP+J__gc0Xae-PEoLc@l
zj3^>89539DR57nNW4>UK*{WSyu7f1@Y=u%XAhKW0*|^?qlzG1Yxx|fj(|dEDI@NJ<
zbN~RAs7*TY-Ij{dO__x~kvD0%%knObt>|`90!^l!u-B6pS@)AyrzU@!9VvYEe=T!6
z74?#Le;O6Lr~P0djJD;(4(_jUd=hO<s;BzQy-yc(UJZWEI!`oB4s-TZiW3;+XXJj6
z&A;cld8NW9EOZ=H8`4kIO1tOFOgI01=fYq<DM*z?C51&E4<|0|Rh`VIj1qer?Vc0k
z?QGY7L6%j$jx=TK10&+BQb>jqkMF3Mq0EY0`Z@{U^PMF775<q7QH$NBp%E)UYCr2+
z)?4~D(=W#QVUYfY{bzH}SB4oFy%A+d8>A)5!Y=aCo#q{15&?-$X`Jb$F$YrEvbTlf
z&F6A~$IFG($-GKgLbyq28WAfUKAji*n2wgLh`1svs}7#$51bo=M?8{+FAq!$&#eer
zZ%48yXRCTc0tbw-G_LMHih)MB_mR6*%~Wg9KQsT0Qt&x|(Su9N8+r?H_y6A73Idxk
zxa>bZF^0?ol~T@Ix4?OC2dSwg%IP4kh6nOe{~=8;gn8}n@58^qbph=`rTz>^(Z|Np
zGcrmh9KgH^!wWoIT;DuN&vi{uwnGa7rbcnahvj2_EpyNxzt$;Fa`?9^o}ZnqJSHTK
zTy$+{Y6AARTTcQdaJk`@v7}(TzVHarSkS_xK%xtElS1(=fQbW3d3_yRQg8$`fs+Jf
zSO}iUEj9yW@!hBZ_+(Znb{lVk86<kITd^0Bx*}8Ru+TTR9J4Bo2M;zkHg0inSWx^L
zE|i6SX5{hp2=MLO+k%1~78dQxdnNzHDbyJOh<wvkq-bPa^6GTx^k5CJM|0jYPx5)c
zxbhDRaf2<^$}Kn;dapJZ&S;Ez!uNvl4jg8{1A)JAkaFI>4RI2CAFy8QHrfni`hFgH
zPP9wk{v2)h8QbO8RX>T#-i@L8_s-2u{ry7n@^-DdGK{}c6$yW@uN?VQ@{R`CX#bVK
z8(8k0StNY4!$2d=rO>aTbt>QEmw)rN485i6<m;&o`eNIA(H`<*H3}9u4ZRnCW^9t@
z@Ctk<ybNk|ZVhJV`$8%nj7;*@4BmZh-TIi`k;`LX-4)$YX&l|NYO_ld((zX`X=b|R
zsOuvUN(L+0*MV4}=QNhT@LH;Ai0DoN(0*F-(cJYaoRdolB`h*d{m1?ly_ynpmE3G9
z9!n#10VQ-TEd8Jqy|C|_>I+S}Jzt#PoEts6;zI}DzYh}3U%GK2|NLlVZ_O^@c+JBf
zaAqR!?$8mwiIe7VaYC!+eHl5kgT{c2jU$_t!sY2jLCSE3azwv3+6oM8zjNoi)#CX6
z=lzrK#a)W@^A{(8R<5Hs)~{7Czc9~~<?a#gx!2kruz%|x<|3}83YEl0*IzmWpRcAP
zI*tsE*ieXe+`24RYns_Rbi#AS=atxc()8%>Z$waAzKYUQjdvIDn0Wh375&%!3kvRZ
zC_`;96HMt)!z{qz?A>(#)-8LX{5ulVK|Ois(t&dvG_!)NtTuZ~-C&~H1v_z-_G<vb
zU+u<7LQEGYX&eaOF9BQwO+gDt&>=5jqAEB_hfdzjZ4YK!knVal^(YzAz90(X<R4F7
zWx&bqBA_q;V*?u>U=*;@`LJXS_-sw<nVGdh+i~3tfgAtpw{HY7UDwef;(Kz?c}p?C
zobCG1QWKsfjg^DUf;N|_>JEoGVsw6Sad82GB50qCw&*W+W6aN&$YEx1U9kD(*->1F
zi@M<yLx~3J^cAoo`7S34x9%mna6IdW(5@xYJ;vUHgsa1H$@}NKU3-xWV^z-}i^^9#
zJ3AZhM;JQ5uL#%-AZ~woTh-bKc1mClK*HbYHNk6W?WK_YDAah6qX%S+%by-Y(D49w
z2YlX@Fd@A-JEBTtqocpsHccv@m?za-Jkqv2fL)9!Yf`MtLCW*6)*9w9*Q=^8U-+_B
zlO->G14FOLQ@gvn%gK@;W4U}efBp*)4IcXX->-jeV0ZYySqi;M2m<~vfSm#C)N~CE
zAM;Vn0Y(KLbkGvXz80sP82<V5nuZE5{Y#hD)3~NuG_wUk!q8c|%S9rhUaOyJOROr3
zS!611!A$scbK%D`NUL^N!?=Wet8>-B)BbS%$h#I6?CP1OU-en>N{oUBGrA=k%nj0b
zk>)m0cL=m67Es1Md5Z*|xB~K_y<O_eUJu>m-TFIIW)|tyk%@76NnG#4Eo?}jc=i`c
z_IJbNfu?&e(bhedzVKn*|DuajPN|UYH|2O9X1#dJrl(tpJg|l{Q45kO45PmW@txkd
zhdQ80u^uH{>R__>rZgiZ2}5Qq<ZM@OV_-tkT5OKAdOC(^GFReu$c`cwG42Cp6{!^K
zpTin&bL3Lk%|}sF8(`v=Rga2jCzKnyj3r<AyCeLtvT*0woH*;&*J%tfoV*wD-)4~^
zud7~Mz>oFFgZ#JZx;rYOmziWgM)M4*VxKZ@ll8qxMLe-lcqA9+6JBcYiPgeq8Mj)^
z2hXhM8V>G<lOY;@4<*Kj6}^HnGI&dQ0VnfecZ)Z8FW&d(0Edv;5L`bH0aqM%<VF{C
zIC7E)=H1#_cW?#4hgp>mG@iw=-IL}aL0(=*3kwX=NU&kMCBA4ttG4bVuAiYDx@k+%
zV=Vy8<X-k>I9slduguI$-*XLk=86+uLfFBz=^w^N{r&!@pofT##>WI8CzSB;1##?x
z*R>WM9UTt`$8)%pLqa5b-M|w9M*t)+g71SR4KCShPr2$}m}v2uGz?n{Y<M>2<j^3B
z1<$w!pvk_@a5byST5bT26Da?1NZ7vShzdGegHP}}vN23biY>j{m|Cr*6&y?e9-z8%
z0oB_B-j?z2-^pU-;J|_!l89cy1XKV}`Zmxw=<8>yl%i_t>K=CD@xobzff|;UmgbAQ
zv+n-@;A`g&y^r1^u%kM`1ErQPaete!8L|xE7Ao^dpcdW+<QTU!k|}k)o7_BMAPp#N
zCFSM4tPy$szhC>R%fJBzPAL{*9C<Bh{K|=}6RyS*X1l96z-<C!LCC4Pp5Y6Nh@5~a
zQ#D_r<<+al<0vA40Egj!n{{8>ZBN7{d|m71S&ZX%j!fPm@t}J{%oNs$bKkRM5*veZ
zt5dzt3msQ93JG0}cTb89`|O}3Q6p88A0>A>&+TA1zsKK<A^XoFE{ypWXHE0tk$H16
zhi9m<h80>`oo^*Y)k0YYsS7*!zCw8Bin~kjW#5iQK+`{iwl_1MJkS}GG#gS-NNqds
z{qwG+p<cG)zxyk3N;L1^20nJHVb`s%7Hue)L?tvq@#TLQGlr2I3>i6PJBQtl9~3*B
z+ZT8eoVrrzRk88krYW(Wb=u&uOS)IhI~`F(N7X*KO)_v0c=ZmAa*TaMJ9f|aQS<kg
z#Z7H?Gjz)}3OqeZ<6?P_iaXlt>&M>(Ea=y$Flz_01?8Ood2m)+8G@i0JUZGJKhm9;
zt~1qld^%W$vC>DEC{Y|K(Yi_3Jc}QNEletNSgKCGEm+VI*>7FakIgFYAFlgGco8Lo
zORn)Zo;erlFu@T0Fem06tXuc^JHxLi(3r9Lv>BO6)O~kv7%^>}SUga%$!21Y&=1b;
za6%1R007Q)fKHpk#2YQFg^CG3NNQQz>Kr?UIZyG3YM!|0yBR^Tn`&d85G&QZ=gY&}
z>qeIhnFtUZUfk65FXZYt1O~M^xw%0rUv8u-2|534@O3n*^oHA#rWYrwa|CDO@bJ(#
z3MH-xoZjFC92j6$*5)8h8jM<lg9F%K|Kj53dzojC{DT7P0o2hzcDX)JD&Kt^JF|o^
z%-n*gLeMyDH!KrEww~kUJNOcy6pb(rSl7aq$@hMw?`o~q;}>*lGo>6VRg)U90djuQ
zt0B<J&tna4s-?-eB92^jVVnMp5k@;ZyJW%~mcF6+tTC5<%GaoH)%!aF?K#-|@r$G?
zMg+x$ki_4Uc{}|7E^ASQxjYQ@!R;UcIi0XJLI4eQc@Jb3Fdu}-THn14*m+s-`F=m?
zj9-H#_x<~dv(E8`IlNi<_Vg(%5A{-WO2&0o44i9*C_87qEufgA`#)`q*++jW$Z%B~
zDPg>zE!#jKOaCYoBSda}#m2qiCj*X+?F%M$(~3|1(-K{Gyv~+ThZd@btnYt{Ws%Aq
zqk}m{gTgWi?gPa0Z%}g))CEMu3uMv?(luF_XNInRiWqwGdwK=`9<!?4?Gbg=BX*UC
zv)!CBrZ+k$f;|w3B>chw6k{ZQ%ud0I<va14S+;uS>0@Xl`6tKBwhB)%MgJYQspdUY
zODPc-)vC}M5r}2l8ojM?5O|zvT4V8LZe*;^-mcvV1Bn-vt(n1q9#^t5zDMFm$0G0G
zf#+e%jqHEdnr(RXciw4sYfVBrc)m5MJYU_CBFRQW47=%{&(81p39BcJv6`7w+EnNa
zSHw<EC&j+oNL!o5bv}QZUByL$G@tj&(P%%7om}WL9;6huuilf-Qo}RhEwE?CR6^2Q
zw#O>H=Ifx0uNBuYAXh#6z9sr#4axHGgB3q_7LFWwgExdT9_|~vc}g87hkRz8a2I%4
zYNr#Nu!d6g@O`x9b0rq{sH4KAgKzos!Hs4Tp@v+)JjI~?k$$EEG#qa*TYrG9g|IMO
zEE;*@pQ@{O#VfT)?>Lb39$jt>eQGU#*<FrDlSt=#rd56w<loM%HU?XolR=->v9U2h
zxHuqz2hOFk{Es~<$jIHLvVg(rS%|R-?<i0xK0RL_q}bQXiKTygesstBE6Pd#jYI{Q
zIsqiC6{5kCGxe}E_4V~3S12_#H8b=3#6)-PpLLJj+8=EpSMN*}?@*PL=4K<1gn}^f
zh;u(OVC`Mtw8C5Zg8X>g>Bf0kg8#yVqqZ&KthLwTc32~Q>l2DM5iNvw-#$<8Tb=HI
zlYO=G59R&ViTM>PGT!y*9b<1bTxAQVc~1fe?;o?r>VNB|h}9Qd@ziej6WjlHar0(T
z0={VI;-Zvn%X`lHlh=D~lzWNim6tAS8*ambCvA#X$Cbb8|418$k&&W=jE6j+)N#kT
zxyVCej-E@n;;?&+iKxcta0hKcF407m<ApI&4D|s4mshp%januX>{88Q-Cs6ks&7@Y
zPhR8VvXYve*CzXX@jb6{F;f3fs+K)`x%j<RgD~>`T<8RkKBsaVVSqTga+$tva?{4(
z*IVxqNET&Wbe-0tpzLkV`Q*lWv$p}8RT5*^JNNAJVg|gl=@o8i$6;6@l2RVcx3|*S
z4dghLeAyfR%zNI0K%nx|P|3s)7&lt($<pb5LGH&CT4r2w2-0Uuwm0yOo`s;Owd|J3
zVisV{5m2}?$)s3|D0^MpZkv3dx9GJQa7@G5x)mL+7r!jiUi&$I^zEuh(xV@OcU$*o
zcN7NSDtYMdj}1Q5uz&`%Tm#MA@$rj6n5GO26mzKj2U308&>+I&@OtF&;8TIK+NVRC
zyim1vM&fV{02Kq42&rUOr?I?_3Ge<U^Y`4by1raSAQcPt^pJ0+|5ju2rdhQ`2XxGA
z8hJG21PD#w$5hn@{}7>J=G1eVcoV)cCRr)Fa-@(<Ur#S$A@DL>1*NwpYs@`OwTjdp
zWlgVDgsgcYvIULLFE)@PIH@1YbwQCLE0p)_Sv#6n^^?wp;O7n&_E7^&t1?ysc9#|V
zGcFnItkz$juLv7Aef(3=dZljUUs_K7*Egt(P2OLnYt!+b<Q!q%F(r426od9H<v1((
zU~&@~6N}U0A{k@DSEzhKq#}XCcSQ?JxN5kJ(}RMs+E)ZCpO|f8PZQht2H)_d3vqdx
z`Ma<=lSE<5n?_iMw>!xUKfv;@ESgpzK`HW$-WRh_N4@j)3ZbrSjBdu~f(!>tA913+
z8=`MegwIPW)Df57L1wI#u|BiSn)P_!$oFsGAE!zDB7pGD<uYyC4_kYO1HzYb?ikYA
zGO^9SlU&O6)ZGXVr^SpXvPI<|==UGyWB#)D*spR8&0Fjk+@g-eU2V{F{C#;LtfMpQ
z8k9IQJS5jygePjm%{{29rB%e`Hhf=Xi590PT;6}^xLitQ8E=<(sGU-#1?NuJ)O3U;
zFRGaqS(Q@gRFomZ=P18@F>5Y4Bb@QcGu7XgcI_zZk#@9ajSE`gnZs6QO!zn~#7dv3
zCeq0BI1N9hkZPun9yu2)XQz7a*+_{;-_S7~8}29;Tg_&CG1lMzZrf0zYBNMF)}Vyy
z0wRc-d`ky-DWYWDCU}z+JZe}U_E0RVP<S9(jeyYs8`N+HNFEy>9d$ob1Qio(&j6tX
zlMab|z`=Cu1@JaiT@yWQH_hL(IiBv9j2R%DKJNb8Ies#8S5BvsKH*=8K*wq%8Hc<;
zwx+)qE#f`BvHx!H?LzEZ`tpLdOsAOEE#V)tl`@00=B)+86)jDpzp{yh#7C?9S}iCb
zIU3e_?8n~RGAiKZ{`%b8eOjkPH=*rc=GPxORn|AVzkgr-vr!%?1JzQYiT9tOE6*d!
z_5-F*OrNX*Kd(J{O%cHmRj}LacK+i>T&K)471j?wI=8lXmX$a-exYFBS`@zBc8fS?
zHizDmXnTE@tt=M*X5Nd4O+2Y|5pmBa9%9CoFn;hRlDgdy8t>X@e`lBU&9aZ^&05a&
z^j2h6GD<yJ%iGlVSPE3u_kQ|64FJuzEJZ~QS%CEiF-Dv1;$+{>U_b3}u3L;=OTHuB
z7*Fm6U>02>5N&-+^;0tH^(`%cQ`itRLTA$Yn}IPKR{0_!XKB+pV}rQ1Y-q%GEyjc}
z*-eRoG}rmU94Gi~_9IFjGRK+2%l6bDv$2%duLmb)HmUx2Bpzz<zlcPHq8GT9;UlFj
zeu`9TDrJ8woT<$u-;9@Zy4s!n?xPsU98a=`ar=Tg=y6TwdRH}h(?9-ore-=Vj1Tn;
zlMx(vb1{a`ZETQcI%D(EyXyGlGPC%0^vzr+&c2O{H8|OPL_G4WU%n1omv9^L5g@qJ
z$tq2VCHV?V7(UgSRJ692xb&V?W(%@EAn}ZjsDmRyHYV9v{R0`7(SDTKCO=$OlHvSV
z3vcCN5Vt)Gq68dtR0zaFLqmgv5G!#K04&1#6ISw+i3%^uK)hhWGx_ZB2+}jsR~AZ?
zS<8*Dy1K%MB>zZ$=q<$|kL)gU(GM1EtqoD82vV^7a;r%ttStt=K<U-zDdEs>v~uc(
zK9c5Ql&}3X1r~ziRDRT%_xmu=V64gi8G2k9(SnlX-5}g4)z7M(l)+Z|Z1!XA!r7@E
zjr;>vzxXv1vt;Hvf;mg(&_(8>t~<TmoX>`wZr-~2ZcZ8@lP$xcvoiFMEu*i=JIHBs
zt8LgbP)PJ)i8c<(;gR3w=2m_l3uGU<UaS$VSNqUViH%#^KNh0z({*#~-~HC_7?2v%
zvMZm;(9O?0_oVA7Iq6f+FPHTFh(PM@G~RQ+?$G(@LOS1ni(8TG*qEUh(pf2bu{N<$
z^2^SqEF%so+f5ft)GMNcBNOG{hUlgO8a%oP!!#)f(Erf3NH;P6*^kUIi&ZFA8G6&W
z+`7d2Hf?}S$?NR=bW-^ayH_hKRj!<em-R-F?W50YHQpbmn`Z9!FzR^R=T1ArQmdqO
zTw}i?$EhU?!E2|BjK_*ZFqU+(gz3~)ExP)Sl_gSArkOS=urT>+gWB^EAqC+${v`Hm
zUflz`sdyf&zXVGuD4B@x8v^S$5+k<7tTSZZBkfyu6*^uZRiiwAiavAaB@qngk*h<p
zN-rr^-1vJ$ffy$AVbo>hV<)C)(=-$aN$s>IW7|}5Hscv{6tq=63)GRnoyj4{lX6?2
z`s&M<nx3Cg@9%wgp_~d3vG73W`Ww3ZmAvB$ZV;C*0k0oDG^z1*zg&465Y$8QD4~k$
zdMJZesZVV{1yV}7WOh>Ahn3$)G$438XrVm}LQbKjy-7+6HJFJRulNwGN$P597GKV*
zsw<r&<jzh1KI@%tD((1y#V&Cu8FLlWz~$A<J!|}1^@!5o)~44ygBUF`rQlnvV1@G7
zm&j)|=_o{~DfLXpzdb#i8y7@T;|Ugde9dI<NvC<m6>#2*_?@ml7w}S{sAP=zu-ngI
z?nY=wkfK!~UudR}#7Chz6zpl5IZF~{t;XhXx7+&bf;|M2^xs~#yt*3BYZi@1@!Xz5
z9-X38vvj1}wV5j{Kb_w}(?%Tr^@r2C{MP88!*Op7))uvxFqB(WINCEuQO(*bA-mI9
z9`u4mU4%EH6a;U?r^F&NW!|Gcl<aJ9oIAcH{xrIsQ`)D~6ziWZ%is1U!k|-4LPmx!
z>bAxFdE_g41}p}dn-6e%X5E%q>xO!)6wUp)UHX1D8q5pOR6Ju_XEHPYvY56(a_6C+
zs32~dN^dI5{nbl)gc8@MqObt9E|ey2o1f@+sl2GqOl2<+;~NiyUq;17DpEPz?}`Y1
z`(t!&<qpA^m2&t;Pu$Zdu7A*%xzWEcj*Ib2y{&L!39pV}rOf%eg&QLaG7C23Y=c`0
z&WI4})M!g-$4`b5zFRjRyc?`qM5Pc{%2-^-o^$SzM*E4PO|<8`{)?fM3I|W)e<YoC
zJl@~`#&6uZbC}JonU3jcrfWXaZ4=Yo-8CIk(_@(K&Kah=W4gQjj_=REJn-Os-sha_
zbzRpJF^o_Q5r!MbC(Ydc-`^e^|0=9Y_#da=Ed#xfgSA&JLgbLNVt-)AnVhCu{AVuO
zzq|KNT*{w%n3F1oyW#ZStKkk)hwJ0jCi3AUg?bi+*##bs^nav9sz8-(n?G(^%~_RW
z3|xdZXb5dWBH4SVL!RGqJz&-V+E36xgP_e^wfWQI!!YP22J?=!EZ~Pc0dgWYF$U;>
zVqnPnO9=E9V3kT=itbzIQ-49$2h`Z*$II#Qg8tT<p-$J2W@PaUGs;^quQ?m}#=YLo
zm-CiZS-&pry}vOj;Q5)zT_t_g-YZ^XY$Tx4qwcS0B3B^V-+fOlb&r?&wc@|}lJvlV
z0^}v0k(!rOdj9Naom|Wm^s1TPcn{t$n_u6}r3yb~3jPcCX9qW({Zna2Qm~yukhAVS
z%=|-I**?VP)5-HKFw;s+PtxFEG2QfMxOyCUH{r7}xx6)`z4n@vjqDxUg6#y~2o;VT
z4pxt}KYsdy_r*Czn1o70IydosP0dt?=<?V-3AUQB?Nmkv#a8W-Ra%qq=bPAk#B-ma
z#@Zn7C?RU;(SO~wuemhYHbkA}y{Jl0C4P7)yS{22QI7MzZd~p6Gh%kvm%MvNUlI}p
zw~SRMLY-c3Q3OKVVS)JMw^CCj3@<E)1T0N**<)34%V(+)8!|f#yRwZjeSG?sM!#6?
zL?Vh?hN=|)8xwOdlIiJgA|KgG-aakks`4RtZ<CyT`CYoq78^6=+is+Slir!My-ZMU
z+e-|cmUo6}awrX?I~IAGT?ZVwpNU!p++B$Z@^alZ7FJf=y;jYrJ$tEwkOl3Wl#>%9
zf^WP6?t)u_cSy!UXpwAKT0ZiGuClFxH$9bJ%Dr-gonwj_Cw?{#J6z*l4Eu{B2iu)*
za>=2H+4LH(y1P*JgDQwV@@*TJJ9R4H1S-E#7@<}9LWDHW&#11S++<s;kt<8zRIL?W
zA;Lz4A%pKI&udg{13z+e;(Sz|nq!7`TC&@)&r7tD%hJTc{J_-r3%-&yzfD+Y?+Z70
zCwkUApY3wG^J9S<7u6qxM}V##E1M6bbzr&x1205GL{P&A$OdH@`&V~h7T|Qdx)p{M
zE|vR|+j4tnXRgUbM)7aqtlY;h+g;dqb)J@*F?Git>po~JJv6L(yXH^-uJxtk_U$h7
z7{!b14>^$j+S-O>CmP6MzllHDcCMZi2^dU>w}|ehVbs=vXL6;ZMCBzpoj|w28Jyp~
z;c=IOW|s^ugr_%S?TO6%%kEhVZ?gHEO3d7*O7Sgbak9zyR~ehl^pgityR;Poel!Gz
zSglN3*n^j?lge#q-?Q7qrP;tDuD{;&RP9uA;IV2BLDu)?-go}V!3llywv!@>+GvY~
zM_V@|CZlwwvZvfUUQ}uTFV9qIn9LTNjOX=J`9TJ~c3Uwo2Mx3Tm%(T~f}N9LB+Gr6
zm*^X$LuZqPuWLfrt<rnTAsRUH_+&2)rGqz6nBe?x3cn-gu{|aXroV0Q9D4IbE`&?e
zLv&Ag?IISwL)t1}*i5A$-_d4X*KTV!8oQ3`(KtgRf0a`DO_}Yv(+g(JSRPZmyCiHv
znIdqd&?~LDF5UF)+T1^?t<FSgAlsahf(T-JX#cD$(;qU8LCY2_R)<lLtpBNqgUp7y
zj43<0QxVpai2Pow&ZdeqizI+R>qqrrN;rOTcuopY4f4WzRHKj)83LDRV;g34y}2Dd
zv?Y{Bce0QWTUV6C{%w1MOzAot4suE6ReS5c8ZCE}fLFf1h%F$mY{`S1P#y*8=T~-V
z9*Ago!$YqFIBGJJq{j+B+A#^7g^_c&T!`MDhb2?MkyQ%}MU{%Cy~}Rq-FGB^=-Lxa
z8&{jwDL2#nTO#@4(2EP~1=9xPqH(Q$)+ZuoHBBqV;GOC7=6RzgNR+JsUD7=fFA#nd
z7vBPc+WI^Q5si*|fqFC(t5Gl(eKzczcRjaiI@FMbNpRaNRhy|)%3tm*y6{u&O<lBH
z%6@H6)zkAz{n<{n6#H%U+edAO#<;s#sP*WlmWT%x%Y%*!#F?=mr_%CUR0`3AW74p!
zaJ}`occN@*Y`iauPDDapjBrUKX)z45y;S>@_rm+=Z|A>=8=q$55&??QAE<FZ8jqqG
zcUX3@p$CfZ)osq^zRs9A+WIJXHc6Dm(om!4b7)aU1&Ob?W=njwDE{KPMgDESS=`4R
z3xWy<N2#fsO+X!sV~2uj3%B(nPa-3Z@)hwhCe}4wfufG4Cy~SWKF?Fd<yVCy+MtoE
z8Lr9QF}5-irVt8NK|{;K-uWT33LHymUaU7SD5*m!e?*kED568~{Vh-s46r&EFoz8_
zxN(rOr6m~h(8RKsCd&~SyniYbk286%_UDC<RWsnT6wfx&`sdu!rZr^uxbAniXNrS;
z?ftyS=vX3$RgPL#OpHE<tE0~>W?jKYMYKjTK@UE3ZL+TGL8<?=q`HsL?*wzBs%>t{
zO^3O&+`32SL3KMf9-%mif0ML}mxaj!^zxEIzZ6|u<(iX?0Y4tjWF?(lPe{Yx)<4cK
z4~OrDdEISk5A)sS%!J)K|1`7v8_mr9ueUVtXK%wFzg7aHguPkCT5149B*2nO4C_`P
zR%ZIIN~C{;U%aS+_%<Tf!wXu7D_);&=u`)hGTJ8@cbW_>RW%&Ec&eHU8XjHNN%I2F
zr^k0nkI~fqGT2`0MgpfdEmEAKaVPFp!2$2*mzIHr2qlgnw1<GEn#(y)A*J&A<VmF<
zldOc6@rAF=_dC)kFYruW4}S*giF=1#`t;sAdy}Jwt6{#DQ_z<e;BzA<U?}I|y4$t<
z?YLCVA|7C^5d$h#@I5lOU9Qxr8M5?=za=~Hol1~ld*IA_tY8^?kpCdgpd&1nzK<)7
z3utwgY|UBG2_?pz@z2H{A^&CW7+K9&HD>PB`sZ^|{g;agav*ZtFW=vz-GyJ@pYT0`
zQzGfpiS_RtQlU8<?3x@JRUC=O`@O=2s|Vj9BTN26(tXailP*WI#nOs3T$wSV@BQJw
zOYuj{@LtLK+IAx`ObtMS9nOi-g3L(a;c%lWN9haIi<1-n>grbBMlPmPY&jrjdDLB4
z1=lIc`yDR~BZWaG5((%3xu)D-pI~_|__?AMp@pd_$|P}+2z9U7?@ap>^J3@VDR+E`
zH5vYH$3C`a;DMk^ODH-9|Mu6=&$77T;tfrf{Sy}V!xLklN7I{EJb&<5DDI}_#zyP*
zzJsgptN{I_`Q$7Kye!8<b|0<Jo=5H-0ZS{zV_)Fg<jV+SN?ckzBF6tHzJ8gmdaBtD
z+j4id*;}lmB0cVLDZg@T#C(8?O8-M8^{V}4Q;+d8dOa#J`bD=gJbg!{T$3$4o+nDI
z()2kc?&qz)&Q%TmpWM`EF1+XO`lO;CJZTS$>yccd#DAfOgcx8Nyk~_d!+OQ(Ancej
z4bvqMX$+kg3sfi{MQz@9hptfZQbSHqgS!aKDt>GSOMdXVKKLQrE@cdETSO>K?vEQ1
zgWKe$K~X)O)~up9)e;ymBDAZ+nWm>{R#a*uNm)FG?-1AE$RvC#${<RQ&4s{w*+HUG
z*Au7Md$}LZ@G#OSJSZ-!%s?g6K&9X?Iut&Rnk3jzc&`-ze=@g7f>&>p_TKk>IRSp=
zh#o1%zwidc!Rz&-ySgU`z?1?k@8p#6{nBw5Aze%Z0C_*E1!Wot7Rz?!(~e%h_x9l;
zMHCsYR(tc0mxT<gFG4LnTC0>6rE~AX`!PLV)f~`fg2ap}uForVvX$vcqW~McYD)OE
zapY4|B$#Kg-g`eCE(#<u4>UjC$`_rFHx1hf4jbxSE)0}EB8;|&9FSWdE;ZMfeu3@Y
z9l50>J5+@9@#3_btu($1edT2vblhdN;<hGA@Wa1ToDE%sMe4SP+db@fC2jSdFZy-x
zCn423gHTvIzQi{%;j6Doh5EvUHwW0i^1PxArTu)3H8Ty}GHqPF4pttiprZB2Aww6X
zP)XHl<<z*t*QCEQT2f$P8f>n|*u$hsWbtN>mRuG`J1~*J!CDM?t)S$kZc+%MhJlCz
zEp6fVwVB_-i8EFRCGDDB?jQq^mL`{1Agh#a>+Iw<M$<qOUd(xE$h+D9PN~dFld<5H
zPYV`LCXbJ?BKLVR;cfQ`-P5f9%oxJv#Jnb22Xl6uhf0F8mAns@AbKV;(#jp?t|`^0
zGX@uPa(N$^7OL;}-<rbLer0Ua8q?JqJ%x(Go`0|p+kQ6<O65RhPRaUujcSt=O_#q5
zQfOwz5U}xY>{gGLJ~4Jos7?FWUY&=K8&j=nu$BLNv3xLFl^7NX=MR<ig^9>~($a$c
z=NdQGOb9QZ?sw#Fn8%{c%J?4~BzQOvuAB+D2uYJUPw%t0v`d(Y+HOcEG4>r+*A*>y
zyJHQH1t}o**$aMqZ|nc$(`y_Hx)KSZzZQ8R_>z4FA^>4EYLbapej|hOp;@{_apKc(
z8vDPyE1D?b)WeYm!w^B59UbN~GGt$v3`B51Q=9+t>GrBxBE8K~$T!ofsfp(Z%cB{F
z;-USOpD|#IFKd)?oX(=^%*Nv&*Q~wnX6vhG7!3(<JOUS%loXP}_~$A&0|Vc!8(<Gg
zlm$7g=Rk5JU7sDO97PEd1A#TYBN-aX%q=JW#RP^A;8_Mb_VgYz0|Tf7#YGDO4qw1;
z``-tq2sPf$_V)F5?pM(HpCJ1Q)H5H{Ed%Tjz&cs85d$ZboUAO0|B9QptE(%R_s`DG
z0=Oe6TYProgKsMW``zEKS!<~Y!vVAB?_H}ayex+XfcF)*!3tjZz|aqrs5JS4an6O_
zujJ3;PY^&;NaG&L5O4u#kKC-orIx1JTIav%e9r)!Ksj*Q)^`Ig#a}PH+kC(e%<_q?
zuI7D56*t(Qn!I2z(N^ZP7?4K3!CNMhhGRrYDSEz!?URcu!?9rdMxbmyjNBR#HAkMs
z@un#2bbXv+z5PRdCF<50N1zBM6U5)3)+iJ?D__>I65n4>DRAvqxg9sr-cmK^Q{zoA
z!rP2AA=Fu2pkbAH2gv`TGuO&U&CvO1ezenkwydp}8Mj_XT>5HAo(s(v{Fi1?j>V+$
zRdoC&|Emvxe}Fl|!9-72esg-a;bQq!NyP0hHuZnzgmY6+h%RFp?u;blNnY~o6`FUi
z^;)>7;M}-3K>VmfuW4s}`6-F}wPS8aB)7n$hcNGJG8g+>AM7M`QJ;fDd)DSO1A~rX
zvD3EEDxwxL#U)LwX0@NVp^{;Q`9<-J=t+MWo1A*`Ylo$Bb<>0xnhj6>>fdu`SGP}1
zErQF9OPeTlJY(F4NfJKzY&JKY$$V~)*Cnr*U%qZ(CB<;`szikhS3vScOpF`JWDrx7
zpuay_PEdOAzlOH^F?SlBk_sN<|C8a8K~R>1HF3K)dnsCOi=+iHC8528lSREHwvN*a
zsMzlf#jc<#w+s|T{f4*<rNe#=kwI5|^XF*x>~Ry>$9eC_n_;vFHIBMSX*k<<w$p!a
zGvntc2k|QDq7kAEc($pGnFsyh%OgH0j@2GF0(gX8x6-JX6Fr^!{IO|V?{0ds^gN2H
z{v%Ty$pnN%qn?OgAN18ImWIy&tmhdeW>oPU5CN!_-T#?S05ImK`Y-D*U*>@;X*(0-
zoMv0Sn)=pn03s11INlm$GJs$9c0m8}v?}Xi(0~p2sDP~z7^2)pb0mShpj~JEiiD)$
z*`PQvIr;7pRNn*zxhy&*gYPk(^~lA>cHBk&$i~311Hx&*#CyAn?epW~&qeDiK#f@f
zt<!bO-U4J;%iebf;Jbm}rNI0)_p1<a_r4MM53TgquU{a-(GyNss7~Yo$Sz<c56s0o
zK_24SBVfk#c-<!q+>;=g7R?U<^34)RU%}%0pRK!(UC;MWy<@=vJL}!5Y_6!N=q0@)
zW|}%7wi7=&i_+=YyMdOrg}Iiuy}fZ8u4lB`jd9~TvVOF|UC0MBW0;Ul2x+85kwhHs
zNCf=G+5H5@@1lV*iWXw66$1Y^ffmGmn8bn*P8pT(!3mPD?>5Z#PBcqblcKLPZ`b_g
ztON}l&JSh;T+4|BhXW}E2M)b%5nY~?J*_q9W0mR;ygzA4-4$S;Bhny*TpfBJqGqlS
zmPRq*BMc+ph||0mBNig5POP^gv(AA*Vb?m8frzCGd|f^e-*v$c1!jYr20m@9R0^qu
zqpIDh9co~qxOM5h7F6(W9HF6OeaNhyJC<Rsb<ACY#zGn_&S&~%&EhGn{5~LQ*)n@I
zzjoa-sDhmfq!VW>C(_YCUnyGYUFK|&E2VMy<sphSM1B|Yv0}k^8Rq2O+~U&L8vV7l
zVwCuWF_bc!iM?p|@{SH1r8bj-vyDUOmb}b`%f?B}fBZ*V$e=n#=B3->;o^9(VDe)Y
z+jq<DQ7!+_<2ds*B0LJJGJGh65;KwdNByXh|C?^3-8b)!y@Zzi5So&i2XIh+tK_ff
z5A~F)*F0Lbph^jIyR1HNyHcfe(Ej?g`4Z=v_A;F1o~8wAwBl^wiaX}gVJ3FWHi&SH
z3sW;{_@*`!ka=!CSy$qbm}4HR<Ge`jP4$s6Y`8xcmp~?6fURtm{AhNL-$~L9A{fvW
zfE<0w^gbp*A{W`VFD<QB_~yqjx8PM@+Z(+~Ss1~8C9OZNZ`0_%y}n>?W!lR!OaXkp
zw)%Pv+IXO()qI&&%oMx<U@^c~baHY64Sd-luWzU76w6*dbIAbW0Eiuc%ap}st|~ZK
z0C-CAN<v^m;d9)M0lWdQgP{1kf-Gd6)%-_5jnvTi@jrr>k53!$tb?-mE;b<Ll}J#6
zfX(;sD<I(n=uHA(TyNdDQvhg~-k{(8*=P@NYhVpM7gK|J0#H~0a1S6M21FJ(Vjk-S
zz)hmUK>_g=q3CsRi(Ob+@&@@Yg>PJ_zS7k2?Unn$=nO0@(cRtgq}Cu9DIUCL?K^)k
zwRZs(CF8RP&A#!}H#cTE;GWX<7x;NED2Xu+7CkIG{D%X>Cnjg_ZaoRLQpH@&;R<TM
zTNzLHicBOk^>yl)6wh?aeO=)-?C^aFk%01Hh7C)8mTZ4Y`XcRrKBxHv`L-$u|C3k^
zTkrxtS+OjF`cL8G%46lcI(s(C%Lw-Da!O_r5wV?o0mw&>yZ7_AF0VtMTnvs3+xjUJ
z7&f2wdBpp$zf{`Od7T+L$Wh@(ag}(z+rMzMenNq~jDU|3sUmJW@A@ny$6t)jrjOQw
zvlZE3h-=)DzGY%z;qG(EIn?g!V$eP;5vH-hss6S*FmvH-1NngbeoyLYl_F0+&iPt$
z#Gp6p>uNhp5Z9G*#V8>uh9;z&<$Br(4wC~)yER5Iz?wwMd)dhqDS}V--Z07!eLTke
z;zUVCD~8?JeyLMahA=<5@E>XU95bC(uAlPLVL--9XOrQy*XV)t6d8POA9t_AL_>7b
zwCTa&#o?4MiSQ3gX%6?Work`w`ya1m7tBj%uS$lsE7j_esYwfKa}<wvIw^$W{Q*=W
zo(M-if#mctCGDnS%0hdLcwA*L|Jln_)|BC``BtwG4W^l<>3W!3&*-X_$4D8Gxci0W
z#PptujZ_t)m-PnQuEfVwI5#}jNs)UvBHctfak_=0+%~eg7B=rlzn3vJZ~>I5gQQXH
z?B2UyTXipn=J}^>1g`JeXcGwDj4R4U$X4&3RqwDzR+s3KE5QqS-L15C{aq4u5RZ_~
z$LrrP3PM6d>0Se)1n>`9?arx8Z1eHz8y6<(C#aS{^G*6=wo~&buz{L5cowh&5wHcn
zs}=zp7ZhF;AakUtW##2{THN14f<OX<o;R8kT$H`Mo^7)B_8bc1C!uax!&{F0Aan?D
zU!Y`wBpAd~Kq&@wzpIy{KMXkaL5g=~YKq(E(Gy%eDl|Yg@;UVgN6*UYb2h{SW`0ok
z4&dLNpP&Cq#+UOyRvD^)JvgC($_@ZMVIl&gzj<K1#f*{yeug_x#?j{i2TPQdi316h
zH<PB-DS=|yV%fZ2#=K-mFrtV;g|u3LYyu%NZOT|KZtl;(J=PWfJc^72BK;oXfISAj
z+gjM0it7zQQ->;t0iuAu4)ZG3Rj+X~>-+k3W9^Y7dO64V){8n(x*nRL2L#t&gh$ow
z<g_O6y!RWHlm{gC_7sJ7>v;a5EMcS?1K(AAA8{V;42na%Al^Un#?~mk^rA(6v9ve^
zN#q7^a=u4p;lKI<){Ci&Fg{wA>zSA7k;u#ejkIb;Vyc>&OmyME#|7GHntG%=jG7Rn
zFP9+;ELS5U-CGo*Dnj9qRKKwC<L?-^5(K?CsK!N5QWBPQkKORSiU4GvBpg^4D-&L9
z1@ZLQni|wW6<_EBKl2}{C%3gMP7bokA{{5RiDXxN*5Av!C*Cg?49(1Bm6TPKQJXhd
z3hJS|KlKtB{^Dv-u8<lohi7BeiyMd=+=s$RGckR;J2#&9zLtY9>iMX|egi|uJoll7
zZ)=)Uw%Z!F32)>+q}9Tvd5rMBOvr<|`F6_cG5d0;W}aF~bQVfOOZbGzd($lCH`AZD
zl$y7)C&I%r=7pn&=ibDPv$lHLbnmf~378yMre3z^GVd)%-+Br5U69YcDo=%z5Em8t
z9S)Q0t#7!tgSOIorbM2S4dUrl4Vps?TpM&Kabm6OuptALAi2HrE^}LafZV#O_UW^b
zgIlqFR^eyjkl^xK5+v3Q+?_?84$=)Y(Qz0YiYSqOqoCTWeHICbW0!cqU~mrVU!KuP
zxGU{#XFS|&oz}0%u7NoTGXFHuG&h@pm4)aHr>eq`Rl}L-;PnmFmc{Js;?YZXhOrMd
zH?tHWU#@?j#LfltBrhCpZ}+FL_fL#;Ld7BN_)w)k7e#zkM0p?8_Rb>UaHwg(x*(Z_
z%2-sMLMi)qG^_M+HIf#=$?n+`2`DBV9UU4>mq$KNch49;sa$aS17|9I&pHFP>p{+8
zCJ>S2<ct@xs#pWL5x^t_WK;zuCF~%v=Pv|1plrT{jm^`Jk`IXeqkS(gw*})&kl6>=
z5nbSB2BZ-HEtz~q5dujE?1I4AAE`7?M@tLf*`AAyPQ$`ap6>3qAb|5NCZ_$&6Qt$A
zn5q?&j(|=o0s?|aa$#?9y8-NyE%IqlC4h+(AWw?`=;>gUaT|6*A*w}=J7f9Jhu7yO
z4HpOqaIS6f^%6fBJ_`u~^x^c(4-;#A?h}AABAZvqY4Rei(PP2&K5_lm{`Mk8UcHgm
zadudW`wnX3QOz3gjV^>X#ppv45i91e7mPl7O!mEmI>1L?FKZjjpy%Rj$c!tCN!Apn
zyKxqi*K6m+d=S$rZmY&;o8;L;bMUA=I3bpTV2~G8)jHZ@tdo#s_oza^AHNE{@ZGt_
zUBT5nck7FCZLiO{!$xcH?06>dXc6VrgfBm@#2&a-;zZc9i9-<~xG-T4#Ust~o>!2}
zzAcQ<wub{728I$@8tBSZ-)D=$!Tx)$xXFDU;pUrF>eS5&bHx^D&d&!yv)Z*ll0!BV
zoRZHDeYkU94PyfIf(NN}6x698o4l4$wu1hZrlTnsJM1(3D_DLE`c>h0W3R}q1~NIV
z{(NoC;4ZSi(a%DTdFR4U)7+l$wyzvqie!rE50)K%xNJS92up_r9(o6y%%EnC;-QB~
z+G{cq_ooPUx#n<JxTXs=H5*;%YJM<{NZh?gobKxiMWl=saa7qUrl_kjy{i4Du8+}3
zMs@N29aR7`d1)dFm)=%6ZQOs6dpgAX9fuh5>0w8O*>RHcekOSSGS|Tb>Q8kJ{ISwZ
zy_qTm{`AaaN1Xf4A&Z1E(v3#Qfvd-V>^vv@;CN=}|0A3FSQ$1=<!~?gg!8w@JB4&5
z)Nfpb3&1^91UlaVCqRRV#ABS>ha*h{|LUh*7aEu41ZAxsgYt=H6A%Ih84^yqJ+!}?
z)(c|`*1WE2>M>uw?2!s8bC%!544Yl1SwSfEe10FQnQr{I;F&DcR&TY=U!nT$MteEY
z;=<GkrO<mTBo{C1d12MeT7uxc9YdxWmjxFooqP%#NWcT62xz1MM?|5^8RJ;#JkV1C
z>M1JvUPq)&*hNYiYip-zFlDkCirvoufHr`a<P{X$J^-J<qf9(40|8o;6n>Nxf*(XC
z4qyba1&>9Pl$302eoa~|0>GP<)d9dy=qM|Ts7wT+;)7@o2w|O_odLH2rY{U7Ou`=A
zfj|w~Ptek2$(_Y(m($ST1};y4K*Ia3`w0UC1d^CEL3jodDv>kV`HeF6M`Poh0b9z@
zW^1bu_-&{6Bwt+Jy#msl_VbFO8vK0L8%6$6&GYu~=6c=FY40{T82&18C^enqz@Hhz
z9Vu;4;bkND{^4?mZJC<n%KHx$Y*+q$8G-AgW>WEpbWFTvB2BM6<&`lWN`IsK^$QRp
zQzAN%hfAtc(Jy?R@lMeble=$2x+bxGQ?bzQDk!Fy8mm+3`uEzyS|)?{@pSI!&cx^U
zj`ibJNYbV=M4o<-6UN{N<gA>@G;LB8e;nCFg}ukOYA%785|rF7^cx>3N`VhJ1|L>z
z>wzb0&yKz_t}LUUq)CSK_pQUs$OtU?>;#d#MocRuA-<TGFYObihCa~#!0~lf6MrE7
zwk+v_{L@KqQRM`co(4R9&}W)T>wl-Ju>V9R(2pi-9^q1OJxQHFgt)T?T?#W$s6j+m
zjo<Kb@boQX2o^aypYC(I9^6A9Xl44g9Z1I6F+WX3v}5*OvLD^g`n+!z()MtfAcx@C
z*QY3}!IJV4)RT2wa+fVwbSgWiCiz`We0qjlOchcY5*Q#q#;g7=2j%`^+`aM$Mh;*R
z@clkuxMxvy<w%^ii-NOC@dC4Gu%M{jf?W-bnl4um<vq*iqS(w}SqQ<l1Ob9{`+q;l
zJ)LLFBBT88xNzu+*1x44Xr(rej!ENr-=Yz?d#P|~j(kSwS{?2iSq}`%r9-cFIg!MV
zb)D^0X18UwjSeXT>dy7;>Zf-075-H_3Nci3Em|6eHw?n2y~D3%($rA>QxIvrEE1Vi
zgy*D<H0=bh={D@IEEhQsqhGGi3kc1TR`X5rrAC*v#?JM2c)d-K-aaHhO)G`UgeUHn
zPrqB;Jc?P+{=~DORqdLuR;W%}h)<n8AYdBqH5Z6Jo%E;*Sl*#u96{F_u**B`PJqUv
zhDA_4rK_!t-hOm-G++0txcChpUn)Oy7vL!^Zk>U)6;O=^e98c)1w8oxMFo1<z*tZ4
z>HciIQ0XgqXQd?<X^jRGXk-Dq2|!xu{o=_aJ_frVU~uK-=l2*#0haCA=_v;X$AraO
zUt3<!{h12T4*`fKKydgr^f{p8xc8+EnXtDf*yXlT8vv&|liz7~2OUwd5Fe~tt<u`&
zX7H(X+IR*|&JVw)!Tj+Np9F{zQlJR~$Q@P1yW<)gb6VOCRq;_M;pdX6#prSntDU7&
z=d=0GK6R1Kn_m#u<5@axvAfG#Uy-}yj7PK3K_gdaHzGr<Y2!W!zg%H~*5D+QJD7`x
zB9lYM;dp$PbKU5q*2vAf(e$}^FAiVQZ5C9)hi}c~+0nePdGL5IAB<3Alt}3^YU$zO
zau=e_&*RNe-`4ATFEQ~_Io~wwf?pMeBfEjy#=2dNu;M1Pc81|ynHJT{;TS)DLkJ(b
zA^k_>Ev5_viv$m?0;QdI!Li2r+%ybA27K7Q%b5IU8wnb9Rd@N{l54Ll=}=iTg(UFQ
znR}Q!SFYYGK9=IEj>6m+E6GJ<Xg45b?>BMo)n|H8;Ej~|Lo-6FyC&gWFiSiPpa#m7
zD#9ObM>0OS%@&uOSNG#5>@YyiC2#EZp6+>@?%=r#X<2_7KTKtd*EB?IYJ8hNc=fJ0
zQmt*aK)yfH_1y}Jm$#j)q|=GhPy5e<SK12SN}5X;s)F~T3lfw<wV$^9jZ>ma_t1%0
zUJ6$Ja=1hCliuGxvM0HPlW2aO1&k$eqRGB%MofsX_hKxc<rEQH=wlKB$9_5$vV^`2
zM!6>t@z1896b-@ob<|N=^7GfQx+-_W^eA>93oBjSaL^ns)EMl`@p{x~h}GiR8v)Bw
zCu+3jZ{p&9wW~z>J`e{S*xGa{GwL`8k{q+M_n=6~hH~M{0xz1PDo8i5Tb=f=SxYh!
zWsQb1$*{_eA%xxrJTzg`{+9r;b-cXXpZQ{KhWj%iL7LzKF$IReLgsuoK{6YjHvv4I
zf+tHa5znkqn!MZ`lBJ#8Aq<4-ACN2vf(>(Gzx-F0_FR23ySzNihT#kF%2e;8yN%d0
zx7J5x?Hrc3&a7rD{{dQbzHnO6!pI0tm;{KEK>*{uZaxDf!@d@ROmWrxL98?sOoIUG
zRxF#1D59pe_VViLE4i>9=$@V2O;1mMZebcVbL8R$eTE<fIvVYo2_%xI`z>M6%#jS*
zC9W{JL8%l5603lfIt+&i918&^x~mIpYWL+IJ*=juz|Cpk*;7u6i-838wx7j{bNj#A
zmh8@dBu1coB+}K-uos#)Yk!AhNafVq=)?W^f%=E89*REnjmrML#Yy2hma#Eirf}p(
zMw9PB?W7wID1<cA-{-zC>eQ5jz89oq0{;wR3KTK=Wb;#pUe=W9W@FQ(10HZW$ATGD
z*bPelXW(>seiupf)o|nZNDudC;#5*}`GCW9P#elW`{D1g)QDi%9x1~q#!{GH6N?&>
z>z(ECgB;R>isrHPx#~Yb*HS8hm*fAgxt7)ZHX?Q&{v5;a$5JKDX?=+`JLO%3Lb{e#
z>(Z9J*SoXMxJE+lv}Z%N|5%i`QEl59bw?0~aKD^8fWQJ^DnD9-WI!2;-5$9J9<@5h
zgN?5+)R_uNMg-mN#R9XfQ><PUJuSg+X<4>^$X71bGeS499v3uO1=fXXQB4K|a6dC(
zGRC?N)0;}FKLO$JAEwJwOhd)c)Lj2r^Uq<Ci2VEkn_8#Z;CE&IK?4q^%+f4b5RrH%
zj%(fI45d+1RKCz_FWg`6i^sv<lPbM2l9gF^QGG=|^U0z(+003$jdjDhz{rz!QxaF1
zLIF*IQudVn$bZX|FpPpY@I#Q}>vVhsQWFx}YV<5u!yHH)B?LZ;RE=qcLd2|S!s~CY
z%f~=Y7XGyL6flpt&fRv(`5Sog3g<%%s&rKb3y#InCc4kpO#x+PyB%BwMF~rkJ6ujm
zNc-0rcMJ$ycn(ROF5QgFj8*j(ORBhS`i|>|)4)@P<+dY#D|Za4vR2UwEpx#o6TVUR
z?HgeL`f;gH>7C@EAE*7ts*$6>SkPlni+3>J)M7tWhvJ`d9Tn24hfPDU`Bw*~qOW}x
zYnb8+SMmi;6vwC{rNBIEI5{Rp8Nen|Qb5ui_iNv}a}y>~*Zs{IRcvU7LHVpD2;1;_
z-7bTxA~yEk#Vw$QL*677*Vh9>s{)|qBuP{A+pS3eWlj*j&!_?no}#33CoMpT7>kS-
zaB_cjKR^RIViFVoQ&xt>raxp;5TF6Mk2m`6Zuuz_ur9}|CoRBb2-Lc5@hpI<bz)Ei
z7}f~^8&zMFz)iw;dJ7<QfI3rIPk|GfDScvNX66Mw2*ej6BO$65`KA9^zVk2WAC%{V
z1av&@>GRa@55}eMk*7V*+`RJj;dz?h=CnSVeQo5Pl^O9bh}S@bEtuqm3O5X=D+akQ
z>N<<ctU?T}L-%*G$T7;F)3V~r2oh16K=I@0&PJk^gM|0;V;BP?c&N;=k!@Q^8^v}#
zKa;}4IsZ$gn-2OU^CFrVi$5I<KYWHM9E`vGKCI@d!6o?gW$&YD-iK=GwD@5MGEwCf
zTzh^&s(`XbZ?tN%u*CYe!Q~lynOyeRZbKHt`Z249<9Ra0jr>jXJq!93MxQt3AwyG}
zF4{{&|3#30BYvzu>+F2m>U-HCitxA?X^m{egrWEbuKM+wrgSQSLj7x!B6TWZClqg@
zdu!tP)j6m*PNXj$aTtsd&um<^3S_zyg9w;Y9<H&u_(;Yg%I3Zl+eEv1K|s18j`DqU
z#`bLG{MgJc&pdCi-4!;tZMSUVMjJ*Dv9dO;Ch6sWGfq8Ctn(7m5%B47DrBq+T=*M0
zjNZO9&OWA`rp8fr)UFt9c>j5PRJcVxu)`i#flUD=713%og&ScRvn#hpQhl_k7;13T
zdk7`4HyARD6&Vl5?BZn+hYx}HqEP1geIBJ3;8;^sOt{I>i{3g+^A#NGajtfOOfmp3
zODXM)KU+hQydSR;ZB{p(`g=TUu}c(qQWVx&zV>isoJjOoELZ-O-QYUp*Z$OQVdViR
z44h-V3Rx--14r(Mcd>nhOnMbFd(L<Ft)rSx<0M5^I7I}wUx$r}vjeN8i-?P?_Lsdx
zl2Qz;&1!3$XXo!!|IqO^VX8(6*<7v-_E(`1v6xa)L>mJ2ALLVZn_Aa7&ST*lUHj3(
ziFQwa?H4-fiCHI`b{ib+sOifE$%f|;vFa@>E@s5Vfe2<Yi*6%GQ3eMih39}El6sj=
zzg@aA{WD2*xO|i<_BUvn1|REw*A_MITn@fD^qE`FeTMak%afCcFgiNGS_hWb(N$YA
z&^WCp4o-&4AQ}%ei`);73=9k)Rbp32>Fo{%vR?&He*<=K$wx*>m271*5XSz0bK>(-
z0zWr3<~a5J!|A_)XN>v)0mMMFwxpz_zWy2%l+mJ4GBaC&p;uT~7*HrGG%P_bUs7`V
z_+vDCZ*u4J5);e*p3E||!t1>^MZqnmr`~)VX0DX5!-9iwrZ^zLJe9Odu%PEFV=kR!
ztVl$befDZCs(l~1uM4kTfcXar5NPd3cqr~P<yCb5pg;O+;Eahn;(R6y6kt<Dh`?59
zkj?lm7it%2B9{Hr#TJw$^}1x*F2CBc2r-`hKE$9TbW@DNpRU6-RktT{wW+&gX#9Hz
zJgacuq3~{EaT2l8a`G$Ew8U#E8tq07Jm+UC=k(G&^%4Y1z$C5VvR2n!L%<p3kcr}3
zP_SB<Rpz}O#gZyr5)%%mfiT5ytlQS)VwbrQZMVu8Yke+(6PZ04*#;a2EHSY2K(i>`
z(sx8!QRxCI-&;v}zQIjHO)*QPpu2{`Xg~2m%J(l5^I-hIy+Qa#rjJ`DNeiyJo=+#s
z^%rMR-C`891lbZ|?@g6FBbF`K`C4~|oP=`uT7&YSaA};o=z+R^r~iFvmZEZPHS0(F
z@ZsIdsKM*Q;ftG|SYLhW_^h{@od2rwTZ5xt)mCS~r0wflKOg`0R`^_2Hy`u*XYucb
z$sx?&lygG+S>ZNx-;W`Bv=lL79;NthN^}_5i2N8?<U|k_V)u$)h<k8iD6zPh6j147
zmTN>v2mZ+~84L&xnxyu(_XYC5VF-EBwx~`NWTGjaKMa9%M9V3PpNEz6hSsfy&gFt(
zc*{;l?Z+T0Z#538$ZP+6%rfqJDID9FQ8>|<_>tns>WSTO)j0Vq4#R~E9@Kvv6(ZXS
z=p+>Re}~d-pI)sW*2hLkPzkkZl%i=^dPgW^<_Vu{@`G?sO@pz)5v~^P=;jvG3d_Nm
zQ8cbvqF{jWPYPEq&|s|6rpz7C{#e&b#@?IfQR0W0C}uJw^vBD-f#iKuY$S3SnwtG1
zK{>bI9MkvK)=X*HPd9ogx_XwgtX~}pf#IM4MW7NSJwYjGgN~5ZTy<q7$Ir<(I4Gb%
zaBa5Y*<%iFHzddf`T2`>eTCTC;W<Edd+o7b0onmXU|`qES9>E9XQDY}z}7vD456l_
zU9#(YHIT#{p}hsv5BrAu^SBnU_vK2qN@?pgI_`i@LL_8lz(2OPuT(62=|o)o{PFi*
z>fOyoyy+`TP0d-enqR<(Y2<hZM#1g}Wyio)toc7d!t9&8Osryh%E;ouY~8d@e%9@I
z^)lhkU%rZt6P>J|U$<^hUNR`O9}yWY70vcbko={(vAJCLg+oT_u(b`YC=0^zllL>D
zjeCl2P*+*ZLe>ej>=|+07V413Zf?mNmJX6BqW4mDn~Ri5h+%2-n#`p0cIhbK4ZcWY
zY7w~n{P!E)F9(70E!&a9eT}xsg%PoV4Gu4V4(6fJ@h*1D3G%^a!%LANAqVky3^+JU
zslQ)*GD3^cfJZB~b7@w9PuQ5F*M&#vVhl_WO%a{&nu_Q;0|O3wKJdjLxmQ-J42#F^
z^`G~sYa2hs!a>ZD#XW2|zc*Eas*-Yr;eW241=f4*CR9`zX<ql&S(n1ud|%go^C;8z
z{ktR5lgJ2_h8<JxzTc<gMO#5(qF~Dt5wSHHyB-S@_K=AEw!h1huv~izKmF%l1y^0j
z;%iN#&ci2n+SXCq?@3WTkQjLIq(Zo6-5S#=E7Ta}r1c*6f67yHsOrb_eIl}(F1&od
znO8-uEjYlBd`E4e(7lB#`>(<_G^%HgyG_{Dgq%5v@2-iDc5{#Tbz!|**k1B>4~|8=
za+yRi9)s3~i80dG2sFtiYRY3tTs2r2!pmSfC=Y~PO$Ex!#_brE&6Zn(o&|x4^x{;m
zxZ<IpR^Q-UQFRAkB0%Uf3E%~1W{P_GuoM~TVCipg8F_6Qg@(HbgS9a9p&m%(9uT_0
z?;_jgqF4;WrWXz|mA5(5?~GP%R~;x$UvfnTd_)q(Pk(PfBI+9_7spv8$H|!@@#!#U
zme8g2@m$r_lQi+8vTl*I!rxS31jx%Ueveyb1uN8i$$-1Bj+QgAZyhR4ZMzqFOp0x=
zG!BZ-nJ7v(6M=Jw!^`OM+^wOCNWT6-2r@gq<^9;rL8~~B;%fLRh%xVQ*{8~-?!V;+
z-=c=rod=#4Dk|s-qu~4`XS)3~3*Pc9&j*4Uv(X$-B+{3=yRHdWs6N?34TfQ$(!#Xy
z;)Xt4R!NCmVFuI){G8OY*l3ZbWn_L>8#8_$F!??Yn8bL=qI;S@6w)HXSCBuhNVhAL
zwH*F3A9FxUv=!V!;eWmONI%@S4>x}MHYMI^RS)SM%-4r&jXdhRj5NLD94fO!d<+|*
zOj~n(LrX*;qHtt;AMs33tjnke!N(Vr{c{^7k%BkZ{*~J58~QHxET)q$S+m+0Xz}cv
zuUu@F%mux34jvSMr8zbi6RN}>TQ2fOk%9b|>_BZb55kJZ6c3l`**!WW*&j_z6dhqr
zbCld<b&!vZA}>fI^ykj8tqK%Q0+;POEnJT^29f~{#fp$RdZb}WVU~Aeo&<gJID{G=
zRblkt@)AU%w5&?)SN|nj&5eK6!E{t5d)-Naz`hckPWb^br@DO8FkuX)PO0s>qoPE?
z1|P#EO-Gq#FcY>aNdLtk%6}1)iXl|JnoyeSO{^;WNwy8auSTqPO=CVO)TWjSk#f_!
zr75SECaC;Hit}xE%J)>NFo>vfH5)~nMu{rIkNTTK)VgIJ$9>zU4qXUHQ%+U$y>QqZ
zRkppVdP)@dB6{?gA=C5k?_*~9u<@St83u_-9JGdual58~Z9S>pn`BuSAs$Y?PyFO5
zx{q0Xb-<34DF-75X@YcAEoeR$<$T>h7)uiOcP9a-mNCld3ZJbtMm<|Q0zArO3?cl_
z4g@R+Ih;5I;Tv)vK8h-}IHb`2GjDX=Je8H7*N3s|v+einWKy0pi(eZwc|UjeDyDei
z1pM)%WT({(9?V+FAsZpCC*~zJLDvx$9kPx*ZkNJ{BcM@Ihzt6MS}iMJ+!^RG9r?Jc
zWNNUy>Kn<_^1$t-l4;Y8(QZr(oR?qn4xyqrP?^-dIgC3C*Uae`L@MyH{O>$2bKBC(
zH<yB49<9F|G3ndQ$LY5?IvtIETB-X+rFSJQZZ)$WrtuCpS34TCG6YVf2Faeroo?*0
zmL8KqO83*buUuNsUVSStu9*4nMfdrQCs62wsU%FFz0vT`?j07O$u%E$qLYv`kCV){
z%xipS*euAfSz{qUx7wa7FLlu_rc5db++U0Ad3%K5J1U3a(Gj5Z9WjW~(2e&KGYeC*
zs|?$U`-&IFTWy0CI8~7oL8aJgi`#4SukTXc?%_c%>WPhuZI;dkmNChNGT)kN9bI|>
z=cM4U!~KNKQ~SagudT_iX%jRL&!j1Qs5Blt;n<(@9LzN9jxV}pN`W!vu@5&%=F;|T
zduZ?fQ1((t`EGPL7|fNUieO)s7yikQ^~K}IW-|Q%{|^odkI{7;KVGm=>>yzIig}92
zAErv!-Ml}5`s(t%UAr%jqVM{s1)>-wDyuTv2>WS+bVd{bM9z-SezVVDTqFUrhtbS~
ztWPmInkX~@O;ow0e~4NspZM?Hg;K;vCcZ7gh+b(e5gdu`Et~s30R#_h0S{!$Qe99G
zmnYKhKn6)=Vc&P6BS_K%gFNY9j}vZGz{(;Kj^5!w*4OQtX=+^YW4TX?YO$&I{MEu_
z#f>-~yuxP|e6;@W;~}RT+1)4{lJzD5`{}v?>m9K;$16rCs1(My2(Cozcm&vg!?6V1
zb%?ogoj4WK`NNO;{Pgy5;n2*)P=auiAgFZWzjJ6pGc#RE;M0A{%voH;k42afW!g7B
zYjWeD*b17SXiLL?QK!=ON{ZibmC%fIJ&Di_Ex-POz!l~dP>#%wJExzsi=@*X2@ipx
zm7!ZB-0#FZK;Jg8!TaKkkqs0%a3r<e3JipC|0iY9zx(OruCt0sW?XRi{R5nz^6y?F
zkQb(UdjVny6<R%2Opv3{S)Jw1vvd)r{uGW+Ywxfx4;NowHgXo5{&7U@nO;s%6@v3s
ze#5F+dmB;r=$7=!SmpKi9=y!;oDPWZt2Xx%m#xbm!{jfIKS|M!;lKrobeb0ZCGcCk
zn^^kkArureEo<t`_08w`Ire`Rep$ePB>)-wZ(8zgd|&k6)TFc3k}ms>n<P76>fbCI
zBI{%B?;3ZA^&Fj&8)B=*DG*zcWO`fh`>XDd{IUw^YD(Zm?vnyNb0m`g?tUbLaQ#tS
zi4R2lty7JU>njl^;@#QCm%gp#uwC?<(#_alt*l9C`|PrUc(I7;Jr1tP*)cvA6K21}
zf&()WuPpiH)p`u6x%bSQiq8n%p1oM8zdynYuJE0WTyr1p6z<K<>#`0tJE_j)Vd}or
zDq$wAa5RiQ7nr;p;LXa~_oWJ?5-*1;=TVTq__*+|wD}FyJ1lL?5(vK%W)R+(c|6@h
z!@<EjB|+h%X<^`Nu}ntTp0D6B-Xy5dYFO14w(#&d+aX8I=kW5bSa#>w76x&@PQ>Xf
zikU1Bu9^$%f3e@gX~f3;8lC^(A>^`rRC+5K^W=bI+kq{fV}#o=aW&XTXF2SE9csG%
zUj5%2xZ{rfUS-+>=<1wb;m4I8y?sL*l6J#a_Fm=n2Daaa{cAa~)F4n>WHyZCS11UG
zA`Avd{C=FOw_9*$zFow;NVa6CbI26P-$8Rwa+_d7LM&5X!<tVCoaJ`+U!iUd%YFD^
zV_7^B;~R(M5?(q1_Is{f%;RM7s=b6fo5wM?+RMYqr^gSwd4JN~vU)$=L=veh`AjYB
z;C{6k7Z+yMtH?9$Yt?`eJJw6c208uS-Y0>G$mQWhac@^M#*ZIrHh~yM*27hYu#k4`
z8n?n`A@1Aa^O7$FLq6U*0banz@LBWori;((a_u^yM=wZ*0Jr>~r>T{d)u6+tWDkqa
zhA7CseyooeeISkewD-R;xCT*6DF)9&Cr=jTZ<5silm@Nk6LeuI3F{{TRx>kUxa3I`
zXDVuHVpoEsi=mH)4u0&(9m^xJh&_~f7hQFj;(dlyRD!off(+SfWs^NTdPj#mKR8%x
z>Fv(ign<sgX8I`aPtDJ>54kGRUEAJG+QoxNEP8)SLiuEG1@quIWbSpcCMG?OMnQw$
zAiGz#twGniF!aI5#*nw{OTy)Xl;_exLP&SSdA-SOx?RSpDA1CzBFSNX4#OKBM9i|K
zrEg91xBokhpQ=)%{3%bAM8nUz(=CP}w1epTwP^(-M_T+bD9x$;z*hH!(*!xV5O!j-
zea$$Bd5jPfkzaI5z#^{hes(JJ)$;>=;vjfE292HRS`3f;ZY|V<(O0fCBF_7qo5(r^
zm6i@n+CX4&j3PL=S?VQfge-dO2Li(GNAo;e!`l339&I@Ni3!TC9}oWW%2QV!gpo5{
z`wUMs-+DMn)y|J(aefgU`S-)?0edQ%HrjBF5inEe<5d5J^>-)^6mJg{{eXnhdcyq0
z0wO7yP7Jo+c!@&V(LW&9KHt0}DX%@$I78E0;oJQp=m=3D6zvE>BAmy}BG6FCV$qSj
zrwk45$m&ASRUVh*X*nuyFx3CVN-R7xPA{8~2d${egmnUA{g+cYQu$A8>ab!H9HIkK
z?NxreJ6{;nCzkt+B0m}gdpb&O_H%ZmUBefno!*E9Yt(T>8>|`R&P~&v=h(Wdg+bEk
ziw~nBF;P;OA<^dO_AdA5>aX_doNShcB#m$5Jh{o<zP7>ZCk&&ZfluYFa=+X^dWzfP
zTjToohvDi;<al<jqKI&^|5Kv+$x=qh>UszQmWQf2B0iSO(ZWQ9aX?YS<8OUEVqG{_
z`bN3Y)ImGp`eu8-=R6*9A?GH<llez!sn<cxGz1Di*nvRAoM@k!(L|>Ei_D|v#l^w?
zvSz9dQ~q$#=_*=oPxv2d!B*ri+AC<HLlKAKCyvx%qVIxFm|S}ZP5i;dK%2Gs#K`dB
zxU>)0*S{m~o<~OR#A_|-2?KdNxl|LJ?LQXK;QOBiWnv!+#OY|Vs4{$8y8Z4m4R;n+
zd&t~G!(T&7CtzR~s1to{O*Vk^%DF=0-Qsn|;7p#gGdf};0Z%CGg%~&TS3DTpNc|7g
zowN0B5drR@b{9UjrV~r#S}EKdim>)RSY$kfND205(rnAXwN5AYdWbVAxK$bF;otKm
zwBH1wkMr}VQ~1P$8R_mdzG@NpND!2n`QjrAD~Kg+^nLKCXh4UQc$W)WvS_tO1U9e4
z6*?%bN}Zcez|91T!Uv+`YP})kpw#Em@ZQ3#@_y9SgW(iy7$xGhlQ=w0Z92!QX8+;e
z*$*Ns%N%N&o3euUI~;0yAkuC>Bnbb6m(QL3qk3(#>D9Z8%cZ|TPZ#OZWie*eE^TLF
z%CyNA7f`nji*Zk`mHE3Sx&W3C({8pgjrsaR%*;>X*2v7U4An)30r9~s2>1uluY>3e
zHTTtJ=<!9MFvNe<P$>P|vG>!_WoUxD<njvFzR1fV4=T{LdHk56c3go}8hA8m_&8q^
z7y=5sYP#Ade&d-9zLF=cc6eV%pK7RT;pU+xto<}{cKUJ-GySltcDwd<^}HeWT7a`H
zSs;@aRoX#SP}XLFi3m3tmYLfybi2x~)!rNu-F{2t{%zHfk}Mt!-2}69&V#4*9n%KW
zUf<8A(~&O%yL{+>vZ^ppb}WZ~UT|9gYNcGGuhL4zL!v?Zj&55|uT+jDwN|C&MKv<{
z;>})GW3YRn@Of2vpOevITf1luALm8}QI@$zJiMsj&4!l4^>EvlN3&8&b{ZnI#`j3M
za6Visrkxa4Y<r*YX@XZ+1R3A^$F%$~{mWb@_^HZ`<@50P&7q6>qUV_;P0RDM{{;8^
zo<;}lTjM)}f8u<e?*277YiuSC<Hwk`T__|K_;5XTt-LBnRCxR$tnw%8{rWITcN6n<
z`74{Z9fZ9cLLU%Rgc6LDA?G;j7Pio&17ho-J?3++_QL_S7fcOr-8{{E2m1+_ExoSR
zL901oQ9re0Y+RMb)2PTud0Q{=)Lrfuy_>&sw3(GegMtAgf8$-M0X-2K@`0i(J&3nM
zpePL05DLS$^1Mvz)fPhH(NM?<u{ByXhI%1KGd7Vxqt$kC-yAGGfOogk0LA*T3jdZ%
z8D1Vy9L@*^nSlGxKnsrfJ5qP3<ZuD>kKID6mu}lr%a^;$?5reVVNQpsJF6o`$+6S!
zJdFGuqrbM@$fhXlL{~Q5<uAfiXAX=qzd{7N@W?`4{~YCGEd)s;?0d6`A0LJE`=KDe
z_7$U6A=;9o#Fdl^e<OTX(ntC=E7aACswT=jp3yCnhwMj%%lU0-ZR@K$Dj{JMF%h};
zvw^G|IWa>9F!xLB$BQ%0hT&sHf7~B4$*A(KndTz9Yy_d`;9TUvQaaT>rG4T0v`>m<
zzNj*q)GJ|uEnL*_A5+L!ih47!&i@%&C!oGIdi){gzHo~i6B>6-P7U427dCgZMLs^I
z_8dp-f?0^!W(bO>M4Fv;g~!XR(v?1?`BJC2u`Tp>8NxS<yoEvOzoTpo3^+qT9FUEK
z7joRrwgNG-V<vgMlFQ5RUw3GaUk>GeBO8jb0k``PSCXR!ouSyR0KX`H4=r}#q;gZ1
zrHHYwhWdv|)AOeB6CpoB2JZ~f0v6%BaPB3-6=PG?%N_M5yX{nbME;9mmK~9=zp6F%
zxqr_@P~^5Vd2WtxRhrTD_9FW4Qp`MpZ;pAkd`DksXAlogg29^ZvI=z}!-p|MO4OI1
zXx=dMDrUyy46`;&2-w%4%#?z^5|YKG_MBq3WIje87T;YX0#;g8n|8JwA@W8f6~vZf
zn^1a+DoZpEDpwRiG+FwyDl&2bD^F+R5#sCgQysar<O|1hO~A?X8o(zmO_Ebm0*gQn
zaV$&zDNNednLWhY<*AAJX!FYrxdQqtk~LSyRZIAwDM%yPw(UxnvoGC`7&8()pK#e%
z5~=D`v$4q0o&0c(S-H-P!5GI^oj;lX;u9(i{iH9d_o$J`P1>!o<l<j1#AY1-AhRn!
z-)mD5lwqAMwsbx0(jwklrjT`RIZIg1$D4$J<Ln{rA3p4XMq?ku{dN;wR^vi&IF~?T
zNaL53J5LkmQo?Pes@A%#!F%PbaM|4nS!o_;DO_b(52iTlW%T#asBC;!Vc&S%8zT{T
zHecdU_@Z_)12rmfuQ!3>!Af*04ONnGCxYpJMQnaam&PO&5`5|Yre}H-Q}{$V2^Z2l
zGyawPr49vGiU=M|<MinM|2R6!uqd!7fDYX$9TJk#A)QJH(%mJ}(%mI3E#2MSol?@$
zNJvX}!#<W@`>iqzBiy-pPFnr$SHJxwx(xrmPvv_{kO61Z1<VzcHwY^c(WL7)b@sO@
zKfZClG}H+!iK*`#5`M6g@GQ1}Ni1ERsP;x-in(EGs2V_sRHrH!e_k~ex;@S;_dLB^
z?0jZxcQ4`EnU?M{+UgIh26wKy{M^&n#g<i#&ud3uKLW;?VcY>CrXZ6;R%d%i!-;RG
z$jl-6a~DhuM5<BwAbqB22P5IrCq2IdG0Z|}*H=u+qA2?O_Xb3TtsrJ0^yILTI8Qei
z8jv!0X9&ITQ(Y4egmbND$jC!L!Lh;osYxvl+YI`bFX=7<BLo9hvQq_C6svEyG2#nh
z=PL2{H08#+RkSG8D_!HLU~5_l`|M~61|fO{sB$z4Uf93NbHjcg(HKW<q1U>6B1GRn
zYZVVu(d1L(n#aB6D3F)QRAZVk|D0|6n~Y%IBhT$n5-R-r4pbIs@e~OYpumEl(EaLP
z*|I;}96n=P#u`#FvmZI4uAZW2dT_#UpENEt4la}K4?RKMA6MVDGn|i?NziU^>CGW+
z1?vF4c6W7*+MFKQ!3^<FV%@EFu#y>%ms>mf_*a@RP(w^=!iWx{kQH7P*s?qGTLX2{
zjApDr#?~6=U?wpK?A5V#wEX{bpF^q0L$oF2+S!>$o=vsRSgQ}#89==i`JIG*>fT3S
zR6RL@1dV6q@m6ruyX?5jqa0BTE5a{iqSDBOX7k5HXhqXzIZ8|vn=1x#LyrQ=e(-M8
zz&Dh@sb6p$$eng^Dy5T~>Ax1K%v<jGU8biv5{Vv6_Sc?>w6*bxzt@*NhJ4n{oczn7
z)%W%bC+39lcC{hRzw7>UENVrku)?(PzPz>u2ny84Y+TWVpyB_Q$+qYW`Y;`h6oS*_
z4nDq@BIf$G4mA<*M<_{LK@97pi@-M>R%0GX1g*$VNd(Hakg@9bG^kPgil5o>(`D(Y
zzEKT=WCtCM6dNhReNTKS)|vOjj`p9d0f7=q${LcF20MoNUi34ImI?VSW%;wUtB{Bf
zq6~K4cUw<?Lx1v*6o>c}3DHGRWX>LiLU$tFPUqm1r%okjSZ1SnJR$-qnE2^Q?!m^=
zvar5>#HQxvJC~D5q)aL^4g%l-&A52cem;}YdOMQZ3i^2?uUMRqrdMWY<mJ$s)3y`f
zJ4cNyDxxfXYbMRQOu*D%4~ZOFA6vTCNV)f9Fh=2fD`#O@Y11VJIqrr;;WJB#<%QU~
zu-7NV3@8%oZb>Rw8qQYM`M_(b3Gexjf%N3?DgGi*4VZ%nuD&o~zK^EUDc_+f$dQvE
z`@Ca@h_*0BU1%X6DH-!U;wc~8Uw?$|<VUR~>!1^fUV|`Oli8Dyp^8CQOguCDZ`QIz
z!vugf$X6~IB+JfVdt|X!X;dNc%H8%HF%N9;UlB37S0R!x2VZRo*SOz^VHu;Bo5zV$
zvr%wYlPfYYY1DImwa*uz4*f0$e?^MKmsSI-d%c~$9h5Nn`g4cDjPB~G_IK=hu6BzQ
zvGSR1JhR$!VPPe|kDNyZ{L`g{CDXN>$vZmGE$?%nI!7k(E8$G6&DWCR{<eKhU1_XK
z$D~(*7-jpK8q@98VUfFivU=_P_7!d2DRHoZb`UOg_P%7NVlF26)=mgzI9s(X)l2U4
zIpWg`Vl<^IzcAe1f!gP0wSkK7{G4nq@^^>Y^P=5G5LL2+H&=TbW&-5wooVP3_w9)&
zzh0?i9GsGW3b}$0%$LSBcKxDYLq*@$E?Q8($&+*m*1IYPL<p=@7^6{CYYsR?Ba}@F
z3uQ|L9&P=}C1AQYT!SOP>fyoO@r_yP=?xMM&K0^3(NPaO>iGGjfp56@5CMIFUU*vB
zU|rdu3M6+{n|&A(q2>Db6U+8iKr=2eykhSA6pRF2*ID01*E$KHBzw{kL1*pa$wDZC
zM~6_0phvsCRp5t2^GpwKLosy02>KFWLQG}1!P181T!*ew4i2(ZRQP_?1yIQ>S($e<
zb8@{oho-eT$?6ZgBn3;d(jqRxVbocOn9>vPqc^grMLkbvmRBUkS0}KbN`nRiiULfg
zhCh`gGVwQ9KmMZawE1e@SbrT~shK|{=%zJX7w<c>(s`dXV5@WtveLP>i^W29-*q~z
zBqc@N4*Tyar6_!)#T%v5G%`>M_K&iVsnT(!DEdw3pmysRnMoIe#EvWi-}>Bdp9w1M
z=ngJ#e!Z#a);lrgTmxpn-DvGl{=3istBB%0CNCaLe@g-D8OlP;aM1r8<7(9Mg~OLY
zS?{V_%f)8g?-yd=`)mGMNaOFmup+Du!9|Z4gyha#1hy7d0fx{QzKWbHBI$J!G8HtV
z95b;jj9lf&4osN{_ZqB`FN&@AECOa2fD2Tk;$x${H-gGx#El5$h(BO45tZH;vm-}3
z*c(_k3^an!oj}O+d69#Sf<!Chvuv0jW%fcFQ%)*h6>(Ew=CG5q1P%x6%4W7J3`O5z
zol`Wxys6C1#n2-&vheFGO{BuZ4-6c3;~xF$zLyEN+NAg+wU~uIntJ!w_i}Jni~gF2
z=<=4D?|Z2WCM<<oQM@^!cWLuo#j(oj?V<0VxA6>@w>xF#h`!{5@ph`FbV9mLJ+Ia8
zw=uqd9{>l#(A9zDh!Exvo$I?$mF60d7#u!c>>nSYn{eV2{{|tK(ey&&D!sSei@tUP
zTa8tWBYn)pf9Jq&1{*vpD2ioIT>U4_nrhf{E9YqCct-l{Qp?L1l=M^9+AT?P<Jcja
z@0Zz*j8}H(Qd_Ib5$fMm@dff?(!1VyR1YsjyDZSo!qOrkia;y)CivdLzJcn~6H`W5
zM*5MT*DLQZ`Ik76JsUCI@rv)=*pZN`$(@2MDH9gPf#3m$)_e51wWk!<{!B%cp=7Mo
zV8h<LWcd%&a1>DND9Xcjxo1=UU*z|R9;NeO*Fq@hKKPSy@wZT(5KjIM5M)NhCcmTu
zMqW%I(k7WMs6oF_5dv07oF7#d>YAU9h>uoQ!+|kA?T*>Tx`?g_Eu_m%%S!DdH8h5+
zuq-TCi2|Oxk+FoUizX*JYt{@NYk}8>g5vI*=^P#KFxHN|6NZwt$!44rlMv*r2j*es
zy_CMLuYGH~KHNR55fES76fL@Gq(eD3Z<BxA>U4K}!?R^F7A%+Osd?^9zU#S{0wYqK
zCE0HVmR6Q_NqP60?NIj*j_`+Z>>R=pK03LHQ_rocw0ORw&-&c$%YF&HP7>K+-8=bM
zCzhh1;e7Msd2$O6QsvY*K)wFwO+cFP&wx?oUn5kdu;g)yT)3-J>jQB9k*7`K;X3d!
zjw(`F34hc2V>x$1nofFle=5BF$v<KGVGirz2h5V=+ucv7KQK&KP+>(x$f20vuzl^b
zP(H#cK`5e8=^(VxP<^)Sv$XJz(C8wNi_F<vTviAdxw|w;LO6dIG6f=Z<B!QplZx@7
zw_-`jp~J>?S__W>eyJlTBA12bGIEmSH0!QE2{#DgVPP^5Fhgt9EVDS*f4N>9w%_Do
zKngx|LTf@)Fvr9#P?u>4Dn0}e{1!@zK(r3(j<gNv633!qO4vI`uA|<=by<~(H6H8H
z3_!4)E|5o^KRD_T)&3+2c83>*<`1|v`=xQk2m9^Y#rEV0^_i54MiN$)nzyxw<2h%<
zlP>GTq>(FBqSwxow25_LycW|utEInM3A}b(7%l%^PP_`{qF{>(cgWl@is84-_=Wm?
z423VxE9JoGx6uc|@1VqadFTyN{KKf?^{O<)Sg!Jo+F&in7_nRfY>Ap_-hnm=)c<{?
z-2Y2yor<-!ESN!sP?g5`3{B_XL{(SKcVf`jzhur@l>MgJiMSJuEHNM?g#Jnq%m{is
z5uZO8$BL-P4Ay2RhvhL;KW)_Y9*Xq^YoMkDVUl7l3KCT-4l6g9UBb8^e3kqBC-fI#
zTz)8Dn9%v-X!QXg8oeBJj%F;@T)m0SVU#_*8q2sTgwEDrR25%-4Ua`(9JgyDff$9B
z4hgeMCkcg`=NxRY0-Ky<SNIz(6ePr=0qD)vsF&*^h}JAYf1L%8m|vwM)A@^FD?pN<
z=%eAApy<hA?4gK4#<hqcd&NXDr@PS<UC>2P{LyHf1K%_uS|8a$*@XxKxS{KlD5WS}
zCD_*Jd@Go*m8aFwTMz^d$J4B2WCV9K&@l{^@hv3QkaGDF>ZtN${e}0ie?%Is@vS|f
z5lJ*&^pyVkD4Wd6{P|8SM#-8-W8|k1cDl(jDK|E3jDi+jycC>K_PFuhpAK$78N+$k
zRB3W!CJ6D*GrkM-hZ~`LpTh59s8cz;G9ANSQDVE!o-BmqD^@NzehW)_6|y?rZs{<6
zZ&NbG?&S8ZV4F|b;m<C*mNCA89;zWxj$OwL5}gV;TTm9_*?Y#YV-AaaU2OD=7B<u_
z{|3?Dn}(5z1V>vK8WXc2J`0nCVhTthSzFyyFj5d0N+e^{kMPJ)yjc+JQ}f+Myb0(J
zBE(%VoS?ZcG*{2^w1pLoiByK;M@3lhWv!fMSsyM2vYL*wG#Si{aG~^TL_!rgg)u4G
zpE~oAX?#Q?AuPTw)?-wL2QjR>*cT6)L_CA~K#Ym<qRrTi(~^)KN~}u@b4uibk;wG~
zdBR831An=`N(o$ozD+Dq`P+l~m}V}uF@pUG<p*Ig7`=VE)N=UzX+UzRNh4xsjjVd;
z_Yh^MR!kb-UTPF<`qdjBuj+r1_xvtaDYo~GI78<6Zv0eQk2~Vt%&)odF12NHGlJ$g
ze@VPy_lhkp?l2v106ZkWkIOCVx)72Pi8O1-*=w{{7m}na{(}#pO#{BUutnH9_<s5h
z4U}eZ8d=?N2|F#-BM}MqWd{S<6eQQZ|F%&z4+L~Rr^(TZD*}&u4jlwYzI|nA_&;+8
z_hze=7EiO+_;-^J*x5IeKzdn$m=v3rSDqqq1Q%JH6TBIEPVN@6n^4AlES=#?mxH*s
z3mskQ^Z$PX1++cho%)n9VDV>rXGdR8Ia^`Sq&9|1N)czk4)FeV7Dp}Whqvt0k2p#N
zNd|!TI>@k1&ju(#G(7Qezl)Ghys)1W0s{lVf_UiWKf2x)9p+f7FYL){C|I3D8zWy1
zUi;tz;H-CN<_6FI`niDaHSqf`kvqA6c|reX{?J*wTn!vQbxViQ#0^<-Dc~&p*`k*o
z_w>BlDD<(wSmbuJo?mX~m7P@o;dzDk<cNw*bPu2HxH~5jH#`V2qi}~LR^}Ogm=6)b
zUzRk4GY~fuApi=XvJCcVc{rsWtWYgg=MgmQ^n&BK$CNfk*&|cEWY9}np8xxf!1DP5
z<MY=IP+PfVQvAK=%+Z4VmN2IJF|Pf{5JO_P%4m3^5f)QxQpo?OiV98En$kEgY$NU=
zYEE;~R=`5Yt6np5irwCBZ<1({G5^zEI`}$Y#Arxw*ChmL)$C1fa;t?1nya54IX>+*
z4`Pw8N|){1mR<}oD1HNc6nCXf)_W`?ay$ig3Vzz~V|%5qYC;6B5aDpV+@awSTp@ae
zF^o()4~x}vnnI2aNZVgBz04%Yy!8VP+e5^P-tH!R_QbvLFf?YNoa~B9!UDClUSA%j
zXQ1DmGSVn?j6zBgOZ!$($-T8a9TRLcSH1-}EUwl{?sUv>8QkSaY31_DVH&(dMJ0}U
z2T#g;932xSny5V}@n&ykx{mj@*89YDWZ*cyQs)h3C<Kg^^X10xJkz)bYM@dzW8y6=
z%%h7q4J(&S+3tQxWG>A6m^BtRul&}L_syf&hJrVQ>N6_(xiKrf{I4e(C&jf!65Rwf
z_sBo@NoLL<f+t(V9&*)W5{{8z;>i<21W~+stXiB%k{PUf@Wl(ss)WQCl9NsJETHE>
zru|rrTBeoieuz+FLXkkchS5Tx@eBy6pxwJrk~S8|ji9i<U@F>v!wL}<dCw$~0e`DS
zHF%OsKhGUfxc#0U+Sh|Yn8P=WO2w18uZ<HbAIZ;|KazJn(!WrG6!Hxb#X+dnCYbb!
zTm{-5DUqG5Sd>))wspPO?+c#NKLa25@1c2hL5)qfMH;zNTRR_LIlWI-NlpgUXI_46
zWK`o&9Cqa6EgBb|1AvQ1Wg@n={rgqc=JrW>xHMO&QlWxQ*W01X(BZ;4fw_}<*B+U<
zKMQ|obBF%MR+Lgm|G0xx)y10_Y#6OL=8Oq)W=W58Hm0AX1bvW`oZsN8pH<FMb=0z0
zgpGsYIBkdDSR|1t?fXh(%oc)4o;M*ij<p%*lpRYik!FA?6et|LPWtqG@MxMwV*2AM
z%BQr%;o4FDAT))1)C@<0cS*WoE2Q>&x3Aw9s9KYugA`rVPxElj_^b!9cqcG4Oby)t
zZxoALmiBIV%FI4vFJmu_;aUHpj*)iur0aR$Y}cJFGvnXC){@ea(y``or;6|^tjMse
z-2CKg1fNRoP(V6j)~XxabCizF+rI<u3BS^cmVZ;oEfxArw(A#r(=N+)l8TCx`QO0B
z<LK6lRSD+r=?y?#<l-TI0;{}0RUifMO5jusSXzJEC49*ozXnocuwBn#I=1X_+|ISM
zpH>gncY#LBW`%4${QBbJ0AQ6mJN3bWODv$5>AL)R2Tr|&$xlH}3SjikeCc|XbDX2x
z(hwRNnim-pFe1IP)LVa5NjD6n#Q^*CqF4utjy7v(Rv{taA@gYm#1AE^HAg<+;o1iL
z=SM|*Utsu_1L`60C(_U-&(IZV8^Zj7z3Y*Yk?ZS*qL{!N^CD70{`Mk`0;=N`@LadH
zl!@X2wb%7-uTWcCTlg#{>fs0q+}n8n?R(8i=F?_+SEoK<oZGxxP$B#5b|E|tJH9;C
z6E?>&`48E_G5!eAf&P~A)4793A)-Fj6@t%z9ySYmO=|TctUn$hChVlT{?fzM()MGo
zWSBFVz~gzLwdX~+S|du5_v2#Ut}7RbQ^F5O3L`_PN}h}DePJi3{f(G+*V-QN2xEnl
zM&YVcJ7`VK#nOE8jQ(J=Zh4FQ@ayV1!|hW>356l)T9@LJe8i;o?VMrc(GEXa+45MT
zD)twHH#zSKRXC`9`S87;QYMWtyODW6z9-<LKya&>K{O-xvnw7@$1XlI){>@ovR5TV
z2;vozNM@i#)ZtG5NBK#b>+V%hK@vgYW6tOU<H<!3d+;B73P*~<ZzPr14&1WuHNCxq
z{=iUuQBywsl2B0y-;}VpyT2RW5kX~v{>ZtGPrx^}Nl57s7(1PiBwoim@(E7#qOpEf
zx8Ctc+lC?Y9d4yMOU6znHv<Qu8pp!ej$Yf%!E83nfTJdqShy;V_=h=@&aIV#(pl42
z)iXZ#$q$8iE7uvHh|@dnTIP;IX?AE@`6T3D7wdPpALr^<XjU=WKK<^>{v)R!nr(I(
z)BRAdDE5WAc7QjLnmxb?_m|G#Qk#m0TQj?o*bJvP#<@C-VD~)5Q)$MQ*MaVE>#K<G
zwnou!?BJQ!@`{oyxSQ2J8$dw{L&pQBClFQ1{gJF~1CZ@({a!iusz&=-+p_kfOLeiz
zgh8tnk8>(I9$+JuSsH&86hhE7{29kn?rOzYwE6X`<F{(<CNG-VRpnYIatWoMzuEM&
z*;SSMI(47JaDD7!$1oGp95VDcGN;bPGC$jLd?0=Q5KV36<jy?rbbO#TRuHl+ZOX~1
z+qkHyhP}53ej?o;Zp=m0>(`1={OOW|^lDwJXV#guIZI2vP9CHlS+`j{=A$)_ytRJ#
zo7+`${V;lbt@}j2`B#xT{cKi7*&#XRmE^w!y&vBL(VynHe;8BRuGe7>NS4b?sVZ$d
z$1mC@PU}=O{6_tih`FypRN#Zhy=58kj?wjeNp+|g&JVn3EYPi~Hi+a#X`8~-bp2nT
zG&xD8p35(Kj(yEj{6q}yuMWXRa_xc@xYwzyJU$&Dt1K^XkB1NhvGMZWg5Oy|Ohg@z
z!}?oT10$mx@Hg-~Z@vv|4ADY>a(4B8<r>_rML(;!xiy!R3>n)4NtBfp>PMP5pcn(I
z%|4gvK0wsdU_M=NxjzRqX~_l2L&lu44$V5wt-7i+AA-@rV)fp>{&UM5{}v}%)Bsv9
zI2%F_exvUX?9w%iAb$z(&nfwr?=H@luBJM(ZaZ(qrK-veJ`2zhmTWq`009ob=m0_C
z0oc$EkG-#3YZ$?eH`vrh^e-uCsn}75)}5o48aAm#5AI#J%~PV6od!XLN-At%V`n_`
z`u-7wM>g4MPFYn|T=D9q!(x?Tqw1zV)`~b_{SE-M&Q9IE;llfk8kcazfeLj8LHI@#
zP#tAxfE&wu8a$|VBMdlt052rj<F4fXzk-ZedBMwgx-ejpmX(za%h|N&6~)wHPNb45
zFxM+-9IUab)?g-0dnl+~U|h3rX8v}Mfblww?Q;-7iUA9I?!`a}lTLRgMFkbaM=$z|
z8+c@J!(c2f{%vFnY@GiFG%p~pxC27Og33yp!^L{=Li>{&*Dmx1V+aGzSmTQO{&Nz<
z7hQ{oF_Y&tlZDr}tkIS3_Ndq17cwUi(><j*A4UyWB^U?PuaVa4Cf-jrHd(+ZD-)s6
zYv0^+mhL4fZYoX*Ss}$&I&6!ZGg7{#i61kw|B+~v^6nFU-HLa>%vPH7OwF{g&%Y_t
zACB7(mD~yA*5=Jye7woX8GOR_O@eIf-t>3lANnZC-HXgN-wM|<Bnt*Oi3Ej&$8y)k
z!E424Ri2P4%Y=O7Tjb4{iAj&wGl+Z7_jAI>!KXuC<BN_+u|Jx@du)p=5_U{@m=p^1
z{wy5mJGSU9gb%hv_L%-8iPhUoIWup~gNil9Sc@-C*07&Cy58Sve?NXbQd`|@$mdh9
z!0dFEd*1UA`<;V1>NMxZY1y3R&ksKpj2TP6{86*241I+frw}wCe_k(`lc$xw``p!Y
z`OT~eUVW5U*_YjHAZeGnIc~B&LVaCE^8zJ*J1v=^6`>_T;KsLqFX=k6HLQezBl{yC
z5B<VnOHNU;l?l5*)qNJt2uv#m+JTTU5j?pxo{j4FMiVUyb`61Y!=YB;3;r<`8tm9I
zE{_=e2~}0OpCA5^dc1yQpQygw%YJjeDMsm8{VB9>%eE}(4x5N0@Uf1o+62qSCsH2D
z<&^Adt~S?R*?Z_;cb^QamY7qD6fHG7J%cmx>ty4GXh^9sJWtY_$^J;gNcy~<3!W-s
zV_gMgyjY}I>NXO{wmu^~jD58Hu!DgJBvSOv?_TmvWP!{yx}+R~6dIb3l-3MRdMfGN
zJeL3VB2Nxe&Ahhc?K!3B0>;N`h;Y)Ew5vPp@{(o{3#vkX<FJurwrF(PMUSyA;4EzB
zD@D^G%N4pd^Vuq83yS3KwJ+-NvnVf0+P{HGB@_}JT(^}-l&u6oFX5N=#mOqVz)8$}
zMSukj_pCP!7c0r$5dy4ew3V}@oz%<&T>raiTKBOTrnVNNpKZ6-LJEyHQEP9WwkZl@
z3$ja->ncjd{wm4TS`MK2IneH`-iugJMiUTw?=fT^dhPXl?uX#cF<NVm>BBW=NjPvV
z^HP@HD8&0ww=r}#g*2sgy2qu0?iwOuh+FwMPwp$nB4el@%b1dWNa*jB^!=4k^b`gm
zEi*?h4|XK#diW(JPuGAE12l?fhF(B|40vVD;3Nx37+E^~%~OVq&+-%X0Q;q~%(FSt
z5u8oYW_rH-F90M<Ju3xTc~^m_!8cLHwVIW4`;L6#ii`{l+BL>VS^IbEy}^yZS8p-%
zRuQLN&qh{u6gUcApk>+re>n1iV}5>+ap^F-T<lJQNJ+|Ly9Vy9xKMK&8?S-nz;|RT
zh2O;*sD}k!ciOJ^^!15JNrg`D#eca?v8;fSkdz!x<Bc0K2B%}%T3U{}$A^cP_m6;U
z16WboO}2&(4(Fyq=Y-RoK%J(kr?)aczw5|{@N$4sG`=%p%<d<W1(a8qh&<_Iv$L}R
z%3;eR@M1sbC?Ie|56%UE3{F{b#h{=dK7M{n3k&ccj=C@D=oaq171z?-95(=U0PqJ0
zwqlg)j(lE1`VI~bG;w?X{?#m4-3F*>YVv}I1CGFln>js?!xpFgGo;Xx5}>LCGH8G%
z0P=JIjWVg7nVV~@tNR%12yQt+VBdGA!Uka)z<Vl6OTq2+scTzdp{beK$JjhT-vI%d
zFMUjm(y(63N%#2RfP{bmyc>Z~43ItT4|RIo`q=-+RRTgnUI4=asJO(Ai+ops4v>yk
zdTud93Ei1Jl~-3+gCv`uBoY8cqaq@7QXXzHqo*#b821ZkO7;>*imP?3)SoLv-mX<m
zZ2LIbm{E-k=o@RZG~Nn2wcNa^(2RT@^})i08Eh3JOoC#UpSWk0v^HL}W{YO~ZQ<hP
zq}zVf!1R2g&*VDpb(%eSAy#Cv2MvKLotDam=C>~rT;$eJQT~A}clCAE<3?K;HBBHh
zis*b$_}w2B4ZGPIGq&ThPAm91@ja!L$JT2#$sbZw$vlJCm0N~Tlm3s8RR@K5qnfC8
zMffukR5-@904^T1>D}s{`jZl^O48*CjIF9yTwS&qu^3Px0p!slhz8r8+ga1nTHWT^
zeW9!Ar5DkP^bNVGI&*!rEOGVK+IpufYqc9SNd<Pz%x27mN6T)fS4+fGcI&AK9W$?v
zG^bC(l*|6*so<pRr*9oM)`rBQ{Z6Mic+3Qdr$M5hRL$P8EbQ!*dG}KAgYZn!icT~B
z*KL<2^1{CxckjNCc~{ov5ex=W9zI_>FeNfrmqlG%$)_F1ZVbir9um;_gFvc0p_{*T
z6gF)BsZ#4A@;WM=uYkcu!#O(6?!&a)(?2$S-Ny(gZi1HA#IJW(8*_nw&o7`A?L+PQ
zY|PA%$`1j4$#My6`eVh9@>5O>&naY^x)0Z>Z4plK>7Gu4J}&Xk9O0?KJbw%8Bl88@
z9R2W-6Eh8r&}~ITxJ9W{!Vbve;qc={iQ3u@sAJ$zb|)~{lfD&1B7YQRLESNbj73D%
z7H6akJ1V-^-I9A3PffAmGO6@4OpE<(u*CcYdWGAAli1Tpx^f^{uNZfe`yzu*D-Nlm
z$P8Q8TYJxV8?x@t8?}}<7tUv$l^@;&)`pP#Arbj5eKpTebZox+y&_68)h4`>aE!P(
zHi$Pe@0NIg*>+SCM%?h^x>VR%ceX(mUpAYQBCQ?6?^sQ{ynqrCONE&8XTLN}u+wmc
zZ<12?lH2Dx{N5(TWsd)`c5!8s_b$MYsHMUJua$IKWh-swh+w{xBT)vGj6WJNV$^L!
zuppc4_S6TKe~jd=Qc_$jd}d+F{X;%4zs-#LKrFSuT48+{S60C27tZnZ*@v~c^JebF
z3cre&>1e0;Ps5+R4*raCm+=V5V6iE~((Gcgr4!I>8t^g}G?EczGYVJ2w6|0|(X0A8
z>aMoAozDSDwI{Ug2w+#)k1%E4FYnkl7t>&hD~_e}Ujr9`&skjN!=a6j$6f&U%8R!e
ztf)LcjOXU&`j(UcMQ>5jE?`c+guvk+4C>`tFKS5h_k1|WfI-QdKBjHm3|FO94#KwA
z)9nt3R2?VZSb&jt(W+r`a<Z}GvOFA*37GEzj2q;X?I3c;4s9X`oj`T23WGcooO3LL
zyFG9n@C+_w8>|+TR8{j!{!L6w{7UAStJKdNHR(M2QHhFy0c6*@ZLW5`L1-`KxT@+5
zpipuF$*N&5eCwYTV4-$9H&MiidM%hDL-T*?%*hE<-_!)C%%GTBZgzO_)PQ%Iu<&p)
za7757c78>LwUyO@dgtAY@Z+@b)&ejQngI}BkRhNoAFOshx2`@OfoB2IL9VZhoHi?M
z<DT0biILhJ5y$q;pl$|V2#C7df!YCtZ!%y7cL8o};QURLq1pMB{0bF*<Md_;2yei-
zNxF>eQ6FH!2tkF2Q37qOMZNV(o7=|E?*L(8QcH~;D(`bQ4T9+7sEzmZ%8GTh2EY?C
z>onN{u-Wsa{<9N!J4s;D1_<m-9DIC__7!j-DF{@o>iS-n03Ap~M3ghR`vMTms;hGZ
zWx{9*K+WGGKlRvBL*1PFlOu-Xvy5HCFIY7ITA^nvE}$R=frOTuiwpQYudlAO%4cuS
zcRG_ns!l>Aoz8<*a{AlaY!R|sU`_DT)W!QM^t>~2i?Xq9jm6O+*?@q6#xA*BFa%l{
zapjc3eI>8F(l0qGSngE=`B;8mAS8K*aCxjK=+>WgSw~Sg0lBa(VX5Qv<GHNzp=HON
zmj0s(4wGhid7~~yQj4|O-AVUn-P8t*L*bU4k*FZPmU8C8(mJYFVG!sXzoRbg@iU`;
zxKroNg-@fW+^CLFq9UAZ{yOvB>JmIFegAA~m;2Jj79pk%aQCVRjDEMan0MXimg|&d
z5Sta6OAxf7t6<<o{PE`D+p`eKkqO8R&gaDx!PYbHgyT_quTQ;$Hp6Q3x3HeP`(lVQ
zO6_Ww>pUw~ApJWzCI<6`IVClxKNqbG)S}SmE4+;KCpt1b{N2}49EJY!9U*j8qn;zj
zLj8OuE0x!Vk$nm)-D6qNud<evDK(kUJ^N*+wX8diQdl0_(_~axl4%ihiiryh1@1GV
zz_zm{uTMiZaU6b28g)n50>^%(Rx;YaL4}brcWig{z0Z|r|1aKKw3%P}XMEZ$fjsw}
z=auU#71bOAq~aYYsouoIM`XetJ(?<73q0fcLbRNAc5KId{XR=Aq{KG^Va3f(@Vp0Z
z-%@*spEX!zWS}NRIM^IjV7w5XQ3d)Dq|Fd*tr7H*rakt|v~6$9FBR6mP=?zH3aYZg
z<9A~?7!uqWvL$78p|HXPWuZuu%Vx(%3#Z;P483I^4KAoH3JWrd{J!<{WN~D+Rakg4
zrl>Y|UY?2^{8J3OsW>@DT?;db=03=bY$uLEYS8LfGB8!U>Jy?t5(#PU@1Z@2RC4l`
z=QUk5iM;-%sVOECB6f>_su{Eu3oWEY8ZdW9Y{wyS^g=(oGbiYCT`(DJto3diT(oq@
z#=f&4`@3#%cbxPDKa0vyA-IqY_hXMu8KssYD&vTCt11bd2QAHdot-Db|KjIuOOCtT
zHY5r%@2E-b=Tv^>H#ByRrmp+BNO~uHe6(%7p~H(m?v-E6Rlrb}#(3l?Wo#&tMwLhL
zMbVSTxYy2iF1A!{69<%}+x;EYW1`(el8!jomU-tG{9xXdp8DHwj|by15UQ~)*|`HA
zhN2>|_P8q4@m`{NxbSRPN5uEEu<P=Cf~Dq**&l*Irl_A7Zj)l-<MSNl^RRJ$+}T-C
zapZEctz4`kDLF7duVHFhNF|kd(?`4Vc;w=<217RZYD;!{8DwJ%wWcpYZF_E<7V;9q
zfkY65CLrtW23+iN?Zy_J3V^8sr_!X^3cIEHk0rqMoSqI6tmnV@of^P^o=f&<W?--e
zXglcuD6-~<uyR@9k}l+Rr@eZo_7o0S=-1!@g`aQ70WKRHUtc~R`*Z@-PPvU&X-SFx
z<3DvW@0;}*fXdcwz4~h7p)D@nkH)=xvM}y_HLGm{VD;^`>+e5*-bmwh0Gwi8Q1{z-
z?Q2(Sl;!4rzPs2141|yzI?y^zO-gDK8)*)-;vz;5?!0b4#>K}UPvw4Tee~xexPvmF
zI{@L)`x(%A4xC#De*S!UGT^Il=?_D|0r$(d{1Q+>3k1~dn<po>-fjY~pZ}?MYU$`O
zB7(A^r2@p#%vq<$`RdOv@$mzOASdXyJe-gFoTsjO9#jwbf_EkmmmAB=%Xh}o@4@GS
zM$)Ma4T!wn;4VPu;iMPzU*rW&`!IZNdR0r+NCn+5!0YiGNy-nj5lbsq4WL780pw@E
zuq^N9rQ7|S*c1zSaLWd%EkN4I^9g`&|GM+}v9bN|>uqC2>rqQ#hWlFr)R$;`aX}C?
z35HL_F8^Gz3QgHbA}ci3@g@EVxBSfwtFZdFc=7%kMczf=YusO#(Z6w}O{_C@LuUT?
zExfE^(xTW+C0aFb-#TZO7;WUPy~zADaWLZUkZBR5M)QpWFBEAwWk^3@!phe_Hw4J@
z4oidDkEC)VC68+Q!##Rq+n3&iD50q;ll~{4N9(5AafO+_!T5qg<HfLu6v`6ZDcLfi
zZkBxwPnhS;+}S>y)eCB`gu+8t6T5T7!+{(6tk}c#{D(I_zA*4VrENush)^U-)cw#7
z$b0nhy@lUI2T3EoN1!sO>x!O0+4P2?bEt0cLy3#${UKjQRb1uaE3ez{fbVwvzTx8J
zu~EUEaNYjt*t4ed_jr!QaKS9T-e<V{{q611UT)4&URF;L9LhuwuJ2Uy^Ftejm~f1g
z>gu0nPv<yZF_Zh%gl3nc!VnW`NKvmbp8oh)v6Xq#l@=vr@Scx{@Q_epDmi161xip`
zzh?dr#seLGTn9ok=G4M499~jlU)@yby7({ZX``Ui=Y&+)C)?w`V3K3t9A3%>mO9;Y
zor5gnPN{_5{p=$<YYHYTbxbUyT33QSSEhb@m*+lIhX<MuZCtdJj!+M0Lc7#bo%dDn
zo~6NzTnFF#d&gNFV@n}Nj)~g7pS+evO}6~i^P!171kIFV{(IeR#9>fHLF9pk(6Owj
zyt_fnO^E4m+J6{vK44J^a+L_;HICwqf3d;?Q8lLC(+#7Rp{bZK(<`j=a_n}Q`+6(%
zA!2yU+uD46y;Ohn_&C)5ZCA0~(;ctO1e#17#@D|o63blZ=o|?t!>}@#a5{JeiPIYL
z%RP(ZlV^C|Es;Yg-`3CY6OlHJofuE-WvbevcK9aQ(eW3P-)oADZo^-bycTj?p1AO-
zG=t&PWKL((9T^s}JG>a?MX|D$AMN>a`KdDOJE~5{M(OK^O)}j|hm(^G86L;m*uI;O
zb62tfl2@5eqb!c9hl>q%+n0@(hf9h|fAV%zvLdM&ZbeciOrENP;Ew+$wuO2aB;4>6
z7S<lAj>w;_ejqXYN1kF%gTQN?<x<1cIU$0OR+X)wEAXKqNaxAErmL*y&vs%JqJ$yq
zDt(^$IZNEc?Z*4*I`EqeV$u%MZe{=A;2=nmJcU-hKox$n*1ZaD{1qob+RN_q^Z<e*
z)c#zh&&_(U4d?=RLIWws#N12MbY_-I^%e`Zd*>Vt17p>Fzg+)zSpDgg?AZ=r`arnT
zt6IY?$Kgu-3JhN017wSp@3SXBBp@Otc4$r;*(xb6h5{rBwMsqU-h@(B1)_s}=hm0V
z28PbPtl)0~F!Tc`^2fc79LR15B|$}h4Q}s2+jb|z<0!H7Ve4R_R#g>{Z%K)X8R+SU
zTow}Ifp3j>dgBz}(o#nooDUZTyq>>nnS_Uhsa5Fgo!>$-$7#cqg{J`c6Qt0;=jJ+(
zy^cZS*Ox8~JV~L<V<qf&AY=XcQ=;`x2JK({VFO*}xpbG6<jf~xV&ePTai7<KVBKv%
zhXeWt`gc=_GSk15qt5ml>+63cCVq+q>8^k%X6%r$!0SY+;*O5jboBJicmGPyGtb=H
z!B==`gMtDA#B7!q%<fDHh?3=hk)Ph%{hx5sg#la+cw)4|w^HD(4REuCZ@MwIsqwde
zCC7D=?i|;mp`n3ZgpG+zFRRS7;{wTR^>4B@`SHIU(#O9S-lcwW*pfTX{=!(C%^^^K
zW)}M$-<<4~2_A~UM`+*g+)Mm7@8p`RP-FPyLE9(2PwrLBr0!Ne6L%T0;PTT^dMABJ
zDHbx;uLXUf!xFkwyWWxUPt-qJZXUQk%&`cy=WjHoI#i3T$WH5RHV`qt`|)+K+%r7w
zc=w&?N9?8;793@k4y0Fqbsv_DR`znQaOAIQg@?Ngy{-C%1{GiR`j>}o^N`XM5DOxF
zpBPlJ{OWzduAz?z%M3@~YYQ)sB|_fWL3hJw^l{Qo>$}gNu5U;x0oP19`8fR|*e45Y
zGS=x*)d6?7u2u(LEYy+eeFScx)+9J3sn=`iWh^uDAY1ZaqbNOFLJ6U~4<-oPdyVk(
zx1uaf90JBs^Im~DzjK7|#I}u_>*cKznzFRmBU{6jtr-F8WH=N3Tgz{6_xIEPQYcZ_
zBmZ2Qj}aZofg-H)ib!-1vw2*6(`!2RmibeMy0#tPrg6#rH`4U+_WAbPd_P?TI8g<M
znuH-}u0+$*M>5+)^`qzUN{Wyt&GVI~=^ZQU@n6I?nRcV!xyDO}tlk_3d$@FJEdCbo
zJjf~-B-PI7xJY2$k(s_oQT+sce1cRT=g7pi`h{DNYuWNP4{h#Jz{r5d)$P}+-B(nH
zviJh3ZYrp(U|kpzL|eHxiPTd=;e274npp6tbrQd*f>2eB+YoVCF=|*tCUtiY$1=Of
zFGNs-$RWrN5J$x-_rsuGBV>i69AOjY%I}GMyu4#Ud!E+m%+aIx&dX|HRu8>IWt7bO
zBSD^OSfwBD34$eWPuSVtvN+l)bKD2buY6L1O466oGW>*bxIvdl-@9Fz%+y{tV{lG6
zl*c|VFdsHiBevmaQq)eAD)P*H<@HVD`3sq&0rWz#_VAb5J$`qjFSiNJ|IFbtvdOAi
z(k%D{?VEHHaTQ}p#HpVa&P~hyOn4rSdUT%mAK`PO_|LaJ{oLEHXq-QY{iCSzhz$Mb
z`McUUvEj+Yio$XK`UXO9Bxwi+1|+DWUor?j>IeoFHnUO4zF;ZEInTo%PxovsbCik6
zif3fHU&eClj=RP+HBY%mZ8)AzDRN#jqkV98?jb%>oB$#a&u1&oZjgnd5O~F0)m4ib
zWNFAeZvgcR9!VJ%Hz*rd&!4l%wyEp6+0pw+3{#wKb>&V%`M%rW1ZYzD?f&-FjtixZ
zY+;A?fm$Ef9Fn5WSc3bFia~fQDjHPB1~IOjZkYOP3b+hw7Y=4XdPOe=f5x#4h;#Ro
zQQj|2#Idol0l?`2oVvskSYO7G`|IQ9--SX>JLxVB_4R<A58ArvmA77F;r7r4=0rh?
z>gtW4gl=Qp1E2Cv*5l!H05nu9I_@ko$GJh^1eN-hAHr)MkE?@}cb2mix=Vnl_2-Wu
zXdZYrG2%q8x_fV~DqasVptL)~wf=eH_BrRq3*Q=yc{7s8k_loESlTI-rn@y*JNpph
zlRoYSz6qu<BOxjtm!q_Pqf@|t0G$W00#Ic<6#LSzNOV4%${r*Oeo(meIrpF&IRjl!
z@B);nSpq~5sIk9;I^D_95gg^kNk+YX1TGkFDX&fBr`VTTyS5jEy$tt%#j$|C>3v!H
z?%liF4zezbdS>kgD+7b9+}z$nXVA)MPlg4z-{6B-L$mP=xRl<N7wG?6<xMys4#|9)
z{Ay3$AE9K0-Pp*Exe@MhvqjiLU;UoRLg7<n(g&tjvUra^=w)cXSf(<>g+K5_YJFyU
z%YM-A-ec+TqiIBdVO#I{IMd}OEMBFhDLY~0$j+Yq2MNYDe$(TYbLRC)qfb1#jP>o{
zn`GPHnp&Rp<XpyH8E)6_k7|=MC~Iq~bid+p<0)P)BC<%4f0&p213?Jp&Cqv^{EqZf
zCmzjKK`d5EoWS<)nSp8uKPKL!e((aiR1z%8y#DKGsNG<yGU!*%xCOV$(ceDC{Na=t
zH8iyTrnnWFkIP8eiqO=FCO!~|JXd;e`-cmXNt$(4Lw+N9=qQ<_I>t%%$B<dZ=!fmc
zi-DU1xxbZpgQhA}y*Owp9GQhwaYH+qtM;3NeLW3tTP+B~Fm4VA6LGU>dm8k(obBCp
z+9owmZJqnaBPuWu@OdND$D5CgFL>eKMIfGG(o4l#v~St#npf1)mX;v#tNBRH)WD5R
z{k@sk?K%o*U%Hk_Yu8{iH34@D7JRt{9A7w0dEgYKj0JFKP>y|8(;AoGXqCmz%r@E-
z8rS2gs==rgj{HkQE+2c?-U%vjE8U03IOc6U4b@>kqOZJ|d522+r_yA~Hyk@T53Moq
zEB&!v-l|PEU;0d<BX0T)WXICIV<RGP&q;ARZ<DIC!jzu1i-J^@;%j$BuAD8~Sdol0
z1$7)<4v7r0CUGCZZ^eS%x4Zr%j9nL>wYrexs@}7pc3D^T@=%e(@o9XGHN=t?SI1K~
z^>Hnw3N?AMZw&J^<aYVRt~PU;p4;^GH(onsEQhQdoQC2(pYw9f*d$ht=JpNJ7md?5
zM(m*^El4K^;*N1*k!3-1a^J$As3Ni1Dc)|g?^tgyzrV+z=L=oxI_f{7=9OEcDkgaJ
zz=D;2OAbXN$Nf%@B7x$Jo!Cs2y0c|x%WGjaIH?w4h^8P#XTrXQJj7YPdM0~uIpdzp
z$NOS)GI?(GA9H2ZLi=}hU4{h`yu$rhzkr)Utm;YJFS~;sL8Y@%B*O8?vVk7_aH3$J
zE5?sL6Z3=ejLf3s=#txV4qqT0alL#QtMFPOuC20RzhOVy_k0w$d*ZLugWn7n3u|XT
zU4nt9!c<@oFFa?JMa1-5LJ=yIx2&Z3aCWfySj;{4bTCjyzU9&WB=h77C-)8_aE?7!
zZDlNU`Es8%(QvI}*<skUbsT1%i~Vas(-bh6KN+!C_JEr9X}|M{fn^euh)*wCDu>K_
z9n1ZF4fd$0DB<g6hjrT<V5(xYz1UUkT+PgUfCn`&VblPNJn>n3|H~FoqfO?Fg>JL`
z76_VX;Aa^Sp3UpQ^a&)YTO*0WCtWaLjN&H#3=~vmoJ6SbegOCfygE>L;a_IUG>N&b
zby^(F!7SR;)YQYHb$n-kcXxMxA56QzOzM~X&cMcLSQxS*PG$Smq9l;Zf>;WsLtqaQ
z2^RVxMnO$&c6nI<B!n-lT+k4%Tz!7J1`8Ads|61x2DJ-mWAvGOpfw1FV*=V>JY)>K
z36o}Z?d^grWw0dt&Wt4Ji3thLE-tABdtfA_S6Q)tyAtt{ss{9QLH=z6IKD0W6(Iiv
z(VmQeKm!b_fS1AhereU&$w^jD4s?S%IywkBOg6PeK|QaktgNi1#mCBOP_G5L3oAtu
zj&MF>|Ci7d`rjDo>D@rHLtS4#Qyr@H;s|i<eNMym!9T+GpJQ*Ar?DGh^!dq2tSF2d
z&xUU6`r>B#By=EaBuO0T@c3jQUY@L2_<myJ^TP#>BtpK}R7*&Wk4bWtk-=?K%V0lo
z!bY&vSEF4ht&Z;G%!&Lg$>>sbmP^&SUmX@hYeUnYgXP@!_pSQ%e3lqqBYhr_PvqjJ
z9soy`eQOyXU|2}2n$k|Yu_i5KBY-gOH~k)JfjJFY>CtaRhU8p&UhXg6Cb~kAzMOHy
zjBR(baRy~kUaxdGC+_A`=@o7{#P}CzjAEqts@&O#6fGtnKBki!1Pw9!|H$%({(>1)
z3&%fW_%Q%piq#PNmr~&eZk6yNAFF(35!TThiv*QqLe>4yDU}Edg}-9%pU=7sBFY5?
zns7$fh=b>a`_hn|uh?P@6yM>+L}JntcD-Hi7&IWsT9hB|`}bkgC~(rD$ih#|w_?9q
zLjX_N2;H31$yif%-ZFE_s+qv(Gi|V>0&X|WqWW6pPu1d%_o#(&8qo(1s6wJFSq6{-
z-vfu`v-Zl}l9r8iAFOh`((%s{IbQtN={{$-V2+eLR24gx_mh@tX#K5|jCR9YViXpi
z)m8V>g3F^7HJ!ON=4+VRReSkAQ>DzS%e$eyxaD6byE}#|Q1&Lo_;5)09Vp+ip%<OT
zTlTn^o~4eTyG(1C^y6l;d@yD^))-tm`zzP5YMw!qE#LDx`<aqOtIBc^f5ARxR3znu
zTC0IrKB!6NH!|J{tJ|wkD&^46u~sWi48qjbenJH8Rt#@Z-{bL#Kw4F0TEEt)!bY&;
z=gT>;m&fyID&*^TIArQe=BHxQVla8Q;c+uh<C<uq(OB&jjLMrP1$?*>RB0g$VIwHy
z|J9)9e6`_#In0{;GjQ0R)9_!9>U0s2h}svWZe>|>j#s8qk+x6Vs0Y-u^33RKSF!c6
zh%obxCjChmv#4Fn=^-*7-xTT#jT|(v)uMK>-u@H~`dh~NAV2MsJuzZH^s_Esz4Ebd
zCw3zjU*B^~*dt>=f9ow1zS!hCQ*!kYjVPw)yGmN#hk<|;DGXA<iTcOe?9T}9dW+a(
z#AAW94xvri#THzjU0g>Pr@fN3Ft*N{TEm*%uD_+;?kJ@&&jnc+$-X<+i7!CP+}iu$
z2_e|(V;#Vqs%;jhPBh91PBd2XI)IaLOwNmoMLZ<T!QB-h78CI;oe)?H%<%k@UzIHs
z;tPeGXV_+dO6m8h%Onn)>(fyR{J9?-34u|sqt@^QDtk$@i&)h2DQP52H%NJOngFl+
z_R)LavW(yy)=NZnMuTzt(jD~NJm||hN%SfktE*4JP@e=;(yf06B1v2KD_YN{|ACdG
zP_Y-@W8K9UWntOrmlE3J%Bpkq8Myr%S3A76wzfe3?{?O(bcQHYEW>R(In}zw{ORHL
z#iIlUL10)95R>o$VB{6fIP%iS1N~PjDd~KrSSro(Sz?>EQ=po8DSJUv7PJ^aP2Ft$
zhc9*X3K03*o*$1ZOG`&gYC(bevhtLgl0qeAVQI-BTU%UAFW-Or=C!I+EF<10;P3!-
zZv)sfu-o`)#>wY(cOh(5q`}zWerXXk0J^prS65e_U)KH{XT)}#xC*><769QK><$2n
z)Xr$?+|*PJm{EcDtvBe;j&dss+^huvwV@Y?ex|hxZF<L`#CAEDR|FnUn<QoymgA$N
zryl%{lYAC0`pi7Rv%xpVZsQ)-ZKpp$%3YS1x2b#VuAX7*1ozzf|KO+R=H_N7jus%z
zJ=_ZliVvLcTS43RVIO3)+uy!}$a^OK>lv$9#n_QETH0)d1|d3DS=*h9pK%?xzF>oW
zZ~Vg>5(3P*;pr7=OSs4%H@FeOnyleQr{9w+&Fgd{4h=2{;&Su8_KV|93O)OISSB(t
zmXyl%eNHJWyBXB)bVhbCnDcu|zyB$phLX`9O@d}Xsl_Dy_NyJwMcUt*c+DwiOp8r8
zwX`_L(Ji$<zdhUd%rG&R<D(o3(h``RH#JEv8KWkA5=><xkeCaQLO*UP<E2(JRx8;C
zpe(?>W5xgQa~J*<whWdNeizoRA04VMs#<9gPdRe5S^zFHo~oT^MCI2BZ^xb{2fX8y
zDDzmg(^h)B=;<WAFx|gFge0V2%r8ffBia>p)Jg<p^32IhP03g;;}m#=eoiV%V3Ux&
zNqAFeXKY+Ts$KKBdc7j=u-DO>ggp8E1;qds6ArJ~0(l`JOL#qTG@GmgCr-t+YP*eL
zS+;8!i!EE<q#`yu`h;V57*DRq4_;ZG@D-`DL@^De@ugVJ4~$y#ExS+rl2I8}?T-?r
zOR9|)d&L8ptZ2HCrYu6O)QkKCJYJ$w1rF6b1`Zx2JIvays~!zrd()*t;2%`}q0as)
z=WKhn>vlR(F1fUBSyc<2Ztr)f{v*Ne%Bg?*VCttn?2TLtt~azB@0Csz8H~&))W)J#
zbjQP%ZcVUMDUBinrGJj6<@jq1TiW^SkN%aw|MKU6U@OlTr-0>nC_gt3iMr6y1#(bD
zf{N`$z>)P@qAP4$lEd&_U9T7gu1Xh-o!$U+FC=&=p<ZfxRX=}}Zn6xU_Gfj7gfh|&
zO~}@TOUKVTy7A8AaQ2vj7EDKpnujZBgdkSgjOLH(fnt#{RMrg43`ohYkrC1|y?f$p
zNiz7}|I9i4Vv~8KL$0vMU=`5n7-tD$n17?nAtW<TkwPe&vfuS``cZsyU`4C&M;=TS
zju(C3TP8A$XOgK8^@>?0=if)ffIK6(5ybF6ib|_0ot{n>>_x^?{^Xku!Xh<`ZSS1&
zzjHk8GCto7uFWT3-RvrG;e}o}?Wd%WkjcVIKv4_~-{@z~X8!t-x4mus$&~iK-pf1J
z3C`zhzv|BsMfG=;396Ww_Ea=`HS2^M7lz)jj<s)wt0LJ44U>&yk@%fqs3ixX;bkNV
zC|iS;HGjP=f+uu5@kgX@LfjDzl%j)%g2oKs%wx(i!TlUm3~fy;+dtIVx|nUY7$u+L
z<MQs4CFn~0FqK|K`gL08_IH#tR~RvtN*64M0&fVYB&n&D>+8XGl>FSKdO5Hwwsk(=
zcXrmvy>?mka-oTX0z)A{krsa3lgB_qD=ujPu?39mx3`$V(EGUa`KfJWJ|6?DZGylA
zDrrW&HjUW4m>4WoReTn`HnT~}%<)EpZhs7~-4D*KKzO3>G^2Ve(vY1EdZU-u*Xru(
z<4J6}+1a9CopV~?wLDiUSm`V&`S*eBZsK%fz@d2=%-3HK+hCHVr>6&U&ZVVPxk73w
zt#<dznlB>)ucOEjtsAvt^T1c%q!t<(8L?^JN_dFZ0fluTc-n2hX--(4&sfg4M?ori
z>^i_tB{j@);VJ;yupOHW0-yyD1tKM=*EwX*K~I2=iOGqF1T-E?%FAasnSMxbrFVh`
z<9VpOXAT&P)z{Z&XG5LbKQ{hx*7lADJ4erJ2*ORvg;rpR0Bj{#SXrsyQ0t>rEggbx
z<Sh*#?*l5a{U4{fe5K-VDEKcAP*=B^PUtD54?esDo%UyWNg_QF-h*j8kO+eQaUtC>
z$h5(xtG<$wQOY*hUhV#*JBA^2vj$qar04@*8~>OzE}hGwtDkhDt7H2Lv&du$J%Xp+
zl(zJ_aS80#KR>QMx98*lZF$EA=`lEA0@kDx_jXWH$Um*Tyt#Q@EsP8hl992r{i4AR
zm62e%;#HFV_p2{i#9}icp_qQJg4O(oAdJAYAOC)HP|Fg^>r1XaIGeHypTN)^!aB;=
zhDI7POYP!ZVY8lBpDWI42<Ix9O3I;AY&sfFQ%VbU1@nh;^QLw(J(-_dHj<f=hiu=n
z7UxYR{={L5l`l^&{4-6w95*Uau@m!lTS_Ai)-nmB$I?v*ev#1o)t92s--H=c3dXTs
z2ct0|Q~TYeuWAA!HD%ptijp>>gNPJFf=ZxG-&8JRZ0;9`?!uM+$@%nN0=u3ls--~G
z>ZH0o%HdUf>&-8Vrwzo$vEL8Y2`Zf=U0dr_(Mt2nqnFdSTbhdx7h*%^kO2v)xA8o?
zQ8lK~9dvPo9WD`m^S@1D;Dk5gS#ceCJ)0hj2!HoP7`_d_Jx~iINqL)M@QPVkVupf(
ze4Z+G$s$=<RMAh3G%<9`R;tIo_#$AK0d=yY_ZDkv!+5GFgYf%%CuO&WHjBfvZ^!N9
zt6U7r|B-Z-QBgH)7p8OQ8hYsNF6kZ+5D=uhQ(7d3?(S}-B&EB%8wBYV2>}85&hvh=
z_``Df=djK_ckF%bEg_E`TYGVz^QQzGSv--f(}xS|s)aR=CC~6;05#_5*=|qFZgf}l
zR%gb*|CVXHCbz@&_sg%F2a~yx+^Eo0?fG3-5XGvIwvm{JN8nX|)~ah@_tZeNYJV}^
zjHwa1ceIk#<QGfq*>S9%r-&2=zoZ%j8HSJQR}&z!tbK^$JQP6$pOlu6-jK_NuR2t|
zuy`@}8>H5}*9{CK#SP+*Obn+Oq(KzvK&}WgM-31nku4?K;HOS=9yi<+Fql63J@ZWt
zpT%qEyL&)#GZtKB-?wSkUxwfBT%GX?@?yt_aNnSM8i()7HBzu>lR%@Uw$M16D3XcB
z!qW%%@i>&ca;-)!xB^o=h#^FB$}~)H^mQ;>ja*CT<d1dY-{y24B0)>6cN*xIGI<k0
zQP0cL$T^Xt4kdw0J03v<@Xzf}wDreUbFa6}D=k|u>b*ZX^1BZ`4L3NG0{_7sM^l^&
zlb;KRC=X4p5$Di}E|LJhUtYvw-`SLyL7N;oMR=@7=pcWyB({BL9B<N%y$;;R$UFn0
zcS^nHW~w{=j}DG^kcAHHWJK_r*?D=UZ=Qv1*oDst<J`?t38Z52Ftf3|;|GSmAP}0}
zL9ho5kAq1w?Hbx(jRyF%xFLX^^Oc+aM&gaG-Kv#9a4F2$_9I(tj=^BM)?P2Sg>tO}
zZLYw!piqtusd7UpSwz@0w>st=g-r;wG;X@i`iUUi1lTdgi(LX&jet5Jic_`k#eu^|
zUK0TK``4I01G6e;4G`Yp2gHDe$<WAaR#sJUg*_R6yVt4d3O6g&`U*s^p;Gx20_nK`
z`J60{HCoHiFt?%*kRELU5~9k=Ly0=)o|iuw%-V*A=N_Vf2q`=w0!R;~op1-*&e2gN
zdVGB#vlN2X4-{QM|8uQ?<lDj?F;MS!cM8<5L!B#CRn;3K42l1JDl36v2BcKMIk!CF
zcZ?mlAB;@yg_D;%Ykd1l8~4A@;|j2VcytQ_{<Cqn#>!nM6Uh#s-wz1<*Z9alm0$zF
zyFPi^*_{AKB;QBI?3^5~12C|Uh?0{b97;~cuUZ1+P&bIqt95<+YCwLEH!UJyQd+4o
z$k^VPpVz8d@&hjGhgB3nJ_2xu1C*?0oEbNMU5`8euIZ6lZ~wXr9kV@{M6jXv7Lc5t
zo!#inz5j_w{UG&ks2R|&+Wlmpb5l;{Y{uAk%VG}3{=n(LSZqyCz9!acqw9MSkrB7f
z0rv?-gnP0!AbhtI@m1#;N2k*Q`X?Fg5AQ$B_6Y{>Sq@<*27w7;^&aP`;`{AiS88fZ
z2?gR+rSk`k25<~%*q$B<dBPv}HxdrE<L<C9h+}G*dqK<kt{~UhN|DMY-wEGuOz-L=
zT-XouGVFiTHHoos{yd;dVOSoD$2H1x<l{liB`?~74L~S&=`~_J1xYFAT`@|sqjZnM
zkRRc&hiR~1aDxKSOayBjy!F&GM5l7CyKKI%esESnAab_QOw;^X{5^6?VpBLo;La9B
z-pe^}Oe(fjT>bzR#r*tuPdlij#4%IdCA5O8?o(nYh&!J?9Wn9%ZCpvvBdPApvph}h
zW3+G0*eH5KO75$h8A&kc4M~HHVTxRpKCM~yV|l2d`pG#3g1GKmnfzI(6GR~@<&yh|
z$yL?->k#kO)uCFR=OlJ9NtBbdZEWn)0nnI+59fU2^Zb0=JGb~S7`EMsEBv|0=1g@i
zKX^WCq2zN2aSoPrU583Fr{YV)k^pA<3a7DIz1Vp9jH6zgZpz1n73ak2<-bG@L45<C
zBI3_uZoMbI%6Zgr&988*U6e2-{IxF+dulI6lz5EiXPd^b7OdlyDJWQT+I(z(Z<;Ed
z=9v83{B$A{&kQ0{5VDK6zVR3qq%j?fF3KC~IZwJvmW|^G3BfXSRqhKARoV$I>fbQ~
zhrEIFqrpzWg?Gru`}Mv2GT-SWCOepap;MThKg0C}Br20zpk3=^`H9PWro0mJ^{feh
z+LXXe4;-1a)C%5pOmv~xJx6+qD6d5|r43mLo*8(=wMUU2ys%l5y$z&(OBByq+-1w_
zENP$afxFPlKQ^dTVf=<)XBMsAZ9dTj#SKPnFCC#UTgdTp%^?ZTyYH<Fhwko5bt}V4
z5e6E?^O*8iEBIPnU!PLTJrs^dQ)Mdb|Heos=2>8BWplC49LuzR<FhALMqs7gl;@Ar
z5C1f5+s==_T0{gs*tWJz46-|A(yTc~)h9veQ=_2vENeiwueo;KT^=gR#tB~(dxEu=
zri_rh;5@bpopRM&o^0mR%P==jO<~~A1k<!n*j-u_V0j09L`O)Q6yymP&NinF42?EL
z50wh%bv5U=K#<jlISoyM!H?qF&Z5@KRMjpqGGOsBpjUq>=^GhV?`=~4D=yhGJxJS7
zlaT^{nMc<X$m408zQUVi?I!S96E0^kukknz;rRhc)gkggSX4#Wf;rr6tLiIVO${MQ
z4_eQAb8bE3H+#*h@|wB8W)vuugz|Iz7jgT}Kj`H&Cly<I$bI)JfnH01pMSsQp>mOy
z`m4#`73Y?trO+UtST68)09CW21L#?S;|w5L;=)<xdNrj=rhoMBey?Vc5En-Y#N+|i
z9YBQRYlOZiNlUNnm%{L}jg>LsDe?*!koFx&0Izw0un}M|($u+gr@V7FpaDu0%lkH1
zkEx+D+&}!Co5#!Ur^|_qT!~MDue5|JVKOWXs=U^rjX$>#xzgGOu@>M_%nd<qj;Uk(
zRLYJ6LaJN=Tfgsljbk~&uRpdY@Y%Jj@^UJ-kT9sK>UO`VkJ<ljnX(6LJahIUuY<$u
zX{zpX4`bA?tR$-Z)dmMwL}49IOw(S_+z#;RaW{YY!s)dpTS{)<U(xi`S-4@3<&CSR
zIy0Q@)+Xy@DaofQTQ&=YSYVYHjI^itFh~CmG5q*DjKEL>+n8D2Nyd{HX$5f>F`@{o
za~5k%#^jqS?z}FKO<FaAeOCh3f(U^eK3M(B{p8Q#_iqSY9LkC^9dd%c_Vo6dK{NG-
zEwgL6KWiEv=li)AfGehEY?BG#`7wXkF{5bV{Sb`>8|G>Sk{Ii6j`E>5Q3N4<7fu(J
z=WfjK1EYuy7BLKfzq~=0(rjWefYV=Y?_df_&9-M({~*7&!>vOF+^Pd)T9=KxRci9e
zi4jSgoMIg<3l}&lkYW<ktham@bOP@+mipTUP~-nN`q}}t2iPtq<-<!8=2?}w^E;iE
zCr__-{m>WMBBeZk*VtCshFNvU+1d0fd1&2l??UTmlCRl<i{HItqi`-Fs<#bokt4mM
z_v50E=$sI{btyjCLg<IKIYlQHwYchNUduwG0B(=PH-FM+A+&$$17R^V?Pq#g>J!`}
zGPi_3-}2;J^D8P8Pr!u~iEdIM;YHKH8EGKPbL+ZVPVj-%k3R8Xj!GfasXkCxF8b56
zm+Isa|M)S?^d4POLS8GYowYJXPje!UPgqhJ5(d#YV<<2{)e>Kjc1cwcI${zL?{C5W
z=nT6dkR$B=ggqcPLHmKn1C&<Gcs`Yim5iQ*uDPsoAcIZsN?0<HDf)p}y5GED{WIbs
zg)X-#dTxaLEQ+R5zZ^}TM-UF}EG7a)gn1%{+U3wrC}_|W$?>siH9FY^nui3hBWUs#
zqPy(VO`yZ1u~RQ(@+l>KiU?4?aG6Yz7rHHp1_bW!)*qXG%T>WB_SqlV?ryzX`)cyp
zJA!BgRQo$M6$QB_^sk?;u=|hfO_*Q0$(w#igjydv9$7LHk{orjs0!1@-!+#Zv%<Ho
zKy$|ZLL7?w*{+zg-JutU<w^#V-V_TO6xW%hs2hZIoEU~Aw}WJhiz38K%u`IR@)a}3
z*2u^OWkFBwO?~nS1C$FMnv<G)baY6}PJ6@pn9;RJsP-uGKtWGbEK(UW`sJJoPFP6#
zZK~`*Y#BN|=?slNk2dYvd&+uL>Q2GD>5S?h;_Jj*&i*C$Km+AfwPfEdi1)l8g^QFh
z@)5|4?)rYVGgSy=Wdd=Uj?T{0_vHLSLOr@guYqzv&@C`O1FhD-`@cJYBpRqe@bQvm
z?{A5oe+{J}?Ql`-?ftH=&)mLv?|GLMZzDQj^UZEBbYMVyd*~}1W2@ZPO%H9;Bcf_`
z=%m?vb8Dbf1Qw6dpH2q62IfnA17)?co>AR59ab+SZ;(y12O>5k{$0Pk{@pquUoM9c
zeBSsYJfYH%WLs(jndftTtSjS>(qm`&#3nROAN@6FcwQ^pa<>dBG^>S_o5~308W50H
z6yn1A2tp#yH;Xs2#4Jo4Lw$KX3PEO{Mf%adt$7U3<N*U!m?FRuQOM=`tW$1z-z(rZ
z(RO^!Hvz}1dd2t!lK(Pcm;96@746j3YW#?ZZX--8wLGg9zDGe;G#(;vsw!lJcc?Q*
zV)cHT?TtAaXw}Xj;fg|#?ck#lz*2cAPiipFmDj|ROT`T$;!i9D@%pB@xb}grq{)`0
zo9YZh%$213ovr!#Xbbh23;bkaiZwpi<3#Ma<jH2G{9x`t73P-_WveBz|55fmkM<d}
zeUDkPs4;JL*SquM_XW3~LOJCwdKP5EJKc0IVt?YO#L}?C>2tPDJ))BLIqzq>Pc8>n
zZD(pZV9d)LfZ@p|c)-B_ab?MUZEj&C7yv^D-O8CBA9p*lBa|XaqgQQR)VMbN#n+Km
z9f8)qS59!VrYvACW075jm1NrSjw!cmH(*Ee$~m>(UrpH`M(Hu0P#ihN%Oz{V(+wqJ
z@d{6TwH@RIvF$K0M+nYSxdv%w&Jjz6s1B39V`&)RT`DO)o@A{kkNn4M#VH77O17f!
zbCsb|-L1dwW6*BZsYrWF+Z2g0&HnkI{r3Ap|J%1bxd1u7ScI4Lh|%W{ErH!8wnFk3
z*6s6BYl-r38!l^+D98uwIRr+OQNek2dU7wWEbb5K1Fx}(bYd!AgoW^xOz7a!UTobj
zDCD>O?8hir2w_oyOr<o41Q|raP&6rIA0$S3EfiyduH;gz;kr}dJbHt=jUsF$VT7^%
zum_AUq9JYyDc^ib4%Q7k<?BC1vmSM_g!FI6dD!+Jx;sSYg2_q6K6eIg$3ywgId5>N
zHZfsD5h?gta(pYbKP~EyuecS@^xveAYd2u9^vb=(z0yjd1@D`)60ny$2ZfN*Qn8|l
z5SnSwP!?|lZ>c%Q-Y9?R-IM1Gx0*#^GKEty(+nm;5yr5ygc8ydEb%|l)3Bj6*r8P8
zH*gBGf3GI%aETA#?LEiHR$Y495atf0cRz#jvi{0c<PM|PI<w+eHkwQ2yh_p>H+(QU
zC*SSm=2N*^{c?BRxBw^b9FIEITb)KYGKOWA4J(SA-hEHmrHY>z$o~A=Hnd<~{|ry_
zba3_P4>%)?JAHmri}%Np@?9?+y?!#Q*SqFefA5O?Ee04zUI{Wac}o^G{~mOi)Ly&J
zII73rP)CG0Z54m{fHnD;s`K-9r}LRk^iViU4a8Bl3nq}Dr>|<Z`dxfl?$`H=poW+u
zC+EB0<6v71pf}Jqb)O;W{^{bN_BJ%$|4A|284YIY+19^>IQIiyN-D7qUFnY9<!5`R
z^Na@&OFDkm+`;nk9SU>llL&WQ+2`{lWy*tkXX9}^oVkseAA|(@e&d)InQ_pQCw{3+
z7N!j_Xh0s$5-s_?b$u*6QSF#1Sqo7Q)86-nrf~ZNtrJb>%;^*ocL6Hm6$sj<1bN}~
z1V6P~RyP_8QA}?=50#j*%%LO{JN{})mi^11+0Sz%<vcemoj#rTlFUV66*4K@-%Ia4
ziP?A;(T}PpXVHs5j|ov)i;&C__;Pc{<}oy{f)Q!Mnubw`G*FZy`^P$;aU&C5{;8^u
z+TmUEUA}9dBaY#=Xn(JU={+@_Cah-afRn;fgz%JU=4i1W;XwhhmDlE0p+5@$_Pl4Q
z_<no(MZ&-vuu9n3S_=}USbW{Ji(9%$AN?9y)nwSDx8i?}7qj)dvBd~bhv;T}0tBb<
z|Lwd9+G%a}=Agn&M{`_8?a}6lFDI_J%oS}gVoHH@D!1~O<(sdvQLi6Hm=uJKr=h4r
zz2J%q!ZsG_BS-2_^KvS7P@bRV{;4S?xswSj!Eow~<2*Wb(xm$2vb>`^sAAwmwyPQe
za4_f=p%|jaFviWl)axuAbiy#nK43vt<2u5An0j+|Ln!tTv4o`M5%xHTu0jE3tU$;u
z7_^cXSY02;f-oVn*U%)(3!s$>zX^ACb&Tbs*%jOexhI>84W-G2Xty+6?+r#gPAzCJ
z(Nu6ZWf+yxF^%O9;%c%-Vyu;<%3z2;j#=s<P0_5=VCa4cwZ7^{I}b;4j2MSGIsr_)
zV0kHmS!7pP1b-yeq?$~-L3SRZLs_D8c}m5a;113lf%pOWY7vmJfIy<g>JP=X7+bH?
zyliCEm`ZzdS;U?vh158OYR;B}I3yh?A7%FFTRv~+Pqm{ac~PN%?|b++1Gq(3kBXay
zyT4TW{c}Bc6`2}Z)OW4kBlvHj<;5n%Y-yQn*DuZ4<Sq;Q?d-K!UmCGR<7W<X*tbj`
z>*t^eq-jek|LKu(GhoNeh%Ag5*M^P@!90Q>a0SZ}{sp~jRF0IHdsg|>#zp{TA=czK
z;~(2)omR_cv#0Aoeb^Mu7oOqg5^5<tRiZ8K{R&qE`h>bB5wz8R{UL~``S}^dgh;O)
zz6(aMQ1<IzbzJRC<?7Fz8WcI?DpR&R=EkD#T~K!B%c}cgW1Is=A?k4)7b+Hr`mZkQ
znynQEtRbR-_uhn;Hw!A5)2uW<8GTrF_U+&0?_a5+ZO)><wv`0wIE0>^&pFux2Xd#s
zqDT?Og58OYf(jP8GJeM`Ck3Um<%kRzyzjdGMV0Ng=Vxkq-&b!@QAskjai8XrAs~cx
z4&3dJTwiMu%ge<+Gx(|F)ucnYi%Z`jBx89abErpitZt77qG#M)|7kGjKkakrg9jgL
zq9}^!jGa??c{W(YrjUu?@$>;H)~Fvvt3#Yy(HwT{xJ}6{O$lX836SAsywEGsQV}3g
zO{rQ2gQtG^zkuC>!3PbG4->8B=%&Jb{9H@&&rk4gTCg>HZEXC|MdC<4J^XV+G55Lf
z7)kU5<#psMG$0siXcR{Zo_i&$6XrD#Ki`~uc4LL-=2y7CnG68o_VK{-`;n<erI6Xf
zx<pqLk6{AbZ~?-o2zrHJ+B$O9UU>M?4ks1bb~xJ1!kl+_T!iP*&=jab6&tGxOSCgI
z%tc3c13Iu_HTafb8m+zMOKW>k(b;BJ`fm3A>~Z6-7oR2<?#(qewB7TK%iM0iwwB_t
zZBd((PyZMf7xY^!56T)D(UP|e9P33E9TidzqGD`D-nLA99o(6F`5?%*88CWzYpbs>
zv}6~@R)ei5NMzjilyQ9tp=5eYlUY~Xiu31DEY8i+-PAAUje^Inv=rEf$Cf`vr6AN<
zSRdibs0Ej3FlNbGv)uL~O@<4fBb%ZQ_69j6L&!7BqejBvl#!JOe-T?}Y^b9)mG;Nt
z(<d1i_`L3lGa&9f(-S#EL-?fs;MALm{-&UfL?~DTp1A}0+WNpHd^P@pe=Osgkno+p
zA`cUw`7Iw*TLTSupyv;}nx~s8ke*nKRFH1QA(|_?$zqI;LzK0PFsxzr47;?o8kj5n
zZ;Oz#O%Z6h(Z0*9F(KL*>(5EiXSRINl}07V37$|Hme++n0)YO0EpzPSATYDWP%3Ep
z%@_7tl|i_xV1jRQ>W~+VOGT~2FiuY5YR^1|GIFZNmh!4^Cr}9+&#rDWT`F0{`wq5e
zBEF+_3HhMf(e}y@=kbQLj7)pwW+1BdoH%)?tR#?Gu$oK7kUy`;%Q-Gr{+|0r_t7K)
zTb!z_BFmu|WH>`7ugy~Wk=`Q}Jiw|SXUO#_FBRlwn@HDnPP&^YGv2GMEW%?H#-)$s
z<yt6&*M+89RMi_dF4e<K7$eiq?KuF#keOvQCkoRiI?!Ko{lNUu3@-)8Bro?}Upkc`
zvE_em=z`^&fj#lMAdT#c&)T16LBQ^BcBsfKsA3vX?qgFzNN?>#ry(e=G)$YPIKeQJ
zHYHlcpJVfxJlW#>g%|S;Y-udz9-rFW6er0TDw}ZUQ2)MV|IO{JY=-5|ws`mR0axHv
z2=#N%r$fU&BE!B{vj0{C$!@2MUoS5&%@f#|hH(<8y!4p8t_+!;P{L3KUf7mj!@J3|
z1T&IV(R-Osn2sgXe29lk3Ms!BHAVK_UP%5^csXVHP*Yo}!kUM!NI+-t^>-9tyK)Nf
zRhE}!6+DU35xz>In`X|`H56cPEg0e2t_R_v#}H-20~%=p4{h#uveWp~MMjES6GA%s
z&yL?o3c}gV^kaEKJn}sZFjyVKAemR%`6P7cXs{_8l4^Xu2|c}`C^y19z4)h%hke#v
z-uEjhn)(`J8Wd9y8jG~!sH+DS?AW^Q-~=aly^Y=kb&XTTR5Rvq+p=-Bj|49~yk^mr
zzn6=0%XU8utMAo9=3}P9EUor&OCoT4MTx?HB1-N{!309&3emDnk%py^aV+~#H_Wcm
za&KACO0VCgKl&QFu8w`+R-p+2XJ|0v9udi-hsjjh=SouRYfelDbb4uFl+&b67&FCl
zno|xM5|8ATz2|z!Nbs)h{%D&`_qQz&XqJK+PWbYM%4*0jD~(#ADIbYyJ_fflu&FI*
zH`?Va<i&@kLRC`P*KB=ub}o;legW(wK%*{^wzOxXu2+|#taf>_<ne{3tHZvqInvWj
z;qxK_Q4{<A#a^x&0YXvE1xA+9vjK9AmpFk3J$iPgt}8UDD4A^Jhy<Dx#6M~(gMwlP
zW;8|O*E}Xc=0_|DDW!1J%T04;sj?$Zswz)PUHdV@Pklcrc$t&)*!ywN%GrLH({0<(
zaGB+RLH_6%ZOg3O_wkr`eMH}2CO)7VKRVtnc~*pEcovT%l~B`Ig`yfbbW2TX^>6t&
zGYLuw#%9aFd4eV6HIYwfN(nu8P;q>Aa9bm6VL<YfxD+GZ0`eYiFgk7#^)Li6tx#4e
zNW6;W8=|cY4}C9A+)gOEl2p87ZZ(N@2)q++h#+onsKRU?0%IwLcq7Cx=)<aJ;tT1}
zD8}%jb$P%)lp>Jg2%Oy5Zq3&m&l{s5Pb{gkxR%#TvH8`Ly`uaW)$Ny}?68SNsHor~
zH8nY>Q!bB(rOC{t)1xN}&c*Ua3^axx!}!esG%h(4PA?Q-)1H_HL1(dn6z6fq<47J*
z?Cg(;OJR$kpiBn->9%*zT1fCk;cIEF3zinP*qe=-jh0V+=sFrG1G5b1Ay>ta*sO9x
zjrY)H!UNV#d*%UC(6_iXB0af}GoP5eZyQU=2Bd^oysoMm9WTs2(_v$}Wle2)gzMj=
ze3i9MsZ(~mJkU-o0tanHY{?3S*-EEgEox{390qKBYQ}d{*)zNstkeIJF?;%Unedqe
zdv~0lojPyPU{dChjgk;bh(t8DAW8iD`-E_rB0z$<eeavJlG*_S`hr)*|1>qK!@#}w
z?_a+Ib|Z@ci)E!SRXtq`=U;f%Z5KkNWSiv&Dacz6=zYD=VlTYy!C4x!enKdS9ro}i
zPEz7&q9Ue}4NGmsT|{<)PU0nR#!2jPHIVx0@~vw2DLlONps0oW3%J60r+`ck{ro4n
zk>j^Qok4`mOyJu-Cir`T3khFM*cn3Znc4f$fAHAI!X}Ugz3j}55fL0wQ(P`&4i{IX
z0avgk7(teh8(KI?J4`SAm9^hV=TLW6Ykb%KGBb?cm1gi${!dv|O{{-*B-F;!)z>U|
zDU_cLSL8mjY)gh)C+e*Ih_Hr4cdjOwai8=a4OH#rO0W5A?FmC0%#hIEBh!(>-om6x
z3E0r~G838dH!ukPh<pj%=tBtEftlgbpxPaW+~9^Hb)NJ3+SzZjKcB$~Y4@W%FxZxI
z6arJ~P!6F$(jp;sM@7dIU{qx_O<DZ|hx2RakyFq+MS0Co?|M$MFw*)}DRBSetM#$p
z&Z4itSA9qItxCh!(Vk{UAJqWn1#XZL0h08@!J^^!qcV;fp&#9QCT|ERkB9bq?_VWI
z!EsnP+2Qb|Flq8yQR3~2*N3O0+Rup>Pmc)zU7_e&IKg3Gn^zNsFO)U2EstxZzBDIq
z>ztqGditwz^p<d=B^hRtz6H&393gfbIU^0~6Vjgp5h9prOSExC7(P=8I+bB^hVs}C
zzMRm>b(Hj#>tnO_{^uoH;AFFcb6sThTtLv2`m^qeS}~H?k6CQMgRs0A8Gga?39fvs
znzx<SQpf*pRCzw7bzC#oQ0ZL<tR3aAHv;Iqf0lGp`GJ-Sr?h^6_e<2ZOzH=p4SEbm
z*pe$8uW1Mknk-lgBGul@-vfaIVT2_b(K4CYLSV@J<@^m=SMU#j>ps=l<xMD7pXO*U
zZ!6lTLiF#lbWOd=Xfi}#+;MWn-biL+04~l2PF5)c4RBi^d~<w>wG`p+-*o?JiR<Ed
zVIt8nWAO6nN&#fF;J$W49=O$P@zLLs+vjI$)#NXiJR#Q|hTeEZ#ow9^eVQqHb*bJf
z^@CDu{U$Tl^nILOgW$FCqhR&#0u39&e`Dd`g5Z?pq_tUPOp1F?-F9zxIYw;o>qCO{
z$HG*=;UIct5Dc3|2_1@o09mK^ZXQ8K#I9n?o!iviqAkw3w$Ysk?24q$+bJT^(;7%{
z-ZQ~TTx#_r<MOC4i_lBQ;h-xiK6U(MB`p0U{1gF)gtuVof@@^uC8CAycR(oX_85`n
ziG%tY7rYfo98K<X=29o>bNNyV1Cv>dkgh9!!Bk|4!t2j-d?IX@nbCDbX?AKQ^uN%S
zCGL;R%C%Gj9I{{9{`ca4{!f`~MQ4b6Up{)6dBo+yp8q_pS)P?1XsP+z3Z>mC_07yq
zv!kf;s9E#MQ>84i0C}e2<(EeE;vOL1;4YR@via%e^+(Scr2K@Pjm611`VUB<Ljehi
zY3O6?XNdxLEm}g`V=0apm&1aaZ;f)_uirMd*2m<rX3+<m#V5FtMRM!u6?peTKJeKD
zgo%(S6k&!Jf>Cx5_OY<5cQOX0%5v)Ix!u(0rpm-yL)-qb807_n6-P4l$A9A4M_&cz
ziCNR40cO(Ix@;G!!)GLsI6!nEA|j5lQ`g{1ruf(Hi+mOR>R6{YcR;e9WPJ*fdT<mv
zF`I7Eu^W_9NSIAyZ<G1$+`DThi;^n@%RYn15ijCSi4lk{+9~t%Mb~q6TjAH<+0kH3
z-G1@W5!kN?qdKbm2n8ivOqS%R(%&i$`KqfDR}BV>47LpvmzN11M^jF|zZO0jGFZL+
zd{r}V^?bg1B_+yl#&v!9c$m>_SZ=eDp2hWJuF)Z;=q$X_I{uO?e_8L)MICwAa}l4c
zyuLJz9C?tI6?u?RSBxbf8^^o8E4uB-_szIQP-9S(Tln^2m^zmer?evv*tOm?(E~qQ
zDx|hwl<V8Y$GWEQVRLaoU)@Jb+L0&Xo955{CuHU##rn0`!?_sO1nqn(dfHQ2z%_Yw
zZ6>f_h+Bl`jlk|i2(hvL`RZrOfmSx<_>YXjcj~1$iadfiUwao>&etEVd1?#>A4FCa
z^TryKQJ|bbh}xqt&`}|QsC0z%sPth2n>4X&bm$F}CiCEZ+D?e3o|-@Ld6;b2<C(k$
zie#7?WS~|?)&IvqF#${iF^?OLb>B!>)YQQ&#fVt-D@3VM6g_!L_x!%2%lKCm0TaD)
z`|n|L;11UR)0H!)OB@l+W^ImP80H)!>(YHmTy^8^7GNAx|4uPwuf&}d@A87b?}Uw$
zwFaBIQ$wyS^g{ak3+!pTf8}|SxIAF&w!xb#VVLv|n0naGXRK%iEggyy59u6eHsCPL
z#Nb$jky#^Gk#2X&oKY&$w3r0P^t98S@46nXPOv2R%89e1Mc$~S<y@jwAZU~DRK*%0
z$~ATd()E@*^RhCEZ+~86FcelQMs6wC2Mc|UiMN@pHoQYCpPu^#iJa`D<WO~w-3RNE
zG_$Qfx4?CA(K3M@Y@P=vO0pnXu}*ThzgMm<c_@z7EE{lPxDm9VsoA}6uLC{*y_jqd
zl>fb%2Nnt^vF<i)%$JYPq8DeV`llorDCFlEc)#D`uMf`NfQ(&jss+F8drdv;bU3#j
zWRIlxlzkcJirnqZ4>>CE3%DJPa$QNaNlBXbH2O$d7L)4De)J6q3G<Jp`k#95H!cDi
zeydne3p*h(Ub%3Q+QhcebZ0MHX4Ah}G{s|~D?x~jl$#njr`k<6?WS;lX{bAfrQP&!
zk#53CpLaOyy)Abgo*w&Z{4Mz`Se)&O`qfNgk2>@|$f}Y8hD7t+&`H&oeGlzCHDtVb
z$`?yQ{*ZNGl)T|3`lyVoksO<D`iGA{Ty;c4_zxn8sQ19SNX|3YDJXh%reo(dvy%ur
zY&6rOR~#JCwZo+mg%v4_(T#|asX<!=UZt<2A>V<M1X+CVMfO2kH>0BO!$jo9pbg#O
zFEzvKMB?p4V|+%5?u}MMO*)^j5AquGT54)bb|s75LJZ|KRD48gbH)$IJy_ji5Ug+3
zjJKBQqV!}-*Q4;7GjH3QD=>^cqW!$JC1wJa3=}1gxxH8mw>zy|@3KfK9}ViUi<ji(
z%ZU^?TbbUAha*7|5stG;oBT0;6!T?$m;`GPvlDkGHwv%RBAF9$E4U)_nlMB+dLUFh
zk(0Rvg$9jmf5SJ$RO%ZfbxoeH;@ycfA)3wA>ZqN+JrT9>uq#X{ov0Z!?CT?@AIBj9
zOnn6R4PRrtC1t~Ms>j>V8_0sp4pkN4+R=Ad3+#{Jh`Xq(QY1{uTjAddAa*DrS2T39
zWRALV*9UJ6A~G;4w^9b6L@lJ+89K~kRzMMO!zGX(i+D2OC_!kenl~h&1n&@uSjQHN
z%H85qe)oTd5MKAAWWo{cY9KB^kQsB4@mPz<Z)F0|->tWPkiNI+ppT+Tkfag<B-TjM
zdL3RDfMJq}kr6Pb1L&h2vF*orn}W}WHwCZH08HW!U<}8T#=Q=Z0%&u4dwYPFNM}AF
ziCs*gtT=r=hx+-pI_J_q4YYVL%3u!6GyFCA4V-H)cU-vvr@t+^6SH%B`SWVElpFAb
z#@}IC9ePgqe1r26hoD7{JVYTIgzIs2ga9Ny&@CwGy<PI@Epf>aj+$}aNAU2D@F+xz
zLAc9n%WA2l4IlB~;$|tA^ZYa;W9dq0!j@xilzGPUw>fZh4i=QOK@<;&{wbW0Cx<`w
zWt2=(Vv1{q_AC<NhE3Ch!YWmiMPF$MgK=6@TUD6=^<P~1nG&)xs#5%1N61`>HplMj
zJsd(s)a`s1DM2cIP<GjwZ_v6g7(*&bxlEY|D)av5AJ;171odCSVj!gBVERE!1T++2
z2M_!N!u<!88xsx;sQ$*qzh!V<r>9f$XHNFTpq+)6eWrdj_?9czad<=3oIuuSkf_D;
z^3#v?I%li<!wgoEnY(2jp{+VWQ_u6~c_Gd>_vV~r?;Ay`4n1}ocN;97L`3xaCUp)`
z9b2E)wrBoPM7{YVPYT72oPDqI4!MMdaag1(S%8P%5^D_$!SYx?K_u822JfXLgYZY1
z%$PZ{na$MOKwv159rmwfB8}X-kWAZmvdKJMM1*I0h?}F#$MJbbcnBNVODrY~^#68q
zCu^5h7@}<`#E8jz6Xp|{EP`g|uF2RaJmLC?=4oo1DY|#mC%2;f*7S6fy+ju7ly4C&
zR*EM!N7!Sy59^|k{9Scwu*|I}I&m<5Qe8YtVcXnhBC=T0Ql=eLXi=IZwjZMv?dB&1
z1&mWE7>Opa7a0$XNF53RQD)?s5#gH__N>zZ8?oP(if=wt*6TZooRm_j7pL#l(fmm!
zbdUdA9DOEvgVW=C91u8xuh{^HZNkGn=eB&vf^p|%yxH#d?ATFsmYqu=uj=bt#bqd9
zOSPQHM^}{fSJvXt4j{RclyOZ*#%I%b1RwbhaUS|FR_;fmbwHphbOzy6Orn%1eWA>Q
z(jkTc3f=u`QL=AGA1JP;ruy#LcMKxxBhl&tGmC^puoB|%nJPk_|5A{1;ZI*XG9jE(
zK{9uZW)ig`59%TxI!&4G$<#br3LG;Vbj@FUDiaBsUP;i7dFKLl2jI%FcWNQzL$#VH
z4Ll6r7f`cgUWb4B=T~Z>RG7gf7Y4(JhtkuYtae%&n9+#8ZJ@9~cMRzq^pRY&sFf9%
z)#64|G?O?FVFiboDM=H3;YJy@`tIgCU>qIInyao!s0PV`mM>tKwio~;nEo)#*OP+o
zhsPPo>*jBtIb4Y7CmL$c0P;@Sf1iKD!^4M%)@tv#3|s5`AFtnjK7AK%=HcN1kiiW(
zg@(ded+n_Hp3ALX+tzfnoIieIPCVpN<P~1-c`fVi+E7%du<JgwHr?5&9bB!;jm-&n
zCiBC>bku*F?3ST_INK@zfb;tWMfa|8TXu-gpI=!+>S~u{j{cUyUZPrI4W(#8kWe9p
zh(FpKB3#oxQyZdnxl4KDbLw9><--1jS3S0|MhI^@Qvz>+)vN_~yzXmEg|_kONN8#Q
zB|IZvY6jk9vTl7F?$$BOEmA{}9;^lSDNxOn>lB@l%iJ>S#kqlJvQdv>5S8cJ3ya$q
zUTVgSIhMi_iZE+QkIaLK>>%2rtQo)2>zi&vsDM$HCr&1XgpMsu{1<cK8N*b*zW6{{
z-mZ2B1NaFD{NG}YX5xc<R%7{QiS<X>-{(bmg!1;qg9!v^$)B_T!DVqb#C9J$c^kjn
z<H-A=@}?B!lX%}>u8Mg*^Y_xY&$X6roD<gUBTiM5B%(})4E&uN>TJw2(dN0Q<??En
zlA1~y#a~DgAWX}JLgiF=SYQ&{NSJD_2wKb~+yPm$`N;UixXr3&2@;s0yq#rX@yZM}
z+0F6_>Lv3Q03+Wlc|jVQLh?z3cic2rBRhshAw^Gq+{lzJmELYZCl0S-bTFw%Qei;U
zJ%UGomw?$Wm9RXVeNUJ9D?MLySE{dBI0R{kOqn?tDU`+udY5Z06#?!<Q$`C;3`~#t
zBG`Z*gk6a>^sWx8CbZc!81k3@7?CMeMkKah8O$;XDhQ$QfT6h?kJRHT4cF*KM>Epl
zkuq~}ksz4?XeH|B9n^wPmu)11F3U|UH|%ON$Lmtf+ug;iErFRvFO$kT0^nUuMyp$9
zUPy@n$OyM|H@qA;_I&$0yRA<-O_%VZ$Vh=OtWK$_$hZU*<#}UXN+c#Pm`l8%S)liQ
z^SSEHABx5|oOZeyn!CjwnHB>SF+7faYa;<{>S<604r#x0!l+XICjKJ)SaT&=GKrXc
zBqE9TXj|o8TMk0!#Pb+JLXE}gQxb+7mgyZ$MZz0TdPWIqrERIM>9OO1R0l1TgYHOL
zKIacz^j5gDonX5LU3y6^xB<D!k?fAauur6I;PBvV>6D}pX8p-g?VGUo<@)7aQk4lq
zJa=DNtT1C?*reRjC|L7hQLCDxQOCr$tR6)8wj9SxnTnd7br_pF17AYmm5AEK=)n;s
znWU4y5zK7iXcJitL85wnuA&T8OGy(4{%;D*z)4D_ot+2|)85@1t9k_q!$5}(FbNv~
zx?y^H`hVVo|GZ@H-by5?S5W&M7Xj{yfL(%u)edi$w{PFFrs2y2MzFYgy-D+W@ta9L
zz^?${1ponVxgBeCvU-Kug1=5=!9r-zE_43!AUTBR&3cRXr=#yjDA?!83u7N={(0-%
zJZsz!F`SAqo_37TRm5ohqpg&a9mgvu<r_DpezHo=>&&D<DVLH_XbdVSMbwm59zZ(J
zwhs;@^{baPF`SZ$jcPLfWuYt(fMXZtJyjv3()E@P+CGq3&Ws)&<?DqYEj1T;aGX#?
zO0T_{1~r(vf(IofM(Kxc3_aiTopEwHT5k93xa=)co063xDjj4p*1ALUf&s;25>+^k
z`KhJM?M3hGoDS<@@~J|`9N{VEyh@pdiLEI$TO_GVaQkLzkKz|sBO@(@It)T(IY&JY
z-h0#apKvExnZ%hv%F6C~>{fxNiptzz|C6!|z~1)W&~S5k`8$A@1f0(R%?3d6%F`yj
zuki<@I(fow#cgeEWn~OK^!QP?cXw@uwSWouOC`Yf`llVpVB+?8eE{6=FVD|6n;ljT
zCP+9wGyxQ{C-ReF<Nqz}k^k!)e&Ryy#HpY|sM-=qnwb}_0SqnYaKR<eOUtH+RxM_l
zoOT|sXO9(3F@=PDjNEQhdp|}(_{*I+M1OC*`=_h}oAeBO)8ty_fv)ot)0mif!ajZi
zug+eTWV7R7iZ%KY-BN$bjZnN}7!O)720<d?l9hZ=Q{^W|g7+)rfn7?MpvKbdz|Aox
z-Rm2^;UY5xmIbFhkDyZM+tea(@~B*P6n{`P-ZTPOK9t|yrOzz+M|5NCATungGHC%U
z9Fp5_kU-?FPoJfQ>sd{py>Y@bT0RB@#bDY;lR)5oMX>PPA0rLrJ#i5#6l$@b=u;DO
z;xxUK!>KJ0_TX%H5Xc{j5c?B@Xf$?^N@-C1f<f5t$}2^_tvED`E}VF9X1EDc0FU}*
zN@&|3s3jf0y2Z%i0-pD%TRzmlAmYF+1VFn1?24q^V#b_Nxbm-T(X^GPBk!+b8do{k
z`6o>HNAmQd>sbz{yye^MvXh5S3MAg*%6&@uR@!X`c>ei%UgUYXQTBJ|b{+FFRNzZ8
z+mSn+VpF6W2Q(Hb>Z!brZbR)(k5<7p9<Ug)hG6SH8UjygESY#ybcJX~76n4y(WvJ(
z6zN{`49kou&a<ponXf6f*x&Mcdb0b#jG$p*%0jkDC0MnJDvP2bscM5at}>j`INSh6
zmeyu~Bc4Yhn<=hz@AmMhG+|US*}QTCO|dLts0JR#s`$P+oM0FQxT|`MH_39=6h&_b
ztcN)iNeGwCyTpo%z-N+<@2aPyKj+CkcUpw1GBy@!ZEnr;!3>v?rzA57hMgO(i6#Z&
zO+-Luho~kyHzFfR>n!D(4FUwc?ni*+2|UGbm6fdj^KEtmtS7)`dNWAS^P}lx4Uoha
z%mDN$tCkHM3gJYRvLJwOj|#}_0keNuSsCEa0+4gI;#4?cG611o%yp;t-^&vaB*0F5
zc6kX<`)-eqfqzAfj>#)#R-m;T;MNu(2N^3dKK9|@%D?%;6J&@j?~9E7#bdZyAi@8v
zxh4COlFNtHp~>*O_sn<Gkt{%x{V^&N^;PXBSKfjk=gN<FW1ETVE@b6c-pNwQrunOM
z=23IMf<Q%DXhAsqv!-bJtgbokx^|lmBixb3x|3}miLo&U+$^y)A*nwt;igQ5)gb~5
zmy72%^!CG+jkQQc;JLwMS&pH#*z6(FqB~vjC3b(V4#@;dI>AT^rrF?{P*)}?PW5~1
z;dNzHI4yV(B4jZhc^@gBUMqkW5=z;C@YSudF_JY%TX=)DRGP!Jl@N@YGswITf)bRW
zS;6}h5`_20>%shq+T7UbGUv7L7H1)7A&CN@EpDyAcBaVMGhpuW18_2c&+P2%Oh@PQ
zZWI$>CI0iLrH2wsPL7F$0Awlv4;t_zcz0~UAfpY>=Z!Pn2OKVKsc=wr^~<%!kze;m
z1VOJ439ou>?p6Q*oLPN~`zAmKaC`xz#K3Nk6RnDm<Ee)LKIiGSLbA*KKqces-a+91
z_l9_Y<EzKj@}0G=((nRLOypE5ndde>Yq!!90EUxN)nPZly&xx)o4eq`yubbRy6(Lz
zOSk4aNxL?OD_8HKus8Yd?5X)>LI0in23$n@Dt7EFRk@HVy&`X4BqBv2T@HAypIyXM
z{=2MKbOkKys6lTi)%uu<yyjrgsy1Ii4eu%9me%0UU((c$a<Y#V8LpyIHjz;vWzvYr
zTKGRWMKPtwTHol>qiU1qk0pX3g*M!~!W_)XmaZ_XToolI*JC9NzrG07_h4P6kld0g
zjpWgY10z9gbmS{33E?6{-W^!8t(cj}2a@pUS{P0-H^Q4p>Gs+0V%P>|ol*|tO370{
zN3*OIbaWyH%(82N3HaA`PvFbnI}%RAOdyb9$sS-@g_{lT0mcsN>0EsyBg!}h05E(9
z@QCSirpgyi01uzj#`io?PkVRw`NO8M_0(T)8EdfP=wpzds-q{DsTlbjc@((tSGaXR
zRSP_yx9-$kd{@4cuzN+6kCrgSQ@pO>h_*;%fXT<?7+=<_!!`{@@Y5zC5mxwSehR`_
zrsDllu|M(FJ!ScL5OUKKDZc0@1BTJCudBmQg2v$JTxO`%IA_(SUaT5^#O{aY5kt+2
zuGNWicSGIyScn4!g*9)S8GZ(7WYIAkPuLeJMQjL=<C~ZQCJU;-FhTtApF@D260w(l
zIiV;emhP^QVOA$M=_@OiDcLb{NU8r;Up@pbB{A$b>{$z;!IYSnSJBviQDHeoN4lwG
zjoXqLMhgx*Neo6xg&06|aMxEbytIJVJx?7TUoZzr<Xel6xeS2#`0XS9`SWM>3hzJX
zzMh@}o}LQ;c*EoezyfXA4tP?0bDabXA^-gi${}dMy>&~hsTmn;(Y!o7Nh)Ok)krXB
z%DS-^crk*;$5nvnwKxTfdOb}|JlhU0Cu}4I394PU=$OYrCYY7g2KA@d-)`d*Z9h@Y
z8m#&+x5h0Jl*`J#i+rs6fR2KP#E&H}y~343j@+xSwd}Jb@a^UI-NiQP>FKNhgXkhx
zsoMLdRW-YGrS;rYbFD;RDa1%;l%1|du$*Wmg8*J7oPT6-f!8t(vcy9kSj=0t{fJ(3
zKu@$jG7DN~9kr*R{Ont06EZ3qOjy~c1Z!3J0CC_Z9MTPC-@C&5D$gNwBK3WzW^gfy
zsm{kW)%;z3Thcp_#L(o%SSXLSyJi!+>?id6eA+W6MUh8~SUhVPI4unX#z_>?;a(Kc
z<3wa4!W73)?qdz4Y^8abX$b0XM&_`TLepq^Ro5C?rXot%tadOOW@`}{5{Rvh(AJjc
zIGh{WudKA;SU&J`wyE0e`A5Eq3x2uXuz9^p;L`>s31{bFwgbS;x6}tn)0<tN?w4x}
zegUomEOJ30Q6xAxxZvg71~7bP3c2Ld0}ryy!onhIaAGMNm<~lm?CSM^P&_|BKPrIN
z3h?zrD13<t08gqE5QtZ%#im=`nkoVUfdD*<BjBO{Y7MXwl@$G7$5XfC8Y!dOKO06?
zwN<qGnv>7B>=T%DSe4K7^0%3!U@Myfi}?h~%FPm?MVl;pC6HCcmeri$f?1BVAL(6R
z5<?k65zl8nz-hYf%7C_B|I~|tt}&M7ibt=EtHvHa#TcEOxZuIZ7}Z)`YT1eX@=G^s
z;|a~icSIa0E2OP8{10`Jq4SOx<y^y2ZhmyR1*Y8U_2f$shIegLRXN>iJ}-nTc;YXo
zE>#D0Fn16o5}Pw=f_iE1EORiuWpS%CD*3)C1t^oy6%7DQlaCHwn4+fL`hN*>bM5EP
zgk!SoMJM_~CO21&8_ENYAcVpUa1%?-)nd?Lr+3-LF7$cJx$5^9E!#i-i%G}=Dt8$>
zlc=cZ@;8$nfLD|7`P>2(o8n7NjRcTUAWkI&qDxZ&ym6}+e{A{vE;rjOd3^zn8Gv#H
zAdMATEDQWV@Lv|6jf$!&2l0S5C{<h^O@B@{<s=$oBMb6blb2PR5pK+y4=YxWR)m<}
zibjxsw%OvHqa|c>#rGj%+a2fc<{z!K*rkTTU?N8Apc?{@(oBjSR~Qd`Up&)9V!RzJ
zw3L9bzHK&C=B1y#RG9UPu^0=3NKbN+a1wi(bGB;K5s2F(MM|aS9)B!3bxzGPPtAy{
zK(T`)BMl1Hp+7CFhRxA|$qW?~-Y1uiXlM;aRD|-3RbgPkJ@7{>j0Tf9hP@y{5u0aO
z^WLht6aPi#rEMR!eIy)WI-+@x*rkDq9;=F8jky5(T09oUxzLGhAUT?df_W?5Z{0{9
z&Zztc@M~-9EWH5epgfVrpG6UGDl6CdW}e%dn+3q2%k7??&dyGt(ZL7w>gkoNCT{fv
z?$O1^?f<R@aDZ4K0EBVc?hIB443xZjb@<i2x8FK0_v@9_<1#-#w~>)~!d*}}m`9M&
zS3kWj{J^NSw1fQ@@@3b=ol*K0CVPjWF|=t4LA61x4&8m2_q*j<vJ-=W89!Yd<I!|m
z`|gwCRP1nrBdjm^;^yUwrzHO}ThvHr>qz7-_vqmz;M<CrkkFBEx!J?sZvxq#quhbC
z_t%32Hxbwz(<m+MRoW^j2x03VM8!xc1{<z?GBY6nCz>S<OeIJdmPN`wF@B)(J9BZa
z`rk7u6(nVzVhWKlc}STcxPV2(o!xL-4>}m$vi0i?eo;|&Eq@Bx+SYR+?9eS=V|I#H
zkT8;K<{)iO$3rbCwhl*r{@dwqCkbOi9V=`mbRXLqDVQAIR)1aQ1eZeirE>9+NM^|$
zt#}D{tY+|{x@S;B9DRvT=2~14k3<Z;MNX;5_&Z_21B!h7Hc$}zyIgut3O+2~Si*Gl
z+4NG*F=0aKWi%*W5Ja0(ZOjYO=CO)}-s{e+;-fvzn>w~AjZp>j0Ar1E5P4&;I}O2y
zn1jgD-AAuoZCR4x9F>!GJdr386#w`fO8%Ye>AsmZF>)Vc0ICrXjN(R7q5YR{8e!S<
zGeEls=zae|MgjwSHbQ<KACFq{0<;zY=R{)cLxUS7M<@>@kca~A^{u04b%0usBjkb|
z@z%Hx0tWrLyUPQ%6qk}>Vq!5vyY2xc5VSxUS~#Dzb)Yf={cKoE|2GxPp*9`u&X{S$
z{mZoSVOrh#4#D;1Ofu4ydD8p9fa0pwO-0*&--f;qjY%yoEj`(J`M&*sFF|idgg?+T
zBw@-TafLP(nx7DUE)2n@DzFFZ{<&}nx$*rolO%sL9={!7Qq~gw7t%vj+QYc5FK>eN
zPM;#eF)J@cTmp6Heb#u1@;(%0_t>}p4$St~KR(W)h}^PKTN~FIBH8l*U<9R*0LC;j
zGUA$E=fx#^TADHp2SWo^7h9H?R)o@w5)VTcNDShZOV7Uu`kq?GcM$(e8lEZyAGmWz
zNl9rgu>gn#x4o+MjSV0<KvINs!g`^B{r>*G2k`#au{!{O?s2wn04r>Ju0(NT{dD5M
zmNp59>Pok=YSiEO4p3t=RLTyINXVQ034oL=fDfjo9#1KHD^~=Ei=CnrD<CkpB|({>
zJQhm*&S<(U!_}k8e?}AGyW&8T8{E*@iQgU3kevVdoKvNw26VU?$|&LkLT%I&-F_Ub
z-JQbLg(X$AZIz~4iH`YXonJri9;g?Fg0zyFV)x!#y-Vgv_oFeka?{zuphi8iOGsu<
zVlUE<Ehql;tYj+)AEx=)E!0!L6>p<=p5!&tE=he49pP9t&*&}OL}@@UV_c>RyiBiF
z`Les44x(cs#Cu*`**i&)vePsXoff$_FUGi0k0%)-mm#>%9xmWaNwpA;pV@H!PKOA;
zTpt6)=H}5~m?EA2Z1bZKz{Y8BKb)IOs;~cP%fCLWQNrwJWhJkwnpb<)X2_YRJ~KU?
zK5+nS6M%Z8L=U9Dy6?L}cBrWffbZhJK<t_T56{jW@0$QL<}?i*T0H;mFJ`03rM_ME
zvWVFV0VhT$=YvNElTbIJn4z^ba~+~|`FbVA#_Xwv1Dn%1_~yh6xWHO7=SursP6;(X
z%AZ0GF1iWx`8TNzm5A*DF0q!;+QVbuiVu0tYpZ(++TOLSN9vOe+_St;n@n9Pb0n2Z
zwLZww`mVXNo-wliwQV_~kB(m@Sh)j>ne4lhm@Ok8gNi(3GNC|aJGxQdV&2Td#+;Y^
zUuFh)3e=idU6e#C|A1$+CJ|Te5IxcFQAq>!b00HBCXwOf83~I}zyS)md*VPx_i5F}
z(t~t^eh)qd-ut#Blq+Z#8!6PSQ<Xryl16n-A}O7z6UvdN8dO>tU5V{0ju|F1{r#en
zb;iN?qdEXa2I81RgoTgqpUBA#w*P#;r;-r$xZ3$qS!w$AZN~O57khgZdi?OBv<WMt
z6_baIp^tN(p8+@%FiyERI~!lFp&|qWL6eBUcde+$C>EUh36Oth5->J6IJm!W`R?7q
zwTt(~x(;W?*8V?R{&s+I93PJjNm6nI*mFKUtDn~w7Z(9I{j$vnIt<e3`oBU^Z!rQ8
z-`ChPp!5-<-%eK$P_lTg2{O~X_{Bt0sB-4DNSBV9ojQh(FAsNVznW3yTeiSPhG$iW
z;Y^l#ktAC&J-;5er#3KHD)V;QEAXNFq508IC4weII_iB)gDVaT9Tl`IWo;QXsRM{m
z*>k?V>28g=r?g=YS(t26bI*+CzDP@z-RH1p&5{h-Ma+6EGZ@>$LGUROR9r%PhsE^a
zO#gI+RP|2N5%A{|LR&COBJ>EMi|l1^;c~|PzopSW@UV@}$Y4+;X5a@kmFc(1%m4Q4
zGS>HEpP2V#q7dBJASK8A{#}rhJr)VUQ%6VV^5WNjc)j%|mMmZ(jYnu;Zvo<|?(dmW
z#sHu^0IvVL)ZZ^dn*;<d!O#C6M`ythRo6vfLb@BIWoVG@2I)@ePU#Mj?q-0YyAkP-
zE@6P7K|+vD=@g{C`+oBaX71c`&OUpsy`H0+`rzkdNt%nF^+7+~^8mgFVklgbN{32u
ziiZ{TyvnLiXLal^LoH?ohN`L}V+PW)HezM%ZgkeqteO%Zzik(kYDJrDl@rSFG&&C*
z20!P{6YQjY_CerQqW{)2e(VF=sIU6OJOU=ORk<O%Q`FadC(c5s<G>96hC-J;q%1cn
z>|<)8mSdzm54$cuMfA#WP!*lxUIR(LkK3kwm<m~;bhqT19Hh}2mB3+pne?aFghXO<
zNn!cD<RBCKT}mx?Bv(!*HkWx=8I3_if95a(Qa24p#{6_ZKZrH$YWw>@A+-}{e><=F
zxh)k8E*|ZSf0Px!U5OJpsl=L%6@$v{Dag#*n<*2v=V8l9dJ{0zL{VFZO^?q5$g03g
zsG-~1)AQVYJw;ARiu&fsv>u=a0^wTjyQ8T9MJqP8G1ui^jg7(3kUF(krv$F#Qg$H+
zDRNY3%{!P)U*Grv%)e*vgJn^B=B0a04Qezq@nt|G+x|ZH@VlBghn$B%Qv=N>2cNaB
z<MvMs?C?_ERG2sg5H000LIbEUy{v0A3ia?#LA(+bIhlQBPf{oM9ujd)RRGR;HYXzk
zBjax@m%Xt!4rB(VjZM&I)w6XWU$>2gg8a)Zso`U9*zhN7UhWW(azRK*<0heV56dR(
zf!>Na+zgUJKU7Hyj{}kM&O$T@64K*WE~9ipG@$<_EvPifHb+rFGwY*sz72z&ftQJX
z6qX1^pA?hIBo~JuSww2l7odBg{T$F6ki6YO+hl+#D%*uxm)c!0krKB>)LFvJJyo{!
zy&6&L&n$}ZS3oQPoOooec3mk(GNI{lmdT=vEL=E(W(Q(-`<Mvq3yn-<QH?Gp@+Ky~
zf!6N41EH*glT)JHvzQn=P)g4oc_=HxWJyeRZv*~IvQPxq)cpKO1n}ILNqGx`0-|mF
z|3lXT8I(ZAkw|J5D<SbF8SO@4p7ZLFSAb2^OOsZ0I!tT>!Ma-KldbK@vk-B7h8`ia
zPcTqX9Nz}OtIl_J5+9@=Tt5KsK6J+&>VEa`1QZsouC7dk|9JSda80W}z+E)itd?t}
z@UCc$VX|B$2wV#}pR<&xr(KB5Mpi~QRK@V;Dv{wdg<F2Mt*xwFsZTA~-4a}V{(z;V
zc|+m%n}atQtW};prDQgGEGB4%8Q_4O#;i?Q<OGrDb&95@q|u|%hDd4A!$L1H=Y`${
zIYsw0>-cCX6_E(ODm{5dbk4GYhwK|@wyui;+~8sdf5f_c`$M~Ho~y5csA_|)o@ei@
zH|UjxLU<7#{>eOAqdV)LmWv!YXpEQ!9XrZsjvmfsOSXMyvyMj(LFZ@iy8l<z`K*Eh
z7nifclanN9<?rHJKz8i=_qFdoOx~14-|Gym3;;%g&abW-v1HtxZ%By#_c^KP7f#~g
z;qe^85&%REf(nBa8^YloK{fg4qw7?Kh5$ZjQpO0h5CVEjZlK?PP+A=N;E#z29pFTL
zV{b3HRKCbCcF@eoFvH7DhL46#S;BSV%jU@Zh@8ygEfBELuGn|$@Q<P#-*qwG=98@f
z2Lt}z;I?mD1VuwhYlm)<^})Vv+pkx9OGGMB{G@l4Sj;9q4WKbCn{fze>mw*<u)I3Y
zTB!zP@YONTZ)_BT<#<Fhh7bOst*C<aGuei##>(&wp$d60WnA(NQ$_OkxVMtGg@KE<
zBk%~iOufTY1qfK2*nj5MF#qcH7t`GT4haDlrsTG9ND+ZFdX|3*I%v>f$~I&cm?5;|
z)WC}uzK1cGla2s!eu2HefFtWZFo5^10x130FGyr$-cFUdf6w}_Uxuq~K;-{4@Pb*J
zOv}B~jSSmRwNa~_|NZ+nfVMllxv}OJGGjTaQPTYhpirtcVuYvG0D>sY10N0AR$aT>
z4_~7B?=d^8pR=lZth#3Yr!G-)WzAQ6XDw{17U9+1I2J~HceeN=u4IVTz+E~bkq#kL
zSvP`hyMBu=`9fj(!sZx*k83XI34@JdQ&QygeA~pi#d|(6l4pB@>!W;r9D11o5i^2#
zAdwDSyXT{e&$*2&QV_=rrRX~;G}Ykst=I6r?$(qTRnbN|>fCE&nWP>4k=TP=e4Zd2
z$+5D*%1p~P3;no+T1yr|2KY$(m|CTpFm#RQGH8mf7r{!rRy0wRXi(xZtq;X^nRUt&
zuO2#qHPLE69bP&o#S_0L*}|I&rLlO!AB`zPq-1NTKfuiF0ObjD=WkI)%%4%ITKq#A
z8Lw)ZdK8w%*5SFwcx5IfEG&4K7CI979K^-|LW%ijz}zi}>Oz2j{8F%j%+=|nw!R)H
z+va$k0j3oor2#ZomCAYWZiF=O2OS;S`*sc1jMF7Q`2+?&9nM-Pf}K`LDJZ@_>~rLK
zCS@p0)EV&nxfE<9{qm)`S_hj`HBR;=(AuD`s*3dOTj6T^<O+wl5*=M#v1!MRiztEa
z1F>`W;2;2f{T~*s_UV*w$@scLpyy~s<`L+;EE#)F0whJJ)udrdAp2X)=S1Jvw;j48
zg&QHkj0e~4bo5W!yL^vTfS&m3=;<j?@4Yz%Jv+09tg@$E?yW<yWJS{l!+D;XX^B!%
zF)J}<4th!6B9Q$k0rllR#Sk0HLhU>4y-M*PMvt&KV{t+C1^F*A|8TKIg&Tn$&Xv{J
zz0>eQx&D|^da5;o#jj&UEJR)>>lc~|xeH4z^%T)=eY=^_G|_~??YB1AI+8xjjl;)u
zhef$%<{JA&Z&-WNq@_IGwuxxyATrouH<PI-ykD<igr7H;rWyz9FvB1_Dv!_W8cgYG
zmCi=hwY6T3H4)OZu&Z7GEzw?k_1kx&$96IYgQNRmR-Ss&nj2u`bk>O^rKvC^Q;O^_
zYWq?=R#)Do!-O~2|K9m=VzR+R1H2B9NPs%d9vrcu&a~U^e4OaY`yAxbl^Flt(knd*
zxyc~lvtl_DA!_7BfMO*HIY~TTJRZ7&t)^I@3JO@UyNZQa(009xTZWGGCPIb?Cvjwz
zC7*Ghgu<ZO>CcSSHJELhYVE5H@JQ{*qUd<6#KoW%P<N&32oxv+3VOl2rVn=B{q_H#
zJaS{8BCR&3=m?8>(=n$3e&r~nF>e3xSkVeBnlV4o2r<Ivthei&IZ_P}>4ZRRnqApj
zi(^8D*@_0y^nJB_<GM=7xkwSSC|M+keveE(@7FLPhIInV+>o-vJbcQG24Ow>SkjJW
zdJ_mBHW}xjo*1s>tXBT@6RmLQy=$!p*q}fO0z{GmkdJDen$Da^q&0Tn9#dQl5Az6d
z;@_j%lZggHWZw&5`1MeTce_r$1u!AP!U)jh<7&c8Gc_}_vwz2)B*y(_FE-LkK(m53
zHo{uh`yC#XOQ&a7C6Tpy$3ho!J)Y-$pZ{SK-N7^d%So;D!Hx7t%%jckt|&KwJ;6(c
zoPUSpw%@b&pHE)j6vp6ny?^%AEO}i1sC=5g_FxpWs`fc1CGr;M32}3iVz=5;XgdB=
z3H824-oxhHf{{e6QJ`5_z$ezKZ!*a<yfW`XFGX1=A>7rL+%9CoMI?m=X{KOF2CHH}
zcN!BSw*;`YAr%>4$j<P>=mC?X&R<-N(sZ;14HYf5E&W5Gr1j?ny8W#WaGOYoT0F}0
zJa9-d!)__6`;u4Ne2v|LQlhdTjISX$)@buRvj;|boyQBKHhrfcMJUm*opR?64J@f-
zLNLiDXSAt;$qHhl`|%^<m~~T0Nr^@Szw;+=3cJ8=4Hp03Iz51}Tv1W+@Zhg-b7Sme
z5LMye?94ttPjG$B(+|+A=pa$2>@W&y>YBR!0Tf?|(kOT2V8jmL=g-cttKl6bD=WaU
zQ=+l#KgoA>+P)Nc*K9NI^>S<0aaeM+Wno(Zf`LVAu7QXA$^|600)VYAtIq8JG0F>w
zF?1PG<Ikm}qJn@N{A<n%HJAv2Y^&84hqT9OApOf6K*f+4yGa2kt-`OVVHZmD2qBr@
z0!?#sR2?0vl^QcrJlRU4HH^@(3|1Bz(W=>W=Y*$2LK#Z4Y_MX&sQ2la_q4U(BNrOs
z@C@lx?CjAAuJCUgt5YKpRv8;WBRnc>U-nqVOSl~p*S|9VP&nmB=SrsulDGtEA<Zkx
z2+|pG!4$YfB;sudFgYr+zr#!;X*+e0f15Bao_?|SZ^89>6C5iUp@XYOh^VM1gV{-o
zO_tK1T9#147GjlC0o~F3iImK!&qVkXG~cA5%S>2v6F`TBH4CT>?RirMcKP1-7r<f!
zcni-r^XeOc*8+eH2W%B>-p8)Jx9nqW?9hRxtZcH!5rG#2O;H({WRm!#jcFv37DvO&
z<;L&M+M1ybV6`-r5+<khiPx8nSaMfux0FAh!Upne8eORg2q=UGQ|aJjWZ;rT5oWY@
zBs@l$jv!6xWt;BN6v}O$Dz1p_Q(7XS0ZLR87T_Zy=x=uglCsa0Sz}uv0u*t)ypAg>
zvR1I&b!e#D7wsSmwOf<~m38?Kl^R1eLboxew(HT|_X|&-1@>5<*S_b5lG?OS(}#}N
zA*o>Wmx9wSqN*@b-)qIteom43krv;|6Ym}}@nhT2Fa#oZ`7V??485F5?PTFA>4TK_
zb(Kv_KZ76XlZN4x7kIA;G^wa14WTzE;8yi5DI!2+v(MSPu1<}~fC;tb0~hfMGC$kS
zus85bA=<jSz_~|>`LC-}m^$db7zjR>)toz8czNz(kKfv&b2%U9b*K3CYcNt;D2-Y6
zonMb2c9V+m<gZrI7r~4S1^gwmX%pYXk2;%|4cD3v?R}|#Pry3SmohInW^)ialn*fx
zk1Bm_oZhHuBitS0HSZ5RME9bleTBwq-hVyTMihWNEG1Jt9&!#P^779+S&03R5m_-%
zw24Vc6dTsz`&qx^o#}BT@bD{5G!-;3C&V+lKHaeN+(9hanck|o9}nXB5x`uC^}DFw
z!ah9r_caQmJe%|c;$KeUuq)<8jsC`OCu^9Tmp_tDP6&%Oy&Ig{qu-Ay;0xY|zsW&c
zBp^3`7MUY3$`XmP6}L*0+uB8Yp8XU@>_es~?Q!7KWp(%GD!*<x$EboF<$Gn7S(B)i
zxNFz5W2FLKGL&;NLfZpXM@o?;TR%S5`|PW=LDGjgaWlta4W^8|aV6K{BKx<dz}*1-
ztsHIcWK9i_w}~D(2rOYNQ6O6xNF5aiPIxx{rC-11e*NO*=htH)Qkl=mCM(P)^9_Hk
zEDUOCZSAWWXM}ac#dV7qo0?#0uyON6vT2)5|LvQW!Ev8g#l*rxwf-E?<m{Zqz{8Uc
z%l;Qog7;wdqBw2`e!b~Se}I18NAD=^8WImYRsB>}$6H?ZhXo<Hf&;H`+V^2E({=6p
zCBUVA=|>UYT>P`r<$Df*tofamH+#v0^Tx);01;{LmpITW0C23+L53jwG27;(ohJ(;
zk~dp_Y5v<!te{|R?IQ?k=WeVGQ3HCGjI|pljNWa;pQ5Uw`9sAA^id`cIY>(JSMX%w
znhz?yyt+Um0#sXp8$3~mWQ~)GdwV+pMeB5&QHUUq!7?{Id7g^RNBw9e*RVgTmhacl
zn;B{47uG_o@F~TN;*5`$u~_j9NY2SED`jBd*gW*(;7SCs<Y#<mO0Pk7SZ?~B1JoUK
z6tW|D=DcS)i~0tDP<`FmC5ZiCVqyX`oB@I$aCKa&HQ2$v7U1QrHR)>8U|REDGI@S}
zPD@J@@ewTnCPK!OMY%a(S3iEtTUjMl%r2AG)o5KkBvjxf&#zCBuLEi(-$5b3dFA@r
zR|sHfEX_lrsYgr%9DE?DcyRO9$9iqfw^>;%O4BUNhDT-1i)(pllkD$r_Vyc(HE{56
z=sV@ImD0Y3qBF^e)glwU5Cy@j58xd#{MEFNuJ8BF)XD@gk$fwrTPX>3RvvBQz|CHN
zEwee?bNc0;=k}!(%hrGg_7+@L-I1bcVm?)UnaauK%q>j%<VLvZ_f}C#ufYqHtwFgZ
zM~rQ8w4kS5RaUiC57IBe9b(ZA&=ZmlrVpUfMr3*)@;OtgWRqstP3`T1na4Yp3+W6t
z*LG*MoH26jRa4hD3vuYKoTPb$g~`K~O>Fh1J^wDYhJeSIs^I4*NR9o`2qGjR@;D)}
zDQOD%9jf2lG^dxour-8H!{Y7z^F5pWo<~g+_`%=Mh&j`p!jelRZG7B|Q^ApSi?g)!
zQ22OJiH=T3mcC&JqbcHM)>j9@{P}XR)qz~3dqQ9rx*&|63(oC@{yp0>#X42(c7V=O
zy2Vq!+VV>bYnymI3%snhUA1kbw|}dU4^zL2-MGj_8|k^HI=Cb@Y_c994IM6#C;t9>
zOV}^L`9Nbyst$X%98@VTNNtVU5ABa{jvUHlQ_U8S#qxwBy&(UNABP+5(x65Jmww%W
z^75c<+hMH4QHMxWJW!<XMu+<|`fXAAhjxb}MElP~pIt^u^8=^l4Ox0RxiiI@TiVh;
z4j&igria2Ubb0c?S)TFe*+NJ}3mTx>225=4iP;pjw6(3+h@0793-fJ}f2!RHVZ7R~
zdH|kL|K-%Ce<3{>VD~gOTH00=Ii$nLhDN`OsSnM}A4RZvZuTSQMAbFBZtPUVmVmsz
ztQ}*?l`i{OThN-A_4y4>OkUP}yj-@D;p59<;Nw%kkCT=cp&8y*Q5Di3KOua5CJ=q%
zM4AMH7_fC-ZbGP;G+DG3wAaT|l&TDkE^Z}Hw)#0v&0K7bZHyP?3xyoTc^_x$rThN4
z1-vwzM@d9XA9MlN{Fj5*r^3RQn@Uy|7AGJC{}Eu+`!98^w;F#l)BOpIs|v)A0eeL2
zlTrW9<%f580vTrDGJq-nAC&#SRC-9^1>kwS-l2Z=qrt7Jt250$B|wkdKR8fVlEeoX
zrqXZ41Ma=fhm?o@wC4T?C*5!x!s6o#zOx}Q`yTv|8T@eO+b6=ucY9){$fVoy)gFzw
zHm%d_YfTl_)sNWJTR8isKg+~|ZyeDCG`n*4JqIi<)GB;llAf#V`$=f|pFW?q)NEdB
zUr6J6q=X|Y6p&sUt)MF!3b8HB%mC)7cd0QI4ohaiJvB9eP3;;0g2>CuqaY*e^`ch+
zk^IE*&(B}>n#4IdX<!QY5Luc{k@IdW5uX!a^SHdf)OU3JIVo^p)i`(Bz9Se<;AX|;
zb5_=x(L8NCO~voBJ1ehPo{}Og!leROn<9jQ^2!yfN8R}CaNMlfO)@?-mCa40k9GNz
z99s}B_9Jp)xG0TaXGJ%g6Rn}FZi-fg@?D_8tz)i2#?cuzN44N)X7xKdDsAmA{6^^}
zC!?=a`38P<F3-Z3>eQb7VLoVzydRu%2%)$$6#IFl?K#OAzMGVTUn`5{Hg@~Q(f=l%
zaKHMGMd0IHylKBi9u8;*gj%|QN6NT?$}`=knhe!8GJ33~5(TO&h(pfVX--CR*Y5yD
z%bzu!exikHnK?Nu)&@BRQ{Q84Vd}1*-VvAf6_UH|-mL=8Fnh<Lb36N(y7xJ`{x_O+
zopD`f!i@=85ht4p3i#k~ZEgDcqdSIej{s5OAr+oU?yLIypU-Q-TqLhxGc|61u_Z=@
zz{vVMsQ*`eZ${tsVUv%Zx1}eeDJDVc<#ugT(E(@&-;>X`+#ua=GH~CZ{3^m>upk2Z
zUvA862t5r1Ih$P<j(!;3WS=$*2XL19O+@X4UnxY<<9l>6SC0c0H-RxJlGoFEU;FHv
z{K9|zv)_EbP29gy4r19mOxVfAhL-<QRz~X4&;#9yh6h)tyB64eL0~g7ZPSOqKWxWO
zYZ8(z2YYeynGH7h@AD!Qssn%jth->KUqy2>JFeRZ)GAx0x(V!-B^|1RUYOh|{FWSe
z3}>D3IKf$yxk7#^b?<-u8nt$#Xfj}6G-%F=riQ>F`C9h&h(`Vzarxw<*XsYpZ{FZ>
z2CplWzy@<a`(xlD&ZN=0?K9Cu;nM-m!<K*ElG-Em;rr)BAwle<M0Q$u_3InWBr45h
zh4Yk`hs9vil`6p0q#blG(MRs`eXH-e{q@ecFTbFGikw`Vu)MOe5<u?a{QgeU4G4b<
zLDk|phuh*f?kJl!b*%`B?@~1pnb5{V!ZR$_>dlR&YpA($Y}pe3&}qb5feSg{smXU4
zU5gtep98oFFkj+|MFs}iG`jD<GEGPv6i&0J#OFVmmr4(g>=dDJs#d*0BL?)NZ*cm`
z&w~#cl%WbBAX}Ir&B4{R?_v-m_~p8g<Moq;#enKK%FCYFi!2y4#0fO2Pwf^*1z(>4
zm-EO0&%u7&&JKz+t)Zdcb*?|m=zbIB@?o5h@6pgO&)lu9cpy6`E_e$=&5ABOoI*_L
zix?Kx#Dw{3*}T(=v<wiT9%2;f%J(}J&1NurG6mzuy|N%mFXF)<xzrXj`J)H2W9kcK
zCBZ?xxyTwy4=2JarqSkW<mWAE)S)y^MD8r*cGR_Et@giO0{RWV4lrO>G0^6sWBa!n
z6Sf#U4~yt+s@2})pC$ZYh#MXIfu%Zcw07uR?531w<RfJ}0O{`w_HMs}aJ(h>iH+||
z1UcD;+BTD?dZ>&Gw&dkpL+le<hXF;r0*?o=QMr>?X?i6l?dZ2G|1PJ-odZd#uaW~V
z`91&fnt;4!UjS@8{i55L<>KJ5+){02X<4gL)J6<@N4yhGy$dlqJS_UkDlUE&A#Lof
zt2Xbq3E$btM5v#Ha<K14kwmfe=PQ@0N?I}P+qZ{*Qj`qnOIa#h5>CH4wLE7e=F|$V
zd_T|M>m#$hw|w852Xj5R%RhqZou7-qgg&$42n#k(ENb^9e?i1Nv6#k{fePM{2kmSg
z9(Jw#Rz4TMGtjpZB`PnIA`_Mh=gh;QU&iUVfS(X(JfQN!5)I9d@GPbb!ocZdT^O*a
z3jH~QnK?+Z$(4oTz}&TWe8HXqK{ynF1oR#U_JTJgKC<}h{KSs-q{1l&YqM!-%P3>?
zJ)drq--O~cd=_YKKCAY|*ItUE`aUmSE!ibMV&Sef+8jw7Q^&v+?PCd7Fvp|yKwST#
zJr6n4g7fn6QBzm{sH1Zq_@JZ2N*wzEkfl1Z&s>rycVwuyKW{X{_P(g9Vq$B>t<st?
z89Nik+rF3QjLA&{4r{<%JO6hreB*p#TAc~K=>*Q%SrB`E9&V3&etu#?!zkWC>wU8`
zd7J7Cb|O|z9NUuoQ+0`WCKDmaVD1sC*4m`YCTrl{X?IV)&!%#qgZ170#$@mf+mr`I
z`-jum@6!YR!4IxKhmVH4GynGH`f@b5C0HS$uP)!ot^0BOU5EAfdiqK{&#NSJ*;=hu
zeEAl{9vn0|ISE8*_cya5poLv%fq>$>xy?S;`M5gJ7@?=Gq`dh{z+Y3zk;Q_Zwq$_`
zgI64^+~o(GPmf%2ge1!|{og*O6b!Uw2T-`8{!A`lgbPwwiLYL-OEEg_3}{S?4rM7F
zwVyu0{lP{Yy|tD!Ja-y|-o(3i%NL4BnZplY6w}lyv4-FfLdVa}Ojj4zZX3=3TWUtG
z7ZiaK8Y_o}d>dFWr55n{wC6JyCO6q)J&L`(pvTkq-y7<xiMlL8*Vp&YW%FxZ1TL4)
z9YRJ+vBP;Ia{VhE1iG?IT&hjiRqjq0YzSm8gZl+S|Jag-P&Qq&>>Ifn<t%2l1fMp_
z3npY}ED%K+ZASaQTyQ9}Vtmg~4#pZTe|0wbbC^p+WKq9_v7+z;P!C-8Jqvf}sDZsD
zuduSh_M&SeL%^B4??LqdDq;GkTqri|3n;X-W)^Zb#z@TrsfiG5!_t|jDFtQwT2~3>
zHoLmrndPi5Z`yw=lWWAZ{rj%^{vDHPH{N*mu#Z0SHHsS>1qPoam)e5dHkqvGfXM+`
z!Oust?MpuZ<REVL1I_&p862;`5=waJ*4CvZmzZdGY45swvYH9y5${>d^@^RkxA)}P
zvIU>O{A_5621}ziYx{4x#?eNrge2jLSZB}2)1;kEwWiv7=-2UlzSPp|?10KGzHSEV
z=yijD12{y99lK1C%xK~#0jO*Dn*St#1Z_3wG84GY*$~8;g4z<7J!G{u<o>1-6<K!Y
z_<LrNyl?-Q_uRL+M6VPQTU}%w>#wm-mTxhT+(G3@`GZ#epM>8Z(+R{2=KVX1SB#dy
zV{?=Qw)Z6o)GWlVkNUoYL>C}XKMG4aM32emW9fGk3Z_9B4U$;4Hwg5;PvV($g-ef*
z9ru=SeT9>`lS{pjZ$=&W+jPY#?23>bg%GyYot=~AP>}l={ZsHO_3H&reDqeTd<^vH
zkS3oYRo_3v<C+KO%VqHDv}wUu;CfE_<y#hX!M*Yhc4hS-J<RX!R<A#Puvt%wWhP<E
z$*;60@7u0lVjmnx*tw<r3#h1M#2TvkrrO%R8Xm5qqQRuWf|tz08RBr2{HpLCMV|_G
z!11V42{e*g=C;`rwH&y-l85ijUSS4(<H3jK9o2e`^YC4@p<FzKXn1vQaW><+I$IhC
z3(jM%@Gq&sPbs&>lqZ4${&%zoGd@SDOM9lQt5@}TB7Lr3Ho~DJ*aYk2i#Qjd$ZvHP
z5GmZ;e&u5q5>2FRj4wj{*OFhA>bk+K5->aMvI1*g$eQbY;v>TZ5N6y%D}CVk^1Mb3
z(l665`ySVZNnm4J;)2Jh>wKASOk3I8`;x4X>;Lj87Yt%%J)S}jyTE4zmVD(7G+Dk>
zPmALR0X?kEMm9Ar@+y@U4o&3Hv!*6Hek+#dbHnu^eFDCG(7?sBbtUtAHsYGmPh})-
z=R{e=ZH@QN&dj9Tq>L4QO$!18?5nQuS^U$z(+&6N!MtzhZY`CS<AEM%5+!0+$)M-U
zL(g7QuN9QeymJ0%kB<fzW8xM9wgN!wgN&)<R8%|Yd?YY(58s+o*3@Og=%cPD=_{;z
z?{hxFD-=Lz?xZrk=l9P6gtl4%SU^~ik+Uc?Stp9(e%bP?xqsjux^t4^JAJh(&8Utb
zU9;1)NsY!kZ0R6fG(3qyP#I9?lru*kSAM<+jcz8H)Q94sMoAA#_S+c<8K|+K=R{3I
zYjh_jtVM*ETjQq#qaM##O#+y$fHk!JHxsViwyb3H*5mQCrHxx~ls*#|^DU0}sH#A!
zN|U9^RQ;U60f)DV+i>OU?bz#+Tub@4yy>hQhEid{w~A<EBZHwUbWi_E1(Wh;vw{hS
z<4fMxxqpQ;5+!7aiJ~|%`w#65@QxZRPca8P+{L|$$2;T{YncD;)RmF3%Fn-rCPVcY
zJU+Zz<}cQ$DS4-D1lyl%tASvKKlm@!T3Ckdi61O}tC+U?C#K{WK0T^AlRj2l^kJ~@
z+jV%|G07px1ZQbUL7_-6c<lLPBTN6|xQ+F(Iqym<{MT$-Ntv$b&vAs!*1;3WHp&I<
z;J??K*gkt>=k0fuipLNaAdgm?;wL9NFGpu4n1p54RJD%MC9H60dW*yV5B%<J`Z+WZ
zA;%nZ#DZXIY34i>;bfSlA2cz<X)P6wggWM-qe;b=;9?-IWpvD(d43nreAGgQUhLo}
z`rZF$V&cNW#m#&qjKl6gZLy9W8*35}wDxyF)r9>sxDTQgu@$Lmo;OU8;n~tPe@20g
zS`P1>ymIAuC*sYv)vO%p)T6rclBB>SU1w_#>jEw$NmvEc*Cm;nT6B2!%lezfTgN}p
zZJvj2BW##ENtYW=)kd<BW<_rSlnRl7h4oevu0Asq9vPX5kd%B!;x)~WVwEBL!_s80
z_@{SQPpMVSMT;^$CL0dEZQ0I5dvQ|8)9(v=;!O&-cz#AdC((cDzdsD}R-eHZX`*|8
zovO(jRR@PgdI}yqUk8&<jXjh+r>#(%4C{(a{x<P)oe^MS^7Z`7zIK)Qv}bntkxDe*
z3jyyPdrKay<BN|OBruUj!{TE;)Sso-f4}SK<(=8u)Lo)eZSlw?QUI7S+3n5pATbf2
zs<6D8-1;CyiG?wXlk0j{jMN6qzesWU2FNJm_#?snXg0cr>9~deJ->0uQX;aEJj4KI
z=(lKS{vTWJ^0CsE-ND7>MaJwM>Y#EaDx7IS(@HJKpv_vxFfQV4GprZ<r<v93ibg1j
zT6Gw{Cj_*UwTzu4>%u($iw$0ZI{@P+J$P@}^wERA#llKxGn7+#xH0ozAY(ux6<-mP
zsj70}C+b8?F4xultHJgVkO5fdBH$E@yc3&Jm^hZSDZ!$Mi7C$Gw6#Nn>Gir$B$q#R
z@@h9NuLXB<lP1Jj+e}>+X$*9Eza8S<Nb{|-U1wBMdOX+VQ=&uh-qCDFk-eDISop%Y
z7vEH*J&Knd%1OA=G9uL6wi?v}p7&lDj!R((dzmQKdZ~`xw%MAy)(|OWdKCq`?33fs
zshHPR<U=(xUpB9^kvoMvI0aNuIcANDtO%OnWs5g^3d<&IGPv?bM*@u@P@wqg8FNZn
zLWZDBnL-{BZ?ngq%d`lI;ur@xQJD2Nd<H6C9%dkg*e|y6rlX$|i^6TJgo_?%HU};>
zJsO;eu@NSAnR4&HFb)d+esi6jf4_(1MXL|ukPoDl5#asS(zJ1K3DBT2tgPY@M<ypT
zj=UQ67eap->SXw>RaY_b^G(v@+uGRNm3?qg9dggg<{~DZ;RWtxIq!;91`*MmD;RXZ
z2-pTq!v9tYsCyxfDBbGx+-bSXUSDtL>+<GQR+6b38cRPUdv@o1q7+l+SN-R3oTAC?
zbz?O`+R#5}7@&e)nnmy7`9q0tZx~eJhjj_+&i^5Xi%2e96cx$rL<9>FstPrA<H>Hi
z@F$HPO1Cv9pO8WjjeGa-jFxQotBK0tQyhI-f1oRexA)1K!Q5?v$d9wXjwEJzOSd;x
z$waHal)&ki0bi2EDqNR0nZ_-RSz%1*JUl8YoD%Bd(`Ub}xhcd|_#J^|9XYt&;PYPI
zn@?ABd){6)k2m?{Esap}DO_zdQcQm?{CCPvo55_92X64w6l96@!^@`o*>ulGv9tMR
zuYG^6bd7rAPHwixagri$6N2n$`a2E~K=>`Ks#EWm{k0K{mM8^K&7Rme-Il21hdD8I
zpiXsq+}B&PjAFNj&_CS)c{}8jiLX}M!4o{M4&q;mgNh@pCo9(5FV_D_S2~P_PzT3o
zq!gj3LuyIRab@g0?*_J|uqOM3<2~y<>&Pt+(Y`FL=C$|4I`XxAs#(pygJL9`^&`>!
zqsOKqIOdFgJaVlN`cRd7M%vibL4Hrvhd{L}McqqBF+0m+ZTaJ_sXgZpCK*lv=av-m
zajY7*=p?GfJCWh4Fw+P!TXJ}XQ1nUA3tBJM>Ocr;BdU;Fp#5Z)5Gk}fKLJ@}i_<9_
zPw9~ctENT|*5tgpZZ{dJ-)uWc{V++3I>;J@3ODuPAu!0r1=}8&x_Jn^^m_u7@Y9nM
zV*qgG@w){W835Yx04qHHedpnd5wKGAYt12EI*L34?kbhtg8b(pb$Bk3{?fPUTJf@m
zYEshJmlN1jg648SjE|tGh{)>%3kBTi>ExE1Tab8xLYecbTV7gp*yF#>5ojeV>z5?$
zDeKzt@jOr}%za7-*xQGrsm0&4wDWM9|Gjm863mHWqk}C@<yWv70o8oq!otk@)cyT7
zKY7)pb^?bz)rn~pEAHQ7$g;jI=G;tjDcD}xaR36*OV62Qay(NqpTdlK<L*@yvh|+o
zG1u+89wZIS>q;6S-O|?7(7$F}T}*q~)(%v|&d!)vMAq3Oa)yRg-(=?-oaN-0G8>(*
z{23UU+En?!lAtfQ{WexNfX;9#?P{w~$gyrR!>Le7hG|i7_!VPcnGXcmhp=Qc&pWAd
zA<$tkX`p$hL|hJIJ~q8=Tj~qAeiSD*`T6&2-)rvLN%}4mdQIZqrUqUky&adqsCx=!
zipG~WM$E}2tBkgR;;dgJ!KiQ2b8`M<XSe8H+*@~W|KU+>)#3IwF*8jZ-D&*zjU_2@
z_UG^o@9Aldh5ngq{O~YY=UAElu7Vn?V$cKGfm~L@(gi|>Eqw}Tg}Yh!<eG_|oXT;k
z_HG*q+l@xblH)T5q3!KTLV<tIrIkwSyy(~mR$U7g-CYohlP!bd+lhlw2vbL_FuFpS
z_6(A^mqb(|r6i8!R6nndG(kc*cJcrM;Xo)^jMeU1`7mL*uBMIw)n7lraSPe8uU-h(
z)m4~lR1X4I7Ru=Ydt+t6+izd5b#xuBuftDIk2;0ds<YG5Kxu^W`otI*=}Ls?CmXK%
zkW{5DK{A7q@}{-lN|FrPG}$AZs9`wcLc2GXQMxYpSWol_7wz))VOA+&ih`E&d;`(_
zZL{%*%1ig~%UwFIOUDrDNNm*p#yy#0_KJhVgF^2wR!0GCaGAl7>~AN}@5>3>(9Clg
zCrPpI%L@28kob%p(kZ6b@c6bbiN8R;2?fE<u@gUP{#35FG3fBBi^^%gzT>!v#8H3A
zbZIS3*G_CQRxD4*1Fc978RYFH)%GPVo!SM9A4Do~Y%$AO=7}y<Nm?+9Y)n5MWbtrC
zldapk8q>IJ@n$<?fT;H^{$?YO5Vy6=a8GxK;?e1q+<?^OVpO;?K>jf@A#ro^jGV)}
z&reQKH!Lkz+lH3f+MMv-8YrF$*m4-|e;;)#PBg~fkqct~$gHqj<;0N)wNg$lds4z3
zvRfsC%~A+$URw98zh3xJK*z{O?z=Wl@1NI#9!I^G@RFmWqHJyLCdbBZgMauY(4f})
zy@M0n!NkFF{oQ#xno2id-cV7o|K<Gi#`5y=5@7DYc>jG9=$zksz+L<xP!9y4*S$ak
zO`Qx*M^0Bob{?ed;e`bCm?$?4P$)v4*%2gG!dnSE`_kw>!c4|07e*=Y_99@<TtiP+
zgmmG`e@)g9=*&h_S5#LMqOTmabb%nXHR!mgDKJ`COMCMt-QK3THn#bLW_dX#ViFAB
zGOd#pD@@EE@a=28t2Q@&GrXcro=+j+p(vl^{65A}8^RH6M(d_WHw+32TNfF>GcXkG
zz$lVIxB~qfD6K(Co=yQ3RWTvSu3*U~GoD@ICO5lKau$p&$h{lhf!^NTIoXu+h`?@m
z_qeMG%kf?09vZE7Jtn3(_$Aw76H~{xLnP!6MEM#JJ28wuZdMZbZ3^3m$T%crWg$zU
zRjL$?8Wat>=r^~J4x;W#B4asag|OYL;yb9|h*!arixySyChQqgYG2MSd~ANueGIz#
zPg*Uvh8A^`4k3|qVKos5^5c)51+y=Rf(b7EjoXOewyZs3<wR9z8Yr4jLX&6})np@Q
zml&azNtP(x;yk2myVq?N%dBaMSVLr#?C^<v1tDRzifwA_t+xx0alL|<+@4#3sy4kN
zI{U0p5s~~KZ_>nWRCs#2^9(}6!mZ5NmM<gmUB0nIhp7t5sYzXKQ(CAOh`AIGplN96
z&T(@|xM!q9h^lbMnif@ojfEU$4RQ#LLP~Px#i+Ewai26eGMm9=%38Bc3@j|RJ*Jk8
z(8apFO{qZ(>yE7H`Nb%k;u_hZn2D(zBBIFs{khTYlTTihirbq~42+tD0_5`7{w*;|
zQ%WEGxuPzK;cMcVG~m&7rU+0_{(%<;^Bb6lbn$iFgYcxMEeIPitl0xM;U&DnsJ$*4
zv(oqb=Q-h<HA3EilqlXeBEcnpfNACUc^vi0W+X%-vaaX$gpf>y39v8H=O7=qHz2A_
zz`KQckJNni`jYd5GfCFL9b0|o9P8h+%{OBf$n@UY@%Jf5Wp4-FLft^AW@8-~k}jH}
zS!-{>yKCb0rqo0>)ja#+JsOnhgQp#e*Nvxhfy#~UXfdveP+kWb#VZS{7kCL$8!zx!
z*LTMRE)2({4!BSx;wJ0T52X<ln25utH_2T5Bl@g5;YjjA!b1sN?Z8=K9SrHl5mEog
zEJvA#9wUtqXU=VkgO(NfwkoWY$tEr&RA?aYtWE}wK1Ir`#>NnhQV^HJUle$EPcQYs
z_#EREb%;6Bm9nLy+@79oHSb$mpLyTPf=MaLbaI+&Df}oZHwB}1BAmN6Z%6dLfw8Hv
z4T$OJ;tQiX2u;y{ZiVT@J0DKxc5$GFxhVnbzByf~JYU3D{N;WJF!liB$Uvrt!>3OG
zIy4Y431UPJc5OVLRa7v@YVPmvV^at=xNh_Ux|+5NV=g<aP2kU{tg-+XTdm#hff9e@
zn<UxB5dSzhNlnx@qa+l0I-nCmk7fQ)I3l9`8eIkaY8_2YOsJIZ(Xo{+GEE`0DJxfb
zjJq>wI(kRYg|c8c!=FNhz$7^XX0D*6m;o#B80X{?!=>I@$3xHvV@NT#eWN|nb}2H-
z>OyY~qsX@MVWx1G)Kd<EHBrb%D;7>u)>qWItbbcW8v_6M^K<T^VQ$4B;e(2StxsFt
zSh}+aqCPP=Vu#IEgH*1&E>00gudWvPB0bfMkkZx1J;PE<<s}MX*A6a>X0=LqUDRDc
z@^KERs$;^Dh5ZPhxYbhO(rxfra&QQw&BN$Y4HE-}#^87~^fj-nJBkX?6VLcQA8cm@
zYtm*8WrYuWF_r4){rdZ(*XRXNQkTNfp|gFvyvpJz{)>qGRkfCG1`kQNaYf&Bc0L!(
zrt({&WvW*|qdNJ8Vr#|~7n=c?MMvF2uaUjFk=c-??54#z-N}skq>(x8Zs)wLdE-z*
z*rO%vC@$Nl-WW_^QO#*<b$o~qjz!bg7w&X1pu3i(90HO8QSI&DzD==f3|r+L`o@Xg
z&k40DdxL}{jsitSBt#wcXf3fX5@G&rT_K%1BV8dxT|I6KybxrC>fo|HEq+*YI?3AD
zVv?2ASX*NG>~Z(buJh+c)QY+t!DW7UYT4|RXmFwvAz=?L?`1}+$Ebe@`uCFl_X;nV
zpR4t4kaWsph&A}K`r9QXFs1#g!F}XO`pWbBJw*ySU;Sv!DvU?qw54z?6?O+gx&3HJ
zqp;H7587T{8WnnzK?m6VcgN-~R?~uwv_`8B8C8#OBuRK{nN(N`c?*Z+=33d(d^xW!
z#-X|S`^_hbT#Wkze~H)UBoUFX!hG3(%XH9^F~aSpXe>6qSMthpr%~otY)Tz*AK|fX
zYuIC{du#WEN0n{Y3m)g(qUdlRsr;yeAv~^0JRL_sA4T`!E!scMgH(ba(lk;$yrIbO
zVQBcC$|Sm3=JZ7Vai%BS55#Vngm?b};~XpvYM|QiofZ>et$yjX)#aI)e~!njM~?rj
zbp?)<a~mrP_O?hsDHvT>g;v`@Xwb_p>VdQ6sLxHz+~2TtbZ8VQs4F5W-sX6h=zX;%
z)hJ`$+eLq%n0O*4E4k>;S9lp_?9l#=B!&AT`QKVqQU4Eo%qJiayh}%|_+Pld+UN70
z^WfLVP)QoMo5NXP90|~C1_lNIRHdkA+dfI$gJreW-FVw>9xv9CJJUgT%~JoBAoyee
z4x`(Yg-%DO$bk^OrPY12Xm?iTYbTFPc#_eFVJu8gtn@&Njf}LGrYO~XzRdlmm^k8)
z+A@6#f&%{D)%FRmz_=SlMa3aRKMQ(enNB~XZ_K^$&Hd<o0)2Q_NrKgVVAK|*-kr?|
zBl>oPC9oIKt-opX;P+Gya;frh##=UGI7a-E>VhUY8TL!i<gHixq%BF+&8Bbv;8&TT
z#y@enzo;XwEZ_*7$SZ&7#CajC%0;Do=n7*=)k)C}R7QevX%fwmY@LRc6J_i}?pTGU
zw3W}FCRuvRgLDmOcZ$ESJvW)>(FIjSZF*AZa@gK#an5w>=<y(3X&DfOoJ{QY8ug~V
zC6l@(sG}8W&syP7CbU(b*zQjSiBgT7qrE}g+W(`&T}K3x=X%0=*iUkTQFvM<JX~c=
zS>uk_$j9#HP97=cg=^H!9|u-z802`D4X?)~oD6+bv=KPPo_b37Q`#1X9=RfjF-Fi@
z5QFDQz^|p;ET7~ls`7n~G9w!Iz8H?1ZAriYbtPSCxlIZWh?NS#{mvR=2<D|%Jey4(
z^{8eDtJ}J?cKpgroNY87s%c#U4@Q!nh*Z&HXf2Wi4;!(<DLVNY|3$^p7~Rot(YLNt
z%v!byq>-VOr}f?L!I3E)WQirTE-nJ=F-sXkZ#0@>j6=Rq35_}#v4pmkygc{7-P5;K
zI~lnzU$c<mM0J0+ia#$yFW&ntmVx_$IG9&Uh0-9P`#WK7=Wv8t4ol5I+Qn|1yj(#e
zc2=z=<Wur#kccb!@Z%fx4>1!w=L2*ZWpP?IS?DNs5vk|bU;3l#3tz%1YD=fS#YhZ%
zKqA7qzL3HuW=dx+Y}r5&Y<Tiy<V*Yj7_2z*CGh?H7aie%%F`S<uvcHW*iWaUEw1DH
zFJtPovK5cnG{{pFnqYjIf1Ea9rkY8Oq@kf%|L^-SP{zO;M9Z@#tGL0dPpuglgz*bC
z_WZK`mkbqgRMsrty|@!{?Dsu(JMM!!gG$Q4HqD$U?x3os2AdiX$l;P$SCMu{Dm>O8
z&_d}<>8+F~t!;Yw7kP-7$HR0hegh3Eht>broT_RDY!4U^zYpwn6I`30_k^*>AOALW
zA0`5hN`rP66L0TZfDTS1YtZ-d0G3delhXEvkvFJH*y8<+UXteuM_|}$NE_2I`F13{
z!ln?n?LKJHRSZ85qN?oGgA~o05oqxl%=I%9G7)Cw!lQn~MW<E9Z}Yg=+!l*4Oc%68
zw5B!P?$C-yPxGVsN?snbp@-Qr{C?E3cJor>V`f%1JezDaCnlO!QB|CliIgvSDhp<O
zU_o{D-do9e3(v+O(h!eW{N1JmD#n6}j-(H9ai~_Me%2#Nmf0Vy1MzRsGc?%KZfK<N
z)^45Cm(r9ikeSleb!sLcq|;j922qeGtH(Rg9E-N&CI#FRE;0?y=YGm6R;k#P17`5H
zB!1h_-9b<i^{;~4%?ZU}UX07gdu?s4V_AE5Cjxcco)9amOm{*>Em0~1={fJ;i=ua4
z`HbmU$fv2aKixr!9t=sJ^|YG{ZZmWk6on(r+i(#mjJW45Bv?}NnfPb6hgo+N)4a5O
z;|L4)kLWOO<{Sp3u<I(lqpVY<NmXVbB_hu{&akv(Ht)YZxCp<GCv`s{6E;v<Dt50A
z_omlat^(&&RZ-D$WK$0*>x86m;%5O+qoe_yaqN<eJ2NtbhGu>f$}~%(i9~e>CoiXc
zF&57VM{Ju-p`$eVGYft~Fx9Z4JKojjNXPk}%PZjibkLGuo@%aOm=lQx-EPPTKBmzt
z6Y*;LaOM-|ooHrjFX4Te1wzon+H|d<aIQMoRLSI_bkrkX`}t+pQ36`&<9UR&R#Yl6
zNQXa1sEu=}L6_)q`28t}dh-&F$&0KC-=6U9(vMyjFN}Eas#@e47qzGcX;^7_OuD*-
zqEZ1|79eW#oX&_Rl*~winxbaZlvj<)Lrr~-UOGy6dS%X1%M`cQ$PQzL5wmSPwS4T}
zdl>dqVR@JUe=K3sZn^C6eE_{v=F;U>?3h?1eand5NZ4<t{03ANbmy+Zu~A`UokKx6
zbn`yR-;bVxtgoeoG(>tt8UBt{qjj6jgCIxgOodXmv3vcH+MgFm$`6SEzCT-b37F#q
zTv_^t;$JKWCwKR^<2hb{1R^m3fu*%IpyzXZ{Q$s}KSE{<m<hG$W%;oPT;a&ru*_mK
zu*yYEl^fCiO*$=JK9YPz3g{7U-c3kICkAF#@UN6t&<r3a6-v_!L4_`m9zllq(h^Dj
zV?FE^k~zlSzGpny_gXj6*1ESs6=fOh&xB}lpXu=8hKqJaXRGq3Ij|Gir)BQ^4iDYZ
z;^u}e|NU4L^W#<G(Kp~mCSab!VB|N%60XY7c^H*O(@JS74%^~h@K|P7W8v86zqbiP
zuaFtHn1W8s;r<fUfDcBIw;-`DYFRFXO{IF1hzZ(c?!lBLbfk8ggK{J8ui4yh9%uEY
z=0)jYBNsmd77ITn+;Dm^YIj}8rdm^wD<kOYf$HUT35R(nQ;7bwKT=PLu^sHP`J<qW
zrmjw&Au;4s)%Ej?Z;LvTvrgS$qM_LFu`5>CDf(U9Uy!oOrFtg}DT`#=1tKfWP@vj3
z)n>qI90CgI;LIJktkz^uA_8ytwi_GSZa_Yt+|fIs%~^N2VZ;~rV{#-YKkW3JT*Q%t
zhmnZ&@))_9uvajNxNB5QOAxeDw3$D|qCn<U63Q)H$pVNyPt#O2E=90sNpa0SZ7X82
z5Aqjqwe_u?-C&4tsWE$(h%ObTRJZ4(9)EWU2}Ov+a`H=nvei-unFH}?BYLJ++!4jd
zR|yr8dOw?N{3+~`!uEo)m^M9GF+xy8HQtcDqZRGV+MxDKzSYuHHUguYa!jMbg)zDi
z+Rz$BFxikQy_1beq!EGRe=v{mAXA<1F?D*>SxHVERu|NLSA(CbKyGg%ZThF*OOXFE
z0Tz6gUC$rJ=GEBmNh%}+2S*{;Tf#n;L5(LIzw@+C)M!j~l@b~8SX|8%RPQ@f_#%lB
zcHsf&mpt($OkhyQ@VWCUzbX%|{z<Nnk5AOl7GO1Y;%9|<eEhgHGc&_10K^B)YSioL
z+~YeWZX>jXgQ}zUVVQAl)6B%W$=0h>6knW1!r68zg|}O=JZTfPM*2d+(*{~B?hX|q
z%UK2CnL58}e|u6sYxvrw@oo4ri9xQC;m@C#51gLG)^oYcyG|J7c|<)M5aN-MILPn>
zW?S?KQ-5At`hqDSMrgN;vy~bVddCTQusBeE*WO@b;@QTo^G*4-<LifyX{%xj$+fH{
zP0}rb7w_19&<-}2|1&**`R_R$tFpFb=JkEsGXX(zi6nC?@AFV7H>6}w6$3WFtX*KK
zBxfr72%nT?x{`<#+LX_dGRN-tP$jgC93S6HB&Kbn*rclM>y=wR*;Sh5qNYt2NC7n=
zP0G%B+m28LnRe{!!doA<)UHr<v27&(O@$EtU23hkh4+anS`ar<+b86%;N4;aja91u
zT^dZ|a$@)Ep61VYCy3z$9mc^FSV`Rt?0G@lSD5pK`_vv<LD9`SWgE!)hTE>ONEo$;
z_>Y0<uwUZ^?Y<6jpW#`G5E%L~j_#}JWZRn-c^1U%%=ecuDTTP6s~ggz+l*WPSgU>?
zI{$U`Bllf;>_<FbBZBB<&wAgK5cwC(^UfDhyQC7P8kSxtlGJ^8EKU-SvZ`ug3DfoU
zb<&P~PFq7mgT+wn)FgeTF}JvQZ$rb(($doJ-_OSI{Ra}S52;&tLi(!W$*Cw9(AX%k
zQ|GNpoJk>Ko1ua+mSqjI@M)B$92NZ)Q6{p5a2PpwZ)}9WqN0Hf3vv~ePmqStqk$t7
zBaLh+KWpJM@oZBptl}Bt;ls7(=YQeowudi`HQ^ohrj+wC&^2+N(}B|f?VB>r&oD%?
zEPZs2f}jEU{xF%~mz^iOo#nYFDTn>@y@eDsFul<9N$s2RlsLw7YpgLQmf_MV%@s>X
zIKRe{^gAg}9?p+*2O7-#V`WnC&=EuZIOM3(pMFnebNa$bi4Gx&)H$>W{0TB5Ol}J%
z%+7ys9AvO~!_?Fc%>9OUt~rBix|pt6uMW*(R)_>>Bebu#Zk5NS?o`Gb%VpdxA#P{B
zy}cK;t%b^*9XFo;l2@xQCC+RrJ#K`kUc=SQfdRoxI6SyK10aS7A+&#MC>k)lb7zYN
z-d_xpm~}s`#&h)EZ@ipt6!>k&0{z6I`uhKJqD1!Oe9qUMbD8ai9<vj<0t>skKfX&<
zOIK?7$itJ|#*55<eCH>v9dEYZIum3m<D!1{L*sC5&g7_^Bfz<OK4_fw+&XA@V)}sl
zQsmz=qfuTmV;<OW{GTnd4%A2yCb%ON_BN-rWIpejT!BG09FA8K?{iS~s)!gCCpUs5
z`9dfT!VD_IM8T+Ej0kRIKzkmDkX9y@h{(WHK`;I=rm#cFerJlU7W2mkw738LM5_OO
zBA|b~@4eqHl}`qSq+Y#MRaM!DyKWbaaHxza($7y%bqQ^L*64ow_HDW^-`aS7KbXzt
zDyi2}r%vD2>qV!%J~Mi6-~SAA@u2sTJ&*a17@y-8vG7R1BZ!cOFiquVGG53$xO`19
zH&(8xZa0hrBi4(s*sjHW^WPUB1-^hgAik6o6ck)ux({&zlM)&R2L3?SC^i<>&&5S0
z@C^X<T4_7gU@Bu8KM?;b1ZxTb_BJ4b-4kY%m6xYddBu+;FLztrM7Pq$t_Ut+3Vw3Q
zcS+iT1A}@t+4Gqxpn%v3*(2$#wjpEgTNSqcr$XI((D~hY)raC>+LwE|?YYu<!Qt<f
zW9llCBG}ZHgpi{?Ic7ti2KOSMr}8t$8!5jdJotVx=<zK-AK%Y~1;M19DY(0U9vDWD
zY$+p4uPo%#93MY_&^}M0LC_OH;r$PRzK6;GvL46<oYU3V4zK6_*WJ1QL!G{VTvFO<
ztF1Odv}JWbgmOr1rCODAP?Xblkcc71aWL)nl`V_K7mM(bE$a|bISr<glqr(Klrb}j
zNsKdN26Onn-n;E%Kc62y|G>9Lk4Iv>-}n1|-}iODuIs+9=Oy(N17osgfkIK$Kz?h@
zda3~drhWA25iy2ppHqd+owhd`dW^e#>y&CoBb6$TQcuc=GvZ4lMz7+H<Wlxa|CdxF
z=zvF@wECJ}08a7wthoMk2WKo6m($yPD%n0_(}JJYiZiX`e6<qX-i-)l(q^PHdV4qj
zvCP%gmCI(=M6hSL)b;Ka8?wR-RxZ5jOq(K)JkNUB)#YTaPBne_+}qC0jmIcFij(I6
z)NOD+s~3Rtai9X}<*pBy{B$&~VZzTde(i!MS<Q^0+OoB{AMv+&j{;&$fBt85;ksj2
zTryGb-Q~jdY@Dy79y#5X3aDm&PEHSbq(196CO>?d_d_9aAKU_m=YaIEZQC|<vh;u9
z=s!(xz;);w#=wc41T3QphifB!`d*eqNM=&VU+1{<KYjWmKi`Z^8QZXGVI&6$z&D3$
zL@Ou~zAN3lTk6&W9^{hwSM|bnxW{rhE(GQz5aZ0{3s3~cA9%K->labaqFK2VCF#@r
z0^*OY&_#S5mFNY0SBvA#&X+n0P1&^3TqcJjePZmlFR!@Rl1;<YjV65aQSS2-KhgfV
zV(w^y`>B&94rH|r%8N4%=5^>VwrSP0UZ^1N?zJk0mN;B>;m->9yh8r5yx;j%Ouk?`
zY{T7#UX#PwNAztBl^2JaXBxU^&t;T0^2V(<ts?CK(wNB)P(7P=A<r%}^IR^!>W)XL
zPS!UKMMpL&T-_xM?=Z4q2C&NJ>^<5QI7VC2IN~)Po#&vVa;=*<E0;ApRn_;+vc>c5
zYrBUH?bT^XO*bcA@7zdQb4EB6V5!liy$JPlhXZ;okfTQDQXAcxGU+e$?)X(YZBAOb
z_f*J{F5|8dA*F`HGZt4a;WolkblZCr-1Jo6U6M?-hD|99z|^ss^1yW)5HIFG$0ekc
z`Bj>mnuZ{AkWqT_?&*i2f`KI0sPD3mD66ZhuU-vY3X;GJPTn;$q+257IyJ=ViwG&m
z@8ojn7hb9CJ$fv!?eSGb5DbwIg<*<xqH$)K+o=)<FC<&uK9-l0lS8M|Z{7NE$e{#~
z6bGF^#Dxy()sUwjgZuXW(T~CAF3>nkroF4HkMc8-NEE+*znt)Gh<Rob>qXxLPF|_5
zS@WfWJeq-2n_S^rATPpar-+Rpl2;&LA}uXP>-4XHXoF;F5N#Nxt5&Uo6~F6odjI~0
zf%by+@z2M1ZAv<TN)K1BUi}W>Xew1^Z4<E-<7kZ;d1F?y;?>8swY5m2Y&DA0u(U8Y
zFU<GE$82rmXq4+#XJt}JKN+Pmvx|$1i;74*j|-<d#A0#gPKuEYe{hi8T-UmM?$e$z
z#JQ~2bqhj~MqEXsNg}9Pi6Mg}4L9m<&EAB41TlG_3ON({hK4I*_E9JlM@L87fiH`_
z{HRnaN}=~xl>#Y)r`OWb!v3_oyE_`d<i|Ahz_CY9fD4SAEX?gv9i`~{mKGqZ;xfsi
zWVie8aOb?dJcI*SELKNH;Drcfi*#=sGVEDuKKcl`T*7gN>Pm&~2f-d;;xBT0O`5Xz
zMAeSP_$-EvZf}QuB6imt=@F7~W~Mibuuas-9F6+3Tj^Ylg^^MTS5^ZI4tYehY4F|s
zK8CBbl=e0snJ_a01+z0Vn$|PTGI28?BDN>m!z`%vU)zTvAb2?oaEr}JGf$Li?*ZtI
zbNJY=r-~b>)#HuY@X!wX>^ao>^1K1kXJ|uZtmL_JtTKW}a@VnZMj|DfNs`N}c|Ni!
zpZ)vxk-*l7kB^5PI&Uz|9*GDN474-YI;^r0x=iZmQ?o7Oa6$fQdwU@PiKWqI9~d>3
z4eid>-?>wghbjQwQ5pb3Dnv}(&l+OWn7Z5BJ39viq3Eriu?or&;K7jJVmbS+xpp|9
z*x&uNS?qoA!qR<eL&)R@0PSTQmNlT|Y1=LxKIr;R{}-w#iuzkdhVw(uc3^^C1^M>j
z@8@dx7XJ(M>>u<uGRD6&?t0DT`kd-u(xrkZ_0T_V-CCy}N9P0OhMuOG*Ksc2jEs!b
z3+rAKXDJQFKz;uFxjR~*U0iLTwuJs%*T7~1)!GIy$iUFLaNz>>KrE(8;%Wv?6su@x
z$h!J0%5RPlUHzcET=qeU{<hRDnvyke)4yrDcZ21-&d#dpO^njonf785tL&BcI57&C
zR0%Wp_8(U~(k!Q6*kU<4S^mROgH$nLsxj~NBF3V31Pyy#y!aciU2hvK0*4+lPo6w!
zG4=Kwca|eWD|To9>dkVM&ER<JY>KfPYpOUxP_SdTBF90evy9DT21x`=`mY8~;9Mm0
zOk#ByB+&!$&-wY<&7Q4BYZ{KObekTCm@-_`P~z>Fpvfw;w|IA1t<~tuIw*lIkRBc~
zT^yaAC4-i_FxXLMlDgYZG;~uKL!6o&@!yL-VqNZDN)6^E*@L*sZR(p~*nY2-hyesh
zbFGj=p(FD@ASj6I$I#8C6x-^?f8WMrasg%y>bl%;x12M>5!S+vAGWcPjHl4Wvvk=k
zGM6SmHz#W)zN-zV&4xKM6%`e!f&y1IRVJZ}>h+`_eWV|=qtsPauQp{55h>&vGq0m8
zM30v?H8pLqG=cHN^_{2^K@caTZv%Q3g8*}31oSOtfJ8bwBEwyS#_E;0!96j<7pt^U
zsYdkvDiVr1b_%;DZtI0(?)DQRzu(gi(oH(U*Mp+U&i<y=h^^Sr&>$PvlfBt_9;3nD
zb+(gPrO3n8BSs%9Ql}ZNwZfW_aD3hH>{(ZzyFscmEzmU9UnUV!`*v_c+6!C)dSZ;X
z_zczeavFmN@^Wh@GDf<{tv1N(x=*oE59y7^f<QDkoh$x`H&82+jIhdfZrwU|AFxzR
z_3>m~M+@m#TwH7{0L|_p$9aC!h>Z%lRN2*~79t!x`%uL%q7Y4JXmAzp8^VXcEzFu}
z%O$Qw<vVgcFI}SXi)dGNXCK*|G>n3SaS?V*0d2U7pD_~F=N!Zqq&9~=+qsUxx|}Y?
z%V_f+=StYzFPAPY#sb;@{_$0qGC<SWXo_?MuLbbKZtzB7se$~KiON`{S*T28Tt)ce
z)=^6}4r?KEb?}eE!fMF+TESf(Z>04STZfG{ubP{=LELbAmk=J&{gut(TUIXgepkwi
z9CXY+Vgm9v);QD->e^rWZje($(V&XQ4r$#VPX(H>6S=^>y}je>aViPqHSn$*&l^Ch
zRyvU`Uc49@O5}suT1@v&PEL+*2UW1vzpp7#I*A36_)pknfYrp=PuE;Yxd&4?Ha6zp
zWV&Jb^^0j!n1M4~nS^T}xGpPn00>lLQkU}L`IkIBXJ%%Iv7R|xV=>QIn^{^2YZn0c
z&_F@4OF3!Hy#Rg(P_<yC0GNX>hTfK(^Ym;Cw>Hb*0N!>x#pU#=Q=1s$A$=L;L}O}$
zY@;Wdc8u%?chV<fBAuA?jHMimbqJ@w*v3f1=2ZIkp%+wDRJQwY)RshjYi%YIPY|=K
za(c3eO$*Y#@rKLQSfHSyq5`c5#u2qj<%FxN41>AfFl+kdxbDwk78)`82-6Ldeq<vV
z9zh_PteN<tL7g&~aBvI3J5hZ&{x2*+^=C`&H<@XxE!h$4j}(fC9#yU{#WJ@(%2M17
zMDo9~vv(zE1`UP*WsS2S`T3pz))6yPhk=1dYck^lzy#_wv&fl-M}%4B#h`ovCW3R=
zSUo9Guj2hr4H{JQ6h=n!sv4|qK@2KZ(Ro)N+iiAJzUGk@|9x-lj$vhG<={G1&OKC=
z00bNUKwv-sWF;m!R-Git_jUTHOyM{6&YfoCf|U|CJGp(je&qs%Ep+jC(!6LSvLnID
z7th(z*0%9RX~@J!G~wIC7hq!nU<3rQ!qvx(jg9z140O43Wghmq_vN%87cHw98SkBM
z-->oWTXezQ-4b@*G`2@L+cPF|<cud11Q-I$H#q2Z=@K7KM~pG2B0>^+;)HB?L`ph;
z{&(04^*Gni{@YZUkV>b@P)d<WZ4aoasew{L4dk)7X4Af#P%u8>e4JF9fRI|WXi=Fr
z9mb$AFK=4hXQ@Y|<hJ(q{@&c@FPkLH*fE@kiTp4oI$`fDcwrkc{y=RFr1%?1aUhq|
zdQ2c25;XJjJ0Unez0OXW1I@TVK_2eF@Z$G3ZY(sG%pB^u@G|a~UluP}a_3my(y;e)
zv&6j{WFPdT>rm<4$f)AD2L?FV*;QTH(8e(R6#`#X#*I)#xp(eh?)8%vqUZBN-%N7P
z8@y|4LswtHU^`o4Vqoy*?b}a*J9nzv`uk5{cBQy`$^%5Xav`832NPB<i2^|wqyMmd
zPS?bK>>WS72Dt>CnAO}j7JMx#YNSTUA*zd@A5h{VC#Np_G<uep*}IV3nxNUvWYQ9=
zRaI4&s+(6Bd<<zp35<OEngQ`dGXT4hySo)FMZ4B6`*~kZett(sM^((-q9S!=WnZ-o
z@!vlvE2|1G#+d}K?X*&3ue1vmS*|2MM@Lqp7X3G3uwur}lmGEp9$Cl^ii?SH#?H+<
zuPK;R7&*|E+Kh(w{JFwRW?QX0>g+tEwF#ruH1_^@a%7LmSa9{-yWW*AQV)G3&yxcO
z3*O!O_3Me8VjPyZ<Izc%u;^^8c&Ld)nu)+G{gYQX8f>l}ms?bHI6;%nbv=IEUo_gC
zln&$7a?wa7=0HNPI$vqITo=p$EQt?=#oF%O`2f?vYTcNqCk{+uAc-h<JRl{8X86Uj
zep~9yr<^!2KW)Q4tVrMP9SZXg(#RB0^5@T-$u211!;C*Tql^YxVx^p!o%KeDQY{QA
z(gFnIC8Dt&EY~A@mhNnWQo&UDt5g%*=P$u|nnwV*FB;8c3ak4dXhJ4i_S-VP)?Dy}
zaRn#7pLDexH&$#L+K<~O?a3z{%bQg=1(=nEp;F`ZeK|}Q$`BFbIa7BHT9g|uln~3j
zDra;)t1QL;%-4G_8@i^jhD}iCO7X-Au!G+HXp!@_tmfum!NwcjEYi)gu)&pk;VNmn
ze$WzCc?VG)R(ECu!jVQ`V8gAJi(u+~`t%7)(QrjitW3(4%~~tg>;J-Aas#JEejnI=
z3M9`o@vV5x7cs91mmlC6B!O2GhR5B5=2Jnj>WZ!}EliAMH$J%So)x8?E<QUxD~X`X
z5P_oMFZ&BafUj)UF01HGI7q;ZGN{t&*q+I$De0&EmZ!1BXQbk6@$gFG@{*I8Mfv%s
zlLJm0Jd`VjvI%8V+^UL3SmiztMP=T_VRgC;zZD<sBRX_7YLjA4hwQRWnB2YP4<dz<
zk*td|^^DiAkHF8kwGr#(_nOO5d8EX9$ExU^;Bj0#qh{i}cKP)O4;~m98CAnyc-c1r
z7YZ&Je`v_t!(*$>MCYaAnt}WRX@8dVi%-ads|gM8_xI1UyRk24_~%ELTqe>wI!-z>
z^=N~on1Ao_HVJLy1Hs?jeJ1FD(8JUSo@m>3x%c1dEL(s*O}owY$E<In+<Q`h?&i&#
z5&c=QypiWu;$UuQFGG%isxgUta8Ff+s5$JTVX_<CmzX$YWIy%V&L0a-PH7SZo8x<!
z5~N2f;u-+JaTTYg&~srpUc9g_uZw?iUjE1LC=^;lk9BS<lrTzCAUdYK=&n`H(IE2b
zjY$W1ejz-gSFPyS0qh+G&bq_1#ZzOpW>KyrM<w=*1p~pnaiyPZ^^z!XK+?UGud#Yt
z9kx#Jp^V{K;h~vcZ|`O2=Jw^~W|{?${)<xbsVbAf17Yf0YfoeW`o6!ynhTCy_K}Oc
znO82w<)x*5)6XFO9BbVL9|&&<bk=q*mx|?ZYI4%f-kw#)hPTqv(%n=iji!sDvCbas
z%c4dgexXg`O@x%kFjO((YD{~!n<gFDyDq-<;dwz@o1M8jf;VQEMOdlT8m1A%l5~{U
z3SMXL8IH_4q*VatX7gsG`)gVc*C;tN*{rMD#wTEOBIe7JobAeQKGMjA=SRfE;BKBP
zc?-#Od~=eyy6y4fiH^6>twd>{2NdIdI7_EPtm(F28(&`Vt6ODNm08k(%CF9$pAME*
zb>%%8=JjwM`syXa6ON;bd(eegg3zg4OeP9vLftskW*HDF8?@%o{|ELLwOYPhytrb`
zQ-Zq+yDJQ>X^7LX)m)zJ77!SicE{Af;MkUw*8a(tFJFFqm5wM-))Sl$%?RT3A0FMd
z_*`gcRb}O=WL}J_aco?io{r9McT7!9^EMs`3JTInT)ldAyjvxmPK8{I-2M3OwYHX)
z%g<Il-@z}ukID?IqU&`SDr?q&B1Z6{Ow`m>RNfffwcCs)IR$q|lH}g2*CN(n(+cz>
z*%__Ev#4(OGGPyyoWUgtb<$P%yVrKdjVs}}!J9__585$#DRFzCejyOCnj?CquS`yN
z(pd$cBPCtD&T#QL%v;RF3e+*+z~AxVRGX^Al$DnsOdyLzV}6x4UtNIGZ!+yuJC#hV
z>Ff8$Y9?AUN@F!FhnIYk2e*?<20EU@;qbIH%!6Nhk4JO=fM6SeE^NJHLmgA1UVc1J
zse<vLiror2xT5dzaI_HS-pJC@($Mf++Q*kKe<|W4e)wIU9R`gbU%s-{Q<tHlt`3Nw
zZ@TzH`ftCz#j{|2#n6GYXMYugP9A2{jMHCrmW3lCgT)VjF!4{EAV_uUwOD&0I-4&O
z%{_0hx_l6|yZm}ar>Cc#wg`7WYg(#dag)Jo!r;Q#yo>pkdT3uV532E<TZ%KeWiLbp
z>AN>?-h7BKnTue^G`#%bRjC>2>2nc!!~4RrsuMIPCb8mZ%#Hz{v^$Rc)sS;wrQ;0Y
z6nsinTbq%YnM!p1VMfbW3f<q@bj=C=q5#+p<Po6ZKGkE-pfsX@d&<#}T+~+<BWB@C
z+&l1{8=^$$4Ae1@#K}ZUotcObNq>ZxA&&?)1=n!k?4eu}Bu-~p4Ppjyh<sRN6(i(@
zC<J^z4TuP3We9~nj7%t%5lB`cT_!>PIw9_#8P~S3+2PGQg-!wOC*0eVrw>4f_rse-
zf8k&>L^yV>#V7<25gd#)yUv(RKCZ9a1$|DH6wBIeyed$aSg*1-f!M?-FAwtdMRu=*
zq?MSOnHeFQg)V1Z-i==%{EzTi1o&`TE9H<@aplLfAM`6o>?*t{AXhFy3Bf56s&Ylo
zAZQ4(iAB~3VJ#3qLpzB03qZ%jace|&Om+7nR!Wor`*E(~W^L^h{sHH3K|7*T7`h^?
z@7}B_$W-dIo@{S2Przql(8~thEwO5_A6~MzwQZge@PCxd3JE_L@sQb$B4<Z?`@WO!
zs!+9wGkM1tt)z=$LUH7iaEF4-3TK~3D!GWNm^DQXIz*)vfK(&s+?Wtz?*W6#9CGBv
z`8Thw(y?S-Nli^9>?5&WqXq@Hy`8r`q^~Ih?IR_+h6w}$C^#s7lQ5BQiG!M|Dy5mi
zxsMn%v_AaN9f)>z!V|^~-?p~)tTGK2bw?2~F<SgvLie>A!Buajit02h5Iexaf{Gzi
z!|Vc&PE6_T=}_3*nf)UUl}=Lh-_U$@tcU1bXmMiXB76bBH+$Q6=TFs&#~FCKJfbE^
z9Qao-u*7nO;0hwR5Do9Isgiuv+%Zx{B80S*k%YT#Z{Cz5$cZy{N)U7~he30%_*I6%
zh{9SvEH7_<`O@y>$;@#c5!APx7I9_leoj=%HJ=FnN4OnMct^Q>sr3G)8_SnOu}?2c
zb`wlaR>M0+c(tys4q^?O9;_~vm@0+`0<f6Y#JM8(_npR%f6!N3lEQE+Cs`v}OL)>3
zjRu6Xh`%4ao#5#I5eRI-vlvxC<F}+BkQfg04k)o$Tz$s_6Ug2*JOENO_1-e&_a?Eb
zMHRBi=`c)c_*X|ZVs&#x@dKDo`0I-m<gZ&jxqMS9l_L75JN(^y@W<`#?Gc|ty`o<a
z=b|1r%)MUC<eS!rLA8d;!BPgY%uk$1%FmD7{Y~NvOi6gveF4Q3XK=<q^$s8e3C|Bz
z?RfB+;ivm5-5lue$G(7YR&w1+-T^j%h<&s^T!wcRc#s#IQs`KYnGrBte`{kS27(J-
z2`yTI+1B=ZYya622S-N=Yy*bTi_$@h5A)3-nYGiq;J$sx-R_YFtiqG-QNL(-bg-&G
zo$|DtzFruKC<}D&5Jmz%PRcx_x!e>kH8Jt`9zAgT4Hg7E794IEV}sN~B@TrJ1vCs0
zgo$k#Nnc;L!b55$T5B#(&_s>^BrdM<5KR~hc4~cqMM%4-;@189t$e{rJG<aRbA&WG
zIfZ^}t6g?Aobv{G8ykV}DXyLI+<SDsqM|XHWpA&vKmk)%mjNf>@eiY2{>?R?ZbeH!
ziCRa5?)Og#Zy;bAHgw6A7BX>xRR)hthXLgh+?vi=8MBXFzXFW}yX4|ULZc#{P@R^h
z(s21sZtgalOP4ND5PPaLXL6m}7GuW(Lmw{}oN#!a`T3a$li@pX8lVv?oth-ActuLC
zVPmi~^`3G+-5VrAO5-cnw$z8KzZq?*(+krsRw!VSLWMMLIN-?@2jAQ@U0esTO03*+
zBCp%WUJUtVl+5jA%$gFlN1Ch|&Ta;&SZHGQWo2~ttn$FwRB%8^EeVFHtT;s5E-N+5
zcTK7j{OYR1(+Ouwegi&!uc_|UM*49)*zIH8zQJzGD=9~oU$??=zwfUK32KlUmZ_EH
zg1gy-n|hQT+MIMiD-o}NWFWEjVj<$x+}_*Tr2h-74>m<uELzv`mps4gR_oN3STYy7
zHgkKGaB(LGhtXLHyb02j`Fj@;wq;3|byMJ4P4)QO1UB|fz>M`x+%-QZGa)g%zFfo>
z-m}|`m{s~6)UYe{E5`UU%P7jrJ0(?UHS#8ra6^>J?9(`k<^T{&D9YTRN+%Zw2j7X|
zt~2txmL)?C^5(@`DG5V<mU}M@csBp@ZlC-*IZ;i<SJTTsZ~m>VHnEcXYab9<IBVC*
z5qrGEHn07%ujIsY%+;GcoXWrd{7n~=tzU?Q?XBgg(R<>=-o=0Yp6`6W6w{#VTZSi0
zdJa6vdZEMcOF8@1=gXvQjF;E^yaV^2m*1-R-QSnp^>mHgpLfN!?Yyt%T>0Fd>Ysj=
z`{y(Ny_x@P@GX%0>$VErUt9hA{-*r@lgsZNReVBIXKnfCd8Q{6pDeWuj_Wb`=hdZD
z@;I_iLHa*Ersu9rkv$9$4D@p}K6msosnf|RX?oh}y7)gT=Kehb^lUc>q-%cPK^3g{
zO78D|WxT#mk)0)uqy9N)s?B%WkGLL^U-kDZPVeiNL|Z@lJfcQR$IWY~TfcDl`|Y00
zqzm=5<}CW_=T8_7BZL3`af30+l(b$G$2b1GUhs=q2}PEabmHHh=U!*k9iBAY*?G@K
zr!gm4VPT=Xl$th?+pyb9v{p_|ZV7p>1Noefx3?RKEEgPfKET^Ic3!^(KlzsU$@w#6
zH?wnoZum#eK!2-&uKsr2tp;`mTg?oN%(fcq>KmEq>rYngeE1)~;O%qX<3h-P|AolD
S$S?2<a@KnfTNNQ2<Np9+$Gc4c

literal 0
HcmV?d00001

diff --git a/doc/design/assistant/blog/day_80__default_backend.mdwn b/doc/design/assistant/blog/day_80__default_backend.mdwn
new file mode 100644
index 0000000000..5b6aa7f981
--- /dev/null
+++ b/doc/design/assistant/blog/day_80__default_backend.mdwn
@@ -0,0 +1,14 @@
+I've changed the default backend used by git-annex from SHA256 to SHA256E.
+Including the filename extension in the key is known to make repositories
+more usable on things like MP3 players, and I've recently learned it also
+avoids [[forum/Weird_behavior_with_OS_X_Finder_and_Preview.app]]. 
+
+I thought about only changing the default in repositories set up by the
+assistant, but it seemed simpler to change the main default. The old
+backend is really only better if you might have multiple copies of files
+with the same content that have different extensions.
+
+Fixed the socket leak in pairing that eluded me earlier.
+
+I've made a new [[polls]] page, and posted a poll:
+[[polls/prioritizing_special_remotes]]
diff --git a/doc/design/assistant/blog/day_81__enabling_pre-existing_special_remotes.mdwn b/doc/design/assistant/blog/day_81__enabling_pre-existing_special_remotes.mdwn
new file mode 100644
index 0000000000..45a7e9f20b
--- /dev/null
+++ b/doc/design/assistant/blog/day_81__enabling_pre-existing_special_remotes.mdwn
@@ -0,0 +1,34 @@
+It's possible for one git annex repository to configure a special remote
+that it makes sense for other repositories to also be able to use. Today I
+added the UI to support that; in the list of repositories, such
+repositories have a "enable" link.
+
+To enable pre-existing rsync special remotes, the webapp has to do the same
+probing and ssh key setup that it does when initially creating them.
+Rsync.net is also handled as a special case in that code. There was one
+ugly part to this.. When a rsync remote is configured in the webapp,
+it uses a mangled hostname like "git-annex-example.com-user", to
+make ssh use the key it sets up. That gets stored in the `remote.log`, and so
+the enabling code has to unmangle it to get back to the real hostname.
+
+---
+
+Based on the still-running [[prioritizing_special_remotes]] poll, a lot
+of people want special remote support for their phone or mp3 player.
+(As opposed to running git-annex on an Android phone, which comes later..)
+It'd be easy enough to make the webapp set up a directory special remote
+on such a device, but that makes consuming some types of content on the
+phone difficult (mp3 players seem to handle them ok based on what people tell
+me). I need to think more about some of the ideas mentioned in [[android]]
+for more suitable ways of storing files.
+
+One thing's for sure: You won't want the assistant to sync all your files
+to your phone! So I also need to start coming up with partial syncing
+controls. One idea is for each remote to have a configurable matcher for files
+it likes to receive. That could be only mp3 files, or all files inside a
+given subdirectory, or all files *not* in a given subdirectory. That means
+that when the assistant detects a file has been moved, it'll need to add
+(or remove) a queued transfer. Lots of other things could be matched on,
+like file size, number of copies, etc. Oh look, I have a
+[beautiful library I wrote earlier](http://joeyh.name/blog/entry/happy_haskell_hacker)
+that I can reuse!
diff --git a/doc/design/assistant/blog/day_82__git-annex_branch_work.mdwn b/doc/design/assistant/blog/day_82__git-annex_branch_work.mdwn
new file mode 100644
index 0000000000..ed2e4e6029
--- /dev/null
+++ b/doc/design/assistant/blog/day_82__git-annex_branch_work.mdwn
@@ -0,0 +1,26 @@
+Started today doing testing of [[syncing]], and found some bugs and things
+it needs to do better. But was quickly sidetracked when I noticed that
+`transferkey` was making a commit to the git-annex branch for every file it
+transferred, which is too slow and bloats history too much.
+
+To fix that actually involved fixing a long-standing annoyance; that
+read-only git-annex commands like `whereis` sometimes start off with
+"(Recording state in git)", when the journal contains some not yet
+committed changes to the git-annex branch. I had to carefully think
+through the cases to avoid those commits.
+
+As I was working on that, I found a real nasty lurking bug in the git-annex
+branch handling. It's unlikely to happen unless `annex.autocommit=false` is
+set, but it could occur when two git-annex processes race one another just
+right too. The root of the bug is that `git cat-file --batch` does not
+always show changes made to the index after it started. I think it does
+in enough cases to have tricked me before, but in general it can't be
+trusted to report the current state of the index, but only some past state.
+
+I was able to fix the bug, by ensuring that changes being made to the
+branch are always visible in either the journal or the branch -- never in
+the index alone.
+
+----
+
+Hopefully something less low-level tomorrow..!
diff --git a/doc/design/assistant/blog/day_83__3-way.mdwn b/doc/design/assistant/blog/day_83__3-way.mdwn
new file mode 100644
index 0000000000..9411c4c1c2
--- /dev/null
+++ b/doc/design/assistant/blog/day_83__3-way.mdwn
@@ -0,0 +1,73 @@
+Syncing works well when the graph of repositories is strongly connected.
+Now I'm working on making it work reliably with less connected graphs.
+
+I've been focusing on and testing a doubly-connected list of repositories,
+such as: `A <-> B <-> C`
+
+----
+
+I was seeing a lot of git-annex branch push failures occuring in
+this line of repositories topology. Sometimes was is able to recover from
+these, but when two repositories were trying to push to one-another at the
+same time, and both failed, both would pull and merge, which actually keeps
+the git-annex branch still diverged. (The two merge commits differ.)
+
+A large part of the problem was that it pushed directly into the git-annex
+branch on the remote; the same branch the remote modifies. I changed it to
+push to `synced/git-annex` on the remote, which avoids most push failures.
+Only when A and C are both trying to push into `B/synced/git-annex` at the
+same time would one fail, and need to pull, merge, and retry.
+
+-----
+
+With that change, git syncing always succeeded in my tests, and without
+needing any retries. But with more complex sets of repositories, or more
+traffic, it could still fail.
+
+I want to avoid repeated retries, exponential backoffs, and that kind of
+thing. It'd probably be good enough, but I'm not happy with it because
+it could take arbitrarily long to get git in sync.
+
+I've settled on letting it retry once to push to the synced/git-annex
+and synced/master branches. If the retry fails, it enters a fallback mode,
+which is guaranteed to succeed, as long as the remote is accessible.
+
+The problem with the fallback mode is it uses really ugly branch names.
+Which is why Joachim Breitner and I originally decided on making `git annex
+sync` use the single `synced/master` branch, despite the potential for
+failed syncs. But in the assistant, the requirements are different,
+and I'm ok with the uglier names.
+
+It does seem to make sense to only use the uglier names as a fallback,
+rather than by default. This preserves compatability with `git annex sync`,
+and it allows the assistant to delete fallback sync branches after it's
+merged them, so the ugliness is temporary.
+
+---
+
+Also worked some today on a bug that prevents C from receiving files
+added to A.
+
+The problem is that file contents and git metadata sync independantly. So C
+will probably receive the git metadata from B before B has finished
+downloading the file from A. C would normally queue a download of the
+content when it sees the file appear, but at this point it has nowhere to
+get it from.
+
+My first stab at this was a failure. I made each download of a file result
+in uploads of the file being queued to every remote that doesn't have it
+yet. So rather than C downloading from B, B uploads to C. Which works fine,
+but then C sees this download from B has finished, and proceeds to try to
+re-upload to B. Which rejects it, but notices that this download has
+finished, so re-uploads it to C...
+
+The problem with that approach is that I don't have an event when a download
+succeeds, just an event when a download ends.  Of course, C could skip
+uploading back to the same place it just downloaded from, but loops are
+still possible with other network topologies (ie, if D is connected to both
+B and C, there would be an upload loop 'B -> C -> D -> B`). So unless I can
+find a better event to hook into, this idea is doomed.
+
+I do have another idea to fix the same problem. C could certainly remember
+that it saw a file and didn't know where to get the content from, and then
+when it receives a git push of a git-annex branch, try again.
diff --git a/doc/design/assistant/blog/day_84__deferred_downloads.mdwn b/doc/design/assistant/blog/day_84__deferred_downloads.mdwn
new file mode 100644
index 0000000000..0ae684e476
--- /dev/null
+++ b/doc/design/assistant/blog/day_84__deferred_downloads.mdwn
@@ -0,0 +1,33 @@
+Implemented deferred downloads. So my example from yesterday of three
+repositories in a line keep fully in sync now!
+
+I punted on one problem while doing it. It might be possible to get a really
+big list of deferred downloads in some situation. That all lives in memory.
+I aim for git-annex to always have a constant upper bound on memory use,
+so that's not really acceptable. I have TODOed a reminder to do something
+about limiting the size of this list.
+
+----
+
+I also ran into a nasty crash while implementing this, where two threads
+were trying to do things to git HEAD at the same time, and so one crashed,
+and in a way I don't entirely understand, that crash took down another
+thread with a BlockedIndefinitelyOnSTM exception. I think I've fixed
+this, but it's bothersome that this is the second time that modifications
+to the Merger thread have led to a concurrency related crash that I
+have not fully understood. 
+
+My guess is that STM can get confused when it's
+retrying, and the thread that was preventing it from completing a
+transaction crashes, because it suddenly does not see any other
+references to the TVar(s) involved in the transaction. Any GHC STM gurus
+out there?
+
+---
+
+Still work to be done on making data transfers to keep fully in sync in all
+circumstances. One case I've realized needs work occurs when a USB drive is
+plugged in. Files are downloaded from it to keep the repo in sync, but the
+repo neglects to queue uploads of those files it just got out to other
+repositories it's in contact with. Seems I still need to do something to
+detecting when a successful download is done, and queue uploads.
diff --git a/doc/design/assistant/blog/day_85__more_foundation_work.mdwn b/doc/design/assistant/blog/day_85__more_foundation_work.mdwn
new file mode 100644
index 0000000000..25bad37488
--- /dev/null
+++ b/doc/design/assistant/blog/day_85__more_foundation_work.mdwn
@@ -0,0 +1,17 @@
+Turns out I was able to easily avoid the potential upload loops that would
+occur if each time a repo receives a download, it queues uploads to the
+repos it's connected to. With that done. I suspect, but have not proven,
+that the assistant is able to keep repos arranged in any shape of graph in
+sync, as long as it's connected (of course) and each connection is
+bi-directional. That's a good start .. or at least a nice improvement from
+only strongly connected graphs being kept in sync.
+
+Eliminated some empty commits that would be made sometimes, which is a nice
+optimisation.
+
+------
+
+I wanted to get back to some UI work after this week's deep dive into the
+internals. So I filled in a missing piece, the repository switcher in the
+upper right corner. Now the webapp's UI allows setting up different
+repositories for different purposes, and switching between them.
diff --git a/doc/design/assistant/blog/day_86__towards_the_beta.mdwn b/doc/design/assistant/blog/day_86__towards_the_beta.mdwn
new file mode 100644
index 0000000000..b11dd9bf90
--- /dev/null
+++ b/doc/design/assistant/blog/day_86__towards_the_beta.mdwn
@@ -0,0 +1,33 @@
+Putting together a shortlist of things I want to sort out before the beta.
+
+* [[Progress bars|progressbars]] for file uploads.
+* No mocked up parts in the webapp's UI. Think I implemented the last of
+  those yesterday, although there are some unlinked repository configuration
+  options.
+* The basic watching functionality, should work reliably.
+  There are some known scalability issues with eg,
+  [[kqueue on OSX|bugs/Issue_on_OSX_with_some_system_limits]] that
+  need to be dealt with, but needn't block a beta.
+* Should keep any configuration of repositories that can be set up using
+  the webapp in sync whenever it's possible to do so. I think that'll work
+  after the past few days work.
+* Should be easy to install and get running. Of course part of the point
+  of the beta release is to get it out there, on Hackage, in Debian
+  unstable, and in the other places that git-annex packagers put it.
+  As to getting it running, the autostart files and menu items look good
+  on Linux. The OSX equivilants still need work and testing.
+* No howlingly bad bugs. [[This bug|bugs/pasting_into_annex_on_OSX]] is
+  the one I'm most concerned with currently. OTOH, 
+  [[bugs/watcher_commits_unlocked_files]] can be listed in the errata.
+
+----
+
+So I worked on progress bars for uploads today. Wrote a nice little
+parser for rsync's progress output, that parses arbitrary size chunks,
+returning any unparsable part. Added a ProgressCallback parameter to
+all the backends' upload methods. Wrote a nasty thing that intercepts
+rsync's output, currently a character at a time (horrible, but rsync
+doesn't output that much, so surprisingly acceptable), and outputs it and
+parses it. Hooked all this up, and got it working for uploads to
+git remotes. That's 1/10th of the total ways uploads can happen that
+have working progress bars. It'll take a while to fill in the rest..
diff --git a/doc/design/assistant/blog/day_87__more_progress_progress.mdwn b/doc/design/assistant/blog/day_87__more_progress_progress.mdwn
new file mode 100644
index 0000000000..c2b266d6d9
--- /dev/null
+++ b/doc/design/assistant/blog/day_87__more_progress_progress.mdwn
@@ -0,0 +1,28 @@
+Worked more on upload progress tracking. I'm fairly happy with its state
+now:
+
+* It's fully implemented for rsync special remotes.
+
+* Git remotes also fully support it, with the
+  notable exception of file uploads run by `git-annex-shell recvkey`. That
+  runs `rsync --server --sender`, and in that mode, rsync refuses to output
+  progress info. Not sure what to do about this case. Maybe I should
+  write a parser for the rsync wire protocol that can tell what chunk of the
+  file is being sent, and shim it in front of the rsync server? That's
+  rather hardcore, but it seems the best of a bad grab bag of options that
+  include things like `LD_PRELOAD` hacks.
+
+* Also optimised the rsync progress bar reader to read whole
+  chunks of data rather than one byte at a time.
+
+* Also got progress bars to actually update in the webapp for uploads.
+
+  This turned out to be tricky because kqueue cannot be used to detect when
+  existing files have been modified. (One of kqueue's worst shortcomings vs
+  inotify.) Currently on kqueue systems it has to poll.
+
+I will probably upload add progress tracking to the directory special remote,
+which should be very easy (it already implements its own progress bars),
+and leave the other special remotes for later. I can add upload progress
+tracking to each special remote when I add support for configuring it in
+the webapp.
diff --git a/doc/design/assistant/blog/day_88__progressbars_still_progressing.mdwn b/doc/design/assistant/blog/day_88__progressbars_still_progressing.mdwn
new file mode 100644
index 0000000000..cd3c493c15
--- /dev/null
+++ b/doc/design/assistant/blog/day_88__progressbars_still_progressing.mdwn
@@ -0,0 +1,18 @@
+Short day today, but I again worked only on progress bars.
+
+* Added upload progress tracking for the directory special remote.
+* Some optimisations.
+* Added a `git annex-shell transferkey` command. This isn't used yet,
+  but the plan is to use it to feed back information about how much
+  of a file has been sent when downloading it. So that the uploader
+  can display a progress bar. This method avoids needing to parse the rsync
+  protocol, which is approximately impossible without copying half of rsync.
+  Happily, git-annex's automatic ssh connection caching will make the small
+  amount of data this needs to send be efficiently pipelined over the same
+  ssh connection that rsync is using.
+
+I probably have less than 10 lines of code to write to finish up
+[[progressbars]] for now. Looking forward to getting that behind me, and on
+to something more interesting. Even doing mail merge to print labels to
+mail out Kickstarter rewards is more interesting than progress bars at this
+point. :)
diff --git a/doc/design/assistant/blog/day_89__final_polish.mdwn b/doc/design/assistant/blog/day_89__final_polish.mdwn
new file mode 100644
index 0000000000..4a72a7ff23
--- /dev/null
+++ b/doc/design/assistant/blog/day_89__final_polish.mdwn
@@ -0,0 +1,24 @@
+Finally wrapped up progress bars; upload progress is now reported in all
+situations. 
+
+After all that, I was pleased to find a use for the progress info, beyond
+displaying it to the user. Now the assistant uses it to decide whether it
+makes sense to immediately retry a failed transfer. This should make it
+work nicely, or at least better, with flaky network or drives.
+
+The webapp crashed on startup when there was no `~/.gitconfig`.
+Guess all of us who have tried it so far are actual git users,
+but I'm glad I caught this before releasing the beta.
+
+Jimmy Tang kindly took on making a OS X .app directory for git-annex.
+So it now has an icon that will launch the webapp. 
+[[!img /assistant/osx-app.png]]
+
+I'm getting lots of contributors to git-annex all of a sudden. I've had 3
+patches this weekend, and 2 of them have been to Haskell code.
+Justin Azoff is working on [[todo/incremental_fsck]], and Robie Basak
+has [gotten Amazon Glacier working](https://github.com/basak/glacier-cli)
+using the hook special remote.
+
+Started doing some design for [[transfer_control]]. I will start
+work on this after releasing the first beta.
diff --git a/doc/design/assistant/blog/day_8__speed.mdwn b/doc/design/assistant/blog/day_8__speed.mdwn
new file mode 100644
index 0000000000..d99add97a7
--- /dev/null
+++ b/doc/design/assistant/blog/day_8__speed.mdwn
@@ -0,0 +1,67 @@
+Since last post, I've worked on speeding up `git annex watch`'s startup time
+in a large repository.
+
+The problem was that its initial scan was naively staging every symlink in
+the repository, even though most of them are, presumably, staged correctly
+already. This was done in case the user copied or moved some symlinks
+around while `git annex watch` was not running -- we want to notice and
+commit such changes at startup.
+
+Since I already had the `stat` info for the symlink, it can look at the
+`ctime` to see if the symlink was made recently, and only stage it if so.
+This sped up startup in my big repo from longer than I cared to wait (10+
+minutes, or half an hour while profiling) to a minute or so. Of course,
+inotify events are already serviced during startup, so making it scan
+quickly is really only important so people don't think it's a resource hog.
+First impressions are important. :)
+
+But what does "made recently" mean exactly? Well, my answer is possibly
+over engineered, but most of it is really groundwork for things I'll need
+later anyway. I added a new data structure for tracking the status of the
+daemon, which is periodically written to disk by another thread (thread #6!)
+to `.git/annex/daemon.status` Currently it looks like this; I anticipate
+adding lots more info as I move into the [[syncing]] stage:
+
+	lastRunning:1339610482.47928s
+	scanComplete:True
+
+So, only symlinks made after the daemon was last running need to be
+expensively staged on startup. Although, as RichiH pointed out,
+this fails if the clock is changed. But I have been planning to have a
+cleanup thread anyway, that will handle this, and other
+potential problems, so I think that's ok.
+
+Stracing its startup scan, it's fairly tight now. There are some repeated 
+`getcwd` syscalls that could be optimised out for a minor speedup.
+
+----
+
+Added the sanity check thread. Thread #7! It currently only does one sanity
+check per day, but the sanity check is a fairly lightweight job,
+so I may make it run more frequently. OTOH, it may never ever find a
+problem, so once per day seems a good compromise. 
+
+Currently it's only checking that all files in the tree are properly staged
+in git. I might make it `git annex fsck` later, but fscking the whole tree
+once per day is a bit much. Perhaps it should only fsck a few files per
+day? TBD
+
+Currently any problems found in the sanity check are just fixed and logged.
+It would be good to do something about getting problems that might indicate
+bugs fed back to me, in a privacy-respecting way. TBD
+
+----
+
+I also refactored the code, which was getting far too large to all be in
+one module. 
+
+I have been thinking about renaming `git annex watch` to `git annex assistant`,
+but I think I'll leave the command name as-is. Some users might
+want a simple watcher and stager, without the assistant's other features
+like syncing and the webapp. So the next stage of the
+[[roadmap|design/assistant]] will be a different command that also runs
+`watch`.
+
+At this point, I feel I'm done with the first phase of [[inotify]].
+It has a couple known bugs, but it's ready for brave beta testers to try.
+I trust it enough to be running it on my live data.
diff --git a/doc/design/assistant/blog/day_8__speed/comment_1_a3dba537b276d5737abc8cb93f1965f4._comment b/doc/design/assistant/blog/day_8__speed/comment_1_a3dba537b276d5737abc8cb93f1965f4._comment
new file mode 100644
index 0000000000..d0a207c82a
--- /dev/null
+++ b/doc/design/assistant/blog/day_8__speed/comment_1_a3dba537b276d5737abc8cb93f1965f4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="Battery usage"
+ date="2012-06-15T09:57:33Z"
+ content="""
+Complete fsck is good, but once a week probably enough.
+
+But please see if you can make fsck optional depending on if the machine is running on battery.
+"""]]
diff --git a/doc/design/assistant/blog/day_90__beta.mdwn b/doc/design/assistant/blog/day_90__beta.mdwn
new file mode 100644
index 0000000000..fc9bf4a41d
--- /dev/null
+++ b/doc/design/assistant/blog/day_90__beta.mdwn
@@ -0,0 +1,16 @@
+Just released git-annex 3.20120924, which includes beta versions of
+the assistant and webapp. Read the [[/assistant/errata]], then give it a
+try!
+
+I've uploaded it to Haskell's cabal, and to Debian unstable, and hope my
+helpers for other distributions will update them soon. (Although the
+additional dependencies to build the webapp may take a while on some.)
+I also hope something can be done to make a prebuilt version available on
+OSX soonish.
+
+I've decided to license the webapp under the
+[AGPL](http://www.gnu.org/licenses/agpl-3.0.html). This should not impact
+normal users of it, and git-annex can be built without the webapp as a pure
+GPL licensed program. This is just insurance to prevent someone turning the
+webapp into a propritary web-only service, by requiring that anyone who
+does so provide the source of the webapp.
diff --git a/doc/design/assistant/blog/day_90__beta/comment_1_5f2a3b18ad7558abe04f51534a29ff13._comment b/doc/design/assistant/blog/day_90__beta/comment_1_5f2a3b18ad7558abe04f51534a29ff13._comment
new file mode 100644
index 0000000000..6b95e317dd
--- /dev/null
+++ b/doc/design/assistant/blog/day_90__beta/comment_1_5f2a3b18ad7558abe04f51534a29ff13._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlJEI45rGczFAnuM7gRSj4C6s9AS9yPZDc"
+ nickname="Kevin"
+ subject="Haskell on MacPorts"
+ date="2012-09-24T21:09:39Z"
+ content="""
+FYI, I just came across a [MacPorts ticket](https://trac.macports.org/ticket/35813) to update Haskell to 2012.2.0.0.  It would be nice to install git-annex from MacPorts.
+
+"""]]
diff --git a/doc/design/assistant/blog/day_90__beta/comment_2_961c4eba97f4eac75174244d6b2b00c0._comment b/doc/design/assistant/blog/day_90__beta/comment_2_961c4eba97f4eac75174244d6b2b00c0._comment
new file mode 100644
index 0000000000..ed6c8e2aec
--- /dev/null
+++ b/doc/design/assistant/blog/day_90__beta/comment_2_961c4eba97f4eac75174244d6b2b00c0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2012-09-24T21:21:57Z"
+ content="""
+cool, I haven't been on top of things recently. If haskell-platform gets updated in macports and assuming its easy to package up any dependancies (if any) as macport packages, git-annex should be relatively straightforward to package up
+"""]]
diff --git a/doc/design/assistant/blog/day_90__beta/comment_3_c76675a4633cbbe347ed42c222918d38._comment b/doc/design/assistant/blog/day_90__beta/comment_3_c76675a4633cbbe347ed42c222918d38._comment
new file mode 100644
index 0000000000..151a9c2578
--- /dev/null
+++ b/doc/design/assistant/blog/day_90__beta/comment_3_c76675a4633cbbe347ed42c222918d38._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkurjhi0CRJvgm7QNaZDWS9hitBtavqIpc"
+ nickname="Bret"
+ subject="A few OS X bugs"
+ date="2012-09-25T00:50:56Z"
+ content="""
+Cabal update
+
+Cabal install git-annex 
+Seemed to install correctly on OS X 10.7
+
+After the installation, an application for git-annex showed up on my desktop.  This is the wrong place to put applications in OS X.  It should belong in the /Applications Folder.  
+Launching the git-annex app, the web-browser is opened, and it tells me to make a repository.  I entered /Users/[my home folder]/Annex and continued.  I then got an internal server error and nothing else happened.  The Error:
+
+uuid [\"-m\"] exited 127
+
+Annex was created, and there is a .git folder in it.
+
+Checking the annex status:
+Bret-Air:Annex bret$ git annex status
+git-annex: First run: git-annex init
+
+I'll try it on 10.6 here in just a moment.  Let me know if I can provide any more useful information.  
+"""]]
diff --git a/doc/design/assistant/blog/day_90__beta/comment_4_f0b8f77cb691e747fe35bcf2f51b5baa._comment b/doc/design/assistant/blog/day_90__beta/comment_4_f0b8f77cb691e747fe35bcf2f51b5baa._comment
new file mode 100644
index 0000000000..f6889fe049
--- /dev/null
+++ b/doc/design/assistant/blog/day_90__beta/comment_4_f0b8f77cb691e747fe35bcf2f51b5baa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkurjhi0CRJvgm7QNaZDWS9hitBtavqIpc"
+ nickname="Bret"
+ subject="comment 4"
+ date="2012-09-25T00:59:51Z"
+ content="""
+OS X 10.6 is doing the same thing as on 10.7.
+"""]]
diff --git a/doc/design/assistant/blog/day_90__beta/comment_5_99fbc9feac62e66a12b0d357cf86ccc1._comment b/doc/design/assistant/blog/day_90__beta/comment_5_99fbc9feac62e66a12b0d357cf86ccc1._comment
new file mode 100644
index 0000000000..d886d56bb5
--- /dev/null
+++ b/doc/design/assistant/blog/day_90__beta/comment_5_99fbc9feac62e66a12b0d357cf86ccc1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.141"
+ subject="comment 5"
+ date="2012-09-25T14:49:31Z"
+ content="""
+@Bret my best guess (without any error message from the uuid command) is that your uuid doesn't support the -m parameter. I've made the configure step check for this and it'll fall back to uuid without the parameter.
+"""]]
diff --git a/doc/design/assistant/blog/day_91__break.mdwn b/doc/design/assistant/blog/day_91__break.mdwn
new file mode 100644
index 0000000000..f2102746da
--- /dev/null
+++ b/doc/design/assistant/blog/day_91__break.mdwn
@@ -0,0 +1,7 @@
+Mostly took a break from working on the assistant today. Instead worked
+on adding incremental fsck to git-annex. Well, that will be something
+that assistant will use, eventually, probably.
+
+Jimmy and I have been working on a self-contained OSX app for using the
+assistant, that doesn't depend on installing git, etc. More on that
+once we have something that works.
diff --git a/doc/design/assistant/blog/day_92__S3.mdwn b/doc/design/assistant/blog/day_92__S3.mdwn
new file mode 100644
index 0000000000..c3f275a865
--- /dev/null
+++ b/doc/design/assistant/blog/day_92__S3.mdwn
@@ -0,0 +1,23 @@
+Amazon S3 was the second most popular choice in the
+[[polls/prioritizing_special_remotes]] poll, and since I'm not sure how
+I want to support phone/mp3 players, I did it first.
+
+So I added a configurator today to easily set up an Amazon S3 repository.
+That was straightforward and didn't take long since git-annex already
+supported S3.
+
+The hard part, of course, is key distribution. Since the webapp so far
+can only configure the shared encryption method, and not fullblown gpg keys,
+I didn't feel it would be secure to store the S3 keys in the git repository.
+Anyone with access to that git repo would have full access to S3 ... just not
+acceptable. Instead, the webapp stores the keys in a 600 mode file locally,
+and they're not distributed at all.
+
+When the same S3 repository is enabled on another computer, it prompts for
+keys then too. I did add a hint about using the IAM Management Console in
+this case -- it should be possible to set up users in IAM who can only
+access a single bucket, although I have not tried to set that up.
+
+---
+
+Also, more work on the standalone OSX app.
diff --git a/doc/design/assistant/blog/day_92__S3/comment_1_eda656247d11cea7fbed2e33137a39e5._comment b/doc/design/assistant/blog/day_92__S3/comment_1_eda656247d11cea7fbed2e33137a39e5._comment
new file mode 100644
index 0000000000..af610bdb73
--- /dev/null
+++ b/doc/design/assistant/blog/day_92__S3/comment_1_eda656247d11cea7fbed2e33137a39e5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2012-09-26T23:52:50Z"
+ content="""
+I think a lot of people misinterpreted \"phone/mp3 player\" as \"Android\"; I know I did.
+
+As you already support directories, MTP would be needed to support the other half of pretty much all phones and media players (other than those made by Apple). MTP is a valley of pain, though.
+"""]]
diff --git a/doc/design/assistant/blog/day_92__S3/comment_2_8249d2d9521e44c674da3fda74be077a._comment b/doc/design/assistant/blog/day_92__S3/comment_2_8249d2d9521e44c674da3fda74be077a._comment
new file mode 100644
index 0000000000..fb83b23e4a
--- /dev/null
+++ b/doc/design/assistant/blog/day_92__S3/comment_2_8249d2d9521e44c674da3fda74be077a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlFd2EbAmGD0FjHmuoerXfT0GO_jPcgvQA"
+ nickname="Gert"
+ subject="Single bucket for S3"
+ date="2012-09-27T09:17:24Z"
+ content="""
+You can easily do that with IAM, checkout <http://andrewhitchcock.org/?post=325>.
+
+It boils down to creating a policy for each user/bucket. But allow read access to the full bucket list (otherwise the AWS Console won't work).
+"""]]
diff --git a/doc/design/assistant/blog/day_93__OSX_standalone_app.mdwn b/doc/design/assistant/blog/day_93__OSX_standalone_app.mdwn
new file mode 100644
index 0000000000..711710fc7c
--- /dev/null
+++ b/doc/design/assistant/blog/day_93__OSX_standalone_app.mdwn
@@ -0,0 +1,23 @@
+Various bug fixes, and work on the OSX app today:
+
+* Avoid crashing when ssh-keygen fails due to not being able to parse
+  `authorized_keys`.. seems a lot of people have crufty unparsable
+  `authorized_keys` files.
+* On OSX, for some reason the webapp was failing to start sometimes due
+  to bind failing with EINVAL. I don't understand why, as that should
+  only happen if the socket is already bound, which it should not as
+  it's just been created. I was able to work around this by retrying
+  with a new socket when bind fails.
+* When setting up `authorized_keys` to let `git-annex-shell` be run,
+  it had been inserting a perl oneliner into it. I changed that
+  to instead call a `~/.ssh/git-annex-shell` wrapper script that it sets
+  up. The benefits are it no longer needs perl, and it's less ugly,
+  and the standalone OSX app can modify the wrapper script to point to
+  wherever it's installed today (people like to move these things around I
+  guess).
+* Made the standalone OSX app set up autostarting when it's first run.
+* Spent rather a long time collecting the licenses of all the software that
+  will be bundled with the standalone OSX app. Ended up with a file
+  containing 3954 lines of legalese. Happily, all the software appears
+  redistributable, and free software; even the couple of OSX system libraries
+  we're bundling are licensed under the APSL.
diff --git a/doc/design/assistant/blog/day_93__easy_install.mdwn b/doc/design/assistant/blog/day_93__easy_install.mdwn
new file mode 100644
index 0000000000..013b872e12
--- /dev/null
+++ b/doc/design/assistant/blog/day_93__easy_install.mdwn
@@ -0,0 +1,34 @@
+I hear that people want the git-annex assistant to be easy to install
+without messing about building it from source..
+
+## on OSX
+
+So Jimmy and I have been working all week on making an easily installed OSX
+app of the assistant. This is a .dmz file that bundles all the dependencies
+(git, etc) in, so it can be installed with one click.
+
+It seems to basically work. You can get it [[here|install/OSX]].
+
+Unfortunatly, the [[bugs/pasting_into_annex_on_OSX]] bug resurfaced while
+testing this.. So I can't really recommend using it on real data yet.
+
+Still, any testing you can do is gonna be really helpful. I'm squashing OSX
+bugs right and left.
+
+## on Linux
+
+First of all, the git-annex assistant is now available in Debian unstable,
+and in Arch Linux's AUR. Proper packages.
+
+For all the other Linux distributions, I have a workaround. It's
+a big hack, but it seems to work.. at least on Debian stable.
+
+I've just put up a [[install/linux_standalone]] tarball, which has **no
+library dependencies** apart from glibc, and doesn't even need git to be
+installed on your system.
+
+## on FreeBSD
+
+The FreeBSD port has been updated to include the git-annex assistant too..
+
+[[!meta title="day 94 easy install"]]
diff --git a/doc/design/assistant/blog/day_93__easy_install/comment_1_d4f7de723c98577ef28d89ee6b87fd13._comment b/doc/design/assistant/blog/day_93__easy_install/comment_1_d4f7de723c98577ef28d89ee6b87fd13._comment
new file mode 100644
index 0000000000..57a0c78d7a
--- /dev/null
+++ b/doc/design/assistant/blog/day_93__easy_install/comment_1_d4f7de723c98577ef28d89ee6b87fd13._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://rjc.pip.verisignlabs.com/"
+ ip="86.22.66.200"
+ subject="assistant in Debian"
+ date="2012-09-30T09:10:17Z"
+ content="""
+The same version of ghc in Debian repository on i386 and amd64 privides ghc-ghci virtual package while on all the other architectures it doesn't. Is that normal or shall I file a bug?
+
+What it basically means is that the packages, both git-annex (with assistant) and its build dependencies, for all the other archs cannot be build on Debian porting machines until that is fixed. It already is in the experimental version but until that one gets to unstable there won't be any official debs for all non-Intel architecures.
+"""]]
diff --git a/doc/design/assistant/blog/day_93__easy_install/comment_2_6337b341c1cfb2132b59704394e57b36._comment b/doc/design/assistant/blog/day_93__easy_install/comment_2_6337b341c1cfb2132b59704394e57b36._comment
new file mode 100644
index 0000000000..ba027e9217
--- /dev/null
+++ b/doc/design/assistant/blog/day_93__easy_install/comment_2_6337b341c1cfb2132b59704394e57b36._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.149"
+ subject="comment 2"
+ date="2012-09-30T17:11:13Z"
+ content="""
+The next upload to debian will enable building the assistant on architectures that don't have template haskell and so cannot build the webapp.
+"""]]
diff --git a/doc/design/assistant/blog/day_95__repository_groups.mdwn b/doc/design/assistant/blog/day_95__repository_groups.mdwn
new file mode 100644
index 0000000000..5e4bc6d209
--- /dev/null
+++ b/doc/design/assistant/blog/day_95__repository_groups.mdwn
@@ -0,0 +1,21 @@
+Spent a lot of time this weekend thinking about/stuck on the [[cloud]]
+notification problem. Currently IRC is looking like the best way for
+repositories to notify one-another when changes are made, but I'm not sure
+about using that, and not ready to start on it.
+
+Instead, laid some groundwork for [[transfer_control]] today. Added 
+some simple commands to manage groups of repositories, and find files
+that are present in repositories in a group. I'm not completely happy
+with the syntax for that, and need to think up some good syntax to specify
+files that are present in *all* repositories in a group.
+
+The plan is to have the assistant automatically guess at groups to put new
+repositories it makes in (it should be able to make good guesses),
+as well as have an interface to change them, and an interface to configure
+transfer control using these groups (and other ways of matching files).
+And, probably, some canned transfer control recipes for common setups.
+
+---
+
+Collected up the past week's work and made a release today. I'm probably
+back to making regular releases every week or two.
diff --git a/doc/design/assistant/blog/day_96__revisiting_file_adds.mdwn b/doc/design/assistant/blog/day_96__revisiting_file_adds.mdwn
new file mode 100644
index 0000000000..a9607bb804
--- /dev/null
+++ b/doc/design/assistant/blog/day_96__revisiting_file_adds.mdwn
@@ -0,0 +1,24 @@
+Today I revisited something from way back in [[day_7__bugfixes]].
+Back then, it wasn't practical to run `git ls-files` on every
+file the watcher noticed, to check if it was already in git. Revisiting
+this, I found I could efficiently do that check at the same point it checks
+`lsof`. When there's a lot of files being added, they're batched up at that
+point, so it won't be calling `git ls-files` repeatedly.
+
+Result: It's safe to mix use of the assistant with files stored in git
+in the normal way. And it's safe to mix use of `git annex unlock` with
+the assistant; it won't immediately re-lock files. Yay!
+
+----
+
+Also fixed a crash in the committer, and made `git annex status` display
+repository groups.
+
+----
+
+Been thinking through where to store the [[transfer_control]] expressions.
+Since repositories need to know about the transfer controls of other
+remotes, storing them in `.git/config` isn't right. I thought it might be
+nice to configure the expressions in `.gitattributes`, but it seems the
+file format doesn't allow complicated multi-word attributes. Instead,
+they'll be stored in the git-annex branch.
diff --git a/doc/design/assistant/blog/day_96__revisiting_file_adds/comment_1_da3ca47041168b6c82aeb2c18acc5017._comment b/doc/design/assistant/blog/day_96__revisiting_file_adds/comment_1_da3ca47041168b6c82aeb2c18acc5017._comment
new file mode 100644
index 0000000000..298a953710
--- /dev/null
+++ b/doc/design/assistant/blog/day_96__revisiting_file_adds/comment_1_da3ca47041168b6c82aeb2c18acc5017._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://wiggy.net/"
+ nickname="Wichert"
+ subject="symlinks?"
+ date="2012-10-03T07:15:21Z"
+ content="""
+Does that mean that git-annex will no longer need to turn everything into symlinks? I suspect that that will improve behaviour on at least OSX quite a bit.
+"""]]
diff --git a/doc/design/assistant/blog/day_97__stuffing.mdwn b/doc/design/assistant/blog/day_97__stuffing.mdwn
new file mode 100644
index 0000000000..595aca1e0c
--- /dev/null
+++ b/doc/design/assistant/blog/day_97__stuffing.mdwn
@@ -0,0 +1,14 @@
+Not a lot of programming today; I spent most of the day stuffing hundreds
+of envelopes for this Kickstarter thing you may have heard of. Some post
+office is going to be very surprised with all the international mail soon.
+
+----
+
+That said, I did write 184 lines of code. (Actually rather a lot, but it
+was mostly pure functional code, so easy to write.) That
+pops up your text editor on a file with the the trust and group
+configurations of repositories, that's stored in the git-annex branch.
+Handy for both viewing that stuff all in one place, and changing it.
+
+The real reason for doing that is to provide a nice interface for editing
+transfer control expressions, which I'll be adding next.
diff --git a/doc/design/assistant/blog/day_98__preferred_content.mdwn b/doc/design/assistant/blog/day_98__preferred_content.mdwn
new file mode 100644
index 0000000000..d1324f69eb
--- /dev/null
+++ b/doc/design/assistant/blog/day_98__preferred_content.mdwn
@@ -0,0 +1,44 @@
+Started implementing [[transfer_control]]. Although I'm currently calling
+the configuration for it "preferred content expressions". (What a mouthful!)
+
+I was mostly able to reuse the Limit code (used to handle parameters like
+--not --in otherrepo), so it can already build Matchers for preferred content
+expressions in my little Domain Specific Language.
+
+Preferred content expressions can be edited with `git annex vicfg`, which
+checks that they parse properly. 
+
+The plan is that the first place to use them is not going to be inside the
+assistant, but in commands that use the `--auto` parameter, which will use
+them as an additional constraint, in addition to the numcopies setting
+already used. Once I get it working there, I'll add it to the assistant.
+
+Let's say a repo has a preferred content setting of
+"(not copies=trusted:2) and (not in=usbdrive)"
+
+* `git annex get --auto` will get files that have less than 2 trusted
+  copies, and are not in the usb drive.
+* `git annex drop --auto` will drop files that have 2 or more trusted
+  copies, and are not in the usb drive (assuming numcopies allows dropping
+  them of course).
+* `git annex copy --auto --to thatrepo` run from another repo
+  will only copy files that have less than 2 trusted copies. (And if that
+  was run on the usb drive, it'd never copy anything!)
+
+There is a complication here.. What if the repo with that preferred content
+setting is itself trusted? Then when it gets a file, its number of
+trusted copies increases, which will make it be dropped again. :-/
+
+This is a nuance that the numcopies code already deals with, but it's
+much harder to deal with it in these complicated expressions. I need to think
+about this; the three ideas I'm working on are:
+
+1. Leave it to whoever/whatever writes these expressions to write ones
+   that avoid such problems. Which is ok if I'm the only one writing
+   pre-canned ones, in practice..
+2. Transform expressions into ones that avoid such problems. (For example,
+   replace "not copies=trusted:2" with "not (copies=trusted:2 or (in=here and
+   trusted=here and copies=trusted:3))"
+3. Have some of the commands (mostly drop I think) pretend the drop
+   has already happened, and check if it'd then want to get the file back
+   again.
diff --git a/doc/design/assistant/blog/day_98__preferred_content/comment_1_2136618e3515d0ac6369a41f1934ec2a._comment b/doc/design/assistant/blog/day_98__preferred_content/comment_1_2136618e3515d0ac6369a41f1934ec2a._comment
new file mode 100644
index 0000000000..b0fcd8c798
--- /dev/null
+++ b/doc/design/assistant/blog/day_98__preferred_content/comment_1_2136618e3515d0ac6369a41f1934ec2a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://meep.pl/"
+ ip="193.23.174.18"
+ subject="Ah, the barber paradox"
+ date="2012-10-05T06:51:11Z"
+ content="""
+Nice. Would (not in=here) be the simplest paradoxical expression?
+
+Is just disregarding the target repo completely during checks a possibility? This would interpret (not copies=trusted:X) as \"not in X *other* trusted repositories, no matter whether we are trusted or not\", and (not in=here) just as \"true\". I think this should generally arrive at the same results as the option 2., but by definition of the expression meaing, not by rewriting.
+
+Alternative 3 (or is my wording different enough to be 3a?) - check that the invariant \"we have all the known files matching our PCE and only these files\" would hold after an operation before actually performing it - could be bistable if done both for gets and drops:
+
+* (not in=here) and we do not have the file -> get thinks \"if we get it, we have a file not matching the PCE\" -> get does not get it;
+* (not in=here) and we do have the file -> drop thinks \"if we drop it, there exists a file matching the PCE which we miss\" -> drop does not drop it.
+
+This is not necessarily bad. Checking just for drops should be monostable, I guess, but doesn't it look a bit arbitrary? (Though it would be again equivalent to option 2, wouldn't it? So maybe not that arbitrary.)
+"""]]
diff --git a/doc/design/assistant/blog/day_98__preferred_content/comment_2_5f6db00e69628bf2f72b0e6f2981a49b._comment b/doc/design/assistant/blog/day_98__preferred_content/comment_2_5f6db00e69628bf2f72b0e6f2981a49b._comment
new file mode 100644
index 0000000000..fa1ce32b83
--- /dev/null
+++ b/doc/design/assistant/blog/day_98__preferred_content/comment_2_5f6db00e69628bf2f72b0e6f2981a49b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.149"
+ subject="comment 2"
+ date="2012-10-05T15:08:26Z"
+ content="""
+Yes, I think checking the future only for drops is both stable and equivilant to the other choices. 
+
+Disregarding the target solves the problem for the current set of expressions. There may be future expressions or operations where that does not hold. For example, if move supported --auto (which it does not), you'd need to disregard both sides.
+
+That method would make it impossible to do some possibly useful things. \"in=here or (not copies=3)\"
+
+The real problem with it is that existing options like --copies and --in already take all repos into account, so this would potentally lead to two divergent DSLs being used by git-annex, which would probably be confusing.
+"""]]
diff --git a/doc/design/assistant/blog/day_99_shotgun.mdwn b/doc/design/assistant/blog/day_99_shotgun.mdwn
new file mode 100644
index 0000000000..77a08f3cb3
--- /dev/null
+++ b/doc/design/assistant/blog/day_99_shotgun.mdwn
@@ -0,0 +1,70 @@
+Fixed the assistant to wait on all the zombie processes that would sometimes
+pile up. I didn't realize this was as bad as it was.
+
+Zombies and git-annex have been a problem since I started developing it,
+because back then I made some rather poor choices, due to barely knowing
+how to write Haskell. So parts of the code that stream input from git commands
+don't clean up after them properly. Not normally a problem, because
+git-annex reaps the zombies after each file it processes. But this reaping
+is not thread-safe; it cannot be used in the assistant.
+
+If I were starting git-annex today, I'd use one of the new Haskell things like
+Conduits, that allow for very clean control over finalization of resources.
+But switching it to Conduits now would probably take weeks of work; I've not
+yet felt it was worthwhile. (Also it's not clear Conduits are the last,
+best thing.)
+
+For now, it keeps track of the pids it needs to wait on, and all the code
+run by the assistant is zombie-free. However, some code for fsck and unused
+that I anticipate the assistant using eventually still has some lurking
+zombies.
+
+----
+
+Solved the issue with preferred content expressions and dropping that
+I mentioned yesterday. My solution was to add a parameter to specify a set
+of repositories where content should be assumed not to be present. When
+deciding whether to drop, it can put the current repository in, and then
+if the expression fails to match, the content can be dropped.
+
+Using yesterday's example "(not copies=trusted:2) and (not in=usbdrive)",
+when the local repo is one of the 2 trusted copies, the drop check will
+see only 1 trusted copy, so the expression matches, and so the content will
+not be dropped.
+
+I've not tested my solution, but it type checks. :P I'll wire it up to
+`get/drop/move --auto` tomorrow and see how it performs.
+
+----
+
+Would preferred content expressions be more readble if they were inverted
+(becoming content filtering expressions)?
+
+1. "(not copies=trusted:2) and (not in=usbdrive)" becomes
+   "copies=trusted:2 or in=usbdrive"
+2. "smallerthan=10mb and include=*.mp3 and exclude=junk/*" becomes
+   "largerthan=10mb or exclude=*.mp3" or include=junk/*"
+3. "(not group=archival) and (not copies=archival:1)" becomes
+   "group=archival or copies=archival:1"
+
+1 and 3 are improved, but 2, less so. It's a trifle weird for "include"
+to mean "include in excluded content".
+
+The other reason not to do this is that currently the expressions
+can be fed into `git annex find` on the command line, and it'll come
+back with the files that would be kept.
+
+Perhaps a middle groud is to make "dontwant" be an alias for "not".
+Then we can write "dontwant (copies=trusted:2 or in=usbdrive)"
+
+----
+
+A user told me this:
+
+> I can confirm that the assistant does what it is supposed to do really well. I
+> just hooked up my notebook to the network and it starts syncing from notebook to
+> fileserver and the assistant on the fileserver also immediately starts syncing
+> to the [..] backup
+
+That makes me happy, it's the first quite so real-world success report I've
+heard.
diff --git a/doc/design/assistant/blog/day_99_shotgun/comment_1_12bb8f54bb13ea20ac4187a2301d77ca._comment b/doc/design/assistant/blog/day_99_shotgun/comment_1_12bb8f54bb13ea20ac4187a2301d77ca._comment
new file mode 100644
index 0000000000..eeaefef421
--- /dev/null
+++ b/doc/design/assistant/blog/day_99_shotgun/comment_1_12bb8f54bb13ea20ac4187a2301d77ca._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://meep.pl/"
+ ip="193.23.174.18"
+ subject="Include/exclude"
+ date="2012-10-06T08:40:23Z"
+ content="""
+It seems that example 2 reads weird for filtering because exclude/include say *what to do* while copies/in say *what to test*. An alias (maybe \"glob\") for include  should be acceptable both ways (largerthan=10mb or glob=junk/\* or not glob=\*.mp3).
+
+That said, I would vote for keeping PCEs. And actually the simple \"not (copies=trusted:2 or in=usbdrive)\" does not read significantly worse than with \"dontwant\". (In *my bikeshed* we would have \"all\" == \"glob=\*\" and \"except\" == \"and not\").
+"""]]
diff --git a/doc/design/assistant/blog/day_9__correctness.mdwn b/doc/design/assistant/blog/day_9__correctness.mdwn
new file mode 100644
index 0000000000..1fa4c09d0d
--- /dev/null
+++ b/doc/design/assistant/blog/day_9__correctness.mdwn
@@ -0,0 +1,30 @@
+	git merge watch_
+
+My cursor has been mentally poised here all day, but I've been reluctant to
+merge watch into master. It seems solid, but is it correct? I was able to
+think up a lot of races it'd be subject to, and deal with them, but did I
+find them all?
+
+Perhaps I need to do some automated fuzz testing to reassure myself.
+I looked into using [genbackupdata](http://liw.fi/genbackupdata/) to that
+end. It's not quite what I need, but could be
+[moved in that direction](http://bugs.debian.org/677542). Or I could write
+my own fuzz tester, but it seems better to use someone else's, because 
+a) laziness and b) they're less likely to have the same blind spots I do.
+
+My reluctance to merge isn't helped by the known bugs with files that are
+either already open before `git annex watch` starts, or are opened by two
+processes at once, and confuse it into annexing the still-open file when one
+process closes it.
+
+I've been thinking about just running `lsof` on every file as it's being
+annexed to check for that, but in the end, `lsof` is too slow. Since its
+check involves trawling through all of /proc, it takes it a good half a
+second to check a file, and adding 25 seconds to the time it takes to
+process 100 files is just not acceptable.
+
+But an option that could work is to run `lsof` after a bunch of new files
+have been annexed. It can check a lot of files nearly as fast as a single
+one. In the rare case that an annexed file is indeed still open, it could
+be moved back out of the annex. Then when its remaining writer finally
+closes it, another inotify event would re-annex it.
diff --git a/doc/design/assistant/blog/day_9__correctness/comment_1_564a39cb976767e2c0a9c74fabe10be4._comment b/doc/design/assistant/blog/day_9__correctness/comment_1_564a39cb976767e2c0a9c74fabe10be4._comment
new file mode 100644
index 0000000000..8236002ccd
--- /dev/null
+++ b/doc/design/assistant/blog/day_9__correctness/comment_1_564a39cb976767e2c0a9c74fabe10be4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://wiggy.net/"
+ nickname="Wichert"
+ subject="os compatibility"
+ date="2012-06-15T07:19:23Z"
+ content="""
+A downside of relying on lsof is that you might be painting yourself into a linux corner: other operating systems might not have a lsof or alternative you can rely on. Especially for Windows this might be a worry. 
+"""]]
diff --git a/doc/design/assistant/blog/day_9__correctness/comment_2_77924e9d50b40f05e792e427a25849a6._comment b/doc/design/assistant/blog/day_9__correctness/comment_2_77924e9d50b40f05e792e427a25849a6._comment
new file mode 100644
index 0000000000..8744882c97
--- /dev/null
+++ b/doc/design/assistant/blog/day_9__correctness/comment_2_77924e9d50b40f05e792e427a25849a6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://dieter-be.myopenid.com/"
+ nickname="dieter"
+ subject="filesystem number of open file handles on a file"
+ date="2012-06-15T08:21:37Z"
+ content="""
+wasn't there some filesystem functionality that could tell you the amount of open file handles on a certain file?  I thought this was tracked per-file too.
+Or maybe i'm just confusing it with the number of hard links (which stat can tell you), anyway something to look into.
+"""]]
diff --git a/doc/design/assistant/blog/day_9__correctness/comment_3_92bd86cd06d579e23800af2e5c66a291._comment b/doc/design/assistant/blog/day_9__correctness/comment_3_92bd86cd06d579e23800af2e5c66a291._comment
new file mode 100644
index 0000000000..680f16ecc1
--- /dev/null
+++ b/doc/design/assistant/blog/day_9__correctness/comment_3_92bd86cd06d579e23800af2e5c66a291._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 3"
+ date="2012-06-15T08:58:17Z"
+ content="""
+I would also be reluctant to use lsof for the sake of non-linux systems or systems that don't have lsof. I've only been playing around with the watch branch of my \"other\" laptop under archlinux. It looks usable, however I would prefer support for OSX before the watch branch gets merged to master ;)
+"""]]
diff --git a/doc/design/assistant/blog/day_9__correctness/comment_4_0d12b51ccdfc2a94d3e59a5628521e0a._comment b/doc/design/assistant/blog/day_9__correctness/comment_4_0d12b51ccdfc2a94d3e59a5628521e0a._comment
new file mode 100644
index 0000000000..7218754916
--- /dev/null
+++ b/doc/design/assistant/blog/day_9__correctness/comment_4_0d12b51ccdfc2a94d3e59a5628521e0a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 4"
+ date="2012-06-15T10:21:17Z"
+ content="""
+Corner case, but if the other program finishes writing while you are annexing and your check shows no open files, you are left with bad checksum on a correct file. This \"broken\" file with propagate and the next round of fsck will show that all copies are \"bad\".
+
+Without verifying if this is viable, could you set the file RO and thus block future writes before starting to annex?
+"""]]
diff --git a/doc/design/assistant/blog/day_9__correctness/comment_5_208f9dd3e1d92555b05c29159538a901._comment b/doc/design/assistant/blog/day_9__correctness/comment_5_208f9dd3e1d92555b05c29159538a901._comment
new file mode 100644
index 0000000000..b7fbecc398
--- /dev/null
+++ b/doc/design/assistant/blog/day_9__correctness/comment_5_208f9dd3e1d92555b05c29159538a901._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.135"
+ subject="comment 5"
+ date="2012-06-15T15:14:52Z"
+ content="""
+@wichert All this inotify stuff is entirely linux specific AFAIK anyway, so it's find for workarounds to limitations in inotify functionality to also be linux specific.
+
+@dieter I think you're thinking of hard links, filesystems don't track number of open file handles afaik.
+
+@Jimmy, I'm planning to get watch going on freebsd (and hopefully that will also cover OSX), after merging it :)
+
+@Richard, the file is set RO while it's being annexed, so any lsof would come after that point.
+"""]]
diff --git a/doc/design/assistant/blog/day_9__correctness/comment_6_90cc6b60718896fb175919417600fdf9._comment b/doc/design/assistant/blog/day_9__correctness/comment_6_90cc6b60718896fb175919417600fdf9._comment
new file mode 100644
index 0000000000..622b141fdb
--- /dev/null
+++ b/doc/design/assistant/blog/day_9__correctness/comment_6_90cc6b60718896fb175919417600fdf9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.135"
+ subject="comment 6"
+ date="2012-06-15T15:23:21Z"
+ content="""
+But Rich is right, and I was thinking the same thing earlier this morning, that delaying the lsof allows the writer to change the file and exit, and only fsck can detect the problem then. Setting file permissions doesn't help once a process already has it open for write. Which has put me off the delayed lsof idea unfortunately. lsof *could* be run safely during the intial annexing.
+"""]]
diff --git a/doc/design/assistant/chunks.mdwn b/doc/design/assistant/chunks.mdwn
new file mode 100644
index 0000000000..0aa389899a
--- /dev/null
+++ b/doc/design/assistant/chunks.mdwn
@@ -0,0 +1,271 @@
+To avoid leaking even the size of your encrypted files to cloud storage
+providers, add a mode that stores fixed size chunks.
+
+May be a useful starting point for [[deltas]].
+
+May also allow for downloading different chunks of a file concurrently from
+multiple remotes.
+
+Also, can allow resuming of interrupted uploads and downloads.
+
+# legacy chunking
+
+Supported by only the webdav and directory special remotes.
+
+Filenames are used for the chunks that make it easy to see which chunks
+belong together, even when encryption is used. There is also a chunkcount
+file, that similarly leaks information.
+
+It is not possible to enable chunking on a non-chunked remote.
+
+Problem: Two uploads of the same key from repos with different chunk sizes
+could lead to data loss. For example, suppose A is 10 mb chunksize, and B
+is 20 mb, and the upload speed is the same. If B starts first, when A will
+overwrite the file it is uploading for the 1st chunk. Then A uploads the
+second chunk, and once A is done, B finishes the 1st chunk and uploads its
+second. We now have [chunk 1(from A), chunk 2(from B)].
+
+# new requirements
+
+Every special remote should support chunking. (It does not make sense
+to support it for git remotes, but gcrypt remotes should support it.)
+
+S3 remotes should chunk by default, because the current S3 backend fails
+for files past a certian size. See [[bugs/Truncated_file_transferred_via_S3]].
+
+The size of chunks, as well as whether any chunking is done, should be
+configurable on the fly without invalidating data already stored in the
+remote. This seems important for usability (eg, so users can turn chunking
+on in the webapp when configuring an existing remote).
+
+Two concurrent uploaders of the same object to a remote should be safe,
+even if they're using different chunk sizes.
+
+The legacy chunk method needs to be supported for back-compat, so
+keep the chunksize= setting to enable that mode, and add a new chunk=
+setting for the new mode.
+
+# obscuring file sizes
+
+To hide from a remote any information about the sizes of files could be
+another goal of chunking. At least two things are needed for this:
+
+1. The filenames used on the remote don't indicate which chunks belong
+   together.
+
+2. The final short chunk needs to be padded with random data,
+   so that a remote sees only encrypted files with uniform sizes
+   and cannot make guesses about the kinds of data being stored.
+
+Note that padding cannot completely hide all information from an attacker
+who is logging puts or gets. An attacker could, for example, look at the
+times of puts, and guess at when git-annex has moved on to
+encrypting/decrypting the next object, and so guess at the approximate
+sizes of objects. (Concurrent uploads/downloads or random delays could be
+added to prevent these kinds of attacks.)
+
+And, obviously, if someone stores 10 tb of data in a remote, they probably
+have around 10 tb of files, so it's probably not a collection of recipes..
+
+Given its inneficiencies and lack of fully obscuring file sizes,
+padding may not be worth adding, but is considered in the designs below.
+
+# design 1
+
+Add an optional chunk field to Key. It is only present for chunk
+2 and above. Ie, SHA256-s12345--xxxxxxx is the first chunk (or whole
+object), while SHA256-s12345-c2--xxxxxxx is the second chunk.
+
+On an encrypted remote, Keys are generated with the chunk field, and then
+HMAC enrypted.
+
+Note that only using it for chunks 2+ means that git-annex can start by
+requesting the regular key, so an observer sees the same request whether
+chunked or not, and does not see eg, a pattern of failed requests for 
+a non-chunked key, followed by successful requests for the chunked keys.
+(Both more efficient and perhaps more secure.)
+
+Problem: This makes putting chunks easy. But there is a problem when getting 
+an object that has been chunked. If the key size is not known, we
+cannot tell when we've gotten the last chunk. (Also, we cannot strip
+padding.) Note that `addurl` sometimes generates keys w/o size info
+(particularly, it does so by design when using quvi).
+
+Problem: Also, this makes `checkPresent` hard to implement: How can it know if
+all the chunks are present, if the key size is not known?
+
+Problem: Also, this makes it difficult to download encrypted keys, because
+we only know the decrypted size, not the encrypted size, so we can't
+be sure how many chunks to get, and all chunks need to be downloaded before
+we can decrypt any of them. (Assuming we encrypt first; chunking first
+avoids this problem.)
+
+Problem: Does not solve concurrent uploads with different chunk sizes.
+
+# design 2
+
+When chunking is enabled, always put a chunk number in the Key,
+along with the chunk size.
+So, SHA256-1048576-c1--xxxxxxx for the first chunk of 1 megabyte.
+
+Before any chunks are stored, write a chunkcount file, eg
+SHA256-s12345-c0--xxxxxxx. Note that this key is the same as the original
+object's key, except with chunk number set to 0. This file contains both
+the number of chunks, and also the chunk size used. `checkPresent` downloads this
+file, and then verifies that each chunk is present, looking for keys with
+the expected chunk numbers and chunk size.
+
+This avoids problems with multiple writers using different chunk sizes,
+since they will be uploading to different files.
+
+Problem: In such a situation, some duplicate data might be stored, not
+referenced by the last chunkcount file to be written. It would not be
+dropped when the key was removed from the remote.
+
+Note: This design lets an attacker with logs tell the (appoximate) size of
+objects, by finding the small files that contain a chunk count, and
+correlating when that is written/read and when other files are
+written/read. That could be solved by padding the chunkcount key up to the
+size of the rest of the keys, but that's very innefficient; `checkPresent` is not
+designed to need to download large files.
+
+# design 3
+
+Like design 1, but add an encrypted chunk count prefix to the first object.
+This needs to be done in a way that does not let an attacker tell if the
+object has an encrypted chunk count prefix or not. 
+
+This seems difficult; attacker could probably tell where the first encrypted
+part stops and the next encrypted part starts by looking for gpg headers,
+and so tell which files are the first chunks.
+
+Also, `checkPresent` would need to download some or all of the first file.
+If all, that's a lot more expensive. If only some is downloaded, an
+attacker can guess that the file that was partially downloaded is the
+first chunk in a series, and wait for a time when it's fully downloaded to
+determine which are the other chunks.
+
+Problem: Two uploads of the same key from repos with different chunk sizes
+could lead to data loss. (Same as in design 2.)
+
+# design 4
+
+Use key SHA256-s12345-S1048576-C1--xxxxxxx for the first chunk of 1 megabyte.
+
+Note that keeping the 's'ize field unchanged is necessary because it 
+disambiguates eg, WORM keys. So a 'S'ize field is used to hold the chunk
+size.
+
+Instead of storing the chunk count in the special remote, store it in 
+the git-annex branch. 
+
+The location log does not record locations of individual chunk keys
+(too space-inneficient). Instead, look at a chunk log in the
+git-annex branch to get the chunk count and size for a key.
+
+`checkPresent` would check if any of the logged sets of chunks is 
+present on the remote. It would also check if the non-chunked key is
+present, as a fallback.
+
+When dropping a key from the remote, drop all logged chunk sizes.
+(Also drop any non-chunked key.)
+
+As long as the location log and the chunk log are committed atomically,
+this guarantees that no orphaned chunks end up on a remote
+(except any that might be left by interrupted uploads).
+
+This has the best security of the designs so far, because the special 
+remote doesn't know anything about chunk sizes. It uses a little more
+data in the git-annex branch, although with care (using the same timestamp
+as the location log), it can compress pretty well.
+
+## chunk log
+
+Stored in the git-annex branch, this provides a mapping `Key -> [[Key]]`.
+
+Note that a given remote uuid might have multiple sets of chunks (with
+different sizes) logged, if a key was stored on it twice using different
+chunk sizes. Also note that even when the log indicates a key is chunked,
+the object may be stored non-chunked on the remote too.
+
+For fixed size chunks, there's no need to store the list of chunk keys,
+instead the log only records the number of chunks (needed because the size
+of the parent Key may not be known), and the chunk size.
+
+Example:
+
+	1287290776.765152s e605dca6-446a-11e0-8b2a-002170d25c55:10240 9
+
+Later, might want to support other kinds of chunks, for example ones made
+using a rsync-style rolling checksum. It would probably not make sense to
+store the full [Key] list for such chunks in the log. Instead, it might be
+stored in a file on the remote.
+
+To support such future developments, when updating the chunk log, 
+git-annex should preserve unparsable values (the part after the colon).
+
+## chunk then encrypt
+
+Rather than encrypting the whole object 1st and then chunking, chunk and
+then encrypt.
+
+Reasons:
+
+1. If 2 repos are uploading the same key to a remote concurrently,
+   this allows some chunks to come from one and some from another,
+   and be reassembled without problems.
+
+2. Also allows chunks of the same object to be downloaded from different
+   remotes, perhaps concurrently, and again be reassembled without
+   problems.
+
+3. Prevents an attacker from re-assembling the chunked file using details
+   of the gpg output. Which would expose approximate
+   file size even if padding is being used to obscure it.
+
+Note that this means that the chunks won't exactly match the configured
+chunk size. gpg does compression, which might make them a
+lot smaller. Or gpg overhead could make them slightly larger. So `checkPresent`
+cannot check exact file sizes.
+
+If padding is enabled, gpg compression should be disabled, to not leak
+clues about how well the files compress and so what kind of file it is.
+
+## chunk key hashing
+
+A chunk key should hash into the same directory structure as its parent
+key. This will avoid lots of extra hash directories when using chunking
+with non-encrypted keys.
+
+Won't happen when the key is encrypted, but that is good; hashing to the
+same bucket then would allow statistical correlation.
+
+## resuming interupted transfers
+
+Resuming interrupted downloads, and uploads are both possible.
+
+Downloads: If the tmp file for a key exists, round it to the chunk size,
+and skip forward to the next needed chunk. Easy.
+
+Uploads: Check if the 1st chunk is present. If so, check the second chunk,
+etc. Once the first missing chunk is found, start uploading from there.
+
+That adds one extra checkPresent call per upload. Probably a win in most cases.
+Can be improved by making special remotes open a persistent
+connection that is used for transferring all chunks, as well as for
+checking checkPresent.
+
+Note that this is safe to do only as long as the Key being transferred
+cannot possibly have 2 different contents in different repos. Notably not
+necessarily the case for the URL keys generated for quvi.
+
+Both **done**.
+
+## parallel
+
+If 2 remotes both support chunking, uploading could upload different chunks
+to them in parallel. However, the chunk log does not currently allow
+representing the state where some chunks are on one remote and others on
+another remote.
+
+Parallel downloading of chunks from different remotes is a bit more doable.
diff --git a/doc/design/assistant/chunks/comment_1_a3b24ff308664e89c97d23034e4ffe2f._comment b/doc/design/assistant/chunks/comment_1_a3b24ff308664e89c97d23034e4ffe2f._comment
new file mode 100644
index 0000000000..c1432c3596
--- /dev/null
+++ b/doc/design/assistant/chunks/comment_1_a3b24ff308664e89c97d23034e4ffe2f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 1"
+ date="2021-04-18T16:18:45Z"
+ content="""
+I am unclear about something: does git-annex in fact pad chunks? And does that mean if I annex a 500 KB file, it will actually use 1MB of space (or whatever the chunk size is?)
+"""]]
diff --git a/doc/design/assistant/chunks/comment_2_ec5c7a80d1e17db19d178e821f6534e5._comment b/doc/design/assistant/chunks/comment_2_ec5c7a80d1e17db19d178e821f6534e5._comment
new file mode 100644
index 0000000000..4bcc265f88
--- /dev/null
+++ b/doc/design/assistant/chunks/comment_2_ec5c7a80d1e17db19d178e821f6534e5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-04-18T17:05:43Z"
+ content="""
+git-annex does not pad chunks, although the data it stores is designed to
+allow adding padding later if there's a good reason to.
+"""]]
diff --git a/doc/design/assistant/cloud.mdwn b/doc/design/assistant/cloud.mdwn
new file mode 100644
index 0000000000..f0452df2a9
--- /dev/null
+++ b/doc/design/assistant/cloud.mdwn
@@ -0,0 +1,45 @@
+The [[syncing]] design assumes the network is connected. But it's often
+not in these pre-IPV6 days, so the cloud needs to be used to bridge between
+LANS.
+
+## The cloud notification problem (**done**)
+
+Alice and Bob have repos, and there is a cloud remote they both share.
+Alice adds a file; the assistant transfers it to the cloud remote.
+How does Bob find out about it?
+
+There are two parts to this problem. Bob needs to find out that there's
+been a change to Alice's git repo. Then he needs to pull from Alice's git repo,
+or some other repo in the cloud she pushed to. Once both steps are done,
+the assistant will transfer the file from the cloud to Bob.
+
+* dvcs-autosync uses xmppp; all repos need to have the same xmpp account
+  configured, and send self-messages. An alternative would be to have
+  different accounts that join a channel or message each other. Still needs
+  account configuration.
+* irc could be used. With a default irc network, and an agreed-upon channel,
+  no configuration should be needed. IRC might be harder to get through
+  some firewalls, and is prone to netsplits, etc. IRC networks have reasons
+  to be wary of bots using them. Only basic notifications could be done over
+  irc, as it has little security.
+* When there's a ssh server involved, code could be run on it to notify
+  logged-in clients. But this is not a general solution to this problem.
+* pubsubhubbub does not seem like an option; its hubs want to pull down
+  a feed over http.
+
+See [[xmpp]] for design of git-annex's use of xmpp for push notifications.
+
+## storing git repos in the cloud **done for XMPP**
+
+Of course, one option is to just use github etc to store the git repo.
+
+Two things can store git repos in Amazon S3:
+* <http://gabrito.com/post/storing-git-repositories-in-amazon-s3-for-high-availability>
+* <http://wiki.cs.pdx.edu/oss2009/index/projects/gits3.html>
+
+Another option is to not store the git repo in the cloud, but push/pull
+peer-to-peer. When peers cannot directly talk to one-another, this could be
+bounced through something like XMPP. This is **done** for [[xmpp]]!
+
+Another option: Use <https://spwhitton.name/tech/code/git-remote-gcrypt/> to store
+git repo encrypted on cloud storage.
diff --git a/doc/design/assistant/cloud/comment_1_4997778abc171999499487b71b31c9ba._comment b/doc/design/assistant/cloud/comment_1_4997778abc171999499487b71b31c9ba._comment
new file mode 100644
index 0000000000..1a01afaa33
--- /dev/null
+++ b/doc/design/assistant/cloud/comment_1_4997778abc171999499487b71b31c9ba._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkq0-zRhubO6kR9f85-5kALszIzxIokTUw"
+ nickname="James"
+ subject="Cloud Service Limitations"
+ date="2012-06-11T02:15:04Z"
+ content="""
+Hey Joey!
+
+I'm not very tech savvy, but here is my question. 
+I think for all cloud service providers, there is an upload limitation on how big one file may be.
+For example, I can't upload a file bigger than 100 MB on box.net. 
+Does this affect git-annex at all? Will git-annex automatically split the file depending on the cloud provider or will I have to create small RAR archives of one large file to upload them?
+
+Thanks!
+James
+"""]]
diff --git a/doc/design/assistant/cloud/comment_2_08da8bc74a4845e354dca99184cffd70._comment b/doc/design/assistant/cloud/comment_2_08da8bc74a4845e354dca99184cffd70._comment
new file mode 100644
index 0000000000..a9b377ea5f
--- /dev/null
+++ b/doc/design/assistant/cloud/comment_2_08da8bc74a4845e354dca99184cffd70._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.126"
+ subject="re: cloud"
+ date="2012-06-11T04:48:08Z"
+ content="""
+Yes, git-annex has to split files for certian providers. I already added support for this as part of my first pass at supporting box.com, see [[tips/using_box.com_as_a_special_remote]].
+"""]]
diff --git a/doc/design/assistant/cloud/comment_3_faafd1266301997b1822d215ec8e8d8c._comment b/doc/design/assistant/cloud/comment_3_faafd1266301997b1822d215ec8e8d8c._comment
new file mode 100644
index 0000000000..074a3a82c8
--- /dev/null
+++ b/doc/design/assistant/cloud/comment_3_faafd1266301997b1822d215ec8e8d8c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7Oyqusvn0oONFtVhCx5gRAcvPjyRMcBI"
+ nickname="Michaël"
+ subject="is ftp an option?"
+ date="2012-05-30T10:44:12Z"
+ content="""
+for people only having ftp-access to there storage.
+"""]]
diff --git a/doc/design/assistant/cloud/comment_4_3eb557d5439831f6e0032944d12c02cf._comment b/doc/design/assistant/cloud/comment_4_3eb557d5439831f6e0032944d12c02cf._comment
new file mode 100644
index 0000000000..e3879a1142
--- /dev/null
+++ b/doc/design/assistant/cloud/comment_4_3eb557d5439831f6e0032944d12c02cf._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9XEh8pxrJxZxIkyK7lWaA7QG1UWt9lgU"
+ nickname="Gugelplus"
+ subject="OwnCloud"
+ date="2012-08-27T20:43:19Z"
+ content="""
+“Google drive (attractive because it's free, only 5 gb tho)”
+
+Just in case somebody also wants their 5GB of disk space in the cloud, consider using some of the [owncloud providers](http://owncloud.org/providers/). They also offer that amount, but they use free software for everything, using standard protocols (WebDav mostly, because is well supported in all OS).
+
+Git Annex works with them through davfs2, but it would be great if it could support this other program/protocol (OwnCloud/WebDAV) in a more integrated way.
+"""]]
diff --git a/doc/design/assistant/comment_10_f2233fad55c20686cf299bf6788f1f23._comment b/doc/design/assistant/comment_10_f2233fad55c20686cf299bf6788f1f23._comment
new file mode 100644
index 0000000000..f24357fb64
--- /dev/null
+++ b/doc/design/assistant/comment_10_f2233fad55c20686cf299bf6788f1f23._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://www.klomp.eu/"
+ ip="95.91.241.82"
+ subject="Watch also possible with git?"
+ date="2012-06-15T17:25:30Z"
+ content="""
+Hi,
+
+it seems that you put a lot of efforts in handling race conditions. Thats great. I wonder if the watch can also be used with git (i.e. changes are commited into git and not as annex)? I know that other projects follow this idea but why using different tools if the git-annex assistant could handle both...
+"""]]
diff --git a/doc/design/assistant/comment_11_a38f0f21c2346e65b786d791b6829f9b._comment b/doc/design/assistant/comment_11_a38f0f21c2346e65b786d791b6829f9b._comment
new file mode 100644
index 0000000000..71a9f155d3
--- /dev/null
+++ b/doc/design/assistant/comment_11_a38f0f21c2346e65b786d791b6829f9b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawneJXwhacIb0YvvdYFxhlNVpz6Wpg6V7AA"
+ nickname="Shayne"
+ subject="comment 11"
+ date="2012-08-13T00:37:35Z"
+ content="""
+Yeah definately go with homebrew rather than macports if possible. macports and fink, whilst great systems, have a tendency to sort of create their own alternative-dimension of files within the system that just dont always feel particularly well integrated. As a result \"brew\" has become increasingly more popular to the point its almost ubuquitous now.
+
+Plus its brew-doctor thing is awesome. 
+
+The best approach though thats agnostic to distro systems is to simply go for a generic installer.
+"""]]
diff --git a/doc/design/assistant/comment_12_5e991177d6577384f39a36ae02f5f574._comment b/doc/design/assistant/comment_12_5e991177d6577384f39a36ae02f5f574._comment
new file mode 100644
index 0000000000..b2de673e3c
--- /dev/null
+++ b/doc/design/assistant/comment_12_5e991177d6577384f39a36ae02f5f574._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlu-fdXIt_RF9ggvg4zP0yBbtjWQwHAMS4"
+ nickname="Jörn"
+ subject="Multiple annexes?"
+ date="2012-09-20T16:10:29Z"
+ content="""
+Thank you for this great piece of software which is now becoming even better with the assistant.
+
+Just one question: will one instance of the assistant be able to track multiple git annex repositories each building up their own network of annexes OR would I need to run multiple instances of the assistant?
+
+Thanks,
+Jörn
+"""]]
diff --git a/doc/design/assistant/comment_13_f8625c6f43b58847840df338a73b7972._comment b/doc/design/assistant/comment_13_f8625c6f43b58847840df338a73b7972._comment
new file mode 100644
index 0000000000..c121eaf7f1
--- /dev/null
+++ b/doc/design/assistant/comment_13_f8625c6f43b58847840df338a73b7972._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 13"
+ date="2012-09-20T16:21:11Z"
+ content="""
+@Jörn, two days ago I added support in the webapp for multiple independent repositories. So you can create independent repos using it, and switch between them from a menu. Under the hood there are multiple git-annex assistant daemons running, but this is an implementation detail; it's not like these use any more memory or other resources than would a single daemon that managed multiple repositories.
+"""]]
diff --git a/doc/design/assistant/comment_14_c37ef5931b0f5c1f808083e0d636a208._comment b/doc/design/assistant/comment_14_c37ef5931b0f5c1f808083e0d636a208._comment
new file mode 100644
index 0000000000..b43741febe
--- /dev/null
+++ b/doc/design/assistant/comment_14_c37ef5931b0f5c1f808083e0d636a208._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="you rock! & roadmap update?"
+ date="2012-09-21T04:25:58Z"
+ content="""
+joey, you rock. I just want to push on that point - it doesn't seem like there's that many tools that do what git-annex is trying to do out there, and you seem to be doing an incredible job at doing it, so this is great, keep going!
+
+i was wondering - i am glad to see the progress, but it is unclear to me where you actually are in the roadmap. are things going according to plan? are we at month 3? 4? or 1-4? :) just little updates on that roadmap section above would be quite useful!
+
+thanks again!
+"""]]
diff --git a/doc/design/assistant/comment_15_68c98a27083567f20c2e6bc2a760991b._comment b/doc/design/assistant/comment_15_68c98a27083567f20c2e6bc2a760991b._comment
new file mode 100644
index 0000000000..10b55bbe30
--- /dev/null
+++ b/doc/design/assistant/comment_15_68c98a27083567f20c2e6bc2a760991b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 15"
+ date="2012-09-21T05:25:53Z"
+ content="""
+We're on month 4 of work, and most of months 1-3 is done well enough for a first pass. Very little of what's listed in month 4 has happened yet, due to my being maybe 2 weeks behind schedule, but bits of [[cloud]] are being planned.
+
+I've made a small adjustment, I think it'll make sense to spend a month on user-driven features before getting into Android.
+"""]]
diff --git a/doc/design/assistant/comment_16_8e6788c817c60371d2a2f158e1a65f87._comment b/doc/design/assistant/comment_16_8e6788c817c60371d2a2f158e1a65f87._comment
new file mode 100644
index 0000000000..de5e5b0785
--- /dev/null
+++ b/doc/design/assistant/comment_16_8e6788c817c60371d2a2f158e1a65f87._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~gdr-go2"
+ nickname="gdr-go2"
+ subject="Maybe a DEB?2"
+ date="2012-09-27T09:44:14Z"
+ content="""
+Month 3 was all about easy setup, so I kind of expected to download a deb package and just install it, not to download a whole bunch of haskell libraries. Is there a chance that you will release some packages?
+"""]]
diff --git a/doc/design/assistant/comment_17_97bdfacac5ac492281c9454ee4c0228e._comment b/doc/design/assistant/comment_17_97bdfacac5ac492281c9454ee4c0228e._comment
new file mode 100644
index 0000000000..ea3f50e611
--- /dev/null
+++ b/doc/design/assistant/comment_17_97bdfacac5ac492281c9454ee4c0228e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.141"
+ subject="comment 17"
+ date="2012-09-27T18:44:11Z"
+ content="""
+@gdr A package with the assistant is available in Debian unstable.
+"""]]
diff --git a/doc/design/assistant/comment_18_53137b2df4913496c0afb2d895aa4ee2._comment b/doc/design/assistant/comment_18_53137b2df4913496c0afb2d895aa4ee2._comment
new file mode 100644
index 0000000000..672c2a9d75
--- /dev/null
+++ b/doc/design/assistant/comment_18_53137b2df4913496c0afb2d895aa4ee2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7AuSfii_tCkLyspL6Mr0ATlO6OxLNYOo"
+ nickname="Georg"
+ subject="for OSX, package managers (homebrew and macports) are really second-class"
+ date="2013-07-24T07:24:49Z"
+ content="""
+at least with regards to wide spread use. I agree with Wichert, the average OSX user won't use them. I myself would go with homebrew (because it is far less of a pain than macports), but actually static built binaries that are just dragged from a DMG to your programs folder is the way to go if you can't go osx app store. It's just how most Apple users are wired. PKG would be fine, too, since most will know them, but those are really only needed if you need to place stuff in /Library/Frameworks or things like that. If it can be done as a all-inclusive OSX .app, do it that way and just pack it up in a .DMG.
+"""]]
diff --git a/doc/design/assistant/comment_19_ff1b0ba57e22ed757ec3fc5400b5e43e._comment b/doc/design/assistant/comment_19_ff1b0ba57e22ed757ec3fc5400b5e43e._comment
new file mode 100644
index 0000000000..1ef6136b90
--- /dev/null
+++ b/doc/design/assistant/comment_19_ff1b0ba57e22ed757ec3fc5400b5e43e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlnoH5btjn_BLib3_IhES5uMhrzuOiwCYo"
+ nickname="András"
+ subject="windows port"
+ date="2013-07-25T07:50:19Z"
+ content="""
+I'd love to use the Windows port of the assistant by Christmas. Keep up the good work! :)
+"""]]
diff --git a/doc/design/assistant/comment_1_a48fcfbf97f0a373ea375cd8f07f0fc8._comment b/doc/design/assistant/comment_1_a48fcfbf97f0a373ea375cd8f07f0fc8._comment
new file mode 100644
index 0000000000..646a03398a
--- /dev/null
+++ b/doc/design/assistant/comment_1_a48fcfbf97f0a373ea375cd8f07f0fc8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2012-06-02T12:06:37Z"
+ content="""
+Will statically linked binaries be provided for say Linux, OSX and *BSD?  I think having some statically linked binaries will certainly help and appeal to a lot of users.
+"""]]
diff --git a/doc/design/assistant/comment_20_099da245e3276fa84f5e14312d186621._comment b/doc/design/assistant/comment_20_099da245e3276fa84f5e14312d186621._comment
new file mode 100644
index 0000000000..f423c3e10d
--- /dev/null
+++ b/doc/design/assistant/comment_20_099da245e3276fa84f5e14312d186621._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 20"
+ date="2013-07-25T18:22:51Z"
+ content="""
+@Georg, DMG have been built for OSX for a long time. See [[install/OSX]]
+"""]]
diff --git a/doc/design/assistant/comment_2_6d3552414fdcc2ed3244567e6c67989d._comment b/doc/design/assistant/comment_2_6d3552414fdcc2ed3244567e6c67989d._comment
new file mode 100644
index 0000000000..8056eec168
--- /dev/null
+++ b/doc/design/assistant/comment_2_6d3552414fdcc2ed3244567e6c67989d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 2"
+ date="2012-06-04T19:45:00Z"
+ content="""
+Jimmy, I hope to make it as easy as possible to install. I've been focusing on getting it directly into popular Linux distributions, rather than shipping my own binary. The OSX binary is static, and while I lack a OSX machine, I would like to get it easier to distribute to OSX users.
+"""]]
diff --git a/doc/design/assistant/comment_3_05223be50c889b2ed6bc4abf74116450._comment b/doc/design/assistant/comment_3_05223be50c889b2ed6bc4abf74116450._comment
new file mode 100644
index 0000000000..a78fa33439
--- /dev/null
+++ b/doc/design/assistant/comment_3_05223be50c889b2ed6bc4abf74116450._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 3"
+ date="2012-06-07T20:22:55Z"
+ content="""
+I'd agree getting it into the main distros is the way to go, if you need OSX binaries, I could volunteer to setup an autobuilder to generate binaries for OSX users, however it would rely on users to have macports with the correct ports installed to use it (things like coreutils etc...)
+
+"""]]
diff --git a/doc/design/assistant/comment_4_fbbd93b55803ae21e6ba4b6568c2fafd._comment b/doc/design/assistant/comment_4_fbbd93b55803ae21e6ba4b6568c2fafd._comment
new file mode 100644
index 0000000000..cd3b5aaef7
--- /dev/null
+++ b/doc/design/assistant/comment_4_fbbd93b55803ae21e6ba4b6568c2fafd._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 4"
+ date="2012-06-08T01:56:52Z"
+ content="""
+I always appreciate your OSX work Jimmy...
+
+Could it be put into macports?
+"""]]
diff --git a/doc/design/assistant/comment_5_f4e9af3fed6c27e8ff39badb9794064d._comment b/doc/design/assistant/comment_5_f4e9af3fed6c27e8ff39badb9794064d._comment
new file mode 100644
index 0000000000..bf8d9709e8
--- /dev/null
+++ b/doc/design/assistant/comment_5_f4e9af3fed6c27e8ff39badb9794064d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 5"
+ date="2012-06-08T07:22:34Z"
+ content="""
+In relation to macports, I often found that haskell in macports are often behind other distros, and I'm not willing to put much effort into maintaining or updating those ports. I found that to build git-annex, installing macports manually and then installing haskell-platform from the upstream to be the best way to get the most up to date dependancies for git-annex.
+
+fyi in macports ghc is at version 6.10.4 and haskell platform is at version 2009.2, so there are a significant number of ports to update.
+
+I was thinking about this a bit more and I reckon it might be easier to try and build a self contained .pkg package and have all the needed binaries in a .app styled package, that would work well when the webapp comes along. I will take a look at it in a week or two (currently moving house so I dont have much time)
+"""]]
diff --git a/doc/design/assistant/comment_6_c7ad07cade1f44f9a8b61f92225bb9c5._comment b/doc/design/assistant/comment_6_c7ad07cade1f44f9a8b61f92225bb9c5._comment
new file mode 100644
index 0000000000..9fa66d6d31
--- /dev/null
+++ b/doc/design/assistant/comment_6_c7ad07cade1f44f9a8b61f92225bb9c5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 6"
+ date="2012-06-08T15:21:18Z"
+ content="""
+It's not much for now... but see <http://www.sgenomics.org/~jtang/gitbuilder-git-annex-x00-x86_64-apple-darwin10.8.0/> I'm ignoring the debian-stable and pristine-tar branches for now, as I am just building and testing on osx 10.7.
+
+Hope the autobuilder will help you develop the OSX side of things without having direct access to an osx machine! I will try and get gitbuilder to spit out appropriately named tarballs of the compiled binaries in a few days when I have more time.
+"""]]
diff --git a/doc/design/assistant/comment_7_609d38e993267195a80fecd84c93d1e2._comment b/doc/design/assistant/comment_7_609d38e993267195a80fecd84c93d1e2._comment
new file mode 100644
index 0000000000..6685c6548e
--- /dev/null
+++ b/doc/design/assistant/comment_7_609d38e993267195a80fecd84c93d1e2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.126"
+ subject="comment 7"
+ date="2012-06-09T18:07:51Z"
+ content="""
+Thanks, that's already been useful to me. You might as well skip the debian-specific \"bpo\" tags too.
+"""]]
diff --git a/doc/design/assistant/comment_8_22b818e1a2a825efb78139271a14f944._comment b/doc/design/assistant/comment_8_22b818e1a2a825efb78139271a14f944._comment
new file mode 100644
index 0000000000..57f354e494
--- /dev/null
+++ b/doc/design/assistant/comment_8_22b818e1a2a825efb78139271a14f944._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawldKnauegZulM7X6JoHJs7Gd5PnDjcgx-E"
+ nickname="Matt"
+ subject="Homebrew instead of MacPorts"
+ date="2012-06-22T04:26:02Z"
+ content="""
+[Homebrew] is a much better package manager than MacPorts IMO.
+
+[Homebrew]: http://mxcl.github.com/homebrew/
+"""]]
diff --git a/doc/design/assistant/comment_9_d052e2142da8b4838fb1edf791ea23ae._comment b/doc/design/assistant/comment_9_d052e2142da8b4838fb1edf791ea23ae._comment
new file mode 100644
index 0000000000..5e955c2b6c
--- /dev/null
+++ b/doc/design/assistant/comment_9_d052e2142da8b4838fb1edf791ea23ae._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://wiggy.net/"
+ nickname="Wichert"
+ subject="macports"
+ date="2012-06-12T13:00:34Z"
+ content="""
+The average OSX user has a) no idea what macports is, and b) will not be able to install it. Anything that requires a user to do anything with a commandline (or really anything other than using a GUI installer) is effectively a dealbreaker. For our use cases OSX is definitely a requirement, but it must only use standard OSX installation methods in order to be usable. Being in the appstore would be ideal, but standard dmg/pkg installers are still common enough that they are also acceptable.
+
+FWIW this is the same reason many git GUIs were not usable for our OSX users: they required separate installation of the git commandline tools.
+"""]]
diff --git a/doc/design/assistant/configurators.mdwn b/doc/design/assistant/configurators.mdwn
new file mode 100644
index 0000000000..4d08ac54a9
--- /dev/null
+++ b/doc/design/assistant/configurators.mdwn
@@ -0,0 +1,20 @@
+Add to the [[webapp]] some configuration of git-annex.
+
+There are some basic settings that pass through to `git config`, things
+like how much disk space to leave free, how many copies to ensure are kept
+of files, etc.
+
+The meat of the configuration will be in configuration assistants that walk
+through setting up common use cases.
+
+* Create a repository (run when the web app is started without a configured
+  repository too). **done**
+* Clone this repo to a USB drive or other removable drive. **done**
+* Make a bare repo on a remote ssh server **done**
+* Clone this repo to another host. (Needs [[pairing]]) **done**
+* Set up Amazon S3. **done**
+* Set up encrypted rsync remote. **done**
+* Rsync.net special case **done**
+* Set up gpg encryption key; gpg key distribution.
+* I lost my USB drive!
+* etc -- many more possibilities
diff --git a/doc/design/assistant/deltas.mdwn b/doc/design/assistant/deltas.mdwn
new file mode 100644
index 0000000000..0f7d308b81
--- /dev/null
+++ b/doc/design/assistant/deltas.mdwn
@@ -0,0 +1,27 @@
+Speed up syncing of modified versions of existing files. 
+
+One simple way is to find the key of the old version of a file that's
+being transferred, so it can be used as the basis for rsync, or any
+other similar transfer protocol.
+
+For remotes that don't use rsync, use a rolling checksum based chunker,
+such as BuzHash. This will produce [[chunks]], which can be stored on the
+remote as regular Keys -- where unlike the fixed size chunk keys, the
+SHA256 part of these keys is the checksum of the chunk they contain.
+
+Once that's done, it's easy to avoid uploading chunks that have been sent
+to the remote before.
+
+When retriving a new version of a file, there would need to be a way to get
+the list of chunk keys that constitute the new version. Probably best to
+store this list on the remote. Then there needs to be a way to find which
+of those chunks are available in locally present files, so that the locally
+available chunks can be extracted, and combined with the chunks that need
+to be downloaded, to reconstitute the file.
+
+To find which chucks are locally available, here are 2 ideas:
+
+1. Use a single basis file, eg an old version of the file. Re-chunk it, and
+   use its chunks.  Slow, but simple.
+2. Some kind of database of locally available chunks. Would need to be kept
+   up-to-date as files are added, and as files are downloaded.
diff --git a/doc/design/assistant/deltas/comment_1_bdb477af913c9782c0e8509e6b294b6e._comment b/doc/design/assistant/deltas/comment_1_bdb477af913c9782c0e8509e6b294b6e._comment
new file mode 100644
index 0000000000..3361de4bf1
--- /dev/null
+++ b/doc/design/assistant/deltas/comment_1_bdb477af913c9782c0e8509e6b294b6e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkfHTPsiAcHEEN7Xl7WxiZmYq-vX7azxFY"
+ nickname="Vincent"
+ subject="zsync?"
+ date="2012-09-10T12:35:45Z"
+ content="""
+zsync.moria.org.uk may have broken some of the ground here.
+"""]]
diff --git a/doc/design/assistant/deltas/comment_2_71889d15ba20ebb0fe13080c68162a5b._comment b/doc/design/assistant/deltas/comment_2_71889d15ba20ebb0fe13080c68162a5b._comment
new file mode 100644
index 0000000000..3ef911b776
--- /dev/null
+++ b/doc/design/assistant/deltas/comment_2_71889d15ba20ebb0fe13080c68162a5b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm72W-CH7bzZ8uHvaw1KJGrToPSQDNBnIA"
+ nickname="Beni"
+ subject="bup splitting"
+ date="2013-08-05T17:13:14Z"
+ content="""
+bup splits files into chunks based on rolling sums.
+https://github.com/apenwarr/bup/blob/master/DESIGN
+For small changes to big files, this would improve not only transfer speed but also repository size.
+And git-annex already supports bup remotes.  What's missing?
+"""]]
diff --git a/doc/design/assistant/deltas/comment_3_c60bbe9b280855a583c7c3e48e803760._comment b/doc/design/assistant/deltas/comment_3_c60bbe9b280855a583c7c3e48e803760._comment
new file mode 100644
index 0000000000..dc174163a8
--- /dev/null
+++ b/doc/design/assistant/deltas/comment_3_c60bbe9b280855a583c7c3e48e803760._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="how about for regular key/value storage?"
+ date="2018-12-01T17:42:18Z"
+ content="""
+are there plans to have chunks stored in the regular backend storage?
+
+i'm curious because one my use cases is archiving websites, where we end up with lots of WARC files. those files are basically a bunch of files from the website gzipp'd together in a stream, which means that multiple crawls of the same website (or actually, different website) have *lots* of redundant data (e.g. jQuery.js). storing those files in git-annex is not very efficient, because that data is duplicated all over the place.
+
+if the storage backend was chunked, there could be massive deduplication across those files... this is why i looked at the [[todo/borg_special_remote]]: I figured that i could at least deduplicate on the remote side, but it would still be nice to have this built-in! -- [[anarcat]]
+"""]]
diff --git a/doc/design/assistant/deltas/comment_4_d1728f96202b7113b0671b90ed16473d._comment b/doc/design/assistant/deltas/comment_4_d1728f96202b7113b0671b90ed16473d._comment
new file mode 100644
index 0000000000..8407a7824d
--- /dev/null
+++ b/doc/design/assistant/deltas/comment_4_d1728f96202b7113b0671b90ed16473d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-12-03T16:58:10Z"
+ content="""
+The bup special remote does exist, so if you want to use that special
+remote, you can get efficient storage and transfer of related versions.
+It would probably be possible to make bup use the same git repo as
+git-annex, just storing its data in a separate branch, but I have not tried
+it.
+"""]]
diff --git a/doc/design/assistant/desymlink.mdwn b/doc/design/assistant/desymlink.mdwn
new file mode 100644
index 0000000000..ffa37399dd
--- /dev/null
+++ b/doc/design/assistant/desymlink.mdwn
@@ -0,0 +1,145 @@
+While dropbox allows modifying files in the folder, git-annex freezes
+them upon creation, using symlinks.
+
+This is a core design simplification of git-annex.
+But it is problematic too:
+
+* To allow directly editing files in its folder, something like [[todo/smudge]] is
+  needed, to get rid of the symlinks that stand in for the files.
+* OSX seems to have a [[lot_of_problems|bugs/OSX_alias_permissions_and_versions_problem]]
+  with stupid programs that follow symlinks and present the git-annex
+  hash filename to the user.
+* FAT sucks and doesn't support symlinks at all, so [[Android]] can't
+  have regular repos on it.
+
+One approach for this would be to hide the git repo away somewhere,
+and have the git-annex assistant watch a regular directory, with
+regular files.
+
+There would have to be a mapping from files to git-annex objects.
+And some intelligent way to determine when a file has been changed
+and no longer corresponds to its object. (Not expensive hashing every time,
+plz.)
+
+Since this leaves every file open to modification, any such repository
+probably needs to be considered untrusted by git-annex. So it doesn't
+leave its only copy of a file in such a repository, but instead
+syncs it to a proper git-annex repository.
+
+The assistant would make git commits still, of symlinks. It can already do
+that with without actual symlinks existing on disk. More difficult is
+handling merging; git merge wants a real repository with files it can
+really operate on. The assistant would need to calculate merges on its own,
+and update the regular directory to reflect changes made in the merge.
+
+Another massive problem with this idea is that it doesn't allow for
+[[partial_content]]. The symlinks that everyone loves to hate on are what
+make it possible for the contents of some files to not be present on
+disk, while the files are still in git and can be retreived as desired.
+With real files, some other standin for a missing file would be needed.
+Perhaps a 0 length, unreadable, unwritable file? On systems that
+support symlinks it could be a broken symlink like is used now, that
+is converted to a real file when it becomes present.
+
+## concrete design
+
+* Enable with annex.direct
+* Use .git/ for the git repo, but `.git/annex/objects` won't be used
+  for object storage.
+* `git status` and similar will show all files as type changed, and
+  `git commit` would be a very bad idea. Just don't support users running
+  git commands that affect the repository in this mode. Probably.
+* However, `git status` and similar also will show deleted and new files,
+  which will be helpful for the assistant to use when starting up.
+* Cache the mtime, size etc of files, and use this to detect when they've been
+  modified when the assistant was not running. This would only need to be
+  checked at startup, probably.
+* Use dangling symlinks for standins for missing content, as now.
+  This allows just cloning one of these repositories normally, and then
+  as the files are synced in, they become real files.
+* Maintain a local mapping from keys to files in the tree. This is needed
+  when sending/receiving/dropping keys to know what file to access.
+  Note that a key can map to multiple files. And that when a file is
+  deleted or moved, the mapping needs to be updated.
+* May need a reverse mapping, from files in the tree to keys? TBD
+  (Currently, getting by looking up symlinks using `git cat-file`)
+  (Needed to make things like `git annex drop` that want to map from the
+  file back to the key work.)
+* The existing watch code detects when a file gets closed, and in this
+  mode, it could be a new file, or a modified file, or an unchanged file.
+  For a modified file, can compare mtime, size, etc, to see if it needs
+  to be re-added.
+* The inotify/kqueue interface does not tell us when a file is renamed.
+  So a rename has to be treated as a delete and an add, so can have a lot
+  of overhead, to re-hash the file.
+* Note that this could be used without the assistant, as a git remote
+  that content is transferred to and from. Without the assistant, changes
+  to files in this remote would not be noticed and committed, unless
+  a git-annex command were added to do so.
+  Getting it basically working as a remote would be a good 1st step.
+* It could also be used without the assistant as a repository that
+  the user uses directly. Would need some git-annex commands
+  to merge changes into the repo, update caches, and commit changes.
+  This could all be done by "git annex sync".
+
+## TODO
+
+* kqueue does not deliver an event when an existing file is modified.
+  This doesn't affect OSX, which uses FSEvents now, but it makes direct
+  mode assistant not 100% on other BSD's.
+
+## done
+
+* `git annex sync` updates the key to files mappings for files changed,
+  but needs much other work to handle direct mode:
+  * Generate git commit, without running `git commit`, because it will
+    want to stage the full files. **done**
+  * Update location logs for any files deleted by a commit. **done**
+  * Generate a git merge, without running `git merge` (or possibly running
+    it in a scratch repo?), because it will stumble over the direct files.
+    **done**
+  * Drop contents of files deleted by a merge (including updating the
+    location log), or if we cannot drop,
+    move their contents to `.git/annex/objects/`.  **no**  .. instead, 
+    avoid ever losing file contents in a direct mode merge. If the file is
+    deleted, its content is moved back to .git/annex/objects, if necessary.
+  * When a merge adds a symlink pointing at a key that is present in the
+    repo, replace the symlink with the direct file (either moving out
+    of `.git/annex/objects/` or hard-linking if the same key is present
+    elsewhere in the tree. **done**
+  * handle merge conflicts on direct mode files **done**
+* support direct mode in the assistant (many little fixes)
+
+* Deal with files changing as they're being transferred from a direct mode
+  repository to another git repository. The remote repo currently will 
+  accept the bad data and update the location log to say it has the key.
+
+  This affects both special remotes and git remotes. 
+
+  For special remotes,
+  it seems the best that could be done is to have an error unwind action
+  passed to `sendAnnex` that is called if the file is modified as it's
+  transferred. That would then remove the probably corrupted file from the
+  remote. (The full transfer would still run, unless there was also a way
+  to cancel an in progress transfer.) **done**
+
+  (With the above, there is some potential for the bad content being
+  downloaded from the special remote into another repo. This would only
+  happen if the other repo for some reason thinks the special remote 
+  has the content. Since the location log would not be updated until the
+  transfer is successful, this should not happen.)
+
+  For local git remotes, need to check the direct mode file after it's
+  copied and before it's put into place as a key's content. **done**
+  (untested)
+
+  `git-annex-shell sendkey` needs to do something if it sent bad
+  data. This seems to not need protocol changes; it can just detect 
+  the problem and exit nonzero. Would need to do something to clean up
+  the temp file, which is probably corrupt. (Could in future use it as a
+  basis for transferring the new key..) **done**
+
+  For git remotes, added a flag to `git-annex-shell recvkey` (using a field
+  after the "--" to remain back-compat). With this flag, after receiving
+  the data, the remote fscks the data. This is not optimal, but avoids
+  needing another round-trip, or a protocol change.
diff --git a/doc/design/assistant/desymlink/comment_1_f1bfe250b7f872359f7075998b6e42e3._comment b/doc/design/assistant/desymlink/comment_1_f1bfe250b7f872359f7075998b6e42e3._comment
new file mode 100644
index 0000000000..5e60ff29e0
--- /dev/null
+++ b/doc/design/assistant/desymlink/comment_1_f1bfe250b7f872359f7075998b6e42e3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn-KDr_Z4CMkjS0v_TxQ08SzAB5ecHG3K0"
+ nickname="Glen"
+ subject="Modifying files in a folder watched by assistant"
+ date="2012-09-19T14:18:54Z"
+ content="""
+I think this feature is really important.  For my use cases, if I can't modify files that are in the folder that is kept in sync, then I would just use rsync or manually keep copies on multiple systems..
+
+I might be missing something, but tried a git annex unlock on the file, but if the assistant is running, it seems to revert this back.
+
+"""]]
diff --git a/doc/design/assistant/desymlink/comment_2_5e876edfe9853645f761b5ed9b5021aa._comment b/doc/design/assistant/desymlink/comment_2_5e876edfe9853645f761b5ed9b5021aa._comment
new file mode 100644
index 0000000000..b79ae4781a
--- /dev/null
+++ b/doc/design/assistant/desymlink/comment_2_5e876edfe9853645f761b5ed9b5021aa._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawknpbpx4uDElXRzJ4kPXuJU1KdcslOI6go"
+ nickname="Rodrigo"
+ subject="I strongly agree with Glen"
+ date="2012-10-03T14:07:40Z"
+ content="""
+And if your goal is to build an app \"like dropbox\" it is a must have feature.
+Thanks for your work. You are doing great!
+"""]]
diff --git a/doc/design/assistant/desymlink/comment_3_538561d74371e53c2f8df7f5ebdf58a8._comment b/doc/design/assistant/desymlink/comment_3_538561d74371e53c2f8df7f5ebdf58a8._comment
new file mode 100644
index 0000000000..40067b25bb
--- /dev/null
+++ b/doc/design/assistant/desymlink/comment_3_538561d74371e53c2f8df7f5ebdf58a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.149"
+ subject="comment 3"
+ date="2012-10-05T00:43:11Z"
+ content="""
+@Glen, for what it's worth, you can now manually \"git annex unlock\" a file and it'll stay unlocked until you manually \"git annex add\" the new version.
+"""]]
diff --git a/doc/design/assistant/desymlink/comment_4_586ecaa800e6c162377c937da5e65440._comment b/doc/design/assistant/desymlink/comment_4_586ecaa800e6c162377c937da5e65440._comment
new file mode 100644
index 0000000000..aeb1587edc
--- /dev/null
+++ b/doc/design/assistant/desymlink/comment_4_586ecaa800e6c162377c937da5e65440._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlJEI45rGczFAnuM7gRSj4C6s9AS9yPZDc"
+ nickname="Kevin"
+ subject="unlock not behaving as you describe"
+ date="2012-11-05T22:35:35Z"
+ content="""
+@joeyh,
+
+I'm not seeing the behavior you describe re \"git annex unlock\" when using the assistant.  After unlocking and writing the file, git annex assistant commits the changes and recreates the symlink from under me which is annoying.
+
+I'm running OS X 10.7.5 using the bundled git-annex.app version 3.20121017.
+"""]]
diff --git a/doc/design/assistant/desymlink/comment_5_8fc703de67814cf2aec2a908852298a4._comment b/doc/design/assistant/desymlink/comment_5_8fc703de67814cf2aec2a908852298a4._comment
new file mode 100644
index 0000000000..ca43615326
--- /dev/null
+++ b/doc/design/assistant/desymlink/comment_5_8fc703de67814cf2aec2a908852298a4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 5"
+ date="2012-11-05T23:40:50Z"
+ content="""
+Well, you're able to unlock and modify the file -- that's what I fixed.
+
+Committing changes to files is what the assistant does..
+"""]]
diff --git a/doc/design/assistant/desymlink/comment_6_1b473ad89494afb82250af4b6df5f5c9._comment b/doc/design/assistant/desymlink/comment_6_1b473ad89494afb82250af4b6df5f5c9._comment
new file mode 100644
index 0000000000..fad9cbe984
--- /dev/null
+++ b/doc/design/assistant/desymlink/comment_6_1b473ad89494afb82250af4b6df5f5c9._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 6"
+ date="2012-12-03T05:33:44Z"
+ content="""
+> One approach for this would be to hide the git repo away somewhere, and have the git-annex assistant watch a regular directory, with regular files.
+
+I think this would be the single most important feature added to git-annex.
+1. It could be used to backup regularly a smb share over the network.
+2. For those who dont trust a program who modifies their files directly. 
+(I had a 3GB permanent data loss, when trying to push a 10GB directory into git annex.)
+3. Android 
+
+I do hope the above method will be implemented for Android too, so its like two birds with one stone. 
+(Im really for option 2 here. I dont like the very idea of modifying my files directly. 
+Git does not do it either, I have disk space (if not I buy more disks), rather then risquing losing important datas)
+
+Best, 
+ Laszlo
+
+"""]]
diff --git a/doc/design/assistant/disaster_recovery.mdwn b/doc/design/assistant/disaster_recovery.mdwn
new file mode 100644
index 0000000000..6fcf955195
--- /dev/null
+++ b/doc/design/assistant/disaster_recovery.mdwn
@@ -0,0 +1,185 @@
+The assistant should help the user recover their repository when things go
+wrong.
+
+[[!toc ]]
+
+## dangling lock files
+
+There are a few ways a git repository can get broken that are easily fixed.
+One is left over index.lck files. When a commit to a repository fails,
+check that nothing else is using it, fix the problem, and redo the commit.
+
+* **done** for .git/annex/index.lock, can be handled safely and automatically.
+* **done** for .git/index.lock, only when the assistant is starting up.
+* What about local remotes, eg removable drives? git-annex does attempt
+  to commit to the git-annex branch of those. It will use the automatic
+  fix if any are dangling. It does not commit to the master branch; indeed
+  a removable drive typically has a bare repository.
+  However, it does a scan for broken locks anyway if there's a problem
+  syncing. **done**
+* What about git-annex-shell? If the ssh remote has the assistant running,
+  it can take care of it, and if not, it's a server, and perhaps the user
+  should be required to fix up if it crashes during a commit. This should
+  not affect the assistant anyway.
+* **done** Seems that refs can also have stale lock files, for example
+  '/storage/emulated/legacy/DCIM/.git/refs/remotes/flick_phonecamera/synced/git-annex.lock'
+  All git lock files are now handled (except gc lock files).
+
+## incremental fsck
+
+Add webapp UI to enable incremental fsck **done**
+
+Of course, incremental fsck will run as an niced (and ioniced) background
+job. There will need to be a button in the webapp to stop it, in case it's
+annoying. **done**
+
+When fsck finds a damanged file, queue a download of the file from a
+remote. **done**
+
+Detect when a removable drive is connected in the Cronner, and check
+and try to run its remote fsck jobs. **done** (Same mechanism will work for
+network remotes becoming connected.)
+
+TODO: If no accessible remote has a file that fsck reported missing,
+prompt the user to eg, connect a drive containing it. Or perhaps this is a
+special case of a general problem, and the webapp should prompt the user
+when any desired file is available on a remote that's not mounted?
+
+## git-annex-shell remote fsck
+
+TODO: git-annex-shell fsck support, which would allow cheap fast fscks
+of ssh remotes.
+
+Would be nice; otherwise remote fsck is too expensive (downloads
+everything) to have the assistant do.
+
+Note that Remote.Git already tries to use this, but the assistant does not
+call it for non-local remotes.
+
+## git fsck and repair
+
+Add git fsck to scheduled self fsck **done**
+
+TODO: git fsck on ssh remotes? Probably not worth the complexity..
+
+TODO: If committing to the repository fails, after resolving any dangling
+lock files (see above), it should git fsck. This is difficult, because
+git commit will also fail if the commit turns out to be empty, or due to
+other transient problems.. So commit failures are currently ignored by the
+assistant.
+
+If git fsck finds problems, launch git repository repair. **done**
+
+git annex fsck --fast at end of repository repair to ensure
+git-annex branch is accurate. **done**
+
+If syncing with a local repository fails, try to repair it. **done**
+
+TODO: "Repair" gcrypt remotes, by removing all refs and objects,
+and re-pushing. (Since the objects are encrypted data, there is no way
+to pull missing ones from anywhere..) 
+Need to preserve gcrypt-id while doing this!
+
+TODO: along with displaying alert when there is a problem detected
+by consistency check, send an email alert. (Using system MTA?)
+
+## nudge user to schedule fscks
+
+Make the webapp encourage users to schedule fscks of their
+local repositories. The goal here was that it should not be obnoxious about
+repeatedly pestering the user to set that up, but should still encourage
+anyone who cares to set it up.
+
+Maybe: Display a message only once per week, and only after the repository
+has existed for at least one full day. But, this will require storing
+quite a lot of state.
+
+Or: Display a message whenever a removable drive is detected to have been
+connected. I like this, but what about nudging the main repo? Could do it
+every webapp startup, perhaps? **done**
+
+There should be a "No thanks" button that prevents it nudging again for a
+repo. **done**
+
+## git repository repair
+
+There are several ways git repositories can get damanged. 
+
+The most common is empty files in .git/annex/objects and commits that refer
+to those objects. When the objects have not yet been pushed anywhere.
+I've several times recovered from this manually by
+removing the bad files and resetting to before the commits that referred to
+them. Then re-staging any divergence in the working tree. This could
+perhaps be automated.
+
+As long as the git repository has at least one remote, another method is to
+clone the remote, sync from all other remotes, move over .git/config and
+.git/annex/objects, and tar up the old broken git repo and `git annex add`
+it. This should be automatable and get the user back on their feet. User
+could just click a button and have this be done.
+
+This is useful outside git-annex as well, so make it a
+git-recover-repository command.
+
+### detailed design
+
+Run `git fsck` and parse output to find bad objects. **done** Note that
+fsck may fall over and fail to print out all bad objects, when
+files are corrupt. So if the fsck exits nonzero, need to collect all
+bad objects it did find, and:
+
+1. If the local repository contains packs, the packs may be corrupt.
+   So, start by using `git unpack-objects` to unpack all
+   packs it can handle (which may include parts of corrupt packs) 
+   back to loose objects. And delete all packs. **done**
+2. Delete all loose corrupt objects. **done**
+
+Repeat until fsck finds no new problems. **done**
+
+Check if there's a remote. If so, and if the bad objects are all
+present on it, can simply get all bad objects from the remote,
+and inject them back into .git/objects to recover:
+
+3. Make a new (bare) clone from the remote.
+   (Note: git does not seem to provide a way to fetch specific missing
+   objects from the remote. Also, cannot use `--reference` against
+   a repository with missing refs. So this seems unavoidably
+   network-expensive.) **done**
+5. Rsync objects over. (Turned out to work better than git-cat-file, 
+   because we don't have to walk the graph to add missing objects.)
+   **done**
+6. If each bad object was able to be repaired this way, we're done!
+   (If not, can reuse the clone for getting objects from the next remote.)
+   **done**
+
+If some missing objects cannot be recovered from remotes, find commits in each
+local branch that are broken by all remaining missing objects. Some of this can
+be parsed from git fsck output, but for eg blobs, the commits need to
+be walked to walk the trees, to find trees that refer to the blobs. **done**
+
+For each branch that is affected, look in the reflog and/or `git log
+$branch` to find the last good commit that predates all broken commits. (If
+the head commit of a branch is broken, git log is not going to show
+anything useful, but the reflog can be used to find past refs for the
+branch -- have to first delete the .git/HEAD file if it points to the
+broken ref.) **done**
+
+The basic idea then is to reset the branch to the last good commit
+that was found for it.
+
+* For the HEAD branch, can just reset it. (If no last good commit was found
+  for the HEAD branch, reset it to a dummy empty commit.) This will
+  leave git showing any changes made since then as staged in the index and
+  uncommitted. Or if the index is missing/corrupt, any files in the tree will
+  show as modified and uncommitted. User (or git-annex assistant) can then
+  commit as appropriate. Print appropriate warning message. **done**
+* Special handling for git-annex branch and index. **done**
+* Remote tracking branches can just be removed, and then `git fetch`
+  from the remote, which will re-download missing objects from it and
+  reinstate the tracking branch. **done**
+* For other branches, reset them to last good commit, or delete
+  if none was found. **done**
+* (Decided not to touch tags.)
+
+The index file can still refer to objects that were missing.
+Rewrite to remove them. **done**
diff --git a/doc/design/assistant/disaster_recovery/comment_1_955dc807196863da23aa8dbd15e04364._comment b/doc/design/assistant/disaster_recovery/comment_1_955dc807196863da23aa8dbd15e04364._comment
new file mode 100644
index 0000000000..63c7e942d9
--- /dev/null
+++ b/doc/design/assistant/disaster_recovery/comment_1_955dc807196863da23aa8dbd15e04364._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://nullroute.eu.org/~grawity/"
+ nickname="Mantas"
+ subject="comment 1"
+ date="2013-10-19T15:50:47Z"
+ content="""
+The restriction on fetching over the Git protocol is, partly, for security reasons – e.g. if one accidentally pushes a commit with private data, and then `push --force`'s a cleaned-up version, Git needs to prevent anyone from downloading the old commit by just giving its SHA1 (e.g. obtained from an IRC/email push notification). So it restricts fetching to the tips of any ref. (I've been told that it could check if the given object is merely *reachable* from any ref, but it doesn't do so for performance reasons.)
+
+git 1.8 has a minor way to relax this requirement – it allows giving a SHA1 to `git fetch` (although I think the protocol already worked this way), and it allows refs to be hidden server-side but still remain fetchable, so in theory there could be a (hidden) ref for every object, for easy fetching...
+"""]]
diff --git a/doc/design/assistant/encrypted_git_remotes.mdwn b/doc/design/assistant/encrypted_git_remotes.mdwn
new file mode 100644
index 0000000000..b7e817cff4
--- /dev/null
+++ b/doc/design/assistant/encrypted_git_remotes.mdwn
@@ -0,0 +1,22 @@
+Encrypted git remotes are now possible 
+using [git-remote-gcrypt](https://spwhitton.name/tech/code/git-remote-gcrypt/).
+
+There are at least two use cases for this in the assistant:
+
+* Storing an encrypted git repository on a local drive. **done**
+* Or on a remote server. This could even allow using github. But more
+  likely would be a shell server that has git-annex-shell on it so can
+  also store file contents, and which is not trusted with unencrypted data.
+  **done**
+
+git-remote-gcrypt is already usable with git-annex. What's needed is
+to make sure it's installed (ie, get it packaged into distros or embedded
+into git-annex), and make it easy to set up from the webapp. **done**
+
+Hmm, this will need gpg key creation, so would also be a good opportunity
+to make the webapp allow using that for special remotes too.
+
+One change is needed in git-annex core.. It currently does not support
+storing encrypted files on git remotes, only on special remotes. Perhaps
+the way to deal with this is to make it consider git-remote-grypt remotes
+to be a special remote type? **done**
diff --git a/doc/design/assistant/gpgkeys.mdwn b/doc/design/assistant/gpgkeys.mdwn
new file mode 100644
index 0000000000..9d1254eb93
--- /dev/null
+++ b/doc/design/assistant/gpgkeys.mdwn
@@ -0,0 +1,40 @@
+Currently the assistant sets up a shared encryption key, which is checked
+into git, so anyone who gets the repository can decrypt files that are
+stored encrypted on special remotes.
+
+To support using gpg keys in the assistant, we need some things:
+
+1. Help user set up a gpg key if they don't have one. This could be a
+   special-purpose key dedicated to being used by git-annex. It might be
+   nice to leave the user with a securely set up general purpose key,
+   but that would certainly preclude prompting for its password in the
+   webapp. Indeed, the password prompt is the main problem here.
+   Best solution would be to get gpg agent working on all supported 
+   platforms.
+
+   Update: For now, git-annex only assists in generating gpg keys that are
+   intended to only be used to encrypt a repo.
+
+2. After generating a gpg key, back it up. It might be the only way
+   some data is accessible.
+
+   One way I'm considering is generating a QR code
+   of the key, which could be printed to paper. Preliminary results
+   are good; a 4096 bit secret key fits in a QR code (a secret key
+   with many subkeys may not). Debian has command-line utilities that
+   can generate and read such a QR code.
+
+   Another way would be to use shamir secret sharing to split the key into
+   N peices and send each one to one of the user's repos.
+
+3. Help user learn the gpg keys of people they want to share their repo
+   with, and give them access. If the public key was recorded in the git-annex
+   branch, this could be easily determined when sharing repositories with
+   friends. Or, use MonkeySphere, or Monkeysign..
+
+-----
+
+Another gpg key security thing is that currently git-annex stores
+crypto creds in memory while it's running. Should use locked memory. See
+<https://github.com/vincenthz/hs-securemem> and
+<https://github.com/vincenthz/hs-securemem/issues/1>
diff --git a/doc/design/assistant/gpgkeys/comment_1_a14427f88c9fd8e25ad8708146bb4bff._comment b/doc/design/assistant/gpgkeys/comment_1_a14427f88c9fd8e25ad8708146bb4bff._comment
new file mode 100644
index 0000000000..610f9bbb67
--- /dev/null
+++ b/doc/design/assistant/gpgkeys/comment_1_a14427f88c9fd8e25ad8708146bb4bff._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="gernot"
+ ip="85.197.15.125"
+ subject="Paperkey"
+ date="2013-12-05T11:37:02Z"
+ content="""
+Regarding backups, have you considered using [paperkey](http://www.jabberwocky.com/software/paperkey/) (also [in Debian](http://packages.debian.org/search?keywords=paperkey))?
+It only stores a minimal amount of key data and formats it in a human-readable way.
+
+The result is mainly meant to be printed but `paperkey` would probably also be a good way to keep the size of QR codes down.
+
+I've actually recovered a key from a such a printed backup (using OCR) and it worked great thanks to line-wise checksums.
+Maybe you could create paperkey PDF files with a proper OCR font through the web app?
+
+"""]]
diff --git a/doc/design/assistant/inotify.mdwn b/doc/design/assistant/inotify.mdwn
new file mode 100644
index 0000000000..c951f4fe2a
--- /dev/null
+++ b/doc/design/assistant/inotify.mdwn
@@ -0,0 +1,234 @@
+"git annex watch" command, which runs, in the background, watching via
+inotify for changes, and automatically annexing new files, etc. Now
+available!
+
+[[!toc]]
+
+## known bugs
+
+* Kqueue has to open every directory it watches, so too many directories
+  will run it out of the max number of open files (typically 1024), and fail.
+  I may need to fork off multiple watcher processes to handle this.
+  See [[bug|bugs/Issue_on_OSX_with_some_system_limits]]. (Does not affect
+  OSX any longer, only other BSDs).
+
+## beyond Linux
+
+I'd also like to support OSX and if possible the BSDs.
+
+* kqueue ([haskell bindings](http://hackage.haskell.org/package/kqueue))
+  is supported by FreeBSD, OSX, and other BSDs.
+
+  In kqueue, to watch for changes to a file, you have to have an open file
+  descriptor to the file. This wouldn't scale. 
+
+  Apparently, a directory can be watched, and events are generated when
+  files are added/removed from it. You then have to scan to find which
+  files changed. [example](https://developer.apple.com/library/mac/#samplecode/FileNotification/Listings/Main_c.html#//apple_ref/doc/uid/DTS10003143-Main_c-DontLinkElementID_3)
+
+  Gamin does the best it can with just kqueue, supplimented by polling.
+  The source file `server/gam_kqueue.c` makes for interesting reading.
+  Using gamin to do the heavy lifting is one option. 
+  ([haskell bindings](http://hackage.haskell.org/package/hlibfam) for FAM;
+  gamin shares the API)
+
+  kqueue does not seem to provide a way to tell when a file gets closed,
+  only when it's initially created. Poses problems..
+
+  * [man page](http://www.freebsd.org/cgi/man.cgi?query=kqueue&apropos=0&sektion=0&format=html)
+  * <https://github.com/gorakhargosh/watchdog/blob/master/src/watchdog/observers/kqueue.py> (good example program)
+
+  *kqueue is now supported*
+
+* hfsevents ([haskell bindings](http://hackage.haskell.org/package/hfsevents))
+  is OSX specific.
+
+  Originally it was only directory level, and you were only told a
+  directory had changed and not which file. Based on the haskell
+  binding's code, from OSX 10.7.0, file level events were added.
+
+  This will be harder for me to develop for, since I don't have access to
+  OSX machines..
+
+  hfsevents does not seem to provide a way to tell when a file gets closed,
+  only when it's initially created. Poses problems..
+
+  * <https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/Introduction.html>
+  * <http://pypi.python.org/pypi/MacFSEvents/0.2.8> (good example program)
+  * <https://github.com/gorakhargosh/watchdog/blob/master/src/watchdog/observers/fsevents.py> (good example program)
+
+  *hfsevents is now supported*
+
+* Windows has a Win32 ReadDirectoryChangesW, and perhaps other things.
+
+  It was easy to get watching to work in windows. But there is no lsof,
+  to check if a file can safely be added. So, need to carefully consider
+  how to make adding a file safe in windows.
+
+  Without lsof, an InodeCache is generated in "lockdown" (which doesn't
+  do anything to prevent new writers), and is compared with the stat of the
+  file after it's ingested (and checksummed). This will detect many changes
+  to files, which change the size or mtime.
+
+  So, we have 2 cases to worry about. 
+
+  1. A process has the file open for write as it's added, does not change
+     it until the add is done.
+
+     As long as an event is generated once the file does get closed, this
+     is fine -- the modified version will be re-added. And such events are
+     indeed generated on windows.
+
+  2. A process has the file open for write as it's added, and changes it 
+     in some way that does not affect size or mtime.
+
+     If an event is generated when the file does get closed, this is the
+     same as a scenario where a process opens the file after it's added,
+     makes such a change, and closes it. In either case, a file closed
+     event is generated, and the Watcher will not detect any change
+     using the inode cache, so will not re-add the file.
+
+     So, this scenario is a potential problem, but it seems at least
+     unlikely that a program would modify a file without affecting its
+     mtime. Note that this same scenario can happen even with lsof, and
+     even on linux (although on linux the InodeCache includes an actual
+     inode, which might detect the change too).
+
+  Conclusion: It's probably ok to run without lsof on Windows.
+
+  Corrolary: lsof might not generally be needed in direct mode, on
+  systems that do generate file close events (but not when
+  eventsCoalesce).
+  The same arguments given above seem to apply to !Windows. Note that lsof
+  is needed in indirect mode, as discussed below.
+
+  **windows is now supported**
+
+## the races
+
+Many races need to be dealt with by this code. Here are some of them.
+
+* File is added and then removed before the add event starts.
+
+  Not a problem; The add event does nothing since the file is not present.
+
+* File is added and then removed before the add event has finished
+  processing it.
+  
+  **Minor problem**; When the add's processing of the file (checksum and so
+  on) fails due to it going away, there is an ugly error message, but
+  things are otherwise ok.
+
+* File is added and then replaced with another file before the annex add
+  moves its content into the annex.
+
+  Fixed this problem; Now it hard links the file to a temp directory and
+  operates on the hard link, which is also made unwritable.
+
+* File is added and then replaced with another file before the annex add
+  makes its symlink.
+
+  **Minor problem**; The annex add will fail creating its symlink since
+  the file exists. There is an ugly error message, but the second add
+  event will add the new file.
+
+* File is added and then replaced with another file before the annex add
+  stages the symlink in git.
+
+  Now fixed; `git annex watch` avoids running `git add` because of this
+  race. Instead, it stages symlinks directly into the index, without
+  looking at what's currently on disk.
+
+* Link is moved, fixed link is written by fix event, but then that is
+  removed by the user and replaced with a file before the event finishes.
+
+  Now fixed; same fix as previous race above.
+
+* File is removed and then re-added before the removal event starts.
+
+  Not a problem; The removal event does nothing since the file exists,
+  and the add event replaces it in git with the new one.
+
+* File is removed and then re-added before the removal event finishes.
+
+  Not a problem; The removal event removes the old file from the index, and
+  the add event adds the new one.
+
+* Symlink appears, but is then deleted before it can be processed.
+
+  Leads to an ugly message, otherwise no problem:
+
+	./me: readSymbolicLink: does not exist (No such file or directory)
+
+  Here `me` is a file that was in a conflicted merge, which got
+  removed as part of the resolution. This is probably coming from the watcher
+  thread, which sees the newly added symlink (created by the git merge),
+  but finds it deleted (by the conflict resolver) by the time it processes it.
+
+## done
+
+- on startup, add any files that have appeared since last run **done**
+- on startup, fix the symlinks for any renamed links **done**
+- on startup, stage any files that have been deleted since last run
+  (seems to require a `git commit -a` on startup, or at least a
+  `git add --update`, which will notice deleted files) **done**
+- notice new files, and git annex add **done**
+- notice renamed files, auto-fix the symlink, and stage the new file location
+  **done**
+- handle cases where directories are moved outside the repo, and stop
+  watching them **done**
+- when a whole directory is deleted or moved, stage removal of its
+  contents from the index **done**
+- notice deleted files and stage the deletion
+  (tricky; there's a race with add since it replaces the file with a symlink..)
+  **done**
+- Gracefully handle when the default limit of 8192 inotified directories
+  is exceeded. This can be tuned by root, so help the user fix it.
+  **done**
+- periodically auto-commit staged changes (avoid autocommitting when
+  lots of changes are coming in) **done**
+- coleasce related add/rm events for speed and less disk IO **done**
+- don't annex `.gitignore` and `.gitattributes` files **done**
+- run as a daemon **done**
+- A process has a file open for write, another one closes it,
+  and so it's added. Then the first process modifies it.
+
+  Or, a process has a file open for write when `git annex watch` starts
+  up, it will be added to the annex. If the process later continues
+  writing, it will change content in the annex.
+
+  This changes content in the annex, and fsck will later catch
+  the inconsistency.
+
+  Possible fixes: 
+
+  * Somehow track or detect if a file is open for write by any processes.
+    `lsof` could be used, although it would be a little slow.
+
+    Here's one way to avoid the slowdown: When a file is being added,
+    set it read-only, and hard-link it into a quarantine directory,
+    remembering both filenames.
+    Then use the batch change mode code to detect batch adds and bundle
+    them together.
+    Just before committing, lsof the quarantine directory. Any files in
+    it that are still open for write can just have their write bit turned
+    back on and be deleted from quarantine, to be handled when their writer
+    closes. Files that pass quarantine get added as usual. This avoids
+    repeated lsof calls slowing down adds, but does add a constant factor
+    overhead (0.25 seconds lsof call) before any add gets committed. **done**
+
+  * Or, when possible, making a copy on write copy before adding the file
+    would avoid this.
+  * Or, as a last resort, make an expensive copy of the file and add that.
+  * Tracking file opens and closes with inotify could tell if any other
+    processes have the file open. But there are problems.. It doesn't
+    seem to differentiate between files opened for read and for write.
+    And there would still be a race after the last close and before it's
+    injected into the annex, where it could be opened for write again.
+    Would need to detect that and undo the annex injection or something.
+
+- If a file is checked into git as a normal file and gets modified
+  (or merged, etc), it will be converted into an annexed file.
+  See [[blog/day_7__bugfixes]]. **done**; we always check ls-files now
+- When you `git annex unlock` a file, it will immediately be re-locked.
+  See [[bugs/watcher_commits_unlocked_files]]. Seems fixed now?
diff --git a/doc/design/assistant/inotify/comment_1_3d3ff74447452d65c10ccc3dbfc323cd._comment b/doc/design/assistant/inotify/comment_1_3d3ff74447452d65c10ccc3dbfc323cd._comment
new file mode 100644
index 0000000000..d042806a17
--- /dev/null
+++ b/doc/design/assistant/inotify/comment_1_3d3ff74447452d65c10ccc3dbfc323cd._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://ciffer.net/~svend/"
+ subject="comment 1"
+ date="2012-06-04T19:42:07Z"
+ content="""
+I would find it useful if the watch command could 'git add' new files (instead of 'git annex add') for certain repositories.
+"""]]
diff --git a/doc/design/assistant/inotify/comment_2_a3c0fa6d97397c508b4b8aafdcee8f6f._comment b/doc/design/assistant/inotify/comment_2_a3c0fa6d97397c508b4b8aafdcee8f6f._comment
new file mode 100644
index 0000000000..13ee1523c3
--- /dev/null
+++ b/doc/design/assistant/inotify/comment_2_a3c0fa6d97397c508b4b8aafdcee8f6f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 2"
+ date="2012-06-04T19:46:03Z"
+ content="""
+I think it's already on the list: \"configurable option to only annex files meeting certian size or filename criteria\" -- files not meeting those criteria would just be git added.
+"""]]
diff --git a/doc/design/assistant/inotify/comment_3_b346e870c1cd80e4b0a313c3a9fed6b3._comment b/doc/design/assistant/inotify/comment_3_b346e870c1cd80e4b0a313c3a9fed6b3._comment
new file mode 100644
index 0000000000..c1f22c4b8a
--- /dev/null
+++ b/doc/design/assistant/inotify/comment_3_b346e870c1cd80e4b0a313c3a9fed6b3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 3"
+ date="2012-06-17T08:52:32Z"
+ content="""
+In relation to OSX support, hfsevents (or supporting hfs is probably a bad idea), its very osx specific and users who are moving usb keys and disks between systems will probably end up using fat32/exfat/vfat disks around. Also if you want I can lower the turn around time for the OSX auto-builder that I have setup to every 1 or 2mins? would that help?
+"""]]
diff --git a/doc/design/assistant/inotify/comment_4_32be58b4c3b17a4ea539690d2fb45159._comment b/doc/design/assistant/inotify/comment_4_32be58b4c3b17a4ea539690d2fb45159._comment
new file mode 100644
index 0000000000..d854d91c2b
--- /dev/null
+++ b/doc/design/assistant/inotify/comment_4_32be58b4c3b17a4ea539690d2fb45159._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.2.147"
+ subject="comment 4"
+ date="2012-06-17T16:39:43Z"
+ content="""
+hfsevents seems usable, git-annex does not need to watch for file changes on remotes on other media.
+
+But, trying kqueue first.
+
+You could perhaps run the autobuilder on a per-commit basis..
+"""]]
diff --git a/doc/design/assistant/inotify/comment_5_0cdd3046d90ad2012025d846ece0731e._comment b/doc/design/assistant/inotify/comment_5_0cdd3046d90ad2012025d846ece0731e._comment
new file mode 100644
index 0000000000..8b075c36f0
--- /dev/null
+++ b/doc/design/assistant/inotify/comment_5_0cdd3046d90ad2012025d846ece0731e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 5"
+ date="2012-06-17T21:42:59Z"
+ content="""
+okay, I've gotten gitbuilder to poll the git repo every minute for changes, gitbuilder doesn't build every commit. It doesn't work like that, it checks out the master and builds that. If there is a failure it automatically bisects to find out where the problem first got introduced. Hope the change to the builder helps!
+"""]]
diff --git a/doc/design/assistant/inotify/comment_6_e197d5d0d853572ec1f2e5985762e60d._comment b/doc/design/assistant/inotify/comment_6_e197d5d0d853572ec1f2e5985762e60d._comment
new file mode 100644
index 0000000000..76716ddda5
--- /dev/null
+++ b/doc/design/assistant/inotify/comment_6_e197d5d0d853572ec1f2e5985762e60d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnV2c63kDc6X21a1H81me1mIenUCScd2Gs"
+ nickname="Emanuele"
+ subject="watch branch?"
+ date="2012-06-01T19:19:17Z"
+ content="""
+Hello there? Where can I find more info about this git watch branch? 
+Keep up the good work!
+"""]]
diff --git a/doc/design/assistant/inotify/comment_7_00809aaad6b68f189a9cc42af810a0a6._comment b/doc/design/assistant/inotify/comment_7_00809aaad6b68f189a9cc42af810a0a6._comment
new file mode 100644
index 0000000000..7e1ad7db5c
--- /dev/null
+++ b/doc/design/assistant/inotify/comment_7_00809aaad6b68f189a9cc42af810a0a6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnwfqF4wL6l_O26RyzoBowUMvQ_955Vpao"
+ nickname="Markus"
+ subject="comment 7"
+ date="2014-06-14T06:29:55Z"
+ content="""
+FWIW: Removing the [raspi-copies-and-fills](https://github.com/simonjhall/copies-and-fills) package ('apt-get purge raspi-copies-and-fills') stops annex from printing the message over and over again. According to the package's description though, you suffer a performance penalty without the package.
+"""]]
diff --git a/doc/design/assistant/leftovers.mdwn b/doc/design/assistant/leftovers.mdwn
new file mode 100644
index 0000000000..b8c0f456b6
--- /dev/null
+++ b/doc/design/assistant/leftovers.mdwn
@@ -0,0 +1,17 @@
+Things that don't fit anywhere else:
+
+* Automatically start daemon on boot or when user logs in, using
+  freedesktop autostart file. **done**
+* Somehow get content that is unavailable. This is problematic with inotify,
+  since we only get an event once the user has tried (and failed) to read
+  from the file. This is only needed if all the files in the directory 
+  are not kept synced, but in some situations (ie, low disk space phones),
+  that is likely.
+* Drop files that have not been used lately, or meet some other criteria
+  (as long as there's a copy elsewhere). **done** (via preferred content;
+  eg archive directories)
+* Perhaps automatically dropunused files that have been deleted,
+  although I cannot see a way to do that, since by the time the inotify
+  deletion event arrives, the file is deleted, and we cannot see what
+  its symlink pointed to! Alternatively, perhaps automatically
+  do an expensive unused/dropunused cleanup process.
diff --git a/doc/design/assistant/leftovers/comment_1_b20c88bb3c583a32023c1f6b6dc9486d._comment b/doc/design/assistant/leftovers/comment_1_b20c88bb3c583a32023c1f6b6dc9486d._comment
new file mode 100644
index 0000000000..3c7e1820db
--- /dev/null
+++ b/doc/design/assistant/leftovers/comment_1_b20c88bb3c583a32023c1f6b6dc9486d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2012-10-30T09:07:37Z"
+ content="""
+I think the automatic dropunused part is handled by the assistant already anyway, but in case it's not: The git repo still knows where the symlink pointed to so it should not be a problem to get that info from the last commit that was 'actively' locally and which contained said symlink.
+"""]]
diff --git a/doc/design/assistant/more_cloud_providers.mdwn b/doc/design/assistant/more_cloud_providers.mdwn
new file mode 100644
index 0000000000..bad5d16ac6
--- /dev/null
+++ b/doc/design/assistant/more_cloud_providers.mdwn
@@ -0,0 +1,22 @@
+Git-annex already supports storing large files in 
+several cloud providers via [[special_remotes]].
+More should be added, such as:
+
+* Google drive (attractive because it's free, only 5 gb tho)
+* Owncloud (has several [providers](http://owncloud.org/providers/);
+  at least one provides 5 gb free; open DAV based API)
+* OpenStack Swift (teh future)
+* Box.com (it's free, and current method is hard to set up and a sorta
+  shakey; a better method would be to use its API) **done**
+* Dropbox? That would be ironic.. Via its API, presumably.
+* [[Amazon Glacier|todo/special_remote_for_amazon_glacier]] **done**
+* Internet Archive **done**
+* Mediafire provides 50gb free and has a REST API.
+* Flickr provides 1 tb (!!!!) to free accounts, and can store at least
+  photos and videos. <https://github.com/ricardobeat/filr> is a hack
+  to allow storing any type of file on Flickr.
+* mega.co.nz. Already supported via [[tips/megaannex]], would just need
+  webapp modifications to configure it. May want to use megaannex as-is to
+  build a non-hook special remote in haskell.
+
+See poll at [[polls/prioritizing_special_remotes]].
diff --git a/doc/design/assistant/pairing.mdwn b/doc/design/assistant/pairing.mdwn
new file mode 100644
index 0000000000..d09c644ee7
--- /dev/null
+++ b/doc/design/assistant/pairing.mdwn
@@ -0,0 +1,83 @@
+For git-annex to be able to clone its repo to another host, it'd be good to
+have some way of pairing devices.
+
+## security
+
+Pairing uses its own network protocol, built on top of multicast UDP.
+
+It's important that pairing securely verifies that the right host is being
+paired with. This is accomplied by having a shared secret be entered on
+both the hosts that will be paired. Hopefully that secret is communicated
+securely out of band. 
+
+(In practice, the security of that communication will vary. To guard against
+interception, each pairing session pairs exactly two hosts and then forgets
+the shared secret. So an attacker who tries to reuse an intercepted secret
+will not succeed in pairing. This does not guard against an intercepted
+secret that is used before the legitimate parties finish pairing.)
+
+Each host can construct messages that the other host can verify using the
+shared secret, and so know that, for example, the ssh public key it
+received belongs to the right host and has not been altered by a man in the
+middle.
+
+The verification works like this: Take a HMAC SHA1 checksum of the message,
+using the shared secret as the HMAC key. Include this checksum after the
+message. The other host can then do the same calculation and verify the
+checksum.
+
+Additionally, a UUID is included in the message. Messages that are part of
+the same pairing session all share a UUID. And all such messages should
+be verifiable as described above. If a message has the same UUID but is
+not verifiable, then someone on the network is up to no good. Perhaps
+they are trying to brute-force the shared secret. When this is detected,
+the pairing session is shut down. (Which would still let an attacker
+DOS pairing, but that's not a very interesting attack.)
+
+The protocol used for pairing consists of 3 messages, a PairReq, and
+PairAck, and a PairDone. Let's consider what an attacker could accomplish
+by replaying these:
+
+* PairReq: This would make the webapp pop up an alert about an incoming
+  pair request. If the user thought it was real and for some reason
+  entered the right shared secret used in the real one earlier, the
+  ssh key inside the PairReq would be added to `authorized_keys`. Which
+  allows the host that originally sent the PairReq to access its git
+  repository, but doesn't seem to do the attacker any good.
+* PairAck:  If the host that originally sent
+  the PairReq is still pairing, it'll add the ssh key from the PairAck,
+  and start syncing, which again does the attacker no good.
+* PairDone: If the host that sent the PairAck is still syncing, it'll
+  add the ssh key from the PairDone, and start syncing, and stop
+  sending PairAcks. But probably, it's not syncing, because it would have
+  seen the original PairDone.. and anyway, this seems to do the attacker no
+  good.
+
+So replay attacks don't seem to be a problem.
+
+So far I've considered security from a third-party attacker, but either the
+first or second parties in pairing could also be attackers. Presumably they
+trust each other with access to their files as mediated by
+[[git-annex-shell]]. However, one could try to get shell access to the
+other's computer by sending malicious data in a pairing message. So the
+pairing code always checks every data field's content, for example the ssh
+public key is rejected if it looks at all unusual. Any control characters
+in the pairing message cause it to be rejected, to guard against console
+poisoning attacks. Furthermore, git-annex is careful not to expose data to
+the shell, and the webapp uses Yesod's type safety to ensure all user input
+is escaped before going to the browser.
+
+## TODO
+
+* pairing over IPV6 only networks does not work. Haskell's
+  `network-multicast` library complains "inet_addr: Malformed address: ff02::1"
+  .. seems it just doesn't support IPv6. The pairing code in git-annex
+  does support ipv6, apart from this, it's just broadcasting the messages
+  that fails. (Pairing over mixed networks is fine.)
+* If there are three assistants on the network, and 2 pair, the third is
+  left displaying a "Pair request from foo" alert, until it's close. 
+  Or, if the user clicks the button to pair, it'll get to the 
+  "Pairing in progress" alert, which will show forever (until canceled).
+
+  It should be possible for third parties to tell when pairing is done,
+  but it's actually rather hard since they don't necessarily share the secret.
diff --git a/doc/design/assistant/partial_content.mdwn b/doc/design/assistant/partial_content.mdwn
new file mode 100644
index 0000000000..cbfbfcea83
--- /dev/null
+++ b/doc/design/assistant/partial_content.mdwn
@@ -0,0 +1,36 @@
+On a regular system, a reasonable simplifying assumption is that all the
+files in the folder will be synced to the system. A user might want to
+disable syncing of some subdirectories, for eg, archived files. But in
+general, things are simpler to understand and implement if all files sync.
+
+But, an Android gadget probably cannot hold all a user's files. Indeed,
+it's likely that old files will be aggressively dropped from the Android
+after syncing to elsewhere, in order to keep enough free space on it for
+new files. 
+
+There needs to be a way for the user to browse files not on the gadget and
+request they be transferred to it. This could be done as a browser in the
+web app, or using a subdirectory full of placeholder files (not symlinks;
+see [[Android]]) that start transfer of the real file when accessed.
+
+----
+
+Currently, Android uses the "source" repository type in some
+configurations. This makes files be removed as soon as they are sent
+somewhere else.
+
+A compromise that avoids needing UI might be to change "source" so it
+retained files for a while after they were created, even after they were
+uploaded elsewhere. For example, it could hold onto them for a day. This
+would allow the user time to do things with new files before they are
+removed from the android device.
+
+One way to implement that would be a new preferred content expression like
+"age(1 day)". But this would need at least a daily full transfer scan to be
+run. 
+
+Another way would be to have a way to make drops of files be deferred
+for a period of time. This approach would not need to be specific to the
+"source" repository type. And seems easy enough to do, just have a
+configuration setting for the time interval, and an ordered drop queue
+and a thread that waits as needed before dropping.
diff --git a/doc/design/assistant/partial_content/comment_1_58c4faa321a5bb71adf9fdee079849f4._comment b/doc/design/assistant/partial_content/comment_1_58c4faa321a5bb71adf9fdee079849f4._comment
new file mode 100644
index 0000000000..aa65cd6b9a
--- /dev/null
+++ b/doc/design/assistant/partial_content/comment_1_58c4faa321a5bb71adf9fdee079849f4._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkpEY8WTFDhjIVTWG38Ph7ppmuXUTJAHAg"
+ nickname="Justin"
+ subject="selective sync"
+ date="2012-07-28T04:08:00Z"
+ content="""
+hey joey
+
+great work!!
+
+will partial content work like selective sync in dropbox
+
+use case: on desktop i have photos/mp3s/docs, but would only want to sync the docs to my netbook
+
+cheers
+
+justin
+"""]]
diff --git a/doc/design/assistant/partial_content/comment_2_588009d2140b7d259cdf191dca539e14._comment b/doc/design/assistant/partial_content/comment_2_588009d2140b7d259cdf191dca539e14._comment
new file mode 100644
index 0000000000..6dac2d7ce0
--- /dev/null
+++ b/doc/design/assistant/partial_content/comment_2_588009d2140b7d259cdf191dca539e14._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="Isn't this done?"
+ date="2019-09-28T12:39:52Z"
+ content="""
+Isn't this handled by [[/preferred content]] these days?
+"""]]
diff --git a/doc/design/assistant/polls.mdwn b/doc/design/assistant/polls.mdwn
new file mode 100644
index 0000000000..3457fd2453
--- /dev/null
+++ b/doc/design/assistant/polls.mdwn
@@ -0,0 +1 @@
+[[!inline pages="(page(design/assistant/blog/*) and tagged(design/assistant/polls)) or page(design/assistant/polls/*)" show=0]]
diff --git a/doc/design/assistant/polls/2013_user_survey.mdwn b/doc/design/assistant/polls/2013_user_survey.mdwn
new file mode 100644
index 0000000000..d1bac0ef8a
--- /dev/null
+++ b/doc/design/assistant/polls/2013_user_survey.mdwn
@@ -0,0 +1 @@
+The 2013 git-annex user survey is in progress [[here|/polls/2013]].
diff --git a/doc/design/assistant/polls/Android.mdwn b/doc/design/assistant/polls/Android.mdwn
new file mode 100644
index 0000000000..78806eac29
--- /dev/null
+++ b/doc/design/assistant/polls/Android.mdwn
@@ -0,0 +1,18 @@
+Help me choose a goal for the month of December. The last poll showed 
+a lot of interest in using the git-annex assistant with phones, etc.
+
+Background: git-annex uses symbolic links in its repositories. This makes it
+hard to use with filesystems, such as FAT, that do not support symbolic links.
+FAT filesystems are the main storage available on some Android devices that
+have a micro-SD card. Other, newer Android devices don't have a SD card and so
+avoid this problem.
+
+I can either work on the idea described in
+[[design/assistant/desymlink]], which could solve the symlink problem and
+also could lead to a nicer workflow to editing files that are stored in
+git-annex.
+
+Or, I can work on [[Android_porting|design/assistant/android]], and try to
+get the assistant working on Android's built-in storage.
+
+[[!poll open=no 81 "solve the symlink problem first" 17 "port to Android first" 1 "other"]]
diff --git a/doc/design/assistant/polls/Android/comment_1_fa6c409833f28c67da105d25f4a440e0._comment b/doc/design/assistant/polls/Android/comment_1_fa6c409833f28c67da105d25f4a440e0._comment
new file mode 100644
index 0000000000..49b7796073
--- /dev/null
+++ b/doc/design/assistant/polls/Android/comment_1_fa6c409833f28c67da105d25f4a440e0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn4yApngiiAJE5iX1MQ0VO_LXjLt4LgdHE"
+ nickname="Jim"
+ subject="No mass storage"
+ date="2012-12-02T03:33:06Z"
+ content="""
+I would have asked for better FAT support, but my Galaxy Nexus doesn't support mass storage mode, and MTP is not as easy to use nor reliably supported everywhere.  So I'd lean towards functionality that stays on the phone as much as possible.
+"""]]
diff --git a/doc/design/assistant/polls/Android_default_directory.mdwn b/doc/design/assistant/polls/Android_default_directory.mdwn
new file mode 100644
index 0000000000..8aa8cfefa3
--- /dev/null
+++ b/doc/design/assistant/polls/Android_default_directory.mdwn
@@ -0,0 +1,7 @@
+What directory should the Android webapp default to creating an annex in?
+
+Same as the desktop webapp, users will be able to enter a directory they
+want the first time they run it, but to save typing on android, anything
+that gets enough votes will be included in a list of choices as well.
+
+[[!poll open=no expandable=yes 79 "/sdcard/annex" 6 "Whole /sdcard" 9 "DCIM directory (photos and videos only)" 3 "Same as for regular git-annex. ~/annex/"]]
diff --git a/doc/design/assistant/polls/Android_default_directory/comment_1_d39655091ac3ed51a9d4325d86b23ad7._comment b/doc/design/assistant/polls/Android_default_directory/comment_1_d39655091ac3ed51a9d4325d86b23ad7._comment
new file mode 100644
index 0000000000..30b73d184c
--- /dev/null
+++ b/doc/design/assistant/polls/Android_default_directory/comment_1_d39655091ac3ed51a9d4325d86b23ad7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2013-04-19T06:29:14Z"
+ content="""
+While my main use case is a photo repo, I don't think it's wise to default to there.
+
+Similarly, spamming what amounts to the root dir of \"external\" storage with repos seems like a bad idea.
+"""]]
diff --git a/doc/design/assistant/polls/Android_default_directory/comment_2_2f1eaae95075db26488517720afd1c63._comment b/doc/design/assistant/polls/Android_default_directory/comment_2_2f1eaae95075db26488517720afd1c63._comment
new file mode 100644
index 0000000000..b2df3b0a27
--- /dev/null
+++ b/doc/design/assistant/polls/Android_default_directory/comment_2_2f1eaae95075db26488517720afd1c63._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnE6kFAbud1LWrQuyX76yMYnUjHt9tR-A8"
+ nickname="Leonardo"
+ subject="Direct mode"
+ date="2013-04-20T20:55:09Z"
+ content="""
+I think direct mode should be the default on Android
+"""]]
diff --git a/doc/design/assistant/polls/Android_default_directory/comment_3_b484012f60789be73d7d5b338cff6203._comment b/doc/design/assistant/polls/Android_default_directory/comment_3_b484012f60789be73d7d5b338cff6203._comment
new file mode 100644
index 0000000000..7474d774df
--- /dev/null
+++ b/doc/design/assistant/polls/Android_default_directory/comment_3_b484012f60789be73d7d5b338cff6203._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-04-20T23:38:47Z"
+ content="""
+@Richard, including all of /sdcard seems a reasonable thing to do if you want to back it all up. I don't know how likely anyone would be to want to sync the whole contents though.
+
+@Leonardo direct mode is the default for all respositories created by the webapp, as well as all repositories on crippled filesystems that cannot support indirect mode. Android webapp thus defaults to direct mode twice over!
+"""]]
diff --git a/doc/design/assistant/polls/goals_for_April.mdwn b/doc/design/assistant/polls/goals_for_April.mdwn
new file mode 100644
index 0000000000..53132dd441
--- /dev/null
+++ b/doc/design/assistant/polls/goals_for_April.mdwn
@@ -0,0 +1,17 @@
+What should I work on in April? I expect I could get perhaps two of these
+features done in a month if I'm lucky. I have only 3 more funded months,
+and parts of one will be spent working on porting to Windows, so choose wisely!
+--[[Joey]]
+
+[[!poll open=yes expandable=yes 4 "upload and download rate limiting" 15 "get webapp working on Android" 5 "deltas: speed up syncing modified versions of existing files" 8 "encrypted git remotes using git-remote-gcrypt" 0 "add support for more cloud storage remotes" 19 "don't work on features, work on making it easier to install and use" 2 "Handle duplicate files" 6 "direct mode (aka real files instead of symlinks) [already done --joey]" 3 "start windows port now"]]
+
+References:
+
+* [[rate_limiting]]
+* [[Android]]
+* [[deltas]] to speed up syncing modified files (at least for remotes using rsync)
+* [[encrypted_git_remotes]]
+* [[more_cloud_providers]] (OpenStack Swift, Owncloud, Google drive,
+  Dropbox, Mediafire, nimbus.io, Mega, etc.)
+* [[old poll on "what is preventing me from using git-annex assistant"|what_is_preventing_me_from_using_git-annex_assistant]]
+  (many of the items on it should be fixed now, but I have plenty of bug reports to chew on still)
diff --git a/doc/design/assistant/polls/goals_for_April/comment_1_9f81fa96db5970a4be0828c74a6d2d55._comment b/doc/design/assistant/polls/goals_for_April/comment_1_9f81fa96db5970a4be0828c74a6d2d55._comment
new file mode 100644
index 0000000000..f63460543b
--- /dev/null
+++ b/doc/design/assistant/polls/goals_for_April/comment_1_9f81fa96db5970a4be0828c74a6d2d55._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="Duplicate files"
+ date="2013-04-01T07:58:51Z"
+ content="""
+Having duplicate files is fairly easy. 
+a) Just a backup of your files, to not have accidental deleting.
+
+b) Some programs implements UNDO command (Ctrl-Z) as simply copying over the working text file
+to a backup directory. 
+
+c) If you tests precompiled programs, like git annex itself, it has identical files across releases.
+
+
+For more info about duplicate files, read hear these two bugreports:
+
+http://git-annex.branchable.com/bugs/When_syncing_two_repositories__44___git_annex_uses_9x_times_diskspace/
+(last comment)
+
+http://git-annex.branchable.com/bugs/Direct_mode_keeps_re-checksuming_duplicated_files/
+"""]]
diff --git a/doc/design/assistant/polls/goals_for_April/comment_2_d8956d220ccacff3d2f6cbeb15718459._comment b/doc/design/assistant/polls/goals_for_April/comment_2_d8956d220ccacff3d2f6cbeb15718459._comment
new file mode 100644
index 0000000000..8fed65fb0c
--- /dev/null
+++ b/doc/design/assistant/polls/goals_for_April/comment_2_d8956d220ccacff3d2f6cbeb15718459._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkWG4T4SGZxY-q4Wo8Jbxwb67g4J-WYmQM"
+ nickname="Mark"
+ subject="don't work on features option"
+ date="2013-04-01T14:03:35Z"
+ content="""
+The \"don't work on features...\" poll entry is a bit vague, so I figured stating my interpretation of it and why I choose it might be a good idea.
+I've had git-annex installed for the last few months during which it has been steadily improving, but IMO it still lacks polish.
+From time to time I see transient issues: (even on the current version)
+
+- random download stalling when I know the remote is accessible
+- files disappearing then reappearing without an obvious cause
+- xmmp hanging
+
+I do not have any means of replicating these issues (though IIRC some of the recently worked on bugs related to these issues).
+In my past experience this indicates that there are all sorts of 'fun' bugs hiding in the source which you seem to be chasing down.
+Heck, I could have a simple configuration error from when I set things up on my remote server.
+There was little documentation available when I setup my remote server for this and unless I have missed something in the RecentChanges feed, there still is relatively little.
+So, some issues with my xmmp daemon, local ssh keys via ssh-agent, or bad $PATH stuff could be causing things to subtlety malfunction at no fault of git-annex.
+
+Falling back to the command line only tends to be a good response, but outside of the assistant there does not seem to be any manual way to handle the special remotes.
+Fair enough, but it would seem logical for error handling to recognize that these are assistant only urls rather than some generic \"bad url\".
+Just getting the right error messages while a small touch would be a sign of some polish even though it is a nitpick.
+
+Perhaps some simple test code run repeatedly to form a stress test could reveal some odd behavior, but I'm not sure myself.
+
+With all of that said, I like what has been done so far and I'm hoping to see all the nooks of git-annex get the polishing that they deserve.
+"""]]
diff --git a/doc/design/assistant/polls/goals_for_April/comment_3_aadad6dfd56d068d2e377606910c006f._comment b/doc/design/assistant/polls/goals_for_April/comment_3_aadad6dfd56d068d2e377606910c006f._comment
new file mode 100644
index 0000000000..f3cea47c83
--- /dev/null
+++ b/doc/design/assistant/polls/goals_for_April/comment_3_aadad6dfd56d068d2e377606910c006f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="Ask for more money :-)"
+ date="2013-04-01T19:01:49Z"
+ content="""
+This is slightly off topic, but from my perspective this Kickstarter project has been a riotous success, and due to the credibility you have built up from 9 months of consistently high quality work produced in a very transparent and community-oriented fashion, I'd be surprised if you weren't able to raise more money to continue development after the 12 months is up.  Assuming you want to of course :)  Maybe you need a break or change of scene.  But if not, it would be a shame not to continue if the userbase wants it.
+"""]]
diff --git a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
new file mode 100644
index 0000000000..1307c892cd
--- /dev/null
+++ b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
@@ -0,0 +1,16 @@
+Background: git-annex supports storing data in various [[special remotes]].
+The git-annex assistant will make it easy to configure these, and easy
+configurators have already been built for a few: removable drives, rsync.net,
+locally paired systems, and remote servers with rsync.
+
+Help me prioritize my work: What special remote would you most like
+to use with the git-annex assistant?
+
+[[!poll open=yes 18 "Amazon S3 (done)" 13 "Amazon Glacier (done)" 10 "Box.com (done)" 79 "My phone (or MP3 player)" 29 "Tahoe-LAFS" 19 "OpenStack SWIFT" 37 "Google Drive"]]
+
+This poll is ordered with the options I consider easiest to build
+listed first. Mostly because git-annex already supports them and they
+only need an easy configurator. The ones at the bottom are likely to need
+significant work. See [[cloud]] for detailed discussion.
+
+Have another idea? Absolutely need two or more? Post comments..
diff --git a/doc/design/assistant/polls/prioritizing_special_remotes/comment_1_dd9280df27848a7ff132f5809dab0a79._comment b/doc/design/assistant/polls/prioritizing_special_remotes/comment_1_dd9280df27848a7ff132f5809dab0a79._comment
new file mode 100644
index 0000000000..0214d4a12b
--- /dev/null
+++ b/doc/design/assistant/polls/prioritizing_special_remotes/comment_1_dd9280df27848a7ff132f5809dab0a79._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2012-09-13T08:39:59Z"
+ content="""
+I've been looking at ceph for various reasons in work, it supports a swift interface as well as it's own restful api. so +1 for swift (and any s3 compatible api).
+"""]]
diff --git a/doc/design/assistant/polls/prioritizing_special_remotes/comment_2_370e0b9c43486ee96c825f9155eebde4._comment b/doc/design/assistant/polls/prioritizing_special_remotes/comment_2_370e0b9c43486ee96c825f9155eebde4._comment
new file mode 100644
index 0000000000..4d00922a48
--- /dev/null
+++ b/doc/design/assistant/polls/prioritizing_special_remotes/comment_2_370e0b9c43486ee96c825f9155eebde4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 2"
+ date="2012-09-13T09:07:02Z"
+ content="""
+Swift has its own API but offers a S3 compatibility layer. Last I tried that layer, it did not work.
+"""]]
diff --git a/doc/design/assistant/polls/prioritizing_special_remotes/comment_3_883a003b9c552b89f191135c582f99aa._comment b/doc/design/assistant/polls/prioritizing_special_remotes/comment_3_883a003b9c552b89f191135c582f99aa._comment
new file mode 100644
index 0000000000..83844cd351
--- /dev/null
+++ b/doc/design/assistant/polls/prioritizing_special_remotes/comment_3_883a003b9c552b89f191135c582f99aa._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmsz4weoPXV2oEtv3zpo9dOxn_SEPz-7Iw"
+ nickname="Zooko"
+ subject="reasons to like Tahoe-LAFS as a special remote"
+ date="2012-10-12T18:17:42Z"
+ content="""
+Here are a couple of things which are (I think) unique about the Tahoe-LAFS special remote:
+
+1. encryption ; All of the data is encrypted before leaving your local system and heading for the server (or for the clouds). This is true even though you don't (I think) have to enter an encryption key into git-annex to access your data.
+
+(Note: the above implies that you're in danger of permanently losing access to your data, by losing the last copy of the encryption key, if your local git-annex state is lost. This deserves careful consideration.)
+
+2. erasure-coding ; You can configure Tahoe-LAFS to spread the data out in a RAID-like way across multiple remote storage servers, where each server holds only, say, 1/3 of the data, but there are, say, 10 different servers, where any 3 of them are sufficient to give you full access to your data. Does that make sense it uses less bandwidth and storage space than replication (i.e. putting a complete replica of your data on each of 4 or 5 or 10 different storage servers), but it is more robust than sharding (i.e. putting 1/3 of your data on each of three different servers so that if any one of them goes down you lose 1/3 of your data).
+"""]]
diff --git a/doc/design/assistant/polls/prioritizing_special_remotes/comment_4_746006c3fffc7f917c4526fd688051f7._comment b/doc/design/assistant/polls/prioritizing_special_remotes/comment_4_746006c3fffc7f917c4526fd688051f7._comment
new file mode 100644
index 0000000000..713d1d7b59
--- /dev/null
+++ b/doc/design/assistant/polls/prioritizing_special_remotes/comment_4_746006c3fffc7f917c4526fd688051f7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnjrMQEhzd8xI81V9BL2jsKlNgVJLD7PKs"
+ nickname="Pankaj"
+ subject="Google Music as remote?"
+ date="2012-10-31T06:07:32Z"
+ content="""
+A dropbox like folder which syncs with Google Music. Google Music allows uploading upto 20K songs. Also using git-annex , I can ensure that I dont need to store all the duplicate mp3 on my local drive. Only one copy of \"older music\" is \"arvhived\" on GMusic, whereas more recent songs are on my local drive.
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant.mdwn b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant.mdwn
new file mode 100644
index 0000000000..4b4778c1f4
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant.mdwn
@@ -0,0 +1,16 @@
+My goal for this month is to get more people using the git-annex assistant,
+and fix issues that might be blocking you from using it. To do this,
+I'd like to get an idea about whether you're already using it,
+or what's keeping you from using it.
+
+If you use `git-annex` at the command line and have no reason to use the
+assistant, please instead fill in this poll on behalf of less technically
+adept friends or family -- what's preventing you from introducing them to
+the assistant?
+
+[[!poll open=no expandable=yes 8 "I'm using the assistant!" 28 "I need a Windows port" 30 "I need an Android port" 3 "I need an IPhone port (not holding my breath)" 2 "Well, it's still in beta..." 11 "I want to, but have not had the time to try it" 5 "Just inertia. I've got this dropbox/whatever that already works.." 3 "It's too hard to install (please say why in comments)" 2 "Perceived recent increase of bug reports and thus sitting it out." 25 "Initially the lack of direct-mode. Now concerns about the safety of direct mode. Perhaps after the next release." 10 "I haven't always well understood the differences between commandline operation & the assistant, so the differences would confuse me, and I found the command line more understandable & less scary.  Now trying to learn to like & trust the assistant. :)" 21 "An Ubuntu PPA would be supercool! Thanks for your great work!!" 18 "Not yet in Debian sid amd64" 6 "Waiting for Fedora/CentOS rpm repository." 2 "throttling transfers, it upsets people when I saturate the connection" 2 "partial content" 1 "Not yet available in macports" 4 "No build yet for Nokia N9" 3 "Using only git-annex webapp to config does not seem to work: Create walkthough?" 5 "No build for OSX 10.6" 5 "Needs more focus on the UI." 1 "Just inertia. I don't have a Dropbox/whatever." 4 "Replaces files with a symlink mess." 2 "configurable option to only annex files meeting certian size or filename criteria" 4 "I'm really confused about how to make it sync with a remote NON-bare repository. I'm even afraid to try `git remote add`, since there is no clear method to completely forget a git-annex remote..." 5 "A build for te raspberry pi would be supercol!" 1 "Would be nice to exclude subfolders from the gui or through a config file" 1 "I wish I had transparently encrypted git repos in the cloud available, like jgit." 1 "too many inodes used in direct mode. maybe it's possible to keep more info as git objects instead?" 2 "I need to be able to restrict in which repo dirs changes get auto-committed" 1 "Provide .deb package" 1 "Better documentation/walkthroughs on using git-annex within an existing git repo. AKA mixed use" 1 "Union mounts to have a single view of file collection on the network" 1 "Ubuntu PPA does not build with webapp" 1 "I set it up, but am confused about what I set up! It would be great to be able to start from scratch." 1 "I need to be able to restrict in which repo dirs changes get auto-committed using a syntax similar to gitignore"]]
+
+Feel free to write in your own reasons, or add a comment to give me more info.
+
+Note: Poll is now closed. Nearly all these issues have been dealt with.
+Please file bug reports if any of these issues still affect you.
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_10_10a4839a05be39ced54ffbe880a588bb._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_10_10a4839a05be39ced54ffbe880a588bb._comment
new file mode 100644
index 0000000000..b501be3b8b
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_10_10a4839a05be39ced54ffbe880a588bb._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 10"
+ date="2013-01-11T21:57:29Z"
+ content="""
+@joey: My usecase is fairly simple. 
+I have a working directory where I do work 
+(not programing, but text editing with homecooked spreadsheet/texteditor).
+
+I work/type on spot/on site. So I'm walking while typing.
+
+Its easy to do stupid things while you work, 
+so would be really handy to have a backup automagically on the same computer to prevent mistakes, user errors.
+(The last mistake, I did is I copied all my daily files into a \"tmp\" directory, 
+then I launched my homebrew program which also created a tmp dir then deleted the whole content of it. 
+I fixed it, but my datas was lost. It is a simple user mistake which could be prevented if I would have a 
+live backup all the time. Creating a git repo for daily typing is just too much overhead. 
+It is like you create a git repo for your text messages...)
+
+So my usecase is a live backup. Or the broken file deleting thing on unix/linux since forever.
+
+Laszlo
+
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_11_ac91d866f11c66dd8c86e2cd1a368c85._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_11_ac91d866f11c66dd8c86e2cd1a368c85._comment
new file mode 100644
index 0000000000..1657d11ad0
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_11_ac91d866f11c66dd8c86e2cd1a368c85._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 11"
+ date="2013-01-11T22:17:07Z"
+ content="""
+@dzsino: You may want to have a look at [metamonger](https://github.com/RichiH/metamonger) which tries to solve exactly this problem. It's not finished yet, though.
+
+-- Richard
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_12_e244c1bf334b1cc9ad0cc760bf8fe5de._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_12_e244c1bf334b1cc9ad0cc760bf8fe5de._comment
new file mode 100644
index 0000000000..fc2b03baca
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_12_e244c1bf334b1cc9ad0cc760bf8fe5de._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkx5V3MTbzCXS3J7Mn9FEq8M9bPPYMkAHY"
+ nickname="Pedro"
+ subject="It fails silently and leaves symlinks behind"
+ date="2013-01-11T23:49:51Z"
+ content="""
+I dedicated a day to looking into using the assistant and although it's clearly an exciting piece of software it's still pretty hard to get working. To get two machines to sync with one another the options seem to be:
+
+1. Connect both of them to a XMPP server: That makes metadata sync flawlessly and yet leaves a symlink mess behind. As it turns out that's because XMPP syncs only metadata but nowhere was that stated on the webapp (that I could find) and no error message given
+2. So then I tried the sync method with SSH. 
+
+For that you'll need to:
+
+* Have SSH servers installed on both endpoints (for me that was easy to do but I'm sure most users will have a harder time)
+* Make sure both computers are actually on the same broadcast network otherwise they won't see each other (I was testing with a VM behind virtualbox's NAT so initially it didn't work)
+* Install the assistant on both sides and make sure both the base program and the shell wrapper are in the PATH. (this was harder to do than needed as in the standalone bundle they're not on the same folder and the shell wrapper needs to be run by the runshell script, so even if you get it in the path it will still fail with missing libraries. An Ubuntu PPA would have solved this I'm sure.
+
+For some reason I couldn't figure out they still couldn't sync and symlink mess ensued.
+
+I think there are a few usability issues here:
+
+1. Direct mode should never overwrite files in a way you can no longer use them just because metadata updates came before content updates. I'd rather have an older version of the file than lose access to it.
+2. Error reporting needs to be a lot more explicit to be able to debug these issues
+3. At the best of times SSH sync is going to be a problem. In my opinion to be really dropbox-like the sync method for normal users should be to connect all devices to the same XMPP account (this works great now) and then have those assistants automatically reach each other by a direct connection when possible and by something like STUN if NAT punching is needed. The SSH/bup/etc remotes all have their place for advanced setups but being able to tell the user to just connect to XMPP and be done would turn this from \"something I'll spend an afternoon writing puppet manifests to deploy in my personal servers/computers\" to \"something I can explain to a non-technical friend how to use over a phone call and then share files with him\".
+
+On the XMPP side though, it would work best if you could authenticate a Google XMPP acount through an OAuth workflow instead of asking for the password. I wouldn't give any program my gmail password but I'd easily give it permission to use gtalk on my behalf.
+
+As I started by saying the assistant (and git-annex in general) is an extremely impressive piece of software that I'm very excited about. I hope it keeps improving at the current pace as there are still a few features I'd love to have (partial content particularly) but by far the thing that's keeping me most from using it is the ability to easily get a reliable sync going that won't leave me with a folder full of symlinks that I don't know what to do about. One of the great things about dropbox is that whenever it isn't running or can't sync for any reason your folder degenerates into a folder like any other on your disk. The right way of thinking about direct mode should be that one, \"a folder like any other that we stream changes from and to on multiple machines\". Right now, with the symlink replacement when sync isn't possible and to a lesser extent the adding of .git folders it doesn't live up to that guarantee.
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_13_1a0faf4bdc78741937e8a2f5cb5bbec6._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_13_1a0faf4bdc78741937e8a2f5cb5bbec6._comment
new file mode 100644
index 0000000000..066859b32b
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_13_1a0faf4bdc78741937e8a2f5cb5bbec6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 13"
+ date="2013-01-12T08:16:48Z"
+ content="""
+@Pedro: That is an excellent test, and usecase!
+
+Indeed, the gui needs a lot more info on it. 
+Also file integratity is a real fear with this kind of application.
+
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_14_8d8a11dbfae7a7bc574bdf37f87e0684._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_14_8d8a11dbfae7a7bc574bdf37f87e0684._comment
new file mode 100644
index 0000000000..1ecaff59f0
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_14_8d8a11dbfae7a7bc574bdf37f87e0684._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~rubiojr"
+ nickname="rubiojr"
+ subject="git-annex PPA"
+ date="2013-01-15T14:16:35Z"
+ content="""
+Hey Joey,
+
+I do maintain a PPA with a more up2date version in fact:
+
+https://launchpad.net/~rubiojr/+archive/git-annex
+
+Now that the direct mode is in place, I guess it's probably a good time to backport again.
+
+Thanks for such a great piece of software.
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_15_c437adeaccf0b3d134e0f81c64e25b9f._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_15_c437adeaccf0b3d134e0f81c64e25b9f._comment
new file mode 100644
index 0000000000..e6e4af37e2
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_15_c437adeaccf0b3d134e0f81c64e25b9f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~rubiojr"
+ nickname="rubiojr"
+ subject="direct mode still 'untrusted'?"
+ date="2013-01-15T14:23:22Z"
+ content="""
+BTW,
+
+Does this still apply?
+
+\"I'd like git annex direct to set the repository to untrusted, but I didn't do it. Partly because having git annex indirect set it back to semitrusted seems possibly wrong -- the user might not trust a repo even in indirect mode. Or might fully trust it. The docs will encourage users to set direct mode repos to untrusted -- in direct mode you're operating without large swathes of git-annex's carefully constructed safety net. (When the assistant later uses direct mode, it'll untrust the repository automatically.)\"
+
+http://git-annex.branchable.com/design/assistant/blog/day_151__direct_mode_toggle/
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_16_6e3fce3a32ab346dc3d0fd4b69967536._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_16_6e3fce3a32ab346dc3d0fd4b69967536._comment
new file mode 100644
index 0000000000..afda489a13
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_16_6e3fce3a32ab346dc3d0fd4b69967536._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="just one thing"
+ date="2013-01-16T01:45:54Z"
+ content="""
+http://git-annex.branchable.com/todo/wishlist:_disable_automatic_commits/ is the only thing I'm waiting for.  Will become a very keen beta-tester (maybe even coder) when that happens.
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_17_1b7233d88593d0d99b26ea3e7af20d9c._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_17_1b7233d88593d0d99b26ea3e7af20d9c._comment
new file mode 100644
index 0000000000..278181ad51
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_17_1b7233d88593d0d99b26ea3e7af20d9c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 17"
+ date="2013-01-16T19:38:36Z"
+ content="""
+@rubiojr I recommend configuring direct mode repos as untrusted if you care about accessing old versions of your files as stored in git. If that is not a concern, direct mode is safe, it's just that it allows editing/deleting any file at any time, even if that's the only copy of the file.
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_18_a23d5a0e2718b8e486f036fe8a413b36._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_18_a23d5a0e2718b8e486f036fe8a413b36._comment
new file mode 100644
index 0000000000..5f82d7ebb6
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_18_a23d5a0e2718b8e486f036fe8a413b36._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="comment 18"
+ date="2013-01-17T12:04:34Z"
+ content="""
+the \"I haven't always well understood the differences between commandline operation & the assistant, so the differences would confuse me, and I found the command line more understandable & less scary. Now trying to learn to like & trust the assistant.\" fits pretty well for me -- i'd like to use the webapp at least for viewing, but i'm worried that some auto-magic would kick in, and i regularly have uncommitted stuff in at least one git-annex repo.
+
+a --dry-run flag or similar on the `git annex webapp` would be nice, or a description of what would happen or how to turn that off / make it create other branches / even commit or push something.
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_19_f4c84a9d701d52cf2f2e45f3d764a90c._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_19_f4c84a9d701d52cf2f2e45f3d764a90c._comment
new file mode 100644
index 0000000000..35def93746
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_19_f4c84a9d701d52cf2f2e45f3d764a90c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnmvVKc1ECzZx7EhtLHBP6RWPZewq4x_9I"
+ nickname="Daniele"
+ subject="Windows + git ignore like syntax for files to sync"
+ date="2013-04-19T10:47:36Z"
+ content="""
+Hi,
+
+my company would need this for some project.
+
+But to adopt it I would need:
+* windows support (I don't care if now symlink support for now)
+* being able to define which files are automatically synced using a syntax similar to the gitignore one
+* being able to disable auto-commit (just synching, user should be able to commit on their own)
+
+thanks
+
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_1_00a0de8190d946caaeeca3b44646146f._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_1_00a0de8190d946caaeeca3b44646146f._comment
new file mode 100644
index 0000000000..4bebe748d1
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_1_00a0de8190d946caaeeca3b44646146f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="Two reasons"
+ date="2013-01-10T18:00:05Z"
+ content="""
+As of right now, the assistant has only secondary benefit over plain git-annex inasmuch there's a lot more code activity.
+
+As soon as the assistant supports Android, I will use for syncing photos off of my phone and may start to use the assistant on my usual repos as a natural consequence.
+
+Additionally, there's a subjective feeling of more bugs being reported. That may or may not be true, but as long as there's no Android port, I don't have an actual reason to \"risk\" it.
+
+-- Richard
+
+PS: This seems to be the first poll where you can place only one vote while it's the first where I really wanted to vote on two separate items.
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_20_199c9807499470771af6cbca6d034cfa._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_20_199c9807499470771af6cbca6d034cfa._comment
new file mode 100644
index 0000000000..51e1bc4ea0
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_20_199c9807499470771af6cbca6d034cfa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 20"
+ date="2013-04-19T18:01:44Z"
+ content="""
+You can turn off automatic commits in the webapp by pausing syncing for the local repository. 
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_21_9185b0e05b1b1997533694da1de83073._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_21_9185b0e05b1b1997533694da1de83073._comment
new file mode 100644
index 0000000000..5ec65ad98a
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_21_9185b0e05b1b1997533694da1de83073._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmH-n1yD04qmSeXKKzYaXFTN1ciFWVb5As"
+ nickname="Martyn"
+ subject="Can't seem to get the configuration I am looking for from the webapp"
+ date="2014-01-02T23:41:44Z"
+ content="""
+Currently, I have a local server, desktop and laptop (all on the same network). My laptop leaves the house occasionally where I work on it...
+Quite simply, I want make the local server the centralised repository and have the desktop + laptop sync up and down to and from the server. The server would act as a backup and file change history between all local repositories on desktop and laptop. So I would sync between trips away.
+
+Sadly every combination with git-annex webapp fails for a number of reasons, it could be just me but here is what I've experienced:
+
+a) I want to use direct mode ALL the time or at least be able to configure it without the command line. Currently server side set ups are indirect depending on the repository group. So no symlinks basically. I think \"full backup\" and \"client\" are the only two that do what I was hoping for here.
+b) The list of repository group types miss something I'm looking for, I want the \"full backup\" with \"transfer\" for the remote server - I guess? 
+c) For remote cloud solutions, I would like the files to exist, not just the raw .git/ directory to exist on the server. When I tested it, I couldn't see a way to test on the server itself the integrity of the files (could be my lack of git-annex knowledge :)
+d) I would like it if the assistant made it simpler to configure remotes, i.e. right now if I have 2 directories I believe I would need 4 configurations to push/pull locally and remotely to the 1 server with each machine. I've had this working and it's the closest I've got so far, but tedious if I want to do it for 5 directories on 2 machines (that's 20 configurations to add in all unless there is an easier way?)
+e) The \"share with other devices\" option seems one of the best right now, but it suffers with the issues of c) AFAICT. Why not have the server just be a remote when unencrypted?
+
+From some reading up on the command line tools, it seems like it would be easier to set up using those for what I want than using the webapp.
+I currently love the webapp, it's just missing some polish and options to do what I need.
+
+Thanks for the great work so far! :)
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_2_35f6f121e54260cb960211a6e2e51e8e._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_2_35f6f121e54260cb960211a6e2e51e8e._comment
new file mode 100644
index 0000000000..bf52b9c1c2
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_2_35f6f121e54260cb960211a6e2e51e8e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniCRkhl_W87gOK5eElfsef3FoUsUFpAr4"
+ nickname="Alexandre"
+ subject="Two assistants with shared transfer repository"
+ date="2013-01-11T07:17:12Z"
+ content="""
+I voted for the Windows port, which unfortunately I must use at work.
+
+But another thing that Dropbox gets right is that you can [sync two clients with one shared repository](http://git-annex.branchable.com/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__) that works without any configuration whether you are home or somewhere else. This use case is covered by sync over XMPP, but there are two small issues with this :
+- if I use Google XMPP servers to sync two assistants in the same network, everything goes through the slower Internet link
+- if I setup my own XMPP server, well, this is more setup, more open ports, etc.
+
+It would be nice to have repository pushs on a shared repository notified to the connected clients in the SSH connection.
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_3_acbe4f63b5d552ac5ae5a12c6f42dc18._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_3_acbe4f63b5d552ac5ae5a12c6f42dc18._comment
new file mode 100644
index 0000000000..0d971c29c1
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_3_acbe4f63b5d552ac5ae5a12c6f42dc18._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="http://a-or-b.myopenid.com/"
+ ip="220.244.41.108"
+ subject="comment 3"
+ date="2013-01-11T09:32:33Z"
+ content="""
+I've got a few wishes for git-annex…  Referring to the poll options:
+
+- I need an Android port
+
+I think this is the biggest issue for getting a high WAF.  (I want to put our photos in an annex, and getting them auto-magically off her phone would get me massive brownie points.)
+
+- Initially the lack of direct-mode. Now concerns about the safety of direct mode. Perhaps after the next release.
+
+The \"potentially unsafe\" sort of comments in the blog make me worry about trusting my data to the direct mode.  Saying that I *really* appreciate the honesty of the comments.  That is why I want to keep using, and recommend to others, git-annex.
+
+- I haven't always well understood the differences between commandline operation & the assistant, so the differences would confuse me, and I found the command line more understandable & less scary. Now trying to learn to like & trust the assistant.
+
+I also have worried about the automatic adding by the assistant - prior to direct mode.
+
+- throttling transfers, it upsets people when I saturate the connection
+
+I think a bittorrent option would be ideal.  Not public torrents, but torrents between my annexes.
+
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_4_0d988280865caae498a3b693b6342e37._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_4_0d988280865caae498a3b693b6342e37._comment
new file mode 100644
index 0000000000..b66cd12f7e
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_4_0d988280865caae498a3b693b6342e37._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="Two local repositories"
+ date="2013-01-11T10:31:54Z"
+ content="""
+Here is my usecase:
+I want two local (direct mode) repositories. So basically a working directory and a backup directory to the working one.
+
+The removable media repository *almost* fulfill this usecase, except you can only select drive and not a directory.
+I think it would be relatively simple to implement. (A drive is a directory under linux after all).
+
+Best, 
+ Laszlo
+
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_5_ac8fe3768c30dd7999c183500f8567bb._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_5_ac8fe3768c30dd7999c183500f8567bb._comment
new file mode 100644
index 0000000000..713e8ef7d9
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_5_ac8fe3768c30dd7999c183500f8567bb._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="marvin"
+ ip="91.154.225.32"
+ subject="SSH keys"
+ date="2013-01-11T12:02:50Z"
+ content="""
+Really looking forward to seeing this project go forward and impressed by what you have accomplished.
+
+I have my own server which I want to use as a repository, so I'll choose \"Remote server\". I want to use direct mode.
+Now I can only create an encrypted remote which is fine for me, but I don't know how to sync that with another client using this remote.
+
+Also with the generated ssh keys I no longer can log into my server normally as it tries to use the generated keys.
+The generated keys should also be restricted to only be able to change the repository and nothing else.
+
+Maybe webdav could be used to create something with better access control and repositories for groups etc.
+Also with a simple web upload/download page, similar to dropbox.
+
+Sorry if my post is long and idiotic, just simple (hopefully constructive) feedback from a simple user :)
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_6_36832de705a2bebf8dc6e65dcd661731._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_6_36832de705a2bebf8dc6e65dcd661731._comment
new file mode 100644
index 0000000000..525a325f03
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_6_36832de705a2bebf8dc6e65dcd661731._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 6"
+ date="2013-01-11T15:06:47Z"
+ content="""
+Laszlo's concern about \"you can only select a drive and not a directory\" relates to a problem I had.
+
+I have two local directories, ~/annex indirect my main annex, and ~/directannex for playing with direct mode.
+
+I had hoped to back each up to the same shared drive, but didn't realize there was no option to select a directory within a shared drive, so when I tried to do that through the assistant I inadvertently connected the two by backing them up to the same directory on the shared drive!
+
+This is probably a \"power user problem\" which has a \"power user solution\" of setting up the separate repository manually.  But it did take me by surprise.
+
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_7_3618067e473577a112e36970ca71e0ab._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_7_3618067e473577a112e36970ca71e0ab._comment
new file mode 100644
index 0000000000..bfb1b949ce
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_7_3618067e473577a112e36970ca71e0ab._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://dzsino.myopenid.com/"
+ nickname="dzsino"
+ subject="Recording file creation dates?"
+ date="2013-01-11T16:35:27Z"
+ content="""
+I've just started using git annex, command line feels safer for the time being. One issue I've got with assistant that I had to kill it couple of times when it got confused over something (could be that I used command line git annex at the same time?),  shutdown from the UI is welcome.
+
+More of a git annex issue for me that I lost file creation dates for annexed files, which i don't really mind for most of my content, except really old photos without proper EXIF tags.
+I think of git annex as more of a DVR for my digital life, rather than a mere sync tool, so I would welcome some basic metadata facility. Would you consider adding this?
+(Really getting carried away, I would want to full text search on file names, ID3 tags, document metadata and text etc. and requesting files based on search hits, spotlight style..)
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_8_07a13b6f000ddc0ac4472b863d8b50bd._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_8_07a13b6f000ddc0ac4472b863d8b50bd._comment
new file mode 100644
index 0000000000..8bbd57b5d2
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_8_07a13b6f000ddc0ac4472b863d8b50bd._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 8"
+ date="2013-01-11T20:02:39Z"
+ content="""
+@Alexandre, what you want can be achieved by setting up XMPP pairing, and also [[local pairing|assistant/local_pairing_walkthrough]]. Then when computers are on the same network, transfers are done via the LAN.
+
+@Laszlo, this can be set up without using the webapp. Just make the two repositories, using the webapp. Then go into each and run \"git remote add myotherrepo $path_to_other_repo\". Then assistant will automatically sync them. I *have* thought about adding a configurator for this to the webapp. It would help to know what use cases you're getting at with this.
+
+@marvin The generated ssh keys are configured to only allow running `git-annex-shell`, which limits it to only acting on the repository. The keys are also configured, in `.ssh/config` to only be used when a particular host alias is used. They should not be used when you just ssh normally to the host. If this is happening to you, please file a bug report with details.
+
+@dzsino you can get file creation dates out of git using git log :)
+"""]]
diff --git a/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_9_e15eb407d988fda363296c8b566cc8fb._comment b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_9_e15eb407d988fda363296c8b566cc8fb._comment
new file mode 100644
index 0000000000..f7dd3eb884
--- /dev/null
+++ b/doc/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/comment_9_e15eb407d988fda363296c8b566cc8fb._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQafKy7hNSEolLs6TvbgUnkklTctUY9LI"
+ nickname="Zellyn"
+ subject="Question about git-annex"
+ date="2013-01-11T21:05:55Z"
+ content="""
+Not sure where the correct place to ask this is...
+
+My use case for git-annex is to back up important files (pictures, videos, etc.) on a hard disk at work and one at home. Is there an easy way to do that? I'd like to be able to get git-annex to fill up my phone/laptop with files that it thinks are backed up in <2 of the locations, and ferry them back and forth. They can be deleted to free up space after that, if necessary.
+
+Thanks for all your work, by the way. I missed the kickstarter, but if there's a simple and direct way to donate (dwolla?, gittip?), I'd love to chip in.
+"""]]
diff --git a/doc/design/assistant/progressbars.mdwn b/doc/design/assistant/progressbars.mdwn
new file mode 100644
index 0000000000..7de70452d0
--- /dev/null
+++ b/doc/design/assistant/progressbars.mdwn
@@ -0,0 +1,43 @@
+Currently, git-annex takes a very lazy approch to displaying
+progress into. It just lets rsync or whatever display the progress
+for it, in the terminal.
+
+Something better is needed for the [[webapp]]. There needs to be a
+way for the web app to know what the current progress is of all transfers.
+
+This is one of those potentially hidden but time consuming problems.
+
+## downloads
+
+* Watch temp file as it's coming in and use its size.
+  Can either poll every .5 seconds or so to check file size, or
+  could use inotify. **done**
+* When easily available, remotes call the MeterUpdate callback as downloads
+  progress. **done**
+* S3: TODO  
+  While it has a download progress bar, `getObject` probably buffers the whole
+  download in memory before returning. Leaving the progress bar to only
+  display progress for writing the file out of memory. Fixing this would
+  involve making hS3 stream better (also avoids it wasting memory).
+
+## uploads
+
+Each individual remote type needs to implement its own support for calling
+the MeterUpdate callback as the upload progresses.
+
+* git: **done**
+* rsync: **done**
+* directory: **done**
+* web: Not applicable; does not upload 
+* webdav: **done**
+* S3: **done**
+* glacier: **done**
+* bup: **done**
+* hook: Would require the hook interface to somehow do this, which seems
+  too complicated. So skipping.
+
+## communication
+
+It may be worth using a better communication channel than files on disk for
+the transfer progress. Shared memory could be used, or http posts to the
+webapp.
diff --git a/doc/design/assistant/progressbars/comment_1_3ea263b1f334e8e38e14f00a96202988._comment b/doc/design/assistant/progressbars/comment_1_3ea263b1f334e8e38e14f00a96202988._comment
new file mode 100644
index 0000000000..4a011f61be
--- /dev/null
+++ b/doc/design/assistant/progressbars/comment_1_3ea263b1f334e8e38e14f00a96202988._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://abhidg.myopenid.com/"
+ ip="129.67.132.87"
+ subject="librsync"
+ date="2012-06-13T02:14:29Z"
+ content="""
+There's librsync which might support reporting the progress through its API, but it seems to be in beta.
+"""]]
diff --git a/doc/design/assistant/rate_limiting.mdwn b/doc/design/assistant/rate_limiting.mdwn
new file mode 100644
index 0000000000..3ab804329a
--- /dev/null
+++ b/doc/design/assistant/rate_limiting.mdwn
@@ -0,0 +1,57 @@
+Webapp needs a simple speed control knob, especially to avoid saturating 
+bandwidth on uploads.
+
+We have basic throttling support in git-annex for rsync,
+but none for any special remotes. A good first step would be to expose
+this in the webapp, and ensure that `git-annex-shell` also honors it when
+sending/receiving data.
+
+We actually need two speed controls, one for upload and one for download.
+
+It is probably not necessary to throttle git push/pull operations, as the
+data transfers tend to be small. Only throttling file transfers is
+essential.
+
+## possibility: trickle
+
+Since `git-annex transferkeys` is a separate process, one easy option would
+be to run it inside `trickle`. If the user changes the bandwidth limits,
+it could kill the transfer and restart it with different trickle options.
+
+Problem: Not all special remotes support resuming transfers, so this is
+suboptimal. (So too are the pause/resume buttons, when using those
+remotes!)
+
+`trickle` is available for OSX as well as Linux and BSDs.
+<http://hints.macworld.com/comment.php?mode=view&cid=65362>
+<http://mac.softpedia.com/get/Network-Admin/Trickle.shtml>
+It is probably not easily available for Android, as it uses `LD_PRELOAD`.
+
+## possibility: built in IO limiting
+
+A cleaner method would be to do the limiting inside git-annex. We already
+have metered file IO. It should be possible to make the meter not only report
+on the transfer speed, but detect when it's going too fast, and delay. This
+will delay the file streaming through the special remote's transfer code,
+so should work for a variety of special remotes. (Not for rsync or bup
+or git-annex-shell though, so those need to be handled separately.)
+
+Should work well for uploads at least. I don't know how well it would work
+for throttling downloads; the sender may just keep sending data and the
+data buffer before it gets to the IO meter. Maybe once the buffers fill the
+OS would have the TCP throttled down. Needs investigation; trickle claims
+to throttle downloads.
+
+## communications channels
+
+There would need to be a communication channel for the assistant to tell
+`git annex transferkeys` when the rate limit has changed. It could for
+example send it a SIGUSR1, and then leave it up to the process to reload
+the git config. Inside the IO meter, we could have an MVar that contains
+the current throttle value, so the IO meter could check it each time it's
+called and adjust its throttling appropriately.
+
+Ideally, the assistant could also communicate in the same way with
+`git-annex-shell` to tell it when the limit has changed. Since
+`git-annex-shell` uses rsync, it would need to abort the transfer, and rely
+on the other side retrying to start it up with the new limit.
diff --git a/doc/design/assistant/rate_limiting/comment_1_bd0fd62297ff1f87884b41c11fc4320c._comment b/doc/design/assistant/rate_limiting/comment_1_bd0fd62297ff1f87884b41c11fc4320c._comment
new file mode 100644
index 0000000000..5ee5989272
--- /dev/null
+++ b/doc/design/assistant/rate_limiting/comment_1_bd0fd62297ff1f87884b41c11fc4320c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="Commits could be rate-limited too"
+ date="2019-09-29T23:03:47Z"
+ content="""
+See [todo/wishlist: disable_automatic_commits](/todo/wishlist__58___disable_automatic_commits) for another kind of rate limiting, which would also help reduce I/O between remotes in some cases simply by reducing \"churn\" within any given repo.
+"""]]
diff --git a/doc/design/assistant/screenshot/firstrun.png b/doc/design/assistant/screenshot/firstrun.png
new file mode 100644
index 0000000000000000000000000000000000000000..7e9d505b4057e2bf71faeeb0f32ef325fd15700e
GIT binary patch
literal 54347
zcmX7P1z1z>|MqAUkWeWV5Cy){Atf=9R6&&Pl<v-L2uL^q5fG4=iimVfnB-_ANB8I)
zFq#2l+q>WYJ?A>-T<2^jpHJMM`+lCp*RQmhu5(`p002zSbu<hB0Lu5|<rzIC`H12#
z;S}<Q+C@!I4FIT4VYsrVA@5TJ7-&BOR1DqSChzb$>KNz&0O5iFKvXOMa7jKCwFLkK
zNdf>EI{@HG768EEo7?b4nfwE-!%J-q0O^18x8|ZW@{w!4I_3f7t<L`~TD=~s<kJDq
zHPnnkXLr#Mt6M=tx`V0R6mz>w-o}J)S4OYfc$b)Us6>8i=m{6{jxv|0KRJC;{c>NN
z5R5^)S<hyK3oQtkxW5NJ6DjL_@rRE|xb4=9N%A?b=hu70cZaY;kt8#-i|W>+4wGX-
z<oWM)xD3oz2ELz%igf-`znXf%7yBvaUF&gED+4=}?;x5_q4CKYZI>itM*?THS!V)g
z>c5!@zx2*jkOfQV(6H;qM@k>or#<AaL(!4Y$!5~s@K;)Q&N1qYe<dOLj9-m~Iv<gx
zc+*8PKx@HsBMb@`dFlO{Kh^AEs*YK9dJyYNGp&aXoZT}Sn6E$k1w@?<3o3#K{vAja
z#L>~w=sa|AnaZC3#;ElQbUDx5CG@iYRim(S7hCb3*eo<5=E*FSI$z$8)={0XSJ1Ja
z4CPXho}bX%*zNm#C%xr+_0seqRXkGU@}g{D(7LZdawTU;CO-T8py|~DJ9W!<le8?!
zL#&dwyrrl!{QYLw|J{q4BAPEt>`P_K5DAOtm)FlYy^15hj6!2XYU{Cc+Q_%kh_x0a
z*sJUzOHt({)3jIglZUs!W0PpQqvZPklph+*BmsTVT^CX=u6I?WmF-vda(myd>9RB2
zqxvbsNR`ilZ6e4e{o2^=>X$ZEbd}&okAo#v!l1p=3ic;eMTWmDMcJV<x>G67GpW@=
zoi_*^!j)H6VDpDx5_~YBqV!GVKZdXQrp<Ut`m;mdpFu_ycY2ff=sV)y=RXNZ4)UXU
z8o|2#MJ^&WJ;QuJ(6NAs{mZ%FP(7UCxFQ*6FQ}!>PP$5s4Ps5~ls|vu?{b(W^EmlB
zFWZy<vShLcoS}Pjzl|P7{@IC<VBV$UV@u?Wt7Zaz(BKCsqhuH#(6^&;f<svsKSy+9
z(h%%%ZA(kv+SDj+8=F#0qoMTMR>wALkh2x1HivAM+u(>3*L(zhdo3z$xN12%(Z%jv
z0^LW~-!afzldfWH9d^+<bbM42Y<$i?`GaPjyU0VY!a3tobspaAN$Dk=;cK84)f(<f
znsNbJH(gj7j=Pds6Ul8)es*ibw*`CUy8OE-yc}J}(Y>C_7aqI?m6bMO*j=v2Od|}+
zs5y)a;ZH3wbMu1yA`(ic{k+7cmGCpg`ek}bvZbazXxE4Jv$p=<Q|AUraC1rRZc5iC
zs2QwSN3|Z8BS&S;I60&`|5{Y0HumfBc%T06?<2B2^&eHomc`%V2Z53hjm(a$-`@?D
z_$V@V=oEf_9<pH45LBtT!OsRQPqWbNj@zm(KwF{jqDn@F%|ONxbxl_ML8(<!PU80Q
zhtqE#$I{ZpQqysN%$*s<&}NKbq~q*8rKZD$JwaYcgJLA*01Hss!u%0Ngp@10bBz=Q
za4}sI?2KZSy01n-XwERG{)e^E(Ba^e<QKGyszk)kYp=7ag#YaF^j2!&PiX7lkNbz-
z;n(dE+jQqtH_xJrqPh~0P*ZxLtg(%CqUcoSvs&b;3lY%0#Kp;LC*57%P2Q<9wXuGX
znvf|<EP#uQ;yB}2p<Syz$+L|lU#D_4QKv44R6hF2JLyb!H$zPvs^3PzDo6X_Tj$qg
zI&^+|!lvrrp~`+&3eXt`xg44ZxP3XDmYv-a0k^m)O-R#MeIy~l@ztEetG*Sv5DG8B
zNCUDH63^^zZYpn$LIPp(WdiWtrrmX9oxXnd#a5QoJ@$K#35q7`H`L5d`%3ju;iK$X
zb5}Fg%|77F+gnad_&7dE#%|4|KfX!MY4rq~z?IP6_fTVIRmmC3;*rkKhQpvIDu8O8
zhiv_N&QM)<Y5!m1jU(>M#|&FJV?HUZ$AULG*d*;<T<uY!5Gsnad~w6Bk6&tp$Kl^t
zHmKlMEwbx}e$c&+y!=!2=IHGe)oRAFceKv9tHaOWAvbXd9u<=53<|9u>0}r)64xiG
z`X4yvwCe0l3SpBQ<qLhPH0R|Y$;2I#u-8b{{aCp|t0H4?hXy(PiDt6_?T?30h0><g
zX6=%U55BnnkzH62?m1qjd517F`*M#*YPTp2ND4p9+6-fTz<A@DT=w8z<%Ky_`Khvk
zf<ov_jg#1-b)DzTK(-9?y(i=T%O>><p=%@BKeSRN&0_~7kPti?bj+@8ow+xxE6Q4F
zcFMf7Gi6c^R&d%_8h#D%gv#L0c<yYtl>@2i2N!{5r#`1HMbvErlI2SExWWAz%6p=A
zMbhXVKP!-RQV5b*mtHzys;sP17<~3hFz|K48RmA(h+W+uG*fqS(tH{r4yyYlkn~fe
zwuvvH6CgqFU%&ajbmJ*+cAeH@n9xJuk?-2p$RzSD|F3?rQK3O0P<vZ*!lqbUx0Zgr
z$NYJ9u#d0w_K5+r=`|{O9l`(N@u-7}x^W)WOQtBL9{pXRGsf6T5e+u2fq$L98tNj9
z+VGXC7w%Zl4z30G9od*Q6I5@1R-=C=IC;9WiH^}Kf62MD3x3~vhijzV-?FaFZrt@T
z6`jq_*~?5}W8p&G$r8H%*|#Pl1$woJ=e5)oOpJBX;7?3%E*S|F;jui7<_ifpK0U0M
zoP6#i4w~b~^Xd!6fX}P$103r@22tTPsN<&76{)C>cxK?`RskR%LcAd1k)%7a?&EDS
zbY2Vyh8`9QhgQRZhe>zOVd_kj%#sSH%SwtuLsoK$9oFYRd)Vgb7HQ~<RG*XnR+YT+
zz2?L;#v9T8An<qL;e2Yy0x-1qCyV*#ea34IcrNYPM;?d1?2q^yvwV=G?fJw9kKl$B
zo@V$y0O=hw@a$HUJn;g@1qbs=zdoJy@W>BcIjlqy>RVduS1oyE_~qP=_FVczEQyN5
zy5-;<c=)LZvp%EhXIs!aKhQP`^<*@%;H=ZsvL<<wp33~?(VyR7$21D1#Oy|-yY;&S
zIqQ?{l+C&EDm|y&QyG&=ut3-|JDcy@HP5r|mT?`Q?{lS=qVvm2%M~Lm%BQxeV(2LT
zzJ6m9w%xu|_5Fo0K1EXNAse)76w`02obI*g_1HhaMJ2s@ujAUyZt8Q!zdx%PjULe~
z82NSmHqv=)p|^R*2=J3Jzzcqz#SY0l_ZV`DF?D{$osU3nm9?D=|9#iNw%>oTKe_*S
z<1a-`#HI==L1h;k1Pc6{DtH5{dDq3=)s_ARCpm=;I2+<aMfZg0sH8%f3p538;{CAQ
zw5eMk?mmrdHrNp4fb+vg_`gs{r~ZN6m7SVg*9(G@F4{groPT!9gT6@|n2LsOR{#33
zliV!tVju422uySe!c32#d~8mNk}@k@dGk)?Q_Wg-_4UD~X0u1A9^U3TIUAMxXG5~6
zZqEorjZTVYL8$=|pLpt8LReqTKwa(m=JoGuB}g#yb~Mn`-r;9IBB};-VGWI&dZ<m&
zi&Myp7n6r_g^}=+dU;g|WvBG+#vEH4`9+sV;izlXAuVSEfA=g=`79Bg^KvbN!h3U+
z-zq#8`-;BsmIPd&>7{^?j1Sd@79KU|6^!I6gw<5Es76k|1~@rkWL!{M$=vHZbI8HZ
z4%Jysg{<GzoH#0uq&diO@{5j#yT^btTw`=^f2)b_9M4=<R&rUpBIS~+pgQX*m9vKy
zc28=X-07*iW;J=>NjTn}f!95n3?53!(f>-*vOKB}6DGu4qMp9g8q5kqJ`=bNIvQI~
z+9$g7_K#$uY{M&!vJktKEe3DuM+}5o^AJr4x5h{A-7A~zrGr-+Bv06w1kiVUPfP}R
zwP%x^S?SWbw-r@;@afa1`Q1E9A34k)Q!#8ee3M3P*h9F|-}4)6bh09wSs?e3NY?2Z
zfk-3*yrGG%7e&MNpjgmmGso2<P51p<O`v0%{QmQOZ`|J=o8&u39mX9wcP5d)pJ2Hj
z{{cDVTpHyYBes8J$Hf0B`Of#JSQig=?(~j22rI<#vg=b+-48%Yxh%%^GSBR(WFS&(
ziW;rLp7W<t{%#5d+dci1Y2bv&wp&`+_|<GteqdAwu|c=CzKeNwCI8dM@~ntP`dY+c
z$<hYDvqn>CY-w2q9L)R{pzl*S^A_u>RChl1iZ`4l#S<YGoAN3FMm#1>WQ*oZl`*Tr
zAuDi5V#rOOP@(>v9G`-H-LfZBbuZCwuR?7D-b%1hx4BA=PffgPkZ8m9&_`*}=C-sM
z_PwCy8Zyr72d?a4*n5frS^oMaa&nBxd3=YbG(A&a8Oxd`*7DMNURkYm$_ORZ8Uovn
zBK!7}o<mUR>~C^r&Zu*O()YQ=NH4WE1UZk9CZ625Ixh%8T)~rM1!928=M8}Q<8ua8
zUTgy{b%t_L5?`FL42djVO0DL-vdYO;4my+ZQeQ$X@>=_{G$ym(2x2AumNz~O4QRjT
z^+HkMbia~RYx@a$?gK044Hs8L9N4FhGqj2TX`Js}X6kk(M46OMd%Rp*i-(0_D(@rp
zN!Y`=I-V)8q|9NlqP(p#kAm-0YY<3N^Sy32r9!}&r<s{6-tOZs!?(RBj}9w;B2g9t
z{ME7c<dUUi#2t@6Kl$cbtTDRSqitEVKbL47yi(oe5Nu!AqPn0p^tO5$sn*5rT3&ro
z(THt`tlxI9dGqFtw|9lt2iaYwT<m;p#AXE=@H2mOyq?*DL+5$`!Wl%Ohuu_M;E=GA
z`_QD!l!=zLJs@Bi-#P(GgvX0cMv)7*#hoQz3pYfp{N8_+%gCwt-Dv|4t~liV4|Z!|
z#O1eLbK{8Vc6a^n5{WOSw#`pG|1I_Py{yedWttjM)5S~b6^t+C0BO!AdFkqa5~jIz
zmb_}M<JUS0tAJ(mEf*Z9{L-~`R9Bo7OLtg*U$^GHN2;<PGHdm7?>_$FM02v&@Ei1g
z&gd5i$jr#dPCb7|CifkH@33xJF=CMyHf_&xo&I{NP9cZz5CuIW*Y4ONVzt^qi{D94
z@TSY-nwmPLir%;2%ij1*lB4wyhpm3&em>OVu`m6>mwXkF^Qz?>1#PR0zF=d$$gVTt
zBA+<`hox9TFK+f;AQ5x%X)#)V+*<hTFnOsq4xx!%-@j8u(or*}K`C_UaX>>q?_9pX
z@xq@zLG>KwqR#4$1&K13%qMV}GzI`4fX(E3HFa+NM&x=M!Iu7%$pB6h^_<^%9&My{
z-=+opN#~*N+^L8MH~My2<4-pm3^WC36MXbAs?ewDyFtT-apT<_2qL}hKl$F{fM1|0
zppZKzEg6B8ND<QE0)!r%eWyVh%`@cwceR|`>9ha9k!$JDKA%nyjRu!<7b9)aj~0*b
z#I~W5Qs-co_@jF*lN=(y;x?LC4Z>GW4n`a)t}YUvSMV#PxT+c(4Y!DW2FJW=bD3I2
zBt{i!KSDO)d4zT;K=;YfHv6NPh#^%1Ju@@?0iuz!Ly|2~!QmfYu})Q%9$PUZ8T8eB
zE&ZC`<!Hk~d*h(d0Cd#Q<CymSzM#JX>ev}RgAHIR-)s@nPk?^-U{YcAh`xPmq##qm
zHa|603UnFxSijjjgzs94^3`i2qx9!2H}c24Y)Rd`9C)2|suG3}9^z5vv0%04+N52X
zm*iJ<^$hS>zU}c4Yu)lh@qO<Hys)6cI@Y+jq{^$guc@gVO;mJsy`<t9_(+$Ft6>K1
z``BDnkXFG2<8?0V3cnI)!&5U%Q%A=Y`m$^4*U#F%steRB%<A^+h)>Y8Tg$J7VHEnk
zTSYCbXm=$n3Ee4odhO6>PLsdb2Y($=MvkX-ErsbXzuM|}V3P9a?ptCR$GYBI(tfJ{
zJMJp0+5!&72>|N)(LB;EHbuv$$L1GD3}Sthe2=;324ZjhDAHrTbNgD<Z8etIR}H0u
zbqD?#7Nqn<F8$132s5dU>@YQ!C%XotQ%@G53J;3LCYTwR>WJyFXtXY)q{B6or3PE7
zsqVN85yE<L{+Q_B=TPn2^ggwBjR3mu3{Vry;I;tLw@vg<{T@4X&eQn;IKYd|F*Y4E
z;?ppqk$O%l7!PONEPHE%9)|mGIvOYbfW7r(+N}h1%SRZOt|q$G2<vrGTo{i{%Z>AY
ztqDkQ<fhEr`t0A#?$TdGCF_;hGmGBsJm{iDCSIM&gEeAeOJd@&+&vDe=G~OM{JN<x
zA24yl6!~?HuJIQlmB+t`vVmaBDstTd)m+tL5>pO)B^*$D!+dH7!_Cb-Ki}Xtm6imB
zLK_?B?WAiXUqd8nlX}R!h2H$un+F5RKG>z;kuUOGmJ{RSYa1Js3V~b0N9+Cj4Ljl<
z;f4d=u$WV*ScmR)KM8}s8DETP@L%O3!OP1WL}hhxnksv=1w}MKnXT~IILK7junv+H
zunli&dsF=)WMrR1qAFi`#(#(XdsqfJCyxO+++}A+Lgs}6{1mOzP2aqc@@iLkmLrhu
zQTpu^X7D~l`;_%bg&BUMzbTUG)Rg)i-2=*Dvxw{<(-&yty_<7WMS2_ps-NcT+Qozo
zZOy$AFp9_HR_u`kz?O$_&UH*{*YSErrZ_DPvxCMDxXZXQ3b*3}bhrk1z}AaasWh=Y
zV~>?npEO7e-HG6BX!wV%4_Pr*p)xZ|bi&2ceMrvyv#U?v4ztnGY|OI}xJ}d7Sr`3e
zS3Gd~&b{WkvBIB~K`k8DqV3i`KCveJjSxJDZVfre(-&;*WcaAzNkKX+nh6VAY^pkc
zAHodrCth9j8&7n^Gm(Kl@b^ziIk|@VhDV)0O4xUj@7}Yw2SLuIMZ%9f0WsE{fHI-l
z>#%Q8#Lv6xyp-jtD|5T8=*wO{c^?RRJz&z2GO7aeN0hIL;NYXml0au;aEEv@51S-j
z^(jF~bq!9BG9jv8PTUV?bA4>KH!1BfYZ1F(J-7M~=(<R2-_dXNu6Xz%CM<jL+fGYw
zCDo4XYQlkUs!rg_+VlKPB^Avtx(xyCsg6jq0X_9eHk07u8sR`+{n;UgXdejg>C6Y!
zk3C+<*9YwI9OyugrIVax8Hx)_Z(-HSaO1|SmoF{<`YwMFvjmXM$KpY?Eb7eTy0XN9
z;KJx@!!vV`mrCjNmiAsF@ylg#K{Xclp*7oj3kmw@<(gTu0F5QF1^zLev$EvFySKJV
z9o4}@pm@X<%{%$+m)sJh{{pr9FRA0HVd6?fvW;iQpWeq(6Ai*IU&Q?98-=SCxKAI=
z7j!5&X*@mYe&M2hT0Mq&mBUNEkjoXgck$5yyZR}!<|2$!TDsfYA?Ny^{U2wyz0J8A
z37*y)@g25iy4=v`mRWf7>4dH15=iaki}fxBDgsp#=(4m4Pec1Y9j0P!S+G}ypm@}8
zA<AAbGQ5FixXm$?+xT~>UdSvvR|ZOG7P#A^mmRnXBb_$_Nr#GaNTg_X541D5p}IEt
zf8odV!X>A9>@prLE&wX+Z~o^gColKdY#<lr19`VOa>)6yt22PTW#xr27DuDzsMVL=
zvO+-+6kO!RFM%c~L%N3T-c5H+B(d7b)%JB73Ws0mR}#Z|XJ5t>-%91Ki^(!&%ndS`
za>j81gQtxVTk}Z)VNiCKkFvIt#X#C6%yMa^aLxMg25LxCTiZ&S?l$%k`1CiysfUBE
z#RsWN*uIME!`(Ndg~t^i?Mp!E{ybU_j8T65J-g&F<=@c2(o4?_bd5!Y143+Mm4E0C
zUH;%4ZL9BTygHuw)L7#}*1EySt=ai5%M#FcDJtRM;PdDx22&c$QMZtw{Ps1A$h)qA
zYtewG?R^zC&F+tbSH;)9G&MC*L-X9?R3^`^$duwoUX^GLYIq@B`_A?9RX-h_f8+pE
z?z4w(#MzQAIfiEv4&%)uR0n4Nmlb!GSaCq$!`7DojqklA{H7L!BlCkAuH+I&=liRL
zghhApcX&{Cj=l>~IUZMFjhR6WMndpX9p3|4b)$EFKYxC+2lw`h7eE`{7*Nr7zfBEr
zt1RL4kU71-Yp>-<tMk=jLj)q4bhS{7)9mW}a{;G2bz6)C^aj9YYfr!VE*ZlEpN<n4
zw5UU}rfVpr_sO;HcuTt&^v1Q_#THn(Mk;etLohGO+V_rh7*XZkLi9RznU(EHryO&g
zEyUJDFd!f;<d1TPB!8S=KtSmP8E{%R%Cs4Gw;V4lB;M=}$A{WBxt|5zlzsd-vSA-;
z;?g~JCQr<N9ul-rD%vr<SAlg$PMz}I9IY3}@uwwvxDIQ^GGX3UaYuDga&ROLxsDrI
z7nhcRG3)E56(-?uo`td=DrP<6{szhV3CKIahlQ`C)Z^g5RY~+>O2~o8e$_ReiIBI+
z7ocb7m;kM^gE%u;MD0IS?+jib@xR3h_Qk`lhYdcxAL`-HQWbFf0X9~ns3Qz-rg$FF
z>_rYx$)_eK;bN{aXH%KLJhQm+u*0wiC>_I!P^rAc9u0HYTp1ZCjkH&JKiKdB;aR^K
ze`i+x!k>4JQNQ{50UC{jRs9$GkEPM6wm7S~PO@|Xw6k1fs>1h5p(I@4oR~ed@F4tI
zp+Q})-aVG3{gsuK<>iHuBmPt!e%2lht-FNnKXy{;os^%dDl&yd)T1M$^Yl6;g$rw1
z+Wx~9M5J007Jl&2Uw*}KY@qy7d%2Uepk2g(qOlFtN$@u<SDvIl_Y~_qp6y7hZslNw
zrUpGok$c-N`PfAyWFPLX&O-felZmz?qvWMp%rmcuSKGZX5s}LIkVTb`(-|@yn(j~h
zuGV@Dg6Ogj4EGzSX7V(^0?MeVsR@%@6_w4yZ62&Yym$U6dqV8uBEG)9n$dS-pxzil
znro1^39)x_$YykwdH8u<f@Hh4Rn0u4^F>F4DM`@ObbH%SzVEn{^hZ)w)EN^1=fQwX
zI@O~2eD9iqi7P9{+x`+h#RC(Ues71TnD4O7KIhxl@bcPwbZVZR^Mh`uZVGcX?Xc3M
zJb&9?J|=bN>P?4NOT{eV%v~u$5JBdS`PiPDKZ>GlepTT*yG`b#7<g67+U%%50(7;g
znXcd9zO}o1$tHA@y3IjKek+Loz$TxE9bTOFh+o{hY=*IzT8-+8j)`&l5{YmrRIYd(
z*6uk(zyM6AIBzOi@Uv0)24y@UxOllkE?%=fHrbWdG0gQ_>UY!^1&__hHq@F)+{d5d
z-u!)`Cs?2%?AYl*#__=~%9A<e1_lRf8^glG!>>1)yUHv6a<S-gOshV`o|};|8|nS*
zaMgXMB5-v}op`sTE}rZ2q;MS5cb7*jk{@-j*f+MOF3_IXX#q1IrHV=@mke9<a9jGY
zAb%8VhXZS;bgxQU(Js+<v-Hlw-^dGT)G-!|4OxuPAO0jM`8TqDwg>_&B8@J5iD|PO
zC2e(OdN?5pn}~0WUN7bvvGzzYK1h9m&F0JlRkgM^Nb|FjqtPP|_Sl;O0`G`K8yg#O
zarEE!#nmHxfdS68E)(!1QwB;2X?f!EOi?IB5^VumDX+}x;XtWKW}Zprcg3x`i(or^
zfUoN`jCjeM3^rc>(sSH2^S0r&pLpo&-#U>X-W`2!8!}QG6x0g}a%?`!?r~1&I^*qk
zy2+xTD|l0$dr&%C!|t1h=hgXYGZht;uAt#sLMj1&D$lKW?SX^&wFgg&WQ>gSgM)7-
zrezO0C)EXSmy(L*6W>-`pX*^oSq|imILHOzv^fRJbo<T*V;U;*c<<afanxocQ~9~y
zp%MB_&h{fU5Ct;;jU(kwnRu#>V8DoL#o6&TzI1#I@orNriHS+pVvrBQTWmBMCQ0kt
zva%`nsM;~-7r&f)Dax%h56$P_!J4Rn#U6c+p+t&ZYKqzye*DOq2uRRym@E{M=f^pr
z%SbW-S`zi1&j!q(@8v_DnCa=D5;`3uGD67ehK=d|Zo{WLMvm$+XYRG_n$q{38Bxb4
zF*83=Qj8rh3df2bQlH>fxP!=o8`-$D+PS!OyS1+Q+y$!U%jbyOws=aPt}_|Onwk4F
zIdg7kj4)GOQK=|5=UPAT?@%;6gBpE|O}yD;Y?Fst<NxVW<`_hN&>}(I>BA9<^0N=^
zrTY*8czn<u9{E~W{7!<sJ-Mj`;WM6cV<86qd1lB>F2<zrykxEN=Mh+G=h^h<?<lCm
z*x`j^+I%ddcP6cO)=*ALIPlpjYJI5U)y-eKnKy?jsP4zI_?HG;iUDF-p3#2~)uq25
zI}do+jEcUxj@j9PToHf6J=Ey$zmjyG4-LUB5({Gg<5|25z9MdA`K{(zGd!dBi{?cF
z!(Fa?NY~D8rT7RI^cd&}#?JeDr;eyKfFse@C?UqB%QQv6!F-ly|B_0DHhY3jPb(@u
z+-nS0zC0*!POGLvCN9&b^+pzBMvcoS`#S=nU@&Oe9n?A2fLv!+d~bWZLFV^n98wdy
zyeqt~%hyA7oh3PkY#aV1Xi#0^`_SR|^T+U+NNjr;3{23^gfSd4f71EcJn)HpM;`;k
zs-K=$IkXgC{bN;vuud8sBgt$p?8yFtERS~GS8rdXit%v&1KUIKC`QK4*D_N=3Pya5
zOSg-T67R}t2?mhWJpkFJy}SnNk7UTGE5I4M5c|kf))bmdl8pRUwUF*4$&E6~%?ZU@
z+t~Dd<=*>ViM-ClwT2m$*XI$6WjV4OZ4NCfFAoX|0{X42JxEbLT8?joMR+eP604<8
zw`ZmboF^>wnjqiWhPRfN!$^O&%_BmR5<g<ruX)s(JdhlSox|Fhe_8!Vt6nhUNy(Q{
zlb@gOsHL4VxS?(f5y%u#7&0?7oXe>pw^_f0_1C}<{{B7;#(f^G!nU8+0NjN0K_L42
zDLW&M<o3?<y^Grm0glUZY7BBH((qs_q?zUYy!LKSgBSE!emZO?{5~Wbm-WWQA|m8A
zO!>BA<iGv=u+Evi#`}Q}csx8jtgUVdy~>T;`W_#=H>>EV<*(Jf(c|*Vs_1KdV|^ab
z7P~rTTU2WJpR%*^`M)9be$U5yMW6a3zI?B%n;aYjttIFr%S?{D3b2vsTW52w4oPK{
zyqw%oQ`f|VSaAEj$@TK@4K5W{%_Zff*<Tfs>|fj3im<=L?0DS1j&sAQ9L#Luxs#H>
z1Q5Qel99F}^?`QsJtY%ELr1;Cqa$vW@RQhUH?6h;b6G|`G=X_$7h^1mjUNzM6!es$
zECHtzJMm4ocq4BJ(n_k6XEpZ)Na(^Eoq-anYUP>n_BIroUotwzAtG)>bBP<&cCaC)
zuB-|TI?Dj^Hw)Q%W3Nd$_Gp}X`Q$1F1W#ehc)<$Yk{=NWOtR9-=U;jmxW{rc3Qu4!
zEe%D|diC=~t7%q45G@h-Jw(pm?iQ~iz1Mcb-z%AIN}B#l)d^~NQg224*O9W$OQ^6Z
z+EMeqjEkd<v0qF0*WFDU)5e$9iwQc_>`7S%MVvz`{a@uO+gO_R*GR{-wffOQyC_>d
zrEz5&>l{OO6js+F_E*Dfib`F~v)f$l%(GvaqK?0~;n0;Hu0}A$G1GfNXS*}<i;>5r
zl`YqqnNyOJc~m3MPqxQ8IyzGBDjsd*_~ffZoHcmzJo{I!Q8bmqCFLTS^-*i+5;g1^
zH_(w0-wS}V3aXC*q3=9)FAW>c*B)_X_g7V^iA$T$WPeaCUb8hVyFAl**Vx!tR8$ln
zukGu502=$nrPx2Y$9v-CbB@Q;(b8W0-@5OuxGgvvkApOoOzlKum#ZI|kv~~LYG(SM
z>)j)(-PyWHWGe^Fy}Dz{kvUSpAHWO>+BPuMG5L2prAYa35OEQ7ie~7I=F4sL1-E<o
z-R;TN&DG!+KPS4XEwdJ9aV^auAxJPr#!1mOlDIeGqsh-2)zH8V5DY-9N}-Mmor-Q@
zZ9>p~DI>0rIl0YDOfHXmQ{cFKQI-3tFLr{0n39;%u-W_}A;7aSzx@5ZpF40DRLk*@
zlDD__O`%st|J|aXph!(kC9e&C>4stJH^~LXLfGcL>%Fm`Y}lk2r>0xExa+&MDyrM2
zr|n!lAIop)X+6+QiY|U5Dce2{sAx0rkYv!!<Rag)Up-4z;0wnA8YdKC+p)3=3=0jV
zj~*T#_9eF&1BZBeMuwA<Q~lq+p%Hi^6O&VWpTB?qv5RKmrq&^3q;y1{aJZ?RJF1J2
zZ<#Z}DmLZC#bmBX=;aF@@YeD#yDO~HYIl-M4tKM0iK?f4gugsuOUe;>j%h_-!`-+m
zSygAUv%P)V=?Gt(X;`mN!X5;k`-xq4)AH^U*%E(NRKz(s^?ZOxa&v3PF(X<mFOQ3h
z)An&kCzN*8W@T+;#Wz5HwYvB1W$~ZD@qhomtGD0b4s?cV@~7Utz|NJLN-Xl+J2rGn
zG%0NsyR7S`%}bP7PzA5(3qg@$=i<%-W?!5lCV{ju_hn>cl>aw1{rc7IDQBr&RBq~R
zBs@W;5s`Ro<G{dxCX~IF_iwPDUvY8q_IgyE*v&Zm@GB4H9wNKUB`NvoL+`Zw#>1o)
zi&Ptyr1Xi!<LQTpcT)ER{A-I^LX~!?ITQ>`{Pty-U#dK#ppUNJO+%c)Tpzc~%1sl_
zdSIhFcSyBF!ms%-DxYGA+cwPn8r4$f%Ki%xCgz6=GdT;tMdy+DQkkHYZyaEt+um1G
z+wg6Ho!B<H0j3G<#oqI}g}J0kaOmhi;>dHf$oeqp3LDAJNM+ac;kJlL*_K`&h3khi
zCkSy&Q*hY!x6aomFSx>Bd*x}1ku^L0y!l}p+26kL0k*fdCoE_`-fC?QSq#RXzX`_I
z7ew!R|N25ERqG=!j*{zY(9yG|3!`SZ)yABoTK<^UZegaI`7cuc(gdX!ot+oW!1Bu8
zUiH))&ns^FC3-yFyysxrZ-e<A*hn+u6@eE}>O0OvTc)IEz@#iThVt&P45xob+hA%o
zy`B^oRad`xTVn>v_{u>oBN5%p=c|>)ZSTz4_Rvf>Jf?8uKl(4?s@F?oWjRVKZZI(!
zgxAMYpA*Z(D<{WK48u;H<%zq;R0famTLmc#K~vV5;?@>5Z=Y*v(MCb8R(bvW{CYlo
zC_2}}=n=&Zl`AKVaQj7(D~CN(m5WQ{%4%<qptq13|G5Y!I48bREz6mi{-utw+p#CP
zHj9azm|)mN2tGD3EX-Cv@AH4`iK5D+-WGiy7)vH@Z;DwrN01eIub868FH_vq?T>{%
zGwL1Hm6aJeBr03J@hiNnLG(quemxwUm6b~cL#Ii)Ew#Rzm@sW>#t(vzvOgk7A^Ojv
zGvn277W|q0ny_3T$`03gSkYo(9ky+-mcS||Y&X6WNbW&KP3|aWvqWRVLcQRL={|K#
zUcC-Y{@?YY7NagNpTtpgEVX7TGD<od-Rh8Zd{B@KQ>Z6F3D-gdI29cy)}ashwZi^W
zRwYC(TKoB_Fns7qzDFeqx;$xbf9CPR$*E9-{~7}Wm7QG9p!4y;az}aQ7a`rOVJKnk
z@&j=$C9W{~C)!SLYySPAv{V$K2jz*rSZ>lJ+c`Fz^nlbUl*x!gsrV5)2CN^UngM*k
zh^drcZvu#sML7wIUR8ik{noZ%w+h+g_6``VNz^PxDr$6e^kA;&tmZz9M=6Aq#!Sn6
z7hpH~0|*s3OOYt=GL+g$fuak6wqDa$Fj<MDoB>JnUsf!#KGUW}okhwT7On8CDvOAJ
zvwT7WeQ?>UZ!_sNdva;3rR&gX0O-aT(&?KwSwQx{!9#&SAo9zjJ$(IxVEHubV1z$D
zde_9Jr_mUAa1~AA?La%{f4v0m{|lJyF0Ws3HVQc-KHhoH5q*2KGTAh;=6ID$Uu^5A
z`mX!f%ixy?%TI*)U9p)r&=SGHk4W1e=#zbM`S=)>#pfzCt<%&0bVMnAmT3+s2b3L`
znUtsK4XGTRsTY2Fta$`R#=Mb~@mf8^^}Hf(mg{ymj7i%SN^{gJJGe?lC46r~=88iu
zc<(5tja<e|Me|(|XVU!&;zK<2$>B#Td!VhY4Y1~4e@X)Y0)fRw;cKpK>AfJ96yz0V
zDMMreCxjNt>`&5)F|qWL&bG3)wzjguU@+m?VJ@o^vbD8k<K;h3vk$YR9Lby>;>D@?
z(7PVq9ME!mmr#CI9%0)BpxV12A2BIoT44l~^%z=6QT3~$<tPzWSC1FahXnrnbZ~UM
zNs%iC<dE__-xb=>V7%jpIdKbl&+q+gmzay{6X_E$aC4f_WM;-G>K9>AimxqqUgIm>
zWrYhrtSVHSS^2dzAyb&gR^XzMTf?Y;v*t!ZUI+qtjI9f)^NtAFISW}t6TK1LrKnsb
z`HO{Oa0@snsFt7AaqVx4>dcO?qqdfYS-%6Pp#K_uh&-a1cTYBFFgoh!1Dr^t2+?gK
z_p>_8_i7^hZW52mY*$xTurQfCkq$p`-BHY*@jN>^GWhQn0gppyVUu&`@SDXgL;`^a
zEM-(E;xp@Oyx4U45s65#eNnc!Rg)4zF|FWd^cQjjfOX1BwFrXT@R7-7`BLp9;(wLz
zid4;J-wZWvAH_A&(w;BK|F_hOT;O4{+nCQ&mN>a{R5JB#;*vJaZiIo-#aiX{<Vl7%
zy{$tq@A#V^HW3$rNxm+zz$m47y4(hL@3Q8;oRfI45i0lYj-Ug8G1%>R@Adg|yd(KV
zye?zpOC-kM)0_i_Ga+!?DWs*&8Mh(3{S~GU_${VV1sdF`ET5@|pi8axP?N?cWoCYt
zt!F2sTUQ}_N?%uPDMKM4eqDu^IMs8h)n;D6-OytgJDjU^!VyNq!F-6Dw&v?}i?;Rt
z0s!6+xAewaPmz~tuNnX3d$YgwoIkisuC4Uy$1ie2i@BrP?9MlVBsa0-%?l)nun!0Z
z1yZ&Gry$3DIkq{v?0`+=&=qQDzX(|~X^}KkD?#H>{Ehx(^999u&I@YX(}Y3*b=%3C
z$xYng-^ybTi+iU5WLNYS1bkhEk@jIeS9n|Ae7t+3*xZ@r3|Q?<c>htRF4vZzeJh~)
zzBtFpkK`j!<d5UCH`F3O0p0PBpeP%uI~XMl3*q9bnH0WSTWhW~+42T*x${e<$Xa4X
z3{AestanInvPEEgk*Ln3dr#fm%X_Dhc(3u66Lv+0BrQjB$+uuPEH8(-bB7GU8nj+j
zZP`yATd9MZ-xzkdx$D*jktzMNw;NYo!t(Wv`Vi#En+Mw3$#<n9&0Kw3e<!p7v@{uS
zFx}vkik#m1ms(Jub$NmdNNa>4r}vhfXg}&aoUIQKib6Mrz!U?tD#;|-#BB}^az|0N
z(}|8s4Mj!UmV+MP{`~231=@T^-t*6fC|lyg&kL&iHSkjbgDHuYD~C6;3`!x`EU5>I
zN=gwYTT&CI!tpn*QL!l9$L9F7WJ^2s<*S$@^b@Eg!I7R|Ffsj+VNH!{uH^m6Hg4An
z8>WxU?w+2n9~oy>TJbzl_;Yl$UTjE9E`iR^PmqD+G;_epgZ(h_CN)B}@6vJB0Xh>&
ze0C8<K|wBblzk7DI>vZ+Yv}V@)c8~79&eeOnAp5g73Tl3-k8sme|U3$%L!;xQi36K
zhaga%20s}m^%8f}4(_W{(cbWcPY+i~a&Tla!&P&oojx?S6Hd%)i!wLYF_`?@7Ut%P
zPJOokb@uKY931bT*@LFKx(aQP;E9Qe7&>Mmxk7l-_jCE#;g-<iT!A<g7X;dldBCif
zQ%yP-=*al|ua{&2**%$4S01Dk_hknp+TOKX;-{6w4dSMnnu52Ha)@4c{ePctayS6R
znlGPTef!*FGB<cJmU3gC>ys~WI07K<uN-xcD+PRxU7aW*I-qkFArMnDvuQ5`+IdjM
zBVsc9NXEJF(P^=e7ftQ+vWk&MD(n2T01d`;o}<#*CvGun{HEg@-b1RrVbGI9=7kNZ
zwb|yQOjK@@@PFEj-d{(<YzR=u)@xR(0QJ*uuM5LXiLVu(4=FKWZAP{kM0>x!AAeZt
z*PyGLAx)Wz9%^IO+op6vL$GnuXYUhy&ZIIBli$Oee6<fjf)3iM#q@dgf{cAYU`#Ow
zQSzxE@d_`!l)fj{vA#MdlQIvKpSVOzo)lk5vC+1Yt#lKT0qI$z+x4#0=DAyaG>rvH
z<htS`A02+c6QJ*kO74)MP12?|nrf+eaNoMTW!AZiMne3Pj=<ha`zWE!Zi12{qH$YC
z#Zty&sAKZ-)+U&rSJCa0=^XSCegW;gAvU7=`L_^H>R(#h;)?1y)E+}kV|JwG1_|VU
zl&Hx-g?>1*NTB?!G}{-<fcbr-M@`%;u#ICxA_|mMuAaG9x+Z<SDLs+Ucax6XS!sOh
z5?_x%jX4Z^E*M`;A2SreSD>{08$mwe;eK}?`0f18oK5#e@D(<F2hAy!7-);RcX&(8
z>|Fr#_s`~jgSP8(o0ZppT=ugk7THN1D~FP?QuTlpq_*2LSk`7Tapxr3L}Fb2dQy__
z;h~#hH5rJp6@QdDBoklQM%>vKpRm%Ve0|Wr%gZr|78OIVIe!KX-3<--Yb@mcs0aiu
z0Hsni;%a4OWnf@XmS#zz%L%azk@>T8HYXH$HUq9Ui#+$`0qE=No0^&eqWS*zu5S)y
z(9zMIDjW~3RQFDQ@-=O@^danT7r|y~JvLWUfYlyT6=a6Jq|*H|thA+9>169cii<PY
zcg|}S4hO!-Cq4xe<x^D7*6{mC-kUd%4}~I}Rj)ohkUcm!Q7}I;1nz@@c?uOr29yUT
z#UDOEPL5CU#GZXnWF%mGasp&}PT1chsP)wZ8FSqB$NgC0MUq+$-nred4t3<r8g!0h
zy%x=vp;OUQAkv&s!jLK6AactEl{Yv@kPhGd3tm_V&Sbn!@9UQeIy%&@_VZJF*M_{h
zg1;!<b=tPKw=XO#B-f&KcAm!8)=W>Qwm+VrZrp>`yF@lsibNrcbba&YUWcr&WZK?J
zZo(&Lt1DCJa8mbo0zPizBq9r54>BVAxP%LKtsa>XxAp*71{_$Y$5NpHoeL7uC9KaN
zA=zwlNAC~8jy7~xvu~wW+O(Srr&@Xif!U&f8S+q#xu&2qULvE`xatUHHT_gwF+Dp&
z=aMGV>8Su!8tgf@QJEAG5A+dz4owd~L5LrBqyUq7lqSz+tSu~_cut1`ipDuEnXmH{
zf2LrOI=Cexgfh8gzCoY*5-_hKy~N9#{gLTZT0R8eNQa}7e0slJ>Uwln`*h>e0F0HB
zuWKtHo3qtAH742FHo^n9&=I06?U=4VR(Sno8y*IVQ0q7+tDR4f-d4y2URHpe4shz8
zm7#3D4(Lb0`?*Yhvq0ESNR~pxo0F$uZJLCh?HzVe^Xbq+ep4}JpnTIH#&AQKga2j@
z^>R#%5P0V6>GZyhWYF;c_prVp6WTZ$x`yX~haYbch;R?5+8MHkeg21@HO*(WOrczk
z*GHs3?@<Q&z10r84A&_zBp!6n*)}o&6CSLrc?*et?DUS$6)s)kKB1Fywm4p13NZEv
zgy+KNUha_*?(3Nu@+b%IkmrqIvrdT2U0%Mk;JCBGxyjETG)WC7h0oT84xQg|Q0Hf6
ziE?N8V{XC1nAaF3eVayFa}?nVtplF&O~CN+Di@6v98me7chi;^czDd4ujd!wQJW_J
zm{YDPBdl(vCO#g&%B+{n&AM@Z-%cQ{`mT#=_{kQDh(nf|Rvszuudb5mkNw#9@ADJ`
zy2Gb*_v=O0m{qQZi6~tEy8n)1^<GYO;_4*P1HGT0r{w<@r#0*K1lseWaLTwmc>b@S
z<-)?%iD5vUR|KwC$Yp=FR_5WupO=^kH^U<Er+UKKHNTme2;RTIYppTN54{$N*gZrK
z=wu|GSpel*Mf;A5awu1cV7;6QULerY(NWPeaGeC0&&Y?xgYft`=6e>FrkTg<nZ*Gx
z!~e*RQ*!%yip=IvWP{Hl)$`{zHa7;bUp{nc4gJRsrB-|W@Am2GslO>6b$eO&*QyY>
z!T0dTs3F&F**^8<t@P^q_Ax2o98<sLCh`CRk+r8TQ)itYbwpFwc%Cr6W4^)okw@v5
z%N^7&a&lZ=UIr3Q49(24H2B~AcWW|W@Y5%jyjN2fNf+V&&?Ap`CEm?2F@<+q_xz1e
zoAa+uiw8Czdv$~$t*!^LLJlt$Os9yAAQSJwDTl78M2_8!yEpkHnyyy+1-^DvlD0Bs
zc9-hM`0FM(GXD#kdyq|mg>s*#r2M6|j>&2K0s7Hi3TrW8Aoo&<ZrySBxRt-)kQi&9
z6`_4jnPAj=bQzIbTE=v|#T+F+aXU`|A2>U(!4_-VH?-)t*a1+`+MrbLAJzL*BWYm^
zZGCAk{e63;++o9lNi5n9XC|%I_rvWReb)ZM(SSBWR(7+m-p~^K7>MvqG-%Hi7a<6e
zlmLtYdl89zf#+`gx23#Fs!z*tC3AVaB>ThYuTYoSO#kg4lS?aXDz9(wIe)vVg7z1_
zly&JlonJpDU2KK}YP)CAb0PZ85ckgC32M?(fG_sWy7b`HohNE6w`>TrICxQA9Y`%$
z-cZl0x%Bt8J9O_oTF(c;CvWPA?_*|s4QQ{{m$@+&M<7-!b?L^3HPnk>@2&XlL&pHV
zr<t}FJT?miackv8RsDiiTIw)mxzY)ayr#%nv`vj=I6hk3wxVwC?ChmQ$h%~V@y}?R
zqXVw#md!n^KiTn$CtPWFDqp-WWnZAom$wW}>v|~jfw?`fctLbLQ8%fnc*Mc`7PX9R
zar1nO_nQapl(grb;V!7+u}xdE%UPs}M5;W{!+df0yr<AZG}`sGZ);PLOK54h|J=|)
z!U368?s7PUO0=9$A&C=cG@%){pcI5jM<RhyiGBziAL>k$Jz(W$#I5UHo3Q=Ok7Uu<
zA?d`R*hoAxNB0+`xtiE3WQcv0u&=gZ{V^m$Bx8bm@Ne}9m!%vk%o*Fb-$EESMD5Pk
z%P1)56pRdnE`b5PgAcmds?SH_(<pu_&nCr}lW9c$IL0JS>G3Zs7|fIK@!ul_S`@#F
zOO+0~IEn)xMV~~*i}b_(M&v4mY>esSR6<Dv;lj)q&3|T@WSWCHgc&~b*g@m%&^y$w
zYI4lx1zC{*P38Tsk6&n5S3L?i7qXAOmR$F2gH6_b?LCy^GZyxJ!u@&+@N+1xIkU7B
zqHwml-fvna)0O^WJ$BBUJba;-aOrC>8bfAft|KLyK#?d&O)m;n`RC8$hYzWrBEbam
z2dQ@KVWg#ss;ZLQ**+rk{i>v^W4W8Y7Tlnzaint2tnc<q1O+Y<-$tr`kCyoc!+WLu
zBKl#YXJL!DyJrg2Lk`N2k`c!r`xCD@q@sL+kraU{q<`K+R)i3OH68NyjQ+I$+>#wJ
zGobt6{-=iG0VZQMW(dFvJ;gt%zakwgKXJGLWt;MS`uA!~H8BUK`@Je>t2^qDJCfM>
zJu3CuZ6SYw1@$HsYl`2L+9t3kYzjx-hItLx8m$qe8(7<IM5<D)1Elix>uXSpu9R;T
zG>d|T<;h!;_DpwakJCZ{pBeSbJllVtsCXfsqj_J1X<?*okz)6%_VPQ&%Y^9oH7tJG
zq3ORbOv;A2b4TTy25ZulzYbeV1<gPGP<vz#NQYgqvrySNm1%x5=PvE4Ac&VTc!_){
ztY~^J@j2++$?pt)hDzD{vhss_*lf}Dx9aw&Pw49UYSJk!N1?6N)2CLRe}c-H?#L;h
zFU6>-sYPq{Sh{z50;q|j%=k3|tqkL;KxW<kX6Z!69s{N_9kHmp@u|w^48m`Q;jHfI
zBD?FZs|Z3OA>+fWDGv*H9&z#7YkHrz@#U<tVW)RKK$Nz2TEJ-O&M|KPE;lH%G}i6U
z)O}(J#SHJ>n5}{^j+Z&ARLoAramArv4)+;7y2rleQn?qLx%(gLY}Y%PXyb{`muPly
zadEY65OdLbSiBxu-0IuZYA#9(ooUTEZPF|n$szkDGyI)A7d1SULp1tl3_h>PIKQ8G
ze$vEYdmI>&ia1}Us?RCS%ry0Cwx8jJ1z#<>ubynf0c3<3AK$}EI@k7Csj}}Vd!$I$
z68T^K4m2nEcV%fkC{ov9<>%-qj4N(?s?zpMXhu7QC!_c6i$ViYb|i`TD$bs5Wgp``
zWNiz<78w}ZPH3b+7jh3Lb6qyP7mg<9T?|67v#gvfp%*WLATTg!^jV`j26M)%aIibS
z*n9hfp%XGRJe2Hn-iw=f=XugoM0Y4T$*qBMG9RCU^D2glV5q2f#P`4}h2TJ=9g(Z{
zk@oiG4(%KFxWOB_7T90EC#__2#Mlzm;hp6b?y~pq-xtm}THQ?nL`JOr8^}(<;oLqD
ziu%CBNRkWltDNBV5<$_xgq)l?ZC=QD4v|YGJdmt&L`F89Ui$SXT9d^Gat&CZog&A{
zNM<UbDJlE^rRhKrGy5FxwFd9Rrz_)T<^n>fI5))bhC?a$uf4=dla@K0JNrI{@MOvP
zjWlc$dAMEup_f-fMJfk2nG^7wV>(#r7lQpz-ajSpYm8qTB_jVl1>k;p*9Q#mrIu{~
zF(u4!k@oht2z1<6+9|ypRH!e^jQVjykFo;JO^Pb1Sp&eVO#F9-Kyv=wuZ7m6GNarY
zULV=@#q1+Nu1iIg*3pZ<xsW)ImVdZaX5h!99Pd&Ww{6s<h%TVXy2}r~i98H`MNe{*
zT}?Y!`pBwYSit)g>Fs#-bXPo6Qvi7Eil|GijDPIe2j5wkzRf3_)2(~^CDhZ$Yx=0a
z%zU+cF+DDp76cBQ{~knIDFhcqYd0<_0BAYo*L!h9xKg|EdDy?Vb01=Q^cIgcEWs<?
zZf+2aiPP?vAD>@#>)9SScegx^w0hT?wMHWxMmN^JGo$BoJ3M<)=DNd>$Frl|!+WRj
zl%l-<F*3FxZd+^PxT(Fn>+Sa#+!{nJ#@bBk8r9}ZiT=hD+B6(j(|zTYV5+BBZ2r*|
znU{$S3CU=2NTCq-ejo%?k}XTSQIF52*$G*r&9)uu(5uWnXosIEUHDI|lX0ZjKkvCc
z@tHUI@u~}!!7HIEJ&-HxoVdeCE>iS=RUWPho!92QEf=H(h>Yo)ca^#m25)mH*?iw!
zY8BHZy2T~alati+ewBvjOY&wr7_$4b%Yo-6*Nvy-)OU7P=8~`brLjIak&$%dyG-U<
zgF`H82QL^n&}cM`8a*RpQ{eXJ(;K>p8tunTjg9zina%Jo<<?KE^In-wAz^G$GjFpL
zkL~j}8LnS{E1g|bB-A0v8(CHQb8VC67`9_lr#mAdbl1G%5@QU1uXu?bsShwfAQ5}@
zE)axc&kYFaoxkbi9KK=xy_Id{9D)RQG29fnMRqZPd>)(Iw{OG1bw1rOW6h0_w$sv%
zcp-EeS%q(7XnL_tAj^i(WC9C2H)akAL|MAKdqBaLZvU3<lNCRaN`(i2pxU7L8|#94
zd86e93k!8#UA80}!-9*coJtf3Q;b*u<M%~Ot(z^ps<UX+mT2tJm+~CSxOt>J0XH#G
zX`Bm0EHCbGh?_0x48;c^Ic2;fa~6SQAM<IsaMsb$dGTV*@FfESgO@23f4U>@Pj=mb
z0kRA^+f2$b^CIHzFc*oR_-}V}RC=?DGJTw8YAqa9=e^e~y<Z%khjw_@Ahtg|Rb(^o
zz<N&0Fy$)66`D5U;J$XTI>O<8EAv9DyZu_z^Qx>+igWZh@~4=Yr#wv0Xa5r01B1cv
zRZ!idOXQ*~r>?m8C<hGEXZM(-<cRZfj2ndGM0XI277&+67o_#c>}*g)MFl(be@qc>
zJ^)3ojwRR<sns~21d<uJ2l}^ir)%A&GWtaJAVb>g1z!=5gLXSdns<2%OBU&PcmKq_
z-J!~oux+_}Th@JH-{2mqbL3)%(9~RMWU8G41@DxT3V*5Qv}^;9!H6Y@4<SU?h!@B)
z{%fmf74D)^@Tvdh3y4AZqyGMW9H?&p`?gFt%SVcj+^Wi(t(z&TpGSv>LyM1A$k-x<
zT<Dx+j;e=UkaZ*~I>t~;uM1gg6t{ZfBgy&GAb4Lp0{j2Sd&{UO!>C<&h7be=1OXM0
zP`X6Wp*sWw=^DCg=<ZOFMpC-FYk;ApyJKi+7(%-7Jo>)xIqR(Ro<HBe@B0>O0kfXD
z^SNiwzOH@k{j?O%XFoQr)+E3H)HTiO{T_NmW^Y@LHj{DxRE%DefU1$Nh2KCw3b<it
z$WA}}eAsj{ywvQO|1l8=T@g}Hc(3<90pj-GKcJzZogXYhwY08JCq5~^IS}7HVLug&
zk@q^)e136a@YPmjpqu~r<8s)KC&$d3xVI+NlY_}*EHr^%I5hOv$Mgwzt->Bue}TMd
z3f>w*vjsnMI$m$5jQq2@NyDdZZ-22wUN}h0WVzj^bXHWGOqrIpy-9O(bjdDIoOVX1
z|LN06XQz0)i7JySK-g1Z^N$P|S1taTrywSNXE!GtZ{m&aP5d(CSb2kP7-MB2vHFkZ
z*>c#(xF=FbOYY1lQUIszMKlnx@b>l&4FN(|if;|YKL;i{t@$tl8XGpf!j}-61ppW>
zPfnUm{JBY|r%Z2tvwzjf>f4aOS}6;}u}bLC<>T+ycYbN=>K^TwA@N7t3e4JPwcO*z
zt$NBRq$i@?($v$hBz86gTuy(?_k60*aH~dY>*+ynCpaML5K__^okkbQ2=X1Fig}^~
zIaAKR613{R8fxztkci*Ez*r2@ki>1t_-(mP9bSNb_>h2)I9v`8?oNCXN=;1E1ZV{S
zzGjLAX{AT>Rqf@;C4>0yPA8^u2Rk+M=p|?v$C0&EIqJqrn&Hn$(#D|rZ*U)^ZLxR-
zCKi`ZC1c{+8oPx8epnh-hcFG?7cIlqoQo^zqmtJtawbh?3P8$f+|;|tuOtqA>;Ghr
zw2%bTlEmyd)aLoN+C(<6-3^2u+IarykK4Ui_SIt{VQ%IpI!Iyw5fg7!S63IatEcn2
z6m6r7CbkBDob_meLL#5$3seyJCDf_IoXdUsM<k02eOCM}h_{%Fn2Lb_x#l!rFwYmb
zq_|&10`#0^Z5bPz<yr7pc8~St#r2l&pP<_E*7Lmum2k;y6{bW%4=n;vXqOTciYh%8
zygj1^455kTnOVB8i|5BM-Fzb|HxG{x3eRJ8GNUZXbQab{#969^^o3{f_0-IiZi{wb
zA~&jZm9SDg_mqvD{m<@70=0;UVz#6+vm=U>qq>g;I{;~T-?OYH`&vm@_++OFX-$an
zYijCGtc)fUfwYEeu+V%jfHad55>}ay(V)cYBglCS<xY=}linDh-L()==X?r#A+WnT
z-Umd(!rDLqpd}h?U70VvUrL*_`uxCdzX>oz`epLvT9$3-93V3*8DP@lns%_y2)`gJ
zLmPfu=R-viFd!dqEni)Y^ULrN!0rY;`|9oiPqhf+0P>#5dwV&!xI#L!u+ltMs__N+
zD)<2EqlLr#QvWRYtz2y$zGt8H+q_&>?K&H8RTJWolh&I>N2a)OL;KUFfiXAW`@+bi
z>ez83Q1k)C-9h6~9kBn0N?QVu@}gZsH#ax$=HZTxF=!wnX9mK>_5K?Fnceni`);wi
zj&W7HNIMB<`NWR6;dgPGeN9ctZ2J{Ia1-*c_$!v_klMh&A1orn9ybO=JGP69%U|+b
ze=jTZaTC83ZUx81sj`&;KWtTbo=`;FiI<pIU_$=ZC;A9aw|c#LC*2iyRE_1?&V*^q
z)nuVE;NF=H7h<;Tgin|aySdc^u>=GHalS|P709`f_44wfkAY)T=RnpS+>h7r1eCHI
zeLZ(vb6Zm$Q@$8~%fZlQdzHQk|8ywE?*{TW@TY{`6>K-sfWQX#`SPcBZcQCZZcC#I
z>GAO2<GKAlch}Oi9|K#+T7A~d`OkmbkzyFkR%Cj3ivd^_kcX+?pP9t;JtgO=NXU0}
z8E|k_zdS{e^14-wnb&Br7*=Y~#q=4o3{(j)4*=P`AL%0202^#WM(ViHAD13MDde;r
z)oyOw_CefGt^3-|Gf4cAtNr)qVGq6<{M|~H_z$lmFl5uV$R2+cp{71;Zf!0r(=~s9
zt(&GR*6|aM{4xuWnI+L+17~L=mz>kIrd>ZrSp$$XWoKu2-UV=gP(~RV&#hKJlJ|fK
zWXlJtGfSu&e1&q6*4A%a4nvF~Wt2cPh$OUhE3d4K4gN<L|4~OT;CFm{a5`jBr@^Ae
z@RW^>O%js5pnrP$8ygSjZQ>9>5-q-_`I{}COBk%e1bkGxB!E?t`@Ssv@Y=!I{y8}z
z;r1bW+pukN7zHN+M%J!@yE|{o3CJ$zDzN$ecwwo@LCK;!co}L?s|LKIXP}W2$?Qxl
z=JWHb83<`G07pIm_bz=4sI&qYfkle@haW_-sas!!>Vp;R>Zy)?iT@F~C-0&7b6+p9
zog8F-9@lc+2goz2*CjjsI8Nv|ZLcqi9vcQ<rePhrJ0CGmsh4RGJzrpW6<arb#X<c!
z3L2jO^CaXvM4}=#l_~iNU-JgkP?CSNZoUq#OCKSa9?Grm?R^)yOzG^xicQ`5use)w
zIl0)MR_OM&dw`59VSiyRXD|PDt?0`WqadEfU{IIQztM$fA|C=O)2-}(;!^JP^=((o
z{}P@WVTf#dv;CExT6BzNU{)MfvlkVWIn{)fmygsGUIZMt(f}9B(pe9^-fZpkkZXSB
zNFJJ|<hFB31^SFy#zwJY9V{lB2wd!sw~Vwzg;5GEA*bkoHa>xygNbV^(W<KI=05L$
z@mIYFUljhmk`giecS2Emk;U33kktQt5&Z61W4~(nHGE_u?<SR86|k9mObhk=0s^Tz
zn4;JXW3~L8Hk8p8O-aCH8xH31mFuK4k1WTrfND6OqlRlKGi(C?b@e|NN(mI&5d`Ym
zP=7up94h}ia#;efj+K?@r~k%B(ORn1zX~O$V9))Z{Q!xfSK6yo-vUz>fnliE>87!c
z+^(B$@<$q%k&l5@h}sx>ztP=~#5I3sxPw<o81G;P3BUC)|2r*@Li|lf@06DOjr2g9
zR`1jLOwao}TQkUzrd!*Klum)6cC>HFf9AKGtHZx(N8VD{>TEFz*gORUza`{<s2qd1
zu?>CwFhP~A`$_gZ0sRKvL!#td9>4W{x!n|zrHqu7LMuzVsd=688wj3jn-fuj8&PtM
zN?YaBWI`AUu01`MqT54{Yxe$u!%uPfZ<Tf|`a3QU=;Dd!(B9w>c|sFiK0Y(_^cFZi
zB(ybrL3YPNmuF&Vl&xobyv`k|*9t6de2e@=x#`{7t5qpX&+Vb^>v7AA39QzZ!%D`t
z&(E!ALHgadSfD**g$TgS|5?%SO~hzB<uPJ49q54$JIChEM=^@51q3c~*$@t6!<*#K
z23#!<PJP;FNJ1%p{1FyQJqnFHd36x}qGWy0uvIy3Q~9Q<P1X6{#_?R_{-H9>?Ju^m
z_rjVEy4q=tl#lbf3{Pqj6(u8A?hZ{ee~C`~v=O-wILpX6SZEn^jJLrWC1Ejrf3RHW
zEBozCku0o=f*!5qaxHXxt~_ZOo(AFEA66)p2m$-Kl3g6<`~J`ravi*Dj1>6O`NI}k
zK7X9ku)$-JEIywOlUe^$16w1jKB&!`9cZ0EIQO?7Ssog!9oDmN&ff{?-fxgWR|jc1
zh2|>26*XnT^tF~(Ns-={_W_acT4(}rDBkM$eh!Wcq?CQ>oZl0NC~^G+TPAk)m|0){
ztneHyi4<FS!pb}D{3a}~5_QOVPVRZJ7IAzUj<_gfY=79@G1a)l>|v%pg>|@Sz<+yM
zqhNAL0b(JM1-+RSd+&a%ztKJz?drlPE0|756)aO<J>XjUuH~W<D<&vuv1RFgg0HbN
zz4b)Dz}}&s>suTN?y&dKl|r!lLUT;A5VEW8QyL)?NBYg`i7uv58|UVZ*z;FCr41(?
ze3bVGnKyr2?3Y4X-$fGqCPBGZBcEZn6h4#xwlVaGzSB;W%hnX+_IdH<SG7MSZ8P4=
zvTKR0?u<3zPj2e35Y7|=D>=^NO1J~8oQHba(4jI-x5M!5Ljy^JENSe(FX;NB>)Ee<
zhW!+;c2hvzQWQZcS6J&JDYLm-*iC;j{BC09!Cqla8QUIsF3^^2jhp;pF-+1|IXk&j
zE&MAOURzSmGi+w;dnlRR8k}EkEZRF%igM%k(2m7Yi2kEv6Swg+NI+<cnYp#D@ikT~
zB&fz=pmt`TR(w)+a7%FM&&0(U_t38!53gH^;79eYUY}vlA7<R$Z_iA{E0dr5y5hBM
zxBEmi@wuJCp1kDtW%;wF{5YT6OKUilFJ4F`qCL9@%uuw-6uBSzIG#CZ0W8e39<dG5
z+^F=HP}OE{JZ5Lld3oP6aDqR1Slq)$8g+U+hCjY!v1`)m>64J$d^a1~Ixs|nxo9T0
zaJ_cZ9@+Zc-f3skXh$USj;t*n-wf?X;vI`0ro<tX)aWb!`HUFyxm3afq0{nG`eZ`a
zH1}mSn+Yot+q+AjLB01jLgzG~$l&68kITEo9$jtcb+O3C88o+z=EOUJ%A47f$eakP
z#MVG(ltA#z3RObCKtn#3EEDbB*BY+@=iWumP5K4SKlW}B6?q!kf!(>oK9~5eVX~>P
z@Az=KJeEWYXxFvJ_@E*VDgS-Yyi_*^w-!ENXsMkAbOm1bVznJPCRodoyj1^0@gj6O
zI~I1l!#|JChd<zlOG0AEF8tuz2pOntBwN)xBE8x0PB|Nb_B*QWyK7IxqX!CZ$4#(b
zl%LY@UxpV@i|mSm+sxdz(jM~iTrDZ`m7CKq^Wh}LAcIEEe0+Yd&$b2WU5=fb2`DVz
zUVkdq3%Q|zP2_cq3^q<|#hH{3&*4+G6Xj*zRMAs>NLfig+WghmSmAR^WSda%hwuI&
z2!66WRetN!+v09(%iH82eXPTVuR&x4jh**$31dtn*jc(-8SVhVOH_2-u3B7unxgp`
zo#wmQDak9jP>BiY4DPqBYw6s}yjWPMX&$WZ;;S)^wNEbvN=OI0q*^H`9L?IdT4!7E
z<WCX52jJyWk;koO;{tkKmz;j}o(DKQcbWzUSKHfEb<(b0H)EP05mub47Ph->{q;jB
zVw>S2Eb|Zu^?Kg)*{vmI!y~`Evi5j~Uotun8FS9!0VTYQIU151`bRH?_%$q?VkV{a
z;hw=&X;!>laHp+B@XNQLxW|G7%%zNRj|oA7g2#EptlSlcD><6&k;8}ytm~0;3Tt7?
z-x%`hWP5l#{7D4ozj3AHXR?hazAyIt)P>3GRUfqNc#w13Wp-kM@Em9EtxnqN+itdA
z^5{h3{t>X7A<~&N7zzT~ptmL6ka%U|J~1Z3Hx_Gt0E$2kEF2-uq9xV^EekH->|NoK
zf0~F^%??flX^sg`<oL!fXt!#}nIhGPLr$*IKyR2PJ!kT8weY6CkiJaZx`SaM)wDoP
z?+L}QsUf&hhpwwyUhD7d7B6pQ@9$3IeN9XC@Y}q5QzPXm*dS?q7f3TpRx_@jXc&Xg
z*`UXscGKoi)-I5p?)2&+A*-Zbzz9ei@mYCJkZIgbGmG4EI==RUC4#tzh+D@NB%Y6Y
zoW{BY?;ak;>eoq{5l~aKI`nSYpv*5$e#;zu-;@4_$2%uT>nq!7o=pTUUaK5+p{&ON
zJWo=3H$W<aPtR-gIv?JS@okqU2IlGnu1R@FV8Ij9e2CtJZbArHqRz1`f9!zmx!{7?
zQl3iG(Jm;(HeGOISkYl+lwR*;qrSCAp!4C|PeIG?(4&8{da~}*nIos|D9KTr!V!p7
zFggu!pdsoL<$<?)JjERi+tnAbKb|Cp9B%$wv`t*%G#crlO3e0;-$K%2+%VB=7YApl
z>`&f7R1lB9Sts^GpM9TYv433IID8(4B#jTd`Q2z4=)Us#uoctx>jyMY({q}<v)G-b
z$<hwk7^3Ls<-;fLht19s^G}yQF(Z%g1w9Xf*d+`f_)#gfDPdLe>6;JtQwif`zKo6!
z1`18kaG-Z*n`8!bO_nJF`6@9x9)bx-4J<!r^*N<j!Nqz5r^8ku>#LC@ZectSJ^L(M
zMb@%kREuS_uJXf`ropWg%$fW4!<5`BHe>kmWGBaHv1_X<!F9EAegt^F{9>b}`o1=f
zJ;JfoHu-z1>E0i=m8KL-vh>=PT)|V3)7x-K7p;Zc@LjQp`}6pzjhG-Qf%C85Q{V4g
zjOfX}OF8ttKuNmHb&|%<=`d%k-_?xsXm$s^P$os+3csVo0<As480M^+&|*U-BY1jY
zZFaV0Srtjuun4266o~q-_xknD{{D(}WGn_gukwHdO?aO9@XL$FeUU)g!9Q@UcV>|g
z6XUWtz;IW5#_aCW8(8#OS|@>3eAbCfA`<N_&qKL+Z8W{``_yI!mDw(M7(qJ9#GuQk
zH-%nN0e^P*-tzWxbEa8ffJgoKm7kwMHjL56C!0=ykJGK+36-9G(BkX&C`j;T7cHo1
z1n*Il{^X+f@7sO+h$&x)?f5U!)|>V1Y#yXNWdzi5b0eYDw$$BS?mE^xo!t9$Xtu=n
z)<W*&g_Kr_cTP6x;jPh8ycxTXgPY~)SSvDq_^O8!X^Q|}?|SF{5njwZe}2D4Sx#|j
z*GrGIw_k2{F`p1}!21aPeG!y)wSKqq3GWlE!OnGeTC6Ve>}tbpp69BS{O10=QV^ss
zNT%lKbbctw?*=^^>yWFn+VYP3vofk&?Ms>XRLS8|xaFOq_hokeftlGK8;#4UjyGww
zbT8*BUC)jBk*#FYH>@9k#I?yYx3i;wSLmWapX#j!)0itJb&j9C;OXDuUkQwmj0{(&
zI<Y@%trl^_d`!Q;>Atc4B>mULqZX@c_MjI3k1svcoeC-mx_?Do)#JA`9yB3fY5TG}
zmx}?ElO0mT%fzJa_f?%5SJksdZHv-Iq9&$CSLMSv0Z_Yz#SVThA>XStcLBeElWWCY
zF<1P?;yq*Qj)o@P^UZX;8GQL$ThNW(E4%2%_pR4$nEbJq%b@dCOT3{^)a{&4W=zeH
zx^=!s=^Zvw^lZ_=oy(ztl(xEp`+*Zif+_eb3_*K)Jo}u3ylTD%w_dO8!o*rTu)db_
zfmTup54Lj>OiD>znru?Hz1VpZ9Sep7-pi6R3Le_8Hc{z+x?XZ5!AQC5#MZXB@6Ia=
zG_~>%su#BMhn=tFcO`-81;KVp0qMR=R;(vI%$p~NKD2pPQ$Ueb?U|DXd9@c}Lf#Ok
z)gSq$c%x*C>sz=EF6o|b_diHNYY?K^Db@6E?G5{#D7^!%dq{4MxVHw@@CSAe$auXz
zn&)&DJSo07xZjldSm1FfKx8U^R=|m88)Md}#OtYU)qZf%lJvsWL4MUP{IwEZw$x(6
zZn;mNA{jNwvTG!Mn2_)Jl>Pj1y3du7j9r`e#pRxldYG;t5eE0;ludFOTb?Q8IpQv~
z$2H#<o|$zWG(tprcXZsB2lmC|o;zYvgJTv!n^X;L4S?@fqquY4TCjNq$o$1So@JZo
ztQoLWbBjui(8_o##T3A)*8M0hF0MY%3xecopuie_%p}jcsw8}W;8))d`L<$GX*{aA
z_c|pKd+?0!k_v9J`|9g6a}Za2UZLSMF$`bAI?-%EX)a+_P~uTRryV+ru+9lj{4;EV
z`9cl9XND_Hxz$^8WZ{zB9ab^di&qylCspko<>dFR?zU#B2gQsd-qLg^hnEllo;mz2
z(pRAPD}qJSsi_9A^(!}&$45JV)(%+YbS63q;_jb-*wX(X5eJ%%^Qvr#W3=cBW2wZ@
z`0<v`b4JsZs^-q>^N<3&jGx2D`RG&G_|1FZlr6hCWZVw+-4YD|P?cuZri|Dra2_WA
za#%)R-upxHSgZ1_@#^}A6$g<62;Taq>$Xa=qu3t=q962jd0+Z!x!vC*!hXyLeaXXk
z_GHzdFh=L<5~XA2J2tM$2O!rRTPFcs7|7+W<l^!Q3;zh8unlC+YB!v#;*gznWGRZh
zLo1b@pouj(cJ&58eh%KFpX!N#cEelSC&dqUF!m(?I4JAn^EV%roAMu%(0K)*+*9ye
zDA0St_AM|KY<t0w9sm=6I~j9(w}W0o`b6{tJI^&g0S)1p1{whIQC|!n{e%8ox^n+I
zN~Qcah}719G?NChN~=-Ae{)`UUjqu_G1M6e?%fYyM+n9toraa#Y|GVVk!!^O^U|Qg
zl>3jsI3=#s7_73cQ~Tb#;Q;6g5g~u)cuM@$0C6*k6RZL7GhM@FJbxD@n|+fCT>D>)
zz<;iT;pKnKqV-T5xU9`C(IZQt9lZ*WFa!?GuNNVO-iBggV#%@P4k!PB{r_60BL6=I
zBl6#SSH1ob3IEsbkN&qU`hR=VXu-ZNbFP1N6IS;&|FR>^0IoLySUI|zxPg5b|0a<6
zIHC9&*r4NiASDf`ITR+DEt*LX?9;5cz7#Ls4s1uSZDg0>*p5@HX>fB$50@lxD%R_O
zx=PQ&yY))zm%7*VO0$3i)my%o7u@6I0NmMi$llB&N2gXI;O6}QYs3G)dANeBnSV2{
zwGqE-HWmY`qFkBVRk>QvG07&cbslp&pCA-LD7!?=A*(L##;aE6$*FzCbie_vuU)N_
z3{>Sz(9+9iOC|drHGaGpm|SOa*jw2m{~=6X>sV&MRTgj4MmN>QyV<%&Fs=x-TB4gW
zt+I;3!sBj4FQZ3owI~an^6l-CW!MZGqGHs~_l-1zTEz)PeVpsm_|*z$4NVwoEJ0W&
zp>v&UDL=DTH)pN`vT~+TFIia3J=C8UDLJn>md+kY*y<vVNzGWkRJS_L9`2H5|Lu+l
zr~C85icJHmXN+TPnzTzoqI7wTxUksTx1g48yC2%3qoguUhh?Z7o1p9^=5_MT`rZ|N
zI-Ee1*U>7K68&3fIP)OVKkpm#;g|Gx%~d&_lOBE1S*zdbH)VTM@@iyk2QtqBc<qS&
z@budsz#Hin8{$#dXg(C|nh(oxRzM^rgxFQpA12~NF=w$sEBzqW3=A?;C|b&k(OUVv
z92q>WAZAchOw2q2Zyzg&qQKWIiG9D?U#_{67_6Nfpmu2fZsnKV;$96-0Y*M1xA4RF
zy~9ra@0-0#zh=7dmO^n|8>p>ewyhKmgu-U9*Ru>DrNT+$xBdhU9gQ2S_D(9F_noDs
z6~#X)W3w<>URT6lOC}fLfS(dS74LlaSSukRc6Pvjt^Yl#vGG>I52iDP4^PNK>L<k|
zRFYm*H`gBzW`&hDNXVfiuc+ViOtRZs%)1*Svieh;uaLwNaifVDQ8c1oX5E%E)~^(F
zZcN+k7i1^m(SGBqvLS1l-`;c$mgW*`eP;UpR!A%EH%<oQe7)T#dDYyPnKC&!T}7*E
z@IpoWB%@}2&4uevHRR+jCHE8)7U%3ENJVWGFi6q=L(22Qq$Y={lmsqSx|$Z2BqTo%
z)n*$wXxFs0E$evj9Z!R*<zxMTa>5v+^(T%AP7CvV&X`sX<Bm8?AjZ{zsCqX#viP~`
zFBC`utLa#kO;Zr|<IVt9zOpZtWw%50q-y41sy7_4v1kSm%YYI;-FlwgK$npa=DPp)
z>kvbb1m>3~95JOkaI2nRM#h_IVzgdnwyIPZaRQfwmAigUdKP1)!=IuqtCM1o@WacW
zDsg&6LmDa7@8yVMPi3~IM%PO<n`rXUKsmw;ALnjEicXz(uWq*JT3a4lPt;+QdHq3j
zSvl5Bw|aqr(%rX3Az>7%m72`)O@iuA#<Zp4Yu{&NMKcfRLVR_I32+KRYkPHd>UH8u
zhv!?J@XcfgHNUrdd&6l~=Twi=-sRU@*wxpcrEk03@hQ~UAIW-74jsL&sX&9ykhCgQ
z^4IlGE*w}b6VE-8an*&~IMLb;Lz~KXeo8Qa%%^S~PAlD+)oe6zRaI`5rq^L9bu?0;
zcEY&Is+lj4C$1$U-}D1lJ*q0u$!Hi^O$>Bje$4G6{)TK~qC0a&h1|@P&YJC8nw;KV
zNyF~}e?h6R1_dV)P1%ia^m#-@huEnuFSwkeUC*LHHGdqB?aUil7{?LdmYZlCa%`|h
zImBV&mQp4i_gbLp%4e&o?eAQAU)8p)I)BkNQ8aru8q0-cv^-19mvDf512N(gH3NNM
zmspy1HfJ-Eb9@uiQ=XPs>D`s~*s%_#C=bP_TK>GjZZgZ}Fdq;tU#^#|DQI+eUPF<b
z^NSPo!!PVKyx8F*E74ioW+@W>;;f#h_@cSRV;Kdzx0czFzuO;=qtIS>8kU=R!bx&C
z8w)pzSspyy;3G$nFK90EMy0lly$Fjt3MD<9t#Rw2Gg&nRU3nOrSi@PTtLhTU2hMbw
zU^{7#ImhdSpW_NYwqA@!{yTwBa0a!JT<}UuDGqfX0>3={6D^b==GAT7z|W-CcUrCG
zqsDBaHePjx{1M?+Nl~gf(^~BC9VXctI?(UOk;g`vkF0sWGg+mbsH!N9nJ(_ZG^drn
zCt4JS(#&#W#*0^QPAGxR{ZmTz<e4gjm<N({_68f6*PcGa$-yw_8b=Cq<s3c#;y>Mm
zQ^o063(5#fYw*_mXi2d8^utj{yu=g#N=NWh)c1tuY`IN3DlQ%q5sc&<Q7y{}X{Cs{
zrw~t@<j$XjwXo8c5c;nYkLJ%mS;>s-E-P)O<vDZ^DMM(n<kYC8zsMCD6wNk7SZ~Yk
zP8$U8GW4$bZ%>^N(G|bZ{4(W8RAOtg5eL^>!l*cMgnT@gRnQlC#s`7LzZ0m-2*Ty7
zr&cmj$pmc3C_0&Xxqq4YR8d}9SW4qt9#MmVD8RjgghDx9N=aaVl|XbERXG^KijE86
zAtC4lQ(lDH+EI}tV=tn*#kq7Ah8WGYXc@Bzwf)cZl*A{lPTN<b<(Z;VmuqYsR%=6%
z_97uuH@cdQuE_B-+!97jo~von6J<hTRyB1{wUS|SRX?kF`k%1bJmuRT*sUbNPhf<}
z^aW>d9*Q0NI~Y##1J<bMr&hAY(2^y`Az0HnKB&Ubd-pnZK<!YIBu^ob*^iC=k^6pQ
zaV}DN#x$r)3iHgtpa;?!g8A@wI9A0cn1|!=s-XbrLx&lQY_O#!4d4XZkkl=l8G)Ec
zT7Ge;=3aq9LU3+r3~_Lh1tW~sXuzG_5?cpgzkt=~brM(JtFJu_NkY?;L)0EqB~$Q7
z-m<GNh^|uQ{X*s>wt}zMwMhz#o0Fv<7Hc$A%;()_6#ac*@fM5)SA=y%UHKJ@omQ&5
z5{|s%Yu9?ks*X7!=BZ*gj~WNw*9~;@_A!THs>2(oyn9}}V>+Ah$RK(mGGi)u!#JzU
zws-mUw^5~AS9I-3C<r!TVq~%1ABQ{laR#o-ljruaH~dg7tOt~}W_S^|iO#^nl$H`O
zp7)J8JOo>G;vp9(wxAePmhol;u69!*vp+<*yRugh41-&3r7yv|RQBVmb7xbz2Y6Fv
z>4$bsuIpwtub7K;r4k~_gitb7By0;~x1*E7!gv*_%gqa=McgeFugDA?o+VS1GO=1;
z%M+y+gju+rJT3l)rlIzHZs6ss&)T+i=KK+%5y%8Eh*rXKo2itZw&j=NwDJdHTodye
zHJt)1t_{oiz=qYV{e?P&;Ry4h&{foX2^x7Uc$Wg3I*0*eaUz%NfTDksKT#2)Mp=_0
zKXI$HR3|Wzz3G&5xVwzV=9XU@)k>`tn(<gfe6)I_*3B-Ln7mR9!nN56v+$mzUR>$@
zI{MUFjZ`-oL!qWTO19s$LrXx@=DuHrH3I~MqFqC~*9zVcXJFK*(mmZUc}FX$)427T
z?k$~^4t7S4ov*}%X7F34JuQXrH(yc3GGOtYNt{-z1pjtoumezRJ}rm(;&E*mR8x1A
zbo%KUkIvQcb6H{s2GxE{s0-Tf$KeG^q-X^yq!<!%Hi=@n2n)YO2tST@CS+*m!y$@Y
z{lRW6F^m^S*hD&iVuoULj0Lr@d2~{1VK0IM8dZ(wOR=Kd?*2MT%&OOtZQ)1l#5Va{
zOMhzInYk{g&g;X6XV&W5wp~50L=Hp^#9NMFegDzTn8iT~IY+fp(#X;**hxWkl8*rm
z7h-B-v0yt7q#WzHZ%V9#Y~Pq5we@nizuze4WfWk7yDz4&Kn<mJ)u^M2r7~?N3f!Cw
ztIj0kO(jpn5|aA+`UcI5PS)22ccPZK^5aO%%9_i4%~h1upPJgjG$nne;b~k|5{uT3
zrF=<F6rH<Cd^skX5!wm|#6ghHY>rpQN+>ySrNs_Pxx}&Y82B=+tuYbMOMy>bA9~CH
zMR8<-lOh=!+Wv)j+VN50eiet`k4>K0FGC}#=8i|)JhV>~&_0ax&a5|MEQ-XM+2}U&
zE`Ju#dfJoYqU7WtL$iWQW%Mc2S*Ofg?i%4eZTWh{MhimA_@Lhn#D`OhX|<WbPlVu)
zwPn*dTgOAuiY<4pced~d9mqL?X1}I}R>h0D5+v;j7Wx`GDAz32m)E?tddYQ@*~d1|
z&;Cj;$fiQMF5-iCM=85ZRf3qSg5&R8=jT^Z5O2kaIFmqTR1DtX##e?utvG{JMOJ)0
z_-n?nuGJ~o66UgjnRpYun|qao+eiY3z($FlVsNK~RBhAQl*`eqOuOjw7rCmWaP5|j
zT}2=3z16cTD^m5$-9F+knGBO?(|zT~v$-cRG`x(wGF{#5I?0V5mB5{1YV*jqS-+i<
z9)d((S86o*^v!*7Fu!0O8hfy5+zW;>{!WEE?bEahA|~gPH$m9psini8uqwF4DAFqD
zFsyl_CU34kMJT{zwH4#4e_{;Es0ZbhV`hBi@;E?!d5%kAowSH>uCWvC4@hyw1vmZB
zeUa3n^|)fpf^${uqC^LKCHHFQi44oEJB2TO|M$n4fSZ)IRAV-*4If9ee#A38nNZs*
zPsZ2ZLEP^Dg0a6Q61B0bv*C~Utt^~~4a+?nDX522>T(=O^XzWg3+c6Dx56C_<K@oh
z$q}@C*=;J(dPU`*RluzUy_!b@ges+^wVcl8(gEpjE6xy^mBED%Efh=9CXI!rZ3nWP
zc^HY2SHy7=Z+56usTk<E7<pO8*t1}7s`;e)#>9h?jilzH*GXqClW-jL$KzyF&0BsW
zhpy)<eWVx0M`61qEGmUlN|?7<S!P}Ap~{236^-?&F3u{D#!Y&Of(F>`;Kvwvmde3a
zGPjYl<&OXfn<Fh)d%F@|Zcznhs<U++Tr~1MMo+0`YQDs4zqZbtNfOSYgx6mL5)<;+
z`3o?oONO9u!6z)ZQfY)T*bU$}0aT}MCZ%fgYtFV9v<tPxN&eRJl<GwoOi3M;Xxj{K
z+kQC1*UbFCP4;g^l|>xs_Su!-+K{My>uwcVg)U8BiasAk3gUIQtiYk2Z+Hr>+G0|>
z%l6$#Z&TF<B$3k_PH_{a8k9D)LU#JL3H!TEHv4h*6~oeaCdmg1t9}l6bZvF+oX#q0
zb-YbjWC7?QNi(}%`Qe7`E?OAWolj(Pt9np23-ug3Ez<iFWG`OK<#@#<yQ0!4v)2f$
zHn6zgz9`vdN|zVJYSgZS##KV2)`AyHm2QZ$d3DFyhpo%?ulQ>bMdE?9$!ZKqzD^=K
zqg?pIkfy1WUlDUt?u&D{R&{UY*($TE5L3SdW(lnGt!fX=a5_FOu-GhKX|Lx+MdXAr
zttVGFpW&dw-jtaSZ903F9Cp)>IJjUw1W3Gv@vWZq?u7XGs`?zXxfB7*^^qY3G-A2P
z!e}O<gdutCT^JZ3t&B3<KH8WoGL<Y<8S88g7A@Q|$tlJK2Wo!-%5TK}sHrbYBLS!u
z2!2S<x+H0K+xcY1@gx;%!cTArNlejSk|l7Jqk#tlEaJrb5&LRC>q`3{t@r<gv+{WP
z0jnMjq;KSrJW{IJjGC!Q&iW-#W^4;p$15vx<%uF&DtE+Qc#1V=JIwk#vb0f4YW5k3
zT^@?Fa)yrO(|qk@HglN0s~S*T55{Xyo7!%&n1MB(ny8=FM>kufmN9TT%1H)G_Eoi%
z?>S$;zk_XW=-TT<l<RE~T&fCzq^kkHt@YA;vsUP|3q%!JL)+8>c_4gLu9?0g3vRl%
zfVkWliu1PENgcm8Gv4oYzNVhZdy#tKmCkkR;VKd7nzpp(Y&BkeQv3$CAOAx^LeF)C
zwJ5=}%bB;uCsk}^<`(q&J>WUZBd-wqXX6$zpc0$!<MOoiIDVL9-{7r=8DMp=ojy9a
z)v8Y$+!hdyrvAVj>Lmhi_2S53J)ZP0208hmSu^PW`94(anp4A8cDCa@AA9cZuo6;r
zd=ipOqUIOAU4NyTT3d;AH$jsiUu;0X<?{Hj36GrnU4~T=NFBp&e^{NjPz(!Jw@hFq
z(&D$6?&rkM%#7--Ui8lJF1Ktel;wH>3Kf-YL;JRqwP16Q1w-Ke#+=Vf+*m1UlYBP=
zk8$8zR&Sgl9$Gt52zZPdju?}y!;31z+35Eh@T&=3E2a-({cS~ww!H|JM{EIp7Kil=
zqnfs++Aw0T35TbCyc7F13-qz-#}jBWe%btYy(hh3j-rsx8gYq9LJ)aRGZ(C|Up)zK
z-M*=+NzB`D_PH^81KdkIM9-BJ5a2xE7^3kQ?M@--X?d7N#mkaZ3IWGWB@hP|UfWWy
zQt?wy_g$xu4ac{kXLKNT!KCNUp44v>^BrlZADbQ^yxrscL1fuV^uwQ2I$6LVJmBmU
zDaj<1$PZ~I#Hdqas=uHN>0@p@NLRbEs*fldQykH=a+`5p>8~a^m@O(3H&3BVsNuGl
zT6Ico*(cDJa^9}kKX)O5ig5URkO_6EA>+$np8L^URxgY$RA83#`D<=Toj1w+{!~^|
zNU7D^+G#re#NbViw21!wb~cYv8(x>I>;a<HfarLbWnx;h=}>#%ZXBPGDg&>TE$NNr
zO&NnmOlq2P#>0z156LVh>-Ou-sEoovt)%2!w(&1$*v3=Ref}bhR^Yf-d}hpx+`_yp
zHF61QrH)TRwfTfvJnUw*gm8Rn#XthrKxIgglVZMVFCA%<xxCJOvZ83U61Hxj_Q|wU
z8Ncn)Err$Dkzz8u(|Rs?m~L1zC7T(E?`MKEq$=-^O;g>h^N<}sf1JvWFPs^oT3`sa
z)^0JiXbDbk6|}hdnpK~RdtrfZqis@W*v0xFHe~)WTkXfnWcp&I*#{4mTv`O(H?qzp
zw)^phq4l;Dq?FYbvI}`~JJzcyxkJvTijUSU<%*}{RPstcEwqRv*BHVI#qK7Q=%=;|
zw#wg?7W2k#0V2z?;iKgE3Jc|pRk;Cm%E6iW=U=L!LBn%P@+P{|3r=SutricV?+teH
zHpq&}_q!v`5l*aX)-tnIJNhd%SI>8k1EG9}Q*HGH@p2U{2RREb_p;vOVAd!~Cp%89
zFqP*zB$e{y&i#1(B`fsYrKKD`kA5+tnG{3J4Y3$_;JjLO<ynODzPz$UwZeU<#L3xZ
za{Q7td9}{EKU|X^l1($>QQ=f;RP*Z+JT9FHLpaUdkTvrEy$AP6LBbPdvv>Hy<77`G
z`G`0@)hwSSXS9VNIY3po%q2Te&bQ2dK%MC5yQsaOng-5V0QGxXGbj0tUgpG7y=Fk@
z`XH|*2Bz83D)Lou^)&;SMEr>z*QmmW7{Yf=i1s%7;LixZ89Xttb<;<|OPKWU7uJo1
zUSCne4j!>q)Jl+n#ot|wjN6<?s{Y&3c~k-3{M!?7&XAnUaYw)#wYXSASLa4&yPW;^
z^HmNYmLJKnIifNIhDy<m^Wm@yL}DMK$Ok2A)^`uv;3c=io~l!bha3^_GNFy;vVDww
z9vKYu1My1H3E7yYbo3V`%@jxkERy7dZ15)q0}Gi)1gU9<R^H6bZwSV>iBH!43uuFK
z%<4kkQS3j1ar^i=X%>{q(la6iTX<(mBLh(O*j#tW31G`O|85!Ol+$;X5AA59ko+x@
zIJ9q%OF-(NGOG6#Xu>|<5gUj~#Tm8==N7Ne`_H0+&=qWTuyu5Q$ke$U_7kI&J?Fos
zZ6?~5I;s?$jck9T0$tIT&dny@?`V$jwHSX#{8WR1q${7;{dfhdV`Q*URqzrwkF2h$
zVkIYjVQlrm)pP2*1I4lgR3_{=@GW31=i{SO<1kH(MPv0w=H`E?F(?2}-B1BzD^&s{
zO_lKk4GJnd!>-YI5%)%dww}fg)4=+PACq$N6vg5fazSBo#u}4^a~W5>d0>%FX^w~Z
zc7`*hZg;cxMR+Z<YCB;4t0orI4LL~M5=xoqg9C>Sp#P|}-bmZ9A~|3PTd1UAB;;VM
z4EaGTT%I>@&i%<M6;@i&Qeb&kIQ^fC%Bkgs-ih6*L~L$r%=0mQm_mpy_V)vSEe)Wp
z&c*5!jCELz3?PzkpX7&!G)kG-6)?K&lB!aaV5_%W@cjLKJLVrC;i(kW0qK_p)+X+o
z<AZx4gsJRUv}U%>SgzDP_ykfoFl27?SZT+(2RT~m*1`>X%B;ju{gx8E^=H*0_bo!(
zM<k5N@P=6vGig=es;djS(RIbVRTd)So(qX<dI^Ml?i<Q9?3zc`)!BRH)n;ndDF(ev
z4MlCblNL%!awIq~c|1W^gPrv#71~C;mIlkS795N9+x4lwOr{FqqcCZKf&L@(9DLmU
z4lSOt5qy8LUC<v`#?fwCR6jac+&*r4z?p-^P=T;x*Q43XBp}PY!+0t}PCA%*8s+~E
zirc8eBR>Ig@An4VA@VHv<k;6+X0m<D@OeP;Gm~V9{^Ns^xm36;lr*Ps&s~i*0n8o#
z0F=|8c4`S3*jL*$V8W23H`yRTLzL{LjLzmzNksO;8p~a#G3+o`WJ=g4F5=MKyfu|9
z2?(El`-P~spLaL~?M#R^?uE2mGHee~j~0@xf&M(sa$6vJVjm2e#N?S4a^7&ada0vP
zv74*QmVOu1Rh-AZ$z{Ss#VQHT=zlFSQzE4Uqz>xF&Xc;+@YB8YLljuNRdknbVXYjw
z+42BDG)SS)#)AYZZ2(_GxfJiWWGb@a7Mbf7_bj@>44kR`+P?jGd1~o8uzx@&D=%F(
zn$6(oZcl7l^W*2VYD4ONG3>Ks*IyJ4Ug6qcmxEq!{shzmT2`sVa`avj4Sb`@5tLNk
z8s-T)V{0Ao+$G@7H$K7pz5F_)N8tNg=I7WWgR}m}AI+=k$~5D$rCiJ{*%Ov2c_A~O
zn@Wo_`80g&h(XKSNF6o0H@pvp$EK%7Dc1Yn+s<pPo2QKngAmc-qvSQ}TS#GjHA!Bk
zYK6pFdI1XTk7-lR-iSq^RJH7$tQb@D-lZnIq&scoX31Tu?xLkmkWH<CpnH5NRjirm
zf%zHN^h+lrHPe?&oSA*Y!?V~_9PVoP9<_}dF0Kji;a#mX#YfA%pRwZtH~t!V4x?#n
z;l$>56iIiOiN(17McY@?b+NyKLH!Q#0D_IF^Rh}?;0<YuGs{dS7ZOJ3nCJ7kjNn6q
z&Nd0QwOubrR;ds^<U4lPwXx5HTx_~g&r!#lEQ2QPg~WZoETm<lZ+W%qiZ_y3G@~kJ
z*Xwv8e9VwWG$!}kITH(=<wGuC>D}=Sf7xos4o8QN{`SGLrdw>fn5AU{{A&O@%rhJG
zR4i55fmnYskAZ0u@EP6Z37{O9HaF~rzv#_{odrJ>fe%PD@1(2Esb*KF@cAshr+vqm
zRpE7)mQu3H(|{eG-eB$Wt0X1jx<ZZuVd=@t_|V{L_f!Ds8M3u5OiYvrCmfg&E_W;;
zgRXE>5juRa-Hmo<u2OVY2>(2K#Tm19>rpY|?0VvC71PdJ%xv#)5HW7i$5_(wAG^o%
zQL)KmAk8_E*3n@S`z*E6P1<teq+*j@7TQeX^s75yw6x*+TW3w2J(QCu#ML^ruEKm^
zX}!!PQ|<3=Ld~~&)Fbid0T+C`13iU1;t57(53^ORmf1{e9S(Qf(g{#gz3$T(h?tza
zEdh2G)){fUXMPpWEj*-2`8`M&-eEBsLnnu3mvP0z2TwuQyaY>-*OL%$zaEL+JdLpV
zUV>4?4Z=2t3NV*L?k02xECGWnRlYy%kFNf+lANGlv}=b>E*bm*pZv0BfY)j1TppfO
zn+v;MJ}SZCt`L42>W~o<h=y%4FT`3+=9#*dT;7=cNcg;a19cv2yf=@$pO>KD-}lmk
zm1ma~U@!qq7;rH&&}EW5N4}>{9BiVFK|5-h+q;*$NP`;`Ihwbp-|}9pj7j9oV!gf5
zxVOvZ9q^cj8tE%0$e~(f4}{)kJjcTPNu;!AQXsp9%%nk~Rp}?KG8P_gt6!ET=6l0(
z%&9uH%NRO+DN>|NG4U-eRGAlv-%<W}{w>GFT}Cg;TaeqwOrgi%58m0HsWZ07<J-&e
zg`dRNx%Q4`{u5@U^N)IowuW6@nr(a#{N_yW%a^n=zv=KM2ONcm;`t}zb*&{2Ql<@-
zt#V%ur!=$VUNqc&Wz~G^Uij8Y!p6m17Y|F~3)4FviPgPl*Q`I6t~+9oTEav>;7)hz
zZ+3^to>8DdD1ce?X_T+tZnDpwKEz|#%D~iUOUR}Cj3S#BcvDkswYx4U93-5cab#(z
zN6)GEfsBPfa&c<L9KR`el-kZQ^X7lcJNYjW$$yD2{(E)Aflv#k9VV!)o4fI4oxWIq
zyXslaFho!GA$7CF(PiCXmjwXgd`|vcb`DJu=qQ?QCWR4(N1J%-A?KTW=McGZD@+XU
ziH?({fH#-VB8j&fzlxs=#^?<to$lQ-eS|jB($&m=dSrtfZyI{8$>(4jZwu&DUN+LM
z9o4oAqwKN(Xf}60Y)xCw<cCi7Ew85qz-4V;SLXsfOX=C*m>~1E!gk4bTX|shF<v4l
zrbdM#5N(C^<O>dErvgx_x*Ac7283v{rq(|5*jWl=O_SmYY$Kp|qwW+X&66z)4tA=G
z+s{4apv~ELpUh8RQ(|c?ionln4{3n#cd#V7zM}a<4Uh|@62^&%=Ccw48b)w()y1N#
z19f867ba;iXTO!bH-ub}1o0Mm+uE&!%n=(eCT7n$(@}R)*J<-_ayJ3kOEiL(+03+z
zS;Z>D&%;znUt^bUe(PJ=`p|;&%`p=?_`PJVd`f!3H_fau{i(rR#uKy7*X$K+@d=5E
zah2@uHip{$gjO;lYNn>wX(oK<g(@rk?<uwGUbWIhp&P0Y2U`S(6wrdWBRnnUl;X;{
zV90=>V&GXp$20qnOf8wJ<2OwUL!B}~XqwJS4*ClHTEdwB7nG(hW-=7SJfc-^RE!|Z
z{0qQPt7gxE&}!9$BM#RuABB+*DqmPNY;U;X^Y|d%!oaWLnrGX`pX*0+Ovtq2t9*x&
zQUZ5P0JO!(yO+q89M9v(2#~3qT`#vL+>7}Jr)>_AsI314ZXQH_r0Ihg`nE)R^B?Vf
zw8vL-R6{46uk$!8tz=)h>}d+pSI;JmWGDJR@ekFlB#ZP!)Nzk0x_Abz&2BhWi6Vba
zvhpR}$W_}f-QtLsFFfr~;-<@yvT3-QVhJ^*(u>?kE`G}Vz6*woCFO?QM}z=ar4;wS
z#Y;Sh=sPB2=qg!SjJo*%6McDw#)}^@>XUDCJ0aS+h7HF}?m#Sbsz(YoM+m?y-ehhw
z`-n1QAyB+YsDBfavWHsY@-D0NJfx=FxP9|o_4pK0QFg7)I%K(u5n_6@5EjxDUJUY+
z;D{=ISE{A1ln58Jzj*)~52?+aZK7L5*!-Vhi+AU-4)UHy*0Bn0iw=g&kk@|i`$-k(
zJoQ3s%UOX@f%tp<ySk?-n_3(xbg%Mjn3xoEh3N$*OeR90Va*qG>GE2Ons6775g$^_
zZi(DIFCawGKRg2~hcb=K^Fnk|*C4D06M6kz$?@faKgwIDd97qM<FZTyW7OHIpy6qU
ztUAsrQqApE-+)@hQeSEq9OWD-)b<ObBy(A_^*?@yTy!{^rK6+ep~aSF%E_ez_xASJ
z=GiU+&mtR4PfpnjdM%VQl$wbNw^>A|qT|iXs7D(GgPbsPRV$@Aab=2=l<NalLw;;y
zfc|@=mYe*aNNu(e{zLZ}w#8}4m3@rrkCLCe4G%%%)lePmh$I2#cVR&N_?^9HASA%v
zpTabGKqP~5GD_66*c^;~sZKwqVV*U@S~6Y%II_xye%q&B%WOB9C%mue>8<>uo5<%4
zO)wj@sCXEW-_v$-EJ`hxLcMscYSEGKZGjt|9Lu9uA2>?xD8=XE6Y;5FHcHWyB%dpb
zUh}n@4#9`%vjP=nlACiwBX;W{N?Cscn5F#;>-{J7$AMNZPaWF>+d&}Z2h!pqDnY{<
z@q`ksrLrGJ77<6>?`bBlX_&aMg})<q_}{h`JQcQ9nP?n)A_6*=odm5CWt{;rnJ0ez
z(KJL+(QlDXthvJYo%G`9y|t!<8sIXJwurSprr#}%b1{y%vzv+Q&NZghMGIkG0fst8
z8C4i7nu3XC?MJVZT@f4-zZRb6jGVuC>}Y7HhPhSvF%^vhCe??ovZaguXt_|tUeGWq
z>KQ49g}#dm99Fqk!tw!~Xf1$zFEJu%TFLf!Cub_c*t7J4d^;=RX(1GrmotkkHC<H<
z@s!;<bXg)}Ch4^BHiDFC*4m%FD7C!}nXG>a@h1p?{=Tl1iz?c2>KM6xK6!hkn%f$0
z?r9(w7L0?o{>2?r`iVX8`?#$an;6ht$T3P_`tj2-^}=tD-8HARxk2A1;rHKah{trF
zK{eAFxHucL#J2`S`jAk`srI>PCF{gumDI;nT0*s|L%4PPF{m6$-ts`SZ}K09k##n~
zWsgGMZ1+2c6ldk<GHMymyN?u*KRelz6V!ntPOKZJBq%JZ6GiV-@JhdKBEP9wKk}%n
za~e}jJ^xA>T4Q2?A{oYriWgjtlq`C<lM02rtZU<`PeH>D3u9(r`iO=Tf@4Gz1L_p-
ze)`me9*pV!#edA66>IM=Qaj)Fm}`fqmoBMOho_`B@$#r(k}#xk6q><|C~R~nW#l8+
z7wXv9>G{~)6-8{|4?oC9*ft19dgg_<^l#1d!HFVl^GGR&YMSBlM5vDD+{Wf7nn*4b
zO_d?@Pm;SN0m)w5ky5fq9v#}^-{@^STp%jd_s!H7Us{T~8sp@GL4LEJXG@%UR{DWY
z*|@0`_*+D%RvmjsQgjN5t<Fa#e6Ahlta_O*S?&r+%wRHXZYO_MZ#_o8nFLyi0+8QC
ztZTM`63<5u`FsOnCJ?Wji5YI4jdgLdCGURFa2E#Sx_>1S$z$IaT2<``{Ldj0BDj-C
zQo1K0NKuFIM4o4bf_O#^IaPTP!Sf?{sHvs#Wclg165Z+%h>sw5iEc~_qv_kH0+i15
zpBE4_ky8>t1b%~70)+M|tHk$fPiLJEWH}z2O7ML*#yV{14OsEX6Hpcn%|~I~>Gwng
zl=HFD;@UJIXOW2%Ivw|=Bq>so5|6%ighgp0L(*_!h=VKl65H}911N4cPjM(@^Xn|}
z3u4?1B^?Z4X{}taon+h@?s0q_nUC^JC2uSMmUrs9bKT0Z-vi0%9sP;E^gs>XyhF1*
z`Yk@WFz3zu_u5f@k&+Fr%B4Nl=51p(t0AUZMmtTd<LDaW+CGTYP*GkcU0KFd1}}9d
z2M}l)?jIC0q2od#pQAvp=|*bv@&}V1W0;!cWWU9Y)ASsl@NZk!tS&wLTBuQI>n5qz
zvH)551P1xw^m=#H!G_|lzXrY2`zD(h_vo{k>7KAV&=qv1q<`!cAJ<eng0X`L9J|31
zbdW)3do|79aCVx?JhJPsc)6|#s)CdUnhN!Ea=JR5_i_K95G>+UEFqf62y}&bx8ujp
z!_gnVG?2Cv<HZYehE(m#kxI}H!C`b|){fIY%0Zzr=-_Rc_o9xY2RF?~sK-KI942()
zq?nMDJzRlG=F9Ar?D$DB6D}Oh&3;Y^bt3qXdeH$Dq0X$VJ`DXH-XCb$`DHjYj(q0y
zSzbMrOZT;$=k$ik;J}(6PHW9`6cJHCnT}9su-x!+3<X)LxomKVeE)J!cQ>65v^z32
z`N*Ri(Zqx6sA*>@;ozn<9{qYgCJo_suy$)=QLO%%Z9#(o@lKuc`w#eA8!J=MqlnTI
z5)v3P+1mEZit)ckW7W{n^*0hnyR4qmCh>!PimxVJyH{xo4I<9O%$z|hJv3Z`?}RS&
z&Amhi5(O6z6F)STd&c}d4@~oFh-HbH96E`o@#V`gF{=FZq?t#Y2}5itaTBX|R;cd$
z(qXxg9~W6#h2yrfX`^-j4C5>rd7Wvh)(b(``}I5@S=osGk+e$F)ax_Wg`qPIWl<aQ
zFe+>TUCrVt-o|?Y4vX>EAS^s`2CO1(20sP(oidGL7g(5T{`{AJoG@mP@cEqM)A@W2
z3qKq@@|6L&hlep3tL+|E2$M1JS0KR=#)`Gm_h*<M-i0XvKu%;v+vW*Y*~F^HD89}#
zkSiI))JBSJsa~@tF!46`u2Enhe?ZMO7A6JlZ)dX%{BMBU9fFn|2#o+w%3D}#?)n~K
zxlHyyh<nSRxVmm#w1F20o}j@A?t}#QAi>>fECGVMI|L6F+}+(9_u%f(jccHBXk1Re
z-@bKk)!F-=zo)AE&+6(`bB#6TnDcqYGshrP`O~ykZ${P#hj7%WZua7K)c;?~PDJpE
z<^N6D$q$*BYs05E7pl>0VrjqH(oZZz6<sHX#lD5n>E)~pErE8c;NMz)O&&gQpTXOf
z9J|_)cgE2En=&|&g{+j*WcQg$Ia6?B1x6jrH&I0#d-y=;SWhQU&!HJwJv@OuF}9Uk
zs!}vqBa=xkF_l5PyXeX?xC0mVocYoRUw?fY$%fH4s!n8yKzMG}{-P@lS2{zg-p5)N
zqqV-P6?=d3EBN=1=F{hYW$(k$@MPQneKm6eUppc%B328t7%D&|0EVnFSv{*5$ztKv
z3&&o}y8;EaiZVHEO*?hfxt|yc7^Mw#(4r|=bK_|Q-m1#xl?UG&7i4O2LK)T+?>KL_
z8;cf+YT&igAQtZq-`HA<KP<u*4EQ#Fv2t`|3HW-6oEU)iaG9xwC$|tm966^oW!kTn
zrP}bXj#lb1wl(9+g?+VDAx&cy+941wj#$LE&2HwB#sJ9eH6}%jynDy|mv1-uFZx__
zzLjze;nBU|qJ5<C^S0k!8^PWl{;dd6NyO7cQ@Beoi2H-@VRF<^=8uI-ay@_;TxBpu
z|5!J1rVyi^_=i=8PdWA%8F#Jc8VI?DYiOsq!VJCkT>y3_i5QgAmb?Y-*0sh+f-P?*
z5Rx_<0jP|<C<r!@ycmGp-CYoS-NbYbP0_Nwo4J&G6|O!qpf)go65t>OSSt4VPcm;V
zju6%esshQ3k%WQ|lkM16&9ot4Y`W#zMdT!|DJf&Y_T8DswK67DAXCz2IRLwo<L&&R
zTO}f20CL5#$4K(?)K8c#_%GYF3s6u6p*;%;G(a00?glI`Y;7sEJ6#T5Wwaac(2q}1
zuS5lyd3+x;wjt=HX0ttQ(^RvR6xaM-${n}Ul2Xiuyh(J_ZaVjn&wW*oZG}+zbS*ab
zXqJKTss2h{A<2ueFdR!t-zuM)xoSZ=sJc|hSy9O@Ne?M?v*OS0d(S_sbSm5-K2T(S
z$e~m_)Hx>UySBEJdsqFB*UL=u0Vx8&TY~UEX>sKvEZP&Evg&4t=c8S|tPqXB@iax(
z7=DMIKtfmthz%6(G*X<^_LH0ckRO>K0N?S8jQ;A8o<uXDTVcggB~#h>1mG=6I9xoW
zkCCi@pP|fNIgKc0{2iQ6ceCSo=FR}bW-fABnaoP>(7cDBV~pl~{?JDx%e3Vu%K`~?
zFi<s{Y<oKXl`r>K0WK-d6SwKGSGjxwwFmz2*ZuMJTNg-juF*7#GCx85Ii9fj>2l`8
z_CyC+;3%^vIE{{95bzI*9FgsPqnWQf_78i*EChhs;b><LGb337spd^dmB_<sjJ@mM
zwO<!-H9CurlT*hU4KJr0L6@)UTL|@NT_r52SiFE`RL&@~0I4sqIC3iKQJc*$!w4B5
z*F#iX{-kC*xSiQ#nVwsyo$fT9)WL6m(Zvj<%md_Vo{h~6?N{lvnz3o90)Azn05U}2
zKq?khK;xGIHvU>fesrV}xPXWInLtk`u*y2ps7xmtXl8YqVf{S+qq6>r5LONXv8jz%
zUh=@#zXB<~+>o+zmFQ#m)G(K<{o*LByBt`pBqy(%nu4ls>4^NDr{<Te?^@gTiz~~G
zE~;VT%+&#d>+<0GnbHKmn6=!b{>%5Tbt7PH6(a3#Lv6DJW|2FDwsi!<NoPjQ9#t@O
z#W@?a1d;A?Y7=Qqo5f#rHB*|BTv^9XW{)Wx`ap|%ST{bst)CRZ?84`UgOY0HFzQNF
z2>1fsWu8A0FTrj17@(s6O;1I)@4-M&YCR{x+JNpObKFnP);PK~-jRp=yu7^Uc6er;
zotde*D;yiEsU3h3TxY9Z=_2sF&+2;p>m)*zxf2`EGWs*b`l<=A8#ia@Nk{*CqGr>{
z&`Y+0!?2^;!Q15>ln9wh(6@klka34-Dod1D?CYSP?IhSoxc(Cl1IG%$7}m9fz?!w#
z*jwqZ$FK9tAO?T!9b6(d;9Xe|GCO^r@#7C_T0muG{hr{y;Os(HV`)lLCrIl0VGru$
zOJtuxd7!N}a-!RY4))=$bp`%7s&AoSJ(kgyX8Z`RpF=Khj;PaA;9<V~g@^Hrdab9e
z5;8zc#DA~;qg0sf@$>1t)2$Cv!5@3Ohw(oj0W0@OMbLdfF~KAAjlz0Oc&g2W%fxn5
zs~+I@P>oVL0bZVX2)1q-9oQG+N>S%UZ4e4E$$NuXYiAJ3{T_8vKPQtc&r~(9cab|o
zu}IKOqld%SKn+z;!5q>iNbtAR8TYAHix}IMDWK!&8EpjQF}_En=dMai#~@e_#C0-h
zBgjEjE3$vMJUduAd5lt|XWTaL!Yz?gp&G#f)Hj>yc3)2^$Q$7I4l>o!{>(~CMi;}_
zH8lfjk84POp}>)>$<BexZAX|Zvonl+;SEvYATv}-AreOqnzM+HDqlAimoKRAuB<+}
z6;YNEA4FgAyRff#{-frxzI0nf0wGM(RuMod>fUeK{SPu6=Q_{*(4BL}@M@_IGRPt+
zK+gi<2T&}xcwxCnRcM{mb`kKqn>k4i&9s>LdbJ5Q?WUx*G0}~KwMpZj`byX=jz%iU
zppie16|7k`zD})nvC?zDaYQe?`!<#z-m}~a_yrptvn%&evYg{TeptDrC4eiE(fUTs
z8a_lnzuugRR#rWB5#2q$abA^_vz}imb(CuOA`s5I>%w?q3>?rJldt3kxsf-}x~Z9z
z4BAEuW?Z9P6Hg1C+tmS0c*XE`z<1KUrvyq2t9mwHnk$w`E>`u9Wj8HVD2b{KnCzs|
z<&^k73EalgjEIZI#L(7$^f8RhktEAHyY=Z3EsUMSA^+eXIg;>kD<aBO4uSTFjBxre
z2-vI_+F#K+c-$NAd<D~s!#fBz&AGqKJwJ1;IB~6DJ6hRm@h3}O&#Pj7&V;J7x`mzh
zsB9x1U<vOByQk#MaBh{F&D9zB^^AE&>M-ze@KrN<e0jUtwM&}RlGO5P<vN_E<v`Vp
z5r@Mx@I-U3s(+0b=6C0nBM7sai*yUynhgKTg}jzl#oAesaie8NNgN6h*t|A5__CEB
zyt>VXrOD*uEZljBU*<KIIma%DX$C_AeEhVJKlv*|e5ImTj`E)K%RA1P9~GU{9zA?G
zsVK(YmdbnBY!!=NbW1hMu#K#ekwzO0KQW>Fu62$YM7O2{U<#IOW#QkHNQYMTH57Rj
z6ykgdHpL;YiAln^LvYAUF;n+LBbr>Ra8p9P1pz_Lp&OMg=M9sa5!2L!tAEhE&5bhf
z*f+8WXygC$gpHpQ%jD1x^bISRG>X&|$+n=reZd(1v*Dn^&B^f6c;8{Uw)*R8tvbGC
z4fmEo1O-%O(gQ*s-ZRC+QhBdArubqDB`iAR-aNF}tbXFvz$kL=Xgz`^rHf+lMIb#O
zO!^sqqy~diKMp7QtKs)jV|mb!p&6T$974E@Qbha&%c5c|5P{F8KRp^55c>5e<#7~>
z0ZHAvdJoniAJ!?3^VTeYP&Je07uoUwyw0uIp>`dnj*UI?&nJ*2UV<litYHM68DRp+
zaC^FH&lQ*Xn7H_f>-sdw3}qT{qIg_aePZ>x&Y$$L#2uPm{rtHDOLZaC_;nXtOI4eY
zJnM_xC{Okd+76}u^<TbxJi^lmQICO+#;aI5K2DKl+GPXNKA67}jXp6UQ?0|>nlG<e
zAsg4}agkPRW|3uGB8d4}O1)d#PiA#<@pWzNi=S0(#tU$EVf-Sp-=kRkfVEcqB4M-5
zy0E^^vYRSo;H&9s)`iI0^1zm%hGpo(g3)3*85wSZMs^^}efj>PrYXB7W;8Rg`es>~
zPl5;!!2vVM0p&B$RBTX<*uw6#dAVOAfz*qNNR9shR{M)zHuB1gdJzFY5ZUl3AL>Td
z9OXI0s?<G)efwtf8sVg16AX@;V2G>7M|@jS!+7{rWD^vvu+Y0xiy9jY#k!h42xjFH
zFeI-MH-F!BgH)S3K@e(CC%a_En+9%!wRIqNiX5_i-n$<Vx#a^yFO`MgVWaS&QlVDh
zccEBek;e$?166YYfEsHxuW{UFTy6S{<byKbIdy=3f=PM4Aj6fuNerg+hnc2DVmFO_
zwZB$11$A{C*Aux`eC;KH$qzUC4Ffa0Xu9E5VIK5kqv3gJE-@kH=zhLb-L-#C$PhN2
zz!+SlG-GX<y+NJ#16$7PWEfLlL%dBwLMx_Qa*1KbM<=c=k2r{biL>Q)(D(6?-WHgu
zmh(pGwfXi0`+6|CNJV||Z$2xK9_|3fENMeo(0|t;eLTKaPA7fm8Z&EsW^;C$^HuTn
zTHZW<shA0)tDCQ~)BPy*z16Bu?aoR%OEjA*l&E%n`XR1qNKl!i4k!IcYg_Ky+=r0#
zO*4I({p?}tetI+m8gTwOtT}?cO^F8V`JuI<vokt+#}6>fQF9`sMUbg6_py1tgxs72
zNqBXGypG@Q57}{beEp{Dp;_KoJX_~l9#9{d1$2$VG0L*>UVmt&eyGvedu%_*FeM8a
z9T0>&<W?49?(2Tjnh^0GnusVf+9JgvRI68w2^m7zC4kD!w$DcW9x&zKH$hf`XfUi=
ze>Zv@UY;@M^h7iy71HhirGVWQF>b$$*;#6y#1u9WS6qux1WcZOi#?(92>ZC=o!{iT
z9Q$G!Wfj!E)OtVA7sTmI(;<<amjZ4N`+!5y08>isRSYi2q-b$YJ=!AwImGJA;#gFF
zXz?&jBp`?~XizMCt{*rg<oI3rww8z~d@esE+|5wt_=r<ozS%*lsiP%tQsvLKv2~V8
zt*?hyAL}8W8W<Qm|1B-^m>_h2w9s+`P5%6G8^z@OtzFWWNFnlot~g6?h?2rhpLPE(
zn)g_PZ(rJ(Pp2y7s_;p0o-?|Zs27A}>nLOiCD!xk&zG&0r`f`=ke&Z544SHi;}aan
z#-JDs?QY^j>mgHFV~=d*_Vep&7qD5w>7Rd=v^N3|5mxVA85BZmSVlI~=Gw+|91bLI
zL$P{yUV=Dpy=*$RNkn|!IvgN|^l(wpx_Ej%uk6ch6<TL_j?Z@C1k}dh8IM`P+WKDl
z9|8DCbe_xJ-`@6Qe@$?1Q7>(Me~x4j6a=3WDc6caFq@1CTT5IDRC|Pw)%qhEnzhI8
zg0yxVbXKaNGxQ{JEo16>{Fd6@4C8{<;2<M>yAudOTX@Bc5a+5P5)}>~M3=>hn!o=L
zUsvJ+)W74)LC}Xo<-#o3>;Z|}X{SCl-rL4L!<cm2B58GK8s5<G_wYCS+h-nzihA4l
z4UB6zM_H|9Xy{*=_vt!c#<H>qm1>>;X8}D#%v}9%O-ENCMx(a^p%T2@EZ9s?K%nm+
zie?~N)NjoS7;_Md-2Q9%SHq)Vs9RLV$!VEt^As|`iD2HW=&Pb)NIl~NLH4;}EEcII
z1G;j0`^ih)mSYY^D|#tc5yTZMY4p6^JUZ{sNS5Qx%|l7a;9j}UbMm5r6guJJO#j?X
zo+I|oDD{>Ic9ZKMlI^`;JF?%IM>TF<Lbw{}KZbLytj_N`kD4?62{|0s6f0taR9ly-
z*hIX-cKA9IOQndVGb|+K=s2Rfg=Dpz^??<(Bt?LEum0+AmU1Yj)D+mtmqubv4Dt=w
z&nb*+n2<E%^2@~{rC8P1t#Rrn6Dpvz$?V^8IxBs)*QhH`c!aQNs_$<xr6BonI1w;T
z6OxQt!OG*q-*d|~W>;FDt!z_Jq+LcKFKHz2rlc%r5NM8<afj3;Qv`S%yup0<6=*yw
zU8kfxlFEuT=Kjhzj?~h6jx$7+6YX!7DC`o-K66sk(Sy(MM22&@a<?&;x%m-`F`#dH
zqK@A<KFI&ntur72!;qU)Gbyo(DoByRBF(%{P<X<sk94o2S`iqW0USX^<)AyEiz6%|
zx6QX5Fvy-A-8Ps&h*4p3RRHSuX#Ca1$~Z@S9xqX!SK6iB+}{qvC&&i&i8%ydq+(a4
z4T%#tubFt6u+aq+W+8dxEZ0i$CAyxUr$whLbYm%pzX6MOc_+@E3KS}WVh|Z+K}zEy
z?wQ_Z7@C&28gynXX*L4MosO|{hZI-2)fKYu9%hhB)@X%>IkKHm>1?-axyypt=)jVY
zU+qFgN&TEdCstaGiRdb8Rq)*pfbn;2*PnA8G=gH@MKwejFh8EQQt%{8lD66>dU@nM
zlXyu6O!ZScfN+(fH?$&8!+CNG@1)n81{wuvAg9vh>2M3U5(vWyE8YNsNd&YMlQBn!
zXd}Sj@*orSRM52`r~X<Nssge-eo{t>{j#d8`#FRA$V^IG*3RVgwM197Us$qR%*gDQ
z`&8O@9X%!P84!Wv8@^RPY$v+;y**7Z82zDXg*E=%WLAExMf^aLqUS@6iY-^8mMp)x
z^007F^#Qe-VkrB$DsA^aQLKDuM8a&`3Hs+OYM!&~zEq}$(=dJ0nK+Mux2=N7$|Tq<
z#$U{(hjBq<XH!z}8VamDiT|mocwFG~Z#4!}%DsPUPtraz{-@r<iuC=zr4U9$M*ro%
zWNuVN{;i@=AA9L2lu4c`Jh>B6>c4fQ8$NuNK0xM^e^{4lVmPhz`(=I&EkJVgLFU~^
z^4@c+WHD6*vV*a@Z~#qEkZSCKJc?^uk0RO^`YQ7e)ZNzmD550`x+xZ3t8?VpvJ5i*
zR=tQi`kzfzM+RkP911PrtH(D&af$=CCuw#|gs88pW&SP*i0>6|Qvfy$ZHm5&=TK=O
zP-Aobdr1_^g`-M&E@8s&<*a%ImcraM2(0VG^`)!Nars*^5U25>K31Df2ih6*Dqqcf
z0*@X=1Tr1&w=idWLkIN$B9#EPf0lP)&Teo{2hFea9}KN%KGDUVK<Cs@+k#$d^jf-i
zQ-e&TbLg^lYY|}?fMObvU3!ZqhuXje#DvXNG-mfe=aPAoyiF;+tlUZdi*BS{L^#`K
z=PiUbiKT`2jsbNN0rWBdAY|$;F3G!xzt<{W5eKc41e<Aj<X)`f4FVO8jq0xkx-Ton
zpR)pZm)R!~9Gq`WB=_A~Y-}1MBo)!HGbO+dv^Y9_n6miFzdD)Arc53cEo|mPgSQrG
zeP9z)WHKg&eNqL*lI1lIiJ?J~z?gd-Dks60bz2yq@j_(75sx7h{1{p?PnN5xbZ8AH
z2Mo^nW7pQ#EgWkpN;Ti}{=JmDp+Ks@t;p#QRD_LothOy0B)di0G83(~RKF$70On;n
zHx5C!NZfB?9-aW$LJJk_s%N4axacFMmb{SS-OWK5U8&8R<g7V#%Q{E0+u33-Ge0}q
z{&hUIVx}5>KI7k|3uIv_JPRzlrPk|<5RvU`F@yu2pf(F_?K|=zLAQCZh_Q1Sf>wpg
zk@YpY?Ii`?PmV)qEaXVi_3MED$?YXscSC)C&-66Gih?r`GX1;ZzRxU#8b2JB4RTar
z1+s|t4xt0B8>-(1)ae<i5=1T99i5yU+y5nfn?`XF^0gJzyF7OaR~^bFc9j>C*jZH`
zL|Kn=7im63RiUo@j235QSMOZdb@9MJDAg_LEoCniz+|KwPyS<u5Rk!j0);xZsp#Zw
zW1?cQp$c|(35Kx@?7K<oR-uQ2>kFfA1O&!U3fyos9PG-NS<40XVfE3<+;YS*%h7`<
ztRfQM3n3M_hIx*U(L2k7S;gXRrb{DTDzDxGH}eX4m96q)^s+-~<AI6N%=zs#jVFRp
z@kebEdOTIyox>3PxS!Przf8D#<H+o0K_$g!waO)j0%a!xD<enl6!4SA)o-TUxIhay
zkFDt@p$$Xi1h7Yx;xGZd`1z^t__a!pK=6=$)6lhftTJgjcI=KM&|Kr4R#_?f$+Wfs
zUwxgY|6SSO4X3tk%FD51b6%P2wbIJ4mP}N%*@|k<{*8M&y+#!SmU(PsbGjKPI_BfF
zM_-l2Q90j=nYw-XVMaRH(L3gACCrl*-s#E1Mgs<xwl)FX=SeSFVfue4n-{3z@9%ZD
zb!U#GAFTo}ljS?UuyFE)Wz~nvHKQ`qq02}%P~16gq^&8Jwrw3hbxPD85lhmsMLFt&
zc){uqEqn@*$y0&(gReke^Ma<@-E&8`r93-c0r1otC|J4C_RJ-n8`hR!0RL#6^d6lu
zWlXb;{D{=iHJ)8mUps6p<<WF=ZN+xu24Q18o^nb0*tOdfA1NLDwo>04VV`&Bc56xC
zX{&Q4Q8Y+mXb+vwuxiUnkPt>kro|3R43PREQ+e&pt((Je#G4!fFK=wmyfgzL{FPVa
z&#bKu`OQjf&V@SrzKkli%539Xg;iu--Y>;lO%6vs8R{`UN{l7KuP^e&CGGC$rBy3-
z8oj0BwlI+8rlfNBxy|bxS3szoSrMY*0>Lob8O4%JlvIPsV>LBME${)(h406el@ct6
zlY6m6#)qdg@@RmVzN~1NTp@)BNN6H36N~`Kqw+>|G~qk)rgls~o8qEzY!+v0V7gU-
zDsm8d(*m$KkYYrbuz6t{{tE0XKRp1#2Jrpd#($)tfQX}2s}_?r!O|f#2Y`+nNB7om
z8NRFJdVMR>C5>iDOp0}k54LU5a`Q(R2$;$RR_!8BC9Yg|T`T<gU+r|&6$if3@i5Qm
z8KC9P2^}Db<*!g1-YA@X3;<gNeF^E5s+|3JP}+XSn8T?HIIiM(pIFKq02&Q9ZG`MA
zM0_s(MisIpLsC188IdGg^GlRv)?SmuY^yjl`ShLL?4Tlc6D*q0&a!lt@wWo~Ofjb#
zV3XV$vcy%n>~eR$9*=1V!wn0ft@nx5rt~Q1wTf`C(F$JR#Lm?hrpsJn(sn-SsqJqy
z^3XHH+-PYqH<HzKjjP{1FZ$8CYwVJ~X_<|PjM0-KCqbK}$O&?q$eL4<)nltPQezaF
z#wP?g@CB`y=`dEHi2$|K0LC8Ut-L`L@@faGcQ6u7Z$o&?_Qm%<r!o}jcayZN@?#gE
z%wwUbn<UPqa?JWB*rF<$O^z+E4i*t>sDGK&`5uVm)pHSZ)oSxZleR?r3$*-gYH%38
zGxRDV>A%AO*mW1aBjSKMD223R1mt!6!F9y{>XUe4;yijJhu)sR%_Ah1$HbX5>p+Xe
zN0)Y8e%G-5yx7?M{ZYnK8i?_fI=Ms+(X5;P*G8N4${j8}eTRDOH({b|rkCXmmcXw2
z7Um0>eng8eV7g_9wj<98pdvu-m1SdTacXY^CoI&!OQwt=pmP1ZDx`RSGL+o$&7i`>
z`m#a7Nn%+b8{-?~cjN3Y{AT@4XgI5Rys_6_3LTTBce-NcTzc)m&IC89z~n0hoxu_q
zcT=5j@d7^J@?FN7iW=wlhOvbrI=SJ6qFy>|L8>JywGM$F?8q!PCAs0QiZ_e5=_P|5
z_hgqX9xz%G$BX*D-yz<`D%=OZXfIS_m@5)L9^@AXs{~#D>n5qgCI*!}{e}eoS{)l2
ztX8B}kXu_M6^L#@{LQB+S}@nw(bbk3`&A?LF)JDYz65PyS;*zY5ZFcCcwt4trbAuK
zyJ<AOAxyz-%Hs9>uSKknOG|5;l)5V;1S>0N8MjFQh2dLPJJ<wrowRt$Q!!$?T+;-6
zK)C1e&0NDr&SkHv75s`Bu*R9s#toQGwmQLXK&XX$oi`(h7Xh06_-i2#?a{EajILYI
zf$tuo>{e>unyq-y&^acqXnf_jl9M5eQQ#r*{43A*7w+zIA7<@~syCbPi`0b~!5l>(
z&nPXqlBU=sDkDqF=J#W+swr{oe=4%Wb-M2Puv(p(Hh7D+^wFg(L?cL%DzHyxTbT(?
zN25umzDhJ#jn6iAR+;bG92rIHzCRpFu3P~0cp6lSBL`f00jPL6?t+CVMcn^1RB!ev
z<jbj<H&WBho1r8$ZPad9e*&V9H51SdSL`M26}w@y$Ue5TyM>{M>4p^h<^pxTS1zoD
zI3AI`M|CLdRmuMcF!`C^-)t`+_R32q1UF!b`(TB(Ad@9bG{15vi8VQ#X)EnBT_H}G
zM-TOP9AC59itYI84EM?=TPh=MB<w2NECX<~3T^i~Ux9@>W!Xcu#AeH)m9(_U&iW2f
z@bG7^g#;J29cZhXwpt$QW+O0Iv@-z&D!Ew!8sffi`R^IS35ZN{akP0W0>J9as!dqb
zxCx$pQ_tahLJEZ#en6@G&lEEPYggwSa%>I-LFNmAoljcCB|Z+<JTYx`bQc8dZBA8`
zwJ?`Q1Vvdi0Q^V-Wo_Ez9fCpYe8tr#PPXe->X!bk+M5aOm8U*j0K56Q&gpVE|E2DQ
z>Lka!WO5d|Ygf1+(k>Z7E_-Xk4xJ<4A0)y&v$LnM4()-68&Y#CYsZHLtfs*>y@I(M
zdn;?SQ@LM;V(GGtmQfl-=t;<x)u1x})w930iPP1&k~LoOJflNQrC_^%etEY)eq6zb
zZ7r!9*bZuSNI5@F>a(h#1Z8V^gwcoT0d`YPQV-rZEdV-9$j>p0G}sfC{{Y!O!oZtH
zAwxE&cBr|$T4AH7fcfH6r4|K;v<E>!geJ$wnECv4h!xxpv(_5JEOy5fQht_ZvVC*E
zrQ~>cyIUY!a5htm2_RM!Ak=-Q5X%j}#+Z=s6u(CRMNrTo*&@GOCh@j$`qmtj!DXfc
z8m~nPxR(?Z(r$^sD`s(4x{ZjfpKKA<Crs$<^d0Grddo>C0QegXQ76Z~2sn_rX&Wwt
z8|FG=Y#mPDFH%-=sEQRxdMX+m)I!Y8;72aieb3ngugGmlXy{5m<L@OcaJj{L4JiyC
zYv$ZQ@O86?DiYRZ>bXu$s(w|Sip;LrL0YFqe>yWq4K#%cNSx13w{<3=K9_4%teA2u
ze_>i8w<}#J)bO7@cWJ6xoIDjq&GeMpxM)Zk8D00xw6hrjvJFEPI!Z<`mww|Bge*X!
z33|<0(3jbU+8!Wm>fSbFAB)P@oD__7d*s58l-{dW5!QURJF5#&>Yf4f!j;u@*&0oI
zgIj*io@pW-lIlO+Qy7npVc~`<n;Is`Jv9{Pftt!3jKVr=hmKfgmUy(UueD-sV8<&5
ze4ZnWBHP<$?!<Cm>0@C)g#y7U#(7)oWzPCFYRAM1=E%^jtmplgnJhxarlO_^3!9)R
z(vmzf)I{;>;SEiqbljv6Zb+ZH_=7_@D(feS?-iqP%jPI9+mkIVo{qCsSFgP9Xws@u
z{cN*7yLc+(6i+I}`7yh63r;%s$xN^fBTirq`c4Tzz{e8?p$djDS@`1FcP^CUwsm-T
zXfu?9Er=R!I7QGZemqKH{0j+nw_%32U<bg!u=@DUif1dNZyOdF#!Fb<9jvIva|CZ*
z7@1hQK+0nS_{hh{ht|T+7$DAbW0&UO49NXaVE;LlvApynHIU8FJpXQjJo@C>WDSW3
zT@tSzBXv9X$Jr|BM>pAgB|_qs(vm-~_@H6L5LWyEqW3#Ji0P&@?1qE@RJ$k>{@mXo
z@mF@sjmX2~WF46<i8Ru39;3a1@~b-EBB|BIw;jU&$#e<*L%zc0r8&yN1=`^2>HR<%
zZnODMn59^MAJ3u1+LDOJVd0&Sf<1O2mzt_3+FB`Ev^Kcrp|Ic4eq>Dkb>2f-I&3R~
zFJ%W_QGms21gZsbS`}6DGIQNUuVZ1s^Ir)_;(7f8CBmtZbXqAjp9@#~UV)74yx~P%
z2GIN^Oi1wcSRmpkin7~%+?0ZSP0i?cCF=KzXoL9D1Su4yvEp;{c|ro`vpOon1{vL{
zY58o<k{?Uowr*znm<Bug_?PD7av&sV(TaR@g;?;oDQhm1*y#OVPqXY%K@c)!o<q$1
zd7f3WQO3Fu*VP0*_M*7Zv#!0=*pW}$O}(F8^P9}&R1LdLbSVX_$rhu5(&;`hf(1zL
zy}}6tptY-w{wiJl_oxHwuK=R2-`4!d%~)}RE;&c0^ItTFYJ{w_QG|}b4<@9Mr+rId
zM0IU#(J;>tMJ?yNiM}tKMXN>DvuD%m3rez<e1sA`7?RFY3_DWK<=yUVLsvtl6m-JG
z-S7KYOh4SOE6Ee1DmbO0=uqW^Fkg|VCmuPN3LE1tQTs1U2@3ctoMJ^jakmclw~sA{
ztEcM5{nyV#ot1=dd|&@(vf*FNO}y{_%u^(ri4Z<t%y?(ZK$G4250->(7SxVz+E<f3
zS60=I{Ob$Zh8_dobPIWzI(&o#u7)hO_9zA}u!n_Cam3k;SC)G#@svz=*ql<F`PWCm
z^EyIph4x(}D*})RJM|pyCnc`*ljYM7)N84-nzxz9N_p_x3a`DI>gvYaw=~rpO;To(
z8~0lMd_*wrE&t%=ZNSmO^hWe_gb<MxP8$I3`)c~6QvW$XsX#dRT^k|ma2hU9;IK(%
zj6oxZ=FMic+FDYBnu%9QKQDlt+0SJ|iUm?d0MX`)UkuV)t9}$G;^Xa^z(VRZ35xSh
zh?DOlpHu|QIl2kpRc|8j(zWr&i733adP0cKq@`YCoPFZIm`bzXwv{DQMjZM6TcBb`
zE9nLwmzZfL565mE&7*gp=7Av<Pm{ev;5)pA?vlqd$0yBwYl}CsD{y9{6LN%Lfr{F@
z)dL6YhIR%}cKP-Jo+J!AeeLk*i7J&r?}qc`lapvdRA``Hh+`0Yjp-RDM~RhBdEI}Z
z@z(0rDqD-;6`vcY9T08CIT$jYMc7`VgM2{PS#NPxSIWy5`#(c;O$OGw3@>lNN74tB
z;KihC81LyZIqV*R%%fb}Ab;JT@$Sc{Vk+y&4@e@}YD?EYNmw({FfZLYLW7n{m7f2`
z7<`Oh?ho3cgCAyZEHg~Y0YYkTB_l0ISwx*ICyVi_dK5F?Tb+?+t2qZ~@fX!BuyDBo
z_^>%_%e9A9mpZDNeg7N=B2L<(xXx5ppF@gdN*z)0E1894;nOZ(U}w<ZybJkJ)DQS)
zCnBlVpltH!A5BkTeG+xX3mH0Mue|F*OCzJ$xe)RH@B#2PYnrDQ^=!)AT3YxdBr(#}
zK1Ed%pLT6p9Qey$r3~$^xVeH0&G`+dxJg8?2mgOS`sz>eXj@pnU-f?K*0H0s)N@zh
zVO|Vj2;%>Pq@k1LnI%J?M5?$M6J>d}vRdjJ*1xN1lPXcTACX!;tli+*szNlGSL&X=
zN7~YM{P|8wJfR7+i5aFdxgU_DV`+@hWG-hXdzW3_=3r`a^>UsbePU7#W`ADUv6E1T
zT4WB=TgD--N8|}VqJa6cKu}XDZEc2%4PE<-7=wt@^;B$gT{ryN*5|BZG)<^%|H_VP
zMhsk}W(iTBb6+l*bIF=_%Q`lN3F4se4%NR$4)wJV+S1~3)yzDuFXLUfR#e1>1-EIl
z&bJ_u5Ie8h;g@~3dx|5co+Z5S$PaH~8PLrtE$1r!{r6uB1K2al+UEER!5W_R7%+oq
z^3!2+Jk4s29)tX|x|pCVNu?#bu@+!~HuL^<_wbl)S7_+(Mz$dzGWq`vQnysVVwI6B
zN;R~Yr!@=$S1(T;u>dAXGpKy5#pmfJJY!t76BY_>5!s)g=frH2s?{PMnAubo`7<fo
zEp2s+d^PyAP<pH>-BU<GD?@8}beX;`azM8O)b*9{4da=5#t6Q~Vl1iI#Fn~kwj+KM
zCnWBLuLbBR1XdNz3P{4j&$!+Y9Q-3pP2^Gy8NIy!#ti&fov^Hk(nS8qsM<aT$c30<
zxz^~EMxbbPkS6dL6$ZlRImuL(7cFMspZ_wC%4{4i<-=!sjDXGslptJ9<Y_J9gFk64
zP6ac3SWzpiTS*MZi<UhWAHUj)@9yy!Nl3_m87Ywhl<<VEG;)m*?r^IZI8Zi^S5RxJ
zWDbRW%32SX*#TbB=$-@g3H%-TE2iRxmPKEaT=4qc7y@vcaK!@SZOQpGmYPJBf|JZd
zdbsxiaP)f@SY96eA}D_>BBrg2f>y|-)gjd%;|SPG7vCzYk4FUbn<yQU8&)&@?)s^@
zoarTZw=LJ|h2B$ZGPyr0|FhQu9Rt9Z*=tZin@9g%#ZfIir!-I&OwCWh#3_@xU>Wrz
zKb<aGV>_=oRxtz#kc$y*IXem?Kpxi2m~bw!uGTYp*U1)_0`bAZ`e6BQrpSb;$RMq*
zD6h4<&emu{#?mMu4<B6a6avClsSTL4Xmo4#VmSGQ$aauc8>I}jw$eq*aCk%zD|;i7
z^*2naDIHNv<a-0D9P?Kjx7M~sNwn5Bu9iRFP<O$mvPxbi1Hj!IgaBszhVz~ic|%*B
zmdZqe;B?a4)L<zxK%&y)L8Vb{CSKH(Xo*d}3LaLehs}Q;Xxlc9A~x|o?c@>H*Uwv~
z$sg6IB{(XH4ZrZaf2K}i3Ha1G^J&`fAS)pM&ARMZX}gWOt<6wG$LfEgHR;|C{_z5{
z{3OMv72$&C{(=JG%bBhHBSOW64}kxUTnB{g^bktrS&n1gAsM?zS;%7n8jJMW`)vTn
zpm(mi15aJNtS*sinyxo*$K*ynW?l<Op>VO-j%W$Fm$;UF-@!7=AC3OHHZ0aY@xA)v
zX)|!bug7A3!sJ}u#A29QdZ<EuyIg}W#$Mybl^C8?^brFppOaMl7rb=+=RAEpxz9-=
z@Xs~l6l#yBgtn5Sn}dm?Hfs%Qb8LIBB6w)cjDQ4SMv#6Ue~G^K#G_d$<!pj2^7~+@
zhVha)qj7h10l<|hKSq6rW1_bxXinq)^8z4dm))p>hh3VQn4Y5tq#a85f{CG>lo*H0
z5qtgy(J)rtYY&VVqHkcw0|cZ_5Vp4Ilim`f-tF<&!@a(Zk+P)cDJh681IH;FjZURP
z6X5XZ+&@K95v4A|=S3>Lwyb8BsAHa2OcpS92#3-1Mqmwp7bD;*x9gsss4?{L1}Qxr
z7Xbf?!io9|q_)fZ?lxN0$X`tY0HvYY^Ml=G2agW`F%Ru5Oc7}9kN00?Lns2~C_40p
z1TC$-t#Uf|iiTaOe>wtGQY;FCnMHCVXs!Jo;69;D&&jH<srFS)(k~AsV2rq<c~66p
zHX;cc9U8~fJ@k#l?csXxjzcUi1^6H#al1o%6@2N4UX8B>e6EEx_6c(F&m&TG+eqK(
zZjqD@o~rJqXeBe!Ew-9HVpC16&Y?{ac-uqYY_eBGwEuw1Q6@M}d9cQ=A~n$gDoj*U
z93pcj@N4Y9yp=e#v3dj-5vEi~P88?!%TELWO=azP?0EXcFOy1Qw(#N|=&or90R<%l
z>mTg4|D;h!lVrqbG_AeCzjeF)R!>CXtPG4CKy}{Atguw*<Z1ER;>>7=ApDJ9P!lJh
zoR(Z;G&HBTjU!S1!C9!K$*e9jDibkH+>G=w$0F<io!;B~@t8@|Zr&Qf(;LV@#e1~l
zFGS$kS|rSc%Cms6QOiIpF?RLjX!&y}BKe<%lPaOV+D&>B^c9}ya;>Kh5+_+H!We(A
zNvnK!GNLqX;?d7oS9A*B+X}C2tP6tXwk5y4BnP>+|H4JiW#h%Z%@`ZI-l9wY)PD{D
z8rp>eTdP3};FZpUfX~W@f_|V+MT5T@OY;NPoGL52*FH534I-$QgV~0zlaPBgt&ZFl
zc*~&^i{B#$YO1G~PHHJ^dK<Mz33sY<HR~4Eq}w32g15T5aAL2nWl_aE)tM!<!(hTY
zecS<yUsYA7b4@2N9=H5&0R8dT3xNSa-43>GJXSS&&O!}MId#Sr_>%WfKAQi{+`PNh
z-=zdu&eqcQGYMq#O0I&8nJ}cypnow>+@R=JG-clK7~4r+-lJpu{r`sPg4wI0e8?Vc
zSg{?P`pB=~*o>ow%bg2!8|#Xr&-k|LquU5PDVqyG*R5+mZw+9=wz`@0efpjvsVPGE
z3lyx_S{I>*zuuUE1mGt1?v_+=+<c2U{x1UCqAtK|p7e2>^nJ(sZ<jF#2bDq`DRD)v
zT=;&}uq07QX`YZa!x%S=DmswxFkhoYC4Z4F`a}J__{wlvLL(HQ;N*aGFZQL4qnRu8
zt6clAFdGL4$4NaoIe91p&mZ<~SE$x}{8AMNj&q3M$JY<kA1^Us(l=T^3|I0UI2su<
zV;jidd@!|av%dH6q^QZZhs#RT8T7o1@%LbYg!V^zi)`>Fa|6+r7eaTV4f~co1=Ure
zpgIfL)eoE5R`0SpX@Xgi6Jrm0V=%%1`1QZNRAKq<I8CLln=&8?s^H(AV)q^ttex`w
zr+I{H5_!1d;cp&Z{!e)1uUEC_?_M^|Vcb6-S7HL*I^pE|WYTA&rcNV?Q=j`V(p@EH
zpnXtN6;Vq29pMQOx>FI^_oPtx%1cRiD-imv=L)kQVEi*@5ul<)A1ot&&&S<sI!@Db
zC4@uq=KL)Mys@W%POJV!$47+s=a@*uNGQhdhksh8?<0SpMT4_Q=yW@Psee2~06%zo
zFqrtMjydKar<Z?_Fgfs?J_eBy(;#smA)SlM!PB^oiLvT$!5{XKgg%d5H3;qG?3sJ6
zVpH`5q2lR<#prQxV5Uxgvoahs4#DI{5aA6QLGu&C!~J|hjVJy`MMMc1>Ad%OM>jjI
zb>b1Jh1~cF!7thThbM(GqR`Z|$mOU0pcGEbo`a7H*!>5isRW-ydahWsKVsgcUX295
z#T}|28xqMmbBFf~MWyul{Z)6%#xY=s)$|3>kNkejyU#xPGv_PanB4I{#-MWlp-~SW
zRF?OKgaQQ$`%-pxr@psqDG3P)Ct`2Xl*d>oAD>@t*S+m0(z#i*3g;X?5N}|gzW{#x
zxahS-IopEf{P=rK74hflN%S>JTe!4~gNRbEx0Zh#otUQ3^pnxL_gN>T*?vwwmX!{E
zv)6szZrx5VSFaJiCrx^h)TAw(a{x`snAxYc3F20ow{HN3c09G>gS(?|je9=#2C*cH
z?2jSg2svEsPY|$ZsmRgG4_=NAoprzZ!EX_D;3<+AZ|;c_pg>=+^Mf|oKRIXO3spb>
zW*}f{di}!Z>hbydh(>+{{+FwOZ#`6iZ0U2vY8zBZ!ZJu;kBu157-~&tiTA*`;E`JW
zzlK*lr>E+@MUWdD8&FpkcHQa=!N=efnz}+bM-b`x_z5hUZJ!uBf-7;)=ZcBf#qy@e
zG=A8Is^_X6FohvFlqk4Q4r9{&4qpNzP<^LT!?)jUA_+~M_mOKdxsUUX4w**e`H<~i
z-Di956X#4ZJTaw=aTv5Esz$G77%v63qq{x-l<s~DL0=+H#BgJ)Wv(jUMjkXkdQ|yZ
zhkW1DiFNZ$OvK(choR5TvCl{7%1Gy)vG&vY<rHnD#*=QGTAY?2;@vVLNQi8A9HMi7
zj%XWv$*KGOZ=?XA_FI4GL<VnI0w*A6s`*>>yw&cyXX`z6K(RTHNa*1lWZ1&>>M8;O
zU-uOi6S0#&&oTk${7%8GT+ERWv;)1^AMZ0Zi54Rjr$Akn{G$I3!sjm)cTP{r>qAfU
zYscHBbKckH*D-(J0A+=L$71yIq`S2t>etooe|tr#PbyPDQI_!tzxHJ)&|j~m>Ktyz
zS@FjqjBQ1z*(;3zz#ajBdTI+WrbJnuW?t%D`=^~mhg6^HSklQpbWyTH?JS@j;pU66
z;xUMaa*gbrxWe<y0KbF1^syN_X9trF`=^%&?Q}lTb=cPSIZPf)k&VrICCr8TBH$6(
z0Yisi{n^)gl4l+H78?L<BAs&34qPx^qCfpD4L9pB&23?S9U8kKiI01KuY65Y&77!v
zNx^Ai^xvKqjGe}xNVkN`(g2=q$5HBrudB~HIY<TvF9nBlIj9tG*fQ?dSNvZ+ce6Lf
zApxi=p|_t7gd#V-4~8W5QN56SPSDYP>ppaQ(9?`65JKe#l`=Z>e|;+A;LY+Dy7p06
zNz3`R=QZAe%(#EL`GWqLy;1`qr=`JWU$KXjcsFL9TxiN<e}b}8xb-0D6;VUyKH_e`
z+%GgK)_4$MxbAX>|I5@984G2E^AlBm*xY*}aYDAyp)dFM_vTaC1iBxJmR|P0K=2-$
z(PL|Xg6!Gthqv8V*K;}g6*WjbomYc<i!r<#2JLnWFoq+y25S~TW5;yc<NZ{&sJny?
zUeA5x8FfDXdZ)m&)Ai9r6I9!1V_qdp6PgclJq%fd5wX*ji<Y;Xy}<iI!~VY5HwR!9
zshwsO7@aIXpQP*^XWlI}05FF0HabAa?Nd2|uRcNSszPTv5JN%tlQ#baiAyNZ9l8t6
z$(iF=<pvJTWZ;~2TE2>Qw}-%;@Q?@UlCd;+_M4;ebiIA+y3D%5;pDLGU^i!e=;ow-
z$;SSk!q4;8gyY!nZp{c2&NwRRtY3;luar}Ax;;MEBkiz9*@ncL#QMRuPuIZQP+lYd
zo$azY`vu>2x@cm$?AVZY9S_l)R_j-{OFaJuWt}@{j=>X5S`_I?pYa8fLoVXJTY_h(
zi6D3%g5-ZO(_M+P@%Zz=bG+mEEG*psYUuTYC3fTG_`AW?ls<BfmZF`lb+0sK^jb2{
zf!oJG-+%n;)M3r$tzWmMJj`%J9M5~?b42}o#3Ld&Kt6kcuF8n1_b~sb+|%hPVdPk5
zhF9saz@(fzQb6~M>T~Ovl7iDH^}sF>_R|Sc&N@6>vsK}LlaNEke@7EbWCW*zF3c(X
zpVEHv4VbHR?`^6pi?|)dyDuPB7k|#uA$}1%hZdhy!B0bY7}L=i)ay@Q9OaS=y6Lbc
zW98Fo?X~;CCV<vURan`RLjG0y-i>tb_VN%*Z-<eJ16%NOTMF<P{Cr@9Md9VT+II-m
z`!=zNccacL0u*VUZ%t9wT{>ClT>Wm)d^=lqRR=*o3mvS2yF%u`gfu)t__C4RER2<G
z7`zr{M#qTGer|(l4PnK3kO&;Ny0R&EtU6sC+Jmw$Czy`gy~<i`&$phHZ60>bq3%e_
zPjYkp%71a)!YL1GEJtHO`VfuRqr*tYN4L#cy0yisiU2HNGj<2h+x5g9!pRNB*dzEP
zH35Dwue)glYa4aGIejRbOIZ@p9;=thxT{-agXHkNtWjP)dBX$wllM?;4y4}KxkaPj
zaig6hyZV!>@=}N1($kIuQ})6A?F&@jwjbwpmlT-ufR}yHj!phLQ$m7Sd`jtCzO{OB
zHn^s>`TUCc($0S#ImyAYgv^T%B<vw2GfcZ14?W9quzOsL+u6WlzCVpSdwDeCCRJDy
zeXiI)qd;S?<iDQ7c^<3Ke0>aV-*;Ja%&9$R?zws@w)e;Cao(R4^|Vr7-PVc7@p8Nf
zv{g=1YN1@azoN{+Kz(YUB+GdjZ@{U<hl+tk>E$u^OaQ}EQ%g{ou(0rzTE@v`07#$c
z<?661R&%)SwvL<ksh3V`DEc{rvh26X*}in8{aQ=I{{Ch<Z{UH69F~CHv45XYoVV*M
z-piLqh+{LIn!n9ON%IkV*AFBgK#zf_>)}L|@)7O=lZOR?-51vE4PQxhk=66mGqtS6
z*HzwbeD>i^6VLmBMP5;$QTO2o!aG_F093cqY(T*Dsu)J#G;imz{Bm=)-MHkwX4QSM
zYa-&Ho#Qjk>j6XYS(0oMKJ9C%@_4A@UZPkPn10xfMr{^(*7=inry;|Ct9x<r$RKjl
z%IklPK6PdP`dHR1^3eJV-sPDc=zK&P4c>U>hsR%zYGsFB0fh0VhbD=3!;XhP&0r8=
zb!yh0=S!Hq0*`&x45z5=y1*4!dE-}ml`n8|fn;jw$f(lOF@L0~=2XRi>aC0hVb6_i
zPFcs9+uVV?-$Syr&fN|#eMXLM&ExOxmo%7YmjF}czN+6t4XS%ew|869_A^-BD0Vz<
zfWH~xDQ&zPKGj#Z`$oByg&qzlFV9x)?`|hMC$G8>JhOA|7cQK&-9@fi-hS9KsaKf3
zumUXCnS}LkIkc}`sivLPFVsCkT(`PId|QVNDuF$E{20bnnVkf6LQWGcMFNH$nUVUU
z4s)+EtF{sIlt7;~lA8roUj1eRec;6tY08wzTBxh_vZN~t<Ytn4w_1q|$E}I0G272s
zvp-kM&+^KSd{LN#)!z4_soAdTWitH>;na{;MyUja-T<Nwjk&~%vyzRy4#)Fkcbm!U
zo-y6af;}d-5a?b$qRqgm<|ne7y`gK%ihr%2Cirns6}4h#KSqqI*7@M`hNq?VkkM=G
zna=^LU<L;YVxYrH6U}SI6|hFx1EWPHM7*r+$XUCy9Hab&puuR{GyB_nj_Jz~3|1X%
z2gg|I_11-h@hqV!N?X!O&s_#6um64*#P6cs|1K_bWo3o?wq{eD+aoY`qx-v?+s)2x
z&3UM}z};vwHt5yJO!3u-aZ>m>)_=^p3xCBYFM11WfDpCzhK4^-EZ1cMeTsocxyw(^
z;GPbGW7u1eA-`1l)=Q!=Y>u2voRDU82#~u3%}7t*FDi%H>)2O&nXZvsG+#XOZ@6l8
zC41irICSr}iC*r`=-s?<pF5v#yj{~;eJF@TT7DScFTgUg05-ooNj=W7ZO9Xfy2CE-
z!<JGaHA;<O7zS(o_RdiDl?_X)XD3MOLC7A?g1`4k70_0iR8Nn>bm@rBO~xVbjQrcy
z>T=5xJC^A4gf@lOM~`DY@BUl8F^pK-b@GG|b*N^Z(@>c@C6nl1zNL%hhf91G%=q|N
z&+Mg?YX0J<>)37>tQkM&<;Nk3$aefOQTI!K>_Ru_P~E>a-qGN>y&I<_N7)bhh~wD_
zdu@E&OA*bkco75yI1Sytnpf)&-0}PEYdhYOiw-yl-SxlTEy28BuJ%Nqmjb*@{-*t{
z@0(5Ac(odMrhMJ(Bn_Z$RJrK&UUJ$y!trxf)EU0&*y@kzwq+x}@;^FOh6fTyD2wPi
zshysw=pQ!rN-El8F{<+r4w2_*VdakUnJ%ZJ67RO7kiBi;%)yqo^%gVmSpfHco(x;V
z@;0A)C(ruN6F62p9j=FrKA?(}7?ILAFTDpmu;OJP2<8U~x&iS*lp<_c?4Iie5Hy5n
zyYHvXm75wLDAv!HB`)t=owR!m2HKOMNLV%457|C;6*3_;JRJ|!RlZrT(a#k|j|3E$
zOBYWJD{D|~;l}2oDj0W%Hvzzja;qBNEtP)ugFTkv&#9Y5<Hw`0Ce^x5c=T#}ikrY0
zS!#IuV(TU2XYevCXs@SEQqxk^@<Z6R{{i$ItNRSC)>SSMCf?7yh<49SI=CljXaKsO
z-ltG1+pV=q^WBlLpE7%0T2r1qvb^G$ZTJ(Y^ui>*-KV_h+$@Mbp7+Bxo*yC)?l)ed
z4({{2eU2nHUcn_kqA$x(ju@X4ct|FA^Un`>4@t584Y13(QJ14gCdgzA9s2sz<otAI
z)cw$JUrKQ=|83%@vZyEQiT7@!`(^On9^dCd_S;rmI?b8B<rCfp^fl4{2O_fS1nMIr
zuV?n_Gt@Csx|;aSKg_Rx{j_IxIQ&nn*Ikug?kU$(u8q0jQR>h13nw5|p|}u=Pe@2#
zGkjYOJ6VYKZh99<5#jrEeQF*98ePKHtEpK$v0tXG|FOGc?q+Xi-R^&q3v2V42<=oJ
zf)Gj`#j;b>yF!cSs$R{tcNQftFpR8kKHTnu6*GXNlo%%hLp2W8{gEXc)xNMxcr$>U
zH3<GfFo!VcsI>cHe&%Y5SNKw2-d6%@ncTj3X(ja&JJ1)l82PAd)Gsl`Ekr~Bu@2&8
z=CO&f@)*F&Fd}U{GfXM{On1!;n7qAgbqAfk&N3TAuckVmE-P&JL<-rd@q%JkQg%Ek
zJT!(S{A(WjouM~RL8mxK&GuuapT6-=T^X(14j4QFuXf>0>Nm5MKby3>!MY!6{85Dj
z1O?%QSfu~UmVY+?`o&b1cX!iENX<+CQnz3CLldR4@Oj--_w_(&f5(<B8jld;<H~+9
z3&(4P->V^@&MagDr%AZwYW`{{bG+Zk^6}T(XQJ1O$kzs?yqB${vRL7nWl++=v(VIM
zL7Z-fC+{QsSL263Wg$a<q4`M_yf*Mn*Yc#3z5fAfQr!T}(mx*s1s_AQfU%TMGl3>X
zGHuS7|85DCzKRNd78cGrxl_LyGkUp<efb;vJw<vAleRht70UA$){OLIn|;5@<Kwq}
zVE%IZ&&$$*2-(X3FSbWy|3i2|hBnPhl#dU2%gEN3o5@=@yei`RJMvAGFwGtbn@n4&
zm;Em`&#D9ce%}Nad@lBHV;1YswuyETtyliGI}cQylZ3f*nr|)q<LeZSMAQai;W5tR
zw|DwIWPQfLR~Zp;V6aJ!onyM=o||Zhg|kh=x*R?<Reb4<`@h;d*Qh40Jb+Ii2x?j)
zZxne6SR_Cmtl0pDS5X2{pm-px7=%m~P#{8534%N|RY{v5LIg@8_R#IF2qL%`c^FJ9
z;hAoIfq+2K#1?_@PzXe_6Sg0=AG+If_V{h*!_1jE_kYjKojYe{elx%OZ*FdmUu#`n
z?=)J7qYC?SlMSNLnl0ASiNQHL9D-@?_LR2&kFBS7;g<vQRcF)LVzNt4SyJo-kC`5h
z>-S_R>$}OIYbAMarjIg`L$gxg#bT}8GfL06M+4PeI{)z#SJdWu3PzFi1d}&8{LL+F
z<!i>ef>9qm{c6U>K((1;YSK=2X)CRse%tp*T<E7-J9myiAUxF*+j1fo+9Q1bw)x(V
z!`4F2`{dO5AxYkRSwo{RPZ=McA9QN%)DL;5#BtYS8owSt;<WYO2-}Y~-?jfj*!Dj2
z+XT3_J}}E0BH5G>E*LVk+}w7HuCS7_25U9@10=C&$8Go7Re<mIN&evsK-JN8v{^K3
z_54rEY0-h2rfY6+G#=l5!%3qIy0+7iBDmTi;<hgAIcDyYWLnCrTRQ%TGX(ClPaITF
zvDdom*nY^<^;MOdzeR~^YTOfu5P{!o3wWsv6%||Hdea%z%C1Gt0mAH8K*30>dMM<6
z9h^I^4SD7Erim`ix$fL<CrP!ZOul|yzXursyV8~V&AwK~cr>or05YnKEqSR$Rce2V
z)sfso$Eej>fmU6UZ@n5g9XmWT^2uA%WbG9c<}y!k-f~9+QNyBz25;~5TKVwB3DKIu
zbo!wtRIV4MY@n1}3?WufrR|NCEhzb-WYymunUl>Ny%BQn=TLCq*^GYrN5rPN7mDzA
z0si*~GdKrbz->C*w+X=uUdkzv-}^yz@?uWrk@%E5eqCQE5+m~e?mFTyTDr=!+a)nP
z>-!~%ICv4d6CDi8u~&7CAx<Z0w;8Cq39Zmu4#5TdsW$gZZ=s<vCjsnFBs~b3zIpuF
zfkex+5)1Q909yrd8_zaD9-~yL_WSOJzrwuknwN?Q<WG3)G_l{<k?jyr1h}gGH_yN2
z^(0CcVUtzG6LGaK9QJ&^UhCluJ)%#U&HJ)tz^2^6MCbx7`5aBMvaLM|R=F>7by%h%
zhDdEn3|^To|0%(W1Cyiq7+C_;cutq4D(+22zdpj5r_LHbvrPAa2Pz&y3=0}JB%^H%
z>TA>{$Cn%&S!H&W&yA7s!*YC`nru`AgeQ61q~uffmQut(fB&7a*`lJN{_Bq5JcX)W
z39?)L{xd(#WHp}Asa;=7F;f--Jb)J~)4(`e(f(ae*JnCX@g=DJgRR}nO34-%esKX8
zrY|IR4p@rggd&lstW5enVb`s*sK#7`zlWgj<-$_$0wAaDmB<(F4B&9B>YsspAIXZo
z1|{!b@Rh*X!rJ1YK7=v#0U8iV(FBA@pUN4wF>5Bs$^$kL4_LG#`Tdra<O&Ek_K0@}
zT2#{oJe&!U`hkm~rq`UCS`qIs6$3|3WZNPDVUp9RtOVtXIQ!0v1M{TurS_lo^dx|8
zARmV12r$g_3KDkrsE5}`BoZrv5S%~Tue>neRqEAL1Kf@YCVe6sj`Svl_yqPL<;8_4
zb~dbR7Y&@CBTUH;T9{-b5@#Xf;>yH2MuICqw399F-oAZO{9(tOM|kb@?JLJZEo|Xs
zm@`o|$V+A~ryjwX4g5>issa=%Di7W$tSf%pXQJ;g$Kl0oRpVRGBa_<#E%rgsxNY%y
zFPs-Q9veE>))$wo2iJPqc+`>tj7kd@GO8T&WEGu<Llx&W-|jbZFo`4z4O?O$SI8-7
z=^X6$xI+I4m;V>d=>MU=%f@<7&4lgk##+}gp>rJeWQ@$TPP;%KZnO9Z`Wq`#FgD;N
zh$K?Qna;Wo0!FcyK<sdDx!c@x1(y4!(9l-a(<44HX#&M&1spmwsN>`KWkL){p}Lfv
zS&`ZaD>tT^nvN40x}3gS9d_?ddf8i^#gtR{DMSm<nFVbHd#*O$`?Y!Yo{sf@=!nsv
z53sSX*m&E^cU(3EI<Pi*y@k?y{0pt^U#1?v-y?X}sY|hYE5b&*&m-gDhN&kD99C=m
zLSkoL{B`c3E@|{{8h!tGqe~bgD{2dG;2vG+l$+*}*EYtwDk>p&WC$WQguhvi3~o~`
zblq?Qvo7#Cv@*=U8Z0Yn6oh<7T@{J`8?In1QmwvT*GT$hrP@|I+7mS%e)kzPA75Hg
zS_zfSJ9U|>Z^6%;Jh5FO;jItMbXF$UXf%(Z!Zrn3V<$UUzO?j-1^@s@RxpJ{W2B|g
z(^<d)I*XN(o@CEtC1kSbpuM|&P;w?CE#=d+2*C~-RN7fr8cbl(y=j?rXaQi+7_2)Q
z?~cP9#^AmGfb+(p-O*m&XmpYCFzHtTX$&ys&)L5nuz2_N8z=xE1t0pjA@EqyKLK=F
BYZ(9l

literal 0
HcmV?d00001

diff --git a/doc/design/assistant/screenshot/intro.png b/doc/design/assistant/screenshot/intro.png
new file mode 100644
index 0000000000000000000000000000000000000000..23ed49d6776cd9c365d2a834b55265931a61c26e
GIT binary patch
literal 50730
zcmW(-1zb~a7runj($bAemq?CorI9WHkp}7R?odF9AuTQ43_&_3-2)^>*XS7E{@=Fy
z-re`!-R*bZ_nhZB&pCIon(9gfxYW1+01&7s%WDGwdL(L*#YRW<h?a09qgI$UGHNma
zP@9Z*Z}9}RjpnYcBnwoJ)9#`+7_F4G)d0ZnB>;p(0KhG(D`W=%Jox}%?*jmceFFfB
z&pB;cAk>bhmhY70fye)zKRQdlpn7mVD;v6_*2@216o(unQ6C3X<YnIbEFP?Qo9O7@
z0VnY7PcjBLI^S_QL;!LVk<a<MIdqHpPBYJ(Dw<G@`QdR@({Tme;+5`Fxl?1W1czRq
z-o*3rFx}4~EW@AqNEJ!a#Djxb{}9Py%UPP|9S>;uySp8?!gKtO0^Oi=L~`_bc-Tzm
z-rerB1MZ-aGtdB{qdq>IUK3M>C?bSW1&xUj6WxYlKucEXRuJm`wJReZA2e_latG8U
z0%1fcvbFMDo=n*Lfq*};o4i$L4BQvIVGvcoE+I!H616TeyAY{B$QBwxh8>AIlr<ww
zmY<1;2y^{F_Kn*7CM}oToPD|9Rl>nag}<$Gil(wy`{)i@v9RVa&6D6QlkxVT-oCLf
zWO1YB7QC|0>?<iwX_a*R!mB@haNLZExSj{6@@U7_<Hgf!8kst6-{2`}fQP!$cwIdy
zVv8|vghjTA!WsM*#^*rL-SYP;y;#YV0x1@TQ5K>}?q1&~Fyi2$aNj8F<Oi_pwqsL8
zX^&4(cqg{#_$S_fqDlD#ergvR8&Q(NfdT_{v`P9b;yxQbxXl(L)rGt8VrP2U)Xm=v
zEzbY$zfI2dUnbB>`Y<X?J&pThxQvw|fr&;tKu9;QQCvO>(cy4SMZ094RweK!9;j`|
z_mXyOhL>o3GR&~1><CK8`h&PfOuby@;c3@4;9!j0Tot27fRt$Lt^B=8sT5s)7-aMz
zlMh~lmrp>eoyOOV*-tFX@PH4zvSXGr@$!~9BY&fe4r3yGlB^9o+!AONiT<p$?BsCX
zMOv0gOG~bm4qpD_FRnQxUwF}>!=^BW-)n@Vet|QqtL#eaKuxiR7J|iSU^W;MgQ4|>
zQ}MAE8(l0q%HtUh2S*tIWOpjFu3a79?=}}I0n&`9v9qB6^Bfx!=ys)*Ap${@Dboe5
z7hgYp8r{Oc<Jrl^_o&Vet;4Wn#_I2Lqa8t9`N{godxN*JKge{WQA+C*XcJQwHilqI
z5LD9xBx{(UlnCV?9YG5VGqQ)#jM({_A}ztk4N_1uNa4#!W(2!{9F^@`s4zU5j)_qv
zUzsff_sCe&MUb9GBkArcaa{!b$sno1TbqSs`WZFf`=jDtsvjxaItuO&TDjD?$5N}W
z%Kq&99zb9+F&6sE!`PI!LVqp9OB&wD$RO2z-pLHO=Co#J2d$ohfX}p7OA{<}HKu`w
zhg;*-&+Ya5&8A<MFQxClMME1>=>>dHUt|f0Wu&A@%PJ(k-R3EjFmd?dr!njde9OB3
z**-6aiSDFU+}zIl8&^8oW`>Y1j8UF>eJB6ntm(k&g*KWBwTpc|L0gMtZ8gtWj85b2
z;u)@IkVU>GD|y`UNM}T1zwhD?LP7#uJc1I+EDJ-JNYwkQWTENdPBQAMl5!){d>&42
zh<|Cz&!PioPu-ao{-G{6eQ<TH(H|rv7>Vfpm-g=yci7|TqvY+*hH-OTju}2eiZO(U
z$bv~G2zJIO6**?+A?LetR?V|f_KSF=Zrcu66FJ%@D4ycH0Ge*XHKXoU;={zQ{rv~q
zqP$|_4~JX{s;LmHpS#hqmphLDS}VLHH}4uHACu%0k>M4I{^!eRL@oZcKsVY+aJaam
z))F&z80!!+(C^6|C*|S?(Dn()B|zFxLo4Z#Ma3c-c!W)KibPr3?gf2qnm|}B{$N;!
z@Q(b#?>!+niYm5y3LL>&<+K{C{Zv#`nw_<JqZ8*Fy-P!9@gioWm|;OSD!ra+d6$?W
zyX9K$oF}_B4sYMS9c6$+#CZAGem)_v7$4AKqa<eC7k0>yK3HvX3Ve)E4brOo>>{&o
z*ybTB{L2c9m$#;gofJxnd7ijCq}_-=Hh-X?=}kgQOAE5-!5lfqz<NgZ{JD{$b;V-f
z?LyXiY_H!{QfF|Lz4;fXu78EedD*84;hm`#--?eP3N3EW?KI}g3S05@_U&iOX#|e(
zNYIGkOzK$@hI=$qm9$^qT5D?ll4o|dW<k&@O}#hJjINEv@J*_h6nzSiTpMAqklEtw
z<%k{MHRM&Ws=lds5|TqB3?k^UA$fI~snm9cF2k)BQ%R_VBd6$S@TgD&mM}6@FI=q4
z#wZ<?x*7<D{0^@sBn_38PU}IPSm;QEE3GA^D1{L_jI3-r9R|Z4K&<<Ktqf}omL<xU
z`bP943TC~IqZ|jUk~T0gS4FwLexj`498knp!wBh78mD&U8WG?cNwc4?_0N94NwV^K
z8#>CBIyz_ndy7+2Q2pM&Z+M_YW1p7(8DJSE;&YPeuLRp(^Zj;vZ8cF_+n-E=Hc{8k
z<4aE;{O|PJ{5(1aVx!-b-2Yi}w$Ri+<0!_gAieg~9OJIaaPYx4j%RJvmJc|(L>Ns$
z>&;9$OfqQuYuuRtp@v3kB1|R18&^mF>n?#`RO9$UOY0MKG$<lJKmT1OPvgDU?qu;)
ziJG|Uzlg2T3ySCr&u_D@o&T0B<zT_q6J^srTD3>z(jKM%wl^I!^z232!6*c|AcxKM
zt4<Q<|Mn-w91C7HC53m!Y#0PORh5pu$PZ@7CKQ>Vt{UuBP!8e5#u{wLQa|OfsZa+a
zF@UH`h66djr{NGh><CO1W#u-brAi~gx!8s;awO5P(hsBVPh~@(#&d;pH19cd2a@PU
z*}adSbCS8m7MaNrW6Gq3g$5QvZclA8N+SQmKx~D7xasAFr}HrzzTYb<AT{2tZAPrA
zO-_l912{%Chp;L<;J09lo8zCqf`GYMxg}-4z>3n*@ox1Rwjv|Z^z6^b>e*8R%hNP6
zt%u~SrSD1*$%;zr0Wa6&yw(uLKS1~F^PJnufemjvVKi}1TZ6$EIL&iKd7`Vc_4U0Y
z7ad+0m-V1Bd*=Nn_SLu?;bV}VzK`?XlzT$`z1IgN(RFcd-xgg-bb#bXy}XE^5F6Y?
z2--WG&LANqa`0Yp!Kr6!rP-YCCokPn2VC{Vs?4Z59mB?y4F@otk+THZg;)4lSSrbQ
ze)y(YNh$sbKjflrj{57c2()2hWh(h2e1BKz&g&pUkmq8A+vdHhEY{G^O!F7Ygjn#K
zD~P_t!?{jqXeg(C(E0UW_23eH3N1ddqT%I)+p`h7JB{TnlRK{z&7e@`G8@%~3*uRj
zrmeZBt~HXNSg(-a*&!y-9FH4+3_GHo(5*gk=Hq1|N?~Q^;N?c7_zN4*xpYL2_?%J#
z>R`~#A5smVyP~G+7Uq9^u{X1SeY&yz-Rb%0xA|XAgn5JIo#_%=y9*`U;JW&pE3lA7
zL{(L{x%e+6yfV$+jGAXwBk0U7`J_65=W*0qs(59F6jPLAT0Cf$lR)^Vb+!f_QBJBt
z=HL5oe4fXz;Kb;ePVGrE(>t?)53iYsUL{k_L(H#UdiO=O_vhL0J~tD4<Fri+Tw7i!
z(P4;7-fq?dCkqgysC7T51s!?6z&#R9KH|B;#noigIF>tDE+%yKL?cc4Xu<V?K@5z+
z7*gIA^y$$>|GWp#Urz~L0rg-3Kt;R%gX58@-p>@=_9!gnKyiu{j$*sZ@mzsa&B~L@
z&#tw^3bY3bWD5HpZGV3}Lk|tH*on%O-ekc*S6&0*SIWvh)jWEdE3NqwBjgWt>mOak
zxF-prFJ1s7p@T|K)2}j2uV>pP1ujTmBQ>OlGrBHDbu<zv`D}M=YLbzkW}v}#_?+~K
zZv!3<HS%(<bn-3qzAoJ#wm)H(0{%NnNkb{PIlisjieg|TtHZ0*l>sxPp@B5^i@Csf
z{a)mC)hfA-gN23T&^a$55jq9%qa6Ck=YYKJFk)b8cT>-s*B5qP$o1p77=U)&KL=hW
z(a#q8Zz?%-VTSO_VO3tc*_gaP36YU|d<a-QZr(I!mYAICa;T$_c>kVbrg$W?!oi-o
z-SbJv{#?2+0#WFHadvf8pY?@RrPhFqoZjuh>&dIsG;}m}GF?4g0eluRp}UW<8#mqE
zNqsL~9Fixq_pTvb@kjU)K^$+V1PRxQPd*s-dq{63*bG%tvSKnN?o3}~%CXZzNfONq
zsvq&PR^5~GTCY3#fk)G;T&{i9s}{_)R)(&7a1yv~r*F_LYUz6Q*yiRV<`uQAFvH;C
z8{b7t??~m(YnHoh$H?~UhpyV%33K`z-?T1m#?wvTZIjF5SSYWf0q@j2TPZi>thAzl
z6N&)te;dd7x~P#7V-8RW1-6c`tPfq0wB=O&4Mz4Y3X@ZS!rL7e8+bpQBaZtb!R*x%
z^+!{oIB{(`$J`@`fL?9lB2EDENOE(qbUgF-pkLQP&V`=pzDGQ^dXr-H==6RAdY!M*
zA3*zUU>W;<y}iqwLIWdY#@xmIj+3(-Dh)35IuKd3nBRbU9jBBQ@X#-=7G_2#?#<=S
z&L8vRx|mlf>KFy+vyq`mpXM6Vh0Atq;$|P>U@DuM&X8|8gWW2wW~i)wozn9l2u%7<
z9Phv7<+*hAEp88Gh}K#xDGr=3UhhLmf7)wrJ_BXvy1OpFu31>dEp9$SrVKzj&KZ!*
zGWnrZ+rM+InjGifUVLjg=`)i>SFd2trfD$CrtpU}*>V8^wTCfG7i%H>$?E<d*JJzN
zUxU9BQBq<PsO!GdIQ-&s>#t~d^|7KnGBUEb_+U-6|A&_TucN4YV-VCqw~zcQE1R@4
zPxwsRZJ*MN@tXmmI#NUZf!VGf?f$0}z8}2leZYm@$n$s`hzhhnimd`4>lt0nrq<5h
z3KPpi2N!dY?Kf{b?k|DsmX+}wY=8C3Dsiw+_>=UP4z!ZanZa-Zzd$w5nH|?&8u6v-
z7a@~-AO%Y%-q5hLuml|#Pc_b0bYQ1pq_44UJp3v4!$au5a@$S=z2og%=%WNL0%}S#
z``GK&;kQ6MvAwF1N&T&q^wp&VV&Q;6V-!K6=7a3)b_oi&?~CmB)icGpyP0POzO}58
zuGlb0b=tlFPD~Dmq}*5US;qx6oZ%}2QtN1nk{4~qN4bUcc{rfEy>os1p-0svev>jA
z8+G5UrIX{k3!2BRxaJTWkFDl2J9DR51wfPBlzY1MG6`Sk)5S#Jn#3!~bnMS$%SI@O
zEO)Svi;GK;IQ$e8BrosN`vJd1=i~ZjZ7f68qt>VZy0$VArb^s<`^LN)mwJ7CMiShI
zfWVoV#iq{M5k=4^Lq(3~H+OzCY>PfNYQ4S*bICL0x?Bz$849w}A^e}*K}3mktG*+J
zQqbNOi&{xpbl_im^fpCBp-)%CPXC+49fn?J6?CyUOqQotV(z<cnou-7DmqxZxYMc`
zaB_(V{B*=QL`>gL`|A9p^Xr~F+{<oYP4oDKzI9<?Wh0u*bclZtokh$?sB&(i(;qnx
z(eFE9WZ>KAo9JihX2EES2SVV-%Uo>RA9?ZP7(<c~8Ekj`Im4~9Ur6<_JGL(g(7?xV
z-p*wS+`Xs(?#wMT$Ba1mdTRcJ8_6as6+LVMBKJX<3J1Vo#z4g5{u{j!6ivPXhI{9O
zQqkAY7@O*Yk*2z=P>R(yT@^nN9XSAEV5eBY!KtJ2ror<kcoG?bqfoG<@B|>Don4rN
zLQadZ^OaSn1g-gEUd+<Xbtqan(hE5n*x8kxRva80G&Bez9!vlsJjb^U3r$BdrqyOG
zL<|0FbXzYH=OOP>!r(Vi?$nrO;9G6)nVKBv-w(Bzz|nIymmSte%9(d48H07OPv}3?
zOO88M2M7U`hqltAyV_t97sKCCiEex~0>26!JwB4QM?sd;(>R8Y$ujic%X{qxG+#UG
z?pE~_6#V_G8EW_S7RFIIYmJ<rSO2I>$0_c0v{>s-0mOh5+_zP?eY=Ww^r+xs+%FA)
z016FP6`#`mC*E?>CVjC_BiTaW4@DmvYYN`$lJ4wTJ7>?HGiO+zH#Q1dV;@j<3nYv!
z`vCa{m_<ZvC1-l4r!0`OH)6!S=m0k>j<>#o^0&-j03}rP<ged(o2x%dL&Y-xBG9ym
zCHx4kGJx)c)XwqEoWKreurQd``hX@LO#d*HcB8?I4zzf@T&b}MHZR-FsPzU@^DqOz
zOM-(e-$q-q?#6@BbGO}_Ru*~8b2suXF^78%C2gso&F@CdYxg5?m*->&w3EkYTODaM
znd7<QtHL}<mGKZ4DT&1=;jSzwa7tJHGgrfj#>gQcz{d7>+YwU+JM!cEOm${7s6c}z
zD_R(%f~9U`x%KI{jhiGo^x<LN)hi#>eb3X0711Os%97eE>PdV8z|Dm)V@s8Sj@z&O
zR5eB@k#}JMZ||_yO@E4^IVDB2?-vM~sXG&9)_hd>NNMv!1SZ~M6~2;|Od};)pf3o-
zJn2RR_|7J+2Dcl@f2r)&wfQ+oMG1!cUnNO+Z)?6^UPHj^t*oq^4wnK}H-}6M{e4r=
zh0)MFquDhmbjsdScP2-_*YrNeJ^2c2E!Li+Bs(HO5RVO*I#TV8j-ZE(X`_W?#t)h}
zAnq;Geth$1Ax#>!qM!66#Y-S%Ml<hq13~re*;`dV@?=E6x1Bl55ETiSm=I);5p?|x
z22zxZ)9ur1f<vs^PM7D-B1FW+@4^Ws*L)>~guE8&th0rjvOvB92Frd<x|r_lj!jM;
zHD(K<R4bNPAM>EQ<aADzLA|2Ay<2D-=B5{i?6pT5N<Ak2l5YwN6p!IsZx?ZOGH9mj
z#<m13Rw91Z_5b}`XyEI$t!lgZXQDh*JTh{n#Z{+RFEY|IQ@L2!Wt-ypa};PS8AQ&s
z?MW^!#8y^V)t+o5OHh-N$|3Gg(Z`Y>4exGcr5a}$y-7(ui!a@X_4McL9qhi#f2@v+
zk14_@bIE_x86%)ct)|v|qPcd{59?PzCn`$WFbLILBWFMatcjzWuP#>18DtcTWTYs6
z3_?ni03GtIlj0}X{y(C3PdG@wgn}pA>}0q-k9$l~n&VxW=a;thTE|6lGcNB=*5yVK
z*DYDF-)qdQ<@or(GFx?M)-XFp3FXuqT88ISbinOJyj0-J`X9f3nFpjrw-4;T{th3{
zJ)YzJoujK%BScU3U~c_b`{BRfGpwt#?UN}Fk%~!z-0Yhy`&@PS-eOv*d$D#|d%LQ}
zR0i*!%Zq)VQ3Oa%r?%6Nk9J_b!vh}x1l8tdQsKWvi0p0{&;iP*Mu@mkpFKhe5v<@0
zbMyYq8NdDgtnqp_O_miq<6BUM9tA~^>-D8o4Mf85C3*<&Y^4xVJLYKO=C4_2^?}jl
z*1e$>xWN!b`6p!LWm$?z+S$)%tU*vTCLm<7oFum0Wb<XI{jl#^;tRp|nRr`t*H1@g
z1+_UU6m7rQRp8J|Z|<qsag0S4*;go7GSEPjs2x-Lms@oW0<P4RZC}YU4noQ{MaBo9
zmz_HxfQe{uS%P!;U8gV1ZE!I_&qlqhvQqWkJB$$0SL$5GDCY6YqTfSj)VZiTvC*l<
zOzZK+nxVM!i~H^(DX&JuYxo8~ZVZ*aV)8?f_uh)!?s_dwV>;^BN{6?fQ192a4Qs=s
z0Kg-?kJ-D`j=pE&vSGow|4DC8kF&{;cExn9T)#@uB+bIEf`Y;ZRzd^pNN>OH+ScY(
zoepS2Up9=AZaYY3+wTQr6czW^Xdyh?+hz0>-YzSbaaPTJBc&?OAX4!ixJ`R7`-A8R
z6|fb26R7lT%?Iqj+VIZjhbWjRjq9`2V_F&*Ij|pZ_IR`zYTWFcp7GWDc=lmN-&`lA
zThn-d@86yx?%O?HSRLd>$M=rf<M1hv?p-|;p!({go!u*#`Biyt@p6D%*nI^1D=%XS
z>qUt9{r3%V+&E{6%SmlQ!Yip@<o0swLGY--d{~%7M8aG`Av4Pp^xr6UE}B&DAIC*2
z;n7`&&^PQC{K!rA?&x`Dg!j>On65kM_!wR>%4^^2<M<FBW<{l6_GixcH(%wcM6b|<
zpc?Q~H=W!%y}WKX4)qf7RQTRj@ZMCbT(6=W2(h5-a{a(>Vs|kCT4A3zXL;71cF8?p
z?+Y$$Y;7!tQ*VE~$xldQD_T6#&Vt_zXH!{|zv=g2M>8$7@_K9-VPTzImHSvPe~Cv$
z`>*B&dbKr*9_pDR^)DCR5ld{yg<+J7C<M)#f#Du~Hg4{C)X$g}+0%8a@?qsS+hZ6_
zpPqu@C}$m5VF(q^Oh$l8^|#2$GZrej2)o_!q5LR~J?E6tR!+g!@HBUc4kNrH@PP~_
z`J2fi@<zCvV<yqr8b~!5t*iX~qj{<aAfl#j`|vyL1_5`0bx;A5lapL|!cLC<Z)Tg^
zC?<J9dw-J-BfM>6k}GRPFN)vFZLx!`I-htDx&{%fQ$61-^*;1ipK}q_8*qK^q~O;}
zU@@~DoO_>Mtjkq3t}0G8!7?rquDq9D!}Bj2>ZXuykuO|L@so;zfl$T3;AEzQ##&6~
zGnPw*fI-#BnU$4zYSqg|TjQh+(JU*^^f^Mia)&=>Kf05;8Y5hO-}Hh8s5ol2Iq@*U
zddS@fG1j%rQpOOpI>y>&<!*?xZC@}Ewy5H&4^r)lIm*J`Q!FDN{r<rxsop)0>76^-
z2zh#XQSKQ2?uric)hqF9e6X0s-y+v7kZ#Fbt@K+{6C8TVMKMwe!eA#AFL%PMc8EzY
zm9y*g;o;+h&k2hLAU#vn5wQ5Gq`os1iVSSiZRszr${wq=2Vj~v#*Jq-z|I^m&qi{6
z^96k_#`5jOe(vQGdvVsm6ia2*v(v}kBN(@k+3RPxxCisKa_>KWbT%{d^^F|+o=C{-
zy-UXY9DU@QGcIx53vzPur*e1<FE7u|{u$CVQ#F0NpaP2LE|L#_pMs_a)2&#tJ^|Q|
zfcaV|V@%uX_lVv5Z?CY!KG;$lDM@#aQj|Vi_xe7>UZDT*%`_|gf_2p_zR2+W;1zb>
z?F?l0$=hOuTt)W#Bh#hi#KfE3gJY|w!pACaU-QeT<~|%GaSz-SGQ2K$#!tF^fqj7<
zf&-OozgP<I34bK<pd^`XZXUZTTx8c3C&G(KO;#8EyhfNQ1);z?-=&<up%&$C3A}T*
zvx_v~BEeBOqCcXirze2BUY%g$9b0x0&JIA$xl&u&hN+FkWr)zjK6`prX;(a;ix~u2
zlP9CRQwF#3r+fR=uE4yYTlSDn8Pg4auY(3B)tVji%T0V0YI_^b<;v5gMoy(4kHUmS
zKR15C^A0%~*LFpxnq5Teg{`<{Vgh7I&A~XAsS~79W`QY%&LeFJzP?3e;R-KQVRa6f
zG~PbbEE|^pHjJAN#r)cJc+Pn8nSiyI&tn2H!mS1Be$Un$WzGz2AISs1{GqTF|4Whx
z&7H~CyB6PdItet!-PoZrcEg@}<0m{prdSDhXDA8aTj;51@CqwpN<q6OWL#oXfFEe_
zy~+HV86Ww^tu=FcmNO;mKtWJ#*CXp^jJns;3bYVw84hxL{HMAqhMp=n^~b!N6>OK!
z{e9vkUP_8>k0hF}bZY(WlfsnNG_69M{NhoWJP025bFU@5JEeJ-p&I1Y7EYrevi|rl
zI!M`pmm`V?_IN7~D2uxaxX%B5nZf*FY8(phYJm7XSTT2HTu?Xr+#FD?|797~-zOI2
zl6(dPn5xX3nAPIC5S#IOg~&2BcVvsPv1xLo`}wp83qeo`8{DDmou5+_E+<?V===b7
zACGr@e6OsWktTp9!?t-wog3;{Xp_4C(5V21H>PjZKyzQDE87!1&2Tz*8@b3?)xSq<
zILuXRecjEB)MUfQeJ0p%4Ti6LJc?fpVyT1jh52a0Vy%Ai-0V!bJm(G^QS*SnB-?E6
zp0EA_%iUhNdYK-IUfj9*M*ngq=B6sJLj%Kolcx4BtY3J`iA82BVN;9-)venynG2UV
zNg}gqxT+V<zij0=NSaFcEf*c7n&vEK0Kg-14wC1O6op(qBwj!gH(Ijx$_wsk>cLqD
z>pWJr{b#u|8R+ONCZ>Iu-DBBLIFUEO4w85B92qGjIDGinkt48RUa=-<5xY*LY-n|c
zmn-o~%k1KnJ|U%`$4GN_n^)D`saYQ4eDHhxm*{@6_N^2N5LAau*JppcfPCND48|NA
ze`;GeH|w!a;`}OQNlRDPQ|&t{(dh7nWHw%vOU>7}rG3bRD#Pi1kzab{Vk0S(PR#S!
zJ}rzLRN!t<s+p?EN`@OLi^^aLjBg|~zY*L+Vc_~i;39}}F5|v$Vhi}udExJDrd7)0
zgs9GIvSx$);kO6)zM8VN>25DEwXEo=5n(bB#r$Cg{@T6CFgHxJ$T~i(15w$3LkF@7
zq~7a_<vq(EchdEcIsrlJ64Wb*0r=MLZ}*&B&IxV(+EW5-COUL+PyEHR8R5pQ8O?Vx
z-04k^M7pLl40N1i*g$umg2yA0QAOdtjtL|CYM5*qnUI-+aUZZ^B9HIH2jSOb%P`U5
z@N8RrzPY=*JLIlvOkg-iQ&U3F$U=g33R>MX|4ANOY~T3SVuPIM<;;w3k)|W9mWNnY
ziR7bgvDxI|f^V;JUUqr{XI#P;aTDKkb;{YRTKzCG!hhl(<J<nG*PJtQ1|w~lN(A&Z
zDJ!d2k#FRQ(7(4Usd+Yzj-9gzf(k}19P|^X`o|TC<a_TN6KzI`P1}rKRwISl^(XOy
zz)p`{Vw)Zvr?nedd)F|DP&iHNcc?rdozh(gVkb_beeE@OM8^<(YG`N2KHz$Ebi|^V
zh`&pMhWRxk<L>rm84^B`k=fQHNjm)uJB%nUf(2`!m=^l6k0(M}nkYh(^^*@$+u8Z^
zhaZ`lneP`9tbClRz%ILqp+a#s^flYQ>fO^_mp%2ggpGc3RvKbdx@B*Vo|}}-*s0d+
zy@p{}y6U9HR~UaNJ;GgmmPCgB0NoHt%HKsr==r%lPgrpPZKl&xtamPKHFBnZw`i6_
zobKmELI0|P1C-ZSw|%iu!^+oC-qF#d_;CM4M|twnp>;GYtX+lmV^wIXas&u1YjH6z
z7&gZ*5>v9fLoe|VaF74=tupo>OQzr9iiN!FUF!!N%&)8{6^pBl&Q60JY(xL_jroY6
z14&j?!`%WN?vL1onq0)OOWWTY{NXB3bDK1hd017n{p7ybtb%caHTqV!q1=q6EZDM)
zM9Qq%>E%5GbA-S-KIHRm^fR8M-`7mPT^*~`^~>};anH$PBQC@Ffn|<1%XERC$-6;q
zMxMT*ZOaSfvV^pu(rZUN`-|+?(1VI1O)h5E{_M|B(6zZd&+>4(t_Hq$eoR9<4K&EG
z%A&4R{P_fvb+`DWx~zQK-ag0l`FTkB%<eQwCDdLIxrWgWEI{I)<UeP`mgOQ*qZbDa
zLgUM4_!@pMyl7KW-t}zA*Bhj|z0%mEY-?!vTC#K&$`O&^1AsTM!&<&R=tp;dAk^Ts
z$;6iU>}&?%V79nkLxbV+X5<^+N|HxVThmtH9h2P;o}evVG3Zu|EO!LtnEq_5^VIP9
zGtgVC)Qru`%bR6E8TEU$Xh)JCIX<=T&`6!=I!(>=?uf+letzP&3|(R{gj@svZ=mIY
zQD%+FYVGmgR?f(Ao+KRChrJgznP^NAM1J!UL{Jvg8(BipgaK@(h!jNQl|Pf_$n^Ad
zj=2BgLa{V9)2p48W=OmLJDAPQRoLnE@%r+@ROj8Lw--B+>>$o~u7rf3>(}~suB#Rx
zq<HLMI1?4q`CngUMXb}?)4&0QNu*KV>D95*CF=CZOCyqGl=f{K^@uEWA{%QwaIq8#
zgEKuqr5p&BhomN#?%Cx{ot*3x`VQ0DpESpRjl4m%!|%x({Uo4>#>U1uXSN#n>hzvR
zl{s-QpD-?-g5_>v4|<f{Awz^Bs-^@|zHr)7SN@hOH5b}-awL9SOfT^k_jqn~{zgI~
z@ZTRLm*p0Ir^Tt&faXZ2!sf5j)aT7{$Joji9yPG=r}#9fA}{SWTbOWIn0r_V1l<p#
zv<-dS2iMlMQYG-5DH`2O{leFckcmOA82$tO7s)hVy&wFl%!2c>@R%b0t{Ne#87eBu
zO-z<~P229TH<FKGo%?+h=12&k)HlTP=$%$wOAFd7^&FqgRHbKhV&}-akxcGjmrDfn
zOPJn+VTD^`+^ZP0hp3o7%Q%6Zi^hI;y;S9c-Q5Lop(KlMq!5NLL(6Q#nudlmS)Mb~
z(`2wtaX<Mq1Fo{_Y7g%#W$KH;)M+`U&`>a#{;IH#NOngupKTBNI#_rAJgn`D2pGeg
zA~u@SP*?ZqHpXjcys}pEH>8=FncDWvmaw=xk9qtNY^xZ~;O+H5k3AMMuvgAeHhnl*
zJd%vc?W0tp64mc*c2oVOC2A0j7k3+14Z9kW2n6(QAX!7wZF3N7M9SnACeAzlorTrd
zXUy1CcWZACR<9(eK*hm1Bg@22lww&M!HAu-VejA|n&j!~N+<Xs#uYh>&zq_H{$~Xz
zg9^0<k*1E0LRwE&7KgC#)#=7dda;0Cvzjz(a~Z*O?`r1q#60)zZxHF}>HTD=r272)
zJQ~JR<zgp9bT?`i*B``ZO18`^>{PEAJOzB{4H(O^&KgZ&YWUnh7Vsg&CZts653T6U
z*|%8t0~-U6cGly5I&TdHSfaQ>^SdyNrR|h&U{?-!k9Cv<5V9eXswwh8Iv@|m@3cgX
z(pQd`8{svOaZ=3n!zxMvRwmzj7J=`T=?h}iOVjDPB(Vo)TPE&&Naqo6R6f6`?9TJS
zXL^wM@%Cz%m_@OqsEGB&3p!D^kA2Y$HIHYUQBFgNT1L6*rE^yY#HPj-D1Jf`TcoIi
zlI8<$^Iio@Wccl#MV9Yz)EX4b?X$my)^P!Rf>U*A6tJ%1QhY1L#0?Sk!ZPCc7k=Sp
zTp6f9nsy+GL0G1+LKoJtphu9Nm-l!B&tnkx;t~)L;NhwEzdHKzN+T&D0pz(i4bKY(
z=j8>P3lYlhSQJdyQ-u|s`z?O>k??rlh_4JX5&3b^O&KzqjjZ)6*PHqnC7M~I@?z4N
zIJbyo=pwtSQ^fW>d5aSXO5a668VZ`%*NLgA#hmYbF#4Qtkfo@ca(8$4+FHv0+Yhnw
zw@WT|kM}25ReDRqj&yMYd&3;D?=!NEc_{}j4&O~Rg27-XW2pZNQlfgWzw?&TBQ3vW
zgeYrp!<qS`DFpl}>k9ta7tGrd=pYTjj4QCsBEcORtuK9DuO6#h5Dv-9OHMx9zL+*A
zeDuB52$cqanVEDz`t?}S0PVn*DP(*5=#Ar`a`^8bbNhcRRbc5OQl$s&Io>L4Br~?<
zo{eo2ECa*KD^T-}Zr7^LT`?)C$0Zktr>7?!$mdsfwy~zBriX`zrsm)IS}XH_Qw7xA
zbAdcOmlKfvnU0AmGqcAQ$gOMqZe|a^Q7q7jyKrjqDaPMMkm<-&qx62rWUa1Wl*?_;
zzpajdXV*hkSgxQPQUBJ97o)A8CwhCs;l8=*nW)jYyFA>Vt2th%S3;3#|GVcDnGF^W
z%Ef8E2s7kBU2sH1l#j3Plc!JZ8{2x7l9~jTN(L%))6-Ei&&~PBDp~RqZvSfFQnQPB
zRP}`(+v2Y%f>iW>kqh-w_a~1TJb{nhp%_C$LuF-3l1ST`f<Bkg;0yB96c0WIr>gO}
zB@H$*J$?PSzBGhrFx7dZ1WP*&WUSroFqNOQ1JntGSQ}dLZHpw?eFBx(-CCNN)qp2V
z+vWE>sG}?*W!KAI2kX86`Ya(H@-4GMui~!nqGHC*c9`$i<63;CJ8~36y4s#>u-xPS
z@7(X9$!Uq1<-Z3fCnr@Df08;)%`zKV9Lk(u+l)IdH94*KL=s?C7i-&DTU&EtHH>{H
z!kqXA>32sy{<B&Ye}cY5bAHBv<%PVQLqMe%NJ!9u@`G^pXkHjo7{*P(rjp-K;ecIZ
zV_x;cgrIOKd_K!NvqO#MoPe}X*7D)@V#^*Kn;1x-o^bi_Xx497y`3|}Ih#zg{BYi!
zjjTNN+8Sn{S()PHX*DEgmps+&{!0<U2z<CX+ZxH_bx~U?=e<vJ+i~M3o}X*9-Ki{%
z;E~aL9dPm+Yb1jkBjjHtOMB8v<x4rUVC#nX_tSiw*^w&7SBC28(j$0&Z|xN&MHd^b
zI>s#L9nETg!O-SR(xPH7DVmpC9Gxy&kA*(|eBx&YQm$q=Iq=ALh|xV%mP6L89<<6o
zx%x_$=!fJ_RT2T_mrI0<p#l|C*^g7dZiQ&}_Nuu{t0`cDzv^wE&v5HtxR==twQo;5
z)^9^=l1<9rgpB;qyb9Hj*dO$AoL>_{)V5mF9b;r1-XPoS$6nLeJ3J9|xUZO|g}%-K
zY$Y_PLaLucG5TcL*j0h6-kgAz{^b8K(e*7YDsb?LSssz#8hnha`(>iLTX+(tC*pDa
zQ<*jBU+k+W0vfNYqm{mR3YWzO96<8^q&FfW0<j=!g`wE|GWZ?sK$-4VkmOluo}c~U
zB5#p)S#$Fh!)_^ku2}1v1tH?(#NQ&qyiftktKF$+>vI%1L1;w<K6kI3pRY1dWy|AY
zat+XlT#t04;p_$@C0*}*n07Tgrfmha^{=>%A^zLDRDPZPy<?qiC5o(GH{0!FP$}_v
zfgQ7;-N?r~c->V7&ug=H>S_{od#iaJr`tVq6r<jJtQ9lqS}XpwTr5N>TjX1P-p7hp
zI~K@{0(_&yD7XPCdIZCLlHfjIIAt5vTrzvy@UWzm+x5;fG&+0xavXGQ^dw})Tj2bN
zT#iUSZ|56cCJ)2S#o&oWFTvORqI31+pJw#V^blG}5iX{DYnf9Nf&qNKXPcFkTvl&g
zU28Sj5@KQiAPPn4c43|Er;}$PXc$Hl8b>uPkK(1~J$Oz8vy{U%bdY|(nTN9t!`qPu
z!!K~|xU*DKo*BpalOb^l#gUIZ+l7j=L%o^rd}~vP@SIqwrMmbW+@z&LX5!Ay&X}<z
z3qDD#eCntjH1#N!Z9aumzz)Tu7!T;4R|S0cx_V&h2(g_pjV_6+I7WJ}_EFV9==WZV
zdFAhPC*_rb#A|B52aB5Xt$$a^rxO=+AYZSCzj~_-h`6n9XVA5qo7sxfFFBeG%vsvF
zRwP!en~c2b5~~U4ROz0b9zByN`;zzFO1GV%Yk}e0`RKo+P`ga$Ls*mhZF~()X5(T>
zVk6jE@0lJ0@K#adT@K@Wmun5YEY$q9E;;}yU1eQdYU-o8%0Zia#1}^gPRrj2+4KfR
zVDU}QlE`Mj4U({uu%cKD)S+4^Z;KtZCTgTJqH8ab8)}2S?-Ou&zx5c@naFoUjTxgr
zQl|QR<_#H8&=zIZsdbHv-e+6<a37AU)`gt)oOji((79j%DQ}Af$0DMl&_h&TzE%gM
zQP)tJRm@Y&{otEW%m9Q=+)PhTlF2s*wU_eT-cwX<iid|syR4zDtu6igQv5)=uC8UO
zgY$nrS;F~Qf2aS|C&Tb$*;Kdd!PgpN_Z!Jl;2^*4jH*@DxAeh`TWh1=>roI5&gI|F
zb`g@?p67iM8*l8_pZ9nVNnZ`R8w){uK$B+m67}3WFAom<kAoo}?r>CocVwC)*B+6l
z$yZV$pV#208((yEbfg|O5s`Ri{)og#X055xYjXQ^+3Fu`ajZiH#*sl?T@ii6uj?G<
zddsjJ1gWhAyC~AL-J87Ye|#AIsT2?pP+n1?oHk8^AN`Es9C4boL+hM_(h7IL64hpq
zE|<ryTC4svRzriY3}lp`k0*Z*au5$28+7KG3n(ENm5D>;UT)r-aim`!Ea<S2p#!~q
zC>y3u?1w_3K_H&_tIHAIz~Br@5jn4e@Qu~hNL3&tO-eGzX0e>i%Y$NY>1<{)CN{Z-
zX4&Czj7RtDcH*ytNV`|^b;=b1>Qy-ccaQ{4f3LY)cpIp7^3yo2>Fugk?c;Dfc`VuM
zFa+`#T4`7B{h9W7YRd}vefTck^aUBVJSNjq09<-?EDAb`&D3rRvNOVB|F;r`Q3eX>
z3iaSQrpGU`?$~_1-M{}43!UT59Q$+Y{`u+F;oc^rIT~6Q0Icb_Q!R^8YY+<vSBdNH
zI(;Y$HS5Cw2ZPCOb}nw;ILvlDTrQ!ilb7SjIbp$%54m@|Xx)%mB$_mrpEVJ%d>gog
ze4P{0_L{r3xnNHD&RECzdSD`VSHJc1ldo#IA`M|g{&#JWZLz?Q;D~?=a2?Jqb^f%e
z=lV&txf{FIV1&U`6^+!<FngOZqE`cck8v~})Rugy*FQm5TH}_VugT|ZpW|;c^$;r@
zwBpC7^fDiho?+D#=8g|wzEhR5Y5&|hw=7OoN~70Qo8f4X)=%QZ1N*$;HymMQU9#e<
z`R#mAEmZfgBpI(wYe<TU92<~p$Ev#iURG89`Sjd*{#&GVR#a6p%T|fC+(Kp7SQPa?
z_S)J`$42*Fkdt0qVdJZDc5@%AtcnmIWL$f)->Y(!fo#Q3(9t;iMzHBWoDp&rG<V<w
z#@s*yuAl*oF%m8fMCEfzZY3PS#vG$weS05_F?Z+LSFf9ozP6x<*zz*E_%#5?U;{t&
z-`i{i^KQd10Wcg`yIgTgRCM20S8?CqM~jeVMDei!W0%fGlw6oC>|)<&lws}e=2lQp
zfEm{0cazTe=AzkZKs|x_O%7wsd4di~Rt6Y}uoJLgv%i`<G&j%oT_8LrC$~v-OQovc
zv(nN?XqMVLDq9>fu>nd!#`R<=B&E350j$&i=`&>@1o?nv{qbW0owyeiyn^u*-|ZLX
zs?&`#iqRj!I`7I#!9m9l-teyLo|3U_NyCSQqm}kN-%tJjnqfYHNC##n(W~N2m_fs5
zM8Avo!8|wzw0@G>>%!ybuyXsz<>P7grQ)xxCrYp@okG#Do`N1TEv<}IKR=(B&*&$I
zy*iAw|H0w<Iy&5BxG3VJ^NcR$VDimRE2WBsHbr^m;>i_%uVgy$*_E*e#jeSzk@|*?
z4r@+s9v*sB3;=wKE<+h-c6RouaoPL5jSU?$GgzxTTnc$zSgY#M>~5KNV^MSFR{$Al
zm&*0?xc|yRakMw$RyYvQc6p!Z(&i%oS}rjFly5KYLF_m{z0{-Y%w0uhK-&aIMW;nP
z?+X3-JF~t&f7DwwsvEu|c<(fh4*Bk9V;O+8XMJehmueaZ$fL3|hhs{AM6%Qo3h{R4
zY8ZgcBD$0d+LfVwn2#jd$>>4EqvPV1dR{rP{`j|xZ(HAucE?7@J35r$e!})bs-Wu?
zy(p`VfJlA~DIO1;Cn3he6`|{<V}w(??|1_shtm-Y?g=>S(D6hH65!Y4bYy}Rm0Z7S
z!$MlJ#@^}g8&el3gCh*#-brHS`}*3*_b_=i;L^S(6*%ebXW$s-tbCqxwGH~gIp;Ly
z^YN%>2p4BSj$pvw_ItTNql~9Y!H!nIt_T!S{x;F1<ZiEftCV7#(2Kkzrxo`HW=JW0
zJo0Qr>Xq6aDG^cko-U2|Ht1&We#r7H3B1y>jfix)d=XI%d{*P%X%y~>_ZZdBs|l>v
zVaOk)04@U{@K5V%it13`ODfy)x(sfWxvzp;v15Pwh2(n^{RyF_q7TLfS6X_FoGrd`
zN9?biU!tM85gIC_zZ{%uUl+Q-#&($Z%P^#xL-E1HH($xc4;^1?RJ=`3*T=PX*0rP2
z;n9JiJN+vPqBm7Ee4ad!ZhV22?d0$}Z(DC{J7@dyK-?ykzi&k6<xh6&NHA#RGwo+u
zD55B$tnBAUN(#BMsLI(hdv0@`k-6Eh>AAKE*>G`O1(LY!9`PrMG;jW%ak@m#Rk+i?
zQGYz!&lARb7s;$*`|IL&y$a|AJ+ymi=?<lYyf1sNUFLCnzT2N|jP^nLF=%Y;Z%HTy
z7Oj{^1nbb3S5s)+Q&UrYeNO-%uy^_pE-tQ|oSackYp0JYjYn@Z0m?_$fc=kda>czt
z7t>SX-bV-1?3Ep|TN_o^EDwK3lcgG+mNZZVUqfX<%Jb|`LV^@H;Osj?@IAkzBodC{
zUn+6=ljX&?)6s+rn%S|O(}TU4#~`n5ci`mS9r_5DG6!8PBN!g{3q|YA0U*l)a(&!Z
zBjgCW9{KIM(a#`qf`}nz$?Uos7mue9ufq*PaW-t(ZbXMNTL(i;^?3%T^J?eD(RPM;
zN?yjLu}NN+Bn&15$H&1<d;0<_2qwkG#KbCczL(C4+uD)tkQ@^;I5L8Viz|R-Rd{yh
z2K==>SlRd4`Ezrf`at?%3asT#VYQ6T>SnIo9L`mOS)x?;|KR|#=&~<Z0m@m8Z;yr<
zX**^zyYW_zAlc4?*ie9vXYx*qU_kq6w&)$9&*mQ9<GqugJaq03>l}&M?YG=AP&Ck~
zfDZg6hnKM5=-bSR<G~HbLND6CeBw#iXB+7#eDHn9@{Na+7M0Bg=ZaG-l_t*^l<WSR
zH{^{{QO<$~iv{iOWk_gror?jRTU(y{UdJnI?U%W<XV+iNx=P})9k-LCksVdc0iIli
zIJW)ik$>oAfWLhM*5Z8#u6HS$Q|{m<Q5$EN6GS~<f}8{(B3e@+0n-<>?A8QcjvXJ}
zn}2*CHhMww4jU!);Ur-bc#)%bpUj`sM^_?Ry*gti?UJjPKHV#ax<oFnZS3O$y#?ZE
z(!VPB_&^5V&6lg9c>&eHPaK3PZph2uiN>G0E`^BD#nT%dhxTv!2;Nz~p4k2;BwX#w
z@^~?_y<Y&Ud3I!X@dU33I6CY=|6s`I<g62HTs8Muji6%HKu#1kE`(?(CmX}@c=M)}
zu2eE_nO({H8X7ER+`(wHx$eyyT<jS<*f`VVb>`Y(PXKRlgm!r<kferb93!`1el8V>
zLd6Xm5rP%yVvUQ3Dc(wN3H{<;?}$cOHuzam+Xbe-YSM3pKiN!fPo@{Szl(gQZ{}~&
zR^iYIE1uegT>BXZX_ZAs-{~YL#qJWXUnhNHO^soX6AipQ*EbK;)zbRynp0DA+`Jk@
zLrm<7*jC%nd0hoRdg*^&tCUPD$^2y~0sd!ubyZNI3h6QSj(7BEq2AZ#^3&zNT9YH)
ze7&o~C2xc<O`gBk>}=Jl1Y&d)Wm^%Ek?H#H6M{EW^O^#sK1<8K9qx)HO+))I`DgPO
z^60$Q9r1AIEhXj|7yg28+CG|q?lyVrc+AiFx!O$F`#+Pn`Et=6h@%3O5q+e>7>kj7
z2pF@;s}^<JJo%g7`>cqTQq*!Y?Zt5i;?lBqKHtHgIZaUWX&TuH==i03MOj&DYs+HJ
zmx5hX90lugS2|)(j@{i_-`+95-Xoc~InUcwXm+XP;&lIlHs9W@NP@1-rYi1A;=>~-
zB2uk!oZ$p|&A^a1I5-$j!K)}QkE*T{78c%U{bXS9O|h`{@k7`1k4GQc4wx|e$vupE
zOyyeqLl@neMqUL|-6kSOXWG}b&*pmXB+Z;QjItb7JY`5iwtcci2e5|f-a<R`D#UJv
zT0^Ft2k@M+|6ByM{25eTI$tK>*7e(mJR0Evx>4n(tH*vHdsx6`&VFTr)rI)LKk;Gp
zx5eJadS3W$7(i0>c-Pm*<uJR9);FpLtW0Rqszf?ZBZ4md-#`(VX!<p))B;ER2oQ%6
z{hoE)sr8dNp*$<I9EbrAtFsC8j%5RXI<blBG@$UV_2*GSHt@mM4ExvCKEp6g4g;#h
zm|j7-=)=QNla?t+u~U>D_?b1CJRX+WtYK%@8sF{V)B~~@>W&YW1%Y!cSoY#W(NoYv
zF!9NzY1}9&rcQewzN!~al^+RJR*q#9NiY9m6(V)wadzKOyof_zgFe>ne$@TLsqyRu
z&4HY=ndBnJn-f|h^fgg6-Qw(0Z<eL6w)1{M&8gNGrYkE4f?vZA9XU1j-?sYR5MlC{
zM@s?noUFS+^iTS9iJzagSOouCXu3q83`fu1sHxN!%#mJR-z57-{}(MD?Z7YEu}KmP
zU)r7aH~8k<KO98cGOSU>GV5_O#RS<eN|fX^u~rFIk2<|JX7}GAA9jcP1oSC3^o>jp
zY2NA8cKpz>{W}6xJJoC0tj#^rN)@Hx`NDd$o$Z3$V0irO?ftkO%}{OH{v1_%4TO_E
zZDNE*8DywXOH7W99iFVSeEr>BSIIvaFVFm4RdMRPG_NXf`};0S)T<^&#LNEn&aE@I
z^m3QH7PV~QalfET@6|xWK|S<%zLrH$P`+4O?YjsXP@)e0I2_NK=i|r$s0J5M@fx3=
ze8vjVHxI%Aq&d(5LPA2o$9-KE_(63!1(kd}sBerWWS|%LI2ei{l}syYzdPBy>U-xD
zYxSEFV70VUQ)`TF$Ljqn;U`~8FYyuKNlQDBd;M@_Ar~!$oY#p|coI!WNBhRICA=c#
zZ4rN`AIf~heS63njnaKD-%rM96>n_?=St}t8GY(_$(=cZb-oWj-p{_g8`|7d+1j!;
zw5fl3>2j0jh>MN=A2Q+LVE_ya48p?A2sm{A!VidviQxnD5K{83ovil~xR?vX(_IdV
z^NvoeJd8E=4oU_4LEl(@#A3J#DrE4ry6h<Dl=AcP$MuPOv)rb)&p!`gHhGKQ&Co81
zVcT}<w5>XmbLzf(@7X{IX*Gvy9@&R7)#1gMkSA2j?+{}H?=OzgT|+b%Us!0G^!yO9
z(nCqFeMKr?WMyUF8<jMb=$Qu@?oD+zoy$5UnsEs0a`WDG=$9TL=`V0Ur4QCqCsncb
z$#lDWKZ>y-c2$YwZ>k)e>BQf0KYQd=&s6D9^(K7(H;qU**F+hRUf+^JQwE6M{o&%Z
za2Qdc$kVpY@RiZt?3pkMEt<%4eQo|L5R(x1*zIF*T>ihXKkXDJTu?nyS<wppw8_ul
ziZPM8LWgBO3MOKr=cfay7$9S{6ngJ!>o=pX_&OYhk>QI=rPiSjXd&gpWd2#sYAxTt
zJcrqE6>@TE!|1`F+`<ac?WDgiNJ4l!eKdEd8C~5uxoWixv$^f+S-s+H8e7H^@w)TG
zTTbQwZ+@f;ZLh{Pcvw2bR@*$7f5J}+-r30>^T5D7Le1=eprgb{rK8^JC%J`XGohu{
zRFKpA;dd{!F|W8FUK}lO>^37qQ&i;>UgId_|28P}pA8DZ8|*cbf0sOG#O&dSBR$3J
zJ0%<0GgO4~8zs&BY!HNge$%}pY6N}#G|9%-f(0t>%L&TtI$a)dK`u?1+CS?D7~MTj
z&(6xrCwK!lL~YAxgwN1W<sd#jJ{_n1H2r^^SK6p_w3CsSJJTxM<ICD=o?G3>Qx%m$
z#91}!2JMZFFK&!m=etuRvGP2bC|lh~7RL^w1dCL*iV6olEGXr()oAuzBrdh=?i)g(
zu$G(s1t@f(*4_WJ=4U&@*1Vcz3<o==EDQbM+XZ-Dl|;bx$=dI59qk}`QMdE7E12PA
z&Ifz|8Pv5KT=GgvK&G(l^5XRHFF)UYjeDS_)t>n}T*JoN^B7j|FgKX}<n8wg<JR&p
z3xoV#4P7+pNF(y+&r381gVh%ZfnYG|zNtl>psten;KSSWUZrPhD7~#xmYf*YH#6h;
z2)#3&lB}(*wX?H}jg9T!AIK2)GKB<nc65M*g!E8}EU92ge*W58)dCDt8{{`SdW4(#
zH}H`p;;z9I_&a8NrnlGnYdt=izsB^1U%;>3rPvKDUK7MWsorqAxo^F4d592(EH3a^
zPOw;|!R=yYeo9a%!L#pye0A@X0LnKuh`;I>g?;6Z9PhkJ$rR+3Z{N68DKU{==7Nq9
zYFOdxaAxeJJTVO|@A}bJ2y*WW--3Nmg}i5?Pw$+e*(l*ta8buo)!YRJ;OwlLvWD+_
zVC~Ib0@Xtz#G)-CnpSe<>Q9!2s8)C5Ujud%)E^l9IG(o&x<0OEqd>mR<llZGewEvC
zgQ&q6Ts*~t+0T}odohuI8h<#*p5{BsbnEfHE@GEx>+x=X+wec?-ZH3;sB0H&oZ!J7
z5+H=&1a}QC3Bldn-5~^b4-O$5<lyd>;2zxF-5sX$e&4N`sk(orZq=Q-{5j_|yI1eM
zdhgZU&-1L+5?)u7E=N4uL6UEQjujnTLDP{KE7!~TFFU`jA9>U%)Exg@Tuj?4q8dDx
zBB+&mcN{SPXuDTlIy$7)!yS*;#nHQrd!?enM8dgznS)WmKiSl)nD#^}JzEA|ziKqF
z`MRqcT}l#@6OTt*$S9eX&(A2pY3i2!ye|s%cqe#ud$aO5f416wBIPN_c`)8nN9P|k
zUH!GF`m;|uIs!oJyX^M#H;6d=;jY>4*Dw8PK3SW(>S2Bo=;W`x1mDMP@m{@W9|BlU
zc@LVLXBTI!r%u-e&LK$^32t?cbRS`rc7YXg@A9uxh`_2dgYqC7V)S^mGkWigsuFMV
zS}nYoLu7yvUGxqpywDi0-eIn0nBe2Z25Oq-?b=o@9zQCZlrgpDQTg$ux_~(5_HvJj
z>%lddo10tKPGDdlNHAM@!-7DYBk9iZvG0bd$Y52ibY9W4dGV9?CeSf<Z!tl>!OisX
zqw?E0cTZ1j__GN`J}0O0q4WpC>MEKtz1Gb>Z%_q_CYvGX<au4fv+`1L)lHx~-{#|`
zuP>PzF}v{4#ve4qa#*Y=boW^OLMrI!Zr`;Uh=dtQoK$1Hw;;RXQ?JoEyF1&TkSF=h
z!`<DUzaZ8NWZ^~+K|S^NkcWpm2U0B!l_Z}t!;}%7o@g>Xb>{@6!m?sPhqsJ(ah1cG
zgIrqmOfS7c^z<s(zR&%KX4y~o;8psr6U@|cOg4$Uu`SnlxN9NMdmIgB7Sg>t`Kg7V
z_h@$X=pnxng9y-0_#S~8g{c*x>4U3mzh@71_1Vik$V!EVhQ>CuTToC?!0URk&PL1E
zw{3VQCT_gv#rt|T<4*Ul>EkKLekS;?-&on%ntCYoeyL?B-7$xgopD?YYFJ3J&DUn^
z{K7AJ!7zLVFbkZIeDjE~-mYFt&omp+@o>2|`Vw}U@Zw!CGx4QpcUUcZisT1~UQCs{
z)u-6B4&JAi&tS-tniROd=(hHBcL$khfVZV_RFco2GyqI_+_?kqK0uuG;>&h^CW&h@
zUP>c7H`)hpJZ9$92{U_Z`UT0d)4RO_vYuFLZx|;qlE}%Gr|6|^xW9{D&OX{W(oxkV
zpW!+_C~r^uxD#|m^89cvd(n1(KL`@mkGe|LiF&?w##d>-Lom^a6YVLtcE<DKmvzpk
zy=0SXC<)<&%a50oW5|8i&-QqAj+WN>;O@~Q_ooF;ESJMB(LjbXnv9qKVdw%BV%DE5
z|2?<@r_joCD^)OuS51HcVb%`F+_f!4fZve9IlZs%b}sbN?H*A;LH%}snR*jKIZ$of
z5^xIgs7v*BD<Dt@(s`gZqDZ;m(zErStPf=#q$)ua%4t*}q;oc!r@Za>@Ga$Kj*)v=
z;%ipYJR=0p<gse~Rbj~sjwD2Z-;SQ&@_3@xc<}uJK09)Lx3yyE*Dp%WW;1PH<HU(^
zCaxT_9J}|UV&oMZlVnD88s@9ki6~&NFE8a}WUwQ;QG$N9v}Axvzzu5b{<3mc5UX+~
zUHQy_|A6$+?9qUyOaF_G7(lVzesSwgNyjL)GkGXf*-{j|g9ix3sv;sH+S~nHuY+V$
z9K9|>9a$1g`I)y4Hk370m%-tI*}RS;83faQcPnODX*_<N(3kqdC)MdcklERWnwpw7
zV!_8N?QWO5tS3w!2T%F3TKJJsL27-ibtj8i{DP?)+*`v?N9Gg3%2uRnijFGM-z*#)
zDm(<E%}ot5`Ai_v5qdoLvBId@uAzVk(cg?PEq9N3+HN&qC%}v_*uXs4#63FC!t^SQ
zqvN7yc5z+JI33Id5x7}&0@>8T!NG{AsH6E>=-JT^!%Fwx!RWy0qSGi5GYi#sr3h*9
zco{_X=&`CCGk1aB&kO}dg=rrce^+M&tg2_3c|^l~1KwCXzzaj6Q!{^SkgqB3mz2xg
z_s3ZSk^Ve7e0b<xk_5Nu2%~7EF)^y$-LZQOx%Bhd`PN_cR#lyY;7c5}bYsfSsX?HJ
z|IeRVbaZrE`CBt1dV|kTkDD6GrY)>+fTO||!w+r>prxg?ctGo_;BjcO_&f}!7fc-f
zK*#htq8ofrTv}RsMqMi5CXVsQQiD!`jLR1fI?lQq0x+#*pT4~Gd2@w%C@b$v(WWEM
zIQ|JWo1sQBWDkcnTIl8R(C6VMno!VjT+5EZcOxo(-B3tKFHTCF_j;R|zSYQ(d1uRJ
z?)>O>^VKp+HYoJ```0iW0t)hw;YGg`#(IINHROEHTIy0#a^<?i1B<s}k-0?R3P`>?
zeNjaTdJB;6E2IzwZ+kp%B)wpV{n>U7Hc(H-LxwN4XsxKI2tp+w*6RXg7j#BHQ&MI?
zcJK6r@6Gpl@$y++x8%s8lH#}Su>Ly%Mjp$u$M0gpBk03lQ3Bkn{yQFV>g>Kl@ad_2
z+B%|Qyo+?7Ll6=8UnXy3a{z#lpYk1b-%C0LCjJr~D$1FK2n!<cjWR3UV#Bomwm}fE
zcUCUeRimdwz{$>Z-z^Z6bj$Z`dZ<=d;-hEQQA>i(S0oY6SLk;>f*eLNZVFhA<gYCA
z2VBQwm&=yHad&Oyyw|eSK?p&aUA&osP7uF#U*<OUoh<@ACb~u(A|egtJl5rROYhW^
z>B|cVg>1pd?Zaj|L<Q#1bD!j=B+Vr0G`rH37oJ{RS!wWd5~7juIj<6e1aYQgkXuS<
z=xPpDV@g-fjFrp$`FXf<!Hre1Rg<KIE84D-w)R_>xF)H5(3f#TJkb+-&bnDy1k5_8
zr}phWH~6Ee%UAg=4uQF;An*@P^d$zR^NhU+5-vMXggi4n-PF)fQ}W65OA$LO>-dPg
z7V?`(VzyN4ePxW+FI{afUN`wI(7QOD-wZfn-(ZtlIhqYTN!I=0{8vL)pR}&cvilMJ
zb3!|;QZ%{wmv=R}70RI+75dLh&Ht_@Z{Orja6T234UtCml9M0vkGdU9t3an{qR3TL
zRIWOOmJ2L+*?$?)E1nQzM@R&a@qNMNxXC9dE-qeH=hlNxUGGh#@9;D(LQM|XvYeE0
zx7OCi%k8{1H0HWd2^2E8bGZnSDZhil#Mcj=ULg`LDKenKCyNpph7K$Km(qJ@YIR3a
zHRy~R3hKjJ?+FxYb;}F1q!g&lgofrx`jr+Jvq4VzPx;GF<8O}1pfe<=xcF}_Pt6&2
zm)pU+-<}!aFdD<OpLF4{z!zt|Wpop?eqTYyVAfr<;pVq<kq5o-BC*sK{Ftr|acM7J
zLSXS7e%7n2D;Pj6f_6$Xm|7YHQ;NP?+H>?>A}V6WjKyN58E_|a*kZ$g6%T$%y~hm`
zH>_0ukR(No-Mb?B0Sj6C*WVEXgU)~e{#o}km+a-rX&3mehM#p$9D$&O5M|H_P%15R
zy|Q;nXoeF`Y6@?~1nVSlM}yQVqk2W{N&B<c>whX{rFRLn9wXG!P0iq6{alWKC~|IH
z*Es`VoHZop$v{`3Oeyi1U_@8{uFfOORLcS?<PiXtpb`j0rX-9u<-Ql9Zv*Qb^+{6+
z>0W;J&`4#C^G7oIe!j*l^iMfhapru%pqx_4@AWi)MHl!^%U1&1Sn|bGXx=lM``(vn
zQ=5Z>V`n7G^}lqFo;OD;Y0!X1Kb^b7C+4sDoa8p~4}B}@tU|?#TxM#ofelts&?;re
z!GGy04fw%>e9usHzn6nl5BmS>*CBG&j#f4**z9}Bu8SqW?Y=t`A79n8eRgw0_R{yh
zV<!`Amiu6KQ7<&?c`Plt-FaaIYBhJ;W?Q`q&KB#XkuaaaZ=C+=H*bP64fcbb4FCHm
zeN`oAnCHCB)S&IL7vyi0@ZYvG&rlw2PEHODslfIxfu_T0Q!L{Wkiw~XcMn>y&=k1!
z=#K=1<z*%uOS1Sicw|?7qF|CNnvJ`ELvdc=;HRyV`5#@V_86YUZp$77HR&oNOy6+8
zdrRJCWN^ev9cPxHslGe=7UH?UB{(q1A^n&2o55{6KSz6o|0qqzp0FqA|HjQ#F>kK9
zb5tQUBZ(r{Vzy+1I!Y`@!T%Pc{@?$JspA%UC+3gl;41OYC+(FW4WFQw#d5dxYNQPL
zpQpK|5jUm+>`C^~t()NJkm|<fRK#q6Ug&GlLZ6z>i(aAf6|1|-iH?9upXTGIQNIkG
z+Us6TxrEZb@6HUB@+ga{bB=(w*4IbDDcsy?bDtaA=_YFot*R>_?3+7V?Tf6wrFy(t
zm5~=dB=p{mO1@Y}0DqPZK<N_({<>ppBlkq~1_6eYaE5$t81O7QpKaF}=J2E%_udbw
z!c8td1f#*|2ejH$>T>vx<k}sW!u~}PhSdjD(S@gI5T_Zfc*-kz>q(sNO<C*%{jtEB
zZ;0_tpTfUVV%1XOgss+4g_X{j&Q*D)of{%#0VSc#Z}P_$mjd(E(@x$efhtzsCMlWu
z76@{!HniETS}8F^y~N^&t`-RZt9<zukSY_UF0$!--6OIsP+57t*q+9TQ&8}jzkdEO
ziE%WPduHjNZ}`=)TnUrWsIZ^jt=-}A#z8SUNlO2OKo96hY{Y^2_pR?q2Z#3RRU$Hs
z{&|TY!|&&o#+*t9o#sgNJrd&mVn@6$h*$)w^krF}zi>qZ71YuS8GN7BY;Lc1A`3sW
zW^Un%A!^f`mXR&OeGPlEJE+2ZMJmYo0c$bHlC00kE-uJIQrIn!I`wSA5RE)nvTXsb
zsVVjlL_+7JyY{~YE}+aNhZxN|Tu6#s(E;x{+)3NWoi{18R_{Mx{qQ>@^fT0YDy~&n
zbhzjxT3d4wLhVBglV@0#`Z-lp;DA`gq~(=%OwKUuO1k3qbq6ao&7d#iOH6tQM#RYz
zMz!*fCKN~5l{cg4k&rKK^VgeDxEtTv`sXV5zmXZex;J%)$=eo#KEvC-W^Q_b?U)e`
z+l`%#`#qn{8GFE5vO^l;+7!y&mYy%(^m5_DvcfhakNM<L82aFb6l2b_n!Xi5-9V$k
zJ5{3jGK|5-$jmHz@0+%s2m=-UbS-q^Ipd?!y$ho+%Xj@nt^7Z#P`zB2RjXNbmYU^!
z*t8w(f^(W)*@WF6LRv*Gbm9D~)34|ICxlEVCv$V{4>nT+=Pcp+XjqKD4&|JQxsj9o
z9FaBB;6(O6i;X0jXxyH$X`Hfd7t!gtCO+WxHouO`yl&@6cArd0_{m>`5K^zhFy`_K
zOEK+oXv+Ugvh5+uWD233oc#XJ;rVByk>|(E$|a;|A`&KJg=fzO4iJY#gyCO#u?U0r
z=3gD&94RNgbvUP{aeFcYfMf{5689;Aa9HRd+!r)}RIJjN0Vxai{c8s`e_W!EYlPq4
zY{0m`@zSN-ln-MVM!v^UqFXOdGvx1Ob4I4cc&!v9`uPoVUyrKzS)kOrbi8YP96#9J
zF>y8WmOqPoA~xdzQZGL=l%FDEywlwx9FsZ<+X4nY3;L1Lu_woJ_HhTK_(O4}YkIJW
z(a6NV@v##C9TD&}uyIPO<9kK!qk3)2aDbn0lI=iB9-Zb$;8*JRkj7|iX$vh}{M_xz
ziB_vCGVNawTZ=4CLSE#sFTt3JQsImRFzQXJU9Y_1wHy1o_4yaM775-D)E8vmNQ>nt
z{d)asKa(#QI4tKYY?8@QjPyHAENXvhAP0ztwcS%pA770{NLWs!)|BeR=b@wRjDAam
zk5VsWBWI8F`sw09JeL<FPWKxLj*vQ@EkeJa2+bE;ng-CaLUxYB)l%*KU>2AgD5WIs
z6wm_!fI(A>8eV|xt&v3ig*7LnH2F2jzxJ&DIc4r9E)!(b@hE|vqlO7QA``!FDt(Oj
z0mqLczmh6u-p_hfe$w@x-p;@kHqeoxH$IW)V&^aZ)Q9`%y}3R|+#u39M|^uXqy4I*
z@cHw$$9G`Ay1<Xwto*b6rW_3L#}&hVb77?N=_mi{^j&0j`Ci%QQ`t8v_JVm(G~V88
z1ph<q;@ihgkz6*9ls5q72^%$&)EDn(eb-l0_tX5+o#Vu}dz{oh9(mqJ4|c5=;jBwW
zr{R7Xj}9|;TxuEfN34dmtmAeAGxUn(D=yE&ei@65M30zG?{Z^&>y9tuqjqLO_&rXD
zy@k)u<qJ|uxNEiMx1=YMQ3>z9Xb#-$ta#HgN?@^-jpK!_9XJW~v{xTLT-d<^<6HfB
z1+I3yt$(a8n@h`?0W|4Q`dfjc6p~2}lq##$f|`YtXk(IgLmkokk<`0cD>3k+e}I<+
zr=X2@xOJw1&M8FE(<Z*8*B$tA|CJpOA3a0@p7hd9GosE8Sr3DVl(#Y5PM-TFgC^#G
z6(Vz_WF8CnoVD6oq`fm(hfeUKrJjOD_vPV~jKN}E)#P3_Qs9UA-<5{1zkLiYYjkbD
zxbN2n2y6rr<3nOiqF&COFUy1mn!M6SAl7DW_Gz+zLcu=7Wbnb^3Pgr+x=B0KhvjW6
zc<$G}31b%QMtDbz6Xo?&#lxCGS8bS9SC;Uli#pkfBPDrDyQiH+SFQ>;owR~0-8W3S
zm{cohbf(}kI6jpwmv=l8TyC8a2PaesZ%1XTQ67^{qd_$*NnIqA5W<wv6MzPA$I5Hp
zCOV`c%z>lR*4ejVE5JIH-@{%<1qe`%)0C^2-bbO52x%&CJ(^F9lhL~QHNGUPcA&O+
zh)C*UdCQ()0x;yFgK|upDMUiWHHg3|);Fq^>pdbAKqJL2Rn6`AoDm4!1JhO9-?su^
zQ+gx!X->n5J{A)cG8JSnm{*adEmT2Wv)v8dzdLwdAf5Z)^!o5QhrbllY0ad%Zop;7
z<Zn~^@wq$pwf8=q1}wI$#_J-*MEgei9*oNm_NL*ipz$QI-B)I<w6&a5DM$KQZ8azO
z=~Q^_8pS*|t(L|tn>$P3MqYg<U|)G=zhni}@5bo`+I3>VeYl!39Dd<rIAe}h4|w_f
z?zkv!+WQ{&yJ>|x@nJZ+j0=M%Qi0{2YjPJ$wv}4_@oLQR54I|>0#X6jF^qpnl$U!J
zW|7uL;rJ6=dA{~ilaYAu&yg-jM8MdSet}nr`XL#_BKYJ(5cmCKx1H-``u3fO(I@d0
z!T5(^#qs)>OKDO|?c%kz*!q_S2fg<^DOM`jz}Oz&{w0}9Et#`;;?62<ts668dsSv5
zRxkpt?o!k5m&fNgDmkz0VI9Yw+p@*BlM%b;PWq=1+D}dD(|yJKocQHX(-AJd7TfIW
z1AH|#-8v(=pIV(7aKA73?G~FEHMSNtP^f%t7iXISg_<_bDs?1pH#IqBji%l#!ioLb
z*ZL4R++#h<rU|!E-gJyJ9k%0<T@hL)+C$3#7HPpSc>P>_ph;%b*zcZob8$g3FFaGG
zlRg!chR2acUVfb<4G63FoY)pEm`n|;2TnmnXGMYcX3}i-?mN#*Vq1u62DMm(>3LTi
ziF>%|HY4?9{M3L_$pyk++|6(oQQ-6{DHY#%ZMSnH&+NM(t5G4dIVKr@Szuj?)_}*f
zd^s`K38p+DGm$qtLLyWy%-4kWT0x5E=4x6GgFIa5oY&t1-gGK0kIQm(cYLAouUDf_
z<HMgQV(yoX#>x6`QFMxEG46*~%3PL|Zoi9kcBlkxy(NGO%bOw+4gkP;K%^ZObZJI(
zbj$X<FXb$R;0l-K*<jRMqTDPuuGOV|J1<#?X+L~2)A8)tBe6uWT`csFKvv>{7;>ax
z<LzEe1T0vhSdM)7{Zn!!<S0;S;?Vh|$9QvDRe5@%^>=H1*^WwDhgQLDuO9NyU9D~K
z{ex&_sZZx&(On?mp8_8yQ_XLwKrUq7B%4<`G@8Zyz98pT^ehsd%P4JF=dZk$eeS|g
zbL!3olg_KgYgGT)mQT=g_9n?4@BsSUnSAd1hXRd$$WmEbi;@_~(hqxu4#B}3mg*Cc
zB~1{3Td7@x7^;x6?31W=alAFAUlh#fbY-Y}V|&)V(lXZSl_=xU=5<rJVwZI?&$z$e
zEkt752I}O1(8!jXnbh!zh;r@5zjZ!C@p(6D%J}F7d1(&0F8lNej6%m6&G^7#Gn&tO
z+%cP&NN28?42KB|fQof_{>WJ}`-`Y@`%63k)H5)7h?Nl=o_w=IYVaZ`D_XFxz3Jn1
zM(~NVaB-k$dn)f25J*fmaX%T~@pZS;*BDR^f$H6zEG(>Lu>ShSYOfiUweo%j4%v2Q
zcbIh^XZ2GQxv+iSCp(NsPBnOdYe4=^8pf6+<-<(9yZ{knXp4W{W0<LDqzFn5#2g4n
z`^o65>0jBra3a>#WD)_LFU&x$72a5C_8kzgBwMi8M2Y2xQoxm9b;!COETdr@qMDlh
zTjsgHn}6X2C2fBwYO*SfGSMx|gMsJ3wGkXxSfq(Ln&q=GuW&Ujw+e>wBOiI4_%f#s
zL%fvd!T>Cm8H7NY2Y4|H8E>iBU6CCg){oLm#Zd+!6>|)#Q)}uX+U2J;r6EV`roWT>
zTOEwn$0{vK7(OgM%-Fd`c?vQ`CAsV!K3!CH1*c=~hipEOMRuOu1e~_4>dH&cG>I=8
zBDOt0LSjVhp$7M}xvj<kEyknkb6w|U&}?fzKiP9K43??QaxZ6t$Y9HNuN{##GGnF8
ziCnQ7tpX7aE`_?!Uc@tfPLV8YcQiW+<m?dNc8l$!ZXdU7x|xq;NEuH!+=%d9jP+i}
z-e+=pDUm6kTo%uKdVY~pEG#IL<wi2;?GmFXsidgVIKMKmME$ONgKbk*=&RtF3l++v
z#~*0s`I7yvIb=V%%4joZVdol#4nBGZ%uQ=lGH=0?7!5?bCB|xk+x3XBB0|5gW9dAF
zeN|EWE25mLTX@&EVxcv_#2iK%Sc9qabbPWnN{xDOZ%c;DLXg0DfRzpOH+PS)gZT~D
z(PpHUkd3^gNk})TQ~F>sCbbRAr4J2ouAF_aK8!b`Z(%+jJ$cU*dO+=U9+pz~#Fck;
z&R!{*tuUIwZF8KAK41{o46)O*`^>lC#-KG_Q)%R7H06MKv|Ys5q%u6KGtgu*P$QhU
z?It5-c%rSQ`ti4HIr#mpOnC~Cwe{<~^>xFn9gyuic4I-5>@gq|;{ZaJPIOii9}w9a
z6X)7q4(lGx<PIs}fCle}Ww>5Jvab1J8BG;1c{TnPzry~60v@-*WrM{qTQc4=P_^+O
zWFu!76yz*ZURxxnklc16`c`y46|L_0KD$G9QYgw;AxK-#4U~4%<iGQ3o$z56*=_|8
z0D8>F!GpM$tnYEmAb~Ia{%B|MBvlQ4{menpSJiodoj9NWOnGt91@Y|md*eYOt#4KJ
zTiN^+zoV;7-az-q*j_#Jgb&$5nS!2Dl&_x~vZBUhJ)3%l_qlkMZ<9W}hzhq$dvd<5
zSfN&V4%)W)^A|RoeB;Vmd<O<Dy_QncrcdDp5h8=lrZD;mo|c+3Rk7&21#*(7Rv5Zo
zQS>HezV*3l@u$wlrM0-x%1nj*^J%3+0wP;U$kPyC587n)YZ!rdDoY#!_$E#%qykPQ
z6&K<(cy$FW?Lvizi3R-v_m(_c8m<<z8x#3%PD4hHKn~YzgFtD2nr3CO!b#gx*`~I&
zNVQ&nGk2ZdZc+<B&=8-_S8O{U9UmX>irll>=k7AcXcBU|+$OSQx09yu_O}<hy*C0v
zog_mIz^2N8G{CKXI1lxEX)2cr>9r%)Fgk8LekCHZWN2rc8qB5*=Sd?+?!fV4+qp&t
zj9LBpj)BeXusUml@)wg#-u*C0m+GB1_oF<N<YKbyq8!#AiSS$Eimf~Q)~=0m444|@
zN3ryDQnl|taq{v2KhAfxn}Fkaf>q-4yz7OU_~O}Ff8TT5z1`t4z$P~Ff=>HsQTw5%
z|EBBBN%rW=#E-iDCzXTtBGnQ1w~y0V2%~;hW)jIBzIV@F>0B-O-Uff~ZiL_i?VwOJ
zg76~$L`G(eDAky#cSM0D+)uNt6C>Ha3`T#AWtR9fbu+!(SMHi<7<y%GIXE4j!SqxL
z>902js;=kof4G}^-%i#YI@@jaKaDC#6`D2`O(=fr^rozxYkjk!KAqQ(=yGD-n0qg3
z*_4^8XuZO9(VxpeRAIC+d~edo<y4l2-s)c1TPUa&oo&tUv<u-8xXm|cQ}T7p-W#)V
zO2N%o=CTs^yP|s1MlT+ebX%Z{f%9U|xc~Uk!7|3EdB4?sw+JEd+IklKYO1{G$hA77
zOpUD4%2|K-cqQ>VrD~3ipd9y-C@ve?f&etCq28knw!7zdsJ>GW7MGBi%g*!ir?$8+
z(L(HB*4dfeZzk8tqljR-I6XoKK(derV9;(D<3|TjcLdR~SIS*8CyEAy-R4ZQ6lt%{
zj|9(C2B*{%A7QXHZYvsI8z+~Dxy9bv3fec`Cp)e!zDoAcEbX?8Ql)dm&hl{;ua&&S
z^hyd|r~f4x;*j7KGWdhO-A2eccZh?1t()$w82rU!eDA|$C2ALQYM^&CJc;*9Yy%Au
zZkD6w_;LZr`PH!>#QM~&4{$36U<$jjX8ZzxpMO?Sl@McPmj*YD11&bh{aC+h4ZQ*~
zVZQyz`L$ZNgr~7>p<RU3v4^<FDNT)S?@!th2#=o=i69o}%z?UnV3)hunr*(l7mO3B
zi%ngMAK#^w@z909tZ8fYeLi*gSRU4yWjVELez!w)0sxEr(TX4`nOY$ZTIgZ-HSuK)
zl{kJZd%|BZ-$o^1dVIVX4U}S0r~X!|^S9xXnt6?N@>XTDWOWBy_~~m!^rZ5YctZ_u
zXqQ&m%nv6cd4sIFVvJW<Uxh|{9L;ChTup6DGD^?(q2)c7;m*b*ho~O%*%W$AoZny0
zb#7OeM->ioI2s0QO(4e~+^ucxA~g1&AbrwHB$@2)_r`jq3ROPUNA4N-3qifqQyWdL
zCuHP|?1fTWZ90C5-68bNF{CU<uVXC5+_c)2i63B0GJl#H%wYDCOE>V-7d6WeGQtH)
zUfB&8sVOHRQuaGg`E=TEja7ODGPXau+IpIgHN>?ww^8NdoxoR8EGW$QXxXxwF(EWY
znHgqrDrDHkzM%V)pktGi^%d(kCb~SA79c8BW8`bOx?MQ`4%1asY>WR~)a=7y*r#t(
zbfo)T>7in-Ril9bgTz(eoP}K-UFoQ!4Y;C`G-}i+TQc4LR8LGjUn2XPgHx59&#NZu
zfEsz1jg4o2GJw%~qj65#4s>8`P9v{%U^%hYfaxH2L(}z6-_uk)oEnXzNfXlKlPEO}
z07OpTUM(}bYK-{E6*WJq6vKCn>=_fGreosX#v@SsV+eP{qQ-jG@=B(Du-N?DzNJ|*
zJ<GC{48uu5ubT1R6+s`S_`r8Kjv@VSsZD7AroxcyP}9#Jo^oy)Ju$Bi$NRZsbrVLV
ztIc<Q(FkdTr<oi1>8R#r>|jXk-u;`1&w7Xx!mtPBwMc2SGP{qT%kFncAD^d@qxrmI
zPV}llxI7@|avE==>Mru?ts9YfJb6wb52|Ka{u(g}gayd2!@jU7{n-})E0mGpVssIA
zFz=t<E)5iGGzg96fhqmgqw|?ZEhky`j^(+XEDtO7yb9x&cMjRjv|Vo@QoZtz8-3Y1
z$_eKcokl-lWIj$j+q<rfzf?Wc7*Soan7`!CJT!eOh@q~Jfoz;HYt+B{Y8Os1%joSH
z3)96vYbiZ9+I}+BUhK=Q34-NVO)uc%$~4?z%g?KZ^Ax1J6f9xP9MjHK_2b<W481=f
zp>Xtj{KkaS^@aQ&aIaZTbRsSJ4`ugR-+h3N|9<sfKsNtBPT_k7=6_g#O>b`9sKd_V
ze>=mC#(>cJo1Ne8ksy%GLjgkLUKL)H;7qZ<^r4iZ?5KqQ2j`>q5dIGk{Xc;C|FHMp
zd*iU7Z5*;uf=w{_)<8bJMw4-HokCe0Jmx&2bUa9Ofx?hz=C_Ic#&6@0|I>*{RjGK~
zh;AU(=gnxR#CNvTAy8#s{`Md2Zxcj`yrD%O-y3CnTdGh{EyI(X43^-Cr<OKLAq5Zb
zS-5tg0Gf`y_-_{De+-N8|2>u-qyO}oh5Vn<k&rXO|8)JovHbr{yV6>3o%4?-nWH#=
ztqqvsX=VcZtwa(VTUKU>=~u7x&Ah#OTD9AV{1&=pCjCVYrJG6Aq8X1E>}ivq`zpJ$
zi^|<xS(^hq)=~9eRf%V8c^DDo@4pf|9PGd`z0f0LAxqPVAj_~L9M%0*?fy)rLWA8{
zr={^9x`Yb5alf$GRZ9oDUKudHmI~4)xi8Z2$Y^p8OT<Crxc{Hsq51H<zir@nP`-%S
z(LC&k|EbnW=O6u1H&J$Wn-E1Jyx7gn2+P|8H6A;qd+YJS+2=86XE)OIZ*J|L6zgo9
zsrc9HsvBmMv3KM;-KoWtxEpx-`QOtvY+Jk|`2M<M6AnQB4Twk4C}i<;8qOg`0Du!}
z4*qw84(;BL7T}06)2`cm7o$o!pGn@AJWFO!L*rQ?epL>E9^@C7^Nb|n%uf}^A&D+p
zZS-xInVEl{NQ7!H7<IDRd>+gWe5L5x&VSF_adIokfwl^DYEQ0=fFAExsl{!c$7-Yg
zuX_~L7`Is!^?vHxP33fc+!$F_Efu=lMiL;FZ!vU>qfmHOoxi%ObXanGJbR$I)^6rv
z0~gQa_v`51Z0kF8z`yB}S4`pQ4^}g6YX8=H7on;40?f}#wBr2fHgCsA>NWE5=xGr>
zai%~ulWx=G2*<xwnKr$A=6;SU3+NwImh8cpd0rke<hax<-EC1zzyZA+spdOc#2vCy
zV}MB6k&YhN^S;+3jlPc~6<N)W;=z9}?>m1W0`p3Ssm32S9ra^M?IaMz5P-?aMeCjW
zw_x*V^Aq<WfCVTMj`A|z=4yXNl+(GS@fomt27=p}OvubHl05G(n;h;WSss&oj_X~^
zn88tPhPp=gLXe`k{b6ho4KC@4h=_U;8*(F_T}TC&U0HkW5JU4yx66fWgvNX7W6&~d
zpTE8IE--=4nrOR{0LMit3cjjkJ;+J+#X0UhX|_=IC9)B8m?8-F`~&SC8ZUtL3ZCl~
zQSU`uPP1HJ*DNvgZg}Dv$Htfb%~uKWQ1YCFwe1Xf3g5ePVlytje<WLgX5fbbJN*a(
zy?R@n^M-Ns2^Zc2lGK>|{Q83@`PbGQMrUzrvt>CSA!DQjh#Wu;T&O=Wr1Npx;vtN)
zU4H3BXGPsZ@@2QAL@Y~CY`%KnUkss|=OF*+s{EsemQ=Ck&PL?0D{;fCbuRMljDb_U
zBrM^4_4L0bn?N4E<EM*(v*`Uyg#PA|mJT7mAVY`z-^myddmZCKy7Jl?9_WQd{1<aD
zb3)#d!vPET4F4faA+6c}3BO8W|MLK)i5DXsfR(dVe)BJcldJRFWB;vPQk^MwKYVj#
zLg>?+ga<BFOD+Z@`y}_eg?+I7(~>9;_|_MJl|R|S|Dx<Or~4`)BzeQauYSxGq?)sY
z-udsYFV%}{73LLRMwW4CfEGkCk;BHO<kz>DQQ!ER*C*9o`%uEaLAFP=s$c&%PhJvE
zpZ|+1{r@#&{x1Y-TI&RDG{nG8eSMATxhWCQF`7Zt(qZCn<D}+2T1%tA+8Y+^#F2mg
zd5o)q0Xne<wgxj0g~xpJ`bu?h{&V(TywsDY%-N3`d%(a<n)i>4Zx1)o2<#lQg<9G0
z+tz>k=d7bcJDixaP4JpB_EK?;=5*VF^Ka33|IbhH|EUiBUpN>4$L^Y2je6=PY?Aiw
z&)EpmK;V&qRiWwBje%80$ZLc|Y+*P6u%(QKH8*bNgMQSf^{z1Bx1CSlNFk&Z<ngRo
zCg>T75@=S)L%*W5>i%S{>hqEu6-ZjpKdgIkd?sfThyMpaA!1l|!zG?O9@$5meMMnU
z7?YlC^if6mb~};AUtmF0;h@^wtaKrCxcFqH+(F67TC37fIT;@SjDgOad;&OOs)Z$u
zOc=g3IE;--s-Gn9ObQANcWfz}t~6>2u9rgns(VC+t7xEqxLM8bw*L?!C~e!37alze
z;~{Ez^=&w?DoFsqy1qXE03S#qz2dup?SZ3-14eNZSYb=cv@J=f1hEJVE?hoh4zNjy
z0fWW$qx*-}Qg?wD4H}YCjio6LI%t6yU=0mC7&a~A>k}dU>?hIaqSpO~GTNfVa~j>G
zdEF4}AzgDpS9#8QstHB20P6pR^L^vew5vIlW?d4TN!`M89Z3O=)>y8>f$(S9ea;Y4
z%3r=k#3!$EU_R8Bl^Qan)tvd7<UxohuB+x!j$JsNs@WT_A(mgu(a?zpmT7b)Q8Hcu
z&PxTDhKZD_-w1*A&Si!19}rFK92!1cpvHt&{H9xsB!;7yYVb?_jxhm98^VkItugQZ
zfvGy=siq<d*CC078Qu+P^;uw_kVv`ByJ1339fgv%Qs?zEE!KVDC>1Y)&FR#`Fj_bH
zTul)8wv!)K;`2$g9xMQ}cHT|mYR;yXU#2+B0E;CeicHOz_AdIzL{+N1toF)}Mmid*
z6sGBK>BxvdVqF>3^*<1LHs*^}8oMph0ZM+tZJT9ZJGEaZLVl*cal`;6w?$`HcT|rN
zG??u(S!0`xvT87|8Uiu#qBs@>;LyJY(;q=hdN7O-<ThN|<VN3+8qFaosF&c$GRXZj
zK7F+gOsuDRfr{dG0sy;5F};bUD{k7>k?Kp(LKT;d^dM)giX4EJMob=C1OMj@=is98
z1DAEiwq2*GvnJnD1-Fa*Cz;Q#l@?Coboxp^{rV;ww|nj$mlA(wfF;kvud^@uZ<1wq
z$Q9=r91|Qo_m=Ze>LCv*Pigne%N3knQ-fa7P?*&~J?ld@l9^vS5L+bwRsHd<;r3bG
zW~s~0Hoe6^(bI*MrHi}Mb_xN*5$S>oMJee=nO$`dt$(NMYr3nbGljsfGj6Y?pKdoF
z4t)Oxo8fgPPw`OTG0M`j=4+78lmxRo$r%aqTnWwR_dh*uNg&C?X|4f)<yPm{qnyhv
z3Ts{T@Frwhe3FlhA0S`%4s><1ii4#9jxiby8L8A}pCib72PsimQ^fazRfgmHk=Wq-
z4gH12Xox)a<s-hRF)Ia8`@sYKsE|=bMI>J40_1hBve4{{Fo#Ymt7M9=aDYF*?eU^9
zU#&IwwXBX%mG$#J!@Rb`>#_aFpV;c<8OdyJBlB0QrW?p_@dMeoHMJ7qfSIJm*Q^lt
zjQFHXv*mAd8fPwN+#DZ!8}`@EUSZVLJw+AD=+&BgSiT1Qktr9|x38=connTv?)z1-
zw6Y_(|2}gf_M|r=q)%Dc{6vW<(Wv2_0u>Jw!WcE2dB4mjuH!|#l9`{4>$E1F0W3_#
zfqrQ?|HX`Wp0AZAKFVL@sXz`+8igz5UZpjyn0?M`nptKF5QjCl!Dr*9^YGet1^VcI
z?%?f&!yRY7rI42YxQ#=aV2sv-F<m$=Keh>R$mzI#h~FR(C$;ELK2pM%nygd^J%)yy
z-5CvEZA8fRa(upBl#i&hQ?Kw5>!`UJtmCUWDdE5E9|+7=_o<PycyIE=YvdkF%cNQ3
z^ZVx!$)<D!Kq-dm#c9Jn>S}kW2-T^3H|#e)P2<)6qssSV9}<i|w*KI>4P$!hhmj1s
z#VM2VjTzr|?-K%Pt9B%f8e;wNG=^es65!{e{yY)|;f`LVK*$Gv44`-@3K|vg%GgOr
zop^1!1)^JRns7Gzn&0N=+Yw3f$&=wV<U}HF0?_w*{i{T8V)oma14K+%*Va`>0QDj=
zKoS=X*dt2aPIYpM3Y@|s!`afeT384zUTo4o6f(by{@1_OJul>JSm5A-(kCK{jce|i
zlfw$Nu4;mqud}#mj7C<Q$7bSY@Wz+b>%jExwibvL`CaA46#&5k;&C=$zyh3bo2I7f
z#<?=1Y&y(RV9i$j_F^^VDAx^glg0Csl*1>(&go&!2p;}-z-C;}-en|JGG1Tbm+4X;
z%WBI>?cophs2Ip~oY7*8bL(WqduhC5ug0IQS$Z~Xyp$tx;-sB8<<N=p{EZQ;f8gX2
zvM<DSZ**fZ*F6*3-3%G0vmqLX0S@##7!-N_tSIU{UJYkZfjtlOodTFYVb$$~I4q0k
z+Y+H>%s&j|6bG%>hUm0z2o>Kz7=Ki=$YiV{M&$jOz#oDEIE44fl>>*u)V{}naZuCW
zg<dV-omY4GQBV0#Gd~uN;?!|MN{&(I?J8FYg9gkiTNVL$L3Lgn@xTth0rIKI9{k7%
zu1sU&nW?vY6S(e(@|lPL&m1HsvA9AU6`(wiL341bsXem(L*;c%Xf%>zQ7t58PjZYn
zA*O#9p9(lo$}A@0EmqV-+cBh*&V4IAtN~(Es~F|c0m_*4>!-iBJa1xG5hvjEFS-g>
zMXF&aB~kb27GNm<pg-oxGrIC0HSmNSq!PK9g;xFf{@%VpZwX3=ZW}fsD5Het7P$GT
z%sm_iJ3)?&it%c>JYaoMPT36mj<!359r}rJTPi@yUf8^^GuiqKW6D`xYbomUfk5QO
zl*SxHZ*C$1DHW$1_z1z&Osy<Z(NIpErdxLh)Z1J!&~tLxUmMaW5$6<!Ha#%QTE_%*
z4sCkXCsX%)x3*jwDoTZ{%=CZm7Pi=j&}~%iyDOA=5PIIVtbMFv%b`BXi4WF@aE#1l
zavb=(7p2QtCySAT=zr;^M=tnLmox)8{Pfn}f9gRn7Un&%kZE`CkKm=DowihsJ%AE3
zMphwmbQVKGGbg+}0`9G&lYGFOx6IPF>AJ*t150R;^vx$39MMHp@<%B&N~^0L%Q<{&
zpMoW2f`x4b#i~bxEz>w@8BNnJXTX1Rb5owD2#Af#;u>|Iz!KIhrsE93ltICQV=vH4
zl~=U9hg26S<NU3I1B~BK<<P;`V*!1<S*DMiycWe;7gm#o(YOs)q_+L|$4b%WK3tzl
zFIjqwOmqk$P|9y2xZW-1df^^bG*!dxAMb@?!MXStZQmb36O~G8-En_9e13CtY>j4*
zQ}1Y+KkwXa(H)tzT|V5c^g;HRkttYWkf1y(9X*FrhZ8@@@3gZedC823$5&*za|@{8
z4biQBPesax{rKkHC;X%g%IGwM9f(p8;pW=7rHR5T^u%JN66F4YAw>V%-P<3?2>xio
zRxRH%(rtKS(Pdbk49!KXW~`uZC+MWyg<IF>cs4Aidn`3DN>6I$WL%6Q{=g%t4=4P<
zs(ob)%wrROZA=X>ga<w_E?rLaa;u{c@2Q!t!N|MizYkI;Pc0k)UyN{g8To_t4Pehd
zcxmKj>1c>*`QOg5?#Dm*e>mqOG&>>u-HE)7j8V!td!yI(=!)*mF9jB`gVryqF{XIk
zXQ>y~OFpJosP1y#xoH&QQdHc`72<pAFGFjbb-TRPp@Iz<lre~XaDDVJQd0w8ly}4n
z-uYGFFa9Lf;(W*ZMm`k|7+739eLn$1&-6wC4U3daFEJrGD~?FW)YCP359Y^@ABFh!
zbu<@&^wAV?ntr>E{2};mnog~_=pRfKSVwUvgHJ`I2O?X6SO<Pao)02P=@w0Pa=00U
zMm`CRR8IqaovN8&kxWRE1rVE-O#IQ5*Br$uyaoWC$6vh;$Db_hp66kiv+JKeRFdyP
zK6J)(;YXB#Tla#~!OgdHiLN`T1%r7yD}NtOid?q9;tKj7Va8OpwkN9=?-NP+<sj(5
zVqr<M10qm`Y5KXJZavi4ybWOWZfDuQ9b*3C#L-wJqnY}OMgx#x>_{WcQ7uio@7(T5
zCQHOhsUrX=x%fhUMoLnD_Lf5i#Cv=3wtj6H?*QgiNi+Z@YBWY6SUONk%a}KE=7e0>
z1hxStG|jts^V!m)Ac+X`F!2+OtMcUN7ZcVPX-CJuX`mPE`Kbgv$bXS3azJ`%Xt-Kp
zI^uk%7^Gi)PVb<|p%#Fevldnz*wV|&)E$NlLq8j#&j)wg3Oq2*rIDcs+>-aWGbA8c
zO-TSs+CNCJ98Th;EALd7lPwP+12s(|)l;b0kvF6k;aZLhW`oc}iXz5-IDf*Zzr*V=
z*f~`&#+0gyUi0b+t=4nbO*?d^fsP5p`rYvy6y6kbKe@%jL^yg%jpanqlCYG~Sb2(h
z7V1n=4t3xGEw=E(ML%pDJVUgo)W*hcOFZCKvWJ99L{xjIQ(oy;P}e1{(dS`;7_F6g
zwikONEe%&p8RZ7+0c<X!KD={}bhnyORj69As+;D^X(6@=K7dRAQOvMM-B+cA9Ub98
za=BTSl2y<Uy$@!RhlV|WKp@LBJhZ=G8sBEizTNU&5aG{+c&9I17BFRIrlg9pT%`hg
z%fYs`QO8LmZ+)RCPHQl$_Of-}A)=UVA!pC~r-Tz^tQvG$4Dm&g0$N(}ncc6#@1_TO
zjw{h#ryo!DDO79E_`C#><8VQ2Td&A-H8?%So6NS!HR`%D>TKq!_=$lIzp-yuRt156
zZvo@NHzwWj_=z9Ax(B^Xht*j<;vn40XjrhZCH}Qea`o@6M2yWe{)G!xAU0hsF(DHH
zaA1XS<Kn#5=RcWinyNt<zA>t=sAc3d9Li~`lUXuS7?NK}K!}9|F}#SZqJe?J!G(*l
zz;@y54J-qd{66OdnL%LBB41WBjQG1W(UUXA139kidr4Y#{>yF9Az?+za#o760`YOF
zNWgjDpZ5`G_uJFR#?L)31ly3*3ATgUf(h=~_|m!DvA`39$X;n>`R3iGK#y)OUBs!^
zO8MF=x91Qvd8aDYs6dkw4cN4e9GS|G(7u&ReiPdPwlPvQGC#Lr2wH5aXy~>liqg!9
zRZ@Y1B5W*N$GtpJ@ui!H6Ddl)jdmkjU~sEtUl>>GH(IyRaQPm-Vv{&o0$RyXgYkjx
z9)ua=!tw(4htnqV_!$BbV)O-7#=v!(9BCvKneiTp9=oT!bV4|;tSd{HNVAr+R}MYS
ztitxjXuz+jR`TE8LaraR7J5Eq@Cv-@pa3|JhS}=yl3FdF(gJ&03Pzkq4#G88EDC6Q
z1NmPAb!J5$)rP-yfyP6+qEhLz=4@NkI)p4NzqD5OZ#H$VT_MS1woXzoxz^~_%87m#
z-K0PV=qx;Xnlm8^rEd2#i^LK=w8XS^WtxgQE68aZ-E`$PGWn}8$VM1-#`JFQFa5m;
zd!fDJban3-nWc3U;D*%8(e&Dhfkevi^e5?Q$Q_0$wxBtL%}4-XnEw^ISQC#pYhN>-
zX>fb#QDn6Z*O7j3(KS>46*hDOUrrirrP)&uXyJ47NhIAqYKZZp{qRnh-+X*Naw<Y5
zXESw6V=Xoxk!87xj-<xe))5ylFDqcsvhyU_s>!Dyq~IjSc{`$B!Dck94X9VW+j!{P
z){)BMbKC!EO;e~`zcWVkk+UB#2PX0@=5ppx)3|keyCn;jy}ZBT<G7q$kMDlJ{mDOp
zT+Giua?V8CtF^HGDe`kDPD+V_R-=^8j4Dl!q?|ChfSZZq1x1%F4md+$4ApB~&-U-w
zlqj_0i!l_IsNq=L;7%#pjjy`=@2Ply8^NkZd<$S=TTwLT(MF5Df=)}N@m{UoXEfCg
zCSdQI%q|kkXR|taXd()K4kk7oUSdM(gPXhEBKfO2JYyME@RC@4Z0T4*qtz&ui?sNg
zFa}2dX#G3QnpTq6wQ$%MI>$i&9}PrdvN(&7S>O1H9`)UC-O4N4TZ(27*wTI+I?9ga
zTr*q8#Q6E*#kwd}f~|ho#{@`82F}{M;F^r7{h<vH+)cW-+Z=6WJrn7y7k^n{NPcq_
zSP%Si`gmT`P5ICME@(d_U01Zl(xi#_Ck!R{7!=)2HWiUTl_jm0Gt66ts1DZ4-J7R2
zzx2g9xaxVYzqQ?MRVPQ+-}m9m7Hla@9Lf8ik4W9andEU}leOKqKd`X6VdP<i?X_F9
zTFcilrc0Rw%a#@4d$pP?qZ-`Z{rMYwwSq8Z(mr~NM5=UawO6LaiGAcNMK^-|1Cvfr
zCY`C982|ZehRr<bo3pik2h@1jpTyQGtisxVBTE7yl@uPvU%v)QYNzk2$<It?ZT|Wm
zcpyI!7bcCKU2dZqg)RDLV%l!DjTaAPLe~8Kt7yfHbav)tMymtL(kf)&{Xmr!SA9q6
z5n6N&IL8a8-9(-BUh|LEyBpLt)s9~C#2^a0=;WzJ82tgB4Z+%W?A;p$gex*se4ftP
z9@9fjsL`r3fgFI$z-7ezk3gRpIwiOUnC}ttLS1zJqA2EoU*(={RL``@$5xGx>4Vzh
zL@%y#t!&D`oQo_1SD`Gc@aLs^*7Z-Ll*C%h2uf%<Wmfc!gs`N7=&U<*NTFCWgA)n?
zWY#thB;!@3-?}+%<t(3iEVuEkKNV<y3F`&`@k42Gk*~GoggJjI%d8srN;v~m`mL{_
z@2uu=ha1L~BWI}bOP6`yLB`{Gb*b?D<6$dyIU5uA)~l(~A*?o4JG_76$HK{qOEIW0
zNgB16*G*<hwNm(Poqs!LDwriXGB7^95fB>DzOMSB5fA;=O_JO^)yk-oYSHA^D^#^i
z;z4{6Z40mt?-jkS8xbnOCecb6zBC=SW^zg_wd;0GK>?8Mb0AS$`YmVFza+eBGx?7w
z-jQ0^R5ZUPv4XxE+`jFxRK*zHues)F5FyL1?zS;mxuPPG=R&^4BqldHAt>MA_`>cU
z%va2l4r#=*o_0k-(!|!R6sw&wfM24;wBXmp?3bVcOX>^`Y+WP|Axg0156w38Tz)rM
zpClS#q7<Db|EU1&htFXjh@5h%O|R2u`h;{Tbn+&u7ZqPlFHsAAf3j7k??<aNhLW-8
zt7xgL8t3iP*y%DLx9<AXd46<d>DQ3*^c2P;PRdZE-BGjkYtK^<iJ5iQ`cr2?V?jhy
ze2AR}n+p342|bOxof2kcF`Qf+Q?X#!N%reEQh!(v_tVMEqzNt8Qn=jq)R1dmri8Ah
zg}00QE8Br%a0h;E6Zl^sl0JuvBEd?{oez!k(h(;gMf)_Kclc~V37_2%S6(~L{=W5P
z0x|Vnk-+~wB<;%Yr<<5LLjYjQ@li#zCh`ZQgv``PKrA0_Cs$BNVd27SK5J#cOy~aZ
zV~s$2_We_EHGR~-4qhttZm{`RU2D#OFXkEmTAG~QT=PM;RUnjn;LLJ^rFJ-`r_$<z
zn^Ozr7j6ffKddUkD#|a(Rw94cI&8rI5*CZAPPDk{^iwK~_ER&w=cE=L5zqmv1($;q
z3%fT}QR1?KvR~R&)4&YO=|5L_;Z^E>MgV}lC4D;3K?>mWz7dqwaxf+=M#xqn?1aKw
zu)0qNWt=J`QI|K{Ew5(~&l7D=(epc@nN$Y*x~pkg)ekC|E^mYYpNDS@L)*llCKu74
zNx(DqN-gd7_WOQIjg^{}CE6-e08<=FOj+2?HySMs4>|!MJv9p;uA?DbJvIogqyM)V
zPo{0h4}&i;o@#klNq7a(&rJ3%WW2uKPk8dh{C@0;MR5Md0{jAR6Ea#~gRIxo1&B<r
zowjmmoa9M-5Y{veicat!0ZSv4e+>huX?Wq>-Y|2%`NREtN_lUN<}E<vf2|PK`C`63
z=5S1TT{jRlm8{#W4EJ`lkHrqEf}5@Q@{~p{3?rOEWNB**{S?9M9@I@tF!*q^8}tE)
z1^WE+P7)_?$)D*RTKJ@%%-!^o%5rK-xPO5)UKtsg;FKC3G)oKD_w{=BRlhpt?w?7S
z*};Jhy%LB#bMKoJ-}rOl<*Mmhv(BfFEFI6~`?4j2N5K1joZF|l<XxR@Fe=A#rX(h^
zJ<Xu=VeRD*wocr6SN>_6Sn2s^-KGwh@2)Y)oa)_0qMvswUIpm>N)8@0EB{L~$D@WC
z65I_dd{&D}Pz)^cxshX$tXgJ>XsDjgOl1t}Jlx$O!WYV*ghvdDc6G8RD|`U{ba$Ho
zt0ek9y|;5#Q*BSZZr2Ha8MK?eqJgB<yv_i#B%@HYlw8H*E$Cq2@3Lg|EclwyhR=SQ
zl1?|Kp)u$;Z(%5v<eGZjUJk_L&RsR!SMD2?l2TB=0%ZbSHvB46KEf+yzSMv}Var1>
z#RE-q$$<XjetZ>}N7e0x)I?H_6zEp6JNvr9wV;Gv*gty(&%cTd5BQ3^t;d~7#`nI5
zzQQV11_6NaosRkH;T%SeWq2=uwOH<xbpjG#Ull=Ow&zu*!p!MH2rD_Cl-zt4C+c;w
zhMd<Uf|AK<$u?a}h8Wzf+W}2=lGqOkjAb@#U}zBP%nodl4YsJJbio4t(O`1Mbv$gS
zGyCv9{Y6ChKnF+rt^%{25E(k~){gl=`K&M2i)uD%*(Dg{Up-jJ>oW-7J2~UPnHXWH
zdaY@`@_*0E1||u~FKw4t+S@FI!rQCeP8S|0;t>!KKzXl;T_662`TH9J;AYODDcNwY
zuT<Y-6V}{a5(<+u*;Umxy>4AN6s+jO0bxpq`ixw44-ups<fE;r$3uxSkj)@wFC(BU
z^$R3~ay+lhaOHe*p?%q>A!~?^y!^ka`|6;$o-g0QN$?OPxD!0MI|&I+a3{D8?m7`%
zCIokayEC{X!QI{6eb8Zelkab<-fnGe)!W+l{&@4x)UDg+-tNAqPoLADPxldZmi`e0
z{lUFFe;kge9QwoNG#>OpN{R*vWM_%47Tif}AepojkCj3)H&83JY{fQe(g(u=_@lJw
z`d5xN8KTncP1Bd5y~Wy_KmpiIfbX=^pJ!j9%q=1<h*joH9hi3{TVbA|fpS<?2=Hmp
z&W=cRHM>(L5hm!dO>AnnH)4&d<V!~kTx$oalj0&adkd@n%DUu7A?7QME?5UZ2jJgc
z?-2x^F2Y(_$(BSt&*SPX%7h^HoyVd9obitdUO9b45$^%wAY6cynHb~EwLqIbgOCs@
zK<3L=uBE0=DKQ8$`1#A`bo9ZZpcu~5zUW)l<^s52JFb%KZ%|*I#!1NwM$GqTxF>|v
z8v&;htk=Ku?Ezz@^5)?C`vui_<S42afvl3*2Mfonz*o+E@0ZY4e*KCqShr_+_F|MX
zq+|dDkOb_Ju6ZH(GiKsczTDhLa4f{}kH9*F2**XpzFz<MXrZ1MORXQ-=w|%(NP~N^
z>k5$!1ZnNOmwFaOvxWw6Mt5lRrJ_B<i(&IiSHopjSG&NheM<SG90w>74Oi;<n#zpd
zxFs4^T{o<oJq*xF*++<A0({+a^@&U}YH-XDMmMk{1tWL`l86okNC{w?s!96t3ji5_
z3{yt!+RxS&bN#?QGxlyQY2iGe9`x2WO7HJv^ay^<BZt`0`K`phn1vK6h^t2iVPax_
zc`xxO8^%NbyhqSrii8o`Dra8V`j`2kkG|=mxb{{LQ3`mt9!UMq#$nUWf1_gk-=i-D
zspfE~r64drZ@<YW^MyP+JWYdoH>7mqRg9F39v`)Za{Qtf8Xr!)1OwGdqE1>ud8lR&
zSG%Q%>T4=Hgb_!>`MX{fW$X(~qgy&|D=g;O9ZzT<>*pp;Q|eVu3gOAL*w!=v4eD8R
z7)c@@B^OA7I$F-Zs##7+AeJ*6<~t?@9T#fF%M${`F>*Kxe(kuE+r{xTxaKEnIaYhx
zlzLXE4<5vnZPo3Sde+(nD7<?XWzr@rv4lgm`nXuZzff;Y$LveG>9Q;#i<HpDOfQZR
zWj%y|U~7^iky**R)&UXC2qn>cBPC@N@%%Mon7OuN*2+Z9RJ8ABiY@|THm5f-mI~pv
ztwY^X2>>;yqD{Io_6BKo1xgVTOqv22PyjXy0(~!tu*m)Cpf%r^O&<0KsS8(Y68(A6
zkza7#fHZ}9Ms1U4PdSPiK8ArqO^<#7l>Z}=mPKy;G0-yY4z&DZai8kiUKuGLbu2kT
z-V#L(ilKQFZ-Syp04g{~7Sx-ZdD-|W)FHwHK^jPX*WT99JHM*SnjPQ7N(5lX9!28@
zbP3i!G(d_Ew@=kV8#*EiJh@pHKWoi7F;2<gnTrWb6ct(4Lbh#e0p6G4z+dXWuq2yF
zz*?-j+`#^;CXJ245#EA4r$vbM<gen|xEBRn0tFT)^AO<UO8z3AV;Te%u#x8VyM%S6
zmH`OnF(AYR{4%q=m|FY3UmE?`zK)r|z5Vsr516PI_u#XT`gOni7eZHpd2Ahj7{Cx-
z((@IH4mny94qXwC!BhuJ7xj1<(SSR{lGk2?GaES@Io`pZ2Lo?6zH@s<<f(^~S4@=*
zqz-AZ9BS}t#Uf>=|HunVZh$yqKy;MJ$=}i&Uw754Kcnqe6x1y!EYtUZHC}wB>}YJ#
z%bS^YJRcA)w*NR8DJQkf81e@J)qeTy?hcvf5fE(q!;gG$-?M2Cv3`lB0XUDy$wT|#
z$Q?<3Y!$tW0+@n|BLpWREf9ilf1Ty;{19AmRGv*`UE&RTAhzWG#*C`gANfOvUB7aC
z<xu5%pmJcyu$G<QpzO;UpifaHUVhjBYlA7sxlZr%CJK#@bo!<rftI($G;A85-|t-h
ze4{`>*?jfm%U03A@HA}Vpf|w9RQCMmOH#rd!a`;v=%uD{8OC*%(*pI?yJEFC0Eu}L
zC+i!hxPtbi4iw6ExIlIFa~vX5Cz1zvlI3LTLgA68?Gzc_>EpCn@ZuF^7HMJO>8-^O
z1{Oz$*6Xe&cx>^$-cJ0~RT+i4vz;%*QlTO!Plk5H7A~Z<)1$>Z!=_=D$l$p09dY=w
zJ}hTGEn;G}{7vBE8(H&+VIKPm>L4HZFMdrkSjg}*a)B}u=3)IGCH>;a0GbdA5FdXV
zYd42Klw?Dg8p!ooOL2xv5euyU80<YFpQd2CoLYVzY2lWi$T(#v$z%WFAaiZLKdnQJ
zi6f(>fx&H)Rla2Ydm4F>`47PYmd~v1Neab~yq)6BxI;Aa$c1v<ID=MG;KYqdQCw2x
z$k*u7nOUMC&%wHacbcE>2i+PfXP6K>_b56(UHZCAl)d#RUj}9PM<tf`a~N0A?muuT
z{79-CYSMA_JD$-j$C_*yGOkp@A(iz16SDD^Jh5CX^Jkk5|HHOPgTwR>?9|j2fx8E;
z8p6aO$s&oB+aA|CNkOf(jVtlmSvD|66m`1~3j2JOgHd>{Uo2}tH*DG#Nuz)>gVV9Z
z&a<5;k`@C2NDc}lHgc?fukw-gJ-cmMjC>Aus@DJHEE8op%B>;@d1%nmSRL#rPOLL?
zBT_yxi(tAbW@_fMiw+f{Lg|`)ypAT3)%+@*blbR|BHZ(n3NU7|lYp&|nV6#UF-gX9
z=Vf;<j??_YtTo!#*N%5f-?*QX=7JJxLlKK@@l3y)hk2aln+s7*PmYQ;P-uh!#6y`m
z=yNremD^uFOup!SZ7Tgy2(d`{={}0#vbQe%#lu^>nx7Dd<x+IrH{vdh$cai|j4*?&
z_0<hKl?(|jtnV4kz3D&FGE2~t1w8B!_{2~;H?xe`5>Db!6b2~1ET{R)ykpADl+9oP
z@GSsqXC#>npn+og>&Vs)6b&_4jP+NtuVlNsxM%drTP7=o&H!Hls@9$sTb_y_Coq*;
zr>C`rYQFw#rFRNeay(cqUl(u{45m_kL+Byq!i1%w)eF(Ksz*Dh5dIb39-}mCv(^XD
zqIo)J9?l5M8>2I(xx(Nhz4c6@;#lhlD^Z)ci2ZkU0bN5mDcGs~?^W2ltDT1ufSHmE
z-|#1<6Hwddd^>Q1-s{{1c4VFI8t?yk{8`FWsulW2>q}4bflY}!%)FKWz)a4EW9Kd~
zom=K;GlL-da|)QY5O%I33V!W*o=gUG^_82N4al1;Us;@Vo68;%=M!cdnX<7j18IGo
zv0?+!wy>3}4j*vzGWg_qe*MT1+s`-O{QZ)65S}?u{Xv6U;l|rTWhX@cM(B$~<%k;f
zm5;fU`6ktk?&!tKQDjrczRfxPlIz+~5)kVrDl=64QdC5m(dV`U#~Em9)@4zW<@}le
z=LcA*#tygk9$;_k_l1V?#lFlqZIgH)0KE-eD)`+VnPe_!j&h{>tbsAGK{RTn3zNcA
zbikf0N)Mcx8XeC2iKtYbftmL%rjN);gE}nhb@^mu8))%RGSymiB6hIf0Akq&mvXHF
zlzE_A51eSk+-gnhCPVS4x%mXNY_Y{jREu3JpUhCMZ?(}J1T=BCk5tpC#axD1Qd`ht
z$dcSx|8`2n$oDzTs01QFYv8=!L5hP~2_sJmry_~#ikaT3Mw5UoEBc{}Hj_D8c53E@
zE)H~3gDRoDC;PL4NnG*<6u=tCJ!-F-sP*jEUF<c1d?(3t#A}ksFy1;q-qgbF*Rg|}
zBK_~a`WElc!A8Tbxy7P5Xmu<AtF&SMDWZ&<A~q#6?-610>bg3GqX?UtR;ItreckTe
zOY7&KiV5J4)m=G$FVD&BG@lra5l7*X?>OBgzJGg@A;v#59$?|#Y*ja@kD_6ou`q?c
z1@ANJ1@WgY&0+|P#6*qs=<B0t46NmaGFf+P*=Pe<vCtlaTE~kM`z%r&jQV^cEdx}y
z7xIcp%X;;Skph(4dPRX~Vk@>9(L|u)o~?6{GLW^MzKMa!*;7bdW%>yjUi@_3T(d(0
z8D{5D`|?1H7rhK?+3;f``m9>Rpko6SzfZb3$gU&bcz!F-w$=F^zQ9?o4drYw2)mox
z02ZoD_9vLvQ`OsQNSv3qEY&5;P6X&6mh0VV>l=V>!#`qNSU!^O$r5)}65F;Bafhd;
z4Mr=}mk8$+crqyCOE|eR7d{|65UZsPyUd(d1GW)J0o%BR^D9;iod+K`YXQa*w!jLh
zuVhRv#&(X}?9dVgEU74_ijntXYTE%HnLEDMU;xHZ#&wj^w8-}C%ROiL@asj>6Fg=j
ze#6gMgm~xWH47$C-bDPm-It965c)IGraFm|*K-1-&=Ajoq}Vu5*EDV52^6(eo{UG~
z>T+aQlYmavZH0}9iJa#TK!1LvE7swq+n(A%Wfy11tNq30V}ADQxv-=ukOBq<E<Zdh
zd;-2Nxs0uk{Jm-x>^Q-IaajG*ErSJJ2?wtmkoybJY4fHF#PV=QYFZKJ_t>qEpvg#Q
z+zKuok{Lbv!U$Q<e+ry>eBjdp@}QjgEr+KBoNRS@;INb`m{WqXSFxn9N3-S@;RCTJ
zbc=QT3&>b!G44a(s#JH-Bo32ag%i9w-~hm=tYNn9fh7;~^qG^)7eMQ;GiU%{K9bbf
zX}Ba*S@fexLd@zpbh9u^m@{OTPpb3-4$Vt8MRpe77bX)%PoU^xB#gw_q;KeyWUQ!e
z_PcWqL!uM3);6x%h64o~XxV}<;pkkf(}!}+k-t~W(3~b1<ojngdBj0Qm3Zs@^<3Jv
z-*|w~@5|*A+J{qsYz^7`atX;J)=6!hezEAd4?gv1o$0kG<Narvy=U>P@X<ygCyeaM
zdgL=)FIo|n5u8lw>k55ukD+J`Tx8z|HOViYsK@4ykDwLLwYB>YhS;J2#EtEk^}uh;
zV)RCnQbmxr+G+E8Q6lj=Uf9D@29u_*&laPFc{Ikt$nfSs2eCiZhrl#Pq$d)`hM?RU
zVROKX<CpcE4Ac5}$j;c;bYiq4I19|$8E6SHK{+-3M1Q87Npj*Y;|h^%><RZpAPwSh
z##;}(IS0}2*rb>A^tqYokzMtAr33Z`A|X~e5`H6pRp2_71yvs3Qz*n2N!LM{hrYjP
zO|z0@pYyq2BvI>!IEs89xc4^PZD)p4=V|PxIox&lcPR;vzfZrWwHsLYz>cGzrANQi
z&#<Vp*2>|{!={$L3dGYxn`-}36SsvJJ8?z>`iCBeH}_9yjQ6NfU40#YgV)|7WrbZK
zZ$V{49i=;^Wb}JJ^C2kF@Ag_0^R|)BpDYBJd-^vS^?aI`dS-q1nj(4p;re>cstLXY
zhfBJrVW((?)Cmg#y^E=(TXih4Y)Eemt{dN3-z<<ZJ{=avCevl4{C;OK@l08k3lFN&
z=G?_7byW(SE}s#w-?8stT!@Vk%WBQ%T6Ex78qK0~Td+2E{yEY5wDoHrWn`;#;=F;<
zQHW~Nqlv;Zi5?I=u;f<5Ukw)eYG(?mI@S|e>j`0P=m;9(7P$OENT#8D$l~s9PCLi~
zibq3RoBFUAy9--h&eTBB-v8UZ+rx#p9wPYZSGnyq`=D~;B;F8yRUImlbi4i&I|dV@
zx6P49PTa+u41%_-Gl}{6`Cmw4<meO-+x@|qd4{j{2sgdr2G7Jb0n#)yGF)X#`;N!)
zQ|PtgBQrGs&F5+;>YdCofGA|Zx6dF<g7BDDI=TMjuTt+(0c}+WR>HR2?<Es(S?VY2
zWz#TZ=%%Fds}3^Xy#Olg4vf!^i|&w<1?AHDNgKCJEwIe<Xq<(8oQ=`$3-IcVI^K#h
zv|8ceWRtlH|AMLcd@O8y+3yC)GKs5$g*lMmjH~c1SDE3dsPO5r$b{eBMw7!IcFr}q
z!gKEli03{(l}UKd_L4$nszc?;N*j6S_FxjDwl9P<PjD0YBgc3~I*xH5$*WZ}*XHkW
z`41m_eAabdTtT6FStHKC&1iDLi2_);eaXv1?q!smc9Kl-kB-2gJLk_{hAevP{e+*g
zI!c<D1HW!$J6&|fR$L4;3!<wKO_n`gu~7jZQ+6IMb)J4eb@!!C=-Rt2TI`{Xd|;hP
zCgKbkp*M5<6l$~e)LYDNS45U}^k&_6W&8prk;1U9SEQvZZCS4wOe`1G-B^yECm^?X
z3$V?YFBrDN)9I1FLCcS=Z#2(WB=79)7blI4=l5MTRfOLbp`=>56>eu2&uNmKUYZ%o
zblCPa%oTKRPS-VcscLIIhxI4_4)1J5oHYl~r@c9q{&A%@_kg`>cDHeE$EwbFk<$1R
zH9Nv~Nd5!RgOPvEPq9DfDLE|6hR{@;iH`0g)gd<lLF|PtI6N#YzSmbtPA*Su#+;6h
zZo8U_kbr=tlHss=i>qluM7I~)&9c9aGu#Xk9<LE`gA)D}bvTH&A}WE&4OoY_mco7Y
zGS+i=w3h~0X%BzAwn}?1ov#bFj?neAbMBKk*uY4vONnnmB1x%E`Pf|T%pEabqCxfv
z68=&n0xHxk)`g!Pq845+>B5E%AoxNRP7a8~Z}YsF!bVJ8M*w14O|xyzs&mR;Td?zY
zF#M?ZZ~=SYv<dN^7AOE2)jTHv6aT8u^KgD^XoCX(!#rDp4F$f^k77(2Y|Ce&&$&Uj
zr=<n#bNma*EarBYAr!!h@SrA^SK$Lxs>DrZeX-62IV58}K{Iaxa`pB0U$mJ{fBHJb
zqBm=<4+x}rE*&}4@jKmze1tEEZbxZ;<WT(MTm%hWcKo5s)Z*@5#`(9OUxQ4{Ewwi1
zw+cgq1cl~B4{-P1cIG|P)#tD?H{fIUY<<I1i;v=bG#@KpLglyWS6pqG)$b|PJ~h=B
z7GSe9V^Qqn5UF}TC;#rgS0yIKo-bul2|W&~MbLW<u^$**Xim*&8!480)urdgc%6Rm
zh3S!3|7AC!-y;7)%}iV<hUy}U`t%@)@{8z5I+Y`!PU)DZ-P8NiI!SDP*hBe!$<AjB
z)|_@7!?sNgX>polzCgvuw?KVd(WCP#PoXv$QeR4|@*USd>$UjqfOppoC~u--@~xDd
z#;C>3zuWMd!_Eto23ux7+73~vhSX;P4QmLgqMuWadh$)_=&Iu8sd%}2sjA$oww)K~
zb0oCY%ZJ2i)Rgzu)r&hx@`xPa<xJ##t*;k&+*S&IE+0JkkDR`0d#cE#oL7U}M9@XF
z;A9OY)Lrx*aY9)=E<6B{&ttu||4DJi{w==x#}CG%Xn?&vaJF0a`ch|Jpwr;@pg>n4
z38VBZktv>qT2lesbY7hFLlSl_3a@togkRn*-}Vfi`;e`A-`N}W`Y+h+PPx}e?@nDQ
zrK|{VD`#v>YTNV4Km_vrPytB1Ahs8x%ZFHy%z8s_ezW7Flx|b6rv-v%U*4c71)Duy
z3meS}9|r5>larth0Z!1|u|uXZP@uc$1y_Cs?@;<R<#w6yC|{it4HtZNgQB23e%TJb
zPN;eiX<l6BuHG(#{w`g)zoy@e?QfqvPqG5NqTw+2Q=v?7MD!~!i@aI><ZA*|vSOEh
zl}7#OuyK*S3t8+6C89rnM&`r%OSE_UR)$jPhx%DwU4Ca0vUEDQQ9Za8NGF$ikdilf
z4V`ufpC}^W(G4-G#s5>xjVEj^`!4cb8*9nlQWw^-N=tjc?}=8&w#A@sAMadSJKLAA
zj|q<A0>=&f+MOlR_O(QvJ}sgW0p2zYfI0|8)xPQE&wAS+R8k5m!jFL@-3*;Hotlel
zDdE)dDEQE!kb|-Z@!Fr;EIHOprX|4dHX6;nQ#R2Uczim~aO~=+`H-BIFlwUN&^1%b
zqls+P27yacjjTkno;q|@m)H1X6Bf1mrqhTwn4ppx8+$qkAg@_`Es%~LDe#S-#u+Bl
zNHa>SP6t**OD0_Dy7tsgs8o<zFfGm47yw#T{9GfP23{duFFNq}#nQxL0Cta60HJAR
z+BjrvrgnAxO7X*1k$`p<Yu6oNFdOn*8KjOgWEA`sH1p2wEBbLXQ#NF^+-Q|ZTCP~3
zfok>@+a}&W0T8?kqhe4LD_ey+Ea)az1(7%G`hFH->R4n1_#(jt${r<0AtS%((k}2O
z2Dr%rM+CO7Yy_B8ZncWg09e8y5LZt%l}(S3I!y*o$kMrG5}}rT5#kvfT%{%GYt#~7
z_B0ci7TnG?cjtG~ZAZs<Qg1c3Nh6QEx4LMU*NJm+x2HW@=!LsKHRQGy{3?o@kF0a>
z0j!;){Qx4r;i~+V9$qu0ldW{>To%)$<W#JBI(U4J@@9`8z{)2xdz%9JoO{?p7xr3f
zKU1<|jNy9O-42nnF)^7+9|5q)Uf&MV0j3yClr4F*0VVq^;Au5U@on{edu+0zEB<g6
zW4vshS8T2jmO^=D36icZd4`VjI!*R6T=sc=n6yn3-?6BVU0Lo!-=6!hO<_HHL61m%
zF-~8dV3JJpaQ%6uk-(zvRxdp>y6`g+K<)4j*+ImJ-xLuOx7coav@RkNn{Vqg0o!im
zs*GgoQC7(1Oi7h@?@*iqBS)l-g7;e8m^51&Jb<Y(+<-B5uh{$Cro;Mw8Z)!`a%15`
zG|332Obpn9KfAK{#=Ec_goxEjs*&GJCyN<}5}he2AKD*I*DS_Qn*Xv8<Qzz5Ua$IK
z-ss$O@@zD!$=WJJi}yrBxiC7~TEGTVxHsp$*aHVn#ZSkiWk+$l3!z@XbfDtnJ8M%8
z+AQFl6|XAzMn#ws3dyBPqDP-|*g+Oq)@1v#C!yBdTiR{2!9&4Kfexy<xSixlpaQ95
zr=l{z*La_eM@3KZPx)BM;_o7c#)2<BXu;RqRl%rDPbJL<n#?5}U71JM%u1wYtJ6WI
zq=E`SC7)W+xv_bNQI<GTizRh)#^*XPZpCdLOQ}l0omV^|Wny37Qt-KGdA+QxR=Wu6
zfDww!=F_CBXClQ%VfdJ%nWKcrt=T@Z?u_g#l+GHEQA{^Ea(Hk{>q~P#<AX4m5fkOT
zfleF96+TaVfHvCmgcq`HXrR@&#x+I}$?3-<g3*1#SLEEYDQ2BhXKL7Q$glxX=(5<!
zHCbS!9g*C0fy)DK6IU{m55c2YQcmx`83B1J1E(|6F+2ZLgf#dH?4H&g^)^tfyQ?a(
ze4JPp<dtX6^eup87LkRW(O7Mlu+kTCWPM3FA2Q<D#Ty7V`wbnlI)Gi^(4B_(dSMxk
z7CD?)9r>R^Ij9lAe#35jpn`h`+p@0%b&8BL>ZefiB0NyHCyhkgIS8kS>J?cx4D)x)
z`pM)7nh<Le*L#*pl(74I{7h7}e1d_xX<5$(1%q-86p#u|0^}Z6RjOoQRPV2?+B{4l
zPAspo$x^(BW?Ie9!R3cPwitR(P)Bb=eRzs-1wp~stW?nyXfjJCJCSjB4ZPq30FQrR
z6O@f4|I=DWvF`3FZCFV~%+FUg_GH*(DQ$?z8qoU3C`={7?dxu6n~#Sbgc7hudi2&C
z`EPhsdZ0a$;8>ds&~oyU%&yVnF@d$7c1mY2aW8?-zFFtllVMIn%1$GM{zg{i_QI;+
zCw}=}aNU=m$%>{Hb|A7DxTwsJHboBePNk|#m7RHnsUgNx2N}NWVTzzVoy8J^a^Or?
z>3@u*$N<R)4kz65M&*q2U#n*hs7MYD%KBL*fC?QE*bQ&u8;d{PD>ji~fG&1428)X-
z9Ynq>y$uMiIz8&tt>ksKQ9wm*o(Zt#z#$3`;#t5IqyX<X8{)PM5`f-Wo(Rv|8Ir%#
z@5x(?rz*SBW!TiqPbQst0jRYE+q-*KmaBhXR#Y@_^9yZXUN7+!F~9d!T$G+YpA3`R
zzQW9|{yA`bO6?Xk+`9IyM|0BmIpwmht^{3%ef}Y;W@_4UMZbdESI23VwS>SM&0_23
zk!Wblt+DgHdhxPXYk8AhfR5b4v2cFYi{%>#I|m0*t24t3brHCXw;U!&y;BVT#ZPqB
z;Ce4)IjL`$Ho;d0SodAGKmegh5e_mEf$yj7kk9soTMil<T42nw_GXXc_;fBydw)a*
zX#l55J9}&d4gL!xDXzR#zK^J|!TB*PHl4A8;Mhd&aDi=XZMx|BjsBu!(g~q^5#L^a
z*-a-+Ojo}Tl<)mD&Li-X{QBq34@@_G-W!Qo=KzKxF_HAMWnA-u+vF`O!s<@)vR<&{
zx3;#fSw7s~m#Ll_i$3;5liO;*XZW=upvgb}6<k=VuVRf-u{1zB{2QhB)xvBZm+O5E
zeS1s8XB6F^uXmcxI!hVN27d2O4vYBhYq;SZQQ>S7G(v#%`+nxS*00371&fXq_t53T
zAz6^#KK{ukj8!3&?2modn@MtVKBnTFwynAaq(f8$<+&4&a6}X^zVqup`~P4lB3O9u
zQ`RddCpTdJe-twOw?u$CB7oqqOm;3z{5p`z{;fcp1u|OP#LuO{mmlb7DaQ*mbD+0#
zE7wtz{H&xNMcjvMWgKcGH?~AiQ!RKB7d$u&DV<4NCfXwHe!4S!j$1u{JQ^fU(gcO%
zn{DH5#547LbmMsRx@7vc!JX7qbBl}U&DkvOgi#~Zi?cBgYxG=$QdZ9$Vzm3ydvI2~
z8&76_1ze)<z88#pQQrH(Xp@VXTK=s!%7(WWHS*>N=78TrnktblxJ_f^VN>I@{Z*fp
zR;}km&u(kMEt7)bek+%PbzYiu@vM2=_X|0xuhMTk1iS>IQJfo5hKp;hL=O`MjIIFA
zB1XcA17lyvz90eczmWm}KVOVlfW<MnQNuuhpA<!XL03OGwgmBox#elmL9c0~#;lWp
zT2wjsj{q9d?QM=t7?0n}#3X%{u<V4P!l9u^DSR^vpAqa?M)zm|;&``LNEWIpzJ)&J
z^gf#doF4P8m_(o|tHd0g(z2C&`q7oQ>rQ8e)Rd)6J1xpRNl>Km_@n&jzJ{d?ZpPz7
zk&mn+|9+()d%4A{m)g+S4gcM@Mz5Qd`bsJTV}|2K<%O%;$*rLHe(_ibc|SRIv1%_a
zfRUxoVkfz}YD4Yn{xg7OQ6*^mHt=VOa6n3t;NFpkDDnzT4tLR@=~(tiS$S2xlm?eQ
zj7R@F)q6W+%Pw|=;mo8BT_nNclrjowR+thrnCh9?+LckDsso}}w=IVr#Ss7sSB6p=
zqAn2`MG9Jvw#c2n6{@t1s`~8^ME}YTuCLa&7EgfdaY<gThd0IkwDsyDQ5mwG_&K9r
zTuT+Irghsx&jr}uvY7wjW~~HotO0sl(l4v%^iiXmjU}3cKUmt>#Zfmc(eVBt_le=W
z2>2>{EieCh(IVp4iFB6ROOUaN=haeLG1ncFJbFtAAiL~ns#|dScSzJ#pcW$C^jS?n
zK)_6)S7k=vW>0h-OVD8|EA(-*zN@MD7A2uwz{3~vRe*P2)&3*%=$4qkYs_;!6lrd;
zX|JNmSJM3W((HW4p}Ce<N8hE3-rsemX6=cuY%0O%^Uwwe44gxeWpjUu_*pLwD%;8C
zx`*-@d>2OO2nMqX^{GoJAe&;0j@WhdT}X_mpZ*`B8Qy&#O!>BJ_~yuKH5~S>5rcxe
z%L9VgWMJOr+?Wz}0s!!&gqhn`o8i`b2+m}qx!hQi>y6Fa*M;dZs)guwQDXjF?N}Y3
z@P|+zlpqUaifOl5xbismyYesv8NQMWsH6~)pi<z(l7nrI1UDCtXzcoC>#aO;1lC(E
z?O4iZ)<(9juGL72d<^AsOH;~i(3Q`~1y~_h|B=qhHkf~#>D;`*aTrZpU!_i;PnX~?
zuJX7M_c{V;)bvIOkiE1pp)cikPB?Mw=T#_?P~|#j^XX^qY`%D4d%p25R)qO+A%V-o
z=k-haVdf<JG}0r9mCXnMXkf`w+?2-#KkT=}Mr0JVOYfMA+1@smhnlry1!D_Z3QGU0
zTGA_ueHVE^k==Esu=xbm320Bug|6m}TdUW-Ou5e3E1hlH<~KGsv!2FPr2JUwuY3%6
zgWAQBg}ApS`Jtx`nn=!#Uu)aA0M#SsopYJb>OZNrr<@*BMg(0Q-elF!V{aoPf5P^{
z>#>rTM;U|OAht#i`)&3!gZ$%Ic+JtkSfJbvF5{@d;oda;YXB)(YM7AU5>^!+&O#yy
zJEHFxcwL2!wjR(&6$2Ny$Z*~nsrvBK)dC8Z2yq}5;>637@LT%QVaTg@3a=9GAEjcB
zfvWI;0Fzxe`JP@B5M*XzdeVV)%b<_x)3osZt%gR0xh=p9Wa{Ya0j`ja{-Y(MarpVx
zJ;_=?7~ISK;z^FPaye){ueb>rYR7lrd{QKBGK*?zg`^Rq9&WtVK;uRuZ0?!f(0j9Y
z-5@~Cj|sJ_d-d(Hd>B9nnml<wDvND*3Fn2TqVt#W%ycf?T^<vFMkd6@bnE56ij%e4
zO>3QsQ)Ee)c@cm2*>y0ZzCMyp(E94jPsZkauq7QoE!{Fo1tF?Be+fCTWYVzec}_(F
zBIqDs<yBjpp1>b<)6tNHF+NNkE!@po)-&}-8LE(=b^N+aa7!~(1Pmp1=^Cndx%!Un
zeu(N&vgg)vfW&_MSUkJ=YKq~>N}W=g5fEV0?3wo=ow{l87e!r#;p<NVOxG^5ETIm^
zgQwMr?;=GkrTLw+t2yCw>lg3c)%~&VdXBEVH}T3sXyjC3qjs3R%qk<dGmv?k{?jk9
zb$3{M)wWr}P`90IewPxng<Y=KPT{r68qB!iE4bg7Kl{YtBG5NzmgtgO0d3_t(Mzeo
z{`idQ-@Vg5kh>#t=9V56?czs#@h}xFS{Jj|@!NTF=cW9?Wqpx{W*OT{OuRMoFM9Kr
z;Fvj=;cuCY&N29j(|j+Z<9{eTdV3s5ld8)xL_Blyh7`8h_n6G{O--6qR4i!7UEXnP
zmKhfR)UdvlpE^{9rP-G$t<G~Fc-UTAX#UeCFvG|~hQwHczn)V20baRL-bd!Ah<WTw
zlCj)sJ1wk`2su{RU_D)BtJWzngYp!0jF<3G{G{Sri!oNNx@FZ2RtQS)@?-fL5i@fN
z53lx6V+m>)!d%109VNeDu|+Gs4*dIhT9Y|vj7ESw^k3h-t`v~BG6J+}IBsS>2gFT=
z2TeI>Uoug!Fednlt30$5PE{T7Rbuw`w&=s8f==%sI;Y0sBR;QRLts+11s9BkT>_24
z{^lyF!|vkmd%(mVnY~>#!(1J`b?7q!$vP`4R27n6YGcnOOa;(~kZWl>o3dR+((Kb`
zG^~FL(5RwSHn#p?$*4B#A%f0>DPG|)WbPvo(Y#+x%e$RUjd$8YbFV&eb&Q*zbAbHh
zBmoo-+Ad9o?ZK2xkpOl4P_6x^bYRH8lqm{#MyI=SKQ$evemhxbMDqUdJyB3?*mza8
zF?8ld?s~kBKwU7hM@$C6w-(=PmMp4nEozV%50NE{aBP}j1_(<YCl15J<32~CP;%#n
zh7aeK1hn!hY<U@?p~n?FeBxLpv>!#pTd}ed>&?w6*dQptZ!?Wg136u6IgzeV-14$C
z7`_{ibxRu>`shUZg&0#=8Djze+V_RE2)p)SGeevJ!plRqV-R?Z5~V1n4qLx#@y&T_
zV2gQIh=lr>`Fyj4@+Mo-<-LLdaA}PAB7Z`g>zfr4X>Op$0LdE~UnC+_Wr-WNxgx4R
zZpO;f1M>qu9ZpTf179wfo@1V>hh9&Scl(;-_oO&q_Js-Zc~W#%iPCtiYY>w+Z&+BD
zow+n6g7a_cW^{^>Xvor6lM!<#(cL?zQl9|#ttF<~am=D>UF&pNtj_da@qLB#!Ulcq
z_AiaN^xMbM0#d~$qY2|M%?*VL9^k+)iUfi4lF@|p9T)6f8~g2!1rN0r|MNUI3!A%l
zVlL{teQGfEWva!HI<-BisQU1Yb&qmGYLbk!BkvvWRW}Yo%EDQ0Nwk|iDsqK+6M{m@
z-AyodJr3H|u;2an$6yo$v`2;Gi<*sGW#<ghqYm<*orNp+q?2?UM2^liN0rKiao%`H
zcoZEHS-j(+=gPwpK8^e$A%f777Y+~X=NO#3-xhhXvRfA%#>$Q`NF*n=W<R>(Wm&M@
z`L_B4KfzK}zcK%g>-BB!-QW`7t5~uwS+Iza6k1*88o{9xdFAdO(8ppW>>n@Wx>w&o
zFA`ogmBhVeUze)pi2g=|^4z@xbVndp_(pP1_;G0uamY{|aawm{1;<NKe1lxZKo9$;
z@1kNJ$m1V|z}TK1P3EMLrae>XPG8B#&9mGB1Gn&h6Jn|kErPK{Hj}Cn^?)<T7c+SF
zL4XR<cg>>s6w>a`KgpY(dBe1T(L}-)eLm-<?YDpRjtA%g`#d`SdC$W8LhkfCc}dq(
z%eXK`SCfZH`3D~Q(ZWcv6%wC7cLv1gWSr8m-FSF`JL>=&;79{bKiPGI-L3AxGwQ{w
zT)f9-A!w!&F3I{@j>0|_!|^c3{;Afvd3Q`q8W$&qA({FHx6bJRi%+!3YZu$+TX&hV
zl%5?elJG{dFeH?DC!VC^os3t7s;J$W^Z{W}=65B@nBN=8KDIQp?b^szlzLs-(Jo3|
zL^PSx?VSkYej5M{#Ghz-9FwT<7cnL!)V`P<$#McuKloY6t7_7ro8B!lSWZ8f1l9|0
z<I2}u?%-_R{&bW}?-w@jx6<-BwpJC;#C##!mw4H#oi6A4+*tmiw_dy9&+d^pGR;am
zHNKqz$Id`?CjI#*vH_Rd=s{iZbaNuC&(bq?mRzh79McN<@T_vKu;)QEDJuaS)A3WU
z%{79;w*7R*kL)z5Y5Ya7_wbV!@<6?10u(2@hdB59J#J+s{`C!B)U^<|BvAxyo?war
zd#Lik{-p;N8~{+4yZ9Y8Bd}QQ2prm!V;3<f_&h?xOe#EivxmCel-oAa1NuXW=}Qoq
zqZIvIBflOpox|JL$U|RAT!Y5|PF6h`$I;Go!}c+gxH*!+x3t@f;>Q?55M~Yx2Z`ea
z@5GtXZ3R5{xQ3!c2+oi}E1G_t{xzSbS@`aJc<shKD$2dQP5Q(sF&|#I*<mj<FC_Mq
z+-sFvk;*{Qcbg6vf9S1=3|JfP>zAQ-c&|wEyof}#(h@1RG|_QO&<EKUFmI%!6LFUo
zi?ptk)`JjEOJwWH+FvVBudGm|f6z;4`EuGS(n|T^EjYem)G&y#Iq0ZAu(^a{>{;LS
zH7-gZ0pLnzLorf<+eLuuc!XcQlZ%NncIx@Z)nNn_G9v@ocaf%HsC;y=fP8nMLF=MG
zLpFnXS@3u<iyPnh#I2eyJl$SO*+2(4n4IYFQRxQV60ye0?_MZEXx}@Dxgvjmufl!!
zey6b}g^&OV0akw3l|$Wm+XX29-uR^mF)2jD`nKI^pKz#{FLQINfIQ|P)zcM{4mzm!
z=$&}akRplLg#T*!O<fBl$S?<*jLGOZ6n*mSuwHpYxpiWK7Z<S5e2!J9kZt2gLsiK{
zmm~I897GCj@$)5YXj)la_-*E2`4@9*R&8}P>ytdhV_!8_w0D%$9Xs9lPNxeljz3R*
zx!@47z+^pbB{_gZu$|zWR$p5EMYQ(@f5x2E2=+k-aeIkrQI$Vr3^SXe$c&|Zwu(w)
zpEX!fc7NsLmVh2@w#+`Q+Ajq-+z=73rvd&wxTlk|3;s$SUI|-H=t%Ze-Iscg)M4^8
z7ryF!^)q8J9`{?A&0Ch4P09Nf(^W~>QEe7{io^~o3IVE%P&AhkJ8=aZ<{DH6xa}lV
z`d6IqN*22d$;mxq)By+GtCyYnNtWK1U0aXOspbljIFSUls5O%u&p|A8=4VPqZNSFx
z@yh+6bzZyyIKLTPPPC>z)Z5l}pM3Q`{A4{e=nOt=z~04Zdp<H@c61E|J4s%j{aL-8
zQ5`w;GaDqPqNk<XPB0V?yu>(_yge&)T2>c%`Ejb8(ck-WBuz3P$adca0a`9#D^yUK
zKZ|Tg?9ABwL9&V+aTmZ#m*atW87bhzl)DFP`g<dT@$Ahr0w7tw4mhbZ!(3r4QA#fD
z-Tw5Z=$bJBqq8DSj&knR0rw4<CENfRQI1g$+@vGtf>;2lvyHb9Unx>uKkQ__NC})p
zo`b!NNJp%X2t-em_6BE3j%e`)dZK^>>A?Gk<^*#tIwA}2brR3^`TsOwdFOrmTkavC
zF#ikOZ1#Kwr>jD7i1+S((nr}OtD}^9B|k>s!s%kveinC^^O1l6h>NJ<>C1}-**P9z
z*cI;d#{!+o%@MkjPVAJ)xS+^JH*sNufsg%3#Jo@sap-=EWSPNa?2zT;{g<eu3p?6P
zSc?4P1a*MZvGbNkDu?TQ5JDkj5$*hPos;<lEn!{_c)BwYEX!;U8>6UTUmx)BhdC;2
z&KDG(I0u2o{2FV%u_<D<h0bAw@9Q|OZQeL<%NpwaPQW`m_hSPZKT1?A{Z24wyboaK
zFniWm^LW=Q8P2BI=qXxVdUNiFX>E8Nx<AN?q*Jl^S5%~eJwG%F{t-fqc$61mZSanE
zfpwJUv#_=#mnp)}<gY^F%3~AeAZrTj`5LCS1UhEA3%?)D>6&-XVAa@yl~j)xaiJr=
zCL-6tPBFu#y??^@H$ppR;Rey*$Y12%=h3C%J&Xl~-g`fLGbOL@3MCkk8*hJ&%#QdH
zJE1Ic&)i&HqMUk4RQkEjmU|I<dR#wV*5kbe=r*?R;sqXlUl$lSY29IaICL@&IT){&
zd_c>19*0uzG|Z8H>m-SGHntnse%aKU>3=pOiX|%g;6FHM{NOsdl4}BRwl;Nq=o0Ke
zo6Z%5IKA3`7?wqmJn}czX**Q;(|^irK6v)AfVhe>=+Y!hg74*?|MjQk3Q>B=mAm_S
zC-dDHhjC=@J;M84@S~ysRFcG;@S8n@R!-#P)-(4%K``TcXCD3^WCp_(q8ry3WHA9G
zi%F`&t9t1aFu_sxR=4AVqv+3JHg2!md=W_zBHC}=z$dVAjNG63Dy!36Gh+AGWu#ef
z3=_YLZt#xisGO%`Z}%!(sb<?@Qo{)LDDM>b@KAYIfwD1f;xpzybtNip+;tZ9oTQ`q
za>4|5*(on{&sGu{ij8C43b+nBCNb83?s@GGSj#V@hHp8|w!?Q+F-C5)_Tk$}@KtL6
z#-;A=%9Cby&Vcz!aiI5k&ytiXX{TaG0pb7~t~U72D6zTXXc6F&b2jUNGoY3AcRiP-
z0}{6wqv_V5W#wbj=^q2{>h+%)4_UCC?ktN);?8`MEbJKn!}=y8(Lqm&``<CvfluQh
znbat6P;_M$oOuL(5HBi@2JA#;X|#!Fh54%v7rIMg8a?Rl<3xqM4nmBf%Vo)SkH;ct
zWX99w(^|~jT{(5T%|mwpuao%$Gk~Jp?<j@$)VmTzYK)-y)~(rl5HSP}V3R@jBMCRo
zyPu>QuWIe7PZr^#gO{y*#OaO5fQnO2)Egj}Yw@mhVfO)kCprsQTXr%b7rLLHrIgIT
zM>3T$v=z9l>43{^7M}(_Ju(6+N~w+Sx%ewZ1BtVq>YYO2_jWrjh3yREzZGM;9BQA~
ze9yh71&<~Bi8(-A#d1b#Cf{JjM`1CBk5_R{92FKjxD$Uz$kd$s(;><w36<Z&viF<F
z(Wk@F4xaN|u^Fx#aJbDRLJQJ&_5Or<a){R-USF;n$YJNs5@Tc%QZLj)7w7<*rEmP`
zT{f;KR2><~MkU0jy@*fzk8f*7#atA1JngM{-T*q~_B>(IuOU2b&HfJtKMl_Joq`>;
zN+FeXDHGm3mRan*_C`Io1WOrG(2B$Uw}z5U3Ba{tt`Bw2wmy*g(uORx?Xc^O;L{Gb
znvHt<4xe+3hSfXIGvL$e=C7bwiHL2C7qTin0viUcb2P9IR}X3dR9?STZBNCXf;8ab
zv9;Xz2+LR2J3*Wkv`}?9X}|@Y?#Vh`sz1If#A&;JB7aIfGE+iD1w`HojeGl7vrop|
zcc?#U?#ZJB-H+#kUEH`GPL?yO+Y1_+i~v>M_MfI56kl1X_}wEo1}lcXG{Udh8C4pM
z2Qwq;l4|O!NDVqYi9p>3W+OH?Z2^z=yl$bHbJzJ8XEWAlvvD|tBh-cR?FW56JG9K^
zE$FQen|qt8@E-7!i|=UV<3xVPlPP!Qi$TP)`9D)gYm82$pmABy)>z~zYLe=Q1FBBN
zpeu`0lNC@E3Kq3w-OE-;9ah6x<IZQfO{tlE7Tf^GUc#UYRmm0YnC?>WVJScg23V9#
z__QMmaK8LgbWKPdOza7WTrgU63?wy5QTE4Ml#FfE`H*P2y5P!N*9ZUz(uD;)$2)$X
zL2I9r_@OTQkwIo1uPPwab2mB-Yn)=-xCK5te%E3A8pG4ZNq&X$wh4ptQK+qDd;L9*
zFe7BPojmXc9Q5I)mxu&U%qsAl`a%?Scyk&t+nqhAd<-&yCm;@hrK=437OuN-3I#h~
zhU#>{*udt`oQC~P;SH+mJAdXbQe-<G6#IK>l}(^t^btW&M*ljGUh9slkDHsF!-&+Y
z;mh@PPMhpVij7yEXNu5{h%~&loj<CNi_MBo7)c${byc#Dm1pB9KL+7P#g)_RJM@ir
zRp)G~S$CuLw!9W_VzmK{aN^7-uZ}Pd@Wu{`$$i9Kc~B!OCGaVwc{J#bWyznETD+?E
z9<gfIlDJ|t;9P_2<KeK{)co?wr0F)A3)T9oQ&8PE|9=gX%Qbj)JW0^zdTd9_4}qsn
zFG=rnLHE_W6?ys9M%VqrhSdP5$%grP2DfBM)_cRz1WVr%9rQ;he(`I^d9H(sz}ty6
zJjuIKy!Oip!jLB+3_}xfw~hVrC!gbqQ;xRV!YqvJhhM70Pmj5`SF`X7`BPXm{LdVH
z$9*)lrNQ;soV?THNk(qaeb;aeP}R8YdgJhvYt&QRk5#)Zz70+64(}A6H3?qvm-60V
z{#AHSKQSJ7n*?tNJYDz7dQ1}h%v=%ZeKlQb8=HsAY(Q`SCvbZL&-flMOX2`VbNXm>
zLQObcP;F^jd=~KSJwuK=?5-)`;hH|^R{ZEbe(3JTq1T|n83^qP1#tm;yEp)2$f}O=
z_-8A>Gq=NEOlkzUh)O&gTKNr5+Rf7Cbvu|01u-|Ebc(Xj9s`CJ&uPyfTQ#D8MMt(z
zW=5(!*K841{L_9~N9#6TyY&(-<=F_wH*ITMU>$%8qoe^vkM0Ad3gn%3uP0@sPKUNr
z>+KPJ7A$CIVn)+ZP{R9ZG|*=e0=(mtm&?!nFJLiWXd^$^S7{;<e#qr?ceAR&^Ch@D
zRH88Gunvxxs3xg>i7$;|Js77qHB^ML@h#e5#ZzzoQL>7{!vUttAUrsXu#pl*{dBdl
zx@!{ki{o>cKrF&(gAsj(UQV4pNzGe$Qf0I}YxTfF(=vB_CRZ08Z!Eq8Kfg~2Ti!(a
z&t4&7UTF$a`mppO3}JQqeTUlUA`svh!gXXg<dzI(iTRi7r~~fMe<<#_>lK~*=qva<
zpHI=NU4PIihj83V9pL~ECUP8i6lWyE;XlsCUO-+`;<8u`PGoRYgPQ{vt1PhuQRo(4
zD%cCUAPQ#99^a~VKy3{lpCIhUi>?Mk54#w*Uf?HS6NjT-Ye?1UXrSs%$_39~KbS$m
z@yYveru^wsgXa@T$I^E4<6y%h><y=|!Fdam=y--J=-?Ly#Bq7xujP`noi+y;G&rK2
z^~tsv!!wxu$f6ZOWuJ#V84wq`v;WJ<N9wwXKnUm$IoXc2*$?vMqtMdnt4Bad2ebMV
z<fY~0;yX7z{vTn4|6(Hkw_wHpKSUN2a6w^Vd+poamo-DedVe{X0ukp})2>#R@J)8a
zK3D_+^MBfGwh}7DenI8^+rJMVSY~&7JH1IM>bX>p$dws(Qq!Wh6H(r~^cE4XK1@J>
zizg|**iz-%wG4y=;{jHPVQE)??|7|ybV}{C+zkDNL2dZYuN7fWma#JsJksTEugFvQ
zvw5>amvp+Hh#D^o-UcxLZvyH6wEq7AbDr6~Ax2c&hT~LnWFS56FE(wH+j<5&?Mpdc
zvJXPAV*e`@JZuU>w0{YOb$B71n(JHK-{C7KSGWFA(W!^!A9UMG)(*+oAoHKEaPq_Z
zm9at8KX|yipe1|HKV;bj?0;yo0^hVB!eIaQxw=*=1Gf>cPH=;`RX$E5t}F*9CVosH
z{q2cR$CWSu=~J3hu*|7-ntW-1#i>pQ^4b%IGIeOcEI0*`ZWloA{#MuB+zAM@baV%}
z1D&}XExlZ6IA~;TT%CZn9ze^|hyg?~#=pfZKDk?pn7djc{s260xOq6<2y*ZUYw~c5
u@bilBBQE(w-n<cv+Hm_10zfAVTPvUcTHxKd{wP8K@ZqhBT!oD3m;VLw7?KnK

literal 0
HcmV?d00001

diff --git a/doc/design/assistant/sshpassword.mdwn b/doc/design/assistant/sshpassword.mdwn
new file mode 100644
index 0000000000..59f981bb16
--- /dev/null
+++ b/doc/design/assistant/sshpassword.mdwn
@@ -0,0 +1,65 @@
+Currently the assistant sets up dedicated ssh keys, that can just use
+git-annex. This is ok. The problem is that the initial 2 connections to the
+ssh server when setting up these keys involve a password prompt, which is
+done at the console unless the system happens to have a working ssh agent
+that can pop up a dialog. That can be confusing.
+
+It would be nice to have the webapp prompt for the password. Can it be done
+securely?
+
+This might come down to a simple change to the webapp to prompt for the
+password, and then rather a lot of pain to make the webapp use HTTPS so we
+can be pretty sure noone is sniffing the (localhost) connection.
+
+## ssh-askpass approach
+
+* If ssh-askpass is in PATH, or `SSH_ASKPASS` is set, do nothing.
+  (Unless webapp is run remotely.)  
+  XXX not currently done; the UI would need to omit the password entry
+  fields in this case.
+* Otherwise, have the assistant set `SSH_ASKPASS` to a command that will
+  cause the webapp to read the password and forward it on. Also, set
+  DISPLAY to ensure that ssh runs the program. **done**
+
+Looking at ssh.exe, I think this will even work on Windows; it contains the
+code to run ssh-askpass. (It does work on Windows!)
+
+### securely handling the password
+
+* Maybe force upgrade webapp to https? Locally, the risk would be that
+  root could tcpdump and read password, so not large risk. If webapp
+  is being accessed remotely, absolutely: require https.
+* Use hs-securemem to store password.
+* Avoid storing password for long. Erase it after webapp setup of remote
+  is complete. Time out after 10 minutes and erase it. **done**
+* If the user is slow, the cached ssh key can exire before they finish.
+  This results in ssh being given no password, and failing. The UI
+  now detects this and suggests the user retry. **done**
+* Prompt using a html field name that does not trigger web browser password
+  saving if possible.
+
+### ssh-askpass shim, and password forwarding
+
+`SSH_ASKPASS` needs to be set to a program (probably git-annex)
+which gets the password from the webapp, and outputs it to stdout. **done**
+
+Seems to call for the webapp and program to communicate over a local
+socket (locked down so only user can access) or environment.
+Environment is not as secure (easily snooped by root).
+Local socket probably won't work on Windows. Could just use a temp file.
+
+(Currently uses a temp file with locked down perms that it's careful
+to clean up after use.)
+
+Note that the webapp can probe to see if ssh needs a password, and can
+prompt the user for it before running ssh and the ssh-askpass shim.
+This avoids some complexity, and perhaps some attack vectors,
+if the shim cannot requst an arbitrary password prompt.
+(This complexity not needed with the temp file approach..)
+
+### TODO
+
+* test on OSX
+* test on Android
+* remove the vestigial terminal on Windows and Android, since this was the
+  last thing actually using it (not easy!)
diff --git a/doc/design/assistant/sshpassword/comment_1_24399abe0a0c1de271490ee15e064760._comment b/doc/design/assistant/sshpassword/comment_1_24399abe0a0c1de271490ee15e064760._comment
new file mode 100644
index 0000000000..e71806fa29
--- /dev/null
+++ b/doc/design/assistant/sshpassword/comment_1_24399abe0a0c1de271490ee15e064760._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
+ nickname="Matt"
+ subject="comment 1"
+ date="2014-04-29T10:10:04Z"
+ content="""
+Can you do something similar for gpg-agent?  Or do it instead with a ssh supported gpg-agent?
+"""]]
diff --git a/doc/design/assistant/sshpassword/comment_2_36a811bca209c7ac8a44d64bf8bc5bf3._comment b/doc/design/assistant/sshpassword/comment_2_36a811bca209c7ac8a44d64bf8bc5bf3._comment
new file mode 100644
index 0000000000..8d9925af2e
--- /dev/null
+++ b/doc/design/assistant/sshpassword/comment_2_36a811bca209c7ac8a44d64bf8bc5bf3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="216.145.95.162"
+ subject="comment 2"
+ date="2014-05-19T15:47:19Z"
+ content="""
+I don't feel comfortable prompting for gpg passphrases in the webapp. See [[gpgkeys]] for thoughts on this.
+"""]]
diff --git a/doc/design/assistant/syncing.mdwn b/doc/design/assistant/syncing.mdwn
new file mode 100644
index 0000000000..df9a771b13
--- /dev/null
+++ b/doc/design/assistant/syncing.mdwn
@@ -0,0 +1,220 @@
+Once files are added (or removed or moved), need to send those changes to
+all the other git clones, at both the git level and the key/value level.
+
+## misc TODO
+
+* Test MountWatcher on LXDE.
+* Add a hook, so when there's a change to sync, a program can be run
+   and do its own signaling.
+* --debug will show often unnecessary work being done. Optimise.
+* Configurablity, including only enabling git syncing but not data transfer;
+  only uploading new files but not downloading, and only downloading
+  files in some directories and not others. See for use cases:
+  [[forum/Wishlist:_options_for_syncing_meta-data_and_data]]
+* speed up git syncing by using the cached ssh connection for it too
+  Will need to use `GIT_SSH`, which needs to point to a command to run,
+  not a shell command line. Beware that the network connection may have
+  bounced and the cached ssh connection not be usable.
+* Map the network of git repos, and use that map to calculate
+  optimal transfers to keep the data in sync. Currently a naive flood fill
+  is done instead. Maybe use XMPP as a side channel to learn about the
+  network topology?
+* Find a more efficient way for the TransferScanner to find the transfers
+  that need to be done to sync with a remote. Currently it walks the git
+  working copy and checks each file. That probably needs to be done once,
+  but further calls to the TransferScanner could eg, look at the delta
+  between the last scan and the current one in the git-annex branch.
+* [[use multiple transfer slots|todo/Slow_transfer_for_a_lot_of_small_files.]]
+* The TransferQueue's list of deferred downloads could theoretically
+  grow without bounds in memory. Limit it to a given number of entries,
+  and fall back to some other method -- either storing deferred downloads
+  on disk, or perhaps scheduling a TransferScanner run to get back into sync.
+
+## More efficient syncing
+
+See [[syncing/efficiency]]
+
+## TransferScanner efficiency
+
+The TransferScanner thread needs to find keys that need to be Uploaded
+to a remote, or Downloaded from it.
+
+How to find the keys to transfer? I'd like to avoid potentially
+expensive traversals of the whole git working copy if I can.
+(Currently, the TransferScanner does do the naive and possibly expensive
+scan of the git working copy.)
+
+One way would be to do a git diff between the (unmerged) git-annex branches
+of the git repo, and its remote. Parse that for lines that add a key to
+either, and queue transfers. That should work fairly efficiently when the
+remote is a git repository. Indeed, git-annex already does such a diff
+when it's doing a union merge of data into the git-annex branch. It
+might even be possible to have the union merge and scan use the same
+git diff data.
+
+But that approach has several problems:
+
+1. The list of keys it would generate wouldn't have associated git
+   filenames, so the UI couldn't show the user what files were being
+   transferred.
+2. Worse, without filenames, any later features to exclude
+   files/directories from being transferred wouldn't work.
+3. Looking at a git diff of the git-annex branches would find keys
+   that were added to either side while the two repos were disconnected.
+   But if the two repos' keys were not fully in sync before they
+   disconnected (which is quite possible; transfers could be incomplete),
+   the diff would not show those older out of sync keys.
+
+The remote could also be a special remote. In this case, I have to either
+traverse the git working copy, or perhaps traverse the whole git-annex
+branch (which would have the same problems with filesnames not being
+available).
+
+If a traversal is done, should check all remotes, not just
+one. Probably worth handling the case where a remote is connected
+while in the middle of such a scan, so part of the scan needs to be
+redone to check it.
+
+## done
+
+1. Can use `git annex sync`, which already handles bidirectional syncing.
+   When a change is committed, launch the part of `git annex sync` that pushes
+   out changes. **done**; changes are pushed out to all remotes in parallel
+1. Watch `.git/refs/remotes/` for changes (which would be pushed in from
+   another node via `git annex sync`), and run the part of `git annex sync`
+   that merges in received changes, and follow it by the part that pushes out
+   changes (sending them to any other remotes).
+   [The watching can be done with the existing inotify code! This avoids needing
+   any special mechanism to notify a remote that it's been synced to.]  
+   **done**
+1. Periodically retry pushes that failed.  **done** (every half an hour)
+1. Also, detect if a push failed due to not being up-to-date, pull,
+   and repush. **done**
+2. Use a git merge driver that adds both conflicting files,
+   so conflicts never break a sync. **done**
+
+* on-disk transfers in progress information files (read/write/enumerate)
+  **done**
+* locking for the files, so redundant transfer races can be detected,
+  and failed transfers noticed **done**
+* transfer info for git-annex-shell **done**
+* update files as transfers proceed. See [[progressbars]]
+  (updating for downloads is easy; for uploads is hard)
+* add Transfer queue TChan **done**
+* add TransferInfo Map to DaemonStatus for tracking transfers in progress.
+  **done**
+* Poll transfer in progress info files for changes (use inotify again!
+  wow! hammer, meet nail..), and update the TransferInfo Map **done**
+* enqueue Transfers (Uploads) as new files are added to the annex by
+  Watcher. **done**
+* enqueue Tranferrs (Downloads) as new dangling symlinks are noticed by
+  Watcher. **done**
+  (Note: Needs git-annex branch to be merged before the tree is merged,
+  so it knows where to download from. Checked and this is the case.)
+* Write basic Transfer handling thread. Multiple such threads need to be
+  able to be run at once. Each will need its own independant copy of the 
+  Annex state monad. **done**
+* Write transfer control thread, which decides when to launch transfers.
+  **done**
+* Transfer watching has a race on kqueue systems, which makes finished
+  fast transfers not be noticed by the TransferWatcher. Which in turn
+  prevents the transfer slot being freed and any further transfers
+  from happening. So, this approach is too fragile to rely on for
+  maintaining the TransferSlots. Instead, need [[todo/assistant_threaded_runtime]],
+  which would allow running something for sure when a transfer thread
+  finishes. **done**
+* Test MountWatcher on KDE, and add whatever dbus events KDE emits when
+  drives are mounted. **done**
+* It would be nice if, when a USB drive is connected, 
+  syncing starts automatically. Use dbus on Linux? **done**
+* Optimisations in 5c3e14649ee7c404f86a1b82b648d896762cbbc2 temporarily
+  broke content syncing in some situations, which need to be added back.
+  **done**
+
+  Now syncing a disconnected remote only starts a transfer scan if the
+  remote's git-annex branch has diverged, which indicates it probably has
+  new files. But that leaves open the cases where the local repo has
+  new files; and where the two repos git branches are in sync, but the
+  content transfers are lagging behind; and where the transfer scan has
+  never been run.
+
+  Need to track locally whether we're believed to be in sync with a remote.
+  This includes:
+  * All local content has been transferred to it successfully.
+  * The remote has been scanned once for data to transfer from it, and all
+    transfers initiated by that scan succeeded.
+
+  Note the complication that, if it's initiated a transfer, our queued
+  transfer will be thrown out as unnecessary. But if its transfer then
+  fails, that needs to be noticed.
+
+  If we're going to track failed transfers, we could just set a flag,
+  and use that flag later to initiate a new transfer scan. We need a flag
+  in any case, to ensure that a transfer scan is run for each new remote.
+  The flag could be `.git/annex/transfer/scanned/uuid`.
+
+  But, if failed transfers are tracked, we could also record them, in 
+  order to retry them later, without the scan. I'm thinking about a
+  directory like `.git/annex/transfer/failed/{upload,download}/uuid/`,
+  which failed transfer log files could be moved to.
+* A remote may lose content it had before, so when requeuing
+  a failed download, check the location log to see if the remote still has
+  the content, and if not, queue a download from elsewhere. (And, a remote
+  may get content we were uploading from elsewhere, so check the location
+  log when queuing a failed Upload too.) **done**
+* Fix MountWatcher to notice umounts and remounts of drives. **done**
+* Run transfer scan on startup. **done**
+* Often several remotes will be queued for full TransferScanner scans,
+  and the scan does the same thing for each .. so it would be better to
+  combine them into one scan in such a case. **done**
+* The syncing code currently doesn't run for special remotes. While
+  transfering the git info about special remotes could be a complication,
+  if we assume that's synced between existing git remotes, it should be
+  possible for them to do file transfers to/from special remotes.
+  **done**
+
+* The transfer code doesn't always manage to transfer file contents.
+
+  Besides reconnection events, there are two places where transfers get queued:
+
+  1. When the committer commits a file, it queues uploads.
+  2. When the watcher sees a broken symlink be created, it queues downloads.
+
+  Consider a doubly-linked chain of three repositories, A B and C.
+  (C and A do not directly communicate.)
+  
+  * File is added to A.
+  * A uploads its content to B.
+  * At the same time, A git syncs to B.
+  * Once B gets the git sync, it git syncs to C.
+  * When C's watcher sees the file appear, it tries to download it. But if
+    B had not finished receiving the file from A, C doesn't know B has it,
+    and cannot download it from anywhere.
+
+  Possible solution: After B receives content, it could queue uploads of it 
+  to all remotes that it doesn't know have it yet, which would include C. 
+  **done**
+  
+  In practice, this had the problem that when C receives the content,
+  it will queue uploads of it, which can send back to B (or to some other repo
+  that already has the content) and loop, until the git-annex branches catch
+  up and break the cycle.
+
+  To avoid that problem, incoming uploads should not result in a transfer
+  info file being written when the key is already present. **done**
+
+  Possible solution: C could record a deferred download. (Similar to a failed
+  download, but with an unknown source.) When C next receives a git-annex
+  branch push, it could try to queue deferred downloads. **done**
+
+  Note that this solution won't cover use cases the other does. For example,
+  connect a USB drive A; B syncs files from it, and then should pass them to C.
+  If the files are not new, C won't immediatly request them from B.
+
+* Running the assistant in a fresh clone of a repository, it sometimes
+  skips downloading a file, while successfully downloading all the rest.
+  There does not seem to be an error message. This will sometimes reproduce
+  (in a fresh clone each time) several times in a row, but then stops happening,
+  which has prevented me from debugging it.
+  This could possibly have been caused by the bug fixed in 750c4ac6c282d14d19f79e0711f858367da145e4.
+  Provisionally closed.
diff --git a/doc/design/assistant/syncing/comment_1_c70156174ff19b503978d623bd2df36f._comment b/doc/design/assistant/syncing/comment_1_c70156174ff19b503978d623bd2df36f._comment
new file mode 100644
index 0000000000..019490e619
--- /dev/null
+++ b/doc/design/assistant/syncing/comment_1_c70156174ff19b503978d623bd2df36f._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk4YX0PWICfWGRLuncCPufMPDctT7KAYJA"
+ nickname="betabrain"
+ subject="selective data syncing"
+ date="2012-07-24T15:27:08Z"
+ content="""
+How will the assistant know which files' data to distribute between the repos?
+
+I'm using git-annex and it's numcopies attribute to maintain a redundant archive spread over different computers and usb drives. Not all drives should get a copy of everything, e.g. the usb drive I take to work should not automatically get a copy of family pictures.
+
+How about .gitattributes?
+
+* \* annex.auto-sync-data = false # don't automatically sync the data
+* archive/ annex.auto-push-repos = NAS # everything added to archive/ in any repo goes automatically to the NAS remote.
+* work/ annex.auto-synced-repos = LAPTOP WORKUSB # everything added to work/ in LAPTOP or WORKUSB gets synced to WORKUSB and LAPTOP
+* work/ annex.auto-push-repos = LAPTOP WORKUSB # stuff added to work/ anywhere gets synced to LAPTOP and WORKUSB
+* important/ annex.auto-sync-data = true # push data to all repos
+* webserver_logs/ annex.remote.WEBSERVER.auto-push-repos = S3 # only the assistant running in WEBSERVER pushes webserver_logs/ to S3 remote
+"""]]
diff --git a/doc/design/assistant/syncing/comment_2_eb992b5b2c7a5ce23443e2a6007e5ff9._comment b/doc/design/assistant/syncing/comment_2_eb992b5b2c7a5ce23443e2a6007e5ff9._comment
new file mode 100644
index 0000000000..a4609d7e19
--- /dev/null
+++ b/doc/design/assistant/syncing/comment_2_eb992b5b2c7a5ce23443e2a6007e5ff9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnBl7cA6wLDxVNUyLIHvAyCkf8ir3alYpk"
+ nickname="Tyson"
+ subject="Bridging LANs"
+ date="2012-07-10T10:20:59Z"
+ content="""
+Why rely on the cloud when you can instead use XMPP and jingle to perform NAT traversal for you? AFAIKT, it also means that traffic won't leave your router if the two endpoints are behind the same router.
+"""]]
diff --git a/doc/design/assistant/syncing/comment_3_e1b5e8a24556de16d1cacd27ee0c1bd1._comment b/doc/design/assistant/syncing/comment_3_e1b5e8a24556de16d1cacd27ee0c1bd1._comment
new file mode 100644
index 0000000000..c9118595c9
--- /dev/null
+++ b/doc/design/assistant/syncing/comment_3_e1b5e8a24556de16d1cacd27ee0c1bd1._comment
@@ -0,0 +1,80 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2012-07-03T08:26:43Z"
+ content="""
+On \"git syncing\" point number 9, on OSX you could potentially do this on a semi-regular basis
+
+<pre>
+system_profiler SPNetworkVolumeDataType
+Volumes:
+
+    net:
+
+      Type: autofs
+      Mount Point: /net
+      Mounted From: map -hosts
+      Automounted: Yes
+
+    home:
+
+      Type: autofs
+      Mount Point: /home
+      Mounted From: map auto_home
+      Automounted: Yes
+</pre>
+
+and
+
+<pre>
+x00:~ jtang$ system_profiler SPUSBDataType
+USB:
+
+    USB High-Speed Bus:
+
+      Host Controller Location: Built-in USB
+      Host Controller Driver: AppleUSBEHCI
+      PCI Device ID: 0x0aa9 
+      PCI Revision ID: 0x00b1 
+      PCI Vendor ID: 0x10de 
+      Bus Number: 0x26 
+
+        Hub:
+
+          Product ID: 0x2504
+          Vendor ID: 0x0424  (SMSC)
+          Version: 0.01
+          Speed: Up to 480 Mb/sec
+          Location ID: 0x26200000 / 3
+          Current Available (mA): 500
+          Current Required (mA): 2
+
+            USB to ATA/ATAPI Bridge:
+
+              Capacity: 750.16 GB (750,156,374,016 bytes)
+              Removable Media: Yes
+              Detachable Drive: Yes
+              BSD Name: disk1
+              Product ID: 0x2338
+              Vendor ID: 0x152d  (JMicron Technology Corp.)
+              Version: 1.00
+              Serial Number: 313541813001
+              Speed: Up to 480 Mb/sec
+              Manufacturer: JMicron
+              Location ID: 0x26240000 / 5
+              Current Available (mA): 500
+              Current Required (mA): 2
+              Partition Map Type: MBR (Master Boot Record)
+              S.M.A.R.T. status: Not Supported
+              Volumes:
+                Porta-Disk:
+                  Capacity: 750.16 GB (750,156,341,760 bytes)
+                  Available: 668.42 GB (668,424,208,384 bytes)
+                  Writable: Yes
+                  File System: ExFAT
+....
+</pre>
+
+I think its possible to programatically get this information either from the CLI (it dumps out XML output if required) or some development library. There is also DBUS in macports, but I have never had much interaction with it, so I don't know if its good or bad on OSX.
+"""]]
diff --git a/doc/design/assistant/syncing/efficiency.mdwn b/doc/design/assistant/syncing/efficiency.mdwn
new file mode 100644
index 0000000000..18f0ca5012
--- /dev/null
+++ b/doc/design/assistant/syncing/efficiency.mdwn
@@ -0,0 +1,77 @@
+Currently, the git-annex assistant syncs with remotes in a way that is
+dumb, and potentially inneficient:
+
+1. Files are transferred to each reachable remote whose
+   [[preferred_content]] setting indicates it wants the file.
+
+2. After each file transfer (upload or download), a git sync
+   is done to all the remotes, to update location log information.
+
+## unnecessary transfers
+
+There are network toplogies where #1 is massively inneficient.
+For example:
+
+<pre>
+  laptopA-----laptopB-----laptopC
+      \         |             /
+       \---cloud based repo--/
+</pre>
+
+When laptopA has a new file, it will first send it to laptopB. It will then
+check if the cloud based transfer repository wants a copy. It will, because
+laptopC has not yet gotten a copy. So laptopA will proceed with a slow
+upload to the cloud, while meanwhile laptopB is sending the file over fast
+LAN to laptopC.
+
+(The more common case with no laptopC happens to work efficiently.
+So does the case where laptopA is paired with laptopC.)
+
+## unnecessary syncing
+
+Less importantly, the constant git syncing after each transfer is rather a
+lot of work, and prevents collecting multiple presence changes to the git-annex 
+branch into larger commits, which would save disk space over time.
+
+In many cases, this sync is necessary. For example, when a file is uploaded
+to a transfer remote, the location change needs to be synced out so that
+other clients know to grab it.
+
+Or, when downloading a file from a drive, the sync lets other locally
+paired repositories know we got it, so they can download it from us. 
+OTOH, this is also a case where a sync is sometimes unnecessary, since
+if we're going to upload the file to them after getting it, the sync
+only perhaps lets them start downloading it before our transfer queue
+reaches a point where we'd upload it.
+
+It would be good to find a way to detect when syncing is not immediately
+necessary, and defer it.
+
+## mapping
+
+Mapping the repository network has the potential to get git-annex the
+information it needs to avoid unnecessary transfers and/or unnecessary
+syncing.
+
+Mapping the network can reuse code in `git annex map`. Once the map is
+built, we want to find paths through the network that reach all nodes
+eventually, with the least cost. This is a minimum spanning tree problem,
+except with a directed graph, so really a Arborescence problem.
+
+A significant problem in mapping is that nodes are mobile, they can move
+between networks over time. This breaks LAN based paths through the
+network. Mapping would need a way to detect this. Note that individual
+git-annex assistants can tell when they've switched networks by using the
+`networkConnectedNotifier`.
+
+## P2P signaling
+
+Another approach that might help with these problems is if git-annex
+repositories have a non-git out of band signaling mechanism. This could,
+for example, be used by laptopB to tell laptopA that it's trying to send 
+a file directly to laptopC. laptopA could then defer the upload to the
+cloud for a while.
+
+## syncing only requested content
+
+See [[adhoc_routing]]
diff --git a/doc/design/assistant/telehash.mdwn b/doc/design/assistant/telehash.mdwn
new file mode 100644
index 0000000000..788074f961
--- /dev/null
+++ b/doc/design/assistant/telehash.mdwn
@@ -0,0 +1,136 @@
+[Telehash](http://telehash.org/) for secure P2P communication between
+git-annex (assistant) repositories.
+
+Or something similar like [Snow](http://www.trustiosity.com/snow/)
+or [cjdns](https://github.com/cjdelisle/cjdns) or tor or i2p or [magic wormhole](http://magic-wormhole.io/).
+
+## telehash implementation status
+
+* node.js version seems almost complete
+* C version currently lacks channel support and seems buggy (13 Jan 2014)
+* No pure haskell implementation of telehash v2. There was one of
+  telehash v1 (even that seems incomplete). I have pinged its author
+  to see if he anticipates updating it.
+* Rapid development, situation may change in a month or 2. (2014)  
+  Not seeing many commits now (2015)
+* Is it secure? A security review should be done by competant people
+  (not Joey). See <https://github.com/telehash/telehash.org/issues/23>
+* **Haskell version** 
+  <https://github.com/alanz/htelehash/tree/v2/src/TeleHash>
+  May support v2; v3 support seems not started yet, and not in active
+  development at the moment, although there has been work on it a year ago.
+* Not very convinced this is going to be usable anytime soon, so would like
+  to find something that is. (2015)
+
+## snow status
+
+* Seems ready to use?
+* NAT punching works per docs; relies on a DHT network for hole punching,
+  and the reliabilty of that network is not known. I notice it has only 1
+  pre-seeded peer in the source tree for the DHT, and that peer was not up
+  when I tried it.
+* Only provides network-layer transport, still need to implement some 
+  file transfer protocol on top.
+
+## cjdns status
+
+* Has a network with "hundreds of active nodes"
+* Is not pure P2P; there's a network that does routing
+  of packets. This may be a good thing, or not.
+* Seems to require manual configuration of a "friend"
+  node that's already on the network, with address and password to connect
+  to it, so if you can't find someone you know to connect to their node,
+  you can't use it. Urk.
+
+## tor status
+
+* Awesome.
+* Easy to install, use; very well known.
+* Supported in git-annex now!
+
+## i2p status
+
+## magic wormhole
+
+* simple file transfer protocol with out of band shared secret
+* handles NAT transversal
+* easy to use
+* doesn't require a running daemon
+* can transfer arbitrary blobs (strings, directories, files)
+
+## general design
+
+* There is a generic P2P protocol, which should be usable with any P2P
+  system that can send messages between peers.
+* A p2p remote has an url like tor-annex::fijdksajdksjfkj, which connects
+  to a specific peer. The peer's address may be kept private, but 
+  the design allows the address to be public without giving access to
+  the peer.
+* An authtoken also needs to be presented when connecting with a peer.
+  This is stored in local creds storage and must be kept private.
+* The remotedaemon runs, and/or communicates with the program implementing
+  the P2P network. For example for tor, the remotedaemon runs the
+  hidden service.
+* The remotedaemon handles both sides of git push over the transport.
+* The remotedaemon may also support sending objects over the transport,
+  depending on the transport.
+
+## address exchange
+
+The address is a public key, and the authtoken is some large chunk of data,
+so won't want to type that in. Need discovery or exchange for peering.
+
+* Easy way is any set of repos that are already connected can communicate
+  them via address.log.
+* Address and authtoken can be communicated out of band (eg,
+  via an OTR session or gpg encrypted mail or phone call),
+  and pasted into the webapp.
+* Use eg, electrum-mnemonic to encode the address+authtoken so that
+  it can be read over the phone.
+* Users may not have a way to communicate with perfect forward secrecy.
+  So it would be good to have a address+authtoken that can only be used
+  one time during pairing.
+* Check out [PAKE](https://en.wikipedia.org/wiki/Password-authenticated_key_agreement)
+  for MITM resistance.
+* Possibly use magic wormhole to exchange the address, which avoids
+  the users needing to exchange so much data. The magic wormhole code
+  is just 3 words, and it uses PAKE.
+  
+  I tried it, and opened a couple of bug reports that would be useful in
+  integrating it with git-annex:
+
+  - [option to receive to a specific file](https://github.com/warner/magic-wormhole/issues/101)
+  - [machine readable wormhole code ](https://github.com/warner/magic-wormhole/issues/104])
+
+## local lan detection
+
+At connection time, after authentication, the remote can send
+(ip address, ssh host key). Try sshing to the ip address to check if
+the host key matches. If so, can enable a ssh remote, which will
+be cheaper than using the transport. Send the ssh public key back to the
+remote to get it authorized.
+
+## remotedaemon
+
+See [[git-remote-daemon]] for its design.
+
+Advantages:
+
+* `git annex sync` could also use the running daemon
+* `git-remote-$transport` could use the running daemon
+* c-telehash might end up linked to openssl, which has licence combination
+  problems with git-annex. A separate process not using git-annex's code
+  would avoid this.
+* Allows the daemon to be written in some other language if necessary
+  (for example, if c-telehash development stalls and the nodejs version is
+  already usable)
+* Potentially could be generalized to handle other similar protocols.
+  Or even the xmpp code moved into it. There could even be git-annex native
+  exchange protocols implemented in such a daemon to allow SSH-less
+  transfers.
+* Security holes in telehash would not need to compromise the entire
+  git-annex. daemon could be sandboxed in one way or another.
+
+Disadvantages:
+
+* Adds some complexity.
diff --git a/doc/design/assistant/thanks/comment_1_8b08b5c30e5aea3fc4599f856fd25df5._comment b/doc/design/assistant/thanks/comment_1_8b08b5c30e5aea3fc4599f856fd25df5._comment
new file mode 100644
index 0000000000..77a0873ee4
--- /dev/null
+++ b/doc/design/assistant/thanks/comment_1_8b08b5c30e5aea3fc4599f856fd25df5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlUbH3eytydcwlWqv8oauE2Jg4NwcV9uA0"
+ nickname="Anna"
+ subject="Special"
+ date="2012-07-20T23:45:15Z"
+ content="""
+I feel pretty special getting an individualized thank you!  Btw, the good news is that your video finally explained what you were working on so that I understood it. :-)
+"""]]
diff --git a/doc/design/assistant/todo.mdwn b/doc/design/assistant/todo.mdwn
new file mode 100644
index 0000000000..2b369a2e2e
--- /dev/null
+++ b/doc/design/assistant/todo.mdwn
@@ -0,0 +1,4 @@
+This is a subset of [[/todo]] and [[/bugs]] 
+for items tagged for the assistant.
+
+[[!inline pages="tagged(design/assistant) and !link(bugs/done) and !link(bugs/moreinfo)" show=0 archive=yes]]
diff --git a/doc/design/assistant/transfer_control.mdwn b/doc/design/assistant/transfer_control.mdwn
new file mode 100644
index 0000000000..b0a14ed2b7
--- /dev/null
+++ b/doc/design/assistant/transfer_control.mdwn
@@ -0,0 +1,123 @@
+Some remotes are too small to sync everything to them.
+
+The case of a small remote on a gadget that the user interacts with,
+such as a phone, where they may want to request it get content
+it doesn't currently have, is covered by the [[partial_content]] page.
+
+But often the remote is just a removable drive or a cloud remote,
+that has a limited size. This page is about making the assistant do
+something smart with such remotes.
+
+## TODO
+
+* The expensive scan currently makes one pass, dropping content at the same
+  time more uploads and downloads are queued. It would be better to drop as
+  much content as possible upfront, to keep the total annex size as small
+  as possible. How to do that without making two expensive scans?
+* The TransferWatcher's finishedTransfer function relies on the location
+  log having been updated after a transfer. But there's a race; if the
+  log is not updated in time, it will fail to drop unwanted content.
+  (There's a 10 second sleep there now to avoid the race, but that's hardly
+  a fix.)
+
+### dropping no longer preferred content
+
+When a file is renamed, it might stop being preferred, so
+could be checked and dropped. (If there's multiple links to
+the same content, this gets tricky. Let's assume there are not.)
+
+### analysis of changes that can result in content no longer being preferred
+
+1. The preferred content expression can change, or a new repo is added, or
+   groups change. Generally, some change to global annex state. Only way to deal
+   with this is an expensive scan. (The rest of the items below come from
+   analizing the terminals used in preferred content expressions.) **done**
+2. renaming of a file (ie, moved to `archive/`) **done**
+   (note also that renaming a file can also make it become preferred content
+   again, and should cause it to be transferred in that case) **done**
+3. we get a file (`in`, `copies`) **done**
+4. we sent a file (`in`, `copies`) **done**
+5. some other repository drops the file (`in`, `copies` .. However, it's
+   unlikely that an expression would prefer content when *more* copies
+   exisited, and want to drop it when less do. That's nearly a pathological
+   case.)
+6. `migrate` is used to change a backend (`inbackend`; unlikely)
+
+That's all! Of these, 1-4 are by far the most important.
+
+## specifying what data a remote prefers to contain (**done**)
+
+Imagine a per-remote preferred content setting, that matches things that
+should be stored on the remote.
+
+For example, a MP3 player might use:
+`smallerthan(10mb) and filename(*.mp3) and (not filename(junk/*))`
+
+Adding that as a filter to files sent to a remote should be
+straightforward.
+
+A USB drive that is carried between three laptops and used to sync data
+between them might use: `not (in=laptop1 and in=laptop2 and in=laptop3)`
+
+In this case, transferring data from the usb repo should
+check if preferred content settings rejects the data, and if so, drop it
+from the repo. So once all three laptops have the data, it is
+pruned from the transfer drive.
+
+## repo groups (**done**)
+
+Seems like git-annex needs a way to know the groups of repos. Some
+groups:
+
+* enduser: The user interacts with this repo directly.
+* archival: This repo accumulates stuff, and once it's in enough archives,
+  it tends to get removed from other places.
+* transfer: This repo is used to transfer data between enduser repos,
+  it does not hold data for long periods of time, and tends to have a
+  limited size.
+
+Add a group.log that can assign repos to these or other groups. (**done**)
+
+Some examples of using groups:
+
+* Want to remove content from a repo, if it's not an archival repo,
+  and the content has reached at least one archival repo:
+
+  `(not group=archival) and (not copies=archival:1)`
+
+  That would make send to configure on all repos, or even set
+  a global `annex.accept` to it. **done**
+
+* Make a cloud repo only hold data until all known clients have a copy:
+
+  `not ingroup(enduser)`
+
+## configuration
+
+The above is all well and good for those who enjoy boolean algebra, but
+how to configure these sorts of expressions in the webapp?
+
+Currently, we have a simple drop down list to select between a few
+predefined groups with pre-defined preferred content recipes. Is this good
+enough?
+
+I think so; useful recipes can be developed on the wiki and included in
+git-annex.
+
+## the state change problem (**done**)
+
+Imagine that a trusted repo has setting like `not copies=trusted:2`
+This means that `git annex get --auto` should get files not in 2 trusted
+repos. But once it has, the file is in 3 trusted repos, and so `git annex
+drop --auto` should drop it again!
+
+How to fix? Can it even be fixed? Maybe care has to be taken when
+writing expressions, to avoid this problem. One that avoids it:
+`not (copies=trusted:2 or (in=here and trusted=here and copies=trusted:3))`
+
+Or, expressions could be automatically rewritten to avoid the problem.
+
+Or, perhaps simulation could be used to detect the problem. Before
+dropping, check the expression. Then simulate that the drop has happened.
+Does the expression now make it want to add it? Then don't drop it!
+**done**.. effectively using this approach.
diff --git a/doc/design/assistant/transfer_control/comment_1_d5adaef4712913dc0263d4ebafb79320._comment b/doc/design/assistant/transfer_control/comment_1_d5adaef4712913dc0263d4ebafb79320._comment
new file mode 100644
index 0000000000..54e6a59cc2
--- /dev/null
+++ b/doc/design/assistant/transfer_control/comment_1_d5adaef4712913dc0263d4ebafb79320._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2012-09-23T21:58:08Z"
+ content="""
+You could try to do it similar to [RT](http://bestpractical.com/rt/):
+
+* Implement saved statements, i.e. offer common use cases
+* Allow those statements (or aliases? stanzas?) to be loaded in a relatively simple editor with a basic wizard to support the building of new rules
+* Offer a free-text input for advanced users. It should be able to parse that and load it into the simple editor.
+* Users should be able to save, export, and import those statements.
+* Optionally, allow users to dry run the rules by showing them what git-annex needs to do to fulfill the requirements set by the statements.
+
+"""]]
diff --git a/doc/design/assistant/transfer_control/comment_2_3b51474fefa6c0d19055046e06af196d._comment b/doc/design/assistant/transfer_control/comment_2_3b51474fefa6c0d19055046e06af196d._comment
new file mode 100644
index 0000000000..ec53f7aacd
--- /dev/null
+++ b/doc/design/assistant/transfer_control/comment_2_3b51474fefa6c0d19055046e06af196d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnRRUUZo3W7pAoRoST8P_l0PtUBhvYuzDg"
+ nickname="Lyle"
+ subject="exactly this use case: cloud remotes too small"
+ date="2014-01-06T00:31:34Z"
+ content="""
+I want to store a lot of scientific data in git-annex and have only a specific subset of my often used data in a box.com account so it is quickly synced between computers (my home internet has a limited upload speed). My home server will store all the files as it has effectively unlimited space. 
+
+I basically want the opposite of archive for git-annex-assistant, I'd like to mark the box.com special remote to store every *except* a certain special directory called less used files or whatever, or vise-versa, only store a folder of often used files, the local clients would store everything and my home server would also store everything. 
+
+It seems like transfer control and the groups.log can do this but I'm just not sure how to actually set it up?
+
+Thanks!
+"""]]
diff --git a/doc/design/assistant/transfer_control/comment_3_44a1a6d2db9097de9ae68ea1ff1b08a2._comment b/doc/design/assistant/transfer_control/comment_3_44a1a6d2db9097de9ae68ea1ff1b08a2._comment
new file mode 100644
index 0000000000..33ab5565bd
--- /dev/null
+++ b/doc/design/assistant/transfer_control/comment_3_44a1a6d2db9097de9ae68ea1ff1b08a2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 3"
+ date="2014-01-06T15:04:33Z"
+ content="""
+Just put the box.com remote in the transfer group. There is no need for special subdirectories, the transfer group makes the remote only want files that have not yet reached all the known clients.
+"""]]
diff --git a/doc/design/assistant/upgrading.mdwn b/doc/design/assistant/upgrading.mdwn
new file mode 100644
index 0000000000..1395d0cd85
--- /dev/null
+++ b/doc/design/assistant/upgrading.mdwn
@@ -0,0 +1,52 @@
+The assistant should support upgrading itself.
+
+## non-distro upgrades
+
+When git-annex was installed from this website, the assistant should poll
+periodically (once a day or so) to see if there is a new version.
+It downloads, over https, a .info file, which contains a serialized data
+type containing upgrade information. The url it's downloaded from is
+configured by setting `UPGRADE_LOCATION` when building git-annex on the
+autobuilders.
+
+When a new version is found, the webapp prompts the user to start the
+upgrade. (annex.autoupgrade can be set to true to upgrade w/o prompting.)
+
+The upgrade process is automatic, and rather tricky. The file is downloaded
+using git-annex (as a regular key!), and is then unpacked into a new
+directory, and the programfile updated to point to it. Then git-annex
+restarts itself.
+
+### manifest files
+
+To clean up the old installation, a git-annex.MANIFEST file is looked for
+in it, and the files listed, as well as empty directories, are deleted.
+I don't want to accidentally delete something I didn't ship!
+
+## restart on upgrade
+
+When git-annex is installed from a proper distribution package, there is no
+need for the above. But, the assistant still needs to notice when git-annex
+get upgraded, and offer to restart (or automatically restart when
+annex.autoupgrade is set).
+
+This is done using the DirWatcher, watching the directory containing the
+git-annex binary. Or, in the case of a non-distro install, watching the
+directory where eg git-annex.linux/ was unpacked.
+
+When an change is detected, restart.
+
+## multi-daemon upgrades
+
+A single system may have multiple assistant daemons running in different
+repositories.
+
+In this case, one daemon should do the non-distro upgrade, and the rest
+should notice the upgrade and restart.
+
+I don't want every daemon trying to download the file at once..
+
+Approach: The first new version is installed into a stable directory, based
+on its version. So, start the upgrade by making this directory. If upgrade
+is already in progress, the directory will already exist. (Remove directory
+if upgrade fails.)
diff --git a/doc/design/assistant/webapp.mdwn b/doc/design/assistant/webapp.mdwn
new file mode 100644
index 0000000000..797c9ad301
--- /dev/null
+++ b/doc/design/assistant/webapp.mdwn
@@ -0,0 +1,65 @@
+The webapp is a web server that displays a shiny interface.
+
+## performance
+
+Having the webapp open while transfers are
+running uses significant CPU just for the browser to update the progress 
+bar. Unsurprising, since the webapp is sending the browser a new `<div>`
+each time. Updating the DOM instead from javascript would avoid that;
+the webapp just needs to send the javascript either a full `<div>` or a 
+changed percentage and quantity complete to update a single progress bar.
+
+(Another reason to do this is it'll cut down on the refreshes, which 
+sometimes make browsers ignore clicks on UI elements like the pause button, 
+if the transfer display refreshes just as the click is made.)
+
+## other features
+
+* there could be a UI to export a file, which would make it be served up
+  over http by the web app
+* there could be a UI (some javascript thing) in the web browser to
+  submit urls to the web app to be added to the annex and downloaded.
+  See: [[todo/wishlist:_an_"assistant"_for_web-browsing_--_tracking_the_sources_of_the_downloads]]
+* Display the `inotify max_user_watches` exceeded message. **done**
+* Display something sane when kqueue runs out of file descriptors.
+* allow removing git remotes **done**
+* allow disabling syncing to here, which should temporarily disable all
+  local syncing. **done**
+
+## better headless support
+
+`--listen` is insecure, and using HTTPS would still not make it 100% secure
+as there would be no way for the browser to verify its certificate.
+
+I do have a better idea, but it'd be hard to implement.
+`git annex webapp --remote user@host:dir` could ssh to the remote host,
+run the webapp there, listening only on localhost, and then send the
+port the webapp chose back over the ssh connection. Then the same
+ssh connection could be reused (using ssh connection caching) to set up
+port forwarding from a port on the local host to the remote webapp.
+
+This would need to handle the first run case too, which would require
+forwarding a second port once the webapp made the repository and
+the second webapp started up.
+
+## first start **done**
+
+* make git repo **done**
+* generate a nice description like "joey@hostname Desktop/annex" **done**
+* record repository that was made, and use it next time run **done**
+* write a pid file, to prevent more than one first-start process running
+  at once **done**
+
+## security **acceptable/done**
+
+* Listen only to localhost. **done**
+* Instruct the user's web browser to open an url that contains a secret
+  token. This guards against other users on the same system. **done**
+  (I would like to avoid passwords or other authentication methods,
+  it's your local system.)
+* Don't pass the url with secret token directly to the web browser,
+  as that exposes it to `ps`. Instead, write a html file only the user can read,
+  that redirects to the webapp. **done**
+* Alternative for Linux at least would be to write a small program using
+  GTK+ Webkit, that runs the webapp, and can know what user ran it, avoiding
+  needing authentication.
diff --git a/doc/design/assistant/webapp/comment_1_bab6f6fa720273c0f9700a3765150189._comment b/doc/design/assistant/webapp/comment_1_bab6f6fa720273c0f9700a3765150189._comment
new file mode 100644
index 0000000000..3e1330f96d
--- /dev/null
+++ b/doc/design/assistant/webapp/comment_1_bab6f6fa720273c0f9700a3765150189._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlup4hyZo4eCjF8T85vfRXMKBxGj9bMdl0"
+ nickname="Ben"
+ subject="ARM support"
+ date="2012-07-13T16:51:15Z"
+ content="""
+The closure of [this](http://hackage.haskell.org/trac/ghc/ticket/5839) ticket hopefully marks the end of TH issues on ARM. As of 7.4.2, GHC's linker has enough ARM support to allow a selection of common packages compile on my PandaBoard. That being said, it hasn't had a whole lot of testing so it's possible I still need to implement a few relocation types.
+"""]]
diff --git a/doc/design/assistant/webapp/comment_2_3cf0cf460c7869d0cc22940fcc84aec4._comment b/doc/design/assistant/webapp/comment_2_3cf0cf460c7869d0cc22940fcc84aec4._comment
new file mode 100644
index 0000000000..60d678aba4
--- /dev/null
+++ b/doc/design/assistant/webapp/comment_2_3cf0cf460c7869d0cc22940fcc84aec4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yatesa"
+ ip="171.25.193.21"
+ subject="Secret URL token"
+ date="2012-06-19T03:41:16Z"
+ content="""
+> Instruct the user's web browser to open an url that contains a secret token. This guards against other users on the same system.
+
+How will you implement that? Running \"sensible-browser URL\" would be the obvious way, but the secret URL would show up in a well timed ps listing. (And depending on the browser, ps may show the URL the entire time it's running.)
+"""]]
diff --git a/doc/design/assistant/webapp/comment_3_428e153135f7a64215730719207d82c4._comment b/doc/design/assistant/webapp/comment_3_428e153135f7a64215730719207d82c4._comment
new file mode 100644
index 0000000000..7a73799aa4
--- /dev/null
+++ b/doc/design/assistant/webapp/comment_3_428e153135f7a64215730719207d82c4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jtang"
+ ip="79.97.135.214"
+ subject="comment 3"
+ date="2012-07-26T17:35:18Z"
+ content="""
+Using twitter-bootstrap for the webapp - this might be a wishlist item, but would it be possible to ensure that the webapp's css uses twitter-bootstrap classes. It would make theming much easier in the long run and it would give you a nice modern look with a low amount of effort.
+"""]]
diff --git a/doc/design/assistant/webapp/comment_4_f4068a7abbb77ba6a3297cbcf1e503e9._comment b/doc/design/assistant/webapp/comment_4_f4068a7abbb77ba6a3297cbcf1e503e9._comment
new file mode 100644
index 0000000000..d713e3e8fc
--- /dev/null
+++ b/doc/design/assistant/webapp/comment_4_f4068a7abbb77ba6a3297cbcf1e503e9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.189"
+ subject="comment 4"
+ date="2012-07-26T17:45:28Z"
+ content="""
+So, Yesod's scaffolded site actually does use bootstrap, but I didn't use the scaffolded site so don't have it. I am not quite to the point of doing any theming of the webapp, but I do have this nice example of how to put in bootstrap right here..
+
+By the way, if anyone would like to play with the html templates for the webapp, the main html template is `templates/default-layout.hamlet`. Uses a slightly weird template markup, but plain html will also work. And there's also the `static/` directory; every file in there will be compiled directly into the git-annex binary, and is available at `http://localhost:port/static/$file` in the webapp. See the favicon link in `default-layout.hamlet` of how to construct a type-safe link to a static file: `href=@{StaticR favicon_ico}`. That's all you really need to theme the webapp, without doing any real programming!
+"""]]
diff --git a/doc/design/assistant/webapp/comment_5_2bdb436f35c659316193b89ee6e52fcb._comment b/doc/design/assistant/webapp/comment_5_2bdb436f35c659316193b89ee6e52fcb._comment
new file mode 100644
index 0000000000..b1592af20b
--- /dev/null
+++ b/doc/design/assistant/webapp/comment_5_2bdb436f35c659316193b89ee6e52fcb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="dirk.schmidt@045f26624b94d351628bbb315f94150d627fb18b"
+ nickname="dirk.schmidt"
+ subject="Webapp don open"
+ date="2015-07-08T12:49:01Z"
+ content="""
+Hey there,
+i am using Ubuntu 14.04 
+I have disabled all my repositories and now i cannot open the webapp any more.
+Any suggestions ?
+"""]]
diff --git a/doc/design/assistant/windows.mdwn b/doc/design/assistant/windows.mdwn
new file mode 100644
index 0000000000..78ab69febb
--- /dev/null
+++ b/doc/design/assistant/windows.mdwn
@@ -0,0 +1,33 @@
+See [[todo/windows_support]]..
+
+## symlinks
+
+Apparently new versions of Windows have something very like symlinks.
+(Or really, 3 or so things not entirely unlike symlinks and all different.)
+Stackoverflow has some details.
+
+NTFS supports symbolic links two different ways: an [[!wikipedia NTFS symbolic link]] and an [[!wikipedia NTFS_junction_point]].  The former seems like the closest analogue to POSIX symlinks.
+
+The windows port will not use symlinks. It will only support direct mode.
+
+## POSIX
+
+Lots of ifdefs and pain to deal with POSIX calls in the code base.
+
+Or I could try to use Cygwin.
+
+## Deeper system integration
+
+[NTFS Reparse Points](http://msdn.microsoft.com/en-us/library/aa365503%28v=VS.85%29.aspx) allow a program to define how the OS will interpret a file or directory in arbitrary ways.  This requires writing a file system filter.
+
+## Developement environment
+
+Someone wrote in to say:
+
+> For Windows Development you can easily qualify
+> for Bizspark - http://www.microsoft.com/bizspark/
+> 
+> This will get you 100% free Windows OS licenses and
+> Dev tools, plus a free Azure account for cloud testing.
+> (You can also now deploy Linux VMs to Azure as well)
+> No money required at all.
diff --git a/doc/design/assistant/windows/comment_1_f4b829318b182e1cec29f13babb6498e._comment b/doc/design/assistant/windows/comment_1_f4b829318b182e1cec29f13babb6498e._comment
new file mode 100644
index 0000000000..0bccc3a354
--- /dev/null
+++ b/doc/design/assistant/windows/comment_1_f4b829318b182e1cec29f13babb6498e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlCGROoy62svBUy6P24x1KoGoDWrBq2ErA"
+ nickname="Steve"
+ subject="comment 1"
+ date="2012-08-07T04:15:43Z"
+ content="""
+NTFS symbolic links should do exactly what you would expect them to do. They can point to files or directories. Junction points are legacy NTFS functionality and reparse points are more like the POSIX mount functionality.
+
+NTFS symbolic links should work for you, junction point should be avoided, and reparse points would be like using a nuke to kill a fly. The only hang up you might have is that I think all three features require elevated privileges to manage.
+"""]]
diff --git a/doc/design/assistant/xmpp.mdwn b/doc/design/assistant/xmpp.mdwn
new file mode 100644
index 0000000000..4bdc58874f
--- /dev/null
+++ b/doc/design/assistant/xmpp.mdwn
@@ -0,0 +1,136 @@
+The git-annex assistant uses XMPP to communicate between peers that
+cannot directly talk to one-another. A typical scenario is two users
+who share a repository, that is stored in the [[cloud]].
+
+### TODO
+
+* Do git-annex clients sharing an account with regular clients cause confusing
+  things to happen? 
+  See <http://git-annex.branchable.com/design/assistant/blog/day_114__xmpp/#comment-aaba579f92cb452caf26ac53071a6788>
+* Support registering with XMPP provider from within the webapp, 
+  as clients like pidgin are able to do.
+* At least some XMPP servers are lossy (does XMPP guarantee delivery)?
+  I have seen a log where a push's packet 1 and 3 arrived, but 2 did not.
+  To deal with this, need at least a 1 packet buffer and ACK or resend
+  request implemented over top of XMPP. Essentially, TCP over XMPP. :(
+
+## design goals
+
+1. Avoid user-visible messages. dvcs-autosync uses XMPP similarly, but
+   sends user-visible messages. Avoiding user-visible messages lets
+   the user configure git-annex to use his existing XMPP account
+   (eg, Google Talk).
+
+2. Send notifications to buddies. dvcs-autosync sends only self-messages,
+   but that requires every node have the same XMPP account configured.
+   git-annex should support that mode, but it should also send notifications
+   to a user's buddies. (This will also allow for using XMPP for pairing
+   in the future.)
+
+3. Don't make account appear active. Just because git-annex is being an XMPP
+   client, it doesn't mean that it wants to get chat messages, or make the
+   user appear active when he's not using his chat program.
+
+## protocol
+
+To avoid relying on XMPP extensions, git-annex communicates
+using presence messages, and chat messages (with empty body tags,
+so clients don't display them).
+
+git-annex sets a negative presence priority, to avoid any regular messages
+getting eaten by its clients. It also sets itself extended away.
+Note that this means that chat messages always have to be directed at
+specific git-annex clients.
+
+To the presence and chat messages, it adds its own tag as
+[extended content](http://xmpp.org/rfcs/rfc6121.html#presence-extended).
+The xml namespace is "git-annex" (not an URL because I hate wasting bandwidth).
+
+To indicate it's pushed changes to a git repo with a given UUID, a message
+that is sent to all buddies and other clients using the account (no
+explicit pairing needed), it uses a broadcast presence message containing:
+
+	<git-annex xmlns='git-annex' push="uuid[,uuid...]" />
+
+Multiple UUIDs can be listed when multiple clients were pushed. If the
+git repo does not have a git-annex UUID, an empty string is used.
+
+To query if other git-annex clients are around, a presence message is used,
+containing:
+
+	<git-annex xmlns='git-annex' query="" />
+
+For pairing, a chat message is sent to every known git-annex client,
+containing:
+
+	<git-annex xmlns='git-annex' pairing="PairReq|PairAck|PairDone myuuid" />
+
+### git push over XMPP
+
+To indicate that we could push over XMPP, a chat message is sent,
+to each known client of each XMPP remote.
+
+	<git-annex xmlns='git-annex' canpush="myuuid" shas="sha1 sha1" />
+
+The shas are omitted by old clients. If present, they are the git shas of
+the head and git-annex branches that are available to be pushed. This lets
+the receiver check if it's already got them.
+
+To request that a remote push to us, a chat message can be sent.
+
+	<git-annex xmlns='git-annex' pushrequest="myuuid" />
+
+When replying to an canpush message, this is directed at the specific
+client that indicated it could push. To solicit pushes from all clients,
+the message has to be sent directed individually to each client.
+
+When a peer is ready to send a git push, it sends:
+
+	<git-annex xmlns='git-annex' startingpush="myuuid" />
+
+The receiver runs `git receive-pack`, and sends back its output in
+one or more chat messages, directed to the client that is pushing:
+
+	<git-annex xmlns='git-annex' rp="N">
+	007b27ca394d26a05d9b6beefa1b07da456caa2157d7 refs/heads/git-annex report-status delete-refs side-band-64k quiet ofs-delta
+	</git-annex>
+
+The sender replies with the data from `git push`, in 
+one or more chat messages, directed to the receiver:
+
+	<git-annex xmlns='git-annex' sp="N">
+	data
+	</git-annex>
+
+The value of rp and sp used to be empty, but now it's a sequence number.
+This indicates the sequence of this packet, counting from 1. The receiver
+and sender each have their own sequence numbers.
+
+When `git receive-pack` exits, the receiver indicates its exit
+status with a chat message, directed at the sender:
+
+	<git-annex xmlns='git-annex' rpdone="0" />
+
+### security
+
+Data git-annex sends over XMPP will be visible to the XMPP account's
+buddies, and to the XMPP server (and any attacker who has access to the
+XMPP server). So it's important to consider the security exposure of using
+it.
+
+Even if git-annex sends only a single bit notification, this lets attackers
+know when the user is active and changing files. Although the assistant's other
+syncing activities can somewhat mask this.
+
+As soon as git-annex does anything unlike any other client, an attacker can
+see how many clients are connected for a user, and fingerprint the ones
+running git-annex, and determine how many clients are running git-annex.
+
+An attacker can observe the UUIDs used for pushes and pairing, and determine
+how many different remotes are being used.
+
+An attacker could replay push notification messages, reusing UUIDs it's
+observed. This would make clients pull repeatedly, perhaps as a DOS.
+
+The XMPP server, or an attacker with access to it can reconstruct the git 
+repository from data sent in pushes, in part or in whole.
diff --git a/doc/design/assistant/xmpp/comment_1_f20650f93d7f0ca39b9ba3ce0380193f._comment b/doc/design/assistant/xmpp/comment_1_f20650f93d7f0ca39b9ba3ce0380193f._comment
new file mode 100644
index 0000000000..7ee62eea7f
--- /dev/null
+++ b/doc/design/assistant/xmpp/comment_1_f20650f93d7f0ca39b9ba3ce0380193f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://meep.pl/"
+ ip="193.23.174.18"
+ subject="xmlns"
+ date="2012-11-11T09:00:01Z"
+ content="""
+A minor point, but is saving a couple of bytes per message worth using a [deprecated feature](http://www.w3.org/TR/REC-xml-names/#iri-use) of the namespaces specification? This is not technically *breaking* the current specification, since \"git-annex\" is of course still a (relative) URI reference; and anyway chances of problems are, I guess, slim. But is it the lesser of two bugs?
+
+The shortest moderately sane absolute URI containing \"git-annex\" would probably be \"data:,git-annex\".
+"""]]
diff --git a/doc/design/assistant/xmpp/comment_2_8c22839a8f5912b4a817415c4a359697._comment b/doc/design/assistant/xmpp/comment_2_8c22839a8f5912b4a817415c4a359697._comment
new file mode 100644
index 0000000000..5b6ea3946c
--- /dev/null
+++ b/doc/design/assistant/xmpp/comment_2_8c22839a8f5912b4a817415c4a359697._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkurjhi0CRJvgm7QNaZDWS9hitBtavqIpc"
+ nickname="Bret"
+ subject="Plans for two factor authentication or oath?"
+ date="2013-04-15T00:58:04Z"
+ content="""
+Are there plans to support google's two factor authentication?  Right now I have to use an application specific password.
+"""]]
diff --git a/doc/design/assistant/xmpp/comment_4_773102522f21844cffc841e6cde9229e._comment b/doc/design/assistant/xmpp/comment_4_773102522f21844cffc841e6cde9229e._comment
new file mode 100644
index 0000000000..f8ddf0a3b8
--- /dev/null
+++ b/doc/design/assistant/xmpp/comment_4_773102522f21844cffc841e6cde9229e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="hhm"
+ ip="108.17.80.177"
+ subject="file transfer?"
+ date="2013-04-23T10:22:51Z"
+ content="""
+Would it be possible to add optional support for transferring files over XMPP (possibly being disabled out-of-the-box so as not to suck up third-party bandwidth)?
+"""]]
diff --git a/doc/design/assistant/xmpp_security.mdwn b/doc/design/assistant/xmpp_security.mdwn
new file mode 100644
index 0000000000..647bffd797
--- /dev/null
+++ b/doc/design/assistant/xmpp_security.mdwn
@@ -0,0 +1,29 @@
+Currently [[xmpp]] relies on the SSL connection to the server for security.
+The server can see git repository data pushed through it. (Also, the SSL
+connection is not pinned or really checked well at all.)
+
+Add an encryption layer that does not rely on trusting the XMPP server's
+security. There are a few options for how to generate the key for eg,
+AES encryption:
+
+  * Do a simple Diffie-Hellman shared key generation when starting each XMPP
+    push session. Would not protect the users from active MITM by the
+    XMPP server, but would prevent passive data gathering attacks from
+    getting useful data. Since the key is ephemeral, would provide
+    Forward Security.
+  * Do D-H key generation, but at pairing, not push time. Allows for an
+    optional confirmation step, using eg, BubbleBabble to compare the
+    keys out of band. ("I see xebeb-dibyb-gycub-kacyb-modib-pudub-sefab-vifuc-bygoc-daguc-gohec-kuxax .. do you too?")
+  * Prompt both users for a passphrase when XMPP pairing, and 
+    use SPEKE (or similar methods like J-PAKE) to generate a shared key.
+    Avoids active MITM attacks. Makes pairing harder, especially pairing
+    between one's own devices, since the passphrase has to be entered on
+    all devices. Also problematic when pairing more than 2 devices,
+    especially when adding a device to the set later, since there
+    would then be multiple different keys in use.
+  * Rely on the user's gpg key, and do gpg key verification during XMPP
+    pairing. Problematic because who wants to put their gpg key on their
+    phone? Also, require the users be in the WOT and be gpg literate.
+
+Update: This seems unlikely to be worth doing. [[Telehash]] is better.
+--[[Joey]]
diff --git a/doc/design/assistant/xmpp_security/comment_1_c714e86553c02600249795efb224be8a._comment b/doc/design/assistant/xmpp_security/comment_1_c714e86553c02600249795efb224be8a._comment
new file mode 100644
index 0000000000..92cff201df
--- /dev/null
+++ b/doc/design/assistant/xmpp_security/comment_1_c714e86553c02600249795efb224be8a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Sagi"
+ ip="2001:610:1908:8001:25ce:8a0b:53cc:c010"
+ subject="Why not use OTR?"
+ date="2013-07-23T23:53:12Z"
+ content="""
+[OTR](http://www.cypherpunks.ca/otr/) seems a natural fit for end-to-end encryption over xmpp. I can't find Haskell bindings for libotr at this moment, but creating those instead of inventing new protocols might be worth considering. There are also several [native implementations](http://www.cypherpunks.ca/otr/software.php) (Python, Go, Scheme), but I'm not sure if that's worth the effort.
+
+
+"""]]
diff --git a/doc/design/balanced_preferred_content.mdwn b/doc/design/balanced_preferred_content.mdwn
new file mode 100644
index 0000000000..0e2bc5d417
--- /dev/null
+++ b/doc/design/balanced_preferred_content.mdwn
@@ -0,0 +1,149 @@
+Say we have 2 drives and want to fill them both evenly with files,
+different files in each drive. Currently, preferred content cannot express
+that entirely:
+
+* One way is to use a-m* and n-z*, but that's unlikely to split filenames evenly. 
+* Or, can let both repos take whatever files, perhaps at random, that the
+  other repo is not know to contain, but then repos will race and both get
+  the same file, or similarly if they are not communicating frequently.
+  Existing preferred content expressions such as the one for archive group
+  have this problem.
+
+So, let's add a new expression: `balanced(group)`
+
+## implementation
+
+This would work by taking the list of uuids of all repositories in the
+group that have enough free space to store a key, and sorting them, 
+which yields a list from 0..M-1 repositories.
+
+(To know if a repo has enough free space to store a key 
+will need [[todo/track_free_space_in_repos_via_git-annex_branch]]
+to be implemented.)
+
+To decide which repository wants key K, convert K to a number N in some
+stable way and then `N mod M` yields the number of the repository that
+wants it, while all the rest don't.
+
+(Since git-annex keys can be pretty long and not all of them are random
+hashes, let's md5sum the key and then use the md5 as a number.)
+
+## stability
+
+Note that this preferred content expression will not be stable. A change in 
+the members of the group will change which repository is selected. And
+changes in how full repositories are will also change which repo is
+selected.
+
+Without stability, when another repo is added to the group, all data will
+be rebalanced, with some moving to it. Which could be desirable in some
+situations, but the problem is that it's likely that adding repo3 will make
+repo1 and repo2 want to swap some files between them,
+
+So, we'll want to add some precautions to avoid a lot of data moving around
+in such a case:
+
+	((balanced(backup) and not (copies=backup:1)) or present
+
+So once file lands on a backup drive, it stays there, even if more backup
+drives change the balancing.
+
+## use case: 3 of 5
+
+What if we have 5 backup repos and want each key to be stored in 3 of them?
+There's a simple change that can support that:
+`balanced(group:3)`
+
+This works the same as before, but rather than just `N mod M`, take
+`N+I mod M` where I is [0..2] to get the list of 3 repositories that want a
+key.
+
+However, once 3 of those 5 repos get full, new keys will only be able to be
+stored on 2 of them. At that point one or more new repos will need to be
+added to reach the goal of each key being stored in 3 of them. It would be
+possible to rebalance the 3 full repos by moving some keys from them to the
+other 2 repos, and eke out more storage before needing to add new
+repositories. A separate rebalancing pass, that does not use preferred
+content alone, could be implemented to handle this (see below).
+
+## use case: geographically distinct datacenters
+
+Of course this is not limited to backup drives. A more complicated example:
+There are 4 geographically distributed datacenters, each of which has some
+number of drives. Each file should have 1 copy stored in each datacenter,
+on some drive there. 
+
+This can be implemented by making a group for each datacenter, which all of
+its drives are in, and using `balanced()` to pick the drive that holds the
+copy of the file. The preferred content expression would be eg:
+
+    ((balanced(datacenterA) and not (copies=datacenterA:1)) or present
+
+In such a situation, to avoid a `N^2` remote interconnect, there might be a
+transfer repository in each datacenter, that is in front of its drives. The
+transfer repository should want files that have not yet reached the
+destination drive. How to write a preferred content expression for that?
+It might be sufficient to use `copies=datacenterA:1`, so long as the file
+reaching any drive in the datacenter is enough. But may want to add
+something analagous to `inallgroup=` that checks if a file is in
+the place that `balanced()` picks for a group. Eg, 
+`balancedgroup=datacenterA` for 1 copy and `balancedgroup=group:datacenterA:2`
+for N copies.
+
+The [[design/passthrough_proxy]] idea is an alternate way to put a
+repository in front of such a cluster, that does not need additional
+extensions to preferred content.
+
+## split brain situations
+
+Of course, in the time after the git-annex branch was updated and before
+it reaches the local repo, a repo can be full without us knowing about
+it. Stores to it would fail, and perhaps be retried, until the updated
+git-annex branch was synced. 
+
+In the worst case, a split brain situation
+can make the balanced preferred content expression
+pick a different repository to hold two independent
+stores of the same key. Eg, when one side thinks one repo is full,
+and the other side thinks the other repo is full.
+
+If `present` is used in the preferred content, both of them will then
+want to contain it. (Is `present` really needed like shown in the examples
+above?)
+
+If it's not, one of them will drop it and the other will
+usually maintain its copy. It would perhaps be possible for both of
+them to drop it, leading to a re-upload cycle. This needs some research
+to see if it's a real problem. 
+See [[todo/proving_preferred_content_behavior]].
+
+## rebalancing
+
+In both the 3 of 5 use case and a split brain situation, it's possible for
+content to end up not optimally balanced between repositories. git-annex
+can be made to operate in a mode where it does additional work to rebalance
+repositories. 
+
+This can be an option like --rebalance, that changes how the preferred content
+expression is evaluated. The user can choose where and when to run that.
+Eg, it might be run on a node inside a cluster after adding more storage to
+the cluster.
+
+In several examples above, we have preferred content expressions in this
+form:
+
+    ((balanced(group:N) and not (copies=group:N)) or present
+
+In order to rebalance, that needs to be changed to:
+
+    balanced(group:N)
+
+What could be done is make `balanced()` usually expand to the former,
+but when --rebalance is used, it only expands to the latter.
+
+(Might make the fully balanced behavior available as `fullybalanced()` for
+users who want it, then 
+`balanced() == ((fullybalanced(group:N) and not (copies=group:N)) or present`
+usually and when --rebalance is used, `balanced() == fullybalanced(group:N)`
+
+
diff --git a/doc/design/balanced_preferred_content/comment_1_a7eea522b04ddefbd0b9ff49dfb82d15._comment b/doc/design/balanced_preferred_content/comment_1_a7eea522b04ddefbd0b9ff49dfb82d15._comment
new file mode 100644
index 0000000000..069871cb10
--- /dev/null
+++ b/doc/design/balanced_preferred_content/comment_1_a7eea522b04ddefbd0b9ff49dfb82d15._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="hurlebouc"
+ avatar="http://cdn.libravatar.org/avatar/bda734a6d937c1fe0c9778a6eaefffbc"
+ subject="comment 1"
+ date="2023-07-24T13:10:09Z"
+ content="""
+Hi, this topic ils pretty old: is there any mean to balance files between several repositories?
+"""]]
diff --git a/doc/design/caching_database.mdwn b/doc/design/caching_database.mdwn
new file mode 100644
index 0000000000..c415aed3e8
--- /dev/null
+++ b/doc/design/caching_database.mdwn
@@ -0,0 +1,153 @@
+* [[metadata]] for views
+* [[todo/cache_key_info]]
+
+What do all these have in common? They could all be improved by
+using some kind of database to locally store the information in an
+efficient way.
+
+The database should only function as a cache. It should be able to be
+generated and updated by looking at the git repository.
+
+* Metadata can be updated by looking at the git-annex branch,
+  either its current state, or the diff between the old and new versions
+* Incremental fsck information is not stored in git, but can be
+  "regenerated" by running fsck again.  
+  (Perhaps doesn't quite fit, but let it slide..)
+
+Store in the database the Ref of the branch that was used to construct it.
+(Update in same transaction as cached data.)
+
+## implementation plan
+
+1. Store incremental fsck info in db, on a branch, with sqlite. **done**
+2. Make sure that builds on all platforms, and works reliably. **done**
+3. Use sqlite db for associated files cache. **done** (only for v6 unlocked
+   files)
+4. Use associated files db when dropping files, to fix
+   indeterminite preferred content state for duplicated files **done**
+5. Also, use associated files db to construct views.
+6. Use sqlite db for metadata cache.
+7. Use sqlite db for list of keys present in local annex.
+
+## sqlite or not?
+
+sqllite seems like the most likely thing to work. But it does involve ugh,
+SQL. And even if that's hidden by a layer like persistent, it's still going
+to involve some technical debt (eg, database migrations).
+
+It would be great if there were some haskell thing like acid-state
+that I could use instead. But, acid-state needs to load the whole
+DB into memory. In the comments of
+[[bugs/incremental_fsck_should_not_use_sticky_bit]] I examined several
+other haskell database-like things, and found them all wanting, except for
+possibly TCache. (And TCache is backed by persistent/sqlite anyway.)
+
+## one db or multiple?
+
+Using a single database will use less space. Eg, each Key will only need to
+appear in it once, with proper normalization.
+
+OTOH, it's more complicated, and harder to recover from problems.
+
+Currently leaning toward one database per purpose.
+
+## case study: persistent with sqllite
+
+Here's a non-normalized database schema in persistent's syntax.
+
+<pre>
+CachedKey
+  key Key
+  associatedFiles [FilePath]
+  lastFscked Int Maybe
+  KeyIndex key
+
+CachedMetaData
+  key Key
+  metaDataField MetaDataField
+  metaDataValue MetaDataValue
+</pre>
+
+Using the above database schema and persistent with sqlite, I made
+a database containing 30k Cache records. This took 5 seconds to create
+and was 7 mb on disk. (Would be rather smaller, if a more packed Key
+show/read instance were used.)
+
+Running 1000 separate queries to get 1000 CachedKeys took 0.688s with warm
+cache. This was more than halved when all 1000 queries were done inside the
+same `runSqlite` call. (Which could be done using a separate thread and some
+MVars.)
+
+(Note that if the database is a cache, there is no need to perform migrations
+when querying it. My benchmarks skip `runMigration`. Instead, if the query
+fails, the database doesn't exist, or uses an incompatible schema, and the
+cache can be rebuilt then. This avoids the problem that persistent's migrations
+can sometimes fail.)
+
+Doubling the db to 60k scaled linearly in disk and cpu and did not affect
+query time.
+
+----
+
+Here's a normalized schema:
+
+<pre>
+CachedKey
+  key Key
+  KeyIndex key
+  deriving Show
+
+AssociatedFiles
+  keyId CachedKeyId Eq
+  associatedFile FilePath
+  KeyIdIndex keyId associatedFile
+  deriving Show
+
+CachedMetaField
+  field MetaField
+  FieldIndex field
+
+CachedMetaData
+  keyId CachedKeyId Eq
+  fieldId CachedMetaFieldId Eq
+  metaValue String
+
+LastFscked
+  keyId CachedKeyId Eq
+  localFscked Int Maybe
+</pre>
+
+With this, running 1000 joins to get the associated files of 1000
+Keys took 5.6s with warm cache. (When done in the same `runSqlite` call.) Ouch!
+
+Update: This performance was fixed by adding `KeyIdOutdex keyId associatedFile`,
+which adds a uniqueness constraint on the tuple of key and associatedFile.
+With this, 1000 queries takes 0.406s. Note that persistent is probably not
+actually doing a join at the SQL level, so this could be sped up using
+eg, esquelito.
+
+Update2: Using esquelito to do a join got this down to 0.109s.
+See `database` branch for code.
+
+Update3: Converting to a single un-normalized table for AssociatedFiles
+avoids the join, and increased lookup speed to 0.087s. Of course, when
+a key has multiple associated files, this will use more disk space, due
+to not normalizing the key.
+
+Compare the above with 1000 calls to `associatedFiles`, which is approximately
+as fast as just opening and reading 1000 files, so will take well under
+0.05s with a **cold** cache.
+
+So, we're looking at maybe 50% slowdown using sqlite and
+persistent for associated files. OTOH, the normalized schema should
+perform better when adding an associated file to a key that already has many.
+
+For metadata, the story is much nicer. Querying for 30000 keys that all
+have a particular tag in their metadata takes 0.65s. So fast enough to be
+used in views.
+
+Update4: Comparing git-annex fsck using the sticky bit to the final sqlite
+implementation:
+
+sticky bit: 4m30.787s  
+sqlite: 4m40.789s  
diff --git a/doc/design/encryption.mdwn b/doc/design/encryption.mdwn
new file mode 100644
index 0000000000..1c64566c15
--- /dev/null
+++ b/doc/design/encryption.mdwn
@@ -0,0 +1,118 @@
+This was the design doc for [[/encryption]] and is preserved for
+the curious. For an example of using git-annex with an encrypted S3 remote,
+see [[tips/using_Amazon_S3]].
+
+[[!toc]]
+
+## encryption key management
+
+[[!template id=note text="""
+The basis of this scheme was originally developed by Lars Wirzenius et al
+[for Obnam](http://liw.fi/obnam/encryption/).
+"""]]
+
+Data is encrypted by GnuPG, using a symmetric cipher. The cipher is
+generated by GnuPG when the special remote is created. By default the
+best entropy pool is used, hence the generation may take a while; One
+can use `initremote` with the `--fast` option
+to speed up things, but at the expense of using random numbers of a
+lower quality. The generated cipher is then checked into your git
+repository, encrypted using one or more OpenPGP public keys. This scheme
+allows new OpenPGP private keys to be given access to content that has
+already been stored in the remote.
+
+Different encrypted remotes need to be able to each use different ciphers.
+Allowing multiple ciphers to be used within a single remote would add a lot
+of complexity, so is not supported.
+Instead, if you want a new cipher, create a new S3 bucket, or whatever.
+There does not seem to be much benefit to using the same cipher for
+two different encrypted remotes.
+
+So, the encrypted cipher is just stored with the rest of a remote's
+configuration in `remote.log` (see [[internals]]). When `git
+annex initremote` makes a remote, it generates a random symmetric
+cipher, and encrypt it with the specified gpg key. To allow another gpg
+public key access, update the encrypted cipher to be encrypted to both gpg
+keys.
+
+Note that there's a shared encryption mode where the cipher is not
+encrypted. When this mode is used, any clone of the git repository
+can decrypt files stored in its special remote.
+
+## filename enumeration
+
+If the names of files are encrypted or securely hashed, or whatever is
+chosen, this makes it harder for git-annex (let alone untrusted third parties!)
+to get a list of the files that are stored on a given enrypted remote.
+But, does git-annex really ever need to do such an enumeration?
+
+Apparently not. `git annex unused --from remote` can now check for
+unused data that is stored on a remote, and it does so based only on
+location log data for the remote. This assumes that the location log is
+kept accurately.
+
+What about `git annex fsck --from remote`? Such a command should be able to,
+for each file in the repository, contact the encrypted remote to check
+if it has the file. This can be done without enumeration, although it will
+mean running gpg once per file fscked, to get the encrypted filename.
+
+So, the files stored in the remote should be encrypted. But, it needs to
+be a repeatable encryption, so they cannot just be gpg encrypted, that
+would yeild a new name each time. Instead, HMAC is used. Any hash could
+be used with HMAC. SHA-1 is the default, but [[other_hashes|/encryption]]
+can be chosen for new remotes.
+
+It was suggested that it might not be wise to use the same cipher for both
+gpg and HMAC. Being paranoid, it's best not to tie the security of one
+to the security of the other. So, the encrypted cipher described above is
+actually split in two; the first half is used for HMAC, and the second
+half for gpg.
+
+----
+
+Does the HMAC cipher need to be gpg encrypted? Imagine if it were
+stored in plainext in the git repository. Anyone who can access
+the git repository already knows the actual filenames, and typically also
+the content hashes of annexed content. Having access to the HMAC cipher
+could perhaps be said to only let them verify that data they already
+know.
+
+While this seems a pretty persuasive argument, I'm not 100% convinced, and
+anyway, most times that the HMAC cipher is needed, the gpg cipher is also
+needed. Keeping the HMAC cipher encrypted does slow down two things:
+dropping content from encrypted remotes, and checking if encrypted remotes
+really have content. If it's later determined to be safe to not encrypt the
+HMAC cipher, the current design allows changing that, even for existing
+remotes.
+
+## other use of the symmetric cipher
+
+The symmetric cipher can be used to encrypt other content than the content
+sent to the remote. In particular, it may make sense to encrypt whatever
+access keys are used by the special remote with the cipher, and store that
+in `remote.log`. This way anyone whose gpg key has been given access to 
+the cipher can get access to whatever other credentials are needed to
+use the special remote.
+
+For example, the S3 special remote does this if configured with
+embedcreds=yes.
+
+## risks
+
+A risk of this scheme is that, once the symmetric cipher has been
+obtained, it allows full access to all the encrypted content. Indeed
+anyone owning a key that used to be granted access could already have
+decrypted the cipher and stored a copy. While it is in possible to
+remove a key with `keyid-=`, it is designed for a
+[[completely_different_purpose|/encryption]] and does not actually revoke
+access.
+
+If git-annex stores the decrypted symmetric cipher in memory, then there
+is a risk that it could be intercepted from there by an attacker. Gpg
+ameliorates these type of risks by using locked memory. For git-annex, note
+that an attacker with local machine access can tell at least all the
+filenames and metadata of files stored in the encrypted remote anyway,
+and can access whatever content is stored locally.
+
+This design does not address obfuscating the size of files by chunking
+them. However, chunking was later added; see [[design/assistant/chunks]].
diff --git a/doc/design/encryption/comment_1_4715ffafb3c4a9915bc33f2b26aaa9c1._comment b/doc/design/encryption/comment_1_4715ffafb3c4a9915bc33f2b26aaa9c1._comment
new file mode 100644
index 0000000000..f2ecc46d0a
--- /dev/null
+++ b/doc/design/encryption/comment_1_4715ffafb3c4a9915bc33f2b26aaa9c1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2011-04-03T20:03:14Z"
+ content="""
+New encryption keys could be used for different directories/files/patterns/times/whatever. One could then encrypt this new key for the public keys of other people/machines and push them out along with the actual data. This would allow some level of access restriction or future revocation. git-annex would need to keep track of which files can be decrypted with which keys. I am undecided if that information needs to be encrypted or not.
+
+Encrypted object files should be checksummed in encrypted form so that it's possible to verify integrity without knowing any keys. Same goes for encrypted keys, etc.
+
+Chunking files in this context seems like needless overkill. This might make sense to store a DVD image on CDs or similar, at some point. But not for encryption, imo. Coming up with sane chunk sizes for all use cases is literally impossible and as you pointed out, correlation by the remote admin is trivial.
+"""]]
diff --git a/doc/design/encryption/comment_2_a610b3d056a059899178859a3a821ea5._comment b/doc/design/encryption/comment_2_a610b3d056a059899178859a3a821ea5._comment
new file mode 100644
index 0000000000..d5461e23c0
--- /dev/null
+++ b/doc/design/encryption/comment_2_a610b3d056a059899178859a3a821ea5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-04-05T18:41:49Z"
+ content="""
+I see no use case for verifying encrypted object files w/o access to the encryption key. And possible use cases for not allowing anyone to verify your data.
+
+If there are to be multiple encryption keys usable within a single encrypted remote, than they would need to be given some kind of name (a since symmetric key is used, there is no pubkey to provide a name), and the name encoded in the files stored in the remote. While certainly doable I'm not sold that adding a layer of indirection is worthwhile. It only seems it would be worthwhile if setting up a new encrypted remote was expensive to do. Perhaps that could be the case for some type of remote other than S3 buckets.
+"""]]
diff --git a/doc/design/encryption/comment_3_cca186a9536cd3f6e86994631b14231c._comment b/doc/design/encryption/comment_3_cca186a9536cd3f6e86994631b14231c._comment
new file mode 100644
index 0000000000..d3c483fdf3
--- /dev/null
+++ b/doc/design/encryption/comment_3_cca186a9536cd3f6e86994631b14231c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 3"
+ date="2011-04-05T23:24:17Z"
+ content="""
+Assuming you're storing your encrypted annex with me and I with you, our regular cron jobs to verify all data will catch corruption in each other's annexes.
+
+Checksums of the encrypted objects could be optional, mitigating any potential attack scenarios.
+
+It's not only about the cost of setting up new remotes. It would also be a way to keep data in one annex while making it accessible only in a subset of them. For example, I might need some private letters at work, but I don't want my work machine to be able to access them all.
+"""]]
diff --git a/doc/design/encryption/comment_4_8f3ba3e504b058791fc6e6f9c38154cf._comment b/doc/design/encryption/comment_4_8f3ba3e504b058791fc6e6f9c38154cf._comment
new file mode 100644
index 0000000000..14eb1acac1
--- /dev/null
+++ b/doc/design/encryption/comment_4_8f3ba3e504b058791fc6e6f9c38154cf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 4"
+ date="2011-04-07T19:59:30Z"
+ content="""
+@Richard the easy way to deal with that scenario is to set up a remote that work can access, and only put in it files work should be able to see. Needing to specify which key a file should be encrypted to when putting it in a remote that supported multiple keys would add another level of complexity which that avoids.
+
+Of course, the right approach is probably to have a separate repository for work. If you don't trust it with seeing file contents, you probably also don't trust it with the contents of your git repository.
+"""]]
diff --git a/doc/design/encryption/comment_5_520e60aa53217b5ba428d4c05d897dee._comment b/doc/design/encryption/comment_5_520e60aa53217b5ba428d4c05d897dee._comment
new file mode 100644
index 0000000000..ff579f49b8
--- /dev/null
+++ b/doc/design/encryption/comment_5_520e60aa53217b5ba428d4c05d897dee._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkS6aFVrEwOrDuQBTMXxtGHtueA69NS_jo"
+ nickname="Hans"
+ subject="using sshfs + cryptmount is more secure"
+ date="2012-08-14T13:41:47Z"
+ content="""
+\"For git-annex, note that an attacker with local machine access can tell at least all the filenames and metadata of files stored in the encrypted remote anyway, and can access whatever content is stored locally.\"
+
+Better security is given by sshfs + cryptmount, which I used when I recently setup a git-annex repository on a free shell account from a provider I do not trust.
+
+See http://code.cjb.net/free-secure-online-backup.html for what I did to get a really secure solution.
+
+Kind regards,
+
+Hans Ekbrand
+"""]]
diff --git a/doc/design/encryption/comment_6_d677fead0fe0c543f48f07d85f83f592._comment b/doc/design/encryption/comment_6_d677fead0fe0c543f48f07d85f83f592._comment
new file mode 100644
index 0000000000..a2c7013fb0
--- /dev/null
+++ b/doc/design/encryption/comment_6_d677fead0fe0c543f48f07d85f83f592._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 6"
+ date="2012-08-14T14:10:40Z"
+ content="""
+Hans,
+
+You are misunderstanding how git-annex encryption works.  The \"untrusted host\" and the \"local machine\" are not the same machine.  git-annex only transfers pre-encrypted files to the \"untrusted host\".
+
+You should setup a git-annex encrypted remote and watch how it works so you can see for yourself that it is not insecure.
+
+Your solution does not provide better security, it accomplishes the same thing as git-annex in a more complicated way.  In addition, since you are mounting the image from the client your solution will not work with multiple clients.
+"""]]
diff --git a/doc/design/encryption/comment_7_c1c38a09b1276e29adc3ba564dc0fe4e._comment b/doc/design/encryption/comment_7_c1c38a09b1276e29adc3ba564dc0fe4e._comment
new file mode 100644
index 0000000000..259214495a
--- /dev/null
+++ b/doc/design/encryption/comment_7_c1c38a09b1276e29adc3ba564dc0fe4e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkS6aFVrEwOrDuQBTMXxtGHtueA69NS_jo"
+ nickname="Hans"
+ subject="comment 7"
+ date="2012-08-15T19:16:10Z"
+ content="""
+Justin,
+
+thanks for clearing that up. It's great that git-annex has implemented mechanisms to work securely on untrusted hosts. My solution is thus only interesting for files that are impractical to manage with git-annex (e.g. data for/from applications that need rw-access to a large number of files). And, possibly, for providers that do not provide rsync.
+
+Your remark that my solution does not work with more than one client, is not entirely accurate. No more than one client can access the repository at any given time, but as long as access is not simultaneous, any number of clients can access the repository. Still, your point is taken, it's a limitation I should mention.
+
+It would be interesting to compare the performance of individually encrypted files to encrypted image-file. My intuition says that encrypted image-file should be faster, but that's just a guess.
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes.mdwn b/doc/design/exporting_trees_to_special_remotes.mdwn
new file mode 100644
index 0000000000..f786af2cf5
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes.mdwn
@@ -0,0 +1,356 @@
+For publishing content from a git-annex repository, it would be useful to
+be able to export a tree of files to a special remote, using the filenames
+and content from the tree.
+
+Note that this document was written with the assumption that only git-annex
+is writing to the special remote. But
+[[importing_trees_from_special_remotes]] invalidates that assumption,
+and needed to add some additional things to deal with it. See that link for
+details.
+
+[[!toc ]]
+
+## configuring a special remote for tree export
+
+If a special remote already has files stored in it, switching it to be a
+tree export would result in a mix of files named by key and by filename.
+That's not desirable. So, the user should set up a new special remote
+when they want to export a tree. (It would also be possible to drop all content
+from an existing special remote and reuse it, but there does not seem much
+benefit in doing so.)
+
+Add a new `initremote` configuration `exporttree=yes`, that cannot be
+changed by `enableremote`:
+
+	git annex initremote myexport type=... exporttree=yes
+
+It does not make sense to encrypt an export, so exporttree=yes requires
+encryption=none.
+
+Note that the particular tree to export is not specified yet. This is
+because the tree that is exported to a special remote may change.
+
+## exporting a treeish
+
+To export a treeish, the user can run:
+
+	git annex export $treeish --to myexport
+
+That does all necessary uploads etc to make the special remote contain
+the tree of files. The treeish can be a tag, a branch, or a tree.
+
+If a file's content is not present, it won't be exported. Re-running the
+same export later should export files whose content has become present.
+(This likely means a second pass, and needs location tracking to track
+which files are in the export.)
+
+Users may sometimes want to export multiple treeishes to a single special 
+remote. For example, exporting several tags. This interface could be
+complicated to support that, putting the treeishes in subdirectories on the
+special remote etc. But that's not necessary, because the user can use git
+commands to graft trees together into a larger tree, and export that larger
+tree.
+
+If an export is interrupted, running it again should resume where it left
+off.
+
+## updating an export
+
+The user can at any time re-run git-annex export with a new treeish
+to change what's exported. While some use cases for git annex export
+involve publishing datasets that are intended to remain immutable,
+other use cases include eg, making a tree of files available to a computer
+that can't run git-annex, and in such use cases, the tree needs to be able
+to be updated.
+
+To efficiently update an export, git-annex can diff the tree
+that was exported with the new tree. The naive approach is to upload
+new and modified files and remove deleted files.
+
+With rename detection, if the special remote supports moving files,
+more efficient updates can be done. It gets complicated; consider two files
+that swap names.
+
+If the special remote supports copying files, that would also make some
+updates more efficient.
+
+## tracking exports
+
+This lets the user say, "I want to export the master branch", 
+and have git-annex sync and the assistant automatically update the export
+when master changes.
+
+git-annex export could do this by default (if the user doesn't want the
+export to track the branch, they could instead export a tree or a tag). Or
+it could be a --tracking parameter.
+
+How to record the export tracking branch? It could be stored
+as refs/remotes/myexport/master. This says that the master branch
+is being exported to myexport, and the ref points to the last treeish
+that was exported.
+
+But.. master:subdir is a valid treeish, referring to the subdir
+of the current master tree. This is a useful thing to want to export.
+But, that's not a legal ref name. So, perhaps better to record
+the export tracking branch some other way. Perhaps in git config?
+
+## changes to special remote interface
+
+This needs some additional methods added to special remotes, and to
+the [[external_special_remote_protocol]].
+
+Here's the changes to the latter:
+
+* `EXPORTSUPPORTED`  
+  Used to check if a special remote supports exports. The remote
+  responds with either `EXPORTSUPPORTED-SUCCESS` or
+  `EXPORTSUPPORTED-FAILURE`
+* `EXPORT Name`  
+  Comes immediately before each of the following requests, 
+  specifying the name of the exported file. It will be in the form
+  of a relative path, and may contain path separators, whitespace,
+  and other special characters.
+* `TRANSFEREXPORT STORE|RETRIEVE Key File`  
+  Requests the transfer of a File on local disk to or from the previously 
+  provided Name on the special remote.  
+  Note that it's important that, while a file is being stored,
+  CHECKPRESENTEXPORT not indicate it's present until all the data has
+  been transferred.  
+  The remote responds with either `TRANSFER-SUCCESS` or
+  `TRANSFER-FAILURE`, and a remote where exports do not make sense
+  may always fail.
+* `CHECKPRESENTEXPORT Key`  
+  Requests the remote to check if the previously provided Name is present
+  in it.  
+  The remote responds with `CHECKPRESENT-SUCCESS`, `CHECKPRESENT-FAILURE`,
+  or `CHECKPRESENT-UNKNOWN`.
+* `REMOVEEXPORT Key`  
+  Requests the remote to remove content stored by `TRANSFEREXPORT`
+  with the previously provided Name.  
+  The remote responds with either `REMOVE-SUCCESS` or
+  `REMOVE-FAILURE`.
+* `RENAMEEXPORT Key NewName`  
+  Requests the remote rename a file stored on it from the previously
+  provided Name to the NewName.  
+  The remote responds with `RENAMEEXPORT-SUCCESS` or with
+  `RENAMEEXPORT-FAILURE` if an efficient rename cannot be done.
+
+To support old external special remote programs that have not been updated
+to support exports, git-annex will need to handle an `ERROR` response
+when using any of the above.
+
+## location tracking
+
+Since not all the files in an exported treeish may have content
+present when the export is done, location tracking will be needed so that
+getting the files and exporting again transfers their content.
+
+Does a copy of a file exported to a special remote count as a copy
+of a file as far as [[numcopies]] goes? Should git-annex get download
+a file from an export?
+
+The problem is that special remotes with exports are not
+key/value stores. The content of a file can change, and if multiple
+repositories can export a special remote, they can be out of sync about
+what files are exported to it. 
+
+Possible solution: Make exporttree=yes cause the special remote to
+be untrusted, and rely on annex.verify to catch cases where the content
+of a file on a special remote has changed. This would work well enough
+except for when the WORM or URL backend is used. So, prevent the user
+from exporting such keys. Also, force verification on for such special
+remotes, don't let it be turned off.
+
+The same file contents may be in a treeish multiple times under different
+filenames. That complicates using location tracking. One file may have been
+exported and the other not, and location tracking says that the content
+is present in the export. A sqlite database is needed to keep track of
+this.
+
+## recording exported filenames in git-annex branch
+
+In order to download the content of a key from a file exported
+to a special remote, the filename that was exported needs to somehow
+be recorded in the git-annex branch. How to do this? The filename could
+be included in the location tracking log or a related log file, or 
+the exported tree could be grafted into the git-annex branch
+(under eg, `exported/uuid/`). Which way uses less space in the git repository?
+
+Grafting in the exported tree records the necessary data, but the
+file-to-key map needs to be reversed to support downloading from an export.
+It would be too expensive to traverse the tree each time to hunt for a key;
+instead would need a database that gets populated once by traversing the
+tree.
+
+On the other hand, for updating what's exported, having access to the old
+exported tree seems perfect, because it and the new tree can be diffed to
+find what changes need to be made to the special remote. 
+
+If the filenames are stored in the location tracking log, the exported tree
+could be reconstructed, but it would take O(N) queries to git, where N is
+the total number of keys git-annex knows about; updating exports of small
+subsets of large repositories would be expensive. So grafting in the
+exported tree seems the better approach.
+
+## export conflicts
+
+What if different repositories can access the same special remote,
+and different trees get exported to it concurrently?
+
+This would be very hard to untangle, because it's hard to know what
+content was exported to a file last, and thus what content the file
+actually has. The location log's timestamps might give a hint, 
+but clocks vary too much to trust it.
+
+Also, if the exported tree is grafted in to the git-annex branch, 
+there would be a merge conflict. Union merging would *scramble* the exported 
+tree, so even if a smart merge is added, old versions of git-annex would 
+corrupt the exported tree.
+
+To avoid that problem, add a log file `export.log` that contains the uuid
+of the remote that was exported to, and the sha1 of the exported tree.
+To avoid the exported tree being GCed, do graft it in to the git-annex
+branch, but follow that with a commit that removes the tree again,
+and only update `refs/heads/git-annex` after making both commits.
+
+If `export.log` contains multiple active exports of different trees,
+there was an export conflict. Short of downloading the whole export to
+checksum it, or deleting the whole export, what can be done to resolve it?
+
+In this case, git-annex knows both exported trees. Have the user provide
+a tree that resolves the conflict as they desire (it could be the same as
+one of the exported trees, or some merge of them or an entirely new tree).
+The UI to do this can just be another `git annex export $tree --to remote`.
+To resolve, diff each exported tree in turn against the resolving tree
+and delete all files that differ. Then, upload all missing files.
+
+## when to update export.log for efficient resuming of exports
+
+When should `export.log` be updated? Possibilities:
+
+* Before performing any work, to set the goal.
+* After the export is fully successful, to record the current state.
+* After some mid-point.
+
+Lots of things could go wrong during an export. A file might fail to be
+transferred or only part of it be transferred; a file's content might not
+be present to transfer at all. The export could be interrupted part way.
+Updating the export.log at the right point in time is important to handle
+these cases efficiently.
+
+If the export.log is updated first, then it's only a goal and does not tell
+us what's been done already.
+
+If the export.log is updated only after complete success, then the common
+case of some files not having content locally present will prevent it from
+being updated. When we resume, we again don't know what's been done
+already.
+
+If the export.log is updated after deleting any files from the
+remote that are not the same in the new treeish as in the old treeish,
+and as long as TRANSFEREXPORT STORE is atomic, then when resuming we can
+trust CHECKPRESENTEXPORT to only find files that have the correct content
+for the current treeish. (Unless a conflicting export was made from
+elsewhere, but in that case, the conflict resolution will have to fix up
+later.)
+
+## handling renames efficiently
+
+To handle two files that swap names, a temp name is required.
+
+Difficulty with a temp name is picking a name that won't ever be used by
+any exported file.
+
+Interrupted exports also complicate this. While a name could be picked that
+is in neither the old nor the new tree, an export could be interrupted,
+leaving the file at the temp name. There needs to be something to clean
+that up when the export is resumed, even if it's resumed with a different 
+tree.
+
+Could use something like ".git-annex-tmp-content-$key" as the temp name.
+This hides it from casual view, which is good, and it's not depedent on the
+tree, so no state needs to be maintained to clean it up. Also, using the
+key in the name simplifies calculation of complicated renames (eg, renaming
+A to B, B to C, C to A)
+
+Export can first try to rename all files that are deleted/modified
+to their key's temp name (falling back to deleting since not all
+special remotes support rename), and then, in a second pass, rename
+from the temp name to the new name. Followed by deleting the temp name
+of all keys whose files are deleted in the diff. That is more renames and
+deletes than strictly necessary, but it will statelessly clean up 
+an interruped export as long as it's run again with the same new tree.
+
+But, an export of tree B should clean up after 
+an interrupted export of tree A. Some state is needed to handle this.
+Before starting the export of tree A, record it somewhere. Then when
+resuming, diff A..B, and delete the temp names of the keys in the
+diff. (Can't rename here, because we don't know what was the content
+of a file when an export was interrupted.)
+
+So, before an export does anything, need to record the tree that's about
+to be exported to export.log, not as an exported tree, but as a goal.
+Then on resume, the temp files for that can be cleaned up.
+
+## renames and export conflicts
+
+What is there's an export conflict going on at the same time that a file
+in the export gets renamed?
+
+Suppose that there are two git repos A and B, each exporting to the same
+remote. A and B are not currently communicating. A exports T1 which
+contains F. B exports T2, which has a different content for F. 
+
+Then A exports T3, which renames F to G. If that rename is done
+on the remote, then A will think it's successfully exported T3,
+but G will have F's content from T2, not from T1.
+
+When A and B reconnect, the export conflict will be detected. 
+To resolve the export conflict, it says above to:
+
+> To resolve, diff each exported tree in turn against the resolving tree
+> and delete all files that differ. Then, upload all missing files.
+
+Assume that the resolving tree is T3. So B's export of T2 is diffed against
+T3. F differs and is deleted (no change). G differs and is deleted,
+which fixes up the problem that the wrong content was renamed to G.
+G is missing so gets uploaded.
+
+So, this works, as long as "delete all files that differ" means it
+deletes both old and new files. And as long as conflict resolution does not
+itself stash away files in the temp name for later renaming.
+
+## dropping from exports and copying to exports
+
+It might be nice for `git annex drop $file --from myexport` and
+`git annex copy $myfile --to export` to work. However, there are some
+very difficult issues in supporting those, and they don't really
+seem necessary to use exports. Re-running `git annex export`
+to resume an export handles all the cases that copying to an export
+would need to. And, deleting a file from a tree and exporting the new tree
+is the thing to do if a file no longer should be exported.
+
+Here's an example of the kind of problem supporting these needs to deal with:
+
+1. In repo A, file F with content K is exported
+2. In repo B, file F with content K' is exported, since F changed in the
+   exported treeish.
+3. In repo A, file F is removed from the export, which results in
+   K being removed from the location log for the export.
+
+But... did #3 happen before or after #2?
+If #3 occurred before #2, then K' is present in the export
+and the location log is correct.
+If #3 occurred after #2, and A and B's git-annex branches
+were not synced, then K' was accidentially removed
+from the export, and the location log is now wrong.
+
+Is there any reason to allow removeKey from an export?
+Why would someone want to drop a single file from an export?
+Why not remove the file from a tree, and export the new tree?
+
+(Alternatively, removeKey could itself update the exported tree,
+removing the file from it, and update the export log accordingly.
+This would avoid the problem. But that's complication and it would be
+rather slow and bloat the git repo with a lot of intermediate trees
+when dropping multiple keys.)
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_10_75ba45174d3c4b927113a6908061b742._comment b/doc/design/exporting_trees_to_special_remotes/comment_10_75ba45174d3c4b927113a6908061b742._comment
new file mode 100644
index 0000000000..15a28e7ced
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_10_75ba45174d3c4b927113a6908061b742._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="export &quot;each revision&quot; -- thinking about quiltdata"
+ date="2017-07-14T20:10:42Z"
+ content="""
+In some cases, if remote supports versioning, might be cool to be able to export all versions (from previously exported point, assuming linear progression).
+Having a chat with [https://quiltdata.com/](https://quiltdata.com/) folks, project which I just got to know about.
+1. They claim/hope to provide infinite storage for public datasets
+2. They do support \"File\" model, so dataset could simply contain files.  If we could (ab)use that -- sounds like a lovely free ride
+3. They do support versioning. If we could export all the versions -- super lovely.  
+
+Might also help to establish interoperability between the tools
+
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_11_0827f5611c8e7e7ffa2633f8c06ae055._comment b/doc/design/exporting_trees_to_special_remotes/comment_11_0827f5611c8e7e7ffa2633f8c06ae055._comment
new file mode 100644
index 0000000000..6cb922e817
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_11_0827f5611c8e7e7ffa2633f8c06ae055._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="Git History"
+ date="2017-08-10T00:25:27Z"
+ content="""
+It would be great to have an option to include git history in the export, such that a special remote could be used both to rebuild a repository and to view the contents.
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_12_1bb8d57383ca733f3a0069ff30181366._comment b/doc/design/exporting_trees_to_special_remotes/comment_12_1bb8d57383ca733f3a0069ff30181366._comment
new file mode 100644
index 0000000000..a039beb5f8
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_12_1bb8d57383ca733f3a0069ff30181366._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: export &quot;each revision&quot;"""
+ date="2017-08-15T18:13:38Z"
+ content="""
+That sounds much more like a regular remote with `git annex copy --all`.
+
+This entire design is preducated on exporting a single treeish. If you want
+to make a single treeish containing all versions of every file ...
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_13_f857e15124b70ae1abc74669f63a2d68._comment b/doc/design/exporting_trees_to_special_remotes/comment_13_f857e15124b70ae1abc74669f63a2d68._comment
new file mode 100644
index 0000000000..951827d494
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_13_f857e15124b70ae1abc74669f63a2d68._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: Git History"""
+ date="2017-08-15T18:16:31Z"
+ content="""
+That is entirely out of scope. You're looking for a way to store a git
+*repository* someplace like S3. Such things exist already, and are not
+git-annex and I'm not going to replicate them as part of this feature.
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_14_41e8ef74c6e62a4321d2046b2571a246._comment b/doc/design/exporting_trees_to_special_remotes/comment_14_41e8ef74c6e62a4321d2046b2571a246._comment
new file mode 100644
index 0000000000..45b675572e
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_14_41e8ef74c6e62a4321d2046b2571a246._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: comments on protocol"""
+ date="2017-08-15T18:18:14Z"
+ content="""
+In `TRANSFEREXPORT STORE|RETRIEVE Key File Name`, it should always
+be possible for the File to not contain spaces in its name. But it could be
+rather painful for git-annex to avoid spaces in some cases (would need to
+link or copy the annexed file content). So well spotted. 
+
+Hmm, it's actually possible for a Key to contain spaces as well,
+at least with the WORM backend.
+[[bugs/external_special_remote_protocol_broken_by_key_with_spaces]]
+
+The protocol `VERSION` is picked by the special remote, it's not
+negotiated.
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_15_3fc518cee1a11b28da769c0915d33e3b._comment b/doc/design/exporting_trees_to_special_remotes/comment_15_3fc518cee1a11b28da769c0915d33e3b._comment
new file mode 100644
index 0000000000..f0de4d49a0
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_15_3fc518cee1a11b28da769c0915d33e3b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2017-08-28T19:00:10Z"
+ content="""
+Since [[bugs/external_special_remote_protocol_broken_by_key_with_spaces]]
+was fixed, the Key can't contain spaces any longer.
+
+The File could still contain spaces, eg when exporting from a direct mode
+repository where the worktree filename contains spaces.
+
+In `RENAMEEXPORT`, both OldName and NewName could contain spaces.
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_16_29f598eda413c0d5e17536d8f9438d31._comment b/doc/design/exporting_trees_to_special_remotes/comment_16_29f598eda413c0d5e17536d8f9438d31._comment
new file mode 100644
index 0000000000..98a9f93f04
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_16_29f598eda413c0d5e17536d8f9438d31._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2017-08-28T19:32:06Z"
+ content="""
+I've updated the proposed external special remote protocol to avoid the
+whitespace concerns. Not wild about needing a separate EXPORT request,
+which will probably get shoved into a global variable in most
+implementations. But it does avoid needing to use some kind of encoding,
+which would complicate implementations more, I feel.
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_17_32a3240206c5ffff71a47dffa6950c48._comment b/doc/design/exporting_trees_to_special_remotes/comment_17_32a3240206c5ffff71a47dffa6950c48._comment
new file mode 100644
index 0000000000..2afef92a8f
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_17_32a3240206c5ffff71a47dffa6950c48._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="protocol message "
+ date="2018-02-06T20:03:27Z"
+ content="""
+joey wrote:
+
+    The protocol VERSION is picked by the special remote, it's not negotiated.
+
+`VERSION ` is provided to git-annex by the special remote to git-annex process.  There is no need to 'negotiate' anything - you could make git-annex understand either of:
+
+- higher `VERSION `, e.g. 
+
+  - `VERSION 2` which would support some new features which that special remote would need.  If parent git-annex is old/doesn't support that version - would fail and demand git annex upgrade
+  - `VERSION 6.20171124` (where `6.20171124` is an example of git-annex version) so if git-annex parent process is older than that it could provide a meaningful message that `git annex >= 6.20171124` is needed
+
+- `VERSION 1 feature1 feature2 ...` where those features could be the ones needed (e.g. `INFO_MSG` for [recent addition](http://git-annex.branchable.com/todo/INFO_message_for_custom_special_remotes/#comment-4dcfb7d4e6db9d5ba8a1bfeb782346b1)). And if parent git-annex doesn't know/support any particular feature, it could fail and inform user that a new annex with that feature support is needed.
+
+In either of those cases the custom special remotes page could outline added features/versions of git-annex supporting them, so may be even those above error messages could point to it.
+
+Overall, it is just a minor change to be done on git-annex side while allowing for clear(er) specification, and I do not see any need for actual \"negotiation\" -- features are either supported or not by the parent process.
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_18_fe77370699b7ce0acd547fd1e045e254._comment b/doc/design/exporting_trees_to_special_remotes/comment_18_fe77370699b7ce0acd547fd1e045e254._comment
new file mode 100644
index 0000000000..bebfee6ed5
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_18_fe77370699b7ce0acd547fd1e045e254._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 18"""
+ date="2018-02-07T16:43:02Z"
+ content="""
+Changing VERSION would prevent any older versions of git-annex from working
+with that external special remote, since they would reject the unknown
+version. (The current parsing of VERSION also happens to preclude adding
+some fields after the number.)
+
+Since it seems completely possible to make the protocol be changed in a way
+that is backwards compatible both ways, while still letting new features to
+be used, I'd rather reserve changing VERSION for whatever future thing
+needs a full breaking bump.
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_19_00d28c758509939974e4583e9b1b9e12._comment b/doc/design/exporting_trees_to_special_remotes/comment_19_00d28c758509939974e4583e9b1b9e12._comment
new file mode 100644
index 0000000000..5e1835eb3d
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_19_00d28c758509939974e4583e9b1b9e12._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 19"
+ date="2018-02-07T18:31:45Z"
+ content="""
+> Changing VERSION would prevent any older versions of git-annex from working with that external special remote, since they would reject the unknown version. (The current parsing of VERSION also happens to preclude adding some fields after the number.)
+
+I still do not get it, sorry -- If there is an older git-annex, and a special remote requests some higher VERSION (thus stating that it needs some features older git-annex does not support), IMHO it would be perfectly fine to fail to use that remote since it wouldn't be usable anyways with that older git-annex (i.e. require some special features it does not provide).  If special remote does not need any feature not present in version `1`, it (like all of them ATM) could still keep requesting `VERSION 1` thus staying compatible with whatever old git-annex is out there.
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_19_1eda1af40f6ca82a8bacd19afaa749bc._comment b/doc/design/exporting_trees_to_special_remotes/comment_19_1eda1af40f6ca82a8bacd19afaa749bc._comment
new file mode 100644
index 0000000000..c67370a074
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_19_1eda1af40f6ca82a8bacd19afaa749bc._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2018-02-07T19:04:03Z"
+ content="""
+What if the remote wants to use some feature like NOTE, but can still
+manage to work when an old git-annex does not support it? Hard bumping the
+VERSION cannot support that. If the remote requires to be able to use NOTE
+and sees it cannot, it can still throw an error.
+
+There are a bunch of requests in the protocol that are optional for the
+remote to support; git-annex deals with remotes that don't support them in
+better ways than throwing up its hands because the special remote is too
+old. It's very good that the protocol allowed adding those extensions
+without bumping a version. The protocol is less extensible when it comes
+replies and other messages sent by the special remote, and I want to get
+the same extensibility for those.
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_1_ea84ee9de604e05b8e02483ba8452186._comment b/doc/design/exporting_trees_to_special_remotes/comment_1_ea84ee9de604e05b8e02483ba8452186._comment
new file mode 100644
index 0000000000..c6e7c7aedd
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_1_ea84ee9de604e05b8e02483ba8452186._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="note that some remotes could support files versioning &quot;natively&quot;"
+ date="2017-07-11T21:59:49Z"
+ content="""
+E.g. when exporting to the S3 bucket with versioning turned on, or OSF (AFAIK).  So upon successful upload special remote could SETURLPRESENT to signal availability of any particular key (associated with the file).
+
+Yet to grasp the cases you outlined better to see if I see any other applicable use-ase
+
+I hope that export would be implemented through extending externals special remote protocol? ;)
+
+[[!meta author=yoh]]
+
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_21_062098e1f54b874467793e4487a45a9b._comment b/doc/design/exporting_trees_to_special_remotes/comment_21_062098e1f54b874467793e4487a45a9b._comment
new file mode 100644
index 0000000000..dfb5cb4569
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_21_062098e1f54b874467793e4487a45a9b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 21"
+ date="2018-02-07T20:01:53Z"
+ content="""
+Ok, gotcha.  Shouldn't then EXTENSION entries also be somehow versioned per each one of them? or if needed a new extension would be born by appending a version to its name (e.g. as with all those imap, imap2, imap3, ... ;-))
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_2_d414fb575845770e003a3c8ca4a986be._comment b/doc/design/exporting_trees_to_special_remotes/comment_2_d414fb575845770e003a3c8ca4a986be._comment
new file mode 100644
index 0000000000..f0fc092ad4
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_2_d414fb575845770e003a3c8ca4a986be._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="couldn't STATE be used for KEY -> FILENAME(s) mapping?"
+ date="2017-07-11T22:05:49Z"
+ content="""
+just wondered...
+at least in my attempt for zenodo special remote I did store zenodo's file deposition ID within the state to be able to request it back later on
+alternative -- URL(s) I guess.  Could be smth like exported:UUID/filename.
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_3_cb063cdc66df79c40039bce247b7170c._comment b/doc/design/exporting_trees_to_special_remotes/comment_3_cb063cdc66df79c40039bce247b7170c._comment
new file mode 100644
index 0000000000..377d167f73
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_3_cb063cdc66df79c40039bce247b7170c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="does it really need to be a new command (&quot;export&quot;) or could be the same old &quot;copy&quot;?"
+ date="2017-07-11T22:14:39Z"
+ content="""
+or it could be just a mode of operation for a special remote depending on \"exporttree=true\" being set, where in one (old) case it would operate based on keys associated with the files pointed on the cmdline (or just keys for --auto or pointed by metadata), whenever when \"exporttree=true\" -- it would operate on filenames pointed on command line (or files found to be associated with the keys as pointed by --auto or by metadata)? 
+Then the same 'copy --to' could be used in both cases, streamlining user experience ;) 
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_4_126ee5332ff88b3993d33d59328d4148._comment b/doc/design/exporting_trees_to_special_remotes/comment_4_126ee5332ff88b3993d33d59328d4148._comment
new file mode 100644
index 0000000000..89bc18d4c8
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_4_126ee5332ff88b3993d33d59328d4148._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-07-12T16:45:51Z"
+ content="""
+I've added a section with changes to the external special remote protocol.
+I included the Key in each of the new protocol commands, although it's not
+strictly neeed, to allow the implementation to use SETURLPRESENT, SETSTATE,
+etc.
+
+`git annex copy $file --to myexport` could perhaps work; the difficulty
+though is, what if you've exported branch foo, and then checked out bar,
+and so you told it to export one version of the file, and are running
+git-annex copy on a different version? It seems that git-annex would have
+to cross-check in this and similar commands, to detect such a situation. 
+Unsure how much more work that would be, both CPU time and implementation
+time.
+
+I do think that `git annex get` could download files from exports easily
+enough, but see the "location tracking" section for trust caveats.
+
+I'm not clear about what you're suggesting be done with versioning support
+in external special remotest?
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_5_fcd9890013371dae6ffcd00561b8c625._comment b/doc/design/exporting_trees_to_special_remotes/comment_5_fcd9890013371dae6ffcd00561b8c625._comment
new file mode 100644
index 0000000000..fb73f0622d
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_5_fcd9890013371dae6ffcd00561b8c625._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="special remotes with versioning support"
+ date="2017-07-12T17:30:33Z"
+ content="""
+thanks -- I will check those all out!
+
+Meanwhile a quick one regarding \"I'm not clear about what you're suggesting be done with versioning support in external special remotes?\".
+
+I meant that in some cases there might be no need for any custom/special tracking per exported file would be needed -- upon export we could just register a unique URL for that particular version of the file for the corresponding KEY so later on it could be 'annex get'ed even if a new version of the file gets uploaded or removed.  So annex could just store those treeish(es) hexsha on what was exported last without any explicit additional tracking per file.  URL might be some custom one to be handled by the special remote backend.
+
+E.g. here is a list of versions (and corresponding urls) for a sample file on the s3 bucket
+
+[[!format sh \"\"\"
+$> datalad ls -aL s3://datalad-test0-versioned/3versions-allversioned.txt 
+Connecting to bucket: datalad-test0-versioned
+[INFO   ] S3 session: Connecting to the bucket datalad-test0-versioned 
+Bucket info:
+  Versioning: {'MfaDelete': 'Disabled', 'Versioning': 'Enabled'}
+     Website: datalad-test0-versioned.s3-website-us-east-1.amazonaws.com
+         ACL: <Policy: yoh@cs.unm.edu (owner) = FULL_CONTROL>
+3versions-allversioned.txt            ...  http://datalad-test0-versioned.s3.amazonaws.com/3versions-allversioned.txt?versionId=Kvuind11HZh._dCPaDAb0OY9dRrQoTMn [OK]
+3versions-allversioned.txt            ...  http://datalad-test0-versioned.s3.amazonaws.com/3versions-allversioned.txt?versionId=b.qCuh7Sg58VIYj8TVHzbRS97EvejzEl [OK]
+3versions-allversioned.txt            ...  http://datalad-test0-versioned.s3.amazonaws.com/3versions-allversioned.txt?versionId=pNsV5jJrnGATkmNrP8.i_xNH6CY4Mo5s [OK]
+3versions-allversioned.txt_sameprefix ...  http://datalad-test0-versioned.s3.amazonaws.com/3versions-allversioned.txt_sameprefix?versionId=Mvsc4FgJWc6gExwSw1d6wsLrnk6wdDVa [OK]
+\"\"\"]]
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_6_3217c2f852e5d9b1e4be2adff995dd24._comment b/doc/design/exporting_trees_to_special_remotes/comment_6_3217c2f852e5d9b1e4be2adff995dd24._comment
new file mode 100644
index 0000000000..4b1265bdd4
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_6_3217c2f852e5d9b1e4be2adff995dd24._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2017-07-12T18:09:00Z"
+ content="""
+That would almost work without any smarts on the git-annex side.
+When it tells the special remote to `REMOVEEXPORT`, the special remote
+could remove the file from the HEAD equivilant but retain the content in its
+versioned snapshots, and keep the url to that registered. But, that
+doesn't actually work, because the url is registered for that special
+remote, not the web special remote. Once git-annex thinks the file has been
+removed from the special remote, it will never try to use the url
+registered for that special remote.
+
+So, to support versioning-capable special remotes, there would need to be
+an additional response to `REMOVEEXPORT` that says "I removed it from HEAD,
+but I still have a copy in this url, which can be accessed using
+the web special remote".
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_7_43a98b4b9d9eb54720a9c92cd8bb3a30._comment b/doc/design/exporting_trees_to_special_remotes/comment_7_43a98b4b9d9eb54720a9c92cd8bb3a30._comment
new file mode 100644
index 0000000000..0ba8327bd8
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_7_43a98b4b9d9eb54720a9c92cd8bb3a30._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="side-note about WebDAV&DeltaV"
+ date="2017-07-12T21:54:49Z"
+ content="""
+DAV = “Distributed Authoring and Versioning.”, but versioning was forgotten about in the original RFC. Only some servers/clients implement DeltaV spec (RFC 3253) which came later to fill that gap. 
+But in principle, any DeltaV-compliant WebDAV special remote could then be used for \"export\" while retaining access to all the versions.
+References: 
+- [WebDAV and Autoversioning - Version Control with Subversion](http://archive.oreilly.com/pub/a/opensource/excerpts/9780596510336/webdav-and-autoversioning.html)
+- [RFC 3253](http://www.webdav.org/specs/rfc3253.html)
+
+I have got interested whenever saw that box.com is supported through WebDAV but not sure if DeltaV is anyhow supported and apparently number of versions stored per file is anyways depends on type of the account (and no versions for a free personal one): https://community.box.com/t5/How-to-Guides-for-Managing/How-To-Track-Your-Files-and-File-Versions-Version-History/ta-p/329 
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_8_7e512ef81c529b0392071b8a6dfe853b._comment b/doc/design/exporting_trees_to_special_remotes/comment_8_7e512ef81c529b0392071b8a6dfe853b._comment
new file mode 100644
index 0000000000..eef7d08cab
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_8_7e512ef81c529b0392071b8a6dfe853b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="regarding setting a URL by custom special remote"
+ date="2017-07-12T22:04:38Z"
+ content="""
+I also wonder if `SETURLPRESENT Key Url` could also be extended to be `SETURLPRESENT Key Url Remote`, i.e. that a custom remote could register a URL to Web remote?
+In many cases I expect a \"custom uploader/exporter\" but then public URL being available, so demanding a custom external remote to fetch it would be a bit overkill.
+
+N.B. I already was burnt once on a large scale with our custom remote truthfully replying to CLAIMURL (since it can handle them if needed) to public URLs, thus absorbing them into it instead of relaying responsibility to 'Web' remote. Had to traverse dozens of datasets and duplicate urls from 'datalad' to 'Web' remote.
+"""]]
diff --git a/doc/design/exporting_trees_to_special_remotes/comment_9_6c588170f0b53c74c3c28ff08ed3509d._comment b/doc/design/exporting_trees_to_special_remotes/comment_9_6c588170f0b53c74c3c28ff08ed3509d._comment
new file mode 100644
index 0000000000..54b1f8ada7
--- /dev/null
+++ b/doc/design/exporting_trees_to_special_remotes/comment_9_6c588170f0b53c74c3c28ff08ed3509d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comments on protocol"
+ date="2017-07-12T22:09:54Z"
+ content="""
+- `TRANSFEREXPORT STORE|RETRIEVE Key File Name`  -- note that File could also contain spaces etc (not only the Name), so should be encoded somehow?
+- `old external special remote programs ... need to handle an ERROR response` -- why not just to boost protocol `VERSION` to e.g. `2` so those which implement this would reply with a new version #?
+"""]]
diff --git a/doc/design/external_backend_protocol.mdwn b/doc/design/external_backend_protocol.mdwn
new file mode 100644
index 0000000000..8168099ddc
--- /dev/null
+++ b/doc/design/external_backend_protocol.mdwn
@@ -0,0 +1,188 @@
+Communication between git-annex and a program implementing an external
+[[backend|backends]] uses this protocol.
+
+[[!toc ]]
+
+## starting the program
+
+The external backend program has a name like `git-annex-backend-XFOO`.
+When git-annex is configured to use a backend starting with "X", 
+or encounters a key in a repository starting with "X", it
+looks for the corresponding external backend program in PATH.
+
+The program is started by git-annex when it needs to use it, and may be
+left running for a long period of time. Note that git-annex may choose to
+run multiple instances of the program.
+
+## protocol overview
+
+Communication is via stdin and stdout. While stderr is connected to the
+console and so visible to the user, the program should avoid using it
+except for in the most exceptional circumstances.
+
+The protocol is line based. git-annex sends a request, and the program
+responds with a reply.
+
+Each protocol line starts with a command, which is followed by the
+command's parameters (a fixed number per command), each separated by a
+single space. The last parameter may contain spaces. Parameters may be
+empty, but the separating spaces are still required in that case.
+
+## example session
+
+git-annex always starts by sending a message asking the program what protocol
+version it uses.
+
+	GETVERSION
+
+The program responds.
+
+	VERSION 1
+
+git-annex will next query the program about the properties of the keys it
+uses (`CANVERIFY`, `ISSTABLE`, `ISCRYPTOGRAPHICALLYSECURE`), and the program will
+respond to each query.
+
+Then git-annex may ask the program to generate a key.
+
+	GENKEY somefile
+
+The program will respond with the key it generated, but if it needs to do
+an expensive operation, such as hashing the file, it can first send
+progress messages, indicating the position in the file it has processed.
+
+	PROGRESS 1024
+	PROGRESS 2048
+	GENKEY-SUCCESS XFOO-s2048--dbd009
+
+git-annex can also ask the program to verify if the content of a file
+matches a key.
+
+	VERIFYKEYCONTENT XFOO-s2048--dbd009 somefile
+
+Again the program can send progress messages as it works, finishing
+with the result of the verification.
+
+	PROGRESS 1024
+	PROGRESS 2048
+	VERIFYKEYCONTENT-SUCCESS
+
+## startup messages and replies
+
+These messages are sent to the program soon after starting it, and it should
+reply with one of the listed replies.
+
+* `GETVERSION`  
+  Always the first message sent.  
+  Currently the only version of this protocol is version 1.
+  * `VERSION 1`  
+* `CANVERIFY`  
+  Asks if the program can verify the content of files match a key it generated.
+  The verification does not need to be cryptographically secure, but should
+  catch data corruption.
+  * `CANVERIFY-YES`
+  * `CANVERIFY-NO`
+* `ISSTABLE`  
+  Asks the program if a key it has generated will always have the same
+  content. The answer to this is almost always yes; URL keys are an example
+  of a type of key that may have different content at different times.
+  * `ISSTABLE-YES`
+  * `ISSTABLE-NO`
+* `ISCRYPTOGRAPHICALLYSECURE`  
+  Asks the program if keys it generates are verified using a cryptographically
+  secure hash. Note that sha1 is *not* a cryptographically secure hash any
+  longer. A program can change its answer to this question as the state of the
+  art advances, and should aim to stay ahead of the state of the art by a
+  reasonable amount of time.
+  * `ISCRYPTOGRAPHICALLYSECURE-YES`
+  * `ISCRYPTOGRAPHICALLYSECURE-NO`
+
+## main messages and replies
+
+This is where work happens.
+
+* `GENKEY Contentfile`  
+  The program should examine the ContentFile and from it generate a
+  key. While it is doing this, it can send any number of `PROGRESS`
+  messages indication the position in the file that it's gotten to.
+  * `GENKEY-SUCCESS Key`
+  * `GENKEY-FAILURE ErrorMsg`
+* `VERIFYKEYCONTENT Key ContentFile`  
+  The program should examine the ContentFile and verify that it has the
+  content it would expect for the Key. While it is doing this, it can
+  send any number of `PROGRESS` messages indication the position in the
+  file that it's gotten to. (If the program earlier sent `CANVERIFY-NO`,
+  it will not be asked to do this.)
+  * `VERIFYKEYCONTENT-SUCCESS`
+  * `VERIFYKEYCONTENT-FAILURE`
+
+## general messages
+
+These messages can be sent at any time by either git-annex or the program.
+
+* `DEBUG message`  
+  Tells git-annex to display the message if --debug is enabled.  
+  (git-annex does not send a reply to this message.)
+* `ERROR ErrorMsg`  
+  Generic error. Can be sent at any time if things get too messed up to
+  continue. When possible, use a more specific reply.  
+  The program should exit after sending this, as git-annex will not talk to
+  it any further. If the program receives an `ERROR` from git-annex, it can
+  exit with its own `ERROR`.
+
+## considerations for generating keys
+
+See [[internals/key_format]] for how to format a key and details about the
+parts of a key.
+
+The backend name should match the name of the program, eg if the program
+is git-annex-backend-XFOO, it should generate a key starting with "XFOO-".
+
+The backend name (and program name) has to be all uppercase, and should be
+reasonably short (max 10 bytes or so), and should be entirely ascii
+alphanumerics. Eg, use similar names to other [[backends]]. It must not end
+with "E" (see next paragraph for why).
+
+git-annex will automatically also support an "E" variant of the backend,
+which adds a filename extension to the end of the key. It does this
+entirely transparently to the program, so while the repository may be using
+XFOOE keys, the program will always generate and verify XFOO keys.
+
+The key name is typically some kind of hash, but is not limited to a hash.
+The length of it needs to be similar to the lengths of other git-annex
+keys. Too long a key name will make it annoying to work with repositories
+using them, or even cause problems due to filename length limits. 128 bytes
+maximum, but shorter is better. It should be entirely ascii characters
+in the set `A-Za-z0-9` and `-` is allowed, but other punctuation is not.
+
+It's important that, if the program responds with
+`ISCRYPTOGRAPHICALLYSECURE-YES`, the key name contains only a hash, and not
+other data from some other source. That other data could be used to try to
+mount a sha1 collision attack against git, by embedding colliding material
+in the key name, where users are unlikely to notice it. While git has
+several things that make sha1 collision attacks difficult, we don't want
+this chink in the armor.
+
+It's almost always a good idea to include the size field when generating a
+key. The size does not need to be checked when verifying content, as
+git-annex handles that for you. The only time it would make sense to omit
+the size field is if the content of a key is not stable and might have
+different sizes (like some URL keys do).
+
+There's generally no reason to include the mtime field, and it should
+never be verified when verifying content.
+
+## program names must be unique
+
+It's important that two different programs don't use the same name, because
+that would result in bad behavior if the wrong program were used with a
+repository with keys generated by the other program.
+
+To avoid picking the same name, there is a list of known external backend
+programs in [[backends]].
+
+## signals
+
+The program should not block SIGINT, or SIGTERM. Doing so may cause
+git-annex to hang waiting on it to exit. Of course it's ok to catch those
+signals and do some necessary cleanup before exiting.
diff --git a/doc/design/external_backend_protocol/comment_1_7a55199030c3b9f455354139af7dbac0._comment b/doc/design/external_backend_protocol/comment_1_7a55199030c3b9f455354139af7dbac0._comment
new file mode 100644
index 0000000000..09d889d803
--- /dev/null
+++ b/doc/design/external_backend_protocol/comment_1_7a55199030c3b9f455354139af7dbac0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="key length"
+ date="2020-07-30T15:13:49Z"
+ content="""
+\"128 bytes maximum\" key length -- maybe a bit shorter to support the E variant?
+"""]]
diff --git a/doc/design/external_backend_protocol/comment_2_e6005a7563a65c0fd4615cc3f2c3034b._comment b/doc/design/external_backend_protocol/comment_2_e6005a7563a65c0fd4615cc3f2c3034b._comment
new file mode 100644
index 0000000000..5ff341183e
--- /dev/null
+++ b/doc/design/external_backend_protocol/comment_2_e6005a7563a65c0fd4615cc3f2c3034b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-07-31T20:05:42Z"
+ content="""
+SHA512 backend has 128 bytes key name, that's where I got that suggestion
+from. Some filesystems have limits around 255 bytes for the name of a file,
+so that leaves plenty for extension, and the rest of the parts of the key.
+Realistically, the length of a SHA256 is a better goal.
+
+Of course, if you had a crazy 1025 byte hash and wanted to use it on IDK,
+GNU Hurd or something, you could do it, but your repo
+would not be portable to eg Linux with its 1024 byte filename limit.
+git-annex itself does not care though, and I *think* git would also not
+care.
+"""]]
diff --git a/doc/design/external_backend_protocol/comment_3_cd3410e6c1088289f71ed30b34d802f9._comment b/doc/design/external_backend_protocol/comment_3_cd3410e6c1088289f71ed30b34d802f9._comment
new file mode 100644
index 0000000000..12a7c7bb08
--- /dev/null
+++ b/doc/design/external_backend_protocol/comment_3_cd3410e6c1088289f71ed30b34d802f9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="ah.nikfal@ad3e37b2c18d5aea546f662a0ba95796d0ef33ed"
+ nickname="ah.nikfal"
+ avatar="http://cdn.libravatar.org/avatar/0705936f3b4b8300018ce0ab62a114e5"
+ subject="How to use git-annex-backend-XFOO"
+ date="2022-12-09T12:58:57Z"
+ content="""
+After creating git-annex-backend-XFOO, how should I use this file? Where should I put this file?
+"""]]
diff --git a/doc/design/external_backend_protocol/comment_4_5b9814ca55e5fab94725ecdb5b1618f0._comment b/doc/design/external_backend_protocol/comment_4_5b9814ca55e5fab94725ecdb5b1618f0._comment
new file mode 100644
index 0000000000..f9d1ae371d
--- /dev/null
+++ b/doc/design/external_backend_protocol/comment_4_5b9814ca55e5fab94725ecdb5b1618f0._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="installing custom backend scripts "
+ date="2022-12-11T19:22:17Z"
+ content="""
+>After creating git-annex-backend-XFOO, how should I use this file? Where should I put this file?
+
+Put it somewhere in your PATH.  Make sure the script it executable.
+
+Just for curiosity, what hashing scheme does your custom backend implement?
+
+"""]]
diff --git a/doc/design/external_backend_protocol/comment_5_75ff466d7eeccd1eda9f8f18f465b296._comment b/doc/design/external_backend_protocol/comment_5_75ff466d7eeccd1eda9f8f18f465b296._comment
new file mode 100644
index 0000000000..97f4ef9c31
--- /dev/null
+++ b/doc/design/external_backend_protocol/comment_5_75ff466d7eeccd1eda9f8f18f465b296._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="ah.nikfal@ad3e37b2c18d5aea546f662a0ba95796d0ef33ed"
+ nickname="ah.nikfal"
+ avatar="http://cdn.libravatar.org/avatar/0705936f3b4b8300018ce0ab62a114e5"
+ subject="xxHash as the backend"
+ date="2022-12-12T08:21:35Z"
+ content="""
+I'm trying to use xxHash as the backend.
+Just one side issue. There isn't any repo for git-annex in github? So we could easily create issues and discuss about relevant problems.
+"""]]
diff --git a/doc/design/external_backend_protocol/git-annex-backend-XFOO b/doc/design/external_backend_protocol/git-annex-backend-XFOO
new file mode 100755
index 0000000000..59ae24c559
--- /dev/null
+++ b/doc/design/external_backend_protocol/git-annex-backend-XFOO
@@ -0,0 +1,58 @@
+#!/bin/sh
+# Demo git-annex external backend program.
+# 
+# Install in PATH as git-annex-backend-XFOO
+#
+# Copyright 2020 Joey Hess; licenced under the GNU GPL version 3 or higher.
+
+set -e
+
+hashfile () {
+	local contentfile="$1"
+	# could send PROGRESS while doing this, but it's
+	# hard to implement that in shell
+	md5sum "$contentfile" | cut -d ' ' -f 1 || echo ''
+}
+
+while read line; do
+	set -- $line
+	case "$1" in
+		GETVERSION)
+			echo VERSION 1
+		;;
+		CANVERIFY)
+			echo CANVERIFY-YES
+		;;
+		ISSTABLE)
+			echo ISSTABLE-YES
+		;;
+		ISCRYPTOGRAPHICALLYSECURE)
+			# md5 is not cryptographically secure
+			echo ISCRYPTOGRAPHICALLYSECURE-NO
+		;;
+		GENKEY)
+			contentfile="$2"
+			hash=$(hashfile "$contentfile")
+			sz=$(wc -c "$contentfile" | cut -d ' ' -f 1)
+			if [ -n "$hash" ]; then
+				echo "GENKEY-SUCCESS" "XFOO-s$sz--$hash"
+			else
+				echo "GENKEY-FAILURE" "md5sum failed"
+			fi
+		;;
+		VERIFYKEYCONTENT)
+			key="$2"
+			contentfile="$3"
+			hash=$(hashfile "$contentfile")
+			khash=$(echo "$key" | sed 's/.*--//')
+			if [ "$hash" = "$khash" ]; then
+				echo "VERIFYKEYCONTENT-SUCCESS"
+			else
+				echo "VERIFYKEYCONTENT-FAILURE"
+			fi
+		;;
+		*)
+			echo ERROR protocol error
+		;;
+	esac
+done
diff --git a/doc/design/external_special_remote_protocol.mdwn b/doc/design/external_special_remote_protocol.mdwn
new file mode 100644
index 0000000000..26a4a51858
--- /dev/null
+++ b/doc/design/external_special_remote_protocol.mdwn
@@ -0,0 +1,554 @@
+Communication between git-annex and a program implementing an external
+special remote uses this protocol.
+
+[[!toc]]
+
+## starting the program
+
+The external special remote program has a name like
+`git-annex-remote-$bar`. When 
+`git annex initremote foo type=external externaltype=$bar` is run,
+git-annex finds the appropriate program in PATH.
+
+The program is started by git-annex when it needs to access the special
+remote, and may be left running for a long period of time. This allows
+it to perform expensive setup tasks, etc. Note that git-annex may choose to
+start multiple instances of the program (eg, when multiple git-annex
+commands are run concurrently in a repository).
+
+## protocol overview
+
+Communication is via stdin and stdout. Therefore, the external special
+remote must avoid doing any prompting, or outputting anything like eg,
+progress to stdout. (Such stuff can be sent to stderr instead.)
+
+The protocol is line based. Messages are sent in either direction, from
+git-annex to the special remote, and from the special remote to git-annex.
+
+In order to avoid confusing interactions, one or the other has control
+at any given time, and is responsible for sending requests, while the other
+only sends replies to the requests.
+
+Each protocol line starts with a command, which is followed by the
+command's parameters (a fixed number per command), each separated by a
+single space. The last parameter may contain spaces. Parameters may be
+empty, but the separating spaces are still required in that case.
+
+## example session
+
+The special remote is responsible for sending the first message, indicating
+the version of the protocol it is using.
+
+	VERSION 2
+
+Recent versions of git-annex respond with a message indicating
+protocol extensions that it supports. Older versions of
+git-annex do not send this message.
+
+	EXTENSIONS INFO ASYNC GETGITREMOTENAME UNAVAILABLERESPONSE
+
+The special remote can respond to that with its own EXTENSIONS message, listing
+any extensions it wants to use. 
+(It's also fine to reply with UNSUPPORTED-REQUEST.)
+
+	EXTENSIONS 
+
+Next, git-annex will generally send a message telling the special
+remote to start up. (Or it might send an INITREMOTE or EXPORTSUPPORTED or
+LISTCONFIGS, or perhaps other things in the future, so don't hardcode this
+order.)
+
+	PREPARE
+
+The special remote can now ask git-annex for its configuration, as needed,
+and check that it's valid. git-annex responds with the configuration values
+
+	GETCONFIG directory
+	VALUE /media/usbdrive/repo
+	GETCONFIG automount
+	VALUE true
+
+Once the special remote is satisfied with its configuration and is
+ready to go, it tells git-annex that it's done with the PREPARE step:
+
+	PREPARE-SUCCESS
+
+Now git-annex will make a request. Let's suppose it wants to store a key. 
+
+	TRANSFER STORE somekey tmpfile
+
+The special remote can then start reading the tmpfile and storing it.
+While it's doing that, the special remote can send messages back to 
+git-annex to indicate what it's doing, or ask for other information.
+It will typically send progress messages, indicating how many
+bytes have been sent:
+
+	PROGRESS 10240
+	PROGRESS 20480
+
+Once the key has been stored, the special remote tells git-annex the result:
+
+	TRANSFER-SUCCESS STORE somekey
+
+Now git-annex will send its next request.
+
+Once git-annex is done with the special remote, it will close its stdin.
+The special remote program can then exit.
+
+## git-annex request messages and replies
+
+These are messages git-annex sends to the special remote program.
+
+Once the special remote has finished performing the request, it should
+send one of the listed replies.
+
+The following requests *must* all be supported by the special remote.
+
+* `INITREMOTE`  
+  Requests the remote to initialize itself. This is where any one-time
+  setup tasks can be done, for example creating an Amazon S3 bucket.  
+  Note: This may be run repeatedly over time, as a remote is initialized in
+  different repositories, or as the configuration of a remote is changed.
+  (Both `git annex initremote` and `git-annex enableremote` run this.)
+  So any one-time setup tasks should be done idempotently.
+  * `INITREMOTE-SUCCESS`  
+    Indicates the INITREMOTE succeeded and the remote is ready to use.
+  * `INITREMOTE-FAILURE ErrorMsg`  
+    Indicates that INITREMOTE failed.
+* `PREPARE`  
+  Tells the remote that it's time to prepare itself to be used.  
+  Only a few requests for details about the remote can come before this
+  (EXTENSIONS, INITREMOTE, EXPORTSUPPORTED, and LISTCONFIGS,
+  but others may be added later).
+  * `PREPARE-SUCCESS`  
+    Sent as a response to PREPARE once the special remote is ready for use.
+  * `PREPARE-FAILURE ErrorMsg`  
+    Sent as a response to PREPARE if the special remote cannot be used.
+* `TRANSFER STORE|RETRIEVE Key File`  
+  Requests the transfer of a key. This is the main thing a special remote
+  does. For STORE, the File contains the content to upload;
+  for RETRIEVE the File is where to store the content you download.  
+  When retrieving, the File may already exist, if its retieval was
+  interrupted before. That lets the remote resume downloading, if it's able
+  to.  
+  Note that the File should not influence the filename used on the remote;
+  that filename should be based on the Key.  
+  Note that in some cases, the File's name may include whitespace or other
+  special characters.  
+  While the transfer is running, the remote can send any number of
+  `PROGRESS` messages to indicate its progress. It can also send any of the
+  other special remote messages. Once the transfer is done, it finishes by
+  sending one of these replies:
+  * `TRANSFER-SUCCESS STORE|RETRIEVE Key`  
+    Indicates the transfer completed successfully.
+  * `TRANSFER-FAILURE STORE|RETRIEVE Key ErrorMsg`  
+    Indicates the transfer failed.
+* `CHECKPRESENT Key`  
+  Requests the remote to check if a key is present in it.  
+  It's important that, while a key is being transferred to a remote,
+  `CHECKPRESENT` not indicate it's present in the remote until all
+  the data has been sent.
+  * `CHECKPRESENT-SUCCESS Key`  
+    Indicates that a key has been positively verified to be present in the
+    remote.
+  * `CHECKPRESENT-FAILURE Key`  
+    Indicates that a key has been positively verified to not be present in the
+    remote.
+  * `CHECKPRESENT-UNKNOWN Key ErrorMsg`  
+    Indicates that it is not currently possible to verify if the key is
+    present in the remote. (Perhaps the remote cannot be contacted.)
+* `REMOVE Key`  
+  Requests the remote to remove a key's contents.
+  * `REMOVE-SUCCESS Key`  
+    Indicates the key has been removed from the remote. May be returned if
+    the remote didn't have the key at the point removal was requested.
+  * `REMOVE-FAILURE Key ErrorMsg`  
+    Indicates that the key was unable to be removed from the remote.
+
+Special remotes can optionally support tree exports and imports,
+which makes the [[git-annex-export]] and [[git-annex-import]] commands
+work with them. See the [[export_and_import_appendix]] for
+additional requests that git-annex will make when using special remotes in
+this way.
+
+The following requests can optionally be supported. If not supported,
+the special remote can reply with `UNSUPPORTED-REQUEST`.
+
+* `EXTENSIONS List`  
+  Sent to indicate protocol extensions which git-annex is capable
+  of using. The list is a space-delimited list of protocol extension
+  keywords. The remote can reply to this with its own EXTENSIONS list.
+  See the section on extensions below for details.
+  * `EXTENSIONS List`  
+    Sent in response to a EXTENSIONS request, to indicate the protocol
+    extensions that the special remote is using.
+* `LISTCONFIGS`  
+  Requests the remote to return a list of settings it uses (with
+  `GETCONFIG` and `SETCONFIG`). Providing a list makes `git annex initremote`
+  work better, because it can check the user's input, and can also display
+  a list of settings with descriptions. Note that the user is not required
+  to provided all the settings listed here. A block of responses
+  can be made to this, which must always end with `CONFIGEND`.  
+  (Do not include settings like "encryption" that are common to all external
+  special remotes.)
+  * `CONFIG Name Description`  
+    Indicates the name and description of a config setting. The description
+    should be reasonably short. Example:
+    "CONFIG directory store data here"
+  * `CONFIGEND`  
+    Indicates the end of the response block.
+* `GETCOST`  
+  Requests the remote to return a use cost. Higher costs are more expensive.
+  (See Config/Cost.hs for some standard costs.)
+  * `COST Int`  
+    Indicates the cost of the remote.
+* `GETAVAILABILITY`  
+  Asks the remote if it is locally or globally available.
+  (Ie stored in the cloud vs on a local disk.)  
+  If the remote replies with `UNSUPPORTED-REQUEST`, its availability
+  is assumed to be global. So, only remotes that are only reachable
+  locally need to worry about implementing this.  
+  This is queried at remote startup, so should avoid doing anything that
+  can take long to run or is expensive. Checking if a directory where the
+  remote stores files is currently mounted is the kind of thing it makes
+  sense to do here.
+  * `AVAILABILITY GLOBAL|LOCAL`  
+    Indicates if the remote is globally or only locally available.
+  * `AVAILABILITY UNAVAILABLE`  
+    Indicates that the remote is not currently available.  
+    This will prevent some git-annex commands like `git-annex sync` from
+    trying to use the remote.  
+    Older versions of git-annex do not support this response, so avoid
+    sending it unless the `UNAVAILABLERESPONSE` extension is enabled.
+* `CLAIMURL Url`  
+  Asks the remote if it wishes to claim responsibility for downloading
+  an url.
+  * `CLAIMURL-SUCCESS`  
+    Indicates that the CLAIMURL url will be handled by this remote.
+  * `CLAIMURL-FAILURE`  
+    Indicates that the CLAIMURL url wil not be handled by this remote.
+* `CHECKURL Url`  
+  Asks the remote to check if the url's content can currently be downloaded
+  (without downloading it).
+  * `CHECKURL-CONTENTS Size|UNKNOWN Filename`  
+    Indicates that the requested url has been verified to exist.  
+    The Size is the size in bytes, or use "UNKNOWN" if the size could not be
+    determined.  
+    The Filename can be empty (in which case a default is used),
+    or can specify a filename that is suggested to be used for this url.
+  * `CHECKURL-MULTI Url1 Size1|UNKNOWN Filename1 Url2 Size2|UNKNOWN Filename2 ...`  
+    Indicates that the requested url has been verified to exist,
+    and contains multiple files, which can each be accessed using
+    their own url.  Each triplet of url, size, and filename should be listed,
+    one after the other.
+    Note that since a list is returned, neither the Url nor the Filename
+    can contain spaces.
+  * `CHECKURL-FAILURE ErrorMsg`  
+    Indicates that the requested url could not be accessed.
+* `WHEREIS Key`  
+  Asks the remote to provide additional information about ways to access
+  the content of a key stored in it, such as eg, public urls.
+  This will be displayed to the user by eg, `git annex whereis`.
+  Note that users expect `git annex whereis` to run fast, without eg,
+  network access.  
+  * `WHEREIS-SUCCESS String`  
+    Indicates a location of a key. Typically an url, the string can
+    be anything that it makes sense to display to the user about content
+    stored in the special remote.
+  * `WHEREIS-FAILURE`  
+    Indicates that no location is known for a key.
+    This is not needed when `SETURIPRESENT` is used, since such uris are
+    automatically displayed by `git annex whereis`.  
+* `GETINFO`  
+  Requests the remote to send some information describing its
+  configuration, for display by `git annex info`. A block of responses
+  can be made to this, which must always end with `INFOEND`.
+  * `INFOFIELD Name`  
+    Gives the name of an info field. The name can be anything you want to
+    be displayed to the user. Must be immediately followed by `INFOVALUE`.
+  * `INFOVALUE Value`  
+    Gives the value of an info field.
+  * `INFOEND`  
+    Indicates the end of the response block.
+
+More optional requests may be added, without changing the protocol version,
+so if an unknown request is seen, don't crash, just reply with
+`UNSUPPORTED-REQUEST`.
+
+## special remote messages
+
+These messages may be sent by the special remote at any time that it's
+handling a request.
+
+* `VERSION Int`  
+  Supported protocol version. Current version is 2. Must be sent first
+  thing at startup, as until it sees this git-annex does not know how to
+  talk with the special remote program!  
+  (git-annex does not send a reply to this message, but may give up if it
+  doesn't support the necessary protocol version.)
+* `PROGRESS Int`  
+  Indicates the current progress of the transfer. The Int is the
+  number of bytes from the beginning of the file that have been
+  transferred.  
+  May be repeated any number of times during the transfer
+  process, but it's wasteful to update the progress too frequently.
+  Bear in mind that this is used both
+  to display a progress meter for the user, and for annex.stalldetection.
+  So, sending an update on each 1% of the file may not be frequent enough,
+  as it could appear to be a stall when transferring a large file.  
+  This is highly recommended for STORE.
+  (It is optional but good for RETRIEVE; git-annex will fall back to
+  tracking the size of the file as it grows.)  
+  (git-annex does not send a reply to this message.)
+* `DIRHASH Key`  
+  Gets a two level hash associated with a Key. Something like "aB/Cd/".
+  This is always the same for any given Key, so can be used for eg,
+  creating hash directory structures to store Keys in. This is the same
+  directory hash that git-annex uses inside `.git/annex/objects/`  
+  (git-annex replies with VALUE followed by the value.)
+* `DIRHASH-LOWER Key`  
+  Gets a two level hash associated with a Key, using only lower-case.
+  Something like "abc/def/".
+  This is always the same for any given Key, so can be used for eg,
+  creating hash directory structures to store Keys in. This is the same
+  directory hash that is used by eg, the directory special remote.  
+  (git-annex replies with VALUE followed by the value.)  
+* `SETCONFIG Setting Value`  
+  Sets one of the special remote's configuration settings.  
+  Normally this is sent during INITREMOTE, which allows these settings
+  to be stored in the git-annex branch, so will be available if the same
+  special remote is used elsewhere. (If sent after INITREMOTE, the changed
+  configuration will only be available while the remote is running.)  
+  See also `GETGITREMOTENAME` for a way to access git configuration of the
+  remote.  
+  (git-annex does not send a reply to this message.)
+* `GETCONFIG Setting`  
+  Gets one of the special remote's configuration settings, which can have
+  been passed by the user when running `git annex initremote`, or
+  can have been set by a previous SETCONFIG. Can be run at any time.  
+  It's recommended that special remotes that use this implement
+  LISTCONFIGS.  
+  (git-annex replies with VALUE followed by the value. If the setting is
+  not set, the value will be empty.)
+* `SETCREDS Setting User Password`  
+  When some form of user and password is needed to access a special remote,
+  this can be used to securely store them for later use.
+  (Like SETCONFIG, this is normally sent only during INITREMOTE.)  
+  The Setting indicates which value in a remote's configuration can be
+  used to store the creds.  
+  Note that creds are normally only stored in the remote's configuration
+  when it's surely safe to do so; when gpg encryption is used, in which
+  case the creds will be encrypted using it. If creds are not stored in
+  the configuration, they'll only be stored in a local file.  
+  (embedcreds can be set to yes by the user or by SETCONFIG to force
+   the creds to be stored in the remote's configuration).  
+  (git-annex does not send a reply to this message.)
+* `GETCREDS Setting`  
+  Gets any creds that were previously stored in the remote's configuration
+  or a file.
+  (git-annex replies with "CREDS User Password". If no creds are found,
+  User and Password are both empty.)
+* `GETUUID`  
+  Queries for the UUID of the special remote being used.  
+  (git-annex replies with VALUE followed by the UUID.)
+* `GETGITDIR`  
+  Queries for the path to the git directory of the repository that
+  is using the external special remote.
+  (git-annex replies with VALUE followed by the path.)
+* `GETGITREMOTENAME`  
+  Gets the name of the git remote that represents this special remote.
+  This can be used, for example, to look up git configuration belonging
+  to that git remote. This name will often be the same as what is
+  passed to `git-annex initremote` and `enableremote`, but it is possible
+  for git remotes to be renamed, and this will provide the remote's current
+  name.  
+  (git-annex replies with VALUE followed by the name.)  
+  This message is a protocol extension; it's only safe to send it to
+  git-annex after it sent an EXTENSIONS that included GETGITREMOTENAME.
+* `SETWANTED PreferredContentExpression`  
+  Can be used to set the preferred content of a repository. Normally
+  this is not configured by a special remote, but it may make sense
+  in some situations to hint at the kind of content that should be stored
+  in the special remote. Note that if a unparsable expression is set,
+  git-annex will ignore it.  
+  (git-annex does not send a reply to this message.)
+* `GETWANTED`  
+  Gets the current preferred content setting of the repository.
+  (git-annex replies with VALUE followed by the preferred content
+  expression.)
+* `SETSTATE Key Value`  
+  Can be used to store some form of state for a Key. The state stored
+  can be anything this remote needs to store, in any format.
+  It is stored in the git-annex branch. Note that this means that if
+  multiple repositories are using the same special remote, and store
+  different state, whichever one stored the state last will win. Also,
+  it's best to avoid storing much state, since this will bloat the
+  git-annex branch. Most remotes will not need to store any state.  
+  (git-annex does not send a reply to this message.)
+* `GETSTATE Key`  
+  Gets any state that has been stored for the key.  
+  (git-annex replies with VALUE followed by the state.)
+* `SETURLPRESENT Key Url`  
+  Records an URL where the Key can be downloaded from.  
+  Note that this does not make git-annex think that the url is present on
+  the web special remote.  
+  Keep in mind that this stores the url in the git-annex branch. This can
+  result in bloat to the branch if the url is large and/or does not delta
+  pack well with other information (such as the names of keys) already
+  stored in the branch.  
+  (git-annex does not send a reply to this message.)
+* `SETURLMISSING Key Url`  
+  Records that the key can no longer be downloaded from the specified
+  URL.  
+  (git-annex does not send a reply to this message.)
+* `SETURIPRESENT Key Uri`  
+  Records an URI where the Key can be downloaded from. Use with uris
+  that cannot be downloaded with http.
+  (git-annex does not send a reply to this message.)
+* `SETURIMISSING Key Uri`  
+  Records that the key can no longer be downloaded from the specified
+  URI.  
+  (git-annex does not send a reply to this message.)
+* `GETURLS Key Prefix`  
+  Gets the recorded urls where a Key can be downloaded from.
+  Only urls that start with the Prefix will be returned. The Prefix
+  may be empty to get all urls.
+  (git-annex replies one or more times with VALUE for each url.
+  The final VALUE has an empty value, indicating the end of the url list.)
+* `DEBUG message`  
+  Tells git-annex to display the message if --debug is enabled.  
+  (git-annex does not send a reply to this message.)
+* `INFO message`
+  Tells git-annex to display the message to the user.  
+  When git-annex is in --json mode, the message will be emitted immediately
+  in its own json object, with an "info" field.  
+  This message is a protocol extension; it's only safe to send it to
+  git-annex after it sent an EXTENSIONS that included INFO.  
+  (git-annex does not send a reply to this message.)  
+
+## general messages
+
+These messages can be sent at any time by either git-annex or the special
+remote.
+
+* `ERROR ErrorMsg`  
+  Generic error. Can be sent at any time if things get too messed up
+  to continue. When possible, use a more specific reply from the list above.  
+  The special remote program should exit after sending this, as
+  git-annex will not talk to it any further. If the program receives
+  an ERROR from git-annex, it can exit with its own ERROR.
+
+## protocol versions
+
+Currently git-annex supports `VERSION 1` and `VERSION 2`.
+The two protocol versions are actually identical. 
+
+Old versions of git-annex that supported only `VERSION 1`
+had a bug in their implementation of the 
+part of the protocol documented in the [[export_and_import_appendix]].
+The bug could result in ontent being exported to the wrong file.
+External special remotes that implement that should use `VERSION 2` to
+avoid talking to the buggy old version of git-annex.
+
+## extensions
+
+These protocol extensions are currently supported.
+
+* `INFO`  
+  This allows using the `INFO` message.
+* `ASYNC`  
+  This lets multiple actions be performed at the same time by
+  a single external special remote program, rather than starting multiple
+  programs. See the [[async_appendix]] for details.
+* `GETGITREMOTENAME`  
+  This allows using the `GETGITREMOTENAME` message.
+* `UNAVAILABLERESPONSE`  
+  This allows the `AVAILABILITY UNAVAILABLE` response to be used
+  in reply to `GETAVAILABILITY`.
+
+## signals
+
+The external special remote program should not block SIGINT, or SIGTERM.
+Doing so may cause git-annex to hang waiting on it to exit.
+Of course it's ok to catch those signals and do some necessary cleanup
+before exiting.
+
+## long running network connections
+
+Since an external special remote is started only when git-annex needs to
+access the remote, and then left running, it's ok to open a network
+connection in the PREPARE stage, and continue to use that network
+connection as requests are made.
+
+If you're unable to open a network connection, or the connection closes,
+perhaps because the network is down, it's ok to fail to perform any
+requests. Or you can try to reconnect when a new request is made.
+
+Note that the external special remote program may be left running for
+quite a long time, especially when the git-annex assistant is using it.
+The assistant will detect when the system connects to a network, and will
+start a new process the next time it needs to use a remote.
+
+## claiming custom uri schemes for use with git-annex addurl
+
+If a special remote has its own uri scheme, or some other way to identify a
+particular url as being content that is stored in the special remote,
+and can be downloaded by it, it can implement CLAIMURL and CHECKURL.
+This lets git-annex addurl be used with such urls.
+
+For example, the ipfs special remote implements CLAIMURL and CHECKURL
+for "ipfs:ADDRESS" uris. And the bittorrent special remote implements them
+for http urls ending in ".torrent".
+
+When a special remote has claimed an url, commands like git-annex addurl
+will use TRANSFER RETRIEVE to request it download the content of a key.
+To find out what url to download, the special remote can use GETURLS
+to find out what urls are recorded for the key.
+
+For example, the ipfs special remote sends "GETURLS $KEY ipfs:",
+in order to get only the "ipfs:" uris.
+
+The special remote can also use SETURIPRESENT or SETURLPRESENT,
+eg after transferring content to the remote it might know the uri or url
+that can be used to download it. And SETURIMISSING or SETURLMISSING
+can be used after removing content from the remote. This information can
+then be looked up using GETURLS. But it's not necessary to do this in order
+to simply claim an url, because git-annex addurl takes care of it.
+
+For example, the ipfs special remote sends "SETURIPRESENT $KEY ipfs:ADDRESS"
+after storing each key in ipfs. It can later look up that uri when
+downloading the key, and the ipfs uri is also displayed by git-annex
+whereis.
+
+## readonly mode for http downloads
+
+Some storage services allow downloading the content of a file using a
+regular http connection, with no authentication. An external special remote
+for such a storage service can support a readonly mode of operation.
+
+It works like this:
+
+* When a key's content is stored on the remote, use SETURLPRESENT to
+  tell git-annex the public url from which it can be downloaded.
+* When a key's content is removed from the remote, use SETURLMISSING.
+* Document that this external special remote can be used in readonly mode.
+
+  The user doesn't even need to install your external special remote
+  program to use such a remote! All they need to do is run:
+  `git annex enableremote $remotename readonly=true`
+
+* The readonly=true parameter makes git-annex download content from the
+  urls recorded earlier by SETURLPRESENT.
+
+## TODO
+
+* When storing encrypted files stream the file up/down the pipe, rather
+  than using a temp file. Will probably involve less space and disk IO, 
+  and makes the progress display better, since the encryption can happen
+  concurrently with the transfer. Also, no need to use PROGRESS in this
+  scenario, since git-annex can see how much data it has sent/received from
+  the remote. However, \n and probably \0 need to be escaped somehow in the
+  file data, which adds complication.
+* uuid discovery during INITREMOTE.
+* Hook into webapp. Needs a way to provide some kind of prompt to the user
+  in the webapp, etc.
diff --git a/doc/design/external_special_remote_protocol/async_appendix.mdwn b/doc/design/external_special_remote_protocol/async_appendix.mdwn
new file mode 100644
index 0000000000..acebfdb25b
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/async_appendix.mdwn
@@ -0,0 +1,98 @@
+This is an appendix to the [[external_special_remote_protocol]].
+
+[[!toc]]
+
+## introduction
+
+Normally, an external special remote can only be used to do one thing at a
+time, and when git-annex has concurrency enabled, it will start up multiple
+processes for the same external special remote. 
+
+The `ASYNC` extension lets a single external special remote process handle
+multiple concurrent jobs, which can be useful if multiple processes
+would use too many resources, or if it can be better coordinated using a
+single process.
+
+## protocol overview
+
+As usual, the protocol starts by the external special remote sending
+the version of the protocol it's using.
+	
+	VERSION 1
+
+This extension is negotiated by git-annex sending an `EXTENSIONS` message
+that includes `ASYNC`, and the external special remote responding in kind.
+
+	EXTENSIONS INFO ASYNC
+	EXTENSIONS ASYNC
+
+(Older versions of git-annex will not include `ASYNC` in their extensions
+list. To support them, it's a good idea for the external special remote to
+fall back to using the regular protocol.)
+
+Once the extension is negotiated, messages in the protocol are
+tagged with a job number, by prefixing them with "J n".
+
+As usual, the first message git-annex sends is generally PREPARE,
+which gets tagged with a job number:
+
+	J 1 PREPARE
+
+Rather than just responding PREPARE-SUCCESS, the job number has to be
+included in the reply:
+
+	J 1 PREPARE-SUCCESS
+
+Suppose git-annex wants to make some transfers. It can request several
+at the same time, using different job numbers:
+
+	J 1 TRANSFER RETRIEVE Key1 file1
+	J 2 TRANSFER RETRIEVE Key2 file2
+
+The special remote can now perform both transfers at the same time.
+If it sends PROGRESS messages for these transfers, they have to be tagged
+with the job numbers:
+	
+	J 1 PROGRESS 10
+	J 2 PROGRESS 500
+	J 1 PROGRESS 20
+
+The special remote can also send messages that query git-annex for some
+information. These messages and the reply will also be tagged with a job
+number.
+
+	J 1 GETCONFIG url
+	J 3 RETRIEVE Key3 file3
+	J 1 VALUE http://example.com/
+
+One transfers are done, the special remote sends `TRANSFER-SUCCESS` tagged
+with the job number.
+
+	J 2 TRANSFER-SUCCESS RETRIEVE Key2
+	J 1 PROGRESS 100
+	J 1 TRANSFER-SUCCESS RETRIEVE Key1
+
+Lots of different jobs can be requested at the same time.
+
+	J 4 CHECKPRESENT Key3
+	J 5 CHECKPRESENT Key4
+	J 6 REMOVE Key5
+	J 4 CHECKPRESENT-SUCCESS Key3
+	J 6 REMOVE-SUCCESS Key5
+	J 5 CHECKPRESENT-FAILURE Key4
+
+## notes
+
+There will be one job number for each thread that git-annex runs
+concurrently, so around the same number as the -J value, although in some
+cases git-annex does more concurrent operations than the -J value.
+
+`PREPARE` is sent only once per run of a special remote
+program, and despite being tagged with a job number, it should prepare the
+special remote to run that and any other jobs.
+
+`ERROR` should not be tagged with a job number if either git-annex
+or the special remote needs to send it.
+
+`VERSION`, `EXTENSIONS` and `ERROR` are the only protocol messages
+that do not get tagged with a job number.
diff --git a/doc/design/external_special_remote_protocol/async_appendix/comment_1_850d3eb7c04088041c96686b88c36662._comment b/doc/design/external_special_remote_protocol/async_appendix/comment_1_850d3eb7c04088041c96686b88c36662._comment
new file mode 100644
index 0000000000..2d5d76abf9
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/async_appendix/comment_1_850d3eb7c04088041c96686b88c36662._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="is -J shared between workers and ASYNC or &quot;multipliticative&quot;?"
+ date="2020-09-24T15:37:20Z"
+ content="""
+question: is ASYNC and parallel workers in annex share the `-J` somehow?  I.e. if I start `annex get -J3 .` it would create three workers and then possibly talk to special remote(s).  Special remotes then might announce support of ASYNC and accept multiple jobs.  Would it be 3 active jobs across all workers+async or it would be up to 3*3=9 active jobs if every worker supports ASYNC?
+"""]]
diff --git a/doc/design/external_special_remote_protocol/async_appendix/comment_2_897dbfbd4ed9c0f520bd2d4d0c961745._comment b/doc/design/external_special_remote_protocol/async_appendix/comment_2_897dbfbd4ed9c0f520bd2d4d0c961745._comment
new file mode 100644
index 0000000000..64d3eefc93
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/async_appendix/comment_2_897dbfbd4ed9c0f520bd2d4d0c961745._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-15T16:52:40Z"
+ content="""
+The first process that negotiates support for ASYNC will be the last
+process that git-annex starts for that external special remote. So
+typically it will start one process, that negotiates support for ASYNC.
+Then that single process will do all the work.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_11_8d3c35eb0a2a9c57b10566fcaf56d248._comment b/doc/design/external_special_remote_protocol/comment_11_8d3c35eb0a2a9c57b10566fcaf56d248._comment
new file mode 100644
index 0000000000..58c337ccd7
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_11_8d3c35eb0a2a9c57b10566fcaf56d248._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.43"
+ subject="comment 11"
+ date="2014-01-13T18:45:34Z"
+ content="""
+I've handled the cloud repo check by making external special remotes be assumed by default to be globally available via the cloud. So no need to do anything in most cases. For remotes that are only available locally, the remote can reply with \"AVAILABILITY LOCAL\" when git-annex sends an AVAILABILITY request.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_12_241e57092d9e5631ac0ec4dd962477a6._comment b/doc/design/external_special_remote_protocol/comment_12_241e57092d9e5631ac0ec4dd962477a6._comment
new file mode 100644
index 0000000000..b5b3d1bfc2
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_12_241e57092d9e5631ac0ec4dd962477a6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="TobiasTheViking"
+ subject="Feature request"
+ date="2014-01-11T15:41:48Z"
+ content="""
+The ability to mark a remote as being a \"cloud\" remote. To silence the \"Unable to download files from your other devices. Add a cloud repository\" message in the webapp. 
+
+Maybe as simple as \"SETCONFIG cloud true\", if that is a viable implementation.
+
+
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_12_e3029c65d34f78272bc11961ebfd8237._comment b/doc/design/external_special_remote_protocol/comment_12_e3029c65d34f78272bc11961ebfd8237._comment
new file mode 100644
index 0000000000..e8d0dcfe8e
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_12_e3029c65d34f78272bc11961ebfd8237._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm_YXzEdPHzbSGVwtmTR7g1BqDtTnIBB5s"
+ nickname="Matthias"
+ subject="Chunk it"
+ date="2014-01-20T16:22:09Z"
+ content="""
+> TODO: stream the file up/down the pipe, rather than using a temp file
+
+You might want to use chunked transfer, i.e. a series of \"EXPECT 65536\" followed by that many bytes of binary data and an EOF marker (EXPECT-END or EXPECT 0), instead of escaping three characters (newline, NUL, and the escape prefix) and the additional unnecessary tedious per-character processing that would require.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_13_472748f03ba8dad773da7f35b70cb6e4._comment b/doc/design/external_special_remote_protocol/comment_13_472748f03ba8dad773da7f35b70cb6e4._comment
new file mode 100644
index 0000000000..f222349c13
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_13_472748f03ba8dad773da7f35b70cb6e4._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://schnouki.net/"
+ nickname="Schnouki"
+ subject="comment 13"
+ date="2014-02-10T18:22:55Z"
+ content="""
+First things first: in the documentation, I think `SETCONFIG Setting` should be `SETCONFIG Setting Value`.
+
+Now a few questions:
+
+- why have `SETCREDS` and `GETCREDS` have both a username and a password? I'd like to use them to store a OAuth token, but because of this I also have to store a dummy value, which seems weird to me. Is it possible to just do `SETCREDS oauth_token XXXYYY123456`?
+- about `PROGRESS`: my remote is sending `PROGRESS xxx` every 64kb uploaded or downloaded, but no upload/download progress is displayed by git-annex. Is this normal? Should I do it myself, or will it be done by a future version of git-annex?
+
+Joey, thanks a lot for all your work on git-annex :)
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_14_71c3e21a72222250bab933e1c9167fbc._comment b/doc/design/external_special_remote_protocol/comment_14_71c3e21a72222250bab933e1c9167fbc._comment
new file mode 100644
index 0000000000..095f225373
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_14_71c3e21a72222250bab933e1c9167fbc._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 14"
+ date="2014-02-11T01:36:51Z"
+ content="""
+Schnouki, fixed SETCONFIG docs. Note that this is a wiki. :)
+
+I agree it's a little weird for SETCREDS to have a username and a password. This is just exposing git-annex's existing credential storage which has a tuple of values rather than using, say, a multivalue map. If you only need one it's fine to put in a dummy value for the other one.
+
+Re PROGRESS, it seems I hooked up the progress stuff, so it was visible in the webapp, but forgot to put up a progress display at the command line. Fixed in git.
+
+I look forward to seeing your special remote implementation!
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_15_c77386deddc64b2028d9c3a7393d4df7._comment b/doc/design/external_special_remote_protocol/comment_15_c77386deddc64b2028d9c3a7393d4df7._comment
new file mode 100644
index 0000000000..d8ecdc3983
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_15_c77386deddc64b2028d9c3a7393d4df7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://schnouki.net/"
+ nickname="Schnouki"
+ subject="comment 15"
+ date="2014-02-11T13:44:10Z"
+ content="""
+Joey, thanks for fixing that so quickly. Indeed it works in the webapp; I'll check the CLI version as soon as possible :)
+
+I just released the new remote on <https://github.com/Schnouki/git-annex-remote-hubic>. It's for [hubiC](https://hubic.com/), a French personal cloud storage service made by OVH that has free 25GB accounts and only charges €10/month for 10TB (VAT included). It's really experimental (hacked it over the weekend), but it seems to work for me so far.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_16_62b137a138c143a8110886cc0bbb677e._comment b/doc/design/external_special_remote_protocol/comment_16_62b137a138c143a8110886cc0bbb677e._comment
new file mode 100644
index 0000000000..4d196a2df9
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_16_62b137a138c143a8110886cc0bbb677e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="sjvdwalt@3d195104d8f45061da99fe7f0a97d69dfc49bb5d"
+ nickname="sjvdwalt"
+ subject="Stream encoding"
+ date="2015-08-25T00:36:24Z"
+ content="""
+What encoding is used for the stdin/stdout streams used to communicate with remotes?
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_17_8dc7bbf485c9385a4b506e8b8fa934fe._comment b/doc/design/external_special_remote_protocol/comment_17_8dc7bbf485c9385a4b506e8b8fa934fe._comment
new file mode 100644
index 0000000000..55e8c12447
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_17_8dc7bbf485c9385a4b506e8b8fa934fe._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="WHEREIS -- is it better to just report failure to avoid duplicates?"
+ date="2015-08-26T14:22:49Z"
+ content="""
+I wonder how should I utilize this new API (WHEREIS) in my case:  it seems just to lead to duplication of whereis information in my case of a special remote to support extracting of content from archives. If I make it to reply with the same url (which is not \"public\" per se, i.e. can't be used by annex directly) I just get it duplicated:
+
+    $> git annex whereis simple.txt
+    whereis simple.txt (1 copy) 
+      	82025765-5cac-4571-91ed-637620ec6fc7 -- [annexed-archives]
+    
+      annexed-archives: dl+archive:SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz/a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20
+      annexed-archives: dl+archive:SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz/a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20
+    ok
+
+if I \"explain\" it a bit, also somewhat duplicate:
+
+    annexed-archives: file a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20 within archive SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz
+    annexed-archives: dl+archive:SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz/a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20
+
+But if I just reply with \"WHEREIS-FAILURE\" it becomes more sensible (no duplicates), but I feel that then better documentation for this feature get adjusted to describe
+that it is only to complement information already known to annex, and not really to \"provide any information about ways to access the content of a key stored in it\".  Or have I missed the point? ;)
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_18_a0ed457b1b0d71747b6cf0c45897b5e1._comment b/doc/design/external_special_remote_protocol/comment_18_a0ed457b1b0d71747b6cf0c45897b5e1._comment
new file mode 100644
index 0000000000..f56fa64103
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_18_a0ed457b1b0d71747b6cf0c45897b5e1._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: Stream encoding"""
+ date="2015-09-09T20:44:38Z"
+ content="""
+@sjvdwalt, git-annex does not specify or expect any character encoding to be used
+for this protocol. A robust external special remote shouldn't assume any
+particular character encoding, either.
+
+Lines will be terminated with '\n' (0xA), and words in lines are
+delimited by an ascii space (0x20). The keywords in the protocol are ascii
+too of course. Any values can contain an arbitrary sequence of bytes that may
+or may not be able to be decoded using the current character encoding.
+
+IIRC, character encodings like UTF8 that encode a character to multiple
+bytes avoid ever using 0x0 to 0xFF when doing so. So, every ascii space and
+newline are unambiguously such, and it's safe to split on them even though
+no encoding is specified.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_19_89d532a5013af24f15a0d003cbfbab25._comment b/doc/design/external_special_remote_protocol/comment_19_89d532a5013af24f15a0d003cbfbab25._comment
new file mode 100644
index 0000000000..1a4c180aaf
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_19_89d532a5013af24f15a0d003cbfbab25._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: WHEREIS -- is it better to just report failure to avoid duplicates?"""
+ date="2015-09-09T21:03:13Z"
+ content="""
+There's no point in implementing WHEREIS if it's going to reply with the
+same values that are passed to SETURIPRESENT.
+
+Some special remotes may not need to use SETURIPRESENT to work at
+all, and yet storing data on the remote makes it available from some public
+url. This is the kind of situation where it makes sense to implement
+WHEREIS.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_1_5baff75d278394a8818c348fb4f13b8a._comment b/doc/design/external_special_remote_protocol/comment_1_5baff75d278394a8818c348fb4f13b8a._comment
new file mode 100644
index 0000000000..aa2e85d900
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_1_5baff75d278394a8818c348fb4f13b8a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmicVKRM8vJX4wPuAwlLEoS2cjmFXQkjkE"
+ nickname="Thomas"
+ subject="not useful for &quot;plain directory&quot; special remote?"
+ date="2013-12-16T20:10:16Z"
+ content="""
+It says: \"Note that the File should not influence the filename used on the remote. The filename used should be derived from the Key.\"
+
+Thus this interface might not be useful to implement [[todo/New special remote suggeston - clean directory]]? The clean directory special remote would just do that: save $key content on the remote under the filename $file.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_20_546331742e906a68d760c1bf44be63c4._comment b/doc/design/external_special_remote_protocol/comment_20_546331742e906a68d760c1bf44be63c4._comment
new file mode 100644
index 0000000000..7be874d260
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_20_546331742e906a68d760c1bf44be63c4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="but which of the 3?"
+ date="2015-09-10T03:16:17Z"
+ content="""
+could you express your expert choice explicitly among those 3 choices how I should react to WHEREIS in my (archives) case
+
+1. report the same url
+2. \"spell it out\"
+3. WHEREIS-FAILURE
+
+or really not implement it at all? (we are still at VERSION 1, so I thought that not implementing it might lead to some undesired side-effects)
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_21_a8e8255516dc4741439615fa43b71829._comment b/doc/design/external_special_remote_protocol/comment_21_a8e8255516dc4741439615fa43b71829._comment
new file mode 100644
index 0000000000..f9183fe28a
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_21_a8e8255516dc4741439615fa43b71829._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 21"""
+ date="2015-09-10T16:33:10Z"
+ content="""
+As the documentation says, it's fine to not implement WHEREIS if you don't
+need it.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_22_0387827d94f141be53458807da9c2fc2._comment b/doc/design/external_special_remote_protocol/comment_22_0387827d94f141be53458807da9c2fc2._comment
new file mode 100644
index 0000000000..50add12291
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_22_0387827d94f141be53458807da9c2fc2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="szrc"
+ subject="Local storage of creds"
+ date="2016-04-04T03:59:01Z"
+ content="""
+I have a question about local storage of credentials. I assumed that when creds were stored in the repo (because the remote is encrypted or because embedcreds=yes), they wouldn't be stored locally in .git/annex/creds. But it seems they are stored locally, in plaintext, regardless.
+
+Is there a way to prevent this? Ideally, credentials should not be stored plaintext at all...but maybe there's a technical issue I'm not seeing.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_23_7a5af50f7c482d7c02c53be28ddb6a66._comment b/doc/design/external_special_remote_protocol/comment_23_7a5af50f7c482d7c02c53be28ddb6a66._comment
new file mode 100644
index 0000000000..ba0c1ce402
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_23_7a5af50f7c482d7c02c53be28ddb6a66._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2016-04-04T20:17:05Z"
+ content="""
+@szrc, it's pretty expensive to pull encrypted creds out of the git 
+repository and run gpg to decrypt them. Doing so also tends to result
+in a gpg password prompt. 
+
+Rather than do that every time git-annex needs the creds to access the
+remote, it maintains a local cache file, which has its permissions set so
+only the local user (and root, naturally) can read it.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_24_3340d3c34f2ec197f9010d97da8eb7af._comment b/doc/design/external_special_remote_protocol/comment_24_3340d3c34f2ec197f9010d97da8eb7af._comment
new file mode 100644
index 0000000000..b10bf18222
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_24_3340d3c34f2ec197f9010d97da8eb7af._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="szrc"
+ subject="comment 24"
+ date="2016-04-05T01:18:53Z"
+ content="""
+Thanks for the response, Joey. It seems to me that many/most operations for which credentials are needed will require a gpg prompt anyway, but I can see why it might be too expensive in some cases.
+
+Anyway, if you ever saw fit to add the option to disable or limit local caching, I would definitely use it -- and I'm guessing I'm not the only one who would prefer not to store credentials in plaintext.
+
+Thanks for all of your great work on git-annex.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_25_56f38d934125c28172b6475bdb4de284._comment b/doc/design/external_special_remote_protocol/comment_25_56f38d934125c28172b6475bdb4de284._comment
new file mode 100644
index 0000000000..132c95f5b3
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_25_56f38d934125c28172b6475bdb4de284._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ subject="comment 25"
+ date="2016-05-03T06:25:02Z"
+ content="""
+Is there a reason that DIRHASH in type=external uses a different format (mixed-case) from that used by type=directory (lower-case)? Or, could there be e.g. `DIRHASH LOWER` to select between the formats?
+
+I'm writing an external remote for SMB filesystem access and I'd like its storage to be usable via type=directory in case of emergencies or other reasons, but  with different dirhash layouts that's not going to work, I assume...
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_26_4f8addd76a1e64d05a34910d4719a40c._comment b/doc/design/external_special_remote_protocol/comment_26_4f8addd76a1e64d05a34910d4719a40c._comment
new file mode 100644
index 0000000000..790da04451
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_26_4f8addd76a1e64d05a34910d4719a40c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 26"""
+ date="2016-05-03T17:29:02Z"
+ content="""
+I don't think there's any particularly good reason why DIRHASH uses the
+mixed case format. However, it can't be changed without busting existing
+stuff.
+
+So yeah, I've gone ahead and added a `DIRHASH_LOWER`.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_27_9153a5c49710bf57d11338829f66fa78._comment b/doc/design/external_special_remote_protocol/comment_27_9153a5c49710bf57d11338829f66fa78._comment
new file mode 100644
index 0000000000..5061c0a883
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_27_9153a5c49710bf57d11338829f66fa78._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ subject="comment 27"
+ date="2016-05-03T18:02:03Z"
+ content="""
+Thanks. It'll probably be safer for my use case of storing data on Windows network shares than the mixed-case version.
+
+_(Speaking of \"too late to change\", `DIRHASH-LOWER` with a dash might be more consistent with the existing responses?)_
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_28_74961b12a73a52a700e10a21674e66ee._comment b/doc/design/external_special_remote_protocol/comment_28_74961b12a73a52a700e10a21674e66ee._comment
new file mode 100644
index 0000000000..faaf26a2d4
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_28_74961b12a73a52a700e10a21674e66ee._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 28"""
+ date="2016-05-03T18:09:50Z"
+ content="""
+Agreed, DIRHASH-LOWER is more consistent, changed it to that.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_29_c1d97815386453c3e433fca9a44c4667._comment b/doc/design/external_special_remote_protocol/comment_29_c1d97815386453c3e433fca9a44c4667._comment
new file mode 100644
index 0000000000..b714602e39
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_29_c1d97815386453c3e433fca9a44c4667._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="Retrieval progress message helpers"
+ date="2016-05-20T19:42:23Z"
+ content="""
+It would be nice if
+- progress could be provided in percentage rather than bytes, when that's all that's available
+- git-annex could inform the special remote how many bytes a file to be downloaded is, if that information is already available
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_2_70429b7c4f1e4083a9d5a6e2e238056d._comment b/doc/design/external_special_remote_protocol/comment_2_70429b7c4f1e4083a9d5a6e2e238056d._comment
new file mode 100644
index 0000000000..032136b022
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_2_70429b7c4f1e4083a9d5a6e2e238056d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 2"
+ date="2013-12-16T20:42:23Z"
+ content="""
+That's not how special remotes work -- they have nothing to do with the symlinks in the work tree, which are managed by git (or git-annex in direct mode). They only store values for keys.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_30_7d045871f9ebbb89e3f9bbfa28e8468f._comment b/doc/design/external_special_remote_protocol/comment_30_7d045871f9ebbb89e3f9bbfa28e8468f._comment
new file mode 100644
index 0000000000..4330e7f971
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_30_7d045871f9ebbb89e3f9bbfa28e8468f._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 30"""
+ date="2016-05-23T18:54:35Z"
+ content="""
+You can find out the size of a key by using 
+`git-annex examinekey $key --format='${bytesize}\n'` 
+(There's a --batch option to avoid needing to spin up
+repeated such processes.)
+
+I suppose I could add a PROGRESSPRECENT, but any version of git-annex that
+didn't support it would fail with a protocol error if a special remote
+tried to use that. So, the special remote would need to check git-annex
+version to use it.
+
+So, maybe better to get the size of the key yourself, and convert the
+percentage to bytes for PROGRESS.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_31_907597187020180e7730e27e86f6da5e._comment b/doc/design/external_special_remote_protocol/comment_31_907597187020180e7730e27e86f6da5e._comment
new file mode 100644
index 0000000000..d1d4d753c9
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_31_907597187020180e7730e27e86f6da5e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 31"
+ date="2018-09-19T11:01:31Z"
+ content="""
+What exacly is the difference between SETURIPRESENT and SETURLPRESENT?
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_32_f6b8306cfdcb3792728aa47af0677338._comment b/doc/design/external_special_remote_protocol/comment_32_f6b8306cfdcb3792728aa47af0677338._comment
new file mode 100644
index 0000000000..6ccf84027b
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_32_f6b8306cfdcb3792728aa47af0677338._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 32"
+ date="2018-09-19T18:19:22Z"
+ content="""
+Some questions about CHECKPRESENT Key: (1) if Key is a URL backend key, should this return true if CHECKURL on the URL would return CHECKURL-CONTENTS?
+(2) Should the external special remote implementation call GETURLS on the key and return true if CHECKURL would return CHECKURL-CONTENTS for any of the URLs?
+(3) Calling GETURLS on a URL key returns an empty list; shouldn't it return a one-element list containing the included URL (at least if a CHECKURL call on that URL 
+would return CHECKURL-CONTENTS)?
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_33_bee7ff39f3989dfbec292490e47bcaaa._comment b/doc/design/external_special_remote_protocol/comment_33_bee7ff39f3989dfbec292490e47bcaaa._comment
new file mode 100644
index 0000000000..ac472845f5
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_33_bee7ff39f3989dfbec292490e47bcaaa._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 33"""
+ date="2018-09-24T15:35:54Z"
+ content="""
+@Ilya_Shlyakhter,
+
+1. CHECKURL is only used by git-annex add/importfeed when adding a new url.
+   So it does not need to be consistent with CHECKPRESENT, though it would
+   probably make sense for it to be in most cases.
+2. I guess you're asking if it should do that in its CHECKPRESENT
+   implementation. CHECKPRESENT needs to use some method to actively verify
+   that the remote currently contains the content of the key. It doesn't
+   necessarily need to use a recorded url.
+3. GETURLS looks at information stored in the git-annex branch. If the url
+   key has been added to the repository with `git annex add` then its url
+   will be stored there, but if you just generated an url key, it doesn't
+   necessarily have anything stored about it in the git-annex branch.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_34_af6ae46fa9228461573dd7b2f0713ef1._comment b/doc/design/external_special_remote_protocol/comment_34_af6ae46fa9228461573dd7b2f0713ef1._comment
new file mode 100644
index 0000000000..68064e9b02
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_34_af6ae46fa9228461573dd7b2f0713ef1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="question about special remote protocol"
+ date="2018-09-26T17:16:13Z"
+ content="""
+What exacly is the difference between SETURIPRESENT and SETURLPRESENT?
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_35_2f71f6d0caf4fa5ccd26618026714975._comment b/doc/design/external_special_remote_protocol/comment_35_2f71f6d0caf4fa5ccd26618026714975._comment
new file mode 100644
index 0000000000..c4129a8afd
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_35_2f71f6d0caf4fa5ccd26618026714975._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 35"""
+ date="2018-10-04T18:17:57Z"
+ content="""
+Use `SETURLPRESENT` when it's a regular http url. This allows
+git-annex to download from the remote in readonly mode without needing the
+external special remote program to be installed at all.
+
+Use `SETURIPRESENT` for things that are not http urls, but that it makes
+sense for `git annex whereis` to display.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_36_f8081ce200700516efef61ec0ac86f86._comment b/doc/design/external_special_remote_protocol/comment_36_f8081ce200700516efef61ec0ac86f86._comment
new file mode 100644
index 0000000000..ba95e05787
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_36_f8081ce200700516efef61ec0ac86f86._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 36"
+ date="2018-10-19T15:52:21Z"
+ content="""
+What is the intended use case for CHECKURL-MULTI?  Are there examples of external special remote implementations that use this response?
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_37_2aef2647d7df69876f107247e039f5a6._comment b/doc/design/external_special_remote_protocol/comment_37_2aef2647d7df69876f107247e039f5a6._comment
new file mode 100644
index 0000000000..a879de95c1
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_37_2aef2647d7df69876f107247e039f5a6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 37"""
+ date="2018-10-29T19:39:01Z"
+ content="""
+@Ilya, the uses for CHECKURL-MULTI are open-ended,
+bittorrent files that can list several files is one example of
+a way it's used.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_39_62f6621259587333a83776cf514b2497._comment b/doc/design/external_special_remote_protocol/comment_39_62f6621259587333a83776cf514b2497._comment
new file mode 100644
index 0000000000..b9f9096007
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_39_62f6621259587333a83776cf514b2497._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: PREPARE-LOCAL"""
+ date="2019-01-16T18:24:08Z"
+ content="""
+There is a difference between a WHEREIS that for some reason itself hit the
+network, and a single network connection in PREPARE. The language was
+really talking about the former, which would make whereis on a large number
+of files painful. Not saying it wouldn't be better to avoid the latter too;
+if the user is only running whereis on 1 file the overhead is equally as bad.
+
+Hmm, there is that "long running network connections" section
+that encourages using PREPARE that way, I think the idea was to make it as
+simple as possible to implement an external remote. All of git-annex's
+built-in remotes defer anything like that until it's needed.
+
+In a way the real problem here is that WHEREIS is something most
+remotes will never need to implement, but it's queried of all of them.
+If only the few remotes that implement it needed to avoid network
+connections in PREPARE, that would not be much trouble to do.
+
+PREPARE-LOCAL would need to be a protocol extension, so special remotes
+would have to be modified to request it, and those that are not modified
+would still have the overhead. Would that be any more likely to
+happen/easier to do than modifying all special remotes to defer network
+connections until needed?
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_39_ea321b96df3314a9e2a35cd0f8312972._comment b/doc/design/external_special_remote_protocol/comment_39_ea321b96df3314a9e2a35cd0f8312972._comment
new file mode 100644
index 0000000000..04f221bb89
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_39_ea321b96df3314a9e2a35cd0f8312972._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="PREPARE-LOCAL"
+ date="2019-01-15T15:47:39Z"
+ content="""
+> \"Note that users expect `git annex whereis` to run fast, without eg, network access\"
+
+Currently, git-annex spins up a remote process for every `git annex whereis` command that involves a file present on the remote (w/o chunking & encryption). As most remotes establish their network connection during the PREPARE phase, the command is slowed down, especially with bad internet connection. So I propose an extension `PREPARE-LOCAL` that tells the remote to get all necessary config information but skip the networking.
+
+Alternatively, the remotes could wait to establish network connection until the first transfer command is sent but I think something like `PREPARE-LOCAL` would be the cleaner solution.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_3_c763e44d06d9f50f0d357889b180b819._comment b/doc/design/external_special_remote_protocol/comment_3_c763e44d06d9f50f0d357889b180b819._comment
new file mode 100644
index 0000000000..08d405c8e2
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_3_c763e44d06d9f50f0d357889b180b819._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="TobiasTheViking"
+ subject="Feature requests"
+ date="2013-12-28T13:57:35Z"
+ content="""
+PREPARE-Failure ErrorMsg (matching INITREMOTE-FAILURE ErrorMsg)
+
+Also, i'd like for the following to overwrite existing credentials/configs 
+MYFOLDER=\"testfolder\" MYLOGIN=\"login\" MYPASSWORD=\"pword\" MYURL=\"http://webdav/\"    git annex enableremote owncloud type=external externaltype=owncloud --debug
+
+This would also be needed for refreshing oauth.
+
+
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_40_a312c0180bce6dbbd03b14b8ba3dcb5f._comment b/doc/design/external_special_remote_protocol/comment_40_a312c0180bce6dbbd03b14b8ba3dcb5f._comment
new file mode 100644
index 0000000000..e9fd6503dc
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_40_a312c0180bce6dbbd03b14b8ba3dcb5f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: PREPARE-LOCAL"""
+ date="2019-01-17T15:49:05Z"
+ content="""
+I've thought up a way to solve this problem, it's in
+[[todo/external_remote_querying_transition]].
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_41_7d63261342ea475f696cadb419782dbb._comment b/doc/design/external_special_remote_protocol/comment_41_7d63261342ea475f696cadb419782dbb._comment
new file mode 100644
index 0000000000..9eaf91449e
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_41_7d63261342ea475f696cadb419782dbb._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="michael.hanke@c60e12358aa3fc6060531bdead1f530ac4d582ec"
+ nickname="michael.hanke"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Empty lines sent by git-annex to an external special remote"
+ date="2019-05-14T06:36:11Z"
+ content="""
+I am implementing a special remote using https://github.com/Lykos153/AnnexRemote
+
+I found that the annexremote leaves the `readline()` loop once it receives an empty line from git-annex over stdin (https://github.com/Lykos153/AnnexRemote/blob/master/annexremote/annexremote.py#L410). Given that the protocol description says nothing about empty lines this may or may not be sensible. However, I also found that git-annex does (sometimes?) sends empty lines. Here is an excerpt:
+
+```
+% git annex --debug copy --to inm7 down/cope1.feat/report_log.html
+...
+[2019-05-14 07:45:43.350358695] git-annex-remote-inm7[1] <-- TRANSFER STORE MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html .git/annex/objects/mj/Kx/MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html/MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html
+<<INCOMING ''
+(repeated a total of 22 times)
+...
+<<INCOMING 'TRANSFER STORE MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html .git/annex/objects/mj/Kx/MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html/MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html\n'
+```
+
+where '<<INCOMING' reports anything that is read via `readline()` from the special remote's `stdin`. So 22 empty lines are read from
+`stdin` before the `TRANSFER STORE` reported by git-annex to have been sent actually appears.
+
+If I drive the remote implementation \"by hand\" I don't see anything wrong, and no non-protocol output:
+
+```
+% git-annex-remote-inm7
+VERSION 1
+EXTENSIONS INFO
+EXTENSIONS
+PREPARE
+GETCONFIG dataset_uuid
+VALUE dda42d6c-7231-11e9-a901-0050b6902ef0
+PREPARE-SUCCESS
+CHECKPRESENT MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html
+DIRHASH MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html
+VALUE mj/Kx/
+CHECKPRESENT-FAILURE MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html
+TRANSFER STORE MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html .git/annex/objects/mj/Kx/MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html/MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html
+DIRHASH MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html
+VALUE mj/Kx/
+TRANSFER-SUCCESS STORE MD5E-s48796--33a9884cc35c891f693958b9dd7fccd6.html
+```
+
+If git-annex runs it, I see empty lines appearing only after `CHECKPRESENT-FAILURE`.
+
+Which purpose do these empty lines serve? Under what conditions would an empty response from git-annex occur?
+
+Thx!
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_42_485588573d8d9f74e64cdf560f65e7fe._comment b/doc/design/external_special_remote_protocol/comment_42_485588573d8d9f74e64cdf560f65e7fe._comment
new file mode 100644
index 0000000000..6250e7f427
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_42_485588573d8d9f74e64cdf560f65e7fe._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="michael.hanke@c60e12358aa3fc6060531bdead1f530ac4d582ec"
+ nickname="michael.hanke"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Re: Empty lines sent by git-annex to an external special remote"
+ date="2019-05-14T08:48:27Z"
+ content="""
+Sorry for the noise. The reason was that my special remote was calling SSH internally and the parent's `stdin` was connected to the SSH process -- which confused all involved parties.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_43_d942d979773d9361fbf3dde28c26a941._comment b/doc/design/external_special_remote_protocol/comment_43_d942d979773d9361fbf3dde28c26a941._comment
new file mode 100644
index 0000000000..75969e0e26
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_43_d942d979773d9361fbf3dde28c26a941._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 43"""
+ date="2019-05-14T19:27:11Z"
+ content="""
+Notice that the --debug flag shows how this protocol is flowing in
+both directions.
+
+	<-- TRANSFER STORE ...
+	--> TRANSFER-SUCCESS STORE ...
+
+The first line was sent from git-annex to the external special remote
+program, and the second line was its reply to git-annex.
+
+This is very handy for understanding when something strange seems to be
+happening with the protocol.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_44_a72db8ed716effc507e7127f9ec95dc4._comment b/doc/design/external_special_remote_protocol/comment_44_a72db8ed716effc507e7127f9ec95dc4._comment
new file mode 100644
index 0000000000..4e5b01d6a9
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_44_a72db8ed716effc507e7127f9ec95dc4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="should there be FSCK and/or CLEAN?"
+ date="2019-09-28T00:31:51Z"
+ content="""
+external remote could crash/get interrupted in the middle of its operation thus leaving some corrupt/temporary files behind.  How/when should it run some diagnostic and clean up after itself?
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_45_a25f00fb081e30f639376b6ad94cdb30._comment b/doc/design/external_special_remote_protocol/comment_45_a25f00fb081e30f639376b6ad94cdb30._comment
new file mode 100644
index 0000000000..850a726055
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_45_a25f00fb081e30f639376b6ad94cdb30._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: should there be FSCK and/or CLEAN?"""
+ date="2019-09-28T16:38:14Z"
+ content="""
+You never need to worry about cleaning up the files git-annex asks content
+be downloaded to.
+
+git-annex also has a per-key temporary work directory that could perhaps
+be useful for this interface to expose; it manages cleanup of those
+temporary directories at the right times.
+
+You can detect when git-annex closes the external program's stdin, and perform
+whatever shutdown cleanup you want to then. But of course there could be other
+git-annex processes also running other instances of the same external
+program, so you'd have to find a way to avoid deleting any files those are
+using.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_46_7ecdba05cb2bfc7d868b81bbd3e3f964._comment b/doc/design/external_special_remote_protocol/comment_46_7ecdba05cb2bfc7d868b81bbd3e3f964._comment
new file mode 100644
index 0000000000..f31b42487e
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_46_7ecdba05cb2bfc7d868b81bbd3e3f964._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="giuly.ippoliti@c1e2f0d5e40b128900f94f3d107d3719f87c3ff7"
+ nickname="giuly.ippoliti"
+ avatar="http://cdn.libravatar.org/avatar/4444ce1930af68fd817e9649d40e0359"
+ subject="Triggering which stage and when?"
+ date="2019-10-24T20:30:10Z"
+ content="""
+Hi,
+
+I would like to better understand how all stages interact together in a special remote. Once a special remote is initialized, how is the PREPARE stage triggered? I could not succeed int this for now. 
+
+Moreover, is the program continuously running after initialization? it seems to exit with an 'ok, recording state in git...'
+
+So, if I run the program 'by hand' and talk to my special remote via VERSION,INFO,PREPARE..the remote succeeds in what it is meant to. I am having troubles in making the same happen with annex under the cover.
+
+Thank you for your help,
+
+Best
+Giulia
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_47_9d48c85b896f738323dec28c1955ee22._comment b/doc/design/external_special_remote_protocol/comment_47_9d48c85b896f738323dec28c1955ee22._comment
new file mode 100644
index 0000000000..7f55ded02d
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_47_9d48c85b896f738323dec28c1955ee22._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="alex@f04d0d3c452a2a99b27ccc93c1543bee4a1bf5be"
+ nickname="alex"
+ avatar="http://cdn.libravatar.org/avatar/9d97e9bcb1cf7680309e37cd69fab408"
+ subject="Resuming an interrupted download"
+ date="2021-10-01T23:27:31Z"
+ content="""
+It would be helpful to allow special remotes to take advantage of git annex's ability to resume interrupted downloads for large files, especially on slow/unreliable connections. One way to implement this would be to allow the special remote to send a message asking git-annex what offset it intends to read at, then write a sparse file with only the needed data. I notice the `testremote` suite includes tests for resuming downloads at an offset, so it is possible no other changes would be needed.
+
+Sparse files could be avoided by allowing the special remote to send a command indicating the offset at which the target file starts.
+
+Does that sound like a reasonable design?
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_48_d378ab8adc6a73a17c39d62978cb9e90._comment b/doc/design/external_special_remote_protocol/comment_48_d378ab8adc6a73a17c39d62978cb9e90._comment
new file mode 100644
index 0000000000..8d51e717bf
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_48_d378ab8adc6a73a17c39d62978cb9e90._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Resuming an interrupted download"""
+ date="2021-10-05T16:01:10Z"
+ content="""
+It's already possible, and in fact very easy to support resuming downloads.
+When the filename that you're asked to download to already exists, you can
+simply check its size and resume downloading to it where
+the previous download left off.
+
+When you send PROGRESS, the value should be the same as the current 
+size of the file. That is always the case really, but the distinction
+between file size and amount you've downloaded only matters when resuming.
+
+Another way to support resuming, when talking to an API that does not,
+is to encourage users of your remote to configure chunking with a small
+enough chunk size. git-annex will then handle resuming by re-starting
+on the last incomplete chunk. In this case, you'll be downloading each
+chunk to a separate file, so you will not need to do anything to support
+resuming.
+
+If a remote does any kind of out of order downloading (like bittorrent
+does), it needs to avoid writing to the file out of order,
+with holes in the middle of it. Such holes would mess up a resume of
+the download of the same object by another remote.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_49_9045ad13ad2c2f998173a870174eb3ee._comment b/doc/design/external_special_remote_protocol/comment_49_9045ad13ad2c2f998173a870174eb3ee._comment
new file mode 100644
index 0000000000..3f66a99905
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_49_9045ad13ad2c2f998173a870174eb3ee._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="alex@f04d0d3c452a2a99b27ccc93c1543bee4a1bf5be"
+ nickname="alex"
+ avatar="http://cdn.libravatar.org/avatar/9d97e9bcb1cf7680309e37cd69fab408"
+ subject="Re: Resuming an interrupted download"
+ date="2021-10-08T03:06:57Z"
+ content="""
+Thanks, that works great!
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_4_20ff41d82b5f1872698a5b24adcd0c41._comment b/doc/design/external_special_remote_protocol/comment_4_20ff41d82b5f1872698a5b24adcd0c41._comment
new file mode 100644
index 0000000000..6597294fba
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_4_20ff41d82b5f1872698a5b24adcd0c41._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 4"
+ date="2013-12-29T17:50:23Z"
+ content="""
+Added PREPARE-FAILURE
+
+git-annex enableremote causes INITREMOTE to be called, so any credentials can be stored etc. (Note that, as with built-in special remotes, credentials are only stored in the git-annex branch when the remote is encrypted. Otherwise, they're stored locally in a .git/annex/creds/ file.)
+
+Also, I'd recommend using environment variables for passing credentials to initremote/enableremote, because that avoids leaking them in `ps`.. but it probably doesn't make sense to use environment variables for other settings, but instead pass them as parameters of initremote/enableremote, which can be looked up using GETCONFIG. Only exception might be if the setting needs to vary between different machines.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_50_fdd9804134e6fe5e6527f35fc782cb80._comment b/doc/design/external_special_remote_protocol/comment_50_fdd9804134e6fe5e6527f35fc782cb80._comment
new file mode 100644
index 0000000000..023d8435dc
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_50_fdd9804134e6fe5e6527f35fc782cb80._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jeroen"
+ avatar="http://cdn.libravatar.org/avatar/72187d05d3414dc8e5766c5575a2d255"
+ subject="DIRHASH ending in slash?"
+ date="2022-09-28T11:58:56Z"
+ content="""
+DIRHASH-LOWER (and I assume the other DIRHASH commands as well) seem to respond with a path ending with a slash. So `VALUE abc/def/` instead of the `VALUE abc/def` example mentioned. `git-annex-remote-rclone` actually assumes the response ends with a slash. Is this indeed what git-annex guarantees? If so, it should probably be documented in this specification.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_51_c0eaa8639ad2b21ac917d9033d77a327._comment b/doc/design/external_special_remote_protocol/comment_51_c0eaa8639ad2b21ac917d9033d77a327._comment
new file mode 100644
index 0000000000..449ae3a6e5
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_51_c0eaa8639ad2b21ac917d9033d77a327._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: DIRHASH ending in slash?"""
+ date="2022-09-30T17:31:25Z"
+ content="""
+Hmm, so it does. This would not have been my choice for ideal behavior, but
+I don't want to break things that depend on it now. 
+So I've updated the documentation.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_52_3c8c5a1d388929da4629f14b099d02d1._comment b/doc/design/external_special_remote_protocol/comment_52_3c8c5a1d388929da4629f14b099d02d1._comment
new file mode 100644
index 0000000000..1f1c99436b
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_52_3c8c5a1d388929da4629f14b099d02d1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Status of the import/export protocol implementation"""
+ date="2023-04-07T16:53:17Z"
+ content="""
+It's still only a draft. I've been waiting for someone to have a use case
+that needs it, so I can work with them in implementing it and making sure
+it all makes sense.
+
+I don't expect that implementing it on the git-annex side will be very
+hard.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_53_a2d1778e6d61f9cb606fb83f0a4a73f4._comment b/doc/design/external_special_remote_protocol/comment_53_a2d1778e6d61f9cb606fb83f0a4a73f4._comment
new file mode 100644
index 0000000000..5669cae726
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_53_a2d1778e6d61f9cb606fb83f0a4a73f4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="matrss"
+ avatar="http://cdn.libravatar.org/avatar/59541f50d845e5f81aff06e88a38b9de"
+ subject="Multi-line string in WHEREIS-SUCCESS?"
+ date="2024-02-21T12:29:14Z"
+ content="""
+Is it possible to somehow make `git annex whereis` show the response of the special remote to `WHEREIS` over multiple lines? Just including newlines obviously results in an error, since that ends the WHEREIS-SUCCESS message.
+
+I am implementing a special remote for which the data is fully described by what is essentially a json-encoded request to a third-party API, and I would like to show this json string pretty-printed over multiple lines in the whereis output, instead of as a single line.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_54_0225736488f9c1e7f78a08eea8ca864d._comment b/doc/design/external_special_remote_protocol/comment_54_0225736488f9c1e7f78a08eea8ca864d._comment
new file mode 100644
index 0000000000..66c7ce087b
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_54_0225736488f9c1e7f78a08eea8ca864d._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="psxvoid"
+ avatar="http://cdn.libravatar.org/avatar/fde068fbdeabeea31e3be7aa9c55d84b"
+ subject="support for bulk write/read/test remote"
+ date="2024-04-02T06:41:25Z"
+ content="""
+Hi,
+
+I'm wondering whether there an any easy way to delay \"progress reporting\" (a.k.a. \"report progress for ALL `transfer_store` operations ONCE\", a.k.a. \"bulk transfer\") for a special remote?
+
+What I'm trying to achieve: there is an archiver called [dar](http://dar.linux.free.fr/), which I would like to implement a special remote for.
+It can write many files into a single archive and also supports incremental/differential backups.
+A one can create an archive with this utility, by providing a list of files or directories as params.
+
+The problem with the current git annex special remote API is that it does not allows to report transfer progress for ALL key/files for a special remote (e.g. with `transfer_store`), and then check the progress at **ONCE** for **ALL** files at the end of the process.
+Ideally, the protocol should have some kind of \"write test\" command to check the written archive for errors, and only then report the progress as \"successful\".
+
+What I was thinking of is to just write all files into a temporarily list during `transfer_store`, and then externally archive this list of files after `git annex copy --to dar-remote` is done. But seems like git annex will think that the process of writing files to that remote was successful, while it may not (e.g. file access error happened, or an archive was corrupted, etc).
+
+How can it be achieved? Do we need to extend git annex with another protocol extension? How difficult it may be, and where to start?
+I suppose there is no way Joey or anyone else will work on it any time soon if there is no workaround, and I have to submit a patch?
+
+P.S.: I've seen [async extensions](https://git-annex.branchable.com/design/external_special_remote_protocol/async_appendix/) but it seems like it's tied to a threads, which most likely won't allow to achieve the described goals.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_5_3ee158e548002badae5bf44dc0442626._comment b/doc/design/external_special_remote_protocol/comment_5_3ee158e548002badae5bf44dc0442626._comment
new file mode 100644
index 0000000000..fcc70a1860
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_5_3ee158e548002badae5bf44dc0442626._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="TobiasTheViking"
+ subject="Feature requests"
+ date="2013-12-31T14:05:07Z"
+ content="""
+Hook should be able to set default configuration for itself.
+
+For instance, clean flickr hook will only upload some files(notably pictures). The user shouldn't have to manage that.
+
+Other hooks have a maximum filesize(though i guess that doesn't matter once splitting works).
+
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_6_ee2828ce25b83bbabc9d5dde35d1e57b._comment b/doc/design/external_special_remote_protocol/comment_6_ee2828ce25b83bbabc9d5dde35d1e57b._comment
new file mode 100644
index 0000000000..f57bfabbc4
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_6_ee2828ce25b83bbabc9d5dde35d1e57b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 6"
+ date="2013-12-31T17:56:34Z"
+ content="""
+I suppose you're talking about preferred content settings.
+
+I think that it makes sense for hooks to use existing git-annex plumbing etc when it's available. So a hook could just run `git annex wanted` to manage its preferred content.
+
+The only problem is that a hook does not currently have a way to discover the UUID of the repository! So I've added a GETUUID to cover this and other use cases.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_7_edb649d0019a061ef7bf6534a444429d._comment b/doc/design/external_special_remote_protocol/comment_7_edb649d0019a061ef7bf6534a444429d._comment
new file mode 100644
index 0000000000..4e9f91c42c
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_7_edb649d0019a061ef7bf6534a444429d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="TobiasTheViking"
+ subject="comment 7"
+ date="2013-12-31T18:20:32Z"
+ content="""
+I think the hook running anything in shell, to interact with git annex, is a mistake.
+
+I see a lot more potential pitfalls and mistakes(especially crossplatform). 
+
+It should be the existing git annex plumbing (preferred content) as you say. I just really think it should be configurable in the protocol, instead of a having to run a shell command. 
+
+Since you have made this advanced protocol i really see it as a mistake to do anything between the hook and git-annex outside of the protocol, it makes much more sense to have all their interactions happen within the protocol.
+
+IMO anyways.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_8_1f4c205a5ce6f33ccf2f4d80754e5699._comment b/doc/design/external_special_remote_protocol/comment_8_1f4c205a5ce6f33ccf2f4d80754e5699._comment
new file mode 100644
index 0000000000..f9803bee01
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_8_1f4c205a5ce6f33ccf2f4d80754e5699._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 8"
+ date="2013-12-31T19:16:16Z"
+ content="""
+It makes sense to only implement one interface to things, unless there is a reason such as performance to do otherwise.
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_9_15c4cfe064be37cc104dcb6aa049a449._comment b/doc/design/external_special_remote_protocol/comment_9_15c4cfe064be37cc104dcb6aa049a449._comment
new file mode 100644
index 0000000000..cc3f7dd235
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_9_15c4cfe064be37cc104dcb6aa049a449._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 9"
+ date="2014-01-02T00:15:28Z"
+ content="""
+Tobias made some good points:
+
+* git-annex may not be in PATH depending on installation method
+* It would in theory be bad if a special remote ran some git-annex command that used the special remote and ran some git-annex command [...].
+* git-annex would need to tell the special remote what git repo it was being used with.
+
+So, added GETWANTED and SETWANTED. However, if I find myself recapitulating a lot of git-annex's command-line plumbing stuff in this protocol, I will need to revisit this decision and find a better way. Particularly, I narrowly escaped an intractable dependency loop in [[!commit 8e3032df2d5c6ddf07e43de4b3bb89cb578ae048]].
+"""]]
diff --git a/doc/design/external_special_remote_protocol/export_and_import_appendix.mdwn b/doc/design/external_special_remote_protocol/export_and_import_appendix.mdwn
new file mode 100644
index 0000000000..d6823e7941
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/export_and_import_appendix.mdwn
@@ -0,0 +1,347 @@
+This is an appendix to the [[external_special_remote_protocol]].
+
+Some special remotes interface to a key/value datastore using keys that are
+eg hashes, and it won't make sense for them to implement any of this.
+
+When a special remote interfaces with something that looks like a directory
+of files, the simple export interface can be implemented to allow the
+[[git-annex-export]] command to be used to store file trees on the special
+remote.
+
+If other tools can write files to the special remote too, the import/export
+interface can be implemented. This allows for both [[git-annex-import]] and 
+[[git-annex-export]] to be used with the special remote.
+
+[[!toc]]
+
+## simple export interface
+
+git-annex will use this when the special remote is initialized with
+exporttree=yes but without importtree=yes and indicates that it supports
+exports.
+
+These are requests git-annex sends to the special remote program.
+Once the special remote has finished performing a request, it
+should send one of the listed replies. Or, if it does not support
+a request, it can reply with `UNSUPPORTED-REQUEST`.
+
+* `EXPORTSUPPORTED`  
+  Used to check if a special remote supports exports.
+  Note that this request may be made before or after `PREPARE`.
+  * `EXPORTSUPPORTED-SUCCESS`  
+    Indicates that it makes sense to export to this special remote.
+  * `EXPORTSUPPORTED-FAILURE`  
+    Indicates that it does not make sense to export to this special remote.
+* `EXPORT Name`  
+  Comes immediately before each of the following requests (except for
+  `REMOVEEXPORTDIRECTORY`), specifying the name of the exported file. It
+  will be in the form of a relative path, and may contain path separators,
+  whitespace, and other special characters.  
+  No response is made to this message.  
+  Note that old versions of git-annex had a bug that sometimes prevented
+  sending `EXPORT`. To avoid being used with such a buggy version of
+  git-annex, send `VERSION 2`.
+* `TRANSFEREXPORT STORE|RETRIEVE Key File`  
+  Requests the transfer of a File on local disk to or from the previously 
+  provided `EXPORT` Name on the special remote.  
+  Note that it's important that, while a file is being stored,
+  `CHECKPRESENTEXPORT` not indicate it's present until all the data has
+  been transferred.  
+  While the transfer is running, the remote can send any number of
+  `PROGRESS` messages. Once the transfer is complete, it finishes by
+  sending one of these replies:
+  * `TRANSFER-SUCCESS STORE|RETRIEVE Key`  
+    Indicates the transfer completed successfully.
+  * `TRANSFER-FAILURE STORE|RETRIEVE Key ErrorMsg`  
+    Indicates the transfer failed.
+* `CHECKPRESENTEXPORT Key`  
+  Requests the remote to check if the previously provided `EXPORT` Name is present
+  in it.  
+  * `CHECKPRESENT-SUCCESS Key`  
+    Indicates that a content has been positively verified to be present in the
+    remote.
+  * `CHECKPRESENT-FAILURE Key`  
+    Indicates that a contents has been positively verified to not be present in the
+    remote.
+  * `CHECKPRESENT-UNKNOWN Key ErrorMsg`  
+    Indicates that it is not currently possible to verify if content is
+    present in the remote. (Perhaps the remote cannot be contacted.)
+* `REMOVEEXPORT Key`  
+  Requests the remote to remove content stored by `TRANSFEREXPORT`
+  with the previously provided `EXPORT` Name.  
+  * `REMOVE-SUCCESS Key`  
+    Indicates the content has been removed from the remote. May be returned when
+    the content was already not present.
+  * `REMOVE-FAILURE Key ErrorMsg`  
+    Indicates that the content was unable to be removed from the remote.
+* `REMOVEEXPORTDIRECTORY Directory`  
+  Requests the remote remove an exported directory.  
+  If the remote does not use directories, or `REMOVEEXPORT` cleans up
+  directories that are empty, this does not need to be implemented.  
+  The directory will be in the form of a relative path, and may contain path
+  separators, whitespace, and other special characters.  
+  Typically the directory will be empty, but it could possibly contain
+  files or other directories, and it's ok to remove those, but not required
+  to do so.  
+  * `REMOVEEXPORTDIRECTORY-SUCCESS`  
+    Indicates that a `REMOVEEXPORTDIRECTORY` was done successfully.
+  * `REMOVEEXPORTDIRECTORY-FAILURE`  
+    Indicates that a `REMOVEEXPORTDIRECTORY` failed for whatever reason.
+    Should not be returned if the directory did not exist.
+* `RENAMEEXPORT Key NewName`  
+  Requests the remote rename a file stored on it from the previously
+  provided `EXPORT` Name to the NewName. Remotes that support exports but not
+  renaming do not need to implement this.  
+  * `RENAMEEXPORT-SUCCESS Key`  
+    Indicates that a `RENAMEEXPORT` was done successfully.
+  * `RENAMEEXPORT-FAILURE Key`  
+    Indicates that a `RENAMEEXPORT` failed for whatever reason.
+
+## import/export interface
+
+(This part is a draft, not implemented yet.)
+
+git-annex will use this interface when the special remote is
+initialized with both exporttree=yes and importtree=yes and indicates
+that it supports both imports and exports.
+
+### content identifiers
+
+The special remote needs to have some way to identify a particular version of a
+file. This is called a ContentIdentifier. A good ContentIdentifier needs to:
+
+* Be stable, so when a file has not changed, its content identifier
+  remains the same.
+* Change when a file is modified.
+* Be as unique as possible, but not necessarily fully unique.
+  A hash of the content would be ideal.
+  A (size, mtime, inode) tuple is as good a content identifier as git uses in
+  its index.
+* Be reasonably short, since it will be stored in the git-annex branch.
+
+It's up to the implementor of a external special remote program what
+to use for their ContentIdentifier, but not meeting those criteria
+will lead to unhappy users, and it's better not to implement this interface if
+you can't do it well.
+
+### protocol messages
+
+These are requests that git-annex sends to the special remote
+program. Once the special remote has finished performing a request,
+it should send one of the listed replies. Or, if it does not
+support a request, it can reply with `UNSUPPORTED-REQUEST`.
+
+* `EXPORTSUPPORTED`  
+  Used to check if a special remote supports exports.
+  Note that this request may be made before or after `PREPARE`.
+  * `EXPORTSUPPORTED-SUCCESS`  
+    Indicates that it makes sense to use this special remote as an export.
+  * `EXPORTSUPPORTED-FAILURE`  
+    Indicates that it does not make sense to use this special remote as an
+    export.
+* `IMPORTSUPPORTED`  
+  Used to check if a special remote supports imports.
+  Note that this request may be made before or after `PREPARE`.
+  * `IMPORTSUPPORTED-SUCCESS`  
+    Indicates that it makes sense to import from this special remote.
+  * `IMPORTSUPPORTED-FAILURE`  
+    Indicates that it does not make sense to import from this special remote.
+* `IMPORTKEYSUPPORTED`
+  Used to check if a special remote supports `IMPORTKEY`.
+  Note that this request may be made before or after `PREPARE`.
+  * `IMPORTKEYSUPPORTED-SUCCESS`  
+    Indicates that `IMPORTKEY` can be used.
+  * `IMPORTKEYSUPPORTED-FAILURE`  
+    Indicates that `IMPORTKEY` cannot be used.
+ * `VERSIONED`
+  Used to check if the special remote is versioned.
+  Note that this request may be made before or after `PREPARE`.
+  * `ISVERSIONED`  
+    Indicates that the remote is versioned.
+  * `NOTVERSIONED`  
+    Indicates that the remote is not versioned.
+* `LISTIMPORTABLECONTENTS`  
+  Used to get a list of all the files that are stored in the special 
+  remote. A block of responses
+  can be made to this, which must always end with `END`.
+  * `CONTENT Size Name`  
+    A file stored in the special remote. The Size is its size
+    in bytes. The Name is the name of the file on the remote,
+    in the form of a relative path, and may contain path separators,
+    whitespace, and other special characters.  
+    Always followed by `CONTENTIDENTIFIER`.
+  * `CONTENTIDENTIFIER ContentIdentifier`  
+    Provide the ContentIdentifier for the previous `CONTENT`.
+  * `HISTORY`  
+    When a special remote stores historical versions of files,
+    this can be used to list those versions. It opens a new
+    block of responses. This can be repeated any number of times
+    (indicating a branching history), and histories can also
+    be nested multiple levels deep.  
+    This should only be used when the remote supports using
+    "TRANSFER RECEIVE Key" to retrieve historical versions of files.
+    And, it should only be used when the remote replies `ISVERSIONED`
+    to the `VERSIONED` message.
+  * `END`  
+    Indicates the end of a block of responses.
+* `LOCATION Name`  
+  Comes before each of the following requests (except for
+  REMOVEEXPORTDIRECTORYWHENEMPTY), 
+  specifying the name of the file on the remote. It will be in the
+  form of a relative path, and may contain path separators,
+  whitespace, and other special characters.  
+  No response is made to this message.
+* `EXPECTED ContentIdentifier`  
+  Comes before each of the following requests (except
+  for REMOVEEXPORTDIRECTORYWHENEMPTY), specifying the
+  ContentIdentifier that is expected to be present on the remote.
+* `NOTHINGEXPECTED`  
+  If no ContentIdentifier is expected to be present, this is sent
+  rather than `EXPECTED`.
+* `IMPORTKEY File`
+  This only needs to be implemented if IMPORTKEYSUPPORTED indicates
+  it is supported. And if a remote did not support it before, adding
+  it will make importing the same content as before generate a likely
+  different tree, which can lead to merge conflicts. So be careful
+  implementing this.  
+  Generates a key by querying the remote for eg, a checksum.
+  (See [[internals/key_format]] for details of how to format a key.)
+  Any kind of key can be generated, depending on what the remote
+  can support.  
+  The user expects this to be reasonably fast and not use a lot of disk
+  space. It should not download the whole content of the file from the
+  remote.  
+  Must take care to generate a key for the same content as the 
+  ContentIdentifier specified by `EXPECTED`, or otherwise fail.  
+  Replies:
+  * `IMPORTKEY-SUCCESS Key`
+  * `IMPORTKEY-SKIP`  
+    This causes nothing to be imported for this file.
+  * `IMPORTKEY-FAILURE ErrorMsg`
+* `RETRIEVEEXPORTEXPECTED File`  
+  Retrieves the content of a file from the special remote
+  to the File on local disk. Must take care to only retrieve
+  content that has the ContentIdentifier specified by 
+  `EXPECTED`.  
+  While the transfer is running, the remote can send any number of
+  `PROGRESS` messages. Once the transfer is complete, it finishes by
+  sending one of these replies:
+  * `RETRIEVE-SUCCESS`
+    Indicates that the retrieve was successful.
+  * `RETRIEVE-FAILURE ErrorMsg`  
+    Indicates the retrieve failed.
+* `STOREEXPORTEXPECTED Key File`  
+  Stores the content of File on the local disk to the previously
+  provided Name on the remote. If the Name already exists on the remote,
+  must take care to only overwrite it when it has the
+  ContentIdentifier that was previously provided by `EXPECTED`.
+  If some other content has been written to the Name,
+  it should not overwrite it.  
+  While the transfer is running, the remote can send any number of
+  `PROGRESS` messages. Once the transfer is complete, it finishes by
+  sending one of these replies:
+  * `STORE-SUCCESS Key ContentIdentifier`
+    Indicates that the store was successful. The ContentIdentifier
+    must be for the content that was stored.
+  * `STORE-FAILURE Key ErrorMsg`  
+    Indicates the store failed.
+* `CHECKPRESENTEXPORTEXPECTED Key`  
+  Requests the remote to check if the previously provided Name
+  is present in it, and still has the ContentIdentifier that was
+  previously provided by `EXPECTED`.  
+  * `CHECKPRESENT-SUCCESS Key`  
+    Indicates that a content has been positively verified to be present
+    in the remote.
+  * `CHECKPRESENT-FAILURE Key`  
+    Indicates that a content has been positively verified to not be
+    present in the remote, or does not have the expected
+    ContentIdentifier.
+  * `CHECKPRESENT-UNKNOWN Key ErrorMsg`  
+    Indicates that it is not currently possible to verify if content is
+    present in the remote. (Perhaps the remote cannot be contacted.)
+* `REMOVEEXPORTEXPECTED Key`  
+  Requests the remote to remove the content at the previously
+  provided Name, but only when it matches the ContentIdentifier
+  that was provided by `EXPECTED`.
+  * `REMOVE-SUCCESS Key`  
+    Indicates the content has been removed from the remote. May be returned when
+    the content was already not present.
+  * `REMOVE-FAILURE Key ErrorMsg`  
+    Indicates that the content was unable to be removed from the remote,
+    either because of an access problem, or because it did not match
+    the ContentIdentifier.
+* `REMOVEEXPORTDIRECTORYWHENEMPTY Directory`  
+  Requests the remote remove an exported directory, so long as it's empty.  
+  If the remote does not use directories, or `REMOVEEXPORTEXPECTED`
+  cleans up directories that are empty, this does not need to be implemented.  
+  The directory will be in the form of a relative path, and may contain path
+  separators, whitespace, and other special characters.  
+  * `REMOVEEXPORTDIRECTORY-SUCCESS`  
+    Indicates that the directory was removed, or was not empty.
+  * `REMOVEEXPORTDIRECTORY-FAILURE`  
+    Indicates that the directory was empty, but could not be
+    removed for some reason.
+
+### protocol example
+
+The protocol starts off with VERSION etc as usual, and
+then git-annex asks the special remote if it supports
+export and import, which it does:
+
+	VERSION 1
+	EXTENSIONS INFO
+	EXTENSIONS
+	PREPARE
+	EXPORTSUPPORTED
+	EXPORTSUPPORTED-SUCCESS
+	IMPORTSUPPORTED
+	IMPORTSUPPORTED-SUCCESS
+
+git-annex asks for a list of files stored in the special remote:
+
+	LISTIMPORTABLECONTENTS
+
+Which in the simple case looks like this:
+
+	CONTENT 100 foo
+	CONTENTIDENTIFIER 100 48511528411921470
+	CONTENT 200 bar
+	CONTENTIDENTIFIER 200 48511528411963410
+	END
+
+Or it could look like this, for a special remote that supports
+versions, and has two branches of history, with one branch having
+several different versions of the file "foo", and the second
+branch having a single version. Here the blocks have been indented to aid
+understanding; the real protocol does not include indenation.
+
+	  CONTENT 100 foo
+	  CONTENTIDENTIFIER 100 48511528411921470
+	  CONTENT 200 bar
+	  CONTENTIDENTIFIER 200 48511528411963410
+	  HISTORY
+	    CONTENT 99 foo
+	    CONTENTIDENTIFIER 99 2113620116963530
+	    HISTORY
+	      CONTENT 1 foo
+	      CONTENTIDENTIFIER 1 2110338579019192
+	    END
+	  END
+	  HISTORY
+	    CONTENT 88 foo
+	    CONTENTIDENTIFIER 88 2104982727272727
+	  END
+	END
+
+(Note that "bar" is a new file; it was not present in any
+of the older versions.)
+
+Next git-annex asks for the content of a file to be retrieved.
+
+	LOCATION foo
+	EXPECTED 100 48511528411921470
+	RETRIEVEEXPORTEXPECTED tmpfile
+
+If the requested version no longer exists, the response should be:
+
+	RETRIEVE-FAILURE content has changed
diff --git a/doc/design/external_special_remote_protocol/export_and_import_appendix/comment_1_9bcf18e2bbe04bf5321e4fc33cca577c._comment b/doc/design/external_special_remote_protocol/export_and_import_appendix/comment_1_9bcf18e2bbe04bf5321e4fc33cca577c._comment
new file mode 100644
index 0000000000..e84e4e6ef5
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/export_and_import_appendix/comment_1_9bcf18e2bbe04bf5321e4fc33cca577c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Status of the import/export protocol implementation"
+ date="2023-04-07T09:17:21Z"
+ content="""
+As of now, the protocol specification states \"This part is a draft, not implemented yet.\" To which degree is this still true? Would it be possible to implement a custom remote that implements (some of) these features, and have git-annex use it in an importtree=yes,exporttree=yes scenario?
+"""]]
diff --git a/doc/design/external_special_remote_protocol/export_and_import_appendix/comment_2_6bea5a316df43a8306fb1cb19192db3f._comment b/doc/design/external_special_remote_protocol/export_and_import_appendix/comment_2_6bea5a316df43a8306fb1cb19192db3f._comment
new file mode 100644
index 0000000000..647c5a70fc
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/export_and_import_appendix/comment_2_6bea5a316df43a8306fb1cb19192db3f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-06-23T16:07:39Z"
+ content="""
+@mih it's still only a draft. See
+[[todo/add_import_tree_to_external_special_remote_protocol]]
+
+What I would like to do is work on implementing it in concert with someone
+making a special remote that uses it, so we can find the pain points and
+iterate a bit and hopefully improve it.
+"""]]
diff --git a/doc/design/gcrypt.mdwn b/doc/design/gcrypt.mdwn
new file mode 100644
index 0000000000..d5b9c064bc
--- /dev/null
+++ b/doc/design/gcrypt.mdwn
@@ -0,0 +1,8 @@
+To integrate with git-remote-gcrypt, a key thing is to have a way to map
+from the gcrypt-id of an encrypted repository to a git-annex repository
+uuid.
+
+To do this, we'll make a v5 UUID, feeding in the gcrypt-id.
+The namespace used is itself a v5 UUID, generated using the URL
+namespace and the URL of this page at the time this scheme was
+developed: "http://git-annex.branchable.com/design/gcrypt/"
diff --git a/doc/design/git-remote-daemon.mdwn b/doc/design/git-remote-daemon.mdwn
new file mode 100644
index 0000000000..41e0c93e18
--- /dev/null
+++ b/doc/design/git-remote-daemon.mdwn
@@ -0,0 +1,173 @@
+# goals
+
+* be configured like a regular git remote, with an unusual url
+  or other configuration
+* receive notifications when a remote has received new commits,
+  and take some action
+* optionally, do receive-pack and send-pack to a remote that
+  is only accessible over an arbitrary network transport
+  (like assistant does with XMPP)
+* optionally, send/receive git-annex objects to remote
+  over an arbitrary network transport
+
+# difficulties
+
+* authentication & configuration
+* multiple nodes may be accessible over a single network transport,
+  with it desirable to sync with any/all of them. For example, with
+  XMPP, there can be multiple friends synced with. This means that
+  one git remote can map to multiple remote nodes. Specific to git-annex,
+  this means that a set of UUIDs known to be associated with the remote
+  needs to be maintained, while currently each remote can only have one
+  annex-uuid in .git/config.
+
+# payoffs
+
+* support [[assistant/telehash]]!
+* Allow running against a normal ssh git remote. This would run
+  git-annex-shell on the remote, watching for changes, and so be able to
+  notify when a commit was pushed to the remote repo. This would let the
+  assistant immediately notice and pull. So the assistant would be fully
+  usable with a single ssh remote and no other configuration!
+  **do this first**
+* clean up existing XMPP support, make it not a special case, and not
+  tightly tied to the assistant
+* git-remote-daemon could be used independantly of git-annex,
+  in any git repository.
+
+# design
+
+Let git-remote-daemon be the name. Or for git-annex,
+`git annex remotedaemon`.
+
+It runs in one of two ways:
+
+1. Forked to background, using a named pipe for the control protocol.
+2. With --foreground, the control protocol goes over stdio.
+
+Either way, behavior is the same:
+
+* Get a list of remotes to act on by looking at .git/config
+* Automatically notices when a remote has changes to branches
+  matching remote.$name.fetch, and pulls them down to the appropriate
+  location.
+* When the control protocol informs it about a new ref that's available,
+  it offers the ref to any interested remotes.
+
+# control protocol
+
+This is an asynchronous protocol. Ie, either side can send any message
+at any time, and the other side does not send a reply.
+
+It is line based and intended to be low volume and not used for large data.
+
+TODO: Expand with commands for sending/receiving git-annex objects, and
+progress during transfer.
+
+TODO: Will probably need to add something for whatever pairing is done by
+the webapp.
+
+## emitted messages
+
+* `CONNECTED uri`
+
+  Sent when a connection has been made with a remote.
+
+* `DISCONNECTED uri`
+
+  Sent when connection with a remote has been lost.
+
+* `SYNCING uri`
+
+  Indicates that a pull or a push with a remote is in progress.
+  Always followed by DONESYNCING.
+
+* `DONESYNCING uri 1|0`
+
+  Indicates that syncing with a remote is done, and either succeeded
+  (1) or failed (0).
+
+* `WARNING uri string`
+
+  A message to display to the user about a remote.
+
+## consumed messages
+
+* `PAUSE`
+
+  The user has requested a pause.  
+  git-remote-daemon should close connections and idle.
+
+* `LOSTNET`
+
+  The network connection has been lost.  
+  git-remote-daemon should close connections and idle.
+
+* `RESUME`
+
+  Undoes PAUSE or LOSTNET.  
+  Start back up network connections.
+
+* `CHANGED ref ...`
+
+  Indicates that a ref is new or has changed. These can be offered to peers,
+  and peers that are interested in them can pull the content.
+
+* `RELOAD`
+
+  Indicates that configs have changed. Daemon should reload .git/config
+  and/or restart.
+
+  Possible config changes include adding a new remote, removing a remote,
+  or setting `remote.<name>.annex-sync` to configure whether to sync with a
+  particular remote.
+
+* `STOP`
+
+  Shut down git-remote-daemon
+
+  (When using stdio, it also should shutdown when it reaches EOF on 
+  stdin.)
+
+# encryption & authentication
+
+For simplicity, the network transports have to do their own end-to-end
+encryption. Encryption is not part of this design.
+
+(XMPP does not do end-to-end encryption, but might be supported
+transitionally.)
+
+Ditto for authentication that we're talking to who we intend to talk to.
+Any public key data etc used for authentication is part of the remote's
+configuration (or hidden away in a secure chmodded file, if necessary).
+This design does not concern itself with authenticating the remote node,
+it just takes the auth token and uses it.
+
+For example, in telehash, each node has its own keypair, which is used
+or authentication and encryption, and is all that's needed to route
+messages to that node.
+
+# network level protocol
+
+How do peers communicate with one another over the network?
+
+This seems to need to be network-layer dependant. Telehash will need
+one design, and git-annex-shell on a central ssh server has a very different
+(and much simpler) design.
+
+## ssh
+
+`git-annex-shell notifychanges` is run, and speaks a simple protocol
+over stdio to inform when refs on the remote have changed.
+
+No pushing is done for CHANGED, since git handles ssh natively.
+
+This is implemented and seems to work well.
+
+## telehash 
+
+TODO
+
+## xmpp
+
+Reuse [[assistant/xmpp]]
diff --git a/doc/design/git-remote-daemon/comment_1_bfa8f33a3fdb6e271dfbdd0378b5d364._comment b/doc/design/git-remote-daemon/comment_1_bfa8f33a3fdb6e271dfbdd0378b5d364._comment
new file mode 100644
index 0000000000..d93bab0902
--- /dev/null
+++ b/doc/design/git-remote-daemon/comment_1_bfa8f33a3fdb6e271dfbdd0378b5d364._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://johan.kiviniemi.name/"
+ nickname="Johan"
+ subject="Rolling hash chunking"
+ date="2014-04-04T14:16:25Z"
+ content="""
+I am not sure which page is the best for this comment, but this one seems somewhat relevant.
+
+Given that a future telehash implementation may download files from multiple peers, it might be a good idea to download files in chunks, possibly in parallel. In this case, it might be a good idea to use a rolling hash for chunking (like rsync et al). [There is a package for that on Hackage](http://hackage.haskell.org/package/hash-0.2.0.1/docs/Data-Hash-Rolling.html).
+
+git-annex could store a list of chunk checksums in `.git/annex/objects/…/SHA….chunks` whenever the repository holds a copy of the file. The checksum list would be a small fraction of the file in size, but all the checksum lists for all the files in a repository might take up too much space to store in the `git-annex` branch.
+
+When getting an object, git-annex could first download the `.chunks` file from a remote/peer and then proceed to download missing chunks in a BitTorrent-like fashion.
+
+If git-annex has an idea about what locally present object might be an earlier version of the file, it could compare the checksum lists and only download the parts that have changed (à la rsync).
+"""]]
diff --git a/doc/design/iabackup.mdwn b/doc/design/iabackup.mdwn
new file mode 100644
index 0000000000..0f52ae3b79
--- /dev/null
+++ b/doc/design/iabackup.mdwn
@@ -0,0 +1,242 @@
+This is a fairly detailed design proposal for using git-annex to build
+<http://archiveteam.org/index.php?title=INTERNETARCHIVE.BAK>
+
+[[!toc ]]
+
+## end-user view
+
+What the end user sees is a directory, with a .git subdirectory,
+and 100 thousand little files (actually, they're broken symlinks, on
+Linux/OSX). Over time, some of the symlinks start filling in with
+"random" content from the IA. 
+
+The user can look at that content, or even delete files they don't want to
+host.
+
+The user can control how much total disk space the directory takes up.
+(It will use around 100 mb when empty.)
+
+## sharding to scale
+
+The IA contains some 14 million Items. Inside these Items are 271 million
+files. Around 177 million of those are available for download.
+
+git repositories do not scale well in the 1-10 million file 
+range, and very badly above that. Storing all that in a git repository
+would strain git's scalability badly.
+
+Solution: Create multiple git repositories, and split the files
+amoung them.
+
+* If each git repository holds 100 thousand files, that is 1770
+  repositories, which is not an unmanagable number. 
+  (For comparison, git.debian.org has 18500 repositories.)
+
+* The IA is ~20 Petabytes large. Each shard would thus be around 1
+  terabyte in size, although this will vary considerably.
+
+* Clients are assigned one or more shards, and clone those repositories.
+
+* A client decides which files in its shard to back up, and does
+  so by running "git annex get" on them. This downloads the files
+  over http from the IA.
+
+* A client will typically not back up its entire shard, but maybe
+  only 500 gb or less of it. Also, we want redundancy (LOCKSS)
+  -- say at least 3 copies of each file. So, a given shard will probably
+  have between 3 and 9 clients handling it.
+
+* Add new shards as the IA continues to grow.
+
+Problem: Need to get the checksums for the files, for git-annex
+to use. The census published by the IA only has md5sums in it. While
+git-annex can use md5sums, this allows bad actors to find md5 collisions
+with files from the archive, and upload bogus files that checksum ok
+when restoring.
+
+## creating a shard
+
+This is a simple matter of making a git repository and telling git-annex
+the filenames and urls that belong in it.
+
+A script can do this using the `git annex fromkey` and `git annex
+registerurl` commands. Time to make such a repository with 100k files
+is in the 10 minute range (faster on SSD or ramdisk).
+
+## adding a client
+
+When a client registers to participate:
+
+1. Generate a UUID, which is assigned to this client, and send it to the
+   client, and assign that UUID to a particular shard.
+2. Send the client an appropriate auth token (eg, a locked down ssh private
+   key) to let them access the shard's git repository (or all the shards).
+3. Client clones its assigned shard git repository,
+   runs `git annex init reinit $UUID`.
+
+Note that a client could be assigned to multiple shards, rather than just
+one. Probably good to keep a pool of empty shards that have clients waiting
+for new files to be added.
+
+Note that we may want to enable direct mode in the client's clone, 
+because it lets the user easily delete files to free up space.
+OTOH, direct mode is slow and less safe, so we might prefer to use indirect
+mode, and then the client would need to use `git annex drop` if they
+decided to remove content.
+
+## distributing files
+
+1. Client runs `git annex sync --content`, which downloads as many
+   files from the IA as will fit in their disk's free space
+   (leaving some configurable amount free in reserve by configuring
+   annex.diskreserve)
+2. Note that [[numcopies|copies]] and [[preferred_content]] settings can be
+   used to make clients only want to download an file if it's not yet
+   reached the desired number of copies. Lots of flexibility here in
+   git-annex.
+3. git-annex will push back to the server an updated git-annex branch,
+   which will record when it has successfully stored an file.
+
+## bad actors
+
+Clients can misbehave in probably many ways. The best defense for many
+misbehaviors is to distribute files to enough different clients that we can
+trust some of them.
+
+The main git-annex specific misbehavior is that a client could try to push
+garbage information back to the origin repository on the server.
+
+To guard against this, the server will reject all pushes of branches other
+than the git-annex branch, which is the only one clients need to modify.
+
+Check pushes of the git-annex branch. There are only a few files that
+clients can legitimately modify, and the modifications will always involve
+that client's UUID, not some other client's UUID. Reject anything shady.
+
+These checks can be done in a git `update` hook. Rough estimate is that
+such a hook would be a couple hundred lines of code.
+
+## verification
+
+We want a lightweight verification process, to verify that a client still
+has the data. This can be done using `git annex fsck`, which can be
+configured to eg, check each file only once per month.
+
+git-annex will need a modification here. Currently, a successful fsck
+does not leave any trace in the git-annex branch that it happened. But
+we want the server to track when a client is not fscking (the user probably
+dropped out).
+
+The modification is simple; just have a successful fsck
+update the timestamp in the fscked file's location log.
+It will probably take just a few hours to code.
+
+With that change, the server can check for files that not enough clients
+have verified they have recently, and distribute them to more clients.
+
+(This is now implemented.)
+
+Note that bad actors can lie about this verification; it's not a proof they
+still have the file. But, a bad actor could prove they have a file, and
+refuse to give it back if the IA needed to restore the backup, too.
+
+## fire drill
+
+If we really want to test how well the system is working, we need a fire
+drill.
+
+1. Pick some files that we'll assume the IA has lost in some disaster.
+2. Look up the shard the file belongs to.
+3. Get the git-annex key of the file, and tell git-annex it's been
+   lost from the IA, by running in its shard: `setpresentkey $key $iauuid 0`
+4. The next time a client runs `git annex sync --content`, it will notice
+   that the IA repo doesn't have the file anymore. The client will then
+   send the file back to the origin repo.
+5. To guard against bad actors, that restored file should be checked with
+   `git annex fsck`. If its checksum is good, it can be re-injected back
+   into the IA. (Or, the fire drill was successful.)
+   (Remember to turn off the fire alarm by running
+   `setpresentkey $key $iauuid 1`)
+
+## shard servers
+
+A server at the IA (or otherwise with a fast pipe) is needed to serve
+the shards. One server can probably manage them all.
+Let's consider what this server needs to have on it:
+
+* git and git-annex
+* ssh server
+* The git repository for each shard. A few hundred mb per shard.
+* The git update hook to filter out bad pushes.
+* Some way to learn when a new user has registered to access a shard,
+  so their ssh key is given access.
+
+## other optional nice stuff
+
+The user running a client can delete some or all of their files at any
+time, to free up disk space. The next time `git-annex sync` runs on the client,
+it'll notice and let the server know, and other clients will then take
+over storing it. (Or if the git-annex assistant is run on the client,
+it would inform the server immediately.)
+
+The user is also free to move files around (within the git repository
+directory), modify files, view them, etc. This doesn't affect anyone else.
+
+Offline storage is supported. As long as the user can spin it up from time
+to time to run `git annex fsck`.
+
+More advanced users might have multiple repositories on different disks.
+Each has their own UUID, and they could move files around between them as
+desired; this would be communicated back to the origin repository
+automatically.
+
+Shards could have themes, and users could request to be part of the
+shard that includes Software, or Grateful Dead, etc. This might encourage
+users to devote more resources.
+
+Or, rather than doing a lucky dip and getting one or a couple shards,
+a user could clone em all, and pick just which files to get.
+
+The contents of files sometimes changes.
+This can be reflected by updating the file in the git repository.
+Clients will then download the new version of the file. (They will also
+tend to retain the old version, although this can be dealt with by using
+`git annex unused`).
+
+Items sometimes go dark; this could be reflected by deleting the Item's
+files from the repository. It's up to the clients what they do with the
+content of such Items.
+
+Client's repos could be put into groups to classify them. For example,
+there could be groups per continent, or for trust levels, or whatever.
+These can be used by [[preferred_content]] expressions to fine tune how
+files are spread out amoung the available clients.
+
+## other potential gotchas
+
+If any single file is very large (eg, 10 terabytes), there may not be
+any clients that can handle it. This could be dealt with by splitting up
+the file into smaller chunks. Word is there is a single 2 tb item, and a few
+more around 100 gb, so this is probably not a concern.
+
+A client could add other files to its local repo, and git-annex branch
+pushes would include junk data about those files. It should probably be
+filtered out by the git update hook (rejecting the whole push because of
+this seems excessive).
+
+There may be a thundering herd problem, where many clients end up
+downloading the same file at the same time, and more copies than neecessary
+result. The next `git annex sync --content` in some of the
+redundant clients will notice this and drop that file, and presumably
+download some other file. It would be good to avoid this problem,
+perhaps by having a new client initially download a random set of the
+files in their shard that don't yet have enough copies.
+
+With clients all fscking their part of a shard once a month,
+that will increase the size of the git repository, with new distributed
+fsck updates. I have run some test and this fsck overhead delta compresses
+well. With a 10 thousand file repo and 100 clients all updating the
+location log, the monthly fsck only added 1 mb to the repository size
+(after `git gc --aggressive`). Should scale linearly with number of files
+in repo. Note that `git annex forget` could be used to forget old
+historical data if the repo grew too large from fsck updates.
diff --git a/doc/design/iabackup/comment_1_d33c0910973bc37ce81bf434017e11fd._comment b/doc/design/iabackup/comment_1_d33c0910973bc37ce81bf434017e11fd._comment
new file mode 100644
index 0000000000..ec06675613
--- /dev/null
+++ b/doc/design/iabackup/comment_1_d33c0910973bc37ce81bf434017e11fd._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="great to see such a large scale effort ongoing"
+ date="2015-03-06T04:47:30Z"
+ content="""
+and I would still maintain my view that removing intermediate directory withing .git/annex/objects whose  current roles is simply to provide read-only protection might half the burden on the underlying file system, either annex repo(s) are multitude or a single one [1]. lean view [2] could also be of good use as well[2].  Similar exercises with simulated annex'es with >5M files also \"helped\" to identify problems with ZOL (ZFS on Linux) caching suggesting that even mere handling of such vast arrays of tiny files (as dead symlinks) might give filesystems a good test, so the leaner impact would be -- the better.
+
+[1] e.g. https://github.com/datalad/datalad/issues/32#issuecomment-70523036
+[2] https://github.com/datalad/datalad/issues/25
+"""]]
diff --git a/doc/design/iabackup/comment_2_c0a59549409faa355a461e85a1c3f908._comment b/doc/design/iabackup/comment_2_c0a59549409faa355a461e85a1c3f908._comment
new file mode 100644
index 0000000000..135917b4ee
--- /dev/null
+++ b/doc/design/iabackup/comment_2_c0a59549409faa355a461e85a1c3f908._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2015-03-09T16:48:18Z"
+ content="""
+I've tried throwing about ~16 million files at git/git-annex in the past where some files were 1-2kb in size (around 30% of them). git/git-annex doesn't work well at that scale.
+"""]]
diff --git a/doc/design/iabackup/comment_3_560d3f65d543c3af9722ed7e9a11e920._comment b/doc/design/iabackup/comment_3_560d3f65d543c3af9722ed7e9a11e920._comment
new file mode 100644
index 0000000000..dca02f8af8
--- /dev/null
+++ b/doc/design/iabackup/comment_3_560d3f65d543c3af9722ed7e9a11e920._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmsy_GIefGlGGD_XJp_R6EsWIRUC4ev9XU"
+ nickname="David"
+ subject="This is a BIG task"
+ date="2015-03-13T20:48:56Z"
+ content="""
+If I understand it correctly, 20PB at 2400 shards of 8TB each with 3 copies is 24TB/shard at 1TB/client is 2400*24 = ~60K clients assuming no churn. So it would probably need ~100K clients to cover the churn and have a good chance that each shard had 3 copies at all times. That's 1/3 the size of BOINC's active population.
+
+It would take time to scale to that population. And it would take time to get three copies out of the Archive. During that time, the Archive is growing. The back of my envelope says that doing this in 2.5yrs roughly doubles the Archive's outbound bandwidth if you average it across the 2.5 years. But the population would grow slowly to start with, then faster, so that the bandwidth impact would be back-loaded. And at the end of the 2.5 years, you would need a lot more than the 100K users.
+
+A design that used erasure coding or entanglement would reduce the storage and bandwidth demand considerably while providing adequate reliability.
+
+"""]]
diff --git a/doc/design/iabackup/comment_4_465c0966c96a57d189f678d4fa724aa0._comment b/doc/design/iabackup/comment_4_465c0966c96a57d189f678d4fa724aa0._comment
new file mode 100644
index 0000000000..15faa40b59
--- /dev/null
+++ b/doc/design/iabackup/comment_4_465c0966c96a57d189f678d4fa724aa0._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/idrn495us85k6mwfdMUolYIsyp4-#cf755"
+ subject="It's not so bad .. only about 10PB"
+ date="2015-04-30T01:19:38Z"
+ content="""
+The good news is that web-archive (.ARC) items are not publicly browsable, and that's about half of the archive's content, so you're only looking at about 10PB to backup.
+
+The bad news is that unless you can work something out with archive.org (which seems unlikely; web-archive items are restricted to protect them legally), or use the old waybackup interface (which I don't think works anymore), or use the wayback machine (which last I heard only supported a few hundred connections per second) you'll only be able to back up half their data.
+
+Still, non-web items seem like a nice place to start.
+
+
+"""]]
diff --git a/doc/design/iabackup/comment_5_7e4d1db9c69c63e79ca13db2ad87c384._comment b/doc/design/iabackup/comment_5_7e4d1db9c69c63e79ca13db2ad87c384._comment
new file mode 100644
index 0000000000..4d24e8f6fc
--- /dev/null
+++ b/doc/design/iabackup/comment_5_7e4d1db9c69c63e79ca13db2ad87c384._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="db48x"
+ subject="14 of 21PB, actually"
+ date="2015-04-30T02:58:05Z"
+ content="""
+IA helpfully did a quick count for us: https://archive.org/details/ia-bak-census_20150304
+"""]]
diff --git a/doc/design/importing_trees_from_special_remotes.mdwn b/doc/design/importing_trees_from_special_remotes.mdwn
new file mode 100644
index 0000000000..5e1603c268
--- /dev/null
+++ b/doc/design/importing_trees_from_special_remotes.mdwn
@@ -0,0 +1,345 @@
+Importing trees from special remotes allows data published by others to be
+gathered. It also combines with [[exporting_trees_to_special_remotes]]
+to let a special remote act as a kind of git working tree without `.git`,
+that the user can alter data in as they like and use git-annex to pull
+their changes into the local repository's version control.
+
+(See also [[todo/import_tree]].)
+
+The basic idea is to have a `git annex import --from remote` command.
+
+It would find changed/new/deleted files on the remote.
+Download the changed/new files and inject into the annex.
+And then generate a commit that can be merged (by the command or later by
+the user) to make their branch reflect changes made on the remote.
+
+## generating commits and tracking branches
+
+For the merge to work correctly, the parent of the generated commit
+needs to be, when possible, a commit whose tree corresponds to the last
+tree that was exported to the remote. This way, git merge will treat the
+remote the same as a normal git remote where changes were made.
+
+If the last exported commit is not known, it would need to make a commit
+with no parent. git merge would then need --allow-unrelated-histories,
+and it would be more likely for the merge to have conflicts.
+
+The export log does not record the last exported commit though, only the
+tree. And the exported tree may not be the tree of any commit in the
+history; it's often a subtree.
+
+Should the last exported commit be stored in the git-annex branch?
+Could be done, but maybe it's not needed.. What the user probably expects
+is that, since importing is like pulling from a remote, and exporting is
+like pushing, for there to be a remote tracking branch that is updated. Eg,
+"refs/remotes/S3/master". The special remote is not a git repo with
+branch, so doesn't really have a master branch of its own, but this naming
+means that the user can "git merge S3" to merge in the imported tree.
+
+If the user starts off in one repository, and later changes to using a
+different repository to import from the same special remote, the tracking
+branch would not be present there. So import would need to make a new branch
+with no parent, and they would have to use --allow-unrelated-histories.
+Perhaps the user could first export to the special remote, to get the
+branch set up, and then import. Assuming that exporting in this situation
+won't overwrite modified file on the special remote (see API below) and
+will succeed enough to update the tracking branch.
+
+Seems best to start with a remote tracking branch, since the user is going
+to expect there to be one, and if it later turns out that the last exported
+commit needs to be available across clones, store it in the git-annex
+branch then.
+
+Currently: There's a remote tracking branch, but no storage of tracking
+branch info in the git-annex branch.
+
+## command line interface
+
+`git annex import master --from foo` will import a tree from the remote
+and update the "refs/remotes/foo/master" tracking branch to that tree.
+
+Users will want a way to import files from a remote into a subdirectory,
+and by analogy to how `git annex export` handles that, it should be
+"master:subdir". So, `git annex import master:subdir --from foo`
+will import a tree from the remote and graft it into the current master
+branch at subdir (replacing whatever's there), storing the result in
+the "refs/remotes/foo/master" tracking branch.
+
+Note that while export can have a particular commit or tree sha specified,
+it does not makes sense to import *to* a particular sha.
+
+Should `git annex import` merge the tracking branch by itself, or leave it
+up to the user? Seems most ergonomic to merge by default; if the user
+wants to not merge it could be `git annex import --fetch --from remote`
+or a separate command. Currently: It does not merge.
+
+Also, there should be a way to configure the default tracking branch, so
+`git annex sync --content` first imports from a remote, merges that, and
+then exports to it. Currently `git annex export` has `--tracking` to
+configure the latter. It seems to only make sense to import and export the
+same tracking branch. So, should `git annex export --tracking` set the same
+thing, or perhaps it would be better to move the tracking branch
+configuration out of `git annex export` and into an interface that
+explicitly configures both import and export? Decision: Moved to
+remote.name.annex-tracking-branch setting.
+
+## content identifiers
+
+The remote is responsible for collecting a list of
+files currently in it, along with some content identifier. That data is
+sent to git-annex. git-annex keeps track of which content identifier(s) map
+to which keys, and uses the information to determine when a file on the
+remote has changed or is new.
+
+git-annex can simply build git tree objects as the file list
+comes in, looking up the key corresponding to each content identifier
+(or downloading the content from the remote and adding it to the annex
+when there's no corresponding key yet). It might be possible to avoid
+git-annex buffering much tree data in memory.
+
+----
+
+A good content identifier needs to:
+
+* Be stable, so when a file has not changed, the content identifier
+  remains the same.
+* Change when a file is modified.
+* Be as unique as possible, but not necessarily fully unique.  
+  A hash of the content would be ideal.
+  A (size, mtime, inode) tuple is as good a content identifier as git uses in
+  its index.
+
+git-annex will need a way to get the content identifiers of files
+that it stores on the remote when exporting a tree to it, so it can later
+know if those files have changed.
+
+----
+
+The content identifier needs to be stored somehow for later use.
+
+It would be good to store the content identifiers only locally, if
+possible.
+
+Would local storage pose a problem when multiple repositories import from
+the same remote? In that case, perhaps different trees would be imported,
+and merged into master. So the two repositories then have differing
+masters, which can be reconciled in merge as usual.
+
+Since exporttree remotes don't have content identifier information yet, it
+needs to be collected the first time import tree is used. (Or import
+everything, but that is probably too expensive). Any modifications made to
+exported files before the first import tree would not be noticed. Seems
+acceptible as long as this only affects exporttree remotes created before
+this feature was added.
+
+What if repo A is being used to import tree from R for a while, and the
+user gets used to editing files on R and importing them. Then they stop
+using A and switch to clone B. It would not have the content identifier
+information that A did. It seems that in this case, B needs to re-download
+everything, to build up the map of content identifiers.
+(Anything could have changed since the last time A imported).
+That seems too expensive!
+
+Would storing content identifiers in the git-annex branch be too
+expensive? Probably not.. For S3 with versioning a content identifier is
+already stored. When the content identifier is (mtime, size, inode),
+that's a small amount of data. The maximum size of a content identifier
+could be limited to the size of a typical hash, and if a remote for some
+reason gets something larger, it could simply hash it to generate
+the content identifier.
+
+Decision: Content identifiers do get stored in the git-annex branch.
+It's up to the remote to generate content identifiers that are reasonably
+short.
+
+## safety
+
+Since the special remote can be written to at any time by something other
+than git-annex, git-annex needs to take care when exporting to it, to avoid
+overwriting such changes.
+
+This is similar to how git merge avoids overwriting modified files in the
+working tree.
+
+Surprisingly, git merge doesn't avoid overwrites in all conditions! I
+modified git's merge.c to sleep for 10 seconds after `refresh_index()`, and
+verified that changes made to the work tree in that window were silently
+overwritten by git merge. In git's case, the race window is normally quite
+narrow and this is very unlikely to happen.
+
+Also, git merge can overwrite a file that a process has open for write;
+the processes's changes then get lost. Verified with
+this perl oneliner, run in a worktree and a second later 
+followed by a git pull. The lines that it appended to the 
+file got lost:
+
+	perl -e 'open (OUT, ">>foo") || die "$!"; sleep(10); while (<>) { print OUT $_ }'
+
+git-annex should take care to be at least as safe as git merge when
+exporting to a special remote that supports imports.
+
+The situations to keep in mind are these:
+
+1. File is changed on the remote after an import tree, and an export wants
+   to also change it. Need to avoid the export overwriting the
+   file. Or, need a way to detect such an overwrite and recover the version
+   of the file that got overwritten, after the fact.
+
+2. File is changed on the remote while it's being imported, and part of one
+   version + part of the other version is downloaded. Need to detect this
+   and fail the import.
+
+3. File is changed on the remote after its content identifier is checked
+   and before it's downloaded, so the wrong version gets downloaded.
+   Need to detect this and fail the import.
+
+The API design has some requirements that, if followed, makes those
+situations be handled well. The directory special remote is thus
+able to avoid these situations as well as git does, and the S3 special
+remote with versioning is able to recover data after those situations.
+
+But.. Other types of remotes are limited by remote APIs that don't
+let this be dealt with. If the limitation is explained to the user,
+and they understand how to avoid these situations, importing from
+such remotes could still be supported. Eg, if a user understands
+that modifications they make to files using their phone may get overwritten
+while git-annex is exporting to it, and so avoids using their phone during
+that process (or chooses to only ever modify certian files on their phone),
+then git-annex can safely support importing from their phone.
+
+## API design
+
+This is an extension to the ExportActions API.
+
+	listContents :: Annex (ContentHistory [(ExportLocation, ContentIdentifier)])
+
+	retrieveExportWithContentIdentifier :: ExportLocation -> ContentIdentifier -> (FilePath -> Annex Key) -> MeterUpdate -> Annex (Maybe Key)
+
+	storeExportWithContentIdentifier :: FilePath -> Key -> ExportLocation -> [ContentIdentifier] -> MeterUpdate -> Annex (Maybe ContentIdentifier)
+
+	removeExportWithContentIdentifier :: Key -> ExportLocation -> [ContentIdentifier] -> Annex Bool
+
+	removeExportDirectoryWhenEmpty :: Maybe (ExportDirectory -> Annex Bool)
+
+	checkPresentExportWithContentIdentifier :: Key -> ExportLocation -> [ContentIdentifier] -> Annex (Maybe Bool)
+
+listContents finds the current set of files that are stored in the remote,
+some of which may have been written by other programs than git-annex,
+along with their content identifiers. It returns a list of those, often in
+a single node tree.
+
+listContents may also find past versions of files that are stored in the
+remote, when it supports storing multiple versions of files. Since it
+returns a history tree of lists of files, it can represent anything from a
+linear history to a full branching version control history.
+
+Note that listContents does not need to worry about generating an
+ExportLocation that contains a ".." attack or an absolute path or other
+such mischief. Since a git tree is built from the ExportLocations, and is
+merged the same as a tree pulled from a regular git remote is, 
+git's usual safety measures avoid such attacks.
+
+retrieveExportWithContentIdentifier is used when downloading a new file from 
+the remote that listContents found. retrieveExport can't be used because
+it has a Key parameter and the key is not yet known in this case.
+(The callback generating a key will let eg S3 record the S3 version id for
+the key.)
+
+retrieveExportWithContentIdentifier should detect when the file it's
+downloaded may not match the requested content identifier (eg when
+something else wrote to it while it was being retrieved), and fail
+in that case.
+
+When a remote supports imports and exports, storeExport and removeExport 
+should not be used when exporting to it, and instead 
+storeExportWithContentIdentifier and removeExportWithContentIdentifier
+be used.
+
+storeExportWithContentIdentifier stores content and returns the 
+content identifier corresponding to what it stored. It can either get
+the content identifier in reply to the store (as S3 does with versioning),
+or it can store to a temp location, get the content identifier of that,
+and then rename the content into place.
+
+storeExportWithContentIdentifier must avoid overwriting any existing file
+on the remote, unless the file has the same content identifier that's passed
+to it, to avoid overwriting a file that was modified by something else.
+But alternatively, if listContents can later recover the modified file, it can
+overwrite the modified file.
+
+Similarly, removeExportWithContentIdentifier must only remove a file
+on the remote if it has the same content identifier that's passed to it,
+or if listContent can later recover the modified file. 
+Otherwise it should fail. (Like removeExport, removeExportWithContentIdentifier
+also succeeds if the file is not present.)
+
+Both storeExportWithContentIdentifier and removeExportWithContentIdentifier
+need to handle the case when there's a race with a concurrent writer.
+They can detect such races and fail. Or, if overwritten/deleted modified
+files can later be recovered by listContents, it's acceptable to not detect
+the race.
+
+removeExportDirectoryWhenEmpty is used instead of removeExportDirectory.
+It should only remove empty directories, and succeeds if there are files
+in the directory. This is needed because removeExportDirectory removes
+non-empty directories, but when importing the stuff in those directories is
+stuff that ought to be imported.
+
+checkPresentExportWithContentIdentifier is used instead of
+checkPresentExport. It should verify that one of the provided
+ContentIdentifiers matches the current content of the file.
+
+Note that renameExport is never used when the special remote supports
+imports, because it may have an implementation that loses changes
+to imported files. (For example, it may copy the file to the new name,
+and delete the old name.)
+
+## multiple git-annex repos accessing a special remote
+
+If multiple repos can access the remote at the same time, then there's a
+potential problem when one is exporting a new tree, and the other one is
+importing from the remote.
+
+This can be reduced to the same problem as exports of two
+different trees to the same remote, which is already handled with the
+export log.
+
+Once a tree has been imported from the remote, it's
+in the same state as exporting that same tree to the remote, so
+update the export log to say that the remote has that treeish exported
+to it. A conflict between two export log entries will be handled as
+usual, with the user being prompted to re-export the tree they want
+to be on the remote. (May need to reword that prompt.)
+
+----
+
+What if the export log indicates an unresolved export conflict,
+and the user tries to import from the special remote?
+
+Well, two trees got exported to the remote independently. The content of
+the remote is not known to export code when there's a conflict, but import
+will resolve that by getting a list of its contents. Although that may be
+an admixture of the two exported trees, and so not necessarily a change the
+user will want to merge into master.
+
+One approach is to not allow imports in this situation; require the export
+conflict be resolved first. (--force could override if the user just wants
+to import whatever ended up on the special remote.)
+
+Another approach, if the commits that contain the trees that were exported
+is known, is to do the import and make a commit that uses those commits
+as its parents. Which nicely indicates to git that there was a conflict and
+it got "resolved".
+
+However, note that there can be an export conflict that occurred on another
+clone, and that the local repo does not know about yet (git-annex branch 
+not synced). Importing will then import whatever the current state of the
+export conflict is. The export conflict will eventually be caught at export
+time, and the user can resolve it then. Since this is unavoidable, the two
+approaches above don't seem worth bothering with.
+
+Also, if an export is running at the same time as an import
+(presumably on two different clones), part of the
+changes made by the export will be imported and part not. Again this will
+lead to an export conflict being recorded and the user will have to sort it
+out later at export time.
diff --git a/doc/design/metadata.mdwn b/doc/design/metadata.mdwn
new file mode 100644
index 0000000000..4e43fe3441
--- /dev/null
+++ b/doc/design/metadata.mdwn
@@ -0,0 +1,182 @@
+[[!toc]]
+
+# metadata
+
+Attach an arbitrary set of metadata to a key. This consists of any number
+of fields. Each field has an unordered set of values. The special field
+"tag" has as its values any tags that are set for the key.
+
+Store in git-annex branch, next to location log files.
+
+Storage needs to support union merging, including removing an old value
+of a field, and adding a new value of a field.
+
+# filtered branches
+
+See [[tips/metadata_driven_views]]
+
+The reason to use specially named filtered branches is because it makes
+self-documenting how the repository is currently filtered.
+
+## unmatched files in filtered branches
+
+TODO Files not matching the view should be able to be included in
+the filtered branch, in a special location, an "other" directory.
+
+For example, it could make a "other" directory containing files
+without a tag when viewing by tag.
+
+It might be nice, if in a two level view, for the other directories
+to nest. For example, `other/2014/file`. However, that leads to a
+performance problem: When adding a level to a view, it has to look at each
+file in the "other" directory and generate a view for it too. With a lot
+of files, that'd be slow.
+
+Instead, why not replicate the parent branch's directory structure inside
+the "other" directory? Then the directory tree only has to be constructed
+once, and can be left alone when refining a view.
+
+## operations while on filtered branch
+
+* If files are removed and git commit called, git-annex should remove the
+  relevant metadata from the files. **done**  
+  (Currently, only metadata used for visible subdirs is added and removed
+  this way.)
+  (Also, this is not usable in direct mode because deleting the
+  file.. actually deletes it...)
+* If a file is moved into a new subdirectory while in a view branch,
+  a tag is added with the subdir name. This allows on the fly tagging.
+  **done**
+* `git annex sync` should avoid pushing out the view branch, but
+  it should check if there are changes to the metadata pulled in, and update
+  the branch to reflect them.
+
+## automatically added metadata
+
+When `annex.genmetadata` is set, git annex add automatically attaches
+some metadata to a file. Currently year and month fields, from its mtime.
+
+There's also a post-commit-annex hook script.
+
+## directory hierarchy metadata
+
+From the original filename used in the master branch, when
+constructing a view, generate fields. For example foo/bar/baz.mp3
+would get /=foo, foo/=bar, foo/bar/=baz, and .=mp3.
+
+Note that dir/=subdir allows a view to use `dir/=*` and only
+match one level of subdirs with the glob. So is better than dir=foo/bar
+as the metadata. (Alternatively, could do special glob matching.)
+
+This allows using whatever directory hierarchy exists to inform the view,
+without locking the view into using it. 
+
+Complication: When refining a view, it only looks at the filenames in
+the view, so it has to map from
+those filenames to derive the same metadata, unless there is persistent
+storage. Luckily, the filenames used in the views currently include the
+subdirs.
+
+# other uses for metadata
+
+Uses are not limited to view branches.
+
+`git annex checkoutmeta year=2014 talk` in a subdir of master could create the
+same tree of files filter would. The user can then commit that if desired.
+Or, they could run additional commands like `git annex fadd` to refine the
+tree of files in the subdir.
+
+Metadata can be used for configuring numcopies. One way would be a
+numcopies=n value attached to a file. But perhaps better would be to make
+the numcopies.log allow configuring numcopies based on which files have
+other metadata.
+
+Other programs could query git-annex for the metadata of files in the work
+tree, and do whatever it wants with it.
+
+# filenames
+
+The hard part of this is actually getting a useful filename to put in the
+view branch, since git-annex only has a key which the user will not
+want to see.
+
+* Could use filename metadata for the key, recorded by git-annex add (which
+  may not correspond to filenames being used in regular git branches like
+  master for the key).
+* Could use the Keys database's associated files. Currently only works for v6
+  unlocked files, and not for locked files.
+* Current approach: Have a reference branch (eg master) and walk it to
+  find filenames and
+  keys. Fine as long as it can be done efficiently. Also allows including
+  the subdirectory a file is in, potentially. cwebber points out that this
+  is essentially a form of tracking branch. Which implies it will need to
+  be updatable when the reference branch changes. Should be doable via
+  diff-tree.
+
+Note that we have to take care to avoid generating conflicting filenames.
+The current approach is to embed the full directory structure inside the
+filename in the view branch.
+
+## union merge properties
+
+While the storage could just list all the current values of a field on a
+line with a timestamp, that's not good enough. Two disconnected
+repositories can make changes to the values of a field (setting and
+unsetting tags for example) and when this is union merged back together,
+the changes need to be able to be replayed in order to determine which
+values we end up with. 
+
+To make that work, we log not only when a field is set to a value, 
+but when a value is unset as well.
+
+For example, here two different remotes added tags, and then later
+a tag was removed:
+
+	1287290776.765152s tag +foo +bar
+	1287290991.152124s tag +baz
+	1291237510.141453s tag -bar
+
+# efficient metadata lookup
+
+Looking up metadata for view generation so far requires traversing all keys
+in the git-annex branch. This is slow. A fast cache is needed.
+
+TODO
+
+# unlocked file issues
+
+View branches can't be used in direct mode repositories.
+
+But, view branches do work with unlocked files in v6 repositories.
+The resulting view branch has all its files locked, although you
+can unlock them again after entering the branch.
+
+# gotchas
+
+* Checking out a view branch can remove the current subdir. May be worth
+  detecting when this happens and help the user.
+  **done**
+
+* Git has a complex set of rules for what is legal in a ref name.
+  View branch names will need to filter out any illegal stuff. **done**
+
+* Metadata should be copied to the new key when adding a modified version
+  of a file. **done**
+
+* Filesystems that are not case sensitive (including case preserving OSX)
+  will cause problems if view branches try to use different cases for 
+  2 directories representing a metadata field.
+  
+  Solution might be to compare fields names case-insensitively, and
+  pick one representation consistently. **done**
+
+* Assistant needs to know about views, so it can update metadata when
+  files are moved around inside them. TODO
+
+* What happens if git annex add or the assistant add a new file while on a
+  view? If the file is not also added to the master branch, it will be lost
+  when exiting the view. TODO
+
+* The filename mangling can result in a filename in a view
+  that is too long for its containing filesystem. Should detect and do
+  something reasonable to avoid. TODO
diff --git a/doc/design/metadata/comment_10_9bc2825b18ce29d2c9b2f085b95aa68c._comment b/doc/design/metadata/comment_10_9bc2825b18ce29d2c9b2f085b95aa68c._comment
new file mode 100644
index 0000000000..107673c7c4
--- /dev/null
+++ b/doc/design/metadata/comment_10_9bc2825b18ce29d2c9b2f085b95aa68c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlZF5AC-FSxwkiay5ZgEYZwUzN69Wa6PTE"
+ nickname="Sunke"
+ subject="filename from metadata?"
+ date="2015-04-06T18:00:25Z"
+ content="""
+Hi everbody,
+is it possible to use a metadata field for the filename in a
+metadata driven view?
+
+I am thinking of the following use case:
+
+git annex metadata --set artist=Led\ Zeppelin --set album=Led\ Zeppelin\ IV --set title=04\ Stairway\ to\ heaven  some/weird/filename.mp3
+git annex view --filename-from title artist=* album=*
+
+result:
+Led Zeppelin/Led Zeppelin IV/04 Stairway to heaven.mp3
+"""]]
diff --git a/doc/design/metadata/comment_11_402d7d3e8e7f2df57eb6685134226642._comment b/doc/design/metadata/comment_11_402d7d3e8e7f2df57eb6685134226642._comment
new file mode 100644
index 0000000000..b7b8937c52
--- /dev/null
+++ b/doc/design/metadata/comment_11_402d7d3e8e7f2df57eb6685134226642._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2015-04-09T18:31:34Z"
+ content="""
+@Sunke, the reason that views make up their own filenames is to
+avoid the problem of having 2 files in a view that have the same
+name.
+
+In your example, that could happen if you used --set title
+with the same title for 2 separate files.
+
+So, I don't think this can be supported reasonably.
+"""]]
diff --git a/doc/design/metadata/comment_1_22ed80bd8eabaa836e9dfc2432531f04._comment b/doc/design/metadata/comment_1_22ed80bd8eabaa836e9dfc2432531f04._comment
new file mode 100644
index 0000000000..493db43397
--- /dev/null
+++ b/doc/design/metadata/comment_1_22ed80bd8eabaa836e9dfc2432531f04._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm3vKzS4eOWYpKMoYXqMIjNsIg_nYF-loU"
+ nickname="Konubinix"
+ subject="Already existing metadata implementation "
+ date="2014-02-22T21:45:25Z"
+ content="""
+Hi,
+
+I love the idea behing storing metadata.
+
+I suggest to exchange ideas (and maybe code) with projects already implementing metadata systems.
+
+I have tried several implementations and particularly noticed tmsu (http://tmsu.org/). This tool stores tags into a sqlite database and uses also a SHA-256 fingerprint of the file to be aware of file moves. It provides a fuse view of the tags with the ability to change tags by moving files (like in the git annex metadata view).
+
+Paul Ruane is particularly responsive on the mailing list and he already supports git annexed files (with SHAE-256 fingerprint) (see the end of the thread https://groups.google.com/forum/#!topic/tmsu/A5EGpnCcJ2w).
+
+Even if you cannot reuse the project, they are interresting ideas that might be worth looking at like the implications of tags: a file tagged \"film\" being automatically tagged \"video\".
+
+Tagsistant (http://www.tagsistant.net/) may also be a good source of inspirations. I just don't like the fact that it uses a backstore of tagged files.
+
+Thanks for reading.
+"""]]
diff --git a/doc/design/metadata/comment_2_03ae28acedbe1fa45c366b30b58fcf48._comment b/doc/design/metadata/comment_2_03ae28acedbe1fa45c366b30b58fcf48._comment
new file mode 100644
index 0000000000..c222f75d36
--- /dev/null
+++ b/doc/design/metadata/comment_2_03ae28acedbe1fa45c366b30b58fcf48._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2014-02-25T09:51:17Z"
+ content="""
+Some additional ideas for metadata...
+
+Instead of having a simplistic scheme like 'field=value' it might be advantageous to consider a scheme like 'attribute=XXX, value=YYY, unit=ZZZ' that way you could do intesting things with the metadata like adding counters to things, and allow for doing interesting queries like give me all 'things' tagged with a unit of \"audio_file\", this assumes one had trawled through an entire annex and then tagged all files based on type with the unix file tool or something like that.
+
+The above idea is already in use in irods and its a really nice and powerful way to let users add meta-data and to build up more interesting use cases and tools.
+
+btw, I plan on taking a look at seeing if I can map some of the meta that we have in work into this new git-annex feature to see how well/bad it works. Either way this feature looks cool! +1!!!
+"""]]
diff --git a/doc/design/metadata/comment_3_ee850df7d3fa4c56194f13a6e3890a30._comment b/doc/design/metadata/comment_3_ee850df7d3fa4c56194f13a6e3890a30._comment
new file mode 100644
index 0000000000..f77cd86115
--- /dev/null
+++ b/doc/design/metadata/comment_3_ee850df7d3fa4c56194f13a6e3890a30._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 3"
+ date="2014-02-25T09:57:09Z"
+ content="""
+actually in your mp3 example you could have ....
+
+ATTRIBUTE=sample_rate, VALUE=22100, UNIT=Hertz
+
+another example use case is to always be consistent with the AVU order then you could stick in ntriples from RDF to do other cool things by looking up various linked data sources -- see http://www.w3.org/2001/sw/RDFCore/ntriples/ and http://www.freebase.com/, actually this would be quite cool if git-annex examined the mp3's id3 tag, the created an ntriple styled entry can be automatically parsed with the web-based annex gui and automatically pull in additional meta-data from the likes of freebase. I guess the list of ideas can just only get bigger with this potential metadata capability.
+"""]]
diff --git a/doc/design/metadata/comment_4_c32ade1524487e5fdc6f83b2db39f04c._comment b/doc/design/metadata/comment_4_c32ade1524487e5fdc6f83b2db39f04c._comment
new file mode 100644
index 0000000000..01f917ef59
--- /dev/null
+++ b/doc/design/metadata/comment_4_c32ade1524487e5fdc6f83b2db39f04c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="bremner"
+ ip="198.164.160.48"
+ subject="convenient way to query metadata?"
+ date="2014-03-15T20:58:28Z"
+ content="""
+I'd like to be able to do something like \"git annex metadata -q fieldname\" and have that output the value(s) of fieldname.  I see I could parse the json output but that isn't too convenient in a shell script. Or have I missed something that already exists?
+"""]]
diff --git a/doc/design/metadata/comment_5_0ac3132cd7a84f0e170fbe3a6f235fe7._comment b/doc/design/metadata/comment_5_0ac3132cd7a84f0e170fbe3a6f235fe7._comment
new file mode 100644
index 0000000000..ca98f7f415
--- /dev/null
+++ b/doc/design/metadata/comment_5_0ac3132cd7a84f0e170fbe3a6f235fe7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.154"
+ subject="comment 5"
+ date="2014-03-15T21:30:52Z"
+ content="""
+@bremner, you must be up to something interesting.. Added metadata --get for you.
+"""]]
diff --git a/doc/design/metadata/comment_6_fa51ae544b193122334dbae7960ab3d9._comment b/doc/design/metadata/comment_6_fa51ae544b193122334dbae7960ab3d9._comment
new file mode 100644
index 0000000000..7be49a6a92
--- /dev/null
+++ b/doc/design/metadata/comment_6_fa51ae544b193122334dbae7960ab3d9._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="tdussa"
+ ip="217.84.74.69"
+ subject="Why not automatically add the whole date?"
+ date="2014-04-30T20:41:20Z"
+ content="""
+Hi,
+
+apologies if I am missing something, but from what I understand, git-annex will automatically add the year and the month from a file's mtime to its metadata if instructed to do so.
+
+So... What about the day (or the time, for that matter?)?  What is the reasoning behind the decision not to add those bits automatically?  And, is there a way to get git-annex to add those bits of information automatically as well (besides the obvious way of creating a pre-commit-hook script to that effect)?
+
+THX & Cheers,
+Toby.
+"""]]
diff --git a/doc/design/metadata/comment_7_04cd255a516c8520a7bc1a8fad253533._comment b/doc/design/metadata/comment_7_04cd255a516c8520a7bc1a8fad253533._comment
new file mode 100644
index 0000000000..12e5042fb9
--- /dev/null
+++ b/doc/design/metadata/comment_7_04cd255a516c8520a7bc1a8fad253533._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlM_DRhi_5pJrTA0HbApHR25iAgy-NBXTY"
+ nickname="Tor Arne"
+ subject="comment 7"
+ date="2014-10-01T22:43:40Z"
+ content="""
+I have the same question as Toby, is there a particular reason the whole timestamp is not stored?
+"""]]
diff --git a/doc/design/metadata/comment_8_0a7e55e7626f72f63966fa1e1d2cf100._comment b/doc/design/metadata/comment_8_0a7e55e7626f72f63966fa1e1d2cf100._comment
new file mode 100644
index 0000000000..965b1932e5
--- /dev/null
+++ b/doc/design/metadata/comment_8_0a7e55e7626f72f63966fa1e1d2cf100._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlM_DRhi_5pJrTA0HbApHR25iAgy-NBXTY"
+ nickname="Tor Arne"
+ subject="Can tags/metadata be used for preferred content?"
+ date="2014-10-01T22:45:36Z"
+ content="""
+Would love to be able to \"tag\" something as archived instead of moving it into a special folder. Coupled with a FinderSync extension on OS X Yosemite for right-click menu. This would allow me to also \"view\" the archive and bring things out of there by \"untagging\" it, if I understand the feature correctly?
+"""]]
diff --git a/doc/design/metadata/comment_9_f0bb62c885a925e0da5ae8ce3c5e9003._comment b/doc/design/metadata/comment_9_f0bb62c885a925e0da5ae8ce3c5e9003._comment
new file mode 100644
index 0000000000..fac3bf135a
--- /dev/null
+++ b/doc/design/metadata/comment_9_f0bb62c885a925e0da5ae8ce3c5e9003._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlM_DRhi_5pJrTA0HbApHR25iAgy-NBXTY"
+ nickname="Tor Arne"
+ subject="comment 9"
+ date="2014-10-01T23:35:39Z"
+ content="""
+Sorry for the noise, I see that tags _can_ be used for preferred content, excellent!
+
+But it seems metadata is tied to a key, not to a specific file/path. If I have 10 different files all with the same content (for some reason, say a simple txt file, Gemspec, or something), and I want to tag one of them as important, it doesn't mean they all are :o
+"""]]
diff --git a/doc/design/new_repo_versions.mdwn b/doc/design/new_repo_versions.mdwn
new file mode 100644
index 0000000000..73210cac78
--- /dev/null
+++ b/doc/design/new_repo_versions.mdwn
@@ -0,0 +1,230 @@
+This page's purpose is to collect and explore plans for a future
+annex.version.
+
+There are two major possible changes that could go in a new repo
+version that would require a hard migration of git-annex repositories:
+
+1. Changing .git/annex/objects/ paths, as appear in the git-annex symlinks.
+
+2. Changing the layout of the git-annex branch in a substantial way.
+
+## object path changes
+
+Any change in this area requires the user make changes to their master
+branch, any other active branches. Old un-converted tags and other
+historical trees in git would also be broken. This is a pretty bad user
+experience. (And it bloats history with a commit that rewrites everything
+too.
+
+For this reason, any changes in this area have been avoided, going all the
+way back to v2 (2011). 
+
+> git-annex had approximately 3 users at the
+> time of that migration, and as one of them, I can say it was a total PITA.
+--[[Joey]] 
+
+So, there would need to be significant payoffs to justify this change.
+
+Note that changing the hash directories might also change where objects are
+stored in special remotes. Because repos can be offline or expensive to
+migrate (or both -- Glacier!) any such changes need to keep looking in the
+old locations for backwards compatability.
+
+Possible reasons to make changes:
+
+* It's annoyingly inconsistent that git-annex uses a different hash
+  directory layout for non-bare repository (on a non-crippled filesystem)
+  than is used for bare repositories and some special remotes.
+
+  Users occasionally stumble over this difference when messing with
+  internals. The code is somewhat complicated by it. In some cases,
+  git-annex checks both locations (eg, a bare repo defaults to xxx/yyy
+  but really old ones might use xX/yY for some keys).
+
+  The mixed case hash directories have caused trouble on case-insensitive
+  filesystems, although that has mostly been papered over to avoid
+  problems. One remaining problem users can stumble on occurs
+  when [[moving a repository from OSX to Linux|bugs/OSX_case_insensitive_filesystem]].
+
+* The hash directories, and also the per-key directories
+  can slow down using a repository on a disk (both SSD and spinning).
+  
+  <https://github.com/datalad/datalad/issues/32>
+
+  Initial benchmarks suggest that going from xX/yY/KEY/OBJ to xX/yY/OBJ
+  directories would improve speed 3x.
+
+  Presumably, removing the yY would also speed it up, unless there are too
+  many objects and the filesystem gets slow w/o the hash directories.
+
+* Removing a directory level would also reduce disk usage, see [[forum/scalability_with_lots_of_files/]] for more info.
+
+## git-annex branch changes
+
+This might involve, eg, rethinking the xxx/yyy/ hash directories used
+in the git-annex branch.
+
+Would this require a hard version transition? It might be possible to avoid
+one, but then git-annex would have to look in both the old and the new
+place. And if a un-transitioned repo was merged into a transitioned one,
+git-annex would have to look in *both* places, and union merge the two sets
+of data on the fly. This doubles the git-cat-file overhead of every
+operation involving the git-annex branch. So a hard transition would
+probably be best.
+
+Also, note that w/o a hard transition, there's the risk that a old
+git-annex version gets ahold of a git-annex branch created by a new
+git-annex version, and sees only half of the story (the un-transitioned
+files). This could be a very confusing failure mode. It doesn't help that
+the git-annex branch does not currently have any kind of
+version number embedded in it, so the old version of git-annex doesn't even
+have a way to check if it can handle the branch.
+
+Possible reasons to make changes:
+
+* There is a discussion of some possible changes to the hash directories here
+  <https://github.com/datalad/datalad/issues/17#issuecomment-68558319> with a
+  goal of reducing the overhead of the git-annex branch in the overall size
+  of the git-annex repository. 
+  
+  Removing the second-level hash directories might improve performance.
+  It doesn't save much space when a repository is having incremental changes
+  made to it. However, if millions of annexed objects are being added
+  in a single commit, removing the second-level hash directories does save
+  space; it halves the number of tree
+  objects[1](https://github.com/datalad/datalad/issues/17#issuecomment-68759754).
+
+  Also,
+  <https://github.com/datalad/datalad/issues/17#issuecomment-68569727>
+  suggests using xxx/yyy.log, where one log contains information for
+  multiple keys. This would probably improve performance too due to
+  caching, although in some cases git-annex would have to process extra
+  information to get to the info about the key it wants, which hurts
+  performance. The disk usage change of this method has not yet been
+  quantified.
+
+* While not a sufficient reason on its own, the best practices for file
+  formats in the git-annex branch has evolved over time, and there are some
+  files that have unusual formats for historical reasons. Other files have
+  modern formats, but their parsers have to cope with old versions that
+  have other formats. A hard transition would provide an opportunity to
+  clean up a lot of that.
+
+## living on the edge
+
+Rather than a hard transition, git-annex could add a mode
+that could be optionally enabled when initing a repo for the first time.
+
+Users who know they need that mode could then turn it one, and get the
+benefits, while everyone else avoids a transition that doesn't benefit them
+much.
+
+There could even be multiple modes, with different tradeoffs depending on
+how the repo will be used, its size, etc. Of course that adds complexity.
+
+But the main problem with this idea is, how to avoid the foot shooting
+result of merging repo A(v5) into repo B(vNG)? This seems like it would be
+all to easy for a user to do. 
+
+As far as git-annex branch changes go, it might be possible for git-annex
+to paper over the problem by handling both versions in the merged git-annex
+branch, as discussed earlier. But for .git/annex/objects/ changes, there
+does not seem to be a reasonable thing for git-annex to do. When it's
+receiving an object into a mixed v5 and vNG repo, it can't know which
+location that repo expects the object file to be located in. Different
+files in the repo might point to the same object in different locations!
+Total mess. Must avoid this.
+
+Currently, annex.version is a per-local-repo setting. git-annex can't tell 
+if two repos that it's merging have different annex.version's. 
+
+It would be possible to add a git-annex:version file, which would work for
+git-annex branch merging. Ie, `git-annex merge` could detect if different
+git-annex branches have different versions, and refuse to merge them (or
+upgrade the old one before merging it).
+
+Also, that file could be used by git-annex, to automatically set
+annex.version when auto-initing a clone of a repo that was initted with
+a newer than default version.
+
+But git-anex:version won't prevent merging B/master into A's master.
+That merge can be done by git; nothing in git-annex can prevent it.
+
+What we could do is have a .annex-version flag file in the root of the
+repo. Then git merge would at least have a merge conflict. Note that this
+means inflicting the file on all git-annex repos, even ones used by people
+with no intention of living on the edge. And, it would take quite a while
+until all such repos get updated to contain such a file.
+
+Or, we could just document that if you initialize a repo with experimental
+annex.version, you're living on the edge and you can screw up your repo
+by merging with a repo from an old version.
+
+git-annex fsck could also fix up any broken links that do result from the
+inevitable cases where users ignore the docs.
+
+## version numbers vs configuration
+
+A particular annex.version like 5 encompasses a number of somewhat distinct
+things
+
+* git-annex branch layout
+* .git/annex/objects/ layout
+* other git stuff (like eg, the name of the HEAD branch in direct mode)
+
+If the user is specifying at `git annex init` time some nonstandard things
+they want to make the default meet their use case better, that is more
+a matter of configuration than of picking a version. 
+
+For example, we could say that the user is opting out of the second-level
+object hash directories. Or we could say the user is choosing to use vNG,
+which is like  v5 except with different object hash directory structure.
+
+	git annex init --config annex.objects.hashdirectories 1 
+		--config annex.objects.hashlower true
+	git annex init --version 6
+
+The former would be more flexible. The latter is simpler. 
+
+The former also lets the user chose *no* hash directories, or 
+choose 2 levels of hash directories while using the (v5 default) mixed
+case hashing.
+
+## concrete design
+
+Make git-annex:difference.log be used by newer git-annex versions than v5,
+and by nonstandard configurations.
+
+The file contents will be "timestamp uuid [value, ..]", where value is a
+serialized data type that describes divergence from v5 (since v5 and older
+don't have the git-annex:difference.log file).
+
+So, for example, "[Version 6]" could indicate that v6 is being used. Or,
+"[ObjectHashLower True, ObjectHashDirectories 1, BranchHashDirectories 1]"
+indicate a nonstandard configuration on top of v5 (this might turn out to
+be identical to v6; just make the compare equal and no problem).
+
+git-annex merge would check if it's merging in a git-annex:difference.log from
+another repo that doesn't match the git-annex:difference.log of the local repo,
+and abort. git-annex sync (and the assistant) would check the same, but
+before merging master branches either, to avoid a bad merge there.
+
+The git-annex:difference.log of a local repo could be changed by an upgrade
+or some sort of transition. When this happens, the new value is written
+for the uuid of the local repo. git-annex merge would then refuse to merge
+with remote repos until they were also transitioned.
+
+(There's perhaps some overlap here with the existing
+git-annex:transitions.log, however the current transitions involve
+forgetting history/dead remotes and so can be done repeatedly on a
+repository. Also, the current transitions can be performed on remote
+branches before merging them in; that wouldn't work well for version
+changes since those require other changes in the remote repo.)
+
+Not covered:
+
+* git-merge of other branches, such as master (can be fixed by `git annex
+  fix` or `fsck`)
+* Old versions of git-annex will ignore the version file of course,
+  and so merging such repos using them can result in pain.
+
diff --git a/doc/design/new_repo_versions/comment_1_b7b4819211910556838ec37bc2b6b37b._comment b/doc/design/new_repo_versions/comment_1_b7b4819211910556838ec37bc2b6b37b._comment
new file mode 100644
index 0000000000..9077eada90
--- /dev/null
+++ b/doc/design/new_repo_versions/comment_1_b7b4819211910556838ec37bc2b6b37b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2015-01-22T01:05:56Z"
+ content="""
+My gut feeling for incompatible changes in v6 is to somehow make v5 and below error out on all merges with a v6 repo.
+
+Conversely, v6 git-annex running in v6 repos would transition all data while merging in v5 repos.
+
+As a migration path for existing repos, you could move `git-annex` and `master` to `git-annex_v5` and `master_v5`. Once you are certain all known repos within that repo group are transitioned, either kill the v5 branches automagically or print info on cli/web UI on what needs to be run to get rid of them.
+
+Having several plain git 1+ GiB repos (i.e. without any annex objects), I would love to transition after v6 and the migration paths have been hung a month or three to dry.
+"""]]
diff --git a/doc/design/new_repo_versions/comment_2_8f35254d2cd5d0c273d5392ddd857c2d._comment b/doc/design/new_repo_versions/comment_2_8f35254d2cd5d0c273d5392ddd857c2d._comment
new file mode 100644
index 0000000000..ef050ac937
--- /dev/null
+++ b/doc/design/new_repo_versions/comment_2_8f35254d2cd5d0c273d5392ddd857c2d._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="comment 2"
+ date="2015-01-26T19:46:12Z"
+ content="""
+\"... merging repo A(v5) into repo B(v6)? This seems like it would be all to easy for a user to do.\"
+
+it would be easy if two separate repos are inited separately of different versions and then merged.  But how frequent could such situation arise?  I  don't think that it is not that common actually in non git-annex assistant initialized  repositories, especially if \"v6\" (or some other custom) layout would be non-default.
+
+This also somewhat reflects upon \"When it's receiving an object into a mixed v5 and v6 repo, it can't know which location that repo expects the object file to be located in.\" -- how plausible/frequent would be to see a mixed v5/6 repo?
+
+\".annex-version flag file\" -- I think it is a good idea.  (may be even better an .annex/version directory/file to reserve for possibly future other branch-specific, thus not for git-annex branch additions).  Indeed it would take time for repos to acquire it, but imho it is ok, if added automagically by new git-annex versions.  Also it is a tiny price to pay for users who do not really care about \"living on the edge\".    But it also might better be coupled with having git-annex:version (i.e. version file under git-annex branch) describing layout of the git-annex branch since those two are somewhat independent, right?
+
+Also a wild idea to mitigate inconvenience for users happen they migrate repositories from old to new formats: to provide 'git annex compat-layout  [version]' command which, for files with content, would  generate symlinks to files in new format to locations in old, with some command to clean them up  later on (e.g. 'git annex compat-layout --cleanup'). Although inefficient per-se it could be a big convenience since would eliminate need to \"migrate/rewrite\" entire history, while still making it possible to get access to previous versions.  With a handling in hooks could be automated to even hide that from users entirely.  or is there a big culprit I don't see?
+
+
+\"version numbers vs configuration\"
+
+having flexibility of configurations, possibly with versions simply providing enumerations to some of them, might be a great feature to have in the long run.  Not sure though if it would not blow up complexity :-/
+
+Overall -- if complete transition to improved/unified v6 is too big of undertaker, allowing for custom non-default configurations while sticking to v5 as the default one and forbidding merges between different versions, could be sufficient to scale up for atypical large uses.  If everyone to migrate to v6 -- more optimal layout should be well thought through to be worthwhile undertaking.
+
+"""]]
diff --git a/doc/design/p2p_protocol.mdwn b/doc/design/p2p_protocol.mdwn
new file mode 100644
index 0000000000..cac4507630
--- /dev/null
+++ b/doc/design/p2p_protocol.mdwn
@@ -0,0 +1,212 @@
+The git-annex P2P protocol is a custom protocol that git-annex uses to
+communicate between peers.
+
+There's a common line-based serialization of the protocol, but other
+serializations are also possible. The line-based serialization is spoken
+by [[git-annex-shell], and by git-annex over tor.
+
+One peer is known as the client, and is the peer that initiates the
+connection and sends commands. The other peer is known as the server, and
+is the peer that the client connects to. It's possible for two connections
+to be run at the same time between the same two peers, in different
+directions.
+
+## Errors
+
+Either the client or the server may send an error message at any
+time. 
+
+When the client sends an ERROR, the server will close the connection.
+
+If the server sends an ERROR in response to the client's
+request, the connection will remain open, and the client can make
+another request.
+
+	ERROR this repository is read-only; write access denied
+
+## Authentication
+
+The protocol generally starts with authentication. However, if
+authentication already occurs on another layer, as is the case with
+git-annex-shell, authentication will be skipped.
+
+The client starts by sending an authentication command to the server,
+along with its UUID. The AuthToken is some arbitrary token that has been
+agreed upon beforehand.
+
+	AUTH UUID AuthToken
+
+The server responds with either its own UUID when authentication
+is successful. Or, it can fail the authentication, and close the
+connection.
+
+	AUTH_SUCCESS UUID
+	AUTH_FAILURE
+
+Note that authentication does not guarantee that the client is talking to
+who they expect to be talking to. This, and encryption of the connection,
+are handled at a lower level.
+
+## Protocol version
+
+The default protocol version is 0. The client can choose to
+negotiate a new version with the server. This must come after
+any authentication.
+
+The client sends the highest protocol version it supports:
+
+	VERSION 2
+
+The server responds with the highest protocol version it supports
+that is less than or equal to the version the client sent:
+
+	VERSION 1
+
+Now both client and server should use version 1.
+
+## Binary data
+
+The protocol allows raw binary data to be sent. This is done
+using a DATA message. In the line-based serialization, this comes
+on its own line, followed by a newline and the binary data.
+The Len value tells how many bytes of data to read.
+
+	DATA 3
+	foo1
+
+Note that there is no newline after the binary data; the next protocol
+message will come immediately after it.
+
+If the sender finds itself unable to send as many bytes of data as it
+promised (perhaps because a file got truncated while it was being sent),
+its only option is to close the protocol connection.
+
+And if the receiver finds itself unable to receive all the data for some
+reason (eg, out of disk space), its only option is to close the protocol
+connection.
+
+## Checking if content is present
+
+To check if a key is currently present on the server, the client sends:
+
+	CHECKPRESENT Key
+
+The server responds with either SUCCESS or FAILURE.
+
+## Locking content
+
+To lock content on the server, preventing it from being removed,
+the client sends:
+
+	LOCKCONTENT Key
+
+The server responds with either SUCCESS or FAILURE.
+The former indicates the content is locked. It will remain
+locked until the connection is broken, or the client
+sends:
+
+	UNLOCKCONTENT Key
+
+The server makes no response to that.
+
+## Removing content
+
+To remove a key's content from the server, the client sends:
+
+	REMOVE Key
+
+The server responds with either SUCCESS or FAILURE.
+
+## Storing content on the server
+
+To store content on the server, the client sends:
+
+	PUT AssociatedFile Key
+
+Here AssociatedFile may be the name of a file in the git
+repository, for information purposes only. Or it can be the
+empty string. It will always have unix directory separators.
+
+(Note that in the line-based serialization. AssociatedFile may not contain any
+spaces, since it's not the last token in the line. Use '%' to indicate
+whitespace.)
+
+The server may respond with ALREADY-HAVE if it already
+had the conent of that key. Otherwise, it responds with:
+
+	PUT-FROM Offset
+
+Offset is the number of bytes into the file that the server wants
+the client to start. This allows resuming transfers.
+
+The client then sends a DATA message with content of the file from
+the offset to the end of file.
+
+In protocol version 1, after the data, the client sends an additional
+message, to indicate if the content of the file has changed while it
+was being sent.
+
+	INVALID
+	VALID
+
+If the server successfully receives the data and stores the content,
+it replies with SUCCESS. Otherwise, FAILURE.
+
+## Getting content from the server
+
+To get content from the server, the client sends:
+
+	GET Offset AssociatedFile Key
+
+The Offset is the number of bytes into the file that the client wants
+the server to skip, which allows resuming transfers.
+See description of AssociatedFile above.
+
+The server then sends a DATA message with the content of the file
+from the offset to end of file.
+
+In protocol version 1, after the data, the server sends an additional
+message, to indicate if the content of the file has changed while it
+was being sent.
+
+	INVALID
+	VALID
+
+The client replies with SUCCESS or FAILURE.
+
+## Connection to services
+
+This is used to connect to services like git-upload-pack and
+git-receive-pack that speak their own protocol.
+
+The client sends a message to request the connection.
+Service is the name of the service, eg "git-upload-pack".
+
+	CONNECT Service
+
+Both client and server may now exchange DATA messages in any order,
+encapsulating the service's protocol.
+
+When the service exits, the server indicates this by telling the client
+its exit code.
+
+	CONNECTDONE ExitCode
+
+## Change notification
+
+The client can request to be notified when a ref in 
+the git repository on the server changes.
+
+	NOTIFYCHANGE
+
+The server will block until at least
+one of the refs changes, and send a list of changed
+refs.
+
+	CHANGED ChangedRefs
+
+For example:
+
+	CHANGED refs/heads/master refs/heads/git-annex
+
+Some servers may not support this command.
diff --git a/doc/design/p2p_protocol/comment_1_367bebae5b84408c7592b5fcca993c1e._comment b/doc/design/p2p_protocol/comment_1_367bebae5b84408c7592b5fcca993c1e._comment
new file mode 100644
index 0000000000..cb34fb951a
--- /dev/null
+++ b/doc/design/p2p_protocol/comment_1_367bebae5b84408c7592b5fcca993c1e._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="late to the party"
+ date="2018-03-12T13:50:33Z"
+ content="""
+eh... i look elsewhere for a week and you design another line
+protocol! ;) so I guess it's too late to do anything to change this,
+but I wanted to share that similar efforts are being done over the
+backup software world, in particular in [restic][],
+which is working with the [rclone][] project to implement an abstract
+get/pull mechanism to store blobs, a lot like what git-annex needs to
+be doing.
+
+they wrote this using a binary protocol for speed (it's basically RPC
+at this point) and I encouraged them to at least use a standard one
+(they use protobufs + HTTP2 AKA gRPC, iirc, and it works over
+stdin/out). you might find the  [full thread][] interesting... it
+would be great if git-annex would support this natively instead of
+rolling its own protocol, because it would mean it could talk with
+other services like rclone or restic servers out of the box, without
+*those* endpoints having to implement yet another custom protocol.
+
+but yeah, i'm way too late it seems. figured you might find it
+interesting anyways... congrats on the performance improvements!
+
+[restic]: https://restic.net
+[rclone]: https://rclone.org/
+[full thread]: https://github.com/restic/restic/issues/1561
+"""]]
diff --git a/doc/design/p2p_protocol/comment_2_dbd118a01c31d17a4223a32a7baa8e39._comment b/doc/design/p2p_protocol/comment_2_dbd118a01c31d17a4223a32a7baa8e39._comment
new file mode 100644
index 0000000000..4eeee45a25
--- /dev/null
+++ b/doc/design/p2p_protocol/comment_2_dbd118a01c31d17a4223a32a7baa8e39._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-03-12T21:59:26Z"
+ content="""
+This is not a new protocol, it was added 2 years ago for
+git-annex's tor hidden service support.
+
+git-annex already supports rclone via a special remote.
+
+This protocol is only used when there's a git-annex repository
+on the other end, so I don't see any benefit in making it compatible with
+any other programs. And it has stuff in it that I'm sure if not in the
+protocol you talked about, like LOCKCONTENT.
+"""]]
diff --git a/doc/design/p2p_protocol/comment_4_94fff4c163de15cdad2030ac072b19ae._comment b/doc/design/p2p_protocol/comment_4_94fff4c163de15cdad2030ac072b19ae._comment
new file mode 100644
index 0000000000..7b59e143c8
--- /dev/null
+++ b/doc/design/p2p_protocol/comment_4_94fff4c163de15cdad2030ac072b19ae._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="re: key content size"
+ date="2019-04-01T17:44:29Z"
+ content="""
+Most keys do include the size of the content as part of the key: see [[internals/key_format]], [[git-annex-examinekey]].
+"""]]
diff --git a/doc/design/p2p_protocol/comment_4_f48e73ea2b6f70597837d09d3c5d3849._comment b/doc/design/p2p_protocol/comment_4_f48e73ea2b6f70597837d09d3c5d3849._comment
new file mode 100644
index 0000000000..9b89b8771e
--- /dev/null
+++ b/doc/design/p2p_protocol/comment_4_f48e73ea2b6f70597837d09d3c5d3849._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="driusan@4d47e7deeb2f5d3846792d049ed06f96a0c3ca98"
+ nickname="driusan"
+ avatar="http://cdn.libravatar.org/avatar/409b69c3ae7b431fc16129ccdadae9cd"
+ subject="key content size"
+ date="2019-03-31T16:31:28Z"
+ content="""
+Is there a mechanism for a client to determine the size of the content pointed to by the key on the remote? How do you determine that all the content is received? If you rely on verifying sha256 (or whatever hash) of the key, I don't see any way you can tell if the object in a local annex is corrupted or just not fully received and should be updated with GET from a higher offset.
+"""]]
diff --git a/doc/design/p2p_protocol/comment_5_08b190ff1c6d1e890311edf7cc7bfcd4._comment b/doc/design/p2p_protocol/comment_5_08b190ff1c6d1e890311edf7cc7bfcd4._comment
new file mode 100644
index 0000000000..75b25ba49f
--- /dev/null
+++ b/doc/design/p2p_protocol/comment_5_08b190ff1c6d1e890311edf7cc7bfcd4._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-04-03T17:03:04Z"
+ content="""
+While it's true that most keys have a size field giving their size, in the
+context of this protocol, it's more relevant that the DATA message
+indicates the number of bytes of content that are going to be transmitted;
+once the receiver has sucessfully read that many bytes of content, it knows
+it has the whole content of the key.
+
+When resuming a previous transfer that has been interrupted, if the
+reciever happened to have all the content of the key, it would send GET
+with the number of bytes it already has, and the reply would be "DATA 0"
+which tells it that it already has all the content.
+
+If the whole content of the key has been received and a hash verification
+fails, git-annex throws away the corrupt data, since this protocol does not
+provide a way to recover from such a problem.
+"""]]
diff --git a/doc/design/passthrough_proxy.mdwn b/doc/design/passthrough_proxy.mdwn
new file mode 100644
index 0000000000..91830f41ce
--- /dev/null
+++ b/doc/design/passthrough_proxy.mdwn
@@ -0,0 +1,127 @@
+When [[balanced_preferred_content]] is used, there may be many repositories
+in a location -- either a server or a cluster -- and getting any given file
+may need to access any of them. Configuring remotes for each repository
+adds a lot of complexity, both in setting up access controls on each
+server, and for the user. 
+
+Particularly on the user side, when ssh is used they may have to deal with
+many different ssh host keys, as well as adding new remotes or removing
+existing remotes to keep up with changes are made on the server side.
+
+A proxy would avoid this complexity. It also allows limiting network
+ingress to a single point.
+
+Ideally a proxy would look like any other git-annex remote. All the files
+stored anywhere in the cluster would be available to retrieve from the
+proxy. When a file is sent to the proxy, it would store it somewhere in the
+cluster.
+
+Currently the closest git-annex can get to implementing such a proxy is a
+transfer repository that wants all content that is not yet stored in the
+cluster. This allows incoming transfers to be accepted and distributed to
+nodes of the cluster. To get data back out of the cluster, there has to be
+some communication that it is preferred content (eg, setting metadata),
+then after some delay for it to be copied back to the transfer repository,
+it becomes available for the client to download it. And once it knows the
+client has its copy, it can be removed from the transfer repository.
+
+That is quite slow, and rather clumsy. And it risks the transfer repository
+filling up with data that has been requested by clients that have not yet
+picked it up, or with incoming transfers that have not yet reached the
+cluster.
+
+A proxy would not hold the content of files itself. It would be a clone of
+the git repository though, probably. Uploads and downloads would stream
+through the proxy. The git-annex [[P2P_protocol]] could be relayed in this way. 
+
+## UUID discovery
+
+A significant difficulty in implementing a proxy is that each git-annex
+remote has a single UUID. But the remote that points at the proxy can't
+just have the UUID of the proxy's repository, git-annex needs to know that
+the proxy's remote can be used to access repositories with every UUID in
+the cluster.
+
+### UUID discovery via P2P protocol extension
+
+Could the P2P protocol be extended to let the proxy communicate the UUIDs
+of all the repositories behind it?
+
+Once the client git-annex knows the set of UUIDs behind the proxy, it can
+instantiate a remote object per uuid, each of which accesses the proxy, but
+with a different UUID.
+
+But, git-annx usually only does UUID discovery the first time a ssh remote
+is accessed. So it would need to discover at that point that the remote is
+a proxy. Then it could do UUID discovery each time git-annex starts up.
+But that adds significant overhead, git-annex would be making a connection
+to the proxy in situations where it is not going to use it.
+
+### UUID discovery via git-annex branch
+
+Could the proxy's set of UUIDs instead be recorded somewhere in the
+git-annex branch?
+
+With this approach, git-annex would know as soon as it sees the proxy's
+UUID that this is a proxy for this other set of UUIDS. (Unless its
+git-annex branch is not up-to-date.) And then it can instantiate a UUID for
+each remote.
+
+One difficulty with this is that, when the git-annex branch is not up to
+date with changes from the proxy, git-annex may try to access repositories
+that are no longer available behind the proxy. That failure would be
+handled the same as any other currently unavailable repository. Also
+git-annex would not use the full set of repositories, so might not be able
+to store data when eg, all the repositories that is knows about are full.
+Just getting the git-annex back in sync should recover from either
+situation.
+
+## streaming to special remotes
+
+As well as being an intermediary to git-annex repositories, the proxy could
+provide access to other special remotes. That could be an object store like
+S3, which might be internal to the cluster or not. When using a cloud
+service like S3, only the proxy needs to know the access credentials.
+
+Currently git-annex does not support streaming content to special remotes.
+The remote interface operates on object files stored on disk. See
+[[todo/transitive_transfers]] for discussion of that problem. If proxies
+get implemented, that problem should be revisited.
+
+## speed
+
+A passthrough proxy should be as fast as possible so as not to add overhead
+to a file retrieve, store, or checkpresent. This probably means that
+it keeps TCP connections open to each host in the cluster. It might use a
+protocol with less overhead than ssh.
+
+In the case of checkpresent, it would be possible for the proxy to not
+communicate with the cluster to check that the data is still present on it.
+As long as all access is intermediated via the proxy, its git-annex branch
+could be relied on to always be correct, in theory. Proving that theory,
+making sure to account for all possible race conditions and other scenarios,
+would be necessary for such an optimisation.
+
+Another way the proxy could speed things up is to cache some subset of
+content. Eg, analize what files are typically requested, and store another
+copy of those on the proxy. Perhaps prioritize storing smaller files, where
+latency tends to swamp transfer speed.
+
+## encryption
+
+When the proxy is in front of a special remote that uses encryption, where
+does the encryption happen? It could either happen on the client before
+sending to the proxy, or the proxy could do the encryption since it
+communicates with the special remote. For security, doing the encryption on
+the client seems like the best choice by far.
+
+But, git-annex's git remotes don't currently ever do encryption. And
+special remotes don't communicate via the P2P protocol with a git remote.
+So none of git-annex's existing remote implementations would be able to handle
+this case. Something will need to be changed in the remote
+implementation for this.
+
+(Chunking has the same problem.)
+
+There's potentially a layering problem here, because exactly how encryption
+(or chunking) works can vary depending on the type of special remote.
diff --git a/doc/design/preferred_content.mdwn b/doc/design/preferred_content.mdwn
new file mode 100644
index 0000000000..3972b8b583
--- /dev/null
+++ b/doc/design/preferred_content.mdwn
@@ -0,0 +1,21 @@
+The [[preferred_content]] expressions didn't have a design document, but
+it's a small non-turing complete DSL for expressing which objects a
+repository prefers to contain.
+
+One thing that needs to be written down though is the stability analysis
+that must be done of preferred content expressions. 
+
+It's important that when a set of repositories all look at one-another's
+preferred content expressions, and copy/move/drop objects to satisfy them,
+they end up at a steady state. So, a given preferred content expression
+should ideally evaluate to the same answer for each key, from the
+perspective of each repository.
+
+The best way to ensure that is the case is to only use terms in preferred
+content expressions that rely on state that is shared between all
+repositories. So, state in the git-annex branch, or the master branch
+(assuming all repositories have master checked out).
+
+Since git is eventually consistent, there might be disagreements about
+which object belongs where, but once consistency is reached, things will
+settle down.
diff --git a/doc/design/requests_routing.mdwn b/doc/design/requests_routing.mdwn
new file mode 100644
index 0000000000..2391cfae95
--- /dev/null
+++ b/doc/design/requests_routing.mdwn
@@ -0,0 +1,100 @@
+## requesting content
+ 
+In some situations, nodes only want particular files, and not everything.
+(Or don't have the bandwidth to get everything.) A way to handle this,
+that should work in a fully ad-hoc, offline distributed network,
+suggested by Vincenzo Tozzi:
+
+* Nodes generate a request for a specific file they want, committed
+  to git somewhere.
+* This request has a TTL (of eg 3 or 4).
+* When syncing, copy the requests that a node has, and decrease their TTL
+  by 1. Requests with a TTL of 0 have timed out and are not copied.
+  (So, requests are stored in git, but on eg, per-node branches.)
+* Only copy content to nodes that have a request for it (either one
+  originating with them, or one they copied from another node).
+* Each request indicates the requesting node, so once no nodes have an
+  active request for a particular file, it's ok to drop it from the
+  transfer nodes (honoring numcopies etc of course).
+
+## simulation
+
+A simulation of a network using this method is in [[simroutes.hs]].
+
+Question: How efficient is this method? Does the network fill with many
+copies that are not needed, before the request is fulfilled?
+
+## storing requests
+
+Requests could be stored in the location tracking file.
+
+Currently:
+
+	time 0|1 uuid1
+	time 0|1 uuid2
+
+* Use negative numbers for the TTL of a request:
+
+	time -3! uuid1
+	time -2 uuid2
+
+  The `!` indicates that the request originated on
+  that node.
+* To propigate a request, set -1 * (TTL+1) in the line
+  for the uuid of the repository that is propigating it.  
+  This should be done as part of the git-annex branch merge,
+  so if a location tracking file is merged, any open requests
+  get propigated to the current repository automatically.
+* When a requested file reaches a node that requested it,
+  the location is set to 1; this automatically clears the
+  request.
+* When a file has no more originating requests, clear all
+  the copied requests:
+
+	time 1 uuid1
+	time -2 uuid2
+
+  Becomes:
+
+	time 1 uuid1
+	time' 0 uuid2
+
+## generating requests
+
+	git annex request [file...]
+
+Indicates that the file is wanted in the current repository.
+
+(git annex get could also do this on failure, or suggest doing this)
+
+## acting on requests
+
+Add a preferred content expression that looks at request data:
+
+	requestedby=N
+
+Matches files that have been requested by at least N nodes.
+
+	requested
+
+Matches files that the current node has requested.
+
+### Example preferred content expressions
+
+For an immobile node that accumulates files it requests, and also
+temporarily stores files requested by other such nodes:
+
+	present or requestedby=1
+
+For a node that only transfers files between the immobile nodes:
+
+	requestedby=1
+
+For an immobile node that only accumulates files it requests, but never
+stores files requested by other nodes:
+
+	present or requested
+
+TODO: Would be nice to be able to prioritize files that more nodes are
+requesting, or that have some urgent flag set. But currently there is no
+way to do that; content is either preferred or not preferred.
diff --git a/doc/design/requests_routing/comment_1_421b14a4dd9d6c431e00333057df1627._comment b/doc/design/requests_routing/comment_1_421b14a4dd9d6c431e00333057df1627._comment
new file mode 100644
index 0000000000..f2e0a857a2
--- /dev/null
+++ b/doc/design/requests_routing/comment_1_421b14a4dd9d6c431e00333057df1627._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://johan.kiviniemi.name/"
+ nickname="Johan"
+ subject="comment 1"
+ date="2014-05-07T06:27:10Z"
+ content="""
+“Nodes generate a request for a specific file they want”
+
+It would be also convenient to be able to “push” a file to another node you do not have direct access to by creating a request for that file on behalf of the node.
+"""]]
diff --git a/doc/design/requests_routing/comment_2_a409df0566b308bf2b84efd4fb2c8a8f._comment b/doc/design/requests_routing/comment_2_a409df0566b308bf2b84efd4fb2c8a8f._comment
new file mode 100644
index 0000000000..d7bbaed085
--- /dev/null
+++ b/doc/design/requests_routing/comment_2_a409df0566b308bf2b84efd4fb2c8a8f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="design phase only"
+ date="2015-08-18T19:02:30Z"
+ content="""
+just to clarify: this is not implemented yet, as far as i know.
+"""]]
diff --git a/doc/design/requests_routing/comment_3_924e6254bf51a5b19eb7fe635053a16e._comment b/doc/design/requests_routing/comment_3_924e6254bf51a5b19eb7fe635053a16e._comment
new file mode 100644
index 0000000000..a5459823d8
--- /dev/null
+++ b/doc/design/requests_routing/comment_3_924e6254bf51a5b19eb7fe635053a16e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="Friendly bump to keep on the radar"
+ date="2019-10-24T09:26:23Z"
+ content="""
+This would be a great feature to have one day. It would work really well in tandem with get/drop/fsck commands to assist in moving files around a disjointed network.
+
+"""]]
diff --git a/doc/design/requests_routing/simroutes.hs b/doc/design/requests_routing/simroutes.hs
new file mode 100644
index 0000000000..3918160405
--- /dev/null
+++ b/doc/design/requests_routing/simroutes.hs
@@ -0,0 +1,402 @@
+-- Simulation of non-flood syncing of content, across a network of nodes.
+
+module Main where
+
+import System.Random
+import Control.Monad.Random
+import Control.Monad
+import Control.Applicative
+import Data.Ratio
+import Data.Ord
+import Data.List
+import Data.Maybe
+import qualified Data.Set as S
+import qualified Data.Map.Strict as M
+
+{-
+ - Tunable values
+ -}
+
+totalFiles :: Int
+totalFiles = 100
+
+-- How likely is a given file to be wanted by any particular node?
+probabilityFilesWanted :: Probability
+probabilityFilesWanted = 0.10
+
+-- How many different locations can each transfer node move between?
+-- (Min, Max)
+transferDestinationsRange :: (Int, Int)
+transferDestinationsRange = (2, 3)
+
+-- Controls how likely transfer nodes are to move around in a given step
+-- of the simulation.
+-- (They actually move slightly less because they may start to move and
+-- pick the same location they are at.)
+-- (Min, Max)
+transferMoveFrequencyRange :: (Probability, Probability)
+transferMoveFrequencyRange = (0.10, 1.00)
+
+-- counts both immobile and transfer nodes as hops, so double Vince's
+-- theoretical TTL of 3.
+-- (30% loss on mocambos network w/o ttl of 4!)
+maxTTL :: TTL
+maxTTL = TTL (4 * 2)
+
+numImmobileNodes :: Int
+numImmobileNodes = 10
+
+numTransferNodes :: Int
+numTransferNodes = 20
+
+numSteps :: Int
+numSteps = 100
+
+-- IO code
+main :: IO ()
+main = do
+--	initialnetwork <- evalRandIO (seedFiles totalFiles =<< genNetwork)
+	initialnetwork <- evalRandIO (seedFiles totalFiles =<< mocambosNetwork)
+	networks <- evalRandIO (simulate numSteps initialnetwork)
+	let finalnetwork = last networks
+	putStrLn $ summarize initialnetwork finalnetwork
+	putStrLn "location history of file 1:"
+	print $ trace (traceHaveFile (File 1)) networks
+	putStrLn "request history of file 1:"
+	print $ trace (traceWantFile (File 1)) networks
+-- Only pure code below :)
+
+data Network = Network (M.Map NodeName ImmobileNode) [TransferNode]
+	deriving (Show, Eq)
+
+data ImmobileNode = ImmobileNode NodeRepo
+	deriving (Show, Eq)
+
+type NodeName = String
+
+type Route = [NodeName]
+
+data TransferNode = TransferNode
+	{ currentlocation :: NodeName
+	, possiblelocations :: [NodeName]
+	, movefrequency :: Probability
+	, transferrepo :: NodeRepo
+	}
+	deriving (Show, Eq)
+
+data NodeRepo = NodeRepo
+	{ wantFiles :: [Request]
+	, haveFiles :: S.Set File
+	, satisfiedRequests :: S.Set Request
+	}
+	deriving (Show, Eq)
+
+data File = File Int
+	deriving (Show, Eq, Ord)
+
+randomFile :: (RandomGen g) => Rand g File
+randomFile = File <$> getRandomR (0, totalFiles)
+
+data Request = Request File TTL
+	deriving (Show, Ord)
+
+-- compare ignoring TTL
+instance Eq Request where
+	(Request f1 _) == (Request f2 _) = f1 == f2
+
+requestedFile :: Request -> File
+requestedFile (Request f _) = f
+
+requestTTL :: Request -> TTL
+requestTTL (Request _ ttl) = ttl
+
+data TTL = TTL Int
+	deriving (Show, Eq, Ord)
+
+incTTL :: TTL -> TTL
+incTTL (TTL t) = TTL (t + 1)
+
+decTTL :: TTL -> TTL
+decTTL (TTL t) = TTL (t - 1)
+
+staleTTL :: TTL -> Bool
+staleTTL (TTL t) = t < 1
+
+-- Origin of a request starts one higher than max, since the TTL
+-- will decrement the first time the Request is transferred to another node.
+originTTL :: TTL
+originTTL = incTTL maxTTL
+
+randomRequest :: (RandomGen g) => Rand g Request
+randomRequest = Request
+	<$> randomFile
+	<*> pure originTTL
+
+type Probability = Float
+
+randomProbability :: (RandomGen g) => Rand g Probability
+randomProbability = getRandomR (0, 1)
+
+-- Returns the state of the network at each step of the simulation.
+simulate :: (RandomGen g) => Int -> Network -> Rand g [Network]
+simulate n net = go n [net]
+  where
+	go 0 nets = return (reverse nets)
+	go c (prev:nets) = do
+		new <- step prev
+		go (c - 1) (new:prev:nets)
+
+-- Each step of the simulation, check if each TransferNode wants to move,
+-- and if so:
+--   1. It and its current location exchange their Requests.
+--   2. And they exchange any requested files.
+--   3. Move it to a new random location.
+--
+-- Note: This implementation does not exchange requests between two
+-- TransferNodes that both arrive at the same location at the same step,
+-- and then move away in the next step.
+step :: (RandomGen g) => Network -> Rand g Network
+step (Network immobiles transfers) = go immobiles [] transfers
+  where
+	go is c [] = return (Network is c)
+	go is c (t:ts) = do
+		r <- randomProbability
+		if movefrequency t <= r
+			then case M.lookup (currentlocation t) is of
+				Nothing -> go is (c ++ [t]) ts
+				Just currentloc -> do
+					let (currentloc', t') = merge currentloc t
+					t'' <- move t'
+					go (M.insert (currentlocation t) currentloc' is) (c ++ [t'']) ts
+			else go is (c ++ [t]) ts
+
+merge :: ImmobileNode -> TransferNode -> (ImmobileNode, TransferNode)
+merge (ImmobileNode ir) t@(TransferNode { transferrepo = tr }) =
+	( ImmobileNode (go ir tr)
+	, t { transferrepo = go tr ir }
+	)
+  where
+	go r1 r2 = r1
+		{ wantFiles = wantFiles'
+		, haveFiles = haveFiles'
+		, satisfiedRequests = satisfiedRequests' `S.union` checkSatisfied wantFiles' haveFiles'
+		}
+	  where
+		wantFiles' = foldr addRequest (wantFiles r1) (wantFiles r2)
+		haveFiles' = S.foldr (addFile wantFiles' satisfiedRequests') (haveFiles r1) (haveFiles r2)
+		satisfiedRequests' = satisfiedRequests r1 `S.union` satisfiedRequests r2
+
+-- Adds a file to the set, when there's a request for it, and the request
+-- has not already been satisfied.
+addFile :: [Request] -> S.Set Request -> File -> S.Set File -> S.Set File
+addFile rs srs f fs
+	| any (\sr -> f == requestedFile sr) (S.toList srs) = fs
+	| any (\r -> f == requestedFile r) rs = S.insert f fs
+	| otherwise = fs
+
+-- Checks if any requests have been satisfied, and returns them,
+-- to be added to satisfidRequests
+checkSatisfied :: [Request] -> S.Set File -> S.Set Request
+checkSatisfied want have = S.fromList (filter satisfied want)
+  where
+	satisfied r = requestTTL r == originTTL && S.member (requestedFile r) have
+
+-- Decrements TTL, and avoids adding request with a stale TTL, or a
+-- request for an already added file with the same or a lower TTL.
+addRequest :: Request -> [Request] -> [Request]
+addRequest (Request f ttl) rs
+	| staleTTL ttl' = rs
+	| any (\r -> requestTTL r >= ttl) similar = rs
+	| otherwise = r' : other
+  where
+	ttl' = decTTL ttl
+	r' = Request f ttl'
+	(other, similar) = partition (/= r') rs
+
+move :: (RandomGen g) => TransferNode -> Rand g TransferNode
+move t = do
+	newloc <- randomfrom (possiblelocations t)
+	return $ t { currentlocation = newloc }
+
+genNetwork :: (RandomGen g) => Rand g Network
+genNetwork = do
+	let immobiles = M.fromList (zip (map show [1..]) (replicate numImmobileNodes emptyImmobile))
+	transfers <- sequence (replicate numTransferNodes (mkTransfer $ M.keys immobiles))
+	return $ Network immobiles transfers
+
+emptyImmobile :: ImmobileNode
+emptyImmobile = ImmobileNode (NodeRepo [] S.empty S.empty)
+
+mkTransfer :: (RandomGen g) => [NodeName] -> Rand g TransferNode
+mkTransfer immobiles = do
+	-- Transfer nodes are given random routes. May be simplistic.
+	-- Also, some immobile nodes will not be serviced by any transfer nodes.
+	numpossiblelocs <- getRandomR transferDestinationsRange
+	possiblelocs <- sequence (replicate numpossiblelocs (randomfrom immobiles))
+	mkTransferBetween possiblelocs
+
+mkTransferBetween :: (RandomGen g) => [NodeName] -> Rand g TransferNode
+mkTransferBetween possiblelocs = do
+	currentloc <- randomfrom possiblelocs
+	movefreq <- getRandomR transferMoveFrequencyRange
+	-- transfer nodes start out with no files or requests in their repo
+	let repo = (NodeRepo [] S.empty S.empty)
+	return $ TransferNode currentloc possiblelocs movefreq repo
+
+randomfrom :: (RandomGen g) => [a] -> Rand g a
+randomfrom l = do
+	i <- getRandomR (1, length l)
+	return $ l !! (i - 1)
+
+-- Seeds the network with the given number of files. Each file is added to
+-- one of the immobile nodes of the network at random. And, one other node,
+-- at random, is selected which wants to get the file.
+seedFiles :: (RandomGen g) => Int -> Network -> Rand g Network
+seedFiles 0 network = return network
+seedFiles n network@(Network m t) = do
+	(origink, ImmobileNode originr) <- randnode
+	(destinationk, ImmobileNode destinationr) <- randnode
+	let file = File n
+	let origin = ImmobileNode $ originr
+		{ haveFiles = S.insert file (haveFiles originr) }
+	let destination = ImmobileNode $ destinationr
+		{ wantFiles = Request file originTTL : wantFiles destinationr }
+	let m' = M.insert origink origin $
+		M.insert destinationk destination m
+	seedFiles (n - 1) (Network m' t)
+  where
+	randnode = do
+		k <- randomfrom (M.keys m)
+		return (k, fromJust $ M.lookup k m)
+
+summarize :: Network -> Network -> String
+summarize _initial@(Network origis _) _final@(Network is _ts) = format
+	[ ("Total wanted files",
+		show (sum (overis (length . findoriginreqs . wantFiles . repo))))
+	, ("Wanted files that were not transferred to requesting node",
+		show (sum (overis (S.size . findunsatisfied . repo))))
+	, ("Nodes that failed to get files",
+		show (map withinitiallocs $ filter (not . S.null . snd)
+			(M.toList $ M.map (findunsatisfied . repo) is)))
+	, ("Total number of files on immobile nodes at end",
+		show (overis (S.size . haveFiles . repo)))
+	--, ("Immobile nodes at end", show is)
+	]
+  where
+	findoriginreqs = filter (\r -> requestTTL r == originTTL)
+	findunsatisfied r = 
+		let wantedfs = S.fromList $ map requestedFile (findoriginreqs (wantFiles r))
+		in S.difference wantedfs (haveFiles r)
+	repo (ImmobileNode r) = r
+	overis f = map f $ M.elems is
+	format = unlines . map (\(d, s) -> d ++ ": " ++ s)
+
+	withinitiallocs (name, missingfiles) = (name, S.map addinitialloc missingfiles)
+	addinitialloc f = (f, M.lookup f initiallocs)
+
+	initiallocs = M.fromList $ 
+		concatMap (\(k, v) -> map (\f -> (f, k)) (S.toList $ haveFiles $ repo v)) $
+			M.toList origis
+
+trace :: (Network -> S.Set NodeName) -> [Network] -> String
+trace tracer networks = show $ go [] S.empty $ map tracer networks
+  where
+	go c old [] = reverse c
+	go c old (new:l) = go ((S.toList $ new `S.difference` old):c) new l
+
+traceHaveFile :: File -> Network -> S.Set NodeName
+traceHaveFile f (Network m _) = S.fromList $ M.keys $
+	M.filter (\(ImmobileNode r) -> f `S.member` haveFiles r) m 
+
+traceWantFile :: File -> Network -> S.Set NodeName
+traceWantFile f (Network m _) = S.fromList $ M.keys $
+	M.filter (\(ImmobileNode r) -> any wantf (wantFiles r)) m 
+  where
+	wantf (Request rf _ttl) = rf == f
+
+mocambosNetwork :: (RandomGen g) => Rand g Network
+mocambosNetwork = do
+	let major = map (immobilenamed . fst) communities
+	let minor = map immobilenamed (concatMap snd communities)
+	majortransfer <- mapM mkTransferBetween majorroutes
+	minortransfer <- mapM mkTransferBetween (concatMap minorroutes (concat (replicate 5 communities)))
+	return $ Network
+		(M.fromList (major++minor))
+		(majortransfer ++ minortransfer)
+  where
+	immobilenamed name = (name, emptyImmobile)
+
+	-- As a simplification, this only makes 2 hop routes, between minor
+	-- and major communities; no 3-legged routes.
+	minorroutes :: (NodeName, [NodeName]) -> [Route]
+	minorroutes (major, minors) = map (\n -> [major, n]) minors
+
+communities :: [(NodeName, [NodeName])]
+communities =
+	[ ("Tainá/SP",
+		[ "badtas"
+		, "vauedo ribera"
+		, "cofundo"
+		, "jao"
+		, "fazenda"
+		]
+	  )
+	, ("Odomode/RS",
+		[ "moradadapaz"
+		, "pelotas" 
+		]
+	  )
+	, ("MercadoSul/DF",
+		[ "mesquito"
+		, "kalungos"
+		]
+	  )
+	, ("Coco/PE",
+		[ "xambá"
+		, "alafin"
+		, "terreiaos"
+		]
+	  )
+	, ("Linharinho/ES",
+		[ "monte alegne"
+		]
+	  )
+	, ("Boneco/BA",
+		[ "barroso"
+		, "lagoa santa"
+		, "terravista"
+		]
+	  )
+	, ("Zumbidospalmanes/NA",
+		[ "allantana"
+		]
+	  )
+	, ("Casa Pneta/PA",
+		[ "marajó"
+		]
+	  )
+	, ("Purarue/PA",
+		[ "oriaminá"
+		]
+	  )
+	, ("Madiba/NET", [])
+	]
+
+majorroutes :: [Route]
+majorroutes =
+	-- person's routes
+	[ ["Tainá/SP", "Odomode/RS"]
+	, ["Tainá/SP", "MercadoSul/DF"]
+	, ["MercadoSul/DF", "Boneco/BA"]
+	, ["MercadoSul/DF", "Zumbidospalmanes/NA"]
+	, ["Zumbidospalmanes/NA", "Casa Pneta/PA"]
+	, ["Casa Pneta/PA", "Purarue/PA"]
+	, ["Casa Pneta/PA", "Linharinho/ES"]
+	, ["Boneco/BA", "Coco/PE"]
+	-- internet connections
+	, ["Tainá/SP", "MercadoSul/DF", "Coco/PE", "Purarue/PA", "Odomode/RS", "Madiba/NET"]
+	, ["Tainá/SP", "MercadoSul/DF", "Coco/PE", "Purarue/PA", "Odomode/RS", "Madiba/NET"]
+	, ["Tainá/SP", "MercadoSul/DF", "Coco/PE", "Purarue/PA", "Odomode/RS", "Madiba/NET"]
+	, ["Tainá/SP", "MercadoSul/DF", "Coco/PE", "Purarue/PA", "Odomode/RS", "Madiba/NET"]
+	, ["Tainá/SP", "MercadoSul/DF", "Coco/PE", "Purarue/PA", "Odomode/RS", "Madiba/NET"]
+	]
diff --git a/doc/design/roadmap.mdwn b/doc/design/roadmap.mdwn
new file mode 100644
index 0000000000..d30190169c
--- /dev/null
+++ b/doc/design/roadmap.mdwn
@@ -0,0 +1,12 @@
+git-annex is in a mode of continual user-driven improvement, involving
+numerous small issues and often easily implemented ideas.
+
+# confirmed
+
+Here are open todo items that have been confirmed as worth doing and
+seem to have a design ready:
+
+[[!inline pages="todo/* and !todo/*/* and !todo/done and !link(todo/done) 
+and link(todo/confirmed) and !link(todo/needsthought) and !*/Discussion and
+!todo/moreinfo and !todo/confirmed and !todo/needsthought and
+!todo/unlikely" template=buglist show=0]]
diff --git a/doc/devblog.mdwn b/doc/devblog.mdwn
new file mode 100644
index 0000000000..00060161dc
--- /dev/null
+++ b/doc/devblog.mdwn
@@ -0,0 +1,3 @@
+Joey blogs about his work here on a semi-daily basis.
+
+[[!inline pages="page(devblog/*)" show=0]]
diff --git a/doc/devblog/day_-1__drop_dead.mdwn b/doc/devblog/day_-1__drop_dead.mdwn
new file mode 100644
index 0000000000..97f7cf1d28
--- /dev/null
+++ b/doc/devblog/day_-1__drop_dead.mdwn
@@ -0,0 +1,5 @@
+Implemented `git annex forget --drop-dead`, which is finally a way to
+remove all references to old repositories that you've marked as dead.
+
+I've still not merged in the `forget` branch, because I developed this
+while slightly ill, and have not tested it very well yet.
diff --git a/doc/devblog/day_-3__.mdwn b/doc/devblog/day_-3__.mdwn
new file mode 100644
index 0000000000..fa1473e06e
--- /dev/null
+++ b/doc/devblog/day_-3__.mdwn
@@ -0,0 +1,29 @@
+John Millikin came through and fixed that haskell-gnutls segfault
+on OSX that I developed a reproducible test case for the other day.
+It's a bit hard to test, since the bug doesn't always happen, but the
+fix is already deployed for Mountain Lion autobuilder.
+
+However, I then found another way to make haskell-gnutls segfault, more
+reliably on OSX, and even sometimes on Linux. Just entering the wrong XMPP
+password in the assistant can trigger this crash. Hopefully John will work
+his magic again.
+
+---
+
+Meanwhile, I fixed the sync-after-forget problem. Now sync always forces
+its push of the git-annex branch (as does the assistant). I considered but
+rejected having sync do the kind of uuid-tagged branch push that the
+assistant sometimes falls back to if it's failing to do a normal sync. It's
+ugly, but worse, it wouldn't work in the workflow where multiple clients
+are syncing to a central bare repository, because they'd not pull down the
+hidden uuid-tagged branches, and without the assistant running on the
+repository, nothing would ever merge their data into the git-annex branch.
+Forcing the push of synced/git-annex was easy, once I satisfied myself
+that it was always ok to do so.
+
+Also factored out a module that knows about all the different log files
+stored on the git-annex branch, which is all the support infrastructure
+that will be needed to make `git annex forget --drop-dead` work. Since this
+is basically a routing module, perhaps I'll get around to making it use
+a nice bidirectional routing library like
+[Zwaluw](http://hackage.haskell.org/package/Zwaluw) one day.
diff --git a/doc/devblog/day_-4__forgetting.mdwn b/doc/devblog/day_-4__forgetting.mdwn
new file mode 100644
index 0000000000..a37b32e33a
--- /dev/null
+++ b/doc/devblog/day_-4__forgetting.mdwn
@@ -0,0 +1,80 @@
+Yesterday I spent making a release, and shopping for a new laptop, since
+this one is dying. (Soon I'll be able to compile git-annex fast-ish! Yay!)
+And thinking about [[todo/wishlist:_dropping_git-annex_history]].
+
+Today, I added the `git annex forget` command. It's currently been lightly
+tested, seems to work, and is living in the `forget` branch until I gain
+confidence with it. It should be perfectly safe to use, even if it's buggy,
+because you can use `git reflog git-annex` to pull out and revert to an old
+version of your git-annex branch. So if you're been wanting this feature,
+please beta test!
+
+----
+
+I actually implemented something more generic than just forgetting git
+history. There's now a whole mechanism for git-annex doing distributed
+transitions of whatever sort is needed.
+
+There were several subtleties involved in distributed transitions:
+
+First is how to tell when a given transition has already been done on a
+branch. At first I was thinking that the transition log should include the
+sha of the first commit on the old branch that got rewritten. However, that
+would mean that after a single transition had been done, every git-annex
+branch merge would need to look up the first commit of the current branch,
+to see if it's done the transition yet. That's slow! Instead, transitions
+are logged with a timestamp, and as long as a branch contains a transition
+with the same timestamp, it's been done.
+
+A really tricky problem is what to do if the local repository has
+transitioned, but a remote has not, and changes keep being made to the
+remote. What it does so far is incorporate the changes from the remote into
+the index, and re-run the transition code over the whole thing to yeild a
+single new commit. This might not be very efficient (once I write the more
+full-featured transition code), but it lets the local repo keep up with
+what's going on in the remote, without directly merging with it (which
+would revert the transition). And once the remote repository has its
+git-annex upgraded to one that knows about transitions, it will finish up
+the transition on its side automatically, and the two branches will once
+again merge.
+
+Related to the previous problem, we don't want to keep trying to merge
+from a remote branch when it's not yet transitioned. So a blacklist is
+used, of untransitioned commits that have already been integrated.
+
+One really subtle thing is that when the user does a transition more
+complicated than `git annex forget`, like the `git annex forget --dead`
+that I need to implement to forget dead remotes, they're not just telling
+git-annex to forget whatever dead remotes it knows right now. They're
+actually telling git-annex to perform the transition one time on every
+existing clone of the repository, at some point in the future. Repositories
+with unfinished transitions could hang around for years, and at some future
+point when git-annex runs in the repository again, it would merge in the
+current state of the world, and re-do the transition. So you might tell it
+to forget dead remotes today, and then the very repository you ran that in
+later becomes dead, and a long-slumbering repo wakes up and forgets about
+the repo that started the whole process! I hope users don't find this
+massively confusing, but that's how the implementation works right now.
+
+----
+
+I think I have at least two more days of work to do to finish up this
+feature.
+
+* I still need to add some extra features like forgetting about dead remotes,
+  and forgetting about keys that are no longer present on any remote.
+
+* After `git annex forget`, `git annex sync`
+  will fail to push the synced/annex branch to remotes, since the branch
+  is no longer a fast-forward of the old one. I will probably fix this by
+  making `git annex sync` do a fallback push of a unique branch in this case,
+  like the assistant already does. Although I may need to adjust that code
+  to handle this case, too..
+
+* For some reason the automatic transitioning code triggers
+  a "(recovery from race)" commit. This is certainly a bug somewhere,
+  because you can't have a race with only 1 participant.
+
+----
+
+Today's work was sponsored by Richard Hartmann.
diff --git a/doc/devblog/day_-4__forgetting/comment_1_f3cc7a25af4c59fda3924c737a789419._comment b/doc/devblog/day_-4__forgetting/comment_1_f3cc7a25af4c59fda3924c737a789419._comment
new file mode 100644
index 0000000000..4c926c1afd
--- /dev/null
+++ b/doc/devblog/day_-4__forgetting/comment_1_f3cc7a25af4c59fda3924c737a789419._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Sandra.Devil"
+ ip="77.172.73.184"
+ subject="New laptop"
+ date="2013-09-01T09:38:32Z"
+ content="""
+What is the new laptop you are going to use? Specs please :) 
+"""]]
diff --git a/doc/devblog/day_-4__forgetting/comment_2_e47476c80af02a2e9cf76c53fdbb8534._comment b/doc/devblog/day_-4__forgetting/comment_2_e47476c80af02a2e9cf76c53fdbb8534._comment
new file mode 100644
index 0000000000..db2438f97e
--- /dev/null
+++ b/doc/devblog/day_-4__forgetting/comment_2_e47476c80af02a2e9cf76c53fdbb8534._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="stp"
+ ip="188.193.207.34"
+ subject="Update one forgetting keys no longer present"
+ date="2014-02-17T23:21:49Z"
+ content="""
+I have some repos where due to some hiccups file versions (not in the working tree anymore) were lost and now they come up again and again when fsck is running.
+So I would be happy if I could make my repos forget these not available files via \"git annex forget $key\" and perhaps even have a better solution to show all objects with numcopies=0.
+"""]]
diff --git a/doc/devblog/day_-4__forgetting/comment_3_b57956a8ce372d620f21ea9a497e8013._comment b/doc/devblog/day_-4__forgetting/comment_3_b57956a8ce372d620f21ea9a497e8013._comment
new file mode 100644
index 0000000000..5c0bbc42b4
--- /dev/null
+++ b/doc/devblog/day_-4__forgetting/comment_3_b57956a8ce372d620f21ea9a497e8013._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 3"
+ date="2014-02-20T18:54:48Z"
+ content="""
+@stp, It seems to me if you just delete the symlinks in your git repository that point to the lost files, `git annex fsck` will shut up.
+"""]]
diff --git a/doc/devblog/day_-4__forgetting/comment_4_812b630df01ac35254e3c4e677554e2b._comment b/doc/devblog/day_-4__forgetting/comment_4_812b630df01ac35254e3c4e677554e2b._comment
new file mode 100644
index 0000000000..187545fbc5
--- /dev/null
+++ b/doc/devblog/day_-4__forgetting/comment_4_812b630df01ac35254e3c4e677554e2b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="stp"
+ ip="84.56.21.11"
+ subject="comment 4"
+ date="2014-02-20T21:07:41Z"
+ content="""
+Yeah true if I remove symlinks from the history (as I understand your suggestion) it would work. I just wanted to suggest that it could be something useful for the git annex forget function as it already cleans out old dead repos and other things.
+"""]]
diff --git a/doc/devblog/day_-4__forgetting/comment_5_a9670eca2aff9ad5f04412a8d8b6df6a._comment b/doc/devblog/day_-4__forgetting/comment_5_a9670eca2aff9ad5f04412a8d8b6df6a._comment
new file mode 100644
index 0000000000..d830225262
--- /dev/null
+++ b/doc/devblog/day_-4__forgetting/comment_5_a9670eca2aff9ad5f04412a8d8b6df6a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 5"
+ date="2014-02-20T21:14:21Z"
+ content="""
+You don't need to delete them from the history, just from the branch you're running `git annex fsck` in.
+"""]]
diff --git a/doc/devblog/day_-4__forgetting/comment_6_4f87e2ab119f3cd81266159f02952188._comment b/doc/devblog/day_-4__forgetting/comment_6_4f87e2ab119f3cd81266159f02952188._comment
new file mode 100644
index 0000000000..4ecbb1ae65
--- /dev/null
+++ b/doc/devblog/day_-4__forgetting/comment_6_4f87e2ab119f3cd81266159f02952188._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="stp"
+ ip="84.56.21.11"
+ subject="comment 6"
+ date="2014-02-20T22:19:12Z"
+ content="""
+As discussed on irc.
+Fsck --all does check more then the working tree and therefore for fsck to not complain this would be a worthy feature to be added. (git annex forget $key)
+"""]]
diff --git a/doc/devblog/day_-4__forgetting/comment_7_a865216046aa91a47d0d2b2f0668ea89._comment b/doc/devblog/day_-4__forgetting/comment_7_a865216046aa91a47d0d2b2f0668ea89._comment
new file mode 100644
index 0000000000..dc142edc01
--- /dev/null
+++ b/doc/devblog/day_-4__forgetting/comment_7_a865216046aa91a47d0d2b2f0668ea89._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="stp"
+ ip="84.56.21.11"
+ subject="New findings"
+ date="2014-02-24T12:28:03Z"
+ content="""
+Another thing I found, which was annoying is that I have objects in my annex not tracked anywhere it seems.
+\"git annex fsck --all\" complains about not having access to the object. \"git log --stat -S '$key'\" doesn't have any record. \"git annex fsck\" has no issues and \"git annex unused\" comes up empty too.
+I'm not sure where these objects still reside or why how to remove this annoying failure.
+
+So not only should \"git annex forget $key\" remove references from within all branches, but should also clean up the aforementioned loose objects, which are neither unused, nor available, nor referenced.
+"""]]
diff --git a/doc/devblog/day_-4__forgetting/comment_8_3f7045a00905b4287d950b08d5a77a82._comment b/doc/devblog/day_-4__forgetting/comment_8_3f7045a00905b4287d950b08d5a77a82._comment
new file mode 100644
index 0000000000..f0ba50990c
--- /dev/null
+++ b/doc/devblog/day_-4__forgetting/comment_8_3f7045a00905b4287d950b08d5a77a82._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="stp"
+ ip="188.193.207.34"
+ subject="Any update on cleaning up commands?"
+ date="2014-03-21T16:32:43Z"
+ content="""
+Is there any update on cleaning up object/file references to objects/content not at all present and lost. I would love my git annex fsck --all to show current failures and not these old files all the time.
+Thanks
+"""]]
diff --git a/doc/devblog/day_-4__forgetting/comment_9_d9121a5172f02df63364f19eae87d011._comment b/doc/devblog/day_-4__forgetting/comment_9_d9121a5172f02df63364f19eae87d011._comment
new file mode 100644
index 0000000000..a104c2dd26
--- /dev/null
+++ b/doc/devblog/day_-4__forgetting/comment_9_d9121a5172f02df63364f19eae87d011._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="stp"
+ ip="24.134.205.34"
+ subject="Any update"
+ date="2014-10-01T12:47:47Z"
+ content="""
+Any update?
+"""]]
diff --git a/doc/devblog/day_100__git-annex_sync_--content.mdwn b/doc/devblog/day_100__git-annex_sync_--content.mdwn
new file mode 100644
index 0000000000..f35fbd330e
--- /dev/null
+++ b/doc/devblog/day_100__git-annex_sync_--content.mdwn
@@ -0,0 +1,4 @@
+Spent the day building this new feature, which makes `git annex sync --content`
+do the same synchronization of file contents (to satisfy preferred content
+settings) that the assistant does. The result has not been tested a lot
+yet, but seems to work well.
diff --git a/doc/devblog/day_101__old_mistakes.mdwn b/doc/devblog/day_101__old_mistakes.mdwn
new file mode 100644
index 0000000000..4a37416dc4
--- /dev/null
+++ b/doc/devblog/day_101__old_mistakes.mdwn
@@ -0,0 +1,23 @@
+In order to remove some hackishness in `git annex sync --content`, I
+finally fixed a bad design decision I made back at the very beginning
+(before I really knew haskell) when I built the command seek code, which
+had led to a kind of inversion of control. This took most of a night, but
+it made a lot of code in git-annex clearer, and it makes the command
+seeking code much more flexible in what it can do. Some of the oldest, and
+worst code in git-annex was removed in the process.
+
+Also, I've been reworking the numcopies configuration, to allow for a 
+[[todo/preferred_content_numcopies_check]]. That will let the assistant,
+as well as `git annex sync --content` proactively make copies when
+needed in order to satisfy numcopies. 
+
+As part of this, `git config annex.numcopies` is deprecated, and there's a
+new `git annex numcopies N` command that sets the numcopies value that will
+be used by any clone of a repository.
+
+I got the preferred content checking of numcopies working too. However,
+I am unsure if checking for per-file .gitattributes annex.numcopies
+settings will make preferred content expressions be, so I have left
+that out for now.
+
+Today's work was sponsored by Josh Taylor.
diff --git a/doc/devblog/day_101__old_mistakes/comment_1_2c6e991efde3296450189b2821f2ccc3._comment b/doc/devblog/day_101__old_mistakes/comment_1_2c6e991efde3296450189b2821f2ccc3._comment
new file mode 100644
index 0000000000..93fb84aa3d
--- /dev/null
+++ b/doc/devblog/day_101__old_mistakes/comment_1_2c6e991efde3296450189b2821f2ccc3._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2014-01-21T00:20:34Z"
+ content="""
+Some more details on
+
+* when the old mechanism will stop working
+* how you will ensure interoperability in repo sets which have different versions installed in different places
+* which option weighs more heavily
+
+would be appreciated.
+
+
+Richard
+"""]]
diff --git a/doc/devblog/day_101__old_mistakes/comment_2_524690d69056737dd296e4f7626737d2._comment b/doc/devblog/day_101__old_mistakes/comment_2_524690d69056737dd296e4f7626737d2._comment
new file mode 100644
index 0000000000..9f7ebecf18
--- /dev/null
+++ b/doc/devblog/day_101__old_mistakes/comment_2_524690d69056737dd296e4f7626737d2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.249"
+ subject="comment 2"
+ date="2014-01-21T02:23:00Z"
+ content="""
+I don't plan to remove .git/config annex.numcopies support. It is 5 lines of code. 
+
+A fundamental problem with the .git/config annex.numcopies setting is that it can be inconsistently set between repositories. Therefore, there is no worse potential with interoperability if you use differing versions of git-annex that support and do not support the new global numcopies setting. If this was a concern though, you can use .gitattributes to set annex.numcopies for *, which all recent versions of git-annex support.
+
+The old git/config annex.numcopies setting is overridden as soon as you use `git annex numcopies`. In turn `git annex numcopies` is overridden by any relevant .gitattributes annex.numcopies setting. This is documented on the man page.
+"""]]
diff --git a/doc/devblog/day_102__cleanups.mdwn b/doc/devblog/day_102__cleanups.mdwn
new file mode 100644
index 0000000000..27a1badeaf
--- /dev/null
+++ b/doc/devblog/day_102__cleanups.mdwn
@@ -0,0 +1,10 @@
+Worked on cleaning up and reorganizing all the code that handles numcopies
+settings. Much nicer now. Fixed some bugs.
+
+As expected, making the preferred content numcopies check look at
+.gitattributes slows it down significantly. So, exposed both the slow and
+accurate check and a faster version that ignores .gitattributes.
+
+Also worked on the test suite, removing dependencies between tests.
+This will let tasty-rerun be used later to run only previously failing
+tests.
diff --git a/doc/devblog/day_103__unused.mdwn b/doc/devblog/day_103__unused.mdwn
new file mode 100644
index 0000000000..affb4e532e
--- /dev/null
+++ b/doc/devblog/day_103__unused.mdwn
@@ -0,0 +1,34 @@
+A big missing peice of the assistant is doing something about the content
+of old versions of files, and deleted files. In direct mode, editing or
+deleting a file necessarily loses its content from the local repository,
+but the content can still hang around in other repositories. So, the
+assistant needs to do something about that to avoid eating up disk space
+unnecessarily.
+
+I built on recent work, that lets preferred content expressions be matched
+against keys with no associated file. This means that I can run unused keys
+through all the machinery in the assistant that handles file transfers, and
+they'll end being moved to whatever repository wants them. To control which
+repositories do want to retain unused files, and which not, I added a
+`unused` keyword to preferred content expressions. Client repositories and
+transfer repositories do not want to retain unused files, but backup etc
+repos do.
+
+One nice thing about this `unused` preferred content implementation is that
+it doesn't slow down normal matching of preferred content expressions at
+all. Can you guess why not? See [[!commit 4b55afe9e92c045d72b78747021e15e8dfc16416]]
+
+So, the assistant will run `git annex unused` on a daily basis, and
+cause unused files to flow to repositories that want them. But what if no
+repositories do? To guard against filling up the local disk, there's
+a `annex.expireunused` configuration setting, that can cause old unused
+files to be deleted by the assistant after a number of days.
+
+I made the assistant check if there seem to be a lot of unused files piling
+up. (1000+, or 10% of disk used by them, or more space taken by unused files
+than is free.) If so, it'll pop up an alert to nudge the user to configure
+annex.expireunused.
+
+Still need to build the UI to configure that, and test all of this.
+
+Today's work was sponsored by Samuel Tardieu.
diff --git a/doc/devblog/day_104__unused_II.mdwn b/doc/devblog/day_104__unused_II.mdwn
new file mode 100644
index 0000000000..7dc01c5fdd
--- /dev/null
+++ b/doc/devblog/day_104__unused_II.mdwn
@@ -0,0 +1,7 @@
+Built the UI to manage unused files.
+
+[[!img assistant/unused.png]]
+
+Testing yesterday's work, I found several problems that prevented the
+assistant from moving unused files around, and fixed them. It seems to be
+working pretty well now.
diff --git a/doc/devblog/day_104__unused_II/comment_1_a693a56123497a39c30cbd35b8e35bce._comment b/doc/devblog/day_104__unused_II/comment_1_a693a56123497a39c30cbd35b8e35bce._comment
new file mode 100644
index 0000000000..a4893f63ab
--- /dev/null
+++ b/doc/devblog/day_104__unused_II/comment_1_a693a56123497a39c30cbd35b8e35bce._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7AuSfii_tCkLyspL6Mr0ATlO6OxLNYOo"
+ nickname="Georg"
+ subject="state of windows"
+ date="2014-01-28T10:29:41Z"
+ content="""
+Any idea when this stuff will end in the windows build? I am currently fiddling around with git-annex on windows (btw: great work on that so far!) and the unused files config would be highly valueable to me, since I want to mostly use it to push files out to my server from my work machine or my windows tablet, while preventing to clog up too much space. And since I am lazy, I would love to leave the house keeping to git-annex ;)
+
+An additional question on the windows build: which of the backends can actually make use of windows proxy settings? I guess if webdav was in the list of supported backends, it would work fine, since it is only http, but since it is missing, which of the others would work through just a standard configured squid proxy? For my work machine this is the only way to reach the outside world, doing https to my web server.
+"""]]
diff --git a/doc/devblog/day_104__unused_II/comment_2_9833fb9daa50bc838cc46ca2f6c16580._comment b/doc/devblog/day_104__unused_II/comment_2_9833fb9daa50bc838cc46ca2f6c16580._comment
new file mode 100644
index 0000000000..eeaef05bf2
--- /dev/null
+++ b/doc/devblog/day_104__unused_II/comment_2_9833fb9daa50bc838cc46ca2f6c16580._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.199"
+ subject="comment 2"
+ date="2014-01-28T20:58:32Z"
+ content="""
+AFAICS, the Windows build does include WebDAV support.
+
+I don't know about Windows proxy stuff. If it requires the program to do something, git-annex almost certianly does not do it.
+"""]]
diff --git a/doc/devblog/day_104__unused_II/comment_3_873a882ec1ddc3be473473cb224a9040._comment b/doc/devblog/day_104__unused_II/comment_3_873a882ec1ddc3be473473cb224a9040._comment
new file mode 100644
index 0000000000..96b870627f
--- /dev/null
+++ b/doc/devblog/day_104__unused_II/comment_3_873a882ec1ddc3be473473cb224a9040._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7AuSfii_tCkLyspL6Mr0ATlO6OxLNYOo"
+ nickname="Georg"
+ subject="comment 3"
+ date="2014-01-29T08:22:13Z"
+ content="""
+well, at least in the assistant there is no selection to add a webdav repository - only box.com, rsync.net, S3, remote ssh, and the archives on glazier or internet archive. It is the binary version from 16th this month. I thought it was still excluded due to the compiler crashes you wrote about, because it doesn't show up in the webapp as option. I was scratching my head anyway about that windows build, because there was nothing about setting up encryption in the configuration in the webapp.
+
+Proxy support on Windows is kinda like proxy support on linux when you pull the proxy from gnome settings - just it is pulled from the registry. I don't know how Haskell HTTP client libraries handle it, only know it for Python - there the client libraries usually grab proxy settings automatically from the system configuration.
+
+Another option which could work for me to get through our firewall at work would be ssh - I can use ssh with proxy commands to reach the outside, but didn't yet find the used ssh configs on the windows git-annex installation - it doesn't use the one in ~/.ssh, I added my proxy commands there, but that isn't used.
+"""]]
diff --git a/doc/devblog/day_104__unused_II/comment_4_5ef1bb4d69cf7206f7ca0e542abad6bd._comment b/doc/devblog/day_104__unused_II/comment_4_5ef1bb4d69cf7206f7ca0e542abad6bd._comment
new file mode 100644
index 0000000000..adf3293ffe
--- /dev/null
+++ b/doc/devblog/day_104__unused_II/comment_4_5ef1bb4d69cf7206f7ca0e542abad6bd._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7AuSfii_tCkLyspL6Mr0ATlO6OxLNYOo"
+ nickname="Georg"
+ subject="comment 4"
+ date="2014-01-29T08:26:19Z"
+ content="""
+Oh, just noticed in the console window of the assistant:
+
+ssh-keygen: /home/xgwsbae/.ssh/known_hosts: No such file or directory
+ssh-keygen: /home/xgwsbae/.ssh/known_hosts: No such file or directory
+
+Home directory is C:/Users/xgwsbae/ (git bash gives /c/Users/xgwsbae in $HOME) ... looks like something got confuzzled between Windows and Unix there.
+"""]]
diff --git a/doc/devblog/day_104__unused_II/comment_5_1964bfce4887c9c0828fd7f54f5b4f6b._comment b/doc/devblog/day_104__unused_II/comment_5_1964bfce4887c9c0828fd7f54f5b4f6b._comment
new file mode 100644
index 0000000000..12849438c6
--- /dev/null
+++ b/doc/devblog/day_104__unused_II/comment_5_1964bfce4887c9c0828fd7f54f5b4f6b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.199"
+ subject="comment 5"
+ date="2014-01-29T17:58:26Z"
+ content="""
+Some things (not git-annex) default to /home/$USER when appropriate env vars are not set. There is a bug open about that, [[bugs/assistant_using_the_incorrect_path_on_windows?]], although I don't know what it makes sense for git-annex to do to deal with it.
+
+box.com *is* a webdav repository. It is the only webdav repository the webapp currently supports setting up, although you can configure any webdav remote you like at the command line and the assistant will then be able to use it.
+
+Will be curious to hear if the http-conduit library used for webdav supports proxies. If not, that would certianly seem a good place to file a bug. Unofrtunately, git-annex uses 2 or 3 other http stacks in other places too.
+"""]]
diff --git a/doc/devblog/day_104__unused_II/comment_6_0ed4023c9c249024fe0454fc5bab3b14._comment b/doc/devblog/day_104__unused_II/comment_6_0ed4023c9c249024fe0454fc5bab3b14._comment
new file mode 100644
index 0000000000..d900dc5117
--- /dev/null
+++ b/doc/devblog/day_104__unused_II/comment_6_0ed4023c9c249024fe0454fc5bab3b14._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7AuSfii_tCkLyspL6Mr0ATlO6OxLNYOo"
+ nickname="Georg"
+ subject="comment 6"
+ date="2014-01-30T10:52:09Z"
+ content="""
+Well, according to the hackage documentation of http conduit it seems it at least supports proxies when youre code gives it the proxy host and port.
+
+But the link about the problem with environment settings helped me to get around my immediate problem by just running annex from the git bash (which is prefereably to me most of the time anyway). So I could set up my annex on my work machine and just tunnel out with ProxyCommand via our ssh gateway. Yay!
+"""]]
diff --git a/doc/devblog/day_105__locking.mdwn b/doc/devblog/day_105__locking.mdwn
new file mode 100644
index 0000000000..b41056bb44
--- /dev/null
+++ b/doc/devblog/day_105__locking.mdwn
@@ -0,0 +1,30 @@
+With yesterday's release, I'm pretty much done with the month's work. Since
+there was no particular goal this month, it's been a grab bag of features
+and bugfixes. Quite a lot of them in this last release.
+
+I'll be away the next couple of days.. But got a start today on the next
+part of the roadmap, which is planned to be all about Windows and Android
+porting. Today, it was all about lock files, mostly on Windows.
+
+Lock files on Windows are horrific. I especially like that programs that
+want to open a file, for any reason, are encouraged in the official
+documentation to retry repeatedly if it fails, because some other
+random program, like a virus checker, might have opened the file first.
+
+Turns out Windows does support a shared file read mode. This was
+just barely enough for me to implement both shared and exclusive
+file locking a-la-flock.
+
+Couldn't avoid a busy wait in a few places that block on a lock.
+Luckily, these are few, and the chances the lock will be taken for a long
+time is small. (I did think about trying to watch the file for close events
+and detect when the lock was released that way, but it seemed much too
+complicated and hard to avoid races.)
+
+Also, Windows only seems to support mandatory locks, while all locking in
+git-annex needs to be advisory locks. Ie, git-annex's locking shouldn't
+prevent a program from opening an annexed file! To work around that,
+I am using dedicated lock files on Windows.
+
+Also switched direct mode's annexed object locking to use dedicated lock
+files. AFAICS, this was pretty well broken in direct mode before.
diff --git a/doc/devblog/day_106__catching_up.mdwn b/doc/devblog/day_106__catching_up.mdwn
new file mode 100644
index 0000000000..86e7acbaec
--- /dev/null
+++ b/doc/devblog/day_106__catching_up.mdwn
@@ -0,0 +1,5 @@
+While I've not been blogging over what amounted to a long weekend, looking
+over the changelog, there were quite a few things done. Mostly various
+improvements and fixes to `git annex sync --content`.
+
+Today, got the test suite to pass on Windows 100% again.
diff --git a/doc/devblog/day_107__TDD.mdwn b/doc/devblog/day_107__TDD.mdwn
new file mode 100644
index 0000000000..0ae41f0d64
--- /dev/null
+++ b/doc/devblog/day_107__TDD.mdwn
@@ -0,0 +1,10 @@
+A more test driven day than usual. Yesterday I noticed a test case was
+failing on Windows in a way not related to what it was intended to test,
+and fixed the test case to not fail.. But knew I'd need to get to the
+bottom of what broke it eventually.
+
+Digging into that today, I eventually (after rather a long time stuck)
+determined the bug involved automatic conflict resolution, but only
+happened on systems without symlink support. This let me reproduce it on
+FAT outside Windows and do some fast TDD iterations in a much less
+unwieldly environment and fix the bug.
diff --git a/doc/devblog/day_108__new_use_for_location_tracking.mdwn b/doc/devblog/day_108__new_use_for_location_tracking.mdwn
new file mode 100644
index 0000000000..62e40672f7
--- /dev/null
+++ b/doc/devblog/day_108__new_use_for_location_tracking.mdwn
@@ -0,0 +1,20 @@
+Added a new feature that started out with me wanting a way to undo a
+`git-annex drop`, but turned into something rather more powerful. The `--in`
+option can now be told to match files that were in a repository at some
+point in the past. For example, `git annex get --in=here@{yesterday}` will
+get any files that have been dropped over the past day.
+
+While git-annex's location tracking info is stored in git and thus versioned,
+very little of it makes use of past versions of the location tracking info
+(only `git annex log`). I'm happy to have finally found a use for it!
+
+OB Windows porting: Fixed a bug in the symlink calculation code.
+Sounds simple; took 2 hours!
+
+Also various bug triage; updated git version on OSX; forwarded bug about
+DAV-0.6 being broken upstream; fixed a bug with initremote in 
+encryption=pubkey mode. Backlog is 65 messages.
+
+---
+
+Today's work was sponsored by Brock Spratlen.
diff --git a/doc/devblog/day_109__elimintating_absNormPath.mdwn b/doc/devblog/day_109__elimintating_absNormPath.mdwn
new file mode 100644
index 0000000000..8381f2956e
--- /dev/null
+++ b/doc/devblog/day_109__elimintating_absNormPath.mdwn
@@ -0,0 +1,18 @@
+git-annex has been using MissingH's `absNormPath` forever, but that's
+not very maintained and doesn't work on Windows. I've been
+wanting to get rid of it for some time, and finally did today, writing a
+`simplifyPath` that does the things git-annex needs and will work with all
+the Windows filename craziness, and takes advantage of the more modern
+System.FilePath to be quite a simple peice of code. A QuickCheck test found
+no important divergences from absNormPath. A good first step to making
+git-annex not depend on MissingH at all. 
+
+That fixed one last Windows bug that was disabled in the test suite:
+`git annex add ..\subdir\file` will now work.
+
+I am re-installing the Android autobuilder for 2 reasons: I noticed I had
+accidentally lost a patch to make a library use the Android SSL cert directory,
+and also a new version of GHC is very near to release and so it makes sense
+to update.
+
+Down to 38 messages in the backlog.
diff --git a/doc/devblog/day_10__lazy_Sunday.mdwn b/doc/devblog/day_10__lazy_Sunday.mdwn
new file mode 100644
index 0000000000..c8843d3747
--- /dev/null
+++ b/doc/devblog/day_10__lazy_Sunday.mdwn
@@ -0,0 +1,23 @@
+Fixed a typo that broke automatic youtube video support in `addurl`.
+
+----
+
+Now there's an easy way to get an overview of how close your repository
+is to meeting the configured numcopies settings (or when it exceeds them).
+
+<pre>
+# time git annex info . 
+[...]
+numcopies stats: 
+	numcopies +0: 6686
+	numcopies +1: 3793
+	numcopies +3: 3156
+	numcopies +2: 2743
+	numcopies -1: 1242
+	numcopies -4: 1098
+	numcopies -3: 1009
+	numcopies +4: 372
+</pre>
+
+This does make `git annex info` slow when run on a large directory tree,
+so --fast disables that.
diff --git a/doc/devblog/day_110__release_prep.mdwn b/doc/devblog/day_110__release_prep.mdwn
new file mode 100644
index 0000000000..12ba78a4fd
--- /dev/null
+++ b/doc/devblog/day_110__release_prep.mdwn
@@ -0,0 +1,25 @@
+Last night I tracked down and fixed a bug in the DAV library that has been
+affecting WebDAV remotes. I've been deploying the fix for that today,
+including to the android and arm autobuilders. While I finished a clean
+reinstall of the android autobuilder, I ran into problems getting a clean
+reinstall of the arm autobuilder (some type mismatch error building
+yesod-core), so manually fixed its DAV for now.
+
+The WebDAV fix and other recent fixes makes me want to make a release soon,
+probably Monday.
+
+ObWindows: Fixed git-annex to not crash when run on Windows
+in a git repository that has a remote with a unix-style path 
+like "/foo/bar". Seems that not everything aggrees on whether such a path
+is absolute; even sometimes different parts of the same library disagree!
+
+[[!format haskell """
+import System.FilePath.Windows
+
+prop_windows_is_sane :: Bool
+prop_windows_is_sane = isAbsolute upath || ("C:\\STUFF" </> upath /= upath)
+  where upath = "/foo/bar"
+"""]]
+
+Perhaps more interestingly, I've been helping dxtrish port git-annex to
+OpenBSD and it seems most of the way there.
diff --git a/doc/devblog/day_111__windows_beta_release.mdwn b/doc/devblog/day_111__windows_beta_release.mdwn
new file mode 100644
index 0000000000..cd880dc0c5
--- /dev/null
+++ b/doc/devblog/day_111__windows_beta_release.mdwn
@@ -0,0 +1,6 @@
+Pushed out the new release. This is the first one where I consider the
+git-annex command line beta quality on Windows.
+
+Did some testing of the webapp on Windows, trying out every part of the UI.
+I now have eleven todo items involving the webapp listed in
+[[todo/windows_support]]. Most of them don't look too bad to fix.
diff --git a/doc/devblog/day_112__metadata_design.mdwn b/doc/devblog/day_112__metadata_design.mdwn
new file mode 100644
index 0000000000..e75d4fc4ed
--- /dev/null
+++ b/doc/devblog/day_112__metadata_design.mdwn
@@ -0,0 +1,18 @@
+There's a new design document for letting git-annex store arbitrary
+metadata. The really neat thing about this is the user can check out only
+files matching the tags or values they care about, and get an automatically
+structuted file tree layout that can be dynamically filtered. It's going to
+be awesome! [[design/metadata]]
+
+In the meantime, spent most of today working on Windows. Very good
+progress, possibly motivated by wanting to get it over with so I can spend
+some time this month on the above. ;)
+
+* webapp can make box.com and S3 remotes. This just involved fixing a hack
+  where the webapp set environment variables to communicate creds to
+  initremote. Can't change environment on Windows (or I don't know how to).
+* webapp can make repos on removable drives.
+* `git annex assistant --stop` works, although this is not likely to really
+  be useful
+* The source tree now has 0 `func = error "Windows TODO"` type stubbed out
+  functions to trip over.
diff --git a/doc/devblog/day_113__metadata_groundwork.mdwn b/doc/devblog/day_113__metadata_groundwork.mdwn
new file mode 100644
index 0000000000..4859c4d33e
--- /dev/null
+++ b/doc/devblog/day_113__metadata_groundwork.mdwn
@@ -0,0 +1,9 @@
+Built the core data types, and log for metadata storage. Making metadata
+union merge well is tricky, but I have a design I'm happy with, that will
+allow distributed changes to metadata.
+
+Finished up the day with a `git annex metadata` command to get/set metadata
+for a file.
+
+This is all the goundwork needed to begin experimenting with generating
+git branches that display different metadata-driven views of annexed files.
diff --git a/doc/devblog/day_114__windows_porting.mdwn b/doc/devblog/day_114__windows_porting.mdwn
new file mode 100644
index 0000000000..2f1cace1b1
--- /dev/null
+++ b/doc/devblog/day_114__windows_porting.mdwn
@@ -0,0 +1,8 @@
+Windows porting all day. Fixed a lot of issues with the webapp,
+so quite productive. Except for the 2 hours wasted finding a way to kill a
+process by PID from Haskell on Windows.
+
+Last night, made `git annex metadata` able to set metadata on a whole
+directory or list of files if desired. And added a `--metadata field=value`
+switch (and corresponding preferred content terminal) which limits
+git-annex to acting on files with the specified metadata.
diff --git a/doc/devblog/day_115__windows_porting.mdwn b/doc/devblog/day_115__windows_porting.mdwn
new file mode 100644
index 0000000000..a9abe4ad2f
--- /dev/null
+++ b/doc/devblog/day_115__windows_porting.mdwn
@@ -0,0 +1,17 @@
+More Windows porting.. Seem to be getting near an end of the easy stuff,
+and also the webapp is getting pretty usable on Windows now, the only
+really important thing lacking is XMPP support.
+
+Made git-annex on Windows set HOME when it's not already set. Several of
+the bundled cygwin tools only look at HOME. This was made a lot harder and
+uglier due to there not being any way to modify the environment of the
+running process.. git-annex has to re-run itself with the fixed
+environment.
+
+Got rsync.net working in the webapp. Although with an extra rsync.net
+password prompt on Windows, which I cannot find a way to avoid.
+
+While testing that, I discovered that openssh 6.5p1 has broken support for
+~/.ssh/config Host lines that contain upper case letters! I have filed a
+bug about this and put a quick fix in git-annex, which sometimes generated
+such lines.
diff --git a/doc/devblog/day_116__views.mdwn b/doc/devblog/day_116__views.mdwn
new file mode 100644
index 0000000000..a7aaf2c939
--- /dev/null
+++ b/doc/devblog/day_116__views.mdwn
@@ -0,0 +1,54 @@
+Working on building [[design/metadata]] filtered branches.
+
+Spent most of the day on types and pure code. Finally at the end 
+I wrote down two actions that I still need to implement to make
+it all work:
+
+[[!format haskell """
+applyView' :: MkFileView -> View -> Annex Git.Branch
+updateView :: View -> Git.Ref -> Git.Ref -> Annex Git.Branch
+"""]]
+
+I know how to implement these, more or less. And in most cases
+they will be pretty fast.
+
+The more interesting part is already done. That was the issue of how to
+generate filenames in the filter branches. That depends on the `View` being
+used to filter and organize the branch, but also on the original filename used
+in the reference branch. Each filter branch has a reference branch (such as
+"master"), and displays a filtered and metadata-driven reorganized tree
+of files from its reference branch.
+
+[[!format haskell """
+fileViews :: View -> (FilePath -> FileView) -> FilePath -> MetaData -> Maybe [FileView]
+"""]]
+
+So, a view that matches files tagged "haskell" or "git-annex"
+and with an author of "J\*" will generate filenames like 
+"haskell/Joachim/interesting_theoretical_talk.ogg" and
+"git-annex/Joey/mytalk.ogg".
+
+It can also work backwards from these 
+filenames to derive the MetaData that is encoded in them.
+
+[[!format haskell """
+fromView :: View -> FileView -> MetaData
+"""]]
+
+So, copying a file to "haskell/Joey/mytalk.ogg" lets it know that
+it's gained a "haskell" tag. I knew I was on the right track when
+`fromView` turned out to be only 6 lines of code!
+
+The trickiest part of all this, which I spent most of yesterday thinking
+about, is what to do if the master branch has files in subdirectories. It
+probably does not makes sense to retain that hierarchical directory
+structure in the filtered branch, because we instead have a
+non-hierarchical metadata structure to express. (And there would probably
+be a lot of deep directory structures containing only one file.) But
+throwing away the subdirectory information entirely means that two files
+with the same basename and same metadata would have colliding names.
+
+I eventually decided to embed the subdirectory information into the filenames
+used on the filter branch. Currently that is done by converting
+`dir/subdir/file.foo` to `file(dir)(subdir).foo`. We'll see how this works
+out in practice..
diff --git a/doc/devblog/day_117__views_implemented.mdwn b/doc/devblog/day_117__views_implemented.mdwn
new file mode 100644
index 0000000000..fa2ae28375
--- /dev/null
+++ b/doc/devblog/day_117__views_implemented.mdwn
@@ -0,0 +1,76 @@
+Today I built `git annex view`, and `git annex vadd` and a few related
+commands. A quick demo:
+
+<pre>
+joey@darkstar:~/lib/talks>ls
+Chaos_Communication_Congress/  FOSDEM/       Linux_Conference_Australia/
+Debian/                        LibrePlanet/  README.md
+joey@darkstar:~/lib/talks>git annex view tag=*
+view  (searching...)
+Switched to branch 'views/_'
+ok
+joey@darkstar:~/lib/talks#_>tree -d
+.
+|-- Debian
+|-- android
+|-- bigpicture
+|-- debhelper
+|-- git
+|-- git-annex
+`-- seen
+
+7 directories
+joey@darkstar:~/lib/talks#_>git annex vadd author=*
+vadd  
+Switched to branch 'views/author=_;_'
+ok
+joey@darkstar:~/lib/talks#author=_;_>tree -d
+.
+|-- Benjamin Mako Hill
+|   `-- bigpicture
+|-- Denis Carikli
+|   `-- android
+|-- Joey Hess
+|   |-- Debian
+|   |-- bigpicture
+|   |-- debhelper
+|   |-- git
+|   `-- git-annex
+|-- Richard Hartmann
+|   |-- git
+|   `-- git-annex
+`-- Stefano Zacchiroli
+    `-- Debian
+
+15 directories
+joey@darkstar:~/lib/talks#author=_;_>git annex vpop
+vpop 1
+Switched to branch 'views/_'
+ok
+joey@darkstar:~/lib/talks#_>git annex vadd tag=git-annex
+vadd  
+Switched to branch 'views/(git-annex)'
+ok
+joey@darkstar:~/lib/talks#(git-annex)>ls
+1025_gitify_your_life_{Debian;2013;DebConf13;high}.ogv@
+git_annex___manage_files_with_git__without_checking_their_contents_into_git_{FOSDEM;2012;lightningtalks}.webm@
+mirror.linux.org.au_linux.conf.au_2013_mp4_gitannex_{Linux_Conference_Australia;2013}.mp4@
+joey@darkstar:~/lib/talks#_>git annex vpop 2
+vpop 2
+Switched to branch 'master'
+ok
+</pre>
+
+Not 100% happy with the speed -- the generation of the view branch is close
+to optimal, and fast enough (unless the branch has very many matching
+files). And `vadd` can be quite fast if the view has already limited the
+total number of files to a smallish amount. But `view` has to look at every
+file's metadata, and this can take a while in a large repository. Needs indexes.
+
+It also needs integration with `git annex sync`, so the view branches
+update when files are added to the master branch, and moving files around
+inside a view and committing them does not yet update their metadata.
+
+---
+
+Today's work was sponsored by Daniel Atlas.
diff --git a/doc/devblog/day_118__views_refined.mdwn b/doc/devblog/day_118__views_refined.mdwn
new file mode 100644
index 0000000000..bfd102f18f
--- /dev/null
+++ b/doc/devblog/day_118__views_refined.mdwn
@@ -0,0 +1,7 @@
+Still working on views. The most important addition today is that
+`git annex precommit` notices when files have been moved/copied/deleted
+in a view, and updates the metadata to reflect the changes.
+
+Also wrote some walkthrough documentation: [[tips/metadata_driven_views]].  
+And, recorded a screencast demoing views, which I will upload next time
+I have bandwidth.
diff --git a/doc/devblog/day_119__catching_up.mdwn b/doc/devblog/day_119__catching_up.mdwn
new file mode 100644
index 0000000000..c49c3e34dd
--- /dev/null
+++ b/doc/devblog/day_119__catching_up.mdwn
@@ -0,0 +1,15 @@
+Spent the day catching up on the last week or so's traffic. Ended up
+making numerous small big fixes and improvements. Message backlog stands at
+44.
+
+Here's the [[screencast demoing views|videos/git-annex_views_demo]]!
+
+Added to the design today the idea of
+automatically deriving metadata from the location of files in the master
+branch's directory tree. Eg, `git annex view tag=* podcasts/=*` in a
+repository that has a `podcasts/` directory would make a tree like
+"$tag/$podcast". Seems promising. 
+
+So much still to do with views.. I have belatedly added them to
+the roadmap for this month; doing Windows and Android in the same month was
+too much to expect.
diff --git a/doc/devblog/day_119__catching_up/comment_1_8aa413e75cab411b0aec254f0f33ebb9._comment b/doc/devblog/day_119__catching_up/comment_1_8aa413e75cab411b0aec254f0f33ebb9._comment
new file mode 100644
index 0000000000..9c1ba1e43e
--- /dev/null
+++ b/doc/devblog/day_119__catching_up/comment_1_8aa413e75cab411b0aec254f0f33ebb9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlJEI45rGczFAnuM7gRSj4C6s9AS9yPZDc"
+ nickname="Kevin"
+ subject="Neat!"
+ date="2014-02-20T21:59:05Z"
+ content="""
+When the [[metadata design|day_112__metadata_design]] stuff appeared on the blog I didn't understand what you meant by automatically creating new tree layouts.  I'm really liking these views and can already imagine how useful it would be to tag my photos by person/place/time.  This is awesome!  Keep up the good work.
+"""]]
diff --git a/doc/devblog/day_119__catching_up/comment_2_db31d08690730836ce6277e797fcae1d._comment b/doc/devblog/day_119__catching_up/comment_2_db31d08690730836ce6277e797fcae1d._comment
new file mode 100644
index 0000000000..532b7a4d5f
--- /dev/null
+++ b/doc/devblog/day_119__catching_up/comment_2_db31d08690730836ce6277e797fcae1d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawneiQ3iR9VXOPEP34u7m_L3Qr28H1nEfE0"
+ nickname="Ethan"
+ subject="LFS"
+ date="2014-02-21T00:03:59Z"
+ content="""
+You might be interested in the Logic File System at http://www.padator.org/wiki/wiki-LFS/doku.php or http://www.padator.org/papers/ which has a similar idea with views and metadata.
+"""]]
diff --git a/doc/devblog/day_119__catching_up/comment_3_d44da76b18f53a5f51b46e3e15090a48._comment b/doc/devblog/day_119__catching_up/comment_3_d44da76b18f53a5f51b46e3e15090a48._comment
new file mode 100644
index 0000000000..9d97aff2d4
--- /dev/null
+++ b/doc/devblog/day_119__catching_up/comment_3_d44da76b18f53a5f51b46e3e15090a48._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmZgZuUhZlHpd_AbbcixY0QQiutb2I7GWY"
+ nickname="Jimmy"
+ subject="comment 3"
+ date="2014-02-21T07:05:34Z"
+ content="""
+I agree with Kevin as to the potential usefulness for photos.  Particularly if there's some way of automatically extracting and using tags or other EXIF metadata.
+"""]]
diff --git a/doc/devblog/day_11__webapp_encrypted_drives.mdwn b/doc/devblog/day_11__webapp_encrypted_drives.mdwn
new file mode 100644
index 0000000000..677c02491b
--- /dev/null
+++ b/doc/devblog/day_11__webapp_encrypted_drives.mdwn
@@ -0,0 +1,12 @@
+Now the webapp can set up encrypted repositories on removable drives.
+
+[[assistant/encryptdrive.png]]
+
+This UI needs some work, and the button to create a new key is not wired
+up. Also if you have no gpg agent installed, there will be lots of password
+prompts at the console.
+
+Forked git-remote-gcrypt to fix a bug. Hopefully my patch will be merged;
+for now I recommend installing my worked version.
+
+Today's work was sponsored by Romain Lenglet.
diff --git a/doc/devblog/day_120__more_metadata.mdwn b/doc/devblog/day_120__more_metadata.mdwn
new file mode 100644
index 0000000000..daff68e379
--- /dev/null
+++ b/doc/devblog/day_120__more_metadata.mdwn
@@ -0,0 +1,17 @@
+When generating a view, there's now a way to reuse part of the directory
+hierarchy of the parent branch. For example, `git annex view tag=* podcasts/=*`
+makes a view where the first level is the tags, and the second level is
+whatever `podcasts/*` directories the files were in.
+
+Also, year and month metadata can be automatically recorded when
+adding files to the annex. I made this only be done when annex.genmetadata
+is turned on, to avoid polluting repositories that don't want to use metadata.
+
+It would be nice if there was a way to add a hook script that's run
+when files are added, to collect their metadata. I am not sure yet if
+I am going to add that to git-annex though. It's already possible to do via
+the regular git `post-commit` hook. Just make it look at the commit to see
+what files were added, and then run `git annex metadata` to set their
+metadata appropriately. It would be good to at least have an example of
+such a script to eg, extract EXIF or ID3 metadata. Perhaps someone can
+contribute one?
diff --git a/doc/devblog/day_121__special_remote_maintenance.mdwn b/doc/devblog/day_121__special_remote_maintenance.mdwn
new file mode 100644
index 0000000000..5517048858
--- /dev/null
+++ b/doc/devblog/day_121__special_remote_maintenance.mdwn
@@ -0,0 +1,23 @@
+Turns out that in the last release I broke making box.com, Amazon S3 and
+Glacier remotes from the webapp. Fixed that.
+
+Also, dealt with changes in the haskell DAV library that broke support for
+box.com, and worked around an exception handling bug in the library.
+
+I think I should try to enhance the test suite so it can run live tests
+on special remotes, which would at least have caught the some of these
+recent problems...
+
+----
+
+Since metadata is tied to a particular key, editing an annexed file,
+which causes the key to change, made the metadata seem to get lost.
+
+I've now fixed this; it copies the metadata from the old version to the new
+one. (Taking care to copy the log file identically, so git can reuse its
+blob.) 
+
+That meant that `git annex add` has to check every file it adds to see if
+there's an old version. Happily, that check is fairly fast; I benchmarked my
+laptop running 2500 such checks a second. So it's not going to slow things
+down appreciably.
diff --git a/doc/devblog/day_122_more_windows_porting.mdwn b/doc/devblog/day_122_more_windows_porting.mdwn
new file mode 100644
index 0000000000..7b496f670f
--- /dev/null
+++ b/doc/devblog/day_122_more_windows_porting.mdwn
@@ -0,0 +1,4 @@
+More Windows porting. Made the build completely `-Wall` safe on Windows.
+Fixed some DOS path separator bugs that were preventing WebDav from
+working. Have now tested both box.com and Amazon S3 to be completely
+working in the webapp on Windows.
diff --git a/doc/devblog/day_123__stuck.mdwn b/doc/devblog/day_123__stuck.mdwn
new file mode 100644
index 0000000000..c48507cf0e
--- /dev/null
+++ b/doc/devblog/day_123__stuck.mdwn
@@ -0,0 +1,13 @@
+Not a lot accomplished today. Some release prep, followed up to a few bug
+reports.
+
+Split git-annex's .git/annex/tmp into two directories. .git/annex/tmp will
+now be used only for partially transferred objects, while
+.git/annex/misctmp will be used for everything else. In particular this
+allows symlinking .git/annex/tmp to a ram disk, if you want to do that.
+(It's not possible for .git/annex/misctmp to be on a different filesystem
+from the rest of the repository for various reasons.)
+
+Beat on Windows XMPP for several more painful hours. Got all the haskell
+bindings installed, except for gnuidn. And patched network-client-xmpp to
+build without gnuidn. Have not managed to get it to link.
diff --git a/doc/devblog/day_124__day_off.mdwn b/doc/devblog/day_124__day_off.mdwn
new file mode 100644
index 0000000000..c8c8f0109f
--- /dev/null
+++ b/doc/devblog/day_124__day_off.mdwn
@@ -0,0 +1,13 @@
+Did not plan to work on git-annex today..
+
+Unexpectedly ended up making the webapp support HTTPS. Not by default,
+but if a key and certificate are provided, it'll use them. Great for
+using the webapp remotely! See the new tip: [[tips/remote_webapp_setup]].
+
+Also removed support for --listen with a port, which was buggy and not
+necessary with HTTPS.
+
+Also fixed several webapp/assistant bugs, including one that let it be run in
+a bare git repository.
+
+And, made the quvi version be probed at runtime, rather than compile time.
diff --git a/doc/devblog/day_125__metadata_and_views.mdwn b/doc/devblog/day_125__metadata_and_views.mdwn
new file mode 100644
index 0000000000..471457355a
--- /dev/null
+++ b/doc/devblog/day_125__metadata_and_views.mdwn
@@ -0,0 +1,11 @@
+Worked on metadata and views. Besides bugfixes, two features of note:
+
+Made git-annex run a hook script, pre-commit-annex. And I wrote a
+sample script that extracts metadata from lots of kinds of files,
+including photos and sound files, using extract(1) to do the heavy lifting.
+See [[tips/automatically_adding_metadata]].
+
+Views can be filtered to not include a tag or a field.
+For example, `git annex view tag=* !old year!=2013`
+
+Today's work was sponsored by Stephan Schulz
diff --git a/doc/devblog/day_128__release_prep.mdwn b/doc/devblog/day_128__release_prep.mdwn
new file mode 100644
index 0000000000..d43d2f877b
--- /dev/null
+++ b/doc/devblog/day_128__release_prep.mdwn
@@ -0,0 +1,27 @@
+Preparing for a release (probably tomorrow or Friday).
+
+Part of that was updating the autobuilders. Had to deal with the gnutls
+security hole fix, and upgrading that on the OSX autobuilder turned out to
+be quite complicated due to library version skew. Also, I switched the
+linux autobuilders over to building from Debian unstable, rather than
+stable. That should be ok to do now that the standalone build bundles all
+the libraries it needs... And the arm build has always used unstable, and
+has been reported working on a lot of systems. So I think this will be
+safe, but have backed up the old autobuilder chroots just in case.
+
+Also been catching up on bug reports and traffic and 
+and dealt with quite a lot of things today. Smarter log file
+rotation for the assistant, better webapp behavior when git is not
+installed, and a fix for the webdav 5 second timeout problem.
+
+Perhaps the most interesting change is a new `annex.startupscan` setting,
+which can be disabled to prevent the assistant from doing the expensive
+startup scan. This means it misses noticing any files that changed since it
+last run, but this should be useful for those really big repositories.
+
+(Last night, did more work on the test suite, including even more checking
+of merge conflict resolution.)
+
+----
+
+Today's work was sponsored by Michael Alan Dorman.
diff --git a/doc/devblog/day_12__gpg_key_generation.mdwn b/doc/devblog/day_12__gpg_key_generation.mdwn
new file mode 100644
index 0000000000..c79c49f856
--- /dev/null
+++ b/doc/devblog/day_12__gpg_key_generation.mdwn
@@ -0,0 +1,35 @@
+I decided to keep gpg key generation very simple for now. So it generates a
+special-purpose key that is only intended to be used by git-annex. It
+hardcodes some key parameters, like RSA and 4096 bits (maximum recommended
+by gpg at this time). And there is no password on the key, although you can
+of course edit it and set one. This is because anyone who can access the
+computer to get the key can also look at the files in your git-annex
+repository. Also because I can't rely on gpg-agent being installed
+everywhere. All these simplifying assumptions may be revisited later, but
+are enough for now for someone who doesn't know about gpg (so doesn't 
+have a key already) and just wants an encrypted repo on a
+removable drive.
+
+Put together a simple UI to deal with gpg taking quite a while to
+generate a key ...
+
+[[assistant/genkey.png]]
+
+[[assistant/repoinfo.png]]
+
+Then I had to patch git-remote-gcrypt again, to have a per-remote
+signingkey setting, so that these special-purpose keys get used for signing
+their repo.
+
+Next, need to add support for adding an existing gcrypt repo as a remote
+(assuming it's encrypted to an available key). Then, gcrypt repos on ssh
+servers..
+
+----
+
+Also dealt with build breakage caused by a new version of the Haskell DNS
+library.
+
+----
+
+Today's work was sponsored by Joseph Liu.
diff --git a/doc/devblog/day_12__gpg_key_generation/comment_1_48cdfe3bd71fb348ae05fd90e8cf1dab._comment b/doc/devblog/day_12__gpg_key_generation/comment_1_48cdfe3bd71fb348ae05fd90e8cf1dab._comment
new file mode 100644
index 0000000000..d7a6a86313
--- /dev/null
+++ b/doc/devblog/day_12__gpg_key_generation/comment_1_48cdfe3bd71fb348ae05fd90e8cf1dab._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://nullroute.eu.org/~grawity/"
+ nickname="Mantas"
+ subject="comment 1"
+ date="2013-09-18T05:00:12Z"
+ content="""
+Should be \"PGP\" or *at least* \"GnuPG\".
+"""]]
diff --git a/doc/devblog/day_130__post_release.mdwn b/doc/devblog/day_130__post_release.mdwn
new file mode 100644
index 0000000000..b6a2af6c8b
--- /dev/null
+++ b/doc/devblog/day_130__post_release.mdwn
@@ -0,0 +1,17 @@
+Release made yesterday, but only finished up the armel build today. 
+And it turns out the OSX build was missing the webapp, so it's also been
+updated today.
+
+Post release bug triage including:
+
+Added a nice piece of UI to the webapp on user request: A "Sync now" menu
+item in the repository for each repo. (The one for the current repo syncs with
+all its remotes.)
+
+Copying files to a git repository on the same computer turns out to have
+had a resource leak issue, that caused 1 zombie process per file. With
+some tricky monad state caching, fixed that, and also eliminated 8% of the work
+done by git-annex in this case.
+
+Fixed `git annex unused` in direct mode to not think that files that were
+deleted out of the work tree by the user still existed and were unused.
diff --git a/doc/devblog/day_131__more_bug_squashing.mdwn b/doc/devblog/day_131__more_bug_squashing.mdwn
new file mode 100644
index 0000000000..3c256f1fbd
--- /dev/null
+++ b/doc/devblog/day_131__more_bug_squashing.mdwn
@@ -0,0 +1,11 @@
+Squashed three or four more bugs today. Unanswered message backlog is down
+to 27.
+
+The most interesting problem today is that the git-repair code was using
+too much memory when `git-fsck` output a lot of problems (300 thousand!). I
+managed to half the memory use in the worst case (and reduced it much more
+in more likely cases). But, don't really feel I can close that bug yet,
+since really big, really badly broken repositories can still run it out of
+memory. It would be good to find a way to reorganize the code so that the
+broken objects list streams through git-repair and never has to all be
+buffered in memory at once. But this is not easy.
diff --git a/doc/devblog/day_132__database_musings.mdwn b/doc/devblog/day_132__database_musings.mdwn
new file mode 100644
index 0000000000..76ce14c32d
--- /dev/null
+++ b/doc/devblog/day_132__database_musings.mdwn
@@ -0,0 +1,17 @@
+Updated the Debian stable backport to the last release. Also it seems that
+the last release unexpectedly fixed XMPP SIGILL on some OSX machines.
+Apparently when I rebuilt all the libraries recently, it somehow fixed that
+[[old_unsolved_bug|bugs/Share_with_friends_crash_in_osx]].
+
+[RichiH](http://richardhartmann.de/) suggested "wrt ballooning memory on
+repair: can you read in broken
+stuff and simply stop reading once you reach a certain threshold, then
+start repairing, re-run fsck, etc?" .. I had considered that but was
+not sure it would work. I think I've gotten it to work.
+
+Now working on a design for using a [[design/caching_database]]
+for some parts of git-annex. My initial benchmarks using SQLite
+indicate it would slow down associated file lookups by nearly an order of
+magnitude compared with the current ".map files" implementation.
+(But would scale better in edge cases). OTOH, using a SQLite
+database to index metadata for use in views looks very promising.
diff --git a/doc/devblog/day_133__db_and_bugfixes.mdwn b/doc/devblog/day_133__db_and_bugfixes.mdwn
new file mode 100644
index 0000000000..5ba1df20e6
--- /dev/null
+++ b/doc/devblog/day_133__db_and_bugfixes.mdwn
@@ -0,0 +1,20 @@
+Did some more exploration and perf tuning and thinking on caching
+databases, and am pretty sure I know how I want to implement it. Will be
+several stages, starting with using it for generating views, and ending(?)
+with using it for direct mode file mappings.
+
+Not sure I'm ready to dive into that yet, so instead spent the rest of the
+day working on small bugfixes and improvements. Only two significant ones..
+
+Made the webapp use a constant time string comparison (from `securemem`)
+to check if its auth token is valid. This could help avoid a potential
+timing attack to guess the auth token, although that is theoretical.
+Just best practice to do this.
+
+Seems that openssh 6.5p1 had another hidden surprise (in addition to
+its now-fixed bug in handing hostnames in `.ssh/config`) -- it broke
+the method git-annex was using for stopping a cached ssh connection,
+which led to some timeouts for failing DNS lookups. If git-annex seems
+to stall for a few seconds at startup/shutdown, that may be why
+(--debug will say for sure). I seem to have found a workaround that
+avoids this problem.
diff --git a/doc/devblog/day_134-135__avoiding_the_turing_tarpit.mdwn b/doc/devblog/day_134-135__avoiding_the_turing_tarpit.mdwn
new file mode 100644
index 0000000000..d18470ae03
--- /dev/null
+++ b/doc/devblog/day_134-135__avoiding_the_turing_tarpit.mdwn
@@ -0,0 +1,18 @@
+Added some power and convenience to [[preferred_content]] expressions.
+
+Before, "standard" was a special case. Now it's a first-class keyword,
+so you can do things like "standard or present" to use the standard
+preferred content expression, modified to also want any file that happens
+to be present.
+
+Also added a way to write your own reusable preferred content expressions,
+tied to groups. To make a repository use them, set its preferred 
+content to "groupwanted". Of course, "groupwanted" is also a first-class
+keyword, so "not groupwanted" or something can also be done.
+
+While I was at it, I made `vicfg` show the built-in standard preferred
+content expressions, for reference. This little IDE should be pretty
+self-explanatory, I hope.
+
+So, preferred content is almost its own little programming language now.
+Except I was careful to not allow recursion. ;)
diff --git a/doc/devblog/day_136__frustrating_day.mdwn b/doc/devblog/day_136__frustrating_day.mdwn
new file mode 100644
index 0000000000..9088093d4a
--- /dev/null
+++ b/doc/devblog/day_136__frustrating_day.mdwn
@@ -0,0 +1,10 @@
+The website broke and I spent several hours fixing it, changing the
+configuration to not let it break like this again, cleaning up after it,
+etc.
+
+Did manage to make a few minor bugfixes and improvements, but nothing
+stunning.
+
+----
+
+I'll be attending LibrePlanet at MIT this weekend.
diff --git a/doc/devblog/day_137-138__bug_triage_and_too_much_windows.mdwn b/doc/devblog/day_137-138__bug_triage_and_too_much_windows.mdwn
new file mode 100644
index 0000000000..28b197356b
--- /dev/null
+++ b/doc/devblog/day_137-138__bug_triage_and_too_much_windows.mdwn
@@ -0,0 +1,15 @@
+Yesterday, worked on cleaning up the todo list. Fixed Windows slash problem
+with rsync remotes. Today, more Windows work; it turns out to have been
+quite buggy in its handling of non-ASCII characters in filenames. Encoding
+stuff is never easy for me, but I eventually managed to find a way to fix
+that, although I think there are other filename encoding problems lurking
+in git-annex on Windows still to be dealt with.
+
+Implemented an interesting metadata feature yesterday. It turns out that
+metadata can have metadata. Particularly, it can be useful to know when a
+field was last set. That was already beeing tracked, internally (to make
+union merging work), so I was able to quite cheaply expose it as
+"$field-lastchanged" metadata that can be used like any other metadata.
+
+I've been thinking about how to implement [[todo/required_content]]
+expressions, and think I have a reasonably good handle on it.
diff --git a/doc/devblog/day_139-140__traveling.mdwn b/doc/devblog/day_139-140__traveling.mdwn
new file mode 100644
index 0000000000..3025e45b5c
--- /dev/null
+++ b/doc/devblog/day_139-140__traveling.mdwn
@@ -0,0 +1,17 @@
+Yesterday coded up one nice improvement on the plane -- `git annex unannex`
+(and `uninit`) is now tons faster. Before it did a git commit after every
+file processed, now there's just 1 commit at the end. This required using
+some locking to prevent the `pre-commit` hook from running in a confusing
+state.
+
+Today. LibrePlanet and a surprising amount of development. I've
+added [[tips/file_manager_integration]], only for Nautilus so far.
+The main part of this was adding --notify-start and --notify-finish, which
+use dbus desktop notifications to provide feedback. 
+
+(Made possible thanks to Max Rabkin for updating
+[fdo-notify](http://hackage.haskell.org/package/fdo-notify) to use the
+new dbus library, and ion for developing the initial Nautilus integration
+scripts.)
+
+Today's work and LibrePlanet visit was sponsored by Jürgen Lüters.
diff --git a/doc/devblog/day_13__encrypted_sneakernet_working.mdwn b/doc/devblog/day_13__encrypted_sneakernet_working.mdwn
new file mode 100644
index 0000000000..777da255a2
--- /dev/null
+++ b/doc/devblog/day_13__encrypted_sneakernet_working.mdwn
@@ -0,0 +1,13 @@
+Spent basically all of today getting the assistant to be able to handle
+gcrypt special remotes that already exist when it's told to add a USB
+drive. This was quite tricky! And I did have to skip handling gcrypt repos
+that are not git-annex special remotes.
+
+Anyway, it's now almost easy to set up an encrypted sneakernet 
+using a USB drive and some computers running the webapp. The only part
+that the assistant doesn't help with is gpg key management.
+
+Plan is to make a release on Friday, and then try to also add support for
+encrypted git repositories on remote servers. Tomorrow I will try to get
+through some of the communications backlog that has been piling up while I
+was head down working on gcrypt.
diff --git a/doc/devblog/day_141__f-droid_sprint.mdwn b/doc/devblog/day_141__f-droid_sprint.mdwn
new file mode 100644
index 0000000000..2a9e30b553
--- /dev/null
+++ b/doc/devblog/day_141__f-droid_sprint.mdwn
@@ -0,0 +1,3 @@
+Attended at the f-droid sprint at LibrePlanet, and have been getting a
+handle on how their build server works with an eye toward adding git-annex
+to it. Not entirely successful getting vagrant to build an image yet.
diff --git a/doc/devblog/day_141__f-droid_sprint/comment_1_1cc76207020ac478747117c76d7b5f9c._comment b/doc/devblog/day_141__f-droid_sprint/comment_1_1cc76207020ac478747117c76d7b5f9c._comment
new file mode 100644
index 0000000000..9971f33da5
--- /dev/null
+++ b/doc/devblog/day_141__f-droid_sprint/comment_1_1cc76207020ac478747117c76d7b5f9c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmJuOOkYYguRbWhXzxihIPBavxITJIMyww"
+ nickname="Matt"
+ subject="Excellent News"
+ date="2014-03-26T14:14:35Z"
+ content="""
+It will be great to see git-annex on f-droid!
+"""]]
diff --git a/doc/devblog/day_142__digging_out.mdwn b/doc/devblog/day_142__digging_out.mdwn
new file mode 100644
index 0000000000..fc2ceea365
--- /dev/null
+++ b/doc/devblog/day_142__digging_out.mdwn
@@ -0,0 +1,13 @@
+Catching up on conference backlog. 36 messages backlog remains.
+
+Fixed `git-annex-shell configlist` to automatically initialize a
+git remote when a git-annex branch had been pushed to it. This is necessary
+for gitolite to be easy to use, and I'm sure it used to work.
+
+Updated the Debian backport and made a Debian package of the
+fdo-notify haskell library used for notifications.
+
+Applied a patch from Alberto Berti to fix support for tahoe-lafs
+1.10.
+
+And various other bug fixes and small improvements.
diff --git a/doc/devblog/day_143__foolish_hiatus.mdwn b/doc/devblog/day_143__foolish_hiatus.mdwn
new file mode 100644
index 0000000000..f6763dff30
--- /dev/null
+++ b/doc/devblog/day_143__foolish_hiatus.mdwn
@@ -0,0 +1,20 @@
+Last week's trip was productive, but I came home more tired than I
+realized. Found myself being snappy & stressed, so I have been on break.
+
+I did do a little git-annex dev in the past 5 days. On Saturday I
+implemented [[todo/preferred_content]] (although without the active checks
+I think it probably ought to have.) Yesterday I had a long conversation
+with the Tahoe developers about improving git-annex's tahoe integration.
+
+Today, I have been wrapping up [building propellor](http://joeyh.name/code/propellor/).
+To test its docker support, I used propellor to build and deploy a
+container that is a git-annex autobuilder. I'll be replacing the old
+autobuilder setup with this shortly, and expect to also publish docker
+images for git-annex autobuilders, so anyone who wants to can run their
+own autobuilder really easily.
+
+---
+
+I have April penciled in on the roadmap as the month to do telehash.
+I don't know if telehash-c is ready for me yet, but it has had a lot of
+activity lately, so this schedule may still work out!
diff --git a/doc/devblog/day_144__catching_up.mdwn b/doc/devblog/day_144__catching_up.mdwn
new file mode 100644
index 0000000000..52e25f0d58
--- /dev/null
+++ b/doc/devblog/day_144__catching_up.mdwn
@@ -0,0 +1,12 @@
+Got caught up on all recent bugs and questions, although I still have a
+backlog of 27 older things that I really should find time for.
+
+Fixed a couple of bugs. One was that the assistant set up ssh
+`authorized_keys` that didn't work with the fish shell.
+
+Also got caught up on the current state of telehash-c. Have not quite
+gotten it to work, but it seems pretty close to being able to see it do
+something useful for the first time.
+
+Pushing out a release this evening with a good number of changes left over
+from March.
diff --git a/doc/devblog/day_144__catching_up/comment_1_311a7245dd12f1a7e432168d16041348._comment b/doc/devblog/day_144__catching_up/comment_1_311a7245dd12f1a7e432168d16041348._comment
new file mode 100644
index 0000000000..f13ed82ae3
--- /dev/null
+++ b/doc/devblog/day_144__catching_up/comment_1_311a7245dd12f1a7e432168d16041348._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="70.82.37.38"
+ subject="comment 1"
+ date="2014-04-02T21:28:15Z"
+ content="""
+awesome! can't wait to see telehash land! :)
+"""]]
diff --git a/doc/devblog/day_145__a_plan.mdwn b/doc/devblog/day_145__a_plan.mdwn
new file mode 100644
index 0000000000..5f18ab8064
--- /dev/null
+++ b/doc/devblog/day_145__a_plan.mdwn
@@ -0,0 +1,16 @@
+I have a plan for this month. While waiting for telehash, I am going to
+build [[design/git-remote-daemon]], which is the infrastructure git-annex
+will need, to use telehash. Since it's generalized to support other protocols,
+I'll be able to start using it before telehash is ready.
+
+In fact, I plan to first make it work with ssh:// remotes, where
+it will talk with git-annex-shell on the remote server. This will let the
+assistant immediately know when the server has received a commit, and that
+will simplify using the assistant with a ssh server -- no more need for
+XMPP in this case! It should also work with git-remote-gcrypt encrypted
+repositories, so also covers the case of an untrusted ssh server where
+everything is end-to-end encrypted.
+
+Building the git-annex-shell part of this should be pretty easy, and
+building enough of the [[design/git-remote-daemon]] design to support it
+also not hard.
diff --git a/doc/devblog/day_145__a_plan/comment_1_c0ceea77443be1172527ed8549f000a4._comment b/doc/devblog/day_145__a_plan/comment_1_c0ceea77443be1172527ed8549f000a4._comment
new file mode 100644
index 0000000000..6bcc18bc2a
--- /dev/null
+++ b/doc/devblog/day_145__a_plan/comment_1_c0ceea77443be1172527ed8549f000a4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="2001:1928:1:9::1"
+ subject="look at mosh"
+ date="2014-04-04T14:07:51Z"
+ content="""
+you may want to look at how \"mosh\" handles authentication: http://mosh.mit.edu/
+
+from what i understand, it negociates an authentication token using SSH and then uses that to encrypt and authenticate UDP traffic. seems like similar issues here...
+"""]]
diff --git a/doc/devblog/day_146__halfway_to_git-remote-daemon.mdwn b/doc/devblog/day_146__halfway_to_git-remote-daemon.mdwn
new file mode 100644
index 0000000000..977123f55a
--- /dev/null
+++ b/doc/devblog/day_146__halfway_to_git-remote-daemon.mdwn
@@ -0,0 +1,17 @@
+Added `git-annex-shell notifychanges` command, which uses inotify (etc)
+to detect when git refs have changed, and informs the caller about the
+changes. This was relatively easy to write; I reused the existing inotify
+code, and factored out code for simple line-based protocols from the
+external special remote protocol. Also implemented the git-remote-daemon
+protocol. 200 lines of code total.
+
+Meanwhile, Johan Kiviniemi improved the dbus notifications, making them
+work on Ubuntu and adding icons. Awesome!
+
+There's going to be some fun to get git-annex-shell upgraded so that the
+assistant can use this new notify feaure. While I have not started working
+on the assistant side of this, you can get a jump by installing today's
+upcoming release of git-annex. I had to push this out early because there
+was a bug that prevented the webapp from running on non-gnome systems. Since
+all changes in this release only affected Linux, today's release will be a
+Linux-only release.
diff --git a/doc/devblog/day_147__git-annex_remotedaemon.mdwn b/doc/devblog/day_147__git-annex_remotedaemon.mdwn
new file mode 100644
index 0000000000..0e500ec406
--- /dev/null
+++ b/doc/devblog/day_147__git-annex_remotedaemon.mdwn
@@ -0,0 +1,5 @@
+Built `git-annex remotedaemon` command today. It's buggy, but it already
+works! If you have a new enough git-annex-shell on a remote server, you can
+run "git annex remotedaemon" in a git-annex repository, and it will notice
+any pushes that get made to that remote from any other clone, and pull down
+the changes.
diff --git a/doc/devblog/day_148__too_many_documents.mdwn b/doc/devblog/day_148__too_many_documents.mdwn
new file mode 100644
index 0000000000..3cb5e5baf8
--- /dev/null
+++ b/doc/devblog/day_148__too_many_documents.mdwn
@@ -0,0 +1,8 @@
+Various bug triage today. Was not good for much after shuffling paper for
+the whole first part of the day, but did get a few little things done.
+
+Re <http://heartbleed.com/>, git-annex does not use OpenSSL itself,
+but when using XMPP, the remote server's key could have been intercepted
+using this new technique. Also, the git-annex autobuilds and this website
+are served over https -- working on generating new https certificates now.
+Be safe out there..
diff --git a/doc/devblog/day_149__remote_control_working.mdwn b/doc/devblog/day_149__remote_control_working.mdwn
new file mode 100644
index 0000000000..56c108b7b7
--- /dev/null
+++ b/doc/devblog/day_149__remote_control_working.mdwn
@@ -0,0 +1,15 @@
+[[design/git-remote-daemon]] is tied into the assistant, and working!
+Since it's not really ready yet, this is in the `remotecontrol` branch.
+
+My test case for this is two client repositories, both running
+the assistant. Both have a bare git repository, accessed over ssh,
+set up as their only remote, and no other way to keep in touch with
+one-another. When I change a file in one repository,
+the other one instantly notices the change and syncs.
+
+This is gonna be *awesome*. Much less need for XMPP. Windows will be fully
+usable even without XMPP. Also, most of the work I did today will be fully
+reused when the telehash backend gets built. The telehash-c developer is
+making noises about it being almost ready for use, too!
+
+Today's work was sponsored by Frédéric Schütz.
diff --git a/doc/devblog/day_149__signal.mdwn b/doc/devblog/day_149__signal.mdwn
new file mode 100644
index 0000000000..2bcb01a728
--- /dev/null
+++ b/doc/devblog/day_149__signal.mdwn
@@ -0,0 +1,16 @@
+[[!meta title="day 150 signal"]]
+
+The git-remote-daemon now robustly handles loss of signal, with
+reconnection backoffs. And it detects if the remote ssh server has too
+old a version of git-annex-shell and the webapp will display a warning
+message.
+
+[[!img /assistant/connection.png]]
+
+Also, made the webapp show a network signal bars icon next to both
+ssh and xmpp remotes that it's currently connected with. And, updated the
+webapp's nudging to set up XMPP to now suggest either an XMPP or a ssh remote.
+
+I think that the `remotecontrol` branch is nearly ready for merging!
+
+Today's work was sponsored by Paul Tagliamonte.
diff --git a/doc/devblog/day_14__gcrypt_refinements_and_OOM_fixes.mdwn b/doc/devblog/day_14__gcrypt_refinements_and_OOM_fixes.mdwn
new file mode 100644
index 0000000000..2ff1d16dda
--- /dev/null
+++ b/doc/devblog/day_14__gcrypt_refinements_and_OOM_fixes.mdwn
@@ -0,0 +1,26 @@
+Spent a few hours improving gcrypt in some minor ways, including adding a
+--check option that the assistant can use to find out if a given repo is
+encrypted with dgit, and also tell if the necessary gpg key is available to
+decrypt it. Also merged in a fix to support subkeys, developed by a
+git-annex user who is the first person I've heard from who is using gcrypt.
+I don't want to maintain gcrypt, so I am glad its author has shown up
+again today.
+
+Got mostly caught up on backlog. The main bug I was able to track down
+today is git-annex using a lot of memory in certian repositories. This
+turns out to have happened when a really large file was committed right
+intoo to the git repository (by mistake or on purpose). Some parts of
+git-annex buffer file contents in memory while trying to work out if
+they're git-annex keys. Fixed by making it first check if a file in git is
+marked as a symlink. Which was really hard to do!
+
+At least 4 people ran into this bug, which makes me suspect that lots of
+people are messing up when using direct mode (probably due to not reading
+the documentation, or having `git commit -a` hardwired into their fingers,
+and forcing git to commit large files into their repos, rather than having
+git-annex manage them. Implementing [[todo/direct_mode_guard]] seems more
+urgent now.
+
+----
+
+Today's work was sponsored by Amitai Schlair.
diff --git a/doc/devblog/day_15-17__Android_rebuild.mdwn b/doc/devblog/day_15-17__Android_rebuild.mdwn
new file mode 100644
index 0000000000..758e2d0977
--- /dev/null
+++ b/doc/devblog/day_15-17__Android_rebuild.mdwn
@@ -0,0 +1,67 @@
+Made a release on Friday. But I had to rebuild the OSX and Linux standalone
+builds today to fix a bug in them.
+
+Spent the past **three days** redoing the whole Android build environment.
+I've been progressively moving from my first hacked up Android build env to
+something more reproducible and sane. Finally I am at the point where I can
+run a shell script (well, actually, 3 shell scripts) and get an Android
+build chroot. It's still not immune to breaking when new versions of
+haskell libs are uploaded, but this is much better, and should be
+maintainable going forward. 
+
+This is a good starting point for getting git-annex into the F-Droid app
+store, or for trying to build with a newer version of the Android SDK and
+NDK, to perhaps get it working on Android 4.3. (Eventually. I am so sick
+of building Android stuff right now..)
+
+Friday was all spent struggling to get ghc-android to build. I had not built
+it successfully since February. I finally did,
+on Saturday, and I have made my own fork of it which builds using a
+known-good snapshot of the current development version of ghc. Building
+this in a Debian stable chroot means that there should be no possibility
+that upstream changes will break the build again.
+
+With ghc built, I moved on to building all the haskell libs git-annex
+needs. Unfortunately my build script for these also has stopped working
+since I made it in April. I failed to pin every package at a defined
+version, and things broke.
+
+So, I redid the build script, and updated all the haskell libs to the
+newest versions while I was at it. I have decided not to pin the library
+versions (at least until I find a foolproof way to do it), so this new
+script will break in the future, but it should break in a way I can fix up
+easily by just refreshing a patch.
+
+The new ghc-android build has a nice feature of at least being able to
+compile Template Haskell code (though still not run it at compile time.
+This made the patching needed in the Haskell libs quite a lot less. Offset
+somewhat by me needing to make general fixes to lots of libs to build with
+ghc head. Including some fun with `==#` changing its type from `Bool` to
+`Int#`. In all, I think I removed around 2.5 thousand lines of patches!
+(Only 6 thousand lines to go...)
+
+Today I improved ghc-android some more so it cross builds several C libraries
+that are needed to build several haskell libraries needed for XMPP.
+I had only ever built those once, and done it by hand, and very hackishly.
+Now they all build automatically too.
+
+And, I put together a script that builds the debian stable chroot and
+installs ghc-android.
+
+And, I hacked on the EvilSplicer (which is sadly still needed) to
+work with the new ghc/yesod/etc.
+
+At this point, I have git-annex successfully building, including the APK!
+
+----
+
+In a bored hour waiting for a compile, I also sped up `git annex add`
+on OSX by I think a factor of 10. Using cryptohash for hash calculation
+now, when external hash programs are not available. It's still a few
+percentage points slower than external hash programs, or I'd use it by
+default.
+
+----
+
+This period of important drudgery was sponsored by an unknown bitcoin
+user, and by Bradley Unterrheiner and Andreas Olsson.
diff --git a/doc/devblog/day_151__birthday_bug.mdwn b/doc/devblog/day_151__birthday_bug.mdwn
new file mode 100644
index 0000000000..251bfb935f
--- /dev/null
+++ b/doc/devblog/day_151__birthday_bug.mdwn
@@ -0,0 +1,18 @@
+Pushed out a new release today, fixing two important bugs, followed by a
+second release which fixed the bugs harder.
+
+Automatic upgrading was broken on OSX. The webapp will tell you upgrading
+failed, and you'll need to manually download the .dmg and install it.
+
+With help from Maximiliano Curia, finally tracked down a bug I have been
+chasing for a while where the assistant would start using a lot of CPU
+while not seeming to be busy doing anything. Turned out to be triggered by
+a scheduled fsck that was configured to run once a month with no particular
+day specified.
+
+That bug turned out to affect users who first scheduled such a fsck job
+after the 11th day of the month. So I expedited putting a release out to
+avoid anyone else running into it starting tomorrow.
+
+(Oddly, the 11th day of this month also happens to be my birthday. I did not
+expect to have to cut 2 releases today..)
diff --git a/doc/devblog/day_152__more_ssh_connection_caching.mdwn b/doc/devblog/day_152__more_ssh_connection_caching.mdwn
new file mode 100644
index 0000000000..ad472b5e55
--- /dev/null
+++ b/doc/devblog/day_152__more_ssh_connection_caching.mdwn
@@ -0,0 +1,37 @@
+Made ssh connection caching be used in several more places. `git annex
+sync` will use it when pushing/pulling to a remote, as will the assistant.
+And `git-annex remotedaemon` also uses connection caching. So, when
+a push lands on a ssh remote, the assistant will immediately notice it, and
+pull down the change over the same TCP connection used for the
+notifications.
+
+This was a bit of a pain to do. Had to set `GIT_SSH=git-annex` and then
+when git invokes git-annex as ssh, it runs ssh with the connection caching
+parameters.
+
+Also, improved the network-manager and wicd code, so it detects when a
+connection has gone down. That propagates through to the remote-daemon,
+which closes all ssh connections. I need to also find out how to detect
+network connections/disconnections on OSX..
+
+Otherwise, the remote-control branch seems ready to be merged. But I want
+to test it for a while first.
+
+----
+
+Followed up on yesterday's bug with writing some test cases for
+Utility.Scheduled, which led to some more bug fixes. Luckily nothing
+I need to rush out a release over. In the end, the code got a lot
+simpler and clearer.
+
+[[!format haskell """
+-- Check if the new Day occurs one month or more past the old Day.
+oneMonthPast :: Day -> Day -> Bool
+new `oneMonthPast` old = fromGregorian y (m+1) d <= new
+  where
+        (y,m,d) = toGregorian old
+"""]]
+
+-------
+
+Today's work was sponsored by Asbjørn Sloth Tønnesen.
diff --git a/doc/devblog/day_153__remotedaemon_has_landed.mdwn b/doc/devblog/day_153__remotedaemon_has_landed.mdwn
new file mode 100644
index 0000000000..5033b32b25
--- /dev/null
+++ b/doc/devblog/day_153__remotedaemon_has_landed.mdwn
@@ -0,0 +1,10 @@
+After fixing a few bugs in the `remotecontrol` branch, It's landed in
+`master`. Try a daily build today, and see if the assistant can keep in
+sync using nothing more than a remote ssh repository!
+
+So, now all the groundwork for telehash is laid too. I only need a
+telehash library to start developing on top of. Development on telehash-c
+is continuing, but I'm more excited that
+[htelehash](https://github.com/alanz/htelehash/tree/v2) 
+has been revived and is being updated to the v2 protocol, seemingly quite
+quickly.
diff --git a/doc/devblog/day_153__remotedaemon_has_landed/comment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment b/doc/devblog/day_153__remotedaemon_has_landed/comment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment
new file mode 100644
index 0000000000..5ff090ffde
--- /dev/null
+++ b/doc/devblog/day_153__remotedaemon_has_landed/comment_1_f19ae6b3d6f33a68e4ffe0c32f788745._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkC0W3ZQERUaTkHoks6k68Tsp1tz510nGo"
+ nickname="Georg"
+ subject=" remotedaemon in pre-built tarballs"
+ date="2014-04-17T07:40:25Z"
+ content="""
+Hi Joey,
+
+can you tell me when the pre-built Linux tarballs will include the remotedaemon?
+Are they updated on a daily basis?
+
+Best regards, Georg
+"""]]
diff --git a/doc/devblog/day_153__remotedaemon_has_landed/comment_2_fbf0c50f772e958af638d2b72dac73f5._comment b/doc/devblog/day_153__remotedaemon_has_landed/comment_2_fbf0c50f772e958af638d2b72dac73f5._comment
new file mode 100644
index 0000000000..5f81fde5cf
--- /dev/null
+++ b/doc/devblog/day_153__remotedaemon_has_landed/comment_2_fbf0c50f772e958af638d2b72dac73f5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 2"
+ date="2014-04-17T19:31:30Z"
+ content="""
+The daily builds are updated on a daily basis, so already include it.
+
+The release builds are updated on each release, and so do not.
+"""]]
diff --git a/doc/devblog/day_154__catching_up.mdwn b/doc/devblog/day_154__catching_up.mdwn
new file mode 100644
index 0000000000..7c49a788e2
--- /dev/null
+++ b/doc/devblog/day_154__catching_up.mdwn
@@ -0,0 +1,13 @@
+Worked through message backlog today. Got it down from around 70 to just
+37. Was able to fix some bugs, including making the webapp start up more
+robustly in some misconfigurations.
+
+Added a new `findref` command which may be useful in a git `update` hook to
+deny pushes of refs if the annexed content has not been sent first.
+
+----
+
+BTW, I also added a new `reinit` command a few days ago, which can be
+useful if you're cloning back a deleted repository.
+
+Also a few days ago, I made `uninit` a *lot* faster.
diff --git a/doc/devblog/day_155__missing_bits.mdwn b/doc/devblog/day_155__missing_bits.mdwn
new file mode 100644
index 0000000000..aa8fd9d4ee
--- /dev/null
+++ b/doc/devblog/day_155__missing_bits.mdwn
@@ -0,0 +1,27 @@
+Sometimes you don't notice something is missing for a long time until
+it suddenly demands attention. Like today.
+
+Seems the webapp never had a way to stop using XMPP and delete the XMPP
+password. So I added one.
+
+The new support for instantly noticing changes on a ssh remote forgot to
+start up a connection to a new remote after it was created. Fixed that.
+
+(While doing some testing on Android for unrelated reasons, I noticed that
+my android tablet was pushing photos to a ssh server and my laptop
+immediately noticed and downloaded them from tere, which is an excellent
+demo. I will deploy this on my trip in Brazil next week. Yes, I'm spending
+2 weeks in Brazil with git-annex users; more on this later.)
+
+Finally, it turns out that "installing" git-annex from the standalone
+tarball, or DMG, on a server didn't make it usable by the webapp. Because
+git-annex shell is not in PATH on the server, and indeed git and rsync may
+not be in PATH either if they were installed with the git-annex bundle.
+Fixed this by making the bundle install a ~/.ssh/git-annex-wrapper, which 
+the webapp will detect and use.
+
+Also, quite a lot of other bug chasing activity.
+
+----
+
+Today's work was sponsored by Thomas Koch.
diff --git a/doc/devblog/day_155__missing_bits/comment_1_76424498600ba603946035efffb88023._comment b/doc/devblog/day_155__missing_bits/comment_1_76424498600ba603946035efffb88023._comment
new file mode 100644
index 0000000000..d9ee528e0a
--- /dev/null
+++ b/doc/devblog/day_155__missing_bits/comment_1_76424498600ba603946035efffb88023._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 1"
+ date="2014-04-20T23:58:51Z"
+ content="""
+thanks!
+"""]]
diff --git a/doc/devblog/day_156__release_day.mdwn b/doc/devblog/day_156__release_day.mdwn
new file mode 100644
index 0000000000..7a312b234e
--- /dev/null
+++ b/doc/devblog/day_156__release_day.mdwn
@@ -0,0 +1,14 @@
+I hope this will be a really good release. Didn't get all the way to
+[[design/assistant/telehash]] this month, but the remotedaemon is pretty sweet. Updated [[design/roadmap]]
+pushes telehash back again.
+
+The files in this release are now gpg signed, after recently moving the
+downloads site to a dedicated server, which has a dedicated gpg key.
+You can verify the detached signatures as an additional security check
+over trusting SSL. The automatic upgrade code doesn't check the gpg
+signatures yet.
+
+Sören Brunk has ported the webapp to Bootstrap 3.
+<https://github.com/brunksn/git-annex/tree/bootstrap3>  
+The branch is not ready for merging yet (it would break the Debian stable
+backports), but that was a nice surprise.
diff --git a/doc/devblog/day_157__upgrade_checking.mdwn b/doc/devblog/day_157__upgrade_checking.mdwn
new file mode 100644
index 0000000000..ff70b80939
--- /dev/null
+++ b/doc/devblog/day_157__upgrade_checking.mdwn
@@ -0,0 +1,22 @@
+Now git-annex's self-upgrade code will check the gpg signature of a
+new version before using it.
+
+To do this I had to include the gpg public keys into the
+git-annex distribution, and that raised the question of which public keys
+to include. Currently I have both the dedicated git-annex distribution
+signing key, and my own gpg key as a backup in case I somehow misplace the
+former.
+
+Also spent a while looking at the recent logs on the web server. There
+seem to be around 600 users of the assistant with
+upgrade checking enabled. That breaks down to 68% Linux amd64, 20% Linux
+i386, 11% OSX Mavericks, and 0.5% OSX Lion.
+
+Most are upgrading successfully, but there are a few that seem to
+repeatedly fail for some reason. (Not counting the OSX Lion, which will
+probably never find an upgrade available.) I hope that someone who is
+experiencing an upgrade failure gets in touch with some debug logs.
+
+In the same time period, around 450 unique hosts manually downloaded a
+git-anex distribution. Also compare with Debian popcon, which has 1200
+reporting git-annex users.
diff --git a/doc/devblog/day_158__enroute_to_Brazil.mdwn b/doc/devblog/day_158__enroute_to_Brazil.mdwn
new file mode 100644
index 0000000000..cd9830f2ee
--- /dev/null
+++ b/doc/devblog/day_158__enroute_to_Brazil.mdwn
@@ -0,0 +1,10 @@
+Next month the roadmap has me working on [[design/assistant/sshpassword]].
+That will be a nice UI improvement and I'd be very surprised if it takes
+more than a week, which is great.
+
+Getting a jump on it today, investigating using `SSH_ASKPASS`. It seems this
+will even work on Windows! Preliminary design in [[design/assistant/sshpassword]].
+
+Time to get on a plane to a plane to a plane to Brasilia!
+
+[[!meta date="Fri, 25 Apr 2014 16:32:36 -0400"]]
diff --git a/doc/devblog/day_159__tmp_file_cleanup.mdwn b/doc/devblog/day_159__tmp_file_cleanup.mdwn
new file mode 100644
index 0000000000..d1ef58109f
--- /dev/null
+++ b/doc/devblog/day_159__tmp_file_cleanup.mdwn
@@ -0,0 +1,12 @@
+Today was mostly spent driving across Brazil, but I had energy this evening
+for a little work on git-annex.
+
+Made the assistant delete old temporary files on startup. I've had
+scattered reports of a few users whose `.git/annex/tmp` contained many
+files, apparently put there by the assistant when it locks down a file
+prior to annexing it. That seems it could possibly be a bug -- or it could
+just be unclean shutdowns interrupting the assistant. Anyway, this will
+deal with any source of tmp cruft, and I made sure to preserve
+tmp files for partially downloaded content.
+
+[[!meta date="Sun, 27 Apr 2014 22:12:55 -0300"]]
diff --git a/doc/devblog/day_160__.mdwn b/doc/devblog/day_160__.mdwn
new file mode 100644
index 0000000000..2c20d2f0d8
--- /dev/null
+++ b/doc/devblog/day_160__.mdwn
@@ -0,0 +1,20 @@
+Reviewed Sören's updated bootstrap3 patch, which appeared while I was
+[traveling](http://joeyh.name/blog/entry/the_real_Brazil/). Sören
+kindly fixed it to work with Debian stable's old version of Yesod,
+which was quite a lot of work. The new new bootstrap3 UI looks nice,
+found a few minor issues, but expect to be able to merge it soon.
+
+Started on [[design/assistant/sshpassword]] groundwork. Added a simple
+password cache to the assistant, with automatic expiration, and made
+git-annex be able to be run by ssh as the `SSH_ASKPASS` program.
+
+The main difficulty will be changing the webapp's UI to prompt for the ssh
+password when one is needed. There are several code paths in ssh remote
+setup where a password might be needed. Since the cached password expires,
+it may need to be prompted for at any of those points. Since a new page is
+loading, it can't pop up a prompt on the current page; it needs to redirect
+to a password prompt page and then redirect back to the action that needed
+the password. ...At least, that's one way to do it.
+I'm going to sleep on it and hope I dream up a better way.
+
+[[!meta date="Tue, 29 Apr 2014 18:33:53 -0400"]]
diff --git a/doc/devblog/day_161__routing_design.mdwn b/doc/devblog/day_161__routing_design.mdwn
new file mode 100644
index 0000000000..9c9e65d171
--- /dev/null
+++ b/doc/devblog/day_161__routing_design.mdwn
@@ -0,0 +1,13 @@
+I've moved out of implementation mode (unable to concentrate enough), and
+into high-level design mode.
+
+[[Syncing efficiency|design/assistant/syncing/efficiency]] has been an open TODO for years,
+to find a way to avoid flood filling the network, and find more efficient
+ways to ensure data only gets to the nodes that want it. Relatedly,
+Android devices  often need a way to mark individual files they want to have.
+Had a [very productive discussion with Vince and Fernao](http://joeyh.name/blog/entry/who_needs_whiteboards_when_you_have_strange_seed_pods_from_the_jungle/)
+and I think we're heading toward a design that will address both these
+needs, as well as some more Brazil-specific use cases, about which more
+later.
+
+Today's work was sponsored by Casa do Boneco.
diff --git a/doc/devblog/day_162__routing_sim_and_massive_contribution_landed.mdwn b/doc/devblog/day_162__routing_sim_and_massive_contribution_landed.mdwn
new file mode 100644
index 0000000000..a8f5313ac4
--- /dev/null
+++ b/doc/devblog/day_162__routing_sim_and_massive_contribution_landed.mdwn
@@ -0,0 +1,17 @@
+Sören Brunk's massive bootstrap 3 patch has landed! This is a 43 thousand
+line diff, with 2 thousand lines after the javascript and CSS libraries are
+filtered out. Either way, the biggest patch contributed by anyone to
+git-annex so far, and excellent work.
+
+Meanwhile, I built a [[haskell program|design/assistant/syncing/simroutes.hs]] to simulate
+a network of highly distributed git-annex nodes with ad-hoc connections and
+the selective file syncing algorythm now documented at the bottom of
+[[design/assistant/syncing/efficiency]].
+
+Currently around 33% of requested files never get to their destination
+in this simulation, but this is probably because its network is randomly
+generated, and so contains disconnected islands. So next, some data entry,
+from a map that involves an Amazon not in .com, dotted with names of people
+I have recently met... :)
+
+<a href="https://downloads.kitenet.net/git-annex/mapa/mapa.jpg"><img src="https://downloads.kitenet.net/git-annex/mapa/mapa.jpg" width=1024 height=768></a>
diff --git a/doc/devblog/day_163__request_and_routing_design.mdwn b/doc/devblog/day_163__request_and_routing_design.mdwn
new file mode 100644
index 0000000000..c11664a06f
--- /dev/null
+++ b/doc/devblog/day_163__request_and_routing_design.mdwn
@@ -0,0 +1,3 @@
+I have a preliminary design for [[design/requests_routing]]. Won't be
+working on it immediately, but simulations show it can work well in a large
+ad-hoc network.
diff --git a/doc/devblog/day_164__back.mdwn b/doc/devblog/day_164__back.mdwn
new file mode 100644
index 0000000000..48a6ce6f07
--- /dev/null
+++ b/doc/devblog/day_164__back.mdwn
@@ -0,0 +1,17 @@
+My backlog is massive -- 181 items to answer. Will probably take the rest
+of the month to get caught back up. Rather than digging into that yet,
+spent today working on the webapp's ssh password prompting. 
+
+I simplified it so the password is entered on the same form as the rest
+of the server's information. That made the UI easy to build, but
+means that when a user already has a ssh key they want to use, they need
+to select "existing ssh key"; the webapp no longer probes to automatically
+detect that case.
+
+Got the ssh password prompting in the webapp basically working, and it's a
+*really* nice improvement! I even got it to work on Windows (eventually...).
+It's still only in the `sshpassword` branch, since I need to test it more
+and probably fix some bugs. In particular, when enabling a remote that
+already exists, I think it never prompts for the password yet.
+
+Today's work was sponsored by Nicola Chiapolini.
diff --git a/doc/devblog/day_165__sshpassword_merged.mdwn b/doc/devblog/day_165__sshpassword_merged.mdwn
new file mode 100644
index 0000000000..4479df733e
--- /dev/null
+++ b/doc/devblog/day_165__sshpassword_merged.mdwn
@@ -0,0 +1,18 @@
+Spent the day testing the sshpasswd branch. A few interesting things:
+
+* I was able to get rid of 10 lines of Windows specific code for
+  rsync.net, which had been necessary for console ssh password prompting to
+  work. Yay!
+* git-remote-gcrypt turned out to be broken when there is no controlling
+  tty. --no-tty has to be passed to gpg to avoid it falling over in this
+  case, even when a gpg agent is available to be used. I fixed this with
+  a new release of git-remote-gcrypt.
+
+Mostly the new branch just worked! And is merged...
+
+Merged a patch from Robie Basak that adds a new special remote that's sort
+of like bup but supports deletion: [[special_remotes/ddar]]
+
+Backlog: 172
+
+Today's work was sponsored by Andrew Cant.
diff --git a/doc/devblog/day_166__catching_up.mdwn b/doc/devblog/day_166__catching_up.mdwn
new file mode 100644
index 0000000000..51878562e9
--- /dev/null
+++ b/doc/devblog/day_166__catching_up.mdwn
@@ -0,0 +1,40 @@
+Powered through the backlog today, and got it down to 67! Probably most of
+the rest is the hard ones though.
+
+A theme today was: It's stupid hard to get git-annex-shell installed into
+PATH. While that should be the simplest thing in the world, I'm pinned
+between two problems:
+
+1. There's no single portable package format, so all the decades of
+   development nice ways to get things into PATH don't work for everybody.
+2. bash provides not a single dotfile that will work in all circumstances
+   to configure PATH. In particular, "ssh $host git-annex-shell" causes bash
+   to helpfully avoid looking at any dotfiles at all.
+
+Today's flailing to work around that inluded:
+
+* Merged a patch from Fraser Tweedale to allow `git config remote.origin.annex-shell /not/in/path/git-annex-shell`
+* Merged a patch from Justin Lebar to allow symlinking the git-annex-shell
+  etc from the standalone tarball to a directory that is in PATH. (Only
+  on Linux, not OSX yet.)
+* Improved the warning message git-annex prints when a remote server does
+  not have git-annex-shell in PATH, suggesting some things the user could
+  do to try to fix it.
+
+I've found out why OSX machines were retrying upgrades repeatedly. The
+version in the .info file did not match the actual git-annex version for
+OSX. I've fixed the info file version, but will need to come up with a
+system to avoid such mismatches.
+
+Made a few other fixes. A notable one is that dragging and dropping
+repositories in the webapp to reorder the list (and configure costs)
+had been broken since November.
+
+git-annex 5.20140421 finally got into Debian testing today, so I updated
+the backport. I recommend upgrading, especially if you're using the
+assistant with a ssh remote, since you'll get all of last month's nice
+features that make XMPP unnecessary in that configuration.
+
+----
+
+Today's work was sponsored by Geoffrey Irving.
diff --git a/doc/devblog/day_167__growing_the_community_of_git-annex_contributors.mdwn b/doc/devblog/day_167__growing_the_community_of_git-annex_contributors.mdwn
new file mode 100644
index 0000000000..1408e13e2c
--- /dev/null
+++ b/doc/devblog/day_167__growing_the_community_of_git-annex_contributors.mdwn
@@ -0,0 +1,11 @@
+Released git-annex 5.20140517 today. The changelog for this release
+is very unusual, because it's full of contributions from others! There are
+as many patches from others in this release as git-annex got in the first
+entire two years of its existence.
+
+I'd like to keep that going. Also, I could really use help triaging bug
+reports right now. So I have updated the **[[contribute]]** page with more
+info about easy ways to contribute to git-annex. If you read this devblog,
+you're an ideal contributor, and you don't need to know how to write
+haskell either.. So take a [[look at the page|contribute]] and see if
+you can help out.
diff --git a/doc/devblog/day_168__backlog_continued.mdwn b/doc/devblog/day_168__backlog_continued.mdwn
new file mode 100644
index 0000000000..ab19565338
--- /dev/null
+++ b/doc/devblog/day_168__backlog_continued.mdwn
@@ -0,0 +1,16 @@
+Worked on triaging several bugs. Fixed an easy one, which involved the
+assistant choosing the wrong path to a repository that has multiple
+remotes. After today, backlog is down to 43, nearly pre-Brazil levels.
+
+It seems that git-remote-gcrypt [[never quite worked on OSX|bugs/remote_gcrypt_based_repos_and_conflicting_uuids]].
+It looked like it did, but a bug prevented anything being pushed to the remote.
+Tracked down and fixed that bug.
+
+This evening, getting back to working on the armel autobuilder setup
+using propellor. The autobuilder will use a pair of docker containers, one
+armel and a companion amd64, and their quite complex setup will be *almost*
+fully automated (except for the haskell library patching part).
+
+----
+
+Today's work was sponsored by Mica Semrick.
diff --git a/doc/devblog/day_169-171__juggling.mdwn b/doc/devblog/day_169-171__juggling.mdwn
new file mode 100644
index 0000000000..2b34da90ac
--- /dev/null
+++ b/doc/devblog/day_169-171__juggling.mdwn
@@ -0,0 +1,14 @@
+Keeping lots of things going these past few days..
+
+* Rebootstrapping the armel autobuilder with propellor. 
+  Some qemu instability and the need to update haskell
+  library patches meant this took a lot of hand-holding. Finally got a
+  working setup today.
+* Designing and ordering new git-annex stickers on clear viynl backing;
+  have put off sending those to campaign contributors for too long.
+* Added a new feature to the webapp: It now remembers the ssh remotes
+  that it sets up, and makes it easy to enable them elsewhere, the same
+  as other sorts of remotes. Had a very pleasant surprise building this,
+  when I was able to reuse all the UI code for enabling rsync and gcrypt
+  remotes. I think this will be a useful feature as we transition away
+  from XMPP.
diff --git a/doc/devblog/day_172__.mdwn b/doc/devblog/day_172__.mdwn
new file mode 100644
index 0000000000..7f2595cef9
--- /dev/null
+++ b/doc/devblog/day_172__.mdwn
@@ -0,0 +1,7 @@
+Working on moving the android autobuilder to Docker & Propellor, which will
+finish containerizing all the autobuilds that I run. Updated
+ghc-android to use the released ghc 7.8.2, which will make it build more
+reliably. 
+
+Also did bug triage. Bugs are now divided into [[bugs/confirmed]]
+and [[bugs/unconfirmed]] categories.
diff --git a/doc/devblog/day_173-174__android_rebootstrap.mdwn b/doc/devblog/day_173-174__android_rebootstrap.mdwn
new file mode 100644
index 0000000000..6029b1870f
--- /dev/null
+++ b/doc/devblog/day_173-174__android_rebootstrap.mdwn
@@ -0,0 +1,8 @@
+With some help from Sören, have been redoing the android build environment
+for git-annex. This included making propellor put it in a docker container,
+which was easy. But then much struggling with annoying stuff like getting
+the gnutls linking to work, and working around some dependency issues on
+hackage that make cabal's dependency resolver melt down.
+Finally succeeded after much more time than I had wanted to spend on this.
+
+[[!meta date="Mon May 27 16:36:40 JEST 2014"]]
diff --git a/doc/devblog/day_175__encoding_day.mdwn b/doc/devblog/day_175__encoding_day.mdwn
new file mode 100644
index 0000000000..5e23342d5c
--- /dev/null
+++ b/doc/devblog/day_175__encoding_day.mdwn
@@ -0,0 +1,20 @@
+These themed days are inaverdent, but it happened again: Nearly everything
+done today had to do with encoding issues.
+
+The big news is that it turned out everything written to files in the
+git-annex branch had unicode characters truncated to 8 bits. Now fixed so
+you should always get out the same thing you put in, no matter what
+encoding you use (but please use utf8). This affected things like storing
+repository descriptions, but worse, it affected metadata. (Also preferred
+content expressions, I suppose.)
+
+With that fixed, there are still 7 source files left that use Char8 libraries.
+There used to be more; nearly every use of those is a bug. I looked over
+the remaining uses of it, and there might be a problem with Creds using it.
+I should probably make a push to stamp out all remaining uses of Char8.
+
+Other encoding bugs were less reproducible.
+
+And just now, Sören made some progress on
+[[bugs/Bootstrap3_icons_missing_on_Android]] ... and my current theory
+is this is actually caused by an encoding issue too.
diff --git a/doc/devblog/day_176__mostly_a_day_off.mdwn b/doc/devblog/day_176__mostly_a_day_off.mdwn
new file mode 100644
index 0000000000..46bf1c4db1
--- /dev/null
+++ b/doc/devblog/day_176__mostly_a_day_off.mdwn
@@ -0,0 +1,8 @@
+Got a handle on the Android webapp static file problems (no, they were not
+really encoding problems!), and hopefully
+that's all fixed now. Also, only 3 modules use Char8 now. And updated the
+git-annex backport. That's all I did today.
+
+Meanwhile, a complete [[tips/ZSH_completion]] has been contributed by
+Schnouki. And, Ben Gamari sent in a patch moving from the deprecated 
+MonadCatchIO-transformers library to the exceptions library.
diff --git a/doc/devblog/day_177__enabling.mdwn b/doc/devblog/day_177__enabling.mdwn
new file mode 100644
index 0000000000..55a1895aaf
--- /dev/null
+++ b/doc/devblog/day_177__enabling.mdwn
@@ -0,0 +1,21 @@
+After making a release yesterday, I've been fixing some bugs in the
+webapp, all to do with repository configuration stored on the git-annex
+branch. I was led into this by a strange little bug where the webapp stored
+configuration in the wrong repo in one situation. From there, I noticed
+that often when enabling an existing repository, the webapp would stomp on
+its group and preferred content and description, replacing them with
+defaults.
+
+This was a systematic problem, it had to be fixed in several places. And
+some of the fixes were quite tricky. For example, when adding a ssh
+repository, and it turns out there's already a git-annex repository at the
+entered location, it needs to avoid changing its configuration. But also,
+the configuration of that repo won't be known until after the first git
+pull from it. So it doesn't make sense to show the repository edit form
+after enabling such a repository.
+
+Also worked on a couple other bugs, and further cleaned up the [[bugs]]
+page. I think I am finally happy with how the bug list is displayed,
+with confirmed/moreinfo/etc tags.
+
+Today's work was sponsored by François Deppierraz.
diff --git a/doc/devblog/day_177__enabling/comment_1_820d29f84dade09b0e7bb7435c52fcb8._comment b/doc/devblog/day_177__enabling/comment_1_820d29f84dade09b0e7bb7435c52fcb8._comment
new file mode 100644
index 0000000000..05ecdc32d1
--- /dev/null
+++ b/doc/devblog/day_177__enabling/comment_1_820d29f84dade09b0e7bb7435c52fcb8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2014-06-02T13:36:00Z"
+ content="""
+Can you make the tags be displayed with background colours or some other mechanism for quick visual recognition? All \"done\" are green, all \"moreinfo\" blue(?), etc pp.
+
+
+Thanks,
+Richard
+"""]]
diff --git a/doc/devblog/day_178-179__screencast_and_what_next.mdwn b/doc/devblog/day_178-179__screencast_and_what_next.mdwn
new file mode 100644
index 0000000000..fe7ba399da
--- /dev/null
+++ b/doc/devblog/day_178-179__screencast_and_what_next.mdwn
@@ -0,0 +1,12 @@
+Yesterday I recorded a new screencast, demoing using the assistant on a
+local network with a small server. [[videos/git-annex_assistant_lan]].
+That's the best screencast yet; having a real framing story was nice;
+recent improvements to git-annex are taken advantage of without being made
+a big deal; and audio and video are improved. (But there are some minor
+encoding glitches which I'd have to re-edit it to fix.)
+
+The [[design/roadmap]] has this month dedicated to improving Android.
+But I think what I'd more like to do is whatever makes the assistant usable
+by the most people. This might mean doing more on Windows, since I hear
+from many who would benefit from that. Or maybe something not related to
+porting?
diff --git a/doc/devblog/day_178-179__screencast_and_what_next/comment_1_eeba788fed45cb22f9cc2a738ceaa074._comment b/doc/devblog/day_178-179__screencast_and_what_next/comment_1_eeba788fed45cb22f9cc2a738ceaa074._comment
new file mode 100644
index 0000000000..d5bb0a1833
--- /dev/null
+++ b/doc/devblog/day_178-179__screencast_and_what_next/comment_1_eeba788fed45cb22f9cc2a738ceaa074._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm8BAEUyzYhORZmMuocRTk4M-3IumDm5VU"
+ nickname="luciusf0"
+ subject="Windows Support +1"
+ date="2014-06-06T21:54:38Z"
+ content="""
+I just also (like others) wanna state my strong interest in a windows port. Actually it's the only thing which is holding me back of using git-annex for real, as I live and work in a mixed-OS environment. The git-annex features would be the answers to an awful lot of our day-to-day problems, and I cannot wait to have it ready for a production environment. So -> Windows Port +1
+"""]]
diff --git a/doc/devblog/day_178-179__screencast_and_what_next/comment_2_d44e67e34615c7b00e29f307556cdd06._comment b/doc/devblog/day_178-179__screencast_and_what_next/comment_2_d44e67e34615c7b00e29f307556cdd06._comment
new file mode 100644
index 0000000000..defb4a80ff
--- /dev/null
+++ b/doc/devblog/day_178-179__screencast_and_what_next/comment_2_d44e67e34615c7b00e29f307556cdd06._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"
+ nickname="Jim"
+ subject="Android"
+ date="2014-06-08T02:44:45Z"
+ content="""
+As I don't use Windows and git-annex is already fitting my Linux use cases perfectly, I'd have to vote for Android.  FWIW, I have previously posted some thoughts on what would I see as lacking on Android [here](http://git-annex.branchable.com/forum/Controlling_content_on_mobile_device/).
+"""]]
diff --git a/doc/devblog/day_180__porting.mdwn b/doc/devblog/day_180__porting.mdwn
new file mode 100644
index 0000000000..27b4eaca1c
--- /dev/null
+++ b/doc/devblog/day_180__porting.mdwn
@@ -0,0 +1,13 @@
+Did work on Windows porting today. First, fixed a reversion in the last
+release, that broke the git-annex branch pretty badly on Windows, causing
+\r to be written to files on that branch that should never have DOS line
+endings. Second, fixed a long-standing bug that prevented getting a file
+from a local bare repository on Windows.
+
+Also refreshed all autobuilders to deal with the gnutls and openssl
+security holes-of-the-week. (git-annex uses gnutls only for XMPP,
+and does not use openssl itself, but a few programs bundled with it,
+like curl, do use openssl.)
+
+A nice piece of news: OSX Homebrew now contains git-annex, so it can be
+easily installed with `brew install git-annex`
diff --git a/doc/devblog/day_180__porting/comment_1_133875f4435a298b85ddfb8a2cc11a7a._comment b/doc/devblog/day_180__porting/comment_1_133875f4435a298b85ddfb8a2cc11a7a._comment
new file mode 100644
index 0000000000..2aa67e8233
--- /dev/null
+++ b/doc/devblog/day_180__porting/comment_1_133875f4435a298b85ddfb8a2cc11a7a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Tamschi"
+ ip="178.27.213.202"
+ subject="It's still impossible to use the git-annex repository on Windows."
+ date="2014-06-09T14:44:07Z"
+ content="""
+Since the bug tracker is in the same repository and branch as the main program (why?), any bugs submitted with a colon in the title will prevent access on NTFS file systems.  
+There is at least one such instance, I assume it potentially affects blog posts too.
+"""]]
diff --git a/doc/devblog/day_181__tricky_merge.mdwn b/doc/devblog/day_181__tricky_merge.mdwn
new file mode 100644
index 0000000000..c6bcaf8d42
--- /dev/null
+++ b/doc/devblog/day_181__tricky_merge.mdwn
@@ -0,0 +1,8 @@
+Spent most of today improving behavior when a sync or merge is
+interrupted in direct mode. It was possible for an interrupt at the wrong
+time to leave the merge committed, but the work tree not yet updated. And
+then the next sync would make a commit that reverted the merged changes!
+
+To fix this I had to avoid making any merge commit or indeed updating the
+index until after the work tree is updated. It looked intractable for a
+while; I'm still surprised I eventually succeeded.
diff --git a/doc/devblog/day_182__service.mdwn b/doc/devblog/day_182__service.mdwn
new file mode 100644
index 0000000000..1377252487
--- /dev/null
+++ b/doc/devblog/day_182__service.mdwn
@@ -0,0 +1,6 @@
+Have for the first time gotten git-annex to run as a proper Windows
+service, using nssm.
+([details](http://git-annex.branchable.com/todo/windows_support/#comment-a61be55862ea32e3dc30972f905bb987))
+Not quite ready yet though; doesn't run as the right user.
+
+And a few other windows porting bits.
diff --git a/doc/devblog/day_183__rubbing_sticks_together.mdwn b/doc/devblog/day_183__rubbing_sticks_together.mdwn
new file mode 100644
index 0000000000..ecab379167
--- /dev/null
+++ b/doc/devblog/day_183__rubbing_sticks_together.mdwn
@@ -0,0 +1,23 @@
+Spent all day on some horrible timestamp issues on legacy systems. 
+
+On FAT, timestamps have a 2s granularity, which is ok, but then Linux adds
+a temporary higher resolution cache, which is lost on unmount. This
+confused git-annex since the mtimes seemed to change and it had to
+re-checksum half the files to get unconfused, which was not good.
+I found a way to use the inode sentinal file to detect when on FAT
+and put in a workaround, without degrading git-annex everywhere else.
+
+On Windows, time zones are a utter disaster; it changes the mtime it reports
+for files after the time zone has changed. Also there's a bug in the
+haskell time library which makes it return old time zone data after a time
+zone change. (I just finished developing a fix for that bug..)
+
+Left with nothing but a few sticks, I rubbed them together, and
+actually found a way to deal with this problem too. Scary details in
+[[bugs/Windows_file_timestamp_timezone_madness]]. While I've implemented
+it, it's stuck on a branch until I find a way to make git-annex notice when
+the timezone changes while it's running.
+
+----
+
+Today's work was sponsored by Svenne Krap.
diff --git a/doc/devblog/day_184__windows_month.mdwn b/doc/devblog/day_184__windows_month.mdwn
new file mode 100644
index 0000000000..c99d03e90b
--- /dev/null
+++ b/doc/devblog/day_184__windows_month.mdwn
@@ -0,0 +1,22 @@
+It's officially a Windows porting month. Now that I'm half way through it
+and with the last week of the month going to be a vacation, this makes
+sense.
+
+Today, finished up dealing with the timezone/timestamp issues on Windows.
+This got stranger and stranger the closer I looked at it. After a timestamp
+change, a program that was already running will see one timestamp, while a
+program that is started after the change will see another one! My approach
+works pretty much no matter how Windows goes insane though, and always
+recovers a true timestamp. Yay.
+
+Also fixed a regression test failure on Windows, which turned out to be
+rooted in a bug in the command queue runner, which neglected to pass
+along environment overrides on Windows.
+
+Then I spent 5 hours tracking down a tricky 
+test suite failure on Windows, which turned out to also
+affect FAT and be a recent reversion that has as it's
+root cause a [fun bug in git itself](http://marc.info/?l=git&m=140262402204212&w=2).
+Put in a not very good workaround. Thank goodness for test suites!
+
+Also got the arm autobuilder unstuck. Release tomorrow.
diff --git a/doc/devblog/day_185__service.mdwn b/doc/devblog/day_185__service.mdwn
new file mode 100644
index 0000000000..0613ae2bf9
--- /dev/null
+++ b/doc/devblog/day_185__service.mdwn
@@ -0,0 +1,6 @@
+More work on [[todo/windows_git-annex_service]], but am stuck with a
+permissions problem.
+
+Fixed a bug that prevented two assistants from syncing when there was only
+a uni-directional link between them. Only affected direct mode, and
+was introduced back when I added the direct mode guard.
diff --git a/doc/devblog/day_186__cracked_it.mdwn b/doc/devblog/day_186__cracked_it.mdwn
new file mode 100644
index 0000000000..cff6130cbf
--- /dev/null
+++ b/doc/devblog/day_186__cracked_it.mdwn
@@ -0,0 +1,8 @@
+After despairing of ever solving this yesterday (and for the past 6 months
+really), I've got the webapp running on Windows with no visible DOS box.
+Also have the assistant starting up in the background on login.
+
+It turns out a service was not the way to do. There is a way to write a VB
+Script that runs a "DOS" command in a hidden window, and this is what I
+used. Amazing how hard it was to work this out, probably partly because I
+don't have the Windows vocabulary to know what to look for.
diff --git a/doc/devblog/day_186__cracked_it/comment_1_288b736adf392acd0f45667b2980138d._comment b/doc/devblog/day_186__cracked_it/comment_1_288b736adf392acd0f45667b2980138d._comment
new file mode 100644
index 0000000000..d85798eb88
--- /dev/null
+++ b/doc/devblog/day_186__cracked_it/comment_1_288b736adf392acd0f45667b2980138d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~maestro-alubia"
+ nickname="maestro-alubia"
+ subject="Congratulations!"
+ date="2014-06-18T09:08:45Z"
+ content="""
+I really feel with you and I am glad I currently do not need to develop on/for Windows. I wish you good progress with Windows porting, so you can concentrate on the interesting stuff again :)
+
+Best regards,
+Fabian
+"""]]
diff --git a/doc/devblog/day_186__cracked_it/comment_2_d1d79e93ac420f6b3a6f8a622e8e00bd._comment b/doc/devblog/day_186__cracked_it/comment_2_d1d79e93ac420f6b3a6f8a622e8e00bd._comment
new file mode 100644
index 0000000000..d6ade5c01a
--- /dev/null
+++ b/doc/devblog/day_186__cracked_it/comment_2_d1d79e93ac420f6b3a6f8a622e8e00bd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="Claes"
+ subject="VBScript + wscript to avoid DOS window"
+ date="2014-06-21T02:09:58Z"
+ content="""
+I use this technique too, to run cygwin xterm without an ugly DOS box popup.
+"""]]
diff --git a/doc/devblog/day_186__cracked_it/comment_3_8ca17a51b10b4e4a63d0672d5ce29024._comment b/doc/devblog/day_186__cracked_it/comment_3_8ca17a51b10b4e4a63d0672d5ce29024._comment
new file mode 100644
index 0000000000..356453e8f2
--- /dev/null
+++ b/doc/devblog/day_186__cracked_it/comment_3_8ca17a51b10b4e4a63d0672d5ce29024._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="Claes"
+ subject="VBScript + wscript to avoid DOS window"
+ date="2014-06-21T02:15:04Z"
+ content="""
+(sorry that I didn't see before that you had run into this annoying problem)
+"""]]
diff --git a/doc/devblog/day_187__release_prep.mdwn b/doc/devblog/day_187__release_prep.mdwn
new file mode 100644
index 0000000000..a5207c373e
--- /dev/null
+++ b/doc/devblog/day_187__release_prep.mdwn
@@ -0,0 +1,10 @@
+Last night, got logging to daemon.log working on Windows. Aside from XMPP
+not working (but it's near to being deprecated anyway), and some possible
+issues with unicode characters in filenames, the Windows port now seems in
+pretty good shape for a beta release.
+
+Today, mostly worked on fixing the release process so the metadata
+accurarely reflects the version from the autobuilder that is included in
+the release. Turns out there was version skew in the last release (now
+manually corrected). This should avoid that happening again, and also
+automates more of my release process.
diff --git a/doc/devblog/day_187__release_prep/comment_1_206692d16177c2a9ca11c0eeff545697._comment b/doc/devblog/day_187__release_prep/comment_1_206692d16177c2a9ca11c0eeff545697._comment
new file mode 100644
index 0000000000..a9e982a211
--- /dev/null
+++ b/doc/devblog/day_187__release_prep/comment_1_206692d16177c2a9ca11c0eeff545697._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlnoH5btjn_BLib3_IhES5uMhrzuOiwCYo"
+ nickname="András"
+ subject="sync options?"
+ date="2014-06-19T13:16:51Z"
+ content="""
+What options will we have in this beta for windows <=> windows (local network) and windows <=> linux (remote server) synchronization?  I'm interested only in non-cloud sync possibilities.
+
+(I tried to follow the developments but apparently failed...)
+
+Also thank you for working on the windows port!
+
+"""]]
diff --git a/doc/devblog/day_187__release_prep/comment_2_961fb35d9cf7d5e518f8d0bddb8626a6._comment b/doc/devblog/day_187__release_prep/comment_2_961fb35d9cf7d5e518f8d0bddb8626a6._comment
new file mode 100644
index 0000000000..6abcfb7dd3
--- /dev/null
+++ b/doc/devblog/day_187__release_prep/comment_2_961fb35d9cf7d5e518f8d0bddb8626a6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.203"
+ subject="comment 2"
+ date="2014-06-19T22:13:23Z"
+ content="""
+windows to linux server (local or remote) to windows will work. 
+"""]]
diff --git a/doc/devblog/day_188__back_sans_laptop.mdwn b/doc/devblog/day_188__back_sans_laptop.mdwn
new file mode 100644
index 0000000000..080d6176ef
--- /dev/null
+++ b/doc/devblog/day_188__back_sans_laptop.mdwn
@@ -0,0 +1,5 @@
+I am back from the beach, but my dev laptop is dead. A replacement is being
+shipped, and I have spent today getting my old netbook into a usable state
+so I can perhaps do some work using it in the meantime.
+
+(Backlog is 95 messages.)
diff --git a/doc/devblog/day_189__finally_working_again.mdwn b/doc/devblog/day_189__finally_working_again.mdwn
new file mode 100644
index 0000000000..54b72b52b5
--- /dev/null
+++ b/doc/devblog/day_189__finally_working_again.mdwn
@@ -0,0 +1,18 @@
+Finally back to work with a new laptop!
+
+Did one fairly major feature today: When using git-annex to pull down
+podcasts, metadata from the feed is copied into git-annex's metadata store,
+if annex.genmetadata is set. Should be great for views etc!
+
+Worked through a lot of the backlog, which is down to 47 messages now.
+
+Only other bug fix of note is a fix on Android. A recent change to git made
+it try to chmod files, which tends to fail on the horrible /sdcard
+filesystem. Patched git to avoid that.
+
+For some reason the autobuilder box rebooted while I was away, and 
+somehow the docker containers didn't come back up -- so they got
+automatically rebuilt. But I have to manually finish up building the
+android and armel ones. Will be babysitting that build this evening.
+
+Today's work was sponsored by Ævar Arnfjörð Bjarmason.
diff --git a/doc/devblog/day_190__fun_fixes.mdwn b/doc/devblog/day_190__fun_fixes.mdwn
new file mode 100644
index 0000000000..d3895df1f4
--- /dev/null
+++ b/doc/devblog/day_190__fun_fixes.mdwn
@@ -0,0 +1,13 @@
+Spent the morning improving behavior when `commit.gpgsign` is set.
+Now git-annex will let gpg sign commits that are made when eg, manually
+running `git annex sync`, but not commits implicitly made to the git-annex
+branch. And any commits made by the assistant are not gpg signed. This was
+slightly tricky, since lots of different places in git-annex ran `git
+commit`, `git merge` and similar.
+
+Then got back to a test I left running over vacation, that added millions
+of files to a git annex repo. This was able to reproduce a problem where
+`git annex add` blew the stack and crashed at the end. There turned out to
+be two different memory issues, one was in git-annex and the other is in
+Haskell's core `getDirectoryContents`. Was able to entirely fix it,
+eventually.
diff --git a/doc/devblog/day_191__semidistracted.mdwn b/doc/devblog/day_191__semidistracted.mdwn
new file mode 100644
index 0000000000..3d4b5b6efc
--- /dev/null
+++ b/doc/devblog/day_191__semidistracted.mdwn
@@ -0,0 +1,7 @@
+Got a bit distracted improving Haskell's directory listing code.
+
+Only real git-annex work today was fixing [[bugs/Assistant_merge_loop]],
+which was caused by changes in the last release (that made direct mode
+merging crash/interrupt-safe). This is a kind of ugly bug, that can result
+in the assistant making lots of empty commits in direct mode repositories.
+So, I plan to make a new release on Monday.
diff --git a/doc/devblog/day_192__release_day.mdwn b/doc/devblog/day_192__release_day.mdwn
new file mode 100644
index 0000000000..ce1a38861c
--- /dev/null
+++ b/doc/devblog/day_192__release_day.mdwn
@@ -0,0 +1,4 @@
+Got the release out. Had to fix various autobuilder issues. The arm autobuilder
+is unfortunatly not working currently.
+
+Updated git-annex to build with a new version of the bloomfilter library.
diff --git a/doc/devblog/day_193-194__ugly_bug.mdwn b/doc/devblog/day_193-194__ugly_bug.mdwn
new file mode 100644
index 0000000000..668b7b2ab9
--- /dev/null
+++ b/doc/devblog/day_193-194__ugly_bug.mdwn
@@ -0,0 +1,37 @@
+**Important** A bug [[caused the assistant to sometimes remove all files|bugs/bad_merge_commit_deleting_all_files]] from the git repository.
+You should check if your repository is ok. If the bug hit you, it should be
+possible to revert the bad commit and recover your files with no data loss.
+See the bug report for details. 
+
+This affected git-annex versions since 5.20140613, and only when using the
+assistant in direct mode. It should be fixed in today's release,
+5.20140709.
+
+I'm available <urgent2014@joeyh.name> to help anyone hit by this
+unfortunate bug.
+
+This is another bug in the direct mode merge code. I'm not happy about it.
+It's particularly annoying that I can't fix up after it automatically
+(because there's no way to know if any given commit in the git history that
+deletes all the files is the result of this bug, or a legitimate deletion
+of all files).
+
+The only good thing is that the design of git-annex is pretty robust, and
+in this case, despite stupidly committing the deletion of all the files in
+the repository, git-annex did take care to preserve all their contents and
+so the problem should be able to be resolved without data loss.
+
+Unfortunately, the main autobuilder is down and I've had to spin up
+autobuilders on a different machine (thank goodness that's very automated
+now!), and so I have not been able to build the fixed git-annex for android
+yet. I hope to get that done later this evening.
+
+---
+
+Yesterday, I fixed a few (much less bad) bugs, and did some thinking about
+plans for this month. The [[design/roadmap]] suggests working on some of
+[[!traillink design/assistant/chunks]], [[!traillink design/assistant/deltas]] or [[!traillink design/assistant/gpgkeys]].
+I don't know how to do deltas yet really. Chunks is pretty easily done.
+The gpg keys stuff is pretty open ended and needs some more work to define
+some use cases. But, after today, I am more inclined to want to spend
+time on better testing and other means of avoiding this kind of situation.
diff --git a/doc/devblog/day_195-196__catching_up.mdwn b/doc/devblog/day_195-196__catching_up.mdwn
new file mode 100644
index 0000000000..2c04eaa150
--- /dev/null
+++ b/doc/devblog/day_195-196__catching_up.mdwn
@@ -0,0 +1,13 @@
+Spent past 2 days catching up on backlog and doing bug triage and some
+minor bug fixes and features. Backlog is 27, lowest in quite a while so I
+feel well on top of things.
+
+I was saddened to find [this bug](http://git-annex.branchable.com/bugs/files_lost_during_upgrade/#comment-b265c796b1599d2dde649699cb54fa86)
+where I almost managed to analize the [[ugy_bug|day_193-194__ugly_bug]]'s race
+condition, but not quite (and then went on vacation). BTW, I have not heard
+from anyone else who was hit by that bug so far.
+
+The linux autobuilders are still down; their host server had a disk crash
+in an electrical outage. Might be down for a while. I would not mind
+setting up a redundant autobuilder if anyone else would like to donate a
+linux VM with 4+ gb of ram.
diff --git a/doc/devblog/day_197__autobuilder_rescuscitation.mdwn b/doc/devblog/day_197__autobuilder_rescuscitation.mdwn
new file mode 100644
index 0000000000..12dada287d
--- /dev/null
+++ b/doc/devblog/day_197__autobuilder_rescuscitation.mdwn
@@ -0,0 +1,14 @@
+Yay, the Linux autobuilder is back! Also fixed the Windows build.
+
+Fixed a reversion that prevented the webapp from starting
+properly on Windows, which was introduced by some bad locking when I put in
+the hack that makes it log to the log file on that platform.
+
+Various other minor fixes here and there. There are almost enough
+to do a release again soon.
+
+I've also been trying to bootstrap ghc 7.8 on arm, for Debian. There's a script
+that's supposed to allow building 7.8 using 7.6.3, dealing with a linker
+problem by using the gold linker. Hopefully that will work since otherwise
+Debian could remain stuck with an old ghc or worse lose the arm ports.
+Neither would be great for git-annex..
diff --git a/doc/devblog/day_198__branching_out.mdwn b/doc/devblog/day_198__branching_out.mdwn
new file mode 100644
index 0000000000..cdb3a6d1b6
--- /dev/null
+++ b/doc/devblog/day_198__branching_out.mdwn
@@ -0,0 +1,23 @@
+I have mostly been thinking about gcrypt today.
+[This issue](https://github.com/blake2-ppc/git-remote-gcrypt/issues/9)
+needs to be dealt with. The question is, does it really make sense to
+try to hide the people a git repository is encrypted for? I have 
+[posted some thoughts](http://git-annex.branchable.com/bugs/using_gpg_encryption_with_multiple_keys_fails/?updated#comment-0c4f679d972c63b0b25b6aa5e851af62)
+and am coming to the viewpoint that obscuring the identities of users
+of a repository is not a problem git-annex should try to solve itself,
+although it also shouldn't get in the way of someone who is able and
+wants to do that (by using tor, etc).
+
+Finally, I decided to go ahead and add a gcrypt.publish-participants
+setting to git-remote-gcrypt, and make git-annex set that by default when
+setting up a gcrypt repository.
+
+Some promising news from the ghc build on arm. I got a working ghc, and
+even ghci works. Which would make the template haskell in the webapp etc
+avaialble on arm without the current horrible hacks. Have not managed to
+build the debian ghc package successfully yet though.
+
+Also, fixed a bug that made `git annex sync` not pull/push with a local
+repository that had not yet been initialized for use with git-annex.
+
+Today's work was sponsored by Stanley Yamane.
diff --git a/doc/devblog/day_198__branching_out/comment_1_91ce3dc707ba1ba7c5d9e57e20ffce40._comment b/doc/devblog/day_198__branching_out/comment_1_91ce3dc707ba1ba7c5d9e57e20ffce40._comment
new file mode 100644
index 0000000000..7b9ba45b7d
--- /dev/null
+++ b/doc/devblog/day_198__branching_out/comment_1_91ce3dc707ba1ba7c5d9e57e20ffce40._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="lex"
+ ip="2620:149:7:303:796f:ae98:a0a1:94b"
+ subject="comment 1"
+ date="2014-07-16T21:13:06Z"
+ content="""
+glad my bug inspired a blog post about it.  =]
+"""]]
diff --git a/doc/devblog/day_199__ten_minute_cycle.mdwn b/doc/devblog/day_199__ten_minute_cycle.mdwn
new file mode 100644
index 0000000000..56b48747e2
--- /dev/null
+++ b/doc/devblog/day_199__ten_minute_cycle.mdwn
@@ -0,0 +1,6 @@
+Spent hours today in a 10-minute build/test cycle, tracking down a bug that
+caused the assistant to crash on Windows after exactly 10 minutes uptime.
+Eventually found the cause; this is fallout from last month's work
+that got it logging to the debug.log on Windows.
+
+There was more, but that was the interesting one..
diff --git a/doc/devblog/day_19__moving_on.mdwn b/doc/devblog/day_19__moving_on.mdwn
new file mode 100644
index 0000000000..7f4cd8244a
--- /dev/null
+++ b/doc/devblog/day_19__moving_on.mdwn
@@ -0,0 +1,37 @@
+Finished moving the Android autobuilder over to the new clean build
+environment. Tested the Android app, and it still works. Whew!
+
+There's a small chance that the issue with the Android app not working on
+Android 4.3 has been fixed by this rebuild. I doubt it, but perhaps someone
+can download the daily build and give it another try..
+
+----
+
+I have 7 days left in which I'd like to get remote gcrypt repositories
+working in the assistant. I think that should be fairly easy, but a
+prerequisite for it is making git-annex-shell support being run on a gcrypt
+repository. That's needed so that the assistant's normal locked down ssh
+key setup can also be used for gcrypt repositories.
+
+At the same time, not all gcrypt endpoints will have git-annex-shell
+installed, and it *seems* to make sense to leave in the existing support
+for running raw rsync and git push commands against such a repository. So
+that's going to add some complication.
+
+It will also complicate git-annex-shell to support gcrypt repos. Basically,
+everything it does in git-annex repos will need to be reimplemented in
+gcrypt repositories. Generally in a more simple form; for example it
+doesn't need to (and can't) update location logs in a gcrypt repo.
+
+----
+
+I also need to find a good UI to present the three available choices
+(unencrypted git, encrypted git, encrypted rsync) when setting up a repo
+on a ssh server. I don't want to just remove the encrypted rsync option,
+because it's useful when using xmpp to sync the git repo, and is simpler to
+set up since it uses shared encryption rather than gpg public keys.
+
+My current thought is to offer just 2 choices, encrypted and non-encrypted.
+If they choose encrypted, offer a choice of shared encryption or encrypting
+to a specific key. I think I can word this so it's pretty clear what the
+tradeoffs are.
diff --git a/doc/devblog/day_19__moving_on/comment_1_870106f671f9a055b81e6fc83e0850b5._comment b/doc/devblog/day_19__moving_on/comment_1_870106f671f9a055b81e6fc83e0850b5._comment
new file mode 100644
index 0000000000..b0ed97bcf3
--- /dev/null
+++ b/doc/devblog/day_19__moving_on/comment_1_870106f671f9a055b81e6fc83e0850b5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmW0kg4uiMIhSHeVuvJFyo2VYMl7Qoej0s"
+ nickname="Chris"
+ subject="comment 1"
+ date="2013-09-23T20:58:45Z"
+ content="""
+The new version of the Android apk doesn't work for me on my Nexus 4.
+"""]]
diff --git a/doc/devblog/day_19__moving_on/comment_2_fad055c8860385ac6c012f897c96408f._comment b/doc/devblog/day_19__moving_on/comment_2_fad055c8860385ac6c012f897c96408f._comment
new file mode 100644
index 0000000000..f2e754b3ab
--- /dev/null
+++ b/doc/devblog/day_19__moving_on/comment_2_fad055c8860385ac6c012f897c96408f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="comment 2"
+ date="2013-09-24T07:11:31Z"
+ content="""
+Yeah, no joy on Cyanogenmod 10.2(Android 4.3).
+
+Would be pretty surprising if it had worked.
+"""]]
diff --git a/doc/devblog/day_19__moving_on/comment_3_69e47d612159587f080ab761566d1830._comment b/doc/devblog/day_19__moving_on/comment_3_69e47d612159587f080ab761566d1830._comment
new file mode 100644
index 0000000000..206fdd8520
--- /dev/null
+++ b/doc/devblog/day_19__moving_on/comment_3_69e47d612159587f080ab761566d1830._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnR6E5iUghMWdUGlbA9CCs8DKaoigMjJXw"
+ nickname="Efraim"
+ subject="not working on my nexus 4 either"
+ date="2013-09-24T07:37:28Z"
+ content="""
+terminal output reads:
+
+Falling back to hardcoded app location; cannot find expected files in /data/app-lib
+
+git annex webapp
+
+u0_a124@mako:/sdcard/git-annex.home $ git annex webpp
+
+CANNOT LINK EXECUTABLE: git-annex invalid R_ARM_COPY relocation against DT_SYMBOLIC shared library libc.so (built with -Bsymbolic?)
+
+1|u0_a124@mako:/sdcard/git-annex.home $
+"""]]
diff --git a/doc/devblog/day_1__inauspicious_beginning.mdwn b/doc/devblog/day_1__inauspicious_beginning.mdwn
new file mode 100644
index 0000000000..b14f763bbe
--- /dev/null
+++ b/doc/devblog/day_1__inauspicious_beginning.mdwn
@@ -0,0 +1,11 @@
+I try hard to keep this devblog about git-annex development and not me.
+However, it is a shame that what I wanted to be the beginning of my first
+real month of work funded by the new campaign has been marred by my home's
+internet connection being taken out by a lightning strike, and by illness.
+Nearly back on my feet after that, and waiting for my new laptop to
+finally get here.
+
+Today's work: Finished up the `git annex forget` feature and merged it in.
+Fixed the bug that was causing the commit race detection code to
+incorrectly fire on the commit made by the transition code. Few other bits
+and pieces.
diff --git a/doc/devblog/day_1__inauspicious_beginning/comment_1_cc4dea43caf3126c6f814b589b701d70._comment b/doc/devblog/day_1__inauspicious_beginning/comment_1_cc4dea43caf3126c6f814b589b701d70._comment
new file mode 100644
index 0000000000..03e3fec6d6
--- /dev/null
+++ b/doc/devblog/day_1__inauspicious_beginning/comment_1_cc4dea43caf3126c6f814b589b701d70._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="rjc"
+ ip="86.22.66.200"
+ subject="laptop"
+ date="2013-09-04T21:42:52Z"
+ content="""
+Are you retiring your Dell mini?
+
+What kind of laptop are you getting?
+"""]]
diff --git a/doc/devblog/day_200__one_year_along.mdwn b/doc/devblog/day_200__one_year_along.mdwn
new file mode 100644
index 0000000000..6cfab59b97
--- /dev/null
+++ b/doc/devblog/day_200__one_year_along.mdwn
@@ -0,0 +1,17 @@
+Updated the Debian backport. (Also the git-remote-gcrypt backport.)
+
+Made the assistant install a desktop file to integrate with Konqueror.
+
+Improved `git annex repair`, fixing a bug that could cause it to leave
+broken branch refs and yet think that the repair was successful.
+
+----
+
+A bit surprised to see that now been a full year since I started doing
+development funded by my campaign. Not done yet!
+
+Update on campaign rewards: <https://campaign.joeyh.name/blog/stickers_soon/>
+
+----
+
+Today's work was sponsored by Douglas Butts.
diff --git a/doc/devblog/day_201__chunky.mdwn b/doc/devblog/day_201__chunky.mdwn
new file mode 100644
index 0000000000..b210702a46
--- /dev/null
+++ b/doc/devblog/day_201__chunky.mdwn
@@ -0,0 +1,12 @@
+Working on designs for better [[chunking|design/assistant/chunks]]. Having
+a hard time finding a way to totally obscure file sizes, but otherwise a
+good design seems to be coming together. I particularly like that the new
+design puts the chunk count in the Key (which is then encrypted for special
+remotes, rather than having it be some special extension.
+
+While thinking through chunking, I realized that the current chunking
+method can fail if two repositories have different chunksize settings for
+the same special remote and both upload the same key at the same time.
+Arn't races fun? The new design will eliminate this problem; in the
+meantime updated the docs to recommend never changing a remote's
+chunksize setting.
diff --git a/doc/devblog/day_202__new_chunk_groundwork.mdwn b/doc/devblog/day_202__new_chunk_groundwork.mdwn
new file mode 100644
index 0000000000..c8e0ce7f6e
--- /dev/null
+++ b/doc/devblog/day_202__new_chunk_groundwork.mdwn
@@ -0,0 +1,6 @@
+The design for new style chunks seems done, and I laid the groundwork for it
+today. Added chunk metadata to keys, reorganized the legacy chunking code
+for directory and webdav so it won't get (too badly) in the way, and
+implemented the chunk logs in the git-annex branch.
+
+Today's work was sponsored by LeastAuthority.com.
diff --git a/doc/devblog/day_203__in_the_weeds.mdwn b/doc/devblog/day_203__in_the_weeds.mdwn
new file mode 100644
index 0000000000..a8cf1787ab
--- /dev/null
+++ b/doc/devblog/day_203__in_the_weeds.mdwn
@@ -0,0 +1,39 @@
+A lil bit in the weeds on the chunking rewrite right now. I did succeed in
+writing the core chunk generation code, which can be used for every special
+remote. It was pretty hairy (needs to stream large files in constant
+memory, separating into chunks, and get the progress display right
+across operations on chunks, etc). That took most of the day.
+
+Ended up getting stuck in integrating the encryptable remote code, and had
+to revert changes that could have led to rewriting (or perhaps
+eliminating?) most of the per-remote encryption specific code.
+
+Up till now, this has supported both encrypted and non-encrypted remotes;
+it was simply passed encrypted keys for an encrypted remote:
+
+[[!format haskell """
+remove :: Key -> Annex Bool
+"""]]
+
+But with chunked encrypted keys, it seems it needs to be more complicated:
+
+[[!format haskell """
+remove' :: Maybe (Key -> Key) -> ChunkConfig -> Key -> Annex Bool
+"""]]
+
+So that when the remote is configured to use chunking, it can look up
+the chunk keys, and then encrypt them, in order to remove all the encrypted
+chunk keys.
+
+I don't like that complication, so want to find a cleaner
+abstraction. Will sleep on it.
+
+----
+
+While I was looking at the encryptable remote generator, I realized
+the remote cost was being calculated wrongly for special 
+remotes that are not encrypted. Fixed that bug.
+
+----
+
+Today's work was sponsored by bak.
diff --git a/doc/devblog/day_204__mowing.mdwn b/doc/devblog/day_204__mowing.mdwn
new file mode 100644
index 0000000000..b34f1ba380
--- /dev/null
+++ b/doc/devblog/day_204__mowing.mdwn
@@ -0,0 +1,64 @@
+Remained frustratingly stuck until 3 pm on the same stuff that puzzled
+me yesterday. However, 6 hours later, I have the directory
+special remote 100% working with both new chunk= and legacy chunksize=
+configuration, both with and without encryption.
+
+----
+
+So, the root of why this is was hard, since I thought about it a lot today
+in between beating my head into the wall: git-annex's internal API for remotes
+is really, really simple. It basically comes down to:
+
+[[!format haskell """
+	Remote
+		{ storeKey :: Key -> AssociatedFile -> MeterUpdate -> Annex Bool
+		, retrieveKeyFile :: Key -> AssociatedFile -> FilePath -> MeterUpdate -> Annex Bool
+		, removeKey :: Key -> Annex Bool
+		, hasKey :: Key -> Annex (Either String Bool)
+		}
+"""]]
+
+This simplicity is a Good Thing, because it maps very well to REST-type
+services. And it allows for quite a lot of variety in implementations of
+remotes. Ranging from reguar git remotes, that rsync files around without
+git-annex ever loading them itself, to remotes like webdav that load
+and store files themselves, to remotes like tahoe that intentionally do not
+support git-annex's built-in encryption methods.
+
+However, the simplicity of that API means that lots of complicated stuff,
+like handling chunking, encryption, etc, has to be handled on a per-remote
+basis. Or, more generally, by `Remote -> Remote` transformers that take
+a remote and add some useful feature to it.
+
+One problem is that the API is so simple that a remote transformer that adds
+encryption is not feasible. In fact, every encryptable remote has
+had its own code that loads a file from local disk, encrypts it, and sends
+it to the remote. Because there's no way to make a remote transformer that
+converts a `storeKey` into an encrypted `storeKey`. (Ditto for retrieving
+keys.)
+
+I almost made the API more complicated today. Twice. But both times
+I ended up not, and I think that was the right choice, even though
+it meant I had to write some quite painful code.
+
+----
+
+In the end, I instead wrote a little module that pulls together supporting
+both encryption and chunking. I'm not completely happy because those
+two things should be independent, and so separate. But, 120 lines of
+code that don't keep them separate is not the end of the world.
+
+That module also contains some more powerful, less general APIs, 
+that will work well with the kinds of remotes that will use it.
+
+The really nice result, is that the implementation of the directory
+special remote melts down from 267 lines of code to just 172! (Plus some
+legacy code for the old style chunking, refactored out into a file I can
+delete one day.) It's a lot cleaner too.
+
+With all this done, I expect I can pretty easily add the new style chunking
+to most git-annex remotes, and remove code from them while doing it!
+
+----
+
+Today's work was sponsored by Mark Hepburn.
diff --git a/doc/devblog/day_205__incremental.mdwn b/doc/devblog/day_205__incremental.mdwn
new file mode 100644
index 0000000000..c8535d4390
--- /dev/null
+++ b/doc/devblog/day_205__incremental.mdwn
@@ -0,0 +1,21 @@
+Last night, went over the new chunking interface, tightened up exception
+handling, and improved the API so that things like WebDAV will be able to
+reuse a single connection while all of a key's chunks are being downloaded.
+I am pretty happy with the interface now, and except to convert more
+special remotes to use it soon.
+
+Just finished adding a killer feature: Automatic resuming of interrupted
+downloads from chunked remotes. Sort of a poor man's rsync, that while less
+efficient and awesome, is going to work on *every* remote that gets the new
+chunking interface, from S3 to WebDAV, to all of Tobias's external special
+remotes! Even allows for things like starting a download
+from one remote, interrupting, and resuming from another one, and so on.
+
+I had forgotten about resuming while designing the chunking API. Luckily, I
+got the design right anyway. Implementation was almost trivial, and only
+took about 2 hours! (See [[!commit 9d4a766cd7b8e8b0fc7cd27b08249e4161b5380a]])
+
+I'll later add resuming of interrupted uploads. It's not hard to detect
+such uploads with only one extra query of the remote, but in principle,
+it should be possible to do it with no extra overhead, since git-annex
+already checks if all the chunks are there before starting an upload.
diff --git a/doc/devblog/day_206__zap.mdwn b/doc/devblog/day_206__zap.mdwn
new file mode 100644
index 0000000000..eccee2464b
--- /dev/null
+++ b/doc/devblog/day_206__zap.mdwn
@@ -0,0 +1,83 @@
+Zap! ... My internet gateway was [destroyed by lightning](https://identi.ca/joeyh/note/xogvXTFDR9CZaCPsmKZipA).
+Limping along regardless, and replacement ordered.
+
+Got resuming of uploads to chunked remotes working. Easy!
+
+----
+
+Next I want to convert the external special remotes to have these nice
+new features. But there is a wrinkle: The new chunking interface works
+entirely on ByteStrings containing the content, but the external special
+remote interface passes content around in files.
+
+I could just make it write the ByteString to a temp file, and pass the temp
+file to the external special remote to store. But then, when chunking is
+not being used, it would pointlessly read a file's content, only to write
+it back out to a temp file.
+
+Similarly, when retrieving a key, the external special remote saves it to a
+file. But we want a ByteString. Except, when not doing chunking or
+encryption, letting the external special remote save the content directly
+to a file is optimal.
+
+One approach would be to change the protocol for external special
+remotes, so that the content is sent over the protocol rather than in temp
+files. But I think this would not be ideal for some kinds of external
+special remotes, and it would probably be quite a lot slower and more
+complicated.
+
+Instead, I am playing around with some type class trickery:
+
+[[!format haskell """
+{-# LANGUAGE Rank2Types TypeSynonymInstances FlexibleInstances MultiParamTypeClasses #-}
+
+type Storer p = Key -> p -> MeterUpdate -> IO Bool
+
+-- For Storers that want to be provided with a file to store.
+type FileStorer a = Storer (ContentPipe a FilePath)
+
+-- For Storers that want to be provided with a ByteString to store
+type ByteStringStorer a = Storer (ContentPipe a L.ByteString)
+
+class ContentPipe src dest where
+        contentPipe :: src -> (dest -> IO a) -> IO a
+
+instance ContentPipe L.ByteString L.ByteString where
+        contentPipe b a = a b
+
+-- This feels a lot like I could perhaps use pipes or conduit...
+instance ContentPipe FilePath FilePath where
+        contentPipe f a = a f
+
+instance ContentPipe L.ByteString FilePath where
+        contentPipe b a = withTmpFile "tmpXXXXXX" $ \f h -> do
+                L.hPut h b
+                hClose h
+                a f
+
+instance ContentPipe FilePath L.ByteString where
+        contentPipe f a = a =<< L.readFile f
+"""]]
+
+The external special remote would be a FileStorer, so when a non-chunked,
+non-encrypted file is provided, it just runs on the FilePath with no extra
+work. While when a ByteString is provided, it's swapped out to a temp file
+and the temp file provided. And many other special remotes are ByteStorers,
+so they will just pass the provided ByteStream through, or read in the
+content of a file.
+
+I think that would work. Thoigh it is not optimal for external special
+remotes that are chunked but not encrypted. For that case, it might be worth
+extending the special remote protocol with a way to say "store a chunk of
+this file from byte N to byte M".
+
+---
+
+Also, talked with ion about what would be involved in using rolling checksum
+based chunks. That would allow for rsync or zsync like behavior, where
+when a file changed, git-annex uploads only the chunks that changed, and the
+unchanged chunks are reused.
+
+I am not ready to work on that yet, but I made some changes to the parsing
+of the chunk log, so that additional chunking schemes like this can be added
+to git-annex later without breaking backwards compatability.
diff --git a/doc/devblog/day_207__at_last.mdwn b/doc/devblog/day_207__at_last.mdwn
new file mode 100644
index 0000000000..936ac98f0e
--- /dev/null
+++ b/doc/devblog/day_207__at_last.mdwn
@@ -0,0 +1,34 @@
+It took 9 hours, but I finally got to make [[!commit c0dc134cded6078bb2e5fa2d4420b9cc09a292f7]],
+which both removes 35 lines of code, and adds chunking support to all
+external special remotes!
+
+The groundwork for that commit involved taking the type scheme I sketched
+out yesterday, completely failing to make it work with such high-ranked
+types, and falling back to a simpler set of types that both I and GHC seem
+better at getting our heads around.
+
+Then I also had more fun with types, when it turned out I needed to
+run encryption in the Annex monad. So I had to go convert several parts of
+the utility libraries to use MonadIO and exception lifting. Yurk.
+
+The final and most fun stumbling block caused git-annex to crash when
+retriving a file from an external special remote that had neither
+encryption not chunking. Amusingly it was because I had not put in an
+optimation (namely, just renaming the file that was retrieved in this case,
+rather than unnecessarily reading it in and writing it back out). It's
+not often that a lack of an optimisation causes code to crash!
+
+So, fun day, great result, and it should now be very simple to convert
+the bup, ddar, gcrypt, glacier, rsync, S3, and WebDAV special remotes
+to the new system. Fingers crossed.
+
+But first, I will probably take half a day or so and write a 
+`git annex testremote` that can be run in a repository and does live
+testing of a special remote including uploading and downloading files.
+There are quite a lot of cases to test now, and it seems best to get
+that in place before I start changing a lot of remotes without a way to
+test everything.
+
+----
+
+Today's work was sponsored by Daniel Callahan.
diff --git a/doc/devblog/day_208__testremote.mdwn b/doc/devblog/day_208__testremote.mdwn
new file mode 100644
index 0000000000..87c497fccc
--- /dev/null
+++ b/doc/devblog/day_208__testremote.mdwn
@@ -0,0 +1,10 @@
+Built `git annex testremote` today. 
+
+That took a little bit longer than expected, because it actually found
+several fence post bugs in the chunking code.
+
+It also found a bug in the sample external special remote script.
+
+I am very pleased with this command. Being able to run 640 tests against
+any remote, without any possibility of damaging data already stored in the
+remote, is awesome. Should have written it a looong time ago!
diff --git a/doc/devblog/day_209__mass_conversion.mdwn b/doc/devblog/day_209__mass_conversion.mdwn
new file mode 100644
index 0000000000..23de65b2ac
--- /dev/null
+++ b/doc/devblog/day_209__mass_conversion.mdwn
@@ -0,0 +1,32 @@
+Have started converting lots of special remotes to the new API. Today, S3
+and hook got chunking support. I also converted several remotes to the new
+API without supporting chunking: bup, ddar, and glacier (which should
+support chunking, but there were complications). 
+
+This removed 110 lines of code while adding features! And,
+I seem to be able to convert them faster than `testremote` can test them. :)
+
+Now that S3 supports chunks, they can be used to work around several
+problems with S3 remotes, including file size limits, and a memory leak in
+the underlying S3 library.
+
+The S3 conversion included caching of the S3 connection when
+storing/retrieving chunks. [Update: Actually, it turns out it didn't;
+the hS3 library doesn't support persistent connections. Another reason I
+need to switch to a better S3 library!] 
+
+But the API doesn't yet support caching
+when removing or checking if chunks are present. I should probably expand
+the API, but got into some type checker messes when using generic enough
+data types to support everything. Should probably switch to `ResourceT`.
+
+Also, I tried, but failed to make `testremote` check that storing a key
+is done atomically. The best I could come up with was a test that stored a
+key and had another thread repeatedly check if the object was present on
+the remote, logging the results and timestamps. It then becomes a
+statistical problem -- somewhere toward the end of the log it's ok if the key
+has become present -- but too early might indicate that it wasn't stored
+atomically. Perhaps it's my poor knowledge of statistics, but I could not
+find a way to analize the log that reliably detected non-atomic storage.
+If someone would like to try to work on this, see the `atomic-store-test`
+branch.
diff --git a/doc/devblog/day_20__gcrypt_and_git-annex-shell.mdwn b/doc/devblog/day_20__gcrypt_and_git-annex-shell.mdwn
new file mode 100644
index 0000000000..0e4142b7c0
--- /dev/null
+++ b/doc/devblog/day_20__gcrypt_and_git-annex-shell.mdwn
@@ -0,0 +1,14 @@
+Added support for gcrypt remotes to git-annex-shell. Now gcrypt special
+remotes probe when they are set up to see if the remote system has a
+suitable git-annex-shell, and if so all commands are sent to it. Kept the
+direct rsync mode working as a fallback.
+
+It turns out I made a bad decision when first adding gcrypt support to
+git-annex. To make implementation marginally easier, I decided to not
+put objects inside the usual `annex/objects` directory in a gcrypt remote.
+But that lack of consistency would have made adding support to
+git-annex-shell a lot harder. So, I decided to change this. Which 
+means that anyone already using gcrypt with git-annex will need to
+[[manually_move_files_around|upgrades/gcrypt]].
+
+Today's work was sponsored by Tobias Nix.
diff --git a/doc/devblog/day_210__conversion_and_digression.mdwn b/doc/devblog/day_210__conversion_and_digression.mdwn
new file mode 100644
index 0000000000..2629eb9174
--- /dev/null
+++ b/doc/devblog/day_210__conversion_and_digression.mdwn
@@ -0,0 +1,14 @@
+Just finished converting both rsync and gcrypt to the new API,
+and testing them. Still need to fix 2 test suite failures for gcrypt.
+Otherwise, only WebDAV remains unconverted.
+
+Earlier today, I investigated switching from hS3 to
+<http://hackage.haskell.org/package/aws>. Learned its API, which seemed a
+lot easier to comprehend than the other two times I looked at it. Wrote
+some test programs, which are in the `s3-aws` branch. I was able to stream
+in large files to S3, without ever buffering them in memory (which hS3's
+API precludes). And for chunking, it can reuse an http connection.
+This seems very promising. (Also, it might eventually get Glacier support..)
+
+I have uploaded haskell-aws to Debian, and once it gets into testing and
+backports, I plan to switch git-annex over to it.
diff --git a/doc/devblog/day_211__conversion_complete.mdwn b/doc/devblog/day_211__conversion_complete.mdwn
new file mode 100644
index 0000000000..5e172fae18
--- /dev/null
+++ b/doc/devblog/day_211__conversion_complete.mdwn
@@ -0,0 +1,12 @@
+Converted the webdav special remote to the new API. 
+All done with converting everything now!
+
+I also updated the new API to support doing things like
+reusing the same http connection when removing and checking
+the presence of chunks.
+
+I've been working on improving the haskell DAV library, in a
+number of ways that will let me improve the webdav special remote.
+Including making changes that will let me do connection caching, and
+improving its API to support streaming content without buffering a whole
+file in memory.
diff --git a/doc/devblog/day_212__webdav_rewrite.mdwn b/doc/devblog/day_212__webdav_rewrite.mdwn
new file mode 100644
index 0000000000..714800c9aa
--- /dev/null
+++ b/doc/devblog/day_212__webdav_rewrite.mdwn
@@ -0,0 +1,18 @@
+Today was spent reworking so much of the webdav special remote that it was
+essentially rewritten from scratch.
+
+The main improvement is that it now keeps a http connection open and uses
+it to perform multiple actions. Before, one connection was made per action.
+This is even done for operations on chunks. So, now storing a chunked file
+in webdav makes only 2 http connections total. Before, it would take around
+10 connections *per chunk*. So a big win for performance, although there is
+still room for improvement: It would be possible to reduce that down to
+just 1 connection, and indeed keep a persistent connection reused when
+acting on multiple files.
+
+Finished up by making uploading a large (non-chunked) file to webdav not
+buffer the whole file in memory. 
+
+I still need to make downloading a file from webdav not buffer it, and
+test, and then I'll be done with webdav and can move on to making
+similar changes to S3.
diff --git a/doc/devblog/day_213__newchunks_merged.mdwn b/doc/devblog/day_213__newchunks_merged.mdwn
new file mode 100644
index 0000000000..42ea7a6550
--- /dev/null
+++ b/doc/devblog/day_213__newchunks_merged.mdwn
@@ -0,0 +1,15 @@
+Finished up webdav, and after running `testremote` for a long time, I'm
+satisfied it's good. The newchunks branch has now been merged into master
+completely.
+
+Spent the rest of the day beginning to rework the S3 special remote to use
+the aws library. This was pretty fiddly; I want to keep all the
+configuration exactly the same, so had to do a lot of mapping from hS3
+configuration to aws configuration. Also there is some hairy stuff
+involving escaping from the ResourceT monad with responses and http
+connection managers intact.
+
+Stopped once `initremote` worked. The rest should be pretty easy, although
+Internet Archive support is blocked by
+<https://github.com/aristidb/aws/issues/119>. This is in the `s3-aws`
+branch until it gets usable.
diff --git a/doc/devblog/day_214-215__wrapping_up_recent_work.mdwn b/doc/devblog/day_214-215__wrapping_up_recent_work.mdwn
new file mode 100644
index 0000000000..7e06e231b2
--- /dev/null
+++ b/doc/devblog/day_214-215__wrapping_up_recent_work.mdwn
@@ -0,0 +1,16 @@
+Yesterday, finished converting S3 to use the aws library. Very happy with
+the result (no memory leaks! connection caching!), but s3-aws is not merged
+into master yet. Waiting on a new release of the aws library so as to not
+break Internet Archive S3 support.
+
+Today, spent a few hours adding more tests to `testremote`. The new tests
+take a remote, and construct a modified version that is intentionally
+unavailable. Then they make sure trying to use it fails in appropriate
+ways. This was a very good thing to test; two bugs were immediately found
+and fixed.
+
+And that wraps up several weeks of hacking on the core of git-annex's
+remotes support, which started with reworking chunking and kind of took
+on a life of its own. I plan a release of this new stuff in a week. The
+next week will be spent catching up on 117 messages of backlog that
+accumulated while I was in deep coding mode.
diff --git a/doc/devblog/day_216__various_minor_bugs.mdwn b/doc/devblog/day_216__various_minor_bugs.mdwn
new file mode 100644
index 0000000000..a9c49a9dd3
--- /dev/null
+++ b/doc/devblog/day_216__various_minor_bugs.mdwn
@@ -0,0 +1,16 @@
+Working on getting caught up with backlog. 73 messages remain.
+
+Several minor bugs were fixed today. All edge cases. The most edge case one
+of all, I could not fix: git-annex cannot add a file that has a newline
+in its filename, because `git cat-file --batch`'s interface does not support such
+filenames.
+
+Added a page [[documenting how verify the signatures of git-annex releases|install/verifying_downloads]].
+
+Over the past couple days, all the autobuilders have been updated to new
+dependencies needed by the recent work. Except for Windows, which needs to
+be updated to the new Haskell Platform first, so hopefully soon.
+
+Turns out that upgrading unix-compat means that inode(like) numbers are
+available even on Windows, which will make git-annex more robust there.
+Win win. ;)
diff --git a/doc/devblog/day_216__various_minor_bugs/comment_1_0d0a0e75b9446f8a1c4cc43f36569473._comment b/doc/devblog/day_216__various_minor_bugs/comment_1_0d0a0e75b9446f8a1c4cc43f36569473._comment
new file mode 100644
index 0000000000..a1cc9c3b7f
--- /dev/null
+++ b/doc/devblog/day_216__various_minor_bugs/comment_1_0d0a0e75b9446f8a1c4cc43f36569473._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="80.202.103.55"
+ subject="comment 1"
+ date="2014-08-14T05:30:46Z"
+ content="""
+What exactly does «git-annex cannot add a file that has a space in its filename» mean? git-annex (/assistant) actually can't handle tracking any file that has a space in its filename?
+"""]]
diff --git a/doc/devblog/day_216__various_minor_bugs/comment_2_6b06b3f46f20a6d2e60684d1d59fca07._comment b/doc/devblog/day_216__various_minor_bugs/comment_2_6b06b3f46f20a6d2e60684d1d59fca07._comment
new file mode 100644
index 0000000000..559689bb79
--- /dev/null
+++ b/doc/devblog/day_216__various_minor_bugs/comment_2_6b06b3f46f20a6d2e60684d1d59fca07._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 2"
+ date="2014-08-15T19:45:28Z"
+ content="""
+That was a typo. Of course, spaces are no problem. Newlines in filenames, on the other hand..
+"""]]
diff --git a/doc/devblog/day_216__various_minor_bugs/comment_3_05177e2ed414d22711dcec57a614e38c._comment b/doc/devblog/day_216__various_minor_bugs/comment_3_05177e2ed414d22711dcec57a614e38c._comment
new file mode 100644
index 0000000000..4b3f0248a5
--- /dev/null
+++ b/doc/devblog/day_216__various_minor_bugs/comment_3_05177e2ed414d22711dcec57a614e38c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="80.202.103.55"
+ subject="comment 3"
+ date="2014-08-16T15:22:35Z"
+ content="""
+Ah, well then, that sounds a lot more reasonable. Though legal, I have yet to hear of a sane reason for using newlines in filenames.
+"""]]
diff --git a/doc/devblog/day_217__autobuilders.mdwn b/doc/devblog/day_217__autobuilders.mdwn
new file mode 100644
index 0000000000..2a58e0c631
--- /dev/null
+++ b/doc/devblog/day_217__autobuilders.mdwn
@@ -0,0 +1,10 @@
+Over the past couple days, got the arm autobuilder working again. It had
+been down since June with several problems. cabal install tended to crash;
+apparenty this has something to do with threading in user-mode qemu,
+because -j1 avoids that. And strange invalid character problems were fixed
+by downgrading file-embed. Also, with Yury's help I got the Windows
+autobuilder upgraded to the new Haskell Platform and working again.
+
+Today a last few finishing touches, including getting rid of the last
+dependency on the old haskell HTTP library, since http-conduit is being
+used now. Ready for the release!
diff --git a/doc/devblog/day_218__scary_locking.mdwn b/doc/devblog/day_218__scary_locking.mdwn
new file mode 100644
index 0000000000..81afb263b5
--- /dev/null
+++ b/doc/devblog/day_218__scary_locking.mdwn
@@ -0,0 +1,24 @@
+Plan is to be on vacation and/or low activity this week before DebConf.
+However, today I got involved in fixing a bug that caused the assistant to
+keep files open after syncing with repositories on removable media.
+
+Part of that bug involved lock files not being opend close-on-exec, and
+while fixing that I noticed again that the locking code was scattered all
+around and rather repetitive. That led to a lot of refactoring, which is
+always fun when it involves scary locking code. Thanks goodness for
+referential transparency.
+
+Now there's a Utility.LockFile that works on both POSIX and Windows.
+Howver, that module actually exports very different functions for the two.
+While it might be tempting to try to do a portability layer, the
+two locking models are really very different, and there are lots of gotchas
+such a portability layer would face. The only API that's completely the
+same between the two is dropLock.
+
+This refactoring process and the cleaner, more expressive
+code it led to helped me spot a couple of bugs involving locking. See
+[[!commit e386e26ef207db742da6d406183ab851571047ff]]
+and [[!commit 0a4d301051e4933661b7b0a0791afa95bfe9a1d3]]
+Neither bug has ever seemed to cause
+a problem, but it's nice to be able to spot and fix such bugs before they
+do.
diff --git a/doc/devblog/day_219__catching_up_and_looking_back.mdwn b/doc/devblog/day_219__catching_up_and_looking_back.mdwn
new file mode 100644
index 0000000000..8d82d8cb96
--- /dev/null
+++ b/doc/devblog/day_219__catching_up_and_looking_back.mdwn
@@ -0,0 +1,109 @@
+Yesterday and today were the first good solid days working on git-annex in a
+while. There's a big backlog, currently of 133 messages, so I have been
+concentrating on bug reports first. Happily, not many new bugs have been
+reported lately, and I've made good progress on them, fixing 5 bugs today,
+including a file descriptor leak.
+
+## catching up
+
+In this end of summer rush, I've been too busy to blog for the past 20 days,
+but not entirely too busy to work on git-annex. Two releases have been made
+in that time, and a fair amount of improvements worked on.
+
+Including a new feature: When a local git repository is cloned with `git
+clone --shared`, git-annex detects this and defaults to a special mode
+where file contents get hard linked into the clone. It also makes the cloned
+repository be untrusted, to avoid confusing numcopies counting with the
+hard links. This can be useful for temporary working repositories without
+the overhead of lots of copies of files.
+
+## looking back
+
+I want to look back further, over the crowdfunded year of work covered
+by this devblog. There were a lot of things I wanted to accomplish this
+past year, and I managed to get to most of them. As well as a few surprises.
+
+* Windows support improved more than I guessed in my wildest dreams.  
+  git-annex went from working not too well on the command line to
+  being pretty solid there, as well as having a working
+  and almost polished webapp on Windows.  
+  There are still warts -- it's Windows after all!
+
+* Android didn't get many improvements. Most of the time I had budgeted to
+  Android porting ended up being used on Windows porting instead. I did,
+  however, get the Android build environment cleaned up a lot from the initial
+  hacked together one, and generally kept it building and working on Android.
+
+* The [direct mode guard](http://git-annex.branchable.com/devblog/day_48__direct_mode_guard_design/)
+  was not planned, but the need for it became clear, and
+  it's dramatically reduced the amount of command-line foot-shooting
+  that goes on in direct mode.
+
+* Repository repair was planned, and I've very proud of [git-repair](http://git-repair.branchable.com/).
+  Also pleased with the webapp's UI for scheduling repository consistency
+  checks.  
+  Always room for improvement in this kind of thing, but this brings a new
+  capability to both git and git-annex.
+
+* The [[external_special_remote_interface|special_remotes/external]] came
+  together beautifully. External special remotes are now just as well
+  supported as built-in ones, except the webapp cannot be used to configure
+  them.
+
+* Using git-remote-gcrypt for fully encrypted git repositories, including
+  support in the webapp for setting them (and gpg keys if necessary),
+  happened. Still needs testing/more use/improvements. Avoided doing
+  much in the area of gpg key management, which is probably good to avoid when
+  possible, but is probably needed to make this a really suitable option for
+  end users.
+
+* Telehash is still being built, and it's not clear if they've gotten it
+  to work at all yet. The v2 telehash has recently been superseded by a
+  a new v3. So I am not pleased that I didn't get git-annex working with
+  telehash, but it was outside my control. This is a problem that needs to get
+  solved outside git-annex first, either by telehash or something else.
+  The plan is to keep an eye on everything in this space, including for example,
+  Maidsafe.
+
+* In the meantime, the new notifychanges support in git-annex-shell
+  makes XMPP/telehash/whatever unnecessary in a lot of configurations.
+  git-annex's remotedaemon architecture supports that and is designed
+  to support other notification methods later. And the webapp has a lot of
+  improvements in the area of setting up ssh remotes, so fewer users will
+  be stuck with XMPP.
+
+* I didn't quite get to [[design/assistant/deltas]], but the final month
+  of work on chunking provides a lot of new features and hopefully a
+  foundation that will get to deltas eventually. There is a new haskell
+  library that's being developed with the goal of being used for git-annex
+  deltas.
+
+* I hadn't planned to make git-annex be able to upgrade itself, when installed
+  from this website. But there was a need for that, and so it happened.
+  Even got a gpg key trust path for the distribution of git-annex.
+
+* Metadata driven views was an entirely unplanned feature. The current
+  prototype is very exciting, it opens up entire new use cases. 
+  I had to hold myself back to not work on it too much,
+  especially as it shaded into adding a caching database to git-annex.
+  Had too much other stuff planned to do all I wanted.
+  Clearly this is an area I want to spend more time on!
+
+Those are most of the big features and changes, but probably half
+of my work on git-annex this past year was in smaller things, and general
+maintenance. Lots of others have contributed, some with 
+code (like the large effort to switch to bootstrap3),
+and others with documentation, bug reports, etc.
+
+Perhaps it's best to turn to `git diff --stat` to sum up the activity
+and see just how much both the crowdfunding campaign and
+the previous kickstarter have pushed git-annex into high gear:
+ 
+	   campaign: 5410 files changed, 124159 insertions(+), 79395 deletions(-)
+	kickstarter: 4411 files changed, 123262 insertions(+), 13935 deletions(-)
+	year before: 1281 files changed,   7263 insertions(+), 55831 deletions(-)
+
+What's next? The hope is, no more crowdfunded campaigns where I have
+to promise the moon anytime soon. Instead, the goal is to move to a more
+mature and sustainable funding model, and continue to grow the git-annex
+community, and the spaces where it's useful.
diff --git a/doc/devblog/day_219__catching_up_and_looking_back/comment_1_16b13b2510183a9da5f960ae5765e581._comment b/doc/devblog/day_219__catching_up_and_looking_back/comment_1_16b13b2510183a9da5f960ae5765e581._comment
new file mode 100644
index 0000000000..5b839b55cb
--- /dev/null
+++ b/doc/devblog/day_219__catching_up_and_looking_back/comment_1_16b13b2510183a9da5f960ae5765e581._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkRGMQkg9ck_pr47JXZV_C2DJQXrO8LgpI"
+ nickname="Michael"
+ subject="Hard linking on local clone"
+ date="2014-09-13T06:28:01Z"
+ content="""
+Thanks for this feature. It will save a lot of space when working on one-off projects with big scientific datasets.
+
+Unfortunately, there is probably no easy solution to achieve similar savings across file systems. On our shared cluster individual labs have their data in separate ZFS volumes (to ease individual backup handling), but data is often shared (i.e. copied) across volumes when cloning an annex. We need expensive de-duplication on the backup-server to, at least, prevent this kind of waste to hit the backups -- but the master file server still suffers (de-duplication ratio sometimes approaching a factor of 2.0).
+"""]]
diff --git a/doc/devblog/day_219__catching_up_and_looking_back/comment_2_460c064bebb5061fcba2a6c79f039362._comment b/doc/devblog/day_219__catching_up_and_looking_back/comment_2_460c064bebb5061fcba2a6c79f039362._comment
new file mode 100644
index 0000000000..a00d33dc6f
--- /dev/null
+++ b/doc/devblog/day_219__catching_up_and_looking_back/comment_2_460c064bebb5061fcba2a6c79f039362._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 2"
+ date="2014-09-14T17:38:34Z"
+ content="""
+thanks so much for your work on git-annex, joeyh. it's hard to imagine that just 4 years ago, we didn't have anything even close to this tool and how far it went since then. 
+
+~~~~
+anarcat@marcos:git-annex$ pepper age
+Loading cache index... done
+git-annex is 3 years old
+git-annex's birthday is in about 1 month (October 19th)
+~~~~
+
+birthday is coming soon! :)
+
+it's also quite impressive how much work can be done in a single year with some (fairly minimal) funding to dedicate a full dev on a project. very inspiring - keep up the good work! -- [[anarcat]]
+"""]]
diff --git a/doc/devblog/day_219__catching_up_and_looking_back/comment_3_9699d5a9de5ea64fbc876352e20261c4._comment b/doc/devblog/day_219__catching_up_and_looking_back/comment_3_9699d5a9de5ea64fbc876352e20261c4._comment
new file mode 100644
index 0000000000..91fc49409c
--- /dev/null
+++ b/doc/devblog/day_219__catching_up_and_looking_back/comment_3_9699d5a9de5ea64fbc876352e20261c4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ ip="70.83.139.100"
+ subject="camlistore"
+ date="2014-09-17T20:18:56Z"
+ content="""
+have you looked at [camlistore](http://camlistore.org/) at all? it's a fairly new project, but it seems like it could be an interesting backend, or at least inspiration for git-annex's design. --[[anarcat]]
+"""]]
diff --git a/doc/devblog/day_219__catching_up_and_looking_back/comment_4_23c4ede3db0ea8165311466881cfa6a2._comment b/doc/devblog/day_219__catching_up_and_looking_back/comment_4_23c4ede3db0ea8165311466881cfa6a2._comment
new file mode 100644
index 0000000000..8e24916db8
--- /dev/null
+++ b/doc/devblog/day_219__catching_up_and_looking_back/comment_4_23c4ede3db0ea8165311466881cfa6a2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmH7o6q2l99M-PQolOfbR3_i5B_jtTIcAE"
+ nickname="Giovanni"
+ subject="Camlistore"
+ date="2014-09-17T20:36:43Z"
+ content="""
+anarcat, have you used it? I tried, but it is buggy. They seem to be at [\"the Archivist\"](http://git-annex.branchable.com/) group of people, but if you don't have a hard drive to store the things, everything breaks up. I paid a lot of money to Amazon because I believed I could use Camlistore to organize data stored at S3, but apparently S3 is \"just for backup\", and if it is your only storage, then Camlistore will keep fetching data over and over \"to index it\" and in the end you pay.
+
+Yes, it keeps working, so you need some server online at all times, with Camlistore running.
+"""]]
diff --git a/doc/devblog/day_219__catching_up_and_looking_back/comment_5_7997305d7ec7db072b78dd0c31ecd824._comment b/doc/devblog/day_219__catching_up_and_looking_back/comment_5_7997305d7ec7db072b78dd0c31ecd824._comment
new file mode 100644
index 0000000000..91e4dc5f5d
--- /dev/null
+++ b/doc/devblog/day_219__catching_up_and_looking_back/comment_5_7997305d7ec7db072b78dd0c31ecd824._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ ip="70.83.139.100"
+ subject="comment 5"
+ date="2014-09-17T20:53:01Z"
+ content="""
+i haven't tried it at all - only looked at [this one demo video](https://www.youtube.com/watch?v=yxSzQIwXM1k) that reminded me of git-annex a lot...
+"""]]
diff --git a/doc/devblog/day_21__bugfix_day.mdwn b/doc/devblog/day_21__bugfix_day.mdwn
new file mode 100644
index 0000000000..a913fce56a
--- /dev/null
+++ b/doc/devblog/day_21__bugfix_day.mdwn
@@ -0,0 +1,5 @@
+Did various bug fixes and followup today. Amazing how a day can vanish that
+way. Made 4 actual improvements.
+
+I still have 46 messages in unanswered backlog. Although only 8 of
+the are from this month.
diff --git a/doc/devblog/day_220__working_through_backlog.mdwn b/doc/devblog/day_220__working_through_backlog.mdwn
new file mode 100644
index 0000000000..4685e3ff05
--- /dev/null
+++ b/doc/devblog/day_220__working_through_backlog.mdwn
@@ -0,0 +1,14 @@
+Made a release yesterday, which was all bugfixes.
+
+Today, a few more bug fixes. Looked into making the webapp
+create non-bare repositories on removable drives, but before I got too far
+into the code, I noticed [there's a big problem with that idea](http://git-annex.branchable.com/forum/usability:_creating_an_archive_on_a_new_external_drive/).
+
+Rest of day was spent getting caught up on forum posts etc. I'm happy to
+read lots of good answers that have been posted while I've been away.
+Here's an excellent example: <http://git-annex.branchable.com/install/fromsource/#comment-5f8ceb060643ae71cd2adc72f0fca3f0>
+
+That led to rewriting the docs for building git-annex from source.
+New page: [[install/fromsource]].
+
+Backlog is now down to 117.
diff --git a/doc/devblog/day_221__another_fine_day_of_bugfixing.mdwn b/doc/devblog/day_221__another_fine_day_of_bugfixing.mdwn
new file mode 100644
index 0000000000..0c26f57359
--- /dev/null
+++ b/doc/devblog/day_221__another_fine_day_of_bugfixing.mdwn
@@ -0,0 +1,10 @@
+Working through the forum posts and bugs. Backlog is down to 95.
+
+Discovered the first known security hole in git-annex!
+Turns out that S3 and Glacier remotes that were configured with embedcreds=yes and encryption=pubkey or encryption=hybrid
+didn't actually encrypt the AWS credentials that get embedded into the git
+repo. This doesn't affect any repos set up by the assistant.
+
+I've fixed the problem and am going to make a release soon.
+If your repo is affected, see 
+[[upgrades/insecure_embedded_creds]] for what to do about it.
diff --git a/doc/devblog/day_222_preparing_for_debian_release.mdwn b/doc/devblog/day_222_preparing_for_debian_release.mdwn
new file mode 100644
index 0000000000..62acc02b22
--- /dev/null
+++ b/doc/devblog/day_222_preparing_for_debian_release.mdwn
@@ -0,0 +1,12 @@
+Made two releases of git-annex, yesterday and today, which turned out to
+contain only Debian changes. So no need for other users to upgrade.
+
+This included fixing building on mips, and arm architectures.
+The mips build was running out of memory, and I was able to work around
+that. Then the arm builds broke today, because of a recent change to the
+version of llvm that has completely trashed ghc. Luckily, I was able
+to work around that too.
+
+Hopefully that will get last week's security fix into Debian testing,
+and otherwise have git-annex in Debian in good shape for the upcoming
+freeze.
diff --git a/doc/devblog/day_223__partial_commit_problem.mdwn b/doc/devblog/day_223__partial_commit_problem.mdwn
new file mode 100644
index 0000000000..b2d1ec4e00
--- /dev/null
+++ b/doc/devblog/day_223__partial_commit_problem.mdwn
@@ -0,0 +1,26 @@
+`git commit $some_unlocked_file` seems like a reasonably common thing for
+someone to do, so it's surprising to find that it's a [[little bit broken|/bugs/modified_permissions_persist_after_unlock__44___commit]],
+leaving the file staged in the index after (correctly) committing the
+annexed symlink.
+
+This is caused by either a bug in git and/or by git-annex abusing the
+git post-commit hook to do something it shouldn't do, although it's not
+unique in using the post-commit hook this way. I'm talking this over with
+Junio, and the fix will depend on the result of that conversation. It might
+involve git-annex detecting this case and canceling the commit, asking the
+user to `git annex add` the file first. Or it might involve a new git hook,
+although I have not had good luck getting hooks added to git before.
+
+----
+
+Meanwhile, today I did some other bug fixing. Fixed the Internet Archive
+support for embedcreds=yes. Made `git annex map` work for remote repos
+in a directory with an implicit ".git" prefix. And fixed a
+strange problem where the repository repair code caused a `git gc` to run
+and then tripped over its pid file.
+
+I seem to have enough fixes to make another release pretty soon.
+Especially since the current release of git-annex doesn't build with yesod
+1.4.
+
+Backlog: 94 messages
diff --git a/doc/devblog/day_224-226__long_rainy_slog.mdwn b/doc/devblog/day_224-226__long_rainy_slog.mdwn
new file mode 100644
index 0000000000..9c26b134b9
--- /dev/null
+++ b/doc/devblog/day_224-226__long_rainy_slog.mdwn
@@ -0,0 +1,14 @@
+3 days spent redoing the Android autobuilder! The new version of
+yesod-routes generates TH splices that break the EvilSplicer. So after
+updating everything to new versions for the Nth time, I instead went back
+to older versions. The autobuilder now uses Debian jessie, instead of
+wheezy. And all haskell packages are pinned to use the same version
+as in jessie, rather than the newest versions. Since jessie is quite near
+to being frozen, this should make the autobuilder much less prone to
+getting broken by new versions of haskell packages that need patches for
+Android.
+
+I happened to stumble over <http://hackage.haskell.org/package/setenv>
+while doing that. This supports setting and unsetting environment variables
+on Windows, which I had not known a way to do from Haskell. Cleaned up
+several ugly corners of the Windows port using it.
diff --git a/doc/devblog/day_227__info.mdwn b/doc/devblog/day_227__info.mdwn
new file mode 100644
index 0000000000..0b5950fe51
--- /dev/null
+++ b/doc/devblog/day_227__info.mdwn
@@ -0,0 +1,33 @@
+Today, I've expanded `git annex info` to also be able to be used on annexed files
+and on remotes. Looking at the info for an individual remote is quite
+useful, especially for answering questions like: Does the remote have
+embedded creds? Are they encrypted? Does it use chunking? Is that old style
+chunking?
+
+<pre>
+remote: rsync.net
+description: rsync.net demo remote
+uuid: 15b42f18-ebf2-11e1-bea1-f71f1515f9f1
+cost: 250.0
+type: rsync
+url: xxx@usw-s002.rsync.net:foo
+encryption: encrypted (to gpg keys: 7321FC22AC211D23 C910D9222512E3C7)
+chunking: 1 MB chunks
+</pre>
+
+<pre>
+remote: ia3
+description: test [ia3]
+uuid: 12817311-a189-4de3-b806-5f339d304230
+cost: 200.0
+type: S3
+creds: embedded in git repository (not encrypted)
+bucket: joeyh-test-17oct-3
+internet archive item: http://archive.org/details/joeyh-test-17oct-3
+encryption: not encrypted
+chunking: none
+</pre>
+
+Should be quite useful info for debugging too..
+
+Yesterday, I fixed a bug that prevented retrieving files from Glacier.
diff --git a/doc/devblog/day_229__S3_multipart.mdwn b/doc/devblog/day_229__S3_multipart.mdwn
new file mode 100644
index 0000000000..caccda07ab
--- /dev/null
+++ b/doc/devblog/day_229__S3_multipart.mdwn
@@ -0,0 +1,11 @@
+Some progress on the [[bugs/S3_upload_not_using_multipart]] bug. The aws
+library now includes the multipart API. However, when I dug into it, it
+looks like the API needs some changes to get the ETAG of each uploaded
+part. Once that's fixed, git-annex should be able to support S3 multipart
+uploads, although I think that git-annex's own chunking is better in most
+situations -- it supports resuming uploads and downloads better. The main
+use case for S3 multipart seems to be using git-annex to publish large
+files.
+
+Also, managed to get the backlog down from 100 to just 65 messages,
+including catching up on quite old parts of backlog.
diff --git a/doc/devblog/day_22__gcrypt_on_rsync.net.mdwn b/doc/devblog/day_22__gcrypt_on_rsync.net.mdwn
new file mode 100644
index 0000000000..2c59517952
--- /dev/null
+++ b/doc/devblog/day_22__gcrypt_on_rsync.net.mdwn
@@ -0,0 +1,20 @@
+Being still a little unsure of the UI and complexity
+for configuring gcrypt on ssh servers, I thought I'd start today with the
+special case of gcrypt on rsync.net. Since rsync.net allows running some git
+commands, gcrypt can be used to make encrypted git repositories on it.
+
+Here's the UI I came up with. It's complicated a bit by needing to explain
+the tradeoffs between the rsync and gcrypt special remotes.
+
+[[!img /assistant/rsync.net.encryption.png]]
+
+This works fine, but I did not get a chance to add support for enabling
+existing gcrypt repos on rsync.net. Anyway, most of the changes to make
+this work will also make it easier to add general support for gcrypt on ssh
+servers.
+
+Also spent a while fixing a bug in git-remote-gcrypt. Oddly 
+`gpg --list-keys --fast-list --fingerprint` does not show the fingerprints
+of some keys.
+
+Today's work was sponsored by Cloudier - Thomas Djärv.
diff --git a/doc/devblog/day_230__S3_multipart_round_2.mdwn b/doc/devblog/day_230__S3_multipart_round_2.mdwn
new file mode 100644
index 0000000000..a73579df82
--- /dev/null
+++ b/doc/devblog/day_230__S3_multipart_round_2.mdwn
@@ -0,0 +1,9 @@
+More work on S3 multipart uploads, since the aws library got fixed today
+to return the ETAGs for the parts. I got multipart uploads fully working,
+including progress display.
+
+The code takes care to stream each part in from the file and out the
+socket, so I'd hoped it would have good memory behavior. However, for
+reasons I have not tracked down, something in the aws library is causing
+each part to be buffered in memory. This is a problem, since I want to
+use 1 gb as the default part size.
diff --git a/doc/devblog/day_231__S3_multipart_wrapped_up.mdwn b/doc/devblog/day_231__S3_multipart_wrapped_up.mdwn
new file mode 100644
index 0000000000..df8ecb601c
--- /dev/null
+++ b/doc/devblog/day_231__S3_multipart_wrapped_up.mdwn
@@ -0,0 +1,13 @@
+S3 multipart is finally completely working. I still don't understand the
+memory issue that stumped me yesterday, but rewrote the code to use a
+simpler approach, which avoids the problem. Various other issues, and
+testing it with large files, took all day.
+
+This is now merged into the `s3-aws` branch, so when that branch lands, S3
+support will massively improve, from the current situation of using a buggy
+library that buffers uploaded files in memory, and cannot support very
+large file uploads at all, to being able to support hopefully files of
+arbitrary hugeness (at least up to a few terabytes).
+
+BTW, thanks to Aristid Breitkreuz and Junji Hashimoto for working on the
+multipart support in the `aws` library.
diff --git a/doc/devblog/day_232__OSX_Yosemite.mdwn b/doc/devblog/day_232__OSX_Yosemite.mdwn
new file mode 100644
index 0000000000..468d7030ef
--- /dev/null
+++ b/doc/devblog/day_232__OSX_Yosemite.mdwn
@@ -0,0 +1,6 @@
+The OSX autobuilder has been updated to OSX 10.10 Yosemite. The 
+[resulting build](https://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg)
+might also work on 10.9 Mavericks too, and I'd appreciate help testing that.
+
+Went ahead and fixed the [[partial commit problem|bugs/modified_permissions_persist_after_unlock__44___commit]]
+by making the pre-commit hook detect and block problematic partial commits.
diff --git a/doc/devblog/day_233__direct_mode_proxy.mdwn b/doc/devblog/day_233__direct_mode_proxy.mdwn
new file mode 100644
index 0000000000..21a2f2d00c
--- /dev/null
+++ b/doc/devblog/day_233__direct_mode_proxy.mdwn
@@ -0,0 +1,29 @@
+Ever since the direct mode guard was added a year ago, direct mode has been
+a lot safer to use, but very limited in the git commands that could be run
+in a direct mode repository.
+
+The worst limitation was that there was no way to `git revert` unwanted
+changes. But also, there was no way to check out different branches,
+or run commands like `git mv`.
+
+Today I made `git annex proxy`, which allows doing all of those things,
+and more. [documentation here](http://git-annex.branchable.com/direct_mode/#index5h2)
+
+It's so flexible that I'm not sure where the boundries lie yet, but it
+seems it will work for any git command that updates both the work tree and
+the index. Some git commands only update one or the other and not both and
+won't work with the proxy. As an advanced user tool, I think this is a
+great solution. I still want to make a simpler
+[[undo command|todo/direct_mode_undo]] that can nicely integrate into file
+managers.
+
+The implementation of `git annex proxy` is
+[quite simple](http://source.git-annex.branchable.com/?p=source.git;a=blob;f=Command/Proxy.h), because it
+reuses all the complicated work tree update code that was already written
+for `git annex merge`.
+
+----
+
+And here's the lede I buried: I've gotten two years of funding to work
+on git-annex part-time!
+[Details in my personal blog](http://joeyh.name/blog/entry/continuing_to_be_pleasantly_surprised/).
diff --git a/doc/devblog/day_234__undo_undo.mdwn b/doc/devblog/day_234__undo_undo.mdwn
new file mode 100644
index 0000000000..270bee5d77
--- /dev/null
+++ b/doc/devblog/day_234__undo_undo.mdwn
@@ -0,0 +1,6 @@
+Built the `git annex undo` command. This is intended to be a simple
+interface for users who have changed one file, and want to undo the change
+without the complexities of `git revert` or `git annex proxy`. It's simple
+enough that I added undo as an action in the file manager integration.
+
+And yes, you can undo an undo. :)
diff --git a/doc/devblog/day_235__thanksgiving_backlog.mdwn b/doc/devblog/day_235__thanksgiving_backlog.mdwn
new file mode 100644
index 0000000000..4cc28b5a1c
--- /dev/null
+++ b/doc/devblog/day_235__thanksgiving_backlog.mdwn
@@ -0,0 +1,18 @@
+Back from the holiday, catching up on traffic. Backlog stands at 113
+messages.
+
+Here's a nice tip that Giovanni added:
+[[tips/publishing_your_files_to_the_public]] (using a public S3 bucket)
+
+Just before going on break, I added a new feature that I didn't mention
+here. `git annex diffdriver` integrates git-annex with git's external diff
+driver support. So if you have a smart diff program that can diff, say,
+genome sequences, or cat videos, or something in some useful way, it
+can be hooked up to `git diff` and will be able to see the content of
+annexed files.
+
+Also today, I spent a couple hours today updating the license file included
+in the standalone git-annex builds to include the licenses of all the
+haskell libraries git-annex depends on. Which I had for some reason not
+thought to include before, despite them getting built into the git-annex
+binary.
diff --git a/doc/devblog/day_236__release_day.mdwn b/doc/devblog/day_236__release_day.mdwn
new file mode 100644
index 0000000000..48cbce09d1
--- /dev/null
+++ b/doc/devblog/day_236__release_day.mdwn
@@ -0,0 +1,10 @@
+Today's release has a month's accumulated changes, including several nice
+new features: `git annex undo`, `git annex proxy`, `git annex diffdriver`,
+and I was able to land the s3-aws branch in this release too, so lots of
+improvements to the S3 support.
+
+Spent several hours getting the autobuilders updated, with the haskell
+`aws` library installed. Android and armel builds are still out of date.
+
+Also fixed two Windows bugs related to the location of the bundled ssh
+program.
diff --git a/doc/devblog/day_237__extending_addurl.mdwn b/doc/devblog/day_237__extending_addurl.mdwn
new file mode 100644
index 0000000000..e0129398ec
--- /dev/null
+++ b/doc/devblog/day_237__extending_addurl.mdwn
@@ -0,0 +1,14 @@
+Worked on [[todo/extensible_addurl]] today. When `git annex addurl` is run,
+remotes will be asked if they claim the url, and whichever remote does will
+be used to download it, and location tracking will indicate that remote
+contains the object. This is a masive 1000 line patch touching 30 files,
+including follow-on changes in `rmurl` and `whereis` and even `rekey`.
+
+It should now be possible to build an external special remote that handles
+*.torrent and magnet: urls and passes them off to a bittorrent client for
+download, for example.
+
+Another use for this would be to make an external special remote that
+uses youtube-dl or some other program than quvi for downloading web videos.
+The builtin quvi support could probably be moved out of the web special
+remote, to a separate remote. I haven't tried to do that yet.
diff --git a/doc/devblog/day_238__extending_addurl_further.mdwn b/doc/devblog/day_238__extending_addurl_further.mdwn
new file mode 100644
index 0000000000..0dd3764361
--- /dev/null
+++ b/doc/devblog/day_238__extending_addurl_further.mdwn
@@ -0,0 +1,67 @@
+Some more work on the interface that lets remotes claim urls for `git annex
+addurl`. Added support for remotes suggesting a filename to use when
+adding an url. Also, added support for urls that result in multiple files
+when downloaded. The obvious use case for that is an url to a torrent that
+contains multiple files.
+
+Then, got `git annex importfeed` to also check if a remote claims an url.
+
+Finally, I put together a quick demo external remote using this new
+interface. [[special_remotes/external/git-annex-remote-torrent]]
+adds support for torrent files to git-annex, using [aria2c](http://aria2.sourceforge.net/) to download them.
+It supports multi-file torrents, but not magnet links. (I'll probably
+rewrite this more robustly and efficiently in haskell sometime soon.)
+
+Here's a demo:
+
+<pre>
+# git annex initremote torrent type=external encryption=none externaltype=torrent
+initremote torrent ok
+(Recording state in git...)
+# ls
+# git annex addurl  --fast file:///home/joey/my.torrent
+  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
+                                 Dload  Upload   Total   Spent    Left  Speed
+100   198  100   198    0     0  3946k      0 --:--:-- --:--:-- --:--:-- 3946k
+addurl _home_joey_my.torrent/bar (using torrent) ok
+addurl _home_joey_my.torrent/baz (using torrent) ok
+addurl _home_joey_my.torrent/foo (using torrent) ok
+(Recording state in git...)
+# ls _home_joey_my.torrent/
+bar@  baz@  foo@
+# git annex get _home_joey_my.torrent/baz
+get _home_joey_my.torrent/baz (from torrent...) 
+  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
+                                 Dload  Upload   Total   Spent    Left  Speed
+  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:-100   198  100   198    0     0  3580k      0 --:--:-- --:--:-- --:--:-- 3580k
+
+12/11 18:14:56 [NOTICE] IPv4 DHT: listening on UDP port 6946
+
+12/11 18:14:56 [NOTICE] IPv4 BitTorrent: listening on TCP port 6961
+
+12/11 18:14:56 [NOTICE] IPv6 BitTorrent: listening on TCP port 6961
+
+12/11 18:14:56 [NOTICE] Seeding is over.
+12/11 18:14:57 [NOTICE] Download complete: /home/joey/tmp/tmp.Le89hJSXyh/tor
+
+12/11 18:14:57 [NOTICE] Your share ratio was 0.0, uploaded/downloaded=0B/0B
+                                                                               
+Download Results:
+gid   |stat|avg speed  |path/URI
+======+====+===========+=======================================================
+71f6b6|OK  |       0B/s|/home/joey/tmp/tmp.Le89hJSXyh/tor/baz
+
+Status Legend:
+(OK):download completed.
+ok                      
+(Recording state in git...)
+# git annex find
+_home_joey_my.torrent/baz
+# git annex whereis _home_joey_my.torrent/baz
+whereis _home_joey_my.torrent/baz (2 copies) 
+  	1878241d-ee49-446d-8cce-041c46442d94 -- [torrent]
+   	52412020-2bb3-4aa4-ae16-0da22ba48875 -- joey@darkstar:~/tmp/repo [here]
+
+  torrent: file:///home/joey/my.torrent#2
+ok
+</pre>
diff --git a/doc/devblog/day_239-240__bittorrent_remote.mdwn b/doc/devblog/day_239-240__bittorrent_remote.mdwn
new file mode 100644
index 0000000000..3b466540f3
--- /dev/null
+++ b/doc/devblog/day_239-240__bittorrent_remote.mdwn
@@ -0,0 +1,16 @@
+Spent a couple days adding a [[bittorrent_special_remote|special_remotes/bittorrent]]
+to git-annex. This is better than the demo external torrent remote I made
+on Friday: It's built into git-annex; it supports magnet links; it even
+parses aria2c's output so the webapp can display progress bars.
+
+Besides needing `aria2` to download torrents, it also currently depends on
+the `btshowmetainfo` command from the original bittorrent client (or
+bittornado). I looked into using
+<http://hackage.haskell.org/package/torrent> instead,
+but that package is out of date and doesn't currently build. I've got a
+patch fixing that, but am waiting to hear back from the library's author.
+
+There is a bit of a behavior change here; while before `git annex addurl` of
+a torrent file would add the torrent file itself to the repository, it now will
+download and add the contents of the torrent. I think/hope this behavior
+change is ok..
diff --git a/doc/devblog/day_23__GNU_day.mdwn b/doc/devblog/day_23__GNU_day.mdwn
new file mode 100644
index 0000000000..4f5b25ca77
--- /dev/null
+++ b/doc/devblog/day_23__GNU_day.mdwn
@@ -0,0 +1,23 @@
+Worked on making the assistant able to merge in existing encrypted
+git repositories from rsync.net.
+
+This had two parts. First, making the webapp UI where you click to enable a
+known special remote work with these encrypted repos. Secondly, handling
+the case where a user knows they have an encrypted repository on rsync.net,
+so enters in its hostname and path, but git-annex doesn't know about that
+special remote. The second case is important, for example, when the
+encrypted repository is a backup and you're restoring from it. It wouldn't
+do for the assistant, in that case, to make a *new* encrypted repo and
+push it over top of your backup!
+
+Handling that was a neat trick. It has to do quite a lot of probing, including
+downloading the whole encrypted git repo so it can decrypt it and merge it,
+to find out about the special remote configuration used for it. This all
+works with just 2 ssh connections, and only 1 ssh password prompt max.
+
+Next, on to generalizing this rsync.net specific code to work with
+arbitrary ssh servers!
+
+----
+
+Today's work was made possible by [RMS's vision 30 years ago](http://article.olduse.net/771@mit-eddie.UUCP).
diff --git a/doc/devblog/day_241-242__end_of_year_cleanup.mdwn b/doc/devblog/day_241-242__end_of_year_cleanup.mdwn
new file mode 100644
index 0000000000..4044ae183f
--- /dev/null
+++ b/doc/devblog/day_241-242__end_of_year_cleanup.mdwn
@@ -0,0 +1,22 @@
+Took a holiday week off from git-annex development, and started a new side
+project building [shell-monad](http://joeyh.name/code/shell-monad/), which
+might eventually be used in some parts of git-annex that generate shell
+scripts.
+
+Message backlog is 165 and I have not dove back into it, but I have started
+spinning back up the development engines in preparation for new year
+takeoff. 
+
+Yesterday, added some minor new features -- `git annex sync` now
+supports git remote groups, and I added a new plumbing command
+`setpresentkey` for those times when you really need to mess with
+git-annex's internal bookkeeping. Also cleaned up a lot of build warning
+messages on OSX and Windows.
+
+Today, first some improvements to make `addurl` more robust.
+Then the rest of the day was spent on Windows. Fixed (again)
+the Windows port's problem with rsync hating DOS style filenames. Got
+the rsync special remote fully working on Windows for the first time.
+
+Best of all, got the Windows autobuilder to run the test
+suite successfully, and fixed a couple test suite failures on Windows.
diff --git a/doc/devblog/day_243__android_5.mdwn b/doc/devblog/day_243__android_5.mdwn
new file mode 100644
index 0000000000..96bf67268a
--- /dev/null
+++ b/doc/devblog/day_243__android_5.mdwn
@@ -0,0 +1,16 @@
+I've finally been clued into why [git-annex isn't working on Android 5](http://git-annex.branchable.com/bugs/__91__Android__93___5.0_needs_PIE_executables___40__git_annex_does_not_work_on_android_5.0__41__/), and
+it seems fixing it is as easy as pie.. That is, passing -pie -FPIE to the
+linker. I've added a 5.0 build to the Android autobuilder. It is currently
+untested, so I hope to get feedback from someone with an Android 5 device;
+a [test build](http://downloads.kitenet.net/git-annex/autobuild/android/5.0/git-annex.apk) is now available.
+
+I've been working through the backlog of messages today, and gotten down
+from 170 to 128. Mostly answered a lot of interesting questions, 
+such as "[Where to start reading the source code?](http://git-annex.branchable.com/install/fromsource/#comment-cb68f2aa0a598d0150db852834ea07da)"
+
+Also did some work to make git-annex check git versions at runtime more
+often, instead of assuming the git version it was built against. 
+It turns out this could be done pretty inexpensively in 2 of 4 cases,
+and one of the 2 fixed was the git check-attr behavior change, 
+which could lead to git-annex add hanging if used with an old version of
+git.
diff --git a/doc/devblog/day_243__android_5/comment_1_59a139108f4cf20dd7443a5fa767f614._comment b/doc/devblog/day_243__android_5/comment_1_59a139108f4cf20dd7443a5fa767f614._comment
new file mode 100644
index 0000000000..a3acbbd42e
--- /dev/null
+++ b/doc/devblog/day_243__android_5/comment_1_59a139108f4cf20dd7443a5fa767f614._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkGCmVc5qIJaQQgG82Hc5zzBdAVdhe2JEM"
+ nickname="Bruno"
+ subject="comment 1"
+ date="2015-01-06T01:52:03Z"
+ content="""
+I got \"error: only position independent executables (PIE) are supported\" on a Nexus 4 (Android 5.0.1)
+http://i.imgur.com/TXO4fcf.png
+"""]]
diff --git a/doc/devblog/day_244__relative_paths.mdwn b/doc/devblog/day_244__relative_paths.mdwn
new file mode 100644
index 0000000000..f631dbc8fb
--- /dev/null
+++ b/doc/devblog/day_244__relative_paths.mdwn
@@ -0,0 +1,14 @@
+git-annex internally uses all absolute paths all the time.
+For a couple of reasons, I'd like it to use relative paths.
+The best reason is, it would let a repository be moved while git-annex was
+running, without breaking. A lesser reason is that Windows has some
+crazy small limit on the length of a path (260 bytes?!), and using relative
+paths would avoid hitting it so often.
+
+I tried to do this today, in a `relativepaths` branch. I eventually got the
+test suite to pass, but I am very unsure about this change. A lot of random
+assumptions broke, and the test suite won't catch them all. In a few
+places, git-annex commands do change the current directory, and that
+will break with relative paths.
+
+A frustrating day.
diff --git a/doc/devblog/day_245__yak_shaving.mdwn b/doc/devblog/day_245__yak_shaving.mdwn
new file mode 100644
index 0000000000..0e1a7dbaf3
--- /dev/null
+++ b/doc/devblog/day_245__yak_shaving.mdwn
@@ -0,0 +1,9 @@
+Worked more on the `relativepaths` branch last night, and I am actually
+fairly happy with it now, and plan to merge it after I've run it for a bit
+longer myself.
+
+It seems that I did manage to get a git-annex executable that is built PIE
+so it will work on Android 5.0. But all the C programs like busybox
+included in the Android app also have to be built that way. Arranging for
+everything to get built twice and with the right options took up most of
+today.
diff --git a/doc/devblog/day_246__old_todos.mdwn b/doc/devblog/day_246__old_todos.mdwn
new file mode 100644
index 0000000000..6957cff525
--- /dev/null
+++ b/doc/devblog/day_246__old_todos.mdwn
@@ -0,0 +1,9 @@
+Got a release out today.
+
+I'm feeling a little under the weather, so wanted something easy to do in
+the rest of the day that would be nice and constructive. Ended up going
+over the todo list. Old todos come in three groups; hard problems, already
+solved, and easy changes that never got done. I left the first group alone,
+closed many todos in the second group, and implemented a few easy changes.
+Including `git annex sync -m` and adding some more info to `git annex info
+remote`.
diff --git a/doc/devblog/day_247__hooks_and_large_files_on_windows.mdwn b/doc/devblog/day_247__hooks_and_large_files_on_windows.mdwn
new file mode 100644
index 0000000000..59865b36bd
--- /dev/null
+++ b/doc/devblog/day_247__hooks_and_large_files_on_windows.mdwn
@@ -0,0 +1,30 @@
+Today I got The pre-commit-annex hook working on Windows. It turns out that
+msysgit runs hook scripts even when they're not executable, and it parses
+the #! line itself. Now git-annex does too, on Windows.
+
+Also, added a new chapter to the walkthrough,
+[[walkthrough/using_special_remotes]]. They clearly needed to be mentioned,
+especially to show the workflow of running initremote in one repository,
+then syncing another repository and running enableremote to enable the same
+special remote there.
+
+Then more fun Windows porting! Turns out git-annex on Windows didn't handle
+files > 2 gb correctly; the way it was getting file size 
+[uses a too small data type on Windows](https://github.com/jystic/unix-compat/issues/16).
+Luckily git-annex itself treats all file sizes as unbounded Integers,
+so I was easily able to swap in a `getFileSize` that returns correct
+values for large files.
+
+While I haven't blogged since the 13th and have not been too active until
+today, there are still a number of little improvements that have been done
+here and there.
+
+Including a fix for an interesting bug where the assistant would tell
+the remotedaemon that the network connection has been lost, twice in a row,
+and this would make the remotedeamon fail to reconnect to the remote when
+the network came up. I'm not sure what situation triggers this bug (Maybe
+machines with 2 interfaces? Or maybe a double disconnection event for 1
+interface?), but I was able to reproduce it by sending messages to the
+remotedaemon, and so fixed it.
+
+Backlog is down to 118 messages.
diff --git a/doc/devblog/day_248__workload_tuning.mdwn b/doc/devblog/day_248__workload_tuning.mdwn
new file mode 100644
index 0000000000..d0677fc60b
--- /dev/null
+++ b/doc/devblog/day_248__workload_tuning.mdwn
@@ -0,0 +1,54 @@
+Today I put together a lot of things I've been thinking about:
+
+* There's some evidence that git-annex needs tuning to handle some unusual
+  repositories. In particular very big repositories might benefit from
+  different object hashing.
+* It's really hard to handle [[upgrades]] that change the fundamentals of
+  how git-annex repositories work. Such an upgrade would need every
+  git-annex user to upgrade their repository, and would be very painful.
+  It's hard to imagine a change that is worth that amount of pain.
+* There are other changes some would like to see (like lower-case object
+  hash directory names) that are certainly not enough to warrant a flag
+  day repo format upgrade.
+* It would be nice to let people who want to have some flexibility to play
+  around with changes, in their own repos, as long as they don't a)
+  make git-annex a lot more complicated, or b) negatively impact others.
+  (Without having to fork git-annex.)
+
+This is discussed in more depth in [[design/new_repo_versions]].
+
+The solution, which I've built today, is support for
+[[tuning]] settings, when a new repository is first created. The resulting
+repository will be different in some significant way from a default
+git-annex repository, but git-annex will support it just fine. 
+
+The main limitations are:
+
+* You can't change the tuning of an existing repository
+  (unless a tool gets written to transition it).
+* You absolutely don't want to merge repo B, which has been tuned in
+  nonstandard ways, into repo A which has not. Or A into B. (Unless you like
+  watching slow motion car crashes.)
+
+I built all the infrastructure for this today. Basically, the git-annex
+branch gets a record of all tunings that have been applied, and they're
+automatically propagated to new clones of a repository.
+
+And I implemented the first tunable setting:
+
+	git -c annex.tune.objecthashlower=true annex init
+
+This is definitely an experimental feature for now.
+`git-annex merge` and similar commands will detect attempts to merge
+between incompatibly tuned repositories, and error out. But, there are a
+lot of ways to shoot yourself in the foot if you use this feature:
+
+* Nothing stops `git merge` from merging two incompatible repositories.
+* Nothing stops any version of git-annex older from today from merging
+  either.
+
+Now that the groundwork is laid, I can pretty easily, and inexpensively,
+add more tunable settings. The next two I plan to add are already
+documented, `annex.tune.objecthashdirectories` and 
+`annex.tune.branchhashdirectories`. Most new tunables should take about 4
+lines of code to add to git-annex.
diff --git a/doc/devblog/day_249_onward.mdwn b/doc/devblog/day_249_onward.mdwn
new file mode 100644
index 0000000000..dac851c542
--- /dev/null
+++ b/doc/devblog/day_249_onward.mdwn
@@ -0,0 +1,28 @@
+Made a release yesterday, and caught up on most recent messages
+earlier this week. Backlog stands at 128 messages.
+
+Had to deal with an ugly problem with /usr/bin/glacier today. Seems that
+there are multiple programs all using that name, some of them shipping in
+some linux distributions, and the one from boto fails to fail when passed
+parameters it doesn't understand. Yugh! I had to make git-annex probe to
+make sure the right glacier program is installed.
+
+I'm planning to deprecate the glacier special remote at some point.
+Instead, I'd like to make the S3 special remote support the S3-glacier
+lifecycle, so objects can be uploaded to S3, set to transition to
+glacier, and then if necessary pulled back from glacier to S3. That should
+be much simpler and less prone to break.
+
+But not yet; [haskell-aws needs glacier support added](https://github.com/aristidb/aws/issues/81).
+Or I could use the new amazonka library, but I'd rather stick with
+haskell-aws.
+
+Some other minor improvements today included adding `git annex
+groupwanted`, which makes for easier examples than using vicfg, and
+making `git annex import` support options like --include and --exclude.
+
+Also I moved a many file matching options to only be accepted by
+the commands that actually use them. Of the remaining common
+options, most of them make sense for every command to accept (eg, --force
+and --debug). It would make sense to move --backend, --notify-start/finish,
+and perhaps --user-agent. Eventually.
diff --git a/doc/devblog/day_249_onward/comment_1_80af832a132ee37a470d0586ae751f2a._comment b/doc/devblog/day_249_onward/comment_1_80af832a132ee37a470d0586ae751f2a._comment
new file mode 100644
index 0000000000..d5984716d8
--- /dev/null
+++ b/doc/devblog/day_249_onward/comment_1_80af832a132ee37a470d0586ae751f2a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlOl_Hf78lWy2iVDHYIey_zc1qVBQjlJgw"
+ nickname="Stefan"
+ subject="comment 1"
+ date="2015-02-07T10:04:31Z"
+ content="""
+Please announce that deprecation well in advance, though. I feel your pain and have started to migrate to an S3->Glacier setup myself, but getting data out of Glacier is fairly expensive if done quickly. 
+
+(And due to git-annex' ease of adding more data, I got a fairly large amount of backups, and would also prefer not to be stuck on an old version of git-annex just for Glacier support.)
+"""]]
diff --git a/doc/devblog/day_249_onward/comment_2_ada958a8df4da36b25a456a7700b310f._comment b/doc/devblog/day_249_onward/comment_2_ada958a8df4da36b25a456a7700b310f._comment
new file mode 100644
index 0000000000..881eef278a
--- /dev/null
+++ b/doc/devblog/day_249_onward/comment_2_ada958a8df4da36b25a456a7700b310f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-02-09T18:38:27Z"
+ content="""
+Don't worry, by "deprecate glacier", I mean at worst "refuse to make new glacier
+remotes". No plans to remove a remote that someone is using.
+"""]]
diff --git a/doc/devblog/day_24__nearly_done_with_gcrypt.mdwn b/doc/devblog/day_24__nearly_done_with_gcrypt.mdwn
new file mode 100644
index 0000000000..22d3fa70b5
--- /dev/null
+++ b/doc/devblog/day_24__nearly_done_with_gcrypt.mdwn
@@ -0,0 +1,23 @@
+So close to being done with gcrypt support.. But still not quite there.
+
+Today I made the UI changes to support gcrypt when setting up a repository
+on a ssh server, and improved the probing and data types so it can tell
+which options the server supports. Fairly happy with how that is turning
+out.
+
+Have not yet hooked up the new buttons to make gcrypt repos. While I was
+testing that my changes didn't break other stuff, I found a bug in the
+webapp that caused it to sometimes fail to transfer one file to/from a
+remote that was just added, because the transferrer process didn't know
+about the new remote yet, and crashed (and was restarted knowing about it,
+so successfully sent any other files). So got sidetracked on fixing that.
+
+Also did some work to make the gpg bundled with git-annex on OSX be
+compatable with the config files written by MacGPG. At first I was going to
+hack it to not crash on the options it didn't support, but it turned out
+that upgrading to version 1.4.14 actually fixed the problem that was making
+it build without support for DNS.
+
+----
+
+Today's work was sponsored by Thomas Hochstein.
diff --git a/doc/devblog/day_250__backog_bugfixing.mdwn b/doc/devblog/day_250__backog_bugfixing.mdwn
new file mode 100644
index 0000000000..9f5d3239bc
--- /dev/null
+++ b/doc/devblog/day_250__backog_bugfixing.mdwn
@@ -0,0 +1,10 @@
+Plowing through the backlog today, and fixing quite a few bugs! Got the
+backlog down to 87 messages from ~140. And some of the things I got to were
+old and/or hard.
+
+About a third of the day was spent revisiting
+[[bugs/git-annex_branch_shows_commit_with_looong_commitlog]].
+I still don't understand how that behavior can happen, but I have a
+donated repository where it did happen. Made several changes to try to make
+the problem less likely to occur, and not as annoying when it does occur,
+and maybe get me more info if it does happen to someone again.
diff --git a/doc/devblog/day_251-252__dusting_off_the_roadmap.mdwn b/doc/devblog/day_251-252__dusting_off_the_roadmap.mdwn
new file mode 100644
index 0000000000..0a0e50f645
--- /dev/null
+++ b/doc/devblog/day_251-252__dusting_off_the_roadmap.mdwn
@@ -0,0 +1,12 @@
+Many more little improvements made yesterday and part of today. While
+it's only been a week since the last release, it feels almost time
+to make another one, after so many recent bug fixes and small improvements.
+
+I've updated the [[design/roadmap]]. I have been operating without a
+roadmap for half a year, and it would be nice to have some plans.
+Keeping up with bug reports and requests as they come in is a fine mode
+of work, but it can feel a little aimless. It's good to have a planned out
+course, or at least some longer term goals.
+
+After the next release, I've penciled in the second half of this month to
+work on the [[design/caching_database]].
diff --git a/doc/devblog/day_253__sqlite_for_incremental_fsck.mdwn b/doc/devblog/day_253__sqlite_for_incremental_fsck.mdwn
new file mode 100644
index 0000000000..0b5f42c79d
--- /dev/null
+++ b/doc/devblog/day_253__sqlite_for_incremental_fsck.mdwn
@@ -0,0 +1,58 @@
+[[!meta title="day 254  sqlite for incremental fsck"]]
+
+Yesterday I did a little more investigation of key/value stores.
+I'd love a pure haskell key/value store that didn't buffer everything in
+memory, and that allowed concurrent readers, and was ACID, and production
+quality. But so far, I have not found anything that meets all those
+criteria. It seems that sqlite is the best choice for now.
+
+Started working on the `database` branch today. The plan is to use
+sqlite for incremental fsck first, and if that works well, do the rest
+of what's planned in [[design/caching_database]].
+
+At least for now, I'm going to use a dedicated database file for each
+different thing. (This may not be as space-efficient due to lacking
+normalization, but it keeps things simple.) 
+
+So, .git/annex/fsck.db will be used by incremental fsck, and it has
+a super simple Persistent database schema:
+
+[[!format haskell """
+Fscked
+  key SKey
+  UniqueKey key
+"""]]
+
+It was pretty easy to implement this and make incremental fsck use it. The
+hard part is making it both fast and robust.
+
+At first, I was doing everything inside a single `runSqlite` action.
+Including creating the table. But, it turns out that runs as a single
+transaction, and if it was interrupted, this left the database in a
+state where it exists, but has no tables. Hard to recover from.
+
+So, I separated out creating the database, made that be done in a separate
+transation and fully atomically. Now `fsck --incremental` could be crtl-c'd
+and resumed with `fsck --more`, but it would lose the transaction and so
+not remember anything had been checked.
+
+To fix that, I tried making a separate transation per file fscked. That
+worked, and it resumes nicely where it left off, but all those transactions
+made it much slower.
+
+To fix the speed, I made it commit just one transaction per minute. This
+seems like an ok balance. Having fsck re-do one minute's work when restarting
+an interrupted incremental fsck is perfectly reasonable, and now the speed,
+using the sqlite database, is nearly as fast as the old sticky bit hack was.
+(Specifically, 6m7s old vs 6m27s new, fscking 37000 files from cold cache
+in --fast mode.)
+
+There is still a problem with multiple concurrent `fsck --more`
+failing. Probably a concurrent writer problem? And, some porting will be
+required to get sqlite and persistent working on Windows and Android.
+So the branch isn't ready to merge yet, but it seems promising.
+
+In retrospect, while incremental fsck has the simplest database schema, it
+might be one of the harder things listed in [[design/caching_database]], 
+just because it involves so many writes to the database. The other use
+cases are more read heavy.
diff --git a/doc/devblog/day_253__sqlite_for_incremental_fsck/comment_1_683d669ac6af8e314585609f75cfdaf3._comment b/doc/devblog/day_253__sqlite_for_incremental_fsck/comment_1_683d669ac6af8e314585609f75cfdaf3._comment
new file mode 100644
index 0000000000..17d1d11cf2
--- /dev/null
+++ b/doc/devblog/day_253__sqlite_for_incremental_fsck/comment_1_683d669ac6af8e314585609f75cfdaf3._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 1"
+ date="2015-02-16T21:26:22Z"
+ content="""
+i am curious: why separate database files while you can have multiple tables in the same database file? --[[anarcat]]
+"""]]
diff --git a/doc/devblog/day_253__sqlite_for_incremental_fsck/comment_2_08dd639180ae79addc007ee47d52048a._comment b/doc/devblog/day_253__sqlite_for_incremental_fsck/comment_2_08dd639180ae79addc007ee47d52048a._comment
new file mode 100644
index 0000000000..481c3df4bb
--- /dev/null
+++ b/doc/devblog/day_253__sqlite_for_incremental_fsck/comment_2_08dd639180ae79addc007ee47d52048a._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-02-17T20:15:36Z"
+ content="""
+@anarcat, see [[design/caching_database]] for my thinking on that.
+"""]]
diff --git a/doc/devblog/day_253__ssh-options.mdwn b/doc/devblog/day_253__ssh-options.mdwn
new file mode 100644
index 0000000000..805363f3c5
--- /dev/null
+++ b/doc/devblog/day_253__ssh-options.mdwn
@@ -0,0 +1,5 @@
+Spent a couple hours to make the ssh-options git config setting be used
+in more places. Now it's used everywhere that git-annex supports ssh
+caching, including the `git pull` and `git push` done by `sync` and by the
+assistant. Also the `remotedaemon` and the gcrypt, rsync, and ddar
+special remotes.
diff --git a/doc/devblog/day_255__sqlite_concurrent_writers_problem.mdwn b/doc/devblog/day_255__sqlite_concurrent_writers_problem.mdwn
new file mode 100644
index 0000000000..05b431a4dc
--- /dev/null
+++ b/doc/devblog/day_255__sqlite_concurrent_writers_problem.mdwn
@@ -0,0 +1,34 @@
+Worked today on making incremental fsck's use of sqlite be safe with
+multiple concurrent fsck processes.
+
+The first problem was that having `fsck --incremental` running and starting a
+new `fsck --incremental` caused it to crash. And with good reason, since
+starting a new incremental fsck deletes the old database, the old process
+was left writing to a database that had been deleted and recreated out from
+underneath it. Fixed with some locking.
+
+Next problem is harder. Sqlite doesn't support multiple concurrent writers
+at all. One of them will fail to write. It's not even possible to have two
+processes building up separate transactions at the same time. Before using
+sqlite, incremental fsck could work perfectly well with multiple fsck
+processes running concurrently. I'd like to keep that working.
+
+My partial solution, so far, is to make git-annex buffer writes, and every
+so often send them all to sqlite at once, in a transaction. So most of the
+time, nothing is writing to the database. (And if it gets unlucky and
+a write fails due to a collision with another writer, it can just wait and
+retry the write later.) This lets multiple processes write to the database
+successfully.
+
+But, for the purposes of concurrent, incremental fsck, it's not ideal.
+Each process doesn't immediately learn of files that another process has
+checked. So they'll tend to do redundant work. Only way I can see to
+improve this is to use some other mechanism for short-term IPC between the
+fsck processes.
+
+----
+
+Also, I made `git annex fsck --from remote --incremental` use a different
+database per remote. This is a real improvement over the sticky bits;
+multiple incremental fscks can be in progress at once, 
+checking different remotes.
diff --git a/doc/devblog/day_256__sqlite_concurrency_argh.mdwn b/doc/devblog/day_256__sqlite_concurrency_argh.mdwn
new file mode 100644
index 0000000000..df02d47be7
--- /dev/null
+++ b/doc/devblog/day_256__sqlite_concurrency_argh.mdwn
@@ -0,0 +1,28 @@
+Breaking news: gitlab.com repositories now support git-annex!
+
+* [GitLab Annex solves the problem of versioning large binaries with git](https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/)
+* [freely licensed source code](https://gitlab.com/gitlab-org/gitlab-shell)
+
+A very nice surprise! More git hosters should do this..
+
+----
+
+Back to sqlite concurrency, I thought I had it dealt with, but more testing
+today has turned up a lot more problems with sqlite and concurrent writers
+(and readers).
+
+First, I noticed that a process can be happily writing changes to the
+database, but if a second process starts reading from the database, this
+will make the writier start failing with BUSY, and keep failing until the
+second process goes idle. It turns out the solution to this is to use WAL 
+mode, which prevents readers from blocking writers.
+
+After several hours (persistent doesn't make it easy to enable WAL mode),
+it seemed pretty robust with concurrent fsck.
+
+But then I saw SELECT fail with BUSY. I don't understand why a reader would
+fail in WAL mode; that's counter to the documentation. My best guess is
+that this happens when a checkpoint is being made.
+
+This seems to be a real bug in sqlite. It may only affect the older
+versions bundled with persistent.
diff --git a/doc/devblog/day_257__release_day.mdwn b/doc/devblog/day_257__release_day.mdwn
new file mode 100644
index 0000000000..bd3057145c
--- /dev/null
+++ b/doc/devblog/day_257__release_day.mdwn
@@ -0,0 +1,17 @@
+Today's release doesn't have the database branch merged of course, but it
+still has a significant amount of changes.
+
+Developed a test case for the sqlite problem, that
+reliably reproduces it, and sent it to the sqlite mailing list. It seems
+that under heavy write load, when a new connection is made to the database,
+SELECT can fail for a little while. Once one SELECT succeeds, that database
+connection becomes solid, and won't fail any more (apparently). This makes
+me think there might be some connection initialization steps that don't end
+up finishing before the SELECT goes through in this situation. I should be
+able to work around this problem by probing new connections for stability,
+and probably will have to, since it'll be years before any bug fixed sqlite
+is available everywhere.
+
+I also noticed that current git-annex incremental parallel fsck doesn't
+really parallelize well; eg the processes do duplicate work. So, the
+database branch is not really a regression in this area.
diff --git a/doc/devblog/day_258__database_branch_merged.mdwn b/doc/devblog/day_258__database_branch_merged.mdwn
new file mode 100644
index 0000000000..97cae78b5d
--- /dev/null
+++ b/doc/devblog/day_258__database_branch_merged.mdwn
@@ -0,0 +1,25 @@
+I'm snowed in, but keeping busy..
+
+Developed a complete workaround for the [sqlite SELECT ErrorBusy bug](http://news.gmane.org/find-root.php?message_id=20150219163255.GA13383%40kitenet.net).
+So after a week, I finally have sqlite working robustly. And, I merged in
+the branch that uses sqlite for incremental fsck.
+
+Benchmarking an incremental fsck --fast run, checking 40 thousand files,
+it used to take 4m30s using sticky bits, and using sqlite slowed it down by
+10s. So one added second per 4 thousand or so files. I think that's ok.
+Incremental fsck is intended to be used in big repos, which are probably not
+checked in --fast most, so the checksumming of files will by far swamp
+that overhead.
+
+Also got sqlite and persistent installed on all the autobuilders. This
+was easier than expected, because persistent bundles its own copy of
+sqlite.
+
+That would have been a good stopping place for the day's work.. But then I
+got to spent 5 more hours getting the EvilSplicer to support Persistent.
+Urgh. :-/
+
+Now I can look forward to using sqlite for something more interesting than
+incremental fsck, like metadata caching for views, or the direct mode mappings.
+But, given all the trouble I had with sqlite, I'm going to put that off for
+a little while, to make sure that I've really gotten sqlite to work robustly.
diff --git a/doc/devblog/day_259__submodules.mdwn b/doc/devblog/day_259__submodules.mdwn
new file mode 100644
index 0000000000..a2178a80fb
--- /dev/null
+++ b/doc/devblog/day_259__submodules.mdwn
@@ -0,0 +1,8 @@
+I had thought that git-annex and git submodules couldn't mix. However,
+looking at it again, it turned out to be possible to use git-annex quite
+sanely in a submodule, with just a little tweaking of how git normally
+configures the repository. Details of this still experimental feature are in
+[[/submodules]].
+
+There is still some work to be done to make git-annex work with submodules
+in repositories on filesystems that don't support symlinks.
diff --git a/doc/devblog/day_25__finishing_up_gcrypt.mdwn b/doc/devblog/day_25__finishing_up_gcrypt.mdwn
new file mode 100644
index 0000000000..9666282d0e
--- /dev/null
+++ b/doc/devblog/day_25__finishing_up_gcrypt.mdwn
@@ -0,0 +1,25 @@
+Long day, but I did finally finish up with gcrypt support. More or less.
+
+Got both creating and enabling existing gcrypt repositories on ssh servers
+working in the webapp. (But I ran out of time to make it detect when the
+user is manually entering a gcrypt repo that already exists. Should be easy
+so maybe tomorrow.)
+
+Fixed several bugs in git-annex's gcrypt support that turned up in testing.
+Made git-annex ensure that a gcrypt repository does not have
+receive.denyNonFastForwards set, because gcrypt relies on always forcing
+the push of the branch it stores its manifest on. Fixed a bug in
+`git-annex-shell recvkey` when it was receiving a file from an annex in
+direct mode.
+
+Also had to add a new `git annex shell gcryptsetup` command, which is
+needed to make setting up a gcrypt repository work when the assistant
+has set up a locked-down ssh key that can only run git-annex-shell. Painted
+myself into a bit of a corner there.
+
+And tested, tested, tested. So many possibilities and edge cases in this
+part of the code..
+
+----
+
+Today's work was sponsored by Hendrik Müller Hofstede.
diff --git a/doc/devblog/day_260__random_month.mdwn b/doc/devblog/day_260__random_month.mdwn
new file mode 100644
index 0000000000..2d71c04dd0
--- /dev/null
+++ b/doc/devblog/day_260__random_month.mdwn
@@ -0,0 +1,27 @@
+This month is going to be a bit more random than usual where git-annex
+development is concerned.
+
+* On Saturday, the [Seven Day Roguelike](http://7drl.org/) competition
+  begins, and I will be spending a week building a game in haskell,
+  to the exclusion of almost all other work.
+* On March 18th, I'll be at the [Boston Haskell User's group](http://www.meetup.com/Boston-Haskell/events/219298257/).
+  (Attending, not presenting.)
+* March 19-20, I'll be at Dartmouth visiting with the DataLad developers
+  and learning more about what it needs from git-annex.
+* March 21-22, I'll be at the FSF's [LibrePlanet](https://libreplanet.org/2015)
+  conference at MIT.
+
+Got started on the randomness today with this 
+[[design proposal for using git-annex to back up the entire Internet Archive|design/iabackup]].
+This is something the Archive Team is [considering taking on](http://archiveteam.org/index.php?title=INTERNETARCHIVE.BAK),
+and I had several hours driving and hiking to think about it and came up
+with a workable design. (Assuming large enough crowd of volunteers.)
+
+Don't know if it will happen, but it was a useful thought problem to see how
+git-annex works, and doesn't work in this unusual use case.
+
+One interesting thing to come out of that is that git-annex fsck does not
+currently make any record of successful fscks. In a very large distributed
+system, it can be useful to have successful fscks of an object's content recorded,
+by updating the timestamp in the location log to say "this repository still
+had the content at this time".
diff --git a/doc/devblog/day_261__random_improvements.mdwn b/doc/devblog/day_261__random_improvements.mdwn
new file mode 100644
index 0000000000..bc0478e5cd
--- /dev/null
+++ b/doc/devblog/day_261__random_improvements.mdwn
@@ -0,0 +1,5 @@
+Fixed a mojibake bug that affected metadata values that included both
+whitespace and unicode characters. This was very fiddly to get right.
+
+Finished up Monday's work to support submodules, getting them working
+on filesystems that don't support symlinks.
diff --git a/doc/devblog/day_262__ipfs.mdwn b/doc/devblog/day_262__ipfs.mdwn
new file mode 100644
index 0000000000..9ae79c8c77
--- /dev/null
+++ b/doc/devblog/day_262__ipfs.mdwn
@@ -0,0 +1,16 @@
+Did a deep dive into [ipfs](http://ipfs.io/) last night. It has great
+promise.
+
+As a first step toward using it with git-annex, I built an experimental
+[[ipfs_special_remote|special_remotes/ipfs]]. It has some nice abilities;
+any ipfs address can be downloaded to a file in the repository:
+
+	git annex addurl ipfs:QmYgXEfjsLbPvVKrrD4Hf6QvXYRPRjH5XFGajDqtxBnD4W --file somefile
+
+And, any file in the git-annex repository can be published to the world
+via ipfs, by simply using `git annex copy --to ipfs`. The ipfs address
+for the file is then visible in `git annex whereis`.
+
+Had to extend the external special remote protocol slightly for that, so
+that ipfs addresses can be recorded as uris in git-annex, and will show up
+in `git annex whereis`.
diff --git a/doc/devblog/day_263__diving_back_in.mdwn b/doc/devblog/day_263__diving_back_in.mdwn
new file mode 100644
index 0000000000..29a73774bc
--- /dev/null
+++ b/doc/devblog/day_263__diving_back_in.mdwn
@@ -0,0 +1,7 @@
+After an intense week away, I didn't mean to work on git-annex today, but I
+got sucked back in..
+
+Worked on some plumbing commands for mass repository creation.
+Made `fromkey` be able to read a stream of files to create from stdin.
+Added a new `registerurl` plumbing command, that reads a stream of keys and
+urls from stdin.
diff --git a/doc/devblog/day_264__catching_up.mdwn b/doc/devblog/day_264__catching_up.mdwn
new file mode 100644
index 0000000000..6c68d0be45
--- /dev/null
+++ b/doc/devblog/day_264__catching_up.mdwn
@@ -0,0 +1,7 @@
+Caught up with most of the recent backlog today. Was not very bad.
+
+Fixed `remotedaemon` to support gcrypt remotes, which was never
+quite working before.
+
+Seem to be on track to making a release tomorrow with a whole month's
+changes.
diff --git a/doc/devblog/day_265__at_Dartmouth.mdwn b/doc/devblog/day_265__at_Dartmouth.mdwn
new file mode 100644
index 0000000000..80d6df54e6
--- /dev/null
+++ b/doc/devblog/day_265__at_Dartmouth.mdwn
@@ -0,0 +1,4 @@
+Spent a couple of days at Dartmouth hanging out in the neuroscience
+department with the [Datalad](http://datalad.org/) developers.
+Added several new plumbing commands and a new post-update-annex hook,
+based on their feedback of how they're using git-annex.
diff --git a/doc/devblog/day_266-267__man_page_split.mdwn b/doc/devblog/day_266-267__man_page_split.mdwn
new file mode 100644
index 0000000000..6239e7dfdf
--- /dev/null
+++ b/doc/devblog/day_266-267__man_page_split.mdwn
@@ -0,0 +1,16 @@
+While traveling for several days, I filled dead time with a rather massive
+reorganization of the git-annex man page, and I finished that up this
+morning.
+
+That man page had gotten rather massive, at around 3 thousand lines. I
+split out 87 man pages, one for each git-annex command. Many of these were
+expanded with additional details, and have become a lot better thanks
+to the added focus and space. See for example, [[git-annex-find]],
+or any of the links on the new [[git-annex]] man page. (Which is still over
+1 thousand lines long..)
+
+Also, `git annex help <command>` can be used to pull up a command's man
+page now!
+
+I'm taking the rest of the day off to R&R from the big trip north, and
+expect to get back into the backlog of 143 messages starting tomorrow.
diff --git a/doc/devblog/day_266-267__man_page_split/comment_1_d55600917128cb0ce38002fbf6f0b088._comment b/doc/devblog/day_266-267__man_page_split/comment_1_d55600917128cb0ce38002fbf6f0b088._comment
new file mode 100644
index 0000000000..a8d5128e3f
--- /dev/null
+++ b/doc/devblog/day_266-267__man_page_split/comment_1_d55600917128cb0ce38002fbf6f0b088._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="nice!"
+ date="2015-03-25T16:28:47Z"
+ content="""
+that's a great idea!! hopefully those smaller manpages can be expanded with more examples and tips as well!
+"""]]
diff --git a/doc/devblog/day_266-267__man_page_split/comment_2_63791201452a6ab30a35cd742434acca._comment b/doc/devblog/day_266-267__man_page_split/comment_2_63791201452a6ab30a35cd742434acca._comment
new file mode 100644
index 0000000000..95bf5dde2e
--- /dev/null
+++ b/doc/devblog/day_266-267__man_page_split/comment_2_63791201452a6ab30a35cd742434acca._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="works like charm"
+ date="2015-03-31T02:29:04Z"
+ content="""
+THANKS!
+"""]]
diff --git a/doc/devblog/day_266-267__man_page_split/comment_3_d7764c605ad338c4bf4c4b46b54abd8a._comment b/doc/devblog/day_266-267__man_page_split/comment_3_d7764c605ad338c4bf4c4b46b54abd8a._comment
new file mode 100644
index 0000000000..0e7f793bb9
--- /dev/null
+++ b/doc/devblog/day_266-267__man_page_split/comment_3_d7764c605ad338c4bf4c4b46b54abd8a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="comment 3"
+ date="2015-03-31T02:32:04Z"
+ content="""
+I only wish it was identical to git syntax (git COMMAND --help for manpage full doc, git COMMAND -h for short summary), but iirc I have whined before and it wasn't trivial to achieve.  So current one is next akin ;-) 
+"""]]
diff --git a/doc/devblog/day_268_stressed_out.mdwn b/doc/devblog/day_268_stressed_out.mdwn
new file mode 100644
index 0000000000..e2fd6159be
--- /dev/null
+++ b/doc/devblog/day_268_stressed_out.mdwn
@@ -0,0 +1,18 @@
+While I plowed through a lot of backlog the past several days,
+I still have some 120 messages piled deep.
+
+That work did result in a number of improvements, culminating in a rather
+rushed release of version 5.20150327 today, to fix a regression affecting
+`git annex sync` when using the standalone linux tarballs. Unfortunately, I
+then had to update those tarballs a second time after the release
+as the first fix was incomplete.
+
+And, I'm feeling super stressed out. At this point, I think I should step
+away until the end of the month. Unfortunately, this will mean more backlog
+later. Including lots of noise and hand-holding that I just don't seem to
+have time for if I want to continue making forward progress.
+
+Maybe I'll think of a way to deal with it while I'm away. Currently, all I
+have is that I may have to start ignoring irc and the forum, and
+de-prioritizing bug reports that don't have either a working reproduction
+recipe or multiple independent confirmations that it's a real bug.
diff --git a/doc/devblog/day_268_stressed_out/comment_1_d28352c9fbc988ece19688a687d30ffe._comment b/doc/devblog/day_268_stressed_out/comment_1_d28352c9fbc988ece19688a687d30ffe._comment
new file mode 100644
index 0000000000..bb603e27b7
--- /dev/null
+++ b/doc/devblog/day_268_stressed_out/comment_1_d28352c9fbc988ece19688a687d30ffe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmtJGSG74JdKxtaMvHQTTeq8P2yxXmuPD0"
+ nickname="Kenneth"
+ subject="comment 1"
+ date="2015-03-28T03:36:15Z"
+ content="""
+\" and de-prioritizing bug reports that don't have either a working reproduction recipe or multiple independent confirmations that it's a real bug.\"
+
+This seems quite reasonable. Hope you get a little downtime to relax.
+"""]]
diff --git a/doc/devblog/day_268_stressed_out/comment_2_f7b04b2e96f0fc7530f1c21ccfcfb0f9._comment b/doc/devblog/day_268_stressed_out/comment_2_f7b04b2e96f0fc7530f1c21ccfcfb0f9._comment
new file mode 100644
index 0000000000..dffce0772b
--- /dev/null
+++ b/doc/devblog/day_268_stressed_out/comment_2_f7b04b2e96f0fc7530f1c21ccfcfb0f9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica"
+ subject="You should take a break"
+ date="2015-03-29T20:37:16Z"
+ content="""
+By all means, take a break Joey! 
+"""]]
diff --git a/doc/devblog/day_268_stressed_out/comment_3_0eb4c17d35fba9db6a7446a5f253ace9._comment b/doc/devblog/day_268_stressed_out/comment_3_0eb4c17d35fba9db6a7446a5f253ace9._comment
new file mode 100644
index 0000000000..f098c700ad
--- /dev/null
+++ b/doc/devblog/day_268_stressed_out/comment_3_0eb4c17d35fba9db6a7446a5f253ace9._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="take care and ideas"
+ date="2015-03-30T16:26:05Z"
+ content="""
+we not careful enough with ourselves and with each other... i can only send my warmest support for your self-imposed break, i should probably have done that myself a few times, and never had the lucidity to do it soon enough... so yeah, break time, and enjoy spring! :)
+
+git-annex has grown in leaps and bounds in the last year, and it looks like it's getting more and more the traction it deserves. that means a lot more support requests and yes, a lot more noise in the forums and issue queues. in my experience, having the core devs step away from the support forums isn't necessarily a bad thing: it will leave some room for other people to step up and start cooking up their own answers. i did a very quick analysis of the `doc` subdirectory of the current git repo, and at least a third of the data is injected in the forum:
+
+<pre>
+$ ncdu doc/
+[...]
+   13,0MiB  3 270 [##########] /forum
+   10,4MiB  2 243 [########  ] /bugs
+    4,4MiB    964 [###       ] /design
+    2,2MiB    550 [#         ] /todo
+    1,6MiB    398 [#         ] /devblog
+    1,5MiB    348 [#         ] /tips
+[...]
+ Total disk usage:  38,3MiB  Apparent size:  15,4MiB  Items: 8711
+</pre>
+
+I wonder if moving this out of the wiki (to, say, a mailing list or Stack-exchange like Q&A site) would be helpful? It seems there is a significant amount of FAQ and divergence from topic on the forum posts... trying another tool may be helpful here (but I know how annoying and crazy this sounds at first...).
+"""]]
diff --git a/doc/devblog/day_268_stressed_out/comment_4_fecf179be92c3a3e25f4a47fcea6b6ec._comment b/doc/devblog/day_268_stressed_out/comment_4_fecf179be92c3a3e25f4a47fcea6b6ec._comment
new file mode 100644
index 0000000000..f042f93943
--- /dev/null
+++ b/doc/devblog/day_268_stressed_out/comment_4_fecf179be92c3a3e25f4a47fcea6b6ec._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/27ceb3c5-0762-42b8-8f8a-ed21c284748f"
+ nickname="g"
+ subject="SuperUser"
+ date="2015-03-31T01:09:20Z"
+ content="""
+Totally agree that the main developers, and especially you, Joey, shouldn't have to be handling most of the support you are now. There's already a reasonable amount of [git-annex-related action over on the SuperUser Stack Exchage](http://superuser.com/search?q=git-annex), though the actual [`git-annex` tag seems to only have been used once](http://superuser.com/questions/tagged/git-annex)
+
+Echoing #3, it does seem like it would make sense to move more of the basic support work over there from the forum. For this sort of Q&A, I find Stack Exchange a bit better structured, a little harder to miss past questions before re-posting, and like that it has a built-in community of people to help answer.
+"""]]
diff --git a/doc/devblog/day_269__wildcards_and_podcasts.mdwn b/doc/devblog/day_269__wildcards_and_podcasts.mdwn
new file mode 100644
index 0000000000..af17eebfa3
--- /dev/null
+++ b/doc/devblog/day_269__wildcards_and_podcasts.mdwn
@@ -0,0 +1,26 @@
+Turns out that git has a feature I didn't know about; it will expand
+wildcards and other stuff in filenames passed to many git commands. This is
+on top of the shell's expansion.
+
+That led to some broken behavior by `git annex add 'foo.*'`
+and, it could lead to other probably unwanted behavior, like `git annex
+drop 'foo[barred]'` dropping a file named `food` in addition to
+`foo[barred]`
+
+For now, I've disabled this git feature throughout git-annex. If you relied
+on it for something, let me know, I might think about adding it back in
+specific places where it makes sense.
+
+----
+
+Improved `git annex importfeed` to check the itemid of the feed and avoid
+re-downloading a file with the same itemid. Before, it would add duplicate
+files if a feed kept the itemid the same, but changed the url. This was
+easier than expected because annex.genmetadata already caused the itemid
+to be stored in the git-annex metadata. I just had to make it check the
+itemid metadata, and set itemid even when annex.genmetadata isn't set.
+
+----
+
+Also got 4 other bug reports fixed, even though I feel I'm taking it easy
+today. It's good to be relaxed again!
diff --git a/doc/devblog/day_26__gcrypt_really_done_this_time.mdwn b/doc/devblog/day_26__gcrypt_really_done_this_time.mdwn
new file mode 100644
index 0000000000..347e4be5f7
--- /dev/null
+++ b/doc/devblog/day_26__gcrypt_really_done_this_time.mdwn
@@ -0,0 +1,17 @@
+Did I say it would be easy to make the webapp detect when a gcrypt repository 
+already existed and enable it? Well, it wasn't exactly hard, but it took
+over 300 lines of code and 3 hours..
+
+So, gcrypt support is done for now. The glaring omission is gpg key
+management for sharing gcrypt repositories between machines and/or people.
+But despite that, I think it's solid, and easy to use, and covers some
+great use cases.
+
+Pushed out a release.
+
+Now I really need to start thinking about
+[[design/assistant/disaster_recovery]].
+
+----
+
+Today's work was sponsored by Dominik Wagenknecht.
diff --git a/doc/devblog/day_270__distributed_fsck.mdwn b/doc/devblog/day_270__distributed_fsck.mdwn
new file mode 100644
index 0000000000..0e25acb2bf
--- /dev/null
+++ b/doc/devblog/day_270__distributed_fsck.mdwn
@@ -0,0 +1,27 @@
+Added two options to `git annex fsck` that allow for a form of distributed
+fsck.  This is useful in situations where repositiories cannot be trusted to
+continue to exist, and cannot be checked directly, but you'd still like to
+keep track of their status. [[design/iabackup]] is one use case for this.
+
+By running a periodic fsck with the --distributed option,
+the repositories can verify that they still exist and that the
+information about their contents is still accurate. This is done by
+doing an extra update of the location log each time a file is verified by
+fsck to still be in the repository.
+
+The other option looks like --expire="30d somerepo:60d". It checks that
+each specified repository has recorded a distributed fsck within the specified
+time period. If not, the repository is dropped from the location tracking
+log. Of course it can always update that later if it's really still around.
+
+Distributed fsck is not the default because those extra location log updates
+increase the size of the git-annex branch. I did one thing to keep the size
+increase small: An identical line is logged to for each key, including the
+timestamp, so git's delta compression will work as well as is possible. But,
+there's still commit and tree update overhead. 
+
+Probably doesn't make sense to run distributed fscks too often for that and
+other reasons. If the git-annex branch does get too large, there's always
+`git annex forget` ...
+
+**(Update: This was later rethought and works much more efficiently now..)**
diff --git a/doc/devblog/day_271__parallel_get_groundwork.mdwn b/doc/devblog/day_271__parallel_get_groundwork.mdwn
new file mode 100644
index 0000000000..7f7a3afbaa
--- /dev/null
+++ b/doc/devblog/day_271__parallel_get_groundwork.mdwn
@@ -0,0 +1,32 @@
+I've started work on [[todo/parallel_get]].
+Today, laid the groundwork in two areas:
+
+1. Evalulated the ascii-progress haskell library. It can display
+   multiple progress bars in the terminal, portably, and its author
+   Pedro Tacla Yamada has kindly offered to improve it to meet
+   git-annex's needs.
+
+   I ended up filing [10 issues](https://github.com/yamadapc/haskell-ascii-progress/issues)
+   on it today, around 3 of the are blockers for git-annex using it.
+
+2. Worked on making --quiet more quiet. Commands like rsync and wget
+   need to have thier progress output disabled when run in parallel.
+
+   Didn't quite finish this yet.
+
+---
+
+Yesterday I made some improvements to how git-annex behaves when it's
+passed a massive number of directories or files on the command line.
+Eg, when driven by xargs. There turned out to be some bugs in that
+scenario.
+
+One problem one I kind of had to paper over. While git-annex get
+normally is careful to get the files in the same order they were listed on
+the command line, it becomes very expensive to expand directories using
+git-ls-files, and reorder its output to preserve order, when a large number
+offiles are passed on the command line. There was a O(N*M) time blowup.
+
+I worked around it by making it only preserve the order of the first 100
+files. Assumption being that if you're specifying so many files on the
+command line, you probably have less of an attachment to their ordering. :)
diff --git a/doc/devblog/day_272__forest_for_trees.mdwn b/doc/devblog/day_272__forest_for_trees.mdwn
new file mode 100644
index 0000000000..cdbde54a35
--- /dev/null
+++ b/doc/devblog/day_272__forest_for_trees.mdwn
@@ -0,0 +1,13 @@
+Rethought distributed fsck. It's not really a fsck, but an expiration of
+inactive repositories, where fscking is one kind of activity. That insight
+let me reimplement it much more efficiently. Rather than updating all
+the location logs to prove it was active, `git annex fsck` can simply and
+inexpensively update an activity log. It's so cheap it'll do it by default.
+The `git annex expire` command then reads the activity log and expires
+(or unexpires) repositories that have not been active in the desired time
+period. Expiring a repository simply marks it as dead.
+
+Yesterday, finished making --quiet really be quiet. That sounds easy,
+but it took several hours. On the `concurrentprogress` branch, I have
+ascii-progress hooked up and working, but it's not quite ready for prime
+time.
diff --git a/doc/devblog/day_273__unexpected_release.mdwn b/doc/devblog/day_273__unexpected_release.mdwn
new file mode 100644
index 0000000000..5b902c892c
--- /dev/null
+++ b/doc/devblog/day_273__unexpected_release.mdwn
@@ -0,0 +1,15 @@
+I've had to release git-annex twice this week to fix reversions. On Monday,
+just after I made a planned release, I discovered a bug in it, and had to
+update it with a .1 release. Today's release fixes 2 other reversions
+introduced by recent changes, both only affecting the assistant.
+
+Before making today's release, I did a bunch of other minor bugfixes and
+improvements, including adding a new `contentlocationn` plumbing command.
+This release also changes `git annex add` when annex.largefiles is
+configured, so it will `git add` the non-large files. That is particularly
+useful in direct mode.
+
+I feel that the assistant needs some TLC, so I might devote a week to it in
+the latter part of this month. My current funding doesn't cover work
+on the assistant, but I should have some spare time toward the end of the
+month.
diff --git a/doc/devblog/day_274__concurrent_annex_state.mdwn b/doc/devblog/day_274__concurrent_annex_state.mdwn
new file mode 100644
index 0000000000..3aa73c0f3b
--- /dev/null
+++ b/doc/devblog/day_274__concurrent_annex_state.mdwn
@@ -0,0 +1,42 @@
+Back working on `git annex get --jobs=N` today. It was going very well,
+until I realized I had a hard problem on my hands.
+
+The hard problem is that the AnnexState structure at the core of git-annex
+is not able to be shared amoung multiple threads at all. There's too much
+complicated mutable state going on in there for that to be feasible at all.
+
+In the git-annex assistant, which uses many threads, I long ago worked
+around this problem, by having a single shared AnnexState and when a thread
+needs to run an Annex action, it blocks until no other thread is using it.
+This worked ok for the assistant, with a little bit of thought to avoid
+long-duration Annex actions that could stall the rest of it.
+
+That won't work for concurrent `get` etc. I spent a while investigating maybe
+making AnnexState thread safe, but it's just not built for it. Too many
+ways that can go wrong. For example, there's a CatFileHandle in the
+AnnexState. If two threads are running, they can both try to talk to the
+same `git cat-file --batch` command at once, with bad results. Worse, yet,
+some parts of the code do things like modifying the AnnexState's Git repo
+to add environment variables to use when running git commands.
+
+It's not all gloom and doom though. Only very isolated parts of the code
+change the working directory or set environment variables. And the
+assistant has surely smoked out other thread concurrency problems already.
+And, separate `git-annex` programs can be run concurrently with no problems
+at all; it uses file locking to avoid different processes getting in
+each-others' way. So AnnexState is the only remaining obstacle to concurrency.
+
+So, here's how I've worked around it: When `git annex get -J10` is run,
+it will start by allocating 10 job slots. A fresh AnnexState will be
+created, and copied into each slot. Each time a job runs, it uses its
+slot's own AnnexState. This means 10 `git cat-file` processes,
+and maybe some contention over lock files, but generally, a nice, easy,
+and hopefully trouble-free multithreaded mode.
+
+And indeed, I've gotten `git annex get -J10` working robustly!
+And from there it was trivial to enable -J for `move` and `copy` and `mirror`
+too!
+
+The only real blocker to merging the concurrentprogress branch is some bugs
+in the ascii-progress library that make it draw very scrambled progress
+bars the way git-annex uses it.
diff --git a/doc/devblog/day_274__concurrent_annex_state/comment_1_7414fc0dde7a1d1ee456f8eba0b0c2a9._comment b/doc/devblog/day_274__concurrent_annex_state/comment_1_7414fc0dde7a1d1ee456f8eba0b0c2a9._comment
new file mode 100644
index 0000000000..b4e2eeef82
--- /dev/null
+++ b/doc/devblog/day_274__concurrent_annex_state/comment_1_7414fc0dde7a1d1ee456f8eba0b0c2a9._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 1"
+ date="2015-04-10T21:33:02Z"
+ content="""
+great news!
+
+one thing i've been wondering after fooling around with the git-annex branch outside of git-annex is why git-annex talks with the commandline git client at all? libgit, for example, seem to access the .git objects directly without a dependency on the git commandline... there doesn't seem to be any haskell shims for libgit, but it seems to me it would reduce the overhead of a bunch of stuff in git-annex...
+
+as an aside, any thoughts of making the [git-annex-specific git library](http://source.git-annex.branchable.com/?p=source.git;a=tree;f=Git;hb=HEAD) portable and standalone? maybe in collaboration with the existing [hs-libgit](https://hackage.haskell.org/package/libgit)?
+"""]]
diff --git a/doc/devblog/day_274__concurrent_annex_state/comment_2_4ca498ee4b4aaac8ee6dbc2c769dbad7._comment b/doc/devblog/day_274__concurrent_annex_state/comment_2_4ca498ee4b4aaac8ee6dbc2c769dbad7._comment
new file mode 100644
index 0000000000..e8629e5323
--- /dev/null
+++ b/doc/devblog/day_274__concurrent_annex_state/comment_2_4ca498ee4b4aaac8ee6dbc2c769dbad7._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-04-11T14:41:47Z"
+ content="""
+Josh Tripplet has some haskell bindings for libgit2 somewhere.
+My reasons for not using it so far include:
+
+* ABI stability; at least it used to have none. soname is 21 already..
+* Josh told me parts of it are much less optimised than git.
+  (This was several years ago, but I still imagine the git code base
+  has much more work on speed.)
+* It's not even been in a stable release of Debian yet.
+* Adding a C library dependency will make git-annex much harder for
+  users to get started building.
+* The couple of things that I could really use a git library for, like
+  index file access and catting object contents, could be implemented
+  just as well (and likely as fast) in pure haskell
+  code, and would not be particularly hard to do either. There may even
+  be suitable pure haskell libraries for them; haven't checked.
+"""]]
diff --git a/doc/devblog/day_275-276__mostly_Windows.mdwn b/doc/devblog/day_275-276__mostly_Windows.mdwn
new file mode 100644
index 0000000000..bcdc94696d
--- /dev/null
+++ b/doc/devblog/day_275-276__mostly_Windows.mdwn
@@ -0,0 +1,20 @@
+Mostly working on Windows recently. Fixed handling of git
+repos on different drive letters. Fixed crazy start menu loop. Worked around
+stange msysgit version problem.
+
+Also some more work on the `concurrentprogress` branch, making the progress
+display prettier.
+
+Added one nice new feature yesterday: `git annex info $dir` now includes a
+table of repositories that are storing files in the directory, with their
+sizes.
+
+	repositories containing these files: 
+		288.98 MB: ca9c5d52-f03a-11df-ac14-6b772ffe59f9 -- archive-5
+		288.98 MB: f1c0ce8d-d848-4d21-988c-dd78eed172e8 -- archive-8
+		 10.48 MB: 587b9ccf-4548-4d6f-9765-27faecc4105f -- darkstar
+		 15.18 kB: 42d47daa-45fd-11e0-9827-9f142c1630b3 -- origin
+
+Nice thing about this feature is it's done for free, with no extra work other
+than a little bit of addition. All the heavy location lookup work was already
+being done to get the numcopies stats.
diff --git a/doc/devblog/day_277__thanks.mdwn b/doc/devblog/day_277__thanks.mdwn
new file mode 100644
index 0000000000..de82769bb4
--- /dev/null
+++ b/doc/devblog/day_277__thanks.mdwn
@@ -0,0 +1,20 @@
+Recent work has included improving `fsck --from remote` (and fixing a
+reversion caused by the relative path changes in January), and making
+annex.diskreserve be checked in more cases. And added a `git annex
+required` command for setting [[required_content]].
+
+Also, I want to thank several people for their work:
+
+* Roy sent a patch to enable http proxy support.. despite
+  having only learned some haskell by "30 mins with YAHT". I investigated
+  that more, and no patch is actually necessary, but just a newer version
+  of the http-client library.
+* CandyAngel has been posting lots of helpful comments on the website,
+  including [this tip](http://git-annex.branchable.com/forum/__34__git_annex_sync__34___synced_after_8_hours/#comment-890ca1381d800ac833ccbb8c5db175ea)
+  that significantly speeds up a large git repository.
+* Øyvind fixed a lot of typos throughout the git-annex
+  documentation.
+* Yaroslav has created a `git-annex-standalone.deb` package
+  that will work on any system where debian packages can be installed,
+  no matter how out of date it is (within reason), using the same
+  methods as the standalone tarball.
diff --git a/doc/devblog/day_278__release_day.mdwn b/doc/devblog/day_278__release_day.mdwn
new file mode 100644
index 0000000000..22d637c89e
--- /dev/null
+++ b/doc/devblog/day_278__release_day.mdwn
@@ -0,0 +1,25 @@
+I hope that today's git-annex release will be landing in Debian unstable
+toward the end of the month. And I'm looking forward to some changes that
+have been blocked by wanting to keep git-annex buildable on Debian 7.
+
+Yesterday I got rid of the [SHA](http://hackage.haskell.org/package/SHA/)
+dependency, switching git-annex to use a newer version of cryptohash for
+HMAC generation (which its author Vincent Hanquez kindly added to it when I
+requested it, waay back in 2013). I'm considering using the LambdaCase
+extension to clean up a lot of the code next, and there are 500+ lines of
+old yesod compatability code I can eventually remove.
+
+These changes and others will prevent backporting to the soon to be Debian
+oldstable, but the standalone tarball will still work there. And, the
+git-annex-standalone.deb that can be installed on any version of Debian is
+[now available from the NeuroDebian repository](http://neuro.debian.net/install_pkg.html?p=git-annex-standalone),
+and its build support has been merged into the source tree.
+
+In the run up to the release today, I also dealt with getting the
+Windows build tested and working, now that it's been updated to newer
+versions of rsync, ssh, etc from Cygwin. Had to add several more dlls to
+the installer. That testing also turned up a case where `git-annex init`
+could fail, which got a last-minute fix.
+
+PS, scroll down [this 10 year of git timeline](https://www.atlassian.com/git/articles/10-years-of-git/)
+and see what you find!
diff --git a/doc/devblog/day_279__.mdwn b/doc/devblog/day_279__.mdwn
new file mode 100644
index 0000000000..25eb9a64e1
--- /dev/null
+++ b/doc/devblog/day_279__.mdwn
@@ -0,0 +1,10 @@
+Posted a design for [[design/balanced_preferred_content]]. This would let
+preferred content expressions assign each file to N repositories out of a
+group, selected using Math. Adding a repository could optionally be
+configured to automatically rebalance the files (not very bandwidth
+efficiently though). I think some have asked for a feature like this
+before, so read the design and see if it would be useful for you.
+
+Spent a while debugging a problem with a S3 remote, which seems to have
+been a misconfiguration in the end. But several improvements came out of
+it to make it easier to debug S3 in the future etc.
diff --git a/doc/devblog/day_27__locking_fun.mdwn b/doc/devblog/day_27__locking_fun.mdwn
new file mode 100644
index 0000000000..ef0c4131f9
--- /dev/null
+++ b/doc/devblog/day_27__locking_fun.mdwn
@@ -0,0 +1,49 @@
+Started the day by getting the builds updated for yesterday's release. This
+included making it possible to build git-annex with Debian stable's version
+of cryptohash. Also updated the Debian stable backport to the previous
+release.
+
+----
+
+The [[design/roadmap]] has this month devoted to improving git-annex's
+support for recovering from disasters, broken repos, and so on. Today I've
+been working on the first thing on [[the_list|design/assistant/disaster_recovery]],
+stale git index lock files.
+
+It's unfortunate that git uses simple files for locking, and does not use
+fcntl or flock to prevent the stale lock file problem. Perhaps they want
+it to work on broken NFS systems? The problem with that line of thinking is
+is means all non-broken systems end up broken by stale lock files. Not a
+good tradeoff IMHO.
+
+There are actually two lock files that can end up stale when using
+git-annex; both `.git/index.lock` and `.git/annex/index.lock`. Today I
+concentrated on the latter, because I saw a way to prevent it from ever
+being a problem. All updates to that index file are done by git-annex when
+committing to the git-annex branch. git-annex already uses fcntl locking
+when manipulating its journal. So, that can be extended to also cover
+committing to the git-annex branch, and then the git `index.lock` file
+is irrelevant, and can just be removed if it exists when a commit is
+started.
+
+To ensure this makes sense, I used the type system to prove that the journal
+locking was in effect everywhere I need it to be. Very happy I was able to
+do that, although I am very much a novice at using the type system for
+interesting proofs. But doing so made it very easily to build up to a point
+where I could unlink the `.git/annex/index.lock` and be sure it was safe to do
+that.
+
+----
+
+What about stale `.git/index.lock` files? I don't think it's appropriate
+for git-annex to generally recover from those, because it would change
+regular git command line behavior, and risks breaking something. However, I
+do want the assistant to be able to recover if such a file exists when it
+is starting up, since that would prevent it from running. Implemented that
+also today, although I am less happy with the way the assistant detects
+when this lock file is stale, which is somewhat heuristic (but should work
+even on networked filesystems with multiple writing machines).
+
+----
+
+Today's work was sponsored by Torbjørn Thorsen.
diff --git a/doc/devblog/day_27__locking_fun/comment_1_0eb247235fbf8f563934f3548e1d2e10._comment b/doc/devblog/day_27__locking_fun/comment_1_0eb247235fbf8f563934f3548e1d2e10._comment
new file mode 100644
index 0000000000..261fa005c6
--- /dev/null
+++ b/doc/devblog/day_27__locking_fun/comment_1_0eb247235fbf8f563934f3548e1d2e10._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://cstork.org/"
+ nickname="Chris Stork"
+ subject="News page not updated"
+ date="2013-10-04T09:38:21Z"
+ content="""
+Already for the last three or so releases the News page wasn't updated. :-( I think many people (including me) used this page to check if their version is uptodate. Posting the newest version there motivates people to try the very latest which seems very desirable for the git-annex development.
+"""]]
diff --git a/doc/devblog/day_27__locking_fun/comment_2_e8b1dfe1b0641e031d05733448b7bc8b._comment b/doc/devblog/day_27__locking_fun/comment_2_e8b1dfe1b0641e031d05733448b7bc8b._comment
new file mode 100644
index 0000000000..c073f735a4
--- /dev/null
+++ b/doc/devblog/day_27__locking_fun/comment_2_e8b1dfe1b0641e031d05733448b7bc8b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.243"
+ subject="comment 2"
+ date="2013-10-04T20:13:37Z"
+ content="""
+Sorry about that. It turns out my release script was broken.
+"""]]
diff --git a/doc/devblog/day_27__locking_fun/comment_3_b67f8ef4ed42b49c8c2e6c4e53163b16._comment b/doc/devblog/day_27__locking_fun/comment_3_b67f8ef4ed42b49c8c2e6c4e53163b16._comment
new file mode 100644
index 0000000000..39c840e84f
--- /dev/null
+++ b/doc/devblog/day_27__locking_fun/comment_3_b67f8ef4ed42b49c8c2e6c4e53163b16._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 3"
+ date="2013-10-07T09:17:30Z"
+ content="""
+Hi,
+
+Can you please enlighten us mere mortals, when this stale file locking problem occcurs?
+The typical situation. I tried to google up, and read locking files on wikipedia, but 
+still have no exact knowledge when the \"stale\" part happens.
+
+How it gets outdated without noticing?
+
+Best, 
+ Laszlo
+
+"""]]
diff --git a/doc/devblog/day_27__locking_fun/comment_4_0759644baf26b75f4e48dbb387d725a5._comment b/doc/devblog/day_27__locking_fun/comment_4_0759644baf26b75f4e48dbb387d725a5._comment
new file mode 100644
index 0000000000..cbeae8b78f
--- /dev/null
+++ b/doc/devblog/day_27__locking_fun/comment_4_0759644baf26b75f4e48dbb387d725a5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.22"
+ subject="comment 4"
+ date="2013-10-12T23:31:16Z"
+ content="""
+Git simply creates a file as a lock file, and does not use any form of locking on it, so if the git process dies for any reason before it gets a chance to remove the lock file, a stale lock file remains, and future git commands will fall over it.
+
+It's really surprisingly bad..
+"""]]
diff --git a/doc/devblog/day_280__slow_week.mdwn b/doc/devblog/day_280__slow_week.mdwn
new file mode 100644
index 0000000000..ed0dce49d9
--- /dev/null
+++ b/doc/devblog/day_280__slow_week.mdwn
@@ -0,0 +1,16 @@
+Reduced activity this week (didn't work on the assistant after all),
+but several things got done:
+
+Monday: Fixed `fsck --fast --from remote` to not fail when the remote
+didn't support fast copy mode. And dealt with an incompatibility in S3 bucket
+names; the old hS3 library supported upper-case bucket names but the new
+one needs them all in lower case.
+
+Wednesday: Caught up on most recent backlog, made some improvements
+to error handling in `import`, and improved integration with KDE's file
+manager to work with newer versions.
+
+Today: Made `import --deduplicate/--clean-duplicates` actively 
+verify that enough copies of a file exist before deleting it. And,
+thinking about some options for batch mode access to git-annex plumbing,
+to speed up things that use it a lot.
diff --git a/doc/devblog/day_281__catching_up__and_arm_autobuilder_needed.mdwn b/doc/devblog/day_281__catching_up__and_arm_autobuilder_needed.mdwn
new file mode 100644
index 0000000000..d55823f755
--- /dev/null
+++ b/doc/devblog/day_281__catching_up__and_arm_autobuilder_needed.mdwn
@@ -0,0 +1,43 @@
+I've not been blogging, but have been busy this week. Backlog is down to
+113 messages.
+
+Tuesday: I got a weird bug report where `git annex get` was deleting
+a file. This turned out to be a bug in `wget ftp://...` where it would
+delete a symlink that was not where it had been told to download the fie
+to. I put a workaround in git-annex; wget is now run in a temp
+directory. But this was a legitimate wget bug, and it's now been reported
+to the wget developers and will hopefully get fixed there.
+
+Wednesday: Added a --batch mode for several plumbing commands
+(contentlocation, examinekey, and lookupkey). This avoids startup overhead,
+and so lets a lot of queries be done much faster. The implementation
+should make it easy to add --batch to more plumbing commands as needed,
+and could probably extend to non-plumbing commands too.
+
+Today: The first 5 hours involved an incompatible mess of ssh and rsync
+versions on Windows. A Gordian knot of brokenness and dependency hell.
+I finally found a solution which involves downgrading the cygwin rsync
+to an older version, and using msysgit's ssh rather than cygwin's.
+
+Finished up today with more post-Debian-release changes. Landed a patch to
+switch from dataenc to sandi that had been waiting since 2013, and got
+sandi installed on all the git-annex autobuilders. Finished up with some
+prep for a release tomorrow.
+
+----
+
+Finally, Debian has a new enough ghc that it can build template haskell
+on arm! So, whenever a new version of git-annex finally gets into Debian
+(I hope soon), the webapp will be available on arm for those arm laptops.
+Yay!
+
+This also means I have the opportunity to make the standalone arm build
+be done much more simply. Currently it involves qemu and a separate
+companion native mode container that it has to ssh to and build stuff,
+that has to have the same versions of all libraries. It's just enormously
+complicated and touchy. With template haskell building support, all that
+complexity can fall away. 
+
+What I'd really like to do is get a fast-ish arm box with 2gb of ram
+hosted somewhere, and use that to do the builds, in native mode.
+Anyone want to help provide such a box for git-annex arm autobuilds?
diff --git a/doc/devblog/day_282__release_day.mdwn b/doc/devblog/day_282__release_day.mdwn
new file mode 100644
index 0000000000..da648c1cdd
--- /dev/null
+++ b/doc/devblog/day_282__release_day.mdwn
@@ -0,0 +1,16 @@
+Got the release out after more struggling with ssh on windows and a last
+minute fix to the quvi support.
+
+The downloads.kitenet.net git annex repository had accumulated 6 gb of past
+builds that were not publically available. I am publishing those 
+[on the Internet Archive now](https://archive.org/details/git-annex-builds),
+so past builds can be downloaded using git-annex in that repository in the
+usual way. This worked great! :)
+
+I have ordered a CubieTruck with 2 gb of ram to use for the new Arm builder.
+Hosting still TBD.
+
+Looks like git-annex is almost ready to
+[be included in stackage](https://github.com/fpco/stackage/pull/519#issuecomment-98590181),
+which will make building it from source much less likely to fail due to
+broken libraries etc.
diff --git a/doc/devblog/day_283__lazy_sunday.mdwn b/doc/devblog/day_283__lazy_sunday.mdwn
new file mode 100644
index 0000000000..2850e2cbb7
--- /dev/null
+++ b/doc/devblog/day_283__lazy_sunday.mdwn
@@ -0,0 +1,7 @@
+Lazy afternoon spent porting git-anenx to build under ghc 7.10. Required
+rather a lot of changes to build, and even more to build cleanly after the
+AMP transition.
+
+Unfortunately, ghc 7.10 has started warning about every line that uses tab
+for indentation. I had to add additional cruft to turn those warnings off
+everywhere, and cannot say I'm happy about this at all.
diff --git a/doc/devblog/day_283__lazy_sunday/comment_1_fdc6da890e2dc6b86b6a5fe2ebceea4a._comment b/doc/devblog/day_283__lazy_sunday/comment_1_fdc6da890e2dc6b86b6a5fe2ebceea4a._comment
new file mode 100644
index 0000000000..e5d4d4c5ea
--- /dev/null
+++ b/doc/devblog/day_283__lazy_sunday/comment_1_fdc6da890e2dc6b86b6a5fe2ebceea4a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 1"
+ date="2015-05-11T09:02:10Z"
+ content="""
+I'd be interested to hear your reasons for preferring tabs over spaces, if it's anything more than an aesthetic preference.
+
+The [GHC trac](https://ghc.haskell.org/trac/ghc/ticket/9230) suggests that it was turned on by default because beginners accidentally mix tabs and spaces and get very confused.
+"""]]
diff --git a/doc/devblog/day_284__development.mdwn b/doc/devblog/day_284__development.mdwn
new file mode 100644
index 0000000000..7ecf684301
--- /dev/null
+++ b/doc/devblog/day_284__development.mdwn
@@ -0,0 +1,33 @@
+Implemented `git annex drop --all`. This also added for free drop with
+`--unused` and `--key`, which overlap with `git annexdropunused` and
+`git annex dropkey`.
+
+The `concurrentprogress` branch had gone too long without being merged, and
+had a lot of merge conflicts. I resolved those, and went ahead and merged
+it into master. However, since the ascii-progress library is not ready yet,
+I made it a build flag, and it will build without it by default. So, `git
+annex get -J5` can be used now, but no progress bars will display yet.
+
+When doing concurrent downloads, either with the new -J or by hand by
+running multiple processes, there was a bug in the diskreserve
+checking code. It didn't consider the disk space that was in the process of
+being used by other concurrent downloads, so would let more downloads
+start up than there was space for.
+
+I was able to fix this pretty easily, thanks to the transfer log files.
+Those were originally added just to let the webapp display transfers, but
+proved very helpful here!
+
+Finally, made .git/annex/transfer/failed/ files stop accumulating when the
+assistant is not being used. Looked into also cleaning up stale
+.git/annex/transfer/{upload,download}/ files (from interrupted transfers).
+But, since those are used as lock files, it's difficult to remove them
+in a concurrency safe way.
+
+Update: Unfortunately, I turned out to have stumbled over an apparent bug
+in haskell's implementation of file locking.
+<https://github.com/haskell/unix/issues/44> Had to work around that.
+
+Happily, the workaround also let me implement cleanup of stale transfer
+info files, left behind when a git-annex process was interrupted. So,
+.git/annex/transfer/ will entirely stop accumulating cruft!
diff --git a/doc/devblog/day_285__tuning_git-annex_unused_refs.mdwn b/doc/devblog/day_285__tuning_git-annex_unused_refs.mdwn
new file mode 100644
index 0000000000..b5afaec175
--- /dev/null
+++ b/doc/devblog/day_285__tuning_git-annex_unused_refs.mdwn
@@ -0,0 +1,20 @@
+Today I added a feature to `git annex unused` that lets the user tune which
+refs they are interested in using. Annexed objects that are used by other
+refs then are considered unused.
+
+Did a fairly complicated refspec format for this, with globs and
+include/exclude of refs. Example:
+
+	+refs/heads/*:+HEAD^:+refs/tags/*:-refs/tags/old-tag
+
+----
+
+I think that, since Google dropped openid support, there seems to have been
+less activity on this website. Although possibly also a higher signal to
+noise ratio. :) I have been working on some ikiwiki changes to make it
+easier for users who don't have an openid to contiribute. So git-annex's
+website should soon let you log in and make posts with just an email address.
+
+People sometimes ask for a git-annex mailing list. I wouldn't mind having
+one, and would certianly subscribe, but don't see any reason that I should
+be involved in running it.
diff --git a/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_1_a3f0dd4fc8457af7c72040fbe8fd5fee._comment b/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_1_a3f0dd4fc8457af7c72040fbe8fd5fee._comment
new file mode 100644
index 0000000000..a94383fa23
--- /dev/null
+++ b/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_1_a3f0dd4fc8457af7c72040fbe8fd5fee._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="mailing lists and support sites"
+ date="2015-05-14T20:26:59Z"
+ content="""
+after years subscribing to zillions of them, i have acquired an allergy to mailing lists. it seems that i get this every once in a while: i'm subscribed to a bunch of them and i stop reading and just hit \"d\" on my mail client. :)
+
+i think there are very interesting alternatives, online web forums (yes yes, i know, bear with me) where knowledge is established and shared instead of just having a threaded conversation. i'm thinking of http://ask.debian.net/ or the stackexchange sites. as i [[analysed before|devblog/day_268_stressed_out/#comment-e0814585df0047e6d4e11515aebe1dec]], the forum is the biggest part of this website (and consequently the git-annex source code!), bug tracker coming in second, and the two together forming the majority of disk usage of the git repository.  there are alternative discussion tools like discourse.org that may also be interesting for people wanting to run such a service.
+
+anyways, the ideas of those is to converge on a set of FAQs and knowledge items more than just have random discussion, and force people to reuse existing topics.
+
+if i had more time, i'd probably setup something like this but really, i can only encourage those initiatives at this point. :)
+"""]]
diff --git a/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_2_dae167e473c60dace129c66beb0af384._comment b/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_2_dae167e473c60dace129c66beb0af384._comment
new file mode 100644
index 0000000000..41e0922c82
--- /dev/null
+++ b/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_2_dae167e473c60dace129c66beb0af384._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 2"
+ date="2015-05-16T18:35:22Z"
+ content="""
+Unfortunately stack exchange is nearly unusable for me on dialup. In order for me to contribute to any git-annex communication channels, it needs to be something that can be taken offline, like git or email.
+"""]]
diff --git a/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_3_52179fc326e681d8fbf85ee8963f352c._comment b/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_3_52179fc326e681d8fbf85ee8963f352c._comment
new file mode 100644
index 0000000000..f85d63350e
--- /dev/null
+++ b/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_3_52179fc326e681d8fbf85ee8963f352c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 3"
+ date="2015-05-16T21:46:20Z"
+ content="""
+interesting! i didn't think of those requirements, which do seem quite stringent, but i am certainly sensitive to them, considering i will be spending my own significant amount of time with intermittent access soon.
+
+i have opened a todo item to move the discussion somewhere more relevant, see [[todo/enable_a_discussion_forum_or_support_system]].
+"""]]
diff --git a/doc/devblog/day_286-287__rotten_locks.mdwn b/doc/devblog/day_286-287__rotten_locks.mdwn
new file mode 100644
index 0000000000..7db07da578
--- /dev/null
+++ b/doc/devblog/day_286-287__rotten_locks.mdwn
@@ -0,0 +1,44 @@
+There's something rotten in POSIX fctnl locking. It's not composable,
+or thread-safe.
+
+The most obvious problem with it is that if you have 2 threads, and they
+both try to take an exclusive lock of the same file (each opening it
+separately) ... They'll both succeed. Unlike 2 separate processes,
+where only one can take the lock.
+
+Then the really crazy bit: If a process has a lock file open and fcntl
+locked, and then the same process opens the lock file again, for any
+reason, closing the new FD will release the lock that was set
+using the other FD.
+
+So, that's a massive gotcha if you're writing complex multithreaded code.
+Or generally for composition of code. Of course, C programmers deal with
+this kind of thing all the time, but in the clean world of Haskell, this is
+a glaring problem. We don't expect to need to worry about this kind of
+unrelated side effect that breaks composition and thread safety.
+
+After noticing this problem affected git-anenx in at least one place,
+I have to assume there could be more. And I don't want to need to worry
+about this problem forever. So, I have been working today on a clean fix
+that I can cleanly switch all my lock-related code to use.
+
+One reasonable approach would be to avoid fcntl locking, and use flock.
+But, flock works even less well on NFS than fcntl, and git-annex relies on
+some fcntl locking features. On Linux, there's an "open file description
+locks" feature that fixes POSIX fnctl locking to not have this horrible
+wart, but that's not portable.
+
+Instead, my approach is to keep track of which files the process has
+locked. If it tries to do something with a lockfile that it already has
+locked, it avoids opening the same file again, instead implements its own
+in-process locking behavior. I use STM to do that in a thread-safe manner.
+
+I should probably break out git-annex's lock file handling code as a
+library. Eventually.. This was about as much fun as a root canal, and I'm
+having a real one tomorrow. :-/
+
+----
+
+git-annex is now included in [Stackage](http://www.stackage.org/)!
+
+Daniel Kahn Gillmor is doing some work on reproducible builds of git-annex.
diff --git a/doc/devblog/day_288__microrelease_prep.mdwn b/doc/devblog/day_288__microrelease_prep.mdwn
new file mode 100644
index 0000000000..fc1a5f3dfb
--- /dev/null
+++ b/doc/devblog/day_288__microrelease_prep.mdwn
@@ -0,0 +1,22 @@
+After a less active than usual week (dentist), I made a release last Friday.
+Unfortunately, it turns out that the Linux standalone 
+builds in that release don't include the webapp. So, another release is
+planned tomorrow.
+
+Yesterday and part of today I dug into
+the [[bugs/windows_ssh_webapp_password_entry_broken]]
+reversion. Eventually cracked the problem; it seems that
+different versions of ssh for Windows do different things in a `isatty`
+check, and there's a flag that can be passed when starting ssh to make it
+not see a controlling tty. However, this neeeds changes to the
+`process` library, which db48x and I have now coded up. So a fix for this bug
+is waiting on a new release of that library. Oh well.
+
+Rest of today was catching up on recent traffic, and improving the behavior
+of `git annex fsck` when there's a disk IO error while checksumming a file.
+Now it'll detect a hardware fault exception, and take that to mean the file
+is bad, and move it to the bad files directory, instead of just crashing.
+
+I need better tooling to create disk IO errors on demand.
+Yanking disks out works, but is a blunt instrument. Anyone know of
+good tools for that?
diff --git a/doc/devblog/day_288__microrelease_prep/comment_1_99e359976acbdb9727598f8a87027de0._comment b/doc/devblog/day_288__microrelease_prep/comment_1_99e359976acbdb9727598f8a87027de0._comment
new file mode 100644
index 0000000000..3f849e73e8
--- /dev/null
+++ b/doc/devblog/day_288__microrelease_prep/comment_1_99e359976acbdb9727598f8a87027de0._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="bup-cron has something"
+ date="2015-05-27T23:32:18Z"
+ content="""
+so the bup people has a little [bup-damage](https://github.com/bup/bup/blob/master/cmd/damage-cmd.py) command to insert noise into files. it doesn't simulate I/O problems per se, but maybe it could help? --[[anarcat]]
+"""]]
diff --git a/doc/devblog/day_288__microrelease_prep/comment_2_27a74d3926083a00c110aafea28420d7._comment b/doc/devblog/day_288__microrelease_prep/comment_2_27a74d3926083a00c110aafea28420d7._comment
new file mode 100644
index 0000000000..461a86e8a9
--- /dev/null
+++ b/doc/devblog/day_288__microrelease_prep/comment_2_27a74d3926083a00c110aafea28420d7._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="namelessjon"
+ subject="comment 2"
+ date="2015-05-28T10:14:45Z"
+ content="""
+https://stackoverflow.com/questions/1870696/simulate-a-faulty-block-device-with-read-errors ?
+"""]]
diff --git a/doc/devblog/day_288__microrelease_prep/comment_3_17752e96baaf46f3048b14a9ec288e3b._comment b/doc/devblog/day_288__microrelease_prep/comment_3_17752e96baaf46f3048b14a9ec288e3b._comment
new file mode 100644
index 0000000000..b6e65a9293
--- /dev/null
+++ b/doc/devblog/day_288__microrelease_prep/comment_3_17752e96baaf46f3048b14a9ec288e3b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://schnouki.net/"
+ nickname="Schnouki"
+ subject="comment 3"
+ date="2015-05-29T12:20:08Z"
+ content="""
+A while ago I needed a tool to emulate slow IO (low bandwidth and high latency). I ended writing a small FUSE driver (in Go, just for fun) that did this by adding some delay to each function call. Hacky, but simpler than setting up a device mapper or NBD. I guess you could also emulate IO errors with something like this. If you're interested I can clean up my code and push it to a public repo.
+"""]]
diff --git a/doc/devblog/day_288__microrelease_prep/comment_4_2838c1d9da3202616e331bb31fd43f20._comment b/doc/devblog/day_288__microrelease_prep/comment_4_2838c1d9da3202616e331bb31fd43f20._comment
new file mode 100644
index 0000000000..dbb014c7ef
--- /dev/null
+++ b/doc/devblog/day_288__microrelease_prep/comment_4_2838c1d9da3202616e331bb31fd43f20._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-05-30T16:03:17Z"
+ content="""
+@Schnouki yes please, that's what I was looking for!
+
+Although perhaps google-fu could find someone else who's already done
+it..
+"""]]
diff --git a/doc/devblog/day_289__new_arm_autobuilder.mdwn b/doc/devblog/day_289__new_arm_autobuilder.mdwn
new file mode 100644
index 0000000000..f0df5995a5
--- /dev/null
+++ b/doc/devblog/day_289__new_arm_autobuilder.mdwn
@@ -0,0 +1,21 @@
+On Friday I installed the CubieTruck that is the new autobuilder
+for arm. This autobuilder is hosted at [WetKnee Books](http://www.wetknee.com/),
+so its physical security includes a swamp. 
+
+The hardware is not fast, but it's faster and far more stable than qemu arm
+emulation. By Saturday I got the build environment all installed nicely,
+including building libraries that use template haskell!
+
+But, ghc crashed with an internal error building git-annex.
+I upgraded to ghc 7.10.1 (which took another day), but it also crashed.
+Was almost giving up, but I looked at the ghc parameters, and -j2 stuck
+out in them. Removed the -j2, and the build works w/o crashing! \o/
+(Filed [a bug report on ghc](https://ghc.haskell.org/trac/ghc/ticket/10469).)
+
+----
+
+Anarcat has been working on improving the man pages, including lots of
+linking to related commands.
+
+The [2015 Haskell Communities and Activities Report](http://www.haskell.org/communities/05-2015/html/report.html)
+is out, and includes an entry for git-annex for the first time!
diff --git a/doc/devblog/day_28__lazy_saturday.mdwn b/doc/devblog/day_28__lazy_saturday.mdwn
new file mode 100644
index 0000000000..c2237b28bd
--- /dev/null
+++ b/doc/devblog/day_28__lazy_saturday.mdwn
@@ -0,0 +1,17 @@
+Finished up the automatic recovery from stale lock files. Turns out git
+has quite a few lock files; the assistant handles them all.
+
+Improved URL and WORM keys so the filenames used for them
+will always work on FAT (which has a crazy assortmeny of illegal
+characters). This is a tricky thing to deal with without breaking backwards
+compatability, so it's only dealt with when creating new URL or WORM keys.
+
+-----
+
+I think my next step in this disaster recovery themed month will be adding
+periodic incremental fsck to the assistant. `git annex fsck` can already
+do an incremental fsck, so this should mostly involve adding a user
+interface to the webapp to configure when it should fsck. For example, you
+might choose to run it for up 1 hour every night, with a goal of checking
+all your files once per month. Also will need to make the assistant do
+something useful when fsck finds a bad file (ie, queue a re-download).
diff --git a/doc/devblog/day_290__.mdwn b/doc/devblog/day_290__.mdwn
new file mode 100644
index 0000000000..7b0111485d
--- /dev/null
+++ b/doc/devblog/day_290__.mdwn
@@ -0,0 +1,23 @@
+Worked thru some backlog. Currently stands at 152 messages.
+
+Merged work from Sebastian Reuße to teach the assistant to listen for
+systemd-networkd dbus events when the network connection changes.
+
+Added `git annex get --incomplete`, which can be used to resume whatever it 
+was you were downloading earlier and interrupted, that you've forgotten
+about. ;)
+
+----
+
+The [Isuma Media Players project](http://isuma-media-players.readthedocs.org/en/latest/index.html)
+is using git-annex to "create a two-way, distributed content distribution
+network for communities with poor connexions to the internet".
+My understanding is this involves places [waaay up North](http://www.isuma.tv/did).
+
+Reading over their [design docs](http://isuma-media-players.readthedocs.org/en/latest/design.html)
+is quite interesting, both to see how they've leveraged things
+like git-annex metadata and preferred content expressions and the assistant,
+and areas where git-annex falls short.
+
+Between DataLad, Isuma, Baobáxia, IA.BAK, and more, there are a lot of
+projects being built on top of git-annex now!
diff --git a/doc/devblog/day_291__public_S3.mdwn b/doc/devblog/day_291__public_S3.mdwn
new file mode 100644
index 0000000000..35e1240428
--- /dev/null
+++ b/doc/devblog/day_291__public_S3.mdwn
@@ -0,0 +1,20 @@
+Now git-annex can be used to set up a public S3 remote. If you've cloned a
+repository that knows about such a remote, you can use the S3 remote
+without needing any S3 credentials. Read-only of course.
+
+This tip shows how to do it: [[tips/public_Amazon_S3_remote]]
+
+One rather neat way to use this is to configure the remote with
+`encryption=shared`. Then, the files stored in S3 will be encrypted, and
+anyone with access to the git repository can get and decrypt the files.
+
+This feature will work for at least AWS S3, and for the Internet Archive's
+S3. It may work for other S3 services, that can be configured to publish
+their files over unauthenticated http. There's a `publicurl` configuration
+setting to allow specifying the url when using a service that git-annex
+doesn't know the url for.
+
+Actually, there was a hack for the IA before, that added the public url to
+an item when it was uploaded to the IA. While that hack is now not
+necessary, I've left it in place for now, to avoid breaking anything that
+depended on it.
diff --git a/doc/devblog/day_291__public_S3/comment_1_c0e96b25b764180975cc26b1316f462d._comment b/doc/devblog/day_291__public_S3/comment_1_c0e96b25b764180975cc26b1316f462d._comment
new file mode 100644
index 0000000000..dc51f11108
--- /dev/null
+++ b/doc/devblog/day_291__public_S3/comment_1_c0e96b25b764180975cc26b1316f462d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="richih.mailinglist@c4d55c76731cd68299d3983dc5e6f5385128a68a"
+ nickname="richih.mailinglist"
+ subject="comment 1"
+ date="2015-06-08T23:55:20Z"
+ content="""
+Can you backport that to stable? This would be very useful for video.debconf.net
+
+Thanks,
+Richard
+"""]]
diff --git a/doc/devblog/day_291__public_S3/comment_2_d5223684c09725973b2052425fd30773._comment b/doc/devblog/day_291__public_S3/comment_2_d5223684c09725973b2052425fd30773._comment
new file mode 100644
index 0000000000..7fdb9de425
--- /dev/null
+++ b/doc/devblog/day_291__public_S3/comment_2_d5223684c09725973b2052425fd30773._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-06-09T19:16:11Z"
+ content="""
+Dude, I'm no DD. 
+
+git-annex is backportable to stable in its current state, if/when
+a new version finally gets uploaded to unstable.
+"""]]
diff --git a/doc/devblog/day_292__dead_keys.mdwn b/doc/devblog/day_292__dead_keys.mdwn
new file mode 100644
index 0000000000..3ad66edb5e
--- /dev/null
+++ b/doc/devblog/day_292__dead_keys.mdwn
@@ -0,0 +1,21 @@
+Ever since `git annex fsck --all` was added, people 
+[have](http://bugs.debian.org/753888)
+[[complained|bugs/fsck_reports_unsolvable_problem]] that
+there's no way to stop it complaining about keys whose content is gone for
+good. Well, there is now: `git annex dead --key` can be used when you know
+that a key is no longer available and want fsck to stop complaining about
+it.
+
+Running fsck on a directory will intentionally still complain about files
+in the directory with missing contents, even if the keys have been marked
+dead.
+
+The crucial part was finding a good way to store the information; luckily
+location log files are parsed in a way that lets it be added there without
+breaking backwards compatability. A bonus is that adding a key's content
+back to the annex will automatically bring it back from the dead.
+
+I'm pondering making `git annex drop --force` automatically mark a key as
+dead when the last copy is dropped, but I don't know if it's too DWIM or
+worth the complication. Another approach would be to let fsck mark keys as
+dead, but that would certianly need an extra flag.
diff --git a/doc/devblog/day_293__last_push_before_summer_vacation.mdwn b/doc/devblog/day_293__last_push_before_summer_vacation.mdwn
new file mode 100644
index 0000000000..5cb6bfb4bb
--- /dev/null
+++ b/doc/devblog/day_293__last_push_before_summer_vacation.mdwn
@@ -0,0 +1,26 @@
+Well, not the literal last `push`, but I've caught up on as much backlog as
+I can (142 messages remain) and spent today developing a few final features
+before tomorrow's release.
+
+Some of the newer things displayed by `git annex info` were not included in
+the --json mode output. The json includes everything now.
+
+`git annex sync --all --content` will make it consider all known annexed
+objects, not only those in the current work tree. By default that syncs all
+versions of all files, but of course preferred content can tune what
+repositories want.
+
+To make that work well with preferred content settings like
+"include=*.mp3", it makes two passes. The first pass is over the work tree,
+so preferred content expressions that match files by name will work. The
+second pass is over all known keys, and preferred content expressions
+that don't care about the filename can match those keys. 
+
+Two passes feels a bit like a hack, but it's a lot better than `--all`
+making nothing be synced when the a preferred content expression matches
+against filenames... I actually had to resort to bloom filters to make the
+two passes work.
+
+This new feature led to some
+[slightly tricky follow-on changes](http://source.git-annex.branchable.com/?p=source.git;a=commit;h=8268f7951e9c70760379bd084425b48df99250d6)
+to the [[preferred_content/standard_groups]] preferred content expressions.
diff --git a/doc/devblog/day_294__back_focusing_on_bugs.mdwn b/doc/devblog/day_294__back_focusing_on_bugs.mdwn
new file mode 100644
index 0000000000..0c7b510118
--- /dev/null
+++ b/doc/devblog/day_294__back_focusing_on_bugs.mdwn
@@ -0,0 +1,7 @@
+Back, and have spent all day focusing on new bug reports. All told, I fixed
+4 bugs, followed up on all other bugs reported while I was away, and fixed
+the android autobuilder.
+
+The message backlog started the day at 250 or something, and is down to 178
+now. Looks like others have been following up to forum posts while I was
+away (thanks!) so those should clear quickly.
diff --git a/doc/devblog/day_295__caught_up.mdwn b/doc/devblog/day_295__caught_up.mdwn
new file mode 100644
index 0000000000..cc52882025
--- /dev/null
+++ b/doc/devblog/day_295__caught_up.mdwn
@@ -0,0 +1,8 @@
+Now caught up on nearly all of my backlog of messages, 
+and indeed am getting to some messages that have been waiting for months.
+Backlog is down to 113! Couple of bugfixes resulted, and many questions answered.
+
+Think I'll spend a couple more days dealing with the older part of the
+backlog. Then, when that reaches diminishing returns, I'll move on to some
+big change. I have been thinking about [[design/caching_database]] on and
+off..
diff --git a/doc/devblog/day_296__into_the_backlog.mdwn b/doc/devblog/day_296__into_the_backlog.mdwn
new file mode 100644
index 0000000000..9293db3405
--- /dev/null
+++ b/doc/devblog/day_296__into_the_backlog.mdwn
@@ -0,0 +1,16 @@
+Mostly spent today getting to older messages in the backlog. This did
+result in a few fixes, but with 97 old messages left, I can feel the
+diminishing returns setting in, to try to understand old bug reports that
+are often unclear or lacking necessary info to reproduce them.
+
+By the way, if you feel your bug report or question has gotten lost in my
+backlog, the best thing to do is post an update to it, and help me
+reproduce it, or clarify it.
+
+Moved on to looking through [[todo]], which was a more productive
+way to find useful things to work on. 
+
+Best change made today is that `git annex unused` can now be configured to
+look at the reflog. So, old versions of files are considered still used
+until the reflog expires. If you've wanted a way to only delete (or move
+away) unused files after they get to a certian age, this is a way to do that ...
diff --git a/doc/devblog/day_297__optparse-applicative.mdwn b/doc/devblog/day_297__optparse-applicative.mdwn
new file mode 100644
index 0000000000..0885f0db41
--- /dev/null
+++ b/doc/devblog/day_297__optparse-applicative.mdwn
@@ -0,0 +1,25 @@
+Now working on converting git-annex to use
+[optparse-applicative](https://github.com/pcapriotti/optparse-applicative)
+for its command line parsing. I've wanted to do this for a long time, 
+because the current code for options is generally horrible, runs in
+IO, and is not at all type safe, while optparse-applicative has wonderful
+composable parsers and lets each subcommand have its own data type
+repesenting all its options.
+
+What pushed me over the edge is that optparse-applicative has automatic
+bash completion!
+
+	# source <(git-annex --bash-completion-script `which git-annex`)
+	# git-annex fsck -
+	--all                   --key                   -S
+	--from                  --more                  -U
+
+Since nobody has managed to write a full bash completion for git-annex
+before, let alone keep it up-to-date with changes to the code, automating
+the problem away is a really nice win. :)
+
+The conversion is a rather huge undertaking; the diff is already over 3000
+lines large after 8 hours of work, and I'm maybe 1/3rd done, with
+the groundwork laid (except for global options still todo) and a few
+subcommands  converted. This won't land for this week's release; it'll
+need a lot of testing before it'll be ready for any release.
diff --git a/doc/devblog/day_299__so_many_commands_and_options.mdwn b/doc/devblog/day_299__so_many_commands_and_options.mdwn
new file mode 100644
index 0000000000..04a2c1e2db
--- /dev/null
+++ b/doc/devblog/day_299__so_many_commands_and_options.mdwn
@@ -0,0 +1,9 @@
+Day 3 of the optparse-applicative conversion.  
+116 files changed, 1607 insertions(+), 1135 deletions(-)  
+At this point, everything is done except for around 20 sub-commands.
+Probably takes 15 minutes work for each. Will finish plowing through
+it in the evenings.
+
+Meanwhile, made the release of version 5.20150710. The Android build for
+this version is not available yet, since I broke the autobuilder last week
+and haven't fixed it yet.
diff --git a/doc/devblog/day_29__scheduling.mdwn b/doc/devblog/day_29__scheduling.mdwn
new file mode 100644
index 0000000000..98c928bf8b
--- /dev/null
+++ b/doc/devblog/day_29__scheduling.mdwn
@@ -0,0 +1,10 @@
+Spent most of the day building some generic types for scheduling recurring
+events. Not sure if rolling my own was a good idea, but that's what I did.
+
+In the incrementalfsck branch, I have hooked this up in `git-annex vicfg`,
+which now accepts and parses scheduled events like 
+"fsck self every day at any time for 60 minutes" and 
+"fsck self on day 1 of weeks divisible by 2 at 3:45 for 120 minutes", and
+stores them in the git-annex branch. The exact syntax is of course subject
+to change, but also doesn't matter a whole lot since the webapp will have
+a better interface.
diff --git a/doc/devblog/day_2__new_laptop.mdwn b/doc/devblog/day_2__new_laptop.mdwn
new file mode 100644
index 0000000000..0008007429
--- /dev/null
+++ b/doc/devblog/day_2__new_laptop.mdwn
@@ -0,0 +1,8 @@
+Now I can build git-annex twice as fast! And a typical incremental build is
+down to 10 seconds, from 51 seconds.
+
+Spent a productive evening working with Guilhem to get his encryption
+patches reviewed and merged. Now there is a way to remove revoked gpg keys,
+and there is a new encryption scheme available that uses public key
+encryption by default rather than git-annex's usual approach. That's not
+for everyone, but it is a good option to have available.
diff --git a/doc/devblog/day_2__new_laptop/comment_1_93447dbd4eb09b4db96770644ea663cb._comment b/doc/devblog/day_2__new_laptop/comment_1_93447dbd4eb09b4db96770644ea663cb._comment
new file mode 100644
index 0000000000..15d19b0c95
--- /dev/null
+++ b/doc/devblog/day_2__new_laptop/comment_1_93447dbd4eb09b4db96770644ea663cb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
+ nickname="Laszlo"
+ subject="comment 1"
+ date="2013-09-05T15:07:44Z"
+ content="""
+out of curiosity, what laptop model have you choosen finally?
+
+Laszlo
+"""]]
diff --git a/doc/devblog/day_2__new_laptop/comment_2_e1d022b25f2c16dbe72db07ad4b10a2d._comment b/doc/devblog/day_2__new_laptop/comment_2_e1d022b25f2c16dbe72db07ad4b10a2d._comment
new file mode 100644
index 0000000000..0525975216
--- /dev/null
+++ b/doc/devblog/day_2__new_laptop/comment_2_e1d022b25f2c16dbe72db07ad4b10a2d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.54"
+ subject="comment 2"
+ date="2013-09-06T18:02:08Z"
+ content="""
+Lenovo Yoga 11s
+"""]]
diff --git a/doc/devblog/day_300__optparse-applicative_landed.mdwn b/doc/devblog/day_300__optparse-applicative_landed.mdwn
new file mode 100644
index 0000000000..e46dfceeea
--- /dev/null
+++ b/doc/devblog/day_300__optparse-applicative_landed.mdwn
@@ -0,0 +1,3 @@
+Worked through the rest of the changes this weekend and morning, and the
+optparse-applicative branch has landed in master,
+including bash completion support.
diff --git a/doc/devblog/day_301__completion_and_er_completion.mdwn b/doc/devblog/day_301__completion_and_er_completion.mdwn
new file mode 100644
index 0000000000..871b4c49d4
--- /dev/null
+++ b/doc/devblog/day_301__completion_and_er_completion.mdwn
@@ -0,0 +1,9 @@
+Worked on bash tab completion some more. Got "git annex" to also tab complete.
+However, for that to work perfectly when using bash-completion to demand-load
+completion scripts, a small improvement is needed in git's own completion
+script, to have it load git-annex's completion script. I sent a 
+[patch for that to the git developers](http://thread.gmane.org/gmane.comp.version-control.git/274034),
+and hopefully it'll get accepted soon.
+
+Then fixed a relatively long-standing bug that prevented uploads to
+chunked remotes from resuming after the last successfully uploaded chunk.
diff --git a/doc/devblog/day_302-305__gitlab.mdwn b/doc/devblog/day_302-305__gitlab.mdwn
new file mode 100644
index 0000000000..05048ebb69
--- /dev/null
+++ b/doc/devblog/day_302-305__gitlab.mdwn
@@ -0,0 +1,30 @@
+I've been working on adding GitLab support to the webapp for the past 3
+days.
+
+That's not the only thing I've been working on; I've continued to work on
+the older parts of the backlog, which is now shrunk to 91 messages, and
+made some minor improvements and bugfixes.
+
+But, GitLab support in the webapp has certianly taken longer than I'd have
+expected. Only had to write 82 lines of GitLab specific code so far, but it
+went slowly. The user will need to cut and paste repository url and
+ssh public key back and forth between the webapp and GitLab for now. And
+the way GitLab repositories use git-annex makes it a bit tricky to set up;
+in one case the webapp has to do a forced push dry run to check if the
+repository on GitLab can be accessed by ssh.
+
+I found a way to adapt the existing code for setting up a ssh server to
+also support GitLab, so beyond the repo url prompt and ssh key setup,
+everything will be reused. I have something that works now, but there are
+lots of cases to test (encrypted repositories, enabling existing
+repositories, etc), so will need to work on it a bit more before merging
+this feature.
+
+Also took some time to split the [centralized git repository tutorial](http://git-annex.branchable.com/tips/centralized_git_repository_tutorial/)
+into three parts, one for each of GitHub, GitLab, and self-administered servers.
+
+----
+
+The git-annex package in Debian unstable hasn't been updated for 8 months.
+This is about to change; Richard Hartmann has stepped up and is preparing
+an upload of a recent version. Yay!
diff --git a/doc/devblog/day_306__release_day.mdwn b/doc/devblog/day_306__release_day.mdwn
new file mode 100644
index 0000000000..dbc0f5e925
--- /dev/null
+++ b/doc/devblog/day_306__release_day.mdwn
@@ -0,0 +1,8 @@
+Made a release today, with recent work, including the optparse-applicative
+transition and initial gitlab.com support in the webapp.
+
+I had time before the release to work out most of the wrinkles in the
+gitlab.com support, but was not able to get gcrypt encrypted repos to work
+with gitlab, for reasons that remain murky. Their git-annex-shell seems to
+be misbehaving somehow. Will need to get some debugging assistance from the
+gitlab.com developers to figure that out.
diff --git a/doc/devblog/day_307__two_release_week.mdwn b/doc/devblog/day_307__two_release_week.mdwn
new file mode 100644
index 0000000000..0b8a1595ec
--- /dev/null
+++ b/doc/devblog/day_307__two_release_week.mdwn
@@ -0,0 +1,11 @@
+Made a release this morning, mostly because the release earlier this week
+turns out to have accidentally removed several options from `git annex copy`.
+
+Spent some time this afternoon improving how git-annex shuts down when
+--time-limit is used. This used to be a quick and dirty shutdown, similar
+to if git-annex were ctrl-c'd, but I reworked things so it does a clean
+shutdown, including running any buffered git commands. 
+This made incremental fsck with --time-limit resume much better, since
+it saves the incremental fsck database on shutdown. Also tuned when the
+database gets checkpointed during an incremental fsck, to resume better after
+it's interrupted.
diff --git a/doc/devblog/day_308__other_peoples_bugs.mdwn b/doc/devblog/day_308__other_peoples_bugs.mdwn
new file mode 100644
index 0000000000..1b0d81828a
--- /dev/null
+++ b/doc/devblog/day_308__other_peoples_bugs.mdwn
@@ -0,0 +1,11 @@
+Work today has started in the git-annex bug tracker, but the real bugs were
+elsewhere. Got a patch into hinotify to fix its handling of filenames
+received from inotify events when used in a non-unicode locale. Tracked
+down why gitlab's git-annex-shell fails to initialize gcrypt repositories,
+and filed a bug on gitlab-shell.
+
+Yesterday, I got the Android autobuilder fixed. I had started upgrading it
+to new versions of yesod etc, 2 months ago, and something in those new
+versions led to character encoding problems that broke the template haskell
+splicing. Had to throw away the work done for that upgrade, but at least
+it's building again, at last.
diff --git a/doc/devblog/day_309__proxy.mdwn b/doc/devblog/day_309__proxy.mdwn
new file mode 100644
index 0000000000..4afc4c23e5
--- /dev/null
+++ b/doc/devblog/day_309__proxy.mdwn
@@ -0,0 +1,5 @@
+Ended up sending most of today working on `git annex proxy`. It had a lot
+of buggy edge cases, which are all cleaned up now.
+
+Spent another couple hours catching up on recent traffic and fixing a
+couple other misc bugs.
diff --git a/doc/devblog/day_30__cronner.mdwn b/doc/devblog/day_30__cronner.mdwn
new file mode 100644
index 0000000000..f368407caa
--- /dev/null
+++ b/doc/devblog/day_30__cronner.mdwn
@@ -0,0 +1,17 @@
+Lots of progress from yesterday's modest start of building data types for
+scheduling. Last night I wrote the hairy calendar code to calculate when
+next to run a scheduled event. (This is actually quite superior to `cron`,
+which checks every second to see if it should run each event!) Today I
+built a "Cronner" thread that handles spawning threads to handle each
+scheduled event. It even notices when changes have been made to the its
+schedule and stops/starts event threads appropriately.
+
+Everything is hooked up, building, and there's a good chance it works
+without too many bugs, but while I've tested all the pure code (mostly
+automatically with quickcheck properties), I have not run the Cronner
+thread at all. And there is some tricky stuff in there, like noticing
+that the machine was asleep past when it expected to wake up, and deciding
+if it should still run a scheduled event, or should wait until next time.
+So tomorrow we'll see..
+
+Today's work was sponsored by Ethan Aubin.
diff --git a/doc/devblog/day_30__cronner/comment_1_53dfd9310e92f5225db52a13e20a46d4._comment b/doc/devblog/day_30__cronner/comment_1_53dfd9310e92f5225db52a13e20a46d4._comment
new file mode 100644
index 0000000000..dc0c7dfe1c
--- /dev/null
+++ b/doc/devblog/day_30__cronner/comment_1_53dfd9310e92f5225db52a13e20a46d4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://nullroute.eu.org/~grawity/"
+ nickname="Mantas"
+ subject="comment 1"
+ date="2013-10-09T06:04:15Z"
+ content="""
+The SysV Unix *cron* learned this same thing [in 1979][1].
+
+[1]: http://en.wikipedia.org/wiki/Cron#Multi-user_capability
+"""]]
diff --git a/doc/devblog/day_30__cronner/comment_2_f98357c6f7a6da23873ac27c2e1e9638._comment b/doc/devblog/day_30__cronner/comment_2_f98357c6f7a6da23873ac27c2e1e9638._comment
new file mode 100644
index 0000000000..0fc310a780
--- /dev/null
+++ b/doc/devblog/day_30__cronner/comment_2_f98357c6f7a6da23873ac27c2e1e9638._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.22"
+ subject="comment 2"
+ date="2013-10-11T17:07:24Z"
+ content="""
+However, if you strace a traditional cron, you will be sad at how it's implemented. So much statting of files, and checking of entries every second..
+
+0 polling or redundant calulcation in my code!
+"""]]
diff --git a/doc/devblog/day_310__half_day.mdwn b/doc/devblog/day_310__half_day.mdwn
new file mode 100644
index 0000000000..01b76d7bff
--- /dev/null
+++ b/doc/devblog/day_310__half_day.mdwn
@@ -0,0 +1,7 @@
+Took a half day and worked on making it simpler to set up ssh remotes.
+The complexity I've gotten rid of is there's no need to take any action to
+get a ssh remote initialized as a git-annex repository. Where before,
+either git-annex init needed to be ran on the remote, or a git-annex branch
+manually pushed to it, now the remote can simply be added and `git annex sync`
+will do the rest. This needed git-annex-shell changes, so will only work
+once servers are upgraded to use a newer version of git-annex.
diff --git a/doc/devblog/day_310__half_day/comment_1_81db682a271ebc92cce893762c3930a8._comment b/doc/devblog/day_310__half_day/comment_1_81db682a271ebc92cce893762c3930a8._comment
new file mode 100644
index 0000000000..57d9bc97ab
--- /dev/null
+++ b/doc/devblog/day_310__half_day/comment_1_81db682a271ebc92cce893762c3930a8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="great news"
+ date="2015-08-05T18:52:47Z"
+ content="""
+that's great news. this has been a major usability WTF for me in the past!
+
+thanks!
+"""]]
diff --git a/doc/devblog/day_311__SHA-3.mdwn b/doc/devblog/day_311__SHA-3.mdwn
new file mode 100644
index 0000000000..d4936cf8bd
--- /dev/null
+++ b/doc/devblog/day_311__SHA-3.mdwn
@@ -0,0 +1,6 @@
+The SHA-3 specification was released yesterday; git-annex got support for
+using SHA-3 hashes today. I had to add support for building with the new
+cryptonite library, as cryptohash doesn't (correctly) implement SHA-3 yet.
+Of course, nobody is likely to find a use for this for years, since SHA-2
+is still prefectly fine, but it's nice to get support for new hashes
+in early. :)
diff --git a/doc/devblog/day_312__release_prep.mdwn b/doc/devblog/day_312__release_prep.mdwn
new file mode 100644
index 0000000000..4e0db7de26
--- /dev/null
+++ b/doc/devblog/day_312__release_prep.mdwn
@@ -0,0 +1,12 @@
+Catching up on weekend's traffic, and preparing for a release tomorrow.
+
+Found another place where the optparse-applicative conversion broke some
+command-line parsing; using git-annex metadata to dump metadata recursively
+got broken. This is the second known bug caused by that transition, which
+is not too surpising given how large it was.
+
+Tracked down and fixed a [very tricky encoding problem with metadata values](http://git-annex.branchable.com/bugs/view_fails_with___34__invalid_character__34__/).
+
+The arm autobuilder broke so it won't boot; got a serial console hooked up
+to it and looks like a botched upgrade resulting in a udev/systemd/linux
+version mismatch.
diff --git a/doc/devblog/day_313__optimisation.mdwn b/doc/devblog/day_313__optimisation.mdwn
new file mode 100644
index 0000000000..feedf09e0f
--- /dev/null
+++ b/doc/devblog/day_313__optimisation.mdwn
@@ -0,0 +1,7 @@
+Been doing a little bit of optimisation work. Which meant, first improving
+the --debug output to show fractions of a second, and show when commands
+exit.
+
+That let me measure what takes up time when downloading files from ssh remotes.
+Found one place I could spawn a thread to run a cleanup action, and this simple
+change reduced the non-data-transfer overhead to 1/6th of what it had been!
diff --git a/doc/devblog/day_314__pre_trip_catchup.mdwn b/doc/devblog/day_314__pre_trip_catchup.mdwn
new file mode 100644
index 0000000000..15546aa23c
--- /dev/null
+++ b/doc/devblog/day_314__pre_trip_catchup.mdwn
@@ -0,0 +1,13 @@
+Did some work on Friday and Monday to let external special remotes be used
+in a readonly mode. This lets files that are stored in the remote be
+downloaded by git-annex without the user needing to install the 
+external special remote program. For this to work, the external special
+remote just has to tell git-annex the urls to use. This was developed in
+collaboration with Benjamin Gilbert, who is developing
+[gcsannex](https://github.com/bgilbert/gcsannex), a Google Cloud Storage
+special remote.
+
+Today, got caught up with recent traffic, including fixing a couple of
+bugs. The backlog remains in the low 90's, which is a good place to be as I
+prepare for my August vacation week in the SF Bay Area, followed by a week
+for ICFP and the Haskell Symposium in Vancouver.
diff --git a/doc/devblog/day_315__scrambling.mdwn b/doc/devblog/day_315__scrambling.mdwn
new file mode 100644
index 0000000000..5a6f0441b2
--- /dev/null
+++ b/doc/devblog/day_315__scrambling.mdwn
@@ -0,0 +1,5 @@
+Today was a scramble to get caught up after weeks away. Got the message
+backlog down from over 160 to 123. Fixed two reversions, worked around a
+[strange bug](https://github.com/yesodweb/persistent/issues/474),
+and implemented support for the `gpg.program` configuration, and made
+several smaller improvements.
diff --git a/doc/devblog/day_316-318__chasing_dependencies_and_todos.mdwn b/doc/devblog/day_316-318__chasing_dependencies_and_todos.mdwn
new file mode 100644
index 0000000000..9c656d0799
--- /dev/null
+++ b/doc/devblog/day_316-318__chasing_dependencies_and_todos.mdwn
@@ -0,0 +1,24 @@
+Seems that Git for Windows was released a few weeks ago, replacing msysgit.
+There were a couple problems using git-annex with that package of git,
+which I fixed on Thursday. The next release of git-annex won't work with
+msysgit any longer though; only with Git for Windows.
+
+On Friday, I improved the Windows package further, making it work even when
+git is not added to the system PATH. In such an installation, git-annex
+will now work inside the "git bash" window, and I even got the webapp
+starting from the menu working without git in PATH.
+
+----
+
+In other dependency fun, the daily builds for Linux got broken due to a
+glibc bug in Debian unstable/testing, which makes the bundled curl and ssh
+segfault. With some difficulty I tracked that down, and it turns out the
+bug has been [fixed upstream](https://sourceware.org/bugzilla/show_bug.cgi?id=16381)
+for quite a while. The daily builds are now using the fixed glibc 2.21.
+
+----
+
+Today, got back to making useful improvements, rather than chasing
+dependencies. Improved the bash completion for remotes and backends,
+made annex.hardlink be used more, and made special remotes that are
+configured with autoenable=true get automatically enabled by `git annex init`.
diff --git a/doc/devblog/day_319__release_day.mdwn b/doc/devblog/day_319__release_day.mdwn
new file mode 100644
index 0000000000..5679501659
--- /dev/null
+++ b/doc/devblog/day_319__release_day.mdwn
@@ -0,0 +1,6 @@
+Made the release this morning, first one in 3 weeks. A fair lot of good
+stuff in there.
+
+Just in time for the release, git-annex has support for
+[Ceph](http://ceph.com/). Thanks to Mesar Hameed for building 
+[the external special remote](https://github.com/mhameed/git-annex-remote-ceph)!
diff --git a/doc/devblog/day_31__blah.mdwn b/doc/devblog/day_31__blah.mdwn
new file mode 100644
index 0000000000..672adbfd37
--- /dev/null
+++ b/doc/devblog/day_31__blah.mdwn
@@ -0,0 +1,17 @@
+Some neat stuff is coming up, but today was a pretty blah day for me.
+I did get the Cronner tested and working (only had a few little bugs). But
+I got stuck for quite a while making the Cronner stop `git-annex fsck`
+processes it was running when their jobs get removed. I had some code to do
+this that worked when run standalone, but not when run from git-annex.
+
+After considerable head-scratching, I found out this was due to
+`forkProcess` masking aync exceptions, which seems to be probably
+[a bug](http://ghc.haskell.org/trac/ghc/ticket/8433). Luckily was able to
+work around it. Async exceptions continue to strike me as the worst part of
+the worst part of Haskell (the worst part being exceptions in general).
+
+Was more productive after that.. Got the assistant to automatically queue
+re-downloads of any files that fsck throws out due to having bad contents,
+and made the webapp display an alert while fscking is running, which will
+go to the page to configure fsck schedules. Now all I need to do is
+build the UI of that page.
diff --git a/doc/devblog/day_320__caught_up.mdwn b/doc/devblog/day_320__caught_up.mdwn
new file mode 100644
index 0000000000..8c8c85ae1b
--- /dev/null
+++ b/doc/devblog/day_320__caught_up.mdwn
@@ -0,0 +1,13 @@
+I've mostly been chewing through old and new bug reports and support
+requests that past several days. The backlog is waaay low now -- only 82
+messages! Just in time for me to go on another trip, to Louisville on
+Thursday.
+
+Amazon S3 added an "Infrequent Access" storage class last week, and I got a
+patch into the haskell-aws library to support that, as well as partially
+supporting Google Nearline. That patch was accepted today, and git-annex is
+ready to use the new version of the library as soon as it's released.
+
+At the end of today, I found myself rewriting `git annex status` to parse
+and adjust the output of `git status --short`. This new method makes it
+much more capable than before, including displaying Added files.
diff --git a/doc/devblog/day_320__porting_and_such.mdwn b/doc/devblog/day_320__porting_and_such.mdwn
new file mode 100644
index 0000000000..a62510a1e3
--- /dev/null
+++ b/doc/devblog/day_320__porting_and_such.mdwn
@@ -0,0 +1,13 @@
+Lots of porting work ongoing recently:
+
+* I've been working with [Goeke](http://www.goeke.net/) on building git-annex
+  on Solaris/SmartOS. Who knows, this may lead to a binary distribution
+  in some way, but to start with I got the disk free space code ported
+  to Solaris, and have seen git-annex work there.
+* Jirib has also been working on that same disk free code, porting it to
+  OpenBSD. Hope to land an updated patch for that.
+* Yury kindly updated the Windows autobuilder to a new Haskell Platform
+  release, and I was able to land the `winprocfix` branch that fixes
+  ssh password prompting in the webapp on Windows.
+* The arm autobuilder is fixed and back in its colo, and should be making
+  daily builds again.
diff --git a/doc/devblog/day_321__download_verification.mdwn b/doc/devblog/day_321__download_verification.mdwn
new file mode 100644
index 0000000000..e8c944364a
--- /dev/null
+++ b/doc/devblog/day_321__download_verification.mdwn
@@ -0,0 +1,13 @@
+While at the DerbyCon security conference, I got to thinking about
+verifying objects that git-annex downloads from remotes. This can be
+expensive for big files, so git-annex has never done it at download time,
+instead deferring it to fsck time. But, that is a divergence from git,
+which always verifies checksums of objects it receives. So, it violates
+least surprise for git-annex to not verify checksums too. And this could
+weaken security in some use cases.
+
+So, today I changed that. Now whenever git-annex accepts an object into
+.git/annex/objects, it first verifies its checksum and size. I did add a
+setting to disable that and get back the old behavior: `git config
+annex.verify false`, and there's also a per-remote setting if you want to
+verify content from some remotes but not others.
diff --git a/doc/devblog/day_321__download_verification/comment_1_424367fba4db56f4699952572bd3d605._comment b/doc/devblog/day_321__download_verification/comment_1_424367fba4db56f4699952572bd3d605._comment
new file mode 100644
index 0000000000..447bd39433
--- /dev/null
+++ b/doc/devblog/day_321__download_verification/comment_1_424367fba4db56f4699952572bd3d605._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 1"
+ date="2015-10-02T04:13:07Z"
+ content="""
+It might be nice to set `annex.verify-threshold` to verify all files below a certain size.  This could default to 500MB.
+"""]]
diff --git a/doc/devblog/day_321__download_verification/comment_2_926cc165e99f2e125c909bd706460a05._comment b/doc/devblog/day_321__download_verification/comment_2_926cc165e99f2e125c909bd706460a05._comment
new file mode 100644
index 0000000000..a75caf5351
--- /dev/null
+++ b/doc/devblog/day_321__download_verification/comment_2_926cc165e99f2e125c909bd706460a05._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 2"
+ date="2015-10-02T04:15:48Z"
+ content="""
+I mean: *only* files below that size.
+"""]]
diff --git a/doc/devblog/day_321__download_verification/comment_3_fb0ed50c27a493c3494bf2efbf9a9c5d._comment b/doc/devblog/day_321__download_verification/comment_3_fb0ed50c27a493c3494bf2efbf9a9c5d._comment
new file mode 100644
index 0000000000..657b61bace
--- /dev/null
+++ b/doc/devblog/day_321__download_verification/comment_3_fb0ed50c27a493c3494bf2efbf9a9c5d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="encryptio"
+ subject="comment 3"
+ date="2015-10-03T21:09:31Z"
+ content="""
+Nice! I actually had been doing `git annex get $file && git annex fsck $file` in all my scripts already because I had run into an issue where a bad file got replicated everywhere, and the only good copy I had was `drop`ped before I realized. This would have caught it. Thanks!
+"""]]
diff --git a/doc/devblog/day_321__download_verification/comment_4_fecb2d6349aa61f1c76525178fea4598._comment b/doc/devblog/day_321__download_verification/comment_4_fecb2d6349aa61f1c76525178fea4598._comment
new file mode 100644
index 0000000000..26d60c868f
--- /dev/null
+++ b/doc/devblog/day_321__download_verification/comment_4_fecb2d6349aa61f1c76525178fea4598._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="sunny256"
+ subject="Yay, man!"
+ date="2015-10-04T23:28:43Z"
+ content="""
+I love this! Especially since I've noticed some read errors on my laptop disk now and then. Not when using git-annex, I've never lost a file with it, but when doing other things. I've been hoping for this, as I've used computers with memory corruption years ago, and in cases like that, all bets are off and you'll only hope that the file copy goes well. I've grown quite paranoid after that computer, and have enabled everything in git (setting `fetch.fsckObjects`, `receive.fsckObjects` and `transfer.fsckObjects` to `true`) to catch potential errors as a result of bad disk, memory corruption or transfer errors over the network. I'd rather wait a bit longer while copying or especially moving files than wait for that single corrupted bit in the only copy of a 4 gig file. Thanks!
+"""]]
diff --git a/doc/devblog/day_322-326__concurrent_drop_safety.mdwn b/doc/devblog/day_322-326__concurrent_drop_safety.mdwn
new file mode 100644
index 0000000000..5dbf420e4c
--- /dev/null
+++ b/doc/devblog/day_322-326__concurrent_drop_safety.mdwn
@@ -0,0 +1,49 @@
+Well, I've spent all week making `git annex drop --from` safe.
+
+On Tuesday I got a sinking feeling in my stomach, as I realized that
+there was hole in git-annex's armor to prevent concurrent drops from
+violating numcopies or even losing the last copy of a file.
+[[The bug involved an unlikely race condition|bugs/concurrent_drop--from_presence_checking_failures]],
+and for all I know it's never happened in real life, but still this is not
+good.
+
+Since this is a potential data loss bug, expect a release pretty soon 
+with the fix. And, there are 2 things to keep in mind about the fix:
+
+1. If a ssh remote is using an old version of git-annex, a drop may fail.
+   Solution will be to just upgrade the git-annex on the remote to the
+   fixed version.
+2. When a file is present in several special remotes, but not in any
+   accessible git repositories, dropping it from one of the special
+   remotes will now fail, where before it was allowed.
+
+   Instead, the file has to be moved from one of the special remotes to
+   the git repository, and can then safely be dropped from the git repository.
+
+   This is a worrysome behavior change, but unavoidable.
+
+Solving this clearly called for more locking, to prevent concurrency
+problems. But, at first I couldn't find a solution that would allow
+dropping content that was only located on special remotes. I didn't want to
+make special remotes need to involve locking; that would be a nightmare to
+implement, and probably some existing special remotes don't have any
+way to do locking anyway.
+
+Happily, after thinking about it all through Wednesday, I found a solution,
+that while imperfect (see above) is probably the best one feasible. If my
+analysis is correct (and it seems so, although I'd like to write a more
+formal proof than the ad-hoc one I have so far), no locking is needed on
+special remotes, as long as the locking is done just right on the git repos
+and remotes. While this is not able to guarantee that numcopies is always
+preserved, it is able to guarantee that the last copy of a file is never
+removed. And, numcopies *will* always be preserved except for when this
+rare race condition occurs.
+
+So, I've been implementing that all of yesterday and today. Getting it
+right involves building up 4 different kinds of evidence, which can be
+used to make sure that the last copy of a file can't possibly end up being
+dropped, no matter what other concurrent drops could be happening.
+I ended up with a very clean and robust implementation of this, and
+a 2,000 line diff.
+
+Whew!
diff --git a/doc/devblog/day_327__soaking.mdwn b/doc/devblog/day_327__soaking.mdwn
new file mode 100644
index 0000000000..d2f033d5f5
--- /dev/null
+++ b/doc/devblog/day_327__soaking.mdwn
@@ -0,0 +1,16 @@
+Feeling kind of ready to cut the next release of git-annex, but am giving
+the recent large changes just a little time to soak in and make sure
+they're ok.
+
+Yesterday, changed the order that `git annex sync --content` and the
+assistant do drops. When dropping from the local repo and also some
+remotes, it now makes more sense to drop from the remotes first, and only
+then the local repo. There are scenaries where that order lets content be
+dropped from all the places that it should be, while the reverse order
+doesn't.
+
+Today, caught up on recent bug reports, including fixing a bad merge
+commit that was made when git merge failed due to filenames not supported by
+a crippled filesystem, and cleaning up a network transport warning that was
+displayed incorrectly. Also developed a patch to the `aws` library to
+support google nearline when creating buckets.
diff --git a/doc/devblog/day_328__git-annex_is_five.mdwn b/doc/devblog/day_328__git-annex_is_five.mdwn
new file mode 100644
index 0000000000..d1dfc9c456
--- /dev/null
+++ b/doc/devblog/day_328__git-annex_is_five.mdwn
@@ -0,0 +1,15 @@
+The first release of git-annex was 5 years ago.
+
+There have been a total of 187 releases, growing to 50k lines of haskell
+code developed by 28 contributors (and another 10 or so external special
+remote contributors). Approximately 2000 people have posted questions,
+answers, bugs, todos, etc to this website, with 18900 posts in total.
+
+I've been funded for 3 of the 5 years to work on git-annex, with support
+from [[1451 individuals and 6 organizations|thanks]].
+
+Released a new version today with rather more significant changes than usual
+(see recent devblog entries).
+
+The [2015 git-annex user survey](http://git-annex-survey.branchable.com/polls/2015/)
+is now live.
diff --git a/doc/devblog/day_328__git-annex_is_five/comment_1_ff7e8d4c37f4a1aa189af0354db8794a._comment b/doc/devblog/day_328__git-annex_is_five/comment_1_ff7e8d4c37f4a1aa189af0354db8794a._comment
new file mode 100644
index 0000000000..ef8bedc5b8
--- /dev/null
+++ b/doc/devblog/day_328__git-annex_is_five/comment_1_ff7e8d4c37f4a1aa189af0354db8794a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="happy birthday!"
+ date="2015-10-19T20:58:57Z"
+ content="""
+wow, this is great news! :) happy birthday to git-annex, and congratulations on the parents - which is mostly Joey, i guess, but also all those kickstarter contributors, docs writers, bug reporters and patch senders!
+
+long (hopefully *eternal*) life to git-annex and the data it protects! :)
+
+and thanks again, and again joeyh!
+"""]]
diff --git a/doc/devblog/day_328__git-annex_is_five/comment_2_9e18a2c71884229f06b5ba62a6529a33._comment b/doc/devblog/day_328__git-annex_is_five/comment_2_9e18a2c71884229f06b5ba62a6529a33._comment
new file mode 100644
index 0000000000..404eb4ec7e
--- /dev/null
+++ b/doc/devblog/day_328__git-annex_is_five/comment_2_9e18a2c71884229f06b5ba62a6529a33._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2015-10-21T09:59:06Z"
+ content="""
+Yay! Really glad I got to be part of (part of) the journey so far :)
+
+Thank you Joey. Hip hip, hooray!
+"""]]
diff --git a/doc/devblog/day_32__fsck_config_UI.mdwn b/doc/devblog/day_32__fsck_config_UI.mdwn
new file mode 100644
index 0000000000..66f4cfd54f
--- /dev/null
+++ b/doc/devblog/day_32__fsck_config_UI.mdwn
@@ -0,0 +1,20 @@
+Last night, built this nice user interface for configuring periodic fscks:
+
+[[!img assistant/fsckconfig.png]]
+
+Rather happy that that whole UI needed only 140 lines of code to build.
+Though rather more work behind it, as seen in this blog..
+
+Today I added some support to git-annex for smart fscking of remotes.
+So far only git repos on local drives, but this should get extended to
+git-annex-shell for ssh remotes. The assistant can also run periodic fscks
+of these.
+
+Still need to test that, and find a way to make a removable drive's fsck
+job run when the drive gets plugged in. That's where picking "any time"
+will be useful; it'll let you configure fscking of removable drives when
+they're available, as long as they have not been fscked too recently.
+
+----
+
+Today's work was sponsored by Georg Bauer.
diff --git a/doc/devblog/day_331__concurrent-output_preparations.mdwn b/doc/devblog/day_331__concurrent-output_preparations.mdwn
new file mode 100644
index 0000000000..028147ad53
--- /dev/null
+++ b/doc/devblog/day_331__concurrent-output_preparations.mdwn
@@ -0,0 +1,11 @@
+Today started with getting a release of git-annex out, to deal with a new
+version of the aws library, which broke the build. That also added support
+to the S3 remotes for creating Google Nearline buckets, although only when
+git-annex is built with the newest version of the aws library.
+
+Rest of the day (and most of the past weekend) I've been working on the
+concurrent-output library. Today I finished making it support multi-line
+regions, and color, and even fully optimised its console updates to use
+minimal bandwidth. So, it's got everything git-annex can possibly need
+to display those troublesome concurrent actions. Will be starting to make
+git-annex use it soon!
diff --git a/doc/devblog/day_332__concurrent_output_at_long_last.mdwn b/doc/devblog/day_332__concurrent_output_at_long_last.mdwn
new file mode 100644
index 0000000000..39003557ec
--- /dev/null
+++ b/doc/devblog/day_332__concurrent_output_at_long_last.mdwn
@@ -0,0 +1,6 @@
+Got git-annex using concurrent-output today. It works beautifully.
+Since the library is new, git-annex has to be explicitly configured to use
+it, so it'll be a while until this is available in regular builds.
+
+There are no progress bars yet in concurrent output mode, but that will change
+soon.. Probably tomorrow.
diff --git a/doc/devblog/day_333__cylons.mdwn b/doc/devblog/day_333__cylons.mdwn
new file mode 100644
index 0000000000..36eb738dc0
--- /dev/null
+++ b/doc/devblog/day_333__cylons.mdwn
@@ -0,0 +1,5 @@
+Spent my time today porting concurrent-output to Windows, fixing a
+tricky problem with error handling/thread joining with git-annex -J,
+and improving the concurrent state handling to support the git command
+queue. Got add/addurl working in concurrent mode.
+No concurrent progress bars yet.. maybe tomorrow?
diff --git a/doc/devblog/day_334__too_easy.mdwn b/doc/devblog/day_334__too_easy.mdwn
new file mode 100644
index 0000000000..1f9f7aabc3
--- /dev/null
+++ b/doc/devblog/day_334__too_easy.mdwn
@@ -0,0 +1,6 @@
+Finally concurrent progress bars are working! After all the groundwork,
+it was really easy to add, under a dozen lines of code.
+
+I've found several bugs while testing commands in -Jn mode, and the rest of
+today was spent fixing them. Two of them affected concurrent `git annex
+add`; the worst narrowly avoided being a data loss bug.
diff --git a/doc/devblog/day_334__too_easy/comment_1_2181970ef1a3380407ce9eef311c9ebc._comment b/doc/devblog/day_334__too_easy/comment_1_2181970ef1a3380407ce9eef311c9ebc._comment
new file mode 100644
index 0000000000..4598cc3eab
--- /dev/null
+++ b/doc/devblog/day_334__too_easy/comment_1_2181970ef1a3380407ce9eef311c9ebc._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="could / will this help with global status?"
+ date="2015-11-07T16:43:42Z"
+ content="""
+is there some plans to address [[todo/wishlist:_global_progress_status/]] alongside this? thanks, inspiring and innovative stuff here... --- [[anarcat]]
+"""]]
diff --git a/doc/devblog/day_335__catching_up_with_the_bug_reports.mdwn b/doc/devblog/day_335__catching_up_with_the_bug_reports.mdwn
new file mode 100644
index 0000000000..2db6f14375
--- /dev/null
+++ b/doc/devblog/day_335__catching_up_with_the_bug_reports.mdwn
@@ -0,0 +1,4 @@
+Some work today on improving the standalone linux builds and the
+git-annex-standalone.deb. Also, improved fscks's behavior when asked to
+fsck a dead repo, and fixed some places in the assistant where configured
+ssh-options were not used. Backlog is back down to 95.
diff --git a/doc/devblog/day_336__green.mdwn b/doc/devblog/day_336__green.mdwn
new file mode 100644
index 0000000000..2d1bff774b
--- /dev/null
+++ b/doc/devblog/day_336__green.mdwn
@@ -0,0 +1,15 @@
+Test suite is 100% green! Fixed one remaining bug it found, and solved the
+strange sqlite crash, which turned out to be caused by the test suite deleting
+its temporary repository before sqlite was done with the database inside it.
+
+The only remaining blocker for using v6 unlocked files is a bad interaction
+with shared clones. That should be easy to fix, so release of git-annex
+version 6 is now not far away!
+
+While I've only talked about v6/[[todo/smudge]] stuff here lately, I have been
+fixing various other bugs along the way, and have accumulated a dozen bug
+fixes since the last release. Earlier this week I fixed a bug in `git annex
+unused`. Yesterday I noticed that `git annex migrate` didn't copy over
+metadata. Today, fixed a crash of `git annex view` in a non-unicode locale.
+Etc. So it'll be good not to have the release blocked any longer by v6
+stuff.
diff --git a/doc/devblog/day_336__pid_locks.mdwn b/doc/devblog/day_336__pid_locks.mdwn
new file mode 100644
index 0000000000..03ca076e65
--- /dev/null
+++ b/doc/devblog/day_336__pid_locks.mdwn
@@ -0,0 +1,27 @@
+Been working today on getting git-annex to fall back from nice posix fcntl
+locks to pid locks when the former are not supported. There will be an
+`annex.pidlock` to control this. Mostly useful, I think for networked file
+systems like NFS and Lustre. While these *do* support posix locks, I
+guess it can be hard sometimes to get some big server configured
+appropriately, especially when you don't admin it and just want to use
+git-annex there.
+
+Of course, the fun part about pid locks is that it can be pretty hard to
+tell if one is stale or not. Especialy when using a networked filesystem,
+because then the pid in question can be running on a different computer.
+
+Even if you do figure out that a pid lock is stale, how do you then
+take over a stale pid lock, without racing with anther process that
+also wants to take it over? This was the truely tricky question of the
+day.
+
+I have a possibly slightly novel approach to solve that: 
+Put a more modern lock file someplace else (eg, /dev/shm)
+and use that lock file to lock the pid lock file. Then you can tell if 
+a local pid lock file is stale quickly locally, and take it over safely.
+Of course, if the pid is not locked by a local process, this still
+has to fall back to the inevitable retry-and-timeout-and-fail.
+
+I hope the result will work pretty well, although git-annex will not
+support as fine-grained concurrency when using pid locks. Will find out
+tomorrow when I run today's code! ;)
diff --git a/doc/devblog/day_337__who_needs_POSIX.mdwn b/doc/devblog/day_337__who_needs_POSIX.mdwn
new file mode 100644
index 0000000000..3ab185cc91
--- /dev/null
+++ b/doc/devblog/day_337__who_needs_POSIX.mdwn
@@ -0,0 +1,21 @@
+Got the pid locks working pretty easily, as expected.
+
+But then... Detoured into some truely insane behavior of the Lustre
+filesystem. It seems that Lustre is perfectly happy to let link()
+succeed even when there's a file there that it would overwrite. Rather than
+overwriting the file, Lustre picks an even more crazy way to violate
+POSIX.. It lets there be 2 files in a directory with the **same name**, but
+different contents. Has to be seen to be believed:
+
+	hess$ ls pidlock
+	-r--r--r--  1 hess root    70 Nov 13 15:07 pidlock
+	-r--r--r--  1 hess root    70 Nov 13 15:07 pidlock
+	hess$ rm pidlock; ls pidlock
+	-r--r--r--  1 hess root    74 Nov 13 14:35 pidlock	
+
+git-annex's pid locking code now detects this and seems to work
+even on Lustre. Eep.
+
+I'm clutching my "NO WARRANTY" disclaimer pretty hard though, if anyone
+wants to use git-annex on Lustre. When POSIX is being violated this badly,
+it's hard to anticipate what other strangeness might result.
diff --git a/doc/devblog/day_338__week_in_review.mdwn b/doc/devblog/day_338__week_in_review.mdwn
new file mode 100644
index 0000000000..07b37e7abf
--- /dev/null
+++ b/doc/devblog/day_338__week_in_review.mdwn
@@ -0,0 +1,16 @@
+Monday: Some finishing touches on the pid locking support, and released
+5.20151116. After the release I noticed that concurrent downloads didn't
+always include a progress meter, and made the necessary changes to fix
+that.
+
+Wednesday: This was a day of minor bug fixing and responding to questions
+etc. Message backlog got down below 90, not bad.
+
+Thursday: I've been distracted from coding today with an idea of making
+some new stickers. Hexagonal this time, and even better, composable...
+So they can show git-annex getting as big as you want. ;)
+
+[[stickers/hex.svg]]
+
+The design is done, see [[stickers]], and seems to work well, and even
+better is easy to modify. May find time to get these printed at some point.
diff --git a/doc/devblog/day_339_smudging_out_direct_mode.mdwn b/doc/devblog/day_339_smudging_out_direct_mode.mdwn
new file mode 100644
index 0000000000..a4096c2b96
--- /dev/null
+++ b/doc/devblog/day_339_smudging_out_direct_mode.mdwn
@@ -0,0 +1,61 @@
+I'm considering ways to get rid of direct mode, replacing it with something
+better implemented using [[todo/smudge]] filters.
+
+## git-lfs
+
+I started by trying out git-lfs, to see what I can learn from it. My
+feeling is that git-lfs brings an admirable simplicity to using git with
+large files. For example, it uses a push-hook to automatically
+upload file contents before pushing a branch.
+
+But its simplicity comes at the cost of being centralized. You can't make a
+git-lfs repository locally and clone it onto other drive and have the local
+repositories interoperate to pass file contents around. Everything has to
+go back through a centralized server. I'm willing to pay complexity costs
+for decentralization.
+
+Its simplicity also means that the user doesn't have much control over what
+files are present in their checkout of a repository. git-lfs downloads
+all the files in the work tree. It doesn't have facilities for dropping
+files to free up space, or for configuring a repository to only want to get
+a subset of files in the first place. Some of this could be added to it 
+I suppose.
+
+I also noticed that git-lfs uses twice the disk space, at least when
+initially adding files. It keep a copy of the file in .git/lfs/objects/,
+in addition to the copy in the working tree. That copy seems to be
+necessary due to the way git smudge filters work, to avoid data loss. Of
+course, git-annex manages to avoid that duplication when using symlinks,
+and its direct mode also avoids that duplication (at the cost of some
+robustness). I'd like to keep git-annex's single local copy feature 
+if possible.
+
+## replacing direct mode
+
+Anyway, as smudge/clean filters stand now, they can't be used to set up
+git-annex symlinks; their interface doesn't allow it. But, I was able to
+think up a design that uses smudge/clean filters to cover the same use
+cases that direct mode covers now.
+
+Thanks to the clean filter, adding a file with `git add` would check in a
+small file that points to the git-annex object.
+
+In the same repository, you could also use `git annex add` to check
+in a git-annex symlink, which would protect the object from modification,
+in the good old indirect mode way. `git annex lock` and `git annex unlock` 
+could switch a file between those two modes.
+
+So this allows mixing directly writable annexed files and locked down
+annexed files in the same repository. All regular git commands and all
+git-annex commands can be used on both sorts of files. Workflows could
+develop where a file starts out unlocked, but once it's done, is locked to
+prevent accidental edits and archived away or published.
+
+That's much more flexible than the current direct mode, and I think it will
+be able to be implemented in a simpler, more scalable, and robust way too.
+I can lose the direct mode merge code, and remove hundreds of lines of
+other special cases for direct mode.
+
+The downside, perhaps, is that for a repository to be usable on a crippled
+filesystem, all the files in it will need to be unlocked. A file can't
+easily be unlocked in one checkout and locked in another checkout.
diff --git a/doc/devblog/day_339_smudging_out_direct_mode/comment_1_6435db0003d2d8414b1a040b8899c7b8._comment b/doc/devblog/day_339_smudging_out_direct_mode/comment_1_6435db0003d2d8414b1a040b8899c7b8._comment
new file mode 100644
index 0000000000..75d1c2db43
--- /dev/null
+++ b/doc/devblog/day_339_smudging_out_direct_mode/comment_1_6435db0003d2d8414b1a040b8899c7b8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="niiice"
+ date="2015-11-24T01:07:32Z"
+ content="""
+that would be pretty awesome! thanks so much for looking into what others are doing: it takes great maturity and respect for others, something that is so often missing online...
+
+i hope this can solve a bunch of WTF issues i've had with direct mode, which already improved by leaps and bounds, mind you. :)
+
+speaking of which - would it make sense for git-annex to support lfs remotes out of the box? or is considered builtin to git (ie. if you install git-lfs, you can already have a hybrid lfs/annex repo?)
+"""]]
diff --git a/doc/devblog/day_339_smudging_out_direct_mode/comment_2_79d19b2b057c2a0b23875a32dae0c2ba._comment b/doc/devblog/day_339_smudging_out_direct_mode/comment_2_79d19b2b057c2a0b23875a32dae0c2ba._comment
new file mode 100644
index 0000000000..ee6158fbfa
--- /dev/null
+++ b/doc/devblog/day_339_smudging_out_direct_mode/comment_2_79d19b2b057c2a0b23875a32dae0c2ba._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-11-24T14:22:37Z"
+ content="""
+Sure, it would be great to have a special remote supporting the git-lfs
+storage backend. This would let git-annex repos be uploaded to github along
+with the annexed files, which is a nice diversity to have in addition to
+gitlab's support for git-annex.
+
+The API is documented, so it's certianly doable, as an external special
+remote even.
+"""]]
diff --git a/doc/devblog/day_339_smudging_out_direct_mode/comment_3_43f7c7c6c2fd227466857c3232e13351._comment b/doc/devblog/day_339_smudging_out_direct_mode/comment_3_43f7c7c6c2fd227466857c3232e13351._comment
new file mode 100644
index 0000000000..226fdb2402
--- /dev/null
+++ b/doc/devblog/day_339_smudging_out_direct_mode/comment_3_43f7c7c6c2fd227466857c3232e13351._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 3"
+ date="2015-11-26T01:34:17Z"
+ content="""
+At present it's possible to check (small) files directly into a git branch alongside annexed files.  To do this one uses `git add` rather than `git annex add`.  But if `git add` would add files via the smudge/clean process, how would one check files directly into git?  Would it no longer be possible?
+"""]]
diff --git a/doc/devblog/day_339_smudging_out_direct_mode/comment_3_43f7c7c6c2fd227466857c3232e13351/comment_1_78e16167ca29eb3ed43706b39bf08603._comment b/doc/devblog/day_339_smudging_out_direct_mode/comment_3_43f7c7c6c2fd227466857c3232e13351/comment_1_78e16167ca29eb3ed43706b39bf08603._comment
new file mode 100644
index 0000000000..f114b48a2b
--- /dev/null
+++ b/doc/devblog/day_339_smudging_out_direct_mode/comment_3_43f7c7c6c2fd227466857c3232e13351/comment_1_78e16167ca29eb3ed43706b39bf08603._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-11-30T19:03:49Z"
+ content="""
+@spwhitton, you'd have to adjust annex.largefiles to not match the small
+files that you want to add to git.
+"""]]
diff --git a/doc/devblog/day_339_smudging_out_direct_mode/comment_4_35d0472cd64335eedeeb17d51cdbaf5b._comment b/doc/devblog/day_339_smudging_out_direct_mode/comment_4_35d0472cd64335eedeeb17d51cdbaf5b._comment
new file mode 100644
index 0000000000..6690bd93ba
--- /dev/null
+++ b/doc/devblog/day_339_smudging_out_direct_mode/comment_4_35d0472cd64335eedeeb17d51cdbaf5b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/27ceb3c5-0762-42b8-8f8a-ed21c284748f"
+ nickname="g"
+ subject="The downside"
+ date="2015-12-10T03:45:09Z"
+ content="""
+If I'm understanding correctly, that one downside (requiring all checkouts to have all files be direct if any filesystems require it) seems to be a fairly major limitation, no? Changing the concept of locked/unlocked files from being a local, per-repo concern to a global one seems like quite a major change.
+
+For instance, would mean that any public repo using git annex for distributing a set of data files would either have to have all files be unlocked, or else no one would be able clone onto a FAT32-formatted external hdd?
+
+
+FWIW, the particular use case I'm concerned about personally is having my annexes on my android device.
+"""]]
diff --git a/doc/devblog/day_339_smudging_out_direct_mode/comment_5_499f3553c4efc35e54f121a7d4abc029._comment b/doc/devblog/day_339_smudging_out_direct_mode/comment_5_499f3553c4efc35e54f121a7d4abc029._comment
new file mode 100644
index 0000000000..b4cbe978e2
--- /dev/null
+++ b/doc/devblog/day_339_smudging_out_direct_mode/comment_5_499f3553c4efc35e54f121a7d4abc029._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-12-10T15:00:52Z"
+ content="""
+I'm concerned about that too. But it may be possible to finesse it,
+when git-annex is running on a crippled filesystem, it may be able to
+unlock all files as it gets content for them, producing a local fork.
+
+The first difficulty would be avoiding or autoresolving conflicts
+between locked and unlocked when merging changes into that fork. I think
+this is very tractable; such a conflict comes down mostly to the symlink
+bit in the tree object.
+
+The real difficulty would be that any pushes from that fork would include
+its change converting all files to unlocked. Although it's fairly mechanical
+to convert such a commit into one that doesn't unlock files, so perhaps
+that could be automated somehow on push or merge.
+
+There's also a small and probably easy to implement git change that
+would avoid all this complexity: If git's smudge filters were optionally
+able to run on the link-text of symlinks, then a file could be unlocked
+locally without changing what's in the repo and all the smudge stuff
+would still work on it.
+
+Crippled filesystems aside, I think there's value in being able to unlock
+files across clones of a repo. For example, a repo could have a workflow
+where the files for the current episiode/experiment/whatever start out
+unlocked and are locked once it's complete.
+"""]]
diff --git a/doc/devblog/day_339_smudging_out_direct_mode/comment_6_ede48107675edfe40d5fdd3377553aa4._comment b/doc/devblog/day_339_smudging_out_direct_mode/comment_6_ede48107675edfe40d5fdd3377553aa4._comment
new file mode 100644
index 0000000000..d52b054e32
--- /dev/null
+++ b/doc/devblog/day_339_smudging_out_direct_mode/comment_6_ede48107675edfe40d5fdd3377553aa4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/27ceb3c5-0762-42b8-8f8a-ed21c284748f"
+ nickname="g"
+ subject="comment 6"
+ date="2015-12-11T22:58:22Z"
+ content="""
+Thanks for the quick reply (and all your work on this!)
+
+Interesting, that change to git does sound like it should be relatively small compared to the workarounds needed. But in any case, glad to hear you're thinking about the issue.
+
+Also curious what your thoughts are on the performance issues you had identified previously with using smudge/clean on larger repos. Do the changes in git 2.5 address all your concerns? Or are there still some cases where this will potentially result in significant slow-down?
+"""]]
diff --git a/doc/devblog/day_339_smudging_out_direct_mode/comment_7_ceb1d2a0e5bbc73590b80ff69292102d._comment b/doc/devblog/day_339_smudging_out_direct_mode/comment_7_ceb1d2a0e5bbc73590b80ff69292102d._comment
new file mode 100644
index 0000000000..7de202eac0
--- /dev/null
+++ b/doc/devblog/day_339_smudging_out_direct_mode/comment_7_ceb1d2a0e5bbc73590b80ff69292102d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2015-12-19T18:21:04Z"
+ content="""
+I'm still not entirely happy with the smudge/clean interface's performance.
+At least git doesn't fall over if the clean filter declines to read all the
+content of the large file on stdin anymore, which was the main thing
+preventing an optimised use of it. Still, git has to run the clean filter once
+per file, which is suboptimal. And, the smudge filter can't modify the file in
+the work tree, but instead has to pass the whole file content back to git
+for writing, which is going to result in a lot of unnecessary context
+switches and slowdown. Especially in git-annex's case, where all it really
+needs to do is make a hard link to the content.
+"""]]
diff --git a/doc/devblog/day_33__fsck_on_connect.mdwn b/doc/devblog/day_33__fsck_on_connect.mdwn
new file mode 100644
index 0000000000..36c2260083
--- /dev/null
+++ b/doc/devblog/day_33__fsck_on_connect.mdwn
@@ -0,0 +1,9 @@
+Built everything needed to run a fsck when a remote gets connected. Have
+not tested it; only testing is blocking merging the incrementalfsck branch
+now.
+
+Also updated the OSX and Android builds to use a new gpg release (denial of
+service security fix), and updated the Debian backport, and did a small
+amount of bug fixing. I need to do several more days of bug fixing once 
+I get this incremental fsck feature wrapped up before moving on to recovery
+of corrupt git repositories.
diff --git a/doc/devblog/day_340__post_turkey_catchup.mdwn b/doc/devblog/day_340__post_turkey_catchup.mdwn
new file mode 100644
index 0000000000..c7e22f66d5
--- /dev/null
+++ b/doc/devblog/day_340__post_turkey_catchup.mdwn
@@ -0,0 +1,9 @@
+Spent a couple of days catching up on backlog, and my backlog is down to 80
+messages now. Lowest in recent memory.
+
+Made the annex.largefiles config be honored by `git annex import`, `git
+annex addurl`, and even `git annex importfeed`.
+
+Planning to dive into smudge filters soon. The design seems ready to go,
+although there is some complication in needing to keep track of mappings
+between worktree files and annex keys.
diff --git a/doc/devblog/day_341__starting_smudge.mdwn b/doc/devblog/day_341__starting_smudge.mdwn
new file mode 100644
index 0000000000..d212ca78af
--- /dev/null
+++ b/doc/devblog/day_341__starting_smudge.mdwn
@@ -0,0 +1,24 @@
+I've gotten git-annex working as a smudge/clean filter today in the
+`smudge` branch. It works ok in a local git repository. `git add` lets
+git-annex decide if it wants to annex a file's content, and checking out
+branches and other git commands involving those files works pretty well.
+
+It can sometimes be slow; git's smudge interface necessarily needs to
+copy the content of files around, particularly when checking out files,
+and so it's never going to be as fast as the good old git-annex symlink
+approach. Most of the slow parts are things that can't be done in direct
+mode repos though, like switching branches, so that isn't a regression.
+
+No git-annex commands to manage the annexed content work yet. That
+will need a key to worktree file mapping to be maintained, and implementing
+that mapping and ensuring its always consistent is probably going to be
+the harder part of this.
+
+Also there's the question of how to handle upgrades from direct mode
+repositories. This will be an upgrade from annex.version 5 to 6, and you
+won't want to do it until all computers that have clones of a repository
+have upgraded to git-annex 6.x, since older versions won't be able to work
+with the upgraded repository. So, the repository upgrade will need to be
+run manually initially, and it seems I'll need to keep supporting direct
+mode for v5 repos in a transition period, which will probably be measured
+in years.
diff --git a/doc/devblog/day_342__continuing_smudge.mdwn b/doc/devblog/day_342__continuing_smudge.mdwn
new file mode 100644
index 0000000000..8d66735ad9
--- /dev/null
+++ b/doc/devblog/day_342__continuing_smudge.mdwn
@@ -0,0 +1,30 @@
+Made a lot of progress today. Implemented the database mapping a key to its
+associated files.  As expected this database, when updated by the
+smudge/clean filters, is not always consistent with the current git work tree.
+In particular, commands like `git mv` don't update the database with the
+new filename. So queries of the database will need to do some additional
+work first to get it updated with any staged changes. But the database is
+good enough for a proof of concept, I hope.
+
+Then I got git-annex commands treating smudged files as annexed files.
+So this works:
+
+	joey@darkstar:~/tmp/new>git annex init
+	init  ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/new>cp ~/some.mp3 .
+	joey@darkstar:~/tmp/new>git add some.mp3
+	joey@darkstar:~/tmp/new>git diff --cached
+	diff --git a/some.mp3 b/some.mp3
+	new file mode 100644
+	index 0000000..2df8868
+	--- /dev/null
+	+++ b/some.mp3
+	@@ -0,0 +1 @@
+	+/annex/objects/SHA256E-s191213--e4b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.mp3
+	joey@darkstar:~/tmp/new>git annex whereis some.mp3
+	whereis some.mp3 (1 copy) 
+	  	7de17427-329a-46ec-afd0-0a088f0d0b1b -- joey@darkstar:~/tmp/new [here]
+	ok
+
+get/drop don't yet update the smudged files, and that's the next step.
diff --git a/doc/devblog/day_343__get_and_drop_for_smudge.mdwn b/doc/devblog/day_343__get_and_drop_for_smudge.mdwn
new file mode 100644
index 0000000000..50046ac08f
--- /dev/null
+++ b/doc/devblog/day_343__get_and_drop_for_smudge.mdwn
@@ -0,0 +1,26 @@
+Well, another day working on smudge filters, or unlocked files as the
+feature will be known when it's ready. Got both `git annex get` and `git
+annex drop` working for these files today.
+
+Get was the easy part; it just has to hard link or copy the object to the
+work tree file(s) that point to it.
+
+Handling dropping was hard. If the user drops a file, but it's unlocked and
+modified, it shouldn't reset it to the pointer file. For this, I reused the
+InodeCache stuff that was built for direct mode. So the sqlite database
+tracks the InodeCaches of unlocked files, and when a key is dropped it can
+check if the file is modified.
+
+But that's not a complete solution, because when git uses a clean filter,
+it will write the file itself, and git-annex won't have an InodeCache for
+it. To handle this case, git-annex will fall back to verifying the content
+of the file when dropping it if its InodeCache isn't known.
+Bit of a shame to need an expensive checksum to drop an unlocked file;
+maybe the git clean filter interface will eventually be improved to let
+git-annex use it more efficiently.
+
+Anyway, smudged aka unlocked files are working now well enough to be a
+proof of concept. I have several missing safety checks that need to be
+added to get the implementation to be really correct, and quite a lot
+of polishing still to do, including making `unlock`, `lock`, `fsck`,
+and `merge` handle them, and finishing repository upgrade code.
diff --git a/doc/devblog/day_344-345__smudging_along.mdwn b/doc/devblog/day_344-345__smudging_along.mdwn
new file mode 100644
index 0000000000..7b7e6f0421
--- /dev/null
+++ b/doc/devblog/day_344-345__smudging_along.mdwn
@@ -0,0 +1,7 @@
+New special remote alert! Chris Kastorff has made
+[a special remote supporting Backblaze's B2 storage servie](https://github.com/encryptio/git-annex-remote-b2).
+
+And I'm still working on v6 unlocked files. After beating on it for 2 more
+days, all git-annex commands should support them. There is still plenty
+of work to do on testing, upgrading, optimisation, merge conflict resolution,
+and reconciling staged changes.
diff --git a/doc/devblog/day_346-347__nearly_ready_to_merge.mdwn b/doc/devblog/day_346-347__nearly_ready_to_merge.mdwn
new file mode 100644
index 0000000000..944e148c50
--- /dev/null
+++ b/doc/devblog/day_346-347__nearly_ready_to_merge.mdwn
@@ -0,0 +1,19 @@
+Two more days working on v6 and the `smudge` branch is almost ready to be
+merged. The test suite is passing again for v5 repos, and is almost
+passing for v6 repos. Also I decided to make `git annex init` create v5
+repos for now, so `git annex init --version=6` or a `git annex upgrade`
+is needed to get a v6 repo. So while I still have plenty of todo items for
+v6 repos, they are working reasonably well and almost ready for early
+adopters.
+
+The only real blocker to merging it is that the database stuff used by v6
+is not optimised yet and probably slow, and even in v5 repos it will query
+the database. I hope to find an optimisation that avoids all database
+overhead unless unlocked files are used in a v6 repo.
+
+I'll probably make one more release before that is merged though. Yesterday
+I fixed a small security hole in `git annex repair`, which could expose the
+contents of an otherwise not world-writable repository to local users.
+
+BTW, the [2015 git-annex user survey](http://git-annex-survey.branchable.com/polls/2015/)
+closes in two weeks, please go fill it out if you haven't yet done so!
diff --git a/doc/devblog/day_348__v6_assistant.mdwn b/doc/devblog/day_348__v6_assistant.mdwn
new file mode 100644
index 0000000000..08659e8e2d
--- /dev/null
+++ b/doc/devblog/day_348__v6_assistant.mdwn
@@ -0,0 +1,8 @@
+Today was mostly spent making the assistant support v6 repositories.
+That was harder than expected, because I have not touched this part of the
+assistant's code much in a long time, and there are lots of tricky races
+and edge cases to deal with.
+
+The smudge branch has a 4500 diff from master now. Not counting
+documentation changes (Another 500 lines.) The todo list for it is
+shrinking slowly now. May not get it done before the new year.
diff --git a/doc/devblog/day_349__v6_database_optimisation.mdwn b/doc/devblog/day_349__v6_database_optimisation.mdwn
new file mode 100644
index 0000000000..bf18614171
--- /dev/null
+++ b/doc/devblog/day_349__v6_database_optimisation.mdwn
@@ -0,0 +1,7 @@
+Got unexpectedly far today on optimising the database that v6 repositories
+use to keep track of unlocked files. The database schema may still need
+optimization, but everything else to do with the database is optimised.
+Writes to the database are queued together. And reads to the database
+avoid creating the database if it doesn't exist yet. Which means v5
+repos, and v6 repos with no unlocked files will avoid any database
+overhead.
diff --git a/doc/devblog/day_34__wrapping_up_fsck.mdwn b/doc/devblog/day_34__wrapping_up_fsck.mdwn
new file mode 100644
index 0000000000..b667086054
--- /dev/null
+++ b/doc/devblog/day_34__wrapping_up_fsck.mdwn
@@ -0,0 +1,7 @@
+Fixed a lot of bugs in the assistant's fsck handling today, and merged
+it into master. There are some enhancments that could be added to it, 
+including fscking ssh remotes via git-annex-shell and adding the ability to
+schedule events to run every 30 days instead of on a specific day of the
+month. But enough on this feature for now.
+
+Today's work was sponsored by Daniel Brockman.
diff --git a/doc/devblog/day_350-351__it_landed_on_xmas_eve.mdwn b/doc/devblog/day_350-351__it_landed_on_xmas_eve.mdwn
new file mode 100644
index 0000000000..12b9c55758
--- /dev/null
+++ b/doc/devblog/day_350-351__it_landed_on_xmas_eve.mdwn
@@ -0,0 +1,9 @@
+If you've got some free holiday time, the v6 repository mode is now
+available in many of the daily builds, and there's documentation at
+[[tips/unlocked_files]]. It would be very useful now if you can give
+it a try. Use a clone or new repository for safety.
+
+Yesterday I checked all parts of the code that special case direct mode,
+and found a few things that needed adjusting for v6 unlocked files. Today,
+I added the annex.thin config. Around 4 other major todo items need to be
+dealt with before this is ready for more than early adopters.
diff --git a/doc/devblog/day_352__had_to_be_done.mdwn b/doc/devblog/day_352__had_to_be_done.mdwn
new file mode 100644
index 0000000000..181fbd7e79
--- /dev/null
+++ b/doc/devblog/day_352__had_to_be_done.mdwn
@@ -0,0 +1,3 @@
+Automatic merge conflict resolver updated to work with unlocked files in v6
+repos. Fairly tricky and painful; thank goodness the test suite tests a lot
+of edge cases in that code. 
diff --git a/doc/devblog/day_353__one_step_forward_and_N_steps_back.mdwn b/doc/devblog/day_353__one_step_forward_and_N_steps_back.mdwn
new file mode 100644
index 0000000000..0e8bf8f794
--- /dev/null
+++ b/doc/devblog/day_353__one_step_forward_and_N_steps_back.mdwn
@@ -0,0 +1,5 @@
+Got the test suite passing 100%, but then added a pass that uses v6
+unlocked files and 30-some more failures appeared. Fixed a couple of the
+bugs today. After sprinting unexpectedly hard all December on v6, I need a
+change of pace, so I started digging into the website message backlog
+and fixed some bugs and posted some comments there.
diff --git a/doc/devblog/day_354-355__beating_on_the_test_suite.mdwn b/doc/devblog/day_354-355__beating_on_the_test_suite.mdwn
new file mode 100644
index 0000000000..2eacb2acb9
--- /dev/null
+++ b/doc/devblog/day_354-355__beating_on_the_test_suite.mdwn
@@ -0,0 +1,8 @@
+Been working hard on the last several test suite failures for v6 unlocked
+files. Now I've solved almost all of them, which is a big improvement to
+my confidence in its (almost) correctness.
+
+Frustratingly, the test suite is still not green after all this work.
+There's some kind of intermittent failure related to the sqlite database.
+Only seems to happen when the test suite is running, and the error
+message is simply "Error" which is making it hard to track down..
diff --git a/doc/devblog/day_356__benchmarking.mdwn b/doc/devblog/day_356__benchmarking.mdwn
new file mode 100644
index 0000000000..05fbce7a5a
--- /dev/null
+++ b/doc/devblog/day_356__benchmarking.mdwn
@@ -0,0 +1,11 @@
+Added `git annex benchmark` which uses the excellent Criterion to benchmark
+parts of git-annex. What I'm interested in benchmarking right now is the
+sqlite database that is used to manage v6 unlocked files, but having a
+built-in benchmark will probably have other uses later.
+
+The benchmark results were pretty good; queries from the database are
+quite fast (60 microseconds warm cache) and scale well as the size increases.
+I did find one scalability issue, which was fixed by adding another index
+to the database. The kind of schema change that it's easy to make now, but
+that would be a painful transition if it had to be done once this was in wide
+use.
diff --git a/doc/devblog/day_357__post_release_catchup.mdwn b/doc/devblog/day_357__post_release_catchup.mdwn
new file mode 100644
index 0000000000..7d997edb8a
--- /dev/null
+++ b/doc/devblog/day_357__post_release_catchup.mdwn
@@ -0,0 +1,8 @@
+After finally releasing git-annex 6 yesterday, I did some catching up
+today, and got the message backlog back down from 120 to 100.
+
+By the way, the first OSX release of git-annex 6 was broken; I had to fix
+an issue on the builder and update the build. If you upgraded at the wrong
+time, you might find that git-annex doesn't run; if so reinstall it.
+I now have an account on a separate OSX machine from the build machine,
+that automatically tests the daily build, to detect such problems.
diff --git a/doc/devblog/day_357__post_release_catchup/comment_1_6963d1c6be69e531726f62f02d50855c._comment b/doc/devblog/day_357__post_release_catchup/comment_1_6963d1c6be69e531726f62f02d50855c._comment
new file mode 100644
index 0000000000..ed91175824
--- /dev/null
+++ b/doc/devblog/day_357__post_release_catchup/comment_1_6963d1c6be69e531726f62f02d50855c._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 1"
+ date="2016-01-16T05:14:40Z"
+ content="""
+Congratulations!
+"""]]
diff --git a/doc/devblog/day_358__bugfix_release.mdwn b/doc/devblog/day_358__bugfix_release.mdwn
new file mode 100644
index 0000000000..fb2b066532
--- /dev/null
+++ b/doc/devblog/day_358__bugfix_release.mdwn
@@ -0,0 +1,9 @@
+Bugfix release of git-annex today. The release earlier this month had a bug
+that caused `git annex sync --content` to drop files that should be
+preferred content. So I had to rush out a fix after that [bug was reported](http://git-annex.branchable.com/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__/).
+(Some of the builds for the new release are still updating as I post this.)
+
+In the past week I've been dealing with a blizzard. Snowed in for 6 days
+and counting. That has slightly back-burnered working on git-annex, and
+I've mostly been making enhancements that the DataLad project needs, along
+the lines of more commands supporting --batch and better --json output. 
diff --git a/doc/devblog/day_358__bugfix_release/comment_1_a9aa122010e576c572ca719638ecf2e6._comment b/doc/devblog/day_358__bugfix_release/comment_1_a9aa122010e576c572ca719638ecf2e6._comment
new file mode 100644
index 0000000000..b55f0b073b
--- /dev/null
+++ b/doc/devblog/day_358__bugfix_release/comment_1_a9aa122010e576c572ca719638ecf2e6._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2016-02-01T12:43:47Z"
+ content="""
+--batch and --with-files on addurl is amazing! I migrated one of my scripts last night, that used to use 'parallel' and disabling autocommit, and it simplified the workflow a *lot*.
+"""]]
diff --git a/doc/devblog/day_359__annex.largefiles_gitattributes.mdwn b/doc/devblog/day_359__annex.largefiles_gitattributes.mdwn
new file mode 100644
index 0000000000..7cd5013f28
--- /dev/null
+++ b/doc/devblog/day_359__annex.largefiles_gitattributes.mdwn
@@ -0,0 +1,18 @@
+For use cases that mix annexed files with files stored in git, the
+annex.largefiles config is more important in v6 repositories than before,
+since it configures the behavior of `git add` and even `git commit -a`. To
+make it possible to set annex.largefiles so it'll stick across clones of
+a repository, I have now made it be supported in `.gitattributes` files
+as well as git config.
+
+Setting it in .gitattributes looks a little bit different, since
+the regular .gitattributes syntax can be used to match on the filename.
+
+	* annex.largefiles=(largerthan=100kb)
+	*.c annex.largefiles=nothing
+
+It seems there's no way to make a git attribute value contain whitespace.
+So, more complicated annex.largefiles expressions need to use parens to
+break up the words.
+
+	* annex.largefiles=(largerthan=100kb)and(not(include=*.c))
diff --git a/doc/devblog/day_359__annex.largefiles_gitattributes/comment_1_ac73ad4147629c25cd51d13cfea206cf._comment b/doc/devblog/day_359__annex.largefiles_gitattributes/comment_1_ac73ad4147629c25cd51d13cfea206cf._comment
new file mode 100644
index 0000000000..d1732a4270
--- /dev/null
+++ b/doc/devblog/day_359__annex.largefiles_gitattributes/comment_1_ac73ad4147629c25cd51d13cfea206cf._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="all those parenthesis..."
+ date="2016-02-02T22:56:51Z"
+ content="""
+... is that lisp showing through your haskell sir? :)
+
+jokes aside, it's cool that you can actually do that, i didn't know! is the \"non-space expression\" new too?
+"""]]
diff --git a/doc/devblog/day_359__annex.largefiles_gitattributes/comment_2_cfbf4fb5a3a1beb582faa051d1627a31._comment b/doc/devblog/day_359__annex.largefiles_gitattributes/comment_2_cfbf4fb5a3a1beb582faa051d1627a31._comment
new file mode 100644
index 0000000000..b3633c209c
--- /dev/null
+++ b/doc/devblog/day_359__annex.largefiles_gitattributes/comment_2_cfbf4fb5a3a1beb582faa051d1627a31._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-02-03T21:00:55Z"
+ content="""
+Weirdly, that hack wouldn't work if I had used a more lisp-style format for
+the expressions. At least, I don't think lisp can be written with no
+whitespace at all, in general. It was just luck that the expression format
+happened to work out that way.
+
+Anyway, it's a hack, but it works. Would be nice if git got a way to put
+spaces in gitattribute values..
+"""]]
diff --git a/doc/devblog/day_35__anacron_and_bugfixing.mdwn b/doc/devblog/day_35__anacron_and_bugfixing.mdwn
new file mode 100644
index 0000000000..dc8fbb6284
--- /dev/null
+++ b/doc/devblog/day_35__anacron_and_bugfixing.mdwn
@@ -0,0 +1,15 @@
+While I said I was done with fsck scheduling yesterday, I ended up adding
+one more feature to it today: Full anacron style scheduling. So a fsck can
+be scheduled to run once per week, or month, or year, and it'll run the
+fsck the next time it's available after that much time has passed. The nice
+thing about this is I didn't have to change Cronner *at all* to add this,
+just improved the Recurrence data type and the code that calculates when
+to run events.
+
+Rest of the day I've been catching up on some bug reports. The main bug I
+fixed caused git-annex on Android to hang when adding files. This turns out
+to be because it's using a new (unreleased) version of git, and
+`git check-attr -z` output format has changed in an incompatible way.
+
+I am currently 70 messages behind, which includes some ugly looking bug
+reports, so I will probably continue with this over the next couple days.
diff --git a/doc/devblog/day_360__annex.largefiles_mimetype.mdwn b/doc/devblog/day_360__annex.largefiles_mimetype.mdwn
new file mode 100644
index 0000000000..587dcdac35
--- /dev/null
+++ b/doc/devblog/day_360__annex.largefiles_mimetype.mdwn
@@ -0,0 +1,8 @@
+The same parser was used for both preferred content expressions and
+annex.largefiles. Reworked that today, splitting it into two distinct
+parsers. It doesn't make any sense to use terms like "standard" or
+"lackingcopies" in annex.largefiles, and such are now rejected.
+
+That groundwork also let me add a feature that only makes sense for
+annex.largefiles, and not for preferred content expressions: Matching by
+mime type, such as `mimetype=text/*`
diff --git a/doc/devblog/day_360__annex.largefiles_mimetype/comment_2_78a22b96a82f76ab7217d37918a19024._comment b/doc/devblog/day_360__annex.largefiles_mimetype/comment_2_78a22b96a82f76ab7217d37918a19024._comment
new file mode 100644
index 0000000000..3e6f070a55
--- /dev/null
+++ b/doc/devblog/day_360__annex.largefiles_mimetype/comment_2_78a22b96a82f76ab7217d37918a19024._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-02-19T15:53:46Z"
+ content="""
+Don't know, unless your system somehow has the magic C library installed
+but no magic database file installed. You should file a bug report with
+details about your system and how you installed the magic C library.
+"""]]
diff --git a/doc/devblog/day_360__annex.largefiles_mimetype/comment_3_3145e5843e20a037351e5a14fa3d6e9a._comment b/doc/devblog/day_360__annex.largefiles_mimetype/comment_3_3145e5843e20a037351e5a14fa3d6e9a._comment
new file mode 100644
index 0000000000..659f02f94f
--- /dev/null
+++ b/doc/devblog/day_360__annex.largefiles_mimetype/comment_3_3145e5843e20a037351e5a14fa3d6e9a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="davho"
+ subject="Why would it fail?"
+ date="2016-02-19T15:49:00Z"
+ content="""
+Yeah! I've waited for this option for a half a year :-)  Thumbs up for finally including it!
+
+Doesn't work out of the box, though; I do have the MagicMime build flag but it fails to add files now!
+
+I get this error message for every file I try to add:
+
+    /etc/magic, 0: Warning: using regular magic file `/usr/share/misc/magic'
+    
+    git-annex: user error (magicLoadDefault: could not find any valid magic files!)
+    failed
+
+"""]]
diff --git a/doc/devblog/day_360__annex.largefiles_mimetype/comment_3_bf44404de52b00ff4e4f1effd4cef336._comment b/doc/devblog/day_360__annex.largefiles_mimetype/comment_3_bf44404de52b00ff4e4f1effd4cef336._comment
new file mode 100644
index 0000000000..e7f4f40549
--- /dev/null
+++ b/doc/devblog/day_360__annex.largefiles_mimetype/comment_3_bf44404de52b00ff4e4f1effd4cef336._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/27ceb3c5-0762-42b8-8f8a-ed21c284748f"
+ nickname="g"
+ subject="why not mimetypes for preferred content?"
+ date="2016-03-28T08:32:45Z"
+ content="""
+Why does matching by mimetype only make sense for annex.largefiles, but not for preferred content expressions? Sorry if this is a stupid question, but it seems it would in fact be quite useful to easily express that, for example, a certain repo have a preference for my photos and not my music files (though both should be considered large files)
+"""]]
diff --git a/doc/devblog/day_360__annex.largefiles_mimetype/comment_4_70c337d91f8d0458927c111763041118._comment b/doc/devblog/day_360__annex.largefiles_mimetype/comment_4_70c337d91f8d0458927c111763041118._comment
new file mode 100644
index 0000000000..51bff84886
--- /dev/null
+++ b/doc/devblog/day_360__annex.largefiles_mimetype/comment_4_70c337d91f8d0458927c111763041118._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-03-28T13:22:35Z"
+ content="""
+For the simple reason that git-annex doesn't know the mime type of a file
+before it downloads a copy.
+
+There are some more complicated reasons involving preferred content
+expressions needing to evaluate the same way in different repos, which
+can be on different computers with different versions of the magic
+database, etc.
+"""]]
diff --git a/doc/devblog/day_360__results_of_2015_user_survey.mdwn b/doc/devblog/day_360__results_of_2015_user_survey.mdwn
new file mode 100644
index 0000000000..c515981b65
--- /dev/null
+++ b/doc/devblog/day_360__results_of_2015_user_survey.mdwn
@@ -0,0 +1,56 @@
+The [2015 git-annex user servey](http://git-annex-survey.branchable.com/polls/2015/)
+is over with, and I'm reading through it and comparing with the
+[2013 survey](http://git-annex-survey.branchable.com/polls/2013/).
+
+37% fewer users responded to the 2015 survey than in 2013.
+It's hard to tell if this has anything to do with the total number of
+git-annex users; Debian's popcon suggests the number of users has doubled
+since 2013, although its graph also suggests the number of users has
+flattened off since 2014. The difference may just be that I 
+promoted the 2013 survey better than the 2015 survey, perhaps reaching
+kickstarter backers who I was in touch with back then.
+
+25% use the assistant. Of those, 20% use XMPP, which is good to know as I'd
+like to get rid of it.
+
+Android use has quardrupled, and Windows use has doubled; both are now at
+4%. It's not surprising that Android and Windows users still think more
+porting work is needed for those OSes. iOS is the only unsupported OS that
+more than 1% of users want. Embedded and NAS systems were mentioned much
+less than in 2013; probably the
+[[arm_tarball_build|forum/new_linux_arm_tarball_build]] met many such
+needs.
+
+About the same percentage of users prefer direct mode in 2015 as did in 2013,
+and ditto for indirect mode. But, more users in 2015 only use direct mode
+on platforms that force its use. Correlating with the OS percentages
+suggests that many of these users are using removable media with the
+FAT filesystem, rather than an OS like Windows or Android. Hopefully
+v6 unlocked files will eventually better meet those user's needs.
+
+The percent of users installing git-annex from source has halved since 2013,
+and it seems that builds from this website have taken up most of that slack;
+I would have expected more installs from Debian, Homebrew etc, but that
+seems not to have increased.
+
+The number of repositories per user has gone up quite a lot since 2013,
+when only 7% of users had more than 10 repos. Now, 23% of users do. And,
+2% of users have more than 100 repos! This probably involves both more
+repositories for different purposes, and cloning of repositories
+to more devices.
+
+Similarly, the amount of data stored has gone up. 34% have more than 1
+terabyte stored, up from 18% in 2013. 2% have more than 16 terabytes.
+
+There's some indications of more users sharing repositories or
+otherwise using it in teams of larger groups, although most users still use
+it by themselves.
+
+Users seem happier with git-annex now than in 2013. 16% call it "one of my
+favorite applications of all time". And, significantly fewer find it too
+hard to use than in 2013.
+
+The main blocking problems are documentation, performance with many
+files (a general git problem), and various issues with the assistant.
+Respondants suggest more focus on making it easier for nontechnical users,
+and for use in larger groups/organizations.
diff --git a/doc/devblog/day_360__results_of_2015_user_survey/comment_1_5f30c583cd20c33e2bcd386f674d6f3b._comment b/doc/devblog/day_360__results_of_2015_user_survey/comment_1_5f30c583cd20c33e2bcd386f674d6f3b._comment
new file mode 100644
index 0000000000..4c53ea41bb
--- /dev/null
+++ b/doc/devblog/day_360__results_of_2015_user_survey/comment_1_5f30c583cd20c33e2bcd386f674d6f3b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 1"
+ date="2016-02-05T23:06:11Z"
+ content="""
+thanks for the review! great to see those surveys every once in a while...
+
+i wonder if [[todo/build_a_user_guide/]] could help with the documentation. the [[todo]] and [[forum]] pages are useful, but they are more \"search\" based than a handbook would be. there is the [[walkthrough]], but it could cover a *lot* more ground and i am not sure the wiki format is appropriate for this...
+"""]]
diff --git a/doc/devblog/day_360__results_of_2015_user_survey/comment_2_68479af6dda2f732436b19160297aacd._comment b/doc/devblog/day_360__results_of_2015_user_survey/comment_2_68479af6dda2f732436b19160297aacd._comment
new file mode 100644
index 0000000000..501e7b455d
--- /dev/null
+++ b/doc/devblog/day_360__results_of_2015_user_survey/comment_2_68479af6dda2f732436b19160297aacd._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2016-02-08T13:08:30Z"
+ content="""
+I already have a cookbook of sorts (written in POD), but it is notes based on my usage. I'd be happy to expand this if I can get some feedback from newer/Windows users, as my usage is unusual and focused (e.g. no direct mode, limited assistant).
+"""]]
diff --git a/doc/devblog/day_360__results_of_2015_user_survey/comment_3_e38568c6baa30f58c5a7735b2f7985ed._comment b/doc/devblog/day_360__results_of_2015_user_survey/comment_3_e38568c6baa30f58c5a7735b2f7985ed._comment
new file mode 100644
index 0000000000..e43930cc61
--- /dev/null
+++ b/doc/devblog/day_360__results_of_2015_user_survey/comment_3_e38568c6baa30f58c5a7735b2f7985ed._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="publish!"
+ date="2016-02-08T19:12:30Z"
+ content="""
+well, publish those notes somewhere! it's always good to share!
+"""]]
diff --git a/doc/devblog/day_360__results_of_2015_user_survey/comment_4_e0bfb67454df205f2c9c566933e7f121._comment b/doc/devblog/day_360__results_of_2015_user_survey/comment_4_e0bfb67454df205f2c9c566933e7f121._comment
new file mode 100644
index 0000000000..ee565ac2d9
--- /dev/null
+++ b/doc/devblog/day_360__results_of_2015_user_survey/comment_4_e0bfb67454df205f2c9c566933e7f121._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 4"
+ date="2016-02-10T12:49:18Z"
+ content="""
+Okay, I'll need to go through it first and remove all the snide comments to myself though :P
+
+I'll throw up a HTML version up in a temporary place, if Joey approves, I'll ask if there is a namespace on CPAN that I can use as a more permanent home (or Joey can do it if he'd prefer control over it, I don't mind).
+"""]]
diff --git a/doc/devblog/day_361__adjusted_branches_design.mdwn b/doc/devblog/day_361__adjusted_branches_design.mdwn
new file mode 100644
index 0000000000..a51bf7885d
--- /dev/null
+++ b/doc/devblog/day_361__adjusted_branches_design.mdwn
@@ -0,0 +1,5 @@
+Working on a design for [[design/adjusted_branches]]. I've been kicking
+this idea around for a while to replace direct mode on crippled filesystems
+with v6 unlocked files. And the same thing would allow for hiding not
+present files. It's somewhat complicated, but the design I have seems like
+it would work.
diff --git a/doc/devblog/day_362__encoding_fun.mdwn b/doc/devblog/day_362__encoding_fun.mdwn
new file mode 100644
index 0000000000..392c5745a0
--- /dev/null
+++ b/doc/devblog/day_362__encoding_fun.mdwn
@@ -0,0 +1,19 @@
+This was one of those days where I somehow end up dealing with tricky
+filename encoding problems all day.
+
+First, worked around inability for concurrent-output to display unicode
+characters when in a non-unicode locale. The normal trick that git-annex
+uses doesn't work in this case. Since it only affected -J, I decided to
+make git-annex detect the problem and make -J behave as if it was not built
+with the concurrent-output feature. So, it just doesn't display concurrent
+output, which is better than crashing with an encoding error.
+
+The other problem affects v6 repos only. Seems that not all Strings will
+round trip through a persistent sqlite database. In particular, unicode
+surrogate characters are replaced with garbage. This is really [a bug in
+persistent](https://github.com/yesodweb/persistent/issues/540).
+But, for git-annex's purposes, it was possible to work around it,
+by detecting such Strings and serializing them differently.
+
+Then I had to enhance `git annex fsck` to fix up repositories that were
+affected by that problem.
diff --git a/doc/devblog/day_363__snow_day.mdwn b/doc/devblog/day_363__snow_day.mdwn
new file mode 100644
index 0000000000..4744816dac
--- /dev/null
+++ b/doc/devblog/day_363__snow_day.mdwn
@@ -0,0 +1,11 @@
+Made a `no-cbits` branch that removes several things that use C code and
+the FFI. I moved one of them out to a new haskell library,
+<http://hackage.haskell.org/package/mountpoints>. Others were replaced with
+other existing libraries. This will simplify git-annex's build process, and
+more library use is good. Planning to merge this branch in a week or two.
+
+v6 unlocked files don't work on Windows. I had assumed that since the build
+was succeeding, the test suite was passing there. But, it turns out the
+test suite was failing and somehow not failing the build. Have now fixed
+several problems with v6 on Windows. Still a couple test suite problems to
+address.
diff --git a/doc/devblog/day_364__more_v6_unlocked.mdwn b/doc/devblog/day_364__more_v6_unlocked.mdwn
new file mode 100644
index 0000000000..38b053136a
--- /dev/null
+++ b/doc/devblog/day_364__more_v6_unlocked.mdwn
@@ -0,0 +1,8 @@
+In a v6 repository on a filesystem not supporting symlinks,
+it makes sense for commands like `git annex add` and `git annex import`
+to add the files unlocked, since locked files are not usable there.
+After implementing that, I also added an `annex.addunlocked` config setting,
+so that the same behavior can be configured in other repositories.
+
+Rest of the day was spent fixing up the test suite's v6 repository tests
+to work on FAT and Windows.
diff --git a/doc/devblog/day_365__some_kind_of_milestone.mdwn b/doc/devblog/day_365__some_kind_of_milestone.mdwn
new file mode 100644
index 0000000000..fdbd4f610d
--- /dev/null
+++ b/doc/devblog/day_365__some_kind_of_milestone.mdwn
@@ -0,0 +1,6 @@
+Should mention that there was a release two days ago. The main reason for
+the timing of that release is because the Linux wstandalone builds include
+glibc, which recently had a nasty security hole and had to be updated.
+
+Today, fixed a memory leak, and worked on getting caught up with backlog,
+which now stands at 112 messages.
diff --git a/doc/devblog/day_366__starting_adjusted_branches.mdwn b/doc/devblog/day_366__starting_adjusted_branches.mdwn
new file mode 100644
index 0000000000..3f50d76bf9
--- /dev/null
+++ b/doc/devblog/day_366__starting_adjusted_branches.mdwn
@@ -0,0 +1,33 @@
+Getting started on [[design/adjusted_branches]], taking a top-down and
+bottom-up approach. Yesterday I worked on improving the design. Today,
+built a `git mktree` interface that supports recursive tree generation and
+filtering, which is the low-level core of what's needed to implement the
+adjusted branches.
+
+To test that, wrote a fun program that generates a git tree with all
+the filenames reversed.
+
+[[!format haskell """
+import Git.Tree
+import Git.CurrentRepo
+import Git.FilePath
+import Git.Types
+import System.FilePath
+
+main = do
+        r <- Git.CurrentRepo.get
+        (Tree t, cleanup) <- getTree (Ref "HEAD") r
+        print =<< recordTree r (Tree (map reverseTree t))
+        cleanup
+
+reverseTree :: TreeContent -> TreeContent
+reverseTree (TreeBlob f m s) = TreeBlob (reverseFile f) m s
+reverseTree (RecordedSubTree f s l) = NewSubTree (reverseFile f) (map reverseTree l)
+
+reverseFile :: TopFilePath -> TopFilePath
+reverseFile = asTopFilePath . joinPath . map reverse . splitPath . getTopFilePath
+"""]]
+
+Also, fixed problems with the Android, Windows, and OSX builds today.
+Made a point release of the OSX dmg, because the last several releases
+of it will SIGILL on some hardware.
diff --git a/doc/devblog/day_367__adjusted_branches_proof_of_concept.mdwn b/doc/devblog/day_367__adjusted_branches_proof_of_concept.mdwn
new file mode 100644
index 0000000000..80576005a9
--- /dev/null
+++ b/doc/devblog/day_367__adjusted_branches_proof_of_concept.mdwn
@@ -0,0 +1,18 @@
+Now I have a proof of concept [[design/adjusted_branches]]
+implementation, that creates a branch where all locked files
+are adjusted to be unlocked. It works!
+
+Building the adjusted branch is pretty fast; around 2 thousand files
+per second. And, I have a trick in my back pocket that could double that
+speed. It's important this be quite fast, because it'll be done often.
+
+Checking out the adjusted branch can be bit slow though, since git runs
+`git annex smudge` once per unlocked file. So that might need to be
+optimised somehow. On the other hand, this should be done only rarely.
+
+I like that it generates reproducible git commits so the same adjustments
+of the same branch will always have the same sha, no matter when and where
+it's done. Implementing that involved parsing git commit objects.
+
+Next step will be merging pulled changes into the adjusted branch, while
+maintaining the desired adjustments.
diff --git a/doc/devblog/day_368__leap.mdwn b/doc/devblog/day_368__leap.mdwn
new file mode 100644
index 0000000000..69766b5e32
--- /dev/null
+++ b/doc/devblog/day_368__leap.mdwn
@@ -0,0 +1,9 @@
+Pushed out a release today, could not resist the leap day in the version
+number, and also there were enough bug fixes accumulated to make it worth
+doing.
+
+I now have `git-annex sync` working inside adjusted branches, so pulls
+get adjusted appropriately before being merged into the adjusted branch.
+Seems to mostly work well, I did just find one bug in it though. Only
+propigating adjusted commits remains to be done to finish my adjusted
+branches prototype.
diff --git a/doc/devblog/day_369-370__paddling_furiously.mdwn b/doc/devblog/day_369-370__paddling_furiously.mdwn
new file mode 100644
index 0000000000..5321079002
--- /dev/null
+++ b/doc/devblog/day_369-370__paddling_furiously.mdwn
@@ -0,0 +1,72 @@
+Tuesday was spent dealing with lock files. Turned out there were some bugs
+in the `annex.pidlock` configuration that prevented it from working, and
+could even lead to data loss.
+
+And then more lock files today, since I needed to lock git's index file the
+same way git does. This involved finding out how to emulate `O_EXCL` under
+Windows. Urgh.
+
+Finally got back to working on [[design/adjusted_branches]] today. And, I've just
+gotten syncing of commits from adjusted branches back to the orginal branch
+working! Time for short demo of what I've been building for the past couple
+weeks:
+
+	joey@darkstar:~/tmp/demo>ls -l
+	total 4
+	lrwxrwxrwx 1 joey joey 190 Mar  3 17:09 bigfile -> .git/annex/objects/zx/X8/SHA256E-s1048576--44ee9fdd91d4bc567355f8b2becd5fe137b9e3aafdfe804341ce2bcc73b8013f/SHA256E-s1048576--44ee9fdd91d4bc567355f8b2becd5fe137b9e3aafdfe804341ce2bcc73b8013f
+	joey@darkstar:~/tmp/demo>git annex adjust
+	Switched to branch 'adjusted/master(unlocked)'
+	ok
+	joey@darkstar:~/tmp/demo#master(unlocked)>ls -l
+	total 4
+	-rw-r--r-- 1 joey joey 1048576 Mar  3 17:09 bigfile
+
+Entering the adjusted branch unlocked all the files.
+
+	joey@darkstar:~/tmp/demo#master(unlocked)>git mv bigfile newname
+	joey@darkstar:~/tmp/demo#master(unlocked)>git commit -m rename
+	[adjusted/master(unlocked) 29e1bc8] rename
+	 1 file changed, 0 insertions(+), 0 deletions(-)
+	  rename bigfile => newname (100%)
+	joey@darkstar:~/tmp/demo#master(unlocked)>git log --pretty=oneline
+	29e1bc835080298bbeeaa4a9faf42858c050cad5 rename
+	a195537dc5beeee73fc026246bd102bae9770389 git-annex adjusted branch
+	5dc1d94d40af4bf4a88b52805e2a3ae855122958 add
+	joey@darkstar:~/tmp/demo#master(unlocked)>git log --pretty=oneline master
+	5dc1d94d40af4bf4a88b52805e2a3ae855122958 add
+
+The commit was made on top of the commit that generated the adjusted branch.
+It's not yet reached the master branch.
+
+	joey@darkstar:~/tmp/demo#master(unlocked)>git annex sync
+	commit  ok
+	joey@darkstar:~/tmp/demo#master(unlocked)>git log --pretty=oneline
+	b60c5d6dfe55107431b80382596f14f4dcd259c9 git-annex adjusted branch
+	9c36848f078a2bb7a304010e962a2b7318c0877c rename
+	5dc1d94d40af4bf4a88b52805e2a3ae855122958 add
+	joey@darkstar:~/tmp/demo#master(unlocked)>git log --pretty=oneline master
+	9c36848f078a2bb7a304010e962a2b7318c0877c rename
+	5dc1d94d40af4bf4a88b52805e2a3ae855122958 add
+
+Now the commit has reached master. Notice how the history of the adjusted
+branch was rebased on top of the updated master branch as well.
+
+	joey@darkstar:~/tmp/demo#master(unlocked)>ls -l
+	total 1024
+	-rw-r--r-- 1 joey joey 1048576 Mar  3 17:09 newname
+	joey@darkstar:~/tmp/demo#master(unlocked)>git checkout master
+	Switched to branch 'master'
+	joey@darkstar:~/tmp/demo>ls -l
+	total 4
+	lrwxrwxrwx 1 joey joey 190 Mar  3 17:12 newname -> .git/annex/objects/zx/X8/SHA256E-s1048576--44ee9fdd91d4bc567355f8b2becd5fe137b9e3aafdfe804341ce2bcc73b8013f/SHA256E-s1048576--44ee9fdd91d4bc567355f8b2becd5fe137b9e3aafdfe804341ce2bcc73b8013f
+
+Just as we'd want, the file is locked in master, and unlocked in 
+the adjusted branch.
+
+(Not shown: git annex sync will also merge in and adjust changes from remotes.)
+
+So, that all looks great! But, it's cheating a bit, because it locks
+all files when updating the master branch. I need to make it remember,
+somehow, when files were originally unlocked, and keep them unlocked. Also
+want to implement other adjustments, like hiding files whose content is not
+present.
diff --git a/doc/devblog/day_36__bugfixing.mdwn b/doc/devblog/day_36__bugfixing.mdwn
new file mode 100644
index 0000000000..0e31d54bf4
--- /dev/null
+++ b/doc/devblog/day_36__bugfixing.mdwn
@@ -0,0 +1 @@
+Productive day, but I'm wiped out. Backlog down to 51.
diff --git a/doc/devblog/day_371__catching_up.mdwn b/doc/devblog/day_371__catching_up.mdwn
new file mode 100644
index 0000000000..02cdf8e7b5
--- /dev/null
+++ b/doc/devblog/day_371__catching_up.mdwn
@@ -0,0 +1,21 @@
+Over the weekend, I converted the linux "ancient" autobuilder to use stack.
+This makes it easier to get all the recent versions of all the haskell
+dependencies installed there.
+
+Also, merged my no-ffi branch, removing some library code from git-annex
+and adding new dependencies. It's good to remove code.
+
+Today, fixed the OSX dmg file -- its bundled gpg was broken. I pushed out a
+new version of the OSX dmg file with the fix.
+
+With the recent incident in mind of malware inserted into the Transmission
+dmg, I've added a virus scan step to the release process
+for all the git-annex images. This way, we'll notice if an autobuilder
+gets a virus.
+
+Also caught up on some backlog, although the remaining backlog is a little
+larger than I'd like at 135 messages.
+
+Hope to work some more on adjusted branches this week. A few mornings ago,
+I had what may be a key insight about how to reverse adjustments when
+propigating changes back from the adjusted branch.
diff --git a/doc/devblog/day_372__adjusted_branches_improved.mdwn b/doc/devblog/day_372__adjusted_branches_improved.mdwn
new file mode 100644
index 0000000000..625169eafd
--- /dev/null
+++ b/doc/devblog/day_372__adjusted_branches_improved.mdwn
@@ -0,0 +1,18 @@
+After a real brain-bender of a day, I have commit propagation from the
+adjusted branch back to the original branch working, without needing to
+reverse adjust the whole tree. This is faster, but the really nice thing
+is that it makes individual adjustments simpler to write.
+
+In fact, it's so simple that I took 10 minutes just now to implement a second
+adjustment!
+
+[[!format haskell """
+adjustTreeItem HideMissingAdjustment h ti@(TreeItem _ _ s) = do
+         mk <- catKey s
+         case mk of
+                 Just k -> ifM (inAnnex k)
+                         ( return (Just ti)
+      	                 , return Nothing
+                         )
+                 Nothing -> return (Just ti)
+"""]]
diff --git a/doc/devblog/day_373__away.mdwn b/doc/devblog/day_373__away.mdwn
new file mode 100644
index 0000000000..e8761b4e2c
--- /dev/null
+++ b/doc/devblog/day_373__away.mdwn
@@ -0,0 +1,6 @@
+Caught up with a few last things today, before I leave for 
+[a week in Boston](http://joeyh.name/trips/2016/boston/).
+
+Converted several places that ran git hash-object repeatedly to feed data
+to a running process. This sped up git-annex add in direct mode and with
+v6 unlocked files, by up to 2x.
diff --git a/doc/devblog/day_374__security_fix.mdwn b/doc/devblog/day_374__security_fix.mdwn
new file mode 100644
index 0000000000..c1d20bbdf1
--- /dev/null
+++ b/doc/devblog/day_374__security_fix.mdwn
@@ -0,0 +1,4 @@
+Pushed out a git-annex release this morning mostly because of the recent
+[[bugs/git_security_fix]]. Several git-annex builds bundle a copy of git and
+needed to be updated. Note that the OSX autobuilder is temporarily down and
+so it's not been updated yet -- hopefully soon.
diff --git a/doc/devblog/day_375__back.mdwn b/doc/devblog/day_375__back.mdwn
new file mode 100644
index 0000000000..c53cebaba3
--- /dev/null
+++ b/doc/devblog/day_375__back.mdwn
@@ -0,0 +1,10 @@
+Back from Libreplanet and a week of spring break. Backlog is not too bad
+for two weeks mostly away; 143 messages.
+
+Finally got the OSX app updated for the git security fix yesterday. Had to
+drop builds for old OSX releases.
+
+Getting back into working on adjusted branches now. Polishing up the UI and
+docs today. Nearly ready to merge the feature; the only blocker is there
+seems to be something a little bit wrong with how pulled changes are merged
+into the adjusted branch that I noticed in testing.
diff --git a/doc/devblog/day_376__in_the_weeds.mdwn b/doc/devblog/day_376__in_the_weeds.mdwn
new file mode 100644
index 0000000000..4454d7672c
--- /dev/null
+++ b/doc/devblog/day_376__in_the_weeds.mdwn
@@ -0,0 +1,18 @@
+Spent all day fixing sync in adjusted branches. I was lost in the weeds for
+a long time. Eventually, drawing this diagram helped me find my way
+to a solution:
+
+	origin/master    adjusted/master     master
+	A                                    A
+	|--------------->A'                  |
+	|                |                   |
+	|                C'- - - - - - - - > C
+	B                                    |
+	|                                    |
+	|--------------->M'<-----------------|
+
+After implementing that, syncing in adjusted branches seems to work much
+better now. And I've finally merged support for them into master.
+
+There's still several bugs and race conditions and upgrade things to sort
+out around adjusted branches. Proably another week's work all told.
diff --git a/doc/devblog/day_377__will_adjusted_branches_ever_end.mdwn b/doc/devblog/day_377__will_adjusted_branches_ever_end.mdwn
new file mode 100644
index 0000000000..9e6499b4e1
--- /dev/null
+++ b/doc/devblog/day_377__will_adjusted_branches_ever_end.mdwn
@@ -0,0 +1,21 @@
+Feels like I've been working on adjusted branches too long.
+
+Did make some excellent progress today. Upgrading a direct mode repo to v6
+will now enter an adjusted branch where all files are unlocked. Using an
+adjusted branch like this avoids unlocking all files in the master branch
+of the repo, which means that different clones of a repo can be
+upgraded to v6 mode at different times. This should let me advance the
+timetable for enabling v6 by default, and getting rid of direct mode.
+
+Also, cloning a repository that has an adjusted branch checked out will
+now work; the clone starts out in the same adjusted branch.
+
+But, I realized today that the way merges from origin/master into
+adjusted/master are done will often lead to merge conflicts. I have came up
+with a better way to handle these merges that won't unncessarily conflict,
+but didn't feel ready to implement that today.
+
+----
+
+Instead, I spent the latter half of the day getting caught up on some
+of the backlog. Got it down from some 200 messages to 150.
diff --git a/doc/devblog/day_378__finishing_adjusted_branches_merge.mdwn b/doc/devblog/day_378__finishing_adjusted_branches_merge.mdwn
new file mode 100644
index 0000000000..2b952f1615
--- /dev/null
+++ b/doc/devblog/day_378__finishing_adjusted_branches_merge.mdwn
@@ -0,0 +1,23 @@
+Well, I had to rethink how merges into adjusted branches should be handled.
+The old method often led to unnecessary merge conflicts. My new approach
+should always avoid unnecessary merge conflicts, but it's quite a trick.
+
+To merge origin/master into adjusted/master, it first merges origin/master
+into master. But, since adjusted/master is checked out, it has to do the
+merge in a temporary work tree. Luckily this can be done fairly
+inexpensively. To handle merge conflicts at this stage, git-annex's
+automatic merge conflict resolver is used. This approach wouldn't be
+feasible without a way to automatically resolve merge conflicts, because
+the user can't help with conflict resolution when the merge is not
+happening in their working tree.
+
+Once that out-of-tree merge is done, the result is adjusted, and merged
+into the adjusted branch. Since we know the adjusted branch is a child of
+the old master branch, this merge can be forced to always be a
+fast-forward. This second merge will only ever have conflicts if the work
+tree has something uncommitted in it that causes a merge conflict.
+
+Wow! That's super tricky, but it seems to work well. While I ended up
+throwing away everything I did [[last Thursday|day_376__in_the_weeds]]
+due to this new approach, the code is in some ways simpler than that
+old, busted approach.
diff --git a/doc/devblog/day_379__bugs_race_conditions_and_taxes.mdwn b/doc/devblog/day_379__bugs_race_conditions_and_taxes.mdwn
new file mode 100644
index 0000000000..3d323d2d49
--- /dev/null
+++ b/doc/devblog/day_379__bugs_race_conditions_and_taxes.mdwn
@@ -0,0 +1,12 @@
+Think I'm really finished with adjusted branches now. Fixed a bug in
+annex symlink calculation when merging into an adjusted branch. And, fixed
+a race condition involving a push of master from another repository.
+
+While `git annex adjust --unlock` is reason enough to have adjusted
+branches, I do want to at some point look into implementing `git annex
+adjust --hide-missing`, and perhaps rewrite the view branches to use
+adjusted branches, which would allow for updating view branches when
+pulling from a remote.
+
+Also, turns out Windows supports hard links, so I got annex.thin working
+on Windows, as well as a few other things that work better with hard links.
diff --git a/doc/devblog/day_37__long_day.mdwn b/doc/devblog/day_37__long_day.mdwn
new file mode 100644
index 0000000000..7882a746d8
--- /dev/null
+++ b/doc/devblog/day_37__long_day.mdwn
@@ -0,0 +1,6 @@
+A long day of bugfixing. Split into two major parts. First I got back to a
+bug I filed in August to do with the assistant misbehaving when run in a
+subdirectory of a git repository, and did a nice type-driven fix of the
+underlying problem (that also found and fixed some other related bugs that
+would not normally occur). Then, spent 4 hours in Windows purgatory working
+around crazy path separator issues.
diff --git a/doc/devblog/day_380__post_release.mdwn b/doc/devblog/day_380__post_release.mdwn
new file mode 100644
index 0000000000..d36aa27d65
--- /dev/null
+++ b/doc/devblog/day_380__post_release.mdwn
@@ -0,0 +1,8 @@
+Yesterday I released version 6.20160412, which is the first to support
+adjusted branches.
+
+Today, some planning for ways to better support `annex.thin`, but that
+seems to be stuck on needing a way to update git's index file. Which is the
+main thing needed to fix various problems with v6 unlocked files.
+
+Dove back into the backlog, got it down to 144 messages. Several bug fixes.
diff --git a/doc/devblog/day_381__executable_unlocked_files.mdwn b/doc/devblog/day_381__executable_unlocked_files.mdwn
new file mode 100644
index 0000000000..cac006205b
--- /dev/null
+++ b/doc/devblog/day_381__executable_unlocked_files.mdwn
@@ -0,0 +1,2 @@
+Seems I forgot about executable files entirely when implementing v6
+unlocked files. Fixed that oversight today.
diff --git a/doc/devblog/day_382-384__pretty_well_caught_up.mdwn b/doc/devblog/day_382-384__pretty_well_caught_up.mdwn
new file mode 100644
index 0000000000..86089f568a
--- /dev/null
+++ b/doc/devblog/day_382-384__pretty_well_caught_up.mdwn
@@ -0,0 +1,9 @@
+The past three days have felt kind of low activity days, but somehow a lot
+of stuff still got done, both bug fixes and small features, and I am
+feeling pretty well caught up with backlog for the first time in over a
+month. Although as always there is some left, 110 messages.
+
+On Monday I fixed a bug that could cause a hang when dropping content, if
+git-annex had to verify the content was present on a ssh remote. That bug
+was bad enough to make an immediate release for, even though it was only a
+week since the last release.
diff --git a/doc/devblog/day_385__new_features.mdwn b/doc/devblog/day_385__new_features.mdwn
new file mode 100644
index 0000000000..a2ff3ed195
--- /dev/null
+++ b/doc/devblog/day_385__new_features.mdwn
@@ -0,0 +1,16 @@
+Something that has come up repeatedly is that `git annex reinject` is
+too hard to use since you have to tell it which annexed file you're providing
+the content for. Now `git-annex reinject --known` can be passed a list of
+files and it will reinject any that hash to known annexed contents
+and ignore the rest. That works best when only one backend is used in a 
+repository; otherwise it would need to be run repeatedly with different
+`--backend` values.
+
+Turns out that the `GIT_COMMON_DIR` feature used by adjusted branches
+is only a couple years old, so don't let adjusted branches be used with
+a too old git.
+
+And, `git merge` is getting a new sanity check that prevents merging
+in a branch with a disconnected history. `git annex sync` will inherit that
+sanity check, but the assistant needs to let such merges happen when eg,
+pairing repositories, so more git version checking there.
diff --git a/doc/devblog/day_385__new_features/comment_1_f76ff85897f24692e96f88236b7f4b7d._comment b/doc/devblog/day_385__new_features/comment_1_f76ff85897f24692e96f88236b7f4b7d._comment
new file mode 100644
index 0000000000..91d4b2ddab
--- /dev/null
+++ b/doc/devblog/day_385__new_features/comment_1_f76ff85897f24692e96f88236b7f4b7d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2016-04-24T10:56:01Z"
+ content="""
+    git-annex reinject --known can be passed a list of files and it will reinject any that hash to known annexed contents and ignore the rest.
+
+I **so** can't wait for this to get released, it will save so much time for me!
+
+Thank you Joey ^_^
+"""]]
diff --git a/doc/devblog/day_386__day_off.mdwn b/doc/devblog/day_386__day_off.mdwn
new file mode 100644
index 0000000000..ae73307bb4
--- /dev/null
+++ b/doc/devblog/day_386__day_off.mdwn
@@ -0,0 +1,12 @@
+I'm on a long weekend. This did not prevent git-annex from getting an
+impressive lot of features though, as Daniel Dent contributed
+<https://github.com/DanielDent/git-annex-remote-rclone> which uses
+[rclone](http://rclone.org/) to add support for a ton of additional cloud
+storage things, including: 
+
+Google Drive, Openstack Swift, Rackspace cloud files, Memset Memstore, Dropbox,
+Google Cloud Storage, Amazon Cloud Drive, Microsoft One Drive, Hubic, Backblaze
+B2, Yandex Disk
+
+Wow! I hope that rclone will end up packaged in more distributions (eg Debian)
+so this will be easier to set up.
diff --git a/doc/devblog/day_387__release_day.mdwn b/doc/devblog/day_387__release_day.mdwn
new file mode 100644
index 0000000000..c7a294aed2
--- /dev/null
+++ b/doc/devblog/day_387__release_day.mdwn
@@ -0,0 +1,10 @@
+git-annex 6.20160419 has a rare security fix.
+A [bug](http://git-annex.branchable.com/bugs/External_special_remote_broken__63__/) made encrypted special
+remotes that are configured to use chunks accidentally expose the checksums
+of content that is uploaded to the remote. Such information is supposed to
+be hidden from the remote's view by the encryption. The same bug also made
+resuming interrupted uploads to such remotes start over from the beginning.
+
+After releasing that, I've been occupied today with fixing the Android
+autobuilder, which somehow got its build environment broken (unsure how),
+and fixing some other dependency issues.
diff --git a/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment b/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment
new file mode 100644
index 0000000000..9c20baad79
--- /dev/null
+++ b/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 1"
+ date="2016-04-29T10:26:22Z"
+ content="""
+> A bug made encrypted special remotes that are configured to use chunks accidentally expose the checksums of content that is uploaded to the remote. Such information is supposed to be hidden from the remote's view by the encryption.
+
+What should the users do to repair this situation? How can the exposed checksums be removed from the remote? Is a `git annex sync` enough?
+
+Thank you for the timely release!
+"""]]
diff --git a/doc/devblog/day_387__release_day/comment_2_86262439c9056c0e06623cdf79eaf9a6._comment b/doc/devblog/day_387__release_day/comment_2_86262439c9056c0e06623cdf79eaf9a6._comment
new file mode 100644
index 0000000000..19492995ab
--- /dev/null
+++ b/doc/devblog/day_387__release_day/comment_2_86262439c9056c0e06623cdf79eaf9a6._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-03T17:56:44Z"
+ content="""
+The exposed information is not stored in the remote. If it's stored
+anywhere, it would be in a server log, which might log an attempt
+to access an un-encrypted key filename (which typically includes the
+checksum and maybe the file's extension).
+
+So on the one hand, you don't need to do anything other than upgrade
+git-annex to recover from the problem. On the other hand, if the potential
+that a un-encrypted filename of a git-annex key having leaked into a server
+log somewhere is a problem, I don't have a solution to the problem. :-/
+"""]]
diff --git a/doc/devblog/day_388-389__various_and_windows.mdwn b/doc/devblog/day_388-389__various_and_windows.mdwn
new file mode 100644
index 0000000000..b929882b8f
--- /dev/null
+++ b/doc/devblog/day_388-389__various_and_windows.mdwn
@@ -0,0 +1,13 @@
+Lots of little fixes and improvements here and there over the past couple
+days.
+
+The main thing was fixing several bugs with adjusted branches and Windows.
+They seem to work now, and commits made on the adjusted branch are
+propigated back to master correctly.
+
+It would be good to finish up the last todos for v6 mode this month.
+The sticking point is I need a way to update the file stat in the git index
+when git-annex gets/drops/etc an unlocked file. I have not decided yet if
+it makes the most sense to add a dependency on libgit2 for that, or extend
+`git update-index`, or even write a pure haskell library to manipulate
+index files. Each has its pluses and its minuses.
diff --git a/doc/devblog/day_38__starting_git_repo_repair.mdwn b/doc/devblog/day_38__starting_git_repo_repair.mdwn
new file mode 100644
index 0000000000..3808abe389
--- /dev/null
+++ b/doc/devblog/day_38__starting_git_repo_repair.mdwn
@@ -0,0 +1,11 @@
+Goal for the rest of the month is to build automatic recovery git
+repository corruption. Spent today investigating how to do it and came up
+with a fairly [[detailed_design|design/assistant/disaster_recovery]]. It
+will have two parts, first to handle repository problems that can be fixed
+by fetching objects from remotes, and secondly to recover from problems
+where data never got sent to a remote, and has been lost.
+
+In either case, the assistant should be able to detect the problem and
+automatically recover well enough to keep running. Since this also affects
+non-git-annex repositories, it will also be available in a standalone
+`git-recover-repository` command.
diff --git a/doc/devblog/day_38__starting_git_repo_repair/comment_1_321468d9686db5dde072500bdaeb7d29._comment b/doc/devblog/day_38__starting_git_repo_repair/comment_1_321468d9686db5dde072500bdaeb7d29._comment
new file mode 100644
index 0000000000..3a1ce7851c
--- /dev/null
+++ b/doc/devblog/day_38__starting_git_repo_repair/comment_1_321468d9686db5dde072500bdaeb7d29._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://cstork.org/"
+ nickname="Chris Stork"
+ subject="Idea: checksum left-over files in .git/annex/tmp for potential recovery"
+ date="2013-10-19T12:30:58Z"
+ content="""
+This just came to mind when I thought about the second case.  I noticed quite often that files were left in .git/annex/tmp (seen on OS X) and sometimes these are the only instances of files on this particular computer.
+
+(It's on my todo list to file several bug reports about this and other issues on OS X...)
+"""]]
diff --git a/doc/devblog/day_390__sharedpubkey.mdwn b/doc/devblog/day_390__sharedpubkey.mdwn
new file mode 100644
index 0000000000..805b5b6c9a
--- /dev/null
+++ b/doc/devblog/day_390__sharedpubkey.mdwn
@@ -0,0 +1,5 @@
+It's not every day I add a new special remote encryption mode to
+git-annex! The new encryption=sharedpubkey mode
+lets anyone with a clone of the git repository (and access to the remote)
+store files in the remote, but then only the private key owner can access
+those files. Which opens up some interesting new use cases...
diff --git a/doc/devblog/day_391__git_smudge_clean_interface_proposal.mdwn b/doc/devblog/day_391__git_smudge_clean_interface_proposal.mdwn
new file mode 100644
index 0000000000..0a9d676aa7
--- /dev/null
+++ b/doc/devblog/day_391__git_smudge_clean_interface_proposal.mdwn
@@ -0,0 +1,3 @@
+Posted a [proposal for extending git smudge/clean filters with raw file access](http://thread.gmane.org/gmane.comp.version-control.git/294425).
+If git gets an interface like that, it will make it easy to deal with most of
+the remaining [[v6_todo_list|todo/smudge]].
diff --git a/doc/devblog/day_392__v6_fixes.mdwn b/doc/devblog/day_392__v6_fixes.mdwn
new file mode 100644
index 0000000000..10d2de263e
--- /dev/null
+++ b/doc/devblog/day_392__v6_fixes.mdwn
@@ -0,0 +1,12 @@
+Fixed several problems with v6 mode today. The assistant was doing some
+pretty wrong things when changes were synced into v6 repos, and that
+behavior is fixed. Also dealt with a race that caused updates made to the
+keys database by one process to not be seen by another process.
+And, made `git annex add` of a unlocked pointer file not annex the pointer
+file's content, but just add it to git as-is.
+
+Also, Thowz pointed out that adjusted branches could be used to locally adjust
+where annex symlinks point to, when a repository's git directory is not in
+the usual location. I've added that, as `git annex adjust --fix`. It
+was quite easy to implement this, which makes me very happy with the
+adjusted branches code!
diff --git a/doc/devblog/day_392__v6_fixes/comment_1_6da0787fa9749ee2d1f91842f10a5d3c._comment b/doc/devblog/day_392__v6_fixes/comment_1_6da0787fa9749ee2d1f91842f10a5d3c._comment
new file mode 100644
index 0000000000..a123937b53
--- /dev/null
+++ b/doc/devblog/day_392__v6_fixes/comment_1_6da0787fa9749ee2d1f91842f10a5d3c._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="dangling objects"
+ date="2016-05-18T01:49:11Z"
+ content="""
+My repos have accumulated thousands of dangling objects recently (every one).  I'm wondering, would this issue be resolved with the syncing fix?  If so, should the objects just be deleted?
+"""]]
diff --git a/doc/devblog/day_392__v6_fixes/comment_2_15434848be1951e93a1e5b9fcbccedb0._comment b/doc/devblog/day_392__v6_fixes/comment_2_15434848be1951e93a1e5b9fcbccedb0._comment
new file mode 100644
index 0000000000..129f88e98f
--- /dev/null
+++ b/doc/devblog/day_392__v6_fixes/comment_2_15434848be1951e93a1e5b9fcbccedb0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-21T13:55:01Z"
+ content="""
+Dangling objects are not related to the v6 syncing problems mentioned in
+this post.
+
+You can generally safely delete dangling objects from a git repository;
+git gc does it automatically after 30 days or so. git-annex does not
+normally create dangling objects but several git operations can.
+"""]]
diff --git a/doc/devblog/day_392__v6_fixes/comment_3_74e696f147f80162a941a5a5435327ce._comment b/doc/devblog/day_392__v6_fixes/comment_3_74e696f147f80162a941a5a5435327ce._comment
new file mode 100644
index 0000000000..e331dd8792
--- /dev/null
+++ b/doc/devblog/day_392__v6_fixes/comment_3_74e696f147f80162a941a5a5435327ce._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="comment 3"
+ date="2016-05-22T15:58:22Z"
+ content="""
+Thanks.
+"""]]
diff --git a/doc/devblog/day_393__fun_and_more_fun.mdwn b/doc/devblog/day_393__fun_and_more_fun.mdwn
new file mode 100644
index 0000000000..9d1fc0c326
--- /dev/null
+++ b/doc/devblog/day_393__fun_and_more_fun.mdwn
@@ -0,0 +1,15 @@
+Over the weekend, I noticed that a relative path to `GIT_INDEX_FILE` is
+interpreted in several different, inconsistent ways by git. git-annex
+mostly used absolute paths, but did use a relative path in `git annex
+view`. Now it will only use absolute paths to avoid git's wacky behavior.
+
+Integrated some patches to support building with ghc 8.0.1, which was
+recently released.
+
+The gnupg-options git configs were not always passed to gpg. Fixing this
+involved quite a lot of plumbing to get the options to the right functions,
+and consumed half of today.
+
+Also did some design work on [[design/external_special_remote_protocol]]
+to avoid backwards compatability problems when adding new protocol
+features.
diff --git a/doc/devblog/day_394__implicit_vs_explicit.mdwn b/doc/devblog/day_394__implicit_vs_explicit.mdwn
new file mode 100644
index 0000000000..300ac4c570
--- /dev/null
+++ b/doc/devblog/day_394__implicit_vs_explicit.mdwn
@@ -0,0 +1,23 @@
+git-annex has always balanced implicit and explicit behavior.
+Enabling a git repository to be used with git-annex needs an explicit init,
+to avoid foot-shooting; but a clone of a repository that is already
+using git-annex will be implicitly initialized. Git remotes implicitly
+are checked to see if they use git-annex, so the user can immediately
+follow `git remote add` with `git annex get` to get files from it.
+
+There's a fine line here, and implicit git remote enabling sometimes
+crosses it; sometimes the remote doesn't have git-annex-shell, and so
+there's an ugly error message and annex-ignore has to be set to avoid
+trying to enable that git remote again. Sometimes the probe of a remote
+can occur when the user doesn't really expect it to (and it can involve a
+ssh password prompt).
+
+Part of the problem is, there's not an explicit way to enable a git remote
+to be used by git-annex. So, today, I made `git annex enableremote` do
+that, when the remote name passed to it is a git remote rather than a
+special remote. This way, you can avoid the implicit behavior if you want
+to.
+
+I also made `git annex enableremote` un-set annex-ignore, so if a remote
+got that set due to a transient configuration problem, it can be explicitly
+enabled.
diff --git a/doc/devblog/day_395__leaky_abstractions.mdwn b/doc/devblog/day_395__leaky_abstractions.mdwn
new file mode 100644
index 0000000000..41bce37cc1
--- /dev/null
+++ b/doc/devblog/day_395__leaky_abstractions.mdwn
@@ -0,0 +1,7 @@
+Release today includes a last-minute fix to parsing lines from the
+git-annex branch that might have one or more carriage returns at the end.
+This comes from Windows of course, where since some things transparently
+add/remove `\r` before the end of lines, while other things don't,
+it could result in quite a mess. Luckily it was not hard or expensive to
+handle. If you are lucky enough not to use Windows, the release also
+has several more interesting improvements.
diff --git a/doc/devblog/day_396__misc_fixes.mdwn b/doc/devblog/day_396__misc_fixes.mdwn
new file mode 100644
index 0000000000..8f33d66ea3
--- /dev/null
+++ b/doc/devblog/day_396__misc_fixes.mdwn
@@ -0,0 +1,11 @@
+A productive day of small fixes. Including a change to deal with an
+incompatibility in git 2.9's commit.gpgsign, and couple of fixes
+involving gcrypt repositories.
+
+Also several improvements to cloning from repositories where an adjusted
+branch is checked out. The clone automatically ends up with the adjusted
+branch checked out too.
+
+The test suite has 3 failures when run on a FAT repository, all involving
+adjusted branches. Managed to fix one of them today, hope to get to the
+others soon.
diff --git a/doc/devblog/day_397__befuddled.mdwn b/doc/devblog/day_397__befuddled.mdwn
new file mode 100644
index 0000000000..a7d35fc75f
--- /dev/null
+++ b/doc/devblog/day_397__befuddled.mdwn
@@ -0,0 +1,28 @@
+Been having a difficult time fixing the two remaining test suite failures
+when run on a FAT filesystem.
+
+On Friday, I got quite lost trying to understand the first failure. At
+first I thought it had something to do with queued git staging commands not
+being run in the right git environment when git-annex is using a different
+index file or work tree. I did find and fix a potential bug in that area.
+It might be that some reports long ago of git-annex branch files getting
+written to the master branch was caused by that. But, fixing it did not
+help with the test suite failure at hand.
+
+Today, I quickly found the actual cause of the first failure.
+Of course, it had nothing to do with queued git commands at
+all, and was a simple fix in the end.
+
+But, I've been staring at the second failure for hours and am not much
+wiser. All I know is, an invalid tree object gets generated by the adjusted
+branch code that contains some files more than once. (git gets very
+confused when a repository contains such tree objects; if you wanted to break a
+git repository, getting such trees into it might be a good way. *cough*) This
+invalid tree object seems to be caused by the basis ref for the adjusted branch
+diverging somehow from the adjusted branch itself. I have not been able to
+determine why or how the basis ref can diverge like that.
+
+Also, this failure is somewhat indeterminite, doesn't always occur and
+reordering the tests in the test suite can hide it. Weird.
+
+Well, hopefully looking at it again later with fresh eyes will help.
diff --git a/doc/devblog/day_398__fresh_eyes.mdwn b/doc/devblog/day_398__fresh_eyes.mdwn
new file mode 100644
index 0000000000..ce5c2adb7b
--- /dev/null
+++ b/doc/devblog/day_398__fresh_eyes.mdwn
@@ -0,0 +1,11 @@
+Today I was indeed able to get to the bottom of and fix the bug that
+had stumped me the other day.
+
+Rest of the day was taken up by catching up to some bug requests and
+suggestions for v6 mode. Like making unlock and lock work for files
+that are not locally present. And, improving the behavior of the clean
+filter so it remembers what backend was used for a file before and
+continues using that same backend.
+
+About ready to make a release, but IIRC there's one remaining test suite
+failure on FAT.
diff --git a/doc/devblog/day_399__weird_git_merge_bug.mdwn b/doc/devblog/day_399__weird_git_merge_bug.mdwn
new file mode 100644
index 0000000000..76e56384af
--- /dev/null
+++ b/doc/devblog/day_399__weird_git_merge_bug.mdwn
@@ -0,0 +1,16 @@
+There was one more test suite failure when run on FAT, which I've
+investigated today. It turns out that
+[a bug report](https://git-annex.branchable.com/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/)
+was filed about the same problem, and at root
+it seems to be a [bug in git merge](http://thread.gmane.org/gmane.comp.version-control.git/297237).
+Luckily, it was not hard to work around the strange merge behavior.
+
+It's been very worthwhile running the test suite on FAT; it's pointed me at
+several problems with adjusted branches over the past weeks. It would be
+good to add another test suite pass to test adjusted branches explicitly,
+but when I tried adding that, there were a lot of failures where the test
+suite is confused by adjusted branch behavior and would need to be taught
+about it.
+
+I've released git-annex 6.20160613. If you're using v6 repositories and
+especially adjusted branches, you should upgrade since it has many fixes.
diff --git a/doc/devblog/day_39__git-recover-repository.mdwn b/doc/devblog/day_39__git-recover-repository.mdwn
new file mode 100644
index 0000000000..f2c552eef8
--- /dev/null
+++ b/doc/devblog/day_39__git-recover-repository.mdwn
@@ -0,0 +1,54 @@
+Built a `git-recover-repository` command today. So far it only does the
+detection and deletion of corrupt objects, and retrieves them from remotes
+when possible. No handling yet of missing objects that cannot be recovered
+from remotes.
+
+Here's a couple of sample runs where I do bad things to the git
+repository and it fixes them:
+
+<pre>
+joey@darkstar:~/tmp/git-annex>chmod 644 .git/objects/pack/*
+joey@darkstar:~/tmp/git-annex>echo > .git/objects/pack/pack-a1a770c1569ac6e2746f85573adc59477b96ebc5.pack 
+joey@darkstar:~/tmp/git-annex>~/src/git-annex/git-recover-repository 
+Running git fsck ...
+git fsck found a problem but no specific broken objects. Perhaps a corrupt pack file? Unpacking all pack files.
+fatal: early EOF
+Unpacking objects: 100% (148/148), done.
+Unpacking objects: 100% (354/354), done.
+Re-running git fsck to see if it finds more problems.
+Re-running git fsck to see if it finds more problems.
+Initialized empty Git repository in /home/joey/tmp/tmprepo.0/.git/
+Trying to recover missing objects from remote origin
+Successfully recovered repository!
+You should run "git fsck" to make sure, but it looks like
+everything was recovered ok.
+</pre>
+
+----
+
+<pre>
+joey@darkstar:~/tmp/git-annex>chmod 644 .git/objects/00/0800742987b9f9c34caea512b413e627dd718e
+joey@darkstar:~/tmp/git-annex>echo > .git/objects/00/0800742987b9f9c34caea512b413e627dd718e
+joey@darkstar:~/tmp/git-annex>~/src/git-annex/git-recover-repository 
+Running git fsck ...
+error: unable to unpack 000800742987b9f9c34caea512b413e627dd718e header
+error: inflateEnd: stream consistency error (no message)
+error: unable to unpack 000800742987b9f9c34caea512b413e627dd718e header
+error: inflateEnd: stream consistency error (no message)
+git fsck found 1 broken objects. Unpacking all pack files.
+removing 1 corrupt loose objects
+Re-running git fsck to see if it finds more problems.
+Re-running git fsck to see if it finds more problems.
+Initialized empty Git repository in /home/joey/tmp/tmprepo.0/.git/
+Trying to recover missing objects from remote origin
+Successfully recovered repository!
+You should run "git fsck" to make sure, but it looks like
+everything was recovered ok.
+</pre>
+
+Works great! I need to move this and `git-union-merge` out of the git-annex
+source tree sometime.
+
+----
+
+Today's work was sponsored by Francois Marier.
diff --git a/doc/devblog/day_3__gcrypt_uuids.mdwn b/doc/devblog/day_3__gcrypt_uuids.mdwn
new file mode 100644
index 0000000000..3182aca633
--- /dev/null
+++ b/doc/devblog/day_3__gcrypt_uuids.mdwn
@@ -0,0 +1,63 @@
+Started work on [gcrypt](https://github.com/blake2-ppc/git-remote-gcrypt)
+support.
+
+The first question is, should git-annex leave it up to gcrypt to transport
+the data to the encrypted repository on a push/pull? gcrypt hooks into git
+nicely to make that just work. However, if I go this route, it limits
+the places the encrypted git repositores can be stored to regular git
+remotes (and rsync). The alternative is to somehow use gcrypt to
+generate/consume the data, but use the git-annex special remotes to store
+individual files. Which would allow for a git repo stored on S3, etc.
+For now, I am going with the simple option, but I have not ruled out
+trying to make the latter work. It seems it would need changes to gcrypt
+though.
+
+Next question: Given a remote that uses gcrypt, how do I determine the
+annex.uuid of that repository. I found a nice solutuon to this. gcrypt has
+its own gcrypt-id, and I convert it to a UUID in a 
+[[reproducible, and even standards-compliant way|design/gcrypt]]. So
+the same encrypted remote will automatically get the same annex.uuid
+wherever it's used. Nice. Does mean that git-annex cannot find a uuid
+until `git pull` or `git push` has been used, to let gcrypt get the
+gcrypt-id. Implemented that.
+
+The next step is actually making git-annex store data on gcrypt remotes.
+And it needs to store it encrypted of course. It seems best to avoid
+needing a `git annex initremote` for these gcrypt remotes, and just have
+git-annex automatically encrypt data stored on them. But I don't
+know. Without initializing them like a special remote is, I'm limited to
+using the gpg keys that gcrypt is configured to encrypt to, and cannot use
+the regular git-annex hybrid encryption scheme. Also, I need to generate
+and store a nonce anyway to HMAC ecrypt keys. (Or modify gcrypt
+to put enough entropy in gcrypt-id that I can use it?) 
+
+Another concern I have is that gcrypt's own encryption scheme is simply
+to use a list of public keys to encrypt to. It would be nicer if the
+full set of git-annex encryption schemes could be used. Then the webapp
+could use shared encryption to avoid needing to make the user set up a gpg
+key, or hybrid encryption could be used to add keys later, etc.
+
+But I see why gcrypt works the way it does. Otherwise, you can't make an
+encrypted repo with a friend set as one of the particpants and have them be
+able to git clone it. Both hybrid and shared encryption store a secret
+inside the repo, which is not accessible if it's encrypted using that
+secret. There are use cases where not being able to blindly clone a gcrypt
+repo would be ok. For example, you use the assistant to pair with a friend
+and then set up an encrypted repo in the cloud for both of you to use.
+
+Anyway, for now, I will need to deal with
+setting up gpg keys etc in the assistant. I don't want to tackle
+full [[design/assistant/gpgkeys]] yet. Instead, I think I will start by
+adding some simple stuff to the assistant:
+
+* When adding a USB drive, offer to encrypt the repository on the drive
+  so that only you can see it.
+* When adding a ssh remote make a similar offer.
+* Add a UI to add an arbitrary git remote with encryption.
+  Let the user paste in the url to an empty remote they have,
+  which could be to eg github. (In most cases this won't be used for
+  annexed content..)
+* When the user has no gpg key, prompt to set one up. (Securely!)
+* Maybe have an interface to add another gpg key that can access the gcrypt
+  repo. Note that this will need to re-encrypt and re-push the whole
+  git history.
diff --git a/doc/devblog/day_400-401__git_development.mdwn b/doc/devblog/day_400-401__git_development.mdwn
new file mode 100644
index 0000000000..a3b7f5d564
--- /dev/null
+++ b/doc/devblog/day_400-401__git_development.mdwn
@@ -0,0 +1,11 @@
+Working on git, not git-annex the past two days, I have implemented the
+smudge-to-file/clean-from-file extension to the smudge/clean filter
+interface. Patches have been [sent to the git developers](http://thread.gmane.org/gmane.comp.version-control.git/297475), 
+and hopefully they'll like it and include it. This will make git-annex
+v6 work a lot faster and better.
+
+Amazing how much harder it is to code on git than on git-annex! While I'm
+certianly not as familiar with the git code base, this is mostly because C
+requires so much more care about innumerable details and so much verbosity
+to do anything. I probably could have implemented this interface in
+git-annex in 2 hours, not 2 days.
diff --git a/doc/devblog/day_402__enhanced_smudge_clean_interface.mdwn b/doc/devblog/day_402__enhanced_smudge_clean_interface.mdwn
new file mode 100644
index 0000000000..a7739755ea
--- /dev/null
+++ b/doc/devblog/day_402__enhanced_smudge_clean_interface.mdwn
@@ -0,0 +1,14 @@
+Continued working on the enhancaed smudge/clean interface in git,
+incorporating feedback from the git developers.
+
+In a spare half an hour, I made an `improved-smudge-filters` branch
+that teaches git-annex smudge to use the new interface. 
+
+Doing a quick benchmark, `git checkout` of a deleted 1 gb file took:
+
+* 19 seconds before
+* 11 seconds with the new interface
+* 0.1 seconds with the new interface and annex.thin set  
+  (while also saving 1 gb of disk space!)
+
+So, this new interface is very much worthwhile.
diff --git a/doc/devblog/day_403__update_and_away.mdwn b/doc/devblog/day_403__update_and_away.mdwn
new file mode 100644
index 0000000000..02c1834354
--- /dev/null
+++ b/doc/devblog/day_403__update_and_away.mdwn
@@ -0,0 +1,4 @@
+Continued working on the enhanced smudge/clean interface in git today.
+Sent in a third version of the patch set, which is now quite complete.
+
+I'll be away for the next week and a half, on vacation.
diff --git a/doc/devblog/day_404__low_hanging_fruit.mdwn b/doc/devblog/day_404__low_hanging_fruit.mdwn
new file mode 100644
index 0000000000..73f8ee7fb9
--- /dev/null
+++ b/doc/devblog/day_404__low_hanging_fruit.mdwn
@@ -0,0 +1,15 @@
+Back from vacation, with a message backlog of 181. I'm concentrating first on
+low-hanging fruit of easily implemented todos, and well reproducible bugs,
+to get started again.
+
+Implemented --batch mode for `git annex get` and `git annex drop`, and also
+enabled --json for those.
+
+Investigated git-annex startup time; see
+<http://git-annex.branchable.com/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__/>.
+Turns out that cabal has a bug that causes many thousands of unnecessary
+syscalls when linking in the shared libraries. Working around it halved
+git-annex's startup time.
+
+Fixed a bug that caused `git annex testremote` to crash when testing a
+freshly made external special remote.
diff --git a/doc/devblog/day_405__more_git_development.mdwn b/doc/devblog/day_405__more_git_development.mdwn
new file mode 100644
index 0000000000..2a2485db89
--- /dev/null
+++ b/doc/devblog/day_405__more_git_development.mdwn
@@ -0,0 +1,3 @@
+Revisited my enhanced smudge/clean patch set for git, updating it for code
+review and to deal with changes in git since I've been away. This took
+several hours unfortunately.
diff --git a/doc/devblog/day_406__low_handing_fruit_continued.mdwn b/doc/devblog/day_406__low_handing_fruit_continued.mdwn
new file mode 100644
index 0000000000..e417f1856a
--- /dev/null
+++ b/doc/devblog/day_406__low_handing_fruit_continued.mdwn
@@ -0,0 +1,3 @@
+Worked on recent bug reports. Two bugs fixed today were both reversions
+introduced when the v6 repository support was added. Backlog is down to
+153.
diff --git a/doc/devblog/day_407__lazy_sunday.mdwn b/doc/devblog/day_407__lazy_sunday.mdwn
new file mode 100644
index 0000000000..7fe5e19176
--- /dev/null
+++ b/doc/devblog/day_407__lazy_sunday.mdwn
@@ -0,0 +1,9 @@
+Noticed that in one of my git-annex repositories, git-annex was spending
+a full second at startup checking all the git-annex branches from remotes
+to see if they contained changes that needed to be merged in. So, I added a
+cache of recently merged branches to avoid that. I remember considering
+this optimisation years ago; don't know why I didn't do it then. Not every
+day that I can speed up git-annex so much!
+
+Also, made `git annex log --all` show location log changes for all keys.
+This was tricky to get right and fast.
diff --git a/doc/devblog/day_408__release_day.mdwn b/doc/devblog/day_408__release_day.mdwn
new file mode 100644
index 0000000000..647b64eac8
--- /dev/null
+++ b/doc/devblog/day_408__release_day.mdwn
@@ -0,0 +1,6 @@
+First release in over a month. Before making this release, a few last
+minute fixes, including a partial workaround for the problem that
+Sqlite databases don't work on Lustre filesystems.
+
+Backlog is now down to 140 messages, and only 3 of those are from this
+month. Still higher than I like.
diff --git a/doc/devblog/day_408__release_day/comment_1_RichiH._comment b/doc/devblog/day_408__release_day/comment_1_RichiH._comment
new file mode 100644
index 0000000000..36f8272022
--- /dev/null
+++ b/doc/devblog/day_408__release_day/comment_1_RichiH._comment
@@ -0,0 +1,3 @@
+You typo'ed the tag and the release date in debian/changelog: 6.20160619 instead of 6.20160719
+
+I will release 6.20160719-1 in Debian on the assumption that you will fix that tag :)
diff --git a/doc/devblog/day_409__--branch.mdwn b/doc/devblog/day_409__--branch.mdwn
new file mode 100644
index 0000000000..6ede436c76
--- /dev/null
+++ b/doc/devblog/day_409__--branch.mdwn
@@ -0,0 +1,17 @@
+A common complaint is that `git annex fsck` in a bare repository complains
+about missing content of deleted files. That's because in a bare
+repository, git-annex operates on all versions of all files. Today I added
+a --branch option, so if you only want to check say, the master branch, you
+can: `git annex fsck --branch master`
+
+The new option has other uses too. Want to get all the files in the v1.0
+tag? `git annex get --branch v1.0`
+
+It might be worth revisiting the implicit --all behavior for bare
+repositories. It could instead default to --branch HEAD or something like
+that. But I'd only want to change that if there was a strong consensus in
+favor.
+
+Over 3/4th of the time spent implementing --branch was spent in
+adjusting the output of commands, to show "branch:file" is being
+operated on. How annoying.
diff --git a/doc/devblog/day_40__another_fine_mess.mdwn b/doc/devblog/day_40__another_fine_mess.mdwn
new file mode 100644
index 0000000000..dfe5bc5642
--- /dev/null
+++ b/doc/devblog/day_40__another_fine_mess.mdwn
@@ -0,0 +1,15 @@
+Solid day of working on repository recovery. Got `git recover-repository
+--force` working, which involves fixing up branches that refer to missing
+objects. Mostly straightforward traversal of git commits, trees, blobs, to
+find when a branch has a problem, and identify an old version of it that
+predates the missing object. (Can also find them in the reflog.) 
+
+The main complication turned out to be that `git branch -D` and `git
+show-ref` don't behave very well when the commit objects pointed to by refs
+are themselves missing. And git has no low-level plumbing that avoids
+falling over these problems, so I had to write it myself.
+
+Testing has turned up one unexpected problem: Git's index can itself refer
+to missing objects, and that will break future commits, etc. So I need to
+find a way to validate the index, and when it's got problems,
+either throw it out, or possibly recover some of the staged data from it.
diff --git a/doc/devblog/day_410__better_JSON_for_metadata.mdwn b/doc/devblog/day_410__better_JSON_for_metadata.mdwn
new file mode 100644
index 0000000000..44648d9992
--- /dev/null
+++ b/doc/devblog/day_410__better_JSON_for_metadata.mdwn
@@ -0,0 +1,31 @@
+I've had to change the output of `git annex metadata --json`.
+The old output looked like this:
+
+	{"command":"metadata","file":"foo","key":"...","author":["bar"],...,"note":"...","success":true}
+
+That was not good, because it didn't separate the metadata fields
+from the rest of the JSON object. What if a metadata field is named
+"note" or "success"? It would collide with the other "note" and "success"
+in the JSON.
+
+So, changed this to a new format, which moves the metadata fields into
+a "fields" object:
+
+	{"command":"metadata","file":"foo","key":"...","fields":{"author":["bar"],...},"note":"...","success":true}
+
+I don't like breaking backwards compatability of JSON output, but in this
+case I could see no real alternative. I don't know if anyone
+is using `metadata --batch` anyway. If you are and this will cause a
+problem, get in touch.
+
+----
+
+While making that change, I also improved the JSON output layer, so it can
+use Aeson. Update: And switched everything over to using Aeson, so
+git-annex no longer depends on two different JSON libraries.
+
+This let me use Aeson to generate the "fields" object for `metadata
+--json`. And it was also easy enough to use Aeson to parse the output of
+that command (and some simplified forms of it).
+
+So, I've laid the groundwork for `git annex metadata --batch` today.
diff --git a/doc/devblog/day_411__metadata_--batch.mdwn b/doc/devblog/day_411__metadata_--batch.mdwn
new file mode 100644
index 0000000000..acd1429c8a
--- /dev/null
+++ b/doc/devblog/day_411__metadata_--batch.mdwn
@@ -0,0 +1,4 @@
+With yesterday's JSON groundwork in place, I quickly implemented `git annex
+metadata --batch` today in only 45 LoC. The interface is nicely elegant;
+the same JSON format that git-annex metadata outputs can be fed into it
+to get, set, delete, and modify metadata.
diff --git a/doc/devblog/day_412__if_at_first_you_dont_succeed.mdwn b/doc/devblog/day_412__if_at_first_you_dont_succeed.mdwn
new file mode 100644
index 0000000000..958564cab3
--- /dev/null
+++ b/doc/devblog/day_412__if_at_first_you_dont_succeed.mdwn
@@ -0,0 +1,49 @@
+[[!meta title="if at first you don't succeed.."]]
+
+A user suggested [adding --failed](http://git-annex.branchable.com/todo/__34__copy_--failed__34__/)
+to retry failed transfers. That was a great idea and I landed a patch for it
+3 hours later. Love it when a user suggests something so clearly right and
+I am able to quickly make it happen!
+
+----
+
+Unfortunately, my funding from the [DataLad](https://datalad.org/) project
+to work on git-annex is running out. It's been a very good two years funded
+that way, with an enormous amount of improvements and support and bug
+fixes, but all good things must end. I'll continue to get some funding
+from them for the next year, but only for half as much time as the past two
+years.
+
+I need to decide it it makes sense to keep working on git-annex to the
+extent I have been. There are definitely a few (hundred) things I still
+want to do on git-annex, starting with getting the git patches landed to
+make v6 mode really shine. Past that, it's mostly up to the users. If they
+keep suggesting great ideas and finding git-annex useful, I'll want to
+work on it more.
+
+What to do about funding? Maybe some git-annex users can contribute a
+small amount each month to fund development. I've set up a Patreon
+page for this, **<https://www.patreon.com/joeyh>**
+
+----
+
+Anyhoo... Back to today's (unfunded) work.
+
+`--failed` can be used with `get`, `move`, `copy`, and
+`mirror`. Of course those commands can all be simply re-ran if some
+of the transfers fail and will pick up where they left off. But using
+`--failed` is faster because it does not need to scan all files to find
+out which still need to be transferred. And accumulated failures from
+multiple commands can be retried with a single use of `--failed`. 
+
+It's even possible to do things like `git annex get --from foo; git annex
+get --failed --from bar`, which first downloads everything it can from the
+foo remote and falls back to using the bar remote for the rest. Although
+setting remote costs is probably a better approach most of the time.
+
+Turns out that I had earlier disabled writing failure log files, except by
+the assistant, because only the assistant was using them. So, that had to
+be undone. There's some potential for failure log files to accumulate
+annoyingly, so perhaps some expiry mechanism will be needed. This is why
+`--failed` is documented as retrying "recent" transfers. Anyway, the
+failure log files are cleaned up after successful transfers.
diff --git a/doc/devblog/day_412__if_at_first_you_dont_succeed/comment_1_8980f56815a2c016ca950aec09e6e839._comment b/doc/devblog/day_412__if_at_first_you_dont_succeed/comment_1_8980f56815a2c016ca950aec09e6e839._comment
new file mode 100644
index 0000000000..b299eb2a71
--- /dev/null
+++ b/doc/devblog/day_412__if_at_first_you_dont_succeed/comment_1_8980f56815a2c016ca950aec09e6e839._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="rasmus"
+ avatar="http://cdn.libravatar.org/avatar/cb09dc4c52e771aa888e14b931d3acc3"
+ subject="support"
+ date="2016-10-27T10:45:06Z"
+ content="""
+Hi Joey,
+
+git annex has become great.  In the past I spent a lot of time fiddeling with it and even lost files.  Now, it all runs in the background flawlessly.
+Even the \"spin up\" of the disk is
+
+In any case, I would be very happy to help fund the development in what way I can.
+However, it would be great if you could point out a way to do single transfers to you, either by credit card or paypal (or a European bank transfer, which I guess is less interesting).
+I'm also happy to support a rebooted campaign.joeyh.name.
+
+Thanks,
+Rasmus
+"""]]
diff --git a/doc/devblog/day_412__if_at_first_you_dont_succeed/comment_2_641ca9bce852cea42cac25fd77518885._comment b/doc/devblog/day_412__if_at_first_you_dont_succeed/comment_2_641ca9bce852cea42cac25fd77518885._comment
new file mode 100644
index 0000000000..9754a97ced
--- /dev/null
+++ b/doc/devblog/day_412__if_at_first_you_dont_succeed/comment_2_641ca9bce852cea42cac25fd77518885._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-10-27T19:23:41Z"
+ content="""
+Nice to hear. <https://joeyh.name/thanks/> has some pointers.
+"""]]
diff --git a/doc/devblog/day_413__back.mdwn b/doc/devblog/day_413__back.mdwn
new file mode 100644
index 0000000000..ebd2335ee4
--- /dev/null
+++ b/doc/devblog/day_413__back.mdwn
@@ -0,0 +1,19 @@
+Back after taking most of August off and working on other projects.
+
+Got the unanswered messages backlog down from 222 to 170. Still scary high.
+
+Numerous little improvements today. Notable ones:
+
+* Windows: Handle shebang in external special remote program. This is
+  needed for [git-annex-remote-rclone to work on Windows](https://github.com/DanielDent/git-annex-remote-rclone/pull/10).
+  Nice to see that external special remote is getting ported and
+  apparently lots of use.
+* Make --json and --quiet suppress automatic init messages, and any
+  other messages that might be output before a command starts. This was a
+  reversion introduced in the optparse-applicative changes over a year ago.
+
+Also I'm developing a plan to improve parallel downloading when multiple
+remotes have the same cost. See [[todo/get_round_robin]].
+
+Today's work was sponsored by Jake Vosloo on
+[Patreon](https://www.patreon.com/joeyh).
diff --git a/doc/devblog/day_414__improved_parallel_get.mdwn b/doc/devblog/day_414__improved_parallel_get.mdwn
new file mode 100644
index 0000000000..28f6c8ad8d
--- /dev/null
+++ b/doc/devblog/day_414__improved_parallel_get.mdwn
@@ -0,0 +1,6 @@
+Turned out to not be very hard at all to make `git annex get -JN`
+assign different threads to different remotes that have the same cost.
+Something like that was requested back in 2011, but it didn't really make
+sense until parallel get was implemented last year.
+
+(Also spent too much time fixing up broken builds.)
diff --git a/doc/devblog/day_415__catching_up.mdwn b/doc/devblog/day_415__catching_up.mdwn
new file mode 100644
index 0000000000..d2828a0c8b
--- /dev/null
+++ b/doc/devblog/day_415__catching_up.mdwn
@@ -0,0 +1,19 @@
+Catching up on backlog today. I hope to be back to a regular work schedule
+now. Unanswered messages down to 156. A lot of time today spent answering
+questions.
+
+There were several problems involving git branches with slashes in their
+name, such as "foo/bar" (but not "origin/master" or "refs/heads/foo").
+Some branch names based on such a branch would take only the "bar" part.
+In `git annex sync`, this led to perhaps merging "foo/bar" into "other/bar"
+or "bar". And the adjusted branch code was entirely broken for such
+branches. I've fixed it now.
+
+Also made `git annex addurl` behave better when the file it wants to 
+add is gitignored.
+
+Thinking about implementing `git annex copy --from A --to B`.
+It does not seem *too* hard to do that, at least with a temp file
+used inbetween. See [[todo/transitive_transfers]].
+
+Today's work was sponsored by Thomas Hochstein on Patreon.
diff --git a/doc/devblog/day_416__measure_twice.mdwn b/doc/devblog/day_416__measure_twice.mdwn
new file mode 100644
index 0000000000..e3d9f00c47
--- /dev/null
+++ b/doc/devblog/day_416__measure_twice.mdwn
@@ -0,0 +1,8 @@
+Only had a couple hours today, which were spent doing some profiling of
+git-annex in situations where it has to look through a large working tree in
+order to find files to act on. The top five hot spots this found are
+responsible for between 50% and 80% of git-annex's total CPU use in these
+situations.
+
+The first optimisation sped up `git annex find` by around 18%.
+More tomorrow..
diff --git a/doc/devblog/day_417__cut_once.mdwn b/doc/devblog/day_417__cut_once.mdwn
new file mode 100644
index 0000000000..419e279f78
--- /dev/null
+++ b/doc/devblog/day_417__cut_once.mdwn
@@ -0,0 +1,6 @@
+Did most of the optimisations that recent profiling suggested. 
+This sped up a `git annex find` from 3.53 seconds to 1.73 seconds.
+And, `git annex find --not --in remote` from 12.41 seconds to 5.24 seconds.
+One of the optimisations sped up git-annex branch querying by up to 50%,
+which should also speed up use of some preferred content expressions.
+All in all, a very nice little optimisation pass.
diff --git a/doc/devblog/day_418__concurrent_externals.mdwn b/doc/devblog/day_418__concurrent_externals.mdwn
new file mode 100644
index 0000000000..6dd6916dd2
--- /dev/null
+++ b/doc/devblog/day_418__concurrent_externals.mdwn
@@ -0,0 +1,12 @@
+Realized recently that despite all the nice concurrency support in
+git-annex, external special remotes were limited to handling one request at
+a time.
+
+While the external special remote prococol could almost support concurrent
+requests, that would complicate implementing them, and probably need a
+version flag to enable to avoid breaking existing ones.
+
+Instead, made git-annex start up multiple external special remote processes
+as needed to handle concurrency.
+
+Today's work was sponsored by Josh Taylor on Patreon.
diff --git a/doc/devblog/day_418__concurrent_externals/comment_1_75e6569b143cf3f595ba9b356415a747._comment b/doc/devblog/day_418__concurrent_externals/comment_1_75e6569b143cf3f595ba9b356415a747._comment
new file mode 100644
index 0000000000..dfad031d78
--- /dev/null
+++ b/doc/devblog/day_418__concurrent_externals/comment_1_75e6569b143cf3f595ba9b356415a747._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Adam"
+ subject="Question"
+ date="2016-10-04T05:27:31Z"
+ content="""
+Hi Joey,
+
+Does this mean that, for example, when uploading many small files to a special remote, that git-annex could upload more than one at a time?  Sometimes it seems like the time spent waiting for a small file to upload is mostly spent waiting for the server to begin accepting the file.   With lots of small files, this adds up (similar to how round-trip time slows down Obnam significantly when using a network repo).
+
+Thanks.
+"""]]
diff --git a/doc/devblog/day_418__concurrent_externals/comment_2_067909ed54f3f9295f90233f25ccfd70._comment b/doc/devblog/day_418__concurrent_externals/comment_2_067909ed54f3f9295f90233f25ccfd70._comment
new file mode 100644
index 0000000000..c075785763
--- /dev/null
+++ b/doc/devblog/day_418__concurrent_externals/comment_2_067909ed54f3f9295f90233f25ccfd70._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-10-04T15:16:01Z"
+ content="""
+Well yes, git-annex -J4 or something can parallelize any operation and
+avoid such latencies.
+"""]]
diff --git a/doc/devblog/day_418__concurrent_externals/comment_3_39c729fc2ea4b597d13e54d60bb36d0d._comment b/doc/devblog/day_418__concurrent_externals/comment_3_39c729fc2ea4b597d13e54d60bb36d0d._comment
new file mode 100644
index 0000000000..7f4202ab9c
--- /dev/null
+++ b/doc/devblog/day_418__concurrent_externals/comment_3_39c729fc2ea4b597d13e54d60bb36d0d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Adam"
+ subject="comment 3"
+ date="2016-10-04T21:24:50Z"
+ content="""
+Oh, I see, thanks.  Have you thought about adding an option for that to the assistant?  For example, I tested syncing a bunch of text files through a special remote, and even though the files were small, the per-command latency added up, so the effective transfer rate wasn't very high.  If it were easy to set the concurrency option in the assistant, I guess it would help with that.
+"""]]
diff --git a/doc/devblog/day_418__concurrent_externals/comment_4_6b254fbe92d40abc30d01afe5d039afc._comment b/doc/devblog/day_418__concurrent_externals/comment_4_6b254fbe92d40abc30d01afe5d039afc._comment
new file mode 100644
index 0000000000..8f3387ee1f
--- /dev/null
+++ b/doc/devblog/day_418__concurrent_externals/comment_4_6b254fbe92d40abc30d01afe5d039afc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="evilmoo@0c9697a666c2853b3b3229b6646d3a4e849f7ec8"
+ nickname="evilmoo"
+ subject="bittorrent"
+ date="2016-10-05T03:53:05Z"
+ content="""
+Will this speed up the problems with added Bittorrent URLs only downloading one file at a time?
+"""]]
diff --git a/doc/devblog/day_418__concurrent_externals/comment_5_5e851b62bdca1cb8d8062d4890c77956._comment b/doc/devblog/day_418__concurrent_externals/comment_5_5e851b62bdca1cb8d8062d4890c77956._comment
new file mode 100644
index 0000000000..a3f39a5cd5
--- /dev/null
+++ b/doc/devblog/day_418__concurrent_externals/comment_5_5e851b62bdca1cb8d8062d4890c77956._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-10-05T15:31:37Z"
+ content="""
+@evilmoo is that problem detailed somewhere?
+"""]]
diff --git a/doc/devblog/day_418__concurrent_externals/comment_6_ea5d42bcb03af937a604119039f9073a._comment b/doc/devblog/day_418__concurrent_externals/comment_6_ea5d42bcb03af937a604119039f9073a._comment
new file mode 100644
index 0000000000..cb7a23ccec
--- /dev/null
+++ b/doc/devblog/day_418__concurrent_externals/comment_6_ea5d42bcb03af937a604119039f9073a._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2016-10-05T15:32:15Z"
+ content="""
+@Adam adding a concurrency setting to the assistant would indeed be nice.
+"""]]
diff --git a/doc/devblog/day_419__catching_up.mdwn b/doc/devblog/day_419__catching_up.mdwn
new file mode 100644
index 0000000000..90e0da1ff9
--- /dev/null
+++ b/doc/devblog/day_419__catching_up.mdwn
@@ -0,0 +1,23 @@
+Several bug fixes today and got caught up on most recent messages. Backlog
+is 157.
+
+The most significant one prevents git-annex from reading in the whole
+content of a large git object when it wants to check if it's an annex
+symlink. In several situations where large files were committed to git, or
+staged, git-annex could do a lot of work, and use a lot of memory and maybe
+crash. Fixed by checking the size of an object before asking 
+`git cat-file` for its content.
+
+Also a couple of improvements around versions and upgrading. IIRC git-annex
+used to only support one repository version at a time, but this was changed
+to support V6 as an optional upgrade from V5, and so the supported versions
+became a list. Since V3 repositories are identical to V5 other than the
+version, I added it to the supported version list, and any V3 repos out
+there can be used without upgading. Particularly useful if they're on
+read-only media.
+
+And, there was a bug in the automatic upgrading of a remote that caused it
+to be upgraded all the way to V6. Now it will only be upgraded to V5.
+
+Today's work was sponsored by Jake Vosloo on
+[Patreon](https://patreon.com/joeyh/).
diff --git a/doc/devblog/day_41__onward.mdwn b/doc/devblog/day_41__onward.mdwn
new file mode 100644
index 0000000000..fd393b7340
--- /dev/null
+++ b/doc/devblog/day_41__onward.mdwn
@@ -0,0 +1,17 @@
+I think that git-recover-repository is ready now. Made it deal with the
+index file referencing corrupt objects. The best approach I could think of
+for that is to just remove those objects from the index, so the user can
+re-add files from their work tree after recovery.
+
+Now to integrate this git repository repair capability into the git-annex 
+assistant. I decided to run `git fsck` as part of a scheduled
+repository consistency check. It may also make sense for the assistant to
+notice when things are going wrong, and suggest an immediate check. I've
+started on the webapp UI to run a repository repair when fsck detects
+problems.
+
+[[!img /assistant/brokenrepositoryalert.png]]
+
+[[!img /assistant/repairrepository.png]]
+
+[[!meta title="the user interface I hope noone ever sees"]]
diff --git a/doc/devblog/day_41__onward/comment_1_a716c7b5a9ea3c949ff047cfb4e9a0a4._comment b/doc/devblog/day_41__onward/comment_1_a716c7b5a9ea3c949ff047cfb4e9a0a4._comment
new file mode 100644
index 0000000000..0457a4bf04
--- /dev/null
+++ b/doc/devblog/day_41__onward/comment_1_a716c7b5a9ea3c949ff047cfb4e9a0a4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="aarone"
+ ip="2607:f470:8:d008:290:f5ff:fec3:a9e6"
+ subject="Email alert"
+ date="2013-10-22T21:23:24Z"
+ content="""
+I have at least one git-annex repository where I seldom open the web UI, but rather have the assistant humming along in the background.  I think for my use case it would be best to receive an email notification that the assistant had detected a problem, which would prompt me to open the web UI and perform the recovery.
+"""]]
diff --git a/doc/devblog/day_41__onward/comment_2_33149e424cd5f03fac376288bcc4dfdc._comment b/doc/devblog/day_41__onward/comment_2_33149e424cd5f03fac376288bcc4dfdc._comment
new file mode 100644
index 0000000000..fd26f92903
--- /dev/null
+++ b/doc/devblog/day_41__onward/comment_2_33149e424cd5f03fac376288bcc4dfdc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="excellent idea"
+ date="2013-10-22T22:13:58Z"
+ content="""
+Added to my todo. I think it would require the system have an MTA though, I really don't want git-annex to grow to the point it can send email. ;)
+"""]]
diff --git a/doc/devblog/day_41__onward/comment_3_3b07503bd79089ad3ce3ddd7535ed116._comment b/doc/devblog/day_41__onward/comment_3_3b07503bd79089ad3ce3ddd7535ed116._comment
new file mode 100644
index 0000000000..1116b4d1b0
--- /dev/null
+++ b/doc/devblog/day_41__onward/comment_3_3b07503bd79089ad3ce3ddd7535ed116._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://jasonwoof.com/"
+ nickname="JasonWoof"
+ subject="Please check if it needs help from the user first"
+ date="2013-10-23T23:30:10Z"
+ content="""
+Awesome that you're working on recovery, and recovery automation!
+
+Please only bother the user if there is a serious problem _and_ it can't be fixed without their help. Otherwise I fear people will learn to ignore your dialog boxes, like they do most dialog boxes. If you want to notify your user that some hard drive corruption happened (and it's been fixed already) then put a little yellow/orange line across somewhere with a warning message.
+
+When I read to the part about how it can (probably) be fixed automatically, I got a flash of annoyance and thought \"well, then fix it automatically, why are you bothering me?\"
+
+Please (if you aren't already) check if it can be automatically fixed without help from the user before telling the user about it. Then you can say \"The data to fix this could not be reached, please plug in another repo or something.\"
+"""]]
diff --git a/doc/devblog/day_420__delayed_debugging.mdwn b/doc/devblog/day_420__delayed_debugging.mdwn
new file mode 100644
index 0000000000..8ab3ecd972
--- /dev/null
+++ b/doc/devblog/day_420__delayed_debugging.mdwn
@@ -0,0 +1,17 @@
+Over a month ago, I had some reports that syncing into adjusted branches
+was losing some files that had been committed. I couldn't reproduce it, but
+IIRC both felix and tbm reported problems in this area. And, felix kindly
+sent me enough of his git repo to hopefully reproduce it the problem.
+
+Finally got back to that today. Luckily, I *was* able to reproduce the bug
+using felix's repo. The bug only occurs when there's a change deep in a
+tree of an adjusted branch, and not always then. After staring at it for a
+couple of hours, I finally found the problem; a modification flag was not
+getting propagated in this case, and some changes made deep in the tree
+were not getting included into parent trees.
+
+So, I think I've fixed it, but need to look at it some more to be sure, and
+develop a test case. And fixing that exposed another bug in the same code.
+Gotta run unfortunately, so will finish this tomorrow..
+
+Today's work was sponsored by Riku Voipio.
diff --git a/doc/devblog/day_421__lost_in_the_trees.mdwn b/doc/devblog/day_421__lost_in_the_trees.mdwn
new file mode 100644
index 0000000000..1cb09b63da
--- /dev/null
+++ b/doc/devblog/day_421__lost_in_the_trees.mdwn
@@ -0,0 +1,6 @@
+Finished up where I left off yesterday, writing test cases and fixing
+bugs with syncing in adjusted branches. While adjusted branches need v6
+mode, and v6 mode is still considered experimental, this is still a rather
+nasty bug, since it can make files go missing (though still available
+in git history of course). So, planning to release a new version with these
+fixes as soon as the autobuilders build it.
diff --git a/doc/devblog/day_422__bugfixes_for_v6_mode.mdwn b/doc/devblog/day_422__bugfixes_for_v6_mode.mdwn
new file mode 100644
index 0000000000..3cd7bc35b9
--- /dev/null
+++ b/doc/devblog/day_422__bugfixes_for_v6_mode.mdwn
@@ -0,0 +1,16 @@
+Several bug fixes involving v6 unlocked files today. Several related bugs
+were caused by relying on the inode cache information, without a fallback
+to handle the case where the inode cache had not gotten updated. While the
+inode cache is generally kept up-to-date well by the smudge/clean
+filtering, it is just a cache and can be out of date. Did some auditing for
+such problems and hopefully I've managed to find them all.
+
+Also, there was a tricky upgrade case where a v5 repository contained a
+v6 unlocked file, and the annexed content got copied into it. This
+triggered the above-described bugs, and in this case the worktree needs
+to be updated on upgrade, to replace the pointer file with the content.
+
+As I caught up with recent activity, it was nice to see some contributions
+from others. James MacMahon sent in a patch to improve the filenames
+generated by `importfeed`. And, xloem is writing workflow documentation for
+git-annex in [[todo/Workflow_guide]].
diff --git a/doc/devblog/day_423__ssh_fun.mdwn b/doc/devblog/day_423__ssh_fun.mdwn
new file mode 100644
index 0000000000..1fe12bc368
--- /dev/null
+++ b/doc/devblog/day_423__ssh_fun.mdwn
@@ -0,0 +1,19 @@
+Made a significant change today: Enabled automatic retrying of transfers
+that fail. It's only done if the previous try managed to advance the
+progress by some amount. The assistant has already had that retrying for
+many years, but now it will also be done when using git-annex at the
+command line.
+
+One good reason for a transfer to fail and need a retry is when the network
+connection stalls. You'd think that TCP keepalives would detect this kind
+of thing and kill the connection but I've had enough complaints, that I
+suppose that doesn't always work or gets disabled. Ssh has a
+ServerAliveInterval that detects such stalls nicely for the kind of batch
+transfers git-annex uses ssh for, but it's not enabled by default. So I
+found a way to make git-annex enable it, while still letting ~/.ssh/config
+settings override that.
+
+Also got back to analizing an old bug report about proliferating
+".nfs*.lock" files when using git-annex on nfs; this was caused by the
+wacky NFS behavior of renaming deleted files, and I found a change to the
+ssh connection caching cleanup code that should avoid the problem.
diff --git a/doc/devblog/day_424__the_dog.mdwn b/doc/devblog/day_424__the_dog.mdwn
new file mode 100644
index 0000000000..0c117a8563
--- /dev/null
+++ b/doc/devblog/day_424__the_dog.mdwn
@@ -0,0 +1,11 @@
+[[!meta title="the dog that didn't bark"]]
+
+Worked on several bug reports today, fixing some easy ones, and following
+up on others. And then there are the hard bugs.. Very pleased that I was
+able to eventually reproduce a bug based entirely on the information
+that git-annex's output did not include a filename. Didn't quite get that
+bug fixed though.
+
+At the end of the day, got a bug report that `git annex add` of filenames
+containing spaces has broken. This is a recent reversion and I'm pushing
+out a release with a fix ASAP.
diff --git a/doc/devblog/day_425__tor.mdwn b/doc/devblog/day_425__tor.mdwn
new file mode 100644
index 0000000000..08fe21cdd5
--- /dev/null
+++ b/doc/devblog/day_425__tor.mdwn
@@ -0,0 +1,23 @@
+Have waited too long for some next-generation encrypted P2P network, like
+telehash to emerge. Time to stop waiting; tor hidden services are not as
+cutting edge, but should work. Updated the [[design|design/assistant/telehash]]
+and started implementation in the `tor` branch.
+
+Unfortunately, Tor's default configuration does not enable the ControlPort.
+And, changing that in the configuration could be problimatic. This
+makes it harder than it ought to be to register a tor hidden service.
+So, I implemented a `git annex enable-tor` command, which can be run as root
+to set it up. The webapp will probably use `su-to-root` or `gksu` to run it. 
+There's some Linux-specific parts in there, and it uses a socket for
+communication between tor and the hidden service, which may cause problems
+for Windows porting later.
+
+Next step will be to get `git annex remotedaemon` to run as a tor hidden
+service.
+
+Also made a `no-xmpp` branch which removes xmpp support from the assistant.
+That will remove 3000 lines of code when it's merged. Will probably wait
+until after tor hidden services are working.
+
+Today's work was sponsored by Jake Vosloo on
+[Patreon](https://www.patreon.com/joeyh/).
diff --git a/doc/devblog/day_425__tor/comment_1_1dd41fa32eb3867d764f3238005b5b81._comment b/doc/devblog/day_425__tor/comment_1_1dd41fa32eb3867d764f3238005b5b81._comment
new file mode 100644
index 0000000000..fe609cab01
--- /dev/null
+++ b/doc/devblog/day_425__tor/comment_1_1dd41fa32eb3867d764f3238005b5b81._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ avatar="http://cdn.libravatar.org/avatar/7003e967f47003bae82966aa373de8ef"
+ subject="comment 1"
+ date="2016-11-15T18:01:18Z"
+ content="""
+…or `pkexec`, which is present on many systems and generally integrates better with whatever DE/non-DE the user may be running.
+
+(OTOH, pkexec does not set up X11 access – then again, root helpers shouldn't need it.)
+"""]]
diff --git a/doc/devblog/day_426__grab_bag.mdwn b/doc/devblog/day_426__grab_bag.mdwn
new file mode 100644
index 0000000000..36e32077ee
--- /dev/null
+++ b/doc/devblog/day_426__grab_bag.mdwn
@@ -0,0 +1,63 @@
+Fixed one howler of a bug today. Turns out that
+`git annex fsck --all --from remote` didn't actually check the content of
+the remote, but checked the local repository. Only `--all` was buggy;
+`git annex fsck --from remote` was ok. Don't think this is crash priority
+enough to make a release for, since only `--all` is affected.
+
+Somewhat uncomfortably made `git annex sync` pass
+`--allow-unrelated-histories` to git merge. While I do think that git's
+recent refusal to merge unrelated histories is good in general, the
+problem is that initializing a direct mode repository involves making an
+empty commit. So merging from a remote into such a direct mode repository
+means merging unrelated histories, while an indirect mode repository doesn't.
+Seems best to avoid such inconsistencies, and the only way I could see to
+do it is to always use `--allow-unrelated-histories`. May revisit this once
+direct mode is finally removed.
+
+Using the git-annex arm standalone bundle on some WD NAS boxes used to
+work, and then it seems they changed their kernel to use a nonstandard page
+size, and broke it. This actually seems to be a 
+[bug in the gold linker](http://bugs.debian.org/844467), which defaults to an
+unncessarily small page size on arm. The git-annex arm bundle is being
+adjusted to try to deal with this.
+
+ghc 8 made `error` include some backtrace information. While it's really
+nice to have backtraces for unexpected exceptions in Haskell, it turns
+out that git-annex used `error` a lot with the intent of showing an error
+message to the user, and a backtrace clutters up such messages. So,
+bit the bullet and checked through every `error` in git-annex and made such
+ones not include a backtrace.
+
+Also, I've been considering what protocol to use between git-annex nodes
+when communicating over tor. One way would be to make it very similar to
+`git-annex-shell`, using rsync etc, and possibly reusing code from
+git-annex-shell. However, it can take a while to make a connection across
+the tor network, and that method seems to need a new connection for each
+file transfered etc. Also thought about using a http based protocol. The
+servant library is great for that, you get both http client and server
+implementations almost for free. Resuming interrupted transfers might
+complicate it, and the hidden service side would need to listen on a unix
+socket, instead of the regular http port. It might be worth it to use http
+for tor, if it could be reused for git-annex http servers not on the tor
+network. But, then I'd have to make the http server support git pull and
+push over http in a way that's compatable with how git uses http, including
+authentication. Which is a whole nother ball of complexity. So, I'm leaning
+instead to using a simple custom protocol something like:
+
+		> AUTH $localuuid $token
+		< AUTH-SUCCESS $remoteuuid
+		> SENDPACK $length
+		> $gitdata
+		< RECVPACK $length
+		< $gitdata
+		> GET $pos $key
+		< DATA $length
+		< $bytes
+		> SUCCESS
+		> PUT $key
+		< PUT-FROM $pos
+		> DATA $length
+		> $bytes
+		< SUCCESS
+
+Today's work was sponsored by Riku Voipio.
diff --git a/doc/devblog/day_426__grab_bag/comment_1_4d01c756850032d351fa99188a3301a7._comment b/doc/devblog/day_426__grab_bag/comment_1_4d01c756850032d351fa99188a3301a7._comment
new file mode 100644
index 0000000000..7b5a2949a9
--- /dev/null
+++ b/doc/devblog/day_426__grab_bag/comment_1_4d01c756850032d351fa99188a3301a7._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://anarc.at/openid/"
+ nickname="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/b36dcf65657dd36128161355d8920a99503def9461c1bb212410980fe6f07125"
+ subject="how about reusing the special remote protocol?"
+ date="2016-11-16T21:58:08Z"
+ content="""
+git-annex already has a custom protocol detailed in [[design/external_special_remote_protocol]]. it could be quite useful to have that protocol extended to support direct object transfer instead of having to mess around with temporary files like may remotes do, for example...
+
+maybe that makes no sense at all, i don't know. :) --[[anarcat]]
+"""]]
diff --git a/doc/devblog/day_427__free_p2p.mdwn b/doc/devblog/day_427__free_p2p.mdwn
new file mode 100644
index 0000000000..7c727587b1
--- /dev/null
+++ b/doc/devblog/day_427__free_p2p.mdwn
@@ -0,0 +1,51 @@
+For a Haskell programmer, and day where a big thing is implemented
+without the least scrap of code that touches the IO monad is a good day.
+And this was a good day for me!
+
+Implemented the p2p protocol for tor hidden services. Its needs are somewhat
+similar to the external special remote protocol, but the two protocols are
+not fully overlapping with one-another. Rather than try to unify them, and
+so complicate both cases, I prefer to reuse as much code as possible between
+separate protocol implementations. The generating and parsing of messages
+is largely shared between them. I let the new p2p protocol otherwise
+develop in its own direction.
+
+But, I *do* want to make this p2p protocol reusable for other types of p2p
+networks than tor hidden services. This was an opportunity to use the Free
+monad, which I'd never used before. It worked out great, letting me write
+monadic code to handle requests and responses in the protocol, that reads
+the content of files and resumes transfers and so on, all independent
+of any concrete implementation.
+
+The whole implementation of the protocol only needed 74 lines of monadic code.
+It helped that I was able to factor out functions like this one, that is used
+both for handling a download, and by the remote when an upload is sent to it:
+
+	receiveContent :: Key -> Offset -> Len -> Proto Bool
+	receiveContent key offset len = do
+	        content <- receiveBytes len
+	        ok <- writeKeyFile key offset content
+	        sendMessage $ if ok then SUCCESS else FAILURE
+	        return ok
+
+To get transcripts of the protocol in action, the Free monad can be evaluated
+purely, providing the other side of the conversation:
+
+	ghci> putStrLn $ protoDump $ runPure (put (fromJust $ file2key "WORM--foo")) [PUT_FROM (Offset 10), SUCCESS]
+	> PUT WORM--foo
+	< PUT-FROM 10
+	> DATA 90
+	> bytes
+	< SUCCESS
+	result: True
+
+	ghci> putStrLn $ protoDump $ runPure (serve (toUUID "myuuid")) [GET (Offset 0) (fromJust $ file2key "WORM--foo")]
+	< GET 0 WORM--foo
+	> PROTO-ERROR must AUTH first
+	result: ()
+
+Am very happy with all this pure code and that I'm finally using Free monads.
+Next I need to get down the the dirty business of wiring this up to
+actual IO actions, and an actual network connection.
+
+Today's work was sponsored by Jake Vosloo on Patreon.
diff --git a/doc/devblog/day_428-429__git_push_to_hiddden_service.mdwn b/doc/devblog/day_428-429__git_push_to_hiddden_service.mdwn
new file mode 100644
index 0000000000..ec1bf12fd4
--- /dev/null
+++ b/doc/devblog/day_428-429__git_push_to_hiddden_service.mdwn
@@ -0,0 +1,31 @@
+The `tor` branch is coming along nicely.
+
+This weekend, I continued working on the P2P protocol, implementing
+it for network sockets, and extending it to support connecting up
+git-send-pack/git-receive-pack. 
+
+There was a bit of a detour when I split the Free monad into two separate
+ones, one for Net operations and the other for Local filesystem operations.
+
+This weekend's work was sponsored by Thomas Hochstein on Patreon.
+
+----
+
+Today, implemented a `git-remote-tor-annex` command that git will
+use for tor-annex:: urls,  and made `git annex remotedaemon`
+serve the tor hidden service.
+
+Now I have git push/pull working to the hidden service, for example:
+
+	git pull tor-annex::eeaytkuhaupbarfi.onion:47651
+
+That works very well, but does not yet check that the user is authorized
+to use the repo, beyond knowing the onion address. And currently
+it only works in git-annex repos; with some tweaks it should
+also work in plain git repos.
+
+Next, I need to teach git-annex how to access tor-annex remotes.
+And after that, an interface in the webapp for setting them up and
+connecting them together.
+
+Today's work was sponsored by Josh Taylor on Patreon.
diff --git a/doc/devblog/day_42__repair_milestone.mdwn b/doc/devblog/day_42__repair_milestone.mdwn
new file mode 100644
index 0000000000..61a1bea279
--- /dev/null
+++ b/doc/devblog/day_42__repair_milestone.mdwn
@@ -0,0 +1,35 @@
+The webapp now fully handles repairing damage to the repository.
+
+Along with all the git repository repair stuff already built, I added
+additional repairs of the git-annex branch and git-annex's index file.
+That was pretty easy actually, since git-annex already handles merging
+git-annex branches that can sometimes be quite out of date. So when git repo
+repair has to throw away recent changes to the git-annex branch, it just
+effectively becomes out of date. Added a `git annex fsck --fast` run to
+ensure that the git-annex branch reflects the current state of the
+repository.
+
+When the webapp runs a repair, it first stops the assistant from committing
+new files. Once the repair is done, that's started back up, and it runs a
+startup scan, which is just what is needed in this sitation; it will add
+any new files, as well as any old files that the git repository damange
+caused to be removed from the index.
+
+Also made `git annex repair` run the git repository repair code, 
+for those with a more command-line bent. It can be used in non-git-annex
+repos too!
+
+----
+
+So, I'm nearly ready to wrap up working on disaster recovery. Lots has been
+accomplished this month. And I have put off making a release for entirely
+too long!
+
+The big missing piece is repair of git remotes located on removable drive.
+I may make a release before adding that, but removable drives are probably
+where git repository corruption is most likely to occur, so I certainly
+need to add that.
+
+----
+
+Today's work was sponsored by Scott Robinson.
diff --git a/doc/devblog/day_430__tor_socket_problem.mdwn b/doc/devblog/day_430__tor_socket_problem.mdwn
new file mode 100644
index 0000000000..7e7c8d1bd0
--- /dev/null
+++ b/doc/devblog/day_430__tor_socket_problem.mdwn
@@ -0,0 +1,13 @@
+Debian's tor daemon is very locked down in the directories it can read
+from, and so I've had a hard time finding a place to put the unix socket
+file for git-annex's tor hidden service. Painful details in 
+<http://bugs.debian.org/846275>. At least for now, I'm putting it under
+/etc/tor/, which is probably a FHS violation, but seems to be the only
+option that doesn't involve a lot of added complexity.
+
+--- 
+
+The Windows autobuilder is moving, since
+[NEST](http://nest-initiative.org/) is shutting down the server it has been
+using. Yury Zaytsev has set up a new Windows autobuilder, hosted at
+Dartmouth College this time.
diff --git a/doc/devblog/day_431__p2p_linking.mdwn b/doc/devblog/day_431__p2p_linking.mdwn
new file mode 100644
index 0000000000..1e53ffefc3
--- /dev/null
+++ b/doc/devblog/day_431__p2p_linking.mdwn
@@ -0,0 +1,27 @@
+Today I finished the second-to-last big missing peice for tor hidden service
+remotes. Networks of these remotes are P2P networks, and there needs to be
+a way for peers to find one-another, and to authenticate with one-another.
+The `git annex p2p` command sets up links between peers in such a network.
+
+So far it has only a basic interface that sets up a one way link between
+two peers. In the first repository, run `git annex p2p --gen-address`.
+That outputs a long address. In the second repository, run
+`git annex p2p --link peer1`, and paste the address into it. That sets up a
+git remote named "peer1" that connects back to the first repository over tor.
+
+That is a one-directional link, while a bi-directional link would be
+much more convenient to have between peers. Worse, the address can be reused by
+anyone who sees it, to link into the repository. And, the address is far
+too long to communicate in any way except for pasting it.
+
+So I want to improve that later. What I'd really like to have is an
+interface that displays a one-time-use phrase of five to ten words, that
+can be read over the phone or across the room. Exchange phrases with a
+friend, and get your repositories securely linked together with tor.
+
+But, `git annex p2p` is good enough for now. I can move on to the final
+keystone of the tor support, which is file transfer over tor.
+That should, fingers crossed, be relatively easy, and the `tor` branch is
+close to mergeable now.
+
+Today's work was sponsored by Riku Voipio.
diff --git a/doc/devblog/day_431__p2p_linking/comment_1_1d5f809564c25e765f82594af8e174ab._comment b/doc/devblog/day_431__p2p_linking/comment_1_1d5f809564c25e765f82594af8e174ab._comment
new file mode 100644
index 0000000000..9eceb71edb
--- /dev/null
+++ b/doc/devblog/day_431__p2p_linking/comment_1_1d5f809564c25e765f82594af8e174ab._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="https://anarc.at/openid/"
+ nickname="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/b36dcf65657dd36128161355d8920a99503def9461c1bb212410980fe6f07125"
+ subject="magic wormhole"
+ date="2016-11-30T22:16:19Z"
+ content="""
+> What I'd really like to have is an interface that displays a
+> one-time-use phrase of five to ten words, that can be read over the
+> phone or across the room. Exchange phrases with a friend, and get
+> your repositories securely linked together with tor.
+
+I already mentionned the project in [[design/assistant/telehash/]],
+but [magic-wormhole](https://github.com/warner/magic-wormhole) does
+exactly that:
+
+    % wormhole send README.md
+    Sending 7924 byte file named 'README.md'
+    On the other computer, please run: wormhole receive
+    Wormhole code is: 7-crossover-clockwork
+    
+    Sending (<-10.0.1.43:58988)..
+    100%|=========================| 7.92K/7.92K [00:00<00:00, 6.02MB/s]
+    File sent.. waiting for confirmation
+    Confirmation received. Transfer complete.
+
+Receiver:
+
+    % wormhole receive
+    Enter receive wormhole code: 7-crossover-clockwork
+    Receiving file (7924 bytes) into: README.md
+    ok? (y/n): y
+    Receiving (->tcp:10.0.1.43:58986)..
+    100%|===========================| 7.92K/7.92K [00:00<00:00, 120KB/s]
+    Received file written to README.md
+
+While that example shows a file transfer, arbitrary data can be
+transfered this way. There's a documented protocol, and it's not
+completely peer-to-peer: there are relay servers to deal with NAT'd
+machines. But the [PAKE
+protocol](https://en.wikipedia.org/wiki/Password-authenticated_key_agreement)
+(basically SPAKE2) could be a good inspiration here.
+
+Otherwise, I must say that, as a user, I don't mind copy-pasting a
+hidden service string (if that's what it's about): i can do that over
+a secure medium (email + OpenPGP or IM + OTR) easily... But I
+understand it can be difficult to do for new users.
+
+"""]]
diff --git a/doc/devblog/day_432-433__almost_there.mdwn b/doc/devblog/day_432-433__almost_there.mdwn
new file mode 100644
index 0000000000..b41ce3f701
--- /dev/null
+++ b/doc/devblog/day_432-433__almost_there.mdwn
@@ -0,0 +1,13 @@
+Friday and today were spent implementing both sides of the P2P protocol for
+git-annex content transfers.
+
+There were some tricky cases to deal with. For example, when a file is being
+sent from a direct mode repository, or v6 annex.thin repository, the
+content of the file can change as it's being transferred. Including being
+appended to or truncated. Had to find a way to deal with that, to avoid
+breaking the protocol by not sending the indicated number of bytes of data.
+
+It all seems to be done now, but it's not been tested at all, and there are
+probably some bugs to find. (And progress info is not wired up yet.)
+
+Today's work was sponsored by Trenton Cronholm on Patreon.
diff --git a/doc/devblog/day_434__it_works.mdwn b/doc/devblog/day_434__it_works.mdwn
new file mode 100644
index 0000000000..75d096b31c
--- /dev/null
+++ b/doc/devblog/day_434__it_works.mdwn
@@ -0,0 +1,27 @@
+Git annex transfers over Tor worked correctly the first time I tried them
+today. I had been expecting protocol implementation bugs, so this was a
+nice surprise!
+
+Of course there were some bugs to fix. I had forgotten to add UUID
+discovery to `git annex p2p --link`. And, resuming interrupted transfers
+was buggy.
+
+Spent some time adding progress updates to the Tor remote. I was curious to
+see what speed transfers would run. Speed will of course vary depending on
+the Tor relays being used, but this example with a 100 mb file is not bad:
+
+	copy big4 (to peer1...) 
+	62%          1.5MB/s 24s
+
+There are still a couple of [[known bugs|todo/tor]], 
+but I've merged the `tor` branch into `master` already.
+
+----
+
+Alpernebbi has built a GUI for editing git-annex metadata.
+Something I always wanted!  
+[[Read about it here|tips/a_gui_for_metadata_operations]]
+
+----
+
+Today's work was sponsored by Ethan Aubin.
diff --git a/doc/devblog/day_435-436_post_tor_merge.mdwn b/doc/devblog/day_435-436_post_tor_merge.mdwn
new file mode 100644
index 0000000000..2f05e02521
--- /dev/null
+++ b/doc/devblog/day_435-436_post_tor_merge.mdwn
@@ -0,0 +1,20 @@
+More improvements to tor support. Yesterday, debugged a reversion that
+broke push/pull over tor, and made actual useful error messages be
+displayed when there were problems. Also fixed a memory leak, although I
+fixed it by reorganizing code and could not figure out quite why it happened,
+other than that the ghc runtime was not managing to be as lazy as I would
+expect. 
+
+Today, added git ref change notification to the
+P2P protocol, and made the remotedaemon automatically fetch changes from
+tor remotes. So, it should work to use the assistant to keep
+repositories in sync over tor. I have not tried it yet, and linking over tor
+still needs to be done at the command line, so it's not really ready for
+webapp users yet.
+
+Also fixed a denial of service attack in git-annex-shell and git-annex when
+talking to a remote git-annex-shell. It was possible to feed either a large
+amount of data when they tried to read a line of data, and summon the OOM
+killer. Next release will be expedited some because of that.
+
+Today's work was sponsored by Thomas Hochstein on Patreon.
diff --git a/doc/devblog/day_437__catching_up.mdwn b/doc/devblog/day_437__catching_up.mdwn
new file mode 100644
index 0000000000..1deb54459c
--- /dev/null
+++ b/doc/devblog/day_437__catching_up.mdwn
@@ -0,0 +1,20 @@
+Quite a backlog developed in the couple of weeks I was concentrating on tor
+support. I've taken a first pass through it and fixed the most pressing
+issues now. 
+
+Most important was an ugly memory corruption problem in the GHC runtime
+system that may have led to data corruption when using git-annex with Linux
+kernels older than 4.5. All the Linux standalone builds of git-annex have
+been updated to fix that issue.
+
+Today dealt with several more things, including fixing a buggy timestamp
+issue with `metadata --batch`, reverting the ssh ServerAliveInterval
+setting (broke on too many systems with old ssh or complicated ssh
+configurations), making batch input not be rejected when it can't be decoded
+as UTF-8, and more.
+
+Also, spent some time learning a little bit about Magic Wormhole and SPAKE,
+as a way to exchange tor remote addresses. Using Magic Wormhole for that
+seems like a reasonable plan. I did file a couple bugs on it which will
+need to get fixed, and then using it is mostly a question of whether it's
+easy enough to install that git-annex can rely on it.
diff --git a/doc/devblog/day_438__bi-directional_p2p_links.mdwn b/doc/devblog/day_438__bi-directional_p2p_links.mdwn
new file mode 100644
index 0000000000..abcbed1229
--- /dev/null
+++ b/doc/devblog/day_438__bi-directional_p2p_links.mdwn
@@ -0,0 +1,6 @@
+Improved `git annex p2p --link` to create a bi-directional link
+automatically. Bi-directional links are desirable more often than not, so
+it's the default behavior.
+
+Also continued thinking about using magic wormhole for communicating
+p2p addresses for pairing. And filed some more bugs on magic wormhole.
diff --git a/doc/devblog/day_439__wormhole_pairing.mdwn b/doc/devblog/day_439__wormhole_pairing.mdwn
new file mode 100644
index 0000000000..cc988a2db3
--- /dev/null
+++ b/doc/devblog/day_439__wormhole_pairing.mdwn
@@ -0,0 +1,51 @@
+`git annex p2p --pair` implemented, using Magic Wormhole codes
+that have to be exchanged between the repositories being paired.
+
+It looks like this, with the same thing being done at the same time
+in the other repository.
+
+	joey@elephant:~/tmp/bench3/a>git annex p2p --pair
+	p2p pair peer1 (using Magic Wormhole) 
+	
+	This repository's pairing code is: 1-select-bluebird
+	
+	Enter the other repository's pairing code: (here I entered 8-fascinate-sawdust) 
+	Exchanging pairing data...
+	Successfully exchanged pairing data. Connecting to peer1...
+	ok
+
+And just that simply, the two repositories find one another, 
+Tor onion addresses and authentication data is exchanged, and a git remote
+is set up connecting via Tor.
+
+	joey@elephant:~/tmp/bench3/a>git annex sync peer1
+	commit  
+	ok
+	pull peer1 
+	warning: no common commits
+	remote: Counting objects: 5, done.
+	remote: Compressing objects: 100% (3/3), done.
+	remote: Total 5 (delta 0), reused 0 (delta 0)
+	Unpacking objects: 100% (5/5), done.
+	From tor-annex::5vkpoyz723otbmzo.onion:61900
+	 * [new branch]      git-annex  -> peer1/git-annex
+
+Very pleased with this, and also the whole thing worked on the very first
+try!
+
+It might be slightly annoying to have to exchange two codes during pairing.
+It would be possible to make this work with only one code. I decided to go
+with two codes, even though it's only marginally more secure than one,
+mostly for UI reasons. The pairing interface and 
+[[instructions for using it|tips/peer_to_peer_network_with_tor]] is simplfied
+by being symmetric.
+
+(I also decided to revert the work I did on Friday to make `p2p --link`
+set up a bidirectional link. Better to keep `--link` the simplest possible
+primitive, and pairing makes bidirectional links more easily.)
+
+Next: Some more testing of this and the Tor hidden services, a webapp UI
+for P2P peering, and then finally removing XMPP support. I hope to finish
+that by New Years.
+
+Today's work was sponsored by Jake Vosloo on Patreon.
diff --git a/doc/devblog/day_43__bugfix_day.mdwn b/doc/devblog/day_43__bugfix_day.mdwn
new file mode 100644
index 0000000000..ad150f5120
--- /dev/null
+++ b/doc/devblog/day_43__bugfix_day.mdwn
@@ -0,0 +1,26 @@
+Got well caught up on bug fixes and traffic. Backlog is down to 40.
+
+Made the assistant wait for a few seconds before doing the startup
+scan when it's autostarted, since the desktop is often busy starting
+up at that same time.
+
+Fixed an ugly bug with chunked webdav and directory special remotes
+that caused it to not write a "chunkcount" file when storing data,
+so it didn't think the data was present later. I was able to make it
+recover nicely from that mistake, by probing for what chunks are actually
+present.
+
+Several people turn out to have had problems with `git annex sync` not
+working because receive.denyNonFastForwards is enabled. I made the webapp
+not enable it when setting up a ssh repository, and I made `git annex sync`
+print out a hint about this when it's failed to push. (I don't think this
+problem affects the assistant's own syncing.)
+
+Made the assistant try to repair a damaged git repository without
+prompting. It will only prompt when it fails to fetch all the lost
+objects from remotes.
+
+Glad to see that others have managed to 
+[get git-annex to build on Max OS X 10.9](http://git-annex.branchable.com/bugs/git_annex_doesn__39__t_work_in_Max_OS_X_10.9/#comment-8e8ee5e50506a6fde029d236f4809df8). 
+Now I just need someone to offer up a ssh account on that OS, and I could
+set up an autobuilder for it.
diff --git a/doc/devblog/day_440__holidaze.mdwn b/doc/devblog/day_440__holidaze.mdwn
new file mode 100644
index 0000000000..e002d0d157
--- /dev/null
+++ b/doc/devblog/day_440__holidaze.mdwn
@@ -0,0 +1,11 @@
+Have been working on some improvements to `git annex enable-tor`. Made it
+su to root, using any su-like program that's available. And made it test
+the hidden service it sets up, and wait until it's propigated the the Tor
+directory authorities. The webapp will need these features, so I thought I
+might as well add them at the command-line level.
+
+Also some messing about with locale and encoding issues. About most of
+which the less said the better. One significant thing is that I've made the
+filesystem encoding be used for all IO by git-annex, rather than needing to
+explicitly enable it for each file and process. So, there should be much
+less bother with encoding problems going forward.
diff --git a/doc/devblog/day_441__webapp_wormhole_pairing.mdwn b/doc/devblog/day_441__webapp_wormhole_pairing.mdwn
new file mode 100644
index 0000000000..b27723b9dc
--- /dev/null
+++ b/doc/devblog/day_441__webapp_wormhole_pairing.mdwn
@@ -0,0 +1,18 @@
+Added the Magic Wormhole UI to the webapp for pairing Tor remotes.
+This replaces the XMPP pairing UI when using "Share with a friend" 
+and "Share with your other devices" in the webapp.
+
+[[!img assistant/share_with_a_friend_walkthrough/enabletor.png]]
+
+[[!img assistant/share_with_a_friend_walkthrough/wormholepairing.png]]
+
+I have not been able to fully test it yet, and it's part of the `no-xmpp`
+branch until I can.
+
+It's been a while since I worked on the webapp. It was not as hard as I
+remembered to deal with Yesod. The inversion of control involved in coding
+for the web is as annoying as I remembered.
+
+----
+
+Today's work was sponsored by Riku Voipio.
diff --git a/doc/devblog/day_442__xmpp_removal.mdwn b/doc/devblog/day_442__xmpp_removal.mdwn
new file mode 100644
index 0000000000..d66764314f
--- /dev/null
+++ b/doc/devblog/day_442__xmpp_removal.mdwn
@@ -0,0 +1,15 @@
+The webapp's wormhole pairing almost worked perfectly on the first test.
+Turned out the remotedaemon was not noticing that the tor hidden service
+got enabled. After fixing that, it worked perfectly!
+
+So, I've merged that feature, and removed XMPP support from the assistant
+at the same time. If all goes well, the autobuilds will be updated soon,
+and it'll be released in time for new year's.
+
+Anyone who's been using XMPP to keep repositories in sync will need to
+either switch to Tor, or could add a remote on a ssh server to sync by
+instead. See
+<http://git-annex.branchable.com/assistant/share_with_a_friend_walkthrough/>
+for the pointy-clicky way to do it, and
+<http://git-annex.branchable.com/tips/peer_to_peer_network_with_tor/> for
+the command-line way.
diff --git a/doc/devblog/day_442__xmpp_removal/comment_1_22ff11b84f855ab5e6de6dcf2553a050._comment b/doc/devblog/day_442__xmpp_removal/comment_1_22ff11b84f855ab5e6de6dcf2553a050._comment
new file mode 100644
index 0000000000..ccb079ed59
--- /dev/null
+++ b/doc/devblog/day_442__xmpp_removal/comment_1_22ff11b84f855ab5e6de6dcf2553a050._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="Apichat"
+ avatar="http://cdn.libravatar.org/avatar/af7b465d7cd067b9c5acd365bdef92ac"
+ subject="Maintain the XMPP function ?"
+ date="2017-01-05T14:00:34Z"
+ content="""
+Is it realy a good idea to remove now the XMPP function ? While XMPP is a good tool to manage social relations and is getting improve ? [As you say it is an easy way to share with friends](http://joeyh.name/blog/entry/p2p_dreams/)
+
+The lake of use of the XMPP function in Git-annex is may be due to the fact that Git-annex assistant and the XMPP feature are difficult to use on Windows - so 90% of social relations can't exist.
+
+Can't you a least maintain the XMPP function ?
+ 
+XMPP is getting improve a lot those years :
+
+  * Host services, finally we can easily use a host service up to date and with our own domain name :
+    * [[https://account.conversations.im/domain]]
+    * [[https://support-en.mailbox.org/knowledge-base/article/introduction-to-jabber]]
+    * [[https://gultsch.de/compliance_ranked.html]]
+
+  * Protocol Specifications 
+    * [The State of Mobile XMPP in 2016](https://gultsch.de/xmpp_2016.html)
+
+  * Client software :
+    * [[https://conversations.im]]
+    * [[https://jitsi.org]]
+    * [[https://conversejs.org]]
+    * [Tor Messenger](https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger)
+
+  * Server software :
+    * [[https://prosody.im]]
+    * [[https://www.ejabberd.im]]
+    * [Mongoose IM platform](https://www.erlang-solutions.com/products/mongooseim.html)
+
+
+"""]]
diff --git a/doc/devblog/day_442__xmpp_removal/comment_2_eaf64ce3daae790bb27d21887886d73b._comment b/doc/devblog/day_442__xmpp_removal/comment_2_eaf64ce3daae790bb27d21887886d73b._comment
new file mode 100644
index 0000000000..5a5f327bb8
--- /dev/null
+++ b/doc/devblog/day_442__xmpp_removal/comment_2_eaf64ce3daae790bb27d21887886d73b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Apichat"
+ avatar="http://cdn.libravatar.org/avatar/af7b465d7cd067b9c5acd365bdef92ac"
+ subject="OMEMO to encrypt content end to end"
+ date="2017-01-28T11:05:29Z"
+ content="""
+One of your argument for removing XMPP is 
+
+> _it was not entirely secure, since the XMPP server saw the contents of git pushes without encryption_
+
+But since one years there is a new way to encrypt XMPP content end to end : [OMEMO Multi-End Message and Object Encryption](https://conversations.im/omemo/)
+
+> _OMEMO is an XMPP Extension Protocol (XEP) for secure multi-client end-to-end encryption. It is an open standard based on a Double Ratchet and PEP which can be freely used and implemented by anyone. The protocol has been audited by a third party._
+
+Here are other informations : [[https://gultsch.de/talks/omemo.html]]
+
+You can see here the xmpp clients which are using it : [[https://omemo.top]]
+"""]]
diff --git a/doc/devblog/day_443__yes_it_has_been_a_while.mdwn b/doc/devblog/day_443__yes_it_has_been_a_while.mdwn
new file mode 100644
index 0000000000..0af4201257
--- /dev/null
+++ b/doc/devblog/day_443__yes_it_has_been_a_while.mdwn
@@ -0,0 +1,30 @@
+First day working on git-annex in over a month. I've been away preparing
+for and giving two talks at Linux Conf Australia and then recovering from
+conference flu, but am now raring to dive back into git-annex development!
+
+The backlog stood at over 300 messages this morning, and is down to 274 now. So
+still lots of catching up to do. But nothing seems to have blown up badly in my
+absence. The [[tips/antipatterns]] page was a nice development while I was
+away, listing some ways people sometimes find to shoot their feet.
+Read and responded to lots of questions, including one user who mentioned
+a scientific use case: "We are exploring use of git-annex to manage the
+large boundary conditions used within our weather model."
+
+The main bit of coding today was adding a new `git annex config` command.
+This is fairly similar to `git config`, but it stores the settings in the
+git-annex branch, so they're visible in all clones of the repo (aka
+"global"). Not every
+setting will be configurable this way (that would be too expensive, and too
+foot-shooty), but starting with annex.autocommit I plan to enable
+selected settings that make sense to be able to set globally. 
+If you've wanted to be able to configure some part of git-annex in all
+clones of a repository, suggestions are welcome in the
+[todo item about this](https://git-annex.branchable.com/todo/wishlist__58___per-repository_autocommit__61__false/)
+
+`git annex vicfg` can also be used to edit the global settings, and I also
+made it able to edit the global `git annex numcopies` setting which was
+omitted before. There's no real reason to have a separate `git annex
+numcopies` command now, since `git annex config` could configure
+global annex.numcopies.. but it's probably not worth changing that.
+
+Today's work was sponsored by Trenton Cronholm on Patreon.
diff --git a/doc/devblog/day_444__memory_leak_with_a_cold.mdwn b/doc/devblog/day_444__memory_leak_with_a_cold.mdwn
new file mode 100644
index 0000000000..bed714e95d
--- /dev/null
+++ b/doc/devblog/day_444__memory_leak_with_a_cold.mdwn
@@ -0,0 +1,21 @@
+Spent rather too long today tracking down a memory leak in `git annex unused`. 
+Actually, it was three memory leaks; one of them was a reversion introduced
+while otherwise improving a function to not be partial. Another only
+happened in very rare circumstances. The third, which took several more
+hours staring at the code, turned out to simply be an unnecessary use of an
+accumulating list. Feel like I should have seen that one sooner, but then I
+am under the weather and was running profiles in a daze for several hours..
+In the end, `git-annex unused` went from needing 1 gb of memory to 150 mb
+in my big repo.
+
+One advantage to all the profiling though, was I noticed that the `split`
+function was allocating a lot of memory, and seemed generally ineficient. This
+has to do with it splitting on a string; splitting on a single character
+can run twice as fast and churn the GC quite a bit less, so I wrote up a
+specialized version of that, and it's used extensively in git-annex now, so
+it may run up to 50% faster in some cases. Seems like haskell libraries
+with a `split` function should perhaps use the more optimal version
+when splitting on a single character, and I'm going to file bugs to that
+effect.
+
+Today's work was sponsored by Jake Vosloo on Patreon.
diff --git a/doc/devblog/day_445__configs.mdwn b/doc/devblog/day_445__configs.mdwn
new file mode 100644
index 0000000000..148954d507
--- /dev/null
+++ b/doc/devblog/day_445__configs.mdwn
@@ -0,0 +1,11 @@
+Finished the repository-clone-global configuration settings I started
+adding on Monday. Came up with a nice type-driven way to make sure
+that configuration is loaded when needed, and only loaded once.
+Then it was easy to make annex.autocommit be configurable by git-annex
+config. Also added a new annex.synccontent configuration, which can also be
+set by git-annex config.
+
+Also resolved a tricky situation with providing an appid to magic wormhole.
+It will happen on a flag day in 2021. I've marked my calendar..
+
+Today's work was sponsored by Thomas Hochstein on Patreon.
diff --git a/doc/devblog/day_446__quiet_progress.mdwn b/doc/devblog/day_446__quiet_progress.mdwn
new file mode 100644
index 0000000000..87c7c64605
--- /dev/null
+++ b/doc/devblog/day_446__quiet_progress.mdwn
@@ -0,0 +1,14 @@
+Last week I only had energy to work most of each day on git-annex,
+or to blog about it. I chose quiet work. The changelog did grow
+a good amount.
+
+Today, fixed some autobuilder problems, and I am gearing up to add another
+autobuild, targeting arm boxes with older linux kernels, since I got a
+chance to upgrade the arm autobuilder's disk this weekend.
+
+Also, some work on the S3 special remote, and worked around a bug in
+sqlite's handling of umask.
+
+Backlog is down to 243 messages.
+
+Today's work was sponsored by Trenton Cronholm on Patreon.
diff --git a/doc/devblog/day_447__bug_class.mdwn b/doc/devblog/day_447__bug_class.mdwn
new file mode 100644
index 0000000000..c7b3d386c5
--- /dev/null
+++ b/doc/devblog/day_447__bug_class.mdwn
@@ -0,0 +1,48 @@
+When you see a command like "ssh somehost rm -f file", you probably don't
+think that consumes stdin. After all, the `rm -f` doesn't. But, `ssh`
+can pass stdin over the network even if it's not being consumed, and it
+turns out git-annex was bitten by this.
+
+That bug made `git-annex-checkpresentkey --batch` with remote accessed
+over ssh not see all the batch-mode input that was passed into it, because
+ssh sometimes consumed some of it.
+
+Shell scripts using git-annex could also be impacted by the bug, for
+example:
+
+	#!/bin/sh
+	find . -type l -atime 100 | \
+		while read file; do
+			echo "gonna drop $file that has not been used in a while"
+			git annex drop "$file"
+		done
+
+Depending on what remotes `git annex drop` talks to, it might consume
+parts of the output of find.
+
+I've fixed this in git-annex now (using `ssh -n` when running commands
+that are not fed some stdin of their own), but this seems like a class of
+bug that could impact lots of programs that run ssh.
+
+----
+
+I've been thinking about [[simpler_setup_for_remote_worktree_update_on_push]].
+
+One nice way to make a remote update its worktree on push is available
+in recent-ish gits, receive.denyCurrentBranch=updateInstead. That could
+already be used with `git annex sync`, but it hid any error messages
+when pushing the master branch to the remote (since that push fails with
+a large error message in default configurations). Found a way to make
+the error message be displayed when the remote's receive.denyCurrentBranch
+does not have the default configuration.
+
+The remaining problem is that direct mode and adjusted branch remotes
+won't get their works trees updated even when configured that way. I am
+thinking about adding a post-update hook to support those.
+
+----
+
+Also continuing to bring up the ancient kernel arm autobuilder. It's running
+its first build now.
+
+Today's work was sponsored by Riku Voipio.
diff --git a/doc/devblog/day_448__git_push_to_update_remote.mdwn b/doc/devblog/day_448__git_push_to_update_remote.mdwn
new file mode 100644
index 0000000000..edcccc2b7a
--- /dev/null
+++ b/doc/devblog/day_448__git_push_to_update_remote.mdwn
@@ -0,0 +1,24 @@
+Today was all about writing
+[[tips/making_a_remote_repo_update_when_changes_are_pushed_to_it]].
+
+That's a fairly simple page, because I added workarounds for all the
+complexity of making it work in direct mode repos, adjusted branches, and
+repos on filesystems not supporting executable git hooks. Basically,
+the user should be able to set the standard
+receive.denyCurrentBranch=updateInstead configuration on a remote, and 
+then `git push` or `git annex sync` should update that remote's working tree.
+
+There are a couple of unhandled cases; `git push` to a remote on a
+filesystem like FAT won't update it, and `git annex sync` will only update
+it if it's local, not accessed over ssh. Also, the emulation of git's
+updateInstead behavior is not perfect for direct mode repos and adjusted
+branches.
+
+Still, it's good enough that most users should find it meets
+their needs, I hope. How to set this kind of thing up is a fairly common
+FAQ, and this makes it much simpler.
+
+(Oh yeah, the first ancient kernel arm build is *still*
+running. May finish before tomorrow.)
+
+Today's work was sponsored by Jake Vosloo on Patreon.
diff --git a/doc/devblog/day_449__SHA1_break_day.mdwn b/doc/devblog/day_449__SHA1_break_day.mdwn
new file mode 100644
index 0000000000..df70856029
--- /dev/null
+++ b/doc/devblog/day_449__SHA1_break_day.mdwn
@@ -0,0 +1,21 @@
+[The first SHA1 collision](https://shattered.io/) was announced today,
+produced by an identical-prefix collision attack.
+
+After looking into it all day, it does not appear to impact git's security
+immediately, except for targeted attacks against specific projects by
+very wealthy attackers. But we're well past the time when it seemed ok that git
+uses SHA1. If this gets improved into a chosen-prefix collision
+attack, git will start to be rather insecure.
+
+Projects that store binary files in git, that might be worth $100k for an
+attacker to backdoor **should** be concerned by the SHA1 collisions.
+A good example of such a project is
+<git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git>.
+
+Using git-annex (with a suitable backend like SHA256) and signed commits
+together is a good way to secure such repositories. 
+
+Update 12:25 am: However, there are some ways to embed SHA1-colliding data
+in the names of git-annex keys. That makes git-annex with signed
+commits be no more secure than git with signed commits. I am working
+to fix git-annex to not use keys that have such problems.
diff --git a/doc/devblog/day_44__automatic_removable_drive_repair.mdwn b/doc/devblog/day_44__automatic_removable_drive_repair.mdwn
new file mode 100644
index 0000000000..444cf5f2e5
--- /dev/null
+++ b/doc/devblog/day_44__automatic_removable_drive_repair.mdwn
@@ -0,0 +1,16 @@
+Finally got the assistant to repair git repositories on removable drives,
+or other local repos. Mostly this happens entirely automatically, whatever
+data in the git repo on the drive has been corrupted can just be copied
+to it from `~/annex/.git`.
+
+And, the assistant will launch a git fsck of such a repo whenever it fails
+to sync with it, so the user does not even need to schedule periodic fscks.
+Although it's still a good idea, since some git repository problems don't
+prevent syncing from happening.
+
+Watching git annex heal problems like this is quite cool!
+
+One thing I had to defer till later is repairing corrupted gcrypt
+repositories. I don't see a way to do it without deleting all the objects
+in the gcrypt repository, and re-pushing everything. And even doing that
+is tricky, since the `gcrypt-id` needs to stay the same.
diff --git a/doc/devblog/day_450__hardening_against_SHA_attacks.mdwn b/doc/devblog/day_450__hardening_against_SHA_attacks.mdwn
new file mode 100644
index 0000000000..5e419dea7a
--- /dev/null
+++ b/doc/devblog/day_450__hardening_against_SHA_attacks.mdwn
@@ -0,0 +1,13 @@
+Yesterday I said that a git-annex repository using signed commits and SHA2
+backend would be secure from SHA1 collision attacks. Then I noticed that
+there were two ways to embed the necessary collision generation data inside
+git-annex key names. I've fixed both of them today, and cannot find any
+other ways to embed collision generation data in between a signed commit
+and the annexed files.
+
+I also have a design for a way to configure git-annex to expect to see only
+keys using secure hash backends, which will make it easier to work with
+repositories that want to use signed commits and SHA2. Planning to implement
+that tomorrow.
+
+[[todo/sha1_collision_embedding_in_git-annex_keys]] has the details.
diff --git a/doc/devblog/day_451__annex.securehashesonly.mdwn b/doc/devblog/day_451__annex.securehashesonly.mdwn
new file mode 100644
index 0000000000..d0407d0e8e
--- /dev/null
+++ b/doc/devblog/day_451__annex.securehashesonly.mdwn
@@ -0,0 +1,16 @@
+The new annex.securehashesonly config setting prevents annexed content
+that does not use a cryptographically secure hash from being downloaded or
+otherwise added to a repository.
+
+Using that and signed commits prevents SHA1 collisions from causing
+problems with annexed files. See [[tips/using_signed_git_commits]] for
+details about how to use it, and why I believe it makes git-annex
+safe despite git's vulnerability to SHA1 collisions in general.
+
+If you are using git-annex to publish binary files in a repository,
+you should follow the instructions in [[tips/using_signed_git_commits]].
+
+If you're using git to publish binary files, you can improve the security
+of your repository by switchingto git-annex and signed commits.
+
+Today's work was sponsored by Riku Voipio.
diff --git a/doc/devblog/day_452__GIT_SSH.mdwn b/doc/devblog/day_452__GIT_SSH.mdwn
new file mode 100644
index 0000000000..a1ce5cfade
--- /dev/null
+++ b/doc/devblog/day_452__GIT_SSH.mdwn
@@ -0,0 +1,17 @@
+Found a bug in git-annex-shell where verbose messages would sometimes make
+it output things git-annex didn't expect.
+
+While fixing that, I wanted to add a test case, but the test suite actually
+does not test git-annex-shell at all. It would need to ssh, which test
+suites should not do. So, I took a detour..
+
+Support for `GIT_SSH` and `GIT_SSH_COMMAND` has been requested before for
+various reasons. So I implemented that, which took 4 hours. (With one
+little possible compatibility caveat, since git-annex needs to pass the -n
+parameter to ssh sometimes, and git's interface doesn't allow for such a
+parameter.)
+
+Now the test suite can use those environment variables to make mock ssh
+remotes be accessed using local `sh` instead of `ssh`.
+
+Today's work was sponsored by Trenton Cronholm on Patreon.
diff --git a/doc/devblog/day_453_release_prep.mdwn b/doc/devblog/day_453_release_prep.mdwn
new file mode 100644
index 0000000000..8a0a90dadf
--- /dev/null
+++ b/doc/devblog/day_453_release_prep.mdwn
@@ -0,0 +1,13 @@
+Preparing for a release tomorrow. Yury fixed the Windows autobuilder over
+the weekend. The OSX autobuilder was broken by my changes Friday, which
+turned out to have a simple bug that took quite a long time to chase down.
+
+Also added `git annex sync --content-of=path` to sync the contents of files
+in a path, rather than in the whole work tree as `--content` does. I would
+have rather made this be `--content=path` but optparse-applicative 
+[does not support](https://github.com/pcapriotti/optparse-applicative/issues/243)
+options that can be either boolean or have a string value. Really,
+I'd rather `git annex sync path` do it, but that would be ambiguous
+with the remote name parameter.
+
+Today's work was sponsored by Jake Vosloo on Patreon.
diff --git a/doc/devblog/day_454__multicast.mdwn b/doc/devblog/day_454__multicast.mdwn
new file mode 100644
index 0000000000..1972c5ead9
--- /dev/null
+++ b/doc/devblog/day_454__multicast.mdwn
@@ -0,0 +1,15 @@
+Earlier this week I had the opportunity to sit in on a workshop at MIT where
+students were taught how to use git-annex as part of a stack of tools for
+reproducible scientific data research. That was great!
+
+One thing we noticed there is, it can be hard to distribute files to such a
+class; downloading them individually wastes network bandwidth. Today, I
+added [[git annex multicast|git-annex-multicast]] which uses `uftp`
+to multicast files to other clones of a repository on a LAN.
+An "easy" 500 lines of code and 7 hour job.
+
+There is encryption and authentication, but the key management for this
+turned out to be simple, since the public key fingerprints can be stored on
+the git-annex branch, and easily synced around that way. So, I expect
+this should be not hard to use in a classroom setting such as the one
+I was in earlier this week.
diff --git a/doc/devblog/day_454__multicast/comment_1_137ea34cd11004513a03f24955719756._comment b/doc/devblog/day_454__multicast/comment_1_137ea34cd11004513a03f24955719756._comment
new file mode 100644
index 0000000000..5f842eec46
--- /dev/null
+++ b/doc/devblog/day_454__multicast/comment_1_137ea34cd11004513a03f24955719756._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="point to point?"
+ date="2017-03-31T13:08:59Z"
+ content="""
+I wonder: could this be used to send blobs to arbitrary hosts as well? I've been looking at the problem of sharing blobs without sharing the git repository (in [[tips/semi-synchronized_remotes]]), and while we have the tor/wormhole and SSH remotes that can be (ab)used for this purpose, uftp seems like a much better fit, feature-wise.
+
+When you run: `git annex multicast --gen-address; git annex sync`, does the `sync` command exchange git refs over multicast?
+
+When you run: `git annex multicast --send`, will that work for all git-annex blobs, or just the ones that are in the local checkout?
+
+Looking at the [server usage](http://uftp-multicast.sourceforge.net/server_usage.txt), i see that multicast is the default, but that you can also unicast to specific hosts:
+
+       Or in unicast mode:
+
+	    uftp -M host_or_ip file
+
+       Where host_or_ip is the hostname or unicast IP address of the  host  to
+       send to.
+
+       To send only to certain hosts:
+
+	    uftp -H client_id_1,client_id_2,client_id_3 file_to_send
+
+       or:
+
+	    uftp -H @file_containing_list_of_clients file_to_send
+
+Could this be used to send to arbitrary, non-local hosts on the internet?
+
+And how about tor support? Could this simplify the encrypted setup?
+
+This amazing feature just brings up more questions for me, but i'm really glad to see this come. It certainly addresses parts of [[todo/Bittorrent-like_features]], and is probably the first remote that supports bandwidth optimizations for multiple downloads, or rather, in this case, uploads. :)
+
+Thanks so much for your hard work!
+The feature set of git-annex never ceases to amaze me - new features just keep on coming, this is great!
+"""]]
diff --git a/doc/devblog/day_454__multicast/comment_2_09908606fc362cbee516999cd696f718._comment b/doc/devblog/day_454__multicast/comment_2_09908606fc362cbee516999cd696f718._comment
new file mode 100644
index 0000000000..b7b5279498
--- /dev/null
+++ b/doc/devblog/day_454__multicast/comment_2_09908606fc362cbee516999cd696f718._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-04-05T15:20:20Z"
+ content="""
+Multicast is only being used to send git-annex objects around, not git
+objects. There's assumed to be some way to sync git repositories, which is
+how the encryption keys for uftp are distributed.
+
+`git annex multicast --send` operates on files in the working tree.
+It would be possible to make it support `--all`.
+
+I'm not sure if uftp can send outside the local LAN.
+
+It would certianly be possible to have a special remote backed by uftp
+that thus only sends to a single host. Since multicast does not send
+to any particular remote, it did not make sense to implement it
+as a special remote.
+"""]]
diff --git a/doc/devblog/day_455__semi-synchronized.mdwn b/doc/devblog/day_455__semi-synchronized.mdwn
new file mode 100644
index 0000000000..2a53f06bb5
--- /dev/null
+++ b/doc/devblog/day_455__semi-synchronized.mdwn
@@ -0,0 +1,9 @@
+Catching up on some recent backlog after a trip and post-trip flu.
+
+Anarcat wrote up an anlysis of [[tips/semi-synchronized_remotes]], and
+based on that I implemented `remote.<name>.annex-push` and
+`remote.<name>.annex-pull`
+
+Also fixed the Windows build.
+
+Today's work was sponsored by Thomas Hochstein on Patreon.
diff --git a/doc/devblog/day_456__digging_in.mdwn b/doc/devblog/day_456__digging_in.mdwn
new file mode 100644
index 0000000000..024e0b90b8
--- /dev/null
+++ b/doc/devblog/day_456__digging_in.mdwn
@@ -0,0 +1,16 @@
+Digging in to some of the meatier backlog today. Backlog down to 225.
+
+A lot of fixes around using `git annex enableremote` to add new gpg keys to
+a gcrypt special remote. 
+
+Had to make git-annex's use of `GIT_SSH`/`GIT_SSH_COMMAND`
+contingent on `GIT_ANNEX_USE_GIT_SSH=1` being set. Unfortunate, but
+difference from git made at least one existing use of that environment
+variable break, and so it will need to be whitelisted in places where
+git-annex should use it.
+
+Added support for `git annex add --update`
+
+----
+
+Today's work was sponsored by Trenton Cronholm on Patreon.
diff --git a/doc/devblog/day_457__improved_ssh_password_prompting.mdwn b/doc/devblog/day_457__improved_ssh_password_prompting.mdwn
new file mode 100644
index 0000000000..df38304e4e
--- /dev/null
+++ b/doc/devblog/day_457__improved_ssh_password_prompting.mdwn
@@ -0,0 +1,17 @@
+After a month away building [debug-me](https://debug-me.branchable.com/)
+I'm back working on git-annex. I hope debug-me will be useful for debugging
+git-annex in some situations BTW.
+
+Pushed a release yesterday that was mostly changes from back in March.
+It also updated the git bundled with git-annex to fix the recent git-shell
+security hole.
+
+After work on Monday and today, I am caught up with all the recent month's
+backlog, but still have 230 old backlogged messages to get to.
+
+The first consequental thing I got back to was improving ssh password
+prompting when git-annex is running concurrently with -J. It used to start
+up several ssh's at the same time, so connection caching didn't kick in,
+and there could be a bunch of ssh password prompts at the same time. Now
+there will never be more than one ssh password prompt at once, and only one
+prompt per host. (As long as connection caching is enabled.)
diff --git a/doc/devblog/day_458__adeiu_MissingH.mdwn b/doc/devblog/day_458__adeiu_MissingH.mdwn
new file mode 100644
index 0000000000..5d6a7870e8
--- /dev/null
+++ b/doc/devblog/day_458__adeiu_MissingH.mdwn
@@ -0,0 +1,18 @@
+Wasn't planning to, but spent the day making git-annex not depend on the
+MissingH library. This has been a long-term goal, as MissingH pulls in
+several other libraries and is not modern or principled.
+
+The first part was to using cryptonite for MD5 calculation. While
+converting to the form git-annex uses to make hash directories involved
+some math, this did make git-annex garbage-collect less, and
+probably made it faster.
+
+Then I had to write my own progress meter display, since git-annex was
+using MissingH's display. That was fairly simple (73 LoC), and let me
+make it more efficient and tuned for the git-annex use case. As a bonus, it
+got progress displays when transferring files of unknown sizes, which
+wasn't done before.
+
+MissingH was handy training wheels when I was coming over from perl,
+but it's been training wheels on some old cars in the middle of a 
+500 car train for a while, so glad that's over.
diff --git a/doc/devblog/day_459__git_bug.mdwn b/doc/devblog/day_459__git_bug.mdwn
new file mode 100644
index 0000000000..3ec5f167fa
--- /dev/null
+++ b/doc/devblog/day_459__git_bug.mdwn
@@ -0,0 +1,29 @@
+Seems that the recent release of git 2.13.0 contained a reversion that
+broke `git-annex sync` in an adjusted branch. After bisecting git,
+producing a minimal test case, and reporting that to the git developers, I
+was able to work around it in git-annex. The workaround is normally not
+expensive, but could be when a repository has thousands of unpacked refs.
+So I hope this will get fixed in git and I can remove the workaround.
+
+I think I will hurry up the next git-annex release somewhat to get the
+workaround out. It's not a super bad bug, but it does make the test suite
+fail and I've already had 3 people report the problem.
+
+Seems it would be good to have an integration test that runs git-annex's
+test suite against new commits to git. Ævar Arnfjörð Bjarmason has stepped
+up to add that to git's test suite.
+
+----
+
+Also, I dealt with some fallout from removing MissingH; a exponential
+speed blowup in a directory traversal function.
+
+Getting back to the ssh password prompting with -J I was working on last
+week, dealt with the ssh prompt interfering with the regional display
+manager. The fix is not perfect, but good enough; before ssh prompts (and
+only if it prompts), git-annex temporarily clears the regional display.
+Then the display gets redrawn under the ssh output. That needed some
+changes to concurrent-output (which I did over the weekend), so will only
+be done when it's built with a new enough version. A better approach would
+be to save and restore the cursor position, but the ansi-terminal library
+does not yet support that.
diff --git a/doc/devblog/day_45__command_line.mdwn b/doc/devblog/day_45__command_line.mdwn
new file mode 100644
index 0000000000..fa6a7ffc74
--- /dev/null
+++ b/doc/devblog/day_45__command_line.mdwn
@@ -0,0 +1,9 @@
+All command line stuff today..
+
+Added --want-get and --want-drop, which can be used to test preferred content settings
+of a repository. For example `git annex find --in . --want-drop` will list the same
+files that `git annex drop --auto` would try to drop. (Also renamed `git annex content`
+to `git annex wanted`.)
+
+Finally laid to rest problems with `git annex unannex` when multiple files point to the
+same key. It's a lot slower, but I'll stop getting bug reports about that.
diff --git a/doc/devblog/day_460__move_--to_here.mdwn b/doc/devblog/day_460__move_--to_here.mdwn
new file mode 100644
index 0000000000..64cb002853
--- /dev/null
+++ b/doc/devblog/day_460__move_--to_here.mdwn
@@ -0,0 +1,3 @@
+From the why-did-I-never-think-of-that-before department:
+`git annex move --to=here` implemented today. Useful if you want to
+move a file from whatever remotes might contain it to the local repository.
diff --git a/doc/devblog/day_461__shell_completions.mdwn b/doc/devblog/day_461__shell_completions.mdwn
new file mode 100644
index 0000000000..e2bd652fcb
--- /dev/null
+++ b/doc/devblog/day_461__shell_completions.mdwn
@@ -0,0 +1,8 @@
+A new version of optparse-applicative supports zsh and fish shell
+completions. Got that integrated into git-annex, although it will be a
+while until most builds are updated to that version of the library.
+Also, re-submitted my old patch from 2015 to make "git annex<tab>"
+always tab complete in bash.
+
+Enough other small fixes and improvements have accumulated that a release
+is due soon..
diff --git a/doc/devblog/day_462__the_feature_youve_all_been_waiting_for.mdwn b/doc/devblog/day_462__the_feature_youve_all_been_waiting_for.mdwn
new file mode 100644
index 0000000000..dfa4080941
--- /dev/null
+++ b/doc/devblog/day_462__the_feature_youve_all_been_waiting_for.mdwn
@@ -0,0 +1,12 @@
+Have been working on a design for [[design/exporting_trees_to_special_remotes]].
+As well as being handy for publishing scientific data sets out of git-annex
+repositories, that covers long-requested features like
+[[todo/dumb, unsafe, human-readable_backend]].
+
+I had not been optimistic about such requests, which seemed half-baked, but
+Yoh came up with idea of exporting a git treeish, and remembering the last
+exported treeish so a subsequent export can be done incrementally, and can
+fully sync the exported tree.
+
+Please take a look at the design if you've wanted to use git-annex for some
+sort of tree export before, and see if it meets your needs.
diff --git a/doc/devblog/day_462__the_feature_youve_all_been_waiting_for/comment_1_6b13defcdf76691049b9bcd7ec675da6._comment b/doc/devblog/day_462__the_feature_youve_all_been_waiting_for/comment_1_6b13defcdf76691049b9bcd7ec675da6._comment
new file mode 100644
index 0000000000..a4638c14bf
--- /dev/null
+++ b/doc/devblog/day_462__the_feature_youve_all_been_waiting_for/comment_1_6b13defcdf76691049b9bcd7ec675da6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/3ee5cf54-f022-4a71-8666-3c2b5ee231dd"
+ nickname="Anthony DeRobertis"
+ avatar="http://cdn.libravatar.org/avatar/1007bfece547e9f2d86fafa142cd240a62456c37f104a9d96ba9db5bf18e1934"
+ subject="Link broken?"
+ date="2017-07-14T07:37:40Z"
+ content="""
+The link isn't working for me, but found it at [[http://git-annex.branchable.com/design/exporting_trees_to_special_remotes/]]
+"""]]
diff --git a/doc/devblog/day_463-465__back_buggy_external_special_remotes.mdwn b/doc/devblog/day_463-465__back_buggy_external_special_remotes.mdwn
new file mode 100644
index 0000000000..f374a51cb6
--- /dev/null
+++ b/doc/devblog/day_463-465__back_buggy_external_special_remotes.mdwn
@@ -0,0 +1,30 @@
+I'm back working on git-annex after a month away! It's good to be back, and
+I've made some decent improvements this week. 
+
+New features include a `GIT_ANNEX_VECTOR_CLOCK` environment variable that
+may be useful for those using git-annex in a HIPPA compliance setting,
+where timestamps are verboten (but verifying full compliance is up to
+you!), and remote.name.annex-ignore-command and
+remote.name.annex-sync-command configurations that let shell commands be
+run to vary what remotes are used depending on eg, what network it's on.
+
+Also, I took a look at the external special remote protocol, and noticed
+two problems with it. First, keys with spaces in their names can't be used
+with it. This only affects the WORM backend, and it seems no one has ever
+run into the problem. Rather than complicate the implementation of external
+special remotes, I decided to deprecate having spaces in key names. Which
+is just asking for trouble anyway. So now there's a nice error message, and
+a migration path.
+
+The other problem was that the external special remote documentation
+incorrectly said that a filename parameter never contained spaces. But in
+fact, there are situations where it can. This was not a problem with the
+protocol, but only with its documentation, and potentially with the
+implementation of some special remotes. So, I've spent some time today
+auditing every git-annex special remote that I know about. A few scripts
+that are bundled with git-annex were buggy and got fixed, and I
+filed bugs on 9 other external special remotes. A few did already get it
+right!
+
+Today's work was sponsored by Trenton Cronholm on 
+[Patreon](https://patreon.com/joeyh/)
diff --git a/doc/devblog/day_466__export_prototype.mdwn b/doc/devblog/day_466__export_prototype.mdwn
new file mode 100644
index 0000000000..cdc1926f83
--- /dev/null
+++ b/doc/devblog/day_466__export_prototype.mdwn
@@ -0,0 +1,6 @@
+Put together a prototype of `git annex export` in the "export" branch.
+Exporting to a directory special remote is basically working, but this is
+only the beginning.
+
+Today's work was sponsored by Jake Vosloo on
+[Patreon](https://patreon.com/joeyh/)
diff --git a/doc/devblog/day_467__export_progress.mdwn b/doc/devblog/day_467__export_progress.mdwn
new file mode 100644
index 0000000000..d5d32d5446
--- /dev/null
+++ b/doc/devblog/day_467__export_progress.mdwn
@@ -0,0 +1,11 @@
+Good progress on `git annex export` today. Changing the exported tree now
+works and is done efficiently. Resuming an export is working. Even
+detecting and resolving export conflicts should work (have not tested it).
+The necessary information about the export is recorded in the git-annex
+branch, including grafting in the exported tree there.
+
+There are some known problems when the tree that is exported contains
+multiple files with the same content. And git-annex is not yet able
+to download exported files from a special remote. Handling both of those
+needs way to get from keys to exported filenames. So, I plan to
+populate a sqlite database with that information next.
diff --git a/doc/devblog/day_467__firming_up_export.mdwn b/doc/devblog/day_467__firming_up_export.mdwn
new file mode 100644
index 0000000000..6b5e193ca0
--- /dev/null
+++ b/doc/devblog/day_467__firming_up_export.mdwn
@@ -0,0 +1,27 @@
+More work on `git annex export`. Made `initremote exporttree=yes` be
+required to enable exporting to a special remote. Added a sqlite database
+to keep track of what files have been exported. That let me fix the known
+problems with exporting multiple files that have the same content. 
+
+The same database lets `git annex get` (etc) download content from exports.
+Since an export is not a key/value store, git-annex has to do more
+verification of content downloaded from an export. Some types of keys,
+that are not based on checksums (eg WORM and URL), 
+cannot be downloaded from an export. And, git-annex will never trust
+an export to retain the content of a key, since some other tree could
+be exported over it at any time.
+
+With `git annex get` working from exports, it might be nice to also support
+`git annex copy --to export` for exporting specific files to them. However,
+that needs information that is not currently stored in the sqlite database
+until the export has already completed. One way it could work is for `git
+annex export --fast treeish --to export` to put all the filenames in the
+database but not export anything, and then `git annex copy --to export` (or
+even `git annex sync --content` to send the contents). I don't know if this
+complication is worth it.
+
+Otherwise, the export feature is fairly close to being complete now.
+Still need to make renames be handled efficiently, and add support for
+exporting to more special remotes.
+
+Today's work was supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_467__firming_up_export/comment_1_382fac60766340481acbcb8c05b70f42._comment b/doc/devblog/day_467__firming_up_export/comment_1_382fac60766340481acbcb8c05b70f42._comment
new file mode 100644
index 0000000000..09277b2f2b
--- /dev/null
+++ b/doc/devblog/day_467__firming_up_export/comment_1_382fac60766340481acbcb8c05b70f42._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ avatar="http://cdn.libravatar.org/avatar/0be1310904ded29624b9edb4824d451b"
+ subject="Partial exports"
+ date="2017-09-05T09:16:26Z"
+ content="""
+For what it's worth, partial exports (being able to only copy certain files to an export) would be very useful for me. My main usecase is exporting to my android phone (which has an sshd in termux that I use) from my desktop. I've got some large repos where having it all on my phone isn't possible, but it would be very useful to use git-annex to upload partials (right now I'm just using plain-old-rsync for that).
+"""]]
diff --git a/doc/devblog/day_468__export_renames.mdwn b/doc/devblog/day_468__export_renames.mdwn
new file mode 100644
index 0000000000..e40ebac907
--- /dev/null
+++ b/doc/devblog/day_468__export_renames.mdwn
@@ -0,0 +1,23 @@
+I knew that making `git annex export` handle renames efficiently would take
+a whole day somehow.
+
+Indeed, thinking it over, it is a seriously super hairy thing. Renames can swap
+contents between two or more files, and so temp files are needed. It has to
+handle cleaning up temp files after interrupted exports, which may be
+resumed with the same or a different tree. It also has to recover from
+export conflicts, which could cause the wrong content to be renamed to a file.
+
+I think I've thought through everything and found a way to deal with it all.
+Here's how it looks in operation swapping two files:
+
+	git annex export master --to dir
+	rename bar -> .git-annex-tmp-content-SHA256E-s30--472b01bf6234c98ce03d1386483ae578f6e58033974a1363da2606f9fa0e222a ok
+	rename foo -> .git-annex-tmp-content-SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c ok
+	rename .git-annex-tmp-content-SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c -> bar ok
+	rename .git-annex-tmp-content-SHA256E-s30--472b01bf6234c98ce03d1386483ae578f6e58033974a1363da2606f9fa0e222a -> foo ok
+	(recording state in git...)
+
+The export todo list is only getting longer.. But the branch may
+be close to being merged.
+
+Today's work was supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_468__export_renames/comment_1_4c37e6f9ac1e1571495b0d355c8af9ff._comment b/doc/devblog/day_468__export_renames/comment_1_4c37e6f9ac1e1571495b0d355c8af9ff._comment
new file mode 100644
index 0000000000..b9bc07ee43
--- /dev/null
+++ b/doc/devblog/day_468__export_renames/comment_1_4c37e6f9ac1e1571495b0d355c8af9ff._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="anthony@ad39673d230d75cbfd19d2757d754030049c7673"
+ nickname="anthony"
+ avatar="http://cdn.libravatar.org/avatar/05b48b72766177b3b0a6ff4afdb70790"
+ subject="comment 1"
+ date="2017-09-06T22:01:57Z"
+ content="""
+Looking forward to the export support! 
+
+Just curious (and I apologize in advance for any nightmares induced) did you consider the case of four files, A–D, where (content-wise) A=B and C=D and the change is to swap A/C and B/D? That'd potentially be an issue, since four files want to share two temporary names. Unless of course it's all only done with pairwise swaps.
+"""]]
diff --git a/doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment b/doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment
new file mode 100644
index 0000000000..1dfdfe6dee
--- /dev/null
+++ b/doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-09-07T19:54:41Z"
+ content="""
+Did not consider such a case. However, that's closely related to exporting
+files with same content being inefficient. There's a move
+operation but no copy operation. I might add a copy operation eventually,
+unsure.
+
+If a copy operation is added, then that rename case can be handled more
+efficiently, by moving to the single temp file and copying. Although it
+might still involve the special remote doing more work than strictly
+necessary depending on how it implements copy.
+
+Anyway, if the user is exporting copys of files, they're probably going to
+care more about that being somewhat more efficient than about renames of
+pairs of those copies being optimally efficient..
+
+Handling it fully optimally, with only one temp file per key,
+would require analizing the change and finding pairs of renames
+that swap filenames and handling each pair in turn. I suppose that
+is doable, just needs a better data structure than I have now.
+I've added a note to my todo list and the design document, but
+no promises.
+"""]]
diff --git a/doc/devblog/day_469__export_merged.mdwn b/doc/devblog/day_469__export_merged.mdwn
new file mode 100644
index 0000000000..5cd54d878d
--- /dev/null
+++ b/doc/devblog/day_469__export_merged.mdwn
@@ -0,0 +1,8 @@
+I've merged the `export` branch, after fixing most of the remaining known
+warts, and testing clean-up from interrupted exports and export conflicts.
+
+The main thing remaining to be done is adding the new commands to the
+external special remote interface, and adding export support to S3, webdav,
+and rsync special remotes.
+
+Today's work was supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_46__wrapping_up_the_month.mdwn b/doc/devblog/day_46__wrapping_up_the_month.mdwn
new file mode 100644
index 0000000000..c6045178c5
--- /dev/null
+++ b/doc/devblog/day_46__wrapping_up_the_month.mdwn
@@ -0,0 +1,18 @@
+Spent today reviewing my [[plans_for_the_month|assistant/disaster_recovery]]
+and filling in a couple of missing peices.
+
+Noticed that I had forgotten to make repository repair clean up any stale
+git locks, despite writing that code at the beginning of the month, and
+added that in.
+
+Made the webapp notice when a repository that is being used does not have
+any consistency checks configured, and encourage the user to set up checks.
+This happens when the assistant is started (for the local repository),
+and when removable drives containing repositories are plugged in. If the
+reminders are annoying, they can be disabled with a couple clicks.
+
+And I think that just about wraps up the month. (If I get a chance, I would
+still like to add recovery of git-remote-gcrypt encrypted git repositories.)
+
+My [[design/roadmap]] has next month dedicated to user-driven features
+and polishing and bugfixing.
diff --git a/doc/devblog/day_470__export_to_external_and_S3.mdwn b/doc/devblog/day_470__export_to_external_and_S3.mdwn
new file mode 100644
index 0000000000..df27b06ed7
--- /dev/null
+++ b/doc/devblog/day_470__export_to_external_and_S3.mdwn
@@ -0,0 +1,12 @@
+Got `git annex export` working to external special remotes. Each external
+special remote will need some modifications to allow exporting. Exporting
+to some things doesn't make sense, but often there's a way to browse a tree
+of files stored on the special remote and so export is worth supporting.
+Now would be a good time to contact the author of your favorite special
+remote about supporting export..
+
+Also had time to get `git annex export` working to S3. The tip 
+[[tips/publishing_your_files_to_the_public]] had a clumsy method for
+publishing files via S3 before, and is now quite simple!
+
+Today's work was supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_471__export_to_more_remotes.mdwn b/doc/devblog/day_471__export_to_more_remotes.mdwn
new file mode 100644
index 0000000000..bf8c1e66a8
--- /dev/null
+++ b/doc/devblog/day_471__export_to_more_remotes.mdwn
@@ -0,0 +1,13 @@
+Got `git annex export` working to webdav and rsync special remotes. Tested
+exporting to the Internet Archive via S3, and to box.com via webdav. Both
+had little weirdnesses in their handling of the protocols, which were
+worked around, and it's quite nice to be able to export trees to those
+services, as well as Amazon S3.
+
+Also added connection caching for exports, so S3 and webdav exports only
+make one http connection, instead of one per file.
+
+Had to change the format of `git-annex:export.log`; the old format didn't
+take into account that a repository can export to several different remotes.
+
+Today's work was supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_472__removing_empty_directories.mdwn b/doc/devblog/day_472__removing_empty_directories.mdwn
new file mode 100644
index 0000000000..25b36fd867
--- /dev/null
+++ b/doc/devblog/day_472__removing_empty_directories.mdwn
@@ -0,0 +1,20 @@
+After doing some fine-tuning of webdav export on Wednesday, I noticed a
+problem: There seems to be no way in the webdav spec to delete a collection
+(directory) only when it's empty like `rmdir(2)` does. 
+It would be possible to check the contents of the collection before
+deleting it, but that's complex (involving XML parsing) and race-prone.
+
+So, I decided to add a remote method to delete a directory, and make
+git-annex keep track of when a directory in an export is empty, and delete
+it. While it does complicate the design some to need to do this, that seems
+better than complicating the implementation of remotes like webdav. And
+some remotes may not have a `rmdir(2)` equivalent or a way to check if a
+directory is empty.
+
+Spent most of today implementing that, including some rather hairy
+eSQL to maintain a table of exported directories.
+
+Still not quite done with export..
+
+Today's work was sponsored by Trenton Cronholm on
+[Patreon](https://patreon.com/joeyh)
diff --git a/doc/devblog/day_473__distributed_use_of_exports.mdwn b/doc/devblog/day_473__distributed_use_of_exports.mdwn
new file mode 100644
index 0000000000..3113292460
--- /dev/null
+++ b/doc/devblog/day_473__distributed_use_of_exports.mdwn
@@ -0,0 +1,17 @@
+The tricky part of the `git annex export` feature has definitely been
+making it work in a distributed situation. The last details of that seem to
+have been worked out now.
+
+I had to remove support for dropping individual files from export remotes.
+The [[design|design/exporting_trees_to_special_remotes]] has a scenario
+where that makes distributed use of exports inconsistent.
+
+But, what is working now is `git annex export` being run in one repository,
+and then another repository, after syncing, can get files from the export.
+
+Most of export is done now. The only thing I'm thinking about adding is
+a way to make an export track a branch. so `git annex sync` can update
+the export.
+
+Today's work was sponsored by Jake Vosloo on
+[Patreon](https://patreon.com/joeyh/).
diff --git a/doc/devblog/day_474__tracking_exports.mdwn b/doc/devblog/day_474__tracking_exports.mdwn
new file mode 100644
index 0000000000..7b06027c45
--- /dev/null
+++ b/doc/devblog/day_474__tracking_exports.mdwn
@@ -0,0 +1,26 @@
+Built a way to make an export track changes to a branch.
+
+	git annex export --tracking master --to myexport
+
+That ties in nicely with `git annex sync`:
+
+	joey@darkstar:~/tmp/bench/a> echo hello > foo
+	joey@darkstar:~/tmp/bench/a> git annex add
+	add foo ok
+	joey@darkstar:~/tmp/bench/a> git annex sync --content
+	commit  
+	[master 8edbc6f] git-annex in joey@darkstar:~/tmp/bench/a
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 foo
+	ok
+	export myexport foo 
+	ok                          
+	joey@darkstar:~/tmp/bench/a> git mv foo bar
+	joey@darkstar:~/tmp/bench/a> git annex sync --content
+	commit  
+	[master 3ab6e73] git-annex in joey@darkstar:~/tmp/bench/a
+	 1 file changed, 0 insertions(+), 0 deletions(-)
+	 rename foo => bar (100%)
+	ok
+	rename myexport foo -> .git-annex-tmp-content-SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03 ok
+	rename myexport .git-annex-tmp-content-SHA256E-s6--5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03 -> bar ok
diff --git a/doc/devblog/day_475__assistant_exports.mdwn b/doc/devblog/day_475__assistant_exports.mdwn
new file mode 100644
index 0000000000..789fa0728b
--- /dev/null
+++ b/doc/devblog/day_475__assistant_exports.mdwn
@@ -0,0 +1,4 @@
+Got the git-annex assistant updating exports. The assistant is pretty
+complicated, so that took most of the day.
+
+Exports are done!
diff --git a/doc/devblog/day_476__third_time_lucky.mdwn b/doc/devblog/day_476__third_time_lucky.mdwn
new file mode 100644
index 0000000000..1a07b1b036
--- /dev/null
+++ b/doc/devblog/day_476__third_time_lucky.mdwn
@@ -0,0 +1,29 @@
+There's been a lot of little bug fixes and improvements going on
+in the ... oops ... almost a month since I last updated the devblog.
+Including a release of git-annex on the 3rd, and another release
+that's almost ready to go now. Just have not had the energy to blog about
+it all.
+
+Anyway, today I spent way too long fixing a minor wart. When multiple
+annexed files have the same content, transferring them with concurrency
+enabled could make it complain that "transfer already in progress".
+Which is better than transferring the same content twice, but it did make
+there seem to be a failure.
+
+I implemented two and a half different fixes for that. The first half a fix
+was too intrusive and I couldn't get it to work. Then came a fix that
+avoided the problem pretty cleanly, except it actually led to worse
+behavior, because it would sometimes transfer the same content twice, and
+needed non-obvious tweaks here and there to prevent that. Finally, around
+an hour ago, having actually given up unhappily for the day, I realized a
+much better way to fix it, that was minimally intrusive and works
+perfectly. 
+
+So it goes.. I'd say "concurrency is hard", but it's more that big complex
+code bases can make things that seem simple not really that simple.
+Yesterday I had a much easier time fixing a related problem with `git annex
+add -J`, which was really a lot hairier (involving a race condition and
+a lack of atomicity), but didn't cut across the code base in the same broad
+way.
+
+Today's work was supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_477__windows_build_fixed.mdwn b/doc/devblog/day_477__windows_build_fixed.mdwn
new file mode 100644
index 0000000000..c957815a1e
--- /dev/null
+++ b/doc/devblog/day_477__windows_build_fixed.mdwn
@@ -0,0 +1,10 @@
+Got the Windows build fixed, with help from Yury. The toolchain had been
+broken for months. We switched to using stack, which should make the
+Windows build more reproducible and easy to manage.
+
+Unfortunately, there was a link problem, and I had to disable some FFI code
+that was needed to terminate processes on Windows. Until that gets fixed,
+restarting and stopping the assistant won't work right on Windows.
+
+Aaand: The EvilLinker is not needed any longer, so I was very happy to be
+able to delete that hack. \o/
diff --git a/doc/devblog/day_478__windows_the_blackhole.mdwn b/doc/devblog/day_478__windows_the_blackhole.mdwn
new file mode 100644
index 0000000000..f1c65dabc7
--- /dev/null
+++ b/doc/devblog/day_478__windows_the_blackhole.mdwn
@@ -0,0 +1,14 @@
+Good grief, I've spent another whole day on Windows porting issues.
+
+Tested the new windows builds. Got win32 patched with terminateProcessId,
+and got the windows build using that. Unfortunately this made stack not
+incrementally rebuild very well, so Windows builds 
+got very slow. ([Bug report](https://github.com/commercialhaskell/stack/issues/2960))
+
+Found and fixed an ugly bug with annex link generation on Windows,
+which probably dates back to this spring. Code was comparing `"C:\"` with
+`"C:/"` and thinking the drives were different, argh. Still waiting on
+sloooow builds to test that.
+
+There will probably be an almost Windows-dedicated release tomorrow. Only
+"almost" because Sean T Parsons sent in some patches.
diff --git a/doc/devblog/day_47__fell_off_the_blogging_wagon.mdwn b/doc/devblog/day_47__fell_off_the_blogging_wagon.mdwn
new file mode 100644
index 0000000000..fd312a0d8d
--- /dev/null
+++ b/doc/devblog/day_47__fell_off_the_blogging_wagon.mdwn
@@ -0,0 +1,3 @@
+Low activity the past couple of days. Released a new version of git-annex
+yesterday. Today fixed three bugs (including a local pairing one that was
+pretty compicated) and worked on getting caught up with traffic.
diff --git a/doc/devblog/day_482__website_login_problem.mdwn b/doc/devblog/day_482__website_login_problem.mdwn
new file mode 100644
index 0000000000..65584ff8e3
--- /dev/null
+++ b/doc/devblog/day_482__website_login_problem.mdwn
@@ -0,0 +1,31 @@
+I noticed a large drop in bug reports and comments on the git-annex website
+over the holiday period of December. At first I thought this was just due
+to the holidays, even though holidays are often busy times for free
+software projects since lots of people have more time. But, traffic is
+still down this week, and several people emailed me about problems logging
+into the website.
+
+So, lacking much detail at all about what people were doing that didn't
+work, I've the past day and a some trying to guess at and reproduce
+the problem. And I think I have, <http://ikiwiki.info/bugs/login_problem/>,
+and once reproduced it was of course easily fixed.
+
+If you tried to post something and got a login prompt instead of seeing it
+on the website, now would be a good time to post it again.
+
+If you still have login problems with the website (other than openid which
+has lot of broken providers and badly specified protocol and stuff), please
+get in touch and try to provide enough detail to reproduce the problem, cuz
+my guessing muscles are feeling sprained after this experience.
+
+In the meantime, there has still been git-annex development happening.
+I added a new `git annex inprogress` command over the holidays that 
+allows doing things like streaming videos while `git annex get` is still
+downloading them. Several fixes to problems with the switch to youtube-dl 
+are fixed, core.sharedRepository is handled better, and the cabal file's
+custom-setup stanza was added back after quite a lot of refactoring of
+library code.
+
+---
+
+Today's work was sponsored by an anonymous bitcoin donor.
diff --git a/doc/devblog/day_483__faster_start_with_removable_drives.mdwn b/doc/devblog/day_483__faster_start_with_removable_drives.mdwn
new file mode 100644
index 0000000000..38016e9b74
--- /dev/null
+++ b/doc/devblog/day_483__faster_start_with_removable_drives.mdwn
@@ -0,0 +1,27 @@
+git-annex does a little bit of work at startup to learn about the git
+repository it's running in. That's been optimised some before, but
+not entirely eliminated; it's just too useful to have that information
+always available inside git-annex. But it turned out that it was doing more work
+than needed for many commands, by checking the git config of local remotes.
+Thas caused unnecessary spin up of removable drives, or automount timeouts,
+or generally more work than needed when running commands like `git annex
+find` and even tab completing git-annex. That's fixed now, so it
+avoids checking the git config of remotes except when running commands that
+access some remote.
+
+There's also a new config setting, `remote.<name>.annex-checkuuid` that can
+be set to false to defer checking the uuid of local repositories until
+git-annex actually uses them. That can avoid even more spinup/automounts,
+but that config prevents git-annex from transparently handling the case
+where different removable drives get mounted to the same place at different
+times.
+
+Speaking of speed, I benchmarked linux kernel mitigation for the meltdown
+attack making `git status` 5% slower from a warm cache. It did not
+slow down `git annex find` or `git annex find --in remote` enough to be
+measured by my benchmark. I expect that git-annex commands that transfer
+data are bottlenecked on IO and won't be slowed down appreciably by the
+meltdown mitigation either.
+
+Today's work was sponsored by Jake Vosloo on
+[Patreon](https://patreon.com/joeyh/).
diff --git a/doc/devblog/day_484__special_remote_protocol_extensions.mdwn b/doc/devblog/day_484__special_remote_protocol_extensions.mdwn
new file mode 100644
index 0000000000..68140c6fee
--- /dev/null
+++ b/doc/devblog/day_484__special_remote_protocol_extensions.mdwn
@@ -0,0 +1,12 @@
+The 
+[[external special remote protocol|design/external_special_remote_protocol]]
+had extensibility built into it for messages git-annex sends, but not
+for messages that the remote sends back to git-annex. To fix this
+asymmetry, I've added a new EXTENSIONS to the protocol, which can be used
+to find out about what new protocol extensions are supported.
+
+There was the possibility that adding that might break some external
+special remote that hardcoded the intial protocol messages. So, I checked
+all of them that I know of, and all were ok, except for older versions of
+datalad, which we were able to deal with. If you have your own external
+special remote implementation, now would be a good time to check it.
diff --git a/doc/devblog/day_485__slow_and_steady.mdwn b/doc/devblog/day_485__slow_and_steady.mdwn
new file mode 100644
index 0000000000..22a011d99f
--- /dev/null
+++ b/doc/devblog/day_485__slow_and_steady.mdwn
@@ -0,0 +1,9 @@
+I've been recovering from some stuff over the past month, so
+progress lately has been slow, but still steadily progressing. Yesterday's
+release of git-annex had a month and a half of improvements, including JSON
+enhancements, adding extension support to the external special remote
+protocol, and making fsck warn about required content that's missing.
+
+Today I've been working on `git annex export` to rsync special remotes.
+
+Today's work was sponsored by Jake Vosloo [on Patreon](https://www.patreon.com/joeyh).
diff --git a/doc/devblog/day_486__time_to_ditch_rsync.mdwn b/doc/devblog/day_486__time_to_ditch_rsync.mdwn
new file mode 100644
index 0000000000..bd7cf0d4bb
--- /dev/null
+++ b/doc/devblog/day_486__time_to_ditch_rsync.mdwn
@@ -0,0 +1,14 @@
+I'm excited by this new design
+[[todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol]].
+
+git-annex's use of rsync got transfers over ssh working quickly early on,
+but other than resuming interrupted transfers, using rsync doesn't really
+gain git-annex much, since annexed objects don't change over time. And
+rsync has always involved a certian amount of overhead that a custom
+protocol would avoid.
+
+It's especially handy that such a protocol was already developed for
+`git-annex p2p` when using tor. I've not heard of a lot of people using that
+feature (but maybe people who do have reason not to talk about it), but
+it's a good solid thing, implemented very generically with a free monad,
+and reusing it for git-annex-shell would be great.
diff --git a/doc/devblog/day_487__git-annex-shell_p2pstdio.mdwn b/doc/devblog/day_487__git-annex-shell_p2pstdio.mdwn
new file mode 100644
index 0000000000..1301d6123e
--- /dev/null
+++ b/doc/devblog/day_487__git-annex-shell_p2pstdio.mdwn
@@ -0,0 +1,38 @@
+It was rather easy to implement `git-annex-shell p2pstdio`, the P2P
+protocol implementation done for tor is quite generic and easy to adapt for
+this. 
+
+The only complication was that git-annex-shell has a readonly mode,
+so the protocol server needed modifications to support that.
+Well, there's also some innefficiency around unnecessary verification
+of transferred content in some cases, which will probably need extensions
+to the P2P protocol later.
+
+Also wrote up some documentation of what the P2P protocol looks like,
+for anyone who might want to communiate with git-annex-shell using it,
+for some reason, and doesn't understand Haskell and free monads.
+[[design/P2P_protocol]]
+
+While comparing the code of the P2P server and git-annex-shell commands, I
+noticed that the P2P server didn't check inAnnex when locking content,
+while `git-annex-shell lockcontent` did check inAnnex. This turned out to
+be a ugly data loss bug involving direct mode repositories, where a
+modified direct mode file was allowed when locking a key in the repository.
+Turned out that the bug happened when locking a file over tor to drop it
+locally, but also when locking a file locally in a direct mode repository
+to allow dropping it from any remote. 
+
+Very glad I noticed that, and I've changed the API to prevent that class of
+bug. I feel this is not a severe data loss bug, because when a direct mode
+repository is involved, dropping from somewhere and then modifying the file
+in the direct mode repository can have the same effect of losing the old copy.
+The bug just made data loss happen when running the same operations in the
+other order.
+
+Next will be making git-annex use this new git-annex-shell feature
+when available.
+
+----
+
+Today's work was sponsored by Trenton Cronholm on
+[Patreon](https://patreon.com/joeyh)
diff --git a/doc/devblog/day_488__groundwork_for_using_p2pstdio.mdwn b/doc/devblog/day_488__groundwork_for_using_p2pstdio.mdwn
new file mode 100644
index 0000000000..e09da769ae
--- /dev/null
+++ b/doc/devblog/day_488__groundwork_for_using_p2pstdio.mdwn
@@ -0,0 +1,30 @@
+Spent most of the day laying groundwork for using git-annex-shell p2pstdio.
+Implemented pools of ssh connections to it, and added uuid verification.
+Then generalized code from the p2p remote so it can be reused in the git
+remote. The types got super hairy in there, but the code reuse level is
+excellent.
+
+Finally it was time to convert the first ssh remote method
+to use the P2P protocol. I chose key removal, since benchmarking it doesn't
+involve the size of annexed objects.
+
+Here's the P2P protocol in action over ssh:
+
+	[2018-03-08 17:02:47.688627136] chat: ssh ["localhost","-S",".git/annex/ssh/localhost","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","git-annex-shell 'p2pstdio' '/~/tmp/bench/a' '--debug' 'da72c285-2615-4a67-828f-eaae4f42fc3d' --uuid db017fac-eb8f-42d9-9d09-2780b193cef1"]
+	[2018-03-08 17:02:47.901897195] P2P < AUTH-SUCCESS db017fac-eb8f-42d9-9d09-2780b193cef1
+	[2018-03-08 17:02:47.902025504] P2P > REMOVE SHA256E-s4--97b912eb4a61df5f806ca6239dde3e1a4f51ad20aced1642cbb83dc510a5fa6b
+	[2018-03-08 17:02:47.910074003] P2P < SUCCESS
+	[2018-03-08 17:02:47.914181701] P2P > REMOVE SHA256E-s4--6af2f5b785a8930f0bd3edc833e18fa191167ab0535ef359b19a1982a6984e96
+	[2018-03-08 17:02:47.918699806] P2P < SUCCESS
+
+For a benchmark, I set up a repository with 1000 annexed files,
+and cloned it from localhost, then ran `git annex drop --from origin`.
+
+before: 41 seconds  
+after: 10 seconds
+
+400% speedup for dropping is pretty great.. And when there's more latency
+than loopback has, the improvement should be more pronounced. 
+Will test it this evening over my satellite internet. :)
+
+Today's work was sponsored by Trenton Cronholm on [Patreon](https://patreon.com/joeyh/).
diff --git a/doc/devblog/day_489__zooming.mdwn b/doc/devblog/day_489__zooming.mdwn
new file mode 100644
index 0000000000..454d9a5846
--- /dev/null
+++ b/doc/devblog/day_489__zooming.mdwn
@@ -0,0 +1,31 @@
+Andrew Wringler has released
+[git-annex-turtle](https://github.com/andrewringler/git-annex-turtle)
+which provides Apple Finder integration for git-annex on macOS,
+including custom badge icons, contextual menus and a Menubar icon.
+This looks really nice!
+
+---
+
+I've completed the P2P protocol with git-annex-shell. It turned out just as
+fast and good as I'd hoped. 
+[[todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol]] has the
+benchmark details. 
+
+Even transferring of large files speeds up somewhat;
+git-annex is actually faster than rsync at shoving bytes down a pipe.
+(Though rsync still wins in lots of other benchmarks I'm sure.)
+
+Surprisingly, in one benchmark, I found accessing a repository on localhost
+via ssh is now slightly *faster* than accessing that same repository by
+path. I think that this is because when git-annex is talking to
+git-annex-ssh, the programs run on different CPU cores, so there's some
+extra concurrency.
+
+There are still some implementation todos, some of which will make it
+faster yet, and others involving potential edge cases. This is a big change
+and will need some time to be considered stable.
+
+----
+
+Today's work was sponsored by Jake Vosloo on
+[Patreon](https://patreon.com/joeyh)
diff --git a/doc/devblog/day_489__zooming/comment_1_d840f371f1d22b0ee8f3c8df25ebe3d3._comment b/doc/devblog/day_489__zooming/comment_1_d840f371f1d22b0ee8f3c8df25ebe3d3._comment
new file mode 100644
index 0000000000..38410b5ea7
--- /dev/null
+++ b/doc/devblog/day_489__zooming/comment_1_d840f371f1d22b0ee8f3c8df25ebe3d3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="progress bars?"
+ date="2018-03-12T13:44:50Z"
+ content="""
+how do progress bars work in this new design? we had those for free with rsync before (i assume?), do we still have them now?
+
+how about [[todo/wishlist__58___global_progress_status]]? is that more feasible now?
+
+thanks!
+"""]]
diff --git a/doc/devblog/day_489__zooming/comment_2_ec579c84aeb244798a818a20ff0f50b5._comment b/doc/devblog/day_489__zooming/comment_2_ec579c84aeb244798a818a20ff0f50b5._comment
new file mode 100644
index 0000000000..db39387248
--- /dev/null
+++ b/doc/devblog/day_489__zooming/comment_2_ec579c84aeb244798a818a20ff0f50b5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-03-12T21:36:45Z"
+ content="""
+It will use git-annex's native progress display, same as it already did
+when -J is used.
+
+Rsync's progress display was not blocking
+[[todo/wishlist__58___global_progress_status]].
+"""]]
diff --git a/doc/devblog/day_48__direct_mode_guard_design.mdwn b/doc/devblog/day_48__direct_mode_guard_design.mdwn
new file mode 100644
index 0000000000..c047e7f750
--- /dev/null
+++ b/doc/devblog/day_48__direct_mode_guard_design.mdwn
@@ -0,0 +1,29 @@
+I've been investigating ways to implement a [[/todo/direct_mode_guard]].
+Preventing a stray `git commit -a` or `git add` doing bad things in a
+direct mode repository seems increasingly important.
+
+First, considered moving `.git`, so git won't know it's a git repository.
+This doesn't seem *too* hard to do, but there will certainly be unexpected
+places that assume `.git` is the directory name.
+
+I dislike it more and more as I think about it though, because it moves
+direct mode git-annex toward being entirely separate from git, and I don't
+want to write my own version control system. Nor do I want to complicate
+the git ecosystem with tools needing to know about git-annex to work in
+such a repository.
+
+So, I'm happy that one of the other ideas I tried today seems quite
+promising. Just set core.bare=true in a direct mode repository. This nicely
+blocks all git commands that operate on the working tree from doing
+anything, which is just what's needed in direct mode, since they don't know
+how to handle the direct mode files. But it lets all git commands and other
+tools that don't touch the working tree continue to be used. You can even
+run `git log file` in such a repository (surprisingly!)
+
+It also gives an easy out for anyone who really wants to use git commands
+that operate on the work tree of their direct mode repository, by just
+passing `-c core.bare=false`. And it's really easy to implement in
+git-annex too -- it can just notice if a repo has core.bare and
+annex.direct both set, and pass that parameter to every git command it
+runs. I should be able to get by with only modifying 2 functions to
+implement this.
diff --git a/doc/devblog/day_48__direct_mode_guard_design/comment_1_ec0147ccc55bad3a38652383f4098a65._comment b/doc/devblog/day_48__direct_mode_guard_design/comment_1_ec0147ccc55bad3a38652383f4098a65._comment
new file mode 100644
index 0000000000..3f297d505c
--- /dev/null
+++ b/doc/devblog/day_48__direct_mode_guard_design/comment_1_ec0147ccc55bad3a38652383f4098a65._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="70.82.37.38"
+ subject="awesome!"
+ date="2013-11-05T15:50:15Z"
+ content="""
+`core.bare=true` seems like an awesome idea!!! it probably means this can be factored into current installs without any change too right?
+"""]]
diff --git a/doc/devblog/day_490__kind_of_annoying.mdwn b/doc/devblog/day_490__kind_of_annoying.mdwn
new file mode 100644
index 0000000000..bf3344b332
--- /dev/null
+++ b/doc/devblog/day_490__kind_of_annoying.mdwn
@@ -0,0 +1,28 @@
+Working on getting the git-annex-shell P2P protocol into a releasable
+state. This was kind of annoying.
+
+I started out wanting to make annex.verify=false disable verification when
+using the P2P protocol. But, that needed protocol changes, and
+unfortunately the protocol was not extensible. I thought it was supposed to
+reject unknown commands and keep the connection open, which would make
+extensions easy, but unfortunately it actually closed the connection after
+an unknown command.
+
+So, I added a version negotiation to the P2P protocol, but it's not done
+for tor remotes yet, and will be turned on for them in some
+[[future flag day|todo/p2p_protocol_flag_days]], once all of them get
+upgraded.
+
+After all that, I got completely stuck on the annex.verify change.
+Multiple problems are preventing me from seeing a way to do it at all.
+[[todo/support_disabling_verification_of_transfer_over_p2p_protocol]]
+This must be why I didn't support it in the first place when building the
+P2P protocol two years ago.
+
+Also fixed performance when a ssh remote is unavailable, where it was
+trying to connect twice to the remote for each action. And confirmed that
+the assistant will behave ok when moving between networks while it has
+P2P connections open. So, other than annex.verify not being supported,
+I feel fairly ready to release this new feature.
+
+Today's work was supported by an anonymous bitcoin donor.
diff --git a/doc/devblog/day_491__annex.verify_redux.mdwn b/doc/devblog/day_491__annex.verify_redux.mdwn
new file mode 100644
index 0000000000..1d061f679b
--- /dev/null
+++ b/doc/devblog/day_491__annex.verify_redux.mdwn
@@ -0,0 +1,19 @@
+With fresh eyes I stopped being confused by P2P protocol free monad stuff,
+and got annex.verify=false supported when it's safe to skip verification.
+
+And, I found some cases where resuming a download with annex.verify=false
+could let corrupt data into the repository. This is not a new problem; as
+well as with the P2P protocol, it could happen when downloading from the
+web, and possibly with some external special remotes that support resuming.
+So, it seemed best to override annex.verify configuration when
+resuming a download.
+
+Also fixed up some progress bar stuff related to the P2P protocol. 
+Including dealing with the case where the size of a key being downloaded is
+not known until the peer starts sending its data. The progress bar will
+now be updated with the size from the P2P protocol, so it can display
+a percentage even in this case.
+
+I hope that's the end of the P2P protocol stuff for now.
+
+Today's work was supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_492__concurrency_is_hard.mdwn b/doc/devblog/day_492__concurrency_is_hard.mdwn
new file mode 100644
index 0000000000..6a18072d95
--- /dev/null
+++ b/doc/devblog/day_492__concurrency_is_hard.mdwn
@@ -0,0 +1,12 @@
+In the past 24 hours, I've fixed two extremely hairy problems with 
+`git annex get -J`. One was a locking problem.
+And the other involved thundering herds and ssh connection multiplexing
+and inherited file descriptors and races, and ...
+That took 4 hours of investigation to understand well enough to fix it.
+
+Neither of those involved the ssh P2P changes, other than perhaps they
+exposed one of the issues more than it was exposed before,
+but on the plus side I've been testing that new code
+quite a lot as I worked on them..
+
+Today's work was supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_493__two_new_special_remotes.mdwn b/doc/devblog/day_493__two_new_special_remotes.mdwn
new file mode 100644
index 0000000000..478450ba81
--- /dev/null
+++ b/doc/devblog/day_493__two_new_special_remotes.mdwn
@@ -0,0 +1,18 @@
+I've been traveling and at conferences.
+
+In the meantime, Lykos has released
+[git-annex-remote-googledrive](https://github.com/Lykos153/git-annex-remote-googledrive),
+a replacement for an older, unmaintained Google Drive special remote.
+
+Today I added a special remote that stores files on an Android device
+using `adb`. It supports `git annex export`, so the files stored on 
+the Android device can have the same filenames as in the git-annex
+repository. I have plans for making `git annex import` support
+special remotes, and other features to make bi-directional
+sync with Android work well.
+
+Of course, there is some overlap between that and the Android port,
+but they probably serve different use cases.
+
+Today's work was sponsored by Trenton Cronholm on
+[Patreon](https://patreon.com/joeyh/)
diff --git a/doc/devblog/day_494__url_download_changes.mdwn b/doc/devblog/day_494__url_download_changes.mdwn
new file mode 100644
index 0000000000..3d542dd57b
--- /dev/null
+++ b/doc/devblog/day_494__url_download_changes.mdwn
@@ -0,0 +1,25 @@
+To make git-annex faster when it's dealing with a lot of urls,
+I decided to make it use the http-conduit library for all url access by
+default. That way, http pipelining will speed up repeated requests to the
+same web servers. This is kind of a follow-up to the recent elimination of
+rsync.
+
+Some users rely on some annex.web-options or a .netrc file to configure
+how git-annex downloads urls. To keep that supported, when
+annex.web-options is set, git-annex will use curl.
+To use a .netrc file, curl needs an option, so you would configure:
+
+	git config annex.web-options --netrc
+
+I get the feeling that nobody has implemented resuming interrupted
+downloads of files using http-conduit before, because it was unexpectedly
+kind of hard and http-types lacks support for some of the necessary
+range-related HTTP stuff.
+
+Today's work was supported by the NSF-funded DataLad project.
+
+----
+
+Stewart V. Wright [announced recastex](http://git-annex.branchable.com/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex/),
+a program that publishes podcasts and other files from by git-annex to your
+phone.
diff --git a/doc/devblog/day_495__move_numcopies_safety.mdwn b/doc/devblog/day_495__move_numcopies_safety.mdwn
new file mode 100644
index 0000000000..0161244911
--- /dev/null
+++ b/doc/devblog/day_495__move_numcopies_safety.mdwn
@@ -0,0 +1,20 @@
+New version released today with adb special remote, http connection
+caching, improved progress displays, annex.retry, and other changes.
+
+I've been rethinking `git annex move` in the context of numcopies
+checking. Thanks to a user posting
+[[forum/git-annex_move_does_not_appear_to_respect_numcopies]].
+Of course, move is known not to do that, but it's useful to get a
+perspective that this is susprising behavior and not wanted by that user,
+and poorly documented besides.
+
+So, I added `git annex move --safe` which does honor numcopies, so 
+it only does a copy when there are not enough copies to move.
+
+I'm leaning toward making that the default behavior, and
+needing `git annex move --unsafe` to get the current behavior of moving
+without a net. Of course, lots of us probably use move and like the current
+behavior, and such a change can break workflows and scripts.
+There might be a transition period where move warns when run without --safe
+or --unsafe. Feedback welcomed on the bug report 
+[[bugs/move_violates_numcopies]].
diff --git a/doc/devblog/day_496__move_numcopies_safety_revisited.mdwn b/doc/devblog/day_496__move_numcopies_safety_revisited.mdwn
new file mode 100644
index 0000000000..9d96e0cdd5
--- /dev/null
+++ b/doc/devblog/day_496__move_numcopies_safety_revisited.mdwn
@@ -0,0 +1,12 @@
+After talking it over in [[bugs/move_violates_numcopies]], we found a nicer
+compromise for `git annex move`. Rather than strictly enforcing numcopies,
+it avoids making any bad situations worse. For example, when there's
+only one copy of a file, it can be moved even if numcopies is higher.
+But, when numcopies is 2 and the source and destination repos have a copy,
+move will not drop from the source repo, since that would make it worse.
+
+Implemented that today. While doing so I got bit by the inverted Ord
+instance for TrustLevel, so spent a while cleaning that up.
+
+Today's work was sponsored by Jake Vosloo on
+[Patreon](https://patreon.com/joeyh/).
diff --git a/doc/devblog/day_497__rethinking_the_android_port.mdwn b/doc/devblog/day_497__rethinking_the_android_port.mdwn
new file mode 100644
index 0000000000..5d1b74124c
--- /dev/null
+++ b/doc/devblog/day_497__rethinking_the_android_port.mdwn
@@ -0,0 +1,24 @@
+I've long been unsatisfied with the amount of effort needed to maintain the
+Android port in its current state, the hacky cross-compiler toolchain 
+needs days of wasted work to update, and is constantly out of date and
+breaking in one way or other. This sucks up any time I might spare to
+actually improve the Android port.
+
+So, it was quite a surprise yesterday when I downloaded the git-annex
+standalone Linux tarball into the Termux Android shell and unpacked it, and
+it more or less worked!
+
+The result, after a [[few minor fixes|todo/termux_package]], works 
+just as well as the git-annex Android app, and probably better. Even the 
+webapp works well, and with the Termux:Boot app, it can even
+autostart the assistant on boot as a daemon. If you want to give it a
+try, see [[tips/install_on_Android_in_Termux]].
+
+So, I am leaning toward deprecating the android port for this, removing 14
+thousand lines of patches and android-specific code. Not going to do it
+just yet, but I feel a weight lifting...
+
+----
+
+Today's work was sponsored by Jake Vosloo on
+[Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_497__rethinking_the_android_port/comment_1_cb30ab18753e5f221ed4d92b3ff8a32e._comment b/doc/devblog/day_497__rethinking_the_android_port/comment_1_cb30ab18753e5f221ed4d92b3ff8a32e._comment
new file mode 100644
index 0000000000..f288912e65
--- /dev/null
+++ b/doc/devblog/day_497__rethinking_the_android_port/comment_1_cb30ab18753e5f221ed4d92b3ff8a32e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/3ee5cf54-f022-4a71-8666-3c2b5ee231dd"
+ nickname="Anthony DeRobertis"
+ avatar="http://cdn.libravatar.org/avatar/1007bfece547e9f2d86fafa142cd240a62456c37f104a9d96ba9db5bf18e1934"
+ subject="Looking forward to trying this"
+ date="2018-04-26T13:10:30Z"
+ content="""
+I use the current Android port on a few tablets, and it's... well, clearly labeled beta. On one of the tablets, it randomly segfaults [no idea if that's a git-annex bug or a hardware problem, not like I have a memtest86 available]. On both it sometimes just decides to add commits to remove files recently added on other machines (easy enough to fix with git revert). Sometimes it puts in place small placeholder files (git annex fsck fixes). Still far better than manually copying & sync'ing, though!
+
+At least for me, v6 mode just doesn't work on Android — even on a new empty repository, last I checked, switching to v6 mode gave errors.
+
+So I look forward to trying it in Termux! 
+"""]]
diff --git a/doc/devblog/day_498__unexpected_release_prep.mdwn b/doc/devblog/day_498__unexpected_release_prep.mdwn
new file mode 100644
index 0000000000..8ceae0a808
--- /dev/null
+++ b/doc/devblog/day_498__unexpected_release_prep.mdwn
@@ -0,0 +1,21 @@
+I'm unexpectedly preparing for a release soon, because the last
+release turned out to have a crasher bug when using a bare repository or
+--all, and a bug that prevented the webapp starting on OSX.
+
+As well as fixing those, the new release will have
+several smaller improvements and fixes all done today. It's been a rather
+productive day.
+
+And, using git-annex in Termux is now working even on newer versions of
+Android, that use seccomp filtering to filter out system calls that the ghc
+runtime uses. The `proot` program on Termux worked around that nasty
+problem.
+
+The old Android app is now deprecated, and I'll probably remove it entirely
+within a few months unless I find a reason not to.
+So, I also closed almost all the old Android-specific bug reports today. I
+don't normally do mass bug closures without followup, but it was warranted
+here; almost all of those bugs are specific to the old Android app.
+
+Today's work was sponsored by Trenton Cronholm on
+[Patreon](https://patreon.com/joeyh)
diff --git a/doc/devblog/day_499__security_hole.mdwn b/doc/devblog/day_499__security_hole.mdwn
new file mode 100644
index 0000000000..d110f0c31b
--- /dev/null
+++ b/doc/devblog/day_499__security_hole.mdwn
@@ -0,0 +1,27 @@
+I'm writing this on a private branch, it won't be posted until a week from
+now when the security hole is disclosed.
+
+Security is not compositional. You can have one good feature, and add
+another good feature, and the result is not two good features, but a new
+security hole. In this case
+[[security/CVE-2018-10857_and_CVE-2018-10859|CVE-2018-10857]]. 
+And it can be hard to spot this kind of security hole, but then once it's
+known it seems blindly obvious.
+
+It came to me last night and by this morning I had decided the potential
+impact was large enough to do a coordinated disclosure. Spent the first
+half of the day thinking through ways to fix it that don't involve writing
+my own http library. Then started getting in touch with all the
+distributions' security teams. And then coded up a fairly complete fix for
+the worst part of the security hole, although a secondary part is going to
+need considerably more work.
+
+It looks like the external special remotes are going to need at least some
+security review too, and I'm still thinking that part of the problem over.
+
+Exhausted.
+
+Today's work was sponsored by Trenton Cronholm 
+[on Patreon](https://patreon.com/joeyh).
+
+[[!meta date="Jun 15 2018 7:00 pm"]]
diff --git a/doc/devblog/day_49__direct_mode_guard_implementation.mdwn b/doc/devblog/day_49__direct_mode_guard_implementation.mdwn
new file mode 100644
index 0000000000..ebc0dd4946
--- /dev/null
+++ b/doc/devblog/day_49__direct_mode_guard_implementation.mdwn
@@ -0,0 +1,14 @@
+Long, long day coding up the direct mode guard today. About 90% of the fun
+is dealing with `receive.denyCurrentBranch` not preventing pushes that
+change the current branch, now that core.bare is set in direct mode.
+My current solution to this involves using a special branch when using
+direct mode, which nothing will ever push to (hopefully). A much nicer
+solution would be to use a `update` hook to deny pushes of the current
+branch -- but there are filesystems where repos cannot have git hooks.
+
+The test suite is falling over, but the `directguard` branch otherwise
+seems usable.
+
+----
+
+Today's work was sponsored by Carlo Matteo Capocasa.
diff --git a/doc/devblog/day_49__direct_mode_guard_implementation/comment_1_3ebe5c3f708070f164ecaf36b79f7bfc._comment b/doc/devblog/day_49__direct_mode_guard_implementation/comment_1_3ebe5c3f708070f164ecaf36b79f7bfc._comment
new file mode 100644
index 0000000000..2a77d6d815
--- /dev/null
+++ b/doc/devblog/day_49__direct_mode_guard_implementation/comment_1_3ebe5c3f708070f164ecaf36b79f7bfc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="comment 1"
+ date="2013-11-06T11:50:00Z"
+ content="""
+Thanks, Joey! I am very proud!
+"""]]
diff --git a/doc/devblog/day_4__unexpected_windows_day.mdwn b/doc/devblog/day_4__unexpected_windows_day.mdwn
new file mode 100644
index 0000000000..6a448c3fc1
--- /dev/null
+++ b/doc/devblog/day_4__unexpected_windows_day.mdwn
@@ -0,0 +1,10 @@
+Woke up with a pretty solid plan for gcrypt. It will be structured as a
+separate special remote, so `initremote` will be needed, with a gitrepo=
+parameter (unless the remote already exists). git-annex will then set up
+the git remote, including pushing to it (needed to get a gcrypt-id).
+
+Didn't feel up to implementing that today. Instead I expectedly spent
+the day doing mostly Windows work, including setting up a VM on my new
+laptop for development. Including a ssh server in Windows, so I can
+script local builds and tests on Windows without ever having to
+touch the desktop. Much better!
diff --git a/doc/devblog/day_500__security_hole_part_2.mdwn b/doc/devblog/day_500__security_hole_part_2.mdwn
new file mode 100644
index 0000000000..3d485ee73c
--- /dev/null
+++ b/doc/devblog/day_500__security_hole_part_2.mdwn
@@ -0,0 +1,26 @@
+Most of the day was spent staring at the http-client source code and trying
+to find a way to add the IP address checks to it that I need to fully close
+the security hole.
+
+In the end, I did find a way, with the duplication of a couple dozen lines
+of code from http-client. It will let the security fix be used with
+libraries like aws and DAV that build on top of http-client, too.
+
+While the code is in git-annex for now, it's fully disconnected and
+would also be useful if a web browser were implemented in Haskell,
+to implement same-origin restrictions while avoiding DNS rebinding attacks.
+
+Looks like http proxies and curl will need to be disabled by default,
+since this fix can't support either of them securely. I wonder how web
+browsers deal with http proxies, DNS rebinding attacks and same-origin?
+I can't think of a secure way.
+
+Next I need a function that checks if an IP address is a link-local address
+or a private network address. For both ipv4 and ipv6. Could not find
+anything handy on hackage, so I'm gonna have to stare at some RFCs. Perhaps
+this evening, for now, it's time to swim in the river.
+
+Today's work was sponsored by  Jake Vosloo
+[on Patreon](https://patreon.com/joeyh)
+
+[[!meta date="June 16 2018 4:00 pm"]]
diff --git a/doc/devblog/day_501__security_hole_part_3.mdwn b/doc/devblog/day_501__security_hole_part_3.mdwn
new file mode 100644
index 0000000000..6187f7d534
--- /dev/null
+++ b/doc/devblog/day_501__security_hole_part_3.mdwn
@@ -0,0 +1,13 @@
+Got the IP address restrictions for http implemented. (Except for http
+proxies.)
+
+Unforunately as part of this, had to make youtube-dl and curl not be used
+by default. The annex.security.allowed-http-addresses config has to be
+opened up by the user in order to use those external commands, since they
+can follow arbitrary redirects.
+
+Also thought some more about how external special remotes might be
+affected, and sent their authors' a heads-up.
+
+[[!meta date="June 17 2018 4:00 pm"]]
+
diff --git a/doc/devblog/day_502__security_hole_part_4.mdwn b/doc/devblog/day_502__security_hole_part_4.mdwn
new file mode 100644
index 0000000000..8988a7f15d
--- /dev/null
+++ b/doc/devblog/day_502__security_hole_part_4.mdwn
@@ -0,0 +1,24 @@
+Spent several hours dealing with the problem of http proxies, which
+bypassed the IP address checks added to prevent the security hole.
+Eventually got it filtering out http proxies located on private IP
+addresses.
+
+Other than the question of what to do about external special remotes
+that may be vulerable to related problems, it looks like the security
+hole is all closed off in git-annex now.
+
+Added a new page [[security]] with details of this and past security holes
+in git-annex.
+
+Several people I reached out to for help with special remotes have gotten
+back to me, and we're discussing how the security hole may affect them and
+what to do. Thanks especially to Robie Basak and Daniel Dent for their
+work on security analysis.
+
+Also prepared a minimal backport of the security fixes for the git-annex in
+Debian stable, which will probably be more palatable to their security team
+than the full 2000+ lines of patches I've developed so far. 
+The minimal fix is secure, but suboptimal; it prevents even safe urls from
+being downloaded from the web special remote by default.
+
+[[!meta date="June 18 2018 4:00 pm"]]
diff --git a/doc/devblog/day_503__security_hole_part_5.mdwn b/doc/devblog/day_503__security_hole_part_5.mdwn
new file mode 100644
index 0000000000..86c760c6c2
--- /dev/null
+++ b/doc/devblog/day_503__security_hole_part_5.mdwn
@@ -0,0 +1,19 @@
+Started testing that the security fix will build everywhere on
+release day. This is being particularly painful for the android build,
+which has very old libraries and needed http-client updated, with many
+follow-on changes, and is not successfully building yet after 5 hours. 
+I really need to finish deprecating the android build.
+
+Pretty exhausted from all this, and thinking what to do about
+external special remotes, I elaborated on an idea that Daniel Dent had
+raised in discussions about vulnerability, and realized that git-annex
+has a second, worse vulnerability. This new one could be used to trick a
+git-annex user into decrypting gpg encrypted data that they had 
+never stored in git-annex. The attacker needs to have control of both an
+encrypted special remote and a git remote, so it's not an easy exploit to
+pull off, but it's still super bad.
+
+This week is going to be a lot longer than I thought, and it's already
+feeling kind of endless..
+
+[[!meta date="June 19 2018 8:00 pm"]]
diff --git a/doc/devblog/day_504__security_hole_part_6.mdwn b/doc/devblog/day_504__security_hole_part_6.mdwn
new file mode 100644
index 0000000000..17680941c2
--- /dev/null
+++ b/doc/devblog/day_504__security_hole_part_6.mdwn
@@ -0,0 +1,12 @@
+Was getting dangerously close to burnt out, or exhaustion leading to
+mistakes, so yesterday I took the day off, aside from spending the morning
+babysitting the android build every half hour. (It did finally succeed.)
+
+Today, got back into it, and implemented a fix for CVE-2018-10859 and also
+the one case of CVE-2018-10857 that had not been dealt with before.
+This fix was really a lot easier than the previous fixes for
+CVE-2018-10857.
+Unfortunately this did mean not letting URL and WORM keys be downloaded
+from many special remotes by default, which is going to be painful for some.
+
+[[!meta date="June 20 2018 5:00 pm"]]
diff --git a/doc/devblog/day_505__security_fix_release.mdwn b/doc/devblog/day_505__security_fix_release.mdwn
new file mode 100644
index 0000000000..2f2d486675
--- /dev/null
+++ b/doc/devblog/day_505__security_fix_release.mdwn
@@ -0,0 +1,15 @@
+Just released git-annex 6.20180626 with important security fixes!
+
+Please go upgrade now, read the [[release_notes|news/security_fix_release]]
+for details about some necessary behavior changes,
+and if you're curious about the details of the security holes,
+see [[the advisory|security/CVE-2018-10857_and_CVE-2018-10859]].
+
+I've been dealing with these security holes for the past week and a half,
+and decided to use a security embargo while fixes were being developed
+due to the complexity of addressing security holes that impact both
+git-annex and external special remote programs. For the full story
+see past 5 posts in this devblog, which are being published all together
+now that the embargo is lifted.
+
+[[!meta date="Jun 26 2018 12:00 pm"]]
diff --git a/doc/devblog/day_506__summer_features.mdwn b/doc/devblog/day_506__summer_features.mdwn
new file mode 100644
index 0000000000..52eea6a454
--- /dev/null
+++ b/doc/devblog/day_506__summer_features.mdwn
@@ -0,0 +1,38 @@
+After the big security fix push, I've had a bit of a vacation. Several new
+features have also landed in git-annex though.
+
+git-worktree support is a feature I'm fairly excited by.
+It turned out to be possible to make git-annex just work in working trees
+set up by `git worktree`, and they share the same object files. So,
+if you need several checkouts of a repository for whatever reason,
+this makes it really efficient to do. It's much better than the old
+method of using `git clone --shared`.
+
+A new `--accessedwithin` option matches files whose content was accessed
+within a given amount of time. (Using the atime.) Of course it can
+be combined with other options, for example
+`git annex move --to archive --not --accessedwithin=30d`  
+There are a few open requests for other new file matching options that I
+hope to get to soon.
+
+A small configuration addition of remote.name.annex-speculate-present
+to make git-annex try to get content from a remote even if its records
+don't indicate the remote contains the content allows setting up an interesting
+kind of [local cache of annexed files](https://git-annex.branchable.com/tips/local_caching_of_annexed_files/)
+which can even be shared between unrelated git-annex repositories, with
+inter-repository deduplication. 
+
+I suspect that remote.name.annex-speculate-present may also have other
+uses. It warps git-annex's behavior in a small but fundamental way which
+could let it fit into new places. Will be interesting to see.
+
+There's also a annex.commitmessage config, which I am much less excited by,
+but enough people have asked for it over the years.
+
+Also fixed a howler of a bug today: In -J mode, remotes were sorted not
+by cost, but by UUID! How did that not get noticed for 2 years?
+
+Much of this work was sponsored by NSF-funded DataLad project at Dartmouth
+Colledge, as has been the case for the past 4 years. All told they've
+funded over 1000 hours of work on git-annex. This is the last month of that
+funding.
diff --git a/doc/devblog/day_507__v6_revisited.mdwn b/doc/devblog/day_507__v6_revisited.mdwn
new file mode 100644
index 0000000000..cb8bcaa473
--- /dev/null
+++ b/doc/devblog/day_507__v6_revisited.mdwn
@@ -0,0 +1,23 @@
+Plan is to take some time this August and revisit v6, hoping to move it
+toward being production ready.
+
+Today I studied the "Long Running Filter Process" documentation in
+gitattributes(5), as well as the supplimental documentation in git about
+the protocol they use. This interface was added to git after v6 mode was
+implemented, and hopefully some of v6's issues can be fixed by using it in
+some way. But I don't know how yet, it's not as simple as using this
+interface as-is (it was designed for something different), but
+finding a creative trick using it.
+
+So far I have [this idea](http://git-annex.branchable.com/todo/Long_Running_Filter_Process/#comment-7c571c4ed26ce370ccd48db0a4aff4fc)
+to explore. It's promising, might fix the worst of the problems.
+
+Also, reading over all the notes in [[todo/smudge]], I finally
+checked and yes, git doesn't require filters to consume all stdin anymore,
+and when they don't consume stdin, git doesn't leak memory anymore either.
+Which let me massively speed up `git add` in v6 repos. While before `git
+add` of a gigabyte file made git grow to a gigabyte in memory and copied a
+gigabyte through a pipe, it's now just as fast as `git annex add` in v5
+mode is.
+
+This work is supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_508__git-protocol.mdwn b/doc/devblog/day_508__git-protocol.mdwn
new file mode 100644
index 0000000000..b3de2ffa8a
--- /dev/null
+++ b/doc/devblog/day_508__git-protocol.mdwn
@@ -0,0 +1,20 @@
+Spent today implementing the git pkt-line protocol. Git uses it for a bunch
+of internal stuff, but also to talk to long-running filter processes.
+
+This was my first time using attoparsec, which I quite enjoyed aside from
+some difficulty in parsing a 4 byte hex number. Even though parsing to a
+Word16 should naturally only consume 4 bytes, attoparsec will actually
+consume subsequent bytes that look like hex. And it may parse fewer than 4
+bytes too. So my parser had to take 4 bytes and feed them back into a call
+to attoparsec. Which seemed weird, but works. I also used
+bytestring-builder, and between the two libraries, this should be quite a
+fast implementation of the protocol.
+
+With that 300 lines of code written, it should be easy to implement support
+for the rest of the long-running filter process protocol. Which will surely
+speed up v6 a bit, since at least git won't be running git-annex over and
+over again for each file in the worktree. I hope it will also avoid a memory
+leak in git. That'll be the rest of the low-hanging fruit, before v6
+improvements get really interesting.
+
+This work is supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_509__filterdriver.mdwn b/doc/devblog/day_509__filterdriver.mdwn
new file mode 100644
index 0000000000..8bc6fc9c4a
--- /dev/null
+++ b/doc/devblog/day_509__filterdriver.mdwn
@@ -0,0 +1,16 @@
+Working on a "filterdriver" branch, I've implemented support for the
+long-running smudge/clean process interface.
+
+It works, but not really any better than the old smudge/clean interface.
+Unfortunately git leaks memory just as badly in the new interface as it did
+in the old interface when sending large data to the smudge filter. Also,
+the new interface requires that the clean filter read all the content of the
+file from git, even when it's just going to look at the file on disk, so
+that's worse performance.
+
+So, I don't think I'll be merging that branch yet, but git's interface does
+support adding capabilities, and perhaps a capability could be added that
+avoids it schlepping the file content over the pipe. Same as my old git
+patches tried to do with the old smudge/clean interface.
+
+This work is supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_50__grab_bag.mdwn b/doc/devblog/day_50__grab_bag.mdwn
new file mode 100644
index 0000000000..e38ec065c7
--- /dev/null
+++ b/doc/devblog/day_50__grab_bag.mdwn
@@ -0,0 +1,34 @@
+Started by tracking down a strange bug that was apparently
+ubuntu-specific and caused git-annex branch changes to get committed to
+master. Root cause turned out to failing to recover from an
+exception. I'm kicking myself about that, because I remember looking at the
+code where the bug was at least twice before and thinking "hmm, should add
+exception handling here? nah..". Exceptions are horrible.
+
+Made a release with a fix for that and a few minor other accumulated
+changes since last Friday's release. The pain point of this release is to
+fix building without the webapp (so it will propigate to Debian testing,
+etc). This release does not include the direct mode guard, so I'll have a
+few weeks until the next release to get that tested.
+
+Fixed the test suite in `directguard`. This branch is now nearly ready to
+merge to master, but one command that is badly needed in guarded direct
+mode is "git status". So I am planning to rename "git annex status" to
+"git annex info", and make "git annex status" display something similar
+to "git status".
+
+Also took half an hour and added optional [[EKG]] support to git-annex.
+This is a Haskell library that can add a terrific monitoring console web
+UI to any program in 2 lines of code. Here we can see the git-annex
+webapp using resources at startup, followed in a few seconds by the
+assistant's startup scan of the repository.
+
+[[!img ekg/ekg.png]]
+
+BTW, Kevin tells me that the machine used to build git-annex for OSX is
+going to be upgraded to 10.9 soon. So, hopefully I'll be making autobuilds
+of that. I may have to stop the 10.8.2 autobuilds though.
+
+----
+
+Today's work was sponsored by [Protonet](http://protonet.info/).
diff --git a/doc/devblog/day_50__grab_bag/comment_1_01846f6494fe843889391fd09fd127a0._comment b/doc/devblog/day_50__grab_bag/comment_1_01846f6494fe843889391fd09fd127a0._comment
new file mode 100644
index 0000000000..1c17171808
--- /dev/null
+++ b/doc/devblog/day_50__grab_bag/comment_1_01846f6494fe843889391fd09fd127a0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="OS X builds"
+ date="2013-11-07T05:12:13Z"
+ content="""
+Joey, were you not interested in my offer of an OS X build server that I've posted elsewhere on this list, and also in e-mail to you?
+"""]]
diff --git a/doc/devblog/day_50__grab_bag/comment_2_12736014aa2c1af81e4b83072505e7d5._comment b/doc/devblog/day_50__grab_bag/comment_2_12736014aa2c1af81e4b83072505e7d5._comment
new file mode 100644
index 0000000000..70d7b7cd16
--- /dev/null
+++ b/doc/devblog/day_50__grab_bag/comment_2_12736014aa2c1af81e4b83072505e7d5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 2"
+ date="2013-11-07T16:01:00Z"
+ content="""
+John, must have missed that; can't see to find it anywhere..
+"""]]
diff --git a/doc/devblog/day_510__v6_get_drop_index.mdwn b/doc/devblog/day_510__v6_get_drop_index.mdwn
new file mode 100644
index 0000000000..9cd7e805b7
--- /dev/null
+++ b/doc/devblog/day_510__v6_get_drop_index.mdwn
@@ -0,0 +1,14 @@
+I've now fixed the worst problem with v6 mode, which was that get/drop of
+unlocked files would cause git to think that the files were modified.
+
+Since the clean filter now runs quite fast, I was able to fix that by,
+after git-annex updates the worktree, restaging the not-really-modified 
+file in the index.
+
+This approach is not optimal; index file updates have overhead; and only
+one process can update the index file at one time. [[todo/smudge]] has a
+bunch of new todo items for cases where this change causes problems. Still,
+it seems a lot better than the old behavior, which made v6 mode nearly
+unusable IMHO.
+
+This work is supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_510__v6_get_drop_index/comment_1_0e2eff8c8c3aaef3499b8f94b2733148._comment b/doc/devblog/day_510__v6_get_drop_index/comment_1_0e2eff8c8c3aaef3499b8f94b2733148._comment
new file mode 100644
index 0000000000..42a871a147
--- /dev/null
+++ b/doc/devblog/day_510__v6_get_drop_index/comment_1_0e2eff8c8c3aaef3499b8f94b2733148._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 1"
+ date="2018-08-17T14:44:13Z"
+ content="""
+> I've now fixed the worst problem with v6 mode, which was that get/drop of
+> unlocked files would cause git to think that the files were modified.
+
+\o/
+
+I have been using v6 lately and did not know that this was a known
+issue; I assumed I was doing something wrong.
+
+Thank you!
+"""]]
diff --git a/doc/devblog/day_511__v6_improved_index_update.mdwn b/doc/devblog/day_511__v6_improved_index_update.mdwn
new file mode 100644
index 0000000000..989aa1feab
--- /dev/null
+++ b/doc/devblog/day_511__v6_improved_index_update.mdwn
@@ -0,0 +1,13 @@
+Found a better way to update the index after get/drop in v6 repositories.
+I was able to close all the todos around that.
+
+Only problem is there is a race where a modification that happens to a file
+soon after get/drop gets unexpectedly staged by the index update. I made
+this race's window as small as I reasonably can. Fully fixing it would
+involve improvements to the git update-index interface, or another way to
+update the index.
+
+Only two todos remain in [[todo/smudge]] that
+I want to fix in the remainder of this v6 sprint.
+
+This work is supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_512__fixed_race.mdwn b/doc/devblog/day_512__fixed_race.mdwn
new file mode 100644
index 0000000000..94f5d920ad
--- /dev/null
+++ b/doc/devblog/day_512__fixed_race.mdwn
@@ -0,0 +1,5 @@
+Sleeping on that race from yesterday, I realized there is a way to fix it,
+and have implemented the fix. It doubled the overhead of updating the
+index, but that's worth it to not have a race condition to worry about.
+
+This work is supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_513__v6_reconciling_staged_changes.mdwn b/doc/devblog/day_513__v6_reconciling_staged_changes.mdwn
new file mode 100644
index 0000000000..aeb22aad5d
--- /dev/null
+++ b/doc/devblog/day_513__v6_reconciling_staged_changes.mdwn
@@ -0,0 +1,21 @@
+More v6 work. Got most of the way to a solution to the problem of updating
+the associated files database for staged changes to unlocked files, eg a
+`git mv`.
+
+While writing the test case, I was surprised to find that the problem
+is timing dependent. If a `git mv` is run less than a second after `git
+add`, git runs the smudge filter for whatever reason, which avoids the
+problem. With a longer delay, it doesn't run the smudge filter. Seems this
+could be the cause of intermittent glitches with v6 mode, and I've seen a
+few such glitches before.
+
+Anyway, I developed an inexpensive way to find the relevant staged changes,
+using `git diff` with a full page of options to tweak its behavior just
+right. Still need to make that only run when the index has changed, not
+every time git-annex runs.
+
+There's still a race between a command like `git mv` and `git annex
+drop/get`, that can result in the unlocked file's content not being
+updated. Don't have a solution to that yet.
+
+This work is supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_514__fixed_5_races_in_v6.mdwn b/doc/devblog/day_514__fixed_5_races_in_v6.mdwn
new file mode 100644
index 0000000000..b400555290
--- /dev/null
+++ b/doc/devblog/day_514__fixed_5_races_in_v6.mdwn
@@ -0,0 +1,9 @@
+That's a lot of races! Well, 4 of them were all related, but the fixes to
+them had to be made in two different places.
+
+Hopefully that's all the v6 races fixed. I've been finding these races by
+inspection, who knows if I missed some. Anyway, I'm now down to one todo
+item left on the v6 sprint. Gonna take a break for a couple days before
+tackling it.
+
+This work is supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_514__v6_bug_review.mdwn b/doc/devblog/day_514__v6_bug_review.mdwn
new file mode 100644
index 0000000000..f50571f26b
--- /dev/null
+++ b/doc/devblog/day_514__v6_bug_review.mdwn
@@ -0,0 +1,25 @@
+Looked over bugs filed about v6 mode and did some triage and analysis.
+[[todo/smudge]] has the details.
+
+This led to changing what's done by `git add` and `git commit file` when
+annex.largefiles is not configured. Rather than behaving like `git annex
+add` and always storing the file in the annex, it will store it in the
+annex if the old version was annexed, and in git if the old version was
+stored in git. This avoids accidental conversions.
+
+It might make sense to have `git annex add` also do this, even in v5
+repositories, but I want to concentrate on v6 for now, and also don't
+think that `git add` and `git annex add` necessarily need to behave
+identically in v6 mode. While using `git commit -a` doesn't imply
+anything about whether you want the file in git or the annex,
+using `git-annex add` seems to imply they you want it in
+the annex, unless you've gone out of your way to configure otherwise.
+
+----
+
+Also did some design work on supporting versioned S3 buckets with
+`git-annex export`.
+
+----
+
+This work is supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_515__S3_exporttree_with_versioning.mdwn b/doc/devblog/day_515__S3_exporttree_with_versioning.mdwn
new file mode 100644
index 0000000000..27ff00d5aa
--- /dev/null
+++ b/doc/devblog/day_515__S3_exporttree_with_versioning.mdwn
@@ -0,0 +1,10 @@
+Most of the way done with implementing support for export to S3 buckets
+with versioning enabled. This will make the files from the most recent
+`git annex export` be visible to users browsing the bucket, while letting
+git-annex download any of the content from previous exports too.
+
+Still need to test it. And, deletion of old content from such a bucket is
+not supported, and my initial thoughts are that it might not be possible
+in a multi-writer situation. I need to think about it more.
+
+This work is supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_516__S3_exporttree_with_versioning_continued.mdwn b/doc/devblog/day_516__S3_exporttree_with_versioning_continued.mdwn
new file mode 100644
index 0000000000..cd57d5be94
--- /dev/null
+++ b/doc/devblog/day_516__S3_exporttree_with_versioning_continued.mdwn
@@ -0,0 +1,19 @@
+Finished this feature, and I'm liking it quite a lot!
+Though I had to put off [[todo/support_public_versioned_S3_access]] until
+some other time as I'm all out of time and energy.
+
+The storage of S3 version IDs got rethought -- I was not comfortable with
+using per-remote state in the git-annex branch which would have caused
+problems if dropping from these remotes later gets supported.
+
+So, I added per-remote metadata in about 1 hour! It's like git-annex's regular
+metadata, but scoped so only the remote that owns it can see it. This is
+perfect for storing things like S3 version IDs. It probably ought to be added
+to the external special remote interface since it could be used for lots of
+stuff.
+
+Here's how that looks when S3 version IDs are stored in it:
+
+	1535737778.867692782s 31ea6c94-fba3-4952-99b5-285ae192d92a:V +woYHK59DD2VUkJfg527mEBBqtCaPlSXn#myfile
+
+This work was supported by the NSF-funded DataLad project.
diff --git a/doc/devblog/day_517__return_to_crowdfunding.mdwn b/doc/devblog/day_517__return_to_crowdfunding.mdwn
new file mode 100644
index 0000000000..0d4f03db97
--- /dev/null
+++ b/doc/devblog/day_517__return_to_crowdfunding.mdwn
@@ -0,0 +1,9 @@
+Back to being only [crowdfunded](https://patreon.com/joeyh) now.
+
+Several little things today, including a git-annex.cabal patch from
+fftehnik that fixed building without the assistant, and supporting
+`AWS_SESSION_TOKEN`. The main work was on making `git annex drop --dead`
+prune obsolete per-remote metadata, and on fixing a bug in v6 mode that
+left git-annex object files writable.
+
+Today's work was sponsored by Paul Walmsley in honor of Mark Phillips.
diff --git a/doc/devblog/day_518__S3_versioning_finishing_touches.mdwn b/doc/devblog/day_518__S3_versioning_finishing_touches.mdwn
new file mode 100644
index 0000000000..57c79049cb
--- /dev/null
+++ b/doc/devblog/day_518__S3_versioning_finishing_touches.mdwn
@@ -0,0 +1,39 @@
+Got git-annex downloading versioned files from S3, without needing S3
+credentials. This makes a S3 special remote be equally capable as a
+git-annex repository exported over http, other than of course not including
+the git objects.
+
+An example of this new feature:
+
+	AWS_SECRET_ACCESS_KEY=... AWS_ACCESS_KEY_ID=...
+	git annex initremote s3 type=S3 public=yes exporttree=yes versioning=yes
+	git annex export --tracking master --to s3
+	git tag 1.0
+	# modify some files here
+	git annex sync --content s3
+
+And then in a clone without the credentials:
+
+	git annex enableremote s3
+	git checkout 1.0
+	git annex get somefile
+
+This is nice; I only wish it were supported by other special remotes.
+It seems that any special remote could be made to support it, but ones not
+supporting some kind of versioning would need to store each file twice,
+and many would also need each file to be uploaded to them twice. But
+perhaps there are others that do have a form of versioning.
+WebDAV for one has a versioning extension in RFC 3253.
+
+Also did a final review of a patch Antoine Beaupré is working on to
+backport the recent git-annex security fixes to debian oldstable,
+git-annex 5.20141125. He described the backport [in his blog](https://anarc.at/blog/2018-08-31-report/):
+
+> This time again, Haskell was nice to work with: by changing type
+> configurations and APIs, the compiler makes sure that everything works out and
+> there are no inconsistencies. This logic is somewhat backwards to what we are
+> used to: normally, in security updates, we avoid breaking APIs at all costs.
+> But in Haskell, it's a fundamental way to make sure the system is still
+> coherent.
+
+Today's work was sponsored by Trenton Cronholm [on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_518__S3_versioning_finishing_touches/comment_1_aed297f65b6e555f338fc622a8678c0f._comment b/doc/devblog/day_518__S3_versioning_finishing_touches/comment_1_aed297f65b6e555f338fc622a8678c0f._comment
new file mode 100644
index 0000000000..b4b7e84750
--- /dev/null
+++ b/doc/devblog/day_518__S3_versioning_finishing_touches/comment_1_aed297f65b6e555f338fc622a8678c0f._comment
@@ -0,0 +1,121 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="what to be done for previously exported instances?"
+ date="2018-09-10T17:03:16Z"
+ content="""
+OpenNeuro folks have been exporting their datasets for a while by now using older git-annex, which didn't have all the recent \"public S3\" support implemented.  What changes should be done on their end so git-annex could get those files (ATM --debug output and error message give no information on why access is failing)?  Here is an example repository/dataset:
+[[!format sh \"\"\"
+$> git clone https://github.com/OpenNeuroDatasets/ds001506 ; cd ds001506; 
+Cloning into 'ds001506'...                                                
+remote: Counting objects: 10911, done.
+remote: Compressing objects: 100% (6624/6624), done.
+remote: Total 10911 (delta 1820), reused 10911 (delta 1820), pack-reused 0
+Receiving objects: 100% (10911/10911), 1.16 MiB | 0 bytes/s, done.
+Resolving deltas: 100% (1820/1820), done.
+
+$> git annex info s3-PUBLIC                                              
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+download failed: Not Found
+
+  Remote origin not usable by git-annex; setting annex-ignore
+uuid: ca9b233b-7567-48b3-89c7-efe7f6a97d4a
+description: s3-PUBLIC
+remote annex keys: 1288
+remote annex size: 103.29 gigabytes (+ 632 unknown size)
+
+$> git annex info          
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 6
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	810b2f6b-fb98-4401-9130-6c84dd7ddc50 -- root@b3ba225d5547:/datalad/ds001506
+ 	8fdca7f0-84c3-4b1b-af9a-453effd5380c -- s3-PRIVATE
+ 	b2a25c10-6db6-4e7c-8490-b16837fff749 -- yoh@hopa:/tmp/ds001506 [here]
+ 	ca9b233b-7567-48b3-89c7-efe7f6a97d4a -- s3-PUBLIC
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 21.98 gigabytes (+1 megabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 665
+size of annexed files in working tree: 104.83 gigabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+	MD5E: 665
+
+$> git annex enableremote s3-PUBLIC                                          
+
+enableremote s3-PUBLIC ok          
+(recording state in git...)
+
+$> git annex get --from s3-PUBLIC sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz
+get sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz (from s3-PUBLIC...) failed
+git-annex: get: 1 failed
+
+$> git annex get --debug --from s3-PUBLIC sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz 
+[2018-09-10 12:53:35.937741872] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2018-09-10 12:53:35.946999706] process done ExitSuccess
+[2018-09-10 12:53:35.947122637] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-09-10 12:53:35.951493681] process done ExitSuccess
+[2018-09-10 12:53:35.951694627] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..566bcf31d8d24f0e03df73d7c2196092e6fce39e\",\"--pretty=%H\",\"-n1\"]
+[2018-09-10 12:53:35.955844481] process done ExitSuccess
+[2018-09-10 12:53:35.956107478] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-10 12:53:35.956674577] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-10 12:53:35.963580866] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz\"]
+get sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz (from s3-PUBLIC...) failed
+[2018-09-10 12:53:35.991800587] process done ExitSuccess
+[2018-09-10 12:53:35.992039867] process done ExitSuccess
+git-annex: get: 1 failed
+
+$> git annex version
+git-annex version: 6.20180807+git230-gaa291acfe-1~ndall+1
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.12 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+local repository version: 5
+
+$> git annex whereis sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz
+whereis sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz (2 copies) 
+  	810b2f6b-fb98-4401-9130-6c84dd7ddc50 -- root@b3ba225d5547:/datalad/ds001506
+   	8fdca7f0-84c3-4b1b-af9a-453effd5380c -- s3-PRIVATE
+
+  The following untrusted locations may also have copies:
+  	ca9b233b-7567-48b3-89c7-efe7f6a97d4a -- [s3-PUBLIC]
+ok
+
+$> datalad ls s3://openneuro.org/ds001506/sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz
+Connecting to bucket: openneuro.org                                                            
+[INFO   ] S3 session: Connecting to the bucket openneuro.org anonymously 
+Bucket info:
+  Versioning: S3ResponseError: 403 Forbidden
+     Website: S3ResponseError: 403 Forbidden
+         ACL: <Policy: openneurocommon (owner) = FULL_CONTROL, http://acs.amazonaws.com/groups/global/AllUsers = READ, rblair2 = FULL_CONTROL, http://acs.amazonaws.com/groups/global/AllUsers = READ_ACP>
+ds001506/sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz 2018-09-10T14:20:22.000Z 11697980 
+
+$> datalad ls --list-content md5 -L s3://openneuro.org/ds001506/sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz 
+Connecting to bucket: openneuro.org
+[INFO   ] S3 session: Connecting to the bucket openneuro.org anonymously 
+Bucket info:
+  Versioning: S3ResponseError: 403 Forbidden
+     Website: S3ResponseError: 403 Forbidden
+         ACL: <Policy: openneurocommon (owner) = FULL_CONTROL, http://acs.amazonaws.com/groups/global/AllUsers = READ, rblair2 = FULL_CONTROL, http://acs.amazonaws.com/groups/global/AllUsers = READ_ACP>
+ds001506/sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz 2018-09-10T14:20:22.000Z 11697980 ver:snn1VMlJ8hgxd42_Dy1dXuiyBCwd00eZ  acl:AccessDenied  http://openneuro.org.s3.amazonaws.com/ds001506/sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz?versionId=snn1VMlJ8hgxd42_Dy1dXuiyBCwd00eZ [OK] f8e1e6ec4efe752b86a7e5885d64e131
+
+$> ls -ld sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz                            
+lrwxrwxrwx 1 yoh yoh 145 Sep 10 12:53 sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz -> ../../../.git/annex/objects/fq/V7/MD5E-s11697980--f8e1e6ec4efe752b86a7e5885d64e131.nii.gz/MD5E-s11697980--f8e1e6ec4efe752b86a7e5885d64e131.nii.gz
+
+\"\"\"]]
+
+so file is available from S3, matches the checksum, but `git annex get` just fails to get it without giving any clarification on why.
+If I add `versioning=yes` to enableremote then it starts asking for the AWS credentials.
+
+Thank you in advance for looking into it.
+
+"""]]
diff --git a/doc/devblog/day_518__S3_versioning_finishing_touches/comment_2_a981371786ba702ac616cd55b296bc1c._comment b/doc/devblog/day_518__S3_versioning_finishing_touches/comment_2_a981371786ba702ac616cd55b296bc1c._comment
new file mode 100644
index 0000000000..3c7a5736e3
--- /dev/null
+++ b/doc/devblog/day_518__S3_versioning_finishing_touches/comment_2_a981371786ba702ac616cd55b296bc1c._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-09-11T16:17:09Z"
+ content="""
+What they'll need to do is:
+
+1. Enableremote with versioning=yes
+2. Manually update the git-annex branch location tracking
+   info for older versions of exported files so git-annex knows that the files
+   are still stored in S3. Ie, `git-annex setpresentkey`
+3. Add remote metadata log files to git-annex branch so that the S3 remote knows
+   the S3 version ID for all the already updated files.
+
+The third item is surely going to involve some work since they'll have to
+gather the S3 version IDs, match them up with git-annex keys for the file
+that was uploaded at that point, and manually generate files to
+commit to the git-annex branch. The rmet log file for S3 looks like:
+
+	timestamp uuid:V +versionid#filename
+
+For example, for a file that was uploaded to the bucket as "myfile":
+
+	1535737778.867692782s 31ea6c94-fba3-4952-99b5-285ae192d92a:V +woYHK59DD2VUkJfg527mEBBqtCaPlSXn#myfile
+
+Note that if the filename contains spaces it gets more complicated and it
+would probably be worth adding some plumbing command to git-annex to set
+per-remote metadata.
+
+----
+
+As to the problems you're having with that S3 remote, it looks like
+it does not have public=yes enabled in its configuration at all, which is
+why git-annex is failing to download from it. It kind of looks like you
+have some other S3 creds in the environment, otherwise I'd expect git-annex
+to complain that the remote is not public and no creds are set. Or maybe a
+bug in the handling of that case. devblog doesn't seem like the place to
+dig into that..
+"""]]
diff --git a/doc/devblog/day_518__S3_versioning_finishing_touches/comment_3_08de1605f1aa8b042ba3c4b710939989._comment b/doc/devblog/day_518__S3_versioning_finishing_touches/comment_3_08de1605f1aa8b042ba3c4b710939989._comment
new file mode 100644
index 0000000000..bca50a3620
--- /dev/null
+++ b/doc/devblog/day_518__S3_versioning_finishing_touches/comment_3_08de1605f1aa8b042ba3c4b710939989._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2018-09-11T16:53:38Z"
+ content="""
+Thank you Joey!
+"""]]
diff --git a/doc/devblog/day_519__release_prep.mdwn b/doc/devblog/day_519__release_prep.mdwn
new file mode 100644
index 0000000000..bff6916bc7
--- /dev/null
+++ b/doc/devblog/day_519__release_prep.mdwn
@@ -0,0 +1,10 @@
+I'm in release prep mode now, fixing build problems and a few bugs, but
+the v6 sprint is well over, though v6 still has its issues.
+Might as well release all the last month's work.
+
+Yesterday was taken up with dealing with some very ugly git interface
+stuff that changed between versions. An July workaround for a bug in
+git turns out to have caused reversions with older versions, and was not
+a complete fix either. Tuned it to hopefully work better.
+
+This was sponsored by Jake Vosloo [on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_51__direct_mode_guard_finished.mdwn b/doc/devblog/day_51__direct_mode_guard_finished.mdwn
new file mode 100644
index 0000000000..9c637aa949
--- /dev/null
+++ b/doc/devblog/day_51__direct_mode_guard_finished.mdwn
@@ -0,0 +1,6 @@
+Finished the direct mode guard, including the new `git annex status`
+command.
+
+Spent the rest of the day working on various bug fixes. One of them turned
+into rather a lot of work to make the webapp's UI better for git
+remotes that do not have an annex.uuid.
diff --git a/doc/devblog/day_520__storm_before_the_calm.mdwn b/doc/devblog/day_520__storm_before_the_calm.mdwn
new file mode 100644
index 0000000000..62acfd0d8f
--- /dev/null
+++ b/doc/devblog/day_520__storm_before_the_calm.mdwn
@@ -0,0 +1,10 @@
+Well it took the whole day to finish the release. Including fixing a
+deadlock when the new v6 code runs with an older git, and some build
+errors. Ant there's still an intermittent test suite failure involving v6 on
+one autobuilder, which will need to be dealt with later.
+
+This is a big release, lots of bug fixes, lots of v6 improvements, and
+significant S3 improvements.
+
+Today's work was sponsored by Paul Walmsley 
+[on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_521__newlines_in_filenames.mdwn b/doc/devblog/day_521__newlines_in_filenames.mdwn
new file mode 100644
index 0000000000..1eccb59bfe
--- /dev/null
+++ b/doc/devblog/day_521__newlines_in_filenames.mdwn
@@ -0,0 +1,21 @@
+Unix would be better if filenames could not contain newlines. But they can,
+and so today was spent dealing with some technical debt.
+
+The main problem with using git-annex with filenames with newlines is that
+`git cat-file --batch` uses a line-based protocol. It would be nice if that
+were extended to support `-z` like most of the rest of git does, but I
+realized I could work around this by not using batch mode for the rare
+filename with a newline. Handling such files will be slower than other
+files, but at least it will work.
+
+Then I realized that git-annex has its own problems with its `--batch`
+option and files with newlines. So I added support for `-z` to every batchable
+command in git-annex, including a couple of commands that did batch input
+without a `--batch` option.
+
+Now git-annex should fully support filenames containing newlines, as well 
+as anything else. The best thing to do if you have such a file is to
+commit it and then `git mv` it to a better name.
+
+Today's work was sponsored by Trenton Cronholm 
+[on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_522__multi.mdwn b/doc/devblog/day_522__multi.mdwn
new file mode 100644
index 0000000000..99b3dc01bb
--- /dev/null
+++ b/doc/devblog/day_522__multi.mdwn
@@ -0,0 +1,7 @@
+Started work on <http://git-annex.branchable.com/todo/to_and_from_multiple_remotes/>.
+It's going slow, I had to start with a large refactoring. So far, option
+parsing is working, and a few commands are almost working, but concurrency
+is not working right, and concurrency is the main reason to want to support
+this (along with remote groups).
+
+Today's work was supported by Jake Vosloo [on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_523__backlog.mdwn b/doc/devblog/day_523__backlog.mdwn
new file mode 100644
index 0000000000..1894d4c982
--- /dev/null
+++ b/doc/devblog/day_523__backlog.mdwn
@@ -0,0 +1,13 @@
+So I've been catching up on backlog for a couple of days. Including reading
+all the old todos, and closing a bunch of them that turned out to have been
+implemented already.
+
+Today I added an annex.jobs setting, fixed annex.web-options
+which was broken in the semi-recent security update,
+and fixed a very tricky bug in rmurl.
+
+(What happened to the <http://git-annex.branchable.com/todo/to_and_from_multiple_remotes/>
+I was working on earlier this week? When I looked at the details, it was
+much more complicated than I had thought. Back burnered.)
+
+Today's work was sponsored by Jake Vosloo [on Patreon](https://patreon.com/joeyh/).
diff --git a/doc/devblog/day_524__new_phone.mdwn b/doc/devblog/day_524__new_phone.mdwn
new file mode 100644
index 0000000000..3bacd9f03d
--- /dev/null
+++ b/doc/devblog/day_524__new_phone.mdwn
@@ -0,0 +1,17 @@
+Been making some improvements to `git-annex export` over the past couple
+days, but took time off this afternoon to set up a new phone, and try
+[git-annex in termux](https://git-annex.branchable.com/tips/install_on_Android_in_Termux/)
+on it. Luckily, I was able to reproduce the signal 11
+on arm64 problem that several users have reported earlier, and also found a fix,
+which is simply to build git-annex for arm64.
+
+So I want to set up a [[todo/arm64_autobuilder]], and if someone has an
+arm64 server that could host it, that would be great. Otherwise, I could
+use Scaleway, but I'd rather avoid that ongoing expense.
+
+Also fixed a recent reversion in the linux standalone 
+runshell that broke git-annex in termux, and probably on some other
+systems.
+
+Today's work was sponsored by Trenton Cronholm
+[on Patreon](https://patreon.com/joeyh)
diff --git a/doc/devblog/day_52__slowly_but_surely.mdwn b/doc/devblog/day_52__slowly_but_surely.mdwn
new file mode 100644
index 0000000000..01019355bd
--- /dev/null
+++ b/doc/devblog/day_52__slowly_but_surely.mdwn
@@ -0,0 +1,5 @@
+Been chipping away at my backlog of messages, and it's down to 23 items.
+
+Finally managed to get ghc to build with a newer version of the NDK.
+This *might* mean a solution to git-annex on Android 4.2. I 
+[need help with testing](http://git-annex.branchable.com/bugs/git-annex_broken_on_Android_4.3/#comment-90b82735cd6090a7765f423b743fffd3).
diff --git a/doc/devblog/day_545__termux_improvements.mdwn b/doc/devblog/day_545__termux_improvements.mdwn
new file mode 100644
index 0000000000..dcdcc0ce50
--- /dev/null
+++ b/doc/devblog/day_545__termux_improvements.mdwn
@@ -0,0 +1,13 @@
+I've improved the termux installation, adding an installer script to make
+it easier, and fixing some issues that have been reported. And it supports
+arm64 and also should work on Intel android devices. 
+This feels very close to being able to remove the old deprecated Android
+apps.
+
+I'm temporarily running the arm64 builds on my phone, in a Debian chroot. But
+it overheats, so this is a stopgap and it won't autobuild daily, only manually
+at release time.
+
+Released git-annex 6.20181011.
+
+Today's work was sponsored by Jake Vosloo [on Patreon](http://patreon.com/joeyh/).
diff --git a/doc/devblog/day_546__deleted_40_thousand_lines_of_code.mdwn b/doc/devblog/day_546__deleted_40_thousand_lines_of_code.mdwn
new file mode 100644
index 0000000000..ee51cd19a3
--- /dev/null
+++ b/doc/devblog/day_546__deleted_40_thousand_lines_of_code.mdwn
@@ -0,0 +1,14 @@
+Pulled the trigger on the old Android builds, and made a 
+[massive commit](http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=38d691a10febf9590dd3639defa0e4f38ec3648c)
+removing all the cruft that had built up to enable them. Running in Termux
+is just better. It's important to note this does not mean I've given up on
+more native git-annex Android stuff, indeed there are promising
+developments in ghc Android support that I'm keeping an eye on.
+
+I'll kind of miss the EvilSplicer, that was 750 lines of crazy code to be
+proud of. But really, it's going to be great to not have hanging over me
+the prospect that any change could break the Android build and end up
+needing tons of work to resolve.
+
+Today's work was sponsored by Trenton Cronholm 
+[on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_547__v6_almost_complete.mdwn b/doc/devblog/day_547__v6_almost_complete.mdwn
new file mode 100644
index 0000000000..3e8cbe8c29
--- /dev/null
+++ b/doc/devblog/day_547__v6_almost_complete.mdwn
@@ -0,0 +1,12 @@
+No time to blog yesterday, but I somehow found the time to fix the second
+to last known major issue with v6 mode, a database inconsistency problem
+involving touching annexed files.
+
+The only remaining blocker for v6 not being experimental is that `git
+checkout` of large unlocked files can use a lot of memory (and doesn't
+honor annex.thin).
+
+Also I finally have a rought plan for how to [[todo/hide_missing_files]]:
+Have `git annex sync` update the working tree to only show visible files.
+Still details to work out, but it would be great to finally get this
+often-requested feature.
diff --git a/doc/devblog/day_548__hiding_missing_files.mdwn b/doc/devblog/day_548__hiding_missing_files.mdwn
new file mode 100644
index 0000000000..5f26183083
--- /dev/null
+++ b/doc/devblog/day_548__hiding_missing_files.mdwn
@@ -0,0 +1,18 @@
+At long last there's a way to hide annexed files whose content
+is missing from the working tree: `git-annex adjust --hide-missing`
+
+And once you've run that command, `git annex sync` will update the tree
+to hide/unhide files whose content availability has changed.
+(So will running `git annex adjust` again with the same options.)
+
+You can also combine `--hide-missing` with `--unlock`, which should prove
+useful in a lot of situations.
+
+My implementation today is as simple as possible, which means that every
+time it updates the adjusted branch it does a full traversal of the
+original branch, checks content availability, and generates a new branch.
+So it may not be super fast in a large repo, but I was able to implement
+it in one day's work. It should be possible later to speed it up a
+lot, by [maintaining more state](http://git-annex.branchable.com/todo/hide_missing_files/#comment-5f56545b69a0baebffe5411258ee30ea).
+
+Today's work was sponsored by Ethan Aubin.
diff --git a/doc/devblog/day_549__operating_on_hidden_files.mdwn b/doc/devblog/day_549__operating_on_hidden_files.mdwn
new file mode 100644
index 0000000000..71d41931ac
--- /dev/null
+++ b/doc/devblog/day_549__operating_on_hidden_files.mdwn
@@ -0,0 +1,52 @@
+Goal for today was to make `git annex sync --content` operate on files hidden by
+`git annex adjust --hide-missing`. However, this got into the weeds pretty
+quickly due to the problem of how to handle `--content-of=path` when
+either the whole path or some files within it may be hidden.
+
+Eventually I discovered that `git ls-files --with-tree` can be used to
+get a combined list of files in the index plus files in another tree,
+which in git-annex's case is the original branch that got adjusted.
+It's not documented to work the way I'm using it (worrying), but it's
+perfect, because git-annex already uses `git ls-files` extensively and this
+could let lots of commands get support for operating on hidden files.
+
+That said, I'm going to limit it to `git annex sync` for now,
+because it would be a lot of work to make lots of commands support them,
+and there could easily be commands where supporting them adds lots of
+complexity or room for confusion.
+
+Demo time:
+
+	joey@darkstar:/tmp> git clone ~/lib/sound/
+	Cloning into 'sound'...
+	done.
+	Checking out files: 100% (45727/45727), done.
+	joey@darkstar:/tmp> cd sound/
+	joey@darkstar:/tmp/sound> git annex init --version=6
+	init  (merging origin/git-annex origin/synced/git-annex into git-annex...)
+	(scanning for unlocked files...)
+	ok
+	joey@darkstar:/tmp/sound> git annex adjust --hide-missing
+	adjust 
+	Switched to branch 'adjusted/master(hidemissing)'
+	ok
+	joey@darkstar:/tmp/sound#master(hidemissing)> ls
+	podcasts
+	joey@darkstar:/tmp/sound#master(hidemissing)> ls podcasts
+	feeds
+	joey@darkstar:/tmp/sound#master(hidemissing)> git annex sync origin --no-push -C podcasts
+	...
+	joey@darkstar:/tmp/sound> time git annex adjust --hide-missing
+	adjust
+	ok
+	15.03user 3.11system 0:14.95elapsed 121%CPU (0avgtext+0avgdata 93280maxresident)k
+	0inputs+88outputs (0major+12206minor)pagefaults 0swaps
+	joey@darkstar:/tmp/sound#master(hidemissing)> ls podcasts
+	Astronomy_Cast/                                     Hacking_Culture/
+	Benjamen_Walker_s_Theory_of_Everything/             In_Our_Time/
+	Clarkesworld_Magazine___Science_Fiction___Fantasy/  Lightspeed_MagazineLightspeed_Magazine___Science_Fiction___Fantasy/
+	DatCast/                                            Long_Now__Seminars_About_Long_term_Thinking/
+	Escape_Pod/                                         Love___Radio/
+	Gravy/                                              feeds
+
+Close to being able to use this on my phone. ;-)
diff --git a/doc/devblog/day_549__operating_on_hidden_files/comment_1_29ded4a0926cca6f2485efc07c039b62._comment b/doc/devblog/day_549__operating_on_hidden_files/comment_1_29ded4a0926cca6f2485efc07c039b62._comment
new file mode 100644
index 0000000000..f43538c68b
--- /dev/null
+++ b/doc/devblog/day_549__operating_on_hidden_files/comment_1_29ded4a0926cca6f2485efc07c039b62._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kamil.figiela@79c245579d15acc2bf83467adce982bfaf8fc4cc"
+ nickname="kamil.figiela"
+ avatar="http://cdn.libravatar.org/avatar/f2f427676bad0fa6874bba199c6861e5"
+ subject="comment 1"
+ date="2018-10-27T09:32:21Z"
+ content="""
+This feature sounds awesome! I have quite large repo of music that I keep on NAS, but still want to have some of it on computer. This will really help, as I am always confused what I have on laptop while on the go.
+"""]]
diff --git a/doc/devblog/day_54__android_bisection_minions.mdwn b/doc/devblog/day_54__android_bisection_minions.mdwn
new file mode 100644
index 0000000000..ed86c68d07
--- /dev/null
+++ b/doc/devblog/day_54__android_bisection_minions.mdwn
@@ -0,0 +1,9 @@
+Finally found the [root cause](http://git-annex.branchable.com/bugs/git-annex_broken_on_Android_4.3/#comment-452bee7d0a816300ccb4a34f9758134e)
+of the Android 4.3/4.4 trouble, and a fix is now in place!
+
+As a bonus, it looks like I've fixed a problem accessing the
+environment on Android that had been worked around in an ugly way before.
+
+Big thanks to my remote hands Michael Alan, Sören, and subito. All
+told they ran 19 separate tests to help me narrow down this tricky
+problem, often repeating long command lines on software keyboards.
diff --git a/doc/devblog/day_54__android_bisection_minions/comment_1_bea8fbe2b87d4a4865b92fa796298fa0._comment b/doc/devblog/day_54__android_bisection_minions/comment_1_bea8fbe2b87d4a4865b92fa796298fa0._comment
new file mode 100644
index 0000000000..0f8e588273
--- /dev/null
+++ b/doc/devblog/day_54__android_bisection_minions/comment_1_bea8fbe2b87d4a4865b92fa796298fa0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmW0kg4uiMIhSHeVuvJFyo2VYMl7Qoej0s"
+ nickname="Chris"
+ subject="Woot!"
+ date="2013-11-12T15:52:48Z"
+ content="""
+Thanks for getting this fixed.  I'm about to go on a long plane ride, and this will make it a lot easier for me to put movies on my tablet.
+"""]]
diff --git a/doc/devblog/day_550__a_plan_to_finish_v6.mdwn b/doc/devblog/day_550__a_plan_to_finish_v6.mdwn
new file mode 100644
index 0000000000..60bbf1c0b8
--- /dev/null
+++ b/doc/devblog/day_550__a_plan_to_finish_v6.mdwn
@@ -0,0 +1,12 @@
+Dreadfully early this morning I developed a plan for a way to finish the
+last v6 blocker, that works around most of the problems with git's smudge 
+interface. The only problem with the plan is that it would make both `git
+stash` and `git reset --hard` leave unlocked annexed files in an
+unpopulated state when their content is available. The user would have to
+run git-annex afterwards to fix up after them. All other git checkout,
+merge, etc commands would work though.
+
+Not sure how I feel about this plan, but it seems to be the best one so
+far, other than going off and trying to improve git's smudge interface again.
+I also wrote up [[git_smudge_clean_interface_suboptiomal]] which explains
+the problems with git's interface in detail.
diff --git a/doc/devblog/day_550__a_plan_to_finish_v6/comment_2_4a839c274832e43664d665e90b93146c._comment b/doc/devblog/day_550__a_plan_to_finish_v6/comment_2_4a839c274832e43664d665e90b93146c._comment
new file mode 100644
index 0000000000..3c1ed898c7
--- /dev/null
+++ b/doc/devblog/day_550__a_plan_to_finish_v6/comment_2_4a839c274832e43664d665e90b93146c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="michael.hanke@c60e12358aa3fc6060531bdead1f530ac4d582ec"
+ nickname="michael.hanke"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Awesome!"
+ date="2018-10-26T17:13:48Z"
+ content="""
+I have been using V6 more and more over the past weeks, and it is working pretty well for me so far.
+
+If you are now on the final straight, how will parallelization be triggered (i.e. git annex add --jobs ...) when everything runs (or could run) implicitly through the normal Git API.
+
+Thanks for making this happen!
+"""]]
diff --git a/doc/devblog/day_550__a_plan_to_finish_v6/comment_2_bae3f3303d61126a337f2dac71681e1d._comment b/doc/devblog/day_550__a_plan_to_finish_v6/comment_2_bae3f3303d61126a337f2dac71681e1d._comment
new file mode 100644
index 0000000000..e5af419f67
--- /dev/null
+++ b/doc/devblog/day_550__a_plan_to_finish_v6/comment_2_bae3f3303d61126a337f2dac71681e1d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-10-26T17:41:14Z"
+ content="""
+Well, `git annex add -J` works of course.. `git add` doesn't have a way to
+parallelize, nor does git checkout.
+
+It might be useful to parallelize `git annex smudge --update` which updates
+unlocked files in the work tree. I guess it should already be mostly disk
+bound when it's copying files and parallalizing that would likely only
+worsten things due to seeking (on spinning rust), 
+but it may have some parallizable overhead when it's making annex.thin hardlinks.
+It would need to be controlled via a git config flag or something since
+it gets run internally.
+"""]]
diff --git a/doc/devblog/day_551__v6_or_v7.mdwn b/doc/devblog/day_551__v6_or_v7.mdwn
new file mode 100644
index 0000000000..05a35ebfc1
--- /dev/null
+++ b/doc/devblog/day_551__v6_or_v7.mdwn
@@ -0,0 +1,19 @@
+In the `delaysmudge` branch, I've implemented the delayed worktree update in
+the post-merge/post-checkout hooks for v6. It works very well!
+
+In particular, with annex.thin set, checking out a branch
+containing a huge unlocked file does a fast hard link to the file.
+
+Remaining problem before merging that is, how to get the new hooks installed? Of
+course `git annex init` and `git annex upgrade` install them, but I know plenty
+of people have v6 repositories already, without those hooks.
+
+So, would it be better to bump up to v7 and install the hooks on that upgrade,
+or stay on v6 and say that it was, after all, experimental up until now, and
+so the minor bother of needing to run `git annex init` in existing v6 repositories
+is acceptable? If the version is bumped to v7, that will cause some pain
+for users of older versions of git-annex that won't support it, but those old
+versions also have pretty big gaps in their support for v6. I'm undecided,
+but leaning toward v7, even though it will also mean a lot of work to update
+all the documentation, as well as needing changes to projects like datalad that use
+git-annex. Feedback on this decision is welcomed below...
diff --git a/doc/devblog/day_551__v6_or_v7/comment_1_a46bd8dcc560a681405f82f13fc2e87e._comment b/doc/devblog/day_551__v6_or_v7/comment_1_a46bd8dcc560a681405f82f13fc2e87e._comment
new file mode 100644
index 0000000000..7adf029515
--- /dev/null
+++ b/doc/devblog/day_551__v6_or_v7/comment_1_a46bd8dcc560a681405f82f13fc2e87e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="pigmonkey"
+ avatar="http://cdn.libravatar.org/avatar/560cedfcec1b75e8ac2e98a10615d770"
+ subject="comment 1"
+ date="2018-10-25T21:54:18Z"
+ content="""
+As someone with a mix of v5 and v6 repositories, I think keeping the version number and requiring `git annex init` is reasonable. I wouldn't be upset with either route...
+"""]]
diff --git a/doc/devblog/day_551__v6_or_v7/comment_2_555009f3455129946b0238bc7e3bc52e._comment b/doc/devblog/day_551__v6_or_v7/comment_2_555009f3455129946b0238bc7e3bc52e._comment
new file mode 100644
index 0000000000..47e85a281a
--- /dev/null
+++ b/doc/devblog/day_551__v6_or_v7/comment_2_555009f3455129946b0238bc7e3bc52e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ avatar="http://cdn.libravatar.org/avatar/0be1310904ded29624b9edb4824d451b"
+ subject="v7"
+ date="2018-10-26T09:33:09Z"
+ content="""
+I would prefer making it v7 so that it can be done automatically. I've got a large number of git-annex repositories (between 10-15) checked out on many boxes. I have upgraded some to v6, but I'm not sure I remember which (though I could find out). Having it be automatic would be preferable so that I wouldn't have to manually go check.
+"""]]
diff --git a/doc/devblog/day_551__v6_or_v7/comment_3_0fa5ed098fa850fee538034f4787f35e._comment b/doc/devblog/day_551__v6_or_v7/comment_3_0fa5ed098fa850fee538034f4787f35e._comment
new file mode 100644
index 0000000000..7c91e7320a
--- /dev/null
+++ b/doc/devblog/day_551__v6_or_v7/comment_3_0fa5ed098fa850fee538034f4787f35e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2018-10-26T15:27:50Z"
+ content="""
+If making a new repo version, maybe consider also changing the format of symlinks to locked files, to remove the double repetition of the key?  See discussion at [[todo/shorter_keys_through_better_encoding]] .
+"""]]
diff --git a/doc/devblog/day_552_523__v7_release_prep.mdwn b/doc/devblog/day_552_523__v7_release_prep.mdwn
new file mode 100644
index 0000000000..c9027ce5c4
--- /dev/null
+++ b/doc/devblog/day_552_523__v7_release_prep.mdwn
@@ -0,0 +1,34 @@
+I fixed two reversions yesterday (neither related to v7 repos) during a day
+of triage in preparation for the release of git-annex 7. 
+
+One of the reversions broke adding remotes in the webapp, and was filed all
+the way back in January with lots of confirmations. I feel bad I didn't get
+around to even looking at that bug report until now. 
+
+My backlog is kind of large, it hovers around 400 messages most of the time
+now, there needs to be a better way to make sure I notice such bad bugs. Would
+someone like to help with git-annex bug triage, picking out bugs that
+multiple users have confirmed, or that have good intructions to reproduce
+them, and helping me prioritize them? No coding required, massive
+contribution to git-annex. Please get in touch.
+
+---
+
+Anyway, after that full day's work, I took a look at the autobuilders, and
+it was bad; the test suite was failing everywhere testing v7. For quite a
+while I've been seeing intermittent test suite failures involving the new
+repo version, that mostly only happened on the autobuilders. But now they
+were more reproducible; a recent change made them happen much more
+frequently. That was good; it made it easier to track down the problem.
+
+Which was that git-annex was getting mtime information with 1 second
+granularity. So when the test suite modified a file several times in the
+same second, git-annex could fail to notice some of the modifications. I
+think when I origianlly developed the inode cache module in 2013, for
+direct mode, there was no easy way to access high-precision mtimes from
+haskell, but there is now, and git-annex will use them.
+
+That left one other failure in the test suite, an intermittent crash of
+sqlite with ErrorIO on Linux. May be related to the known sqlite crashes in WSL.
+I've been trying various things today to try to fix it, but have to run the
+test suite in a loop for several hours to reproduce it reliably.
diff --git a/doc/devblog/day_552_523__v7_release_prep/comment_1_31c6692172dbc1217d0a7ab90c074823._comment b/doc/devblog/day_552_523__v7_release_prep/comment_1_31c6692172dbc1217d0a7ab90c074823._comment
new file mode 100644
index 0000000000..814dcb1faf
--- /dev/null
+++ b/doc/devblog/day_552_523__v7_release_prep/comment_1_31c6692172dbc1217d0a7ab90c074823._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="apenwarr on mtimes"
+ date="2018-11-20T19:16:59Z"
+ content="""
+this is pretty much the most thorough overview of mtime and related issues I've ever read:
+
+https://apenwarr.ca/log/20181113
+
+warmly recommend it. he basically gave up on mtime: they're tracked and important, but not in isolation. he also tracks file size, inode numbers, etc.
+"""]]
diff --git a/doc/devblog/day_554__git-annex_user_survey_draft.mdwn b/doc/devblog/day_554__git-annex_user_survey_draft.mdwn
new file mode 100644
index 0000000000..6c6bd4ab54
--- /dev/null
+++ b/doc/devblog/day_554__git-annex_user_survey_draft.mdwn
@@ -0,0 +1,7 @@
+It's been several years since the last git-annex user survey, and I've put
+together a new one. 
+
+<http://git-annex-survey.branchable.com/polls/2018/>
+**This is only a draft**, any votes made at this point
+won't count. I wanted to get more eyes on it before it goes live to get
+whatever feedback and ideas you have on the content of the survey.
diff --git a/doc/devblog/day_555__git_annex_user_survey_live.mdwn b/doc/devblog/day_555__git_annex_user_survey_live.mdwn
new file mode 100644
index 0000000000..415d51168c
--- /dev/null
+++ b/doc/devblog/day_555__git_annex_user_survey_live.mdwn
@@ -0,0 +1,7 @@
+The survey is now live,
+<http://git-annex-survey.branchable.com/polls/2018/>
+
+I had said I was going to clear votes to the draft survey, but for
+technical reasons I decided not to. So if you already voted you don't need
+to vote again, but if you made any joke votes please go change your vote.
+(I removed the proposed port of git-annex to the TOPS-20.)
diff --git a/doc/devblog/day_556__snow_day.mdwn b/doc/devblog/day_556__snow_day.mdwn
new file mode 100644
index 0000000000..e2d199649e
--- /dev/null
+++ b/doc/devblog/day_556__snow_day.mdwn
@@ -0,0 +1,6 @@
+Snowed in and without internet until now, I've been working on the backlog.
+This included adding `git annex find --branch` and adding support
+for combining options like `--include`, `--largerthan` etc with
+`--branch`.
+
+Today's work was sponsored by Jake Vosloo [on Patreon](https://patreon.com/joeyh/).
diff --git a/doc/devblog/day_557__upgrade_bugfixes.mdwn b/doc/devblog/day_557__upgrade_bugfixes.mdwn
new file mode 100644
index 0000000000..04b7fb2b65
--- /dev/null
+++ b/doc/devblog/day_557__upgrade_bugfixes.mdwn
@@ -0,0 +1,10 @@
+Fixed several bugs involving upgrade to v7 when the git repository
+already v7 contained unlocked files. The worst of those involved direct
+mode and caused the whole file content to get checked into git. While
+that's a fairly unusual case, it's an ugly enough bug that I rushed out a
+release to fix it.
+
+Also, LWN has posted a
+[comparison of git-annex and git LFS](https://lwn.net/Articles/774125/).
+
+Today's work was sponsored by Trenton Cronholm [on Patreon](https://patreon.com/joeyh/).
diff --git a/doc/devblog/day_558__new_horizons.mdwn b/doc/devblog/day_558__new_horizons.mdwn
new file mode 100644
index 0000000000..5404a0f4af
--- /dev/null
+++ b/doc/devblog/day_558__new_horizons.mdwn
@@ -0,0 +1,15 @@
+Starting the new year with
+[new git-annex development funding](https://joeyh.name/blog/entry/git-annex_and_funding_update/)
+for most of the things on the [[design/roadmap]]!
+
+Today was spent converting the UUID data type to use a ByteString, rather
+than a String, and also converting repo descriptions to ByteString.
+That's groundwork for reading and writing log files on the git-annex
+branch using attoparsec and ByteString builders, which will hopefully
+improve performance.
+
+Until that's complete, it will often convert a String to a ByteString and
+then back to a String, which could actually make performance slightly
+worse. Benchmarking `git annex whereis` doesn't find much of a change. It
+may have gotten a slightly faster overall, due to the faster Eq and
+Ord instances making the map of repositories faster.
diff --git a/doc/devblog/day_559__surprising_win.mdwn b/doc/devblog/day_559__surprising_win.mdwn
new file mode 100644
index 0000000000..a104a009e6
--- /dev/null
+++ b/doc/devblog/day_559__surprising_win.mdwn
@@ -0,0 +1,9 @@
+Built an attoparsec parser for timestamps, and unsurprisingly it's 15 times
+faster parsing ByteStrings with it than the old String parser. The
+surprising thing to me was that converting a String to a ByteString and
+using the new parser is 10 times as fast as the old parser despite the
+conversion overhead. A nice immediate speedup for many parts of git-annex!
+
+Of course timestamp parsing is not a major cost center in git-annex, but
+benchmarking `git annex whereis` run on 1000 files, there is a real
+speedup already, approximately 4%.
diff --git a/doc/devblog/day_55__fireside_porting.mdwn b/doc/devblog/day_55__fireside_porting.mdwn
new file mode 100644
index 0000000000..c7469d953b
--- /dev/null
+++ b/doc/devblog/day_55__fireside_porting.mdwn
@@ -0,0 +1,22 @@
+Annoyingly, the Android 4.3 fix breaks git-annex on Android 4.0 (probably
+through 4.2), so I now have two separate builds of the Android app.
+
+---
+
+Worked on Windows porting today. I've managed to get the assistant
+and watcher (but not yet webapp) to build on Windows.
+The `git annex transferrer` interface needs POSIX stuff, and seems to be
+the main thing that will need porting for Windows for the assistant to
+work, besides of course file change detection. For that, I've hooked up
+[Win32-notify](http://hackage.haskell.org/package/Win32-notify).
+
+So the watcher might work on Windows. 
+At least in theory. Problem is, while all the code builds ok, 
+it fails to link:
+
+	ghc.exe: could not execute: C:\Program Files (x86)\Haskell Platform\2012.4.0.0\lib/../mingw/bin/gcc.exe
+
+I wonder if this is case of too many parameters being passed?
+
+This happens both on the autobuilder and on my laptop, so I'm stuck here.
+Oh well, I was not planning to work on this anyway until February...
diff --git a/doc/devblog/day_55__fireside_porting/comment_1_d690a52db82f9594d99ae65fe51e1f1a._comment b/doc/devblog/day_55__fireside_porting/comment_1_d690a52db82f9594d99ae65fe51e1f1a._comment
new file mode 100644
index 0000000000..74acc83221
--- /dev/null
+++ b/doc/devblog/day_55__fireside_porting/comment_1_d690a52db82f9594d99ae65fe51e1f1a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://nullroute.eu.org/~grawity/"
+ nickname="Mantas"
+ subject="comment 1"
+ date="2013-11-13T06:22:49Z"
+ content="""
+[ProcExp](http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) may be useful -- it can show process-related syscalls and their return codes _(among other things like file or registry access)_ so it should tell exactly why the exec failed.
+"""]]
diff --git a/doc/devblog/day_560__into_the_weeds.mdwn b/doc/devblog/day_560__into_the_weeds.mdwn
new file mode 100644
index 0000000000..d7f8c3a75e
--- /dev/null
+++ b/doc/devblog/day_560__into_the_weeds.mdwn
@@ -0,0 +1,14 @@
+Converted git-annex branch access to use ByteStrings, with support also for
+writing to it using bytestring-builder, which is supposed to be faster.
+Finished both an attoparsec parser and a builder for the location logs.
+All the other logs just convert to and from String for now, so there is
+still a lot of work to do.
+
+The `git annex whereis` benchmark looks to be around 6% total speedup now,
+so this only improved it by a few percent, but these little speedups are adding up.
+
+Writing to the git-annex branch may also have sped up significantly; the
+builder is probably able to stream out to git without doing any internal
+copies. But there are not many cases where git-annex does a lot of writes to
+the branch without some other operation that is much more expensive, so I don't
+anticipate much speed improvement on that side.
diff --git a/doc/devblog/day_561__better_benchmarking.mdwn b/doc/devblog/day_561__better_benchmarking.mdwn
new file mode 100644
index 0000000000..0bc7811af6
--- /dev/null
+++ b/doc/devblog/day_561__better_benchmarking.mdwn
@@ -0,0 +1,17 @@
+I've been benchmarking whole calls to eg `git annex whereis`, and that's
+not ideal because git-annex has some startup overhead that I'm not
+interested in benchmarking (right now), and often that overhead swamped
+the things I wanted to benchmark, making it difficult to trust my results.
+
+So, I've built a `git annex benchmark` command, that can benchmark any other
+git-annex commands, without starting a new git-annex process. It uses
+criterion to get statistically meaningful benchmark results. And operations
+as fast as 10 ms can be benchmarked now, without needing to write any
+special purpose benchmark code.
+
+New results for this weeks's optimisations:
+
+whereis on 1000 files........... 5% speedup  
+whereis on 1 file............... 14% speedup  
+info on dir with 1000 files..... 4% speedup  
+local get ; drop of 1000 files.. 3% speedup  
diff --git a/doc/devblog/day_562__on_to_metadata.mdwn b/doc/devblog/day_562__on_to_metadata.mdwn
new file mode 100644
index 0000000000..c75d65d27e
--- /dev/null
+++ b/doc/devblog/day_562__on_to_metadata.mdwn
@@ -0,0 +1,14 @@
+Continuing with the ByteString conversion marathon, today worked on
+converting the metadata types. Actually, metadata field names made more
+sense to change to Text, since they're limited to a subset of utf-8.
+
+I lost 2 hours to a puzzling quickcheck failure of metadata serialization.
+It turned out to involve unicode non-breaking spaces. Aaargh.
+Otherwise, fairly straightforward changes, but metadata is used all over
+git-annex, so the final patch was nearly 1000 lines.
+
+Benchmark time:
+
+setting metadata in 1000 files...... 1% speedup  
+getting metadata from 1000 files.... 0.5% speedup  
+finding a single file out of 1000 that has a given metadata value... 5% speedup  
diff --git a/doc/devblog/day_563-564__log_conversion.mdwn b/doc/devblog/day_563-564__log_conversion.mdwn
new file mode 100644
index 0000000000..e415eecdfb
--- /dev/null
+++ b/doc/devblog/day_563-564__log_conversion.mdwn
@@ -0,0 +1,15 @@
+Spent two days converting all code that deal with git-annex branch log
+files to use attoparsec and bytestring builders.
+
+For most of them, I'm not expecting much if any speed improvements, since
+often git-annex only ever parses a given log file once, and writes to many
+log files are only done rarely. The main candidates for speedup are chunk
+logs and remote state logs. Also Group was converted to a ByteString,
+which may speed up queries that involve groups. I have not benchmarked.
+It was still worth doing the conversion, for consistency and better code
+if not speed.
+
+I found a few bugs in the old parsers for log files along the way.
+The uuid.log parser was not preserving whitespace in repositiory
+descriptions; the new one will. And the activity.log parser filtered out
+unknown values, not leaving room for expansion.
diff --git a/doc/devblog/day_565__bytestring_Key.mdwn b/doc/devblog/day_565__bytestring_Key.mdwn
new file mode 100644
index 0000000000..5cbae4a44f
--- /dev/null
+++ b/doc/devblog/day_565__bytestring_Key.mdwn
@@ -0,0 +1,15 @@
+Today worked on converting the Key data type to use ByteString.
+
+Microbenchmarks of Keys improved, especially parsing them got 700% faster.
+But key parsing is not enough of an overhead in any commands I benchmarked
+to be a real improvement.
+
+The new key parser is much stricter than the old one, which helps the
+speed. Hopefully the oddly formatted edge cases that the old parser allowed
+are not really in use; they include keys with fields out of the usual order,
+and keys with multiple values for the same field.
+
+The next step would probably be to convert the git interface to use
+ByteStrings, and that plus the current groundwork is likely to lead to some
+real performance improvements. But I'm going to stop here with the
+ByteString conversion for now.
diff --git a/doc/devblog/day_566__stopping_place.mdwn b/doc/devblog/day_566__stopping_place.mdwn
new file mode 100644
index 0000000000..484fbfb85c
--- /dev/null
+++ b/doc/devblog/day_566__stopping_place.mdwn
@@ -0,0 +1,26 @@
+I said I was going to stop with the ByteString conversion, but then I
+looked at [[/profiling]], and I knew I couldn't stop there --
+conversion between String and ByteString had became a major cost center.
+
+So today, converted all the code that reads and parses symlinks and pointer files
+to ByteString, now ByteString is used all the way from disk to Key. Also
+put in some caching, so git-annex does not need to re-serialize a Key
+that it's just deserialized from a ByteString.
+
+There's still some ByteString to String conversion when generating
+FilePaths; to avoid that will need an equivilant of System.FilePath that
+operates on RawFilePath, and I don't think there is one yet? But the
+[[/profiling]] does show improvement, it's more and more dominated by IO
+operations that can't be sped up, and less by slow code.
+
+This really does feel like a stopping place now.
+
+Updated benchmarks (compared to last git-annex release):
+
+find on 10000 files, none present... 8% speedup  
+whereis on 1000 files............... 12% speedup  
+info on dir with 1000 files......... 7% speedup  
+local get ; drop of 1000 files...... 4% speedup  
+setting metadata in 1000 files...... 8% speedup  
+getting metadata from 1000 files.... 7% speedup  
+finding a single file out of 1000 that has a given metadata value... 8% speedup  
diff --git a/doc/devblog/day_567__neither_rain_nor_snow.mdwn b/doc/devblog/day_567__neither_rain_nor_snow.mdwn
new file mode 100644
index 0000000000..a79abb21d9
--- /dev/null
+++ b/doc/devblog/day_567__neither_rain_nor_snow.mdwn
@@ -0,0 +1,16 @@
+Offline today due to weather, but there's lots of nice backlog to work
+on...
+
+I've written down a [[todo/external_remote_querying_transition]] plan.
+If you maintain an external special remote that implements WHEREIS or
+GETINFO, please take a look as your code would need to be updated if this
+is done.
+
+Ilya suggested making `git annex testremote` be able to test readonly
+remotes, and I implemented that.
+
+There was a discussion in the forum about .git/annex/misctmp/
+containing cruft left by an interrupted git-annex process.
+I was surprised to find half a gigabyte of old files on my own laptop due
+to this problem. I've put in a fix, so git-annex will clean up such temp
+files that were left behind by a previous interrupted git-annex process.
diff --git a/doc/devblog/day_568__release_day.mdwn b/doc/devblog/day_568__release_day.mdwn
new file mode 100644
index 0000000000..6f65fba77e
--- /dev/null
+++ b/doc/devblog/day_568__release_day.mdwn
@@ -0,0 +1,11 @@
+After a long struggle with the test suite, the new
+git-annex release is finally out today.
+
+A few last-minute changes in the release include removing
+box.com from the webapp since their webdav gateway is EOL at the end of the
+month, supporting armv71 in the android installation script, allowing
+installation with 64 bit git on windows, and shortening the estimated time
+to completion display.
+
+Today's work was supported by Trenton Cronholm
+[on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_569__another_week_another_release.mdwn b/doc/devblog/day_569__another_week_another_release.mdwn
new file mode 100644
index 0000000000..232671a346
--- /dev/null
+++ b/doc/devblog/day_569__another_week_another_release.mdwn
@@ -0,0 +1,11 @@
+Today's release is to fix a
+[data loss bug](http://git-annex.branchable.com/bugs/potential_data_loss_after_late_enabling_of_S3_versioning/),
+that affects S3 remotes configured with exporttree=yes that got versioning=yes
+turned on after some unversioned data is stored in them. If you use the new
+versioning=yes feature with S3, please upgrade.
+
+Also, there are only two days left to fill out the
+[git-annex user survey](http://git-annex-survey.branchable.com/polls/2018/)
+if you have not already.
+
+Today's work was sponsored by Jake Vosloo [on Patreon](https://patreon.com/joeyh/).
diff --git a/doc/devblog/day_56__git-annex_user_survey.mdwn b/doc/devblog/day_56__git-annex_user_survey.mdwn
new file mode 100644
index 0000000000..8c1c67994e
--- /dev/null
+++ b/doc/devblog/day_56__git-annex_user_survey.mdwn
@@ -0,0 +1,20 @@
+One of my goals for this month is to get a better sense of how git-annex is
+being used, how it's working out for people, and what areas need to be
+concentrated on. To start on that, I am doing the 
+[2013 git-annex user survey](http://git-annex-survey.branchable.com/polls/2013/), similar to the git user
+surveys. I will be adding some less general polls later (suggestions for
+topics appreciated!), but you can go vote in any or all of 10 polls now.
+
+----
+
+Found a workaround for yesterday's Windows build problem. Seems that only
+cabal runs gcc in a way that fails, so `ghc --make` builds is successfully.
+However, the watcher doesn't quite work on Windows. It does get events when
+files are created, but it seems to then hang before it can add the file to
+git, or indeed finish printing out a debug log message about the event.
+This looks like it could be a problem with the threaded ghc runtime on
+Windows, or something like that.
+
+Main work today was improving the git repository repair to handle corrupt
+index files. The assistant can now start up, detect that the index file is
+corrupt, and regenerate it all automatically.
diff --git a/doc/devblog/day_570__brrr.mdwn b/doc/devblog/day_570__brrr.mdwn
new file mode 100644
index 0000000000..451012e3aa
--- /dev/null
+++ b/doc/devblog/day_570__brrr.mdwn
@@ -0,0 +1,20 @@
+Started off the day with some more improvements and bug fixes for export
+remotes.
+
+Then I noticed that there is no progress displayed for transfers to export
+remotes; it seems I forgot to wire that up. That really ought to be handled
+by the special remote setup code, the same way it is for non-export
+remotes. But it was not possible to do it there the way that export actions
+are structured.
+
+I got sidetracked with how S3 prepares a handle to the server. That didn't
+work as well as it might have; most of the time each request to the remote
+actually prepared a new handle, rather than reusing a single handle. Though
+the http connection to the server did get reused, that still caused a lot
+of unnecessary work. I fixed that, and the fix also allowed me to
+restructure export actions in the way I need for progress bars.
+
+I've ran out of time to finish adding the missing progress bars today, so
+I'll do it tomorrow.
+
+Today's work was sponsored by Jake Vosloo [on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_571__survey_results.mdwn b/doc/devblog/day_571__survey_results.mdwn
new file mode 100644
index 0000000000..3587f9ce7f
--- /dev/null
+++ b/doc/devblog/day_571__survey_results.mdwn
@@ -0,0 +1,173 @@
+The [2018 user's survey](http://git-annex-survey.branchable.com/polls/2018/) 
+is closed, time for a look at the results. Several of the questions were
+also on the two past surveys, so we can start to look at historical
+trends as well.
+
+<img src="https://git-annex-survey.branchable.com/polls/2018/graphs/num_respondants.png">
+
+Very similar numbers of people responded in 2018 as in 2015.
+The 2013 survey remains a high water mark in participation.
+[[My thoughts on the 2015 survey|day_360__results_of_2015_user_survey]]
+participation level mostly still stand, although there has been a
+consistent downwards trend in [Debian popcon](https://qa.debian.org/popcon-graph.php?packages=git-annex&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1)
+since 2015.
+
+Also interesting that several people skipped the first question on the
+survey, perhaps because it was a fairly challenging question? And later
+questions saw much higher response rates this time than in either of the
+previous surveys, thanks to improvements in the survey interface.
+
+## v7
+
+v7 unlocked files are being used by 7% of users, pretty impressive uptake
+for a feature that has only been really finished for a couple of months.
+Direct mode is still used by 7% of users, while its v7 replacement of
+adjusted unlocked branches is only used by 1% so far. That's still some
+decent progress toward eliminating the need for direct mode.
+
+## command line vs assistant
+
+<img src="https://git-annex-survey.branchable.com/polls/2018/graphs/command_line_vs_assistant.png">
+
+Well that's plain enough isn't it? Although note that I myself have
+the assistant running in some repos all the time, but would of course
+vote "command line" since I interact with that much more.
+
+Also notice that people who apparently don't use git-annex
+but wanted to fill out the survey anyway was the same for 2013-2015,
+but has now declined.
+
+## operating system
+
+<img src="https://git-annex-survey.branchable.com/polls/2018/graphs/operating_system.png">
+
+Android users have more or less gone away since I deprecated the app.
+I hope the termux integration brings some back.
+
+## how git-annex is installed
+
+<img src="https://git-annex-survey.branchable.com/polls/2018/graphs/how_installed.png">
+
+Good to see the increase in using git-annex packages from the OS
+or a third-party package manager.
+
+## missing/incomplete ports
+
+<img src="https://git-annex-survey.branchable.com/polls/2018/graphs/missing_ports.png">
+
+Good improvement here since 2015 with 60% now satisfied with available
+ports.
+
+Worth noting that in 2013, 6% wanted a way to use git-annex on
+Synology NAS. That is possible now via the standalone linux tarball.
+This year, 2% wanted "Synology NAS (app store package)".
+
+Also honorable mention to the anonymous person who rewrote
+git-annex in another language. You should release the code!
+
+## number of repositories
+
+<img src="https://git-annex-survey.branchable.com/polls/2018/graphs/number_of_repositories.png">
+
+Increasingly users seem to have just a couple repositories or a large
+number, with the middle ground shrinking. A few percent have 200+ 
+repositories now. The sense is of a split between causual users who
+perhaps clone one repository to a few places, and power users who
+are adding new repositories over time.
+
+## data stored in git-annex
+
+<img src="https://git-annex-survey.branchable.com/polls/2018/graphs/size_of_annex.png">
+
+Increasing growth in the high end with many users storing dozens of terabytes
+of data in git-annex and a couple storing more than 64 terabytes. 
+And a bit of growth in the low end storing under 100 gb.
+
+The total data stored in git-annex looks to be around 650-1300 terabytes
+now. It was around 150-300 terabytes in 2013. That doesn't count redundant
+data. And it could be off slightly if shared repositories were reported by
+multiple users.
+
+(Compare with the Internet Archive, which was 15000 terabytes in 2016
+but I think they keep two copies of everything, so call it 7000
+terabytes of unique data.)
+
+## git level
+
+<img src="https://git-annex-survey.branchable.com/polls/2018/graphs/git_level.png">
+
+The same question was asked in the [git surveys](https://git.wiki.kernel.org/index.php/GitSurvey2016)
+so I have included those in the graph for comparison.
+
+git-annex users trend more experienced than git users,
+which is not surprising. You have to know some stuff about 
+git to understand why you'd want to use git-annex.
+
+Notice that git knowledge level is generally going up over time in both
+surveys.
+
+## happyness with the software
+
+<img src="https://git-annex-survey.branchable.com/polls/2018/graphs/happyness.png">
+
+A similar question on the git survey included for comparison.
+
+There's a bimodal distribution to git-annex user's happyness,
+with more unhappy with it than with git, but also more so happy
+they gravitate toward extreme praise.
+
+There seem to be more unhappy users in 2018 than in 2015 though.
+The 2018 results are very close to the 2013 results.
+
+## blocking problems
+
+Notably 15% of users now find git-annex too hard to use, up from 5% in
+2015. Which seems to correlate with some users being more unhappy with it.
+I don't think git-annex has gotten any harder to use, so this must
+reflect a change in expectations and/or demographics. (2013 had similar
+numbers to 2018.)
+
+Very few complain about the documentation now, down to 3% from 13% in 2015,
+but 12% want to see more tutorials showing how to tie the features
+together.
+
+And a staggering 21% picked a write-in, "no issues personally, but people
+don't see (or realize they need) the immense benefits it provides".
+Need to find better ways to market git-annex, essentially.
+
+## size of group using git-annex together
+
+A similar distribution to 2015. One person said they're using git-annex in
+a group of 50+, and 5 reported groups larger than 10 people.
+
+## scientific data
+
+A new high of 11% of respondants are using git-annex to store scientific data.
+(Other kinds of data it's used for seem more or less the same.)
+
+Part of that growth is because of the companion 
+[2018 git-annex scientific data survey](http://git-annex-survey.branchable.com/polls/2018_science/)
+which was promoted in some scientific communities, and
+so brought more scientists to the main survey.
+
+<img src="https://git-annex-survey.branchable.com/polls/2018/graphs/field_of_science.png">
+
+The use for neuroscience is no surprise, but so much use for astronomy and
+physics is. And "other" in that pie chart includes statistics,
+social sciences, mathematics, education, linguistics, biomedical
+engineering, EE, and physiology -- wow!
+
+## survey reach
+
+All participants in the science survey did go on to answer at least part of
+the main survey. So 37% of respondants to the main survey are scientists.
+
+A full 27% of survey respondants have their name on the thanks
+page, many for financial support. Which is really great, but also speaks to
+the fraction of the git-annex user base who saw the survey,
+because I really doubt that a quarter of the users of *any* free software
+are financially supporting it. 
+
+As with any online survey, the results are skewed by who bothers to answer it.
+Still, a lot of useful information to mull over.
+
diff --git a/doc/devblog/day_572__thinking_please_wait.mdwn b/doc/devblog/day_572__thinking_please_wait.mdwn
new file mode 100644
index 0000000000..667e3bc219
--- /dev/null
+++ b/doc/devblog/day_572__thinking_please_wait.mdwn
@@ -0,0 +1,17 @@
+Not a lot of coding the past few days, but a lot of skull sweat!
+
+I've been working through the design for the [[todo/import_tree]] feature,
+and I think I finally have a design that I'm happy with. There were some
+very challenging race conditions, and so import tree may only be safely
+able to be implemented for a few remotes; S3 (with versioning enabled),
+directory, maybe webdav and I hope adb. Work on this included finding
+equivilant race conditions in git's update of the worktree, which do
+turn out to exist if you go looking, but have much narrower time
+windows there.
+
+And I'll be running a tutorial for people who want to
+learn about git-annex internals at the code level, to start development or
+be better able to design their own features. That's in Montreal, March
+26th-27th (8 hours total), hosted at McGill university. There may be one or
+two seats left, so if you are interested in attending, please get in touch
+with me by email. Haskell is not a prerequisite.
diff --git a/doc/devblog/day_573__starting_import_tree_implementation.mdwn b/doc/devblog/day_573__starting_import_tree_implementation.mdwn
new file mode 100644
index 0000000000..88b95220be
--- /dev/null
+++ b/doc/devblog/day_573__starting_import_tree_implementation.mdwn
@@ -0,0 +1,12 @@
+Started building [[todo/import_tree]] (in the `importtree` branch). So far
+the content identifier storage in the git-annex branch is done. Since the
+API tells me it will need to both map from a key to content identifiers,
+and from content identifier to the key, I also added a sqlite database to
+handle the latter.
+
+While implementing that, I happened to notice a bug in storage of metadata
+that contains newlines; [[internals]] said that would be base64'd, but it
+was not. That bug turns out to have been introduced by the ByteString
+conversion in January, and it's the second bug caused by that conversion.
+The other one broke git-annex on Windows, which was fixed by a release
+yesterday.
diff --git a/doc/devblog/day_574__weeds.mdwn b/doc/devblog/day_574__weeds.mdwn
new file mode 100644
index 0000000000..fe7e0f589f
--- /dev/null
+++ b/doc/devblog/day_574__weeds.mdwn
@@ -0,0 +1,19 @@
+Not a lot of progress on [[todo/import_tree]] today I feel..
+
+Started off by adding a QuickCheck test of the content
+identifier log, which did find one bug in that code.
+
+Then started roughing out the core of the importing operation, which involves
+building up git trees for the files that are imported. But that needs a
+way to graft an imported tree into a subdirectory of another tree, 
+and the only way I had available to do it needed to read in the entire
+recursive tree of the current branch, which would be slower and use
+more memory than I like.
+
+So, got sidetracked building a git tree grafter. It turns out that 
+the export tree code also needs to graft a tree (into the git-annex
+branch), and did so using the same innefficient method that I want to
+avoid, so it will also be able to be improved using the grafter.
+
+Unfortunately, I had to stop for the day with the grafter not quite working
+properly.
diff --git a/doc/devblog/day_575__core_of_import_tree_done.mdwn b/doc/devblog/day_575__core_of_import_tree_done.mdwn
new file mode 100644
index 0000000000..6690ef63c0
--- /dev/null
+++ b/doc/devblog/day_575__core_of_import_tree_done.mdwn
@@ -0,0 +1,9 @@
+Yesterday, got the git tree generation done and working. The main import
+tree code is also implemented, though it may need some fine tuning.
+
+Today I've been working on firming up user interface design and documentation.
+Turns out that import tree is going to lead to some changes to export tree.
+A remote tracking branch will be updated by both export tree and import
+tree, since those operations are similar to git push and git fetch.
+And `git annex export --tracking` will be deprecated in favor
+of a git config setting that configures both import and export.
diff --git a/doc/devblog/day_576__import_export.mdwn b/doc/devblog/day_576__import_export.mdwn
new file mode 100644
index 0000000000..ee1f4d9e3c
--- /dev/null
+++ b/doc/devblog/day_576__import_export.mdwn
@@ -0,0 +1,39 @@
+Past two days have been spent making [[todo/import_tree]] interoperate
+safely with `git annex export`. This was more complicated and needed more
+methods to be added to the remote API than I had expected.
+
+At this point, the directory special remote's implementation is no longer
+an unsafe prototype, but detects conflicting file modifications and
+avoids overwriting them when exporting to the directory.
+
+Here it is in action:
+
+	joey@darkstar:/tmp/testrepo> git annex unlock foo
+	joey@darkstar:/tmp/testrepo> echo version from git > foo
+	joey@darkstar:/tmp/testrepo> echo version from special remote > ../dir/foo
+	joey@darkstar:/tmp/testrepo> git annex add foo
+	joey@darkstar:/tmp/testrepo> git commit -m add
+	joey@darkstar:/tmp/testrepo> git annex export master --to dir
+	unexport dir foo failed
+	export dir foo failed
+	(recording state in git...)
+	git-annex: export: 2 failed
+	joey@darkstar:/tmp/testrepo> git annex import master --from dir
+	import dir ok
+	update refs/remotes/dir/master ok
+	(recording state in git...)
+	joey@darkstar:/tmp/testrepo> git merge dir/master
+	Auto-merging foo
+	CONFLICT (content): Merge conflict in foo
+	Automatic merge failed; fix conflicts and then commit the result.
+	joey@darkstar:/tmp/testrepo> echo merged version > foo
+	joey@darkstar:/tmp/testrepo> git annex add foo
+	joey@darkstar:/tmp/testrepo> git commit -m resolved
+	joey@darkstar:/tmp/testrepo> git annex export master --to dir
+	unexport dir foo ok
+	export dir foo ok
+	(recording state in git...)
+
+The feature is close to being mergeable to master now, but still needs some
+work on the progress display of `git annex import`, and on supporting
+imports from the same special remote to different git repos.
diff --git a/doc/devblog/day_576__import_tree_details.mdwn b/doc/devblog/day_576__import_tree_details.mdwn
new file mode 100644
index 0000000000..0e0b83f01e
--- /dev/null
+++ b/doc/devblog/day_576__import_tree_details.mdwn
@@ -0,0 +1,11 @@
+Still working on [[todo/import_tree]] today. I decided to
+make the imported commit be on an unrelated history from the main branch,
+which avoids some very susprising merge behavior, but means
+users will need to pass --allow-unrelated-histories to git merge.
+
+Also got `export` and `sync` commands updating the remote tracking branch.
+It was surprisingly complicated to do.
+
+With that done, I've tested exporting to a directory remote,
+then making changes to the directory manually, and importing, and it all
+works together.
diff --git a/doc/devblog/day_576__import_tree_working.mdwn b/doc/devblog/day_576__import_tree_working.mdwn
new file mode 100644
index 0000000000..7f622e6835
--- /dev/null
+++ b/doc/devblog/day_576__import_tree_working.mdwn
@@ -0,0 +1,23 @@
+Yesterday I implemented the command-line interface for
+`git annex import branch --from remote` and today I got a prototype of it
+it working with the directory special remote. Still a whole lot to do
+before this feature is ready for release, but it's good to have the command
+line interface working to play with it. The workflow feels pretty good:
+
+	joey@darkstar:~/tmp/t> echo hello > ../dir/new_file
+	joey@darkstar:~/tmp/t> git annex import master --from dir
+	import dir ok
+	update refs/remotes/dir/master ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/t> git merge dir/master
+	Updating d3277e2..410aa8e
+	Fast-forward
+	 new_file | 1 +
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 new_file
+	joey@darkstar:~/tmp/t> cat new_file
+	hello
+
+My laptop's keyboard is dying; the S and X keys often don't register. Is 
+making programming feel very clumsy, and there are far too many S's in
+the code I've been working on. ;-)
diff --git a/doc/devblog/day_576__import_tree_working/comment_1_2ffd447e05466b806d36b761b4143e56._comment b/doc/devblog/day_576__import_tree_working/comment_1_2ffd447e05466b806d36b761b4143e56._comment
new file mode 100644
index 0000000000..abded0caf0
--- /dev/null
+++ b/doc/devblog/day_576__import_tree_working/comment_1_2ffd447e05466b806d36b761b4143e56._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="thanks for working on this"
+ date="2019-02-28T18:06:26Z"
+ content="""
+import tree directly addresses one use case I have, where a task run in the cloud reads some inputs from a bucket and writes new outputs to that bucket. import tree can then be used to register the new outputs with git-annex.
+"""]]
diff --git a/doc/devblog/day_577__how_am_I_still_working_on_import_tree.mdwn b/doc/devblog/day_577__how_am_I_still_working_on_import_tree.mdwn
new file mode 100644
index 0000000000..b296226519
--- /dev/null
+++ b/doc/devblog/day_577__how_am_I_still_working_on_import_tree.mdwn
@@ -0,0 +1,7 @@
+Two more days into [[todo/import_tree]] and I'm running out of steam.
+
+However.. Imports from the same special remote into several clones of a
+repository are now fully working!
+
+The hard part should be behind me now. Hoping to merge it on Monday after
+improving the command's output a bit.
diff --git a/doc/devblog/day_578__import_tree_merged.mdwn b/doc/devblog/day_578__import_tree_merged.mdwn
new file mode 100644
index 0000000000..e9052d563c
--- /dev/null
+++ b/doc/devblog/day_578__import_tree_merged.mdwn
@@ -0,0 +1,28 @@
+Whew, I got the finishing touches on the import tree feature, and it's
+merged into master! Still work to do on that, particularly supporting more
+interesting special remotes than directory. It may be two or three weeks
+until I get back to working on it.
+
+Even with only directory special remotes, some nice things can be done with
+this. Like bi-directional syncing between a removable drive with no
+git-annex repository on it, and a subdirectory of the git-annex repository:
+
+	$ git config remote.drive.annex-tracking-branch master:subdir
+	$ date > /mnt/new-from-drive
+	$ date > subdir/new-from-repo
+	$ git annex add
+	add subdir/new-from-repo ok
+	$ git annex sync --content
+	commit
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 subdir/new-from-repo
+	ok
+	list drive ok
+	import drive new-from-drive ok
+	update refs/remotes/drive/master ok
+	
+	Merge made by the 'recursive' strategy.
+	 subdir/new-from-drive | 1 +
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 subdir/new-from-drive
+	export drive new-from-repo ok
diff --git a/doc/devblog/day_579__bug_triage.mdwn b/doc/devblog/day_579__bug_triage.mdwn
new file mode 100644
index 0000000000..7fe9dec022
--- /dev/null
+++ b/doc/devblog/day_579__bug_triage.mdwn
@@ -0,0 +1,3 @@
+Had not looked at bug reports in over a month, so did some triage. No
+particularly bad new bugs have shown up, but there were lots of interesting
+lesser bugs, and I fixed 6 of them today.
diff --git a/doc/devblog/day_57__mavericks.mdwn b/doc/devblog/day_57__mavericks.mdwn
new file mode 100644
index 0000000000..1031895bed
--- /dev/null
+++ b/doc/devblog/day_57__mavericks.mdwn
@@ -0,0 +1,14 @@
+The user survey is producing some interesting and useful results!  
+Added two more polls: [using with](http://git-annex-survey.branchable.com/polls/2013/using_with/) and [blocking problems](http://git-annex-survey.branchable.com/polls/2013/blocking_problems/)  
+(There were some load issues so if you were unable to vote yesterday, try
+again..)
+
+Worked on getting the autobuilder for OS X Mavericks set up. Eventually
+succeeded, after patching a few packages to work around a cpp that thinks
+it should parse haskell files as if they're C code.
+Also, Jimmy has resuscitated the OS X Lion autobuilder.
+
+A not too bad bug in automatic merge conflict resolution has been reported,
+so I will need to dig into that tomorrow. Didn't feel up to it today, so
+instead have been spending the remaining time finishing up a branch that
+switches the test suite to use the tasty test framework.
diff --git a/doc/devblog/day_580__import_from_android.mdwn b/doc/devblog/day_580__import_from_android.mdwn
new file mode 100644
index 0000000000..c69649d0c6
--- /dev/null
+++ b/doc/devblog/day_580__import_from_android.mdwn
@@ -0,0 +1,11 @@
+It was not very hard to get `git annex import` working with adb special
+remotes. This is a nice alternative to installing git-annex on an Android
+device for syncing with it. See [[tips/android_sync_with_adb]].
+
+I'm still thinking about supporting import from special remotes that can't
+avoid most race conditions. But for adb, the only race conditions that
+I couldn't avoid are reasonably narrow, nearly as narrow as `git
+checkout`'s own race conditions, with only the added overhead of
+adb. So I let them slide.
+
+Today's work was sponsored by Trenton Cronholm on Patreon.
diff --git a/doc/devblog/day_581__starting_import_from_S3.mdwn b/doc/devblog/day_581__starting_import_from_S3.mdwn
new file mode 100644
index 0000000000..a9682bd0d7
--- /dev/null
+++ b/doc/devblog/day_581__starting_import_from_S3.mdwn
@@ -0,0 +1,27 @@
+Started today on `git annex import` from S3, in the "import-from-s3"
+branch.
+
+It looks like I'm going to support both versioned and unversioned buckets;
+the latter will need --force to initialize since it can lose data. 
+
+One thought I had about that is: It's probably better for git-annex to be
+able to import data from an unversioned S3 bucket with caveats about
+avoiding unsafe operations (export) that could lose data, than it is for
+git-annex to not be able to import from the bucket at all, guaranteeing
+that past versions of modified files will be lost. (Rationalization is a
+powerful drug.)
+
+To support unversioned buckets, some kind of stable content identifier is
+needed other than the S3 version id. Luckily, S3 has etags, which are
+md5sum of the content, so will work great. But, the `aws` haskell library
+needs one small change to return an etag, so this will be
+blocked on that change.
+
+I've gotten listing importable contents from S3 working for unversioned
+buckets, including dealing with S3's 1000 item limit by paging.
+Listing importable contents from versioned buckets is harder, because
+it needs to synthesize a git version history from the information that S3
+provides. I think I have a method for doing this that will generate the
+trees that users will expect to see, and also will generate the same past
+trees every time, avoiding a proliferation of git trees. Next step: 
+Converting my prose description of how to do that into haskell.
diff --git a/doc/devblog/day_582__versioned_S3_import_working.mdwn b/doc/devblog/day_582__versioned_S3_import_working.mdwn
new file mode 100644
index 0000000000..4367649c5c
--- /dev/null
+++ b/doc/devblog/day_582__versioned_S3_import_working.mdwn
@@ -0,0 +1,9 @@
+Despite struggling with a keyboard controller that's increasingly prone to
+flaking out and not registering some key presses while doubling others, I
+managed to finis implementing import from versioned S3 buckets. It's quite
+nice to see it download past versions of files and construct a git history.
+
+Still enough unimplemented stuff and bugs to need to work on this for
+probably one more day.
+
+(Imagine here me stuggling for a full minute to :wq)
diff --git a/doc/devblog/day_583__S3_import_and_export_fully_working.mdwn b/doc/devblog/day_583__S3_import_and_export_fully_working.mdwn
new file mode 100644
index 0000000000..7754de9a94
--- /dev/null
+++ b/doc/devblog/day_583__S3_import_and_export_fully_working.mdwn
@@ -0,0 +1,17 @@
+Got S3 import and export working fully for both versioned and unversioned
+buckets. This included developing a patch to the aws library; only
+versioned buckets are fully supported until that gets merged.
+
+I'm left with one blocking problem before merging `import-from-s3`: The commit
+history when importing from a versioned bucket is too long. It needs to
+find the point in the versioned import that has already been committed and
+avoid committing it again. Have started on that, but didn't get all the way
+today.
+
+Also, this S3 import feature should be able to be used with anonymous S3
+access to a bucket, and indeed that might be more common than wanting to
+import from a bucket you own or have credentials to allow access to. 
+But the S3 remote does not currently try to use anonymous S3 access,
+so supporting that will need some more changes.
+
+(Keyboard is fixed, yay!)
diff --git a/doc/devblog/day_584__matching_S3_histories.mdwn b/doc/devblog/day_584__matching_S3_histories.mdwn
new file mode 100644
index 0000000000..d2bb151e22
--- /dev/null
+++ b/doc/devblog/day_584__matching_S3_histories.mdwn
@@ -0,0 +1,16 @@
+I've been working on matching up the git history with the history from a 
+versioned S3 export. Got sidetracked for quite a while building an
+efficient way to get the git history up to a certian depth (including all
+sides of merge commits) without reading the entire `git log` output.
+
+The history matching is mostly working now, but there's a problem when a
+rename is exported to S3, because it's non-atomic on S3 and atomic in git,
+and so the histories stop matching up. This is not fatal, just results
+in an ugly git history with the right tree at the top of it. It's
+not entirely wrong; the git repo and the S3 bucket did legitimately diverge
+for a while, so shouldn't the merged history reflect that? The problem is
+just that the divergence is not represented in the opimal way.
+
+I hate giving up at the final hurdle, but I feel I need to think about this
+some more, so merging `import-from-s3` is postponed for another day, or
+likely until Monday.
diff --git a/doc/devblog/day_585__not_matching_S3_histories.mdwn b/doc/devblog/day_585__not_matching_S3_histories.mdwn
new file mode 100644
index 0000000000..b025257f71
--- /dev/null
+++ b/doc/devblog/day_585__not_matching_S3_histories.mdwn
@@ -0,0 +1,16 @@
+I could not find a good solution to the S3 history matching problem, so I
+think that was the wrong approach. Now I have what seems to be a better
+approach implemented: When an import of history from S3 contains some trees
+that differ from the trees that were exported to S3, all git-annex needs to
+do is make git aware of that, and it can do so by making the remote
+tracking branch contain a merge between what was exported to S3 and what
+was imported from it.
+
+That does mean that there can be some extra commits generated form an
+import, with the same trees as commits that the user made, but a different
+message. That seems acceptable. Less so is that repeated imports generate
+different commits each time; I need to make it generate stable commits. I
+should also add back detection of the simple fast-forward case which was
+working but got broken today.
+
+So still not done with this, but the end is in sight!
diff --git a/doc/devblog/day_586__wrapping_up_S3_import.mdwn b/doc/devblog/day_586__wrapping_up_S3_import.mdwn
new file mode 100644
index 0000000000..2e81734e57
--- /dev/null
+++ b/doc/devblog/day_586__wrapping_up_S3_import.mdwn
@@ -0,0 +1,18 @@
+Finally got the remote tracking branch for import from S3 into a good shape.
+
+Rather than coaxing git into generating the same commits each time for
+imports (which would have needed commit dates to be stable somehow), 
+I made git-annex always preserve a reference to the last import commit.
+
+[[s3rename.png]]
+
+Here's how it looks when a rename was exported to S3, which resulted in a
+history in S3 that diverged and reconverged with the git history.
+
+[[s3history.png]]
+
+And here's how the history develops as more changes get exported and
+imported.
+
+With adb and S3 import done, the first phase of [[todo/import_tree]] is
+complete.
diff --git a/doc/devblog/day_586__wrapping_up_S3_import/s3history.png b/doc/devblog/day_586__wrapping_up_S3_import/s3history.png
new file mode 100644
index 0000000000000000000000000000000000000000..4c9fac80bb1b49b92c8ad559de654832e5c0f954
GIT binary patch
literal 16015
zcmbt*byOV9*Jcmy?oRLo3+@aF65QS0-F*lI3l<3O5Zv88KyV07aDux#EWGdU+x>RW
zp8aRfnVIgXuDZAGt?H_}Pdyc;ASZ!}M1%wY0IK9CQ6&HXrM}!(BS5|U5;I?JzFZI;
zK504w0I9+27Zjh`;qsCQ?;<HH2EPFd!lD6{qP1SVBoVrZX}El}x3x93a{)d&nHsv7
znozh~x>!(1NXjax2cY2t00kf^Dx%`CaF}kcqauOdm)R1Drj&<3pM@i$h?6^4mD{KH
zc}b%()u1AbrjMwqmq^;k`!KvpTrBr9=|MQXu2+cdbvt=|<q)2RXawIgIe9|5)7J2!
zAV0hNQO(p>e3rfG5_qTp@XdqaH)aY91nL}21ek7rv{8w&^c?!%z4|C9Juz|=KGT?}
z0Jir{oIe&Q-^wgkhAe2T(>k9Q9+i)Hotl-#AUR+I%0YVLz8&;iJ;!S2rr7Lsds>Ic
z0C1~IoQ_~cS`GXoB^$dVw4-yfpqkmcx2DXoT61r(E3=+Q^?4B`v7M4!Z#vMKd!`~{
z&R5J>^lOU`pU?JMzkQ540>5;=J$@>la(;JZlu~{{Cyl{i|Mdf`0?LhFr2bS`K>|Yc
zx~}*^=~lJY94j-UFqQF9k#n)+p8|VnkGq@gA@1T4qstRXB88{nFG{P<t&NE~qa@B3
zzVRxqJ7<p(TamRUbICi+rK7`*mZ`TL2S~@&jfZ-t`SZlnFewYu>$k|OYwFDx8cuHw
zhmYp=SW3Qp0=<FRiz8dOig37V=VMYs&-?)*IjoYYw^H^hIJ;-anT24ad13T^h(Xi)
z=nw&db0HE9%ev@vg}#Vq_Xa-@t&=$DbX5ZYA8L-ffp&l{an^UW#C4C*Ns}Q#G$3^2
z=eo=LIP@-Cz<?ieNIz0KLl5vl=ePr?^|*6UdAg#BX>Cu8Cc9v!d0O<#jIqyTV9>+S
z<z4pqgYJD_B2LXEs+4+X71$ks5CENU77(~OHhTgvO68RAQm84iMZ#dW7UO-e(SVv<
zY;WABTVGEzDNkJ*`v?LI=!0TySII=O5z1ERC;lB*s97ijaKFe6%y&$WCrFjk77%&_
zPD8T8t|S2<QGu*PHgpa?@$l)v^l<A92J?`8_!H`{JXJSkNdv$$0#GT~Rm4K<;wm1G
z53w37cI+aNAqtu>2=6RMjfy^tVa-~35slM%3K~*u8i_^oN1HHq_yaK&WSOcD;!-#Y
zz{6MuJ(8u}8MH7Y;(!Sd`QTe=At0E<&V7_Y(Q_b_G6E_ct(-+ePOD$6MtQSA>gy1P
zC_06lih3~-6_J=?c$LiBBoLnS7JrIs_?}<*U70&zKl}8V`*_|udfL&A^H=zd@mOC8
zx;`<%F7mxAo2Br%1i?&#+2|-D8ryO$B_FRY$<7#Al@*t;px=GY<2QMQ{_?*eG>^ln
zSMhZvf0wE%b@|DA^9lYW<HKH;ZSo7@*bE&G<v#P`>VuKtICxRB#^&4tX?dZHWW|w<
z<&O0nZ$_OnLT5^BmB-CJO8QnJziEU<M|sBD6X2}o(`d_nDbYgTF-j+uOU9|WkQU~X
z1S76O0X)z+pvwSjFlZI!0tyLI14c4{g8_|Je?IMWrNG62G6N%LWiv7mHX{6hLNS2i
zfKCDMAp{VR8VJw=YyqGm0D*#Z6^aZDZ;8=Kn1$g0I)b|GB<L*OOCZ~|_jVs&x%8e%
zH91=NB|b_<tGS(jq}hDGri@MX(XT@<;ZU9AOI3wUdMuH^xYOhqeyp-sKv@%&Tjp9p
zpG_tQ-I>rH58gwiX|`v{ZM6uCM+2S5>;iHX;+C6QQ&&%$k2yJXzoYj~p8r)p&NvNp
z=`66rZu~b3_7ap$n=6G3b~RPiWgQjpa+;4Q4Do^$BjMgY_$KV;M&<^-YNP)pBy79F
z;(gRlpoBA2A+k0uTQDr}=bdl(S#JHsA!hQDznF(TKXFh<LOCCI1oDu)KR3lM7i$f-
zLGQt_eZ^n(BX=1+CNwq1YS)WRw{~jft|2p@6E+IQjs));B*qT*JuU8p!j|UEhr<6H
zv+qD?9~4u&Juby9i13-@;wRtQGJjQ$^6hZ!s&WsD(1$ksRlkBO<@<DR@$G}CSla`3
z4_uJz>9%58ipqzdRh^ErH%kR>X@67GRDauEZmm?$M(cOL8HgdB9-N;0YU=vr+cU3y
z?PJ!@XgImHb~KxRRG%SIHJ+^R`8FA)+qi(JgAGK>lc1!XPx<V$)*tTc`ak%c-{FQJ
zbHk75D0mym@7J2B{q}x#MFvf=<pR{AX$tl#j0faSCmGr+<t5%41l31<xIa!O>j#L)
z{WjaxmG$X9A{n(O*Z@h32%%y$EGrpH*Y<Is+z3ykm9YxIToVHmngL8XPKE)64{@Nt
zwt(S)e}avIQZ{wY)5$^`M=<~)b`o|HIKW!0Vi>?)z<Gf4ZIot^e!)8dlEd6FUups&
z+~Y*_P|VO`U|~(;We{)&ZPWSVZ6cW>X2a9Z6i^85?Y<(3w_10TX+Yc689eC@PlvRV
zxJW}2mEX{V-9rEYgp{GP=AQd1PyR|1OJ8Z2oOprBzI(@-#o8>|OTpS}MD`uNm|w%i
zhXaq3Qb6Fz*>ClFc9<^R`cK>KrMEp73mTseE1N}c-om+=23?0i+t<tIeKv>|9wUIb
z?Kf?rQdMU)RNP#7C^E2n<=&RhlkDKQw}P+zvAxZ-q0FtH0a*URay)MCZdjq4{=vJ7
zx0GqtIBinK+vBYc885fr?)3ib115a8`oerAu!z0>o?LjSd4KdWRU)DuUEuv<f@~R4
z$H~C>IH^0lwB7rqB_VEy<^AS!J8t`py4}9>9&E3m#8q>mD<VGO%ZW?5U1ROi<uN10
z?5}3}$SDr1hSmg4JA2=+)GQr&HwGf*I-)B0pGiYTQd%6+jEbxxEr@6>@&c81EwxG;
z#i#b{{LFq|sy?f3k5_Lj#mkm4u&$QZlJPqK{3{~dTDo=sS~bi#y^ULOtu$lrEc{XL
zJbO&i^7ij1duu$0;cV-UBRYKnzm4TWO7L^#X|Zg9-1F!)TOI|H!;UTog-L(koMRCw
zlMOnda>XU)o=)@5ok*bKw}7Q4oQdQWk`~T20B3Tzl)&svX-%EnWuFrTEN&LIWdn>C
z98O??o|{-J)U2<eops|M{9!p1ZW;&(-f2Jng;EdDs~$)sJmHT)`J^@=gyg=K1|eCc
zTt&ixY69znt21Jb#|c4R0Dh$ct2?3t$ZOz<6YdIhXzFQ^)xdbA%21V)qUc?4lU(y7
zP{<sbFRJCfzhMT4V5h7WHFbX8bv#y^b5RS*BgxkD>4=5Yh8IOfyp8z1`{~arZ#PoH
zy<w;*Uisbamb2cr`=b$l&^md-LH#c2*>N*hK8`4<fEWG~PPLcDLFp`M*%Df^QUxl;
zULP~5OPTnlOKrZ&U~x0VGLU%m!+Yrq4439gnx#YAo=V}-@<Sfjtb&o{PYvY$$DI`X
zcmP7n%_*)By-c6*SFfu-;1CkQj@rQZyU1N0wR8!72~Q#r<gr_%=MSSc_VeKI05ZnN
z!zD{5rZWqRRUtgW!kvpu^5+p@tKHijlpZQ>wM$1%V7&i+cKOKP&)>p-weXgYFRx8?
zLB}t~)Q`(b)tny<vVu}DcHjwC+nZb>Ec`_ZEnApyc2=4Ah5h?qlMKHE{%q_&S{~@1
zy}z$6i*^LPVWwL*jHM2Af7Bu^od@W%(!W|_1`Ztl_*NA7l@PksLmwuKg8h83CC5>B
zQI^3n<|#YX`vc<ns$-57bS=Sj1INZZSNqjaaN4Bx?$kL>x*2`6fTewf&=9KCECwXO
z21}=*!gaoB!tkou9DSF#CIM8vG~q*mTUZh^EoaEyk7a<PRAwUfx9Zs5fV~n=16cr$
z&Gg%lN`2q(<Q=C9Oe?$q=-a^<rUCSsT=gUU8VW@HBl>NBJ~jK=MQ$x(Thq+v$<@sK
zn*usG0p|5xF;SsJG%w={w0e@=tQKwj_eqOo0WRZ9wgjtUPH2$NwL$MHock|P=}9l1
zK#0A=f!^}dC|;i8u1+9`-_^*za;v$wJJ~LewM$uVQHb4&XFO6Cy&&a-<knxx!vhn~
zCP>wRbEk=5>U7>L?Nv~mIcG3C(2lB09RLmKa7LvJocm4!z#d~$t)KN@SQNtptDp_<
zJ8S#;xaer=G|)|blt_9o>gdD0sCq$dgH+4VC9$VuHz9<1x&BN^|5q_KBwezo_a`G|
zW>-<3;<bNdLdO8!tkiJa(c~Y(1h)ptuTTc|6u$j2&_J&d5m>7H)6dSO9GAEIh6At|
znN&)o4ou>a^BN7?{hl3SPwh8)*iT`4s80`mPZZD<6o7j9@~m_5Y)(BUz%)-?YS#@1
z_E&ax8(BS7-gYOrAMR?&cKK|Ert!8mxZrHFTlpz5;n5q*1HBfW5rl?;Nd2oC6}B8O
z2Vt%PE^r4Nq8xBM@H#5X_)Lm(xA&g{?X>pHjo>oJR;MnEug!H;cKpYFlI-^PjuyH&
znf%HJ=7yHv|5X6O#W*0}ZL&iHT3ju21#K=sKg|)R{?iJbd*5>LdN~fNO+pG<iUP=R
z$+_tEXEXsxO(@F1yZSq;cTJ~#J4R6svx5a?OhJRj6+vJ0c1>A4860_ewJFS2trYjF
zQ&oA5x6F#Zca2D~2uWv^C@*N|Et&Ff{2ptm>OS%1#guiF`&DKL3g5UeCU3Bp8e3%o
zQsz`Hl0r?^hB(>bd$-JKhSXhXk_P|}&Qj_)NtHQ^P-64dV2E`u2%iiAuXNu1WwJW4
zP8V_Pt`OLnt1oJ;;V^x-v5O$zriyYz`<0~CRC=^IzC{<I6~=35CPN|Pt0puw0E$7-
zfkOjLPN^CJ3gE24dCZMHQWs=+1%U$7^Th=;#XW!i1iL^xJNWP(d4G`0cQmgBWIzC!
zjx(@4PSMpGxz{Hr=OAy5W&2o{+r07%wKW{JcNhrB_ySF@C%K31S%PD^@N=MYNdK#u
zyOk|>pXo_?_=;RY<1l-}t5v;FzvJ12H|nlFKgi^vJVeamp?dA@sqmKl-eb$lR&kZ!
z2sW&>%Tsm1mc7U1l0X)G=PrCLVZMc8%h>Wb3}FCFvy=;6Yp1xKui8D2jINJt0cfz#
z`LTo4N^!e8DPU6$qGBwLQ4~i&V5Fa14pun^^m<%E5VP02jru}U-LK3J#!~wRyb3gY
zxjuq#;B?IA^WJ=FcErM&9iB%8f;>H-Q3|K%CDCkub=Zl4O9#J)!#4u3osMAO#6;qK
zR%MMDG&R)IO%RV3vDWQ{L$nUJxe*5aJI!bF&ur6dwu;KpkyXjs_o)&MZsZ&!tRPYD
z=+a!2w7q*ysLriqw(iA2LMCOkc%5vKjHG@06xz1NTSrCw(XJm+!wT2${Oxw$dr)Y&
z{jQ)2Mjs@A2swCY<sQM(wM3!a^?QVWj7H_Ny`L(!v{5R!Tw>>k@<xI4fKcpBsi8W4
zl#-G0aXferJu3u+Z^(%Yhwo$j)>SWf%bG=`TkiLkS0cCYZD<{%!QR2Qcl|7vKg?Wq
z_j=f-h9p0=cx<|kk6Bx3q^h@)aj`m`RgSRxA62^?aUZrW3;4BIX#1=dlIx7j0S7w!
znfy=g%U@V~QW8p2mKpy9r$lU-ZtLpS@D$dB6a}IR^B*sd-X|=RqM$U%KefeoYPejv
zf6vJEh|lLDhHO%C*OsujRhY{wHr}r;{mu2P<43vgTSDoKD-3~jTcV_o!yiCCeLA+(
zg}bQ^O@PyZ69^yzV>%#L#`%6K3$R!vG(buM^1*bg6b>XOP#$2e6C{M<D9e=JSru9x
z)#`NegALNp;Dm3AaypB>Cxuxf?>TJ_U5PKgSaU~Pte7@GbBow6FM8Knn7XW9JU68{
zgXTQz1shlxk3A~0KQblwQk19_gcGYWY10NaCAUYejK4EHhkCrpaxfVUE)<YQkHZRc
zk5ezbuXBfg?(%C3b~UQvea~%|>h_Rlmr8bqcpB!()Qm&2d!<_;O(#<d?LUDPts-2~
zRijp(i9_&r>UW!LX9@8)!!=rfKA}(E@mt<l1c=>F*CWlS%8Z3iYn@}YB_P1c*~+na
z5j1^t=1-F|kZ)<K#*=rfLR;v#)Tz3cJ730F?aoBpd>g!6I(xUiu5;gfRd(mf$*CTf
zY>U{om8Fp<STsw*xSL%>v%=So$#UF!9)A1nx@n6{54->2y<T%8(Oki4{;#ldXJf`2
zOG;zpeAyX`+8|SbC4+~bs4Ps?)n}-v^RoT+=}Qr?LHbQAwPIAn^X{Hud2I_e05eBs
z?cWC~5;>6UB--I#2nYW~Ta8H|<-?%wl;Y7bTY&~c{KP7~&Y>@4veT>+H~~_iDooi~
z$S^=SPy(HrhDR$H9>{5MqF`Vg&H?swz<#GB1a25mpQn85HZA;%K2?AVnnmAooS)Yu
zvyIc`7SyKr?Jnm*r@-tg9nY=Iu!5Go1@GcMFt#qjNTfq}?zeG{^ymE!OfgrzmZ68}
zIh_)q!c+SxiAhkO%R%E>R{gp$s?9_Z3!jb3df`Kvc)TK$cD^d3!F0PUcK@SaKiy|r
z!}#CU`<*d265Ge0l(t=5r34+lr>X_xLWB$)cXHsc<xwq_)w}A5aO7Cf4>UX~B~F%|
z*W9gdIALeey}0&TzOn`R`QN&>`^dy4r4c`AyDgLt(4!ErJJvnsfD%!LOF1unr2Q*y
zGN5%nG>j8k(#WdW^06-TetK-QaF_Bf8FbaOEsBOwEnm-FAN*#R#J2zGP$V*kzL#z~
zS9BG+OeMzxE7Ib95K7woiIFsV$@hUY(TxNIUyt9Ge9$DgS%mOW)ff`c?~Ph<dxBww
zqke0>iR==@L?ZO4R?I9Lu@E}Z2vQ;H!+GF|IiRmaT$nKwO@)12+Qcm$p`AbWqUj@k
zZ_ycsYVT$lVTE1G)cuG>#85$#jUhoTaf{0@@#BO7^nL6u(KAV_nlW!mjAptYg+SA>
zmwSjqJia&HM~zwvL1;X@#BN-y`f2+YoG!03R;2caiwR`{7oil#cz9iEVwdv4EM(Kb
z(Frq^csA4N=96IY2n;+%j?Fh}LDWR)9(klB5*uL{BuGLeJeA<0#)J<W`jkWt3el1G
zZ~p$a=vSVE?gjIZA9_@N*Ml<xVKA7OPg->2N|X|DIX!-D{oA55BDnJT>nBP!3y#0t
z$*QA`7EZ;jYO23Xr<F2ka~KZe*&_BvixT!*Wkl~~co`tV@NT8(Wj|)SKsP?q@p#yr
z+4AykIxd4ximuQpALXA9M^b(L!ml!%*E`d|zuC!aqx)E;M9QSDrk;j;hDvgzLN!R%
zdOmG7aowAL@9l$cT`x8HqbB5BUz$7*aTy93ofvE_FwGaoA@896MRGWa4vG=o2t(*a
zA(=bb^cmg`YtP`->NU6e%MPYc*@S^9?ESz*wi_0WF(Gtxc1~5~wI?oCD}zkgh)PR*
z(7ej=FqO*ymyR;w%nHlqO6uzrhTZ;FNTsA%2BD-_b?a*P51yOuiDe7z=~OItOTU$C
z`$=Ev7PihEYHdo3x84mM`B39z2{+sf@$uq0f61}mg@wO!FbmRAoOBv^%R-e^`JMCD
z$5}q|g)1MWlaYeM6q*7oy^g3hfe*&P?uxT~WnPPR(mKBS@X{^v&m~&?8!1Pn-ql^J
z!F~C(Yu9A9b387(-IZbR<Z&fw;5Q2)Fq}odZRej|!>spI1mERbza3db>2AqlAKY`3
znu#qgE>QS(Ve-dnTqK?{BEritV=N~My`v}h2!fBW_RiI)Y+*!Ir?f5t`xHYQ+NhGW
z>oh@y-&5&c33f?j<X#bbs{)x+KdqmOl?I<LK(uxcwys#QovCC`(@=L3b))-ias{T&
z<antpF=L?iq>bBZ!`^90PWB(IHVY+}!tkoD3evZ>2g!jUqih`PKh01fxU;Q2+=Zca
z&F8hrC5;*-Y+u}G4>Fo|Mya4NZ8iP~m5lve?c4AVDgIn;E5&1~I?VQ-Hj#I2f35c`
zzD(0EKgx0_Ldvm{Gj+e0=(#Tv837@t6%7r|?jURXRMz78qo<%-fpclf6IW+$gMDhf
zp?ydiBNuwod{qKjk9?xJ+xwi>7pOcG-(Cub|9Xkz*9e3mH2z25LAq5Bmvg3<>!O%n
z4el7qrS9l3(s%q)>%p^wcDo6xweannNBf^oj}lFH4VsrywR`b9UbMRTUka3Wx=OCA
z=WHZ{r(&x)skbIxe7eX$BMPfadTGnYMCzCCai%J=ZChkKv!WzZP;>R$l0W<@d1|D$
zc=rYxCE$cpF&<OanrD)!Fh0zJ@#Fnhh7ZAp7Quw4le8a^Ca;!p*im{|CCF)&I?q$L
zH<KBB_X|<J{atBEev=Szn3pb1-IZmm%YN)v<7^phNI==+qF*^S0l_k9i`A@ZNu^0>
zFud5AuwAH~`2EZG{;F!;=C<Q4=XdM!965&AjE4*;T)#({p7Ge~FN1_$(}lCWo!MNe
zvuuTj``zk)vFLnMD}}y>nZUZr(o9*ePERR${p}w6e7LqxGjYhMepwsw!<<H;G+W1+
zkC#SbWg%F-<i2j4k{AANA}p1Gue|j0(QZHUnmvh{pf?^v`}<;c1sS|IK@}lmR5_{&
zvnro+lYb+!NwC+8HYk7HE1C-54av|^Db4nAZswusPYQJ1j<#`MJQ9%X$h~JFhVl(3
zf5=ZVbd^5JcWVvZWzOY#;(Izt{oy@3pejd!dC30pG~wgKeIk-OT~hZHK9;UB?6fk2
zRB=JEZ}$BfA5GQF+3@b)?{6seT4zJx5B;vy+u~U8aUyqSy_pFDtfa+nh!R*EiCHMr
zd0+ec7hLiE$+`H4TYB9vzgU%%4{vW2Z}u!MHiGUzOW9doZ|?=MXr`4_2dCMlqsq75
zE)IDbENd&s*c;pI8dMrp_phAhbblZMV6K5|o1tp@-EJv`J2N}km&)FFt@?N}BbE{e
zp{3M#of3xUm@)Fux+LtmS*Z)E)&w!i52^4sr<72f%CDD?S`$wd<XIl_Jw#l1TlX+M
z_7M^6Lu)L%ergea<8JRB-o5l^BF?>F`pIpCTZr=?UzD9qa>x!gG|P_H7J6AtbHa{S
zXWKe;P%&p~6NK4q_bDyOF}?Ujsl=*QW(bbSeCPVzqk0}3>2UnE%I@#!KI7(zs4!_e
z%^!5z#K~3K$BWI?(JCShOYJoMW5(Ok;~a+q)lX?cAs>ii;rS8uapTpo-&XvD7lh3d
zn^tZq-;JUC$i~LjJ(jLq@&|FGxWI}=aC$E*K`zl^5i_SEqn_xkMY&Fun%G%D|A*wy
z%<5ty>eR~Pn?7Oe4p3`xq8#(XGN#Q}-@b{~I&Y7D%cjBjReXLfVY(|pf$>T7UMIQQ
zl`S*kZNSSYm>3|e$UuwHZlv)887C{=|4Zw_pp`fQY<BR+=bU>Cog%fb(>-+dz)Op=
z1fGdm3(ILT*%08@w;r?ANs>!$segUhri$Z+oP3es2+yI1+#&g;+71*2y>Brt=_ti}
z0~<Pif;0K?PX?ykih99+@@n=>kPQJoSwyy*iDXt62882|7(yUZm<(Zq(zK>^ugX0a
zQ?YB#&>1V%;#NRKSuGNI%iuRf1e`LAo2`S-_YOsZ@nZ@fD5TXJ$Y$Y|wCDp#PXB5>
zXh<u4*d7_-7~+R6=Uch-T^flZ0wx_=54#iiEWPRqXPV;){KOCskYjlVRT}rdZG?n_
z$0KNcIW!sXfn@eyPcC#eCMVTLAbEdeluL`L{;B7~nr#%SUl05ywvaAX=Tr>%njvi6
zqzCxCWN(=EN9WE6FV4@hk?yYC1?*2ueh=On+UEw!=eL(lnwZi!IGE=vPZQ4B(S8o7
zEehN{@X{%)-5$Y)^|Ft3Xk&dT#tSQdQ=e#8NNzme^{{G1yv?aEEk-8fu0K4m;u;;L
zog4O3gbr-*_IfW<Rf^^}(-d=QixQ%(5m{L~KR!yoy=xj4p|w4lo`*X2b#ZFKOd~FA
z;8+Z$$0n7-PUIf=a%6RDCEcJfw$+8lG*i#<)~{JY5r)mnbf~EAG9-on=(gVMVCCK2
zKGkk7dz~OT3CUuU^ZhKp*VB#}`;Xx11T@+Qe18kV{{s5mKMC<Ul_zRe7VR!1zzyah
z1W7Rn`7MOz7sC@jU&l6kiOcoKM?AIs{o_mM6}8lWa%MvCt=y|J#l@86$3$^X-G5m)
zbS-StzBj$oal65CO8kgpYpp?d)a@mSYCp#4v_UwB%ES8La{BUE&-pl``A+G5&cys|
zVqF!7?SrvLxJDVhnIOAbZUDb}D@K_gQ~f@xeQhRZ4+3?Odwmr5=E5D5AJ1-hr@y3&
z0;xGLmSGuTfoj{t97%`9tH^qwlC79K5dNl<kM{*6)Y7>s$vZw2F1vn8dkQ(bSb~3-
z@CM^8_C#%P4HA4E`d5oVuSyqT{nX|q|4+GuVGjG@U+rZyRIW<)`S!Z3CgW8x%cjk0
zQHnn|6z4RGp-`EH6BttW2vgDXP8*t3>;}@DvpBNYOD8f<#+iD;qQuD$naiZ_UJN0p
zq|RD!T^sS0Np2-tAKlf0Q)-3Z1WQwHFJZq-N#b*(z0?N7EHts6m_4-_mEzu_xjbeP
z`uLJhf~WbR>nTH`5Lc&{6?$#cFk3BuBIEbgjw6@v9~hw4HZ13q2K`kdbI5EY&AN9b
zEU~?u%U}z-gk?|V<xxCzeolT3^<f@R5D}bnay7+em@SlJ2FAzQJ$=KkZH`B&NX;Y5
z>v%555BV#UKsb4HLBa!R0zc9p@Xs0{RS#V?rRFuw7Yjc#9L^4Yqp1<`FEnI-EjS49
z@!ux;09VDp3m`4iiT~V;-knf6yJ0{lSeexKu1WXtxoebi-)S#1Rwyup4nwGvle4ss
zcT3#oKHIaQTUt9@w|&PVM&UD_4oZjCiC<<_m<p5~UOgvFOYu8+D*bxKJ#X|6Y?k-g
zt5VCwR8@F$lW2MX7AUdI{}lN`CU|`10!Tz@;Y?Nz#gb+m<->WY_{^o1YMX<oO%a1o
z_Wl$n4mAFElq^p;s^Ie%J<IRkTE91@r7>Z!JJiv;&W}jRd)F*6#<MkQ?hd%RzdL%}
zc5t5`ZM>-Fm|@(OrtldKRht%(l|-NE2H}iZ&I>fufBb9D45X;sxck$*vxL>1kNO>!
zlv7?>ZBb??K8?8ib_*NVlm*qF*Z;VgH!#nLkWl7;1`hDRL(B4@DU$zNru4%So34l1
zpDAUjsBVcMv8x5Bmt#I3J`}0C)vN+b58S_?QVYmu?D1?T?0VW9J4GeRo3&CUL*Ijy
zU_Q$^emsRLh7j5ACZx=Kt$OQF%T;@}yGGVz=l6JUyZrB`^!Bpmk?BkGbgrs;eS}4s
zocIuK>j*B<->{~qe9PZt>-}Q7JOu`Y_wmBq5V>!ev4Ap#?hGiTfU}tW*<^O2AXZKu
z<dRzUzknWKKtLM9)vDwwJ3K6mB}$OiQ<ub@?M^XG6h?#YUx<emqnIaWx33@F>ILE{
zzI+#rB#&~<#4D(CG8R;uzVx)WpAnamtt_adJHKIxIr#{i*eCp4H=Pro2vuPFZD(-7
zv)-5ZoaY4wp|`?I_Yk4WH61KAW96P~I3@O?u_23Vj`Zv}^rsZeJrmemmes4W+sD1?
z>hhymqk`FP@8Is3C<*;dmlhF#eXf-x&-?qZrENEHdyfNq3wXsoo~iCms}s73Co{_}
zi1EtdAx4&I8Tgua!vw6kCx6FtCVR{;QJEcM!-4(3DoxPEOQulS;Z!L$DdI&z?_7oP
z6*fg8XHi;b!tIBT{<7{Jlw}toTSXeRT#UG*T3^-d6E+98r3`Cb8YIHZ+SgDOpKpTd
z?s0Ey(OEOEkI9AI<ET+dX4(oT$!4p(E}=KN-Av<+RS2i6O|^QV)DHjPsIleN$cr}2
z$R}#rlM-MdwT;G3@#>}rXEqAH^$gxnSa2j*y1M%LGsPC?U6IJz#TnS@XBSzQBk%PQ
z6jt)e)qenh%2MiQCi2Ojrn{)mq)dz6X0`Y3!-dnr5F^4QP3yhegeT~YkE1O?3q0t#
z&y_lL3_cY)uT5CnP^^<U{W2a7&fmRNKUIY1)G9WLYedRYL&pQZ#Qm86#Qp1#5@zS7
ze@6Liky^DfMb*LYs{7r<MDIUnRE~fDs(~46;j$j@rbH4+_rZbw#$mM+DsNp2DboLo
zMW={hJy-II5k*?Gn}CLtgeW8M=F5Q%k!<67sA`XRx&OCBpTv@;ZEc5awbvRATC0B1
zQDb@;Clo}X9d0Tw3gY2V2o&^uRk0@!R6qSc!sH;9=;9d(<Mz*V3&Pw=p5-G?gr-%e
zpbDOM^Y!s#X-w8;Tog+mC@>>o>c+6p;d9OL=>#ydlLDZL+f(pIVW7e+s0$yr-SHq=
zj8p61GALp~uZljW{L9(#{XLou%5TLk`+~6u7l-Pm>p<kUH-Qr<7reup1eL6Sb=xG@
zJ=^QA(sM<HSi2{BTU{%&7O6Qx*LXo}!Rdb8dLqAU=~$p{k5bCL+_dekw(__$@wA1a
zkF!XZ$P+L;QEZf#>#_CmIyD{L)?0|-W^2-IBvu)*Lcd>+Ec<;=OQChTnxI_+O?i7o
zVBS)}v)vrwtc&?l94Z_)2Nx$|$F)UIU-mv$u&lsMlFlX!)`XBif^W=O8DGFmxa5=+
zJ9pp-^G-xHR%vYAk75Xu%9Q4OJrT97DFRilUfOm|;YQE#Ng@9#?1vkv^rLb&XWZE(
zrVUYnpa}?pjf6uh&9q#`l%Ei?7XW(#&v`5%o7BPV;^Rp6r}Mkc&WpCUq@yZS_*9a`
z9tz0lO9>|zr(=osz`t}PPLHh3{7e?=f^aBpXNd!$9{I?5AxpWxzEh5jH-<wW&ehIo
zVE^SUU{A%ixi{!}(N1<>FBe93obC<KYRPo92zIs1=!MF%Hq;EFk{xaG-xKgeRe%0p
zv<<sSy|QOs0%dR_N~Ioj)>y>1Ks<V}+LgWxUXLBdkL(|9W&jPx5q_UQB~)uFV&0b5
zFuPLOl)kma?0Q(tos2NlqG#bs)0Y;Wo9vk%l7ciTDwy^4zlGW_t7Q2hK}xdoQ+9wt
z31WV2e;}QCP($7RBT1O6R(m;UVpeZvnCvoZ<{~9kjXC_mZuiUF>8hqA+e)+3J<HKu
z3^KN^rpEirYiki~Gyxk_DtsXNIgR}0k@H+~d%?}#?{PVG<ZB=reguk^qofk++x3}D
z4ffS>YJb7OFbPe3^Qz_EyJuHIFw@uSuTl;Aer~7b?&dR}p6|H<0^aJOsm>~M!6)Zt
zJZD^YDMUxZXQA_B&(Y)NYYAlItEEIu%U;JnI30r3*CN#Po)0Gn`GK<H_N+5h?&*m7
z*eNPaxV+T4BqLh8E)lm1y!N;OGf2`?Y+YSl-`ibPf>n6#?earS4c^5WOw$^a6pt3a
zmDUdaH*OxusoP8`DO3*sLDx|L{-Q73#ajErCfg}kk8{uUy+h&1Rvn7fee($}CMOLB
z>Yry4-0y|)3KaqB%F?^vkcE-!Ln;zQKiBDi{;=(p#)GSZokm__Q4(KkV!g7X*$*Lq
zNp>XY?DBVbK5n9v7m&9EbvSBV9%%l!=_?!szrS6e^%3+T!z}xZRfk0~@?9>5H>HXO
zt5gfdCQnU9_yVKY2z4`cvX_CkkEE2}-=t;3ZCmn=bjg1nV@LU6mAe<EMB9nGZbMAQ
zov`k7_B3RLdWot-{xxcL{y(DTFfCY+HiHyYeX*~IBKhys&6LRj2C)yV9u?^53y((?
zUUd4*^h6UC*E+0F(+LqLoQ#GJ+!+sPEH8aWDmWgAe#OrxCzBetH75KEPCFmbBag_N
zu43IzwRk5}%evf>CZua8vZQM~oXI}~+I$41Ne8Fyt%a2_a6p$JnEp>Sqf~Px*7x>g
zZDpr;>~=C9{S0ZSeYotvtx`Ro;G9B2<S4}SJgibB&>zgh7Mbg3+QN}k?`XWT2(+{(
z;V?*93e6AmKhF2vXHoFPd{ajA@YPnXzl#X}f1~MX?E2WSR6A^ra`FqC9~GV>okQvf
zxC_))pjsP?)Wzda=^Z>;s<Iyg#j?Z_Lo^yM6Qw^@_+G19;w^bqlNw0xy#C?+AN4j|
zgVoBT)bb-oQtyErYGxDhnc6SKB143Ck5bR7MI!Ldo4l&cE_J6#cD2UqvD$dM1GnO4
z2Q&N)<p)&BmiiVA_5-KqbGKL=vi#Ad!Ubd5<H3Ks<hs?xRNn~=?w2*bjD@ubwN{CR
zq--Xi#KpyLnw+g@G_o~2)ynuvv?Txh-o=XK|8OxqsrC_eB)+7j<kJgu9r_P+-B=kT
z%nWM9+K5EpSp6Byy)B&<fQ^tzoiku&_I9!^I)XYUo!>nQg((26mYym6R$BOlQu=0L
zd+>W%+^vZU;>!Tpj`9$;%JG`&kCtPoO&A)?v}PS*F=rKIF^7d<5=HyPVopt1v?l>f
zK~(?G1yfd=hw9(^n`*Uma)gOW8lrlb52pW>fvA2OX`(XzBZmzl3=;;bc8;O+>zqX%
zXfan@|0?zc5a_J@z+r>C75pl((CtO(i;x$fU{XN#MYPk){{V%Nm!b^+(dfN&7Nh3-
z^pXM<P|DXq@tWbK%J|U#7Q1(P(fvA6J`08h+rCyLsDd=dumtlT)x0S<FP1(2Q}{*u
zs|-;N+qH;)@7IR3T>U6s^t{>|AMl?HFGjx;?NLK}m0t_yunGHDp+Cxt)CH_pv6zR@
zJuhaeCK10%%wC}UpYA#5h_sj+eEARaf%C-)dH*ODt$il>$C#2)7KHzJr1wSeYa0kH
zq$J$^CVM;ODu1#$l=$~e3D@9~Fy)KSx)`56dzBFR7@kqKBHBqSi1QWr;iv@ph)qC%
zG+Oe0o%ccLU4H`(Q9?!VA%9SSpYl@r*a#_xzR7lNu;nkbp4hR{HAxoi0<PrPt0P|;
zC1JRtXB#=5d}`WO`?cj2I{RCmiPoFtV$fIU0vYT2t+|DgkVJC5=e7$FOYba9H~h#1
zj(XJdqj$O#CMx9EoVG4gVuOTS*>Y|t<L>>O5AUX~Pj`k;-mw4{g*N1ryi3i=WvVc}
zB8BOxpxk_fXlCj%ZuTW~^lx4ZLtueTk`k&2LJzZGJJg(Ze|ygwr{Q*z06h+%R+^5<
zzK0MP6b%y*&NqiZY3z|zW0m{}2We5N!YCjO(RzL{wJEBP1Qj17<`J+aW3&OvQ1#Gr
zm)~u_Qh34e;gi_An${Jl4TrlF%^~Cvj3*nk1RUzPxia`6I$~+yt$Iic;tOL=N^-=Z
zc6kB@Ef8IG%4haa<!RMkh+NPPF8xObVj%dfZD=qBVQa!_5`)JrJ>O9<M9g-Nv?tG~
z)AmSkAzXgn`a-1)@uj0_bthY`#<u3h5tU)x2e?BB$4Pn6O`z)_8Q}L0cpm6Upmcy+
z^U1sOBL(~_G)X6x1=KHpM+U@3s2@;JV02b^A}GI3I||7JiE4prxIPe|2Wo&^LkL*m
z9{^!Z5&?vtATzM~Dq9Sq5Asw+ir#3`bH|Xjnz--=ZbD`H;rU&ZmF0>xQx@Gkk$0PU
z_nL3C(-~vR?WrIfDoc%HK2u${+7;8Hc2fLeUD;`No2Mn=iJP~O$AFRGtRCAtv4MVn
zfwTUO)1rK?Em%RXCa<VJ2=z;AxD9rheww1^1%5Ti;DY0O7}*$64!+0k2jN-$Pg16>
zOJaeE4=P%?qD`}jWGg-o^VU?*&?1Rwob8B9z(;va;#j`=aeglfZpujZZGXKh<~&T>
zvCk!I<`wTbuoryrA>+dP%Y0ruo0mgH-e`rv9<sCuL3@I2l*#XL0eBE57`m#{kOH3`
zihu%@2TBH(y5s!`+9x;^;A0lXCjbkCw+f9A@Cc^tgpCNmqQGQ@d*IOSKu-e^fXP>(
zioiTEs4glN+CmPWxO#I-hL1lEpqBeMPq`+wy@!8ZjOK6T`CEBO83Hi`GDx+BZ8oLv
z-}~RfdOUgVf7z7Zz(KZ>FKdjKfcm-U>#%HK*)Y;psxcKMW>{hN(0ribJ^*{NH`Tm$
zew+k%Y%x<lu|$V>&mHktW+C@yd<l&*m+AL%Wh^#P=`w0(eXvVk;^W=&ufssA5FNuB
zP3u_}mD0DHclB%7atMJl^-1GznOZD{7v|5M{77oAI6D2P!58Tv1*|Rm_8*B(I_niv
zBKaSAdaLXXlct@CNLJ80JEO`h^NM<5ZUwM;a5J+QMyK8i%R+a;KY)Z+QDOjUP#wfz
z71M#39<&S<Yrhx_CeDHbvM_F-f59C=34!4h5C8%s9snf<?bCNQabOmL0Dut;;1nQ0
zBf>a@cpQBdNQC_9WXeJ`V75*LPGI=nvZx3rtt|=mWd+gr!SPA|m57!+oAW+cNP`$c
zJT_;rqn3i7IhXnY`qK(wY8rz6P3_eM<#%?l09KJ!LBh2wCjg{|iPQw!B&R>j{9H!G
zc&^@U6btEs-@YSO#%ORz*5EKbEl*DDYe%kh5VDr(-8ZhSQPLL};#~4GQIodjf(YJG
zsRgHfQ|*1I-jatw;k%R0f`x@^B~?3Dk2)H+-TSC)E({<V4N<)dnc-G-7A{W5jkgzj
zjI6F#sSrA(eK|Iv8atTDX$(yYkgY;d1ArFD4S-&RqflM}t-=Vv+CldMsG$Im3;@Ou
z*zr!!PQ*$O2?$;Dkr7rK3xC7ZsJyB3834qp!{+$Eg!Vx-L#z67d|)~5O0Oiu<aS~|
zw+gq^^BVAOFTsW6L`?m<dFaiKq)}G#rD&{KIoSBE^y(0?&jlg5B?q&0M02U31V0P5
zXB#9G&Grs&9-5SiiIsn&5zp71R*no$_E({5@sx1>-P)x^GzYY%YqXe4!ZYKXHa*RD
z6r#SIkOMdviv;_Ptt}Jw3;g#Whf4=V;!&3yF2*sKm&Ke_zs41@{h6=3vnEGCx05`|
z0W6kjfaFs<b$K#i8$b+Zi=l2|ABWi~?y~rHAchxHcF?wth@M-FZVtGOX4I_ZNt6@~
z>F7pWdVHF1;o9!v1S~y2yobiOhW3<GPyH=xcUXkm@TMz5{SNh~F$mC?f&Mgx9Y#1+
zMX$QzS~U(G6Z_64t1BkbQ1en(QnhIQ11NB4h($otRXHPo#!Yr4uGzr&BD+CrkW+*L
zvur^z{ZG;3f*(9J6v{Y^1^Nj@IG_QEPzyRTfSLl^1Bn_+5scg^qicJnFfQp?A$xnV
z(?1uEiN9^zbjM|~x#+kwLS1goe%e4yxikfblgj*wX(TQ4jenV7-MU)s0U5BGq!nm{
zT)hqfb_M9)p#ihQa%{L2q0zC$jb>a~jaQQ&(^4+K)5!v@Wtu7Cdg}jFOZE_U&|+RH
zw=kS+^(LzzOUk65!3q=%MvKWwyCW!sZv@!^5_nHi0Q;AD{S+JDJ%9k{?Ig`2Ge8Or
z5MAXO-`>d39Kzql9Z!SnOa9%CLEZP@O)6do%xMv(@Njy2-q-q<lmoD=EcTfR_){5L
zj_($#>Nq$Yt)5mNy4*zCKvdv|)kX5}?QN+I_yE^z5~kY4fWI~}^tspJzQBSYb0ZVI
z^DZ}B9Q0sgF<Q4uAR<(9t}h7*h>QYY23P{9O)(`gG0+}R2|(X%_RHWX=6R|UMS)d{
zPADSiC5T+7B?a^xOcKxw0WXcwsB`AidL>+TL@qXzH#GpAw{`b9$T~U^FtLP&6^`uB
zI$Wg^lb&WHT3g~v3+~i<j_rjsFYX;&nm%B+yn34N(Plc{{xc)IHgH}^%90YTacnXO
zGC17xfBd`r`D->Dr?nE-h-N)gok}lM@JL#N@jAWw-XAsHlo}M&Gc0U-y-2&7n}{OS
zX%eJzIP4%6_MCxfi+K4tskpb6veoiqYK;QCNF|t3S1i)?%3MGrj0v<Q*m;%dL@Pl8
z-2#Ogx(R~73P%#)Rz0{6fWRCIr5H6tp!`l-3Rrp=6o?jBcRpV)xn7l&(O|1sOqfZ4
zVDb@dXjq`FC)O@7E^{UH+Yh<JjoUZR;7rqyeSF=omnXJd-hWG)_Pf~1KUwvbL1r;p
zKYR(`fau{@{@@nPzbs6p;A6XsrpoVMM;<0_iPC=<;@Ledw`*H?#J#i*fo&MR30v{a
z<o7Y+RgJXPWVgT1ChW*u8;P93#^3tGS!>B#RTmbS!c}<MMb<isG;8L2!l<He%`S4Y
z$Dn_D`f<vFAzaC;S^HE+$VB2Cccb{z)vijbG<ay4L7AjF?lB^`2k-2`iX5F@S+vec
z6;EByn<}7B8gp3VWQ{^E;+jLtNjlw+`U5knJX!?(B32F!zPQR4rJ<|=sagc6EW`qr
z0Y6!Yna)&}6#rQsfuxZ}<?4u{R);B@$D7xeoolapr~;|en~3En#`{Y1o=B#{2{u?&
z$$U(z59aes;dDkg;}(5P_gY^ObJ|318j0#nsTQ_JjdEx&GJ{1qpqf64Qed=y_N{%J
zHjD9cXe|+AqIjDwWPmReOcA3>7XW@iy1*0|PbEH!lf*Dk0Sf8gD-26KO553p>bvP7
z=yuL8+iA~eUg@260KxyZO$Qs~4(@<25Sp_?a((~bcITwFlYV~&VJrpk;4ab{@V+4O
z@P-_7a;rCQh1CkPK`>BjUn4AV#EQH{Lj$6S>WTZlY!-AJE{XWh9&6giHoXEb-bp6u
zsm<oQM<MdE5h%BhUYhm#jyQeo)x*bdFv)hPLvo(-x1NGX^Yxl5%Ec$~x5rU&LuR6a
zQ}5{48+py6AF683E1_e}*<SIYu}`RE7EQa`$OA<=oimG=En_Fj#`W?k*q-FBB*=bq
z)#I(xKAzvFrvRvc6V3C9>xnn8bEJ+X$9YHMAvq7Zc1|RFG->yjse0c2&itKA<e9B+
z>i;lQtn~Z9htecp>vZt0TIrWy&k~F2>gNgD{vKBV(-&E3w?0Q*xr?=6$wc*~?-Ae1
z{>p8@Zx|>eY4gt=5-(_wUO(?%?^||5PG!Aop@fgR^aLMDFRK{ebsi^th@l)P&3kp#
z`PK_{BLb;<Hz`4w6_<*KC&|>pom-mGJMd`RTDjpK-IAk+6=j6=9drA8L&f=ua%nc_
z5#3C@Pc=u;p=(ONJg-I1>@j;nli!FF44jN1NXfYp%v;~Bjv}cYu;e4qxJKPr#!-H;
z^tP8OCG$=C1RAr?U}<>OT$9gN%iT)kb(1Vj7f6$gSU{dvmNZ<4mj(w0VMDV<7vN*w
zwiakhztXz}OjEu-jdBK|7%4ju@&7{=4;B0P+#Yi&^hZQyKM#*4(PR3%_Nm>$bXNjZ
zQB8Wwr5#*c3ulbR;i_E^z!K}c_-_2w{jf*5s+4Z|d3S|jgg!!n%9GJcnXZaYwAu&B
zNmQuDcwTwPh66)J-!AB6)S^l1=<^K|Y4`<}WKk~)Zz_2;8%7hf-oJfUYQ^H+AM<fw
zpW)S#m#H}XXxfp91bmv7Fyd^@FZ#3vl@*rWM=Ch*MnmO$8^^=uL)-oqN`1^?&9H$H
z%dXR;YH>}mH}uQvvQ0W+vTl(ACBEs8FgUR=K3EXq{kNGHI}ofX$$gL{qma**&35@0
z3H9u!j{hXbE+&ef&eRuY)*@wF)R%*zCQ<oj?Od+Yckyj}o=WYycktB_5l-vt%)t_{
zwoyff))jeK|92i|td%wJa^N(ADn+M9%`-p$9#LD5{p5Slp1HfzFClO1oik{!+&7nE
zFNpHU0YB4$R*#;n*&xQ<V^?*oXpZVVmn_NkJ!vLF{TEfKiZbYr>*VPjxywlZ@)8eA
z6&ZJ~;r|ppz+oT+jU`7v;i!Da@X3lFjMk!_2*nfm)tQXSl5Am>Jp5mjHqJHFNCHYm
z4U0jsQUpm3zSAijnH)#yP$941OagE`gA(k_B$}HX5HN+$8YU`v)=Nx|fiR8O)b$VL
zfa+!F!J0sL=~nxp7Bb8?5}kk5Y2#nV9c9czTbV@&(PNxGjq01%B!zF-_2C8FLVIna
zBt*~ey2dyTT;*wA1gL}rm*K5x0vI1&PB<bj((Vmfy`~3+i`5qYuAF`&fJ}S6YrkT*
zf{~nTyu_UKqwB_UFuyh*3jyW>%?mX0tKQ>z^6=P8){$*(eX4_{KG?^5$WHq(N*NGX
zY|C02?jL2R(sH|4a^P*=3L*=Ktt)sb`k6?mKDf+mO;Zt`yQZ(}E0XDa3YtFB>U@nk
z?x$Dv^4W$Zk{<P|zTMMviz6Ly1W*79B<xWuYL1F2Pw>^Esj~@r`%*IAVr!3{L}cT`
zF`-g-nn5-X3%f7`uv0zwXJ^lhLdN7|xr&&Y_X{h7!soLu2UB;AfU~y(2_K7MhGtqS
z#mhqKRhCOq?t7Hn2k$o1!ksp`%kCNg=uhc0E4MW+KS*3sG&Op<mDW@Ej}+Ac9ghUb
zrM}jctB#lqMbC^_YA#lrqvA;IH`U!85);{_H7|Qjy@M~Y)~kb;-n{H+shQ=A?_N+r
zW3A0s#uBFczG<%WYaaG`A)hMjxF-ByCS0?=pX`v$Pq}gy{A1;tTW^g9?hw|<$CZ2)
z!MWcbU1o?p@=~uL@DGf64xc90YzIlms6dheuGDLebSk1(3$IG#UeK?9C!bHE|FeI*
zU_q~-*lU)UQ1O>8^v_Z2mk|H;J$`-k|0>}_`#?@iM8suwj-&E&avYEplM^lfVDR~W
E08I&mBme*a

literal 0
HcmV?d00001

diff --git a/doc/devblog/day_586__wrapping_up_S3_import/s3rename.png b/doc/devblog/day_586__wrapping_up_S3_import/s3rename.png
new file mode 100644
index 0000000000000000000000000000000000000000..eeb71dcf24df9d373999a17f62014321f60fe8ba
GIT binary patch
literal 10321
zcmZ{KbyOTpv-jfe76=-WV8Pujfe_r?3BD|{=;DMBBq0eJ+}&kyhY;LtahJv2_mbzi
z=e_ry^L>9zPfc}ARaf;)_it({TuntD51R@b007`Aynm|!03d}w(Xp7wPwj4?%=4!c
zmh*dkHvoXf?C*gTm)r(^Vq$<5l;2^jqahJ9@OV}|+jwG8g5T+ZWkEpTM<*~q*7c(~
z_@foQrybaqUS2_2O*aUi0sx=~D7=-{@`4?tdiyHP-1RPdTJz{z{rLV}FBrAb0a#me
zX>3Sp9GkUFu5GLh>?v>5sF~I&)`n%hb5MxXaIo9|RP<^Z^96BuN%i6~U5tWtRn$w1
zfTi;LAHN{O;`1%(!Xv-jB(s|lk9U~C^a~%Ed%w}dm=L0_mQB3Y*3P9sm9C#3eNXY!
z2YZPbtVR#6d#R>Hx;uA=9)25oC!Y-9-`f`TR}C@{Ba!9DT30_;K2<gE_!)SEY%fAZ
z2i9(XWmrgY(RV)rhTq=BbDt~~m7!^kE?qX?ST3MZ){7<eGE7Lk3EweXZY2g0^k@Y^
z4oz5?$DYSi60aAD@t<$0)&?A0a=r!`SFo4@MOs|kukX_d(qFKIwrlKZrXnY`T#C@f
z(GWl2JYT6bTt2n@j($PctqR-Gj=??IF2YR=NInxW-&&!ZSzr5IVvu|{Is+OOMI5bO
z2|Bd_UoFu_6eCkHx#*K$t$h@+Tc1jZH|2=eWM8c3EZdb;As&pzzo|I=GXWaxyS|=3
zRv|HD=NqBrXCvq<02><k<Kl~DsJG{6Z<`try5F6NFm$%-$S#H9$NE_~^dJ_8|GK1&
zWSmxH6&X&w#B$phvitJcn06Ow=qmQD&yJXM4{;<5RS#K$nzNe{_2-+HTMj!iqt{4!
z7Tl@t45@&x)Tk{4&x8jnp=KX2%p`yUrrgCd-1jIM>|szD>oqYPv^Oq^!@+1kyBe}8
z$nT$zchGEENiUc})#`(N^u!7_wiUQ|I`Z3kt1;h8ab@^c8jY!(v>;#*VB3LAJ_<9)
z4yNSu_A^NYt`@%5owbMhb=x|+g!A)p3%91n>A6H1RIys3^V&vo=Jln_3ii||M^)E*
zwD%Bby~*dMm1YTQ<@OSJ?ext~a7(eC@2w_&yDQZ?Lk-#3lqWS9C-42B%_!>1IN*Gm
zu+LG#QfK{-9(qP;P+2^1^o(_qySbkcM5}!K?rV=1CO;YQ71*6R>}`)L`8pBl=#;c(
zN9FJ|K7wGv+{hs7gibWev9V{d5+lic;p-+(qk*j~jT;r0oLR%?R)%`Z*}zuD2;D~%
zv)}bN17t>f*@Zh`qf^l2SBK4<K60fyZu#xF;`gu|=7<*7IpZ1T4@82pL)3S@7uU12
zLl?`BvA%m%9<Yf14u-=M!?rvB=`9qdMa6nbi2JcU?<r7>_2X-m`supj?fqY27G;U^
z0@L`3Jgn>e4dqPtq%NQOgLXm6dz<q+EQT%PBV~yv2lpZB6yhj;ns*Y~t&iV{Y!&?;
z#xmP<QWc@kZuyMx&V3s$c*}JFZvLTpZ_7-M`$n1&6UlGN;*ftrT90?SMp~@cR~It>
zFwTfK3J|#eEQwmY*u_r0C+Q?B=lg1SsqBn2o{0@`peM8MAb<baYzM#ZSkwrWZU?&q
z8ntcq+z6TRT8g*8MwApKp!1bl2TqcdtRBISj80NOlC&Z~rBkOKnS&7hfCpqVErqQW
zB<@UO5<K1`SlQ;9CoftDYKxL2Tjyb4%Ut0qzpgD0Ky(D7AbjGE|Ljb)XeF!0uj?<9
zqZ#epfeYu3%A*^s?C%l>0?{0JINtd`?CpH<(<=LZKfQ3$8vU&r&*yaR=+0jh=r`%T
z+&&)eXIh{iFo_K&Yo)DREl+<D!@lcxpN}lQOnE&Bscla*&BR~THt}{7>^R#yjiYO=
zh6g&h7IE+inXk;#gxqmL{W>X$r&}s_){m~<`7lT1NiW9wSL@zP+O9iO7%%f*74|X`
z`ved#F>(bS6U}ii4tDUCnF`P67hmb}5_6d7P)&*nftRT3s2+gABrhZ(7LO_7C*h9=
zw7fOXPPYnZvn3?G_zDd4{L^vO&mhAO8|ecs@mqMj=tF6l<pT6=E-vE*&nNr!V}>Yn
z??KZLwqdzqygjP0;k$8;nZ=qVQgf@BvUSPPwvi~6uNM(zQLg^*2xv&16&TX;P<&yz
zHqqoOuzmK4^Rq8E86T0{H`+&#x^KP+Xjox{tL1)7USYj$!4<}od9`sG@?kjb%B}l3
z+cfAfFp|Rgy6zQF9s!>RITi~{L1|jWwj)*jRenvlZ$RQci?7l>&u(yTI5|I&@}@%*
zYP+aw#^HYsAuz5IJTDwh7eCz2oO2Tq7GU&9D?MFJzMOK@YRd`>7Vc8uky2iWn2Ytl
zA3TbDbegsKp1*X+dxnZSztN6M!GHz}B$}2LG71gLV7bQ|SaqMje?`P9OETK-t%s6E
zh)k}BotufVvswhqI%hTtb1>5ec_wqQ2f>b?<#fuu4>f`Ir=VpB+IAERF<mx65ATBt
z{o-3;v)W^5cEjZl6~L=d%8@rtl4Y7oMy?6mC=zYA3*UQwWPIgv1}|T})BQa23(O(T
zzP?Fh{L{qSW#EJdE95dEpn7n>kK{$#otfVx;dyRQmt>T~T^oCAc^Po3bQju^zooQ)
z>vq~+mhM=<cS(atv`ng2{~EA>8GAJW*q-rEGR?fK9pVKYz8;)UZ*3e(ODfkscQv0{
z?ro*I-5757j)S$Kr{Ez9j7QK|7TXTEvYK@Ae>Ji52u<IeP<bTu)*jG#9zE_}AVqdD
zVW8Uvw#ebz9JiJ>d4T3COS)%N5tlOhr92=1Tr)n%`Brc1!xLB`t+W#!`+Y^02s>ES
z*8TzF;l6);b+;MBz??qZ26i?KW8)OO+h_VJN6BqI8DCcZM&kI{t0GdU`taYC%tapR
zc@2I)<znM*FqC)_a^Oa$o_zX?@1rN^N4|>s*3Tvh_;@=Lug|XdM|O7D(XWL+rqVqh
zs}Su!P(DkZO`rViFmDffIpWTi?yz01Z9W>RW7(RBIE~F5@VRy{d)F}B(pW0yajkU`
zwimQns-KJ^0=|YADTB~7&s@bd?r<NhbtYF74<7nCF0@n{xnBs0=6JKE%P1cPIdCRT
z`<i4b%F-~~lce+cR=I|PmX>oN0rZFVK979>AE-f^)1T{+M6Jily~y5ALNy4~$y&%S
zbk2E;$hWh&i$IbWbl1cd?NlMtm3QccFN{J^2$5O7W2y$ZL(^)1Y9kwUpxy6B%mcJD
znhtWA-UJIk`N((7H7hM%^=nzrbk0y++w)-foh!izmd+Mq9<f==Vg`nv&2ex1QV>=A
z3<co7j5Vm+UibLu&T0}ejQ@<+Wp-dWpsB>P0$m5SZMyhz!xD0(4T2#Jf|LyiM=f`j
zCk%bq5@Dei?{C^N(=VcZuB;%4(cGne1y8w8_SG1RcA5G$SGum7LyM?OUeKkc96Ke9
z3L|c41z1=U^xLyd)d4}JxAcsEVBGr8QqKsgJs>KT%4&9z*?z&4ByER(f(LxlNC1l)
zh9F(l<ehfhgxJRdFsTrOIP8)sK8K%Fdy>qkZg!*H(WB;sGSk?e8BEy)obYcoALMKk
z^mxCSm&mpGB05@qnJ-?1IBv_8tfk>A`~KC{gv~~IiSFp`u8f5S#l3x-7WB>6qLN+L
zr6iQX>Z_Qf>vj<(xfRLl@p5BhKfaSVe1m{>6I=*c*OEEjaDL+sl(ybXS*=Ou#^cdI
zDrj1}SyTIS-SA|hhqkYlkcTkY`&J+KiMh#+)FKGmFV;JqguU&FsfVy^H{EuHOs8Dm
z^N(~(rze9B#rgUirJ8RlY4xdyA=YPO-DRb4B$c1~ST{ZfaW~cdUz7aL13%t1(FFs=
zk421vi#!xi4#>qn1lfDm)UYeYM?4_8nNcZ)bU9DuNiRV$Ir?@nKCl{nrZTH~&<3zu
zxogZBzEF}H@-f#Jl)9ZdD<=5eI^NZ@T#*zt_2KuP`4B<=o^hSreS+`~!HlD>&eM77
z;mH@z!sI6kMN5d>4e$Lo@wQ#7wUzuN8v>uBt?h})2MA)waulRxo0$Ztf3-h*X>g!k
zD~exod>FaOWMXhTa!8U8ILWr%6>UWG=nI!JG@v-HS;VlvAM+G-PcQZRxOsGgO`_Ij
zLRO3l_!^=}rJcoLg7TA79whGfklXvb0XZX#L6y(L<RHR*PcIb9tEvjJ>Ek|g@0U~Y
zckZ^8%P!QEi@A_e?GuLj-Di5hQW?4)(qkvTapSb<_F-4MnI(d?Tc=|Rzt|>%Xy<6Q
zGt~p>uLeEEzyLdI9B1w^D~-a#1aWm-woT-eChLB2unP9YB+tWLU9Ugw$!2#89<M*#
z<SGpD74o~qTGwo1%dd>An7>#H+4<*SzYSh(;N}mW?EZ6_)7yFvPC9noCX=n4K8g=>
zQ*!C>3F)KjaSKQTF^BAPW;Bs6foD*w2Q!j;{MXDFGz?sHKn-*D``vo~M5j6#k4W@I
z(WcZf7fMRj;w7WXqeaPs+cvrL+Cd!2ino`adSr_M($J@IV}G}<0#J}dy^h;^oQuQ9
zaYh;Ld4Brr{5hFH!D~P|9yK3Bl}WzB@?^o`!C_HKGPj8T_ECGNSBQG9j((k(YSn{Q
zxMVqHTk8FhrN3NnrDyvH|6NtxqXW=YDY&DAcr9UZV{}~bS@oy}K9-DPQ(C0pze{R!
zUr^fIRa5@r@#0sQm87^E%Wha!@wLausC<>DO$!Dd3U;G@2bE6a^>vml@0w-RTJCu<
zcVMfP9UL_pnL>n5>*{=P%WyoYd>P~g+RLhyB@YAbe#ydFu4(ftmeco(HLap%r%~&2
zkLXW(rr7|42A0{6weAJ4k9LvItqMt=hDn$O+RkDsu6}J+S;NP!8LAEGIJ?AeG!-WG
z>mlg<4E0&cM4<48J_j#LksAMwvmBLh8?}r^@@b3k#`Vd>9&%^}r4Pp@9ZO%IxZvbR
z`%jM~@u_@;Wgzc7^k?o&aMJV@#fg8V(mCHbU;m^|LyO~E*k8R&eqXHS5OdKg%?yjW
zX8sc;%e$r`GLq;r#UL%WpwQN+`V=3*g1Cv-Y&RRMjRJ*5d*Hspj7a6-y0_ZLZtTV_
z(ib5Pa#xVq%U1;vNl|Mi%%vr2{X<Okm)~jwJmAyB3mwht(at@k;8Iu|QfXw9y%M`x
zW)Tste}pFiL9V=;Uklr&38lG;f~I2q%ZFCRy@$CFU`tHACl3KvTIZ`-ft}Ad^SW8}
z*QjC0&tino{35_^hIRN>eyB<GtTTM_1lshJ{%9yWz~{&nhC$eYwzj@ZSIt_-SIoxS
zCwoK_@&xb*4cIh7SG_q^>D8%_YGA&qZ8FV3+ur3M&I(!{%|IU8A(;ce7v|_*i?*f3
z81~Q)LBVjjtC!V^mPfOLk)rG8Wfu-7MUHF*^LcdE5|8^6w#dAadXu=Ms_l6G{_B}e
zeQcs_vlpBrGyUQc)oKnbn*&}x+Ww9sNg$ZS<C~q13Wq7(8)m83KYnbFXX(_3ouiJc
zl#79n!A+Tq*z*O*xVEjz9OT%7APrKd$5mFmW(oV14F<YNwWZz3hHt;SE?_sal7gxG
zw~v!QA6wBRqsh_nk0fn2?ouV5oxO)A<>ROS;yN;#mj;Di+Xl6NH*g4eV6=O{jpoVa
z`)KdbKRr-Bn)4}VNR!Fq;MtZj2R$Q$-O;^Yu6>=`m9y~a)$m!7Y42|`p0*)LqGTJM
zmFys1!x<jka`GJJ{kZ^->(iVM2e*<Mix@&xaKP*V7Bi_6AtsTPKV3Buk0Xo}=XoZ2
z>?f^RtRU$85FLJp`Y}4^@n`%BRR7SVj4)IoBx6wTWS{wHzAtwJB#i3AgG$T1{fF3k
zkK6O~)uzVb@HhGb1<oN7{;(9Jr%(I2>mOz8st4ji=BJrZ&?E6092s@mw$@`TD#!HB
zCzh=o%f6UpIddg+YdD!Ps65(GD#Sn8Itn;Xj}rPZ+ve~?5z$th6L9fZH7@{`ZM<&t
z9DKAaojvu=3DMj1(5r1Ik;bp^0CcQY=^JPioAK)cnLGj|J+j_3fW}&nR36u+pvG*_
zf~BgP@B<>=&KAJCn4_U&gQ8(kzoi@SeR+f&uYKp~d4yjYq!F0LlFGOD8D+1zucurY
zTB!N$n&B=r>rad#GY5Vt%|(G}XC2*Ta`ocHVvN&PO?O6-boAxk{z0<51(3xkIm@={
zuDg~cX;4`xCauJ||6aZKCfPT^SmhkASa?78=(E*l4%I7PFOTku@7zE9DJx}7Rs1cz
zT0`?3#FoKyJdRr~ZP(XuT3VQ#Y%A5&Ta+g-&u@RJ7I<*R-=d|K))#o8Y?@kgNH1yH
zZBZHPVC-NUlZ(Lds0K=BR9Omc&n_2iP@$$Sy3dp7bWuBpaoM6W0jn9r9YaY+Wh)j3
z8);L5rp$u3Mu}xII2}Xc%#i3XD}nuE<OmciD3&qF`3wzui)_QEWzWky+e&x_rr^Xy
zcZ71VNYs%L4|8-k?6m$uu5wCgY-Rd6a0|Ut!OtO;=U`9hz;O8}i&#;xT-f8#Gn?m%
zO?<I!et&2=thu>^^Wl8db8Y$AQH`3s>-La38=jIrA7plg({pC7=z`6!@=jNkK-|-L
z(Fr~_mda*wdyp<o=P%j3?EiK6r-A2e(YB#Zt%HF==oDQoFuiKyq!nl8^AXEj1`!9I
zGv1%3CQ^b09~<Lsx|T_<Q`qHix9x;fs)X_TT=R4^<(=w|#a_v_G|*W6Rs++m7A5x#
zF-7u{bN_x1rw+@Ht9l_&?3ux0MW6Q;Yqt_}8`qEoho&~aeC(D{8tJ>rfN9T!a9l6G
zgnrWs=RZ;Euk;j^fm>T))Zv_Zvvyhe5^lsLovtX#V6BSqIJ6f-DcmF(nL)$md9=k<
zGjAh4;IY@%3}d(8hbbFXtrU(*h4G&{&AFR2A+ayRjm6=gykA$B;iPi8^+%zx+834%
z=_JP+Zv#tPgTkm8`S(dX8ja^$-IP3%dt4SqQrBIy97gjuayc97eilRbFF{)cN=~oI
zPrL(-<#<-q6PnQ%t>6Kvz)>0!(~63T_o}*0(jyt+k?R@Bjv<FX9Y()GrDufM_ymPd
zx8^=+lE3(RZD+e76B~|0F0xZCdR-IBC<n%N2ggoiY}muz;RHM{EY41f_j^suUNgNt
zhGIvUChZ`e%fpFMjr1Z4hKhq{JZPAIPIui?nUg5aadYL%OYtJATfbmireX_y{ikWR
zlU6Y@zp!Un^3?0FDQWGY7M&fwbXSUN!i6_%czn}D1r2jCVAJt1$PBM_mRHV#H?ay`
z<Ml*F(NOZ*o`-esw={%j!R5{}d9)KGpstY+u3WT7ui8^}2^KudX-!mlVXf0S<f1?~
zzELjiUwsLmShMVxFt9maC}e~$U6pclH?#CYRIF9k*gYi~&hkVhQJp(FiAd~NH)|$m
z$WC{oG2SL)lPzF9B}h*b4?R#l>;7O>IFoiGxX`*J3$Sd9vx+_QF~*`^p-%)9^a+d*
z3N}=QLQ-Fpoo^9luSKl3`nxS%4<9Yg(T1Dw?@k6MqzXtp!Cqz4!g2WSxFvZMUfa5?
zm(PVwHB9F@@qM>jZaPG?WayjcUQDxUnd7Q-ilFc>@y%IpwOKb>=DY468}f&a(MksH
zj~jgjUr|n#ojqpa@ip=5o>nHE2iIKWqkDp>LCHm1|EahqM7q6uK-PM-GN}KMmwqJa
z*k|5QABv%s?AoW9Cu%)B6RKX&oC3hv3Qhb~kM&zzZ_U-`L7%a9K_z^n3TZNas8@9C
zGq=S|r8_0n<_v`gJZ^Dk-a_n0LPz%58n)AMVm8q>7cDX`4134kP*wDPN?@)md4%sE
zx0%Q3_6viZf`KQfq4lr9{f$De1s*pMB=T7tm%l05@{~Q8Op|jEJg(Tj`WAvQbSpLh
z=akHU>pBMz*n6BcRdj_gS)bhuIK;nsFs>~a!B9ezn9~sTwdM%v-Se^OAzN7C?j@c{
zE5wmgne`i8v^psuC0%y&S`G{IRdAXas-ozM8@Hq4RBdPsg-}glL6_AvK%bPuPw$&t
zF5jRN&@ME4yTK8Dcb9(kDGsxYj6R&oKE54f#=COqS6FcMwvWY>Hfg56w&s1U?oP|>
zf5(+{Yky$ohYTiq4~vPysP8BDZDbawHkjdKe?rSKZ2gMbTD_0cDU~IJ_f~a24mAO*
zd2}wOCwBz=I;Gc{5WoCIJ~}Nx)ZVYhYpNvXrEme8?EBQarYP7){Gn>uQwAhPA4a@C
z@4SqBitQ3JhEiWDTRj^1dL@+Ku1oN_$Z*s7IECmzwBZ_sfkm6b1AK}@`-31=l^)qA
zNQ%Yi>-<hFA@BZ7Wvb{5Nlq$l?b?F9Kt%FE=JD@N8f$HBZTFiXTeQddN)EQlwXHU`
zVJp9e?IMMB6OXQYh3WZ5Kkal_i`**%Ep6?uMX-aGcVr7>viDeqEJ2X9A$@nRlO75~
zsN-(V&q#9iar;_*PPf$6&pl){>X%004J8?$KzGX8?9<IG->@1JN~Zf-j9!(tzMIiu
z(p32q$G!kxm}(O?k>Y&IHnlhHsKt5~i9q*<RowEIngj@fKMb0q=%Mb9ICrgKPZhjb
zxJNnPYywiA+}HNBycu&N9oS7NOD-nR#gf!^>L1G{+BygkkxA-C?Gzs}E>%W5m#NX{
z=rxzuK%*<2f{%o2T3E9z3EnwJJWx6r8JSbXh30?Tg~$6DufkV!7h$>xFY9>`yF1A`
z)nk2}gt^iS!{rhl+v$8+e+hT<BY}o`w6Q$VdcF9EfW6Ii5BQ0Ff3Bqt=UdVIZYAmz
zVmD9eRY3>gXJShQ^)meZX_@>NOacDZ9dmTWrDBgJdx0k6zcZ*@XRM_BqQP<E+qkYS
zI0XN|=yUJs7ms|3=EC3&nbS(8vyfPl0RkEc(_(MI{S;zg8{x`IY+~~BTRM^aiXO81
zgcvo>I~IEa)h(zS!pduwZd-|kg&fdj!Uc=J)Zi>hk6POzfxYK&T1}JlT(0R}G4<@`
z&6Z5Ams5}RTrxDr9X`KxJB&?~5A<L}$ZnHD>ycd#|LhJ~8oD3Mbv9{iM%A-H@<S8s
zkE@#UpC7AlZyQQl6`3?OW>svb%XU$8>-f0tF}nBv>0$pOAnZ2qW+A69oFqe&^KHhv
zmMZR+cx_5<-CCcAq5jKTx3$>B`7~|<L|4iwNt9vvenP{r+Ltw_$%6fMF8ci;;$__A
znu((igBQdSu->fz{sx;oxHbG;jK6X3{kq<p_?4hqxho@)tTZt-rUf`@PgwihuG8T!
zGA5P4;TFR5fXAEq`ugKqhqLor#(?~8F(BaVTxBq=Q*Rcy!J=zp!))dv$mdnFEkZ2-
zGZHj*ZE#9*EK6>@v*mg7MSv_pfQ)})$YLt5)?udq3wCff*ps9InN6C|Y6-l(t$ZWA
zjq~)E3(QojK!_T?>-1_3qEFg=rBP4N&~zCZdGwKpa9L4$OBoGoXJ7D3<k9AVlrQJg
zLlRu@^V%fhD3^YL|LOn28ib`aAy}>C%TeyN33l*5J^vx-7pni8Z>xF28UGQ%*_!ag
zpohg;@*DedR&P5z-HzE4bZxSQJ^Eyt@bEd1cv<mo{V!WE`d>3*0NAI$8tLK6D*rS3
zzY<x>p4kFVn-uqA>04jU$S332R}5>AUnD0jq@V7bmtM9e)X_cBPn%iRhkpm^JYyU4
zuUb;xe>wE63IChGyn6HBmoTmS$d7Y~$fKvguzV5N)KjKd9@xK0da@$p@^n`NGT%RT
z<dVCu#vkjS*quX+|0u&G2ozXk`RmWiye2lHrzn2+o-qFM*NMSoY<jQI<rm-t&Dq-O
z_1@@ZH(-fQY0?5gCko+&a&xqZU6v73u=BF*1kEaL3epNuWiHvLJFR4D50nL2SPf<1
zZI<#=w_VIoInR~oyD8>s<t4Bg5{@lUwV}WaUAZjGMr&Rbn>nKo{^OZjS+;e>EDe8<
z#Z@G#KGUGO&S7Jrnvug^o~)VF6=9z2GmFtWscjV2cv~eVH8JNx9NGqAd5eY!0a9Rv
zY;=JxH;t^aydgfYcHi2{+V`2;%Pk>r?N}^Q#al~}&jN%%yk6SDeB@wfL5G+u=7v{)
zZdEd=-_TrR4F?l|L)^auHdnFUhb*u1TuWhK*5)qbV60GC1>%2@mi=?fAA?hY#Sw&L
z)IqT)jiLvjaJ1V(ULgoU5<(JP<w@+IpprtFUu;BG2_XP~{_0GY_Q{}Uq9O7(r&4&^
zXzMTdX;1jJrF(WjA*ELC+chYGf9e^0Eauh1B3>#i&ey72Nz8thxEJiS*#I`zaHOu4
zML;~p-_CqLoYpj+zZ&@65JNySm7n7f67n;RYVt+F9iQ{iU?Snw+k~Hz!?$;?DTQ{7
z#v`g*lx5U+HxGpvh+G-7z4q{~=I5<Ha}#c~r3epMogxW>+{t5b6<4sI(PR66rlY6A
zCBzxnrw$vI!7W%pk`p3mlYR-1yT($HL5~HHyp@fe7{BVU5W*vO4pJn<e@+eepoy0$
zS>J%?3EP_W9HMl2)_5R%^%p-X)_i0&UJxk1Vr%oG6H^uhy6u0#<9r}%v|5-qgT8)r
zA9)mfA#yu>Q@K@@-s(bg{3x0p+~-r2%k3WEZPl>5&Ys4LxGi4iY+-uzTs_Lw&n=Ox
zy6T||&RU*L;W;e7!bjyy652ZO?40q`D^!|$44DZOTuO`N?ns(dKto+UOcmS|wyR1P
zC-d7wwUV;51vspT83mq>Qs8$=e#f_Izr8UgFpyCIXsn374-{9!SffV^^jE{zsz=tD
z2}G(ugCcX0`br_8++&erhMHuA;2jg}fBL-QP@IfpF9qr4st^(aanw4xwizt_BFJqP
zxWGt~tiE4|`eU=+f*{uVr%xpWZGUS4K13(qTQqT$(;eeG0p7B0>iV5)eG!#vuP8f`
zko43Vq%6-+TM2bC=loH|P1i#VvN!YIm6`1%Gn5lN0<mw}YV_T(Ejj5J6l+*0DUI0i
zBFabd>4v;`-lM=nZrd(51oH{#3h&i$)FeF&kfiI2XOdGi&s!7?Y%zQakhhV%NRg#O
z0|3eSm}*3ip#k)GZ=i);+5j<W6mmTbG6n#vRN}!sRZ~?7yQod_w^yB<fE;AAplT0T
zPLPvY*7cp>%aRD?#6R^OE)xN|^5+vbln7+foja}x<8ugpsy)d9pnyn+q5G1J*FB_J
ziFLcosGJOSC8;LhD#{b;q}rUM_1kgGRG}?}NJFGJwuoOgId0luWG<&_89UCOy{jZw
zpxEd`=tSiV8%4&`n@HfGId)R>K&&zSp}O2s&#n?pABO?<np^+KkgOlapu^)!5Dv8V
z`17c6x{M|e(JdQnnLTmvGp_zsCn{>}9~0fSSTnu?$9vm{A1tC(A@**6a&wfVPseQF
zttKen&4;77wxg-U&%9={%LATi^h{`v^n^~79W4Khn_U(c74V#4l?ptd@k~X|NoGeY
z45SzP4$C2Rtc1UL8-k6OiMO+gF<<tIExM!28L6zZjS#OXgYtUA9a?gfArkm7NZ%VB
z;Q*4)HugnUGYVd!HmK|)(Fe66*FNy8tl74w#PfNc{mP8##Xa1z6gLm{ak4QlG8b1R
zVx`CQ3>DA^CY~CqX~YIQG1eE_=!^qR_YyD&>d`4^qG><d6Jlp(RAcFjT+a^uu>g*l
z3Ok4K&Eie9KOZE-Lr9Ixw_p^Nq&I<T1>y)eo-NdoMS$|;ie}WrQbC6GPOi$(ojo6u
zp?w`$@W%2yv-%_S?+O6-)<h}<_;9uR2;oyu*ZC*WQ$Ge0XUxVId<b?wc!gOaxz>Qn
zcgzJ2!mprOGZXNVrh0Zb=%ImkPA7bsY#t&L%S3lDskOeEMoQCSd6pSZGUJti@BDLY
zexO#Xl!=jC8DuaIC`pFysJX_mzQV05eVXF!T9$#1ahIcyTbVD&EsTFn!xmqNGzH36
zwoK0I#NM`}zYo;2#kN_=VgJe|hRgjO^Y!s3>`|D<Y5yoSzI0ORtr+UkF@e!1Qs=N!
zwJGRzT((nBWGn40>75{Y9dpe2#kgmyQ8u01pQ#jA@d^{ENb_iKw2dEnF1@uRRHhES
zQ7JsDh~J#y`%uI6bx7`F4#&vv`#N!+BMrWf&Ihpvx#7VMOf}MiWr6ey${S5gE7sI+
z$lkelNlg16@k0-0E<0_j>|!1o>w7L$zU|L?fQoN?H`C)JM%Y(`t2QLOpT6D4!dAXx
zq3{j5Zw-)t`^8;|YKJvt9iPJJBI3wB+8z26>LLVMt;eFna|fsJy3NVpB#7~tK%Lv)
zLj0f!TRtf6?x^-oYDgyxgok**{xnW?TSQ(83|!8uE~bIHieD1+xAw>VOF#@gCV`R?
z6K1gUQ7_p31?7NRImKoH{S&gN`@;Jp|1Nf)#%)c8=o@zMal75q7KhF3EpD&TY*c-$
zD54ObMNNjf>i^3039*z;ygO~tQn%!$l~I0Yh-FM8Ps3*s)lM9(*wuV0BFT!`8IrFY
zk+pFl750I_kF)&o2|yAo&$+kr3u{wQrEnb|eCv3iu#srbd;NHK6Jt6ORqr#@=6-hG
zD7)nRrhivmnvizZTeI>h`?)>^yqxqc%}T&2ew4VJ8fEfCA1<DJ<X>qIzA}gwqZV^@
zh`hY8aT3$oit9b#{nvP~eHbueV`GG&g+xPpswA)IHzvR3R|Y@rrl7@TUubqwQIWkp
z#on3oG8PNe>Z{2$K*;CZ7U{3!8P3I9%1&6KP?epl-rMT|tj$648O1{GUH$<;U&09J
z+lQ1hJGbJ>pQ5<%DU0^2UkxdAPjTs3)j43ec3jCAUcLAh9gThaAXTf}^x@(lA<+rh
zf*AL8Tt(Gfo2V8e*SyR4&69stExUPKxvzZ*{e2fYceB$ks{OYq^5uYPNas&kdl5wq
zu#Sb>+D!=}^{;xQRKdSFdPz;`wtPjtMy6lJRFGclG`4?|*rf;^=Jj2YaaPv}RVWB$
z>Q9^hVE@kj)5H=_ERwcLI3eNP0+YCPTKH63#Eud&Rrf#i-@D7PpVRSvoL(qBSw%3q
z+ua|9*!U(toVgB1KSg2Xd#@Jr)siCIsz?pON%5G#?RcD^j94uFo2i4O8^GK!W)38p
zJz2jOoNjC*(vlx8x>!!+;S%FMQt-Ku-*n>F-g>ne&uRaLX6m(kXmD2JNm>=5UAL+%
zBSn^yQN^fqy7wPUB01tWlb#)l<{?4fe41mCX`bYRre8}FeiHo$K>kyf_D^H`^za7%
zZJq$(|7yPcMa2I!e+$_DujKy~|9?pSU-ADa{vXNzkK+GG{xg_=gh*2n7>!2nw2P{T
Sai41c01EF^-j>Oj1^*Ya5udgI

literal 0
HcmV?d00001

diff --git a/doc/devblog/day_587__import_preferred_content.mdwn b/doc/devblog/day_587__import_preferred_content.mdwn
new file mode 100644
index 0000000000..a1f779b056
--- /dev/null
+++ b/doc/devblog/day_587__import_preferred_content.mdwn
@@ -0,0 +1,20 @@
+I've developed a plan for how to handle [[todo/export_preferred_content]].
+And today I'm working on making `git annex import --from remote` honor
+the preferred content of the remote. It doesn't make sense to support it
+for one and not the other, so this is on the `preferred` git branch for now.
+
+One use case for this is to configure an import to exclude certain file
+extensions or directories. Such unwanted content will be left as-is 
+in the remote's data store, but won't be imported, so from git-annex's
+POV, it won't be present on the remote.
+
+The tricky thing is, when importing, the key is not known until the file
+is downloaded, but you don't want git-annex downloading content that is not
+preferred. I'm finessing that problem by checking the subset of preferred
+content expressions that are not dependent on the file's content, which will
+avoid downloads of unwanted content in probably most cases.
+
+What should it do when the preferred content expression is dependent on
+the file's content? I'm undecided if it's better to warn and not import,
+or to download the content once in order to check the preferred content
+expression, and then throw unwanted content away.
diff --git a/doc/devblog/day_588__export_preferred_content.mdwn b/doc/devblog/day_588__export_preferred_content.mdwn
new file mode 100644
index 0000000000..fd2cf1d6c2
--- /dev/null
+++ b/doc/devblog/day_588__export_preferred_content.mdwn
@@ -0,0 +1,8 @@
+Made `git annex export --to remote` honor the preferred content of the
+remote. In a nice bit of code reuse, `adjustTree` was just what I needed to
+filter unwanted content out of the exported tree.
+
+Then a hard problem: When a tree is exported with some non-preferred
+content filtered out, importing from the remote generates a tree that is
+lacking those files, but merging that tree would delete the files
+from the working tree. Solving that took the rest of the day.
diff --git a/doc/devblog/day_589__wrapping_up_import_export_preferred_content.mdwn b/doc/devblog/day_589__wrapping_up_import_export_preferred_content.mdwn
new file mode 100644
index 0000000000..e9df5c70ce
--- /dev/null
+++ b/doc/devblog/day_589__wrapping_up_import_export_preferred_content.mdwn
@@ -0,0 +1,7 @@
+Kind of surprised it all came together so well today, especially because I
+noticed another big problem with the design, but I was able to work around
+that and import/export with preferred content works great.
+
+I did end up limiting import to supported a subset of preferred
+content expressions. Downloading content that it doesn't yet know if it
+wants to import seemed too surprising and potentially very expensive.
diff --git a/doc/devblog/day_58__urgle.mdwn b/doc/devblog/day_58__urgle.mdwn
new file mode 100644
index 0000000000..f6d930d806
--- /dev/null
+++ b/doc/devblog/day_58__urgle.mdwn
@@ -0,0 +1,16 @@
+Fixed two difficult bugs with direct mode. One happened (sometimes) when a
+file was deleted and replaced with a directory by the same name and then
+those changes were merged into a direct mode repository.
+
+The other problem was that direct mode did not prevent writes to
+.git/annex/objects the way that indirect mode does, so when a file in the
+repository was not currently present, writing to the dangling symlink would
+follow it and write into the object directory.
+
+Hmm, I was going to say that it's a pity that direct mode still has so many
+bugs being found and fixed, but the last real bug fix to direct mode was
+made last May! Instead, I probably have to thank Tim for being a very
+thorough tester.
+
+Finished switching the test suite to use the tasty framework, and prepared
+tasty packages for Debian.
diff --git a/doc/devblog/day_58__urgle/comment_1_bd279f58f614b103a53215dfb0211007._comment b/doc/devblog/day_58__urgle/comment_1_bd279f58f614b103a53215dfb0211007._comment
new file mode 100644
index 0000000000..0fec5fa8c9
--- /dev/null
+++ b/doc/devblog/day_58__urgle/comment_1_bd279f58f614b103a53215dfb0211007._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkx5V3MTbzCXS3J7Mn9FEq8M9bPPYMkAHY"
+ nickname="Pedro"
+ subject="Is direct mode still using symlinks then?"
+ date="2013-11-16T16:28:39Z"
+ content="""
+Is direct mode still using symlinks? I see the bug I opened is still unclosed:
+
+http://git-annex.branchable.com/bugs/Direct_mode_repositories_still_use_symlinks_sometimes/
+
+Any opinion on this? This is still my main problem with replacing dropbox with git-annex.
+"""]]
diff --git a/doc/devblog/day_590__toward_importing_from_externals.mdwn b/doc/devblog/day_590__toward_importing_from_externals.mdwn
new file mode 100644
index 0000000000..bd1de81d24
--- /dev/null
+++ b/doc/devblog/day_590__toward_importing_from_externals.mdwn
@@ -0,0 +1,11 @@
+I've added an
+[[design/external_special_remote_protocol/export_and_import_appendix]]
+to the [[design/external_special_remote_protocol]] which documents how
+the protocol might be extended to allow for importing from external special
+remotes.
+
+Feel this needs more thought. It's complicated by there already
+being an interface that only supports export, and import needing all
+the same operations, but with more checks that the content has not been
+modified behind git-annex's back. Unifying them at the protocol level would
+be possible, but perhaps more confusing.
diff --git a/doc/devblog/day_591__superscalar_pipelining.mdwn b/doc/devblog/day_591__superscalar_pipelining.mdwn
new file mode 100644
index 0000000000..f6bcc7f9db
--- /dev/null
+++ b/doc/devblog/day_591__superscalar_pipelining.mdwn
@@ -0,0 +1,17 @@
+A long day spent making CommandCleanup actions run in a separate job pool 
+than CommandPerform actions. I don't think this will speed anything up much
+yet, but it's useful groundwork. Now expensive things that are not
+the main action of a command can be moved into CommandCleanup and won't
+delay git-annex moving on to the next file. The main thing I want to move
+is checksum verification after a transfer. But there are probably other
+things I have not thought of.
+
+CommandCleanup was always not well distinguised from CommandPerform,
+and so there was little incentive to put things in it. Now that's changed.
+
+I also noticed that with -J, git-annex takes significantly longer than
+without to get started, when the first file it needs to process is quite a
+way down the ls-tree. This must be concurrency overhead. But, when
+CommandStart is skipping over a file that it doesn't need to process,
+there is no need to do that bookkeeping. Planning to take some time
+tomorrow to see if I can refactor CommandStart to avoid that overhead.
diff --git a/doc/devblog/day_592__refactoring_start_messages.mdwn b/doc/devblog/day_592__refactoring_start_messages.mdwn
new file mode 100644
index 0000000000..c654326e8b
--- /dev/null
+++ b/doc/devblog/day_592__refactoring_start_messages.mdwn
@@ -0,0 +1,4 @@
+I have a 2500 line patch on the `starting` branch that refactors how start
+messages get displayed. Prerequisite for faster parallel starts. This
+touched every single command, and quite a few needed non-trivial changes, 
+so it took all day to get it to even compile.
diff --git a/doc/devblog/day_593__partial_success.mdwn b/doc/devblog/day_593__partial_success.mdwn
new file mode 100644
index 0000000000..9a0335b688
--- /dev/null
+++ b/doc/devblog/day_593__partial_success.mdwn
@@ -0,0 +1,12 @@
+Finished the refactoring that I had started on Thursday. This was only
+a partial success, because it didn't result in the speedup to -J that I had
+hoped for. The slow start with -J turns out to not be caused by concurrency
+overhead at all, but a bug,
+[[bugs/rsync_and_gcrypt_special_remotes_make_-J_slow]].
+
+What was successful is that I got rid of the oldest implementation wart in
+git-annex, the implicitMessages state. And, I made progress toward
+separately parallizing checksum verification.
+
+This refactoring is still cooking in the `starting` branch and will be
+merged after the next release.
diff --git a/doc/devblog/day_594__finally_background_checksum_verification.mdwn b/doc/devblog/day_594__finally_background_checksum_verification.mdwn
new file mode 100644
index 0000000000..6a8845545a
--- /dev/null
+++ b/doc/devblog/day_594__finally_background_checksum_verification.mdwn
@@ -0,0 +1,14 @@
+Finally got checksum verification running in a separate job pool from
+downloads, to better keep bandwidth saturated.
+
+I had to resort to what felt like a bit of a hack, but I can't see a better
+way to do it. Also, I got stuck for far too long on a STM deadlock bug.
+
+Interestingly, this means that -J1 now has a purpose, it's not the same as
+no -J option. Instead, it lets one download and also one concurrent
+checksum of the previous download run at the same time.
+
+It would be nice if -J1 could be the default.. One problem with that is
+that it needs a unicode locale to work due to a limitation of
+concurrent-output. Changing the concurrency method based on the locale does
+not seem like a good idea.
diff --git a/doc/devblog/day_594__finally_background_checksum_verification/comment_1_334c36d503abd06611a46cc102139446._comment b/doc/devblog/day_594__finally_background_checksum_verification/comment_1_334c36d503abd06611a46cc102139446._comment
new file mode 100644
index 0000000000..4770ea6aa1
--- /dev/null
+++ b/doc/devblog/day_594__finally_background_checksum_verification/comment_1_334c36d503abd06611a46cc102139446._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="thanks!"
+ date="2019-06-17T20:17:26Z"
+ content="""
+thanks so much for this work! it's something I had identified as an annoyance in the conversation around [[forum/does_git-annex_parallelize_different_remotes__63__]] and I'm really happy to see you're working on this! so yeah, thanks again! :)
+"""]]
diff --git a/doc/devblog/day_595__cleaner_worker_pool_stages.mdwn b/doc/devblog/day_595__cleaner_worker_pool_stages.mdwn
new file mode 100644
index 0000000000..46cc48ee68
--- /dev/null
+++ b/doc/devblog/day_595__cleaner_worker_pool_stages.mdwn
@@ -0,0 +1,23 @@
+I mentioned the other day about "a bit of a hack" that I couldn't find a
+way to avoid. After sleeping on it, I did find a much cleaner way.
+
+The problem involved classifying threads in a worker pool, so eg only a
+certian number of transfer threads and a certian number of checksum threads
+run at the same time.
+
+I had been relying on the stages used internally by git-annex commands to
+classify the threads. And that is a reasonable default for random git-annex
+commands that might do anything, but for a specific command like `git annex
+get` that is all about transferring and checksumming, it would be better to
+mark the segments of code that do transfers and checksums, and have a way to
+specify which what classifications matter for scheduling the actions of the
+command.
+
+As well as cleaning up the design, that also fixed one bug in the thread
+classification. And, it would now be easy to classify threads in other
+ways specific to particular commands.
+
+---
+
+Then I spent too long fixing a STM deadlock. Same one I spent too long
+"fixing" the other day, but I really understaood it and fixed it this time.
diff --git a/doc/devblog/day_596__back_from_summer_vacation.mdwn b/doc/devblog/day_596__back_from_summer_vacation.mdwn
new file mode 100644
index 0000000000..34ca740d45
--- /dev/null
+++ b/doc/devblog/day_596__back_from_summer_vacation.mdwn
@@ -0,0 +1,17 @@
+I've been back from summer vacation for a couple of days.
+My contract to work on git-annex has expired, at least for now,
+but I have a lot of Patreon rewards to catch up on anyway. I've been
+pushing hard for months on that contract and made a lot of progress on
+long-term goals. Plan for the next little while is to cut back a little
+bit, and work on easier stuff.
+
+Today I improved how git-annex uses Copy-On-Write when copying between
+two repositories on the same drive. It had relied on matching up device
+numbers, but it turns out that with eg BTRFS subvolumes, CoW is supported
+even when the device numbers don't match. Also, it was using cp even on
+filesystems that don't support CoW, which prevented resuming after an
+interruption. The new approach is to try to make a CoW copy once per remote,
+and if it fails, fall back to rsync.
+
+Today's work was sponsored by Trenton Cronholm
+<a href="https://patreon.com/joeyh">on Patreon</a>.
diff --git a/doc/devblog/day_597__git-lfs_support.mdwn b/doc/devblog/day_597__git-lfs_support.mdwn
new file mode 100644
index 0000000000..9b9b13f2dc
--- /dev/null
+++ b/doc/devblog/day_597__git-lfs_support.mdwn
@@ -0,0 +1,16 @@
+I've spent a week making git-annex be able to store files in a remote
+on a server using git-lfs.
+
+That included writing a haskell implementation of the git-lfs protocol.
+That could be split out of git-annex into a library if someone wants to use
+it for something else.
+
+Now [[git-lfs is now just another special remote|special_remotes/git-lfs]]
+as far as git-annex is concerned. Albeit one that it can't drop data from,
+because the git-lfs protocol does not have a way to delete an object.
+
+Once nice thing about git-annex's support for git-lfs is it can be used
+along with git-remote-gcrypt, and the result is a remote where both the
+annexed files and the git repo contents are both encrypted.
+
+See [[tips/storing_data_in_git-lfs]] for details.
diff --git a/doc/devblog/day_598__Windows_and_test_suite.mdwn b/doc/devblog/day_598__Windows_and_test_suite.mdwn
new file mode 100644
index 0000000000..198b31ca11
--- /dev/null
+++ b/doc/devblog/day_598__Windows_and_test_suite.mdwn
@@ -0,0 +1,21 @@
+Spent several days fixing test suite failures on Windows. This started out
+really annoying; I had to chase back a "NUL" -- the string not the
+pointer! -- to a indirect dependency that needed an update to work with
+recent ghc on Windows.
+
+Then yesterday I fixed most of the other test suite failures on Windows.
+But, it became clear that the test suite was only testing adjusted unlocked
+branches on Windows, and was finding non-Windows-specific problems
+involving them. So, today I added a fifth pass to the test suite, so it
+will always test adjusted unlocked branches. And fixed all the problems
+with them that test suite turned up.
+
+It turned out there was no good way to use `git-annex import`
+with an adjusted branch. Merging the imported branch into an adjusted
+branch is likely to result in spurious merge conflicts, and the merged
+files don't get adjusted. The solution was adding a new way to merge
+a single branch in the same way that git-annex sync handles merges: 
+`git-annex merge remote/master`
+
+Sadly, I think there are still a couple of test failures on Windows.
+(Can't win em all..)
diff --git a/doc/devblog/day_599__dropping_direct_mode.mdwn b/doc/devblog/day_599__dropping_direct_mode.mdwn
new file mode 100644
index 0000000000..bcb43d19bb
--- /dev/null
+++ b/doc/devblog/day_599__dropping_direct_mode.mdwn
@@ -0,0 +1,11 @@
+Wow, I did not plan to remove direct mode today! The original plan was to
+work on [[todo/sqlite_database_improvements]]. But that seems to need a v8
+repository format, to avoid confusing old git-annex with the new db schemas.
+And to get to v8, we must first get to v7..
+
+Removing direct mode eliminated over 1000 lines of code. I may be able to
+remove a few hundred more yet.
+
+Did find a bug with the upgrade process just as I was wrapping up for the
+day, it's minor (involving a deleted file in the work tree), so I'll deal
+with it tomorrow.
diff --git a/doc/devblog/day_59__release_day.mdwn b/doc/devblog/day_59__release_day.mdwn
new file mode 100644
index 0000000000..469ccec445
--- /dev/null
+++ b/doc/devblog/day_59__release_day.mdwn
@@ -0,0 +1,11 @@
+Release today, right on bi-weekly schedule. Rather startled
+at the size of the changelog for this one; along with the direct mode
+guard, it adds support for OS X Mavericks, Android 4.3/4.4, and fixes
+numerous bugs.
+
+Posted another question in the survey,
+<http://git-annex-survey.branchable.com/polls/2013/roadmap/>.
+
+Spun off git-repair as an independant package from git-annex. Of course,
+most of the source code is shared with git-annex. I need to do something
+with libraries eventually..
diff --git a/doc/devblog/day_5__gcrypt_special_remote_part_1.mdwn b/doc/devblog/day_5__gcrypt_special_remote_part_1.mdwn
new file mode 100644
index 0000000000..626b5edaf9
--- /dev/null
+++ b/doc/devblog/day_5__gcrypt_special_remote_part_1.mdwn
@@ -0,0 +1,7 @@
+About half way done with a gcrypt special remote. I can initremote it (the
+hard part to get working), and can send files to it. Can't yet get files
+back, or remove files, and only local repositories work so far, but this is
+enough to know it's going to be pretty nice!
+
+Did find one issue in gcrypt that I may need to develop a patch for:
+<https://github.com/blake2-ppc/git-remote-gcrypt/issues/3>
diff --git a/doc/devblog/day_600__close_to_v7_default.mdwn b/doc/devblog/day_600__close_to_v7_default.mdwn
new file mode 100644
index 0000000000..99136ea289
--- /dev/null
+++ b/doc/devblog/day_600__close_to_v7_default.mdwn
@@ -0,0 +1,5 @@
+Finished yesterday with elminating direct mode, removing another 200 lines of
+code. I'm close to a decision on
+[[updating repos to v7 by default|todo/v7_path_toward_default]]. Been 
+reviewing open bugs that could impact the decision, taking a final look
+at the code to make, and reaching out to people who might be affected.
diff --git a/doc/devblog/day_601__v7_default.mdwn b/doc/devblog/day_601__v7_default.mdwn
new file mode 100644
index 0000000000..51dc23175a
--- /dev/null
+++ b/doc/devblog/day_601__v7_default.mdwn
@@ -0,0 +1,17 @@
+With git-annex 7.20190912 released this fine Friday the 13th,
+I've finally made v7 the default!
+
+See [[upgrades]] for details about this major transitition if you have not
+been keeping up with v7 stuff.
+
+Based on some feedback that it would be good to have a way to avoid
+accidental upgrades of a repository in some circumstances, there's a new
+config option `git config annex.autoupgraderepository false` to prevent
+upgrades. Since the new git-annex doesn't support working in v5 repos,
+setting that will make every command except `git annex upgrade` fail.
+
+Users of rpm based linux distros can now install a 
+[[git-annex-standalone.rpm|install/rpm_standalone]] 
+package that will work on a broad range of systems. It's based on the
+standalone tarball, just packaged as a rpm similar to the
+git-annex-standalone.deb provided by NeuroDebian.
diff --git a/doc/devblog/day_601__v7_default/comment_1_54af3bf0a521597d49bd8f8ef0ab5555._comment b/doc/devblog/day_601__v7_default/comment_1_54af3bf0a521597d49bd8f8ef0ab5555._comment
new file mode 100644
index 0000000000..b715a75025
--- /dev/null
+++ b/doc/devblog/day_601__v7_default/comment_1_54af3bf0a521597d49bd8f8ef0ab5555._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ avatar="http://cdn.libravatar.org/avatar/7003e967f47003bae82966aa373de8ef"
+ subject="Direct mode"
+ date="2019-09-15T09:57:57Z"
+ content="""
+I've been trying to have something resembling direct mode using the recommended \"adjusted branch\" feature (with annex.thin), and the results aren't really satisfactory:
+
+- If I use `annex adjust --unlock --hide-missing`, the non-present files are of course missing entirely. No convenient way to `annex get` them on demand.
+
+- If I use just `annex adjust --unlock`, or even if I permanently `annex unlock` everything, the non-present files still appear *as regular files* (containing /annex/objects inside), which makes it much harder to distinguish whether the file is present or absent. (In v5 direct mode, absent files appeared as broken symlinks.) Additionally, the adjust command is very slow, unlocking maybe 2–3 files per second (they're video files, approx. ~300MB each).
+
+I don't mind regular (indirect) mode in general, but unfortunately some apps just... don't like symlinks, so I want to have plain unlocked files at least on this particular clone of this particular repo. So it would be great if there was an adjusted branch mode kinda like `--hide-missing` but which kept missing files as broken symlinks just like the regular mode does.
+
+But if that's not possible, I think I'll be able to use `bindfs --resolve-symlinks` to achieve a similar result...
+"""]]
diff --git a/doc/devblog/day_601__v7_default/comment_2_c2daec80c7834ebb62324d7169c6c158._comment b/doc/devblog/day_601__v7_default/comment_2_c2daec80c7834ebb62324d7169c6c158._comment
new file mode 100644
index 0000000000..9bc331b7b1
--- /dev/null
+++ b/doc/devblog/day_601__v7_default/comment_2_c2daec80c7834ebb62324d7169c6c158._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-16T15:58:22Z"
+ content="""
+The adjust command won't be slow if you set annex.thin as it won't need to
+copy the file content.
+
+There are a couple of ways that it might be possible to get symlinks for
+not-present unlocked files. I've opened
+[[todo/symlinks_for_not-present_unlocked_files]] discussing it.
+
+Improving behavior with --hide-missing is also possible
+[[todo/better_way_to_get_missing_files]], and I think much more likely to
+happen.
+"""]]
diff --git a/doc/devblog/day_602__sameas.mdwn b/doc/devblog/day_602__sameas.mdwn
new file mode 100644
index 0000000000..db63f0813a
--- /dev/null
+++ b/doc/devblog/day_602__sameas.mdwn
@@ -0,0 +1,9 @@
+Plenty of stuff going in that has not made the blog. Now I'm working on a
+sort of major feature.
+[[todo/support_multiple_special_remotes_with_same_uuid]] will fill in a odd
+little hole in git-annex's capabilities. I think it will turn out to be
+more useful than it appears. But it's major not so much in what it will
+allow, but in how many assumptions in the git-annex code base have to be
+worked around to implement it. After pondering lots of approaches, I have
+finally gotten stuck in to implementing it, and I've made some good
+progress today (on the `sameas` branch). I might finish it tomorrow.
diff --git a/doc/devblog/day_603__sameas_working.mdwn b/doc/devblog/day_603__sameas_working.mdwn
new file mode 100644
index 0000000000..23517d6cf6
--- /dev/null
+++ b/doc/devblog/day_603__sameas_working.mdwn
@@ -0,0 +1,4 @@
+Gotten the sameas remote feature fully working today, except for the small
+problem that sameas remotes should use different per-remote state from
+one-another. I know how to approach that, but it's another big change, for
+another day.
diff --git a/doc/devblog/day_604__unscheduled_release.mdwn b/doc/devblog/day_604__unscheduled_release.mdwn
new file mode 100644
index 0000000000..751846d83b
--- /dev/null
+++ b/doc/devblog/day_604__unscheduled_release.mdwn
@@ -0,0 +1,5 @@
+Dropped a release today, earlier than planned. There was a bug that broke
+the OSX git-annex.dmg, and another problem broke the Homebrew build, and
+it was worth moving up the release for those.
+
+Now I'm going on a mini vacation to recover from some stuff..
diff --git a/doc/devblog/day_605__well_Im_done_for_now.mdwn b/doc/devblog/day_605__well_Im_done_for_now.mdwn
new file mode 100644
index 0000000000..63f80b5cf0
--- /dev/null
+++ b/doc/devblog/day_605__well_Im_done_for_now.mdwn
@@ -0,0 +1,2 @@
+Not working on git-annex for a while, at least not under the direction of
+users on this website. Sorry.
diff --git a/doc/devblog/day_605__well_Im_done_for_now/comment_1_7366f7108495129680301d9b93bb8fb6._comment b/doc/devblog/day_605__well_Im_done_for_now/comment_1_7366f7108495129680301d9b93bb8fb6._comment
new file mode 100644
index 0000000000..6b5dffd18b
--- /dev/null
+++ b/doc/devblog/day_605__well_Im_done_for_now/comment_1_7366f7108495129680301d9b93bb8fb6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ghen1"
+ avatar="http://cdn.libravatar.org/avatar/efd0e92b6198291138f0cd7aedbf86b6"
+ subject="comment 1"
+ date="2019-10-23T21:03:11Z"
+ content="""
+Is this because of my forum post? I wasn't intending to sound antagonistic about the v7 upgrade. I just want to make sure I don't have any data loss is all. I'm fine with v7.
+"""]]
diff --git a/doc/devblog/day_605__well_Im_done_for_now/comment_2_cd42103ea06ede8352176e66fc5434c5._comment b/doc/devblog/day_605__well_Im_done_for_now/comment_2_cd42103ea06ede8352176e66fc5434c5._comment
new file mode 100644
index 0000000000..0cfcd4e5f5
--- /dev/null
+++ b/doc/devblog/day_605__well_Im_done_for_now/comment_2_cd42103ea06ede8352176e66fc5434c5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.andreparames.com/"
+ avatar="http://cdn.libravatar.org/avatar/4f61994f79eb82293826782d00c32e4802ab644ef5b60ee8d1c65c699d2dbef7"
+ subject="Thank you"
+ date="2019-10-24T23:56:42Z"
+ content="""
+Thanks for all your selfless work over the years. Git-annex is amazing and you are an inspiration to many of us who value Free Software. 
+"""]]
diff --git a/doc/devblog/day_605__well_Im_done_for_now/comment_3_774f264c555965461d621587cbdf8a1e._comment b/doc/devblog/day_605__well_Im_done_for_now/comment_3_774f264c555965461d621587cbdf8a1e._comment
new file mode 100644
index 0000000000..1132980a4e
--- /dev/null
+++ b/doc/devblog/day_605__well_Im_done_for_now/comment_3_774f264c555965461d621587cbdf8a1e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://tribut.de/"
+ nickname="Felix"
+ avatar="http://cdn.libravatar.org/avatar/d7508a030fd9902a76b02f7feff1327e80400a1317ee98e463c68ef4c9c40bb8"
+ subject="comment 3"
+ date="2019-10-25T12:41:54Z"
+ content="""
+So sorry you had to endure such harsh comments. Just know that there are many of us who use your software every day and are eternally grateful for the exemplary dedication that you show for your projects.
+"""]]
diff --git a/doc/devblog/day_606__on_recent_events.mdwn b/doc/devblog/day_606__on_recent_events.mdwn
new file mode 100644
index 0000000000..26e93b1be9
--- /dev/null
+++ b/doc/devblog/day_606__on_recent_events.mdwn
@@ -0,0 +1,5 @@
+I posted in my [main blog](https://joeyh.name/blog/entry/how_I_maybe_didnt_burn_out/).
+
+Planning to start on [[todo/sqlite_database_improvements]] tomorrow, since the
+recent changes have raised the urgency of that significantly. I'll be head
+down working on that, and not reading anything here.
diff --git a/doc/devblog/day_607__v8_is_done.mdwn b/doc/devblog/day_607__v8_is_done.mdwn
new file mode 100644
index 0000000000..eead30e0ce
--- /dev/null
+++ b/doc/devblog/day_607__v8_is_done.mdwn
@@ -0,0 +1,40 @@
+Spent the past two weeks on the [[todo/sqlite_database_improvements]]
+which will be git-annex v8.
+
+That cleaned up a significant amount of technical debt. I had made some bad
+choices about encoding sqlite data early on, and the persistent library
+turns out to make a dubious choice about how String is stored, that
+prevents some unicode surrigate code points from roundtripping sometimes.
+On top of those problems, there were some missing indexes. And then to
+resolve the `git add` mess, I had to write a raw SQL query that used LIKE,
+which was super ugly, slow, and not indexed.
+
+Really good to get all that resolved. And I have microbenchmarks that are
+good too; 10-25% speedup across the board for database operations.
+
+The tricky thing was that, due to the encoding problem, both filenames and
+keys stored in the old sqlite databases can't be trusted to be valid. This
+ruled out a database migration because it could leave a repo with bad old
+data in it. Instead, the old databases have to be thrown away, and the
+upgrade has to somehow build new databases that contain all the necessary
+data. Seems a tall order, but luckily git-annex is a distributed system and
+so the databases are used as a local fast cache for information that can be
+looked up more slowly from git. Well, mostly. Sometimes the databases are
+used for data that has not yet been committed to git, or that is local to a
+single repo.
+
+So I had to find solutions to a lot of hairly problems. In a couple cases,
+the solutions involve git-annex doing more work after the upgrade for a
+while, until it is able to fully regenerate the data that was stored in the
+old databases.
+
+One nice thing about this approach is that, if I ever need to change the
+sqlite databases again, I can reuse the same code to delete the old and
+regnerate the new, rather than writing migration code specific to a
+given database change.
+
+Anyway, v8 is all ready to merge, but I'm inclined to sit on it for a month or
+two, to avoid upgrade fatigue. Also I find more ways to improve the
+database schema. Perhaps it would be worth it to do some normalization,
+and/or move everything into a single large database rather than the current
+smattering of unnormalized databases?
diff --git a/doc/devblog/day_607__v8_is_done/comment_1_7326382d8ff23873c2fe0d6acd984454._comment b/doc/devblog/day_607__v8_is_done/comment_1_7326382d8ff23873c2fe0d6acd984454._comment
new file mode 100644
index 0000000000..97e6a5cf81
--- /dev/null
+++ b/doc/devblog/day_607__v8_is_done/comment_1_7326382d8ff23873c2fe0d6acd984454._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="pigmonkey"
+ avatar="http://cdn.libravatar.org/avatar/560cedfcec1b75e8ac2e98a10615d770"
+ subject="Consider deprecation warnings in the web app"
+ date="2019-11-07T18:38:28Z"
+ content="""
+If rebuilding the database is an operation that will take some time, it might be nice to have deprecation warnings in the web app before the assistant eventually autoupgrades repos.
+
+I use the assistant/web app to manage about 10 repos, some of which are on the larger size both in terms of disk space and number of files. I suspect that if the assistant kicked off an upgrade with a database rebuild on all of these at once, it would have a noticeable performance impact on my machine. If, after v8 is merged but before the assistant autoupgrades, the web app displayed a message like \"This repository is using a version that will soon be upgraded, click here to learn more about v8 and consider upgrading\", it would give folks (who don't read the devblog or release notes) a heads up and give them a chance to manually upgrade repositories one by one.
+"""]]
diff --git a/doc/devblog/day_607__v8_is_done/comment_2_802311f91808a13473aa99578a429497._comment b/doc/devblog/day_607__v8_is_done/comment_2_802311f91808a13473aa99578a429497._comment
new file mode 100644
index 0000000000..6da2674bac
--- /dev/null
+++ b/doc/devblog/day_607__v8_is_done/comment_2_802311f91808a13473aa99578a429497._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="gb@4a49bb1afcf3d183bba8f07297b0395808768c6c"
+ nickname="gb"
+ avatar="http://cdn.libravatar.org/avatar/51ed40932fbf8748c70b31fd7446d40e"
+ subject="Symlinks for not-present unlocked files in v8?"
+ date="2019-11-10T14:51:59Z"
+ content="""
+Hi Joey, do you think it would be possible to squeeze a solution for the missing symlinks for not-present unlocked files in v8?
+
+Symlinks for missing unlocked files are the last thing missing from V5 for those of us simulating direct mode with adjusted branches and `annex.thin`. For reference <https://git-annex.branchable.com/devblog/day_601__v7_default/> and <https://git-annex.branchable.com/todo/symlinks_for_not-present_unlocked_files/>
+
+"""]]
diff --git a/doc/devblog/day_607__v8_is_done/comment_3_7d3cad862be54dc5a39059f8b82834a6._comment b/doc/devblog/day_607__v8_is_done/comment_3_7d3cad862be54dc5a39059f8b82834a6._comment
new file mode 100644
index 0000000000..0231d92ef0
--- /dev/null
+++ b/doc/devblog/day_607__v8_is_done/comment_3_7d3cad862be54dc5a39059f8b82834a6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="Re: Symlinks for not-present unlocked files in v8"
+ date="2019-11-10T23:03:42Z"
+ content="""
+Adding symlinks for not-present unlocked files in v8 would be great, but if it would hold up the release with SQL db fixes, making that release first would be better.  Some query operations -- like finding all unlocked files, or all files present in one remote but not the other -- currently take a while on large repos; if the SQL refactor could solve that, that by itself would be a major step forward.
+"""]]
diff --git a/doc/devblog/day_608__easier_git-lfs_setup.mdwn b/doc/devblog/day_608__easier_git-lfs_setup.mdwn
new file mode 100644
index 0000000000..4c1f6da546
--- /dev/null
+++ b/doc/devblog/day_608__easier_git-lfs_setup.mdwn
@@ -0,0 +1,25 @@
+The git-lfs support I added to git-annex had one small problem: People
+expect to be able to clone a git repo and get right to using it, but after
+cloning a git-annex repo that's on a server that uses git-lfs, there
+was an extra `git annex enableremote` step to be able to use it as a git-lfs
+special remote. And, you ended up with a "origin" git remote and a git-lfs
+special remote with some other name.
+
+Now, it's this simple to set up a git-lfs repo on eg, github:
+
+	git annex initremote github type=git-lfs encryption=none url=https://github.com/joeyh/lfstest
+	git annex sync github
+	git annex copy --to github ...
+
+And then for others to clone and use it is even simpler:
+
+	git clone https://github.com/joeyh/lfstest
+	cd lfstest
+	git annex get
+
+The only gotcha is that git-annex has to know the url that's used for
+the remote. Cloning any other url any other way (eg http instead of https)
+will result in git-annex not using it. This is a consequence of git-lfs
+not having any equivilant of a git-annex repository UUID, so git-annex
+can't probe for the UUID and has to compare urls. This can be worked
+around using `initremote --sameas` to tell git-annex about other urls.
diff --git a/doc/devblog/day_608__easier_git-lfs_setup/comment_1_b72bea21d4445d12cade9f54ecc3767d._comment b/doc/devblog/day_608__easier_git-lfs_setup/comment_1_b72bea21d4445d12cade9f54ecc3767d._comment
new file mode 100644
index 0000000000..8a45019d3b
--- /dev/null
+++ b/doc/devblog/day_608__easier_git-lfs_setup/comment_1_b72bea21d4445d12cade9f54ecc3767d._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="jkrenzer"
+ avatar="http://cdn.libravatar.org/avatar/49eda64e3bd130a5dfaf48f09218cfb1"
+ subject="Great work! Thank you!"
+ date="2019-12-05T12:10:47Z"
+ content="""
+Hi Joe,
+
+I have been using git-annex since several years now and am really happy with it.
+
+But the addition of git-lfs support was, in my humble opinion, an extraordinary leap forward! After gitlab ceased support in favour of lfs and with the advent of lfs in github, annex-integration with widespread used collaborative git-platforms was not very straight-forward anymore. And so it became harder to justify or promote it's use in my institute or other organizations I work for. This has change now again for the better!
+
+So thank you very much for all the hard work and regarding the daunting speed with which new developments and features (version 8 already!) arrive here: Please take good care and do not overstrain yourself. 
+
+Kind regards,
+
+Jörn
+"""]]
diff --git a/doc/devblog/day_609__optimisation.mdwn b/doc/devblog/day_609__optimisation.mdwn
new file mode 100644
index 0000000000..d89fd66179
--- /dev/null
+++ b/doc/devblog/day_609__optimisation.mdwn
@@ -0,0 +1,11 @@
+Today, sped up many git-annex commands by around 5%. Often git-annex
+traverses the work tree and deserializes keys to its Key data type, only to
+turn around and do something with a Key that needs it to be serialized
+again. So caching the original serialization of a key avoids that work. I
+had started on this in January but had to throw my first attempt away.
+
+The big bytestring conversion in January only yielded a 5-15% speedup,
+so an extra 5% is a nice bonus for so relativly little work today.
+It also feels like this optimisation approach is nearly paid out though;
+only converting all filepath operations to bytestrings seems likely to
+yield a similar widespread improvement.
diff --git a/doc/devblog/day_60__damage_driven_development.mdwn b/doc/devblog/day_60__damage_driven_development.mdwn
new file mode 100644
index 0000000000..64460e86a9
--- /dev/null
+++ b/doc/devblog/day_60__damage_driven_development.mdwn
@@ -0,0 +1,36 @@
+Wrote some evil code you don't want to run today. Git.Destroyer randomly
+generates Damage, and applies it to a git repository, in a way that is
+reproducible -- applying the same Damage to clones of the same git repo 
+will always yeild the same result.
+
+This let me build a test harness for git-repair, which repeatedly clones,
+damages, and repairs a repository. And when it fails, I can just ask it to
+retry after fixing the bug and it'll re-run every attempt it's logged.
+
+This is already yeilding improvements to the git-repair code.
+The first randomly constructed Damage that it failed to recover
+turned out to be a truncated index file that hid some other
+corrupted object files from being repaired.
+
+	[Damage Empty (FileSelector 1),
+	 Damage Empty (FileSelector 2),
+	 Damage Empty (FileSelector 3),
+	 Damage Reverse (FileSelector 3),
+	 Damage (ScrambleFileMode 3) (FileSelector 5),
+	 Damage Delete (FileSelector 9),
+	 Damage (PrependGarbage "¥SOH¥STX¥ENQ¥f¥a¥ACK¥b¥DLE¥n") (FileSelector 9),
+	 Damage Empty (FileSelector 12),
+	 Damage (CorruptByte 11 25) (FileSelector 6),
+	 Damage Empty (FileSelector 5),
+	 Damage (ScrambleFileMode 4294967281) (FileSelector 14)
+	]
+
+I need to improve the ranges of files that it damages -- currently QuickCheck
+seems to only be selecting one of the first 20 or so files. Also, it's quite
+common that it will damage `.git/config` so badly that git thinks it's not
+a git repository anymore. I am not sure if that is something `git-repair`
+should try to deal with.
+
+---
+
+Today's work was sponsored by the WikiMedia Foundation.
diff --git a/doc/devblog/day_610-611__ByteString_optimisation_early_days.mdwn b/doc/devblog/day_610-611__ByteString_optimisation_early_days.mdwn
new file mode 100644
index 0000000000..c64240173d
--- /dev/null
+++ b/doc/devblog/day_610-611__ByteString_optimisation_early_days.mdwn
@@ -0,0 +1,12 @@
+Two entire days spent making a branch where git-annex uses ByteString
+instead of String, especially for filepaths. I commented out all the
+commands except for find, but it still took thousands of lines of patches
+to get it to compile.
+
+The result: git-annex find is between 28% and 66% faster when using
+ByteString. The files just fly by!
+
+It's going to be a long, long road to finish this, but it's good to have a
+start, and know it will be worth it.
+[[todo/optimize_by_converting_String_to_ByteString]] is the tracking page
+for this going forward.
diff --git a/doc/devblog/day_610-611__ByteString_optimisation_early_days/comment_1_1601268fd4dba4df9cc3dc84932914a6._comment b/doc/devblog/day_610-611__ByteString_optimisation_early_days/comment_1_1601268fd4dba4df9cc3dc84932914a6._comment
new file mode 100644
index 0000000000..45e0c377ed
--- /dev/null
+++ b/doc/devblog/day_610-611__ByteString_optimisation_early_days/comment_1_1601268fd4dba4df9cc3dc84932914a6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="amazing!"
+ date="2019-11-26T21:07:32Z"
+ content="""
+66% performance improvements is an amazing number! i take it this will be especially good for repositories with a large number of files? if so this could make my life MUCH better! :)
+
+i wonder if this connects with the [problems gorzen identified in python 3 about POSIX paths](https://changelog.complete.org/archives/10063-the-fundamental-problem-in-python-3)... does Haskell have similar problems with non-unicode filenames?
+
+in any case, I thank you for this awesome work...
+"""]]
diff --git a/doc/devblog/day_610-611__ByteString_optimisation_early_days/comment_2_21872150f9b2ff9cc08f94d52dbdf3a6._comment b/doc/devblog/day_610-611__ByteString_optimisation_early_days/comment_2_21872150f9b2ff9cc08f94d52dbdf3a6._comment
new file mode 100644
index 0000000000..7249b8dc09
--- /dev/null
+++ b/doc/devblog/day_610-611__ByteString_optimisation_early_days/comment_2_21872150f9b2ff9cc08f94d52dbdf3a6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="parallelization"
+ date="2019-11-27T17:30:12Z"
+ content="""
+This is great.
+
+One other potential for speedup is fixing [[issues with parallel operations|forum/people's_experience_with_parallel_git-annex_operations]].  My current fix is to use `-J1`, giving up a potential 96X speedup.  There may also be additional [[todo/parallel_possibilities]].
+"""]]
diff --git a/doc/devblog/day_612__building_again.mdwn b/doc/devblog/day_612__building_again.mdwn
new file mode 100644
index 0000000000..a6e4e518af
--- /dev/null
+++ b/doc/devblog/day_612__building_again.mdwn
@@ -0,0 +1,11 @@
+I've gotten the `bs` branch to build everything again. Was not trivial,
+the diff is over 7000 lines.
+
+Had hoped this was a mechanical enough conversion it would not introduce
+many bugs, but the test suite quickly found a lot of problems. So that
+branch is not ready for merging yet.
+
+I'm considering making a library that's like
+[filepath](http://hackage.haskell.org/package/filepath) but for
+RawFilePath. That would probably speed git-annex up by another 5% or so,
+in places where it currently has to convert back to FilePath.
diff --git a/doc/devblog/day_613__end-to-end_ByteString_milestone.mdwn b/doc/devblog/day_613__end-to-end_ByteString_milestone.mdwn
new file mode 100644
index 0000000000..1b774c019b
--- /dev/null
+++ b/doc/devblog/day_613__end-to-end_ByteString_milestone.mdwn
@@ -0,0 +1,17 @@
+The `bs` branch has reached a milestone: `git-annex find` and `git-annex
+get` (when all files are present) process ByteStrings end-to-end with 
+no String conversion. That sped it up by around 30% on top of the previous
+optimisations. 
+
+To get here, I spent a couple of days creating the
+[filepath-bytestring](https://joeyh.name/blog/entry/announcing_the_filepath-bytestring_haskell_library/)
+library, which git-annex will depend on. Lots more git-annex internals
+were switched to ByteString, especially everything having to do with
+statting files.
+
+Other commands, like `git-annex whereis`, still do some String
+conversions. Optimisation never ends.
+
+But the bs branch is ready to merge as-is, and the diff is 10 thousand lines,
+so not a branch I want to maintain for long. Planning to merge it after
+the next release.
diff --git a/doc/devblog/day_614__bytestring_wrapping_up.mdwn b/doc/devblog/day_614__bytestring_wrapping_up.mdwn
new file mode 100644
index 0000000000..db686e7d6f
--- /dev/null
+++ b/doc/devblog/day_614__bytestring_wrapping_up.mdwn
@@ -0,0 +1,15 @@
+Cut the last release before the switch over to end-to-end ByteString.
+(Including fixing the rpm repo's index which had not been getting updated.)
+
+I had left the `bs` branch last week with a known bug, so got that fixed.
+Also there were some encoding problems on windows with the ByteString
+filepaths, which needed a new release of filepath-bytestring to clean up.
+Now I think the `bs` branch is really in a mergeable state.
+(It's still not tested on Windows at all though.)
+
+Took the last little while to do some more profiling. Mostly the remaining
+ByteString conversions barely seem worth doing (1% improvement at most),
+but [[todo/optimise_journal_access]] seems like it could pay off well.
+
+Also found time in there somewhere to implement `git annex inprogress
+--key`
diff --git a/doc/devblog/day_615__new_year.mdwn b/doc/devblog/day_615__new_year.mdwn
new file mode 100644
index 0000000000..f36668383b
--- /dev/null
+++ b/doc/devblog/day_615__new_year.mdwn
@@ -0,0 +1,21 @@
+The release of git-annex with all the ByteString optimisations went out
+earlier this week. The Windows autobuilder was down and I didn't try to get
+it building on Windows, so fixed that today, luckily all those changes only
+broke a few bits of Windows-specific code.
+
+Also today, I added git-annex add --force-annex/--force-git options.
+These do the same thing as -c annex.largefiles=anthing etc, but 
+are easier to type and may avoid some tricky git behavior in some edge
+cases.
+
+I'd kind of like to get back to v8 this month and perhaps release it.
+There's a `v8` branch now, which as well as the sqlite changes adds a new
+annex.dotfiles config setting, and cleans up the special cases around
+adding dotfiles. Anyone not using git-annex to manage large dotfiles
+(or files in dotdirs) won't be impacted, but those who do will need to
+enable annex.dotfiles and configure annex.largefiles to match the dotfiles
+they want annexed. There is a risk that someone who's in the habit of
+running `git annex add .dotfile` to add them to the annex will be surprised
+when the new version adds them to git because they've not done the necessary
+configuration. I'm still mulling over whether this is an acceptable risk
+to mostly de-uglify and de-special-case dotfiles.
diff --git a/doc/devblog/day_616__remote_config_parsing.mdwn b/doc/devblog/day_616__remote_config_parsing.mdwn
new file mode 100644
index 0000000000..858b53d206
--- /dev/null
+++ b/doc/devblog/day_616__remote_config_parsing.mdwn
@@ -0,0 +1,9 @@
+I'm in the middle of a big change to internals. Remotes have buried inside
+them a string-based configuration, and those settings are only parsed when
+they're used, so bad configuration is often ignored rather than being
+detected when the user inputs it. The parsing is moving to happen upfront.
+
+This is something I could not have done when I first wrote git-annex,
+because the values that get parsed have many different types, so how can a
+single Remote data type contain those, whatever they are? Now I know how
+to use the Typeable class to do such things.
diff --git a/doc/devblog/day_617__remote_config_parsing_continued.mdwn b/doc/devblog/day_617__remote_config_parsing_continued.mdwn
new file mode 100644
index 0000000000..48d41d0f81
--- /dev/null
+++ b/doc/devblog/day_617__remote_config_parsing_continued.mdwn
@@ -0,0 +1,20 @@
+This has been a big change, I'm now 3 days and a 3000 line diff in and I
+finally got all the remote configuration settings converted to the new
+up-front parsing.
+
+Seems like quite a lot of work, since the only user-visible improvement is
+these error messages:
+
+	# git annex initremote demo type=directory directory=../foo encryption=none foo=bar
+	initremote demo
+	git-annex: Unexpected fields: foo
+	
+	# git annex initremote demo type=directory directory=../foo encryption=none exporttree=true
+	initremote demo
+	git-annex: Bad value for exporttree (expected yes or no)
+
+But this involved paying down technical debt in a big code base, so of course it was
+expensive.
+
+Anyway, it should now be relatively easy to implement
+`git annex initremote --list-params-for=S3`
diff --git a/doc/devblog/day_617__remote_config_parsing_continued/comment_1_d3ab2e85ea775cc6f39f12210374c35f._comment b/doc/devblog/day_617__remote_config_parsing_continued/comment_1_d3ab2e85ea775cc6f39f12210374c35f._comment
new file mode 100644
index 0000000000..541bb6487d
--- /dev/null
+++ b/doc/devblog/day_617__remote_config_parsing_continued/comment_1_d3ab2e85ea775cc6f39f12210374c35f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="thanks"
+ date="2020-01-23T16:51:44Z"
+ content="""
+\"the only user-visible improvement is these error messages\" -- FWIW, I've been bitten by the lack of config param checking in the past (thought I had set a chunk size but didn't due to misspelled param name, had to re-create the remote.)
+"""]]
diff --git a/doc/devblog/day_618__v8_merged.mdwn b/doc/devblog/day_618__v8_merged.mdwn
new file mode 100644
index 0000000000..8013fee452
--- /dev/null
+++ b/doc/devblog/day_618__v8_merged.mdwn
@@ -0,0 +1,5 @@
+v8 is now merged into master and so the next release will use v8.
+
+The presumably last v7 release happened earlier today, with some
+accumulated changes, including a data loss bug in
+`git-annex fsck --from remote -J`.
diff --git a/doc/devblog/day_619__important_bugfix_release_and_v8_too.mdwn b/doc/devblog/day_619__important_bugfix_release_and_v8_too.mdwn
new file mode 100644
index 0000000000..f59e5751de
--- /dev/null
+++ b/doc/devblog/day_619__important_bugfix_release_and_v8_too.mdwn
@@ -0,0 +1,14 @@
+A [[nasty_bug|bugs/gcrypt_special_remote_not_working]]
+that made git-annex store content on gcrypt and git-lfs
+without encrypting it led to a bugfix-only release,
+7.20200226.
+
+Since v8 was already close to release -- I was thinking probably Friday --
+and the autobuilders are already building that version, it made sense to
+move up the v8 release as well, so that's also been released today.
+
+That bug was happened because of an oversight when I was doing the big
+remote config parsing change. I tested that a lot, but I didn't think
+to test that gcrypt actually stored content encrypted! I need to do
+something about [[todo/network_test_suite]], so this kind of breakage
+in special remotes can be caught.
diff --git a/doc/devblog/day_61__damage_driven_development__II.mdwn b/doc/devblog/day_61__damage_driven_development__II.mdwn
new file mode 100644
index 0000000000..605a3878d8
--- /dev/null
+++ b/doc/devblog/day_61__damage_driven_development__II.mdwn
@@ -0,0 +1,15 @@
+Pushed out a minor release of git-annex today, mostly to fix build problems
+on Debian. No strong reason to upgrade to it otherwise.
+
+Continued where I left off with the Git.Destroyer. Fixed quite a lot of
+edge cases where git repair failed due to things like a corrupted .git/HEAD
+file (this makes git think it's not in a git repository), corrupt
+git objects that have an unknown object type and so crash git hard, and
+an interesting failure mode where git fsck wants to allocate 116 GB of
+memory due to a corrupted object size header. Reported that last to the git
+list, as well as working around it.
+
+At the end of the day, I ran a test creating 10000 corrupt git
+repositories, and **all** of them were recovered! Any improvements will
+probably involve finding new ways to corrupt git repositories that my code
+can't think of. ;)
diff --git a/doc/devblog/day_620__emergency_mode.mdwn b/doc/devblog/day_620__emergency_mode.mdwn
new file mode 100644
index 0000000000..711ec5b76d
--- /dev/null
+++ b/doc/devblog/day_620__emergency_mode.mdwn
@@ -0,0 +1,20 @@
+I'm only working on git-annex a day or two a week at present. Like
+everyone, dealing with the covid-19 crisis taking up a lot of my time.
+Some days I can't concentrate, some days I am dealing with basic needs,
+and other days I am rushing to develop other software targeted at this crisis.
+(See my [personal blog](https://joeyh.name/blog/).)
+
+I remotely attended the
+[MONII](https://www.mcgill.ca/neuro/channels/event/virtual-web-based-making-open-neuroscience-infrastructures-interoperable-30-303671)
+conference a week ago, with lots of researchers doing things with software
+related to git-annex, some in the health field, and something that struck
+me was a mention that it's important that scientists continue their work,
+even if it's not directly related to the crisis. All kinds of fields are
+going to be important in the time ahead beyond saving lives.
+
+So I am prioritizing anything scientists need to use git-annex, and
+anything those working on the crisis might need. If that's you and you need
+something, you can use the new "priority" tag on bugs and todos, and it
+will go right to the top of the [[design/roadmap]]. Do bear in mind that I
+have limited time/resources/attention right now, so only use it when you
+really need something urgently.
diff --git a/doc/devblog/day_621__back_to_normal-ish.mdwn b/doc/devblog/day_621__back_to_normal-ish.mdwn
new file mode 100644
index 0000000000..535c10df26
--- /dev/null
+++ b/doc/devblog/day_621__back_to_normal-ish.mdwn
@@ -0,0 +1,14 @@
+git-annex development has been more or less back to normal for the past
+several weeks, including getting on top of most of the recent backlog.
+
+Today I'm finishing up a project that has taken half the week. The internal
+remote interface uses Bool extensively, and avoided throwing exceptions,
+and so it was not uncommon for access to a remote to fail and no reason be
+given. There have been a number of bugs about one thing or anther over the
+years, which have been fixed on an ad hoc basis without addressing the
+underlying problem. Now it's all been changed to throw exceptions, so the
+failure reason will always be displayed. Some tens of thousands of lines of
+diffs later, it's almost done.
+
+Today's work was sponsored by Graham Spencer
+[on Patreon](https://www.patreon.com/joeyh).
diff --git a/doc/devblog/day_622__behavior_changes.mdwn b/doc/devblog/day_622__behavior_changes.mdwn
new file mode 100644
index 0000000000..b0c2adf44e
--- /dev/null
+++ b/doc/devblog/day_622__behavior_changes.mdwn
@@ -0,0 +1,28 @@
+Landed two behavior changes in the past two days, which I wanted to mention
+here.
+
+First, special remotes configured with autoenable=yes will be auto-enabed
+by the automatic git-annex initialization that it does in a clone of a
+git-annex repo. Before, `git annex init` had to be run to "auto-enable"
+them. Probably few people will notice this, unless a special remote somehow
+takes too long to enable. May later have to add a timeout.
+
+Second, a command like `git annex get foo` will complain if the specified
+file or directory is not known to git. Lots of users have gotten confused
+by why such a command would silently return without doing anything. 
+
+Commands like `git annex get dir` will not complain about files in the
+directory that are not under git's control, unless none of them are.
+(Same behavior as eg `git commit dir`.) Mostly this change affects using
+wildcards, or just being confused about a file not being checked into git.
+
+Due to the potential to break some workflows, new behavior will only be
+enabled for now annex.skipunknown is set to false. I plan to make that the
+default in early 2022. (About a year delay seemed right generally but I
+added some time due to the pandemic.) So if you prefer the original
+behavior, you can just set annex.skipunknown true.
+
+At least for now, git-annex will still skip over files that are checked
+into git but are not annexed files. May make sense to change that too,
+we'll see if users get confused by that like by the other skipping
+behavior.
diff --git a/doc/devblog/day_623__started_timeouts.mdwn b/doc/devblog/day_623__started_timeouts.mdwn
new file mode 100644
index 0000000000..b7e90e191b
--- /dev/null
+++ b/doc/devblog/day_623__started_timeouts.mdwn
@@ -0,0 +1,17 @@
+Working this week on a long missing capability of git-annex: The ability to
+time out, and perhaps retry, a transfer that has gotten stuck.
+
+It's a lot harder than it sounds, because to get it right with no resource
+leaks, every process and child thread that git-annex runs has to be stopped
+by a timeout too, which the current code base was not designed for at all.
+[[gory details here|todo/more_extensive_retries_to_mask_transient_failures]]
+
+So far I have most processes being stopped, and that took 2 solid days.
+This may take a while to finish. I do think though, that once the basic
+operation of stopping a transfer is available, there will be other uses
+besides timeouts. 
+
+One I can think of already is, if a remote is being very slow, it might
+make sense to stop a transfer from it and switch to using a different
+remote. Another is that there could be a hotkey to skip the current
+transfer, moving on to the next file.
diff --git a/doc/devblog/day_624__timeouts_snag.mdwn b/doc/devblog/day_624__timeouts_snag.mdwn
new file mode 100644
index 0000000000..67221e2c1e
--- /dev/null
+++ b/doc/devblog/day_624__timeouts_snag.mdwn
@@ -0,0 +1,13 @@
+Started out the day productively working through more async exception
+safety for timeouts. But then I realized there's a whole can of worms
+involving bracket not working like I expected it to. 
+
+Got a bit side tracked checking if other people expect bracket to work the
+way it actually does, and [seem to have found a
+bug](https://github.com/haskell/process/issues/183) in the `process`
+library. Which is especially concerning since it's just the first place I
+looked, so what other libraries might have similar problems?
+
+So the timeouts feature is seeming a lot less plasible than it did last
+week. I'll probably defer it until later. The work done on it so far is
+at least generally an improvement to the code.
diff --git a/doc/devblog/day_625__import_tree_largefiles.mdwn b/doc/devblog/day_625__import_tree_largefiles.mdwn
new file mode 100644
index 0000000000..6506261e05
--- /dev/null
+++ b/doc/devblog/day_625__import_tree_largefiles.mdwn
@@ -0,0 +1,13 @@
+New feature today: Implemented [[todo/import_tree_should_honor_annex.largefiles]].
+
+This only took an hour to implement, but I had to think for several hours
+first to get a solid understanding of it. Particularly, what happens if
+a file on a remote has a name that makes it be treated as non-large, but
+then in a later import, it's renamed to a name that would be treated as
+large? (Or vice-versa.) My conclusion is that is equivilant to `git
+annex add` of a file with the first name followed by `git mv`, so it's
+ok for annex.largefiles to not take effect in such a case.
+
+----
+
+Today's work was sponsored by Martin D [on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_626__performance_week.mdwn b/doc/devblog/day_626__performance_week.mdwn
new file mode 100644
index 0000000000..88baa0f869
--- /dev/null
+++ b/doc/devblog/day_626__performance_week.mdwn
@@ -0,0 +1,18 @@
+I've spent all week working on performance. It started when Lukey
+found a way to use git cat-file --buffer to make --all faster.
+Once implemented, that turned out to be a 2x to 16x speedup in seek time.
+
+I felt that same approach could probably also speed up other parts of
+git-annex that use git cat-file, so spent another 4 days finding ways to do
+that. Some of the ideas are not implemented yet, but I landed a 2x speedup
+today, to all git-annex commands that seek annexed files to work on.
+
+Oh and also there used to be a git-annex branch read cache, but it got
+removed many years ago, and I forgot it had been removed. Which does not
+lead to writing the fastest code. Bringing the cache back makes some things
+another 20% faster.
+
+----
+
+This work was sponsored by Mark Reidenbach, Jake Vosloo, and Graham Spencer 
+[on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_627__last_performance_work_for_now.mdwn b/doc/devblog/day_627__last_performance_work_for_now.mdwn
new file mode 100644
index 0000000000..f3417f02de
--- /dev/null
+++ b/doc/devblog/day_627__last_performance_work_for_now.mdwn
@@ -0,0 +1,16 @@
+One more day working on performance, as I had a few known improvements I had
+not had time to get to. Managed to double the speed of `move --to, `copy
+--to`, and `drop` when seeking files to act on and a few percent more in
+general.
+
+My laptop's keyboard is failing, with more and more keys not working --
+luckily so far only ones in the number row -- so I'm stopping early and
+hoping the fix arrives quickly on Monday. At some point I know
+that [[this_todo|todo/faster_key_lookup_for_limits]] will be able to speed
+up using things like `--in` and `--copies` by a similar amount as the recent
+performance improvements.
+
+--
+
+Today's work was sponsored by Jake Vosloo
+[on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_628__external_key_backends.mdwn b/doc/devblog/day_628__external_key_backends.mdwn
new file mode 100644
index 0000000000..a10939b320
--- /dev/null
+++ b/doc/devblog/day_628__external_key_backends.mdwn
@@ -0,0 +1,10 @@
+Today I implemented [[external backends|design/external_backend_protocol]]
+for keys. So unusual new hashes can be used by writing a small program.
+
+Probably lots of other uses for this too; I don't know if I'll like
+them all. It has the potential to warp git-annex in some directions I don't
+want to deal with. Still, it's good to have this feature.
+
+I was able to reuse a lot of the external special remote code for this,
+and only had to write around 400 lines of new code. Dunno how that all
+happened in 8 hours, but it did!
diff --git a/doc/devblog/day_628__external_key_backends/comment_1_e6ff184245dd1a6cffff2ecdaeff6a66._comment b/doc/devblog/day_628__external_key_backends/comment_1_e6ff184245dd1a6cffff2ecdaeff6a66._comment
new file mode 100644
index 0000000000..09126d2db4
--- /dev/null
+++ b/doc/devblog/day_628__external_key_backends/comment_1_e6ff184245dd1a6cffff2ecdaeff6a66._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="thanks"
+ date="2020-07-30T15:51:13Z"
+ content="""
+Thanks a lot Joey for implementing this.
+
+\"only had to write around 400 lines of new code\" -- sign of good design.  At some point I'll learn enough Haskell to understand/learn from git-annex's design.
+
+"""]]
diff --git a/doc/devblog/day_629__async_external_special_remotes.mdwn b/doc/devblog/day_629__async_external_special_remotes.mdwn
new file mode 100644
index 0000000000..eefc8958be
--- /dev/null
+++ b/doc/devblog/day_629__async_external_special_remotes.mdwn
@@ -0,0 +1,25 @@
+After a release on Monday, I've spent the week working on
+[[async extension to external special remote protocol|design/external_special_remote_protocol/async_appendix]].
+This is lets a single external special remote process handle multiple
+requests at the same time, when it's more efficient to use one process
+than for git-annex to run several processes.
+
+It's a good thing I added support for extensions a couple of years back.
+I never imagined at the time using it for something like this, that
+radically changes the whole protocol! It could have just been protocol
+version 2, but then special remotes would be pushed towards using this by
+default, which I don't want. It's probably overkill for most of them.
+
+          J 4 CHECKPRESENT Key3
+          J 5 CHECKPRESENT Key4
+          J 6 REMOVE Key5
+          J 4 CHECKPRESENT-SUCCESS Key3
+          J 6 REMOVE-SUCCESS Key5
+          J 5 CHECKPRESENT-FAILURE Key4
+
+The protocol extension went through a bunch of iterations, ending up with
+probably the simplest possible way to do it, a simple framing layer around
+the main protocol. I started with rather a lot of rather hairy code and it
+kind of all melted away as I refined the protocol down to that, which was
+nice, although I also kind of wish I had been able to jump right to
+the clean and simple end result.
diff --git a/doc/devblog/day_62__upgrade_alerts.mdwn b/doc/devblog/day_62__upgrade_alerts.mdwn
new file mode 100644
index 0000000000..0b30785631
--- /dev/null
+++ b/doc/devblog/day_62__upgrade_alerts.mdwn
@@ -0,0 +1,22 @@
+Still working on the git repair code. Improved the test suite, which found
+some more bugs, and so I've been running tests all day and occasionally
+going and fixing a bug in the repair code. The hardest part of repairing a
+git repo has turned out to be reliably determining which objects in it are
+broken. Bugs in git don't help (but the git devs are going to fix the one I
+reported).
+
+But the interesting new thing today is that I added some upgrade alert code
+to the webapp. Ideally everyone would get git-annex and other software as
+part of an OS distribution, which would include its own upgrade system -- 
+But the  [survey](http://git-annex-survey.branchable.com/polls/2013/how_installed/)
+tells me that a quarter of installs are from the prebuilt binaries I
+distribute.
+
+So, those builds are going to be built with knowledge of an upgrade url,
+and will periodically download a small info file (over https) to see if a
+newer version is available, and show an alert.
+
+I think all that's working, though I have not yet put the info files in
+place and tested it. The actual upgrade process will be a manual
+download and reinstall, to start with, and then perhaps I'll automate it
+further, depending on how hard that is on the different platforms.
diff --git a/doc/devblog/day_62__upgrade_alerts/comment_1_cdb44aaa1d2a784a72613cbf16038f89._comment b/doc/devblog/day_62__upgrade_alerts/comment_1_cdb44aaa1d2a784a72613cbf16038f89._comment
new file mode 100644
index 0000000000..cb0bfc08b8
--- /dev/null
+++ b/doc/devblog/day_62__upgrade_alerts/comment_1_cdb44aaa1d2a784a72613cbf16038f89._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
+ nickname="Tobias"
+ subject="gitannex-install"
+ date="2013-11-22T07:13:02Z"
+ content="""
+To install and upgrade the prebuilt binary on Linux I use the fantastic [gitannex-install](https://github.com/zerodogg/scriptbucket/blob/master/gitannex-install) script, together with the upgrade alert this is just great.
+"""]]
diff --git a/doc/devblog/day_62__upgrade_alerts/comment_2_b08bb946e4760d7f03b45c852c745b2e._comment b/doc/devblog/day_62__upgrade_alerts/comment_2_b08bb946e4760d7f03b45c852c745b2e._comment
new file mode 100644
index 0000000000..3a5ec5b7db
--- /dev/null
+++ b/doc/devblog/day_62__upgrade_alerts/comment_2_b08bb946e4760d7f03b45c852c745b2e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="git-annex release annex"
+ date="2013-11-25T06:15:23Z"
+ content="""
+Immediate thought: instead of an info file, why not sync a public git repo with releases annexed with URLs?
+"""]]
diff --git a/doc/devblog/day_630__dealing_with_git_changes.mdwn b/doc/devblog/day_630__dealing_with_git_changes.mdwn
new file mode 100644
index 0000000000..4f496e96b9
--- /dev/null
+++ b/doc/devblog/day_630__dealing_with_git_changes.mdwn
@@ -0,0 +1,42 @@
+A stressful thing about maintaining git-annex is that sometimes changes to
+git break it in some way. Since git has a high development velocity, it can
+be hard to keep up with all changes and catch such problems. The git devs
+are good about backwards compatibility, but can still make mistakes. Worse
+is when there's an assumption about how people will use git, when git-annex
+lets people use it in a rather different way. I've been dealing with one of
+those today.
+
+    CONFLICT (file location): x/foo added in refs/remotes/origin/master
+    inside a directory that was renamed in HEAD, suggesting it should
+    perhaps be moved to y/foo.
+
+This was a interesting new git feature when it was added back in 2.18,
+especially since git doesn't really track directories, so is here
+somewhat guessing if a directory was renamed.
+
+An example of a way git-annex is used that this does not play well with
+is managing media files for consumption, where you might have an incoming
+directory, and then rename files to somewhere else once they're processed.
+If you renamed the last file in your incoming directory, and then a new
+file was later added to it in some other clone of the repository, this git
+feature could result in that new file being moved to an unexpected
+location when you `git-annex sync`.
+
+Normally it wouldn't matter much if git guessed wrong like that about a
+rename, since the merge conflict forces the user to look at it.
+But, git-annex sync and the assistant automatically resolve merge
+conflicts, so the user can easily not notice this happening.
+
+If you're worried that might have happened to you, look for files in your
+repository with ".variant" in the name. If there are two with the same
+base name, that's a normal merge conflict, but if there's only a single
+variant file by itself, it could have been created by this rename
+conflict scenario.
+
+git-annex will now avoid this problem, by setting merge.directoryRenames=false
+when running a merge (unless you've manually configured it yourself).
+
+----
+
+Today's work was sponsored by Martin D
+[on Patreon](https://www.patreon.com/joeyh)
diff --git a/doc/devblog/day_630__introspection_for_speed.mdwn b/doc/devblog/day_630__introspection_for_speed.mdwn
new file mode 100644
index 0000000000..e3096fb702
--- /dev/null
+++ b/doc/devblog/day_630__introspection_for_speed.mdwn
@@ -0,0 +1,11 @@
+Three recent todos have needed a way to introspect the matchers built from
+preferred content expressions and some command-line options, to determine
+what information they use. So implemented that today.
+
+With that, it was possible to double the seeking speed of 
+`git-annex sync --all` when include=/exclude= are not used
+in preferred content. And the seeking speed of commands like
+`git-annex find --copies=2` and `--in remote` improved by around 20%.
+
+Today's work was sponsored by Jake Vosloo
+[on Patreon](https://www.patreon.com/joeyh).
diff --git a/doc/devblog/day_631-632__memory_leak.mdwn b/doc/devblog/day_631-632__memory_leak.mdwn
new file mode 100644
index 0000000000..dea5e71e4e
--- /dev/null
+++ b/doc/devblog/day_631-632__memory_leak.mdwn
@@ -0,0 +1,16 @@
+I've spent two days trying to track down a recently introduced memory leak,
+or leaks. This was unusually hard because all the profiler could tell
+me is the memory is "PINNED", but not what allocated it or anything else
+about it. 
+
+I probably should have bisected it, rather than staring at the code and
+randomly reimplementing things I thought could be pinning memory. Oops.
+
+And there is more memory that the profiler doesn't even show
+being allocated, which got much bigger with a new toolchain, and I have not
+gotten to the bottom of that yet.
+
+--
+
+This work was sponsored by Jake Vosloo and Mark Reidenbach
+<a href="https://patreon.com/joeyh">on Patreon</a>.
diff --git a/doc/devblog/day_633__ten_years.mdwn b/doc/devblog/day_633__ten_years.mdwn
new file mode 100644
index 0000000000..a74e96a69e
--- /dev/null
+++ b/doc/devblog/day_633__ten_years.mdwn
@@ -0,0 +1,12 @@
+The first prerelease of git-annex was made ten years ago.
+Taking a look back at 0.01, which I think only I ever used, it
+had the commands add, get, drop, unannex, init, fix, and fromkey.
+There were 2600 lines of code in all, which has increased 30-fold.
+
+Later that week, 0.02 added the move command. I've been working recently
+on fixing a [[tricky_problem|todo/interruped_move_resume]] with
+resuming interrupted moves. The move command has been surprisingly
+subtle to get just right, since it turns out to not be as simple as a get
+followed by a drop -- numcopies checks that would prevent a drop sometimes
+need to be relaxed to allow a move. Maybe I've finally gotten it perfect
+now. Probably not.
diff --git a/doc/devblog/day_633__ten_years/comment_1_4842e53398d9ee668053ec6d4da426dd._comment b/doc/devblog/day_633__ten_years/comment_1_4842e53398d9ee668053ec6d4da426dd._comment
new file mode 100644
index 0000000000..3bc85ff9a2
--- /dev/null
+++ b/doc/devblog/day_633__ten_years/comment_1_4842e53398d9ee668053ec6d4da426dd._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="amindfv@97236fbaab6048ce6805b2737b27dd7f1cd51da4"
+ nickname="amindfv"
+ avatar="http://cdn.libravatar.org/avatar/a82f30bc12d79fee2d142021af8e9aa0"
+ subject="comment 1"
+ date="2020-10-23T05:37:40Z"
+ content="""
+Many congratulations and many thanks! Git annex has been huge for me and I know it has been for lots and lots of other people too. Here's to another happy and healthy decade for you and for Git Annex, and then another decade, and then another :)
+"""]]
diff --git a/doc/devblog/day_633__ten_years/comment_2_48b09fc7e66cd9d9fb7c0f78f21c7ac5._comment b/doc/devblog/day_633__ten_years/comment_2_48b09fc7e66cd9d9fb7c0f78f21c7ac5._comment
new file mode 100644
index 0000000000..554065ee40
--- /dev/null
+++ b/doc/devblog/day_633__ten_years/comment_2_48b09fc7e66cd9d9fb7c0f78f21c7ac5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="thanks"
+ date="2020-10-26T15:37:57Z"
+ content="""
+\"Thanks\" doesn't quite cut it, but still worth saying :)  Thanks for the huge amount of work and thought you've put into this over the years.  git-annex has grown into an impressive \"swiss army knife\" adaptable to all sorts of uses.  It's certainly one of the most best FLOSS projects I've seen.  With the proliferation of various cloud services for storing data, it's becoming even more useful for keeping track of things without losing sanity.  Thanks @joeyh!
+"""]]
diff --git a/doc/devblog/day_634__new_features.mdwn b/doc/devblog/day_634__new_features.mdwn
new file mode 100644
index 0000000000..bd8271715f
--- /dev/null
+++ b/doc/devblog/day_634__new_features.mdwn
@@ -0,0 +1,59 @@
+Update on 3 new features. Appropriate to the season, there's a past,
+a present, and a future one.
+
+---
+
+Past: The last release added `git annex adjust --unlock-present`
+which might be just what you were looking for, if you used to use direct
+mode. It unlocks files whose content is present, but files whose content is
+missing are dangling symlinks. Currently, the branch is only refresh after
+git-annex finishes all requested transfers. There is a 
+annex.adjustedbranchrefresh config that can make it refresh more
+frequently, but doing it after every file may be too slow in a large repo.
+I hope to speed it up enough eventually to perhaps make this the default
+later in places where `--unlock` is currently used.
+
+(That work was sponsored by Gioele Barabucci ENK)
+
+----
+
+Present: This week, I've been working on an internal protocol to
+comminicate about all console IO
+that git-annex does, so it can start some child processes to perform
+long-running tasks, like downloads. The goal is to 
+[[detect stalled transfers and cancel or retry them|todo/more_extensive_retries_to_mask_transient_failures]].
+This is after previous attempts, at doing it using threads failed.
+I finished the IO serialization part today, but may put off the rest until
+a bit later.
+
+(This work was sponsored by Jake Vosloo, Mark Reidenbach, and Graham Spencer
+[on Patreon](https://patreon.com/joeyh/))
+
+----
+
+Future: We've been thinking about a [[todo/borg_special_remote]] for a
+while, and last night I realized that something I implemented this summer
+for [[todo/importing_from_special_remote_without_downloading]] might be
+just what's needed for this new kind of remote. That was surprising!
+At the time, I had been doubtful about the new feature, since it seemed
+only the directory special remote would benefit from it at all.
+
+The idea is the user runs a backup program, like borg, to store a copy of
+your git-annex repo, and then points git-annex at it, to learn what annexed
+content is stored in it. This is particularly exciting to me, because it's
+a whole new kind of special remote, and could be used for lots of backup
+programs beyond borg, and probably other stuff.
+
+Imagine something like this:
+
+	borg init user@host:/annex.borg
+	borg create user@host:/annex.borg::{now} .git
+	git annex initremote borg type=borg repolocation=user@host:/annex.borg
+	git annex import --known --from borg
+	git annex drop --unused
+
+And now all your old unused annex objects have been moved into the borg
+repo, where they're efficiently stored with its data deduplication.
+And of course, you can use `git-annex get` to get them from there.
+
+I have a feeling I'll be haunted by this idea until I implement it..
diff --git a/doc/devblog/day_635__stall_detection.mdwn b/doc/devblog/day_635__stall_detection.mdwn
new file mode 100644
index 0000000000..f870fdbd21
--- /dev/null
+++ b/doc/devblog/day_635__stall_detection.mdwn
@@ -0,0 +1,19 @@
+Finally have all the groundwork done for canceling stalled transfers. This
+involved taking some code that was in the assistant, and had not been
+touched for probably 7 years beyond basic maintenance, dusting it off,
+and making it suitable to be used in git-annex more generally. Now I have
+git-annex using transferkeys child processes, and all that seems to work
+well.
+
+I'm finishing up today by designing the new git config that will enable stall
+detection and canceling. annex.stalldetection will be configurable to a
+value like "1MB/30s", which means it's stalled unless every 30 seconds
+a megabyte of data has been tranferred. Or "0KiB/2m" will let things stall
+for up to 2 minutes with no data transfer. There will also be a per-remote
+config, so minimum transfer rates can be set for each. This can be combined
+with annex.retry to make it retry after detecting a stall.
+
+----
+
+Today's work was sponsored by Jake Vosloo
+[on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_636__stall_stall.mdwn b/doc/devblog/day_636__stall_stall.mdwn
new file mode 100644
index 0000000000..3c04f71830
--- /dev/null
+++ b/doc/devblog/day_636__stall_stall.mdwn
@@ -0,0 +1,11 @@
+I got annex.stalldetection implemented yesterday without much drama. It was
+a big patch, and it all worked on the first try. But ended up also spending
+all of today working on it. After sleeping on it, I realized there were
+several things I needed to improve. Including making a real
+protocol that git-annex uses to talk to the helper `git-annex
+transferrer` processes, to make it fairly future proof.
+
+----
+
+This work was sponsored by Jake Vosloo and Mark Reidenbach 
+[on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_637__thirdparty_of_borg.mdwn b/doc/devblog/day_637__thirdparty_of_borg.mdwn
new file mode 100644
index 0000000000..5d4a34c999
--- /dev/null
+++ b/doc/devblog/day_637__thirdparty_of_borg.mdwn
@@ -0,0 +1,17 @@
+Finally gotten started on the borg special remote idea. A prerequisite of
+that is remotes that can be imported from, but not exported to. So I
+actually started by allowing setting importtree=yes without
+exporttree=yes. A lot of code had assumptions about that not being allowed,
+so it took a while to chase down everything. Finished most of that yesterday.
+
+What I've done today is added a `thirdPartyPopulated` type of remote,
+which `git-annex sync` can "pull" from by using the existing import
+interface to list files on it, and determine which of them are annex object
+files. I have not started on the actual borg remote at all, but this should
+be all the groundwork for it done.
+
+(I also finished up annex.stalldetection earlier this week.)
+
+---
+
+This work was sponsored by Jake Vosloo [on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_638__borg_special_remote_working.mdwn b/doc/devblog/day_638__borg_special_remote_working.mdwn
new file mode 100644
index 0000000000..1abb08de27
--- /dev/null
+++ b/doc/devblog/day_638__borg_special_remote_working.mdwn
@@ -0,0 +1,26 @@
+Just barely managed to get the borg special remote fully working by end of
+day today. I'm still a bit shocked it was possible to do this at all, let
+alone as neatly as it turned out, with so few changes to git-annex to
+support such an entirely different thing.
+
+I put in a fair amount of effort to making it fast to keep up-to-date with
+changes to the borg repo; `git-annex sync` does need to run `borg list` to
+check what archives are in it, but it avoids rescanning archives it already
+knows the contents of.
+
+There are a slew of new todo items related to this special remote:
+[[todo/allow_overriding_untrust_of_import_remotes]],
+[[todo/borg_special_remote_add_subdir_config]],
+[[todo/sync_--content_with_borg_does_not_get_content]],
+[[todo/borg_sync_tree_not_grafted]],
+[[todo/use_same_vector_clock_for_content_identifier_updates_in_import]]
+
+And, if this backup-as-a-remote idea does turn out to be useful,
+there are lots of other backup programs. It would be good to be able to
+write external special remotes for them, but that would need
+[[a_protocol_extension|design/external_special_remote_protocol/export_and_import_appendix]].
+
+---
+
+This work was sponsored by Mark Reidenbaach 
+[on Patreon](https://patreon.com/joeyh).
diff --git a/doc/devblog/day_639__major_keys_database_milestone.mdwn b/doc/devblog/day_639__major_keys_database_milestone.mdwn
new file mode 100644
index 0000000000..1915de45d8
--- /dev/null
+++ b/doc/devblog/day_639__major_keys_database_milestone.mdwn
@@ -0,0 +1,15 @@
+I've fallen completely out of practice on this dev blog, but I felt I had
+to mention a major milestone accomplished over the past week. The database
+that git-annex maintains about keys and worktree files used to only be
+guaranteed to be maintained for unlocked files, but it did not have
+information about locked files. Now it does, and it's automatically, and
+efficiently (I hope) kept up-to-date.
+
+That let a long-standing bug get fixed, where when 2 files used the same
+key, the preferred content expression could match one file and not the
+other and cause get/drop to happen over and over. 
+
+But there are probably a lot of other ways this database could be used, now
+that's it's fully available. For example, it would be easy to write a
+git-annex command that queries for which worktree files use a key, without
+needing to scan the whole worktree to find them.
diff --git a/doc/devblog/day_63__leverage.mdwn b/doc/devblog/day_63__leverage.mdwn
new file mode 100644
index 0000000000..6cf8acfa25
--- /dev/null
+++ b/doc/devblog/day_63__leverage.mdwn
@@ -0,0 +1,24 @@
+The difference picking the right type can make! Last night, I realized that
+the where I had a `distributionSha256sum :: String`, I should instead use
+`distributionKey :: Key`. This means that when git-annex is eventually
+downloading an upgrade, it can treat it as just another Key being
+downloaded from the web. So the webapp will show that transfer along with
+all the rest, and I can leverage tons of code for a new purpose. For
+example, it can simply fsck the key once it's downloaded to verify its
+checksum.
+
+Also, built a DistriutionUpdate program, which I'll run to generate the
+info files for a new version. And since I keep git-annex releases in a
+git-annex repo, this too leverages a lot of git-annex modules, and ended up
+being just 60 easy lines of code. The upgrade notification code is tested
+and working now.
+
+And, I made the assistant detect when the git-annex program binary is
+replaced or modified. Used my existing DirWatcher code for that. The plan
+is to restart the assistant on upgrade, although I need to add some sanity
+checks (eg, reuse the lsof code) first. And yes, this will work even for
+`apt-get upgrade`!
+
+----
+
+Today's work was sponsored by Paul Tötterman
diff --git a/doc/devblog/day_640__finally_dealt_with_clock_skew.mdwn b/doc/devblog/day_640__finally_dealt_with_clock_skew.mdwn
new file mode 100644
index 0000000000..363ceb9af0
--- /dev/null
+++ b/doc/devblog/day_640__finally_dealt_with_clock_skew.mdwn
@@ -0,0 +1,20 @@
+I've been unsatisfied with git-annex's handling of clock skew since day 1.
+Since it relies on timestamps, it needs clocks to be synchronised across
+users, at least to a reasonable extent. A clock in the far future or distant
+past could potentially confuse git-annex a lot. Vector clocks felt like
+the right kind of solution, but also wrong somehow.
+
+I've finally cracked it! See [[todo/git-annex_branch_clocks]] for the
+details, but in summary, git-annex will be able to detect clock skew
+and fall back to vector clocks, but will otherwise continue to use
+timestamps for their benefits over vector clocks
+(ie, having some idea about what order disconnected events actually occurred,
+to the extent physics makes that possible).
+
+That is mostly implemented, only needs some more testing and cleanup before
+merging.
+
+----
+
+Today's work was sponsored by Graham Spencer 
+[on Patreon](https://patreon.com/joeyh)
diff --git a/doc/devblog/day_641__an_alternative_smudge_filter.mdwn b/doc/devblog/day_641__an_alternative_smudge_filter.mdwn
new file mode 100644
index 0000000000..ec590b02d8
--- /dev/null
+++ b/doc/devblog/day_641__an_alternative_smudge_filter.mdwn
@@ -0,0 +1,26 @@
+Would you rather that `git checkout` got a lot faster at checking out a lot
+of files, and `git add` got a lot faster at adding a lot of small files, if
+the tradeoff was that `git add` and `git commit -a` got slower at adding
+large files to the annex than they are now?
+
+Being able to make that choice is what I'm working on now. Of course,
+we'd rather it were all fast, but due to 
+[[todo/git_smudge_clean_interface_suboptiomal]], that is not possible
+without improvements to git. But I seem to have a plan that will
+work around enough of the problems to let that choice be made.
+
+Today I've been laying the groundwork, by implementing git's
+pkt-line interface, and the long-running filter process protocol.
+Next step will be to add support for that in `git-annex smudge`,
+so that users who want to can enable it with:
+
+	git config filter.annex.process 'git-annex filter-process'
+
+I can imagine that becoming enabled by default at some point in v9, if most
+users prefer it over the current method. Which would still be available
+by unsetting the config.
+
+----
+
+Today's work was sponsored by Mark Reidenbach
+[on Patreon](https://patreon.com/joeyh)
diff --git a/doc/devblog/day_641__an_alternative_smudge_filter/comment_1_ab7bbff67f34e217df5f0e75dedb7f2c._comment b/doc/devblog/day_641__an_alternative_smudge_filter/comment_1_ab7bbff67f34e217df5f0e75dedb7f2c._comment
new file mode 100644
index 0000000000..dd4f590db4
--- /dev/null
+++ b/doc/devblog/day_641__an_alternative_smudge_filter/comment_1_ab7bbff67f34e217df5f0e75dedb7f2c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2021-11-08T16:34:29Z"
+ content="""
+These changes would not affect locked-files-only repos, correct?
+"""]]
diff --git a/doc/devblog/day_641__an_alternative_smudge_filter/comment_2_9bc08810306ceb39ed1f017e9f1d81e3._comment b/doc/devblog/day_641__an_alternative_smudge_filter/comment_2_9bc08810306ceb39ed1f017e9f1d81e3._comment
new file mode 100644
index 0000000000..658643bc83
--- /dev/null
+++ b/doc/devblog/day_641__an_alternative_smudge_filter/comment_2_9bc08810306ceb39ed1f017e9f1d81e3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-11-08T20:21:29Z"
+ content="""
+If you have all locked files, git will never run the smudge/clean filter,
+so its performance will not matter to you. If you have non-annexed files
+in git, it does run the filter on those though, and this will improve
+that case.
+"""]]
diff --git a/doc/devblog/day_641__an_alternative_smudge_filter/comment_3_b9ffc711b4531b6f2b4af4efd1e9d9d6._comment b/doc/devblog/day_641__an_alternative_smudge_filter/comment_3_b9ffc711b4531b6f2b4af4efd1e9d9d6._comment
new file mode 100644
index 0000000000..0b9e5f667f
--- /dev/null
+++ b/doc/devblog/day_641__an_alternative_smudge_filter/comment_3_b9ffc711b4531b6f2b4af4efd1e9d9d6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="clarification re: smudge filter and annex.supportunlocked"
+ date="2021-11-09T18:28:09Z"
+ content="""
+> If you have non-annexed files in git, it does run the filter on those
+
+Not when `annex.supportunlocked=false`, right?   (Of course, that's not the default setting, so the smudge filter changes will still help by default.)
+
+
+"""]]
diff --git a/doc/devblog/day_641__an_alternative_smudge_filter/comment_4_b2a0a8f646197ce1826bc2e6859139b1._comment b/doc/devblog/day_641__an_alternative_smudge_filter/comment_4_b2a0a8f646197ce1826bc2e6859139b1._comment
new file mode 100644
index 0000000000..661fd62e67
--- /dev/null
+++ b/doc/devblog/day_641__an_alternative_smudge_filter/comment_4_b2a0a8f646197ce1826bc2e6859139b1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-11-09T19:53:38Z"
+ content="""
+Right, annex.supportunlocked avoids all these performance considerations.
+
+But, it seems possible that enabling filter-process will speed it up enough
+to not need annex.supportunlocked. I'd be interested to know if that works
+for you.
+"""]]
diff --git a/doc/devblog/day_641__an_alternative_smudge_filter/comment_5_6a5932706a9fee097c3fdf2cd6808f1d._comment b/doc/devblog/day_641__an_alternative_smudge_filter/comment_5_6a5932706a9fee097c3fdf2cd6808f1d._comment
new file mode 100644
index 0000000000..2c8343980c
--- /dev/null
+++ b/doc/devblog/day_641__an_alternative_smudge_filter/comment_5_6a5932706a9fee097c3fdf2cd6808f1d._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="comment 5"
+ date="2022-07-06T05:04:07Z"
+ content="""
+Until this is ready, at the moment, I got around the slowness [by setting](https://github.com/neuropoly/intranet.neuro.polymtl.ca/blob/d5c320c/geek-tips/git-annex.md#new-repo)
+
+```
+cat > .gitattributes <<EOF
+*.mkv   filter=anex annex.largefiles=anything
+*.mp3   filter=anex annex.largefiles=anything
+EOF
+```
+
+This way the file size is ignored and instead git makes the decision for me based on file extension. This is much faster than running every file through `git annex smudge`. I'
+
+I might end up sticking with this even if you use the faster filter API.
+"""]]
diff --git a/doc/devblog/day_641__an_alternative_smudge_filter/comment_6_ad1d78a28887af24d77b2b9e3739b68a._comment b/doc/devblog/day_641__an_alternative_smudge_filter/comment_6_ad1d78a28887af24d77b2b9e3739b68a._comment
new file mode 100644
index 0000000000..e7abc96774
--- /dev/null
+++ b/doc/devblog/day_641__an_alternative_smudge_filter/comment_6_ad1d78a28887af24d77b2b9e3739b68a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="prancewit"
+ avatar="http://cdn.libravatar.org/avatar/f6cc165b68a5cca3311f9a1cd7fd027c"
+ subject="comment 6"
+ date="2022-09-13T11:19:53Z"
+ content="""
+This is probably waaaaay too late but I wanted to chime in with my 2 cents to the question from Joey.
+
+My personal preference would be to optimize for large files as opposed to many small files. My reasoning is that we can work around the many small files being slow issue by tar-ing them. This is also IMO usually the better option (at least for me) since we rarely have use cases where we have a gajillion small files that directly need to be accessible.
+
+"""]]
diff --git a/doc/devblog/day_641__an_alternative_smudge_filter/comment_7_3107429d7250a71584ea7947609207ec._comment b/doc/devblog/day_641__an_alternative_smudge_filter/comment_7_3107429d7250a71584ea7947609207ec._comment
new file mode 100644
index 0000000000..4d3795f1c9
--- /dev/null
+++ b/doc/devblog/day_641__an_alternative_smudge_filter/comment_7_3107429d7250a71584ea7947609207ec._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="many small files"
+ date="2022-09-13T17:20:45Z"
+ content="""
+>we rarely have use cases where we have a gajillion small files that directly need to be accessible
+
+Scientific datasets often do have many small files, e.g. the results of computing something for many subsets of data under many combinations of parameter settings.
+The files need to be directly accessible so that downstream analysis tools can read them.
+
+"""]]
diff --git a/doc/devblog/day_641__an_alternative_smudge_filter/comment_8_45f97189936e7f477850aef9ef745538._comment b/doc/devblog/day_641__an_alternative_smudge_filter/comment_8_45f97189936e7f477850aef9ef745538._comment
new file mode 100644
index 0000000000..ef3834a07c
--- /dev/null
+++ b/doc/devblog/day_641__an_alternative_smudge_filter/comment_8_45f97189936e7f477850aef9ef745538._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="re: many small files"
+ date="2022-09-13T17:28:29Z"
+ content="""
+OTOH, I've found myself using only locked annexed files for datasets, and [[projects/datalad]] does the same.  But there are reasons others might want to use unlocked files for that.
+"""]]
diff --git a/doc/devblog/day_641__an_alternative_smudge_filter/comment_9_3129a6da37ba7a1f8ee11441b7ed4d07._comment b/doc/devblog/day_641__an_alternative_smudge_filter/comment_9_3129a6da37ba7a1f8ee11441b7ed4d07._comment
new file mode 100644
index 0000000000..2c0bf035c7
--- /dev/null
+++ b/doc/devblog/day_641__an_alternative_smudge_filter/comment_9_3129a6da37ba7a1f8ee11441b7ed4d07._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-09-13T18:15:19Z"
+ content="""
+This has been implemented for a while, see [[day_642__cost_model]]
+for how I got around the dilemma. Upgrade to repository v9 to use it.
+"""]]
diff --git a/doc/devblog/day_642__cost_model.mdwn b/doc/devblog/day_642__cost_model.mdwn
new file mode 100644
index 0000000000..4ea5ed2ab5
--- /dev/null
+++ b/doc/devblog/day_642__cost_model.mdwn
@@ -0,0 +1,28 @@
+Last Thursday I implemented `git-annex filter-process`, which you
+can try enabling to make commands like `git add` and `git checkout`
+faster when they operate on a lot of files.
+
+	git config filter.annex.process 'git-annex filter-process'
+
+On Friday, I benchmarked it
+and was not surprised to find that it's slower in some cases than the
+old smudge/clean filter interface, and faster in other cases. Still, good
+to see actual numbers (see [[!commit 054c803f8d7cc43eb01fdf6141ab6572373c7d60]]).
+The surprising good news is that it only seems to make `git add` around 10%
+slower when adding a large file (to the annex presumably). Although I
+know I can speed that up, eventually.
+
+Today, I used the benchmark results to build a cost model into git-annex,
+so it knows when it would be faster to have filter.annex.process set or
+unset, and temporarily unsets it when that seems best. It can only
+do that when it's restaging pointer files, but that was the main problem
+with setting filter.annex.process really.
+
+So I'm fairly close to wanting to enable it by default. But will probably
+just wait until whenever v9 happens and do it then. Hopefully some people
+will try it out in the meantime and perhaps I can refine the cost model.
+
+---
+
+This work was sponsored by Jake Vosloo, Graham Spencer, and Dr. Land Raider
+[on Patreon](https://patreon.com/joeyh)
diff --git a/doc/devblog/day_642__cost_model/comment_1_36ecaafc1d7f6460758d6824a357432c._comment b/doc/devblog/day_642__cost_model/comment_1_36ecaafc1d7f6460758d6824a357432c._comment
new file mode 100644
index 0000000000..64b9ca7775
--- /dev/null
+++ b/doc/devblog/day_642__cost_model/comment_1_36ecaafc1d7f6460758d6824a357432c._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 1"
+ date="2021-11-09T08:48:33Z"
+ content="""
+My first impression of commit [[!commit a0758bdd1002e798f62353efa725ac2972589b96]] with the cost model
+is quite positive as I'm the one with multigigabyte annexed files in his otherwise rather small (by number of files)
+repo and thus I'm affected by the limitations of the filter-process method which pipes all the content of annexed
+files from git to git-annex. Compared to commit [[!commit 837025b14f523f9180f82d0cced1e53a8a9b94de]], which frankly
+for me was unusable in this particular repo with `filter.annex.process` set, the new version behaves rather nicely
+in that a simple test of `time git checkout git-annex` followed by
+`time git checkout 'adjusted/master(hidemissing-unlocked)'` turns out to be faster than using an unoptimised version
+(=8.20211028) without the long-running `filter-process` functionality. Obviously, it's only the first stage,
+i.e. checking out the git-annex branch, that becomes faster by over 50 percentage points but I'll take any improvement
+in my daily git-annex operations. :)
+
+The timings I got are as follows.
+
+* `git checkout git-annex`
+  - unoptimised 8.20211028 / w/o `filter-process`: 103s
+  - commit 837025b14 / w/ `filter-process` enabled: 36s
+  - commit 9d3ce224e / w/ `filter-process` enabled: 37s
+* `git checkout 'adjusted/master(hidemissing-unlocked)'`
+  - unoptimised 8.20211028 / w/o `filter-process`: 49s
+  - commit 837025b14 / w/ `filter-process` enabled: 57 minutes (I had dropped a few files, in reality this would've taken even longer)
+  - commit 9d3ce224e / w/ `filter-process` enabled: 43s
+
+This repo is on Windows (with annex.thin set) and locally has only 13 annexed files on this very drive but the files
+cover some 870 gigabytes worth of system backup images so individual files are definitely on the larger side for
+git-annex.
+
+"""]]
diff --git a/doc/devblog/day_642__cost_model/comment_2_5bb7a20dd3141423ce4109d8fd4098c4._comment b/doc/devblog/day_642__cost_model/comment_2_5bb7a20dd3141423ce4109d8fd4098c4._comment
new file mode 100644
index 0000000000..53d5450178
--- /dev/null
+++ b/doc/devblog/day_642__cost_model/comment_2_5bb7a20dd3141423ce4109d8fd4098c4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-11-09T19:55:51Z"
+ content="""
+Thanks @jkniiv, that's good to hear. That is exactly the results I would
+have hoped for for a repository like yours. To speed up the checkout
+of the annexed files in your case will need improvements to git,
+probably. But the crucial thing is it's not gotten worse, and the other
+checkout improved a lot.
+
+I would be curious how you find `git add`'s performance now, if you ever
+use that to add large annexed files.
+"""]]
diff --git a/doc/devblog/day_643__adjusted_view_branches.mdwn b/doc/devblog/day_643__adjusted_view_branches.mdwn
new file mode 100644
index 0000000000..7e71c30a8e
--- /dev/null
+++ b/doc/devblog/day_643__adjusted_view_branches.mdwn
@@ -0,0 +1,38 @@
+(Tap tap. Oh, this devblog is still on?)
+
+View branches are a neat corner of git-annex that have remained kind of
+obscure since I implemented them back in 2014. Not many improvements
+have been made from back then until recently.
+
+Today I implemented a longstanding todo, unifying view branches with
+adjusted branches. The result is that you can enter an adjusted branch from
+a view branch, or a view branch from an adjusted branch, and get what you
+would probably expect.
+
+For example, to sort your annexed files into directories by author and
+year, and have all annexed files in the view be unlocked:
+
+    git-annex adjust --unlock
+    git-annex view author=* year=*
+
+Earlier this month, I addressed probably the main missing feature of view
+branches, by making `git-annex sync` work in a view branch, updating it
+with metadata and files pulled in from remotes. Although 
+it there is room to make it 
+[[faster|faster_incremental_update_of_view_branch_by_git-annex_sync]]
+still.
+
+Also, view branches can be made that include files that lack metadata.
+Such files are put in a directory named `"_"`. And can be moved out of
+there to other directories to set their metadata. For example:
+
+    git-annex view author?=*
+
+Views combine nicely with graphical file managers, and Yann Büchau
+has recently built an 
+[integration with Thunar](https://pypi.org/project/thunar-plugins/)
+that supports most of these new features and can be seen in action in
+[this screencast](https://fosstodon.org/@nobodyinperson/109836827575976439).
+
+This work was sponsored by Lawrence Brogan, Erik Bjäreholt, and unqueued
+[on Patreon](https://patreon.com/joeyh)
diff --git a/doc/devblog/day_643__adjusted_view_branches/comment_1_5f2dfde34d4ef5048920f3fcabddbd56._comment b/doc/devblog/day_643__adjusted_view_branches/comment_1_5f2dfde34d4ef5048920f3fcabddbd56._comment
new file mode 100644
index 0000000000..5bf60226bf
--- /dev/null
+++ b/doc/devblog/day_643__adjusted_view_branches/comment_1_5f2dfde34d4ef5048920f3fcabddbd56._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="dud225@35a1ee469f82f3a7eb1f2dce4ad453f5e47bdfd3"
+ nickname="dud225"
+ avatar="http://cdn.libravatar.org/avatar/5147563e50c475918474594d93be95c2"
+ subject="?=*"
+ date="2023-06-27T07:59:55Z"
+ content="""
+Regarding the expression that allows to include the files that are missing the proper metadata:
+
+    git-annex view author?=*
+
+It's not working on my side, which version is bringing that feature? I don't see it mentioned in the [changelogs](https://git-annex.branchable.com/news/).
+
+> Yann Büchau has recently built an integration with Thunar 
+
+I'm not using Thunar but I have to admit that this plugin is awesome!
+"""]]
diff --git a/doc/devblog/day_643__adjusted_view_branches/comment_2_51e285666d42e08edbaf22699782392e._comment b/doc/devblog/day_643__adjusted_view_branches/comment_2_51e285666d42e08edbaf22699782392e._comment
new file mode 100644
index 0000000000..eedc602074
--- /dev/null
+++ b/doc/devblog/day_643__adjusted_view_branches/comment_2_51e285666d42e08edbaf22699782392e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-06-28T17:06:45Z"
+ content="""
+@dud225 that came in 10.20230214 which is too old for the news page, but
+you can find it in the [full CHANGELOG](http://source.git-annex.branchable.com/?p=source.git;a=blob;f=CHANGELOG;h=f5ec8192765fc403c340f74f1bcfde765e470ef7;hb=HEAD#l189)
+"""]]
diff --git a/doc/devblog/day_644-648__terminal_escape_sequences.mdwn b/doc/devblog/day_644-648__terminal_escape_sequences.mdwn
new file mode 100644
index 0000000000..767e239068
--- /dev/null
+++ b/doc/devblog/day_644-648__terminal_escape_sequences.mdwn
@@ -0,0 +1,46 @@
+Last weekend I watched a talk
+["Houdini of the Terminal: The need for escaping"](https://www.youtube.com/watch?v=4kfDBNzStbs)
+which shows several recent exploits of terminal emulators using escape
+sequences. It was eye opening that security holes like that are still 
+being found, and also how severe some of the results can be. I was already
+familiar with escape sequences as a potential security hole, but it never
+seemed to make sense to have a program that was not a terminal emulator
+guard against them. This talk made me think it can make sense for some
+programs, as a defence in depth.
+
+Now git does escape unusual characters when displaying filenames (most of
+the time). But git-annex never has. So it seems it would be a good idea to
+make git-annex follow git's lead on this. And git has a core.quotePath
+which can be used to make it not escape unicode characters, so git-annex
+should also support that.
+
+Implementing that was not very easy, because there are a vast number of
+places where git-annex can display a filename. I had to check every error
+message and warning message and other output in the whole code base to find
+ones that displayed a filename. That took a while.
+
+While doing that, I realized that there are some other ways a control
+character could be stored in the git repository that would cause git-annex
+to display it. It's possible for a git-annex key to have a control
+character in its name. And a few other things stored in the git-annex
+branch, like metadata, could also contain control characters.
+
+I decided the best way to deal with those is not with some complex
+escaping, but just by filtering out the control characters on output. In fact,
+git-annex now filters out control characters in basically all its output.
+The exceptions are some cases where filtering is not done when it's outputting
+to a pipe, and that commands like `git-annex find` that support `--format` 
+only do escaping when requested by the format.
+
+By the way, it turns out that git will display control characters in
+the names of remotes or branches. Possibly in other situations too.
+(I do wonder if a git remote that uses control characters in a branch
+could be used to exploit a terminal emulator?) So git-annex has now gone
+further than git in this area.
+
+The resulting diff is 6500 lines, and I don't consider this an actual
+security fix in git-annex, but only a hardening measure. So I won't be
+hurrying out the next release for this.
+
+This work was sponsored by Jake Vosloo, unqueued, Graham Spencer,
+and Erik Bjäreholt [on Patreon](https://patreon.com/joeyh)
diff --git a/doc/devblog/day_649-650__speeding_up_repeated_imports.mdwn b/doc/devblog/day_649-650__speeding_up_repeated_imports.mdwn
new file mode 100644
index 0000000000..13a6d09c30
--- /dev/null
+++ b/doc/devblog/day_649-650__speeding_up_repeated_imports.mdwn
@@ -0,0 +1,30 @@
+Importing trees from special remotes still feels a bit like a new feature,
+although it was added to git-annex in 2019. I don't know if many people are
+using it. I've had some complaints about it being slow when the remote
+contains a large number of files (eg 100 thousand).
+
+I've just finished speeding up repeated imports from a special remote a
+lot, when the special remote contains a large number of files, and few or
+no files have changed.
+
+git-annex was spending a lot of time converting content identifiers to
+keys. Each conversion took a database lookup, which was slow enough to
+become painful in bulk.
+
+I thought of a neat trick. Take the sha1 of a content identifier, and
+create a git tree of the files in the special remote, using those sha1s as
+the content of the files. Of course, that is not the actual content of any
+file that git knows about. But it doesn't matter, because once git-annex
+has those trees, it can diff the current tree to the tree from the previous
+import. And that tells it which files have changed. Then it only has to do
+database lookups for the changed files.
+
+This turned out to be one of the best results I've ever gotten from a
+git-annex optimisation. It runs 60x faster or more with more files!
+
+The moral is that git is really good at diffing trees fast, and so it's
+worth using git diff whenever possible, even if the thing being diffed is
+not a regular tree of files.
+
+This work was sponsored by Mark Reidenbach and Lawrence Brogan
+[on Patreon](https://patreon.com/joeyh)
diff --git a/doc/devblog/day_64__overkill.mdwn b/doc/devblog/day_64__overkill.mdwn
new file mode 100644
index 0000000000..fd5d66f4ec
--- /dev/null
+++ b/doc/devblog/day_64__overkill.mdwn
@@ -0,0 +1,31 @@
+Completely finished up with making the assistant detect when git-annex's
+binary has changed and handling the restart.
+
+It's a bit tricky because during an upgrade there can be two assistant
+daemons running at the same time, in the same repository. Although I
+disable the watcher of the old one first. Luckily, git-annex has long
+supported running multiple concurrent git-annex processes in the same
+repository.
+
+The surprisingly annoying part turned out to be how to make the webapp
+redirect the browser to the new url when it's upgraded. Particularly needed
+when automatic upgrades are enabled, since the user will not then be taking
+any action in the webapp that could result in a redirect. My solution to this
+feels like overkill; the webapp does ajax long polling until it gets an
+url, and then redirects to it. Had to write javascript code and ugh.
+
+But, that turned out to also be useful when manually restarting the webapp
+(removed some horrible old code that ran a shell script to do it before),
+and also when shutting the webapp down.
+
+[[!img assistant/downloadupgrade.png alt="assistant downloading an upgrade to itself"]]
+
+Getting back to upgrades, I have the assistant downloading the upgrade, and
+running a hook action once the key is transferred. Now all I need is some
+platform-specific code to install it. Will probably be hairy, especially on
+OSX where I need to somehow unmount the old git-annex dmg and mount the new
+one, from within a program running on the old dmg.
+
+----
+
+Today's work was sponsored by Evan Deaubl.
diff --git a/doc/devblog/day_64__overkill/comment_1_e1db7678aae37af281d31ae211677786._comment b/doc/devblog/day_64__overkill/comment_1_e1db7678aae37af281d31ae211677786._comment
new file mode 100644
index 0000000000..b04af39ffb
--- /dev/null
+++ b/doc/devblog/day_64__overkill/comment_1_e1db7678aae37af281d31ae211677786._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="abg"
+ ip="184.75.210.234"
+ subject="Upgrade installation in OSX"
+ date="2013-11-24T00:28:03Z"
+ content="""
+Hey,
+
+You don't have to implement any whacky DMG replacement logic for OSX upgrades. No sane user will be using the application from the DMG. They will drag the .app directory to /Applications or some non-standard location and unmount the DMG.  So your upgrade logic for OSX should end up looking very similar to the upgrade logic for Linux.
+"""]]
diff --git a/doc/devblog/day_64__overkill/comment_3_f7a96f0b6d942d0b59d9d0ec1b21c4bf._comment b/doc/devblog/day_64__overkill/comment_3_f7a96f0b6d942d0b59d9d0ec1b21c4bf._comment
new file mode 100644
index 0000000000..c9e76b577e
--- /dev/null
+++ b/doc/devblog/day_64__overkill/comment_3_f7a96f0b6d942d0b59d9d0ec1b21c4bf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmuh_0-Mjz7QkVz7gT_7PRpCgmMcBFkj14"
+ nickname="Wichert"
+ subject="Running from DMG is not a sane use-case"
+ date="2013-11-25T08:23:38Z"
+ content="""
+I don't think you should bother trying to support upgrades when people are running from a dmg. A DMG is just a disk image, and a format commonly used to distribute software. Running software from a DMG is not something anyone does beyond a quick first test of an application. A more reasonable thing to do, which many applications do now, is to offer to move the application from the DMG to /Applications if you detect someone is running it from a DMG.
+"""]]
diff --git a/doc/devblog/day_651__a_major_release__and_a_conference.mdwn b/doc/devblog/day_651__a_major_release__and_a_conference.mdwn
new file mode 100644
index 0000000000..ab256f3774
--- /dev/null
+++ b/doc/devblog/day_651__a_major_release__and_a_conference.mdwn
@@ -0,0 +1,17 @@
+Today I'm releasing git-annex 10.20230626. This release got delayed for 2
+months due to making some breaking changes in how filenames with unusual
+characters are quoted. So it has an unsual amount of changes in it, and is
+as major as a git-annex release gets without being a repository version
+bump.
+
+But I mostly wanted to announce that we are planning a joint git-annex/Datalad meeting!
+In the first half of 2024, probably in Germany. If you would be interested in
+attending, please fill out this 
+[brief survey](https://docs.google.com/forms/d/e/1FAIpQLSf0PVLyzicTnAIz8dN7PrT8runUl2W9QxSWCzZoEW3x5bD9lA/viewform).
+While Datalad is aimed at scientists, and I look forward to spending time
+with them, you do not have to be a scientist to attend, any interested
+users are welcome.
+
+Also, if you'd like to learn about git-annex in Germany this weekend,
+Yann Büchau is hosting a
+[workshop](https://cfp.tuebix.org/tuebix-2023/talk/review/GWRP3UKE3VFKVDG8RNQ8ZZPCZPNZYYWM).
diff --git a/doc/devblog/day_65__wrapping_up_upgrades.mdwn b/doc/devblog/day_65__wrapping_up_upgrades.mdwn
new file mode 100644
index 0000000000..9faa31a63c
--- /dev/null
+++ b/doc/devblog/day_65__wrapping_up_upgrades.mdwn
@@ -0,0 +1,5 @@
+[[!img assistant/upgradecomplete.png]]
+
+Upgrades are fully working on Linux. OSX code is written but intested and I
+thought of one bug it certainly has on my evening walk. Probably another
+hour's work left later this evening to finish it off.
diff --git a/doc/devblog/day_66__upgrade_testing.mdwn b/doc/devblog/day_66__upgrade_testing.mdwn
new file mode 100644
index 0000000000..741ec494ee
--- /dev/null
+++ b/doc/devblog/day_66__upgrade_testing.mdwn
@@ -0,0 +1,17 @@
+Upgrades should be working on OSX Mavericks, Linux, and sort of on Android.
+This needs more testing, so I have temporarily made the daily builds think
+they are an older version than the last git-annex release. So when you
+install a daily build, and start the webapp, it should try to upgrade
+(really downgrade) to the last release. Tests appreciated.
+
+Looking over the whole upgrade code base, it took 700 lines of code
+to build the whole thing, of which 75 are platform specific (and mostly
+come down to just 3 or 4 shell commands). Not bad..
+
+----
+
+Last night, added support for quvi 0.9, which has a completely changed
+command line interface from the 0.4 version.
+
+Plan to spend tomorrow catching up on bug reports etc and then low activity
+for rest of the week.
diff --git a/doc/devblog/day_67_thanksgiving_rush.mdwn b/doc/devblog/day_67_thanksgiving_rush.mdwn
new file mode 100644
index 0000000000..7ac6ba523f
--- /dev/null
+++ b/doc/devblog/day_67_thanksgiving_rush.mdwn
@@ -0,0 +1,19 @@
+My last day before thanksgiving, getting caught up with some recent bug
+reports and, quite a rush to get a lot of fixes in. Adding to the fun,
+wintery weather means very limited power today.
+
+It was a very productive day, especially for Android, which hopefully has
+XMPP working again (at least it builds..), halved the size of the package,
+etc.
+
+Fixed a stupid bug in the automatic v5 upgrade code; annex.version was not
+being set to 5, and so every git annex command was
+actually re-running the upgrade.
+
+Fixed another bug I introduced last Friday, which the test suite luckily
+caught, that broke using some local remotes in direct mode.
+
+Tracked down a behavior that makes `git annex sync` quite slow on
+filesystems that don't support symlinks. I need to switch direct mode to 
+not using `git commit` at all, and use plumbing to make commits there.
+Will probably work on this over the holiday.
diff --git a/doc/devblog/day_68__bits_and_pieces.mdwn b/doc/devblog/day_68__bits_and_pieces.mdwn
new file mode 100644
index 0000000000..1caa6e38bb
--- /dev/null
+++ b/doc/devblog/day_68__bits_and_pieces.mdwn
@@ -0,0 +1,14 @@
+Made a release yesterday to fix a bug that made git-annex init in a bare
+repository set core.bare=false. This bug only affected git-annex 5, it
+was introduced when building the direct mode guard. Currently recovering
+from it is a [manual (pretty easy) process](http://git-annex.branchable.com/bugs/assistant_creating_.git_directory_inside_bare_repo/#comment-73a8ce8aa100baa7c03861b769fdca29).
+Perhas I should automate that, but I mostly wanted to get a fix out
+before too many people encountered the bug.
+
+Today, I made the assistant run batch jobs with ionice and nocache, when
+those commands are available. Also, when the assistant transfers files,
+that also runs as a batch job.
+
+Changed how git-annex does commits, avoiding using `git commit` in direct
+mode, since in some situations `git commit` (not with `-a`!) wants to
+read the contents of files in the work tree, which can be very slow.
diff --git a/doc/devblog/day_69__catching_up.mdwn b/doc/devblog/day_69__catching_up.mdwn
new file mode 100644
index 0000000000..45b1e38e6c
--- /dev/null
+++ b/doc/devblog/day_69__catching_up.mdwn
@@ -0,0 +1,14 @@
+Still working through thanksgiving backlog. Around 55 messages to go.
+
+Wrote hairy code to automatically fix up bad bare repositories created by
+recent versions of git-annex. Managed to do it with only 1 stat call
+overhead (per local repository). Will probably keep that code in git-annex
+for a year or so, despite the bug only being present for a few weeks,
+because the repositories that need to be fixed might be on removable drives
+that are rarely used.
+
+Various other small bug fixes, including dealing with box.com having
+changed their WebDAV endpoint url.
+
+Spent a while evaluating various key/value storage possibilities. 
+[[bugs/incremental_fsck_should_not_use_sticky_bit]] has the details.
diff --git a/doc/devblog/day_6__gcrypt_fully_working.mdwn b/doc/devblog/day_6__gcrypt_fully_working.mdwn
new file mode 100644
index 0000000000..58abdbb602
--- /dev/null
+++ b/doc/devblog/day_6__gcrypt_fully_working.mdwn
@@ -0,0 +1,8 @@
+gcrpyt is fully working now. *Most* of the examples in
+[[tips/fully_encrypted_git_repositories_with_gcrypt]] should work.
+
+A few known problems:
+
+* `git annex sync` refuses to sync with gcrypt remotes. some url parsing issue.
+* Swapping two drives with gcrypt repositories on the same mount point doesn't work yet.
+* http urls are not supported
diff --git a/doc/devblog/day_6__gcrypt_fully_working/comment_1_136bb7537a9ba93d400ce6f6ea1932ac._comment b/doc/devblog/day_6__gcrypt_fully_working/comment_1_136bb7537a9ba93d400ce6f6ea1932ac._comment
new file mode 100644
index 0000000000..adb298fd33
--- /dev/null
+++ b/doc/devblog/day_6__gcrypt_fully_working/comment_1_136bb7537a9ba93d400ce6f6ea1932ac._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="82.36.235.9"
+ subject="Converting an rsync special remote to a gcrypt special remote"
+ date="2013-09-11T17:36:09Z"
+ content="""
+I'm guessing there is no way to convert an rsync special remote to a gcrypt special remote?  It would be cool not to have to upload 100GB across the Atlantic again!
+"""]]
diff --git a/doc/devblog/day_6__gcrypt_fully_working/comment_2_1f8faa65bbd56a12588b43a5bc822d96._comment b/doc/devblog/day_6__gcrypt_fully_working/comment_2_1f8faa65bbd56a12588b43a5bc822d96._comment
new file mode 100644
index 0000000000..a6859cf2f7
--- /dev/null
+++ b/doc/devblog/day_6__gcrypt_fully_working/comment_2_1f8faa65bbd56a12588b43a5bc822d96._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.51"
+ subject="comment 2"
+ date="2013-09-12T16:53:02Z"
+ content="""
+Well, rsync and gcrypt use the same locations for annexed content, so it's theoretically possible.
+
+However, it seems a lot easier to just add a gcrypt remote and let git-annex use the existing rsync remote for the content that is already stored in it.
+"""]]
diff --git a/doc/devblog/day_70__preliminary_user_survey_analysis.mdwn b/doc/devblog/day_70__preliminary_user_survey_analysis.mdwn
new file mode 100644
index 0000000000..0202d6c4af
--- /dev/null
+++ b/doc/devblog/day_70__preliminary_user_survey_analysis.mdwn
@@ -0,0 +1,104 @@
+The [2013 git-annex user survey](http://git-annex-survey.branchable.com/polls/2013/)
+has been running for several weeks and around 375 people have answered
+at least the first question. While I am going to leave it up through the
+end of the year, I went over the data today to see what interesting
+preliminary conclusions I can draw.
+
+* 11% build git-annex from source. More than I would have guessed.
+
+* 20% use the prebuilt versions from the git-annex website.
+  
+  This is a number to keep in mind later, when more people have upgraded to
+  the last release, which checks for upgrades. I can run some stats on
+  the number of upgrade checks I receive, and multiplying that by 5 would
+  give a good approximation of the total number of computers running
+  git-annex.
+
+* I'm surprised to see so many more Linux (79%) than OSX (15%) users.
+  Also surprising is there are more Windows (2%) than Android (1%) users.
+  (Android numbers may be artificially low since many users will use it in
+  addition to one of the other OSes.)
+
+* Android and Windows unsurprisingly lead in ports requested, but the 
+  Synology NAS is a surprise runner up, with 5% (more than IOS).
+
+  In theory it would not be too hard to make a standalone arm tarball,
+  which could be used on such a device, although IIRC the Synology had
+  problems with a too old linker and libc. It would help if I could make
+  the standalone tarball not depend on the system linker at all.
+  
+  A susprising number (3%) want some kind of port the the Raspberry Pi, which
+  is weird because I'd think they'd just be using Raspbian on it.. but a
+  standalone arm tarball would also cover that use case.
+
+* A minimum of 1664 (probably closer to 2000) git annex repositories are being
+  used by the 248 people who answered that question. Around 7 repositories
+  per person average, which is either one repository checked out on 7
+  different machines or two repositories on 3 machines, etc.
+
+* At least 143 terabytes of data are being stored in git-annex. This does
+  not count redundant data. (It also excludes several hundred terabytes from
+  one instituion that I don't think are fully online yet.)
+  Average user has more than half a terabyte of data.
+
+* 8% of users store scientific data in git-annex! :) A couple of users are
+  using it for game development assets, and 5% of users are using it for
+  some form of business data.
+
+* Only 10% of users are sharing a git-annex repository with at least one
+  other person. 27% use it by themselves, but want to get others using
+  their repositories. This probably points to it needing to be easier for
+  nontechnical users.
+
+* 61% of git-annex users have good or very good knowledge of git.
+  This question intentionally used the same wording as the 
+  [general git user survey](https://git.wiki.kernel.org/index.php/GitSurvey2012),
+  so the results can be compared. The curves have somewhat different
+  shapes, with git-annex's users being biased more toward the higher
+  knowledge levels than git's users.
+
+* The question about how happy users are also used the same wording.
+  While 74% of users are happy with git-annex, 94% are similarly happy with
+  git, and a while the median git-annex user is happy, the median git user
+  is very happy.
+  
+  The 10% who wrote in "very enthusiastic, but still often
+  bitten by quirks (so not very happy yet, but with lots of confidence in
+  the potential" might have thrown off this comparison some, but they
+  certianly made their point!
+
+* 3% of respondants say that a bug is preventing them from using git-annex,
+  but that they have not reported the bug yet. Frustrating! 1% say that a
+  bug that's been reported already is blocking them.
+
+* 18% wrote in that they need the webapp to support using github (etc)
+  as a central server. I've been moving in that direction with the
+  encryption and some other changes, so it's probably time to make a UI for
+  that.
+
+* 12% want more control over which files are stored locally when using the
+  assistant.
+
+* A really surprising thing happened when someone wrote in that I should
+  work on "not needing twice disk space of repo in direct mode", and 5% of
+  people then picked this choice. This is some kind of documentation
+  problem, because of course git-annex never needs 2x disk space, whether
+  using direct mode or not. That's one of its advantages over git!
+
+* Somewhere between 59 and 161 of the survey respondants use Debian.
+  I can compare this with [Debian popularity contest data](http://qa.debian.org/popcon-graph.php?packages=git-annex)
+  which has 400 active installations and 1000 total installations,
+  and make guesses about what fraction of all git-annex users have answered
+  the survey. By making different assumptions I got guesses that varied by
+  2 orders of magnitude, so not worth bothering with. Explicitly asking how
+  many people use each Linux distribution would be a good idea in next
+  year's survey.
+
+----
+
+Main work today was fixing Android DNS lookups, which was trying to use
+/etc/resolv.conf to look up SRV records for XMPP, and had to be changed to
+use a getprop command instead. Since I can't remember dealing with this
+before (not impossible I made some quick fix to the dns library before and
+lost it though), I'm wondering if XMPP was ever usable on Android before.
+Cannot remember. May work now, anyway...
diff --git a/doc/devblog/day_71__that_was_unexpected.mdwn b/doc/devblog/day_71__that_was_unexpected.mdwn
new file mode 100644
index 0000000000..92de97b7dc
--- /dev/null
+++ b/doc/devblog/day_71__that_was_unexpected.mdwn
@@ -0,0 +1,30 @@
+Had planned to spend all day not working on git-annex and instead getting
+caught up on conference videos. However, got a little bit multitasky while
+watching those, and started investigating why, last time I worked on
+Windows port, git-annex was failing to link. 
+
+A good thing to do while watching conference videos since it involved lots of 
+test builds with different flags. Eventially solved it. 
+Building w/o WebDAV avoids crashing the compiler anyhow.
+
+Thought I'd try the resulting binary and see if perhaps I had forgotten to
+use the threaded RTS when I was running ghc by hand to link it last time,
+and perhaps that was why threads
+[[seemed to have hung|day_56__git-annex_user_survey]] back then.
+
+It was. This became clear when I saw a "deadlocked indefinitely in MVar"
+error message, which tells me that it's at least using the threaded RTS.
+So, I fixed that, and a few other minor things, and ran this command
+in a DOS prompt box:
+
+	git annex watch --force --foreground --debug
+
+And I've been making changes to files in that repository, and amazingly,
+the watcher is noticing them, and committing them!
+
+So, I was almost entirely there to a windows port of the watcher a month
+ago, and didn't know. It has some rough edges, including not doing anything
+to check if a newly created file is open for write when adding it, and
+getting the full assistant ported will be more work, and the full webapp
+may be a whole other set of problems, but this is a quite nice milestone
+for the Windows port.
diff --git a/doc/devblog/day_72__windows_webapp_not.mdwn b/doc/devblog/day_72__windows_webapp_not.mdwn
new file mode 100644
index 0000000000..985afe7c42
--- /dev/null
+++ b/doc/devblog/day_72__windows_webapp_not.mdwn
@@ -0,0 +1,22 @@
+Got the entire webapp to build on Windows.
+
+Compiling was easy. One line of code had to be #ifdefed out, and the whole
+rest of the webapp UI just built!
+
+Linking was epic. It seems that I really am runninginto a 32kb command line length
+limit, which causes the link command to fail on Windows. git-annex with all
+its bells and whistles enabled is just too big. Filed a 
+[ghc bug report](https://ghc.haskell.org/trac/ghc/ticket/8596), and got back a
+helpful response about using <http://gcc.gnu.org/wiki/Response_Files> to
+work around.
+
+6 hours of slogging through compiling dependencies and fighting with
+toolchain later, I have managed to link git-annex with the webapp!
+
+The process is not automated yet. While I was able to automate
+passing gcc a @file with its parameters, gcc then calls collect2, which
+calls ld, and both are passed too many parameters. I have not found a way
+to get gcc to generate a response file. So I did it manually. Urgh.
+
+Also, it crashes on startup with `getAddrInfo` failure. But some more
+porting is to be expected, now that the windows webapp links.. ;)
diff --git a/doc/devblog/day_73__EvilLinker.mdwn b/doc/devblog/day_73__EvilLinker.mdwn
new file mode 100644
index 0000000000..68aa5d0653
--- /dev/null
+++ b/doc/devblog/day_73__EvilLinker.mdwn
@@ -0,0 +1,28 @@
+Android has the EvilSplicer, now Windows gets the EvilLinker. Fully
+automated, and truly horrible solution to the too long command line problem.
+
+Now when I run `git annex webapp` on windows, it almost manages to open
+the web browser.
+
+At the same time, I worked with Yuri to upgrade the Windows autobuilder to a
+newer Haskell platform, which can install Yesod. I have not quite achieved
+a successful webapp build on the autobuilder, but it seems close.
+
+----
+
+Here's a nice Haskell exercise for someone. I wrote this quick and dirty
+function in the EvilSplicer, but it's crying out for a generalized solution.
+
+[[!format haskell """
+{- Input contains something like 
+ - c:/program files/haskell platform/foo -LC:/Program Files/Haskell Platform/ -L...
+ - and the *right* spaces must be escaped with \
+ -
+ - Argh.
+ -}
+escapeDosPaths :: String -> String
+escapeDosPaths = replace "Program Files" "Program\\ Files"
+        . replace "program files" "program\\ files"
+        . replace "Haskell Platform" "Haskell\\ Platform"
+        . replace "haskell platform" "haskell\\ platform"
+"""]]
diff --git a/doc/devblog/day_74__so_close.mdwn b/doc/devblog/day_74__so_close.mdwn
new file mode 100644
index 0000000000..1f63eaf4d8
--- /dev/null
+++ b/doc/devblog/day_74__so_close.mdwn
@@ -0,0 +1,20 @@
+Windows webapp now starts, opens a web browser, and ... crashes. 
+
+<img src="https://identi.ca/uploads/joeyh/2013/12/7/hDkkSA.png">
+
+This  is [a bug in warp](https://github.com/yesodweb/wai/issues/202)
+or a deep level of the stack. I know that yesod apps have run on Windows
+before, so apparently something has changed and introduced this problem.
+
+Also have a problem with the autobuilder; the EvilSplicer or something
+it runs is locking up on that system for reasons not yet determined.
+
+Looks like I will need to wait a bit longer for the windows webapp, but I
+could keep working on porting the assistant in the meantime. 
+
+The most important thing that I need to port is how to check if a file
+is being written to at the same time the assistant adds it to the
+repository. No real `lsof` equivilant on Windows. I might be able to do
+something with exclusive locking to detect if there's a writer (but this
+would also block using the file while it was being added). Or I may be able
+to avoid the need for this check, at least in direct mode.
diff --git a/doc/devblog/day_74__so_close/comment_1_b1aa185734c3d74830b81def4fe63bff._comment b/doc/devblog/day_74__so_close/comment_1_b1aa185734c3d74830b81def4fe63bff._comment
new file mode 100644
index 0000000000..2abbc8dd33
--- /dev/null
+++ b/doc/devblog/day_74__so_close/comment_1_b1aa185734c3d74830b81def4fe63bff._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://nullroute.eu.org/~grawity/"
+ nickname="Mantas"
+ subject="comment 1"
+ date="2013-12-08T12:52:26Z"
+ content="""
+Take a look at how Process Hacker implements the \"Search for open handles\" function; it is rather close to `lsof`. (Unlocker probably does it the same way, too.)
+
+But locking (e.g. I think the \"share mode\" could prevent other programs from writing but not reading) may be more reliable, if a program starts writing to file *after* the lsof check happens...
+"""]]
diff --git a/doc/devblog/day_75__hallelujah.mdwn b/doc/devblog/day_75__hallelujah.mdwn
new file mode 100644
index 0000000000..42fb4fdf9c
--- /dev/null
+++ b/doc/devblog/day_75__hallelujah.mdwn
@@ -0,0 +1,8 @@
+I have seen the glory of the webapp running on Windows.
+
+One of the warp developers pointed me in the right direction and I
+developed a fix for the `recv` bug.
+
+My Windows and MSIE are old and fall over on some of the
+javascript, so it's not glorious enough for a screenshot. But large chunks
+of it do seem to work.
diff --git a/doc/devblog/day_75__hallelujah/comment_1_df04c456e99d47743494a18c1badba8c._comment b/doc/devblog/day_75__hallelujah/comment_1_df04c456e99d47743494a18c1badba8c._comment
new file mode 100644
index 0000000000..bd83ec1ff4
--- /dev/null
+++ b/doc/devblog/day_75__hallelujah/comment_1_df04c456e99d47743494a18c1badba8c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~maestro-alubia"
+ nickname="maestro-alubia"
+ subject="comment 1"
+ date="2013-12-09T19:47:32Z"
+ content="""
+Yeah! Looking forward to finally introduce git-annex in my heterogeneous network. Thanks and keep up the good work!
+"""]]
diff --git a/doc/devblog/day_76__results.mdwn b/doc/devblog/day_76__results.mdwn
new file mode 100644
index 0000000000..4fc71eaa63
--- /dev/null
+++ b/doc/devblog/day_76__results.mdwn
@@ -0,0 +1,15 @@
+Fixed up a few problems with the Windows webapp, and it's now completely
+usable, using any browser other than MSIE. While there are missing
+features in the windows port, all the UI for the features it does have
+seems to just work in the webapp.
+
+Fixed a ugly problem with Firefox, which turned out to have been introduced
+a while ago by a workaround for an ugly problem in Chrome. Web browsers are
+so wonderful, until they're crap.
+
+Think I've fixed the bug in the EvilLinker that was causing it to hang on
+the autobuilder, but still don't have a Windows autobuild with the webapp
+just yet.
+
+Also improved `git annex import` some more, and worked on a bug in git
+repository repair, which I will need to spend some more time on tomorrow.
diff --git a/doc/devblog/day_77__it_builds.mdwn b/doc/devblog/day_77__it_builds.mdwn
new file mode 100644
index 0000000000..421bb5efec
--- /dev/null
+++ b/doc/devblog/day_77__it_builds.mdwn
@@ -0,0 +1,8 @@
+Got the Windows autobuilder building the webapp. Have not tried that build
+yet myself, but I have high hopes it will work.
+
+Made other Windows improvements, including making the installer
+write a start menu entry file, and adding free disk space checking.
+
+Spent rest of the day improving git repair code on a real-world corrupted
+repository.
diff --git a/doc/devblog/day_78__desidetracked.mdwn b/doc/devblog/day_78__desidetracked.mdwn
new file mode 100644
index 0000000000..5b8ca8a583
--- /dev/null
+++ b/doc/devblog/day_78__desidetracked.mdwn
@@ -0,0 +1,34 @@
+I've switched over to mostly working on Windows porting in the evenings
+when bored, with days spent on other git-annex stuff. So, getting back to
+the planned [[design/roadmap]] for this month..
+
+Set up a [tip4commit for git-annex](http://tip4commit.com/projects/152).
+Anyone who gets a commit merged in will receive a currently small amount of
+bitcoin. This would almost be a good way to encourage more committers
+other than me, by putting say, half the money I have earmarked for that into
+the tip jar. The problem is, I make too many commits myself, so most of the
+money would be quickly tipped back out to me! I have gotten in touch with the
+tip4commit people, and hope they will give me a way to blacklist
+myself from being tipped.
+
+Designed a [[design/external_special_remote_protocol]] that seems pretty
+good for first-class special remotes implemented outside git-annex.
+It's moderately complicated on the git-annex side to make it simple and
+flexible on the special remote side, but I estimate only a few days to build
+it once I have the design finalized.
+
+# windows
+
+Tested the autobuilt windows webapp. It works! Sorted out some issues with
+the bundled libraries.
+
+Reworked how `git annex transferkeys` communicates, to make it easier to
+port it to Windows. Narrowly managed to avoid needing to write Haskell
+bindings to Windows's equivilant of `pipe(2)`. I think the Windows
+assistant can transfer keys now. and the webapp UI may even be able to be
+used to stop transfers. Needs testing.
+
+Investigated what I'll need to get XMPP working on Windows. Most of the
+libs are available in cygwin, but gsasl would need to be built from source.
+Also some kind of space-in-path problem is preventing cabal installing some
+of the necessary dependencies.
diff --git a/doc/devblog/day_79__catch_up.mdwn b/doc/devblog/day_79__catch_up.mdwn
new file mode 100644
index 0000000000..0206a0acf6
--- /dev/null
+++ b/doc/devblog/day_79__catch_up.mdwn
@@ -0,0 +1,3 @@
+Spent most of today catching up with a weeks's worth of traffic.
+
+Fixed 2 bugs. Message backlog is 23 messages.
diff --git a/doc/devblog/day_7__release_day.mdwn b/doc/devblog/day_7__release_day.mdwn
new file mode 100644
index 0000000000..f377bb4be2
--- /dev/null
+++ b/doc/devblog/day_7__release_day.mdwn
@@ -0,0 +1,10 @@
+Got git annex sync working with gcrypt. So went ahead and made a release
+today. Lots of nice new features!
+
+Unfortunately the linux 64 bit daily build is failing, because my build
+host only has 2 gb of memory and it is no longer enough. I am looking for a
+new build host, ideally one that doesn't cost me $40/month for 3 gb of ram
+and 15 gb of disk. (Extra special ideally one that I can run multiple builds
+per day on, rather than the current situation of only building overnight to
+avoid loading the machine during the day.) Until this is sorted out, no
+new 64 bit linux builds..
diff --git a/doc/devblog/day_7__release_day/comment_1_12bb94d903868ecddb3e348c9c4afeaf._comment b/doc/devblog/day_7__release_day/comment_1_12bb94d903868ecddb3e348c9c4afeaf._comment
new file mode 100644
index 0000000000..266e843fd5
--- /dev/null
+++ b/doc/devblog/day_7__release_day/comment_1_12bb94d903868ecddb3e348c9c4afeaf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="comment 1"
+ date="2013-09-09T21:51:47Z"
+ content="""
+Joey, I'd be happy to host 64-bit builds on both Mac and Linux using my personal Jenkins server (both machines are local and have 16+ GB of RAM).  I might even be able to get you SSH jail access to the build tree for the 64-bit Linux build.  Just let me know at johnw@fpcomplete.com.
+"""]]
diff --git a/doc/devblog/day_7__release_day/comment_2_d3e38d6f6bba179dab40d4d75ff061de._comment b/doc/devblog/day_7__release_day/comment_2_d3e38d6f6bba179dab40d4d75ff061de._comment
new file mode 100644
index 0000000000..96fb5dce30
--- /dev/null
+++ b/doc/devblog/day_7__release_day/comment_2_d3e38d6f6bba179dab40d4d75ff061de._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="comment 2"
+ date="2013-09-10T23:11:27Z"
+ content="""
+Everything is all setup now to build git-annex on both systems, at most once per hour (if there have been new Git commits), and only between 2am and 4pm.  Just contact me on IRC or e-mail and I'll setup you up with credentials so that you can manipulate the jobs and access the build artifacts.
+"""]]
diff --git a/doc/devblog/day_80__plumbing.mdwn b/doc/devblog/day_80__plumbing.mdwn
new file mode 100644
index 0000000000..3ef76a3730
--- /dev/null
+++ b/doc/devblog/day_80__plumbing.mdwn
@@ -0,0 +1,9 @@
+Made some improvements to git-annex's plumbing level commands today. Added
+new lookupkey and examinekey commands. Also expanded the things that
+`git annex find` can report about files. Among other things, the elusive
+hash directory locations can now be looked up, which IIRC a few people have
+asked for a way to do.
+
+Also did some work on the linux standalone tarball and OSX app. Both now
+include man pages, and it's also now possible to just unpack it and symlink
+git-annex into ~/bin or similar to add it to PATH.
diff --git a/doc/devblog/day_81__more_standalone.mdwn b/doc/devblog/day_81__more_standalone.mdwn
new file mode 100644
index 0000000000..646f280c12
--- /dev/null
+++ b/doc/devblog/day_81__more_standalone.mdwn
@@ -0,0 +1,15 @@
+Made the Linux standalone builds more self-contained, now they include
+their own linker and glibc, and ugly hacks to make them be used when
+running the included programs. This should make them more portable
+to older systems.
+
+Set up an arm autobuilder. 
+This autobuilder runs in an Debian armel chroot, using
+qemu-user-static (with a patch to make it support some syscalls ghc uses).
+No webapp yet; waiting on feedback of how well it works. I *hope* this
+build will be usable on eg, Synology NAS and Raspberry PI.
+
+Also worked on improving the assistant's batching of commits during the
+startup scan. And some other followups and bug triage.
+
+Today's work was sponsored by Hamish Coleman.
diff --git a/doc/devblog/day_81__more_standalone/comment_1_25ceb116406b55a8ff28f7b392806bc9._comment b/doc/devblog/day_81__more_standalone/comment_1_25ceb116406b55a8ff28f7b392806bc9._comment
new file mode 100644
index 0000000000..4a18b79a66
--- /dev/null
+++ b/doc/devblog/day_81__more_standalone/comment_1_25ceb116406b55a8ff28f7b392806bc9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnRai_qFYPVvEgC6i1nlM1bh-C__jbhqS0"
+ nickname="Matthew"
+ subject="Binaries"
+ date="2013-12-17T12:49:26Z"
+ content="""
+Are there binaries for the RPi version anywhere, it would be great to try it.
+
+Thanks
+"""]]
diff --git a/doc/devblog/day_82__rpi_and_synology.mdwn b/doc/devblog/day_82__rpi_and_synology.mdwn
new file mode 100644
index 0000000000..3749f474ad
--- /dev/null
+++ b/doc/devblog/day_82__rpi_and_synology.mdwn
@@ -0,0 +1,21 @@
+Fixed a few problems in the [[armel build|install/Linux_standalone]], and
+it's been confirmed to work on Raspberry Pi and Synology NAS. Since none of
+the fixes were specific to those platforms, it will probably work anywhere
+the kernel is new enough. That covers 9+% of the 
+[missing ports in the user survey](http://git-annex-survey.branchable.com/polls/2013/missing_ports/)!
+
+Thought through the possible issues with the assistant on Windows not being
+able to use lsof. I've convinced myself it's probably safe. (In fact, it
+might be safe to stop checking with lsof when using the assistant in direct
+mode entirely.) Also did some testing of some specific interesting
+circumstances (including 2 concurrent writers to a single file).
+
+I've been working on adding the webapp to the armel build. This can mostly
+reuse the patches and EvilSplicer developed for Android, but it's taking
+some babysitting of the build to get yesod etc installer for various reasons.
+Will be surprised if I don't get there tomorrow.
+
+One other thing.. I notice that <http://git-annex.org/> is up and running.
+This was set up by Subito, who offered me the domain, but I suggested he
+keep it and set up a pretty start page that points new users at the
+relevant parts of the wiki. I think he's done a good job with that!
diff --git a/doc/devblog/day_82__rpi_and_synology/comment_1_d154ddcf22027fd06acf9da73e12c006._comment b/doc/devblog/day_82__rpi_and_synology/comment_1_d154ddcf22027fd06acf9da73e12c006._comment
new file mode 100644
index 0000000000..33bc12e634
--- /dev/null
+++ b/doc/devblog/day_82__rpi_and_synology/comment_1_d154ddcf22027fd06acf9da73e12c006._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Attila"
+ ip="213.163.19.162"
+ subject="git-annex.org"
+ date="2013-12-27T14:14:07Z"
+ content="""
+Minor glitch on git-annex.org: the first link to http://git-annex.branchable.com is missing http:// prefix and so points to http://www.git-annex.org/git-annex.branchable.com
+"""]]
diff --git a/doc/devblog/day_83__armel_webapp.mdwn b/doc/devblog/day_83__armel_webapp.mdwn
new file mode 100644
index 0000000000..95c70010b8
--- /dev/null
+++ b/doc/devblog/day_83__armel_webapp.mdwn
@@ -0,0 +1,19 @@
+Got the arm webapp to build! (I have not tried to run it.) The build
+process for this is quite elaborate; 2 chroots, one amd64 and one armel,
+with the same versions of everything installed in each, and git-annex is
+built in the first to get the info the EvilSplicer needs to build it in the
+second.
+
+Fixed a nasty bug in the assistant on OSX, where at startup it would follow
+symlinks in the repository that pointed to directories outside the
+repository, and add the files found there. Didn't cause data loss itself
+(in direct mode the assistant doesn't touch the files), but certainly
+confusingly breaks things and makes it easy to shoot your foot off. I will
+be moving up the next scheduled release because of this bug, probably to
+Saturday.
+
+Looped the git developers in on a problem with git failing on some kernels
+due to `RLIMIT_NOFILE` not working. Looks like git will get more robust and
+this should make the armel build work on even more embedded devices.
+
+Today's work was sponsored by Johan Herland.
diff --git a/doc/devblog/day_84__ho_uh_oh.mdwn b/doc/devblog/day_84__ho_uh_oh.mdwn
new file mode 100644
index 0000000000..516ceb5321
--- /dev/null
+++ b/doc/devblog/day_84__ho_uh_oh.mdwn
@@ -0,0 +1,11 @@
+Resurfaced today to fix some problems with the Linux standalone builds
+in the Solstice release. The worst of these prevented the amd64 build from
+running on some systems, and that build has been updated. The other
+problems all involved the binary shimming, and were less serious.
+
+As part of that work, replaced the hacky shell script that handled the
+linux library copying and binary shimming with a haskell program.
+
+Also worked on some Windows bugs, and fixed a typo in the test suite.
+Got my own little present: haskell-tasty finally got out of Incoming, so
+the next Debian package build will once again include the test suite.
diff --git a/doc/devblog/day_85__external_special_remote_protocol_types.mdwn b/doc/devblog/day_85__external_special_remote_protocol_types.mdwn
new file mode 100644
index 0000000000..9b3e4d9b1f
--- /dev/null
+++ b/doc/devblog/day_85__external_special_remote_protocol_types.mdwn
@@ -0,0 +1,25 @@
+Only did a few hours today, getting started on implementing the
+[[design/external_special_remote_protocol]].
+
+Mostly this involved writing down types for the various messages,
+and code to parse them. I'm very happy with how the parsing turned out;
+nearly all the work is handled by the data types and type classes,
+and so only one line of very simple code is needed to parse each message:
+
+[[!format haskell """
+instance Receivable Response where
+       parseCommand "PREPARE-SUCCESS" = parse0 PREPARE_SUCCESS
+       parseCommand "TRANSFER-SUCCESS" = parse2 TRANSFER_SUCCESS
+       parseCommand "TRANSFER-FAILURE" = parse3 TRANSFER_FAILURE
+"""]]
+
+An especially nice part of this implementation is that it knows exactly how
+many parameters each message should have (and their types of course), and so
+can both reject invalid messages, and avoid ambiguity in tokenizing the
+parameters. For example, the 3rd parameter of TRANSFER-FAILURE is an error
+message, and as it's the last parameter, it can contain multiple words.
+
+	*Remote.External> parseMessage "TRANSFER-FAILURE STORE SHA1--foo doesn't work on Christmas" :: Maybe Response
+	Just (TRANSFER_FAILURE Upload (Key {keyName = "foo", keyBackendName = "SHA1", keySize = Nothing, keyMtime = Nothing}) "doesn't work on Christmas")
+
+That's the easy groundwork for external special remotes, done.
diff --git a/doc/devblog/day_86__external_special_remote_implementation.mdwn b/doc/devblog/day_86__external_special_remote_implementation.mdwn
new file mode 100644
index 0000000000..c40bfbaea3
--- /dev/null
+++ b/doc/devblog/day_86__external_special_remote_implementation.mdwn
@@ -0,0 +1,11 @@
+Built most of the external special remote today. While I've written 600
+lines of code for this, and think it's probably working, and complete
+(except for a couple of features), all I know is that it compiles.
+
+I've also written an [[example external special remote program in shell script|special_remotes/external/example.sh]],
+so the next step is to put the two together and see how it works.
+I also hope that some people who have built hook special remotes
+in the past will update them to the new external special remote interface,
+which is quite a lot better.
+
+Today's work was sponsored by Justine Lam.
diff --git a/doc/devblog/day_86__external_special_remote_implementation/comment_1_5116bcf4b60030cb46683df94a75d7ee._comment b/doc/devblog/day_86__external_special_remote_implementation/comment_1_5116bcf4b60030cb46683df94a75d7ee._comment
new file mode 100644
index 0000000000..3580623086
--- /dev/null
+++ b/doc/devblog/day_86__external_special_remote_implementation/comment_1_5116bcf4b60030cb46683df94a75d7ee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawleVyKk2kQsB_HgEdS7w1s0BmgRGy1aay0"
+ nickname="Milan"
+ subject="comment 1"
+ date="2013-12-27T08:44:44Z"
+ content="""
+Will it support splitting of large files for remotes that limits size of stored file?
+"""]]
diff --git a/doc/devblog/day_86__external_special_remote_implementation/comment_2_7b6e734f785fbd9db7883b63150023dc._comment b/doc/devblog/day_86__external_special_remote_implementation/comment_2_7b6e734f785fbd9db7883b63150023dc._comment
new file mode 100644
index 0000000000..7a0c857834
--- /dev/null
+++ b/doc/devblog/day_86__external_special_remote_implementation/comment_2_7b6e734f785fbd9db7883b63150023dc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 2"
+ date="2013-12-27T19:12:17Z"
+ content="""
+That's on the TODO list and the protocol should be easily flexible enough to let it be added. The existing code to handle chunks is a bit of a mess though.
+"""]]
diff --git a/doc/devblog/day_87__external_special_remotes_done.mdwn b/doc/devblog/day_87__external_special_remotes_done.mdwn
new file mode 100644
index 0000000000..b8bba606bb
--- /dev/null
+++ b/doc/devblog/day_87__external_special_remotes_done.mdwn
@@ -0,0 +1,16 @@
+The [[external_special_remote|special_remotes/external]] interface is now
+done, and tested working great! Now we just need all the old hook special
+remotes to be converted to use it..
+
+I punted on per-special-remote, per-key state storage in the git-annex
+branch for now. If I find an example of a remote that needs it (Tahoe-LAFS
+may, but still TBD), I'll add it. Added suppport for using the same
+credential storage that git-annex uses for S3 and WebDAV credentials.
+
+The main improvement I'd like to make is to add an interface for transferring
+files where the file is streamed to/from the external special remote,
+rather than using temp files as it does now. This would be more efficient
+(sometimes) and make the progress bars better. But it needs to either use a
+named pipe, which is complicated and non-portable, or serialize the file's
+contents over a currently line-based protocol, which would be a pain.
+Anyway, this can be added later, the protocol is extensible.
diff --git a/doc/devblog/day_88__lazy_sunday.mdwn b/doc/devblog/day_88__lazy_sunday.mdwn
new file mode 100644
index 0000000000..b06c76bd2f
--- /dev/null
+++ b/doc/devblog/day_88__lazy_sunday.mdwn
@@ -0,0 +1,15 @@
+Fixed a bug that could leave a direct mode repository stuck at
+annex.version 3. As part of that, v3 indirect mode repositories will be
+automatically updated to v5. There's no actual change in that upgrade, it
+just simplifies things to have only one supported annex.version.
+
+Added youtube playlist support to git-annex. Seems I had almost all the
+pieces needed, and didn't know it. Only about a dozen lines of code!
+
+Added PREPARE-FAILURE support to the external special remote interface.
+
+After I found the cable my kitten stole (her apport level is high), fixed
+file transfers to/from Android. This broke because git-annex assistant
+tries to use ionice, if it's in PATH, and Android's ionice is not suitable.
+It could probably include ionice in the busybox build and use that one, but
+I wanted a quick fix for this before the upcoming release.
diff --git a/doc/devblog/day_89__reflections.mdwn b/doc/devblog/day_89__reflections.mdwn
new file mode 100644
index 0000000000..94bbf87e2b
--- /dev/null
+++ b/doc/devblog/day_89__reflections.mdwn
@@ -0,0 +1,18 @@
+Worked on bug report and forum backlog (24 messages left), and made a few
+bug fixes. The main one was a fix for a Windows-specific direct mode merge
+bug.
+
+This month didn't go entirely to plan. I had not expected to work on the
+Windows assistant and webapp and get it so close to fully working. Nor had
+I expected to spend time and make significant progress on porting git-annex
+to *Linux* -- particularly to embedded NAS devices! I had hoped to
+encourage some others to develop git-annex, but only had one bite from a
+student and it didn't work out. Meanwhile, automatically rewarding
+committers with bitcoin is an interesting alternative approach to possibly
+motivating contributors, and I would like to set that up, but the software
+is new and I haven't had time yet. The only thing that went exactly as
+planned was the external special remote implementation.
+
+A special surprise this month is that I have started hearing privately from
+several institutions that are starting using git-annex in interesting ways.
+Hope I can share details of some of that 2014!
diff --git a/doc/devblog/day_8__ill.mdwn b/doc/devblog/day_8__ill.mdwn
new file mode 100644
index 0000000000..c086a9dc1b
--- /dev/null
+++ b/doc/devblog/day_8__ill.mdwn
@@ -0,0 +1,20 @@
+I've been out sick. However, some things kept happening. Mesar contributed
+a build host, and the linux and android builds are now happening, hourly,
+there. (Thanks as well to the two other people who also offered hostng.)
+And I made a minor release to fix a bug in the test suite that I was pleased
+three different people reported.
+
+Today, my main work was getting git-annex to notice when a gcrypt remote
+located on some removable drive mount point is not the same gcrypt remote
+that was mounted there before. I was able to finesse this so it
+re-configures things to use the new gcrypt remote, as long as it's a
+special remote it knows about. (Otherwise it has to ignore the remote.)
+So, encrypted repos on removable drives will work just as well as
+non-encrypted repos!
+
+Also spent a while with rsync.net tech support trying to work out why
+someone's git-annex apparently opened a lot of concurrent ssh connections
+to rsync.net. Have not been able to reproduce the problem though.
+
+Also, a lot of catch-up to traffic. Still 63 messages backlogged however,
+and still not entirely well..
diff --git a/doc/devblog/day_90__slow_start.mdwn b/doc/devblog/day_90__slow_start.mdwn
new file mode 100644
index 0000000000..09d1f7270c
--- /dev/null
+++ b/doc/devblog/day_90__slow_start.mdwn
@@ -0,0 +1,23 @@
+Various work on Debian, OSX, and Windows stuff. Mostly uninteresting, but
+took most of the day.
+
+Made `git annex mirror --all` work. I can see why I left it out; when the
+mirroring wants to drop an object, in --all mode it doesn't have an
+associated file in the tree, so it cannot look at the annex.numcopies in
+gitattributes. Same reason why `git annex drop --all` is not implemented.
+But decided to go ahead and only use other numcopies configuration for
+mirroring.
+
+Added GETWANTED and SETWANTED to the external special remote protocol, and
+that is as far as I want to go on adding git-annex plumbing stuff to the
+protocol. I expect Tobias will release a boatload of special remotes
+updated to the new protocol soon, which seems to prove it has everything
+that could reasonably be needed.
+
+This is a nice public git-annex repository containing a growing collection
+of tech conference videos. <https://github.com/RichiH/conference_proceedings>
+
+Did some design work on [[todo/untracked_remotes]], which I think will turn
+out to be read-only remotes. Being able to clone a repository and use
+git-annex in the clone without anything leaking back upstream is often
+desirable when using public repository, or a repository with many users.
diff --git a/doc/devblog/day_91__wintry_mix.mdwn b/doc/devblog/day_91__wintry_mix.mdwn
new file mode 100644
index 0000000000..bfa9ddd35e
--- /dev/null
+++ b/doc/devblog/day_91__wintry_mix.mdwn
@@ -0,0 +1,11 @@
+Implemented read-only remotes. This may not cover every use case around
+wanting to clone a repository and use git-annex without leaking the
+existence of your clone back to it, but I think it hits most of them in a
+quite easy way, and allows for some potentially interesting stuff like
+partitioned networks of git-annex repositories.
+
+Zooko and I have been talking things over (for rather too long),
+and I think have now agreed on a how a more advanced git-annex
+Tahoe-LAFS special remote should work. This includes storing the
+tahoe file-caps in the git-annex branch. So, I really need to add that
+per-special-remote data storage feature I've been thinking about.
diff --git a/doc/devblog/day_92-93__reconnection.mdwn b/doc/devblog/day_92-93__reconnection.mdwn
new file mode 100644
index 0000000000..aa83bde38c
--- /dev/null
+++ b/doc/devblog/day_92-93__reconnection.mdwn
@@ -0,0 +1,34 @@
+Yesterday, added per-remote, per-key state storage. This is exported via
+the external special remote protocol, and I expect to use it at least for
+Tahoe Lafs.
+
+Also, made the assistant write ssh config files with better permissions,
+so ssh won't refuse to use them. (The only case I know of where that
+happened was on Windows.)
+
+Today, made `addurl` and `importfeed` honor annex.diskreserve. Found out about
+this the hard way, when an importfeed cron job filled up my server with
+youtube videos. I should probably also make `import` honor
+annex.diskreserve.
+
+---
+
+I've been working, so far inconclusively, on making the assistant
+deal with remotes that might open a long duration network connection.
+Problem being that if the connection is lost, and the remote is not smart
+enough to reconnect, all further use of it could fail.
+
+In a `restarttransferrer` branch, I have made the assistant start separate
+`transferkeys` processes for each remote. So if a remote starts to
+fail, the assistant can stop its `transferkeys` process, and restart it,
+solving the problem.
+
+But, if a resource needed for a remote is not available, this degrades to
+every transfer attempt to that remote restarting it. So I don't know if this is the
+right approach.
+
+Other approaches being considered include asking that implementors of
+external special remotes deal with reconnection themselves (Tobias, do you
+deal with this in your remotes?), or making the
+assistant only restart failing remotes after it detects there's been 
+a network connection change.
diff --git a/doc/devblog/day_94__leaks.mdwn b/doc/devblog/day_94__leaks.mdwn
new file mode 100644
index 0000000000..3aa4e1552c
--- /dev/null
+++ b/doc/devblog/day_94__leaks.mdwn
@@ -0,0 +1,12 @@
+Spent ages tracking down a memory leak in the assistant that showed up when
+a lot of files were added. Turned out to be a standard haskell laziness
+induced problem, fixed by adding strictness annotations. Actually there
+were several of them, that leaked at different rates. Eventually, I seem to
+have gotten them all fixed:
+
+Before: [[bugs/import_memleak_from_the_assistant/leakbefore.png]]
+After: [[bugs/import_memleak_from_the_assistant/leakafter.png]]
+
+Also fixed a bug in `git annex add` when the disk was completely full.
+In that situation, it could sometimes move the file from the work tree to
+.git/annex/objects and fail to put the symlink in place.
diff --git a/doc/devblog/day_95__reconnection_revisited.mdwn b/doc/devblog/day_95__reconnection_revisited.mdwn
new file mode 100644
index 0000000000..b2d5b28a58
--- /dev/null
+++ b/doc/devblog/day_95__reconnection_revisited.mdwn
@@ -0,0 +1,13 @@
+Taught the assistant to stop reusing an existing `git annex transferkeys`
+process after it detects a network connection change. I don't think this is
+a complete solution to what to do about long-duration network connections
+in remotes. For one thing a remote could take a long time to time out
+when the network is disconnected, and block other transfers (eg to
+local drives) in the meantime. But at least if a remote loses its network
+connection and does not try to reconnect on its own, and so is continually
+failing, this will get it back into a working state eventually.
+
+Also, fixed a problem with the OSX Mavericks build, it seems that the
+versions of wget and coreutils stuff that I was including in it were built
+by homebrew with full optimisations turned on, so didn't work on some CPUs.
+Replaced those with portable builds.
diff --git a/doc/devblog/day_95__reconnection_revisited/comment_1_c1106e573fcf9f3d4524c0e4f4254790._comment b/doc/devblog/day_95__reconnection_revisited/comment_1_c1106e573fcf9f3d4524c0e4f4254790._comment
new file mode 100644
index 0000000000..67618f64d3
--- /dev/null
+++ b/doc/devblog/day_95__reconnection_revisited/comment_1_c1106e573fcf9f3d4524c0e4f4254790._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnX1msQxnLoSeu7q-i-c9BWghonsN7Qmns"
+ nickname="Jan Ulrich"
+ subject="comment 1"
+ date="2014-01-07T16:02:01Z"
+ content="""
+Thanks for the Mavericks fix! 
+"""]]
diff --git a/doc/devblog/day_95__reconnection_revisited/comment_2_40478739f95e0b56ce0103db6e405ef4._comment b/doc/devblog/day_95__reconnection_revisited/comment_2_40478739f95e0b56ce0103db6e405ef4._comment
new file mode 100644
index 0000000000..331965e3e7
--- /dev/null
+++ b/doc/devblog/day_95__reconnection_revisited/comment_2_40478739f95e0b56ce0103db6e405ef4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnxp2XU8gIribhhGhGuYtU6eMMwHv5gUGI"
+ nickname="Amitai"
+ subject="obligatory &quot;bah homebrew, yay pkgsrc&quot; comment"
+ date="2014-01-12T03:01:17Z"
+ content="""
+Bah homebrew, yay pkgsrc.
+
+:-)
+"""]]
diff --git a/doc/devblog/day_96__catching_up.mdwn b/doc/devblog/day_96__catching_up.mdwn
new file mode 100644
index 0000000000..c41e962b13
--- /dev/null
+++ b/doc/devblog/day_96__catching_up.mdwn
@@ -0,0 +1,7 @@
+Been on reduced activity the past several days. I did spend a full day
+somewhere in there building the Tahoe LAFS special remote. Also, Tobias has
+finished updating his full suite of external special remotes to use the new
+interface!
+
+Worked on closing up the fundraising campaign today (long overdue).
+This included adding a new wall-o-names to [[/thanks]].
diff --git a/doc/devblog/day_97__exciting_telehash_possiblities.mdwn b/doc/devblog/day_97__exciting_telehash_possiblities.mdwn
new file mode 100644
index 0000000000..2477949768
--- /dev/null
+++ b/doc/devblog/day_97__exciting_telehash_possiblities.mdwn
@@ -0,0 +1,20 @@
+If you've been keeping an eye on the [[design/roadmap]], you'll have seen that
+[[design/assistant/xmpp_security]] keeps being pushed back. This was because
+it's a hard and annoying problem requiring custom crypto and with an
+ugly key validation problem built into it too. I've now removed it from the
+roadmap entirely, replacing it with a [[design/assistant/telehash]] design.
+
+I'm excited by the possibilities of using telehash with git-annex. It seems
+it would be quite easy to make it significantly more peer-to-peer and
+flexible. The only issue is that telehash is still under heavy
+development and the C implementation is not even usable yet..
+(I'll probably end up writing Haskell bindings to that.)
+So I've pushed it down the roadmap to at least March.
+
+Spent the rest of the day making some minor improvements to external special
+remote protocol and doing some other minor bug fixes and backlog catch up.
+My backlog has exploded to nearly 50 messages remaining.
+
+----
+
+Today's work was sponsored by Chad Horohoe.
diff --git a/doc/devblog/day_97__exciting_telehash_possiblities/comment_1_7c775d93cbeed0d553e224751d30fbaa._comment b/doc/devblog/day_97__exciting_telehash_possiblities/comment_1_7c775d93cbeed0d553e224751d30fbaa._comment
new file mode 100644
index 0000000000..78750716ed
--- /dev/null
+++ b/doc/devblog/day_97__exciting_telehash_possiblities/comment_1_7c775d93cbeed0d553e224751d30fbaa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkGCmVc5qIJaQQgG82Hc5zzBdAVdhe2JEM"
+ nickname="Bruno"
+ subject="is telehash udp only?"
+ date="2014-01-14T14:21:36Z"
+ content="""
+Is telehash UDP only?
+
+I like that XMPP works with HTTPS so it also works at work with proxies that only allows http traffic.
+"""]]
diff --git a/doc/devblog/day_98__old_bug.mdwn b/doc/devblog/day_98__old_bug.mdwn
new file mode 100644
index 0000000000..565efbdbcc
--- /dev/null
+++ b/doc/devblog/day_98__old_bug.mdwn
@@ -0,0 +1,17 @@
+Fixed a bug that one or two people had mentioned years ago, but I was never
+able to reproduce myself or get anyone to reproduce in a useful way. It
+caused log files that were supposed to be committed to the git-annex branch
+to end up in master. Turned out to involve weird stuff when the environment
+contains two different settings for a single variable. So was easily fixed
+at last. (I'm pretty sure the code would have never had this bug if
+Data.AssocList was not buried inside an xml library, which rather
+discourages using it when dealing with the environment.)
+
+Also worked on, and hopefully fixed, another OSX cpu optimisations problem.
+This one involving shared libraries that git-annex uses for XMPP.
+
+Also made the assistant detect corrupt .git/annex/index files on startup
+and remove them. It was already able to recover from corrupt .git/index
+files.
+
+Today's work was sponsored by David Wagner.
diff --git a/doc/devblog/day_99__catching_up_again.mdwn b/doc/devblog/day_99__catching_up_again.mdwn
new file mode 100644
index 0000000000..118a21f8d2
--- /dev/null
+++ b/doc/devblog/day_99__catching_up_again.mdwn
@@ -0,0 +1,19 @@
+Activity has been a bit low again this week. It seems to make sense to do
+weekly releases currently (rather than bi-monthly), and Thursday's
+release had only one new feature (Tahoe LAFS) and a bunch of bug fixes.
+
+Looks like git-annex will get back into Debian testing soon, after various
+fixes to make it build on all architectures again, and then the
+backport can be updated again too.
+
+I have been struggling with a problem with the OSX builds, which fail with
+a SIGKILL on some machines. It seems that homebrew likes to agressively
+optimise things it builds, and while I have had some success with its
+`--build-bottle` option, something in the gnutls stack used for XMPP is
+still over-optimised. Waiting to hear back from Kevin on cleaning up some
+optimised system libraries on the OSX host I use. (Is there some way to make
+a clean chrooot on OSX that can be accessed by a non-root user?)
+
+Today I did some minor work involving the --json switch, and also 
+a small change (well, under 300 line diff) allowing
+--all to be mixed with options like --copies and --in.
diff --git a/doc/devblog/day_99__catching_up_again/comment_1_b871bf0606dc29be9b8c2e5dc150f708._comment b/doc/devblog/day_99__catching_up_again/comment_1_b871bf0606dc29be9b8c2e5dc150f708._comment
new file mode 100644
index 0000000000..933de78737
--- /dev/null
+++ b/doc/devblog/day_99__catching_up_again/comment_1_b871bf0606dc29be9b8c2e5dc150f708._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkq2cjugiSvKWiWmcah3CPBqviQV_cin9I"
+ nickname="Yury"
+ subject="The world of Mac"
+ date="2014-01-19T14:13:55Z"
+ content="""
+I think that there is nothing fundamental about Mac OS X, which would prevent one from making a clean chroot that would work for non-root users. For instance, I believe that jailkit has been reported to work just fine. The problem is that you'll have to rebuild most of the stuff you need from scratch, which is very tedious. Might be easier to find instances where Homebrew has something like -march=native added to the $CFLAGS (not that I particularly fancy Homebrew of all 'missing' package managers on OS X).
+
+Anyways, it sounds like I'm going to get a Mac Mini donated sometime soon and I'm curious as to what would be the best way to make use of it for the CI system...
+"""]]
diff --git a/doc/devblog/day_99__catching_up_again/comment_2_c8363d47223e7bb899420e800bde3e27._comment b/doc/devblog/day_99__catching_up_again/comment_2_c8363d47223e7bb899420e800bde3e27._comment
new file mode 100644
index 0000000000..fb2377845d
--- /dev/null
+++ b/doc/devblog/day_99__catching_up_again/comment_2_c8363d47223e7bb899420e800bde3e27._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnE6kFAbud1LWrQuyX76yMYnUjHt9tR-A8"
+ nickname="Leonardo"
+ subject="Chroots"
+ date="2014-01-21T13:52:29Z"
+ content="""
+How about simply having sshd inside the chroot?
+"""]]
diff --git a/doc/devblog/day_9__Friday_the_13th.mdwn b/doc/devblog/day_9__Friday_the_13th.mdwn
new file mode 100644
index 0000000000..77d9039eb8
--- /dev/null
+++ b/doc/devblog/day_9__Friday_the_13th.mdwn
@@ -0,0 +1,21 @@
+Worked to get git-remote-gcrypt included in every git-annex autobuild
+bundle.
+(Except Windows; running a shell script there may need some work later..)
+
+Next I want to work on making the assistant easily able to create encrypted
+git repositories on removable drives. Which will involve a UI to select
+which gpg key to use, or creating (and backing up!) a gpg key.
+
+But, I got distracted chasing down some bugs on Windows. These were
+quite ugly; more direct mode mapping breakage which resulted in 
+files not being accessible. Also fsck on Windows failed to detect and fix
+the problem. All fixed now. (If you use git-annex on Windows, you should
+certainly upgrade and run `git annex fsck`.)
+
+As with most bugs in the Windows port, the underlying cause turned out to
+be stupid: `isSymlink` always returned False on Windows. Which makes sense
+from the perspective of Windows not quite having anything entirely like
+symlinks. But failed when that was being used to detect when files in the
+git tree being merged into the repository had the symlink bit set..
+
+Did bug triage. Backlog down to 32 (mostly messages from August).
diff --git a/doc/devblog/day_9__Friday_the_13th/comment_1_07195b4ec399ba1be6c8bdb3ae0fa50b._comment b/doc/devblog/day_9__Friday_the_13th/comment_1_07195b4ec399ba1be6c8bdb3ae0fa50b._comment
new file mode 100644
index 0000000000..aff4dc264a
--- /dev/null
+++ b/doc/devblog/day_9__Friday_the_13th/comment_1_07195b4ec399ba1be6c8bdb3ae0fa50b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://nullroute.eu.org/~grawity/"
+ nickname="Mantas"
+ subject="comment 1"
+ date="2013-09-13T22:05:37Z"
+ content="""
+Windows *does* have something very much like symlinks – they're called *symlinks* (\"symbolic links\") and they are meant to [\"function just like UNIX links\"][1] as the official docs say.
+
+But on the other hand, yes – `isSymlink` makes less sense on Windows, because symlinks are just a type of reparse points, and there may be several other types (e.g. directory junctions should also be treated like symlinks, but mount points shouldn't...)
+
+[1]: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365680(v=vs.85).aspx
+"""]]
diff --git a/doc/devblog/day__126-127__merge_fixes.mdwn b/doc/devblog/day__126-127__merge_fixes.mdwn
new file mode 100644
index 0000000000..f4a57a09d7
--- /dev/null
+++ b/doc/devblog/day__126-127__merge_fixes.mdwn
@@ -0,0 +1,61 @@
+Yesterday I learned of a nasty bug in handling of merges in direct mode. It
+turns out that if the remote repository has added a file, and there is a
+conflicting file in the local work tree, which has not been added to git, the
+local file was overwritten when git-annex did a merge. That's really bad, I'm
+very unhappy this bug lurked undetected for so long.
+
+Understanding the bug was easy. Fixing it turned out to be hard, because
+the automatic merge conflict resolution code was quite a mess. In
+particular, it wrote files to the work tree, which made it difficult for a
+later stage to detect and handle the abovementioned case. Also, the
+automatic merge resolution code had weird asymmetric structure that I never
+fully understood, and generally needed to be stared at for an hour to begin
+to understand it.
+
+In the process of cleaning that up, I wrote several more tests,
+to ensure that every case was handled correctly. Coverage was about 50%
+of the cases, and should now be 100%.
+
+To add to the fun, a while ago I had dealt with a bug on FAT/Windows where
+it sometimes lost the symlink bit during automatic merge resolution. Except
+it turned out my test case for it had a heisenbug, and I had not actually
+fixed it (I think). In any case, my old fix for it was a large part
+of the ugliness I was cleaning up, and had to be rewritten.
+Fully tracking down and dealing with that took a large part of today.
+
+Finally this evening, I added support for automatically handling merge
+conflicts where one side is an annexed file, and the other side has the
+same filename committed to git in the normal way. This is not an important
+case, but it's worth it for completeness. There was an unexpected benefit
+to doing it; it turned out that the weird asymmetric part of the code went
+away.
+
+The final core of the automatic merge conflict resolver has morphed from
+a mess I'd not want to paste here to a quite consise and easy to follow
+bit of code.
+
+[[!format haskell """
+        case (kus, kthem) of
+                -- Both sides of conflict are annexed files
+                (Just keyUs, Just keyThem) -> resolveby $
+                        if keyUs == keyThem
+                                then makelink keyUs
+                                else do
+                                        makelink keyUs
+                                        makelink keyThem
+                -- Our side is annexed file, other side is not.
+                (Just keyUs, Nothing) -> resolveby $ do
+                        graftin them file
+                        makelink keyUs
+                -- Our side is not annexed file, other side is.
+                (Nothing, Just keyThem) -> resolveby $ do
+                        graftin us file
+                        makelink keyThem
+                -- Neither side is annexed file; cannot resolve.
+                (Nothing, Nothing) -> return Nothing
+"""]]
+
+Since the bug that started all this is so bad, I want to make a release
+pretty soon.. But I will probably let it soak and whale on the test suite
+a bit more first. (This bug is also probably worth backporting to old
+versions of git-annex in eg Debian stable.)
diff --git a/doc/devblog/day__228_new_AWS.mdwn b/doc/devblog/day__228_new_AWS.mdwn
new file mode 100644
index 0000000000..3003a79852
--- /dev/null
+++ b/doc/devblog/day__228_new_AWS.mdwn
@@ -0,0 +1,13 @@
+New AWS region in Germany announced today. git-annex doesn't support it
+yet, unless you're using the `s3-aws` branch.
+
+I cleaned up that branch, got it building again, and re-tested it with
+`testremote`, and then fixed a problem the test suite found that was
+caused by some changes in the haskell aws library.
+
+Unfortunately, s3-aws is [not ready to be merged](http://git-annex.branchable.com/bugs/new_AWS_region___40__eu-central-1__41__)
+because of some cabal dependency problems involving `dbus` and `random`. I did
+go ahead and update Debian's haskell-aws package to cherry-pick
+from a newer version the change needed for Inernet Archive
+support, which allows building the s3-aws branch on Debian.
+Getting closer..
diff --git a/doc/devblog/day__329-330__a_rising_tide.mdwn b/doc/devblog/day__329-330__a_rising_tide.mdwn
new file mode 100644
index 0000000000..b23d2677f4
--- /dev/null
+++ b/doc/devblog/day__329-330__a_rising_tide.mdwn
@@ -0,0 +1,15 @@
+Things have been relatively quiet on git-annex this week. I've been
+distracted with other projects. But, a library that I developed for
+[propellor](http://propellor.branchable.com/) to help with 
+[concurrent console output](http://joeyh.name/blog/entry/concurrent_output_library/)
+has been rapidly developing into a kind of
+[tiling region manager for the console](http://joeyh.name/blog/entry/a_tiling_region_manager_for_the_console),
+which may be just the thing git-annex needs on the concurrent
+download progress display front.
+
+After seeing it could go that way, and working on it around the clock to
+add features git-annex will need, here's a teaser of its abilities.
+
+<img src="https://joeyh.name/code/concurrent-output/aptdemo.gif">
+
+Probably coming soonish to a `git-annex -J` near you!
diff --git a/doc/devblog/moving_blogs.mdwn b/doc/devblog/moving_blogs.mdwn
new file mode 100644
index 0000000000..f6dac56c9e
--- /dev/null
+++ b/doc/devblog/moving_blogs.mdwn
@@ -0,0 +1,5 @@
+I've started a new page for my devblog, since I'm not focusing extensively
+on the assistant and so keeping the blog [[here|design/assistant/blog]]
+increasingly felt wrong. Also, my new year of
+[crowdfunded development](https://campaign.joeyh.name)
+formally starts in September, so a new blog seemed good.
diff --git a/doc/devblog/moving_blogs/comment_1_6caa7e67461a6ea5de8155ae9cf75fab._comment b/doc/devblog/moving_blogs/comment_1_6caa7e67461a6ea5de8155ae9cf75fab._comment
new file mode 100644
index 0000000000..46df4a7f68
--- /dev/null
+++ b/doc/devblog/moving_blogs/comment_1_6caa7e67461a6ea5de8155ae9cf75fab._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://pnijjar.livejournal.com/"
+ ip="99.236.22.229"
+ subject="comment 1"
+ date="2013-08-31T00:05:16Z"
+ content="""
+Do we need to update our RSS feeds? I appear to be getting your devblog posts in my old feed, but I do not know whether that will continue working.
+"""]]
diff --git a/doc/devblog/moving_blogs/comment_2_e3e2048fc2397b87a2f29c9fe49394cb._comment b/doc/devblog/moving_blogs/comment_2_e3e2048fc2397b87a2f29c9fe49394cb._comment
new file mode 100644
index 0000000000..19b5ae1c6f
--- /dev/null
+++ b/doc/devblog/moving_blogs/comment_2_e3e2048fc2397b87a2f29c9fe49394cb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="comment 2"
+ date="2013-08-31T10:03:04Z"
+ content="""
+The old RSS feed will continue working.
+
+So sit back, relax, and enjoy the show.
+"""]]
diff --git a/doc/devblog/whither_XMPP.mdwn b/doc/devblog/whither_XMPP.mdwn
new file mode 100644
index 0000000000..9e99ba1acd
--- /dev/null
+++ b/doc/devblog/whither_XMPP.mdwn
@@ -0,0 +1,30 @@
+Pushed a release today. Rest of day spent beating head against Windows XMPP
+brick wall.
+
+Actually made a lot of progress -- Finally found the right approach, and
+got a clean build of the XMPP haskell libraries. But.. ghc fails to
+load the libraries when running Template Haskell. 
+"Misaligned section: 18206e5b".
+Filed [a bug report](https://ghc.haskell.org/trac/ghc/ticket/8830), 
+and I'm sure this alignment problem can be fixed,
+but I'm not hopeful about fixing it myself.
+
+One workaround would be to use the EvilSplicer, building once without the
+XMPP library linked in, to get the TH splices expanded, and then a second
+time with the XMPP library and no TH. Made a `winsplicehack` branch with
+tons of ifdefs that allows doing this. However, several dozen haskell libraries
+would need to be patched to get it to work. I have the patches from
+Android, but would rather avoid doing all that again on Windows.
+
+Another workaround would be to move XMPP into a separate process from the
+webapp. This is not very appealing either, the IPC between them would be
+fairly complicated since the webapp does stuff like show lists of XMPP
+buddies, etc. But, one thing this idea has to recommend it is I am already
+considering using a separate helper daemon like this for
+[[design/assistant/Telehash]].
+
+So there could be synergies between XMPP and Telehash support, possibly
+leading to some kind of plugin interface in git-annex for this sort of
+thing. But then, once Telehash or something like it is available and
+working well, I plan to deprecate XMPP entirely. It's been a flakey pain
+from the start, so that can't come too soon.
diff --git a/doc/devblog/youtube-dl.mdwn b/doc/devblog/youtube-dl.mdwn
new file mode 100644
index 0000000000..0a7fbb51b7
--- /dev/null
+++ b/doc/devblog/youtube-dl.mdwn
@@ -0,0 +1,30 @@
+Working on [[todo/switch_from_quvi_to_youtube-dl]], because
+quvi is not being maintained and youtube-dl can download a lot more stuff.
+
+Unfortunately, youtube-dl's interface is not a good fit for git-annex,
+compared with quvi's interface which was a near-perfect fit. Two things
+git-annex relied on quvi for are a way to check if a url has embedded media
+without downloading the url, and a way to get the url from which the
+embedded media can be downloaded. Youtube-dl supports neither. Also it has
+some other warts that make it unncessarily hard to interface with, like not
+always [storing the download in the location specified by --output](https://github.com/rg3/youtube-dl/issues/14864),
+and [sometimes crashing when downloading non-media urls (eg over my satellite internet)](http://bugs.debian.org/874321).
+
+I've found ways to avoid all these problems. For example, to make
+`git annex addurl` avoid unncessarily overhead of running youtube-dl
+in the common case of downloading some non-web-page file, I'll have it
+download the url content, and check if it looks like a html page.
+Only then will it use youtube-dl. So addurl of html pages without
+embedded media will get slower, but addurl of everything else
+will be as fast as before.
+
+But there's an unavoidable change to `addurl --relaxed`. It will not check
+for embedded media and more, because that would make it a lot slower, since
+it would have to hit the network. `addurl --fast` will have to be used for
+such urls instead. I hope this behavior change won't affect workflows
+badly.
+
+Today was all coding groundwork, and I just got to the point that I'm
+ready to have it run youtube-dl. Hope to finish it tomorrow.
+
+Today's work was sponsored by Jake Vosloo [on Patreon](https://www.patreon.com/joeyh).
diff --git a/doc/devblog/youtube-dl/comment_1_ff062ea66ea50d2f31a92c25017bb135._comment b/doc/devblog/youtube-dl/comment_1_ff062ea66ea50d2f31a92c25017bb135._comment
new file mode 100644
index 0000000000..172eee1b21
--- /dev/null
+++ b/doc/devblog/youtube-dl/comment_1_ff062ea66ea50d2f31a92c25017bb135._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="svw"
+ avatar="http://cdn.libravatar.org/avatar/539b90cb79086a2b1d7d3fbe48fd4184"
+ subject="Passing flags to youtube-dl"
+ date="2018-04-20T05:57:39Z"
+ content="""
+Joey - is there some way to pass flags to youtube-dl?
+
+For example the `--extract-audio` flag allows the extraction of just the audio stream.
+"""]]
diff --git a/doc/devblog/youtube-dl_day_2.mdwn b/doc/devblog/youtube-dl_day_2.mdwn
new file mode 100644
index 0000000000..a113339f72
--- /dev/null
+++ b/doc/devblog/youtube-dl_day_2.mdwn
@@ -0,0 +1,13 @@
+It's mostly working now. Still need to fix --fast and --relaxed, and avoid
+youtube-dl running out of the annex.diskreserve.
+
+The first hour or two was spent adding support for per-key temp
+directories. youtube-dl is run inside such a directory, to let it write
+whatever files it needs. Like the per-key temp files, these temp directories
+are not cleaned up when a download fails or is interrupted, so resuming can
+pick up where it left off. Taught `git annex dropunused` and everything
+else that cleans up per-key temp files to also clean up the temp
+directories.
+
+Today's work was sponsored by Trenton Cronholm on
+[Patreon](https://patreon.com/joeyh/)
diff --git a/doc/devblog/youtube-dl_day_3.mdwn b/doc/devblog/youtube-dl_day_3.mdwn
new file mode 100644
index 0000000000..bc868d25cd
--- /dev/null
+++ b/doc/devblog/youtube-dl_day_3.mdwn
@@ -0,0 +1,7 @@
+Finished up youtube-dl integration today, including all the edge cases in
+`addurl` and honoring annex.diskreserve.
+
+I changed my mind about `git annex addurl --relaxed`; it seems better for
+it to be slower than before, but not have surprising behavior, than to be
+fast but potentially surprising. If it's too slow, add `--raw` to avoid
+using youtube-dl.
diff --git a/doc/devblog/youtube-dl_day_3/comment_1_bcf6ccc65f191c446ae4ea70c4e86c87._comment b/doc/devblog/youtube-dl_day_3/comment_1_bcf6ccc65f191c446ae4ea70c4e86c87._comment
new file mode 100644
index 0000000000..f558092575
--- /dev/null
+++ b/doc/devblog/youtube-dl_day_3/comment_1_bcf6ccc65f191c446ae4ea70c4e86c87._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="Joseph Rawson"
+ subject="""comment 1"""
+ date="2017-12-31T16:23:04Z"
+ content="""
+Merry Christmas!  Thanks for adding this.  I was falling back to yt-dl when
+quvi failed.  I built from git last night and tested this.  I have a few
+comments and questions.
+
+- I am using debian/stretch.  Is yt-dl being used from system python package,
+or my virtualenv? (I have been preparing for py3 being default version in a
+couple of years.)
+
+- I have often used a terminal window and prefixed my input with "git-annex
+addurl" then drag links to the window for pasting.  Often, I have to press the
+up-arrow and run the command again.  The addurl behavior with urls that are
+already locally present, quvi responds "ok."  However, when repeating a command
+using yt-dl, when the url is already local, yt-dl refuses to overwrite, yet
+returns "failed."  I didn't know if you were aware of this.  This isn't a
+show-stopper, but just something I noticed.  I generally do "addurl" manually.
+
+- Playlist support.  Currently youtube-dl will allow you to download a whole
+playlist.  When I add a url "yt.com/watch?v=vidID&list=playlistID" only the
+video identified is downloaded.  This is a good default behavior.  When I add "
+yt.com/watch?list=listID" yt-dl successfully parses the whole list, but will
+only download one video from the list.
+"""]]
diff --git a/doc/devblog/youtube-dl_day_3/comment_2_423d1896981b9d5de85c89fdcde2d1ab._comment b/doc/devblog/youtube-dl_day_3/comment_2_423d1896981b9d5de85c89fdcde2d1ab._comment
new file mode 100644
index 0000000000..8ab6065d1f
--- /dev/null
+++ b/doc/devblog/youtube-dl_day_3/comment_2_423d1896981b9d5de85c89fdcde2d1ab._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-12-31T16:25:07Z"
+ content="""
+It uses whatever youtube-dl you have in PATH.
+
+I was not aware of the changed behavior when adding an url that's already
+locally present. I've opened [[bugs/addurl_youtube-dl_behavior_change]]
+to remember to look into it.
+
+The reason it only downloads one video from a playlist or channel is that
+git-annex needs to associate an url with the annexed file, so it can later
+download that single file when git-annex get is used, and there's no clear
+way to associate an url with a particular file that youtube-dl downloaded
+from a playlist or channel or whatever. [[tips/downloading_podcasts]] has a
+way to use `git annex importfeed` with a youtube playlist though.
+"""]]
diff --git a/doc/devblog/youtube-dl_day_3/comment_3_c3735d169bfe81eaba5557197b1c0eb0._comment b/doc/devblog/youtube-dl_day_3/comment_3_c3735d169bfe81eaba5557197b1c0eb0._comment
new file mode 100644
index 0000000000..904580913f
--- /dev/null
+++ b/doc/devblog/youtube-dl_day_3/comment_3_c3735d169bfe81eaba5557197b1c0eb0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joseph.rawson.works@85a210ab8c0e37a0b2d6bb235738b20e23e8878f"
+ nickname="joseph.rawson.works"
+ avatar="http://cdn.libravatar.org/avatar/6b473d5484b68803e8c47eeff9197397"
+ subject="Download playlist"
+ date="2018-01-06T20:34:31Z"
+ content="""
+Thanks!  I'll try testing the ```importfeed``` now!
+"""]]
diff --git a/doc/devblog/youtube-dl_day_3/comment_4_d19a698b28a5d6b583c527b9a909370d._comment b/doc/devblog/youtube-dl_day_3/comment_4_d19a698b28a5d6b583c527b9a909370d._comment
new file mode 100644
index 0000000000..a2a9be207c
--- /dev/null
+++ b/doc/devblog/youtube-dl_day_3/comment_4_d19a698b28a5d6b583c527b9a909370d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joseph.rawson.works@85a210ab8c0e37a0b2d6bb235738b20e23e8878f"
+ nickname="joseph.rawson.works"
+ avatar="http://cdn.libravatar.org/avatar/6b473d5484b68803e8c47eeff9197397"
+ subject="testing importfeed"
+ date="2018-01-06T21:57:06Z"
+ content="""
+I tested importfeed.  It seemed to be stuck on ```importfeed checking known urls```.  The first playlist I tried had 70+ videos, so I tested a shorter playlist and got the same response.  I noticed that on the [[tips/downloading_podcasts]] page, only channels are mentions, but not playlists.  However, you mentioned playlists in your response.  I was able to work around the issue:
+
+```for _id in `youtube-dl 'https://www.youtube.com/watch?v=ps40Uminvno&list=PLWnVxuqvY7Jj2Z8aeR-qKXACCXUN4Ouv_' --get-id` ; do echo \"https://www.youtube.com/watch?v=${_id}\" ; done | git-annex addurl --batch --jobs 2```
+
+"""]]
diff --git a/doc/direct_mode.mdwn b/doc/direct_mode.mdwn
new file mode 100644
index 0000000000..c3cf8dc10a
--- /dev/null
+++ b/doc/direct_mode.mdwn
@@ -0,0 +1,14 @@
+Normally, git-annex repositories consist of symlinks that are checked into
+git, and in turn point at the content of large files that is stored in
+`.git/annex/objects/`. Direct mode was a hack to avoid the symlinks.
+
+The advantage of direct mode was that you can access files directly,
+including modifying them. The disadvantage was that many regular git
+commands could not used in a direct mode repository, since they don't
+understand how to update its working tree.
+
+Direct mode has been removed from git-annex as of version 7.20190826.
+The first time a new git-annex is run in a direct mode repository,
+it automatically converts it to a v7 repository with 
+[[unlocked|tips/unlocked files]]. See [[upgrades]] for details
+about the transition to v7 repositories.
diff --git a/doc/direct_mode/comment_11_1c79c93f4b17cfc354ab920e3775cc60._comment b/doc/direct_mode/comment_11_1c79c93f4b17cfc354ab920e3775cc60._comment
new file mode 100644
index 0000000000..ad1b66bc07
--- /dev/null
+++ b/doc/direct_mode/comment_11_1c79c93f4b17cfc354ab920e3775cc60._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://www.gl-como.it/author/valhalla/"
+ nickname="valhalla"
+ subject="Direct mode clone of an indirect repo"
+ date="2013-08-18T08:47:35Z"
+ content="""
+I too have issues with mixing direct and indirect mode repositories.
+
+ I have a regular, existing repository with ebooks, shared between various clones on proper :) filesystems; now I would need a copy of some of them on an ereader which only offers a FAT filesystem, so it has to be direct mode.
+
+    mount $READER
+    cd $reader
+    git clone $REPO
+
+I get a directory full of small files, the way git manages links on FAT.
+
+    git annex init \"ebook reader\"
+
+This detects the fact that it is working on a crippled filesystem, enables direct mode and disables ssh connection caching; up to now everything seems to be fine, but then
+
+    git annex get $SOME_BOOK
+
+seems to work, downloads the file somewhere, but when I try to open $SOME_BOOK it is still the fake link, and the file has been downloaded in its destination, as if the repo wasn't in direct mode.
+
+I use version 4.20130723 on debian jessie
+"""]]
diff --git a/doc/direct_mode/comment_12_1b5218fdb6ee362d6df68ff1229590d4._comment b/doc/direct_mode/comment_12_1b5218fdb6ee362d6df68ff1229590d4._comment
new file mode 100644
index 0000000000..1743d5df99
--- /dev/null
+++ b/doc/direct_mode/comment_12_1b5218fdb6ee362d6df68ff1229590d4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 12"
+ date="2013-08-23T17:48:54Z"
+ content="""
+There should be no obstacles to using direct mode on one clone of a git repository, and indirect mode on another clone. The data stored in git for either mode is identical, and I do this myself for some repositories.
+
+@valhalla, you probably need to run `git annex fsck`, and if that does not solve your problem, you need to file a bug report.
+"""]]
diff --git a/doc/direct_mode/comment_12_7d507b6f87085a19d8dd5014f580922b._comment b/doc/direct_mode/comment_12_7d507b6f87085a19d8dd5014f580922b._comment
new file mode 100644
index 0000000000..bc8f006800
--- /dev/null
+++ b/doc/direct_mode/comment_12_7d507b6f87085a19d8dd5014f580922b._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="http://mildred.fr/"
+ ip="82.247.184.53"
+ subject="Fixing symlinks to the annex store in direct mode"
+ date="2014-07-16T06:52:33Z"
+ content="""
+I have an issue with direct mode: I have tons of symlinks that points to the git-annex store, while in direct mode. After investigation, I found that these files don't seem to be part of the repository. I can check with:
+
+    $ git -c core.bare=false status --porcelain tr.html
+    ?? Documentation/Mozilla/developer.mozilla.org/tr.html
+
+    $ ls -l tr.html
+    lrwxrwxrwx 1 mildred mildred 205 10 juin  16:22 tr.html -> ../../../.git/annex/objects/gF/z1/SHA256E-s31895--c873982bd742ba8db6e026afee26b7ab2f75f54f587304d8c2d877db3900c0f6.html/SHA256E-s31895--c873982bd742ba8db6e026afee26b7ab2f75f54f587304d8c2d877db3900c0f6.html
+
+The link is valid, and is probably pointing to a unused file in the annex store. How to add these files back?
+
+If I was in indirect mode, I could simply use `git add tr.html` (and **not** `git annex add`). This would stage to the git staging area the symlink, and all would be well.
+
+I found that in direct mode, the same was true. The command is: 
+
+    git -c core.bare=false add tr.html
+
+The file is added to the repository, and the link is converted to the target file. The question now is why? There is no hook on the add command. Could it be the annex assistant? If that didn't worked, my question would have been: how to checkout a file in direct mode?
+"""]]
diff --git a/doc/direct_mode/comment_13_5169c5541970d3b3bc1e080e07539b22._comment b/doc/direct_mode/comment_13_5169c5541970d3b3bc1e080e07539b22._comment
new file mode 100644
index 0000000000..7d15fca6f8
--- /dev/null
+++ b/doc/direct_mode/comment_13_5169c5541970d3b3bc1e080e07539b22._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://mildred.fr/"
+ ip="82.247.184.53"
+ subject="Re: Fixing symlinks to the annex store in direct mode"
+ date="2014-07-16T07:04:08Z"
+ content="""
+What I said was just wrong. Instead of trying on tr.html, I tried with a copy of that file. But making the copy of that file had the wanted effect, transforming the symlink to the actual file. Probably the assistant monitoring file creation, and transforming indirect file to direct file. Or perhaps the `cp` command follows symlinks by default (I thought it didn't).
+"""]]
diff --git a/doc/direct_mode/comment_13_55108ac736ea450df89332ba5de4a208._comment b/doc/direct_mode/comment_13_55108ac736ea450df89332ba5de4a208._comment
new file mode 100644
index 0000000000..b8d80cd7ea
--- /dev/null
+++ b/doc/direct_mode/comment_13_55108ac736ea450df89332ba5de4a208._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 13"
+ date="2013-08-23T17:50:15Z"
+ content="""
+@obergix asked:
+
+> But then, how can a direct repo sync with changes made in other remotes, if there no pull/fetch available.
+
+The answer is simple: By running `git annex sync`, which handles all that.
+"""]]
diff --git a/doc/direct_mode/comment_14_03a02e689d92faa596de98e02b2ffe28._comment b/doc/direct_mode/comment_14_03a02e689d92faa596de98e02b2ffe28._comment
new file mode 100644
index 0000000000..ce47a5eb8c
--- /dev/null
+++ b/doc/direct_mode/comment_14_03a02e689d92faa596de98e02b2ffe28._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 14"
+ date="2014-07-16T17:51:28Z"
+ content="""
+I kinda wish people would post questions to the forum, and not clutter up this page..
+
+Anyway, there have been past bugs in the direct mode code that caused some files to not be checked out in direct mode, but stay as symlinks pointing at the content. That can be fixed by running `git annex fsck`. But, I am not aware of any problem that can leave a git-annex symlink that is not checked into git at all. Perhaps you copied the symlink from another location?
+"""]]
diff --git a/doc/direct_mode/comment_14_ff4ffc2aabc5fd174d7386ef13860f78._comment b/doc/direct_mode/comment_14_ff4ffc2aabc5fd174d7386ef13860f78._comment
new file mode 100644
index 0000000000..3a538e00b3
--- /dev/null
+++ b/doc/direct_mode/comment_14_ff4ffc2aabc5fd174d7386ef13860f78._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://olivier.berger.myopenid.com/"
+ nickname="obergix"
+ subject="Git annex copy needed before git annex sync"
+ date="2013-08-23T19:59:35Z"
+ content="""
+Thanks for these details @joeyh. But AFAIU, one needs to proceed to the git annex copy before doing the git annex sync, otherwise, symlinks (or files containing the symlink path on SMB) will be created, instead of the plain \"direct\" files that are expected.
+
+I'm still not sure whether the git annex sync needs to be issued on either of the indirect or direct remotes first, or both, then in which sequence. I think a \"walkthrough\" script would help.
+"""]]
diff --git a/doc/direct_mode/comment_15_1cd32456630b25d5aaa6d2763e6eb384._comment b/doc/direct_mode/comment_15_1cd32456630b25d5aaa6d2763e6eb384._comment
new file mode 100644
index 0000000000..d265118a04
--- /dev/null
+++ b/doc/direct_mode/comment_15_1cd32456630b25d5aaa6d2763e6eb384._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 15"
+ date="2013-08-24T15:56:47Z"
+ content="""
+No, you can sync before you copy, get, or whatever. git-annex will replace the symlinks with the actual files when they arrive at the repository.
+"""]]
diff --git a/doc/direct_mode/comment_15_599b2285d24ae1244a1945d572b2c397._comment b/doc/direct_mode/comment_15_599b2285d24ae1244a1945d572b2c397._comment
new file mode 100644
index 0000000000..d8c5e825fc
--- /dev/null
+++ b/doc/direct_mode/comment_15_599b2285d24ae1244a1945d572b2c397._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmjjrCHEIa4vpDIJoBuJsrF3y8wZQElVHw"
+ nickname="Siyuan"
+ subject="Non-direct mode for Windows"
+ date="2014-10-08T15:55:04Z"
+ content="""
+Why Windows is restricted to direct mode? NTFS has symbolic links too. Is that fundamentally different from POSIX symlinks that it cannot be done?
+"""]]
diff --git a/doc/direct_mode/comment_16_7f6805e090d0acd8a077b65214da5837._comment b/doc/direct_mode/comment_16_7f6805e090d0acd8a077b65214da5837._comment
new file mode 100644
index 0000000000..d40ee9e985
--- /dev/null
+++ b/doc/direct_mode/comment_16_7f6805e090d0acd8a077b65214da5837._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 16"
+ date="2015-02-17T05:22:00Z"
+ content="""
+i believe this is [answered here](https://git-annex.branchable.com/todo/windows_support/#comment-e72601243c643d7821e68d3a04489fcb). TLDR; basically NTFS + symlink works in Linux, but not in Windows/Cygwin, which git-annex seems to be using. YMMV.
+"""]]
diff --git a/doc/direct_mode/comment_17_e7c066fba8e28c61e8517c7a18a02457._comment b/doc/direct_mode/comment_17_e7c066fba8e28c61e8517c7a18a02457._comment
new file mode 100644
index 0000000000..6847c5f9ee
--- /dev/null
+++ b/doc/direct_mode/comment_17_e7c066fba8e28c61e8517c7a18a02457._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="mitzip"
+ subject="--depth undo option"
+ date="2015-05-27T02:54:17Z"
+ content="""
+Well I just spent 4 hours building a OSX GUI around git annex undo --depth and it responds with \"git-annex: unrecognized option '--depth'\"... lol Please tell me that option exists somewhere other than the documentation... lol
+"""]]
diff --git a/doc/direct_mode/comment_18_e46f70efa6d8d65d5ef81cdcbd844869._comment b/doc/direct_mode/comment_18_e46f70efa6d8d65d5ef81cdcbd844869._comment
new file mode 100644
index 0000000000..ed9d016519
--- /dev/null
+++ b/doc/direct_mode/comment_18_e46f70efa6d8d65d5ef81cdcbd844869._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-27T18:31:26Z"
+ content="""
+This page mentioned a --depth option, but no, it was never implemented.
+I have updated this page.
+
+If you need something simpler than the basic undo, you can use `git annex
+proxy` to run eg, a `git revert`.
+
+(Deleted a forum thread that duplicated the previous comment.)
+"""]]
diff --git a/doc/direct_mode/comment_19_f4f23d9be76fa3c201b6c67efab0d69c._comment b/doc/direct_mode/comment_19_f4f23d9be76fa3c201b6c67efab0d69c._comment
new file mode 100644
index 0000000000..1d47744bbb
--- /dev/null
+++ b/doc/direct_mode/comment_19_f4f23d9be76fa3c201b6c67efab0d69c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 19"
+ date="2018-09-19T19:12:58Z"
+ content="""
+This page says direct mode is \"deprecated\"; but, v6 is not yet official ( https://git-annex.branchable.com/forum/default_repo_version_is_still_5__63__/ )?  So, for now, direct mode is the recommended thing to use?
+"""]]
diff --git a/doc/direct_mode/comment_20_4d0077d7881df05dcbeb460bf7734b6b._comment b/doc/direct_mode/comment_20_4d0077d7881df05dcbeb460bf7734b6b._comment
new file mode 100644
index 0000000000..803b263cd0
--- /dev/null
+++ b/doc/direct_mode/comment_20_4d0077d7881df05dcbeb460bf7734b6b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 20"""
+ date="2018-09-24T15:40:48Z"
+ content="""
+Indirect mode is the recommended thing to use, except for situations where
+it doesn't work, then direct mode is used as a fallback.
+
+v6 is getting fairly close to working better than direct mode at this
+point.
+"""]]
diff --git a/doc/direct_mode/comment_3_8020d74bddf0e38b0a297e5dae7c217b._comment b/doc/direct_mode/comment_3_8020d74bddf0e38b0a297e5dae7c217b._comment
new file mode 100644
index 0000000000..f89cafe533
--- /dev/null
+++ b/doc/direct_mode/comment_3_8020d74bddf0e38b0a297e5dae7c217b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl2Jj8q2upJL4ZQAc2lp7ugTxJiGtcICv8"
+ nickname="Michael"
+ subject="comment 3"
+ date="2013-02-19T03:03:14Z"
+ content="""
+So, if I edit a \"content file\" (change a music file's metadata, say), what's the workflow to record that fact and then synchronise it to other repositories?
+
+I can't do a `git add`, so I don't understand what has to happen as a first step.  (Thanks for your quick reply above, BTW.)
+
+
+"""]]
diff --git a/doc/direct_mode/comment_4_97c26bd82f623a3b2d56bab4afff0126._comment b/doc/direct_mode/comment_4_97c26bd82f623a3b2d56bab4afff0126._comment
new file mode 100644
index 0000000000..cf5ae2fb64
--- /dev/null
+++ b/doc/direct_mode/comment_4_97c26bd82f623a3b2d56bab4afff0126._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.183"
+ subject="comment 4"
+ date="2013-02-19T03:05:35Z"
+ content="""
+<pre>
+git annex add $file
+git annex sync
+git annex copy $file --to otherrepo
+</pre>
+"""]]
diff --git a/doc/direct_mode/comment_5_42363bf0367f935b3eee8ad3d2eaf5cf._comment b/doc/direct_mode/comment_5_42363bf0367f935b3eee8ad3d2eaf5cf._comment
new file mode 100644
index 0000000000..d4e2962a64
--- /dev/null
+++ b/doc/direct_mode/comment_5_42363bf0367f935b3eee8ad3d2eaf5cf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="mildred"
+ ip="2a01:e35:2f7b:8350:225:22ff:fe40:fdfc"
+ subject="What happens to object database in direct mode?"
+ date="2013-07-08T13:27:21Z"
+ content="""
+What happens to the object database (`.git/annex/objects`) when going to direct mode? Are the objects deleted, moved to another location, kept?
+
+If the objects are kept, does it means that the file on the repository in direct mode is duplicated in the object database? If so, would it be relevant to use `cp --reflink=auto` to populate the working directory to enable copy on write on filesystems that supports it?
+"""]]
diff --git a/doc/direct_mode/comment_6_5f03b1686c1fb3f7606a5bc724ac3812._comment b/doc/direct_mode/comment_6_5f03b1686c1fb3f7606a5bc724ac3812._comment
new file mode 100644
index 0000000000..1cdb9a79c7
--- /dev/null
+++ b/doc/direct_mode/comment_6_5f03b1686c1fb3f7606a5bc724ac3812._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.254.222"
+ subject="comment 6"
+ date="2013-07-08T16:11:32Z"
+ content="""
+`.git/annex/objects` does not typically contain any file contents in direct mode. The file contents are stored directly in the working tree.
+"""]]
diff --git a/doc/direct_mode/comment_7_5355ac418bfb26e990762b80f4c36b77._comment b/doc/direct_mode/comment_7_5355ac418bfb26e990762b80f4c36b77._comment
new file mode 100644
index 0000000000..d416a01f62
--- /dev/null
+++ b/doc/direct_mode/comment_7_5355ac418bfb26e990762b80f4c36b77._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://caust1c.myopenid.com/"
+ nickname="asbraithwaite"
+ subject="comment 7"
+ date="2013-08-12T18:06:21Z"
+ content="""
+Would it be safe to add largefiles to gitignore in direct mode?
+
+Can git-annex still track large files ignored by git?
+
+Thanks. :-)
+"""]]
diff --git a/doc/direct_mode/comment_8_6cd15e2c5fd0bef48f60c6993322c2fc._comment b/doc/direct_mode/comment_8_6cd15e2c5fd0bef48f60c6993322c2fc._comment
new file mode 100644
index 0000000000..72ba16baf4
--- /dev/null
+++ b/doc/direct_mode/comment_8_6cd15e2c5fd0bef48f60c6993322c2fc._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="arand"
+ ip="130.243.226.21"
+ subject="comment 8"
+ date="2013-08-12T18:12:32Z"
+ content="""
+asbraithwaite:
+No, as far as I know it can not.
+"""]]
diff --git a/doc/distributed_version_control.mdwn b/doc/distributed_version_control.mdwn
new file mode 100644
index 0000000000..ccf82b91c7
--- /dev/null
+++ b/doc/distributed_version_control.mdwn
@@ -0,0 +1,21 @@
+In git, there can be multiple clones of a repository, each clone can 
+be independently modified, and clones can push or pull changes to
+one-another to get back in sync.
+
+git-annex preserves that fundamental distributed nature of git, while
+dropping the requirement that, once in sync, each clone contains all the data
+that was committed to each other clone. Instead of storing the content
+of a file in the repository, git-annex stores a pointer to the content.
+
+Each git-annex repository is responsible for storing some of the content,
+and can copy it to or from other repositories. [[Location_tracking]]
+information is committed to git, to let repositories inform other
+repositories what file contents they have available.
+
+---
+
+The [[walkthrough]] shows how to create a distributed set of git-annex
+repositories with no central repository.
+
+Prefer a central repository like GitHub? See the
+[[tips/centralized_git_repository_tutorial]].
diff --git a/doc/download.mdwn b/doc/download.mdwn
new file mode 100644
index 0000000000..9fbd9878d7
--- /dev/null
+++ b/doc/download.mdwn
@@ -0,0 +1,30 @@
+The main git repository for git-annex is `git://git-annex.branchable.com/`
+[[gitweb](http://source.git-annex.branchable.com/?p=source.git;a=summary)]
+
+(You can push changes to this wiki from that anonymous git checkout.)
+
+Other mirrors of the git repository:
+
+* `git://git.joeyh.name/git-annex` or `https://git.joeyh.name/git/git-annex.git` [[gitweb](https://git.joeyh.name/index.cgi/git-annex.git/)]
+
+Releases of git-annex are uploaded
+[to hackage](http://hackage.haskell.org/package/git-annex). Note that the
+tarball there is not the complete git-annex source tree, but only a subset
+to make cabal/stack install work. Use git to checkout the full source tree.
+
+Some operating systems include git-annex in easily prepackaged form and
+others need some manual work. See [[install]] for details.
+
+## git branches
+
+The git repository has some branches, including:
+
+* `ghc7.0` is a by now very out of date branch that can be built with
+  ghc 7.0.
+* `debian-*-backport` contains the latest backport of git-annex.
+* `setup` contains configuration for this website
+
+----
+
+Developing git-annex? Patches are very welcome.
+You should read [[coding_style]].
diff --git a/doc/download/comment_1_ec2578241a966cfcdd43f2a26a5c8709._comment b/doc/download/comment_1_ec2578241a966cfcdd43f2a26a5c8709._comment
new file mode 100644
index 0000000000..e242230a05
--- /dev/null
+++ b/doc/download/comment_1_ec2578241a966cfcdd43f2a26a5c8709._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm3uJkdiJJejvqix9dULvw_Ma7DCtB-6zA"
+ nickname="Ian"
+ subject="git clone git://git-annex.branchable.com/ gives an error"
+ date="2012-08-13T20:57:34Z"
+ content="""
+Thought you would want to know
+
+error: unable to create file doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2_however_syb-0.1.0.2_was_excluded_because_json-0.5_requires_syb___62____61__0.3.3.mdwn (File name too long)
+fatal: cannot create directory at 'doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2_however_syb-0.1.0.2_was_excluded_because_json-0.5_requires_syb___62____61__0.3.3': File name too long
+
+
+"""]]
diff --git a/doc/download/comment_2_ee0d158ac59903737dbc4ef632f11fe3._comment b/doc/download/comment_2_ee0d158ac59903737dbc4ef632f11fe3._comment
new file mode 100644
index 0000000000..d3024217a9
--- /dev/null
+++ b/doc/download/comment_2_ee0d158ac59903737dbc4ef632f11fe3._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 2"
+ date="2012-08-16T23:28:30Z"
+ content="""
+Ok, I've renamed that long-ish filename.
+"""]]
diff --git a/doc/download/comment_3_b59fc32a18a9fda8da120da82fade0a6._comment b/doc/download/comment_3_b59fc32a18a9fda8da120da82fade0a6._comment
new file mode 100644
index 0000000000..27fa71ca08
--- /dev/null
+++ b/doc/download/comment_3_b59fc32a18a9fda8da120da82fade0a6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jckuester@11e9fceb442172b6db63320bb545797a47a4c103"
+ nickname="jckuester"
+ subject="error during &quot;git clone git://git.kitenet.net/git-annex&quot;"
+ date="2015-11-22T15:38:57Z"
+ content="""
+error: unable to create file doc/bugs/On_Lubuntu_14.04_assistant_fails_to_create_new_setup_or_actually_work___40__fixed_by_regular_lxsession_package_update_from_2014-06-30__41__.mdwn (File name too long)
+fatal: unable to checkout working tree
+"""]]
diff --git a/doc/download/comment_4_bf102d87552f97ac293dd20f6822b84f._comment b/doc/download/comment_4_bf102d87552f97ac293dd20f6822b84f._comment
new file mode 100644
index 0000000000..2993a6e101
--- /dev/null
+++ b/doc/download/comment_4_bf102d87552f97ac293dd20f6822b84f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-11-30T19:13:34Z"
+ content="""
+I guess you guys with the badly limited filename lenghs are using encfs or
+something like that. encfs is [really shoddy](https://defuse.ca/audits/encfs.htm),
+and I feel kind of like someone is complaining that the git repo can't be
+checked out on MS-DOS. 
+8.3 filenames are so 1985, and 128 filenames are so.. 1995?
+"""]]
diff --git a/doc/encryption.mdwn b/doc/encryption.mdwn
new file mode 100644
index 0000000000..970232d216
--- /dev/null
+++ b/doc/encryption.mdwn
@@ -0,0 +1,157 @@
+[[!toc]]
+
+git-annex mostly does not use encryption. Anyone with access to a git
+repository can see all the filenames in it, its history, and can access
+any annexed file contents.
+
+Encryption is needed when using [[special_remotes]] like Amazon S3, where
+file content is sent to an untrusted party who does not have access to the
+git repository.
+
+Such an encrypted remote uses strong ([[symmetric|design/encryption]] or
+asymmetric) encryption on the contents of files, as well as HMAC hashing
+of the filenames. The size of the encrypted files, and access patterns
+of the data, should be the only clues to what is stored in such a
+remote.
+
+You should decide whether to use encryption with a special remote before
+any data is stored in it. So, `git annex initremote` requires you
+to specify "encryption=none" when first setting up a remote in order
+to disable encryption. To use encryption, you run
+`git-annex initremote` in one of these ways:
+
+* `git annex initremote newremote type=... encryption=hybrid keyid=KEYID`
+* `git annex initremote newremote type=... encryption=shared`
+* `git annex initremote newremote type=... encryption=pubkey keyid=KEYID`
+* `git annex initremote newremote type=... encryption=sharedpubkey keyid=KEYID`
+
+To see what encryption is used for a special remote, run
+`git annex info $remote` and look for a line like:
+
+	encryption: hybrid (to gpg keys: AEC828149D85C538 C910D9122512E3C8)
+
+## hybrid encryption keys (encryption=hybrid)
+
+The [[hybrid_key_design|design/encryption]] allows additional
+encryption keys to be added on to a special remote later. Due to this
+flexibility, it is the default and recommended encryption scheme.
+
+	git annex initremote newremote type=... [encryption=hybrid] keyid=KEYID
+
+The KEYID is passed to `gpg` to find a gpg key.
+Typically, you will say "keyid=2512E3C7" to use a specific gpg key.
+Or, you might say "keyid=id@joeyh.name" to search for matching keys.
+
+To add a new key and allow it to access all the content that is stored
+in the encrypted special remote, just run `git annex
+enableremote` specifying the keyid to add:
+
+	git annex enableremote myremote keyid+=788A3F4C
+
+You can repeat this process to add any number of gpg keys, including
+your own gpg keys and any public keys of others who you want to give
+access. Anyone with a corresponding secret key will be able to decrypt
+all content that is stored in the remote.
+
+While a key can later be removed from the list, note that it will **not**
+prevent the owner of the key from accessing data on the remote (which is by
+design impossible to prevent, short of deleting the remote). In fact the
+only sound use of `keyid-=` is probably to replace a revoked key:
+
+	git annex enableremote myremote keyid-=2512E3C7 keyid+=788A3F4C
+
+See also [[encryption_design|design/encryption]] for other security
+risks associated with encryption.
+
+## shared encryption key (encryption=shared)
+
+Alternatively, you can configure git-annex to use a shared cipher to
+encrypt data stored in a remote. This shared cipher is stored,
+**unencrypted** in the git repository. So it's shared among every
+clone of the git repository.
+
+	git annex initremote newremote type=... encryption=shared
+
+The advantage is you don't need to set up gpg keys. The disadvantage is
+that this is **insecure** unless you trust every clone of the git
+repository with access to the encrypted data stored in the special remote.
+
+By default `gpg` is used for shared encryption, but it is also possible to
+use other programs that implement the Stateless OpenPGP command line
+interface. For example, to use Sequoia PGP's `sqop` command, configured to
+be backwards compatable with `gpg`:
+
+    git config annex.shared-sop-command sqop
+    git config annex.shared-sop-profile rfc4880
+
+## regular public key encryption (encryption=pubkey)
+
+This alternative simply encrypts the files in the special remotes to one or
+more public keys. The corresponding private key is needed to store
+anything in the remote, or access anything stored in it.
+It might be considered more secure due to its simplicity and since
+it's exactly the way everyone else uses gpg.
+
+	git annex initremote newremote type=.... encryption=pubkey keyid=KEYID
+
+A disadvantage is that it is not easy to later add additional public keys
+to the special remote. While the `enableremote` parameters `keyid+=` and
+`keyid-=` can be used, they have **no effect** on encrypted files that
+are already stored in the remote. 
+
+So if you need other public keys to also have access, it's best to add them
+immediately after initializing the remote:
+
+	git-annex initremote newremote keyid+=788A3F4C
+
+Another use for these parameters is to replace a revoked key:
+
+	git annex enableremote myremote keyid-=2512E3C7 keyid+=788A3F4C
+
+But even in this case, since the files are not re-encrypted, the revoked
+key has to be kept around to be able to decrypt those files.
+(Of course, if the reason for revocation is
+that the key has been compromised, it is **insecure** to leave files
+encrypted using that old key, and the user should re-encrypt everything.)
+
+(A cipher still needs to be generated (and is encrypted to the given key IDs).
+It is only used for HMAC encryption of filenames.)
+
+## regular public key encryption with shared filename encryption (encryption=sharedpubkey)
+
+This is a variation on encryption=pubkey which lets anyone who
+has access to the gpg public keys store files in the special remote.
+But, only owners of the corresponding gpg private keys can retrieve the files
+from the special remote.
+
+	git annex initremote newremote type=... encryption=sharedpubkey keyid=KEYID
+
+This might be useful if you want to let others drop off files for you in a
+special remote, so that only you can access them.
+
+The filenames used on the special remote are encrypted using HMAC,
+which prevents the special remote from seeing the filenames. But, anyone
+who can clone the git repository can access the HMAC cipher; it's stored
+**unencrypted** in the git repository.
+
+## MAC algorithm
+
+The default MAC algorithm to be applied on the filenames is HMACSHA1. A
+stronger one, for instance HMACSHA512, can be chosen upon creation
+of the special remote with the option `mac=HMACSHA512`. The available
+MAC algorithms are HMACSHA1, HMACSHA224, HMACSHA256, HMACSHA384, and
+HMACSHA512. Note that it is not possible to change algorithm for a
+non-empty remote.
+
+## credentials storage
+
+Special remotes that need some form of credentials, such as a password,
+may support embedding the credentials in the git repository, using
+embedcreds=yes. See individual special remotes' documentation for details.
+When credentials are embedded in the repository, they're also encrypted using
+whatever encryption setting has been selected for the repository.
+
+Such credentials are also cached locally in a file only you can read,
+in `.git/annex/creds/`. If you prefer to not expose the credentials on disk
+in unencrypted form, you can disable this cache, by setting the
+`annex.cachecreds` config to `false`.
diff --git a/doc/encryption/comment_10_6416ee43ffad1c306ef71247ae71a6c5._comment b/doc/encryption/comment_10_6416ee43ffad1c306ef71247ae71a6c5._comment
new file mode 100644
index 0000000000..ae2fb88a49
--- /dev/null
+++ b/doc/encryption/comment_10_6416ee43ffad1c306ef71247ae71a6c5._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2017-05-24T17:47:46Z"
+ content="""
+@Yurt, git-annex will let you specify the gpg key id using anything that gpg
+accepts, including a keyid with a appended '!'. However, when I tried that,
+gpg seemed to still pick the master key instead of the subkey. That
+happens because git-annex runs the input through `gpg --list-public-keys`
+(in order to convert eg, email addresses to key ids)
+which always lists the master key even when given a subkey.
+
+I made a small change to git-annex to special case this '!' suffix
+behavior. Seems to work in my very limited testing.
+
+Please file bug reports about this kind of thing!
+"""]]
diff --git a/doc/encryption/comment_11_30b926fbabe9a0089de1f55f6f9a5d2d._comment b/doc/encryption/comment_11_30b926fbabe9a0089de1f55f6f9a5d2d._comment
new file mode 100644
index 0000000000..5cddcfee49
--- /dev/null
+++ b/doc/encryption/comment_11_30b926fbabe9a0089de1f55f6f9a5d2d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="headless configs"
+ date="2018-05-17T21:02:32Z"
+ content="""
+is there some combination of this and the gcrypt special remote that would give me the following properties:
+
+ 1. password-less operation (ie. allow uploading content without the private key)
+ 2. easy revocation and key rotation (ie. not encrypt directly with GnuPG but instead encrypt a keyfile with the public keys)
+
+It seems to me this would be technically possible, no? A mix of \"hybrid\" and \"sharedpubkey\", basically...?
+
+Hybrid works great, except I can't use it in my scenario because I am trying to automate backups and it will prompt me for the private key password. I guess the solution here is to have a special unencrypted private key for the batch job? Thanks! -- [[anarcat]
+"""]]
diff --git a/doc/encryption/comment_12_51fd19bf174906b1dd1461efd6ce3798._comment b/doc/encryption/comment_12_51fd19bf174906b1dd1461efd6ce3798._comment
new file mode 100644
index 0000000000..64bd3d3115
--- /dev/null
+++ b/doc/encryption/comment_12_51fd19bf174906b1dd1461efd6ce3798._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="johannes@f7951ad4aa9c858952712114847f969dde63b172"
+ nickname="johannes"
+ avatar="http://cdn.libravatar.org/avatar/5a2ee3d066dbffac3a2b14b3cffbebb0"
+ subject="Option to disable filename encyprtion"
+ date="2018-12-29T01:13:20Z"
+ content="""
+Are there plans to have a mac=PLAIN/NONE option?
+"""]]
diff --git a/doc/encryption/comment_13_44c6a401526a6ee22d5f0316336d453b._comment b/doc/encryption/comment_13_44c6a401526a6ee22d5f0316336d453b._comment
new file mode 100644
index 0000000000..e21f44bbe7
--- /dev/null
+++ b/doc/encryption/comment_13_44c6a401526a6ee22d5f0316336d453b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="datamanager"
+ avatar="http://cdn.libravatar.org/avatar/7d4ca7c5e571d4740ef072b83a746c12"
+ subject="Can I manually decrypt my files?"
+ date="2021-04-13T20:04:31Z"
+ content="""
+I have a dropbox remote configured, and `git annex copy/move/get/etc` all seem to work just fine. I have hybrid encryption enabled on the remote, using my gpg key. So I thought, what if I were to download the encrypted file, and attempt to decrypt it locally. Would that work?
+It didn't work. Maybe I'm doing something wrong? I simply download the file through rclone, or the dropbox interface, and run `gpg --decrypt filename....` pinentry does ask for my password, but I don't think it's asking for the password to my gpg key. Maybe the file is encrypted twice? Once with my key, and again using a generic password that git-annex knows? I am not sure.
+Any help would be appreciated!
+"""]]
diff --git a/doc/encryption/comment_14_5832365e198284c93d4a505856932841._comment b/doc/encryption/comment_14_5832365e198284c93d4a505856932841._comment
new file mode 100644
index 0000000000..c98b76a910
--- /dev/null
+++ b/doc/encryption/comment_14_5832365e198284c93d4a505856932841._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-13T20:30:33Z"
+ content="""
+See
+<https://git-annex.branchable.com/tips/Decrypting_files_in_special_remotes_without_git-annex/>
+for a small shell script that can do it.
+"""]]
diff --git a/doc/encryption/comment_14_fb6ec1f42789a62358605e293b678318._comment b/doc/encryption/comment_14_fb6ec1f42789a62358605e293b678318._comment
new file mode 100644
index 0000000000..a4f553ae53
--- /dev/null
+++ b/doc/encryption/comment_14_fb6ec1f42789a62358605e293b678318._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="hybrid encryption"
+ date="2021-04-13T20:30:43Z"
+ content="""
+With [[hybrid encryption|design/encryption]], your gpg key encrypts a symmetric key which then encrypts file content.  Try getting the encrypted symmetric key from [[`remote.log`|internals]], decrypting it with your gpg key, then using that to decrypt file content.
+"""]]
diff --git a/doc/encryption/comment_16_5dc76b832ae6b1bb7f458bf8e2650e8e._comment b/doc/encryption/comment_16_5dc76b832ae6b1bb7f458bf8e2650e8e._comment
new file mode 100644
index 0000000000..c642cddc50
--- /dev/null
+++ b/doc/encryption/comment_16_5dc76b832ae6b1bb7f458bf8e2650e8e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="datamanager"
+ avatar="http://cdn.libravatar.org/avatar/7d4ca7c5e571d4740ef072b83a746c12"
+ subject="reply"
+ date="2021-04-18T15:38:33Z"
+ content="""
+>  Try getting the encrypted symmetric key from remote.log
+
+Sorry, but where is that file? `find ./ -type f -name *.log` doesn't show me anything in this repository. 
+
+
+"""]]
diff --git a/doc/encryption/comment_17_a2195a298f65e427fe8460c8bc380f99._comment b/doc/encryption/comment_17_a2195a298f65e427fe8460c8bc380f99._comment
new file mode 100644
index 0000000000..ec0a772f35
--- /dev/null
+++ b/doc/encryption/comment_17_a2195a298f65e427fe8460c8bc380f99._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 17"
+ date="2021-04-18T15:40:55Z"
+ content="""
+It’s on the git-annex branch.  See [[internals]].
+"""]]
diff --git a/doc/encryption/comment_1_4257e3c4ae559f1c0595a903f738fd7e._comment b/doc/encryption/comment_1_4257e3c4ae559f1c0595a903f738fd7e._comment
new file mode 100644
index 0000000000..e1decc397c
--- /dev/null
+++ b/doc/encryption/comment_1_4257e3c4ae559f1c0595a903f738fd7e._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlZ-6dtxJY4cP7shhvV8E6YyuV0Rak8it4"
+ nickname="Giovanni"
+ subject="comment 1"
+ date="2015-03-10T22:16:09Z"
+ content="""
+I have a gcrypt special remote encrypted in hybrid mode, when I try to add a keyid using:
+
+     git annex enableremote myremote keyid+=XXXXXXXX
+
+I get this error:
+
+     enableremote myremote (encryption update) (hybrid cipher with gpg keys XXXXXXXX XXXXXXX) fatal: remote myremote already exists. 
+     git-annex: git [Params \"remote add\",Param \"myremote\",Param \"gcrypt::XXXXXXXXXXX:gcrypt-tests\"] failed
+
+this is my git-annex version info: 
+
+     git-annex version: 5.20141125 
+     build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash 
+     key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL 
+     remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external 
+     local repository version: 5 
+     supported repository version: 5 
+     upgrade supported from repository versions: 0 1 2 4
+
+am I doing something wrong? thank you Giovanni
+
+"""]]
diff --git a/doc/encryption/comment_2_5c2da865082de475254ebfd53feb2d0a._comment b/doc/encryption/comment_2_5c2da865082de475254ebfd53feb2d0a._comment
new file mode 100644
index 0000000000..c8a571813b
--- /dev/null
+++ b/doc/encryption/comment_2_5c2da865082de475254ebfd53feb2d0a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-06T19:57:12Z"
+ content="""
+@Giovanni, git is complaining that there is already a remote named
+"myremote" enabled in the current repository. Perhaps you have reused this
+name for a different remote.
+
+(This seems to have nothing to do with the page the comment was posted to, which 
+is a bit annoying. Please post questions in the forum and not attached to
+random other pages.)
+"""]]
diff --git a/doc/encryption/comment_3_46e64e4856975706e06e2a012a5d8f67._comment b/doc/encryption/comment_3_46e64e4856975706e06e2a012a5d8f67._comment
new file mode 100644
index 0000000000..eba9a883cd
--- /dev/null
+++ b/doc/encryption/comment_3_46e64e4856975706e06e2a012a5d8f67._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="whlabratz@d10941ab2681deb87122fd8f6da51f3dcdb8dbe5"
+ nickname="whlabratz"
+ subject="Listing GPG keys enabled for a remote with hybrid encryption"
+ date="2015-09-15T22:37:35Z"
+ content="""
+Is there a straight-forward way to list which GPG keys are enabled for a particular remote?
+"""]]
diff --git a/doc/encryption/comment_4_fe8b181adef9a39a039ff96a0d587188._comment b/doc/encryption/comment_4_fe8b181adef9a39a039ff96a0d587188._comment
new file mode 100644
index 0000000000..4b8014f00d
--- /dev/null
+++ b/doc/encryption/comment_4_fe8b181adef9a39a039ff96a0d587188._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""listing gpg keys"""
+ date="2015-09-17T17:01:38Z"
+ content="""
+Run "git annex info specialremote" and it will describe the encryption
+settings of the remote, including gpg keys where applicable.
+
+Needs a fairly recent git-annex. `git show git-annex:remote.log` can
+also be used.
+"""]]
diff --git a/doc/encryption/comment_5_5c9897663aaa83ca39a7e8cb292a3fd1._comment b/doc/encryption/comment_5_5c9897663aaa83ca39a7e8cb292a3fd1._comment
new file mode 100644
index 0000000000..ee4c2f3287
--- /dev/null
+++ b/doc/encryption/comment_5_5c9897663aaa83ca39a7e8cb292a3fd1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="gavinwahl@d3a94ffbd6df3b8833a53ff11ec435f58f7c44a9"
+ nickname="gavinwahl"
+ subject="Shared key - how many keys?"
+ date="2016-04-03T03:43:58Z"
+ content="""
+In shared mode, is a single key used to encrypt every file in the repository? Or is a new key created for each file?
+
+Shared mode has the properties I need - getting access to the git repo should give you access to all the content. BUT, if one loses access to updates to the git repo, they should not have access to files added after they lost access.
+"""]]
diff --git a/doc/encryption/comment_6_1756ce62906586f876a3491e5d9befde._comment b/doc/encryption/comment_6_1756ce62906586f876a3491e5d9befde._comment
new file mode 100644
index 0000000000..81802c6254
--- /dev/null
+++ b/doc/encryption/comment_6_1756ce62906586f876a3491e5d9befde._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2016-04-04T18:48:34Z"
+ content="""
+@gavinwahl, it's a single shared key that any clone of the repository
+provides access to.
+
+If you use the [[tahoe]] special remote, storing files in tahoe-lafs does result
+in a new capability (a kind of key) being stored in the git repo.
+So someone with an old clone can't access the files from tahoe-lafs.
+Tahoe is unique in providing that ability.
+"""]]
diff --git a/doc/encryption/comment_8_3849eb24c3682644e263bae107747dee._comment b/doc/encryption/comment_8_3849eb24c3682644e263bae107747dee._comment
new file mode 100644
index 0000000000..393d18ecc5
--- /dev/null
+++ b/doc/encryption/comment_8_3849eb24c3682644e263bae107747dee._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joern.mankiewicz@06fb5bc9b732f143dee3606866362f562531310d"
+ nickname="joern.mankiewicz"
+ avatar="http://cdn.libravatar.org/avatar/446365f4d50dddc42965fa0432e70cdb"
+ subject="Workflow for adding a keyid in hybrid-enc lateron and re-encrypting? "
+ date="2017-03-21T22:08:30Z"
+ content="""
+Hi folks!
+
+We are considering introducing git-annex with gcrypt in hybrid mode as secure storage for common data in our company and I'd rather not delete and reinit the repo everytime when somebody new is granted access.
+A little testing with current git-annex showed, that GCRYPT_FULL_REPACK with a forced git-push of all branches makes the git-repo accessible (I get the files) to the newcomer but not the annexed data (gpg error \"No secret key\" in git annex get, git annex info secretRepo just lists my first key).
+
+Has anybody sucessfully tested adding keyids in hybrid-encryption later on? Which further steps where needed to make it work? 
+
+Thanks for any input! :)
+
+Cheers 
+
+Jörn
+"""]]
diff --git a/doc/encryption/comment_8_66e81e89fd483ca95620522b0f63c4fd._comment b/doc/encryption/comment_8_66e81e89fd483ca95620522b0f63c4fd._comment
new file mode 100644
index 0000000000..bca3286d07
--- /dev/null
+++ b/doc/encryption/comment_8_66e81e89fd483ca95620522b0f63c4fd._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2017-04-07T16:52:59Z"
+ content="""
+@joern.mankiewicz, I see you found a bug and filed it, so will answer in
+the but report.
+
+Barring bugs, adding another gpg key to a hybrid encryption special remote
+is as simple as `git annex enableremote $theremote keyid+=$newkey`
+"""]]
diff --git a/doc/encryption/comment_9_5ca10891d642392aaff342c1478b0550._comment b/doc/encryption/comment_9_5ca10891d642392aaff342c1478b0550._comment
new file mode 100644
index 0000000000..723e3df2d4
--- /dev/null
+++ b/doc/encryption/comment_9_5ca10891d642392aaff342c1478b0550._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Yurt"
+ avatar="http://cdn.libravatar.org/avatar/28d2177f7678c6cc0b677c34927eba06"
+ subject="Encrypt to different subkeys?"
+ date="2017-05-16T20:25:01Z"
+ content="""
+Is it possible to encrypt with subkeys. I have a few subkeys distributed to different computers and I'd like to be able to sync to a special remote with all of them. Right now, if the master key is stripped, I get an error from gpg.
+
+I do this exact thing with password-store. Appending \"!\" to the subkey id should force gpg to use that specific key: [https://lists.zx2c4.com/pipermail/password-store/2014-September/001131.html](https://lists.zx2c4.com/pipermail/password-store/2014-September/001131.html).
+"""]]
diff --git a/doc/favicon.ico b/doc/favicon.ico
new file mode 100644
index 0000000000000000000000000000000000000000..e754f5a48b1782620b743e3e9096f3cd40333edb
GIT binary patch
literal 2550
zcmeH{Pj3=Y6vYov6>UXE)Y_^QwIKEH!^+B-xG-IsRKo}821p1bEJ!hF8pFzjm8rF@
zDM1Y>(l(}c0}D1Ju%XD>9qAWn8j@Oq2;Mit0A-M*Cc5fL=HC0x@4k6&?qUEH)X?ko
zl>1;&0cHS3BWSI~XD#rIJPUbx?$g8jxL%1-3Y>9mZRJs~*OAZXvADQ|FB^4Ot>c)V
ze@EUojEvSXvGEwu?;phe&L9YahEWg%gWYcB*)%0Q=h-F*FQhyvu1!-CH%$8N+?Vx~
z#Ov22*%R~78)@0dOC)Zr#^0}sK=eEBbJ#VXlaZb$^ziwKlEx*~G)u0zxjB?dB}{yM
z1eeQ&<>h7gd_GK1zeFODz}{X7)!I+QVlm9j%wS<*fo8iU&ereuBOZ@qc6JukY7Lv4
zo5*A`D3{Cddc7F46|uIqhGMY@r_+f_rGjWQitX)f1cO0@LLr31VXUmIAel@eolYZ{
z%fan-qgJaS5{cl`$G6zo*@4I7LHSo1G)$yYDeUg<BAd;^;c%c(C?F6BV1NGy*4NkR
zzE$btj^fb-jwaA^0=hO?!MLsswRx@5JRnjYPPN=tb*G6LL(7({ha6wk8;t$DxGvjr
zR*~6%MO=*zGiJIZgGRo=m}aa|pQGLmtfSWtG`(X=ewncoO)e<;Mfz^eIXQ1qays)C
zKcADkj9qBHt5MveJDoW#a;t{1`<+~OlNx9*kBs#xux|V~W5Y5Zd7y02S{O4o_ABqF
z?C<TI?Zkrz)roZn@!+AkVnbI$tyXvSW%J*0dULzv1Dm-WQr-0BqBp<YXzR9<&`Dcw
SE+3-%!~VbLJ%0}W0saQKoa2-L

literal 0
HcmV?d00001

diff --git a/doc/footer/column_a.mdwn b/doc/footer/column_a.mdwn
new file mode 100644
index 0000000000..92c77d8406
--- /dev/null
+++ b/doc/footer/column_a.mdwn
@@ -0,0 +1,7 @@
+### Recent [[news]]
+
+[[!inline pages="news/* and !*/Discussion" archive=yes show=2 feeds=no]]
+
+### [[devblog|devblog]]
+
+[[!inline pages="devblog/* and !*/Discussion" archive=yes show=5 feeds=no]]
diff --git a/doc/footer/column_b.mdwn b/doc/footer/column_b.mdwn
new file mode 100644
index 0000000000..4d2d3dd983
--- /dev/null
+++ b/doc/footer/column_b.mdwn
@@ -0,0 +1,7 @@
+### Recent [[videos]]
+
+[[!inline pages="videos/* and !*/Discussion" archive=yes show=2 feeds=no]]
+
+### Recent [[forum posts|forum]]
+
+[[!inline pages="forum/* and !*/Discussion" archive=yes show=5 feeds=no]]
diff --git a/doc/forum.mdwn b/doc/forum.mdwn
new file mode 100644
index 0000000000..48e1b9538e
--- /dev/null
+++ b/doc/forum.mdwn
@@ -0,0 +1,9 @@
+This is a place to discuss using git-annex.
+If you need help, advice, or anything, post about it here.
+
+But, please don't post bug reports here. Put them in [[bugs]].  
+And please don't make wishlist requests here. Put them in [[todo]].  
+(If you post bugs/todo here, it'll just get moved.)
+
+[[!inline pages="forum/* and !tagged(forum/forumbug) and !forum/bugreport and !*/Discussion" archive=yes feedlimit=10 
+rootpage=forum postformtext="Add a new thread titled:"]]
diff --git a/doc/forum/--verbose_not_really_verbose__63__.mdwn b/doc/forum/--verbose_not_really_verbose__63__.mdwn
new file mode 100644
index 0000000000..3ed5741fba
--- /dev/null
+++ b/doc/forum/--verbose_not_really_verbose__63__.mdwn
@@ -0,0 +1,7 @@
+I am trying to set up android's "/sdcard" (which is not really an sd card) synchronization as described in https://git-annex.branchable.com/tips/android_sync_with_adb/
+
+The problem is that my "sdcard" is quite sizeable, 128Gb, and I don't seem to manage to get all the contents adb-pulled overnight, and I can't leave the phone copying for more than ~10 hours.
+
+When I am trying to resume the synchronization with `git annex  import --verbose master --from android_cable` , it does immediately produces a `git` process with a 99% I/O consumption, but displays no information, so I don't know what is it that it's actually doing.
+
+Is it possible to increase the verbosity of --verbose?
diff --git a/doc/forum/--verbose_not_really_verbose__63__/comment_1_9a7927c22a50addafc58028f34c48578._comment b/doc/forum/--verbose_not_really_verbose__63__/comment_1_9a7927c22a50addafc58028f34c48578._comment
new file mode 100644
index 0000000000..b811767d9e
--- /dev/null
+++ b/doc/forum/--verbose_not_really_verbose__63__/comment_1_9a7927c22a50addafc58028f34c48578._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2020-06-15T04:38:04Z"
+ content="""
+try `--verbose --debug` .
+"""]]
diff --git a/doc/forum/--verbose_not_really_verbose__63__/comment_2_0c846317803019058f6b522bc9abd5a6._comment b/doc/forum/--verbose_not_really_verbose__63__/comment_2_0c846317803019058f6b522bc9abd5a6._comment
new file mode 100644
index 0000000000..7f08ceefa1
--- /dev/null
+++ b/doc/forum/--verbose_not_really_verbose__63__/comment_2_0c846317803019058f6b522bc9abd5a6._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="https://dead-doomer.livejournal.com/"
+ subject="comment 2"
+ date="2020-06-15T05:23:31Z"
+ content="""
+--debug does add a bit of information, but still not much. 
+
+```
+lockywolf@delllaptop:~/Android_OnePlus_5t_sdcard_root$ time git annex --verbose --debug import --verbose --debug master --from android_cable
+[2020-06-15 12:55:38.412251405] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2020-06-15 12:55:38.440426228] process done ExitSuccess
+[2020-06-15 12:55:38.440584943] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2020-06-15 12:55:38.449779319] process done ExitSuccess
+[2020-06-15 12:55:38.450385777] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..5a8e10ac8b853f8ee810f2569267fdabd41dfc79\",\"--pretty=%H\",\"-n1\"]
+[2020-06-15 12:55:38.627505978] process done ExitSuccess
+[2020-06-15 12:55:38.706288754] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2020-06-15 12:55:38.707306945] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+
+
+```
+
+stays in this state \"forever\". 
+
+Is it possible to find out how much of the \"update-index\" has passed?
+
+git-annex seems to be the only bi-directional synchronization tool in the field. I mean, there is also `adb-sync`, but it, as all other tools, doesn't handle deletions properly. 
+
+"""]]
diff --git a/doc/forum/--verbose_not_really_verbose__63__/comment_3_a360190fee9a9514f0ba201baeaecd7a._comment b/doc/forum/--verbose_not_really_verbose__63__/comment_3_a360190fee9a9514f0ba201baeaecd7a._comment
new file mode 100644
index 0000000000..b6017b75f9
--- /dev/null
+++ b/doc/forum/--verbose_not_really_verbose__63__/comment_3_a360190fee9a9514f0ba201baeaecd7a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-06-16T16:12:57Z"
+ content="""
+What git-annex is working on doing here is adding all the data it had
+started recording when you interrupted it before to the git-annex branch.
+
+If it had imported a large number of files, that could take a while.
+The number of files in .git/annex/journal/ is a good indication of how much
+work it needs to do (but all the files will remain there until it's finished).
+
+Normally with a fairly large number of files like a thousand or so, this
+step takes less than 1 second..
+
+--verbose is the default verbosity level BTW.
+"""]]
diff --git a/doc/forum/--verbose_not_really_verbose__63__/comment_4_e4d75464af5ced1ce1f9539ddf8755f4._comment b/doc/forum/--verbose_not_really_verbose__63__/comment_4_e4d75464af5ced1ce1f9539ddf8755f4._comment
new file mode 100644
index 0000000000..c02916c377
--- /dev/null
+++ b/doc/forum/--verbose_not_really_verbose__63__/comment_4_e4d75464af5ced1ce1f9539ddf8755f4._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://dead-doomer.livejournal.com/"
+ subject="comment 4"
+ date="2020-06-17T02:41:51Z"
+ content="""
+>Normally with a fairly large number of files like a thousand or so, this step takes less than 1 second..
+
+Well, I wouldn't need any specialised synchronisation tool if I had 1000 files.
+
+My \"sdcard\", which is not really an SD card (Android lying as always), has ~400 000 files, out of which a huge load are garbage files created by poorly written apps which you cannot avoid, like a bank-client, which are unmanageable from a phone itself. 
+
+I hoped to pull them to the laptop, do the heavy lifting of sorting that out on the laptop, using fdupes, rdfind, find/grep, and such, delete the rubbish, and push it back. 
+
+It's not an \"exotic\" setup at all, I don't even have my phone rooted. In fact for about a year or two a phone with 128Gb of storage is fairly affordable. And it's not really possible to stop apps from being garbage.
+"""]]
diff --git a/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__.mdwn b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__.mdwn
new file mode 100644
index 0000000000..84f92ae7ea
--- /dev/null
+++ b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__.mdwn
@@ -0,0 +1,3 @@
+I have 2 clients (laptops) that  would (usually) not be online at the same time. Is it possible to use git-annex for syncing these 2 clients through an encrypted server?
+
+I have tried to set this up with the assistant by using an USB-disk for copying the repository from one client to the other. The server is configured through the assistant as repository group 'transfer'. Now both clients see the encrypted ssh-server, each client copy stuff to the encrypted server, but no files are copied between the 2 clients. (In my case, running git-annex on the server is not an option. I have read through this forum, but it doesn't seem anyone has been able to get it to work.)
diff --git a/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_1_924521ad5972046bac44d2e04ec296c7._comment b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_1_924521ad5972046bac44d2e04ec296c7._comment
new file mode 100644
index 0000000000..90b47a3a9a
--- /dev/null
+++ b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_1_924521ad5972046bac44d2e04ec296c7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnvVfFLW4CTKs7UjdiLIsOn_cxj1Jnh64I"
+ nickname="Charl"
+ subject="Change the encrypted server repository group to &quot;full backup&quot;"
+ date="2014-03-23T21:00:01Z"
+ content="""
+Have you tried changing the repository group of the encrypted server to \"full backup\" instead of \"transfer\"?
+
+I've just started experimenting with git-annex, and this setup (two possibly remote laptops, one encrypted server) seems to be working after very limited testing. I'm currently importing a larger collection of about 40000 files, will see if it still does (it seems whilst one client is transferring to the remote server, the other client laptop is not beeing synced; it did sync after my first batch of copying however.)
+"""]]
diff --git a/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_2_e2a7f34a3ccc1b6467e6da611c067d66._comment b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_2_e2a7f34a3ccc1b6467e6da611c067d66._comment
new file mode 100644
index 0000000000..b50ba4b469
--- /dev/null
+++ b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_2_e2a7f34a3ccc1b6467e6da611c067d66._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkvN0eFnwvgw2JyTSSHw0QouytcxtPLln8"
+ nickname="Stein Roald"
+ subject="No success"
+ date="2014-03-26T19:43:24Z"
+ content="""
+Thank you, Charl, for your suggestion. I've tried it, without success. (It doesn't seem like that change changed anything on the encrypted ssh-server.)
+"""]]
diff --git a/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_3_f9a369a6ac69f091e6128990274d3228._comment b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_3_f9a369a6ac69f091e6128990274d3228._comment
new file mode 100644
index 0000000000..1e42061447
--- /dev/null
+++ b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_3_f9a369a6ac69f091e6128990274d3228._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.41"
+ subject="comment 3"
+ date="2014-03-26T21:10:39Z"
+ content="""
+What kind of encrypted remote are you using? An encrypted rsync special remote does not include the git repository, but only the content of the files, so cannot be used in this way.
+
+If you set up a [[gcrypt special remote|special_remotes/gcrypt]], it will be encrypted and includes the full git repository, as well as the content of the files, so can be used like this.
+"""]]
diff --git a/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_4_91b422f8d55b68077245c606c4f7f87c._comment b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_4_91b422f8d55b68077245c606c4f7f87c._comment
new file mode 100644
index 0000000000..4d8915b8df
--- /dev/null
+++ b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_4_91b422f8d55b68077245c606c4f7f87c._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkvN0eFnwvgw2JyTSSHw0QouytcxtPLln8"
+ nickname="Stein Roald"
+ subject="Need some clarification"
+ date="2014-03-28T22:49:14Z"
+ content="""
+OK, thank you Joey for your help, and I think you have made some really excellent software. I've spent a couple of days to configure gpg and understand how to use it (glad I did, it has been on my todo-list for a long time...)
+
+First to your question: When I started, I just used the git-annex assistant to \"set up a repository on a remote server using ssh\" as a \"transfer repository\". Now I'll use git-remote-gcrypt instead.
+
+Now I have 2 questions:
+
+---
+
+1) On this webpage: [[https://github.com/joeyh/git-remote-gcrypt]] these are the instructions for setting up a remote for two participants:
+
+    git remote add cryptremote gcrypt::rsync://example.com:repo
+    git config remote.cryptremote.gcrypt-participants \"KEY1 KEY2\"
+    git push cryptremote master
+
+**Question 1:** As I own both computers myself, will syncing between the 2 computers work if I only use 1 KEY (the same KEY on both computers)?
+
+---
+
+2) I am still struggling to understand git-annex assistant and the use of special remotes. Important reasons for using git-annex are backups and moving data to the cloud to free up disk space locally. If I've understood it correctly, git-annex assistant always encrypts data sent to special remotes. And it seems to me that this page [[http://git-annex.branchable.com/special_remotes/]] suggest that git-annex assistant makes it easy to transfer files between different computers that do not communicate directly. I must clearly have misunderstood something, as Joey's comment above seem to state that I can't use the assistant for setting up syncing between computers.
+
+**Question 2:** If I loose my computer, or it becomes corrupted, how can I get my files back if I don't set up special remotes as a gcrypt special remote? (And if I can't, what is the purpose of the special remotes made by the assistant?)
+"""]]
diff --git a/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_5_f6128fe75ff3453747f69f12e0fd0a5b._comment b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_5_f6128fe75ff3453747f69f12e0fd0a5b._comment
new file mode 100644
index 0000000000..8dcddbeef5
--- /dev/null
+++ b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_5_f6128fe75ff3453747f69f12e0fd0a5b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="Confused"
+ date="2014-03-31T03:18:41Z"
+ content="""
+>What kind of encrypted remote are you using? An encrypted rsync special remote does not include the git repository, but only the content of the files, so cannot be used in this way.
+
+Forgive me, Joey, I've been following your work on the assistant for almost as long as you've been working on it, and I use git a little bit, but I have yet to wrap my head around the complexities of git and how git-annex and the assistant...morph them.  I've read all the design docs you've written, but I still don't understand this.  From reading the OP it sounds like this is exactly what the encrypted rsync special remote is for: using a transfer repo to sync two devices that don't connect directly to each other.  Why would he need to use a gcrypt repo instead?
+
+Thanks for your patience.  I know you get asked these basic questions over and over again.
+"""]]
diff --git a/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_6_9b90b4031a5ed26c375903b33ed65a10._comment b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_6_9b90b4031a5ed26c375903b33ed65a10._comment
new file mode 100644
index 0000000000..5fc4286b27
--- /dev/null
+++ b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_6_9b90b4031a5ed26c375903b33ed65a10._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 6"
+ date="2014-04-02T20:11:35Z"
+ content="""
+@Adam, an encrypted special remote does not contain the git repository (the gcrypt special remote is an exception to this rule). So you need to use another method to sync the git repository between machines.
+
+@Stein Roald once you have a clone of the git repository, you have the information that git-annex needs in able to get files from encrypted special remotes.
+
+Question 1: While gcrypt supports multi-key setups, when you use the git-annex assistant to set up a gcrypt remote it only sets it up to use one key. It's left to you to arrange for this key to be on every computer that needs it. Or use command-line stuff to add additional keys later.
+
+Question 2: You can certianly use the assistant to set up syncing between computers, but the only setup that currently provides 100% end-to-end enctyption of the git repository is using gcrypt. (Special remotes are 100% end-to-end encrypted, but as I've stated several times, do not contain the git repository data.)
+Since you seemed to want 100% end to end encryption I suggested using gcrypt. There are simpler setups, like using XMPP, that encrypt everything but not end-to-end, so the XMPP server could snoop on it.
+
+If you loose your computer, you can get your files back from any other device where you've set up a clone of that repository. A backup drive, another computer , etc. 
+"""]]
diff --git a/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_7_acd64ce1b08a97ddf730622272e9f611._comment b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_7_acd64ce1b08a97ddf730622272e9f611._comment
new file mode 100644
index 0000000000..f850253b18
--- /dev/null
+++ b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_7_acd64ce1b08a97ddf730622272e9f611._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkvN0eFnwvgw2JyTSSHw0QouytcxtPLln8"
+ nickname="Stein Roald"
+ subject="comment 7"
+ date="2014-04-03T21:55:14Z"
+ content="""
+Thanks again, Joey, for your time and for your kind answers.
+
+I have tried to set up git-annex with 2 laptops, each with their own gpg-key in order to use a remote server with gcrypt (and those laptops have shared the keys with each other). I regularly use git, but so far I haven't been able to get this setup to work. But before I bother the world with these problems, I would be interested in learning how to do the following:
+
+*Question 3*: How can I use the git-annex assistant to set up a gcrypt remote (with one key)? It doesn't show up as an option as far as I can see (git-annex version: 4.20130815).
+
+*Promise*: When I get git-annex to work with gcrypt, I'll make a summary on how I did it (and maybe which mistakes I made so others can avoid them).
+"""]]
diff --git a/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_8_9baacb14fc5eb449cb13e0b4a4995fb0._comment b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_8_9baacb14fc5eb449cb13e0b4a4995fb0._comment
new file mode 100644
index 0000000000..0ecc2fb3ba
--- /dev/null
+++ b/doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_8_9baacb14fc5eb449cb13e0b4a4995fb0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="216.145.95.162"
+ subject="comment 8"
+ date="2014-05-19T16:48:09Z"
+ content="""
+4.20130815 is too old. Get a current version.
+"""]]
diff --git a/doc/forum/4hr+_sync_on_new_remote___40__USB_drive__41__.mdwn b/doc/forum/4hr+_sync_on_new_remote___40__USB_drive__41__.mdwn
new file mode 100644
index 0000000000..167c090f18
--- /dev/null
+++ b/doc/forum/4hr+_sync_on_new_remote___40__USB_drive__41__.mdwn
@@ -0,0 +1,92 @@
+I need some help understanding what would cause ``git-annex sync`` to still be running 4hrs+ on a new remote (FAT32 USB drive - BTEST) ? From all my searching, it appears to be part of git's optimization routines. But to be this long and slow seems odd. Also I am not sure what there would be optimize since it's a brand new remote ? The src (WTEST) doesn't seem to show any need to run ``git gc``.
+
+I followed the walkthrough's setup of a remote and followed that up with ``git-annex sync``. I did not specify the source for the sync as there is only one other (WTEST). The content is mostly ISO files and Win32 executables in 7 separate commits. In between ``git-annex import`` and ``git commit``, the working directory was removed with ``git rm '*'`` but no ``git-annex drop``. There were lots of duplicate files and it truly was satisfying to not see the disk usage increase. My backend is also MD5E for purposes of quicker imports and ease of hash lookup from other sources.
+
+I would like to have 20-30 USB remotes. The length of time to get one remote up and running at this point is horrendous. Other people seem to have better experiences with it. Only odd thing that I see with my configuration is that the remote FAT32 drive is in ``indirect`` mode. My understanding is that ``git-annex`` would automatically switch to ``direct`` if it detected a filesystem that did not support symbolic links. 
+
+What is wrong with my setup ? How can I fix it ?
+
+Here's the basic config of WTEST.
+
+[[!format sh """
+
+WTEST$ git-annex info
+
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 4
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        98dfasdf-ab83-4a0e-8b73-4dfasffdsaff1ae -- WTEST [here]
+        9dfdsfdf8-c5d5-4761-ab67-ffsadfsadfsa83 -- BTEST
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 488.16 gigabytes (+1 megabyte reserved)
+local annex keys: 57327
+local annex size: 58.57 gigabytes
+annexed files in working tree: 4322
+size of annexed files in working tree: 6.82 gigabytes
+bloom filter size: 16 mebibytes (11.5% full)
+backend usage:
+        MD5E: 61649
+"""]]
+
+[[!format sh """
+WTEST$git object-count -v
+
+count: 521829
+size: 66794240
+in-pack: 0
+packs: 0
+size-pack: 0
+prune-packable: 0
+garbage: 0
+size-garbage: 0
+"""]]
+
+
+[[!format sh """
+WTEST$git config -l
+
+core.repositoryformatversion=0
+core.filemode=false
+core.bare=false
+core.logallrefupdates=true
+core.ignorecase=true
+core.precomposeunicode=true
+annex.uuid=98dfasdf-ab83-4a0e-8b73-4dfasffdsaff1ae
+annex.sshcaching=false
+annex.version=5
+annex.backends=MD5E
+annex.queuesize=102400
+annex.genmetadata=true
+remote.BTEST.url=/Volumes/BTEST
+remote.BTEST.fetch=+refs/heads/*:refs/remotes/BTEST/*
+remote.BTEST.annex-uuid=9dfdsfdf8-c5d5-4761-ab67-ffsadfsadfsa83
+"""]]
+
+**The long running sync.**
+
+[[!format sh """ 
+BTEST$ git-annex sync
+
+commit  ok
+
+pull origin
+
+Auto packing the repository for optimum performance. You may also
+
+run "git gc" manually. See "git help gc" for more information.
+
+Counting objects: 521834, done.
+
+Delta compression using up to 4 threads.
+
+Compressing objects:  12% (59687/462488)
+"""]]
+
+**Update 7hrs later:**
+
+[[!format sh """
+Writing objects:  70% (366184/521834)
+"""]]
diff --git a/doc/forum/4hr+_sync_on_new_remote___40__USB_drive__41__/comment_1_01a6020d25826a3e0afb087899f6919c._comment b/doc/forum/4hr+_sync_on_new_remote___40__USB_drive__41__/comment_1_01a6020d25826a3e0afb087899f6919c._comment
new file mode 100644
index 0000000000..d7209a89b8
--- /dev/null
+++ b/doc/forum/4hr+_sync_on_new_remote___40__USB_drive__41__/comment_1_01a6020d25826a3e0afb087899f6919c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-16T17:38:02Z"
+ content="""
+git gc is using the time here.
+
+It's easy to configure git to not do auto-gc. See the git-config man
+page's documentation of gc.auto.
+
+(It's impossible to use git-annex in indirect mode on a fat filesystem,
+unless FAT has suddenly grown symlink support overnight and I didn't
+notice..)
+"""]]
diff --git a/doc/forum/ARM_build_on_Zyxel_NAS.mdwn b/doc/forum/ARM_build_on_Zyxel_NAS.mdwn
new file mode 100644
index 0000000000..4fe46bedbc
--- /dev/null
+++ b/doc/forum/ARM_build_on_Zyxel_NAS.mdwn
@@ -0,0 +1,15 @@
+I am trying to run the linux standalone ARM build on my Zyxel NAS, but I get the following error
+
+`FATAL: kernel too old`
+
+The system runs the following:
+
+`
+uname -a
+`
+
+`
+Linux nas 2.6.31.8 #2 Thu Dec 19 14:31:05 CST 2013 armv5tel GNU/Linux
+`
+
+Help would be much appreciated.  
diff --git a/doc/forum/ARM_build_on_Zyxel_NAS/comment_1_38f38755c0afd76a2b968836fec395e8._comment b/doc/forum/ARM_build_on_Zyxel_NAS/comment_1_38f38755c0afd76a2b968836fec395e8._comment
new file mode 100644
index 0000000000..02d2716ac7
--- /dev/null
+++ b/doc/forum/ARM_build_on_Zyxel_NAS/comment_1_38f38755c0afd76a2b968836fec395e8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Joey"
+ subject="""comment 1"""
+ date="2014-10-20T15:11:49Z"
+ content="""
+The git-annex arm build is built using the libc from Debian stable,
+which needs a newer version of the Linux kerenl than is on your device.
+
+It would be possible to build git-annex against an older libc, but
+not easily, which is why I don't.
+"""]]
diff --git a/doc/forum/ARM_build_on_Zyxel_NAS/comment_2_44c8f1af0cbe9ad51794e6d8d16be627._comment b/doc/forum/ARM_build_on_Zyxel_NAS/comment_2_44c8f1af0cbe9ad51794e6d8d16be627._comment
new file mode 100644
index 0000000000..9cec2bf69b
--- /dev/null
+++ b/doc/forum/ARM_build_on_Zyxel_NAS/comment_2_44c8f1af0cbe9ad51794e6d8d16be627._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="musella"
+ ip="84.73.42.152"
+ subject="comment 2"
+ date="2014-10-21T23:35:35Z"
+ content="""
+what is the minimal kernel version that I would need?
+
+"""]]
diff --git a/doc/forum/ARM_build_on_Zyxel_NAS/comment_3_b4f6e5ac672e8ece36cceb74ff3315dd._comment b/doc/forum/ARM_build_on_Zyxel_NAS/comment_3_b4f6e5ac672e8ece36cceb74ff3315dd._comment
new file mode 100644
index 0000000000..2ff40efe65
--- /dev/null
+++ b/doc/forum/ARM_build_on_Zyxel_NAS/comment_3_b4f6e5ac672e8ece36cceb74ff3315dd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.96"
+ subject="comment 3"
+ date="2014-10-22T16:22:24Z"
+ content="""
+I know kernel 3.2 would work. I don't know what the minimum kernel supported by glibc 2.13 is.
+"""]]
diff --git a/doc/forum/A_git-annex_helper.mdwn b/doc/forum/A_git-annex_helper.mdwn
new file mode 100644
index 0000000000..23a568eeb2
--- /dev/null
+++ b/doc/forum/A_git-annex_helper.mdwn
@@ -0,0 +1,6 @@
+Hi,
+I have developed a [sort-of-a-GUI](http://github.com/atrent/AdMinchiam/tree/master/ga-gui) for git-annex and I'd like you to test it if you have time, see README and [screenshots](http://github.com/atrent/AdMinchiam/blob/master/ga-gui/Screenshots/GitAnnexGUI_020.png), the idea is very simple: visually tag items then generate a script based on editable templates.
+
+The only problem at the moment is the very slow git-annex data acquisition; not my fault, on very large annexes, in terms of number of files, the 'git-annex list' and 'git-annex metadata' commands take AGES...
+
+Thank you
diff --git a/doc/forum/A_little_help_with_headless_server_configuration.mdwn b/doc/forum/A_little_help_with_headless_server_configuration.mdwn
new file mode 100644
index 0000000000..3dc52be306
--- /dev/null
+++ b/doc/forum/A_little_help_with_headless_server_configuration.mdwn
@@ -0,0 +1,2 @@
+Attempting to setup a multiple server file share. I am really not sure how to configure and setup the headless system for sharing? Seems easy enough with the webapp and have my windows system appear to be working not sure how to get my Linux headless systems to sync up as well any help would be greatly appreciated.
+
diff --git a/doc/forum/A_little_help_with_headless_server_configuration/comment_1_d32e28e8dcacf89eb357b78aefded274._comment b/doc/forum/A_little_help_with_headless_server_configuration/comment_1_d32e28e8dcacf89eb357b78aefded274._comment
new file mode 100644
index 0000000000..9413b10cb8
--- /dev/null
+++ b/doc/forum/A_little_help_with_headless_server_configuration/comment_1_d32e28e8dcacf89eb357b78aefded274._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-11-18T18:03:30Z"
+ content="""
+It's not really clear from that what you want this server 
+(or servers?) to do.
+
+I think if you explain some more we can help better.
+
+I guess you have a repository on Windows using the webapp and you want
+that repository to be synced to one or more servers. The webapp has a
+dialog to Add a Repository on a Remote server. You'll need to install
+git-annex on the server, and tell the webapp the password to use to ssh to
+it, and otherwise that's pretty simple.
+
+That will get you a git repository on the server that will store all the files
+from your Windows repository. Since it's a bare git repository by default,
+all you can do with it is clone it to somewhere else, which can then get
+files from it. That could be another server or another webapp client or
+whatever, depending on what you're trying to accomplish.
+"""]]
diff --git a/doc/forum/A_question_an_the_nomad_use_cases__58___files_to_fetch__44___files_to_delete__44___files_to_keep__63__.mdwn b/doc/forum/A_question_an_the_nomad_use_cases__58___files_to_fetch__44___files_to_delete__44___files_to_keep__63__.mdwn
new file mode 100644
index 0000000000..c6c67a2917
--- /dev/null
+++ b/doc/forum/A_question_an_the_nomad_use_cases__58___files_to_fetch__44___files_to_delete__44___files_to_keep__63__.mdwn
@@ -0,0 +1,12 @@
+Hello,
+
+I went through several of the questions on the forum but could not find the answer to this. I have the following scenario, which seems very similar to the nomad case.
+
+I have a server at home with many big media files. I want to keep a subset of these files on my laptop, to watch when I travel. When I'm done watching the files, I want to either delete them (i.e, they should no longer be on any machine) or archive them (i.e., they should remain on the server, but no longer be on the laptop). I think I know how to do this from the command line, but I still have a few questions.
+
+- How do I drop a file from _every_ repository? If I understood correctly, `git annex drop foo` will only drop foo locally.
+- Is it possible to follow this use case using the assistant, or should I use the command line instead (which would be very fine with me)? In particular, how do I choose the file I want to put on the laptop? (It seems `git annex get` is the command line way, is there an assistant equivalent?)
+- Can I use both the assistant and the command line at the same time? Is there a description of the command-line version of what the assistant is doing behind the scenes?
+- Can the server repository be both a "transfer" repository (to hold the files I haven't watch) and an "archive" repository (to keep the files I've watched and decided to keep), or do I need two repositories (on the server) for that?
+
+Thanks a lot for any suggestion.
diff --git a/doc/forum/A_question_an_the_nomad_use_cases__58___files_to_fetch__44___files_to_delete__44___files_to_keep__63__/comment_1_fe291cd6cd8e2d5b8e23f8e3689d824b._comment b/doc/forum/A_question_an_the_nomad_use_cases__58___files_to_fetch__44___files_to_delete__44___files_to_keep__63__/comment_1_fe291cd6cd8e2d5b8e23f8e3689d824b._comment
new file mode 100644
index 0000000000..e29f576577
--- /dev/null
+++ b/doc/forum/A_question_an_the_nomad_use_cases__58___files_to_fetch__44___files_to_delete__44___files_to_keep__63__/comment_1_fe291cd6cd8e2d5b8e23f8e3689d824b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 1"
+ date="2013-10-21T22:41:44Z"
+ content="""
+You can use `git annex drop foo --from remote` to drop the file from the remote. Of course, the remote has to be accessible. You can't drop files from an offline drive that's stored in a safe.. 
+
+What you might be looking for is `git annex drop foo; rm foo`, followed by a git commit, and then later you can run `git annex unused` on a remote and it will let you then easily drop the files you've removed from the repository. This approach of just deleting files when you're done with them also works when using the assistant.
+
+The assistant isn't really about only keeping a subset of files on your laptop. It would like to get them all, except for ones in \"archive\" directories.
+You can configure the assistant to use manual mode, and then it doesn't download any files on its own (so you have to manually `git annex get` them), but it will still handle all the other stuff the assistant does, like automatically committing and syncing changes.
+
+An archive repository wants one copy of every file that is not already stored in some other archive repository. So an archive repository could certainly be used instead of a transfer repository. (But not a small archive repository; those only want files that are moved to \"archive\" directories.) A better choice might be to make that server be a backup repository. That makes it want *every* file, no matter what, and it follows that it would archive everything, and have everything the client wants available for transferring to it.
+"""]]
diff --git a/doc/forum/A_question_an_the_nomad_use_cases__58___files_to_fetch__44___files_to_delete__44___files_to_keep__63__/comment_2_f0dbc3c723999bf0f22502e3a89d1d4a._comment b/doc/forum/A_question_an_the_nomad_use_cases__58___files_to_fetch__44___files_to_delete__44___files_to_keep__63__/comment_2_f0dbc3c723999bf0f22502e3a89d1d4a._comment
new file mode 100644
index 0000000000..3ae6b94c5c
--- /dev/null
+++ b/doc/forum/A_question_an_the_nomad_use_cases__58___files_to_fetch__44___files_to_delete__44___files_to_keep__63__/comment_2_f0dbc3c723999bf0f22502e3a89d1d4a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://alan.petitepomme.net/"
+ nickname="Alan Schmitt"
+ subject="comment 2"
+ date="2013-10-23T10:06:53Z"
+ content="""
+Thank you for the suggestions and explanations. I'm using a manual repo and I find that it works quite well.
+"""]]
diff --git a/doc/forum/A_really_stupid_question.mdwn b/doc/forum/A_really_stupid_question.mdwn
new file mode 100644
index 0000000000..38c7bcb56a
--- /dev/null
+++ b/doc/forum/A_really_stupid_question.mdwn
@@ -0,0 +1,3 @@
+Sorry, but all this wiki and the manpage seem to gloss over the most obvious question:
+
+What happens when you commit conflicting edits in different repositories?
diff --git a/doc/forum/A_really_stupid_question/comment_1_40e02556de0b00b94f245a0196b5a89f._comment b/doc/forum/A_really_stupid_question/comment_1_40e02556de0b00b94f245a0196b5a89f._comment
new file mode 100644
index 0000000000..2a400db3b0
--- /dev/null
+++ b/doc/forum/A_really_stupid_question/comment_1_40e02556de0b00b94f245a0196b5a89f._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="Good question!"
+ date="2011-12-20T23:07:25Z"
+ content="""
+You get a regular git merge conflict, which can be resolved in any of the regular ways, except that conflicting files are just symlinks.
+
+Example:
+
+<pre>
+$ git pull
+...
+Auto-merging myfile
+CONFLICT (add/add): Merge conflict in myfile
+Automatic merge failed; fix conflicts and then commit the result.
+$ git status
+# On branch master
+# Your branch and 'origin/master' have diverged,
+# and have 1 and 1 different commit(s) each, respectively.
+#
+# Unmerged paths:
+#   (use \"git add/rm <file>...\" as appropriate to mark resolution)
+#
+#	both added:         myfile
+#
+no changes added to commit (use \"git add\" and/or \"git commit -a\")
+$ git add myfile
+$ git commit -m \"took local version of the conflicting file\"
+</pre>
+"""]]
diff --git a/doc/forum/A_tiny_filesystem__63__.mdwn b/doc/forum/A_tiny_filesystem__63__.mdwn
new file mode 100644
index 0000000000..44a397e2f6
--- /dev/null
+++ b/doc/forum/A_tiny_filesystem__63__.mdwn
@@ -0,0 +1,7 @@
+First of all, thanks for the amazing work! I've already tried Owncloud, SparkleShare, Unison, rsync and lsycnd. Finally I may have found the real deal.
+
+My main problem with git-annex right now is that it is not fast/reliable enough. The main issues being: broken links now and then (I've probably done something wrong) and the slow: "startup scans", "consistency checks", "attempting to fix here" and "syncing with server". (50 Giga, Work-Server-Home, setup via webapp assistant)
+
+Please, tell me if I'm wrong, but I have the impression that git-annex would get much more robust if it was 100% sure that nobody could mess with its file tree. One possibility would be to add the option (when creating a repo) to make a protected filesystem controlled by git-annex only via FUSE (not something like ShareBox). This could be a tiny filesystem (such as loggedfs) that does nothing but make sure that only git-annex can mount/change files. This would definitely add to speed (reducing checks) and stability.
+
+I'm I being too naive? Most likely there is something I'm overlooking, like the amount of work this would involve.
diff --git a/doc/forum/A_tiny_filesystem__63__/comment_1_993e3f5dbe4bcbb5b7bd9e08ab9554f3._comment b/doc/forum/A_tiny_filesystem__63__/comment_1_993e3f5dbe4bcbb5b7bd9e08ab9554f3._comment
new file mode 100644
index 0000000000..aa246b5ee7
--- /dev/null
+++ b/doc/forum/A_tiny_filesystem__63__/comment_1_993e3f5dbe4bcbb5b7bd9e08ab9554f3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 1"
+ date="2014-04-05T22:34:32Z"
+ content="""
+git-annex can indeed be sped up by preventing modification of files in the tree. you can do this by running \"git annex indirect\"
+"""]]
diff --git a/doc/forum/A_tiny_filesystem__63__/comment_2_af57591d42868c8aa1cc1eda43ca8b98._comment b/doc/forum/A_tiny_filesystem__63__/comment_2_af57591d42868c8aa1cc1eda43ca8b98._comment
new file mode 100644
index 0000000000..1d4bc4be7a
--- /dev/null
+++ b/doc/forum/A_tiny_filesystem__63__/comment_2_af57591d42868c8aa1cc1eda43ca8b98._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="2001:1928:1:9::1"
+ subject="comment 2"
+ date="2014-04-07T04:25:43Z"
+ content="""
+what's wrong with [sharebox](https://github.com/chmduquesne/sharebox-fs), actually?
+"""]]
diff --git a/doc/forum/A_tiny_filesystem__63__/comment_3_3869c0472b50d7cf5e29ac0720f4f20f._comment b/doc/forum/A_tiny_filesystem__63__/comment_3_3869c0472b50d7cf5e29ac0720f4f20f._comment
new file mode 100644
index 0000000000..9c1613ca7c
--- /dev/null
+++ b/doc/forum/A_tiny_filesystem__63__/comment_3_3869c0472b50d7cf5e29ac0720f4f20f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="augusto"
+ ip="177.98.104.136"
+ subject="comment 3"
+ date="2014-04-08T22:46:18Z"
+ content="""
+When I saw Sharebox's page on Github I had the impression it was vaporware. It has a section named \"Planned Interface\" and there are no updates for quite a while.
+
+Is it working? How to install/use it?
+"""]]
diff --git a/doc/forum/Accessing_files_directly_on__a_USB_device.mdwn b/doc/forum/Accessing_files_directly_on__a_USB_device.mdwn
new file mode 100644
index 0000000000..7b16f65231
--- /dev/null
+++ b/doc/forum/Accessing_files_directly_on__a_USB_device.mdwn
@@ -0,0 +1,11 @@
+Using the assistant, I have created a repository on my laptop plus a synced repository on a USB disk. Looking into the first repository, I see my files accompanied by a .git directory. However, looking on the USB disk (e.g. /media/usb/annex), all I see is what looks like the content of a .git directory.
+
+This means that it is difficult to retrieve any file directly from this disk -- it has to be synced to another local repository first.
+
+Is there any way to change this ? E.g. to have a copy of the working tree, plus a .git directory, on the disk ?
+
+My use case: I have added plenty of media files to my repository. In addition to using the USB disk as a backup/medium for transfering these files to another computer, I'd like to be able to plug the disk to e.g. a media player and read the files directly from the tree, but it does not work at the moment.
+
+Is there anything I am missing ?
+
+Edited: yes, there is something I was missing: the forum entry at [[forum/USB_backup_with_files_visible/]]
diff --git a/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote.mdwn b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote.mdwn
new file mode 100644
index 0000000000..5d0addf6c4
--- /dev/null
+++ b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote.mdwn
@@ -0,0 +1 @@
+Hello, I would like to use git-annex to sync files between my desktop, laptop, and a remote server.  The remote server is part of a Beowulf cluster, these files are used to run simulations on the cluster, but I want the same files on my laptop and desktop to mirror those on the cluster.  I already have git annex assistant syncing files between the desktop and laptop.  I do not and will not ever have root access on the cluster, so I can't install git-annex there.  I can access the cluster server via ssh or by mounting it as NFS (OS X 10.11.6).  The NFS solution doesn't work due to the issues with file locking previously discussed on these forums.  I can set up an ssh repo but that's a "special remote" and I cannot access the files when ssh'ed in there, which I need to do to run the simulations.  Is there a strategy to do what I want with git-annex?  Thanks!
diff --git a/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_1_b2f7b4aa5e7c859de9741db440292365._comment b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_1_b2f7b4aa5e7c859de9741db440292365._comment
new file mode 100644
index 0000000000..fa475cba09
--- /dev/null
+++ b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_1_b2f7b4aa5e7c859de9741db440292365._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="comment 1"
+ date="2017-01-16T12:29:59Z"
+ content="""
+It sounds like you want to have a git-annex working directory on the server.
+
+You can put git-annex on the server without root access.  Just place it in a user folder such as ~/local .
+"""]]
diff --git a/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_2_6450ee0b5729beec155fbe0ce304e223._comment b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_2_6450ee0b5729beec155fbe0ce304e223._comment
new file mode 100644
index 0000000000..72348528aa
--- /dev/null
+++ b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_2_6450ee0b5729beec155fbe0ce304e223._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jaylangseth@fa84aeedaf6dd96a51e93b012339ac09fb4dc135"
+ nickname="jaylangseth"
+ avatar="http://cdn.libravatar.org/avatar/a40561e76777f90b29891f8fb86b5d05"
+ subject="comment 2"
+ date="2017-01-17T16:37:39Z"
+ content="""
+Ok thanks!  I'll give that a try.
+"""]]
diff --git a/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_3_9d8d03bda09596d03d9cfb7138a152f0._comment b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_3_9d8d03bda09596d03d9cfb7138a152f0._comment
new file mode 100644
index 0000000000..b689938a9e
--- /dev/null
+++ b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_3_9d8d03bda09596d03d9cfb7138a152f0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jaylangseth@fa84aeedaf6dd96a51e93b012339ac09fb4dc135"
+ nickname="jaylangseth"
+ avatar="http://cdn.libravatar.org/avatar/a40561e76777f90b29891f8fb86b5d05"
+ subject="comment 3"
+ date="2017-01-18T21:11:15Z"
+ content="""
+Ok!  Got it working, and I can ssh between the two machines and access git-annex-shell on both sides, got all the $PATH stuff right.  I set up one repo on the desktop and one on the server, made them remotes of each other, and I have managed to transfer files back and forth using \"git annex sync.\"  But how do I get the assistant to do this automatically without command line intervention?  Just dropping the file in one folder, it doesn't show up in another, unlike the other git-annex repos I have between my two local computers.
+"""]]
diff --git a/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_4_650ebbe4e7b57361a42882f3092122f0._comment b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_4_650ebbe4e7b57361a42882f3092122f0._comment
new file mode 100644
index 0000000000..8d08278600
--- /dev/null
+++ b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_4_650ebbe4e7b57361a42882f3092122f0._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-02-13T20:14:31Z"
+ content="""
+In your original message, you mentioned NFS won't work due to locking.
+However, as far as I know, those NFS locking problems can be worked
+around by `git config annex.pidlock true`. That said, I encourage
+*not* using NFS if there is any alternative and it sounds like you've
+found an alternative, so great.
+
+Re your question about the assistant, have you tried running the assistant
+in the repo on the server? Once it's running, it should update the
+repository whenever the client pushes over a change.
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository.mdwn b/doc/forum/Accessing_files_in_bare_repository.mdwn
new file mode 100644
index 0000000000..2ea6ba9d32
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository.mdwn
@@ -0,0 +1,5 @@
+I have set up a remote server repository using the git-annex web assistant, accessed via ssh. The repository is a bare one according to the config file in the annex directory on the server.
+
+I am wondering how I could access any of the files in the repository while logged in to the server - they don't have their usual file names to look for clearly. Is there a way to get a list of the files for starters? I tried using git annex find, but it never returns any files. git annex get followed by a filename of a document in the repository also doesn't work.
+
+Thanks to help me understand better how to approach this.
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_10_7eb66e3806f9524e043fae2da9d57d64._comment b/doc/forum/Accessing_files_in_bare_repository/comment_10_7eb66e3806f9524e043fae2da9d57d64._comment
new file mode 100644
index 0000000000..2b9bb86317
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_10_7eb66e3806f9524e043fae2da9d57d64._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 10"
+ date="2013-05-13T04:08:14Z"
+ content="""
+I'm not sure what's up.  I hope Joey can weigh in.
+
+\"git annex sync\" ought to go get the symlinks from your remote, and merge them into your master branch, which is currently checked out, so you should see them.  :(
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_11_f0165d66865ad14f7eb5d50e900c1df4._comment b/doc/forum/Accessing_files_in_bare_repository/comment_11_f0165d66865ad14f7eb5d50e900c1df4._comment
new file mode 100644
index 0000000000..abacbc30e4
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_11_f0165d66865ad14f7eb5d50e900c1df4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 11"
+ date="2013-05-13T17:33:26Z"
+ content="""
+When the assistant (or git annex sync) pushes to a repository, it creates a `synced/master` branch. So your bare repository has no regular `master` branch. So when you clone it, you get a repository with no branch checked out, which is what git-annex sync complains about.
+
+There are several solutions. The easiest is to run `git merge origin/synced/master`; then your checkout will have a master branch and you can use `git annex sync` from then on.
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_12_0e7ea5161b6da6e9bb9425bdb953de33._comment b/doc/forum/Accessing_files_in_bare_repository/comment_12_0e7ea5161b6da6e9bb9425bdb953de33._comment
new file mode 100644
index 0000000000..8d083d32db
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_12_0e7ea5161b6da6e9bb9425bdb953de33._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7"
+ nickname="Frederik Vanrenterghem"
+ subject="comment 12"
+ date="2013-05-14T04:07:37Z"
+ content="""
+Thanks Joey, this worked. The symlinks are in the directory and I can get the actual file contents (except for one attempt that failed - I'll need to check why that didn't seem to have propagated to the bare repository.)
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_13_f804b9bf71f7d04bd23ce32d813dc340._comment b/doc/forum/Accessing_files_in_bare_repository/comment_13_f804b9bf71f7d04bd23ce32d813dc340._comment
new file mode 100644
index 0000000000..470541f1d1
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_13_f804b9bf71f7d04bd23ce32d813dc340._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 13"
+ date="2013-06-12T18:56:39Z"
+ content="""
+Regarding my comment above, I've changed things so now `git annex sync` to a bare repository *does* push to the regular branch. So `git clone` will work without this bother.
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_1_6de649d38febd2240eb5b703da77c2d6._comment b/doc/forum/Accessing_files_in_bare_repository/comment_1_6de649d38febd2240eb5b703da77c2d6._comment
new file mode 100644
index 0000000000..ec14394b88
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_1_6de649d38febd2240eb5b703da77c2d6._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 1"
+ date="2013-05-08T13:40:16Z"
+ content="""
+Do you have git-annex available on the server from the command line?
+
+If so, the easiest way would probably be to clone the repo in git, and do a \"git annex init\" in it.  This would give you a copy of the repo with none of the files in it.  It would be tiny, just full of symlinks, no content.  Then pull down copies of *only* the individual files you need using \"git annex get.\"
+
+Maybe set that repo to \"untrusted\" to make sure other repos don't start depending on it to store copies of files to fulfill numcopies.
+
+When you're done with a copy of a file, just \"git annex drop\" it again so it disappears from this skeletal repo.
+
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_2_7e8dd09915ddc3267377e900891cb02c._comment b/doc/forum/Accessing_files_in_bare_repository/comment_2_7e8dd09915ddc3267377e900891cb02c._comment
new file mode 100644
index 0000000000..9c4df2f054
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_2_7e8dd09915ddc3267377e900891cb02c._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7"
+ nickname="Frederik Vanrenterghem"
+ subject="comment 2"
+ date="2013-05-10T03:21:57Z"
+ content="""
+I have git-annex on the VPS. The bare repository is in the directory \"annex\"
+
+From the user's root directory, I execute:
+
+git clone annex/ Documents
+Cloning into 'Documents'...
+done.
+warning: remote HEAD refers to nonexistent ref, unable to checkout.
+
+cd Documents/
+~/Documents$ git annex init 'Documents on VPS'
+init Documents on VPS ok
+(Recording state in git...)
+
+Still, when I try to get a file now, or do a git annex find, nothing shows up.
+
+
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_3_80eae4a73f38d1a7e35f97c33b6401f8._comment b/doc/forum/Accessing_files_in_bare_repository/comment_3_80eae4a73f38d1a7e35f97c33b6401f8._comment
new file mode 100644
index 0000000000..31aa5b1a39
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_3_80eae4a73f38d1a7e35f97c33b6401f8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 3"
+ date="2013-05-10T04:11:22Z"
+ content="""
+OK, I'm not sure what is up, but perhaps try \"git annex sync\" and see if that gives you the treeful of symlinks that you want.
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_4_5ec13e98d3ecb69426e974d34f712f9b._comment b/doc/forum/Accessing_files_in_bare_repository/comment_4_5ec13e98d3ecb69426e974d34f712f9b._comment
new file mode 100644
index 0000000000..720d787666
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_4_5ec13e98d3ecb69426e974d34f712f9b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 4"
+ date="2013-05-10T04:11:53Z"
+ content="""
+that is, do \"git annex sync\" from within your new clone.
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_5_dccbf5793998c6381e23eb8ff6497ebf._comment b/doc/forum/Accessing_files_in_bare_repository/comment_5_dccbf5793998c6381e23eb8ff6497ebf._comment
new file mode 100644
index 0000000000..d89ab793ec
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_5_dccbf5793998c6381e23eb8ff6497ebf._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7"
+ nickname="Frederik Vanrenterghem"
+ subject="comment 5"
+ date="2013-05-10T04:23:28Z"
+ content="""
+Thanks for your help. Unfortunately that doesn't do the trick either:
+
+git annex sync
+(merging origin/git-annex into git-annex...)
+(Recording state in git...)
+commit
+ok
+git-annex: no branch is checked out
+
+After this, git annex find still yields no results.
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_6_42d923916232c81f3b8bdbefa34a89d3._comment b/doc/forum/Accessing_files_in_bare_repository/comment_6_42d923916232c81f3b8bdbefa34a89d3._comment
new file mode 100644
index 0000000000..f33b521466
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_6_42d923916232c81f3b8bdbefa34a89d3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 6"
+ date="2013-05-10T12:52:48Z"
+ content="""
+OK, I'm going to guess the problem is there is no \"master\" branch in your cloned repository, because there is no \"master\" branch in a bare remote. (Not sure about this, just guessing.)  Try \"git branch\" in your clone.  If there is no \"master\" branch, that's the problem.
+
+If that's true, the right thing to do would probably have been not to clone from it, but to create a fresh git repo and then set your bare repo as a remote.
+
+You could try doing that -- create a fresh git repo, git annex init it, and then try something like \"git remote add barerepo /path/to/bare/repo\" and then \"git annex sync\" which should pull changes from the bare repo's 'synced/master' branch into your 'synced/master' branch and from there into your master branch, giving you all your symlinks.
+
+If that works you could declare your previous attempt \"dead\" and you'll be good.
+
+It *may* also be possible to just fix the clone you've got by creating a master branch, maybe by branching off of synced/master.  Do a \"git branch\" and see whether synced/master exists, and just try \"git branch master synced/master\" and then \"git checkout master\" and that might do the job!
+
+But I'm just throwing ideas around here, so I hope somebody who actually knows what's going on (joey? are you there?) will pipe up.
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_7_43a0a7d222faee582aeb3150a59cef87._comment b/doc/forum/Accessing_files_in_bare_repository/comment_7_43a0a7d222faee582aeb3150a59cef87._comment
new file mode 100644
index 0000000000..7684b0c461
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_7_43a0a7d222faee582aeb3150a59cef87._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7"
+ nickname="Frederik Vanrenterghem"
+ subject="comment 7"
+ date="2013-05-12T14:04:29Z"
+ content="""
+That all sounded very plausible, but for some reason it failed to work for me. I went back to basics and tried getting there by replicating steps 1 to 3 of the walkthrough, but also to no aval. I'll still try one more thing - setting up a local repository on the VPS and syncing it to my main one over XMPP. That seems rather convoluted given the bare repository is on the same server, but who knows...
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_8_ec1024235c1c74c113483a833df84654._comment b/doc/forum/Accessing_files_in_bare_repository/comment_8_ec1024235c1c74c113483a833df84654._comment
new file mode 100644
index 0000000000..e609a4c902
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_8_ec1024235c1c74c113483a833df84654._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 8"
+ date="2013-05-12T19:06:14Z"
+ content="""
+So what *does* show up?  Is your repo an empty directory?  Or are the symlinks that should point to content there?
+
+as far as git goes, are you on the master branch?  *is* there a master branch?  If you do \"git status\" what do you see?
+
+There's no reason this shouldn't work for you....
+"""]]
diff --git a/doc/forum/Accessing_files_in_bare_repository/comment_9_c156b8c1ae0f2905566bbdb13b84e577._comment b/doc/forum/Accessing_files_in_bare_repository/comment_9_c156b8c1ae0f2905566bbdb13b84e577._comment
new file mode 100644
index 0000000000..43b93b271c
--- /dev/null
+++ b/doc/forum/Accessing_files_in_bare_repository/comment_9_c156b8c1ae0f2905566bbdb13b84e577._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7"
+ nickname="Frederik Vanrenterghem"
+ subject="comment 9"
+ date="2013-05-12T23:51:16Z"
+ content="""
+I get the following:
+
+frederik@niihau:~/Documents$ git status
+# On branch master
+#
+# Initial commit
+#
+nothing to commit (create/copy files and use \"git add\" to track)
+
+And this is the config:
+
+frederik@niihau:~/Documents$ cat .git/config 
+[core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = false
+        logallrefupdates = true
+[remote \"origin\"]
+        fetch = +refs/heads/*:refs/remotes/origin/*
+        url = /home/frederik/annex
+        annex-uuid = 1648a298-27aa-4cb1-xx-xxx
+[annex]
+        uuid = 4406bd35-9ff7-4008-yy-yyy
+        version = 3
+[remote \"niihau\"]
+        url = /home/frederik/annex
+        fetch = +refs/heads/*:refs/remotes/niihau/*
+        annex-uuid = 1648a298-27aa-4cb1-xx-xxx
+
+Not having worked with git before, all this is still very new for me. I have 33M of data in the .git directory, mostly in objects, so it does seem to have synced something already.
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository.mdwn b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository.mdwn
new file mode 100644
index 0000000000..f09b2ea3de
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository.mdwn
@@ -0,0 +1,28 @@
+Hi!
+
+One of my annex repository has a very strange behavior. Every `git annex` command is very slow.
+
+I'm using MacOSX Mavericks, and this repository is a network drive, mounted with Samba. It's using direct mode, and the filesystem is crippled. I use *annex* for storing huge files, for example movies. I moved some files in this directory, and used `git annex add`. It was long (as checksum was performed) and I thought that everything was OK. I tried `git log -p`, it was OK too:
+
+    new file mode 120000
+    index 0000000..e58c65a
+    --- /dev/null
+    +++ b/Movies/movie.mp4
+    @@ -0,0 +1 @@
+    +../.git/annex/objects/FK/60/SHA256E-s346858581--053dca6a842376ab8022722df306ad5
+    \ No newline at end of file
+
+However it was not. I tried to launch `git annex sync another_repo` (with *another_repo* indirect and on a local disk) and it took ages. Even `git annex list` takes ages, **on every repository linked to this one**. With `ps -A`, I found out that the issue was created by `git --git-dir=/Volumes/SAMBA_REMOTE/.git --work-tree=/Volumes/SAMBA_REMOTE -c core.bare=false checkout -q -B annex/direct/master`.
+
+**Have you ever noticed this behavior? Have I done something wrong?**
+
+Here is the output of `git annex version`:
+
+    git-annex version: 5.20131117-gbd514dc
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav glacier hook
+    local repository version: 4
+    default repository version: 3
+    supported repository versions: 3 5
+    upgrade supported from repository versions: 0 1 2 4
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/bugs/direct_mode_sync_should_avoid_git_commit.mdwn b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/bugs/direct_mode_sync_should_avoid_git_commit.mdwn
new file mode 100644
index 0000000000..ec7ce2ccef
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/bugs/direct_mode_sync_should_avoid_git_commit.mdwn
@@ -0,0 +1 @@
+See [[/bugs/direct_mode_sync_should_avoid_git_commit/]] instead.
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_10_06dae5709750ea1da4f7fdbee4e84efc._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_10_06dae5709750ea1da4f7fdbee4e84efc._comment
new file mode 100644
index 0000000000..c8feb05b93
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_10_06dae5709750ea1da4f7fdbee4e84efc._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 10"
+ date="2013-11-26T21:48:11Z"
+ content="""
+Hmm. Seems to me that `git commit` is trying to download the whole big file from the SMB share. Perhaps just to compare it with the symlink it expects to be there?
+
+When I try this, in a large direct mode repository with some video from *my* family, `git commit` does not open the file (verified with strace), let alone read it, and so finishes in well under 1 second. 
+
+Aha, I was able to reproduce `git commit` doing that with a repo on a FAT filesystem. git opens the file, and mmaps it, and I guess it proceeds to try to diff it against the symlink standin file it expected to be there.
+
+This is particularly unfortunate, since `git commit` is only, I think, doing this so that it can print out a \"Changes not staged for commit\" message. Which git-annex sync throws away. There seems to be no git commit option that disables this behavior.
+
+I think that this calls for making `git annex sync` not use `git commit` any longer, and instead manually build the commit using `git-write-tree` and `git-commit-tree`. Since I don't know if I will get to this before the thanksgiving holiday, I am creating a bug: [[bugs/direct_mode_sync_should_avoid_git_commit]]
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_11_2069c5c41882ae0a1973fb7da583b60e._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_11_2069c5c41882ae0a1973fb7da583b60e._comment
new file mode 100644
index 0000000000..76ecd13c2a
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_11_2069c5c41882ae0a1973fb7da583b60e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="TroisSinges"
+ ip="82.227.207.5"
+ subject="comment 11"
+ date="2013-11-26T21:57:52Z"
+ content="""
+Awesome! Thanks for your very efficient investigations. I'll stay tuned to the bug report.
+
+Happy Thanksgiving!
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_12_b35e3a87c30974eedd71ebe52ecbed96._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_12_b35e3a87c30974eedd71ebe52ecbed96._comment
new file mode 100644
index 0000000000..282f1fb4ce
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_12_b35e3a87c30974eedd71ebe52ecbed96._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="TroisSinges"
+ ip="82.227.207.5"
+ subject="comment 12"
+ date="2013-11-27T12:08:29Z"
+ content="""
+I corrected the bug address: See [[/bugs/direct_mode_sync_should_avoid_git_commit/]]
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_13_84e026f9bda87bfd12a3769dcef77f8b._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_13_84e026f9bda87bfd12a3769dcef77f8b._comment
new file mode 100644
index 0000000000..dfc0db3d2d
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_13_84e026f9bda87bfd12a3769dcef77f8b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 13"
+ date="2013-11-27T12:13:04Z"
+ content="""
+thanks!
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_14_b2ac2ea300a5026832b40a1a6b27a7cd._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_14_b2ac2ea300a5026832b40a1a6b27a7cd._comment
new file mode 100644
index 0000000000..4dfc762ac3
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_14_b2ac2ea300a5026832b40a1a6b27a7cd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 14"
+ date="2013-12-02T20:05:00Z"
+ content="""
+Should be fixed; the git commit is now avoided.
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_1_ed3534196164c6736a8dbf21c65c119d._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_1_ed3534196164c6736a8dbf21c65c119d._comment
new file mode 100644
index 0000000000..ed104f488e
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_1_ed3534196164c6736a8dbf21c65c119d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 1"
+ date="2013-11-26T17:26:12Z"
+ content="""
+If you run git-annex with --debug, it will print out every command it is running. This is useful because A) I can see the commands in context and B) it includes timestamps, which is a little bit more informative than \"it took ages\". (Which can mean anything.)
+
+Anyway, I figured out the problem. Upgrade from v4 to v5 does what should be a one-time git checkout, but it seems that the auto upgrade code neglected to update annex.version, so it started doing it on every command run in a v4 repo. Fixed in git. You can work around the bug by running \"git config annex.version 5\".
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_2_1e29bcf568f02765c48f0eac6c640673._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_2_1e29bcf568f02765c48f0eac6c640673._comment
new file mode 100644
index 0000000000..ab0cd9c9d4
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_2_1e29bcf568f02765c48f0eac6c640673._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="TroisSinges"
+ ip="82.227.207.5"
+ subject="comment 2"
+ date="2013-11-26T20:42:03Z"
+ content="""
+My problem isn't solved. I cloned the repository from my netbook to the SMD drive, and added a file in this new direct annex repository :
+
+    [3singes:/Volumes/Video/Videos/Films] $ git annex add MyFamily.mkv --debug
+    [2013-11-26 19:52:59 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"ls-files\",\"--others\",\"--exclude-standard\",\"-z\",\"--\",\"MyFamily.mkv\"]
+    [2013-11-26 19:52:59 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"ls-files\",\"--modified\",\"-z\",\"--\",\"MyFamily.mkv\"]
+    [2013-11-26 19:52:59 CET] chat: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
+    add MyFamily.mkv [2013-11-26 19:52:59 CET] chat: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.numcopies\",\"--\"]
+    (checksum...) [2013-11-26 19:52:59 CET] read: gsha256sum [\"MyFamily.mkv\"]
+    [2013-11-26 20:55:35 CET] chat: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
+    [2013-11-26 20:55:35 CET] chat: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"hash-object\",\"-t\",\"blob\",\"-w\",\"--stdin\",\"--no-filters\"]
+    ok
+    (Recording state in git...)
+    [2013-11-26 20:55:35 CET] feed: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+    [2013-11-26 20:55:35 CET] chat: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+    [2013-11-26 20:55:35 CET] feed: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+    [2013-11-26 20:55:35 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2013-11-26 20:55:36 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"write-tree\"]
+    [2013-11-26 20:55:36 CET] chat: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"commit-tree\",\"9bdb7b18b44020441ec8dc179e676120e769ff32\",\"-p\",\"refs/heads/git-annex\"]
+    [2013-11-26 20:55:37 CET] call: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"update-ref\",\"refs/heads/git-annex\",\"293332232ca4e7428090171b52dcc5b3b80d1df6\"]
+
+Let's try to sync to my macbookpro annex repository:
+
+    [3singes:/Volumes/Video/Videos/Films] $ git annex sync macbookpro --debug
+    [2013-11-26 20:57:48 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+    [2013-11-26 20:57:48 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2013-11-26 20:57:49 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..293332232ca4e7428090171b52dcc5b3b80d1df6\",\"--oneline\",\"-n1\"]
+    [2013-11-26 20:57:49 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..b2146cf0abc7d6a7e5c79d3b133181b56cd77461\",\"--oneline\",\"-n1\"]
+    [2013-11-26 20:57:49 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c2cf7488b4745d4168491d8e62f5bdc354869133\",\"--oneline\",\"-n1\"]
+    [2013-11-26 20:57:49 CET] chat: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
+    [2013-11-26 20:57:49 CET] read: git [\"config\",\"--null\",\"--list\"]
+    [2013-11-26 20:57:49 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"ls-files\",\"--stage\",\"-z\",\"--others\",\"--exclude-standard\",\"--\",\"/Volumes/Video/Videos\"]
+    [2013-11-26 20:57:50 CET] chat: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
+    (Recording state in git...)
+    [2013-11-26 20:57:55 CET] feed: xargs [\"-0\",\"git\",\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"add\",\"-f\"]
+    commit
+    [2013-11-26 20:57:55 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"commit\",\"-m\",\"git-annex automatic sync\"]
+
+Now it's 21:41 CET, and it's been stuck for circa 1 hour.
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_3_9ea6803a94b1de15079a3fa20d59c9af._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_3_9ea6803a94b1de15079a3fa20d59c9af._comment
new file mode 100644
index 0000000000..f2c4fd77e1
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_3_9ea6803a94b1de15079a3fa20d59c9af._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 3"
+ date="2013-11-26T20:51:59Z"
+ content="""
+The problem you reported *is* solved. You were not talking about syncing before.
+
+If your setup is such that `git commit` takes a long time to run, then `git annex sync` is also necessarily going to take a long time to run.
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_4_3fae5a7fa5d99d0eb4473adb43e7f6f5._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_4_3fae5a7fa5d99d0eb4473adb43e7f6f5._comment
new file mode 100644
index 0000000000..e9b7655cf7
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_4_3fae5a7fa5d99d0eb4473adb43e7f6f5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="TroisSinges"
+ ip="82.227.207.5"
+ subject="comment 4"
+ date="2013-11-26T20:55:39Z"
+ content="""
+Thanks for your answer. On the second part of my problem, *why* should `git commit` be slow? It's only committing a file with a line (../.git/annex/...), isn't it?
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_5_57a5b73cff480266355e75c7bdc762c2._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_5_57a5b73cff480266355e75c7bdc762c2._comment
new file mode 100644
index 0000000000..51e31d9b4e
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_5_57a5b73cff480266355e75c7bdc762c2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="TroisSinges"
+ ip="82.227.207.5"
+ subject="comment 5"
+ date="2013-11-26T21:02:17Z"
+ content="""
+Err, I read my post again, and I definitely *was* talking about syncing ;-)
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_6_bbcf5e863c8f152e1079536e9011a404._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_6_bbcf5e863c8f152e1079536e9011a404._comment
new file mode 100644
index 0000000000..4640a91bfc
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_6_bbcf5e863c8f152e1079536e9011a404._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 6"
+ date="2013-11-26T21:04:44Z"
+ content="""
+I think the most likely reason for git commit to be slow on your setup is that it probably rewrites .git/index. If you have a lot of files in your repository, the index file will be large and rewriting the index file will involve re-transferring it all over the network to the SMB share. 
+
+It's also possible that git commit scans the whole work tree, although I don't think it should -- it's not been told to with -a.
+
+You may be able to find what's taking a long time by
+
+    strace git --git-dir=/Volumes/Video/Videos/.git --work-tree=/Volumes/Video/Videos -c core.bare=false commit -m \"git-annex automatic sync\"
+
+(or ltrace)
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_7_fdcd144c22601bdf98ff844254b0120d._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_7_fdcd144c22601bdf98ff844254b0120d._comment
new file mode 100644
index 0000000000..033a1af45a
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_7_fdcd144c22601bdf98ff844254b0120d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 7"
+ date="2013-11-26T21:07:12Z"
+ content="""
+If you kept your git repository on your local disk, and used a [[directory special remote|special_remotes/directory]] on the SMB share, you could then `git annex copy --to smbshare` and `git annex get --from smbshare` as desired, which would probably be much more efficient.
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_8_b77243e765b2af7ba71e963fcb5cbbb1._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_8_b77243e765b2af7ba71e963fcb5cbbb1._comment
new file mode 100644
index 0000000000..273b9d8e91
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_8_b77243e765b2af7ba71e963fcb5cbbb1._comment
@@ -0,0 +1,71 @@
+[[!comment format=mdwn
+ username="TroisSinges"
+ ip="82.227.207.5"
+ subject="comment 8"
+ date="2013-11-26T21:17:38Z"
+ content="""
+Thanks again for your answers.
+
+`.git/index` is only 30Ko big. It shouldn't be an issue, even through the network.
+
+However, I ran `lsof`, and strangely it lock the big file I added before (`/Volumes/Video/Videos/Films/MyFamily.mkv`)
+
+    COMMAND   PID    USER   FD   TYPE DEVICE    SIZE/OFF                 NODE NAME
+    git     68047 3singes  cwd    DIR   46,7       16384  5152641528667254045 /Volumes/Video/Videos
+    git     68047 3singes  txt    REG    1,4     3035984             77501447 /Applications/git-annex.app/Contents/MacOS/bundle/git
+    git     68047 3singes  txt    REG   46,7        8632  9219631544499731818 /Volumes/Video/Videos/.git/objects/pack/pack-99901c82bacfa26c04f505ceb27c4af9ccda414f.idx
+    git     68047 3singes  txt    REG    1,4      403392             77501680 /Applications/git-annex.app/Contents/MacOS/bundle/usr/lib/libpcre.0.dylib
+    git     68047 3singes  txt    REG   46,7        4012  8204150806531008435 /Volumes/Video/Videos/.git/objects/pack/pack-bb60a2315b13bda720682a4213507e5ee9ba029f.idx
+    git     68047 3singes  txt    REG   46,7       15969 12003107822997399035 /Volumes/Video/Videos/.git/objects/pack/pack-bb60a2315b13bda720682a4213507e5ee9ba029f.pack
+    git     68047 3singes  txt    REG    1,4      169392             77501683 /Applications/git-annex.app/Contents/MacOS/bundle/usr/lib/libz.1.dylib
+    git     68047 3singes  txt    REG    1,4     2088992             77501673 /Applications/git-annex.app/Contents/MacOS/bundle/usr/lib/libiconv.2.dylib
+    git     68047 3singes  txt    REG    1,4      600832             72809225 /usr/lib/dyld
+    git     68047 3singes  txt    REG    1,4   342937194             75930310 /private/var/db/dyld/dyld_shared_cache_x86_64
+    git     68047 3singes    0u   CHR  16,10    0t718314                 2413 /dev/ttys010
+    git     68047 3singes    1w   CHR    3,2         0t0                  308 /dev/null
+    git     68047 3singes    2w   CHR    3,2         0t0                  308 /dev/null
+    git     68047 3singes    3u   REG   46,7           0 17793593705208135594 /Volumes/Video/Videos/.git/index.lock
+    git     68047 3singes    4r   REG   46,7 15581987050 12221620371912261305 /Volumes/Video/Videos/Films/MyFamily.mkv
+    git     68047 3singes    8w   CHR    3,2         0t0                  308 /dev/null
+
+I'm using MacOSX, so I can only use `dtrace`, which I don't know so much.
+
+**The process is over, after 1H30:**
+
+    ok
+    [2013-11-26 22:13:48 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"HEAD\"]
+    [2013-11-26 22:13:48 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+    [2013-11-26 22:13:48 CET] call: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"show-ref\",\"--verify\",\"-q\",\"refs/heads/synced/master\"]
+    [2013-11-26 22:13:49 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/heads/synced/master\",\"--oneline\",\"-n1\"]
+    pull macbookpro
+    [2013-11-26 22:13:49 CET] call: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"fetch\",\"macbookpro\"]
+    From /Users/3singes/Movies/NE PAS SAUVEGARDER/Videos
+       b2146cf..c2cf748  git-annex  -> macbookpro/git-annex
+    [2013-11-26 22:13:50 CET] call: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"show-ref\",\"--verify\",\"-q\",\"refs/remotes/macbookpro/annex/direct/master\"]
+    [2013-11-26 22:13:50 CET] call: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"show-ref\",\"--verify\",\"-q\",\"refs/remotes/macbookpro/synced/master\"]
+    [2013-11-26 22:13:50 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/synced/master..refs/remotes/macbookpro/synced/master\",\"--oneline\",\"-n1\"]
+    ok
+    [2013-11-26 22:13:50 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+    [2013-11-26 22:13:50 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2013-11-26 22:13:50 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..293332232ca4e7428090171b52dcc5b3b80d1df6\",\"--oneline\",\"-n1\"]
+    [2013-11-26 22:13:51 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..b2146cf0abc7d6a7e5c79d3b133181b56cd77461\",\"--oneline\",\"-n1\"]
+    [2013-11-26 22:13:51 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c2cf7488b4745d4168491d8e62f5bdc354869133\",\"--oneline\",\"-n1\"]
+    [2013-11-26 22:13:51 CET] call: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"synced/master\"]
+    [2013-11-26 22:13:51 CET] call: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"master\"]
+    [2013-11-26 22:13:51 CET] call: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"show-ref\",\"--verify\",\"-q\",\"refs/remotes/macbookpro/synced/master\"]
+    [2013-11-26 22:13:51 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"log\",\"refs/remotes/macbookpro/synced/master..refs/heads/synced/master\",\"--oneline\",\"-n1\"]
+    [2013-11-26 22:13:51 CET] call: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"show-ref\",\"--verify\",\"-q\",\"refs/remotes/macbookpro/git-annex\"]
+    [2013-11-26 22:13:51 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"log\",\"refs/remotes/macbookpro/git-annex..git-annex\",\"--oneline\",\"-n1\"]
+    push macbookpro
+    [2013-11-26 22:13:52 CET] call: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"push\",\"macbookpro\",\"+git-annex:synced/git-annex\",\"annex/direct/master:synced/master\"]
+    Counting objects: 9, done.
+    Delta compression using up to 8 threads.
+    Compressing objects: 100% (4/4), done.
+    Writing objects: 100% (5/5), 440 bytes | 0 bytes/s, done.
+    Total 5 (delta 3), reused 0 (delta 0)
+    To /Users/3singes/Movies/NE PAS SAUVEGARDER/Videos
+       c2cf748..2933322  git-annex -> synced/git-annex
+    [2013-11-26 22:13:57 CET] read: git [\"--git-dir=/Volumes/Video/Videos/.git\",\"--work-tree=/Volumes/Video/Videos\",\"-c\",\"core.bare=false\",\"push\",\"macbookpro\",\"master\"]
+    ok
+
+"""]]
diff --git a/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_9_cb0815e96ee211d4778f2e7a4274e855._comment b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_9_cb0815e96ee211d4778f2e7a4274e855._comment
new file mode 100644
index 0000000000..041f3c5477
--- /dev/null
+++ b/doc/forum/Actions_very_slow_on_a_direct___40__and_crippled__41___annex_repository/comment_9_cb0815e96ee211d4778f2e7a4274e855._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="TroisSinges"
+ ip="82.227.207.5"
+ subject="comment 9"
+ date="2013-11-26T21:19:42Z"
+ content="""
+I thought to a directory special remote, but it doesn't meet my needs: the SMB drive is used by a MediaCenter, so I need the working tree.
+"""]]
diff --git a/doc/forum/Add_a___34__local__34___remote.mdwn b/doc/forum/Add_a___34__local__34___remote.mdwn
new file mode 100644
index 0000000000..c35a637a85
--- /dev/null
+++ b/doc/forum/Add_a___34__local__34___remote.mdwn
@@ -0,0 +1,13 @@
+I have been playing around with annex assistent today (way late as I am one of the Kickstarter backers) and found the following puzzling.
+
+I am running a fairly new version, my package manager calls it 4.20130323 (git-annex does not seem to have a --version switch). 
+
+I have been playing around with the annex assistent webapp today and have the following questions/observations: 
+
+1) The "remote" server creates a bare git repository as far as I can tell, the "local computer" probably does the right thing (but I cannot run it as the "other box" has no X or browser). Is there any way to remotely create a "local" copy (i.e. non-bare git repository, which can later be managed by the cli?)
+2) It seems like git-annex-assistent (webapp) binds to localhost, is it possible to let it bind to either a specific ip-address (or all)? (Yes, I understand the security implications, but the use-case is the box from question 2 - i.e. on local network but no X and no browser). 
+3) what is being launched when I hit "files", on the video it starts a file-manager on my box nothing happens (and no errors as far as I can tell). 
+
+Thank you in advance
+
+Svenne
diff --git a/doc/forum/Add_a___34__local__34___remote/comment_1_c68ad724b465c4be5243be687168c0b3._comment b/doc/forum/Add_a___34__local__34___remote/comment_1_c68ad724b465c4be5243be687168c0b3._comment
new file mode 100644
index 0000000000..251e89e034
--- /dev/null
+++ b/doc/forum/Add_a___34__local__34___remote/comment_1_c68ad724b465c4be5243be687168c0b3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-08T19:11:33Z"
+ content="""
+1. If you want to use the cli for managing the repository, why not `git clone` it using the cli as well? Set up a remote in your existing repository pointing at the repository you cloned, and the assistant will push changes to it. This is all that the webapp would do when creating the repository. The webapp does not set up remote non-bare repositories because unless the user is comfortable with the cli, nothing is going to keep them up-to-date.
+
+2. Setting up the assistant on a headless box is something I need to support better, indeed. I've just now made `git annex webapp --listen=IP` listen on the specified IP address, and output the URL you can connect to from the remote side. Note that this does not yet use HTTPS, so use with caution.
+
+3. It uses the `xdg-open` program to open a file manager. If `xdg-open` was not in your PATH, it would instead point the web browser at a file:/// URI as a fallback. If it seems to do nothing, this probably means `xdg-open` is in PATH but not working for some reason. Try running `xdg-open /path/to/your/repository`
+"""]]
diff --git a/doc/forum/Add_annex_files_outside_git_root_directory.mdwn b/doc/forum/Add_annex_files_outside_git_root_directory.mdwn
new file mode 100644
index 0000000000..8d90cbf99a
--- /dev/null
+++ b/doc/forum/Add_annex_files_outside_git_root_directory.mdwn
@@ -0,0 +1,24 @@
+Hi,
+
+I love the idea of git-annex, and I'm trying to do my first steps with it. I'm stuck on the following issue:
+
+When creating a git repository and annexing a file in the root directory, everything works as expected:
+
+    git init
+    git annex init "mytest"
+    echo 1 > annexfile
+    git annex add annexfile
+    # add annexfile ok
+    # (Recording state in git...)
+
+However, when I try to add a file in a subdirectory of the repository, the adding command fails without any error message:
+
+    mkdir mydir
+    echo 1 > mydir/myfile
+    git annex add mydir/myfile
+    # no message, no status change, nothing
+    # note that I can add the file in the root dir and then move it to `mydir`
+
+Am I doing something wrong here?
+
+Thank you!
diff --git a/doc/forum/Add_annex_files_outside_git_root_directory/comment_1_3d7c8917633a6632f22385b8f7a98ccf._comment b/doc/forum/Add_annex_files_outside_git_root_directory/comment_1_3d7c8917633a6632f22385b8f7a98ccf._comment
new file mode 100644
index 0000000000..c0a433f947
--- /dev/null
+++ b/doc/forum/Add_annex_files_outside_git_root_directory/comment_1_3d7c8917633a6632f22385b8f7a98ccf._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-04T17:19:46Z"
+ content="""
+git-annex should have no difficulty doing that, and in fact its test
+suite includes some adds of files in subdirs.
+
+The most likely reason for this behavior would be if you have configured
+a `.gitignore` file (or other method of configuring gitignore) to 
+exclude the file you want to add. If so, "git annex add --force
+mydir/myfile" would override the gitignore.
+
+Internally, git-annex add runs "git ls-files --others --exclude-standard"
+and passes it the files/dirs you specified to add, and then adds
+the files that command lists. So you can run that command and see
+what it lists too.
+"""]]
diff --git a/doc/forum/Add_annex_files_outside_git_root_directory/comment_2_312a57883d809857a69216fa47e04f17._comment b/doc/forum/Add_annex_files_outside_git_root_directory/comment_2_312a57883d809857a69216fa47e04f17._comment
new file mode 100644
index 0000000000..0e5be5eec8
--- /dev/null
+++ b/doc/forum/Add_annex_files_outside_git_root_directory/comment_2_312a57883d809857a69216fa47e04f17._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlJl0OCe6AJEnIFIcg-t5Rhk-lI_Y-tWUs"
+ nickname="Michael"
+ subject="comment 2"
+ date="2015-02-12T16:22:18Z"
+ content="""
+Ok, seems that I assumed incorrectly that `.gitignore` files were not valid for annex.
+
+However, if I `git add file_that_is_ignored`, I get an error message saying:
+
+    The following paths are ignored by one of your .gitignore files:
+    Use -f if you really want to add them.
+
+Would it be possible for git-annex to be consistent with git behaviour here?
+"""]]
diff --git a/doc/forum/Add_file_to_git_index_while_in_direct_mode.mdwn b/doc/forum/Add_file_to_git_index_while_in_direct_mode.mdwn
new file mode 100644
index 0000000000..e1678e95c7
--- /dev/null
+++ b/doc/forum/Add_file_to_git_index_while_in_direct_mode.mdwn
@@ -0,0 +1,20 @@
+Hi, 
+
+Is there a preferred way to add files to git's index (instead of the annex) while in direct mode? 
+
+I am trying to use git-annex for scientific data. On linux and mac in indirect mode, the git workflow is basically unchanged, and I really like the way git annex works. Unfortunately when I use git-annex on Windows, I have not found a good way to add things to git's tree. 
+
+I've tried two things:
+
+```
+$ git annex proxy -- git add smallfile
+```
+
+This is slow because it has to copy things over to create a work tree
+
+```
+$ git config annex.largefiles="*.pdf or *.h5"
+$ git annex add largefile.pdf
+```
+
+This doesn't seem to work as well as I'd like either. I'd like the equivalent of a ```git add``` command in direct mode.
diff --git a/doc/forum/Add_file_to_git_index_while_in_direct_mode/comment_1_3eb43a983eba09f500b776f75b299341._comment b/doc/forum/Add_file_to_git_index_while_in_direct_mode/comment_1_3eb43a983eba09f500b776f75b299341._comment
new file mode 100644
index 0000000000..df4fd7655f
--- /dev/null
+++ b/doc/forum/Add_file_to_git_index_while_in_direct_mode/comment_1_3eb43a983eba09f500b776f75b299341._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-10T22:02:19Z"
+ content="""
+In what way does setting annex.largefiles and using git annex add not work
+as well as you'd like?
+"""]]
diff --git a/doc/forum/Add_file_to_git_index_while_in_direct_mode/comment_2_6945d9e930e7385f0abe6538622a9aa3._comment b/doc/forum/Add_file_to_git_index_while_in_direct_mode/comment_2_6945d9e930e7385f0abe6538622a9aa3._comment
new file mode 100644
index 0000000000..7dc65c2dc6
--- /dev/null
+++ b/doc/forum/Add_file_to_git_index_while_in_direct_mode/comment_2_6945d9e930e7385f0abe6538622a9aa3._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="aloukian@c071735c08bc04266b792aa478ad1bae2d6a8b50"
+ nickname="aloukian"
+ subject="comment 2"
+ date="2015-09-11T00:42:03Z"
+ content="""
+Sorry, I should have clarified. I was not sure how to add a commit message.
+
+I played with a test repo and I think I figured it out. What I tried was this:
+   
+```
+$ git init test-repo
+$ touch test.txt
+$ git add test.txt
+$ git commit -m \"initial commit\"
+$ git annex init
+$ git config annex.largefiles=\"*.pdf\"
+$ echo \"updated\" > test.txt
+$ git annex add test.txt
+$ git annex sync -m \"updated test.txt\"
+```
+
+So if I understand correctly, in direct mode 
+
+- ```git add``` ->  ```git annex add``` 
+- ```git commit -m MSG``` -> ```git annex sync -m MSG```
+
+```git log``` now shows the right message, but I am still not sure how to check whether a file is in the annex or directly in the git tree. I suppose I could just make aliases for git add and git commit, but I wouldn't be able to add arbitrary files to git annex without playing with annex.largefiles. For example, if I had many small ```.txt``` files and one large file and I wanted to just add that large file to the git annex, I'd have to change the largefiles setting.
+
+Is there a better way of doing this or is loss of functionality intrinsic until Windows symlinks work?
+"""]]
diff --git a/doc/forum/Add_file_to_git_index_while_in_direct_mode/comment_3_8f77b5dcf582e88099b2e6e77563fb11._comment b/doc/forum/Add_file_to_git_index_while_in_direct_mode/comment_3_8f77b5dcf582e88099b2e6e77563fb11._comment
new file mode 100644
index 0000000000..e597917e3e
--- /dev/null
+++ b/doc/forum/Add_file_to_git_index_while_in_direct_mode/comment_3_8f77b5dcf582e88099b2e6e77563fb11._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-09-11T17:39:05Z"
+ content="""
+You can temporarily set annex.largefiles to match no files, while running
+git-annex add, to force it to add the file to git instead of the annex.
+
+git -c annex.largefiles='exclude=*' annex add somefile
+"""]]
diff --git a/doc/forum/Add_files_to_direct_mode_repos.mdwn b/doc/forum/Add_files_to_direct_mode_repos.mdwn
new file mode 100644
index 0000000000..a5cb2d691c
--- /dev/null
+++ b/doc/forum/Add_files_to_direct_mode_repos.mdwn
@@ -0,0 +1 @@
+I started a git annex repo in a crippled filesystem (FAT32). I git-annex-add'ed some files but then I learned one cannot then git-commit them if on a direct mode repo (“fatal: This operation must be run in a work tree”). How do I add files in a crippled filesystem and then have them propagate to other repost if numcopies > 1?
diff --git a/doc/forum/Add_files_to_direct_mode_repos/comment_1_41d632853d3160899b04da7e4b95475e._comment b/doc/forum/Add_files_to_direct_mode_repos/comment_1_41d632853d3160899b04da7e4b95475e._comment
new file mode 100644
index 0000000000..5ca3a4edfd
--- /dev/null
+++ b/doc/forum/Add_files_to_direct_mode_repos/comment_1_41d632853d3160899b04da7e4b95475e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="comment 1"
+ date="2017-09-24T13:14:53Z"
+ content="""
+You should reat the [dirct mode page](https://git-annex.branchable.com/direct_mode/#index5h2).
+
+In short, use `git-annex sync` as a replacement for `git commit`.
+
+"""]]
diff --git a/doc/forum/Added_file_to_annex_but_it_doesn__39__t_show_up_in_here.mdwn b/doc/forum/Added_file_to_annex_but_it_doesn__39__t_show_up_in_here.mdwn
new file mode 100644
index 0000000000..03dcf5a8fb
--- /dev/null
+++ b/doc/forum/Added_file_to_annex_but_it_doesn__39__t_show_up_in_here.mdwn
@@ -0,0 +1,75 @@
+I recently added a file and for some reason it doesn't show up as being available locally, but I just added it.
+
+```
+find .git/annex | grep -i harry
+.git/annex/objects/f1/36/WORM-s2046008512-m1537755616--Harry,32Brown,32,402009,41,321080p.mp4
+.git/annex/objects/f1/36/WORM-s2046008512-m1537755616--Harry,32Brown,32,402009,41,321080p.mp4/WORM-s2046008512-m1537755616--Harry,32Brown,32,402009,41,321080p.mp4
+```
+
+```
+git annex find --in here --debug
+[2019-04-16 17:45:49.540555] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2019-04-16 17:45:49.5474] process done ExitSuccess
+[2019-04-16 17:45:49.547482] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2019-04-16 17:45:49.557155] process done ExitSuccess
+[2019-04-16 17:45:49.557621] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--"]
+[2019-04-16 17:45:49.565683] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2019-04-16 17:45:49.571062] process done ExitSuccess
+[2019-04-16 17:45:49.571143] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2019-04-16 17:45:49.576242] process done ExitSuccess
+[2019-04-16 17:45:49.577407] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..739c33e04bd4d714eff432f630d1dcbb69625d6a","--pretty=%H","-n1"]
+[2019-04-16 17:45:49.584986] process done ExitSuccess
+[2019-04-16 17:45:49.585072] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..404abbb2b903597ee753eba0f9213125d41a31f6","--pretty=%H","-n1"]
+[2019-04-16 17:45:49.591936] process done ExitSuccess
+[2019-04-16 17:45:49.636082] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2019-04-16 17:45:49.638359] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2019-04-16 17:45:49.643613] read: git ["config","--null","--list"]
+[2019-04-16 17:45:49.727427] process done ExitSuccess
+[2019-04-16 17:45:49.727735] process done ExitSuccess
+```
+
+In the past, adding the file always resulted in behavior that made sense. I'm at a loss as to what to do. If I try to add it again, nothing happens. I can't copy it to another remote; it's like it doesn't actually exist.
+
+
+```
+git annex version
+git-annex version: 7.20190220-g1812ec5da
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV FsEvents TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.3 http-client-0.5.14 persistent-sqlite-2.9.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: darwin x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+
+cat .gitattributes
+* annex.largefiles=(largerthan=500kb)
+* annex.backend=WORM
+
+cat .git/config
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+	ignorecase = true
+	precomposeunicode = true
+[annex]
+	thin = true
+	uuid = UUID
+	version = 5
+	direct = false
+[filter "annex"]
+	smudge = git-annex smudge %f
+	clean = git-annex smudge --clean %f
+[remote "WD-1TB-USB"]
+	url = /Volumes/WD-1TB-USB/repos/film
+	fetch = +refs/heads/*:refs/remotes/WD-1TB-USB/*
+	annex-uuid = UUID
+[remote "quorra"]
+	url = 192.168.70.10:/home/jasonb/repos/film
+	fetch = +refs/heads/*:refs/remotes/quorra/*
+	annex-uuid = UUID
+	#annex-rsync-transport = ssh -c blowfish
+	annex-ssh-options = -c aes128-gcm@openssh.com
+```
diff --git a/doc/forum/Added_file_to_annex_but_it_doesn__39__t_show_up_in_here/comment_1_6757bfdc2876b5b763c338ad414e74dc._comment b/doc/forum/Added_file_to_annex_but_it_doesn__39__t_show_up_in_here/comment_1_6757bfdc2876b5b763c338ad414e74dc._comment
new file mode 100644
index 0000000000..5ddcce8131
--- /dev/null
+++ b/doc/forum/Added_file_to_annex_but_it_doesn__39__t_show_up_in_here/comment_1_6757bfdc2876b5b763c338ad414e74dc._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="jasonb@ab4484d9961a46440958fa1a528e0fc435599057"
+ nickname="jasonb"
+ avatar="http://cdn.libravatar.org/avatar/c7330f4da122c671b935fc1d58bb02b1"
+ subject="Unusual behavior"
+ date="2019-04-18T01:36:04Z"
+ content="""
+So I ran:
+
+```
+git annex --numcopies=0 dropunused 1-2
+dropunused 1 ok
+dropunused 2 ok
+(recording state in git...)
+```
+
+Which is fine, then:
+
+```
+cat Harry\ Brown\ \(2009\)\ 1080p.mp4
+/annex/objects/WORM-s2046008512-m1537755616--Harry,32Brown,32,402009,41,321080p.mp4
+```
+
+And that is strange.
+
+```
+$ rm Harry\ Brown\ \(2009\)\ 1080p.mp4
+override r--r--r--  jasonb/staff for Harry Brown (2009) 1080p.mp4? y
+$ cp -a ~/Downloads/Harry\ Brown\ \(2009\)\ 1080p.mp4 .
+$ git annex add Harry\ Brown\ \(2009\)\ 1080p.mp4
+add Harry Brown (2009) 1080p.mp4 ok
+(recording state in git...)
+$ ls -l Harry\ Brown\ \(2009\)\ 1080p.mp4
+lrwxr-xr-x  1 jasonb  staff  162 Apr 17 21:24 Harry Brown (2009) 1080p.mp4 -> .git/annex/objects/XV/Wx/WORM-s2046008512-m1555550686--Harry,32Brown,32,402009,41,321080p.mp4/WORM-s2046008512-m1555550686--Harry,32Brown,32,402009,41,321080p.mp4
+```
+
+And that's what I expected. I'm lost as to what happened.
+"""]]
diff --git a/doc/forum/Adding_a_URL_from_wayback_machine.mdwn b/doc/forum/Adding_a_URL_from_wayback_machine.mdwn
new file mode 100644
index 0000000000..d019e255b6
--- /dev/null
+++ b/doc/forum/Adding_a_URL_from_wayback_machine.mdwn
@@ -0,0 +1,64 @@
+Is there a nice way to add a URL from the Wayback machine?
+I don't want to add HTML documents but rather PDFs etc.
+The problem is that web.archive.org doesn't send a Content-Length header:
+
+    $ curl -I http://web.archive.org/web/20171117120847/https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg
+    HTTP/1.1 200 OK
+    Server: Tengine/2.1.0
+    Date: Fri, 17 Nov 2017 12:09:35 GMT
+    Content-Type: audio/ogg
+    Connection: keep-alive
+    X-Archive-Orig-content-length: 29784324
+    X-Archive-Orig-accept-ranges: bytes
+    X-Archive-Orig-server: Apache/2.4.29 (Debian)
+    X-Archive-Orig-last-modified: Wed, 11 Feb 2015 01:31:47 GMT
+    X-Archive-Orig-connection: close
+    X-Archive-Orig-etag: "1c67904-50ec5f783257c"
+    X-Archive-Orig-date: Fri, 17 Nov 2017 12:08:49 GMT
+    Cache-Control: max-age=1800
+    X-Archive-Guessed-Content-Type: audio/ogg
+    Memento-Datetime: Fri, 17 Nov 2017 12:08:47 GMT
+    Link: <https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg>; rel="original", <http://web.archive.org/web/timemap/link/https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg>; rel="timemap"; type="application/link-format", <http://web.archive.org/web/https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg>; rel="timegate", <http://web.archive.org/web/20140426045733/https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg>; rel="first memento"; datetime="Sat, 26 Apr 2014 04:57:33 GMT", <http://web.archive.org/web/20170822174608/https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg>; rel="prev memento"; datetime="Tue, 22 Aug 2017 17:46:08 GMT", <http://web.archive.org/web/20171117120847/https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg>; rel="memento"; datetime="Fri, 17 Nov 2017 12:08:47 GMT", <http://web.archive.org/web/20171117120847/https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg>; rel="last memento"; datetime="Fri, 17 Nov 2017 12:08:47 GMT"
+    Content-Security-Policy: default-src 'self' 'unsafe-eval' 'unsafe-inline' data: archive.org web.archive.org analytics.archive.org
+    X-App-Server: wwwb-app39
+    X-ts: ----
+    X-Archive-Playback: 0
+    X-location: All
+    X-Page-Cache: MISS
+
+Therefore, I'd have to pass the `--relaxed` flag when calling `addurl`.
+Is there maybe a way to tell git-annex to download the file before checking its size?
+Or is there a way to use the Wayback machine via the S3 special remote?
+
+Eventually, I'd like to have a script that automatically saves all web content in my repo
+into the Wayback machine and adds the new URLs for redundancy.
+
+This is what I've got so far:
+
+    #! /usr/bin/env python3
+    
+    from subprocess import check_output, Popen, PIPE
+    import json
+    from urllib import request
+    from sys import stdout
+    
+    output = check_output(['git-annex', 'find', '--in', 'web', '--json'])
+    files = [json.loads(line)['file'] for line in output.split(b'\n')[:-1]]
+    p = Popen(['git-annex', 'whereis', '--batch', '--json'], stdin=PIPE, stdout=PIPE)
+    p.stdin.writelines(str.encode(f + '\n') for f in files)
+    out, err = p.communicate()
+    urls = []
+    for line in out.split(b'\n')[:-1]:
+        for loc in json.loads(line)['untrusted']:
+            if loc['uuid'] == '00000000-0000-0000-0000-000000000001':
+                url = loc['urls'][0]
+                import urllib.request
+                print('GET https://web.archive.org/save/' + url)
+                r = request.urlopen('https://web.archive.org/save/' + url)
+                assert(r.getcode() == 200)
+                urls.append(r.geturl())
+                break
+    assert(len(files) == len(urls))
+    p = Popen(['git-annex', 'addurl', '--batch', '--with-files', '--relaxed'], stdin=PIPE, stdout=stdout)
+    p.stdin.writelines(str.encode(f + ' ' + u) for f, u in zip(urls, files))
+    p.communicate()
diff --git a/doc/forum/Adding_a_URL_from_wayback_machine/comment_1_bc78c24becbf758da7873cdf01e2adc5._comment b/doc/forum/Adding_a_URL_from_wayback_machine/comment_1_bc78c24becbf758da7873cdf01e2adc5._comment
new file mode 100644
index 0000000000..4660977462
--- /dev/null
+++ b/doc/forum/Adding_a_URL_from_wayback_machine/comment_1_bc78c24becbf758da7873cdf01e2adc5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-12-05T17:37:21Z"
+ content="""
+Lack of a Content-Length header does not prevent `git annex addurl` from
+working as far as I can see. Perhaps you should show what the problem
+you're experiencing looks like.
+"""]]
diff --git a/doc/forum/Adding_a_URL_from_wayback_machine/comment_2_6df0501b103a7cfcd1eaa4120f7fa818._comment b/doc/forum/Adding_a_URL_from_wayback_machine/comment_2_6df0501b103a7cfcd1eaa4120f7fa818._comment
new file mode 100644
index 0000000000..c438596bf2
--- /dev/null
+++ b/doc/forum/Adding_a_URL_from_wayback_machine/comment_2_6df0501b103a7cfcd1eaa4120f7fa818._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="robert.schuetz@7942237bf71a2ae4f5d3cb047d167612b8c9e311"
+ nickname="robert.schuetz"
+ avatar="http://cdn.libravatar.org/avatar/89879460a9e84b9c736d982d9489d3d9"
+ subject="comment 2"
+ date="2017-12-09T11:50:09Z"
+ content="""
+I'm adding a file and later want to add a URL, that doesn't give a Content-Length header, to the file.
+
+It is essantially the following:
+
+    mkdir test
+    cd test
+    git init
+    git annex init
+    wget http://web.archive.org/web/20171117120847/https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg
+    git annex add
+    git annex addurl \"http://web.archive.org/web/20171117120847/https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg\" --file git-annex_views_demo.ogg
+
+and the last command gives me the result
+
+    addurl git-annex_views_demo.ogg 
+      while adding a new url to an already annexed file, url does not have expected file size (use --relaxed to bypass this check) http://web.archive.org/web/20171117120847/https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg
+    failed
+    git-annex: addurl: 1 failed
+"""]]
diff --git a/doc/forum/Adding_a_URL_from_wayback_machine/comment_3_aefbb393c11ab233d145311409d405c7._comment b/doc/forum/Adding_a_URL_from_wayback_machine/comment_3_aefbb393c11ab233d145311409d405c7._comment
new file mode 100644
index 0000000000..1711ccb911
--- /dev/null
+++ b/doc/forum/Adding_a_URL_from_wayback_machine/comment_3_aefbb393c11ab233d145311409d405c7._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-12-11T17:56:53Z"
+ content="""
+Ah, gotcha.
+
+When adding an url to an annexed file, git-annex doesn't download the
+content again, because that could be a lot of work, instead it checks
+if the size is the same, which is the same check that git-annex always uses
+to see if the web still seems to have the content of a file.
+
+It doesn't feel safe to relax the size check when the web server doesn't
+send a Content-Length, because then there's no indication at all 
+that this url really has the same content as the file. It *might* make
+sense for git-annex to download all the content again in that case, and
+check if it's the expected content and only then add it. However, that
+could be a whole lot of unwanted work to do.
+
+If the user is sure that the url has the same content, it does make sense
+for them to add --relaxed. So, perhaps what's needed is a --strict
+for the users who are not sure and want to force a full download to check.
+
+Here's how to check it yourself, without any changes to git-annex.
+
+	wget -O tmp.git-annex_views_demo.ogg http://web.archive.org/web/20171117120847/https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg
+	if [ "$(git annex calckey tmp.git-annex_views_demo.ogg)" == "$(git annex find --format '${key}' git-annex_views_demo.ogg)" ]; then
+		git annex addurl \"http://web.archive.org/web/20171117120847/https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg\" --file git-annex_views_demo.ogg --relaxed
+	fi
+	rm tmp.git-annex_views_demo.ogg
+"""]]
diff --git a/doc/forum/Adding_a_mounted_network.mdwn b/doc/forum/Adding_a_mounted_network.mdwn
new file mode 100644
index 0000000000..5f62e79a2b
--- /dev/null
+++ b/doc/forum/Adding_a_mounted_network.mdwn
@@ -0,0 +1 @@
+I would like to add (bare) repositories on network directories that are locally mounted. "Add more repositories" gives me many choices, which apparently does not include this specifically. It does have "Removable drive" which sees the CIFS directory (perhaps because it's under /media?) but not the AFS directory, and there doesn't seem to be a way to enter a path where it's not inclined to look ("rescan for removable drives" still misses /afs). I am comfortable using shell commands, but I don't know what commands to use.
diff --git a/doc/forum/Adding_a_mounted_network/comment_1_9b4bab6177856569adfec26ada6b01cd._comment b/doc/forum/Adding_a_mounted_network/comment_1_9b4bab6177856569adfec26ada6b01cd._comment
new file mode 100644
index 0000000000..cda6d5fafc
--- /dev/null
+++ b/doc/forum/Adding_a_mounted_network/comment_1_9b4bab6177856569adfec26ada6b01cd._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2015-04-09T13:17:41Z"
+ content="""
+It's just a git remote..
+
+    git remote add somerepo /path/to/repo
+    git annex sync
+
+should be all you need.
+"""]]
diff --git a/doc/forum/Adding_a_mounted_network/comment_2_ae3d4ac918ef002ead859ed0c962ae32._comment b/doc/forum/Adding_a_mounted_network/comment_2_ae3d4ac918ef002ead859ed0c962ae32._comment
new file mode 100644
index 0000000000..eaf0665581
--- /dev/null
+++ b/doc/forum/Adding_a_mounted_network/comment_2_ae3d4ac918ef002ead859ed0c962ae32._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-04-09T18:33:47Z"
+ content="""
+If you want to do with using the webapp, go to the "Repository"
+menu in the upper-left, and select "Add another local repository."
+
+You can then enter the path to your repository, whevever it is, 
+and click on "combine the repositories"
+
+But, like Justin said, this just sets up a git remote, so doing it at
+the command line will work just as well.
+"""]]
diff --git a/doc/forum/Adding_a_mounted_network/comment_3_559cfec9210f8c86de6ee13de0ec2175._comment b/doc/forum/Adding_a_mounted_network/comment_3_559cfec9210f8c86de6ee13de0ec2175._comment
new file mode 100644
index 0000000000..b45f741760
--- /dev/null
+++ b/doc/forum/Adding_a_mounted_network/comment_3_559cfec9210f8c86de6ee13de0ec2175._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://lhealy.livejournal.com/"
+ subject="comment 3"
+ date="2015-04-10T15:35:16Z"
+ content="""
+Thanks for both these answers. For the first, one does the repository have to be made first? I.e., do a `git init --bare` first? I discovered the second approach before reading the comment and it worked, but it did not make a bare repository as happens with the \"removable drive\" option in the assistant.
+"""]]
diff --git a/doc/forum/Adding_existing_S3_bucket_to_sync_with.mdwn b/doc/forum/Adding_existing_S3_bucket_to_sync_with.mdwn
new file mode 100644
index 0000000000..af138c1015
--- /dev/null
+++ b/doc/forum/Adding_existing_S3_bucket_to_sync_with.mdwn
@@ -0,0 +1,16 @@
+Hello,
+
+I am just starting to learn git-annex so forgive me if this is a naive question.
+
+I have the following repositories:
+
+1. Home (laptop)
+2. Work (mac mini)
+3. S3 bucket
+4. USB drive, full backup, attached to Home laptop.
+
+I want to sync files between Home and Work via the S3 bucket.  It is not clear to me how to accomplish this through the git-annex assistant.  Is this possible? Are there instructions online?
+
+Thanks in advance!
+
+Scott
diff --git a/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_1_30b9a70d367dd5b8781e9a86e42d4c3e._comment b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_1_30b9a70d367dd5b8781e9a86e42d4c3e._comment
new file mode 100644
index 0000000000..d68af19f95
--- /dev/null
+++ b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_1_30b9a70d367dd5b8781e9a86e42d4c3e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://marco.paga.myopenid.com/"
+ ip="2001:4dd0:ff00:917b:d575:780:2c27:d982"
+ subject="Yes, it is possible"
+ date="2013-08-19T17:59:56Z"
+ content="""
+You can sync both repos. The simplest way is to have both clients signed on to jabber. This way the clients exchange information when the two are online.
+
+Additionally you need to have a cloud special remote available on both ends. The cloud repository is needed to push and retrieve data for the clients. You need to configure the cloud as a transfer reposity. The clients as - what else - client. The USB Drive can be used as a backup repository on one or both ends and perhaps even for syncing very large files around.
+"""]]
diff --git a/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_2_a8525c1a7e5f89c30c9503fe8bfed02e._comment b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_2_a8525c1a7e5f89c30c9503fe8bfed02e._comment
new file mode 100644
index 0000000000..9e1d27af4e
--- /dev/null
+++ b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_2_a8525c1a7e5f89c30c9503fe8bfed02e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://marco.paga.myopenid.com/"
+ ip="2001:4dd0:ff00:917b:d575:780:2c27:d982"
+ subject="I forgot to mention"
+ date="2013-08-19T18:01:47Z"
+ content="""
+You might want to have a look at this: https://git-annex.branchable.com/assistant/remote_sharing_walkthrough/
+"""]]
diff --git a/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_3_c3878989f74e740c0ed42f440750f3a4._comment b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_3_c3878989f74e740c0ed42f440750f3a4._comment
new file mode 100644
index 0000000000..9925f8274d
--- /dev/null
+++ b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_3_c3878989f74e740c0ed42f440750f3a4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkjQhXk8KAh9yD0p1R6QzT-Sw7FtHE3d54"
+ nickname="Scott"
+ subject="comment 3"
+ date="2013-08-19T18:03:41Z"
+ content="""
+Great thanks!  I'll try it out tonight and report back.
+"""]]
diff --git a/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_4_c06cc86496f9d4c0c42a8c89aa5a7b35._comment b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_4_c06cc86496f9d4c0c42a8c89aa5a7b35._comment
new file mode 100644
index 0000000000..5e1a397135
--- /dev/null
+++ b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_4_c06cc86496f9d4c0c42a8c89aa5a7b35._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkjQhXk8KAh9yD0p1R6QzT-Sw7FtHE3d54"
+ nickname="Scott"
+ subject="comment 4"
+ date="2013-08-20T16:18:24Z"
+ content="""
+When I try to setup my Jabber client, using my gmail address, the assistant crashes.  I thought this might be due to having two-factor authentication enabled so I generated an application specific password and tried that.  The assistant still crashes.  The log is huge, I am not sure what would be relevant to show here.
+"""]]
diff --git a/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_5_0a1c2dd0929511ff824be8de2c8d85eb._comment b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_5_0a1c2dd0929511ff824be8de2c8d85eb._comment
new file mode 100644
index 0000000000..2c4927b195
--- /dev/null
+++ b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_5_0a1c2dd0929511ff824be8de2c8d85eb._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://marco.paga.myopenid.com/"
+ ip="2001:4dd0:ff00:917b:f87b:5579:3820:5db"
+ subject="Please post the log"
+ date="2013-08-21T15:49:00Z"
+ content="""
+I don't know what is going wrong. It is not a bad idea to post the log information.
+
+"""]]
diff --git a/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_6_1444c2f89885f028f20a4d3ce225a403._comment b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_6_1444c2f89885f028f20a4d3ce225a403._comment
new file mode 100644
index 0000000000..21c3d80e35
--- /dev/null
+++ b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_6_1444c2f89885f028f20a4d3ce225a403._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkjQhXk8KAh9yD0p1R6QzT-Sw7FtHE3d54"
+ nickname="Scott"
+ subject="comment 6"
+ date="2013-08-21T20:05:31Z"
+ content="""
+I tried a different approach and attempted to setup s3 at the command line.  This is what I did:
+
+zombie:annex scott$ export AWS_ACCESS_KEY_ID=\"my key\"
+zombie:annex scott$ export AWS_SECRET_ACCESS_KEY=\"my secret key\"
+zombie:annex scott$ git annex initremote S3 type=S3 encryption=shared
+[2013-08-21 13:03:42 PDT] read: git [\"--git-dir=/Network/Servers/filer004/vol/office_homes/scott/annex/.git\",\"--work-tree=/Network/Servers/filer004/vol/office_homes/scott/annex\",\"show-ref\",\"git-annex\"]
+[2013-08-21 13:03:42 PDT] read: git [\"--git-dir=/Network/Servers/filer004/vol/office_homes/scott/annex/.git\",\"--work-tree=/Network/Servers/filer004/vol/office_homes/scott/annex\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2013-08-21 13:03:42 PDT] read: git [\"--git-dir=/Network/Servers/filer004/vol/office_homes/scott/annex/.git\",\"--work-tree=/Network/Servers/filer004/vol/office_homes/scott/annex\",\"log\",\"refs/heads/git-annex..da801570f9ed8d28e5a0cea6cc51f1a2003317d6\",\"--oneline\",\"-n1\"]
+[2013-08-21 13:03:42 PDT] read: git [\"--git-dir=/Network/Servers/filer004/vol/office_homes/scott/annex/.git\",\"--work-tree=/Network/Servers/filer004/vol/office_homes/scott/annex\",\"log\",\"refs/heads/git-annex..8015f3fed32792b558d16008d20816fab0fc50c2\",\"--oneline\",\"-n1\"]
+[2013-08-21 13:03:42 PDT] chat: git [\"--git-dir=/Network/Servers/filer004/vol/office_homes/scott/annex/.git\",\"--work-tree=/Network/Servers/filer004/vol/office_homes/scott/annex\",\"cat-file\",\"--batch\"]
+[2013-08-21 13:03:42 PDT] read: git [\"config\",\"--null\",\"--list\"]
+initremote S3 (encryption setup) [2013-08-21 13:03:42 PDT] read: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--gen-random\",\"--armor\",\"2\",\"512\"]
+(shared cipher) (checking bucket...)
+git-annex: connect: does not exist (Connection refused)
+failed
+git-annex: initremote: 1 failed
+"""]]
diff --git a/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_7_1c30944010d541096baff18198a5560d._comment b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_7_1c30944010d541096baff18198a5560d._comment
new file mode 100644
index 0000000000..7e05bf59af
--- /dev/null
+++ b/doc/forum/Adding_existing_S3_bucket_to_sync_with/comment_7_1c30944010d541096baff18198a5560d._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkjQhXk8KAh9yD0p1R6QzT-Sw7FtHE3d54"
+ nickname="Scott"
+ subject="comment 7"
+ date="2013-08-21T20:07:58Z"
+ content="""
+Sorry that didnt format properly
+
+    zombie:annex scott$ export AWS_ACCESS_KEY_ID=\"key\"
+    zombie:annex scott$ export AWS_SECRET_ACCESS_KEY=\"secret\"
+    zombie:annex scott$ git annex initremote S3 type=S3 encryption=shared
+    [2013-08-21 13:03:42 PDT] read: git [\"--git-dir=/Network/Servers/filer004/vol/office_homes/scott/annex/.git\",\"--work-tree=/Network/Servers/filer004/vol/office_homes/scott/annex\",\"show-ref\",\"git-annex\"]
+    [2013-08-21 13:03:42 PDT] read: git [\"--git-dir=/Network/Servers/filer004/vol/office_homes/scott/annex/.git\",\"--work-tree=/Network/Servers/filer004/vol/office_homes/scott/annex\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2013-08-21 13:03:42 PDT] read: git [\"--git-dir=/Network/Servers/filer004/vol/office_homes/scott/annex/.git\",\"--work-tree=/Network/Servers/filer004/vol/office_homes/scott/annex\",\"log\",\"refs/heads/git-annex..da801570f9ed8d28e5a0cea6cc51f1a2003317d6\",\"--oneline\",\"-n1\"]  
+    [2013-08-21 13:03:42 PDT] read: git [\"--git-dir=/Network/Servers/filer004/vol/office_homes/scott/annex/.git\",\"--work-tree=/Network/Servers/filer004/vol/office_homes/scott/annex\",\"log\",\"refs/heads/git-annex..8015f3fed32792b558d16008d20816fab0fc50c2\",\"--oneline\",\"-n1\"  ]
+    [2013-08-21 13:03:42 PDT] chat: git [\"--git-dir=/Network/Servers/filer004/vol/office_homes/scott/annex/.git\",\"--work-tree=/Network/Servers/filer004/vol/office_homes/scott/annex\",\"cat-file\",\"--batch\"]
+    [2013-08-21 13:03:42 PDT] read: git [\"config\",\"--null\",\"--list\"]
+    initremote S3 (encryption setup) [2013-08-21 13:03:42 PDT] read: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--gen-random\",\"--armor\",\"2\",\"512\"]
+    (shared cipher) (checking bucket...)
+    git-annex: connect: does not exist (Connection refused)
+    failed
+    git-annex: initremote: 1 failed
+"""]]
diff --git a/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase.mdwn b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase.mdwn
new file mode 100644
index 0000000000..e13d3914f8
--- /dev/null
+++ b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase.mdwn
@@ -0,0 +1,69 @@
+I'm working in v7 mode with `annex.largefiles` configured.  When I add a lot of files (1000 in the example below), it takes 2 mins for the `(recording state in git...)` phase to complete.  The same happens if I just add files directly using `git add`.  Running `git add -v` will slowly list the files, so it's apparent that the adding of the files to git is what's causing the delay.  Is this slow `add` performance normal when adding files to git through git-annex?
+
+I didn't want to report this as a *bug* since I don't know if this is the result of a known process that git-annex is performing.  However, I find it curious how adding the same files to git-annex directly (without `annex.largefiles` configured) is very fast.
+
+If this is not a bug, perhaps the `(recording state in git...)` output could show the files being added instead to avoid the suspicion that the `add` command is hanging.
+
+I'm using git-annex version 7.20190912-gab739242a3 (with git version 2.23.0).
+
+Here is an example I've been using to investigate the different conditions and the output from a run of the script:
+
+```
+#!/usr/bin/env bash
+
+set -eu
+
+dir=$(mktemp -d)
+cd ${dir}
+
+cleanup() {
+    chmod 777 -R ${dir}
+    rm -rf ${dir}
+}
+
+trap cleanup EXIT
+
+# create 1000 files
+for idx in {1..1000}; do
+    echo ${RANDOM} > file${idx}
+done
+
+git init
+set -x
+
+time git add . > /dev/null
+git rm --cached -r . > /dev/null
+
+git annex init
+
+time git annex add -c annex.largefiles="largerthan=1M" .
+git rm --cached -r . > /dev/null
+
+time git add .
+```
+
+
+```
+Initialized empty Git repository in /tmp/tmp.BdmH199gbk/.git/
++ git add .
+real    0m0.049s
+user    0m0.010s
+sys 0m0.039s
++ git rm --cached -r .
++ git annex init
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
++ git annex add -c annex.largefiles=largerthan=1M .
+real    2m4.617s
+user    1m40.865s
+sys     0m18.335s
++ git rm --cached -r .
++ git add .
+real    2m13.367s
+user    1m48.507s
+sys     0m21.230s
++ cleanup
++ chmod 777 -R /tmp/tmp.BdmH199gbk
++ rm -rf /tmp/tmp.BdmH199gbk
+```
diff --git a/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_1_67d8488c421da24702fea4c37afe74c3._comment b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_1_67d8488c421da24702fea4c37afe74c3._comment
new file mode 100644
index 0000000000..7d32730ef2
--- /dev/null
+++ b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_1_67d8488c421da24702fea4c37afe74c3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-09-16T17:19:38Z"
+ content="""
+This is because `git add` has to run git-annex once
+per file to smudge it. 
+See [[todo/git_smudge_clean_interface_suboptiomal]].
+"""]]
diff --git a/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_2_f9fb8b2ad05a17e8451d434c783fc7d7._comment b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_2_f9fb8b2ad05a17e8451d434c783fc7d7._comment
new file mode 100644
index 0000000000..a435f312da
--- /dev/null
+++ b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_2_f9fb8b2ad05a17e8451d434c783fc7d7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="achilleas"
+ avatar="http://cdn.libravatar.org/avatar/ed6c67c4d8e6c6850930e16eaf85a771"
+ subject="comment 2"
+ date="2019-09-16T20:59:11Z"
+ content="""
+Oh, the old smudge filter.  Should have known it has something to do with that.  Thanks for getting back so quickly.
+"""]]
diff --git a/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_3_71bbf490cfa2cbfab322aab865d93261._comment b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_3_71bbf490cfa2cbfab322aab865d93261._comment
new file mode 100644
index 0000000000..4151279224
--- /dev/null
+++ b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_3_71bbf490cfa2cbfab322aab865d93261._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="achilleas.k@14be77d42a1252fab5ec9dbf4e5ea03c5833e8c8"
+ nickname="achilleas.k"
+ avatar="http://cdn.libravatar.org/avatar/ed6c67c4d8e6c6850930e16eaf85a771"
+ subject="comment 3"
+ date="2019-09-24T15:04:49Z"
+ content="""
+Reading up more on the issue (the page you linked and some other pages regarding the way smudge/clean filters affect performance), I'm still not sure I understand the exact issue for this case.  When adding a lot of files to the annex directly, there's no issue.  Am I understanding the smudge/clean filter performance issues incorrectly?  When the `largefiles` option is used and files are added to git (instead of annex), what does the smudge filter do to the file or its contents that requires extra time?  I guess I'm not clear on what exactly happens when a file is excluded from a `largefiles` filter that takes longer than adding a file to git-annex.  I would have expected the opposite to be true.
+"""]]
diff --git a/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_4_66dbcc3600c1df2df03896935dfce9c0._comment b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_4_66dbcc3600c1df2df03896935dfce9c0._comment
new file mode 100644
index 0000000000..691667f1ec
--- /dev/null
+++ b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_4_66dbcc3600c1df2df03896935dfce9c0._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="non-annexed files still get passed through the clean/smudge filter"
+ date="2019-09-24T17:26:09Z"
+ content="""
+\"what exactly happens when a file is excluded from a largefiles filter that takes longer\" -- looking in `.git/info/attributes`:
+[[!format sh \"\"\"
+* filter=annex
+.* !filter
+
+\"\"\"]]
+
+i.e. _all_ files except dotfiles get passed through the clean/smudge filter defined in `.git/config`:
+[[!format sh \"\"\"
+[filter \"annex\"]
+        smudge = git-annex smudge -- %f
+        clean = git-annex smudge --clean -- %f
+\"\"\"]]
+
+It would be better if `git-annex` would only add unlocked files to .gitattributes (the one at the repo root), and remove them when they're locked.  This would also make it easier to find the unlocked files.
+"""]]
diff --git a/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_5_665bdcd79b486f8d2604eb6de5c10b2b._comment b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_5_665bdcd79b486f8d2604eb6de5c10b2b._comment
new file mode 100644
index 0000000000..abf9fd299d
--- /dev/null
+++ b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_5_665bdcd79b486f8d2604eb6de5c10b2b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="achilleas.k@14be77d42a1252fab5ec9dbf4e5ea03c5833e8c8"
+ nickname="achilleas.k"
+ avatar="http://cdn.libravatar.org/avatar/ed6c67c4d8e6c6850930e16eaf85a771"
+ subject="comment 5"
+ date="2019-09-24T17:29:28Z"
+ content="""
+> i.e. all files except dotfiles get passed through the clean/smudge filter defined in .git/config:
+
+Right, that's understandable.  Why is it faster to clean/smudge a file going into annex than it is going into git though?
+"""]]
diff --git a/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_6_cf89b44d67752edabfbf577d1212e7ad._comment b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_6_cf89b44d67752edabfbf577d1212e7ad._comment
new file mode 100644
index 0000000000..ca1f3cebe2
--- /dev/null
+++ b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_6_cf89b44d67752edabfbf577d1212e7ad._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="comment 6"
+ date="2021-01-02T23:49:14Z"
+ content="""
+I'm having a very similar issue. Adding files is quite slow, and it hangs for several minutes in `(recording state in git...)` now (that started after adding quite a few files already), and the time seems to increase (I fear that it will soon be hours, not minutes, making it basically unusable...).
+
+I have not really configured anything (i.e. it should use all the defaults). I just did `git init` and `git annex init`, and then started to import files using `git annex import`. That's all.
+
+I don't really know about this smudge thing. Is that enabled by default? If that is causing problems, should I maybe disable it?
+
+"""]]
diff --git a/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_7_a4e2f0e65a9dc92fc4dd85183e8f8090._comment b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_7_a4e2f0e65a9dc92fc4dd85183e8f8090._comment
new file mode 100644
index 0000000000..367202c85a
--- /dev/null
+++ b/doc/forum/Adding_files_to_git__58___Very_long___34__recording_state_in_git__34___phase/comment_7_a4e2f0e65a9dc92fc4dd85183e8f8090._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-01-04T16:13:36Z"
+ content="""
+This will avoid the overhead of the smudge filter, when all the files
+you're adding are ones you want stored in git, *not* in git-annex.
+
+	git-annex add --force-small
+
+I do think it would be possible for `git-annex add` to use the same method
+whenever it adds non-large files. But it might have unwanted other effects,
+since the way that manages to be fast is by avoding using `git add` and
+having git-annex hash the file and add it to git itself. Opened
+[[todo/speed_up_git_annex_add_of_small_files]] to consider this.
+
+The only way to speed up `git add` is to disable the smudge filter, but then
+all files you `git add` will be stored in git, not in git-annex. And
+disabling the smudge filter also will prevent using unlocked annexed files.
+(See [[todo/git_smudge_clean_interface_suboptiomal]] for background.)
+"""]]
diff --git a/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite.mdwn b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite.mdwn
new file mode 100644
index 0000000000..589877860a
--- /dev/null
+++ b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite.mdwn
@@ -0,0 +1,10 @@
+I've been trying to get all image files added to git annex with a wildcard, with no luck. If I use 'git annex add image.jpg', the file gets added and I can commit it. Also using 'git annex add .' works for adding all files. 
+
+Comands I've tried-
+
+git annex add *.jpg     * This outputs to the screen that it's adding each .jpg it finds, but when I go to commit there are 0 files staged.
+
+git annex add . --include='*.jpg'   * This doesn't return any results.
+
+
+What command should I be using on a Mac to just add all files with a specific extension?
diff --git a/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_1_e0784676aab3388254cdc9e7dd2d97e7._comment b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_1_e0784676aab3388254cdc9e7dd2d97e7._comment
new file mode 100644
index 0000000000..d7efcec954
--- /dev/null
+++ b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_1_e0784676aab3388254cdc9e7dd2d97e7._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-27T18:21:11Z"
+ content="""
+There is no difference between "git annex add *" and "git annex
+add list of files". The wildcard is expanded by your shell, not by
+git-annex.
+
+Post a transcript of the problem.
+"""]]
diff --git a/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_2_d9a7d2669d1524cab71e7e3139631f2a._comment b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_2_d9a7d2669d1524cab71e7e3139631f2a._comment
new file mode 100644
index 0000000000..c6a410a657
--- /dev/null
+++ b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_2_d9a7d2669d1524cab71e7e3139631f2a._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmFe2gzaJequ06hlza8N1-lFqQfwtFnw68"
+ nickname="Michael"
+ subject="Works in a subfolder, but not from root of site"
+ date="2015-03-27T19:23:06Z"
+ content="""
+So if I drill all the way down into a folder containing images, the git annex add and git commit are successful. When trying to do the same from the root of the site, I get the add messages, but nothing appears to be staged when committing.
+
+
+Here is the output when trying to add all images recursively from the root of the site
+
+    macbook-pro:domain.com mhoskison$ git annex add *.jpg
+    add webroot/HTML/images/a-expanded.jpg ok
+    add webroot/HTML/images/about-logo1.jpg ok
+    <few hundred more lines add lines in-between>
+    add webroot/wp-content/uploads/2015/01/shutterstock_98870129-300x227.jpg ok
+    add webroot/wp-content/uploads/2015/01/shutterstock_98870129-940x198.jpg ok
+    add webroot/wp-content/uploads/2015/01/shutterstock_98870129.jpg ok
+    add webroot/wp-content/uploads/2015/01/smart-beauty-guide-logo.jpg ok
+    git-annex: *.jpg not found
+    macbook-pro:domain.com mhoskison$ git commit -m \"annex jpg wildcard\"
+    (recording state in git...)
+    On branch master
+    Your branch is up-to-date with 'origin/master'.
+    nothing added to commit but untracked files present
+    macbook-pro:domain.com mhoskison$ 
+
+
+Here is the successful output when I run the same commands from a subfolder
+
+    macbook-pro:04 mhoskison$ git annex add *.jpg
+    add april-150x150.jpg ok
+    add april.jpg ok
+    add images2-150x150.jpg ok
+    add images2.jpg ok
+    add p44242.tf_3B4F1611-AE82-BF8C-9E3190356674F495.Clear-and-Brilliant-logo-219x305_1_-150x150.jpg ok
+    add p44242.tf_3B4F1611-AE82-BF8C-9E3190356674F495.Clear-and-Brilliant-logo-219x305_1_-215x300.jpg ok
+    add p44242.tf_3B4F1611-AE82-BF8C-9E3190356674F495.Clear-and-Brilliant-logo-219x305_1_-219x198.jpg ok
+    add p44242.tf_3B4F1611-AE82-BF8C-9E3190356674F495.Clear-and-Brilliant-logo-219x305_1_.jpg ok
+    (recording state in git...)
+    macbook-pro:04 mhoskison$ git commit -m \"annex test from subfolder\"
+    [master 9859afd] annex test from subfolder
+     8 files changed, 8 insertions(+)
+     create mode 120000 webroot/wp-content/uploads/2014/04/april-150x150.jpg
+     create mode 120000 webroot/wp-content/uploads/2014/04/april.jpg
+     create mode 120000 webroot/wp-content/uploads/2014/04/images2-150x150.jpg
+     create mode 120000 webroot/wp-content/uploads/2014/04/images2.jpg
+     create mode 120000 webroot/wp-content/uploads/2014/04/p44242.tf_3B4F1611-AE82-BF8C-9E3190356674F495.Clear-and-Brilliant-logo-219x305_1_-
+    F8C-9E3190356674F495.Clear-and-Brilliant-logo-219x305_1_-150x150.jpg
+     create mode 120000 webroot/wp-content/uploads/2014/04/p44242.tf_3B4F1611-AE82-BF8C-9E3190356674F495.Clear-and-Brilliant-logo-219x305_1_-215x300.jpg
+     create mode 120000 webroot/wp-content/uploads/2014/04/p44242.tf_3B4F1611-AE82-BF8C-9E3190356674F495.Clear-and-Brilliant-logo-219x305_1_-219x198.jpg
+     create mode 120000 webroot/wp-content/uploads/2014/04/p44242.tf_3B4F1611-AE82-BF8C-9E3190356674F495.Clear-and-Brilliant-logo-219x305_1_.jpg
+
+
+"""]]
diff --git a/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_3_a0fdcd19954a38141b1dc2a51638ba30._comment b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_3_a0fdcd19954a38141b1dc2a51638ba30._comment
new file mode 100644
index 0000000000..6af065cb54
--- /dev/null
+++ b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_3_a0fdcd19954a38141b1dc2a51638ba30._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-03-27T19:25:26Z"
+ content="""
+The shell does not expand *.jpg to match files inside subdirectories.
+
+I suggest you read up on how shell wildcards work, and how to use them
+properly.
+
+There is a bit of a bug here, which is that the shell, when `*.jpg` does not
+expand to anything, passes the `"*.jpg"` parameter to git-annex un-expanded,
+which then passes it off to git ls-files, which then unexpectedly expands
+it to recursively match jpegs in subirectories. Only then does git-annex
+try to add a `*.jpg` file, and when it doesn't exist, it exits with an
+error, leaving the files it did add unstaged in git.
+
+To get out of that situation, just re-run git-annex add and actually list
+the files or directories to add, rather than a wildcard that won't expand
+to them..
+
+I'll see if I can fix the behavior here, it should just fail when given an
+un-expanded wildcard.
+"""]]
diff --git a/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_3_bc36d8f7b1d4d475018a236f71d06bb5._comment b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_3_bc36d8f7b1d4d475018a236f71d06bb5._comment
new file mode 100644
index 0000000000..d04ab1c774
--- /dev/null
+++ b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_3_bc36d8f7b1d4d475018a236f71d06bb5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmFe2gzaJequ06hlza8N1-lFqQfwtFnw68"
+ nickname="Michael"
+ subject="Symlinks added"
+ date="2015-03-27T19:33:07Z"
+ content="""
+Git-annex does replace all jpg files with symlinks when I run the add command from the root directory. It's just when I try to commit and sync that no changes are detected.
+"""]]
diff --git a/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_5_a02c3cd804c2f6fd80d8839cc5c81af4._comment b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_5_a02c3cd804c2f6fd80d8839cc5c81af4._comment
new file mode 100644
index 0000000000..14560b0231
--- /dev/null
+++ b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_5_a02c3cd804c2f6fd80d8839cc5c81af4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-03-27T20:42:21Z"
+ content="""
+I've fixed this; now you'll see:
+
+<pre>
+git annex add *.jpg
+git-annex: *.jpg not found
+</pre>
+"""]]
diff --git a/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_6_703ecd8e1dfc5b5b58655e27c9db838a._comment b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_6_703ecd8e1dfc5b5b58655e27c9db838a._comment
new file mode 100644
index 0000000000..30a6bd26fc
--- /dev/null
+++ b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_6_703ecd8e1dfc5b5b58655e27c9db838a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="clacke"
+ subject="regression"
+ date="2015-04-22T11:39:19Z"
+ content="""
+The fix is a regression compared to previous behavior.
+
+Being able to do `git annex add '*'.{JPG,jp{,e}g,AVI,avi,MOV,mov,3GP,3gp,mp4,tif,pdf,PDF,doc,pps,bmp,png,mp{,e}g,MP{,E}G,wav,WAV,nef,NEF,thm,THM,key.gz,ogg,OGG,ppt,GIF,gif,m4a}` in the root of my binary files archive to catch any newly copied files was a real feature. This worked until recently. I was just about to add a bug report stating the same problem as the OP for the OSX homebrew version, but I verified with the latest Linux standalone and there wildcards were completely turned off.
+"""]]
diff --git a/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_7_dbe40fef2ba65cc0f1c20f41f2daab4d._comment b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_7_dbe40fef2ba65cc0f1c20f41f2daab4d._comment
new file mode 100644
index 0000000000..47b00a5f06
--- /dev/null
+++ b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_7_dbe40fef2ba65cc0f1c20f41f2daab4d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="clacke"
+ subject="workaround"
+ date="2015-04-22T13:31:10Z"
+ content="""
+This is a workaround to the missing functionality, generating an `--include` expression:
+
+[[!format sh \"\"\"
+git annex add $(printf -- '--include=*.%s --or ' jp{,e}g avi mov 3gp mp4 tif pdf doc pps bmp png mp{,e}g wav nef thm key.gz ogg ppt gif) --include='*.m4a'
+\"\"\"]]
+"""]]
diff --git a/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_8_d8620ce7b3dbb81c0d3d0b09ded1deb0._comment b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_8_d8620ce7b3dbb81c0d3d0b09ded1deb0._comment
new file mode 100644
index 0000000000..ac95deb7fe
--- /dev/null
+++ b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_8_d8620ce7b3dbb81c0d3d0b09ded1deb0._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2015-04-24T17:26:01Z"
+ content="""
+The old behavior was accidental, and was never documented. When you use
+such undocumented behaviors, you're taking the risk of bugfixes breaking
+things. It's not fair to call that a "regression". If I had to worry about
+every bugfix breaking users who relied on the old buggy behavior in some
+way, I could just stop working now.
+
+It might be reasonable to add the "expand wildcards rather than letting the
+shell do it" feature, as an option. Of course, it would need to be tested
+for every git-annex command and problems like the one that caused this bug
+to be noticed in the first place dealt with, for every git-annex command.
+Using --include and --exclude, which already work seems pretty reasonable
+instead.
+"""]]
diff --git a/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_9_6a43f52449c4a38a986772ec9d65f9d5._comment b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_9_6a43f52449c4a38a986772ec9d65f9d5._comment
new file mode 100644
index 0000000000..210ece464f
--- /dev/null
+++ b/doc/forum/Adding_files_with_wildcard_on_Mac_Yosemite/comment_9_6a43f52449c4a38a986772ec9d65f9d5._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="clacke"
+ subject="not regression"
+ date="2015-04-27T12:13:12Z"
+ content="""
+Fair enough. And I have got over my initial frustration with the change in behavior. The workaround works.
+"""]]
diff --git a/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows.mdwn b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows.mdwn
new file mode 100644
index 0000000000..b9d118cd81
--- /dev/null
+++ b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows.mdwn
@@ -0,0 +1,31 @@
+Hi,
+I'm working on a game project (Unity3D) which I want to use git-annex for all those binary assets,
+
+but I still want to be able to commit normal code files in git,
+
+is there a way to do that?
+
+below is what I tried (but failed) to do.
+
+Thanks.
+
+Chris
+
+
+
+    C:\Users\Chris\Projects\testing>git annex init "testing"
+    init testing
+      Detected a filesystem without fifo support.
+    
+      Disabling ssh connection caching.
+    
+      Detected a crippled filesystem.
+    
+      Enabling direct mode.
+    ok
+    (recording state in git...)
+    
+    C:\Users\Chris\Projects\testing>echo test > testing.txt
+    
+    C:\Users\Chris\Projects\testing>git add testing.txt
+    fatal: This operation must be run in a work tree
diff --git a/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_1_e40e129fbdae305ad48f810c578fa69f._comment b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_1_e40e129fbdae305ad48f810c578fa69f._comment
new file mode 100644
index 0000000000..e2c1df6bef
--- /dev/null
+++ b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_1_e40e129fbdae305ad48f810c578fa69f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/5j.FKrMpxZS.luSB.5ahyosMU6RcaYq2#74c60"
+ nickname="Jarno"
+ subject="Proxy command"
+ date="2015-06-26T17:32:42Z"
+ content="""
+Have you tried the `git annex proxy --` command? Another way might be to just bypass the annex checks with `git -c core.bare=false`.
+Check <http://git-annex.branchable.com/direct_mode/> for details.
+"""]]
diff --git a/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_2_3f2556b0a0cd8b7523aed1bea1be8484._comment b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_2_3f2556b0a0cd8b7523aed1bea1be8484._comment
new file mode 100644
index 0000000000..96bc4f42b7
--- /dev/null
+++ b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_2_3f2556b0a0cd8b7523aed1bea1be8484._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="chris.forum.email@596f849a9d27c1f0bcdd653d1d2dc992f21ce603"
+ nickname="chris.forum.email"
+ subject="comment 2"
+ date="2015-06-27T11:23:05Z"
+ content="""
+if I use `git annex proxy` I can't see the changes:
+
+    C:\Users\Chris\Projects\testing>git annex proxy -- git status
+    On branch annex/direct/master
+    nothing to commit, working directory clean
+
+and I noticed that I'm on a branch called `annex/direct/master`, not the `master` I'd expect...
+
+if I use `git -c core.bare=false`, I get the normal output:
+
+    C:\Users\Chris\Projects\testing>git -c core.bare=false status
+    On branch annex/direct/master
+    Untracked files:
+      (use \"git add <file>...\" to include in what will be committed)
+    
+            test.txt
+    
+    nothing added to commit but untracked files present (use \"git add\" to track)
+
+but I'm still on a \"wrong\" branch? what is this `annex/direct/master` branch and am I supposed to commit and push this branch?
+
+Thanks, Chris
+"""]]
diff --git a/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_3_d50b99393009ba4adf2040f1d5d5078b._comment b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_3_d50b99393009ba4adf2040f1d5d5078b._comment
new file mode 100644
index 0000000000..eaef967b41
--- /dev/null
+++ b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_3_d50b99393009ba4adf2040f1d5d5078b._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-06T18:41:35Z"
+ content="""
+One nice way to do this is to use the annex.largefiles configuration
+setting. With a recent version of git-anne (5.20150409 or newer),
+adding a file that doesn't match annex.largefiles will cause it to be
+checked into git, rather than annexed.
+
+So, for example, `git -c annex.largefiles='exclude=*' annex add foo`
+will temporarily configure it to not annex any files, and add file foo to
+git. Or you can set annex.largefiles more permanantly to match specific
+file extensions.
+
+As to the annex/direct/master branch, this branch will get merged into the
+master branch on a push, so don't worry about it.
+
+(The `-c core.bare=false` approach will also work, just run regular git
+commands to add the file and commit. But, it's best to avoid this approach,
+because it's very easy to shoot yourself in the foot, by eg using
+`git commit -a` with it, which will check *all* file contents into git.)
+"""]]
diff --git a/doc/forum/Adding_public_key_to_hybrid_encrypted_repo_causes___34__remote_already_exists__34___error.mdwn b/doc/forum/Adding_public_key_to_hybrid_encrypted_repo_causes___34__remote_already_exists__34___error.mdwn
new file mode 100644
index 0000000000..8032584f1e
--- /dev/null
+++ b/doc/forum/Adding_public_key_to_hybrid_encrypted_repo_causes___34__remote_already_exists__34___error.mdwn
@@ -0,0 +1,5 @@
+Hello, I'm running git-annex version: 5.20151208-1build1.  I am trying to add a public key to my git annex repo but it tells me the repo already exists.  I worked around this by marking the repo as dead and re-enabling but I feel like this isn't the correct course of action.  Is there another way to avoid this error?
+
+    $ git annex enableremote annex.repo keyid+=920D7A56
+    enableremote annex.repo (encryption update) (hybrid cipher with gpg keys 97A273201BA73A76 A50E9160920D7A56) fatal: remote annex.repo already exists.
+    git-annex: git [Param "remote",Param "add",Param "annex.repo",Param "gcrypt::ssh://ben@annex/dataset/annex/share"] failed
diff --git a/doc/forum/Adding_public_key_to_hybrid_encrypted_repo_causes___34__remote_already_exists__34___error/comment_1_fe2f0e7a4688865faf21c2c0467852b7._comment b/doc/forum/Adding_public_key_to_hybrid_encrypted_repo_causes___34__remote_already_exists__34___error/comment_1_fe2f0e7a4688865faf21c2c0467852b7._comment
new file mode 100644
index 0000000000..be3a213144
--- /dev/null
+++ b/doc/forum/Adding_public_key_to_hybrid_encrypted_repo_causes___34__remote_already_exists__34___error/comment_1_fe2f0e7a4688865faf21c2c0467852b7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-03-02T19:04:08Z"
+ content="""
+Your version of git-annex is impressively out of date.
+When I try this with the current version, it works ok.
+"""]]
diff --git a/doc/forum/Adding_selected_big_binaries_recursively.mdwn b/doc/forum/Adding_selected_big_binaries_recursively.mdwn
new file mode 100644
index 0000000000..b870a39fac
--- /dev/null
+++ b/doc/forum/Adding_selected_big_binaries_recursively.mdwn
@@ -0,0 +1,12 @@
+I have a very large stack of files, with many large binaries.
+Unless I am told its a bad idea, I want to initialize a git annex archive with the big files 'git annex added' ( symlinked to hidden annex) and the rest of the files 'git added'
+
+I tried-
+git annex add "*.adi"
+find . -name "*.adi" | git annex add
+find . -name "*.adi" | xargs git annex add
+git annex add robots/\*.adi
+
+
+Whats a good ( correct) way to do only the *.adi files recursively?
+( its Friday PST here- will return Monday)
diff --git a/doc/forum/Adding_selected_big_binaries_recursively/comment_1_6ff6031a5a44caf17f36c3569cca5512._comment b/doc/forum/Adding_selected_big_binaries_recursively/comment_1_6ff6031a5a44caf17f36c3569cca5512._comment
new file mode 100644
index 0000000000..abfbbad5c2
--- /dev/null
+++ b/doc/forum/Adding_selected_big_binaries_recursively/comment_1_6ff6031a5a44caf17f36c3569cca5512._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-30T16:36:51Z"
+ content="""
+It's fine to annex the big files and store the small files in git in
+the usual way.
+
+The `find | xargs` approach should work.
+
+You can also use the [[git-annex-matching-options]], eg:
+
+	git annex add --include='*.adi'
+
+Or:
+
+	git annex add --largerthan=1mb
+
+
+You can also configure git-annex to know which files you consider
+large, so that `git annex add` will annex the large ones and add 
+the rest to git not the annex. See [[tips/largefiles]]
+"""]]
diff --git a/doc/forum/Adding_selected_big_binaries_recursively/comment_2_872bef6902ddb362b62d5e9ec1afe864._comment b/doc/forum/Adding_selected_big_binaries_recursively/comment_2_872bef6902ddb362b62d5e9ec1afe864._comment
new file mode 100644
index 0000000000..3950b19577
--- /dev/null
+++ b/doc/forum/Adding_selected_big_binaries_recursively/comment_2_872bef6902ddb362b62d5e9ec1afe864._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="JohnFisher"
+ subject="didn't work for me, perhaps I did the attributes wrong?"
+ date="2016-08-04T20:43:15Z"
+ content="""
+I created .gitattributes in the root of my repo:
+jfisher@buildos1:~/annex$ cat .gitattributes
+* annex.largefiles=(largerthan=100mb)
+jfisher@buildos1:~/annex$ git config -l
+user.email=jfisher@intouchhealth.com
+user.name=John Fisher
+core.repositoryformatversion=0
+core.filemode=true
+core.bare=false
+core.logallrefupdates=true
+annex.uuid=75d91aa9-f5fc-45b8-b62c-e6050ed7c3d5
+annex.version=5
+
+where I intend for all users of the repo to automatically add all files larger than 100Mb as annexed and add all other files as conventional git.
+
+I ran 
+git annex add
+and small text files were staged as links, as well as a large file
+
+Comment? Ideas?
+"""]]
diff --git a/doc/forum/Adding_selected_big_binaries_recursively/comment_3_4be5ca7a22db19a3152b54bee943f58c._comment b/doc/forum/Adding_selected_big_binaries_recursively/comment_3_4be5ca7a22db19a3152b54bee943f58c._comment
new file mode 100644
index 0000000000..c0f9a03e78
--- /dev/null
+++ b/doc/forum/Adding_selected_big_binaries_recursively/comment_3_4be5ca7a22db19a3152b54bee943f58c._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="JohnFisher"
+ subject="re-format for readability"
+ date="2016-08-04T20:48:55Z"
+ content="""
+    jfisher@buildos1:~/annex$ cat .gitattributes
+    * annex.largefiles=(largerthan=100mb)
+
+    jfisher@buildos1:~/annex$ git config -l
+    user.email=jfisher@intouchhealth.com
+    user.name=John Fisher
+    core.repositoryformatversion=0
+    core.filemode=true
+    core.bare=false
+    core.logallrefupdates=true
+    annex.uuid=75d91aa9-f5fc-45b8-b62c-e6050ed7c3d5
+annex.version=5
+
+"""]]
diff --git a/doc/forum/Adding_selected_big_binaries_recursively/comment_4_83b62738f79c434f5a2cacc9316e5d2b._comment b/doc/forum/Adding_selected_big_binaries_recursively/comment_4_83b62738f79c434f5a2cacc9316e5d2b._comment
new file mode 100644
index 0000000000..321d1c7c46
--- /dev/null
+++ b/doc/forum/Adding_selected_big_binaries_recursively/comment_4_83b62738f79c434f5a2cacc9316e5d2b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-10-05T21:01:38Z"
+ content="""
+That .gitattributes work when I try it here. Perhaps your version of
+git-annex is too old to support it. Configuring annex.largefiles via
+.gitattributes was first supported in version 6.20160211.
+"""]]
diff --git a/doc/forum/Adding_the_same_content_under_different_file_names.mdwn b/doc/forum/Adding_the_same_content_under_different_file_names.mdwn
new file mode 100644
index 0000000000..57c31199ed
--- /dev/null
+++ b/doc/forum/Adding_the_same_content_under_different_file_names.mdwn
@@ -0,0 +1,17 @@
+Working on the Baobáxia project, we have this interesting problem: If some content is added twice with different file names, it will appear in the git-annex repository as two symlinks pointing to the same file in the annex.
+
+So far so good.
+
+But this means that if I want to delete a file, I have two cases:
+
+* If this content was added only once, I need to drop the binary content with git annex drop and afterwards remove the symlink with git rm.
+* If this content exists under more than one file name, I need to remove the symlink with git rm only; I should *not* drop the content.
+
+So the question is: How do I know that, apart from searching through the whole repository? Is there a more efficient way? After going through the manual I can't find it, but I may have overlooked something.
+
+Best regards and TIA for any response
+Carsten Agger
+
+
+Note: This question references bug #191 in the Baobáxia project, https://github.com/RedeMocambos/baobaxia/issues/191
+
diff --git a/doc/forum/Adding_the_same_content_under_different_file_names/comment_1_7c659668f62577612eaf8f463383a185._comment b/doc/forum/Adding_the_same_content_under_different_file_names/comment_1_7c659668f62577612eaf8f463383a185._comment
new file mode 100644
index 0000000000..e71a6901ed
--- /dev/null
+++ b/doc/forum/Adding_the_same_content_under_different_file_names/comment_1_7c659668f62577612eaf8f463383a185._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="ghen1"
+ avatar="http://cdn.libravatar.org/avatar/efd0e92b6198291138f0cd7aedbf86b6"
+ subject="comment 1"
+ date="2017-01-07T15:41:36Z"
+ content="""
+You don't need to keep track of links. Just delete the links, then run:
+
+    git-annex unused
+
+This will find any content that isn't linked to. You can then run *git-annex dropunused* to free up space.
+
+See these man pages:<br/>
+<https://git-annex.branchable.com/git-annex-unused/><br/>
+<https://git-annex.branchable.com/git-annex-dropunused/>
+"""]]
diff --git a/doc/forum/Adding_the_same_content_under_different_file_names/comment_2_217052fe47822f73ffc765afd6386a7e._comment b/doc/forum/Adding_the_same_content_under_different_file_names/comment_2_217052fe47822f73ffc765afd6386a7e._comment
new file mode 100644
index 0000000000..c2fe6e94cf
--- /dev/null
+++ b/doc/forum/Adding_the_same_content_under_different_file_names/comment_2_217052fe47822f73ffc765afd6386a7e._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-01-31T16:35:15Z"
+ content="""
+This deduplication is generally considered a feature.
+(If you don't want it, you can eg use the WORM backend.)
+
+The `git annex unused` command can be used in this case. It looks through
+all files (in all branches) in the repo and finds content that no files
+are using, which can then be dropped.
+
+So the question is, if you've been using `git annex drop` before deleting a
+file, how do you know when you need to not do that, and 
+instead use `git annex unused` after deleting a file? Well, my suggestion
+is to just never get in the habit of `git annex drop` before deleting a
+file. Reserve using `git annex drop` for times when you are getting low on
+disk space and need to free some up by dropping content from local
+storage; don't try to manually manage which content is stored in the local
+repository as long as you have enough free disk space.
+"""]]
diff --git a/doc/forum/Advice_needed__58___git-annex_slows_down_my_macbook.mdwn b/doc/forum/Advice_needed__58___git-annex_slows_down_my_macbook.mdwn
new file mode 100644
index 0000000000..459e738382
--- /dev/null
+++ b/doc/forum/Advice_needed__58___git-annex_slows_down_my_macbook.mdwn
@@ -0,0 +1,21 @@
+I need some advice from more experienced users. 
+
+I've created four repositories on my macbook and paired them with repos on my ubuntu desktop. They are all created with the webapp so they might have some configurations that are not optimal for me.
+
+In fact, when I start my macbook it is unusual for more than an hour because git-annex is reading and writing to and from the disk in the background. 
+
+I don't change much in three of the four repos, only one repo contains my daily work. 
+
+What configuration would enhance my situation?
+
+The four repos are called:
+
+- movies
+- pictures
+- music
+- documents (many changes each day)
+
+I have also problems to switch to the documents repo in the webapp.
+
+TIA
+juh
diff --git a/doc/forum/Advice_needed__58___git-annex_slows_down_my_macbook/comment_1_af8ab0a47cd379fcb1445e50782ad086._comment b/doc/forum/Advice_needed__58___git-annex_slows_down_my_macbook/comment_1_af8ab0a47cd379fcb1445e50782ad086._comment
new file mode 100644
index 0000000000..a7cb701b6f
--- /dev/null
+++ b/doc/forum/Advice_needed__58___git-annex_slows_down_my_macbook/comment_1_af8ab0a47cd379fcb1445e50782ad086._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmTIL7ubr5opWM69Q5VtCxuxC2H0SSnzic"
+ nickname="Petr"
+ subject="Where are your repositories located?"
+ date="2014-01-14T08:58:31Z"
+ content="""
+First - Where are the repos actually located ~/Desktop or ~/annex/<repo>? Other?
+ 
+I can confirm, that like two weeks back I have had similar issue using git-annex-assistant with other synced repos on local LAN and at Box.com. The git-annex processes actually overloaded the CPU and I was forced to kill annex processes to get over.
+
+I also found myself that NFS mounted shares, linked by symlink to home directory, can slowdown mac finder app as well if NFS has slight delays in response.
+"""]]
diff --git a/doc/forum/Advice_needed__58___git-annex_slows_down_my_macbook/comment_2_a7202bcbdda36a3801833d2432db1965._comment b/doc/forum/Advice_needed__58___git-annex_slows_down_my_macbook/comment_2_a7202bcbdda36a3801833d2432db1965._comment
new file mode 100644
index 0000000000..478d2804f6
--- /dev/null
+++ b/doc/forum/Advice_needed__58___git-annex_slows_down_my_macbook/comment_2_a7202bcbdda36a3801833d2432db1965._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnX1msQxnLoSeu7q-i-c9BWghonsN7Qmns"
+ nickname="Jan Ulrich"
+ subject="comment 2"
+ date="2014-01-14T10:23:21Z"
+ content="""
+All repositories are located in my home folders:
+~/Pictures
+~/Movies
+~/Music
+~/Documents
+
+On my Ubuntu desktop machine and my macbook. They are connected in my local network via WLAN. 
+
+I use different git annex versions on these two machines. Maybe this causes problems.
+
+On Ubuntu I have 
+Version: 4.20130815
+Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP 
+
+On my macbook:
+Version: 5-20140106-gcb3351b
+
+juh
+"""]]
diff --git a/doc/forum/All_repos_on_same_filesystem.mdwn b/doc/forum/All_repos_on_same_filesystem.mdwn
new file mode 100644
index 0000000000..ee61ab7254
--- /dev/null
+++ b/doc/forum/All_repos_on_same_filesystem.mdwn
@@ -0,0 +1,14 @@
+Hi,
+ I am looking to find out the best way to use git annex, when all repos will live on the same filesystem, using a central repo.
+
+What I have so far is, after creating the main repo (mainrepo).
+
+Create clones via: git clone -shared mainrepo clonerepo
+
+Then  use "git annex add" and "git add". When it comes to making the data accessible to the mainrepo, it is a little unclear to me. 
+There is a lot of disjoint information regarding pull/pushing content and which directions use hardlinks vs copies etc. So I 
+was hoping that someone could fill me in on best practices.
+
+Thanks in advance!
+
+Pete
diff --git a/doc/forum/All_repos_on_same_filesystem/comment_1_a6666a89f62dc7e2d40e028782e5a25a._comment b/doc/forum/All_repos_on_same_filesystem/comment_1_a6666a89f62dc7e2d40e028782e5a25a._comment
new file mode 100644
index 0000000000..9074c4e16c
--- /dev/null
+++ b/doc/forum/All_repos_on_same_filesystem/comment_1_a6666a89f62dc7e2d40e028782e5a25a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-12-19T17:55:40Z"
+ content="""
+When you clone a repository with --shared, all git-annex commands
+that transfer data into or out of the repository will use hardlinks
+whenever possible.
+
+(But, before version 5.20150916, it didn't manage to use them all the
+time.)
+
+To get started, just use `git annex sync --content`
+"""]]
diff --git a/doc/forum/Alternative_modes_for_annex_repos.mdwn b/doc/forum/Alternative_modes_for_annex_repos.mdwn
new file mode 100644
index 0000000000..6d707d3b14
--- /dev/null
+++ b/doc/forum/Alternative_modes_for_annex_repos.mdwn
@@ -0,0 +1,35 @@
+I have given a lot of thought and experimentation to how git-annex could be used for large projects where there is a desire to distribute files to many users, but where only a minority of users would would actually push key changes.
+
+The first option would be to have an annexless mode, where a local repo either has no uuid, or where the git-annex branch is not stored in the default namespace.
+
+This is for cases where the client only cares that a file exists in the repo and that it has been verified.
+
+One possibility could be `git-annex-get --no-init`, which would not init a local repo, but would get and verify a file. The existence of a file would simply be if the file exists. Only upon making a change can a could be fully inited.
+
+Or even better, in a restricted environment where git-annex is not available, this case is simple enough that getting a key from a url could be done with a shellscript. The url could be extracted from the upstream git-annex branch without checking it out, and the symlinks used for verification. However, there is a chance that the upstream git-annex branch may not be stable (like if it is not propagated after a mirror), so one could "shrinkwrap" keys and store their remote url locations in a .gitattributes file or somewhere else in the same branch. If key changes are desired, it can be fairly effortlessly upgraded to an actual git-annex repo.
+
+A step up from a completely annexless repo would be a hypothetical local-only git-annex repo, where git-annex only uses a git-annex branch locally.
+
+There could be a `git-annex-init --local` option which creates a `local/git-annex` branch, for local tracking, but would not sync to the server by default.
+
+In this mode, the upstream git-annex branch would just be pulled and kept read-only, and `local/git-annex` would keep local differences. The `local/git-annex` would just use the union driver to combine upstream changes with local changes. Upgrading to a full git-annex repo would be as easy as creating a new `git-annex` branch at the same commit id as `local/git-annex`
+
+
+So, in summary, I have considered two modes:
+
+Fully annex-less mode, which is simple enough to be implemented completely without git-annex, useful for restricted environments. Optionally, can use a kind of shinkwrapping to externalize key URLs to a file in the branch to guarantee that the fetch location is stored.
+
+Secondly is local mode, where a `local/git-annex` branch is downstream from a git-annex branch, and in order to sync changes back to the server, the repo is upgraded.
+
+Both of these modes could easily be upgraded to a full git-annex repo on demand.
+
+I think this is useful when considering large scale usage.
+
+
+Most of this functionality is something that is probably best suited for a wrapper.
+
+In terms of any any potential core changes to git-annex, it may be as simple as having a GIT_ANNEX_BRANCH environment variable, analogous to the GIT_DIR variable for git.
+
+Has anyone given any thought to scenarios like this?
+
+I think there are cases where developers use git-lfs and something like this might be a better fit. And also with making git-annex repos more generally available and portable.
diff --git a/doc/forum/Alternative_to_Tor_for_remote_pairing__63__.mdwn b/doc/forum/Alternative_to_Tor_for_remote_pairing__63__.mdwn
new file mode 100644
index 0000000000..a473efb761
--- /dev/null
+++ b/doc/forum/Alternative_to_Tor_for_remote_pairing__63__.mdwn
@@ -0,0 +1,5 @@
+So i noticed the server provider i was using block tor traffic, and aren't really accepting tor to be installed/running on the host...
+That said, i know i could use ssh to share files between my local machine and the remote server, but i would have preferred something that wouldn't need ssh.
+
+My current isp also don't like tor so i only ever use it through vpn when i need to, so my question (as the post's title is) is there any working alternative to Tor/ssh for remote pairing with git-annex?
+I do have some accounts on some vpn provider, but i don't think/not sure how this could work.
diff --git a/doc/forum/Alternative_to_Tor_for_remote_pairing__63__/comment_1_39417a8bd5e6834041d759ea3666d894._comment b/doc/forum/Alternative_to_Tor_for_remote_pairing__63__/comment_1_39417a8bd5e6834041d759ea3666d894._comment
new file mode 100644
index 0000000000..6e2d1bdb2e
--- /dev/null
+++ b/doc/forum/Alternative_to_Tor_for_remote_pairing__63__/comment_1_39417a8bd5e6834041d759ea3666d894._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="plasmastrike@66c1cae4abae92d03faf344111c446a1908981ff"
+ nickname="plasmastrike"
+ avatar="http://cdn.libravatar.org/avatar/2859d0b6fe78b2252c6fbf46ce02e85b"
+ subject="Yggdrasill"
+ date="2019-11-01T13:34:36Z"
+ content="""
+You could use Yggdrasil and a Yggdrasil ipv6 address. It would allow you to ssh even if the ssh port is normally blocked. Think of Yggdrasil as dynamic reconfiguring vpn so all traffic goes through one port and encrypted.
+
+https://yggdrasil-network.github.io/
+https://yggdrasil-network.github.io/2018/07/15/remote-access.html
+
+You would still need ssh, rsync or an alternative to move the files but you will get past blocked ports
+"""]]
diff --git a/doc/forum/Alternative_to_XMPP_on_Windows__63__.mdwn b/doc/forum/Alternative_to_XMPP_on_Windows__63__.mdwn
new file mode 100644
index 0000000000..7edd703e01
--- /dev/null
+++ b/doc/forum/Alternative_to_XMPP_on_Windows__63__.mdwn
@@ -0,0 +1 @@
+Is there an alternative to XMPP to sync Windows machines?
diff --git a/doc/forum/Alternative_to_XMPP_on_Windows__63__/comment_1_4084abf5b26fcc92e577eea34c331a15._comment b/doc/forum/Alternative_to_XMPP_on_Windows__63__/comment_1_4084abf5b26fcc92e577eea34c331a15._comment
new file mode 100644
index 0000000000..39ab7a8a67
--- /dev/null
+++ b/doc/forum/Alternative_to_XMPP_on_Windows__63__/comment_1_4084abf5b26fcc92e577eea34c331a15._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-04T17:16:43Z"
+ content="""
+The best alternative currently is to use a server with git-annex installed,
+which the windows instance can then communicate with.
+"""]]
diff --git a/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get.mdwn b/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get.mdwn
new file mode 100644
index 0000000000..61d0ea699e
--- /dev/null
+++ b/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get.mdwn
@@ -0,0 +1,15 @@
+I have a big git-annex repository. If I add a few files on my laptop I want to sync it with my server which consists of one bare git-annex repository (server_bare) and one regular git-annex repository (server).
+
+I run
+
+git annex sync
+git annex copy * --to server
+
+The second command is really slow since it runs git annex copy on every single file that I have locally (it sometimes takes an hour to complete). If I would instead run
+
+git annex sync
+git annex get .
+
+This is usually quite fast, but it is not so easy to do since I don't keep an SSH port open on my laptop.
+
+My question: Is there any command that I can run on my laptop which basically invokes "git annex get ." from the server?
diff --git a/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_1_7f62ed07749308a46f0028a9586a10a4._comment b/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_1_7f62ed07749308a46f0028a9586a10a4._comment
new file mode 100644
index 0000000000..b9aabb3098
--- /dev/null
+++ b/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_1_7f62ed07749308a46f0028a9586a10a4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-02T20:33:31Z"
+ content="""
+Try `git annex copy --fast --to server`
+
+That avoids checking if the server still has every file, and only sends
+files it knows the server does not have. If you've just synced with the
+server, it knows what's on the server, so this can't go wrong.
+
+That'll be almost as fast as `git annex get`
+"""]]
diff --git a/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_2_a0c58c65091f36b426e016c700ec2f1c._comment b/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_2_a0c58c65091f36b426e016c700ec2f1c._comment
new file mode 100644
index 0000000000..60239f93a9
--- /dev/null
+++ b/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_2_a0c58c65091f36b426e016c700ec2f1c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kristianrumberg@85de814abe9398ab5573b77bb8a7a80ceaf3b9e1"
+ nickname="kristianrumberg"
+ avatar="http://cdn.libravatar.org/avatar/bb8d029db59da98a0c5e0053b1edc459"
+ subject="comment 2"
+ date="2017-02-05T17:02:10Z"
+ content="""
+Thanks :) It indeed speeds it up a lot
+"""]]
diff --git a/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_3_102047d2676af0bc62791fa0f18ac49f._comment b/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_3_102047d2676af0bc62791fa0f18ac49f._comment
new file mode 100644
index 0000000000..bdd7907796
--- /dev/null
+++ b/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_3_102047d2676af0bc62791fa0f18ac49f._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="kanak@3c4f6e7d832d88751c617b25bdbac896417eb93b"
+ nickname="kanak"
+ avatar="http://cdn.libravatar.org/avatar/708121dfec06e554300b2a3a73a26818"
+ subject="get appears to be doing less work?"
+ date="2017-08-22T11:55:41Z"
+ content="""
+I'm running v6.20170519 on Fedora. Syncing between my desktop and my external drive (USB3).
+
+When I do the following:
+
+1. desktop$ git annex sync usbdrive
+2. desktop$ git annex copy --fast --to usbdrive
+
+The output shows every single file in the respository followed quickly by an OK. Output-wise it's no different than if i omitted the --fast flag. 
+
+However, when I do the following, 
+
+1. usbdrive$ git annex sync desktop
+2. usbdrive$ git annex get .
+
+The only output is the files being copied over. It also appears to be faster for me than a copy.
+
+I feel like i'm missing something basic or some step? Is copy --fast doing the same amount of work as get but just displaying more output?
+"""]]
diff --git a/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_4_717078ebeb3b69dd9c52c8abe457824a._comment b/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_4_717078ebeb3b69dd9c52c8abe457824a._comment
new file mode 100644
index 0000000000..8145210a70
--- /dev/null
+++ b/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_4_717078ebeb3b69dd9c52c8abe457824a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="kanak@3c4f6e7d832d88751c617b25bdbac896417eb93b"
+ nickname="kanak"
+ avatar="http://cdn.libravatar.org/avatar/708121dfec06e554300b2a3a73a26818"
+ subject="get appears to be doing less work? (Part 2)"
+ date="2017-08-22T12:20:56Z"
+ content="""
+I tried git annex copy --to desktop from my laptop:
+
+without --fast, I see a \"(checking desktop)\" line
+with --fast, I only see the lines corresponding to transfer between files.
+
+Given that I don't see a \"checking\" line when I do this with my usb, I assume that it's not actually checking. However, I'm puzzled by the difference in output between the USB and the SSH scenarios.
+
+I still feel like I have a basic misunderstanding here, and I apologize in advance.
+"""]]
diff --git a/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_5_0630abbcb27e1f9dc5e9269b09a99b09._comment b/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_5_0630abbcb27e1f9dc5e9269b09a99b09._comment
new file mode 100644
index 0000000000..ad4043f3b5
--- /dev/null
+++ b/doc/forum/Alternative_to_git_annex_copy_which_is_as_fast_as_git_annex_get/comment_5_0630abbcb27e1f9dc5e9269b09a99b09._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-09-29T20:23:21Z"
+ content="""
+The behavior is different when the remote repository is on the USB drive,
+because git-annex knows it can quickly check if the remote really contains
+a file, and so it always checks it, even with --fast.
+
+I'm not sure if you're actually seeing a significant speed difference, or
+are psycholicically feeling it's slower since it outputs more. Perhaps you
+should time it.
+"""]]
diff --git a/doc/forum/Always_sync_all_content_to_remote.mdwn b/doc/forum/Always_sync_all_content_to_remote.mdwn
new file mode 100644
index 0000000000..fa6cc08719
--- /dev/null
+++ b/doc/forum/Always_sync_all_content_to_remote.mdwn
@@ -0,0 +1,5 @@
+I am trying to set up two repositories, one on my laptop and one on my server, and then have "git annex sync" always push everything on the laptop to the server.
+
+So far, I have created repositories on the laptop and on the server and then added the server as an ssh remote on the laptop. At the root of the repository on the server, I ran "git annex group . backup" and "git annex wanted . standard". At the root of the repository on the laptop, I ran "git annex group . manual" and "git annex wanted . standard". When I run "git annex sync" or "git annex sync --content" on the laptop now, it seems to only copy the symlink information to the server but not the actual data. When I go to the server and run git annex sync, it updates the working tree symlinks but does not have the content data they point to. If I use "git annex copy file --to server" then the symlink created when I ran "git annex sync" on the server points to the correct file. Do I not have the correct content preferences set up? Or do I need to alias "git annex sync --content" to "git annex sync --content && git annex copy . --to server" on the laptop?
+
+I want to be able to drop large amounts of data from the laptop and get it back if needed but always have it available on the server any way without having to push it explicitly. I would think that this would be a fairly common use case. Maybe I have missed something in the documentation? I have not set up the laptop as a remote on the server (I'd prefer not to -- I only plan to push/pull from the laptop, not push/pull from the server).
diff --git a/doc/forum/Always_sync_all_content_to_remote/comment_1_241c19cad6249fbd0832c76028c8b373._comment b/doc/forum/Always_sync_all_content_to_remote/comment_1_241c19cad6249fbd0832c76028c8b373._comment
new file mode 100644
index 0000000000..3ceecdf8de
--- /dev/null
+++ b/doc/forum/Always_sync_all_content_to_remote/comment_1_241c19cad6249fbd0832c76028c8b373._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-30T15:33:13Z"
+ content="""
+The configuration you describe sounds right and should work.
+
+Are you sure that the laptop had seen the changed configuration from the
+server when `git annex sync --content` didn't send files to the server?
+Ie, did you try running it a second time?
+"""]]
diff --git a/doc/forum/Always_sync_all_content_to_remote/comment_4_3eda671cea0f8869f1aac0194cae7146._comment b/doc/forum/Always_sync_all_content_to_remote/comment_4_3eda671cea0f8869f1aac0194cae7146._comment
new file mode 100644
index 0000000000..2a2c02d52d
--- /dev/null
+++ b/doc/forum/Always_sync_all_content_to_remote/comment_4_3eda671cea0f8869f1aac0194cae7146._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d"
+ nickname="wsha.code+ga"
+ subject="comment 4"
+ date="2015-06-02T21:37:36Z"
+ content="""
+Okay, sorry, in the previous posts, I misunderstood parts of how git annex works. Let me break down what I want to do again and how I have tried to set it up.
+
+Use case
+--------
+The basic use case is to have a client (could be more than one) generating content that is pushed to a server. The client would like to be able to drop any data at any time, while the server is expected to keep all data at all times. Additionally, the data stored in the server should be visible in the working tree to other users on the server (and the working tree should stay up to date). The client has push access to the server, but the server does not have pull access to the client.
+
+Set up
+------
+I have taken the following steps to try to set this up so far:
+
+* Create git annex repos on the client and server.
+* Add the server as a remote for the client.
+* Set the client's group as manual and the server's group as backup.
+* Set up the server so that its working tree is kept up to date
+  - This step was one of the ones I was expecting to work when I first asked the question
+  - To do this, I added `git merge synced/master master` to the `annex-content` hook described [here](https://git-annex.branchable.com/git-annex-shell/) and to the `post-receive` hook (I did this because the `annex-content` hook was not being called for updates pushed by the assistant -- should it be?).
+* Set up the server so its working tree remains visible to other users
+  - Set `git config core.sharedrepository group` on the server repo as described [here](http://git-annex.branchable.com/tips/shared_git_annex_directory_between_multiple_users/) so that the server's files are accessible to other users in the same group.
+  - I'm not sure if the previous step was doing anything because updated files were still being changed to the server's group. To deal with this, I added `chgrp -R shared \"$(git rev-parse --show-toplevel)\"` to the `annex-content`, `post-receive`, and `post-merge` hooks.
+
+Questions
+---------
+The above set up seems to be working now. My remaining questions are:
+
+1. Is it okay to auto merge synced/master like this? Is there a better way to do the same thing? The repo contents should only see light editing, but could I run into problems if the client is running the assistant and I try to edit files on the server directly (e.g. if some file is modified on the client and the assistant triggers it auto-merging into the server while I am modifying some other file in the server's working tree)? Should I use a separate client repo on the server if I want to modify files on the server?
+2. Is there a better way to make the group permissions stick?
+3. Is it okay to symlink just `git-annex` and `git-annex-shell` onto my path and not `git`, `git-upload-pack`, `git-receive-pack`, etc? Maybe there is no downside to using the versions that are packaged with git annex for all of my general git usage, but I'd rather just use the system git for things other than git annex.
+"""]]
diff --git a/doc/forum/Ambigous_argument___40__unknown_revision_or_path__41__.mdwn b/doc/forum/Ambigous_argument___40__unknown_revision_or_path__41__.mdwn
new file mode 100644
index 0000000000..a4cc6a0a50
--- /dev/null
+++ b/doc/forum/Ambigous_argument___40__unknown_revision_or_path__41__.mdwn
@@ -0,0 +1,148 @@
+Okey, so I set up a repo on a client computer with files in a directory. All went fine without errors. Then I created the remote server in backup mode. Everything went well with the sync. Back at the office I now want the same repo content on this computer, so I fire up the assistant, add a local repo directory (empty of course) and then add a remote server. Then this happens
+
+    [2014-11-05 09:17:24 CET] main: Syncing with server__volume1_work_user_work
+    From ssh://git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work
+     * [new branch]      git-annex  -> server__volume1_work_user_work/git-annex
+     * [new branch]      master     -> server__volume1_work_user_work/master
+     * [new branch]      synced/git-annex -> server__volume1_work_user_work/synced/git-annex
+     * [new branch]      synced/master -> server__volume1_work_user_work/synced/master
+    (merging server__volume1_work_user_work/git-annex server__volume1_work_user_work/synced/git-annex into git-annex...)
+    (Recording state in git...)
+    fatal: ambiguous argument 'refs/heads/synced/master..refs/remotes/server__volume1_work_user_work/synced/master': unknown revision or path not in the working tree.
+    Use '--' to separate paths from revisions, like this:
+    'git <command> [<revision>...] -- [<file>...]'
+
+    Automatic merge went well; stopped before committing as requested
+    To ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/
+       3943547..00aa6bd  git-annex -> synced/git-annex
+     ! [rejected]        annex/direct/master -> synced/master (non-fast-forward)
+    error: failed to push some refs to 'ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/'
+    hint: Updates were rejected because a pushed branch tip is behind its remote
+    hint: counterpart. Check out this branch and integrate the remote changes
+    hint: (e.g. 'git pull ...') before pushing again.
+    hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+    [2014-11-05 09:20:09 CET] Pusher: Syncing with server__volume1_work_user_work
+    [2014-11-05 09:20:09 CET] Committer: Committing changes to git
+    (Recording state in git...)
+
+    SHA256E-s1570--7437c0b77825d2636723cde82f0094854357aec43619b7d62707b5c26c4b0379.c
+
+                  0   0%    0.00kB/s    0:00:00
+              1,570 100%    1.50MB/s    0:00:00 (xfr#1, to-chk=0/1)
+    [2014-11-05 09:20:10 CET] Transferrer: Downloaded timing_ds20.c
+    To ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/
+       0e52256..2515592  annex/direct/master -> synced/master
+    error: Ref refs/heads/synced/master is at 2515592b1a0b2a355b5334c315d8857619b4a9c3 but expected 0e522560b9b6f0e52f789187e2fbd9076174bc4b
+    remote: error: failed to lock refs/heads/synced/master
+    To ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/
+     ! [remote rejected] annex/direct/master -> synced/master (failed to lock)
+    error: failed to push some refs to 'ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/'
+    To ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/
+     * [new branch]      git-annex -> refs/synced/a455ea74-d6fe-4f82-b796-72c20fc113fd/git-annex
+     * [new branch]      annex/direct/master -> refs/synced/a455ea74-d6fe-4f82-b796-72c20fc113fd/annex/direct/master
+
+    SHA256E-s7--19d210b22987ea279fe707c89b3afdbe530537118d3bac62c722b6ec54901e5a
+
+                  0   0%    0.00kB/s    0:00:00
+                  7 100%    6.84kB/s    0:00:00 (xfr#1, to-chk=0/1)
+    [2014-11-05 09:20:13 CET] Transferrer: Downloaded somefile
+    [2014-11-05 09:20:13 CET] Pusher: Syncing with server__volume1_work_user_work
+    (Recording state in git...)
+
+    SHA256E-s7762408--27c11674fe8c0b23f469aa90342dd45bf9ec9c83108251985b3231178f0f4ed5.pdf
+
+                  0   0%    0.00kB/s    0:00:00
+          5,406,720  69%    5.12MB/s    0:00:00
+          7,762,408 100%    5.01MB/s    0:00:01 (xfr#1, to-chk=0/1)
+    To ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/
+       00aa6bd..841a157  git-annex -> synced/git-annex
+    [2014-11-05 09:20:16 CET] Transferrer: Downloaded anotherfile.pdf
+
+    SHA256E-s322841--452ddf060131e1cfe44a02ee23840494d4566c4b1ad58f0131d52f17fbf65ea2.pdf
+
+And then it continues transfering the files. Then this happens
+
+    error: Ref refs/heads/synced/git-annex is at 4a802d679a5a7e2eae3c16b2ed0a8d724b665b0a but expected 45004c24db2eb24dddc04d1542d3689aa27b9507
+    remote: error: failed to lock refs/heads/synced/git-annex
+    To ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/
+     ! [remote rejected] git-annex -> synced/git-annex (failed to lock)
+    error: failed to push some refs to 'ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/'
+    [2014-11-05 10:13:48 CET] read: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","push","server__volume1_work_user_work","master"]
+
+    SHA256E-s115543--4aca4053b23d914ea034f06439edcb7d3d9bcc24b5d9865f5e062394ca1263e0
+   
+                  0   0%    0.00kB/s    0:00:00
+            115,543 100%    2.98MB/s    0:00:00 (xfr#1, to-chk=0/1)
+    [2014-11-05 10:13:48 CET] feed: ssh ["-S",".git/annex/ssh/abf79f467a5dcf714ddaf5162ffc09ba","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork","git-annex-shell 'transferinfo' '/volume1/work_user/work/' 'SHA256E-s115543--4aca4053b23d914ea034f06439edcb7d3d9bcc24b5d9865f5e062394ca1263e0' --uuid 05bdd8d5-da30-4024-a921-0f8b1a2f33df '--' 'remoteuuid=a455ea74-d6fe-4f82-b796-72c20fc113fd' 'associatedfile=pathtosomefile' '--'"]
+    [2014-11-05 10:13:48 CET] NetWatcherFallback: trying manual pull to resolve failed pushes
+    [2014-11-05 10:13:48 CET] call: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","fetch","server__volume1_work_user_work"]
+    [2014-11-05 10:13:48 CET] Watcher: add symlink pathtosomefile
+    [2014-11-05 10:13:48 CET] Transferrer: Downloaded file
+    [2014-11-05 10:13:48 CET] TransferWatcher: transfer finishing: Transfer {transferDirection = Download, transferUUID = UUID "05bdd8d5-da30-4024-a921-0f8b1a2f33df", transferKey = Key {keyName = "4aca4053b23d914ea034f06439edcb7d3d9bcc24b5d9865f5e062394ca1263e0", keyBackendName = "SHA256E", keySize = Just 115543, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}}
+    [2014-11-05 10:13:48 CET] Transferrer: Transferring: Download UUID "05bdd8d5-da30-4024-a921-0f8b1a2f33df" pathtosomefile2 Nothing
+    [2014-11-05 10:13:48 CET] TransferWatcher: transfer starting: Download UUID "05bdd8d5-da30-4024-a921-0f8b1a2f33df" SHA256E-s145572--50e4d0d2fa52fb6843258509637307b8efc87d31abab834e7bc3174296689e25 Nothing
+    [2014-11-05 10:13:48 CET] TransferWatcher: transfer starting: Download UUID "05bdd8d5-da30-4024-a921-0f8b1a2f33df" pathtosomefile2 Nothing
+    [2014-11-05 10:13:48 CET] read: rsync ["--progress","--inplace","--perms","-e","'ssh' '-S' '.git/annex/ssh/abf79f467a5dcf714ddaf5162ffc09ba' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork' 'git-annex-shell ''sendkey'' ''/volume1/work_user/work/'' ''SHA256E-s145572--50e4d0d2fa52fb6843258509637307b8efc87d31abab834e7bc3174296689e25'' --uuid 05bdd8d5-da30-4024-a921-0f8b1a2f33df ''--'' ''remoteuuid=a455ea74-d6fe-4f82-b796-72c20fc113fd'' ''direct=1'' ''associatedfile=pathtosomefile2'' ''--'''","--","dummy:","/home/officeusername/work/.git/annex/tmp/SHA256E-s145572--50e4d0d2fa52fb6843258509637307b8efc87d31abab834e7bc3174296689e25"]
+    [2014-11-05 10:13:49 CET] Committer: committing 2 changes
+    [2014-11-05 10:13:49 CET] Committer: Committing changes to git
+    (Recording state in git...)
+    [2014-11-05 10:13:49 CET] feed: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","update-index","-z","--index-info"]
+    [2014-11-05 10:13:49 CET] read: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","symbolic-ref","HEAD"]
+    [2014-11-05 10:13:49 CET] read: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","show-ref","--hash","refs/heads/annex/direct/master"]
+    [2014-11-05 10:13:49 CET] read: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","write-tree"]
+    [2014-11-05 10:13:49 CET] read: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","rev-parse","2515592b1a0b2a355b5334c315d8857619b4a9c3:"]
+    [2014-11-05 10:13:49 CET] read: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","symbolic-ref","HEAD"]
+    [2014-11-05 10:13:49 CET] read: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","show-ref","refs/heads/annex/direct/master"]
+    [2014-11-05 10:13:49 CET] call: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","branch","-f","synced/master"]
+    [2014-11-05 10:13:49 CET] call: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","branch","-f","master"]
+    drop server__volume1_work_user_work pathtosomefile2
+    [2014-11-05 10:13:49 CET] call: ssh ["-S",".git/annex/ssh/abf79f467a5dcf714ddaf5162ffc09ba","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork","git-annex-shell 'dropkey' '/volume1/work_user/work/' '--quiet' '--force' 'SHA256E-s674028--398092ddec93e33310ca8be87b4d48b2c84a873b579b80002cad3738c1461266' --uuid 05bdd8d5-da30-4024-a921-0f8b1a2f33df"]
+
+    SHA256E-s145572--50e4d0d2fa52fb6843258509637307b8efc87d31abab834e7bc3174296689e25
+
+Again it transfer some files...and then
+
+    error: Ref refs/heads/synced/git-annex is at ac6d09794a274e861db1ef00295e361e15d85ca3 but expected 4a802d679a5a7e2eae3c16b2ed0a8d724b665b0a
+    remote: error: failed to lock refs/heads/synced/git-annex
+    To ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/
+     ! [remote rejected] git-annex -> synced/git-annex (failed to lock)
+    error: failed to push some refs to 'ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/'
+    [2014-11-05 10:13:52 CET] read: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","push","server.me__volume1_work_user_work","master"]
+
+          8,454,144   2%    2.67MB/s    0:02:24  [2014-11-05 10:13:53 CET] NetWatcherFallback: fallback pushing to [Remote { name ="server__volume1_work_user_work" }]
+    [2014-11-05 10:13:53 CET] call: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","push","server.me__volume1_work_user_work","+git-annex:refs/synced/a455ea74-d6fe-4f82-b796-72c20fc113fd/git-annex","refs/heads/annex/direct/master:refs/synced/a455ea74-d6fe-4f82-b796-72c20fc113fd/annex/direct/master"]
+
+         12,058,624   2%    2.86MB/s    0:02:13  To ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/
+       00aa6bd..ac6d097  git-annex -> refs/synced/a455ea74-d6fe-4f82-b796-72c20fc113fd/git-annex
+
+         16,875,520   4%    3.34MB/s    0:01:53  [2014-11-05 10:13:55 CET] Pusher: Syncing with server__volume1_work_user_work
+
+Again
+
+    error: Ref refs/heads/synced/git-annex is at 383d9581c2722ab87647cf26f1ab8f25758866a4 but expected d158cddb1055adbe44973208d5562961acb0c42b
+    remote: error: failed to lock refs/heads/synced/git-annex
+    To ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/
+     ! [remote rejected] git-annex -> synced/git-annex (failed to lock)
+    error: failed to push some refs to 'ssh://username@git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work/'
+    [2014-11-05 11:13:58 CET] read: git ["--git-dir=/home/officeusername/work/.git","--work-tree=/home/officeusername/work","-c","core.bare=false","push","server__volume1_work_user_work","master"]
+    ok
+    [2014-11-05 11:13:58 CET] dropped somefile (from UUID "05bdd8d5-da30-4024-a921-0f8b1a2f33df") (copies now 2) : file renamed
+    [2014-11-05 11:13:58 CET] TransferWatcher: transfer starting: Download UUID "05bdd8d5-da30-4024-a921-0f8b1a2f33df" someotherfile Nothing
+
+Then some other stuff
+
+    error: Ref refs/remotes/server__volume1_work_user_work/synced/git-annex is at 2e867456306f9ac0dd61e29c221ea3968dc4cb70 but expected 086e08a168498b84a74065c1f71e114a9868867d
+    From ssh://git-annex-server-username_7000_.2Fvolume1.2Fwork_user.2Fwork/volume1/work_user/work
+    ! 086e08a..2e86745  synced/git-annex -> server__volume1_work_user_work/synced/git-annex  (unable to update local ref)
+
+And so on. When submitting this, the system is still transfering files (arrow pointing to the left, so that has to be from the server to the office computer I suppose). Checking the office computer file index by running
+
+    git ls-files | wl -l
+
+yields the expected number of files. So, in addition to the errors above this seems a bit strange to me that it is still transferring files.
+
+Thinking about the error messages above...is it so that the download and git repo updates work in parallel, so if git tries to update on a partly transferred files the checksum is wrong and then I get the errors above? If so, is the file transferred again later and is there a way to suppress the "failed to sync" in the webapp? 
+
+Another thing, then I add the remote server it automatically goes into transfer mode, even though I configured it to be a backup from home before coming into the office. Maybe it is not autodetected. Would it cause problem to later change it from transfer to backup mode?
+
+Hope someone can point me in the right direction. And thanks in advance!
diff --git a/doc/forum/Ambiguous_repo_names__63__.mdwn b/doc/forum/Ambiguous_repo_names__63__.mdwn
new file mode 100644
index 0000000000..fb96240fe7
--- /dev/null
+++ b/doc/forum/Ambiguous_repo_names__63__.mdwn
@@ -0,0 +1,8 @@
+The output of `git annex info` includes this:
+
+ 	34xx3351-xx14-4039-6xxx-xxx9x5xxxxxx -- wx550 (wx312)
+ 	9x9x07xx-x6x9-464x-7x5x-x3xx42xx7x70 -- wx550
+
+What does this mean? Do I have two different repos both named wx550?
+What is wx312? 
+
diff --git a/doc/forum/Ambiguous_repo_names__63__/comment_1_9695c42113ad6c873b1eae1c1f04e70a._comment b/doc/forum/Ambiguous_repo_names__63__/comment_1_9695c42113ad6c873b1eae1c1f04e70a._comment
new file mode 100644
index 0000000000..13f7dbe78d
--- /dev/null
+++ b/doc/forum/Ambiguous_repo_names__63__/comment_1_9695c42113ad6c873b1eae1c1f04e70a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-06-03T17:35:38Z"
+ content="""
+You have two repositories with a description of "wx550".
+You can set the description to anything you want using `git annex
+describe`.
+
+One of the repositories is configured as a remote of the local repositry.
+This means that the local repository can access it. The name of that
+remote is "wx312".
+"""]]
diff --git a/doc/forum/Android_-_ext3__47__4__47__....mdwn b/doc/forum/Android_-_ext3__47__4__47__....mdwn
new file mode 100644
index 0000000000..5227228a97
--- /dev/null
+++ b/doc/forum/Android_-_ext3__47__4__47__....mdwn
@@ -0,0 +1 @@
+Is there a good way to use a ext4 formated external sdcard on a rooted android with symlinks. If android mounts it (with the sdcard command i think) symlinks don't work. If i mount it with mount the permissions are a problem because every app has a different user.
diff --git a/doc/forum/Android__58___Cabal_hell.mdwn b/doc/forum/Android__58___Cabal_hell.mdwn
new file mode 100644
index 0000000000..e31b1b0dce
--- /dev/null
+++ b/doc/forum/Android__58___Cabal_hell.mdwn
@@ -0,0 +1,32 @@
+I tried to build the Android app according to the instructions on [the install page](https://git-annex.branchable.com/install/Android/).
+
+But during step 2 (In the chroot, run install-haskell-packages) cabal fails to handle the dependencies correctly. So I tried to change the standalone/android/cabal.config file to update all the dependencies, but this had me running into something I think is unresolvable in another package's
+dependencies. Eventually I had the following output:
+
+    # ./standalone/android/install-haskell-packages 
+    Downloading the latest package list from hackage.haskell.org
+    Skipping download: Local and remote files match.
+    /home/repo/git-annex /home/repo/git-annex/standalone/android
+    Resolving dependencies...
+    cabal: Could not resolve dependencies:
+    trying: git-annex-6.20160318 (user goal)
+    trying: persistent-template-2.1.6/installed-08b... (dependency of
+    git-annex-6.20160318)
+    next goal: monad-control (dependency of git-annex-6.20160318)
+    rejecting: monad-control-1.0.0.5/installed-cac..., 1.0.0.5, 1.0.0.4, 1.0.0.3,
+    1.0.0.2, 1.0.0.1, 1.0.0.0, 0.3.3.1, 0.3.3.0, 0.3.2.3 (global constraint
+    requires ==0.3.2.2)
+    rejecting: monad-control-0.3.2.2 (conflict: persistent-template =>
+    monad-control==1.0.0.5/installed-cac...)
+    rejecting: monad-control-0.3.2.1, 0.3.2, 0.3.1.4, 0.3.1.3, 0.3.1.2, 0.3.1.1,
+    0.3.1, 0.3.0.1, 0.3, 0.2.0.3, 0.2.0.2, 0.2.0.1, 0.2, 0.1 (global constraint
+    requires ==0.3.2.2)
+
+This tells me that the package persistent-template depends on the package monad-control at a version of 1.0.0.5. So I look at the [persistent-template hackage page](https://hackage.haskell.org/package/persistent-template-2.1.6) and see that it lists its dependency on monad-control as:
+
+    monad-control (>=0.2 && <1.1)
+
+And I don't think that's possible to resolve.
+
+All I wanted to do was change the icons on the Android package, so if you'll just accept the changed
+icons folder, I can submit the patch without testing the Android build, but currently I'm unable to build the Android port of git-annex.
diff --git a/doc/forum/Android__58___Cabal_hell/comment_1_34e869c1092f2885f54f627fb77a6057._comment b/doc/forum/Android__58___Cabal_hell/comment_1_34e869c1092f2885f54f627fb77a6057._comment
new file mode 100644
index 0000000000..e96bdf2222
--- /dev/null
+++ b/doc/forum/Android__58___Cabal_hell/comment_1_34e869c1092f2885f54f627fb77a6057._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-03-28T13:20:06Z"
+ content="""
+The android packages are all pinned at old versions, so the build is
+supposed to be reproducible using those versions. Diverging certainly
+invites cabal hell.
+
+Any chance you could show the original failure?
+
+I could probably integrate new icons if you want to just submit them.
+"""]]
diff --git a/doc/forum/Android__58___Cabal_hell/comment_2_ed5b2b37d37278458fdf2dc37539e741._comment b/doc/forum/Android__58___Cabal_hell/comment_2_ed5b2b37d37278458fdf2dc37539e741._comment
new file mode 100644
index 0000000000..0dba07c3c5
--- /dev/null
+++ b/doc/forum/Android__58___Cabal_hell/comment_2_ed5b2b37d37278458fdf2dc37539e741._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="freewheelinfranks@f936f2e420801f565d39e40036c0a22c71a79425"
+ nickname="freewheelinfranks"
+ subject="Makes sense."
+ date="2016-04-02T23:41:23Z"
+ content="""
+Okay, thanks for the information.
+
+How should I send you the icons? I have sent you an email with a zip file of the icons. If that is not appropriate, please let me know.
+"""]]
diff --git a/doc/forum/Android__58___Cabal_hell/comment_3_fe71aa84ed5e1bb1e19a7d0f4e42eccd._comment b/doc/forum/Android__58___Cabal_hell/comment_3_fe71aa84ed5e1bb1e19a7d0f4e42eccd._comment
new file mode 100644
index 0000000000..c9d865c648
--- /dev/null
+++ b/doc/forum/Android__58___Cabal_hell/comment_3_fe71aa84ed5e1bb1e19a7d0f4e42eccd._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-04-14T19:01:42Z"
+ content="""
+An email would be fine, but I have not received that email.
+
+Post a link to somewhere?
+"""]]
diff --git a/doc/forum/Android__58___Cabal_hell/comment_4_da004cee7c0cf5617291dbd520af2e96._comment b/doc/forum/Android__58___Cabal_hell/comment_4_da004cee7c0cf5617291dbd520af2e96._comment
new file mode 100644
index 0000000000..043ed6d552
--- /dev/null
+++ b/doc/forum/Android__58___Cabal_hell/comment_4_da004cee7c0cf5617291dbd520af2e96._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="freewheelinfranks@f936f2e420801f565d39e40036c0a22c71a79425"
+ nickname="freewheelinfranks"
+ subject="Here's a link to the image files"
+ date="2016-05-03T06:14:40Z"
+ content="""
+The file \"icons.zip\" can replace the icons folder in the git-annex repo. The folder to be replaced is found at standalone/android/icons.
+
+[https://stanford.edu/~farhank/icons.zip](https://stanford.edu/~farhank/icons.zip)
+"""]]
diff --git a/doc/forum/Android__58___Cabal_hell/comment_5_12e2cb09ac2ee07b392cd9be064a3cbe._comment b/doc/forum/Android__58___Cabal_hell/comment_5_12e2cb09ac2ee07b392cd9be064a3cbe._comment
new file mode 100644
index 0000000000..2fc689cb3c
--- /dev/null
+++ b/doc/forum/Android__58___Cabal_hell/comment_5_12e2cb09ac2ee07b392cd9be064a3cbe._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-05-03T17:26:34Z"
+ content="""
+Indeed, I can see these are better scaled and rounded corners.
+Thanks for the contribution, and for testing it! Merged.
+"""]]
diff --git a/doc/forum/Android__58___Encrypted_Remotes__63__.mdwn b/doc/forum/Android__58___Encrypted_Remotes__63__.mdwn
new file mode 100644
index 0000000000..b8342392fc
--- /dev/null
+++ b/doc/forum/Android__58___Encrypted_Remotes__63__.mdwn
@@ -0,0 +1,3 @@
+Hi,
+
+Does the Android app support encryption at all? The assistant allows me to create encrypted repositories but it just keeps telling me to install git-remote-gcrypt, which did not work.
diff --git a/doc/forum/Android__58___Encrypted_Remotes__63__/comment_1_6b16cd372a9bd4f99d4c8b09a82ce3ed._comment b/doc/forum/Android__58___Encrypted_Remotes__63__/comment_1_6b16cd372a9bd4f99d4c8b09a82ce3ed._comment
new file mode 100644
index 0000000000..3edcc5f900
--- /dev/null
+++ b/doc/forum/Android__58___Encrypted_Remotes__63__/comment_1_6b16cd372a9bd4f99d4c8b09a82ce3ed._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 1"
+ date="2014-07-03T19:14:37Z"
+ content="""
+Encrypted [[special_remotes]] are supported just fine on Android.
+
+As for storing the [[encrypted git repository itself on a remote|special_remotes/gcrypt]], which is what git-remote-gcrypt is used for, it would need porting that to Android. I don't think that should be very hard (it's just a rather complicated shell script and all the tools it uses are already included in the git-annex bundle). I may eventully end up reimplementing git-remote-gcrypt as part of git-annex in Haskell, since porting it to eg, Windows is likely to be a lot harder..
+"""]]
diff --git a/doc/forum/Android__58___git_annex_sync_--content_not_run_in_all_repos__63__.mdwn b/doc/forum/Android__58___git_annex_sync_--content_not_run_in_all_repos__63__.mdwn
new file mode 100644
index 0000000000..4d4b679417
--- /dev/null
+++ b/doc/forum/Android__58___git_annex_sync_--content_not_run_in_all_repos__63__.mdwn
@@ -0,0 +1,24 @@
+I have two repositories in an Android device, and each is synced with a corresponding repo in a computer:
+
+A-android <-> A-computer
+
+B-android <-> B-computer
+
+Both are configured as "client: a repository on your computer".
+
+
+One of the repositories (say, A) has the expected behavior (changes in the Android device show in the computer and viceversa).
+
+The other repo pair doesn't. Changes in the computer do appear in the Android device, but not the other way around. I can get them to appear if, in the computer, I do
+
+~/B-computer$ git annex sync --content
+
+but not otherwise. For example, from the Android web app clicking "sync" in B-android or B-computer does not make the changes in the Android appear in the computer. 
+
+I am very new to git annex, but I do not understand this; I've searched around to no avail; I think that I should expect sync to run for all repositories  
+[http://git-annex.branchable.com/design/assistant/#comment-6ddc18af9685a7ddbbe6e639e7b15feb](http://git-annex.branchable.com/design/assistant/#comment-6ddc18af9685a7ddbbe6e639e7b15feb), but 
+then maybe not to do what I expect: [http://git-annex.branchable.com/sync/#comment-1a0a053001ef684a0f3c5325e8062483](http://git-annex.branchable.com/sync/#comment-1a0a053001ef684a0f3c5325e8062483).
+
+
+The problem with the behavior I see is that in addition to making me unsure if I am seeing the latest stuff when I do, say, "ls" or "cat", it leads to trouble (if I edit the same file in both the Android and the computer, eventually I will get a conflict, of course). If this is by design, is there a way to get all of the repositories to show the first behavior (changes propagated android <-> computer)?
+
diff --git a/doc/forum/Android__58___git_annex_sync_--content_not_run_in_all_repos__63__/comment_1_aff6a984ab076433fbce32bacae6660e._comment b/doc/forum/Android__58___git_annex_sync_--content_not_run_in_all_repos__63__/comment_1_aff6a984ab076433fbce32bacae6660e._comment
new file mode 100644
index 0000000000..8d62f0bf59
--- /dev/null
+++ b/doc/forum/Android__58___git_annex_sync_--content_not_run_in_all_repos__63__/comment_1_aff6a984ab076433fbce32bacae6660e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-25T19:22:17Z"
+ content="""
+It sounds like the android device is sending the files to repository
+B-computer, but it is not updating its repository until you run
+`git annex sync` manually.
+
+Are you sure that the git-annex assistant is actively managing the `B-computer`
+repository? I would `tail -f .git/annex/daemon.log` in that repository 
+when making a change to B-android, and see what it does.
+"""]]
diff --git a/doc/forum/Android__58___git_annex_sync_--content_not_run_in_all_repos__63__/comment_2_5b1565955ed88554e5ef4a00c0f4a754._comment b/doc/forum/Android__58___git_annex_sync_--content_not_run_in_all_repos__63__/comment_2_5b1565955ed88554e5ef4a00c0f4a754._comment
new file mode 100644
index 0000000000..056c78547b
--- /dev/null
+++ b/doc/forum/Android__58___git_annex_sync_--content_not_run_in_all_repos__63__/comment_2_5b1565955ed88554e5ef4a00c0f4a754._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnbPKLjBONawBd74MKJZo05juCqdsP1jAU"
+ nickname="Ramon"
+ subject="comment 2"
+ date="2015-02-26T08:08:37Z"
+ content="""
+Thanks. I'll check as suggested if it happens again. Since switching between repos in android was complicated, I've started all over putting everything in a single repo (the default one).
+"""]]
diff --git a/doc/forum/Android__58___is_constant_high_cpu_usage_to_be_expected__63__.mdwn b/doc/forum/Android__58___is_constant_high_cpu_usage_to_be_expected__63__.mdwn
new file mode 100644
index 0000000000..0392dbb38f
--- /dev/null
+++ b/doc/forum/Android__58___is_constant_high_cpu_usage_to_be_expected__63__.mdwn
@@ -0,0 +1,3 @@
+While running the Git Annex App on Android, the app causes a constant cpu usage of about 50% when idling. I've seen this behavior on two devices (phone and tablet) with a CM 10.1 nightly build. The app causes this high cpu usage even when it is in the background, not performing any synchronization and managing only one repository containing just one file. Unfortunately I couldn't figure out what causes the cpu usage. The daemon.log file remains unchanged and I couldn't find any other log files.
+
+Is this expected behavior or unusual high cpu usage?
diff --git a/doc/forum/Android__58___is_constant_high_cpu_usage_to_be_expected__63__/comment_1_7880fc38792a1fcbf3e5c47e8bcaabce._comment b/doc/forum/Android__58___is_constant_high_cpu_usage_to_be_expected__63__/comment_1_7880fc38792a1fcbf3e5c47e8bcaabce._comment
new file mode 100644
index 0000000000..28f3dfb925
--- /dev/null
+++ b/doc/forum/Android__58___is_constant_high_cpu_usage_to_be_expected__63__/comment_1_7880fc38792a1fcbf3e5c47e8bcaabce._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmKKg3Vmzk7KwRGRKjHVdtyoj1JfxLX6NM"
+ nickname="Tom"
+ subject="comment 1"
+ date="2013-10-01T17:38:03Z"
+ content="""
+I've had this issue as well. Saw a comment on Joey's blog that implies he knows about it and that a fix will be released soon.
+"""]]
diff --git a/doc/forum/Android__58___is_constant_high_cpu_usage_to_be_expected__63__/comment_2_840fbce18b4fdec21ee557fdf52c366e._comment b/doc/forum/Android__58___is_constant_high_cpu_usage_to_be_expected__63__/comment_2_840fbce18b4fdec21ee557fdf52c366e._comment
new file mode 100644
index 0000000000..eaf42c9e2a
--- /dev/null
+++ b/doc/forum/Android__58___is_constant_high_cpu_usage_to_be_expected__63__/comment_2_840fbce18b4fdec21ee557fdf52c366e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 2"
+ date="2013-10-16T16:57:02Z"
+ content="""
+This was fixed.
+
+(Please file bug reports for bugs in the future, so they don't clutter up this forum once fixed.)
+"""]]
diff --git a/doc/forum/Android__58___repository_is_not_initialized_for_use_by_.mdwn b/doc/forum/Android__58___repository_is_not_initialized_for_use_by_.mdwn
new file mode 100644
index 0000000000..542b4afcb2
--- /dev/null
+++ b/doc/forum/Android__58___repository_is_not_initialized_for_use_by_.mdwn
@@ -0,0 +1,22 @@
+I've been using git-annex in android/termux (pixel 3a, android 12 rooted) for a while to manage multiple repositories in command line (no assistant here). So far so good. I upgraded termux packages one day and troubles began: all repositories now throw the following errors for all kind of git-annex commands:
+
+```
+$ git annex status
+git-annex: This repository is not initialized for use by git-annex, but .git/annex/objects/ exists, which indicates this repository was used by git-annex before, and may have lost its annex.uuid and annex.version configs. Either set back missing configs, or run git-annex init to initialize with a new uuid.
+error: external filter 'git-annex smudge --clean -- %f' failed 1
+error: external filter 'git-annex smudge --clean -- %f' failed
+```
+
+Note I filter out the recurring error "WARNING: linker: Warning: failed to find generated linker configuration from ..." for clarity.
+git version: 2.36.1
+git annex version: 10.20220121
+
+- Funny thing #1: "git config -l" shows the uuid is correctly set.
+
+- Funny thing #2: I installed nix-on-droid with git (2.33.3) and git-annex (8.20211028) and ... I have the same error (?!?).
+
+- Funny thing #3: when I clone a repository from scratch, "git annex init" never completes. When interrupted, then "git annex status" never completes...
+
+- Funny thing #4: git alone works very well, in both git-annex'ed repos or plain git ones.
+
+If you have any idea of something to check/change/update/try, I'll be happy to report the results.
diff --git a/doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_1_ef3dbc83f24f00c49b7d7cf626af44aa._comment b/doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_1_ef3dbc83f24f00c49b7d7cf626af44aa._comment
new file mode 100644
index 0000000000..8a3a24b664
--- /dev/null
+++ b/doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_1_ef3dbc83f24f00c49b7d7cf626af44aa._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-07-15T15:11:34Z"
+ content="""
+Upgrade your git-annex to a newer version. I suspect you will get a
+different error message, perhaps along the lines of:
+
+	Git refuses to operate in this repository, probably because it is owned by someone else.
+
+(Although that would not explain why git-annex init might hang.)
+"""]]
diff --git a/doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_2_719abfa1dc9a64b1245376dedbccca6e._comment b/doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_2_719abfa1dc9a64b1245376dedbccca6e._comment
new file mode 100644
index 0000000000..1688e443df
--- /dev/null
+++ b/doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_2_719abfa1dc9a64b1245376dedbccca6e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 2"
+ date="2022-07-17T20:41:51Z"
+ content="""
+I'm using the latest git-annex version available for arm64 on android already. I checked both the stable build and the autobuild, both point to the same archive with git-annex 10.20220121-g0bcb94487
+
+I upgraded git to the latest revision available in termux base packages, namely git 2.37.1. It did not change anything.
+"""]]
diff --git a/doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_3_027130ce7e8a56551e1d16cbbae6d115._comment b/doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_3_027130ce7e8a56551e1d16cbbae6d115._comment
new file mode 100644
index 0000000000..f5e3c81c43
--- /dev/null
+++ b/doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_3_027130ce7e8a56551e1d16cbbae6d115._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 3"
+ date="2022-08-16T14:55:44Z"
+ content="""
+For those who face the same issue, here is a workaround: in git config, I force the annex.uuid and annex.version of the smudge & clean filter commands.
+
+in .git/config, from this:
+
+```
+[filter \"annex\"]
+  smudge = git-annex smudge -- %f
+  clean = git-annex smudge --clean -- %f
+```
+
+I go to:
+
+```
+[filter \"annex\"]
+  smudge = git -c annex.version=8 -c annex.uuid=<the repo uuid> annex smudge -- %f
+  clean = git -c annex.version=8 -c annex.uuid=<the repo uuid> annex smudge --clean -- %f
+```
+
+You can get the repo uuid in the same file.
+
+This is it !
+
+I don't know though why the git-annex filter command is not able to read the .git/config file to retrieve this information by itself (?!).
+"""]]
diff --git a/doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_4_99d78dca3534c4d54f6925a095f1d43f._comment b/doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_4_99d78dca3534c4d54f6925a095f1d43f._comment
new file mode 100644
index 0000000000..d22a6e1e06
--- /dev/null
+++ b/doc/forum/Android__58___repository_is_not_initialized_for_use_by_/comment_4_99d78dca3534c4d54f6925a095f1d43f._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-08-16T16:03:57Z"
+ content="""
+Aha, that is a useful clue about what's going on here!
+
+Since those smudge commands are run by git, it may be that git is doing
+something to the environment or cwd that prevents git-annex from reading
+the git config.
+
+Also, you have git installed in termux, but git-annex includes its
+own copy of git in its distribution. So it may be that the termux git is
+somehow causing this problem, but the one included in git-annex does not.
+
+Can you try running: 
+
+	cd git-annex.linux
+	./runshell
+
+And then see if the problem occurs when you use git-annex from within the
+shell that starts?
+"""]]
diff --git a/doc/forum/Android__58___unusably_slow_with_moderately_sized_repositories.mdwn b/doc/forum/Android__58___unusably_slow_with_moderately_sized_repositories.mdwn
new file mode 100644
index 0000000000..ca2b3906fa
--- /dev/null
+++ b/doc/forum/Android__58___unusably_slow_with_moderately_sized_repositories.mdwn
@@ -0,0 +1,67 @@
+I am trying to sync a repository between a computer and two Android devices. The data in the directory of files (i.e., not the .git directory) takes about 7.4 GB and there are about 10000 files and directories in total (as reported by find . | wc -l) of which 7000 are files (as reported by find - -type f | wc -l).
+
+I've used two different routes: 1. start the assistant in the Android in a directory with all the files: 2. start the assistant in the Android in an empty dir and sync with the git-annex repository in the computer. None are working. I am using, in the androids, v. 5.20150224-g9dca034 and in the computer the latest Debian version (5.20141125).
+
+Details follow:
+
+
+Route 1. 
+=========
+
+In one Android, I had already transmitted all the files (nothing git-related; just the directory). So I placed that directory under /sdcard/annex, and started the assistant. I did not add any other repository (i.e., the computer was not added). After more than 12 hours, it is not done. The webapp in the Android shows "Adding blablabla".
+
+If I compare the sizes of directories between the computer and the android with du I get:
+
+Computer:~  du -H -d 1
+215624  ./.git
+7710564 ./directory
+7926192 .
+
+
+Android (using adb shell):~ du -H -d 1
+7681744 ./directory
+35388   ./.git
+7717136 .
+
+
+Over the last six hours it seems the size in the Android is getting closer and closer to that in the computer, but it seems is never quite getting there. And then, I think after this is completed (if ever), I'll need to sync with the computer.
+
+
+Route 2. 
+========
+
+In the other Android I started the assistant, and added the computer as the other repository. Let them sync. Initially I was getting the TransferScanner crashed problem in
+[Android version does not sync](http://git-annex.branchable.com/forum/Android_version_does_not_sync/). So I issued the git-annex sync as suggested. Things started syncing. But again, after more than 12 hourse, it is not done and I have no idea how long I'd have to wait. In this case, git-annex seems to be placing stuff in ./git, as the things downloaded are actually links. A du shows this:
+
+392304  ./.git
+82464   ./directory
+474776  .
+
+-------
+
+I think I am experiencing two different problems:
+
+Problem 1. 
+==========
+
+git is just taking forever (route 1.) in the Android. There are not network issues possible there, since that Android is not downloading/syncing anything with anyone. Interestingly, in case this is of any use, from adb shell a top shows: 
+
+User 27%, System 16%, IOW 1%, IRQ 0%
+User 318 + Nice 28 + Sys 199 + Idle 674 + IOW 20 + IRQ 0 + SIRQ 0 = 1239
+
+
+and the git-annex process taking between 3% to 15% CPU.
+
+
+Problem 2
+==========
+
+git + network issues in route 2.  But I doubt this is mainly a network problem. As a comparison, using syncthing I was able to initially sync (i.e., download to the android device) the complete set of files in about four hours and then checking for changes in the Android takes syncthing about 1 to 3 minutes. I've also repeated this using a private seafile server (seafile server running in the computer); downloading all files takes about the same (about four hours), and then checking for changes against the seafile server takes between 45 minutes and an hour. For comparison, a top also shows that git-annex is taking between 2 and 15% CPU.
+
+
+So I am wondering if I am making some silly mistake here, or maybe this is not the intended use case (because of number or size of files for an Android device). Of course, computer-to-computer things work just fine. It is the Android part which is not working. 
+
+
+
+
+
diff --git a/doc/forum/Android__58___unusably_slow_with_moderately_sized_repositories/comment_3_c5c655ee3ec2501c1c3c60fd83574914._comment b/doc/forum/Android__58___unusably_slow_with_moderately_sized_repositories/comment_3_c5c655ee3ec2501c1c3c60fd83574914._comment
new file mode 100644
index 0000000000..42cab60b5e
--- /dev/null
+++ b/doc/forum/Android__58___unusably_slow_with_moderately_sized_repositories/comment_3_c5c655ee3ec2501c1c3c60fd83574914._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnbPKLjBONawBd74MKJZo05juCqdsP1jAU"
+ nickname="Ramon"
+ subject="comment 3"
+ date="2015-02-26T23:44:40Z"
+ content="""
+Please forgive the noise. I think I've been doing something very, very stupid. Sorry. I'd delete the whole thread if I could
+"""]]
diff --git a/doc/forum/Android___34__Bad_system_call__34__.mdwn b/doc/forum/Android___34__Bad_system_call__34__.mdwn
new file mode 100644
index 0000000000..ad6236c74c
--- /dev/null
+++ b/doc/forum/Android___34__Bad_system_call__34__.mdwn
@@ -0,0 +1,89 @@
+Hi!
+
+I'ce git a Pixel 4a with GrapheneOS running and tried to installiert git-annex, but it fails:
+
+~ $ source git-annex-install
+Installing dependencies with termux pkg manager...
+Testing the available mirrors:
+[*] (10) https://packages-cf.termux.dev/apt/termux-main: ok
+[*] (1) https://mirrors.cbrx.io/apt/termux/termux-main: ok
+[*] (1) https://packages.nscdn.top/termux-main: bad
+[*] (1) https://mirror.nevacloud.com/applications/termux/termux-main: ok
+[*] (1) https://mirror.bardia.tech/termux/termux-main: ok
+[*] (1) https://mirror.albony.xyz/termux/termux-main: ok
+[*] (1) https://linux.domainesia.com/applications/termux/termux-main: ok
+[*] (1) https://mirror.textcord.xyz/termux/termux-main: ok
+[*] (1) https://mirrors.dgut.edu.cn/termux/apt/termux-main: bad
+[*] (1) https://mirrors.cqupt.edu.cn/termux/apt/termux-main: ok
+[*] (1) https://mirror.iscas.ac.cn/termux/apt/termux-main: ok
+[*] (1) https://mirrors.aliyun.com/termux/termux-main: ok
+[*] (1) https://mirrors.bfsu.edu.cn/termux/apt/termux-main: ok
+[*] (1) https://mirrors.nju.edu.cn/termux/apt/termux-main: ok
+[*] (1) https://mirrors.ustc.edu.cn/termux/apt/termux-main: ok
+[*] (1) https://mirrors.pku.edu.cn/termux/termux-main/: ok
+[*] (1) https://mirrors.hit.edu.cn/termux/apt/termux-main: ok
+[*] (1) https://mirrors.sdu.edu.cn/termux/termux-main: ok
+[*] (1) https://mirrors.sau.edu.cn/termux/apt/termux-main: ok
+[*] (1) https://mirrors.tuna.tsinghua.edu.cn/termux/apt/termux-main: ok
+[*] (1) https://mirror.nyist.edu.cn/termux/apt/termux-main: ok
+[*] (1) https://mirrors.njupt.edu.cn/termux/apt/termux-main: bad
+[*] (1) https://mirrors.scau.edu.cn/termux/apt/termux-main: bad
+[*] (1) https://mirrors.sustech.edu.cn/termux/apt/termux-main: ok
+[*] (1) https://mirror.mwt.me/termux/main: ok
+[*] (4) https://grimler.se/termux/termux-main: ok
+[*] (1) https://termux.librehat.com/apt/termux-main: ok
+[*] (1) https://termux.sahilister.in/apt/termux-main: bad
+[*] (1) https://cdn.lumito.net/termux/termux-main: ok
+[*] (1) https://termux.astra.in.ua/apt/termux-main: ok
+[*] (1) https://termux.mentality.rip/termux-main: ok
+[*] (1) https://termux.3san.dev/termux/termux-main: ok
+[*] (1) https://mirror.accum.se/mirror/termux.dev/termux-main: ok
+[*] (1) https://termux.cdn.lumito.net/termux-main: ok
+[*] (1) https://packages.termux.dev/apt/termux-main: ok
+[*] (1) https://mirror.termux.dev/termux-main: ok
+[*] (1) https://md.mirrors.hacktegic.com/termux/termux-main: ok
+[*] (1) https://mirrors.sahilister.in/termux/termux-main: ok
+[*] (4) https://packages.termux.dev/apt/termux-main: ok
+[*] (1) https://plug-mirror.rcac.purdue.edu/termux/termux-main: ok
+[*] (1) https://mirrors.utermux.dev/termux/termux-main: ok
+[*] (1) https://dl.kcubeterm.com/termux-main: ok
+[*] (1) https://mirror.vern.cc/termux/termux-main: ok
+[*] (1) https://mirror.fcix.net/termux/termux-main: ok
+[*] (1) https://mirror.mwt.me/termux/main: ok
+[*] (1) https://mirror.csclub.uwaterloo.ca/termux/termux-main: ok
+[*] (1) https://mirrors.wale.id.au/termux/termux-main: ok
+[*] (1) https://mirror.surf/termux/termux-main/: ok
+[*] (1) http://mirror.mephi.ru/termux/termux-main: ok
+Picking mirror: (3) /data/data/com.termux/files/usr/etc/termux/mirrors/default
+Get:1 https://packages-cf.termux.dev/apt/termux-main stable InRelease [14.0 kB]
+Get:2 https://packages-cf.termux.dev/apt/termux-main stable/main aarch64 Packages [490 kB]
+Fetched 504 kB in 1s (403 kB/s)
+Reading package lists... Done
+Building dependency tree... Done
+Reading state information... Done
+All packages are up to date.
+Reading package lists... Done
+Building dependency tree... Done
+Reading state information... Done
+git is already the newest version (2.39.2).
+wget is already the newest version (1.21.3-5).
+tar is already the newest version (1.34-2).
+coreutils is already the newest version (9.1-2).
+proot is already the newest version (5.1.107-57).
+0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
+Downloading git-annex...
+--2023-03-04 21:36:15--  https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-arm64.tar.gz
+Resolving downloads.kitenet.net... 66.228.36.95
+Connecting to downloads.kitenet.net|66.228.36.95|:443... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 66569031 (63M) [application/x-gzip]
+Saving to: ‘STDOUT’
+
+-             100%  63.48M  6.47MB/s    in 12s
+
+2023-03-04 21:36:27 (5.28 MB/s) - written to stdout [66569031/66569031]
+
+Running on Android.. Tuning for optimal behavior.
+Bad system call
+
+[Process completed (code 159) - press Enter]
diff --git a/doc/forum/Android___34__Bad_system_call__34__/comment_1_d53c57d0f42e3eb5efd6ff5d47b73698._comment b/doc/forum/Android___34__Bad_system_call__34__/comment_1_d53c57d0f42e3eb5efd6ff5d47b73698._comment
new file mode 100644
index 0000000000..cc72e833f8
--- /dev/null
+++ b/doc/forum/Android___34__Bad_system_call__34__/comment_1_d53c57d0f42e3eb5efd6ff5d47b73698._comment
@@ -0,0 +1,94 @@
+[[!comment format=mdwn
+ username="derphysiker"
+ avatar="http://cdn.libravatar.org/avatar/80623354932109c891c2e0ebf523b38f"
+ subject="comment 1"
+ date="2023-03-04T20:45:47Z"
+ content="""
+Ok, this time with a correct syntax ^^:
+
+	~ $ source git-annex-install
+	Installing dependencies with termux pkg manager...
+	Testing the available mirrors:
+	[*] (10) https://packages-cf.termux.dev/apt/termux-main: ok
+	[*] (1) https://mirrors.cbrx.io/apt/termux/termux-main: ok
+	[*] (1) https://packages.nscdn.top/termux-main: bad
+	[*] (1) https://mirror.nevacloud.com/applications/termux/termux-main: ok
+	[*] (1) https://mirror.bardia.tech/termux/termux-main: ok
+	[*] (1) https://mirror.albony.xyz/termux/termux-main: ok
+	[*] (1) https://linux.domainesia.com/applications/termux/termux-main: ok
+	[*] (1) https://mirror.textcord.xyz/termux/termux-main: ok
+	[*] (1) https://mirrors.dgut.edu.cn/termux/apt/termux-main: bad
+	[*] (1) https://mirrors.cqupt.edu.cn/termux/apt/termux-main: ok
+	[*] (1) https://mirror.iscas.ac.cn/termux/apt/termux-main: ok
+	[*] (1) https://mirrors.aliyun.com/termux/termux-main: ok
+	[*] (1) https://mirrors.bfsu.edu.cn/termux/apt/termux-main: ok
+	[*] (1) https://mirrors.nju.edu.cn/termux/apt/termux-main: ok
+	[*] (1) https://mirrors.ustc.edu.cn/termux/apt/termux-main: ok
+	[*] (1) https://mirrors.pku.edu.cn/termux/termux-main/: ok
+	[*] (1) https://mirrors.hit.edu.cn/termux/apt/termux-main: ok
+	[*] (1) https://mirrors.sdu.edu.cn/termux/termux-main: ok
+	[*] (1) https://mirrors.sau.edu.cn/termux/apt/termux-main: ok
+	[*] (1) https://mirrors.tuna.tsinghua.edu.cn/termux/apt/termux-main: ok
+	[*] (1) https://mirror.nyist.edu.cn/termux/apt/termux-main: ok
+	[*] (1) https://mirrors.njupt.edu.cn/termux/apt/termux-main: bad
+	[*] (1) https://mirrors.scau.edu.cn/termux/apt/termux-main: bad
+	[*] (1) https://mirrors.sustech.edu.cn/termux/apt/termux-main: ok
+	[*] (1) https://mirror.mwt.me/termux/main: ok
+	[*] (4) https://grimler.se/termux/termux-main: ok
+	[*] (1) https://termux.librehat.com/apt/termux-main: ok
+	[*] (1) https://termux.sahilister.in/apt/termux-main: bad
+	[*] (1) https://cdn.lumito.net/termux/termux-main: ok
+	[*] (1) https://termux.astra.in.ua/apt/termux-main: ok
+	[*] (1) https://termux.mentality.rip/termux-main: ok
+	[*] (1) https://termux.3san.dev/termux/termux-main: ok
+	[*] (1) https://mirror.accum.se/mirror/termux.dev/termux-main: ok
+	[*] (1) https://termux.cdn.lumito.net/termux-main: ok
+	[*] (1) https://packages.termux.dev/apt/termux-main: ok
+	[*] (1) https://mirror.termux.dev/termux-main: ok
+	[*] (1) https://md.mirrors.hacktegic.com/termux/termux-main: ok
+	[*] (1) https://mirrors.sahilister.in/termux/termux-main: ok
+	[*] (4) https://packages.termux.dev/apt/termux-main: ok
+	[*] (1) https://plug-mirror.rcac.purdue.edu/termux/termux-main: ok
+	[*] (1) https://mirrors.utermux.dev/termux/termux-main: ok
+	[*] (1) https://dl.kcubeterm.com/termux-main: ok
+	[*] (1) https://mirror.vern.cc/termux/termux-main: ok
+	[*] (1) https://mirror.fcix.net/termux/termux-main: ok
+	[*] (1) https://mirror.mwt.me/termux/main: ok
+	[*] (1) https://mirror.csclub.uwaterloo.ca/termux/termux-main: ok
+	[*] (1) https://mirrors.wale.id.au/termux/termux-main: ok
+	[*] (1) https://mirror.surf/termux/termux-main/: ok
+	[*] (1) http://mirror.mephi.ru/termux/termux-main: ok
+	Picking mirror: (3) /data/data/com.termux/files/usr/etc/termux/mirrors/default
+	Get:1 https://packages-cf.termux.dev/apt/termux-main stable InRelease [14.0 kB]
+	Get:2 https://packages-cf.termux.dev/apt/termux-main stable/main aarch64 Packages [490 kB]
+	Fetched 504 kB in 1s (403 kB/s)
+	Reading package lists... Done
+	Building dependency tree... Done
+	Reading state information... Done
+	All packages are up to date.
+	Reading package lists... Done
+	Building dependency tree... Done
+	Reading state information... Done
+	git is already the newest version (2.39.2).
+	wget is already the newest version (1.21.3-5).
+	tar is already the newest version (1.34-2).
+	coreutils is already the newest version (9.1-2).
+	proot is already the newest version (5.1.107-57).
+	0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
+	Downloading git-annex...
+	--2023-03-04 21:36:15--  https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-arm64.tar.gz
+	Resolving downloads.kitenet.net... 66.228.36.95
+	Connecting to downloads.kitenet.net|66.228.36.95|:443... connected.
+	HTTP request sent, awaiting response... 200 OK
+	Length: 66569031 (63M) [application/x-gzip]
+	Saving to: ‘STDOUT’
+	
+	-             100%  63.48M  6.47MB/s    in 12s
+	
+	2023-03-04 21:36:27 (5.28 MB/s) - written to stdout [66569031/66569031]
+	
+	Running on Android.. Tuning for optimal behavior.
+	Bad system call
+	
+	[Process completed (code 159) - press Enter]
+"""]]
diff --git a/doc/forum/Android___34__Bad_system_call__34__/comment_2_74a33b262400ed74a7e0e3bbeac651d5._comment b/doc/forum/Android___34__Bad_system_call__34__/comment_2_74a33b262400ed74a7e0e3bbeac651d5._comment
new file mode 100644
index 0000000000..2cbcce6b22
--- /dev/null
+++ b/doc/forum/Android___34__Bad_system_call__34__/comment_2_74a33b262400ed74a7e0e3bbeac651d5._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-03-06T16:44:33Z"
+ content="""
+Reproduced the same thing on my Pixel 5 with CalyxOS.
+
+My guess as to what has happened is that the arm64 build has been updated
+to use a newer version of glibc etc, and that is trying to use a syscall
+that the Android kernel is too old to support. (Kernel 4.19 in my phone's
+case.)
+
+I suggest you try the Nix-On-Droid installation method instead, if you
+don't really need to use termux.
+
+Opened a bug: [[bugs/Android_termux_install_fails_with_Bad_system_call]]
+"""]]
diff --git a/doc/forum/Android___34__Bad_system_call__34__/comment_3_818a652075a2e283e0be57a11e10a14b._comment b/doc/forum/Android___34__Bad_system_call__34__/comment_3_818a652075a2e283e0be57a11e10a14b._comment
new file mode 100644
index 0000000000..ae23a7641d
--- /dev/null
+++ b/doc/forum/Android___34__Bad_system_call__34__/comment_3_818a652075a2e283e0be57a11e10a14b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-03-10T16:00:29Z"
+ content="""
+Good news, I was able to fix this. Re-run the install and you should get
+the new, working build.
+"""]]
diff --git a/doc/forum/Android_version_does_not_sync.mdwn b/doc/forum/Android_version_does_not_sync.mdwn
new file mode 100644
index 0000000000..4c2d288be9
--- /dev/null
+++ b/doc/forum/Android_version_does_not_sync.mdwn
@@ -0,0 +1,23 @@
+Hey!
+
+I have got a Kindle Fire HD (2nd generation) and want to use Git Annex to sync my data round. However, it does not sync my data at all (my other setups, e.g. PC or laptop do work quite well). The reason for that seems to be quite simple, but I do not know how to fix that:
+
+I always get the warning message:
+
+> TransferScanner crashed: /storage/emulated/legacy/annex/.git/index: copyFile: does not exist (No such file or directory).
+
+I found the same error in the log:
+
+> git-annex: /storage/emulated/legacy/annex/.git/index: copyFile: does not exist (No such file or directory)
+> ...
+> fatal: Run with no arguments or with -c cmd
+> git-annex-shell: git-shell failed
+
+I am using the latest versions for android and arm (server, raspberry pi) from this site from today (13.07.2014)
+
+http://git-annex.branchable.com/install/
+
+I hope somebody can help me. I tried restaring the TransferScanner, restarting git-annex, restarting the OS, resetting the OS (to shipping defaults), nothing helped.
+
+Cheers,
+Stephan
diff --git a/doc/forum/Android_version_does_not_sync/comment_1_ed9e33eef2c6d651847dca9d3f7a63f6._comment b/doc/forum/Android_version_does_not_sync/comment_1_ed9e33eef2c6d651847dca9d3f7a63f6._comment
new file mode 100644
index 0000000000..589b230c39
--- /dev/null
+++ b/doc/forum/Android_version_does_not_sync/comment_1_ed9e33eef2c6d651847dca9d3f7a63f6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="sts"
+ ip="134.147.119.104"
+ subject="comment 1"
+ date="2014-07-14T09:12:13Z"
+ content="""
+Ok, I checked and the index file was missing and not sure why, but I had to manually sync one time. So I had to go in the annex folder with the command line and make a \"git annex sync\". It works pretty well now, it seems not to automatically sync my data (have to force it with \"Sync Now\"), but at least I can sync data to my tablet and thats awesome :).
+"""]]
diff --git a/doc/forum/Android_version_does_not_sync/comment_2_4eafd3e989611f835c489b379bd6ec8a._comment b/doc/forum/Android_version_does_not_sync/comment_2_4eafd3e989611f835c489b379bd6ec8a._comment
new file mode 100644
index 0000000000..bf2b412633
--- /dev/null
+++ b/doc/forum/Android_version_does_not_sync/comment_2_4eafd3e989611f835c489b379bd6ec8a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 2"
+ date="2014-07-14T18:21:15Z"
+ content="""
+How did you create this repository on the android device? Normally a git repository has an index file, unless it has just been manually created with `git init` and has not yet had anything added to it. When the webapp is used to create a repository, it should always leave it with an index file already present.
+"""]]
diff --git a/doc/forum/Android_version_does_not_sync/comment_3_2a4efec37015ea44509e7ed16b36a72d._comment b/doc/forum/Android_version_does_not_sync/comment_3_2a4efec37015ea44509e7ed16b36a72d._comment
new file mode 100644
index 0000000000..71c5b91d19
--- /dev/null
+++ b/doc/forum/Android_version_does_not_sync/comment_3_2a4efec37015ea44509e7ed16b36a72d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnjX_O_VChwfDjcKlcRHbc2Aah8aYQlqts"
+ nickname="Ludovic"
+ subject="comment 3"
+ date="2014-10-05T11:01:39Z"
+ content="""
+I have the same problem.
+I checked again, removed the previous annex/ directory and created a new annex repository from the webapp. No annex/.git/index file is created.
+
+I then add a remore ssh server. The synchronisation fails with the error in the log: \"/storage/emulated/legacy/annex/.git/index: copyFile: does not exist (No such file or directory).\"
+
+Running \"git annex sync\" solved the problem.
+"""]]
diff --git a/doc/forum/Android_version_does_not_sync/comment_4_1ad06842dd96be14e66cde67f32d50f8._comment b/doc/forum/Android_version_does_not_sync/comment_4_1ad06842dd96be14e66cde67f32d50f8._comment
new file mode 100644
index 0000000000..3ae4f77847
--- /dev/null
+++ b/doc/forum/Android_version_does_not_sync/comment_4_1ad06842dd96be14e66cde67f32d50f8._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkyMs6WP6rXEnFqQg9oooOjYZzqO1j9_kE"
+ nickname="John"
+ subject="Same problem here"
+ date="2015-03-29T02:30:36Z"
+ content="""
+**Here's the log right from the first start up after creating a repo, and also the warning I get when I open the webapp:**
+
+[2015-03-29 10:18:01 JST] main: starting assistant version 5.20150327-ge414f2d [2015-03-29 10:18:01 JST] 
+Cronner: You should enable consistency checking to protect your data. (scanning...) 
+
+[2015-03-29 10:18:02 JST] Watcher: Performing startup scan (started...) 
+
+Detected a filesystem without fifo support. 
+
+Disabling ssh connection caching. 
+
+Detected a crippled filesystem. (recording state in git...) error: cannot run git-upload-pack '/storage/extSdCard/annex-sync': No such file or directory fatal: unable to fork
+
+
+**Each time I start the webapp, I get this warning:**
+
+Transfer scanner crashed: /storage/sdcard0/annex/.git/index: copyFile does not exist (No such file or directory)
+
+
+"""]]
diff --git a/doc/forum/Annex_contents_just_disappeared__63__.mdwn b/doc/forum/Annex_contents_just_disappeared__63__.mdwn
new file mode 100644
index 0000000000..d18e2bf91c
--- /dev/null
+++ b/doc/forum/Annex_contents_just_disappeared__63__.mdwn
@@ -0,0 +1,12 @@
+Joey,
+
+I have git-annex now to manage many of the repositories on my system.  I have them both on my local machine, and on a very large file server, and a backup system on the Internet.
+
+Today I went to look at a file in one of my annexes and it wasn't there.  This really surprised me.  But what surprised me most is that around 90% of the files in *all* of my annexes on both my local system and my file server are completely missing.  Only the Internet backup system has them.
+
+How could something like this happen, when I haven't been interacting with these annexes at all during this time?  Can you think of any scenario that might lead to this?  This is pretty much the absolute worst case scenario for an archival data system.
+
+I am running on Mac OS X 10.8, using GHC 7.6.3 to build git-annex, and I keep my git-annex binary updated often.
+
+Thanks,
+  John
diff --git a/doc/forum/Annex_contents_just_disappeared__63__/comment_1_4ab5ca00f912c0c95fabc10f2d9600d3._comment b/doc/forum/Annex_contents_just_disappeared__63__/comment_1_4ab5ca00f912c0c95fabc10f2d9600d3._comment
new file mode 100644
index 0000000000..fe4edbc27c
--- /dev/null
+++ b/doc/forum/Annex_contents_just_disappeared__63__/comment_1_4ab5ca00f912c0c95fabc10f2d9600d3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="comment 1"
+ date="2013-08-23T03:06:00Z"
+ content="""
+Wait, I think this comes from a backend switch.  I changed my .gitattributes file at one point to read:
+
+* annex.backend=SHA512E annex.numcopies=2
+
+I thought this would just affect new files, not existing annexed content.  Could this do it?
+"""]]
diff --git a/doc/forum/Annex_contents_just_disappeared__63__/comment_2_657f737c5d64d440aa133ddb41408fbc._comment b/doc/forum/Annex_contents_just_disappeared__63__/comment_2_657f737c5d64d440aa133ddb41408fbc._comment
new file mode 100644
index 0000000000..e30ff02ca1
--- /dev/null
+++ b/doc/forum/Annex_contents_just_disappeared__63__/comment_2_657f737c5d64d440aa133ddb41408fbc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="comment 2"
+ date="2013-08-23T03:14:15Z"
+ content="""
+Yes, that was the problem, sorry to bother you.  None of my data is gone, it's just sitting there under unknown names.  I can roll back to when it knew the names, and migrate them forward.
+"""]]
diff --git a/doc/forum/Annex_contents_just_disappeared__63__/comment_3_9b4c35feb14b37d43d053d7430da9abf._comment b/doc/forum/Annex_contents_just_disappeared__63__/comment_3_9b4c35feb14b37d43d053d7430da9abf._comment
new file mode 100644
index 0000000000..6c40a1cac9
--- /dev/null
+++ b/doc/forum/Annex_contents_just_disappeared__63__/comment_3_9b4c35feb14b37d43d053d7430da9abf._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 3"
+ date="2013-08-23T04:28:45Z"
+ content="""
+If you change the backend, and then in one repository you run `git annex migrate`, other repositories that have the old keys will not know about the new names. For this reason, then multiple repositories have the files, it's best to run it redundantly in each repository.
+
+TBH, migration is a bit of a PITA because of this. Best to aovid it in most cases.
+
+Git-annex will never perform a migration begind your back. You must have run `git annex migrate` at some point. You can check the git history for details.
+"""]]
diff --git a/doc/forum/Annex_contents_just_disappeared__63__/comment_4_c3625409652bff5f2165260803269a8a._comment b/doc/forum/Annex_contents_just_disappeared__63__/comment_4_c3625409652bff5f2165260803269a8a._comment
new file mode 100644
index 0000000000..236f8cfdef
--- /dev/null
+++ b/doc/forum/Annex_contents_just_disappeared__63__/comment_4_c3625409652bff5f2165260803269a8a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="comment 4"
+ date="2013-08-30T06:06:16Z"
+ content="""
+Just to confirm, this wasn't a git-annex problem at all, but just a misstep during migration as you suggested.
+
+I think what I'm going to do now is to just wipe the slate clean and start over again, by using `unannex -fast` on all the files, wiping `.git`, and then adding everything back in using my new default backend of SHA512E.  The bigger pain is doing the same thing on all the servers where I have this data (to avoid having to upload it again), but in such a way that I'm not replicating file history.  I think I should be able to just clone, `mv $OLDREPO/.git/annex/objects objects`, `git annex add objects`, `git rm -r --cached objects`, and then everything should be good without even needing a new commit on the remote machine, just a git-annex sync.
+"""]]
diff --git a/doc/forum/Annex_dropping_files.mdwn b/doc/forum/Annex_dropping_files.mdwn
new file mode 100644
index 0000000000..7ec19caa15
--- /dev/null
+++ b/doc/forum/Annex_dropping_files.mdwn
@@ -0,0 +1,12 @@
+It seems like one of my repos dropped files by itself, my setup involved 3 distributed repos (non bare repos, not using assistant), A/B/C then one client died I've created another one in its place called D cloned from B and marked C as dead. I have now A/B/D. I have updated files in A synced it to D (central) I then tried dropping unused, it listed none (I've dropped the files from A which has full copy) at this point I thought B did not sync to it maybe thats why it did not drop them. I went home sync my laptop B (B dropped its share of unused files) but cental D still show no unused. 
+
+A-D has full copies of the repo
+B has partial.
+
+At this point I checked out a old commit from a week ago, checked where the links for the files are pointing to, they point to no where files are not there. Repo sized reported with du -hcs show both repos are the same size (132GB) looks like D managed to drop unused files by itself. I am wondering what caused this?
+
+My annex version is,
+
+git-annex version: 4.20130902-g307537a
+
+on all clients.
diff --git a/doc/forum/Annex_dropping_files/comment_1_62fbea95248fda2ff075b5a8952a728f._comment b/doc/forum/Annex_dropping_files/comment_1_62fbea95248fda2ff075b5a8952a728f._comment
new file mode 100644
index 0000000000..3844d3f0d3
--- /dev/null
+++ b/doc/forum/Annex_dropping_files/comment_1_62fbea95248fda2ff075b5a8952a728f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.51"
+ subject="comment 1"
+ date="2013-09-12T21:01:03Z"
+ content="""
+If you have just created repository D and have just copied some files to it, then it will only contain those files, and not old deleted files or old versions of files. You can run `git annex copy --all --to D` to copy all those files to D, although if you're only wanting to dropunused them, there is not much point in that..
+"""]]
diff --git a/doc/forum/Annex_keeps_dropping_content.mdwn b/doc/forum/Annex_keeps_dropping_content.mdwn
new file mode 100644
index 0000000000..d3ff813f85
--- /dev/null
+++ b/doc/forum/Annex_keeps_dropping_content.mdwn
@@ -0,0 +1,9 @@
+I'm experiencing a strange behaviour...
+
+I have a few annexes (local, ssh, gitolite) in my group, some of them  are "manual standard" and some are "backup".
+
+If I 'get' files on my laptop annex and then I 'sync --content' local files are dropped! Local is "manual standard".
+
+Am I doing something wrong?
+
+Thanks
diff --git a/doc/forum/Annex_slow_on_Windows__47__direct_mode.mdwn b/doc/forum/Annex_slow_on_Windows__47__direct_mode.mdwn
new file mode 100644
index 0000000000..57247ac5dd
--- /dev/null
+++ b/doc/forum/Annex_slow_on_Windows__47__direct_mode.mdwn
@@ -0,0 +1,11 @@
+I've been using annex for some weeks now and while I more and more love how it behaves on my Linux machines, I just can't get it working on Windows...
+
+The setup consists of two Ubuntu machines (one being an always-on server) and a Windows laptop I keep for the occasional moment of gaming. My wife's Windows machine is a candidate to join the annex setup, as well as some other computers I still use every now and then.
+
+The first thing I started annexing was my pictures folder. It consists of about 40k files and occupies about 350GB. The Ubuntu server is running a hidden service as a substitute for a DynDNS with ssh basically the only thing going out/in. First, I couldn't get annex to properly sync its data via TOR, but when I instead set up a directory special remote on the server (with the annex repository there being "bare", i.e. not containing any actual data) I got them to sync as they should.
+
+Not the Windows machine though. It's just too slow. It seems that on every sync, every add, every anything it scans... well, everything. I added some files and after an hour I checked the resource monitor which files were being accessed and it seemed to be every last one of the files present in the pictures folder. I'm not sure what's going on there, but it's really getting to the point of being a dealbreaker... I think it's something with annex only supporting direct mode repositories on Windows and all files just lying around (as that's really the only large difference between those setups), although I'm of course not entirely sure.
+
+I'd really like to run annex in indirect mode on Windows. I can't really find any information on that (except those few "official" pages that just state that annex is running in direct mode on Windows). I know that creating symlinks needs elevated priviledges on Windows, but accepting a prompt seems to be much more realistic than waiting hours for a sync.
+
+So... Is there any way to get indirect running on Windows? And if there isn't, is there any other way to speed up direct mode / Windows performance?
diff --git a/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_1_d80839f4582fc2a6269db31e30e1dbab._comment b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_1_d80839f4582fc2a6269db31e30e1dbab._comment
new file mode 100644
index 0000000000..c68c727385
--- /dev/null
+++ b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_1_d80839f4582fc2a6269db31e30e1dbab._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnOSgFb3l7nL3Fs7Y9gPGJJjFiV7aJ1tek"
+ nickname="Phil"
+ subject="Same boat"
+ date="2014-07-03T19:38:15Z"
+ content="""
+I'd love to know this too. I'm setting up on 2 Windows 8.1 machines (with a 3rd Windows 7 hopefully joining the party as well as a couple of Linux boxes) but doing anything is really slow. I just ran git annex status on a 50GB, 7000 file Music repo and it took 6 minutes. I've not even setup the remotes yet but as soon as I'd added and sync'd, things slowed down. I'm running on a nippy SSD and CPU usage is around 12%.
+
+"""]]
diff --git a/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_2_593e1e01b70a2b6a15ad6bca09a80c7b._comment b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_2_593e1e01b70a2b6a15ad6bca09a80c7b._comment
new file mode 100644
index 0000000000..0e357f4d6d
--- /dev/null
+++ b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_2_593e1e01b70a2b6a15ad6bca09a80c7b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnOSgFb3l7nL3Fs7Y9gPGJJjFiV7aJ1tek"
+ nickname="Phil"
+ subject="comment 2"
+ date="2014-07-03T19:39:12Z"
+ content="""
+Fortunately, git annex sync is pretty quick
+"""]]
diff --git a/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_3_c4e4c596f31aa97645fe1e1527dc2c31._comment b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_3_c4e4c596f31aa97645fe1e1527dc2c31._comment
new file mode 100644
index 0000000000..a97ccda2e3
--- /dev/null
+++ b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_3_c4e4c596f31aa97645fe1e1527dc2c31._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 3"
+ date="2014-07-04T20:57:54Z"
+ content="""
+Yall need to tell me your git-annex versions. [[devblog/day_183__rubbing_sticks_together]] fixed a horrible slowdown that indeed causes git-annex on windows to unnecessarily look at lots of files.
+
+Also, is this using the git-annex assistant, or using git-annex at the command line that's being slow?
+
+As to using symlinks on windows, cygwin's build of git is able to handle them somehow. I have not tried to get it working with git-annex, but it seems at least possible that indirect mode could be accomplished that way.
+"""]]
diff --git a/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_4_92db0b99ada9af15a5383da41397ebd7._comment b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_4_92db0b99ada9af15a5383da41397ebd7._comment
new file mode 100644
index 0000000000..39e472606b
--- /dev/null
+++ b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_4_92db0b99ada9af15a5383da41397ebd7._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="171.67.172.69"
+ subject="Also in the same boat"
+ date="2014-07-07T01:12:18Z"
+ content="""
+Even worse here. git-annex looked (and still looks) so promising for exactly I want (share >100GB photos/data with my girlfriend which are on my private DSL connected server but each of us should only download whatever he currently needs for offline usage and everything should stay consistent, e.g. is one edits, adds or deletes files). However, after long testing in Windows I gave up. I had so many issues and speed was one of them. So I looked again at other solutions (ownCloud pydio) but they are not good either. unison is one thing that just works perfectly but it is not suited to sync huge stuff where just parts are available on one machine.
+
+I still put much hope in git-annex that it's useable at some point also in Windows. If there would be another of these kickstarters for that, I'd be in.
+
+One BIG dealbreaker for me is SSH. It popped up a couple of times already there is inconsistency between ssh.exe, plink.exe and %GIT_SSH%.
+But the biggest issue is that ssh.exe in Windows does not do connection sharing: For each single file a new SSH session is created! That way it works only for huge files (movies) where the overhead is small. In my tests I had smaller files, that's just unuseable.
+
+I know it's a conundrum. unison just leaves one ssh connection open, that would be nice. I know however that this requires bigger changes. But what about for example starting something in background (during a git-annex command) that leaves the SSH session open and pumps data via some IPC?
+
+Last but not least: links. I agree windows links are unuseable. But would it really be real links? What about just basic *.lnk files?
+
+
+"""]]
diff --git a/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_5_3d628c9db9ebdfd5bff92af105c47719._comment b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_5_3d628c9db9ebdfd5bff92af105c47719._comment
new file mode 100644
index 0000000000..9b7b166b3a
--- /dev/null
+++ b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_5_3d628c9db9ebdfd5bff92af105c47719._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="171.67.172.69"
+ subject="comment 5"
+ date="2014-07-07T01:16:21Z"
+ content="""
+One more thing: integration in TortoiseGit would be sooooooooo great! You would then even be able to let novice computer users use git-annex.
+
+I added a feature request long time ago but it's on hold: http://code.google.com/p/tortoisegit/issues/detail?id=2166
+
+I do hope that git-annex becomes more popular to increase the chance that it will be built into that...
+
+"""]]
diff --git a/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_6_db7965fa928c093233769ed52b2fcd43._comment b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_6_db7965fa928c093233769ed52b2fcd43._comment
new file mode 100644
index 0000000000..90b6094fa8
--- /dev/null
+++ b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_6_db7965fa928c093233769ed52b2fcd43._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Idhup"
+ ip="178.175.139.138"
+ subject="Connection sharing workaround"
+ date="2014-07-07T10:20:23Z"
+ content="""
+I had the same issues but was able to work around most of them. I simply created keypairs on my Windows machines that allowed me to log in to my Ubuntu server. Means that while the overhead does make it smaller (I guess), the whole sync process can simply be run in the background without me having to check for a password prompt for 30 minutes, just to miss the short period during which I can enter it. Also, the actual object storage was moved to a directory special remote on the server, so Windows clients can simply automount a samba share and push the content over that line, which is less of a hazzle.
+
+Also, the speed issue got *much* better when I added all files. I still had a lot of files just lying around on my Windows machine. Once I added them all, the sync process sped up by several magnitudes. So, if https://git-annex.branchable.com/forum/fatal:_Out_of_memory__63___mmap_failed:_No_such_file_or_directory/ can be solved, I guess I'm happy on Windows.
+"""]]
diff --git a/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_7_674f52c5e5484207db403b18efc986c6._comment b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_7_674f52c5e5484207db403b18efc986c6._comment
new file mode 100644
index 0000000000..2b87a11e01
--- /dev/null
+++ b/doc/forum/Annex_slow_on_Windows__47__direct_mode/comment_7_674f52c5e5484207db403b18efc986c6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Idhup"
+ ip="178.175.139.138"
+ subject="typo"
+ date="2014-07-07T10:23:23Z"
+ content="""
+Slower. It's not smaller, it's slower. Gee.
+"""]]
diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files.mdwn b/doc/forum/Annex_v7_repos_and_plain_git_files.mdwn
new file mode 100644
index 0000000000..16c3b00833
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files.mdwn
@@ -0,0 +1,23 @@
+Hi,
+This is not an issue, more some questions related to my 'legacy' git-annex worklfow which is disturbed with v7 repos.
+
+## The context
+I've got an old repo (initially v5) which has both plain git txt files and annexed binary files. The plain git files don't go through git-annex, only git.
+THis way, I have the classic git history of the txt files, versionning, plus the management of the (big) binaries via git-annex.
+The best of the two worlds.
+
+## The pb
+I converted it to v7, and it is now not possible to add plain git files anymore though 'git add', they are managed by git-annex automatically, probably because of the smudge filter added in .git/info/attributes.
+I understand (and like) this new behaviour, because it avoids adding big binary files though 'git add' by accident. But in this repo, I would like to come back to the old behaviour.
+
+## What I did
+I disabled git-annex smudge filter in the file .git/info/attributes, which is now:
+
+    #* filter=annex
+    .* !filter
+
+## Question at 100000$
+Is this safe ?
+
+## Question 2
+Is there an other way of achieving this (adding plain git files outside git-annex) ?
diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files/comment_1_3bf39b5e6990d4343d9154465d951a77._comment b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_1_3bf39b5e6990d4343d9154465d951a77._comment
new file mode 100644
index 0000000000..64d442c0ad
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_1_3bf39b5e6990d4343d9154465d951a77._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="adding plain git files in v7 repos"
+ date="2020-02-09T18:08:30Z"
+ content="""
+What git-annex version are you using, and what are your git config settings?  In the current version, if `annex.largefiles` is not set, or if `annex.gitaddtoannex` is set to `false`, `git add` should [[add all files to plain git|forum/lets_discuss_git_add_behavior/#comment-37e0ecaf8e0f763229fd7b8ee9b5a577]].
+"""]]
diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files/comment_2_a0628a013b57c00ea449b40b93edd385._comment b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_2_a0628a013b57c00ea449b40b93edd385._comment
new file mode 100644
index 0000000000..37efa8fa08
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_2_a0628a013b57c00ea449b40b93edd385._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 2"
+ date="2020-02-09T22:59:35Z"
+ content="""
+Thks for pointing me to the \"git add v7\" very interesting thread. It explains everything.
+
+I'm using git-annex version: 7.20190912 (the default in Ubuntu 19.10 packages).
+
+Neither annex.gitaddtoannex nor annex.largefiles were set in my repo. In this version, I have to set annex.largefiles to \"nothing\" to get the expected behaviour, annex.gitaddtoannex true/false does not change anything. Of course, I verified this behaviour in a fresh new repo without any config change/hack.
+
+But even if annex.gitaddtoannex does not change anything right now, I'll set it to false, in case later version of git-annex uses it.
+
+"""]]
diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files/comment_3_6095eaa58aa298aca72237381f567ffb._comment b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_3_6095eaa58aa298aca72237381f567ffb._comment
new file mode 100644
index 0000000000..04edbe35aa
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_3_6095eaa58aa298aca72237381f567ffb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="updating git-annex"
+ date="2020-02-10T00:05:00Z"
+ content="""
+You can use [[install/conda]] to install a recent git-annex version that supports `annex.gitaddtoannex`.
+"""]]
diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files/comment_4_fd1a3658ed6f3b6af2297c768b3f1ac2._comment b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_4_fd1a3658ed6f3b6af2297c768b3f1ac2._comment
new file mode 100644
index 0000000000..4754643883
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_4_fd1a3658ed6f3b6af2297c768b3f1ac2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="git-annex ubuntu package"
+ date="2020-02-10T02:07:10Z"
+ content="""
+P.S. It's a bit concerning if 7.20190912 is the default git-annex version in a common distro: it's the version most likely to confuse users with the changed `git add` behavior.  Can this be fixed?  Is it definitely the default version?   I don't know much about Ubuntu packaging, but from [https://packages.ubuntu.com/](https://packages.ubuntu.com/), 19.10 (`focal`) seems to have version [7.20191230](https://packages.ubuntu.com/focal/utils/git-annex)?
+"""]]
diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files/comment_5_f47fec91d4ceebe653bc3fb221e2f8df._comment b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_5_f47fec91d4ceebe653bc3fb221e2f8df._comment
new file mode 100644
index 0000000000..34b1aa52ac
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_5_f47fec91d4ceebe653bc3fb221e2f8df._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 5"
+ date="2020-02-10T10:10:06Z"
+ content="""
+Thks for pointing me to Conda, I didn't know it.
+
+About Ubuntu 19.10 old git-annex package, it seems I have the expected revision. I rarely mess with the package manager (only nvidia drivers!), so I don't expect any issue there.
+
+<https://ubuntu.pkgs.org/19.10/ubuntu-universe-amd64/git-annex_7.20190912-1_amd64.deb.html>
+<https://packages.ubuntu.com/eoan/git-annex>
+
+Yes, I agree, my git-annex package is an old one. Ubuntu is supposed to be a stable main stream distro, so optional packages like git-annex are not the cutting edge ones. And 19.10 is not a LTS release, you can expect the situation to be worse on 18.04 LTS. Same on Debian, Raspbian etc...
+
+
+"""]]
diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files/comment_6_21648eecfaf9673b25d40327d11f7b59._comment b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_6_21648eecfaf9673b25d40327d11f7b59._comment
new file mode 100644
index 0000000000..7dc724bf5c
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_6_21648eecfaf9673b25d40327d11f7b59._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="default git-annex version in distros"
+ date="2020-02-10T18:55:29Z"
+ content="""
+\"you can expect the situation to be worse on 18.04 LTS\" -- if the default version there is before 7.20190912 there is no chance of user confusion, only versions 7.20190912 through 7.20191017 can cause it.  I take it it's not possible to change the default version included in existing distributions?  Sorry, don't know how Ubuntu/Debian packaging works...
+"""]]
diff --git a/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__.mdwn b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__.mdwn
new file mode 100644
index 0000000000..389201f60c
--- /dev/null
+++ b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__.mdwn
@@ -0,0 +1,10 @@
+Hello
+
+Is OpenBSD support on the roadmap for the near future?
+Both cabal and stack are problematic on OpenBSD (for now). 
+
+I revisit this issue once in a while and while it is literally the last thing keeping me on Linux, my whole daily workflow revolves around git-annex, so I can't be without it. I also can't have it break on me every time I will need to update.
+
+Just wanted to know if anybody else had success or if a more formal way of installation on OpenBSD is in the cards.
+
+Thanks a lot
diff --git a/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_1_0d87a7d0f6ae556deb999403a2fb5461._comment b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_1_0d87a7d0f6ae556deb999403a2fb5461._comment
new file mode 100644
index 0000000000..b84bfc11f5
--- /dev/null
+++ b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_1_0d87a7d0f6ae556deb999403a2fb5461._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-08-17T20:16:02Z"
+ content="""
+People have told me once or twice that they were able to build git-annex on
+openbsd using stack. If it doesn't build, file a bug (unless it's clearly a
+toolchain/OS issue).
+
+If someone can confirm it builds, I could try to set up an openbsd
+autobuilder in a VM. But I have no openbsd experience so would probably
+need some hand-holding.
+"""]]
diff --git a/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_2_c7fc9be88dad09f71774664b233bc8a3._comment b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_2_c7fc9be88dad09f71774664b233bc8a3._comment
new file mode 100644
index 0000000000..d04ed82d62
--- /dev/null
+++ b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_2_c7fc9be88dad09f71774664b233bc8a3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="hobbes@b2cacef69071743c3a831e60511062f7e014e52f"
+ nickname="hobbes"
+ avatar="http://cdn.libravatar.org/avatar/44b70169c4d862b3619812c360aa8f1e"
+ subject="Building with OpenBSD"
+ date="2018-08-23T19:30:09Z"
+ content="""
+I have successfully built git-annex using plain cabal on OpenBSD, and ran into significant problems using stack.
+
+The main thing was that I needed to add a lot of swap space, and the build took forever. Running out of memory pretty much just killed the machine. I would love to have an official build available. Would make my life easier too, and put the effort in one place.
+"""]]
diff --git a/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_3_89330ea5d2754d59766a096e0c35d791._comment b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_3_89330ea5d2754d59766a096e0c35d791._comment
new file mode 100644
index 0000000000..90969aaf85
--- /dev/null
+++ b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_3_89330ea5d2754d59766a096e0c35d791._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="bnyn"
+ avatar="http://cdn.libravatar.org/avatar/086ca5cb07dc2022f472433c1c5edac1"
+ subject="Update"
+ date="2018-09-11T19:29:39Z"
+ content="""
+Hey joey (and anyone else struggling to compile on OpenBSD)
+
+Just thought I'd give you this update. Git annex now successfully builds for me on OpenBSD 6.3
+I think a recent change regarding the building without assistant fixed it.
+I was playing around with constraints to try to force my way around problematic hackage package versions and decided to start from scrap a couple of days later.
+6.20180808 then simply worked for me. 
+
+Please be aware that I built using cabal with the following flags, otherwise as per the instructions on the \"fromsource\" page here.
+\"-s3 -webdav -assistant -webapp -pairing -torrentparser -magicmime -dbus\"
+
+I don't know if you have intentionally worked on support for the BSDs or another fix applied here as well, but it works now. 
+Thanks a lot, joey! I really appreciate this.
+"""]]
diff --git a/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_4_4cfc6b550dfb24c8468df97428d2cf8a._comment b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_4_4cfc6b550dfb24c8468df97428d2cf8a._comment
new file mode 100644
index 0000000000..63b5df5aba
--- /dev/null
+++ b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_4_4cfc6b550dfb24c8468df97428d2cf8a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-10-08T16:39:42Z"
+ content="""
+I feel that the best thing to do would be for someone to set up an
+autobuilder on openbsd, ideally someone who can be somewhat trusted by
+people in the openbsd community -- and then this site can link to those
+builds.
+"""]]
diff --git a/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_5_82ce026c2dc9627ca2f1563caedfa458._comment b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_5_82ce026c2dc9627ca2f1563caedfa458._comment
new file mode 100644
index 0000000000..1b1adb92ec
--- /dev/null
+++ b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_5_82ce026c2dc9627ca2f1563caedfa458._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="falsifian"
+ avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae"
+ subject="comment 5"
+ date="2021-03-14T05:12:12Z"
+ content="""
+git-annex is now in OpenBSD ports. If you're running current, you can just run `pkg_add git-annex`.
+"""]]
diff --git a/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_6_dfca53829fbe845f7f56e35638faf9fc._comment b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_6_dfca53829fbe845f7f56e35638faf9fc._comment
new file mode 100644
index 0000000000..e6a6d3c763
--- /dev/null
+++ b/doc/forum/Any_plan_for___40__official__41___OpenBSD_support__63__/comment_6_dfca53829fbe845f7f56e35638faf9fc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-03-22T18:35:22Z"
+ content="""
+Oh that's nice news! Thanks falsifian and blackgnezdo
+for adding it. Added to the install page.
+"""]]
diff --git a/doc/forum/Any_way_to_add_a_folder_called___34__.git__34___to_git-annex__63__.mdwn b/doc/forum/Any_way_to_add_a_folder_called___34__.git__34___to_git-annex__63__.mdwn
new file mode 100644
index 0000000000..425301a0da
--- /dev/null
+++ b/doc/forum/Any_way_to_add_a_folder_called___34__.git__34___to_git-annex__63__.mdwn
@@ -0,0 +1,9 @@
+I'm trying to use git-annex as a way to sync fairly large folders between machines. These folders contain documents, projects, ...
+
+There are several issues with files that just won't get added to my git-annex repository:
+
+- files mentioned in .gitignore are not added -- this is good.
+- files starting with a dot are not added unless I explicitly mention them to git add -- this is strange, but I can work around it.
+- folders called .git/ are not added no matter what I try. git annex add --force doesn't help, either.
+
+Any idea how I could solve the third issue? It might not even be specific to git-annex... maybe git just works that way... but I'd be grateful for hints.
diff --git a/doc/forum/Any_way_to_add_a_folder_called___34__.git__34___to_git-annex__63__/comment_1_51f4392e718d857e2f155d6217727a53._comment b/doc/forum/Any_way_to_add_a_folder_called___34__.git__34___to_git-annex__63__/comment_1_51f4392e718d857e2f155d6217727a53._comment
new file mode 100644
index 0000000000..3aecd39881
--- /dev/null
+++ b/doc/forum/Any_way_to_add_a_folder_called___34__.git__34___to_git-annex__63__/comment_1_51f4392e718d857e2f155d6217727a53._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlq4ClC5EMN1Vq1DpWXAqP5TiDnCK1mSfk"
+ nickname="Jonas"
+ subject="comment 1"
+ date="2014-01-09T22:58:30Z"
+ content="""
+I just found [this thread](http://git-annex.branchable.com/forum/Tracking_a_directory_with_some_hg_and_git_repositories/) where a user was discouraged from syncing git repositories with annex.
+
+I've used unison in the past for this. Sure, it would occasionally create a few unneeded object files; but these got removed during the next \"git gc\", and never corrupted a repository... Do people know of any better way to handle this problem?
+"""]]
diff --git a/doc/forum/Any_way_to_add_a_folder_called___34__.git__34___to_git-annex__63__/comment_2_9698c4a8f0d8785ee89a6228e0e85ca9._comment b/doc/forum/Any_way_to_add_a_folder_called___34__.git__34___to_git-annex__63__/comment_2_9698c4a8f0d8785ee89a6228e0e85ca9._comment
new file mode 100644
index 0000000000..0c933fe312
--- /dev/null
+++ b/doc/forum/Any_way_to_add_a_folder_called___34__.git__34___to_git-annex__63__/comment_2_9698c4a8f0d8785ee89a6228e0e85ca9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~timo-linux"
+ nickname="Tim O'Callaghan"
+ subject="How about automatically adding it as a submodule?"
+ date="2014-01-11T10:30:57Z"
+ content="""
+Adding as a submodule and automatically adding the annexe destination as a remote? that should work in most cases..
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon.mdwn b/doc/forum/Apple_M1_Silicon.mdwn
new file mode 100644
index 0000000000..1d2f6383e6
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon.mdwn
@@ -0,0 +1 @@
+I'm reaching out about an estimated ETA for Apple M1 support. I hear that there isn't yet a Haskell compiler for Apple Silicon. Any rough ideas about when this might be expected? 
diff --git a/doc/forum/Apple_M1_Silicon/comment_10_5646c616f1897c797ce383f6d4210ce4._comment b/doc/forum/Apple_M1_Silicon/comment_10_5646c616f1897c797ce383f6d4210ce4._comment
new file mode 100644
index 0000000000..6a7179d56d
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_10_5646c616f1897c797ce383f6d4210ce4._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 10"
+ date="2021-07-05T07:07:34Z"
+ content="""
+Thanks, but it's still not working for me (tried twice):
+
+    Last 15 lines from /Users/md/Library/Logs/Homebrew/git-annex/02.cabal:
+    Currently only 10 to 12 is supported. System LLVM version: 12.0.0
+    We will try though...
+    [518 of 668] Compiling Command.InAnnex  ( Command/InAnnex.hs, dist/build/git-annex/git-annex-tmp/Command/InAnnex.o, dist/build/git-annex/git-annex-tmp/Command/InAnnex.dyn_o )
+    You are using an unsupported version of LLVM!
+    Currently only 10 to 12 is supported. System LLVM version: 12.0.0
+    We will try though...
+    clang: error: unable to execute command: posix_spawn failed: Resource temporarily unavailable
+
+    <no location info>: error:
+    Error running clang! you need clang installed to use the LLVM backend
+    (or GHC tried to execute clang incorrectly)
+    `clang' failed in phase `Clang (Assembler)'. (Exit code: 1)
+
+But perhaps a bottle is not that far away now.
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_11_72129be313d82db95d4fe109793fc3fc._comment b/doc/forum/Apple_M1_Silicon/comment_11_72129be313d82db95d4fe109793fc3fc._comment
new file mode 100644
index 0000000000..3c5385d915
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_11_72129be313d82db95d4fe109793fc3fc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nowkixide"
+ avatar="http://cdn.libravatar.org/avatar/6268f09b18a71aafa3ad68ecd8a20d50"
+ subject="Works fine"
+ date="2022-03-07T12:07:54Z"
+ content="""
+`brew install --build-from-source git-annex` took around 25 minutes on M1 Pro (10 core) and passed `git annex test`.
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_12_b62bcd53f260613fc9043008f0e9df19._comment b/doc/forum/Apple_M1_Silicon/comment_12_b62bcd53f260613fc9043008f0e9df19._comment
new file mode 100644
index 0000000000..de9c8d06b5
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_12_b62bcd53f260613fc9043008f0e9df19._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/2098ac7f-d1c7-413d-8a8a-b7d0d7704ea3"
+ nickname="John Johnson"
+ avatar="http://cdn.libravatar.org/avatar/c8c5edfe8807402d0aa97d66ebbe3bb3710278666cbc5284c0a9ed41db1001e3"
+ subject="No bueno"
+ date="2022-03-29T22:29:21Z"
+ content="""
+Not working for me.
+Cabal runs for a while, then it error out complaining about magic and c libraries for magic.
+I can't find any source of this magic.
+I've installed Haskell-stack, and a lot of other things I'll never use.
+I just need git-annex :-)
+
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_13_c4ea06ee4c929f171eb6eaea0947bfe7._comment b/doc/forum/Apple_M1_Silicon/comment_13_c4ea06ee4c929f171eb6eaea0947bfe7._comment
new file mode 100644
index 0000000000..7203af1b06
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_13_c4ea06ee4c929f171eb6eaea0947bfe7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 13"
+ date="2022-03-30T13:10:48Z"
+ content="""
+Nixpkgs has great support for aarch64-darwin. git-annex is working perfectly fine.
+
+https://nixos.org/download.html#nix-install-macos
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_14_540e6d6f579174bb953824817f5822aa._comment b/doc/forum/Apple_M1_Silicon/comment_14_540e6d6f579174bb953824817f5822aa._comment
new file mode 100644
index 0000000000..6256ce0682
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_14_540e6d6f579174bb953824817f5822aa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2022-03-30T16:55:25Z"
+ content="""
+If you want to use cabal to
+build git-annex, you need to follow the instructions. Specifically,
+[[install/fromsource]] which has a cabal section, which documents using
+"-magicmime" specifically to avoid such a build failure.
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_1_e2aaf539d43951a20ea48d827082fe83._comment b/doc/forum/Apple_M1_Silicon/comment_1_e2aaf539d43951a20ea48d827082fe83._comment
new file mode 100644
index 0000000000..d62054318f
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_1_e2aaf539d43951a20ea48d827082fe83._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-02-01T16:26:02Z"
+ content="""
+Last I saw, someone had gotten ghc built for the platform in December.
+I suppose there will be other toolchain changes needed but that seems
+fairly promising.
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_2_eeed553a1684f0b4ed07e5a7de62db5f._comment b/doc/forum/Apple_M1_Silicon/comment_2_eeed553a1684f0b4ed07e5a7de62db5f._comment
new file mode 100644
index 0000000000..ac30c47586
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_2_eeed553a1684f0b4ed07e5a7de62db5f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="DeweyA123"
+ avatar="http://cdn.libravatar.org/avatar/4f5483bab48a5f33af5d6040709b63c5"
+ subject="Waiting as well"
+ date="2021-04-12T15:12:04Z"
+ content="""
+I am also curious, it's a tool that I use on a daily basis and I'm just wondering where this is at. 
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_3_bed7d9e5565c6bb462e2ba8f4d815725._comment b/doc/forum/Apple_M1_Silicon/comment_3_bed7d9e5565c6bb462e2ba8f4d815725._comment
new file mode 100644
index 0000000000..06db6f1516
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_3_bed7d9e5565c6bb462e2ba8f4d815725._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="cecile.madjar@d95f9e618c3dff4829e7fedba1a71e1499542f3f"
+ nickname="cecile.madjar"
+ avatar="http://cdn.libravatar.org/avatar/a32ab97180285c0e5095bad4616a4d87"
+ subject="comment 3"
+ date="2021-05-04T20:24:50Z"
+ content="""
+Hello,
+
+Is there any updates on this? I am using an Apple M1 Silicon and I am blocked in all my projects because I cannot install git-annex on my computer. Do you have an approximate idea of when this would be available for Apple M1 Silicon users?
+
+Thank you,
+
+
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_4_07c410bacefa5da582ce2064ef345def._comment b/doc/forum/Apple_M1_Silicon/comment_4_07c410bacefa5da582ce2064ef345def._comment
new file mode 100644
index 0000000000..5c327a061d
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_4_07c410bacefa5da582ce2064ef345def._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 4"
+ date="2021-05-04T20:38:01Z"
+ content="""
+Hmm, shouldn't it work just fine with rosetta?
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_5_2efc89b2c4f3ff408ccd015f297d743b._comment b/doc/forum/Apple_M1_Silicon/comment_5_2efc89b2c4f3ff408ccd015f297d743b._comment
new file mode 100644
index 0000000000..b252568096
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_5_2efc89b2c4f3ff408ccd015f297d743b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="cecile.madjar@d95f9e618c3dff4829e7fedba1a71e1499542f3f"
+ nickname="cecile.madjar"
+ avatar="http://cdn.libravatar.org/avatar/a32ab97180285c0e5095bad4616a4d87"
+ subject="comment 5"
+ date="2021-05-04T21:12:52Z"
+ content="""
+Thank you Lukey. Indeed, after installing Rosetta2 it worked. Thank you!
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_6_0fc6e261c00f1df8698c92c8de6f3a27._comment b/doc/forum/Apple_M1_Silicon/comment_6_0fc6e261c00f1df8698c92c8de6f3a27._comment
new file mode 100644
index 0000000000..4d87f91e97
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_6_0fc6e261c00f1df8698c92c8de6f3a27._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 6"
+ date="2021-05-07T20:00:07Z"
+ content="""
+Seeing some strange things lately, I believe it started after updating to macOS 11.3. Some git annex commands work fine (like `git annex àdd` or copying to a remote), others (like `git annex sync`, the webapp) throw errors like this:
+
+    git-annex(55965,0x2046f9e00) malloc: can't allocate region
+    :*** mach_vm_map(size=1048576, flags: 100) failed (error code=268435465)
+    git-annex(55965,0x2046f9e00) malloc: *** set a breakpoint in malloc_error_break to debug
+    git-annex: git: createProcess: runInteractiveProcess: exec: resource exhausted (Cannot allocate memory)
+
+I'm using `8.20210331-g1fb59a63a` from the .dmg provided here. I realize it's a bit of a hack setup so I haven't really investigated much yet, just wondering if someone knows what may be going on.
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_7_c60e046cb8b138aee16af2d4c66c803c._comment b/doc/forum/Apple_M1_Silicon/comment_7_c60e046cb8b138aee16af2d4c66c803c._comment
new file mode 100644
index 0000000000..bb86bc3f2d
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_7_c60e046cb8b138aee16af2d4c66c803c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 7"
+ date="2021-05-19T06:33:02Z"
+ content="""
+Update: To me, this seems to be related to Apple's System Integrity Protection somehow, maybe related to the OS upgrade.
+
+Manually whitelisting the entire contents of the application package under \"Full Disk Access\" seemed to help, at first. But then various commands were still a no-go, as per above. Perhaps because some of the tooling overlap with Homebrew etc.
+
+Maybe if I was just using the webapp I could try again and reinstall everything, but as my needs are more specific I eventually gave up and will wait for proper support. Shouldn't be too far off now.
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_8_4620929361fb5ad8faea15ed3905d67f._comment b/doc/forum/Apple_M1_Silicon/comment_8_4620929361fb5ad8faea15ed3905d67f._comment
new file mode 100644
index 0000000000..b367ad6fc5
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_8_4620929361fb5ad8faea15ed3905d67f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 8"
+ date="2021-06-25T15:07:54Z"
+ content="""
+Using my M1 Air a lot more these days, not having git-annex is a pain. The Homebrew formula dependencies all have ARM bottles at this point, but building from source fails (criterion-measurement-0.1.2.0). Anyone with ideas on how to end up with a working Rosetta 2 setup? My previous experiments were a mess (see above), no doubt partly due to an environment where multiple versions of various components are conflicting with each other. 
+"""]]
diff --git a/doc/forum/Apple_M1_Silicon/comment_9_d77519ba5ca217cb3ec6348567731b9d._comment b/doc/forum/Apple_M1_Silicon/comment_9_d77519ba5ca217cb3ec6348567731b9d._comment
new file mode 100644
index 0000000000..d61fd0422e
--- /dev/null
+++ b/doc/forum/Apple_M1_Silicon/comment_9_d77519ba5ca217cb3ec6348567731b9d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="css@fcd6583660cae4ea6565f44f31443feb8e131139"
+ nickname="css"
+ avatar="http://cdn.libravatar.org/avatar/029af00c2f4a43194d6993d4cd2283e3"
+ subject="comment 9"
+ date="2021-07-05T03:17:39Z"
+ content="""
+A new version of criterion-measurement is out with support for Apple Silicon, it's possible to install git-annex via Homebrew now. No bottle is available as of yet but building from source works fine. 
+"""]]
diff --git a/doc/forum/Archive_USB_drive_not_working_as_documented.mdwn b/doc/forum/Archive_USB_drive_not_working_as_documented.mdwn
new file mode 100644
index 0000000000..73c2db6de2
--- /dev/null
+++ b/doc/forum/Archive_USB_drive_not_working_as_documented.mdwn
@@ -0,0 +1,171 @@
+I'm hoping to use git-annex in a project to manage large image files and maintain archived copies of them on removable USB drives. But I can't get this to work the way it's described in the walkthrough and in the "git-annex/tips/offline archive drives" example. Here's what I did:
+
+    marshal@home[~]> git-annex version
+    git-annex version: 5.20140412ubuntu1
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external
+
+Create the local repo:
+
+    marshal@home[~]> mkdir ~/annex
+    marshal@home[~]> cd ~/annex
+    marshal@home[~/annex]> git init
+    Initialized empty Git repository in /home/marshal/annex/.git/
+    marshal@home[~/annex]> git annex init "my laptop"
+    init my laptop ok
+    (Recording state in git...)
+
+Create the remote repo (assume the warning can be ignored?)
+
+    marshal@home[~/annex]> cd /media/marshal/Sony\ USB/
+    marshal@home[/media/marshal/Sony USB]> git clone ~/annex
+    Cloning into 'annex'...
+    done.
+    warning: remote HEAD refers to nonexistent ref, unable to checkout.
+    marshal@home[/media/marshal/Sony USB]> cd annex
+    marshal@home[/media/marshal/Sony USB/annex]> git annex init "usbdrive"
+    init usbdrive ok
+    (Recording state in git...)
+
+Make them remotes of each other
+
+    marshal@home[/media/marshal/Sony USB/annex]> git remote add laptop ~/annex
+    marshal@home[/media/marshal/Sony USB/annex]> cd ~/annex
+    marshal@home[~/annex]> git remote add usbdrive /media/marshal/Sony\ USB/annex/
+
+Add some files into the local repo
+
+    marshal@home[~/annex]> cp ~/Desktop/file* .
+    marshal@home[~/annex]> git annex add .
+    add file1.m3u ok
+    add file2.sh ok
+    add file3.pdf ok
+    (Recording state in git...)
+    marshal@home[~/annex]> git commit -a -m "added files"
+    [master (root-commit) 4ea3be7] added files
+     3 files changed, 3 insertions(+)
+     create mode 120000 file1.m3u
+     create mode 120000 file2.sh
+     create mode 120000 file3.pdf
+
+Change the preferred content settings
+
+    marshal@home[~/annex]> git annex group usbdrive archive
+    group usbdrive ok
+    (Recording state in git...)
+    marshal@home[~/annex]> git annex wanted usbdrive standard
+    wanted usbdrive ok
+    (Recording state in git...)
+
+Sync to the usbdrive repo
+
+    marshal@home[~/annex]> git annex sync usbdrive
+    commit  ok
+    pull usbdrive 
+    remote: Counting objects: 7, done.
+    remote: Compressing objects: 100% (3/3), done.
+    remote: Total 5 (delta 1), reused 0 (delta 0)
+    Unpacking objects: 100% (5/5), done.
+    From /media/marshal/Sony USB/annex
+     * [new branch]      git-annex  -> usbdrive/git-annex
+    ok
+    (merging usbdrive/git-annex into git-annex...)
+    (Recording state in git...)
+    push usbdrive 
+    Counting objects: 29, done.
+    Delta compression using up to 8 threads.
+    Compressing objects: 100% (22/22), done.
+    Writing objects: 100% (25/25), 2.44 KiB | 0 bytes/s, done.
+    Total 25 (delta 3), reused 0 (delta 0)
+    To /media/marshal/Sony USB/annex/
+     * [new branch]      git-annex -> synced/git-annex
+     * [new branch]      master -> synced/master
+    ok
+
+Copy eveything to the usbdrive repo
+
+    marshal@home[~/annex]> git-annex copy --auto --to usbdrive
+    copy file1.m3u (to usbdrive...) 
+    SHA256E-s64061--c388e2c927cb4c88c11b1b5a8e166c4d8080dc528d53954dad1ee6d4933ce3c7.m3u
+             64,061 100%   29.84MB/s    0:00:00 (xfr#1, to-chk=0/1)
+    ok
+    copy file2.sh (to usbdrive...) 
+    SHA256E-s318--b8729560cc759d2256903feaa4ba65994ccbac94f30515d52a39083ad52e1bad.sh
+                318 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+    ok
+    copy file3.pdf (to usbdrive...) 
+    SHA256E-s32239--9b051067d5ef9f0cb4a01750901bf6bee3f9348e5b10138c8ef416ac8d51e5df.pdf
+             32,239 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+    ok
+    (Recording state in git...)
+
+Check to see where git-annex "thinks" the files are
+
+    marshal@home[~/annex]> git-annex whereis file1.m3u 
+    whereis file1.m3u (2 copies) 
+          	80fa5a68-3843-4e25-b4c9-53a8c51ba9ff -- here (my laptop)
+           	d642b276-5f9b-4a5c-a42e-ea29cd9540b5 -- usbdrive
+    ok
+
+Check the filesystem results
+
+    marshal@home[~/annex]> ls -la ~/annex
+    total 48
+    drwxrwxr-x  3 marshal marshal  4096 Jul 19 14:59 .
+    drwxr-xr-x 99 marshal marshal 24576 Jul 19 14:55 ..
+    lrwxrwxrwx  1 marshal marshal   194 Jul 19 14:59 file1.m3u -> .git/annex/objects/jq/MW/SHA256E-s64061--c388e2c927cb4c88c11b1b5a8e166c4d8080dc528d53954dad1ee6d4933ce3c7.m3u/SHA256E-s64061--c388e2c927cb4c88c11b1b5a8e166c4d8080dc528d53954dad1ee6d4933ce3c7.m3u
+    lrwxrwxrwx  1 marshal marshal   188 Jul 19 14:59 file2.sh -> .git/annex/objects/1J/2K/SHA256E-s318--b8729560cc759d2256903feaa4ba65994ccbac94f30515d52a39083ad52e1bad.sh/SHA256E-    s318--b8729560cc759d2256903feaa4ba65994ccbac94f30515d52a39083ad52e1bad.sh
+    lrwxrwxrwx  1 marshal marshal   194 Jul 19 14:59 file3.pdf -> .git/annex/objects/77/Wj/SHA256E-s32239--9b051067d5ef9f0cb4a01750901bf6bee3f9348e5b10138c8ef416ac8d51e5df.pdf/SHA256E-s32239--9b051067d5ef9f0cb4a01750901bf6bee3f9348e5b10138c8ef416ac8d51e5df.pdf
+    drwxrwxr-x  9 marshal marshal  4096 Jul 19 15:04 .git
+    marshal@home[~/annex]> ls -la /media/marshal/Sony\ USB/annex/
+    total 4
+    drwx------ 1 marshal marshal  144 Jul 19 14:56 .
+    drwx------ 1 marshal marshal 4096 Jul 19 14:56 ..
+    drwx------ 1 marshal marshal  448 Jul 19 14:57 .git
+
+Why is there nothing in the usbdrive repo? And worse, why is the whereis command saying there are 2 copies?
+
+But if I sync from the usbdrive repo, the files are copied
+
+    marshal@home[~/annex]> cd /media/marshal/Sony\ USB/annex/
+    marshal@home[/media/marshal/Sony USB/annex]> git-annex sync laptop
+    (merging synced/git-annex origin/git-annex into git-annex...)
+    (Recording state in git...)
+    commit  ok
+    pull laptop 
+    remote: Counting objects: 23, done.
+    remote: Compressing objects: 100% (8/8), done.
+    remote: Total 11 (delta 3), reused 0 (delta 0)
+    Unpacking objects: 100% (11/11), done.
+    From /home/marshal/annex
+     * [new branch]      git-annex  -> laptop/git-annex
+     * [new branch]      master     -> laptop/master
+     * [new branch]      synced/master -> laptop/synced/master
+    
+    
+    Already up-to-date.
+    ok
+    (merging laptop/git-annex into git-annex...)
+    (Recording state in git...)
+    push laptop 
+    Counting objects: 56, done.
+    Delta compression using up to 8 threads.
+    Compressing objects: 100% (24/24), done.
+    Writing objects: 100% (33/33), 2.34 KiB | 0 bytes/s, done.
+    Total 33 (delta 15), reused 0 (delta 0)
+    To /home/marshal/annex
+     * [new branch]      git-annex -> synced/git-annex
+    ok
+    marshal@home[/media/marshal/Sony USB/annex]> ls -la /media/marshal/Sony\ USB/annex/
+    total 6
+    drwx------ 1 marshal marshal  456 Jul 19 15:07 .
+    drwx------ 1 marshal marshal 4096 Jul 19 14:56 ..
+    lrwxrwxrwx 1 marshal marshal  396 Jul 19 15:07 file1.m3u -> .git/annex/objects/jq/MW/SHA256E-s64061--c388e2c927cb4c88c11b1b5a8e166c4d8080dc528d53954dad1ee6d4933ce3c7.m3u/SHA256E-s64061--c388e2c927cb4c88c11b1b5a8e166c4d8080dc528d53954dad1ee6d4933ce3c7.m3u
+    lrwxrwxrwx 1 marshal marshal  384 Jul 19 15:07 file2.sh -> .git/annex/objects/1J/2K/SHA256E-s318--b8729560cc759d2256903feaa4ba65994ccbac94f30515d52a39083ad52e1bad.sh/SHA256E-s318--b8729560cc759d2256903feaa4ba65994ccbac94f30515d52a39083ad52e1bad.sh
+    lrwxrwxrwx 1 marshal marshal  396 Jul 19 15:07 file3.pdf -> .git/annex/objects/77/Wj/SHA256E-s32239--9b051067d5ef9f0cb4a01750901bf6bee3f9348e5b10138c8ef416ac8d51e5df.pdf/SHA256E-s32239--9b051067d5ef9f0cb4a01750901bf6bee3f9348e5b10138c8ef416ac8d51e5df.pdf
+    drwx------ 1 marshal marshal  448 Jul 19 15:07 .git
+
+Why did I have to sync from the usbdrive? I expected the repo setup and the --auto option to copy the files. What am I missing?
+
+Any help much appreciated.
diff --git a/doc/forum/Archive_USB_drive_not_working_as_documented/comment_1_59de1e101e5e427abb1df3a71c6f1b04._comment b/doc/forum/Archive_USB_drive_not_working_as_documented/comment_1_59de1e101e5e427abb1df3a71c6f1b04._comment
new file mode 100644
index 0000000000..e7f5eea08a
--- /dev/null
+++ b/doc/forum/Archive_USB_drive_not_working_as_documented/comment_1_59de1e101e5e427abb1df3a71c6f1b04._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmcS2gG2R_AIiBBOsWuxGf1yEn_l797jjU"
+ nickname="Mesar"
+ subject="comment 1"
+ date="2014-07-20T00:50:15Z"
+ content="""
+
+When you did:
+
+    marshal@home[~/annex]> git-annex copy --auto --to usbdrive
+
+this copies the file content (see .git/annex/objects/*), and updates the metadata in both repos.
+The reason why you are not seeing the files on the usb is because the metadata has not been merged into your master branch.
+This is verified by the output of:
+
+    marshal@home[/media/marshal/Sony USB/annex]> git-annex sync laptop
+
+To verify that you indeed do have the files and their content, don't do the above sync, but instead do:
+
+    marshal@home[/media/marshal/Sony USB/annex]> git annex merge
+
+the local metadata in the sync/git-annex branch will be merged in, and the local directory will be populated with the new symlinks to the content which you already have in the /media/marshal/Sony USB/annex/.git/annex/objects/*
+"""]]
diff --git a/doc/forum/Archive_USB_drive_not_working_as_documented/comment_2_3541fdd31d398a494a8fa452ac2c277f._comment b/doc/forum/Archive_USB_drive_not_working_as_documented/comment_2_3541fdd31d398a494a8fa452ac2c277f._comment
new file mode 100644
index 0000000000..1ec09b0ef0
--- /dev/null
+++ b/doc/forum/Archive_USB_drive_not_working_as_documented/comment_2_3541fdd31d398a494a8fa452ac2c277f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnwSZggfi3YE0EAuxAB9jT6pMcB73V8ae4"
+ nickname="Marshal"
+ subject="comment 2"
+ date="2014-07-20T01:33:25Z"
+ content="""
+Thank you Mesar! 
+
+I think I'm beginning to understand. Indeed, the files were there on the usbdrive repo (in .git/annex/objects). No need to sync or merge. I was able to drop a file from the laptop repo and get it back from the usbdrive.
+
+What is a bit unnerving, is that the symlinks are not present on the usbdrive, so it looks empty except for the .git directory.
+
+Thanks so much for clearing this up. More to explore... 
+"""]]
diff --git a/doc/forum/Assistance_required_for_a_specific_workflow.mdwn b/doc/forum/Assistance_required_for_a_specific_workflow.mdwn
new file mode 100644
index 0000000000..40af33107e
--- /dev/null
+++ b/doc/forum/Assistance_required_for_a_specific_workflow.mdwn
@@ -0,0 +1,19 @@
+I'm having troubles trying to setup something like this:
+
+* Setup a git-annex locally on my laptop with multiple special remotes.
+   * These are mainly free cloud services mounted with git-annex-remote-rclone
+* Set the number of copies to 2 (so I can have some redundancy on my annexed files, and spread two different copies into two random special remotes)
+* Use my local annex folder, but due to the (potentially) large size of it, be able to "git annex drop some/files" while maintaining the numcopies:2 setting
+* Set it up so that once I copy/create a file in the annex folder, automatically replicated twice (since numcopies:2) to any of my special remotes.
+
+So far, I have setup my local repo as repository group: client, and all my special remotes as "incremental backup" (since I do not wanted them to each hold a full backup of my whole annex, since it might be much larger than the available space provided by the cloud provider, Box for example).
+
+I had numcopies set to 2, but this only copies one version of each file to another special remote (I assume the other copy is the one in my local repo)
+
+Setting numcopies to 3, copies to two special remotes (plus my local copy) but "git annex drop some/file" does not work, complaining that only two other copies are available, so it is not working as expected.
+
+I'm sure I'm missing something obvious here but how would I set this up so it works as automatically/transparent as possible?
+
+Maybe I could utilize the "/archive" folder and move files there, but i hate destroying my directory structure by moving files there, and I would rather "drop" the files in place, and "get" them when i need them...
+
+A big thanks to the collective git-annex brain out there... :)
diff --git a/doc/forum/Assistance_required_for_a_specific_workflow/comment_1_7c803b6f2759f6fa74c514e79a26f369._comment b/doc/forum/Assistance_required_for_a_specific_workflow/comment_1_7c803b6f2759f6fa74c514e79a26f369._comment
new file mode 100644
index 0000000000..5a24cdae73
--- /dev/null
+++ b/doc/forum/Assistance_required_for_a_specific_workflow/comment_1_7c803b6f2759f6fa74c514e79a26f369._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="use git-annex-untrust"
+ date="2019-04-28T17:32:29Z"
+ content="""
+`[[git annex untrust|git-annex-untrust]] here`
+
+will tell git-annex not to count the local copy towards `numcopies`.
+"""]]
diff --git a/doc/forum/Assistance_required_for_a_specific_workflow/comment_2_4a00c4307a492ffe736cf981ced9f57a._comment b/doc/forum/Assistance_required_for_a_specific_workflow/comment_2_4a00c4307a492ffe736cf981ced9f57a._comment
new file mode 100644
index 0000000000..3983dac43d
--- /dev/null
+++ b/doc/forum/Assistance_required_for_a_specific_workflow/comment_2_4a00c4307a492ffe736cf981ced9f57a._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-05-07T14:57:05Z"
+ content="""
+You should not need to untrust any repository to do this kind of thing.
+Only use untrust if you really expect that a repository could lose data at
+any time. So while Ilya's suggestion will technically work, I don't
+think it's a good idea.
+
+By setting the special remotes to "incremental backup", you've told git-annex
+you only want one copy of the file spread amoung all of them whenever possible.
+So you've shot yourself in the foot there if your goal is to have more than one
+copy of the file amoung the special remotes. 
+
+The easiest thing to do is pick some of the special remotes to be "archive"
+and keep the rest "incremental backup", and each file will be stored twice,
+once in each of those two different types of repositories.
+
+There is also a paragraph in [[preferred_content/standard_groups]] that
+explains how to configure archive repositories to keep more than one copy,
+and following this could let you use only archive repositories and have them
+keep as many copies as you eventually want:
+
+   Note that if you want to archive multiple copies (not a bad idea!),
+   you can set `git-annex groupwanted archive` to a version of
+   the above preferred content expression with a larger number of copies
+   than 1. Then make the archive repositories have a preferred
+   content expression of "groupwanted" in order to use your modified
+   version.
+
+Ie:
+
+	git annex groupwanted archive "(not (copies=archive:2 or copies=smallarchive:2)) or approxlackingcopies=1"
+	git annex group boxdotcom archive
+	git annex group othercloud archive
+	git annex wanted boxdotcom groupwanted
+	git annex wanted othercloud groupwanted
+"""]]
diff --git a/doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__.mdwn b/doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__.mdwn
new file mode 100644
index 0000000000..b75a6eb273
--- /dev/null
+++ b/doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__.mdwn
@@ -0,0 +1,10 @@
+Is there functionality to pause the assistant so that a group of changes all get committed at once?
+
+The case I'm thinking of is using git-annex to manage distribution of my bup backups.  I want to make sure that all the backup files are written - and then the par2 files generated from `fsck`ing - before they are committed and shipped.
+
+Naively, I'm looking for something as simple as a lockfile to touch at the start of the backup and then remove afterwards.
+
+Of course I could just run `git annex sync --content` after the backup is run, but, I'm was thinking that the assistant might be more set and forget...
+
+
+Does anyone do pausing or something similar?
diff --git a/doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__/comment_1_44c97c54066ca0487d8903cc01a356a3._comment b/doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__/comment_1_44c97c54066ca0487d8903cc01a356a3._comment
new file mode 100644
index 0000000000..42f21761fd
--- /dev/null
+++ b/doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__/comment_1_44c97c54066ca0487d8903cc01a356a3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="olaf"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="manual mode?"
+ date="2017-08-17T07:35:41Z"
+ content="""
+It looks like setting the repo to 'manual mode' is sufficient.  I just need to then remember to `git annex add` to ensure everything is committed.
+
+Not ideal, but...
+"""]]
diff --git a/doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__/comment_2_98eb671596e84466e24004f55724660a._comment b/doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__/comment_2_98eb671596e84466e24004f55724660a._comment
new file mode 100644
index 0000000000..7478367b92
--- /dev/null
+++ b/doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__/comment_2_98eb671596e84466e24004f55724660a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 2"
+ date="2017-08-17T10:22:54Z"
+ content="""
+You might also want to check out the annex.alwayscommit and annex.autocommit options.
+"""]]
diff --git a/doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__/comment_3_e3c506ae998a8ae681727d3c432f95d2._comment b/doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__/comment_3_e3c506ae998a8ae681727d3c432f95d2._comment
new file mode 100644
index 0000000000..c11b693578
--- /dev/null
+++ b/doc/forum/Assistant_-_pausing___47___using_lock_file_to_get_atomic__40__ish__41___states__63__/comment_3_e3c506ae998a8ae681727d3c432f95d2._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="olaf"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="comment 3"
+ date="2017-08-18T04:37:57Z"
+ content="""
+Awesome.  Thanks.  I'd missed these entirely.
+
+Looks like my lockfile should be as simple as a combination of those two.
+
+
+I'll report back a working example when I get time to test.
+"""]]
diff --git a/doc/forum/Assistant_Droping_Files.mdwn b/doc/forum/Assistant_Droping_Files.mdwn
new file mode 100644
index 0000000000..e26edc92dc
--- /dev/null
+++ b/doc/forum/Assistant_Droping_Files.mdwn
@@ -0,0 +1,8 @@
+I have a setup as follows,
+
+3 drives on a remote ssh server regular git annex repos.
+One untrusted clone of this repository on my laptop. 
+
+On my laptop in webapp I have set num of copies to 2 (each file does have two copies on the server already). all repos plus laptop is set to manual mode. What happens is whenever I get a file to the laptop it would drop it from the disk on the server. Even though laptop is marked as untrusted this does not happen when using annex at the command line when I do a git annex get . --auto on the server it does not take the files on the untrusted repos into account which is what I want so I can drop files without moving them back to the server.
+
+Is this the intended behavior or am I doing something wrong?
diff --git a/doc/forum/Assistant__58___configure_auto-sync.mdwn b/doc/forum/Assistant__58___configure_auto-sync.mdwn
new file mode 100644
index 0000000000..48c4dc4552
--- /dev/null
+++ b/doc/forum/Assistant__58___configure_auto-sync.mdwn
@@ -0,0 +1,11 @@
+I have large central repositories of data. Therefore, on each client I want to save part data(to save space of disk). In command line I do 
+
+	[...]
+	git-annex webapp
+	git-annex drop [DeleteContentDirectory]
+	[...]
+
+After this command Assistant performs automatic synchronization getting content of files from this directory(DeleteContentDirectory), but I don't want. I want it's was only symlink of file in this directory.
+
+How can I configure Assistant which files have to get content on the client?  It's possible?
+ 
diff --git a/doc/forum/Assistant__58___configure_auto-sync/comment_1_c8cabd38114582bbdbad49f2d81959d7._comment b/doc/forum/Assistant__58___configure_auto-sync/comment_1_c8cabd38114582bbdbad49f2d81959d7._comment
new file mode 100644
index 0000000000..34fffb8463
--- /dev/null
+++ b/doc/forum/Assistant__58___configure_auto-sync/comment_1_c8cabd38114582bbdbad49f2d81959d7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA"
+ nickname="Tobias"
+ subject="comment 1"
+ date="2013-08-26T07:44:22Z"
+ content="""
+You should set your repository to \"manual\" mode instead of \"client\" mode.
+
+But then no data will be synced at all by the assistant, only metadata. You would have to do \"get/drop\" manually for commandline for all files.
+
+Alternatively you could use the special \"archive\" folders that are supported by the assistant.
+
+"""]]
diff --git a/doc/forum/Assistant__58___run_with___34__sync_--fast__34___to_automatically_use_only_available_remotes.mdwn b/doc/forum/Assistant__58___run_with___34__sync_--fast__34___to_automatically_use_only_available_remotes.mdwn
new file mode 100644
index 0000000000..3a6e4a7108
--- /dev/null
+++ b/doc/forum/Assistant__58___run_with___34__sync_--fast__34___to_automatically_use_only_available_remotes.mdwn
@@ -0,0 +1,18 @@
+I have a set of machines, call them A, B, C, I am trying to keep synced. However, all three of them do not always see all the other two (e.g., I might need a vpn tunnel up to see C from A, etc, or C is down, etc). 
+Everything works as expected (i.e., content gets from one machine to the others) if in the webapp I disable the non-reachable nodes (or, equivalently, I set annex-sync to false in .git/config). But I wonder if there is a way to have git annex not use the non-reachable remotes. Using git-annex sync --fast does not seem to do it (since all remotes I guess have the same annex-cost value).
+
+
+I understand a possible solution involves using 
+
+```
+remote.<name>.annex-cost-command
+```
+
+so that I set the cost of the non-available remote to a large value. But then, I'd need to tell the assistant to always use, by default
+
+
+```
+git-annex sync --fast --content
+```
+
+and I do not know how to make it use "--fast". 
diff --git a/doc/forum/Assistant_fails_to_authenticate_to_rsync_remote.mdwn b/doc/forum/Assistant_fails_to_authenticate_to_rsync_remote.mdwn
new file mode 100644
index 0000000000..29a851595c
--- /dev/null
+++ b/doc/forum/Assistant_fails_to_authenticate_to_rsync_remote.mdwn
@@ -0,0 +1,17 @@
+I have an rsync special remote for rsync.net. Recently I noticed that the assistant was not uploading files to this remote. When I look at the log in the webapp I see that it fails to authenticate:
+
+    [2016-04-22 13:28:49.145178] NetWatcherFallback: Syncing with rsync.net
+    Permission denied, please try again.
+    Permission denied, please try again.
+    Received disconnect from 1.1.1.1 port 22:2: Too many authentication failures for 12345
+    Connection to host.rsync.net closed by remote host.
+    rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+    rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.2]
+
+(For privacy I replaced the IP of the rsync.net host with 1.1.1.1 and the numerical user with 12345 and the hostname with host.rsync.net. In the actual log output those 3 things have real values that are correct!)
+
+If I change into this annex in the terminal I can `git annex copy . --to rsync.net` and everything uploads properly, so it is just the assistant which is failing to authenticate. I'm not sure how to go about troubleshooting this. I do use an ssh key to authenticate to the remote. Maybe the assistant doesn't know about this key?
+
+I did create this repo and add the remote manually, only later telling the assistant about the repo through the webapp.
+
+What should I look into to debug this?
diff --git a/doc/forum/Assistant_fails_to_authenticate_to_rsync_remote/comment_1_fdbadd7ae4c0236301944136ac62346a._comment b/doc/forum/Assistant_fails_to_authenticate_to_rsync_remote/comment_1_fdbadd7ae4c0236301944136ac62346a._comment
new file mode 100644
index 0000000000..51b6496716
--- /dev/null
+++ b/doc/forum/Assistant_fails_to_authenticate_to_rsync_remote/comment_1_fdbadd7ae4c0236301944136ac62346a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-03T19:18:29Z"
+ content="""
+The assistant just uses whatever ssh configuration you have.
+
+Desktop environments have password safes and ssh agents. If the assistant
+is being started up outside the desktop environment, it won't have access
+to those. Try stopping the assistant and re-starting it inside a terminal
+in your desktop environment.
+"""]]
diff --git a/doc/forum/Assistant_fails_to_authenticate_to_rsync_remote/comment_2_a395406abd3eb4cf07dc6467506a7e77._comment b/doc/forum/Assistant_fails_to_authenticate_to_rsync_remote/comment_2_a395406abd3eb4cf07dc6467506a7e77._comment
new file mode 100644
index 0000000000..e816a5392b
--- /dev/null
+++ b/doc/forum/Assistant_fails_to_authenticate_to_rsync_remote/comment_2_a395406abd3eb4cf07dc6467506a7e77._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="annexuser"
+ subject="comment 2"
+ date="2016-05-04T19:16:31Z"
+ content="""
+That makes sense! I'm starting the assistant via systemd, so it probably doesn't have access to my environment to get the ssh keys. Thanks!
+"""]]
diff --git a/doc/forum/Assistant_in_windows_only_watches_one_repo_on_startup.mdwn b/doc/forum/Assistant_in_windows_only_watches_one_repo_on_startup.mdwn
new file mode 100644
index 0000000000..9c2e981e46
--- /dev/null
+++ b/doc/forum/Assistant_in_windows_only_watches_one_repo_on_startup.mdwn
@@ -0,0 +1,19 @@
+Hi there,
+
+I've got a problem similar to here: [bugs/Assistant_only_watches_one_repo_on_startup/](https://git-annex.branchable.com/bugs/Assistant_only_watches_one_repo_on_startup/) but in **windows 7**.
+
+I'm running the latest version and my autostart config file (~/.config/git-annex/autostart) contains the following repos:
+
+&nbsp;&nbsp;&nbsp;&nbsp;C:\temp\testrepo1<br>
+&nbsp;&nbsp;&nbsp;&nbsp;C:\temp\testrepo2
+
+From a git bash shell, I launch the assistant using the following command: `git annex assistant --autostart`.
+Upon startup, it outputs the following message: 
+
+&nbsp;&nbsp;&nbsp;&nbsp;git-annex autostart in C:\temp\testrepo1
+
+I then copy a test file to both repos.
+
+In testrepo1, the test file is automatically added to the repo. While in testrepo2, running `git annex status` shows that file has not been processed.
+
+Which means that the second repo is not being watched by the assistant.
diff --git a/doc/forum/Assistant_in_windows_only_watches_one_repo_on_startup/comment_1_48b43fe2ec186cea5930bf641522081d._comment b/doc/forum/Assistant_in_windows_only_watches_one_repo_on_startup/comment_1_48b43fe2ec186cea5930bf641522081d._comment
new file mode 100644
index 0000000000..c487ae28be
--- /dev/null
+++ b/doc/forum/Assistant_in_windows_only_watches_one_repo_on_startup/comment_1_48b43fe2ec186cea5930bf641522081d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-11-20T20:43:50Z"
+ content="""
+What is the output of `git annex assistant --autostart --debug` and `git annex version`?
+"""]]
diff --git a/doc/forum/Assistant_invariants.mdwn b/doc/forum/Assistant_invariants.mdwn
new file mode 100644
index 0000000000..dda0d1adf1
--- /dev/null
+++ b/doc/forum/Assistant_invariants.mdwn
@@ -0,0 +1,20 @@
+I think I might have a wrong mental model about what the annex assistant is really doing and I want to clarify some things.
+
+I have a simple setup, everything was set up with the web app.
+
+* `Desktop`: repository mode, paired locally with Laptop, paired with web server remote `Server`
+* `Laptop`: manual mode, paired locally with Desktop, paired with web server remote `Server`
+* `Server`: transfer client
+
+The intention is that `Desktop` always holds all the files, `Laptop` has some files on-demand, and `Server` is only used for transfer.
+
+After the initial setup configuration, I restarted and used the `git annex assistant` on both `Desktop` and `Laptop` (instead of `git annex webapp`).
+Here are the things that I assumed would happen in this setup.
+
+* There won't be any traffic to the `Server` as long as `Desktop` and `Laptop` are reachable, i.e. in the same network.
+  * I first started pairing `Desktop` and `Laptop` locally. With both in sync, I added the `Server` remote to `Laptop` first, and then I already saw files transferred to `Server`, which I did not expect. 
+* After adding files to `Desktop`, eventually, all metadata would appear on `Laptop`, but never the content as long as I don't manually add it via `git annex add`
+* After adding files to `Laptop`, content would be synced to `Desktop`. The added content on `Laptop` would never be replaced with symlinks, because there is nothing to sync. The latest version is already there.
+* After dropping files from `Laptop`, the content would stay gone until I re-add it.
+
+All my assumptions are immediately violated, so I assume I got them wrong. Is my assistant setup correct for the things that I intend to do?
diff --git a/doc/forum/Assistant_invariants/comment_1_0426e10ffe45f42658d89756ea5ef5be._comment b/doc/forum/Assistant_invariants/comment_1_0426e10ffe45f42658d89756ea5ef5be._comment
new file mode 100644
index 0000000000..b73720e06d
--- /dev/null
+++ b/doc/forum/Assistant_invariants/comment_1_0426e10ffe45f42658d89756ea5ef5be._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Albert"
+ avatar="http://cdn.libravatar.org/avatar/79aaf48dabedd7cd96a9117685fbe2cc"
+ subject="Clarification Example"
+ date="2022-04-23T12:10:36Z"
+ content="""
+Small example for
+
+> After adding files to Laptop, content would be synced to Desktop. The added content on Laptop would never be replaced with symlinks, because there is nothing to sync. The latest version is already there.
+
+I added a `script.sh` file and some resources to `Laptop`. After it synced to `Desktop`, I executed `script.sh`. The content of `script.sh` did not change, but right now the `script.sh` file became a symlink. I assume this symlink will not be replaced, because `Laptop` is in manual mode. Is some metadata change of the file causing syncing again? Access time metadata or some other internal file system metadata that I don't know about? 
+"""]]
diff --git a/doc/forum/Assistant_invariants/comment_2_7d3990582435203e0f94a8a3a2f1ef5a._comment b/doc/forum/Assistant_invariants/comment_2_7d3990582435203e0f94a8a3a2f1ef5a._comment
new file mode 100644
index 0000000000..66791225ee
--- /dev/null
+++ b/doc/forum/Assistant_invariants/comment_2_7d3990582435203e0f94a8a3a2f1ef5a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Albert"
+ avatar="http://cdn.libravatar.org/avatar/79aaf48dabedd7cd96a9117685fbe2cc"
+ subject="Duplicate Files"
+ date="2022-04-24T14:13:46Z"
+ content="""
+Ok, so I think I understand now where all of my problems come from.
+
+On adding new content in `Desktop`, if some files are duplicates of already available content on `Laptop`, those will not be symlinks on `Laptop`.
+When I dropped files from `Laptop`, the duplicate files in other folders, which I did not intend to drop, got also removed. I re-added them, and observed that the files I dropped came back again. Obviously, because they are the same duplicate files.
+
+Very confusing behavior, at least until I understood how duplicate files are handled and the interaction with git annex drop/get + manual mode. Is there maybe some command that drops files from a folder, that **only exist in that folder**?
+"""]]
diff --git a/doc/forum/Assistant_loosing_advantages__63__.mdwn b/doc/forum/Assistant_loosing_advantages__63__.mdwn
new file mode 100644
index 0000000000..113a436bf7
--- /dev/null
+++ b/doc/forum/Assistant_loosing_advantages__63__.mdwn
@@ -0,0 +1,10 @@
+Hey,
+
+I write an article for the univerity about git-annex assistant and I'm a little bit confused about the function of the assistant. 
+Because an advantage of git-annex is that you can hold different files at different places in one repository, but this isn't anymore, or? The assistant syncs every file to every place of the repository. And this makes it just to another Dropbox (not direct the same) pentant or I'm not correct?
+
+The transfer group is just for transfer files to other repositories, which are not connected with the network or?
+
+I'm using ppa, ubuntu 12.04 lts, vers, 2013-12-13
+
+JP Lührig
diff --git a/doc/forum/Assistant_loosing_advantages__63__/comment_1_cdbc827d9e00aeeaefafe45de64b8d2c._comment b/doc/forum/Assistant_loosing_advantages__63__/comment_1_cdbc827d9e00aeeaefafe45de64b8d2c._comment
new file mode 100644
index 0000000000..171019b16c
--- /dev/null
+++ b/doc/forum/Assistant_loosing_advantages__63__/comment_1_cdbc827d9e00aeeaefafe45de64b8d2c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="good question.."
+ date="2013-12-19T17:04:53Z"
+ content="""
+The assistant necessarily simplifies some things git-annex does, so that it can automate them, and this includes keeping files synced to everywhere by default. There are ways to configure the assistant to only keep a subset of files on a computer, including [[archive_directories|assistant/archival_walkthrough]]. Underneath, there is the quite powerful [[preferred_content]] DSL, which can be used to configure lots more interesting behavior about what goes where. So far only some common scenarios have been made easily available in the webappp, but there's potential for lots more configurability here, if a good UI for it is built.
+
+I think the assistant is probably better than dropbox at handling external removable media, used for backups or archiving. (But I have not evaluated, or actually even used dropbox myself. My goal is *not* to copy dropbox.) And it's better at encryption, and it allows using a variety of cloud services rather than only one provider.
+"""]]
diff --git a/doc/forum/Assistant_not_syncing_to_Rsync.mdwn b/doc/forum/Assistant_not_syncing_to_Rsync.mdwn
new file mode 100644
index 0000000000..18adc733d5
--- /dev/null
+++ b/doc/forum/Assistant_not_syncing_to_Rsync.mdwn
@@ -0,0 +1,15 @@
+I have 3 remotes for an annex - one on my laptop, one on a USB drive that's plugged in 50% of the time, and an rsync special remote on a friend's machine that I can access using SSH.
+
+I have tried various things (annex copy, numcopies=3) to make it move data to the rsync remote, but it doesn't seem to want to work. I have tried git annex sync. I added the remote repo using the webapp, and it looked as if it was copying my files for a bit then stopped. I have the remote repo setup as a backup in the webapp.
+
+The sizes of the directorys:
+    ~ $ du -sh Documents
+    126M	Documents
+    ~ $ du -sh /Volumes/Backup/Documents
+    227M	/Volumes/Backup/Documents
+
+and the remote
+    [c0g@womb Tom]$ du -sh MacDocuments/
+    21M	MacDocuments/
+
+I'm also curious as to why the usb drive repo is so much bigger than the thing I'm copying, but I'll worry about that later.
diff --git a/doc/forum/Assistant_not_syncing_to_Rsync/comment_1_2178a7fc0d66643e84597b0938ef65f2._comment b/doc/forum/Assistant_not_syncing_to_Rsync/comment_1_2178a7fc0d66643e84597b0938ef65f2._comment
new file mode 100644
index 0000000000..e701b7cd8f
--- /dev/null
+++ b/doc/forum/Assistant_not_syncing_to_Rsync/comment_1_2178a7fc0d66643e84597b0938ef65f2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 1"
+ date="2013-01-10T18:36:04Z"
+ content="""
+What does it say when you run:
+
+  git annex copy --to $rsyncremote
+"""]]
diff --git a/doc/forum/Assistant_not_syncing_to_Rsync/comment_2_650651398443e128c2adc6a2a2d320d0._comment b/doc/forum/Assistant_not_syncing_to_Rsync/comment_2_650651398443e128c2adc6a2a2d320d0._comment
new file mode 100644
index 0000000000..28d043c6d5
--- /dev/null
+++ b/doc/forum/Assistant_not_syncing_to_Rsync/comment_2_650651398443e128c2adc6a2a2d320d0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkjWgG_L90szs6o4E8cBusol57zkcDhg7c"
+ nickname="Tom"
+ subject="comment 2"
+ date="2013-01-10T18:40:13Z"
+ content="""
+....
+copy FrenchBasicCourserevised-Volume1-StudentText.pdf (checking Womb_MacDocuments...) ok
+....
+
+for each file in the directory.
+"""]]
diff --git a/doc/forum/Assistant_not_syncing_to_Rsync/comment_3_e6d0c9620b148acc72342862a8b4cfef._comment b/doc/forum/Assistant_not_syncing_to_Rsync/comment_3_e6d0c9620b148acc72342862a8b4cfef._comment
new file mode 100644
index 0000000000..99b78a73c4
--- /dev/null
+++ b/doc/forum/Assistant_not_syncing_to_Rsync/comment_3_e6d0c9620b148acc72342862a8b4cfef._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 3"
+ date="2013-01-10T18:44:00Z"
+ content="""
+Sounds like copy works then?
+
+What version of git-annex do you have installed? A bug was fixed on December 11th, before that the assistant never stored things in repositories configured as backups.
+"""]]
diff --git a/doc/forum/Assistant_not_syncing_to_Rsync/comment_4_b91f9febdb8b69d8b487ba4ea08c119a._comment b/doc/forum/Assistant_not_syncing_to_Rsync/comment_4_b91f9febdb8b69d8b487ba4ea08c119a._comment
new file mode 100644
index 0000000000..8303babe3d
--- /dev/null
+++ b/doc/forum/Assistant_not_syncing_to_Rsync/comment_4_b91f9febdb8b69d8b487ba4ea08c119a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkjWgG_L90szs6o4E8cBusol57zkcDhg7c"
+ nickname="Tom"
+ subject="comment 4"
+ date="2013-01-10T18:48:16Z"
+ content="""
+Sorry for lack of extra information: The sizes of the remote folder is still at 21MB, well below even the size of the PDF I posted about (that's about 75MB). Copy claims to work, but I see no network use and the remote repo doesn't grow. I install using cabal on my max yesterday, git-annex version: 3.20130107
+
+
+
+"""]]
diff --git a/doc/forum/Assistant_not_syncing_to_Rsync/comment_5_c5ad7c1546a17d8459c995c9c8c26414._comment b/doc/forum/Assistant_not_syncing_to_Rsync/comment_5_c5ad7c1546a17d8459c995c9c8c26414._comment
new file mode 100644
index 0000000000..653b7cc51f
--- /dev/null
+++ b/doc/forum/Assistant_not_syncing_to_Rsync/comment_5_c5ad7c1546a17d8459c995c9c8c26414._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 5"
+ date="2013-01-10T18:58:49Z"
+ content="""
+Ok, so copy is checking if the file is present, and it seems to think it is, so doesn't try again to send it.
+
+Here's what you need to do: Run `git annex copy FrenchBasicCourserevised-Volume1-StudentText.pdf  --to Womb_MacDocuments --debug`
+
+It'll output something like this:
+
+    copy new (checking rsync...) [2013-01-10 14:51:43 JEST] read: rsync [\"localhost:/tmp/r/f87/4d5/'SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'\"]
+
+Now try running that command at the shell, and check its exit status. For the above, I ran:
+
+    rsync \"localhost:/tmp/r/f87/4d5/'SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'\"; echo $?
+
+It output:
+
+    -rw-r--r--           0 2013/01/10 14:51:40 SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+    0
+
+Compare with the same command but with the filename mangled. 
+
+    rsync: link_stat \"/tmp/r/f87/4d5/'SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/mangled'\" failed: No such file or directory (2)
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1536) [Receiver=3.0.9]
+    27
+
+It seems that rsync might be exiting 0 for content that's not there, in your case. This test will confirm or disprove that hypothesis and might provide some useful debug info.
+"""]]
diff --git a/doc/forum/Assistant_not_syncing_to_Rsync/comment_6_4c12587f972eced91c5128d4885800b5._comment b/doc/forum/Assistant_not_syncing_to_Rsync/comment_6_4c12587f972eced91c5128d4885800b5._comment
new file mode 100644
index 0000000000..3746fa2e37
--- /dev/null
+++ b/doc/forum/Assistant_not_syncing_to_Rsync/comment_6_4c12587f972eced91c5128d4885800b5._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkjWgG_L90szs6o4E8cBusol57zkcDhg7c"
+ nickname="Tom"
+ subject="comment 6"
+ date="2013-01-11T07:44:11Z"
+ content="""
+I did what you said for a file, and checked the remote size as well. Local size of this file was 11.4 meg, remote was 1.3 megabytes.
+
+    copy Paradox Interactive/Crusader Kings II/save games/Yngling/1066_09_15_2.ck2 (checking Womb_MacDocuments...) [2013-01-11 07:30:26 GMT] read: rsync [\"c0g@git-    annex-c0g:/raid/Tom/MacDocuments/87f/7f7/'GPGHMACSHA1--0148d706315885fac29c3a1dc0ec37b2835739a7/GPGHMACSHA1--0148d706315885fac29c3a1dc0ec37b2835739a7'\"]
+     ok
+
+    rsync c0g@git-annex-c0g:/raid/Tom/MacDocuments/87f/7f7/'GPGHMACSHA1--0148d706315885fac29c3a1dc0ec37b2835739a7/GPGHMACSHA1--0148d706315885fac29c3a1dc0ec37b2835739a7'
+    -rw-r--r--     1290004 2013/01/10 17:37:14 GPGHMACSHA1--0148d706315885fac29c3a1dc0ec37b2835739a7
+    0
+
+    ~/Documents ± la Paradox\ Interactive/Crusader\ Kings\ II/save\ games/Yngling
+    total 44728
+    drwx------  4 c0g  staff       136 10 Jan 17:52 . 
+    drwx------  3 c0g  staff       102 10 Nov 20:53 ..
+    -rw-r--r--  1 c0g  staff  11413707 10 Jan 17:52 1066_09_15.ck2
+    -rw-r--r--  1 c0g  staff  11484448 10 Jan 17:52 1066_09_15_2.ck2
+
+    [c0g@womb GPGHMACSHA1--0148d706315885fac29c3a1dc0ec37b2835739a7]$ ls -la
+    total 1268
+    drwxr-xr-x 2 c0g users    4096 Jan 10 12:37 .
+    drwxr-xr-x 3 c0g users    4096 Jan 10 12:37 ..
+    -rw-r--r-- 1 c0g users 1290004 Jan 10 12:37 GPGHMACSHA1--0148d706315885fac29c3a1dc0ec37b2835739a7
+
+
+"""]]
diff --git a/doc/forum/Assistant_not_syncing_to_Rsync/comment_7_6ecaaee9316bcf0c65688676d60fc055._comment b/doc/forum/Assistant_not_syncing_to_Rsync/comment_7_6ecaaee9316bcf0c65688676d60fc055._comment
new file mode 100644
index 0000000000..38f755c86e
--- /dev/null
+++ b/doc/forum/Assistant_not_syncing_to_Rsync/comment_7_6ecaaee9316bcf0c65688676d60fc055._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkjWgG_L90szs6o4E8cBusol57zkcDhg7c"
+ nickname="Tom"
+ subject="comment 7"
+ date="2013-01-11T07:52:17Z"
+ content="""
+I just compressed the documents folder, and it compresses down to 20 MB... I'm going to guess it stores as a compressed encrypted archive? How embarrasing for me!
+"""]]
diff --git a/doc/forum/Assistant_not_syncing_to_Rsync/comment_8_daa9a9a6188afa0394833e1b682f7cd4._comment b/doc/forum/Assistant_not_syncing_to_Rsync/comment_8_daa9a9a6188afa0394833e1b682f7cd4._comment
new file mode 100644
index 0000000000..f0a1c88fc7
--- /dev/null
+++ b/doc/forum/Assistant_not_syncing_to_Rsync/comment_8_daa9a9a6188afa0394833e1b682f7cd4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 8"
+ date="2013-01-11T17:20:19Z"
+ content="""
+Aha! Yes, encryption includes compression. 
+
+So, only remaining question is why your USB drive seems to be using 2x the uncompressed file size. One possibility would be it could have old versions of files, or deleted files still stored in it. You could try running \"git annex unused\" in its repository to find them. Other than that, I'm not sure what it could be. You can look around in its .git/annex directory, and compare to your laptop's repository, and perhaps see what's using the space.
+"""]]
diff --git a/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas.mdwn b/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas.mdwn
new file mode 100644
index 0000000000..e71bf040bf
--- /dev/null
+++ b/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas.mdwn
@@ -0,0 +1,21 @@
+Hello,
+
+I am using the latest git-annex with the webui having two local folders (one over nfs) connected as a full backup group. 
+
+On every reboot I get a jumping ball icon with the text:
+
+"Attempting to repair [tr2]"
+
+And the later the text:
+
+"failed to sync to tr2"
+
+The debug log is filled with entries like this, where the number of deltas is increasing:
+
+[2014-08-26 20:34:50 CEST] PushRetrier: Syncing with tr2 
+fatal: pack has 15 unresolved deltas
+error: unpack failed: index-pack abnormal exit
+To /nfs/backup
+ ! [remote rejected] git-annex -> synced/git-annex (n/a (unpacker error))
+ ! [remote rejected] annex/direct/master -> synced/master (n/a (unpacker error))
+error: failed to push some refs to '/nfs/backup''
diff --git a/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_1_a8effe196e4a040630d183803768c5a1._comment b/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_1_a8effe196e4a040630d183803768c5a1._comment
new file mode 100644
index 0000000000..41f28a0cf2
--- /dev/null
+++ b/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_1_a8effe196e4a040630d183803768c5a1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="anders7788"
+ ip="212.247.195.173"
+ subject="comment 1"
+ date="2014-08-27T06:59:08Z"
+ content="""
+My version is:
+
+assistant version 5.20140517.4
+"""]]
diff --git a/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_2_9f032e43b132bcad656e1337ab2551ad._comment b/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_2_9f032e43b132bcad656e1337ab2551ad._comment
new file mode 100644
index 0000000000..c139bd963f
--- /dev/null
+++ b/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_2_9f032e43b132bcad656e1337ab2551ad._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="anders7788"
+ ip="89.160.15.173"
+ subject="[Solved]"
+ date="2014-09-04T15:47:24Z"
+ content="""
+[Solved]
+
+The following of the steps at: http://git-annex.branchable.com/tips/what_to_do_when_a_repository_is_corrupted/ provided some clues and I discovered that the disk was broken. But a big thanks to git-annex which made it possible to discover this issue early!
+"""]]
diff --git a/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_3_5a09f65c77dce3c62236c13aa90a1191._comment b/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_3_5a09f65c77dce3c62236c13aa90a1191._comment
new file mode 100644
index 0000000000..1b4c2499ac
--- /dev/null
+++ b/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_3_5a09f65c77dce3c62236c13aa90a1191._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 3"
+ date="2014-10-12T17:42:28Z"
+ content="""
+Sorry I didn't get to this earlier. I'm glad you managed to solve the problem, but there is something I am curious about: You say you had 2 folders set as full backups. Were these git repositories in their own right, or were they something else, eg directory special remotes?
+
+I ask because, if there were git repositories then the repair should have been able to pull the missing git objects from them, and fix your repository. Unless the broken disk somehow kept corrupting it, I suppose..
+"""]]
diff --git a/doc/forum/Auto_archiving.mdwn b/doc/forum/Auto_archiving.mdwn
new file mode 100644
index 0000000000..f32a648c23
--- /dev/null
+++ b/doc/forum/Auto_archiving.mdwn
@@ -0,0 +1,17 @@
+I've been toying with the idea of auto archiving files (that is - removing them from .) based on a set of rules.
+
+Git already provides attribute management for files and I put together a simple script that tries to achieve the following:
+
+* Look for files with X copies (including a local one)
+* Verify that the file is not recent (defined as not having been dropped or getted within X days )
+* Verify that the file has an annex.archive attribute
+* Archive if the above is met
+
+Here is the script:
+http://pastebin.com/53iLqyPd
+
+You just add the annex.archive attribute to files via .gitattributes to use
+
+The script runs in preview mode... exec with autoArchive.sh commit to drop the files.
+
+Open to thoughts / suggestions
diff --git a/doc/forum/Auto_ignore_non-reachable_repo.mdwn b/doc/forum/Auto_ignore_non-reachable_repo.mdwn
new file mode 100644
index 0000000000..c56872536e
--- /dev/null
+++ b/doc/forum/Auto_ignore_non-reachable_repo.mdwn
@@ -0,0 +1,15 @@
+Hello,
+
+having multiple remotes, which are often unreachable, I get command output like:
+
+    git annex drop .
+    drop 2017 Haus Idstein/26108065_10212412239435248_1115645256_o.jpg (locking horus...) (lockcontent failed) (checking horus...) ssh: Could not resolve hostname horus.local: Name or service not known
+    (checking S3...) ok
+    drop 2017 Haus Idstein/26177516_10212412238475224_326557077_o.jpg (locking horus...) (lockcontent failed) (checking horus...) ssh: Could not resolve hostname horus.local: Name or service not known
+    (checking S3...) ok
+    drop 2017 Haus Idstein/26178378_10212412238835233_820819105_o.jpg (locking horus...) (lockcontent failed) (checking horus...) ssh: Could not resolve hostname horus.local: Name or service not known
+    (checking S3...) ok
+
+which takes a long time, because it tries to lock horus first for each, waits for timeout and then tries the next remote. Of course I could use ```git annex drop --from=S3``` but I do not always remember that. Is there a way to auto ignore a remote which is not reachable?
+
+Thanks!
diff --git a/doc/forum/Auto_ignore_non-reachable_repo/comment_1_40d7aab5e43c75ede3414ed48f0c7066._comment b/doc/forum/Auto_ignore_non-reachable_repo/comment_1_40d7aab5e43c75ede3414ed48f0c7066._comment
new file mode 100644
index 0000000000..fe3b73a244
--- /dev/null
+++ b/doc/forum/Auto_ignore_non-reachable_repo/comment_1_40d7aab5e43c75ede3414ed48f0c7066._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Horus"
+ avatar="http://cdn.libravatar.org/avatar/8f0ee08b98ea5bba76c3fe112c08851c"
+ subject="comment 1"
+ date="2018-02-28T09:31:26Z"
+ content="""
+Should be a edit: ```git annex drop --from=S3``` does not force checking the repo S3, but drops from S3.
+"""]]
diff --git a/doc/forum/Auto_ignore_non-reachable_repo/comment_2_74c297d8d5e9f7d131c461ed5e803071._comment b/doc/forum/Auto_ignore_non-reachable_repo/comment_2_74c297d8d5e9f7d131c461ed5e803071._comment
new file mode 100644
index 0000000000..4a80489010
--- /dev/null
+++ b/doc/forum/Auto_ignore_non-reachable_repo/comment_2_74c297d8d5e9f7d131c461ed5e803071._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-02-28T15:55:39Z"
+ content="""
+You can temporarily enable annex-ignore for a remote.
+
+For example:
+
+git -c remote.horus.annex-ignore=true git annex drop ...
+
+Adjusting the annex-cost of the remote may also be useful, so git-annex
+will avoid using that remote when it can use a lower-cost remote instead.
+The annex-cost-command could be used to detect the network where the remote
+access times out and make its cost be very high then.
+"""]]
diff --git a/doc/forum/Auto_sync_with_music_player.mdwn b/doc/forum/Auto_sync_with_music_player.mdwn
new file mode 100644
index 0000000000..e4a5543b45
--- /dev/null
+++ b/doc/forum/Auto_sync_with_music_player.mdwn
@@ -0,0 +1 @@
+I have a music directory under Nexus 5 which is a git-annex repository. If I sync the same with remote repository, newly added songs or modified songs(modifed id3 tags) will not sync with music player. But if I use Android File Transfer to transfer songs, it will sync music player. The songs which are transferred using git-annex will reflect in music player only after restart. Do we have to execute any command which will sync music player.
diff --git a/doc/forum/Auto_sync_with_music_player/comment_1_81ad1c15cfd753531c01dae8945d1caf._comment b/doc/forum/Auto_sync_with_music_player/comment_1_81ad1c15cfd753531c01dae8945d1caf._comment
new file mode 100644
index 0000000000..3ed75f9e9d
--- /dev/null
+++ b/doc/forum/Auto_sync_with_music_player/comment_1_81ad1c15cfd753531c01dae8945d1caf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.146"
+ subject="comment 1"
+ date="2014-03-05T20:40:50Z"
+ content="""
+This is probably done via intents or a similar interface. git-annex is not yet able to use such android api's, but if there is a command line way to send the message that a file has changed, which there probably is, I could look into making git-annex use it.
+"""]]
diff --git a/doc/forum/Auto_sync_with_music_player/comment_2_a15e3f298c3d3faa5b3295355f9bb794._comment b/doc/forum/Auto_sync_with_music_player/comment_2_a15e3f298c3d3faa5b3295355f9bb794._comment
new file mode 100644
index 0000000000..fc0d069683
--- /dev/null
+++ b/doc/forum/Auto_sync_with_music_player/comment_2_a15e3f298c3d3faa5b3295355f9bb794._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="EvanDeaubl"
+ ip="67.128.198.190"
+ subject="Workaround using external app"
+ date="2014-03-07T14:57:39Z"
+ content="""
+A workaround for this is using an external app that pings the media scanner to rescan. It's an extra step to remember, but I haven't found it too much of a burden.
+
+I use this one: <https://play.google.com/store/apps/details?id=com.addz.mediascanner>, but there are at least a dozen to choose from.
+
+"""]]
diff --git a/doc/forum/Auto_sync_with_music_player/comment_3_99f65a0efaf5d5f9b8ff530acc122860._comment b/doc/forum/Auto_sync_with_music_player/comment_3_99f65a0efaf5d5f9b8ff530acc122860._comment
new file mode 100644
index 0000000000..b0275abdc2
--- /dev/null
+++ b/doc/forum/Auto_sync_with_music_player/comment_3_99f65a0efaf5d5f9b8ff530acc122860._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.154"
+ subject="comment 3"
+ date="2014-03-18T19:59:07Z"
+ content="""
+Turns out there is an open todo about this with details: [[todo/Use_MediaScannerConnection_on_Android]]
+"""]]
diff --git a/doc/forum/Auto_update_not_working.mdwn b/doc/forum/Auto_update_not_working.mdwn
new file mode 100644
index 0000000000..1c9fa60bf3
--- /dev/null
+++ b/doc/forum/Auto_update_not_working.mdwn
@@ -0,0 +1,6 @@
+Hello,
+
+I've installed to ~/software/ using the prebuilt tarballs. I'm using the assistant with auto updates set to ask. Everytime I start the assistant it claims a new that a new version of git-annex has been installed. I click Finish Upgrade, it does the upgrade and it says to have finished upgrading to version 5.20141105-g8b19598. Next boot / restart everything starts again and it upgrades always to the same version.
+
+Thanks!
+Florian
diff --git a/doc/forum/Automatic___96__git_annex_get__96___after_invalidation_of_local_files_due_to_external_modification__63__.mdwn b/doc/forum/Automatic___96__git_annex_get__96___after_invalidation_of_local_files_due_to_external_modification__63__.mdwn
new file mode 100644
index 0000000000..50518e33ad
--- /dev/null
+++ b/doc/forum/Automatic___96__git_annex_get__96___after_invalidation_of_local_files_due_to_external_modification__63__.mdwn
@@ -0,0 +1,46 @@
+## Use case
+
+A laptop with a relatively small hard drive has copies of a subset of
+all annexed files.  When annexed files are changed externally and `git
+annex sync` is run on the laptop, the stale local copies are
+invalidated and their symlinks break.  How can I automatically fetch
+the updated versions of these previously locally-cached files?
+
+Because I only want a subset of files, I can't do
+
+    git annex add --not --in here --and --in superset.
+
+Because files may be renamed, the
+[[tips/automatically_getting_files_on_checkout/]] solution, by making
+`dir` specify the subset, will require manually and redundantly
+tracking renames.
+
+## Simple ( (?) ) feature addition to git-annex to support this
+
+When locally-cached files are invalidated by `git-annex sync`,
+git-annex could notify the user, and give them the option to
+`git-annex get` the invalidated files.  Bonus points if the mechanism
+allows this to be done at any point in the future, not just when
+running `git-annex sync`.  The idea is that git-annex could track
+which files, previously cached locally, have been invalidated
+*unintentionally* by syncs, and treat them differently from files,
+previously cached locally, that have been *intentionally* dropped
+using `git-annex drop` or `git-annex move`.
+
+## More generally
+
+The ability to specify a collection of files to always cache locally
+(something like a numcopies.here=1), which is robust to renames, would
+work.  The "robust to renames" part seems tricky in git: whereas svn
+attaches properties to files, and so properties are propagated by `svn
+mv`, I believe git attributes are only specified by patterns in
+.gitattributes files.
+
+## Related questions / possible approaches
+
+Other forum posts mention [[`git
+subtree`|forum/git-subtree_support__63__/]] and [[sparse git
+checkouts|forum/sparse_git_checkouts_with_annex/]], but I'm not
+familiar with these features and from reading those questions it's
+unclear if those approaches will work for me.  Does anyone more
+familiar see how to adapt one of those features to my use case?
diff --git a/doc/forum/Automatic___96__git_annex_get__96___after_invalidation_of_local_files_due_to_external_modification__63__/comment_1_dab1099ee56541c194de319c593f1268._comment b/doc/forum/Automatic___96__git_annex_get__96___after_invalidation_of_local_files_due_to_external_modification__63__/comment_1_dab1099ee56541c194de319c593f1268._comment
new file mode 100644
index 0000000000..fa561ef04c
--- /dev/null
+++ b/doc/forum/Automatic___96__git_annex_get__96___after_invalidation_of_local_files_due_to_external_modification__63__/comment_1_dab1099ee56541c194de319c593f1268._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 1"
+ date="2012-06-04T19:56:05Z"
+ content="""
+Personally, I deal with this problem by having a directory, or directories where I put files that I want to have on my partial checkout laptop, and run `git annex get` in that directory. 
+
+It's not a perfect solution, but I don't know that a perfect solution exists.
+"""]]
diff --git a/doc/forum/Automatic___96__git_annex_get__96___after_invalidation_of_local_files_due_to_external_modification__63__/comment_2_b5faccf132fb47e3cda778a6600fd9ef._comment b/doc/forum/Automatic___96__git_annex_get__96___after_invalidation_of_local_files_due_to_external_modification__63__/comment_2_b5faccf132fb47e3cda778a6600fd9ef._comment
new file mode 100644
index 0000000000..2cd1001ef3
--- /dev/null
+++ b/doc/forum/Automatic___96__git_annex_get__96___after_invalidation_of_local_files_due_to_external_modification__63__/comment_2_b5faccf132fb47e3cda778a6600fd9ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlu7K3h7Ry1uDAU_ERYGuqt0LoGNJqGuRo"
+ nickname="Nathan"
+ subject="comment 2"
+ date="2012-06-04T21:01:52Z"
+ content="""
+Joey, that sounds reasonable; I'll try it. Thanks!
+"""]]
diff --git a/doc/forum/Automatic_commit_messages_for_git_annex_sync.mdwn b/doc/forum/Automatic_commit_messages_for_git_annex_sync.mdwn
new file mode 100644
index 0000000000..60b8e034d0
--- /dev/null
+++ b/doc/forum/Automatic_commit_messages_for_git_annex_sync.mdwn
@@ -0,0 +1 @@
+Not really important (who reads git annex commit messages anyways ;-)), but nice to have and maybe a nice task for someone who wants to play around with Haskell and git annex: It would be shiny if the auto-commit done by git annex sync would automatically create a sensible commmit message and description. E.g. if just one file is added, it could say „Added blubb“. If a few files are added, it could say „Added blubb, bla and n other files“, based on the file name length, and list the files in the long description. Lots of room for playing around :-)
diff --git a/doc/forum/Automatic_commit_messages_for_git_annex_sync/comment_1_ea2ec57bc695da4df8a30a35d433959d._comment b/doc/forum/Automatic_commit_messages_for_git_annex_sync/comment_1_ea2ec57bc695da4df8a30a35d433959d._comment
new file mode 100644
index 0000000000..c07dd49999
--- /dev/null
+++ b/doc/forum/Automatic_commit_messages_for_git_annex_sync/comment_1_ea2ec57bc695da4df8a30a35d433959d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-02-24T20:52:51Z"
+ content="""
+Took me a minute to see this is not about [[bugs/wishlist:_more_descriptive_commit_messages_in_git-annex_branch]], but about the \"git-annex automatic sync\" message that is used when committing any changes currently on the master branch before doing the rest of the sync.
+
+So.. It would be pretty easy to `ls-files` the relevant files before the commit and make a message. Although this would roughly double the commit time in a large tree, since that would walk the whole tree again (git commit -a already does it once). Smarter approaches could be faster.. perhaps it could find unstaged files, stage them, generate the message, and then `git commit` the staged changes.
+
+But, would this really be useful? It's already easy to get `git log` to show a summary of the changes made in such a commit. So it's often seen as bad form to unnecessarily mention which files a commit changes in the commit message.
+
+Perhaps more useful would be to expand the current message with details like where the sync is being committed, or what
+remotes it's going to sync from, or something like that.
+"""]]
diff --git a/doc/forum/Automatic_commit_messages_for_git_annex_sync/comment_2_af71f53dbbca35d5a5c66ff131887ada._comment b/doc/forum/Automatic_commit_messages_for_git_annex_sync/comment_2_af71f53dbbca35d5a5c66ff131887ada._comment
new file mode 100644
index 0000000000..a71f72b9e4
--- /dev/null
+++ b/doc/forum/Automatic_commit_messages_for_git_annex_sync/comment_2_af71f53dbbca35d5a5c66ff131887ada._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="comment 2"
+ date="2012-02-24T23:09:03Z"
+ content="""
+Yes, it is really a minor point. And indeed, \"git log --summary\" is pretty good already. But I’d still think that at least the title could deserves some love. Including the Hostname or the name of the repository there is a good idea as well.
+"""]]
diff --git a/doc/forum/Automatically_dropping_files.mdwn b/doc/forum/Automatically_dropping_files.mdwn
new file mode 100644
index 0000000000..dd47d87d68
--- /dev/null
+++ b/doc/forum/Automatically_dropping_files.mdwn
@@ -0,0 +1,7 @@
+I can make `git-annex` automatically fetch files with the [[/preferred content]] setting and the `--auto` flag, and it works almost exactly like I expect it to work.
+
+What I am missing is a way to make `git annex drop --auto` drop all files that are not wanted.
+
+I would like to work with metadata and tags in such a way that I can have clones (with views) that have only exactly those files available which carry a tag (done), and all other files automatically removed from the annex (unless that would be unsafe).
+
+Does anyone know how to achieve this?
diff --git a/doc/forum/Automatically_dropping_files/comment_1_f5fc608f9cb0edf3272b586b62050637._comment b/doc/forum/Automatically_dropping_files/comment_1_f5fc608f9cb0edf3272b586b62050637._comment
new file mode 100644
index 0000000000..28c9c0a565
--- /dev/null
+++ b/doc/forum/Automatically_dropping_files/comment_1_f5fc608f9cb0edf3272b586b62050637._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="216.145.95.162"
+ subject="comment 1"
+ date="2014-05-19T15:41:05Z"
+ content="""
+`git annex drop --auto` *does* automatically drop files that are not wanted, according to your preferred content settings.
+
+If your preferred content for a repo is `metadata=tag=done`, then only files tagged \"done\" will be kept in the repository. 
+
+Of course, files are only dropped if enough other copies can be verified to exist in other repositories..
+"""]]
diff --git a/doc/forum/Automatically_syncronise_centralised_repository.mdwn b/doc/forum/Automatically_syncronise_centralised_repository.mdwn
new file mode 100644
index 0000000000..fe93a814d0
--- /dev/null
+++ b/doc/forum/Automatically_syncronise_centralised_repository.mdwn
@@ -0,0 +1,14 @@
+I would like to use git annex between two locations (work and home) where essentially the two computers are never on at the same time.
+
+I have set up a special remote (S3) to cater for file transfer between the sites, but still need some way of syncronising the git repositories between them.
+I have access to a git server, but which doesn't have git-annex on it. So, I think that is all the components I need to get this working.
+
+However, I don't want to have to manually sync my computers with the central server, so I would like the assistant to do it for me, in what is essentially the complement of the special remote.
+
+What is the best way to accomplish this? I guess that this is a general git question, not specific to git annex.
+I see some solutions [[http://stackoverflow.com/questions/3583061/automatically-mirror-a-git-repository]], but my git isn't really up to evaluating the options properly.
+
+So, what do other people do in this situation? 
+
+
+--Walter
diff --git a/doc/forum/Automatically_syncronise_centralised_repository/comment_1_6a2047daa9faf4309d2ed27d5cc48b76._comment b/doc/forum/Automatically_syncronise_centralised_repository/comment_1_6a2047daa9faf4309d2ed27d5cc48b76._comment
new file mode 100644
index 0000000000..cbf8f0d047
--- /dev/null
+++ b/doc/forum/Automatically_syncronise_centralised_repository/comment_1_6a2047daa9faf4309d2ed27d5cc48b76._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-22T18:58:08Z"
+ content="""
+The assistant can handle this syncing via a central bare remote. The only problem is that, since your server does not have git-annex installed, that remote will have annex-ignore set on it. That made the assistant not use it for syncing at all.
+
+I've just committed a change to git that makes the assistant still use such a git remote for syncing the git repository, even though it cannot store file contents there.
+"""]]
diff --git a/doc/forum/Automatically_syncronise_centralised_repository/comment_2_3be7b45bc2284019f17a81375637a576._comment b/doc/forum/Automatically_syncronise_centralised_repository/comment_2_3be7b45bc2284019f17a81375637a576._comment
new file mode 100644
index 0000000000..956e6b00a3
--- /dev/null
+++ b/doc/forum/Automatically_syncronise_centralised_repository/comment_2_3be7b45bc2284019f17a81375637a576._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
+ nickname="Walter"
+ subject="comment 2"
+ date="2013-04-22T20:37:59Z"
+ content="""
+That looks like exactly what I'm after!
+
+I'm very impressed by the quick response. Keep up the great work!
+"""]]
diff --git a/doc/forum/Autostart_the_assistant.mdwn b/doc/forum/Autostart_the_assistant.mdwn
new file mode 100644
index 0000000000..06439750e9
--- /dev/null
+++ b/doc/forum/Autostart_the_assistant.mdwn
@@ -0,0 +1,9 @@
+Hello,
+
+I'm using the Arch git-annex package: https://www.archlinux.org/packages/community/x86_64/git-annex/
+
+Checking the autostart checkbox in the assistant's web interface has no effect. There is no git-annex desktop file in ~/.config/autostart/ or alike. Neither is one contained in the package, however in the tarball I haven't found either.
+
+How does autostarting the assistant works?
+
+Best Thanks!
diff --git a/doc/forum/Autostart_the_assistant/comment_1_a5421711102fb1649d98d916e5ced86b._comment b/doc/forum/Autostart_the_assistant/comment_1_a5421711102fb1649d98d916e5ced86b._comment
new file mode 100644
index 0000000000..88ad0fc3ad
--- /dev/null
+++ b/doc/forum/Autostart_the_assistant/comment_1_a5421711102fb1649d98d916e5ced86b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Horus"
+ subject="comment 1"
+ date="2016-03-14T08:18:49Z"
+ content="""
+Bump that, since a vast number of ancient posts somehow were resurrected...
+"""]]
diff --git a/doc/forum/Autostart_the_assistant/comment_2_df70bd0f5caab43503a3c9d805323289._comment b/doc/forum/Autostart_the_assistant/comment_2_df70bd0f5caab43503a3c9d805323289._comment
new file mode 100644
index 0000000000..3bad9e467b
--- /dev/null
+++ b/doc/forum/Autostart_the_assistant/comment_2_df70bd0f5caab43503a3c9d805323289._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-03-14T17:41:38Z"
+ content="""
+The way autostart works is, the repository gets listed in
+`~/.config/git-annex/autostart` -- setting up that file is all that
+the webapp preferences does.
+
+`git annex assistant --autostart` looks at that files and gets the
+assistant running in each listed repository.
+
+Now, something has to take care of running that command when the system
+starts or you log in or whatever. At this point it gets OS dependant.
+
+For example, on Debian, this is handled by the git-annex package containing
+`/etc/xdg/autostart/git-annex.desktop`
+
+Sounds like they may have left this file out of the Arch package. 
+
+git-annex's `make install` handles building that desktop file. It only
+generates it if run as root, or with DESTDIR set. One or the other should
+normally be the case when building a package.
+
+Here's the content of `/etc/xdg/autostart/git-annex.desktop`
+
+	[Desktop Entry]
+	Type=Application
+	Version=1.0
+	Name=Git Annex Assistant
+	Comment=Autostart
+	Terminal=false
+	Exec=/usr/bin/git-annex assistant --autostart
+	Categories=
+"""]]
diff --git a/doc/forum/Autostart_the_assistant/comment_3_42de896f64adb49c60ec3f7e0aeebda6._comment b/doc/forum/Autostart_the_assistant/comment_3_42de896f64adb49c60ec3f7e0aeebda6._comment
new file mode 100644
index 0000000000..3f23c03e54
--- /dev/null
+++ b/doc/forum/Autostart_the_assistant/comment_3_42de896f64adb49c60ec3f7e0aeebda6._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="Horus"
+ subject="comment 3"
+ date="2016-03-15T08:53:14Z"
+ content="""
+I use the Arch package, it is built / installed like that <https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/git-annex>
+
+    runhaskell Setup configure -O --prefix=/usr --docdir=\"/usr/share/doc/${pkgname}\" \
+        -fcryptonite -fnetwork-uri -f-ekg -fconcurrentoutput -ftorrentparser \
+        -ftestsuite -f-androidsplice -f-android -fproduction -fpairing -fwebapp \
+        -fassistant -fwebdav -fs3 -f-benchmark -fdbus -fxmpp -fmagicmime
+    runhaskell Setup build
+
+    runhaskell Setup copy --destdir=\"${pkgdir}\"
+
+Seem to be no classical make install involved. I try to peek your build system, but I know way to little about Haskell.
+
+Is there a way to get all the generated desktop files? Maybe add them to the prebuilt tarball?
+"""]]
diff --git a/doc/forum/Autostart_the_assistant/comment_4_5c6e085b1077b0792a1805f032ac6a4b._comment b/doc/forum/Autostart_the_assistant/comment_4_5c6e085b1077b0792a1805f032ac6a4b._comment
new file mode 100644
index 0000000000..23416f76b8
--- /dev/null
+++ b/doc/forum/Autostart_the_assistant/comment_4_5c6e085b1077b0792a1805f032ac6a4b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-04-20T16:56:01Z"
+ content="""
+The only supported way is to either run "make install", or use a
+distribution package that is built using "make install". 
+
+If your distribution is building the package in some other way, please file
+a bug with it to get its package fixed.
+"""]]
diff --git a/doc/forum/Back_up_videos_to_youtube__63__.mdwn b/doc/forum/Back_up_videos_to_youtube__63__.mdwn
new file mode 100644
index 0000000000..4e2d2b2592
--- /dev/null
+++ b/doc/forum/Back_up_videos_to_youtube__63__.mdwn
@@ -0,0 +1,24 @@
+I've gotten back into the habit of recording my gameplay sessions again. However, because my screen resolution hasn't gotten smaller, the recordings are quite large and I don't need to store them in full quality forever, so my idea was it to upload them to YouTube as unlisted videos rather than doing my usual duplication.
+
+How can I map this use-case to git-annex?
+
+I will have one local "full" copy on a hard drive somewhere and some extracted audio tracks.
+
+Then there is a YT copy which only has the game sound without mine or other people's voices in it for privacy reasons.
+
+I want the flow like this:
+
+1. Record on my PC
+2. Add to Annex on PC and git-annex transfer from PC to NAS or store recording on the NAS directly
+4. NAS automatically uploads the recording
+5. NAS automatically splits out the audio Streams and adds them to Annex
+
+Obviously, I'll need some custom scripts here for most of this but what would I do in case of a restore?
+
+I can get the videos via yt-dlp but they will have different content because YT reprocesses the video, so reinjecting isn't an option.
+
+Would addurl be an option somehow? It directly maps a YT video to a key which would allow me to download that instead of the original file in case it was lost but is it possible to make it consider the original file an instance of the URL somehow eventhough it was never downloaded from there?
+
+Would a custom backend make sense here?
+
+Would love to hear what you think how I could best approach this.
diff --git a/doc/forum/Back_up_videos_to_youtube__63__/comment_1_e81f72bfe678e2aceded518338be1473._comment b/doc/forum/Back_up_videos_to_youtube__63__/comment_1_e81f72bfe678e2aceded518338be1473._comment
new file mode 100644
index 0000000000..3d77260f98
--- /dev/null
+++ b/doc/forum/Back_up_videos_to_youtube__63__/comment_1_e81f72bfe678e2aceded518338be1473._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-15T16:23:30Z"
+ content="""
+
+	git-annex migrate --remove-size --backend=WORM foo
+	git-annex addurl --fast --file=foo https://www.youtube.com/...
+
+The migrate step makes git-annex stop caring about what the hash or
+size of the file is, so it will accept whatever gets downloaded from
+youtube.
+ """]]
diff --git a/doc/forum/Back_up_videos_to_youtube__63__/comment_2_6cb19f9c371d7cb046302ed193c77489._comment b/doc/forum/Back_up_videos_to_youtube__63__/comment_2_6cb19f9c371d7cb046302ed193c77489._comment
new file mode 100644
index 0000000000..01828a3371
--- /dev/null
+++ b/doc/forum/Back_up_videos_to_youtube__63__/comment_2_6cb19f9c371d7cb046302ed193c77489._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 2"
+ date="2022-08-18T11:27:12Z"
+ content="""
+Thank you, that works!
+
+Is it possible to register valid sha256s to a WORM file? I'd like to verify that the file I've got present in the local repo is still the one I initially had after migration.
+"""]]
diff --git a/doc/forum/Back_up_videos_to_youtube__63__/comment_3_ccb5cb5fe520b3f2a4822d85c246296f._comment b/doc/forum/Back_up_videos_to_youtube__63__/comment_3_ccb5cb5fe520b3f2a4822d85c246296f._comment
new file mode 100644
index 0000000000..36ca021436
--- /dev/null
+++ b/doc/forum/Back_up_videos_to_youtube__63__/comment_3_ccb5cb5fe520b3f2a4822d85c246296f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-08-19T16:56:13Z"
+ content="""
+WORM keys don't check the content of the file with a hash. That is the
+point of using them here.
+"""]]
diff --git a/doc/forum/Back_up_videos_to_youtube__63__/comment_4_303b4f755dd117f8b22c98669e7bf932._comment b/doc/forum/Back_up_videos_to_youtube__63__/comment_4_303b4f755dd117f8b22c98669e7bf932._comment
new file mode 100644
index 0000000000..1ce9bbf5d4
--- /dev/null
+++ b/doc/forum/Back_up_videos_to_youtube__63__/comment_4_303b4f755dd117f8b22c98669e7bf932._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="adding checksums to WORM keys"
+ date="2022-08-21T21:20:03Z"
+ content="""
+Related: [[todo/alternate_keys_for_same_content]].
+"""]]
diff --git a/doc/forum/Backend_migration_and_special_remotes.mdwn b/doc/forum/Backend_migration_and_special_remotes.mdwn
new file mode 100644
index 0000000000..b1cf885116
--- /dev/null
+++ b/doc/forum/Backend_migration_and_special_remotes.mdwn
@@ -0,0 +1,22 @@
+I have a large repository that is backed up to hubiC with the [special remote that I wrote](https://github.com/Schnouki/git-annex-remote-hubic). When I created this repository I used the WORM backend. But as I have some duplicated files I'd like to migrate to SHA256E to avoid storing them twice. However, when migrating a file, its location on the remote is not kept:
+
+    % git annex whereis "2015-07-25 12.28.16.jpg"
+    whereis 2015-07-25 12.28.16.jpg (2 copies) 
+            23fa590d-682d-43be-9851-8ba47186d763 -- [hubic]
+            f6642b89-2a0f-4788-8e13-be540fdfec58 -- baldr [here]
+    ok
+    
+    % git annex migrate "2015-07-25 12.28.16.jpg" --backend SHA256E
+    migrate 2015-07-25 12.28.16.jpg ok 
+    (recording state in git...)
+    
+    % git annex whereis "2015-07-25 12.28.16.jpg"
+    whereis 2015-07-25 12.28.16.jpg (1 copy) 
+            f6642b89-2a0f-4788-8e13-be540fdfec58 -- baldr [here]
+    ok
+
+Is there any way to store in the git-annex branch that migrated files are still available on remotes without having to re-upload all of them? hubiC is quite slow and I don't really want to re-upload 90 GB from a DSL connection…
+
+Or would it be possible to add something in the special remote protocol to "move" a key without re-uploading it?
+
+Thanks!
diff --git a/doc/forum/Backend_migration_and_special_remotes/comment_1_cf6d45c43b14719fc5ea41d0cbfb612d._comment b/doc/forum/Backend_migration_and_special_remotes/comment_1_cf6d45c43b14719fc5ea41d0cbfb612d._comment
new file mode 100644
index 0000000000..877594007e
--- /dev/null
+++ b/doc/forum/Backend_migration_and_special_remotes/comment_1_cf6d45c43b14719fc5ea41d0cbfb612d._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-18T16:47:02Z"
+ content="""
+A rename operation could be added to the interface for remotes. I suspect
+most remotes wouldn't be able to implement it (could hubic?), but it could
+be used when available.
+
+I'm not sure what to do in the migrate command to make it use such an
+interface though. It could try to move the files to their new names on each
+remote that supports the interface. But what about remotes that cannot be
+accessed?
+
+Could make a `git annex migrate --on remote`, to 
+migrate remotes peicemeal. Which would have to look back in the git history
+to find the old key that a file had been migrated from.
+Although then the user has to be careful to specify the same set of
+files that were migrated before.
+"""]]
diff --git a/doc/forum/Backing_up_photos_to_the_cloud.mdwn b/doc/forum/Backing_up_photos_to_the_cloud.mdwn
new file mode 100644
index 0000000000..0af14cbb80
--- /dev/null
+++ b/doc/forum/Backing_up_photos_to_the_cloud.mdwn
@@ -0,0 +1,13 @@
+I'm using git annex to manage my photo collection. The main reason is because my laptop doesn't have enough space to store all my photos, so I'm using git annex to create a sort of split repository between my laptop (which has some photos) and an external drive (which has everything). So far this has worked well, I have around 15,000 photos which is around 40GB.
+
+Now I also want to see if I can use git annex to improve my backup workflow. Previously I've just exported albums from my photo manager (iPhoto on OS X), zipped them up, and uploaded them to S3. I have lifecycle rules setup so that they are automatically replicated to a different region and archived to Glacier (it's a lot easier than dealing with Glacier directly). I am using this as a last resort backup in case everything else is lost, so it doesn't matter if it takes a while to access. This works well, except on it's own I don't really know what photos are stored where, which is where I'm hoping git annex can help.
+
+I've tried using the S3 remote, but there are a few things which I don't like:
+
+1) If the git repository is lost I can't recover the original paths, so I won't know which photo belongs in which album. As this is a last resort backup, if I ever need to get anything from here it's likely that the git repository is also lost. [JGit supports storing Git repositories in S3](http://www.fancybeans.com/blog/2012/08/24/how-to-use-s3-as-a-private-git-repository/), but that seems like the wrong way to solve this, I'd prefer just to have the original folder structure maintained.
+
+2) As there are 15,000 photos, that means 15,000 requests to S3 to upload them and another 15,000 each time I check them. On my connection I can upload to AWS at around 5MB/s, but due to latency that only means one or two photos per second. I'd prefer to just upload archives.
+
+As I understand encryption + chunking with a sufficiently large size (say 100Mb) would help solve the second problem, but as this is a last resort backup I don't want to have to worry about encryption keys or passphrases.
+
+It looks like a wrapper around the [archivedrive feature](https://git-annex.branchable.com/tips/offline_archive_drives/) (which archives, zips and uploads it to S3) would do what I want, but I'm wondering if there is a better way?
diff --git a/doc/forum/Backup_of_git-annex_repos.mdwn b/doc/forum/Backup_of_git-annex_repos.mdwn
new file mode 100644
index 0000000000..1e5663b2fd
--- /dev/null
+++ b/doc/forum/Backup_of_git-annex_repos.mdwn
@@ -0,0 +1,15 @@
+Hello,
+
+I use CrashPlan, a proprietary offsite backup system to backup a couple of git-annex repositories.
+
+CrashPlan backups the symlinks as symlinks as well as the .git directory. So all data is backuped. However, restoring it tedious.
+
+I identify a file that I want to restore, download it and get only the symlink. Now I can descent into the .git directory and get the correct blob the symlink points to.
+
+Are there any simple strategies getting a specific file from a git-annex repo if you only have file-based view on the repo?
+
+I can, of course, use direct mode, that would resolve this issue, but would prefer to use the safer indirect mode.
+
+Thanks for any ideas!
+
+Best!
diff --git a/doc/forum/Backup_of_git-annex_repos/comment_1_ed90e524606e394f7669fcba10846930._comment b/doc/forum/Backup_of_git-annex_repos/comment_1_ed90e524606e394f7669fcba10846930._comment
new file mode 100644
index 0000000000..3c38efe7ab
--- /dev/null
+++ b/doc/forum/Backup_of_git-annex_repos/comment_1_ed90e524606e394f7669fcba10846930._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-13T19:36:11Z"
+ content="""
+Suggest you restore everything except for `.git/annex/objects`.
+That should not be a lot of data to restore, but it will get
+you a fully working git repository back. Then you won't need the two-step
+process to restore a file, and can instead just restore the `.git/annex/objects`
+file that a symlink points to.
+"""]]
diff --git a/doc/forum/Backup_of_whole_Linux_system.mdwn b/doc/forum/Backup_of_whole_Linux_system.mdwn
new file mode 100644
index 0000000000..1408c9a52b
--- /dev/null
+++ b/doc/forum/Backup_of_whole_Linux_system.mdwn
@@ -0,0 +1,16 @@
+If I would want to back up my whole Linux system, what's unclear or maybe missing from Git Annex:
+
+I'm not exactly sure about the best way to import the files. Should I just copy over all the files (e.g. using `cp -ax /* .`, or maybe `rsync -a /* .` or so) to the repo, and then use `git annex add`? (Let's skip `/dev` and maybe other special files for now.)
+
+Let's say I added now all files to the annex.
+
+I would also want to store the owning user, group, and access attributes, and maybe other extended attributes (ACL, xattr).
+This is not yet covered by Git Annex (by default), right?
+This could be stored as annex metadata. Or maybe better in some other way, because this would be per file path, and not per file content.
+Has anyone already done sth like this? It should not be too hard to do this, right?
+
+I'm also not exactly sure how Git Annex handles symlinks. Would it store the original symlink? Or would it not handle them at all, and just add them to Git itself?
+
+There will be some overlap of the files with other Git Annex repos (e.g. this could contain a subset of pictures I have elsewhere).
+I would want that the annexed data files are shared with my much bigger Annex repo which contains all my main data (pictures and lots of other stuff).
+This is actually the main reason why I consider using Git Annex as well for this purpose, and not some other solution, so that I don't need to store data separately, and get other benefits (to simplify my backups).
diff --git a/doc/forum/Backup_of_whole_Linux_system/comment_1_bf48d93872bfadb5daaf02a10e699b79._comment b/doc/forum/Backup_of_whole_Linux_system/comment_1_bf48d93872bfadb5daaf02a10e699b79._comment
new file mode 100644
index 0000000000..908599abd0
--- /dev/null
+++ b/doc/forum/Backup_of_whole_Linux_system/comment_1_bf48d93872bfadb5daaf02a10e699b79._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="checkout borg remote"
+ date="2021-01-09T15:25:05Z"
+ content="""
+git and git-annex do not store a lot of filesystem metadata. [git-annex metadata](https://git-annex.branchable.com/metadata/) actually stores metadata attached to the file key, which means the metadata is attached to the file content not the file path. Filesystems attach metadata to the file location (within a file tree), so if you have two files with the same content but different permissions in different folders you couldn't represent that information using git-annex metadata.
+
+You might checkout using the `git-annex` [borg special remote](https://git-annex.branchable.com/special_remotes/borg/). You could backup your whole linux system to a borg repository (using standard borg commands). Then you can add that borg repo as a git-annex borg special remote so you could access the files from a git-annex perspective.
+"""]]
diff --git a/doc/forum/Backup_of_whole_Linux_system/comment_2_af49edff9174c2ee17391e78ac97d5f3._comment b/doc/forum/Backup_of_whole_Linux_system/comment_2_af49edff9174c2ee17391e78ac97d5f3._comment
new file mode 100644
index 0000000000..e34b8665e3
--- /dev/null
+++ b/doc/forum/Backup_of_whole_Linux_system/comment_2_af49edff9174c2ee17391e78ac97d5f3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="comment 2"
+ date="2021-01-09T20:14:21Z"
+ content="""
+Yes, I know, but I was basically asking whether anyone has developed an extension already to store such meta data (per path, not content), or done sth similar. Or maybe you could also interpret it as a feature request. Or basically I was just curious whether it makes sense to add some feature like that. I guess this would not be too complicated. So I'm mainly curious whether there are other problems which I don't see right now, or if this is a good or bad idea in general.
+
+Using the Borg special remote sounds like an interesting workaround.
+
+"""]]
diff --git a/doc/forum/Balanced_Parity.mdwn b/doc/forum/Balanced_Parity.mdwn
new file mode 100644
index 0000000000..e2c9af4b63
--- /dev/null
+++ b/doc/forum/Balanced_Parity.mdwn
@@ -0,0 +1,41 @@
+I am interested in using or extending git-annex to manage storage redundancy more efficiently than [[git-annex-numcopies]] allows.  In particular, I wish to be able to tolerate the loss of a repository when I don't have enough disk space for `numcopies 2` -- when my disk capacity is less than double the data size.
+
+
+For example, suppose I wish to store N = 1000 GB on k = 10 servers, each with 150 GB storage (so total storage is 1500 GB, which is less than the 2000 GB that would be required for `numcopies 2`).  For simplicity here, we'll presume that our data is in 1000 1GB files.
+
+We'll set the goal of being able to lose r = 3 servers without losing any data (which would reduce our total storage capacity to 7 * 150 GB = 1050 GB).
+
+This can be done by thinking of our files in groups of seven (k - r) and using parchive2 or similar to create 3 (r) parity files for each set:
+
+```
+Parity group 000: D000 D001 D002 D003 D004 D005 D006  P000.0 P000.1 P000.2
+Parity group 001: D007 D008 D009 D010 D011 D012 D013  P001.0 P001.1 P001.2
+...
+Parity group 141: D987 D988 D989 D990 D991 D992 D993  P141.0 P141.1 P141.2
+Parity group 142: D994 D995 D996 D997 D998 D999       P142.0 P142.1 P142.2
+```
+
+All files are still 1G -- we have used 1429 GB of storage, far less than the 4000 GB that would be required to achieve the same durability with `numcopies 4`.
+
+The trouble is that we now need to ensure that each parity group's files are scattered across all the repositories.  D001 must go in a different repository than D000.  D0002 must go in a different repository than the first two, etc.  git-annex's [[required_content]] mechanism allows allocating files to repositories based on properties of that file, not the presence or absence of other files.
+
+
+Generalizing to differently-sized files, differently-sized repositories, parity group sizes other than k, k changing over time, per-file r values, and trying to minimize churn, it seems to me that the simplest way to do this would be to run a solver that finds a 'best' allocation plan and then writes a metadata tag on every file with its intended home.  Each repository can then have a simple [[required_content]] rule with its own name and [[--auto|walkthrough/automatically_managing_content]] or the assistant can move the files around as necessary.  I'm imagining running the solver periodically, from a cron job or in the assistant.  The other moving part is launching `par2` to create parity files do recovery, which happens after the solver has commanded that all the relevant inputs be brought together on one machine and after `get --auto` invocations or the assistant have done the transfers.
+
+User interface points:
+
+1. User specifies how much disk space the solver should use in each repository.
+2. User specifies the desired durability of each file.  Probably with match expressions?
+3. User declares a repository lost with [[git-annex-dead]].  The solver will notice many degraded parity groups on the next run & emit a plan to start bringing together parity groups' files for `par2 r` runs.  Ideally, running `git-anenx-dead` would would stop any existing solver run & start a fresh solver run immediately.
+4. Report to user parity placement health (are all the files where they should be?  Is recovery finished?  About how much I/O needs to be done to finish?)
+5. Report to user the available storage space for additional content at each durability level (this is non-trivial given differently-sized repositories)
+6. Report to user the storage efficiency of the current arrangement, how much storage efficiency could be improved at various I/O costs, and allowing the user to select a (eg: re-grouping old and recently-written files into new parity groups would allow closer file-size matching, allowing smaller parity files for the smaller file set.)
+7. User specifies parity group size??  This is a trade-off between storage efficiency (larger groups → more efficient) and high-durability storage capacity when repository sizes differ (smaller groups AND repository size diversity → more high-durability storage capacity).  It's possible that there's some principled way to save the user the trouble of having to understand the mechanics of parity groups & choose a parity group size, but I'm unclear on how that would work, so my initial plan is to have the user specify this by the same mechanism that they specify desired durability.  A good UI could support this choice by showing what the effect of each option would be on storage capacity at each durability level. 
+
+
+See also
+
+* [[todo/Wishlist__58___Parity_files_on_all_files]]
+* [[todo/wishlist__58___Parity_files_for_encrypted_remotes]]
+* [[design/assistant/partial_content]]
+* [[forum/sparse_git_checkouts_with_annex]]
diff --git a/doc/forum/Bare_repo_on_USB_drive_not_providing_files.mdwn b/doc/forum/Bare_repo_on_USB_drive_not_providing_files.mdwn
new file mode 100644
index 0000000000..c4ac2c5b72
--- /dev/null
+++ b/doc/forum/Bare_repo_on_USB_drive_not_providing_files.mdwn
@@ -0,0 +1,17 @@
+Dear all,
+     In the first place I will explain what I want to achieve and then the way I figured out to do it. I have a lot of scientific simulations which I need to be traceable (cross check experiment version with code version, etc). I run them mostly on my ubuntu box (14.10, ext4)  and store them on an indirect repo. From time to time, I find useful to work on them on my laptop (OSX 10.10, low disk space, hfs+). 
+My idea was to full sync the main repo with a usb drive, and then at home get only the files I need to work from the USB drive.
+I faced a huge interoperability problem regarding the filesystem format. I tried using ext4, hfs+, fat32 and exfat. Regarding performance and stability, exfat is the only usable option between linux and osx (using hfs+ got the repo corrupted many times while writing from linux). However that forces me to use either a direct mode repo on the USB drive or a bare one. 
+
+Scenario 1: Direct mode on USB drive 
+While this worked in another case, in this case when setting up the repo with the assistant it deleted all symlinks from the main repo. I wasn't able to correctly do this and finally gave up. 
+Can anyone help me setting up this scenario? It will be like the following: 
+
+* ubuntu box (ext4): main repo, indirect mode, all files
+* usb drive (exfat): sync repo, direct mode, all files (having the files available is a plus)
+* osx laptop (hpfs+): partial repo, indirect mode, some files
+
+
+Scenario 2: Bare repo on USB drive 
+In this case the bare repo gets synced, with all data (2.6Gb). However when I clone it on the laptop, I get the  message that files are not available, it says that they are only on main repo. This puzzles me because files seem to be on the bare repo.
+What's wrong in this case? How can I debug this?
diff --git a/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_1_0738174fb6984b777ec0a221502106ac._comment b/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_1_0738174fb6984b777ec0a221502106ac._comment
new file mode 100644
index 0000000000..739ccc84fe
--- /dev/null
+++ b/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_1_0738174fb6984b777ec0a221502106ac._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-12-01T22:03:52Z"
+ content="""
+You should be able to use a direct mode repo on a USB drive.
+Of course, if you delete files from there, the deletion will propigate
+to other clones of that repo. It could be that there's some bug
+with direct mode repos that causes file deletions to be incorrectly
+committed; if so you could a) revert the bad commits and b) file a bug
+report with details to reproduce the problem.
+
+As to a bare repo on a USB drive, it will work too. It sounds to me like
+you forgot to run `git annex sync` after copying the files to that repo.
+And/or forgot to run `git annex sync` before asking git-annex to get
+the files from the drive.
+
+That is to say, the fulll process would be:
+
+Plug drive into first computer, and run in that computer's repo:
+
+	git annex copy --to usbdrive
+	git annex sync
+
+And then move drive to other computer, and run in that computer's
+repo:
+	
+	git annex sync
+	git annex copy --from usbdrive
+"""]]
diff --git a/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_2_1e07d1a9ddb88c0e1d84d8d88b7b4cc4._comment b/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_2_1e07d1a9ddb88c0e1d84d8d88b7b4cc4._comment
new file mode 100644
index 0000000000..778471f5ab
--- /dev/null
+++ b/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_2_1e07d1a9ddb88c0e1d84d8d88b7b4cc4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2014-12-02T17:33:27Z"
+ content="""
+Well, I'm glad you solved it.
+
+I'd recommend a bare repo on a USB drive because it's the simplest thing,
+but a non-bare repo will also work ok.
+"""]]
diff --git a/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_2_65d007284287e709a8f6f07dd8630f15._comment b/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_2_65d007284287e709a8f6f07dd8630f15._comment
new file mode 100644
index 0000000000..018d69afdb
--- /dev/null
+++ b/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_2_65d007284287e709a8f6f07dd8630f15._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmTNrhkVQ26GBLaLD5-zNuEiR8syTj4mI8"
+ nickname="Juan"
+ subject="I finally solved it"
+ date="2014-12-02T01:32:34Z"
+ content="""
+I fnally made it work. I tried git-annex sync wihtout luck. What tricked me was the size of the bare repo, it made me thought that it had the files. However after I've made a git annex get on the bare repo it got all the files and after that everthing worked as expected.
+So, if I don't get you wrong, it is safer to use a bare repo on the USB drive?
+Thanks for the help.
+Best regards,
+                     Juan
+"""]]
diff --git a/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_4_3bbce5d12ece481b669be10ef9a70f40._comment b/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_4_3bbce5d12ece481b669be10ef9a70f40._comment
new file mode 100644
index 0000000000..e70066b62b
--- /dev/null
+++ b/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_4_3bbce5d12ece481b669be10ef9a70f40._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmTNrhkVQ26GBLaLD5-zNuEiR8syTj4mI8"
+ nickname="Juan"
+ subject="I think I got it working, however, same setup works different on fat and exfat"
+ date="2014-12-09T15:04:37Z"
+ content="""
+After struggling a lot, I tried to do the same but with an fat32 drive. Seems that some of the problems I'm experiencing are due to some (linux) filesystem functions working different with fat and exfat.
+Just to get this right, using repos on USB drive formatted as fat32 works perfectly under linux and mac. When I go to the exfat drive, linux fails, and osx keeps working.
+Are you able to test it?
+Steps to reproduce it: 
+1)make a test repo on linux: cd /tmp; mkdir test_repo; cd test repo; git init; git annex init \"test repo on linux box\" 
+2) go to exfat drive and clone it: git clone /tmp/rest_repo
+
+> git clone /home/juan/juanc/tmp/prueba_git 
+Cloning into 'prueba_git'... 
+error: chmod on /media/juan/USB_LIVE/tmp/test1/prueba_git/.git/config.lock failed: Function not implemented 
+error: chmod on /media/juan/USB_LIVE/tmp/test1/prueba_git/.git/config.lock failed: Function not implemented 
+error: chmod on /media/juan/USB_LIVE/tmp/test1/prueba_git/.git/config.lock failed: Function not implemented 
+error: chmod on /media/juan/USB_LIVE/tmp/test1/prueba_git/.git/config.lock failed: Function not implemented 
+error: chmod on /media/juan/USB_LIVE/tmp/test1/prueba_git/.git/config.lock failed: Function not implemented  
+error: chmod on /media/juan/USB_LIVE/tmp/test1/prueba_git/.git/config.lock failed: Function not implemented 
+fatal: 'origin' does not appear to be a git repository 
+fatal: Could not read from remote repository. 
+ 
+Please make sure you have the correct access rights 
+and the repository exists. 
+
+"""]]
diff --git a/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_5_5e6202c319e75a9758bb8c2f32152e0f._comment b/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_5_5e6202c319e75a9758bb8c2f32152e0f._comment
new file mode 100644
index 0000000000..d833e15e6f
--- /dev/null
+++ b/doc/forum/Bare_repo_on_USB_drive_not_providing_files/comment_5_5e6202c319e75a9758bb8c2f32152e0f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-02-09T19:09:53Z"
+ content="""
+I had never heard of [exFAT](http://en.wikipedia.org/wiki/ExFAT) before.
+
+I guess you were mounting it in linux using the FUSE implementation of
+exFAT. It's not very surprising when FUSE filesystems leave off support
+for some syscalls. In this case, chmod.
+
+Since even git clone fails, git-annex obviously cannot work.
+
+A bare repository might be the only option if you're stuck using exFAT for
+some reason.
+"""]]
diff --git a/doc/forum/Basic_set_up_with_one_remote.mdwn b/doc/forum/Basic_set_up_with_one_remote.mdwn
new file mode 100644
index 0000000000..669c281d3d
--- /dev/null
+++ b/doc/forum/Basic_set_up_with_one_remote.mdwn
@@ -0,0 +1,14 @@
+Hi, I'm new to git annex and so far it's looking really useful. I'm convinced what I'm trying to achieve is possible, but I can't seem to hit upon the right combination. Here's what I'd like to set up.
+
+One server with git annex / rsync / ssh access, but configured such that it contains a history of all the files as a full backup.
+Two clients WITHOUT ssh access (these are portable machines and I'd rather not open any ports I don't absolutely have to).
+
+I've used the assistant to set up syncing between all three, using a jabber account to send signals and the server to pass on the files between the machines. This all works beautifully. But what I can't seem to get right is the server / backup aspect. If I set up the server using the assistant as a remote, and set it to "full backup" from the drop down list, it doesn't seem to have any files in the repository except in the .git/annex/objects folder. Which are all cryptic file names and not really accessible. If I run commands such as 
+
+> git annex find
+
+(which should list all files as far as I can tell) in the server repository, it doesn't list any files at all. As the clients are all set up as direct repositories I can't access any history of the files there, so this doesn't seem to be quite what I'm after. The sync is working, but I really want the backup / history aspect as well.
+
+Does anyone know if what I want is possible? If so hopefully I'm close and someone can point out where I've gone wrong. I'm not afraid of the command line, but the assistant is a very convenient way to get started. 
+
+Thanks for your help.
diff --git a/doc/forum/Basic_set_up_with_one_remote/comment_1_3ad06a0dbebf62e6440f549e77af59b6._comment b/doc/forum/Basic_set_up_with_one_remote/comment_1_3ad06a0dbebf62e6440f549e77af59b6._comment
new file mode 100644
index 0000000000..c262611075
--- /dev/null
+++ b/doc/forum/Basic_set_up_with_one_remote/comment_1_3ad06a0dbebf62e6440f549e77af59b6._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3HGoDpnOPob5jOjvIootmkve1-nCpRiI"
+ nickname="Kalle"
+ subject="ssh remote defaults to bare repo"
+ date="2014-05-06T06:10:06Z"
+ content="""
+Hi,
+
+When setting up a ssh remote the default is to create a repo without a human readable file structure. To achieve what you are looking for you have to initialize a git annex repo on the server and then add the remote to the clients. afaik this has to be done using the command line interface. 
+
+If i remember correctly you add remotes with `git remote add ssh://example.com/path/to/annex`
+
+Cant find the docs atm (I'm commuting and at my final dest)
+
+"""]]
diff --git a/doc/forum/Basic_set_up_with_one_remote/comment_2_59e18e759c907b8adabf8c34eef08065._comment b/doc/forum/Basic_set_up_with_one_remote/comment_2_59e18e759c907b8adabf8c34eef08065._comment
new file mode 100644
index 0000000000..40ed2c8b5a
--- /dev/null
+++ b/doc/forum/Basic_set_up_with_one_remote/comment_2_59e18e759c907b8adabf8c34eef08065._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl2I59wfwq505F9W0a6f7sFDcC9neWcc24"
+ nickname="Andrew"
+ subject="comment 2"
+ date="2014-05-06T12:45:05Z"
+ content="""
+OK that sounds reasonable. I'll give it a go.
+
+I don't mind so much that the remote is not human readable as I wont be browsing directly on the remote, but what I did find disconcerting is that I didn't seem to be able to access any files. For example if I lose both the client machines, how do I get access to the files on the remote?
+"""]]
diff --git a/doc/forum/Basic_set_up_with_one_remote/comment_3_5221a713ee3f65fa2740c9fa6cb1db0f._comment b/doc/forum/Basic_set_up_with_one_remote/comment_3_5221a713ee3f65fa2740c9fa6cb1db0f._comment
new file mode 100644
index 0000000000..43dbb5d635
--- /dev/null
+++ b/doc/forum/Basic_set_up_with_one_remote/comment_3_5221a713ee3f65fa2740c9fa6cb1db0f._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl2I59wfwq505F9W0a6f7sFDcC9neWcc24"
+ nickname="Andrew"
+ subject="Still missing something"
+ date="2014-05-06T17:35:20Z"
+ content="""
+On the server I ran
+
+git init
+git annex init
+
+On client I ran
+
+git init
+git annex init
+git annex direct
+
+then dropped some files in and ran
+
+git sync
+
+This didn't upload any files. I now have a broken link on the server without the actual file.
+
+When I tried to set up the server in the same way, then used the web assistant to create the repository on the client and then combine it with the manually created repository on the server, it actually worked for the first file. I could see a working link to the file it had just uploaded. But any subsequent files didn't reflect in the file structure. Additional files would show up in the .git/annex/objects folder, but again I have no way to explore these. git annex find showed nothing, git annex status showed only the first file and git log didn't show much. I tried re-adding this remote to a new annex repository, but it didn't give me access to the files or the history of the files. I'm confused!
+
+Is it me or is this not working as expected?
+"""]]
diff --git a/doc/forum/Basic_set_up_with_one_remote/comment_4_62e554a546e4b50d211f5f65446fd289._comment b/doc/forum/Basic_set_up_with_one_remote/comment_4_62e554a546e4b50d211f5f65446fd289._comment
new file mode 100644
index 0000000000..8cbe86666a
--- /dev/null
+++ b/doc/forum/Basic_set_up_with_one_remote/comment_4_62e554a546e4b50d211f5f65446fd289._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3HGoDpnOPob5jOjvIootmkve1-nCpRiI"
+ nickname="Kalle"
+ subject="Some guesses"
+ date="2014-05-06T19:43:02Z"
+ content="""
+If you don't need human readable file structure on the server you don't have to initialize the annex repo. Just create a \"remote server\" repo with the assistant and set it to \"full backup\" if you want all the files there all the time. Without the \"full backup\" setting I believe only files it thinks someone else needs will be uploaded.* This might solve your problem with symlinks as `git annex sync` syncs metadata, only moving actual data if required.
+
+I'm not sure if the `git-annex find` command will work on a bare repo I can't test as all my repos are configured so that I can access the files in a normal way. Running `git-annex whereis $file` on the client should allow you to check if a file has been uploaded.
+
+
+*Massive caveat as I'm really not sure
+"""]]
diff --git a/doc/forum/Batch_process__44___git_rm__44___and_locking.mdwn b/doc/forum/Batch_process__44___git_rm__44___and_locking.mdwn
new file mode 100644
index 0000000000..5eb1de0102
--- /dev/null
+++ b/doc/forum/Batch_process__44___git_rm__44___and_locking.mdwn
@@ -0,0 +1,7 @@
+Is it "safe" to run `git-annex addurl` or `git-annex registerurl` in batch mode on a git-annex repository while also occasionally executing `git rm` on that repository while the batch process is running?  By "safe", I mean "the `git rm` process will never crash due to the git lock file already existing."  Is there a way to ensure that a `git rm` invocation will not fail due to locking issues while keeping the batch process running?
+
+The only relevant information I can find on this is <https://git-annex.branchable.com/forum/locks_during_--batch_operations/>, which states that a batch process will not hold a single lock throughout its entire run but says nothing about whether a batch process uses a lock at all.
+
+(I am asking about this because we have a program that runs batch processes concurrently with `git rm` invocations, and very rarely there are crashes due to locking issues with `git rm`.  My boss now wants me to address these issues by shutting down any running batch processes before running `git rm`, but this will be a giant hassle that I wish to avoid if at all possible.)
+
+[[!meta author=jwodder]]
diff --git a/doc/forum/Batch_process__44___git_rm__44___and_locking/comment_1_6cb866b48f6426e7ecc4f8d6af5b710d._comment b/doc/forum/Batch_process__44___git_rm__44___and_locking/comment_1_6cb866b48f6426e7ecc4f8d6af5b710d._comment
new file mode 100644
index 0000000000..39a1edf016
--- /dev/null
+++ b/doc/forum/Batch_process__44___git_rm__44___and_locking/comment_1_6cb866b48f6426e7ecc4f8d6af5b710d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-04-07T16:42:16Z"
+ content="""
+The lock you need to worry about here is for `.git/index`,
+which both `git rm` and `git-annex addurl` need to modify
+(when the latter is adding new files, not adding urls to existing files).
+Unfortunately git's handling of that lock file doesn't play well with multiple
+processes (unlike git-annex's other lock files that it uses).
+
+With --batch, git-annex reads a line, handles it, outputs a response, and
+waits for the next line. It should not keep any lock held while it's
+waiting for the line. So, you should be able to schedule your `git rm`
+to happen at that point and not have problems with locks colliding.
+"""]]
diff --git a/doc/forum/Batch_process__44___git_rm__44___and_locking/comment_2_51667179ddb52ca5fa1166196c5d37e2._comment b/doc/forum/Batch_process__44___git_rm__44___and_locking/comment_2_51667179ddb52ca5fa1166196c5d37e2._comment
new file mode 100644
index 0000000000..cbfa1d56a0
--- /dev/null
+++ b/doc/forum/Batch_process__44___git_rm__44___and_locking/comment_2_51667179ddb52ca5fa1166196c5d37e2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2023-04-17T13:01:03Z"
+ content="""
+just to clarify/make sure -- is `registerurl` also subject to the same locking or only `addurl`?
+"""]]
diff --git a/doc/forum/Batch_process__44___git_rm__44___and_locking/comment_3_593879cc70e9a07a49fa663677f5c045._comment b/doc/forum/Batch_process__44___git_rm__44___and_locking/comment_3_593879cc70e9a07a49fa663677f5c045._comment
new file mode 100644
index 0000000000..447051215d
--- /dev/null
+++ b/doc/forum/Batch_process__44___git_rm__44___and_locking/comment_3_593879cc70e9a07a49fa663677f5c045._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-04-17T17:00:58Z"
+ content="""
+`registerurl` does not touch the git index so uses the usual git-annex
+locking that supports concurrency.
+
+Interestingly, `git commit` does not hold the index.lock while waiting for
+the editor anymore. Despite git's lock failure message still suggesting
+that as the most common reason for a lock to fail. So the window for this
+race is narrower than it used to be. (Also this surprisingly means that you
+can `git add` (or `git-annex add` while `git commit` is in the editor and
+stage files that will be included in the ongoing commit!)
+
+Also the index lock is just the git lock that I've seen be a problem
+before. git does have some other locks that could in some situation be a
+problem with concurrency. See core.filesreflocktimeout for one example.
+
+git-annex's locking method is not without problems either, see
+[[todo/withExclusiveLock_blocking_issue]].
+"""]]
diff --git a/doc/forum/Beginners_questions__58___limit_content_on_special_remotes___38___use_non-git_clients_for_r__47__w_access_on_shared_git-annex_server.mdwn b/doc/forum/Beginners_questions__58___limit_content_on_special_remotes___38___use_non-git_clients_for_r__47__w_access_on_shared_git-annex_server.mdwn
new file mode 100644
index 0000000000..7291bd4b0d
--- /dev/null
+++ b/doc/forum/Beginners_questions__58___limit_content_on_special_remotes___38___use_non-git_clients_for_r__47__w_access_on_shared_git-annex_server.mdwn
@@ -0,0 +1,13 @@
+Hi!
+
+I just discovered *git-annex* as a great way to move away from Dropbox, but there are some open questions I couldn't find answers for and hope someone will be able to answer them here:
+
+I didn't completely understand how remotes are treated. As far as I understand there are two different parts to sync, the metadata (which is stored in a regular git repository) and the regular file data (or only chunks of it?). When syncing, I can choose whether I want to only sync the git (-metadata) part, or if I want to include the file contents, right?
+
+1. Is it possible to sync only a *part* of the file contents to certain remotes? For example I would want all my ebooks and photos to be synced to my remote server, but wouldn't want my private accounting and tax stuff to sync over the internet. 
+2. I have several (regular) git repositories used for e.g. development. Can I store a regular (bare) git repository within a git-annex repository? Does this make sense, or should I (for whatever reason) avoid it?
+3. A great feature of the Dropbox app is the automatic upload of photos taken with my iPhone. I would like to adopt this kind of backup. So considering a remotely accessible server. Is there some way to make use of *special remotes* like WebDAV to allow uploads over a *non-git interface*?
+4. Is there a way to access files (read-only) over a non-git interface from some git-annex remote? So could I access e.g. some pdf document from a git-annex repository, when there is a WebDAV special remote? Or do I just misunderstand the concept of *special remotes*? Is there another (useful) way? Maybe some kind of (remotely accessible) web interface? 
+5. Why is git-annex [not a backup system](http://git-annex.branchable.com/not/)?
+
+Thank you in advance!
diff --git a/doc/forum/Beginners_questions__58___limit_content_on_special_remotes___38___use_non-git_clients_for_r__47__w_access_on_shared_git-annex_server/comment_1_871b5a42f1134a059df520993bb55268._comment b/doc/forum/Beginners_questions__58___limit_content_on_special_remotes___38___use_non-git_clients_for_r__47__w_access_on_shared_git-annex_server/comment_1_871b5a42f1134a059df520993bb55268._comment
new file mode 100644
index 0000000000..35346757a5
--- /dev/null
+++ b/doc/forum/Beginners_questions__58___limit_content_on_special_remotes___38___use_non-git_clients_for_r__47__w_access_on_shared_git-annex_server/comment_1_871b5a42f1134a059df520993bb55268._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="Replies to questions"
+ date="2015-01-28T05:34:16Z"
+ content="""
+1. Yes, see [[/preferred content]].
+2. Every time you change a file, git-annex stores that version of it indefinitely, until manually dropped or automatically expired by the git annex assistant daemon.  So every time you checked out a branch or made a commit or whatever, you'd be cluttering your annex with many different versions of the same files.  Since git is a pretty good way of keeping track of versions of files, and indeed syncing with other machines using `git push` and `git pull`, why would you want to put your git repos into another synchronisation system?  (You can certainly tar up your git repos and put them in your annex as a backup.)
+3. Git-annex can run on Android phones but there is no iOS app.  You could have some other app uploading to the server, and then the git-annex assistant could watch the directory the files were being uploaded to and automatically add the files to the annex and sync it to your workstation.
+4. If it's just a normal git remote then you can access it in the usual ways.  Special remotes generally either lack knowledge of the names of your files, or this information is stored opaquely in git.  That means that access via e.g. WebDAV would only let you see your files organised by SHA checksum which would be useless.  So you'd want the git-annex remote you were accessing with a non-git interface to be a normal git remote, not a special remote.
+5. I think that Joey Hess wrote that git-annex is not a backup system to mean that what it does is quite different to something like duplicity, and also to mean that if you just install git-annex and create a repository, nothing is actually being backed up at all: you've got to manually add a remote, and instruct git-annex to send stuff there.  You can certainly use git-annex to backup so long as you understand to what extent it is doing so.
+"""]]
diff --git a/doc/forum/Beginners_questions__58___limit_content_on_special_remotes___38___use_non-git_clients_for_r__47__w_access_on_shared_git-annex_server/comment_2_68d675096d9ea32780b8ec8526544b12._comment b/doc/forum/Beginners_questions__58___limit_content_on_special_remotes___38___use_non-git_clients_for_r__47__w_access_on_shared_git-annex_server/comment_2_68d675096d9ea32780b8ec8526544b12._comment
new file mode 100644
index 0000000000..2965054332
--- /dev/null
+++ b/doc/forum/Beginners_questions__58___limit_content_on_special_remotes___38___use_non-git_clients_for_r__47__w_access_on_shared_git-annex_server/comment_2_68d675096d9ea32780b8ec8526544b12._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="janis_e"
+ subject="comment 2"
+ date="2015-01-29T08:39:02Z"
+ content="""
+Thank you for these answers, especially the 4) makes sense to me and prevented me form blowing up my repository!
+"""]]
diff --git a/doc/forum/Behaviour_of_fsck.mdwn b/doc/forum/Behaviour_of_fsck.mdwn
new file mode 100644
index 0000000000..cd27d49f76
--- /dev/null
+++ b/doc/forum/Behaviour_of_fsck.mdwn
@@ -0,0 +1,13 @@
+The current behaviour of 'fsck' is a bit verbose. I have an annex'd directory of tarballs for my own build system for "science" applications, there's about ~600 or so blobs in my repo, I do occassionally like to run fsck across all my data to see what files don't meet the min num copies requirement that I have set.
+
+Would it be better for the default behaviour of fsck when it has not been given a path to only output errors and not bother to show that a file is ok for every single file in a repo. i.e.
+
+    git annex fsck
+
+should show only 'errors' and maybe a simple indicator showing the status (show a spinner or dots?) and when 
+
+    git annex fsck PATH/FILE 
+
+it should have the current behaviour? 
+
+Right now the current fsck behaviour might get annoying for anyone who would want to run fsck with repos with lots of big files.
diff --git a/doc/forum/Behaviour_of_fsck/comment_1_0e40f158b3f4ccdcaab1408d858b68b8._comment b/doc/forum/Behaviour_of_fsck/comment_1_0e40f158b3f4ccdcaab1408d858b68b8._comment
new file mode 100644
index 0000000000..dc48e2f943
--- /dev/null
+++ b/doc/forum/Behaviour_of_fsck/comment_1_0e40f158b3f4ccdcaab1408d858b68b8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-03-24T17:45:08Z"
+ content="""
+I tend to agree that the default output of fsck is not quite right. I often use git annex fsck -q. A progress spinner display is a good idea.
+"""]]
diff --git a/doc/forum/Behaviour_of_fsck/comment_2_ead36a23c3e6efa1c41e4555f93e014e._comment b/doc/forum/Behaviour_of_fsck/comment_2_ead36a23c3e6efa1c41e4555f93e014e._comment
new file mode 100644
index 0000000000..357b48a234
--- /dev/null
+++ b/doc/forum/Behaviour_of_fsck/comment_2_ead36a23c3e6efa1c41e4555f93e014e._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2011-03-26T10:57:41Z"
+ content="""
+After some thought, perhaps the default fsck output should be at least machine readable and copy and pasteable i.e.
+
+<pre>
+$ git annex fsck
+Files with errors
+
+    file1
+    file2
+
+</pre>
+
+so I can then copy the list of borked files and then just paste it into a for loop in my shell to recover the files. it's just an idea.
+"""]]
diff --git a/doc/forum/Behaviour_of_fsck/comment_3_97848f9a3db89c0427cfb671ba13300e._comment b/doc/forum/Behaviour_of_fsck/comment_3_97848f9a3db89c0427cfb671ba13300e._comment
new file mode 100644
index 0000000000..be34473c0a
--- /dev/null
+++ b/doc/forum/Behaviour_of_fsck/comment_3_97848f9a3db89c0427cfb671ba13300e._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 3"
+ date="2011-03-28T01:16:21Z"
+ content="""
+Another nice thing would be a summary of _what_ is wrong. I.e.
+
+    % git fsck
+    [...]
+    git-annex: 100 total failed
+      50 checksum failed
+      50 not enough copies exit
+
+And the same/similar for all other failure modes.
+
+
+-- RichiH
+"""]]
diff --git a/doc/forum/Behaviour_of_fsck/comment_4_e4911dc6793f98fb81151daacbe49968._comment b/doc/forum/Behaviour_of_fsck/comment_4_e4911dc6793f98fb81151daacbe49968._comment
new file mode 100644
index 0000000000..e8c9837462
--- /dev/null
+++ b/doc/forum/Behaviour_of_fsck/comment_4_e4911dc6793f98fb81151daacbe49968._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 2"
+ date="2011-03-25T11:23:04Z"
+ content="""
+FWIW, I wanted to suggest exactly the same thing.
+"""]]
diff --git a/doc/forum/Benefit_and_drawback_of_new_unlocked_file_mode_V6_vs_locked_mode.mdwn b/doc/forum/Benefit_and_drawback_of_new_unlocked_file_mode_V6_vs_locked_mode.mdwn
new file mode 100644
index 0000000000..e7be125197
--- /dev/null
+++ b/doc/forum/Benefit_and_drawback_of_new_unlocked_file_mode_V6_vs_locked_mode.mdwn
@@ -0,0 +1,4 @@
+Someone wrote: "Unlocked files are more difficult to synchronize (to check for
+modifications and to synchronize throught multiple remotes)."  Does it mean new
+unlocked file mode V6 takes more time to find modifications?  If not what is the
+drawbacks of this new unlocked file mode?
diff --git a/doc/forum/Benefit_and_drawback_of_new_unlocked_file_mode_V6_vs_locked_mode/comment_1_fef0122752291bdc583fdcfdd400d250._comment b/doc/forum/Benefit_and_drawback_of_new_unlocked_file_mode_V6_vs_locked_mode/comment_1_fef0122752291bdc583fdcfdd400d250._comment
new file mode 100644
index 0000000000..657839f467
--- /dev/null
+++ b/doc/forum/Benefit_and_drawback_of_new_unlocked_file_mode_V6_vs_locked_mode/comment_1_fef0122752291bdc583fdcfdd400d250._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-05-03T19:56:03Z"
+ content="""
+I guess you were reading this blogpost <https://rychly.gitlab.io/post/git-annex/> from 2016?
+
+I have not run into any performance issues, but apparently others have. Namely, direct mode (V5) is faster than using unlocked files with a V6 repo, see [How to improve performance with v6 repos](https://git-annex.branchable.com/forum/How_to_improve_performance_with_v6_repos__63__/) related to the difference between direct-mode and V6 unlocked. Joey has a long [TODO related to git smudge filters](https://git-annex.branchable.com/todo/smudge/) that I believe would resolve this performance issue. The other drawback of V6 is that Joey considers it beta: “I'd encourage you to not upgrade any production repositories to v6 yet. It's still in beta state and has known problems. Currently all known problems are only innefficiencies, but there could also still be bugs.” [v5_to_v6_upgrade_strategy](https://git-annex.branchable.com/forum/v5_to_v6_upgrade_strategy/).
+"""]]
diff --git a/doc/forum/Best_approach_for_central_sharing_and_multiple_users.mdwn b/doc/forum/Best_approach_for_central_sharing_and_multiple_users.mdwn
new file mode 100644
index 0000000000..6fc104cb8f
--- /dev/null
+++ b/doc/forum/Best_approach_for_central_sharing_and_multiple_users.mdwn
@@ -0,0 +1,8 @@
+Just a quick question: Can anyone recomment me a good to handle a centralized repository which is used by different users?
+
+Requirements: must work in direct mode on both sides, server is Linux, clients are Windows and operated by 2 different users.
+
+- Should the repository create bare or not?
+- Must the repository created on the server or can it also be "pushed" from one client to the server (via SSH on the server)?
+- Is there a better way for data transfer than SSH (WebDAV as in SVN)? I am still struggling with an elegant way to handle public keys in windows
+- What is the best way to not only keep meta data in sync but also the data each of the users has checked out?
diff --git a/doc/forum/Best_approach_for_central_sharing_and_multiple_users/comment_1_48ffb50b92588daec6887bf08f1b97f5._comment b/doc/forum/Best_approach_for_central_sharing_and_multiple_users/comment_1_48ffb50b92588daec6887bf08f1b97f5._comment
new file mode 100644
index 0000000000..17860d0372
--- /dev/null
+++ b/doc/forum/Best_approach_for_central_sharing_and_multiple_users/comment_1_48ffb50b92588daec6887bf08f1b97f5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-11T19:31:52Z"
+ content="""
+I suggest following this screencast: [[videos/git-annex_assistant_lan]]
+
+While it talks about a local network, this will also work with a server on the internet.
+"""]]
diff --git a/doc/forum/Best_approach_for_central_sharing_and_multiple_users/comment_2_6b9a20f9707da9d2cfc3697a538d6935._comment b/doc/forum/Best_approach_for_central_sharing_and_multiple_users/comment_2_6b9a20f9707da9d2cfc3697a538d6935._comment
new file mode 100644
index 0000000000..c77e9a8fd1
--- /dev/null
+++ b/doc/forum/Best_approach_for_central_sharing_and_multiple_users/comment_2_6b9a20f9707da9d2cfc3697a538d6935._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="171.67.173.91"
+ subject="comment 2"
+ date="2014-07-11T21:56:29Z"
+ content="""
+Thanks, great work!
+
+I wanted to avoid the assistant so far because I feel I do not get so much control (particularly which files are synced to the clients) but I think I'll start with the assistant ...
+
+
+"""]]
diff --git a/doc/forum/Best_option_for_dropable_compression_+_encryption.mdwn b/doc/forum/Best_option_for_dropable_compression_+_encryption.mdwn
new file mode 100644
index 0000000000..7282db1485
--- /dev/null
+++ b/doc/forum/Best_option_for_dropable_compression_+_encryption.mdwn
@@ -0,0 +1,15 @@
+I'm currently using a directory special remote with encryption for dropable storage for incompressible files but I also need one for compressible text files.
+
+Borg would be my go-to for encryption and compression for append-only storage needs and even comes with the additional benefit of best-in-class dedup (though that is not important in this case). Unfortunately, I need to be able to drop files from this remote, so Borg is out of the question.
+
+An encrypted directory would be an option since gpg does its own compression before encryption but I turned that off globally because it uses a horribly inefficient compression algorithm (gzip) which I never want when using it manually and definitely don't want on my already-existing encrypted directory special remote full of incompressible files.
+
+I'd be fine with gzip for this particular purpose but I haven't found a way to make git-annex call gpg with a certain compression flag in one remote but not the other. LMK if you're aware of one.
+
+Two other possible options I can think of that aren't implemented yet (AFAICT) would be:
+
+* customisable compression for special remotes  
+  (This would probably be the best option; efficient, customisable and simple)
+* storing the text files in an actual git repo encrypted with gcrypt
+
+How do you store compressible files which you might need to drop?
diff --git a/doc/forum/Best_option_for_dropable_compression_+_encryption/comment_1_1d55eb39e46eee8c5dd6e142e71289ad._comment b/doc/forum/Best_option_for_dropable_compression_+_encryption/comment_1_1d55eb39e46eee8c5dd6e142e71289ad._comment
new file mode 100644
index 0000000000..51c4d66966
--- /dev/null
+++ b/doc/forum/Best_option_for_dropable_compression_+_encryption/comment_1_1d55eb39e46eee8c5dd6e142e71289ad._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-05-31T19:17:43Z"
+ content="""
+Hi,
+take a look at the `remote.<name>.annex-gnupg-options` option.
+"""]]
diff --git a/doc/forum/Best_option_for_dropable_compression_+_encryption/comment_2_704eed4d3607ebbfc9c6f5c64e7a1507._comment b/doc/forum/Best_option_for_dropable_compression_+_encryption/comment_2_704eed4d3607ebbfc9c6f5c64e7a1507._comment
new file mode 100644
index 0000000000..332c354436
--- /dev/null
+++ b/doc/forum/Best_option_for_dropable_compression_+_encryption/comment_2_704eed4d3607ebbfc9c6f5c64e7a1507._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 2"
+ date="2021-05-31T19:26:52Z"
+ content="""
+Also, you can make gpg use bzip2 compression with `--compress-algo=bzip2 --bzip2-compress-level=<level>`
+"""]]
diff --git a/doc/forum/Best_way_to_extract_git-annex_object_files___40__with_correct_names__41___in_absence_of_git_log.mdwn b/doc/forum/Best_way_to_extract_git-annex_object_files___40__with_correct_names__41___in_absence_of_git_log.mdwn
new file mode 100644
index 0000000000..7d0ecadd71
--- /dev/null
+++ b/doc/forum/Best_way_to_extract_git-annex_object_files___40__with_correct_names__41___in_absence_of_git_log.mdwn
@@ -0,0 +1,18 @@
+# Best way to extract git-annex object files (with correct names) in absence of git log?
+
+**Issue**:
+
+  * any git log is missing, so restore not viable
+  * annex directory is empty, i.e. no symlinks (.git/annex present, though)
+  * annex A: .git/annex/transfer/download/failed contains files
+  * annex B: .git/annex/objects contains files
+  * git-annex fsck -A: checksums files present
+  * git-annex fix: no change
+  * git-annex sync [--content]: on B fetched objects, fails on A (iirc)
+  * git-annex find: nothing
+  * git-annex unused shows couple of files on annex A and B
+  * git-annex addunused && git-annex unlock makes them available but filename is missing: "unused.SHA256E-[...].pdf"
+
+**Question**: any chance of restoring those files with their correct names?
+
+Thanks i.a. for any recommendations.
diff --git a/doc/forum/Best_way_to_extract_git-annex_object_files___40__with_correct_names__41___in_absence_of_git_log/comment_1_a1827481a3ac140d58a4184121328d87._comment b/doc/forum/Best_way_to_extract_git-annex_object_files___40__with_correct_names__41___in_absence_of_git_log/comment_1_a1827481a3ac140d58a4184121328d87._comment
new file mode 100644
index 0000000000..770fed4425
--- /dev/null
+++ b/doc/forum/Best_way_to_extract_git-annex_object_files___40__with_correct_names__41___in_absence_of_git_log/comment_1_a1827481a3ac140d58a4184121328d87._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-04T16:50:59Z"
+ content="""
+By "git log", are you talking about the actual git history of the
+repository?
+
+If this repository is a clone from some other repository, then
+`git annex repair` may be able to help, by repairing the git repository
+damage with information from the other repository.
+
+The git repository is where the names of files are stored, so if you manage
+to completely lose that information, you're kind of out of luck.
+"""]]
diff --git a/doc/forum/Best_way_to_manage_files_on_removable_media__63__.mdwn b/doc/forum/Best_way_to_manage_files_on_removable_media__63__.mdwn
new file mode 100644
index 0000000000..d6d1206ae0
--- /dev/null
+++ b/doc/forum/Best_way_to_manage_files_on_removable_media__63__.mdwn
@@ -0,0 +1,18 @@
+I have a bunch of removable storage devices and was planning on storing my data across
+all of them.  I've run into an annoyance, and would like to see if anybody has any
+ideas.
+
+My goal was to have the full file tree on all the devices, but only a subset of the
+annexed data.  Where I have run into trouble is removing data from the system.  It
+seems that the "git annex unused" command checks remote branches as well as local ones
+when determining whether an object is referred to.
+
+This means that if I remove a file that is stored locally, "git annex unused" doesn't
+report the corresponding object as unused until I either connect and update all
+removable storage *or* remove the remote corresponding to the removable storage.  I
+posted a bug about this inconsistency named
+[[bugs/git annex unused considers remote branches which makes it inconsistent]].
+
+If I used the removable storage as a special remote, then I wouldn't have this issue,
+but I also wouldn't be able to conveniently use the files on it and manage the repo
+from it either.
diff --git a/doc/forum/Best_way_to_re-add_a_file_in_a_direct_and_crippled_annex_repository.mdwn b/doc/forum/Best_way_to_re-add_a_file_in_a_direct_and_crippled_annex_repository.mdwn
new file mode 100644
index 0000000000..c126f83735
--- /dev/null
+++ b/doc/forum/Best_way_to_re-add_a_file_in_a_direct_and_crippled_annex_repository.mdwn
@@ -0,0 +1,17 @@
+Hi!
+
+What is the best way to add again the content of file in an direct and crippled annex repository? I'm using such a repository on a SMB drive, with no symbolic links, that's why the repository is in direct mode.
+
+For example:
+
+`/disk/annex-rep/a.bin` contains the text `../.git/annex/objects/W3/M8/SHA256E-s4701522386--e486cce01b1870cee394a376a3acc64a608e84e38b85e6c21c29721cf14328e6.bin/SHA256E-s4701522386--e486cce01b1870cee394a376a3acc64a608e84e38b85e6c21c29721cf14328e6.bin`
+
+and I've got the real content in another directory, outside annex: /disk/a.bin (contains the binary data)
+
+I imagined this process:
+* replace `/disk/annex-rep/a.bin` with `/disk/a.bin``
+* update `git-annex:122/4b8/SHA256E-s4701522386--e486cce01b1870cee394a376a3acc64a608e84e38b85e6c21c29721cf14328e6.bin.log` by adding this repository uuid
+
+I tried `git annex reinject` but it didn't work.
+
+Is there another way?
diff --git a/doc/forum/Best_way_to_re-add_a_file_in_a_direct_and_crippled_annex_repository/comment_1_552e74f9573a34ec178f396b83252c3e._comment b/doc/forum/Best_way_to_re-add_a_file_in_a_direct_and_crippled_annex_repository/comment_1_552e74f9573a34ec178f396b83252c3e._comment
new file mode 100644
index 0000000000..439c985dcb
--- /dev/null
+++ b/doc/forum/Best_way_to_re-add_a_file_in_a_direct_and_crippled_annex_repository/comment_1_552e74f9573a34ec178f396b83252c3e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 1"
+ date="2013-11-26T19:54:21Z"
+ content="""
+There's a bug report asking that reinject work in direct mode. I just have not gotten around to it.
+
+Another way to do it would be to make a temp directory in your annex repository, move or copy the file to there, and `git annex add`. As long as you're not using the WORM backend, the checksum will be used, and so it'll see it's added the content of the file, and make the a.bin file have that content too.
+
+Off to see if I can easily add direct mode reinject now..
+"""]]
diff --git a/doc/forum/Best_way_to_re-add_a_file_in_a_direct_and_crippled_annex_repository/comment_2_33c57922714f204fc63c260b838f3712._comment b/doc/forum/Best_way_to_re-add_a_file_in_a_direct_and_crippled_annex_repository/comment_2_33c57922714f204fc63c260b838f3712._comment
new file mode 100644
index 0000000000..afc449ac2e
--- /dev/null
+++ b/doc/forum/Best_way_to_re-add_a_file_in_a_direct_and_crippled_annex_repository/comment_2_33c57922714f204fc63c260b838f3712._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 2"
+ date="2013-11-26T20:18:56Z"
+ content="""
+Turned out to be trivial, so it's supported now.
+"""]]
diff --git a/doc/forum/Best_way_to_remove_old_version_of_specific_file.mdwn b/doc/forum/Best_way_to_remove_old_version_of_specific_file.mdwn
new file mode 100644
index 0000000000..4727c75c01
--- /dev/null
+++ b/doc/forum/Best_way_to_remove_old_version_of_specific_file.mdwn
@@ -0,0 +1,24 @@
+Hi,
+
+I store lots of books under annex and every once in a while one of them gets updated and I don't really want to keep the old version. I know about the `unused` subcommand but it makes a bit difficult to identify what I would be dropping. I mean, at the point in time when I'm replacing a file I already know I don't want to keep in the annex, maybe there is a method that directly referrs to that file instead of globally garbage collecting obscurely named files. Now, this is what comes to my mind:
+
+Alternative a
+
+1. git-annex drop f
+2. git rm f
+3. mv new-f f
+4. git-annex add f
+
+Alternative b
+
+1. git-annex unlock f
+2. mv new-f f
+3. git-annex add f
+4. git commit -am blah
+5. git checkout HEAD^
+6. git-annex drop f
+7. git checkout master
+
+As you can see neither option is that pretty. Is there any way to say 'drop f in revision r' or something similar?
+
+Thank you!
diff --git a/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_1_1663dd9118cb1fee92ae3f8d812df79c._comment b/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_1_1663dd9118cb1fee92ae3f8d812df79c._comment
new file mode 100644
index 0000000000..8e075df1be
--- /dev/null
+++ b/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_1_1663dd9118cb1fee92ae3f8d812df79c._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-26T16:52:25Z"
+ content="""
+Your alternative B does not actually remove the old version of the file,
+because git-annex unlock keeps a copy in .git/annex/objects
+(except when using v6 mode with annex.thin).
+
+Alternative A is fine, if you just want to remove the old version
+of the file from the local repository. Other clones of the repository
+may still have the content of that file though.
+
+I use alternative A fairly frequently in my own repositories, and then
+sometimes followup with `git annex unused` in clones and dropping all
+unused files.
+"""]]
diff --git a/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_2_6580f6790404694b55d07a0e57d83336._comment b/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_2_6580f6790404694b55d07a0e57d83336._comment
new file mode 100644
index 0000000000..77b39470c4
--- /dev/null
+++ b/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_2_6580f6790404694b55d07a0e57d83336._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="memeplex"
+ avatar="http://cdn.libravatar.org/avatar/84a611000e819ef825421de06c9bca90"
+ subject="comment 2"
+ date="2017-07-08T15:37:13Z"
+ content="""
+Hi Joey, thank you for answering. I don't understand why alternative b won't work. Doesn't the add after the unlock revert to locked state?
+"""]]
diff --git a/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_3_c1f34ec908d7c4ad05c4360e29e68fb4._comment b/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_3_c1f34ec908d7c4ad05c4360e29e68fb4._comment
new file mode 100644
index 0000000000..6fd7012d4f
--- /dev/null
+++ b/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_3_c1f34ec908d7c4ad05c4360e29e68fb4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="memeplex"
+ avatar="http://cdn.libravatar.org/avatar/84a611000e819ef825421de06c9bca90"
+ subject="comment 3"
+ date="2017-07-08T15:47:47Z"
+ content="""
+I mean, as I understand it I unlock the file, modify it, re-add it, commit, go to the previous revision and drop the annexed old version there. I see this as an instance of the remove-old-annexed-version general case, which AFAIK is valid. What am I missing here? Should I lock instead of adding the new file?
+"""]]
diff --git a/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_4_160011717157fa8fca3a33b543c4d28d._comment b/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_4_160011717157fa8fca3a33b543c4d28d._comment
new file mode 100644
index 0000000000..f476e99466
--- /dev/null
+++ b/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_4_160011717157fa8fca3a33b543c4d28d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="Dropping all older versions of a file"
+ date="2023-07-29T12:57:02Z"
+ content="""
+Is there also a straight forward way to drop all versions of a specific file?
+
+In option 1, I always have to drop the file right away. In my use case it makes more sense to drop (all) older versions of a specific file from time to time.
+
+Typically I want to keep old versions (of other files), therefore I can't use drop unused. But for some specific files, I want to get rid of the history at some point in time (e.g., after the project they belong to is finished).
+
+Alternatively, is there a way to get all prior keys a specific file once pointed to? Then I could drop all these keys.
+"""]]
diff --git a/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_5_dfec54344742e2c8d6904333ff848c8c._comment b/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_5_dfec54344742e2c8d6904333ff848c8c._comment
new file mode 100644
index 0000000000..2ac014599f
--- /dev/null
+++ b/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_5_dfec54344742e2c8d6904333ff848c8c._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="No built-in way for dropping all old versions of a file AFAIK"
+ date="2023-07-29T17:43:41Z"
+ content="""
+@mario: AFAIK there's no built-in way to drop selected|all old versions of a file.
+
+Some Context:
+
+- [user asking pretty much the same](https://git-annex.branchable.com/forum/drop_old_versions_of_a_file/)
+- [me opening a (now vanished?) todo on making old versions available in a view](https://downloads.kitenet.net/gitweb/?p=git-annex.git;a=blob;f=doc/todo/View_for_old_versions_of_a_file.mdwn;h=2d7df8246ecc768556d76fc6a5693b3a17bc8726;hb=a268dbf4012dd1c843da5b7a0cfca0700775a94d)
+
+My [proposal above](https://downloads.kitenet.net/gitweb/?p=git-annex.git;a=blob;f=doc/todo/View_for_old_versions_of_a_file.mdwn;h=2d7df8246ecc768556d76fc6a5693b3a17bc8726;hb=a268dbf4012dd1c843da5b7a0cfca0700775a94d) would facilitate this (kinda), e.g. like this:
+
+[[!format  bash \"\"\"
+# enter a view with all versions of files in the foo directory
+git annex view --historical /=foo
+# in the repo toplevel there are now all versions of all files that were in the foo directory
+git annex drop # drop all versions of all files in the foo dir
+git annex drop MyFile.txt* # drop all versions of that one file named like this
+\"\"\"]]
+
+The `--historical` is not implemented, so you currently have two options:
+
+## 1. Checking out each relevant commit, then drop content from there
+
+[[!format  bash \"\"\"
+f=\"path/to/myfile.txt\"
+# find all commits that touched exactly that file path (except for the latest version)
+# parsing --follow to catch renames/moves will be more challenging
+git log --format=format:%H \"$f\" | tail -n+2 | while read commit;do
+    # go to that commit, then drop that file path
+    (set -x;git checkout $commit;git annex drop \"$f\")
+done
+# remember to switch back to your default branch afterwards
+\"\"\"]]
+
+## 2. Parsing the log to find the relevant keys to drop
+
+[[!format  bash \"\"\"
+# This lists all commits including filenames and annex paths of the file in question
+git log --patch --follow -- path/to/myfile.txt
+# You will need to parse this somehow and extract the keys, then drop them:
+git annex drop --key $KEY
+# This also catches renames (--follow)!
+\"\"\"]]
+
+I would also love a git-annex-native way to delete all old versions of a file reliably. I think option 2 above and/or the [new view feature I proposed](https://downloads.kitenet.net/gitweb/?p=git-annex.git;a=blob;f=doc/todo/View_for_old_versions_of_a_file.mdwn;h=2d7df8246ecc768556d76fc6a5693b3a17bc8726;hb=a268dbf4012dd1c843da5b7a0cfca0700775a94d) would be very helpful. 👍
+"""]]
diff --git a/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_6_e854d6b778bcb7dc1578cbc9c8fcaa42._comment b/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_6_e854d6b778bcb7dc1578cbc9c8fcaa42._comment
new file mode 100644
index 0000000000..0c315fa13f
--- /dev/null
+++ b/doc/forum/Best_way_to_remove_old_version_of_specific_file/comment_6_e854d6b778bcb7dc1578cbc9c8fcaa42._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Dropping all older versions of a file"""
+ date="2023-08-22T16:23:29Z"
+ content="""
+@mario interesting question..
+
+You could use `git log --raw` to list old versions of the file, and
+then use `git show` to find the git-annex key.
+
+Doable, but would take quite a lot of bother to script.
+I think it would be a good enhancement to git-annex to
+add a [[todo/command_to_list_keys_for_old_versions_of_files]].
+"""]]
diff --git a/doc/forum/Big_repository_vs._multiple_small.mdwn b/doc/forum/Big_repository_vs._multiple_small.mdwn
new file mode 100644
index 0000000000..c77dd02a55
--- /dev/null
+++ b/doc/forum/Big_repository_vs._multiple_small.mdwn
@@ -0,0 +1,8 @@
+I am new to git (but extensively used SVN).
+
+In SVN I could have a big fat repository but only check out sub-trees is it.
+Is that also common in git(-annex) / recommended?
+
+E.g., should I create a big-fat repos with all data I have (personal data, music, videos, ...) and check out only the appropriate subtress or create a repository for each purpose? E.g., one for Fotos, Music, OnTheGoData, ebooks, ...
+
+What happens if I have a git-annex repository checked out at my laptop (say, d:\Files) and within it, check out another one (e.g. d:\Files\Library)?
diff --git a/doc/forum/Big_repository_vs._multiple_small/comment_1_8e21ee3c674ef6e595bdab53dd5c2356._comment b/doc/forum/Big_repository_vs._multiple_small/comment_1_8e21ee3c674ef6e595bdab53dd5c2356._comment
new file mode 100644
index 0000000000..707a1cca6e
--- /dev/null
+++ b/doc/forum/Big_repository_vs._multiple_small/comment_1_8e21ee3c674ef6e595bdab53dd5c2356._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 1"
+ date="2014-04-14T15:32:34Z"
+ content="""
+In my setup I have one repository for each category (photos documents videos) it is faster then single giant repository plus it makes sharing with other people easier since you can let people clone one category at a time.
+"""]]
diff --git a/doc/forum/Big_repository_vs._multiple_small/comment_2_656c62351502492d20e8490242e51169._comment b/doc/forum/Big_repository_vs._multiple_small/comment_2_656c62351502492d20e8490242e51169._comment
new file mode 100644
index 0000000000..22fa765428
--- /dev/null
+++ b/doc/forum/Big_repository_vs._multiple_small/comment_2_656c62351502492d20e8490242e51169._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="128.12.90.218"
+ subject="comment 2"
+ date="2014-04-15T18:23:13Z"
+ content="""
+Thank you, that's a good point!
+
+Does this also mean that a repository in git(-annex) is \"all or nothing\"?
+
+For example, I cannot share/clone parts of it? Or define access rights within a repository?
+
+With SVN for example, I have a big repository \"university\" and it contains all stuff of projects/research. Each individual directory is only shared with the persons whom I worked together in this particular project. In short: In git, this should not be that way, right?
+"""]]
diff --git a/doc/forum/Big_repository_vs._multiple_small/comment_3_e9c44ea364513f090844f46af2ea46a1._comment b/doc/forum/Big_repository_vs._multiple_small/comment_3_e9c44ea364513f090844f46af2ea46a1._comment
new file mode 100644
index 0000000000..063260ba10
--- /dev/null
+++ b/doc/forum/Big_repository_vs._multiple_small/comment_3_e9c44ea364513f090844f46af2ea46a1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="Claes"
+ subject="comment 3"
+ date="2014-04-17T14:04:31Z"
+ content="""
+Yeah, git does not have the concept of checking out subdirectories that subversion does. You could, however, have different branches with different content that live in the same repo and therefore share the same git-annex backend, so there could be overlap between what files are in what branch without them using up much extra disk space.
+"""]]
diff --git a/doc/forum/Big_repository_vs._multiple_small/comment_4_82e13580426dc648688e4c26e7ed91ec._comment b/doc/forum/Big_repository_vs._multiple_small/comment_4_82e13580426dc648688e4c26e7ed91ec._comment
new file mode 100644
index 0000000000..e79e19814a
--- /dev/null
+++ b/doc/forum/Big_repository_vs._multiple_small/comment_4_82e13580426dc648688e4c26e7ed91ec._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 4"
+ date="2014-04-18T09:16:44Z"
+ content="""
+with git you can not checkout parts of a repo it is all or nothing but with annex you can download your files dir by dir. When you clone you get symlinks for all files but only the files you want are downloaded.
+"""]]
diff --git a/doc/forum/Big_repository_vs._multiple_small/comment_5_632aceb71dc6a4a9a4bb03de25a9b21a._comment b/doc/forum/Big_repository_vs._multiple_small/comment_5_632aceb71dc6a4a9a4bb03de25a9b21a._comment
new file mode 100644
index 0000000000..182263f397
--- /dev/null
+++ b/doc/forum/Big_repository_vs._multiple_small/comment_5_632aceb71dc6a4a9a4bb03de25a9b21a._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="74.61.144.53"
+ subject="comment 5"
+ date="2014-04-19T05:38:43Z"
+ content="""
+Thanks!
+
+But what to my question regarding checking out a repository within a repository?
+
+I will most likely have a \"home\" repository which I would check out at first level.
+
+Then, within one directory I would like to (only locally!) check out another, such as \"Library\".
+
+Something like mount ... to mount one FS within another mount point.
+
+For SVN I think there exist externals for that ...
+
+Does this work?
+
+
+
+"""]]
diff --git a/doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant.mdwn b/doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant.mdwn
new file mode 100644
index 0000000000..0079ecfee8
--- /dev/null
+++ b/doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant.mdwn
@@ -0,0 +1,37 @@
+Hello everyone,
+
+my problem is: I have added a Bitbucket gcrypt repository (to be used for metadata only); it works via git-annex sync but the Assistant ignores it completely. I can check from the Bitbucket webpage that the remote repository never gets updated by the Assistant, it only does when i run 'git-annex sync' manually.
+
+## Adding the repository:
+
+    git remote add bitbucket gcrypt::https://bitbucket.org/omissis/basic.git
+
+## Syncing to it is ok:
+
+    $ git-annex sync
+    commit  ok
+    pull bitbucket 
+    gcrypt: Development version -- Repository format MAY CHANGE
+    gcrypt: Decrypting manifest
+    [...]
+    ok
+    push bitbucket 
+    gcrypt: Development version -- Repository format MAY CHANGE
+    gcrypt: Decrypting manifest
+    [...]
+    ok
+
+## But it doesn't appear at all in the Assistant webapp!
+
+Even if I do "restart daemon".
+
+BTW, adding a local gcrypt repo works fine and it gets synced normally by the Assistant  (after creating a bare Git repo):
+
+    git remote add enc gcrypt::/tmp/enc
+
+My Git-annex version:
+
+    $ git-annex version
+    git-annex version: 5.20140412ubuntu1
+
+Anybody has any idea? My use case is that I have a computer behind a very restrictive firewall (only http and https are allowed) and I don't know how to sync it otherwise. I would like to avoid XMPP. Thanks!
diff --git a/doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant/comment_1_239ae08d8eb8b0d7fe52991b0bddc653._comment b/doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant/comment_1_239ae08d8eb8b0d7fe52991b0bddc653._comment
new file mode 100644
index 0000000000..7bce01150c
--- /dev/null
+++ b/doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant/comment_1_239ae08d8eb8b0d7fe52991b0bddc653._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-30T18:07:13Z"
+ content="""
+I think this is due to the format of the url. The webapp only supports
+gcrypt repos that are using ssh uris, or are on local drives.
+
+I think, though that this might only prevent the assistant from displaying the
+repo in the list of repos. I think it might still sync with it?
+"""]]
diff --git a/doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant/comment_2_8b91328473b384f347710ec634be710a._comment b/doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant/comment_2_8b91328473b384f347710ec634be710a._comment
new file mode 100644
index 0000000000..fc79c17ba6
--- /dev/null
+++ b/doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant/comment_2_8b91328473b384f347710ec634be710a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Agenta"
+ subject="comment 2"
+ date="2015-07-31T08:34:26Z"
+ content="""
+Unfortunately the Assistant doesn't sync to the https gcrypt repository at all! E.g. if I add a file, the file gets added to the other repositories (the Assistant syncs it in the background) but it doesn't get added to Bitbucket (https gcrypt).
+I know that because Bitbucket tells me when the latest change has been made; I can see that no change is reported unless I perform 'git-annex sync' manually.
+"""]]
diff --git a/doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant/comment_3_12a6bc61a7492650fd2baf9a1b796997._comment b/doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant/comment_3_12a6bc61a7492650fd2baf9a1b796997._comment
new file mode 100644
index 0000000000..4a7ad554a8
--- /dev/null
+++ b/doc/forum/Bitbucket_gcrypt_repository_doesn__39__t_appear_in_the_Assistant/comment_3_12a6bc61a7492650fd2baf9a1b796997._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-08-04T20:23:58Z"
+ content="""
+Well, the file is not uploaded to the bitbucket remote, because bitbucket
+doesn't support git-annex. Without git-annex-shell on the remote, git-annex
+cannot send files to it.
+
+Even if it did, it would need to be a ssh
+transport, not a http transport, since git-annex doesn't upload files over
+http (except to S3 or webdav remotes).
+
+I think that the assistant also assumes that http transport git remotes are
+read-only, and doesn't try to push to them. Which might be improvable,
+perhaps.
+"""]]
diff --git a/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__.mdwn b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__.mdwn
new file mode 100644
index 0000000000..ca96a074f6
--- /dev/null
+++ b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__.mdwn
@@ -0,0 +1,55 @@
+Hello,
+
+I'm not sure this is mature enough as a wishlist item so I put it in the forum.  Please move if it is appropriate.
+
+# Context, general need
+
+I'm considering using git-annex to store photos, yet what I'm needing might be useful in more general cases.
+
+The need in one sentence: **deal with files that change status from "precious, please keep n copies" to "junk, please delete it from everywhere you find it, now and forever"**.
+
+# More concrete need
+
+I take many photographs and am interested in git-annex comfort to ensure a number of copies of files exist at any time.
+
+Sometimes I can sort photos and reject bad ones shortly after taking a roll, typically before I could `git annex add` them.  Sometimes I do it much later, after they have been included in `git-annex` and stored in several places.
+
+## Rationale 1: releasing storage space
+
+I'm worried about having a lot of space still used by photographs that I actually don't want to keep.
+
+It's not marginal.  For example, at 30Mb per RAW photo, 300+ photos in an ordinary afternoon take 10Gb, from which up to one half could turn out rejected.  Whole photo/video collection is already probably much over 1Tb and growing.
+
+So we're talking about 5Gb per shooting day to be freed and already probably 100+Gb to free from remotes, so definitely something to consider.
+
+## Rationale 2: rejecting files once and for all, not having to repeat it
+
+Once I rejected a photograph, I'd like to never have to `rm`, `forget`, `drop` them or whatever again.  Ideally it would just be dropped from any back-end (that supports removing information) at any time in the future, perhaps with just a generic command/script like `git annex purge_the_junk_files`.
+
+# Questions
+
+* Q1 Is there a simple way to somehow "blacklist" a particular file so that from that moment on, any `sync`-like operation of `git-annex` involving a remote will remove the data of this file in that remote.
+* Q2 UI considerations. In my dreams, files could just be moved to a "junk" sub-folder (using photo sorting tools like e.g. geeqie), then a batch command would assign them the "blacklisted" or "junk" status.
+* Q3 I don't mind at this point if there are traces of where (in the filesystem tree) the now-rejected files were.  Perhaps it's easier to perform a different operation, that is completely forgetting the history of blacklisted files in the spirit of `git filter-branch`.
+
+Perhaps most of this can be done with simple configuration and a helper script.
+
+# Additional information
+
+* I'm wondering if some simple scheme like an actual `git filter-branch` in the local `git-annex` repo then some cleanup command (`git annex fsck`) then push to remote would have the intended effect.  Since this involves rewriting history I don't know how `git-annex` would like it.  But that's just a thought-experiment at this point.
+* The number of files to blacklist can quickly go to a few hundreds later thousands.  This might rule out some very naive implementations.
+* I can hack a bash script to perform whatever appropriate command so that given a solution to Q1 I have a solution to Q2.
+
+# Search before you post
+
+I've found other topics but they don't seem to even remotely deal with the topic here.  E.g.:
+
+* [[https://git-annex.branchable.com/forum/Backing_up_photos_to_the_cloud/]]
+* [[https://git-annex.branchable.com/forum/best_practices_for_importing_photos__63__/]]
+* [[https://git-annex.branchable.com/tips/automatically_adding_metadata/]] 
+
+[[https://git-annex.branchable.com/git-annex-forget/]] seems to be orthogonal (forget history of everything, but not delete data)
+
+This might be more-or-less on topic but confusing to me at this point : [[https://git-annex.branchable.com/forum/How_to_get_git-annex_to_forget_a_commit__63__/]]
+
+Thank you for your attention.
diff --git a/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_1_a224bf8ed9502053e9b95317db7b4bfa._comment b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_1_a224bf8ed9502053e9b95317db7b4bfa._comment
new file mode 100644
index 0000000000..46e78c2a8e
--- /dev/null
+++ b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_1_a224bf8ed9502053e9b95317db7b4bfa._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ subject="Sketch of implementation, request for comment"
+ date="2016-10-01T17:25:46Z"
+ content="""
+From forum entry [git annex drop not freeing space on filesystem](http://git-annex.branchable.com/forum/git_annex_drop_not_freeing_space_on_filesystem/) I understand that:
+
+* removing a file from the tree hierarchy (with `git rm`, maybe other ways) opens the possibility of freeing space locally
+* syncing with remotes propagates this possibility
+* `git annex dropunused --force` can free space
+
+So, if we have a way to remove files by content (through git, git annex, etc), e.g. starting from http://stackoverflow.com/questions/460331/git-finding-a-filename-from-a-sha1 , we can sketch a naive implementation:
+
+* (option 1, provides Q1 and Q2 above) run `git ls-tree` and filter output for blacklisted hashes (anyone knows a way to efficiently filter lines matching a pattern from a potentially big collection?), run git rm on the paths obtained
+* (option 2, provides Q3 above) run `git gilter-branch` with a filter spec that removes files by hash (is that possible?)
+* git sync with remotes
+* on each remote `git annex dropunused --force`
+
+Does that make sense?
+
+Thank you.
+
+"""]]
diff --git a/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_2_0f2e7cf29ad9d41e0041924e69425050._comment b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_2_0f2e7cf29ad9d41e0041924e69425050._comment
new file mode 100644
index 0000000000..672ea738d3
--- /dev/null
+++ b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_2_0f2e7cf29ad9d41e0041924e69425050._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-10-04T15:17:49Z"
+ content="""
+The answer to this question depends on how quickly you need to get rid of
+the files, and whether you want git-annex to generally keep the content of
+deleted and old versions of modified files or not.
+
+If you only want git-annex to keep the content of files that are present in
+the current branches and tags, then simply delete a file and commit will
+work. Later using `git annex unused` to finish getting rid of the content
+of deleted files that are not used by any branches/tags.
+
+If you want to keep the full history in general, but drop the content of
+specific files, then you need to use git-annex to drop the content before
+you delete the file. You can use `git annex whereis $file` to see everywhere that
+the content has gotten to, and then `git annex drop $file --from` each location
+(and from the local repository).
+
+If you need to immediately get rid of the content of some file, you can use
+the same procedure to check where it is and drop it from those locations.
+
+You don't need to filter old commits out of branches to use `git annex
+unused`; it only looks at the most recent commit in each branch, so once a
+file has been deleted from all branches it will be identified as unused.
+"""]]
diff --git a/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_3_a2cac051ef2d36e1ffb550c4a788c111._comment b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_3_a2cac051ef2d36e1ffb550c4a788c111._comment
new file mode 100644
index 0000000000..c540d55499
--- /dev/null
+++ b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_3_a2cac051ef2d36e1ffb550c4a788c111._comment
@@ -0,0 +1,101 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Work-in-progress, yet already usable, solution"
+ date="2017-03-09T12:19:49Z"
+ content="""
+TL;DR:  Thanks for clarifying the possibilities.  I chose to maintain an explicit blacklist of files that are definitely uninteresting, because it is safer and more convenient at several level (protect against mistakes, makes reviewing easier, fewer assumptions).  I share the proof-of-concept here in case anyone is interested in the future.  I might share some scripts on a public repo, especially if anyone shows interest.
+
+## Discussion
+
+> You don't need to filter old commits out of branches to use git annex unused; it only looks at the most recent commit in each branch, so once a file has been deleted from all branches it will be identified as unused.
+
+Okay, this is important to know (perhaps something to add to the documentation there).
+
+> (...) depends on how quickly you need to get rid of the files, and whether you want git-annex to generally keep the content of deleted and old versions of modified files or not.
+>
+> If you only want git-annex to keep the content of files that are present in the current branches and tags (...)
+
+In a perfect world, that would be enough.
+
+> If you want to keep the full history in general, but drop the content of specific files, (...)
+
+I realize that I need to keep the full history in general, because (it already happened) although I almost always make small independent commits and review changes before commit, large changes are relatively common.   For example renaming a directory that has many sub-directories full of files.  If some files are removed by mistake since the last commit, the information is drowned in a big change.  As git does not always track renames, it sometimes shows many additions/removal.  Also, changes are sometimes committed by a `git annex sync` (which I avoid for this reason).
+
+So, a file reported by `git unused` is not a proof that it should be deleted.
+
+So all in all, yes I \"want to keep the full history in general, but drop the content of specific files\".
+
+> then you need to use git-annex to drop the content before you delete the file.
+
+Okay, this works locally.  Yet I have started to work another way, see below.
+
+> You can use git annex whereis $file to see everywhere that the content has gotten to, and then git annex drop $file --from each location (and from the local repository).
+>
+> If you need to immediately get rid of the content of some file, you can use the same procedure to check where it is and drop it from those locations.
+
+This somehow assumes connectivity to other repositories at cleanup time, which is not practical.
+
+I might make a number of commits including some that locally prune hundreds of files, several times, before having access to any other repository.
+
+This does not leave a clear state of \"globally blacklisted\" file.
+
+
+
+**It seems to me that the situation needs maintain some state allowing to defer the removal to the time when repositories are available.**
+
+
+## Work-in-progress solution
+
+This evolved to working another way:
+
+* maintain (grow) a list of blacklisted keys that's stored somewhere in the repository and synced like any other (regular git) file.
+* have some script that can be run at any time from any repo and locally delete any file that's blacklisted.
+* variant: before locally dropping the file, check if, as far as this repo knows, it's really unused anywhere.
+
+### Proof-of-concept implementation
+
+#### Script `git_annex_drop_all_files_in_blacklist.sh`
+
+Good for a small blacklist when `git annex unused` is slow.
+
+    #!/bin/bash
+
+    set -eu # Safety, abort on error.
+
+    while read KEY REASON
+    do
+            echo Will drop blacklisted \"$KEY\"
+            git annex dropkey --force \"$KEY\"
+    done <blacklist
+
+
+#### Script to show all unused files
+
+This presents all unused files in a directory.
+They can be presented ordered by date or EXIF date for review.
+
+    #!/bin/bash
+
+    mkdir -p review_unused ; cd review_unused ; time git annex unused | while read NUMBER KEY ; do ln -s $( git annex contentlocation $KEY ) $KEY ; done ; xdg-open . &
+
+Files can then be interactively moved to other directories for further processing: reuse with `git add`, blacklist, etc.
+
+#### Other
+
+I have also written another experimental script that processes the output of `git annex unused`, automatically blacklists them in some specific cases and assists in reviewing or `git annex drop`ing them.
+
+## Additional benefit
+
+Storing state in a blacklist has the advantage of being very explicit and global.
+
+This has the advantage that the blacklist can potentially apply to content outside of any repository.
+For example, I find one of my memory cards for digital camera, that I've not used for a long time.  It has old copies of some photos.  The blacklist allows to delete immediately uninteresting files, then git-annex can tell if the remaining files are known and can be also deleted.  Then, either the card becomes empty, or only the (fewer) remaining files can be manually reviewed.  Quick and safe.
+
+<!--  LocalWords:  whereis dropkey EXIF mkdir ln contentlocation xdg
+ -->
+<!--  LocalWords:  ing
+ -->
+
+"""]]
diff --git a/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_4_d95647d91a33d1164a87344939cb769a._comment b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_4_d95647d91a33d1164a87344939cb769a._comment
new file mode 100644
index 0000000000..64282fb320
--- /dev/null
+++ b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_4_d95647d91a33d1164a87344939cb769a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 4"
+ date="2017-03-10T08:11:13Z"
+ content="""
+I use git-annex-metadata to tag files I don't want, then drop the content with that tag[1]. Then it doesn't matter if the content reappears, it'll get pruned at some point. Also easy to find any symlinks pointing at the unwanted content using git-annex-find :)
+
+[1] I actually move it to another remote on a 3TB drive which only has such unwanted content, and then delete it on there when I need more space on it. Doesn't matter if that drive fails, but allows a bit of a window for an \"actually, I do need that\" recovery.
+"""]]
diff --git a/doc/forum/Borg_and_xattrs.mdwn b/doc/forum/Borg_and_xattrs.mdwn
new file mode 100644
index 0000000000..b8ce3ee0e1
--- /dev/null
+++ b/doc/forum/Borg_and_xattrs.mdwn
@@ -0,0 +1,2 @@
+Not NFS, but I have Borg repos created and used on my Mac, subsequently turned into Borg special remotes for access by a Linux machine. Trying to   `get` file contents from there sometimes fails because I did not think to ignore xattrs while creating the archive, and these particular Apple xattrs-shenanigans aren't compatible with the extracting machine's filesystem (btrfs). `borg extract` has a `--noxattrs` option which I thought might be useful in general for git-annex, since all one usually wants is the actual file contents. Perhaps this could be implemented as a configuration parameter or otherwise passed somehow?
+
diff --git a/doc/forum/Borg_and_xattrs/comment_1_703c9a9be1e0b0ca9ce4dd0309546a04._comment b/doc/forum/Borg_and_xattrs/comment_1_703c9a9be1e0b0ca9ce4dd0309546a04._comment
new file mode 100644
index 0000000000..305659540f
--- /dev/null
+++ b/doc/forum/Borg_and_xattrs/comment_1_703c9a9be1e0b0ca9ce4dd0309546a04._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-09-03T16:07:53Z"
+ content="""
+I see no reason for it to need to preserve xattrs or ACLs.
+I've changed it to disable extracting those.
+"""]]
diff --git a/doc/forum/Borg_and_xattrs/comment_2_a1f4e0758c3e02f4f8558d167a26c0c4._comment b/doc/forum/Borg_and_xattrs/comment_2_a1f4e0758c3e02f4f8558d167a26c0c4._comment
new file mode 100644
index 0000000000..1b26f69d7c
--- /dev/null
+++ b/doc/forum/Borg_and_xattrs/comment_2_a1f4e0758c3e02f4f8558d167a26c0c4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 2"
+ date="2021-09-03T18:22:30Z"
+ content="""
+Sounds good to me. Thanks, Joey!
+"""]]
diff --git a/doc/forum/Box.com_hasn__39__t_been_working_for_a_few_days.mdwn b/doc/forum/Box.com_hasn__39__t_been_working_for_a_few_days.mdwn
new file mode 100644
index 0000000000..77b0928916
--- /dev/null
+++ b/doc/forum/Box.com_hasn__39__t_been_working_for_a_few_days.mdwn
@@ -0,0 +1,72 @@
+I've been experiencing problems with Box.com for a few days now and I don't know what's causing them. Is anyone else experiencing anything similar?
+
+I paste the log.
+
+    [2013-09-02 12:27:26 CEST] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9", transferKey = Key {keyName = "c9e1d5421e78924c21e3d68e84f80a8d1f64f9488020107ca0eeee0c4f10e763.py", keyBackendName = "SHA256E", keySize = Just 1891, keyMtime = Nothing}}
+    [2013-09-02 12:27:26 CEST] TransferScanner: queued Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/kgp/kant.xml Nothing : expensive scan found missing object
+    [2013-09-02 12:27:26 CEST] Transferrer: Transferring: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/argecho.py Nothing
+    [2013-09-02 12:27:26 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/argecho.py Nothing
+    [2013-09-02 12:27:26 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/argecho.py Nothing
+    
+    
+    100%          0.0 B/s 0s[2013-09-02 12:27:26 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/argecho.py Just 437
+    ResponseTimeout
+    ResponseTimeout
+    
+                            
+    [2013-09-02 12:27:44 CEST] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9", transferKey = Key {keyName = "dd3cc45d91430c6f7d68eb807f4ac1561cd0297b11a2de77b5fe66017d125798.py", keyBackendName = "SHA256E", keySize = Just 437, keyMtime = Nothing}}
+    [2013-09-02 12:27:44 CEST] TransferScanner: queued Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/kgp/kgp.dtd Nothing : expensive scan found missing object
+    [2013-09-02 12:27:44 CEST] Transferrer: Transferring: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/autosize.py Nothing
+    [2013-09-02 12:27:44 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/autosize.py Nothing
+    [2013-09-02 12:27:44 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/autosize.py Nothing
+    
+    
+    100%          0.0 B/s 0s[2013-09-02 12:27:44 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/autosize.py Just 2861
+    ResponseTimeout
+    ResponseTimeout
+    
+                            
+    [2013-09-02 12:28:02 CEST] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9", transferKey = Key {keyName = "d6b7940ac68768a8e37e72f248e2d94f19fb0d47062084d9baf0ec08cebbf692.py", keyBackendName = "SHA256E", keySize = Just 2861, keyMtime = Nothing}}
+    [2013-09-02 12:28:02 CEST] TransferScanner: queued Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/kgp/kgp.py Nothing : expensive scan found missing object
+    [2013-09-02 12:28:02 CEST] Transferrer: Transferring: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/builddialectexamples.py Nothing
+    [2013-09-02 12:28:03 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/builddialectexamples.py Nothing
+    [2013-09-02 12:28:03 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/builddialectexamples.py Nothing
+    
+    
+    100%          0.0 B/s 0s[2013-09-02 12:28:03 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/builddialectexamples.py Just 1090
+    ResponseTimeout
+    ResponseTimeout
+    
+                            
+    [2013-09-02 12:28:21 CEST] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9", transferKey = Key {keyName = "f1492b80d05b96cc7cf2904d461c99d430fa86a4eb1d99f1b155c9147ff4420f.py", keyBackendName = "SHA256E", keySize = Just 1090, keyMtime = Nothing}}
+    [2013-09-02 12:28:21 CEST] TransferScanner: queued Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/kgp/russiansample.xml Nothing : expensive scan found missing object
+    [2013-09-02 12:28:21 CEST] Transferrer: Transferring: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/colorize.py Nothing
+    [2013-09-02 12:28:21 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/colorize.py Nothing
+    [2013-09-02 12:28:21 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/colorize.py Nothing
+    
+    
+    100%          0.0 B/s 0s[2013-09-02 12:28:21 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/colorize.py Just 4864
+    ResponseTimeout
+    ResponseTimeout
+    
+    
+    [2013-09-02 12:28:40 CEST] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9", transferKey = Key {keyName = "b577eaf8b6ddbf9fef866c455cae248aec3b22e3f2e91aa2b75ece90f1801689.py", keyBackendName = "SHA256E", keySize = Just 4864, keyMtime = Nothing}}
+    [2013-09-02 12:28:40 CEST] TransferScanner: queued Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/kgp/stderr.py Nothing : expensive scan found missing object
+    [2013-09-02 12:28:40 CEST] Transferrer: Transferring: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/dialect.py Nothing
+    [2013-09-02 12:28:40 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/dialect.py Nothing
+    [2013-09-02 12:28:40 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/dialect.py Nothing
+    
+    
+    100%          0.0 B/s 0s[2013-09-02 12:28:40 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/dialect.py Just 4449
+    ResponseTimeout
+    ResponseTimeout
+    
+                            
+    [2013-09-02 12:28:58 CEST] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9", transferKey = Key {keyName = "c5e5d9b1bee2710c7ed05270a363d3e93270b0fb6779c4c8d59ace06c11db684.py", keyBackendName = "SHA256E", keySize = Just 4449, keyMtime = Nothing}}
+    [2013-09-02 12:28:58 CEST] TransferScanner: queued Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/kgp/stdout.py Nothing : expensive scan found missing object
+    [2013-09-02 12:28:58 CEST] Transferrer: Transferring: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/fibonacci.py Nothing
+    [2013-09-02 12:28:58 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/fibonacci.py Nothing
+    [2013-09-02 12:28:58 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/fibonacci.py Nothing
+
+
+    100%          0.0 B/s 0s[2013-09-02 12:28:58 CEST] TransferWatcher: transfer starting: Upload UUID "72111b4c-28fe-42fd-a77b-e4cb9240a1c9" Documentos/diveintopython-5.4/py/fibonacci.py Just 532
diff --git a/doc/forum/Box.com_hasn__39__t_been_working_for_a_few_days/comment_1_6ca872c241399b9129cf9a18f42ebd43._comment b/doc/forum/Box.com_hasn__39__t_been_working_for_a_few_days/comment_1_6ca872c241399b9129cf9a18f42ebd43._comment
new file mode 100644
index 0000000000..2c7d98b49d
--- /dev/null
+++ b/doc/forum/Box.com_hasn__39__t_been_working_for_a_few_days/comment_1_6ca872c241399b9129cf9a18f42ebd43._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://sunny256.sunbase.org/"
+ nickname="sunny256"
+ subject="It works here"
+ date="2013-09-02T11:47:00Z"
+ content="""
+I set up a box.com remote a couple of months ago or so just for testing. Haven't used it that much, but I tested it now to see if it still works. No errors or problems. I have pasted the output from a session where I copied a file to box.com, dropped it locally, then got it back from box.com here: <https://gist.github.com/sunny256/6411972>. The computer I ran the test on is using the newest git-annex binary (v4.20130827), Ubuntu 10.04.4 LTS. Pretty old distro, but it still works.
+"""]]
diff --git a/doc/forum/Broken_symlinks_remain_after_drop.mdwn b/doc/forum/Broken_symlinks_remain_after_drop.mdwn
new file mode 100644
index 0000000000..bc24049010
--- /dev/null
+++ b/doc/forum/Broken_symlinks_remain_after_drop.mdwn
@@ -0,0 +1,7 @@
+This is a newb question. I don't know whether this is a bug or the way git-annex is intended to function.
+
+I have two annex repos connected to each other. My idea was to have the first repository add files, which would then be moved to the second repository for storage. After moving, repo1 would be empty again, empty and clean of any symlinks.
+
+But after I 'git-annex move * --to repo2' broken symlinks remain in repo1. I don't want any broken/unused symlinks to remain in repo1 for object data it doesn't currently have (even if those files remain in the repository itself).
+
+Is there a way I can clean/remove broken symlinks to object data when those objects aren't present, so the directory only contains symlinks when the repo currently has the object data for those files?
diff --git a/doc/forum/Broken_symlinks_remain_after_drop/comment_1_d4a59b9e58d43d7a3d437e521dd5c4e1._comment b/doc/forum/Broken_symlinks_remain_after_drop/comment_1_d4a59b9e58d43d7a3d437e521dd5c4e1._comment
new file mode 100644
index 0000000000..33a9cb0581
--- /dev/null
+++ b/doc/forum/Broken_symlinks_remain_after_drop/comment_1_d4a59b9e58d43d7a3d437e521dd5c4e1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-06T15:30:54Z"
+ content="""
+git-annex is behaving as expected here. The broken symlink allows you to run `git annex get` on it to get the file content back into the repository, or `git mv` to rename the file even though its content is not present, etc.
+
+You can probably accomplish what you want by using git branches. You want a branch for repo2 that has all the files, and a branch for repo1 that has only the files in repo1. git-annex doesn't maintain such branches for you, but you can probably come up with a way to create such branches (`git annex find` will be useful when scripting up a solution).
+
+Or you can adopt the approach the git-annex assistant uses for archived files -- a archive/ directory, where files are moved when they're no longer wanted in the local system, so that their symlinks don't clutter up the view, while still being easily accessible when the time comes to pull something out of the archive.
+"""]]
diff --git a/doc/forum/Broken_symlinks_remain_after_drop/comment_2_399ba969a17a41a022c69a1f7c480857._comment b/doc/forum/Broken_symlinks_remain_after_drop/comment_2_399ba969a17a41a022c69a1f7c480857._comment
new file mode 100644
index 0000000000..f9225b0661
--- /dev/null
+++ b/doc/forum/Broken_symlinks_remain_after_drop/comment_2_399ba969a17a41a022c69a1f7c480857._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ghen1"
+ ip="66.41.70.34"
+ subject="comment 2"
+ date="2014-10-09T02:20:14Z"
+ content="""
+Thank you for your reply and suggestions. How could I maintain an archive folder on a local repo without those changes (moved files) being reflected in the other repos? Would this require branching as well? How does the assistant do it?
+"""]]
diff --git a/doc/forum/Building_Android_app_fails.mdwn b/doc/forum/Building_Android_app_fails.mdwn
new file mode 100644
index 0000000000..bf0e69ecb1
--- /dev/null
+++ b/doc/forum/Building_Android_app_fails.mdwn
@@ -0,0 +1,69 @@
+When trying to build the Android app, I'm able to successfully set up the chroot, and enter it. Once I am inside, as the user "builder" I get a failure on the second step of the installation process "In the chroot, run standalone/android/install-haskell-packages".
+
+When I run this command, I get the following error:
+
+    cbits/cryptonite_rdrand.c: In function ‘cryptonite_get_rand_bytes’:
+    
+    cbits/cryptonite_rdrand.c:63:2:
+         error: inconsistent operand constraints in an ‘asm’
+          asm(".byte 0x48,0x0f,0xc7,0xf0; setc %1" \
+          ^
+    
+    cbits/cryptonite_rdrand.c:78:3:
+         note: in expansion of macro ‘inline_rdrand_rax’
+           inline_rdrand_rax(tmp, ok);
+           ^
+    
+    cbits/cryptonite_rdrand.c:63:2:
+         error: inconsistent operand constraints in an ‘asm’
+          asm(".byte 0x48,0x0f,0xc7,0xf0; setc %1" \
+          ^
+    
+    cbits/cryptonite_rdrand.c:87:3:
+         note: in expansion of macro ‘inline_rdrand_rax’
+           inline_rdrand_rax(tmp, ok);
+           ^
+    
+    cbits/cryptonite_rdrand.c:63:2:
+         error: inconsistent operand constraints in an ‘asm’
+          asm(".byte 0x48,0x0f,0xc7,0xf0; setc %1" \
+          ^
+    
+    cbits/cryptonite_rdrand.c:87:3:
+         note: in expansion of macro ‘inline_rdrand_rax’
+           inline_rdrand_rax(tmp, ok);
+           ^
+    
+    cbits/cryptonite_rdrand.c:63:2:
+         error: inconsistent operand constraints in an ‘asm’
+          asm(".byte 0x48,0x0f,0xc7,0xf0; setc %1" \
+          ^
+    
+    cbits/cryptonite_rdrand.c:94:3:
+         note: in expansion of macro ‘inline_rdrand_rax’
+           inline_rdrand_rax(tmp, ok);
+           ^
+    cabal: Error: some packages failed to install:
+    cryptonite-0.16 failed during the building phase. The exception was:
+    ExitFailure 1
+
+So, there is a problem with building the haskell package "cryptonite-0.16".
+
+I also get this output a little further up:
+
+    Failed to install cryptonite-0.16
+    Build log ( /home/builder/.cabal/logs/cryptonite-0.16.log ):
+    Warning: cryptonite.cabal: Unknown fields: extra-doc-files (line 37)
+    Fields allowed in this section:
+    name, version, cabal-version, build-type, license, license-file,
+    copyright, maintainer, build-depends, stability, homepage,
+    package-url, bug-reports, synopsis, description, category, author,
+    tested-with, data-files, data-dir, extra-source-files,
+    extra-tmp-files
+
+So perhaps that is helpful as well.
+
+
+If anyone has any guidance on how to move beyond this or what needs to be changed, I'd appreciate it!
+
+Thanks!
diff --git a/doc/forum/Building_Android_app_fails/comment_1_094b90cbc1e2e069900c0037fec145ad._comment b/doc/forum/Building_Android_app_fails/comment_1_094b90cbc1e2e069900c0037fec145ad._comment
new file mode 100644
index 0000000000..6d735d4cf9
--- /dev/null
+++ b/doc/forum/Building_Android_app_fails/comment_1_094b90cbc1e2e069900c0037fec145ad._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-06-09T19:27:03Z"
+ content="""
+FWIW, my android autobuilder currently has cryptonite-0.15 installed.
+
+Seems that version is not frozen in the cabal.config for android,
+so tried a newer one in your case. I'm not sure if that will fix your
+problem, but it may be worth a try.
+"""]]
diff --git a/doc/forum/Building_a_Debian_package_of_git-annex.mdwn b/doc/forum/Building_a_Debian_package_of_git-annex.mdwn
new file mode 100644
index 0000000000..ee222df29d
--- /dev/null
+++ b/doc/forum/Building_a_Debian_package_of_git-annex.mdwn
@@ -0,0 +1,27 @@
+I'd like to have a Debian/Ubuntu package of the latest git-annex (f.e. to have it installed systemwide). In the source I can find the debian/ folder with all needed information to build the package. But it looks like I don't have all needed dependencies on my Ubuntu 12.10:
+
+    user@laptop(pc) ~/src/git/git-annex (git)-[master] % debuild -us -uc
+    dpkg-buildpackage -rfakeroot -D -us -uc
+    dpkg-buildpackage: source package git-annex
+    dpkg-buildpackage: source version 3.20130115
+    dpkg-buildpackage: source changed by Joey Hess <joeyh@debian.org>
+    dpkg-source --before-build git-annex
+    dpkg-buildpackage: host architecture amd64
+    dpkg-checkbuilddeps: Unmet build dependencies: libghc-dav-dev (>= 0.3) libghc-dbus-dev (>= 0.10.3) libghc-yesod-dev libghc-yesod-static-dev libghc-yesod-default-dev libghc-hamlet-dev libghc-clientsession-dev libghc-warp-dev libghc-wai-dev libghc-wai-logger-dev libghc-case-insensitive-dev libghc-http-types-dev libghc-blaze-builder-dev libghc-crypto-api-dev libghc-network-multicast-dev libghc-network-info-dev libghc-safesemaphore-dev libghc-network-protocol-xmpp-dev (>= 0.4.3-1+b1) libghc-gnutls-dev (>= 0.1.4) libghc-xml-types-dev
+    dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
+    dpkg-buildpackage: warning: (Use -d flag to override.)
+    debuild: fatal error at line 1357:
+    dpkg-buildpackage -rfakeroot -D -us -uc failed
+    user@laptop(pc) ~/src/git/git-annex (git)-[master] % apt-get install libghc-dav-dev libghc-dbus-dev libghc-yesod-dev libghc-yesod-static-dev libghc-yesod- default-dev libghc-hamlet-dev libghc-clientsession-dev libghc-warp-dev libghc-wai-dev libghc-wai-logger-dev libghc-case-insensitive-dev libghc-http-types-dev libghc-blaze-builder-dev libghc-crypto-api-dev libghc-network-multicast-dev libghc-network-info-dev libghc-safesemaphore-dev libghc-network-protocol-xmpp-dev libghc-gnutls-dev libghc-xml-types-dev
+    Reading package lists... Done
+    Building dependency tree       
+    Reading state information... Done
+    E: Unable to locate package libghc-dav-dev
+    E: Unable to locate package libghc-network-multicast-dev
+    E: Unable to locate package libghc-network-info-dev
+    E: Unable to locate package libghc-safesemaphore-dev
+
+How can I build the package? Or would it be possible for you to build the package and add it to the "Install" page (like the prebuilt linux tarball)? That would be great!
+
+Cheers and thanks for the hard work,
+Tobias
diff --git a/doc/forum/Building_a_Debian_package_of_git-annex/comment_1_0848513c46f3efa21bc34784554ae88a._comment b/doc/forum/Building_a_Debian_package_of_git-annex/comment_1_0848513c46f3efa21bc34784554ae88a._comment
new file mode 100644
index 0000000000..39790c5ffd
--- /dev/null
+++ b/doc/forum/Building_a_Debian_package_of_git-annex/comment_1_0848513c46f3efa21bc34784554ae88a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 1"
+ date="2013-01-16T23:05:13Z"
+ content="""
+There is a package available already: <http://packages.debian.org/unstable/git-annex>
+
+This will install even on Debian stable, I think.
+"""]]
diff --git a/doc/forum/Building_git-annex-3.20121112-19309.mdwn b/doc/forum/Building_git-annex-3.20121112-19309.mdwn
new file mode 100644
index 0000000000..68d5e32050
--- /dev/null
+++ b/doc/forum/Building_git-annex-3.20121112-19309.mdwn
@@ -0,0 +1,78 @@
+Hi,
+
+I have Problems building git-annex-3.20121112-19309, I rceive the following error:
+
+...
+  Loading object (static) dist/build/git-annex/git-annex-tmp/Utility/libmounts.o ... done
+  final link ... done
+
+  Assistant/Alert.hs:66:30:
+      Warning: default newline style has changed, using an explicit $newline is recommended
+
+  Assistant/Alert.hs:69:31:
+      Warning: default newline style has changed, using an explicit $newline is recommended
+  [157 of 279] Compiling Assistant.Types.DaemonStatus ( Assistant/Types/DaemonStatus.hs, dist/build/git-annex/git-annex-tmp/Assistant/Types/DaemonStatus.o )
+  [158 of 279] Compiling Assistant.Monad  ( Assistant/Monad.hs, dist/build/git-annex/git-annex-tmp/Assistant/Monad.o )
+
+  Assistant/Monad.hs:86:16:
+      Couldn't match expected type `Assistant a'
+                  with actual type `Reader AssistantData a'
+      Expected type: (AssistantData -> a) -> Assistant a
+        Actual type: (AssistantData -> a) -> Reader AssistantData a
+      In the expression: reader
+      In an equation for `getAssistant': getAssistant = reader
+
+  Assistant/Monad.hs:93:15:
+      Couldn't match expected type `Assistant t0'
+                  with actual type `Reader r0 a0'
+      In the return type of a call of `reader'
+      In a stmt of a 'do' block: st <- reader threadState
+      In the expression:
+        do { st <- reader threadState;
+             liftIO $ runThreadState st a }
+
+  Assistant/Monad.hs:99:14:
+      Couldn't match expected type `Assistant t0'
+                  with actual type `Reader r0 a0'
+      In the return type of a call of `reader'
+      In a stmt of a 'do' block: d <- reader id
+      In the expression:
+        do { d <- reader id;
+             liftIO $ io $ runAssistant d a }
+
+  Assistant/Monad.hs:105:14:
+      Couldn't match expected type `Assistant t0'
+                  with actual type `Reader r0 a0'
+      In the return type of a call of `reader'
+      In a stmt of a 'do' block: d <- reader id
+      In the expression:
+        do { d <- reader id;
+             return $ runAssistant d a }
+
+  Assistant/Monad.hs:110:14:
+      Couldn't match expected type `Assistant t0'
+                  with actual type `Reader r0 a0'
+      In the return type of a call of `reader'
+      In a stmt of a 'do' block: d <- reader id
+      In the expression:
+        do { d <- reader id;
+             return $ \ v -> runAssistant d $ a v }
+
+  Assistant/Monad.hs:115:14:
+      Couldn't match expected type `Assistant t0'
+                  with actual type `Reader r0 a0'
+      In the return type of a call of `reader'
+      In a stmt of a 'do' block: d <- reader id
+      In the expression:
+        do { d <- reader id;
+             return $ \ v1 v2 -> runAssistant d (a v1 v2) }
+
+  Assistant/Monad.hs:120:12:
+      Couldn't match expected type `Assistant a0'
+                  with actual type `Reader r0 a1'
+      In the return type of a call of `reader'
+      In the first argument of `(>>=)', namely `reader v'
+      In the expression: reader v >>= liftIO . io
+  cabal: Error: some packages failed to install:
+  git-annex-3.20121112 failed during the building phase. The exception was:
+  ExitFailure 1
diff --git a/doc/forum/Building_git-annex-3.20121112-19309/comment_1_b115e28c77fe748ee6643c41f766beb4._comment b/doc/forum/Building_git-annex-3.20121112-19309/comment_1_b115e28c77fe748ee6643c41f766beb4._comment
new file mode 100644
index 0000000000..3b75dfeb6d
--- /dev/null
+++ b/doc/forum/Building_git-annex-3.20121112-19309/comment_1_b115e28c77fe748ee6643c41f766beb4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.11.120"
+ subject="comment 1"
+ date="2012-11-18T17:49:57Z"
+ content="""
+What platform are you building on? 
+
+What version of ghc is installed?
+
+What version of the haskell mtl library is installed? (`cabal list --installed --simple-output mtl`)
+"""]]
diff --git a/doc/forum/Building_git-annex-3.20121112-19309/comment_2_8c6ae1fd74f14da12ccfa77dbd27fc65._comment b/doc/forum/Building_git-annex-3.20121112-19309/comment_2_8c6ae1fd74f14da12ccfa77dbd27fc65._comment
new file mode 100644
index 0000000000..195f639919
--- /dev/null
+++ b/doc/forum/Building_git-annex-3.20121112-19309/comment_2_8c6ae1fd74f14da12ccfa77dbd27fc65._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmU_2tE75oyG0h2ZPN4lcroIKEMC8G-otE"
+ nickname="Michael"
+ subject="comment 2"
+ date="2012-11-19T06:57:54Z"
+ content="""
+This is an Ubuntu 12.04 system (3.2.0-29-generic-pae #46-Ubuntu SMP Fri Jul 27 17:25:43 UTC 2012 i686 i686 i386 GNU/Linux)
+
+ghc is 7.4.1
+
+mtl info is:
+
+MonadCatchIO-mtl 0.3.0.5
+mtl 2.0.1.0
+
+"""]]
diff --git a/doc/forum/Building_git-annex-3.20121112-19309/comment_3_2f30b301c14f3a7fa0f52715d6140353._comment b/doc/forum/Building_git-annex-3.20121112-19309/comment_3_2f30b301c14f3a7fa0f52715d6140353._comment
new file mode 100644
index 0000000000..d4f48434cb
--- /dev/null
+++ b/doc/forum/Building_git-annex-3.20121112-19309/comment_3_2f30b301c14f3a7fa0f52715d6140353._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 3"
+ date="2012-11-25T18:56:01Z"
+ content="""
+On my Debian system, where it builds ok, I have the same ghc version, but version 2.1.1 of mtl. I suspect your old version of that is the problem. You can try using cabal to install a newer mtl:
+
+<pre>
+  cabal update
+  cabal install mtl
+</pre>
+"""]]
diff --git a/doc/forum/Building_git-annex-3.20121112-19309/comment_4_1e3c3903a71a2ff7109372aa4dd5742a._comment b/doc/forum/Building_git-annex-3.20121112-19309/comment_4_1e3c3903a71a2ff7109372aa4dd5742a._comment
new file mode 100644
index 0000000000..1b59c3d2d0
--- /dev/null
+++ b/doc/forum/Building_git-annex-3.20121112-19309/comment_4_1e3c3903a71a2ff7109372aa4dd5742a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 4"
+ date="2012-11-25T20:26:33Z"
+ content="""
+I was able to reproduce this build failure with the same old version of mtl you have. I've adjusted the cabal build dependencies to require a newer version.
+"""]]
diff --git a/doc/forum/CD-R_as_special_remote.mdwn b/doc/forum/CD-R_as_special_remote.mdwn
new file mode 100644
index 0000000000..b106df9cd5
--- /dev/null
+++ b/doc/forum/CD-R_as_special_remote.mdwn
@@ -0,0 +1,10 @@
+I would like to use a CD-R as a special remote for one of my repositories. I'm not sure what the best way to do this is. I'm thinking aomething like:
+
+1. Make a new directory
+2. Add the directory as a special remote using type=directory
+3. Copy the files to the special remote
+4. Create an iso of the directory and burn it
+
+Does that sound right?
+
+I'm not sure how I can do stuff like tell git-annex that the maximum size of the remote is 700MB and that (after the initial push) the remote should be considered read only. I intend to have multiple of these CD-R/directory remotes for the one annex. Has anybody done anything like this before?
diff --git a/doc/forum/CD-R_as_special_remote/comment_1_e5d6d72953575d2bbfb6c620bb4c9454._comment b/doc/forum/CD-R_as_special_remote/comment_1_e5d6d72953575d2bbfb6c620bb4c9454._comment
new file mode 100644
index 0000000000..dd84eb60d2
--- /dev/null
+++ b/doc/forum/CD-R_as_special_remote/comment_1_e5d6d72953575d2bbfb6c620bb4c9454._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-13T18:14:33Z"
+ content="""
+This was previously discussed in <http://git-annex.branchable.com/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/>.
+
+I don't think that CDs/DVDs are a particularly good fit for git-annex, but it
+seems a couple of users have gotten something working.
+"""]]
diff --git a/doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__.mdwn b/doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__.mdwn
new file mode 100644
index 0000000000..f4878da200
--- /dev/null
+++ b/doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__.mdwn
@@ -0,0 +1,19 @@
+Hi,
+
+I try to install git-annex master with cabal, so I cloned the git repo and run "cabal install --only-dependencies". This gives me the following error:
+
+    Resolving dependencies...
+    cabal: Could not resolve dependencies:
+    trying: git-annex-3.20120826 (user goal)
+    trying: git-annex-3.20120826:+oldyesod
+    trying: git-annex-3.20120826:+currentyesod
+    next goal: yesod-default (dependency of git-annex-3.20120826:+oldyesod)
+    rejecting: yesod-default-1.1.0 (conflict: git-annex-3.20120826:oldyesod =>
+    yesod-default(<=1.0.1.1))
+    rejecting: yesod-default-1.0.1.1, 1.0.1, 1.0.0, 0.6.1, 0.5.0, 0.4.1, 0.4.0,
+    0.3.1 (conflict: git-annex-3.20120826:currentyesod => yesod-default(>=1.1.0))
+
+Any idea how to fix this? (PS: I'm running Kubuntu 12.04)
+
+Cheers,
+Tobias
diff --git a/doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__/comment_1_2eb4f410b54a25fcc895893a3c631c43._comment b/doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__/comment_1_2eb4f410b54a25fcc895893a3c631c43._comment
new file mode 100644
index 0000000000..b18e74f7a1
--- /dev/null
+++ b/doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__/comment_1_2eb4f410b54a25fcc895893a3c631c43._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.16"
+ subject="comment 1"
+ date="2012-08-29T16:01:00Z"
+ content="""
+Hmm, cabal is not as smart as I'd hoped it could be. I've removed the support for old version of yesod.
+"""]]
diff --git a/doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__/comment_2_44cd6f6dd674df105d6f0b3f320f3236._comment b/doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__/comment_2_44cd6f6dd674df105d6f0b3f320f3236._comment
new file mode 100644
index 0000000000..4d8b0a8aa9
--- /dev/null
+++ b/doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__/comment_2_44cd6f6dd674df105d6f0b3f320f3236._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
+ nickname="Tobias"
+ subject="comment 2"
+ date="2012-08-30T10:01:24Z"
+ content="""
+thanks, that resolved the dependency trouble.
+But now:
+
+    Building git-annex-3.20120826...
+    Preprocessing executable 'git-annex' for git-annex-3.20120826...
+
+    Utility/Yesod.hs:15:8:
+        Could not find module `Data.Default'
+        It is a member of the hidden package `data-default-0.5.0'.
+        Perhaps you need to add `data-default' to the build-depends in your .cabal file.
+        Use -v to see a list of the files searched for.
+
+"""]]
diff --git a/doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__/comment_3_992af6855901df79a2018a07941cb8b6._comment b/doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__/comment_3_992af6855901df79a2018a07941cb8b6._comment
new file mode 100644
index 0000000000..09d0dbd9af
--- /dev/null
+++ b/doc/forum/Cabal__58___Could_not_resolve_dependencies___40__yesod__41__/comment_3_992af6855901df79a2018a07941cb8b6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.16"
+ subject="comment 3"
+ date="2012-08-30T16:59:07Z"
+ content="""
+The Data.Default problem is fixed now.
+"""]]
diff --git a/doc/forum/Calculating_Annex_Cost_by_Ping_Times.mdwn b/doc/forum/Calculating_Annex_Cost_by_Ping_Times.mdwn
new file mode 100644
index 0000000000..996e864c30
--- /dev/null
+++ b/doc/forum/Calculating_Annex_Cost_by_Ping_Times.mdwn
@@ -0,0 +1 @@
+I threw together a pair of shell scripts for calculating the cost of a remote using ping times.  I don't know how useful this is in practice, but the theory seemed sound to me.  If I'm in a hotel room with my two laptops, I'd rather annex try to get a file from the other laptop than from my NAS all the way back home.  I'd love to figure out how to also detect if I'm on my VerizonWireless connection at the time and multiply the cost of all connections over the Internet accordingly, but that's down the road.  Latest versions of the pair of scripts will be at <https://gist.github.com/4410357>. I'm interested in feedback, so please fork the git repo on gist and send me changes/updates. Also of note is that these were written for MacOSX. If you're interested in using them on a different linux, pay attention to the format of the summary line of your ping command.
diff --git a/doc/forum/Calculating_Annex_Cost_by_Ping_Times/comment_1_9b4a6bc8d52ecbbdd537e8cf76757a80._comment b/doc/forum/Calculating_Annex_Cost_by_Ping_Times/comment_1_9b4a6bc8d52ecbbdd537e8cf76757a80._comment
new file mode 100644
index 0000000000..2a2554f8d3
--- /dev/null
+++ b/doc/forum/Calculating_Annex_Cost_by_Ping_Times/comment_1_9b4a6bc8d52ecbbdd537e8cf76757a80._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2012-12-30T23:01:39Z"
+ content="""
+You may want to use hop count, not ping times, for a rough guesstimate of distance.
+
+Generally speaking, this is a highly non-trivial problem that's subject to university research projects so unless you find a well-maintained third party tool to solve this problem, it's unlikely that you will find a truly general solution.
+
+Anyway, look into mtr for your distance measurements.
+
+
+Richard
+"""]]
diff --git a/doc/forum/Calculating_Annex_Cost_by_Ping_Times/comment_2_7e04f85c6ba74c18c8dde148aef9bf80._comment b/doc/forum/Calculating_Annex_Cost_by_Ping_Times/comment_2_7e04f85c6ba74c18c8dde148aef9bf80._comment
new file mode 100644
index 0000000000..7dc4072eb1
--- /dev/null
+++ b/doc/forum/Calculating_Annex_Cost_by_Ping_Times/comment_2_7e04f85c6ba74c18c8dde148aef9bf80._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmRFKwny4rArBaz-36xTcsJYqKIgdDaw5Q"
+ nickname="Andrew"
+ subject="comment 2"
+ date="2013-01-06T11:08:42Z"
+ content="""
+Yeah, I was debating between ping times (max or avg) and hop count and ultimately went with ping time because of this situation: From my office to my house is ~12 hops but because we peer with the cable modem provider the ping time is still ~5ms. But from my cell modem, it's ~8 hops but ping times of ~200ms.
+"""]]
diff --git a/doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__.mdwn b/doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__.mdwn
new file mode 100644
index 0000000000..9650f26f57
--- /dev/null
+++ b/doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__.mdwn
@@ -0,0 +1,11 @@
+Hello.
+
+There is a git-annex repository managing about 172.000 annexed files (plus a number of small regular files in git history), for a total of about 1.7TB. At filesystem level, `find` reports about 924.000 entries (directories, files, symlinks).
+
+Inspecting it I see that `.git/annex/transfer` containes over 86000 entries (mostly files).
+
+I tried to find more information about it and only https://git-annex.branchable.com/design/assistant/syncing/ seemed to provide some information but not enough.
+
+Are they needed permanently? Can I just delete `.git/annex/transfer` without damage?
+
+Thanks.
diff --git a/doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__/comment_1_3510190e7c5d08f906b24e5743245f87._comment b/doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__/comment_1_3510190e7c5d08f906b24e5743245f87._comment
new file mode 100644
index 0000000000..2a0bfa1189
--- /dev/null
+++ b/doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__/comment_1_3510190e7c5d08f906b24e5743245f87._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="supernaught"
+ avatar="http://cdn.libravatar.org/avatar/55f92a50f2617099e2dc7509130ce158"
+ subject="comment 1"
+ date="2017-07-18T17:03:54Z"
+ content="""
+I'm not certain, but I think 
+    
+    $> git annex unused --fast
+    $> git annex drop --unused
+
+will work.
+"""]]
diff --git a/doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__/comment_2_bfd829aed28817a5aada3f237496c865._comment b/doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__/comment_2_bfd829aed28817a5aada3f237496c865._comment
new file mode 100644
index 0000000000..cd4a3bff74
--- /dev/null
+++ b/doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__/comment_2_bfd829aed28817a5aada3f237496c865._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="How about find .git/annex/transfer .git/annex/bad -type f -print0 | xargs -0 rm -fv"
+ date="2017-07-19T19:42:25Z"
+ content="""
+> I'm not certain, but I think
+> 
+> $> git annex unused --fast
+> $> git annex drop --unused
+> 
+> will work.
+
+This (quickly) finds only two entries: one regarding a file in `.git/annex/transfer` and one other in `.git/annex/bad/`.
+
+Anyway, `git annex drop --unused` is too general and would potentially involve a number of other files.
+
+I'm just considering something that should probably be safe:
+
+    find .git/annex/transfer .git/annex/bad -type f -print0 | xargs -0 rm -fv
+
+unless people tell me it's dangerous somehow.  Having to do a `git annex fsck` in the future is okay.  Having important features broken until I do a `git annex fsck` (or worse) is less cool. :-)
+
+"""]]
diff --git a/doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__/comment_3_cf2ae4db1fdb421b59d85edd9e58b868._comment b/doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__/comment_3_cf2ae4db1fdb421b59d85edd9e58b868._comment
new file mode 100644
index 0000000000..3c2f8016aa
--- /dev/null
+++ b/doc/forum/Can_I_purge_.git__47__annex__47__transfer_directory___63__/comment_3_cf2ae4db1fdb421b59d85edd9e58b868._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-10-02T16:55:59Z"
+ content="""
+It's fine to delete .git/annex/transfer/ at any time.
+
+Those files are used to make `git annex info` (and the webapp) be able to
+show what transfers are in progress. Normally they're cleaned up when a
+transfer finishes; if you interrupt git-annex they will be left behind.
+
+Running `git annex info` is also supposed to clean up the stale transfer
+info files, but it was broken -- now fixed.
+
+The only time you get files in .git/annex/bad/ is when fsck finds a file
+got corrupted somehow and moves its content there. It's fine to delete
+those unless you were planning to recover or examine the corrupted file in
+some way.
+"""]]
diff --git a/doc/forum/Can_I_remove_a_groupwanted_expression__63__.mdwn b/doc/forum/Can_I_remove_a_groupwanted_expression__63__.mdwn
new file mode 100644
index 0000000000..cbf3f327a6
--- /dev/null
+++ b/doc/forum/Can_I_remove_a_groupwanted_expression__63__.mdwn
@@ -0,0 +1,7 @@
+I associated a groupwanted expression with a group I called "common", but I don't want it any more. Can I remove it, so the group doesn't have any groupwanted expression?
+
+I tried to remove it with `git annex groupwanted common ''`, but when I run `git annex vicfg`, I just end up with `groupwanted common =`. Similarly, if I run `git annex vicfg` and delete that line, it seems to have no effect.
+
+I'm assuming (but haven't verified) that means I won't be able to use `groupwanted` properly with repos that are in `common` and also in a group that has a real expression associated with it.
+
+How can I make it so `common` no longer has an associated expression?
diff --git a/doc/forum/Can_I_remove_a_groupwanted_expression__63__/comment_2_23d18b52d87468ffadf0a3e04bf8052d._comment b/doc/forum/Can_I_remove_a_groupwanted_expression__63__/comment_2_23d18b52d87468ffadf0a3e04bf8052d._comment
new file mode 100644
index 0000000000..c1c622e132
--- /dev/null
+++ b/doc/forum/Can_I_remove_a_groupwanted_expression__63__/comment_2_23d18b52d87468ffadf0a3e04bf8052d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="falsifian"
+ avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae"
+ subject="comment 2"
+ date="2020-09-12T15:30:05Z"
+ content="""
+Update: I've verified that the empty groupwanted expression indeed does indeed block the groupwanted expression from another group. So, other than making sure I never use the `common` group again, or some manual repository surgery, I'm not sure how to recover from this situation.
+"""]]
diff --git a/doc/forum/Can_I_store_normal_files_in_the_git-annex_git_repository__63__.mdwn b/doc/forum/Can_I_store_normal_files_in_the_git-annex_git_repository__63__.mdwn
new file mode 100644
index 0000000000..6d1083dd57
--- /dev/null
+++ b/doc/forum/Can_I_store_normal_files_in_the_git-annex_git_repository__63__.mdwn
@@ -0,0 +1,6 @@
+Is it possible to story ordinary files in the git repository, or is this going to confuse git-annex? In other words, can I safely run
+
+    git add .gitattributes
+    git commit -m 'remember attributes' .gitattributes
+
+..., or do I have to use `git-annex add` all time?
diff --git a/doc/forum/Can_I_store_normal_files_in_the_git-annex_git_repository__63__/comment_1_c8f9923d8dc76b8bed25dce5ae09b520._comment b/doc/forum/Can_I_store_normal_files_in_the_git-annex_git_repository__63__/comment_1_c8f9923d8dc76b8bed25dce5ae09b520._comment
new file mode 100644
index 0000000000..8873edcde8
--- /dev/null
+++ b/doc/forum/Can_I_store_normal_files_in_the_git-annex_git_repository__63__/comment_1_c8f9923d8dc76b8bed25dce5ae09b520._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://peter-simons.myopenid.com/"
+ ip="77.12.196.1"
+ subject="Solved"
+ date="2011-07-13T16:21:25Z"
+ content="""
+I got my answer on #vcs-home: Yes, git-annex and git get along fine.
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo.mdwn b/doc/forum/Can_Not_Sync_to_Git_Repo.mdwn
new file mode 100644
index 0000000000..3b57829961
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo.mdwn
@@ -0,0 +1 @@
+On one my repos (git repo on github data on S3) I've started getting, `fatal: Cannot force update the current branch` `git-annex: failed to update refs/heads/master` other clones of this repository can sync fine but this one started failing after adding a couple of files.
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_10_e0f82074eb1a4b8258729d9a23a7f421._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_10_e0f82074eb1a4b8258729d9a23a7f421._comment
new file mode 100644
index 0000000000..bf3cc836af
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_10_e0f82074eb1a4b8258729d9a23a7f421._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="http://cstork.org/"
+ nickname="Chris Stork"
+ subject="no annex/direct/master branch"
+ date="2013-12-21T04:19:33Z"
+ content="""
+Same problem here:
+
+    % git branch -a
+      git-annex
+    * master
+      synced/git-annex
+      synced/master
+      remotes/HD02/git-annex
+      remotes/HD02/master
+      remotes/HD02/synced/git-annex
+      remotes/HD02/synced/master
+
+This is a direct mode repo, too.
+
+It seems that git-annex didn't properly update the repo.  .git/config shows:
+
+    [core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = false
+        ...
+    [annex]
+        ...
+        version = 3
+        direct = true
+
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_11_842aaf685aa843c21bf3eef0b61f8630._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_11_842aaf685aa843c21bf3eef0b61f8630._comment
new file mode 100644
index 0000000000..a62cd7877f
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_11_842aaf685aa843c21bf3eef0b61f8630._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 11"
+ date="2013-12-29T17:09:26Z"
+ content="""
+I've found a bug where a repo would for some unknown reason be in direct mode but v3, and so would not be auto-upgraded to v5. This explains at least what Chris Stork shows. But I think not what previous posters are experiencing. I've fixed that bug in git.
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_12_b4f8be428a08db01dbd004e1f06dcffd._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_12_b4f8be428a08db01dbd004e1f06dcffd._comment
new file mode 100644
index 0000000000..883ae6d96f
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_12_b4f8be428a08db01dbd004e1f06dcffd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://cstork.org/"
+ nickname="Chris Stork"
+ subject="Bug fix confirmed"
+ date="2014-01-30T15:29:56Z"
+ content="""
+Thank you, Joey!
+FYI, my repo was automatically converted to version 5 and put on the annex/direct/master branch.
+As Joey mentioned, this might only apply to my bug.
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_13_45132d348807fbf8ed32198e110d2caa._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_13_45132d348807fbf8ed32198e110d2caa._comment
new file mode 100644
index 0000000000..f30f2907f6
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_13_45132d348807fbf8ed32198e110d2caa._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlo7XnC4EU3u_9t80JUYXV7XPnUqBQ7mD4"
+ nickname="Ryan"
+ subject="comment 13"
+ date="2014-12-19T00:09:35Z"
+ content="""
+I'm having the same problem with my direct repo:
+
+git branch -a
+  git-annex
+* master
+  synced/git-annex
+  synced/master
+  remotes/cluster/git-annex
+  remotes/cluster/master
+  remotes/cluster/synced/master
+
+git annex version
+git-annex version: 5.20140818-g10bf03a
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_14_d2bb44a7607f3b2cddfd98cc2fa456d6._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_14_d2bb44a7607f3b2cddfd98cc2fa456d6._comment
new file mode 100644
index 0000000000..de76cc210d
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_14_d2bb44a7607f3b2cddfd98cc2fa456d6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://www.ryantm.com/"
+ subject="Possible workaround"
+ date="2015-09-08T14:46:03Z"
+ content="""
+The `git annex checkout annex/direct/master` workaround mentioned above did not work for me, but this did:
+
+git annex indirect
+git annex direct
+
+after that, my repo was on the annex/direct/master branch
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_1_80344c54804ddee81d89c0b40731fb9c._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_1_80344c54804ddee81d89c0b40731fb9c._comment
new file mode 100644
index 0000000000..93c4ce7791
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_1_80344c54804ddee81d89c0b40731fb9c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Remy"
+ ip="83.87.167.98"
+ subject="comment 1"
+ date="2013-12-02T19:32:18Z"
+ content="""
+i have the same problem on one of my repo's as well.
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_2_1797c2fef5c20e885b56b8a2c6330ff0._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_2_1797c2fef5c20e885b56b8a2c6330ff0._comment
new file mode 100644
index 0000000000..8d08c32760
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_2_1797c2fef5c20e885b56b8a2c6330ff0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 2"
+ date="2013-12-02T19:52:04Z"
+ content="""
+Post the version of git-annex you're using, and `git annex sync --debug` output.
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_3_fb23d640f9634cab2da91848f1848627._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_3_fb23d640f9634cab2da91848f1848627._comment
new file mode 100644
index 0000000000..10206a898f
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_3_fb23d640f9634cab2da91848f1848627._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="Remy"
+ ip="83.87.167.98"
+ subject="comment 3"
+ date="2013-12-03T08:35:21Z"
+ content="""
+> git-annex version
+
+	git-annex version: 5.20131117-gbd514dc
+	build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash
+	key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+	remote types: git gcrypt S3 bup directory rsync web webdav glacier hook
+	local repository version: 5
+	default repository version: 3
+	supported repository versions: 3 5
+	upgrade supported from repository versions: 0 1 2 4
+
+
+> git-annex sync --debug bonus_remote
+
+	[2013-12-03 09:23:07 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"show-ref\",\"git-annex\"]
+	[2013-12-03 09:23:07 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+	[2013-12-03 09:23:07 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/git-annex..37a902328b4806d1549bf174241339432105d756\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:07 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/git-annex..5e25b4c5c8c28d48b212c079767827e27819c379\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:07 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/git-annex..2245416c2355c9e00f560bcde15b8856d8f924be\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:07 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/git-annex..18e56479af7031d179cd4f4af4138b15211bea26\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:07 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/git-annex..b74c5b5cfeecfeace64a4b31aabd7163c6c28f42\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:07 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/git-annex..88fd933c3dbb56d2527c19d6b462c61d9213535c\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:07 CET] chat: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"cat-file\",\"--batch\"]
+	[2013-12-03 09:23:07 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"ls-files\",\"--stage\",\"-z\",\"--others\",\"--exclude-standard\",\"--\",\"/Users/remy/Sync\"]
+	[2013-12-03 09:23:07 CET] chat: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"cat-file\",\"--batch\"]
+	commit  
+	[2013-12-03 09:23:13 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"commit\",\"-m\",\"git-annex automatic sync\"]
+	ok
+	[2013-12-03 09:23:13 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"symbolic-ref\",\"HEAD\"]
+	[2013-12-03 09:23:13 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"show-ref\",\"refs/heads/master\"]
+	[2013-12-03 09:23:13 CET] call: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"show-ref\",\"--verify\",\"-q\",\"refs/heads/synced/master\"]
+	[2013-12-03 09:23:13 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/master..refs/heads/synced/master\",\"--oneline\",\"-n1\"]
+	pull bonus_remote 
+	[2013-12-03 09:23:13 CET] call: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"fetch\",\"bonus_remote\"]
+	[2013-12-03 09:23:14 CET] call: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"show-ref\",\"--verify\",\"-q\",\"refs/remotes/bonus_remote/master\"]
+	[2013-12-03 09:23:14 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/master..refs/remotes/bonus_remote/master\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:14 CET] call: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"show-ref\",\"--verify\",\"-q\",\"refs/remotes/bonus_remote/synced/master\"]
+	[2013-12-03 09:23:14 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/synced/master..refs/remotes/bonus_remote/synced/master\",\"--oneline\",\"-n1\"]
+	ok
+	[2013-12-03 09:23:14 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"show-ref\",\"git-annex\"]
+	[2013-12-03 09:23:14 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+	[2013-12-03 09:23:14 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/git-annex..37a902328b4806d1549bf174241339432105d756\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:14 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/git-annex..5e25b4c5c8c28d48b212c079767827e27819c379\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:14 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/git-annex..2245416c2355c9e00f560bcde15b8856d8f924be\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:14 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/git-annex..18e56479af7031d179cd4f4af4138b15211bea26\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:14 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/git-annex..b74c5b5cfeecfeace64a4b31aabd7163c6c28f42\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:14 CET] read: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"log\",\"refs/heads/git-annex..88fd933c3dbb56d2527c19d6b462c61d9213535c\",\"--oneline\",\"-n1\"]
+	[2013-12-03 09:23:14 CET] call: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"branch\",\"-f\",\"synced/master\"]
+	[2013-12-03 09:23:14 CET] call: git [\"--git-dir=/Users/remy/Sync/.git\",\"--work-tree=/Users/remy/Sync\",\"branch\",\"-f\",\"master\"]
+	fatal: Cannot force update the current branch.
+	git-annex: failed to update refs/heads/master
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_4_a947736911e68856f2c3494963063df8._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_4_a947736911e68856f2c3494963063df8._comment
new file mode 100644
index 0000000000..c2a48b5573
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_4_a947736911e68856f2c3494963063df8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmu416zAYgYzbXVZAe30MiXoOWO4z6nGX8"
+ nickname="Johannes"
+ subject="comment 4"
+ date="2013-12-05T16:31:04Z"
+ content="""
+I have the same problem. \"git annex repair\" does not detect any problems.
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_5_ce0e77143cfd2d578b1e5a71e35060da._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_5_ce0e77143cfd2d578b1e5a71e35060da._comment
new file mode 100644
index 0000000000..9b80220fb6
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_5_ce0e77143cfd2d578b1e5a71e35060da._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn26WQjIP5fnMgQF_L_k3Q3UrR5v8mjRTY"
+ nickname="Ellis"
+ subject="comment 5"
+ date="2013-12-07T18:14:21Z"
+ content="""
+I'm experiencing the same problem in one of my repositories on a couple computers now.
+
+> git-annex version: 5.20131118-gc7e5cde
+> build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus XMPP Feeds Quvi TDFA
+> key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+> remote types: git gcrypt S3 bup directory rsync web webdav glacier hook
+> local repository version: 3
+> default repository version: 3
+> supported repository versions: 3 5
+> upgrade supported from repository versions: 0 1 2 4
+
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_6_10e114da6a2bb54b860b44767ba1ca94._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_6_10e114da6a2bb54b860b44767ba1ca94._comment
new file mode 100644
index 0000000000..b605de7262
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_6_10e114da6a2bb54b860b44767ba1ca94._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
+ nickname="Tobias"
+ subject="same here"
+ date="2013-12-11T19:57:09Z"
+ content="""
+I'm facing the same situation as the other commenters.
+
+    git-annex version: 5.20131130-gc25be33
+    [...]
+    (merging gitlab/synced/git-annex into git-annex...)
+    (Recording state in git...)
+    fatal: Cannot force update the current branch.
+    git-annex: failed to update refs/heads/master
+
+Seems to be a problem with the command `git branch -f master`
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_7_415bab6a7ab564e671f42cfad83e0e58._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_7_415bab6a7ab564e671f42cfad83e0e58._comment
new file mode 100644
index 0000000000..8b1824ede5
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_7_415bab6a7ab564e671f42cfad83e0e58._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 7"
+ date="2013-12-12T17:07:37Z"
+ content="""
+What branch does `git branch` say is checked out?
+
+If you're using direct mode, you should not have the master branch checked out. Instead you should have an `annex/direct/master` branch that direct mode sets up and automatically switches you to. (Commits are still made to the master branch when syncing.)
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_8_36abd829ea71a44c7cded1123a7c913d._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_8_36abd829ea71a44c7cded1123a7c913d._comment
new file mode 100644
index 0000000000..66f75327ee
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_8_36abd829ea71a44c7cded1123a7c913d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
+ nickname="Tobias"
+ subject="comment 8"
+ date="2013-12-14T13:15:13Z"
+ content="""
+The master branch was checkout out (I don't know why). Checking out the mentioned branch fixed the syncing issue: `git checkout annex/direct/master`
+"""]]
diff --git a/doc/forum/Can_Not_Sync_to_Git_Repo/comment_9_2fb745aaffe544f97bbdc670261fd4fd._comment b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_9_2fb745aaffe544f97bbdc670261fd4fd._comment
new file mode 100644
index 0000000000..3bf1df783a
--- /dev/null
+++ b/doc/forum/Can_Not_Sync_to_Git_Repo/comment_9_2fb745aaffe544f97bbdc670261fd4fd._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="etset"
+ ip="82.155.112.106"
+ subject="comment 9"
+ date="2013-12-19T12:45:06Z"
+ content="""
+I seem to have the same problem. I have two repositories added as ssh remotes to one another with the assistant. `git-annex sync` works on one of these, but not on the other, failing with the same error as above. Also, running `git-annex sync --debug` results in the same output as in Remy's above post. `git-annex repair` doesn't find any problem. Running `git branch` on both shows that neither repository has an `annex/direct/master` branch, and both have `master` checked out. 
+
+One of the repositories has the current version from debian wheezy-backports, 4.20131106~bpo70+1, installed, and the other one had 5.20131130 from unstable as of when I discovered the problem (I upgraded it today, but the problem persists). I'm not sure, but I think those were the versions I used to create the repositores, too.
+
+Trying to reproduce the problem, I created a new repository via assistant on both computers, the one running 4.20131106~bpo70+1 and the one recently upgraded to 5.20131213. On the 5.* one, a `annex/direct/master` branch was created and checked out, but not on the 4.* one. However, adding each other as ssh remotes with the assistant makes the `annex/direct/master` on 5.* disappear and `master` to be checked out on both.
+
+Is there anything I can do to fix the repositories? Is there any other info I could provide to help with this?
+"""]]
diff --git a/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only.mdwn b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only.mdwn
new file mode 100644
index 0000000000..70e97273d5
--- /dev/null
+++ b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only.mdwn
@@ -0,0 +1,72 @@
+Hi!
+
+I'm using git-annex version: 8.20200522-g01513da12.
+
+A file is present in 3 special remotes (one S3 and two rsync ones). I fsck-ed all theses repositories, no problem found. Numcopies is set to 2.
+
+Whenever I try do drop the file from one of these special remotes, I have an error message:
+
+      Unable to lock down 1 copy of file that is required to safely drop it.
+    
+      (This could have happened because of a concurrent drop, or because a remote has too old a version of git-annex-shell installed.)
+    
+      Rather than dropping this file, try using: git annex move
+    
+      (Note that these git remotes have annex-ignore set: origin)
+
+      (Use --force to override this check, or adjust numcopies.)
+    failed
+    git-annex: drop: 1 failed
+
+**Do you know why I can't delete this file safely?** I don't really want to move the file from repository_s3 to my computer before dropping it from my computer, but maybe it is the only way.
+
+Some debug here:
+
+    git annex drop --from=repository_s3 file
+    [2020-06-01 09:28:36.30172183] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+    [2020-06-01 09:28:36.302839128] process done ExitSuccess
+    [2020-06-01 09:28:36.302910826] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+    [2020-06-01 09:28:36.304674603] process done ExitSuccess
+    [2020-06-01 09:28:36.304870633] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","myfile"]
+    [2020-06-01 09:28:36.308566414] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+    [2020-06-01 09:28:36.310718234] process done ExitSuccess
+    [2020-06-01 09:28:36.310777259] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+    [2020-06-01 09:28:36.312706322] process done ExitSuccess
+    [2020-06-01 09:28:36.313462825] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..b855e6a77dbef6378695d43aca723d6586a5033d","--pretty=%H","-n1"]
+    [2020-06-01 09:28:36.315478283] process done ExitSuccess
+    [2020-06-01 09:28:36.315547977] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..225048506b610815513008d42e9b5d58d8024512","--pretty=%H","-n1"]
+    [2020-06-01 09:28:36.317466181] process done ExitSuccess
+    [2020-06-01 09:28:36.317524901] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..c517aa9598e8e7cd61f7ee4b8742d2d1b23eb4f3","--pretty=%H","-n1"]
+    [2020-06-01 09:28:36.319278416] process done ExitSuccess
+    [2020-06-01 09:28:36.319344343] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..5fce52950d6bf949ab90c07c7886410214c0fb78","--pretty=%H","-n1"]
+    [2020-06-01 09:28:36.320947418] process done ExitSuccess
+    [2020-06-01 09:28:36.324812884] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+    [2020-06-01 09:28:36.325182947] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+    [2020-06-01 09:28:36.330066795] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+    drop wasabi-s3 myfile [2020-06-01 09:28:36.340825449] chat: gpg ["--quiet","--trust-model","always","--decrypt"]
+    [2020-06-01 09:28:37.176503667] process done ExitSuccess
+    (checking repository1...) [2020-06-01 09:28:37.177417745] read: rsync ["-e","'ssh' '-S' '.git/annex/ssh/repository1' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T'","repository1:/home/troissinges/annex/ec8/502/'GPGHMACSHA1--982dee55ea35e4a6b123a0824084224c0d9d1855/GPGHMACSHA1--982dee55ea35e4a6b123a0824084224c0d9d1855'"]
+    [2020-06-01 09:28:38.544912886] process done ExitSuccess
+    [2020-06-01 09:28:38.545311227] chat: gpg ["--quiet","--trust-model","always","--decrypt"]
+    [2020-06-01 09:28:39.467364936] process done ExitSuccess
+    (checking repository2...) [2020-06-01 09:28:39.467946703] read: rsync ["-e","'ssh' '-S' '.git/annex/ssh/repository2' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T'","repository2:/home/troissinges/annex/ff1/3c2/'GPGHMACSHA1--4524287d59896f3257f7a5880d598bae2cccc3a9/GPGHMACSHA1--4524287d59896f3257f7a5880d598bae2cccc3a9'"]
+    [2020-06-01 09:28:41.165332387] process done ExitSuccess
+    (unsafe) 
+      Unable to lock down 1 copy of file that is required to safely drop it.
+    
+      (This could have happened because of a concurrent drop, or because a remote has too old a version of git-annex-shell installed.)
+    
+      Rather than dropping this file, try using: git annex move
+    
+      (Note that these git remotes have annex-ignore set: origin)
+    
+      (Use --force to override this check, or adjust numcopies.)
+    failed
+    [2020-06-01 09:28:41.170070605] read: ssh ["-O","stop","-S","repository2","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
+    [2020-06-01 09:28:41.175742495] process done ExitSuccess
+    [2020-06-01 09:28:41.175982476] read: ssh ["-O","stop","-S","repository1","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
+    [2020-06-01 09:28:41.179991665] process done ExitSuccess
+    [2020-06-01 09:28:41.180410006] process done ExitSuccess
+    [2020-06-01 09:28:41.180589281] process done ExitSuccess
+    [2020-06-01 09:28:41.180985889] process done ExitSuccess
+    git-annex: drop: 1 failed
diff --git a/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_1_e03ec3be310f5c0e02457ac053e6afdd._comment b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_1_e03ec3be310f5c0e02457ac053e6afdd._comment
new file mode 100644
index 0000000000..b8d0c38c63
--- /dev/null
+++ b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_1_e03ec3be310f5c0e02457ac053e6afdd._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-11T17:36:54Z"
+ content="""
+The reason git-annex is preventing you from dropping a file in this
+situation can be understood if you imagine that you've given me and a
+friend access to your remotes.
+
+Each of the three of us runs git-annex drop --from one remote. We all
+picked a different remote. So each git-annex, running at the same time,
+see two copies of the file, so assume they can delete the third copy. 
+And so all 3 copies get deleted.
+
+Admittedly, this is more likely to happen if there are only 2 remotes and 2
+people involved, not 3 or more, and would be a big cooincidence even with
+2 people. But git-annex aims to avoid losing content even in unlikely cases.
+
+So it requires that, in order to drop the file, at least one of the other
+repos have a copy, and be able to lock it in place, preventing it from
+being dropped from that repo.
+
+Unfortunately, the only remote that can lock content currently is a
+git repository. (Maybe that [[could be improved|todo/lockContent_for_special_remotes]].)
+
+The solution for you it to either use --force like the message says
+(only if you're sure nobody else is dropping the files from the other remotes
+at the same time), or to also have a git remote somewhere that contains
+the file.
+"""]]
diff --git a/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_2_1bea8772a170277420faa898dcf2ab83._comment b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_2_1bea8772a170277420faa898dcf2ab83._comment
new file mode 100644
index 0000000000..c881c967dd
--- /dev/null
+++ b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_2_1bea8772a170277420faa898dcf2ab83._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Franky"
+ avatar="http://cdn.libravatar.org/avatar/a428bea83c72676f7a79710fb5625849"
+ subject="comment 2"
+ date="2020-06-18T16:17:36Z"
+ content="""
+It is amazing that git-annex takes this much care. However, I don't really share with anybody else and `--force` scares the hell out of me. I have to double check everything a million times and still keep fingers crossed.
+
+Instead of that, can we have a `--no-lock` option that can be used to do this without needing to lock the repo? It will still do all the usual checks, just not fail on locking files. It'll obviously have the caveat that we can have data loss with simultaneous use, but so does `--force`.
+"""]]
diff --git a/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_3_c061fef62b272d34b605d94a176cd577._comment b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_3_c061fef62b272d34b605d94a176cd577._comment
new file mode 100644
index 0000000000..4cf3bc388e
--- /dev/null
+++ b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_3_c061fef62b272d34b605d94a176cd577._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="Workaround"
+ date="2021-04-08T14:02:51Z"
+ content="""
+If you trust the special remote to not be accessed by multiple repos at the same time, you can `git annex trust` it. That makes git annex trust it to be locked aswell and regular `sync --content` works for me.
+"""]]
diff --git a/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_4_2f6d31ada3a8f3f43bc53ce9ee2c70b8._comment b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_4_2f6d31ada3a8f3f43bc53ce9ee2c70b8._comment
new file mode 100644
index 0000000000..bffdc6ff18
--- /dev/null
+++ b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_4_2f6d31ada3a8f3f43bc53ce9ee2c70b8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-04-08T16:49:43Z"
+ content="""
+I don't think there's much difference between your suggested `--no-lock`
+and trusting the special remote, is there?
+
+Anyway, there is the recently added annex.mincopies, which controls
+how many copies git-annex requires to have locked for a drop to succeed.
+Default is 1. I added that thinking some might want *more* locking
+and so a higher value, but you could set it to a lower value which 
+would behave the same as `--no-lock`.
+"""]]
diff --git a/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_5_d25b7eb756f08c94a2b2ada472cd0f87._comment b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_5_d25b7eb756f08c94a2b2ada472cd0f87._comment
new file mode 100644
index 0000000000..44c402d5e5
--- /dev/null
+++ b/doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_5_d25b7eb756f08c94a2b2ada472cd0f87._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 5"
+ date="2021-04-08T19:33:44Z"
+ content="""
+I guess one difference is be that other repos may erroneously think a file is present in the special remote when, in actuality, it has been deleted. (That's what trust/semitrust is for, right?)  
+In my use-case it doesn't make much of a difference since the special remote will rarely see a deletion but I can imagine there might also be ones where it could end catastrophically.
+
+A better solution all around would probably be to enable the user to override a special remote's perceived locking ability somehow (and only that, no other trust factors).
+
+Having a runtime switch for temporarily trusting special remotes to lock files would be useful in any case though IMO.
+"""]]
diff --git a/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook.mdwn b/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook.mdwn
new file mode 100644
index 0000000000..9c0f5c7d72
--- /dev/null
+++ b/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook.mdwn
@@ -0,0 +1,41 @@
+I'm trying to automate syncing of two repos A and B. My goal is to run `git annex sync` from A and have the working copy of B updated automatically. According to the manual page, `git annex merge` should to the trick. It works just fine when I run it manually in B, but not when I run it from the post-receive hook, as suggested in the manual page.
+
+Here is a test script that illustrates the issue: <https://gist.github.com/anonymous/6197019>
+
+The output I get:
+
+    [...]
+    file1 exists after manual git annex merge
+    [...]
+    file2 does not exist after git annex merge in post-receive
+
+From the output I can see that `git annex merge` is run on the remote end, and seems to do it's thing (`file2` is added):
+
+    remote: merge git-annex (merging synced/git-annex into git-annex...)
+    remote: ok
+    remote: merge synced/master Updating 6e5bfba..0dcbcfd
+    remote: Fast-forward
+    remote:  file2 |    1 +
+    remote:  1 file changed, 1 insertion(+)
+    remote:  create mode 120000 file2
+    remote: 
+    remote: ok
+
+However, the working copy in B does not have the file `file2`. Even worse, `git status` in B shows the file as deleted:
+
+    # On branch master
+    # Your branch is ahead of 'origin/master' by 2 commits.
+    #
+    # Changes not staged for commit:
+    #   (use "git add/rm <file>..." to update what will be committed)
+    #   (use "git checkout -- <file>..." to discard changes in working directory)
+    #
+    #	deleted:    file2
+    #
+    no changes added to commit (use "git add" and/or "git commit -a")
+
+So when running `git annex sync` from B now, the file will be deleted from A as well, which is not what I expected.
+
+This is on Ubuntu 12.04, using the precompiled git-annex tarball (amd64).
+
+What am I doing wrong?
diff --git a/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_1_8b71cb6772b219c27c17392d5099907a._comment b/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_1_8b71cb6772b219c27c17392d5099907a._comment
new file mode 100644
index 0000000000..cfaff89b12
--- /dev/null
+++ b/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_1_8b71cb6772b219c27c17392d5099907a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://kallesoderman.myopenid.com/"
+ ip="85.224.35.48"
+ subject="Same problem here"
+ date="2013-08-14T20:20:42Z"
+ content="""
+I'm trying to achieve [[USB_backup_with_files_visible/]] but can't make the post-recieve or post-update hooks have any effect. The filesystem is vfat so there are some issues with mounting defaults and executables (do the hooks have to be executable?) but regardless of mount options no dice.
+
+ ``git-annex merge`` at the cli works perfectly. I havent been bitten by  files being deleted and propagated though.
+
+Manually merging ruins my \"late for work need to bring data but to tired to think properly\" use case.
+"""]]
diff --git a/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_2_af2a2634d8d128868022d033d6adb549._comment b/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_2_af2a2634d8d128868022d033d6adb549._comment
new file mode 100644
index 0000000000..0623ed1dbb
--- /dev/null
+++ b/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_2_af2a2634d8d128868022d033d6adb549._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 2"
+ date="2013-08-23T18:35:01Z"
+ content="""
+Having just set up <http://annex.debconf.org> which uses a git hook to run `git annex merge`, I can say that the main problems you are likely to run into are:
+
+1. The hook might be run with the cwd not set to the top of the git repository. cd to the git repository in the hook to fix.
+2. The hook might be run with `GIT_DIR` set to a strange value (in my case, it was set to \".\"), which is not the actual .git directory location. Unsetting it fixes that.
+
+I don't know about how to get git hooks to work on FAT filesystems though. Hooks have to be executable, and most systems probably don't mount such filesystems with executability allowed.
+"""]]
diff --git a/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_3_31ec762a0684d2ce87d229ed2924db93._comment b/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_3_31ec762a0684d2ce87d229ed2924db93._comment
new file mode 100644
index 0000000000..2a56b57e92
--- /dev/null
+++ b/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_3_31ec762a0684d2ce87d229ed2924db93._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlq495p0WtZDUpxzYN9YnToZGODfCGnqOw"
+ nickname="Stanis"
+ subject="comment 3"
+ date="2013-08-24T13:30:52Z"
+ content="""
+Thanks joey, that's exactly what was happening.
+
+Just to repeat it here, if anyone else runs into the same problem, your post-receive hook has to look like this:
+
+    #!/bin/sh
+    unset GIT_DIR
+    cd ..
+    git annex merge
+
+"""]]
diff --git a/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_4_cfa52c727baaf683e91c3fbb1c78072c._comment b/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_4_cfa52c727baaf683e91c3fbb1c78072c._comment
new file mode 100644
index 0000000000..1890eabae0
--- /dev/null
+++ b/doc/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/comment_4_cfa52c727baaf683e91c3fbb1c78072c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-02-17T19:34:55Z"
+ content="""
+An easier way to set this up is available now, see 
+<https://git-annex.branchable.com/tips/making_a_remote_repo_update_when_changes_are_pushed_to_it/>
+"""]]
diff --git a/doc/forum/Can__39__t_get_jabber_working.mdwn b/doc/forum/Can__39__t_get_jabber_working.mdwn
new file mode 100644
index 0000000000..6f129ee311
--- /dev/null
+++ b/doc/forum/Can__39__t_get_jabber_working.mdwn
@@ -0,0 +1,7 @@
+I've been running circles around the "jabber account setup" in assistant. I tried using jabber.org (isode) and jabber.de (openfire), but whatever I do I get thrown back to an Error page
+
+"Firefox can't establish a connection to the server at 127.0.0.1:61967." 
+
+Assistant definetly tries to connect to the server (LittleSnitch is giving me a hint) and the connections are unblocked. Even after turning LittleSnitch off completely it won't work. On the other hand, I can connect to the servers using Jitsi without any problems. I'd be really thankful for any help.
+
+David 
diff --git a/doc/forum/Can__39__t_get_jabber_working/comment_1_def20bf0b3c1a188e4dad5ec67b455d8._comment b/doc/forum/Can__39__t_get_jabber_working/comment_1_def20bf0b3c1a188e4dad5ec67b455d8._comment
new file mode 100644
index 0000000000..e2491de644
--- /dev/null
+++ b/doc/forum/Can__39__t_get_jabber_working/comment_1_def20bf0b3c1a188e4dad5ec67b455d8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn_3tllXjSmtgm__aGr9Z4gVNFgJgGyJ30"
+ nickname="David Alan"
+ subject="Edit:"
+ date="2014-01-14T16:31:05Z"
+ content="""
+I tried this on a OS X 10.9.1 and OS X 10.8.5 as well as the regular dmg download and the autobuild.
+"""]]
diff --git a/doc/forum/Can__39__t_get_jabber_working/comment_2_7cb49c0ebfec6e0fe6784e189ed65d40._comment b/doc/forum/Can__39__t_get_jabber_working/comment_2_7cb49c0ebfec6e0fe6784e189ed65d40._comment
new file mode 100644
index 0000000000..d4b296cd52
--- /dev/null
+++ b/doc/forum/Can__39__t_get_jabber_working/comment_2_7cb49c0ebfec6e0fe6784e189ed65d40._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.43"
+ subject="comment 2"
+ date="2014-01-14T18:56:44Z"
+ content="""
+You apprear to be experiencing this bug: [[bugs/Share_with_friends_crash_in_osx]]
+"""]]
diff --git a/doc/forum/Can__39__t_get_jabber_working/comment_3_852dc402a286e38b77b99f174c33f8d1._comment b/doc/forum/Can__39__t_get_jabber_working/comment_3_852dc402a286e38b77b99f174c33f8d1._comment
new file mode 100644
index 0000000000..251047f264
--- /dev/null
+++ b/doc/forum/Can__39__t_get_jabber_working/comment_3_852dc402a286e38b77b99f174c33f8d1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn_3tllXjSmtgm__aGr9Z4gVNFgJgGyJ30"
+ nickname="David Alan"
+ subject="Yes"
+ date="2014-01-15T01:41:12Z"
+ content="""
+Will put future comments there. Thanks you.
+"""]]
diff --git a/doc/forum/Can__39__t_get_jabber_working/comment_4_259741e146906ff70540390bdfe07002._comment b/doc/forum/Can__39__t_get_jabber_working/comment_4_259741e146906ff70540390bdfe07002._comment
new file mode 100644
index 0000000000..005759caf9
--- /dev/null
+++ b/doc/forum/Can__39__t_get_jabber_working/comment_4_259741e146906ff70540390bdfe07002._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlm_3m5gLhML9bHbZ8FpJ-HBZhWaRfFeO8"
+ nickname="Corey"
+ subject="Same bug? OSX 10.9.1"
+ date="2014-01-23T23:38:32Z"
+ content="""
+… using Chrome. Connection to 127.0.0.1:XXXXX interrupted when setting up Jabber.
+"""]]
diff --git a/doc/forum/Can__39__t_get_pairing_to_work.mdwn b/doc/forum/Can__39__t_get_pairing_to_work.mdwn
new file mode 100644
index 0000000000..fc45bffcb4
--- /dev/null
+++ b/doc/forum/Can__39__t_get_pairing_to_work.mdwn
@@ -0,0 +1,5 @@
+I'm trying to pair my ~/music repositories on my two laptops (Ubuntu 10.04 and 12.04) using the Linux standalone tarball on my home WiFi network. After entering the same passphrase on both machines, nothing happens, both remain in "Pairing in progress" state.
+
+The router I'm using is, I think, fairly standard, it's a ZyXEL P-2812HNU-F1 with factory settings.
+
+Are others having the problem too? Any advice where I should start looking for what goes wrong?
diff --git a/doc/forum/Can__39__t_get_pairing_to_work/comment_1_b981977b4fb942fd109c37fcf40f35d7._comment b/doc/forum/Can__39__t_get_pairing_to_work/comment_1_b981977b4fb942fd109c37fcf40f35d7._comment
new file mode 100644
index 0000000000..5e6690354a
--- /dev/null
+++ b/doc/forum/Can__39__t_get_pairing_to_work/comment_1_b981977b4fb942fd109c37fcf40f35d7._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.8"
+ subject="comment 1"
+ date="2012-10-11T23:48:37Z"
+ content="""
+It's not clear from your description whether you
+
+a) Started the pairing process independently on both machines... which probably doesn't work.
+
+b) Started pairing on one machine, and the other one noticed and popped up a pair request alert where
+you re-entered the password.
+
+If b) didn't happen, then the the pairing broadcast is not being seen by the second machine.
+You can try using tcpdump or wireshark to see the traffic. The traffic will look like this:
+
+<pre>
+19:45:11.125893 IP 10.1.1.2.43376 > 224.0.0.1.55556: UDP, length 692
+</pre>
+
+If all is going well, you should be able to see that on both the machine that's initiating the pairing and the other machine. And every other machine on the network for that matter.
+"""]]
diff --git a/doc/forum/Can__39__t_get_pairing_to_work/comment_2_341e2ff6c88ace1b1422e16781edf580._comment b/doc/forum/Can__39__t_get_pairing_to_work/comment_2_341e2ff6c88ace1b1422e16781edf580._comment
new file mode 100644
index 0000000000..541b0e5812
--- /dev/null
+++ b/doc/forum/Can__39__t_get_pairing_to_work/comment_2_341e2ff6c88ace1b1422e16781edf580._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlZvtBCVyJw4O71OPsdwGpVh6iJ1W-xaPc"
+ nickname="Kilian"
+ subject="comment 2"
+ date="2012-10-17T14:39:58Z"
+ content="""
+Thanks - it seems to be a problem with my router's firmware.
+"""]]
diff --git a/doc/forum/Can__39__t_get_pairing_to_work/comment_3_0c8cce48f179f2564ff0844bb7ef6bd1._comment b/doc/forum/Can__39__t_get_pairing_to_work/comment_3_0c8cce48f179f2564ff0844bb7ef6bd1._comment
new file mode 100644
index 0000000000..f1ade11f97
--- /dev/null
+++ b/doc/forum/Can__39__t_get_pairing_to_work/comment_3_0c8cce48f179f2564ff0844bb7ef6bd1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 3"
+ date="2012-10-17T17:35:11Z"
+ content="""
+Well, that's interesting. I wonder if other broadcast network services work over your router? The most common one is probably the avahi/zeroconf services.
+"""]]
diff --git a/doc/forum/Can__39__t_get_pairing_to_work/comment_4_169d77b30cea05125068ee1eeb2ef328._comment b/doc/forum/Can__39__t_get_pairing_to_work/comment_4_169d77b30cea05125068ee1eeb2ef328._comment
new file mode 100644
index 0000000000..7725a3a62a
--- /dev/null
+++ b/doc/forum/Can__39__t_get_pairing_to_work/comment_4_169d77b30cea05125068ee1eeb2ef328._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlZvtBCVyJw4O71OPsdwGpVh6iJ1W-xaPc"
+ nickname="Kilian"
+ subject="comment 4"
+ date="2012-10-18T22:44:40Z"
+ content="""
+Hmm... using avahi-discover the two machines can indeed see some services offered by each other. A git-annex-assistant specific problem after all?
+
+So when I initiate a pairing on 192.168.1.63, and run tcpdump on the same machine, it looks like this:
+
+ke@thot:~/opt/git-annex.linux$ sudo tcpdump -i eth1 host 224.0.0.1 -n
+tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
+listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
+00:33:47.723989 IP 192.168.1.63.56243 > 224.0.0.1.55556: UDP, length 691
+00:33:49.729242 IP 192.168.1.63.55072 > 224.0.0.1.55556: UDP, length 691
+00:33:51.733358 IP 192.168.1.63.55115 > 224.0.0.1.55556: UDP, length 691
+00:33:53.736730 IP 192.168.1.63.60249 > 224.0.0.1.55556: UDP, length 691
+00:33:55.741641 IP 192.168.1.63.59753 > 224.0.0.1.55556: UDP, length 691
+
+The same command (modulo different interface name) on the other machine (192.168.1.59) turns up nothing:
+
+ke@apis:~/opt/git-annex.linux$ sudo tcpdump -i wlan0 host 224.0.0.1 -n
+tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
+listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
+"""]]
diff --git a/doc/forum/Can__39__t_get_pairing_to_work/comment_5_70e6c4f4f01277be1767b38ca8374793._comment b/doc/forum/Can__39__t_get_pairing_to_work/comment_5_70e6c4f4f01277be1767b38ca8374793._comment
new file mode 100644
index 0000000000..2b249ab575
--- /dev/null
+++ b/doc/forum/Can__39__t_get_pairing_to_work/comment_5_70e6c4f4f01277be1767b38ca8374793._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.23"
+ subject="comment 5"
+ date="2012-10-22T16:18:56Z"
+ content="""
+So, the only difference I can think of is that avahi uses a different multicast address than the one I picked for git-annex. It may be that your router is only letting that one address through even though it's supposed to let a whole range through.
+
+I've prepared a test build of git-annex that uses the same 224.0.0.251 address avahi does. http://downloads.kitenet.net/tmp/git-annex-standalone-i386.tar.gz (i386 build)
+If you can try that and see how it behaves, I'll see if I need to change the address.
+"""]]
diff --git a/doc/forum/Can__39__t_get_pairing_to_work/comment_6_2cd014a76fac6e08269dfd8146957418._comment b/doc/forum/Can__39__t_get_pairing_to_work/comment_6_2cd014a76fac6e08269dfd8146957418._comment
new file mode 100644
index 0000000000..49a5a9ac90
--- /dev/null
+++ b/doc/forum/Can__39__t_get_pairing_to_work/comment_6_2cd014a76fac6e08269dfd8146957418._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlZvtBCVyJw4O71OPsdwGpVh6iJ1W-xaPc"
+ nickname="Kilian"
+ subject="comment 6"
+ date="2012-10-22T19:44:45Z"
+ content="""
+Yep, with the test build I see the pair request and can respond to it!
+
+Pairing doesn't seem to succeed, but that looks like a different issue. I'll try around some more and report back, probably in a new thread.
+"""]]
diff --git a/doc/forum/Can__39__t_get_pairing_to_work/comment_7_b9b715084d5a5562998b1724699d49e5._comment b/doc/forum/Can__39__t_get_pairing_to_work/comment_7_b9b715084d5a5562998b1724699d49e5._comment
new file mode 100644
index 0000000000..69d6e12e09
--- /dev/null
+++ b/doc/forum/Can__39__t_get_pairing_to_work/comment_7_b9b715084d5a5562998b1724699d49e5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.23"
+ subject="comment 7"
+ date="2012-10-22T19:49:44Z"
+ content="""
+All right, I'll change the address.
+"""]]
diff --git a/doc/forum/Can__39__t_get_some_files_from_bare_repo.mdwn b/doc/forum/Can__39__t_get_some_files_from_bare_repo.mdwn
new file mode 100644
index 0000000000..8b399621c9
--- /dev/null
+++ b/doc/forum/Can__39__t_get_some_files_from_bare_repo.mdwn
@@ -0,0 +1,21 @@
+# Description
+I have a bare repo on a USB drive with ntfs. Files there sink from two PC: one with WSL/Ubuntu on Windows 10 and one with Manjaro linux.
+I found that though some files are on the usb git annex says:  content is not present in remote as I getting them.
+
+# Researching
+I tried drop files from the usb an copy them there again. And I discovered that on the usb now are two files in different folders:
+
+Before dropping / copy it was: 
+```.git/annex/objects/Pg/vw/SHA256E-s91600--aa3c4ec61a1b5642b8c9c0f04dd36884130b8f0135bc9dae9b48b71c26511e4f.xlsx/SHA256E-s91600--aa3c4ec61a1b5642b8c9c0f04dd36884130b8f0135bc9dae9b48b71c26511e4f.xlsx```
+
+After this there appeared another one: 
+```.git/annex/objects/d21/4c3/SHA256E-s91600--aa3c4ec61a1b5642b8c9c0f04dd36884130b8f0135bc9dae9b48b71c26511e4f.xlsx/SHA256E-s91600--aa3c4ec61a1b5642b8c9c0f04dd36884130b8f0135bc9dae9b48b71c26511e4f.xlsx```
+
+# git-annex versions
+on the wsl: 8.20.200226
+on the manjaro linux: 8.20210428-g27e5f3cd5
+
+# Question
+I understood that it's something about old and new hash format but how to get files in a such situation? Or how to unify hash format?
+
+[[!tag forumbug]] [[bugs/done]]
diff --git a/doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_1_ead60b63efb06249c99202631ef0b247._comment b/doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_1_ead60b63efb06249c99202631ef0b247._comment
new file mode 100644
index 0000000000..71d75f213c
--- /dev/null
+++ b/doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_1_ead60b63efb06249c99202631ef0b247._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-07-15T15:51:16Z"
+ content="""
+Note that 8.20.200226 is not a valid git-annex version and it would be good
+to know the actual version used on WSL.
+
+The mixed-case folder name is what git-annex uses when storing files in a
+git repository that is not bare. The lower-case 3 letter name is used in a bare
+repository. It is also used when git-annex detects a crippled filesystem
+-- which it likely would for a USB drive using FAT or something. 
+Does the repository have annex.crippledfilesystem set in its git config?
+
+Ok, I found a way to reproduce this. I made a repository with
+annex.crippledfilesystem set, and copied a file to it. Then I unset 
+annex.crippledfilesystem. Getting the file in another repository then
+fails.
+
+git-annex does already deal with cases where a non-bare repo is converted
+to bare, by trying both names, but it does not in this case.
+
+I've fixed the problem, but am still curious about how you got into this
+situation. Anyway, install a git-annex autobuild a few hours after this
+comment to get the fix.
+
+(Please use [[bugs]] to report bug reports in the future, this forum is not
+a BTS and you cause extra work by posting bugs here.)
+"""]]
diff --git a/doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_2_82a5d9005dca476916e4b5df671e3111._comment b/doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_2_82a5d9005dca476916e4b5df671e3111._comment
new file mode 100644
index 0000000000..91f57fc2c5
--- /dev/null
+++ b/doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_2_82a5d9005dca476916e4b5df671e3111._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="guardcat"
+ avatar="http://cdn.libravatar.org/avatar/60a9f9f0159e3a732d448f0fd5642d41"
+ subject="Fixing problem"
+ date="2021-07-16T06:21:23Z"
+ content="""
+Thanks for you answer! 
+Sorry for choosing the wrong way to report the rpoblem. It happend because I didn't think it's the program's bug I thought it's my mistake.
+My WSL repo works on FAT32 so it's crippled. The version it the exactly what the git annex says me by ```git annex version``` on WSL. May be Ubuntu developers repacked it?
+
+# How I got into
+1. On the WSL system I mounted NTFS usb-stick.
+2. I created a folder on the usb stick and run ```git init``` and ```git annex init``` in it.
+3. I gone to my HDD repo and done ```git remote add usb /way/to/usb/folder```.
+4. I set ```archive``` group for the usb stick.
+5. I done ```git annex sync --content``` that copied all needed files to the usb stick. 
+6. When I started sync at home I noticed that not all files are on the usb stick. 
+
+# As I seem to have fixed it
+I use my distributive's version of git annex, so I wil get the new version much later.
+I done some steps to fix the problem. Were I right?
+I started ```git annex fix``` in my bare repo, and this command found that approximately a half of files aren't present though they ought to be there according to log. Log was fixed in three hours and then I synced repos. But my WSL repo is behind a NAT so I will sync it in several days and I a little afraid of some problems with it.
+
+If you can give me some pieces of advice to avoid further porblems in my situation I woud be happy.
+"""]]
diff --git a/doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_3_430c7854e33ff3e821ebd00b436dbf45._comment b/doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_3_430c7854e33ff3e821ebd00b436dbf45._comment
new file mode 100644
index 0000000000..21140e031f
--- /dev/null
+++ b/doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_3_430c7854e33ff3e821ebd00b436dbf45._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="guardcat"
+ avatar="http://cdn.libravatar.org/avatar/60a9f9f0159e3a732d448f0fd5642d41"
+ subject="appendix"
+ date="2021-07-16T06:34:53Z"
+ content="""
+And I forgot to add: my home repo is on ext4, so it isn't cripled. And my work repo and the repo on my usb stick are marked as a crippled filesystem both.
+"""]]
diff --git a/doc/forum/Can__39__t_init_git_annex.mdwn b/doc/forum/Can__39__t_init_git_annex.mdwn
new file mode 100644
index 0000000000..85be0e1071
--- /dev/null
+++ b/doc/forum/Can__39__t_init_git_annex.mdwn
@@ -0,0 +1,15 @@
+It seems I can't initialize git annex:
+
+    $ git annex init "files2"
+    init files2 
+      pre-commit hook (/Volumes/project/annex/.git/hooks/pre-commit) already exists, not configuring
+    
+    git-annex: waitToSetLock: failed (Operation not supported)
+    failed
+    git-annex: init: 1 failed
+    $
+
+
+  `project` is a remote file server connected via `smb://`.
+
+   Any ideas why and how to fix?
diff --git a/doc/forum/Can__39__t_init_git_annex/comment_10_c4d2ab1ecf69718a2211c3ea7b27092b._comment b/doc/forum/Can__39__t_init_git_annex/comment_10_c4d2ab1ecf69718a2211c3ea7b27092b._comment
new file mode 100644
index 0000000000..273d0c1351
--- /dev/null
+++ b/doc/forum/Can__39__t_init_git_annex/comment_10_c4d2ab1ecf69718a2211c3ea7b27092b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.8"
+ subject="comment 10"
+ date="2012-10-16T05:52:08Z"
+ content="""
+If you need a git repository with your regular file names on the smb share, none of the special remotes will meet your needs. You'd need to find a way to make it support POSIX locking to use git-annex on it in a full git repository.
+
+But I think that in most cases a directory special remote on such a share, with the git repository kept locally and git-annex used to pull files down to it as needed, would work ok.
+"""]]
diff --git a/doc/forum/Can__39__t_init_git_annex/comment_12_fca9ed3707e097bee2cd642424681005._comment b/doc/forum/Can__39__t_init_git_annex/comment_12_fca9ed3707e097bee2cd642424681005._comment
new file mode 100644
index 0000000000..adc9fba3bb
--- /dev/null
+++ b/doc/forum/Can__39__t_init_git_annex/comment_12_fca9ed3707e097bee2cd642424681005._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZ0g2UAijV7RGrKtWPljCCAYHBJ3pwPvM"
+ nickname="Meng"
+ subject="comment 12"
+ date="2012-10-16T06:01:44Z"
+ content="""
+OK;   The purpose of putting files on the remote `smb://` partition is to publish these big data files, so other (potentially non-technical) people can download and use them.  They'll not be willing to learn how to use git, let alone git-annex.  And i have multiple development machines that can generate revisions/updates to these big files.  I previously just rsync from/to various development machines to/from this smb partition, but i find sometimes I don't always srync in correct direction.  The hope is i can have annex on these development machines, and set the smb:// partition as the remote for these git annex.    But it sounds like none of the special remote will have the original form, and a normal remote is not possible on smb:// partition.  
+"""]]
diff --git a/doc/forum/Can__39__t_init_git_annex/comment_1_a294b5e7e52aa9f66a708866be16f137._comment b/doc/forum/Can__39__t_init_git_annex/comment_1_a294b5e7e52aa9f66a708866be16f137._comment
new file mode 100644
index 0000000000..2dd0575eca
--- /dev/null
+++ b/doc/forum/Can__39__t_init_git_annex/comment_1_a294b5e7e52aa9f66a708866be16f137._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.8"
+ subject="comment 1"
+ date="2012-10-16T02:52:26Z"
+ content="""
+The smb:// is a red flag to me. git-annex relies on POSIX file locking, and I'll bet smb does not provide that, or, perhaps, your samba server needs a configuration change to support it.
+
+You might consider putting your git annex repository on the local filesystem, and setting up a [[special_remote|special_remotes]] on smb. The [[special_remotes/directory]] special remote is a likely choice.
+"""]]
diff --git a/doc/forum/Can__39__t_init_git_annex/comment_2_fcf678d5188821d63b4c9ea5b59474a8._comment b/doc/forum/Can__39__t_init_git_annex/comment_2_fcf678d5188821d63b4c9ea5b59474a8._comment
new file mode 100644
index 0000000000..c3596a5185
--- /dev/null
+++ b/doc/forum/Can__39__t_init_git_annex/comment_2_fcf678d5188821d63b4c9ea5b59474a8._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZ0g2UAijV7RGrKtWPljCCAYHBJ3pwPvM"
+ nickname="Meng"
+ subject="comment 2"
+ date="2012-10-16T03:19:43Z"
+ content="""
+Thanks for getting back so quick; So, after doing
+
+    git annex initremote smb type=directory directory=/Volumes/subproject/ encryption=none
+    git annex describe smb \"smb://XXXhost.com/subproject\"
+
+What else do i need to do?  Do i need to `git init` and/or `git annex init` in `/Volumes/subproject/`?
+"""]]
diff --git a/doc/forum/Can__39__t_init_git_annex/comment_3_c83f7dea7d5304e226e52eb3c43ef14a._comment b/doc/forum/Can__39__t_init_git_annex/comment_3_c83f7dea7d5304e226e52eb3c43ef14a._comment
new file mode 100644
index 0000000000..c7680bc936
--- /dev/null
+++ b/doc/forum/Can__39__t_init_git_annex/comment_3_c83f7dea7d5304e226e52eb3c43ef14a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.8"
+ subject="comment 3"
+ date="2012-10-16T04:12:55Z"
+ content="""
+Nope, you're set with just those two commands. You can now do things like \"git annex copy --to smb\"
+to put files there, and \"git annex get\" will get files from there as necessary.
+"""]]
diff --git a/doc/forum/Can__39__t_init_git_annex/comment_4_06a01dd51ffbfd006c0afb8eab40b530._comment b/doc/forum/Can__39__t_init_git_annex/comment_4_06a01dd51ffbfd006c0afb8eab40b530._comment
new file mode 100644
index 0000000000..421f98e626
--- /dev/null
+++ b/doc/forum/Can__39__t_init_git_annex/comment_4_06a01dd51ffbfd006c0afb8eab40b530._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZ0g2UAijV7RGrKtWPljCCAYHBJ3pwPvM"
+ nickname="Meng"
+ subject="comment 4"
+ date="2012-10-16T04:17:11Z"
+ content="""
+Could i use (some variant of) `git annex sync` to do two-way sync between local and `smb`?
+"""]]
diff --git a/doc/forum/Can__39__t_init_git_annex/comment_5_53c33484bded57abc60f0449331c7b05._comment b/doc/forum/Can__39__t_init_git_annex/comment_5_53c33484bded57abc60f0449331c7b05._comment
new file mode 100644
index 0000000000..996a7a5fcf
--- /dev/null
+++ b/doc/forum/Can__39__t_init_git_annex/comment_5_53c33484bded57abc60f0449331c7b05._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.8"
+ subject="comment 5"
+ date="2012-10-16T04:23:59Z"
+ content="""
+`git annex sync` only syncs the git repository, not file contents, and the special remote has no git repo, only file contents. `git annex copy` will avoid transferring things that are already there, so it's the way to go.
+
+If you want automatic syncing of file contents and lots of other magic including automatic commit of new files, you could try the [[forum/`git_annex_assistant`_command_replace_all_files_with_pointer_file.]].
+
+"""]]
diff --git a/doc/forum/Can__39__t_init_git_annex/comment_6_9e0ff44f6e62581bfc83f9f1da3e0100._comment b/doc/forum/Can__39__t_init_git_annex/comment_6_9e0ff44f6e62581bfc83f9f1da3e0100._comment
new file mode 100644
index 0000000000..36c0bb5d59
--- /dev/null
+++ b/doc/forum/Can__39__t_init_git_annex/comment_6_9e0ff44f6e62581bfc83f9f1da3e0100._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZ0g2UAijV7RGrKtWPljCCAYHBJ3pwPvM"
+ nickname="Meng"
+ subject="comment 6"
+ date="2012-10-16T04:38:40Z"
+ content="""
+OK;  The reason i ask about `git annex sync` is because I had previously copied the large files onto `smb://` before setting up the `annex` and don't want to unnecessarily transfer large data over Internet again.  But now if i do `git annex copy --to smb`, and check what's added/changed in `smb` end, i found 
+ 
+    $ cd /Volumes/subproject
+    $ ls
+    091		383		bigdir1    bigfile1  ...
+
+The files with numbers in names such as`091`, `383` are being added, the `bigfile1` and `bigdir1` are the ones previously copied there.  What are those `091`, `383` etc.
+"""]]
diff --git a/doc/forum/Can__39__t_init_git_annex/comment_7_7f96b5ef05e2faf4a3dbe8bfc39b810e._comment b/doc/forum/Can__39__t_init_git_annex/comment_7_7f96b5ef05e2faf4a3dbe8bfc39b810e._comment
new file mode 100644
index 0000000000..9c29567f68
--- /dev/null
+++ b/doc/forum/Can__39__t_init_git_annex/comment_7_7f96b5ef05e2faf4a3dbe8bfc39b810e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.8"
+ subject="comment 7"
+ date="2012-10-16T04:52:12Z"
+ content="""
+That's where it stores files in the directory special remote. You can move the similar contents of /Volumes/subproject/.git/annex/objects/ to the same place as those and then run `git annex fsck --from smb --fast` and it'll learn about those files you already transferred.
+
+You probably also want to delete /Volumes/subproject/.git afterwards, and any git working tree that was checked out there before; the directory special remote does not use the git repository that you had there before.
+"""]]
diff --git a/doc/forum/Can__39__t_init_git_annex/comment_8_65ab8463716f4ddd7721a5bcfcd18fa0._comment b/doc/forum/Can__39__t_init_git_annex/comment_8_65ab8463716f4ddd7721a5bcfcd18fa0._comment
new file mode 100644
index 0000000000..8f37408f77
--- /dev/null
+++ b/doc/forum/Can__39__t_init_git_annex/comment_8_65ab8463716f4ddd7721a5bcfcd18fa0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZ0g2UAijV7RGrKtWPljCCAYHBJ3pwPvM"
+ nickname="Meng"
+ subject="comment 8"
+ date="2012-10-16T05:22:54Z"
+ content="""
+Oh,  I see.   But what I need on the remote partition `/Volumes/subproject` connected via `smb://` is the actual `bigdir1` and `bigfile`, not the encoded objects.  Maybe I should use some other types of special remote?
+"""]]
diff --git a/doc/forum/Can__39__t_init_git_annex/comment_9_31a45f6a72266190b3ed7a7b02e03d5b._comment b/doc/forum/Can__39__t_init_git_annex/comment_9_31a45f6a72266190b3ed7a7b02e03d5b._comment
new file mode 100644
index 0000000000..94db3f2fef
--- /dev/null
+++ b/doc/forum/Can__39__t_init_git_annex/comment_9_31a45f6a72266190b3ed7a7b02e03d5b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZ0g2UAijV7RGrKtWPljCCAYHBJ3pwPvM"
+ nickname="Meng"
+ subject="comment 9"
+ date="2012-10-16T05:33:06Z"
+ content="""
+Maybe i didn't explain clearly at the beginning:  `/Volumes/subproject` is a remote partition connected via smb://.  It doesn't have a `.git`.  The content I mentioned previously \"copied\" there was copied via `cp -R`.  And my local annex is `~/project/subproject` and it does have `.git` and `.git/annex` in it.
+"""]]
diff --git a/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2.mdwn b/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2.mdwn
new file mode 100644
index 0000000000..d63acdcb8b
--- /dev/null
+++ b/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2.mdwn
@@ -0,0 +1,36 @@
+###Tried to install git-annex.app
+
+- App hangs up
+- Cpu "git" load is 100
+- Had to force quite git-annex
+
+###Install thru command line: using Brew
+
+- Installed haskell
+- updated cabal
+- But when I do:
+
+`
+cabal install git-annex --bindir=$HOME/bin
+`
+
+**I get this**
+
+    Resolving dependencies...
+    Configuring gnuidn-0.2...
+    cabal: The program c2hs is required but it could not be found.
+    Configuring libxml-sax-0.7.3...
+    cabal: The pkg-config package libxml-2.0 is required but it could not be found.
+    cabal: Error: some packages failed to install:
+    git-annex-3.20121127.1 depends on libxml-sax-0.7.3 which failed to install.
+    gnuidn-0.2 failed during the configure step. The exception was:
+    ExitFailure 1
+    libxml-sax-0.7.3 failed during the configure step. The exception was:
+    ExitFailure 1
+    network-protocol-xmpp-0.4.4 depends on libxml-sax-0.7.3 which failed to install.
+
+Any help would be greatly appreciated. 
+
+Thanks,
+
+Carlito
diff --git a/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_1_c44023d81e9e4f7c9341af0e4271a1e4._comment b/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_1_c44023d81e9e4f7c9341af0e4271a1e4._comment
new file mode 100644
index 0000000000..43f86c8b04
--- /dev/null
+++ b/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_1_c44023d81e9e4f7c9341af0e4271a1e4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.253.113"
+ subject="comment 1"
+ date="2012-12-06T18:09:13Z"
+ content="""
+The lack of c2hs can be dealt with by `cabal install c2hs` (which the install instructions already say to do).
+
+Nobody currently understands why git commands are spinning and using all CPU when run by the app. This is being tracked at [[bugs/OSX_app_issues]].
+"""]]
diff --git a/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_2_dfbcd39eedff28dc9ed866a8f1411ef3._comment b/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_2_dfbcd39eedff28dc9ed866a8f1411ef3._comment
new file mode 100644
index 0000000000..904fbb15c6
--- /dev/null
+++ b/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_2_dfbcd39eedff28dc9ed866a8f1411ef3._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlxKQEwwP6J58W0Dmfq0-v0j3LXtT5gNAA"
+ nickname="Carlito"
+ subject="Thanks"
+ date="2012-12-06T19:23:48Z"
+ content="""
+Thanks joey!
+
+Sorry missed `cabal install c2hs` in the instruction. But got passed that and still can't install.
+
+    Resolving dependencies...
+    Configuring libxml-sax-0.7.3...
+    cabal: The pkg-config package libxml-2.0 is required but it could not be found.
+    cabal: Error: some packages failed to install:
+    git-annex-3.20121127.1 depends on libxml-sax-0.7.3 which failed to install.
+    libxml-sax-0.7.3 failed during the configure step. The exception was:
+    ExitFailure 1
+    network-protocol-xmpp-0.4.4 depends on libxml-sax-0.7.3 which failed to install.
+
+I tried
+
+    brew install libxml2
+    cabal install libxml
+
+Also I added $HOME/.cabal/bin to my path
+
+Thanks,
+
+Carlito
+"""]]
diff --git a/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_3_b37b2a9906ffb956cca91adb4bb4e521._comment b/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_3_b37b2a9906ffb956cca91adb4bb4e521._comment
new file mode 100644
index 0000000000..dbfff2a84e
--- /dev/null
+++ b/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_3_b37b2a9906ffb956cca91adb4bb4e521._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.162"
+ subject="comment 3"
+ date="2012-12-06T21:20:19Z"
+ content="""
+I can't help with installing libraries on OSX, but you can disable XMPP support in git-annex like this: \"cabal install git-annex -f-XMPP\"
+"""]]
diff --git a/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_4_afddf16f8faedc78d458835480f10dc3._comment b/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_4_afddf16f8faedc78d458835480f10dc3._comment
new file mode 100644
index 0000000000..c221455fcb
--- /dev/null
+++ b/doc/forum/Can__39__t_install__58___Mac_OS_10.8.2/comment_4_afddf16f8faedc78d458835480f10dc3._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlxKQEwwP6J58W0Dmfq0-v0j3LXtT5gNAA"
+ nickname="Carlito"
+ subject="Got it to work!"
+ date="2012-12-06T22:17:55Z"
+ content="""
+Had to link it: 
+
+    brew install libxml2 
+    brew link libxml2
+
+Thanks for your help.
+
+Will test out annex and leave any bug reports.
+"""]]
diff --git a/doc/forum/Can__39__t_upload_data_to_glacier_remote.mdwn b/doc/forum/Can__39__t_upload_data_to_glacier_remote.mdwn
new file mode 100644
index 0000000000..fbf95df7bc
--- /dev/null
+++ b/doc/forum/Can__39__t_upload_data_to_glacier_remote.mdwn
@@ -0,0 +1,55 @@
+I'm trying to follow the directions on [this tips page](https://git-annex.branchable.com/tips/using_Amazon_Glacier/) to easily back up some large home videos to Glacier. I followed the steps and everything worked fine until the `git annex copy`, at which point it claimed it was successful but had uploaded 0 bytes, as well as dumping the usage message for `glacier-cli` at the terminal (without any error):
+
+    Emily $ git annex copy --to glacier README
+    copy README (gpg) (checking glacier...) (to glacier...) 
+    100%          0.0 B/s 0s
+    glacier <command> [args]
+
+        Commands
+            vaults    - Operations with vaults
+            jobs      - Operations with jobs
+            upload    - Upload files to a vault. If the vault doesn't exits, it is
+                        created
+
+        Common args:
+            --access_key - Your AWS Access Key ID.  If not supplied, boto will
+                           use the value of the environment variable
+                           AWS_ACCESS_KEY_ID
+            --secret_key - Your AWS Secret Access Key.  If not supplied, boto
+                           will use the value of the environment variable
+                           AWS_SECRET_ACCESS_KEY
+            --region     - AWS region to use. Possible values: us-east-1, us-west-1,
+                           us-west-2, ap-northeast-1, eu-west-1.
+                           Default: us-east-1
+
+        Vaults operations:
+
+            List vaults:
+                glacier vaults 
+
+        Jobs operations:
+
+            List jobs:
+                glacier jobs <vault name>
+
+        Uploading files:
+
+            glacier upload <vault name> <files>
+
+            Examples : 
+                glacier upload pics *.jpg
+                glacier upload pics a.jpg b.jpg
+
+    ok                      
+    (Recording state in git...)
+
+Doing a `glacier vaults` also does not show any new vaults, and getting the usage message is obviously not normal.
+
+I tried doing a manual upload to a vault I already had sitting around from some years ago called `TVault`, and that looked to work fine:
+
+    Emily $ glacier upload TVault README 
+    Uploading README to TVault... done. Vault returned ArchiveID [omitted]
+
+(The update date hasn't updated on the management console yet, but I understand that may take up to a day.)
+
+Does anyone know what's going on, or is there at least a way to get a useful error message to output?
diff --git a/doc/forum/Can__39__t_upload_data_to_glacier_remote/comment_1_cb18d5d63663f73a343c8972faadc83a._comment b/doc/forum/Can__39__t_upload_data_to_glacier_remote/comment_1_cb18d5d63663f73a343c8972faadc83a._comment
new file mode 100644
index 0000000000..5c18f19271
--- /dev/null
+++ b/doc/forum/Can__39__t_upload_data_to_glacier_remote/comment_1_cb18d5d63663f73a343c8972faadc83a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="basak"
+ subject="comment 1"
+ date="2015-12-13T21:35:59Z"
+ content="""
+Sounds like you're running the boto glacier command rather than the glacier-cli tool. Unfortunately they have the same name (my intention was to deprecate the boto tool but boto upstream deprecated boto entirely instead). The current plan is to rename glacier-cli to glcr, but I haven't got round to doing that yet.
+
+Try making sure that \"glacier\" runs the glacier-cli tool rather than boto's glacier.
+"""]]
diff --git a/doc/forum/Can__39__t_upload_data_to_glacier_remote/comment_2_9b6a397d1c85da87481d36b8a4bd1ba6._comment b/doc/forum/Can__39__t_upload_data_to_glacier_remote/comment_2_9b6a397d1c85da87481d36b8a4bd1ba6._comment
new file mode 100644
index 0000000000..321d4cc37a
--- /dev/null
+++ b/doc/forum/Can__39__t_upload_data_to_glacier_remote/comment_2_9b6a397d1c85da87481d36b8a4bd1ba6._comment
@@ -0,0 +1,252 @@
+[[!comment format=mdwn
+ username="scorchgeek"
+ subject="Indeed"
+ date="2015-12-13T22:30:47Z"
+ content="""
+Nice catch! I couldn't find any install option for `glacier-cli`, so I just added a symlink to the source distribution and figured that would take care of it.
+
+    Emily $ ls /usr/bin -l | grep glacier
+    lrwxrwxrwx 1 root   root          38 Dec 11 16:19 glacier -> /home/soren/bin/glacier-cli/glacier.py
+
+But:
+
+    Emily $ which glacier
+    /usr/local/bin/glacier
+
+Oops. I changed the location of the symlink to somewhere earlier in the path, uninited and reinited the repository, and it uploaded the README.
+
+Unfortunately, now I'm getting a different error, some kind of Unicode issue, when I try to upload one of the files I actually want to back up:
+
+    Emily $ git annex add family-videos/Tape01.mpg
+    add family-videos/Tape01.mpg ok
+    (Recording state in git...)
+
+    Emily $ git commit
+    [master 5af0257] add tape01 as test
+    1 file changed, 1 insertion(+)
+    create mode 120000 family-videos/Tape01.mpg
+
+    Emily $ git annex copy --to glacier
+    copy family-videos/Tape01.mpg (gpg) (checking glacier...) (to glacier...) 
+    0%        8.1MB/s 11m32sTraceback (most recent call last):
+      File \"/home/soren/bin/glacier\", line 730, in <module>
+        App().main()
+      File \"/home/soren/bin/glacier\", line 716, in main
+        self.args.func()
+      File \"/home/soren/bin/glacier\", line 498, in archive_upload
+        file_obj=self.args.file, description=name)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/vault.py\", line 177, in create_archive_from_file
+        writer.write(data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 219, in write
+        self.partitioner.write(data)
+      [...many more things in boto]
+      File \"/usr/lib/python2.7/httplib.py\", line 979, in request
+        self._send_request(method, url, body, headers)
+      File \"/usr/lib/python2.7/httplib.py\", line 1013, in _send_request
+        self.endheaders(body)
+      File \"/usr/lib/python2.7/httplib.py\", line 975, in endheaders
+        self._send_output(message_body)
+      File \"/usr/lib/python2.7/httplib.py\", line 833, in _send_output
+        msg += message_body
+    UnicodeDecodeError: 'ascii' codec can't decode byte 0x8c in position 0: ordinal not in range(128)
+    gpg: [stdout]: write error: Broken pipe
+    gpg: DBG: deflate: iobuf_write failed
+    gpg: build_packet failed: file write error
+    gpg: [stdout]: write error: Broken pipe
+    gpg: iobuf_flush failed on close: file write error
+    gpg: symmetric encryption of `[stdin]' failed: file write error
+    git-annex: fd:14: hPutBuf: resource vanished (Broken pipe)
+    failed
+    git-annex: copy: 1 failed
+
+Here's my complete session setting up the repository, in case it contains other useful information:
+
+    Emily 1020 [/media/backup/Videos]$ git init
+    Initialized empty Git repository in /media/backup/Videos/.git/
+    Emily 1021 [/media/backup/Videos](.)$ git remote add origin https://[myusername]@bitbucket.org/[myusername]/[myreponame].git
+    Emily 1022 [/media/backup/Videos](.)$ git push
+    fatal: The current branch master has no upstream branch.
+    To push the current branch and set the remote as upstream, use
+
+        git push --set-upstream origin master
+
+    Emily 1023 [/media/backup/Videos](.)$ git push -u origin master
+    error: src refspec master does not match any.
+    error: failed to push some refs to [URL]
+    Emily 1024 [/media/backup/Videos](.)$ git add README
+    Emily 1025 [/media/backup/Videos](@)$ ls
+    family-videos  README
+    Emily 1025 [/media/backup/Videos](@)$ git push -u origin master^C
+    Emily 1025 [/media/backup/Videos](@)$ git commit -am \"test commit\"
+    [master (root-commit) 03fb2a7] test commit
+     1 file changed, 1 insertion(+)
+     create mode 100644 README
+    Emily 1026 [/media/backup/Videos](.)$ git push -u origin master
+    Counting objects: 3, done.
+    Writing objects: 100% (3/3), 223 bytes | 0 bytes/s, done.
+    Total 3 (delta 0), reused 0 (delta 0)
+    remote:
+    remote: We're changing our IP addresses on 15 December 2015 at 00:00 UTC.
+    remote: Please make sure your firewalls are up to date:
+    remote: https://blog.bitbucket.org/?p=2677
+    To https://[myusername]@bitbucket.org/[myusername]/[myreponame].git
+     * [new branch]      master -> master
+    Branch master set up to track remote branch master from origin.
+    Emily 1027 [/media/backup/Videos](.)$ git annex init
+    init  ok
+    (Recording state in git...)
+    Emily 1028 [/media/backup/Videos](.)$ git annex --fast initremote glacier type=glacier encryption=hybrid keyid=[my GPG key ID]
+
+      Remote origin not usable by git-annex; setting annex-ignore
+    initremote glacier (encryption setup) (hybrid cipher with gpg key [hybrid key ID]) ok
+    (Recording state in git...)
+    Emily 1029 [/media/backup/Videos](.)$ git annex enableremote glacier
+    enableremote glacier (gpg) (encryption update) (hybrid cipher with gpg key [hybrid key ID]) ok
+    (Recording state in git...)
+    Emily 1030 [/media/backup/Videos](.)$ git annex copy README --to glacier
+    Emily 1031 [/media/backup/Videos](.)$ git annex sync
+    commit  ok
+    pull origin 
+    ok
+    push origin 
+    Counting objects: 13, done.
+    Delta compression using up to 4 threads.
+    Compressing objects: 100% (10/10), done.
+    Writing objects: 100% (12/12), 2.15 KiB | 0 bytes/s, done.
+    Total 12 (delta 3), reused 0 (delta 0)
+    remote: 
+    remote: We're changing our IP addresses on 15 December 2015 at 00:00 UTC.
+    remote: Please make sure your firewalls are up to date:
+    remote: https://blog.bitbucket.org/?p=2677
+    To [repository URL]
+     * [new branch]      git-annex -> synced/git-annex
+     * [new branch]      master -> synced/master
+    ok
+    Emily 1032 [/media/backup/Videos](.)$ git annex status
+    ? family-videos/Tape01.mpg
+    ? family-videos/Tape02.mpg
+    ? family-videos/Tape03.mpg
+    ? family-videos/Tape04.mpg
+    ? family-videos/Tape05.mpg
+    ? family-videos/Tape06.mpg
+    ? family-videos/Tape07.mpg
+    ? family-videos/Tape08.mpg
+    ? family-videos/Tape09.mpg
+    ? family-videos/Tape10.mpg
+    ? family-videos/Tape11.mpg
+    ? family-videos/Tape12.mpg
+    ? family-videos/Tape13.mpg
+    ? family-videos/Tape14.mpg
+    ? family-videos/Tape15.mpg
+    ? family-videos/Tape16.mpg
+    Emily 1033 [/media/backup/Videos](.)$ gitk
+    Emily 1034 [/media/backup/Videos](.)$ git annex copy README --to glacier^C
+    Emily 1034 [/media/backup/Videos](.)$ git annex add family-videos/Tap
+    ...01.mpg  ...04.mpg  ...07.mpg  ...10.mpg  ...13.mpg  ...16.mpg  
+    ...02.mpg  ...05.mpg  ...08.mpg  ...11.mpg  ...14.mpg  
+    ...03.mpg  ...06.mpg  ...09.mpg  ...12.mpg  ...15.mpg  
+    Emily 1034 [/media/backup/Videos](.)$ git annex add family-videos/Tape01.mpg
+    add family-videos/Tape01.mpg ok
+    (Recording state in git...)
+    Emily 1035 [/media/backup/Videos](@)$ git commit
+    [master 5af0257] add tape01 as test
+     1 file changed, 1 insertion(+)
+     create mode 120000 family-videos/Tape01.mpg
+    Emily 1036 [/media/backup/Videos](+)$ git annex copy --to glacier
+    copy family-videos/Tape01.mpg (gpg) (checking glacier...) (to glacier...) 
+    0%        8.1MB/s 11m32sTraceback (most recent call last):
+      File \"/home/soren/bin/glacier\", line 730, in <module>
+        App().main()
+      File \"/home/soren/bin/glacier\", line 716, in main
+        self.args.func()
+      File \"/home/soren/bin/glacier\", line 498, in archive_upload
+        file_obj=self.args.file, description=name)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/vault.py\", line 177, in create_archive_from_file
+        writer.write(data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 219, in write
+        self.partitioner.write(data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 61, in write
+        self._send_part()
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 75, in _send_part
+        self.send_fn(part)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 222, in _upload_part
+        self.uploader.upload_part(self.next_part_index, part_data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 129, in upload_part
+        content_range, part_data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/layer1.py\", line 1279, in upload_part
+        response_headers=response_headers)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/layer1.py\", line 114, in make_request
+        data=data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/connection.py\", line 1071, in make_request
+        retry_handler=retry_handler)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/connection.py\", line 943, in _mexe
+        request.body, request.headers)
+      File \"/usr/lib/python2.7/httplib.py\", line 979, in request
+        self._send_request(method, url, body, headers)
+      File \"/usr/lib/python2.7/httplib.py\", line 1013, in _send_request
+        self.endheaders(body)
+      File \"/usr/lib/python2.7/httplib.py\", line 975, in endheaders
+        self._send_output(message_body)
+      File \"/usr/lib/python2.7/httplib.py\", line 833, in _send_output
+        msg += message_body
+    UnicodeDecodeError: 'ascii' codec can't decode byte 0x8c in position 0: ordinal not in range(128)
+    gpg: [stdout]: write error: Broken pipe
+    gpg: DBG: deflate: iobuf_write failed
+    gpg: build_packet failed: file write error
+    gpg: [stdout]: write error: Broken pipe
+    gpg: iobuf_flush failed on close: file write error
+    gpg: symmetric encryption of `[stdin]' failed: file write error
+    git-annex: fd:15: hPutBuf: resource vanished (Broken pipe)
+    failed
+    git-annex: copy: 1 failed
+    Emily 1037 [/media/backup/Videos](+)$ git annex copy --to glacier
+    copy family-videos/Tape01.mpg (gpg) (checking glacier...) (to glacier...) 
+    0%        8.1MB/s 11m32sTraceback (most recent call last):
+      File \"/home/soren/bin/glacier\", line 730, in <module>
+        App().main()
+      File \"/home/soren/bin/glacier\", line 716, in main
+        self.args.func()
+      File \"/home/soren/bin/glacier\", line 498, in archive_upload
+        file_obj=self.args.file, description=name)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/vault.py\", line 177, in create_archive_from_file
+        writer.write(data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 219, in write
+        self.partitioner.write(data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 61, in write
+        self._send_part()
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 75, in _send_part
+        self.send_fn(part)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 222, in _upload_part
+        self.uploader.upload_part(self.next_part_index, part_data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 129, in upload_part
+        content_range, part_data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/layer1.py\", line 1279, in upload_part
+        response_headers=response_headers)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/layer1.py\", line 114, in make_request
+        data=data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/connection.py\", line 1071, in make_request
+        retry_handler=retry_handler)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/connection.py\", line 943, in _mexe
+        request.body, request.headers)
+      File \"/usr/lib/python2.7/httplib.py\", line 979, in request
+        self._send_request(method, url, body, headers)
+      File \"/usr/lib/python2.7/httplib.py\", line 1013, in _send_request
+        self.endheaders(body)
+      File \"/usr/lib/python2.7/httplib.py\", line 975, in endheaders
+        self._send_output(message_body)
+      File \"/usr/lib/python2.7/httplib.py\", line 833, in _send_output
+        msg += message_body
+    UnicodeDecodeError: 'ascii' codec can't decode byte 0x8c in position 0: ordinal not in range(128)
+    gpg: [stdout]: write error: Broken pipe
+    gpg: DBG: deflate: iobuf_write failed
+    gpg: build_packet failed: file write error
+    gpg: [stdout]: write error: Broken pipe
+    gpg: iobuf_flush failed on close: file write error
+    gpg: symmetric encryption of `[stdin]' failed: file write error
+    git-annex: fd:14: hPutBuf: resource vanished (Broken pipe)
+    failed                  
+    git-annex: copy: 1 failed
+    Emily 1037 [/media/backup/Videos](+)$ 
+
+Thanks a lot for your help!
+"""]]
diff --git a/doc/forum/Can__39__t_upload_data_to_glacier_remote/comment_3_6625da96f8cdc8b367b4c2bc275f2aee._comment b/doc/forum/Can__39__t_upload_data_to_glacier_remote/comment_3_6625da96f8cdc8b367b4c2bc275f2aee._comment
new file mode 100644
index 0000000000..3804eacf5b
--- /dev/null
+++ b/doc/forum/Can__39__t_upload_data_to_glacier_remote/comment_3_6625da96f8cdc8b367b4c2bc275f2aee._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-12-19T18:28:42Z"
+ content="""
+Note that, since version 5.20150219, git-annex probes to see if the
+"glacier" program in PATH is the one from boto, and fails with a nicer
+error message.
+
+The UnicodeDecodeError is mentioned in the thread for
+[[special_remotes/glacier]] too. There is a workaround posted in that
+thread. It would probably be good to nudge the boto maintainers to apply
+the fix, which has been available for at least 3 months now.
+"""]]
diff --git a/doc/forum/Can_a_repo_be_marked_as___34__must_have_file__63____34__.mdwn b/doc/forum/Can_a_repo_be_marked_as___34__must_have_file__63____34__.mdwn
new file mode 100644
index 0000000000..7eb024adfe
--- /dev/null
+++ b/doc/forum/Can_a_repo_be_marked_as___34__must_have_file__63____34__.mdwn
@@ -0,0 +1,5 @@
+Is there a way to mark a repo as needing to have a copy of a file?
+
+I know there's the `remote.<name>.annex-cost` setting but that's done just on a single copy of the repo.
+
+Obviously the problem here would be determining the path to get a file to a repo, so maybe this isn't possible.
diff --git a/doc/forum/Can_a_repo_be_marked_as___34__must_have_file__63____34__/comment_1_14d4d3f84eacc36dcc55af783d189619._comment b/doc/forum/Can_a_repo_be_marked_as___34__must_have_file__63____34__/comment_1_14d4d3f84eacc36dcc55af783d189619._comment
new file mode 100644
index 0000000000..adf1d1c2d8
--- /dev/null
+++ b/doc/forum/Can_a_repo_be_marked_as___34__must_have_file__63____34__/comment_1_14d4d3f84eacc36dcc55af783d189619._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="kevin@f9ce8e46ad8c29b25093b82cf68fae38f54b89a1"
+ nickname="kevin"
+ subject="Groups..."
+ date="2016-09-18T20:35:00Z"
+ content="""
+The answer seems to be [groups](https://git-annex.branchable.com/preferred_content/standard_groups/).
+
+If I set the two repos I want to have content to be in the backup group, they'll always try to get every file the see.
+"""]]
diff --git a/doc/forum/Can_a_repo_be_marked_as___34__must_have_file__63____34__/comment_2_409d6a97f5c3d1f1fc5e932a2965e227._comment b/doc/forum/Can_a_repo_be_marked_as___34__must_have_file__63____34__/comment_2_409d6a97f5c3d1f1fc5e932a2965e227._comment
new file mode 100644
index 0000000000..65ff9ed903
--- /dev/null
+++ b/doc/forum/Can_a_repo_be_marked_as___34__must_have_file__63____34__/comment_2_409d6a97f5c3d1f1fc5e932a2965e227._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-09-21T16:46:16Z"
+ content="""
+Cost settings have nothing to do with this.
+
+[[Preferred_content]] can be configured to include specific files
+that you want to have in the repository, by matching on the filename.
+For example:
+
+	git annex wanted . "include=somefile or include=otherfile or include=*.mp3"
+
+Putting the repository in the backup group is similar to setting
+"include=*"
+"""]]
diff --git a/doc/forum/Can_git-annex-import_--clean-duplicates_honour_multiple_backends__63__.mdwn b/doc/forum/Can_git-annex-import_--clean-duplicates_honour_multiple_backends__63__.mdwn
new file mode 100644
index 0000000000..a75dd0f1b8
--- /dev/null
+++ b/doc/forum/Can_git-annex-import_--clean-duplicates_honour_multiple_backends__63__.mdwn
@@ -0,0 +1,25 @@
+Is there a better way to de-duplicate in a way that considers multiple backends?
+
+Multiple backends can be added to the .git/config annex.backends entry, but what is the purpose of the secondary backends? The first is used when adding new files, but the second (third, fourth, ...) do not seem to serve any purpose. (Or am I missing something?)
+
+Here's my use case, problem, and a possible solution. I frequently use git-annex to de-duplicate. The default SHA256E backend has caused issues since filename case is significant, so I have partially switched to SHA256. I also occasionally use other backends. Now when I'm given an arbitrary file, as far as I can tell, I have to try de-duplicate once for every possible backend which amounts to something like
+
+    for i SHA256E SHA256 SKEIN256 ... ; do
+        [ -f /tmp/afile.pdf ] && git annex import --clean-duplicates --backend=$i /tmp/afile.pdf
+    done
+
+even though my .git/config has annex.backends = "SHA256E SHA256 SKEIN256 ...". I was surprised that `--clean-duplicates` does not honour all listed annex.backends. In this case hashing multiple times as needed seems quite reasonable IMO, so adding multiple backend support for `--clean-duplicates` would solve the problem. If you're not keen to modify this existing behaviour, it might be instead sensible to have to opt-in by explicitly specifying all backends to consider, like
+
+    git annex import --clean-duplicates --backends="SHA256E SHA256 SKEIN256" /tmp/afile.pdf
+
+or
+
+    git annex import --clean-duplicates --backends="$( git config --get annex.backends )" /tmp/afile.pdf
+
+Moving this loop into git-annex would also allow hashing to be parallelized; it currently cannot because the file could disappear.
+
+- - -
+
+PS. Thanks for git-annex Joey. I have around 100 annexes and rely on them on a daily basis.
+
+-supernaught
diff --git a/doc/forum/Can_git-annex-import_--clean-duplicates_honour_multiple_backends__63__/comment_1_5730767d5247e8997b4fa5b20c4cb281._comment b/doc/forum/Can_git-annex-import_--clean-duplicates_honour_multiple_backends__63__/comment_1_5730767d5247e8997b4fa5b20c4cb281._comment
new file mode 100644
index 0000000000..1b6ebca993
--- /dev/null
+++ b/doc/forum/Can_git-annex-import_--clean-duplicates_honour_multiple_backends__63__/comment_1_5730767d5247e8997b4fa5b20c4cb281._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-05-09T18:06:34Z"
+ content="""
+When git-annex is adding a file, a backend can chose to not
+generate any key, and then it will try the next backend in the list.
+
+The only backend that does that is the URL backend.
+So if someone lists URL first for some reason, it'll fall back to a backend
+that is usable. It could just as well crash in that edge case; the
+annex.backends UI happened before the needs of backends were perfectly
+understood. (As did the "backend" name...)
+
+Anyway, I see the use case, but.. `git annex import` actually honors
+annex.backend settings in .gitattributes before annex.backends in
+git-config. So, relying on it using the latter to make it check multiple
+backends won't always work. I don't think it would be good to complicate
+the .gitattributes annex.backends and --backend to support a list of
+backends.
+
+It seems it would be just as fast for you to run git-annex import once per
+backend, rather than compliciating it to try multiple backends. 
+
+I think that if annex.backends were not a list for historical reasons, 
+I'd be suggesting a small shell script is your best option. 
+
+And so rather than add a new feature just because annex.backends is
+historically a list, I'd rather perhaps deprecate annex.backends as
+unncessarily complicated, and make annex.backend be a single-backend
+setting. (Just did that.)
+
+Sorry this didn't quite go the way you wanted! If there is a disadvantage
+to the simple shell script option, please do let me know..
+"""]]
diff --git a/doc/forum/Can_git-annex-import_--clean-duplicates_honour_multiple_backends__63__/comment_2_c2846031bd79fa60cd903fb4d5bcebaf._comment b/doc/forum/Can_git-annex-import_--clean-duplicates_honour_multiple_backends__63__/comment_2_c2846031bd79fa60cd903fb4d5bcebaf._comment
new file mode 100644
index 0000000000..7a381bf518
--- /dev/null
+++ b/doc/forum/Can_git-annex-import_--clean-duplicates_honour_multiple_backends__63__/comment_2_c2846031bd79fa60cd903fb4d5bcebaf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="supernaught"
+ avatar="http://cdn.libravatar.org/avatar/55f92a50f2617099e2dc7509130ce158"
+ subject="comment 2"
+ date="2017-05-09T22:07:59Z"
+ content="""
+Your solution is reasonable. Simpler is better.
+
+Thanks.
+"""]]
diff --git a/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__.mdwn b/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__.mdwn
new file mode 100644
index 0000000000..0b49f422fa
--- /dev/null
+++ b/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__.mdwn
@@ -0,0 +1,76 @@
+Hi, I tried with several git annex versions, on 3 different clients, and using 2 different remotes (an home server and box.com) and trying out different remotes setups but I've been unable to get git annex working as I expected.
+
+
+I used the assistant for setup, I can sync files between clients just fine if they're connected at the same time, but if I sync a file from client A to the remotes when client B is off, and then later I turn off client A and power on client B, I've never been able to successfully sync files.
+
+on client B, inside .git/annex/daemon.log there's nothing interesting: just messages like:
+
+```(scanning...) [2014-06-03 14:53:26 CEST] Watcher: Performing startup scan
+
+Already up-to-date.```
+
+`git annex sync` just outputs
+
+`"commit  ok"`
+
+and `git annex list`:
+
+```
+here
+
+|berdario
+
+||soloud
+
+|||web
+
+||||box.com
+
+|||||
+
+XX__X IMG_20130202_100444.jpg
+
+XXX_X cookies.png
+
+XXX_X dancingllama.png
+
+XXX_X dario_bertini_cv.pdf
+
+XX__X steam_latest.deb
+```
+
+while this is what I get on client A:
+
+```
+here
+
+|berdario
+
+||web 
+
+|||box.com 
+
+||||
+
+XX_X IMG_20130202_100444.jpg
+
+X__X Russian Lesson 5 - Wikibooks, open books for an open world.html
+
+XX_X cookies.png
+
+XX_X dancingllama.png
+
+XX_X dario_bertini_cv.pdf
+
+XX_X steam_latest.deb
+```
+
+(they're just a bunch of random files I'm using to test it, both clients are called berdario, soloud is the home server (currently down) and the other working remote is box.com)
+
+As you can see the russian wikibooks html file is successfully synced with the remotes, but client B is unable to see it...
+
+I tried to set the remotes as incremental backup, full backup, transfer, client (!?) but none of these settings work.
+
+Is git annex not what I'm looking for? Is it supposed to work only on contemporarily connected clients?
+
+Thanks
diff --git a/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__/comment_1_a3fbae205c0312436f8861f432643811._comment b/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__/comment_1_a3fbae205c0312436f8861f432643811._comment
new file mode 100644
index 0000000000..a5baa31f3b
--- /dev/null
+++ b/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__/comment_1_a3fbae205c0312436f8861f432643811._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-06-04T18:21:13Z"
+ content="""
+your box.com repository only stores encrypted file contents, it does not include the git repository. So you need to either set up XMPP, which will allow the clients to sync while they're turned on, or you need to put a git repository on a remote server, which the clients can use to sync anytime.
+
+Recent versions of git-annex allow encrypting the git repository. Use the \"remote server\" option in the webapp UI to set it up.
+"""]]
diff --git a/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__/comment_2_de49cf261c644a6e7f6ac881a48d4e6c._comment b/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__/comment_2_de49cf261c644a6e7f6ac881a48d4e6c._comment
new file mode 100644
index 0000000000..552a6db2b6
--- /dev/null
+++ b/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__/comment_2_de49cf261c644a6e7f6ac881a48d4e6c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk0Sr9y7EcI5OhPk4GteZiHVxaoC0DmJ-E"
+ nickname="Dario"
+ subject="comment 2"
+ date="2014-06-05T09:10:40Z"
+ content="""
+I have set up XMPP already. I thought it was obvious, since otherwise you wouldn't even be able to share a remote with other clients (it would overwrite the contents)
+
+And the same problem happens with a remote server
+"""]]
diff --git a/doc/forum/Can_not_delete_Repository.mdwn b/doc/forum/Can_not_delete_Repository.mdwn
new file mode 100644
index 0000000000..549b47c3d3
--- /dev/null
+++ b/doc/forum/Can_not_delete_Repository.mdwn
@@ -0,0 +1,3 @@
+I have one repository that I deleted a while back. When I mark it as dead in command line it disappears from git annex info however when I run webapp it pops back webapp shows it as syncing disabled. When I try to delete it from the webapp it does not delete. I tried shutting down the daemon mark it as dead again then run git annex forget --drop-dead --force but running it makes the repo active again instead of deleting it.
+
+Repo in question was a S3 repo. I tried deleting it using both its name and uuid.
diff --git a/doc/forum/Can_not_delete_Repository/comment_1_b1a9420974e2e50c9c86a379ad62502c._comment b/doc/forum/Can_not_delete_Repository/comment_1_b1a9420974e2e50c9c86a379ad62502c._comment
new file mode 100644
index 0000000000..050127c24b
--- /dev/null
+++ b/doc/forum/Can_not_delete_Repository/comment_1_b1a9420974e2e50c9c86a379ad62502c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 1"
+ date="2014-02-21T17:36:03Z"
+ content="""
+Marking a repository as dead does not mean it is deleted. The way this is supposed to work, using the webapp is you tell it to start deleting the repository, which causes it to mark it as dead, and also, crucially, puts it into the \"unwanted\" group. This does not remove it from the list yet, but it causes all files located in the repository to be moved off it (assuming the repository can still be accessed).
+
+Then once the webapp detects that the repository is empty it will prompt you to continue the deletion process and truely remove it. It can take quite a while for the webapp to get around to this last step, since it's done during the expensive transfer scan, which it tries to avoid running unnecessarily.
+
+In any case, you can always edit .git/config and delete the remote, which should make the webapp no longer show it, as long as it's marked as dead.
+"""]]
diff --git a/doc/forum/Can_not_drop_unused_file.mdwn b/doc/forum/Can_not_drop_unused_file.mdwn
new file mode 100644
index 0000000000..8ec48eb14f
--- /dev/null
+++ b/doc/forum/Can_not_drop_unused_file.mdwn
@@ -0,0 +1,14 @@
+I have encrypted directory remote on a usb drive over time it accumulated some unused files. I would like to drop them running,
+
+    git annex --unused --from external
+
+returns a list of unused files when I try to drop them with,
+
+
+    git annex dropunused --force --from external 1-XX
+
+I get,
+
+    dropunused XX (from external...) failed
+
+I can not seem to get rid of these files.
diff --git a/doc/forum/Can_not_drop_unused_file/comment_1_cea83dfdf4cdb4f6efb3f2b33a39a51f._comment b/doc/forum/Can_not_drop_unused_file/comment_1_cea83dfdf4cdb4f6efb3f2b33a39a51f._comment
new file mode 100644
index 0000000000..4a6eacc510
--- /dev/null
+++ b/doc/forum/Can_not_drop_unused_file/comment_1_cea83dfdf4cdb4f6efb3f2b33a39a51f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.68"
+ subject="comment 1"
+ date="2014-01-18T22:39:37Z"
+ content="""
+One reason it might fail (especially if it's not printing any useful message beyond \"(failed)\") is if it thought the file was present in the repositort, but something has happened to it.
+
+So, I suggest you try:
+
+git annex fsck --from external
+
+Followed by dropping again.
+
+If that doesn't help, I'd recommend stracing the dropping of one of the unused files, and see what's going wrong toward the end.
+"""]]
diff --git a/doc/forum/Can_not_drop_unused_file/comment_2_ed1543cff5e6e81ca18c43b716ca8199._comment b/doc/forum/Can_not_drop_unused_file/comment_2_ed1543cff5e6e81ca18c43b716ca8199._comment
new file mode 100644
index 0000000000..321e107615
--- /dev/null
+++ b/doc/forum/Can_not_drop_unused_file/comment_2_ed1543cff5e6e81ca18c43b716ca8199._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 2"
+ date="2014-01-19T23:56:17Z"
+ content="""
+I've tried,
+
+    git annex fsck --from external
+
+and
+
+    git annex fsck --all --from external
+
+did not solve the problem. Running,
+
+    strace git annex dropunused 1 --from external --force
+
+tail of strace produces,
+
+    clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidp
+    tr=0x7f3a8d6d8a10) = 5746                                                            
+    rt_sigaction(SIGINT, {0x4e1fb0, [INT], SA_RESTORER|SA_RESTART, 0x7f3a8c8b60b0}, {SIG_D
+    FL, [], 0}, 8) = 0                                                                   
+    rt_sigaction(SIGHUP, {0x4e1fb0, [HUP], SA_RESTORER|SA_RESTART, 0x7f3a8c8b60b0}, {SIG_D
+    FL, [], 0}, 8) = 0                                                                   
+    rt_sigaction(SIGTERM, {0x4e1fb0, [TERM], SA_RESTORER|SA_RESTART, 0x7f3a8c8b60b0}, {SIG
+    _DFL, [], 0}, 8) = 0                                                                 
+    rt_sigaction(SIGQUIT, {0x4e1fb0, [QUIT], SA_RESTORER|SA_RESTART, 0x7f3a8c8b60b0}, {SIG
+    _DFL, [], 0}, 8) = 0                                                                 
+    rt_sigaction(SIGPIPE, {0x4e1fb0, [PIPE], SA_RESTORER|SA_RESTART, 0x7f3a8c8b60b0}, {SIG
+    _DFL, [], 0}, 8) = 0                                                                 
+    close(5)                                = 0
+    read(4, \"\", 1)                          = 0
+    close(4)                                = 0
+    wait4(5746, dropunused 1 (from external...) (gpg) failed
+    git-annex: dropunused: 1 failed
+    [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 5746
+    --- SIGCHLD (Child exited) @ 0 (0) ---
+    exit_group(1)                           = ?
+
+"""]]
diff --git a/doc/forum/Can_not_drop_unused_file/comment_3_0c9c9c0ed557af4845a67434c21bb4bc._comment b/doc/forum/Can_not_drop_unused_file/comment_3_0c9c9c0ed557af4845a67434c21bb4bc._comment
new file mode 100644
index 0000000000..8a1ecfdd24
--- /dev/null
+++ b/doc/forum/Can_not_drop_unused_file/comment_3_0c9c9c0ed557af4845a67434c21bb4bc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.68"
+ subject="comment 3"
+ date="2014-01-20T16:33:27Z"
+ content="""
+I see you're using encryption. That could have something to do with the problem. Which type of encryption was used for this special remote? encryption=shared or one of the other options?
+
+Look through the whole strace output for attempts to access the directory special remote and show those. Or put up the full strace somewhere.
+"""]]
diff --git a/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__.mdwn b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__.mdwn
new file mode 100644
index 0000000000..2f1491afd6
--- /dev/null
+++ b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__.mdwn
@@ -0,0 +1,6 @@
+I have some repositories where I want to manually control what files are added (autocommit=false), but would like to have the assistant/webapp automatically sync commits and transfer files.
+However it seems that the assistant is not notified if I manually do a commit.
+
+The only solution right now seems to frequently restart the assistant since the startup scan will transfer files if required or run git annex get/copy manually.
+
+Is there another possibility?
diff --git a/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_1_bc838634442883e541de1ceab520d71e._comment b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_1_bc838634442883e541de1ceab520d71e._comment
new file mode 100644
index 0000000000..fb0fbf40b1
--- /dev/null
+++ b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_1_bc838634442883e541de1ceab520d71e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-15T16:01:30Z"
+ content="""
+Right, the assistant doesn't have a way to get notified of your manual
+commits, so it doesn't promptly push them.
+
+While the assistant could be modified to watch git branch files for changes,
+I think that for most people wanting to make manual commits, running `git
+annex sync --content` is a better approach. It does all the same syncing
+that the assistant would.
+"""]]
diff --git a/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_2_676a8c3586d16afedff9e47d9ffd7431._comment b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_2_676a8c3586d16afedff9e47d9ffd7431._comment
new file mode 100644
index 0000000000..beb4010850
--- /dev/null
+++ b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_2_676a8c3586d16afedff9e47d9ffd7431._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="I've hacked an ugly daemon together for this"
+ date="2020-06-11T09:56:57Z"
+ content="""
+I've now written [a custom solution for myself which uses inotifywait to trigger `annex sync` when `master` or `synced/master` is updated](https://github.com/aspiers/pim/blob/master/bin/auto-sync-daemon).
+
+I'm running this on a mesh of remotes which all have the daemon running, so that a manual commit on any remote can be spotted and distributed throughout the network. 
+
+However from a synchronisation PoV, this is pretty ugly:
+
+- The remote where the manual commit is made spots the change to `master` and initiates an `annex sync` which updates at least `synced/master` on the other remotes, even if not `master` due to `receive.denyCurrentBranch` being set to `refuse`.
+- The daemons on the other remotes spot the changes to their `synced/master` and each initiate `annex sync`.
+- At this point a whole bunch of remotes are running `annex sync` at roughly the same time, and the window for weird race conditions is large.
+
+However even though the design is ugly, so far I haven't spotted any issues, which is presumably testament to the quality of the locking / synchronisation code within both `git` and `git-annex`.  Kudos!
+
+Of course I would prefer to ditch my custom hack and use the assistant, but that would require this feature to be added (as well as a solution to [[bugs/assistant_sometimes_removes_and_re-adds_whole_file]]).  I'd happily sponsor development of that but IIUC you aren't accepting sponsorship of individual features, so I'll live with my ugly hack for now until I get round to learning Haskell ;-)
+"""]]
diff --git a/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_3_e584a99e46f881358bf848131a94e293._comment b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_3_e584a99e46f881358bf848131a94e293._comment
new file mode 100644
index 0000000000..e0fa67fde9
--- /dev/null
+++ b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_3_e584a99e46f881358bf848131a94e293._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="I've moved my auto-sync-daemon script"
+ date="2020-07-09T14:24:48Z"
+ content="""
+The script mentioned above now lives [here](https://github.com/aspiers/git-config/blob/master/bin/auto-sync-daemon).
+"""]]
diff --git a/doc/forum/Can_we_have_remotes_that_aren__39__t_tracked__63___.mdwn b/doc/forum/Can_we_have_remotes_that_aren__39__t_tracked__63___.mdwn
new file mode 100644
index 0000000000..684893e84e
--- /dev/null
+++ b/doc/forum/Can_we_have_remotes_that_aren__39__t_tracked__63___.mdwn
@@ -0,0 +1,13 @@
+I'm wondering if it is possible to have remotes that don't have the *content* of git-annex tracked.
+
+# My use case:
+
+I have a number of projects that I am working on at any one time.  They all are tracking independently by `git` and more recently I am using `git annex` to manage the large files.
+
+However because I have so many projects I work on one (called `AAA`), move to another, delete `AAA` to save disk space, ...time passes... return to `AAA`.
+
+Now, prior to `git-annex` I could just clone `AAA` from my central repository folder do work, commit, push, repeat and then delete and there is no indication that I had one, or many copies of `AAA` floating around.  Now with `git-annex` there is some trail of me cloning, running `git annex get`, etc.
+
+Is there some way to set a remote as `untracked`?  By that I mean it is classed as `untrusted` - so I can move files around, add them, copy to trusted remotes and delete the whole repository without worrying about losing data - but it also doesn't push any of the git-annex tracking info of where a copy of a file actually is.  I don't want to know if any or all of my other `untracked` repositories have a copy of a file or not. 
+
+I don't want my `git annex whereis` polluted with many references to repositories that just don't exist any more.  I guess I could set them to dead but that still keeps all of the tracking info around in all the repos, which seems unnecessary...
diff --git a/doc/forum/Can_we_have_remotes_that_aren__39__t_tracked__63___/comment_1_35e5a963b9e58ed7773dfcb884f8ecbd._comment b/doc/forum/Can_we_have_remotes_that_aren__39__t_tracked__63___/comment_1_35e5a963b9e58ed7773dfcb884f8ecbd._comment
new file mode 100644
index 0000000000..955c256ca9
--- /dev/null
+++ b/doc/forum/Can_we_have_remotes_that_aren__39__t_tracked__63___/comment_1_35e5a963b9e58ed7773dfcb884f8ecbd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 1"
+ date="2013-08-07T16:27:21Z"
+ content="""
+This seems like a reasonable request, so I've opened [[todo/untracked_remotes]]
+
+I will note that if you know the annex.uuid of the previous AAA repository, you can make the new one use that same uuid, just `git config annex.uuid $UUID`. (`git annex fsck --fast` would be a good idea after doing that.)
+"""]]
diff --git a/doc/forum/Can_we_have_remotes_that_aren__39__t_tracked__63___/comment_2_7cde9785886c8450e1475f0b54481ae3._comment b/doc/forum/Can_we_have_remotes_that_aren__39__t_tracked__63___/comment_2_7cde9785886c8450e1475f0b54481ae3._comment
new file mode 100644
index 0000000000..92713db013
--- /dev/null
+++ b/doc/forum/Can_we_have_remotes_that_aren__39__t_tracked__63___/comment_2_7cde9785886c8450e1475f0b54481ae3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 2"
+ date="2014-01-02T17:26:35Z"
+ content="""
+I have now implemented a way to mark a remote as readonly. This prevents git-annex from pushing anything to the remote, or modifying it in other ways.
+
+It seems that in your use case, you might want to avoid git-annex sync pushing the git-annex branch, but still push a branch like master. So far, it's up to you to decide which branches to manually push; readonly disables all pushing.
+"""]]
diff --git a/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__.mdwn b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__.mdwn
new file mode 100644
index 0000000000..75b6cb0357
--- /dev/null
+++ b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__.mdwn
@@ -0,0 +1,7 @@
+I'd love to use git annex for my document archive, but my use case necessitates the archive to be stored encrypted while at rest. It also needs to be easily stored on a number of cloud storage providers.
+
+I usually use Cryptomator and gocryptfs - amongst others - to do this.
+
+I'd like to use git annex within one of those vaults, but it seems they are not compatible. With gocryptfs it shows me that the files `changed while being added` if I try to do a `git annex add .` on the folder. 
+
+Is this an issue caused by some fundamental architectural incompatibility between git annex and these kinds of encryption tools or is there something I can do?  
diff --git a/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_1_3e8c83a9d0a8dbb7a5a3fd25136cf0b4._comment b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_1_3e8c83a9d0a8dbb7a5a3fd25136cf0b4._comment
new file mode 100644
index 0000000000..54515d0408
--- /dev/null
+++ b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_1_3e8c83a9d0a8dbb7a5a3fd25136cf0b4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Have a look at mount options"
+ date="2023-02-13T08:32:24Z"
+ content="""
+I don't know gocryptfs but on the man page there is the `-ko` option for additional mount options. Maybe try things like `noatime` and the like? Or other options to gocryptfs? I had to massage a Samba mount quote a bit to be workable with git annex.
+"""]]
diff --git a/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_2_9a46e613745c8c80dedce6a3cd799e0b._comment b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_2_9a46e613745c8c80dedce6a3cd799e0b._comment
new file mode 100644
index 0000000000..e59da688ac
--- /dev/null
+++ b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_2_9a46e613745c8c80dedce6a3cd799e0b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-02-20T19:17:35Z"
+ content="""
+I wonder if gocryptfs does not have stable inode numbers?
+
+The "changed while it was being added" message happens if git-annex saw one
+inode number when it started adding the file, and a different one at the
+end.
+
+Changes to the mtime, device id, or file size will result in the same
+message.
+
+You might try running the `stat` command on a file before and after and
+see what changed.
+"""]]
diff --git a/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_3_de92ff891493737021cb264394a0a6bb._comment b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_3_de92ff891493737021cb264394a0a6bb._comment
new file mode 100644
index 0000000000..efbebb26f0
--- /dev/null
+++ b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_3_de92ff891493737021cb264394a0a6bb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="nadir"
+ avatar="http://cdn.libravatar.org/avatar/2af9174cf6c06de802104d632dc40071"
+ subject="comment 3"
+ date="2023-02-24T18:56:40Z"
+ content="""
+Sorry, didn't see you guys answered. 
+
+I've tried the \"noatime\" mount option, but no change. 
+
+I think joey might be on to something. As far as I understand [this github issue](https://github.com/rfjakob/gocryptfs/issues/606), there could be something to this.
+
+I guess the only remaining solution would be something like Veracrypt. What a pity.
+
+Thank you for your help.
+"""]]
diff --git a/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_4_2689a87a68dc459615d9542ad908b7a3._comment b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_4_2689a87a68dc459615d9542ad908b7a3._comment
new file mode 100644
index 0000000000..3100df7fd5
--- /dev/null
+++ b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_4_2689a87a68dc459615d9542ad908b7a3._comment
@@ -0,0 +1,75 @@
+[[!comment format=mdwn
+ username="dpifke"
+ avatar="http://cdn.libravatar.org/avatar/7b17ce0661a1b1cd708c5c5150eb2c33"
+ subject="comment 4"
+ date="2023-03-23T23:32:45Z"
+ content="""
+After successfully using git-annex + gocryptfs for several years now, I came across this issue because I also am no longer able to add files (\"... changed while it was being added\") after upgrading from bullseye to bookworm.
+
+The issue appears with gocryptfs 2.3.1+b3, but if I downgrade to gocryptfs 1.8.0-1+b6 it works again.
+
+It doesn't seem to be an inode number issue, but I do see the atime and ctime of the file change before and after running `git annex add`:
+
+```
+$ sha256sum Invoice.pdf 
+868cb65310f5ef46fcd4f7d85fb364347ea9047766cadcf3d184a8c704164b90  Invoice.pdf
+$ stat Invoice.pdf 
+  File: Invoice.pdf
+  Size: 54623           Blocks: 112        IO Block: 4096   regular file
+Device: bfh/191d        Inode: 294625      Links: 1
+Access: (0444/-r--r--r--)  Uid: ( 1000/    dave)   Gid: ( 1000/    dave)
+Access: 2023-03-23 17:19:59.707965391 -0600
+Modify: 2023-03-23 17:19:56.731965402 -0600
+Change: 2023-03-23 17:19:56.731965402 -0600
+ Birth: -
+$ git annex --debug add Invoice.pdf 
+[2023-03-23 17:20:23.680446749] (Utility.Process) process [2900635] read: git [\"--git-dir=../../.git\",\"--work-tree=../..\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"show-ref\",\"git-annex\"]
+[2023-03-23 17:20:23.684813572] (Utility.Process) process [2900635] done ExitSuccess
+[2023-03-23 17:20:23.684979722] (Utility.Process) process [2900637] read: git [\"--git-dir=../../.git\",\"--work-tree=../..\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2023-03-23 17:20:23.688066503] (Utility.Process) process [2900637] done ExitSuccess
+[2023-03-23 17:20:23.688331712] (Utility.Process) process [2900638] read: git [\"--git-dir=../../.git\",\"--work-tree=../..\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"log\",\"refs/heads/git-annex..3b3eebc02f68101a6e2aeecc1733f2c214847361\",\"--pretty=%H\",\"-n1\"]
+[2023-03-23 17:20:23.690117996] (Utility.Process) process [2900638] done ExitSuccess
+[2023-03-23 17:20:23.690338783] (Utility.Process) process [2900639] read: git [\"--git-dir=../../.git\",\"--work-tree=../..\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"log\",\"refs/heads/git-annex..60c9383872bd6750ab3d91730de902e2aa330d54\",\"--pretty=%H\",\"-n1\"]
+[2023-03-23 17:20:23.692089872] (Utility.Process) process [2900639] done ExitSuccess
+[2023-03-23 17:20:23.692439951] (Utility.Process) process [2900640] chat: git [\"--git-dir=../../.git\",\"--work-tree=../..\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch\"]
+[2023-03-23 17:20:23.694521134] (Utility.Process) process [2900641] read: git [\"--git-dir=../../.git\",\"--work-tree=../..\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2023-03-23 17:20:23.695417786] (Utility.Process) process [2900641] done ExitSuccess
+[2023-03-23 17:20:23.695579032] (Utility.Process) process [2900642] read: git [\"--git-dir=../../.git\",\"--work-tree=../..\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"show-ref\",\"refs/heads/master\"]
+[2023-03-23 17:20:23.697616186] (Utility.Process) process [2900642] done ExitSuccess
+[2023-03-23 17:20:23.69780391] (Utility.Process) process [2900643] read: git [\"--git-dir=../../.git\",\"--work-tree=../..\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"ls-files\",\"-z\",\"--others\",\"--exclude-standard\",\"--\",\"Invoice.pdf\"]
+[2023-03-23 17:20:23.699829084] (Utility.Process) process [2900644] chat: git [\"--git-dir=../../.git\",\"--work-tree=../..\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.largefiles\",\"annex.numcopies\",\"annex.mincopies\",\"--\"]
+[2023-03-23 17:20:23.701005154] (Utility.Process) process [2900645] chat: git [\"--git-dir=../../.git\",\"--work-tree=../..\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+add Invoice.pdf [2023-03-23 17:20:23.703386207] (Annex.Perms) freezing content Invoice.pdf
+
+                                  
+  Invoice.pdf changed while it was being added
+failed                            
+[2023-03-23 17:20:23.704163913] (Utility.Process) process [2900643] done ExitSuccess
+[2023-03-23 17:20:23.704269644] (Utility.Process) process [2900646] read: git [\"--git-dir=../../.git\",\"--work-tree=../..\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"ls-files\",\"-z\",\"--modified\",\"--\",\"Invoice.pdf\"]
+[2023-03-23 17:20:23.706229644] (Utility.Process) process [2900646] done ExitSuccess
+[2023-03-23 17:20:23.706353485] (Utility.Process) process [2900647] read: git [\"--git-dir=../../.git\",\"--work-tree=../..\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"diff\",\"--name-only\",\"--diff-filter=T\",\"-z\",\"--cached\",\"--\",\"Invoice.pdf\"]
+[2023-03-23 17:20:23.708586251] (Utility.Process) process [2900647] done ExitSuccess
+[2023-03-23 17:20:23.709078263] (Utility.Process) process [2900640] done ExitSuccess
+[2023-03-23 17:20:23.709198563] (Utility.Process) process [2900645] done ExitSuccess
+[2023-03-23 17:20:23.709484216] (Utility.Process) process [2900644] done ExitSuccess
+add: 1 failed
+$ stat Invoice.pdf 
+  File: Invoice.pdf
+  Size: 54623           Blocks: 112        IO Block: 4096   regular file
+Device: bfh/191d        Inode: 294625      Links: 1
+Access: (0444/-r--r--r--)  Uid: ( 1000/    dave)   Gid: ( 1000/    dave)
+Access: 2023-03-23 17:20:23.699965299 -0600
+Modify: 2023-03-23 17:19:56.731965402 -0600
+Change: 2023-03-23 17:20:23.699965299 -0600
+ Birth: -
+$ sha256sum Invoice.pdf 
+868cb65310f5ef46fcd4f7d85fb364347ea9047766cadcf3d184a8c704164b90  Invoice.pdf
+```
+
+The filesystem was mounted as `/home/dave/.encrypted/Finances on /home/dave/Finances type fuse.gocryptfs (rw,nosuid,nodev,noatime,user_id=1000,group_id=1000,max_read=131072)`.
+
+This is with git-annex 10.20230126-2.
+
+I am happy to debug further if someone wants to point me in a useful direction.
+
+"""]]
diff --git a/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_5_a1f8d718be941f4dd5e7b06fd6431c10._comment b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_5_a1f8d718be941f4dd5e7b06fd6431c10._comment
new file mode 100644
index 0000000000..a82ac5e3f6
--- /dev/null
+++ b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_5_a1f8d718be941f4dd5e7b06fd6431c10._comment
@@ -0,0 +1,73 @@
+[[!comment format=mdwn
+ username="dpifke"
+ avatar="http://cdn.libravatar.org/avatar/7b17ce0661a1b1cd708c5c5150eb2c33"
+ subject="comment 5"
+ date="2023-03-23T23:43:17Z"
+ content="""
+Some additional experiments:
+
+```
+$ stat Invoice.pdf 
+  File: Invoice.pdf
+  Size: 54623           Blocks: 112        IO Block: 4096   regular file
+Device: bfh/191d        Inode: 294625      Links: 1
+Access: (0444/-r--r--r--)  Uid: ( 1000/    dave)   Gid: ( 1000/    dave)
+Access: 2023-03-23 17:28:30.299963443 -0600
+Modify: 2023-03-23 17:19:56.731965402 -0600
+Change: 2023-03-23 17:28:30.299963443 -0600
+ Birth: -
+$ sha256sum Invoice.pdf 
+868cb65310f5ef46fcd4f7d85fb364347ea9047766cadcf3d184a8c704164b90  Invoice.pdf
+$ stat Invoice.pdf 
+  File: Invoice.pdf
+  Size: 54623           Blocks: 112        IO Block: 4096   regular file
+Device: bfh/191d        Inode: 294625      Links: 1
+Access: (0444/-r--r--r--)  Uid: ( 1000/    dave)   Gid: ( 1000/    dave)
+Access: 2023-03-23 17:35:38.303961810 -0600
+Modify: 2023-03-23 17:19:56.731965402 -0600
+Change: 2023-03-23 17:28:30.299963443 -0600
+ Birth: -
+```
+
+From the above, I can see that `-ko noatime` doesn't do anything, but the ctime change is something unique to git-annex, not just from opening and reading file contents.  (I've used git-annex on filesystems without noatime before, so I didn't think noatime support was mandatory?)
+
+But wait... why is the file 0444?
+
+```
+$ chmod 644 Invoice.pdf 
+$ stat Invoice.pdf 
+  File: Invoice.pdf
+  Size: 54623           Blocks: 112        IO Block: 4096   regular file
+Device: bfh/191d        Inode: 294625      Links: 1
+Access: (0644/-rw-r--r--)  Uid: ( 1000/    dave)   Gid: ( 1000/    dave)
+Access: 2023-03-23 17:35:38.303961810 -0600
+Modify: 2023-03-23 17:19:56.731965402 -0600
+Change: 2023-03-23 17:38:04.539961252 -0600
+ Birth: -
+```
+
+OK, so setting it back to 0644 modifies ctime.
+
+```
+$ git annex add Invoice.pdf 
+add Invoice.pdf 
+                                  
+  Invoice.pdf changed while it was being added
+failed                            
+add: 1 failed
+$ stat Invoice.pdf 
+  File: Invoice.pdf
+  Size: 54623           Blocks: 112        IO Block: 4096   regular file
+Device: bfh/191d        Inode: 294625      Links: 1
+Access: (0444/-r--r--r--)  Uid: ( 1000/    dave)   Gid: ( 1000/    dave)
+Access: 2023-03-23 17:38:28.999961159 -0600
+Modify: 2023-03-23 17:19:56.731965402 -0600
+Change: 2023-03-23 17:38:28.999961159 -0600
+ Birth: -
+```
+
+And running `git annex add` changes it back to 0444, *and* updates ctime.  So that's why that change is being observed.
+
+So I don't think gocryptfs is doing anything unexpected w.r.t. modifying the file out from under git-annex.  Is there a way to get more detailed information about what git-annex thinks has changed?
+
+"""]]
diff --git a/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_7_375b8234fc79d75f3cb39004cbe4d9e3._comment b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_7_375b8234fc79d75f3cb39004cbe4d9e3._comment
new file mode 100644
index 0000000000..c471d3286b
--- /dev/null
+++ b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_7_375b8234fc79d75f3cb39004cbe4d9e3._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2023-03-28T17:19:46Z"
+ content="""
+This is a filesystem bug. I reported it here:
+<https://github.com/rfjakob/gocryptfs/issues/724>
+
+`git-annex add` makes a hard link to the file and then stats the hard link
+before and after hashing. Due to this filesystem bug, it gets a different
+size.
+
+One workaround is:
+
+	git config annex.crippledfilesystem true
+
+Although setting annex.crippledfilesystem has other effects, including
+git-annex not locking down permissions of annexed files. So I don't know if
+I'd really recommend that workaround.
+
+It would be possible for git-annex to work around this by statting the file
+before making the hard link, rather than statting the hardlink after
+creation. But I don't think I want to work around filesystem breakage like
+that.
+"""]]
diff --git a/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_7_ff7f26601e375146a08b454a2e448f1b._comment b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_7_ff7f26601e375146a08b454a2e448f1b._comment
new file mode 100644
index 0000000000..2926820d3e
--- /dev/null
+++ b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_7_ff7f26601e375146a08b454a2e448f1b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="dpifke"
+ avatar="http://cdn.libravatar.org/avatar/7b17ce0661a1b1cd708c5c5150eb2c33"
+ subject="comment 7"
+ date="2023-03-29T03:13:50Z"
+ content="""
+Thanks for tracking this down, and for the pointer to the `annex.crippledfilesystem` option.  I agree the latter sounds sub-optimal but I'll keep it in mind if staying on the 1.8 release becomes untenable before the Gocryptfs bug is fixed.  I'll follow the linked Github issue for updates on that.
+
+"""]]
diff --git a/doc/forum/Cannot_find_git-annex_in_server.mdwn b/doc/forum/Cannot_find_git-annex_in_server.mdwn
new file mode 100644
index 0000000000..6208c288e5
--- /dev/null
+++ b/doc/forum/Cannot_find_git-annex_in_server.mdwn
@@ -0,0 +1,10 @@
+My server is running the precompiled tarball https://downloads.kitenet.net/git-annex/linux/current/
+
+git-annex version: 4.20130531-g5df09b5
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+
+The tarball is untared in "/opt/git-annex.linux" and this location is added to the users path in ".profile", who can launch the webapp as usual and so on.
+
+But when a git-annex client from another computer tries to stablish a remote server repository with the server via ssh, it will complain "/usr/bin/git-annex", "runshell" and so on are missing. And if the binaries in "/opt/git-annex.linux" are symlinked in "/usr/bin" they will start to miss the other bin and libs in the "/opt/git-annex.linux" source tree.
+
+As you can understand, I can't put the whole "/opt/git-annex.linux" folder tree in "/usr/bin". Is there any solution to make the precompiled tarball work properly as a git-annex server?
diff --git a/doc/forum/Cannot_find_git-annex_in_server/comment_1_bf7e98e6130698ad0dc92e3a6a63ade3._comment b/doc/forum/Cannot_find_git-annex_in_server/comment_1_bf7e98e6130698ad0dc92e3a6a63ade3._comment
new file mode 100644
index 0000000000..b5685c901c
--- /dev/null
+++ b/doc/forum/Cannot_find_git-annex_in_server/comment_1_bf7e98e6130698ad0dc92e3a6a63ade3._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-06-20T15:23:32Z"
+ content="""
+The standalone tarball does not need to be installed in /usr/bin or any other particular location. I *never* hardcode /usr/bin in anything.
+
+It seems likely to me that you have not correctly added /opt/git-annex.linux to PATH. You mention `.profile` -- but this is only used
+by bash when starting a login shell. So any non-login shells won't have it in path. You need to put something in .bashrc for that.
+
+Also, to use git-annex on a server, there is no reason at all to install the latest and greatest version. Any version 3 or greater build of git-annex will work fine on a server with newer git-annex versions on clients. So `apt-get install git-annex` is a much easier and nicer way to install it on a server. Most linux distributions have a package of git-annex and an easy way to install it.
+
+(It would also help if you pasted actual error messages, rather than a summary of an error message.)
+"""]]
diff --git a/doc/forum/Cannot_find_git-annex_in_server/comment_2_168dda4aed09f90a510bc453e8a7cda7._comment b/doc/forum/Cannot_find_git-annex_in_server/comment_2_168dda4aed09f90a510bc453e8a7cda7._comment
new file mode 100644
index 0000000000..48c0a65aff
--- /dev/null
+++ b/doc/forum/Cannot_find_git-annex_in_server/comment_2_168dda4aed09f90a510bc453e8a7cda7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmCEE7m7pm6lqvYmgRSESRP9xqmmMm9ox8"
+ nickname="Daniel"
+ subject="comment 2"
+ date="2013-06-20T20:14:25Z"
+ content="""
+I'd rather use the package from the repositories. But this server is running an openSUSE install and the package manager could not resolve the Haskell dependencies of the unofficial git-annex rpm package.
+
+Indeed, performing the PATH extension in \".bashrc\", not in \".profile\", solved the issue. I feel like a newbie. Thanks for the express answer!
+"""]]
diff --git a/doc/forum/Cannot_get_file_from_special_remote.mdwn b/doc/forum/Cannot_get_file_from_special_remote.mdwn
new file mode 100644
index 0000000000..eb1b6c74e3
--- /dev/null
+++ b/doc/forum/Cannot_get_file_from_special_remote.mdwn
@@ -0,0 +1,62 @@
+Hello,
+
+I have an enabled special remote called StorageBox:
+
+```
+% git annex whereis esp\ 07.odt             
+whereis esp 07.odt (3 copies) 
+        00638e8a-ce29-4c41-b0df-e38bbbea303c -- [StorageBox]
+        2f41eb74-5f33-4737-bb6b-1cd31dd67ee5 -- External
+        8aca09c1-30bb-4c2a-9ea4-94a7096fc8b0 -- Horus [horus]
+ok
+```
+
+but getting the file fails:
+
+```
+% git annex get esp\ 07.odt --from StorageBox
+get esp 07.odt (from StorageBox...) 
+failed
+git-annex: get: 1 failed
+```
+
+with `--debug`
+
+```
+% git annex --debug get esp\ 07.odt --from StorageBox
+[2019-08-07 10:19:16.795808079] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","show-ref","git-annex"]
+[2019-08-07 10:19:16.798356234] process done ExitSuccess
+[2019-08-07 10:19:16.798450913] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2019-08-07 10:19:16.800783647] process done ExitSuccess
+[2019-08-07 10:19:16.80113337] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","log","refs/heads/git-annex..a41476d65829e7e2bc2c7abb8bc5dbc54690bce2","--pretty=%H","-n1"]
+[2019-08-07 10:19:16.803608041] process done ExitSuccess
+[2019-08-07 10:19:16.803697638] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","log","refs/heads/git-annex..156c3e15a2aad0b1207c1574609044170312ea9f","--pretty=%H","-n1"]
+[2019-08-07 10:19:16.806435853] process done ExitSuccess
+[2019-08-07 10:19:16.806527203] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","log","refs/heads/git-annex..ea4446ee38012a32e58a041ccb538135c3e942be","--pretty=%H","-n1"]
+[2019-08-07 10:19:16.809451267] process done ExitSuccess
+[2019-08-07 10:19:16.809558251] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","log","refs/heads/git-annex..4f376a557a384044ef4b7ca481e9ca4c724cf13d","--pretty=%H","-n1"]
+[2019-08-07 10:19:16.811953178] process done ExitSuccess
+[2019-08-07 10:19:16.816776692] chat: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","cat-file","--batch"]
+[2019-08-07 10:19:16.817315416] chat: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2019-08-07 10:19:16.821800692] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2019-08-07 10:19:16.823817987] process done ExitSuccess
+[2019-08-07 10:19:16.823920732] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","show-ref","refs/heads/master"]
+[2019-08-07 10:19:16.826402914] process done ExitSuccess
+[2019-08-07 10:19:16.82657316] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","ls-files","--cached","-z","--","esp 07.odt"]
+get esp 07.odt (from StorageBox...) [2019-08-07 10:19:16.835457997] chat: gpg ["--quiet","--trust-model","always","--decrypt"]
+[2019-08-07 10:19:16.983557153] process done ExitSuccess
+
+[2019-08-07 10:19:17.006493687] retrieve 065/2b5/GPGHMACSHA1--ae77770aef3b651d6fd0da47386891e23015809b/GPGHMACSHA1--ae77770aef3b651d6fd0da47386891e23015809b
+[2019-08-07 10:19:17.32316296] retrieve d8f/3a4/GPGHMACSHA1--ab824710fe31cc23b667dff462af11739d4e116d/GPGHMACSHA1--ab824710fe31cc23b667dff462af11739d4e116d
+failed
+[2019-08-07 10:19:17.338120828] process done ExitSuccess
+[2019-08-07 10:19:17.338792003] process done ExitSuccess
+git-annex: get: 1 failed
+```
+
+The testing when I did `enableremote` was successful.
+
+What can be the reason for that failure?
+
+Thanks,
+Florian
diff --git a/doc/forum/Cannot_get_file_from_special_remote/comment_1_7fd5cebf26042ff0de30746bf8a6adcf._comment b/doc/forum/Cannot_get_file_from_special_remote/comment_1_7fd5cebf26042ff0de30746bf8a6adcf._comment
new file mode 100644
index 0000000000..ba19add12e
--- /dev/null
+++ b/doc/forum/Cannot_get_file_from_special_remote/comment_1_7fd5cebf26042ff0de30746bf8a6adcf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Horus"
+ avatar="http://cdn.libravatar.org/avatar/8f0ee08b98ea5bba76c3fe112c08851c"
+ subject="comment 1"
+ date="2019-08-09T07:51:07Z"
+ content="""
+I have fixed doing an fsck on that special remote and re-uploading the files. Still, I am puzzled how that could have happened...
+"""]]
diff --git a/doc/forum/Cannot_get_file_from_special_remote/comment_2_bbb832f022d23b1f020d07f3fe99577f._comment b/doc/forum/Cannot_get_file_from_special_remote/comment_2_bbb832f022d23b1f020d07f3fe99577f._comment
new file mode 100644
index 0000000000..0fea4911cd
--- /dev/null
+++ b/doc/forum/Cannot_get_file_from_special_remote/comment_2_bbb832f022d23b1f020d07f3fe99577f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-08-09T19:38:36Z"
+ content="""
+What does `git annex info StorageBox` say about it?
+"""]]
diff --git a/doc/forum/Cannot_get_file_from_special_remote/comment_3_81a6054bc3b64f1325f4d85979f2b12a._comment b/doc/forum/Cannot_get_file_from_special_remote/comment_3_81a6054bc3b64f1325f4d85979f2b12a._comment
new file mode 100644
index 0000000000..c067ce7b1d
--- /dev/null
+++ b/doc/forum/Cannot_get_file_from_special_remote/comment_3_81a6054bc3b64f1325f4d85979f2b12a._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="Horus"
+ avatar="http://cdn.libravatar.org/avatar/8f0ee08b98ea5bba76c3fe112c08851c"
+ subject="comment 3"
+ date="2019-08-12T07:40:57Z"
+ content="""
+It gives me:
+
+```
+% git annex info StorageBox
+uuid: 00638e8a-ce29-4c41-b0df-e38bbbea303c
+description: [StorageBox]
+remote: StorageBox
+trust: semitrusted
+cost: 250.0
+type: webdav
+creds: embedded in git repository (gpg encrypted)
+url: https://xyz.your-storagebox.de/annex/Documents
+encryption: hybrid (to gpg keys: 4F4FB5E450C86B8F)
+chunking: 10 megabyteschunks
+remote annex keys: 9629
+remote annex size: 44.27 gigabytes
+```
+"""]]
diff --git a/doc/forum/Cannot_get_file_from_special_remote/comment_4_6e7252449b3eb9ca5d45b5c3889cacd4._comment b/doc/forum/Cannot_get_file_from_special_remote/comment_4_6e7252449b3eb9ca5d45b5c3889cacd4._comment
new file mode 100644
index 0000000000..0568862566
--- /dev/null
+++ b/doc/forum/Cannot_get_file_from_special_remote/comment_4_6e7252449b3eb9ca5d45b5c3889cacd4._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-09-10T18:36:06Z"
+ content="""
+It seems that the file stored in the remote must have either been deleted
+by something, or possibly gotten corrupted. But probably deleted I think,
+because a corrupted file would have a different error message.
+
+Lot of possible ways a file could get deleted. Perhaps StorageBox is
+storing the files as file on the filesystem, and had a disk problem that
+caused fsck to move the file to lost+found. Could happen, disks fail.
+
+Another way would be, if you had made a clone of your git-annex repository,
+and enabled StorageBox in there, and done a `git annex move --from
+StorageBox`. Then the clone would know it had the copy and StorageBox no
+longer did, but until that clone's git-annex branch is pushed out to other
+repositories, they will think StorageBox still has the copy, and fail like
+you showed.
+
+git-annex fsck exists because of these kinds of situations, and gets things
+back to a correct state. But it makes sense to investigate what happened.
+"""]]
diff --git a/doc/forum/Cannot_get_file_with_git-annex.mdwn b/doc/forum/Cannot_get_file_with_git-annex.mdwn
new file mode 100644
index 0000000000..f2419ef83e
--- /dev/null
+++ b/doc/forum/Cannot_get_file_with_git-annex.mdwn
@@ -0,0 +1,95 @@
+I recently noticed that a file I thought I had on one of my repositories was missing, so I decided to get it:
+
+
+	chymera@clusterhost ~/ni_data/ofM.dr $ git annex get 20151226_112356_4012_1_7/2/pulseprogram 
+	get 20151226_112356_4012_1_7/2/pulseprogram (from data0...) 
+	git-annex-shell: failed to read git config of git repository in zenhost on /run/media/chymera/data0/ni_data; perhaps this repository is not set up correctly or has moved
+	rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
+	rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.3]
+
+	  rsync failed -- run git annex again to resume file transfer
+	(from data1...) 
+	git-annex-shell: failed to read git config of git repository in zenhost on /run/media/chymera/data1/ni_data; perhaps this repository is not set up correctly or has moved
+	rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
+	rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.3]
+
+	  rsync failed -- run git annex again to resume file transfer
+	(from quiethost...) 
+	ssh: connect to host localhost port 2225: Connection refused
+	rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
+	rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.3]
+
+	  rsync failed -- run git annex again to resume file transfer
+	(from zenhost...) 
+	SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624
+			 32,243 100%    7.69MB/s    0:00:00 (xfr#1, to-chk=0/1)
+	(checksum...) ok
+	(recording state in git...)
+
+
+	chymera@clusterhost ~/ni_data/ofM.dr $ ls -lah 20151226_112356_4012_1_7/2/pdata/1/
+	total 468K
+	drwxr-sr-x 2 chymera wheel 4.0K Nov  2  2017 .
+	drwxr-sr-x 3 chymera wheel 4.0K Mar 20  2017 ..
+	-rw-r-Sr-- 1 chymera wheel 422K Mar 20  2017 2dseq
+	-rw-r-Sr-- 1 chymera wheel  356 Mar 20  2017 id
+	-rw-r-Sr-- 1 chymera wheel  420 Mar 20  2017 methreco
+	-rw-r-Sr-- 1 chymera wheel  349 Mar 20  2017 procs
+	-rw-r-Sr-- 1 chymera wheel 9.1K Mar 20  2017 reco
+	-rw-r-Sr-- 1 chymera wheel 8.3K Nov  2  2017 visu_pars
+
+
+	chymera@clusterhost ~/ni_data/ofM.dr $ ls -lah 20151226_112356_4012_1_7/2/pulseprogram 
+	lrwxrwxrwx 1 chymera wheel 195 Dec 25 22:01 20151226_112356_4012_1_7/2/pulseprogram -> ../../../.git/annex/objects/vz/WW/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624
+	chymera@clusterhost ~/ni_data/ofM.dr $ git annex get 20151226_112356_4012_1_7/2/pulseprogram 
+	chymera@clusterhost ~/ni_data/ofM.dr $ ls -lah 20151226_112356_4012_1_7/2/pdata/1/^C
+	chymera@clusterhost ~/ni_data/ofM.dr $ git annex direct
+	chymera@clusterhost ~/ni_data/ofM.dr $ git annex get 20151226_112356_4012_1_7/2/pulseprogram 
+	chymera@clusterhost ~/ni_data/ofM.dr $ ls -lah 20151226_112356_4012_1_7/2/pulseprogram 
+	lrwxrwxrwx 1 chymera wheel 195 Dec 25 22:01 20151226_112356_4012_1_7/2/pulseprogram -> ../../../.git/annex/objects/vz/WW/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624
+
+
+	chymera@clusterhost ~/ni_data/ofM.dr $ git annex drop 20151226_112356_4012_1_7/2/pulseprogram 
+	drop 20151226_112356_4012_1_7/2/pulseprogram (locking data0...) (lockcontent failed) (checking data0...) git-annex-shell: failed to read git config of git repository in zenhost on /run/media/chymera/data0/ni_data; perhaps this repository is not set up correctly or has moved
+	(locking data1...) (lockcontent failed) (checking data1...) git-annex-shell: failed to read git config of git repository in zenhost on /run/media/chymera/data1/ni_data; perhaps this repository is not set up correctly or has moved
+	(locking quiethost...) (lockcontent failed) (checking quiethost...) ssh: connect to host localhost port 2225: Connection refused
+	(locking zenhost...) ok
+	(recording state in git...)
+
+
+	chymera@clusterhost ~/ni_data/ofM.dr $ git annex get 20151226_112356_4012_1_7/2/pulseprogram 
+	get 20151226_112356_4012_1_7/2/pulseprogram (from data0...) 
+	git-annex-shell: failed to read git config of git repository in zenhost on /run/media/chymera/data0/ni_data; perhaps this repository is not set up correctly or has moved
+	rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
+	rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.3]
+
+	  rsync failed -- run git annex again to resume file transfer
+	(from data1...) 
+	git-annex-shell: failed to read git config of git repository in zenhost on /run/media/chymera/data1/ni_data; perhaps this repository is not set up correctly or has moved
+	rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
+	rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.3]
+
+	  rsync failed -- run git annex again to resume file transfer
+	(from quiethost...) 
+	ssh: connect to host localhost port 2225: Connection refused
+	rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
+	rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.3]
+
+	  rsync failed -- run git annex again to resume file transfer
+	(from zenhost...) 
+	SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624
+			 32,243 100%   30.75MB/s    0:00:00 (xfr#1, to-chk=0/1)
+	(checksum...) ok
+	(recording state in git...)
+
+	chymera@clusterhost ~/ni_data/ofM.dr $ ls -lah 20151226_112356_4012_1_7/2/pulseprogram 
+	lrwxrwxrwx 1 chymera wheel 195 Dec 25 22:01 20151226_112356_4012_1_7/2/pulseprogram -> ../../../.git/annex/objects/vz/WW/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624
+
+Even after git-annex states it fetched it, the symlink is still broken.
+
+On my other remote, however, it's perfectly fine:
+
+	chymera@zenhost ~/ni_data/ofM.dr $  ls -lah 20151226_112356_4012_1_7/2/pulseprogram
+	lrwxrwxrwx 1 chymera wheel 195 May 23  2018 20151226_112356_4012_1_7/2/pulseprogram -> ../../../.git/annex/objects/vz/WW/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624
+
+
diff --git a/doc/forum/Cannot_get_file_with_git-annex/comment_1_d16cff700d5899c56011f66b655ad9ff._comment b/doc/forum/Cannot_get_file_with_git-annex/comment_1_d16cff700d5899c56011f66b655ad9ff._comment
new file mode 100644
index 0000000000..9272064275
--- /dev/null
+++ b/doc/forum/Cannot_get_file_with_git-annex/comment_1_d16cff700d5899c56011f66b655ad9ff._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="Chymera"
+ avatar="http://cdn.libravatar.org/avatar/555d585d6d78c68894ac90fd1e984309"
+ subject="comment 1"
+ date="2019-01-04T21:08:54Z"
+ content="""
+Interestingly stat claims the target file is missing in both repos:
+
+    chymera@clusterhost ~/ni_data/ofM.dr $ stat .git/annex/objects/vz/WW/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624
+    stat: cannot stat '.git/annex/objects/vz/WW/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624': No such file or directory
+
+    chymera@zenhost ~/ni_data/ofM.dr $ stat .git/annex/objects/vz/WW/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624
+    stat: cannot stat '.git/annex/objects/vz/WW/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624/SHA256E-s32243--feae20d26c487947f9ad30019459464ba5a206a4ae6149a9d10fa4100c64f624': No such file or directory
+
+
+But the tail command works on the file on one of the repos:
+
+
+    chymera@clusterhost ~/ni_data/ofM.dr $ tail -10 20151226_112356_4012_1_7/2/pulseprogram 
+    tail: cannot open '20151226_112356_4012_1_7/2/pulseprogram' for reading: No such file or directory
+
+
+    chymera@zenhost ~/ni_data/ofM.dr $ tail -10 20151226_112356_4012_1_7/2/pulseprogram
+    exit
+    # 147 \"/opt/PV6.0/exp/stan/nmr/lists/pp/FLASHAngio.ppg\"
+    ph0 = 0
+    ph1 = 0 
+
+
+    # 153 \"/opt/PV6.0/exp/stan/nmr/lists/pp/FLASHAngio.ppg\"
+
+
+"""]]
diff --git a/doc/forum/Cannot_get_file_with_git-annex/comment_2_50c375c6af20b38dec08eff10113dee2._comment b/doc/forum/Cannot_get_file_with_git-annex/comment_2_50c375c6af20b38dec08eff10113dee2._comment
new file mode 100644
index 0000000000..4de5c09a66
--- /dev/null
+++ b/doc/forum/Cannot_get_file_with_git-annex/comment_2_50c375c6af20b38dec08eff10113dee2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Chymera"
+ avatar="http://cdn.libravatar.org/avatar/555d585d6d78c68894ac90fd1e984309"
+ subject="comment 2"
+ date="2019-01-04T23:05:43Z"
+ content="""
+turns out I need to do `git annex inidrect` and then `git annex direct` for my files to be detected, this software is really strange
+"""]]
diff --git a/doc/forum/Cannot_get_unlocked_file_contents.mdwn b/doc/forum/Cannot_get_unlocked_file_contents.mdwn
new file mode 100644
index 0000000000..769c61189b
--- /dev/null
+++ b/doc/forum/Cannot_get_unlocked_file_contents.mdwn
@@ -0,0 +1,8 @@
+So I have an unlocked file which I "--content synced" from my machine 'X03' to my bare-repository remote 'origin'. 
+I edited the same file on another machine 'X02' before syncing, realised that, hit undo and synced with content.
+
+Now the file contains only a "hash-link" as if it was an unlocked file which I did not 'get'. 
+I am afraid that I somehow committed that change, i.e., changing the file content to a single line containing the "hash-link", and deleted the actual file contents. Currently I have no access to 'X03'. 
+
+Is there a way to check out an older version or fix this altogether? 
+I assume the real file contents should still be in 'origin'?
diff --git a/doc/forum/Cannot_get_unlocked_file_contents/comment_1_1905d2a9ae0142838f42aff4efd5c643._comment b/doc/forum/Cannot_get_unlocked_file_contents/comment_1_1905d2a9ae0142838f42aff4efd5c643._comment
new file mode 100644
index 0000000000..f4e50decc8
--- /dev/null
+++ b/doc/forum/Cannot_get_unlocked_file_contents/comment_1_1905d2a9ae0142838f42aff4efd5c643._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2020-10-11T14:01:35Z"
+ content="""
+First, you should try \"git annex get\" on that file and see if works. If it simply outputs nothing, then you indeed somehow committed a hash link. Use \"git log --stat\" and look for the commit that changed the file, then copy the commit-id of the commit before that. Then you can get the old version of the file with \"git checkout <commit-id> -- <file>\".
+"""]]
diff --git a/doc/forum/Cannot_get_unlocked_file_contents/comment_2_496503ae9878d402261910e2dd9bc385._comment b/doc/forum/Cannot_get_unlocked_file_contents/comment_2_496503ae9878d402261910e2dd9bc385._comment
new file mode 100644
index 0000000000..9562d811fe
--- /dev/null
+++ b/doc/forum/Cannot_get_unlocked_file_contents/comment_2_496503ae9878d402261910e2dd9bc385._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-10-12T18:56:49Z"
+ content="""
+It's completely normal for an unlocked file whose content is not locally
+present to have an annex hash as its content. That is what gets
+committed to git normally.
+"""]]
diff --git a/doc/forum/Cannot_get_unlocked_file_contents/comment_3_57ee489f24b26b73b28f64566e2b8ff5._comment b/doc/forum/Cannot_get_unlocked_file_contents/comment_3_57ee489f24b26b73b28f64566e2b8ff5._comment
new file mode 100644
index 0000000000..b48377726d
--- /dev/null
+++ b/doc/forum/Cannot_get_unlocked_file_contents/comment_3_57ee489f24b26b73b28f64566e2b8ff5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Maximilian"
+ avatar="http://cdn.libravatar.org/avatar/e7add028a8da87278c36a3d7b9f1cd60"
+ subject="comment 3"
+ date="2020-10-12T19:53:27Z"
+ content="""
+@Lukey: thanks for the tip. Will try this at some point with a new repo. For now I just copied the most recent version of the file from /annex/objects/ of my central repo. 
+
+@joey: I am afraid I committed the hash-link contents: 'git annex get' didn't change anything. Still I have no idea how this could happen; I'll dig through the history and report back :) 
+"""]]
diff --git a/doc/forum/Cannot_get_unlocked_file_contents/comment_3_be1f3ec26c14ca9adc9d8f24ea096976._comment b/doc/forum/Cannot_get_unlocked_file_contents/comment_3_be1f3ec26c14ca9adc9d8f24ea096976._comment
new file mode 100644
index 0000000000..7a02c4e4de
--- /dev/null
+++ b/doc/forum/Cannot_get_unlocked_file_contents/comment_3_be1f3ec26c14ca9adc9d8f24ea096976._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-10-12T20:10:38Z"
+ content="""
+Like I said, committing the hash link, for an unlocked file, is
+perfectly normal. And will not result in this behavior.
+
+You need to show command output of commands like git-annex get, git-annex
+whereis, git-annex fsck for us to understand what the actual problem is.
+"""]]
diff --git a/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa.mdwn b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa.mdwn
new file mode 100644
index 0000000000..351c6f92d6
--- /dev/null
+++ b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa.mdwn
@@ -0,0 +1,6 @@
+Hi, I have installed latest version from https://launchpad.net/~rubiojr/+archive/git-annex, that is git-annex version: 3.20121017-ubuntu1ppa1~precise
+When running git annex webapp I get 
+
+git-annex: unknown command webapp
+
+I only installed git-annex. Are there more packages to be installed to make it work?
diff --git a/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_1_9345551f5772c3a6f1490b00e1edbf69._comment b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_1_9345551f5772c3a6f1490b00e1edbf69._comment
new file mode 100644
index 0000000000..aae67b95e3
--- /dev/null
+++ b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_1_9345551f5772c3a6f1490b00e1edbf69._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
+ nickname="Tobias"
+ subject="comment 1"
+ date="2013-04-23T08:39:50Z"
+ content="""
+This version does not have the webapp. Use a newer one (maybe you need the standalone build)
+"""]]
diff --git a/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_2_0b688a442b6a911a0353e73097a24cb6._comment b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_2_0b688a442b6a911a0353e73097a24cb6._comment
new file mode 100644
index 0000000000..b83eb40ec8
--- /dev/null
+++ b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_2_0b688a442b6a911a0353e73097a24cb6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="tomas"
+ ip="64.103.25.104"
+ subject="comment 2"
+ date="2013-04-23T11:50:21Z"
+ content="""
+According to documentation:
+http://git-annex.branchable.com/assistant/
+The git-annex assistant comes as part of git-annex, starting with version 3.20120924.
+
+So it should be there in 3.20121017, no?
+"""]]
diff --git a/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_3_7e246caa00005560bb489c927c663046._comment b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_3_7e246caa00005560bb489c927c663046._comment
new file mode 100644
index 0000000000..e2463ba23c
--- /dev/null
+++ b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_3_7e246caa00005560bb489c927c663046._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-04-23T16:05:31Z"
+ content="""
+git-annex can be built without the webapp, and if some of the necessary dependencies for the webapp are not available, it will build without it by default. More recent versions than that one let you run `git annex version` and see the build flags, which can all be disabled due to missing dependencies. For example:
+
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+
+Sergio does seem to be trying to backport all the dependencies of the webapp, but it looks to me like some of them, particularly haskell-xml-hamlet, have not successfully built yet.
+"""]]
diff --git a/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_4_1d8025aabe8bc72711a77f691f67da5f._comment b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_4_1d8025aabe8bc72711a77f691f67da5f._comment
new file mode 100644
index 0000000000..4c050f0520
--- /dev/null
+++ b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_4_1d8025aabe8bc72711a77f691f67da5f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="fmarier"
+ ip="121.98.93.240"
+ subject="My PPA (Ubuntu Precise) has git-annex 4.20130417"
+ date="2013-04-27T23:31:54Z"
+ content="""
+It has the 90+ Haskell packages that are required to build git annex with every backend: https://launchpad.net/~fmarier/+archive/ppa
+"""]]
diff --git a/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_5_7c2f95da65190016192424e7c622122f._comment b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_5_7c2f95da65190016192424e7c622122f._comment
new file mode 100644
index 0000000000..6821da22d8
--- /dev/null
+++ b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_5_7c2f95da65190016192424e7c622122f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3HGoDpnOPob5jOjvIootmkve1-nCpRiI"
+ nickname="Kalle"
+ subject="Debian Sid PowerPC is also without webapp"
+ date="2013-05-07T09:44:31Z"
+ content="""
+Took me a couple of minutes to figure out why git-annex on my old Apple G4 wouldn't recognise the webapp command. Comparing the version command output on AMD64 and PowerPC made it obvious.
+"""]]
diff --git a/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_6_9b8465cefe609e7a696e7573b8892e38._comment b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_6_9b8465cefe609e7a696e7573b8892e38._comment
new file mode 100644
index 0000000000..b2a6e55bb9
--- /dev/null
+++ b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_6_9b8465cefe609e7a696e7573b8892e38._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="tomas"
+ ip="188.167.111.235"
+ subject="thanks for the ppa"
+ date="2013-05-08T10:04:25Z"
+ content="""
+Thanks François for your work
+"""]]
diff --git a/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_7_af6472762a598a454ba52ac0caa059aa._comment b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_7_af6472762a598a454ba52ac0caa059aa._comment
new file mode 100644
index 0000000000..d205e653de
--- /dev/null
+++ b/doc/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/comment_7_af6472762a598a454ba52ac0caa059aa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://openid.fmarier.org/"
+ nickname="fmarier"
+ subject="New location for my PPA"
+ date="2013-06-15T07:41:03Z"
+ content="""
+My Ubuntu Precise PPA has moved here: https://launchpad.net/~fmarier/+archive/git-annex
+
+It contains version 20130601 of git-annex.
+"""]]
diff --git a/doc/forum/Cant_see_git-annex-shell_via_SSH_in_OSX.mdwn b/doc/forum/Cant_see_git-annex-shell_via_SSH_in_OSX.mdwn
new file mode 100644
index 0000000000..76b1d5a8f9
--- /dev/null
+++ b/doc/forum/Cant_see_git-annex-shell_via_SSH_in_OSX.mdwn
@@ -0,0 +1,119 @@
+### Sync Problems using SSH remote in OSX
+
+- Im trying to work out SSH remotes by trying to sync up repos on my home network, following the walkthrough. 
+- I have two machines (mini and mbp ) running OSX Mavericks, with RLogin enabled for all users to enable ssh.
+- I can SSH into the remote machine and see *git-annex-shell*, which seems to have ok permissions
+
+```
+
+    johns-mbp:annex johnmccallum$ ssh john@johns-mini-5.home 
+    
+    Last login: Sun Apr 12 07:31:07 2015 from johns-mbp.home
+
+    johns-mini-5:~ john$ which git-annex-shell
+
+    /usr/local/bin/git-annex-shell
+
+    johns-mini-5:~ john$ ls -l /usr/local/bin/git-annex-shell
+
+    -rwxr-xr-x@ 1 john  admin  668 12 Apr 07:03 /usr/local/bin/git-annex-shell
+
+```
+
+- Previously on mini I created and populated a repo
+
+``` 
+
+    494  mkdir annex
+
+    495  cd annex
+
+    496  git init
+
+    497  git annex init
+
+    498  cp ~/Pictures/*.png .
+
+    499  git annex add .
+
+    500  git commit -a -m 'added png'
+
+```
+
+- I can git clone this repo to MBP by SSH
+
+
+```
+	johns-mbp:~ johnmccallum$ git clone ssh://john@johns-mini-5.home/Users/john/annex ~/annex
+
+	Cloning into '/Users/johnmccallum/annex'...
+
+	remote: Counting objects: 24, done.
+
+	remote: Compressing objects: 100% (19/19), done.
+
+	remote: Total 24 (delta 3), reused 0 (delta 0)
+
+	Receiving objects: 100% (24/24), done.
+
+	Resolving deltas: 100% (3/3), done.
+
+	Checking connectivity... done
+
+	johns-mbp:~ johnmccallum$ cd annex
+
+	johns-mbp:annex johnmccallum$ git annex init 'MBP'
+
+	init MBP (merging origin/git-annex into git-annex...)
+
+	(recording state in git...)
+
+	ok
+
+	(recording state in git...)
+
+	johns-mbp:annex johnmccallum$ ls -l
+
+	total 16
+
+	lrwxr-xr-x  1 johnmccallum  staff  196 12 Apr 08:20 CoGe-Snapshot at 2013-03-22 - 11-27-20.png -> .git/annex/objects/gf/Xp/SHA256E-s367697--	fce3f47f218805cd9855ec3fd4203b52e83587148b34c8e706df512783eb7557.png/SHA256E-s367697--fce3f47f218805cd9855ec3fd4203b52e83587148b34c8e706df512783eb7557.png
+
+	lrwxr-xr-x  1 johnmccallum  staff  196 12 Apr 08:20 delicious.png -> .git/annex/objects/ZJ/vX/SHA256E-s112714--057d0faa464f8d588c053dae460838d68ea7803d7eaf7330798679e63f92cecb.png/SHA256E-s112714--057d0faa464f8d588c053dae460838d68ea7803d7eaf7330798679e63f92cecb.png
+
+
+```
+
+ **HOWEVER**   _git annex get_  fails as follows:
+
+```
+
+	johns-mbp:annex johnmccallum$ git annex get delicious.png 
+
+	get delicious.png bash: git-annex-shell: command not found
+
+ 	 Remote origin does not have git-annex installed; setting annex-ignore
+
+ 	 This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git config remote.origin.annex-ignore false
+	(not available) 
+ 	 Try making some of these repositories available:
+  		129620b2-91b1-4541-b7b1-9e5a9d31d5d3 -- john@johns-mini-5.home:~/annex
+	failed
+	git-annex: get: 1 failed
+
+```
+
+This is not the case on the remote host when I SSH in as the same user
+
+```
+
+    johns-mini-5:~ john$ which git-annex-shell
+
+
+    /usr/local/bin/git-annex-shell
+
+```
+
+
+ The only thread on this seems to be https://git-annex.branchable.com/forum/not_finding_git-annex-shell_on_remote/ and Im at a loss to understand it.  
+
+Any suggestions would be welcome
diff --git a/doc/forum/Cant_see_git-annex-shell_via_SSH_in_OSX/comment_1_1fafdc4ed4a0f601918361dca688aa6c._comment b/doc/forum/Cant_see_git-annex-shell_via_SSH_in_OSX/comment_1_1fafdc4ed4a0f601918361dca688aa6c._comment
new file mode 100644
index 0000000000..edbf2edfc4
--- /dev/null
+++ b/doc/forum/Cant_see_git-annex-shell_via_SSH_in_OSX/comment_1_1fafdc4ed4a0f601918361dca688aa6c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-18T20:05:42Z"
+ content="""
+This is a common gotcha; bash sources something like .bashrc
+or whatever that puts /usr/local/bin/ in your path when it's a login shell.
+However, when git-annex is sshing in, there is no login shell,
+and bash does not source any dotfiles, and so git-annex-shell in not in
+PATH.
+
+The solution is probably to move or symlink it to some other directory
+that is in PATH always.
+"""]]
diff --git a/doc/forum/Case-insensitive_search_with_find_list_whereis__63__.mdwn b/doc/forum/Case-insensitive_search_with_find_list_whereis__63__.mdwn
new file mode 100644
index 0000000000..bb14a81794
--- /dev/null
+++ b/doc/forum/Case-insensitive_search_with_find_list_whereis__63__.mdwn
@@ -0,0 +1 @@
+Are case-insensitive searchs possible with find, list, and whereis?
diff --git a/doc/forum/Case-insensitive_search_with_find_list_whereis__63__/comment_1_b893fd9a250d25ebc62913131cb0a479._comment b/doc/forum/Case-insensitive_search_with_find_list_whereis__63__/comment_1_b893fd9a250d25ebc62913131cb0a479._comment
new file mode 100644
index 0000000000..5722906690
--- /dev/null
+++ b/doc/forum/Case-insensitive_search_with_find_list_whereis__63__/comment_1_b893fd9a250d25ebc62913131cb0a479._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-26T16:09:02Z"
+ content="""
+`git annex find | grep -i whatever`
+
+"""]]
diff --git a/doc/forum/Case-insensitive_search_with_find_list_whereis__63__/comment_2_e19abfe33b0f071ffc059e9976fc6d91._comment b/doc/forum/Case-insensitive_search_with_find_list_whereis__63__/comment_2_e19abfe33b0f071ffc059e9976fc6d91._comment
new file mode 100644
index 0000000000..26d9efaf35
--- /dev/null
+++ b/doc/forum/Case-insensitive_search_with_find_list_whereis__63__/comment_2_e19abfe33b0f071ffc059e9976fc6d91._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="ghen1"
+ subject="comment 2"
+ date="2015-03-29T23:14:00Z"
+ content="""
+I feel stupid for not thinking of that. Thank you.
+"""]]
diff --git a/doc/forum/Central_git_annex_server_that_always_keeps_one_copy.mdwn b/doc/forum/Central_git_annex_server_that_always_keeps_one_copy.mdwn
new file mode 100644
index 0000000000..166a22deef
--- /dev/null
+++ b/doc/forum/Central_git_annex_server_that_always_keeps_one_copy.mdwn
@@ -0,0 +1 @@
+Is there a way to configure a central git repository that keeps track of large files with git annex so that multiple users can clone the repository but no repository clone can drop files from the server. Essentially, I'm looking for a way to have one repository that is always populated with at least one copy of each file. Other users shouldn't be able to tell that repository to drop any files (but would be able to add files it). The term "user" in that last sentence really refers to other clones...
diff --git a/doc/forum/Central_git_annex_server_that_always_keeps_one_copy/comment_1_e786c8df6e48d88cf15b555af1b8639a._comment b/doc/forum/Central_git_annex_server_that_always_keeps_one_copy/comment_1_e786c8df6e48d88cf15b555af1b8639a._comment
new file mode 100644
index 0000000000..19339a3aa2
--- /dev/null
+++ b/doc/forum/Central_git_annex_server_that_always_keeps_one_copy/comment_1_e786c8df6e48d88cf15b555af1b8639a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn-TDneVW-8kwb1fyTRAJfH3l1xs2VSEmk"
+ nickname="James"
+ subject="comment 1"
+ date="2014-07-30T20:37:27Z"
+ content="""
+It might not suit all your needs but you could try using gitolite and set permissions on the git-annex branch of your repository
+http://gitolite.com/gitolite/conf.html#write-types
+
+"""]]
diff --git a/doc/forum/Central_git_annex_server_that_always_keeps_one_copy/comment_2_b0a091e11c18c8640888b0aedfbff5c5._comment b/doc/forum/Central_git_annex_server_that_always_keeps_one_copy/comment_2_b0a091e11c18c8640888b0aedfbff5c5._comment
new file mode 100644
index 0000000000..35778ad9ab
--- /dev/null
+++ b/doc/forum/Central_git_annex_server_that_always_keeps_one_copy/comment_2_b0a091e11c18c8640888b0aedfbff5c5._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2014-10-28T20:28:26Z"
+ content="""
+If you configure the central repository to be in the "full backup" group,
+then the assistant and `git annex sync --content` etc will send the
+contents of all files to it, and never remove the contents of files from
+it.
+
+This doesn't prevent someone manually running `git annex drop --from
+$centralrepo --force`, or similar. But then, nothing prevents users from
+using git to push annexed files to the central repo, and never sending the
+contents of the files along to it.
+
+It would be possible to make `git-annex-shell` have a config setting that
+would prevent ever dropping keys. But I'd like to talk about this use case
+more, to make sure that really makes sense.
+"""]]
diff --git a/doc/forum/Central_server_with_automatically_merged_working_tree.mdwn b/doc/forum/Central_server_with_automatically_merged_working_tree.mdwn
new file mode 100644
index 0000000000..8b2bb87d6c
--- /dev/null
+++ b/doc/forum/Central_server_with_automatically_merged_working_tree.mdwn
@@ -0,0 +1,30 @@
+I would appreciate some feedback on whether the following scheme is feasible or will prove unworkable. I have a few specific questions at the bottom.
+
+# Components
+* An archive of documents to be shared amongst computers
+* A server that stores the archive and retains all of its contents
+* A set of client machines that store only the files that they need and drop the rest
+
+# Desired behavior
+* Clients will run the assistant to handle sync'ing
+* On the server, the archive should be accessible in the working tree so that other users can read the files (they do not need write access).
+* It should be possible to modify the archive on the server while logged into the server
+* Clients can push and pull data. The server does not push or pull data.
+
+# Basic setup
+## Set up the server and one client
+* Create git annex repos on the client and server
+* Add the server as a remote in the client repo
+
+## Keep the server's working directory up to date
+* Add `git merge synced/master master` to the `annex-content` hook described [here](https://git-annex.branchable.com/git-annex-shell/).
+* Add `git merge synced/master master` to the `post-receive` hook.
+
+## Keep server working tree visible to a different group
+* Set `git config core.sharedrepository group` for the repository
+* Add `chgrp -R shared "$(git rev-parse --show-toplevel)"` to the `annex-content`, `post-receive`, and `post-merge` hooks, where `shared` is the name of the group that you want to be able to access the server files.
+
+# Questions
+* I had to add the `post-receive` hook because updates from the assistant were not trigger the `annex-content` hook. Should they trigger it?
+* Are there downsides to merging `synced/master` like this?
+* If I want to edit files on the server, is it safe to edit them in the repo with this set up? Or should I create a second client repo on the server, check out the necessary files there, and then push them to the server like I would from any other client?
diff --git a/doc/forum/Central_server_with_automatically_merged_working_tree/comment_1_bc850e25e48598a09353850021c6368c._comment b/doc/forum/Central_server_with_automatically_merged_working_tree/comment_1_bc850e25e48598a09353850021c6368c._comment
new file mode 100644
index 0000000000..2680a14115
--- /dev/null
+++ b/doc/forum/Central_server_with_automatically_merged_working_tree/comment_1_bc850e25e48598a09353850021c6368c._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-21T16:42:29Z"
+ content="""
+A way to do this pretty cleanly is described here:
+<http://git-annex.branchable.com/tips/setup_a_public_repository_on_a_web_site/>
+
+The annex-content hook is not meant to be run when a regular git push
+is made to the repository. That would be unnecessarily redundant with
+existing git hooks.
+
+I'd expect it to be pretty safe to edit files in such a repository,
+but you have to keep in mind that if changes are pushed into it at the same
+time as an edit is occuring, you can get into various situations with the
+hooks etc.
+"""]]
diff --git a/doc/forum/Centralized_repository_with_webapp.mdwn b/doc/forum/Centralized_repository_with_webapp.mdwn
new file mode 100644
index 0000000000..6a9fb285de
--- /dev/null
+++ b/doc/forum/Centralized_repository_with_webapp.mdwn
@@ -0,0 +1,13 @@
+Hi,
+
+I'm kind of new to git-annex, I've been following it for a while and tried small task, but never used it in a real situation.
+I'm now trying to sync various computers through a central server and I'm having some problems, so I think I might be doing something wrong.
+
+I have a remote server that I want to use as central server. I use the webapp to configure client 1 to use that server as remote server and using git (so I assume it stores the files and the tree). I then create the client 2 in another computer and doing the exact same steps.
+Initially everything seams to work, but after a few modifications in the clients weird things start to happen, files only in one client, some files don't get updated, etc.
+
+I guess I'm doing something wrong (maybe I need to clone the repo in client 2 instead of creating a new one?) but I can't figure out how to solve it.
+
+Any tip that could help me?
+
+Thanks!
diff --git a/doc/forum/Centralized_repository_with_webapp/comment_1_dcb9b07fd154f4d4fdef4809cc37ce77._comment b/doc/forum/Centralized_repository_with_webapp/comment_1_dcb9b07fd154f4d4fdef4809cc37ce77._comment
new file mode 100644
index 0000000000..78866072e3
--- /dev/null
+++ b/doc/forum/Centralized_repository_with_webapp/comment_1_dcb9b07fd154f4d4fdef4809cc37ce77._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-11T15:13:32Z"
+ content="""
+Your setup is fine as far as it goes. The problem is that a client has no way to know when another client has pushed a change to the centralized repository. It might take quite a while before it decides on its own to go pull changes from there (most often because *it* has now changed a file, and realizes it needs to sync), and so it won't see files the other client has added right away.
+
+The solution to this is to go to Configuration -> Jabber account, and set both clients up using the same Jabber account. (Or, if these two machines belong to different people, you can pick \"pair with a friend\" to link one with the other over Jabber.)
+
+Now when one client pushes to the centralized repository, it will immediately send the other a message letting it know something has changed.
+
+The webapp actually pops up an alert when you add that centralized ssh repository, to nudge you to do this:
+
+[[/assistant/xmppnudge.png]]
+
+I'm trying to find ways to make the need to do this more clear...
+"""]]
diff --git a/doc/forum/Centralized_repository_with_webapp/comment_2_08c84f2703f89dc12982eba9dd2a06d1._comment b/doc/forum/Centralized_repository_with_webapp/comment_2_08c84f2703f89dc12982eba9dd2a06d1._comment
new file mode 100644
index 0000000000..a6686f6a3d
--- /dev/null
+++ b/doc/forum/Centralized_repository_with_webapp/comment_2_08c84f2703f89dc12982eba9dd2a06d1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
+ nickname="Jon Ander"
+ subject="comment 2"
+ date="2013-03-13T23:52:32Z"
+ content="""
+Hi Joey,
+
+My problem isn't that the repositories don't sync immediately, they are never up at the same time and I understand that the assistant is not constantly checking for changes, so that's not an issue.
+The problem is that with this setup I'm experiencing data loss (files being completely removed from both repos), it has happened a few times, but I cant seam to reproduce it reliably. I'll keep investigating and get back to you if I have a proper bug.
+"""]]
diff --git a/doc/forum/Change_a_special_remote__39__s_type.mdwn b/doc/forum/Change_a_special_remote__39__s_type.mdwn
new file mode 100644
index 0000000000..bd6d6a0210
--- /dev/null
+++ b/doc/forum/Change_a_special_remote__39__s_type.mdwn
@@ -0,0 +1,7 @@
+Hello,
+
+I have accidentally created a special remote of the wrong type (rsync instead of webdav). I would like to reuse the name of that special remote for consistency with other repos, but marking dead does and initremote still not allows me to reuse the name. A new enableremote with the correct configuration succeeds, but the `git annex show XXX` still shows the remote as type rsync and dead.
+
+Is there a way to a) revive the remote and b) change the type of it?
+
+Thanks!
diff --git a/doc/forum/Change_a_special_remote__39__s_type/comment_1_9d7c23f5c985d44ffa78b3957ddc3d15._comment b/doc/forum/Change_a_special_remote__39__s_type/comment_1_9d7c23f5c985d44ffa78b3957ddc3d15._comment
new file mode 100644
index 0000000000..05ffc2722c
--- /dev/null
+++ b/doc/forum/Change_a_special_remote__39__s_type/comment_1_9d7c23f5c985d44ffa78b3957ddc3d15._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2019-07-10T16:29:25Z"
+ content="""
+Could you just reset the git-annex branch to its state before creating the remote?
+"""]]
diff --git a/doc/forum/Change_a_special_remote__39__s_type/comment_2_c514ca0dd8b883e02de7c70b46991152._comment b/doc/forum/Change_a_special_remote__39__s_type/comment_2_c514ca0dd8b883e02de7c70b46991152._comment
new file mode 100644
index 0000000000..25d5ae7416
--- /dev/null
+++ b/doc/forum/Change_a_special_remote__39__s_type/comment_2_c514ca0dd8b883e02de7c70b46991152._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Horus"
+ avatar="http://cdn.libravatar.org/avatar/8f0ee08b98ea5bba76c3fe112c08851c"
+ subject="comment 2"
+ date="2019-07-11T06:51:26Z"
+ content="""
+In the meantime I have learned about `git annex forget --drop-dead --force`. With that I managed to make the repo forget about the dead remote.
+"""]]
diff --git a/doc/forum/Change_a_special_remote__39__s_type/comment_3_b89db83045d4baa82cc96b7610caecda._comment b/doc/forum/Change_a_special_remote__39__s_type/comment_3_b89db83045d4baa82cc96b7610caecda._comment
new file mode 100644
index 0000000000..f275a1f6ee
--- /dev/null
+++ b/doc/forum/Change_a_special_remote__39__s_type/comment_3_b89db83045d4baa82cc96b7610caecda._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-07-19T17:13:46Z"
+ content="""
+It should work to use `git annex enableremote remotename type=webdav`
+"""]]
diff --git a/doc/forum/Change_annex_id_after_harddrive_clone.mdwn b/doc/forum/Change_annex_id_after_harddrive_clone.mdwn
new file mode 100644
index 0000000000..6cf1b03895
--- /dev/null
+++ b/doc/forum/Change_annex_id_after_harddrive_clone.mdwn
@@ -0,0 +1,5 @@
+I got a new laptop the other day. To set it up, I just cloned the home directory from my desktop.
+As part of that, I have a git annex repository that now has all the content, but still thinks it is
+my desktop. 
+What is the right way to convert it into a unique repository?
+I changed the annex uuid in the config file, but I am not sure if that is correct or sufficient.
diff --git a/doc/forum/Change_annex_id_after_harddrive_clone/comment_1_2e8ba624f404edf2923d08ae27d12a60._comment b/doc/forum/Change_annex_id_after_harddrive_clone/comment_1_2e8ba624f404edf2923d08ae27d12a60._comment
new file mode 100644
index 0000000000..51ecb623c1
--- /dev/null
+++ b/doc/forum/Change_annex_id_after_harddrive_clone/comment_1_2e8ba624f404edf2923d08ae27d12a60._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-06-03T18:01:30Z"
+ content="""
+It's sufficient to just change the annex uuid to a new one you generate.
+
+You may want to also run `git-annex describe here` to give the new 
+repository some description.
+"""]]
diff --git a/doc/forum/Change_or_add_S3_credentials.mdwn b/doc/forum/Change_or_add_S3_credentials.mdwn
new file mode 100644
index 0000000000..736f9e4e1b
--- /dev/null
+++ b/doc/forum/Change_or_add_S3_credentials.mdwn
@@ -0,0 +1,6 @@
+How do I change or add S3 credentials, when a S3 special remote is already initialised/enabled?
+
+I have a repository with a `public=yes` S3 remote, such that people can read the data without credentials.
+But then when they need to upload files, how do they add their credentials?
+
+Setting the `AWS_*` environment variables when running `git annex copy --to=s3` works, but then the credentials are not stored.
diff --git a/doc/forum/Change_or_add_S3_credentials/comment_1_864932114dcc7aaf1d88edb0673f1d86._comment b/doc/forum/Change_or_add_S3_credentials/comment_1_864932114dcc7aaf1d88edb0673f1d86._comment
new file mode 100644
index 0000000000..bd9f92c8ad
--- /dev/null
+++ b/doc/forum/Change_or_add_S3_credentials/comment_1_864932114dcc7aaf1d88edb0673f1d86._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Mara"
+ avatar="http://cdn.libravatar.org/avatar/9b8abe5a5b0a41b88fc9970a88c2e317"
+ subject="Also with embedcreds=yes"
+ date="2018-08-13T12:28:09Z"
+ content="""
+Also with `public=no` but `embedcreds=yes`.
+
+It can be useful to embed read-only credentials, but allow users to easily add/store their own credentials (locally) with write-access.
+"""]]
diff --git a/doc/forum/Change_remote_server_address.mdwn b/doc/forum/Change_remote_server_address.mdwn
new file mode 100644
index 0000000000..722b4ada4e
--- /dev/null
+++ b/doc/forum/Change_remote_server_address.mdwn
@@ -0,0 +1,6 @@
+Hi again,
+
+I have a SSH remote server that I registered to my git-annex repository via git-annex assistant. When I go to edit the settings for the repository from within git-annex assistant I noticed I can't edit the server address. If the server IP changes, how should I go about letting git-annex know of this? Can I just (1) shutdown git-annex assistant, (2) edit the 'url' line of the remote entry inside the repository's ``.git/config`` file, and then (3) start up git-annex assistant again? Is this a safe method for doing this?
+
+Regards,
+Blake
diff --git a/doc/forum/Change_remote_server_address/comment_1_401c3d2530ac7ba41dd3857ab4737ed5._comment b/doc/forum/Change_remote_server_address/comment_1_401c3d2530ac7ba41dd3857ab4737ed5._comment
new file mode 100644
index 0000000000..d4e4068296
--- /dev/null
+++ b/doc/forum/Change_remote_server_address/comment_1_401c3d2530ac7ba41dd3857ab4737ed5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-01T16:35:47Z"
+ content="""
+Yes, you can certainly edit .git/config in any way you like and the assistant will use the new values when started back up.
+
+It shouldn't be using a hardcoded IP address normally, unless you manually entered an IP address when setting up that ssh remote. Using DNS is better..
+"""]]
diff --git a/doc/forum/Change_remote_server_address/comment_2_93a4c44d552efe6d51584e0aab3605e7._comment b/doc/forum/Change_remote_server_address/comment_2_93a4c44d552efe6d51584e0aab3605e7._comment
new file mode 100644
index 0000000000..84ec29e051
--- /dev/null
+++ b/doc/forum/Change_remote_server_address/comment_2_93a4c44d552efe6d51584e0aab3605e7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="hasard@aa44fbf6c0a991a7b76fb8a118cc0b274f528de1"
+ nickname="hasard"
+ subject="like dropbox, with your own cloud "
+ date="2015-08-26T17:49:16Z"
+ content="""
+just to be complete: during setup some useful assistant may have created rsa keys so that the assistant can access remote hosts without password and following the update of .git/config you probably will need to update .ssh/config as well.
+ 
+Like many things with git annex and the assistant, its just \"like dropbox with your own cloud\", but you need first to become expert in editing .git/config and .ssh/config. 
+"""]]
diff --git a/doc/forum/Changing_files_during_git_annex_runs.mdwn b/doc/forum/Changing_files_during_git_annex_runs.mdwn
new file mode 100644
index 0000000000..7ff362d1cc
--- /dev/null
+++ b/doc/forum/Changing_files_during_git_annex_runs.mdwn
@@ -0,0 +1,12 @@
+Hello,
+
+I have my music git annexed, direct mode. It's about 30k files of 429GB size. Some actions take considerable time (sync, add and of course transfer to/from other repos). During this time I don't hear music because of my player changes files. :-(
+
+When is it a problem when a files changes during git annex operations?
+
+git annex get gives a wrong checksum I guess and you need to re-transfer later.
+
+What about git annex add?
+
+Thx!
+Florian
diff --git a/doc/forum/Changing_files_during_git_annex_runs/comment_1_8067077c49dafbe2afa7d182b3314df4._comment b/doc/forum/Changing_files_during_git_annex_runs/comment_1_8067077c49dafbe2afa7d182b3314df4._comment
new file mode 100644
index 0000000000..312100b116
--- /dev/null
+++ b/doc/forum/Changing_files_during_git_annex_runs/comment_1_8067077c49dafbe2afa7d182b3314df4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.111"
+ subject="comment 1"
+ date="2014-10-13T21:33:35Z"
+ content="""
+git-annex will detect things like files being changed at the same time that `git annex add` is run. It doesn't currently do a full lsof check to make sure nothing has a file open when `git annex add` is run (the assistant does do such extra checks).
+
+I don't see why syncing or transferring files to other repos should prevent your music player or whatever from using the files that you have locally present.
+
+If you're using direct mode and your music player is modifying the contents of files in the repository, then that will prevent other repositories downloading older versions of those files, since the old version is no longer present in the direct mode repository. There is the possibility for some innefficient attempts to transfer a file, that would fail because it got modified in between. git-annex detects this, but it can still waste bandwidth.
+
+(If my music player was modifying files all the time,  I'd give it a good talking to; that's not the job of a music player. But, I keep my music in an indirect mode repo, so any music player would find it hard to modify annexed files anyway.)
+"""]]
diff --git a/doc/forum/Changing_the_target_of_an_external_special_remote.mdwn b/doc/forum/Changing_the_target_of_an_external_special_remote.mdwn
new file mode 100644
index 0000000000..84b440ccf6
--- /dev/null
+++ b/doc/forum/Changing_the_target_of_an_external_special_remote.mdwn
@@ -0,0 +1 @@
+I've initialized an external special remote (specifically, an rclone remote). It is working great. However, I would like to edit my rclone config and change the name of the rclone remote. This is the value I passed as `target=` when running `git annex initremote`. Can I change the target of the special remote in git annex? I grepped through `~/.git`, but didn't see it anywhere.
diff --git a/doc/forum/Changing_the_target_of_an_external_special_remote/comment_1_db1112fb1b4626f2d2c1b7b78ab3f5e5._comment b/doc/forum/Changing_the_target_of_an_external_special_remote/comment_1_db1112fb1b4626f2d2c1b7b78ab3f5e5._comment
new file mode 100644
index 0000000000..d6dc0ff10d
--- /dev/null
+++ b/doc/forum/Changing_the_target_of_an_external_special_remote/comment_1_db1112fb1b4626f2d2c1b7b78ab3f5e5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-05T16:49:37Z"
+ content="""
+This is generally the kind of thing that `git annex enableremote` is able
+to do, by specifying a new value for target=
+
+I am not very familiar with the rclone remote, so don't know if it will
+work to change its target.
+"""]]
diff --git a/doc/forum/Cheapest_test_for_an_initialized_annex__63__.mdwn b/doc/forum/Cheapest_test_for_an_initialized_annex__63__.mdwn
new file mode 100644
index 0000000000..86cfef9200
--- /dev/null
+++ b/doc/forum/Cheapest_test_for_an_initialized_annex__63__.mdwn
@@ -0,0 +1,11 @@
+I need to implement some functionality that should work in similar ways when faced with a plain Git vs a git-annex repo. In this context I am looking for the cheapest of the appropriate tests for an initialized annex?
+
+I have looked at
+
+- `git config annex.uuid` (~3ms)
+- `git rev-parse git-annex` (~3ms)
+- `git annex info --fast -q` (~50ms)
+
+Are  the fast ones sufficient to guarantee that no subsequent call to a git-annex command would yield `git-annex: First run: git-annex init`?
+
+Thanks!
diff --git a/doc/forum/Cheapest_test_for_an_initialized_annex__63__/comment_1_abe1af7fc49f91e3aa15915190dc5dfd._comment b/doc/forum/Cheapest_test_for_an_initialized_annex__63__/comment_1_abe1af7fc49f91e3aa15915190dc5dfd._comment
new file mode 100644
index 0000000000..688829b314
--- /dev/null
+++ b/doc/forum/Cheapest_test_for_an_initialized_annex__63__/comment_1_abe1af7fc49f91e3aa15915190dc5dfd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="aurtzy"
+ avatar="http://cdn.libravatar.org/avatar/7d44f9b718a534ada04551ee8c72e07f"
+ subject="comment 1"
+ date="2024-04-25T17:35:49Z"
+ content="""
+`git config annex.uuid` seems reliable enough to me - the uuid is stored in `.git/config` and doesn't exist if it's not annex-inited (assuming no malicious behavior).
+
+If you're looking for the very cheapest, perhaps something like a file-exists check on `.git/annex` would work? I don't know if there are any edge cases with this one, though.
+"""]]
diff --git a/doc/forum/Cheapest_test_for_an_initialized_annex__63__/comment_2_3d6f353d087cb945a0288f0594a1d1e0._comment b/doc/forum/Cheapest_test_for_an_initialized_annex__63__/comment_2_3d6f353d087cb945a0288f0594a1d1e0._comment
new file mode 100644
index 0000000000..362abc4ff3
--- /dev/null
+++ b/doc/forum/Cheapest_test_for_an_initialized_annex__63__/comment_2_3d6f353d087cb945a0288f0594a1d1e0._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2024-04-30T19:18:58Z"
+ content="""
+annex.uuid is the right way.
+
+I would not trust checking existence of .git/annex directory. There may be
+some situation where the repo is initialized, then uninitialized, but that
+directory still exists. Or similar.
+"""]]
diff --git a/doc/forum/Check_if_remote_is_using_GPG__63__.mdwn b/doc/forum/Check_if_remote_is_using_GPG__63__.mdwn
new file mode 100644
index 0000000000..d719b2feb7
--- /dev/null
+++ b/doc/forum/Check_if_remote_is_using_GPG__63__.mdwn
@@ -0,0 +1 @@
+Is there a way to check if a special remote is setup to use GPG? And, if so, see the ID of keys that it is encrypting to?
diff --git a/doc/forum/Check_if_remote_is_using_GPG__63__/comment_1_db8ce8ef50fc33a28860ee475988450f._comment b/doc/forum/Check_if_remote_is_using_GPG__63__/comment_1_db8ce8ef50fc33a28860ee475988450f._comment
new file mode 100644
index 0000000000..ff073cd9a0
--- /dev/null
+++ b/doc/forum/Check_if_remote_is_using_GPG__63__/comment_1_db8ce8ef50fc33a28860ee475988450f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-17T18:59:40Z"
+ content="""
+You can tell this by looking at remote.log:
+
+git show git-annex:remote.log
+
+Remotes that are encrypted will have a big \"cipher=\" block in there, and ones that are encrypted to gpg public keys will have a list of the keys following \"cipherkeys=\"
+
+
+"""]]
diff --git a/doc/forum/Check_if_remote_is_using_GPG__63__/comment_2_11c7033904c9c7a1df766e915632c386._comment b/doc/forum/Check_if_remote_is_using_GPG__63__/comment_2_11c7033904c9c7a1df766e915632c386._comment
new file mode 100644
index 0000000000..a88021352e
--- /dev/null
+++ b/doc/forum/Check_if_remote_is_using_GPG__63__/comment_2_11c7033904c9c7a1df766e915632c386._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="annexuser"
+ ip="77.247.182.246"
+ subject="comment 2"
+ date="2013-03-17T22:25:58Z"
+ content="""
+If a special remote was setup using shared encryption, can I change it to using keys by simply doing `initremote myremote encryption=keyid`? Or should I remove the remote and start over?
+"""]]
diff --git a/doc/forum/Check_if_remote_is_using_GPG__63__/comment_3_a7ab70ad87a334c36761ddb3d830d99b._comment b/doc/forum/Check_if_remote_is_using_GPG__63__/comment_3_a7ab70ad87a334c36761ddb3d830d99b._comment
new file mode 100644
index 0000000000..f467495b8e
--- /dev/null
+++ b/doc/forum/Check_if_remote_is_using_GPG__63__/comment_3_a7ab70ad87a334c36761ddb3d830d99b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-03-18T15:09:53Z"
+ content="""
+git-annex won't let you change a remote's encryption scheme, as this would make any data stored in the remote using the old scheme be no longer accessible. You need to make a new remote. It should be fine to point the new remote at the same location as the old one, though.
+"""]]
diff --git a/doc/forum/Check_when_your_last_fsck_was__63__.mdwn b/doc/forum/Check_when_your_last_fsck_was__63__.mdwn
new file mode 100644
index 0000000000..4a655cc1de
--- /dev/null
+++ b/doc/forum/Check_when_your_last_fsck_was__63__.mdwn
@@ -0,0 +1,4 @@
+Hey Joey,
+    Is there a way to see when the last fsck was?  I know about --incremental and the related options, but sometimes I'd like to know when the last time I fsck'd a file (or even the whole repo) was.  There doesn't seem to be a command line option for it, but I know that info is saved somewhere...maybe this could be part of 'git annex status'?
+
+$(words of gratitude and encouragement)
diff --git a/doc/forum/Check_when_your_last_fsck_was__63__/comment_1_ee98a1fcd796fe4fd7af6f77d0c1837d._comment b/doc/forum/Check_when_your_last_fsck_was__63__/comment_1_ee98a1fcd796fe4fd7af6f77d0c1837d._comment
new file mode 100644
index 0000000000..ae8ffe42fa
--- /dev/null
+++ b/doc/forum/Check_when_your_last_fsck_was__63__/comment_1_ee98a1fcd796fe4fd7af6f77d0c1837d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-19T18:50:06Z"
+ content="""
+You're quite right. that info is stored in `.git/annex/fsckstate`. The timestamp of the file is when the last incremental fsck was started. The contents of the file is the same date, represented as seconds from epoch.
+
+That is only written to when doing an incremental fsck though. A non-incremental fsck does not touch the file.
+"""]]
diff --git a/doc/forum/Check_when_your_last_fsck_was__63__/comment_2_7238740d7904a6a9715c1cd7d8a529d4._comment b/doc/forum/Check_when_your_last_fsck_was__63__/comment_2_7238740d7904a6a9715c1cd7d8a529d4._comment
new file mode 100644
index 0000000000..52e9841747
--- /dev/null
+++ b/doc/forum/Check_when_your_last_fsck_was__63__/comment_2_7238740d7904a6a9715c1cd7d8a529d4._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="anthony@ad39673d230d75cbfd19d2757d754030049c7673"
+ nickname="anthony"
+ avatar="http://cdn.libravatar.org/avatar/05b48b72766177b3b0a6ff4afdb70790"
+ subject="Seems this has been somewhat implemented?"
+ date="2018-07-08T07:15:38Z"
+ content="""
+From one of my repositories (UUIDs redacted, I doubt that's required but better safe than sorry):
+
+    $ git show git-annex:activity.log
+    XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX4e Fsck timestamp=1509040059.713438476s
+    XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX41 Fsck timestamp=1509495891.418704179s
+    XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX28 Fsck timestamp=1496379403.744140736s
+    XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX20 Fsck timestamp=1527838142.197908353s
+    XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXdb Fsck timestamp=1530951201.006459518s
+    XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX37 Fsck timestamp=1509828389.73059196s
+
+Those appear to be Unix timestamps, easily converted to human-readable with, e.g., `date -d @TIMESTAMP` (without the `s` at the end; at least with GNU date). E.g., the last one becomes Sat Nov  4 16:46:29 EDT 2017.
+
+Sometimes there are multiple lines per-repository; not sure what determines how long they're kept. Before running `git-annex sync`, this one had dozens of lines of history; sync cleaned it up. Of course, those lines of history remain in the git history.
+"""]]
diff --git a/doc/forum/Check_when_your_last_fsck_was__63__/comment_3_8fa3680b084fad45d7a184d1191fedce._comment b/doc/forum/Check_when_your_last_fsck_was__63__/comment_3_8fa3680b084fad45d7a184d1191fedce._comment
new file mode 100644
index 0000000000..42faf88466
--- /dev/null
+++ b/doc/forum/Check_when_your_last_fsck_was__63__/comment_3_8fa3680b084fad45d7a184d1191fedce._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-08-03T18:28:07Z"
+ content="""
+That was implemented for a different use-case (`git-annex expire`) but
+you can certianly use it to keep track of the last time some fsck, perhaps
+a partial one, was run on a repository.
+"""]]
diff --git a/doc/forum/Checking_for_missing_files_in_S3___40__reduced_redundancy__41__.mdwn b/doc/forum/Checking_for_missing_files_in_S3___40__reduced_redundancy__41__.mdwn
new file mode 100644
index 0000000000..97299a9662
--- /dev/null
+++ b/doc/forum/Checking_for_missing_files_in_S3___40__reduced_redundancy__41__.mdwn
@@ -0,0 +1,5 @@
+I would like to use git-annex with [S3 reduced redundancy storace (RRS)](https://aws.amazon.com/s3/faqs/#rrs_anchor), a cheaper S3 service with an higher chance of seeing your files disappear overnight. This means that git-annex may think that a certain files has been copied to a S3 remote while, in fact, it is no longer there.
+
+I would like to check that the files S3 are really there and, if some files are not, record that we lost that copy. In the case of S3, either the data is there and it is complete or it is not there at all, so there is no need to check the data itself, just the presence of the files.
+
+Is there a way to check that all the files that are supposed to be in a S3 remote are still there?
diff --git a/doc/forum/Checking_for_missing_files_in_S3___40__reduced_redundancy__41__/comment_2_793b3d9f78562f3aecf27dd926bbcf82._comment b/doc/forum/Checking_for_missing_files_in_S3___40__reduced_redundancy__41__/comment_2_793b3d9f78562f3aecf27dd926bbcf82._comment
new file mode 100644
index 0000000000..404ba8b878
--- /dev/null
+++ b/doc/forum/Checking_for_missing_files_in_S3___40__reduced_redundancy__41__/comment_2_793b3d9f78562f3aecf27dd926bbcf82._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.114"
+ subject="comment 2"
+ date="2014-04-24T18:12:59Z"
+ content="""
+git annex fsck --fast --from $yours3remote
+"""]]
diff --git a/doc/forum/Checking_that_everything_is_committed.mdwn b/doc/forum/Checking_that_everything_is_committed.mdwn
new file mode 100644
index 0000000000..7f492fc5ab
--- /dev/null
+++ b/doc/forum/Checking_that_everything_is_committed.mdwn
@@ -0,0 +1,32 @@
+I use this to check that git repos have nothing untracked:
+
+        # 1st command: check index against HEAD
+        # 2nd command: check working tree against index
+        # 3rd command: check for untracked files
+        # 4th command: check for stashes
+        git diff-index --quiet --cached HEAD \
+            && git diff-files --quiet \
+            && test -z "$(git status --porcelain)" \
+            && test -z "$(git stash list)"
+
+The call to git-diff-files(1) fails in a v7 repo with output like this (if I drop the `--quiet`):
+
+    spwhitton@iris:~/lib/athena-apt>git diff-files
+    :100644 100644 f8e47b9532ea17ac825c39bddc35dbd68f120a46 0000000000000000000000000000000000000000 M	dists/buster-backports/main/binary-amd64/Packages
+    :100644 100644 f8e47b9532ea17ac825c39bddc35dbd68f120a46 0000000000000000000000000000000000000000 M	dists/buster-backports/main/binary-i386/Packages
+    :100644 100644 f8e47b9532ea17ac825c39bddc35dbd68f120a46 0000000000000000000000000000000000000000 M	dists/buster/main/binary-amd64/Packages
+    :100644 100644 f8e47b9532ea17ac825c39bddc35dbd68f120a46 0000000000000000000000000000000000000000 M	dists/buster/main/binary-i386/Packages
+    :100644 100644 f8e47b9532ea17ac825c39bddc35dbd68f120a46 0000000000000000000000000000000000000000 M	dists/rc-buggy/main/binary-amd64/Packages
+    :100644 100644 f8e47b9532ea17ac825c39bddc35dbd68f120a46 0000000000000000000000000000000000000000 M	dists/rc-buggy/main/binary-i386/Packages
+    :100644 100644 f8e47b9532ea17ac825c39bddc35dbd68f120a46 0000000000000000000000000000000000000000 M	dists/sid/main/binary-amd64/Packages
+    :100644 100644 f8e47b9532ea17ac825c39bddc35dbd68f120a46 0000000000000000000000000000000000000000 M	dists/sid/main/binary-i386/Packages
+    :100644 100644 f8e47b9532ea17ac825c39bddc35dbd68f120a46 0000000000000000000000000000000000000000 M	dists/stretch/main/binary-amd64/Packages
+    :100644 100644 f8e47b9532ea17ac825c39bddc35dbd68f120a46 0000000000000000000000000000000000000000 M	dists/stretch/main/binary-i386/Packages
+
+I note that the listed files are empty.
+
+Is there a git-annex command that I can run to normalise my repo so that git-diff-files(1) produces no output?  Or does it not make sense to run git-diff-files(1) in a v7 repo?
+
+Thanks.
+
+--spwhitton
diff --git a/doc/forum/Checking_that_everything_is_committed/comment_1_875c22110d65c0d8e6ef6aebced87e95._comment b/doc/forum/Checking_that_everything_is_committed/comment_1_875c22110d65c0d8e6ef6aebced87e95._comment
new file mode 100644
index 0000000000..eb0b6b0c66
--- /dev/null
+++ b/doc/forum/Checking_that_everything_is_committed/comment_1_875c22110d65c0d8e6ef6aebced87e95._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-04-03T17:19:36Z"
+ content="""
+So specifically, this happens for unlocked files in a v7 repository, 
+but only when the files are empty.
+
+I suspect this is a bug in git. It might have something to do with
+the mention in git-diff-files(1) and git-diff(1) about empty files:
+
+       --ita-invisible-in-index
+           By default entries added by "git add -N" appear as an existing
+           empty file in "git diff" and a new file in "git diff --cached".
+
+And `git diff` similarly shows a diff for these empty unlocked files.
+
+Makes me suspect there's some hack going on in git WRT empty
+files and perhaps it bypasses the smudge/clean filters?
+
+I usually use `git diff --cached` for this kind of thing, and it doesn't have
+the problem, but I don't know if it meets your needs either.
+"""]]
diff --git a/doc/forum/Checkout_only_some_files_with_the_assistant.mdwn b/doc/forum/Checkout_only_some_files_with_the_assistant.mdwn
new file mode 100644
index 0000000000..7a2270d920
--- /dev/null
+++ b/doc/forum/Checkout_only_some_files_with_the_assistant.mdwn
@@ -0,0 +1,14 @@
+Hi,
+
+I really like git-annex for sharing contents with all my devices. But i have a problem with the assistant on my phone, i don't know how to git annex get some file but not all.
+For example i have this on a remote:
+
+repository:
+ - big file1
+ - big file2
+ - big file3
+
+I have this repository on my phone. I would like to be able to checkout out only "big file2" directly within the assistant.
+How can i achieve that?
+
+Thank you. 
diff --git a/doc/forum/Checkout_only_some_files_with_the_assistant/comment_1_23d8ab1a05e3e9d3611bd12a4ba70b0c._comment b/doc/forum/Checkout_only_some_files_with_the_assistant/comment_1_23d8ab1a05e3e9d3611bd12a4ba70b0c._comment
new file mode 100644
index 0000000000..85325c60ce
--- /dev/null
+++ b/doc/forum/Checkout_only_some_files_with_the_assistant/comment_1_23d8ab1a05e3e9d3611bd12a4ba70b0c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.114"
+ subject="comment 1"
+ date="2014-04-24T18:15:15Z"
+ content="""
+[[preferred_content]] expressions can be used to do that. Works best if all the files you want have some extension or are in a specific directory.
+
+There are some [[preferred_content/standard_groups]] that might do what you want, particularly the \"manual\" one.
+"""]]
diff --git a/doc/forum/Checkout_only_some_files_with_the_assistant/comment_2_bf095ff5b5af95b062ae1f7da566a279._comment b/doc/forum/Checkout_only_some_files_with_the_assistant/comment_2_bf095ff5b5af95b062ae1f7da566a279._comment
new file mode 100644
index 0000000000..cf35f3541d
--- /dev/null
+++ b/doc/forum/Checkout_only_some_files_with_the_assistant/comment_2_bf095ff5b5af95b062ae1f7da566a279._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="elfangor"
+ ip="176.57.244.101"
+ subject="comment 2"
+ date="2014-04-28T13:12:07Z"
+ content="""
+Thanks for your reply.
+
+The Standard group \"manual\" seems to be what i need. The last thing i'd like to now is, is there a way to do git annex get on the assistant(on the webui) on my phone? (I know i can do this on the shell opened, but it's not that easy to write from the phone.) I guess it's not implemented, and i understand that it should be a lot of work to add a file browser in the ui where you can git annex get, and git annex add from it.
+
+Thanks again for your answer, really helpfull: I have a better idea on how i will structur my git annex repositories.
+"""]]
diff --git a/doc/forum/Checkout_only_some_files_with_the_assistant/comment_3_7c026e36e1cdd52053c34638c87d793c._comment b/doc/forum/Checkout_only_some_files_with_the_assistant/comment_3_7c026e36e1cdd52053c34638c87d793c._comment
new file mode 100644
index 0000000000..ae18c8caff
--- /dev/null
+++ b/doc/forum/Checkout_only_some_files_with_the_assistant/comment_3_7c026e36e1cdd52053c34638c87d793c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="216.145.95.162"
+ subject="comment 3"
+ date="2014-05-19T15:45:57Z"
+ content="""
+There is not currently any UI to do git-annex get/drop. 
+
+There is some recent work on [[tips/file_manager_integration]] which lets you use a file manager and pick files you want and files to drop. Nobody has gotten it working with android file manager yet AFAIK.
+"""]]
diff --git a/doc/forum/Clarification_in_usage_case.mdwn b/doc/forum/Clarification_in_usage_case.mdwn
new file mode 100644
index 0000000000..2426f86801
--- /dev/null
+++ b/doc/forum/Clarification_in_usage_case.mdwn
@@ -0,0 +1,8 @@
+Hello. This is in the git-annex usage case called "the nomad":
+> When she has 1 bar on her cell, Alice queues up interesting files on her server for later. At a coffee shop, she has git-annex download them to her USB drive.
+
+Every time I read this, it makes me think that it would be possible to "tag" a number of files, and then get them all in one go when they are made available. This would be quite useful since I don't always remember what files I wanted when I plug in the external HD and I don't always go get the HD when I remember one more file that would be convenient to have.
+
+Unfortunately I never did find a way of achieving this (not on the command line). Perhaps I could use the *preferred content* to achieve that effect, but it does not seem as convenient as something like an hypothetical `git-annex get --delayed filename1 filename2`.
+
+Could someone suggest a way of doing this? Thank you very much. I'm still learning this neat tool.
diff --git a/doc/forum/Clarification_in_usage_case/comment_1_555ff0df9be2e25dcc784bc7956dcfe7._comment b/doc/forum/Clarification_in_usage_case/comment_1_555ff0df9be2e25dcc784bc7956dcfe7._comment
new file mode 100644
index 0000000000..338ab28c3f
--- /dev/null
+++ b/doc/forum/Clarification_in_usage_case/comment_1_555ff0df9be2e25dcc784bc7956dcfe7._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-29T23:34:24Z"
+ content="""
+When I wrote that, I was thinking of something more like, you have a clone of your repository
+on the server, and you run `git annex addurl` sshed into there. Then you
+can just run `git annex get` (or move) on the client later to download all the queued
+stuff.
+
+But, you can in fact tag files and operate on them like you're thinking of.
+
+	git annex metadata --tag later
+
+	git annex get --metadata tag=later
+"""]]
diff --git a/doc/forum/Clarification_in_usage_case/comment_2_8b43bc642656243cdf43cf77ae1c1851._comment b/doc/forum/Clarification_in_usage_case/comment_2_8b43bc642656243cdf43cf77ae1c1851._comment
new file mode 100644
index 0000000000..0519aab647
--- /dev/null
+++ b/doc/forum/Clarification_in_usage_case/comment_2_8b43bc642656243cdf43cf77ae1c1851._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="Nice!"
+ date="2018-10-30T22:14:43Z"
+ content="""
+I see what you mean about the `addurl`.
+Using tags is quite a clever method. Thank you. I'm not yet using metadata, but I plan to do so one of these days. git-annex keeps providing nice surprises.
+Thank you.
+"""]]
diff --git a/doc/forum/Clarifications_about_how_to_work_with_git-annex.mdwn b/doc/forum/Clarifications_about_how_to_work_with_git-annex.mdwn
new file mode 100644
index 0000000000..9f8943f00c
--- /dev/null
+++ b/doc/forum/Clarifications_about_how_to_work_with_git-annex.mdwn
@@ -0,0 +1,11 @@
+Hello. I am a kinda-new git-annex user. I think git-annex is very difficult to understand. Thus, in this topic, I would like to write out my explanation of how git-annex works and how I can work with it, so that you can tell me if I am misunderstanding something.
+
+I am a machine learning engineer. I use git-annex to store code together data (large images) and artefacts (large images and model weights). Basically, I am trying to use git-annex as normal git, but with the ability to store large binary files. There is a central bare repository and a bunch of non-bare repositories cloned from it on different computers. Usually, the non-bare repositories connect only to the central bare repository, but sometimes I push/fetch between non-bare repositories directly.
+
+I can fetch/push/merge/pull the normal branches I work in just as I do with normal git (without annex). However, the git-annexed files aren't fetched/pushed this way because the branch actually contains only symlinks, not the files themselves. I have disabled all the automatic mergin, pulling, etc. functionality of git because I like to have total control. So, I merge or rebase everything manually when there is a need for it. And I never use pull.
+
+In each repository, there is a branch called git-annex. It contains some metadata that git-annex uses. While in a repository repo1, I can do `git annex sync --only-annex --no-content --no-commit --no-pull --no-push --no-resolvemerge repo2` and git-annex will use some magic (consisting of pushing, pulling, and some kind of automatic merging) to sync the git-annex branch of repo1 and repo2, i.e. it will make them contain the same metadata. The options `--no-commit --no-pull --no-push --no-resolvemerge` are needed to disable the dark magic that is useful for casual users but not for software developers who use git-annex as a git addon. The option `--only-annex` prevents git-annex from creating "synced" branches which are, as far as I understand, another piece of dark magic useful for casual users but not for software developers. If I want, I can remove the `--no-content` flag and git-annex will also download and/or upload the annexed data (does it affect only the data available in the current branch? or is it all data? i'm not sure). This is the only command I need to know to sync the git-annex branch. Supposedly, it's possible to do via normal git fetches, pushes, merges, and maybe pulls, but I don't know how to do that.
+
+The actual annexed data is stored somewhere in the .git directory. I don't need to worry where. What I need to know is that I can use `git annex copy`, `git annex get`, and `git annex sync --only-annex --no-commit --no-pull --no-push --no-resolvemerge otherrepo` with appropriate paths to copy the annexed data between repositories.
+
+Ok, so I can use `git annex sync` with a bunch of flags to sync the git-annex branch, I can use `git annex sync`, `git annex get`, `git annex copy` to copy the data around, and I don't need the synced branches. Is my understanding correct?
diff --git a/doc/forum/Clarifications_about_how_to_work_with_git-annex/comment_1_7f9857887a25df617a99cdab119761d8._comment b/doc/forum/Clarifications_about_how_to_work_with_git-annex/comment_1_7f9857887a25df617a99cdab119761d8._comment
new file mode 100644
index 0000000000..0b826d6798
--- /dev/null
+++ b/doc/forum/Clarifications_about_how_to_work_with_git-annex/comment_1_7f9857887a25df617a99cdab119761d8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-04-17T18:04:26Z"
+ content="""
+Just `git pull` the git-annex branch from remotes yourself like any other
+git branch.
+
+git-annex will automatically merge those pulled git-annex branches into its
+own local git-annex branch the next time you run it.
+
+Then you can `git push` the git-annex branch to any remotes you want to
+publish updated git-annex information to.
+"""]]
diff --git a/doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode.mdwn b/doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode.mdwn
new file mode 100644
index 0000000000..f0912fd74a
--- /dev/null
+++ b/doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode.mdwn
@@ -0,0 +1,19 @@
+I recently began experimenting with direct mode on a repository where only a very limited number of commands (`git annex sync`, `git annex add .`, etc.) are being used (through desktop buttons).
+
+Things were working well, and then on another repository in indirect mode I moved a large folder and synced that data with a bare repo, and synced the repo in direct mode with the same bare repo (to get everything in sync).
+
+At that point, git annex seemed to hang, taking forever to complete, and from looking a processes and files it seemed like it was going nowhere, so I killed it. I wish I had done a bit more diagnostics before that, but unfortunately I didn't.
+
+At that point, I noticed that the old directory was still there and that there were still many files in it, but the new folder had also been created and there were files there, too. So I thought the transfer was done, and for whatever reason `git annex sync` had just not cleaned up properly.
+
+In fact, the sync was only half done and the remaining files in the old directory were the only (local) copies (on the direct mode repo). I removed them and then synced again, which actually told git to delete those symlinks.
+
+When I updated another (indirect mode) repository I noticed this, so I reverted the commit in question and got the symlinks back, no data lost. Then I went back to the direct mode repo, switched to indirect mode because I was worried about direct mode, `git annex sync`ed, then `git annex get` to get the files again from a usb and everything was back to normal.
+
+Except that when I tried to go back to direct mode in that original repo, I got an error saying that git could not stat a file which is in the old (deleted) folder. Searching around, I noticed that in the `.git/annex/objects` directory, there are many remaining `.map` files with lines referring to the old (deleted) directory.
+
+Is there any way to "reset" this somehow? I would like to switch back to direct mode, and I'd prefer not to recreate the repo.
+
+Oh and I'm using version: 4.20130501-g4a5bfb3.
+
+Thanks!
diff --git a/doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode/comment_1_3440b2e1662d3b113c18283afcbf4520._comment b/doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode/comment_1_3440b2e1662d3b113c18283afcbf4520._comment
new file mode 100644
index 0000000000..77c0ebbba6
--- /dev/null
+++ b/doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode/comment_1_3440b2e1662d3b113c18283afcbf4520._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnkBYpLu_NOj7Uq0-acvLgWhxF8AUEIJbo"
+ nickname="Chris"
+ subject="comment 1"
+ date="2013-05-10T03:50:26Z"
+ content="""
+Maybe a simpler question: if I delete all the `.map` and `.cache` files that are leftover in the `.git/annex/objects` directory, will that effectively \"reset\" the status so that I can then switch to direct mode?
+"""]]
diff --git a/doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode/comment_2_9a61ba8ac4a375f1d69cd09b5a6f8091._comment b/doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode/comment_2_9a61ba8ac4a375f1d69cd09b5a6f8091._comment
new file mode 100644
index 0000000000..e471f113ea
--- /dev/null
+++ b/doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode/comment_2_9a61ba8ac4a375f1d69cd09b5a6f8091._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnkBYpLu_NOj7Uq0-acvLgWhxF8AUEIJbo"
+ nickname="Chris"
+ subject="comment 2"
+ date="2013-05-10T04:01:38Z"
+ content="""
+After reading [this](http://git-annex.branchable.com/internals/):
+
+> Also in direct mode, some additional data is stored in these directories. .cache files contain cached file stats used in detecting when a file has changed, and .map files contain a list of file(s) in the work directory that contain the key.
+
+I decided that indeed, deleting the `.map` and `.cache` files should do the trick, so I deleted them and direct mode works again.
+
+Still not sure what went wrong with the original sync, but at least I got things back on track.
+"""]]
diff --git a/doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode/comment_3_6b9d8c48547f3d0a911310622ba91df7._comment b/doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode/comment_3_6b9d8c48547f3d0a911310622ba91df7._comment
new file mode 100644
index 0000000000..b7d495dea4
--- /dev/null
+++ b/doc/forum/Cleaning_up_after_aborted_sync_in_direct_mode/comment_3_6b9d8c48547f3d0a911310622ba91df7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-05-13T18:00:42Z"
+ content="""
+This sounds like one or more bugs that I should address, but I'm having trouble understanding exactly what you did, from your description, at the level of detail I need to replicate a problem.
+
+Do you still have a copy of the corrupted repository? Or any error messages to show me?
+
+It sounds like at least one problem might have been this bug: [[bugs/Unable_to_switch_back_to_direct_mode]]
+At least that is fixed in current git.
+"""]]
diff --git a/doc/forum/Combine_tags_in_view_branches.mdwn b/doc/forum/Combine_tags_in_view_branches.mdwn
new file mode 100644
index 0000000000..8dfb8208fc
--- /dev/null
+++ b/doc/forum/Combine_tags_in_view_branches.mdwn
@@ -0,0 +1,24 @@
+Is there a way to 'combine' tags in view branches? For example:
+
+```
+git annex view photos videos
+```
+
+produces a directory tree like so:
+
++ photos
+  - a.jpg
+  - b.jpg
+  - ...
++ videos
+  - a.mp4
+  - b.mp4
+  - ...
+
+Is there a way to achieve the following output?:
+
+- a.jpg
+- b.jpg
+- a.mp4
+- b.mp4
+- ...
diff --git a/doc/forum/Coming_from_git_world.mdwn b/doc/forum/Coming_from_git_world.mdwn
new file mode 100644
index 0000000000..ee8b844e81
--- /dev/null
+++ b/doc/forum/Coming_from_git_world.mdwn
@@ -0,0 +1,9 @@
+So i am coming from git world, All documentation and posts seemed to be for media etc. I have a simple question.
+
+Can i use git annex to manage large files , Which i think i can. But will it work with branching/tagging etc.
+
+e.g. We currently use git have some large files in git repo.... I am planning to move the large files to use annex. But would like to maintain branches, i.e. each branch might have different version of files and maybe tagged, So i can get back some old version from a branch.
+
+Is this possible ? I did not get any explicit  answer or examples on how this works or even if its supported.
+
+Also can i use same folder for git and git-annex ? 
diff --git a/doc/forum/Coming_from_git_world/comment_10_098bef38c2688607e869425a557cc482._comment b/doc/forum/Coming_from_git_world/comment_10_098bef38c2688607e869425a557cc482._comment
new file mode 100644
index 0000000000..85ba7fe7f0
--- /dev/null
+++ b/doc/forum/Coming_from_git_world/comment_10_098bef38c2688607e869425a557cc482._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 10"
+ date="2013-07-10T17:05:49Z"
+ content="""
+It has its own ssh server written in java too, which hardcodes the set of commands it supports. AFAICS it would require some java coding to add a command to this, it does not seem to be designed for easy extensability.
+"""]]
diff --git a/doc/forum/Coming_from_git_world/comment_11_98d75a1415e0c3689ab4231855e61233._comment b/doc/forum/Coming_from_git_world/comment_11_98d75a1415e0c3689ab4231855e61233._comment
new file mode 100644
index 0000000000..3dba0760b5
--- /dev/null
+++ b/doc/forum/Coming_from_git_world/comment_11_98d75a1415e0c3689ab4231855e61233._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn5RcmefXjrl1vmbHIiOWQyXGXVKxlm3rg"
+ nickname="Kavin"
+ subject="comment 11"
+ date="2013-07-10T20:14:52Z"
+ content="""
+:( Ahh... So i guess this might not be possible in near future.
+
+Ill go to plan B, Setup another server which users will connect to for large files which will have git-annex installed. (So a central Repository for git annex). They will need to add another remote in git config.
+
+Does git annex have a way to manage ssh keys ?  (Please can you point me to the location where i can read how git-annex-shell ? )
+"""]]
diff --git a/doc/forum/Coming_from_git_world/comment_12_5e7079e9bf3e4d97191333c66ac00e52._comment b/doc/forum/Coming_from_git_world/comment_12_5e7079e9bf3e4d97191333c66ac00e52._comment
new file mode 100644
index 0000000000..2d76687371
--- /dev/null
+++ b/doc/forum/Coming_from_git_world/comment_12_5e7079e9bf3e4d97191333c66ac00e52._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 12"
+ date="2013-07-10T21:10:03Z"
+ content="""
+Yes, a separate repository is one way to go, although I do not think it would be very hard to get gerrit's internal ssh to run git-annex-shell.
+
+[[git-annex-shell]] is a low-level restricted shell like git-shell, not a login manager, so it has nothing at all to do with ssh keys. Things like gitosis and gitolite can be built on top of git-shell and git-annex-shell and handle ssh key management.
+"""]]
diff --git a/doc/forum/Coming_from_git_world/comment_1_357443dc601ae38784c01cf18552f4d5._comment b/doc/forum/Coming_from_git_world/comment_1_357443dc601ae38784c01cf18552f4d5._comment
new file mode 100644
index 0000000000..adc65d50f2
--- /dev/null
+++ b/doc/forum/Coming_from_git_world/comment_1_357443dc601ae38784c01cf18552f4d5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 1"
+ date="2013-07-08T20:09:54Z"
+ content="""
+Yes, git-annex would not do very well at adding large file support to git if it did not handle tagging, branches, etc! So of course it does. It's in a sense too obvious a thing to get much mention. And so people sometimes get confused about it.
+
+The only thing to need to be aware of coming from git is that not every repository will have every version of every file locally available. When you check out a branch, you may need to run `git annex get` to retrieve those versions from origin or elsewhere.
+
+And, `git annex unused` can be used to find versions of files that no existing tag or branch refers to, and `git annex dropunused` can then delete those versions. If you want to ensure every revision in your git repo is accessible, you should avoid using those two commands; otherwise git-annex will never delete old versions of files.
+
+The unreleased git master adds a new feature, a --all switch that makes git annex commands operate on all versions of files. While normally `git annex get` will only do what it needs to to get all files in the currently checked out branch, `git annex get --all` will pull down every version of every file in the whole history. Similarly, `git annex copy --all --to origin` will ensure that every locally available version of every file is sent to origin.
+"""]]
diff --git a/doc/forum/Coming_from_git_world/comment_2_ed1847dd3f47a9d013b8dd0455fb80ff._comment b/doc/forum/Coming_from_git_world/comment_2_ed1847dd3f47a9d013b8dd0455fb80ff._comment
new file mode 100644
index 0000000000..33d7d44d35
--- /dev/null
+++ b/doc/forum/Coming_from_git_world/comment_2_ed1847dd3f47a9d013b8dd0455fb80ff._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 2"
+ date="2013-07-08T20:18:27Z"
+ content="""
+And yes, you can use the same git repository for files added to git `git add file` and added to git annex `git annex add file`
+"""]]
diff --git a/doc/forum/Coming_from_git_world/comment_3_09c6bb83a73d34dff2b8bc185a14a1db._comment b/doc/forum/Coming_from_git_world/comment_3_09c6bb83a73d34dff2b8bc185a14a1db._comment
new file mode 100644
index 0000000000..07023ffe3c
--- /dev/null
+++ b/doc/forum/Coming_from_git_world/comment_3_09c6bb83a73d34dff2b8bc185a14a1db._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn5RcmefXjrl1vmbHIiOWQyXGXVKxlm3rg"
+ nickname="Kavin"
+ subject="comment 3"
+ date="2013-07-08T23:27:45Z"
+ content="""
+Awesome!! thanks, As i am kicking the tires, Based on my current scenario, How can i deploy this in my company , So each developer to do the bare minimum, Like just install git annex and it should work.
+
+i.e. is it possible to avoid the step git remote add backup ? Then they can just do
+
+$ yum install git-annex
+$ cd repo
+$ git checkout staging
+$ git pull
+$ git annex get large_file
+
+And it then just works.
+"""]]
diff --git a/doc/forum/Coming_from_git_world/comment_4_6c731bb9a8d21dd9ab8c09612b23f908._comment b/doc/forum/Coming_from_git_world/comment_4_6c731bb9a8d21dd9ab8c09612b23f908._comment
new file mode 100644
index 0000000000..f09281bc45
--- /dev/null
+++ b/doc/forum/Coming_from_git_world/comment_4_6c731bb9a8d21dd9ab8c09612b23f908._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 4"
+ date="2013-07-09T18:14:07Z"
+ content="""
+I don't know where you got the \"git remote add backup\" step from. Obviously this is not necessary unless you want to add a remote named \"backup\".
+
+To use git-annex in a centralized git environment, which it sounds like you have here, you just need to install git-annex on the central git server, and arrange for all the developers to have ssh access to it. Then any git repository that is cloned from that server using ssh as the transport can support git-annex without the user needing to do anything special to set it up.
+
+This assumes that users have shell accounts on the server. git-annex includes the git-annex-shell program, which is similar to the git-shell in git. User accounts can be locked down to use this restricted shell if giving them full shell access to the server is not desired.
+
+If the server is using a git repository manager like gitolite or gitosis, those can also be adapted to use git-annex-shell. I got gitolite patched to support it earlier, see [[tips/using_gitolite_with_git-annex]].
+
+PS: I'm available for consulting on deploying git-annex in production environments. ;)
+"""]]
diff --git a/doc/forum/Coming_from_git_world/comment_5_e719d99af5afd90da3d3db692eff28dc._comment b/doc/forum/Coming_from_git_world/comment_5_e719d99af5afd90da3d3db692eff28dc._comment
new file mode 100644
index 0000000000..ffeaaa6e06
--- /dev/null
+++ b/doc/forum/Coming_from_git_world/comment_5_e719d99af5afd90da3d3db692eff28dc._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn5RcmefXjrl1vmbHIiOWQyXGXVKxlm3rg"
+ nickname="Kavin"
+ subject="comment 5"
+ date="2013-07-09T20:32:51Z"
+ content="""
+Thank you very much!!!!! Yes, Planning to use Centralized repo. Basically what i understood was there will be a git server and separate server for hosting the large files. Its great to know i can use the same server and do not need to explicitly point to the server.
+
+As we are using Gerrit, What is the general best practice for it. (After i am done with it, I will write a blog post, As i am sure many people with centralized repo's might need this)  
+Thanks! 
+"""]]
diff --git a/doc/forum/Coming_from_git_world/comment_6_85a42106944dba9995fb3f4bfee3443a._comment b/doc/forum/Coming_from_git_world/comment_6_85a42106944dba9995fb3f4bfee3443a._comment
new file mode 100644
index 0000000000..840553025e
--- /dev/null
+++ b/doc/forum/Coming_from_git_world/comment_6_85a42106944dba9995fb3f4bfee3443a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 6"
+ date="2013-07-09T20:39:25Z"
+ content="""
+Yes, the default for a repository accessed using ssh is to also store the large files in that repository. Of course you can set up a second remote to hold the large files if that works better.
+
+I don't have any personal experience with Gerrit. All I can say is that files managed by git-annex will appear as symlinks.
+"""]]
diff --git a/doc/forum/Coming_from_git_world/comment_7_90623294b910ceca3dc8ebd41b50fc9b._comment b/doc/forum/Coming_from_git_world/comment_7_90623294b910ceca3dc8ebd41b50fc9b._comment
new file mode 100644
index 0000000000..50b34fb86d
--- /dev/null
+++ b/doc/forum/Coming_from_git_world/comment_7_90623294b910ceca3dc8ebd41b50fc9b._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn5RcmefXjrl1vmbHIiOWQyXGXVKxlm3rg"
+ nickname="Kavin"
+ subject="comment 7"
+ date="2013-07-09T23:48:17Z"
+ content="""
+Thanks, So i made some progress, In the gerrit repo server,  (which has git-annex installed)
+
+I ran: 
+    git annex init origin,
+
+Did a clone of the repo, it had the branch git-annex, So i assumed all is working.
+
+I did a 
+    git annex add 
+and 
+    git push
+
+Then when i try to 
+    git annex copy --to origin
+
+I get error , But git-annex-shell is installed on the machine:
+
+    $ echo $PATH
+    /usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/gerrit2/bin
+    $ which git-annex-shell
+    /usr/bin/git-annex-shell
+
+
+
+    Gerrit Code Review: git-annex-shell: not found
+    rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+    rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]
+    
+    rsync failed -- run git annex again to resume file transfer failed
+    
+Any idea what i  need to do to make it work ?
+"""]]
diff --git a/doc/forum/Coming_from_git_world/comment_8_28dbee30eb54877418f72eb8935302d8._comment b/doc/forum/Coming_from_git_world/comment_8_28dbee30eb54877418f72eb8935302d8._comment
new file mode 100644
index 0000000000..668cfbd95a
--- /dev/null
+++ b/doc/forum/Coming_from_git_world/comment_8_28dbee30eb54877418f72eb8935302d8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 8"
+ date="2013-07-10T16:42:18Z"
+ content="""
+If gerrit is handling incoming ssh connections, it's probable running its own restricted shell. That shell would need to be configured to spawn git-annex-shell when asked to do so in order for git-annex to transfer files to that repository.
+"""]]
diff --git a/doc/forum/Coming_from_git_world/comment_9_6edb36ea9535030fa3766937398e5bc7._comment b/doc/forum/Coming_from_git_world/comment_9_6edb36ea9535030fa3766937398e5bc7._comment
new file mode 100644
index 0000000000..2f1034d173
--- /dev/null
+++ b/doc/forum/Coming_from_git_world/comment_9_6edb36ea9535030fa3766937398e5bc7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 9"
+ date="2013-07-10T16:57:29Z"
+ content="""
+AFAIK Gerrit relies on jgit implementation of git in java; allowing it to execute helper programs like git-annex-shell may be tricky.
+"""]]
diff --git a/doc/forum/Comparison_with_other_big_files_solutions.mdwn b/doc/forum/Comparison_with_other_big_files_solutions.mdwn
new file mode 100644
index 0000000000..cfbd12d29b
--- /dev/null
+++ b/doc/forum/Comparison_with_other_big_files_solutions.mdwn
@@ -0,0 +1,11 @@
+# Comparison
+
+Based on my understanding of the http://git-annex.branchable.com/not/ page and of some research,
+I have made a draft of an [Online excel document][1] that compares different git file solutions.
+
+Feel free to edit the document and help the community to understand the different solutions out there.
+
+[1]: https://onedrive.live.com/redir?resid=C66C90783BD2C185!1200&authkey=!ACF-Ol_mG3DwQ2k&ithint=file%2c.xlsx
+
+Thank you very much,
+Alex
diff --git a/doc/forum/Compile_Problem_with_latest_git_pull_version.mdwn b/doc/forum/Compile_Problem_with_latest_git_pull_version.mdwn
new file mode 100644
index 0000000000..761615a3e7
--- /dev/null
+++ b/doc/forum/Compile_Problem_with_latest_git_pull_version.mdwn
@@ -0,0 +1,23 @@
+Hi,
+I try to compile the latest version of git annex on my server; 
+As you can see some package (WARP) failed to install : 
+
+    [root@git-annex]$ cat /home/reyman64/.cabal/logs/warp-3.1.11.log
+    Configuring warp-3.1.11...
+    Building warp-3.1.11...
+    Preprocessing library warp-3.1.11...
+    [ 1 of 35] Compiling Network.Wai.Handler.Warp.Windows ( Network/Wai/Handler/Warp/Windows.hs, dist/build/Network/Wai/Handler/Warp/Windows.o )
+    [ 2 of 35] Compiling Paths_warp       ( dist/build/autogen/Paths_warp.hs, dist/build/Paths_warp.o )
+    [ 3 of 35] Compiling Network.Wai.Handler.Warp.ReadInt ( Network/Wai/Handler/Warp/ReadInt.hs, dist/build/Network/Wai/Handler/Warp/ReadInt.o )
+    [ 4 of 35] Compiling Network.Wai.Handler.Warp.HTTP2.EncodeFrame ( Network/Wai/Handler/Warp/HTTP2/EncodeFrame.hs, dist/build/Network/Wai/Handler/Warp/HTTP2/EncodeFrame.o )
+    [ 5 of 35] Compiling Network.Wai.Handler.Warp.MultiMap ( Network/Wai/Handler/Warp/MultiMap.hs, dist/build/Network/Wai/Handler/Warp/MultiMap.o )
+    [ 6 of 35] Compiling Network.Wai.Handler.Warp.IORef ( Network/Wai/Handler/Warp/IORef.hs, dist/build/Network/Wai/Handler/Warp/IORef.o )
+    [ 7 of 35] Compiling Network.Wai.Handler.Warp.HTTP2.Manager ( Network/Wai/Handler/Warp/HTTP2/Manager.hs, dist/build/Network/Wai/Handler/Warp/HTTP2/Manager.o )
+    [ 8 of 35] Compiling Network.Wai.Handler.Warp.Counter ( Network/Wai/Handler/Warp/Counter.hs, dist/build/Network/Wai/Handler/Warp/Counter.o )
+    [ 9 of 35] Compiling Network.Wai.Handler.Warp.FileInfoCache ( Network/Wai/Handler/Warp/FileInfoCache.hs, dist/build/Network/Wai/Handler/Warp/FileInfoCache.o )
+    [10 of 35] Compiling Network.Wai.Handler.Warp.Timeout ( Network/Wai/Handler/Warp/Timeout.hs, dist/build/Network/Wai/Handler/Warp/Timeout.o )
+
+    Network/Wai/Handler/Warp/Timeout.hs:86:15:
+        Not in scope: ‘reaperKill’
+        Perhaps you meant ‘reaperNull’ (imported from Control.Reaper)
+
diff --git a/doc/forum/Compile_Problem_with_latest_git_pull_version/comment_1_0b87183756e860d93b8c0197bac3c0b1._comment b/doc/forum/Compile_Problem_with_latest_git_pull_version/comment_1_0b87183756e860d93b8c0197bac3c0b1._comment
new file mode 100644
index 0000000000..e95b87357b
--- /dev/null
+++ b/doc/forum/Compile_Problem_with_latest_git_pull_version/comment_1_0b87183756e860d93b8c0197bac3c0b1._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="reyman64@740e43250854ada1b8484b3bc44b53be03367d70"
+ nickname="reyman64"
+ subject="comment 1"
+ date="2016-01-21T18:21:42Z"
+ content="""
+I think the problem arise here, with the auto-update version : 
+
+--dependency=auto-update=auto-update-0.1.2.2-082ccf928dc1747301e11c3fe47c54fa
+
+You need 0.1.3 to solve problem
+
+https://github.com/yesodweb/wai/issues/495
+
+Waiting for new commit :)
+"""]]
diff --git a/doc/forum/Compile_Problem_with_latest_git_pull_version/comment_2_1dd40ce31bcf994656fdfee7f8af43d2._comment b/doc/forum/Compile_Problem_with_latest_git_pull_version/comment_2_1dd40ce31bcf994656fdfee7f8af43d2._comment
new file mode 100644
index 0000000000..e006d86e83
--- /dev/null
+++ b/doc/forum/Compile_Problem_with_latest_git_pull_version/comment_2_1dd40ce31bcf994656fdfee7f8af43d2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-01-22T15:53:52Z"
+ content="""
+The best way to avoid these kind of transient problems building
+dependencies is to use stack to build from source.
+"""]]
diff --git a/doc/forum/Compile_Problem_with_latest_git_pull_version/comment_3_f8e52610a592c68f9bc733bd31fa9659._comment b/doc/forum/Compile_Problem_with_latest_git_pull_version/comment_3_f8e52610a592c68f9bc733bd31fa9659._comment
new file mode 100644
index 0000000000..c029d967ee
--- /dev/null
+++ b/doc/forum/Compile_Problem_with_latest_git_pull_version/comment_3_f8e52610a592c68f9bc733bd31fa9659._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="reyman64@740e43250854ada1b8484b3bc44b53be03367d70"
+ nickname="reyman64"
+ subject="comment 3"
+ date="2016-01-22T22:12:24Z"
+ content="""
+You're right, works much much better with stack.
+
+If other user are interested, i create a tutorial here to install cabal / stack on : [webfaction hosting](https://community.webfaction.com/questions/19167/install-haskell-ghc-and-cabal-from-source-on-webfaction) After stack install, compiling git-annex is very easy (compared to cabal instal ....)
+"""]]
diff --git a/doc/forum/Compression_in_special_remotes___40__specifically_S3__41____63__.mdwn b/doc/forum/Compression_in_special_remotes___40__specifically_S3__41____63__.mdwn
new file mode 100644
index 0000000000..49f3d75ef3
--- /dev/null
+++ b/doc/forum/Compression_in_special_remotes___40__specifically_S3__41____63__.mdwn
@@ -0,0 +1 @@
+I use git-annex mostly to archive my photos.  They're generally large raw files and I am encrypting them going to the S3 special remote.  Are there any plans to compress objects before encrypting them?  It would save on S3 costs, only add some overhead on get and copy, and I don't think there would be any problems looking up data later.
diff --git a/doc/forum/Compression_in_special_remotes___40__specifically_S3__41____63__/comment_1_9c6c4ca0c9dc6976ba7cf27e84683bf0._comment b/doc/forum/Compression_in_special_remotes___40__specifically_S3__41____63__/comment_1_9c6c4ca0c9dc6976ba7cf27e84683bf0._comment
new file mode 100644
index 0000000000..7c5f1ecc1d
--- /dev/null
+++ b/doc/forum/Compression_in_special_remotes___40__specifically_S3__41____63__/comment_1_9c6c4ca0c9dc6976ba7cf27e84683bf0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.117"
+ subject="comment 1"
+ date="2012-12-14T18:53:04Z"
+ content="""
+gpg compresses encrypted content by default, so all encrypted special remotes get compression for free
+"""]]
diff --git a/doc/forum/Confusion_about_Webapp___40__on_OSX__41__.mdwn b/doc/forum/Confusion_about_Webapp___40__on_OSX__41__.mdwn
new file mode 100644
index 0000000000..a34d5cbc61
--- /dev/null
+++ b/doc/forum/Confusion_about_Webapp___40__on_OSX__41__.mdwn
@@ -0,0 +1,9 @@
+I am confused on how to invoke the web app. I am learning how to use this tool, however I don't feel quite confident yet. I wanted to test out the web app, to play around with configurations and auto syncing, however I stumbled over this:
+
+    ➜  ~  git annex help webapp // works fine
+    ➜  ~  git annex webapp
+    Invalid argument `webapp' // uhh what.
+
+git-annex-webapp didn't work either.
+
+I installed with brew. El Capitan, latest update as of right now.
diff --git a/doc/forum/Confusion_about_Webapp___40__on_OSX__41__/comment_1_868b326cc5eb0767390ffdf45a594cff._comment b/doc/forum/Confusion_about_Webapp___40__on_OSX__41__/comment_1_868b326cc5eb0767390ffdf45a594cff._comment
new file mode 100644
index 0000000000..ed288634ec
--- /dev/null
+++ b/doc/forum/Confusion_about_Webapp___40__on_OSX__41__/comment_1_868b326cc5eb0767390ffdf45a594cff._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-11-30T20:13:39Z"
+ content="""
+git-annex can be built with or without support for the webapp. I suppose
+that your brew install is of the latter variety. For a build with the
+webappp included: <http://git-annex.branchable.com/install/OSX/> (or ask
+the brew developers to include the webapp in their build)
+"""]]
diff --git a/doc/forum/Confusion_about_Webapp___40__on_OSX__41__/comment_2_9b38b92d584395e5468bed03395c927f._comment b/doc/forum/Confusion_about_Webapp___40__on_OSX__41__/comment_2_9b38b92d584395e5468bed03395c927f._comment
new file mode 100644
index 0000000000..5b00be7ff1
--- /dev/null
+++ b/doc/forum/Confusion_about_Webapp___40__on_OSX__41__/comment_2_9b38b92d584395e5468bed03395c927f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="oliverconzen@8cff8c5ab3868de177f748566f90c79720f9cf4b"
+ nickname="oliverconzen"
+ subject="comment 2"
+ date="2016-01-08T19:21:28Z"
+ content="""
+After revisiting this issue the guys over at Homebrew have no idea whats going on apparently. The build process seems to be fairly complicated although obviously automated by cabal. The feature just seemed to went missing and nobody has an idea where to search. I am currently compiling from source and fairly confident that I will get it working.
+
+Since not everyone has the time to deal with this in their freetime, and brew is pretty much done to to this kind of thing automagically, maybe it is worth checking with them what went wrong.
+
+<https://github.com/Homebrew/homebrew/search?q=git+annex+webapp&type=Issues&utf8=%E2%9C%93> reveals two issues about the webapp and S3 features disappearing in between updates with no changes to the formula.
+"""]]
diff --git a/doc/forum/Confusion_about_Webapp___40__on_OSX__41__/comment_3_7d790a158b7c22206b0b523a4227bacb._comment b/doc/forum/Confusion_about_Webapp___40__on_OSX__41__/comment_3_7d790a158b7c22206b0b523a4227bacb._comment
new file mode 100644
index 0000000000..72643f0232
--- /dev/null
+++ b/doc/forum/Confusion_about_Webapp___40__on_OSX__41__/comment_3_7d790a158b7c22206b0b523a4227bacb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-01-11T16:32:47Z"
+ content="""
+Seems to have been resolved in brew by forcing the Webapp flag, which I
+think is the right solution.
+"""]]
diff --git a/doc/forum/Consistency_Check_for_S3.mdwn b/doc/forum/Consistency_Check_for_S3.mdwn
new file mode 100644
index 0000000000..0c06f86090
--- /dev/null
+++ b/doc/forum/Consistency_Check_for_S3.mdwn
@@ -0,0 +1 @@
+Wepapp only allows me to setup consistency checks for the local repo. Non of my computers has full copy of repos. How can I setup annex so that every night for one hour it checks consistency of s3 data?
diff --git a/doc/forum/Consistency_Check_for_S3/comment_1_40385806ef1cc082232cd2723a24be1a._comment b/doc/forum/Consistency_Check_for_S3/comment_1_40385806ef1cc082232cd2723a24be1a._comment
new file mode 100644
index 0000000000..a641ded34d
--- /dev/null
+++ b/doc/forum/Consistency_Check_for_S3/comment_1_40385806ef1cc082232cd2723a24be1a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2013-12-31T19:30:00Z"
+ content="""
+The webapp does not let you set up a consistency check for data in a S3 remote because the only way to check it would be to download the data, which is expensive in bandwidth and potentially, Amazon S3 fees.
+"""]]
diff --git a/doc/forum/Consistency_Check_for_S3/comment_2_ebfe40d9f777c9c0a83c44afd0f5802d._comment b/doc/forum/Consistency_Check_for_S3/comment_2_ebfe40d9f777c9c0a83c44afd0f5802d._comment
new file mode 100644
index 0000000000..d78a1dc52d
--- /dev/null
+++ b/doc/forum/Consistency_Check_for_S3/comment_2_ebfe40d9f777c9c0a83c44afd0f5802d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 2"
+ date="2014-01-01T01:50:57Z"
+ content="""
+Is it possible to do it from command line? I was thinking with a time limit I would spread the fsck over a mount run it once a while to make sure all data is actually there when I need it. 
+"""]]
diff --git a/doc/forum/Consistency_Check_for_S3/comment_3_ec9de6882a0eef4d2786e55b583ad020._comment b/doc/forum/Consistency_Check_for_S3/comment_3_ec9de6882a0eef4d2786e55b583ad020._comment
new file mode 100644
index 0000000000..e0e68fe6df
--- /dev/null
+++ b/doc/forum/Consistency_Check_for_S3/comment_3_ec9de6882a0eef4d2786e55b583ad020._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 3"
+ date="2014-01-01T21:05:20Z"
+ content="""
+Adapting an example from the man page:
+
+`git annex fsck --incremental-schedule 30d --time-limit 1h --from S3`
+"""]]
diff --git a/doc/forum/Content-sensitive_chunking__63__.mdwn b/doc/forum/Content-sensitive_chunking__63__.mdwn
new file mode 100644
index 0000000000..97c3c7cd19
--- /dev/null
+++ b/doc/forum/Content-sensitive_chunking__63__.mdwn
@@ -0,0 +1,9 @@
+Bup, ddar, and borg all use content-sensitive chunking, but git and git-annex do not. Git uses delta compression with heuristics for finding similar files, while with git-annex, deduplication beyond only storing one copy of identical content is only possible in special remotes because of how it works. Anyway, I'm posting this here not because I think git-annex should directly support content-sensitive chunking but because it's an idea I can't get out of my head and I think there are likely to be people in this group who are interested in it.
+
+With content-sensitive chunking, there's always a trade-off between chunk size and deduplication. Bigger chunks mean more duplication, while smaller chunks mean more overhead for storing the chunks themselves. Even if chunks are concatenated into larger files to minimize filesystem overhead, you still have to store a collision-resistant hash of each chunk. My idea is this: because you have the chunks available, you can always recompute the hash if you need to. So instead of indexing on the full hash, index on only part of it, and identify the chunks themselves using base 128 integer IDs instead.
+
+Given that you're only ever looking up the hash of a chunk in order to decide if you need to store a new chunk, one possible approach is to use a trie with only enough bytes of the hash to make it unique in a given repository. Then, any time there's a false collision, add enough additional bytes to make it unique in the presence of the new chunk. Use a cache to avoid repeated hashing of commonly matched chunks.
+
+One problem with this technique is that the per-chunk overhead increases with the number of chunks, but it's logarithmic, so it grows slowly, and for many types of content the savings from increased deduplication should grow similarly. For a trie the average number of hash bytes stored would be the base 256 log of the number of chunks, so 2 bytes for up to 65536 chunks, 3 for up to 16.8 million chunks, 4 for up to 4 billion, etc. The space needed to store the chunk IDs is the same, but you store the ID for each time the chunk is used.
+
+It occurs to me that I should propose this to the Datashards folks :)
diff --git a/doc/forum/Content_branch.mdwn b/doc/forum/Content_branch.mdwn
new file mode 100644
index 0000000000..6eb268eade
--- /dev/null
+++ b/doc/forum/Content_branch.mdwn
@@ -0,0 +1,5 @@
+I was not able to find a convenient way to _only_ see locally available files.
+
+Is there a command to create a branch that only contain files taht are present locally, or is there another way to get a "locally available view" ?
+
+Thanks. 
diff --git a/doc/forum/Content_branch/comment_1_564724cb1508524700b71950b81a5058._comment b/doc/forum/Content_branch/comment_1_564724cb1508524700b71950b81a5058._comment
new file mode 100644
index 0000000000..e843b343fc
--- /dev/null
+++ b/doc/forum/Content_branch/comment_1_564724cb1508524700b71950b81a5058._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jd.schroeder@0c8632a8f2bffdd4b0de05a0a3660f32acdfeeca"
+ nickname="jd.schroeder"
+ subject="comment 1"
+ date="2016-07-29T19:12:24Z"
+ content="""
+I'm not sure about creating a branch, but I use [[https://git-annex.branchable.com/git-annex-find/]] to list locally available files.
+
+Good luck!
+"""]]
diff --git a/doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it.mdwn b/doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it.mdwn
new file mode 100644
index 0000000000..87abccd30f
--- /dev/null
+++ b/doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it.mdwn
@@ -0,0 +1,7 @@
+Looking for some guidance as I'm not currently producing any error messages to guide me.  I keep a copy of an annex on my laptop and on two separate external hard drives such that each hard drive holds all the content of the annex.  However, there are files with content on drive 2, which I can't get onto drive 1.  When I run $git annex get .  or $git annex sync "drive2" --content  the content of the files is not transferred, not even attempted.  My impression is that git annex believes the content is already present, but is somehow disconnected from whatever is showing in the repository.   
+
+
+I don't know if this is relevant or not, but I recently transitioned from running windows to linux.  During that process I was getting pre-commit hook errors.  Following advice from online, I deleted .git/hooks/pre-commit to (presumably) regenerate those hooks.  I also got a post-merge hook error just before the behavior above started happening.  However, I'm unable to produce that error now.  The only thing I could find online about the post-merge error was here https://stackoverflow.com/questions/3563904/git-hook-post-merge-error-cannot-run which seems relevant, but I wasn't able to make out what I need to do to resolve my issue.  
+
+Any help will be appreciated. Thanks!
+
diff --git a/doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it/comment_1_55e676477623db9e26e871d7189a1a88._comment b/doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it/comment_1_55e676477623db9e26e871d7189a1a88._comment
new file mode 100644
index 0000000000..ede6bd68dd
--- /dev/null
+++ b/doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it/comment_1_55e676477623db9e26e871d7189a1a88._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-01T17:28:29Z"
+ content="""
+What version of git-annex are you using?
+
+I suggest you run "git-annex fsck" passing it the name of the file your are
+having problems with. Show what, if anything, it outputs.
+"""]]
diff --git a/doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it/comment_2_cb404061683de3bfd5c24ce7e5ee6b82._comment b/doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it/comment_2_cb404061683de3bfd5c24ce7e5ee6b82._comment
new file mode 100644
index 0000000000..0036857263
--- /dev/null
+++ b/doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it/comment_2_cb404061683de3bfd5c24ce7e5ee6b82._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jwrauch"
+ avatar="http://cdn.libravatar.org/avatar/0e83010187ef0c8c587e0c99e2ca5474"
+ subject="comment 2"
+ date="2022-02-02T20:48:56Z"
+ content="""
+Hi, thanks! That was just what I was looking for.  I haven't had to use that command before but it looks pretty useful.  I ended up running on the entire annex and found files that needed \"fixing\" I wasn't even aware of. Do you recommend periodically running this just to make sure everything checks out, or should I only run it when I discover a problem?  
+
+For some of the files, it claims that no known copies exist and there is not .git/annex/bad directory.  Is that game over for those files? (Only a handful, so not the end of the world, but would be nice to recover them.)
+"""]]
diff --git a/doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it/comment_3_74055eed54696331af07ba1721055562._comment b/doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it/comment_3_74055eed54696331af07ba1721055562._comment
new file mode 100644
index 0000000000..60643a3815
--- /dev/null
+++ b/doc/forum/Content_not_present_and_get_doesn__39__t_retrieve_it/comment_3_74055eed54696331af07ba1721055562._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-02-07T16:28:49Z"
+ content="""
+You should not need to fsck regularly. The question is, what happened to
+make those files that git-annex thinks are present go missing. One
+possible way would be if there was an actual data corruption of files on
+the drive.
+
+`git-annex fsck` only mentions `.git/annex/bad/` when it discovers that a
+file's content on disk has gotten corrupted. It then moves it to that
+directory, and mentions that it has. So this makes me think your drive must
+have data corruption. This is only a guess, since you unfortunately did not
+paste the output, like I asked for..
+"""]]
diff --git a/doc/forum/Controlling_content_on_mobile_device.mdwn b/doc/forum/Controlling_content_on_mobile_device.mdwn
new file mode 100644
index 0000000000..b1f145ccb2
--- /dev/null
+++ b/doc/forum/Controlling_content_on_mobile_device.mdwn
@@ -0,0 +1,46 @@
+I have some questions about how to best manage content on mobile
+devices.  This is probably more of a wishlist discussion, although I
+haven't had enough experience with the assistant and preferred content
+features enough to know how much of this might already be possible.
+
+(While I did donate to both campaigns, I also didn't donate at the
+"personal git-annex assistant" level, so I also know not to expect
+personal undivided attention :) . Any tips would be appreciated.)
+
+In short, I don't think git-annex really fits with how I'd like to use
+it on my Android phone.  My current setup is as follows:
+
+- I have a large repository with various media files.  This is stored
+  on several computers, at least one of which generally has a copy of
+  everything.  I use a centralized bare repo to automatically
+  synchronize between computers with "`git annex sync origin`" using
+  cron, and manually control what is on each one using "`copy --to
+  host`", "`get`", "`drop`", etc.  It is *awesome*.
+
+What I would like for Android is:
+
+- The phone keeps in sync with the origin repository.
+
+- On the phone, I'd like to browse through and choose content to get
+  or drop.  I could use the command-line "`get`" and "`drop`" for
+  this, of course, but being able to do it through the webapp would be
+  better, as typing on a phone is no fun.
+
+- From _off_ the phone, I'd like to be able to choose which content
+  should be _on_ the phone.  For example, using the command line or
+  webapp on my desktop, I'd like to be able to choose media files that
+  should be downloaded to (or removed from) the phone.  However, I
+  don't want to have to move files between directories in the repository
+  to achieve this.
+
+- The only useful content that gets created on the phone is photos and
+  videos.  Those should get uploaded to the main server, but only the
+  most recent files should remain on the phone by default (say,
+  anything older than 2 weeks gets dropped).  Both on the phone, and
+  off the phone, I'd be able to override that using the previously
+  described features, so that certain photos remain on the phone
+  forever, or get dropped earlier.
+
+Thoughts?  I feel like git-annex is close to being able to do this.
+
+-jim
diff --git a/doc/forum/Controlling_content_on_mobile_device/comment_1_708649b7f30d8619d7b34dcb0ef46515._comment b/doc/forum/Controlling_content_on_mobile_device/comment_1_708649b7f30d8619d7b34dcb0ef46515._comment
new file mode 100644
index 0000000000..c9cbc9e79c
--- /dev/null
+++ b/doc/forum/Controlling_content_on_mobile_device/comment_1_708649b7f30d8619d7b34dcb0ef46515._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl_EUsflI4UOGtx0-2yrRJuGAzNyN_5UYY"
+ nickname="Chris"
+ subject="comment 1"
+ date="2014-01-03T16:33:51Z"
+ content="""
+Jim,
+
+I have nothing in terms of a solution, but wanted to say thanks for writing this up.  This describes precisely the use case I am also seeking on my Android phone.
+
+-- Chris
+"""]]
diff --git a/doc/forum/Controlling_content_on_mobile_device/comment_2_dba1a1b0917332a1dee387b1183bd2cb._comment b/doc/forum/Controlling_content_on_mobile_device/comment_2_dba1a1b0917332a1dee387b1183bd2cb._comment
new file mode 100644
index 0000000000..60aea0bdda
--- /dev/null
+++ b/doc/forum/Controlling_content_on_mobile_device/comment_2_dba1a1b0917332a1dee387b1183bd2cb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"
+ nickname="Jim"
+ subject="Metadata?"
+ date="2014-02-21T18:44:10Z"
+ content="""
+I suspect the new [metadata](http://git-annex.branchable.com/design/metadata/) support could be used to help implement this.
+"""]]
diff --git a/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo.mdwn b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo.mdwn
new file mode 100644
index 0000000000..c941725356
--- /dev/null
+++ b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo.mdwn
@@ -0,0 +1 @@
+Is it possible to convert a regular git annex repo (git clone then git annex init in the folder), to an rsync remote. I have an annex with alot of remotes which makes the sync operation take a really long time. I would like to convert some of those remotes to rsync. This particular repo has a TB of data so I would like to avoid dropping content from the remote than re download everything.
diff --git a/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_1_e6065f9c44c85030c7628e2cfa0fd0fa._comment b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_1_e6065f9c44c85030c7628e2cfa0fd0fa._comment
new file mode 100644
index 0000000000..46ba67c302
--- /dev/null
+++ b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_1_e6065f9c44c85030c7628e2cfa0fd0fa._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 1"
+ date="2014-02-23T18:57:42Z"
+ content="""
+This is doable. It works best if the remote repo is a bare git repository, because then the filenames line up 100% with the filenames used in a rsync special remote. If the git repo is not bare, the rsync special remote will first try the paths it expects, and only then fall back to the right paths, so a little extra work done. (If this became a big problem, it would not be infesable to move the files around with a script.)
+
+Anyway, if it's a bare repo, then repo.git/annex/objects is where you want to point the rsync special remote at. With a non-bare repo, repo/.git/annex/objects/ is the location. I'd recommend moving the objects directory out to a new location, and pointing the rsyncurl at that. This way, there's no possibility of git-annex thinking one files accessed 2 ways is 2 copies.
+
+Of course, you can't use encryption for the rsync special remote.
+"""]]
diff --git a/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_2_76bfb11396dc20a5105376b22e7e773b._comment b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_2_76bfb11396dc20a5105376b22e7e773b._comment
new file mode 100644
index 0000000000..8ed4f65081
--- /dev/null
+++ b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_2_76bfb11396dc20a5105376b22e7e773b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 2"
+ date="2014-02-23T19:07:59Z"
+ content="""
+However, if the only problem is that pushing and pulling with a git repository makes `git annex sync` take too long, another option is setting `git config remote.$foo.annex-sync false`. You can still then use git-annex commands to get and push data to the remote, and can even `git annex sync $foo` from time to time, but it won't slow down the normal `git annex sync`.
+
+However, this also prevents the assistant from uploading new files to the remote automatically.
+"""]]
diff --git a/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_3_b34d6ae0718ab0ff6bc1d7b8f2470b9b._comment b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_3_b34d6ae0718ab0ff6bc1d7b8f2470b9b._comment
new file mode 100644
index 0000000000..a8040cd3fe
--- /dev/null
+++ b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_3_b34d6ae0718ab0ff6bc1d7b8f2470b9b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 3"
+ date="2014-02-23T19:39:28Z"
+ content="""
+Thanks for the reply, just to make sure I got you right,
+
+It is indeed a non bare git repo. So I will move the folder repo/.git/annex/objects/ to repo/
+
+then run,
+
+git annex initremote myrsync type=rsync rsyncurl=ssh.example.com:~/repo
+
+and enable the remote on other annexes (disks are connected to an ssh server there is no encryption setup right now so I do not mind not having it.). And everything should be setup correctly.
+"""]]
diff --git a/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_4_8f5e323b29745591f9f2f0f867353f69._comment b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_4_8f5e323b29745591f9f2f0f867353f69._comment
new file mode 100644
index 0000000000..c8305aaa92
--- /dev/null
+++ b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_4_8f5e323b29745591f9f2f0f867353f69._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 4"
+ date="2014-02-23T19:45:09Z"
+ content="""
+and as a follow up do I have rename the repos or can I reuse the same names for the repos?
+"""]]
diff --git a/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_5_9824c953694770afa0611ff7276737bf._comment b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_5_9824c953694770afa0611ff7276737bf._comment
new file mode 100644
index 0000000000..c6052232b8
--- /dev/null
+++ b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_5_9824c953694770afa0611ff7276737bf._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 5"
+ date="2014-02-24T19:07:33Z"
+ content="""
+That looks all-right, although initremote will ask you to tell it what encryption to use, and you'll need to specify `encryption=none`
+
+One thing I forgot to mention is that the UUID of the new rsync repository won't be the same, so git-annex won't know about the files in there. This can be fixed by `git annex fsck --fast --from myrsync`. Which doesn't re-download all the files, but you still may want to run it on a repository close to or on the server for speed.
+
+You can re-use the name you're currently using for the git remote for the new rsync special remote if you like.
+"""]]
diff --git a/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_6_5899741cb7f83e1b22c5ee3509c5ff21._comment b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_6_5899741cb7f83e1b22c5ee3509c5ff21._comment
new file mode 100644
index 0000000000..8b7c3b52e1
--- /dev/null
+++ b/doc/forum/Convert_regular_git-annex_repo_to_a_rsync_repo/comment_6_5899741cb7f83e1b22c5ee3509c5ff21._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 6"
+ date="2014-02-25T09:34:16Z"
+ content="""
+assuming the remote I am converting is called some-repo should mark it as dead before converting and reinitting as rsync some-repo again?
+"""]]
diff --git a/doc/forum/Copy_contents_of_directory_to_rsync_remotes_possible__63__.mdwn b/doc/forum/Copy_contents_of_directory_to_rsync_remotes_possible__63__.mdwn
new file mode 100644
index 0000000000..abc2f8f263
--- /dev/null
+++ b/doc/forum/Copy_contents_of_directory_to_rsync_remotes_possible__63__.mdwn
@@ -0,0 +1,16 @@
+I'm having trouble sharing an rsync remote between two users (as a "transfer" repository).  `git-annex` thinks `rsync` fails because it can't set the permissions on the root directory on the destination.  I've added `--perms --chmod=Dug+rwxs,Fug+rw,o-rwx` to `annex-rsync-options` so all users in the specified group on the destination can create and delete files.  However, I see in the logs errors like:
+
+    sending incremental file list
+    ./
+    rsync: failed to set permissions on "/home/shared-xfer/.": Operation not permitted (1)
+    2fe/985/GPGHMACSHA1--b36ce0a18718e7ea7cf9827c2748608df7152dfc/GPGHMACSHA1--b36ce0a18718e7ea7cf9827c2748608df7152dfc
+    
+             32,768   0%    0.00kB/s    0:00:00  
+          3,359,405 100%    4.78MB/s    0:00:00 (xfr#1, to-chk=0/5)
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.1]
+    [2014-10-18 15:16:24 EDT] chat: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--batch","--passphrase-fd","22","--symmetric","--force-mdc","--no-textmode"]
+    [2014-10-18 15:16:24 EDT] read: rsync ["-e","'ssh' '-S' '.git/annex/ssh/blah@blah' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-l' 'blah' '-T'","--perms","--chmod=Dug+rwxs,Fug+rw,o-rwx","--progress","--recursive","--partial","--partial-dir=.rsync-partial","/blah/.git/annex/tmp/rsynctmp/24863/","blah@blah:/home/shared-xfer/"]
+
+      rsync failed -- run git annex again to resume file transfer
+
+The transfer actually completes fine, except for setting permissions of the root directory on the destination (which I don't really care about, because I have manually set them to be correct).  Is it possible for `git-annex` to copy the contents of the directory to rsync remotes?  For the example above, instead of `/blah/.git/annex/tmp/rsynctmp/24863/`, `/blah/.git/annex/tmp/rsynctmp/24863/2fe` would work.  I can't come up with an alternate solution for this server, except using the same remote user (which I'd prefer not to do).
diff --git a/doc/forum/Copy_contents_of_directory_to_rsync_remotes_possible__63__/comment_1_6a598b2a0fc6c241aa051f663dca9842._comment b/doc/forum/Copy_contents_of_directory_to_rsync_remotes_possible__63__/comment_1_6a598b2a0fc6c241aa051f663dca9842._comment
new file mode 100644
index 0000000000..6e4186622b
--- /dev/null
+++ b/doc/forum/Copy_contents_of_directory_to_rsync_remotes_possible__63__/comment_1_6a598b2a0fc6c241aa051f663dca9842._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-28T19:26:01Z"
+ content="""
+git-annex has to tell rsync to transfer the "24863" directory,
+otherwise rsync would not create that directory, and would then
+fail to create "24863/2fe" since its parent directory doesn't exist.
+
+Might be able to use use ACLS, I suppose, but they bring a lot of complexity.
+"""]]
diff --git a/doc/forum/Copy_contents_of_directory_to_rsync_remotes_possible__63__/comment_3_09b7f1dd1fa4589b3fe0be0086849bf3._comment b/doc/forum/Copy_contents_of_directory_to_rsync_remotes_possible__63__/comment_3_09b7f1dd1fa4589b3fe0be0086849bf3._comment
new file mode 100644
index 0000000000..1d6e912bc9
--- /dev/null
+++ b/doc/forum/Copy_contents_of_directory_to_rsync_remotes_possible__63__/comment_3_09b7f1dd1fa4589b3fe0be0086849bf3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlVB7wf1TFFrNPvM62fg78X-simVV-R1Cg"
+ nickname="Joe"
+ subject="comment 3"
+ date="2014-11-03T02:21:32Z"
+ content="""
+I was thinking that a call to `rsync /blah/.git/annex/tmp/rsynctmp/24863/2fe blah@blah:/home/shared-xfer/24863/` would work just as well, creating the necessary directories.  But this requires knowing all the subdirectories of `24863`.  Not sure if `git-annex` knows this.
+"""]]
diff --git a/doc/forum/Copy_modified_content_to_a_repo_that_only_wants_content_already_present.mdwn b/doc/forum/Copy_modified_content_to_a_repo_that_only_wants_content_already_present.mdwn
new file mode 100644
index 0000000000..a5500d0b1b
--- /dev/null
+++ b/doc/forum/Copy_modified_content_to_a_repo_that_only_wants_content_already_present.mdwn
@@ -0,0 +1,14 @@
+Let's say I have 2 client repos located in my laptop and desktop and a backup repo located in an external drive.<br>
+I want the 2 client repos to only want content that is already present in the repo. So I set their preferred content like this: 
+
+```git annex wanted . "present"```
+
+And let's say the 2 client repos already contain the file **test.txt**.
+
+When I modify **test.txt** in the laptop repo and run `git annex sync --content`, then go to the desktop repo and run `git annex sync`,<br>
+the behavior I'm expecting is that test.txt in the desktop repo will be updated when sync is run since clients want content that is already present. 
+
+However, what happens is that the file **test.txt** in the desktop repo is **dropped**.<br>
+Is this the expected behavior when using `present` in the preferred content expression?
+
+How can I have the modified content in a client repo automatically copied via `git annex sync --content` to another client repo when the preferred content for the client group is to only want content that is already present?
diff --git a/doc/forum/Copy_modified_content_to_a_repo_that_only_wants_content_already_present/comment_1_fb09f84abeebc55df9741b059dc50674._comment b/doc/forum/Copy_modified_content_to_a_repo_that_only_wants_content_already_present/comment_1_fb09f84abeebc55df9741b059dc50674._comment
new file mode 100644
index 0000000000..096ddaa842
--- /dev/null
+++ b/doc/forum/Copy_modified_content_to_a_repo_that_only_wants_content_already_present/comment_1_fb09f84abeebc55df9741b059dc50674._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-10-10T11:28:39Z"
+ content="""
+The [preferred-content](https://git-annex.branchable.com/git-annex-preferred-content/) expression `present` operates on the content of a file, not on the file name. So when you modify `test.txt` on laptop, then `test.txt` now links to the new content (say content2). When you sync, desktop sees that `test.txt` now links to content2, content2 is not present on desktop so on your desktop `test.txt` now links to content that isn't there, IE `test.txt` shows as not present on your desktop. But your old content, say content1 is still present on your laptop and desktop if you were to checkout previous versions of git. Nothing was actually dropped anywhere (I don't think) but the new content (content2) was just not wanted on your desktop since it was never present there.
+
+I don't think what you are trying to achieve is currently possible with git-annex in the general case. But, for 2 repos you could just do: `git annex wanted . \"copies=2\"`. This will mean that anytime you create a new version of a file (new content) on one machine that content will be wanted on the other machine as well to increase the copy count to 2.
+"""]]
diff --git a/doc/forum/Copy_modified_content_to_a_repo_that_only_wants_content_already_present/comment_2_0b13914351aeb57fd7684ff2041618ee._comment b/doc/forum/Copy_modified_content_to_a_repo_that_only_wants_content_already_present/comment_2_0b13914351aeb57fd7684ff2041618ee._comment
new file mode 100644
index 0000000000..b2f0608a6e
--- /dev/null
+++ b/doc/forum/Copy_modified_content_to_a_repo_that_only_wants_content_already_present/comment_2_0b13914351aeb57fd7684ff2041618ee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ericm"
+ avatar="http://cdn.libravatar.org/avatar/67ca64c5a99fb142fc2e3916333881ca"
+ subject="comment 2"
+ date="2018-10-10T23:20:17Z"
+ content="""
+Yeah I realized that what I want to achieve is not currently possible. So I just modified a bit the standard client preferred content, removing the archive folder part,
+"""]]
diff --git a/doc/forum/Copying_and_dropping_right_after.mdwn b/doc/forum/Copying_and_dropping_right_after.mdwn
new file mode 100644
index 0000000000..65680c0629
--- /dev/null
+++ b/doc/forum/Copying_and_dropping_right_after.mdwn
@@ -0,0 +1,18 @@
+Hello,
+
+I have three repos horus (client, this one), astarte (transfer, remote) and external_2tb (client, connected usb). On a git annex sync --content it first copies the content to external and astarte and then dropping the content from astarte right after. 
+
+    copy FLAC/Corvus Corax - Cantus Buranus/Corvus Corax - 08 - Sol solo.flac copy FLAC/Corvus Corax - Cantus Buranus/Corvus Corax - 08 - Sol solo.flac (to external_2TB...) 
+    Corvus Corax - 08 - Sol solo.flac
+         33,541,833 100%  257.72MB/s    0:00:00 (xfr#1, to-chk=0/1)
+    ok
+    copy FLAC/Corvus Corax - Cantus Buranus/Corvus Corax - 08 - Sol solo.flac copy FLAC/Corvus Corax - Cantus Buranus/Corvus Corax - 08 - Sol solo.flac (checking astarte...) (to astarte...) 
+    Corvus Corax - 08 - Sol solo.flac
+        33,541,833 100%  437.82kB/s    0:01:14 (xfr#1, to-chk=0/1)
+    ok
+    drop astarte FLAC/Corvus Corax - Cantus Buranus/Corvus Corax - 08 - Sol solo.flac ok
+
+Why copying it anyway?
+
+Regards,
+Florian
diff --git a/doc/forum/Copying_and_dropping_right_after/comment_1_87d81911964c2628ccb6156b0b631aa0._comment b/doc/forum/Copying_and_dropping_right_after/comment_1_87d81911964c2628ccb6156b0b631aa0._comment
new file mode 100644
index 0000000000..dbe357d66e
--- /dev/null
+++ b/doc/forum/Copying_and_dropping_right_after/comment_1_87d81911964c2628ccb6156b0b631aa0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-01-05T20:31:10Z"
+ content="""
+This must have something to do with the preferred content settings of
+astarte. Can you show the output of this command: `git annex wanted astarte`
+"""]]
diff --git a/doc/forum/Copying_and_dropping_right_after/comment_2_87a14d14014aefc33f811bb15ea27e13._comment b/doc/forum/Copying_and_dropping_right_after/comment_2_87a14d14014aefc33f811bb15ea27e13._comment
new file mode 100644
index 0000000000..b58b61a757
--- /dev/null
+++ b/doc/forum/Copying_and_dropping_right_after/comment_2_87a14d14014aefc33f811bb15ea27e13._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9SYh6N-JUMkYkW4aOk55zC3Vr9KonDV4"
+ nickname="Florian"
+ subject="comment 2"
+ date="2015-01-14T22:01:24Z"
+ content="""
+Sorry for the late reply. I had redone my git-annex repos, but I just had exactly this behaviour again
+
+    % git annex wanted astarte
+    standard 
+    % git annex group astarte 
+    transfer
+
+Best Regards...
+"""]]
diff --git a/doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work.mdwn b/doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work.mdwn
new file mode 100644
index 0000000000..2865441e78
--- /dev/null
+++ b/doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work.mdwn
@@ -0,0 +1,47 @@
+Posting this here because I am not sure if it is a bug or if I am missing something.
+
+I have a ~10 GB file in git-annex. I can't get it to go to S3 whatever I do.
+
+I added a S3 special remote:
+
+    git annex initremote s3-mybucket type=S3 chunk=1MiB keyid=ABCD1234 bucket=mybucket
+
+Then, I tried copying files to the remote.  Small files worked, but big files don't:
+
+    $ git annex copy bigfile.tgz --to s3-mybucket
+    copy bigfile.tgz (gpg)
+    You need a passphrase to unlock the secret key for
+    user: "user"
+    2048-bit RSA key, ID ABCD1234, created 2014-10-13 (main key ID ABCD1234)
+
+    (checking s3-mybucket...) (to s3-mybucket...)
+
+      Your proposed upload exceeds the maximum allowed size
+    failed
+    git-annex: copy: 1 failed
+
+I tried some stuff like this too:
+
+    git annex enableremote s3-mybucket chunk=100MiB
+    git annex enableremote s3-mybucket chunksize=100MiB
+
+It didn't work. Same result.
+
+    $ git annex version
+    git-annex version: 5.20140717
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+The chunk size did seem to be set properly:
+
+    $ git checkout git-annex
+    $ cat remote.log
+    xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx bucket=mybucket chunk=100MiB chunksize=100MiB cipher=....
+
+I'm on OSX 10.9.4 and I installed git-annex via homebrew.
+
+Any ideas?
diff --git a/doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work/comment_1_ec390a7d521c697eb6b17e8db1dc9d1d._comment b/doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work/comment_1_ec390a7d521c697eb6b17e8db1dc9d1d._comment
new file mode 100644
index 0000000000..7b8a0e1f5d
--- /dev/null
+++ b/doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work/comment_1_ec390a7d521c697eb6b17e8db1dc9d1d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.111"
+ subject="comment 1"
+ date="2014-10-15T15:25:14Z"
+ content="""
+You're using an old version of git-annex from before the recent complete rewrite of the chunking code. That old version did not support chunking for S3. QED. Upgrade.
+
+Note that your configuration has both the chunksize= and chunk= set. This is not a good idea, since they enable different types of chunking that are not compatible. If I were you, I'd delete that special remote and make a new one after upgrading, and be careful to only set `chunk=` in that new one.
+"""]]
diff --git a/doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work/comment_2_14a584567ef42d5b7955ee970200e74d._comment b/doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work/comment_2_14a584567ef42d5b7955ee970200e74d._comment
new file mode 100644
index 0000000000..744b9f182c
--- /dev/null
+++ b/doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work/comment_2_14a584567ef42d5b7955ee970200e74d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://digiuser.livejournal.com/"
+ ip="67.161.4.185"
+ subject="Homebrew"
+ date="2014-10-15T15:37:34Z"
+ content="""
+Oh, ok, thank you. I am using the latest version from homebrew. Is there a way to get homebrew to install the latest version?
+
+Thanks.
+"""]]
diff --git a/doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work/comment_3_6cbd7329f1f11edf8dd90df27d45158f._comment b/doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work/comment_3_6cbd7329f1f11edf8dd90df27d45158f._comment
new file mode 100644
index 0000000000..ecba0fc838
--- /dev/null
+++ b/doc/forum/Copying_to_S3_does_not_work_-_chunking_does_not_work/comment_3_6cbd7329f1f11edf8dd90df27d45158f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.111"
+ subject="comment 3"
+ date="2014-10-15T17:25:27Z"
+ content="""
+I think that if you have installed all the build deps for git-annex using homebrew, you should be able to just install git-annex from source.
+
+Or, ask the homebrewers to update the package there..
+"""]]
diff --git a/doc/forum/Correct_way_to_use_somewhat_unreliable_private_server_and_box.com.mdwn b/doc/forum/Correct_way_to_use_somewhat_unreliable_private_server_and_box.com.mdwn
new file mode 100644
index 0000000000..0aa122203f
--- /dev/null
+++ b/doc/forum/Correct_way_to_use_somewhat_unreliable_private_server_and_box.com.mdwn
@@ -0,0 +1,3 @@
+I have a private server (a computer at work) which I use as the "central repository" with git-annex. Unfortunately it sometimes goes down and occasionally I can't easilly put it on again (think holidays). So I'd like to use box.com as a backup.
+
+What's the most efficient way to do it? Simply add both my private serer and box.com as "transfer: distributes files to clients" repositiories? I'm afraid that if I do that then box.com will slow things down for me (I haven't tried it yet because I'm literally starting with git-annex today). Ideally I'd like all transfers to/from box.com to be somehow in the background so that they don't interfere with the transfers to/from my private server.
diff --git a/doc/forum/Correct_way_to_use_somewhat_unreliable_private_server_and_box.com/comment_1_9c357a4a99930936124a58ffe105f87f._comment b/doc/forum/Correct_way_to_use_somewhat_unreliable_private_server_and_box.com/comment_1_9c357a4a99930936124a58ffe105f87f._comment
new file mode 100644
index 0000000000..e159e2e97e
--- /dev/null
+++ b/doc/forum/Correct_way_to_use_somewhat_unreliable_private_server_and_box.com/comment_1_9c357a4a99930936124a58ffe105f87f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
+ nickname="Carl"
+ subject="Cost"
+ date="2015-09-26T08:59:39Z"
+ content="""
+If I understand you correctly, the concept of \"cost\" is exactly what you need. You give the box remote a higher cost, and thus you will prefer to download from the remote with a lower cost, when available.
+"""]]
diff --git a/doc/forum/Correct_way_to_use_somewhat_unreliable_private_server_and_box.com/comment_2_b4aec96cbcd8752f273ecd810400acef._comment b/doc/forum/Correct_way_to_use_somewhat_unreliable_private_server_and_box.com/comment_2_b4aec96cbcd8752f273ecd810400acef._comment
new file mode 100644
index 0000000000..cac39d7bfb
--- /dev/null
+++ b/doc/forum/Correct_way_to_use_somewhat_unreliable_private_server_and_box.com/comment_2_b4aec96cbcd8752f273ecd810400acef._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-09-29T15:42:46Z"
+ content="""
+I'm going to answer this both for the webapp and for command line usage.
+
+webapp:
+
+Drag and drop the box.com remote to be below the remote for your private
+server. This will adjust the cost settings, and let git-annex know it
+should try to get files from your private server first.
+
+Click on "syncing enabled" at any time to toggle it to disabled.
+You could choose to leave box.com disabled most of the time, to avoid files
+being uploaded to it etc. When your private server is not available, you
+can toggle box.com back to enabled to use it temporarily.
+
+command line:
+
+Let's assume the box.com remote is named "box".
+
+You can use `remote.box.annex-cost` in git config, to give that remote a
+higher use-cost than your private server's remote. git-annex will then know
+you prefer using your private server when possible, and so will prefer to
+use it when eg, downloading files. (Same as dragging and dropping in the
+webapp.)
+
+You could configure a cron job (or run the git-annex assistant) on the
+server to send the files on to box.com. Just `git annex enableremote box`
+on the server so it knows how to use that remote. This way, you don't
+need to upload the same file twice to both box.com and your server over
+your home network link, but files will end up in both locations.
+
+Uploading files with `git annex copy --to` can send them to your private
+server. Or, if you want to use `git annex sync --content` or the assistant,
+you could set `remote.box.annex-sync` to false for the box.com
+remote, to prevent sending content to it. When your private server is
+unavailable, you could override that setting temporarily and sync with
+box.com by running `git annex sync --content box`
+"""]]
diff --git a/doc/forum/Corrupt_Repository_Invalid_Object.mdwn b/doc/forum/Corrupt_Repository_Invalid_Object.mdwn
new file mode 100644
index 0000000000..af6d8e3538
--- /dev/null
+++ b/doc/forum/Corrupt_Repository_Invalid_Object.mdwn
@@ -0,0 +1,10 @@
+One of my repositories got corrupted. I am not exactly sure how it happened (was running a series of commands) but I think I accidentally ran regular mv instead of git mv. To fix it I deleted the moved file then checkout the original link however this did not fixed the problem. I ended up with a corrupted repo. Now running any command ends with the following error,
+
+    ga sync
+    (merging origin/git-annex origin/synced/git-annex into git-annex...)
+    (Recording state in git...)
+    error: invalid object 040000 6ad564920e3d78d31c9456f5be3869a0319f9f08 for'3fd/d44'                                                                                
+    fatal: git-write-tree: error building trees
+    git-annex: failed to read sha from git write-tree
+
+Was wondering how to fix this? I did run git fsck and git annex fsck but non fixed the problem.
diff --git a/doc/forum/Corrupt_Repository_Invalid_Object/comment_1_b7fd4b6212b50400342931e70684b96c._comment b/doc/forum/Corrupt_Repository_Invalid_Object/comment_1_b7fd4b6212b50400342931e70684b96c._comment
new file mode 100644
index 0000000000..a62e6d345c
--- /dev/null
+++ b/doc/forum/Corrupt_Repository_Invalid_Object/comment_1_b7fd4b6212b50400342931e70684b96c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 1"
+ date="2014-04-17T19:47:54Z"
+ content="""
+git is complaining about one of the files in `.git/objects` being missing or corrupt.
+
+It's not likely that some accidental command you ran caused this. More likely a disk error or an unclean shutdown could have left the repository in this state.
+
+You can try running `git annex repair` which should be able to repair git repositories with this kind of damage.
+
+Or you can just `git clone` the repository from any other place you have it and move over .git/annex/objects and .git/config to the new repository, discarding the damaged one.
+"""]]
diff --git a/doc/forum/Corrupted_repository__44___can_not_be_repaired.mdwn b/doc/forum/Corrupted_repository__44___can_not_be_repaired.mdwn
new file mode 100644
index 0000000000..e2b4357bf9
--- /dev/null
+++ b/doc/forum/Corrupted_repository__44___can_not_be_repaired.mdwn
@@ -0,0 +1,40 @@
+Hey, I hope somebody can help me:
+
+I recently moved a bunch of files to another location shortly after I renamed them. The assistant was running (repo: indirect mode) and I guess the assistant was confused about whether to commit the rename changes or to fix the symlinks because of the location move (and to commit these changes). I don't know much about the internal design, but after that my repository was kinda broken. Every git command failed and also "git fsck" gave me some error messages. However, I mounted my external drive (backup repo) and tried a "git annex repair". It took quite a while, but it could fix the repo....somehow. This is the current status:
+
+    ~/private [master●] » git annex info
+    repository mode: indirect
+    trusted repositories: error: refs/remotes/extern/git-annex does not point to a valid object!
+    error: refs/remotes/extern/git-annex does not point to a valid object!
+    error: unable to resolve reference refs/heads/git-annex: Datei oder Verzeichnis nicht gefunden // (english: No such file or directory)
+    fatal: Cannot lock the ref 'refs/heads/git-annex'.
+    git-annex: git [Param "update-ref",Param "refs/heads/git-annex",Param "ea4d4b5e09bfd10c714c24ca76ab5af0625bb6a7"] failed
+
+    ~/private [master●] » git fsck
+    Checking object directories: 100% (256/256), done.
+    Checking objects: 100% (654755/654755), done.
+    error: refs/remotes/extern/git-annex does not point to a valid object!
+    error: bad ref for refs/heads/git-annex
+    Checking connectivity: 654760, done.
+    dangling blob cb2a012e65b15baf0bc51cb8ac6ab05c4ac4e543
+    dangling blob 6a48216d54be6fbf0539c86501ce9e4567ebf678
+    dangling blob 3f8f21304c6dcfc6ace92093425d7f057138b5e8
+    dangling blob 4943840264ad7c06071f510261151c28b4fb5168
+    dangling blob d67e845b06b17c3ba5b44a454d3128dea6ebe8cc
+    dangling blob 38b7e4ce06a84c03b9a0f7f3a84872b2ed202421
+    dangling blob ca0a65e010c69e02953d63f33c5f2030f793c8ff
+    dangling blob aeba65035f566ec9f18ad2ba71b155b0efd2193a
+    dangling blob d3cea542db4c2904f5c8c6dd98ca3868074e6d36
+    dangling commit fe1026edee5dcc6306f04ebe1a7762b86678db8a
+    [... some more dangling objects ...]
+
+However, git annex repair does not want to repair my repo a second time:
+
+    ~/private [master●] » git annex repair
+    Running git fsck ...
+    No problems found.
+    ok
+My directory seems to be fine, also the data (symlinks) I renamed & moved are also fine. Just the "git-annex" branch seems to be broken now and I don't know how to fix that.
+
+Cheers,
+Stephan
diff --git a/doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_1_297ea9c13096f6360358b3a3e7197c03._comment b/doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_1_297ea9c13096f6360358b3a3e7197c03._comment
new file mode 100644
index 0000000000..63878f19ef
--- /dev/null
+++ b/doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_1_297ea9c13096f6360358b3a3e7197c03._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="sts"
+ ip="134.147.73.126"
+ subject="comment 1"
+ date="2014-07-18T09:46:01Z"
+ content="""
+I forgot, this might be interesting
+
+    git show ea4d4b5e09bfd10c714c24ca76ab5af0625bb6a7
+    
+    commit ea4d4b5e09bfd10c714c24ca76ab5af0625bb6a7
+    Author: Stephan Schindel <sts@tp1.rub.de>
+    Date:   Fri Jul 18 11:28:07 2014 +0200
+
+        branch created
+
+and
+
+    ~/private [master●] » git annex fsck
+    error: refs/remotes/extern/git-annex does not point to a valid object!
+    error: refs/remotes/extern/git-annex does not point to a valid object!
+    error: unable to resolve reference refs/heads/git-annex: Datei oder Verzeichnis nicht gefunden
+    fatal: Cannot lock the ref 'refs/heads/git-annex'.
+    git-annex: git [Param \"update-ref\",Param \"refs/heads/git-annex\",Param \"199fbe3e7ca1dbce99ffa04e440209eb93446374\"] failed
+
+
+and
+
+    git show 199fbe3e7ca1dbce99ffa04e440209eb93446374
+
+    commit 199fbe3e7ca1dbce99ffa04e440209eb93446374
+    Author: Stephan Schindel <sts@tp1.rub.de>
+    Date:   Fri Jul 18 11:46:29 2014 +0200
+
+        branch created
+
+"""]]
diff --git a/doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_2_c3aabffbe9568cf7acb4018e445f22a5._comment b/doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_2_c3aabffbe9568cf7acb4018e445f22a5._comment
new file mode 100644
index 0000000000..04e11a78cf
--- /dev/null
+++ b/doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_2_c3aabffbe9568cf7acb4018e445f22a5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="sts"
+ ip="134.147.73.126"
+ subject="comment 2"
+ date="2014-07-18T11:17:49Z"
+ content="""
+Ok, I could fix this issue by doing a fresh clone of one of my remotes:
+
+    git clone path/to/remote
+    [move objects folder from broken repo .git/annex/objects to new clone]
+    git annex info (look for UUID or DESC)
+    git annex reinit \"DESC\"
+"""]]
diff --git a/doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_3_baee46af6b2dbaf92be406ab22007a85._comment b/doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_3_baee46af6b2dbaf92be406ab22007a85._comment
new file mode 100644
index 0000000000..662e8a2b34
--- /dev/null
+++ b/doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_3_baee46af6b2dbaf92be406ab22007a85._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-07-21T22:57:32Z"
+ content="""
+There was a bug in the repair code that could leave the repair incomplete like this; I've fixed it.
+
+> I recently moved a bunch of files to another location shortly after I renamed them. The assistant was running (repo: indirect mode) and I guess the assistant was confused
+
+No, I don't think that this was caused by the assistant somehow getting confused. Your git repository was missing objects that had been previously committed to git. The only way this can happen is if your computer lost data. Most commonly due to crashing or being powered off or the drive the repository is in being removed while git is in the middle of committing changes.
+"""]]
diff --git a/doc/forum/Create_lightweight_checkouts_on_the_same_filesystem.mdwn b/doc/forum/Create_lightweight_checkouts_on_the_same_filesystem.mdwn
new file mode 100644
index 0000000000..162185fece
--- /dev/null
+++ b/doc/forum/Create_lightweight_checkouts_on_the_same_filesystem.mdwn
@@ -0,0 +1,7 @@
+I'm sorry if this has been answered before, I did my best searching and couldn't find a fitting solution.
+
+I envision the following setup. There is one central git-annex repository where all modifications are to be performed. At the same time, I want to create lightweight clones of that repository on the same machine, the same filesystem, that would contain all git metadata (so that I can navigate the history inside the child repository), but would reuse binary objects from the parent repository. The child repositories can be read-only, I don't plan to use them for anything else but checking out the specific version of the parent repository.
+
+I found out about --shared flag and it seemed like it was exactly what I need. However, after cloning the parent repository with --shared, the symlinks in the child repository still pointed to nowhere. After I did `git annex sync --content`, the binary files were copied into the child repository's .git/ directory.
+
+Is it possible to achieve what I want? Thanks in advance!
diff --git a/doc/forum/Create_lightweight_checkouts_on_the_same_filesystem/comment_1_dc219eec54b62803831c854a620aceae._comment b/doc/forum/Create_lightweight_checkouts_on_the_same_filesystem/comment_1_dc219eec54b62803831c854a620aceae._comment
new file mode 100644
index 0000000000..2c49a613d2
--- /dev/null
+++ b/doc/forum/Create_lightweight_checkouts_on_the_same_filesystem/comment_1_dc219eec54b62803831c854a620aceae._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="comment 1"
+ date="2017-07-20T17:47:42Z"
+ content="""
+Symbolic links point to `......./.git/annex/objects/.....`
+
+So, you can have them work by making your `.git/annex/objects` a link to the main repo's `.git/annex/objects`.
+
+    cd $mylightweightclone/.git/annex
+    mv objects objects.empty # move away but keep, just in case
+    ln -s $centralrepository/.git/annex/objects
+
+If the lightweight clone only performs read operations, I would expect things to work fine.
+
+I don't know if it can be dangerous to the health of your central repository besides that, so be careful.
+
+"""]]
diff --git a/doc/forum/Create_lightweight_checkouts_on_the_same_filesystem/comment_2_1263830d015a458024a2346540f10f31._comment b/doc/forum/Create_lightweight_checkouts_on_the_same_filesystem/comment_2_1263830d015a458024a2346540f10f31._comment
new file mode 100644
index 0000000000..fbb87f448a
--- /dev/null
+++ b/doc/forum/Create_lightweight_checkouts_on_the_same_filesystem/comment_2_1263830d015a458024a2346540f10f31._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-10-02T16:40:44Z"
+ content="""
+The way to do this is to use `git clone --shared`.
+Since git-annex version, 5.20140915, it detects when a new
+repository has been cloned that way and enables annex.hardlink,
+so files are inexpensively linked into place in the clone when getting them
+from the origin on the same filesystem.
+"""]]
diff --git a/doc/forum/Creating_a_more_secure_shared_encryption.mdwn b/doc/forum/Creating_a_more_secure_shared_encryption.mdwn
new file mode 100644
index 0000000000..5b2019f37c
--- /dev/null
+++ b/doc/forum/Creating_a_more_secure_shared_encryption.mdwn
@@ -0,0 +1,7 @@
+I was wondering if there was a way to make shared encryption more secure.  Here is my suggestion:  
+The shared repository is encrypted using a key for the whole repository, just the way normal encryption would work.  
+The server additionally keeps a copy of every user's public key.  
+When a user is authorized, their repository is initialized and they receive the common key, encrypted by their public key.  
+The only issue would be storage of the common key, which would have to be restricted to repository on a trusted machine.  
+
+Not sure if this would be easy for you to implement, but I figured I'd submit a post detailing it, to see if maybe it was doable.
diff --git a/doc/forum/Crippled_FS__58___remove_read_perms_from_dropped_files__63___.mdwn b/doc/forum/Crippled_FS__58___remove_read_perms_from_dropped_files__63___.mdwn
new file mode 100644
index 0000000000..18dc2fe66f
--- /dev/null
+++ b/doc/forum/Crippled_FS__58___remove_read_perms_from_dropped_files__63___.mdwn
@@ -0,0 +1,3 @@
+While experimenting with direct mode on Windows, I've got confused (and feeling momentary dread about apparent loss of data) many times when opening a file, and finding out that it in fact only contained the checksum; that is, was in the "dropped" state. As an **idea to prevent this confusion**, would it perhaps be possible to make the dropped files non-readable (permission denied) to the user somehow?
+
+(Background: I'm trying to build a version controlled development environment for a bunch of artists collaborating on large binaries, and making the process as fool-proof as possible is a priority.)
diff --git a/doc/forum/Crippled_FS__58___remove_read_perms_from_dropped_files__63___/comment_1_53941b83ff173025934e002a26031d9b._comment b/doc/forum/Crippled_FS__58___remove_read_perms_from_dropped_files__63___/comment_1_53941b83ff173025934e002a26031d9b._comment
new file mode 100644
index 0000000000..243f839aaa
--- /dev/null
+++ b/doc/forum/Crippled_FS__58___remove_read_perms_from_dropped_files__63___/comment_1_53941b83ff173025934e002a26031d9b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-09T19:43:07Z"
+ content="""
+I think that would be a great idea. If someone can tell me how to do that
+on Windows.. 
+
+Note that even if you opened such a file, and made a change, and then
+saved it, this would at the worst result in a new commit being made.
+Other repositories that have a copy of the file would not lose their
+copy, at least not immediately (`git annex dropunused` might eventually
+remove it). So, to recover from such a mistake, it suffices to run `git
+annex undo $file`.
+"""]]
diff --git a/doc/forum/Curious_file_in_repository.mdwn b/doc/forum/Curious_file_in_repository.mdwn
new file mode 100644
index 0000000000..6407112248
--- /dev/null
+++ b/doc/forum/Curious_file_in_repository.mdwn
@@ -0,0 +1,17 @@
+The other day, in the middle of one of my repositories I found a file. There was something strange about this file: it was a regular file, not a symlink like most of the files in my repository.
+Maybe it got lost. Maybe I copied it in and forgot to `add` it. So I tried to add it, but it failed. Or, better, it did not give an error but it also did not change a thing. Why?
+
+    $ git-annex add -d Cats.mkv                                                                             
+    [2019-09-21 12:12:15.243550924] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+    [2019-09-21 12:12:15.246431114] process done ExitSuccess
+    [2019-09-21 12:12:15.246610667] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","show-ref","refs/heads/master"]
+    [2019-09-21 12:12:15.249072467] process done ExitSuccess
+    [2019-09-21 12:12:15.249345571] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","ls-files","--others","--exclude-standard","-z","--","Cats & Dogs (2001).mkv"]
+    [2019-09-21 12:12:15.254996251] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","ls-files","--modified","-z","--","Cats.mkv"]
+    [2019-09-21 12:12:15.260730984] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","diff","--name-only","--diff-filter=T","-z","--cached","--","Cats.mkv"]
+
+I also found this same file in all clones of this repository! What is going on?
+
+Is it something to do with locked/unlocked files? I never unlock anything. `git-annex lock Cats.mkv` changes nothing. `git-annex list` shows no files. `git-annex checkpresentkey $(git-annex calckey Cats.mkv)` returns error number 1. So, it seems safe to say that the file is not in the repository and it _wont't_ go into the repository (not like this). I find this very puzzling!
+
+Maybe I could use `reinject` the file into a repository, but I'm trying to diagnose this situation, trying to determine what is going on. However, I'm out of ideas. Any help?
diff --git a/doc/forum/DBus_on_Ubuntu_12.04__63__.mdwn b/doc/forum/DBus_on_Ubuntu_12.04__63__.mdwn
new file mode 100644
index 0000000000..b4271d172c
--- /dev/null
+++ b/doc/forum/DBus_on_Ubuntu_12.04__63__.mdwn
@@ -0,0 +1,3 @@
+I tried to compile the assitant branch on Ubuntu 12.04. But i depends on the DBus libraryw hich does not compile with some glibberish errors. Is there a way to solve this?
+
+
diff --git a/doc/forum/DBus_on_Ubuntu_12.04__63__/comment_1_dc14a40b64b7eda94d1a3fd766cd39cc._comment b/doc/forum/DBus_on_Ubuntu_12.04__63__/comment_1_dc14a40b64b7eda94d1a3fd766cd39cc._comment
new file mode 100644
index 0000000000..0ef2469d3c
--- /dev/null
+++ b/doc/forum/DBus_on_Ubuntu_12.04__63__/comment_1_dc14a40b64b7eda94d1a3fd766cd39cc._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.119"
+ subject="comment 1"
+ date="2012-08-25T13:06:31Z"
+ content="""
+Hmm, let's see... 
+ 
+If the gibberish error is ouyay orgotfay otay otay elltay emay utwhay ethay
+roreay asway, then we can figure it out, surely..
+
+If the gibberish error looks something like Ḩ̶̞̗̓ͯ̅͒ͪͫe̢ͦ̊ͭͭͤͣ̂͏̢̳̦͔̬ͅ ̣̘̹̄̕͢Ç̛͈͔̹̮̗͈͓̞ͨ͂͑ͅo̿ͥͮ̿͢͏̧̹̗̪͇̫m̷̢̞̙͑̊̔ͧ̍ͩ̇̚ę̜͑̀͝s̖̱̝̩̞̻͐͂̐́̂̇̆͂ 
+
+.. your use of cabal  
+has accidentually summoned Cthulu! Back slowly away from the monitor!
+
+Otherwise, you might try installing the `libdbus-1-dev` package with apt, 
+which might make cabal install the haskell dbus bindings successfully. Or
+you could just install the `libghc-dbus-dev` package, which contains the 
+necessary haskell library pre-built. But I don't know if it's in Ubuntu 
+12.04; it only seems to be available in quantal 
+<http://packages.ubuntu.com/search?keywords=libghc-dbus-dev>
+
+Or you could even build it with the Makefile, rather than using cabal.
+The Makefile has a `-DWITH_DBUS` setting in it that can be removed to build
+the fallback mode that doesn't use dbus.
+
+"""]]
diff --git a/doc/forum/DBus_on_Ubuntu_12.04__63__/comment_2_608a30e274e6a691a39f69503720e320._comment b/doc/forum/DBus_on_Ubuntu_12.04__63__/comment_2_608a30e274e6a691a39f69503720e320._comment
new file mode 100644
index 0000000000..02bda9eaa6
--- /dev/null
+++ b/doc/forum/DBus_on_Ubuntu_12.04__63__/comment_2_608a30e274e6a691a39f69503720e320._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.119"
+ subject="comment 2"
+ date="2012-08-25T13:11:37Z"
+ content="""
+I fnordgot to mention, cabal can be configured to not build with dbus too. The relevant incantation is:
+
+cabal install git-annex --flags=\"-Dbus\"
+"""]]
diff --git a/doc/forum/DBus_on_Ubuntu_12.04__63__/comment_3_791b9978b410c1aff7fd8ef05c38f5f9._comment b/doc/forum/DBus_on_Ubuntu_12.04__63__/comment_3_791b9978b410c1aff7fd8ef05c38f5f9._comment
new file mode 100644
index 0000000000..4097070fd2
--- /dev/null
+++ b/doc/forum/DBus_on_Ubuntu_12.04__63__/comment_3_791b9978b410c1aff7fd8ef05c38f5f9._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmU_2tE75oyG0h2ZPN4lcroIKEMC8G-otE"
+ nickname="Michael"
+ subject="Shame on me..."
+ date="2012-08-25T15:43:19Z"
+ content="""
+The build error is:
+
+$ cabal install DBus
+Resolving dependencies...
+Configuring DBus-0.4...
+checking for pkg-config... /usr/bin/pkg-config
+checking pkg-config is at least version 0.9.0... yes
+checking for DBUS... yes
+configure: creating ./config.status
+config.status: creating DBus.buildinfo
+Building DBus-0.4...
+Preprocessing library DBus-0.4...
+
+DBus/Message.hsc:1:14:
+    Warning: -XPatternSignatures is deprecated: use -XScopedTypeVariables or pragma {-# LANGUAGE ScopedTypeVariables #-} instead
+
+DBus/Message.hsc:2:12:
+    Warning: -fglasgow-exts is deprecated: Use individual extensions instead
+[1 of 5] Compiling DBus.Shared      ( dist/build/DBus/Shared.hs, dist/build/DBus/Shared.o )
+[2 of 5] Compiling DBus             ( dist/build/DBus.hs, dist/build/DBus.o )
+
+DBus.hsc:26:49:
+    Warning: In the use of `mkTyCon'
+             (imported from Data.Typeable):
+             Deprecated: \"either derive Typeable, or use mkTyCon3 instead\"
+[3 of 5] Compiling DBus.Internal    ( dist/build/DBus/Internal.hs, dist/build/DBus/Internal.o )
+
+DBus/Internal.hsc:12:27:
+    Module `Control.Exception' does not export `throwDyn'
+cabal: Error: some packages failed to install:
+DBus-0.4 failed during the building phase. The exception was:
+ExitFailure 1
+
+"""]]
diff --git a/doc/forum/DBus_on_Ubuntu_12.04__63__/comment_4_8665c95299916138c4af375626d9ec7d._comment b/doc/forum/DBus_on_Ubuntu_12.04__63__/comment_4_8665c95299916138c4af375626d9ec7d._comment
new file mode 100644
index 0000000000..abd154a6bc
--- /dev/null
+++ b/doc/forum/DBus_on_Ubuntu_12.04__63__/comment_4_8665c95299916138c4af375626d9ec7d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.119"
+ subject="in the language of the ancients, small details matter"
+ date="2012-08-25T15:50:47Z"
+ content="""
+It seems that to cabal, \"DBus\" and \"dbus\" are different packages, and it seems you should install the latter, which has a current version of 0.10 which works and not some old 0.4 version.
+"""]]
diff --git a/doc/forum/DO_NOT_use_ntfs-3g_on_mac_osx_for_annex.mdwn b/doc/forum/DO_NOT_use_ntfs-3g_on_mac_osx_for_annex.mdwn
new file mode 100644
index 0000000000..16750a1fb2
--- /dev/null
+++ b/doc/forum/DO_NOT_use_ntfs-3g_on_mac_osx_for_annex.mdwn
@@ -0,0 +1,41 @@
+After testing around git-annex on my mac using ntfs-3g to access the removable harddrive, I conclude that this is very dangerous. 
+
+Here are some example error snippets:
+
+    add man/man1/git-tar-tree.1 
+    git-annex: /Volumes/SeagateExpansion/annex/testdirect/.git/annex/objects/0K/JJ/SHA256E-s3805--948fd508a364e036ec28f5287d11825062aea2c0ed86a3a89ed871edc6ddc7a8.1/: openTempFile: interrupted (Interrupted system call)
+    failed
+
+    add man/man1/git-bundle.1 
+    git-annex: /Volumes/SeagateExpansion/annex/testdirect/.git/annex/tmp/e3f_804_SHA256E-s8739--569a4b4fe1072e17ff0aa9a2f67d0130b9ec3ed23f96c5a4ea38ada82f50b4aa.1.log: rename: does not exist (No such file or directory)
+    failed
+
+    add git-core/git-completion.bash failed
+    add man/man7/gitglossary.7 failed
+    (Recording state in git...)
+
+    git-annex: /Volumes/SeagateExpansion/annex/testdirect/.git/annex/journal/.fuse_hidden00005dd50000010a: removeLink: does not exist (No such file or directory)
+    failed
+    git-annex: add: 3 failed
+
+It's interesting that after each git-annex add ., it would got fewer failures. But in the end it stuck at 2 files. After 60 times doing: git-annex add .
+
+It went from this:
+
+    git-annex: add: 248 failed
+
+to this:
+
+    git-annex: add: 2 failed
+
+Now the repository has 246 objects, let's try to convert it into an indirect one:
+
+    git-annex indirect
+    ...
+    git-annex info
+    ...
+    annexed files in working tree: 9
+
+Only 9 files made into the indirect repository! Remaining files stay as original state. Now it would be a nightmare to try to recover form this mess.
+
+I discourage anyone from using ntfs-3g on mac for annexing. Especially direct & indirect mode. Bare repo seems to be fine however.
diff --git a/doc/forum/DS__95__Store_files_are_not_added.mdwn b/doc/forum/DS__95__Store_files_are_not_added.mdwn
new file mode 100644
index 0000000000..f0ccf2023b
--- /dev/null
+++ b/doc/forum/DS__95__Store_files_are_not_added.mdwn
@@ -0,0 +1,3 @@
+The "git annex add" command adds new file to the annex. However ".DS_Store" files are ignored by git-annex. Is there a list of files that are being ignored? 
+
+Maybe sometimes it's useful to add .DS_Store extended attribute data to the annex to ensure a complete sync of Mac files...
diff --git a/doc/forum/DS__95__Store_files_are_not_added/comment_1_30687306da9bd35ec02a806193c5e240._comment b/doc/forum/DS__95__Store_files_are_not_added/comment_1_30687306da9bd35ec02a806193c5e240._comment
new file mode 100644
index 0000000000..3402b84c61
--- /dev/null
+++ b/doc/forum/DS__95__Store_files_are_not_added/comment_1_30687306da9bd35ec02a806193c5e240._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 1"
+ date="2012-08-02T23:29:38Z"
+ content="""
+git-annex ignores whatever git does. See `git-ls-files` and the gitignore configuration.
+"""]]
diff --git a/doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper.mdwn b/doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper.mdwn
new file mode 100644
index 0000000000..bc89b1352d
--- /dev/null
+++ b/doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper.mdwn
@@ -0,0 +1,15 @@
+I've been planning to use git-annex to manage a collection of DVD-Rs (of photos and the like), something along [these lines](https://git-annex.branchable.com/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/), and especially this paragraph therein:
+
+> If the [media is] not rewritable [which in my case it won't be; see below], I might try making the git-annex repo in a temporary directory on the hard disk, and then generating the ISO from that once I've filled it up. Should work fine, I might set "remote..annex-readonly" to true in git repos that had such a disk as a remote to let git-annex know to not try to write to it.
+
+But then there's this bug report: [read-only filesystem on remote prevents auto-upgrade from v3 to v5, and prevents using a remote](https://git-annex.branchable.com/bugs/annex_get_fails_from_read-only_filesystem/), and [Joey's comment]((http://git-annex.branchable.com/bugs/annex_get_fails_from_read-only_filesystem/#comment-67f204c3a4312bbda8ace305dbe0afbf):
+
+> From a code complication POV, it's useful for git-annex to only support one version of repository at a time.
+
+My concept depends on being able to restore files from my archive, N years and M git-annex versions later, using `git annex get` (after `git annex whereis` or the like to find out which volume to mount).  If I can't count on the *get* to work -- and indeed, can pretty much count on it *not* to, after the next format-version bump -- this whole scheme sounds like a nonstarter.
+
+> As far as backwards compatablity goes, I don't anticipate ever removing the upgrade code from git-annex.
+
+This is an archive; therefore it will use write-once media -- if it were rewritable, it would be clobberable should something (including `git-annex upgrade`!) go wrong.
+
+So, is there a way around this?  Or am I (and others) out of luck on using git-annex to manage long-term archival storage?
diff --git a/doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper/comment_1_d2640d4cd5bd28df5ecf389d17a2e52b._comment b/doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper/comment_1_d2640d4cd5bd28df5ecf389d17a2e52b._comment
new file mode 100644
index 0000000000..de950c8825
--- /dev/null
+++ b/doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper/comment_1_d2640d4cd5bd28df5ecf389d17a2e52b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-10-05T20:54:02Z"
+ content="""
+I understand your pain (and have just made git-annex support reading V3
+repos without upgrading them). But, it's not a good idea to make git-annex
+support reading all previous repository versions without an upgrade step.
+
+Suggest you plan on copying your DVD-R to a writable medium to access it,
+if git-annex at some point stops supporting the old repo version without
+upgrade.
+"""]]
diff --git a/doc/forum/Data_loss_if_symlink_target_edited.mdwn b/doc/forum/Data_loss_if_symlink_target_edited.mdwn
new file mode 100644
index 0000000000..9ea1ad3d6c
--- /dev/null
+++ b/doc/forum/Data_loss_if_symlink_target_edited.mdwn
@@ -0,0 +1,7 @@
+I am syncing two repos A and B. Will the following operations cause data loss:
+1. File 1 is locked in repo A, and its symlink target is edited without unlocking file 1.
+2. File 1 is unlocked and editted in repo B, followed by a git-annex add operation.
+3. Repo A and B are synced with git-annex sync --content
+Will the editing in step 1 be lost? If so, can you please do a git fsck on the file to be overwritten to at lease give a warning.
+
+I am using emacs su-mode, until recently have I found that su-mode let me edit the symlink target without unlocking.
diff --git a/doc/forum/Data_loss_if_symlink_target_edited/comment_1_599b96a2299f3c998f0317f4321eeff4._comment b/doc/forum/Data_loss_if_symlink_target_edited/comment_1_599b96a2299f3c998f0317f4321eeff4._comment
new file mode 100644
index 0000000000..836d50ec8f
--- /dev/null
+++ b/doc/forum/Data_loss_if_symlink_target_edited/comment_1_599b96a2299f3c998f0317f4321eeff4._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-06-15T13:50:17Z"
+ content="""
+`git-annex fsck` will detect this problem, but the real problem here is not
+that some edit got lost, but that you corrupted a version control object
+file. Similar to editing a file in `.git/objects/`. Fsck will, when it
+notices the problem, move the corrupted object file to `.git/annex/bad/'.
+So your edits are not lost, but are in danger of being forgotten.
+
+Note that, once the modified version of the file from repo B replaces
+the worktree file, `git annex fsck` of that file won't check the old
+version, so will not detect the problem. `git annex fsck --all` still will
+detect it.
+
+git-annex mostly prevents this kind of problem by making the file not have a
+write bit be set, and putting it in a directory that also has its write bit
+not set.
+
+You have to either be running as root, or using a program that goes
+out of its way to change multiple permissions, to get into that situation.
+
+(One example of a program that does is vim. `:w!` will
+temporarily overwrite both write bits.)
+"""]]
diff --git a/doc/forum/Data_not_synced_from_my_local_repos_to_amazon.mdwn b/doc/forum/Data_not_synced_from_my_local_repos_to_amazon.mdwn
new file mode 100644
index 0000000000..39a8ccaa75
--- /dev/null
+++ b/doc/forum/Data_not_synced_from_my_local_repos_to_amazon.mdwn
@@ -0,0 +1,45 @@
+Disclaimer: I am not an expert in git-annex.
+
+Hi,
+
+I have cloned the git-annex repos on my laptop, and use it to push on amazon s3. So far, everything was working fine.
+
+Recently, I made some changes on my local repos, and synced it (or I _thought_ I did) to Amazon, by doing the following procedure:
+
+~~~
+git commit
+git annex sync
+~~~
+
+Note: I wanted to do `git annex sync --content amazon` after the commit, according to our [procedure](https://github.com/spine-generic/data-multi-subject/blob/95ae0f390b4d9220760d733a3d6c6b560cc6502e/CONTRIBUTING.md), but it failed (see https://github.com/spine-generic/data-multi-subject/issues/18).
+
+So I went ahead, and opened the PRs on Github, and then rebased+merged them on master.
+
+After merging, I went back to another local copy of the repos (on compute canada cluster), and did the following:
+
+~~~
+git pull
+git annex get
+~~~
+
+But I was not able to retrieve the data that were recently pushed (or that I _thought_ I pushed) from my laptop. For example, I get the following error message:
+
+~~~
+[jcohen@gra-login3 data-multi-subject]$ git-annex get sub-cmrra02/anat/sub-cmrra02_T2w.nii.gz 
+get sub-cmrra02/anat/sub-cmrra02_T2w.nii.gz (not available) 
+  Try making some of these repositories available:
+  	5cdba4fc-8d50-4e89-bb0c-a3a4f9449666 -- julien@julien-macbook.local:~/code/spine-generic/data-multi-subject
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+git-annex: get: 1 failed
+[jcohen@gra-login3 data-multi-subject]$ git remote
+amazon
+origin
+~~~
+
+If it could be of any help, the full context is available in this [Github issue](https://github.com/spine-generic/data-multi-subject/issues/24).
+
+Thank you for any help you might provide,
+
+Julien
diff --git a/doc/forum/Dead_repo_content_is_not_considered_unused.mdwn b/doc/forum/Dead_repo_content_is_not_considered_unused.mdwn
new file mode 100644
index 0000000000..87a977592d
--- /dev/null
+++ b/doc/forum/Dead_repo_content_is_not_considered_unused.mdwn
@@ -0,0 +1,15 @@
+I can't get content referenced in a dead repo to be considered unused.
+
+Setup:
+
+1. Make repo A and B, connect them
+2. Add file to A, copy to B, sync
+3. Sync B
+4. Mark A dead
+5. Delete symlink from B
+6. Run git-annex forget --drop-dead on B
+7. Run git-annex unused on B
+
+The file does not appear as unused. Am I doing something wrong or is this genuinely impossible?
+
+I can understand the reasons for not wanting it to work this way in case the dead repo had important files, but what this means is files I genuinely want to drop will never be considered unused if they existed in the dead repo. This could create an issue for me if I lose a repo in one of my very large annexes, because that could mean gigs of wasted space. I rely on unused to safely drop content because the drop command may remove files that are still referenced somewhere else (duplicate symlinks).
diff --git a/doc/forum/Dead_repo_content_is_not_considered_unused/comment_1_e78552e939891b950a8352e4e3bdff92._comment b/doc/forum/Dead_repo_content_is_not_considered_unused/comment_1_e78552e939891b950a8352e4e3bdff92._comment
new file mode 100644
index 0000000000..ec066be266
--- /dev/null
+++ b/doc/forum/Dead_repo_content_is_not_considered_unused/comment_1_e78552e939891b950a8352e4e3bdff92._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-30T14:45:06Z"
+ content="""
+A file is not considered unused until there are no git branches that still
+refer to that file. 
+
+When you delete the symlink in step 5, you don't say
+you commit it, so the master branch still refers to the file; it's not
+unused.
+
+Also, you have A as a remote of B still. So git still has a tracking
+branch, remotes/A/master, that still contains the file. So the file
+is still considered in use because of that.
+
+I think you'll probably also have a synced/master branch that contains
+the file too, at least until you sync with some other repository, or delete
+the branch. Arguably that's an implementation detail of git-annex and perhaps
+it should not consider those branches when checking for branches
+that contain a file.
+"""]]
diff --git a/doc/forum/Dealing_with_crippled_Android_file_system.mdwn b/doc/forum/Dealing_with_crippled_Android_file_system.mdwn
new file mode 100644
index 0000000000..bd957f459f
--- /dev/null
+++ b/doc/forum/Dealing_with_crippled_Android_file_system.mdwn
@@ -0,0 +1,15 @@
+When working on Android in [[termux|tips/Install on Android in Termux]], user has limited choices in where to check out an annex:
+
+* in the home directory (`/data/data/com.termux/files/home`): well-behaved ext4 file system that allow symlinks, but is only accessible from inside termux.
+* in shared storage (`/storage/emulated/0`, symlinked as `~/storage/...`): accessible to media apps, but does not support symlinks and is therefore a crippled file system with all its drawbacks. The file system seems to be backed by the same ext4 partition as above, but mounted through some fuse mechanism which I can only assume is responsible for enforcing Android's permissions model.
+
+It would be nice to find a way to have the best of both; here's what I tried so far:
+
+* running git-annex as root for experimental purposes: Does not help, the fuse file system does not support symlinks (`ln -s foo bar` → `ln: cannot create symbolic link from 'foo' to 'bar': Function not implemented`).
+  * If that had worked, I would have had a look at whether it's just a matter of permissions that termux could obtain, but it's obviously a matter of principle.
+* running git-annex in home, but ro-bind-mounting a view of it into emulated storage: Only made the files visible to root, not even to termux let alone other processes (I tried adding `--make-shared` without knowing what it'd do exactly)
+* I saw there'd be a way to [allow symlinks on Android](https://android.stackexchange.com/questions/84022/how-to-make-symlinks-work-inside-storage-emulated-in-4-4-4#111669), but honestly that appears too scary, and given the root ln issue, I think it does not apply any more.
+
+The use case I have in mind is syncing photos to an Android tablet in a v5 repository.
+
+Are there other ideas around on how git-annex can be used with classical symlinks on Android?
diff --git a/doc/forum/Dealing_with_crippled_Android_file_system/comment_1_1b17852211108d9ab4d3959d7f57a9df._comment b/doc/forum/Dealing_with_crippled_Android_file_system/comment_1_1b17852211108d9ab4d3959d7f57a9df._comment
new file mode 100644
index 0000000000..daa1b01b65
--- /dev/null
+++ b/doc/forum/Dealing_with_crippled_Android_file_system/comment_1_1b17852211108d9ab4d3959d7f57a9df._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="use case"
+ date="2018-05-23T00:12:11Z"
+ content="""
+Hmmm. Could you talk more about your use case “The use case I have in mind is syncing photos to an Android tablet in a v5 repository.”?
+
+Lets say I have a nice collection of family photos on my desktop computer annexed in a folder called `family`. Lets say we have `numcopies` set at 1. I keep only the best photos, so it always takes up about 1gb. In the family folder I have nice organized sub-folders and I add new images occasionally. I have an Android tablet that sits on my coffee table and I want visitors to be able to open the tablet, run some gallery app and view all my family photos. Sometimes i'll grab the tablet and take it with me to family gatherings, so I want all the photos on in, ready for offline viewing.
+
+With this use case, perhaps I run assistant inside termux. I clone family into `/data/data/com.termux/files/home` set it as standard group transfer and call it `t`, I also clone it into `/storage/emulated/0`, set it as standard group client, and call this crippled client repo `c`. Our `c` folder should now be accessible to any Android photo gallery app. As we make changes to `family`, on our desktop, assistant on the Android tablet brings them in, when we have wifi, it will probably copy them directly to `c`?
+
+If I take a photo on my tablet, put it in the `c` directory (which is accessible from my photo app), then this photo should be copied directly to family (if I have wifi). If I don't have have wifi, this photo should be immediately copied to `t` in which case I have two copies of the file on my tablet (I think)? If I delete the photo from the crippled filesystem `c` I still have the one that was already copied to `t`. If I re-connect to wifi, perhaps the photo will get sent to `family` from `t`. It might stay in `t` since it is missing from `c`, not sure how this would work (but anyhow, see archive folders in the next paragraph).
+
+Maybe I want to save some space on my tablet (deleting from photo app might work?, but archiving is more likely to work). So I open up my photo app, browse to my `c` folder and start putting a bunch of files in a sub-folder named `archive`. They are then immediately deleted from my tablet (unless they were never synced to `family` in which case I have two copies of them, so I would still have a copy sitting in transfer `t`). If I archive files when I have no wifi, presumably they will just get moved to `t` by assistant since git-annex cannot verify the copy at `family`?
+
+Would something like that work for your use case? I don't actually use Android termux, so I am sure others might have some insight into use of the various directories.
+
+—Andrew
+"""]]
diff --git a/doc/forum/Dealing_with_crippled_Android_file_system/comment_2_af66edabeeafcefb45b1d5c5d13dda92._comment b/doc/forum/Dealing_with_crippled_Android_file_system/comment_2_af66edabeeafcefb45b1d5c5d13dda92._comment
new file mode 100644
index 0000000000..eb5b340e55
--- /dev/null
+++ b/doc/forum/Dealing_with_crippled_Android_file_system/comment_2_af66edabeeafcefb45b1d5c5d13dda92._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Re: use case"
+ date="2018-05-23T07:56:34Z"
+ content="""
+The particular repository I'm looking at for a first stage is a wedding photo repository. It contains both the working directories of the photographers involved (some JPEG, some RAW-based with git-versioned Makefiles and sidecars to get the JPEGs which are then checked in with numcopies=0), where some photographers have their files in multiples copies to reflect their pre-sorting. The final photos are also copied to a release directory in various combinations (\"complete couple's selection\", \"pictures released to guests\", \"other pictures of guests\") which were then distributed by a process outside of git-annex' control (zip files were created and distributed over a web server).
+
+This copying workflow usually works greatly with git-annex v5 (or v6 when files are always kept locked): even if files were checked in by different contributors with different default hash settings, copying a file means copying a symlink.
+
+The whole repository amounts to 125gb, with 3gb in the selection.
+
+On the tablet, when I clone the repository on the crippled side of the file system, the initial checkout takes quite some time, and the 3gb get blown to 8gb due to the file being copied not only to the \"complete couple's selection\", but also to the other selections and the occasional picture in the photographers' directories.
+
+Note that on this repository, the tablet does not even have write access to the repository. It is set to untrusted and \"wants\" the selection folder.
+
+---
+
+The next repository I'd like to do this with is our family photo repository, containing an average of four persons' digitized analog and digital photos starting in 2002 and contains about 700gb of images; that repository has not that much duplication, but the interesting files (often a \"Selection\" folder per event that contains copies with appropriately named files for a sequence) are still checked in in duplicate.
+"""]]
diff --git a/doc/forum/Dealing_with_crippled_Android_file_system/comment_3_8a555490bf1735c2f05a95cdb281ec80._comment b/doc/forum/Dealing_with_crippled_Android_file_system/comment_3_8a555490bf1735c2f05a95cdb281ec80._comment
new file mode 100644
index 0000000000..9a32c41ebe
--- /dev/null
+++ b/doc/forum/Dealing_with_crippled_Android_file_system/comment_3_8a555490bf1735c2f05a95cdb281ec80._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 3"
+ date="2018-05-23T16:01:18Z"
+ content="""
+Hmmm, yes, my solution above wouldn't handle de-duplication of the same file in multiple folders. I have a one thought that might work (I can't test right now):
+
+Use [proot](https://github.com/termux/proot) inside termux to [bind a path](https://github.com/proot-me/PRoot/blob/master/doc/proot/manual.txt) `/data/data/com.termux/files/home/annex-photos` to a mount point `~/storage/pictures/annex`. Then perhaps symlinks within annex-photos will be presented as files at `~/storage/pictures/annex` without increasing actual storage.
+
+"""]]
diff --git a/doc/forum/Dealing_with_crippled_Android_file_system/comment_4_051a08b7acd718ebae66a6aab69edb6e._comment b/doc/forum/Dealing_with_crippled_Android_file_system/comment_4_051a08b7acd718ebae66a6aab69edb6e._comment
new file mode 100644
index 0000000000..9a067b79be
--- /dev/null
+++ b/doc/forum/Dealing_with_crippled_Android_file_system/comment_4_051a08b7acd718ebae66a6aab69edb6e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Re: proot"
+ date="2018-05-23T17:05:54Z"
+ content="""
+proot would only change the view of programs launched under it. I could probably do that (if git annex works under proot on the tablet in question at all; [[I had to disable it|tips/install_on_Android_in_Termux/#comment-48d995d39f783b4c59b1a2a66b387b55]] to get it running on Android 7.1 (compatible; LineageOS 14.1)).
+
+The gallery and similar apps would still only see the fuse file system.
+"""]]
diff --git a/doc/forum/Dealing_with_crippled_Android_file_system/comment_5_a210b77d8567643667bbe92b40b5bef0._comment b/doc/forum/Dealing_with_crippled_Android_file_system/comment_5_a210b77d8567643667bbe92b40b5bef0._comment
new file mode 100644
index 0000000000..33c86afb5b
--- /dev/null
+++ b/doc/forum/Dealing_with_crippled_Android_file_system/comment_5_a210b77d8567643667bbe92b40b5bef0._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 5"
+ date="2018-05-30T14:43:37Z"
+ content="""
+Aaaah. OK, that makes sense.
+
+So, when you call [termux-setup-storage](https://wiki.termux.com/wiki/Internal_and_external_storage) in Termux it creates a bunch of symlinks to the standard Android directories, calling [setupStorageSymlinks](https://github.com/termux/termux-app/blob/master/app/src/main/java/com/termux/app/TermuxInstaller.java). But yeah, the new folders sitting in $HOME are just symlinks to Android's FAT32 view of these folders. I was thinking maybe they were something else…
+
+So after reading [Diving into SDCardFS: How Google’s FUSE Replacement Will Reduce I/O Overhead](https://www.xda-developers.com/diving-into-sdcardfs-how-googles-fuse-replacement-will-reduce-io-overhead/) it appears that FAT32 is very much the baked-in standard. The article also has some nice information on the naming conventions in Android of various storage types. Some Google-ing does imply that people have changed the underlying filesystem of the root OS, with rooting, but the solutions seems to now, at least, be [device specific](https://stackoverflow.com/a/29727734/8671834).
+
+I can't find any elegant, filesystem level solution for de-duplication of files that would be visible as media to all Android apps in `external storage`.
+
+Maybe it is possible that with Android's new [Adoptable Storage](https://source.android.com/devices/storage/adoptable) one could create symlinks, but I haven't tried this and I am not optimistic. Adoptable storage is not widely supported, but essentially it fully encrypts your device and re-formats your “external storage” as ext4 or f2fs. But I would imagine that any public facing views of external storage would probably still be FAT32 so their wouldn't be any way to create symlinks.
+
+My other thought would be to create an app specific solution to your issue. For example you are trying to make photos visible to Gallery apps and you have a lot of duplicate photos present in multiple folders. One solution would be to use albums, which I am pretty sure already support having the same photo in multiple albums (at least in Google Photos), while only taking up storage for a single photo. So, you could copy a single copy of each of your photos to `~/storage/pictures`, then using Android APIs [add the photos into multiple albums](https://stackoverflow.com/a/11983767/8671834). You could probably automate this process with scripts or perhaps a Termux addon? Or, perhaps there is some other album supporting Android Gallery app that uses a simpler album format, like a JSON file or something.
+
+"""]]
diff --git a/doc/forum/Dealing_with_crippled_Android_file_system/comment_6_91f81669519dbf1dfbad2259f48ab99d._comment b/doc/forum/Dealing_with_crippled_Android_file_system/comment_6_91f81669519dbf1dfbad2259f48ab99d._comment
new file mode 100644
index 0000000000..95a08e122a
--- /dev/null
+++ b/doc/forum/Dealing_with_crippled_Android_file_system/comment_6_91f81669519dbf1dfbad2259f48ab99d._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Re: comment 5"
+ date="2018-06-12T19:01:09Z"
+ content="""
+ad SDCardFS / FAT32: It seems that both the fuse wrapper around the SD card (be it actually formatted FAT32 because it's the external one, or ext4 as is the encrypted internal one on my device) and SDCardFS (which, it appears to me, is just Google moving the fuse wrapper into the kernel) won't expose the functionality we want.
+
+ad adoptable storage: I think that's what's happening on my device (but am not sure), so if it is, the there's still the fuse wrapper / SDCardFS inbetween.
+
+ad specific app: That'd still mean that git-annex needs to operate on crippled file system, and I don't want to rely on special solutions for each app.
+
+---
+
+What I've seen when just setting up a new device is that the Storage Access Framework (looks like Android's idea of gvfs / kvfs with a spike of flatpak-portals to me: a userland file system that operates on `saf:/` and `content://` URIs rather than files, probably does file operations by means of IPC and receiving file handlers) might help:
+
+In the LineageOS built-in file manager, I don't see two \"virtual SD cards\" (the internal and the external one), but also a \"Termux\" \"device\" with proper logo and \"0B free\", which allows me to peek into the termux home directory (but not its usr directory). From that file manager I even see the photos inside a regular (symlinked) checkout, and can open them with the Simple Gallery app. (Provided they end with '.jpg' and not '.JPG', but that's probably a detail of the file manager).
+
+I did not yet find another app that sees this \"Termux\" device; Ghost Commander only sees \"Documents\" and the internal and external SD cards; the \"Dir\" file manager exposes a SAF selection only when creating directories on external SD (and then shows the same selection as Ghost Commander), the Simple tools (Simple File Manager, Simple gallery) show \"Internal\", \"SD Card\" and \"Root\" in their own storage selection (might be pre-SAF; similar situation also for the Amaze file manager).
+
+If we could reproduce what the builtin file manager does to access the files, that might be a solution here. Termux obviously already helps in this by exporting the home directory ([since 0.34](https://termux.com/changelog.html)), but maybe they also can do more (like exporting XDG user directories for quick access?).
+"""]]
diff --git a/doc/forum/Dealing_with_crippled_Android_file_system/comment_7_087fdae633144482473c7391ea338c5c._comment b/doc/forum/Dealing_with_crippled_Android_file_system/comment_7_087fdae633144482473c7391ea338c5c._comment
new file mode 100644
index 0000000000..12c667154a
--- /dev/null
+++ b/doc/forum/Dealing_with_crippled_Android_file_system/comment_7_087fdae633144482473c7391ea338c5c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Update on using SAF"
+ date="2018-06-13T14:57:10Z"
+ content="""
+I've looked around for how this whole SAF thing works and where it is supported; it seems to me that it is indeed the way to go:
+
+* Termux added this with the very intention of making the home directory usable ([initial issue](https://github.com/termux/termux-app/issues/79)).
+  * That .JPG files are not image/jpeg is probably the fault of a library termux uses ([reported](https://github.com/termux/termux-app/issues/721))
+* Some applications can find files from a termux-home out-of-the-box, like the [billthefarmer editor](https://f-droid.org/en/packages/org.billthefarmer.editor/) -- just that if it was just about editing text files, we could just have used ~/storage/shared and plain git.
+* Many applications accept files from there when opened from the file manager (VLC, Simple Gallery, Ghost Commander's picture viewer); I have not found one yet that does not.
+* A good way forward would be to encourage the authors of apps we care about to allow opening SAF locations directly; it appears to me that they sometimes add SAF support for a particular function (eg. to support USB-OTG or writing to external SD cards) and then limit it to that path because the usual other options appear to confusing. [Requested support for it in Simple Gallery](https://github.com/SimpleMobileTools/Simple-Gallery/issues/806), let's see where that takes this.
+"""]]
diff --git a/doc/forum/Dealing_with_crippled_Android_file_system/comment_8_a2bafe08ff3e7a236ba560dafc9c4d85._comment b/doc/forum/Dealing_with_crippled_Android_file_system/comment_8_a2bafe08ff3e7a236ba560dafc9c4d85._comment
new file mode 100644
index 0000000000..87faebd6c2
--- /dev/null
+++ b/doc/forum/Dealing_with_crippled_Android_file_system/comment_8_a2bafe08ff3e7a236ba560dafc9c4d85._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 8"
+ date="2018-06-15T15:59:04Z"
+ content="""
+Oh, Awesome, thanks! Great find. I'll write out some of the things I have tried:
+
+Create a text file called `hi.txt` from Termux in `/data/data/com.termux/files/home` AKA `$HOME`. Launch `Turbo Editor` enable `Use the Storage Access Framework` in Preferences menu. Click `Open a file` | `Open from` `Termux`, click `hi.txt`, edit file, save. Now I can see changes in Termux. Nice.
+
+From Termux create a new soft link, `cd`, `ln -s hi.txt hilink.txt`, then in Turbo Editor I can see both files, I can edit and save either, and see changes correctly in Termux.
+
+I wasn't able to find the Termux `$HOME` folder in any File Manager I tried, nor any Gallery App.
+
+
+
+
+"""]]
diff --git a/doc/forum/Dealing_with_long_filenames.mdwn b/doc/forum/Dealing_with_long_filenames.mdwn
new file mode 100644
index 0000000000..5411c32153
--- /dev/null
+++ b/doc/forum/Dealing_with_long_filenames.mdwn
@@ -0,0 +1,8 @@
+- External HD A: annex (contains files with long paths)
+- External HD B: annex (synced with A, doesn't have the contents for files with long paths)
+- laptop HD: annex     (*syncing with B fails*: paths too long)
+
+How should I resolve this? 
+
+- Can I rename the broken symlinks on B to shorten the paths, and then sync to the laptop? Would this be propagated to A when it's connected again?
+- Can I `git rm too/long/paths` on B and then sync?
diff --git a/doc/forum/Dealing_with_long_filenames/comment_1_373798ea9763d3a0be5ce78f7e3f79f0._comment b/doc/forum/Dealing_with_long_filenames/comment_1_373798ea9763d3a0be5ce78f7e3f79f0._comment
new file mode 100644
index 0000000000..32056270e9
--- /dev/null
+++ b/doc/forum/Dealing_with_long_filenames/comment_1_373798ea9763d3a0be5ce78f7e3f79f0._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-02T18:01:51Z"
+ content="""
+It depends, is it failing because the filenames checked into git are too
+long? Or because the symlinks are links to too long paths?
+
+In the former case, you can `git rename` files as you like.
+As with any change you make to files in a git repository, that will
+propigate to other git repositories in the usual ways.
+
+In the latter case, you might be using a hash like SHA512 that causes
+problimatically long paths, and then `git annex migrate --backend=SHA256` might
+help.
+"""]]
diff --git a/doc/forum/Debugging_Git_Annex.mdwn b/doc/forum/Debugging_Git_Annex.mdwn
new file mode 100644
index 0000000000..fc4d829a2a
--- /dev/null
+++ b/doc/forum/Debugging_Git_Annex.mdwn
@@ -0,0 +1,4 @@
+Hi, 
+May I know, how can I debug git-annex code.
+I am new to Haskell Platform, I would like to know which IDE can be used to debug haskell code.
+Thank You.
diff --git a/doc/forum/Debugging_Git_Annex/comment_1_ce63b2ee641a2338f1ad5ded9e6f09a8._comment b/doc/forum/Debugging_Git_Annex/comment_1_ce63b2ee641a2338f1ad5ded9e6f09a8._comment
new file mode 100644
index 0000000000..84781a00a4
--- /dev/null
+++ b/doc/forum/Debugging_Git_Annex/comment_1_ce63b2ee641a2338f1ad5ded9e6f09a8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="This is not an easy question to answer..."
+ date="2012-06-04T19:49:46Z"
+ content="""
+Do you have a bug in git-annex that you need fixed, or are you just curious?
+"""]]
diff --git a/doc/forum/Debugging_Git_Annex/comment_2_1d70ff052d00f33c34fd45730ea13040._comment b/doc/forum/Debugging_Git_Annex/comment_2_1d70ff052d00f33c34fd45730ea13040._comment
new file mode 100644
index 0000000000..017b34b0de
--- /dev/null
+++ b/doc/forum/Debugging_Git_Annex/comment_2_1d70ff052d00f33c34fd45730ea13040._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlYu7QmD7wrbHWkoxuriaA9XcijM-g5vrQ"
+ nickname="Royal"
+ subject="comment 2"
+ date="2012-06-05T17:19:16Z"
+ content="""
+Hi,
+
+I want to replace rsync with aspera-rsync. Whenever there is file transfer between 2 repositories which are in two different hosts, git-annex will use rsync protocol. I am trying to replace that rsync call with aspera-rsync so that transfer can be more faster. Since I am new to Haskell I am finding difficulties to understand the flow of execution. Is there any way I can debug so that I can get the flow?
+
+Thanks
+"""]]
diff --git a/doc/forum/Debugging_of_transfer_considerations.mdwn b/doc/forum/Debugging_of_transfer_considerations.mdwn
new file mode 100644
index 0000000000..eb75e39772
--- /dev/null
+++ b/doc/forum/Debugging_of_transfer_considerations.mdwn
@@ -0,0 +1,6 @@
+I have a client repository with an archive/ directory. If I let the assistant sync the repos or initiate a manual `git annex sync --content` the contents of the archive directory is filled up.
+
+I can't see why this happens. The repo is a client repo with the standard preferred contents and no required contents onfig.
+One of the files that is wanted has 2 copies in backup repositories (one is trusted and one is reachable and semitrusted). `git annex numcopies` is 2 for one of these files. The repos were checked by `git annex fsck` and synced.
+
+I'm not sure what to look for or how to debug this kind of situation. Any ideas? 
diff --git a/doc/forum/Debugging_of_transfer_considerations/comment_1_e68ab187c15b3b6f9384a990da07f358._comment b/doc/forum/Debugging_of_transfer_considerations/comment_1_e68ab187c15b3b6f9384a990da07f358._comment
new file mode 100644
index 0000000000..ba943b8945
--- /dev/null
+++ b/doc/forum/Debugging_of_transfer_considerations/comment_1_e68ab187c15b3b6f9384a990da07f358._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-06T16:08:55Z"
+ content="""
+Currently the best way to debug this kind of thing is to use git annex find
+with options to find files that match the preferred content expression.
+Once you have gotten git annex find to list the same files that are being
+transferred, you can then modify/cut down the options to narrow down
+what's going on.
+
+The preferred content expression for a client repository is:
+
+	(include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1
+
+Translating this to command-line options:
+
+	git annex find '-(' '--include=*' --and '-(' '-(' '--exclude=*/archive/*' --and '--exclude=archive/*' '-)' --or '-(' --not '-(' --copies=archive:1 --or --copies=smallarchive:1 '-)' '-)' '-)' '-)' --or --approxlackingcopies=1
+
+You'll want to run that when the files are not located in the archive/
+directory, and run it from the top of the repository.
+
+Assuming that lists the files that are getting transferred, then you can
+split it into two commands, each of which checks one of the two parts
+of the expression that are ORed together:
+
+	git annex find '-(' '--include=*' --and '-(' '-(' '--exclude=*/archive/*' --and '--exclude=archive/*' '-)' --or '-(' --not '-(' --copies=archive:1 --or --copies=smallarchive:1 '-)' '-)' '-)' '-)'
+	git annex find --approxlackingcopies=1
+
+Assuming the first of those lists the files and not the second, you can
+then split it further. The include=* part must be matching then, so
+checking two parts ORed within the second part:
+	
+	git annex find '-(' '--exclude=*/archive/*' --and '--exclude=archive/*' '-)'
+	git annex find '-(' --not '-(' --copies=archive:1 --or --copies=smallarchive:1 '-)' '-)'
+
+Probably one of those will list the files and the other won't.
+Which will point fairly strongly at what's happening.
+"""]]
diff --git a/doc/forum/Debugging_of_transfer_considerations/comment_2_f7cd207b08fe365d0a6248316c91ed78._comment b/doc/forum/Debugging_of_transfer_considerations/comment_2_f7cd207b08fe365d0a6248316c91ed78._comment
new file mode 100644
index 0000000000..d95274ef52
--- /dev/null
+++ b/doc/forum/Debugging_of_transfer_considerations/comment_2_f7cd207b08fe365d0a6248316c91ed78._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Horus"
+ avatar="http://cdn.libravatar.org/avatar/8f0ee08b98ea5bba76c3fe112c08851c"
+ subject="comment 2"
+ date="2017-03-14T08:58:54Z"
+ content="""
+Maybe it's the problem that the client group requires a file in archive/ to reach a archive repo, not a backup repo. To combine the behavior of both, I have set the group to archive and wanted to anything.
+"""]]
diff --git a/doc/forum/Debugging_of_transfer_considerations/comment_3_508b5b4155f0f9c0c2a7d2e990a1bf92._comment b/doc/forum/Debugging_of_transfer_considerations/comment_3_508b5b4155f0f9c0c2a7d2e990a1bf92._comment
new file mode 100644
index 0000000000..99a8be0a18
--- /dev/null
+++ b/doc/forum/Debugging_of_transfer_considerations/comment_3_508b5b4155f0f9c0c2a7d2e990a1bf92._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-04-07T20:26:54Z"
+ content="""
+Yes, files in archive/ directories are only dropped from clients once they
+reach an archive. Backup repositories are not considered to be archives.
+
+Of course, you can tweak the preferred content expressions to change this
+behavior.
+
+I don't know if the arhive vs backup distinction makes sense really but
+I have heard of some users doing things that depend on it.
+"""]]
diff --git a/doc/forum/Deduplication_in_direct_mode.mdwn b/doc/forum/Deduplication_in_direct_mode.mdwn
new file mode 100644
index 0000000000..076d0ab5a2
--- /dev/null
+++ b/doc/forum/Deduplication_in_direct_mode.mdwn
@@ -0,0 +1,18 @@
+Hi,
+
+I'm using git-annex across a number of (indirect) repositories, making heavy use of deduplication for organizing files according to various different aspects.
+
+Now I want to keep part of the files also on a VFAT device, which doesn't let me use indirect mode.  In direct mode, however, git-annex "get" or "copy" places a separate copy of each file in the repository, whereas in indirect mode, it would just keep a single copy and maintain a number of (inexpensive) symbolic links.  Since space on the VFAT drive is limited, I would like to just keep one, specific copy, not caring about the others.  If I "drop" an unneeded copy of the file, it also gets replaced by the ASCII "link" in all other places that contained the same file.  Therefore, I can either have multiple copies of the same data or none at all.
+
+Imagine you have a bunch of photos sorted into a directories in meant to make it easy to find them (same file name means same file content):
+
+./photo1.jpg
+./photo2.jpg
+./by-date/2014-10-27/photo1.jpg
+./by-date/2014-10-28/photo2.jpg
+./by-event/holiday-by-the-sea/photo1.jpg
+./by-event/her-birthday/photo2.jpg
+
+I want to keep a copy of ./photo?.jpg in the VFAT repository, but not the other (identical) files.  How do I do that?  Or is there really no way of doing this?
+
+Thanks.
diff --git a/doc/forum/Deduplication_in_direct_mode/comment_1_cb8eaa8c19f5bb9e145a5e4c8995a8ca._comment b/doc/forum/Deduplication_in_direct_mode/comment_1_cb8eaa8c19f5bb9e145a5e4c8995a8ca._comment
new file mode 100644
index 0000000000..63367fcc14
--- /dev/null
+++ b/doc/forum/Deduplication_in_direct_mode/comment_1_cb8eaa8c19f5bb9e145a5e4c8995a8ca._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-31T20:15:58Z"
+ content="""
+There is really no way to do this.
+
+We could consider hard-linking the files, but then modifying one would
+modify the other, which is likely to be confusing. And, FAT doesn't support
+hard links anyway.
+
+I don't want to complicate git-annex's notion of whether an object is
+present or not with the possibility that it might be present for some
+files but not for others. For example, `git annex get` would then need
+to make a copy of content that was already locally present, while
+currently it knows that if the file is locally present, it has nothing to
+do.
+
+I think that the solution is to use either a better filesystem
+which can support the suprerior indirect mode, or to switch your
+repository to use the WORM backend which does not do deduplication.
+"""]]
diff --git a/doc/forum/Default_annex.largefiles.mdwn b/doc/forum/Default_annex.largefiles.mdwn
new file mode 100644
index 0000000000..9da3220e68
--- /dev/null
+++ b/doc/forum/Default_annex.largefiles.mdwn
@@ -0,0 +1 @@
+I'm new to git annex, so if this has been discussed before, please forgive me.  The documentation of annex.largefiles seems to say that all files are added to the annex by default.  However, when I tried it, several of my smaller files were not added to the annex.  I admit that I haven't tried changing this value yet.  Has the default changed?  I'm using the package from Arch AUR git-annex-bin. Possibly this version has a different default?
diff --git a/doc/forum/Default_annex.largefiles/comment_1_74a3ad2388e41f1ff17f64a00485a35a._comment b/doc/forum/Default_annex.largefiles/comment_1_74a3ad2388e41f1ff17f64a00485a35a._comment
new file mode 100644
index 0000000000..d57e4f71d3
--- /dev/null
+++ b/doc/forum/Default_annex.largefiles/comment_1_74a3ad2388e41f1ff17f64a00485a35a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-20T15:26:35Z"
+ content="""
+The default is to treat all files as "large", so any file it sees
+should be added, except for those that are `.gitignored`.
+"""]]
diff --git a/doc/forum/Default_text__47__html_handler.mdwn b/doc/forum/Default_text__47__html_handler.mdwn
new file mode 100644
index 0000000000..a6bf4aaab9
--- /dev/null
+++ b/doc/forum/Default_text__47__html_handler.mdwn
@@ -0,0 +1,2 @@
+I've had to change my default `text/html .html` handler from a text editor to a browser to support the opening sequence of `git annex webapp`. any other way around this? perhaps to have it open the page in the default browser rather than the default text/html handler?
+
diff --git a/doc/forum/Default_text__47__html_handler/comment_1_4730061916c7e12b7a41906152f847ee._comment b/doc/forum/Default_text__47__html_handler/comment_1_4730061916c7e12b7a41906152f847ee._comment
new file mode 100644
index 0000000000..e2424f1ccc
--- /dev/null
+++ b/doc/forum/Default_text__47__html_handler/comment_1_4730061916c7e12b7a41906152f847ee._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.11.120"
+ subject="comment 1"
+ date="2012-11-13T17:25:07Z"
+ content="""
+Not without exposing the secret token to other users in the system by passing it as a parameter to the browser command. Which is why it uses the method it does.
+
+But, you can configure it to use a specific browser in the standard git way:
+
+git config web.browser chromium
+"""]]
diff --git a/doc/forum/Delete_unused_files__47__metadata.mdwn b/doc/forum/Delete_unused_files__47__metadata.mdwn
new file mode 100644
index 0000000000..5c6b413996
--- /dev/null
+++ b/doc/forum/Delete_unused_files__47__metadata.mdwn
@@ -0,0 +1,7 @@
+After moving some files (about 1G, some big and some small files) in and out the annex, I noticed that the size of the repository has grown quite a bit. My empty repository now is over 100 MB (even after  "git annex dropunused ..." and "git gc").
+
+Most of this size is not Git metadata but many small files in the git-annex branch that seem to hold information about files I deleted (even in the other known repositories).
+
+So is there a way to get rid of these useless but space consuming information?
+
+(Maybe there is no (elegant) way to remove the symlink versions from the Git history (is there?), but it would already be nice if those small git-annex metadata files could be removed)
diff --git a/doc/forum/Delete_unused_files__47__metadata/comment_1_3efc19895c8dec89b71ae3778b583fea._comment b/doc/forum/Delete_unused_files__47__metadata/comment_1_3efc19895c8dec89b71ae3778b583fea._comment
new file mode 100644
index 0000000000..c0d779abd1
--- /dev/null
+++ b/doc/forum/Delete_unused_files__47__metadata/comment_1_3efc19895c8dec89b71ae3778b583fea._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 1"
+ date="2012-08-07T20:06:26Z"
+ content="""
+You must have quite a number of files and/or location tracking churn to get the branch that large. 
+
+Removing location tracking files for vanished files from the git-annex branch would not save much space.. Only a very little bit of tree object size going forward. The way the git-annex branch is merged does not really allow deleting files from it. And of course git uses space for even deleted files.
+
+It'd be possible to delete the git-annex branch entirely, first backing up git-annex:uuid.log  git-annex:remote.log and git-annex:trust.log and then making a new, clean branch that those files are added back to. Then run git annex fsck on every clone to repopulate the location tracking info for files that still exit. (Note that this would also lose urls stored by `git-annex addurl`.)
+"""]]
diff --git a/doc/forum/Delete_unused_files__47__metadata/comment_2_23597d9468347b3d94257f3c02afe1b8._comment b/doc/forum/Delete_unused_files__47__metadata/comment_2_23597d9468347b3d94257f3c02afe1b8._comment
new file mode 100644
index 0000000000..340debc11e
--- /dev/null
+++ b/doc/forum/Delete_unused_files__47__metadata/comment_2_23597d9468347b3d94257f3c02afe1b8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2012-08-08T14:54:42Z"
+ content="""
+I'm sort of getting into the same issue as I run 'git-annex get .' and 'git annex sync' with one of the annexes that I have on a nightly basis to collect data for back up reasons. But it's good to know there is a work around for it.
+"""]]
diff --git a/doc/forum/Deleting_remotes_doesn__39__t_work__8230__.mdwn b/doc/forum/Deleting_remotes_doesn__39__t_work__8230__.mdwn
new file mode 100644
index 0000000000..012afe8ec0
--- /dev/null
+++ b/doc/forum/Deleting_remotes_doesn__39__t_work__8230__.mdwn
@@ -0,0 +1 @@
+I'm trying to get rid of two remotes through the assistant, but when I'm trying to delete it, it doesn't start deletion process, as far as I can tell, since the symbol where it say syncing enabled/disabled is not changed to "delete" or whatever it is.
diff --git a/doc/forum/Deleting_remotes_doesn__39__t_work__8230__/comment_1_01d244f44d439ad08681af88284103c8._comment b/doc/forum/Deleting_remotes_doesn__39__t_work__8230__/comment_1_01d244f44d439ad08681af88284103c8._comment
new file mode 100644
index 0000000000..3e1f171bd0
--- /dev/null
+++ b/doc/forum/Deleting_remotes_doesn__39__t_work__8230__/comment_1_01d244f44d439ad08681af88284103c8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 1"
+ date="2016-05-12T06:52:50Z"
+ content="""
+This didn't work, because syncing was disabled before trying to delete the remote. Deleting involves putting the remote in the unwanted group and through active syncing remove all the content from it, before deleting it fully. The assistant should be able to handle starting deletion processes, even when synching is disabled. At least there should be a dialogue telling the user that synching is disabled and therefore the deletion process will not start.
+"""]]
diff --git a/doc/forum/Deleting_remotes_doesn__39__t_work__8230__/comment_2_a33c699726e5a913da72671ceb9be989._comment b/doc/forum/Deleting_remotes_doesn__39__t_work__8230__/comment_2_a33c699726e5a913da72671ceb9be989._comment
new file mode 100644
index 0000000000..972db0e058
--- /dev/null
+++ b/doc/forum/Deleting_remotes_doesn__39__t_work__8230__/comment_2_a33c699726e5a913da72671ceb9be989._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-12T19:14:05Z"
+ content="""
+Thanks, good analysis! I've opened a bug about this:
+[[bugs/webapp_should_notice_when_remote_deletion_cannot_complete_due_to_not_syncing]]
+"""]]
diff --git a/doc/forum/Desktop_as_transfer_repository.mdwn b/doc/forum/Desktop_as_transfer_repository.mdwn
new file mode 100644
index 0000000000..bd6813e366
--- /dev/null
+++ b/doc/forum/Desktop_as_transfer_repository.mdwn
@@ -0,0 +1,33 @@
+Hi,
+
+I try to achieve this with my podcast repository:
+
+I have three repositories all in indirect mode:
+
+1. desktop
+2. backup on usb disk at desktop
+3. raspberrypi
+
+I want to use the desktop as transfer repository. 
+
+If I add a new url on the raspberrypi I want to sync the content via the desktop repository to the backup repository which is no directly accessible from the raspberrypi.
+
+If I add a new url on desktop the content should be moved to raspberrypi and backup. 
+
+So I don't want to have the content of the files on the desktop. All content should be in backup. 
+
+If content is not in raspberrypi I want to get it from backup via desktop.
+
+What is the best workflow to achieve this?
+
+Currently my problem is that if I do a "git annex sync --content" the content is also copied to desktop. Maybe because the desktop repo is origin? 
+
+- backup is in group backup
+- desktop is in group transfer
+- raspberrypi is in no special group
+
+To do further experiments I need a way to see in what group a repo is, but "git annex show" has no information about this.
+
+TIA
+
+juh
diff --git a/doc/forum/Desktop_as_transfer_repository/comment_1_b211b8f0ab58b8e59ce31d6ed6cb3c8c._comment b/doc/forum/Desktop_as_transfer_repository/comment_1_b211b8f0ab58b8e59ce31d6ed6cb3c8c._comment
new file mode 100644
index 0000000000..afce0e5674
--- /dev/null
+++ b/doc/forum/Desktop_as_transfer_repository/comment_1_b211b8f0ab58b8e59ce31d6ed6cb3c8c._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="juh"
+ subject="My current workflow"
+ date="2015-11-17T14:47:59Z"
+ content="""
+Ok,
+
+here is my current workflow to clarify my problem:
+
+On raspberrypi:
+
+    Adding new podcasts
+    git annex sync
+
+On desktop:
+
+    git annex sync
+    git annex get --want-get
+
+New podcast content from raspberrypi is downloaded.
+
+In backup:
+
+    git annex sync
+    git annex get --want-get
+
+New podcast content from desktop is downloaded.
+
+On desktop:
+
+    git annex drop
+
+Everything on desktop is dropped.
+
+**Now the problem**
+
+Next time I do 
+
+    git annex get --want-get
+
+on **desktop** all files are downloaded again from either backup or raspberrypi.
+
+What can I do to have only content in desktop that is not in the raspberrypi repository or in the backup repository? 
+
+I thought that this is the behaviour of a transfer repository.
+"""]]
diff --git a/doc/forum/Desktop_as_transfer_repository/comment_2_9a943bcfe7679e469acc6fa1f78324b7._comment b/doc/forum/Desktop_as_transfer_repository/comment_2_9a943bcfe7679e469acc6fa1f78324b7._comment
new file mode 100644
index 0000000000..93e0778e3e
--- /dev/null
+++ b/doc/forum/Desktop_as_transfer_repository/comment_2_9a943bcfe7679e469acc6fa1f78324b7._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-11-18T17:15:34Z"
+ content="""
+I suspect that if you run `git annex drop --auto` on desktop, it won't drop
+any files. This is because it's configured as a transfer repository, and
+transfer repositories wait for files to reach all client repositories
+before wanting to drop them.
+
+Since you have no client repositories, your transfer repository will prefer
+to hang onto files. In fact, transfer repositories assume there will
+eventually be at least 2 client repositories (otherwise what good would a
+transfer repository between clients be?) and so hang onto files that are
+not in 2 clients, even when less than 2 clients exist yet. That is generally
+useful behavior when setting things up in eg the webapp.
+
+So, the standard preferred content expression for a transfer repository
+won't work in this configuration. Let's instead express the things you want
+as a custom setting.
+
+> If I add a new url on desktop the content should be moved to raspberrypi and backup.
+> 
+> So I don't want to have the content of the files on the desktop. All
+> content should be in backup.
+> 
+> If content is not in raspberrypi I want to get it from backup via desktop.
+
+	git annex wanted desktop "not (inallgroup=backup and inallgroup=client)"
+
+That assumes you put the raspberrypi in the client group, which is what I think it
+basically is. Then desktop will want to get and hold any files that
+have not yet reached all backup and client repositories, at which point
+desktop will drop files.
+"""]]
diff --git a/doc/forum/Desktop_as_transfer_repository/comment_3_17165386df0c8c0085de29659f46f084._comment b/doc/forum/Desktop_as_transfer_repository/comment_3_17165386df0c8c0085de29659f46f084._comment
new file mode 100644
index 0000000000..d29067480c
--- /dev/null
+++ b/doc/forum/Desktop_as_transfer_repository/comment_3_17165386df0c8c0085de29659f46f084._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="juh"
+ subject="Thanks"
+ date="2015-11-19T08:01:09Z"
+ content="""
+This line seems to do the trick. The flexibility of git annex is amazing – and frightening. I fear I would have never found the line by myself.
+"""]]
diff --git a/doc/forum/Desktop_as_transfer_repository/comment_4_986e7d7bb536685f48731ffbbab4dc7c._comment b/doc/forum/Desktop_as_transfer_repository/comment_4_986e7d7bb536685f48731ffbbab4dc7c._comment
new file mode 100644
index 0000000000..89b773a5f1
--- /dev/null
+++ b/doc/forum/Desktop_as_transfer_repository/comment_4_986e7d7bb536685f48731ffbbab4dc7c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-12-02T17:29:25Z"
+ content="""
+It should, in theory, be possible to read [[preferred_content]] and learn
+how to write such an expression. Of course, it is a limited form of
+programming, and so not for everyone. Which is why git-annex ships with
+standard expressions to cover as many common cases as we can think of.
+"""]]
diff --git a/doc/forum/Detached_git_work_tree__63__.mdwn b/doc/forum/Detached_git_work_tree__63__.mdwn
new file mode 100644
index 0000000000..3c1f6ae249
--- /dev/null
+++ b/doc/forum/Detached_git_work_tree__63__.mdwn
@@ -0,0 +1,11 @@
+Does git-annex (safely) handle detached work trees?
+
+That is, in git I can set `GIT_WORK_TREE=/dir/A` and `GIT_DIR=/dir/B` in the environment and have all my .git stuff in /dir/B and all my files in /dir/A.
+
+I can see this coming in useful for a few situations, but in particular for difficult file systems - like SMB or old implementations of NFS.
+
+In my particular case I have a Drobo (something like a proprietary NAS).  The Drobo is linux based, but by default mounts as a samba share or if you install `unfsd` it can be mounted via NFS.  Unfortunately, the nfs is v3 and doesn't allow locks, so git-annex barfs.  :-(
+
+What I'd like to be able to do is have a direct mode annex on the drobo, with the git directory sitting on one of my linux machines.  That machine would be the only one that would directly access the drobo data as an annex but other systems that look at the drobo would see what looks like a normal directory structure; for example my media centre - `mythtv` naturally! - would see "normal" names for my music collection, not SHA256 hashes...
+
+I guess there would be an issue if there were different `GIT_DIR`s pointing to the one `GIT_WORK_TREE`, but that is a caveat emptor IMHO. 
diff --git a/doc/forum/Detached_git_work_tree__63__/comment_10_656c737772bf92be2c7a2f33bd2bb0f0._comment b/doc/forum/Detached_git_work_tree__63__/comment_10_656c737772bf92be2c7a2f33bd2bb0f0._comment
new file mode 100644
index 0000000000..0bf9c12f45
--- /dev/null
+++ b/doc/forum/Detached_git_work_tree__63__/comment_10_656c737772bf92be2c7a2f33bd2bb0f0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlRThEwuPnr8_bcuuCTQ0rQd3w6AfeMiLY"
+ nickname="Alex"
+ subject="comment 10"
+ date="2013-02-24T12:04:21Z"
+ content="""
+Been using it a few hours now and it works like a charm - first thing I did was get a sitemap of the LCA and FOSDEM talks and use addurl --fast on them, since I've been wanting to do that since I saw the lightning talk last year at FOSDEM.
+
+Thanks again for making this awesome utility!
+"""]]
diff --git a/doc/forum/Detached_git_work_tree__63__/comment_1_28ac35a325fba250721d9f1b7c994960._comment b/doc/forum/Detached_git_work_tree__63__/comment_1_28ac35a325fba250721d9f1b7c994960._comment
new file mode 100644
index 0000000000..83721eac36
--- /dev/null
+++ b/doc/forum/Detached_git_work_tree__63__/comment_1_28ac35a325fba250721d9f1b7c994960._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 1"
+ date="2013-01-14T16:32:51Z"
+ content="""
+Recent versions of git-annex support these variables. I haven't tested it extensively, but AFAIK it works.
+"""]]
diff --git a/doc/forum/Detached_git_work_tree__63__/comment_2_7128c26bbc8efea04a5a317edf0ca9f2._comment b/doc/forum/Detached_git_work_tree__63__/comment_2_7128c26bbc8efea04a5a317edf0ca9f2._comment
new file mode 100644
index 0000000000..e9154c6933
--- /dev/null
+++ b/doc/forum/Detached_git_work_tree__63__/comment_2_7128c26bbc8efea04a5a317edf0ca9f2._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlRThEwuPnr8_bcuuCTQ0rQd3w6AfeMiLY"
+ nickname="Alex"
+ subject="Having issues here"
+ date="2013-02-23T14:44:15Z"
+ content="""
+I'm trying to use git-annex with vcsh, and it doesn't seem to be respecting the GIT_WORK_TREE and GIT_DIR variables vcsh sets. If I try it manually, the same happens.
+
+Any time I try to invoke a git-annex subcommand (init, add) via vcsh (vcsh $repo annex init/add/etc) it spits out an error that \"git-annex: Not in a git repository.\"
+
+I'd really like this to work, so that I can manage the bigger files in my home with topic-based annexes alongside plain-git repos for dotfiles.
+
+"""]]
diff --git a/doc/forum/Detached_git_work_tree__63__/comment_3_a3c22f905748ff2c803e8621c74a87a0._comment b/doc/forum/Detached_git_work_tree__63__/comment_3_a3c22f905748ff2c803e8621c74a87a0._comment
new file mode 100644
index 0000000000..0e59edd76e
--- /dev/null
+++ b/doc/forum/Detached_git_work_tree__63__/comment_3_a3c22f905748ff2c803e8621c74a87a0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.253.75"
+ subject="comment 3"
+ date="2013-02-23T15:01:57Z"
+ content="""
+@Alex, you forgot to say what version of git-annex you are having trouble with.
+"""]]
diff --git a/doc/forum/Detached_git_work_tree__63__/comment_4_8063921241760458349e7cb0cadf3d4e._comment b/doc/forum/Detached_git_work_tree__63__/comment_4_8063921241760458349e7cb0cadf3d4e._comment
new file mode 100644
index 0000000000..b0d8fcd419
--- /dev/null
+++ b/doc/forum/Detached_git_work_tree__63__/comment_4_8063921241760458349e7cb0cadf3d4e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlRThEwuPnr8_bcuuCTQ0rQd3w6AfeMiLY"
+ nickname="Alex"
+ subject="comment 4"
+ date="2013-02-23T15:07:52Z"
+ content="""
+3.20130216.1 from Hackage - I packaged it for Exherbo specifically to try this, and installed it about two hours ago.
+"""]]
diff --git a/doc/forum/Detached_git_work_tree__63__/comment_5_4510a787255cb03e7d0c3e7b830b7d52._comment b/doc/forum/Detached_git_work_tree__63__/comment_5_4510a787255cb03e7d0c3e7b830b7d52._comment
new file mode 100644
index 0000000000..693e8ef4dd
--- /dev/null
+++ b/doc/forum/Detached_git_work_tree__63__/comment_5_4510a787255cb03e7d0c3e7b830b7d52._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.253.75"
+ subject="comment 5"
+ date="2013-02-23T16:44:48Z"
+ content="""
+So, I found and fixed that bug. It really seems to be working now. Although I've thought that at least twice before!
+
+There is an important caveat though, with using `GIT_DIR` and/or `GIT_WORK_TREE`.
+
+git-annex needs to check in symlinks that point at the git repository. If using `GIT_DIR`, those symlinks do not look like \"-> .git/annex/objects/\"; they instead point off to some git repository elsewhere, as a relative path. For example they could look like \"-> ../gitrepo/annex/objects/\". Similar when using `GIT_WORK_TREE`.
+
+But this is a problem if you want to use the same git repo elsewhere, with a git work tree and repo that are not set up the same relative to one-another, because the links will all be wrong. So, if you decide to use `GIT_DIR` or `GIT_WORK_TREE` with git-annex, any clone of the repository will need to place the git directory in the same place relative to the working tree. 
+
+If you later want to change the relative paths between git directory and work tree, it would need to be changed in all clones of the repository, and then you could use `git annex fix` to update the symlinks.
+"""]]
diff --git a/doc/forum/Detached_git_work_tree__63__/comment_6_ffd9c67ecc5b46ae98996018573f5591._comment b/doc/forum/Detached_git_work_tree__63__/comment_6_ffd9c67ecc5b46ae98996018573f5591._comment
new file mode 100644
index 0000000000..faecbf2f55
--- /dev/null
+++ b/doc/forum/Detached_git_work_tree__63__/comment_6_ffd9c67ecc5b46ae98996018573f5591._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlRThEwuPnr8_bcuuCTQ0rQd3w6AfeMiLY"
+ nickname="Alex"
+ subject="comment 6"
+ date="2013-02-23T21:23:18Z"
+ content="""
+Cool, thanks! The caveat shouldn't be much of a problem for my use case - with vcsh, the workdir is always $HOME, and I'm using the recommended mr-based workflow so the gitdir will always be ~/.config/vcsh/repo.d/$name.git in each clone.
+
+EDIT: fix erroneous path
+"""]]
diff --git a/doc/forum/Detached_git_work_tree__63__/comment_7_36ca007643c983604fc4aed6ec8cb3d2._comment b/doc/forum/Detached_git_work_tree__63__/comment_7_36ca007643c983604fc4aed6ec8cb3d2._comment
new file mode 100644
index 0000000000..9e5d241a25
--- /dev/null
+++ b/doc/forum/Detached_git_work_tree__63__/comment_7_36ca007643c983604fc4aed6ec8cb3d2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlRThEwuPnr8_bcuuCTQ0rQd3w6AfeMiLY"
+ nickname="Alex"
+ subject="Further possible issues"
+ date="2013-02-23T23:17:43Z"
+ content="""
+Mm, looking at the actual code changes it may still not work with vcsh - since multiple GIT_DIRS share one GIT_WORKTREE, some symlinks will point to ~/.config/vcsh/repo.d/foo.git and some will point to ~/.config/vcsh/repo.d/bar.git. When git annex is invoked with GIT_DIR='~/.config/vcsh/repo.d/bar.git', with the changes you made files annexed by ~/.config/vcsh/repo.d/foo.git will still match isLinkToAnnex.
+"""]]
diff --git a/doc/forum/Detached_git_work_tree__63__/comment_8_b7a2da4fbace7156e11c48a496a19dc9._comment b/doc/forum/Detached_git_work_tree__63__/comment_8_b7a2da4fbace7156e11c48a496a19dc9._comment
new file mode 100644
index 0000000000..7d9d13a7a6
--- /dev/null
+++ b/doc/forum/Detached_git_work_tree__63__/comment_8_b7a2da4fbace7156e11c48a496a19dc9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.210"
+ subject="comment 8"
+ date="2013-02-23T23:23:01Z"
+ content="""
+That should not be a problem, because git-annex only acts on files that `git ls-files` lists.
+"""]]
diff --git a/doc/forum/Detached_git_work_tree__63__/comment_9_f9fa237a693d28178f0451799209f7e2._comment b/doc/forum/Detached_git_work_tree__63__/comment_9_f9fa237a693d28178f0451799209f7e2._comment
new file mode 100644
index 0000000000..16702141c0
--- /dev/null
+++ b/doc/forum/Detached_git_work_tree__63__/comment_9_f9fa237a693d28178f0451799209f7e2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlRThEwuPnr8_bcuuCTQ0rQd3w6AfeMiLY"
+ nickname="Alex"
+ subject="comment 9"
+ date="2013-02-24T00:52:52Z"
+ content="""
+Alright then, sounds like it should be perfect! Thanks for the quick response!
+"""]]
diff --git a/doc/forum/Difference_between_copy__44___move_and_get__63__.mdwn b/doc/forum/Difference_between_copy__44___move_and_get__63__.mdwn
new file mode 100644
index 0000000000..a94281a1fc
--- /dev/null
+++ b/doc/forum/Difference_between_copy__44___move_and_get__63__.mdwn
@@ -0,0 +1,24 @@
+I'm starting to experiment with git annex.  I'd like to use it for a centralized git repo that will be checked out often, but the clones will rarely need some large binary files (used for testing).  Therefore, I've set up a centralized/bare git repo and a clone of that repo using the instructions at [centralized_git_repository_tutorial](http://git-annex.branchable.com/tips/centralized_git_repository_tutorial/) and [bare_repositories](http://git-annex.branchable.com/bare_repositories/).  I've added some files to the annex in the clone.
+
+I'm struggling to understand the difference between copy, move, and get.  Here's a sequence of commands:
+
+    >> git annex add shared/1bel.maegz
+    >> git commit -m "added first file"
+    >> git push
+    >> git annex move shared/1bel.maegz --to origin
+    ## Now it no longer exists in my local repo
+    >> git annex get shared/1bel.maegz
+    fails.
+    >> git annex get shared/1bel.maegz --from origin
+    fails.
+    >> git annex copy shared/1bel.maegz --from origin
+    fails.
+    >> git annex move shared/1bel.maegz --from origin
+    succeeds! Now I have the file in my clone.
+
+Each failure message is:
+
+    fatal: Could not switch to '../.git/annex/objects/W8/gZ/SHA256-s99196--62874e9b58e652c9c01e796c2bf38b2234a80e0cef95c185bb7f0857d9765df2': No such file or directory
+    git-annex: <file descriptor: 6>: hGetLine: end of file
+
+How are copy, move, and get different? Which one *should* I be using to move my large data into the central (bare) repo?  Will it then be available to other clones?
diff --git a/doc/forum/Difference_between_copy__44___move_and_get__63__/comment_1_26ee8192af3a62178c1ccf17c6da5ca5._comment b/doc/forum/Difference_between_copy__44___move_and_get__63__/comment_1_26ee8192af3a62178c1ccf17c6da5ca5._comment
new file mode 100644
index 0000000000..fb1aed5da1
--- /dev/null
+++ b/doc/forum/Difference_between_copy__44___move_and_get__63__/comment_1_26ee8192af3a62178c1ccf17c6da5ca5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-09T02:00:11Z"
+ content="""
+There is no particular reason to use any of copy, move, or get. Use which ever command makes sense at the time.
+
+The problem you're encoutering is that you have an old, and broken version of git-annex installed. Upgrade and the error message will go away and both get and copy, in your example, will work.
+"""]]
diff --git a/doc/forum/Differences_between_unlocked_and_directory_remote.mdwn b/doc/forum/Differences_between_unlocked_and_directory_remote.mdwn
new file mode 100644
index 0000000000..31c2b5d71a
--- /dev/null
+++ b/doc/forum/Differences_between_unlocked_and_directory_remote.mdwn
@@ -0,0 +1,7 @@
+As I am beginning to experiment with git-annex, I am trying to imagine a system as hand-free as possible, that could be usable even for non-git users once everything is setup. Knowing the safety limitations of using files directly, I tend towards using either an unlocked adjusted branch with annex.thin, or a directory special remote (exporttree=yes, importtree=yes), as git-annex will operate further away from the tracked data.
+
+The setup will include multiple computers sharing the same tree, which will have multiple copies across other servers. As each computer will have a different set of prefered content rules, it is important to see missing files.
+
+I feel that the unlocked mode is the safer option, but there is the appeal in having files mostly untouched as in the directory special remote.
+
+How do both methods compare from a user perspective? What are their limitations? Is there a way to show hidden files on a directory special remote (as [drafted](https://git-annex.branchable.com/design/assistant/desymlink/))?
diff --git a/doc/forum/Differences_between_unlocked_and_directory_remote/comment_1_6f4501e32029b1dbb52c9a7b4d2f17a0._comment b/doc/forum/Differences_between_unlocked_and_directory_remote/comment_1_6f4501e32029b1dbb52c9a7b4d2f17a0._comment
new file mode 100644
index 0000000000..47ed0948af
--- /dev/null
+++ b/doc/forum/Differences_between_unlocked_and_directory_remote/comment_1_6f4501e32029b1dbb52c9a7b4d2f17a0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-07-30T06:53:57Z"
+ content="""
+I'd just go with `git annex config --set annex.addunlocked true` and have the assistant run on all machines. I wouldn't use `annex.thin`, though it's appealing to not have files use twice their size, but it is insecure and can easily cause data loss. If possible, I'd also not use an adjusted unlocked branch, because that's yet another layer of complexity where things could go wrong. It usually works, but can also produce weirdness (e.g. there was a bug fixed lately where rexent changes were deleted when syncing an unlocked branch).
+
+Plain git remotes on all sides work most reliably, safely and efficiently with git annex in my experience.
+"""]]
diff --git a/doc/forum/Differences_between_unlocked_and_directory_remote/comment_2_164489438245c38383645822a93cb80c._comment b/doc/forum/Differences_between_unlocked_and_directory_remote/comment_2_164489438245c38383645822a93cb80c._comment
new file mode 100644
index 0000000000..366cbef789
--- /dev/null
+++ b/doc/forum/Differences_between_unlocked_and_directory_remote/comment_2_164489438245c38383645822a93cb80c._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-08-22T16:11:56Z"
+ content="""
+The directory special remote with `importtree=yes exporttree=yes` is indeed
+getting fairly close to feature parity with using all unlocked files with
+`annex.thin` set.
+
+One big difference is that such a special remote will always be untrusted.
+Which might prevent dropping files from elsewhere.
+
+Importing from the directory special remote is slower than just running
+`git commit`. And it probably always will be; git is just fast. 
+Although importing was sped up significantly a few months ago.
+
+Using annex.thin needs the filesystem to support hard links, or git-annex
+stores 2 copies of every file. This is the main reason I'd use a directory
+special remote instead sometimes, when using a filesystem like FAT.
+
+Another reason is if there's some requirement that the directory *not* be a
+git repository. Eg, if it's published by a web server, but you don't want
+to publish all the git history.
+
+Otherwise, I'd always prefer the git repository.
+"""]]
diff --git a/doc/forum/Different_annexes_pointing_to_same_special_remote__63__.mdwn b/doc/forum/Different_annexes_pointing_to_same_special_remote__63__.mdwn
new file mode 100644
index 0000000000..8413a6e08a
--- /dev/null
+++ b/doc/forum/Different_annexes_pointing_to_same_special_remote__63__.mdwn
@@ -0,0 +1,6 @@
+Is there likely to be any problem in pointing different annexes to the same special remote (i.e. rsync/box.com/etc.) ?
+
+As the objects are stored based on their SHA256 key the expectation is that the chance of collision is is small.
+
+The only problem I can foresee is where the same content is stored in more than one annex and it is deleted in the remote in one annex, but not the other - there won't be any protection against that, but for non-overlapping content this risk should be negligible.
+
diff --git a/doc/forum/Different_annexes_pointing_to_same_special_remote__63__/comment_1_359f46805e6508d03aadd90429937546._comment b/doc/forum/Different_annexes_pointing_to_same_special_remote__63__/comment_1_359f46805e6508d03aadd90429937546._comment
new file mode 100644
index 0000000000..282ed82c8b
--- /dev/null
+++ b/doc/forum/Different_annexes_pointing_to_same_special_remote__63__/comment_1_359f46805e6508d03aadd90429937546._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.210"
+ subject="comment 1"
+ date="2013-02-24T21:51:19Z"
+ content="""
+You're basically right. Additionally, if you use encryption, the keys used on the remote are themselves encrypted and so even the same content will result in different keys.
+
+With this said, it's easy to use a subdirectory of a rsync or box.com remote, and I'd rather recommend doing that, rather than jumbling multiple repositories data into a single directory.
+"""]]
diff --git a/doc/forum/Different_branches_for_different_devices__63__.mdwn b/doc/forum/Different_branches_for_different_devices__63__.mdwn
new file mode 100644
index 0000000000..4b9154aa5a
--- /dev/null
+++ b/doc/forum/Different_branches_for_different_devices__63__.mdwn
@@ -0,0 +1,17 @@
+Hi,
+
+I'm currently trying to figure out how to best use git-annex for my needs. And I have a specific use case on which I can't really wrap my head around:
+
+Having a large photo library that collects all photos from all my devices.
+
+What's special about that? Some devices (e.g. mobile phone, laptop, laptop at work) should have/keep their own "view" on the data. Meaning that, e.g., on my laptop at work I don't want to have private pictures, but I might want to have work pictures on my private laptop. Similar for my mobile phone: I want to have all photos for my mobile phone on my laptop, but I don't want all pictures I have ever made on my (tiny) phone.
+
+So, first of all, git-annex supports get, drop, preferred content, etc. which makes it perfect for this use case. Still there is one problem: It's not only that I don't want the content on some devices, I also don't want the respective directory names, simlinks, etc. Say, a directory name like "crazy party pictures" should not be visible on my work laptop, at all...
+
+For me, using directories like "phone", "work", etc. would be a start and a reasonable way to sort which content should be available on these devices. However, as far as I know, it's not possible with GIT to just check out a single (or a few) directories. So I thought different branches could be what I want. But I don't understand how I can copy/move content from one branch to another. Or even, how can I see all the content at once on some machines (e.g. private laptop) without switching branches all the time. I could have several copies of the same repo all set to a different branch, but does this make sense..?
+
+I think what I want is similar to git-annex view, but only for its filter capabilities. Still, subdirectories should work the same as before and filenames should not change. Also the repository should still be fully functional and behaving as usual but just hiding some of the content.
+
+Do you people have similar use cases? What are your best practices?
+
+Best, Mario
diff --git a/doc/forum/Different_branches_for_different_devices__63__/comment_1_a7d2c26298e8da715e1deb13baaf002e._comment b/doc/forum/Different_branches_for_different_devices__63__/comment_1_a7d2c26298e8da715e1deb13baaf002e._comment
new file mode 100644
index 0000000000..edeee3b435
--- /dev/null
+++ b/doc/forum/Different_branches_for_different_devices__63__/comment_1_a7d2c26298e8da715e1deb13baaf002e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-05-24T17:41:08Z"
+ content="""
+Don't underestimate the simple power of branches for this kind of thing.
+If you have a limited `phone` branch, you can `git merge` it into a larger
+branch at home.
+"""]]
diff --git a/doc/forum/Different_branches_for_different_devices__63__/comment_2_214c71d2ab43e4d1bf564ea8337909b7._comment b/doc/forum/Different_branches_for_different_devices__63__/comment_2_214c71d2ab43e4d1bf564ea8337909b7._comment
new file mode 100644
index 0000000000..f06be601af
--- /dev/null
+++ b/doc/forum/Different_branches_for_different_devices__63__/comment_2_214c71d2ab43e4d1bf564ea8337909b7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="comment 2"
+ date="2017-05-25T12:01:46Z"
+ content="""
+Hi, thanks for your help.
+
+But I don't get it entirely. Let's say I move photos from the phone folder into another folder (on the laptop, after merging, in the master branch). How do I propagate these changes back into the phone branch? Since, I guess, merging would only work one-way in this setting. Or let's say I want to push a new picture from my laptop into the phone branch, how would I do this?
+"""]]
diff --git a/doc/forum/Different_branches_for_different_devices__63__/comment_3_534f1e2cfcc0b6d184ef4968ec33dc89._comment b/doc/forum/Different_branches_for_different_devices__63__/comment_3_534f1e2cfcc0b6d184ef4968ec33dc89._comment
new file mode 100644
index 0000000000..54642fdb2f
--- /dev/null
+++ b/doc/forum/Different_branches_for_different_devices__63__/comment_3_534f1e2cfcc0b6d184ef4968ec33dc89._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-05-25T17:44:59Z"
+ content="""
+You'd need to checkout the phone branch on the laptop and make the changes
+to it. So there can be some extra work involved since you have to maintain
+two branches. In some cases `git cherry-pick` could be used to pick a
+change from one branch to the other.
+"""]]
diff --git a/doc/forum/Different_preferred_content_for_subdirs.mdwn b/doc/forum/Different_preferred_content_for_subdirs.mdwn
new file mode 100644
index 0000000000..6186443722
--- /dev/null
+++ b/doc/forum/Different_preferred_content_for_subdirs.mdwn
@@ -0,0 +1,13 @@
+I have annex with a subdir documents/ where I set numcopies to 4 using .gitattributes.  I have a bunch of special remotes in an archive group with `(not (copies=archive:2)) or lackingcopies=1` as preferred content expression.
+
+Now, this directory has over 1000 documents in it.  When I run `git annex sync --content`, git annex will try to drop 1000 documents from 5 archive remotes (one by one) since the files are not wanted (copies > 2) BUT it will conclude it can't because I need at least 4 copies.
+
+This creates incredible amount of churn to the point remotes start to rate-limit me because it takes hours to resolve a single sync.
+
+I tried to mess around with `include` and `exclude` but I can't make it work.  Is this even possible?  For example, I tried
+
+    (include="documents/*" and (not (copies=archive:4))) or (exclude="documents/*" and (not (copies=archive:2)))
+
+Now, I would interpret this as "all the files in documents/ with less than 4 copies in archive OR all the files not in documents/ and less than two copies".  But with this expression (and many similar variants) it always tries to drop the 4+ copy files.
+
+Thanks!
diff --git a/doc/forum/Different_preferred_content_for_subdirs/comment_1_5c1e1e6375360cc9416821085b5a68a8._comment b/doc/forum/Different_preferred_content_for_subdirs/comment_1_5c1e1e6375360cc9416821085b5a68a8._comment
new file mode 100644
index 0000000000..8f79912303
--- /dev/null
+++ b/doc/forum/Different_preferred_content_for_subdirs/comment_1_5c1e1e6375360cc9416821085b5a68a8._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-07T16:18:56Z"
+ content="""
+You are not supposed to quote the pattern after 'include='
+
+So, what your expression actually says is if there is a directory
+named `"documents/` that contains files ending in `"`,
+to apply `not (copies=archive:4)`.
+
+I am kind of surprised that the original situation would lead to any churn
+though. It seems like, since it knows there are at most 3, copies, and 4
+copies are required, it should be able to skip trying to drop at all.
+Instead it does unnecessary work. Filed a bug,
+[[bugs/unnecessary_work_when_drop_cannot_possibly_succeed]].
+"""]]
diff --git a/doc/forum/Different_preferred_content_for_subdirs/comment_2_cc72b229b0a9a8f0ae0f42d6c2a145fd._comment b/doc/forum/Different_preferred_content_for_subdirs/comment_2_cc72b229b0a9a8f0ae0f42d6c2a145fd._comment
new file mode 100644
index 0000000000..b1a138befd
--- /dev/null
+++ b/doc/forum/Different_preferred_content_for_subdirs/comment_2_cc72b229b0a9a8f0ae0f42d6c2a145fd._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-02-08T17:06:02Z"
+ content="""
+> When I run `git annex sync --content`, git annex will try to drop 1000
+> documents from 5 archive remotes (one by one) since the files are not
+> wanted (copies > 2) BUT it will conclude it can't because I need at least
+> 4 copies.
+
+I have not been able to reproduce that. There is code that should prevent
+`git-annex sync --content` from doing any work when there are not enough
+other copies for a drop to succeed. 
+
+Here is my test:
+
+	joey@darkstar:/tmp/a>git config annex.numcopies 4
+	joey@darkstar:/tmp/a>git-annex wanted a2 'exclude=*'
+	wanted a2 ok
+	joey@darkstar:/tmp/a>git-annex whereis me
+	whereis me (4 copies)
+	  	6a56d49c-3a9c-4ac6-9137-4d2752b79a9c -- joey@darkstar:/tmp/a4 [a4]
+	   	91960e05-5f2e-4c20-b979-db5df3e8b296 -- joey@darkstar:/tmp/a3 [a3]
+	   	cdc2c29a-12c8-45a0-8289-d00124a1794c -- joey@darkstar:/tmp/a [here]
+	   	e3abed2b-c65b-4e6e-86ac-d527bdb6ca4a -- joey@darkstar:/tmp/a2 [a2]
+	ok
+	joey@darkstar:/tmp/a>git-annex sync --content --no-pull --no-push
+	commit 
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	joey@darkstar:/tmp/a>git config annex.numcopies 3
+	joey@darkstar:/tmp/a>git-annex sync --content --no-pull --no-push
+	commit 
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	drop a2 me (locking a3...) (locking a4...) ok
+	(recording state in git...)
+
+While `git-annex drop` does do excess work in this situation, I've
+concluded that's ok because the user is explicitly asking it to try to
+drop. But `git-annex sync` does not seem to do excess work when the drop
+cannot succeed.
+
+If you can show otherwise, please do...
+"""]]
diff --git a/doc/forum/Different_preferred_content_for_subdirs/comment_3_c6764ea73c13b59645f1b378e77984b6._comment b/doc/forum/Different_preferred_content_for_subdirs/comment_3_c6764ea73c13b59645f1b378e77984b6._comment
new file mode 100644
index 0000000000..9e09b840bb
--- /dev/null
+++ b/doc/forum/Different_preferred_content_for_subdirs/comment_3_c6764ea73c13b59645f1b378e77984b6._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="MatusGoljer1"
+ avatar="http://cdn.libravatar.org/avatar/8152eed1d594c570563ed46e7fd8356f"
+ subject="comment 3"
+ date="2022-05-16T23:37:55Z"
+ content="""
+Hey Joey, thanks for the response.  The syntax without \" was a big surprise!  Removing the quotes seems to make things work as expected.
+
+Plus it seems a big problem was also an incompatibility of the rclone special remote helper and recent rclone update where they changed some output formats and the helper was reporting incorrect results.  There is a bunch of forks with various fixes, it's a shame the original author disappeared.
+
+Thank you so much for your work on git annex!
+Matus.
+"""]]
diff --git a/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__.mdwn b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__.mdwn
new file mode 100644
index 0000000000..47c327f1be
--- /dev/null
+++ b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__.mdwn
@@ -0,0 +1,14 @@
+Hi, I'm using the webapp and created a repository on my local computer. Then I created another remote repository (encrypted remote with gcrypt), this remote repository is selected as type "full backup". 
+
+I've added some files to the local repository, then changed some of them and watched the sync happen. Then I deleted some files, and these also get synced to the remote.
+
+Now, how can I recover those files from the foreign repo, using the webapp or the command line? I could not find any solution.
+
+I tried:
+git log --diff-filter=D --summary
+and then
+git checkout 488408bfcd58eced685d9e3ca5daf55250850f5d -- .
+to recover the file listed in this remote but got the following response:
+fatal: This operation must be run in a work tree
+
+What do I miss and how does the "Restore" part work when using "full backup" remote repository?
diff --git a/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_1_67ac7e8b53a4374baf640d32dac79030._comment b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_1_67ac7e8b53a4374baf640d32dac79030._comment
new file mode 100644
index 0000000000..21adc4ef99
--- /dev/null
+++ b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_1_67ac7e8b53a4374baf640d32dac79030._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.144"
+ subject="comment 1"
+ date="2014-09-25T15:52:04Z"
+ content="""
+Yes, you need to use git to either revert the repository to a previous version that had the file, or perhaps just revert the commit where the file was deleted. Either way, this requires letting git modify files in the repository, which is prevented by direct mode. So, if you can `git annex indirect` to switch to indirect mode, your git commands will work then.
+"""]]
diff --git a/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_2_eb6df2bfcb3892ae22050a8c5f67ee90._comment b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_2_eb6df2bfcb3892ae22050a8c5f67ee90._comment
new file mode 100644
index 0000000000..5963d4b747
--- /dev/null
+++ b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_2_eb6df2bfcb3892ae22050a8c5f67ee90._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="comment 2"
+ date="2014-09-25T19:25:06Z"
+ content="""
+Thanks Joeyh, of course i guess checking stuff in git would then lose my timestamps as in the previous post. I recommend, as a feature request, to make file recovery a bit easier if possible. I'm not a git expert and definitely wont use command line stuff for doing this on the long run, unless some more intuitive commands like \"git annex list-old-versions\" or \"git annex show-deleted\" and then \"git annex restore \"filename\" version_no  etc.
+"""]]
diff --git a/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_3_15f36487383a631f16e041e2885c44ec._comment b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_3_15f36487383a631f16e041e2885c44ec._comment
new file mode 100644
index 0000000000..99dd7e81be
--- /dev/null
+++ b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_3_15f36487383a631f16e041e2885c44ec._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 3"
+ date="2014-10-02T15:40:40Z"
+ content="""
+Using git does not affect the timestamps or other metadata of files stored by git-annex, which git knows nothing about. It will perhaps change the timestamps of the symlinks that git changes. It you really wanted to avoid that, you could `git clone` the repository and do all the git commands in the clone of the repository, without touching the original repo.
+
+Whether commands like `git checkout` and `git revert` are intuitive depends on how intuitive you find git, I suppose. It sure seems more intuitive to me to reuse git commands that work just fine, rather than adding a whole new set of commands.
+"""]]
diff --git a/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_4_9293831aff5b6cef490f65d03638d34d._comment b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_4_9293831aff5b6cef490f65d03638d34d._comment
new file mode 100644
index 0000000000..176c5d915b
--- /dev/null
+++ b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_4_9293831aff5b6cef490f65d03638d34d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="comment 4"
+ date="2014-10-02T21:57:02Z"
+ content="""
+If git-annex target user community are the ones with some level of git know-how, then you may be right. But I'm not one of them. The only time I use git is to clone a repo from the internet when I want to compile latest source code. Nothing more. Reverting etc are alien to me. 
+
+Besides, what happens if there are multiple files in a commit but you want to revert only one file? This may be a stupid question if git is able to filter files when reverting, but accept my apologies if so, since I do not know git.
+
+I simply want to use git-annex to sync files, keeping some versions of the files in case needed.  
+"""]]
diff --git a/doc/forum/Direct_special_remotes.mdwn b/doc/forum/Direct_special_remotes.mdwn
new file mode 100644
index 0000000000..bf80d57f85
--- /dev/null
+++ b/doc/forum/Direct_special_remotes.mdwn
@@ -0,0 +1,26 @@
+I have a NAS at home which I access both as AFP/SMB shares and thru ssh/rsync.  Now, I'd like to keep on using the shares as before, i.e., browsable via AFP/SMB with conventional file names.  Ideally, I'd also like to git-annex some NAS shares, preferably, in direct mode. However, it seems out of the question to install git-annex on the NAS (hopefully, I'm wrong about this in the long run).
+
+Two **non-special remote setups** would be:
+
+1. Mount the share and turn it into a direct mode git annex repo.  Does anybody have experience with this?  I'd suspect this to be very inefficient due to the use of all the files in .git over AFP/SMB.  Configuration as a WORM backend seems to be advised? (Edit: Well, I just tried this and 'git annex init' failed as described in this [forum post](http://git-annex.branchable.com/forum/Can__39__t_init_git_annex/).  So AFP/SMB seem to be non-starters. :-(  Furthermore, AFP/SMB are immediately detected as crippled and set to direct mode automatically.)
+2. Same as 1. but with a local GIT_DIR.  This should work by having .git on the NAS link to the local GIT_DIR.
+
+Alternatively, I could treat my NAS as a [**web special remote**](http://git-annex.branchable.com/tips/using_the_web_as_a_special_remote/).  Some URL schemes come to mind:
+
+* **file:**  This would benefit from some wish list items ([recursive directory remote setup/addurl](http://git-annex.branchable.com/todo/wishlist:_recursive_directory_remote_setup__47__addurl/)).
+* **rsync:** AFAIK not implemented (yet?) as an option for web special remotes.
+* **sftp:** (Might also include ssh access.)
+
+The problem is that the "web semantics" don't really work in my use case:
+
+* Files might change/move on the NAS.
+* I'd like changes (e.g., renamed files) in my local repo to propagate to the NAS.  Currently, git-annex would use git push for this purpose IIUC, however that's not available on the NAS...
+* the web semantics seem to imply that there is exactly one "web" repository (and the URL is fixed)
+
+All of these indicate a mismatch between my use case and web special remotes.
+
+Hence my question: **Would something like a "direct special remote" make sense?**
+
+As a starting point I'd look at a setup similar to 2. above, i.e., a remote "working copy" with local GIT_DIR.  Except that instead of a whole local .git directory a branch in an existing .git dir might be more appropriate...
+
+--Chris
diff --git a/doc/forum/Direct_special_remotes/comment_1_50357130a1c57ad2fab70f71925faf02._comment b/doc/forum/Direct_special_remotes/comment_1_50357130a1c57ad2fab70f71925faf02._comment
new file mode 100644
index 0000000000..09e9771280
--- /dev/null
+++ b/doc/forum/Direct_special_remotes/comment_1_50357130a1c57ad2fab70f71925faf02._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmVICFY2CDP08xdsPr3cgmScomy9HA-1sk"
+ nickname="Andrew"
+ subject="comment 1"
+ date="2013-04-04T00:33:15Z"
+ content="""
+\"Dumb NAS in direct mode, without git-annex installed\" would greatly expand the possible use cases IMO - it would transform git-annex from a distributed filesystem to a general sync tool. Or maybe I'm dreaming.
+"""]]
diff --git a/doc/forum/Direct_special_remotes/comment_2_e94a722ca056a068bcc16eb822008602._comment b/doc/forum/Direct_special_remotes/comment_2_e94a722ca056a068bcc16eb822008602._comment
new file mode 100644
index 0000000000..4b4d8632c8
--- /dev/null
+++ b/doc/forum/Direct_special_remotes/comment_2_e94a722ca056a068bcc16eb822008602._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://pradermecker.myopenid.com/"
+ ip="81.244.179.73"
+ subject="Local rsync ssh remote (I am confused)"
+ date="2013-04-13T17:54:06Z"
+ content="""
+If I understand this right, it is not possible to use git-annex as a simple wrapper around rsync.
+
+My use case is this: I have a music folder on a plug computer running debian squeeze. The plug computer acts as a streaming music server. My wish is to create a local ssh remote to have my laptop git-annex music repo in sync with the plug computer. So ideally I don't want to install git-annex on the plug computer (but git is there so a git bare repo can be used).
+
+According to the UI, if I use \"Pairing with a local computer\", both computers needs to have git-annex installed. If I try \"Remote server\" either I need both machines git-annex aware or I need the content of the plug computer to be encrypted (which is obviously not what I want in this case).
+
+Is the use case supported by the UI ? Should I try with the CLI ?
+
+Thanks for your help
+
+
+"""]]
diff --git a/doc/forum/Direct_special_remotes/comment_4_187036bbfee0508e2914afb51ead3c71._comment b/doc/forum/Direct_special_remotes/comment_4_187036bbfee0508e2914afb51ead3c71._comment
new file mode 100644
index 0000000000..1f62871115
--- /dev/null
+++ b/doc/forum/Direct_special_remotes/comment_4_187036bbfee0508e2914afb51ead3c71._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://pradermecker.myopenid.com/"
+ ip="81.244.190.181"
+ subject="comment 4"
+ date="2013-04-14T09:01:27Z"
+ content="""
+Thanks !
+
+Before trying the CLI, I will install have a go with installing git-annex on the plug computer.
+
+Do you know by any chance if version 3.20120629~bpo60+2 (the available version on squeeze-backport) will be compatible with the current latest release (4.20130405) ?
+
+I guess I am asking if version 3 is compatible with version 4.
+
+
+"""]]
diff --git a/doc/forum/Direct_special_remotes/comment_4_6bfbf60f2061d49b7d34c844e7e1dea2._comment b/doc/forum/Direct_special_remotes/comment_4_6bfbf60f2061d49b7d34c844e7e1dea2._comment
new file mode 100644
index 0000000000..86621a00e3
--- /dev/null
+++ b/doc/forum/Direct_special_remotes/comment_4_6bfbf60f2061d49b7d34c844e7e1dea2._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="andy"
+ ip="99.48.75.171"
+ subject="comment 4"
+ date="2013-04-14T01:07:19Z"
+ content="""
+@pradermecker: I think that the CLI would be able to do what you're describing (to some extent), but the issue is that the filenames it creates will be hashes, and not in the folder pattern that is on your laptop. Of course, if the plug computer uses file metadata to determine file info, and will search a directory tree, then it probably won't care that the files are named strange things.
+
+As a quick example:
+
+I have a repo with three files in it:
+
+    $ ls -R
+    .:
+    File 1  File 2  File 3
+
+I copy those files to a directory remote:
+
+    $ git annex copy --to=test-dir *
+    copy File 1 (to test-dir...) 
+    ok                      
+    copy File 2 (to test-dir...) 
+    ok                      
+    copy File 3 (to test-dir...) 
+    ok                      
+    (Recording state in git...)
+
+Then I look at what's in my directory remote:
+
+    $ cd ../remote
+    $ ls -R
+    .:
+    0d4  d35  f15
+
+    ./0d4:
+    d37
+
+    ./0d4/d37:
+    SHA256-s7--a940d8aadc02f798331b2d46f1a8ad2c9821783060f4a0810da42bf785855c1c
+
+    ./0d4/d37/SHA256-s7--a940d8aadc02f798331b2d46f1a8ad2c9821783060f4a0810da42bf785855c1c:
+    SHA256-s7--a940d8aadc02f798331b2d46f1a8ad2c9821783060f4a0810da42bf785855c1c
+
+    ./d35:
+    55c
+
+    ./d35/55c:
+    SHA256-s7--ab1ad6a49c022416008887464b8dc03b523b9e81530cf47d1f6f7712c1b30955
+
+    ./d35/55c/SHA256-s7--ab1ad6a49c022416008887464b8dc03b523b9e81530cf47d1f6f7712c1b30955:
+    SHA256-s7--ab1ad6a49c022416008887464b8dc03b523b9e81530cf47d1f6f7712c1b30955
+
+    ./f15:
+    3f2
+
+    ./f15/3f2:
+    SHA256-s7--d1993f1115215aa6389e33fa9979fb39bb29e5bed14661baf1cf6af3182f0164
+
+    ./f15/3f2/SHA256-s7--d1993f1115215aa6389e33fa9979fb39bb29e5bed14661baf1cf6af3182f0164:
+    SHA256-s7--d1993f1115215aa6389e33fa9979fb39bb29e5bed14661baf1cf6af3182f0164
+
+I haven't checked, but I think that the assistant will be able to use a special remote that you create from the CLI once you create it.
+
+To create a remote without encryption using the CLI, try a command of the form `git annex initremote remote-name blah blah blah encryption=none`
+Also see the information at [[special_remotes/directory]], [[special_remotes/rsync]], and [[Repo accessible from \"dumb\" client without git-annex]].
+"""]]
diff --git a/doc/forum/Direct_special_remotes/comment_5_69c34c655e4b153dfc0d1b8580091124._comment b/doc/forum/Direct_special_remotes/comment_5_69c34c655e4b153dfc0d1b8580091124._comment
new file mode 100644
index 0000000000..bad1f635cb
--- /dev/null
+++ b/doc/forum/Direct_special_remotes/comment_5_69c34c655e4b153dfc0d1b8580091124._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andy"
+ ip="99.48.75.171"
+ subject="comment 4"
+ date="2013-04-16T07:57:05Z"
+ content="""
+Not I. Sorry. You might want to make a forum post about this, if you haven't already: [[forum]]
+"""]]
diff --git a/doc/forum/Direct_special_remotes/comment_6_b054cfc3d3f81873f3faae7eb4f5337c._comment b/doc/forum/Direct_special_remotes/comment_6_b054cfc3d3f81873f3faae7eb4f5337c._comment
new file mode 100644
index 0000000000..5ade3f1d01
--- /dev/null
+++ b/doc/forum/Direct_special_remotes/comment_6_b054cfc3d3f81873f3faae7eb4f5337c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 6"
+ date="2013-04-16T17:03:36Z"
+ content="""
+Version 3.2012* is compatible with the current version. You can install that version anywhere you don't need the full assistant.
+"""]]
diff --git a/doc/forum/Direct_special_remotes/comment_7_5f9d8a0ef2f13f242594848825d29ee7._comment b/doc/forum/Direct_special_remotes/comment_7_5f9d8a0ef2f13f242594848825d29ee7._comment
new file mode 100644
index 0000000000..fa1f07daac
--- /dev/null
+++ b/doc/forum/Direct_special_remotes/comment_7_5f9d8a0ef2f13f242594848825d29ee7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkI9AR8BqG4RPw_Ov2lnDCJWMuM6WMRobQ"
+ nickname="Dav"
+ subject="Curious to know if there's progress on this"
+ date="2013-12-09T00:49:45Z"
+ content="""
+The above scenario is also quite interesting to me. Similarly running and old OS (Debian 4.x) on a NAS, and it would be great to be able to access files directly (via direct mode) and manage via git annex, along with a true backup elsewhere. Mostly commenting so I'll get emails for further discussion here.
+"""]]
diff --git a/doc/forum/Disable_autoswitching_to_adjusted__40__unlocked__41___branch.mdwn b/doc/forum/Disable_autoswitching_to_adjusted__40__unlocked__41___branch.mdwn
new file mode 100644
index 0000000000..0bb58b5909
--- /dev/null
+++ b/doc/forum/Disable_autoswitching_to_adjusted__40__unlocked__41___branch.mdwn
@@ -0,0 +1,3 @@
+Is it possible to disable the automatic switching to the `adjusted/main(unlocked)` branch? 
+
+Context: For our measurement campaign, have a policy to only use unlocked files anyway and git-annex always initially switching to that adjusted branch is a bit annoying as we have to manually switch back to the default branch - of which the name is not always the same. Because when you `git annex assist` in an empty repo, it first pushes the `synced/main` branch, which makes it the default on the (Gitea) remote, so subsequent `git clone`s use that as default branch. I'd like to avoid the adjusted branch if possible as I have hit some performance / merge conflict situations with it in the past.
diff --git a/doc/forum/Disable_ssl_verification__63__.mdwn b/doc/forum/Disable_ssl_verification__63__.mdwn
new file mode 100644
index 0000000000..1cba94013a
--- /dev/null
+++ b/doc/forum/Disable_ssl_verification__63__.mdwn
@@ -0,0 +1,34 @@
+I'm trying to create an S3 special remote with git annex using the following command:
+
+git annex initremote snd-2020-51-in-progress type=S3 encryption=none public=yes host=s3.ki.se bucket=snd-2020-51-in-progress protocol=https requeststyle=path
+
+The result is the following:
+
+initremote snd-2020-51-in-progress (checking bucket...) (creating bucket in US...)
+git-annex: HttpExceptionRequest Request {
+  host                 = "s3.ki.se"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Date","Tue, 13 Apr 2021 23:21:41 GMT"),("Authorization","<REDACTED>"),("x-amz-acl","public-read")]
+  path                 = "/snd-2020-51-in-progress/"
+  queryString          = ""
+  method               = "PUT"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+}
+ (InternalException (HandshakeFailed (Error_Protocol ("certificate has unknown CA",True,UnknownCa))))
+failed
+
+When I access the S3 bucket using awscli, I use the "--no-verify-ssl" option: 
+
+aws s3 ls s3://snd-2020-51-in-progress/ --no-verify-ssl --endpoint-url https://s3.ki.se
+
+I haven't found anyway to disable ssl verification with git annex. Is this possible? If not, is there any work around?
+
+Thanks!
+
+Best,
+Joe
diff --git a/doc/forum/Disable_ssl_verification__63__/comment_1_39af4df2a16e363f93f75a7a57af048c._comment b/doc/forum/Disable_ssl_verification__63__/comment_1_39af4df2a16e363f93f75a7a57af048c._comment
new file mode 100644
index 0000000000..92261c9e12
--- /dev/null
+++ b/doc/forum/Disable_ssl_verification__63__/comment_1_39af4df2a16e363f93f75a7a57af048c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-13T23:55:12Z"
+ content="""
+There is not currently a way to do this, other than of course to use http
+rather than https.
+
+I'm not sure if it's even possible to implement it; the underlying tls
+library would would need a way to configure it to be insecure, and that is
+rather in tension with the actual purpose of a tls library.
+"""]]
diff --git a/doc/forum/Disable_ssl_verification__63__/comment_2_8ff8769a1e62caf4f515b04db38d13f0._comment b/doc/forum/Disable_ssl_verification__63__/comment_2_8ff8769a1e62caf4f515b04db38d13f0._comment
new file mode 100644
index 0000000000..467a3ce945
--- /dev/null
+++ b/doc/forum/Disable_ssl_verification__63__/comment_2_8ff8769a1e62caf4f515b04db38d13f0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jbwexler@f0760d2c023f7660c38fb17889d4cd6930183696"
+ nickname="jbwexler"
+ avatar="http://cdn.libravatar.org/avatar/843be3c6c30b8867c2a0c6ddfb5ad45b"
+ subject="thanks"
+ date="2021-04-14T19:03:09Z"
+ content="""
+Thanks for the quick response. Do you see any other way to solve this error? I'm currently stuck as to how to create this special remote.
+"""]]
diff --git a/doc/forum/Disable_ssl_verification__63__/comment_3_cf39af1d8ff11ab602363a717be074c6._comment b/doc/forum/Disable_ssl_verification__63__/comment_3_cf39af1d8ff11ab602363a717be074c6._comment
new file mode 100644
index 0000000000..a88fef0638
--- /dev/null
+++ b/doc/forum/Disable_ssl_verification__63__/comment_3_cf39af1d8ff11ab602363a717be074c6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2021-04-14T20:06:29Z"
+ content="""
+I guess you could put your self-signed certificate in your ca-store (usually `/etc/ssl/certs`), so the tls library accepts it as a valid certificate. This is much safer than disabling certificate validation altogether.
+"""]]
diff --git a/doc/forum/Disadvantages_of_WORM__58___long_filename__63__.mdwn b/doc/forum/Disadvantages_of_WORM__58___long_filename__63__.mdwn
new file mode 100644
index 0000000000..bff1a3ffe7
--- /dev/null
+++ b/doc/forum/Disadvantages_of_WORM__58___long_filename__63__.mdwn
@@ -0,0 +1,13 @@
+Hello,
+
+first, I felt very comfortable with git-annex, but now I run into problems more often, and I think they are related to the WORM backend. I use this backend for my photos, since they are big (25MB) and never modified (camera raws, I don't touch them). So I edited my `.gitattributes` to use `WORM`.
+
+The problems usually are as follows: I perform an operation, and git (I think it is git which has the problems), and the process exits with exit code 1 and tells me "cannot open binary file: File name too long". The same happens from time to time when I have filenames containing special characters such as ', which can happen when I tag my music collection. I suspect the WORM backend to cause the problems, since the file names in `.git/annex` are indeed very long and ugly beccause of all the escaping done here.
+
+I am sorry that I cannot give a recipe how to reproduce this behaviour, and sometimes it helps to enter a subdirectory and perform the operation from there, for example:
+
+`$ git annex copy --to dest Pictures` fails, but `$ cd Pictures/dir_with_problematic_file; git annex copy --to dest .` works.
+
+Is there some advice or did anyone here observe similar behaviour?
+
+Best regards, Philipp
diff --git a/doc/forum/Disadvantages_of_WORM__58___long_filename__63__/comment_1_cc5502b55fb71c8fdb235ea9d17216ff._comment b/doc/forum/Disadvantages_of_WORM__58___long_filename__63__/comment_1_cc5502b55fb71c8fdb235ea9d17216ff._comment
new file mode 100644
index 0000000000..9cd635eba2
--- /dev/null
+++ b/doc/forum/Disadvantages_of_WORM__58___long_filename__63__/comment_1_cc5502b55fb71c8fdb235ea9d17216ff._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-01-05T16:47:16Z"
+ content="""
+Please show `ls -l` output listing one or more of the files with the
+problem. Also I'd need to know the filesystem your repository is using
+in order to reproduce the problem.
+
+Note that you can use `git annex migrate` to switch away from the WORM
+backend..
+"""]]
diff --git a/doc/forum/Disadvantages_of_WORM__58___long_filename__63__/comment_2_d04b7adcc17a305fb1d7f1c1a3641be1._comment b/doc/forum/Disadvantages_of_WORM__58___long_filename__63__/comment_2_d04b7adcc17a305fb1d7f1c1a3641be1._comment
new file mode 100644
index 0000000000..9cf4f8c202
--- /dev/null
+++ b/doc/forum/Disadvantages_of_WORM__58___long_filename__63__/comment_2_d04b7adcc17a305fb1d7f1c1a3641be1._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-01-05T17:01:12Z"
+ content="""
+I refreshed my memory and did some testing, and the WORM backend
+deals with extremely large filenames by detecting the filename length
+limitations of the filesystem where the repository is located, and if a
+WORM key is longer than the maximum filename length, it will truncate it
+down to fit.
+
+This avoids any problems in my testing, as long as the WORM keys are being
+generated and used all on filesystems with similar filename length limits.
+If you are using a version of git-annex older than 4.20131024, it won't
+do that, and you should upgrade.
+
+If you are using a mixture of filesystems, eg EXT4 and VFAT, this can still
+result in WORM key names generated on EXT4 being too long to fit on the
+VFAT filesystem. In this case, I would recommend not using WORM.
+
+Incidentially, that version also made many problematic characters
+not be included in WORM key names, so they're more portable to eg, FAT
+filesystems.
+"""]]
diff --git a/doc/forum/Disconnected_Archive_and_Backups.mdwn b/doc/forum/Disconnected_Archive_and_Backups.mdwn
new file mode 100644
index 0000000000..8d5a354544
--- /dev/null
+++ b/doc/forum/Disconnected_Archive_and_Backups.mdwn
@@ -0,0 +1,18 @@
+I am using git annex to sync a portion of my home directory. The main use/sync point is on my desktop and laptop. The desktop and laptop are connected to a NAS and usb drives.
+
+So, the repos are connected like so:
+
+```
+       NAS - backup
+          ^          ^
+         /             \
+desktop - client      laptop - client
+         \              /
+          v            v
+          USB drive - archive
+```
+
+The idea is the NAS should get all files, the USB drive acts as an archive to keep the clients a bit lighter weight, even while off site.
+
+Question:
+If the laptop is used offsite with the usb drive archive and the laptop archives a file never yet seen by the NAS, will the NAS ever get this file? Note: the USB drive is never directly connected to the NAS and is not in its list of remotes.
diff --git a/doc/forum/Disconnected_Archive_and_Backups/comment_1_c56f2d3328c0d127efc21067dc52df15._comment b/doc/forum/Disconnected_Archive_and_Backups/comment_1_c56f2d3328c0d127efc21067dc52df15._comment
new file mode 100644
index 0000000000..99aa9729e7
--- /dev/null
+++ b/doc/forum/Disconnected_Archive_and_Backups/comment_1_c56f2d3328c0d127efc21067dc52df15._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="reply: disconnected archive"
+ date="2020-03-16T18:56:13Z"
+ content="""
+> If the laptop is used offsite with the usb drive archive and the
+> laptop archives a file never yet seen by the NAS, will the NAS ever
+> get this file?
+
+It looks like there is a path the content could go in this case:
+
+    laptop -> USB -> desktop -> NAS
+
+You don't mention how you are syncing, but assuming that you're doing
+so in a way that actually transfers the content to each node of that
+path (e.g., `git annex sync --content` with appropriately configured
+preferred content), then I'd say the answer is \"yes\".
+
+"""]]
diff --git a/doc/forum/Disconnected_Archive_and_Backups/comment_2_63b934b773b5f7a3c128dd9685f671ab._comment b/doc/forum/Disconnected_Archive_and_Backups/comment_2_63b934b773b5f7a3c128dd9685f671ab._comment
new file mode 100644
index 0000000000..80c2ab5f5b
--- /dev/null
+++ b/doc/forum/Disconnected_Archive_and_Backups/comment_2_63b934b773b5f7a3c128dd9685f671ab._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="lasitus"
+ avatar="http://cdn.libravatar.org/avatar/dfe778f28027aeb75876172022aa5de3"
+ subject="comment 2"
+ date="2020-03-16T22:29:31Z"
+ content="""
+Not sure why I didn't just try this rather than asking... but now that I've tried it, it doesn't make it to the nas.
+
+```
+whereis archive/testOnLaptop3.img (2 copies)
+        19955c70-90fc-4aa4-9531-ff7fb9fd3a9e -- [usbssd]
+        fe861a5c-818b-4b66-8f2c-0717ba5ed081 -- laptop
+```
+
+I would normally be running git annex assistant, but for this test, I ran
+
+```
+git annex sync --content
+```
+on my laptop and then on my desktop without my laptop connected to the network.
+
+When run on my laptop, I had a thumb drive and the external SSD plugged in. The external SSD is an archive. It archived it off the usb thumb drive, because this is a client and left it on my laptop. I plugged in the external ssd to my desktop and ran sync --content, and it never copied it over, because it is archived (as expected) even though the NAS hadn't backed it up yet. I assume this is because the NAS never is directly connected to the usb ssd nor is the ssd ever connected directly to the nas, so the desktop doesn't shuttle it between the two. I suppose I could fix this particular layout by making the nas the archive, but having the ability to have a large data dump when offsite for a long time and have it automatically archive to an ssd seems nice. Perhaps I can make a rule set myself that does what I want, or change the layout with existing groups.
+"""]]
diff --git a/doc/forum/Disconnected_Archive_and_Backups/comment_3_fae320f7453cf8c7147a109f19be22ba._comment b/doc/forum/Disconnected_Archive_and_Backups/comment_3_fae320f7453cf8c7147a109f19be22ba._comment
new file mode 100644
index 0000000000..93014d013c
--- /dev/null
+++ b/doc/forum/Disconnected_Archive_and_Backups/comment_3_fae320f7453cf8c7147a109f19be22ba._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="lasitus"
+ avatar="http://cdn.libravatar.org/avatar/dfe778f28027aeb75876172022aa5de3"
+ subject="comment 3"
+ date="2020-03-17T02:15:13Z"
+ content="""
+Wow! Such an amazing feature to make your own groups. This is so powerful.
+
+I did this, if anyone else is wanting to do this type setup:
+
+```
+groupwanted mainclient = (include=* and ((exclude=*/archive/* and exclude=archive/*) or (not copies=backup:1) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1
+```
+
+I basically added (not copies=backup:1) to the main client so that it will pull stuff off the archive and deliver it to the NAS before not needing it itself. It did exactly that; in the same sync, it grabbed content from the external ssd, transferred it to the nas, then dropped it.
+"""]]
diff --git a/doc/forum/Disconnected_Archive_and_Backups/comment_4_b3d39d1b85489ce4059a72b9a912624c._comment b/doc/forum/Disconnected_Archive_and_Backups/comment_4_b3d39d1b85489ce4059a72b9a912624c._comment
new file mode 100644
index 0000000000..bec682f621
--- /dev/null
+++ b/doc/forum/Disconnected_Archive_and_Backups/comment_4_b3d39d1b85489ce4059a72b9a912624c._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 4"
+ date="2020-03-17T02:35:49Z"
+ content="""
+Sorry, it should have occurred to me that \"archive\", \"client\", and
+\"backup\" in your initial post were referring to git-annex's standard
+groups.  Indeed then, as you say, the desktop won't get the content
+from the archive because, as a client, it uses this content
+expression:
+
+```
+(include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1
+```
+
+> Perhaps I can make a rule set myself that does what I want
+
+I think that, for the desktop repo, extending the expression above
+with something like
+
+```
+(not (copies=backup:1 or copies=incrementalbackup:1))
+```
+
+would do what you're after.  That should make the desktop grab the
+file from the usb if it hasn't reached the NAS.
+
+Here's the complete configuration that I think should be needed:
+
+```
+git annex wanted . groupwanted
+git annex groupwanted client '(include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)) or (not (copies=backup:1 or copies=incrementalbackup:1)))) or approxlackingcopies=1'
+```
+
+"""]]
diff --git a/doc/forum/Disconnected_Archive_and_Backups/comment_5_93bed4629304725297f88cfa3d494720._comment b/doc/forum/Disconnected_Archive_and_Backups/comment_5_93bed4629304725297f88cfa3d494720._comment
new file mode 100644
index 0000000000..1b039fce39
--- /dev/null
+++ b/doc/forum/Disconnected_Archive_and_Backups/comment_5_93bed4629304725297f88cfa3d494720._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 5"
+ date="2020-03-17T02:38:16Z"
+ content="""
+Oh, I should have refreshed the page.  It seems you came up with
+essentially the same expression :>  Sorry for the noise.
+"""]]
diff --git a/doc/forum/Disk_usage_during___96__import__96__.mdwn b/doc/forum/Disk_usage_during___96__import__96__.mdwn
new file mode 100644
index 0000000000..9ece26e330
--- /dev/null
+++ b/doc/forum/Disk_usage_during___96__import__96__.mdwn
@@ -0,0 +1,5 @@
+Does `git-annex import` move data to the working directory before moving it to `.git/annex/objects`?
+
+The reason I'm asking is that I use the split SSD/HDD setup with some annexes, i.e., everything resides on an SSD except for the git-annex objects directory.
+
+If git-annex wrote imported data to the working directoy (on the SSD) first and moved it to the objects directory (on the HDD) later, it would cause lots of unnecessary writes to the SSD.
diff --git a/doc/forum/Disk_usage_during___96__import__96__/comment_1_3ed4d9a36cacb9be96860cfaae8cee90._comment b/doc/forum/Disk_usage_during___96__import__96__/comment_1_3ed4d9a36cacb9be96860cfaae8cee90._comment
new file mode 100644
index 0000000000..33638e076d
--- /dev/null
+++ b/doc/forum/Disk_usage_during___96__import__96__/comment_1_3ed4d9a36cacb9be96860cfaae8cee90._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-01-05T20:08:52Z"
+ content="""
+Yes, it does; `git annex import` is implemented quite similarly to
+`copy /file .; git annex add $file'
+"""]]
diff --git a/doc/forum/Distributing_data_to_a_set_of_drives.mdwn b/doc/forum/Distributing_data_to_a_set_of_drives.mdwn
new file mode 100644
index 0000000000..406379715d
--- /dev/null
+++ b/doc/forum/Distributing_data_to_a_set_of_drives.mdwn
@@ -0,0 +1 @@
+Here is my situation, Say I have a repo that is 3 TBs (lets call this repo A has full copy of everything.) and I have 3 other drives all 1 TB each lets call them B C D, then I have partial checkouts on my laptops D E. What I would like to do is, have two copies of all files in A and BCD I would like to threat BCD as a group acting like a single repo so A distributes files evenly to drives in group BCD. I also want copies in D and E to not count towards num of files. As for the latter even though I set D and E as untrusted annex still counts copies on those repos If a get a file in D assistant drops a copy from one of the trusted repos A or BCD I have to move it back instead of just dropping it. Also How can I or is it possible to set BCD to act as a group so A distributes files among drives currently I can do this using find/get but it turns it into a math problem every time a add a file to A I have to manually check which disk has most space navigate to it check files with less copies then 2 and get them.
diff --git a/doc/forum/Distributing_data_to_a_set_of_drives/comment_1_f1fa72879f4e1db13bf59dea33c91624._comment b/doc/forum/Distributing_data_to_a_set_of_drives/comment_1_f1fa72879f4e1db13bf59dea33c91624._comment
new file mode 100644
index 0000000000..f0c0a1c2be
--- /dev/null
+++ b/doc/forum/Distributing_data_to_a_set_of_drives/comment_1_f1fa72879f4e1db13bf59dea33c91624._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="comment 1"
+ date="2014-05-08T16:56:34Z"
+ content="""
+I recommend rewriting your comment.  Use paragraphs and be more clear and specific.
+"""]]
diff --git a/doc/forum/Distributing_data_to_a_set_of_drives/comment_2_e13b4e5c1e6f1f503f93d521b504d5c1._comment b/doc/forum/Distributing_data_to_a_set_of_drives/comment_2_e13b4e5c1e6f1f503f93d521b504d5c1._comment
new file mode 100644
index 0000000000..5843ab1779
--- /dev/null
+++ b/doc/forum/Distributing_data_to_a_set_of_drives/comment_2_e13b4e5c1e6f1f503f93d521b504d5c1._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="216.145.95.162"
+ subject="comment 2"
+ date="2014-05-17T17:00:19Z"
+ content="""
+git-annex doesn't allow bonding repositories like that, but it does have repository groups which can accomplish the same thing.
+
+For example, if you put B C and D into the archive group, and set the [[preferred_content]] expression to \"standard\", then each repository will only want files that have not yet reached some other archive repository.
+
+Or, you can make up your own group name, like \"BCD\" and set the preferred content of each repository to something like \"not (copies=BCD:2)\"  -- and now it will try to have 2 copies of each file on one of the drives.
+
+Once it's configured, using either the git-annex assistant, or `git annex sync --content` will copy files around according to the configuration.
+
+This will tend to fill up the first drive, or the first 2 drives, and only use subsequent drives if files don't fit on the first drive. You can use [[cost]] settings to control which drives files are put on.
+"""]]
diff --git a/doc/forum/Do_I_have_naming_ssh_remote_issue__63__.mdwn b/doc/forum/Do_I_have_naming_ssh_remote_issue__63__.mdwn
new file mode 100644
index 0000000000..c6f7fd734d
--- /dev/null
+++ b/doc/forum/Do_I_have_naming_ssh_remote_issue__63__.mdwn
@@ -0,0 +1,45 @@
+I'm running [git-annex](http://ix.io/gJJ) from <https://aur.archlinux.org/packages/git-annex-bin> btw on Archlinux.
+
+I fetched a copy of my [git-annex wedding test repo](https://github.com/kaihendry/krwedding) to a machine on ssh called 'bible'.
+
+Now I'm trying to fetch via ssh from my local machine "X1C3".
+
+I can't work out how to fetch from it from b1b15a9b-1aa1-4f94-8b9a-2186d71c0d1a .... what am I missing?
+
+    X1C3:~/annex/krwedding$ git-annex whereis krfeature.mp4
+     whereis krfeature.mp4 (3 copies)
+        00000000-0000-0000-0000-000000000001 -- web
+        10418340-834d-41c2-b38f-7ee84bf6a23a -- s3
+        b1b15a9b-1aa1-4f94-8b9a-2186d71c0d1a -- Jamie's bible
+      web: http://r2d2.webconverger.org/2013-12-22/krfeature.mp4
+      web: http://static.prazefarm.co.uk/krfeature.mp4
+      web: https://objects.dreamhost.com/wedding-video/krfeature.mp4
+    ok
+    X1C3:~/annex/krwedding$ git-annex get . --from "Jamie's bible"
+    git-annex: there is no available git remote named "Jamie's bible"
+    X1C3:~/annex/krwedding$ git-annex enableremote Jamie's bible
+    > ^C
+    X1C3:~/annex/krwedding$ git-annex enableremote "Jamie's bible"
+    git-annex: Unknown special remote name.
+    Known special remotes: s3
+    X1C3:~/annex/krwedding$ git-annex get . --from b1b15a9b-1aa1-4f94-8b9a-2186d71c0d1a
+    git-annex: there is no available git remote named "b1b15a9b-1aa1-4f94-8b9a-2186d71c0d1a"
+
+Why doesn't the UUID work? :/
+
+I even [tried renaming the remote to the UUID... didn't work](http://ix.io/gJI)
+
+**Solution**: Neither UUID or the description is used by get. I also should not have resorted to [[special_remotes]] setup for setting up a git remote.
+
+# Issue 1
+
+Keep getting `git-annex-shell: user error (git ["config","--null","--list"] exited 126)` even though when I run `git config` my return error is 0: <http://ix.io/gJG>
+
+**Solution**: This was because my ssh git URL was incorrect. A better error message has been implemented: <http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=3439ea4>
+
+
+# Issue 2
+
+I can't work out the [git-annex remote type for ssh, in order to rename the remote](http://ix.io/gJH). I think the issue here is that my ssh remote name "Jamie's bible" doesn't match with the `git remote` name bible.
+
+**Solution**: A _rw_ git URL configured with `git remote` are not [[special_remotes]]. I confused the two. If you need to define public git URL ([[time capsule use case|future_proofing]]), it is possible with an undocumented `git annex initremote foo type=git location=url`. So to summarise, just manually setup the git remote `git remote add ssh://someplace/path/to/repo` (don't worry about the name) and git-annex will find it!
diff --git a/doc/forum/Do_I_have_naming_ssh_remote_issue__63__/comment_1_f3e5ef9d7440cba467ebda1f2e8b12ea._comment b/doc/forum/Do_I_have_naming_ssh_remote_issue__63__/comment_1_f3e5ef9d7440cba467ebda1f2e8b12ea._comment
new file mode 100644
index 0000000000..65d2336e41
--- /dev/null
+++ b/doc/forum/Do_I_have_naming_ssh_remote_issue__63__/comment_1_f3e5ef9d7440cba467ebda1f2e8b12ea._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-06T00:43:32Z"
+ content="""
+You cannot use a UUID like that. How is git-anndx supposed to know where
+that UUID is, or how to access it?
+
+You do not use git-annex initremote with normal git remotes, only special
+remotes.
+
+Set up a git remote, and use `git-annex get --from` with that.
+
+	git remote add ssh://someplace/path/to/repo
+
+git-annex will then figure out that that git remote is the one with that
+UUID, and be able to use it.
+
+Names of git remotes are completely separate from **descriptions** of
+git-annex repositories, which is what git-annex info displays.
+
+AFAIK, all the documentation is clear about the several things that you
+seem to have gotten confused about. Pointers to any places in
+the documentation that are confusing about these matters are appreciated..
+"""]]
diff --git a/doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__.mdwn b/doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__.mdwn
new file mode 100644
index 0000000000..d5a3d3a928
--- /dev/null
+++ b/doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__.mdwn
@@ -0,0 +1 @@
+Do both friends need to be online in order for Jabber syncing to work? Or will the pushed changes be stored on the Jabber server, so that when the remote machine does come online it can pull them even if the original machine is now offline?
diff --git a/doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__/comment_1_f290dd8547176793934f8077374e1c0a._comment b/doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__/comment_1_f290dd8547176793934f8077374e1c0a._comment
new file mode 100644
index 0000000000..8df82612a9
--- /dev/null
+++ b/doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__/comment_1_f290dd8547176793934f8077374e1c0a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-02-27T17:54:47Z"
+ content="""
+Both friends need to be online at the same time to sync with Jabber.
+
+There are some extensions that store and forward jabber messages, but:
+
+* They are probably not widely available.
+* AFAIK they only forward chat messages. But we try not to use visible messages, because that would prevent
+  reusing your jabber account with git-annex.
+* Most importantly, the git protocol lets the sender and receiver communicate with each other to work out what data to transfer. If one if offline, the best that could be done is to upload the whole git repository!
+
+If you want the ability for off-line clients to sync up, you should add a shared bare git repository.
+"""]]
diff --git a/doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__/comment_2_c358eb51047f333e582bd824be5e0e65._comment b/doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__/comment_2_c358eb51047f333e582bd824be5e0e65._comment
new file mode 100644
index 0000000000..b3efced0b8
--- /dev/null
+++ b/doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__/comment_2_c358eb51047f333e582bd824be5e0e65._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="annexuser"
+ ip="24.16.193.140"
+ subject="comment 2"
+ date="2013-03-11T19:40:30Z"
+ content="""
+How would I add a shared bare git repository in the web app?
+"""]]
diff --git a/doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__/comment_3_a2332c0e7b29110b9aed2ab69ce9d8c4._comment b/doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__/comment_3_a2332c0e7b29110b9aed2ab69ce9d8c4._comment
new file mode 100644
index 0000000000..c9a8779808
--- /dev/null
+++ b/doc/forum/Does_Jabber_syncing_work_when_the_buddy_is_offline__63__/comment_3_a2332c0e7b29110b9aed2ab69ce9d8c4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-03-11T19:45:34Z"
+ content="""
+That's done by the \"Remote server\" option on the Repositories page.
+
+You need to have git-annex (any old version will do) installed on the server for this to work.
+
+Of course, a regular git remote will do as well, although the assistant does not set this up. You could even use github for that remote, or a similar service; any remote added with `git remote add` will be used by the assistant.
+"""]]
diff --git a/doc/forum/Does_git-annex_version_big_files__63__.mdwn b/doc/forum/Does_git-annex_version_big_files__63__.mdwn
new file mode 100644
index 0000000000..5cbe7d50ac
--- /dev/null
+++ b/doc/forum/Does_git-annex_version_big_files__63__.mdwn
@@ -0,0 +1,5 @@
+Hi
+
+I am trying to understand how git-annex works. Does it version big files at all? 
+
+thanks
diff --git a/doc/forum/Does_git-annex_version_big_files__63__/comment_1_0b44003c1dc53adb807298ae452f8004._comment b/doc/forum/Does_git-annex_version_big_files__63__/comment_1_0b44003c1dc53adb807298ae452f8004._comment
new file mode 100644
index 0000000000..7f403f0cde
--- /dev/null
+++ b/doc/forum/Does_git-annex_version_big_files__63__/comment_1_0b44003c1dc53adb807298ae452f8004._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 1"
+ date="2012-11-09T18:56:59Z"
+ content="""
+Yes. Have you read [[How_It_Works]]?
+"""]]
diff --git a/doc/forum/Does_git-annex_version_big_files__63__/comment_2_ca40b67abd7bd36155d16d0396d7472c._comment b/doc/forum/Does_git-annex_version_big_files__63__/comment_2_ca40b67abd7bd36155d16d0396d7472c._comment
new file mode 100644
index 0000000000..a753d7e82e
--- /dev/null
+++ b/doc/forum/Does_git-annex_version_big_files__63__/comment_2_ca40b67abd7bd36155d16d0396d7472c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="karhun"
+ ip="99.20.248.32"
+ subject="comment 2"
+ date="2012-11-09T21:37:19Z"
+ content="""
+Hi
+
+Thanks for the pointer.
+
+The reason I asked about is that it says that \"git-annex allows managing files with git, without checking the file contents into git. \". So I was just trying to understand the mechanic behind the description. If it is not check into the git then probably it is not versioning the files. I assumed that it must be  merely a sync tool.
+
+
+"""]]
diff --git a/doc/forum/Does_git-annex_version_big_files__63__/comment_3_32de3501feedce51b43ed9dcc399c7a9._comment b/doc/forum/Does_git-annex_version_big_files__63__/comment_3_32de3501feedce51b43ed9dcc399c7a9._comment
new file mode 100644
index 0000000000..33c4ef7ba8
--- /dev/null
+++ b/doc/forum/Does_git-annex_version_big_files__63__/comment_3_32de3501feedce51b43ed9dcc399c7a9._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="karhun"
+ ip="99.20.248.32"
+ subject="comment 3"
+ date="2012-11-12T05:58:16Z"
+ content="""
+Hi
+
+I have one more follow up question.
+
+So git-annex versions files as I understand. Is it possible to use it without file versioning and just use it as a sync tool. I realize that there are example scenarios to demonstrate it however I would like to disable versioning if possible because I am intending to use it on large folders with big binary type files.
+
+thanks
+
+"""]]
diff --git a/doc/forum/Does_git-annex_version_big_files__63__/comment_4_8c65a7f8bda3c876971c2801fb6a76a1._comment b/doc/forum/Does_git-annex_version_big_files__63__/comment_4_8c65a7f8bda3c876971c2801fb6a76a1._comment
new file mode 100644
index 0000000000..f7f2e85dce
--- /dev/null
+++ b/doc/forum/Does_git-annex_version_big_files__63__/comment_4_8c65a7f8bda3c876971c2801fb6a76a1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 4"
+ date="2012-11-12T15:17:53Z"
+ content="""
+Let's suppose you delete a file from git, and sync the deletion. Later, you can run `git annex unused` and it will find content not needed by any branch of the git repository. And if you choose, you can use `git annex dropunused` to delete that content.
+"""]]
diff --git a/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__.mdwn b/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__.mdwn
new file mode 100644
index 0000000000..7899c62cd7
--- /dev/null
+++ b/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__.mdwn
@@ -0,0 +1,8 @@
+I tried using it once, but I couldn't get it to work for me, so I gave up. I'm hoping that if I describe my desired workflow to people who know more about it I can get a better sense of whether it can help me.
+
+Here's what I have:
+
+* A server, with a directory I have read-only access to; this directory is the one I would like to keep in git-annex. Obviously, I have read-write access to other directories.
+* A laptop, which is sometimes on the same LAN as the server and sometimes not; on this laptop, I would like to be able to easily maintain synced copies of certain subdirectories of the main directory (which is on the server). These copies should (ideally) not need to be in the same directory tree on the laptop.
+
+I don't know if this description is clear enough (I'm doubtful), but I can answer questions.
diff --git a/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_1_25572571debe2c91447b0ed952f45cb2._comment b/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_1_25572571debe2c91447b0ed952f45cb2._comment
new file mode 100644
index 0000000000..eb568646ef
--- /dev/null
+++ b/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_1_25572571debe2c91447b0ed952f45cb2._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-12-02T18:14:50Z"
+ content="""
+The two problems are: Read-only directory, and wanting a clone that doesn't
+have the same directory structure.
+
+For the read-only directory, you may be able to use a direct mode
+repository. You might need to set `GIT_DIR` in the environment to make
+the .git directory be placed somewhere outside the read-only directory.
+
+As to wanting different directory structure in your clone, it's an added
+complication I'd recommend avoiding. Not that it's impossible, you can move
+files around in the git repository and that could be automated via
+git-filter-branch or the like. But git-annex offers a simpler solution,
+which is to use the same directory structure and only get the contents of
+files in the subdirectories you want.
+"""]]
diff --git a/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_2_46c27b242c6df76f9df198bbd6f14030._comment b/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_2_46c27b242c6df76f9df198bbd6f14030._comment
new file mode 100644
index 0000000000..9f7dfb6a29
--- /dev/null
+++ b/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_2_46c27b242c6df76f9df198bbd6f14030._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="rpglover64@acd6753c831cc132736943bec350391fcb2ff77d"
+ nickname="rpglover64"
+ subject="Thanks!"
+ date="2015-12-02T20:15:57Z"
+ content="""
+Last time I tried, I managed to get somewhere with the readonly directory, I think using the same idea you suggested. As for the different directory structure, you make a very good point. Thanks for taking the time to respond. I'll take another shot at using git-annex when I have some time.
+"""]]
diff --git a/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_3_2d9baeb81857b354931251a8b8a756e5._comment b/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_3_2d9baeb81857b354931251a8b8a756e5._comment
new file mode 100644
index 0000000000..8687f9eae9
--- /dev/null
+++ b/doc/forum/Does_git_annex_support_my_weird_workflow__63_____40__A_single__44___effectively___95__read_only__95___source__41__/comment_3_2d9baeb81857b354931251a8b8a756e5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="rpglover64@acd6753c831cc132736943bec350391fcb2ff77d"
+ nickname="rpglover64"
+ subject="Third time's the charm?"
+ date="2016-02-08T20:44:11Z"
+ content="""
+So I tried again (I got read-write access to the top level of the directory I want to share, so creating a .git was straightforward), and I had two things get in my way. I have a lot of relatively large files (~10,000), so I decided to use the WORM backend rather than waiting for the SHA to complete. Even so, adding everything was slow-going.
+
+Since the most interesting feature of git-annex is queueing up downloads to sync on LAN, is there a way to add the files especially quickly by sacrificing some more safety? Essentially, I want to use git-annex as a glorified file server, letting my laptop do all the interesting work.
+
+Second, when I Ctrl-C during `git annex add`, progress is not preserved in a direct-mode repository, so the add needs to start all over again.
+"""]]
diff --git a/doc/forum/Does_migrate_ensure_data_integrity__63__.mdwn b/doc/forum/Does_migrate_ensure_data_integrity__63__.mdwn
new file mode 100644
index 0000000000..872e7d53da
--- /dev/null
+++ b/doc/forum/Does_migrate_ensure_data_integrity__63__.mdwn
@@ -0,0 +1,7 @@
+Out of simple curiosity, how does 'git annex migrate' work?  I'm mostly wondering how file integrity is ensured.
+
+Let's say you want to migrate foo.txt from (say) md5 to sha256.  Does git annex simply sha256sum foo.txt and rename it in the .git/objects folder to the new sum?  Or does it md5sum foo.txt, verify that it's the not corrupt, then sha256sum it and rename to the new sum?
+
+You could run into problems if you migrate without first verifying; if the file is corrupt and you simply sha256sum and rename it, then the file wouldn't seem corrupt at your next fsck.
+
+I'm sure you've considered this during the basic design phase of git-annex, but I'd just like to be sure.  I'm kind of paranoid when it comes to data integrity. =P
diff --git a/doc/forum/Does_migrate_ensure_data_integrity__63__/comment_1_cef50b32c46f4406c6f918c5866ddc15._comment b/doc/forum/Does_migrate_ensure_data_integrity__63__/comment_1_cef50b32c46f4406c6f918c5866ddc15._comment
new file mode 100644
index 0000000000..7c819a8ca9
--- /dev/null
+++ b/doc/forum/Does_migrate_ensure_data_integrity__63__/comment_1_cef50b32c46f4406c6f918c5866ddc15._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-13T18:28:01Z"
+ content="""
+I actually didn't originally consider this, but it turns out I have wonderful users, and you're at least the second to consider this case.
+
+So the released git-annex version does already verify the checksum when doing a migration. However, as I was checking this, I noticed 
+I had left a window between the verification and the generation of the new key for the migration. It's pretty unlikely a file would get corrupted just as it was being migrated, but that's no excuse. I've committed a change that reverses the order; so it generates a new key and then verifies the old one.
+"""]]
diff --git a/doc/forum/Does_migrate_ensure_data_integrity__63__/comment_2_f389b924c8531b35fdf5dedd10fc8000._comment b/doc/forum/Does_migrate_ensure_data_integrity__63__/comment_2_f389b924c8531b35fdf5dedd10fc8000._comment
new file mode 100644
index 0000000000..c377d814c5
--- /dev/null
+++ b/doc/forum/Does_migrate_ensure_data_integrity__63__/comment_2_f389b924c8531b35fdf5dedd10fc8000._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="GLITTAH"
+ ip="154.51.136.37"
+ subject="comment 2"
+ date="2013-05-14T15:54:08Z"
+ content="""
+An even better solution.  Thanks for your time and effort joey!
+"""]]
diff --git a/doc/forum/Does_the_windows_version_install_iStartSurf_malware__63__.mdwn b/doc/forum/Does_the_windows_version_install_iStartSurf_malware__63__.mdwn
new file mode 100644
index 0000000000..21c03e758d
--- /dev/null
+++ b/doc/forum/Does_the_windows_version_install_iStartSurf_malware__63__.mdwn
@@ -0,0 +1,3 @@
+Hi, since I installed git-annex-windows through the link from the homepage I got iStartSurf, a really anoying malware. Could somebody ack the existence of iStartSurf in windows version? I use my windows seldom, usualy start only to receive updates. (and of coures to try out git-annex)
+
+Zsolt
diff --git a/doc/forum/Does_the_windows_version_install_iStartSurf_malware__63__/comment_1_0536085a1f969802a7e8607093eee97d._comment b/doc/forum/Does_the_windows_version_install_iStartSurf_malware__63__/comment_1_0536085a1f969802a7e8607093eee97d._comment
new file mode 100644
index 0000000000..9d2e4d29a5
--- /dev/null
+++ b/doc/forum/Does_the_windows_version_install_iStartSurf_malware__63__/comment_1_0536085a1f969802a7e8607093eee97d._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Correlation does not imply causation"""
+ date="2015-06-15T17:27:40Z"
+ content="""
+<pre>
+joey@kite:~/lib/downloads/git-annex/windows/current> clamscan git-annex-installer.exe
+git-annex-installer.exe: OK
+
+----------- SCAN SUMMARY -----------
+Known viruses: 3841819
+Engine version: 0.98.7
+Scanned directories: 0
+Scanned files: 1
+Infected files: 0
+Data scanned: 36.55 MB
+Data read: 23.07 MB (ratio 1.58:1)
+Time: 10.835 sec (0 m 10 s)
+</pre>
+
+FWIW, the git-annex Windows build happens on the same build cluster that is used
+for msysgit. If it were infected by a virus, that would be bad news,
+so if you have some actual evidence of a virus, please share it.
+"""]]
diff --git a/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote.mdwn b/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote.mdwn
new file mode 100644
index 0000000000..532dab61f4
--- /dev/null
+++ b/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote.mdwn
@@ -0,0 +1,5 @@
+I import my phone apps' backups to a subdirectory via an ADB special remote and `importtree=yes` but every time I run a sync, it tries to copy files to it that are below numcopies; even those outside the relevant sub-directory.
+
+How can I make it so that it never tries to copy any files to it? `exporttree=no`, it will provably never work.
+
+Note that you can't make it want `nothing` because that also prevents import from working.
diff --git a/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_1_9f8e1ac58e319540b3d9a5b9962e1f8f._comment b/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_1_9f8e1ac58e319540b3d9a5b9962e1f8f._comment
new file mode 100644
index 0000000000..9f6356a5f7
--- /dev/null
+++ b/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_1_9f8e1ac58e319540b3d9a5b9962e1f8f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="numcopies is no the target"
+ date="2023-12-17T19:04:41Z"
+ content="""
+Syncing doesn't work towards satisfying `numcopies`, just preferred content. So if you find files to be copied to the phone, then its preferred content matches those files. Maybe try `git annex wanted PHONE 'present or approxlackingcopies=1'` or just `git annex wanted PHONE present`. `nothing` is indeed not a good idea as that will have git-annex wanting to yank everything off the phone.
+"""]]
diff --git a/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_2_f398f38ff29d2e681548b1640080dff3._comment b/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_2_f398f38ff29d2e681548b1640080dff3._comment
new file mode 100644
index 0000000000..b171e57ba9
--- /dev/null
+++ b/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_2_f398f38ff29d2e681548b1640080dff3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/86b8c2d893dfdf2146e1bbb8ac4165fb"
+ subject="comment 2"
+ date="2023-12-18T12:08:08Z"
+ content="""
+`present` isn't allowed for special remotes with `importtree=yes`.
+"""]]
diff --git a/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_3_53759e189b2f13b8ea1f48f3b6fb7fca._comment b/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_3_53759e189b2f13b8ea1f48f3b6fb7fca._comment
new file mode 100644
index 0000000000..ebeea821de
--- /dev/null
+++ b/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_3_53759e189b2f13b8ea1f48f3b6fb7fca._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-12-18T17:41:39Z"
+ content="""
+You have probably set remote.phoneremote.annex-tracking-branch to "master".
+That tells `git-annex sync` to try to export the whole branch to that
+remote.
+
+If you are confining the phone to a subdirectory, you should set that
+to eg "master:phonedir", then it will only consider files in that
+directory.
+
+> `exporttree=no`, it will provably never work
+
+What do you mean by this? If git-annex sync 
+ignored exporttree=no, that would be a bug. I just verified it honors that
+setting.
+"""]]
diff --git a/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_4_c3d9048668596f6be3975026ec1debc1._comment b/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_4_c3d9048668596f6be3975026ec1debc1._comment
new file mode 100644
index 0000000000..4b35016d42
--- /dev/null
+++ b/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_4_c3d9048668596f6be3975026ec1debc1._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/86b8c2d893dfdf2146e1bbb8ac4165fb"
+ subject="comment 4"
+ date="2023-12-25T12:21:58Z"
+ content="""
+The remote's `annex-tracking-branch` includes the sub-directory in my setup.
+
+I did not mean that it ignores exporttree and actually exports files, it ignores it insofar that it attempts to copy to the remote but then fails because `exporttree=no`. Tonnes of:
+
+```
+copy Filename (to paperless...) 
+  remote is configured with importtree=yes and without exporttree=yes; cannot modify content stored on it
+failed
+```
+
+It shouldn't even attempt to do that, it will never work.
+
+Some new info: After updating my NAS to NixOS 23.11, it is now also affected while it wasn't before on 23.05.
+
+Good: 10.20230407  
+Bad: 10.20230926
+"""]]
diff --git a/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_5_e9ea995c99785dd6dffba91ef0fceb02._comment b/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_5_e9ea995c99785dd6dffba91ef0fceb02._comment
new file mode 100644
index 0000000000..dfbd56835a
--- /dev/null
+++ b/doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_5_e9ea995c99785dd6dffba91ef0fceb02._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-12-26T19:44:23Z"
+ content="""
+I reproduced it with the current version and a remote set up with:
+
+	git-annex initremote test type=directory directory=../d encryption=none exporttree=no importtree=yes
+	git config remote.directory.annex-tracking-branch master
+
+Fixed for tomorrow's release.
+"""]]
diff --git a/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files.mdwn b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files.mdwn
new file mode 100644
index 0000000000..aae2bf2764
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files.mdwn
@@ -0,0 +1,25 @@
+My Use Case:
+
+I try basicly to use annex as a raid-like tool (at least thats the first step)
+
+so I added some big files to it, and then I synced it to a usb-remote. So far all did go well...
+
+No I startet annex watch daemon... because I thought it would then watch the files and checkin and out at least for the "origin" copy of the files.
+
+Then I thought lets delete some files I dont need anymore... so... rm.... ^^
+
+Maybe I just wanted to see what happens or if that would magicly do what I wanted him to do... ok I knew that it would not delete the file on the usb-drive (backup...) ok... but maybe at least localy...
+
+
+Now what did happen instead of that... the links are gone yes... the files it self are in the .git objects tree, so they did not get deleted, so ok not the way I wanted... have to unlock it first, would make maybe sense...
+
+So I tried first to get the links back... tried fix, tried unused, tried get... but the links doesnt show up again...
+
+is there a way to first bring back the links?
+is it save or the right way to just git rebase HEAD~3 to bring the links back?
+
+and then when I want to delete files from all places whats the way to do that... annex unlock -> then delete? or git drop filex --copies=0 or something?
+
+like I said I try to use is like a more flexible raid thing, this files are to big to really back em up with history... I watch them... and then soon I will often delete them (from everywhere). but other parts stay... I dont delete them then... ^^
+
+So maybe I missuse annex for that usecase... try to find that out ;)
diff --git a/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_1_b307bfb0b70d649897f411eb753bd50a._comment b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_1_b307bfb0b70d649897f411eb753bd50a._comment
new file mode 100644
index 0000000000..739319b71e
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_1_b307bfb0b70d649897f411eb753bd50a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.60"
+ subject="comment 1"
+ date="2012-09-16T00:14:49Z"
+ content="""
+You can use any git command you like like `git rebase` or `git revert` to operate on the links.
+
+git-annex, like git, keeps data for files that have been deleted.
+
+The `git annex unused` command will find that data and let you remove it. See [[walkthrough/unused_data]].
+
+
+"""]]
diff --git a/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_2_58a6a1476274b8c4feb3d43ecd998759._comment b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_2_58a6a1476274b8c4feb3d43ecd998759._comment
new file mode 100644
index 0000000000..01ad2901d2
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_2_58a6a1476274b8c4feb3d43ecd998759._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn4bbuawnh-nSo9pAh8irYAcV4MQCcfdHo"
+ nickname="Stefan"
+ subject="thanx for fast help ;)"
+ date="2012-09-16T16:09:29Z"
+ content="""
+git-annex version: 3.20120629
+
+git annex unused did not show me anything... dont know why... I did only \"rm Directory\" not git rm... but \"git annex watch\" did check it in... I sadly have reverted and droped the file now... but if you want I can try to delete other files the same way to see if annex unused shows them... then I post the hole commands... k I try it now:
+
+oh I see the directory I wanted to drop did not get dropped because I set numcopies to 2 ;) so I try it again with that file:
+
+1. rm -r directory
+2. ls it is gone (should be ;) )
+
+user@host:~/annex/SOFTWARE$ git annex unused
+unused . (checking for unused data...) (checking master...) (checking synced/master...) (checking usbdrive/master...) ok
+user@host:~/annex/SOFTWARE$ 
+
+Is that like it should be? If so, should unused only show stuff that I delete with git rm?
+
+
+-----------------------------------
+
+Ok I did read the unused doku you pointed me. So I thought I got it, but I did not:
+
+If I
+
+1. rm File
+2. in the usb-repos, git pull
+both repositories dont have a link to the file.
+3. git unused shows nothing
+4. it seemed that the link AND the File it links to got deleted:
+
+-../.git/annex/objects/pM/vq/SHA256-s1066518528--00c5e1b1610c0c2dfab05c7a55aaad
+
+but the file size is 1gb, both directories dont get smaller... also if I use git gc after that it does not get smaller too.
+
+Is there a way to really delete files from both repositories.
+
+"""]]
diff --git a/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_3_4b857f481db7b2437ac9f8137a8510e2._comment b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_3_4b857f481db7b2437ac9f8137a8510e2._comment
new file mode 100644
index 0000000000..a1e003ee77
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_3_4b857f481db7b2437ac9f8137a8510e2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.60"
+ subject="comment 3"
+ date="2012-09-16T17:08:49Z"
+ content="""
+> unused . (checking for unused data...) (checking master...) (checking synced
+/master...) (checking usbdrive/master...) ok
+
+It still considers a file's content used while some branch contains the file. So one of the branches it's checking there still has your file in it. Once you get all the branches synced up, the file will become unused.
+"""]]
diff --git a/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_4_828db3bf2863d98c0b0fb4074aa7f066._comment b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_4_828db3bf2863d98c0b0fb4074aa7f066._comment
new file mode 100644
index 0000000000..20e1801075
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_4_828db3bf2863d98c0b0fb4074aa7f066._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn4bbuawnh-nSo9pAh8irYAcV4MQCcfdHo"
+ nickname="Stefan"
+ subject="comment 4"
+ date="2012-09-16T22:51:00Z"
+ content="""
+hmm Ok I tried now something that seems to did it...  after I did checkin and pull the deletion of the soft-link of the file... I addionaly used git annex sync, and then again pushed it from the usb drive... now the unused command finds stuff...
+
+So am I right now to make that happen:
+
+1. delete the file in the \"main\" repos
+2. git pull from the other repository(s)
+3. git annex sync
+
+4. git annex unused (now it founds something to delete)
+
+5. git annex dropunused 1-1000 (or some other range) do that in both repositories to delete in on both... and do that maybe as cronjob (from point 2 to 5) or do the last last step only if a drive is nearly full (automaticly or manually...)
+
+ok so maybe I could use that.
+
+the advantages over something like rsync are...
+
+1. I have a history and can reverse some operations (till I do step 5 ^^)
+2. I am more flexible in repo/remote types
+3. checksums get saved
+4. I can have repo with all links but 0 data on a 3rd pc and can \"get\" stuff dynamicly (what is the cheapest transfeir) ot them... aka partial checkouts
+
+ok I think the 4. advantage buys me ;)
+
+hope I got it now right with the 5 step instruction.
+
+keep up your great work, would have tried kickstarter here maybe too for other stuff... but I am no american ;) and eu-guys are not allowed, and I also have no relative in usa ;) but that only as a site note ;)
+"""]]
diff --git a/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_5_cb2063d6a4e08a5c12bf3723d0fa74e0._comment b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_5_cb2063d6a4e08a5c12bf3723d0fa74e0._comment
new file mode 100644
index 0000000000..14e5b3da39
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_5_cb2063d6a4e08a5c12bf3723d0fa74e0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 5"
+ date="2012-09-17T14:12:13Z"
+ content="""
+That looks right except you shouldn't have to `git pull from the other repository(s)`.  The first thing `git annex sync` does is a `git pull`.
+"""]]
diff --git a/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_6_1759bcd5708f591f91b9c410f6dc5c54._comment b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_6_1759bcd5708f591f91b9c410f6dc5c54._comment
new file mode 100644
index 0000000000..379d728ee4
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_6_1759bcd5708f591f91b9c410f6dc5c54._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn4bbuawnh-nSo9pAh8irYAcV4MQCcfdHo"
+ nickname="Stefan"
+ subject="comment 6"
+ date="2012-09-17T23:00:09Z"
+ content="""
+ok I now at least got it that it is nice to run watch on both repositories... 
+
+but what I dont get is, is the git annex watch commando not a automatic way so that this deamon makes sync command whenever needed? so I have to use git annex sync first on the repos where I delete the file and then again on the repos I want to receive that change... that seemed to work, but why did watch not do that for me???
+
+
+
+
+"""]]
diff --git a/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_7_2a389f01eb5131042ea1e71a73c9787a._comment b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_7_2a389f01eb5131042ea1e71a73c9787a._comment
new file mode 100644
index 0000000000..ecc159641e
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_how_to_delete__47__recover_files/comment_7_2a389f01eb5131042ea1e71a73c9787a._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn4bbuawnh-nSo9pAh8irYAcV4MQCcfdHo"
+ nickname="Stefan"
+ subject="comment 7"
+ date="2012-09-18T00:11:50Z"
+ content="""
+cd /mnt/data/annex/ &&
+/usr/bin/git annex sync &&
+/usr/bin/git annex copy --auto --to usbdrive &&
+cd /mnt/usb1/annex/ &&
+/usr/bin/git annex sync &&
+echo \"synced\" ||
+echo \"backup of annex failed\" | sendxmpp -t name@server.country
+
+
+ok suprisingly that did not only sync the files but also did remove the file, so you dont need a pull... dont know what I did wrong the other times I tried, does maybe the  copy command also \"copies\" the delete commit?
+
+but annyway that works for me... (for now I do the dropunused command manuelly...)
+
+that should work as cronjob...
+"""]]
diff --git a/doc/forum/Don__39__t_understand_local_vs._known_keys.mdwn b/doc/forum/Don__39__t_understand_local_vs._known_keys.mdwn
new file mode 100644
index 0000000000..39f8c1041e
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_local_vs._known_keys.mdwn
@@ -0,0 +1,19 @@
+I just created a new Annex by doing the following:
+
+ 1. git init
+ 2. git annex init
+ 3. git annex add .
+ 4. git commit -m "Added files"
+ 5. git annex status
+
+I see the following:
+
+    local annex keys: 224
+    local annex size: 41 gigabytes
+    known annex keys: 235
+    known annex size: 49 gigabytes
+    bloom filter size: 16 mebibytes (0% full)
+    backend usage: 
+            SHA256: 459
+
+Why is there an 8 gigabyte difference here?  What/where are those files?  What is a bloom filter?
diff --git a/doc/forum/Don__39__t_understand_local_vs._known_keys/comment_1_10749c0d76e824217dd1ff8c8a6e42a5._comment b/doc/forum/Don__39__t_understand_local_vs._known_keys/comment_1_10749c0d76e824217dd1ff8c8a6e42a5._comment
new file mode 100644
index 0000000000..5ab1d55cc2
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_local_vs._known_keys/comment_1_10749c0d76e824217dd1ff8c8a6e42a5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2012-10-17T12:54:42Z"
+ content="""
+Those are duplicate files.
+
+see http://git-annex.branchable.com/tips/finding_duplicate_files/ for how to easily display them.
+"""]]
diff --git a/doc/forum/Don__39__t_understand_local_vs._known_keys/comment_2_db9f1b6d9638c2b0a7e241c2727e8cfb._comment b/doc/forum/Don__39__t_understand_local_vs._known_keys/comment_2_db9f1b6d9638c2b0a7e241c2727e8cfb._comment
new file mode 100644
index 0000000000..c1ca018f5c
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_local_vs._known_keys/comment_2_db9f1b6d9638c2b0a7e241c2727e8cfb._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 2"
+ date="2012-10-17T17:32:52Z"
+ content="""
+The local keys are files whose content is locally present.  
+The known keys are annexed files in the current branch, whose content may or may not be present. 
+
+Justin is correct -- if you have the same file in the tree twice, it will be counted twice as known keys. Since git-annex deuplicates, only one local key is needed to store it.
+
+The bloom filter is a technical implementation detail that allows the potentially expensive status scan to run in constant space. You can read about it on Wikipedia if interested. :)
+"""]]
diff --git a/doc/forum/Don__39__t_understand_sync_with_ssh_remote.mdwn b/doc/forum/Don__39__t_understand_sync_with_ssh_remote.mdwn
new file mode 100644
index 0000000000..45f77d1651
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_sync_with_ssh_remote.mdwn
@@ -0,0 +1,54 @@
+Hi,
+
+I don't understand how to sync an empty local repository on my local pc with ssh server.
+
+On webfaction distant ssh host, i create a repository in v6  which contain all my file (commited with git commit).
+
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        151c9c3c-7bf2-4a06-ab47-38dfd65b0d12 -- reyman64@web504.webfaction.com:~/webdav/bib/seb/pdf-repository [here]
+
+On local pc, i create an empty repository, also in v6, and i configure ssh remote, nammed "pdfwebfaction", so git annex info return this
+
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        151c9c3c-7bf2-4a06-ab47-38dfd65b0d12 -- reyman64@web504.webfaction.com:~/webdav/bib/seb/pdf-repository
+        9d08d7c0-55da-451e-8ca3-aaa612eefb46 -- reyman@Dunwich:~/Sync/PDF_Webfaction [here]
+
+
+I want to sync local with this remote branch, and sync content, so i try :
+ 
+    git annex sync pdfwebfaction
+
+Which return :
+
+    commit  git-annex: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit","-a","-m","git-annex in reyman@Dunwich:~/Sync/PDF_Webfaction"] exited 1
+
+And i also try without success : 
+
+    git-annex get --from pdfwebfaction
+
+which return an error about uuid, don't understand why because uuid exist for ssh repo :
+
+    git-annex: cannot determine uuid for pdfwebfaction (perhaps you need to run "git annex sync"?) (remote.pdfwebfaction.annex-ignore is set)
+
+My git config is : 
+
+    [core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = false
+        logallrefupdates = true
+    [annex]
+        uuid = 9d08d7c0-55da-451e-8ca3-aaa612eefb46
+        version = 6
+    [filter "annex"]
+        smudge = git-annex smudge %f
+        clean = git-annex smudge --clean %f
+    [remote "pdfwebfaction"]
+        url = ssh://reyman64@reyman64.webfactional.com:/home/reyman64/webdav/bib/seb/pdf-repository
+        fetch = +refs/heads/*:refs/remotes/pdfwebfaction/*
+
+There is something i don't understand, and the documentation talk only about ssh associated with a git clone command.
+
+PS : the ssh connection is correct, i test it.
diff --git a/doc/forum/Don__39__t_understand_sync_with_ssh_remote/comment_1_be10d6b564e130f4a516d438831681d1._comment b/doc/forum/Don__39__t_understand_sync_with_ssh_remote/comment_1_be10d6b564e130f4a516d438831681d1._comment
new file mode 100644
index 0000000000..3a96e88472
--- /dev/null
+++ b/doc/forum/Don__39__t_understand_sync_with_ssh_remote/comment_1_be10d6b564e130f4a516d438831681d1._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="reyman64@740e43250854ada1b8484b3bc44b53be03367d70"
+ nickname="reyman64"
+ subject="comment 1"
+ date="2016-01-26T19:14:51Z"
+ content="""
+Ok i finally understand.
+
+I remove the ssh with `git add remove pdfwebfaction` and recreate with
+
+`git remote add pdfwebfaction ssh://reyman@webxxx.webfaction.com:/home/reyman/webdav/pdf`
+
+At this step, `git annex get --from pdfwebfaction` doesn't work, i need to create and add a file like `touch test` to my local empty git repository.
+
+After that, the previous command work.
+
+
+"""]]
diff --git a/doc/forum/Drop__47__move_unused_files_older_than_x.mdwn b/doc/forum/Drop__47__move_unused_files_older_than_x.mdwn
new file mode 100644
index 0000000000..b936217a9c
--- /dev/null
+++ b/doc/forum/Drop__47__move_unused_files_older_than_x.mdwn
@@ -0,0 +1 @@
+I like to keep unused files around in case I need them but I probably won't need files from more than a month ago. Is there a way to drop or move just unused files that were last referenced >x days ago and keep the rest?
diff --git a/doc/forum/Drop__47__move_unused_files_older_than_x/comment_1_626facc640a9018a04f203d10aff7676._comment b/doc/forum/Drop__47__move_unused_files_older_than_x/comment_1_626facc640a9018a04f203d10aff7676._comment
new file mode 100644
index 0000000000..684300e0f1
--- /dev/null
+++ b/doc/forum/Drop__47__move_unused_files_older_than_x/comment_1_626facc640a9018a04f203d10aff7676._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-07-19T15:43:46Z"
+ content="""
+There's a new command, added just last week, that gets close to this. 
+`git annex whereused --unused --historical` will display each unused
+key, along with a git rev where that key was found to be used.
+
+The git rev looks like eg "master~4:filename" or "HEAD@{40}:filename".
+It will usually be the most recent use, although it prefers older uses
+that made it into a branch over any revs from the reflog.
+
+Seems like perhaps `git rev-list --no-walk --before=` could be used in a shell
+pipeline with whereused. I suppose it would be a kind of ugly pipeline,
+since it would have to extract the rev, strip the filename from it, pass
+it through git rev-list, and then output the key when rev-list output a
+rev.
+
+Or, the same method that whereused uses to find where keys were used
+could be applied in something like `git annex unused --older-than=1day`.
+"""]]
diff --git a/doc/forum/Drop_some_unused_objects_keeping___35__n_more_recent.mdwn b/doc/forum/Drop_some_unused_objects_keeping___35__n_more_recent.mdwn
new file mode 100644
index 0000000000..2edba50fef
--- /dev/null
+++ b/doc/forum/Drop_some_unused_objects_keeping___35__n_more_recent.mdwn
@@ -0,0 +1,18 @@
+Hello, thanks for all the work in Git-annex! We've been using since 2018 for Integrated Circuits (ASICs) design with a lot of success.
+
+One feature that would help us would be to be able to Drop Unused, but not all Unused.
+In our design flow, every 2 or 3 weeks, we update a collection of Objects, replacing, "overwriting" the objects with newer version.
+So the older becomes Unused.
+
+But we want to keep a certain history depth of Unused. And this cannot be based on dates.
+Because when we stop working on a certain block/module, the Unused Objects can become quite old (like 6 months), but we still want to keep like for example 3x Unused Objects.
+
+Example: we have overwritten 12x times the same Object "module_a.jpg". So we have 11x Unused versions of "module_a.jpg".
+We want to keep the latest and +3x latest Unused. So on total only 8x Unused copies would get Dropped.
+
+Is there a way to do that with Git-annex?
+Or we would need to create a custom script to parse the git-repository, list all the 12x keys of "module_a.jpg", and pick the 8x for Dropping?
+
+Thank you.
+Best regards.
+Davi Castro.
diff --git a/doc/forum/Drop_some_unused_objects_keeping___35__n_more_recent/comment_1_2e16a4c08568ea37c16f4ea74203ae12._comment b/doc/forum/Drop_some_unused_objects_keeping___35__n_more_recent/comment_1_2e16a4c08568ea37c16f4ea74203ae12._comment
new file mode 100644
index 0000000000..ecb6b82caf
--- /dev/null
+++ b/doc/forum/Drop_some_unused_objects_keeping___35__n_more_recent/comment_1_2e16a4c08568ea37c16f4ea74203ae12._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-09-21T15:35:23Z"
+ content="""
+Interesting, I had not known that ASIC design would involve
+the kind of large files git-annex would be useful for.
+
+I think you may want to use `git annex unused --used-refspec='+refs/heads/*:+HEAD:reflog'  
+That adds all versions that are in the reflog. Then you can
+can configure git to control how much reflog to keep around.
+(See `git-gc` man page`)
+
+The other possibility is a new git-annex feature, `git-annex whereused --unused --historical`  
+After you run `git annex unused`, you can run that to display
+each unused key, along with the git rev where that key was found to be
+used.
+
+The git rev looks like eg "master~4:filename" or "HEAD@{4}:filename".
+It will usually be the most recent use, although it prefers older uses
+that made it into a branch over any revs from the reflog. So you can
+filter for keys with numbers `> 8` or whatever, and get only the older
+versions of files. Then pipe the keys into `git-annex dropkey --batch`.
+
+Improving `git annex unused` to be able to do this kind of filtering itself
+is also a possibility. (See also
+[[forum/Drop__47__move_unused_files_older_than_x]] which was asking
+for a similar kind of thing with a similar response).
+"""]]
diff --git a/doc/forum/Drop_with_assistant.mdwn b/doc/forum/Drop_with_assistant.mdwn
new file mode 100644
index 0000000000..f8847ab188
--- /dev/null
+++ b/doc/forum/Drop_with_assistant.mdwn
@@ -0,0 +1,5 @@
+Hi,
+
+how can I handle *drop* with the assistant? There are some files in my annex that I don't need on my laptop. so i just *drop* them on the command line bevcause I have copies on my server and an external usb drive. But after a while the assistant pulls all the files back in. Can I avoid this and make the *drop* somehow "sticky" until i *get* them over cli?
+
+Best, Michael
diff --git a/doc/forum/Drop_with_assistant/comment_1_048f5a31c549afb19b76a65bddd0cd24._comment b/doc/forum/Drop_with_assistant/comment_1_048f5a31c549afb19b76a65bddd0cd24._comment
new file mode 100644
index 0000000000..e59c285c2f
--- /dev/null
+++ b/doc/forum/Drop_with_assistant/comment_1_048f5a31c549afb19b76a65bddd0cd24._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 1"
+ date="2013-04-11T07:32:50Z"
+ content="""
+Hi,
+
+you can set your repository type to 'manual'.
+
+Best
+Karsten
+"""]]
diff --git a/doc/forum/Drop_with_assistant/comment_2_527d7b6a8efa85b904111f179912d926._comment b/doc/forum/Drop_with_assistant/comment_2_527d7b6a8efa85b904111f179912d926._comment
new file mode 100644
index 0000000000..d3ffed3f71
--- /dev/null
+++ b/doc/forum/Drop_with_assistant/comment_2_527d7b6a8efa85b904111f179912d926._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmU_2tE75oyG0h2ZPN4lcroIKEMC8G-otE"
+ nickname="Michael"
+ subject="comment 2"
+ date="2013-04-11T08:26:01Z"
+ content="""
+@Karsten But then I would loose all replication features? Or can I mark subfolders as manual? Or would I mix different annexes?
+"""]]
diff --git a/doc/forum/Drop_with_assistant/comment_3_c50857506869bb1cd306b66acf37fba8._comment b/doc/forum/Drop_with_assistant/comment_3_c50857506869bb1cd306b66acf37fba8._comment
new file mode 100644
index 0000000000..cd45baeaf1
--- /dev/null
+++ b/doc/forum/Drop_with_assistant/comment_3_c50857506869bb1cd306b66acf37fba8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 3"
+ date="2013-04-11T13:18:04Z"
+ content="""
+The trivial way to do this is to set your repository to \"client\" and then when you want to drop a file, create a folder called \"archive\" and drag the file into that folder.  The assistant will drop it (if numcopies is satisfied that there are enough copies elsewhere).  If you want it back, drag it out of the archive and the assistant will re-fetch it.
+
+This is how I use git-annex: I have an ssh remote and a usb drive which are both \"backup\" and my laptop is \"client\", and my numcopies is sent to 2.
+
+Files are always copied to the ssh remote and the usb drive because they're \"backup.\"  That fulfills my numcopies=2.  At that point, anything in an \"archive\" folder on my laptop will be dropped automatically.
+
+It means my annex is littered with \"archive\" folders, but it achieves the desired effect.
+"""]]
diff --git a/doc/forum/Drop_with_assistant/comment_4_1ea37445d5eb96c3efa182e88e07b867._comment b/doc/forum/Drop_with_assistant/comment_4_1ea37445d5eb96c3efa182e88e07b867._comment
new file mode 100644
index 0000000000..56fcfa2549
--- /dev/null
+++ b/doc/forum/Drop_with_assistant/comment_4_1ea37445d5eb96c3efa182e88e07b867._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmU_2tE75oyG0h2ZPN4lcroIKEMC8G-otE"
+ nickname="Michael"
+ subject="comment 4"
+ date="2013-04-11T13:39:13Z"
+ content="""
+A nice feature would be, to  be able to put a .annex-manual file into a subfolder and from that point the files would require manual git-annex management.
+"""]]
diff --git a/doc/forum/Drop_with_assistant/comment_5_c08908ea5232cbe067c73ecd12d0e218._comment b/doc/forum/Drop_with_assistant/comment_5_c08908ea5232cbe067c73ecd12d0e218._comment
new file mode 100644
index 0000000000..b13392a9cd
--- /dev/null
+++ b/doc/forum/Drop_with_assistant/comment_5_c08908ea5232cbe067c73ecd12d0e218._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 5"
+ date="2013-04-11T15:00:10Z"
+ content="""
+Setting your repository to manual doesn't prevent it syncing changes out to other repositories, it just prevents it from downloading the contents of files it doesn't already have.
+
+
+"""]]
diff --git a/doc/forum/Drop_with_assistant/comment_6_015134228cb865f97326fbb7193636ea._comment b/doc/forum/Drop_with_assistant/comment_6_015134228cb865f97326fbb7193636ea._comment
new file mode 100644
index 0000000000..b57bfdda97
--- /dev/null
+++ b/doc/forum/Drop_with_assistant/comment_6_015134228cb865f97326fbb7193636ea._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmU_2tE75oyG0h2ZPN4lcroIKEMC8G-otE"
+ nickname="Michael"
+ subject="comment 6"
+ date="2013-04-12T06:31:17Z"
+ content="""
+@joey But a *manual* node will still be the middleman between say a remote host and a local usb connected to the node?
+"""]]
diff --git a/doc/forum/Drop_with_assistant/comment_7_950759930667588f21659cd6d7065fbb._comment b/doc/forum/Drop_with_assistant/comment_7_950759930667588f21659cd6d7065fbb._comment
new file mode 100644
index 0000000000..c4bd03a9c8
--- /dev/null
+++ b/doc/forum/Drop_with_assistant/comment_7_950759930667588f21659cd6d7065fbb._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 7"
+ date="2013-04-12T13:30:24Z"
+ content="""
+As I understand it, nothing will \"be the middleman\" in the sense of, if annex A has remotes B and C, grabbing content from B in order to give it to C without regards for whether or not A wants it.  Annex A doesn't think in terms of moving content from one remote to another remote, only in terms of pulling and pushing to remotes individually.
+
+I get the \"move content from remote B to C\" effect by setting numcopies=2 and making both remotes \"backup.\"  If content is only on remote B, it will migrate to A in order to fulfill numcopies.  Then it will migrate to C because of C's preferred content settings.
+
+(Respecting minimum numcopies is higher priority than respecting preferred content settings, so even if A wouldn't normally \"want\" the content, it will receive it if it needs to in order to fulfill numcopies.)
+
+I've got A set to \"client\" so content in archive directories disappears once the content is on B and C (because numcopies is fulfilled, and so A's preferred content can take effect.)
+
+If you had A set to \"manual,\" then it wouldn't automatically drop content once it moved from B to A to C, though.  Because it would only drop things manually.
+
+"""]]
diff --git a/doc/forum/Drop_with_assistant/comment_8_773e540e46adc43487323e8d38ceb2d9._comment b/doc/forum/Drop_with_assistant/comment_8_773e540e46adc43487323e8d38ceb2d9._comment
new file mode 100644
index 0000000000..9f9e0855ce
--- /dev/null
+++ b/doc/forum/Drop_with_assistant/comment_8_773e540e46adc43487323e8d38ceb2d9._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 8"
+ date="2013-04-16T20:46:09Z"
+ content="""
+@edheil, you used to be right about the middleman. But I'm continually improving things. :)
+
+So, consider this situation:
+
+> A (client) --- B (client) ---- C (archive)
+
+If a file is created on A, inside an `archive` directory, B wants a copy, since it's not archived yet. Once B gets the copy, it sends it on the C. At that point, B notices that hey, this file was archived and is in an archive directory, and so it no longer wants its copy and drops it.
+
+(At this point A will also want to drop the file. However, it cannot! This is because git-annex requires positive, direct verification that some other repository has a file before dropping it, and A cannot talk to C to check.
+However, if you set C to be trusted, this verification is bypassed, and then A will be able to drop the file as well.)
+
+This support for middlemen is a new feature, which will be in the next release. You can get it in any recent nightly build.
+
+Amusingly this feature was built without writing any haskell code.. just fine-tuning the preferred content expressions!
+
+We can also consider what happens if B is set to manual. In this case, it won't automatically get the file from A. But if you manually get it, then B will send it on to C. And A will drop the file once it hears that C has it. Due to the manual mode, you'll have to manually drop it from B of course.
+"""]]
diff --git a/doc/forum/Drop_with_assistant/comment_9_d85d120d7219ea6c179c2619a17bdae9._comment b/doc/forum/Drop_with_assistant/comment_9_d85d120d7219ea6c179c2619a17bdae9._comment
new file mode 100644
index 0000000000..9c9aa439c8
--- /dev/null
+++ b/doc/forum/Drop_with_assistant/comment_9_d85d120d7219ea6c179c2619a17bdae9._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 9"
+ date="2013-04-17T03:37:48Z"
+ content="""
+Nice!  It sounds like there would be another way to accomplish what I'm currently accomplishing by using numcopies=2 and standard client/backup directories. (backup <--> client <--> backup)
+
+In order to get double backups, I *could* tweak the content settings for my laptop's annex, which is currently set to standard \"client\" mode, so that it's exactly like \"client\" mode except that \"archive\" directories want to drop content which is archived *twice*. (backup <--> tweaked-client <--> backup)
+
+Then I'd get content automatically copying itself out to two archives, and dropping it when it has done so, without touching numcopies.
+
+No reason not to keep doing it the way I'm doing it, since it's simpler, but it's cool to see the assistant getting smarter. :)
+
+"""]]
diff --git a/doc/forum/Dropping_checksum_from_URL_key.mdwn b/doc/forum/Dropping_checksum_from_URL_key.mdwn
new file mode 100644
index 0000000000..d0ae8d7c4b
--- /dev/null
+++ b/doc/forum/Dropping_checksum_from_URL_key.mdwn
@@ -0,0 +1,9 @@
+I accidentally ran git annex importfeed without using the "--relaxed" option. This means that I know have a great many files in the annex with keys that look like this:
+
+> URL-s108794401--https://media.blubrry.com/thedi-7c04aebc2e18898889af95c74ab3edf0
+
+The problem is that these keys seem to encode a size ("s108794401"), and when I attempt to fetch them from their URLs, git annex detects that the size has changed. I'd like to convert all such files to instead use a key without a size. For example:
+
+> URL--https://media.blubrry.com/thedi-7c04aebc2e18898889af95c74ab3edf0
+
+What's the best way to do this? I tried "git annex migrate ... --backend URL" to no avail.
diff --git a/doc/forum/Dropping_checksum_from_URL_key/comment_1_ce952a9db35d398a9e67adcd7f927d59._comment b/doc/forum/Dropping_checksum_from_URL_key/comment_1_ce952a9db35d398a9e67adcd7f927d59._comment
new file mode 100644
index 0000000000..4e09933a18
--- /dev/null
+++ b/doc/forum/Dropping_checksum_from_URL_key/comment_1_ce952a9db35d398a9e67adcd7f927d59._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-11-12T16:10:01Z"
+ content="""
+Migrating to URL will not do anything since they already are url keys.
+
+This could be scripted using `git-annex examinekey` to 
+convert such a key into one without a size, and then using
+`git-annex rekey`, which lets the new key for a file be specified.
+
+However, that command is a low level plumbing command, and does not copy
+over the url list from the old to the new key as migrate does (nor other
+metadata). So you would also have to use `git-annex addurl file url`
+afterwards to add the url, and use `git-annex metadata` if you have
+metadata. Very unergonomic.
+"""]]
diff --git a/doc/forum/Dropping_checksum_from_URL_key/comment_2_bb458296d464c2025f96502338f34000._comment b/doc/forum/Dropping_checksum_from_URL_key/comment_2_bb458296d464c2025f96502338f34000._comment
new file mode 100644
index 0000000000..65576564f5
--- /dev/null
+++ b/doc/forum/Dropping_checksum_from_URL_key/comment_2_bb458296d464c2025f96502338f34000._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-11-12T16:57:15Z"
+ content="""
+Implemented: `git-annex migrate --remove-size --backend=URL`
+
+Be sure to only run it on files using url keys, since it will also 
+remove sizes from other keys. (Or use `--inbackend=URL` with it.)
+
+Do note that `git-annex migrate` can only migrate files whose content
+is present. If you have never downloaded those urls, and `git-annex get`
+cannot download them now, because their size has changed, you
+won't be able to migrate data you don't have. In this case, re-running
+`git-annex addurl` with `--relaxed` seems like the only option.
+"""]]
diff --git a/doc/forum/Dropping_files_in_an_annex.thin_v7_repository.mdwn b/doc/forum/Dropping_files_in_an_annex.thin_v7_repository.mdwn
new file mode 100644
index 0000000000..0ade7cb45e
--- /dev/null
+++ b/doc/forum/Dropping_files_in_an_annex.thin_v7_repository.mdwn
@@ -0,0 +1,16 @@
+I think git-annex is an excellent project and could solve all my backup problems if I can just figure out how to use it properly!
+My primary usage is as a backup tool: I'm a commercial artist and animator so I have a large archive of projects and assets to manage. About two months ago I found out about git-annex and could see how it could help me create a distributed backup system and easily locate which external HDD the data is stored on.
+The tools I use don't play nicely with symlinks, so my local repository is upgraded to v7 and set to annex.thin.
+I had some issues with speed so I followed some steps [here](https://git-annex.branchable.com/tips/Repositories_with_large_number_of_files/) to get backups to complete in less than 30mins.
+
+Now a few months later, I've completed some projects and want to free up the space on my local HDD and just keep the backups - still being able to pull them down when I need to. I moved the files I want to drop into a directory '_archive' inside the repository. I ran 'git annex sync --content --to backupHDD01' at this point
+
+I tried running 'git annex drop _archive' but I get no output and the size of the directory stays the same.
+
+Then I tried locking every file in the directory and dropping it but again, no change.
+
+Looking through the directory, some of the files are broken symlinks (this is what I wanted) but most are still just hardlinks. Furthermore,'git annex whereis file.ext' only returns output on some of the files. 'git status' reports a clean working tree.
+
+Have I misinterpreted this whole annex.thin thing? Is there a better way to do what I want to do?
+
+Thanks! J.
diff --git a/doc/forum/Dropping_files_in_an_annex.thin_v7_repository/comment_1_9f2dcdfe6a689902f348211db6b7a758._comment b/doc/forum/Dropping_files_in_an_annex.thin_v7_repository/comment_1_9f2dcdfe6a689902f348211db6b7a758._comment
new file mode 100644
index 0000000000..5e5460ed58
--- /dev/null
+++ b/doc/forum/Dropping_files_in_an_annex.thin_v7_repository/comment_1_9f2dcdfe6a689902f348211db6b7a758._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-09-10T18:23:24Z"
+ content="""
+I guess you moved the files using something other than `git mv`. So the
+files in `_archive` are not being tracked by git, the same as if you'd
+added new files to the repo.
+
+If so, need to `git annex add _archive`  
+(or `git add _archive` since you're using v7.)
+
+The lack of output from git-annex indicates it's not found any files to
+work on.
+"""]]
diff --git a/doc/forum/Duplicate_entries_in_location_tracking_logs.mdwn b/doc/forum/Duplicate_entries_in_location_tracking_logs.mdwn
new file mode 100644
index 0000000000..f5f1354440
--- /dev/null
+++ b/doc/forum/Duplicate_entries_in_location_tracking_logs.mdwn
@@ -0,0 +1,25 @@
+I’ve noticed something odd when inspecting the history of the
+git-annex branch today. Apparently, the branch had some merge
+conflicts during sync that involved two alternative location tracking
+entries that both were for one and the same remote. Both entries only
+differed in their timestamps, and the union merge kept both, so that I
+now have .log files in the annex branch that contain duplicate parts
+like this.
+
+<pre>
+1404838274.151066s 1 a2401cfd-1f58-4441-a2b3-d9bef06220ad
+1406978406.24838s 1 a2401cfd-1f58-4441-a2b3-d9bef06220ad
+</pre>
+
+The UUID here is my local repository.
+
+The duplication also occurred in the uuid.log:
+
+<pre>
+4316c3dc-5b6d-46eb-b780-948c717b7be5 server timestamp=1404839228.113473s
+4316c3dc-5b6d-46eb-b780-948c717b7be5 server timestamp=1404847241.863051s
+</pre>
+
+Is this something to be concerned about? The situation somehow arose
+in relation to unannexing a bunch of files and rebasing the master
+branch.
diff --git a/doc/forum/Duplicate_entries_in_location_tracking_logs/comment_1_3afb76397519b8ca8b55958a344f1871._comment b/doc/forum/Duplicate_entries_in_location_tracking_logs/comment_1_3afb76397519b8ca8b55958a344f1871._comment
new file mode 100644
index 0000000000..cc159bd30b
--- /dev/null
+++ b/doc/forum/Duplicate_entries_in_location_tracking_logs/comment_1_3afb76397519b8ca8b55958a344f1871._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.112"
+ subject="comment 1"
+ date="2014-08-03T18:59:58Z"
+ content="""
+This is perfectly normal. The next time that file in the git-annex branch is updated for any reason, git-annex will automatically compress the two entries down to a single one. In the meantime, it has no difficulty working out which entry is more recent. This is basically why it's called a log file. ;)
+
+It would be possible to make the union merge code compress as it merges, but this would slow down union merging some, and make it a more conceptually complicated operation. Also, whether the old entry is present in the file or not, git will be storing a copy of that old entry, so it doesn't actually tend to make the git repository any larger. For more on this, see <https://joeyh.name/blog/entry/databranches/>
+"""]]
diff --git a/doc/forum/Duplicate_entries_in_location_tracking_logs/comment_2_6f327444772ee1e660a12e7442162df5._comment b/doc/forum/Duplicate_entries_in_location_tracking_logs/comment_2_6f327444772ee1e660a12e7442162df5._comment
new file mode 100644
index 0000000000..6cce29757b
--- /dev/null
+++ b/doc/forum/Duplicate_entries_in_location_tracking_logs/comment_2_6f327444772ee1e660a12e7442162df5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="134.147.14.84"
+ subject="comment 2"
+ date="2014-08-04T08:05:37Z"
+ content="""
+Thanks for the info, Joey! As long as the git tracks the history anyway, this should not increase space consumption that much.
+
+Perhaps it would be useful to have something like «git annex gc» that can clean up these things manually in some situations, e. g. to compact everything before doing a «git annex forget».
+"""]]
diff --git a/doc/forum/Duplicate_files_not_detected.mdwn b/doc/forum/Duplicate_files_not_detected.mdwn
new file mode 100644
index 0000000000..c1fc323f15
--- /dev/null
+++ b/doc/forum/Duplicate_files_not_detected.mdwn
@@ -0,0 +1 @@
+Using v6 repository and `git add .` / `git commit`, it appears that copying files to new names results in new files being stored (even though they are obviously the same file).  Is there some other command that needs to be executed to have duplicate files detected/removed/linked?
diff --git a/doc/forum/Duplicate_files_not_detected/comment_1_d49a34aae5decafed804f45a573c0027._comment b/doc/forum/Duplicate_files_not_detected/comment_1_d49a34aae5decafed804f45a573c0027._comment
new file mode 100644
index 0000000000..04b0515ef4
--- /dev/null
+++ b/doc/forum/Duplicate_files_not_detected/comment_1_d49a34aae5decafed804f45a573c0027._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jakemagee"
+ avatar="http://cdn.libravatar.org/avatar/85f708f18a2deeefad7719fa70d67c90"
+ subject="comment 1"
+ date="2017-08-02T15:34:19Z"
+ content="""
+Ok, so I figured out the issue with renamed files (needed to change the annex.backend to SHA256) being duplicated.  However, it still seems that appending small changes to large files results in the entire file being duplicated.  Maybe I've confused a feature of git-annex with another project... does git-annex not support chunking files to alleviate duplicating the entire contents of large files with small changes?
+"""]]
diff --git a/doc/forum/Duplicate_files_not_detected/comment_2_c1afe87e818ac3eea66d5216bb15d727._comment b/doc/forum/Duplicate_files_not_detected/comment_2_c1afe87e818ac3eea66d5216bb15d727._comment
new file mode 100644
index 0000000000..53067a0367
--- /dev/null
+++ b/doc/forum/Duplicate_files_not_detected/comment_2_c1afe87e818ac3eea66d5216bb15d727._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~liori"
+ avatar="http://cdn.libravatar.org/avatar/e1d0fdc746b3d21bb147160d40815e37b257b9119774d21784939b2d3ba95a91"
+ subject="comment 2"
+ date="2017-08-04T22:13:43Z"
+ content="""
+> does git-annex not support chunking files to alleviate duplicating the entire contents of large files with small changes?
+
+Indeed it doesn't.
+"""]]
diff --git a/doc/forum/Duplicate_files_not_detected/comment_3_c07b9634f571b5f12665b368c0ad3c80._comment b/doc/forum/Duplicate_files_not_detected/comment_3_c07b9634f571b5f12665b368c0ad3c80._comment
new file mode 100644
index 0000000000..58195e6129
--- /dev/null
+++ b/doc/forum/Duplicate_files_not_detected/comment_3_c07b9634f571b5f12665b368c0ad3c80._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="woffs"
+ avatar="http://cdn.libravatar.org/avatar/198790d74209efe4896fd4cfc37ec2a6"
+ subject="comment 3"
+ date="2017-08-16T13:02:56Z"
+ content="""
+Maybe you mixed it up with `bup`
+"""]]
diff --git a/doc/forum/Editing_Metadata_in_your___36__EDITOR.mdwn b/doc/forum/Editing_Metadata_in_your___36__EDITOR.mdwn
new file mode 100644
index 0000000000..c7560928f6
--- /dev/null
+++ b/doc/forum/Editing_Metadata_in_your___36__EDITOR.mdwn
@@ -0,0 +1,26 @@
+Hey everyone,
+
+I made a Python script that launches your `$EDITOR` (or `$VISUAL`) to conveniently edit git-annex metadata.
+
+Code is [on Gitlab](https://gitlab.com/nobodyinperson/git-annex-metadata-edit).
+
+## 📥 Installation
+
+```bash
+# Installation
+pip install git+https://gitlab.com/nobodyinperson/git-annex-metadata-edit
+```
+
+## ✨ Features
+
+- Operate on multiple files (recursively)
+- overwrite/remove a metadata field
+- add/remove specific values from a field in one go
+
+## 📟 📹 Screencast
+
+[![asciicast](https://asciinema.org/a/541576.svg)](https://asciinema.org/a/541576?autoplay=1)
+
+Cheers, 👍
+
+Yann
diff --git a/doc/forum/Editing_files_in_metadata_driven_view.mdwn b/doc/forum/Editing_files_in_metadata_driven_view.mdwn
new file mode 100644
index 0000000000..993e3bad34
--- /dev/null
+++ b/doc/forum/Editing_files_in_metadata_driven_view.mdwn
@@ -0,0 +1,3 @@
+I was testing metadata driven view and it seems that it is not meant for
+editing files. Am I correct? Although in this [tip and comments](https://git-annex.branchable.com/tips/metadata_driven_views/) I get impression
+that editing might be ok same way it is in GIT-branches normally. [Documentation does not say anything about editing](https://git-annex.branchable.com/git-annex-view/)
diff --git a/doc/forum/Editing_files_in_metadata_driven_view/comment_1_acb4656e0dafc5689c84d4cca760bafa._comment b/doc/forum/Editing_files_in_metadata_driven_view/comment_1_acb4656e0dafc5689c84d4cca760bafa._comment
new file mode 100644
index 0000000000..7d197d3d78
--- /dev/null
+++ b/doc/forum/Editing_files_in_metadata_driven_view/comment_1_acb4656e0dafc5689c84d4cca760bafa._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-12-15T16:50:43Z"
+ content="""
+Well, you can edit files and make changes, but a view branch is not
+your master branch. If you add a new file, or edit an existing file in
+a view branch, nothing will update the master branch to add that new file
+to it.
+
+When you switch back to the master branch, or check out a new view
+branch, your changes remain in the view branch. They're not lost,
+because each view branch has its own name, and you can check out the branch
+again. 
+
+Although re-running `git annex view` will regenerate the view
+branch, so losing your changes. (The old version of the branch will still
+be preserved in git's reflog for a while.)
+
+I'd say they're mostly for viewing, not editing, but there might be ways
+to use them for editing given these constraints.
+"""]]
diff --git a/doc/forum/Effectively_replicating_backup_files.mdwn b/doc/forum/Effectively_replicating_backup_files.mdwn
new file mode 100644
index 0000000000..85d8f4b52e
--- /dev/null
+++ b/doc/forum/Effectively_replicating_backup_files.mdwn
@@ -0,0 +1,25 @@
+I currently use duply/duplicity to back up my networked computers to my home server. I have two external HDDs and, every week or so, I bring one of these home and copy the backup files to the hard drive (I leave them on the server to easily restore files and because I have a large hard drive in that). I use some hand-written scripts to keep a copy these backup files in the cloud (Ubuntu One) until they have been copied to both hard drives, ensuring that there are always two copies of the files somewhere offsite. Out of paranoia, I also have some "standalone backups" that are just huge encrypted archives of important folders (say, my entire Photos directory) as at a certain date - in case for some reason duplicity ever stops working or I need to roll something back to a version years earlier. I am less worried about these standalone backups and manually keep one copy of each somewhere.
+
+It sounds like Git-Annex could automate things quite nicely (and give me some neat extras, like knowing where they were). This is how I understand I should do it, but please let me know if it is the right approach or if you have any suggestions:
+
+1. Create a folder on my server called "annex" and make a Git-Annex "large backup" repository in there.
+2. Create a folder within that called "archive" and put a "backup" folder within that. I understand that having the backups within an archive folder will mean that they aren't automatically copied to my desktop machines etc. 
+3. Within that "backup" folder, create two folders, one called "duplicity" and one called "standalone". Put the backups in the respective folders.
+4. Set up gcrypt Git-Annex repositories on my two external HDDs as "small backups". This seems to just start copying files across. That surprised me, as the files are in the archive folder and I thought the default was numcopies=1. Is there some autosync option that I need to turn off? Ideally, I would like it to encrypt/decrypt primarily with my server GPG key (which I'm not worried about copying around my computers), but also encrypt to my personal GPG key (where I'd only put my public key on the server, but I know I will not lose the secret key for that). Am I right that to do that I would need to set the repos up manually with:
+
+    git init --bare /mnt/externalHDD1
+
+    git annex initremote externalHDD1 type=gcrypt gitrepo=/mnt/externalHDD1 keyid=$serverkey keyid=$personalkey
+
+    git annex sync externalHDD1
+
+    Or should the gitrepo be the location of my main Git-Annex repository? How do I make it sync up with my other repos?
+
+5. I understand that I would then need to set numcopies=3 in a .gitattributes file in the "archive/backup/duplicity" directory and, say, a numcopies=2 in the "archive/backup/standalone".
+6. I could then add a cloud repository as a "transfer" repository and Git-Annex should only keep files on that that are not already in the right number of places (similar to what my scripts are doing now).
+7. I have recently upgraded my hard drive, so I have my old 1TB internal hard drive that I will be putting in a cupboard somewhere. I was thinking that I could make this an archive drive for things like one copy of my duplicity/standalone backups. I wouldn't want it to be the only copy of anything. If I just set it as an archive drive, would this work?
+8. Are there more clever ways of doing this? I consider my external HDDs and the cloud repo as "offsite" repositories and ideally there would always be one copy of my backups offsite (in addition to at least three overall). There would also ideally be one of each of my files "live" (in most cases my server) that could instantly push files into a cloud repo and then to wherever I am. Is there any ability to put repositories in groups and write rules like that?
+
+Any thoughts greatly appreciated!
+
+Aaron
diff --git a/doc/forum/Effectively_replicating_backup_files/comment_1_b1ab0da82db076c5244b0dcc95282ddd._comment b/doc/forum/Effectively_replicating_backup_files/comment_1_b1ab0da82db076c5244b0dcc95282ddd._comment
new file mode 100644
index 0000000000..54f7f782a3
--- /dev/null
+++ b/doc/forum/Effectively_replicating_backup_files/comment_1_b1ab0da82db076c5244b0dcc95282ddd._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-07T16:42:14Z"
+ content="""
+This all sounds reasonable to me.
+
+gitrepo= is the location of the repository you are setting up with gcrypt, not your existing git-annex repository.
+
+numcopies configures the lower bound of the number of copies, not the upper bound. There's no \"small backup\" type, you must mean either small archive, or incremental backup. Either type of repository is going to want to have files that have not previously been archived, or backed up.
+
+You might eventually want to write your own [[preferred_content]] expressions to handle offsite repositories. I'd recommend starting simple and building up.
+"""]]
diff --git a/doc/forum/Effectively_replicating_backup_files/comment_2_472ab9c973b475f7f3ce7e3934f94281._comment b/doc/forum/Effectively_replicating_backup_files/comment_2_472ab9c973b475f7f3ce7e3934f94281._comment
new file mode 100644
index 0000000000..668416c047
--- /dev/null
+++ b/doc/forum/Effectively_replicating_backup_files/comment_2_472ab9c973b475f7f3ce7e3934f94281._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnFjuvfPpi1kf6l54bxfFUm0Aw_Gf_IO0o"
+ nickname="Aaron"
+ subject="comment 2"
+ date="2013-11-07T19:46:32Z"
+ content="""
+Thanks Joey!
+
+> gitrepo= is the location of the repository you are setting up with gcrypt, not your existing git-annex repository.
+
+Great, thanks. If I set these up outside of the WebApp, what is the best way to link them up to my main repositories?
+
+> numcopies configures the lower bound of the number of copies, not the upper bound. There's no \"small backup\" type, 
+> you must mean either small archive, or incremental backup. Either type of repository is going to want to have files 
+> that have not previously been archived, or backed up.
+
+Yes, I meant incremental backup. Thanks, understood. The page on preferred content ( http://git-annex.branchable.com/preferred_content/ ) made things a bit clearer. I didn't realise that the incremental backups etc want a copy even if it isn't necessary to satisfy numcopies. Does that mean that once it is on one backup drive, it will not be sent to the other unless I increase numcopies?
+
+"""]]
diff --git a/doc/forum/Effectively_replicating_backup_files/comment_3_826493bd59b81786c1f6a56f1c438004._comment b/doc/forum/Effectively_replicating_backup_files/comment_3_826493bd59b81786c1f6a56f1c438004._comment
new file mode 100644
index 0000000000..9088de9e73
--- /dev/null
+++ b/doc/forum/Effectively_replicating_backup_files/comment_3_826493bd59b81786c1f6a56f1c438004._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2013-11-08T17:06:02Z"
+ content="""
+The webapp can use remotes that you have configured at the command line just as well as it can use remotes you configure using the webapp.
+
+Each file only gets backed up to one incremental backup repository. If you have a full backup repository it will (try to) get another copy of every single file.
+"""]]
diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another.mdwn b/doc/forum/Efficiently_move_files_from_one_repo_to_another.mdwn
new file mode 100644
index 0000000000..3b9a9a74ab
--- /dev/null
+++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another.mdwn
@@ -0,0 +1,26 @@
+Hi,
+
+## Context
+
+I use git-annex to work with my files on multiple computers, and also to collaborate with other people on my files. Since I don't want to share all my files to all the devices (especially not these of other people), I have several different annex-repos. Of course there is location tracking and file content is not required on all devices. Still, for some devices I want a clear separation in the sense that there should not be any trace that the files from the other repos even exist. However, sometimes I want to change the "permissions" for a file or directory (meaning I have to move it to another repo).
+
+## Problem
+
+Having multiple annex-repos is a reasonable workaround for the use case discussed above. One remaining issue is that moving files or folders from one repo to another is quite inefficient. This is especially true for the remotes.
+
+### Example:
+
+Having two annex-repos (Repo-A and Repo-B) on my laptop. Both repos also exist on my server. All content is synced among the devices. On the laptop I move a large subdir from Repo-A to Repo-B. If I sync both repos with the server afterwards, I have to re-upload all files even though they are already there, but in a different repo.
+
+## Question
+
+Is there an efficient way to move files from one repo to another that works in the example given above?
+
+## Possible approach
+
+I could imagine something like a device-wide location tracking. In this case Repo-B could check "Is this file available in another repo on the same device?" and get it locally. However, for my use case it is really important, that this device-wide location tracking is not synchronized among all the remotes.
+
+### Example:
+
+Again there are Repo-A and Repo-B on laptop and server. Another repo Repo-C is on my laptop and my phone. The phone knows nothing about Repo-A and Repo-B and also is not aware that the server even exists. And this should stay this way. This means that the laptop must not tell the phone that there are other remotes and other repos, as well.
+
diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_10_191ca3a984412be76f64aa31b55b8d50._comment b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_10_191ca3a984412be76f64aa31b55b8d50._comment
new file mode 100644
index 0000000000..285ad6f560
--- /dev/null
+++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_10_191ca3a984412be76f64aa31b55b8d50._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2018-12-03T17:24:50Z"
+ content="""
+Have you tried using --jobs? That often avoids such bottlenecks.
+"""]]
diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_1_0cc04ef5e511241a5152a0702f943538._comment b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_1_0cc04ef5e511241a5152a0702f943538._comment
new file mode 100644
index 0000000000..62ec2124c1
--- /dev/null
+++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_1_0cc04ef5e511241a5152a0702f943538._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-09-24T15:58:03Z"
+ content="""
+Location tracking tracks locations of keys, not of filenames or directory names (unless you use the WORM backend).  Are you sure you care if other people know what keys (checksums) exist on your non-shared system?   If you don't, you could keep the contents of different repos as unconnected/unrelated branches in the same git repo.  See also [[https://git-annex.branchable.com/tips/local_caching_of_annexed_files/]]
+"""]]
diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_2_be029c0880e76d6b5672eed394140438._comment b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_2_be029c0880e76d6b5672eed394140438._comment
new file mode 100644
index 0000000000..add32237cb
--- /dev/null
+++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_2_be029c0880e76d6b5672eed394140438._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="re: comment 1"
+ date="2018-09-24T18:02:38Z"
+ content="""
+Hi Ilya_Shlyakhter, thanks for your answer.
+
+I'm not sure about using different branches. What prevents other users from just checking out the branches, also the git-annex branch tracks the clear names of all remotes. Moreover, it's a scalability question. Assume the server has thousands (millions?) of files while the phone has only a few. Then it still would be \"bothered\" all the location tracking information of the server.
+
+But one thing in the »local caching« tip raised my attention: \"git config remote.cache.annex-speculate-present true\"
+
+The tip says: \"The annex-speculate-present setting is the essential part. It makes git-annex know that the cache repository may contain the content of any annexed file. So, when getting a file, git-annex will try the cache repository first.\"
+
+Together with \"git config remote.cache.annex-pull false; git config remote.cache.annex-push false\" this could be pretty close to my \"local location tracking\" idea.
+
+It further says: \"The cache repository will remain an empty git repository (except for the content of annexed files). This means that the same cache can be used with multiple different git-annex repositories, without intermingling their git data.\" Thus, there should be no »information leaks« between two repos that both use this cache.
+
+A thing I would have to work around is that I should not do \"git annex --copy --to server --not --in server\". Or, at least before doing this I should always log into the server and do \"git-annex get\" first.
+
+Thanks again for your suggestion. I will give this approach a try.
+"""]]
diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_3_c2f4b10fa1789a4966aed298e00dbc75._comment b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_3_c2f4b10fa1789a4966aed298e00dbc75._comment
new file mode 100644
index 0000000000..5e4b0f5eef
--- /dev/null
+++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_3_c2f4b10fa1789a4966aed298e00dbc75._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2018-09-24T18:29:36Z"
+ content="""
+See also config settings remote.<name>.annex-readonly , remote.<name>.annex-push, remote.<name>.annex-pull etc.
+"""]]
diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_4_65bbee3637d09bb6078ec7b118852fd8._comment b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_4_65bbee3637d09bb6078ec7b118852fd8._comment
new file mode 100644
index 0000000000..c1000dc45a
--- /dev/null
+++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_4_65bbee3637d09bb6078ec7b118852fd8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="comment 4"
+ date="2018-09-25T09:45:00Z"
+ content="""
+I discovered one potential problem with this approach. The \"server\" in my example typically has \"--bare\" repos created by gitolite. I'm not sure if I can convince such a repo to get files from the cache. But I will try and report my findings.
+
+Is there a way to tell a remote repo (e.g. the server) to get files from another remote?
+"""]]
diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_5_45c1788b39953cd7237f014fa94e086b._comment b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_5_45c1788b39953cd7237f014fa94e086b._comment
new file mode 100644
index 0000000000..798fbfea27
--- /dev/null
+++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_5_45c1788b39953cd7237f014fa94e086b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 5"
+ date="2018-09-25T15:23:35Z"
+ content="""
+Maybe http://git-annex.branchable.com/bare_repositories/ can help.  Also, for the approach suggested earlier of storing different repos as unrelated branches in the same repo, maybe could use refspecs and hierarchical branch names (with '/') to keep things sufficiently separate.
+"""]]
diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_6_23b3a1a1412866fa06e736f0f5bab583._comment b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_6_23b3a1a1412866fa06e736f0f5bab583._comment
new file mode 100644
index 0000000000..25b4989713
--- /dev/null
+++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_6_23b3a1a1412866fa06e736f0f5bab583._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2018-09-25T18:14:19Z"
+ content="""
+If you perform the same move between repos on both the laptop and the
+server, git-annex will generate the same keys for the files on both of
+them, and so won't need to transfer the data again.
+"""]]
diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_7_fba097cd3187d1d8b7517594d875c373._comment b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_7_fba097cd3187d1d8b7517594d875c373._comment
new file mode 100644
index 0000000000..a6d2fa8f12
--- /dev/null
+++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_7_fba097cd3187d1d8b7517594d875c373._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="comment 7"
+ date="2018-09-25T21:33:17Z"
+ content="""
+Joey, that's true. However, one of the things I like most about git-annex is that I don't have to repeat operations (like renaming/moving of files) on each remote. Therefore, I try to also automate this behavior even if the move operation spans two repos (if both repos exist on the remote).
+
+Probably such \"actions\" (get files from another local repo) could be checked-in as \"todos\" into the repo. Then the remote could try to perform it after a sync. However, I imagine that its hard to design this in a straight forward way and could get pretty messy. Therefore, I thought some kind of \"local location tracking\" could be the cleaner solution.
+
+My preferred solution would be the following. But I guess this would require changes in git-annex: Multiple local repos can share a single .git/annex/objects directory. Typically a repo would only know about its own files in there (and would not care about files put there by other repos at all, especially not leaking them into the location tracking). But if a file is checked-in into a repo (\"sync\", not \"sync --content\") and the content of this file is already present (e.g. because it also exists in another repo), the repo would detect that the file is there and updates location tracking for this file.
+
+I presume the \"local cache\" approach with hardlinks is the next best thing to this idea, that not requires changes to git-annex. E.g. some scripting/hooks that performs a \"get\" operation after a sync..
+"""]]
diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_8_b8f81522e519bab56036cc8628f29ce9._comment b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_8_b8f81522e519bab56036cc8628f29ce9._comment
new file mode 100644
index 0000000000..25df0a8f06
--- /dev/null
+++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_8_b8f81522e519bab56036cc8628f29ce9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="comment 8"
+ date="2018-09-25T21:59:10Z"
+ content="""
+Ilya_Shlyakhter, thanks for the link. Apparently \"git-annex get\" also works on bare repos (but I still have to find out how to use this with gitolite, maybe I can write some custom hook or something..)
+
+About the refspecs etc. I think my git-knowledge is not sufficient to fully grasp your idea. But there's one thing that makes me hesitate. I'm looking for a solution that is as less \"special\" as possible. If I have to remember what I was thinking when I designed all this, I'm pretty sure things will break eventually. Thus, in a good solution all thinks should work identically as with regular git-annex. If I have to remember something to do things (e.g. move operations) more efficiently that's okay, as long as things don't break when I just use my repo like a regular git-annex repo. I'm not sure if your approach would provide this.
+
+Also, I suppose I would have to \"design\" one mega-repository for all my current (and probably future) use cases. A loose coupling of otherwise separated repos seems not to be possible, as far as I understand the solution. This could especially become an issue for repos I want to share with others.
+"""]]
diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_9_3e5f41a5cce30c21cea629009f91dd31._comment b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_9_3e5f41a5cce30c21cea629009f91dd31._comment
new file mode 100644
index 0000000000..b8277bad53
--- /dev/null
+++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_9_3e5f41a5cce30c21cea629009f91dd31._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="toh_corpora"
+ avatar="http://cdn.libravatar.org/avatar/c4265d106fd775ab35231ea3f9696cb0"
+ subject="comment 9"
+ date="2018-11-27T14:10:53Z"
+ content="""
+I have had a lot of success with some scripts I have written that externally assist git-annex in moving large files. Perhaps they can be at some point integrated into git-annex. I understand that this probably isn't a priority for Joey.
+
+One thing that has made a huge difference for me is asynchronous verification of content. I have a turbo-copy script which simply copies keys from one repo to another externally, and then triggers an fsck in the target repo after it has finished copying everything. In many cases, this makes a huge improvement in transfer speed. I might have it start an fsck in the target as soon as each file is copied externally.
+
+I have also been experimenting with using make to externally manage git-annex pipelines, where it makes more sense to do more simultaneous copies for smaller files, for certain backends.
+
+One thing that would be amazingly helpful, is if there was a way that a backend could inform git-annex ahead of time what it intends to do. For me, when I encrypt and upload files  > 40M  < 400M to Google Drive, git-annex spends about 50% of its time encrypting, and 50% uploading. It would substantially improve performance if git-annex could get to work on the next file while the current one is uploading. I don't know if it is possible for a backend to do this. I think that it would have to falsly claim success to get git-annex to give it the next file.l
+"""]]
diff --git a/doc/forum/Encrypted_Content_Remote_Daemon_.mdwn b/doc/forum/Encrypted_Content_Remote_Daemon_.mdwn
new file mode 100644
index 0000000000..614d276884
--- /dev/null
+++ b/doc/forum/Encrypted_Content_Remote_Daemon_.mdwn
@@ -0,0 +1 @@
+I am currently using rsync.net to keep my notes in sync, both git repo and the content (gpg encrypted) is stored there. Instead of creating two other repos on a server that I have which has git-annex installed where I can actually use remote daemon. Is it possible to create a repo containing both the git repo and the content encrypted from the command line?
diff --git a/doc/forum/Encrypted_Content_Remote_Daemon_/comment_1_96f63e509e23c081c48302274e21db78._comment b/doc/forum/Encrypted_Content_Remote_Daemon_/comment_1_96f63e509e23c081c48302274e21db78._comment
new file mode 100644
index 0000000000..eb97c2680e
--- /dev/null
+++ b/doc/forum/Encrypted_Content_Remote_Daemon_/comment_1_96f63e509e23c081c48302274e21db78._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.114"
+ subject="comment 1"
+ date="2014-04-27T00:31:18Z"
+ content="""
+Why not go all the way and encrypt the git repository stored on the remote server too? [[special_remotes/gcrypt]]
+
+When you have git-annex-shell installed on the remote server, the remote daemon should work for gcrypt repositories as well as normal non-encrypted git repositories.
+"""]]
diff --git a/doc/forum/Encrypted_Content_Remote_Daemon_/comment_2_acd0ffdc3f5079265858073c2af81557._comment b/doc/forum/Encrypted_Content_Remote_Daemon_/comment_2_acd0ffdc3f5079265858073c2af81557._comment
new file mode 100644
index 0000000000..a699ad640c
--- /dev/null
+++ b/doc/forum/Encrypted_Content_Remote_Daemon_/comment_2_acd0ffdc3f5079265858073c2af81557._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 2"
+ date="2014-04-28T09:14:12Z"
+ content="""
+I would love to use gcrypt and I tried it but the problem is at every sync it will ask for my pass phrase even though the key used to encrypt the repo is pass phrase less it goes through the keys in my keychain and asks me to unlock all my keys one by one.
+"""]]
diff --git a/doc/forum/Encrypted_ssh_remote__44___synced_folders.mdwn b/doc/forum/Encrypted_ssh_remote__44___synced_folders.mdwn
new file mode 100644
index 0000000000..ea54026f87
--- /dev/null
+++ b/doc/forum/Encrypted_ssh_remote__44___synced_folders.mdwn
@@ -0,0 +1,87 @@
+Hello,
+
+I hope my understanding of the git-annex webapp is correct, and if not, please correct my wrong thought-pattern.
+
+I have 2 VPS servers and 5 computers. On the 5 computers, I want to sync one folder (with subfolders and files). All the computers are full-disk encrypted, and it is important for me that when the data leaves my computer, it stays encrypted in one way or another. I want to use the two VPS's as an encrypted ssh full backup repository.
+
+The computers are rarely on at the same time, some are off for two weeks, others are on more frequent. However, the VPS's are always on.
+
+Now, is it possible to set up git-annex to support this behaviour? Using an encrypted ssh remote to make sure the folder is in sync on all computers? 
+
+I've set git-annex up on one box, with the two servers as encrypted full backup remotes (without git-annex installed there), and configured my jabber account. That all works, and the files get synced.
+
+Then I've set up a second computer, while the first one is still on. There I've added my jabber account, and created a local repository. Then I selected "Share with your other devices". It now shows my jabber account on both machines, and I saw a few syncing messages, but then there came errors, "Unable to download files from your other devices". I've attached the log at the bottom of this page.
+
+It gives me the option to add a Cloud Repository. If I add the encrypted rsync full backup remote VPS there, will it work and keep my files in sync? is there something I'm doing wrong?
+
+Note that the computers I've set up now are two OS X machines running Mountain Lion, and the servers are CentOS 6.
+
+Log:
+
+
+    [2013-07-15 07:44:17 CEST] main: starting assistant version 4.20130709-g18e5f43
+
+    (scanning...) [2013-07-15 07:44:17 CEST] Watcher: Performing startup scan
+    (started...) [2013-07-15 07:45:08 CEST] main: starting assistant version 4.20130709-g18e5f43
+
+    (scanning...) [2013-07-15 07:45:08 CEST] Watcher: Performing startup scan
+    (started...) [2013-07-15 07:54:31 CEST] XMPPClient: Pairing with stnl in progress
+    rercrrrreveeeec:ccccv vvvv:r:::: e    rsrrrreoeeeesussssorooooucuuuurerrrrc cccceveeee a    vnvvvvaiaaaansnnnnihiiiisesssshdhhhhe eeeed(dddd C    (o((((CnCCCConoooonennnnncnnnneteeeecicccctottttiniiiio oooonrnnnn e    rsrrrreeeeeestsssse eeeetbtttt y    b bbbbypyyyy e    peppppereeeee)eeeer
+    rrrr)))))
+
+
+
+
+    recv: resource vanished (Connection reset by peer)
+    recv:r errceevcs:vo :ur rercseeos uovruacrneci esv havenadin si(hsCehoden dn( eC(coCtnoinnoennce tcriteoisnoe ntr  erbseyes tep teb eybr y)p
+    epeere)r
+    )
+    [2013-07-15 07:55:00 CEST] XMPPSendPack: Syncing with janwxmpp
+    Already up-to-date.
+    recv: resource vanished (Connection reset by peer)
+    [2013-07-15 07:55:04 CEST] XMPPReceivePack: Syncing with janwxmpp
+    To xmpp::janwxmpp@gmail.com
+     * [new branch]      git-annex -> refs/synced/0a41c397-09e8-4957-a6f4-2a6846a4f9d8/cmVsc3RubEBnbWFpbC5jb20=/git-annex
+     * [new branch]      master -> refs/synced/0a41c397-09e8-4957-a6f4-2a6846a4f9d8/cmVsc3RubEBnbWFpbC5jb20=/master
+    [2013-07-15 07:55:25 CEST] XMPPSendPack: Unable to download files from your other devices.
+    [2013-07-15 07:55:25 CEST] XMPPSendPack: Syncing with janwxmpp
+    recv: resource vanished (Connection reset by peer)
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+    [2013-07-15 07:57:25 CEST] XMPPSendPack: Unable to download files from your other devices.
+    recv: resource vanished (Connection reset by peer)
+    recv: resource vanished (Connection reset by peer)
+    recv: resource vanished (Connection reset by peer)
+    recv: resource vanished (Connection reset by peer)
+    recv: resource vanished (Connection reset by peer)
+
+    (Recording state in git...)
+
+    (scanning...) [2013-07-15 08:01:36 CEST] Watcher: Performing startup scan
+    (started...) recvr:rrrrrrre eeeeeeecrcccccccvevvvvvvv:s::::::: o       rurrrrrrrereeeeeeescsssssssoeooooooou uuuuuuurvrrrrrrrcaccccccceneeeeeee i       vsvvvvvvvahaaaaaaanennnnnnnidiiiiiiis sssssssh(hhhhhhheCeeeeeeedoddddddd n       (n(((((((CeCCCCCCCocooooooontnnnnnnnninnnnnnneoeeeeeeecnccccccct tttttttiriiiiiiioeooooooonsnnnnnnn e       rtrrrrrrre eeeeeeesbssssssseyeeeeeeet ttttttt p       bebbbbbbbyeyyyyyyy r       p)pppppppe
+    eeeeeeeeeeeeeeerrrrrrrr))))))))
+
+
+
+
+
+
+
+    [2013-07-15 08:44:42 CEST] XMPPSendPack: Syncing with janwxmpp
+    recv: resource vanished (Connection reset by peer)
+    recrvre:ec cvrv:e: s roreuesrsocoueur rcvceae n vivasanhnieisdsh he(edCd o (n(CnCoeoncnntneiecoctnti ioronen s reretes sebetyt   bpbyey e prpe)ee
+    err))
+
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+    [2013-07-15 08:46:42 CEST] XMPPSendPack: Unable to download files from your other devices.
+    [2013-07-15 08:46:42 CEST] XMPPSendPack: Syncing with janwxmpp
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+    [2013-07-15 08:48:42 CEST] XMPPSendPack: Unable to download files from your other devices.
diff --git a/doc/forum/Encrypted_ssh_remote__44___synced_folders/comment_1_7b9b4ef614c90e0b222d24678d1b9026._comment b/doc/forum/Encrypted_ssh_remote__44___synced_folders/comment_1_7b9b4ef614c90e0b222d24678d1b9026._comment
new file mode 100644
index 0000000000..9ebee5f702
--- /dev/null
+++ b/doc/forum/Encrypted_ssh_remote__44___synced_folders/comment_1_7b9b4ef614c90e0b222d24678d1b9026._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 1"
+ date="2013-07-16T19:40:20Z"
+ content="""
+Yes, you need to add the rsync remote to the second computer. Once it's set up, they will be able to exchange file contents using it, and using XMPP as a control channel.
+
+If the first computer already has that rsync remote configured, it should push some notes about the existance of that remote to the second one, over XMPP. Then in the webapp, you should just need to click on \"enable\" next to the rsync remote, and it'll prompt for the necessary info to set it up.
+"""]]
diff --git a/doc/forum/Ensure_all_versions_are_on_remotes.mdwn b/doc/forum/Ensure_all_versions_are_on_remotes.mdwn
new file mode 100644
index 0000000000..a4656f27d8
--- /dev/null
+++ b/doc/forum/Ensure_all_versions_are_on_remotes.mdwn
@@ -0,0 +1,36 @@
+I thought I was getting the hang of annex, but have run into a bit of a problem. I could use some help ensuring that everything ends up in the right place.
+
+Specifically, it seems like sync does a lot more than push and pull files - that it might actually try to drop things from remotes (at least with the -a) command.
+
+I have two machines I work on, and should only have active content on them. I have two special remotes (S3/wasabi) that should have everything that's ever been annexed, including old versions of files.
+
+If I `git annex sync -a -A` then it will pull all versions locally as well. So I think I may have to separate the get and copy commands?
+
+Here's what I'm doing so far:
+
+
+```
+git annex config --set annex.synccontent false
+git annex config --set annex.synconlyannex true
+git annex config --set annex.autocommit false
+
+git annex group wasabi-east wasabi
+git annex group wasabi-west wasabi
+git annex groupwanted wasabi anything
+git annex required wasabi-east groupwanted
+git annex required wasabi-west groupwanted
+
+git annex group machine1 active
+git annex group machine2 active
+git annex groupwanted active anything
+
+# from machine1
+git annex sync -a origin machine2 wasabi-east wasabi-west
+git annex get -a
+for remote in "wasabi-east wasabi-west"
+do
+  git annex copy -A --not --in $remote -t $remote
+done
+```
+
+I think that's what I need to do? I don't think I can use `git annex sync -a -A wasabi-east wasabi-west` because I don't want to pull old versions to my local machine.
diff --git a/doc/forum/Ensure_all_versions_are_on_remotes/comment_1_b8b674dc99999dcdb5a435f34b96c1ea._comment b/doc/forum/Ensure_all_versions_are_on_remotes/comment_1_b8b674dc99999dcdb5a435f34b96c1ea._comment
new file mode 100644
index 0000000000..b389c86a20
--- /dev/null
+++ b/doc/forum/Ensure_all_versions_are_on_remotes/comment_1_b8b674dc99999dcdb5a435f34b96c1ea._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 1"
+ date="2022-09-13T09:53:45Z"
+ content="""
+The [`unused` preferred content expression](https://git-annex.branchable.com/git-annex-preferred-content/) is probably what you're looking for.
+
+As for your second problem, add your client repositories to a group aswell and make them only want `present`, `approxlackingcopies=1` or something along those lines. That will stop `sync --content` from trying to pull down everything.
+"""]]
diff --git a/doc/forum/Ensure_all_versions_are_on_remotes/comment_2_ad5f1f0b98032361e64bb7275d23e97c._comment b/doc/forum/Ensure_all_versions_are_on_remotes/comment_2_ad5f1f0b98032361e64bb7275d23e97c._comment
new file mode 100644
index 0000000000..ccf430fe27
--- /dev/null
+++ b/doc/forum/Ensure_all_versions_are_on_remotes/comment_2_ad5f1f0b98032361e64bb7275d23e97c._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-13T18:40:02Z"
+ content="""
+`sync --content` will certianly remove files from a repository when
+the preferred content settings for that repository indicate it should
+not contain that content.
+
+When you use `sync --all`, a preferred content setting like
+`"include=*"` or `"exclude=*"` will only ever match files in the current
+working tree, not past versions of files. 
+
+So, if the remote has such a preferred content expression, `sync --all
+--content` will remove the past versions of files from it.
+
+The way to avoid this behavior is to use a preferred content expression
+that does not match on the filename. Eg, `"anything"`. Or don't set a
+preferred content expression in the first place.
+"""]]
diff --git a/doc/forum/Ensure_all_versions_are_on_remotes/comment_3_d9bd5f9ef8c8a8cc08cc39396f0a6f67._comment b/doc/forum/Ensure_all_versions_are_on_remotes/comment_3_d9bd5f9ef8c8a8cc08cc39396f0a6f67._comment
new file mode 100644
index 0000000000..34794bd433
--- /dev/null
+++ b/doc/forum/Ensure_all_versions_are_on_remotes/comment_3_d9bd5f9ef8c8a8cc08cc39396f0a6f67._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 3"
+ date="2022-09-13T21:14:02Z"
+ content="""
+hrm… as you can see in my post, I AM using “anything” as the wanted content. So I would expect all of the remotes (wasabi and machines) to get all of the file versions. But that’s not happening. It’s behaving more like “used” would.
+
+I will try “anything or unused” despite the fact that it seems like “or unused” should be unnecessary.
+"""]]
diff --git a/doc/forum/Ensure_all_versions_are_on_remotes/comment_4_8d07699b69676d9afd53744f267bb615._comment b/doc/forum/Ensure_all_versions_are_on_remotes/comment_4_8d07699b69676d9afd53744f267bb615._comment
new file mode 100644
index 0000000000..53e3c253e6
--- /dev/null
+++ b/doc/forum/Ensure_all_versions_are_on_remotes/comment_4_8d07699b69676d9afd53744f267bb615._comment
@@ -0,0 +1,116 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-09-15T18:31:04Z"
+ content="""
+I think I've set up what you wanted.. And I think enroute I started
+to understand the problem you were having.
+
+Both of the wasabis want all content whether it's unused or not. So I left
+their preferred and required content settings unchanged since that's the
+default. ("anything" would have the same effect). To make the local repository
+want to not hang onto unused content I used:
+
+	git-annex wanted here 'include=*'
+
+With that, `git-annex sync --content --all wasabi-east` would copy an
+unused key to wasabi-east. But then it would drop it from the local
+repository. So a subsequent sync with wasabi-west was not able
+to send a copy to there, because it's already been removed from the local
+repo. I think perhaps that is the problem you were having?
+
+A workaround is to sync with both at once, like you have been doing:
+
+	joey@darkstar:~/tmp/bench/foo>git-annex sync --content --all wasabi-west wasabi-east
+	commit 
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	copy SHA256E-s30--4b03bc898384c2cf2861327108e988ba56d839b831e743d87b066cc4a5a7f487 (to wasabi-west...) 
+	ok                                
+	copy SHA256E-s30--4b03bc898384c2cf2861327108e988ba56d839b831e743d87b066cc4a5a7f487 (to wasabi-east...) 
+	ok                                
+	drop SHA256E-s30--4b03bc898384c2cf2861327108e988ba56d839b831e743d87b066cc4a5a7f487 ok
+	(recording state in git...)
+
+But if you forget to sync with both at the same time, or if one of them
+is unreachable, you can end up with only one of them having a copy.
+Not great.
+
+To avoid that problem, I set numcopies, to force there to be 2 copies
+at all times:
+
+	joey@darkstar:~/tmp/bench/foo>git-annex numcopies 2
+	numcopies 2 ok
+
+Now syncing with one of the wasabi remotes keeps the unused content locally
+present:
+
+	joey@darkstar:~/tmp/bench/foo>git-annex sync --content wasabi-east --all
+	commit 
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	copy SHA256E-s30--906a7a36a37e2ffcee8164da8d7275a7fc1d775b3a9c040771725c9f1e4a9222 (to wasabi-east...) 
+	ok                                
+
+Once the content reaches the other wasabi remote too, it can drop the local copy:
+
+	joey@darkstar:~/tmp/bench/foo>git-annex sync --content wasabi-west --all
+	commit 
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	copy SHA256E-s30--906a7a36a37e2ffcee8164da8d7275a7fc1d775b3a9c040771725c9f1e4a9222 (to wasabi-west...) 
+	ok                                
+	drop SHA256E-s30--906a7a36a37e2ffcee8164da8d7275a7fc1d775b3a9c040771725c9f1e4a9222 ok
+
+But you also have two repositories that you work in. That complicates things
+a bit. Let's bring repository bar into the picture:
+
+	joey@darkstar:~/tmp/bench/bar>git-annex wanted here 'include=*'
+	wanted here ok
+
+Now, when there's a file that is on foo and bar and wasabi-east,
+syncing with wasabi-west will copy it to there. But what if the file
+gets deleted, and we sync with wasabi-east before syncing with wasabi-west?
+
+	joey@darkstar:~/tmp/bench/bar>git-annex get myfile
+	get myfile (from wasabi-east...) 
+	ok                                
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/bar>git-annex whereis myfile
+	whereis myfile (3 copies) 
+	  	948c3bc7-91ce-4a2e-880d-a5e614c8f0e1 -- [foo]
+	   	db04e144-c10a-4ed2-a557-f3fd6d5410c3 -- bar [here]
+	   	fc4dbe84-ddd5-4bc3-b9c5-f5262df528a3 -- [wasabi-east]
+	joey@darkstar:~/tmp/bench/bar>git rm myfile 
+	rm 'myfile'
+	joey@darkstar:~/tmp/bench/bar>git commit -m removed
+	[master e8cb8fe] removed
+	joey@darkstar:~/tmp/bench/bar>git-annex sync --content wasabi-east --all
+	commit 
+	On branch master
+	Your branch is ahead of 'origin/master' by 1 commit.
+	  (use "git push" to publish your local commits)
+	
+	nothing to commit, working tree clean
+	ok
+	drop SHA256E-s30--a8ae034d9371c80258e9d2e0fd436c6974a839dd42c220792f4cac8f597de3d1 ok
+
+It dropped it because there are enough copies that it could. Now a sync with
+wasabi-west from bar won't send the content to it, since bar no longer has it.
+Since foo still has a copy, syncing with wasabi-west on foo will move it to
+there still. But this is perhaps suboptimal.
+
+A better configuration, that avoids that problem, but is more complicated 
+follows:
+
+	git-annex group wasabi-east collector
+	git-annex group wasabi-west collector
+	git-annex wanted foo 'include=* or not inallgroup=collector'
+	git-annex wanted bar 'include=* or not inallgroup=collector'
+
+This forces the work repositories to hang onto unused keys until
+they reach all the collector repositories.
+"""]]
diff --git a/doc/forum/Ensure_all_versions_are_on_remotes/comment_5_2202121e5311b56b1d73f9bb1503c5e3._comment b/doc/forum/Ensure_all_versions_are_on_remotes/comment_5_2202121e5311b56b1d73f9bb1503c5e3._comment
new file mode 100644
index 0000000000..6511f657a8
--- /dev/null
+++ b/doc/forum/Ensure_all_versions_are_on_remotes/comment_5_2202121e5311b56b1d73f9bb1503c5e3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 5"
+ date="2022-09-28T08:40:11Z"
+ content="""
+Thanks for looking into this, and explaining. Your final configuration makes sense to me... I can't say I fully understand why, but I need `-a` otherwise the local repo will get all versions, leaving me with a bunch of unused keys. So my command is `git annex sync -a -A wasabi-east wasabi-west`. I took the other machine out of the sync because sometimes it's offline and I don't want to wait around for an SSH timeout.
+
+I have tested that if I force drop a key from `wasabi-east`, that sync command will get the key from `wasabi-west`, and then copy it to `wasabi-east`. It doesn't automatically drop it locally, I have to do `git annex drop --unused` - but that's not a big deal.
+
+I would just like to be confident that the wasabi remotes are a lockbox for any keys added to my annex. So... I think it works? :)  I'll keep using it and report back if I run into any weirdness.
+"""]]
diff --git a/doc/forum/Equivalent_to_git_bundle__63__.mdwn b/doc/forum/Equivalent_to_git_bundle__63__.mdwn
new file mode 100644
index 0000000000..d16b91cad9
--- /dev/null
+++ b/doc/forum/Equivalent_to_git_bundle__63__.mdwn
@@ -0,0 +1,10 @@
+Hi,
+
+git provides a neat way to create archives of git repos (or parts thereof): git bundle.
+
+git bundle obviously works with git annex as well, BUT those bundles don't include the actual content (in other words, only the symlinks are bundled up).
+
+Is there a way to get the git bundle functionality with git annex?
+
+THX & Cheers,
+Toby.
diff --git a/doc/forum/Equivalent_to_git_bundle__63__/comment_1_e42936a9bc36fbee69f48e32df303dee._comment b/doc/forum/Equivalent_to_git_bundle__63__/comment_1_e42936a9bc36fbee69f48e32df303dee._comment
new file mode 100644
index 0000000000..af3cf569bf
--- /dev/null
+++ b/doc/forum/Equivalent_to_git_bundle__63__/comment_1_e42936a9bc36fbee69f48e32df303dee._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Bram"
+ ip="81.20.68.186"
+ subject="tar"
+ date="2014-10-03T13:44:50Z"
+ content="""
+I would say you're just looking for 'tar cf' or 'tar czf' of the root directory of your repository.
+Unless the (delta) compression that 'git bundle' would perform is a must-have...
+"""]]
diff --git a/doc/forum/Equivalent_to_git_bundle__63__/comment_2_2b8b5c237d8572fdd27202f3502bea96._comment b/doc/forum/Equivalent_to_git_bundle__63__/comment_2_2b8b5c237d8572fdd27202f3502bea96._comment
new file mode 100644
index 0000000000..167353df3e
--- /dev/null
+++ b/doc/forum/Equivalent_to_git_bundle__63__/comment_2_2b8b5c237d8572fdd27202f3502bea96._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="tdussa"
+ ip="217.84.78.25"
+ subject="tar -- not really"
+ date="2014-10-03T20:40:45Z"
+ content="""
+Hi,
+
+THX for your suggestion.  Unfortunately, git bundle is able to carve out particular slices of a repo, which a simple tar obviously cannot do.  This functionality is much desired.
+
+Cheers,
+Toby.
+"""]]
diff --git a/doc/forum/Error__58___failed_to_push_some_refs.mdwn b/doc/forum/Error__58___failed_to_push_some_refs.mdwn
new file mode 100644
index 0000000000..45d36f51ca
--- /dev/null
+++ b/doc/forum/Error__58___failed_to_push_some_refs.mdwn
@@ -0,0 +1,25 @@
+Hello all, my situation is I have two laptops, one for work and one for home use.  I have a lot of simple text files that I use in v6 unlocked mode (used to use direct mode, but recently switched).  I run the assistant to sync between these hosts using an intermediate server which is an always-on VPS (visarend.solasistim.net in this example).
+
+At some point, these files will start to be desynced, and I'll see messages like these in the log files.
+
+    [2018-09-03 11:34:04.062717904] NetWatcherFallback: Syncing with origin 
+
+    error: Your local changes to the following files would be overwritten by merge:
+            howto/c++.md
+            howto/emacs.mkd
+            howto/git-annex.mkd
+            howto/windows.mkd
+            org/kanban.org
+    Please commit your changes or stash them before you merge.
+    Aborting
+    To visarend.solasistim.net:annex
+     ! [rejected]            master -> synced/master (non-fast-forward)
+    error: failed to push some refs to 'visarend.solasistim.net:annex'
+    hint: Updates were rejected because a pushed branch tip is behind its remote
+    hint: counterpart. Check out this branch and integrate the remote changes
+    hint: (e.g. 'git pull ...') before pushing again.
+    hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+
+Using git-annex 6.20170101.1 on all hosts.
+
+What exactly does this error mean?  How can I get rid of it?  I solve it by rm'ing the repository and re-cloning from visarend.solasistim.net, and integrating any changes manually, but I'm wondering why it's happening.
diff --git a/doc/forum/Error_adding_ssh_remote_in_assistant.mdwn b/doc/forum/Error_adding_ssh_remote_in_assistant.mdwn
new file mode 100644
index 0000000000..6d1660f6df
--- /dev/null
+++ b/doc/forum/Error_adding_ssh_remote_in_assistant.mdwn
@@ -0,0 +1,17 @@
+I'm trying to add a ssh remote in the web app, but I receive the following error:
+
+    Internal Server Error
+
+    ssh-keygen ["-F","router.eisenacher81.org"] exited 1
+
+The console complains about the known_hosts file:
+
+   /home/michael/.ssh/known_hosts is not a valid known_hosts file.
+   line 44 missing key:  AAAAB3NzaC1yc2EAAAABIwAAAIEAtnX75Qa8YVR...
+   key_read: uudecode AAAAB3NzaC1|1|veTakKhYY3OSqCepiq7WAUK8cxQ=|suoi0YU/lgg781Vz9O7yTao5exY= ssh-rsa                            AAAAB3NzaC1yc2EAAAABIwAAAIEA4bTnEFFiKz4+i3S9DWHJVoV8CD1DsVRJRodWdTA86+x58S0l0rUyJgXbGwScMI+xFCrqzpd4Hgoc4ElRykj5SL+7IuB5ZAe+4ILQPeiL9ck/1Q7uoh7vWiURXr92Hz5tjuEe3QI9H   iKauXj5yj5mGq1VVXLN1CdfQ99G4zSxK7c= failed
+   line 73 invalid key: |1|k9vzo7Ftuxf235It5LbrX36p2f0=|rNHdygip...
+   line 93: invalid hashed name: |1||1|aptgcuUg4ITWhZQLxzRHH8gUIOQ=|Qe2JAlAw++SZosE9ZhQW+fA3twE=...   
+   line 120 missing key:  AAAAB3NzaC1yc2EAAAABIwAAAQEAsHa75NfjyB1...
+   /home/michael/.ssh/known_hosts is not a valid known_hosts file.
+
+[[!tag forumbug]] [[bugs/done]]
diff --git a/doc/forum/Error_adding_ssh_remote_in_assistant/comment_1_eecc0660db4083cc91c5330587f74610._comment b/doc/forum/Error_adding_ssh_remote_in_assistant/comment_1_eecc0660db4083cc91c5330587f74610._comment
new file mode 100644
index 0000000000..c5ca912317
--- /dev/null
+++ b/doc/forum/Error_adding_ssh_remote_in_assistant/comment_1_eecc0660db4083cc91c5330587f74610._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.141"
+ subject="comment 1"
+ date="2012-09-22T12:40:55Z"
+ content="""
+Looks like you have a corrupt known_hosts file, but I'm pretty sure git-annex did not do it, as it only lets ssh update that as normal. If you delete the problem lines it'll probably work, though you might want to save a copy to investigate what happened.
+"""]]
diff --git a/doc/forum/Error_adding_ssh_remote_in_assistant/comment_2_3e6aad22e8020b12ff7ef914b75281d1._comment b/doc/forum/Error_adding_ssh_remote_in_assistant/comment_2_3e6aad22e8020b12ff7ef914b75281d1._comment
new file mode 100644
index 0000000000..85acfcc1e9
--- /dev/null
+++ b/doc/forum/Error_adding_ssh_remote_in_assistant/comment_2_3e6aad22e8020b12ff7ef914b75281d1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.141"
+ subject="comment 2"
+ date="2012-09-27T15:29:56Z"
+ content="""
+I've made the assistant ignore ssh-keygen -F failing.
+"""]]
diff --git a/doc/forum/Error_adding_ssh_remote_in_assistant/comment_3_3ea529e16502071fc0980c6d5c60a036._comment b/doc/forum/Error_adding_ssh_remote_in_assistant/comment_3_3ea529e16502071fc0980c6d5c60a036._comment
new file mode 100644
index 0000000000..799050de06
--- /dev/null
+++ b/doc/forum/Error_adding_ssh_remote_in_assistant/comment_3_3ea529e16502071fc0980c6d5c60a036._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmU_2tE75oyG0h2ZPN4lcroIKEMC8G-otE"
+ nickname="Michael"
+ subject="comment 3"
+ date="2012-09-27T15:42:19Z"
+ content="""
+Okay, cleaning up the file worked for me, but I suspect that these invalid entries were created by a valid program. So ignoring errors in the file is \"good enough\". 
+"""]]
diff --git a/doc/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote.mdwn b/doc/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote.mdwn
new file mode 100644
index 0000000000..e38e57c159
--- /dev/null
+++ b/doc/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote.mdwn
@@ -0,0 +1,28 @@
+I just created a gcrypt special remote and got an error from (I think) `git-annex-shell`, though my local git-annex didn't complain and seemed to think the creation went okay.
+
+    annex $ ga initremote ma type=gcrypt encryption=hybrid gitrepo=ssh://ma/meta/s/spw/local/annex keyid=3B6D411B                                                  
+    (merging synced/git-annex into git-annex...)
+    (Recording state in git...)
+    initremote ma (encryption setup) (hybrid cipher with gpg key 0F56D0553B6D411B) gcrypt: Development version -- Repository format MAY CHANGE
+    gcrypt: Repository not found: ssh://ma/meta/s/spw/local/annex
+    gcrypt: Development version -- Repository format MAY CHANGE
+    gcrypt: Repository not found: ssh://ma/meta/s/spw/local/annex
+    gcrypt: Setting up new repository
+    gcrypt: Remote ID is :id:icUy+qU392R5L5H7g8Yk
+    Counting objects: 111456, done.
+    Compressing objects: 100% (74045/74045), done.
+    Total 111456 (delta 59312), reused 85857 (delta 33717)
+    gcrypt: Encrypting to:  -r 0F56D0553B6D411B
+    gcrypt: Requesting manifest signature
+    To gcrypt::ssh://ma/meta/s/spw/local/annex
+     * [new branch]      git-annex -> git-annex
+    fatal: What do you think I am? A shell?
+    git-annex-shell: git-shell failed
+    ok
+    (Recording state in git...)
+
+Further `git annex sync ma` runs go off without a hitch and the master branch gets pushed a synced/master, though it didn't get pushed on this initial creation as can be seen from the above output.
+
+Is it a bug that my local git-annex said "ok" when there was an error, or is this just a case of my local git-annex falling back to rsync instead of git-annex-shell because I didn't set up my $PATH properly on the remote?  Should I be worried that my gcrypt repo wasn't set up correctly and thus can't be trusted to hold my annexed data and metadata?  Thanks.
+
+Local git-annex: 5.20141125.  Remote git-annex (standalone build): 5.20150113-gcf247cf.
diff --git a/doc/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote/comment_1_2a69ce8607f97aabdf3cc402c1091d7a._comment b/doc/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote/comment_1_2a69ce8607f97aabdf3cc402c1091d7a._comment
new file mode 100644
index 0000000000..f94690b35a
--- /dev/null
+++ b/doc/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote/comment_1_2a69ce8607f97aabdf3cc402c1091d7a._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-04T18:09:49Z"
+ content="""
+It seems that some versions of git-shell will give this unhelpful
+error message. Newer versions instead say 
+"fatal: Interactive git shell is not enabled."
+
+The initial push of the git-annex branch is not what failed.
+It seems that the attempt to run "git-annex-shell gcryptsetup"
+was what failed.
+
+My guess is that the remote server has an older version of git-annex
+installed in /usr/bin, which doesn't understand the gcryptsetup
+command, and that your newer installation of the standalone
+version is not getting run when it sshes in. (A common problem; `~/.bashrc`
+and `~/.bash_profile` are both ignored.) The old version of
+git-annex-shell then passed the "gcryptsetup" command on to git-shell,
+which I guess rejected it like that. (Not sure why.)
+
+git-annex seems to have successfully fallen back to using rsync to
+configure the ssh://ma/meta/s/spw/local/annex repository's core.gcrypt-id.
+(You might want to check that was set correctly.)
+
+Also, since it detected an old/not-working git-annex-shell on the remote,
+it will have set git.remote.ma.gcrypt to "true", rather than
+"shell", and this will cause git-annex to bypass using git-annex-shell
+and instead use direct rsync. 
+"""]]
diff --git a/doc/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote/comment_2_a112f0bc1a30fa41504e3f52f679053b._comment b/doc/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote/comment_2_a112f0bc1a30fa41504e3f52f679053b._comment
new file mode 100644
index 0000000000..7679ef0cd4
--- /dev/null
+++ b/doc/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote/comment_2_a112f0bc1a30fa41504e3f52f679053b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 2"
+ date="2015-02-04T21:33:41Z"
+ content="""
+The `core.gcrypt-id` on the remote and local is correctly set (to the same thing) and `git.remote.ma.annex-gcrypt` (I assume you meant this and not `git.remote.ma.gcrypt`) on my local machine is indeed set to `true`.  And the remote seems to work for all purposes I've tried to use it for.  So I guess I'm okay.
+
+There is an older version in `/usr/bin` as you suggest: 3.20120523.  I don't know why I didn't notice this myself before I installed the standalone build.
+
+Thank you for taking the time to reply.
+"""]]
diff --git a/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__.mdwn b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__.mdwn
new file mode 100644
index 0000000000..9ab79ded61
--- /dev/null
+++ b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__.mdwn
@@ -0,0 +1,3 @@
+I have some v5 indirect annexes with important data, one of which has hundreds of thousands of files, and I'm concerned about whether upgrading to v7 will result in data loss.
+
+What exactly does the upgrade to v7 do? What is the likelihood of errors or losing data in any way? Will upgrading my biggest annex take a long time?
diff --git a/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_3_04a920f5b86a203d050ee4a9a0f8a33d._comment b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_3_04a920f5b86a203d050ee4a9a0f8a33d._comment
new file mode 100644
index 0000000000..91fac140c7
--- /dev/null
+++ b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_3_04a920f5b86a203d050ee4a9a0f8a33d._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""answering the question"""
+ date="2019-10-22T03:28:47Z"
+ content="""
+In detail, this is exactly what is entailed by the upgrade process
+of a repository that is not in direct mode:
+
+* git is configured to run git-annex as a smudge/clean filter by
+  adding a `[filter "annex"]` section to .git/config and installing a 
+  .git/info/attributes file to contain "filter=annex"
+  (or modifying it if the repo already has one).
+* git-annex scans the repository for files that are currently unlocked,
+  and updates bookkeeping about them (including the git index), 
+  since unlocked files are treated differently in v7. git will treat
+  those unlocked files as unstaged changes in the working tree,
+  that can be committed, if you choose to, since that's how unlocked
+  files work in v7.
+* Two git hooks are installed (post-checkout and post-merge)
+  to run `git annex smudge --update`. (If you happened to
+  already have installed something in those hooks, it will not modify them
+  and will display a warning instead.)
+* annex.version is set to 7
+
+Notice that this process does not touch the work tree at all, or the annex
+objects, so even if it somehow completely exploded, you cannot possibly
+lose data. It is entirely reversable by undoing the git config changes I
+listed.
+
+And it does not break interoperation with other clones of the repository
+that still use v5. So if you have qualms, my advice would be to make a
+clone and try it out for yourself and see. You can prevent accidential
+upgrade of any repos by
+`git config --global annex.autoupgraderepository false`
+"""]]
diff --git a/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_4_b43fda0acca8cc9027f36f51b9489aa3._comment b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_4_b43fda0acca8cc9027f36f51b9489aa3._comment
new file mode 100644
index 0000000000..0fefeea28e
--- /dev/null
+++ b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_4_b43fda0acca8cc9027f36f51b9489aa3._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""(and direct mode)"""
+ date="2019-10-22T04:02:12Z"
+ content="""
+Just for completeness, here's what upgrading a direct mode repository to v7
+entails:
+
+* everything listed above
+* annex.thin is set to true
+* .git/annex/objects gets populated, since direct mode didn't populate
+  it and in v7 annexed objects always get stored there.
+  This involves hard linking annexed files in the work tree
+  into the objects directory. If the filesystem doesn't support
+  hard links, it unfortunately has to copy the files, which will
+  double the disk space used by the repository.
+  (There's a todo item discussing maybe clawing that space back,
+  but it seems to need changes to git to do.)
+* An adjusted unlocked branch is created from the current branch,
+  and checked out.
+  Essentially the same as running `git annex adjust --unlock`
+"""]]
diff --git a/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_5_380240e562358efb25a8acb65b5d4cc7._comment b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_5_380240e562358efb25a8acb65b5d4cc7._comment
new file mode 100644
index 0000000000..d338e184bc
--- /dev/null
+++ b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_5_380240e562358efb25a8acb65b5d4cc7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ghen1"
+ avatar="http://cdn.libravatar.org/avatar/efd0e92b6198291138f0cd7aedbf86b6"
+ subject="comment 5"
+ date="2019-10-30T22:51:27Z"
+ content="""
+I just wanted to report that I've successfully upgraded my repos without any problems. I appreciate everyone's help.
+"""]]
diff --git a/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_5_752b1c3e2394ef432c1e21a5639648be._comment b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_5_752b1c3e2394ef432c1e21a5639648be._comment
new file mode 100644
index 0000000000..1260bf1271
--- /dev/null
+++ b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_5_752b1c3e2394ef432c1e21a5639648be._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""oh, you also asked if it will take a long time.."""
+ date="2019-10-22T04:16:13Z"
+ content="""
+The only potentially expensive part is the scan for unlocked files.
+That involves running `git ls-tree -r HEAD`, so will scale with the
+number of files in the repository. But it would need to be a huge
+repository indeed for it to take a long time.
+"""]]
diff --git a/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_6_e5d4ba2bb9f78380dfa94446cb1f4b54._comment b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_6_e5d4ba2bb9f78380dfa94446cb1f4b54._comment
new file mode 100644
index 0000000000..ef262a9451
--- /dev/null
+++ b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_6_e5d4ba2bb9f78380dfa94446cb1f4b54._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="bremner"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="plz don't annex already committed files"
+ date="2019-10-31T13:50:09Z"
+ content="""
+I am suffering a bit at the moment from git-annex 7 annexing committed files and replacing them with pseudo symlinks. This breaks the file for v5 clients. What's the best way to disable this? I have annex.largefiles=100k, but a few files just a bit larger than that are commited to git.
+"""]]
diff --git a/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_7_cec779ef77336ea30728815739be78b6._comment b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_7_cec779ef77336ea30728815739be78b6._comment
new file mode 100644
index 0000000000..1e57c27644
--- /dev/null
+++ b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_7_cec779ef77336ea30728815739be78b6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="locking files before reverting to v5"
+ date="2019-10-22T18:25:11Z"
+ content="""
+\"It is entirely reversable by undoing the git config changes\" -- just to note, before undoing the git config changes, you'd want to [[lock|git-annex-lock]] any unlocked files (after first committing any pending changes to them).
+"""]]
diff --git a/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_7_e349403ef92a96a08195a7dd1dbf9561._comment b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_7_e349403ef92a96a08195a7dd1dbf9561._comment
new file mode 100644
index 0000000000..8153837871
--- /dev/null
+++ b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_7_e349403ef92a96a08195a7dd1dbf9561._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="not annexing files already stored in git"
+ date="2019-10-31T16:03:41Z"
+ content="""
+\"a few files just a bit larger than that are commited to git\" -- if it's just a few, maybe set `annex.largefiles=nothing` explicitly for each of them in .gitattributes?  (Also then set `annex.largefiles=(largerthan=100kb)` in .gitattributes rather than in git config, since that overrides .gitattributes).  But in general it would be better if files already in git were not annexed even if they match `annex.largefiles`.
+"""]]
diff --git a/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_8_bca507381436a8282645a931aa39fb20._comment b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_8_bca507381436a8282645a931aa39fb20._comment
new file mode 100644
index 0000000000..c1feb76f8f
--- /dev/null
+++ b/doc/forum/Exactly_what_does_a_v5_to_v7_upgrade_entail__63__/comment_8_bca507381436a8282645a931aa39fb20._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="annexing previously non-annexed files, and compatibility with v5"
+ date="2019-10-31T16:19:39Z"
+ content="""
+\"it would be better if files already in git were not annexed even if they match annex.largefiles\" -- actually not sure: what if a file was in git but gets modified to something _much_ larger?  If you have \"a few files just a bit larger\" than your `annex.largefiles` setting, maybe just increase that setting?  You could also set `annex.gitaddtoannex=false` to prevent `git add` from annexing previously non-annexed files, and use `git annex add` to annex new files.
+
+Also, if goal is compatibility with v5, you can lock files after annexing.  If [[todo/auto-lock_files_after_one_edit]] gets implemented at some point, that could also help this case.
+"""]]
diff --git a/doc/forum/Exclude_specific_files_from_a_special_remote.mdwn b/doc/forum/Exclude_specific_files_from_a_special_remote.mdwn
new file mode 100644
index 0000000000..898ebfdded
--- /dev/null
+++ b/doc/forum/Exclude_specific_files_from_a_special_remote.mdwn
@@ -0,0 +1,3 @@
+I have a special remote configured to/from which I can copy files correctly.
+I would like to be prevent some annexed files to be copied to this remote, automatically (in other words, without excluding them manually on the command line)
+How can this be done?
diff --git a/doc/forum/Exclude_specific_files_from_a_special_remote/comment_1_d5a9f3308e09a9b9460014904d23ef48._comment b/doc/forum/Exclude_specific_files_from_a_special_remote/comment_1_d5a9f3308e09a9b9460014904d23ef48._comment
new file mode 100644
index 0000000000..0375b9239f
--- /dev/null
+++ b/doc/forum/Exclude_specific_files_from_a_special_remote/comment_1_d5a9f3308e09a9b9460014904d23ef48._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-20T16:32:29Z"
+ content="""
+This is a job for [[preferred_content]]!
+
+For example, you could configure the remote to not want
+any flac files, so only mp3, ogg, etc files should be stored on that
+remote:
+
+	git annex wanted myremotename 'exclude=*.flac'
+
+This configuration will automatically be honored if you use
+`git annex sync --content` (or the assistant). If you manually
+use `git annex copy` to copy files to the remote, you'll need to
+add the `--auto` flag to make it honor the preferred content settings.
+"""]]
diff --git a/doc/forum/Exclude_specific_files_from_a_special_remote/comment_2_671790686bd4724aadcadd8d8aad2c98._comment b/doc/forum/Exclude_specific_files_from_a_special_remote/comment_2_671790686bd4724aadcadd8d8aad2c98._comment
new file mode 100644
index 0000000000..8ad63b91b9
--- /dev/null
+++ b/doc/forum/Exclude_specific_files_from_a_special_remote/comment_2_671790686bd4724aadcadd8d8aad2c98._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Oliv5@43a03b767570a41ba84b9e5c72f3c9816adb22e2"
+ nickname="Oliv5"
+ subject="comment 2"
+ date="2015-07-23T19:07:58Z"
+ content="""
+Yes, this is exactly what I need. It works well indeed. Thks. I didnt understand how this worked before.
+"""]]
diff --git a/doc/forum/Export_files_that_aren__39__t_locally_present__63__.mdwn b/doc/forum/Export_files_that_aren__39__t_locally_present__63__.mdwn
new file mode 100644
index 0000000000..86af3ca436
--- /dev/null
+++ b/doc/forum/Export_files_that_aren__39__t_locally_present__63__.mdwn
@@ -0,0 +1,7 @@
+I use git-annex to manage my Sansa Clip Zip running Rockbox as a directory special remote since it has a FAT filesystem and I don't want to waste half the storage. I'd like to avoid having a copy of all my music and podcasts on my laptop as well, but git-annex only seems to be able to export files that are locally present. Would it be possible to have git-annex try to copy non-present files directly from remotes where it believes the files are present, starting with the lowest cost remote? 
+
+It would also be cool to be able to convert subdirectory information on the remote into metadata in the repository. For example, I delete podcasts after listening to them, so when git-annex detects that it could either move it into the archive dir or add a "listened" tag in the repo.
+
+Soeaking of metadata, even though special remotes don't support it, I think it would be reasonable to treat files that have never been imported as having no metadata or some configurable default metadata per directory (like tag=listened or status=new) and use the metadata in the repo for files that have been imported previously when evaluating the wanted expression.
+
+Thoughts?
diff --git a/doc/forum/Export_files_that_aren__39__t_locally_present__63__/comment_1_278b70c7bd7397e634df4a257fb604f9._comment b/doc/forum/Export_files_that_aren__39__t_locally_present__63__/comment_1_278b70c7bd7397e634df4a257fb604f9._comment
new file mode 100644
index 0000000000..8898895f10
--- /dev/null
+++ b/doc/forum/Export_files_that_aren__39__t_locally_present__63__/comment_1_278b70c7bd7397e634df4a257fb604f9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2020-01-26T18:43:55Z"
+ content="""
+It's best to post enhancement suggestions under [[todo]].  In this case there's already a similar item at [[todo/git-annex-export_--from_option]], so let's move this thread there.
+"""]]
diff --git a/doc/forum/Exporting_files_to_special_remote__44___even_if_not_in_preferred_contents.mdwn b/doc/forum/Exporting_files_to_special_remote__44___even_if_not_in_preferred_contents.mdwn
new file mode 100644
index 0000000000..62988f2c5c
--- /dev/null
+++ b/doc/forum/Exporting_files_to_special_remote__44___even_if_not_in_preferred_contents.mdwn
@@ -0,0 +1,3 @@
+I use my ereader as a special remote since its file system does not support symbolic links. My preferred contents expression for this remote includes everything in my library of books which is under 6 mb. However, I do occasionally want to export specific books above this size limit. Is there a good way of doing this besides explicitly adding the file to the preferred content expression?
+
+Many thanks
diff --git a/doc/forum/Exporting_files_to_special_remote__44___even_if_not_in_preferred_contents/comment_1_8276c225867733e7a79ba47be2447b1e._comment b/doc/forum/Exporting_files_to_special_remote__44___even_if_not_in_preferred_contents/comment_1_8276c225867733e7a79ba47be2447b1e._comment
new file mode 100644
index 0000000000..e0d473d5bc
--- /dev/null
+++ b/doc/forum/Exporting_files_to_special_remote__44___even_if_not_in_preferred_contents/comment_1_8276c225867733e7a79ba47be2447b1e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2020-07-18T03:58:18Z"
+ content="""
+You could use a [[metadata|git-annex-metadata]] field to mark the content you want, then use a metadata-based preferred content expression.
+"""]]
diff --git a/doc/forum/Exporting_files_to_special_remote__44___even_if_not_in_preferred_contents/comment_2_dc1e718d0043686987abc9526a459dc3._comment b/doc/forum/Exporting_files_to_special_remote__44___even_if_not_in_preferred_contents/comment_2_dc1e718d0043686987abc9526a459dc3._comment
new file mode 100644
index 0000000000..17ac43d131
--- /dev/null
+++ b/doc/forum/Exporting_files_to_special_remote__44___even_if_not_in_preferred_contents/comment_2_dc1e718d0043686987abc9526a459dc3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="erewhon"
+ avatar="http://cdn.libravatar.org/avatar/b9bd5ad7176ebe149d0f051dcfe0a63e"
+ subject="comment 2"
+ date="2020-07-24T16:05:06Z"
+ content="""
+Thanks Ilya,
+
+This seems like a very nice solution. I had not known about metadata tags. I look forward to finding other uses for them as well.
+"""]]
diff --git a/doc/forum/External_drive_syncs_git-annex_branch_but_not_master_branch.mdwn b/doc/forum/External_drive_syncs_git-annex_branch_but_not_master_branch.mdwn
new file mode 100644
index 0000000000..76294b6a61
--- /dev/null
+++ b/doc/forum/External_drive_syncs_git-annex_branch_but_not_master_branch.mdwn
@@ -0,0 +1 @@
+I have an external HDD which I setup as a remote manually before I started using the assistant.  When I plug it in files sync fine and the git-annex branch gets synced, but the master branch doesn't; git annex sync doesn't do the job and I have to run git pull.  This is annoying because it means that portable drive is useless as a backup, since it doesn't have the required metadata; I have to manually git pull to make it a useful backup.  How can I make the assistant sync the metadata in--if not the master branch, at least origin/master so I could merge later without the remote available.  Thanks.
diff --git a/doc/forum/External_drive_syncs_git-annex_branch_but_not_master_branch/comment_1_9a909e3d89061adacbd8ed370520250c._comment b/doc/forum/External_drive_syncs_git-annex_branch_but_not_master_branch/comment_1_9a909e3d89061adacbd8ed370520250c._comment
new file mode 100644
index 0000000000..43fe578e17
--- /dev/null
+++ b/doc/forum/External_drive_syncs_git-annex_branch_but_not_master_branch/comment_1_9a909e3d89061adacbd8ed370520250c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 1"
+ date="2012-12-08T21:25:49Z"
+ content="""
+apologies if I misunderstand your question, but I believe that git-annex puts the metadata in the repository's sync/master branch, which you can merge into the repository's local master either manually or by running \"git annex sync\" in the repository.
+
+"""]]
diff --git a/doc/forum/External_drive_syncs_git-annex_branch_but_not_master_branch/comment_2_0dd489b264374b7b1065b89e1ff7561b._comment b/doc/forum/External_drive_syncs_git-annex_branch_but_not_master_branch/comment_2_0dd489b264374b7b1065b89e1ff7561b._comment
new file mode 100644
index 0000000000..d26707c224
--- /dev/null
+++ b/doc/forum/External_drive_syncs_git-annex_branch_but_not_master_branch/comment_2_0dd489b264374b7b1065b89e1ff7561b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="163.1.166.255"
+ subject="comment 2"
+ date="2012-12-08T21:57:37Z"
+ content="""
+It does, which is what one would have expected I guess, but I didn't look.  Thanks so much.
+"""]]
diff --git a/doc/forum/Extra___38___missing_folders_on_remote.mdwn b/doc/forum/Extra___38___missing_folders_on_remote.mdwn
new file mode 100644
index 0000000000..b78961ccc8
--- /dev/null
+++ b/doc/forum/Extra___38___missing_folders_on_remote.mdwn
@@ -0,0 +1,9 @@
+I created a local annex directory that's an adjusted branch used with the assistant. On another machine, I initialized an annex directory, then made this into a full-backup ssh remote for my local.
+
+After the assistant pushes to the remote, and the remote runs `git annex sync`, the remote is missing some directories and has some extra directories. For example, it has the extra directory `Documents/programs/Documents/programs/`, which has different contents than `Documents/programs/`. Both directories are missing the subdirectory `graphing_experiments/`.
+
+From my local, `git annex whereis Documents/programs/graphing_experiments` says the directory exists on the remote. But it's not there.
+
+I recreated the remote from scratch and the problem persists.
+
+The assistant says the remote is caught up, and is keeping up with new content changes. What could cause this?
diff --git a/doc/forum/Failed_to_push_on_git-lfs.mdwn b/doc/forum/Failed_to_push_on_git-lfs.mdwn
new file mode 100644
index 0000000000..1d4f407abd
--- /dev/null
+++ b/doc/forum/Failed_to_push_on_git-lfs.mdwn
@@ -0,0 +1,23 @@
+Hi,
+
+I've setup a remote on Github with LFS enabled. Running `git-annex sync --content` failed to push on the main branch :
+
+```
+pull lfstest 
+From github.com:myuser/myremote
+ * branch            HEAD       -> FETCH_HEAD
+ok
+push lfstest 
+Everything up-to-date
+To github.com:myuser/myremote.git
+ ! [rejected]        main -> main (non-fast-forward)
+error: failed to push some refs to 'github.com:myuser/myremote.git'
+hint: Updates were rejected because the tip of your current branch is behind
+hint: its remote counterpart. Integrate the remote changes (e.g.
+hint: 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+ok
+```
+Is this an expected behaviour ? Is it possible to correct the push failure ?
+
+Thansk in advance
diff --git a/doc/forum/Failed_to_push_on_git-lfs/comment_1_f83dbcfdd09de3ce908c0d4a9daef458._comment b/doc/forum/Failed_to_push_on_git-lfs/comment_1_f83dbcfdd09de3ce908c0d4a9daef458._comment
new file mode 100644
index 0000000000..f3c9d06728
--- /dev/null
+++ b/doc/forum/Failed_to_push_on_git-lfs/comment_1_f83dbcfdd09de3ce908c0d4a9daef458._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-10-17T16:28:48Z"
+ content="""
+This doesn't involve LFS at all, it's a regular git branch being pushed in
+the regular way. So you can certianly solve the problem with some
+combination of `git pull`, `git merge`, and `git push`.
+
+That said, I don't know why `git-annex sync` didn't work in your situation.
+I created some test git-lfs repos on github and never saw any difficulty
+syncing with them.
+"""]]
diff --git a/doc/forum/Failed_to_push_on_git-lfs/comment_2_52051b251bea7a5ed452769d0320602a._comment b/doc/forum/Failed_to_push_on_git-lfs/comment_2_52051b251bea7a5ed452769d0320602a._comment
new file mode 100644
index 0000000000..61c503889a
--- /dev/null
+++ b/doc/forum/Failed_to_push_on_git-lfs/comment_2_52051b251bea7a5ed452769d0320602a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="AlexPraga"
+ avatar="http://cdn.libravatar.org/avatar/7c4e10fd352b81279b405f9f5337cdb7"
+ subject="comment 2"
+ date="2022-10-22T15:12:26Z"
+ content="""
+Thanks for answering. I managed to correct it with force-pushing it : `git push lfs main -f`.
+Not sure why it did not work before but it seems to be working now.
+"""]]
diff --git a/doc/forum/Failing_to_get_files_from_rclone_special_remote.mdwn b/doc/forum/Failing_to_get_files_from_rclone_special_remote.mdwn
new file mode 100644
index 0000000000..ee0bd72553
--- /dev/null
+++ b/doc/forum/Failing_to_get_files_from_rclone_special_remote.mdwn
@@ -0,0 +1,104 @@
+Hi! Thanks for your time, and please let me know if this is an rclone special remote-specific question that I should be asking elsewhere.
+
+I very likely may be _fundamentally_ misconfiguring something since I'm a git-annex beginner (although a git veteran)
+
+I'm trying to make a system to sync Ableton projects and their corresponding samples between my band's computers.
+
+So far I have Computer A with a repo and git annex with the local file contents.
+
+From here, I've pushed the repository itself to github and the contents to an rclone special remote hosted on pCloud.
+
+```
+% git annex list
+here
+|github
+||web
+|||bittorrent
+||||pcloud_test_annex
+|||||
+X___X Samples/Recorded/1-Audio 0001 [2021-12-08 093649].aif
+X___X Samples/Recorded/1-Audio 0004 [2021-12-08 092222].aif
+X___X Samples/Recorded/1-Audio 0005 [2021-12-08 092402].aif
+...
+
+
+% git remote -v
+github	git@github.com:branch-pcloud.git (fetch)
+github	git@github.com:branch-pcloud.git (push)
+pcloud_test_annex
+```
+
+On computer B, I tried to clone the github repo and pull the pCloud data down, but I can't manage to get it to work.
+
+```
+$ git annex get 'Samples/Recorded/1-Audio 0001 [2021-12-08 093649].aif'
+get Samples/Recorded/1-Audio 0001 [2021-12-08 093649].aif (not available)
+  Maybe enable some of these special remotes (git annex initremote ...):
+        e7e3e2b7-40e7-4b10-83f6-bb5425f33d6d -- pcloud_test_annex
+  Maybe add some of these git remotes (git remote add ...):
+        bab5704a-562e-43eb-8bbb-71f181f043e8 -- bl@compy_A:~/test_project
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+get: 1 failed
+```
+
+Okay, well github (origin) won't have it, so I'll try to enable the special remote:
+
+```
+$ git annex enableremote pcloud_test_annex
+enableremote pcloud_test_annex ok
+(recording state in git...)
+```
+
+But it doesn't help. I get the same error afterwards.
+
+Here's something that's probably bad: on computer B, there's a whole lot of git annex remotes:
+
+```
+$ git annex info
+trusted repositories: 0
+semitrusted repositories: 8
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        2e771318-83eb-4beb-85f4-567896b0e835 -- [pcloud_test_annex]
+        32c6a55a-3879-4a67-beb9-d7e4d1624cc4 -- bl@compy_B:~/Music\mine\test_project [here]
+        69acaaf2-e58b-463d-a578-e2418df5c6b0 -- pcloud_test_annex
+        bab5704a-562e-43eb-8bbb-71f181f043e8 -- bl@compy_A:~/test_project
+        e7e3e2b7-40e7-4b10-83f6-bb5425f33d6d -- pcloud_test_annex
+        ebca6ee8-1baa-4a47-ae85-0a5b65db73f6 -- pcloud_test_annex
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 152.39 gigabytes (+1 megabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 18
+size of annexed files in working tree: 688.91 megabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage:
+        SHA256E: 18
+```
+
+After some investigation, one of these is actually the right one (I think)!
+
+```
+$ git annex info e7e3e2b7-40e7-4b10-83f6-bb5425f33d6d
+uuid: e7e3e2b7-40e7-4b10-83f6-bb5425f33d6d
+description: pcloud_test_annex
+trust: semitrusted
+remote annex keys: 18
+remote annex size: 688.91 megabytes
+```
+
+But I can't figure out how to configure computer B's repository to access it:
+
+```
+$ git annex info e7e3e2b7-40e7-4b10-83f6-bb5425f33d6d
+uuid: e7e3e2b7-40e7-4b10-83f6-bb5425f33d6d
+description: pcloud_test_annex
+trust: semitrusted
+remote annex keys: 18
+remote annex size: 688.91 megabytes
+```
+
+How can I get other computers to pull the contents from pCloud (rclone)?
diff --git a/doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_1_4a762c369e4049bdedecca4a32242f18._comment b/doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_1_4a762c369e4049bdedecca4a32242f18._comment
new file mode 100644
index 0000000000..4febd83e71
--- /dev/null
+++ b/doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_1_4a762c369e4049bdedecca4a32242f18._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-05T16:19:05Z"
+ content="""
+So you have several remotes with the same name, probably all but
+this one you want to use were false starts or created by accident.
+
+In this unusual situation, `git-annex enableremote` picks one more or less at
+random.
+
+(Normally this is prevented by `git-annex initremote`, which won't use a
+name that already exists, but initializing remotes with the same name in
+different clones and merging is one way it could happen.)
+
+What you can do instead is specify the uuid or description of the remote.
+Eg:
+
+	git-annex enableremote e7e3e2b7-40e7-4b10-83f6-bb5425f33d6d
+
+The other thing you can do if you want is to mark all the other
+uuids with this name as dead, and then tell git-annex to forget about dead
+remotes. Doing this will leave only the one that you did not mark as dead,
+so enableremote by name will do what you want.
+
+	git-annex dead ebca6ee8-1baa-4a47-ae85-0a5b65db73f6
+	git-annex dead 69acaaf2-e58b-463d-a578-e2418df5c6b0
+	git-annex dead 2e771318-83eb-4beb-85f4-567896b0e835
+	git-annex forget --drop-dead
+"""]]
diff --git a/doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_2_cfb6be6c940350dbed6cc9e98ee1d633._comment b/doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_2_cfb6be6c940350dbed6cc9e98ee1d633._comment
new file mode 100644
index 0000000000..c7076a7813
--- /dev/null
+++ b/doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_2_cfb6be6c940350dbed6cc9e98ee1d633._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-01-05T17:53:35Z"
+ content="""
+Easier option, with a newish version of git-annex:
+
+	git-annex renameremote e7e3e2b7-40e7-4b10-83f6-bb5425f33d6d pcloud_annex
+	git-annex enableremote pcloud_annex
+"""]]
diff --git a/doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_3_58282be918139a3154938850793a80fb._comment b/doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_3_58282be918139a3154938850793a80fb._comment
new file mode 100644
index 0000000000..f27c19a9fc
--- /dev/null
+++ b/doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_3_58282be918139a3154938850793a80fb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="arekmenner@f0f5403c5cbc803fedaf860e3a6f839a41075e3b"
+ nickname="arekmenner"
+ avatar="http://cdn.libravatar.org/avatar/ec065e4a23146814e887fdcd16a1ee44"
+ subject="response"
+ date="2022-01-05T19:18:09Z"
+ content="""
+This is all completely correct and includes enough explanation and internals that I think I'm unlikely to get into this situation again.
+
+Thanks so much for your time! Now decryption is failing so I'll make another thread
+"""]]
diff --git a/doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_4_1360ee3e3b711990f59e0320e7892cd2._comment b/doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_4_1360ee3e3b711990f59e0320e7892cd2._comment
new file mode 100644
index 0000000000..7edf7a61f0
--- /dev/null
+++ b/doc/forum/Failing_to_get_files_from_rclone_special_remote/comment_4_1360ee3e3b711990f59e0320e7892cd2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-01-05T19:24:50Z"
+ content="""
+Thanks for verifying.
+
+Also FWIW, I'm pushing some changes that improve `git-annex enableremote`
+in this situation, so it does not choose a random remote to enable.
+"""]]
diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__.mdwn b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__.mdwn
new file mode 100644
index 0000000000..e6bfd4a91f
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__.mdwn
@@ -0,0 +1,16 @@
+I have an annex that has an s3 special remote. The s3 remote has been configured with shared encryption and it uses partsize (not chunking). Currently when I try to get a file from the s3 remote, it fails:
+
+    $ git annex get mybigfile.tbz.gpg
+    get mybigfile.tbz.gpg (from s3...)
+    76%         10.6MB/s 57sgpg: WARNING: encrypted message has been manipulated!
+
+      Unable to access these remotes: s3
+
+      Try making some of these repositories available:
+            15ac19e4-223a-4c81-b7f7-797b9b026b86 -- [s3]
+
+      (Note that these git remotes have annex-ignore set: origin)
+    failed
+    git-annex: get: 1 failed
+
+The file is about 3GB. This happens consistently at 76%. No other copy of the file exists. Is there some way I can get the file from s3, either without git annex or just have git annex ignore the error, so that I can inspect the file locally and see if there is anything wrong with it?
diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_1_c769dcbb9d5f082d54b8a091a44c9de4._comment b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_1_c769dcbb9d5f082d54b8a091a44c9de4._comment
new file mode 100644
index 0000000000..51348f462e
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_1_c769dcbb9d5f082d54b8a091a44c9de4._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="annexuser"
+ subject="comment 1"
+ date="2016-04-30T17:30:18Z"
+ content="""
+This also happens with a second file in the same repo, although the download seems to complete on this one before the error. The file is about the same size.
+
+    gxg otherfile.tgz.gpg
+    get otherfile.tgz.gpg (from s3...)
+    100%         10.7MB/s 0sgpg: WARNING: encrypted message has been manipulated!
+
+      Unable to access these remotes: s3
+
+      Try making some of these repositories available:
+            15ac19e4-223a-4c81-b7f7-797b9b026b86 -- [s3]
+
+      (Note that these git remotes have annex-ignore set: origin)
+    failed
+    git-annex: get: 1 failed
+
+"""]]
diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_2_50e35159f7e670ca6b7280121821b494._comment b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_2_50e35159f7e670ca6b7280121821b494._comment
new file mode 100644
index 0000000000..40751e41fa
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_2_50e35159f7e670ca6b7280121821b494._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-03T18:54:41Z"
+ content="""
+What you could try is:
+
+	git config remote.s3.annex-gnupg-options --ignore-mdc-error
+	git config remote.s3.annex-verify false
+
+That should make gpg ignore the error and proceed, and make git-annex
+not try to verify the download either. The resulting file will probably
+be corrupt in some way. It might have a bad chunk in the middle, or be
+truncated, or be garbage past a certian point.
+
+This sounds like something went wrong with the multipart upload to S3.
+What does `git annex info s3` say about the configuration of your S3
+remote? I'd like to reproduce this problem, if possible. Since it hit two
+of your files, it seems to not have been some kind of one-off data
+corruption problem.
+"""]]
diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_3_471ff0cdb00b311f2a3d801b04e9edef._comment b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_3_471ff0cdb00b311f2a3d801b04e9edef._comment
new file mode 100644
index 0000000000..38f6d97f96
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_3_471ff0cdb00b311f2a3d801b04e9edef._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="annexuser"
+ subject="comment 3"
+ date="2016-05-04T19:15:16Z"
+ content="""
+Thanks. I will try that and see if I can recover the files. Here is the output of git annex info s3:
+
+    remote: s3
+    description: [s3]
+    uuid: 15ac19e4-223a-4c81-b7f7-797b9b026b86
+    trust: semitrusted
+    cost: 250.0
+    type: S3
+    creds: stored locally
+    bucket: s3-15ac19e4-223a-4c81-b7f7-797b9b026b86
+    endpoint: s3.amazonaws.com
+    port: 80
+    storage class: OtherStorageClass \"STANDARD_IA\"
+    partsize: 1.07 gigabytes
+    public: no
+    encryption: encrypted (encryption key stored in git repository)
+    chunking: none
+    remote annex keys: 121924
+    remote annex size: 680.42 gigabytes
+
+"""]]
diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_4_e0f80d306a2b4d19d65d268cde25ac31._comment b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_4_e0f80d306a2b4d19d65d268cde25ac31._comment
new file mode 100644
index 0000000000..01df912538
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_4_e0f80d306a2b4d19d65d268cde25ac31._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="annexuser"
+ subject="comment 4"
+ date="2016-05-05T18:11:49Z"
+ content="""
+Those settings don't seem to have an effect. I still get the same `gpg: WARNING: encrypted message has been manipulated!` error when getting the files after I set those options.
+"""]]
diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_4_f648049cc1a82f183bbc7dc84cd170e2._comment b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_4_f648049cc1a82f183bbc7dc84cd170e2._comment
new file mode 100644
index 0000000000..1e781a718c
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_4_f648049cc1a82f183bbc7dc84cd170e2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-05-05T15:55:29Z"
+ content="""
+So you have a lot of data in there. Are all files larger than 1 gb failing
+to download, or only two of them?
+"""]]
diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_6_c2686480c6c77ea7297f739780ea6d3b._comment b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_6_c2686480c6c77ea7297f739780ea6d3b._comment
new file mode 100644
index 0000000000..748ec08e13
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_6_c2686480c6c77ea7297f739780ea6d3b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="annexuser"
+ subject="comment 6"
+ date="2016-05-05T23:57:13Z"
+ content="""
+Yeah, it's a big one :)
+
+Those are the only 2 that are failing. I have a ~50GB file that downloads from s3 without issue. Others in the ~15GB range that download fine also.
+
+There are probably only ~30 files in the repo that are multiple gigabytes. The rest are all small files.
+"""]]
diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_7_6f3d056e449366746aef4f45673515d5._comment b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_7_6f3d056e449366746aef4f45673515d5._comment
new file mode 100644
index 0000000000..1cc923a3a9
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_7_6f3d056e449366746aef4f45673515d5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2016-05-10T16:26:03Z"
+ content="""
+I see now why remote.s3.annex-gnupg-options is not working: That is
+currently only passed to gpg when it's encrypting, not when it's
+decrypting.
+
+So, instead, edit ~/.gnupg/gpg.conf and put "ignore-mdc-error" in
+a line of its own in that file.
+"""]]
diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_8_785e012f478631f4b69fefbd0394f1b8._comment b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_8_785e012f478631f4b69fefbd0394f1b8._comment
new file mode 100644
index 0000000000..d4838d0982
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_8_785e012f478631f4b69fefbd0394f1b8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="annexuser"
+ subject="comment 8"
+ date="2016-05-11T20:32:54Z"
+ content="""
+I set `git config remote.s3.annex-verify false`, and `ignore-mdc-error` in my `gpg.conf`. That allowed me to succesfully download the files. From there I was able to recover the bulk of the files in the archives. Thanks!
+
+Any ideas what caused the files to become corrupted in the first place? Is there anything I can do different when adding new files and copying them to the s3 special remote to prevent corruption?
+"""]]
diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_9_e021705e0fae6645a0b6459757260084._comment b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_9_e021705e0fae6645a0b6459757260084._comment
new file mode 100644
index 0000000000..ece2c012ca
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_9_e021705e0fae6645a0b6459757260084._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2016-05-12T19:04:00Z"
+ content="""
+My best guess at the moment is that the corruption must have something to
+do with using a partsize.
+
+Since you were able to get at the corrupted files, can you characterize at
+all how they were corrupted?
+
+In particular, did the corruption start at some multiple of N GiB?
+into the file? If so, that would correlate with your 1 GiB part size.
+
+Or was it just a small area of corruption?
+
+Or is the corrupt file truncated?
+"""]]
diff --git a/doc/forum/Fast_cloning_a_repo_initially.mdwn b/doc/forum/Fast_cloning_a_repo_initially.mdwn
new file mode 100644
index 0000000000..52a275786c
--- /dev/null
+++ b/doc/forum/Fast_cloning_a_repo_initially.mdwn
@@ -0,0 +1,3 @@
+Is there any fast way to rsync a direct-mode (assistant) git/annex directory from one machine to another?
+
+Scenario: I was already using unison to synchronize 40GB between my desktop and laptop. I've added git annex to my desktop, but is there a way to bootstrap on my laptop without needing to re-transfer all the files? (I don't have a .git on my laptop yet but all the files are there already.)
diff --git a/doc/forum/Fast_cloning_a_repo_initially/comment_1_0db0caafe30dd1b6f15fb1679dec8f9f._comment b/doc/forum/Fast_cloning_a_repo_initially/comment_1_0db0caafe30dd1b6f15fb1679dec8f9f._comment
new file mode 100644
index 0000000000..5d4aa35090
--- /dev/null
+++ b/doc/forum/Fast_cloning_a_repo_initially/comment_1_0db0caafe30dd1b6f15fb1679dec8f9f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="comment 1"
+ date="2014-05-23T15:30:23Z"
+ content="""
+I don't recommend moving direct mode repositories between filesystems, because git-annex relies on the inode as one way to detect if files in a direct mode repo have changed. It will notice that all the inode numbers have changed, and fall back to a mode where it only uses mtime.
+
+Anyway, your situation is better handled by initializing a repository on the desktop, and a separate one on the laptop. Then add remotes tying the repos together, and git-annex sync will just do the right thing, including not transferring files that have already been synced to both places.
+"""]]
diff --git a/doc/forum/Fast_cloning_a_repo_initially/comment_2_e17abc209c2b3ba20158be76801ce04a._comment b/doc/forum/Fast_cloning_a_repo_initially/comment_2_e17abc209c2b3ba20158be76801ce04a._comment
new file mode 100644
index 0000000000..0a07264cd0
--- /dev/null
+++ b/doc/forum/Fast_cloning_a_repo_initially/comment_2_e17abc209c2b3ba20158be76801ce04a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jamieson"
+ ip="71.11.161.246"
+ subject="Thanks!"
+ date="2014-05-23T16:11:35Z"
+ content="""
+I'll do it that way, thanks!!
+"""]]
diff --git a/doc/forum/Feature_Request__58___Specify_file_size_when_adding_files_to_URL_backend.mdwn b/doc/forum/Feature_Request__58___Specify_file_size_when_adding_files_to_URL_backend.mdwn
new file mode 100644
index 0000000000..bc7be2775c
--- /dev/null
+++ b/doc/forum/Feature_Request__58___Specify_file_size_when_adding_files_to_URL_backend.mdwn
@@ -0,0 +1,10 @@
+It seems that the only way to add a key with the URL backend and with an explicit file size is to use addurl --fast, which requires a a connection to be made to the remote server. However, it becomes impractical when I have tens of thousands of URLs, and I end up hammering the server, when I know ahead of time exactly what the file sizes are. I know it is possible to create URL keys with a size attribute. It would be great to be able to have something like addurl --size=342345 --raw, or be able to pass a size to registerurl.
+
+I have figured out how to construct a SHA256 key outside of git-annex, but I've looked at the source and I admit I'm a bit over my head with manually constructing a URL key.
+
+
+I've been doing a lot of experimenting with [pre-seeding](https://git-annex.branchable.com/forum/__34__Preseeding__34___a_special_remote/), which I would like to share. I think it could be a really cool application of git-annex.
+
+So far, I've been able to generate a distfiles repo automatically for Gentoo portage, which contains BLAKE2B512 signatures for all of their distfiles. I think there could potentially be some really cool applications to keeping track of large sets of files, and I want to eventually try to make it so that portage could fetch distfiles from other users over ipfs.
+
+But, there are many interesting collections of files that are in open directories, and all I have is the filenames and sizes, and being able to quickly generate a repo with knowledge of the exact size would make it really easy to divvy up downloading and mirroring with git. I have a script that converts an FTP server to a git-annex repo with a WORM backend, but I still think that using URL keys would be a better representation of where the resource is.
diff --git a/doc/forum/Feature_Request__58___Specify_file_size_when_adding_files_to_URL_backend/comment_1_9d2fa7d796fd40718d0df9feeea654aa._comment b/doc/forum/Feature_Request__58___Specify_file_size_when_adding_files_to_URL_backend/comment_1_9d2fa7d796fd40718d0df9feeea654aa._comment
new file mode 100644
index 0000000000..b3c3f261e4
--- /dev/null
+++ b/doc/forum/Feature_Request__58___Specify_file_size_when_adding_files_to_URL_backend/comment_1_9d2fa7d796fd40718d0df9feeea654aa._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-05-29T16:41:34Z"
+ content="""
+I wonder if you've tried addurl --fast with a recent version of git-annex?
+
+Since it recently stopped shelling out to curl for every url, it keeps a
+http connection open to the server, and is limited only by network
+latency. Combined with -J10, it might be fast enough now to not be a
+serious bottleneck.
+
+The mangling of urls in keys is ad-hoc and I'd rather not document that
+as part of git-annex's interface, so building your own url keys is not
+recommended.
+
+I could see adding a size value to git-annex registerurl, and
+I think you'd also want git-annex fromkey to have that too so you can
+add the keys to the working tree.
+"""]]
diff --git a/doc/forum/Feature_Request__58___add_filename_to_hash_objects.mdwn b/doc/forum/Feature_Request__58___add_filename_to_hash_objects.mdwn
new file mode 100644
index 0000000000..173cd2d949
--- /dev/null
+++ b/doc/forum/Feature_Request__58___add_filename_to_hash_objects.mdwn
@@ -0,0 +1,6 @@
+hi,  
+i just did git annex unused in 2 repos, one with WORM and one with SHA1.   
+with WORM i instantly could see which file it was, with SHA1 not.  
+
+so would it be possible to just add the first seen filename to the hashes identifier? the name could just be ignored but it would help with unused to see which file i am searching for.  
+thanks!
diff --git a/doc/forum/Feature_Request__58___add_filename_to_hash_objects/comment_1_73dc0a9cad486cf2d34faf064c6193b1._comment b/doc/forum/Feature_Request__58___add_filename_to_hash_objects/comment_1_73dc0a9cad486cf2d34faf064c6193b1._comment
new file mode 100644
index 0000000000..8a2f9fb009
--- /dev/null
+++ b/doc/forum/Feature_Request__58___add_filename_to_hash_objects/comment_1_73dc0a9cad486cf2d34faf064c6193b1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 1"
+ date="2013-10-16T15:19:25Z"
+ content="""
+Adding a filename would defeat deduplication. You suggest adding the \"first seen\" filename, but then git-annex would need to maintain a lookup between hashes and hashes with the first seen filename to use when adding new files.
+
+There is already [[todo/wishlist: option to print more info with 'unused']].
+"""]]
diff --git a/doc/forum/Feature_Request__58___add_filename_to_hash_objects/comment_2_f818b3ecfeb1d1dd83df4668c061718a._comment b/doc/forum/Feature_Request__58___add_filename_to_hash_objects/comment_2_f818b3ecfeb1d1dd83df4668c061718a._comment
new file mode 100644
index 0000000000..638492822e
--- /dev/null
+++ b/doc/forum/Feature_Request__58___add_filename_to_hash_objects/comment_2_f818b3ecfeb1d1dd83df4668c061718a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="orb"
+ ip="178.11.228.69"
+ subject="comment 2"
+ date="2013-10-17T21:12:09Z"
+ content="""
+thanks! (i hope a thanks is wanted, i know people who are just distracted and consider \"thanks\" posts unnecessary)
+"""]]
diff --git a/doc/forum/Feature_request__58___--quiet_for_fsck__44___import__44___etc.mdwn b/doc/forum/Feature_request__58___--quiet_for_fsck__44___import__44___etc.mdwn
new file mode 100644
index 0000000000..a00b3482a5
--- /dev/null
+++ b/doc/forum/Feature_request__58___--quiet_for_fsck__44___import__44___etc.mdwn
@@ -0,0 +1,9 @@
+My main use for git-annex is to manage a photo/video archive of my extended family.
+
+I regularly use `git annex import --clean-duplicates` to clean up old copies before going through the effort of manually putting data into the global directory structure. I only care about seeing how much data was removed, i.e. `git annex import --clean-duplicates foo | grep -v 'not duplicate; skipping'`. It would be a lot nicer to suppress this natively with `--quiet`. Ideally, in this case, only files which are being deleted (i.e. destructive actions), errors, and final stats (how many files were not deleted and how many were deleted) would be printed.
+
+Along similar lines, I don't care about everything which goes right in an `fsck`; I care about anything going wrong. A `--quiet` should print errors and final stats, nothing more.
+
+
+Best,
+Richard
diff --git a/doc/forum/Feature_request__58___--quiet_for_fsck__44___import__44___etc/comment_1_cbcc3df01a346c6ee6720c90421ee023._comment b/doc/forum/Feature_request__58___--quiet_for_fsck__44___import__44___etc/comment_1_cbcc3df01a346c6ee6720c90421ee023._comment
new file mode 100644
index 0000000000..a72427e4e8
--- /dev/null
+++ b/doc/forum/Feature_request__58___--quiet_for_fsck__44___import__44___etc/comment_1_cbcc3df01a346c6ee6720c90421ee023._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-05-06T16:03:48Z"
+ content="""
+git-annex already has a --quiet option. It avoids all command output except
+for error messages.
+"""]]
diff --git a/doc/forum/Feature_request__58___Multiple_concurrent_transfers.mdwn b/doc/forum/Feature_request__58___Multiple_concurrent_transfers.mdwn
new file mode 100644
index 0000000000..a9d9fb162d
--- /dev/null
+++ b/doc/forum/Feature_request__58___Multiple_concurrent_transfers.mdwn
@@ -0,0 +1,19 @@
+I'm sitting on a pretty fast connection, and often git-annex isn't using my entire upstream to fill the remotes.
+
+Lets say i have an annex with 10 x 100mb files. and my git-annex has 5 special remotes that needs to be filled.
+
+I would like to have git-annex do 5 concurrent uploads(one to each remote). Currently git-annex only uploads to one special-remote at a time (meaning the 4 remaining servers are just waiting).
+
+It would also be nice to have a per remote number of threads. Especially if adding a directory with 1000 small files in it(say 100bytes each), having 5 transfer threads to each remote would make the sync complete much faster.
+
+
+For now i've made a shell script that i call:
+
+    # for j in `seq -w 0 10`; do echo DOING $j; for i in `curl "http://127.0.0.1:$1/?auth=$2" | grep "continue" | gawk -F\"  ' { print $8 } '`; do curl "http://127.0.0.1:$1$i"; sleep 0; done; done
+
+But it is very rough, and basically just starts all transfers on the page. Which means i currently have 315 active transfers running. whoops.
+
+I could improve the shell script. But it really would be quite a bit niftier to have it as settings in git-annex.
+
+Sincerely
+Tobias
diff --git a/doc/forum/Feature_request__58___Multiple_concurrent_transfers/comment_1_aa666349e9b524fd5394a259ad622c3b._comment b/doc/forum/Feature_request__58___Multiple_concurrent_transfers/comment_1_aa666349e9b524fd5394a259ad622c3b._comment
new file mode 100644
index 0000000000..4ff1504ff9
--- /dev/null
+++ b/doc/forum/Feature_request__58___Multiple_concurrent_transfers/comment_1_aa666349e9b524fd5394a259ad622c3b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="unqueued"
+ avatar="http://cdn.libravatar.org/avatar/3bcbe0c9e9825637ad7efa70f458640d"
+ subject="comment 1"
+ date="2018-05-28T14:46:04Z"
+ content="""
+I have been toying with \"external\" transfer handlers. Sometimes when I am dealing with very large files, it makes more sense to just copy the keys outside of git-annex, and then after they are copied, run fsck. Perhaps at some point there could be a way to have a transfer \"shim\" of some kind, for handling transfers.
+"""]]
diff --git a/doc/forum/Feature_request__58___git_annex_copy_--auto_does_the_right_thing.mdwn b/doc/forum/Feature_request__58___git_annex_copy_--auto_does_the_right_thing.mdwn
new file mode 100644
index 0000000000..0a069340c0
--- /dev/null
+++ b/doc/forum/Feature_request__58___git_annex_copy_--auto_does_the_right_thing.mdwn
@@ -0,0 +1,5 @@
+I'm not sure of the right place for feature requests; sorry if this is incorrect.
+
+It occurred to me that it would be neat if running git annex copy --auto copied enough copies of the file to connected remotes that don't have it to fulfil numcopies (if possible). Further coolness could come from choosing the remotes smartly (based, for example, on availability, access cost, remote disk space, trust level... you get the idea)
+
+Having an option like this would allow the user to use numcopies to backup files to wherever possible, if they don't really care about where those copies go.
diff --git a/doc/forum/Feature_request__58___git_annex_copy_--auto_does_the_right_thing/comment_1_bbac7d0810a79eb1f42a01e1b31d5c4c._comment b/doc/forum/Feature_request__58___git_annex_copy_--auto_does_the_right_thing/comment_1_bbac7d0810a79eb1f42a01e1b31d5c4c._comment
new file mode 100644
index 0000000000..cd834e08d4
--- /dev/null
+++ b/doc/forum/Feature_request__58___git_annex_copy_--auto_does_the_right_thing/comment_1_bbac7d0810a79eb1f42a01e1b31d5c4c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.183"
+ subject="comment 1"
+ date="2013-02-09T02:32:23Z"
+ content="""
+You can kind of do this now by:
+
+for remote in $(git remote); do git annex copy --auto --to $remote; done
+
+Although without some of the potential smarts of course.
+"""]]
diff --git a/doc/forum/Feature_request__58___webapp_support_for_centralized_bare_repos.mdwn b/doc/forum/Feature_request__58___webapp_support_for_centralized_bare_repos.mdwn
new file mode 100644
index 0000000000..2fdab28a77
--- /dev/null
+++ b/doc/forum/Feature_request__58___webapp_support_for_centralized_bare_repos.mdwn
@@ -0,0 +1 @@
+I would like it if the webapp could support setting up [bare remotes](http://git-annex.branchable.com/tips/centralized_git_repository_tutorial/) to assist with syncing between two machines that are never online at the same time.
diff --git a/doc/forum/Feature_request__58___webapp_support_for_centralized_bare_repos/comment_1_0522e3df450efb6b2d264857e07997dc._comment b/doc/forum/Feature_request__58___webapp_support_for_centralized_bare_repos/comment_1_0522e3df450efb6b2d264857e07997dc._comment
new file mode 100644
index 0000000000..16c58c4692
--- /dev/null
+++ b/doc/forum/Feature_request__58___webapp_support_for_centralized_bare_repos/comment_1_0522e3df450efb6b2d264857e07997dc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 1"
+ date="2016-04-04T11:24:38Z"
+ content="""
+seconded
+"""]]
diff --git a/doc/forum/Feature_request__58___webapp_support_for_centralized_bare_repos/comment_2_e0fc126b0d500d41a563b076a4f6ed6d._comment b/doc/forum/Feature_request__58___webapp_support_for_centralized_bare_repos/comment_2_e0fc126b0d500d41a563b076a4f6ed6d._comment
new file mode 100644
index 0000000000..bbcd0e792d
--- /dev/null
+++ b/doc/forum/Feature_request__58___webapp_support_for_centralized_bare_repos/comment_2_e0fc126b0d500d41a563b076a4f6ed6d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 2"
+ date="2016-04-04T11:25:33Z"
+ content="""
+sorry, forgot to check the box for: \"email replies to me\" which was the sole purpose of commenting.
+"""]]
diff --git a/doc/forum/File_downloaded_again_and_again.mdwn b/doc/forum/File_downloaded_again_and_again.mdwn
new file mode 100644
index 0000000000..c4e06be80e
--- /dev/null
+++ b/doc/forum/File_downloaded_again_and_again.mdwn
@@ -0,0 +1,53 @@
+Hello,
+
+I have two repos, asaru in group client, marduk in groups archive and backup. Both are wanted=standard.
+
+Doing a ```git annex sync --content``` at asaru takes a long time and does the same action every time I run it (even if ran consecutively):
+
+```
+florian@asaru ~/Documents (git)-[master] % git annex sync --content
+commit  
+Auf Branch master
+Ihr Branch ist auf dem selben Stand wie 'marduk/master'.
+nichts zu committen, Arbeitsverzeichnis unverändert
+ok
+pull marduk 
+ok
+pull marduk.dynv6 
+ok
+get .localized (from marduk...) 
+SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+              0 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+(checksum...) ok
+get Bewerbung/bmw.aux (from marduk...) 
+SHA256E-s8--3345a075a22fb3bbc04567a1e5660ed0240d53f5881f458a2234dcd42a78d335.aux
+              8 100%    7.81kB/s    0:00:00 (xfr#1, to-chk=0/1)
+(checksum...) ok
+drop archive/Programmierung/zope/lib/python/Homefolder/.svn/empty-file (locking marduk.dynv6...) ok
+drop archive/Schule/Geschichte/Biographie 3/biographie.aux (locking marduk.dynv6...) ok
+pull marduk 
+ok
+pull marduk.dynv6 
+ok
+(recording state in git...)
+push marduk 
+Zähle Objekte: 8, Fertig.
+Delta compression using up to 4 threads.
+Komprimiere Objekte: 100% (8/8), Fertig.
+Schreibe Objekte: 100% (8/8), 679 bytes | 0 bytes/s, Fertig.
+Total 8 (delta 6), reused 0 (delta 0)
+To ssh://marduk.local/home/florian/Documents
+   bb9e640..b0fa6a1  git-annex -> synced/git-annex
+ok
+push marduk.dynv6 
+Everything up-to-date
+ok
+git annex sync --content  50,98s user 3,60s system 40% cpu 2:16,17 total
+```
+
+Taking a long time, as you can see in the last line. marduk.dynv6 and marduk are both (internet and local) remotes to Marduk.
+
+What is wrong here?
+
+Thanks,
+Florian
diff --git a/doc/forum/File_downloaded_again_and_again/comment_1_666b907935d467d5d7c0e57831d76631._comment b/doc/forum/File_downloaded_again_and_again/comment_1_666b907935d467d5d7c0e57831d76631._comment
new file mode 100644
index 0000000000..f4beaf50cc
--- /dev/null
+++ b/doc/forum/File_downloaded_again_and_again/comment_1_666b907935d467d5d7c0e57831d76631._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-19T18:53:04Z"
+ content="""
+Notice that the file it gets is empty, and the file it drops also appears
+to be an empty file, at least based on its filename. So, there is a single
+key used for both empty files.
+
+(There's also the two .aux files, which probably also have the same 8 byte
+content.)
+
+Your preferred content settings make one of the pair of files be wanted,
+and the other one not be wanted. In this situation, `get --auto` will get
+the key used for both files, and `drop --auto` will drop it. `sync
+--content` does both things, so repeatedly gets and then drops the key.
+
+One way to deal with this is to delete one of the copies of the file.
+Then it won't be in this mixed up state. But you may not want to do that.
+
+Another way to deal with it is to unlock one of the files, and add it back
+using `git annex add --backend=WORM $file`. This will make git-annex
+allocate a new key, only for that copy of the file.
+
+I do think this is a bug in git-annex, but not one that can immediately be
+fixed. I've opened a bug report at
+[[bugs/indeterminite_preferred_content_state_for_duplicated_file]].
+"""]]
diff --git a/doc/forum/File_history.mdwn b/doc/forum/File_history.mdwn
new file mode 100644
index 0000000000..4f25c03c51
--- /dev/null
+++ b/doc/forum/File_history.mdwn
@@ -0,0 +1,10 @@
+I'm having some trouble getting an understanding and visibility into the content history of the files managed by my git annex repository.
+
+`git log` shows changes to the files, but these changes are essentially just symlink changes.
+`git log -p` reveals these changes as symlink changes under `.git/annex`.
+
+What I want is:
+
+1. Of a file, to see the changes to that file's content that have happened over time.
+2. Of a file, to be able to revert it to an older version of that file's content.
+3. Of a file, to get visibility into what versions of that file's content are available on what remotes.
diff --git a/doc/forum/File_history/comment_1_6c15cdf71b99ae3bf8fd5de489a7d3ee._comment b/doc/forum/File_history/comment_1_6c15cdf71b99ae3bf8fd5de489a7d3ee._comment
new file mode 100644
index 0000000000..e7f112a788
--- /dev/null
+++ b/doc/forum/File_history/comment_1_6c15cdf71b99ae3bf8fd5de489a7d3ee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="past versions of annexed files"
+ date="2020-03-11T21:55:57Z"
+ content="""
+1. \"Of a file, to see the changes to that file's content that have happened over time\" -- See [[todo/git-annex-init_should_configure_git_diff_driver]].
+2. \"Of a file, to be able to revert it to an older version of that file's content\" -- if you create a branch off the commit with that file version,  and check out that branch, this will check out the file pointer to the older contents version.  You may need to then [[`git-annex-get`|git-annex-get]] that old content if it has been moved somewhere.
+3. \"Of a file, to get visibility into what versions of that file's content are available on what remotes\" -- see [[`git-annex-log`|git-annex-log]]
+"""]]
diff --git a/doc/forum/File_history/comment_2_ebe8025d4769d22cafa81ad0f2ae969a._comment b/doc/forum/File_history/comment_2_ebe8025d4769d22cafa81ad0f2ae969a._comment
new file mode 100644
index 0000000000..9515791362
--- /dev/null
+++ b/doc/forum/File_history/comment_2_ebe8025d4769d22cafa81ad0f2ae969a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2020-03-11T22:00:53Z"
+ content="""
+actually, for (3), `git-annex-log` isn't what you want: it shows _past_ locations, you want _current_ ones.  See [[`git-annex-whereis`|git-annex-whereis]] and [[`git-annex-list`|git-annex-list]].
+"""]]
diff --git a/doc/forum/File_history/comment_3_16aae9a5fdd5cfed816f5cdd96adf7ba._comment b/doc/forum/File_history/comment_3_16aae9a5fdd5cfed816f5cdd96adf7ba._comment
new file mode 100644
index 0000000000..5b88946327
--- /dev/null
+++ b/doc/forum/File_history/comment_3_16aae9a5fdd5cfed816f5cdd96adf7ba._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="NicholasLee"
+ avatar="http://cdn.libravatar.org/avatar/55f6909e71271c68a220adbdf2e0fac7"
+ subject="comment 3"
+ date="2020-09-20T02:28:08Z"
+ content="""
+Is there a way to see the history of a file in annex?   git annex log just shows the status of the current file.  
+
+git log just shows the meta data, not the actual file history.
+"""]]
diff --git a/doc/forum/File_history/comment_4_1b72655106507f111192231ab62cbe7e._comment b/doc/forum/File_history/comment_4_1b72655106507f111192231ab62cbe7e._comment
new file mode 100644
index 0000000000..a6c7a74691
--- /dev/null
+++ b/doc/forum/File_history/comment_4_1b72655106507f111192231ab62cbe7e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="history of annexed file"
+ date="2020-09-20T21:58:41Z"
+ content="""
+\"Is there a way to see the history of a file in annex\" -- do you mean the history of changes to the file?   Annexed files tend to be large binary files, so in what form would you want the diffs between such files shown?
+"""]]
diff --git a/doc/forum/File_history/comment_5_72d1b2ff307df69add474a288f92d8c3._comment b/doc/forum/File_history/comment_5_72d1b2ff307df69add474a288f92d8c3._comment
new file mode 100644
index 0000000000..f134700952
--- /dev/null
+++ b/doc/forum/File_history/comment_5_72d1b2ff307df69add474a288f92d8c3._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="NicholasLee"
+ avatar="http://cdn.libravatar.org/avatar/55f6909e71271c68a220adbdf2e0fac7"
+ subject="comment 5"
+ date="2020-09-21T00:24:28Z"
+ content="""
+By file history, I mean old versions of a file. So, if I do something like this:
+
+touch file.txt
+sleep 5
+echo -n \"1\" > file.txt
+sleep 5
+echo -n \"2\" >> file.txt
+
+How do I find copies of the initial and 2nd version (with only \"1\n\") of file.txt?
+
+Diffs could be done (if meaningful) via command line pipes or whatever.
+
+"""]]
diff --git a/doc/forum/File_still_symlinked_after_git_annex_unannex.mdwn b/doc/forum/File_still_symlinked_after_git_annex_unannex.mdwn
new file mode 100644
index 0000000000..54dc268a84
--- /dev/null
+++ b/doc/forum/File_still_symlinked_after_git_annex_unannex.mdwn
@@ -0,0 +1,22 @@
+So I'm about 5 minutes into using git-annex and I've already messed it up :-p.
+
+My intent is to get a working `.gitattributes` file that automatically uses annex for `git add` on image files such as RW2 (Panasonic RAW files) and regular git for `git add` on non-image files (especially in this case XMP sidecar files). So I set that up seemingly successfully. I did `git add P1000252.RW2` and it seemed to create a symlink in the annex folder. Then I figured I'd try using it a bit like I do with normal git, unstaging it before committing (note that I've made zero commits so far in this repo). That looked like it worked, at least in terms of `git status` and `git annex status`. However now I'm at a point where the file is untracked in git and a question mark in `git annex status` (presumably untracked as well), yet the file is still a symlink to the annex folder. I ran `git annex unannex` on the file and still it's a symlink.
+
+What I expected was that it would just go back to a regular file in its previous location instead of a symlink. Did I do something wrong? How do I "recover" from this, just manually move the file back in place and change the mode on it? Luckily this repo was just a test with some junk files so recovery of this particular file isn't critical, I just don't want to end up messing up my huge photo library going forward.
+
+Further breaking my brain right now is that on `git init` it used branch `main` and continued showing me as being on branch `main` throughout all this. But `git branch` only showed the branch `git-annex`. So I tried checking out this `git-annex` branch, and it says it switched to the branch. Then I tried checking out `main` again but I get `pathspec 'main' did not match any file(s) known to git`.
+
+Version:
+```
+git-annex version: 8.20210803
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.4 http-client-0.6.4.1 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+```
+
+Side note, and maybe this is something you hear a lot and hate hearing, but having the code, docs, and issues on a site like GitLab or GitHub would be a big improvement IMO.
diff --git a/doc/forum/File_still_symlinked_after_git_annex_unannex/comment_1_55f1a5f16fe2f8a85034a85c5450bad2._comment b/doc/forum/File_still_symlinked_after_git_annex_unannex/comment_1_55f1a5f16fe2f8a85034a85c5450bad2._comment
new file mode 100644
index 0000000000..568d3fdfb6
--- /dev/null
+++ b/doc/forum/File_still_symlinked_after_git_annex_unannex/comment_1_55f1a5f16fe2f8a85034a85c5450bad2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Austin"
+ avatar="http://cdn.libravatar.org/avatar/5954e64a0ca016dd371f3110f7acd7a9"
+ subject="comment 1"
+ date="2021-08-18T06:28:39Z"
+ content="""
+Naturally not long after I posted I found something that helped: http://git-annex.branchable.com/forum/git_annex_add_crash_and_subsequent_recovery/#comment-4f5af644597a055624009c5bbb9aca3f
+
+Somewhat unintuitively `git add P1000252.RW2` then `git annex unannex P1000252.RW2` got the file back to its previous location.
+
+I'm still feeling odd about the branch situation, but I think it may be this problem: https://git-annex.branchable.com/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/
+"""]]
diff --git a/doc/forum/File_too_big_for_file_system_of_git_remote.mdwn b/doc/forum/File_too_big_for_file_system_of_git_remote.mdwn
new file mode 100644
index 0000000000..6a1330d5c9
--- /dev/null
+++ b/doc/forum/File_too_big_for_file_system_of_git_remote.mdwn
@@ -0,0 +1 @@
+I have a file which is 5.4 GB big and so it won't fit on my fat32 formated flash drive. Since it's a git remote I can't enable chunking. Is there another way to go about this, or will that file simply not fit?
diff --git a/doc/forum/File_too_big_for_file_system_of_git_remote/comment_1_937df2f51506c42ddd2345735efd8f21._comment b/doc/forum/File_too_big_for_file_system_of_git_remote/comment_1_937df2f51506c42ddd2345735efd8f21._comment
new file mode 100644
index 0000000000..ae88326728
--- /dev/null
+++ b/doc/forum/File_too_big_for_file_system_of_git_remote/comment_1_937df2f51506c42ddd2345735efd8f21._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-06T15:33:17Z"
+ content="""
+You can add a directory special remote to the same flash drive,
+and enable chunking in that special remote, and store the file in there.
+
+Alternatively, there might be a less limited filesystem that you could
+reformat the drive with. Depending on the operating systems that this
+needs to work with..
+"""]]
diff --git a/doc/forum/Filesystem_recommendation___40__ext4__44___btrfs__44___xfs__44___you_name_it__41____63__.mdwn b/doc/forum/Filesystem_recommendation___40__ext4__44___btrfs__44___xfs__44___you_name_it__41____63__.mdwn
new file mode 100644
index 0000000000..95c745d49a
--- /dev/null
+++ b/doc/forum/Filesystem_recommendation___40__ext4__44___btrfs__44___xfs__44___you_name_it__41____63__.mdwn
@@ -0,0 +1,74 @@
+# Context: git annex "rules"
+
+First, I have to tell that `git-annex` is a big win so far (provided you have required git and other knowledge).
+
+My main use case for `git-annex` contains around 260,000 annexed files, for a total of 1.3 terabytes.
+
+Tried regular git on a subset of it and extrapolated.  Count 6-30 hours for simple operations like `git status`.  Plus huge space used for compressed copies of files.  All on current hardware: Intel i7 2.5GHz, 16GB RAM, hard disk raw performance 50-100+ MBytes/s.
+
+Using `git-annex` is a big win :
+
+* `git status` take not hours but about one to a few minutes (mostly thanks to decoupling voluntary data change and accidental data corruption and handling them at different times)
+* No space wasted.
+* "Just ask" push of data to remotes to maintain the required number of copies.
+* Easy fetch of missing data from remotes.
+* Corruption detection turns bad data into missing data which can just be fetched again.
+* Data is still there and readable without `git-annex` or even git.
+
+# Question
+
+**One to a few minutes for a `git status` is still long.  It is faster the second time (seconds) but still.  Can we reduce time for `git status` ?**
+
+
+
+This questions looks not `git-annex` specific.
+
+"Making `git status` fast is a git-level question".  In a sense it is, though `git-annex` repos are an extreme case of git-repository as they contain in most cases a lot of symlinks which look like small files at the filesystem level.
+
+Which makes the question more filesystem-level anyway, yet relevant to ask here.
+
+# Required features of a filesystem
+
+`git-annex` basically needs a filesystem that allows:
+
+* long file and directory names (hash in `.git/annex/objects` directory and file names)
+* long total paths
+* symlinks
+* hard links
+* unix permissions (to make hashed files immutable)
+
+More details e.g. on [day 188 crippled filesystem support](https://git-annex.branchable.com/design/assistant/blog/day_188__crippled_filesystem_support/)
+
+# Wished features of a filesystem
+
+Fast operations!
+
+Reiserfs, reiser4, btrs are said to be very efficient whe dealing with small files and symlinks thanks to [Block suballocation](https://en.wikipedia.org/wiki/Block_suballocation).
+
+# Question, restated.
+
+* Some users of `git-annex` will dedicate whole hard drives to `git-annex` repos, like I do.
+* Reading big files (from megabytes to gigabytes) from any decent filesystem implementation will yield similar performance.
+* Which leaves us to choose the filesystem based on safety and performance of reading a git repository with 100k to 1M symlinks.
+
+**Can anyone recommend a filesystem to use for fast git-annex level operations ?**
+
+## Anticipations
+
+Based on previous experience:
+
+* ext4: default choice, good.  Why chase for better?
+* "challenger filesystem X": might get better performance today (X=btrfs, X=reiser4)... or not. Might get dropped in the future (X=reiser4,X=btrfs). Might have bugs? All this might not be actually important, just do another git clone and reformat your drive to the new filesystem of the day.
+* btrfs: might waste a lot of space and actually have slower performance 
+* xfs?
+* a small and lightweight partition for metadata with a high performance filesystem and `.git/annex/objects` symlink to the big data-dedicated filesystem.  Might be better because of smaller head movements back and forth.  Size has to be decided in advance.
+
+Or perhaps all this is just nitpicking.
+
+Any thoughts?
+
+# References:
+
+* [Fast and slow symlinks - Unix & Linux Stack Exchange](http://unix.stackexchange.com/questions/147535/fast-and-slow-symlinks)
+* [Block suballocation - Wikipedia](https://en.wikipedia.org/wiki/Block_suballocation)
+* [git-annex across two filesystems](http://git-annex.branchable.com/forum/git-annex_across_two_filesystems/)
diff --git a/doc/forum/Filesystem_recommendation___40__ext4__44___btrfs__44___xfs__44___you_name_it__41____63__/comment_1_fcf7f132f771de28553bd20f4fb014cb._comment b/doc/forum/Filesystem_recommendation___40__ext4__44___btrfs__44___xfs__44___you_name_it__41____63__/comment_1_fcf7f132f771de28553bd20f4fb014cb._comment
new file mode 100644
index 0000000000..a671586f9a
--- /dev/null
+++ b/doc/forum/Filesystem_recommendation___40__ext4__44___btrfs__44___xfs__44___you_name_it__41____63__/comment_1_fcf7f132f771de28553bd20f4fb014cb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2018-01-24T03:10:53Z"
+ content="""
+Just ran into this question.  Might still be of interest: for our datalad.org project I did some benchmarking of various filesystems a few years back. Here you can find the final report: [http://old.datalad.org/test_fs_analysis.html](http://old.datalad.org/test_fs_analysis.html) -- I settled on a bunch of software raid5s with BTRFS on top of them.  So far (for years), quite good.  snapshots and [btrbk](http://digint.ch/btrbk/) are also a blessing.  I use the same btrfs also as docker backend.
+"""]]
diff --git a/doc/forum/Filing_issues_with_Mac_dmg_packaging_on_downloads.kitenet.net__63__.mdwn b/doc/forum/Filing_issues_with_Mac_dmg_packaging_on_downloads.kitenet.net__63__.mdwn
new file mode 100644
index 0000000000..2f13ec77c9
--- /dev/null
+++ b/doc/forum/Filing_issues_with_Mac_dmg_packaging_on_downloads.kitenet.net__63__.mdwn
@@ -0,0 +1,11 @@
+Where should questions re: the packaging of the Mac dmg on kitenet.net be directed?  Or, bugs filed?
+
+
+E.g. the CFBundleVersion and CFBundleShortVersionString are never bumped from "0.0.1" which makes it difficult to retrieve and deploy via Autopkg/Munki.
+
+
+Or, the data in git-annex.dmg.info for the current Mac release(s) (as of 2019-06-23) does not match any version reported in News on git-annex.branchable.com
+(currently distributionVersion = "7.20190508", but  distributionReleasedate = 2019-06-15) when installed git annex version reports 7.20190508.
+
+Thank you
+
diff --git a/doc/forum/Filing_issues_with_Mac_dmg_packaging_on_downloads.kitenet.net__63__/comment_1_0d89d709e799442d77b0fc92f97fc3ae._comment b/doc/forum/Filing_issues_with_Mac_dmg_packaging_on_downloads.kitenet.net__63__/comment_1_0d89d709e799442d77b0fc92f97fc3ae._comment
new file mode 100644
index 0000000000..9d4f45a9b1
--- /dev/null
+++ b/doc/forum/Filing_issues_with_Mac_dmg_packaging_on_downloads.kitenet.net__63__/comment_1_0d89d709e799442d77b0fc92f97fc3ae._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-06-25T17:24:15Z"
+ content="""
+You can file bug reports on git-annex about those builds.
+"""]]
diff --git a/doc/forum/Filing_issues_with_Mac_dmg_packaging_on_downloads.kitenet.net__63__/comment_2_cccbc5c1d9b010ae38a8b5cfd9056cfe._comment b/doc/forum/Filing_issues_with_Mac_dmg_packaging_on_downloads.kitenet.net__63__/comment_2_cccbc5c1d9b010ae38a8b5cfd9056cfe._comment
new file mode 100644
index 0000000000..ec8f74e239
--- /dev/null
+++ b/doc/forum/Filing_issues_with_Mac_dmg_packaging_on_downloads.kitenet.net__63__/comment_2_cccbc5c1d9b010ae38a8b5cfd9056cfe._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="leej"
+ avatar="http://cdn.libravatar.org/avatar/eb1c6bd57680f694fb4658388e6de4ed"
+ subject="comment 2"
+ date="2019-06-26T03:16:52Z"
+ content="""
+Thanks, Joey, see Mac dmg packaging related bugs:
+
+* [CFBundleShortVersionString is not incremented with git-annex.dmg releases (downloads.kitenet.net)](http://git-annex.branchable.com/bugs/CFBundleShortVersionString_is_not_incremented_with_git-annex.dmg_releases___40__downloads.kitenet.net__41__/)
+* [downloads.kitenet.net/git-annex/OSX/current/ distribution is 7.20190508 but 7.20190615 expected ](http://git-annex.branchable.com/bugs/downloads.kitenet.net__47__git-annex__47__OSX__47__current__47___distribution_is_7.20190508_but_7.20190615_expected/)
+"""]]
diff --git a/doc/forum/Find_files_that_lack_a_certain_field_in_metadata.mdwn b/doc/forum/Find_files_that_lack_a_certain_field_in_metadata.mdwn
new file mode 100644
index 0000000000..b0fe9ddaab
--- /dev/null
+++ b/doc/forum/Find_files_that_lack_a_certain_field_in_metadata.mdwn
@@ -0,0 +1,5 @@
+Is there any way to find all files that do not have a certain field assigned in metadata. E.g. I want to find all files that do not have an author field set and
+
+    git-annex find --not --metadata "author=*"
+
+doesn't give any results.
diff --git a/doc/forum/Find_files_that_lack_a_certain_field_in_metadata/comment_1_476e52563ccd3ad1b43e3a2da4dfaa82._comment b/doc/forum/Find_files_that_lack_a_certain_field_in_metadata/comment_1_476e52563ccd3ad1b43e3a2da4dfaa82._comment
new file mode 100644
index 0000000000..fbfb6ebb69
--- /dev/null
+++ b/doc/forum/Find_files_that_lack_a_certain_field_in_metadata/comment_1_476e52563ccd3ad1b43e3a2da4dfaa82._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 1"
+ date="2014-02-21T22:36:51Z"
+ content="""
+--metadata does not support globs, so your example is asking for all files that don't have an author field with a literal \"*\" value. When I try that command, it lists all files ... as expected.
+
+It seems that adding glob support to it would get to the result you want, and makes sense to parallel git annex view. Change made in git!
+"""]]
diff --git a/doc/forum/Find_out_if_file_is_in_annex__63__.mdwn b/doc/forum/Find_out_if_file_is_in_annex__63__.mdwn
new file mode 100644
index 0000000000..9d46808400
--- /dev/null
+++ b/doc/forum/Find_out_if_file_is_in_annex__63__.mdwn
@@ -0,0 +1,8 @@
+Hi,
+
+I am currently trying to move nearly all of my files into git-annex, and I was wondering if there is a (plumbing-level?) way to easily figure out if a file I find on a random hard disk is already contained in my annex repository?
+
+I.e., is there an easy way to compute the key for a file (which is not in an annex) and look up if the file is already contained in a given annex repository? I've looked a bit at the plumbing-level commands but none seem to exactly fit the bill :-/
+
+Cheers,
+Alex
diff --git a/doc/forum/Find_out_if_file_is_in_annex__63__/comment_1_3936ff53d5c9f7e5795b15beadf437c7._comment b/doc/forum/Find_out_if_file_is_in_annex__63__/comment_1_3936ff53d5c9f7e5795b15beadf437c7._comment
new file mode 100644
index 0000000000..f70436ab42
--- /dev/null
+++ b/doc/forum/Find_out_if_file_is_in_annex__63__/comment_1_3936ff53d5c9f7e5795b15beadf437c7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-12-11T15:20:55Z"
+ content="""
+It's not plumbing level, but `git-annex import --deduplicate`
+or `git-annex import --skip-duplicates` are meant to handle this sort
+of thing.
+"""]]
diff --git a/doc/forum/Find_unlocked__47__locked_files.mdwn b/doc/forum/Find_unlocked__47__locked_files.mdwn
new file mode 100644
index 0000000000..922c8c5603
--- /dev/null
+++ b/doc/forum/Find_unlocked__47__locked_files.mdwn
@@ -0,0 +1,23 @@
+Hello, I would like to know if there is any way to specifically list the locked or unlocked annexed files in a git annex.
+I looked at the [[git-annex-lock]], [[git-annex-find]], and [[git-annex-matching-options]] pages and even the discussion about the [[tips/unlocked_files]] but I didn't find anything.
+
+I know it wouldn't make any sens for the older versions, but in the v6 mode, I think it might be useful to add such a shortcut search.
+I mean, we can already look for local content with:
+```git annex find --in=here```
+so why not create something like
+```git annex find --locked/unlocked=yes/no```
+?
+
+Sure it is already more or less doable by looking at symlinks:
+[[!format sh """
+#list all broken symlinks (locked absent files ?)
+find . -xtype l 
+#list all symlinks (locked present files ?)
+find -L . -xtype l
+#list all files that aren't symlinks (unlocked files ?)
+find . -type -f
+"""]]
+But it is also possible for any symlink or file not to be part of the annex.
+So, in order to find the locked/unlocked files, it would require to intersect the previous sets of files with the set of annexed ones.
+
+Am I missing any easy tip or command argument to do this ?
diff --git a/doc/forum/Find_unlocked__47__locked_files/comment_1_a34ce29b644c80789bf8cbfd575ffe1a._comment b/doc/forum/Find_unlocked__47__locked_files/comment_1_a34ce29b644c80789bf8cbfd575ffe1a._comment
new file mode 100644
index 0000000000..27bd6c89e5
--- /dev/null
+++ b/doc/forum/Find_unlocked__47__locked_files/comment_1_a34ce29b644c80789bf8cbfd575ffe1a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="comment 1"
+ date="2018-09-23T16:46:47Z"
+ content="""
+Usually I use \"git status\" to check if I have unlocked files. But, I'd say that's a workaround for the feature that you suggest.
+"""]]
diff --git a/doc/forum/Find_unlocked__47__locked_files/comment_2_85d90a43142d087e7b6183dd9f8be8cf._comment b/doc/forum/Find_unlocked__47__locked_files/comment_2_85d90a43142d087e7b6183dd9f8be8cf._comment
new file mode 100644
index 0000000000..da08f40ad8
--- /dev/null
+++ b/doc/forum/Find_unlocked__47__locked_files/comment_2_85d90a43142d087e7b6183dd9f8be8cf._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-19T16:14:26Z"
+ content="""
+`git status` only finds unlocked files that have recently been unlocked but
+not committed. (In v5 there were no other kind, but it won't find them all
+in v7.)
+
+I've added a --unlocked option to find them.
+"""]]
diff --git a/doc/forum/Finding_out_why_file_is_not_being_auto-dropped.mdwn b/doc/forum/Finding_out_why_file_is_not_being_auto-dropped.mdwn
new file mode 100644
index 0000000000..3354d5d27e
--- /dev/null
+++ b/doc/forum/Finding_out_why_file_is_not_being_auto-dropped.mdwn
@@ -0,0 +1,22 @@
+Hello!
+
+I've being using git-annex for a while, and I currently have a file which is not being auto dropped, although it has enough of copies.
+I also cannot find out which commit introduced it.
+
+```sh
+% git annex whereis --key=SHA256E-s1611030508--280877e3adf28838f631f0e3ffd892e1bc04842528a1ffa8d8d23711974d2d08.mp4
+whereis SHA256E-s1611030508--280877e3adf28838f631f0e3ffd892e1bc04842528a1ffa8d8d23711974d2d08.mp4 (3 copies)
+        0155e17e-5a25-4be0-b344-6f37d6e37b8c -- [remote1]
+        2f439291-b8ea-4726-83a7-827b3caf8700 -- user@pc:~/repo [here]
+        831a8460-73d4-4684-bd5d-02433590b3bc -- [remote2]
+ok
+
+% git annex numcopies
+2
+```
+
+`git annex drop --auto` doesn't seem to help safely deleting it.
+
+I tried searching the hash with `% git log -S "<hash>"`, but it returns nothing.
+
+Why could this be, and how do I find and drop this files (and how to treat them in general)?
diff --git a/doc/forum/Finding_out_why_file_is_not_being_auto-dropped/comment_1_d3881fe94e3588c90e74c6bb3db2783c._comment b/doc/forum/Finding_out_why_file_is_not_being_auto-dropped/comment_1_d3881fe94e3588c90e74c6bb3db2783c._comment
new file mode 100644
index 0000000000..de6f2f7ebb
--- /dev/null
+++ b/doc/forum/Finding_out_why_file_is_not_being_auto-dropped/comment_1_d3881fe94e3588c90e74c6bb3db2783c._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-04-19T16:21:09Z"
+ content="""
+`git-annex drop` only operates on files in the current subdirectory
+and below, so it won't do anything about a key that is not used by any
+file.
+
+Run `git-annex unused` and then `git-annex drop --unused` to deal
+with such keys.
+
+All it takes to create a key that is not referenced by anything in
+the repository is adding it and then never committing the file.
+For example:
+
+	git-annex add foo
+	rm foo
+	git rm --cached foo
+"""]]
diff --git a/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__.mdwn b/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__.mdwn
new file mode 100644
index 0000000000..ded094ec13
--- /dev/null
+++ b/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__.mdwn
@@ -0,0 +1,3 @@
+I've made a first attempt at a .app launcher for git-annex webapp for OSX, please see <https://github.com/jcftang/git-annex/commits/master> the icon needs to be resized and made to look nicer at somepoint, the launcher assumes that git-annex is in the run time path.
+
+I would imagine it might be possible to fiddle with the paths and get all the needed components into the .app file for OSX users.
diff --git a/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_1_97c261b9080c5ecc5424683066bbe05b._comment b/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_1_97c261b9080c5ecc5424683066bbe05b._comment
new file mode 100644
index 0000000000..aa2757054f
--- /dev/null
+++ b/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_1_97c261b9080c5ecc5424683066bbe05b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.141"
+ subject="comment 1"
+ date="2012-09-23T15:14:20Z"
+ content="""
+Aha! I had been fumbling trying to find the right way to do this. Looks very promising. Found the documentation for the file format: <http://developer.apple.com/library/ios/#documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html>
+
+Where do I install this thing? If I put the git-annex.app directory inside ~/Desktop/, will that put it on the user's desktop?
+
+Could you make a screenshot?
+
+I'm guessing that the NSAppleScriptEnabled is not needed, and perhaps the LSMinimumSystemVersionByArchitecture block could also be removed.
+"""]]
diff --git a/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_2_ae45f9703b635c235409682cf252d36c._comment b/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_2_ae45f9703b635c235409682cf252d36c._comment
new file mode 100644
index 0000000000..edb8e50c7a
--- /dev/null
+++ b/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_2_ae45f9703b635c235409682cf252d36c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.141"
+ subject="comment 2"
+ date="2012-09-23T15:17:42Z"
+ content="""
+Also, is there any global location I can install it when installing as root?
+"""]]
diff --git a/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_3_066ca31a2e5dfe55a58092ba85231c7c._comment b/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_3_066ca31a2e5dfe55a58092ba85231c7c._comment
new file mode 100644
index 0000000000..4a48117ee1
--- /dev/null
+++ b/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_3_066ca31a2e5dfe55a58092ba85231c7c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 3"
+ date="2012-09-23T15:52:31Z"
+ content="""
+The .app file can be placed anywhere, typically you would want to bundle it in a .dmg file for the user and the user just \"drags\" it to the /Applications folder. It should be possible to bundle statically linked binaries inside the .app bundle, you might end up having to ship parts of coreutils and a few other applications to make it self contained.
+
+Anyhow, here is a quick screencast <http://screencast.com/t/pnk8bk3hyUJM> and a screengrab of the app <http://screencast.com/t/4jjeRFx4g>
+"""]]
diff --git a/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_4_a0a9f7f44cadb8036fcddfc21bb0781f._comment b/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_4_a0a9f7f44cadb8036fcddfc21bb0781f._comment
new file mode 100644
index 0000000000..a18b341f71
--- /dev/null
+++ b/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_4_a0a9f7f44cadb8036fcddfc21bb0781f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 4"
+ date="2012-09-23T16:00:35Z"
+ content="""
+Thinking this out a little, I reckon the script _MacOS/git-annex_ could be a bit more clever and get the basedir/basename of where it app is and execute git-annex from the .app bundle, then you wouldn't need to install it as root at all. It would require a bit of work to collect the executables needed.
+
+Also, I just quickly checked my Lion install, it seems to come with git and uuidgen once xcode and the command line tools are installed. 
+"""]]
diff --git a/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_5_92240b3f8629f1f2bbe1829700082a79._comment b/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_5_92240b3f8629f1f2bbe1829700082a79._comment
new file mode 100644
index 0000000000..e8a6d550f3
--- /dev/null
+++ b/doc/forum/First_attempt_at_an_OSX_launcher___40__.app__41__/comment_5_92240b3f8629f1f2bbe1829700082a79._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.141"
+ subject="comment 5"
+ date="2012-09-23T16:29:19Z"
+ content="""
+For now I have it generating the shell script, so it contains the path to whereever git-annex's binary is actually installed.
+
+For root, the app is installed in /Applications/ , for non-root installs I put it in ~/Desktop/
+"""]]
diff --git a/doc/forum/Fix_duplicate_UUID.mdwn b/doc/forum/Fix_duplicate_UUID.mdwn
new file mode 100644
index 0000000000..f1f7ee89c7
--- /dev/null
+++ b/doc/forum/Fix_duplicate_UUID.mdwn
@@ -0,0 +1,5 @@
+Hi,
+
+For some reason, two of my repositories share the same UUID. Honestly I don't remember how this happened, as I set up these remotes years ago and not used them for a long time; maybe I just accidentally made a copy instead of git clone… no idea. Anyway, I'd like to use these remotes now. What's the best way to correct this problem? Is just editing UUID manually enough?
+
+Thank you,
diff --git a/doc/forum/Fix_duplicate_UUID/comment_1_1186caf5aa6830c2412f8584a43d8d86._comment b/doc/forum/Fix_duplicate_UUID/comment_1_1186caf5aa6830c2412f8584a43d8d86._comment
new file mode 100644
index 0000000000..e224f1dcd7
--- /dev/null
+++ b/doc/forum/Fix_duplicate_UUID/comment_1_1186caf5aa6830c2412f8584a43d8d86._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~liori"
+ nickname="liori"
+ avatar="http://cdn.libravatar.org/avatar/e1d0fdc746b3d21bb147160d40815e37b257b9119774d21784939b2d3ba95a91"
+ subject="comment 1"
+ date="2017-07-16T13:08:41Z"
+ content="""
+So, the procedure that worked for me was:
+
+ 1. edit the annex.uuid configuration setting in one of the repositories that had a duplicate
+
+ 2. edit the remote.*.annex.uuid configuration setting in all repositories that had the repository edited in (1) as a remote
+
+ 3. `git annex fsck` in both repositories that had the duplicate uuid—this is because these repositories did not have correct information as to which files they contained, due to my previous syncing efforts
+
+ 4. `git annex sync` till convergence
+
+"""]]
diff --git a/doc/forum/Fix_duplicate_UUID/comment_2_b0f06b58ef63dbb770773f28dfa1a29d._comment b/doc/forum/Fix_duplicate_UUID/comment_2_b0f06b58ef63dbb770773f28dfa1a29d._comment
new file mode 100644
index 0000000000..19323dc144
--- /dev/null
+++ b/doc/forum/Fix_duplicate_UUID/comment_2_b0f06b58ef63dbb770773f28dfa1a29d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="comment 2"
+ date="2017-07-20T16:33:02Z"
+ content="""
+Thanks for sharing.  I stumbled upon a similar problem and (IIRC) ended up doing at least one new clone.  I don't know if your solution is fully clean but it seems to have lower cost.
+"""]]
diff --git a/doc/forum/Fix_duplicate_UUID/comment_3_525b2838985392eb65e705ad354d02c4._comment b/doc/forum/Fix_duplicate_UUID/comment_3_525b2838985392eb65e705ad354d02c4._comment
new file mode 100644
index 0000000000..bae8551a0d
--- /dev/null
+++ b/doc/forum/Fix_duplicate_UUID/comment_3_525b2838985392eb65e705ad354d02c4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~liori"
+ avatar="http://cdn.libravatar.org/avatar/e1d0fdc746b3d21bb147160d40815e37b257b9119774d21784939b2d3ba95a91"
+ subject="comment 3"
+ date="2017-08-12T15:31:24Z"
+ content="""
+Indeed, I'm also not sure if this procedure fully solves the matter (some confirmation from developers would be nice!), but so far I haven't had any problems.
+"""]]
diff --git a/doc/forum/Fix_duplicate_UUID/comment_4_ce58bf264e63a07a214956436d96f1a5._comment b/doc/forum/Fix_duplicate_UUID/comment_4_ce58bf264e63a07a214956436d96f1a5._comment
new file mode 100644
index 0000000000..c0fb410aa5
--- /dev/null
+++ b/doc/forum/Fix_duplicate_UUID/comment_4_ce58bf264e63a07a214956436d96f1a5._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-10-02T16:47:31Z"
+ content="""
+The described procedure sounds ok to me.
+"""]]
diff --git a/doc/forum/Fix_wrong_rsync_with_git_annex_reinit__63__.mdwn b/doc/forum/Fix_wrong_rsync_with_git_annex_reinit__63__.mdwn
new file mode 100644
index 0000000000..ea4e30c9f3
--- /dev/null
+++ b/doc/forum/Fix_wrong_rsync_with_git_annex_reinit__63__.mdwn
@@ -0,0 +1,38 @@
+# Context
+
+* Had two repo A and B. 
+* A had a lot of content not yet tracked and thus not available on B.
+* Filesystem problem on A: (relatively small) part of big repo content is lost.
+* In emergency, used rsync to propagate yet untracked content from failing A to sane B.
+* But forgot `ignore .git`, so rsync also partly rsync'ed `.git/annex` .
+* Now sane repo B believes it is the source one (same UUID A) as shown by `git annex info --fast`. 
+
+Both A and B show:
+
+    UUID-of-A -- A [here]
+    UUID-of-B -- B
+
+# Actions done
+
+Search on Google, see [[https://git-annex.branchable.com/git-annex-reinit/]] .
+
+On B:
+
+    git annex reinit UUID-of-B
+    git annex fsck
+
+Now `git annex info -fast` on B shows as expected:
+
+    UUID-of-A -- A
+    UUID-of-B -- B [here]
+
+
+I'm currently doing `git annex copy --from B` to repropagate lost parts of A.
+
+# Question
+
+* Were actions done best thing to do?
+* Is there something more to do?
+* Something to check?
+
+Thanks.
diff --git a/doc/forum/Fix_wrong_rsync_with_git_annex_reinit__63__/comment_1_26cb6d46a408c1002aa2fbc6618242f3._comment b/doc/forum/Fix_wrong_rsync_with_git_annex_reinit__63__/comment_1_26cb6d46a408c1002aa2fbc6618242f3._comment
new file mode 100644
index 0000000000..33a480621d
--- /dev/null
+++ b/doc/forum/Fix_wrong_rsync_with_git_annex_reinit__63__/comment_1_26cb6d46a408c1002aa2fbc6618242f3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-05-25T17:51:26Z"
+ content="""
+You must have rsynced over the .git/config from A. That is where the UUID
+of the repository is stored. So B now has whatever git config settings you
+had in A. The reinit fixed the UUID; there could be other things, like
+remotes, that are configured wrong. Otherwise, the way you recovered seems
+fine.
+"""]]
diff --git a/doc/forum/Fix_wrong_rsync_with_git_annex_reinit__63__/comment_2_14ddf5ddf2b85c9d5ed5ca070744f1fe._comment b/doc/forum/Fix_wrong_rsync_with_git_annex_reinit__63__/comment_2_14ddf5ddf2b85c9d5ed5ca070744f1fe._comment
new file mode 100644
index 0000000000..aee6435c42
--- /dev/null
+++ b/doc/forum/Fix_wrong_rsync_with_git_annex_reinit__63__/comment_2_14ddf5ddf2b85c9d5ed5ca070744f1fe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="comment 2"
+ date="2017-07-20T17:55:03Z"
+ content="""
+More specific information is in https://git-annex.branchable.com/forum/Fix_duplicate_UUID/
+
+"""]]
diff --git a/doc/forum/Fixing_up_corrupt_annexes.mdwn b/doc/forum/Fixing_up_corrupt_annexes.mdwn
new file mode 100644
index 0000000000..be6beeca8f
--- /dev/null
+++ b/doc/forum/Fixing_up_corrupt_annexes.mdwn
@@ -0,0 +1,10 @@
+I was wondering how does one recover from...
+
+<pre>
+(Recording state in git...)
+error: invalid object 100644 8f154c946adc039af5240cc650a0a95c840e6fa6 for '041/5a4/SHA256-s6148--7ddcf853e4b16e77ab8c3c855c46867e6ed61c7089c334edf98bbdd3fb3a89ba.log'
+fatal: git-write-tree: error building trees
+git-annex: failed to read sha from git write-tree
+</pre>
+
+The above was caught when i ran a "git annex fsck --fast" to check stash of files"
diff --git a/doc/forum/Fixing_up_corrupt_annexes/comment_1_cea21f96bcfb56aaab7ea03c1c804d2d._comment b/doc/forum/Fixing_up_corrupt_annexes/comment_1_cea21f96bcfb56aaab7ea03c1c804d2d._comment
new file mode 100644
index 0000000000..335cbb51d2
--- /dev/null
+++ b/doc/forum/Fixing_up_corrupt_annexes/comment_1_cea21f96bcfb56aaab7ea03c1c804d2d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 1"
+ date="2012-07-24T22:00:35Z"
+ content="""
+This is a corrupt git repository. See [[tips/what_to_do_when_a_repository_is_corrupted]]
+"""]]
diff --git a/doc/forum/Fixing_up_corrupt_annexes/comment_2_5cdd2fcfa61b3f6255e5ad63a3ab00ce._comment b/doc/forum/Fixing_up_corrupt_annexes/comment_2_5cdd2fcfa61b3f6255e5ad63a3ab00ce._comment
new file mode 100644
index 0000000000..4692338af6
--- /dev/null
+++ b/doc/forum/Fixing_up_corrupt_annexes/comment_2_5cdd2fcfa61b3f6255e5ad63a3ab00ce._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2012-07-25T06:52:32Z"
+ content="""
+Ah I was looking at the walkthrough on how to fix the issue, I had not thought about looking at the tips section. That tip fixed the issue for me, thanks.
+"""]]
diff --git a/doc/forum/Folders_for___34__actions__34___-_now_that_views_have_disrupted_the_file_structure__63__.mdwn b/doc/forum/Folders_for___34__actions__34___-_now_that_views_have_disrupted_the_file_structure__63__.mdwn
new file mode 100644
index 0000000000..61a8c7905d
--- /dev/null
+++ b/doc/forum/Folders_for___34__actions__34___-_now_that_views_have_disrupted_the_file_structure__63__.mdwn
@@ -0,0 +1,20 @@
+The _views_ functionality has made the file structure dynamic. 
+
+With this in mind would it be possible/suitable to make drag and drop targets for `git-annex get` and `git-annex drop` commands?
+This would make available git annex most interesting feature to assistant users.
+
+I'm not entirely sure it's a good idea but it avoids file manager scripts and should be discoverable and easy to use.
+
+I see two possibilities:
+
+1. A folder in the annex root that contains a mirror of the tree but with only the unavailable files. Unavaliable files would then not be displayed in the live tree. Perhaps the folder can be called `remote`? Files can then be dragged from this tree to the live tree to trigger transfer of files. Any error/info gets displayed in the assistant
+2. Flat droptargets in the annex root for `drop` and `get` commands.
+
+
+Number one above makes discovering available files a bit cumbersome as you have to navigate down a parallell tree. It does make the available/remote distinction clearer which may be good for assistant users.
+
+The mechanism could be extended to include a folder or droptarget for each remote.
+
+The creation of droptargets/action folders could be triggered by a big visible button in the assistant interface **Manage Files**
+
+Is it messy?
diff --git a/doc/forum/Forcing_offline_copies_seem_available.mdwn b/doc/forum/Forcing_offline_copies_seem_available.mdwn
new file mode 100644
index 0000000000..0789726971
--- /dev/null
+++ b/doc/forum/Forcing_offline_copies_seem_available.mdwn
@@ -0,0 +1,3 @@
+I have a large archive repository copied on an LTO tape, plus a proxy version of it with data dropped on local HDD. I've added this stripped proxy as a remote to a central repository to keep track of what is stored on the tape. Unfortunately, since the proxy has no contents, the central repo thinks there are no copies available anywhere, even though the offline tape contains all the data.
+
+How could I convince the central repo that the copies do in fact exist, even if they are very much offline?
diff --git a/doc/forum/Forcing_offline_copies_seem_available/comment_1_75e8597a24c925981edf83c517d5a799._comment b/doc/forum/Forcing_offline_copies_seem_available/comment_1_75e8597a24c925981edf83c517d5a799._comment
new file mode 100644
index 0000000000..dc37d67c96
--- /dev/null
+++ b/doc/forum/Forcing_offline_copies_seem_available/comment_1_75e8597a24c925981edf83c517d5a799._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-08-14T14:50:51Z"
+ content="""
+You can use `git annex setpresentkey` to tell git-annex that a remote with
+a given uuid contains a given content.
+
+For example, if the proxy remote is named proxy
+and you know it contains all annexed files in the current directory
+and below, you could run this to tell git-annex that the proxy contains
+all the files it thought it didn't contain:
+
+	uuid=$(git config remote.proxy.annex-uuid)
+	git annex find --not --in proxy --format "\${key} $uuid 1\n" | \
+		git annex setpresentkey --batch
+
+There will be some problems using this empty proxy remote, eg if you
+run `git annex move somefile --from proxy`, git-annex will try to
+delete the content from it, see the content is not there, and update its
+location tracking to say that the proxy does not contain the content any
+longer. `git annex fsck --from proxy` will do similar so you'll need to
+avoid it.
+
+And, you'll probably want to use `git annex trust proxy` so that `git-annex
+drop` assumes it contains the content you said it has; by default git-annex
+will double-check and that check will fail.
+
+To avoid all these kind of issues with the proxy, a better approach might
+be to make a custom special remote that actually accesses the data on the
+tape drive. See [[special remote implementation howto|special_remotes/external]]
+"""]]
diff --git a/doc/forum/Forcing_offline_copies_seem_available/comment_2_7d0e219628ad19093c6b6410d24c5f9a._comment b/doc/forum/Forcing_offline_copies_seem_available/comment_2_7d0e219628ad19093c6b6410d24c5f9a._comment
new file mode 100644
index 0000000000..a63102f62e
--- /dev/null
+++ b/doc/forum/Forcing_offline_copies_seem_available/comment_2_7d0e219628ad19093c6b6410d24c5f9a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jarno"
+ avatar="http://cdn.libravatar.org/avatar/da157278ab330a9c936dd733c43740f8"
+ subject="comment 2"
+ date="2018-08-14T16:03:39Z"
+ content="""
+Nice, thank you! I think I'll just delete or move the proxy away after feeding the (fake) availability info to the main repo. That should prevent git-annex from accidentally discovering that the data doesn't actually exist on the proxy, right?
+"""]]
diff --git a/doc/forum/Forcing_offline_copies_seem_available/comment_3_3d57e187679b36be62f3918eb996c3df._comment b/doc/forum/Forcing_offline_copies_seem_available/comment_3_3d57e187679b36be62f3918eb996c3df._comment
new file mode 100644
index 0000000000..9ede92c73e
--- /dev/null
+++ b/doc/forum/Forcing_offline_copies_seem_available/comment_3_3d57e187679b36be62f3918eb996c3df._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-08-14T17:40:10Z"
+ content="""
+Indeed, making the proxy remote not accessible will avoid such probles.
+
+You will certianly need to make git-annex trust the remote if you want it
+to count the tape as a copy of a file.
+"""]]
diff --git a/doc/forum/Forcing_one_repo_to_contain_a_copy_of_all_files.mdwn b/doc/forum/Forcing_one_repo_to_contain_a_copy_of_all_files.mdwn
new file mode 100644
index 0000000000..827383f9f4
--- /dev/null
+++ b/doc/forum/Forcing_one_repo_to_contain_a_copy_of_all_files.mdwn
@@ -0,0 +1 @@
+With numcopies it is possible to control how many copies there should be of a file overall in all of the remotes. Is it also possible, using .gitattributes or something else, to force one of the repos (e.g. a server) to contain a copy of all files, or does this have to be done manually?
diff --git a/doc/forum/Forcing_one_repo_to_contain_a_copy_of_all_files/comment_1_702b1b94c735f1b9cde16daa77a80c12._comment b/doc/forum/Forcing_one_repo_to_contain_a_copy_of_all_files/comment_1_702b1b94c735f1b9cde16daa77a80c12._comment
new file mode 100644
index 0000000000..d964a253bb
--- /dev/null
+++ b/doc/forum/Forcing_one_repo_to_contain_a_copy_of_all_files/comment_1_702b1b94c735f1b9cde16daa77a80c12._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 1"
+ date="2013-09-14T20:36:53Z"
+ content="""
+That is what the \"backup\" preferred content group is for.  Depending on how your repos connect to each other it might take some more trickery to make all content migrate to it, but that will make it \"want\" all the files if it can get them.
+"""]]
diff --git a/doc/forum/Forcing_one_repo_to_contain_a_copy_of_all_files/comment_2_3df7fcbcd482bb9377ead238b314995b._comment b/doc/forum/Forcing_one_repo_to_contain_a_copy_of_all_files/comment_2_3df7fcbcd482bb9377ead238b314995b._comment
new file mode 100644
index 0000000000..e59af71fbd
--- /dev/null
+++ b/doc/forum/Forcing_one_repo_to_contain_a_copy_of_all_files/comment_2_3df7fcbcd482bb9377ead238b314995b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.105"
+ subject="Ed's right"
+ date="2013-09-19T18:56:39Z"
+ content="""
+What we don't have is something to enforce a particular preferred content setting. Ie, refuse to allow dropping a file from a repo if it's preferred content there. Currently you have to remember to use `git annex drop --auto` to cause the preferred content to be honored.
+"""]]
diff --git a/doc/forum/Forget_about_accidentally_added_file__63__.mdwn b/doc/forum/Forget_about_accidentally_added_file__63__.mdwn
new file mode 100644
index 0000000000..74fc3dbfa0
--- /dev/null
+++ b/doc/forum/Forget_about_accidentally_added_file__63__.mdwn
@@ -0,0 +1,5 @@
+As I am bringing order to my collection, I sometimes add wrong files to a repo (usually because they're in an unexpected place, it's a mess).
+
+Is there a way to make git annex forget about having added the key, as in delete the according `.log` file from the `git-annex` branch's working dir?
+
+I don't need the history to be rewritten but do want it to "soft forget" about the key's existance and stop trying to track or `fsck` it.
diff --git a/doc/forum/Forget_about_accidentally_added_file__63__/comment_1_a7e6b1f6abe4caf8bd93be879c960cec._comment b/doc/forum/Forget_about_accidentally_added_file__63__/comment_1_a7e6b1f6abe4caf8bd93be879c960cec._comment
new file mode 100644
index 0000000000..0f300d1893
--- /dev/null
+++ b/doc/forum/Forget_about_accidentally_added_file__63__/comment_1_a7e6b1f6abe4caf8bd93be879c960cec._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 1"
+ date="2021-04-10T17:12:28Z"
+ content="""
+Should mention that those files are usually only added, not actually committed.
+"""]]
diff --git a/doc/forum/Forget_about_accidentally_added_file__63__/comment_2_6beeec3a8bc9697481aa08738902203a._comment b/doc/forum/Forget_about_accidentally_added_file__63__/comment_2_6beeec3a8bc9697481aa08738902203a._comment
new file mode 100644
index 0000000000..5fa68dde12
--- /dev/null
+++ b/doc/forum/Forget_about_accidentally_added_file__63__/comment_2_6beeec3a8bc9697481aa08738902203a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 2"
+ date="2021-04-11T10:54:39Z"
+ content="""
+I just gave it a try in a test repo and manually deleting a key's `.log*` files makes git-annex forget about that key's existance. The record of it having existed at some point is still there in the historical commits but git annex doesn't care about those.
+
+Not sure about unwanted side-effects in a real repo though.
+"""]]
diff --git a/doc/forum/Forget_about_accidentally_added_file__63__/comment_3_6bf46255cd212942d8db8b01c95443b2._comment b/doc/forum/Forget_about_accidentally_added_file__63__/comment_3_6bf46255cd212942d8db8b01c95443b2._comment
new file mode 100644
index 0000000000..e0ac020fa5
--- /dev/null
+++ b/doc/forum/Forget_about_accidentally_added_file__63__/comment_3_6bf46255cd212942d8db8b01c95443b2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="un-adding a key"
+ date="2021-04-12T00:50:41Z"
+ content="""
+See [[`git-annex-dead --key`|git-annex-dead]].
+"""]]
diff --git a/doc/forum/Forget_about_accidentally_added_file__63__/comment_4_2183fee162740918e5f67f9bd460b18d._comment b/doc/forum/Forget_about_accidentally_added_file__63__/comment_4_2183fee162740918e5f67f9bd460b18d._comment
new file mode 100644
index 0000000000..2779ce217b
--- /dev/null
+++ b/doc/forum/Forget_about_accidentally_added_file__63__/comment_4_2183fee162740918e5f67f9bd460b18d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 4"
+ date="2021-04-12T09:46:03Z"
+ content="""
+I know about `dead` but that only marks the key as dead and doesn't delete its record from the git-annex branch, does it?
+"""]]
diff --git a/doc/forum/Forget_about_accidentally_added_file__63__/comment_5_2b248738c6fb871875cf1aa7413198cc._comment b/doc/forum/Forget_about_accidentally_added_file__63__/comment_5_2b248738c6fb871875cf1aa7413198cc._comment
new file mode 100644
index 0000000000..dbcfe417ab
--- /dev/null
+++ b/doc/forum/Forget_about_accidentally_added_file__63__/comment_5_2b248738c6fb871875cf1aa7413198cc._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="un-adding annexed files"
+ date="2021-04-12T14:18:19Z"
+ content="""
+\"[[`git-annex-dead`|git-annex-dead]] only marks the key as dead and doesn't delete its record from the git-annex branch\" -- true.  But, in theory, the presence of the dead key record would not affect you as a user?   Or are there so many dead keys that they are slowing down git-annex?
+
+The usual git way of undoing changes would be to revert to an earlier state of the branch.  This doesn't quite work with git-annex, because keys added on a reverted branch are still tracked in the current git-annex branch. I've asked about this in an earlier post (can't find it now), and the upshot was that there is not simple fix for this.
+
+[[`git-annex-forget --drop-dead`|git-annex-forget]] will \"prune references to repositories that have been marked as dead\"; maybe it can also prune dead keys?
+"""]]
diff --git a/doc/forum/Forget_about_accidentally_added_file__63__/comment_6_1fcfcb5dca366d8fd610c03654e15704._comment b/doc/forum/Forget_about_accidentally_added_file__63__/comment_6_1fcfcb5dca366d8fd610c03654e15704._comment
new file mode 100644
index 0000000000..3f3e087e8f
--- /dev/null
+++ b/doc/forum/Forget_about_accidentally_added_file__63__/comment_6_1fcfcb5dca366d8fd610c03654e15704._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="un-adding annexed files"
+ date="2021-04-12T14:18:44Z"
+ content="""
+\"[[`git-annex-dead`|git-annex-dead]] only marks the key as dead and doesn't delete its record from the git-annex branch\" -- true.  But, in theory, the presence of the dead key record would not affect you as a user?   Or are there so many dead keys that they are slowing down git-annex?
+
+The usual git way of undoing changes would be to revert to an earlier state of the branch.  This doesn't quite work with git-annex, because keys added on a reverted branch are still tracked in the current git-annex branch. I've asked about this in an earlier post (can't find it now), and the upshot was that there is not simple fix for this.
+
+[[`git-annex-forget --drop-dead`|git-annex-forget]] will \"prune references to repositories that have been marked as dead\"; maybe it can also prune dead keys?
+"""]]
diff --git a/doc/forum/Forget_about_accidentally_added_file__63__/comment_7_a982dd633e7f29ec80c8e4362ebc064a._comment b/doc/forum/Forget_about_accidentally_added_file__63__/comment_7_a982dd633e7f29ec80c8e4362ebc064a._comment
new file mode 100644
index 0000000000..8ca1422d57
--- /dev/null
+++ b/doc/forum/Forget_about_accidentally_added_file__63__/comment_7_a982dd633e7f29ec80c8e4362ebc064a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-04-13T17:00:10Z"
+ content="""
+Marking a key as dead does stop fsck complaining about it, and necessarily
+means there are no copies of it tracked. So it kind of seems to me that
+meets the goal of "forget about the key's existance and stop trying to track
+or `fsck` it"
+
+I do think it would be reasonable to have git-annex forget --drop-dead
+also remove logs for dead keys, but for other reasons: It would reduce the
+size of the git-annex branch, and also eliminate mention of the key in the
+git-annex branch's history. [[todo/forget_dead_keys]]
+"""]]
diff --git a/doc/forum/Forget_about_accidentally_added_file__63__/comment_8_ed88d2b82fc3283540caf3a255a88188._comment b/doc/forum/Forget_about_accidentally_added_file__63__/comment_8_ed88d2b82fc3283540caf3a255a88188._comment
new file mode 100644
index 0000000000..e012b00e03
--- /dev/null
+++ b/doc/forum/Forget_about_accidentally_added_file__63__/comment_8_ed88d2b82fc3283540caf3a255a88188._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 8"
+ date="2021-04-22T10:01:01Z"
+ content="""
+It'd also be helpful if this could be integrated into the unannex subcommand:
+
+`git annex add file` -> realise it shouldn't have been added -> `git annex unannex --forget file`
+
+That would make for a rather intuitive and user-friendly workflow.
+
+If the git-annex branch is unpushed, it could even be rebased to reflect that change but that might be too complicated to do reliably.
+"""]]
diff --git a/doc/forum/Forget_about_accidentally_added_file__63__/comment_9_23cc8cec09f9e8fb56c0cb81c9b361bc._comment b/doc/forum/Forget_about_accidentally_added_file__63__/comment_9_23cc8cec09f9e8fb56c0cb81c9b361bc._comment
new file mode 100644
index 0000000000..de637a6358
--- /dev/null
+++ b/doc/forum/Forget_about_accidentally_added_file__63__/comment_9_23cc8cec09f9e8fb56c0cb81c9b361bc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-06-25T18:19:14Z"
+ content="""
+I think this is the same thing being discussed in
+[[todo/dead_files_in_checkout_directly]].
+"""]]
diff --git a/doc/forum/Fsck_by_refs_or_keys__63__.mdwn b/doc/forum/Fsck_by_refs_or_keys__63__.mdwn
new file mode 100644
index 0000000000..ff2d02df2f
--- /dev/null
+++ b/doc/forum/Fsck_by_refs_or_keys__63__.mdwn
@@ -0,0 +1,5 @@
+Hello,
+
+I'm trying to wrote a cronjob to fsck my git-annex bare repository on a server. My problem is that there are a lot of keys with no known copies because they were file that weren't meant to stay. So I want to only check files that are live in HEAD of master. Is there anyway to tell `git-annex fsck` to only check file that are used in some refs?
+
+Thanks.
diff --git a/doc/forum/Fsck_by_refs_or_keys__63__/comment_1_345daa76cdd13538054e886a755bf29d._comment b/doc/forum/Fsck_by_refs_or_keys__63__/comment_1_345daa76cdd13538054e886a755bf29d._comment
new file mode 100644
index 0000000000..bd5f3f754c
--- /dev/null
+++ b/doc/forum/Fsck_by_refs_or_keys__63__/comment_1_345daa76cdd13538054e886a755bf29d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-12T17:41:35Z"
+ content="""
+Currently the only way to do that is to make a clone of the bare repsitory
+that's not bare. Then run `git annex fsck --from origin` inside the clone.
+This is more efficient when the clone is on the same disk as the bare
+repository.
+
+Another way to deal with it is to use `git annex dead --key` to
+make fsk stop complaining about the specific keys that you don't mind are
+gone.
+"""]]
diff --git a/doc/forum/Fsck_by_refs_or_keys__63__/comment_2_1d74ad47cf3bef9bcc0ccdff4ccb69b9._comment b/doc/forum/Fsck_by_refs_or_keys__63__/comment_2_1d74ad47cf3bef9bcc0ccdff4ccb69b9._comment
new file mode 100644
index 0000000000..b5fba44147
--- /dev/null
+++ b/doc/forum/Fsck_by_refs_or_keys__63__/comment_2_1d74ad47cf3bef9bcc0ccdff4ccb69b9._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Rémi"
+ subject="comment 2"
+ date="2016-07-12T20:28:44Z"
+ content="""
+Thanks, I opted for the clone solution, as there are fare too many lost key in this repository to manually suppress them all.
+"""]]
diff --git a/doc/forum/Fsck_by_refs_or_keys__63__/comment_3_b00a9522bb6dd91fed5d1c790153a230._comment b/doc/forum/Fsck_by_refs_or_keys__63__/comment_3_b00a9522bb6dd91fed5d1c790153a230._comment
new file mode 100644
index 0000000000..b2ee98f73f
--- /dev/null
+++ b/doc/forum/Fsck_by_refs_or_keys__63__/comment_3_b00a9522bb6dd91fed5d1c790153a230._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-07-19T17:01:03Z"
+ content="""
+It would be possible to add something like `git annex fsck --branch foo `
+which would operate on all files in the specified branch. I've opened
+[[todo/operate_on_branch_contents]] requesting that.
+"""]]
diff --git a/doc/forum/Full_restore_from_an_encrypted_special_remote.mdwn b/doc/forum/Full_restore_from_an_encrypted_special_remote.mdwn
new file mode 100644
index 0000000000..d724929b05
--- /dev/null
+++ b/doc/forum/Full_restore_from_an_encrypted_special_remote.mdwn
@@ -0,0 +1,3 @@
+If I lose all my git-annex repositories is it possible to restore the content of a repo from a special remote in which encryption was enabled? I know git-annex isn't designed to be a backup solution but more for the archive and/or nomad use case. I do like the idea of being able to restore the files from an S3 special remote though. I imagine part of the answer to this question has to do with what type of encryption is used (hybrid and shared key rely on information stored in the repo but pubkey doesn't rely on the repo at all) and would probably be easier if there were an option to disable hashing the filenames of the files (less secure, but maybe ok in some cases).
+
+Thoughts?
diff --git a/doc/forum/Full_restore_from_an_encrypted_special_remote/comment_1_f3a7a766ae1fe8e586cd67148761f156._comment b/doc/forum/Full_restore_from_an_encrypted_special_remote/comment_1_f3a7a766ae1fe8e586cd67148761f156._comment
new file mode 100644
index 0000000000..e56829ec5b
--- /dev/null
+++ b/doc/forum/Full_restore_from_an_encrypted_special_remote/comment_1_f3a7a766ae1fe8e586cd67148761f156._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="You need a copy of the git repo"
+ date="2015-07-29T12:20:06Z"
+ content="""
+It is not possible to recover just from a special remote. You need at least one copy of the git repository. This drive doesn't need to carry around the actual payload.
+Consider using an encrypted thumb drive as an additional destination. You can even fully encrypt this repo and sync it up once in a while to keep the information up to date.
+You can have a look at [[tips/fully_encrypted_git_repositories_with_gcrypt]] for detailed information.
+"""]]
diff --git a/doc/forum/Full_workflow_guide.mdwn b/doc/forum/Full_workflow_guide.mdwn
new file mode 100644
index 0000000000..a9b22e53a7
--- /dev/null
+++ b/doc/forum/Full_workflow_guide.mdwn
@@ -0,0 +1,16 @@
+I try to use git annex, but I frequently don't know if I'm doing things correctly, and my files are getting messed up. 
+
+An expert guide to the full workflow would go a long way toward user-friendliness for me. The walkthrough currently has guides to a number discrete items in the workflow, but it doesn't give me a clear sense of the process. 
+
+I'm always confused about when I'm supposed to be using pure git commands and when they should be git annex commands, when to commit, add, and sync --content, and when each of these is redundant.
+
+If possible, most helpful would be a guide to how you imagine the workflow from the beginning and including each step of the process, in the order you'd do it. 
+
+1. I want to start keeping track of some files I have in a directory
+2. I want to copy them to a second computer. 
+3. From a third place, I want to get them from the second computer. 
+4. I change the files on one computer, and I want to make sure the changes get synced to the others. 
+
+What are the commands you'd run at each step?
+
+Many thanks.
diff --git a/doc/forum/Full_workflow_guide/comment_1_14664efebb1218a1449577eaa4653a77._comment b/doc/forum/Full_workflow_guide/comment_1_14664efebb1218a1449577eaa4653a77._comment
new file mode 100644
index 0000000000..320dd6b453
--- /dev/null
+++ b/doc/forum/Full_workflow_guide/comment_1_14664efebb1218a1449577eaa4653a77._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="https://anarc.at/openid/"
+ nickname="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/b36dcf65657dd36128161355d8920a99503def9461c1bb212410980fe6f07125"
+ subject="hopefully an answer..."
+ date="2017-01-17T16:54:22Z"
+ content="""
+looking at the page title here, i'm tempted to simply point you to [[todo/Workflow_guide]] and therefore the new [[workflow]] page, but that may not answer your question directly. so let's see...
+
+the the examples below, i'll assume you are familiar with the commandline and show examples using git and git-annex commands, since you mentioned that. but a lot of those things can be done with the web assistant, if not everything. but i am not very familiar with it, so you'll excuse my geekiness...
+
+1. I want to start keeping track of some files I have in a directory
+
+        cd directory
+        git init
+        git annex init
+        git annex add \"some\" \"files\"
+        git commit -m\"start keeping track of some files\"
+
+    Note that you could track all files with `git annex add .` or `git annex add *`... regular glob patterns apply.
+
+2. I want to copy them to a second computer.
+
+    This is the harder part. Here I'll assume that you have an SSH server on the first computer, which i'll name `firstcomputer`. If that's not your case, you can use the new [[special_remotes/tor]] to pair arbitrary machines with the [[tips/peer_to_peer_network_with_tor]] instructions instead of this.
+
+    On the second computer:
+
+        git clone firstcomputer:directory
+        cd directory
+        git annex get
+
+3. From a third place, I want to get them from the second computer.
+
+    Same comments as above apply.
+
+    On the third computer:
+
+        git clone secondcomputer:directory
+        cd directory
+        git annex get
+
+4. I change the files on one computer, and I want to make sure the changes get synced to the others.
+
+    This can be done manually with [[git-annex-sync]] (with the `--content` flag to copy actual content), or automated with the [[git-annex-assistant]] or [[git-annex-watch]].
+"""]]
diff --git a/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote.mdwn b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote.mdwn
new file mode 100644
index 0000000000..2c229d211b
--- /dev/null
+++ b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote.mdwn
@@ -0,0 +1,9 @@
+I am interested in using `git annex` to manage encrypted backups to Amazon S3/Glacier. So `git annex` will be used with the main file directory in direct mode and an encrypted S3 or Glacier remote set up in archive mode and then `git annex add .` and `git annex sync` will be run periodically. The intent is for this set up to be a backup for catastrophic failure, so I want to make sure I take care of future-proofing and disaster recovery properly. So my basic question is what would I need to have backed up and what would I have to do if the computer with the main repository died. I try to break that out into more specific questions below.
+
+0. S3/Glacier remotes store the contents of `.git/annex/objects` in encrypted form with hashes for file names and nothing else (other than a uuid). The hashes do not match the keys in the main repo. Are they the same keys encrypted? Is there a way to look up the S3 file name corresponding to a file in the repo?
+
+1. For `shared` encryption, I see the cipher text in `remote.log` in the `git-annex` branch. Assuming I didn't have access to `git annex`, what would I need to do to convert that cipher text into a form that I could use with `gpg` to decrypt files?
+   
+2. Same question but for `hybrid` encryption rather than `shared`. I assume the answer is similar but I need to decrypt the cipher first with my gpg key? How do I do that?
+
+3. Assuming I did have access to `git annex`, what would I need to create a new repo on a new computer with access to all of the files in the S3/Glacier bucket? I think I would need my Amazon credentials (possibly already embedded in the git repo), my gpg key if using hybrid or public key encryption, and the `.git` folder as it was the last time files were pushed to the S3/Glacier remote (which would have the necessary decryption information for shared encryption). Is that right? I guess mainly I am checking that the remote does not store any metadata about the repo, so for `git annex` to be able to pull files back out I would need a backup of the `.git` directory and that back up would need to be up to date (can't just copy remote.log and have `git annex` work out the rest from the remote's contents). So for a full backup, my script would need to `tar` the `.git` directory, encrypt it, and push it to S3/Glacier separately after `git annex` does a sync. Then I could recover everything as long as I had a secure backup of my Amazon credentials and my encryption key(s).
diff --git a/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_10_2eb2f05477a86f1352e734d163301ffa._comment b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_10_2eb2f05477a86f1352e734d163301ffa._comment
new file mode 100644
index 0000000000..467ab44c3f
--- /dev/null
+++ b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_10_2eb2f05477a86f1352e734d163301ffa._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2018-07-19T16:16:14Z"
+ content="""
+@oliv5 sharedpubkey's cipher has the same newline problem as pubkey does,
+as discussed above. Unlike pubkey, it has to be base64-decoded first,
+and then the extra newline appended to that.
+
+	                # Pull out MAC cipher from beginning of cipher
+	                if [ \"$encryption\" = \"hybrid\" ] ; then
+	                        cipher=\"$(echo -n \"$cipher\" | head  -c 256 )\"
+	                elif [ \"$encryption\" = \"shared\" ] ; then
+	                        cipher=\"$(echo -n \"$cipher\" | base64 -d | head  -c 256 )\"
+	                elif [ \"$encryption\" = \"pubkey\" ] ; then
+	                        cipher=\"$cipher
+	\"
+	                elif [ \"$encryption\" = \"sharedpubkey\" ] ; then
+	                        cipher=\"$(echo -n \"$cipher\" | base64 -d)\"
+				cipher=\"$cipher
+	\"
+			fi
+
+Note that base64 -d does emit the newline (verified with hexdump);
+again the shell is shooting you in the foot by eliminating it.
+
+BTW, a very simple code hack that makes it easy to dump out the cipher git-annex
+is using:
+
+	diff --git a/Remote/Helper/Encryptable.hs b/Remote/Helper/Encryptable.hs
+	index 97e55a415..c4d252912 100644
+	--- a/Remote/Helper/Encryptable.hs
+	+++ b/Remote/Helper/Encryptable.hs
+	@@ -192,7 +192,7 @@ describeCipher :: StorableCipher -> String
+	 describeCipher c = case c of
+ 		(SharedCipher _) -> \"encryption key stored in git repository\"
+	 	(EncryptedCipher _ _ ks) -> showkeys ks
+	-	(SharedPubKeyCipher _ ks) -> showkeys ks
+	+	(SharedPubKeyCipher c ks) -> show c ++ \" \" ++ showkeys ks
+	   where
+	 	showkeys (KeyIds { keyIds = ks }) = \"to gpg keys: \" ++ unwords ks
+
+Then git-annex info remote will display it. Obviously, this patch is insecure.
+"""]]
diff --git a/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_1_c2f7542ac9a4c423c5ae06c16d42a24f._comment b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_1_c2f7542ac9a4c423c5ae06c16d42a24f._comment
new file mode 100644
index 0000000000..b8c9d33c2a
--- /dev/null
+++ b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_1_c2f7542ac9a4c423c5ae06c16d42a24f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-12-11T14:42:32Z"
+ content="""
+That's what's "special" about special remotes vs regular git remotes: They
+only store the content of annexed files and not the git repository. Back up
+the git repository separately (and your gpg key if it's being used, and the
+credentials if you didn't use embedcreds=yes)
+
+To use your backup, you can make a clone of the backed up git repository and
+use `git annex enableremote` to enable it to use the special remote.
+
+See [[design/encryption]] for details of how the encryption is implemented.
+I've seen people follow that and manually use the data from the git repo to
+decrypt files, but I don't have a pointer to an example at the moment.
+"""]]
diff --git a/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_2_9a9da0ad1538ba59e76a5c4f9fc7fcf7._comment b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_2_9a9da0ad1538ba59e76a5c4f9fc7fcf7._comment
new file mode 100644
index 0000000000..ff35541ec1
--- /dev/null
+++ b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_2_9a9da0ad1538ba59e76a5c4f9fc7fcf7._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d"
+ subject="comment 2"
+ date="2015-12-12T10:42:46Z"
+ content="""
+Thanks for the response.
+
+With `pubkey` encryption, I am able to decrypt the remote's files normally using just `gpg --decrypt` with the public key used to encrypt them in my keyring. One thing I don't understand about `pubkey` encryption: what is in the `cipher=` entry in `remote.log` after the 256 bytes representing the HMAC cipher? The `gpg` key pair is used for encryption, so there is no encryption cipher to put in `remote.log` after the HMAC cipher, I would have thought.
+
+I understand the basic encryption set up, but I don't know how to use `gpg` to work with a raw cipher or raw encrypted text. For example with `pubkey` encryption, my interpretation is that the `cipher=` entry in `remote.log` is encrypted with the public key, but I can't just pass teh entry to `gpg --decrypt` because `gpg` expects the encrypted input to be formatted in a way that specifies which key to use to decrypt. Otherwise it says `gpg: no valid OpenPGP data found.` Similarly for `shared` encryption, I don't see how to pass the second half of the `remote.log` `cipher=` entry to `gpg` to decrypt the remote's files.
+
+I am also having trouble generating the special remote's keys. I created a `directory` remote with `shared` encryption (so that the `cipher=` entry in `remote.log` would not be encrypted). Then I added one file called `tmp.txt` which was stored in the annex as `SHA256E-s9--9c73fdec185d79405f58fc8b4e0ac22fa5ed2de7b7611a61b37606c905509650.txt` I did `git checkout git-annex -- remote.log` and then tried the following:
+
+        echo -n \"SHA256E-s9--9c73fdec185d79405f58fc8b4e0ac22fa5ed2de7b7611a61b37606c905509650.txt\" | openssl dgst -sha1 -hmac $(echo -n $(grep -oP 'cipher\=.*? ' remote.log | sed 's/cipher=//') | base64 -d | xxd -p -l 256 -c 256) -macopt hexkey:string`
+
+but the output does not match the GPGHMACSHA1 file name in the remote, and I don't understand why. I tried other variations as well (dropping the `.txt` or the SHA256E-s9--` prefix) but they did not work either.
+
+"""]]
diff --git a/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_3_27901f1c2c5de211f697972d9b21c104._comment b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_3_27901f1c2c5de211f697972d9b21c104._comment
new file mode 100644
index 0000000000..fe0187145e
--- /dev/null
+++ b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_3_27901f1c2c5de211f697972d9b21c104._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d"
+ subject="comment 3"
+ date="2015-12-14T12:03:22Z"
+ content="""
+Small update: I have gotten the HMAC and decryption steps to work for shared encryption. I didn't figure out what was wrong with my HMAC command above yet, but I was able to reproduce the special remote's keys in Python using the `hmac` and `hashlib` libraries. I was trying to hash the correct string in the comment above (the full key with the `SHA...` prefix and the file extension suffix). For decryption, I used `gpg` on the encrypted file in the special remote and passed it the cipher from `remote.log` with the first 256 bytes removed as the passphrase (in the format returned by `base64.b64decode()` in Python).
+
+I still need to figure out how to decrypt the ciphers for `pubkey` and `hybrid`.
+
+I will try to put together a tip with the steps needed to reproduce special remote keys and to decrypt special remote files using only command line tools after that (assuming I can translate the Python steps back to command line tools; otherwise part of the steps will be in Python).
+"""]]
diff --git a/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_4_56994d9252e8651b3f33044f5c8599b3._comment b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_4_56994d9252e8651b3f33044f5c8599b3._comment
new file mode 100644
index 0000000000..fbfa254ffa
--- /dev/null
+++ b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_4_56994d9252e8651b3f33044f5c8599b3._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d"
+ subject="comment 4"
+ date="2015-12-16T11:21:48Z"
+ content="""
+Decrypting the cipher for `hybrid` and `pubkey` remotes is actually pretty straightforward: `echo -n <cipher_entry> | base64 -d | gpg --decrypt`. I think with that I have enough to put together a short summary of decrypting by hand the contents of `hybrid`, `pubkey`, and `shared` special remotes.
+"""]]
diff --git a/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_5_5aecb8c58d501e929e746d5536032c81._comment b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_5_5aecb8c58d501e929e746d5536032c81._comment
new file mode 100644
index 0000000000..8c3478d978
--- /dev/null
+++ b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_5_5aecb8c58d501e929e746d5536032c81._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-12-19T17:59:38Z"
+ content="""
+When using `pubkey`, the second 256 bytes of ciphertext are currently
+not used for anything.
+
+For `hybrid` and `shared`, the 256 bytes of ciphertext are used
+as a symmetric cipher. So the gpg option to use for both encrypting
+and decrypting is --symmetric. gpg then prompts for a passphrase,
+and the ciphertext is what's used.
+"""]]
diff --git a/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_6_ab0b660e5a3d7fc7d3d3a4b460022da5._comment b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_6_ab0b660e5a3d7fc7d3d3a4b460022da5._comment
new file mode 100644
index 0000000000..eda99e459c
--- /dev/null
+++ b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_6_ab0b660e5a3d7fc7d3d3a4b460022da5._comment
@@ -0,0 +1,139 @@
+[[!comment format=mdwn
+ username="wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d"
+ subject="comment 6"
+ date="2015-12-26T12:31:13Z"
+ content="""
+joey, thanks for answering my questions. I have put together a bash script to check my understanding of how the different encryption methods work. The script is below. With it, I am able to generate the encrypted keys for items for `hybrid` and `shared` encrypted `directory` remotes and to decrypt items for `hybrid`, `shared`, and `pubkey` encrypted `directory` remotes (and presumably other special remotes but I tested with `directory` remotes since those were simplest). The only thing I have not been able to get to work is the generation of the encrypted item keys for `pubkey` remotes. Do you see what I am doing wrong for that case? Once I figure that out, I can make a tip entry on the wiki with the script.
+
+	#!/usr/bin/env bash
+
+	# args: file_path remote decrypt decrypt_path
+
+	# For shared, pubkey, and hybrid encryption:
+	# 1. Take in symlink and output encrypted key
+	# 2. Take in path to encrypted file and print decrypted file to stdout
+	#
+	# args: -r remote [-k symlink] [-d encrypted_file_path]
+
+	usage() {
+		echo \"Usage: ga_decrypt.sh -r REMOTE [-k SYMLINK] [-d FILE]\"
+		echo \"\"
+		echo \"    Either lookups up key on REMOTE for annex file linked with SYMLINK\"
+		echo \"    or decrypts FILE encrypted for REMOTE.\"
+		echo \"\"
+		echo \"    -r: REMOTE is special remote to use\"
+		echo \"    -k: SYMLINK is symlink in annex to print encrypted special remote key for\"
+		echo \"    -d: FILE is path to special remote file to decrypt to STDOUT\"
+		echo \"\"
+		echo \"NOTES: \"
+		echo \"    * Run in an indirect git annex repo.\"
+		echo \"    * Must specify -k or -d.\"
+		echo \"    * -k prints the key including the leading directory names used for a \"
+		echo \"       directory remote (even if REMOTE is not a directory remote)\"
+		echo \"    * -d works on a locally accessible file. It does not fetch a remote file\"
+		echo \"    * Must have gpg and openssl\"
+	}
+
+	decrypt_cipher() {
+		cipher=\"$1\"
+		echo \"$(echo -n \"$cipher\" | base64 -d | gpg --decrypt --quiet)\"
+	}
+
+	lookup_key() {
+		encryption=\"$1\"
+		cipher=\"$2\"
+		symlink=\"$3\"
+
+		if [ \"$encryption\" == \"hybrid\" ] || [ \"$encryption\" == \"pubkey\" ]; then
+			cipher=\"$(decrypt_cipher \"$cipher\")\"
+		fi
+
+		# Pull out MAC cipher from beginning of cipher
+		if [ \"$encryption\" = \"hybrid\" ] ; then
+			cipher=\"$(echo -n \"$cipher\" | head  -c 256 )\"
+		elif [ \"$encryption\" = \"shared\" ] ; then
+			cipher=\"$(echo -n \"$cipher\" | base64 -d | tr -d '\n' | head  -c 256 )\"
+		elif [ \"$encryption\" = \"pubkey\" ] ; then
+			# ???
+			: # Use entire base64 decrypted cipher
+			# cipher=\"$(echo -n \"$cipher\" | head  -c 256 )\"
+			# cipher=\"$(echo -n \"$cipher\" | base64 -d | tr -d '\n' | head  -c 256 )\"
+			# cipher=\"$(echo -n \"$cipher\" | base64 -d | tr -d '\n' )\"
+		fi
+
+		annex_key=\"$(basename \"$(readlink \"$symlink\")\")\"
+		hash=\"$(echo -n \"$annex_key\" | openssl dgst -sha1 -hmac \"$cipher\" | sed 's/(stdin)= //')\"
+		key=\"GPGHMACSHA1--$hash\"
+		checksum=\"$(echo -n $key | md5sum)\"
+		echo \"${checksum:0:3}/${checksum:3:3}/$key\"
+	}
+
+	decrypt_file() {
+		encryption=\"$1\"
+		cipher=\"$2\"
+		file_path=\"$3\"
+
+		if [ \"$encryption\" = \"pubkey\" ] ; then
+			gpg --quiet --decrypt \"${file_path}\"
+		else
+			if [ \"$encryption\" = \"hybrid\" ] ; then
+				cipher=\"$(decrypt_cipher \"$cipher\" | tail -c +257)\"
+			elif [ \"$encryption\" = \"shared\" ] ; then
+				cipher=\"$(echo -n \"$cipher\" | base64 -d | tr -d '\n' | tail  -c +257 )\"
+			fi
+			gpg --quiet --batch --passphrase \"$cipher\" --output - \"${file_path}\"
+		fi
+	}
+
+	main() {
+		OPTIND=1
+
+		mode=\"\"
+		remote=\"\"
+
+		while getopts \"r:k:d:\" opt; do
+			case \"$opt\" in
+				r)  remote=\"$OPTARG\"
+					;;
+				k)  if [ -z \"$mode\" ] ; then
+						mode=\"lookup key\"
+					else
+						usage
+						exit 2
+					fi
+					symlink=\"$OPTARG\"
+					;;
+				d)  if [ -z \"$mode\" ] ; then
+						mode=\"decrypt file\"
+					else
+						usage
+						exit 2
+					fi
+					file_path=\"$OPTARG\"
+					;;
+			esac
+		done
+
+		if [ -z \"$mode\" ] || [ -z \"$remote\" ] ; then
+			usage
+			exit 2
+		fi
+
+		shift $((OPTIND-1))
+
+		# Pull out config for desired remote name
+		remote_config=\"$(git show git-annex:remote.log | grep 'name='\"$remote \")\"
+
+		# Get encryption type and cipher from config
+		encryption=\"$(echo \"$remote_config\" | grep -oP 'encryption\=.*? ' | tr -d ' \n' | sed 's/encryption=//')\"
+		cipher=\"$(echo \"$remote_config\" | grep -oP 'cipher\=.*? ' | tr -d ' \n' | sed 's/cipher=//')\"
+
+		if [ \"$mode\" = \"lookup key\" ] ; then
+			lookup_key \"$encryption\" \"$cipher\" \"$symlink\"
+		elif [ \"$mode\" = \"decrypt file\" ] ; then
+			decrypt_file \"$encryption\" \"$cipher\" \"${file_path}\"
+		fi
+	}
+
+	main \"$@\"
+"""]]
diff --git a/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_7_b96077c98792997cdf344725374abb5c._comment b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_7_b96077c98792997cdf344725374abb5c._comment
new file mode 100644
index 0000000000..d43e118880
--- /dev/null
+++ b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_7_b96077c98792997cdf344725374abb5c._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2016-01-01T20:42:34Z"
+ content="""
+I think it's great you're working on this, and [[future_proofing]] is
+probably a good place to put the result.
+
+I did some digging, and the cipher used for pubkey includes a trailing
+new line. The trailing newline seems to be lost in your script, and
+adding it makes it work.
+
+	cipher="$cipher
+	"
+
+I think the actual problem in the script is in this line:
+
+	cipher="$(decrypt_cipher "$cipher")"
+
+I verified that decrypt_cipher outputs the trailing newline, but
+in capturing its output, the shell chomps it. Can't remember ATM if there's
+a way to avoid that in shell scripting.
+
+Arguably git-annex should not be treating that newline as part of the
+cipher text, although it's probably too late to change that, certainly for
+existing repositories..
+"""]]
diff --git a/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_8_e9597062bbc530920343e5159a7b7ea1._comment b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_8_e9597062bbc530920343e5159a7b7ea1._comment
new file mode 100644
index 0000000000..921d75e1c8
--- /dev/null
+++ b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_8_e9597062bbc530920343e5159a7b7ea1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d"
+ nickname="wsha.code+ga"
+ subject="comment 8"
+ date="2016-01-08T06:56:02Z"
+ content="""
+Thanks for spending the time to check the script. It would have taken me quite a while to catch that issue. I was also a little bit surprised that the hybrid encryption mode uses the base64 encoded cipher string while the shared encryption mode uses the cipher after decoding from base64.
+
+I can now reproduce the HMAC'ed keys and decrypt the files all the supported forms of encryption using openssl and gpg which makes me feel comfortable using them for long term storage.
+"""]]
diff --git a/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_9_756aeeee7be8cb67c5cc9dfa6ea7b82c._comment b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_9_756aeeee7be8cb67c5cc9dfa6ea7b82c._comment
new file mode 100644
index 0000000000..b58d3ce94b
--- /dev/null
+++ b/doc/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/comment_9_756aeeee7be8cb67c5cc9dfa6ea7b82c._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 9"
+ date="2018-07-15T23:59:42Z"
+ content="""
+I'm trying to add support for the sharedpubkey encryption scheme, and while decrypting the files is straight-forward, I cannot get the \"lookup_key\" function to work with this scheme. I tried the following:
+
+    # Pull out MAC cipher from beginning of cipher
+    if [ \"$encryption\" = \"hybrid\" ] ; then
+        cipher=\"$(echo -n \"$cipher\" | head  -c 256 )\"
+    elif [ \"$encryption\" = \"shared\" ] ; then
+        cipher=\"$(echo -n \"$cipher\" | base64 -d | tr -d '\n' | head  -c 256 )\"
+    elif [ \"$encryption\" = \"pubkey\" ] ; then
+        # pubkey cipher includes a trailing newline which was stripped in
+        # decrypt_cipher process substitution step above
+        IFS= read -rd '' cipher < <( printf \"$cipher\n\" )
+    elif [ \"$encryption\" = \"sharedpubkey\" ] ; then
+        cipher=\"$(echo -n \"$cipher\" | base64 -d | tr -d '\n' | head -c 256)\"
+    fi
+
+as well as many other variations (full cipher, no base 64 etc...) without success. The cipher is said to be unencrypted, so I guess it is base-64 encoded only. Would it be possible that an extra character has been added to the cipher like in the \"pubkey\" encryption scheme ?
+
+My tests are done in a directory special remote, sharedpubkey encryption, no chunks, a single test file in the repository.
+"""]]
diff --git a/doc/forum/Fuzzy_local_sensitive_hashing___40__LSH__41__.mdwn b/doc/forum/Fuzzy_local_sensitive_hashing___40__LSH__41__.mdwn
new file mode 100644
index 0000000000..0f1c488722
--- /dev/null
+++ b/doc/forum/Fuzzy_local_sensitive_hashing___40__LSH__41__.mdwn
@@ -0,0 +1,9 @@
+For some file types, e.g. images and sound, I would like to also add some local sensitive hash (LSH), and be able to find duplicates that way. E.g. that would allow me to find duplicate images where the image metadata was changed, or maybe the quality was changed, etc.
+
+Ideally, I would want to add such meta data to Git-Annex. I'm not sure if this should be a backend ([[backends]]) or kept separate from it (as there will be collisions, by design).
+
+I also want fast lookups for some specific hash. I'm not sure if the Git-Annex metadata allow for that? A Git-Annex backend naturally has this feature, but then how would it handle collisions? I would want that this LSH backend just links to a list of matching files, i.e. symlinks to the real files (via SHA backend or so).
+
+Is anything like that already supported?
+
+If not, would it be possible to add such support to Git-Annex? How?
diff --git a/doc/forum/Fuzzy_local_sensitive_hashing___40__LSH__41__/comment_1_29f2396e04251d266b68ba68b8b32215._comment b/doc/forum/Fuzzy_local_sensitive_hashing___40__LSH__41__/comment_1_29f2396e04251d266b68ba68b8b32215._comment
new file mode 100644
index 0000000000..e7973749a6
--- /dev/null
+++ b/doc/forum/Fuzzy_local_sensitive_hashing___40__LSH__41__/comment_1_29f2396e04251d266b68ba68b8b32215._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="seanl@fe5df935169a5440a52bdbfc5fece85cdd002d68"
+ nickname="seanl"
+ avatar="http://cdn.libravatar.org/avatar/082ffc523e71e18c45395e6115b3b373"
+ subject="Different use case from backend"
+ date="2021-01-29T17:35:43Z"
+ content="""
+One of the requirements of the backend is that a collision means the content is identical, so it's trivial to handle them because it doesn't matter which one you keep. For dealing with \"near duplicates\", I'd suggest adding a field with `git annex metadata -s lsh=$(lsh $filename)` or something like that. The metadata is attached to the file's content rather than the name, which will ensure that the LSH gets recomputed if the content changes and will never get computed more than once for identical content.
+
+I think the main drawback of this method is that it's a little more complicated to print metadata en masse than it is to print the key because `git annex find` doesn't support metadata. It's certainly possible to construct a command to do it, it's just a little more involved than the commands for finding duplicates.
+"""]]
diff --git a/doc/forum/GIT__95__SSH.mdwn b/doc/forum/GIT__95__SSH.mdwn
new file mode 100644
index 0000000000..968385d084
--- /dev/null
+++ b/doc/forum/GIT__95__SSH.mdwn
@@ -0,0 +1,3 @@
+Is there any way to get git-annex to respect the GIT_SSH environment variable just like git?  This would be super helpful for specifying ssh options (keys in my application)
+
+Hacks like a ~/.ssh/config with a fake hostname to specify the key are not appropriate in my case, because keys are generated on the fly by a server-side application that may be distributed across multiple servers.  So I really need to be able to specify a key file at run time and then use the normal remote URI.  I can do this with git and GIT_SSH, but have not found a solution for git-annex yet.
diff --git a/doc/forum/GIT__95__SSH/comment_1_c2e827eeac7524845cad42671d77af95._comment b/doc/forum/GIT__95__SSH/comment_1_c2e827eeac7524845cad42671d77af95._comment
new file mode 100644
index 0000000000..baced499e7
--- /dev/null
+++ b/doc/forum/GIT__95__SSH/comment_1_c2e827eeac7524845cad42671d77af95._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-17T17:26:56Z"
+ content="""
+I've added support for this now.
+
+However, since git's interface to this doesn't let any options other than
+-p be passed to the command run by this, git-annex can't either. Which
+means it can't pass options for ssh connection caching. So, I'm afraid that
+using `GIT_SSH` will slow things down somewhat. Of course, you can always
+enable ssh connection caching yourself in either the `GIT_SSH` script or
+the ssh configuration.
+"""]]
diff --git a/doc/forum/GPG_passphrase_handling.mdwn b/doc/forum/GPG_passphrase_handling.mdwn
new file mode 100644
index 0000000000..3f3bc79f1a
--- /dev/null
+++ b/doc/forum/GPG_passphrase_handling.mdwn
@@ -0,0 +1,78 @@
+[[!meta title="GPG passphrase handling on OSX"]]
+
+Hello!
+I'm using OSX 10.9 and have installed gpg (and gpg2, if it matters) through
+homebrew and git-annex through cabal. I also installed
+https://github.com/joeyh/git-remote-gcrypt like the UI told me.
+
+Whenever I'm trying to add an encrypted remote through the web UI I get a
+lot of "You need a passphrase to unlock the secret key for user:" on stdout
+and, obviously, I can't enter my passphrase (If I could I wouldn't make this
+post to begin with :))
+Is this behavior normal? What should I do to work around it?
+I did also try to not use the web UI by using this command:
+git annex initremote rsync.net type=gcrypt gitrepo=user@host:directory encryption=pubkey keyid=X
+
+Because of this I can't copy files to my remotes. All I get is:
+-----
+$ git annex copy --to rsync.net
+copy MySecretFile (gpg) 
+You need a passphrase to unlock the secret key for
+user: "user"
+4096-bit RSA key, ID X, created 2013-10-01 (main key ID Y)
+
+(checking rsync.net...) (to rsync.net...) gpg: no valid addressees
+gpg: [stdin]: encryption failed: No user ID
+failed
+-----
+
+Yes, I am using gpg-agent. When other applications ask for my passphrase I get
+the pinentry dialog from GPGTools, just like I've configured it in
+~/.gnupg/gpg-agent.conf, but this isn't the case with git-annex.
+
+If I remove GPGTools from /usr/local/bin with: ``brew link --overwrite gnupg &&
+brew link --overwrite gnupg2'' it works *slightly* better. 
+I get that pinentry dialog I want but when I do a copy I get:
+-----
+$ git annex copy --to rsync.net
+copy MySecretFile (gpg) (checking rsync.net...) (to rsync.net...) gpg: no valid addressees
+gpg: [stdin]: encryption failed: no such user id
+failed
+-----
+
+--debug shows me it is executing gpg llke so:
+-----
+gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--batch","--encrypt","--no-encrypt-to","--no-default-recipient","--force-mdc","--no-textmode"]
+-----
+
+$ git annex version
+git-annex version: 4.20131024
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav glacier hook
+
+$ gpg --version
+gpg (GnuPG) 2.0.22
+libgcrypt 1.5.3
+Copyright (C) 2013 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+
+Home: ~/.gnupg
+Supported algorithms:
+Pubkey: RSA, ELG, DSA, ?, ?
+Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
+        CAMELLIA128, CAMELLIA192, CAMELLIA256
+Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
+Compression: Uncompressed, ZIP, ZLIB, BZIP2
+
+ $ gpg-agent --version
+gpg-agent (GnuPG/MacGPG2) 2.0.22
+libgcrypt 1.5.3
+Copyright (C) 2013 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+
+[[!tag forumbug]] [[bugs/done]]
diff --git a/doc/forum/GPG_passphrase_handling/comment_1_11ba130e8bea6698858d0a1a5b01830f._comment b/doc/forum/GPG_passphrase_handling/comment_1_11ba130e8bea6698858d0a1a5b01830f._comment
new file mode 100644
index 0000000000..f2709f18cc
--- /dev/null
+++ b/doc/forum/GPG_passphrase_handling/comment_1_11ba130e8bea6698858d0a1a5b01830f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw"
+ nickname="dxtrish"
+ subject="comment 1"
+ date="2013-10-31T00:06:22Z"
+ content="""
+In fact I just tried this with a key without a passphrase and I STILL get:
+
+[2013-10-31 01:00:50 CET] Pusher: Syncing with rsync.net 
+gpg: no valid addressees
+gpg: [stdin]: encryption failed: no such user id
+
+In addition I also noticed a lot of:
+git-annex: fd:28: hPutBuf: resource vanished (Broken pipe)
+"""]]
diff --git a/doc/forum/GPG_passphrase_handling/comment_2_ef9d58d15b7bbe0b3c7140bb01d73a31._comment b/doc/forum/GPG_passphrase_handling/comment_2_ef9d58d15b7bbe0b3c7140bb01d73a31._comment
new file mode 100644
index 0000000000..d15248ab7a
--- /dev/null
+++ b/doc/forum/GPG_passphrase_handling/comment_2_ef9d58d15b7bbe0b3c7140bb01d73a31._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw"
+ nickname="dxtrish"
+ subject="comment 2"
+ date="2013-10-31T02:42:47Z"
+ content="""
+I think I have found two ways I can make this happen.
+
+1) If a filename contains UTF-8 it seems to happen (At least with this specific filename I have right here)
+
+2) Finder.app does not seem to play nice with git-annex (I got the same error when I tried using Finder to copy files to my git-annex thing)
+
+
+
+"""]]
diff --git a/doc/forum/GPG_passphrase_handling/comment_3_84eb129c8483b87b3ae6ecaf8b4a8309._comment b/doc/forum/GPG_passphrase_handling/comment_3_84eb129c8483b87b3ae6ecaf8b4a8309._comment
new file mode 100644
index 0000000000..298e2f13d2
--- /dev/null
+++ b/doc/forum/GPG_passphrase_handling/comment_3_84eb129c8483b87b3ae6ecaf8b4a8309._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 3"
+ date="2013-11-02T20:39:36Z"
+ content="""
+There seem to be a lot of different ways to install gpg on OSX, with different results in what works and not. I don't know what's going on with that. Advice from those who understand Mac OS would be appreciated.
+
+As far as the \"gpg: no valid addressees\" bug goes, I can reproduce it on Linux, and have fixed it. Only affected using gcrypt with encryption=pubkey.
+
+(Please file bug reports in [[bugs]] in the future, not in the forum!)
+"""]]
diff --git a/doc/forum/GPG_passphrase_handling/comment_4_8724297f6d7ac140ab395a940bab0d7d._comment b/doc/forum/GPG_passphrase_handling/comment_4_8724297f6d7ac140ab395a940bab0d7d._comment
new file mode 100644
index 0000000000..983c35c3ab
--- /dev/null
+++ b/doc/forum/GPG_passphrase_handling/comment_4_8724297f6d7ac140ab395a940bab0d7d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw"
+ nickname="dxtrish"
+ subject="comment 4"
+ date="2013-11-03T13:10:11Z"
+ content="""
+I would have filed it in the bug section if I knew it was a bug. I just thought I had done something wrong :)
+"""]]
diff --git a/doc/forum/General_questions_and_help.mdwn b/doc/forum/General_questions_and_help.mdwn
new file mode 100644
index 0000000000..c4456a6491
--- /dev/null
+++ b/doc/forum/General_questions_and_help.mdwn
@@ -0,0 +1,9 @@
+I've been using git annex for the last few months and there are a lot of things I really like about it, but I continue to run into frustration after frustration and it is really hampering my experience with it.  I'm not sure if the frustration is coming from my ignorance, inexperience, the fact I'm using it on a windows machine, or whether I have unrealistic expectations for it.  Let me explain how I'm currently using it, and maybe people have suggestions on how I can make my experience more fluid.  
+
+Currently I have a several annex repos on my laptop and copies on two separate hard drives.  Over the course of a week I'll add and refer to stuff in the annex repos on my laptop, and then once per week I'll sync the repos with my external hard drives and remove content from my laptop to free up space.  Eventually, I'd like to write a script to handle the syncing process.  
+
+I continue to have issues.  A few weeks ago I accidentally added large files straight into git and not knowing or understanding the documentation enough to remove them I eventually just removed and recloned the repo. To this week, being unable to sync my repos due to filenames that are too long. I know neither of these examples are really issues with annex itself, but they are issues which have come up while using annex which gives me bad mental associations with it.  
+
+I guess this is more venting frustration and looking for guidance rather than a specific question.  I've read through much of the documentation, but do I need an understanding of the internals of git and git annex so when something goes wrong I know how to fix it?  Where is a good place to start learning these?  There have now been a couple issues around being on a windows machine, is it even worth using git annex on a windows machine?  Do people have any tips on how I'm using git annex which may make my experience better, like a different workflow or something?
+
+(I'm still having the filenames issue, which from what I can tell the only real solution is changing the name.  If anyone knows a better solution it would be appreciated)
diff --git a/doc/forum/General_questions_and_help/comment_1_adfef0ecc191dd2ad85b4e0f6a4df67d._comment b/doc/forum/General_questions_and_help/comment_1_adfef0ecc191dd2ad85b4e0f6a4df67d._comment
new file mode 100644
index 0000000000..8635f7c050
--- /dev/null
+++ b/doc/forum/General_questions_and_help/comment_1_adfef0ecc191dd2ad85b4e0f6a4df67d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-08-03T07:54:12Z"
+ content="""
+Hi,<br>
+What may help with the filenames too long is putting the repository directly under `C:` like `C:\repo`. The reason is that Windows paths are limited to a maximum of 260? bytes and if you have it under like `C:\Users\bla\loong\path\repo` then the whole path to the keys (`C:\Users\bla\loong\path\repo\.git\annex\objects\xyz\xyz\SHA256E-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`) might be too long. <br>
+You could also try with a different [[backends]] like `SHA1` since then the hash part (`SHA256E-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`) is shorter.
+"""]]
diff --git a/doc/forum/General_questions_and_help/comment_2_972231014d3da4fcd8fb2a77d76e7b77._comment b/doc/forum/General_questions_and_help/comment_2_972231014d3da4fcd8fb2a77d76e7b77._comment
new file mode 100644
index 0000000000..e1ac589bd2
--- /dev/null
+++ b/doc/forum/General_questions_and_help/comment_2_972231014d3da4fcd8fb2a77d76e7b77._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="don't give up ;)"
+ date="2021-08-03T15:06:35Z"
+ content="""
+There's a learning curve, especially around the areas you mention.   I think the rules for which files go into annex vs git have evolved in a somewhat ad-hoc way as @joeyh did his best to reconcile people's different use cases, so ended up being somewhat complex.  It may be worth taking the time to read the [[main page|git-annex]] top-to-bottom once, especially the config options, and also the [[internals]] page.  You can tag git branches when things are in a good state so you can later reset them if anything goes wrong; note though that you'd want to tag the git-annex branch and any `synced/*` branches as well.
+
+I've tried using git-annex on Windows and gave up, using it inside an Ubuntu guest VM via VirtualBox, but I think others have successfully used it on Windows.  Overall I've found git-annex to be very reliable and adaptable to almost any scenario, and these forums helpful.   The issues I've had with git-annex have been mostly around slowness on large repos, but recent releases have made strides to address that.
+"""]]
diff --git a/doc/forum/General_questions_and_help/comment_3_1a071d4a7e62701c47d8531c4faa9dcb._comment b/doc/forum/General_questions_and_help/comment_3_1a071d4a7e62701c47d8531c4faa9dcb._comment
new file mode 100644
index 0000000000..9f887877d1
--- /dev/null
+++ b/doc/forum/General_questions_and_help/comment_3_1a071d4a7e62701c47d8531c4faa9dcb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2021-08-03T15:14:52Z"
+ content="""
+>tried using git-annex on Windows and gave up, using it inside an Ubuntu guest VM via VirtualBox
+
+I meant, I ended up using it *instead* inside an Ubuntu guest VM via VirtualBox, and that has worked very well.   The only caveat is that the files have to be stored inside VirtualBox volumes; trying to access Windows files via shared folder [[runs into VirtualBox filesystem issues|bugs/removeLink_failed_when_initializing_a_repo_in_a_VirtualBox_shared_folder]].
+"""]]
diff --git a/doc/forum/General_questions_and_help/comment_4_51b8cd9f1b8b53bcf880ea56d1858f23._comment b/doc/forum/General_questions_and_help/comment_4_51b8cd9f1b8b53bcf880ea56d1858f23._comment
new file mode 100644
index 0000000000..503567d6f5
--- /dev/null
+++ b/doc/forum/General_questions_and_help/comment_4_51b8cd9f1b8b53bcf880ea56d1858f23._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="jwrauch"
+ avatar="http://cdn.libravatar.org/avatar/0e83010187ef0c8c587e0c99e2ca5474"
+ subject="comment 4"
+ date="2021-08-03T16:36:20Z"
+ content="""
+Thanks for the support guys!  I really appreciate knowing that others have struggled with similar issues and I'm not giving up yet.  
+
+@Lukey That's a great idea, except I'm already doing that.  The issue really wasn't to do with annex, as it wasn't the hash files names.  I was downloading torrent files directly to the annex so I could keep the torrent link active without keeping two copies of the files.  But torrent filenames are packed with information and thus long, leading to my issue.  I just changed the filename and broke the torrent link.  Frustrating, but ultimately not really a big deal. Thanks for the suggestion though.
+
+@Ilya_Shlyakhter Thanks for the support.  I'll go through the Main Page again as well as that Internals page.  I think I skipped the Internals page when I was going through the documentation a few months ago, but looking at it now it looks pretty illuminating.  I'll also check out using a VM, but I may just decide to make the jump to linux and use a windows VM there.  
+
+"""]]
diff --git a/doc/forum/General_questions_and_help/comment_5_0105e241e13f9469bf749735cb9f3e03._comment b/doc/forum/General_questions_and_help/comment_5_0105e241e13f9469bf749735cb9f3e03._comment
new file mode 100644
index 0000000000..516d429545
--- /dev/null
+++ b/doc/forum/General_questions_and_help/comment_5_0105e241e13f9469bf749735cb9f3e03._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="downloading torrent files to annex"
+ date="2021-08-04T15:47:11Z"
+ content="""
+>I was downloading torrent files directly to the annex
+
+Not sure if you're already using it, but there is a [[bittorrent special remote|special_remotes/bittorrent]] (haven't tried it myself).
+"""]]
diff --git a/doc/forum/Generating_a_Temp_View_of_Available_Files.mdwn b/doc/forum/Generating_a_Temp_View_of_Available_Files.mdwn
new file mode 100644
index 0000000000..bdb8ece692
--- /dev/null
+++ b/doc/forum/Generating_a_Temp_View_of_Available_Files.mdwn
@@ -0,0 +1 @@
+Is it possible to generate a view of files currently available on the annex? My use case is that I have pretty large repo (couple of TBs) and I have partial checkouts on multiple machines instead of seeing 100s of broken symlinks I would like to just filter filter files that are present on the machine?
diff --git a/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant.mdwn b/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant.mdwn
new file mode 100644
index 0000000000..be87682225
--- /dev/null
+++ b/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant.mdwn
@@ -0,0 +1,88 @@
+Hi,
+
+I'm trying to get my head around groups, wanted, etc. for a particular use case.
+
+**Problem:** I can't work out how to get a source(?) repository to automatically drop files when they hit a transfer repository.
+
+
+I have a machine (`Machine 1`) that is used for data acquisition but it is behind a strict firewall (both physical and virtual).  I usually physically carry a USB drive over, set up a rsync ssh -> local-USB-drive from the one machine (`Machine 2`) that is able to connect over the network to `Machine 1`.  As it is a pain to lug the drive over, I only do this rsync maybe weekly, so the rsync takes many hours (~24) to complete.  Then (when I remember) I visit and I carry the USB drive back...  Naturally, this slows down my work process.
+
+What I was hoping to do was set up git-annex with the assistant to help me.  I am able to run the assistant, but not the webapp on `Machines 1 and 2`.  :-(
+
+My thought was - as these have to be disconnected network transfers...
+
+- `Repository 1 -> Repository 2` (when space permits)
+- `Repository 2 -> Repository 3` (when space permits) `-> Repository 4` (USB drive(s))
+
+
+Another limitation is that `Repos/Machines 2 & 3` have limited storage space.
+
+
+As a test case I can set up (`Repo1 -> Repo2`) and (`Repo2 -> Repo3`) (on other machines, but the commands should be the same...)
+
+After reading a bit I made a changed [preferred content](/preferred_content/standard_groups/) for a transfer repo to:
+
+```
+not (inallgroup=client and copies=client:1) and ($client)
+```
+
+i.e. `copies` from `2` to `1`.
+ 
+---
+
+
+Finally...The question
+----------------------
+
+**BUT** I can't work out how to get `Repo1` (the source) to automatically drop the files when they hit `Repo2` (what I'm guessing should be a transfer repository).
+
+Can anyone suggest how to automagically do this with the assistant?
+
+
+---
+
+
+If it would help I can share the git-annex commands I've been using, but as I'm only doing testing up at the moment, I'm happy to start from scratch if there is a RTFM page out there.  :-)
+
+
+I've put some details about my thoughts on the repositories and restrictions below.
+
+
+Thanks - Olaf
+
+
+
+
+Repository 1
+------------
+- Type: source (Data collection)
+- Human readable directory structure
+- Physically: Machine 1
+- Strict firewall only incoming network connections from Machine 2
+- Storage: 50Gb
+
+
+Repository 2
+------------
+- Type: transfer
+- Physically: Machine 2
+- Reasonably relaxed firewall, can talk to Repository 3
+- Limited storage: 10Gb
+
+
+Repository 3
+------------
+- Type: transfer
+- Pysically: Machine 3
+- Reasonably relaxed firewall, can talk to Repository 2
+- Limited storage: 10Gb
+- Connected to USB drive(s)
+
+
+Repository 4, 5, ...
+--------------------
+- Type: ? Client ?
+- Human readable directory structure
+- Physically: USB drive
+- Usually (but not always) connected to machine 3
+- Large storage (2Tb) + Additional drives
diff --git a/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_1_ead4b5b7ec0d085d4fa87fb4e29c4d55._comment b/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_1_ead4b5b7ec0d085d4fa87fb4e29c4d55._comment
new file mode 100644
index 0000000000..dec09cf28c
--- /dev/null
+++ b/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_1_ead4b5b7ec0d085d4fa87fb4e29c4d55._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-05-11T16:06:03Z"
+ content="""
+Sounds like an interesting data-gathering application, I have to say
+I'm curious what it is. ;)
+
+If Repo1 is configured like this:
+
+	git-annex group here source
+	git annex wanted here standard
+
+Then it should want to drop the contents of files from Repo1 once it knows
+they have reached any other repository. (Sometimes people put a repository
+in a group but forget to set wanted to "standard" ...)
+
+Looks like Repo1 cannot make outgoing connections to Repo2?
+
+So, you need to run the assistant on Repo2 and probably on Repo1.
+Then it works like this:
+
+1. The assistant on Repo1 will commit files as they're put in the repository.
+2. The assistant on Repo2 will notice changes to Repo1, pull down the
+   files, see that Repo1 is configured as a source repository, and drop
+   the files from Repo1.
+3. The assistant on Repo1 will also notice when it's sent a file to Repo2
+   and can drop it from Repo1 then -- but this may take a while for it to
+   notice and #2 will probably happen first.
+
+Note that if you get the files added and committed by some other process,
+you don't really need to run the assistant on Repo1.
+
+The USB drives need to be client, so that once content reaches one of them,
+the content will be dropped from the transfer repositories. The way that
+part should work:
+
+1. Content reaches Repo2.
+2. The assistant in Repo3 notices the change to Repo2, pulls down
+   the files.
+3. The assistant in Repo3 pushes the files to a connected USB drive.
+4. The assistant in Repo3 drops content from itself and Repo2, since
+   it knows both are transfer repos and the content has reached a client
+   (USB).
+
+If you're having trouble getting any of this to work, I recommend
+running `git annex sync --content` manually while testing it, and make sure
+it does what you would expect to happen at each step.
+"""]]
diff --git a/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_2_835dba9de7a5eea868635dc793d4e75b._comment b/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_2_835dba9de7a5eea868635dc793d4e75b._comment
new file mode 100644
index 0000000000..34d3b46ec7
--- /dev/null
+++ b/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_2_835dba9de7a5eea868635dc793d4e75b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="leavingchicago@c04c893e78d1c4c76cb3e32b5c227cf42bbf7682"
+ nickname="leavingchicago"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="comment 2"
+ date="2017-05-11T23:23:45Z"
+ content="""
+&lt;ASIDE&gt;</br>
+*Laughing* I wish the data collection was interesting.  Just a machine with locked down networking so that it's a tad more secure.  Closest example is an EC2 instance sitting in a VPC...</br> 
+&lt;/ASIDE&gt;
+
+Thanks for the feedback Joey.  I tried again and this approach works **except** where the downstream repo is direct mode - in this case the transfer repo doesn't drop.  I'm not sure if it's a bug or a feature I didn't read about.
+
+Happy to submit a bug report with steps if it's unexpected.
+"""]]
diff --git a/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_3_553542a4a2b2530863a006a1afe91637._comment b/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_3_553542a4a2b2530863a006a1afe91637._comment
new file mode 100644
index 0000000000..3f3dae5673
--- /dev/null
+++ b/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_3_553542a4a2b2530863a006a1afe91637._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="olaf"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="comment 3"
+ date="2017-05-11T23:45:36Z"
+ content="""
+Oops.  I committed the greatest sin...
+
+```
+git-annex version: 6.20170321-gf3dee9d65
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux i386
+```
+"""]]
diff --git a/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_4_4540a15672f9b48b0f9310c97f1a0b86._comment b/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_4_4540a15672f9b48b0f9310c97f1a0b86._comment
new file mode 100644
index 0000000000..0c69fd562c
--- /dev/null
+++ b/doc/forum/Get___39__source__39___group_to_automatically_drop_with_assistant/comment_4_4540a15672f9b48b0f9310c97f1a0b86._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-06-07T16:30:29Z"
+ content="""
+I would not expect the behavior with a direct mode repo to be any
+different. Unless the file in direct mode is getting modified, or
+perhaps git-annex gets confused and thinks it's modified. Either would
+prevent dropping the content from the transfer repository to avoid losing
+the unmodified content.
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__.mdwn b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__.mdwn
new file mode 100644
index 0000000000..9dba66be4a
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__.mdwn
@@ -0,0 +1,83 @@
+In DataLad, there are some dotfiles that we want to annex
+(e.g. `.datalad/metadata/objects/*`), so we need to set
+`annex.dotfiles=true`.  Ideally that would be in effect for annex
+commands that DataLad executes without setting `annex.dotfiles=true`
+in the repo.  DataLad configuring `annex.dotfiles` in the repo seems
+problematic because the change in behavior would be surprising to
+users that call `git annex add` directly.  And more generally, DataLad
+should be able to operate in existing git(-annex) repos without
+changing configuration values in the background.
+
+That reasoning leads to using `-c annex.dotfiles=true` in our calls to
+git-annex.  By doing that combined with `--force-large`, we can make
+`git annex add` send a dotfile to the annex.  However, if the file is
+later unlocked, it switches to being store in git, presumably when the
+clean filter runs.  The script below provides a concrete example of
+this when running on an unlocked adjusted branch.
+
+So, I think this is expected behavior.  `annex.dotfiles=true` is no
+longer in effect when the clean filter runs, and the dotfile goes into
+git instead.  The only way I can think of to work around this
+annex->git conversion is to set `annex.dotfiles=true` in the repo.
+But, as I mentioned in the first paragraph, I'm hoping to avoid that.
+Is there another solution that I'm overlooking?
+
+
+[[!format sh """
+#!/bin/sh
+
+set -eux
+
+cd "$(mktemp -d --tmpdir gx-XXXXXXX)"
+
+echo $(git annex version --raw)
+git init
+git annex init
+git commit --allow-empty -mc0
+git annex adjust --unlock
+
+echo one >.dot
+git annex add -c annex.dotfiles=true --force-large .dot
+git commit -mdot
+git diff
+"""]]
+
+```
++ mktemp -d --tmpdir gx-XXXXXXX
++ cd /tmp/gx-dVCRKik
++ git annex version --raw
++ echo 8.20200226
+8.20200226
++ git init
+Initialized empty Git repository in /tmp/gx-dVCRKik/.git/
++ git annex init
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
++ git commit --allow-empty -mc0
+[master (root-commit) 594fa63] c0
++ git annex adjust --unlock
+adjust
+Switched to branch 'adjusted/master(unlocked)'
+ok
++ echo one
++ git annex add -c annex.dotfiles=true --force-large .dot
+add .dot
+ok
+(recording state in git...)
++ git commit -mdot
+[adjusted/master(unlocked) 826ad5d] dot
+ 1 file changed, 1 insertion(+)
+ create mode 100644 .dot
++ git diff
+diff --git a/.dot b/.dot
+index 9a70ce7..5626abf 100644
+--- a/.dot
++++ b/.dot
+@@ -1 +1 @@
+-/annex/objects/SHA256E-s4--2c8b08da5ce60398e1f19af0e5dccc744df274b826abe585eaba68c525434806.dot
++one
+```
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_10_0ae170680841f86279b95febaafa0440._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_10_0ae170680841f86279b95febaafa0440._comment
new file mode 100644
index 0000000000..4fd74df20a
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_10_0ae170680841f86279b95febaafa0440._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 10"
+ date="2020-03-09T19:05:08Z"
+ content="""
+\"seems to have installed a new git in the conda env (see conda list below), but for whatever reason, invoking git still reaches outside the conda env\" -- that's really strange; at this point I'd consider re-installing Miniconda from scratch, updating conda to the current version, creating a datalad env from scratch, and seeing if the oddity goes away.
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_11_1f46bcb05d7866af35779830ceb632e2._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_11_1f46bcb05d7866af35779830ceb632e2._comment
new file mode 100644
index 0000000000..b8a934e587
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_11_1f46bcb05d7866af35779830ceb632e2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="sam.nastase@2b4a9b3e5094dab41e0a4de0b808a2697a3e9860"
+ nickname="sam.nastase"
+ avatar="http://cdn.libravatar.org/avatar/55c74b521bcb7322069f35bf655f81e0"
+ subject="comment 11"
+ date="2020-03-09T22:43:56Z"
+ content="""
+I'm on an institutional server and don't have admin privileges, so I'm using the existing conda (v4.7.5) installation and installing datalad with `conda install -c conda-forge datalad`. On a second try, can confirm that `git` is not listed among the conda `NEW packages that will be INSTALLED`, although it does get `git-annex conda-forge/linux-64::git-annex-8.20200226-nodep_h1234567_1` (as well as `gitdb` and `gitpython`). Conda env still points to the external git installation. Running the conda version of `datalad save` gives me the `Invalid option `--include-dotfiles'` error, so I install from GitHub with `pip install git+https://github.com/datalad/datalad.git`. However, this doesn't seem to change anything (I think this is why I ended up conda uninstalling datalad previouosly). Is there away to ensure the version installed from GitHub via pip takes precedence?
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_12_177db535bf756cfb4c231a41cd02e137._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_12_177db535bf756cfb4c231a41cd02e137._comment
new file mode 100644
index 0000000000..429ce3b8ca
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_12_177db535bf756cfb4c231a41cd02e137._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 12"
+ date="2020-03-10T00:17:46Z"
+ content="""
+Try creating a fresh env with git-annex (conda create -c conda-forge -n datalad-env git-annex) then pip-installing datalad into that.
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_13_cb4f95866113ac6f689ed9f219a1d8e1._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_13_cb4f95866113ac6f689ed9f219a1d8e1._comment
new file mode 100644
index 0000000000..0122a4b630
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_13_cb4f95866113ac6f689ed9f219a1d8e1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="conda"
+ date="2020-03-10T17:16:31Z"
+ content="""
+Did it work?
+I wonder why you got the standalone (nodep) git-annex build in your environment -- this should only happen when package conflicts prevent the normal package from getting installed.
+When you create a fresh env with git-annex, which package version do you get?
+
+\"don't have admin privileges, so I'm using the existing conda (v4.7.5) installation\" -- with [[install/conda]] you don't need admin privileges, you can get the [installer](https://docs.conda.io/en/latest/miniconda.html#linux-installers) and install it in your own dir.
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_14_748a794bf4cda242923177352e34976c._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_14_748a794bf4cda242923177352e34976c._comment
new file mode 100644
index 0000000000..04e8eac76d
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_14_748a794bf4cda242923177352e34976c._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="sam.nastase@2b4a9b3e5094dab41e0a4de0b808a2697a3e9860"
+ nickname="sam.nastase"
+ avatar="http://cdn.libravatar.org/avatar/55c74b521bcb7322069f35bf655f81e0"
+ subject="comment 14"
+ date="2020-03-10T19:04:34Z"
+ content="""
+Oh right, good point about conda. Although I'm not sure why using a new installation of miniconda would make any difference relative to using the system's conda. When running `conda create -c conda-forge -n datalad-env git-annex` it wants to install:
+    git conda-forge/linux-64::git-2.25.0-pl526hce37bd2_0
+    git-annex conda-forge/linux-64::git-annex-8.20200226-hfc01302_101
+
+I think I understand the git version issue now. I had requested admin update git (v1.8), so they had me sourcing some environment variables pointing to a newer version (v2.9). Apparently this was overriding the conda git installation; when I started from scratch on the server, it correctly uses git v2.25 rather than v1.8.
+
+Following your recipe, I needed a `conda install pip`, then pip installed DataLad from GitHub. However, I'm still running against the previous error:
+
+    CommandError: 'git-annex add -c annex.dotfiles=true --json --json-error-messages -- CHANGES README dataset_description.json derivatives/fmriprep derivatives/freesurfer derivatives/logs participants.tsv sub-002/sub-002_scans.tsv
+
+...listing many files, then:
+
+    sub-315/sub-315_scans.tsv' failed with exitcode 1 under /mnt/bucket/labs/hasson/snastase/narratives
+    git-annex: Repository /mnt/bucket/labs/hasson/snastase/narratives is at unsupported version 7. Automatic upgrade exception! derivatives/mriqc: getSymbolicLinkStatus: does not exist (No such file or directory)
+
+Am I just missing some step in the workflow? If there's no obvious solution, I can probably just re-create the entire datalad dataset from scratch with the new software versions in this conda env.
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_15_994e3e64184a020f9afe21cd9ea34b38._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_15_994e3e64184a020f9afe21cd9ea34b38._comment
new file mode 100644
index 0000000000..1ca5856eac
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_15_994e3e64184a020f9afe21cd9ea34b38._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 15"
+ date="2020-03-10T19:30:50Z"
+ content="""
+> If there's no obvious solution, I can probably just re-create the entire datalad dataset from scratch with the new software versions in this conda env.
+
+It's not obvious to me why an uninstalled subdataset would be causing issues with the repo upgrade process.  Quickly trying, I can't trigger an issue, but perhaps the submodule got into some weird, not-really-removed state.  You can open an issue on DataLad's side and we can try to debug it, though doing so might be tricky without a recipe to trigger it.
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_1_b215a9ab1c37688cc22dbe4ec63347ad._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_1_b215a9ab1c37688cc22dbe4ec63347ad._comment
new file mode 100644
index 0000000000..0374f30914
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_1_b215a9ab1c37688cc22dbe4ec63347ad._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="annexing only large dotfiles"
+ date="2020-03-05T19:31:37Z"
+ content="""
+Maybe, set `annex.dotfiles=true`, then in `.gitattributes` at repo root put `.* annex.largefiles=nothing`, and in .gitattributes under .datalad put `.* annex.largefiles=anything`?
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_2_15de9ba04480697bdf4086cdf91226e4._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_2_15de9ba04480697bdf4086cdf91226e4._comment
new file mode 100644
index 0000000000..71d9aa7e2a
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_2_15de9ba04480697bdf4086cdf91226e4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="re: annexing only large dotfiles"
+ date="2020-03-05T19:56:50Z"
+ content="""
+Thanks for the reply, Ilya.  Sorry, I think my mention of `.datalad/`
+along with an example that used a top-level dotfile was unnecessarily
+confusing.  It's not an issue of sending some files dotfiles to annex
+and some to git.  It's just wanting to avoid setting `annex.dotfiles`
+in `.git/config` (or `git-annex:config.log`) of the repos that DataLad
+touches.
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_3_f642798f8d1c753dca3aad67d0bd9ace._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_3_f642798f8d1c753dca3aad67d0bd9ace._comment
new file mode 100644
index 0000000000..56aab94242
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_3_f642798f8d1c753dca3aad67d0bd9ace._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="sam.nastase@2b4a9b3e5094dab41e0a4de0b808a2697a3e9860"
+ nickname="sam.nastase"
+ avatar="http://cdn.libravatar.org/avatar/55c74b521bcb7322069f35bf655f81e0"
+ subject="Invalid option `--include-dotfiles'"
+ date="2020-03-06T22:17:32Z"
+ content="""
+I just reinstalled DataLad (v0.12.2) via conda today and tried to do a `datalad save` on a preexisting datalad dataset and got previously unseen error with \"Invalid option `--include-dotfiles'\". Is this related to ongoing development? Or is there some easy fix? Thanks! (apologies if this is a poor place to post)
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_4_018442fba01a2aac43531f2eaecc1117._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_4_018442fba01a2aac43531f2eaecc1117._comment
new file mode 100644
index 0000000000..186743b910
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_4_018442fba01a2aac43531f2eaecc1117._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="re: Invalid option `--include-dotfiles'"
+ date="2020-03-06T22:56:35Z"
+ content="""
+DataLad has been updated for the removal of `--include-dotfiles` in
+the latest git-annex release (8.20200226), but there hasn't been a
+DataLad release yet that includes that fix.  So I'd say the easiest
+fix for now would be installing a developmental version of DataLad
+(both `master` and `maint` have the fix).  I think downgrading your
+git-annex version would be problematic because your repo has probably
+already been auto-upgraded to v8.
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_5_577c3dfc1f77ad0821ed8fcbbac3772c._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_5_577c3dfc1f77ad0821ed8fcbbac3772c._comment
new file mode 100644
index 0000000000..8808ba505a
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_5_577c3dfc1f77ad0821ed8fcbbac3772c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="sam.nastase@2b4a9b3e5094dab41e0a4de0b808a2697a3e9860"
+ nickname="sam.nastase"
+ avatar="http://cdn.libravatar.org/avatar/55c74b521bcb7322069f35bf655f81e0"
+ subject="comment 5"
+ date="2020-03-06T23:34:12Z"
+ content="""
+Thanks! This brings me to a new error due to our old version of git (v1.8.3), which apparently doesn't have the `--no-patch` flag for `git show`, but that's a separate issue.
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_6_7a3a21b3995f79710ebb5a8428709f66._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_6_7a3a21b3995f79710ebb5a8428709f66._comment
new file mode 100644
index 0000000000..1c5cc12391
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_6_7a3a21b3995f79710ebb5a8428709f66._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 6"
+ date="2020-03-07T01:05:30Z"
+ content="""
+Strange that a newer git didn’t get installed by conda as a runtime dependency of git-annex... Can you post the output of `conda list`?
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_7_95fe371e2e5083c8dc06b24b2f8d87e1._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_7_95fe371e2e5083c8dc06b24b2f8d87e1._comment
new file mode 100644
index 0000000000..ad8b2fe418
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_7_95fe371e2e5083c8dc06b24b2f8d87e1._comment
@@ -0,0 +1,68 @@
+[[!comment format=mdwn
+ username="sam.nastase@2b4a9b3e5094dab41e0a4de0b808a2697a3e9860"
+ nickname="sam.nastase"
+ avatar="http://cdn.libravatar.org/avatar/55c74b521bcb7322069f35bf655f81e0"
+ subject="comment 7"
+ date="2020-03-09T17:31:44Z"
+ content="""
+I conda uninstalled datalad in this conda env, then pip installed from master using `pip install git+https://github.com/datalad/datalad.git`
+
+Output of conda list:
+
+    # packages in environment at /usr/people/snastase/.conda/envs/datalad:
+    #
+    # Name                    Version                   Build  Channel
+    _libgcc_mutex             0.1                        main  
+    appdirs                   1.4.3                    pypi_0    pypi
+    boto                      2.49.0                   pypi_0    pypi
+    ca-certificates           2020.1.1                      0  
+    certifi                   2019.11.28               py37_0  
+    cffi                      1.14.0                   pypi_0    pypi
+    chardet                   3.0.4                    pypi_0    pypi
+    cryptography              2.8                      pypi_0    pypi
+    datalad                   0.12.2                   pypi_0    pypi
+    deprecated                1.2.7                    pypi_0    pypi
+    fasteners                 0.15                     pypi_0    pypi
+    gitdb                     4.0.2                    pypi_0    pypi
+    gitpython                 3.1.0                    pypi_0    pypi
+    humanize                  2.0.0                    pypi_0    pypi
+    idna                      2.9                      pypi_0    pypi
+    importlib-metadata        1.5.0                    pypi_0    pypi
+    iso8601                   0.1.12                   pypi_0    pypi
+    jeepney                   0.4.3                    pypi_0    pypi
+    jsmin                     2.2.2                    pypi_0    pypi
+    keyring                   21.1.1                   pypi_0    pypi
+    keyrings-alt              3.4.0                    pypi_0    pypi
+    ld_impl_linux-64          2.33.1               h53a641e_7  
+    libedit                   3.1.20181209         hc058e9b_0  
+    libffi                    3.2.1                hd88cf55_4  
+    libgcc-ng                 9.1.0                hdf63c60_0  
+    libstdcxx-ng              9.1.0                hdf63c60_0  
+    monotonic                 1.5                      pypi_0    pypi
+    msgpack                   1.0.0                    pypi_0    pypi
+    ncurses                   6.2                  he6710b0_0  
+    openssl                   1.1.1d               h7b6447c_4  
+    patool                    1.12                     pypi_0    pypi
+    pip                       20.0.2                   py37_1  
+    pycparser                 2.20                     pypi_0    pypi
+    pygithub                  1.46                     pypi_0    pypi
+    pyjwt                     1.7.1                    pypi_0    pypi
+    python                    3.7.6                h0371630_2  
+    readline                  7.0                  h7b6447c_5  
+    requests                  2.23.0                   pypi_0    pypi
+    secretstorage             3.1.2                    pypi_0    pypi
+    setuptools                45.2.0                   py37_0  
+    simplejson                3.17.0                   pypi_0    pypi
+    six                       1.14.0                   pypi_0    pypi
+    smmap                     3.0.1                    pypi_0    pypi
+    sqlite                    3.31.1               h7b6447c_0  
+    tk                        8.6.8                hbc83047_0  
+    tqdm                      4.43.0                   pypi_0    pypi
+    urllib3                   1.25.8                   pypi_0    pypi
+    wheel                     0.34.2                   py37_0  
+    whoosh                    2.7.4                    pypi_0    pypi
+    wrapt                     1.12.0                   pypi_0    pypi
+    xz                        5.2.4                h14c3975_4  
+    zipp                      3.1.0                    pypi_0    pypi
+    zlib                      1.2.11               h7b6447c_3  
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_8_ae600abfb5a82f69981f59e9de55c056._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_8_ae600abfb5a82f69981f59e9de55c056._comment
new file mode 100644
index 0000000000..253e7225b7
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_8_ae600abfb5a82f69981f59e9de55c056._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2020-03-09T18:21:14Z"
+ content="""
+I think the problem demonstrated by the script is the same problem as
+[[bugs/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__]],
+which I've now fixed.
+
+(git-annex does propagate -c settings on to all git commands it runs)
+"""]]
diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_9_d97c211a0e87212ffd2617a96263faa2._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_9_d97c211a0e87212ffd2617a96263faa2._comment
new file mode 100644
index 0000000000..f2ca762b9e
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_9_d97c211a0e87212ffd2617a96263faa2._comment
@@ -0,0 +1,107 @@
+[[!comment format=mdwn
+ username="sam.nastase@2b4a9b3e5094dab41e0a4de0b808a2697a3e9860"
+ nickname="sam.nastase"
+ avatar="http://cdn.libravatar.org/avatar/55c74b521bcb7322069f35bf655f81e0"
+ subject="comment 9"
+ date="2020-03-09T18:47:06Z"
+ content="""
+Hmm yeah I may have previously screwed something up with the conda env, because it didn't have git-annex either, which I just manually installed via conda and is now present. This also seems to have installed a new git in the conda env (see conda list below), but for whatever reason, invoking git still reaches outside the conda env (I got the server admin to upgrade to 2.9):
+
+    (datalad) scotty:/jukebox/hasson/snastase/narratives $ git --version
+    git version 2.9.3
+
+I'm still hitting a datalad error in trying to save the dataset. 
+
+    (datalad) scotty:/jukebox/hasson/snastase/narratives $ datalad save -m \"Added new 'notthefall' subjects\"
+    CommandError: 'git-annex add -c annex.dotfiles=true --json --json-error-messages -- CHANGES README dataset
+    _description.json derivatives/fmriprep derivatives/freesurfer derivatives/logs participants.tsv sub-002/su
+    b-002_scans.tsv...
+
+and on and on listing many files, then:
+
+    sub-315/sub-315_scans.json sub-315/sub-315_scans.tsv' failed with exitcode 1 under /mnt/bucket/labs/hasson/snastase/narratives
+    git-annex: Repository /mnt/bucket/labs/hasson/snastase/narratives is at unsupported version 7. Automatic upgrade exception! derivatives/mriqc: getSymbolicLinkStatus: does not exist (No such file or directory)
+
+I did a `datalad remove` on this derivatives/mriqc directory a few days ago, not sure why that's tripping up.
+
+---
+
+    # packages in environment at /usr/people/snastase/.conda/envs/datalad:
+    #
+    # Name                    Version                   Build  Channel
+    _libgcc_mutex             0.1                        main  
+    annexremote               1.3.1                    pypi_0    pypi
+    appdirs                   1.4.3                    pypi_0    pypi
+    boto                      2.49.0                   pypi_0    pypi
+    ca-certificates           2019.11.28           hecc5488_0    conda-forge
+    certifi                   2019.11.28               py37_0    conda-forge
+    cffi                      1.14.0                   pypi_0    pypi
+    chardet                   3.0.4                    pypi_0    pypi
+    cryptography              2.8                      pypi_0    pypi
+    curl                      7.68.0               hf8cf82a_0    conda-forge
+    datalad                   0.12.2                   pypi_0    pypi
+    dbus                      1.13.6               he372182_0    conda-forge
+    deprecated                1.2.7                    pypi_0    pypi
+    expat                     2.2.9                he1b5a44_2    conda-forge
+    fasteners                 0.15                     pypi_0    pypi
+    future                    0.18.2                   pypi_0    pypi
+    gettext                   0.19.8.1          hc5be6a0_1002    conda-forge
+    git                       2.23.0          pl526hacde149_0  
+    git-annex                 8.20200226         hfc01302_101    conda-forge
+    gitdb                     4.0.2                    pypi_0    pypi
+    gitpython                 3.1.0                    pypi_0    pypi
+    glib                      2.58.3          py37h6f030ca_1002    conda-forge
+    gmp                       6.2.0                he1b5a44_2    conda-forge
+    humanize                  2.0.0                    pypi_0    pypi
+    idna                      2.9                      pypi_0    pypi
+    importlib-metadata        1.5.0                    pypi_0    pypi
+    iso8601                   0.1.12                   pypi_0    pypi
+    jeepney                   0.4.3                    pypi_0    pypi
+    jsmin                     2.2.2                    pypi_0    pypi
+    keyring                   21.1.1                   pypi_0    pypi
+    keyrings-alt              3.4.0                    pypi_0    pypi
+    krb5                      1.16.4               h173b8e3_0  
+    ld_impl_linux-64          2.33.1               h53a641e_7  
+    libcurl                   7.68.0               hda55be3_0    conda-forge
+    libedit                   3.1.20181209         hc058e9b_0  
+    libffi                    3.2.1                hd88cf55_4  
+    libgcc-ng                 9.1.0                hdf63c60_0  
+    libiconv                  1.15              h516909a_1005    conda-forge
+    libmagic                  5.36                 h516909a_1    conda-forge
+    libssh2                   1.8.2                h22169c7_2    conda-forge
+    libstdcxx-ng              9.1.0                hdf63c60_0  
+    lsof                      4.89                          0    conda-forge
+    monotonic                 1.5                      pypi_0    pypi
+    msgpack                   1.0.0                    pypi_0    pypi
+    ncurses                   6.2                  he6710b0_0  
+    openssh                   7.9p1                h0fa992c_1    conda-forge
+    openssl                   1.1.1d               h516909a_0    conda-forge
+    patool                    1.12                     pypi_0    pypi
+    pcre                      8.44                 he1b5a44_0    conda-forge
+    perl                      5.26.2            h516909a_1006    conda-forge
+    pip                       20.0.2                   py37_1  
+    popt                      1.16              h299ea2f_2002    conda-forge
+    pycparser                 2.20                     pypi_0    pypi
+    pygithub                  1.46                     pypi_0    pypi
+    pyjwt                     1.7.1                    pypi_0    pypi
+    python                    3.7.6                h0371630_2  
+    readline                  7.0                  h7b6447c_5  
+    requests                  2.23.0                   pypi_0    pypi
+    rsync                     3.1.3             hed695b0_1002    conda-forge
+    secretstorage             3.1.2                    pypi_0    pypi
+    setuptools                45.2.0                   py37_0  
+    simplejson                3.17.0                   pypi_0    pypi
+    six                       1.14.0                   pypi_0    pypi
+    smmap                     3.0.1                    pypi_0    pypi
+    sqlite                    3.31.1               h7b6447c_0  
+    tk                        8.6.8                hbc83047_0  
+    tqdm                      4.43.0                   pypi_0    pypi
+    urllib3                   1.25.8                   pypi_0    pypi
+    wheel                     0.34.2                   py37_0  
+    whoosh                    2.7.4                    pypi_0    pypi
+    wrapt                     1.12.0                   pypi_0    pypi
+    xz                        5.2.4                h14c3975_4  
+    zipp                      3.1.0                    pypi_0    pypi
+    zlib                      1.2.11               h7b6447c_3  
+
+"""]]
diff --git a/doc/forum/Get_files_in_repository_A__44___that_do_not_exist_in_repository_B.mdwn b/doc/forum/Get_files_in_repository_A__44___that_do_not_exist_in_repository_B.mdwn
new file mode 100644
index 0000000000..69d3c54fd4
--- /dev/null
+++ b/doc/forum/Get_files_in_repository_A__44___that_do_not_exist_in_repository_B.mdwn
@@ -0,0 +1,17 @@
+Hey folks.
+
+Repository B is a external 4Tb HDD kept in cold storage in an offsite location. It was a fully copy of everything in Git Annex about a year ago and serves as an offsite, offline backup.
+
+I'd like to update it.
+
+Repository A is my laptop, with about a 500Gb HDD. It probably has enough free space to `git annex get` a copy of all files that have been created since 1 year ago in Repository B. I'd like to;
+
+1) Get those files to my laptop that need updating in repository B
+2) Head to the offsite location.
+3) Mount the Repository B HDD on my laptop 
+4) From the Repository B, add A (the laptop) as a remote, run a "get" and a "sync", effectively updating Repository B with a "delta" of new files
+5) From Repository A, sync with B, getting an updated index of what exists on Repository B, for updating all the other online repositories I am back home.
+
+The question is, how do I structure the command in Step 1 to get the "delta" of files to update Repository B with?
+
+Thanks! 
diff --git a/doc/forum/Get_files_in_repository_A__44___that_do_not_exist_in_repository_B/comment_1_c09c45c64f75bd30deaae9c8d8633236._comment b/doc/forum/Get_files_in_repository_A__44___that_do_not_exist_in_repository_B/comment_1_c09c45c64f75bd30deaae9c8d8633236._comment
new file mode 100644
index 0000000000..b25e42fccb
--- /dev/null
+++ b/doc/forum/Get_files_in_repository_A__44___that_do_not_exist_in_repository_B/comment_1_c09c45c64f75bd30deaae9c8d8633236._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2020-01-24T00:26:35Z"
+ content="""
+[[git-annex-get]] takes [[git-annex-matching-options]]; see `--in=repository` .
+"""]]
diff --git a/doc/forum/Get_most_recent_git-annex_version_with_anaconda.mdwn b/doc/forum/Get_most_recent_git-annex_version_with_anaconda.mdwn
new file mode 100644
index 0000000000..ea6539f3e4
--- /dev/null
+++ b/doc/forum/Get_most_recent_git-annex_version_with_anaconda.mdwn
@@ -0,0 +1 @@
+I would like to update to the most recent version of git-annex with anaconda3, as I believe some recent changes will fix a bugs I'm dealing with. But it seems the most recent version available with anaconda is  8.20211123 (https://anaconda.org/conda-forge/git-annex). How can I get a more recent version?
diff --git a/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_1_2987d3516235e90621335d055426a808._comment b/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_1_2987d3516235e90621335d055426a808._comment
new file mode 100644
index 0000000000..81fde84a6a
--- /dev/null
+++ b/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_1_2987d3516235e90621335d055426a808._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-27T16:56:12Z"
+ content="""
+They seem pretty good at keeping it up-to-date. May have missed the last
+release of 2021 which was on new year's eve.
+
+I think that this is the source for the conda forge builds and so would be
+where you can contact them: <https://github.com/conda-forge/git-annex-feedstock>
+"""]]
diff --git a/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_2_3046a4711853c88ba7f763fb04b73a5a._comment b/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_2_3046a4711853c88ba7f763fb04b73a5a._comment
new file mode 100644
index 0000000000..f841ee04c4
--- /dev/null
+++ b/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_2_3046a4711853c88ba7f763fb04b73a5a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jbwexler@31214ed76f174318e7628aefcf8404d64627aaaa"
+ nickname="jbwexler"
+ avatar="http://cdn.libravatar.org/avatar/d66af8a701b9f6cce2884cc84127eeea"
+ subject="Thanks!"
+ date="2022-01-28T14:20:45Z"
+ content="""
+Thanks for for the quick reply - will contact them there.
+"""]]
diff --git a/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_3_ece2ad657025186c267aeb20405ea1e5._comment b/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_3_ece2ad657025186c267aeb20405ea1e5._comment
new file mode 100644
index 0000000000..9f97f0e426
--- /dev/null
+++ b/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_3_ece2ad657025186c267aeb20405ea1e5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2022-01-28T19:49:56Z"
+ content="""
+Working on updating it.  conda-forge has changed their build system in ways that broke the build, I'm trying to force it to use old settings -- if that works there'll be an updated package in a day or so.
+"""]]
diff --git a/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_4_f54f3ef05da471ff4d370511e3629e05._comment b/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_4_f54f3ef05da471ff4d370511e3629e05._comment
new file mode 100644
index 0000000000..428bed39f1
--- /dev/null
+++ b/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_4_f54f3ef05da471ff4d370511e3629e05._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="conda updated"
+ date="2022-01-31T16:28:51Z"
+ content="""
+conda-forge now has the 8.20211231 and 10.20220127 versions.
+"""]]
diff --git a/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_5_59365f2d382103f1f8c30d4c52085fd6._comment b/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_5_59365f2d382103f1f8c30d4c52085fd6._comment
new file mode 100644
index 0000000000..0f3c66f3e3
--- /dev/null
+++ b/doc/forum/Get_most_recent_git-annex_version_with_anaconda/comment_5_59365f2d382103f1f8c30d4c52085fd6._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-01-31T17:37:14Z"
+ content="""
+I was looking at the conda forge, and was surprised at the sheer number of
+downloads of git-annex from there --  211,462!
+
+I suspect that counts each successive upgrade as a download as well, and
+perhaps some users are using containers that get rebuilt etc, so maybe it
+needs to be divided by 10 or 100 to get the number of users. Still, this is
+a sizeable number of downloads.
+
+Thanks, Ilya, for making this available!
+"""]]
diff --git a/doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__.mdwn b/doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__.mdwn
new file mode 100644
index 0000000000..c167a66b1f
--- /dev/null
+++ b/doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__.mdwn
@@ -0,0 +1,13 @@
+Hello,
+
+using git-annex 6.20180807-23 on Arch I get this message from time to time:
+
+     copy archive/Studium/Diplomarbeit/Daten/Vortrag/vortrag.snm (to xgm...) 
+     git-annex-shell: <stdin>: hGetChar: illegal operation (handle is closed)ok
+     copy archive/Studium/Diplomarbeit/Daten/Wheels/SingleWheelCalcs/5SpokeWheel/5Spoke_MRF/6000/Lambda2.gz 
+       Lost connection (fd:21: hFlush: resource vanished (Broken pipe))
+     (fd:21: hClose: resource vanished (Broken pipe)) failed
+
+The peer is git-annex, downloaded at Aug 7 at Debian Stable. Repeating the file transfer makes the message goes away, but I have to initiate the transfer multiple times, to be able to transfer all files without this error message.
+
+Best Thanks!
diff --git a/doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__/comment_1_9ff60145d7dfb6785bb11f2a23040948._comment b/doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__/comment_1_9ff60145d7dfb6785bb11f2a23040948._comment
new file mode 100644
index 0000000000..ab93f781c9
--- /dev/null
+++ b/doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__/comment_1_9ff60145d7dfb6785bb11f2a23040948._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2018-11-06T22:16:39Z"
+ content="""
+FWIW -- observed similar one while testing [the fresh fix](http://git-annex.branchable.com/bugs/annex_get_-J_16_via_ssh_stalls_/#comment-2abcda07d2832b923f1e7aa12778b734) under -J10 over ssh:
+
+[[!format sh \"\"\"
+get sourcedata/sub-emmet/ses-20180521/fmap/sub-emmet_ses-20180521_acq-topupXb0X3mm_dir-AP_epi.dicom.tgz (from origin...) 
+  Lost connection (fd:90: hGetChar: illegal operation (handle is closed))
+
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+...
+failed
+\"\"\"]]
+"""]]
diff --git a/doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__/comment_2_7c88ebd9d7cdf4a009aa2580cc55787d._comment b/doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__/comment_2_7c88ebd9d7cdf4a009aa2580cc55787d._comment
new file mode 100644
index 0000000000..e516fa5c00
--- /dev/null
+++ b/doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__/comment_2_7c88ebd9d7cdf4a009aa2580cc55787d._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="The issue persists with recent git-annex"
+ date="2019-03-24T23:00:30Z"
+ content="""
+The same with annex locally 7.20190219+git191-g2d6a364d4-1~ndall+1 and on remote  7.20190129+git78-g3fa6be1fe-1~ndall+1, while copying to the remote host a LOT (59k) of files, 3 \"failed\" and I get datalad print me a summary of those 3 error messages
+
+[[!format sh \"\"\"
+git-annex: <stdin>: hGetChar: illegal operation (handle is closed)git-annex-shell: p2pstdio: 1 failed  Lost connection (fd:20: hGetChar: end of file)
+  This could have failed because --fast is enabled.
+git-annex: <stdin>: hGetChar: illegal operation (handle is closed)git-annex-shell: p2pstdio: 1 failed  Lost connection (fd:19: hGetChar: end of file)
+  This could have failed because --fast is enabled.
+git-annex: <stdin>: hGetChar: illegal operation (handle is closed)git-annex-shell: p2pstdio: 1 failed  Lost connection (fd:19: hGetChar: end of file)
+  This could have failed because --fast is enabled.
+git-annex: copy: 3 failed
+
+\"\"\"]]
+I guess it is because the files are actually pointing to the same key(s), which get transferred in some other parallel batch.
+"""]]
diff --git a/doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__/comment_3_976cb63e97774859023123536bdc9d99._comment b/doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__/comment_3_976cb63e97774859023123536bdc9d99._comment
new file mode 100644
index 0000000000..80f192bb11
--- /dev/null
+++ b/doc/forum/Getting__58___hGetChar__58___illegal_operation___40__handle_is_closed__41__/comment_3_976cb63e97774859023123536bdc9d99._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2019-03-24T23:49:48Z"
+ content="""
+actually not sure if that is a matter of multiple files with the same key since with a subsequent call to `datalad publish` 3 files did get published, so I guess it was something else.
+"""]]
diff --git a/doc/forum/Getting_metadata.mdwn b/doc/forum/Getting_metadata.mdwn
new file mode 100644
index 0000000000..1f6f91fc71
--- /dev/null
+++ b/doc/forum/Getting_metadata.mdwn
@@ -0,0 +1,30 @@
+Hi!
+
+what's wrong here with getting metadata back:
+
+    # setup
+    $ git init .
+    $ git annex init
+    init  ok
+    (Recording state in git...)
+    $ touch testfile
+    $ git add testfile 
+    $ git commit -m "imp"
+    [master (Basis-Commit) 55c385e] imp
+     1 file changed, 0 insertions(+), 0 deletions(-)
+     create mode 100644 testfile
+
+    # set metadata
+    $ git annex metadata testfile --set key=val
+
+    # retrieval doesn't work
+    $ git annex metadata testfile --get key
+    $ git annex metadata testfile
+    $ 
+
+What I would expect here is to get "val" back.
+
+What am I doing wrong?
+
+
+Thanks!
diff --git a/doc/forum/Getting_metadata/comment_1_24bef8f59f370897d6fd6b2b43ed1f39._comment b/doc/forum/Getting_metadata/comment_1_24bef8f59f370897d6fd6b2b43ed1f39._comment
new file mode 100644
index 0000000000..125b852694
--- /dev/null
+++ b/doc/forum/Getting_metadata/comment_1_24bef8f59f370897d6fd6b2b43ed1f39._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-11-10T19:12:57Z"
+ content="""
+`git-annex metadata` only works on annexed files. Your `testfile` is
+checked into git directly, so these git-annex commands silently skip
+it, the same as `git annex whereis` will.
+
+There's some chance this could change.. It would be kind of nice,
+for git-annex's metadata to be able to be applied to regular files
+in the git repository.
+"""]]
diff --git a/doc/forum/Getting_started_with_Amazon_S3.mdwn b/doc/forum/Getting_started_with_Amazon_S3.mdwn
new file mode 100644
index 0000000000..1ee86b57fa
--- /dev/null
+++ b/doc/forum/Getting_started_with_Amazon_S3.mdwn
@@ -0,0 +1,28 @@
+I'm just getting started with git-annex and trying to wrap my head around using it with Amazon S3. I am familiar with using git, but things are a bit different as we can't init a repo at S3 directly.
+
+I've followed http://git-annex.branchable.com/tips/using_Amazon_S3/, and performed:
+
+`git init`<br/>
+Initialized empty Git repository in /home/<br/>
+`git annex init`<br/>
+init  ok<br/>
+`git annex initremote s3 type=S3 encryption=FOOBAR bucket=foo`<br/>
+initremote s3 (encryption setup with gpg key YGTVT51715TFR) (checking bucket...) (gpg) ok<br/>
+`git annex describe s3 "Amazon S3"`<br/>
+describe s3 ok<br/>
+`git annexx add foo/`<br/>
+add foo/bar.txt<br/>
+add foo/bar.png<br/>
+...etc<br/>
+`git annex sync`<br/>
+51 files changed, 51 insertions(+)<br/>
+create mode 120000 foo/bar.txt<br/>
+create mode 120000 foo/bar.png<br/>
+...etc<br/>
+
+
+Looking at http://git-annex.branchable.com/git-annex/, I thought the files added would then be pushed to S3 by git annex sync, but that doesn't seem to be the case. I've also tried variations of got annex copy, like `git annex copy . --to s3`, without any luck.
+
+Is there a way to push to s3?
+
+Any help is appreciated!
diff --git a/doc/forum/Getting_started_with_Amazon_S3/comment_1_f50883133d5d4903cc95c0dcaa52d052._comment b/doc/forum/Getting_started_with_Amazon_S3/comment_1_f50883133d5d4903cc95c0dcaa52d052._comment
new file mode 100644
index 0000000000..b2211fa6c1
--- /dev/null
+++ b/doc/forum/Getting_started_with_Amazon_S3/comment_1_f50883133d5d4903cc95c0dcaa52d052._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.81.112"
+ subject="comment 1"
+ date="2012-05-29T19:09:50Z"
+ content="""
+`git annex sync` only syncs git metadata, not file contents, and metadata is not stored on S3, so it does notthing (much).
+
+`git annex move . --to s3` or `git annex copy . --to s3` is the right way to send the files to S3. I'm not sure why you say it's not working. I'd try it but Amazon is not letting me sign up for S3 again right now. Can you show what goes wrong with copy?
+"""]]
diff --git a/doc/forum/Getting_started_with_Amazon_S3/comment_2_e90aa3259d9a12cd67daa27d42d69ab5._comment b/doc/forum/Getting_started_with_Amazon_S3/comment_2_e90aa3259d9a12cd67daa27d42d69ab5._comment
new file mode 100644
index 0000000000..742e8d4469
--- /dev/null
+++ b/doc/forum/Getting_started_with_Amazon_S3/comment_2_e90aa3259d9a12cd67daa27d42d69ab5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnoUOqs_lbuWyZBqyU6unHgUduJwDDgiKY"
+ nickname="Matt"
+ subject="comment 2"
+ date="2012-05-30T00:40:45Z"
+ content="""
+It's strange. I've done some testing on another machine, and this one, and the issue seems to be with adding only certain sub-directories of the git-annex directory. Would it cause an issue with git-annex if a sub-directory was a git repo?
+"""]]
diff --git a/doc/forum/Getting_started_with_Amazon_S3/comment_3_c3adce7c0f29e71ed9dd07103ede2c1a._comment b/doc/forum/Getting_started_with_Amazon_S3/comment_3_c3adce7c0f29e71ed9dd07103ede2c1a._comment
new file mode 100644
index 0000000000..450a1513ce
--- /dev/null
+++ b/doc/forum/Getting_started_with_Amazon_S3/comment_3_c3adce7c0f29e71ed9dd07103ede2c1a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.81.112"
+ subject="comment 3"
+ date="2012-05-30T00:54:38Z"
+ content="""
+If the subdirectory has a .git, then it's a separate git repo, and inside the directory, all git (and git-annex) commands in it will operate on that nested repo and ignore the outside one.
+"""]]
diff --git a/doc/forum/Getting_the_status_of_a_remotely_changed_annex_file.mdwn b/doc/forum/Getting_the_status_of_a_remotely_changed_annex_file.mdwn
new file mode 100644
index 0000000000..9a2c807992
--- /dev/null
+++ b/doc/forum/Getting_the_status_of_a_remotely_changed_annex_file.mdwn
@@ -0,0 +1,75 @@
+Hello,
+
+I am trying to wrap my head around annex still.  I'm creating a source local git repo, editing an annex file, and then syncing in a second repo.  In that second repo I'm trying to figure out how I can get a status notifying me that a file is out of date.
+
+If I use 'annex sync --content' the files are all up to date, as expected, but what I kind of expected is 'annex status' to say something like 'files out of date, blah blah'.  I am spelling out my example below.  
+
+Annex version is 5.20140613
+
+
+## I create a source and target repo, and I add a git managed file and an annex managed file
+
+    $ mkdir source target
+    $ cd source
+    $ git init
+    $ git annex init
+    $ cat > gitfile
+    hi this is my git file
+    $ cat > annexfile
+    hi this is my annex file
+    $ git add gitfile 
+    $ git annex add annexfile 
+    $ git commit -m 'init commit'
+    $ cd ../target
+    $ git clone ../source/ .
+    $ ls -al
+    total 16
+    drwxr-xr-x  170 Jul 15 15:55 .
+    drwxr-xr-x  136 Jul 15 15:54 ..
+    drwxr-xr-x  442 Jul 15 15:55 .git
+    lrwxr-xr-x  180 Jul 15 15:55 annexfile -> .git/annex/objects/Qp/F0/SHA256E-s25--045cf30cb201c6723cb6fad9ca539f639de7f242b87775b876ef9ccb1f577ccf/SHA256E-s25--045cf30cb201c6723cb6fad9ca539f639de7f242b87775b876ef9ccb1f577ccf
+    -rw-r--r--  23 Jul 15 15:55 gitfile
+    $ git annex sync
+    ...
+    To [base path]/target/../source/
+     * [new branch]      git-annex -> synced/git-annex
+     * [new branch]      master -> synced/master
+    ok
+    $ cat gitfile 
+    hi this is my git file
+    $ cat annexfile 
+    cat: annexfile: No such file or directory
+    $ git annex sync --content
+    $ cat annexfile 
+    hi this is my annex file
+
+## So far so good.  Now I'm going to edit my annexed file in source repo and see if I can find out that the file was edited in the target
+
+    $ cd ..
+    $ cd source
+    $ git annex edit annexfile 
+    $ cat > annexfile 
+    wow I changed my annex file
+    $ git annex add annexfile 
+    $ git commit -m 'changed an annex file'
+    $ cd ..
+    $ cd target
+    $ git pull
+    $ cat annexfile 
+    cat: annexfile: No such file or directory
+    $ git annex sync
+    $ ls
+    annexfile gitfile
+    $ cat annexfile 
+    cat: annexfile: No such file or directory
+    $ git annex status
+    [no output]
+
+## Here is where I'd expect something saying 'annexfile is out of date', etc.
+## I can infer it because the link is missing, but I'm sure there's a more logical way.
+
+    $ git annex sync --content
+    $ cat annexfile 
+    wow I changed my annex file
+
+## After I synced content all is well.
diff --git a/doc/forum/Getting_the_status_of_a_remotely_changed_annex_file/comment_1_e323c21d27bb0946993ba1438429c457._comment b/doc/forum/Getting_the_status_of_a_remotely_changed_annex_file/comment_1_e323c21d27bb0946993ba1438429c457._comment
new file mode 100644
index 0000000000..78b0a9c1e5
--- /dev/null
+++ b/doc/forum/Getting_the_status_of_a_remotely_changed_annex_file/comment_1_e323c21d27bb0946993ba1438429c457._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-16T18:18:00Z"
+ content="""
+As soon as git-annex syncs with a remote that has made changes to the repository, any new files or files that have been modified, and the content is not yet available in the local repository will be broken symlinks. You can generally easily see a broken symlink by running `ls`, at least with a good `ls` on eg Linux that supports colorization. (Look for the red filenames.) Many file managers also represent broken symlinks in a visual way. 
+
+Or, you can run a command like `git annex whereis $file` and see if it includes \"here\" in the list of locations.
+
+Or, you can run `git annex find --not --in here` to find all files whose current content is not present.
+
+The reason `git annex status` doesn't say is that it's focused on showing you which files in the local repository have not yet been committed to git. The `git annex list` command has a similar one line per file output, but puts a \"_\" in the first column (under \"here\") if the file is not locally present.
+"""]]
diff --git a/doc/forum/Git-Annex_Android_sync_files_are_missing_on_Linuxx.mdwn b/doc/forum/Git-Annex_Android_sync_files_are_missing_on_Linuxx.mdwn
new file mode 100644
index 0000000000..4f144d51e4
--- /dev/null
+++ b/doc/forum/Git-Annex_Android_sync_files_are_missing_on_Linuxx.mdwn
@@ -0,0 +1,4 @@
+Hi
+I created shares between Linux and Android(using nightly 4.4). I used Assistant on both. It seems like the files from Android to Linux are all missing, at least the symlinks are broken maybe. However files from Linux to Android are fine.
+
+thanks
diff --git a/doc/forum/Git-Annex_Android_sync_files_are_missing_on_Linuxx/comment_1_72d7811990e78fba0b7fc2e1c7ee515f._comment b/doc/forum/Git-Annex_Android_sync_files_are_missing_on_Linuxx/comment_1_72d7811990e78fba0b7fc2e1c7ee515f._comment
new file mode 100644
index 0000000000..9a0f2880f8
--- /dev/null
+++ b/doc/forum/Git-Annex_Android_sync_files_are_missing_on_Linuxx/comment_1_72d7811990e78fba0b7fc2e1c7ee515f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="htun"
+ ip="5.104.224.15"
+ subject="comment 1"
+ date="2014-10-17T04:57:08Z"
+ content="""
+
+
+Here is what the file is looking for symlink 
+.git/annex/objects/MF/kG/SHA256E-s1589297--0ec542aabec66b1877699ef27549fe355339224680d7923078d03f375028fca1.apk/SHA256E-s1589297--0ec542aabec66b1877699ef27549fe355339224680d7923078d03f375028fca1.apk
+
+
+and here is what is in the objects SHA256E-s1589297--0ec542aabec66b1877699ef27549fe355339224680d7923078d03f375028fca1.apk/SHA256E-s1589297--0ec542aabec66b1877699ef27549fe355339224680d7923078d03f375028fca1.apk.map  
+
+"""]]
diff --git a/doc/forum/Git-Annex_Android_sync_files_are_missing_on_Linuxx/comment_2_cfb7139958ed24c1c64f8b133c99f336._comment b/doc/forum/Git-Annex_Android_sync_files_are_missing_on_Linuxx/comment_2_cfb7139958ed24c1c64f8b133c99f336._comment
new file mode 100644
index 0000000000..8001f5cc9a
--- /dev/null
+++ b/doc/forum/Git-Annex_Android_sync_files_are_missing_on_Linuxx/comment_2_cfb7139958ed24c1c64f8b133c99f336._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-07T18:56:51Z"
+ content="""
+Sounds like the Android repository is not uploading the file contents to
+someplace where the Linux repository can download them from. So the first
+step is to look at what remotes the Android repository is configured to
+use, and see if it's successfully sending files to those. And then check if
+the Linux repository is able to get files from those same remotes.
+"""]]
diff --git a/doc/forum/Git-Annex_with_Asustor_NAS.mdwn b/doc/forum/Git-Annex_with_Asustor_NAS.mdwn
new file mode 100644
index 0000000000..8d29ce0235
--- /dev/null
+++ b/doc/forum/Git-Annex_with_Asustor_NAS.mdwn
@@ -0,0 +1,4 @@
+I'd like to use git-annex with my Asustor 302t NAS. It should be treated like a "simple" removable drive. I don't really know how to do this however, when scanning for "removable drives", it can't be found, when I try connecting via SSH, I receive an Error: Permission denied (publickey,password). As there is no way to insert my password before connecting.
+
+How do I setup a repository on my NAS to be synced with my laptop?
+I am using MAC OS X and the git-annex web interface currently.
diff --git a/doc/forum/Git-Annex_with_Asustor_NAS/comment_1_44445200e5b716caeec225972a5d5dce._comment b/doc/forum/Git-Annex_with_Asustor_NAS/comment_1_44445200e5b716caeec225972a5d5dce._comment
new file mode 100644
index 0000000000..ae5ea41e23
--- /dev/null
+++ b/doc/forum/Git-Annex_with_Asustor_NAS/comment_1_44445200e5b716caeec225972a5d5dce._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-05-16T16:32:05Z"
+ content="""
+If your NAS is accessed over SSH, it is not a removably drive, clearly.
+
+Try starting git-annex webapp from a console, you will probably see the ssh password prompt there. Or, install ssh-askpass, or, install a current daily build of git-annex, which will prompt for the ssh password from within the webapp.
+"""]]
diff --git a/doc/forum/Git-annex_and_Microsoft_Office_files_on_OS_X.mdwn b/doc/forum/Git-annex_and_Microsoft_Office_files_on_OS_X.mdwn
new file mode 100644
index 0000000000..ab26e2b512
--- /dev/null
+++ b/doc/forum/Git-annex_and_Microsoft_Office_files_on_OS_X.mdwn
@@ -0,0 +1 @@
+On OS X 10.11.6, if you save any MS office file (.pptx, .docx, .xlsx) in a git-annex directory it won't be synced unless you restart the daemon.  If you look in the logs it says "/Users/me/annex/test.pptx still has writers, not adding"  This probably has something to do with temporary/lockfiles used by MS office apps.  Any ideas on a workaround, other than restarting the daemon constantly?
diff --git a/doc/forum/Git-annex_and_Microsoft_Office_files_on_OS_X/comment_1_71fdd5e7061d6deb357290057804cc27._comment b/doc/forum/Git-annex_and_Microsoft_Office_files_on_OS_X/comment_1_71fdd5e7061d6deb357290057804cc27._comment
new file mode 100644
index 0000000000..3cd1c5943c
--- /dev/null
+++ b/doc/forum/Git-annex_and_Microsoft_Office_files_on_OS_X/comment_1_71fdd5e7061d6deb357290057804cc27._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-09T17:51:35Z"
+ content="""
+A bug was opened about this:
+[[bugs/Git-annex_and_Microsoft_Office_files_on_OS_X]]
+"""]]
diff --git a/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__.mdwn b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__.mdwn
new file mode 100644
index 0000000000..7771403541
--- /dev/null
+++ b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__.mdwn
@@ -0,0 +1,9 @@
+Hello,
+
+first of all thank you very much for Git-annex: I think it is a great tool to keep files in sync. The feature I like most is the possibility of setting multiple remote servers and execute syncs in a decentralized fashion; this is great for me since I have multiple computers spreaded around but not all of them are always up and almost none is "99.99% guaranteed" and I need high availability.
+
+Getting to the poing: I set up git-annex manually on my computers (most remote are only accessible via ssh tunnels) and I am using it in direct mode, with the assistant running in background on every node. From time to time I open the webapp to check if everything looks fine. Finally, I set a couple of nodes (with plenty of storage) as 'full backup' even if I don't really understand what that setting is really for.
+
+My question is: in my setup, where do deleted files and older versions go? If I ever need one in the future where should I look for it?
+
+Thanks a million!
diff --git a/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_10_645af86feb8506c3ea2134badac68e0b._comment b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_10_645af86feb8506c3ea2134badac68e0b._comment
new file mode 100644
index 0000000000..8029f07c0b
--- /dev/null
+++ b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_10_645af86feb8506c3ea2134badac68e0b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Agenta"
+ subject="comment 10"
+ date="2015-11-19T09:23:55Z"
+ content="""
+Yes I might try that as well, using Bup as a special remote instead of using nightly backups! Thanks for the heads up!
+"""]]
diff --git a/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_1_d9acd44c00676d814e19613d6fd276a2._comment b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_1_d9acd44c00676d814e19613d6fd276a2._comment
new file mode 100644
index 0000000000..a4915729af
--- /dev/null
+++ b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_1_d9acd44c00676d814e19613d6fd276a2._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="Repository groups"
+ date="2015-06-23T12:21:58Z"
+ content="""
+Have a look at the [[preferred_content/standard_groups]] page. Backup Repositories want to get hold of anything.
+
+> anything
+>
+>Matches any version of any file.
+
+So if you have the assistant running it will take care of pushing the old versions in the backup.
+"""]]
diff --git a/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_2_45928886d1ae4a76e2daefb355967729._comment b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_2_45928886d1ae4a76e2daefb355967729._comment
new file mode 100644
index 0000000000..1b0f118343
--- /dev/null
+++ b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_2_45928886d1ae4a76e2daefb355967729._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-06T19:03:57Z"
+ content="""
+While Marco is right about backup repositories, note that the assistant can
+only move the content of deleted/old versions of files to a backup repository 
+if that repository is set up as a remote of the repository where the
+assistant is running.
+
+So, it's quite possible to have some backup repositories that are not well
+enough connected for deleted/old files to reach them. The deleted/old files
+will then be kept in whatever repositories happen to contain them.
+
+Where are the deleted files stored? Underneath .git/annex/objects/
+
+Also, the webapp has a configuration page to control what to do with unused
+files, and can be configured to delete them periodically if you'd prefer.
+"""]]
diff --git a/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_3_1249bf921ea7709b4f7ae25e613bf60a._comment b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_3_1249bf921ea7709b4f7ae25e613bf60a._comment
new file mode 100644
index 0000000000..4fb44b1602
--- /dev/null
+++ b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_3_1249bf921ea7709b4f7ae25e613bf60a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="r@9dd621f83d4900d70d4ed2319f20160749f1343e"
+ nickname="r"
+ subject="How to get deleted files and older versions out of a full backup repository?"
+ date="2015-11-16T21:27:33Z"
+ content="""
+I'm sorry if I have overlooked something obvious, but after playing with a \"simple\" setup (2 desktops and 1 laptop all syncing their ~/annex directory with the assistant/webapp with direct ssh access and XMPP, including one \"full backup\" repository on an ssh server accessible by all) and moving a few directories in and out of ~/annex to verify that it syncs between the clients, the deleted files seem to be present only in the backup repository - simply judging by the size of the repositories on the different machines. However, how can I get them back after deleting them and letting that sync out by the assistant? 
+On the clients, git annex list/log will only print the files still there, not the deleted ones. On the backup repository (which seems to be a bare repository), git annex list/log is mostly empty. The backup repository was automatically created by the webapp on the first client I set up, I only created the (empty) directory and assigned appropriate user ACLs on the ssh server. I have not manually created a (non-bare) git repository there.
+
+Is this a supported/sane configuration for using assistant/webapp? The idea is to have the ~/annex directories behave like Dropbox (simplified point of view), but still be able to get to deleted or old versions of files. I am aware that there is no UI support for this yet, but I understood this to be supported by the \"full backup\" repositories.
+"""]]
diff --git a/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_4_616cb76a510fa32c2aa48c25d24c6044._comment b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_4_616cb76a510fa32c2aa48c25d24c6044._comment
new file mode 100644
index 0000000000..cad2b2493b
--- /dev/null
+++ b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_4_616cb76a510fa32c2aa48c25d24c6044._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Agenta"
+ subject="comment 4"
+ date="2015-11-17T10:32:41Z"
+ content="""
+Dear r,
+
+I did lots of testing about recovering deleted files or previous versions with git-annex but I didn't have much success. I really found it difficult to recover files from git-annex, too time consuming.
+At the end I found a chep and dirty solution. I write it here in case it may be useful to you or to somone else. I now run a daily backup of my git-annex repo with Bup (http://bup.github.io/) on a couple of my computers, so I can easily restore to a previous state if needed. Bup implements data deduplication so you can have daily backups without consuming too much space. Bup is extremely easy to use too, you can mount backups as fuse filesystems or view them via a web browser. The only problem with this approach is that if you change a file multiple times during a day you won't be able to recover those changes.
+"""]]
diff --git a/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_5_100fc29a95923e5ef92eaf87d76bbc6f._comment b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_5_100fc29a95923e5ef92eaf87d76bbc6f._comment
new file mode 100644
index 0000000000..c527276c6d
--- /dev/null
+++ b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_5_100fc29a95923e5ef92eaf87d76bbc6f._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-11-18T17:35:10Z"
+ content="""
+All you need is a clone of the repository that is not using direct mode.
+(The assistant normally sets up repositories using direct mode.)
+So either stop the assistant and run "git annex direct" inside ~/annex,
+or `git clone` the backup repository to a temporary location.
+
+In that clone, you can use regular git commands to check out past versions
+of the tree. Inside such a checkout, you can use `git annex get` to get any
+of the files in that checkout from your backup repository or wherever the
+content of the file has been stored.
+
+For example, using the git-annex repository that I use to publish builds of
+git-annex:
+
+	# git clone https://downloads.kitenet.net/.git/ downloads
+	# cd downloads
+	# git log --stat git-annex/linux/current/
+	(shows a whole lot of past versions of files in that directory)
+	(I decide I want one from a few months ago)
+	# git checkout 81a0d7d
+	HEAD is now at 81a0d7d... publishing git-annex 5.20150731
+	# git annex get git-annex/linux/current/git-annex-standalone-i386.tar.gz
+	get git-annex/linux/current/git-annex-standalone-i386.tar.gz (from origin...) ok
+
+Your backup repository can be used the same way. 
+
+Deleted and old versions of files will be retained in it, as long as the
+assistant was able to send them to the backup repo in the first place
+before they got deleted or modified. When direct mode is used, if you
+change a file before it gets copied to the backup, its old contents are gone
+for good. To avoid that and make sure that all annexed files always get
+backed up, switch your ~/annex to use indirect mode.
+"""]]
diff --git a/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_6_9b19ae8e8c0c70e3827c9f362c1c1dea._comment b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_6_9b19ae8e8c0c70e3827c9f362c1c1dea._comment
new file mode 100644
index 0000000000..fbec80f927
--- /dev/null
+++ b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_6_9b19ae8e8c0c70e3827c9f362c1c1dea._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Agenta"
+ subject="comment 6"
+ date="2015-11-18T18:07:51Z"
+ content="""
+Hello joey,
+
+but that doesn't use any kind of data deduplication, am I correct? In my particular use case the indirect backup repo could grow huge so I may be better of avoiding that.
+"""]]
diff --git a/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_7_0c1c76bb082c108f3074b725bcc272c9._comment b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_7_0c1c76bb082c108f3074b725bcc272c9._comment
new file mode 100644
index 0000000000..d437b916d5
--- /dev/null
+++ b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_7_0c1c76bb082c108f3074b725bcc272c9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2015-11-18T19:09:48Z"
+ content="""
+git-annex automatically deduplicates files. The backup repo will store one
+copy of each version of each file, which may indeed get large depending on
+what you're doing.
+"""]]
diff --git a/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_8_1d7c8c8c5b34cbc7166f8d4d52b91761._comment b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_8_1d7c8c8c5b34cbc7166f8d4d52b91761._comment
new file mode 100644
index 0000000000..41462a16b2
--- /dev/null
+++ b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_8_1d7c8c8c5b34cbc7166f8d4d52b91761._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Agenta"
+ subject="comment 8"
+ date="2015-11-18T19:19:37Z"
+ content="""
+It is my understanding the Bup deduplicates even \"within\" files, i.e. if a file was modified only the changes are stored, not the entire new version. For my use case that would save a lot of space.
+
+"""]]
diff --git a/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_9_2bfb2eaf1a72e0822341cfeba9058aa7._comment b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_9_2bfb2eaf1a72e0822341cfeba9058aa7._comment
new file mode 100644
index 0000000000..086dce7528
--- /dev/null
+++ b/doc/forum/Git-annex_assistant__58___where_are_deleted_files_and_older_versions_saved__63__/comment_9_2bfb2eaf1a72e0822341cfeba9058aa7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2015-11-18T19:46:07Z"
+ content="""
+That's right, bup can store multiple versions of a file as efficiently as
+git itself can (or maybe a little more).
+
+You can use [bup as a special remote of git-annex](https://git-annex.branchable.com/special_remotes/bup/),
+and then your backup repository would be a bup repository.
+Restoring old versions of files from it would work the same way
+I described above.
+"""]]
diff --git a/doc/forum/Git-annex_assistant_configuration_file__40__s__41___location__40__s__41__.mdwn b/doc/forum/Git-annex_assistant_configuration_file__40__s__41___location__40__s__41__.mdwn
new file mode 100644
index 0000000000..36cfd4d768
--- /dev/null
+++ b/doc/forum/Git-annex_assistant_configuration_file__40__s__41___location__40__s__41__.mdwn
@@ -0,0 +1,6 @@
+Hi,
+
+I accidentally removed the .git/ folder inside a git annex assistant-monitored folder. When I open the assistant web app it still shows the repository but when I try to select it the page request never returns. What can I do at this point? I was thinking I can remove the repository from the git annex assitant configuration file if it is a plain-text file, but I don't know of its location. Please advise.
+
+Regards,
+Blake
diff --git a/doc/forum/Git-annex_assistant_configuration_file__40__s__41___location__40__s__41__/comment_1_5baffd4d6994bbcb23614b17777a0ffe._comment b/doc/forum/Git-annex_assistant_configuration_file__40__s__41___location__40__s__41__/comment_1_5baffd4d6994bbcb23614b17777a0ffe._comment
new file mode 100644
index 0000000000..f48337a423
--- /dev/null
+++ b/doc/forum/Git-annex_assistant_configuration_file__40__s__41___location__40__s__41__/comment_1_5baffd4d6994bbcb23614b17777a0ffe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 1"
+ date="2013-12-17T16:07:00Z"
+ content="""
+The file you need is .config/git-annex/autostart in your home directory.
+
+Once deleted, re-running the assistant should let you re-create the git repository and it'll re-add your files.
+"""]]
diff --git a/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__.mdwn b/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__.mdwn
new file mode 100644
index 0000000000..c5a0d70fb8
--- /dev/null
+++ b/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__.mdwn
@@ -0,0 +1,19 @@
+I am trying to follow this guide:
+
+https://git-annex.branchable.com/walkthrough/
+
+I:
+
+* created a repository
+* added a remote
+* added all the files via `git annex add .`
+* commited my changes
+* synced my repositories
+
+
+By the time I tied to actually get the content from repo one into repo two (via `git annex get folder`) I noticed that all of my stuff had been deleted from repo one (and not backed up by git annex anywhere else!).
+
+How can I get my stuff back?
+
+Also, why would any software which is meant for backup or archiving (or any sane software in general) delete stuff without me actually typing `rm` or `delete` into the terminal and without giving me a big warning message and a confirmation prompt? 
+ 
diff --git a/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__/comment_1_65b41a6eb28261e04e4fe8732f97a1f1._comment b/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__/comment_1_65b41a6eb28261e04e4fe8732f97a1f1._comment
new file mode 100644
index 0000000000..c06b202f29
--- /dev/null
+++ b/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__/comment_1_65b41a6eb28261e04e4fe8732f97a1f1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2015-04-18T07:16:01Z"
+ content="""
+Are you sure the files are actually deleted? You don't mention using direct mode or anything, so you should be able to reset the git repository to the last commit you did (restoring the symlinks) and be back on track.
+
+Sounds like you missed something either in your description of the problem, or while following the tutorial.
+"""]]
diff --git a/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__/comment_2_200a869f335909566b9ddab3032fd5a2._comment b/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__/comment_2_200a869f335909566b9ddab3032fd5a2._comment
new file mode 100644
index 0000000000..bb55a04eda
--- /dev/null
+++ b/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__/comment_2_200a869f335909566b9ddab3032fd5a2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkW9u-8uqR62QBZjeTNCXsL7Ds55dAMGbA"
+ nickname="Horea"
+ subject="comment 2"
+ date="2015-04-28T10:15:24Z"
+ content="""
+Apparently what happened is that whenever you want to set up git annex, you have to create just one repository, them *move* your files to a temporary folder on all your other media, *clone* the repository to the other media, and then copy all your files back to the clone and add them to git annex. This is a horrible workflow and not mentioned anywhere. If you do the intuitive thing and start by making a bunch of repos, because all repos are created equal, git annex will happily delete all your stuff on some of them. 
+
+Indeed, as you correctly mention, this can go horribly wrong if you use direct mode and cannot recover your files. A shame, really, that direct mode is the only mode in which you actually have write and copy access to your files, and thus, for most - including myself - the only sane way of managing your files. For the record, I was able to retrieve my files, but to this day git annex is the only software I ever used that ever managed to lose my data. 
+"""]]
diff --git a/doc/forum/Git-annex_fsck_backend_warning.mdwn b/doc/forum/Git-annex_fsck_backend_warning.mdwn
new file mode 100644
index 0000000000..ca17307f16
--- /dev/null
+++ b/doc/forum/Git-annex_fsck_backend_warning.mdwn
@@ -0,0 +1,42 @@
+Since a week or two, git-annex fsck gives a warning that my files (all of them) can be upgraded to an improved key format (SHA256E). However, I use the SHA256E key format as long as I remember and running the proposed command doesn't remove the warning for the next git-annex fsck:
+
+```
+% git-annex fsck documenten/foto_maarten.jpg                     
+fsck documenten/foto_maarten.jpg (checksum...) 
+  documenten/foto_maarten.jpg: Can be upgraded to an improved key format. You can do so by running: git annex migrate --backend=SHA256E documenten/foto_maarten.jpg
+ok
+(recording state in git...)
+
+% git-annex info documenten/foto_maarten.jpg
+file: documenten/foto_maarten.jpg
+size: 349.34 kilobytes
+key: SHA256E-s349336--c0535bad49d6c58c722b941ea020ea1f3ce2aae74c2570c14bfe920ea2171f36.jpg
+present: true
+
+% git annex migrate --backend=SHA256E documenten/foto_maarten.jpg
+migrate documenten/foto_maarten.jpg (checksum...) (checksum...) ok
+(recording state in git...)
+
+% git-annex fsck documenten/foto_maarten.jpg                     
+fsck documenten/foto_maarten.jpg (checksum...) 
+  documenten/foto_maarten.jpg: Can be upgraded to an improved key format. You can do so by running: git annex migrate --backend=SHA256E documenten/foto_maarten.jpg
+ok
+(recording state in git...)
+```
+
+I'm using git-annex as provided with Debian testing. Currently, that's
+
+```
+% git-annex version  
+git-annex version: 8.20200226
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+```
+
+Any idea what's going on here and how to solve it? I couldn't find anything so far.
diff --git a/doc/forum/Git-annex_fsck_backend_warning/comment_1_a504439397db6661788d916cb7c96da1._comment b/doc/forum/Git-annex_fsck_backend_warning/comment_1_a504439397db6661788d916cb7c96da1._comment
new file mode 100644
index 0000000000..3b2c56eb9e
--- /dev/null
+++ b/doc/forum/Git-annex_fsck_backend_warning/comment_1_a504439397db6661788d916cb7c96da1._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment: introduced by 09df58c4e"
+ date="2020-03-20T16:20:05Z"
+ content="""
+I see these false positive warnings too.  This is enough to trigger
+the issue on my end:
+
+[[!format sh \"\"\"
+cd \"$(mktemp -d --tmpdir gx-XXXXXXX)\"
+git init
+git annex init
+>foo.txt
+git annex add foo.txt
+git annex fsck foo.txt
+\"\"\"]]
+
+```
+[...]
+fsck foo.txt (checksum...) 
+  foo.txt: Can be upgraded to an improved key format. You can do so by running: git annex migrate --backend=SHA256E foo.txt
+ok
+```
+
+The presence of the warning bisects to 09df58c4e (handle keys with
+extensions consistently in all locales, 2020-02-20), which was a part
+of the 8.20200226 release.
+
+"""]]
diff --git a/doc/forum/Git-annex_fsck_backend_warning/comment_2_a5415299d07283f393319b37ba9335ff._comment b/doc/forum/Git-annex_fsck_backend_warning/comment_2_a5415299d07283f393319b37ba9335ff._comment
new file mode 100644
index 0000000000..e290e7183e
--- /dev/null
+++ b/doc/forum/Git-annex_fsck_backend_warning/comment_2_a5415299d07283f393319b37ba9335ff._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-03-20T16:55:44Z"
+ content="""
+Fixed in git just now.
+"""]]
diff --git a/doc/forum/Git-annex_fsck_backend_warning/comment_3_300bbfdd90d18619e88310de5a128ef0._comment b/doc/forum/Git-annex_fsck_backend_warning/comment_3_300bbfdd90d18619e88310de5a128ef0._comment
new file mode 100644
index 0000000000..d1e1d0b886
--- /dev/null
+++ b/doc/forum/Git-annex_fsck_backend_warning/comment_3_300bbfdd90d18619e88310de5a128ef0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 3"
+ date="2020-03-20T17:34:03Z"
+ content="""
+Thanks for the quick fix!
+"""]]
diff --git a/doc/forum/Git-annex_init_gets_stuck_on_exFAT.mdwn b/doc/forum/Git-annex_init_gets_stuck_on_exFAT.mdwn
new file mode 100644
index 0000000000..4910d80e92
--- /dev/null
+++ b/doc/forum/Git-annex_init_gets_stuck_on_exFAT.mdwn
@@ -0,0 +1,30 @@
+I  have just started using git annex, and I cloned the annex onto an external usb formatted as exFAT. I am using Mac OS X.
+
+The clone went fine, but when running `git annex init` the following happened
+
+```
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Disabling core.symlinks.
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+
+  Enabling direct mode.
+```
+then git annex appears to get stuck according to `top`:  
+
+```
+PID    COMMAND      %CPU TIME     #TH   #WQ  #PORT MEM    PURG   CMPRS  PGRP  PPID  STATE    BOOSTS  
+
+86934  git-annex    0.0  01:07.09 4     0    13    4152K  0B     5684K  86933 86933 stuck    *0[1]
+```
+
+I am running git-annex 6.20170101, so direct mode should no longer be used. Is that correct? If so what should I do to figure out what's going on?
+
+ The most relevant related thread I could find was this one [Bare repo on USB ...](http://git-annex.branchable.com/forum/Bare_repo_on_USB_drive_not_providing_files/) which suggests exFAT may not work well on Linux. However, I mainly use this USB on my Macbook to supplement the SSD. Another possibly relevant thread is this one [Android table ... only exFAT...](http://git-annex.branchable.com/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/).
+
+I appreciate any assitance.
diff --git a/doc/forum/Git-annex_init_gets_stuck_on_exFAT/comment_1_48da28dbc7da82d4e06fd3ce7962dfc5._comment b/doc/forum/Git-annex_init_gets_stuck_on_exFAT/comment_1_48da28dbc7da82d4e06fd3ce7962dfc5._comment
new file mode 100644
index 0000000000..7e44bab07e
--- /dev/null
+++ b/doc/forum/Git-annex_init_gets_stuck_on_exFAT/comment_1_48da28dbc7da82d4e06fd3ce7962dfc5._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-01-31T16:42:54Z"
+ content="""
+Despite v6 repo format being available now, git-annex still defaults to v5,
+and so needs to use direct mode when run in a FAT filesystem. If you want
+to use v6 repo mode, you will need to `git annex init --version=6`
+
+Based on some googling, "stuck" state in OSX top means that it's stuck in a
+kernel call. This probably means that git-annex is waiting for a disk
+access, or from output from one of its child processes (eg git commands).
+
+It would be helpful to look at the process tree and see what child
+processes of git-annex are running at this point.
+"""]]
diff --git a/doc/forum/Git-annex_link_to_different_file_names.mdwn b/doc/forum/Git-annex_link_to_different_file_names.mdwn
new file mode 100644
index 0000000000..a7a7c2727c
--- /dev/null
+++ b/doc/forum/Git-annex_link_to_different_file_names.mdwn
@@ -0,0 +1,41 @@
+This is a recreation of a stackexchange question, in case the community here is more knowledgeable.
+
+Link to stackexchange question : http://unix.stackexchange.com/questions/325753/git-annex-link-to-different-file-names
+
+Content :
+"Maybe this is just a crazy use case that doesn't work, but I was wondering if there's a way to build a file's history from files with different file names. I'm exploring this idea because I'd like to have a git-annex system but I can't force my coworkers to adapt.
+
+Here's what I have in mind :
+
+    Folder 1, managed by coworkers (On a shared disk) :
+
+        drawing_shop_12_nov_2015.pdf
+        drawing_shop_13_nov_2015.pdf
+        drawing_asbuilt_14_nov_2015.pdf
+        drawing_asbuilt_rev1_15_nov_2015.pdf
+
+And
+
+    Git-annex, managed by me :
+
+        drawing.pdf
+
+    (with a shop branch and a asbuilt branch)
+
+The git-annex's drawing.pdf would have an history like this :
+
+    [shop]
+    |
+    Commit A "Initial shop drawing"
+    |
+    Commit B "Add corrections from Wizzbasket"
+     \
+      |
+      [asbuilt]
+      Commit C "Reflect as built"
+      |
+      Commit D "Change dweezelbox block for simplicity"
+
+But somehow the "managed by coworkers" repo would be a direct mode repo with Commit A pointing to drawing_shop_12_nov_2015.pdf, Commit B to drawing_shop_13_nov_2015.pdf etc.
+
+Can this be done?"
diff --git a/doc/forum/Git-annex_link_to_different_file_names/comment_1_17ab85276bcf495a656c7091753c086f._comment b/doc/forum/Git-annex_link_to_different_file_names/comment_1_17ab85276bcf495a656c7091753c086f._comment
new file mode 100644
index 0000000000..8085253ad5
--- /dev/null
+++ b/doc/forum/Git-annex_link_to_different_file_names/comment_1_17ab85276bcf495a656c7091753c086f._comment
@@ -0,0 +1,60 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-12-20T19:27:31Z"
+ content="""
+Yes, you can do this. Effectively, you have two branches. In the master
+branch, you have drawing.pdf with a single name and changes commited to it.
+In the coworkers branch, you have the multiple different versions. Git has
+no difficulty representing this, but it's up to you to maintain the
+different branches.
+
+For example:
+
+	joey@darkstar:~/tmp/shop>git commit -m 'updated drawing some more' 
+	[master 1403dd4] updated drawing some more
+	 1 file changed, 1 insertion(+), 1 deletion(-)
+	joey@darkstar:~/tmp/shop>git checkout coworkers 
+	Switched to branch 'coworkers'
+	joey@darkstar:~/tmp/shop#coworkers>git show master
+	commit 1403dd49b2c378e78b8b8ec82d73e295c486697b
+	Author: Joey Hess <joeyh@joeyh.name>
+	Date:   Tue Dec 20 15:31:17 2016 -0400
+	
+	    updated drawing some more
+	
+	diff --git a/drawing.pdf b/drawing.pdf
+	index b59371e..c05ed95 120000
+	--- a/drawing.pdf
+	+++ b/drawing.pdf
+	@@ -1 +1 @@
+	-.git/annex/objects/55/MZ/SHA256E-s13--c5f6529491f9e6d40e893d2ffc008bc297bcc56a680040c124e4019fb5c1a94d.pdf/SHA256E-s13--c5f6529491f9e6d40e893d2ffc008bc297bcc56a680040c124e4019fb5c1a94d.pdf
+	\ No newline at end of file
+	+.git/annex/objects/xj/XF/SHA256E-s17--7786e857a89634ff9242d899245cbcc5e009736af6b0553cb7283b2daef77d16.pdf/SHA256E-s17--7786e857a89634ff9242d899245cbcc5e009736af6b0553cb7283b2daef77d16.pdf
+	\ No newline at end of file
+	joey@darkstar:~/tmp/shop#coworkers>ln -s .git/annex/objects/xj/XF/SHA256E-s17--7786e857a89634ff9242d899245cbcc5e009736af6b0553cb7283b2daef77d16.pdf/SHA256E-s17--7786e857a89634ff9242d899245cbcc5e009736af6b0553cb7283b2daef77d16.pdf drawing_rev2.pdf
+	joey@darkstar:~/tmp/shop#coworkers>git add drawing_rev2.pdf 
+	joey@darkstar:~/tmp/shop#coworkers>ls
+	drawing.pdf@  drawing_rev2.pdf@
+	joey@darkstar:~/tmp/shop#coworkers>git commit -m 'added rev2 of drawing'
+	[coworkers cf27781] added rev2 of drawing
+	 1 file changed, 1 insertion(+)
+	  create mode 120000 drawing_rev2.pdf
+
+In the example, I looked at what was committed to master, and copied and
+pasted the git-annex symlink into a new drawing_rev2.pdf file.
+
+That's the basic idea. There might be a better way to do that. Another way,
+for example, would be to have 2 clones of the repo, one with master checked
+out and one with coworkers checked out. You could then run, in the
+coworkers checkout:
+
+	cp -a ../master/drawing.pdf drawing_rev2.pdf
+	git add drawing_rev2.pdf
+	git commit -m 'added rev2 of drawing'
+
+That results in the same commit as the method I showed.
+
+With some scripting, you should be able to automate keeping the two
+branches in sync.
+"""]]
diff --git a/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__.mdwn b/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__.mdwn
new file mode 100644
index 0000000000..ad798bd4c6
--- /dev/null
+++ b/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__.mdwn
@@ -0,0 +1,35 @@
+Some statistics of `git-annex sync --content` (but where there is no new content to sync):
+
+    $ time git-annex sync --content
+    commit 
+    On branch master
+    Your branch is ahead of 'origin/master' by 3 commits.
+    (use "git push" to publish your local commits)
+
+
+    It took 2.15 seconds to enumerate untracked files. 'status -uno'
+    may speed it up, but you have to be careful not to forget to add
+    new files yourself (see 'git help status').
+    nothing to commit, working tree clean
+    ok
+    pull origin 
+    ok
+
+    ________________________________________________________
+    Executed in   26.74 mins   fish           external 
+    usr time  510.99 secs  325.00 micros  510.99 secs 
+    sys time  129.53 secs  134.00 micros  129.53 secs 
+
+
+So >26mins. But I even had cases where this took several hours (also without content).
+(See also the comments [here](https://git-annex.branchable.com/forum/Is_Annex_for_me__63___Questions_about_the_long_term/), although they are much less extreme, just a couple of minutes.)
+
+Why is that so slow? Why does it take so long?
+
+Is this expected? This is a reasonable fast hard disk, using ZFS, on Linux. While the repo is indeed quite big with many files, I definitely would not have expected this. I would have expected sth in the order of a couple of seconds (I think similar as `rsync` or `git status`).
+
+As you see in this output, `git status` was much faster (2 secs), so just going through the files doesn't seem to be the bottleneck. Maybe `git status` does some clever caching. But then I would expect that `git-annex` also does so.
+
+How can I fix it such that this is fast (in the order of seconds, i.e. by at least 2 orders of magnitude faster)?
+
+Side question: I wonder about that "Your branch is ahead ..." message. Shouldn't `git-annex sync` exactly solve that? I called it already multiple times.
diff --git a/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_1_e102345b520423eafb4c202a0d6e276d._comment b/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_1_e102345b520423eafb4c202a0d6e276d._comment
new file mode 100644
index 0000000000..80f4c41bf3
--- /dev/null
+++ b/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_1_e102345b520423eafb4c202a0d6e276d._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-03-12T14:06:08Z"
+ content="""
+Hi, <br>
+Are you using the latest version? There have been large performance improvements in version 8.20200720.
+
+How many files do you have in the repository?
+
+The problem is that git-annex-sync has to check the location log for each key/file from the git-annex branch every time. Because whether a file needs to be copied and where might change depending on a lot of factors (See [[git-annex-preferred-content]]).
+
+But there is a solution: [[todo/Incremental_git_annex_sync\_--content_--all]]. This is not yet implemented in git-annex itself, so I wrote a [bash script](https://gist.github.com/Lukey3332/203ea6f30d48323e7bd1d05c16b5da9c) to do this. To get the speedup, you have to run `incremental-sync.sh --fast`. Beware that in the `--fast` mode `include=` and `exclude=` in your preferred-content expression won't work correctly. And, while the scripts works fine for me so far, it still is experimental.
+
+Also, [ZFS doesn't seem to perform too well with git-annex.](https://www.datalad.org/test_fs_analysis.html)
+
+The \"Your branch is ahead ...\" is normal if you didn't run git-annex-sync on the remote in the meantime. git-annex-sync doesn't push to `master` directly, but to `synced/master` and when you run sync on the remote it will pick up the changes.
+"""]]
diff --git a/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_2_dd1cce225e4d4791b37dad5480936f76._comment b/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_2_dd1cce225e4d4791b37dad5480936f76._comment
new file mode 100644
index 0000000000..541719a0eb
--- /dev/null
+++ b/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_2_dd1cce225e4d4791b37dad5480936f76._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="comment 2"
+ date="2021-03-12T15:44:12Z"
+ content="""
+I'm on Ubuntu 20.04, and just have the default git-annex installed:
+
+git-annex version: 8.20200226
+
+"""]]
diff --git a/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_3_56c132612785da00b09f088c75f903a7._comment b/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_3_56c132612785da00b09f088c75f903a7._comment
new file mode 100644
index 0000000000..90fb721ea0
--- /dev/null
+++ b/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_3_56c132612785da00b09f088c75f903a7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2021-03-12T17:48:12Z"
+ content="""
+Then you don't have the performance improvements yet. You might want to use the latest [[install/Linux_standalone]] tarball.
+"""]]
diff --git a/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_4_b92198e15a0d6154c951cb731eca828a._comment b/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_4_b92198e15a0d6154c951cb731eca828a._comment
new file mode 100644
index 0000000000..d4b773f198
--- /dev/null
+++ b/doc/forum/Git-annex_sync_very_slow._Why__63___How_to_fix_this__63__/comment_4_b92198e15a0d6154c951cb731eca828a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="gioele@678b7c03f524f2669b179b603f65352fcc16774e"
+ nickname="gioele"
+ avatar="http://cdn.libravatar.org/avatar/366dbda84e78aff8a8a070622aeb63ce"
+ subject="comment 4"
+ date="2021-03-13T13:26:44Z"
+ content="""
+> Also, [ZFS doesn't seem to perform too well with git-annex](https://www.datalad.org/test_fs_analysis.html).
+
+The results of that test should be taken with a grain of salt. That test used ZFS version 0.6.4 from 2015. In the following 6 years ZFS went through three major releases (0.7, 0.8, 2.0) with many improvements.
+
+My personal experience is that ZFS RAID-Z2 on spinning disks with L2ARC is only marginally slower than LVM-based RAID6 (but plenty safer and more versatile).
+"""]]
diff --git a/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__.mdwn b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__.mdwn
new file mode 100644
index 0000000000..fed743e3f8
--- /dev/null
+++ b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__.mdwn
@@ -0,0 +1,5 @@
+Am I right in concluding that using an array of limited storage devices that require FAT32 is not a valid use case for git-annex?
+
+Dumb devices that require FAT32, that need all present files to be unlocked in order to not choke on them (i.e. unlike with git-annex’ text-files-as-symlinks on crippled filesystems), that also therefore need missing files to be hidden, and that are storage space-constrained, I would say are extremely common. Yet, if I understood correctly, v7 repos are required for being able to hiding missing files, but at the same time, on v7 and FAT32 filesystems, files that are present take up double their file size.
+
+Am I right, or I am missing a way to use those?
diff --git a/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_1_ee72caf2aeab4a8a2818f87653dc1cd2._comment b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_1_ee72caf2aeab4a8a2818f87653dc1cd2._comment
new file mode 100644
index 0000000000..2052cf9582
--- /dev/null
+++ b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_1_ee72caf2aeab4a8a2818f87653dc1cd2._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="guzik.sergey@9391b6c15e4938a539e36fbe5bab71df07111d2e"
+ nickname="guzik.sergey"
+ avatar="http://cdn.libravatar.org/avatar/69073e903eefa0bc2755123b26441a2f"
+ subject="comment 1"
+ date="2019-02-08T11:00:14Z"
+ content="""
+I would say that FAT32 devices are perfectly valid, but only if used as a [directory special remote](https://git-annex.branchable.com/special_remotes/directory/) with chunking enabled. This way you can transfer files of any size (given there is enough space of course) and keep all previous versions. The downside is that you can't just plug the drive into random computer and read files, git-annex is required, also it is important to remember that special remotes do not store metadata about files so you need your regular repository synced to a computer where you want to read special remote.
+
+Next option is to use [direct mode](https://git-annex.branchable.com/direct_mode/), this way files will be readable on any computer even without git-annex, but file size will be limited to 4Gb and only latest version of your files will be available. Note that you still can drop files from direct mode repository and these files will be replaced with placeholders, so you are not forced to copy big files to a repository with limited file size.
+
+Actually it is possible (and I think it is a valid use case) to use both \"directory special remote\" and \"direct mode repository\" on the same drive.
+
+If I was forced to use FAT32, I would use it this way: create directory special remote with chunking to store files, create bare repository just for metadata. This way the drive will store all versions of files, any size, even if other repositories disappear this will be a complete copy.
+"""]]
diff --git a/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_2_3be98f57bcb2ba838046105276d1afd4._comment b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_2_3be98f57bcb2ba838046105276d1afd4._comment
new file mode 100644
index 0000000000..d810b72d49
--- /dev/null
+++ b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_2_3be98f57bcb2ba838046105276d1afd4._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="chocolate.camera@ec2ecab153906be21ac5f36652c33786ad0e0b60"
+ nickname="chocolate.camera"
+ avatar="http://cdn.libravatar.org/avatar/4f00dfc3ad590ef7492788b854ceba78"
+ subject="comment 2"
+ date="2019-02-14T12:46:17Z"
+ content="""
+By device, I meant the computer-like device that needs to be able to read the files. Say, an MP3 player for example.
+
+>  used as a directory special remote […] you can't just plug the drive into random computer and read files
+
+Well, that rules it out since, the device being dumb, it does need to be able to find the real files at their standard path and be able to read them as is.
+
+Chunking is not a requirement, though, since the device's software, only supporting FAT32, would not support or expect files that cannot exist in FAT32.
+
+> Next option is to use direct mode.
+
+Direct mode is deprecated.
+"""]]
diff --git a/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_3_b17f2361b18420c950eef25d3fff8841._comment b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_3_b17f2361b18420c950eef25d3fff8841._comment
new file mode 100644
index 0000000000..fbbd09a624
--- /dev/null
+++ b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_3_b17f2361b18420c950eef25d3fff8841._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="gioele@678b7c03f524f2669b179b603f65352fcc16774e"
+ nickname="gioele"
+ avatar="http://cdn.libravatar.org/avatar/366dbda84e78aff8a8a070622aeb63ce"
+ subject="FAT/NTFS and POSIX allow different characters in file names"
+ date="2019-03-12T10:51:19Z"
+ content="""
+Lack of support for \"dumb FAT32\" and \"dumb NTFS\" is indeed the reason  why most of the people in my circle of acquaintances do not use git-annex.
+
+V7 and import/export tree should solve most the problems related to the synchronization.
+
+One last issue remains, however: FAT/NTFS and POSIX have different sets of allowed characters in file names. To address this, git-annex should \"smudge\" file names when dealing with a FAT/NTFS remote. For example `Moby-Dick: or, The Whale.epub` should be exported as `Moby-Dick_ or_ The Whale.epub`.
+"""]]
diff --git a/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_4_a8a79961d97fe773c1855632b4772c5b._comment b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_4_a8a79961d97fe773c1855632b4772c5b._comment
new file mode 100644
index 0000000000..4361c95836
--- /dev/null
+++ b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_4_a8a79961d97fe773c1855632b4772c5b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-04-09T15:09:24Z"
+ content="""
+I see no reason to add such filename munging to git-annex, controlling the
+names of files in the working tree is well out of its scope. It could be in
+scope for git, but more likely, if this is a problem for you, you need to
+set up your own policy for what filenames are allowed in your repository,
+and use existing facilities to enforce it (git hooks, etc).
+"""]]
diff --git a/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_5_da422adacdeb36163186a38f1aa6c06b._comment b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_5_da422adacdeb36163186a38f1aa6c06b._comment
new file mode 100644
index 0000000000..1497f0c3b5
--- /dev/null
+++ b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_5_da422adacdeb36163186a38f1aa6c06b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="seanl@fe5df935169a5440a52bdbfc5fece85cdd002d68"
+ nickname="seanl"
+ avatar="http://cdn.libravatar.org/avatar/082ffc523e71e18c45395e6115b3b373"
+ subject="I use git-annex with FAT32"
+ date="2021-01-29T17:10:01Z"
+ content="""
+I'm using git-annex for precisely this use case. I manage files on my Sansa Clip Zip, Odroid Go, and Pi1541 with it. I use a directory special remote for each device pointing at its mount point, with remote.<name>.annex-ignore-command set to `lsblk -no uuid,mountpoint | egrep -qx '<uuid>\s+<mountpoint>'` to make sure git-annex only tries to touch the remote when it's mounted. I just rename any files in the repo that have invalid names.
+"""]]
diff --git a/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_6_6f16af7d1668320d1b80472c76f892fb._comment b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_6_6f16af7d1668320d1b80472c76f892fb._comment
new file mode 100644
index 0000000000..c2cbf46ebb
--- /dev/null
+++ b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_6_6f16af7d1668320d1b80472c76f892fb._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="chocolate.camera@ec2ecab153906be21ac5f36652c33786ad0e0b60"
+ nickname="chocolate.camera"
+ avatar="http://cdn.libravatar.org/avatar/4f00dfc3ad590ef7492788b854ceba78"
+ subject="comment 6"
+ date="2021-01-29T18:23:04Z"
+ content="""
+@seanl What repo version are those? What about “if I understood correctly, v7 repos are required for being able to hiding missing files, but at the same time, on v7 and FAT32 filesystems, files that are present take up double their file size”?
+"""]]
diff --git a/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_7_2d9460736189575a8af99c50557a8e50._comment b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_7_2d9460736189575a8af99c50557a8e50._comment
new file mode 100644
index 0000000000..89c86e429f
--- /dev/null
+++ b/doc/forum/Git-annex_with_dumb_FAT32_devices_not_a_valid_use_case__63__/comment_7_2d9460736189575a8af99c50557a8e50._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-01-29T19:39:24Z"
+ content="""
+It's not a repo version, it's a kind of special remote that just accesses a
+tree of files on the device as if it were a git repo but without all the
+baggage.
+
+	git annex initremote myusbkey type=directory directory=/media/me/foo encryption=none importtree=yes exporttree=yes 
+	git annex import master --from myusbkey
+	git merge myusbkey/master
+	git annex export master --to myusbkey
+"""]]
diff --git a/doc/forum/GitBlit_as_a_centralized_repository.mdwn b/doc/forum/GitBlit_as_a_centralized_repository.mdwn
new file mode 100644
index 0000000000..884392d586
--- /dev/null
+++ b/doc/forum/GitBlit_as_a_centralized_repository.mdwn
@@ -0,0 +1,2 @@
+Is it possible to use Gitblit as a centralized repository using git-annex? 
+thanks Gary
diff --git a/doc/forum/GitBlit_as_a_centralized_repository/comment_1_06bedf5fbac45415e0cc81f41b25a5a0._comment b/doc/forum/GitBlit_as_a_centralized_repository/comment_1_06bedf5fbac45415e0cc81f41b25a5a0._comment
new file mode 100644
index 0000000000..91dac6305a
--- /dev/null
+++ b/doc/forum/GitBlit_as_a_centralized_repository/comment_1_06bedf5fbac45415e0cc81f41b25a5a0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-05-16T17:40:20Z"
+ content="""
+I assume gitblit is something like gitosis or gitolite. These let a user ssh in to a server to access a git repository, but they limit the commands they can run to `git-shell`. In order to use git-annex get/copy to such a repository, it needs to be able to run `git-annex-shell`, which is like git-shell but with more commands available. If gitblit can be made allow git-annex-shell to be run, it will work.
+"""]]
diff --git a/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink.mdwn b/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink.mdwn
new file mode 100644
index 0000000000..18f2e88b8d
--- /dev/null
+++ b/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink.mdwn
@@ -0,0 +1,9 @@
+I am using the git annex assistant between two linux machines. Sometimes, it seems to "lose" a file, having a dangling symlink of it. Fsck shows that there are no known copies of the file in the repositories, but if I do a search in .git/annex/objects, I'm able to find the file.
+
+
+I'm using git annex 6.20160923+gitgd1dabb3-1~ndall+1 and direct mode repositories thanks to the assistant.
+
+Any advice would be highly appreciated. Right now, I can't get it to consistently do this behavior, but any help would be appreciated, including what I should post, look for, etc. for more troubleshooting.
+
+Thanks again,
+Ryan
diff --git a/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_1_7b3cb1d52767b89cf46d57005bf57b06._comment b/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_1_7b3cb1d52767b89cf46d57005bf57b06._comment
new file mode 100644
index 0000000000..66d9a24a4e
--- /dev/null
+++ b/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_1_7b3cb1d52767b89cf46d57005bf57b06._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-10-17T19:39:21Z"
+ content="""
+You say you can find the file in .git/annex/objects. Have you tried
+running `git annex fsck` on the file? If it can also find the file
+there, it should fix the working tree up to have a copy of it.
+
+Direct mode is known to have the odd bug in this area.
+"""]]
diff --git a/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_2_52ad16f63ec47b34485a0d0f4db9e2c8._comment b/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_2_52ad16f63ec47b34485a0d0f4db9e2c8._comment
new file mode 100644
index 0000000000..8255ba778a
--- /dev/null
+++ b/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_2_52ad16f63ec47b34485a0d0f4db9e2c8._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="ryan@d4f0c2d3daacb5ec3a2945bca06f66decad4bfb5"
+ nickname="ryan"
+ avatar="http://cdn.libravatar.org/avatar/7732d2474bcd13998986a87a9b17273c"
+ subject="re: comment 1"
+ date="2016-10-17T19:54:45Z"
+ content="""
+I did try running fsck, which gave a message about not being able to find the file.
+
+That's too bad that there are these types of bugs in direct mode. I find it really nice to be able to just throw all my stuff in the git annex and not worry about the state and have it synced everywhere.
+
+Thanks again for making such a wonderful tool and helping me troubleshoot.
+"""]]
diff --git a/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_3_a60bc9a6e766c0f29835c088c0863cf5._comment b/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_3_a60bc9a6e766c0f29835c088c0863cf5._comment
new file mode 100644
index 0000000000..64c48602a9
--- /dev/null
+++ b/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_3_a60bc9a6e766c0f29835c088c0863cf5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-10-17T20:38:45Z"
+ content="""
+If fsck couldn't find the file, but you could, that begs the question:
+What was the filename of the file that you found?
+"""]]
diff --git a/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_4_c8088fd093312685f130af07e5ca2e22._comment b/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_4_c8088fd093312685f130af07e5ca2e22._comment
new file mode 100644
index 0000000000..58b141306e
--- /dev/null
+++ b/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink/comment_4_c8088fd093312685f130af07e5ca2e22._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="ryan@d4f0c2d3daacb5ec3a2945bca06f66decad4bfb5"
+ nickname="ryan"
+ avatar="http://cdn.libravatar.org/avatar/7732d2474bcd13998986a87a9b17273c"
+ subject="fsck filename"
+ date="2016-10-18T04:05:51Z"
+ content="""
+Something like SHA256E-s146706--ee3814f2a8c017d1a8c2af39124f107a8a663ed00a13757f6e328bd652ecba1b.txt in /.git/annex/objects/...
+
+I didn't take very good notes, but it seemed to have the same filename as everything else. I was able to find it by doing an ag (grep) search for a string I knew was in the file.
+"""]]
diff --git a/doc/forum/Git_Annex_Assistant__58___How_to_add_a_remote__63__.mdwn b/doc/forum/Git_Annex_Assistant__58___How_to_add_a_remote__63__.mdwn
new file mode 100644
index 0000000000..0a3aac9116
--- /dev/null
+++ b/doc/forum/Git_Annex_Assistant__58___How_to_add_a_remote__63__.mdwn
@@ -0,0 +1,11 @@
+Hi,
+
+I am trying to use Git Annex Assistant on my Fedora Linux computer. I currently have a local repository that assistant monitors, but now I want to use my personal server as a git remote for the repository. I click on Configuration > Remote server and it prompts me for my server login credentials and then click the "Check this server" button. After this I am shown a screen that assistant is "Ready to add remote server" and then states:
+> The server <MY IP ADDRESS HERE> can be used as is, but installing git-annex on it would make it work better, and provide more options below.
+>
+> If you're able to install software on the server, do so and click Retry
+
+The information shown below this message is regarding encrypting the data (if I have git-annex installed on the server, which I don't). So my question is, what do I do now? There is no button to just add the remote from within git annex assistant? I created a bare repository on my server and added a remote manually inside the repository on my local machine, but git annex assistant doesn't notice it. I'm clueless on what git annex assistant is expecting from me at this point. I would think what I'm trying to do is one of the most common use cases for git annex, but I can't find any documentation or materials on the correct procedure for this. Any help is appreciated.
+
+Regards,
+Blake
diff --git a/doc/forum/Git_Annex_Assistant__58___How_to_add_a_remote__63__/comment_1_d0a3d0090928790d5a05e9f8e5f05320._comment b/doc/forum/Git_Annex_Assistant__58___How_to_add_a_remote__63__/comment_1_d0a3d0090928790d5a05e9f8e5f05320._comment
new file mode 100644
index 0000000000..5c3a596a5c
--- /dev/null
+++ b/doc/forum/Git_Annex_Assistant__58___How_to_add_a_remote__63__/comment_1_d0a3d0090928790d5a05e9f8e5f05320._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 1"
+ date="2013-10-21T22:20:53Z"
+ content="""
+You have two choices:
+
+1. Install git-annex on your server. You can then use the webapp to set up a git repository, or use the git repository you've already set up.
+
+2. Don't install git-annex on your server. Select the option in the webapp to use an encrypred rsync repository on your server. (The screen you described the webapp showing had a button to use this option, but you seem to have misread it.)
+"""]]
diff --git a/doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive.mdwn b/doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive.mdwn
new file mode 100644
index 0000000000..20e435fcff
--- /dev/null
+++ b/doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive.mdwn
@@ -0,0 +1,3 @@
+I'm using Git Annex Assistant for the first time, trying to get it to mirror a directory of files from my computer to an external USB drive. I've tried setting up the second repo as a "Removable Drive" in the "full backup" repository group. I've also tried putting it in the "client" group. The result is the same, and Assistant doesn't backup any of my files to the external drive.
+
+What I get in the external drive in the directory that should contain the repo are the set of files "annex, objects, refs, config, HEAD" and they are NOT in a .git subdirectory. Aside from this I don't see any of the files Git Annex Assistant says it has synced. As this is my first time using the Assistant, I don't know if this is a bug, or if I'm just using it incorrectly. If anyone knows what is going on here, please share.
diff --git a/doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive/comment_1_a1d1ae9488924b08682b355aff51130d._comment b/doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive/comment_1_a1d1ae9488924b08682b355aff51130d._comment
new file mode 100644
index 0000000000..31ed0999ef
--- /dev/null
+++ b/doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive/comment_1_a1d1ae9488924b08682b355aff51130d._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3HGoDpnOPob5jOjvIootmkve1-nCpRiI"
+ nickname="Kalle"
+ subject="This is the expected default behavior"
+ date="2014-05-17T20:49:06Z"
+ content="""
+Your files should be on the removable drive but the file structure and file names are following git annex logic and is not meant to be human readable.
+
+The default assumption (which I question) is that you will use the removable drive to transfer files between git-annex repositories. So by default you cannot read the files on devices that do not have git-annex installed.
+
+You can configure git-annex to do what you want using the `post-receive` hook. It's a bit complicated and might leave git-annex hogging your drive when you wan't to eject it but see the following:
+
+ - [[forum/USB_backup_with_files_visible/]]
+ - [[forum/Can't_get_git-annex_merge_to_work_from_git_hook/#comment-d93181e69b8bea54bc03cb335dd1d7c8]]
+
+The last post on that second link tells you exactly what to put in the `post-receive` hook in the .git/hooks folder on your removable drive.
+"""]]
diff --git a/doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive/comment_2_6649077583bc14730a08aaaca7ccb62e._comment b/doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive/comment_2_6649077583bc14730a08aaaca7ccb62e._comment
new file mode 100644
index 0000000000..059d446e7b
--- /dev/null
+++ b/doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive/comment_2_6649077583bc14730a08aaaca7ccb62e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnov5q9_Cl4Ps5NoYE08yE01NLSvBANnY8"
+ nickname="Eric"
+ subject="comment 2"
+ date="2014-05-18T09:35:45Z"
+ content="""
+Okay, I understand now. Probably Assistant should only treat the external drive that way if it's in the \"transfer\" group.
+"""]]
diff --git a/doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive/comment_3_f359d9b9356de7ee10b9e725a011cc43._comment b/doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive/comment_3_f359d9b9356de7ee10b9e725a011cc43._comment
new file mode 100644
index 0000000000..caec25ffd1
--- /dev/null
+++ b/doc/forum/Git_Annex_Assistant_won__39__t_backup_files_to_removable_drive/comment_3_f359d9b9356de7ee10b9e725a011cc43._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnov5q9_Cl4Ps5NoYE08yE01NLSvBANnY8"
+ nickname="Eric"
+ subject="comment 3"
+ date="2014-07-10T05:50:32Z"
+ content="""
+Actually, I understand the logic behind encouraging bare repositories.
+"""]]
diff --git a/doc/forum/Git_Annex_Sync_Delinks_Files.mdwn b/doc/forum/Git_Annex_Sync_Delinks_Files.mdwn
new file mode 100644
index 0000000000..1ce18dd0b9
--- /dev/null
+++ b/doc/forum/Git_Annex_Sync_Delinks_Files.mdwn
@@ -0,0 +1,11 @@
+So, I'm using git-annex to manage a group of external hard drives that I use to store a bunch of big files.
+
+When syncing tonight, though, it decided to take a whole subdirectory and replace the symlinks with the content directly when merging, or something.
+
+The remote side is not like that, and I didn't tell it to do anything like that.
+It just seems to feel like that's the thing to do, then it syncs and fails because suddenly git has many gigs of objects, which is what git-annex is supposed to solve.
+
+I've reset master a bunch of times, and it keeps choosing that path, but I don't know why.
+I've also reset master and synced/master a few times. I'm not fully sure what that one actually encodes, so I didn't want to touch it too much, but setting it to the same thing as master didn't seem to fix things either.
+
+Any idea why?
diff --git a/doc/forum/Git_Annex_Sync_Delinks_Files/comment_1_8b03707777a9d8e38715cb77d2a0addc._comment b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_1_8b03707777a9d8e38715cb77d2a0addc._comment
new file mode 100644
index 0000000000..ad0605f494
--- /dev/null
+++ b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_1_8b03707777a9d8e38715cb77d2a0addc._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2013-12-31T18:06:15Z"
+ content="""
+Are you using direct mode?
+
+Before the direct mode guard was put in place, it was not uncommon for users to mistakenly run some command like \"git commit -a\" in a direct mode repository. This happily checks the full large files into git.
+
+It sounds to me like you've done that. But, you have not provided enough information to make anything more than a vague guess.
+"""]]
diff --git a/doc/forum/Git_Annex_Sync_Delinks_Files/comment_2_a625e7d88e321532ace103548b31b67b._comment b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_2_a625e7d88e321532ace103548b31b67b._comment
new file mode 100644
index 0000000000..9dd931053c
--- /dev/null
+++ b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_2_a625e7d88e321532ace103548b31b67b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk_W9oOMDiBaU_xLIbeaTF8wW2wJzJ7bfw"
+ nickname="Christopher"
+ subject="comment 2"
+ date="2013-12-31T18:56:58Z"
+ content="""
+I am not in direct mode.
+I don't believe I did anything in the repo. I reset back to a commit and look in the folder and it's all symlinks and nothing in git status says anything about it.
+
+Then I run `git annex sync` and one of the thing it does is \"Checking out files\" which takes a long time, since it seems to be copying the data into the working directory and commiting it.
+I don't know why it's decided to do that.
+
+What steps can I take to either get you more information or fix things?
+
+Perhaps relatedly, if I make a mistake with git-annex, is git-reset master and git-reset synced/master the right approach?
+Are there other things I should try, etc?
+
+"""]]
diff --git a/doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment
new file mode 100644
index 0000000000..cadf944cd4
--- /dev/null
+++ b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 3"
+ date="2013-12-31T19:19:15Z"
+ content="""
+\"Checking out files\" is a message printed by git (not by git-annex) when it is updating the work tree.
+
+It still seems that you have somehow committed large files directly to git. Perhaps you accidentally ran \"git add\" on a large file.
+
+git annex sync is probably merging this commit from one of your other repositories.
+"""]]
diff --git a/doc/forum/Git_Annex_Sync_Delinks_Files/comment_4_e43ede0bdc20de9aa10ab6ce387d8582._comment b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_4_e43ede0bdc20de9aa10ab6ce387d8582._comment
new file mode 100644
index 0000000000..9b16ea2b06
--- /dev/null
+++ b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_4_e43ede0bdc20de9aa10ab6ce387d8582._comment
@@ -0,0 +1,92 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk_W9oOMDiBaU_xLIbeaTF8wW2wJzJ7bfw"
+ nickname="Christopher"
+ subject="comment 4"
+ date="2014-01-01T15:23:17Z"
+ content="""
+I know that checking of files is a git message, I was just providing it for context.
+
+I know that my other repos do not have these things checked in, because one of them is offline and not involved in this, and the other repo literally can't contain that much data, which is the biggest reason this is an issue.
+
+Here are the commits I don't like:
+
+    commit 1ae2410a4bc3e35edbfd9d48a577bcfc7e3a8836
+    Author: Christopher Vollick <0@psycoti.ca>
+    Date:   Mon Dec 30 23:22:47 2013 -0500
+    
+        git-annex automatic sync
+    
+    :120000 100644 185b311... fd03ae5... T	subdir1/other_file0309
+    :120000 100644 515e6df... 44f8383... T	subdir1/other_file0309
+    
+    commit 7403e3116eb34e2b192dfa3ea4c16e35f82210ba
+    Author: Christopher Vollick <0@psycoti.ca>
+    Date:   Sat Dec 21 19:12:56 2013 -0500
+    
+        git-annex automatic sync
+    
+    :120000 100644 185b311... fd03ae5... T	subdir1/other_file0309
+    :120000 100644 515e6df... 357d9a7... T	subdir1/other_file0309
+    :120000 100644 079f69f... 97c785a... T	subdir1/file01
+    :120000 100644 c69574a... 1589721... T	subdir1/file02
+    :120000 100644 01d98a4... 154a059... T	subdir1/file03
+    :120000 100644 6ee02d5... 6857f73... T	subdir1/file04
+    :120000 100644 aab78e7... 19bae04... T	subdir1/file05
+    :120000 100644 9f8d11b... bd5b501... T	subdir1/file06
+    :120000 100644 ca824c1... a9e0b9e... T	subdir1/file07
+    :120000 100644 c85f526... a6383fc... T	subdir1/file08
+    :120000 100644 a6d957d... 9b99c99... T	subdir1/file09
+    :120000 100644 d3de258... d51da9a... T	subdir1/file10
+    :120000 100644 3cc803e... 8f7945f... T	subdir1/other_file0005
+    :120000 100644 cd94cca... 1c06cf8... T	subdir1/other_file0006
+    :120000 100644 1442c98... fee3c1d... T	subdir1/other_file0201
+    :120000 100644 4131025... f732332... T	subdir1/other_file0202
+    :120000 100644 865214f... 1178931... T	subdir1/other_file0203
+    :120000 100644 a0f84e2... 6c39a4a... T	subdir1/other_file0204
+    :120000 100644 21bf0c1... bbb3c93... T	subdir1/other_file0205
+    :120000 100644 5f6a5f3... d298a97... T	subdir1/other_file0206
+    :120000 100644 3d7f034... 4cac0d1... T	subdir1/other_file0207
+    :120000 100644 ee75d44... d769e8e... T	subdir1/other_file0208
+    :120000 100644 f381401... 5f1a7f3... T	subdir1/other_file0209
+    :120000 100644 8b6a409... 1db8c37... T	subdir1/other_file0210
+    :120000 100644 c6a23f1... 5a9bbf5... T	subdir1/other_file0211
+    :120000 100644 17a34c7... 068c619... T	subdir1/other_file0212
+    :120000 100644 3c7fe0a... 356315b... T	subdir1/other_file0213
+    :120000 100644 4b61d45... e9747e5... T	subdir1/other_file0214
+    :120000 100644 1c0d845... f7a11d3... T	subdir1/other_file0301
+    :120000 100644 cdd57b2... fb5512f... T	subdir1/other_file0302
+    :120000 100644 9bb8ffc... 9b3897d... T	subdir1/other_file0303
+    :120000 100644 007cfa6... 93e36d7... T	subdir1/other_file0304
+    :120000 100644 24cf5d3... 9eecff4... T	subdir1/other_file0305
+    :120000 100644 d9be965... 6c612f4... T	subdir1/other_file0306
+    :120000 100644 20cd474... 9d1c714... T	subdir1/other_file0307
+    :120000 100644 3f24532... 9ff7770... T	subdir1/other_file0308
+    :120000 100644 3939cbe... de9fefd... T	subdir1/other_file0308
+    :120000 100644 9de87f9... 2242892... T	subdir1/other_file0309
+    :120000 100644 7250b17... a544af6... T	subdir1/other_file0310
+    :120000 100644 9de87f9... 2242892... T	subdir1/other_file0312
+    :120000 100644 14fbe43... f643564... T	subdir1/other_file0401
+    :120000 100644 0f28f22... e4b5e2c... T	subdir1/other_file0402
+    :120000 100644 6704647... 4529fb0... T	subdir1/other_file0403
+    :120000 100644 65b3742... dacc2ce... T	subdir1/other_file0404
+    :120000 100644 14ad1d6... a4f7dab... T	subdir1/other_file0405
+    :120000 100644 87bda81... a3b2a0a... T	subdir1/other_file0406
+    :120000 100644 23fd37b... 7ea3182... T	subdir1/other_file0407
+    :120000 100644 a82d025... aa0e1f6... T	subdir1/other_file0408
+    :120000 100644 cd350d3... c225b3d... T	subdir1/other_file0409
+    :120000 100644 2ce6c3b... 1efffa6... T	subdir1/other_file0410
+    :120000 100644 3f780d5... 207f8af... T	subdir1/other_file0411
+    :120000 100644 27ecf10... 4a34b2d... T	subdir1/other_file0412
+    :120000 100644 5cf1ba0... ab0b15d... T	subdir1/other_file0413
+    :120000 100644 a1cccd7... 274dbd1... T	subdir1/other_file0004
+
+Now, the most interesting part here is that commit 7403e3116eb is dated Sat Dec 21.
+That is not when I was attempting this. The 30th, shown in 1ae24 is.
+
+That makes me think that I have failed to reset properly, and so when I'm telling it to sync it's not recomputing the thing, it's just grabbing the thing it did last time.
+
+Now, I still don't know why it chose to do that, but perhaps it wouldn't choose to do that again if I could figure out how to get it to forget that path.
+
+Thoughts?
+
+"""]]
diff --git a/doc/forum/Git_Annex_Sync_Delinks_Files/comment_5_dc71987f0e19f04a920561201f9552b4._comment b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_5_dc71987f0e19f04a920561201f9552b4._comment
new file mode 100644
index 0000000000..03e4d2a9bf
--- /dev/null
+++ b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_5_dc71987f0e19f04a920561201f9552b4._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk_W9oOMDiBaU_xLIbeaTF8wW2wJzJ7bfw"
+ nickname="Christopher"
+ subject="comment 5"
+ date="2014-01-01T16:37:38Z"
+ content="""
+Ok, so, looking into it a little more I think I've found that I screwed up updating a ref, so I didn't reset synced/master like I thought I did.
+
+So, I don't know why it chose to make this choice in the first place, but I was able to reset and manually change my way around it.
+
+That being said, I don't want to do this a lot, because I'm not fully clear on what the synced branches represent.
+Is it that, on repo1, repo2/synced/master is the last thing that pushed over, and that after a sync local synced/master is always master, and before that it's the last sync to anywhere?
+
+How safe is it to screw around with these things?
+"""]]
diff --git a/doc/forum/Git_Annex_Sync_Delinks_Files/comment_6_257a89f81858659c4dac4d116e7cf0a3._comment b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_6_257a89f81858659c4dac4d116e7cf0a3._comment
new file mode 100644
index 0000000000..f293a60308
--- /dev/null
+++ b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_6_257a89f81858659c4dac4d116e7cf0a3._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 6"
+ date="2014-01-01T20:59:32Z"
+ content="""
+The ` T ` in your `git show --raw` indicates that what was a symlink has been replaced with a regular file, and this has been committed to git. 
+
+It's certainly possible to do that when using git-annex, but you have to go a bit out of your way to so shoot yourself in the foot, because normally the pre-commit hook will detect that, and fix up your commit to not change the type of the file. Something like this:
+
+[[!format sh \"\"\"
+joey@darkstar:~/tmp/r>git annex unlock foo
+unlock foo (copying...) ok
+joey@darkstar:~/tmp/r>git commit -a --no-verify -m oops
+[master 9b63e4e] oops
+ 1 file changed, 1 deletion(-)
+ rewrite foo (100%)
+ mode change 120000 => 100644
+joey@darkstar:~/tmp/r>git show --raw
+commit 9b63e4efad1f229ae7713749e9ac2d0f9c286008
+Author: Joey Hess <joey@kitenet.net>
+Date:   Wed Jan 1 16:55:19 2014 -0400
+
+    oops
+
+:120000 100644 ea46194... e69de29... T	foo
+\"\"\"]]
+
+The fact that you seem to have made 2 commits that did this, on the 21st and 30th, makes me wonder if your .git/hooks/pre-commit does not exist, or perhaps you are making some other mistake repeatedly.
+
+The synced/* branches never have any data that is not stored somewhere else (another branch, possibly in the remote repository), so it should always be ok to delete them.
+"""]]
diff --git a/doc/forum/Git_Annex_Transfer_Protocols.mdwn b/doc/forum/Git_Annex_Transfer_Protocols.mdwn
new file mode 100644
index 0000000000..d6a660a2d8
--- /dev/null
+++ b/doc/forum/Git_Annex_Transfer_Protocols.mdwn
@@ -0,0 +1,9 @@
+Hi,
+
+May I know, which processes git-annex is using to move/copy/get file content between repositories?
+Is it using same processes which git uses, Like send-pack, receive-pack.
+I want to use Aspera to move file contents between repositories.
+Is it enough if I customize send-pack, receive-pack of git code to do Aspera file transfer or git-annex uses any other transfer mechanism.
+
+Many Thanks,
+Royal Pinto
diff --git a/doc/forum/Git_Annex_Transfer_Protocols/comment_1_a870ec991078c95a6bb683d6962ab56e._comment b/doc/forum/Git_Annex_Transfer_Protocols/comment_1_a870ec991078c95a6bb683d6962ab56e._comment
new file mode 100644
index 0000000000..31c463470c
--- /dev/null
+++ b/doc/forum/Git_Annex_Transfer_Protocols/comment_1_a870ec991078c95a6bb683d6962ab56e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.186"
+ subject="rsync over ssh"
+ date="2012-05-10T18:18:01Z"
+ content="""
+Some other protocols such as S3 for special remotes.
+"""]]
diff --git a/doc/forum/Git_Annex_Transfer_Protocols/comment_2_71419376ef50a679ea8f0f9e16991c17._comment b/doc/forum/Git_Annex_Transfer_Protocols/comment_2_71419376ef50a679ea8f0f9e16991c17._comment
new file mode 100644
index 0000000000..2e07aef088
--- /dev/null
+++ b/doc/forum/Git_Annex_Transfer_Protocols/comment_2_71419376ef50a679ea8f0f9e16991c17._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlYu7QmD7wrbHWkoxuriaA9XcijM-g5vrQ"
+ nickname="Royal"
+ subject="Protocols to transfer file content"
+ date="2012-05-10T18:48:40Z"
+ content="""
+Thanks, Is git annex is using same protocols as normal git to transfer content between normal git repositories?
+"""]]
diff --git a/doc/forum/Git_Annex_Transfer_Protocols/comment_3_fea43664a500111ca99f4043e0dadb14._comment b/doc/forum/Git_Annex_Transfer_Protocols/comment_3_fea43664a500111ca99f4043e0dadb14._comment
new file mode 100644
index 0000000000..6e7b36e311
--- /dev/null
+++ b/doc/forum/Git_Annex_Transfer_Protocols/comment_3_fea43664a500111ca99f4043e0dadb14._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.186"
+ subject="comment 3"
+ date="2012-05-10T18:51:56Z"
+ content="""
+git-annex doesn't transfer git content between git repositories. You use git for that. Well, git-annex sync can run a few git commands for you to do it.
+"""]]
diff --git a/doc/forum/Git_Annex_Transfer_Protocols/comment_4_56fb2dab1d4030c9820be32b495afdf0._comment b/doc/forum/Git_Annex_Transfer_Protocols/comment_4_56fb2dab1d4030c9820be32b495afdf0._comment
new file mode 100644
index 0000000000..fef10cd813
--- /dev/null
+++ b/doc/forum/Git_Annex_Transfer_Protocols/comment_4_56fb2dab1d4030c9820be32b495afdf0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlYu7QmD7wrbHWkoxuriaA9XcijM-g5vrQ"
+ nickname="Royal"
+ subject="Git annex content transfer protocols"
+ date="2012-05-10T19:13:48Z"
+ content="""
+Sorry if I am not clear. Actually i meant to ask, if i have 2 git repositories which are not special remotes and I am transferring annexed file content between these repositories using git annex command (move or copy) then, which protocol it uses to transfer content? Is it uses git-send-pack git-recieve-pack or some other protocols. 
+"""]]
diff --git a/doc/forum/Git_Annex_Transfer_Protocols/comment_5_a6ec9c5a4a3c0bac1df87f1df9be140b._comment b/doc/forum/Git_Annex_Transfer_Protocols/comment_5_a6ec9c5a4a3c0bac1df87f1df9be140b._comment
new file mode 100644
index 0000000000..be25737c1d
--- /dev/null
+++ b/doc/forum/Git_Annex_Transfer_Protocols/comment_5_a6ec9c5a4a3c0bac1df87f1df9be140b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.186"
+ subject="comment 5"
+ date="2012-05-10T19:17:22Z"
+ content="""
+rsync over ssh is used to transfer file contents between repositories. (You can use the -d option to see the commands git-annex runs.)
+"""]]
diff --git a/doc/forum/Git_Annex_Transfer_Protocols/comment_6_1678452fb7114aeabcf0cc3d5f6c69b0._comment b/doc/forum/Git_Annex_Transfer_Protocols/comment_6_1678452fb7114aeabcf0cc3d5f6c69b0._comment
new file mode 100644
index 0000000000..b7ef8f33c4
--- /dev/null
+++ b/doc/forum/Git_Annex_Transfer_Protocols/comment_6_1678452fb7114aeabcf0cc3d5f6c69b0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlYu7QmD7wrbHWkoxuriaA9XcijM-g5vrQ"
+ nickname="Royal"
+ subject="comment 6"
+ date="2012-05-10T19:21:08Z"
+ content="""
+Ok. This helped me a lot. Thank you
+"""]]
diff --git a/doc/forum/Git_Annex_not_dropping_unused_content.mdwn b/doc/forum/Git_Annex_not_dropping_unused_content.mdwn
new file mode 100644
index 0000000000..ffdebcdbae
--- /dev/null
+++ b/doc/forum/Git_Annex_not_dropping_unused_content.mdwn
@@ -0,0 +1,9 @@
+I've deleted some files, but their content remains in the objects directory, and *git annex unused* does not list them.
+
+I've read in this post <http://git-annex.branchable.com/forum/git-annex_unused_not_dropping_deleted_files/> that if other branches contain the files, then it won't count them as unused. My repo appears to have a few branches left over from views I've used.
+
+    remotes/sdrive/views/(added=14_09);(tag=Shared)
+    remotes/sdrive/views/(added=14_09);Images_=_
+    remotes/sdrive/views/added=_
+
+How can I delete these? Is git annex going to create a new branch for every new view I create?
diff --git a/doc/forum/Git_Annex_not_dropping_unused_content/comment_1_da47b6af512b19cba077499f41455189._comment b/doc/forum/Git_Annex_not_dropping_unused_content/comment_1_da47b6af512b19cba077499f41455189._comment
new file mode 100644
index 0000000000..d21648c9d6
--- /dev/null
+++ b/doc/forum/Git_Annex_not_dropping_unused_content/comment_1_da47b6af512b19cba077499f41455189._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="ghen1"
+ subject="Solved"
+ date="2014-12-19T12:56:55Z"
+ content="""
+I've figured it out:
+
+In the annex in which the view was made (in my case *sdrive*), the views must be deleted with single-quotes:
+
+    git branch -D 'views/(added=14_09);(tag=Shared)'
+    git branch -D 'views/(added=14_09);Images_=_'
+    git branch -D 'views/added=_'
+
+In the connected annexes, for which *sdrive* is a remote, this command removes the remote branches:
+
+    git fetch -p sdrive
+
+     x [deleted]         (none)     -> sdrive/views/(added=14_09);(tag=Shared)
+     x [deleted]         (none)     -> sdrive/views/(added=14_09);Images_=_
+     x [deleted]         (none)     -> sdrive/views/added=_
+
+After these steps *git annex* recognized old files as unused.
+"""]]
diff --git a/doc/forum/Git_Annex_shirts_at_hellotux.com.mdwn b/doc/forum/Git_Annex_shirts_at_hellotux.com.mdwn
new file mode 100644
index 0000000000..d6c3357d3e
--- /dev/null
+++ b/doc/forum/Git_Annex_shirts_at_hellotux.com.mdwn
@@ -0,0 +1,3 @@
+The fine people over at https://hellotux.com would love to make git-annex branded shirts, hoodies and currently also backpacks with git-annex branding. We recently started a cooperation for DataLad shirts, which are now available [here](https://www.hellotux.com/datalad). I have one of those and they look and feel very good. I would love to have the same with git annex's logo embroidered on it. Especially as the distribits meeting is upcoming, now would be a good time to give Gabor from hellotux a quick go that he may start. It won't cost git-annex anything, for datalad the process was very simple: send Gabor the SVG, they make a test stitch and if that looks fine, he'll add it to the webpage.
+
+@joey if you're against this for some reason, you may just say so, then I'll stop bringing this up but I'd like to know what you think of it. 😃
diff --git a/doc/forum/Git_Annex_shirts_at_hellotux.com/comment_1_fa72689070c39054d166d32fa144fabc._comment b/doc/forum/Git_Annex_shirts_at_hellotux.com/comment_1_fa72689070c39054d166d32fa144fabc._comment
new file mode 100644
index 0000000000..7be35c8765
--- /dev/null
+++ b/doc/forum/Git_Annex_shirts_at_hellotux.com/comment_1_fa72689070c39054d166d32fa144fabc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-02-16T18:10:20Z"
+ content="""
+I did get back to that email today.
+
+For what it's worth, I'm generally ok with anyone making git-annex merch. 
+See the [[logo]] page for its license.
+"""]]
diff --git a/doc/forum/Git_LFS_lock_feature.mdwn b/doc/forum/Git_LFS_lock_feature.mdwn
new file mode 100644
index 0000000000..9deb0aa901
--- /dev/null
+++ b/doc/forum/Git_LFS_lock_feature.mdwn
@@ -0,0 +1,15 @@
+Hey Joey, thanks for this awesome software! I am starting to use it for some personal git repos with images/PDFs/etc.
+
+I was wondering if you have considered a feature similar to Git LFS's file locking feature (https://github.com/git-lfs/git-lfs/wiki/File-Locking).
+
+Not sure if it's easy or possible with the way that git-annex does things, but I can imagine it would be useful to know if someone is actively working on a binary file so that 2 different people don't change the same binary file at once. I think it's important to know because it's often difficult or impossible to merge binary files. And on multi-person projects, this becomes more important.
+
+I think the interface described in the LFS wiki link above is pretty nice:
+
+```
+$ git lfs locks
+images/bar.jpg  jane   ID:123
+images/foo.jpg  alice  ID:456
+```
+
+Here we can see who has locked each individual file.
diff --git a/doc/forum/Git_LFS_lock_feature/comment_1_8f5878db6dd2a21893cc6b5a1200b010._comment b/doc/forum/Git_LFS_lock_feature/comment_1_8f5878db6dd2a21893cc6b5a1200b010._comment
new file mode 100644
index 0000000000..9aa9f37d2a
--- /dev/null
+++ b/doc/forum/Git_LFS_lock_feature/comment_1_8f5878db6dd2a21893cc6b5a1200b010._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-26T17:13:45Z"
+ content="""
+git-lfs is a centralized system with a server that can manage the locks.
+git-annex is generally not, and so I do not think it's possible to
+implement locks of that kind generally, for the same reason git does not
+support file locking itself, while contralized VCS systems often do.
+
+However, if you wanted something like git-lfs's behavior of preventing
+pushes that modify files locked by another user, it could be
+implemented as a pre-receive hook on a centralized git server. You would
+only need some way to register the locks to the server, for the pre-receive
+hook to check.
+"""]]
diff --git a/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue.mdwn b/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue.mdwn
new file mode 100644
index 0000000000..ee024eca43
--- /dev/null
+++ b/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue.mdwn
@@ -0,0 +1 @@
+I would like to make some thing. On windows one repo (R1) with files for work. On linux server the other (R2) is for syncing and the third (R3) on linux is for backup with bup. Is it any way to run remote backup command on R2 from R1 but not always when i sync them - only when i send special command? I am looking simple native solution avoiding cygwin or third scripts. Thanks.
diff --git a/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue/comment_1_c9239f9c67b2441ab0e1ac42c53db531._comment b/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue/comment_1_c9239f9c67b2441ab0e1ac42c53db531._comment
new file mode 100644
index 0000000000..3a5bc1c0d8
--- /dev/null
+++ b/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue/comment_1_c9239f9c67b2441ab0e1ac42c53db531._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-12T18:34:13Z"
+ content="""
+Well, you can ssh into the linux box and cd to R2 and run `git annex sync
+---content` and that should cause it to download any new files that it can
+(if it can contact R1), and send them along to R3.
+"""]]
diff --git a/doc/forum/Git_annex___39__corrupting__39___itself.mdwn b/doc/forum/Git_annex___39__corrupting__39___itself.mdwn
new file mode 100644
index 0000000000..fe1edc17dc
--- /dev/null
+++ b/doc/forum/Git_annex___39__corrupting__39___itself.mdwn
@@ -0,0 +1,34 @@
+Hi,
+
+Since the I updated to `2013-10-24` `git annex` has corrupted itself twice on my setup.  I'm not claiming causality here and thus I haven't filled it as a bug (probably the mistake is mine).
+
+I use three laptops and one remote ssh server.  The motherboard on laptop *T* seems to have broken and I haven't fixed it yet.  I have disabled sync to *T*  on the webapp dashboard.  
+
+First, one computer, called *W*, broke on Friday.  I got the dreaded [serious problem](http://git-annex.branchable.com/devblog/day_41__onward/) screen. `git fsck` reported lots of missing blobs and tree problem, though my data seemed OK.  I git cloned the repo from computer *X*.  Now, last night both X and W reported the same problem (log below).  *W*  recovered itself somehow, but *X*  is now in a cycle of re-adding all files in the repo and the posting the below error that has to do with computer *T* (IP ending with 107).  
+
+I would appreciate hints on why this suddenly started happen.  Computer T has been out of sync for almost 14 days (since the 24th of October I think).
+
+    error: refs/remotes/192.168.1.107_annex/git-annex does not point to a valid object!
+    error: refs/remotes/192.168.1.107_annex/master does not point to a valid object!
+    error: refs/remotes/192.168.1.107_annex/synced/git-annex does not point to a valid object!
+    error: refs/remotes/192.168.1.107_annex/synced/master does not point to a valid object!
+    error: refs/synced/2ed58ecf-8e8c-44b8-ad34-d42ddfb35315/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/git-annex does not point to a valid object!
+    error: refs/synced/2ed58ecf-8e8c-44b8-ad34-d42ddfb35315/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/master does not point to a valid object!
+    error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/git-annex does not point to a valid object!
+    error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/master does not point to a valid object!
+    error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/git-annex does not point to a valid object!
+    error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/master does not point to a valid object!
+    error: refs/remotes/192.168.1.107_annex/git-annex does not point to a valid object!
+    error: refs/remotes/192.168.1.107_annex/master does not point to a valid object!
+    error: refs/remotes/192.168.1.107_annex/synced/git-annex does not point to a valid object!
+    error: refs/remotes/192.168.1.107_annex/synced/master does not point to a valid object!
+    error: refs/synced/2ed58ecf-8e8c-44b8-ad34-d42ddfb35315/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/git-annex does not point to a valid object!
+    error: refs/synced/2ed58ecf-8e8c-44b8-ad34-d42ddfb35315/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/master does not point to a valid object!
+    error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/git-annex does not point to a valid object!
+    error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/master does not point to a valid object!
+    error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/git-annex does not point to a valid object!
+    error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/master does not point to a valid object!
+    error: invalid object 100644 1ca66de3cdd9c79cde26a7555cf3b8d26d0e371d for '000/147/SHA256E-s347--1ab8084bf9ae06407ce0a7260a83638ea6e9a028dc59b4815fd60aec61dbd747.txt.log.log'
+    fatal: git-write-tree: error building trees
+    TransferScanner crashed: failed to read sha from git write-tree
+    [2013-11-04 09:45:41 CET] TransferScanner: warning TransferScanner crashed: failed to read sha from git write-tree
diff --git a/doc/forum/Git_annex___39__corrupting__39___itself/comment_1_bcf50a215e2f8771e098aadfff4c300c._comment b/doc/forum/Git_annex___39__corrupting__39___itself/comment_1_bcf50a215e2f8771e098aadfff4c300c._comment
new file mode 100644
index 0000000000..2fe95ab335
--- /dev/null
+++ b/doc/forum/Git_annex___39__corrupting__39___itself/comment_1_bcf50a215e2f8771e098aadfff4c300c._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlEXAlu8qKv_FHYOv-uEohdGgMY_Lw-Ges"
+ nickname="Jonas"
+ subject="Just happened for me as well."
+ date="2013-11-12T08:10:56Z"
+ content="""
+This was the first search result when I googled the error message, I'm not sure what has happened (or if it is a problem since I don't change my files that often).
+
+git-annex version: 4.20131101
+
+Also running git annex with one ssh remote ( laptop1 & laptop2 synching through a ssh remote server ).
+
+Got a bunch of 
+    error: refs/synced/dbb70cea-4b83-416f-93af-e59082c4d633/git-annex does not point to a valid object!
+    error: refs/synced/dbb70cea-4b83-416f-93af-e59082c4d633/master does not point to a valid object!
+    error: refs/synced/dbb70cea-4b83-416f-93af-e59082c4d633/git-annex does not point to a valid object!
+    error: refs/synced/dbb70cea-4b83-416f-93af-e59082c4d633/master does not point to a valid object!
+when I tried a manual git annex sync, and noticed that I had a bunch of those in the log in the webapp as well... 
+
+The gui doesn't show that anything is wrong, and looking at the log it seems that things are atleast uploading
+
+    [2013-11-12 09:05:46 CET] Committer: Committing changes to git
+    [2013-11-12 09:05:46 CET] Pusher: Syncing with born 
+    error: refs/synced/dbb70cea-4b83-416f-93af-e59082c4d633/git-annex does not point to a valid object!
+    error: refs/synced/dbb70cea-4b83-416f-93af-e59082c4d633/master does not point to a valid object!
+    Everything up-to-date
+
+    FILE
+
+       32768  42%    0.00kB/s    0:00:00  
+       76972 100%   42.16MB/s    0:00:00 (xfer#1, to-check=0/1)
+
+    sent 77056 bytes  received 31 bytes  51391.33 bytes/sec
+    total size is 76972  speedup is 1.00
+    [2013-11-12 09:05:48 CET] Transferrer: Uploaded FILE
+    [2013-11-12 09:05:48 CET] Pusher: Syncing with born 
+    error: refs/synced/dbb70cea-4b83-416f-93af-e59082c4d633/git-annex does not point to a valid object!
+    error: refs/synced/dbb70cea-4b83-416f-93af-e59082c4d633/master does not point to a valid object!
+    error: refs/synced/dbb70cea-4b83-416f-93af-e59082c4d633/git-annex does not point to a valid object!
+    error: refs/synced/dbb70cea-4b83-416f-93af-e59082c4d633/master does not point to a valid object!
+    To ssh://me@born/annex
+      54e04cf..333cf10  git-annex -> synced/git-annex
+"""]]
diff --git a/doc/forum/Git_annex___39__corrupting__39___itself/comment_3_75f957e7be6c1ad8936c0a2a5374db3e._comment b/doc/forum/Git_annex___39__corrupting__39___itself/comment_3_75f957e7be6c1ad8936c0a2a5374db3e._comment
new file mode 100644
index 0000000000..80f778bb16
--- /dev/null
+++ b/doc/forum/Git_annex___39__corrupting__39___itself/comment_3_75f957e7be6c1ad8936c0a2a5374db3e._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlEXAlu8qKv_FHYOv-uEohdGgMY_Lw-Ges"
+ nickname="Jonas"
+ subject="comment 3"
+ date="2013-11-13T09:03:24Z"
+ content="""
+I did a change of one of the files and that totally broke all other repositories, git fsck reports a lot of missing trees (I'm not sure if it is normal), and git annex fsck started reporting invalid object for another file for some reason, also got a (git annex repair still reports everything is fine though.)
+
+    fatal: git-write-tree: error building trees
+    git-annex: failed to read sha from git write-tree
+
+
+
+I tried following those instructions but I don't think I had a good repository, git annex repair reported everything was ok but git fsck said a lot of trees where missing and it stopped updating.
+I noticed I was running different git version (git version 1.7.9.5 on the server and git version 1.8.4.2 on one of the clients), so maybe that was part of the reason.
+
+I couldn't find out what remote dbb70cea-4b83-416f-93af-e59082c4d633 was supposed to be either, it wasn't any of the active ones and it didn't show up with git annex status either (I've lost a few repositories when I reinstalled my computer).
+
+I ended up recreating the repository (by copying the raw files) from what I think is the most recent version from one of my computers and hope that it was a error that happened due to upgrades.
+"""]]
diff --git a/doc/forum/Git_annex___39__corrupting__39___itself/comment_3_ab062b1df3b55fd49852a6220c98249e._comment b/doc/forum/Git_annex___39__corrupting__39___itself/comment_3_ab062b1df3b55fd49852a6220c98249e._comment
new file mode 100644
index 0000000000..76e9d00de4
--- /dev/null
+++ b/doc/forum/Git_annex___39__corrupting__39___itself/comment_3_ab062b1df3b55fd49852a6220c98249e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="comment 3"
+ date="2013-11-12T17:19:32Z"
+ content="""
+I have been getting this too. Here is what I have done to fix it:
+
+[[tips/recovering_from_a_corrupt_git_repository]]
+"""]]
diff --git a/doc/forum/Git_annex___39__corrupting__39___itself/comment_4_45974f60a81ed2d00b87ffb1a7963c6f._comment b/doc/forum/Git_annex___39__corrupting__39___itself/comment_4_45974f60a81ed2d00b87ffb1a7963c6f._comment
new file mode 100644
index 0000000000..4328f5d244
--- /dev/null
+++ b/doc/forum/Git_annex___39__corrupting__39___itself/comment_4_45974f60a81ed2d00b87ffb1a7963c6f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.43"
+ subject="comment 4"
+ date="2014-01-13T20:27:34Z"
+ content="""
+Many problems of this sort can happen if the disk that the git reposotory is on is losing data that's written to it, or is just removed (or the computer crashes) at the wrong time. `git-annex repair` can be run in the repository to recover from many problems like this, and it's getting better all the time.
+"""]]
diff --git a/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server.mdwn b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server.mdwn
new file mode 100644
index 0000000000..66d224b3a0
--- /dev/null
+++ b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server.mdwn
@@ -0,0 +1,14 @@
+Hi, I'm trying to setup git annex assistant (my first time).
+When I add the server (in "transfert" mode, if that matters) I get the following error:
+
+    "Neither rsync nor git-annex are installed on the server. Perhaps you should go install them?"
+
+I manually verified that both rsync and git/git-annex are installed and available from PATH in the "annex" account and all seems to be ok.
+
+Can you suggest a way to get a more specific information on the source of the error?
+
+My first guess was that this is due to the fact that rsync and git-annex are installed in "non-standard locations".  My server run NixOS (http://nixos.org) which has a completely different convention about directory hierarchy from traditional linux/unix OS (that is, no /usr/bin /usr/lib etc.).  However, I tried to "cheat" by manually adding symbolic links into a /usr/bin but this didn't work either, so I might be looking in the wrong direction.
+
+Any suggestion appreciated, thank you in advance,
+
+Marco
diff --git a/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_1_75c599cc26e7d3645f69173861d4f8be._comment b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_1_75c599cc26e7d3645f69173861d4f8be._comment
new file mode 100644
index 0000000000..20b83372e7
--- /dev/null
+++ b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_1_75c599cc26e7d3645f69173861d4f8be._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn26A25mnLHRtWAP587-NPwEFKzolmENL4"
+ nickname="Marco"
+ subject="Also with standalone git-annex"
+ date="2014-09-24T14:14:43Z"
+ content="""
+Update: I also tried to install the standalone distribution in the home of the annex user on the server as shown in the video (BTW, nice illustration!), but I get the same error.
+(On the client side I installed the osx app instead.)
+"""]]
diff --git a/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_2_496e2f3a61b609ebb28ab55e5c30022b._comment b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_2_496e2f3a61b609ebb28ab55e5c30022b._comment
new file mode 100644
index 0000000000..f0e63837c0
--- /dev/null
+++ b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_2_496e2f3a61b609ebb28ab55e5c30022b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.144"
+ subject="comment 2"
+ date="2014-09-25T15:42:41Z"
+ content="""
+You need to be able to `ssh yourserver which rsync` and have it succeed. That's what git-annex uses to probe if rsync etc is present.
+
+Note that, since that does not start a login shell, bash doesn't source ~/.bash* at all, or even /etc/profile. So none of the ways people add nonstandard directories to PATH will work.
+
+So, use this to check the PATH that is available on the system: `ssh yourserver 'echo $PATH'`
+"""]]
diff --git a/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_3_e202a6dd2803f733bd30ec8b6ddbe7bf._comment b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_3_e202a6dd2803f733bd30ec8b6ddbe7bf._comment
new file mode 100644
index 0000000000..412a370a57
--- /dev/null
+++ b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_3_e202a6dd2803f733bd30ec8b6ddbe7bf._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="pweemeeuw@86491f921da15d6a4dc6e1878fd42750b33f6963"
+ nickname="pweemeeuw"
+ subject="Got Nixos server configured as a ssh remote (FYI)"
+ date="2015-11-30T16:11:26Z"
+ content="""
+It needed some plumbing, this is what I did:
+
+_~/.ssh/rc_:
+
+    PATH=$HOME/bin:$HOME/.nix-profile/bin:/run/current-system/sw/bin
+
+Since _which_ is an alias (and hence still doesn't work for 'ssh foo which rsync'), I added a shell script _$HOME/bin/which_:
+
+    #!/run/current-system/sw/bin/bash
+    type -P $@
+
+Verified to work (syncs both ways) with a cloned repository on arch linux.
+"""]]
diff --git a/doc/forum/Git_annex_assistant_in_command_line.mdwn b/doc/forum/Git_annex_assistant_in_command_line.mdwn
new file mode 100644
index 0000000000..9323d2137f
--- /dev/null
+++ b/doc/forum/Git_annex_assistant_in_command_line.mdwn
@@ -0,0 +1,2 @@
+How can I clone a git annex remote (bare repository) created with the webapp in command line ? My goal is to be able to access the files using an ssh connection.
+
diff --git a/doc/forum/Git_annex_assistant_in_command_line/comment_1_ce05226307ade8db90ada2dbf290bd58._comment b/doc/forum/Git_annex_assistant_in_command_line/comment_1_ce05226307ade8db90ada2dbf290bd58._comment
new file mode 100644
index 0000000000..e02a4298c4
--- /dev/null
+++ b/doc/forum/Git_annex_assistant_in_command_line/comment_1_ce05226307ade8db90ada2dbf290bd58._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.254.222"
+ subject="comment 1"
+ date="2013-07-07T17:16:27Z"
+ content="""
+There is no difference between a repository created using the assistant and one created by hand. So you can just `git clone ssh://server/path` or `git remote add foo  ssh://server/path` and use it at the command line like any other repository.
+
+The assistant interoperates perfectly with the command line; you can switch between them at will at any time.
+"""]]
diff --git a/doc/forum/Git_annex_assistant_on_EC2.mdwn b/doc/forum/Git_annex_assistant_on_EC2.mdwn
new file mode 100644
index 0000000000..27f20ae462
--- /dev/null
+++ b/doc/forum/Git_annex_assistant_on_EC2.mdwn
@@ -0,0 +1,5 @@
+With Amazon EC2, it is possible to take a snapshot of the virtual machine and then bring up multiple instances based on the snapshot. 
+
+If I configure git annex assistant to sync a folder to S3, will it work correctly if I spin up multiple instances, all identical git annex assistant configurations?
+
+My use case is to allow users of my forums to upload attachments with their posts. The attachments are stored locally on disk, but I'm hoping that git annex assistant can help synchroise the attachments across all forum instances (I usually run only 1 instance, but their could be as many as 3 under heavy load).
diff --git a/doc/forum/Git_annex_assistant_on_EC2/comment_1_bbdb4611373117a2176c225378110a05._comment b/doc/forum/Git_annex_assistant_on_EC2/comment_1_bbdb4611373117a2176c225378110a05._comment
new file mode 100644
index 0000000000..cab80f976c
--- /dev/null
+++ b/doc/forum/Git_annex_assistant_on_EC2/comment_1_bbdb4611373117a2176c225378110a05._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2013-09-06T22:57:05Z"
+ content="""
+If you are using ec2 and s3 why don't you just serve the attachments directly from s3?  Not sure how git-annex adds anything here.
+"""]]
diff --git a/doc/forum/Git_annex_assistant_on_EC2/comment_2_614ed11f7134137d6376d36a61c293f5._comment b/doc/forum/Git_annex_assistant_on_EC2/comment_2_614ed11f7134137d6376d36a61c293f5._comment
new file mode 100644
index 0000000000..dfb629d62b
--- /dev/null
+++ b/doc/forum/Git_annex_assistant_on_EC2/comment_2_614ed11f7134137d6376d36a61c293f5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.251.174"
+ subject="comment 2"
+ date="2013-09-07T17:08:27Z"
+ content="""
+You are going to need to make each repository have a distinct UUID. Otherwise, the assistant will get confused.
+"""]]
diff --git a/doc/forum/Git_annex_drop.mdwn b/doc/forum/Git_annex_drop.mdwn
new file mode 100644
index 0000000000..6f082770d1
--- /dev/null
+++ b/doc/forum/Git_annex_drop.mdwn
@@ -0,0 +1,4 @@
+Hi,
+I am trying to use git annex to store some of the files on my laptop on an external drive. However, after running `git annex sync --content` on both repositories and _then_ trying to run `git annex drop <file>` doesn't free up any space on the local laptop repository (in fact it doesn't give any terminal output). Can anyone point me in a direction to solve this?
+
+Edit. Wth? Even `git annex drop --force` doesn't work. Is there some obvious thing I'm missing?
diff --git a/doc/forum/Git_annex_drop/comment_1_541399d5fff0db0627c786f5e056fabb._comment b/doc/forum/Git_annex_drop/comment_1_541399d5fff0db0627c786f5e056fabb._comment
new file mode 100644
index 0000000000..329d004f73
--- /dev/null
+++ b/doc/forum/Git_annex_drop/comment_1_541399d5fff0db0627c786f5e056fabb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ps"
+ avatar="http://cdn.libravatar.org/avatar/d492f87525ce24bc22ff1348d0c60b0d"
+ subject="Solved"
+ date="2020-03-23T19:07:53Z"
+ content="""
+It had to do with dotfiles. The files I was trying to keep track of were in a dot directory, and hence git annex didn't include it in the annex (and hence couldn't drop them).
+"""]]
diff --git a/doc/forum/Git_annex_drop/comment_2_423ffd4abca9dbb8dba8ce887dee5faf._comment b/doc/forum/Git_annex_drop/comment_2_423ffd4abca9dbb8dba8ce887dee5faf._comment
new file mode 100644
index 0000000000..371995ec0a
--- /dev/null
+++ b/doc/forum/Git_annex_drop/comment_2_423ffd4abca9dbb8dba8ce887dee5faf._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-04-27T16:21:30Z"
+ content="""
+If you pass git-annex the name of a file to operate on, and it does not
+display the name of that file, the file is probably not an annexed file.
+
+The other possibility would be that the file's content has *already* been
+dropped. If git-annex sees there is nothing it needs to do to drop an
+annexed file, it does not display anything either.
+
+I suggest you run `git annex whereis` with the file. If it does not display
+anything, it is not an annexed file. If it does display something, it will
+probably tell you where the content of the file is, since it's not in the
+local repository.
+"""]]
diff --git a/doc/forum/Git_annex_hangs.mdwn b/doc/forum/Git_annex_hangs.mdwn
new file mode 100644
index 0000000000..a7bb359054
--- /dev/null
+++ b/doc/forum/Git_annex_hangs.mdwn
@@ -0,0 +1,2 @@
+http://stackoverflow.com/questions/26305691/git-annex-hangs
+Does anyone know what might be causing this?
diff --git a/doc/forum/Git_annex_hangs/comment_10_ce5355b358f1acc63270331f3749fdcd._comment b/doc/forum/Git_annex_hangs/comment_10_ce5355b358f1acc63270331f3749fdcd._comment
new file mode 100644
index 0000000000..e07ab0403c
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_10_ce5355b358f1acc63270331f3749fdcd._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="p.s."
+ date="2017-05-17T14:34:40Z"
+ content="""
+Actually the situation is even more complex.
+
+\"The server\" where my repo is stored are actually 4 servers for load balancing that share a single file system.
+
+I just found out that on one of the servers the were still some git-annex-shell processes running. Probably the move command with -J10 logged in on different servers; maybe this confused git-annex.
+
+Now, I logged-in on all four servers and killed any remaining processes. Still the problem persists.
+
+    git-annex info --debug
+    [2017-05-17 16:29:07.197350961] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+    [2017-05-17 16:29:07.216435634] process done ExitSuccess
+    [2017-05-17 16:29:07.216539092] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2017-05-17 16:29:07.2214318] process done ExitSuccess
+    [2017-05-17 16:29:07.2220868] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..76cf27fbf3697af8843ddb82f1fffde35aaba0b2\",\"--pretty=%H\",\"-n1\"]
+    [2017-05-17 16:29:07.23077964] process done ExitSuccess
+
+What's interesting is that these killing actions apparently have changed the hash number on which the hang happens (76cf..). What I also did was git-annex sync at another host, this actually seemed to work. Maybe this changed the hash.. I'm not entirely sure..
+
+"""]]
diff --git a/doc/forum/Git_annex_hangs/comment_11_e0b4616c25405fa3c496f7e85800ac43._comment b/doc/forum/Git_annex_hangs/comment_11_e0b4616c25405fa3c496f7e85800ac43._comment
new file mode 100644
index 0000000000..7c11079ec4
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_11_e0b4616c25405fa3c496f7e85800ac43._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2017-05-25T17:47:53Z"
+ content="""
+So there is some kind of networked filesystem involved? What kind?
+
+Do you have annex.pidlock enabled in the repository's `git config`?
+"""]]
diff --git a/doc/forum/Git_annex_hangs/comment_12_053666d256e26803b911d68622257cd5._comment b/doc/forum/Git_annex_hangs/comment_12_053666d256e26803b911d68622257cd5._comment
new file mode 100644
index 0000000000..abe99479c5
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_12_053666d256e26803b911d68622257cd5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="comment 12"
+ date="2017-05-25T18:25:59Z"
+ content="""
+I checked the file system, it's nfs.
+
+`git config --get annex.pidlock` gives nothing, so I guess it's not enabled. Do I have to enable it, if the repo is on an nfs mount?
+
+"""]]
diff --git a/doc/forum/Git_annex_hangs/comment_13_f28528c9b9766fe8e2d344e5f27ade65._comment b/doc/forum/Git_annex_hangs/comment_13_f28528c9b9766fe8e2d344e5f27ade65._comment
new file mode 100644
index 0000000000..a528672103
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_13_f28528c9b9766fe8e2d344e5f27ade65._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="Working again"
+ date="2017-05-29T15:19:18Z"
+ content="""
+Hi,
+
+I'm not sure what exactly has changed, but it's working again!
+
+Until now, I was using git-annex version: 6.20170321-gf3dee9d65 from the standalone-amd64.tar.gz. In the meantime I convinced the administrator to install git-annex system wide. She installed git-annex version: 5.20140221 from the packet-system.
+
+Now, the repository works again with both, git-annex 5 and 6.
+
+However, I cannot exactly tell if anything else has changed in the meantime, since I am not the administrator of the system.
+
+Thanks for your help, anyway.
+
+"""]]
diff --git a/doc/forum/Git_annex_hangs/comment_1_e6b854d4625ae3015aea9c5de71a28ef._comment b/doc/forum/Git_annex_hangs/comment_1_e6b854d4625ae3015aea9c5de71a28ef._comment
new file mode 100644
index 0000000000..34df8fb971
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_1_e6b854d4625ae3015aea9c5de71a28ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-10T18:51:57Z"
+ content="""
+I have followed up there, but the basic answer is, pass --debug to see what it's doing.
+"""]]
diff --git a/doc/forum/Git_annex_hangs/comment_2_4f848771e60c38321a97361b0d1b33dd._comment b/doc/forum/Git_annex_hangs/comment_2_4f848771e60c38321a97361b0d1b33dd._comment
new file mode 100644
index 0000000000..cc1b23c083
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_2_4f848771e60c38321a97361b0d1b33dd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawktbkKjilg70XC9XBFpIgVhtfLYH-0UMHY"
+ nickname="Tad"
+ subject="comment 2"
+ date="2014-10-10T19:08:49Z"
+ content="""
+--debug is useful. Thanks! I have tried from scratch and added backend after creating file and that worked. I will use --debug in the future
+"""]]
diff --git a/doc/forum/Git_annex_hangs/comment_3_a07abdd1dc21a69ad6be0526edaeffc1._comment b/doc/forum/Git_annex_hangs/comment_3_a07abdd1dc21a69ad6be0526edaeffc1._comment
new file mode 100644
index 0000000000..452f175a58
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_3_a07abdd1dc21a69ad6be0526edaeffc1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 3"
+ date="2014-10-12T20:14:36Z"
+ content="""
+Probably the same problem reported here:
+<https://github.com/datalad/datalad/issues/12>
+
+I guess this is a mismatch between the version of git that git-annex was built with and the version it's using. In particular, git check-attr behavior varies between git older than 1.7.7 and newer, and git-annex picks the version at build time.
+
+So, I think this is a broken Ubuntu PPA, and if that's the current one, the maintainer of the PPA needs to be contacted to update the git-annex to match the git version, or depend on an appropriate git version.
+"""]]
diff --git a/doc/forum/Git_annex_hangs/comment_4_2ba5992c32753ed03ddd5c12264e9acf._comment b/doc/forum/Git_annex_hangs/comment_4_2ba5992c32753ed03ddd5c12264e9acf._comment
new file mode 100644
index 0000000000..d46dea1cb5
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_4_2ba5992c32753ed03ddd5c12264e9acf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnjssENdbjzvblxOm4Qr8x2C-BdIV_k_y4"
+ nickname="Tadeusz"
+ subject="comment 4"
+ date="2014-10-15T15:25:27Z"
+ content="""
+I will look into PPA. I hope it won't be this slow:) How long would it take for git annex to add/modify/sync files (~100) taking up 100GB or so? Days? Hours? Minutes?
+"""]]
diff --git a/doc/forum/Git_annex_hangs/comment_5_5fd749f92343079b3916a4d32ddf39c7._comment b/doc/forum/Git_annex_hangs/comment_5_5fd749f92343079b3916a4d32ddf39c7._comment
new file mode 100644
index 0000000000..892f2abf2f
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_5_5fd749f92343079b3916a4d32ddf39c7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2014-10-20T15:28:01Z"
+ content="""
+Adding the files will take as long as it takes to read and hash 
+the conents of those files from disk. If that's too slow, `--backend=WORM`
+will bypass the hashing, so it will take seconds.
+
+Time required to sync files depends on the bandwidth to wherever it's
+syncing with, obviously.
+"""]]
diff --git a/doc/forum/Git_annex_hangs/comment_6_4abe6aa966feea4e1881f6a2fbe7a007._comment b/doc/forum/Git_annex_hangs/comment_6_4abe6aa966feea4e1881f6a2fbe7a007._comment
new file mode 100644
index 0000000000..2d84b08e5f
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_6_4abe6aa966feea4e1881f6a2fbe7a007._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/yx5Y6EI1t.759Jsu63ZWqYclCmpOmxxd.ramtw--#7114a"
+ nickname="Ioanas"
+ subject="Same issue here "
+ date="2015-05-26T17:12:59Z"
+ content="""
+I am also experiencing the same issue. How do I solve this? Re-installing git and git-annex (as some linked GitHub thread suggested) did not help.
+"""]]
diff --git a/doc/forum/Git_annex_hangs/comment_7_f3ea42dc6699275143ba44e7f57e7d5e._comment b/doc/forum/Git_annex_hangs/comment_7_f3ea42dc6699275143ba44e7f57e7d5e._comment
new file mode 100644
index 0000000000..336a4ee057
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_7_f3ea42dc6699275143ba44e7f57e7d5e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="parmour@1304ead3ef9008fa9fe66af7c8678dec867328da"
+ nickname="parmour"
+ subject="Similar sounding issue"
+ date="2016-01-28T15:02:31Z"
+ content="""
+I have seen a similar sounding version on Centos 6.5. I had git version 2.6.4 and installed git annex using:
+wget http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
+rpm -ivh epel-release-6-8.noarch.rpm
+yum install git-annex
+
+git annex would hang when running 'git annex add'
+
+When I changed the git version to be 1.7.1 this problem went away. So it is something to do with the combination of client git version and git annex version.
+"""]]
diff --git a/doc/forum/Git_annex_hangs/comment_8_1bad17001364d192e0d9affe5f0ea554._comment b/doc/forum/Git_annex_hangs/comment_8_1bad17001364d192e0d9affe5f0ea554._comment
new file mode 100644
index 0000000000..e0d360f371
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_8_1bad17001364d192e0d9affe5f0ea554._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2016-01-29T17:47:02Z"
+ content="""
+This was fixed in git-annex back in January 2015. It now checks the git
+version at runtime, not assuming it will be used with as recent a version
+of git as was available at compile time.
+
+So if you're still seeing this problem, upgrading git-annex or git is the only
+solution.
+"""]]
diff --git a/doc/forum/Git_annex_hangs/comment_9_07ae4582a4403b4f0185dbc1830642ad._comment b/doc/forum/Git_annex_hangs/comment_9_07ae4582a4403b4f0185dbc1830642ad._comment
new file mode 100644
index 0000000000..55de021f06
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_9_07ae4582a4403b4f0185dbc1830642ad._comment
@@ -0,0 +1,54 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="Hanging problem still there"
+ date="2017-05-17T14:05:41Z"
+ content="""
+Hi,
+
+it seems my git-annex repository is also affected by the \"hanging\" bug.
+
+Any operation of git-annex just hangs and doesn't do anything. Problem occurs with: sync, whereis, fsck (and with everything I tested).
+
+    git-annex whereis file --debug
+    [2017-05-17 15:57:34.895221948] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+    [2017-05-17 15:57:34.901449143] process done ExitSuccess
+    [2017-05-17 15:57:34.901536719] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2017-05-17 15:57:34.905894352] process done ExitSuccess
+    [2017-05-17 15:57:34.906485313] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..6ccd8cbac5fffa4763294ed88cb1ebc0920c3812\",\"--pretty=%H\",\"-n1\"]
+    [2017-05-17 15:57:34.917489743] process done ExitSuccess
+
+Then it just hangs..
+
+    git-annex sync --debug
+    [2017-05-17 15:58:26.366522677] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+    [2017-05-17 15:58:26.371989858] process done ExitSuccess
+    [2017-05-17 15:58:26.372083975] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2017-05-17 15:58:26.384517659] process done ExitSuccess
+    [2017-05-17 15:58:26.385061668] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..6ccd8cbac5fffa4763294ed88cb1ebc0920c3812\",\"--pretty=%H\",\"-n1\"]
+    [2017-05-17 15:58:26.390054368] process done ExitSuccess
+
+Also here, hangs..
+
+I \"installed\" git-annex from the pre-compiled binaries (i.e., copied it somewhere and put a simlink to git-annex and git-annex-shell into $HOME/bin).
+
+Versions are:
+
+    git --version
+    git version 1.8.3.1
+
+    git-annex version
+    git-annex version: 6.20170321-gf3dee9d65
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
+The setup was working quite fine for a while and now the problem just appeared. Actually, right before I noticed the problem I did git-annex move [...] -J10 from another machine to this repo but it didn't seem to work correctly, so I pressed CTRL-C..
+
+I cannot reboot the server, since I don't have root access.
+
+"""]]
diff --git a/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified.mdwn b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified.mdwn
new file mode 100644
index 0000000000..fc4c3ed037
--- /dev/null
+++ b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified.mdwn
@@ -0,0 +1,33 @@
+Hi,
+
+Whenever I sync files with windows, it shows the every binary file as modified. I've just cloned "fresh" repo from a linux host and ```git annex get```ed the 15-11-03 folder.
+Running git annex status 15-11-03 shows
+
+```
+M ..\15-11-03/ADL Update 11-03-15.pptx
+M ..\15-11-03/Gaming-Rage-Face.jpg
+M ..\15-11-03/eluted-absorption-spectra.png
+M ..\15-11-03/elution.png
+M ..\15-11-03/prep-diagram.png
+M ..\15-11-03/rc-elution-01 (2015 Nov 03).csv
+M ..\15-11-03/rc-elution-02 (2015 Nov 03).csv
+M ..\15-11-03/rc-elution-03 (2015 Nov 03).csv
+M ..\15-11-03/rc-prep-01.h5
+M ..\15-11-03/rc-test-1 (2015 Nov 03).csv
+M ..\15-11-03/rc-test-2 (2015 Nov 03).csv
+M ..\15-11-03/wash-absorption.png
+```
+
+Edit: I should add that this repo is untrusted. Doing sync on it just ends up pulling from remotes, not pushing anywhere:
+
+```
+λ git annex sync
+commit  (recording state in git...)
+ok
+pull origin
+ok
+pull github
+ok
+```
+
+How would I check if this is a problem with my installation or a bug in git annex?
diff --git a/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_1_b6e8f634187d1f5840641633cb82301a._comment b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_1_b6e8f634187d1f5840641633cb82301a._comment
new file mode 100644
index 0000000000..46b259e712
--- /dev/null
+++ b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_1_b6e8f634187d1f5840641633cb82301a._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="aloukian"
+ subject="comment 1"
+ date="2015-11-06T17:33:32Z"
+ content="""
+In particular, I have set up Gpg4Win to use a smart card for ssh-ing. It provides its own sha executables that are on the path and I wonder if that is the reason that the files always show up as modified.
+"""]]
diff --git a/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_2_ab24dacf101a1a7e33e5976f72f6fe05._comment b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_2_ab24dacf101a1a7e33e5976f72f6fe05._comment
new file mode 100644
index 0000000000..6b4cdd13c2
--- /dev/null
+++ b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_2_ab24dacf101a1a7e33e5976f72f6fe05._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-11-10T19:31:18Z"
+ content="""
+git annex status doesn't checksum files, so it can't be the sha executables
+in PATH.
+
+Instead, git-annex status, when in a direct mode repository like on
+windows, checks the recorded timestamps etc of the files to determine if
+they're modified.
+
+I suppose one possibility is a time zone change or DST change. Did you
+recently "fall back" from DST in your location?
+
+Due to the braindead way Windows deals with timezone changes, 
+the timestamps of files appear to *change* when the timezone has changed.
+git-annex tries to detect this situation and offset to get back a stable
+timestamp that can be used to detect file modifications, but I can't say
+that I've tested this situation very carefully, beyond the one very painful
+day implementing that workaround.
+
+Anyway, running `git annex sync` may result in it noticing that nothing has
+actually changed and get the status display to work better.
+"""]]
diff --git a/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_3_cade18a9487c583329249c2d3e72ca46._comment b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_3_cade18a9487c583329249c2d3e72ca46._comment
new file mode 100644
index 0000000000..8a8fc64e78
--- /dev/null
+++ b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_3_cade18a9487c583329249c2d3e72ca46._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="aloukian"
+ subject="comment 3"
+ date="2015-11-10T20:35:58Z"
+ content="""
+Well, sync'ing didn't help, though I didn't do sync --content. I'll try that and maybe it will work.
+"""]]
diff --git a/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_4_1d2281f79cd0c2a1a3599cae42df0187._comment b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_4_1d2281f79cd0c2a1a3599cae42df0187._comment
new file mode 100644
index 0000000000..0683f39585
--- /dev/null
+++ b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_4_1d2281f79cd0c2a1a3599cae42df0187._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="neocryptek@659edac901ffbc8e541a974f8f18987eeafc63bd"
+ nickname="neocryptek"
+ subject="comment 4"
+ date="2015-11-21T17:52:26Z"
+ content="""
+I've been having the same problem on windows direct repository and now that I think about it, it could have started after daylight savings time (I also had the windows ssh upgrade problems that took a few days to figure out around the same time). No matter what I do I can't get it to stop showing up as modified in the status view. I've tried sync, sync --content, adding them again, etc. My status output is getting huge as everything I've added on windows is showing up there as modified now. I'm not sure if it's affecting the performance of status or sync (status is just generally very slow on windows direct repos with increasing number of files).
+"""]]
diff --git a/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_5_5f2f2275ee9de47273671a8009217fb9._comment b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_5_5f2f2275ee9de47273671a8009217fb9._comment
new file mode 100644
index 0000000000..b266f442f7
--- /dev/null
+++ b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_5_5f2f2275ee9de47273671a8009217fb9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="neocryptek@659edac901ffbc8e541a974f8f18987eeafc63bd"
+ nickname="neocryptek"
+ subject="comment 5"
+ date="2015-12-18T18:09:54Z"
+ content="""
+Aloukian were you able to get anything to help? Nothing I've tried has helped.
+
+Joey any more ideas (besides ditching windows :) )?
+"""]]
diff --git a/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_6_54155343eef8c6f95574dffb3910fc61._comment b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_6_54155343eef8c6f95574dffb3910fc61._comment
new file mode 100644
index 0000000000..6f179bcc1e
--- /dev/null
+++ b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_6_54155343eef8c6f95574dffb3910fc61._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2015-12-19T16:30:55Z"
+ content="""
+Sorry I haven't had a chance to think about this problem any more.
+The v6 repository format I've been working on should eliminate class problem
+anyway. It will let git itself be able to tell if annexed files are modified
+or not.
+
+But there is something you can try to debug what's going on.
+
+0. Run the git bash shell and cd to your repository's directory.
+1. `cat .git/annex/sentinal.cache` and paste its content.
+2. `stat .git/annex/sentinal --terse` and paste the output of that.
+2. Pick one of the files wrongly showing as modified. Run `stat $file --terse`
+  and paste the output of that.
+3. And then this command should output the inode cache for the file.
+   Be sure to replace $file with the name of the file:
+   `cat $(git annex find $file --format='.git/annex/objects/${hashdirlower}${key}/${key}.cache`)
+
+But hmm, as I was running windows to get these instructions, I seem to have
+reproduced the problem myself! In my case:
+
+* The sentinal.cache contained data matching the stat of the sentinal file.
+* The annexed file's mtime and size (and even inode) matched the cached
+  values.
+* `git annex status` showed the file as modifed; `git annex sync` found
+  nothing to commit and didn't change that.
+
+Some more debugging and.. It seems this is not a horrible windows-specific
+time zone problem. Thank goodness. Instead, what's going on is that `git -c
+core.bare=false status` does not show these files as typechanged, but as
+modified instead. Since `git annex status` only has special case handling
+for typechanged files, it just passes the M through and displays it.
+
+So, this is only a display problem, and thus nothing to worry about really.
+Ie, the rest of git-annex's behavior should not be impacted at all.
+
+It's not windows specific.. Same happens on FAT on Linux. I think git's
+behavior probably changed since an earlier version; I'm pretty sure its
+status showed typechanged before. Anyway, I've fixed the status display,
+on these systems it will now treat files git says are modified the same
+as typechanged, and so will use git-annex's inode cache info to diplay
+an accurate status for them.
+"""]]
diff --git a/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_7_cbf7035b218566a9fa1cb656290a9cf0._comment b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_7_cbf7035b218566a9fa1cb656290a9cf0._comment
new file mode 100644
index 0000000000..25ab25c1e3
--- /dev/null
+++ b/doc/forum/Git_annex_status_always_showing_annexed_files_as_modified/comment_7_cbf7035b218566a9fa1cb656290a9cf0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="neocryptek"
+ subject="comment 7"
+ date="2016-01-21T03:38:56Z"
+ content="""
+version 6.20160114 fixes the problem on windows and status seems to be faster now (probably due to all the overhead of printing text to the console).
+
+Thanks!
+"""]]
diff --git a/doc/forum/Git_annex_syncing_speed__44___possible__63__.mdwn b/doc/forum/Git_annex_syncing_speed__44___possible__63__.mdwn
new file mode 100644
index 0000000000..d1fcc74aaa
--- /dev/null
+++ b/doc/forum/Git_annex_syncing_speed__44___possible__63__.mdwn
@@ -0,0 +1,21 @@
+Hello
+
+I'm trying Git annex latest builds available in Linux & Android
+Here is the scenario :-
+
+Syncing 2 peer devices running Linux & Android
+Devices can access each other directly over Cisco VPN encrypted link
+
+Currently, syncing files via rsync over webdav (over Cisco VPN)
+Everything is working, manual file tracking is an issue.
+
+Here's where Git annex steps in,
+I've configures external jabber account so they can talk to each other.
+
+But the transfers are super-slow over internet,
+I'm guessing Cisco VPN adding 15-20% overhead + SSH adding another 20-30% overhead.
+
+Since the network link is trusted, is there any way to speed things up assuming Cisco solution
+remains in place?
+
+looking to solve this issue
diff --git a/doc/forum/Git_annex_syncing_speed__44___possible__63__/comment_1_8aa224b3016dc38e4cea8ee1865a3ab6._comment b/doc/forum/Git_annex_syncing_speed__44___possible__63__/comment_1_8aa224b3016dc38e4cea8ee1865a3ab6._comment
new file mode 100644
index 0000000000..eb0e65f801
--- /dev/null
+++ b/doc/forum/Git_annex_syncing_speed__44___possible__63__/comment_1_8aa224b3016dc38e4cea8ee1865a3ab6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2013-07-12T20:09:32Z"
+ content="""
+Not sure if it applies to your devices, but I considerably speed up SSH transfers on my raspberry pi by using
+
+    Ciphers arcfour
+
+in the ssh configuration.
+"""]]
diff --git a/doc/forum/Git_filters__58___smudgeToFile_and_cleanFromFile.mdwn b/doc/forum/Git_filters__58___smudgeToFile_and_cleanFromFile.mdwn
new file mode 100644
index 0000000000..a06fc18f69
--- /dev/null
+++ b/doc/forum/Git_filters__58___smudgeToFile_and_cleanFromFile.mdwn
@@ -0,0 +1,7 @@
+Hello Joey!
+
+I found this patch set that you created few years ago:
+https://lore.kernel.org/git/1466195481-23209-1-git-send-email-joeyh@joeyh.name/
+
+I need the exact same feature :)
+What is your take on it? Any interest in collaborating to try to merge this upstream?
diff --git a/doc/forum/Git_filters__58___smudgeToFile_and_cleanFromFile/comment_1_f21dc5255ce986ef0317503ebd40b4f5._comment b/doc/forum/Git_filters__58___smudgeToFile_and_cleanFromFile/comment_1_f21dc5255ce986ef0317503ebd40b4f5._comment
new file mode 100644
index 0000000000..73eddaabdb
--- /dev/null
+++ b/doc/forum/Git_filters__58___smudgeToFile_and_cleanFromFile/comment_1_f21dc5255ce986ef0317503ebd40b4f5._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-08-04T16:19:57Z"
+ content="""
+Since filter.foo.process was being developed at the same time, they had a
+good reason to not accept the patch.
+
+This page tracks ways that the current git interface limits git-annex:
+[[todo/git_smudge_clean_interface_suboptiomal]]
+
+Since I've been able to work around most of the problems with the
+interface, the main consequences are slightly slower `git add` of large
+files and lack of integration with commands like `git stash` that update
+the working tree without running any hook. This is minor enough that most
+people won't be bothered by it, so implementing a better interface is not a
+priority for me.
+
+I would support git's smudge/clean interface being improved, but the benefits
+to git-annex are too small to make me want to dive back into implementing
+it myself.
+
+(Adding a git hook that runs after `git stash`, `git reset --hard` etc
+would interestingly fix the biggest remaining issue in a way that avoids
+the issue of improving the interface. Adding hooks is comparatively
+easy...)
+"""]]
diff --git a/doc/forum/Git_filters__58___smudgeToFile_and_cleanFromFile/comment_2_4ded2a4b866102450ef96c76b7be94fe._comment b/doc/forum/Git_filters__58___smudgeToFile_and_cleanFromFile/comment_2_4ded2a4b866102450ef96c76b7be94fe._comment
new file mode 100644
index 0000000000..8b3f7dcb52
--- /dev/null
+++ b/doc/forum/Git_filters__58___smudgeToFile_and_cleanFromFile/comment_2_4ded2a4b866102450ef96c76b7be94fe._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="xvorsx@a3fc1a0cf228782f624e5eb21ba8a664227b6c60"
+ nickname="xvorsx"
+ avatar="http://cdn.libravatar.org/avatar/f8a11fb3152e472307bde487d188b23a"
+ subject="comment 2"
+ date="2023-08-07T07:19:25Z"
+ content="""
+Thank you for the reference!
+
+I may try to use this trick, but I doubt it would be sufficient for me:
+
+> To avoid the problem, git-annex smudge --clean relies on a not very well documented trick: It is fed a possibly large file on stdin, but when it closes the FD without reading. git gets a SIGPIPE and stops reading and sending the file. Instead of reading from stdin, git-annex abuses the fact that git provides the clean filter with the work tree filename, and reads and cleans the file itself, more efficiently.
+
+I will keep you updated on the progress in this direction.
+"""]]
diff --git a/doc/forum/Git_remote__63_____40__bitbucket__44___github__41__.mdwn b/doc/forum/Git_remote__63_____40__bitbucket__44___github__41__.mdwn
new file mode 100644
index 0000000000..245b298ff4
--- /dev/null
+++ b/doc/forum/Git_remote__63_____40__bitbucket__44___github__41__.mdwn
@@ -0,0 +1 @@
+Is it possible to use bitbucket as a remote?
diff --git a/doc/forum/Git_remote__63_____40__bitbucket__44___github__41__/comment_1_8a6de753ac0aa56f470b2aefca628388._comment b/doc/forum/Git_remote__63_____40__bitbucket__44___github__41__/comment_1_8a6de753ac0aa56f470b2aefca628388._comment
new file mode 100644
index 0000000000..c6c7f6e1c8
--- /dev/null
+++ b/doc/forum/Git_remote__63_____40__bitbucket__44___github__41__/comment_1_8a6de753ac0aa56f470b2aefca628388._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-09-18T17:43:44Z"
+ content="""
+You can use any git repository as a git remote in git-annex, since git-annex uses plain old git repos.
+
+You will need to add some kind of [[special_remote|special_remotes]] to hold the content of the files stored in git-annex however.
+"""]]
diff --git a/doc/forum/Git_repos_in_git_annex__63__.mdwn b/doc/forum/Git_repos_in_git_annex__63__.mdwn
new file mode 100644
index 0000000000..2d16a66592
--- /dev/null
+++ b/doc/forum/Git_repos_in_git_annex__63__.mdwn
@@ -0,0 +1,7 @@
+Hello,
+
+A mode of operation that I find comfortable, and from various online posts it seems that so do some others, is putting whole git repositories in dropbox.
+
+It seems that currently this mode of operations if not supported in a simple manner. (i.e. just add and let assistant do the work). Is there any workaround or possibility to do this?
+
+Thanks!
diff --git a/doc/forum/Git_repos_in_git_annex__63__/comment_1_8aaa0d83e8fcd5997f6b0097f3b21622._comment b/doc/forum/Git_repos_in_git_annex__63__/comment_1_8aaa0d83e8fcd5997f6b0097f3b21622._comment
new file mode 100644
index 0000000000..fac5ad5b11
--- /dev/null
+++ b/doc/forum/Git_repos_in_git_annex__63__/comment_1_8aaa0d83e8fcd5997f6b0097f3b21622._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="EvanDeaubl"
+ ip="68.230.56.163"
+ subject="comment 1"
+ date="2013-07-28T02:40:24Z"
+ content="""
+I'll give this warning upfront: this works for me, but it requires manual intervention, and I wouldn't be surprised if this spectacularly broke with the assistant running in full auto mode.
+
+I'm currently storing git repos inside of my annex by using a separated git dir, so that git doesn't detect the nested repository and balk at adding it. Doing a git clone or git init with a --separate-git-dir=<git dir> argument puts what would normally be in .git in that directory, and creates a simple .git file in its place which references the separated git dir.
+
+When I'm not using the repo, I move the .git file out of the directory, and everything looks like regular files to git-annex. When I want to use it, I move it back in place, and any git operations inside the repo directory use the inner git repo itself.
+
+Another option I used for a while was to store bare repos in the annex, and doing checkouts from those repos.
+"""]]
diff --git a/doc/forum/Git_repos_in_git_annex__63__/comment_2_8546341a561a5f55216c2f437f8ec0c2._comment b/doc/forum/Git_repos_in_git_annex__63__/comment_2_8546341a561a5f55216c2f437f8ec0c2._comment
new file mode 100644
index 0000000000..90d40d8aa6
--- /dev/null
+++ b/doc/forum/Git_repos_in_git_annex__63__/comment_2_8546341a561a5f55216c2f437f8ec0c2._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="Many months later..."
+ date="2014-05-08T16:49:26Z"
+ content="""
+Here is the relevant bug: <http://git-annex.branchable.com/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X>
+
+Here's my scenario: I have been using Dropbox for several years.  I want to move to git-annex.
+
+For some time I used Bazaar repos inside Dropbox.  A couple of times I accidentally modified files on one computer before another finished syncing, and the repo became mildly corrupted, but I recovered it okay.
+
+Recently I switched to git, and so far, so good.  I'm careful not to make any changes to my files before Dropbox is finished syncing, so everything works fine.
+
+But when I add a directory containing a git repo to an annex, git-annex ignores the .git directory, so the repo isn't synced.
+
+I read this forum thread, and I read the bug report, but there don't appear to be any real solutions.
+
+This seems like what should be a fairly common use case: a user has a directory of simple text files, like shell scripts or org-mode files.  He uses git to version-control them, and he uses Dropbox to sync the files and the git repo automatically between computers.  Now the user wants to use git-annex instead, but if he does this, it will mean having to choose between:
+
+* No longer using git to version-control the files
+* Only using git on a single system, which means that he can't make commits or do any other git operations when using other systems
+* Keeping separate git repos on each system, and making the same commits manually on each one...which would be a mess
+* Keeping separate git repos on each system, and using a script to make commits automatically--which would mean commits wouldn't be any more useful than a simple timed backup script
+
+I guess I could just use git instead of Dropbox or git-annex, but then I must choose between either:
+
+* Only being able to sync repos when both systems are online
+* Having to store repos in plaintext on remote servers
+
+This is one of my primary use cases for Dropbox/git-annex.  I'd really appreciate any help in figuring this out.  Thanks.
+"""]]
diff --git a/doc/forum/Git_repos_in_git_annex__63__/comment_3_88e37911a0280d817559b2d51ddb1d4e._comment b/doc/forum/Git_repos_in_git_annex__63__/comment_3_88e37911a0280d817559b2d51ddb1d4e._comment
new file mode 100644
index 0000000000..efd86d8f8f
--- /dev/null
+++ b/doc/forum/Git_repos_in_git_annex__63__/comment_3_88e37911a0280d817559b2d51ddb1d4e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="memeplex"
+ avatar="http://cdn.libravatar.org/avatar/84a611000e819ef825421de06c9bca90"
+ subject="comment 3"
+ date="2017-04-14T22:35:49Z"
+ content="""
+Another use case is when you use annex for backup. For example I keep most of my files (dotfiles, scripts, music, books, etc) in a \"home\" git annex repo. Part of them is stored in google drive, part in a pendrive, part in my home computer, part in my work computer. Every once in a while I sync everything into my home computer and into an additional external hard drive remote that I keep as a backup. Sadly, my archived git projects can't be managed like that. Nevertheless, it's not a big deal since they are already in the cloud (gitlab or github) and in my local filesystem. Besides, since they are archived, I can just create tarballs and add them to the annex (and in case annex allowed to store .git directories, I'd not be really comfortable with the huge amount of symlinks that would produce).
+
+That said, it's kind of a bathos that the illusion of a distributed, decentralized, redundant, versioned, annotated, etc. filesystem over git is broken by git itself.   
+"""]]
diff --git a/doc/forum/Git_repositories_in_the_annex__63__.mdwn b/doc/forum/Git_repositories_in_the_annex__63__.mdwn
new file mode 100644
index 0000000000..a18af8c2c7
--- /dev/null
+++ b/doc/forum/Git_repositories_in_the_annex__63__.mdwn
@@ -0,0 +1,5 @@
+First of all thanks for the great work. git-annex looks very nice already!
+
+I wonder if it's possible to add Git repositories to the annex. In my current Dropbox setup I drop some small Git repositories into the Dropbox to keep them in sync on two computers. 
+
+This is obviously not possible with git-annex, as the annex itself is a Git repository and sub-repositories (directories with .git folders) are ignored. But in some cases people might want to be able to drop "anything" into the annex, maybe even Git repositories (e.g. the "nomad" usecase)...
diff --git a/doc/forum/Github_pull_request_with_git-annex.mdwn b/doc/forum/Github_pull_request_with_git-annex.mdwn
new file mode 100644
index 0000000000..b0ae1da5d3
--- /dev/null
+++ b/doc/forum/Github_pull_request_with_git-annex.mdwn
@@ -0,0 +1,11 @@
+I would like to use git annex with github. Here what I did:
+
+1. Create github directory "a". Added all the special remote and git annex files. Pushed them to the "a" using "git annex sync."
+2. Fork the repository on gihub to "b". Clone it and enable remote and I could pull annexed files.
+3. Added repository "a" as "upstream" tracking remote to "b".
+3. Created a second special remote for "b". Added new git annex files to it. Used "git annex sync origin" to push the changed files to the forked repository "b".
+4. Now I would like to create a pull request. What are branches I should create pull request for?  a:synced/git-annex vs b:synced/git-annex? Or, a:synced/git-annex vs b:git-annex? Do I need to create separate pull request for the "master"?
+
+Thanks for the help.
+
+ 
diff --git a/doc/forum/Github_pull_request_with_git-annex/comment_1_03023d2fba47e84d03573d996e8366cf._comment b/doc/forum/Github_pull_request_with_git-annex/comment_1_03023d2fba47e84d03573d996e8366cf._comment
new file mode 100644
index 0000000000..ef165fe94f
--- /dev/null
+++ b/doc/forum/Github_pull_request_with_git-annex/comment_1_03023d2fba47e84d03573d996e8366cf._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-19T18:17:17Z"
+ content="""
+Your pull request should be for the branch you changed. In this case, the
+`master` branch. This is the same as adding files to a regular git
+repository and making a pull request for that.
+
+The changes that git-annex makes to the `git-annex branch` can either be
+ignored by the person who merges your pull request, or they could opt to
+fetch your git-annex branch and let git-annex auto-merge it for them. A
+manual review and pull request of the `git-annex` branch is not likely to be
+productive. Whether they need to merge your `git-annex` branch into their
+`git-annex` branch depends on whether git-annex's information about eg,
+locations of file contents needs to be passed along with your pull
+request.
+
+Note that GitHub does not support using git-annex to upload the content of
+annexed files to it. (GitLab does support this.) This GitHub limitation
+may cause problems with this kind of workflow.
+"""]]
diff --git a/doc/forum/Gitolite_problems.mdwn b/doc/forum/Gitolite_problems.mdwn
new file mode 100644
index 0000000000..15b7d62698
--- /dev/null
+++ b/doc/forum/Gitolite_problems.mdwn
@@ -0,0 +1,11 @@
+I am having some issues trying to make git-annex work with the latest version of Gitolite, 
+When running git annex sync, or git annex copy --to I get.
+"""
+Failed to get annex.uuid configuration of repository origin
+
+Instead, got: "annex.uuid=\ncore.gcrypt-id=\n"
+"""
+
+Has anyone found any solution to this? Also, I am using the latest version of Gitolite, because I wanted to see whether it would work.
+Thanks, Zack.
+EDIT: It might also be worthy to note that I did have a go at following the guide on this site.
diff --git a/doc/forum/Gitolite_problems/comment_1_3a41f9b6bddc060b1fa9e35b9ce8b55f._comment b/doc/forum/Gitolite_problems/comment_1_3a41f9b6bddc060b1fa9e35b9ce8b55f._comment
new file mode 100644
index 0000000000..b29fdf2a3e
--- /dev/null
+++ b/doc/forum/Gitolite_problems/comment_1_3a41f9b6bddc060b1fa9e35b9ce8b55f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Renaud"
+ ip="126.10.66.235"
+ subject="comment 1"
+ date="2014-01-11T14:29:08Z"
+ content="""
+I had that problem when I tried to access a newly created remote repository.
+It seems git-annex doesn't recognize anymore if the remote repository has been initialized or not.
+The workaround I used is create a local repository, initialize it with git annex, `clone --bare` it, add the bare repository as a remote and `git annex sync` it to initialize the bare repository. Then, you can put the bare repository where gitolite usualy keep its repositories and use it normally.
+"""]]
diff --git a/doc/forum/Gitolite_problems/comment_2_ef156bf7a1e17496c5fc1f592d45f2ad._comment b/doc/forum/Gitolite_problems/comment_2_ef156bf7a1e17496c5fc1f592d45f2ad._comment
new file mode 100644
index 0000000000..7c4e8662f4
--- /dev/null
+++ b/doc/forum/Gitolite_problems/comment_2_ef156bf7a1e17496c5fc1f592d45f2ad._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqaNwDQ367zpW6cIRviLz6zJZZFODgoEI"
+ nickname="Zack"
+ subject="Almost there!"
+ date="2014-01-12T19:13:29Z"
+ content="""
+Thanks for the help (I can now clone the repo.), but I now get this.
+get file FATAL: bad git-annex-shell command: git-annex-shell 'configlist' '/annex2.git' at /opt/gitolite2/bin/commands/git-annex-shell line 25, <DATA> line 1.
+"""]]
diff --git a/doc/forum/HTTP_uploads.mdwn b/doc/forum/HTTP_uploads.mdwn
new file mode 100644
index 0000000000..c24180d9ee
--- /dev/null
+++ b/doc/forum/HTTP_uploads.mdwn
@@ -0,0 +1,133 @@
+Does git-annex support **uploading** over HTTP? I learned how to set up a public (anonymous, download-only) HTTP remote -- a regular git remote, **not** a special remote -- by following [[tips/setup_a_public_repository_on_a_web_site/]]. Now I also want private repos (so, non-anonymous downloads), and, for completeness, uploads.
+
+I know those Apache-based instructions don't cover those cases. I'm working on extending them. I've [ported those instructions into Gitea](https://github.com/neuropoly/gitea/pull/1), and now I can `git clone` with both gitea's SSH and HTTP URLs and `git annex get` works, and permissions are enforced on private repos.
+
+So I've got non-anonymous downloads covered. But how do I make `git annex sync --content` (or equivalently, `git annex copy --to origin`) upload when the remote is an HTTP URL? Does it know how? I've experimented and haven't been able to get it to work, but neither does it give me a clear error rejecting my attempt.
+
+
+```
+[kousu@nigiri CANDICE-fMRI-]$ git config annex.debug true
+[kousu@nigiri CANDICE-fMRI-]$ git annex copy --to origin
+[2022-05-08 02:52:23.217458919] (Utility.Process) process [28036] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2022-05-08 02:52:23.219000083] (Utility.Process) process [28036] done ExitSuccess
+[2022-05-08 02:52:23.219516464] (Utility.Process) process [28037] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2022-05-08 02:52:23.221135085] (Utility.Process) process [28037] done ExitSuccess
+[2022-05-08 02:52:23.22179462] (Utility.Process) process [28038] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..6c3b23ed5b89e73fdb170e4dfb3dc4f7324acd87","--pretty=%H","-n1"]
+[2022-05-08 02:52:23.224259745] (Utility.Process) process [28038] done ExitSuccess
+[2022-05-08 02:52:23.225976282] (Utility.Process) process [28039] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2022-05-08 02:52:23.228332152] (Utility.Process) process [28040] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--error-unmatch","--"]
+[2022-05-08 02:52:23.229159541] (Utility.Process) process [28041] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2022-05-08 02:52:23.22958377] (Utility.Process) process [28042] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2022-05-08 02:52:23.230213916] (Utility.Process) process [28039] done ExitSuccess
+[2022-05-08 02:52:23.231313697] (Utility.Process) process [28043] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[...]
+copy sub-BAN04/anat/sub-BAN02_T1w.nii.gz [2022-05-08 02:52:53.078448893] (Utility.Url) Request {
+  host                 = "data.praxisinstitute.org.dev.neuropoly.org"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding",""),("User-Agent","git-annex/10.20220322-g959beeea9")]
+  path                 = "/UofC/CANDICE-fMRI-.git/annex/objects/433/2b9/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz"
+  queryString          = ""
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+  proxySecureMode      = ProxySecureWithConnect
+}
+
+[2022-05-08 02:52:53.16577961] (Utility.Process) process [28097] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","credential","fill"]
+Username for 'https://data.praxisinstitute.org.dev.neuropoly.org': kousu
+Password for 'https://kousu@data.praxisinstitute.org.dev.neuropoly.org': 
+[2022-05-08 02:52:56.868778349] (Utility.Process) process [28097] done ExitSuccess
+[2022-05-08 02:52:56.869119387] (Utility.Url) Request {
+  host                 = "data.praxisinstitute.org.dev.neuropoly.org"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding",""),("Authorization","<REDACTED>"),("User-Agent","git-annex/10.20220322-g959beeea9")]
+  path                 = "/UofC/CANDICE-fMRI-.git/annex/objects/433/2b9/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz"
+  queryString          = ""
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+  proxySecureMode      = ProxySecureWithConnect
+}
+
+[2022-05-08 02:52:56.954725712] (Utility.Process) process [28098] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","credential","reject"]
+[2022-05-08 02:52:56.956656836] (Utility.Process) process [28098] done ExitSuccess
+[2022-05-08 02:52:56.957140664] (Utility.Url) Request {
+  host                 = "data.praxisinstitute.org.dev.neuropoly.org"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding",""),("User-Agent","git-annex/10.20220322-g959beeea9")]
+  path                 = "/UofC/CANDICE-fMRI-.git/annex/objects/93/kp/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz"
+  queryString          = ""
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+  proxySecureMode      = ProxySecureWithConnect
+}
+
+[2022-05-08 02:52:57.041148655] (Utility.Process) process [28099] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","credential","fill"]
+Username for 'https://data.praxisinstitute.org.dev.neuropoly.org': kousu
+Password for 'https://kousu@data.praxisinstitute.org.dev.neuropoly.org': 
+[2022-05-08 02:53:00.095495453] (Utility.Process) process [28099] done ExitSuccess
+[2022-05-08 02:53:00.095774849] (Utility.Url) Request {
+  host                 = "data.praxisinstitute.org.dev.neuropoly.org"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding",""),("Authorization","<REDACTED>"),("User-Agent","git-annex/10.20220322-g959beeea9")]
+  path                 = "/UofC/CANDICE-fMRI-.git/annex/objects/93/kp/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz"
+  queryString          = ""
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+  proxySecureMode      = ProxySecureWithConnect
+}
+
+[2022-05-08 02:53:00.183376947] (Utility.Process) process [28100] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","credential","reject"]
+[2022-05-08 02:53:00.18501078] (Utility.Process) process [28100] done ExitSuccess
+(not found) failed
+[2022-05-08 02:53:00.185253039] (Utility.Process) process [28043] done ExitSuccess
+[2022-05-08 02:53:00.185356286] (Utility.Process) process [28042] done ExitSuccess
+[2022-05-08 02:53:00.185460462] (Utility.Process) process [28041] done ExitSuccess
+[2022-05-08 02:53:00.185552806] (Utility.Process) process [28040] done ExitSuccess
+copy: 4 failed
+```
+
+I observe that `git-annex` issues a HEAD request to find out of the file already exists (presumably, checking if it needs to be uploaded), hits the authwall, asks for and reissues the HEAD request with credentials, which _successfully_ gets a 404 -- I know by watching the server logs -- but then it says "(not found) failed". Then it reissues the same two requests for the hashdirmixed ([[internals/hashing]]) variant of the URLs.
+
+Why is it issuing a HEAD at all if it's not going to try to later send a PUT or a POST?
+
+I'm posting this in `forum` because I can't tell if this is a `bug` or a `wishlist` item. Is git-annex supposed to be able to upload over HTTP or not? It can upload to S3, why not to regular HTTP remotes? Would you be interested in exploring this feature if it doesn't yet exist?
+
+<details><summary>version</summary>
+
+```
+[kousu@nigiri ~]$ git annex version
+git-annex version: 10.20220504-g4e4c44ed8
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.11 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+```
+
+</details>
+
+
+My motivation for HTTP uploads is that I want my users to be able to do everything using only one credential; special remotes imply adding an extra credential, and ssh remotes mean managing ssh keys. I know maybe it's less safe, but getting people to adopt this technology is already difficult due to the number of nearly identical but incompatible apps, and asking them to manage extra credentials is often the final breaking point. If I can say "just make up one password" it'll go down easier. Hopefully you can give me a clear answer about if this is/isn't/will/won't be a thing, and then I will know where to focus my efforts next :)
+
+Thanks!
diff --git a/doc/forum/HTTP_uploads/comment_1_e22213816c53e6e3555532c452eceb49._comment b/doc/forum/HTTP_uploads/comment_1_e22213816c53e6e3555532c452eceb49._comment
new file mode 100644
index 0000000000..223a3cc30b
--- /dev/null
+++ b/doc/forum/HTTP_uploads/comment_1_e22213816c53e6e3555532c452eceb49._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-21T17:17:48Z"
+ content="""
+To upload over HTTP, there needs to be some HTTP endpoint accepting the
+upload. There is no "one true way" to upload a file to a HTTP server. There
+are several HTTP-based protocols that can be used for uploads 
+that git-annex supports, including common standards like
+[[special_remotes/webdav]] and
+[[special_remotes/S3]], and less common standards like
+[[special_remotes/git-lfs]].
+
+git-lfs is notable in that it can be used with a regular git remote, that
+happens to implement the git-lfs endpoint. No special remote needed. 
+You can use git-annex to upload to a git-lfs remote. One way to serve
+such a remote would be using gitlab.
+
+I don't want to add some additional git-annex specific HTTP-based protocol. I
+could see possibly adding support for uploading to git remotes using webdav,
+much the same as uploading to git-lfs remotes is handled now. But it does not
+seem common to have a webdav server that accepts uploads to the url of your git
+repository. Not like it's very common for git-lfs to be supported in a git
+repo, when using github or gitlab. It might be more common for a git repo to be
+hosted on S3, so maybe uploads to http remotes via S3 would make sense. But
+that still seems like a niche configuration.
+
+The reason you see HEADs is that before sending content to a remote,
+git-annex checks if the remote already contains it. It knows how to do that
+check for a HTTP remote, which it needs to be able to do for other reasons.
+So it gets that far before failing. (Doing the check also means that if the
+content had been copied to the HTTP remote in the meantime, 
+`git-annex copy --to` would actually succeed. So it's not entirely useless.)
+
+Note that, with the current version of git-annex, you get a different, and
+much better error message:
+
+	copy foo (to origin...)
+	  copying to non-ssh repo not supported
+	failed
+"""]]
diff --git a/doc/forum/HTTP_uploads/comment_2_d99641f1908073724f45dc3b170f3794._comment b/doc/forum/HTTP_uploads/comment_2_d99641f1908073724f45dc3b170f3794._comment
new file mode 100644
index 0000000000..f5eea1c57e
--- /dev/null
+++ b/doc/forum/HTTP_uploads/comment_2_d99641f1908073724f45dc3b170f3794._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="comment 2"
+ date="2022-09-23T01:40:56Z"
+ content="""
+Thank you for the detailed response. That really clarifies things for me.
+
+I like the new error message! Much clearer.
+"""]]
diff --git a/doc/forum/Handling_a_large_number_of_files.mdwn b/doc/forum/Handling_a_large_number_of_files.mdwn
new file mode 100644
index 0000000000..ccf8360a55
--- /dev/null
+++ b/doc/forum/Handling_a_large_number_of_files.mdwn
@@ -0,0 +1,3 @@
+I have noticed performance getting really slow when adding files (git annex add . ) to a directory already containing several hundred thousand files. When using git annex, is it more recommended to split large numbers of files into multiple directories containing fewer files? Is there a particular recommended way of handling large numbers of files (say getting into the millions) in git annex? 
+
+Thanks
diff --git a/doc/forum/Handling_a_large_number_of_files/comment_1_33d2e19fbfdf5a0bfb7b4fbc840824a2._comment b/doc/forum/Handling_a_large_number_of_files/comment_1_33d2e19fbfdf5a0bfb7b4fbc840824a2._comment
new file mode 100644
index 0000000000..055f69f26f
--- /dev/null
+++ b/doc/forum/Handling_a_large_number_of_files/comment_1_33d2e19fbfdf5a0bfb7b4fbc840824a2._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2015-06-17T07:51:53Z"
+ content="""
+I've posted a few tips on this site about dealing with large (file count) repositories.. I should probably collate them into a single post in tips (and I shall go so!).
+
+In terms of directories containing hundreds of thousands of files, my research indicates that the slowness stems from how the filesystem (at least, for ext3) fetches the listing, as it requires multiple \"trips\" to query it (it only returns 32KB of metadata at a time or something like that).
+
+So you can really speed it up by partitioning your files in such a way that a directory listing returns quickly. Personally, I use fpart and 5000 files per directory, but I think you can go up to about 20000.
+
+If you do 'find', and it takes a really long time to *start* printing paths, you have too many files :)
+"""]]
diff --git a/doc/forum/Handling_a_large_number_of_files/comment_2_a46bde96e3be5a105eb1c87bf637f8b6._comment b/doc/forum/Handling_a_large_number_of_files/comment_2_a46bde96e3be5a105eb1c87bf637f8b6._comment
new file mode 100644
index 0000000000..73d7668525
--- /dev/null
+++ b/doc/forum/Handling_a_large_number_of_files/comment_2_a46bde96e3be5a105eb1c87bf637f8b6._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2015-06-17T08:30:55Z"
+ content="""
+Here we go, I started a [tips page](/tips/Repositories_with_large_number_of_files) for this sort of usage :)
+"""]]
diff --git a/doc/forum/Handling_a_large_number_of_files/comment_3_c6564d8cfc217c5b70b2a7a8fe60039b._comment b/doc/forum/Handling_a_large_number_of_files/comment_3_c6564d8cfc217c5b70b2a7a8fe60039b._comment
new file mode 100644
index 0000000000..e3fe246363
--- /dev/null
+++ b/doc/forum/Handling_a_large_number_of_files/comment_3_c6564d8cfc217c5b70b2a7a8fe60039b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="possible large directory scaling..."
+ date="2015-06-17T12:36:36Z"
+ content="""
+awesome tips page, thanks!
+
+i was wondering ... i seem to recall newer changes to ext4 that made it more scalable with large directories, the `dir_index` flag i think. did you try that and, if so, what was the effect? --[[anarcat]]
+"""]]
diff --git a/doc/forum/Handling_a_large_number_of_files/comment_4_f9e25d63417d0354de158c47235cb3be._comment b/doc/forum/Handling_a_large_number_of_files/comment_4_f9e25d63417d0354de158c47235cb3be._comment
new file mode 100644
index 0000000000..5995243685
--- /dev/null
+++ b/doc/forum/Handling_a_large_number_of_files/comment_4_f9e25d63417d0354de158c47235cb3be._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 4"
+ date="2015-06-18T14:03:08Z"
+ content="""
+From what I have gleaned about dir_index, it speeds up finding particular files in a directory, but slows down enumeration of directory contents. It could very well end up as 6 of one, half a dozen of another as git-annex does a bit of both.
+
+So yeah, I've benchmarked this a little (just with a loopback ext3 partitions, dropping caches each time, so *caveat emptor*) and my findings match the above.
+
+Without dir_index, enumerating 102400 files takes 56% more time than 125 files (0.69 seconds vs 1.08 seconds), but with dir_index, it takes 715% more time (0.6 vs. 4.86). However, the initial creation of the files was much faster with dir_index than without (though I wasn't timing that bit).
+
+The results I've gotten so far show that (with dir_index):
+min time: Increases after 64000 files
+max time: Increases after 128000 files
+mean time: Increases after 16000 files
+
+Pretty easy to see where the 20000 files number may have come from.
+
+I'll post the numbers after I have run this longer one (100 iterations) in case anyone is interested. My conclusion is that dir_index being enabled and 16000 files per directory is optimal.
+"""]]
diff --git a/doc/forum/Handling_merge_conflicts_in_direct_mode.mdwn b/doc/forum/Handling_merge_conflicts_in_direct_mode.mdwn
new file mode 100644
index 0000000000..247c30edd1
--- /dev/null
+++ b/doc/forum/Handling_merge_conflicts_in_direct_mode.mdwn
@@ -0,0 +1,27 @@
+I'm having some problems with a direct mode Git Annex repository, created through the Assistant.
+
+I've got two diverged copies of the repository, and I want to reconcile the differences. I ran git annex sync, and it generated a load of files describing the conflicts. I don't want this as I just want to merge preferring the state from one particular repository.
+
+I know this is possible to do in Git, and while having a direct mode repository makes this trickier, this is what I've attempted. I ran:
+
+```
+git annex proxy -- git merge remotes/remote1/master -X ours
+```
+
+This worked for some files, automatically resolving the merge conflict. However, some files were modified in one repository, and deleted in the other.
+
+Unfortunately, `git annex proxy` now refuses to work due to this:
+
+```
+git-annex: Failed to set up proxy work tree.
+CallStack (from HasCallStack):
+  error, called at ./Command/Proxy.hs:60:33 in main:Command.Proxy
+```
+
+So, I can't run the git commands I need to.
+
+Reading the direct mode page, it does state that any git command will work if you pass `-c core.bare=false`. I've tried this with the status, merge and add commands, but all of them refuse to work (saying: `fatal: this operation must be run in a work tree).
+
+My immediate problem is trying to recover the repository I've seemingly broken. I can't work out how to either abort the merge, or resolve the conflicts. Any ideas?
+
+More generally, it would be interesting to know what I did wrong to get in to this mess. All I wanted to do was a merge without having to go round and sort all the variant files that would have been generated by a simple sync.
diff --git a/doc/forum/Handling_merge_conflicts_in_direct_mode/comment_1_7046393b0c4329466a0d6803b718f786._comment b/doc/forum/Handling_merge_conflicts_in_direct_mode/comment_1_7046393b0c4329466a0d6803b718f786._comment
new file mode 100644
index 0000000000..b74be782b8
--- /dev/null
+++ b/doc/forum/Handling_merge_conflicts_in_direct_mode/comment_1_7046393b0c4329466a0d6803b718f786._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-07-19T17:10:41Z"
+ content="""
+I'd encourage you to stop using direct mode, which is well on its way to
+being deprecated and has never been flexible enough to do this kind of
+thing easily.
+
+If you `git annex upgrade` that repository, you will get a v7 repository
+with an adjusted unlocked branch checked out, which is equivilant to a
+direct mode repository, but lets you use arbitrary git commands for merging
+etc.
+"""]]
diff --git a/doc/forum/Handling_permissions_in_a_shared_folder.mdwn b/doc/forum/Handling_permissions_in_a_shared_folder.mdwn
new file mode 100644
index 0000000000..7c26a63b7a
--- /dev/null
+++ b/doc/forum/Handling_permissions_in_a_shared_folder.mdwn
@@ -0,0 +1,17 @@
+Hi everyone,
+
+Just wanted to ask how to handle the following situation:
+
+- shared computer, everyone has an unprivileged, non-sudoer account and logs in via ssh for example or JupyterHub (unprivileged terminal, no `sudo` possible from there).
+- shared directory (everyone in same group, all files owned by group, sticky bit, file owner varies)
+- git-annex repository on this shared directory
+
+Problem: git-annex operations fail depending on who the owner of the files is. As git-annex needs to `chmod` files (which is only possible as owner of the file), this is a problem. 
+
+A partial solution I've employed right now is to sudo-allow one specific command that recursively sets themselves as owner for the shared directory (including the git-annex repo). This however only works when `sudo` is working, which is not the case from JupyterHub...
+
+Any other ideas? (Except ditching the shared folder...)
+
+Cheers,
+
+Yann
diff --git a/doc/forum/Handling_permissions_in_a_shared_folder/comment_1_220b33912339f06fbc9f6c9fbe1a4756._comment b/doc/forum/Handling_permissions_in_a_shared_folder/comment_1_220b33912339f06fbc9f6c9fbe1a4756._comment
new file mode 100644
index 0000000000..36632ca0b6
--- /dev/null
+++ b/doc/forum/Handling_permissions_in_a_shared_folder/comment_1_220b33912339f06fbc9f6c9fbe1a4756._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Shared git repos"
+ date="2022-12-15T13:36:59Z"
+ content="""
+Git has an option to initialize repos in a shared mode (`git init --shared=group`); then it sets all relevant files not only to group writable, but also sets sticky bits so that the group is preserved.
+
+This does also work with git-annex. (It doesn't work so well when users rsync-copy data to that shared repository, but a) that may have been fixed since I stopped letting multiple users do it, and b) it probably doesn't apply to your use case).
+"""]]
diff --git a/doc/forum/Handling_permissions_in_a_shared_folder/comment_2_f0d010731ad51bf8512e5ff93864fb53._comment b/doc/forum/Handling_permissions_in_a_shared_folder/comment_2_f0d010731ad51bf8512e5ff93864fb53._comment
new file mode 100644
index 0000000000..573a3a6d5f
--- /dev/null
+++ b/doc/forum/Handling_permissions_in_a_shared_folder/comment_2_f0d010731ad51bf8512e5ff93864fb53._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2022-12-21T09:32:58Z"
+ content="""
+Thanks, I'll try that. Though I wonder how this would solve the \"only file owners can chmod files to remove write permissions\" problem, which git-annex does to protect the files.
+"""]]
diff --git a/doc/forum/Handling_permissions_in_a_shared_folder/comment_3_9ceff336ab112ada10db1f22436dee43._comment b/doc/forum/Handling_permissions_in_a_shared_folder/comment_3_9ceff336ab112ada10db1f22436dee43._comment
new file mode 100644
index 0000000000..e8c47e470a
--- /dev/null
+++ b/doc/forum/Handling_permissions_in_a_shared_folder/comment_3_9ceff336ab112ada10db1f22436dee43._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 3"
+ date="2022-12-21T19:26:02Z"
+ content="""
+`git init --shared` seems to work so far, thanks! Still wondering why though. git annex also seems to not remove the write bit anymore, or at least only for 'everyone', so `o-w` or something. 🤷
+"""]]
diff --git a/doc/forum/Handling_permissions_in_a_shared_folder/comment_4_9ce6d042fc1826d814f8362ae2716251._comment b/doc/forum/Handling_permissions_in_a_shared_folder/comment_4_9ce6d042fc1826d814f8362ae2716251._comment
new file mode 100644
index 0000000000..c32d5bf9ac
--- /dev/null
+++ b/doc/forum/Handling_permissions_in_a_shared_folder/comment_4_9ce6d042fc1826d814f8362ae2716251._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-12-26T17:17:08Z"
+ content="""
+git-annex repository version 10 improves that, it is able to remove the
+write bit in a shared repository. `git-annex upgrade` can upgrade your
+repo, if you have git-annex version 10.
+"""]]
diff --git a/doc/forum/Handling_web_special_remote_when_content_changes__63__.mdwn b/doc/forum/Handling_web_special_remote_when_content_changes__63__.mdwn
new file mode 100644
index 0000000000..5b7be71575
--- /dev/null
+++ b/doc/forum/Handling_web_special_remote_when_content_changes__63__.mdwn
@@ -0,0 +1,19 @@
+I am in the process of organising all of my documents (pdf/ps/etc.) and putting them into an annex.  It seems like the easiest (and smartest?) way for me to manage my 15,000+ document library...  (Yeah, I've not read them all!)
+
+However, one of the issues I have run into is when I want to include something like a software manual...
+
+I'm not even sure if git-annex is the correct way to handle these sort of document, but...
+
+What would you do if the URL stays the same, but the file content changes over time?
+
+For example, the administration manual for R gets updated and re-released for each release of R, but the URL stays the same.
+
+    http://cran.r-project.org/doc/manuals/R-admin.pdf
+
+I'm not particularly worried about whether my annex version is the most recent, just that if I want to 'annex get' it, it will pull *a* version from somewhere.
+
+Any thoughts?
+
+I'd bet that the SHA-hash would change between releases(!) so would a WORM backend be the best approach?  It would mess up my one-file-in-multiple-directories (i.e. multiple simlinks to the one SHA-...-.....) approach.
+
+ 
diff --git a/doc/forum/Handling_web_special_remote_when_content_changes__63__/comment_1_05ee6a1b1943ef3c90634e52233bde1c._comment b/doc/forum/Handling_web_special_remote_when_content_changes__63__/comment_1_05ee6a1b1943ef3c90634e52233bde1c._comment
new file mode 100644
index 0000000000..0f0bf2f327
--- /dev/null
+++ b/doc/forum/Handling_web_special_remote_when_content_changes__63__/comment_1_05ee6a1b1943ef3c90634e52233bde1c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-01-03T00:57:55Z"
+ content="""
+The web special remote will happily download files when you `git annex get` even if they don't have the same content that they did before.
+
+`git annex fsck` will detect such mismatched content to the best ability of the backend (so checking the SHA1, or verifying the file size at least matches if you use WORM), and complain and move such mismatched content aside. `git annex addurl --fast` deserves a special mention; it uses a backend that only records the URL, and so if it's used, fsck cannot later detect such changes. Which might be what you want..
+
+For most users, this is one of the reasons `git annex untrust web` is a recommended configuration. Once you untrust the web, any content you download from the web will be kept around in one of your own git-annex repositories, rather than the untrustworthy web being the old copy.
+"""]]
diff --git a/doc/forum/Handling_web_special_remote_when_content_changes__63__/comment_2_48d82e391812d8ec0d4e6562d0607fe7._comment b/doc/forum/Handling_web_special_remote_when_content_changes__63__/comment_2_48d82e391812d8ec0d4e6562d0607fe7._comment
new file mode 100644
index 0000000000..93c43137d3
--- /dev/null
+++ b/doc/forum/Handling_web_special_remote_when_content_changes__63__/comment_2_48d82e391812d8ec0d4e6562d0607fe7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://a-or-b.myopenid.com/"
+ ip="203.45.2.230"
+ subject="comment 2"
+ date="2012-01-03T02:49:18Z"
+ content="""
+Thanks!  `git annex addurl --fast` does exactly what I want it to do.
+
+Wow.  Yet another special backend for me to play with.  :-)
+"""]]
diff --git a/doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode.mdwn b/doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode.mdwn
new file mode 100644
index 0000000000..6eb04ceb23
--- /dev/null
+++ b/doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode.mdwn
@@ -0,0 +1,25 @@
+Would it be possible to make `thin` work in locked mode? In other words, could locked mode use **hardlinks** instead of symlinks then `thin` is set?
+
+Such a combined mode would have all the benefits of locked mode (protection, easy-to-spot missing files) and of direct mode (no duplication of files). It would also (partially) solve the problems discussed in [[devblog/day_601__v7_default/]] and [[todo/symlinks_for_not-present_unlocked_files/]].
+
+Here is an example of how this could work from the user prospective:
+
+```
+$ mkdir foobar && cd foobar/ && git init . && git annex init foobar
+$ echo "aaaa" > a && echo "bbbb" > b
+
+$ git config annex.thin true
+$ git annex add a b
+[...] ok
+$ git annex sync
+[...] ok
+$ ls
+a  b  # note: no symlinks
+
+$ echo "foo" > a
+bash: a: Permission denied
+
+$ git annex drop --force a
+$ ls
+a@  b # note: symlink for missing file
+```
diff --git a/doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode/comment_1_ae978190d2d4fc1c4cdadc8256e6ca3d._comment b/doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode/comment_1_ae978190d2d4fc1c4cdadc8256e6ca3d._comment
new file mode 100644
index 0000000000..2ed7d1a0be
--- /dev/null
+++ b/doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode/comment_1_ae978190d2d4fc1c4cdadc8256e6ca3d._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-09-01T19:20:07Z"
+ content="""
+It would have to be represented to git the same as unlocked files are (as
+annex pointer files) because representing as symlinks would cause eg
+`git add` to do the wrong thing.
+
+So the git tree would be the same as `git annex adjust --unlock` sets up.
+The only difference then seems like it would be the mode of the files,
+which would all have their write bits removed.
+
+Unofortunately, that means no easy spotting of removed files via broken
+symlinks.
+
+And it seems all the files in the tree would need to be locked in this way,
+because there's no way to differentiate at the git level between an
+unlocked file and a file locked in this way (since git does not track write
+bits).
+
+If [[todo/symlinks_for_not-present_unlocked_files]] got implemented, it
+could work though. Ie, have a `git annex adjust` mode that represents
+present files as unlocked, but with the write bits unset, and that
+represents missing files as symlinks. Added a note to that todo about the
+idea.
+"""]]
diff --git a/doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode/comment_2_6498a44801996cc5a412558c75f6157e._comment b/doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode/comment_2_6498a44801996cc5a412558c75f6157e._comment
new file mode 100644
index 0000000000..a6abcf91de
--- /dev/null
+++ b/doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode/comment_2_6498a44801996cc5a412558c75f6157e._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-11-11T11:36:37Z"
+ content="""
+> Such a combined mode would have all the benefits of locked mode
+> (protection, easy-to-spot missing files) and of direct mode (no
+> duplication of files).
+
+Well, it does have the benefits of locked mode, but does it really gain
+back any benefits of direct mode?
+
+Direct mode didn't duplicate files. But locked mode with annex.thin doesn't
+duplicate files either, except for on a filesystem that doesn't support
+hard links. But this new mode relies on hard links too.
+
+Direct mode allowed modifying files in place. But locked mode does too,
+more safely than direct mode (except when using annex.thin, then it's the
+same).
+
+Direct mode represented missing content as dangling symlinks (on
+filesystems that support them). And this seems to be the only benefit
+of direct mode that this new mode would gain back.
+
+If the benefit of this new mode is only that, all that's really
+needed is for the missing files to be represented as symlinks. Earlier I
+said:
+
+> it could work though. Ie, have a git annex adjust mode that represents
+> present files as unlocked, but with the write bits unset, and that
+> represents missing files as symlinks.
+
+I now see that unsetting the write bit is not necessary to get the only
+benefit of this new mode. Instead, the unlocked files can work just like
+usual, being a copy of the content. And if the user doesn't want to store
+two copies, they can enable annex.thin to get hardlinks, allowing in-place
+modification.
+
+If it actually made sense to unset the write bit of unlocked
+files, it could be a config independant from this new mode. But I don't
+currently see any real benefit to doing that. As far as I can see,
+this new mode + unset write bit does not have any advantages at all
+compared with regular locked files.
+"""]]
diff --git a/doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode/comment_3_4bd03153c8ad61596ba55b719ad287ee._comment b/doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode/comment_3_4bd03153c8ad61596ba55b719ad287ee._comment
new file mode 100644
index 0000000000..70b1a425ab
--- /dev/null
+++ b/doc/forum/Hardlinks_instead_of_symlinks_in_locked+thin_mode/comment_3_4bd03153c8ad61596ba55b719ad287ee._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-11-13T19:51:04Z"
+ content="""
+I've implemented `git annex adjust --unlock-present` that unlocks files
+whose content is present, while keeping the non-present files locked,
+so dangling symlinks.
+
+It doesn't mess with the file permissions, but otherwise that's what was
+requested here.
+"""]]
diff --git a/doc/forum/Hashes_instead_of_content_in_files.mdwn b/doc/forum/Hashes_instead_of_content_in_files.mdwn
new file mode 100644
index 0000000000..86614cf40e
--- /dev/null
+++ b/doc/forum/Hashes_instead_of_content_in_files.mdwn
@@ -0,0 +1 @@
+I just cloned from a bare repo. The files I got aren't symlinks, but when I look inside them, they're just text SHA numbers, not the real content of the files. How can I get the real content?
diff --git a/doc/forum/Hashes_instead_of_content_in_files/comment_1_800d875c0d980614792207641cedb3ea._comment b/doc/forum/Hashes_instead_of_content_in_files/comment_1_800d875c0d980614792207641cedb3ea._comment
new file mode 100644
index 0000000000..23ce342860
--- /dev/null
+++ b/doc/forum/Hashes_instead_of_content_in_files/comment_1_800d875c0d980614792207641cedb3ea._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-15T04:53:16Z"
+ content="""
+Have you tried `git annex get`?
+
+The most common way this can happen is if using Windows or a FAT
+filesystem, or something else that does not support symbolic links.
+It also happens when using v6 repository mode with unlocked files.
+"""]]
diff --git a/doc/forum/Hashes_instead_of_content_in_files/comment_2_a111296eecf7d69ff30f6a82e9f1e6d4._comment b/doc/forum/Hashes_instead_of_content_in_files/comment_2_a111296eecf7d69ff30f6a82e9f1e6d4._comment
new file mode 100644
index 0000000000..d9f4d5d0dc
--- /dev/null
+++ b/doc/forum/Hashes_instead_of_content_in_files/comment_2_a111296eecf7d69ff30f6a82e9f1e6d4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Adam000"
+ subject="comment 2"
+ date="2016-09-15T15:57:59Z"
+ content="""
+Linux boxes. The repository is v6 and has files unlocked. I like to have my files unlocked so I can edit them. Is there a way to keep them unlocked, but transfer the real file content? Or, edit, then, as a batch operation, lock, sync, unlock?
+"""]]
diff --git a/doc/forum/Hashes_instead_of_content_in_files/comment_3_574964b83563df3afea9049754b1cfa2._comment b/doc/forum/Hashes_instead_of_content_in_files/comment_3_574964b83563df3afea9049754b1cfa2._comment
new file mode 100644
index 0000000000..9f2b988f19
--- /dev/null
+++ b/doc/forum/Hashes_instead_of_content_in_files/comment_3_574964b83563df3afea9049754b1cfa2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Adam000"
+ subject="comment 3"
+ date="2016-09-15T16:03:42Z"
+ content="""
+Locking the files in the first repo did the trick. Ideally a solution is available permitting transfer of unlocked files.
+"""]]
diff --git a/doc/forum/Hashes_instead_of_content_in_files/comment_4_67733580e8f8806b5036406e6712b6a1._comment b/doc/forum/Hashes_instead_of_content_in_files/comment_4_67733580e8f8806b5036406e6712b6a1._comment
new file mode 100644
index 0000000000..72b0cab7f4
--- /dev/null
+++ b/doc/forum/Hashes_instead_of_content_in_files/comment_4_67733580e8f8806b5036406e6712b6a1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-09-21T16:51:02Z"
+ content="""
+Like I said, use `git annex get`. This will populate the unlocked files
+with the content instead of the hashes.
+"""]]
diff --git a/doc/forum/Help_Windows_walkthrough.mdwn b/doc/forum/Help_Windows_walkthrough.mdwn
new file mode 100644
index 0000000000..dbe61b556b
--- /dev/null
+++ b/doc/forum/Help_Windows_walkthrough.mdwn
@@ -0,0 +1,177 @@
+Hello,
+
+i am trying to run the walkthrough on Windows 7. When i try to get the contents of a file, i only get a some git annex text string and not the real file. Both repositories are on the same ntfs filesystem. 
+
+C:\tmp>git annex version  
+git-annex version: 4.20130827-g4f18612  
+build flags: Pairing Testsuite S3 WebDAV DNS  
+local repository version: 4  
+default repository version: 3  
+supported repository versions: 3 4  
+upgrade supported from repository versions: 2  
+  
+C:\tmp\server>git --version  
+git version 1.8.3.msysgit.0  
+   
+
+# walkthrough.bat
+    
+    doskey /history > commands.log
+    mkdir laptop
+    cd laptop
+    git init
+    git annex init laptop
+    cd ..
+    
+    git clone laptop server
+    cd server
+    git annex init server
+    git remote add laptop c:\tmp\laptop
+    
+    cd ..\laptop
+    git remote add server c:\tmp\server
+    copy ..\1.pdf .
+    git annex add 1.pdf
+    git commit -m add
+    dir 
+    
+    cd ..\server
+    dir
+    git fetch laptop
+    git merge laptop/master
+    git annex get 1.pdf
+    dir
+    type 1.pdf
+    
+
+# walkthrough.log
+
+    C:\tmp>walkthrough.bat
+    
+    C:\tmp>doskey /history  1>commands.log
+    
+    C:\tmp>mkdir laptop
+    
+    C:\tmp>cd laptop
+    
+    C:\tmp\laptop>git init
+    Initialized empty Git repository in C:/tmp/laptop/.git/
+    
+    C:\tmp\laptop>git annex init laptop
+    init laptop
+      Detected a crippled filesystem.
+    
+      Enabling direct mode.
+    
+      Detected a filesystem without fifo support.
+    
+      Disabling ssh connection caching.
+    ok
+    (Recording state in git...)
+    
+    C:\tmp\laptop>cd ..
+    
+    C:\tmp>git clone laptop server
+    Cloning into 'server'...
+    done.
+    warning: remote HEAD refers to nonexistent ref, unable to checkout.
+    
+    
+    C:\tmp>cd server
+    
+    C:\tmp\server>git annex init server
+    init server
+      Detected a crippled filesystem.
+    
+      Enabling direct mode.
+    
+      Detected a filesystem without fifo support.
+    
+      Disabling ssh connection caching.
+    ok
+    (Recording state in git...)
+    
+    C:\tmp\server>git remote add laptop c:\tmp\laptop
+    
+    C:\tmp\server>cd ..\laptop
+    
+    C:\tmp\laptop>git remote add server c:\tmp\server
+    
+    C:\tmp\laptop>copy ..\1.pdf .
+            1 file(s) copied.
+    
+    C:\tmp\laptop>git annex add 1.pdf
+    add 1.pdf (checksum...) ok
+    (Recording state in git...)
+    
+    C:\tmp\laptop>git commit -m add
+    [master (root-commit) 7ad1514] add
+     1 file changed, 1 insertion(+)
+     create mode 120000 1.pdf
+    
+    C:\tmp\laptop>dir
+     Volume in drive C has no label.
+     Volume Serial Number is x
+    
+     Directory of C:\tmp\laptop
+    
+    09/01/2013  11:03 AM    <DIR>          .
+    09/01/2013  11:03 AM    <DIR>          ..
+    08/30/2013  12:43 PM            37,500 1.pdf
+                   1 File(s)         37,500 bytes
+                   2 Dir(s)   7,698,817,024 bytes free
+    
+    C:\tmp\laptop>cd ..\server
+    
+    C:\tmp\server>dir
+     Volume in drive C has no label.
+     Volume Serial Number is x
+    
+     Directory of C:\tmp\server
+    
+    09/01/2013  11:03 AM    <DIR>          .
+    09/01/2013  11:03 AM    <DIR>          ..
+                   0 File(s)              0 bytes
+                   2 Dir(s)   7,698,817,024 bytes free
+    
+    C:\tmp\server>git fetch laptop
+    remote: Counting objects: 9, done.
+    remote: Compressing objects: 100% (6/6), done.
+    remote: Total 8 (delta 1), reused 0 (delta 0)
+    Unpacking objects: 100% (8/8), done.
+    From c:\tmp\laptop
+     * [new branch]      git-annex  -> laptop/git-annex
+     * [new branch]      master     -> laptop/master
+    
+    C:\tmp\server>git merge laptop/master
+    
+    C:\tmp\server>git annex get 1.pdf
+    get 1.pdf (merging laptop/git-annex origin/git-annex into git-annex...)
+    (Recording state in git...)
+    (from laptop...)
+    1.pdf
+           37500 100%    4.51MB/s    0:00:00 (xfer#1, to-check=0/1)
+    
+    sent 37573 bytes  received 31 bytes  75208.00 bytes/sec
+    total size is 37500  speedup is 1.00
+    ok
+    (Recording state in git...)
+    
+    C:\tmp\server>dir
+     Volume in drive C has no label.
+     Volume Serial Number is x
+    
+     Directory of C:\tmp\server
+    
+    09/01/2013  11:03 AM    <DIR>          .
+    09/01/2013  11:03 AM    <DIR>          ..
+    09/01/2013  11:03 AM               194 1.pdf
+                   1 File(s)            194 bytes
+                   2 Dir(s)   7,698,767,872 bytes free
+    
+    C:\tmp\server>type 1.pdf
+    .git/annex/objects/kM/0q/SHA256E-s37500--32d8190c7e189d45f48245a100e4cc981ea1bbc
+    02ac8bfa6188db73e41ce06f3.pdf/SHA256E-s37500--32d8190c7e189d45f48245a100e4cc981e
+    a1bbc02ac8bfa6188db73e41ce06f3.pdfC:\tmp\server>
+    C:\tmp\server>
+    
diff --git a/doc/forum/Help_Windows_walkthrough/comment_1_5fc22393a1b28235eabb2871ad83d0a7._comment b/doc/forum/Help_Windows_walkthrough/comment_1_5fc22393a1b28235eabb2871ad83d0a7._comment
new file mode 100644
index 0000000000..95623a6454
--- /dev/null
+++ b/doc/forum/Help_Windows_walkthrough/comment_1_5fc22393a1b28235eabb2871ad83d0a7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.7"
+ subject="comment 1"
+ date="2013-09-03T17:59:03Z"
+ content="""
+The walkthrough assumes a system that uses indirect mode by default, so it won't work quite right on Windows, which is forced to use direct mode.
+
+Running `git annex fsck` in the server repository will fix up this situation, but the right thing on Windows is to use `git annex sync` rather than the manual `git fetch + git merge` the walkthrough shows.
+
+Guess I'll make the walkthrough use sync, although it may make it harder for people to understand what's going on internally.
+"""]]
diff --git a/doc/forum/Help_fixing_S3_mistake.mdwn b/doc/forum/Help_fixing_S3_mistake.mdwn
new file mode 100644
index 0000000000..42c6934c93
--- /dev/null
+++ b/doc/forum/Help_fixing_S3_mistake.mdwn
@@ -0,0 +1,7 @@
+Hello, I'd like some help fixing a mistake I made setting up an S3 remote.
+
+I created an S3 remote A, then at some later time accidentally created an S3 remote B with the same settings as A, and moved some files over to B.
+
+I have fixed it by removing/marking as dead B, but I am missing some files now.
+
+I believe that all of these files exist in A since it is the same bucket as B, but git annex doesn't know that they are in A.  Is there a way to somehow "reinject" or refresh git annex so it knows that the files are there?  I'm using chunking as well, so I don't know how to download all the chunks and use git annex's reinject command.
diff --git a/doc/forum/Help_fixing_S3_mistake/comment_1_dc60d08da4c0b90705b0b88b4c834f05._comment b/doc/forum/Help_fixing_S3_mistake/comment_1_dc60d08da4c0b90705b0b88b4c834f05._comment
new file mode 100644
index 0000000000..54150eed99
--- /dev/null
+++ b/doc/forum/Help_fixing_S3_mistake/comment_1_dc60d08da4c0b90705b0b88b4c834f05._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="darkfeline"
+ subject="comment 1"
+ date="2015-10-13T05:24:25Z"
+ content="""
+A and B have different UUIDs, and they point to the same S3 bucket (I realize I may have done something bad here).
+
+I still have the UUID for B (but not attached to a remote); is it possible to merge git annex's knowledge of B into A, or otherwise re-initialize B?
+"""]]
diff --git a/doc/forum/Help_fixing_S3_mistake/comment_2_f105714b9bac7f45fdcb9a47e77255ac._comment b/doc/forum/Help_fixing_S3_mistake/comment_2_f105714b9bac7f45fdcb9a47e77255ac._comment
new file mode 100644
index 0000000000..8ae5e7ce0d
--- /dev/null
+++ b/doc/forum/Help_fixing_S3_mistake/comment_2_f105714b9bac7f45fdcb9a47e77255ac._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-10-15T18:30:27Z"
+ content="""
+Depends.. If one or both special remotes used encryption then no,
+one can't see the encrypted files that were put in the other one.
+
+If neither used encryption, and they're otherwise configured the same,
+then you can just use `git annex fsck --from A`. This will check files
+to see if their content is located on remote A, and if so, and git-annex
+had thought the file was only located on remote B, it will update the location
+tracking log to reflect the reality that the file is present on A.
+
+If either remote used encryption, then A can't see files that were added
+to B. So instead, you need this approach , which involves data transfer:
+
+	git annex enableremote B
+	git annex copy --from B
+	git annex copy --to A
+	git annex drop --from B
+	git annex dead B # if it wasn't already dead
+	git remote remove B
+"""]]
diff --git a/doc/forum/Help_fixing_S3_mistake/comment_3_a00bca3b6b0d7b6c20ca1ca749c93469._comment b/doc/forum/Help_fixing_S3_mistake/comment_3_a00bca3b6b0d7b6c20ca1ca749c93469._comment
new file mode 100644
index 0000000000..acf1d0bb5e
--- /dev/null
+++ b/doc/forum/Help_fixing_S3_mistake/comment_3_a00bca3b6b0d7b6c20ca1ca749c93469._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="darkfeline"
+ subject="comment 3"
+ date="2015-10-18T20:15:56Z"
+ content="""
+Thanks for the help.  I'm currently stuck partway through fixing this.
+
+1. I changed the UUID of the remote \"amazon\" in .git/config to the UUID of B.
+2. I changed contents of the annex-uuid file in the S3 bucket from the UUID of A to the UUID of B (making sure to not include a newline).
+
+After this, I think I can follow your steps to fix the problem.  However, Git annex is now reporting the error whenever I try to run a command:
+
+    trusted repositories: git-annex: S3 bucket not configured
+
+My understanding of this message is that Git annex is not seeing the UUID it is expecting in the S3 bucket, and that it will be fixed when some cache expires.  Is this correct?
+"""]]
diff --git a/doc/forum/Help_fixing_S3_mistake/comment_4_34333d0f3eeaf2929089535632759ba1._comment b/doc/forum/Help_fixing_S3_mistake/comment_4_34333d0f3eeaf2929089535632759ba1._comment
new file mode 100644
index 0000000000..ddb5c0fb69
--- /dev/null
+++ b/doc/forum/Help_fixing_S3_mistake/comment_4_34333d0f3eeaf2929089535632759ba1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="darkfeline"
+ subject="comment 4"
+ date="2015-10-18T23:58:08Z"
+ content="""
+Actually, I suspect that I may have done more damage than I had initially thought.
+
+Is there a way to check whether the repo still has information about a file's whereabouts, especially how it was chunked on an S3 remote?  I'm not sure if that information still exists or not.  If it doesn't exist anymore, then recovery is likely impossible.
+
+If this information still exists in the repo, I can reconstitute the files by hand (script) if necessary and reinject them.  I'm assuming that I can decrypt them using my private key?
+"""]]
diff --git a/doc/forum/Help_fixing_S3_mistake/comment_5_7060bcd3424caab3570dcc7cbd3df93e._comment b/doc/forum/Help_fixing_S3_mistake/comment_5_7060bcd3424caab3570dcc7cbd3df93e._comment
new file mode 100644
index 0000000000..5cfe3edd2b
--- /dev/null
+++ b/doc/forum/Help_fixing_S3_mistake/comment_5_7060bcd3424caab3570dcc7cbd3df93e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-10-26T17:31:54Z"
+ content="""
+Since this information about remotes is stored in your git repository, I
+don't see how the repository could lose it. I mean, you might have to look
+in the history if you've changed some value, like the chunking setting
+from what it's supposed to be, in order to find the historical value, but
+like anything checked into a git repository, it's there until you throw the
+repository away or git-filter-branch the information out of existence.
+"""]]
diff --git a/doc/forum/Help_on_my_usecase.mdwn b/doc/forum/Help_on_my_usecase.mdwn
new file mode 100644
index 0000000000..ef670aa254
--- /dev/null
+++ b/doc/forum/Help_on_my_usecase.mdwn
@@ -0,0 +1,22 @@
+I am using git-annex assistant for a few months now and still don't think I have it all setup correctly. My setup is:
+
+* Laptop Computer with low storage. Content creator, assistant: file source
+* Desktop Computer with medium storage capacity. Consumer, assistant: manual Mode
+* 2TB USB HD (EXT4) Backup, assistant: full backup
+* 2.5" portable 500GB drive NTFS formatted. transfer to backup: assistant: tried transfer and partial backup
+* Root Server on the web, not yet in the mix. Planned: Index only / content creator
+
+My primary goal is getting the stuff from the Laptop to the 2TB USB drive, syncing the annex with the desktop so I can get files on the desktop from the backup.
+What works:
+
+* Checking stuff into the annex on the Laptop
+* When the 2TB drive is connected to the Laptop, stuff is automatically moved there too
+* Bare Repo on the 2.5" configured as partial backup automatically backups the data
+
+What doesn't work:
+
+* Connecting the 2.5" bare repo to the Desktop to move stuff to the backup drive automatically
+* Having a human readable folder Structure on the 2.5" NTFS drive. I'd be ok to have a bare repo plus a special remote on the drive, but I don't know how to configure it
+* How do I drop stuff from the bare repo on the 2.5" drive? I think a partial backup should drop content that is in a full backup, but it doesn't
+
+Thanks for reading this long post. If anyone has any tips on how to configure the assistant, thats much appreciated.
diff --git a/doc/forum/Help_on_my_usecase/comment_1_a35b35c7927640f21d47c3df4f91dabb._comment b/doc/forum/Help_on_my_usecase/comment_1_a35b35c7927640f21d47c3df4f91dabb._comment
new file mode 100644
index 0000000000..25116a7c43
--- /dev/null
+++ b/doc/forum/Help_on_my_usecase/comment_1_a35b35c7927640f21d47c3df4f91dabb._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 1"
+ date="2013-11-09T18:18:49Z"
+ content="""
+An incremental backup is supposed to drop content once it reaches a full backup. But, the assistant can only do that if it's able to verify that the full backup drive (or some other repository it can access) has a file, at the same time it's dropping it from the incremental backup drive. If you don't have both the incremental and full backup drives plugged in at the same time, you could consider making git-annex [[trust]] the full backup drive, which would avoid this explicit check.
+
+It sounds like you want a non-bare git repository on the 2.5\" drive. The assistant does not currently support setting that up, but you can do it by just using `git clone` as shown in the [[walkthrough]].
+
+I'm not clear on what doesn't work when you connect the 2.5\" drive to your desktop.
+"""]]
diff --git a/doc/forum/Help_with_assistant_and_Adobe_Lightroom.mdwn b/doc/forum/Help_with_assistant_and_Adobe_Lightroom.mdwn
new file mode 100644
index 0000000000..d3cf4e7a1d
--- /dev/null
+++ b/doc/forum/Help_with_assistant_and_Adobe_Lightroom.mdwn
@@ -0,0 +1,3 @@
+I am trying to use the git-annex assistant to automatically sync photos from my Lightroom catalog on Mac OS X to a remote archive server. I hit a snag due to a race condition combined with some peculiar behavior of Adobe Lightroom: it dereferences symlinks and uses the name of the target when importing (see https://forums.adobe.com/thread/568863?tstart=0) I observe the following problematic workflow: 1. Files are imported using the original filename. 2. The assistant eventually moves the content to .git/annex/objects and creates symlinks to replace the originals. 3. The photos no longer appear in the Library, however Lightroom will not allow me to re-import as it thinks the files have already been imported and are duplicates.
+
+I know a few other folks are using git-annex and Lightroom together, but I cannot tell if they are using the assistant or manually managing the annex. This implementation is for my wife who is not technical enough to use git on the command line so that's out of the question. It seems like direct mode is my best option for now, however, I'd like to avoid it since it's being deprecated. Is there some other option that I'm missing? Is anyone else out there successfully using the assistant and Lightroom together? I'd love some advice.
diff --git a/doc/forum/Help_with_assistant_and_Adobe_Lightroom/comment_1_3adf9f5c60558b3c70a8aa041dbbe966._comment b/doc/forum/Help_with_assistant_and_Adobe_Lightroom/comment_1_3adf9f5c60558b3c70a8aa041dbbe966._comment
new file mode 100644
index 0000000000..ea5e6e927c
--- /dev/null
+++ b/doc/forum/Help_with_assistant_and_Adobe_Lightroom/comment_1_3adf9f5c60558b3c70a8aa041dbbe966._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-14T19:42:33Z"
+ content="""
+The usual fix for this kind of problem is to use direct mode for your
+git-annex repository.
+
+Direct mode is actually the default if you use the webapp to create your
+repository. Otherwise, you can stop the assistant running, and run "git
+annex direct" to convert the repository to direct mode, then start the
+assistant back up.
+"""]]
diff --git a/doc/forum/Help_with_get.mdwn b/doc/forum/Help_with_get.mdwn
new file mode 100644
index 0000000000..997a5baf35
--- /dev/null
+++ b/doc/forum/Help_with_get.mdwn
@@ -0,0 +1 @@
+I'm new to git annex, but I couldn't find any other posts describing this error.  I just set up repositories on two external 1TB, NTFS formatted hard drives and I'm working on a windows 10 os.  I followed the walkthrough, setting the repository up on one drive, then cloning it on the other, and now I'm syncing the content (I first sync then get, but the problem occurs when I use the --content flag on sync as well).  After a few files are successfully transferred, the process stalls part way through a file saying an "scp error writing 'file': Permission denied"???  Git annex and git processes don't end and I need to forcefully close the terminal and unplug and replug the drive back in before I can resume.  I don't know if it is something with using git annex on Windows(I was automatically put on an adjusted branch, which I don't fully understand), or the NTFS drives, or maybe the hard drive is failing.  Any advice people can give would be appreciated as this issue is persistent enough (every ~3 files) that it is making git annex unusable.  
diff --git a/doc/forum/Help_with_get/comment_1_439c7562d94a969fd841cc44628abedd._comment b/doc/forum/Help_with_get/comment_1_439c7562d94a969fd841cc44628abedd._comment
new file mode 100644
index 0000000000..8ac255198f
--- /dev/null
+++ b/doc/forum/Help_with_get/comment_1_439c7562d94a969fd841cc44628abedd._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-02-19T15:43:46Z"
+ content="""
+Hi,
+What version of git-annex are you using (Output of `git annex version`)? And since you are on windows, did you follow the install instructions [[here|install/Windows/]] or are you using wsl or something else? Finally, can you run the failing command with `--debug` and post the output here?
+"""]]
diff --git a/doc/forum/Help_with_get/comment_2_137f89ea9c381cdbf57da78308a46078._comment b/doc/forum/Help_with_get/comment_2_137f89ea9c381cdbf57da78308a46078._comment
new file mode 100644
index 0000000000..13bf43f4ba
--- /dev/null
+++ b/doc/forum/Help_with_get/comment_2_137f89ea9c381cdbf57da78308a46078._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jwrauch"
+ avatar="http://cdn.libravatar.org/avatar/0e83010187ef0c8c587e0c99e2ca5474"
+ subject="comment 2"
+ date="2021-02-19T16:10:00Z"
+ content="""
+I'm using git annex version: 8.20200815-g335aae266.  And I followed the instructions the link provided.  I looked into wls but decided to try this first.  Is that a better approach?
+"""]]
diff --git a/doc/forum/Help_with_get/comment_3_f523e44daca53b3d99350e0d3f7a8874._comment b/doc/forum/Help_with_get/comment_3_f523e44daca53b3d99350e0d3f7a8874._comment
new file mode 100644
index 0000000000..ea7c519843
--- /dev/null
+++ b/doc/forum/Help_with_get/comment_3_f523e44daca53b3d99350e0d3f7a8874._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="jwrauch"
+ avatar="http://cdn.libravatar.org/avatar/0e83010187ef0c8c587e0c99e2ca5474"
+ subject="comment 3"
+ date="2021-02-19T16:17:33Z"
+ content="""
+I ran the get command with the debug flag and the output is pretty extensive.  It successfully transferred two files before it failed, so I'm posting from the 'ok' of the last success.  Here is the command and output:
+
+$ git annex get . --debug
+...
+ok
+get recorder/2020-philippines/20200906_165152.mp4 (from avi...)
+[2021-02-19 11:11:22.1489056] call: cp [\"--reflink=auto\",\"--preserve=timestamps\",\"E:\\video\\.git\\annex\\objects\\d88\\080\\SHA256E-s493726419--95dd6a377dce064935ab2e8c0dda2f3c4d9d2b33e0efaca34fceda200cbee249.mp4\\SHA256E-s493726419--95dd6a377dce064935ab2e8c0dda2f3c4d9d2b33e0efaca34fceda200cbee249.mp4\",\".git\\annex\\tmp\\SHA256E-s493726419--95dd6a377dce064935ab2e8c0dda2f3c4d9d2b33e0efaca34fceda200cbee249.mp4\"]
+10%   46.12 MiB        87 MiB/s 4scp: error writing '.git\annex\tmp\SHA256E-s493726419--95dd6a377dce064935ab2e8c0dda2f3c4d9d2b33e0efaca34fceda200cbee249.mp4': Permission denied
+
+"""]]
diff --git a/doc/forum/Help_with_get/comment_4_863d03a8e52335d8a210320d8a02c553._comment b/doc/forum/Help_with_get/comment_4_863d03a8e52335d8a210320d8a02c553._comment
new file mode 100644
index 0000000000..1183ecc7c0
--- /dev/null
+++ b/doc/forum/Help_with_get/comment_4_863d03a8e52335d8a210320d8a02c553._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="jwrauch"
+ avatar="http://cdn.libravatar.org/avatar/0e83010187ef0c8c587e0c99e2ca5474"
+ subject="comment 4"
+ date="2021-02-19T16:19:52Z"
+ content="""
+Sorry, formatting:
+
+    $ git annex get . --debug
+    ok
+    get recorder/2020-philippines/20200906_165152.mp4 (from avi...)
+    [2021-02-19 11:11:22.1489056] call: cp [\"--reflink=auto\",\"--preserve=timestamps\",\"E:\\video\\.git\\annex\\objects\\d88\\080\\SHA256E-s493726419--95dd6a377dce064935ab2e8c0dda2f3c4d9d2b33e0efaca34fceda200cbee249.mp4\\SHA256E-       s493726419--95dd6a377dce064935ab2e8c0dda2f3c4d9d2b33e0efaca34fceda200cbee249.mp4\",\".git\\annex\\tmp\\SHA256E-s493726419--95dd6a377dce064935ab2e8c0dda2f3c4d9d2b33e0efaca34fceda200cbee249.mp4\"]
+    10%   46.12 MiB        87 MiB/s 4scp: error writing '.git\annex\tmp\SHA256E-s493726419--95dd6a377dce064935ab2e8c0dda2f3c4d9d2b33e0efaca34fceda200cbee249.mp4': Permission denied
+
+"""]]
diff --git a/doc/forum/Help_with_get/comment_5_92e48d21fd83c0f7e69a5bb7b4c4f4ee._comment b/doc/forum/Help_with_get/comment_5_92e48d21fd83c0f7e69a5bb7b4c4f4ee._comment
new file mode 100644
index 0000000000..9acbbbd53b
--- /dev/null
+++ b/doc/forum/Help_with_get/comment_5_92e48d21fd83c0f7e69a5bb7b4c4f4ee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jwrauch"
+ avatar="http://cdn.libravatar.org/avatar/0e83010187ef0c8c587e0c99e2ca5474"
+ subject="comment 5"
+ date="2021-02-19T18:58:14Z"
+ content="""
+Okay, so it seems like it was my usb port.  I tried plugging the drive into a different port and the whole repository copied over.  I'd love to know more if anyone has more information about what was happening, but I think the issue is resolved for now.  
+"""]]
diff --git a/doc/forum/Help_with_git-annex_and_controlmaster.mdwn b/doc/forum/Help_with_git-annex_and_controlmaster.mdwn
new file mode 100644
index 0000000000..1eebed3801
--- /dev/null
+++ b/doc/forum/Help_with_git-annex_and_controlmaster.mdwn
@@ -0,0 +1,42 @@
+All,
+
+I am quite new to `git-annex` so it's possible/probable this is a FAQ, but my search-fu has failed me.
+
+Namely, I'm testing out `git-annex` and have a sample repo on a remote server, let's call it "foo". Now I have SSH Controlmaster setup because foo has both a password and PIN that need entered so I usually do a `screen` and run `ssh -MN foo` and detach so that I can do `ssh foo` and boom, on foo no problem. And I can do `scp foo:file .` and no need to enter in either.
+
+So then I tried following the walkthroughs here. First:
+
+```
+❯ git clone git+ssh://foo:/path/to/my/annex
+Cloning into 'annex'...
+remote: Enumerating objects: 28, done.
+remote: Counting objects: 100% (28/28), done.
+remote: Compressing objects: 100% (22/22), done.
+remote: Total 28 (delta 4), reused 0 (delta 0), pack-reused 0
+Receiving objects: 100% (28/28), done.
+Resolving deltas: 100% (4/4), done.
+```
+
+Nice. Then I did:
+
+```
+❯ git annex init "my laptop"
+init my laptop (scanning for unlocked files...)
+Enter PIN:
+Password:
+ok
+(recording state in git...)
+```
+
+Worked, but had to enter PIN and password. And then I `get` and:
+
+```
+❯ git annex get file1.nc4
+get file1.nc4 (from origin...)
+Enter PIN:
+Password:
+ok
+(recording state in git...)
+```
+
+Same thing: worked, but had to do PIN/password. So, is there a way I can utilize an existing controlmaster "tunnel" and avoid the pin/password like I can with a simple `ssh foo`? 
diff --git a/doc/forum/Help_with_git-annex_and_controlmaster/comment_1_2742e65d9faebab80bc5fa0877ef7d29._comment b/doc/forum/Help_with_git-annex_and_controlmaster/comment_1_2742e65d9faebab80bc5fa0877ef7d29._comment
new file mode 100644
index 0000000000..b3707f3594
--- /dev/null
+++ b/doc/forum/Help_with_git-annex_and_controlmaster/comment_1_2742e65d9faebab80bc5fa0877ef7d29._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-05-04T13:42:34Z"
+ content="""
+Hi, I think you have to set the `annex.sshcaching` config to `false`, since git-annex starts it's own controlmaster with that option. These options are documented in the [[git-annex]] manpage.
+"""]]
diff --git a/doc/forum/Help_with_git-annex_and_controlmaster/comment_2_5e57d563d351cc8c850c9cc4726ad23b._comment b/doc/forum/Help_with_git-annex_and_controlmaster/comment_2_5e57d563d351cc8c850c9cc4726ad23b._comment
new file mode 100644
index 0000000000..98a73b47cb
--- /dev/null
+++ b/doc/forum/Help_with_git-annex_and_controlmaster/comment_2_5e57d563d351cc8c850c9cc4726ad23b._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="fortran"
+ avatar="http://cdn.libravatar.org/avatar/ee27e12e945c0af698d58f0d8dde2457"
+ subject="comment 2"
+ date="2021-05-04T19:10:35Z"
+ content="""
+Oh. Wow. That's a big man page...
+
+Okay. So if I run `git config annex.sshcaching false`, then things are happier. Well:
+
+```
+❯ git annex get file1.nc4
+get file1.nc4 (from origin...)
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+ok
+(recording state in git...)
+```
+
+Now, reading the man pages, I see that the default concurrency is 1, so I think I'm safe?  Or is there perhaps something I should use to tell it \"nope\" for that?
+"""]]
diff --git a/doc/forum/Help_with_git-annex_and_controlmaster/comment_3_4fe0973f6b7f912e2e4163ebf5dfc5d4._comment b/doc/forum/Help_with_git-annex_and_controlmaster/comment_3_4fe0973f6b7f912e2e4163ebf5dfc5d4._comment
new file mode 100644
index 0000000000..b591afd081
--- /dev/null
+++ b/doc/forum/Help_with_git-annex_and_controlmaster/comment_3_4fe0973f6b7f912e2e4163ebf5dfc5d4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="fortran"
+ avatar="http://cdn.libravatar.org/avatar/ee27e12e945c0af698d58f0d8dde2457"
+ subject="comment 3"
+ date="2021-05-04T19:25:47Z"
+ content="""
+Essentially, we are hoping to deploy git-annex so the less messages from git-annex, the better for our end users. (Or, I guess, my *supporting* the end users :) )
+"""]]
diff --git a/doc/forum/Help_with_git-annex_and_controlmaster/comment_4_51312d1662d0794e4258551c59877434._comment b/doc/forum/Help_with_git-annex_and_controlmaster/comment_4_51312d1662d0794e4258551c59877434._comment
new file mode 100644
index 0000000000..20710c2496
--- /dev/null
+++ b/doc/forum/Help_with_git-annex_and_controlmaster/comment_4_51312d1662d0794e4258551c59877434._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 4"
+ date="2021-05-04T20:31:45Z"
+ content="""
+Even with concurrency enabled, this should not be a problem in your case, as you're manually doing the controlmaster setup.
+
+@joey I guess there needs to be a way to hide such messages, like git with the `advice.*` configuration options.
+"""]]
diff --git a/doc/forum/Help_with_git-annex_and_controlmaster/comment_5_0b4e2314c23df5eda18661c245f9f057._comment b/doc/forum/Help_with_git-annex_and_controlmaster/comment_5_0b4e2314c23df5eda18661c245f9f057._comment
new file mode 100644
index 0000000000..e77202e7af
--- /dev/null
+++ b/doc/forum/Help_with_git-annex_and_controlmaster/comment_5_0b4e2314c23df5eda18661c245f9f057._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-05-27T16:26:19Z"
+ content="""
+Seems to me that annex.jobs must be set in the git config for that message
+to be displayed as shown.
+
+I agree, it would make sense to have a way to disable the message.
+Added annex.adviceNoSshCaching
+"""]]
diff --git a/doc/forum/Help_with_syncing_file_contents.mdwn b/doc/forum/Help_with_syncing_file_contents.mdwn
new file mode 100644
index 0000000000..28ac22b2e1
--- /dev/null
+++ b/doc/forum/Help_with_syncing_file_contents.mdwn
@@ -0,0 +1,68 @@
+Hi everyone,
+
+everyday I understand more and more how git and git-annex work but I need help with this one.
+I guess I have two questions but let me describe the scenario first:
+
+I have one local repository of mp3s (assume just one file: file1.mp3).
+I clone that repository into a remote git-annex repository over ssh and "git annex get" the file contents for file1.mp3.
+
+I unlock some mp3's locally and modify some mp3 tags. 
+Then I notify git-annex of these changes
+with "git annex add *"
+and commit them with "git commit -m 'mp3 tags changed'". 
+[git annex locks them again and changes the symlinks to point to the changed file in the annex, git commits the changed symlink]
+
+At this point in time there are two objects in my git annex repository:
+hash(file1.mp3) 
+hash(file1.mp3|with modified tags)
+The symlink points now to hash(file1.mp3|with modified tags)
+
+At this point the remote still does not now of this commit and of the new file contents.
+Thus I do "git push" to send the changes to the remote.
+The remote now has a BROKEN symlink because it already points to hash(file1.mp3|with modified tags)
+but the remote annex's object directory only contains hash(file1.mp3).
+
+Then I want my remote repository to also have the updated mp3 tags.
+The only way I see (without scripting) to have the updated mp3 tags in the remote repository is to do an "git annex get file1.mp3" on the remote repository or an "git annex copy --to remote file1.mp3" at my local repository. However, although the binary differences between both files
+file1.mp3 and file1.mp3|with modified tags are small the latter is transferred completely from the local repository to the remote repository.
+
+This is not a problem when just changing one file, but a problem when I have 10GB's of files and when it takes 2days to upload them to the remote because of a low bandwidth. 
+
+First question: Did I miss something? Does git-annex already provide means to only transmit the diff between the two objects? 
+
+Second question regarding disk space.
+I now have a complete history of all changes to file1.mp3 in my git-annex repository. I have the objects that represent every state of file1.mp3 and I can go back to these states when I checkout the respective commits and thereby the symlinks that link to these "old" objects. This history can take up a lot of space. What is the clean way to forget the past? AFAIK "git drop unused" only drops file contents that are not referenced in any commit? 
+
+If one wanted to preserve the entire history but save disk space one could also only store the current content and the patches that allow to reconstruct older versions from the current one. I understand that applying several patches consecutively takes more cpu time but for me going back to an older commit with my binary files only happens rarely. 
+
+This is the algorithm I have in mind for an optimized "git annex get file1":
+
+On that repository where the file is missing:
+
+1. Find the newest object that represented the contents of file1 in file1's commit history.
+
+2. Transmit this object identification hash(object) to the remote that has the current version (the one I am getting from).
+
+At that remote: 
+
+If the history contains full versions of file contents:
+
+Create a binary diff between the object identified by hash(object) and the current content of file1.
+
+If the history contains only the current version and patches to older versions:
+Collect all patches that represent the change from hash(object) to the current content of file1.
+
+If the list of patches is bigger than the current content of file 1 transmit the current content of file1. Otherwise transmit the patch(es) 
+
+On that repository where the file is missing:
+
+Apply the patch(es) to the latest object to obtain the current object.
+
+What's your opinion on this?
+
+Marek
+
+
+
+
+
diff --git a/doc/forum/Help_with_syncing_file_contents/comment_1_7ec34de3140983739080115c82966bf5._comment b/doc/forum/Help_with_syncing_file_contents/comment_1_7ec34de3140983739080115c82966bf5._comment
new file mode 100644
index 0000000000..87ef6d1306
--- /dev/null
+++ b/doc/forum/Help_with_syncing_file_contents/comment_1_7ec34de3140983739080115c82966bf5._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmp1ThsNNAbSn46ju-gwFELfStlhl8usJo"
+ nickname="donkeyicydragon"
+ subject="Possible quick solution with rsync"
+ date="2013-05-28T10:52:30Z"
+ content="""
+One could achieve the effect of only transmitting the changes of file contents using rsync.
+
+On the repository that lacks the current version:
+
+cp latestversionavailable currentversion
+rsync remoterepository/currentversion ./currentversion
+
+
+
+
+
+"""]]
diff --git a/doc/forum/Help_with_syncing_file_contents/comment_2_7dba58d3c62d6f64a270298e4e4329a4._comment b/doc/forum/Help_with_syncing_file_contents/comment_2_7dba58d3c62d6f64a270298e4e4329a4._comment
new file mode 100644
index 0000000000..2d427cccb8
--- /dev/null
+++ b/doc/forum/Help_with_syncing_file_contents/comment_2_7dba58d3c62d6f64a270298e4e4329a4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmp1ThsNNAbSn46ju-gwFELfStlhl8usJo"
+ nickname="donkeyicydragon"
+ subject="I should have read git annex unused first"
+ date="2013-05-28T22:14:46Z"
+ content="""
+Apparently \"git annex unused\" finds previous versions of the object that are not symlinked anymore. However, if a file is renamed then the oldest version before the rename is not marked as unused.
+
+
+"""]]
diff --git a/doc/forum/Help_with_syncing_file_contents/comment_3_b26cfa20dc81517d93e760f4809bdc24._comment b/doc/forum/Help_with_syncing_file_contents/comment_3_b26cfa20dc81517d93e760f4809bdc24._comment
new file mode 100644
index 0000000000..6293ada24b
--- /dev/null
+++ b/doc/forum/Help_with_syncing_file_contents/comment_3_b26cfa20dc81517d93e760f4809bdc24._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-05-29T16:50:35Z"
+ content="""
+Treating each version of a file as a separate object that is stored and transmitted separately is one of the core simplifying assumptions of git-annex. Among other things it makes it easy to have dumb special remotes that are mere key/value stores. And it keeps it easy to understand.
+
+I don't consider this a problem as far as storage goes. Disk space is cheap; git-annex allows dropping unused versions of files from repositories that are not on large cheap storage.
+
+For file transfer, it would be nice to find optimisations that don't require changing this simplifying assumption. This can be done at least for rsync I think. The [[design/assistant/deltas]] page is where the design of this is or will be worked on.
+"""]]
diff --git a/doc/forum/HowTo_Conflict_Resolution.mdwn b/doc/forum/HowTo_Conflict_Resolution.mdwn
new file mode 100644
index 0000000000..2e43efe69e
--- /dev/null
+++ b/doc/forum/HowTo_Conflict_Resolution.mdwn
@@ -0,0 +1,66 @@
+Hello,
+
+I have two git annex repos, AA and BB in direct mode. Both have edited a binary file before syncing
+
+```
+~/Desktop/BB (git)-[annex/direct/master] % git annex sync
+commit  ok
+pull origin 
+remote: Counting objects: 21, done.
+remote: Compressing objects: 100% (17/17), done.
+remote: Total 21 (delta 3), reused 0 (delta 0)
+Unpacking objects: 100% (21/21), done.
+From /home/florian/Desktop/AA
+   d55cfa2..b86e708  annex/direct/master -> origin/annex/direct/master
+   83ff4c6..5cfbd34  git-annex  -> origin/git-annex
+   d7b79e8..b86e708  master     -> origin/master
+   d7b79e8..b86e708  synced/master -> origin/synced/master
+
+Auto-merging bin2
+CONFLICT (content): Merge conflict in bin2
+Auto-merging bin1
+CONFLICT (content): Merge conflict in bin1
+Automatic merge failed; fix conflicts and then commit the result.
+bin2: needs merge
+bin1: needs merge
+(recording state in git...)
+
+  Merge conflict was automatically resolved; you may want to examine the result.
+
+ok
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+push origin 
+Counting objects: 31, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (25/25), done.
+Writing objects: 100% (31/31), 3.04 KiB | 0 bytes/s, done.
+Total 31 (delta 6), reused 0 (delta 0)
+To /home/florian/Desktop/AA
+   83ff4c6..7df9834  git-annex -> synced/git-annex
+   b86e708..59a1240  annex/direct/master -> synced/master
+ok
+```
+
+```
+florian@horus ~/Desktop/BB (git)-[annex/direct/master] % git annex get .
+get bin1.variant-c4b6 (from origin...) ok
+get bin2.variant-f16a (from origin...) ok
+(recording state in git...)
+florian@horus ~/Desktop/BB (git)-[annex/direct/master] % ll
+insgesamt 5824
+-rw-r----- 1 florian florian 2863795 24. Aug 21:32 bin1.variant-1696
+-rw-r----- 1 florian florian 2841749 24. Aug 21:30 bin1.variant-c4b6
+-rw-r----- 1 florian florian  125612 24. Aug 21:32 bin2.variant-0efa
+-rw-r----- 1 florian florian  126067 24. Aug 21:31 bin2.variant-f16a
+
+```
+How can I resolve this conflict now? Is there a way to tell which bin1 / bin2 is from AA, which from BB? Is there a way to tell git annex to completely take the data from AA or BB?
+
+This case might appear somehow artifical but I was caught in that various times when syncing my music database. Actually I didn't care which version of the database it took, but I was unable to produce a coherent data set, so that the database files only come from one sync partner.
+
+I did the git annex get after syncing, becaue usually I sync using --content.
+
+Thanks,
+Florian
+
diff --git a/doc/forum/HowTo_Conflict_Resolution/comment_1_81c06a0590ee828749b8d07e008028bb._comment b/doc/forum/HowTo_Conflict_Resolution/comment_1_81c06a0590ee828749b8d07e008028bb._comment
new file mode 100644
index 0000000000..1a1405ccc0
--- /dev/null
+++ b/doc/forum/HowTo_Conflict_Resolution/comment_1_81c06a0590ee828749b8d07e008028bb._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-21T16:49:43Z"
+ content="""
+The "variant" names are based on a short hash of the key
+of the file, so there's no way to get from such a name back to the
+repository that the file was added to.
+
+What you can do is, look at the `git log --stat`, and find
+the two conflicting commits, and use git to either revert back to one of
+the two, or reset back to before the automatic merge and manually
+merge the two. 
+
+(Of course, this all works best when the repository is
+in indirect mode and you can use any git commands you like to slice and
+dice it. When the repo is direct mode, you might be able to run those
+same git commands via `git annex proxy`)
+"""]]
diff --git a/doc/forum/HowTo_Conflict_Resolution/comment_2_e0ec78f09e5aba83ad3a7252695e4d96._comment b/doc/forum/HowTo_Conflict_Resolution/comment_2_e0ec78f09e5aba83ad3a7252695e4d96._comment
new file mode 100644
index 0000000000..930253db32
--- /dev/null
+++ b/doc/forum/HowTo_Conflict_Resolution/comment_2_e0ec78f09e5aba83ad3a7252695e4d96._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Horus"
+ subject="comment 2"
+ date="2016-04-17T14:10:15Z"
+ content="""
+A very belayed reply...
+
+I would really love to see a feature to make this easier! Like
+
+* Interactive merge: During merge the user is asked for each file that conflicts, if it wants to keep the local or the remote
+* A set merge tool: A tool that allows to either select the local or remote file, renames it accordingly and commits it.
+
+Currently, I really fear a merge conflict, because I work with sets of binary files that needs to be in a coherent state and a merge conflict gives me very much trouble restoring that state.
+
+Thanks!
+"""]]
diff --git a/doc/forum/HowTo_Conflict_Resolution/comment_3_495aea6e73fd7a2d7a387f539496ac3a._comment b/doc/forum/HowTo_Conflict_Resolution/comment_3_495aea6e73fd7a2d7a387f539496ac3a._comment
new file mode 100644
index 0000000000..05e958f767
--- /dev/null
+++ b/doc/forum/HowTo_Conflict_Resolution/comment_3_495aea6e73fd7a2d7a387f539496ac3a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Horus"
+ subject="comment 3"
+ date="2016-04-17T14:10:37Z"
+ content="""
+A very belayed reply...
+
+I would really love to see a feature to make this easier! Like
+
+* Interactive merge: During merge the user is asked for each file that conflicts, if it wants to keep the local or the remote
+* A set merge tool: A tool that allows to either select the local or remote file, renames it accordingly and commits it.
+
+Currently, I really fear a merge conflict, because I work with sets of binary files that needs to be in a coherent state and a merge conflict gives me very much trouble restoring that state.
+
+Thanks!
+"""]]
diff --git a/doc/forum/HowTo_Conflict_Resolution/comment_4_b209d4527bec4620e1014fe759cbdde7._comment b/doc/forum/HowTo_Conflict_Resolution/comment_4_b209d4527bec4620e1014fe759cbdde7._comment
new file mode 100644
index 0000000000..1c8e0a5fb6
--- /dev/null
+++ b/doc/forum/HowTo_Conflict_Resolution/comment_4_b209d4527bec4620e1014fe759cbdde7._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-04-20T16:43:10Z"
+ content="""
+git's default handling of merge conflict resolution is to require you to
+manually decide which of the two versions of the file to use. So, if you
+just don't use git-annex sync, and instead use git pull, it seems to me
+you'll get what you want.
+
+(You could also use `git annex sync --no-pull --content` to let everything
+except for the pull and merge be done by that command, and run the git pull 
+manually first.)
+"""]]
diff --git a/doc/forum/HowTo_Conflict_Resolution/comment_5_446186626e5b2d08d078e3b48be06bfa._comment b/doc/forum/HowTo_Conflict_Resolution/comment_5_446186626e5b2d08d078e3b48be06bfa._comment
new file mode 100644
index 0000000000..a38aaf3615
--- /dev/null
+++ b/doc/forum/HowTo_Conflict_Resolution/comment_5_446186626e5b2d08d078e3b48be06bfa._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Horus"
+ subject="comment 5"
+ date="2016-05-05T10:00:20Z"
+ content="""
+Ok, that something I can understand.
+
+But still, I think, when using git-annex from the command line the situation of a merge conflict is still extremeley hard to handle. What is the reason against adding from which remote the conflicted data comes from?
+"""]]
diff --git a/doc/forum/HowTo_Conflict_Resolution/comment_6_83cafddb480fa9e5b5d87d27b994b2bc._comment b/doc/forum/HowTo_Conflict_Resolution/comment_6_83cafddb480fa9e5b5d87d27b994b2bc._comment
new file mode 100644
index 0000000000..008bc623b2
--- /dev/null
+++ b/doc/forum/HowTo_Conflict_Resolution/comment_6_83cafddb480fa9e5b5d87d27b994b2bc._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Horus"
+ subject="comment 6"
+ date="2016-05-05T10:01:21Z"
+ content="""
+Normal git also has merge markers that the tell me about which part is from HEAD, which from the branch to merge.
+"""]]
diff --git a/doc/forum/How_To_Permanently_Delete_a_File__63__.mdwn b/doc/forum/How_To_Permanently_Delete_a_File__63__.mdwn
new file mode 100644
index 0000000000..fd654079fc
--- /dev/null
+++ b/doc/forum/How_To_Permanently_Delete_a_File__63__.mdwn
@@ -0,0 +1,13 @@
+Hi,
+
+We have several large git annex repos where all of the files are on remotes and we want to got through and clean up the repositories by deleting some subset of files.
+
+What is the fastest way to permanently delete files from a git annex repository with remotes?
+
+I guess I can to ``git annex drop --numcopies=0 <file>; git rm <file>``. Does that actually delete the file permanently?
+
+Is there a faster way?
+
+Thanks,
+
+Mike
diff --git a/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_1_7f2cefb0991789be5a960eb9c0a9df3f._comment b/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_1_7f2cefb0991789be5a960eb9c0a9df3f._comment
new file mode 100644
index 0000000000..c0eb14174b
--- /dev/null
+++ b/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_1_7f2cefb0991789be5a960eb9c0a9df3f._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="comment 1"
+ date="2014-10-09T17:53:04Z"
+ content="""
+I experimented with this by making an empty directory with two empty files and one file with some content. I added them all, then ran ``git annex drop --numcopies=0 <file>; git rm <file>`` on one of the empty files.
+
+Interestingly, what happened is that git annex deleted the empty file from .git/annex/objects, but left the directory structure. In this case the link pointed to:
+
+.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+
+After the drop command what was left was the following empty directory:
+
+.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/
+
+Also interestingly and terrifyingly, because there were two empty files, both pointed to the same object, the ``git annex drop`` command deleted the file in the objects directory, and now the second link points to nothing. The file is done.
+
+This means that if you have a git annex repository and you have two copies of a file, and you think to yourself, \"oh, let me just delete one, I don't need two\", and you use the method above, you will permanently and irrevocably delete both files.  Not good.
+
+Any better ideas on how to do this?
+"""]]
diff --git a/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_2_d13b456c5b3990082c16e78a50f5db91._comment b/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_2_d13b456c5b3990082c16e78a50f5db91._comment
new file mode 100644
index 0000000000..959ac282ff
--- /dev/null
+++ b/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_2_d13b456c5b3990082c16e78a50f5db91._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="comment 2"
+ date="2014-10-09T18:02:59Z"
+ content="""
+Tried another approach:
+
+``git annex unannex <file>; rm <file>``
+
+This does not delete the original, and it only works if you do ``git annex get <file>`` first. It won't update the remote, unless you cd into that remote and run ``git annex sync`` there. After that there is the illusion the file is done, but its content is still in .git/annex/objects. In my test case I could vim into the file in question in the objects directory and it was still there.
+
+So ``git annex drop`` deletes both copies of duplicate files and so is too dangerous to use and ``git annex unannex`` doesn't delete the file anywhere. I am a little stuck here, what do I do?
+"""]]
diff --git a/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_3_854c17ff8cb38486c4bef618d1e94919._comment b/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_3_854c17ff8cb38486c4bef618d1e94919._comment
new file mode 100644
index 0000000000..404d12ae49
--- /dev/null
+++ b/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_3_854c17ff8cb38486c4bef618d1e94919._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="comment 3"
+ date="2014-10-09T18:16:34Z"
+ content="""
+OK, I should have read more before writing.
+
+It seems like the procedure is described here:
+http://git-annex.branchable.com/walkthrough/unused_data/
+
+The process is:
+1. rm files or directories
+2. git annex sync in all remotes (that is a pain, I wish I only had to do it once)
+3. git annex unused
+4. git annex dropunused
+5. Repeat 4 and 5 on any repository where the data is stored
+
+That does work for me, it is just slightly cumbersome. If there is another way or if I am missing something, please let me know.
+
+Thanks,
+
+Mike
+"""]]
diff --git a/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_4_9572ad02bbf6845b1ab6d7c612c12a2a._comment b/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_4_9572ad02bbf6845b1ab6d7c612c12a2a._comment
new file mode 100644
index 0000000000..6e8ddc5959
--- /dev/null
+++ b/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_4_9572ad02bbf6845b1ab6d7c612c12a2a._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 4"
+ date="2014-10-09T18:23:58Z"
+ content="""
+This post is misplaced, it is not a tip about how to use git-annex, but a question. I will be moving it to the forum after posting this comment.
+
+The right answer is probably to run: `git annex drop $file`, with no --numcopies, no --force, etc. Just let git-annex do its job; it will check the remotes to ensure that enough copies of the file exist to make it safe to drop the content of the file from the local repository. (
+Note that --numcopies=0 is very unsafe, you're asking git-annex to delete even the last copy of your data without checking when you do that.)
+
+If your goal is to get rid of every copy of this file from every repository that has a copy, I suggest just `git rm $file; git commit`, followed by running `git annex unused` in the various repositories to clean them up.
+
+There is a faster way, which is to run `git annex drop --from $remote` for each remote that has the file. If you want to get rid of every copy of the file, for sure, you could add a --force to that.
+
+git-annex deduplicates data, so it's completely expected that if two files have the same content, dropping one will remove the content of the other.
+
+I cannot reproduce any .git/annex/objects/foo empty directories being left behind by git-annex after doing that. Perhaps you are not using a current version of git-annex?
+"""]]
diff --git a/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_5_9c28faabb7d7bd1e83d551e2938d3532._comment b/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_5_9c28faabb7d7bd1e83d551e2938d3532._comment
new file mode 100644
index 0000000000..5f6b0bf089
--- /dev/null
+++ b/doc/forum/How_To_Permanently_Delete_a_File__63__/comment_5_9c28faabb7d7bd1e83d551e2938d3532._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="comment 5"
+ date="2014-10-13T14:51:47Z"
+ content="""
+Sorry about the misplacement, that was a complete accident.
+
+What I am trying to do is to delete files as quickly as possible from every repository. In this case we are using git annex to move non-critical data from our main RAID drive to an external drive while still maintaining the full directory structure on the RAID drive. This is very valuable because we sometimes won't need the data for months or years, but then we may suddenly need a few files, and git annex makes it very easy to get them back. But we are talking about many terabytes and thousands and thousands of files here, and sometimes we just want to completely get rid of that data, it just takes up too much drive space. I wanted to make it as easy and safe as possible for people to just delete files from every repository, hence the question.
+
+I am nervous about using ``git annex drop --force`` because it seems to me that if there are two identical copies of a file in a repository, that command will kill the content of both... or does that only happen with ``git annex drop --numcopies=0``?
+
+I think the best solution for me seems to be the ``git rm <file>; git annex unused; git annex dropunused; git annex sync`` series of commands. It would just be nice if it were possible to achieve the same results in every repository with a simple command such as ``git annex rm --all <file>``. I recognise that this would be a dangerous command, but frankly I feel like in linux, everyone should be aware just how dangerous ``rm`` is in every context :-)
+"""]]
diff --git a/doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__.mdwn b/doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__.mdwn
new file mode 100644
index 0000000000..6989dbf556
--- /dev/null
+++ b/doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__.mdwn
@@ -0,0 +1,13 @@
+I noticed today when running `git annex sync` that it was unhappy with one of my remotes:
+
+```
+remote: git-annex: Repository /home/anovak/annex/.git is at unsupported version 7. Automatic upgrade exception! actually-broken.log: getSymbolicLinkStatus: does not exist (No such file or directory)
+```
+
+Digging in, it looks like that machine is running Ubuntu 20.04, which ships Git Annex 8, which *only* supports repo version 8. The rest of my machines are a mix of Ubuntu 18.04 and other Debian derivatives, which all ship older versions of Git Annex, which *can't* support repo version 8.
+
+Is there a way for me to get out of manually installing Git Annex on every machine to upgrade everything to v8 at the same time?
+
+And, before I've upgraded, is there a way to screw up my repo by e.g. running `git annex sync` from the newer Git Annex and pushing commits in the new format over to machines that still only speak the old format?
+
+How are other people handling this transition where there's no repo format that's speakable by all the machines? Just upgrading everything at once and replacing the distro's git annex with a manually installed version?
diff --git a/doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__/comment_1_30fb300ec5dbdb166f2bb979c6f2ee78._comment b/doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__/comment_1_30fb300ec5dbdb166f2bb979c6f2ee78._comment
new file mode 100644
index 0000000000..fcbb8115e4
--- /dev/null
+++ b/doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__/comment_1_30fb300ec5dbdb166f2bb979c6f2ee78._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2020-10-27T09:06:38Z"
+ content="""
+I just use the (daily) standalone linux build everywhere, not the package from my distro. I extract it to `/opt`, set `GIT_ANNEX_PACKAGE_INSTALL=no` at the top of `git-annex.linux/runshell` and then link git-annex to `/usr/bin/git-annex` with `ln -s /opt/git-annex.linux/git-annex /usr/bin/git-annex`.
+"""]]
diff --git a/doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__/comment_2_23cfa4b9abe96e4477f06c5271b706b2._comment b/doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__/comment_2_23cfa4b9abe96e4477f06c5271b706b2._comment
new file mode 100644
index 0000000000..6465d7efbe
--- /dev/null
+++ b/doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__/comment_2_23cfa4b9abe96e4477f06c5271b706b2._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-10-27T18:23:30Z"
+ content="""
+A git-annex repo consisting of annex symlinks (locked files) can be cloned
+and used on machines running git-annex versions between 2 and 8. (Any
+version from the past 9 years.) It's the same information stored in git.
+
+If you choose to commit unlocked files to the repo, those files will only
+work when using git-annex 7 or 8. But that's optional and you can also just
+re-lock the files to regain compatability all the way back to version 2.
+
+So, no, you do not need to worry about git-annex sync breaking something.
+
+And, git-annex 8 on one machine can talk to git-annex 7 (or any version
+really) on another machine, no problem.
+
+Now, if you have a repo that you are physically moving around between
+machines, on USB for example, then the machines all need have to have
+a git-annex version installed that's compatible with the annex.version
+of the repo.
+"""]]
diff --git a/doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__/comment_3_b05a8c63d2594290769aeeaabc91f491._comment b/doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__/comment_3_b05a8c63d2594290769aeeaabc91f491._comment
new file mode 100644
index 0000000000..adecaebfad
--- /dev/null
+++ b/doc/forum/How_are_people_handling_the_v8_repo_upgrade__63__/comment_3_b05a8c63d2594290769aeeaabc91f491._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="interfect@b151490178830f44348aa57b77ad58c7d18e8fe7"
+ nickname="interfect"
+ avatar="http://cdn.libravatar.org/avatar/3ba541a3204f4ea4b274049a152489c5"
+ subject="comment 3"
+ date="2020-11-05T17:55:31Z"
+ content="""
+Oh, that must be the problem; the remote that's giving me trouble is on NTFS, so I think everything has been automatically unlocked there.
+
+I'll just wait for Raspian to upgrade, and see about switching to a better filesystem in the meantime.
+"""]]
diff --git a/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__.mdwn b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__.mdwn
new file mode 100644
index 0000000000..1349ad95ec
--- /dev/null
+++ b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__.mdwn
@@ -0,0 +1,8 @@
+As title says, how big can a git-annex repo be?
+
+My use case is this:
+I have a few external hard disks (like 2TB, 3TB etc) and each of them have a bunch of files. Ideally I would like to keep all of the data organized in a _single_ git annex repo. However, there are probably a handful of really big files and a LARGE number of really small files, and I doubt its a good idea to put all of them in together.
+
+What should be my biggest concern? I assume file size is not a problem, and I should either tar/zip smaller files into much bigger ones and annex that, or split it up into multiple small annex repositories.
+
+Any suggestions? What do the rest of you with similar amounts of data do?
diff --git a/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_1_99e7e1b178bbb17fffea0892538d4049._comment b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_1_99e7e1b178bbb17fffea0892538d4049._comment
new file mode 100644
index 0000000000..84252ba5b1
--- /dev/null
+++ b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_1_99e7e1b178bbb17fffea0892538d4049._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2015-06-30T07:17:48Z"
+ content="""
+It can actually get really big and still be okay to use, if you follow the [tips page for annexs with lots of files](/tips/Repositories with large number of files).
+
+Mine is still reasonably responsive at 10 million files! Iterating over it all (git annex info, deduping) is really painful though, but it'd be like that without git-annex..
+"""]]
diff --git a/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_2_6a7a3c372599eed7c52d5f54e5287577._comment b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_2_6a7a3c372599eed7c52d5f54e5287577._comment
new file mode 100644
index 0000000000..fc05eddf10
--- /dev/null
+++ b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_2_6a7a3c372599eed7c52d5f54e5287577._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-02T20:44:09Z"
+ content="""
+Depending on the total size of the small files, you might consider a mixed
+repo, with the small files checked into git normally, and the larger files
+annexed. 
+
+The advantage is that you then don't need to use git-annex commands to
+manage the many small files. This will probably be faster, for except you
+won't need to `git annex get` a ton of small files, which will avoid a lot
+of overhead.
+
+Of course, if you have gigabytes of small files, that will result
+in a git repo gigabytes in size, and you will start to run into some of the
+scalability problems that git-annex addresses.
+"""]]
diff --git a/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_3_cc62f722b3e1db7d75d6976ef3854f94._comment b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_3_cc62f722b3e1db7d75d6976ef3854f94._comment
new file mode 100644
index 0000000000..da8067ab29
--- /dev/null
+++ b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_3_cc62f722b3e1db7d75d6976ef3854f94._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Mattt"
+ subject="comment 3"
+ date="2015-07-05T19:40:30Z"
+ content="""
+Thanks CandyAngel and Joey. That helped. I have transferred pretty much my entire repo into git annex now and have it sorted the way I want. Yay! 
+"""]]
diff --git a/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__.mdwn b/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__.mdwn
new file mode 100644
index 0000000000..7a7a5d857c
--- /dev/null
+++ b/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__.mdwn
@@ -0,0 +1,25 @@
+I have a particular annexed file (call its key *K*), and I'm trying to find out why *git annex* considers it in-use.
+
+Joey's comment to [[Dead repo content is not considered unused]] does a good job of explaining why, in theory, a file *might be* considered in-use.
+
+But how can I determine, in a particular case, why a given file *is* in-use?  I.e. how can I determine what's referencing it?
+
+Things I've tried:
+
+* *git annex unused --used-refspec=+foo*, where I'm certain that neither tag *foo* nor any of its ancestors references the file in question (that command doesn't report any unused files)
+
+* Verifying that there are now no symlinks to the annex object in question
+
+* *git log --stat --no-textconv -S'K'* (which produces no output)
+
+Background:
+
+*git annex unused* listed *K* as unused.  I wanted to see what it was, so I did *git annex addunused* on it to create a symlink. (As expected, after this, *git annex unused* reported no unused files.)
+
+Having determined that the file was in fact no longer needed, I rm'ed the symlink, expecting *git annex unused* to again report *K* as unused.  But it doesn't; it still reports no unused files.
+
+I'm not aware of having done anything that would create a reference other than *addunused*'s new symlink, but clearly I did so without being aware of it...
+
+So I'm trying to figure out where that reference is, so I can stomp on it and then *git annex dropunused* to get rid of the file for good.
+
+Thanks.
diff --git a/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_1_30217e593a04cefa30619025d0a58108._comment b/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_1_30217e593a04cefa30619025d0a58108._comment
new file mode 100644
index 0000000000..979211ee7b
--- /dev/null
+++ b/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_1_30217e593a04cefa30619025d0a58108._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-05-10T19:04:00Z"
+ content="""
+Is it in use in git's index? git-annex addunused adds a link to the working
+tree, and also stages it in the index. You said
+"I rm'ed the symlink", but that would leave it in the index, so still used.
+
+(It's also theoretically possible for git-annex unused to incorrectly
+decide something is unused that is not -- it uses a bloom filter which can
+have false positives -- but this is highly unlikely unless your repo has
+a huge number of files in it. The annex.bloomaccuracy and annex.bloomaccuracy
+configs can be used to tweak the bloom filter.)
+"""]]
diff --git a/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_1_6793035e1c0fb329b3094bf66a982fa3._comment b/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_1_6793035e1c0fb329b3094bf66a982fa3._comment
new file mode 100644
index 0000000000..2a7682371f
--- /dev/null
+++ b/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_1_6793035e1c0fb329b3094bf66a982fa3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 1"
+ date="2021-05-10T19:05:57Z"
+ content="""
+> I rm'ed the symlink, expecting git annex unused to again report K as
+> unused.  But it doesn't; it still reports no unused files.
+
+That's odd.  Did you also remove it from the index (`git rm`)?
+
+> git log --stat --no-textconv -S'K'
+
+Perhaps try with `--all` to do a wider search, though given what you
+said above (that is was reported as unused before using `addunused`) my
+bet would be on the index.
+
+"""]]
diff --git a/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_3_7cc944d96f4620e98fe22a554684ad22._comment b/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_3_7cc944d96f4620e98fe22a554684ad22._comment
new file mode 100644
index 0000000000..8c35fe084e
--- /dev/null
+++ b/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_3_7cc944d96f4620e98fe22a554684ad22._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="erics"
+ avatar="http://cdn.libravatar.org/avatar/6e5f74c742128e5d98fd672ed6ea4865"
+ subject="D'oh!"
+ date="2021-05-10T21:26:25Z"
+ content="""
+\"Is it in use in git's index?\"
+
+That was it; after *git reset*, the file is now again reported as unused.
+
+Thanks, and sorry for the noise.
+"""]]
diff --git a/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_4_8323e9160d81a4a65f2ca545c4469869._comment b/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_4_8323e9160d81a4a65f2ca545c4469869._comment
new file mode 100644
index 0000000000..2748925103
--- /dev/null
+++ b/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_4_8323e9160d81a4a65f2ca545c4469869._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="erics"
+ avatar="http://cdn.libravatar.org/avatar/6e5f74c742128e5d98fd672ed6ea4865"
+ subject="comment 4"
+ date="2021-05-10T22:06:02Z"
+ content="""
+May I suggest a *what references this key* command?  With that, I'd have been able to figure out for myself what I'd done wrong.
+"""]]
diff --git a/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_5_a74ece6acb2184c4990b434d7357ea00._comment b/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_5_a74ece6acb2184c4990b434d7357ea00._comment
new file mode 100644
index 0000000000..e04c7bfd48
--- /dev/null
+++ b/doc/forum/How_can_I_determine_why_a_given_file_is___34__used__34____63__/comment_5_a74ece6acb2184c4990b434d7357ea00._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-05-12T15:38:13Z"
+ content="""
+I think that's a good idea... [[todo/git-annex_whereused]]
+"""]]
diff --git a/doc/forum/How_can_I_recover_from_misadventure__63__.mdwn b/doc/forum/How_can_I_recover_from_misadventure__63__.mdwn
new file mode 100644
index 0000000000..624ab38300
--- /dev/null
+++ b/doc/forum/How_can_I_recover_from_misadventure__63__.mdwn
@@ -0,0 +1,10 @@
+Hi, 
+
+  I have been attempting to use `git annex` for archiving about 300gb of data (a usb disk that is a copy of a laptop drive). I have an S3 special remote setup as a backup remote right now (the plan is once I feel like the data is safe on s3 I will change the remote type to archive and get rid of the local copies). I am using the WORM backend. I think something has gone wrong:
+
+1. As of right now I have about 200mb of data on S3, but 'git annex copy --to S3 .' runs for a while, then exits, without any indication that it has uploaded any additional files.
+2. .git/ is around 200gb in size
+3. 'git annex add .' adds files for a while, then exits, and does the same thing when run again.
+4. At this point I decided to try and restart from scratch so I ran 'git annex direct' to get the files replaced in the working directory, this runs for a while then hangs.
+
+This has been my first outing with `git annex`, so I am sort of at a loss as to what there is I can poke at to try and determine what is going on. It would be nice to be able to get the data back to the original state, but more than that, I would like to understand what I did wrong, and I would appreciate any pointers or advice. 
diff --git a/doc/forum/How_can_I_recover_from_misadventure__63__/comment_1_1e8ce32e1e8adf32acf7af28c7ab0d0b._comment b/doc/forum/How_can_I_recover_from_misadventure__63__/comment_1_1e8ce32e1e8adf32acf7af28c7ab0d0b._comment
new file mode 100644
index 0000000000..e96476d791
--- /dev/null
+++ b/doc/forum/How_can_I_recover_from_misadventure__63__/comment_1_1e8ce32e1e8adf32acf7af28c7ab0d0b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-19T20:32:30Z"
+ content="""
+When you say that commands run for a while and then exit, are they exiting
+successfully? With a nonzero exit status? With an error message?
+
+What OS? What git-annex version?
+"""]]
diff --git a/doc/forum/How_can_I_recover_from_misadventure__63__/comment_2_94f5435529802ea9d1980ee07025c6eb._comment b/doc/forum/How_can_I_recover_from_misadventure__63__/comment_2_94f5435529802ea9d1980ee07025c6eb._comment
new file mode 100644
index 0000000000..dede1fc7ac
--- /dev/null
+++ b/doc/forum/How_can_I_recover_from_misadventure__63__/comment_2_94f5435529802ea9d1980ee07025c6eb._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="hiredman@b5864f8a30c0cafbc990313b56c39586ca7a21ec"
+ nickname="hiredman"
+ subject="comment 2"
+ date="2016-01-19T23:11:25Z"
+ content="""
+```
+$ git annex version
+git-annex version: 5.20151218-g5008846
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3(multipartupload) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput DNS Feeds Quvi TDFA TorrentParser Database
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL  
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+$ lsb_release -a
+No LSB modules are available.
+Distributor ID: Ubuntu
+Description:    Ubuntu 15.04
+Release:        15.04
+Codename:       vivid  
+$ uname -a
+Linux aktaios 4.2.0-040200rc2-generic #201507160938 SMP Thu Jul 16 09:49:19 UTC 2015 i686 i686 i686 GNU/Linux
+```
+
+The commands would exit successfully.
+
+
+I realize now that if I wanted to start from scratch the correct thing to do is likely 'git annex uninit' so I am running that now, but it fails often with an error like:
+
+```
+git-annex: Users/hiredman/.gem/specs/rubygems.org%80/quick/Marshal.4.8/bundler-1.0.15.gemspec points to annexed content, but is not checked into git.
+Perhaps this was left behind by an interrupted git annex add?
+Not continuing with uninit; either delete or git annex add the file and retry.
+```
+
+So I wrote in little shell loop to run 'git annex uninit', replace symlink with the contents out of .git/, and run 'git annex uinit' again. This is going slowly and seems to be getting slower, so I guess uninit does some kind of scan of all the files that is interrupted every time it hits the above error, and has to be done again from scratch every time, so as I remove those errors one by one uninit takes longer and longer to hit the next error. So what I need to do is write a script to fix the links up in a single scan. 
+
+"""]]
diff --git a/doc/forum/How_can_I_recover_from_misadventure__63__/comment_3_484fc154c68ba59939aae4452c663ce6._comment b/doc/forum/How_can_I_recover_from_misadventure__63__/comment_3_484fc154c68ba59939aae4452c663ce6._comment
new file mode 100644
index 0000000000..25732bb4b8
--- /dev/null
+++ b/doc/forum/How_can_I_recover_from_misadventure__63__/comment_3_484fc154c68ba59939aae4452c663ce6._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-01-20T19:08:34Z"
+ content="""
+So, this seems to suggest that `git annex add` exited before it got around
+to checking all the files it had added into the git repository.
+
+I don't see how that could happen if the command exited successfully.
+If it were interrupted, sure.
+
+Normally I'd recommend that `git annex add` just be re-run to recover from
+an interrupted add. But if it's just going to exit for some reason again,
+I guess that won't work.
+
+I think you need to strace a git-annex command like `git-annex copy --to S3`
+and see if there's some clue why it's exiting unexpectedly.
+"""]]
diff --git a/doc/forum/How_can_I_use_git-annex_get_a_list_of_files_in_directory_that_have_content__63___.mdwn b/doc/forum/How_can_I_use_git-annex_get_a_list_of_files_in_directory_that_have_content__63___.mdwn
new file mode 100644
index 0000000000..78b10b47a4
--- /dev/null
+++ b/doc/forum/How_can_I_use_git-annex_get_a_list_of_files_in_directory_that_have_content__63___.mdwn
@@ -0,0 +1,6 @@
+Hello.
+How can I use git-annex get a list of files in directory that have content? For each such file the result of command
+
+     git-annex get [file] 
+   
+will be empty.
diff --git a/doc/forum/How_can_I_use_git-annex_get_a_list_of_files_in_directory_that_have_content__63___/comment_1_e897d8fc10474cf865279dc22f22ecb7._comment b/doc/forum/How_can_I_use_git-annex_get_a_list_of_files_in_directory_that_have_content__63___/comment_1_e897d8fc10474cf865279dc22f22ecb7._comment
new file mode 100644
index 0000000000..8a0697e093
--- /dev/null
+++ b/doc/forum/How_can_I_use_git-annex_get_a_list_of_files_in_directory_that_have_content__63___/comment_1_e897d8fc10474cf865279dc22f22ecb7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="arand"
+ ip="130.243.226.21"
+ subject="comment 1"
+ date="2013-12-30T13:15:20Z"
+ content="""
+    git annex find <path>
+
+that's what you meant?
+"""]]
diff --git a/doc/forum/How_can_I_use_git-annex_get_a_list_of_files_in_directory_that_have_content__63___/comment_2_3af326205db6ee04f2a8644baa1dd566._comment b/doc/forum/How_can_I_use_git-annex_get_a_list_of_files_in_directory_that_have_content__63___/comment_2_3af326205db6ee04f2a8644baa1dd566._comment
new file mode 100644
index 0000000000..6fe18b5cb2
--- /dev/null
+++ b/doc/forum/How_can_I_use_git-annex_get_a_list_of_files_in_directory_that_have_content__63___/comment_2_3af326205db6ee04f2a8644baa1dd566._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Alexcei"
+ ip="92.255.239.77"
+ subject="comment 2"
+ date="2013-12-30T13:25:45Z"
+ content="""
+Yes, this is what I need. I have not seen this command before. Thank you.
+"""]]
diff --git a/doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__.mdwn b/doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__.mdwn
new file mode 100644
index 0000000000..b94111e943
--- /dev/null
+++ b/doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__.mdwn
@@ -0,0 +1 @@
+I have several TB of media on a Debian ZFS server. If I created a git-annex repo for the data, how hard would it be get git-annex (using bup I assume) to back up the files onto a set of Blu Ray disks? I realize that 8TB of data would take about 320 BR 25GB disks, but it seems like git annex would be great for identifying what disk(s) I needed to recover a file. I'm good at bash scripting, and use git daily. I have no experience with git-annex or bup however. Any links to information or suggestions is very appreciated. Thanks!
diff --git a/doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/comment_1_ea2f6ca0768c55fa136606cf091471cd._comment b/doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/comment_1_ea2f6ca0768c55fa136606cf091471cd._comment
new file mode 100644
index 0000000000..d004c06a08
--- /dev/null
+++ b/doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/comment_1_ea2f6ca0768c55fa136606cf091471cd._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-01T21:36:59Z"
+ content="""
+There was a previous thread about using DVDS:
+<http://git-annex.branchable.com/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__>
+
+If the bluerays are rewritable, I'd probably just slap a Real Filesystem
+(ext2 not isofs) on there and put a regular git-annex repo on it. I'd probably
+run git-annex with the option "-c annex.alwayscommit=false" to prevent it
+making many commits to the repo on the blueray, which would rewrite parts of
+this disk, perhaps too often.
+
+Or, to avoid any rewrites at all (except to directory metadata),
+I might use a directory special remote on the blueray.
+
+I don't see much benefit to using bup over the directory special remote.
+
+If the bluerays are not rewritable, I might try making the git-annex repo
+in a temporary directory on the hard disk, and then generating the ISO
+from that once I've filled it up. Should work fine, I might set "remote.<name>.annex-readonly"
+to true in git repos that had such a disk as a remote to let git-annex
+know to not try to write to it.
+"""]]
diff --git a/doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/comment_2_d79387905af9f8dce77f9aa85f2d6a03._comment b/doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/comment_2_d79387905af9f8dce77f9aa85f2d6a03._comment
new file mode 100644
index 0000000000..4d7caf7496
--- /dev/null
+++ b/doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/comment_2_d79387905af9f8dce77f9aa85f2d6a03._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/e1w.8yMTnpUh.5fOXneP92pTdy23XJPwx84uLSM-#aca7c"
+ nickname="Michael"
+ subject="re: backup my data to blue ray disks"
+ date="2015-05-11T21:13:19Z"
+ content="""
+Thank you for your response. The disks are BD-R, so they are not rewritable. My experience in the past with rewritable disks has been that they work about as well as the average TV infomercial product. Do you have any opinions or suggestions on using par2 files on the disks?
+"""]]
diff --git a/doc/forum/How_do_I_cleanly_remove_an_Android_git-annex_installation__63__.mdwn b/doc/forum/How_do_I_cleanly_remove_an_Android_git-annex_installation__63__.mdwn
new file mode 100644
index 0000000000..a4bcc4843c
--- /dev/null
+++ b/doc/forum/How_do_I_cleanly_remove_an_Android_git-annex_installation__63__.mdwn
@@ -0,0 +1 @@
+I had accidentally chosen the wrong directory for the repository. What should I do to clean all of git-annex?
diff --git a/doc/forum/How_do_I_cleanly_remove_an_Android_git-annex_installation__63__/comment_1_e14757c2c106770c2d7069ace4987b3b._comment b/doc/forum/How_do_I_cleanly_remove_an_Android_git-annex_installation__63__/comment_1_e14757c2c106770c2d7069ace4987b3b._comment
new file mode 100644
index 0000000000..b051aa704a
--- /dev/null
+++ b/doc/forum/How_do_I_cleanly_remove_an_Android_git-annex_installation__63__/comment_1_e14757c2c106770c2d7069ace4987b3b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 1"
+ date="2013-08-24T18:43:08Z"
+ content="""
+It should be sufficient to delete `/sdcard/git-annex.home` and delete the .git directory inside whatever directory you set up as the repository.
+"""]]
diff --git a/doc/forum/How_do_I_do_with_.gitrefs__47_____63__.mdwn b/doc/forum/How_do_I_do_with_.gitrefs__47_____63__.mdwn
new file mode 100644
index 0000000000..d4a2a71b14
--- /dev/null
+++ b/doc/forum/How_do_I_do_with_.gitrefs__47_____63__.mdwn
@@ -0,0 +1 @@
+There is .gitrefs directory in my annexed repo while I am unaware. Should I do `git add .gitrefs/` or `git annex add .gitrefs/` or just ignore?
diff --git a/doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_1_5e235af2ea13fd4f6a226c842f69965e._comment b/doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_1_5e235af2ea13fd4f6a226c842f69965e._comment
new file mode 100644
index 0000000000..9e8d044a1e
--- /dev/null
+++ b/doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_1_5e235af2ea13fd4f6a226c842f69965e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 1"
+ date="2014-01-06T15:44:15Z"
+ content="""
+AFAIK neither git nor git-annex creates a .gitrefs directory.
+"""]]
diff --git a/doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_2_50d0c643537175b514d5eae604fb5bea._comment b/doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_2_50d0c643537175b514d5eae604fb5bea._comment
new file mode 100644
index 0000000000..a812e99b0f
--- /dev/null
+++ b/doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_2_50d0c643537175b514d5eae604fb5bea._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="80.203.53.96"
+ subject="comment 2"
+ date="2014-01-11T07:51:57Z"
+ content="""
+I have noticed a .gitrefs/ directory being added to my git-annex repositories as well.
+Two direct-mode git-annex assistant-managed repos have turned up a .gitrefs directory the past month or so, with the directory often returning after I remove it. First occurrance according to git logs is on the 3rd of December.
+
+The directory looks a lot like .git/refs, as if some tool is trying to do something to .git/refs but has a bug that removes the first /, and then proceeds to copy or recreate the files.
+
+    [0 zerodogg@firefly annexed]$ du -hs .gitrefs .git/refs
+    172K    .gitrefs
+    192K    .git/refs
+    [0 zerodogg@firefly annexed]$ find .gitrefs > /tmp/gitr1
+    [0 zerodogg@firefly annexed]$ find .git/refs > /tmp/gitr2
+    [0 zerodogg@firefly annexed]$ perl -pi -e 's/^\.git.?refs//' /tmp/gitr*                                                                                                   
+    [0 zerodogg@firefly annexed]$ diff -BrayN --suppress-common-lines /tmp/gitr1 /tmp/gitr2                                                                                   
+                                                                  > /tags
+                                                                  > /remotes/browncoats
+                                                                  > /remotes/browncoats/master
+                                                                  > /remotes/browncoats/synced
+                                                                  > /remotes/browncoats/synced/master
+                                                                  > /remotes/browncoats/synced/git-annex
+                                                                  > /remotes/browncoats/git-annex
+                                                                  > /remotes/browncoats/annex
+                                                                  > /remotes/browncoats/annex/direct
+                                                                  > /remotes/browncoats/annex/direct/master
+    /remotes/serenity/master                                      <
+    /remotes/zoe                                                  | /remotes/faerun/annex
+    /remotes/zoe/master                                           | /remotes/faerun/annex/direct
+    /remotes/zoe/synced                                           | /remotes/faerunpi
+    /remotes/zoe/synced/master                                    | /remotes/faerunpi/synced
+    /remotes/zoe/synced/git-annex                                 | /remotes/faerunpi/annex
+    /remotes/firefly                                              | /remotes/faerunpi/annex/direct
+    /remotes/firefly/master                                       <
+    /remotes/firefly/synced                                       <
+    /remotes/firefly/synced/master                                <
+    /remotes/firefly/synced/git-annex                             <
+    /remotes/firefly/git-annex                                    <
+    /remotes/firefly/annex                                        <
+    /remotes/firefly/annex/direct                                 <
+    /remotes/firefly/annex/direct/master                          <
+    /remotes/river/master                                         <
+                                                                  > /remotes/origin
+                                                                  > /remotes/origin/synced
+                                                                  > /remotes/hufsa
+                                                                  > /remotes/hufsa/synced
+                                                                  > /synced
+
+"""]]
diff --git a/doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_3_3d342c32b14c7edbece596ba970a8415._comment b/doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_3_3d342c32b14c7edbece596ba970a8415._comment
new file mode 100644
index 0000000000..8902e004a6
--- /dev/null
+++ b/doc/forum/How_do_I_do_with_.gitrefs__47_____63__/comment_3_3d342c32b14c7edbece596ba970a8415._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.43"
+ subject="comment 3"
+ date="2014-01-15T20:40:35Z"
+ content="""
+A bug in the git repository repair code caused packed-refs files to be exploded to .gitrefs instead of .git/refs. I have fixed that bug.
+
+To fix up a repository that this happened to, I'd recommend checking if there are any tags and branches in the .gitrefs directory that have gone missing from .git/refs.. If so, you could move the files back into place (unannexing them first if necessary). Otherwise, deleting .gitrefs would seem to be the thing to do.
+"""]]
diff --git a/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__.mdwn b/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__.mdwn
new file mode 100644
index 0000000000..c9a5a6c0a4
--- /dev/null
+++ b/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__.mdwn
@@ -0,0 +1,3 @@
+`git annex dropunused` is simple enough.
+
+But how do I perform the equivalent procedure on an rsync remote?  I'd presume that `git annex copy --to remote` is not sufficient.
diff --git a/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_1_8db3cb5348b845eb99c2c829957db9ea._comment b/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_1_8db3cb5348b845eb99c2c829957db9ea._comment
new file mode 100644
index 0000000000..026d393bb5
--- /dev/null
+++ b/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_1_8db3cb5348b845eb99c2c829957db9ea._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c"
+ nickname="Justin"
+ subject="comment 1"
+ date="2013-05-12T23:06:34Z"
+ content="""
+Oh, sheesh, it's right there at the bottom of http://git-annex.branchable.com/special_remotes/.  Oops.
+"""]]
diff --git a/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_2_6cc909d9d74bc1ccb8a7b0d7d234c7cd._comment b/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_2_6cc909d9d74bc1ccb8a7b0d7d234c7cd._comment
new file mode 100644
index 0000000000..2df92a8a36
--- /dev/null
+++ b/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_2_6cc909d9d74bc1ccb8a7b0d7d234c7cd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-05-13T18:03:23Z"
+ content="""
+Well, in your defense it's documented there because I can't think of a better place to put it. Maybe you looked in some other places first before finding it there, and I should add a pointer to those places?
+
+(For the curious, the magic run is just: git annex unused --from remote)
+"""]]
diff --git a/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_3_f24d678e4192a70322aa164ed9b71fc8._comment b/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_3_f24d678e4192a70322aa164ed9b71fc8._comment
new file mode 100644
index 0000000000..2b53984c37
--- /dev/null
+++ b/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_3_f24d678e4192a70322aa164ed9b71fc8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c"
+ nickname="Justin"
+ subject="comment 3"
+ date="2013-05-13T18:56:32Z"
+ content="""
+I think in general the `git annex command --help` bits could be more thorough.  If `git annex dropunused --help` indicated that it took `--from`, that would probably have helped me.
+"""]]
diff --git a/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_4_9233decd0aaf9211447f36e0d9346445._comment b/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_4_9233decd0aaf9211447f36e0d9346445._comment
new file mode 100644
index 0000000000..f326cd3400
--- /dev/null
+++ b/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_4_9233decd0aaf9211447f36e0d9346445._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-05-13T18:59:08Z"
+ content="""
+You might be using an older version. Here's the output of that command in the current version:
+
+<pre>
+Usage: git-annex dropunused NUM|RANGE ... [option ...]
+  -f REMOTE  --from=REMOTE  drop content from a remote
+
+To see additional options common to all commands, run: git annex help options
+</pre>
+"""]]
diff --git a/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_5_e1deb110f752e5495d5c77ec444abac5._comment b/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_5_e1deb110f752e5495d5c77ec444abac5._comment
new file mode 100644
index 0000000000..e9ca6bc138
--- /dev/null
+++ b/doc/forum/How_do_I_dropunused_with_an_rsync_remote__63__/comment_5_e1deb110f752e5495d5c77ec444abac5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c"
+ nickname="Justin"
+ subject="comment 5"
+ date="2013-05-13T19:07:11Z"
+ content="""
+Ah, rebuilding got me that.  That's pretty good!
+"""]]
diff --git a/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__.mdwn b/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__.mdwn
new file mode 100644
index 0000000000..209e0f6a78
--- /dev/null
+++ b/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__.mdwn
@@ -0,0 +1,16 @@
+Hello,
+
+I had some trouble adding a remote (the files would not appear when I was copying them to the remote), so I started over and cloned an existing repository.
+
+Of course, as I started over, I had a duplicate uuid for the remote, which would cause problems when trying to copy (I would have an error "git-annex-shell: expected repository UUID 70582c7b-0b57-4087-a9d1-77b5f5f3c75e but found UUID 335699ea-d5b8-49ff-b207-1571b5969afe").
+
+I finally managed to find the wrong uuid in the .git/config file (there was a duplicated entry for the remote) and I'm now able to copy things to the remote repository, and "git annex sync" works well. However I still see a mention of this repository when I do a "git annex whereis":
+
+    cody:games schmitta$ git annex whereis
+    whereis dungeon_keeper_1.1.0.11.dmg (3 copies) 
+      	1cdfb490-0660-41fb-b7ce-74b89abb9aac -- top
+       	335699ea-d5b8-49ff-b207-1571b5969afe -- here (cody)
+       	70582c7b-0b57-4087-a9d1-77b5f5f3c75e
+
+
+Where can I find where this last line come from, and how can I get rid of it? I tried saying that this uuid is dead, but git annex tells me it's not a remote name.
diff --git a/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_1_b3c215cedba51fb47992ef10c60d6acc._comment b/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_1_b3c215cedba51fb47992ef10c60d6acc._comment
new file mode 100644
index 0000000000..80b664dced
--- /dev/null
+++ b/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_1_b3c215cedba51fb47992ef10c60d6acc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://alan.petitepomme.net/"
+ nickname="Alan Schmitt"
+ subject="comment 1"
+ date="2014-03-08T06:42:29Z"
+ content="""
+If it helps, I had a look at \"git annex vicfg\", and there is no mention of the extra UUID there.
+"""]]
diff --git a/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_2_85415e1fceb737919cc1cd9f37242458._comment b/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_2_85415e1fceb737919cc1cd9f37242458._comment
new file mode 100644
index 0000000000..a251dade38
--- /dev/null
+++ b/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_2_85415e1fceb737919cc1cd9f37242458._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.154"
+ subject="comment 2"
+ date="2014-03-12T19:35:26Z"
+ content="""
+Probably this will fix it:
+
+`git annex dead 70582c7b-0b57-4087-a9d1-77b5f5f3c75e`
+"""]]
diff --git a/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_3_fb3a591dc60182f7922fc2b5c24f50f1._comment b/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_3_fb3a591dc60182f7922fc2b5c24f50f1._comment
new file mode 100644
index 0000000000..bebd8f290d
--- /dev/null
+++ b/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_3_fb3a591dc60182f7922fc2b5c24f50f1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://alan.petitepomme.net/"
+ nickname="Alan Schmitt"
+ subject="comment 3"
+ date="2014-03-13T20:05:53Z"
+ content="""
+Unfortunately git annex tells me there is no such remote:
+
+    cody:games schmitta$ git annex dead 70582c7b-0b57-4087-a9d1-77b5f5f3c75e
+    dead 70582c7b-0b57-4087-a9d1-77b5f5f3c75e git-annex: there is no available git remote named \"70582c7b-0b57-4087-a9d1-77b5f5f3c75e\"
+"""]]
diff --git a/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_4_aed0be32e579c7a39c63aa7e3ec5f67b._comment b/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_4_aed0be32e579c7a39c63aa7e3ec5f67b._comment
new file mode 100644
index 0000000000..99ac0d5a6a
--- /dev/null
+++ b/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_4_aed0be32e579c7a39c63aa7e3ec5f67b._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.154"
+ subject="comment 4"
+ date="2014-03-14T17:46:23Z"
+ content="""
+It seems that the git-annex branch's uuid.log must somehow not list this uuid, but it's used in the location tracking log files. 
+
+The only way I can think of that this could happen is if you had set up a repository, run git-annex init, and then went in and changed the annex.uuid setting to this other uuid, and added files with that misconfiguration. Does that sound like what happened?
+
+The fix is just as evil as the cause -- you can edit .git/config to add a new, dummy git remote that has annex-uuid set to the problem uuid, and then `git-annex dead` can be used to kill the uuid via that remote. For example:
+
+[[!format sh \"\"\"
+joey@darkstar:~/tmp/x>git annex whereis eep
+whereis eep (1 copy) 
+  	00000a6d-e770-4ab9-a640-7d6272e9ffff
+ok
+joey@darkstar:~/tmp/x>git annex dead 00000a6d-e770-4ab9-a640-7d6272e9ffff
+dead 00000a6d-e770-4ab9-a640-7d6272e9ffff git-annex: there is no available git remote named \"00000a6d-e770-4ab9-a640-7d6272e9ffff\"
+- exit 1
+joey@darkstar:~/tmp/x>git remote add dummy dummy
+joey@darkstar:~/tmp/x>git config remote.dummy.annex-uuid 00000a6d-e770-4ab9-a640-7d6272e9ffff
+joey@darkstar:~/tmp/x>git annex dead dummy
+dead dummy ok
+(Recording state in git...)
+joey@darkstar:~/tmp/x>git annex whereis eep
+whereis eep (0 copies) failed
+\"\"\"]]
+"""]]
diff --git a/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_5_0c9a6c8a92d6c6e04ae3a8349b799c60._comment b/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_5_0c9a6c8a92d6c6e04ae3a8349b799c60._comment
new file mode 100644
index 0000000000..9807fb7d9f
--- /dev/null
+++ b/doc/forum/How_do_I_get_rid_of_a_wrong_remote_uuid__63__/comment_5_0c9a6c8a92d6c6e04ae3a8349b799c60._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="http://alan.petitepomme.net/"
+ nickname="Alan Schmitt"
+ subject="comment 5"
+ date="2014-03-14T18:11:52Z"
+ content="""
+Thanks, it worked!
+
+Regarding how I got into that state, here is what happened:
+- I configured a new repository (git init, git annex init) on machine B
+- I added that repository as a remote from machine A
+- I started pushing files from machine A to machine B, starting with the file that later showed this problem
+- I then noticed that, although the files were said to be successfully sent, I could not see them on machine B (no symbolic link was created), even after a \"git annex sync\" there
+- I decided to start over, deleting the annex, and creating it from a clone of an existing annex
+- This resulted in a duplicated UUID for the same path, which led to this problem
+
+Maybe some documentation on how to cleanly start over when things get in a bad state would be very useful.
+
+Thanks again,
+
+Alan
+"""]]
diff --git a/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__.mdwn b/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__.mdwn
new file mode 100644
index 0000000000..72e39cc360
--- /dev/null
+++ b/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__.mdwn
@@ -0,0 +1,2 @@
+Files only present in remotes show up as broken symlinks. That's great for knowing what files exist, but sometimes I just want to browse the files that are actually present. In this case, the many broken symlinks are just clutter.
+Is there a straightforward way to switch to a view that shows only locally present files?
diff --git a/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_1_005e9254a1239164df34ab5fbf2115a8._comment b/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_1_005e9254a1239164df34ab5fbf2115a8._comment
new file mode 100644
index 0000000000..b15296b33b
--- /dev/null
+++ b/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_1_005e9254a1239164df34ab5fbf2115a8._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlZ-6dtxJY4cP7shhvV8E6YyuV0Rak8it4"
+ nickname="Giovanni"
+ subject="direct mode: avoid broken symlinks; indirect mode: matching-options in views (not woring)"
+ date="2015-04-18T07:56:32Z"
+ content="""
+I would like to see only locally present files too, for some of my use case (e.g.: movies exported via NFS to a XBMS/Kodi media player)
+
+I'm using git annex (debian) version 5.20141024~bpo70+1
+
+# [direct mode](http://git-annex.branchable.com/direct_mode/)
+
+as far as I understand, in direct mode broken symlinks (or text files placeholders for filesystems not supporting symlinks) are there by [design](
+https://git-annex.branchable.com/design/assistant/desymlink/), in particular in [partial content](
+https://git-annex.branchable.com/design/assistant/partial_content/) use case where \"there needs to be a way for the user to browse files not on the gadget and request they be transferred to it\"
+
+if there are no other reasons to have broken symlinks (or placeholders) I think git-annex should avoid them (at least in direct mode): if a user needs a file not listed by regular filesystem tools she can simply `git-annex find` it and `git-annex get` it: or do I miss something here?
+
+please consider avoiding broken symlinks or placeholders
+
+# indirect mode
+
+in indirect mode we could live with broken symlinks using views; I tried `git annex view /=* --include=\"*\" --in=here` but the resulting tree was not filtered by matching-options
+
+are matching-options intended to work with the view command or not?
+
+"""]]
diff --git a/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_2_f376604560c36a0aa5afa4619797b396._comment b/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_2_f376604560c36a0aa5afa4619797b396._comment
new file mode 100644
index 0000000000..27197fc82a
--- /dev/null
+++ b/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_2_f376604560c36a0aa5afa4619797b396._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="GiovanniBiscuolo"
+ subject="hide files not present in the local annex: related forum post"
+ date="2015-04-23T11:00:56Z"
+ content="""
+[How to hide broken symlinks](http://git-annex.branchable.com/forum/How_to_hide_broken_symlinks/)
+
+using views (but see comments)
+"""]]
diff --git a/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_5_1ed5e10e51078a0aa7e6968ef48687a3._comment b/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_5_1ed5e10e51078a0aa7e6968ef48687a3._comment
new file mode 100644
index 0000000000..bf55735a57
--- /dev/null
+++ b/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_5_1ed5e10e51078a0aa7e6968ef48687a3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-10-18T18:59:54Z"
+ content="""
+Good news everyone! `git annex adjust --hide-missing` sets up a branch
+where only files with content available are included. And once in such a
+branch, `git annex sync` updates it as necessary to reflect changes in
+content availability.
+"""]]
diff --git a/doc/forum/How_do_I_list_links_with_0_copies__63__.mdwn b/doc/forum/How_do_I_list_links_with_0_copies__63__.mdwn
new file mode 100644
index 0000000000..663549ee28
--- /dev/null
+++ b/doc/forum/How_do_I_list_links_with_0_copies__63__.mdwn
@@ -0,0 +1,5 @@
+I've been searching around and can't find this. I don't need `git annex unused`, but something that'll list the files I should "git rm".
+
+The best solution I've found so far is:
+
+    git annex whereis|grep '0 copies.*failed'|perl -pe 's/^whereis (.*?) \(0 copies\) failed$/$1/'
diff --git a/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_1_ee222f0e227f1c65f84f73af399239e5._comment b/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_1_ee222f0e227f1c65f84f73af399239e5._comment
new file mode 100644
index 0000000000..fdebc58a80
--- /dev/null
+++ b/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_1_ee222f0e227f1c65f84f73af399239e5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-12-28T00:15:34Z"
+ content="""
+	git annex find --not --copies 1
+
+This works because --copies 1 finds all files with 1 or more copies,
+and so inverting it with --not finds all files with fewer copies.
+"""]]
diff --git a/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_2_1528b3c96d6ad5637c2fdda33057c12f._comment b/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_2_1528b3c96d6ad5637c2fdda33057c12f._comment
new file mode 100644
index 0000000000..ca54006289
--- /dev/null
+++ b/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_2_1528b3c96d6ad5637c2fdda33057c12f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="avar"
+ avatar="http://cdn.libravatar.org/avatar/57332d67a86eb51e06bf78d2baf42c3c"
+ subject="comment 2"
+ date="2016-12-28T08:28:35Z"
+ content="""
+Great, this one-liner is then exactly what I needed:
+
+    git annex find --not --copies 1 --print0 | xargs -0 git rm
+"""]]
diff --git a/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_3_e629a5393e56755a42581be9f6942adb._comment b/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_3_e629a5393e56755a42581be9f6942adb._comment
new file mode 100644
index 0000000000..5470332252
--- /dev/null
+++ b/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_3_e629a5393e56755a42581be9f6942adb._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="ghen1"
+ avatar="http://cdn.libravatar.org/avatar/efd0e92b6198291138f0cd7aedbf86b6"
+ subject="comment 3"
+ date="2016-12-28T11:16:17Z"
+ content="""
+When I first read this:
+
+    git annex find --not --copies 1
+
+I expected it would also select files with *more* than 1 copy. Nothing wrong with it if it works; just seems semantically ambiguous to me.
+"""]]
diff --git a/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_4_61a441f83ef690da8e799b0503526c47._comment b/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_4_61a441f83ef690da8e799b0503526c47._comment
new file mode 100644
index 0000000000..3f8bad328e
--- /dev/null
+++ b/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_4_61a441f83ef690da8e799b0503526c47._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="avar"
+ avatar="http://cdn.libravatar.org/avatar/57332d67a86eb51e06bf78d2baf42c3c"
+ subject="A useful command in combination with this"
+ date="2019-04-24T12:37:35Z"
+ content="""
+I've found this useful in combination with this:
+
+```
+git annex find --copies 1 --and --in=NAME --print0 | xargs -0 git annex drop --force
+```
+
+Where `NAME` is some remote of \"incoming downloads\". If nobody's fetched stuff from it let's just \"drop\" it. Running this before the command Joey suggested is best.
+"""]]
diff --git a/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_5_66def7cfeef20866eb3caced831b0d3e._comment b/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_5_66def7cfeef20866eb3caced831b0d3e._comment
new file mode 100644
index 0000000000..ed83192d82
--- /dev/null
+++ b/doc/forum/How_do_I_list_links_with_0_copies__63__/comment_5_66def7cfeef20866eb3caced831b0d3e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-05-06T16:05:40Z"
+ content="""
+Other git-annex comnands than find support the same options for matching
+files, so you can just use:
+
+	git annex drop --copies=1 --and in=NAME
+"""]]
diff --git a/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex.mdwn b/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex.mdwn
new file mode 100644
index 0000000000..90856383a8
--- /dev/null
+++ b/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex.mdwn
@@ -0,0 +1,8 @@
+I want to go back to a specific commit in git annex as I lost most recent copies of a file and want to revert back to a previous revision, few months old. All remotes are dead but after reading few article, there might be a way to get the file back from the objects directory:
+
+git annex whereis image 
+whereis image (0 copies) failed
+git-annex: whereis: 1 failed
+
+Thanks,
+
diff --git a/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_1_ab8896c4f0e20fb351477e3dc92a35d8._comment b/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_1_ab8896c4f0e20fb351477e3dc92a35d8._comment
new file mode 100644
index 0000000000..fa99665fd8
--- /dev/null
+++ b/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_1_ab8896c4f0e20fb351477e3dc92a35d8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-28T17:37:11Z"
+ content="""
+This works the same with git-annex as it does with regular git. You can
+use `git revert` or `git reset` or whatever.
+"""]]
diff --git a/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_2_8f02d0c400d22866e38cc521dd55b2c2._comment b/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_2_8f02d0c400d22866e38cc521dd55b2c2._comment
new file mode 100644
index 0000000000..a8081ccf54
--- /dev/null
+++ b/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_2_8f02d0c400d22866e38cc521dd55b2c2._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="basile.pinsard@f1a7fae9f3bd9d5282fca11f62ad53b45a8eb317"
+ nickname="basile.pinsard"
+ avatar="http://cdn.libravatar.org/avatar/87e1f73acf277ad0337b90fc0253c62e"
+ subject="reverting metadata"
+ date="2020-05-21T13:39:37Z"
+ content="""
+If I revert to a previous commit, the metadata changes are not reverted to their previous state.
+Is there a way to revert metadata?
+If I understood that correctly, the metadata are stored in a single git-annex branch: so there is no way to have two regular branches with different metadata for the same file, right?
+Does any call to git-annex metadata creates a new commit in the git-annex branch?
+The commit message of the git-annex branch are not super informative: they all say \"update\".
+
+A related question: is there a way to get the git-annex branch commit that matches a regular/master branch commit?
+
+Thanks.
+"""]]
diff --git a/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_3_1b84261a9e6389bcad1766b82add4930._comment b/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_3_1b84261a9e6389bcad1766b82add4930._comment
new file mode 100644
index 0000000000..04221cbe24
--- /dev/null
+++ b/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_3_1b84261a9e6389bcad1766b82add4930._comment
@@ -0,0 +1,52 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 3"
+ date="2020-05-21T17:06:12Z"
+ content="""
+> If I revert to a previous commit, the metadata changes are not
+> reverted to their previous state.
+
+Metadata is attached to keys, not files.  (See `man
+git-annex-metadata`.)  If the state you revert to has the same key, it
+will have the same associated metadata.
+
+> Is there a way to revert metadata?
+
+AFAIU not in a way that is tied to the HEAD commit.  You can run `git
+annex metadata --remove-all FILE`, but that will remove the metadata
+on the underlying key.
+
+> If I understood that correctly, the metadata are stored in a single
+> git-annex branch: so there is no way to have two regular branches with
+> different metadata for the same file, right?
+
+Correct.
+
+> Does any call to git-annex metadata creates a new commit in the
+> git-annex branch?
+
+I believe so, provided the caller hasn't overridden
+`annex.alwayscommit` to \"false\".
+
+> The commit message of the git-annex branch are not super
+> informative: they all say \"update\".
+
+In my view generic messages like \"update\" make a lot of sense in the
+context of the behind-the-scenes git-annex branch.  If you're
+inspecting it just because you're curious about what's happening
+underneath, you might find the output of `git log --stat git-annex`
+helpful.
+
+That being said, there is an `annex.commitmessage` config option if
+you want to override the message.
+
+https://git-annex.branchable.com/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/
+
+> A related question: is there a way to get the git-annex branch commit
+> that matches a regular/master branch commit?
+
+I don't think there is any such mapping by design.
+
+
+"""]]
diff --git a/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_4_577f586843c1d7e54d115796988f912d._comment b/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_4_577f586843c1d7e54d115796988f912d._comment
new file mode 100644
index 0000000000..3200ca1dad
--- /dev/null
+++ b/doc/forum/How_do_I_revert_back_to_specific_commit_with_git_annex/comment_4_577f586843c1d7e54d115796988f912d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="basile.pinsard@f1a7fae9f3bd9d5282fca11f62ad53b45a8eb317"
+ nickname="basile.pinsard"
+ avatar="http://cdn.libravatar.org/avatar/87e1f73acf277ad0337b90fc0253c62e"
+ subject="comment 4"
+ date="2020-05-22T13:24:19Z"
+ content="""
+Thanks for the detailed answer.
+
+So the only way to revert metadata changes is to reset the git-annex branch to a previous commit with `git update-ref refs/heads/git-annex <commit>`. 
+
+Thanks for the `git-log --stat` tip.
+
+I guess I could get an approximate match between the master and git-annex branches commits based on commit date.
+"""]]
diff --git a/doc/forum/How_do_I_set_up_git_annex_with_nextcloud.mdwn b/doc/forum/How_do_I_set_up_git_annex_with_nextcloud.mdwn
new file mode 100644
index 0000000000..3baad46a75
--- /dev/null
+++ b/doc/forum/How_do_I_set_up_git_annex_with_nextcloud.mdwn
@@ -0,0 +1,10 @@
+I am probably doing something fundamentally wrong. Here are the steps I've tried:
+
+1. Create a new repository using the webapp (on two virtual machines)
+2. Create a nextcloud account and folder and on the first VM ran: `WEBDAV_USERNAME=test WEBDAV_PASSWORD=whocaresforatest git annex initremote owncloud type=webdav url=https://SERVERNAME/remote.php/webdav/annex chunk=10mb encryption=hybrid keyid=randomkey@igenerated.forthis`. This seemed to lead to some synchronization.
+3. Did the same thing on the second virtual machine.
+4. On the first VM ran: `git annex enableremote owncloud keyid+=keyigenerated@forthesecond.vm`
+
+The problem is, both seem to sync something to the nextcloud installation but they don't seem to be syncing with each other.
+
+What did I do wrong?
diff --git a/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_1_2528e595b04232de60571279ded4c2e8._comment b/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_1_2528e595b04232de60571279ded4c2e8._comment
new file mode 100644
index 0000000000..2c64c00843
--- /dev/null
+++ b/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_1_2528e595b04232de60571279ded4c2e8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nordmagnus999"
+ avatar="http://cdn.libravatar.org/avatar/d5d5b418451be64f8fa5f56909fcc4c3"
+ subject="A possible solution"
+ date="2019-10-28T15:49:12Z"
+ content="""
+You could use [git-annex-remote-rclone script](https://github.com/DanielDent/git-annex-remote-rclone) which support nextcloud/owncloud with its webdav remote iirc. (Also the rclone remote is officially supported by git-annex on the last version afaik + its bundled in some distro's repos).
+"""]]
diff --git a/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_2_562dbc96302644f915a0b8e33428c69a._comment b/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_2_562dbc96302644f915a0b8e33428c69a._comment
new file mode 100644
index 0000000000..b1791bb8fd
--- /dev/null
+++ b/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_2_562dbc96302644f915a0b8e33428c69a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nordmagnus999"
+ avatar="http://cdn.libravatar.org/avatar/d5d5b418451be64f8fa5f56909fcc4c3"
+ subject="Oh yeah, use verbose flag too."
+ date="2019-10-28T15:50:42Z"
+ content="""
+I think it would make more sense to use the verbose flag for debugging imo.
+"""]]
diff --git a/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_3_7fa312e85acd3f9afbfd97d46057e6db._comment b/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_3_7fa312e85acd3f9afbfd97d46057e6db._comment
new file mode 100644
index 0000000000..5738f6d48d
--- /dev/null
+++ b/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_3_7fa312e85acd3f9afbfd97d46057e6db._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Simon"
+ subject="Can you give more details?"
+ date="2019-10-28T16:04:52Z"
+ content="""
+I just started trying to use git-annex. To which command should I add the verbose flag?
+"""]]
diff --git a/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_4_7980af82df895cdd4b5c527bbb2f4c72._comment b/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_4_7980af82df895cdd4b5c527bbb2f4c72._comment
new file mode 100644
index 0000000000..e7f4c3debc
--- /dev/null
+++ b/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_4_7980af82df895cdd4b5c527bbb2f4c72._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Simon"
+ subject="Should there have been a combine step?"
+ date="2019-10-28T16:06:22Z"
+ content="""
+From watching the introductory video it looks like there should be a different step for adding the second remote. Did I maybe screw up using `init` again?
+"""]]
diff --git a/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_5_1fe66285d3369da85c08d8c69ad9746a._comment b/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_5_1fe66285d3369da85c08d8c69ad9746a._comment
new file mode 100644
index 0000000000..94e6f887a3
--- /dev/null
+++ b/doc/forum/How_do_I_set_up_git_annex_with_nextcloud/comment_5_1fe66285d3369da85c08d8c69ad9746a._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Simon"
+ subject="Maybe this is the problem..."
+ date="2019-10-28T16:13:18Z"
+ content="""
+When I look at the .git/config on both machines the remotes have a different annex-uuid. I guess those should be the same, right?
+"""]]
diff --git a/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__.mdwn b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__.mdwn
new file mode 100644
index 0000000000..d63af388ff
--- /dev/null
+++ b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__.mdwn
@@ -0,0 +1,13 @@
+I have a local repo on a computer with some folder on the path
+/computer1/annex/
+
+Then I tried to run git annex on my phone and added a remote ssh repo syncing to
+/computer1/annex/mobile/ from my mobile's picture folder.
+
+But the files ending up there are:
+ls /computer1/annex/mobile/
+annex  branches  config  description  HEAD  hooks  info  objects  refs 
+
+I chose "full backup"
+
+Why dont I see my pictures there, even if they are hiding in the metadata ?
diff --git a/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_1_fc914b5998a09943fc8c1917a0e36096._comment b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_1_fc914b5998a09943fc8c1917a0e36096._comment
new file mode 100644
index 0000000000..ac49670b9e
--- /dev/null
+++ b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_1_fc914b5998a09943fc8c1917a0e36096._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Petter_petterson"
+ ip="89.160.15.173"
+ subject="addition"
+ date="2014-09-13T07:54:58Z"
+ content="""
+I understand that the copy of the cellphones' photos are stored on the server too, when typing git annex whereis <photo> I see that it exists on the server, but I need to be able to, at will copy out the jpg files for editing and using in other places.
+"""]]
diff --git a/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_2_fd5257eff7f94971557c031a94ac2766._comment b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_2_fd5257eff7f94971557c031a94ac2766._comment
new file mode 100644
index 0000000000..97724fd18a
--- /dev/null
+++ b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_2_fd5257eff7f94971557c031a94ac2766._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 2"
+ date="2014-09-14T18:57:12Z"
+ content="""
+If `/computer1/annex/` was already an annex repository you should have synced the phone to that, not to a new bare repository at `/computer1/annex/mobile/`
+"""]]
diff --git a/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_3_5a11c45f92bae1328a5120945bee1fa0._comment b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_3_5a11c45f92bae1328a5120945bee1fa0._comment
new file mode 100644
index 0000000000..8a9f6cd181
--- /dev/null
+++ b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_3_5a11c45f92bae1328a5120945bee1fa0._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="Petter_petterson"
+ ip="89.160.15.173"
+ subject="comment 3"
+ date="2014-09-16T08:13:59Z"
+ content="""
+Thanks Justin, but that wont work. Even pointing out a normal, non-bare repo and then adding it as a ssh remote will convert it into a bare repo. I confirmed that, and then I read this post:
+
+    http://git-annex.branchable.com/forum/Local_and_remote_in_direct_mode/
+
+that states that
+> The \"Remote server using ssh\" option in the webapp is intended to set up a bare git repository on a server, not a non-bare git repository on a client.\"
+
+I even tried to do 
+    git remote add B ssh://machineB:/~/annex
+but to no avail, the created annex on machine B becomes a bare repo.
+
+The only way to do it for me was to do the following,
+Assume my cellphone is device A, and my desktop is device B:
+
+On machine B:
+
+    cd ~/DCIM
+    git init
+    git annex init \"B\"
+    git annex direct
+    echo '*/5 * * * * * cd ~/DCIM; git annex sync' > crontab
+
+On machine A:
+
+    git clone ssh://user@machineB:/home/user/DCIM
+    git annex sync
+    git annex webapp
+
+now pictures are synced to the computer in direct, non-bare format every 5 minutes. I have spent literally days on this and now I finally nailed it in a crude but working fashion. 
+"""]]
diff --git a/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_4_404a8f9daa86c20a046b4c9f9051dfc0._comment b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_4_404a8f9daa86c20a046b4c9f9051dfc0._comment
new file mode 100644
index 0000000000..cbe73a00bf
--- /dev/null
+++ b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_4_404a8f9daa86c20a046b4c9f9051dfc0._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 4"
+ date="2014-09-18T18:00:42Z"
+ content="""
+I have double-checked, and when I already have an existing, non-bare repository, pointing the webapp at it over ssh keeps it as a non-bare repository. As I would expect.
+
+> I even tried to do git remote add B ssh://machineB:/~/annex but to no avail, the created annex on machine B becomes a bare repo.
+
+I didn't try this because it's such a violation of the way git actually works that I just can't believe it could happen. If it does, you've found the git bug of the year.
+
+But, I think you just got confused about whether the repository existed before, or gave the wrong path to the existing repository which would result in a new, bare repository being created in the location you told it.
+
+If you really think this happens, show a transcript with enough details for me, or the git developers, to reproduce the problem.
+"""]]
diff --git a/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_5_3dcdaef370d0df38e7285f1fa11c6bb3._comment b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_5_3dcdaef370d0df38e7285f1fa11c6bb3._comment
new file mode 100644
index 0000000000..7bcce97062
--- /dev/null
+++ b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_5_3dcdaef370d0df38e7285f1fa11c6bb3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 5"
+ date="2014-09-18T18:05:33Z"
+ content="""
+It occurs to me that another way you could have gotten confused is, if ssh://machineB:/~/annex was eg, created in the first place by running the git-annex webapp on machineB, then it would be a direct mode repo. In this case, yes core.bare=true, but so does annex.direct=true. And that repository will not be a bare repo really; it will contain the same file tree as you have on your mobile.
+"""]]
diff --git a/doc/forum/How_do_you_know_when_something_fails_a_fsck__63__.mdwn b/doc/forum/How_do_you_know_when_something_fails_a_fsck__63__.mdwn
new file mode 100644
index 0000000000..d574956bf1
--- /dev/null
+++ b/doc/forum/How_do_you_know_when_something_fails_a_fsck__63__.mdwn
@@ -0,0 +1,4 @@
+Hi Joey,
+    I was wondering how you know when a file in your repo fails a fsck.  I'm having trouble finding out since I can't change any of the objects (which is great!).  I'd just like to know since I have thousands of files in one of my annexes, and scrolling through my term buffer is unwieldy.  I'd assume it would show up when the fsck was done, or in 'git annex status'...
+
+Thanks!
diff --git a/doc/forum/How_do_you_know_when_something_fails_a_fsck__63__/comment_1_1c14981916dd55376d5e9f95023556cb._comment b/doc/forum/How_do_you_know_when_something_fails_a_fsck__63__/comment_1_1c14981916dd55376d5e9f95023556cb._comment
new file mode 100644
index 0000000000..042a1c46a2
--- /dev/null
+++ b/doc/forum/How_do_you_know_when_something_fails_a_fsck__63__/comment_1_1c14981916dd55376d5e9f95023556cb._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2013-06-10T14:23:25Z"
+ content="""
+    justin@box:/tmp/f$ git init
+    Initialized empty Git repository in /tmp/f/.git/
+    justin@box:/tmp/f$ git-annex init 
+    init  ok
+    (Recording state in git...)
+    justin@box:/tmp/f$ cp /etc/motd .
+    justin@box:/tmp/f$ git-annex add .
+    add motd (checksum...) ok
+    (Recording state in git...)
+    justin@box:/tmp/f$ git-annex fsck
+    fsck motd (checksum...) ok
+    justin@box:/tmp/f$ chmod +w motd 
+    justin@box:/tmp/f$ echo hi >> motd 
+    justin@box:/tmp/f$ git-annex fsck
+    fsck motd 
+      Bad file size (3 B larger); moved to /tmp/f/.git/annex/bad/SHA256-s354--2e724dde1a5dc33bc15580b2aef1ee541ca8047d746fff9bb7917062b871c0bf
+
+      ** No known copies exist of motd
+    failed
+    (Recording state in git...)
+    git-annex: fsck: 1 failed
+
+
+You can also use fsck -q which will only show errors.
+
+"""]]
diff --git a/doc/forum/How_does_addurl_work_with_claimurl_on_external_special_remotes__63__.mdwn b/doc/forum/How_does_addurl_work_with_claimurl_on_external_special_remotes__63__.mdwn
new file mode 100644
index 0000000000..cf8a33c17d
--- /dev/null
+++ b/doc/forum/How_does_addurl_work_with_claimurl_on_external_special_remotes__63__.mdwn
@@ -0,0 +1,72 @@
+I'm struggling to implement claimurl in git-annex-remote-googledrive. I want it to be able to download any https://drive.google.com URL. Is that how it's supposed to work? If so, how can the remote know where to download the key if it was never stored inside the remote but added via a claimed url? [[design/external_special_remote_protocol/#index9h2]] says that the remote can ask with GETURLS, but it doesn't get any reply to this request during addurl. What am I doing wrong?
+Is CLAIMURL only supposed to succeed when the file in question is actually known to the remote?
+
+[[!format sh """
+% git annex addurl "https://drive.google.com/uc?id=redacted&export=download" --debug
+[...]
+[2020-06-12 14:42:31.916627411] git-annex-remote-googledrive[1] --> PREPARE-SUCCESS
+[2020-06-12 14:42:31.916697951] git-annex-remote-googledrive[1] <-- CLAIMURL https://drive.google.com/uc?id=redacted&export=download
+[2020-06-12 14:42:31.916809797] git-annex-remote-googledrive[1] --> CLAIMURL-SUCCESS
+[2020-06-12 14:42:31.916911242] git-annex-remote-googledrive[1] <-- CHECKURL https://drive.google.com/uc?id=redacted&export=download
+[2020-06-12 14:42:31.91706263] git-annex-remote-googledrive[1] --> CHECKURL-MULTI https://drive.google.com/uc?id=redacted&export=download 55 test.txt
+addurl https://drive.google.com/uc?id=redacted&export=download (from g7) (to drive.google.com_uc_id_redacted_export_download/test.txt) [2020-06-12 14:42:31.917348019] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2020-06-12 14:42:31.918468762] process done ExitSuccess
+[2020-06-12 14:42:31.918507982] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2020-06-12 14:42:31.919448022] process done ExitFailure 1
+[2020-06-12 14:42:31.919500166] chat: git ["--git-dir=.git","--work-tree=.","check-ignore","-z","--stdin","--verbose","--non-matching"]
+
+[2020-06-12 14:42:31.92107506] git-annex-remote-googledrive[1] <-- TRANSFER RETRIEVE GPGHMACSHA1--d4acf722d74fd40ef280dacdefe9b6837d1ea124 .git/annex/tmp/GPGHMACSHA1--d4acf722d74fd40ef280dacdefe9b6837d1ea124
+[...]
+[2020-06-12 14:42:33.732491287] git-annex-remote-googledrive[1] --> GETURLS GPGHMACSHA1--d4acf722d74fd40ef280dacdefe9b6837d1ea124 
+[2020-06-12 14:42:33.733764764] git-annex-remote-googledrive[1] <-- VALUE 
+[2020-06-12 14:42:33.734311763] git-annex-remote-googledrive[1] --> TRANSFER-FAILURE RETRIEVE GPGHMACSHA1--d4acf722d74fd40ef280dacdefe9b6837d1ea124
+[...]
+"""]]
+
+I also tried different responses to CHECKURL:
+
+[[!format sh """
+% git annex addurl "https://drive.google.com/uc?id=redacted&export=download" --debug
+[...]
+[2020-06-12 14:50:09.461287507] git-annex-remote-googledrive[1] <-- CLAIMURL https://drive.google.com/uc?id=redacted&export=download
+[2020-06-12 14:50:09.461414232] git-annex-remote-googledrive[1] --> CLAIMURL-SUCCESS
+[2020-06-12 14:50:09.461506989] git-annex-remote-googledrive[1] <-- CHECKURL https://drive.google.com/uc?id=redacted&export=download
+[2020-06-12 14:50:09.461627892] git-annex-remote-googledrive[1] --> CHECKURL-CONTENTS 55 test.txt
+addurl https://drive.google.com/uc?id=redacted&export=download (from g7) (to test.txt) [2020-06-12 14:50:09.4617621] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2020-06-12 14:50:09.462835197] process done ExitSuccess
+[2020-06-12 14:50:09.46287404] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2020-06-12 14:50:09.463772174] process done ExitFailure 1
+[2020-06-12 14:50:09.463833405] chat: git ["--git-dir=.git","--work-tree=.","check-ignore","-z","--stdin","--verbose","--non-matching"]
+
+[2020-06-12 14:50:09.465420918] git-annex-remote-googledrive[1] <-- TRANSFER RETRIEVE GPGHMACSHA1--d4acf722d74fd40ef280dacdefe9b6837d1ea124 .git/annex/tmp/GPGHMACSHA1--d4acf722d74fd40ef280dacdefe9b6837d1ea124
+[...]
+[2020-06-12 14:50:11.459806952] git-annex-remote-googledrive[1] --> GETURLS GPGHMACSHA1--d4acf722d74fd40ef280dacdefe9b6837d1ea124 
+[2020-06-12 14:50:11.461497729] git-annex-remote-googledrive[1] <-- VALUE 
+[2020-06-12 14:50:11.462233639] git-annex-remote-googledrive[1] --> TRANSFER-FAILURE RETRIEVE GPGHMACSHA1--d4acf722d74fd40ef280dacdefe9b6837d1ea124
+
+[...]
+"""]]
+and
+
+[[!format sh """
+% git annex addurl "https://drive.google.com/uc?id=redacted&export=download" --debug
+[...]
+[2020-06-12 14:53:47.976684453] git-annex-remote-googledrive[1] <-- CLAIMURL https://drive.google.com/uc?id=redacted&export=download
+[2020-06-12 14:53:47.976746033] git-annex-remote-googledrive[1] --> CLAIMURL-SUCCESS
+[2020-06-12 14:53:47.976847639] git-annex-remote-googledrive[1] <-- CHECKURL https://drive.google.com/uc?id=redacted&export=download
+[2020-06-12 14:53:47.976940533] git-annex-remote-googledrive[1] --> CHECKURL-CONTENTS UNKNOWN
+addurl https://drive.google.com/uc?id=redacted&export=download (from g7) (to drive.google.com_uc_id_redacted_export_download) [2020-06-12 14:53:47.977207094] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2020-06-12 14:53:47.978263358] process done ExitSuccess
+[2020-06-12 14:53:47.978300058] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2020-06-12 14:53:47.97922157] process done ExitFailure 1
+[2020-06-12 14:53:47.979278608] chat: git ["--git-dir=.git","--work-tree=.","check-ignore","-z","--stdin","--verbose","--non-matching"]
+
+[2020-06-12 14:53:47.980818573] git-annex-remote-googledrive[1] <-- TRANSFER RETRIEVE GPGHMACSHA1--b79f263a317c27c2b617b327e5a84bd4d05474ad .git/annex/tmp/GPGHMACSHA1--b79f263a317c27c2b617b327e5a84bd4d05474ad
+[...]
+[2020-06-12 14:53:50.271896938] git-annex-remote-googledrive[1] --> GETURLS GPGHMACSHA1--b79f263a317c27c2b617b327e5a84bd4d05474ad 
+[2020-06-12 14:53:50.27261623] git-annex-remote-googledrive[1] <-- VALUE 
+[2020-06-12 14:53:50.273016408] git-annex-remote-googledrive[1] --> TRANSFER-SUCCESS RETRIEVE GPGHMACSHA1--b79f263a317c27c2b617b327e5a84bd4d05474ad
+
+[...]
+"""]]
+ - Lykos153
diff --git a/doc/forum/How_does_addurl_work_with_claimurl_on_external_special_remotes__63__/comment_1_3ee29c9b0239af732d3734855417dd5a._comment b/doc/forum/How_does_addurl_work_with_claimurl_on_external_special_remotes__63__/comment_1_3ee29c9b0239af732d3734855417dd5a._comment
new file mode 100644
index 0000000000..b6d9660263
--- /dev/null
+++ b/doc/forum/How_does_addurl_work_with_claimurl_on_external_special_remotes__63__/comment_1_3ee29c9b0239af732d3734855417dd5a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-16T17:56:11Z"
+ content="""
+CLAIMURL needs to be able to determine, by looking at the url alone, if
+this is an url that the remote can claim.
+
+Once a remote responds with CLAIMURL-SUCCESS, git-annex will register the
+url, so GETURLS will work after that point. So in TRANSFER RETRIEVE
+you can use GETURLS to check if there's a recorded url for the key,
+and if the url is a google drive url that you recognise, you can download
+it.
+"""]]
diff --git a/doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__.mdwn b/doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__.mdwn
new file mode 100644
index 0000000000..5bbbd59700
--- /dev/null
+++ b/doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__.mdwn
@@ -0,0 +1,4 @@
+I'm interested in using git-annex on a freebsd system and an OSX system. 
+I have previously had problems with manually rsyncing due to the fact that apparently different types of UTF-8 are used namely:  UTF-8 NFC & UTF-8 NFD so one option is to use  rsync -a --iconv=utf-8-mac,utf-8 localdir/ mynas:remotedir/ or alternatively, I can mount the files on the NAS via a cifs share and rsync to it...
+
+just curios how git-annex deals with this issue or if i will run into issues due to filenames containing special characters?
diff --git a/doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__/comment_1_f4b439f7d9ce20d4b5dc8d728cb2e180._comment b/doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__/comment_1_f4b439f7d9ce20d4b5dc8d728cb2e180._comment
new file mode 100644
index 0000000000..a261a0dc01
--- /dev/null
+++ b/doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__/comment_1_f4b439f7d9ce20d4b5dc8d728cb2e180._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-11-10T19:19:47Z"
+ content="""
+Both git and git-annex both treat filenames as strings of bytes, with no
+particular encoding, to the extent supported by the OS[1]. This may result
+in a checkout of git repository having filenames that don't display well on
+a different system.
+
+[1] Of course any reasonable Unix treats filenames like that too.. but
+Windows only supports unicode filenames.
+"""]]
diff --git a/doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__/comment_2_7393a4b2e94f9d36c3c9ca977a8f67b6._comment b/doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__/comment_2_7393a4b2e94f9d36c3c9ca977a8f67b6._comment
new file mode 100644
index 0000000000..eb12e51536
--- /dev/null
+++ b/doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__/comment_2_7393a4b2e94f9d36c3c9ca977a8f67b6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ subject="comment 2"
+ date="2016-01-05T11:09:07Z"
+ content="""
+Git does have a `core.precomposeUnicode` option for converting NFD to NFC; would that work?
+"""]]
diff --git a/doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__/comment_3_a38e2bbe229cb7e1f4f334bd93d91656._comment b/doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__/comment_3_a38e2bbe229cb7e1f4f334bd93d91656._comment
new file mode 100644
index 0000000000..a303be65ea
--- /dev/null
+++ b/doc/forum/How_does_git-annex_handle_rsyncing_between_different_OSes_with_regards_to_UTF-8__63__/comment_3_a38e2bbe229cb7e1f4f334bd93d91656._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 3"
+ date="2016-01-06T17:00:38Z"
+ content="""
+I can't add much to the conversation, I only raised the issue as I had run into it with rsync as described above.
+"""]]
diff --git a/doc/forum/How_does_git_annex_handle_swp_files.mdwn b/doc/forum/How_does_git_annex_handle_swp_files.mdwn
new file mode 100644
index 0000000000..0c07731202
--- /dev/null
+++ b/doc/forum/How_does_git_annex_handle_swp_files.mdwn
@@ -0,0 +1 @@
+Sometime I edit a file with lets say Emacs in the work directory which is synced with all my other computers. Then there is this .something.swp file. This is put into the queue for sync, but if I close this before it starts the sync I get an error since the file is now gone. Then I get a failed message in the webapp. This is slightly annoying. Is there a way to fix this in some way. I can of course disable the swp use, but this is default for different programs. Is there a way to exclude files? For instance all .swp files from ever getting synced?
diff --git a/doc/forum/How_does_git_annex_handle_swp_files/comment_1_8f0b81139fb66f28f9262e919692ecbd._comment b/doc/forum/How_does_git_annex_handle_swp_files/comment_1_8f0b81139fb66f28f9262e919692ecbd._comment
new file mode 100644
index 0000000000..df946a7a1f
--- /dev/null
+++ b/doc/forum/How_does_git_annex_handle_swp_files/comment_1_8f0b81139fb66f28f9262e919692ecbd._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-11-05T16:14:06Z"
+ content="""
+You can set up a .gitignore file containing `*.swp` or whatever.
+"""]]
diff --git a/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__.mdwn b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__.mdwn
new file mode 100644
index 0000000000..a2ac090ad5
--- /dev/null
+++ b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__.mdwn
@@ -0,0 +1,7 @@
+When starting git-annex assistant with:
+
+    git-annex webapp
+
+an unwanted web browser is opened.
+
+How does one change the web browser with which the web interface is displayed?
diff --git a/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_1_f4402eabda2327da3a0bbc64ed3baf9a._comment b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_1_f4402eabda2327da3a0bbc64ed3baf9a._comment
new file mode 100644
index 0000000000..6369dbd0bb
--- /dev/null
+++ b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_1_f4402eabda2327da3a0bbc64ed3baf9a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.60"
+ subject="comment 1"
+ date="2012-09-17T15:32:07Z"
+ content="""
+The web browser is started by running the `xdg-open` program (or just `open` on Mac OS X).
+
+xdg-open, in turn, runs the desktop environment's kde-open, gvfs-open, exo-open. Which browser these run is configured in the desktop environment's settings. Which is my goal for the web app; it should open the same browser that other applications in the desktop use.
+
+When there's no desktop environment in use, xdg-open falls back to some default browser, or to what's configured by the BROWSER environment variable.
+"""]]
diff --git a/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_2_cdb41f2c7b6bc5bf40d88582dcbf45aa._comment b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_2_cdb41f2c7b6bc5bf40d88582dcbf45aa._comment
new file mode 100644
index 0000000000..ce626fa9f5
--- /dev/null
+++ b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_2_cdb41f2c7b6bc5bf40d88582dcbf45aa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlZvtBCVyJw4O71OPsdwGpVh6iJ1W-xaPc"
+ nickname="Kilian"
+ subject="comment 2"
+ date="2012-10-11T21:56:26Z"
+ content="""
+On my Ubuntu 10.04 machine, ./git-annex-webapp starts Firefox whereas xdg-open starts my configured standard browser, Chrome.
+
+-ke
+"""]]
diff --git a/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_3_ca75e928c245eb23a02b5f40ec69cbb1._comment b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_3_ca75e928c245eb23a02b5f40ec69cbb1._comment
new file mode 100644
index 0000000000..b2b605492c
--- /dev/null
+++ b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_3_ca75e928c245eb23a02b5f40ec69cbb1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.8"
+ subject="comment 3"
+ date="2012-10-11T23:41:36Z"
+ content="""
+Recently the webapp has started honoring git's web.browser setting, so if that's set in ~/.gitconfig, it'll use a different browser than xdg-open does.
+"""]]
diff --git a/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_4_1635f136909711295b9b70d1255e0378._comment b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_4_1635f136909711295b9b70d1255e0378._comment
new file mode 100644
index 0000000000..e6d12ca5d0
--- /dev/null
+++ b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_4_1635f136909711295b9b70d1255e0378._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"
+ nickname="Jim"
+ subject="Doesn't use the configured web browser app..."
+ date="2012-12-04T23:10:43Z"
+ content="""
+On my system, `xdg-open http://google.com/` opens firefox as desired, but `xdg-open file:///tmp/foo.html` tries to load **wine**!
+I'm using xfce, and it seems like exo-open is noticing the `file://` URL, finding the mime type, and looking it up in `~/.local/share/applications/wine-extension-html.desktop`, which was (annoyingly) created by wine.  Deleting those files fixes it.
+
+Not sure how you'd make this better.  Maybe give xdg-open a URL like `http://localhost:54896/?authfile=...` that redirects to `file:///tmp/webapp12345.html` that redirects to `http://localhost:54896/?auth=...` ?
+"""]]
diff --git a/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_5_ee0cbe9498c518de98480a2ad229f685._comment b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_5_ee0cbe9498c518de98480a2ad229f685._comment
new file mode 100644
index 0000000000..8dc9d74ecb
--- /dev/null
+++ b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_5_ee0cbe9498c518de98480a2ad229f685._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.72"
+ subject="comment 5"
+ date="2012-12-05T01:21:03Z"
+ content="""
+@Jim, that would be a good technique.. except many browsers prohibit redirecting to file:// urls.
+
+
+"""]]
diff --git a/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_6_799b9d9d3ffbc2c14eca8d442e2aff8c._comment b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_6_799b9d9d3ffbc2c14eca8d442e2aff8c._comment
new file mode 100644
index 0000000000..767426fefa
--- /dev/null
+++ b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_6_799b9d9d3ffbc2c14eca8d442e2aff8c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="comment 6"
+ date="2013-11-15T13:43:06Z"
+ content="""
+Since git web--browse defaults to firefox on my system (Ubuntu/XMonad), I did this on Ubuntu to get the system default browser.
+
+  git config --global web.browser xdg-open
+
+"""]]
diff --git a/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_7_71ff45948487e9ac8de809a5ccc3d874._comment b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_7_71ff45948487e9ac8de809a5ccc3d874._comment
new file mode 100644
index 0000000000..115d402ad5
--- /dev/null
+++ b/doc/forum/How_does_one_change_git-annex_assistant__39__s_web_browser__63__/comment_7_71ff45948487e9ac8de809a5ccc3d874._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="rupi"
+ ip="80.110.152.13"
+ subject="xdg-open"
+ date="2014-02-28T17:48:23Z"
+ content="""
+Since I discovered the same behavior mentioned above (git annex webapp
+tries to use 'winebrowser'). There is an easy way to work with the difference
+between http
+url and html files: enter preferences for both:
+
+In ~/.local/share/applications/mimeapps.list:
+
+		[Added Associations]
+		..
+		x-scheme-handler/http=iceweasel.desktop;
+		x-scheme-handler/https=iceweasel.desktop;
+		text/html=icewesel.desktop;
+
+
+		[Default Applications]
+		x-scheme-handler/http=iceweasel.desktop
+		x-scheme-handler/https=iceweasel.desktop
+		text/html=iceweasel.desktop
+
+
+Your preferred browser might be a different one off course. And I agree that this has to be the most logical place to store that information ever.. 
+
+"""]]
diff --git a/doc/forum/How_does_one_change_the_number_of_simultaneous_uploads.mdwn b/doc/forum/How_does_one_change_the_number_of_simultaneous_uploads.mdwn
new file mode 100644
index 0000000000..8de9cc7692
--- /dev/null
+++ b/doc/forum/How_does_one_change_the_number_of_simultaneous_uploads.mdwn
@@ -0,0 +1,3 @@
+I want to upload and download more than one file at a time to and from the various remotes.
+
+How do I do that?
diff --git a/doc/forum/How_does_one_change_the_number_of_simultaneous_uploads/comment_1_d5559994ee45a5c185a55c9a4d824aa4._comment b/doc/forum/How_does_one_change_the_number_of_simultaneous_uploads/comment_1_d5559994ee45a5c185a55c9a4d824aa4._comment
new file mode 100644
index 0000000000..41999cf0e9
--- /dev/null
+++ b/doc/forum/How_does_one_change_the_number_of_simultaneous_uploads/comment_1_d5559994ee45a5c185a55c9a4d824aa4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="71.80.94.56"
+ subject="comment 1"
+ date="2014-02-07T19:12:10Z"
+ content="""
+This is not currently supported. See [[todo/Slow_transfer_for_a_lot_of_small_files.]]
+
+ You can click on the button next to individual files in the transfer queue to force concurrent transfers.
+
+
+"""]]
diff --git a/doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__.mdwn b/doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__.mdwn
new file mode 100644
index 0000000000..f88f683469
--- /dev/null
+++ b/doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__.mdwn
@@ -0,0 +1,14 @@
+At one point, in two repositories, I added the `largefiles` options to my `.gitattributes` file:
+```
+* annex.backend=BLAKE2B512E annex.numcopies=2 annex.largefiles=largerthan=32kb
+```
+
+There were already Org-mode files in those repositories, kept under git. I used `git annex init` on those repositories long after those files had been under version control.
+
+Since some these files were larger than 32k, it appears that after editing them, git-annex decided to alter the files so that the content in Git HEAD for each file is a pathname into the `objects` directory. That is, when I use `ls -l` the file is never a symlink, and yet if I use `git show HEAD:todo.org`, I see a pathname. Using `git annex unlock` on the file does nothing.
+
+I decided to remove the `annex.largefiles` setting, since I don't want this behavior to be "automatic" anymore. So, in one of the two repositories, I ran `git annex unannex todo.org`, and then `git add`, and now I have a regular file back under version control again.
+
+In the other repository, however, the file goes back to being a file path in the Git tree when I use "git add". Nothing that I do will add the file contents to Git rather than to the Annex, in this strange mode where it's never a symlink on disk, but it's definitely an Annex object file path in the Git tree.
+
+How do I tell Annex to stop managing this particular file?
diff --git a/doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__/comment_1_68ed73d8898bf2ce0a14e0e5909cc64b._comment b/doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__/comment_1_68ed73d8898bf2ce0a14e0e5909cc64b._comment
new file mode 100644
index 0000000000..5d852eea0b
--- /dev/null
+++ b/doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__/comment_1_68ed73d8898bf2ce0a14e0e5909cc64b._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="jwiegley"
+ avatar="http://cdn.libravatar.org/avatar/910fdec093deffebb92d7db019b5996a"
+ subject="An example of what I see"
+ date="2023-03-16T12:24:45Z"
+ content="""
+Here's an example of what I see:
+```
+Hermes ~/kadena/docs $ w
+## main
+?? archive/
+Hermes ~/kadena/docs $ git add archive
+Hermes ~/kadena/docs $ git diff HEAD
+diff --git c/archive/archive.org w/archive/archive.org
+new file mode 100644
+index 0000000..6cd5281
+--- /dev/null
++++ w/archive/archive.org
+@@ -0,0 +1 @@
++/annex/objects/BLAKE2B512E-s239446--66c363a36b5d1919344b41d947d6ee9c3db879e547fb7cfc5e94d09c16bdec>
+```
+
+Note that I discovered that I had both a `kadena.org` and an `archive/kadena.org`. Once I renamed the latter to `archive/archive.org`, then I was able to `git add` the first file without it being placed in the Annex, but I still cannot add `archive/archive.org` without it being put into the Annex as above.
+"""]]
diff --git a/doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__/comment_2_176a92a6ce5d8f356dafc29021242b2d._comment b/doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__/comment_2_176a92a6ce5d8f356dafc29021242b2d._comment
new file mode 100644
index 0000000000..373e52d7e5
--- /dev/null
+++ b/doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__/comment_2_176a92a6ce5d8f356dafc29021242b2d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jwiegley"
+ avatar="http://cdn.libravatar.org/avatar/910fdec093deffebb92d7db019b5996a"
+ subject="comment 2"
+ date="2023-03-16T12:52:53Z"
+ content="""
+Never mind, I found the answer on https://git-annex.branchable.com/git-annex-smudge/
+"""]]
diff --git a/doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__/comment_3_0cdd9683709d55bb7340fb41fef265fa._comment b/doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__/comment_3_0cdd9683709d55bb7340fb41fef265fa._comment
new file mode 100644
index 0000000000..793aba7921
--- /dev/null
+++ b/doc/forum/How_stop_annex_from_annexing_a_file_with___34__git_add__34__/comment_3_0cdd9683709d55bb7340fb41fef265fa._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-03-21T17:57:11Z"
+ content="""
+@jwiegley if you're still around, I'm curious what the answer was.
+
+I mean, I know these are unlocked annexed files.
+But I'm not clear about what was going on here, which seems like it might
+be some kind of bug.
+"""]]
diff --git a/doc/forum/How_to_add_dotfiles_in_direct_mode__63__.mdwn b/doc/forum/How_to_add_dotfiles_in_direct_mode__63__.mdwn
new file mode 100644
index 0000000000..bd79dcdbd1
--- /dev/null
+++ b/doc/forum/How_to_add_dotfiles_in_direct_mode__63__.mdwn
@@ -0,0 +1,6 @@
+I have my Darktable photo library in git-annex and I need to use
+
+- .gitignore to ignore some files like *.lock
+- .gitattributes to make the sidecar .xmp files to be non-annexed normal files (faster and saves the editing history)
+
+What is the correct way to add those dotfiles to git in direct mode? Do I need to switch the repository to indirect mode and then back to direct mode? (I rather not do that very often since the repo has tens of thousands of files.)
diff --git a/doc/forum/How_to_add_dotfiles_in_direct_mode__63__/comment_1_d62d4b9ae5f1ec825fc58090689f7571._comment b/doc/forum/How_to_add_dotfiles_in_direct_mode__63__/comment_1_d62d4b9ae5f1ec825fc58090689f7571._comment
new file mode 100644
index 0000000000..b38fba2282
--- /dev/null
+++ b/doc/forum/How_to_add_dotfiles_in_direct_mode__63__/comment_1_d62d4b9ae5f1ec825fc58090689f7571._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-17T15:52:29Z"
+ content="""
+The best way is to make your .gitattributes file configure annex.largefiles
+to not match the files or file extensions that you want to not be annexed.
+(Including the .gitattributes file itself.)
+
+There are also ways to temporarily override annex.largefiles if you want to
+add a single file to git. Although this can be messy to need to remember if
+you later modify that file and are adding it again. Configuring
+annex.largefiles is better.
+
+See <https://git-annex.branchable.com/tips/largefiles>
+"""]]
diff --git a/doc/forum/How_to_add_dotfiles_in_direct_mode__63__/comment_2_c7269cde1db02069149268b6c6a50786._comment b/doc/forum/How_to_add_dotfiles_in_direct_mode__63__/comment_2_c7269cde1db02069149268b6c6a50786._comment
new file mode 100644
index 0000000000..9c14759d4e
--- /dev/null
+++ b/doc/forum/How_to_add_dotfiles_in_direct_mode__63__/comment_2_c7269cde1db02069149268b6c6a50786._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="pitsa@5f5d24a1fb7ba0d050ae7cf95b4c3032002e8e38"
+ nickname="pitsa"
+ avatar="http://cdn.libravatar.org/avatar/d1de087e3bdaf7c2288b89b8ea56e6a5"
+ subject="Thanks"
+ date="2017-08-17T16:35:33Z"
+ content="""
+Ok, this seems to work:
+
+    git annex add -c annex.largefiles='not include=*' .gitattributes .gitignore
+    git annex sync
+
+"""]]
diff --git a/doc/forum/How_to_allow_clones_to_get_files_via_URL__63__.mdwn b/doc/forum/How_to_allow_clones_to_get_files_via_URL__63__.mdwn
new file mode 100644
index 0000000000..f3978d8123
--- /dev/null
+++ b/doc/forum/How_to_allow_clones_to_get_files_via_URL__63__.mdwn
@@ -0,0 +1,52 @@
+I'm working with Datalad, but I suspect that my problems stem from not fully understanding how git annex works.
+
+I’ve been trying a set up a dataset that primarily lives on a web server, but needs to be clone-able by other people. The annex files are visible and downloadable from the server’s website. In particular, the files I’m concerned about here are in a subdataset.
+
+I used `datalad addurls` to add the URL of each file on the server to each file in the annex. When I run `git annex whereis filename`, it shows up that it lives on the server in the server’s local copy of the dataset, and that it lives on the web, with a correct URL. In fact, if I click on that URL and open it in a browser, it downloads my file.
+
+The dataset lives on Github, but the annex does not. When I make a clone of the superdataset on my personal computer, I get messages like
+
+```
+[INFO   ] Unable to parse git config from origin                                                                                       
+[INFO   ] Remote origin does not have git-annex installed; setting annex-ignore                                                        
+|   This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote origin 
+install(ok): /home/erin/Documents/DHA/carcas (dataset)
+```
+
+Then when I'm in the dataset `carcas-models` that has the annex and I run `datalad get models
+/Alpaca\ 3rd\ Carpal\ L.glb`, I get this error message: 
+
+```
+get(error): models/Alpaca 3rd Carpal L.glb (file) [no known url                                
+no known url
+no known url]
+```
+
+I suspect my problem is with how I set things up with git annex, because when I try `git annex get models/Alpaca\ 3rd\ Carpal\ L.glb`, I get the error:
+
+```
+get models/Alpaca 3rd Carpal L.glb (from web...) 
+  no known url
+
+  Unable to access these remotes: web
+
+  Maybe add some of these git remotes (git remote add ...):
+        095e299d-037e-4172-87e0-bbd7183a6613 -- CARCAS models on the 3dviewers server
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+get: 1 failed
+```
+
+I'm confused on how to debug this because when I run git annex whereis models/Alpaca\ 3rd\ Carpal\ L.glb, everything looks correct:
+
+```
+whereis models/Alpaca 3rd Carpal L.glb (2 copies) 
+        00000000-0000-0000-0000-000000000001 -- web
+        095e299d-037e-4172-87e0-bbd7183a6613 -- CARCAS models on the 3dviewers server
+
+  web: https://3dviewer.sites.carleton.edu/carcas/carcas-models/models/Alpaca%203rd%20Carpal%20L.glb
+ok
+```
+
+What's the correct way to set up this use case? I don't think that I want the server to be a special remote, because the hidden files like .gitattributes aren't visible. I want to be able to put more files on the server, add their URLS based on where they are on the server, and push to github so that other people can get these files if they want. 
diff --git a/doc/forum/How_to_cancel_an_add__63__.mdwn b/doc/forum/How_to_cancel_an_add__63__.mdwn
new file mode 100644
index 0000000000..e0b0f1c8fe
--- /dev/null
+++ b/doc/forum/How_to_cancel_an_add__63__.mdwn
@@ -0,0 +1,5 @@
+What is the safest way to cancel a `git annex add` before the first commit?
+
+Say I first added a directory with a lot of small files to the annex and then (while watching the endless list of checksum operations) decide I should actually put them in a tar file and annex that instead.
+
+The problem seems to be that `git annex add` immediately replaces the files with symlinks instead of waiting for a commit, so I can't just `git reset largedir/; tar cvfz largedir.tgz largedir/; git annex add largedir.tgz`.
diff --git a/doc/forum/How_to_cancel_an_add__63__/comment_1_f768ce5dc7c76f96ee6eb352f167be44._comment b/doc/forum/How_to_cancel_an_add__63__/comment_1_f768ce5dc7c76f96ee6eb352f167be44._comment
new file mode 100644
index 0000000000..cef9384691
--- /dev/null
+++ b/doc/forum/How_to_cancel_an_add__63__/comment_1_f768ce5dc7c76f96ee6eb352f167be44._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-03T00:50:48Z"
+ content="""
+Run `git annex unannex` on the files.
+"""]]
diff --git a/doc/forum/How_to_change_the_name_of_a_repo_on_S3__63__.mdwn b/doc/forum/How_to_change_the_name_of_a_repo_on_S3__63__.mdwn
new file mode 100644
index 0000000000..70e3eada30
--- /dev/null
+++ b/doc/forum/How_to_change_the_name_of_a_repo_on_S3__63__.mdwn
@@ -0,0 +1,2 @@
+git-annex created a gitannexxxxxxxxxxxxxxxxxxxxx folder on S3 and I guess I'm a bit OCD but I'd like to rename it to git-annex. 
+Of course I can rename it in my S3 console but where does git-annex store that name so I can also change it on my local install of git-annex.
diff --git a/doc/forum/How_to_change_the_name_of_a_repo_on_S3__63__/comment_1_be74d63e1951f515948d232e096b4862._comment b/doc/forum/How_to_change_the_name_of_a_repo_on_S3__63__/comment_1_be74d63e1951f515948d232e096b4862._comment
new file mode 100644
index 0000000000..3aecea0517
--- /dev/null
+++ b/doc/forum/How_to_change_the_name_of_a_repo_on_S3__63__/comment_1_be74d63e1951f515948d232e096b4862._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-05-16T16:28:40Z"
+ content="""
+If you look at the [[S3_documentation|special_remotes/S3]] you will see a `bucket` setting that does what you want. You can use `git annex enableremote` to change it.
+"""]]
diff --git a/doc/forum/How_to_change_the_name_of_a_repo_on_S3__63__/comment_2_d54a7163cfe9a94b7ba337860958e5c5._comment b/doc/forum/How_to_change_the_name_of_a_repo_on_S3__63__/comment_2_d54a7163cfe9a94b7ba337860958e5c5._comment
new file mode 100644
index 0000000000..d563d061ac
--- /dev/null
+++ b/doc/forum/How_to_change_the_name_of_a_repo_on_S3__63__/comment_2_d54a7163cfe9a94b7ba337860958e5c5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="comment 2"
+ date="2014-05-16T18:08:11Z"
+ content="""
+Thanks but I realized there's no way to rename an S3 bucket so giving up on this idea...
+"""]]
diff --git a/doc/forum/How_to_completely_remove_tracking_of_a_deleted_file_in_direct_mode.mdwn b/doc/forum/How_to_completely_remove_tracking_of_a_deleted_file_in_direct_mode.mdwn
new file mode 100644
index 0000000000..82fc666a08
--- /dev/null
+++ b/doc/forum/How_to_completely_remove_tracking_of_a_deleted_file_in_direct_mode.mdwn
@@ -0,0 +1,7 @@
+I am in direct mode (managing music) and have no other repositories than the one I'm in.  I would like to delete a file and have git no longer track it at all.
+
+So far I've manually deleted the file and run "git annex add .", but when I run "git annex status" the file is still marked as deleted.  I would like to receive no message whatsoever.
+
+I tried "git annex drop path" , "git annex unannex path", and everything else I can think of but nothing will get git annex to forget the file.
+
+I'm sure this is easy, but how do you remove a deleted file in direct mode?
diff --git a/doc/forum/How_to_completely_remove_tracking_of_a_deleted_file_in_direct_mode/comment_1_c6bd2ef90516dde928ff18ded36df625._comment b/doc/forum/How_to_completely_remove_tracking_of_a_deleted_file_in_direct_mode/comment_1_c6bd2ef90516dde928ff18ded36df625._comment
new file mode 100644
index 0000000000..9b5881ad6b
--- /dev/null
+++ b/doc/forum/How_to_completely_remove_tracking_of_a_deleted_file_in_direct_mode/comment_1_c6bd2ef90516dde928ff18ded36df625._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-02T16:57:46Z"
+ content="""
+git annex sync
+"""]]
diff --git a/doc/forum/How_to_copy__47__duplicate_all_data_from_rsync__47__ssh_backend_to_other_backend__63__.mdwn b/doc/forum/How_to_copy__47__duplicate_all_data_from_rsync__47__ssh_backend_to_other_backend__63__.mdwn
new file mode 100644
index 0000000000..0e72582d32
--- /dev/null
+++ b/doc/forum/How_to_copy__47__duplicate_all_data_from_rsync__47__ssh_backend_to_other_backend__63__.mdwn
@@ -0,0 +1,14 @@
+Hello,
+
+I want to be safe and have two copies of my files on two different backend. Currently I only have a SSH backend, that stores all my data. I have full(root) access to that machine/backend. On my laptop I have only a few bytes of data, because all is moved/copied to that SSH backend. Now, I want to duplicate the data on the SSH backend to a Google Drive account (or any other). How could I do that (without downloading all data from the SSH backend)??? Encryption is not a must.
+
+I looked into the annex/objects folder on the SSH backend, but there are 3 char length directories compared to what I see on a test Google Drive backend, where only 2 char length directory names are.
+
+Example SSH backend: [git-annex root]/annex/objects/c10/90a/SHA256E-s445227--14c3f85d6dd3464f116f6a5bbd411012781d36794549d136b18d1914c4158820.jpg/SHA256E-s445227--14c3f85d6dd3464f116f6a5bbd411012781d36794549d136b18d1914c4158820.jpg
+
+Example Google Drive: [Google Drive root]/annex/W7/xQ/SHA256E-s913904--29f9800b0dd34d4200c4e9ee152b79c3556a9a473848720be7cf83d20eff65a4.JPG
+
+Is there a way to convert these directory names and do a simpe copy??? 
+
+Thank you,
+Bence
diff --git a/doc/forum/How_to_copy__47__duplicate_all_data_from_rsync__47__ssh_backend_to_other_backend__63__/comment_1_7973928b1aa9e0fcfeb6bf80885441f5._comment b/doc/forum/How_to_copy__47__duplicate_all_data_from_rsync__47__ssh_backend_to_other_backend__63__/comment_1_7973928b1aa9e0fcfeb6bf80885441f5._comment
new file mode 100644
index 0000000000..3c7d072588
--- /dev/null
+++ b/doc/forum/How_to_copy__47__duplicate_all_data_from_rsync__47__ssh_backend_to_other_backend__63__/comment_1_7973928b1aa9e0fcfeb6bf80885441f5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.251.174"
+ subject="comment 1"
+ date="2013-09-07T17:11:03Z"
+ content="""
+Just run `git annex copy --all --to remote` 
+
+(Needs git-annex 4.20130709 or newer.)
+"""]]
diff --git a/doc/forum/How_to_deal_with_renamed_files_in_direct_mode__63__.mdwn b/doc/forum/How_to_deal_with_renamed_files_in_direct_mode__63__.mdwn
new file mode 100644
index 0000000000..576d598ddb
--- /dev/null
+++ b/doc/forum/How_to_deal_with_renamed_files_in_direct_mode__63__.mdwn
@@ -0,0 +1,3 @@
+I use git annex in direct mode and I have renamed a file. What should I do to make git annex understand that the file has just been renamed and not deleted/added?
+
+The file I renamed is quite big and I would like to avoid having to copy it again to the remotes and I would also like to avoid having to redownload it again in all the repositories.
diff --git a/doc/forum/How_to_deal_with_renamed_files_in_direct_mode__63__/comment_1_fe38fedbbc9e4a9e13bf19950e63c7ac._comment b/doc/forum/How_to_deal_with_renamed_files_in_direct_mode__63__/comment_1_fe38fedbbc9e4a9e13bf19950e63c7ac._comment
new file mode 100644
index 0000000000..6f452acb8c
--- /dev/null
+++ b/doc/forum/How_to_deal_with_renamed_files_in_direct_mode__63__/comment_1_fe38fedbbc9e4a9e13bf19950e63c7ac._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.254.222"
+ subject="comment 1"
+ date="2013-07-07T17:14:18Z"
+ content="""
+You don't have to do anything special, git-annex automatically detects when a file has been renamed.
+
+Just `git annex` add the new file, and commit and sync like usual.
+"""]]
diff --git a/doc/forum/How_to_deal_with_spotlight_and_macOS.mdwn b/doc/forum/How_to_deal_with_spotlight_and_macOS.mdwn
new file mode 100644
index 0000000000..9dbdefaa9d
--- /dev/null
+++ b/doc/forum/How_to_deal_with_spotlight_and_macOS.mdwn
@@ -0,0 +1,21 @@
+I have been using git annex for a while. I use it completely manually (i.e."git annex add .; git annex sync; git annex copy . --to=desktop") as a DIY Dropbox replacement. 
+
+I have some issues inherent with git annex but they will be reserved to another post.
+
+What I want to ask about now is how to integrate my git annex workflow with macOS?
+
+Specifically:
+
+1) If I search for something in spotlight, it apparently does not search the 'names' of symlinks, and so it is impossible to have spotlight index the git annex archive?
+2) Opening files in git annex, in particular, PDF files with Preview.app, the names of the files are the targets of the symlinks, not their names, so that you end up seeing "SHA256E-s146178--a7e80c95ffe943ceca774d7931651ab4c16574c6f4059ade342a3cdbda3a5ef9.pdf" as the title of the Preview.app window of the PDF you're looking at. This is especially heinous when you have many many open files and you're trying to find one of them and the titles just give you zero information.
+3) Trying to attach some of these files into mail attachments, again, the filename the recipient gets is "SHA256E-s146178--a7e80c95ffe943ceca774d7931651ab4c16574c6f4059ade342a3cdbda3a5ef9.pdf" which is quite useless for them, or even harmful because it can be very confusing if there are 10 attachments from git annex and they all have these crazy names.
+
+Is there anything that can be done about this? This seems to be a conflict between macOS insisting on referring to the target of symlinks as the true names for the files whereas git annex is happy with the names of the symlinks.
+
+I have used several things to work around this, e.g., instead of spotlight I can run 
+find . -iname "*something*" 
+in the terminal to search my archive (I have one archive with all my files).
+
+However it would be nice to integrate this into spotlight.
+
+The bigger problem are the file names. Is it possible to fix this by using hard links instead? Or somehow fool macOS into reading the names of the symlinks instead of the names of the targets of the symlinks?
diff --git a/doc/forum/How_to_deal_with_spotlight_and_macOS/comment_1_3d76fbb8f13bd66d729819a4d037ab4f._comment b/doc/forum/How_to_deal_with_spotlight_and_macOS/comment_1_3d76fbb8f13bd66d729819a4d037ab4f._comment
new file mode 100644
index 0000000000..f0105608f5
--- /dev/null
+++ b/doc/forum/How_to_deal_with_spotlight_and_macOS/comment_1_3d76fbb8f13bd66d729819a4d037ab4f._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="spotlight and macOS"
+ date="2020-03-29T15:27:40Z"
+ content="""
+I also struggle with these issues on macOS.
+
+One workaround would be to always use [unlocked files](https://git-annex.branchable.com/tips/unlocked_files/), 
+
+    git config annex.addunlocked true
+
+The main disadvantage here is that you use double the disk space for every file. After switching to unlocked files you could then also switch to `thin` mode:
+
+    git config annex.thin true
+    git annex fix
+
+Which would only keep 1 copy of every file (using hardlinks), so you are back down to a normal amount of disk space, but you give up some of the protections of git-annex since you could easily delete the only copy of your files.
+
+I have verified that using unlocked files and using unlocked-thin both fix file names in Preview and mail attachments. I'm not sure if both these methods allow files to be indexed by Spotlight.
+
+I have also been hoping to integrate many of these features into [git-annex-turtle](https://github.com/andrewringler/git-annex-turtle) using the [Search and Spotlight](https://developer.apple.com/design/human-interface-guidelines/macos/system-capabilities/search-and-spotlight/) developer APIs. Namely [Core Spotlight](https://developer.apple.com/documentation/corespotlight) could be used to index all `git-annex` locked/unlocked/present/not-present files and [Quick Look](https://developer.apple.com/design/human-interface-guidelines/macos/system-capabilities/quick-look/) APIs could be used to allow previewing of not present files using cached thumbnails.
+
+—Andrew
+
+"""]]
diff --git a/doc/forum/How_to_debug_failing_sync.mdwn b/doc/forum/How_to_debug_failing_sync.mdwn
new file mode 100644
index 0000000000..ad18aeb55c
--- /dev/null
+++ b/doc/forum/How_to_debug_failing_sync.mdwn
@@ -0,0 +1,5 @@
+I've got a remote I setup while connected to my home network that is no longer syncing when I'm on the same network. I'm not sure how to debug the problem. Any tips?
+
+I will say that when I edit the repository in the assistant, the url it gives for the "git repository location at" field looks incorrect. It's got an extra "git-annex-" prepended to the hostname. I'm not sure how to alter that.
+
+I'm using version 5.20140517~bpo70+1, from the wheezy backports.
diff --git a/doc/forum/How_to_debug_failing_sync/comment_1_a597b868182e55e5f39394f154740534._comment b/doc/forum/How_to_debug_failing_sync/comment_1_a597b868182e55e5f39394f154740534._comment
new file mode 100644
index 0000000000..2d89ecda37
--- /dev/null
+++ b/doc/forum/How_to_debug_failing_sync/comment_1_a597b868182e55e5f39394f154740534._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 1"
+ date="2014-05-29T18:15:12Z"
+ content="""
+That extra git-annex- prefix is used in ~/.ssh/config to set up the ssh keys for the repository. So it's normal.
+
+I suggest that you try running git-annex sync at the command line and paste the output so we can see how it fails.
+"""]]
diff --git a/doc/forum/How_to_debug_failing_sync/comment_2_db0a5652d76e4e568a4d7808195bc59c._comment b/doc/forum/How_to_debug_failing_sync/comment_2_db0a5652d76e4e568a4d7808195bc59c._comment
new file mode 100644
index 0000000000..bf707ecb14
--- /dev/null
+++ b/doc/forum/How_to_debug_failing_sync/comment_2_db0a5652d76e4e568a4d7808195bc59c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="go8ose"
+ ip="59.167.191.61"
+ subject="comment 2"
+ date="2014-05-30T10:28:38Z"
+ content="""
+I was shown a password prompt for the remote. Then I realised I was controlling my ~/.ssh/authorized_keys file with puppet, which would have removed the public key that annex would have added to that file. I'm sure that once I fix that up, I'll get it working again.
+
+Thanks for the CLI suggestion.
+"""]]
diff --git a/doc/forum/How_to_define_a_balanced_prefered_content.mdwn b/doc/forum/How_to_define_a_balanced_prefered_content.mdwn
new file mode 100644
index 0000000000..1bfbe848b9
--- /dev/null
+++ b/doc/forum/How_to_define_a_balanced_prefered_content.mdwn
@@ -0,0 +1,5 @@
+I have 6 drives attached to my box and I am trying to split them in to 2 groups I would like to have 2 balanced groups [1] so each file lands on two of these disks. So assuming i have disks A B C D E F, I want to create two balanced groups A B C and D E F. But I can not figure out how to defined rules using  balanced_amoung(group) expression in vicfg. The only place it allows me to use the expression is the group section but how do i define a group that uses a balanced group.
+
+
+
+[1] https://git-annex.branchable.com/design/balanced_preferred_content/
diff --git a/doc/forum/How_to_define_a_balanced_prefered_content/comment_1_d4c94791a5fc7d2e618a7e11bc5db569._comment b/doc/forum/How_to_define_a_balanced_prefered_content/comment_1_d4c94791a5fc7d2e618a7e11bc5db569._comment
new file mode 100644
index 0000000000..b53c615dad
--- /dev/null
+++ b/doc/forum/How_to_define_a_balanced_prefered_content/comment_1_d4c94791a5fc7d2e618a7e11bc5db569._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
+ nickname="Carl"
+ subject="Only a design suggestion"
+ date="2015-09-07T17:24:41Z"
+ content="""
+I am pretty sure that balanced preferred content expressions are not implemented, but only a suggested model on how it could be done.
+"""]]
diff --git a/doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__.mdwn b/doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__.mdwn
new file mode 100644
index 0000000000..7b8e1a0bad
--- /dev/null
+++ b/doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__.mdwn
@@ -0,0 +1,7 @@
+I'm using git-annex to manage my files. Some of my remotes are available using 2 or 3 methods, for example ssh and nfs, but the nfs access is only possible on my local network, of course. Then, git-annex chooses the fastest method to sync or get the files (nfs, if available, ssh instead, using scores to choose). For now, I define a remote per repository and per access method (example: server-by-ssh, server-by-nfs), but that's not a really git-annex way to do the job, as it is not compliant with the numcopies option, which ckecks that the files in the annex are kept with enough replications (with my current method, many remotes are in fact the same folders on a hard drive).
+
+Then, my question applies to both git and git-annex, since the remotes are added in git, not git-annex: I wonder if it is possible to define alternative url for a given remote.
+
+I have tried to use the git remote set --url --add command, but it doesn't really work as I would expect. Indeed, if the nfs url is not reachable, git hangs up and waits.
+
+Any idea?
diff --git a/doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__/comment_1_52918b5ec25e55837215439fe1bb1a14._comment b/doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__/comment_1_52918b5ec25e55837215439fe1bb1a14._comment
new file mode 100644
index 0000000000..5bafa57d95
--- /dev/null
+++ b/doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__/comment_1_52918b5ec25e55837215439fe1bb1a14._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2012-08-21T12:42:16Z"
+ content="""
+I don't think having multiple remotes for the same repository confuses git-annex since it uses the UUID not the url to identify them.
+"""]]
diff --git a/doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__/comment_2_3a1567c9f484b5e12e5560cdcc2cfddd._comment b/doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__/comment_2_3a1567c9f484b5e12e5560cdcc2cfddd._comment
new file mode 100644
index 0000000000..859804678c
--- /dev/null
+++ b/doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__/comment_2_3a1567c9f484b5e12e5560cdcc2cfddd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.29"
+ subject="Justin is right"
+ date="2012-08-21T15:57:46Z"
+ content="""
+git-annex doesn't care how many git remotes you have pointing to a given repo, that repo's uuid still only counts as one copy.
+"""]]
diff --git a/doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__/comment_3_48c3a80c14a85f27d742482b2ccbe628._comment b/doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__/comment_3_48c3a80c14a85f27d742482b2ccbe628._comment
new file mode 100644
index 0000000000..7a0054c493
--- /dev/null
+++ b/doc/forum/How_to_define_an_alternative_remote_url_for_a_git_remote_repository__63__/comment_3_48c3a80c14a85f27d742482b2ccbe628._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/speredenn#aaf38"
+ nickname="Jean-Baptiste Carré"
+ subject="comment 3"
+ date="2012-08-21T18:15:48Z"
+ content="""
+You're totally right: The UUIDs are the same. So it shouldn't matter if there are many repositories pointing to the same folder, as you state it. Thanks a lot!
+"""]]
diff --git a/doc/forum/How_to_delete_a_file_in_direct_mode__63__.mdwn b/doc/forum/How_to_delete_a_file_in_direct_mode__63__.mdwn
new file mode 100644
index 0000000000..7e95224f9e
--- /dev/null
+++ b/doc/forum/How_to_delete_a_file_in_direct_mode__63__.mdwn
@@ -0,0 +1,31 @@
+My use case is that I'm organising my media in a staging area called **uploadme/**.
+
+At this staging area, I add all the media into git-annex and then I go to work pruning, editing & [adding metadata](https://github.com/muennich/sxiv/blob/master/exec/key-handler#L29).
+
+# Pruning
+
+If I find an image I don't like I move it to `/tmp`.
+
+I expected to maybe type `git status` to see the missing file and later confirm that I don't want it. But when I type `git status` I get:
+
+    X1C3:~/media/uploadme$ git status
+    fatal: This operation must be run in a work tree
+
+What should I be doing?
+
+
+
+My use case is that I'm organising my media in a staging area called **uploadme/**.
+
+At this staging area, I add all the media into git-annex and then I go to work pruning, editing & [adding metadata](https://github.com/muennich/sxiv/blob/master/exec/key-handler#L29).
+
+# Pruning
+
+If I find an image I don't like I move it to `/tmp`.
+
+I expected to maybe type `git status` to see the missing file and later confirm that I don't want it. But when I type `git status` I get:
+
+    X1C3:~/media/uploadme$ git status
+    fatal: This operation must be run in a work tree
+
+What should I be doing?
diff --git a/doc/forum/How_to_delete_a_file_in_direct_mode__63__/comment_1_995f3b8cf511921719774f8911e24907._comment b/doc/forum/How_to_delete_a_file_in_direct_mode__63__/comment_1_995f3b8cf511921719774f8911e24907._comment
new file mode 100644
index 0000000000..f04d38bc1a
--- /dev/null
+++ b/doc/forum/How_to_delete_a_file_in_direct_mode__63__/comment_1_995f3b8cf511921719774f8911e24907._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-26T15:45:22Z"
+ content="""
+**direct** mode gets its name, because you can **direct**ly operate on files
+with commands like "rm" or "mv /tmp".
+
+So, to delete a file, you use such a command as you normally would.
+
+`git annex status` can be used in direct mode since `git status` does not
+work.
+
+Perhaps you should read the documentation: [[/direct_mode]]
+"""]]
diff --git a/doc/forum/How_to_delete_a_remote__63__.mdwn b/doc/forum/How_to_delete_a_remote__63__.mdwn
new file mode 100644
index 0000000000..6aebaf5f51
--- /dev/null
+++ b/doc/forum/How_to_delete_a_remote__63__.mdwn
@@ -0,0 +1 @@
+I have a repository with an S3 remote named `cloud`. I now no longer want to use that remote. I've dropped all the data from it (`git annex drop . --from cloud`). How do I tell my repository to forget about the remote?
diff --git a/doc/forum/How_to_delete_a_remote__63__/comment_1_8cba186bb67079ff41bf6d0b04613f4a._comment b/doc/forum/How_to_delete_a_remote__63__/comment_1_8cba186bb67079ff41bf6d0b04613f4a._comment
new file mode 100644
index 0000000000..e60eb3d5d9
--- /dev/null
+++ b/doc/forum/How_to_delete_a_remote__63__/comment_1_8cba186bb67079ff41bf6d0b04613f4a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnldTTAP8PAifJUmqhRar6RAWNWlRcencw"
+ nickname="Marco"
+ subject="You can set the trust to &quot;dead&quot;"
+ date="2013-01-23T19:02:22Z"
+ content="""
+Simple answer: You can't fully delete a remote - with annex commands. You can mark it as dead.
+
+You can give this a try as a workaround: [[Truly_purging_dead_repositories/#comment-51ab797094f4c07bf5327fd21cad5835]]
+"""]]
diff --git a/doc/forum/How_to_delete_a_remote__63__/comment_2_33c429ffa7e9e2ed9c5fac760ee8e82c._comment b/doc/forum/How_to_delete_a_remote__63__/comment_2_33c429ffa7e9e2ed9c5fac760ee8e82c._comment
new file mode 100644
index 0000000000..2866710c8b
--- /dev/null
+++ b/doc/forum/How_to_delete_a_remote__63__/comment_2_33c429ffa7e9e2ed9c5fac760ee8e82c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4830:1600:187::2"
+ subject="comment 2"
+ date="2013-09-04T06:43:26Z"
+ content="""
+Recently git-annex has gotten the ability to do this: `git annex forget --drop-dead`
+
+That prunes all history relating to all dead remotes. You need to be running a git-annex that supports this on all computers you use the repos on, or the pruned history will get merged back in.
+
+I don't recommend doing this just because you want to \"clean history\". Think of it as something you can do at some point in the future if the .git/objects somehow gets too large or too slow. Put off deleting data until tomorrow if you don't absolutely need to do it today.
+"""]]
diff --git a/doc/forum/How_to_delete_a_remote__63__/comment_3_e9c5508092ca2983f458b16bf1e07082._comment b/doc/forum/How_to_delete_a_remote__63__/comment_3_e9c5508092ca2983f458b16bf1e07082._comment
new file mode 100644
index 0000000000..337ef2efe1
--- /dev/null
+++ b/doc/forum/How_to_delete_a_remote__63__/comment_3_e9c5508092ca2983f458b16bf1e07082._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="konubinix"
+ ip="82.243.233.186"
+ subject="Dropping dead repositories"
+ date="2013-09-04T07:40:22Z"
+ content="""
+Actually, it may be a good idea to remove repositories made for tests purposes.
+
+I now have 2 dead repositories that are USB_test1 and USB_test2 that I created before knowing I could reuse the annex uuid.
+
+They are now there and it is difficult to remove them.
+
+For that special case, the --drop-dead feature is very welcome.
+"""]]
diff --git a/doc/forum/How_to_delete_a_remote__63__/comment_4_688a8473d074830303133ba939438084._comment b/doc/forum/How_to_delete_a_remote__63__/comment_4_688a8473d074830303133ba939438084._comment
new file mode 100644
index 0000000000..ef7b820bca
--- /dev/null
+++ b/doc/forum/How_to_delete_a_remote__63__/comment_4_688a8473d074830303133ba939438084._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Cyberthal"
+ avatar="http://cdn.libravatar.org/avatar/1c619d65ee07d2343295c8f70f23c9df"
+ subject="Deleting a repository UUID from vicfg"
+ date="2017-05-03T16:50:53Z"
+ content="""
+I followed these instructions, but a single entry for the targeted UUID persists in vicfg.
+
+For those of us with OCD, this is mildly irksome. Later I might have dead UUID's I actually want to remember, and that bit of spam will always be sitting there at the top of the file.
+
+However, deleting it is still worthwhile, because otherwise it is repeated in every list of remotes.
+"""]]
diff --git a/doc/forum/How_to_delete_a_remote__63__/comment_5_de7dff2dc4357d8cc617d86a06e35b1b._comment b/doc/forum/How_to_delete_a_remote__63__/comment_5_de7dff2dc4357d8cc617d86a06e35b1b._comment
new file mode 100644
index 0000000000..b7792c8e4b
--- /dev/null
+++ b/doc/forum/How_to_delete_a_remote__63__/comment_5_de7dff2dc4357d8cc617d86a06e35b1b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-05-09T18:03:54Z"
+ content="""
+It may help suppress the OCD to consider that vicfg is listing dead
+remotes to give you the option to make them not dead anymore.
+"""]]
diff --git a/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4.mdwn b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4.mdwn
new file mode 100644
index 0000000000..c67d4e77f8
--- /dev/null
+++ b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4.mdwn
@@ -0,0 +1,28 @@
+Git annex is really amazing software, and this cute little scenario is actually Linux's fault. But it's a nasty situation nonetheless, and worth passing on.
+
+...
+
+Create a client repository on your laptop and two backup repositories on external USB drives. Keep all repositories mounted and connected. Now drop 60GB of data spread over 30,000 files into your annex, and watch git annex assistant start adding and syncing. So far, so good.
+
+Now wait a few hours, and watch some kernel crypto code—probably ecryptfs—fall over with a segfault.
+
+Since your laptop and USB drives are all running ext4, the sudden kernel panic will leave you with hundreds of 0-length files. Because git annex assistant was busily adding and syncing files, those 0-length files are spread randomly throughout all your git repositories (typically in `.git/objects`) and throughout all the associated annexes. Unfortunately, because `git annex assistant` generates _tons_ of commits, this is pretty much unrecoverable using standard git tools unless you're willing to get deep into the repositories' internals.
+
+So what should you do, if you want to add 10s of 1000s of files and there's some risk of kernel panic or accidentally bumping a USB cable? Here's my recommendation to limit the damage:
+
+1. Use the command line if possible.
+2. Add all your files with your remotes offline.
+3. Run `git gc` on your central repository, just on general principals.
+4. Mount one repository at a time.
+5. Sync the pure git data first, and then make sure that all disk I/O is flushed (`sync; sleep 10` is a good approximation).
+6. Use `git annex copy --to` to move the annex data.
+7. Unmount the USB repository cleanly and move onto the next one.
+
+If you _do_ bump a USB cable in the middle of step (6), then:
+
+1. Run 'git annex fsck' to clean up any garbage files.
+2. Try another 'git annex copy --to' where you left off.
+
+Wiser minds than I are encouraged to suggest optimizations for the recovery steps.
+
+The theory behind these steps is to only do one thing at a time, and to expose as few remotes as possible to a power failure or crash. A secondary goal is to make sure that pure git operations complete very quickly, limiting the risk that they will be interrupted, because they're the hardest operations to recover from after a crash.
diff --git a/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_1_42ca6cfbbb79fe63514805b8119ac16b._comment b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_1_42ca6cfbbb79fe63514805b8119ac16b._comment
new file mode 100644
index 0000000000..f6d8396b7a
--- /dev/null
+++ b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_1_42ca6cfbbb79fe63514805b8119ac16b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 1"
+ date="2013-07-23T14:45:05Z"
+ content="""
+It seems to me that it would be better to avoid using kernel features that crash. And, set up a git repository on another machine, which will serve as a real backup if something goes catostrophically wrong. The only potential failure mode then would be if a kernel/hardware issue zeroed some of your files, in direct mode the assistant might commit those new corrupt files and ship them over to the backup. But, if your offsite backup is accumulating old versions of files, you can recover from this by reverting the bad commit.
+"""]]
diff --git a/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_2_c94ce6a9767c624e2445a7d9eea40396._comment b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_2_c94ce6a9767c624e2445a7d9eea40396._comment
new file mode 100644
index 0000000000..347a95539a
--- /dev/null
+++ b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_2_c94ce6a9767c624e2445a7d9eea40396._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="http://emk.myopenid.com/"
+ ip="24.2.150.84"
+ subject="Well, this is the first time it ever panicked"
+ date="2013-07-23T16:32:10Z"
+ content="""
+Well, it's not like my machine kernel panics on a regular basis or anything. :-) This is the first time I ever saw the kernel encryption code do this. I'm running a boring stock install of Ubuntu 12.04 LTS that was preloaded by ZaReason, and I'm using the ecryptfs home directory encryption supplied by Ubuntu. So in this case, \"stop using kernel features that crash\" means \"stop using Ubuntu on supported hardware.\"
+
+The underlying problem is that ext4 allocates file contents lazily and out-of-order, and it may wait a surprisingly long time before actually flushing data to disk:
+
+https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781
+http://linux.bihlman.com/2010/learn-linux-help/how-to-solve-zero-length-file-problem-in-linuxs-ext4-file-system/
+
+The problem is that `git annex assistant` and `git` don't sync the disks all that often, and that the assistant can generate huge amounts of complicated disk I/O across multiple volumes for hours on end. All you need to do is go through the walkthrough, create the specified repositories including one on a USB drive, and throw 50GB of data into the annex directory. `git annex assistant` will happily grind away overnight, and it anything prevents ext4 from flushing data, there's a good chance you'll wind up with multiple corrupted repositories with hundreds of `git fsck` errors.
+
+There are some potential workarounds:
+
+1. Reconfigure ext4 to run in data write-back mode. This isn't really possible for non-technical users, but it's an excellent idea for large external USB drives.
+2. Somehow convince `git` and `git annex assistant` to call `sync` or `fsync` more aggressively on local volumes.
+3. Use a remote server for at least one remote, as you suggested.
+4. Operate on the repository manually, so that you can ensure that `git`'s data is in a known-good state before trying to copy the annex files. The 
+annex files are much easier to recover than git's state.
+
+Anyway, I doubt this is really fixable. And it's not really `git annex`'s fault, in any case. But I'm really glad I had recent backups of all my data last night, which allowed me to checksum everything and start from scratch.
+
+...
+
+Leaving aside this incident, `git annex` is one of the nicest pieces of open source software I've seen in a long time, and it's clearly going to change how I use my computer. And thank you for posting the crowd-funding campaign so we can say \"Thanks!\"
+"""]]
diff --git a/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_3_bcda51053b62bbb20ce71a59469e1b26._comment b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_3_bcda51053b62bbb20ce71a59469e1b26._comment
new file mode 100644
index 0000000000..5cf8c93f38
--- /dev/null
+++ b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_3_bcda51053b62bbb20ce71a59469e1b26._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 3"
+ date="2013-07-23T17:17:43Z"
+ content="""
+`git config core.fsyncobjectfiles true`
+
+This will make git fsync all the data it writes. Whether it's a good default, I don't know.
+"""]]
diff --git a/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_4_48e5b9eae920e5f13812de8d6f6bc640._comment b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_4_48e5b9eae920e5f13812de8d6f6bc640._comment
new file mode 100644
index 0000000000..2bac2ca1bf
--- /dev/null
+++ b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_4_48e5b9eae920e5f13812de8d6f6bc640._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 4"
+ date="2013-07-23T17:38:50Z"
+ content="""
+I have made the assistant enable the fsync option when it creates a repository on a removable drive. That is, at least in my experience, the thing that most likely needs it. I don't know if it would have saved you in your situation or not.
+"""]]
diff --git a/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_5_787c0bfdc1d309db1486c3a37723a957._comment b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_5_787c0bfdc1d309db1486c3a37723a957._comment
new file mode 100644
index 0000000000..dd40495ca9
--- /dev/null
+++ b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_5_787c0bfdc1d309db1486c3a37723a957._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="comment 5"
+ date="2013-07-23T17:39:42Z"
+ content="""
+Oh i've had that type of crash from ecryptfs many times over many different versions of Ubuntu, also before i even encountered git-annex.
+
+Git-annex might provoke this issue, but it is by no means the only thing that can crash your system when running ecryptfs.
+
+I highly suggest you try LUKS for a stable experience.
+
+"""]]
diff --git a/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_6_8894beb06443f234e9200b03b5f3badf._comment b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_6_8894beb06443f234e9200b03b5f3badf._comment
new file mode 100644
index 0000000000..149998aaf0
--- /dev/null
+++ b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_6_8894beb06443f234e9200b03b5f3badf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 6"
+ date="2013-07-23T17:54:00Z"
+ content="""
+If there's an easy way to detect when a directory is inside an ecryptfs volume, I'd be happy to make the assistant automatically enable fsync on it. ;)
+"""]]
diff --git a/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_7_457f62ee3e58f68a55f66c5bde6002fd._comment b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_7_457f62ee3e58f68a55f66c5bde6002fd._comment
new file mode 100644
index 0000000000..8f545e2ebd
--- /dev/null
+++ b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_7_457f62ee3e58f68a55f66c5bde6002fd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://emk.myopenid.com/"
+ ip="24.2.150.84"
+ subject="Thank you!"
+ date="2013-07-23T18:36:22Z"
+ content="""
+What good idea! I've turned on `core.fsyncobjectfiles`. This should definitely help avoid the worst damage when ext4 filesystems get unmounted while dirty. Thank you very much for addressing this issue so quickly, even if though has more to do with ext4 than git annex.
+
+develop: Thank you for the suggestion to use LUKS; that's good to know.
+"""]]
diff --git a/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_8_bd2b412116a66107bc0ff0efd7e39a58._comment b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_8_bd2b412116a66107bc0ff0efd7e39a58._comment
new file mode 100644
index 0000000000..0d09a9652b
--- /dev/null
+++ b/doc/forum/How_to_destroy_a_master_annex_and_all_remotes_with_git_annex_assistant_and_ext4/comment_8_bd2b412116a66107bc0ff0efd7e39a58._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://emk.myopenid.com/"
+ ip="24.2.150.84"
+ subject="Detecting ecryptfs"
+ date="2013-07-23T18:49:08Z"
+ content="""
+If the string `\" ecryptfs \"` (with surrounding spaces) appears in `/etc/mtab`, then there's at least one ecryptfs volume on the system. More specific parsing will tell you where it's mounted.
+
+Ubuntu released a new kernels fixing the worst ecryptfs bugs in 12.04 LTS. The current version is OK, but perhaps not exactly great. Some older versions are public menaces with awful data corruption bugs.
+"""]]
diff --git a/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__.mdwn b/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__.mdwn
new file mode 100644
index 0000000000..92bf09ae27
--- /dev/null
+++ b/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__.mdwn
@@ -0,0 +1,9 @@
+I'd like to provide a team of some non-technical Windows (=direct mode) users with the following git-shell scripts to make collaboration safer than with plain "sync":
+
+1) **update-changes-from-others.sh** -- Like sync, but don't commit any local changes. Merge them like sync, don't discard.
+
+2) **sync-all-but-deletes.sh** -- Like sync but don't commit any deletions (-> renames may become additions).
+
+3) **discard-all-my-changes.sh** -- Forcibly discard all local changes, then checkout and get latest master head.
+
+Any pointers on how to approach implementing these safely?
diff --git a/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_1_c5226964b4b64bd47d888b5616ff970b._comment b/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_1_c5226964b4b64bd47d888b5616ff970b._comment
new file mode 100644
index 0000000000..91edd264d0
--- /dev/null
+++ b/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_1_c5226964b4b64bd47d888b5616ff970b._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-12-01T23:08:56Z"
+ content="""
+Well, if you set `remote.foo.annex-readonly` to true, then git-annex
+sync won't push changes to the remote named "foo".
+
+You could set that in .git/config, or you could do something like
+this to set it only when running the sync:
+
+git -c remote.foo.annex-readonly=true annex sync
+
+I am not sure about a good solution for sync-all-but-deletes.sh,
+although it seems like the new `git annex proxy` could perhaps
+be used to build it.
+
+discard-all-my-changes.sh could probably be implemented using the new
+`git annex proxy` command. It would be pretty unsafe though! Maybe
+instead make it first commit all local changes, and then use 
+`git annex proxy -- git reset --hard origin/master`
+"""]]
diff --git a/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_2_748d243bac14a8d55be4ac324c581c1d._comment b/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_2_748d243bac14a8d55be4ac324c581c1d._comment
new file mode 100644
index 0000000000..edef7c1470
--- /dev/null
+++ b/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_2_748d243bac14a8d55be4ac324c581c1d._comment
@@ -0,0 +1,62 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWBvsZvSsAL8P2ye3F0OBStjFCVnOImzM"
+ nickname="Jarno"
+ subject="comment 2"
+ date="2014-12-03T20:04:42Z"
+ content="""
+Thank you, `remote.foo.annex-readonly` looks like a nice solution for the update-changes-from-other.sh!
+
+For discard-all-my-changes.sh, `reset --hard` through proxy worked otherwise nicely, but it doesn't seem to restore deletions:
+
+    $ git annex proxy -- git reset --hard origin/master
+    HEAD is now at 37aed97 git-annex automatic sync
+
+    $ echo \"A\" > test.txt
+    
+    $ git annex add test.txt
+    add test.txt ok
+    (Recording state in git...)
+    
+    $ git annex sync
+    commit  ok
+    pull origin
+    ok
+    push origin
+    Counting objects: 17, done.
+    Delta compression using up to 8 threads.
+    Compressing objects: 100% (7/7), done.
+    Writing objects: 100% (8/8), 783 bytes | 0 bytes/s, done.
+    Total 8 (delta 4), reused 1 (delta 0)
+    To ssh://gitannex@serv-gitannex:/home/gitannex/git-annex-test.git
+       88a25b5..0a8281d  git-annex -> synced/git-annex
+       37aed97..2978dcd  annex/direct/master -> synced/master
+    ok
+    
+    $ rm test.txt
+    
+    $ git annex proxy -- git reset --hard origin/master
+    warning: packfile .git/objects/pack/pack-42568744cdbba46b2dd71a7f37546a52bb26684
+    4.pack cannot be accessed
+    HEAD is now at 2978dcd git-annex automatic sync
+    
+    $ ls test.txt
+    ls: test.txt: No such file or directory
+    
+    $ git annex status
+    D test.txt
+
+    $ git annex version
+    git-annex version: 5.20141128-g70f997e
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feed
+    s Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SH
+    A256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar ho
+    ok external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 2 3 4
+
+Note the \"pack cannot be accessed\" after the second reset.
+
+"""]]
diff --git a/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_3_cf9234339bad14ad9a9d3027f9066936._comment b/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_3_cf9234339bad14ad9a9d3027f9066936._comment
new file mode 100644
index 0000000000..3cf4545621
--- /dev/null
+++ b/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_3_cf9234339bad14ad9a9d3027f9066936._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWBvsZvSsAL8P2ye3F0OBStjFCVnOImzM"
+ nickname="Jarno"
+ subject="Properly saving the changes before hard reset..?"
+ date="2014-12-03T21:46:23Z"
+ content="""
+BTW, my complete discard-all-my-changes.sh is, at the moment:
+
+    git annex add .
+    git annex proxy -- git commit -m \"Temp commit: changes to be discarded on $HOSTNAME.\"
+    git annex proxy -- git reset --hard origin/master
+    git annex get
+    git -c core.bare=false clean -dfi
+
+Is that `proxy -- git commit` even the proper way to save the changes locally before discarding, or will the branch change of the proxied commit always lose the annexed data? While testing, I've noticed that `add .` followed by `proxy -- git commit` at least sometimes replaces the contents of the changed file with a hash, with no apparent way to get them back.
+
+Example:
+
+    $ echo \"test string\" >> show-changes.sh
+    
+    $ git annex add show-changes.sh
+    add show-changes.sh ok
+    (Recording state in git...)
+    
+    $ git annex proxy -- git commit -m \"test\"
+    [annex/direct/master a2a594f] test
+     1 file changed, 1 insertion(+), 1 deletion(-)
+
+    $ cat show-changes.sh
+    ..\..\..\..\.git\annex\objects\QG\3J\SHA256E-s313--a05d6ed6cb73f6a95d98606d37e01
+    4e5b65e86b9fdb8e9fedded7d36a06ea90a.sh\SHA256E-s313--a05d6ed6cb73f6a95d98606d37e
+    014e5b65e86b9fdb8e9fedded7d36a06ea90a.sh    
+
+    $ git annex get show-changes.sh
+    get show-changes.sh (not available)
+      No other repository is known to contain the file.
+    failed
+    git-annex: get: 1 failed
+
+    $ git annex fsck show-changes.sh
+    fsck show-changes.sh (fixing link) ok
+    (Recording state in git...)
+
+    $ cat show-changes.sh
+    .git\annex\objects\QG\3J\SHA256E-s313--a05d6ed6cb73f6a95d98606d37e014e5b65e86b9f
+    db8e9fedded7d36a06ea90a.sh\SHA256E-s313--a05d6ed6cb73f6a95d98606d37e014e5b65e86b
+    9fdb8e9fedded7d36a06ea90a.sh
+
+"""]]
diff --git a/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_4_d899cf35801636e618e4675d91d6104a._comment b/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_4_d899cf35801636e618e4675d91d6104a._comment
new file mode 100644
index 0000000000..146156b2df
--- /dev/null
+++ b/doc/forum/How_to_emulate___34__one-way_sync__34__s_in_a_direct_repo__63__/comment_4_d899cf35801636e618e4675d91d6104a._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnbPKLjBONawBd74MKJZo05juCqdsP1jAU"
+ nickname="Ramon"
+ subject="comment 4"
+ date="2015-03-01T23:58:19Z"
+ content="""
+But is there a way to have the changes in one node (the \"read only\") discarded when there are changes in the remote, so that the new version in the remote is propagated to the read only node?
+So I guess what I'd like is something like *update-changes-from-others.sh* (Like sync, but don't commit any local changes. Merge them like sync, don't discard) but without the merging, so discarding any changes as soon as a new version appears in the remote. 
+
+
+I've tried the ```remote.foo.annex-readonly = true``` in Android but I am not getting my intended behavior.
+
+For instance, suppose a computer and a Android device (but with direct mode, since working with assistant)
+
+- Create file in computer
+- Let it appear in Android
+- Modify in Android; this change apparently does not propagate back to the computer.
+- Modify again in computer; sometime later one gets a conflict (file.variant-xxxx and file-variant-yyyy, with the computer getting one of the conflicts as a link that points nowhere).
+
+
+Adding ```autocommit = false``` does not help either.
+
+
+"""]]
diff --git a/doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__.mdwn b/doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__.mdwn
new file mode 100644
index 0000000000..f06135c24e
--- /dev/null
+++ b/doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__.mdwn
@@ -0,0 +1,7 @@
+My annex contains several large files that I have unlocked, edited, and committed again, i.e. the annex contains the version history of those files. However, I don't want the history -- keeping the latest version is good enough for me. Running `git annex unused` won't detect those old versions, though, because they aren't unused as old Git revisions still refer to them. So I wonder:
+
+1. What is the best way to get rid of the old versions of files in the annex?
+
+2. What is the best way to detect old versions of files in the annex?
+
+I guess, I could run `git rebase -i` to squash commits to those files into one commit, thereby getting rid of the references to the old copies, but that approach feels awkward and error prone. Is anyone aware of a better way?
diff --git a/doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__/comment_1_dccf4dc4483d08e5e2936b2cadeafeaf._comment b/doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__/comment_1_dccf4dc4483d08e5e2936b2cadeafeaf._comment
new file mode 100644
index 0000000000..ee4fe2e6ce
--- /dev/null
+++ b/doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__/comment_1_dccf4dc4483d08e5e2936b2cadeafeaf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://peter-simons.myopenid.com/"
+ ip="77.186.179.173"
+ subject="comment 1"
+ date="2012-02-09T18:53:00Z"
+ content="""
+Sorry for commmenting on my own question ... I think I just figured out that `git annex unused` *does* in fact do what I want. When I tried it, it just didn't show the obsolete versions of the files I edited because I hadn't yet synchronized all repositories, so that was why the obsolete versions were still considered used.
+"""]]
diff --git a/doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__/comment_2_5710294c1c8652c12b6df2233255a45e._comment b/doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__/comment_2_5710294c1c8652c12b6df2233255a45e._comment
new file mode 100644
index 0000000000..576093a87f
--- /dev/null
+++ b/doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__/comment_2_5710294c1c8652c12b6df2233255a45e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2012-02-09T19:42:28Z"
+ content="""
+Yes, contents are still considered used while tags or refs refer to them. Including remote tracking branches like `remotes/origin/master`
+"""]]
diff --git a/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__.mdwn b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__.mdwn
new file mode 100644
index 0000000000..998c608dd4
--- /dev/null
+++ b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__.mdwn
@@ -0,0 +1,9 @@
+<video src=http://s.natalian.org/2015-04-15/git-annex-issues.mp4></video>
+
+I removed some archived directories perhaps foolishly with `rm -rf`. How do I find the files that I've had deleted?
+
+
+
+I also have an issue where by I want one command to sync between two hardrives and [github](https://github.com/kaihendry/uploadme). Or do I have to: `git-annex move --to {foo,bar}; git-annex drop; git-annex sync`? Basically I want copies everywhere except on my laptop (X1C3).
+
+I also expected my git dir to be much smaller than 1.4GB after dropping everything. Thanks!
diff --git a/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_1_8332f71241335a31e270407477bd84f3._comment b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_1_8332f71241335a31e270407477bd84f3._comment
new file mode 100644
index 0000000000..d142d742c1
--- /dev/null
+++ b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_1_8332f71241335a31e270407477bd84f3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-18T19:06:27Z"
+ content="""
+Is your titular question a git-annex question, or a generic git question?
+Because I think the answer would be the same in either case. Ie, `git log`
+or `git status` will tell you what changes you've made to the work tree.
+
+If you've deleted files from your git working tree with rm -rf, then
+their content is still stored in the .git directory. This is also true
+when using git-annex (unless you're using direct mode). 
+
+The size of your .git directory might be a clue: If you've deleted
+files from the working tree, you may not have dropped their content
+from git annex. You can use `git annex unused` to find and clean up
+such file contents.
+"""]]
diff --git a/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_2_984286a35ec828f1e8dda928ea577571._comment b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_2_984286a35ec828f1e8dda928ea577571._comment
new file mode 100644
index 0000000000..15a48bfe41
--- /dev/null
+++ b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_2_984286a35ec828f1e8dda928ea577571._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="http://hendry.iki.fi/"
+ nickname="Kai Hendry"
+ subject="git annex unused doesn't help"
+ date="2015-04-19T13:24:50Z"
+ content="""
+This is a git-annex question. I want to find files that are not in my working tree but are on the backups on my two USB hard drives.
+
+
+I see in this commit the images that I deleted: <https://github.com/kaihendry/uploadme/commit/c53dbdd9bd7879d68635a2adc81a7bc59a84c5ea>
+
+How can I simply just get a listing of where the copies are?
+
+For example I deleted IMG_4110.JPG.
+
+But when I run:
+
+    X1C3:~/media/uploadme$ git-annex whereis IMG_4110.JPG
+    git-annex: IMG_4110.JPG not found
+
+I am pretty confident I have a copy of this on my external USB drives.
+
+Also tried another file:
+
+    X1C3:~/media/uploadme$ git-annex whereis IMG_4558.JPG
+    git-annex: IMG_4558.JPG not found
+    X1C3:~/media/uploadme$ git-annex whereis 2014-10-05/IMG_4558.JPG
+    git-annex: 2014-10-05/IMG_4558.JPG not found
+
+So I am still in the dark how to see how git-annex tracks deleted files across my remotes.
+
+
+
+
+"""]]
diff --git a/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_3_29f6f9df1ad22113e9690b0d1da36ba0._comment b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_3_29f6f9df1ad22113e9690b0d1da36ba0._comment
new file mode 100644
index 0000000000..3a39314a98
--- /dev/null
+++ b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_3_29f6f9df1ad22113e9690b0d1da36ba0._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 3"
+ date="2015-04-19T15:51:45Z"
+ content="""
+Have you tried checking out a commit which it was present in and then using whereis?
+
+Not sure if you can do:
+
+    git annex whereis --key $KEY
+
+But if not, may be worth a feature request!
+"""]]
diff --git a/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_4_43549b3d231f52cf53a66c477c34a708._comment b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_4_43549b3d231f52cf53a66c477c34a708._comment
new file mode 100644
index 0000000000..7d29bec3a7
--- /dev/null
+++ b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_4_43549b3d231f52cf53a66c477c34a708._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-04-21T20:22:25Z"
+ content="""
+Yeah, you need to `git checkout` a tree from before you deleted the files,
+and then you'll be able to use `git annex whereis` in there on the deleted
+files. This will tell you where the files are currently located (not some historical data).
+
+`git annex whereis --key` is indeed an alternative approach, if you know
+the key corresponding to the deleted file. You can see the keys in the git
+diff, if you know where to look.
+
+[[internals]] will let you understand how this all really works.
+"""]]
diff --git a/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_5_94aca10f84783f35d927dbefbeba263a._comment b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_5_94aca10f84783f35d927dbefbeba263a._comment
new file mode 100644
index 0000000000..77cf1c2895
--- /dev/null
+++ b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__/comment_5_94aca10f84783f35d927dbefbeba263a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://hendry.iki.fi/"
+ nickname="Kai Hendry"
+ subject="Two more questions"
+ date="2015-05-07T07:40:41Z"
+ content="""
+How do I undelete in my case then? I.e. not `git checkout ` to find where they are.
+
+`git revert c53dbdd9bd7879d68635a2adc81a7bc59a84c5ea`
+
+
+
+Assuming I make no effort to undelete or recover the files:
+
+The (deleted) files I have copies of on my other two hard drives. Do they detect I've deleted the files and just clean up? How does that process work?
+"""]]
diff --git a/doc/forum/How_to_find_out_if_assistant_is_still_repairing__63__.mdwn b/doc/forum/How_to_find_out_if_assistant_is_still_repairing__63__.mdwn
new file mode 100644
index 0000000000..a959424348
--- /dev/null
+++ b/doc/forum/How_to_find_out_if_assistant_is_still_repairing__63__.mdwn
@@ -0,0 +1 @@
+I have a corrupted repository, that git annex assistant wanted to repair. Before clicing on the button to start the repairing process, I had to deactivate my internet connection for another reason. The daemon.log is showing some connection errors to my remotes. But since pressing the button to repair my repo, the webapp is not showing the dashboard and there's no indicator that's trustworthy enough, that stuff is happening. There are some git and git annex processes running, but is there really now better way to know, if the repairing process is making progress, or if I need to restart the assistant because I needed to reset my internet connection.
diff --git a/doc/forum/How_to_find_out_if_assistant_is_still_repairing__63__/comment_1_9dd192a8e0bfa9e533b22070b87792af._comment b/doc/forum/How_to_find_out_if_assistant_is_still_repairing__63__/comment_1_9dd192a8e0bfa9e533b22070b87792af._comment
new file mode 100644
index 0000000000..988d23374f
--- /dev/null
+++ b/doc/forum/How_to_find_out_if_assistant_is_still_repairing__63__/comment_1_9dd192a8e0bfa9e533b22070b87792af._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 1"
+ date="2016-05-10T14:42:21Z"
+ content="""
+The assistant was indeed still repairing, but there has to be a way to better indicate this. Also it would be nice to let the user know, that, while in repair mode, you can not change syncing settings of your remotes. [See also.](http://git-annex.branchable.com/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/)
+"""]]
diff --git a/doc/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_.mdwn b/doc/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_.mdwn
new file mode 100644
index 0000000000..66a945b192
--- /dev/null
+++ b/doc/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_.mdwn
@@ -0,0 +1,7 @@
+This is more of a mini-tip or self-answered question: What to do when git-annex says "... (transfer already in progress, or unable to take transfer lock)" when trying to transfer a file to a special remote.
+
+If you are sure that there are no other git-annex processes trying to upload (i.e. you cancelled it but git-annex crashed in the middle or something), have a look at `.git/annex/transfer/upload/`. This is only for when you can't get them to be copied by re-running the git-annex command, only for when subsequent calls don't fix it. Intermittent issues might be caused by multiple jobs, so dropping the `--jobs` parameter should fix those.
+
+In my case I had two keys that git-annex refused to copy to a special remote no matter what I did and those dirs contained files named after the keys + ones with `lck.` prefix. After removing those dirs, the upload went through as expected.
+
+Hope this helps someone :) 
diff --git a/doc/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_/comment_1_345a7439720e8dc2cc6cb5eed6bcf73f._comment b/doc/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_/comment_1_345a7439720e8dc2cc6cb5eed6bcf73f._comment
new file mode 100644
index 0000000000..dc193f31e3
--- /dev/null
+++ b/doc/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_/comment_1_345a7439720e8dc2cc6cb5eed6bcf73f._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-05T19:38:17Z"
+ content="""
+The only way I know of that this can perhaps happen is if you have
+a remote accessed over ssh, and you are uploading to it, and ctrl-c
+git-annex and then start the upload again. In that case, it's the remote
+git-annex that complains about the transfer lock, and that happens because
+sometimes the ctrl-c doesn't immediately stop the remote git-annex-shell
+process. But if this were the case, deleting the local directory wouldn't
+help, it would be the remote repo's directory you'd need to mess with, or
+better just stop that git-annex-shell process.
+
+Otherwise, it's true that the lock files for transfers live in that directory,
+and deleting it is safe enough. However, the way git-annex uses locks should
+not suffer from stale lock files normally. A few cases where I guess it
+could:
+
+* When annex.pidlock is set
+* Maybe when using NFS
+* Windows maybe?
+* Older versions of git-annex could get confused with --jobs when
+  several worktree files used the same key, but that's been fixed for a
+  while.
+
+Otherwise, it seems much more likely that you still had a git-annex process
+that  you didn't notice holding the lock open, than it does that your OS is
+letting stale fcntl locks linger around after a process exits.
+"""]]
diff --git a/doc/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_/comment_2_55ad844ee650a6a5026fdf5764dd9470._comment b/doc/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_/comment_2_55ad844ee650a6a5026fdf5764dd9470._comment
new file mode 100644
index 0000000000..beb7daf9cd
--- /dev/null
+++ b/doc/forum/How_to_fix__58_____40__transfer_already_in_progress__44___or_/comment_2_55ad844ee650a6a5026fdf5764dd9470._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="mattplasmastrike@59cb7d099c8665f6c7668d78d9f17db87cabc2fe"
+ nickname="mattplasmastrike"
+ avatar="http://cdn.libravatar.org/avatar/b700eeba98fedf3acb60d76ed1a6df40"
+ subject="comment 2"
+ date="2021-07-31T23:59:12Z"
+ content="""
+- I was also affected by this and removing everything in the transfer folder \"rm -rf ./.git/annex/transfer/*\" on both devices fixed the issue for me.
+- I sure I could have fixed this with a more surgical operation by selectively deleting files or maybe a command that I do not know
+- although I am not sure what caused it I was canceling the progress with \"control c\"
+"""]]
diff --git a/doc/forum/How_to_fix_bad_merge.mdwn b/doc/forum/How_to_fix_bad_merge.mdwn
new file mode 100644
index 0000000000..48b7486104
--- /dev/null
+++ b/doc/forum/How_to_fix_bad_merge.mdwn
@@ -0,0 +1,7 @@
+I stuffed up the [android_sync_with_adb instructions](https://git-annex.branchable.com/tips/android_sync_with_adb) and not for the first time, ending up with everything deleted from my annex except what was on my phone.
+
+I think I previously fixed it with a 'git reset --hard' however this time it has spread to all my annexes. And every time I sync the wrong situation is restored.
+
+I know I haven't lost any files, but how can I get the symlinks back the way they were?
+
+What branches do I need to reset on which repositories?
diff --git a/doc/forum/How_to_fix_bad_merge/comment_1_4a32a727560ab85203d1dd76feff2e1e._comment b/doc/forum/How_to_fix_bad_merge/comment_1_4a32a727560ab85203d1dd76feff2e1e._comment
new file mode 100644
index 0000000000..6af1305dbe
--- /dev/null
+++ b/doc/forum/How_to_fix_bad_merge/comment_1_4a32a727560ab85203d1dd76feff2e1e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-05T16:28:32Z"
+ content="""
+Find the commit that deleted the files (eg with `git log --stat`)
+and `git revert` that commit.
+
+AKA, same way you would deal with a problem commit in any git repository.
+"""]]
diff --git a/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__.mdwn b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__.mdwn
new file mode 100644
index 0000000000..f2b52cc965
--- /dev/null
+++ b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__.mdwn
@@ -0,0 +1,22 @@
+At some point in testing I did a `drop --force` and have no more copies of these files.
+
+When I run `get -A` I get a report that they can't be found, which makes sense. So, I don't need git annex telling me that every time.
+
+I tried `git annex dead --key SHA256E-s70539--3da7e5e584997ad3f8c5cc995025cffb4f0521763bd75be3c8f5e20e2811a0b7.RPP` and it says "ok" but they still show up in `get -A`.
+
+How can I make annex forget these keys ever existed?
+
+```
+$ git annex get -A
+get SHA256E-s70539--3da7e5e584997ad3f8c5cc995025cffb4f0521763bd75be3c8f5e20e2811a0b7.RPP (not available) 
+  No other repository is known to contain the file.
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+get SHA256E-s37042--f1eb72f5f17174741dfb7bc67c4d9ec9c58f60e12be5c05df39ac35477343d96.RPP (not available) 
+  No other repository is known to contain the file.
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+get: 2 failed
+```
diff --git a/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_1_5962c2c7b3a668429a62f7bede990801._comment b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_1_5962c2c7b3a668429a62f7bede990801._comment
new file mode 100644
index 0000000000..434c77e556
--- /dev/null
+++ b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_1_5962c2c7b3a668429a62f7bede990801._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="re: How to forget keys that get can't find?"
+ date="2022-09-11T16:43:47Z"
+ content="""
+See [[`git-annex-dead`|git-annex-dead]].
+"""]]
diff --git a/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_2_f84a8e545da95e72b3e2b03a782335ce._comment b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_2_f84a8e545da95e72b3e2b03a782335ce._comment
new file mode 100644
index 0000000000..467859f63c
--- /dev/null
+++ b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_2_f84a8e545da95e72b3e2b03a782335ce._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 2"
+ date="2022-09-11T17:11:36Z"
+ content="""
+As stated in my post, I did use `git annex dead` on this key, and am still getting that error.
+"""]]
diff --git a/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_3_74f14ae50e37d94fbd2950924a7bee28._comment b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_3_74f14ae50e37d94fbd2950924a7bee28._comment
new file mode 100644
index 0000000000..4522198e10
--- /dev/null
+++ b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_3_74f14ae50e37d94fbd2950924a7bee28._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="re: How to forget keys that get can't find"
+ date="2022-09-13T17:16:52Z"
+ content="""
+Sorry, somehow missed that
+
+Then sounds like this might be worth posting as a [[bug report|bugs]].
+"""]]
diff --git a/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_4_ee99cdb44671eea30eaa4351dbb9dc96._comment b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_4_ee99cdb44671eea30eaa4351dbb9dc96._comment
new file mode 100644
index 0000000000..f6cdbebdf5
--- /dev/null
+++ b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_4_ee99cdb44671eea30eaa4351dbb9dc96._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-09-13T18:21:13Z"
+ content="""
+This was a reversion. 
+
+In 2017,  [[!commit bcf276655c04f36e021f091240ed2dc8211924fd]]
+made --all skip dead keys, by modifying loggedKeys.
+
+But, then the implementation of --all changed to not use loggedKeys
+in [[!commit d010ab04be5a8d74fe85a2fa27a853784d1f9009]].
+
+I've fixed this!
+"""]]
diff --git a/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_5_d0d7674589574ae92e2595d23d000f61._comment b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_5_d0d7674589574ae92e2595d23d000f61._comment
new file mode 100644
index 0000000000..20dafd50a7
--- /dev/null
+++ b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_5_d0d7674589574ae92e2595d23d000f61._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 5"
+ date="2022-09-28T07:43:28Z"
+ content="""
+It's working great here, thanks!!
+"""]]
diff --git a/doc/forum/How_to_get_detailed_information_on_special_remotes__63__.mdwn b/doc/forum/How_to_get_detailed_information_on_special_remotes__63__.mdwn
new file mode 100644
index 0000000000..415b7570e3
--- /dev/null
+++ b/doc/forum/How_to_get_detailed_information_on_special_remotes__63__.mdwn
@@ -0,0 +1 @@
+How can I get information on already-configured special remotes in a repository?  I'd like to find out what type a given special remote is, and which URL/bucket, encryption mode, etc. was used to set it up.
diff --git a/doc/forum/How_to_get_detailed_information_on_special_remotes__63__/comment_1_f1eca38ca0c1edb66e64ac64f0321829._comment b/doc/forum/How_to_get_detailed_information_on_special_remotes__63__/comment_1_f1eca38ca0c1edb66e64ac64f0321829._comment
new file mode 100644
index 0000000000..84b67f75e1
--- /dev/null
+++ b/doc/forum/How_to_get_detailed_information_on_special_remotes__63__/comment_1_f1eca38ca0c1edb66e64ac64f0321829._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-28T20:39:41Z"
+ content="""
+The latest version of git-annex adds the ability to `git annex info
+$remote` and get all the info you asked for. Enjoy!
+"""]]
diff --git a/doc/forum/How_to_get_detailed_information_on_special_remotes__63__/comment_2_73f8b7ebde5870f92bec02d15a533ef3._comment b/doc/forum/How_to_get_detailed_information_on_special_remotes__63__/comment_2_73f8b7ebde5870f92bec02d15a533ef3._comment
new file mode 100644
index 0000000000..cc174870c3
--- /dev/null
+++ b/doc/forum/How_to_get_detailed_information_on_special_remotes__63__/comment_2_73f8b7ebde5870f92bec02d15a533ef3._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="gernot"
+ subject="comment 2"
+ date="2014-11-09T20:30:39Z"
+ content="""
+That's perfect.  Thanks, Joey!
+"""]]
diff --git a/doc/forum/How_to_get_encrypted_name_from_special_remote__63__.mdwn b/doc/forum/How_to_get_encrypted_name_from_special_remote__63__.mdwn
new file mode 100644
index 0000000000..80bb1fcfc0
--- /dev/null
+++ b/doc/forum/How_to_get_encrypted_name_from_special_remote__63__.mdwn
@@ -0,0 +1 @@
+I'm using Amazon S3 (Glacier Deep Archive) as a special remote, and using pubkey encryption. Is there a command to get the encrypted file name for a file so that I can initiate restore on that file before calling `git annex get`? 
diff --git a/doc/forum/How_to_get_encrypted_name_from_special_remote__63__/comment_1_47ce17796de422fe996f45083a6b79b0._comment b/doc/forum/How_to_get_encrypted_name_from_special_remote__63__/comment_1_47ce17796de422fe996f45083a6b79b0._comment
new file mode 100644
index 0000000000..d26d3b9a48
--- /dev/null
+++ b/doc/forum/How_to_get_encrypted_name_from_special_remote__63__/comment_1_47ce17796de422fe996f45083a6b79b0._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-07-15T15:44:03Z"
+ content="""
+See [[tips/Decrypting_files_in_special_remotes_without_git-annex]].
+
+But there is a glacier special remote which handles its particulars.
+It's probably possible to set up a new remote using that,
+which will access the data in your S3 remote now,
+using the method described in
+[[tips/multiple_remotes_accessing_the_same_data_store]].
+"""]]
diff --git a/doc/forum/How_to_get_git-annex_to_forget_a_commit__63__.mdwn b/doc/forum/How_to_get_git-annex_to_forget_a_commit__63__.mdwn
new file mode 100644
index 0000000000..d5aa71b448
--- /dev/null
+++ b/doc/forum/How_to_get_git-annex_to_forget_a_commit__63__.mdwn
@@ -0,0 +1,54 @@
+I've done a `git annex add` and `git commit` on my annex which included some files I don't want to add to the annex. I've tried to reverse it all out, but whenever I `git annex add` something, the unwanted files show up in the git-annex branch.
+
+    git init forgetmenot
+    cd forgetmenot
+    git commit -m "create" --allow-empty
+    git annex init fmn
+    
+    echo 'foo' > foo
+    echo 'bar' > bar
+    
+    git annex add
+    git commit -m "add foo"
+    
+    git log --oneline --name-only
+    # 28634c0 add foo
+    # bar
+    # foo
+    # 4a87050 create
+
+    git log --oneline --name-only git-annex
+    74e6969 update
+    41d/a26/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.log
+    a70/4a5/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730.log
+    95285ed update
+    uuid.log
+    2135e07 branch created
+
+If you now try to get git-annex to forget by reverting *master* and *git-annex* and only adding/commiting *foo*, the master branch ends up correct, but git-annex magically remembers *bar*!
+
+    git reset --hard HEAD^
+    git branch -f git-annex git-annex^
+
+    echo 'foo' > foo
+    git annex add
+    git commit -m "add foo"
+
+    git log --oneline --name-only
+    # 1b4889e add foo
+    # foo
+    # 4a87050 create
+
+    git log --oneline --name-only git-annex
+    # 3d0b9bc update
+    # 41d/a26/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.log
+    # a70/4a5/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730.log
+    # 2e17a19 update
+    # uuid.log
+    # 646776b branch created
+
+How is git-annex remembering this and how can I get it to completely forget?
+
+I have tried `git gc --aggressive --prune=all`, `git annex fsck --all` and `git annex drop unused` but somehow, git-annex is remembering bar existed.
+
+This is an exercise in micro-managing the git-annex branch a bit, but this situation does also cause git-annex to complain about the missing files on fsck (0 out of 2 copies) so it isn't just being a control freak! Honest! :)
diff --git a/doc/forum/How_to_get_git-annex_to_forget_a_commit__63__/comment_1_65471c42e163ac8ee6ec109f1397271b._comment b/doc/forum/How_to_get_git-annex_to_forget_a_commit__63__/comment_1_65471c42e163ac8ee6ec109f1397271b._comment
new file mode 100644
index 0000000000..44b36ba604
--- /dev/null
+++ b/doc/forum/How_to_get_git-annex_to_forget_a_commit__63__/comment_1_65471c42e163ac8ee6ec109f1397271b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ ip="81.111.193.130"
+ subject="comment 1"
+ date="2014-07-17T15:43:03Z"
+ content="""
+Joey has pointed me to the solution.
+
+git-annex was remembering these files due to them being present in *.git/annex/index*.
+
+A simple `rm .git/annex/index` after moving the git-annex branch to the earlier commit prevents the \"ghost\" log files from being recreated and Joey confirmed this is safe to do (git-annex automatically recreates it).
+"""]]
diff --git a/doc/forum/How_to_get_git-annex_to_forget_a_commit__63__/comment_2_cc991abd9155a8e4d935b04ba432744f._comment b/doc/forum/How_to_get_git-annex_to_forget_a_commit__63__/comment_2_cc991abd9155a8e4d935b04ba432744f._comment
new file mode 100644
index 0000000000..2d15cf35e0
--- /dev/null
+++ b/doc/forum/How_to_get_git-annex_to_forget_a_commit__63__/comment_2_cc991abd9155a8e4d935b04ba432744f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 2"
+ date="2014-07-17T16:05:33Z"
+ content="""
+Of course, if the repository has any git remotes, there will also be remote-tracking branches for the git-annex branch that get automatically merged back in, etc. 
+"""]]
diff --git a/doc/forum/How_to_handle_cold_storage__63__.mdwn b/doc/forum/How_to_handle_cold_storage__63__.mdwn
new file mode 100644
index 0000000000..79ea77328a
--- /dev/null
+++ b/doc/forum/How_to_handle_cold_storage__63__.mdwn
@@ -0,0 +1,7 @@
+In my storage setup, I've got a NAS with a copy available to network devices, a copy among a few (mostly) offline USB drives near the NAS for backup and then a bunch of loose drives that are far away from the NAS for off-site backup which also hold a copy.
+
+Most of this is cold storage.
+
+In order to drop content from remotes (e.g. after watching a Movie on the laptop that as been copies from the NAS), I'd need physical access to drives out of the latter two categories in addition to the NAS and directly connect them to the laptop. This isn't feasible of course.
+
+I've resorted to setting all the cold drives as trusted but I feel like there should be a better way to go about this, given how well git-annex lends itself to managing cold storage (The Archivist use-case).
diff --git a/doc/forum/How_to_handle_cold_storage__63__/comment_1_ff49a65d4adaff3cf3902c2850227ea2._comment b/doc/forum/How_to_handle_cold_storage__63__/comment_1_ff49a65d4adaff3cf3902c2850227ea2._comment
new file mode 100644
index 0000000000..2c054ba4af
--- /dev/null
+++ b/doc/forum/How_to_handle_cold_storage__63__/comment_1_ff49a65d4adaff3cf3902c2850227ea2._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-06-28T16:08:38Z"
+ content="""
+This is what [[todo/do_not_count_trusted_repos_toward_mincopies]] is kind
+of about; setting a repo to trusted right now is a promise that you won't
+delete data from it, or will be careful when you do to sync that fact to
+everywhere. If that todo got implemented, you could set all the offline
+drives to trusted and git-annex drop would only need to verify 1 copy is
+present on an online drive.
+
+What I do right now is use trusted for cold storage and never drop
+anything from it except in cases where I want to get rid of all copies of
+some file.
+"""]]
diff --git a/doc/forum/How_to_handle_the_git-annex_branch__63__.mdwn b/doc/forum/How_to_handle_the_git-annex_branch__63__.mdwn
new file mode 100644
index 0000000000..49c732e226
--- /dev/null
+++ b/doc/forum/How_to_handle_the_git-annex_branch__63__.mdwn
@@ -0,0 +1,5 @@
+Hi!
+
+When I update one repository to/from another, am I to push/pull only the master branch (and other branches I'd have created myself) or also the git-annex branch?
+
+From what I understand, the git-annex branch is local to one repository and has no interest in being merged in another, but some examples make use of git pull --all (which merges distant git-annex branch into local).
diff --git a/doc/forum/How_to_handle_the_git-annex_branch__63__/comment_1_800bd55b322e72f229882d7fd3888b14._comment b/doc/forum/How_to_handle_the_git-annex_branch__63__/comment_1_800bd55b322e72f229882d7fd3888b14._comment
new file mode 100644
index 0000000000..6c5a5144f3
--- /dev/null
+++ b/doc/forum/How_to_handle_the_git-annex_branch__63__/comment_1_800bd55b322e72f229882d7fd3888b14._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-04-10T16:05:40Z"
+ content="""
+The git-annex branch is how the annex information for the different repositories is communicated around, so yes, you need to push/pull it. 
+"""]]
diff --git a/doc/forum/How_to_hide_broken_symlinks.mdwn b/doc/forum/How_to_hide_broken_symlinks.mdwn
new file mode 100644
index 0000000000..7c92f32514
--- /dev/null
+++ b/doc/forum/How_to_hide_broken_symlinks.mdwn
@@ -0,0 +1,45 @@
+This is a method for hiding broken links using git-annex views.
+
+Each annex will need it's own name for this system to work. For this example I'll use "localdrive." After getting file content, run:
+
+    git-annex metadata --not --in=here --metadata in=localdrive . -s in-=localdrive
+    git-annex metadata --in=here --not --metadata in=localdrive . -s in+=localdrive
+    git-annex view /=*
+    git-annex vfilter in=localdrive
+
+Unused links will be hidden. Folder structures will remain the same.
+
+To switch back use:
+
+    git-annex vpop 2
+
+Because this is a lot to type, I've placed these in a bash script in the base folder (ignored with .gitignore so it isn't sent to other repos). The local repo name can be changed by editing THISREPO:
+
+    #!/bin/bash
+    
+    THISREPO='localdrive'
+    
+    git-annex metadata --not --in=here --metadata in=$THISREPO . -s in-=$THISREPO
+    git-annex metadata --in=here --not --metadata in=$THISREPO . -s in+=$THISREPO
+    git-annex view /=*
+    git-annex vfilter in=$THISREPO
+    
+    exit 0
+
+## Hiding Broken Links in Preferred Content Repos
+
+If you have a repo with preferred content settings, this can be shortened to a single script which can be run to "refresh" the view:
+
+    #!/bin/bash
+    
+    THISREPO='pcrepo'
+    
+    git-annex vpop 2
+    git-annex sync
+    git-annex get --auto
+    git-annex metadata --not --in=here --metadata in=$THISREPO . -s in-=$THISREPO
+    git-annex metadata --in=here --not --metadata in=$THISREPO . -s in+=$THISREPO
+    git-annex view /=*
+    git-annex vfilter in=$THISREPO
+    
+    exit 0
diff --git a/doc/forum/How_to_hide_broken_symlinks/comment_1_07a70090a9ac8f675233b08b24f55544._comment b/doc/forum/How_to_hide_broken_symlinks/comment_1_07a70090a9ac8f675233b08b24f55544._comment
new file mode 100644
index 0000000000..c4f55b85ba
--- /dev/null
+++ b/doc/forum/How_to_hide_broken_symlinks/comment_1_07a70090a9ac8f675233b08b24f55544._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-01-05T20:52:11Z"
+ content="""
+This works, but it's very inneficient. You're
+adding metadata (which is committed to git!) to represent location information. 
+git-annex already knows about location information,
+so it could just look at it and use it to build the view.
+
+The reason I haven't implemented this yet is I'm not clear about what to do
+if a file is dropped while in a view. It seems like git-annex should update
+the view to no longer show the dropped file. But this means that any change
+to a file's presence needs to update the view, and so it entangles the
+implementation of views with a core part of git-annex. And it might be
+pretty inneficient to need to build a new view branch each time a file is
+dropped too.
+
+With your hack, the view doesn't automatically update when a file is
+dropped. Since you're using it this way, maybe you have some advice or
+thoughts about this question?
+"""]]
diff --git a/doc/forum/How_to_hide_broken_symlinks/comment_2_011f6b97b1eaee1ae513a4a0e445d105._comment b/doc/forum/How_to_hide_broken_symlinks/comment_2_011f6b97b1eaee1ae513a4a0e445d105._comment
new file mode 100644
index 0000000000..21a1c9288d
--- /dev/null
+++ b/doc/forum/How_to_hide_broken_symlinks/comment_2_011f6b97b1eaee1ae513a4a0e445d105._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm_O5eskJUCHFrhtP9jm5atZQlBkxV3g9U"
+ nickname="Markus"
+ subject="comment 2"
+ date="2015-03-26T16:18:08Z"
+ content="""
+I thought about the same thing today.
+
+Well view aren't changing automatically when you change metadata, you'd have to re-create the view by leaving and entering.
+
+It would be great to have some \"internal metadata\" like if the file is present.
+"""]]
diff --git a/doc/forum/How_to_hide_broken_symlinks/comment_3_e3606aa746f516fc771d5d9bf93d70af._comment b/doc/forum/How_to_hide_broken_symlinks/comment_3_e3606aa746f516fc771d5d9bf93d70af._comment
new file mode 100644
index 0000000000..2103ec35e3
--- /dev/null
+++ b/doc/forum/How_to_hide_broken_symlinks/comment_3_e3606aa746f516fc771d5d9bf93d70af._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="GiovanniBiscuolo"
+ subject="Related forum post"
+ date="2015-04-23T11:03:39Z"
+ content="""
+[How do I hide files not present in the local annex?](http://git-annex.branchable.com/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/)
+"""]]
diff --git a/doc/forum/How_to_hide_broken_symlinks/comment_4_c6e3ef3ba5f6e9e54d998bcbe3035650._comment b/doc/forum/How_to_hide_broken_symlinks/comment_4_c6e3ef3ba5f6e9e54d998bcbe3035650._comment
new file mode 100644
index 0000000000..206333db73
--- /dev/null
+++ b/doc/forum/How_to_hide_broken_symlinks/comment_4_c6e3ef3ba5f6e9e54d998bcbe3035650._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnVnsqEy82M-MuS2gLri-az83wSQ6lXSrc"
+ nickname="Jean"
+ subject="comment 4"
+ date="2015-04-26T01:19:21Z"
+ content="""
+If a file is dropped while in a view, how about letting the relevant symlinks become broken until the view is refreshed?
+"""]]
diff --git a/doc/forum/How_to_hide_broken_symlinks/comment_5_1ed5e10e51078a0aa7e6968ef48687a3._comment b/doc/forum/How_to_hide_broken_symlinks/comment_5_1ed5e10e51078a0aa7e6968ef48687a3._comment
new file mode 100644
index 0000000000..bf55735a57
--- /dev/null
+++ b/doc/forum/How_to_hide_broken_symlinks/comment_5_1ed5e10e51078a0aa7e6968ef48687a3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-10-18T18:59:54Z"
+ content="""
+Good news everyone! `git annex adjust --hide-missing` sets up a branch
+where only files with content available are included. And once in such a
+branch, `git annex sync` updates it as necessary to reflect changes in
+content availability.
+"""]]
diff --git a/doc/forum/How_to_improve_performance_with_v6_repos__63__.mdwn b/doc/forum/How_to_improve_performance_with_v6_repos__63__.mdwn
new file mode 100644
index 0000000000..6a4f5e8cf5
--- /dev/null
+++ b/doc/forum/How_to_improve_performance_with_v6_repos__63__.mdwn
@@ -0,0 +1,3 @@
+I've been using git-annex to manage a repo of ~4000 files (an MP3 collection). I used to use direct mode, but switched to v6 and am using unlocked files instead. However, even small commits have been taking 10-20 minutes. Looking at `ps` output shows `git-annex smudge` processes running against all of the files in the repo, one by one.
+
+Is there any way I can speed things up?
diff --git a/doc/forum/How_to_improve_performance_with_v6_repos__63__/comment_1_56e0fead15a88ea12262e6091972c6d6._comment b/doc/forum/How_to_improve_performance_with_v6_repos__63__/comment_1_56e0fead15a88ea12262e6091972c6d6._comment
new file mode 100644
index 0000000000..c5f1866b13
--- /dev/null
+++ b/doc/forum/How_to_improve_performance_with_v6_repos__63__/comment_1_56e0fead15a88ea12262e6091972c6d6._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="page"
+ subject="Some additional notes"
+ date="2016-02-28T11:44:39Z"
+ content="""
+Just to add some info here. I just started using git-annex and v6 sounded like the way to go. I tried to add my photo collection (around 50k files) and all operations take a huge amount of time. I did 'git add photos/' (to add them in unlocked mode), which took hours. Then I run 'git annex sync', which took >10h again to do the commit. After that i run 'git annex sync' from another remote, and it's syncing items at ~2/s (smudge processes as the op mentions, not blocked either by cpu nor io). I'm not sure if I'm doing something wrong, but this is completely unusable for me. I'm all ears if I can try something, otherwise I'm gonna give v5 a try, I guess.
+"""]]
diff --git a/doc/forum/How_to_improve_performance_with_v6_repos__63__/comment_2_93a6a0779f52bdd3de6e4d2500cfd223._comment b/doc/forum/How_to_improve_performance_with_v6_repos__63__/comment_2_93a6a0779f52bdd3de6e4d2500cfd223._comment
new file mode 100644
index 0000000000..7e7d55028d
--- /dev/null
+++ b/doc/forum/How_to_improve_performance_with_v6_repos__63__/comment_2_93a6a0779f52bdd3de6e4d2500cfd223._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-07-06T18:57:15Z"
+ content="""
+This problem is dicussed in detail in [[todo/smudge]] and is the main
+reason that v6 mode is not production ready.
+
+I have patches to git that avoid this problem.
+"""]]
diff --git a/doc/forum/How_to_keep_connected_files_with_another__63__.mdwn b/doc/forum/How_to_keep_connected_files_with_another__63__.mdwn
new file mode 100644
index 0000000000..c1af975d9b
--- /dev/null
+++ b/doc/forum/How_to_keep_connected_files_with_another__63__.mdwn
@@ -0,0 +1,5 @@
+I've got a repo full of (legally aquired) Movies and series, most of which have corresponding metadata JSON and ASS subtitle files. When distributing them over many cold storage drives, I've noticed that git-annex would try to fill them up with many of the (much smaller) text files when there isn't enough space for another video file, leaving video and subtitles files on separate drives.
+
+This isn't a critical issue since there are still enough copies and everything but it'd be annoying to have to search for and connect two or more drives to get videos + subtitles for a single series. 
+
+I was wondering if there was perhaps a clever solution to prevent this from happening. Everything is organised into subfolders, so *ideally* I'd prefer if git-annex could be made to operate on full series (as defined by subdirectories or metadata perhaps?) instead of context-less files somehow.
diff --git a/doc/forum/How_to_keep_connected_files_with_another__63__/comment_1_89e04a7dc25a3df849aa2ada4dbc8439._comment b/doc/forum/How_to_keep_connected_files_with_another__63__/comment_1_89e04a7dc25a3df849aa2ada4dbc8439._comment
new file mode 100644
index 0000000000..e5c379bf61
--- /dev/null
+++ b/doc/forum/How_to_keep_connected_files_with_another__63__/comment_1_89e04a7dc25a3df849aa2ada4dbc8439._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-06-06T18:01:08Z"
+ content="""
+You could make the subtitles wanted in every repo so that all subtitles are present in every repo. Since they are small, the overhead shouldn't be large.
+
+Or you could directly add them to git (\"small files\") so they are also present everywhere. On a fresh repo, this would help a bit with speed too since git-annex then doesn't need to keep track of the location of these small files.
+
+Or (depending on how you configured your preferred content) you could increase numcopies just for the small files. See [[walkthrough/backups/]].
+
+Unfortunately, preferred-content can't directly relate multiple files with each other. git-annex iterates over each file in the tree and checks if preferred-content matches for that particular file.
+"""]]
diff --git a/doc/forum/How_to_keep_connected_files_with_another__63__/comment_2_20e8dba904eff7cc8f72ee12b8119632._comment b/doc/forum/How_to_keep_connected_files_with_another__63__/comment_2_20e8dba904eff7cc8f72ee12b8119632._comment
new file mode 100644
index 0000000000..f20e1db040
--- /dev/null
+++ b/doc/forum/How_to_keep_connected_files_with_another__63__/comment_2_20e8dba904eff7cc8f72ee12b8119632._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 2"
+ date="2021-06-06T20:47:31Z"
+ content="""
+> You could make the subtitles wanted in every repo so that all subtitles are present in every repo. Since they are small, the overhead shouldn't be large.
+
+This is probably what I'll end up doing.
+
+> Or you could directly add them to git (\"small files\") so they are also present everywhere.
+
+I do that for one type of metadata file that isn't important for consumption but I want everything else to be annex files so that I can assign metadata etc. to them.
+
+
+
+"""]]
diff --git a/doc/forum/How_to_keep_connected_files_with_another__63__/comment_3_7b14aa71a166cf14e852ae896b05ee74._comment b/doc/forum/How_to_keep_connected_files_with_another__63__/comment_3_7b14aa71a166cf14e852ae896b05ee74._comment
new file mode 100644
index 0000000000..2a7a65aebd
--- /dev/null
+++ b/doc/forum/How_to_keep_connected_files_with_another__63__/comment_3_7b14aa71a166cf14e852ae896b05ee74._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="specifying preferred content by metadata"
+ date="2021-06-07T14:26:27Z"
+ content="""
+>I'd prefer if git-annex could be made to operate on full series (as defined by subdirectories or metadata
+
+Maybe I'm missing something, but doesn't [[git-annex-preferred-content]] support `metadata=field=glob`?
+"""]]
diff --git a/doc/forum/How_to_keep_connected_files_with_another__63__/comment_4_a33437b28ea7fc74eb221d90efaec487._comment b/doc/forum/How_to_keep_connected_files_with_another__63__/comment_4_a33437b28ea7fc74eb221d90efaec487._comment
new file mode 100644
index 0000000000..73139ec723
--- /dev/null
+++ b/doc/forum/How_to_keep_connected_files_with_another__63__/comment_4_a33437b28ea7fc74eb221d90efaec487._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="keeping connected files together"
+ date="2021-06-07T14:45:35Z"
+ content="""
+One other option is to `tar` up each movie and all associated files into one archive, and annex that.
+
+There's a [special remote in DataLad](https://github.com/datalad/datalad/blob/master/datalad/customremotes/archives.py) for accessing individual files inside annexed archives, though I guess in your case you'd normally want all files anyway.
+"""]]
diff --git a/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository.mdwn b/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository.mdwn
new file mode 100644
index 0000000000..48ad2d1d83
--- /dev/null
+++ b/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository.mdwn
@@ -0,0 +1,3 @@
+I have git-annex set up with three clients and a transfer repository and everything was working fine, but a couple of days ago I noticed that git-annex was starting to upload to the transfer repository files that where already present on the three clients, and it hasn't stopped since. It's uploading all my files and I don't really know why.
+
+Is there a way to know why does git-annex think it needs to upload this files?
diff --git a/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment b/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment
new file mode 100644
index 0000000000..9cbe0939c8
--- /dev/null
+++ b/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.41"
+ subject="comment 1"
+ date="2014-03-26T17:46:30Z"
+ content="""
+A few likely reasons:
+
+* If a 4th client repository had popped up. 
+* If you have configured a high number of copies, it might only be able to be met by keeping files on the transfer repository.
+* Similarly, if a repository that used to have the files has been marked as dead or deleted, more copies might be needed to make up for that.
+* For completeness, if the transfer repository accidentally had its type changed to some other kind of repository, like a full backup.
+
+You can enable debugging (start with --debug or go into the webapp's preferences) and it might say a little more, but the debugging info is not very good.
+
+The best thing is probably to look at one single file, use `git annex whereis` on the file to see what repositories contain it, and then think about how that interacts with the [[preferred_content_expression_of_the_transfer_repository|preferred_content/standard_groups]].
+"""]]
diff --git a/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_2_e772ea0383ac690cbcbcf125258986cf._comment b/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_2_e772ea0383ac690cbcbcf125258986cf._comment
new file mode 100644
index 0000000000..27f158ea1e
--- /dev/null
+++ b/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_2_e772ea0383ac690cbcbcf125258986cf._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
+ nickname="Jon Ander"
+ subject="comment 2"
+ date="2014-04-01T08:01:00Z"
+ content="""
+I thought I had already checked all does possibilities, the repositories where in the correct group and no new repositories had been added. *git annex info* didn't show anything weird and nor did *git annex whereis*. I finally found out *git annex vicfg* and I found two new repositories with no name in the repository groups. It looked something like this:
+
+    # (for )
+    group repository-hash = client
+    # (for )
+    group repository-hash = client
+
+
+No idea of how they got there, but setting both of them to unwanted solved the issue.
+"""]]
diff --git a/doc/forum/How_to_list_all_existing_metadata_types__63__.mdwn b/doc/forum/How_to_list_all_existing_metadata_types__63__.mdwn
new file mode 100644
index 0000000000..43b3c1cfc1
--- /dev/null
+++ b/doc/forum/How_to_list_all_existing_metadata_types__63__.mdwn
@@ -0,0 +1,15 @@
+Is there any way to list all of the existing tag and metadata field types? What I mean is, I have files tagged with several different tags, files with several metadata fields; is there any way to list all the tag and field names being used (not all the files WITH those tags)?
+
+For example, something like:
+
+    git annex metadata --listfields
+    lastchanged
+    month
+    month-lastchanged
+    year
+    year-lastchanged
+
+    git annex metadata --listtags
+    Public
+    Personal
+    Work
diff --git a/doc/forum/How_to_list_all_existing_metadata_types__63__/comment_1_a8c30f697f32a3807661a59482d79b18._comment b/doc/forum/How_to_list_all_existing_metadata_types__63__/comment_1_a8c30f697f32a3807661a59482d79b18._comment
new file mode 100644
index 0000000000..3405ea4d6c
--- /dev/null
+++ b/doc/forum/How_to_list_all_existing_metadata_types__63__/comment_1_a8c30f697f32a3807661a59482d79b18._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-09T19:57:54Z"
+ content="""
+git-annex doesn't currently have a way to generate those lists itself, but you could use `git annex metadata --json` to get the metadata of all files, and pipe that json into a parser to get the data you want.
+
+The output could also be parsed in non-json mode. For example, this will list the tags:
+
+    git annex metadata  | grep '^  tag=' | cut -d '=' -f 2 | sort | uniq
+
+Although it's possible for metadata to contain newlines, and so parsing the json is a more reliable approach.
+
+Another nice way to see all the tags is to switch to a view of all tags:
+
+    git annex view 'tag=*'
+    ls
+"""]]
diff --git a/doc/forum/How_to_make_Maven_releases_work_with_git_annex___63__.mdwn b/doc/forum/How_to_make_Maven_releases_work_with_git_annex___63__.mdwn
new file mode 100644
index 0000000000..b39e69d7b5
--- /dev/null
+++ b/doc/forum/How_to_make_Maven_releases_work_with_git_annex___63__.mdwn
@@ -0,0 +1,5 @@
+Hi,
+
+In normal maven release procedure, it re-clones the gitrepo from the tag to do the release from either git or local file, But as git-annex uses symlinks when the repo is clones by maven, it misses the files. Any recommendations how i can make this work ? 
+
+Also would love some data on who is using git-annex in production environment would be good.
diff --git a/doc/forum/How_to_make_Maven_releases_work_with_git_annex___63__/comment_1_9298aa55771b68873de02e6a7964bbdc._comment b/doc/forum/How_to_make_Maven_releases_work_with_git_annex___63__/comment_1_9298aa55771b68873de02e6a7964bbdc._comment
new file mode 100644
index 0000000000..ca62bd43e0
--- /dev/null
+++ b/doc/forum/How_to_make_Maven_releases_work_with_git_annex___63__/comment_1_9298aa55771b68873de02e6a7964bbdc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 1"
+ date="2013-07-30T18:20:53Z"
+ content="""
+If you can find a way to run `git annex get` in the cloned repo, it will copy over the files. Perhaps there is some way to make Maven do that via a hook script or similar?
+"""]]
diff --git a/doc/forum/How_to_make_a_server_store_the_files.mdwn b/doc/forum/How_to_make_a_server_store_the_files.mdwn
new file mode 100644
index 0000000000..1af29381f2
--- /dev/null
+++ b/doc/forum/How_to_make_a_server_store_the_files.mdwn
@@ -0,0 +1 @@
+How can I make one of my servers keep a copy of the files on the server, so I can easily SFTP in and download the files. I don't want to see the .git folder, I want to see the files synced there.
diff --git a/doc/forum/How_to_make_a_server_store_the_files/comment_1_20196067475918e788afa0debc4d5ce5._comment b/doc/forum/How_to_make_a_server_store_the_files/comment_1_20196067475918e788afa0debc4d5ce5._comment
new file mode 100644
index 0000000000..e653881637
--- /dev/null
+++ b/doc/forum/How_to_make_a_server_store_the_files/comment_1_20196067475918e788afa0debc4d5ce5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-02T17:18:00Z"
+ content="""
+Make a non-bare git repository on the server, and make it have a git post-receive hook that runs 
+\"git annex merge\"
+"""]]
diff --git a/doc/forum/How_to_make_this_workflow_possible__63__.mdwn b/doc/forum/How_to_make_this_workflow_possible__63__.mdwn
new file mode 100644
index 0000000000..8295097714
--- /dev/null
+++ b/doc/forum/How_to_make_this_workflow_possible__63__.mdwn
@@ -0,0 +1,22 @@
+I have recently discovered git-annex and I'm interested in using it to manage my photo archive of about 10 years of raw photos. My existing workflow has worked well, but I'm trying to figure out how to automate it using git-annex. The archive is mirrored across 5-7 different external harddrives, each with a redundant copy of the entire archive (or as much as it can store since each drive capacity varies)
+
+Current workflow:
+
+1. Rename and organize photos on laptop
+2. Copy renamed photos to any two of the external harddrives
+  2a. if the two harddrives are out sync, resync the harddrives
+3. Use laptop as local cache for editing
+  3a. If photo is unavailable on laptop, plug in an external drive and create a local copy of desired photos.
+4. Resync laptop with external drives (this copies XMP sidecars to external harddrives and they will eventually propagate to other drives)
+
+I can get pretty close to this workflow git-annex except for one quirk.
+
+1. have a laptop repository in git-annex. Commit renamed raw photos in git-annex.
+2. Each harddrive have a git-annex repo and sync with laptop repo. The one caveat here is `git annex sync --content --no-pull` seems to ignore the no-pull option and tries to redownload all the raw files back to the laptop. How to do a one-way sync (laptop -> remote only with content)?
+3. XMP sidecars that are produced are tracked in regular git
+4. Try to sync with any available remote (this is the part I can't seem to figure out. I wish git-annex could be detect and try to to push to all available remotes instead me having to track which remotes are available). 
+`git annex [copy|move]` have the `--to=here` option which will copy/move files from remotes to local repo. It would be exceptionally useful to have a `--to=reachable` option to send files to any reachable remote instead of having to copy/moves to each remote individually.
+
+Things I need to figure out, but can't seem to grasp
+1. How to do a one-way sync? Or better yet, since each external drive needs to sync with any other reachable drive, can I exclude the laptop repo from the sync? The laptop repo is only a temporary staging area + local cache.
+2. If sync isn't the solution, how do move/copy to all reachable remotes instead of one-by-one?
diff --git a/doc/forum/How_to_make_this_workflow_possible__63__/comment_1_38d7c0531d68803b1d7910c598aab38c._comment b/doc/forum/How_to_make_this_workflow_possible__63__/comment_1_38d7c0531d68803b1d7910c598aab38c._comment
new file mode 100644
index 0000000000..1b0cf01f60
--- /dev/null
+++ b/doc/forum/How_to_make_this_workflow_possible__63__/comment_1_38d7c0531d68803b1d7910c598aab38c._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 1"
+ date="2022-06-22T12:24:21Z"
+ content="""
+> The one caveat here is `git annex sync --content --no-pull` seems to ignore the no-pull option and tries to redownload all the raw files back to the laptop. How to do a one-way sync (laptop -> remote only with content)?
+
+AFAICT, pull only concerns `git` actions, not `git-annex` actions like transferring content.
+
+What your laptop's repo tries to copy depends on what content it wants and numcopies.  
+
+The latter probably isn't your problem since you should have at least 2 copies of everything distributed over the drives.  
+The former should ideally be solved with a proper customised groups setup but you can also set a wanted expression or use the built-in groups which is probably your best option. Your laptop's repo should be set to `client` or `manual`.
+
+See https://git-annex.branchable.com/git-annex-preferred-content/ and https://git-annex.branchable.com/preferred_content/standard_groups/
+
+> XMP sidecars that are produced are tracked in regular git
+
+Have you set `annex.largefiles` to anything? 
+
+Sidecar files are just XML AFAICT, so a filter that would only add files with binary mimeencoding to annex would exclude these and add them to regular git.
+
+If you haven't touched that setting (double check with `git config`), that's a bug.
+
+> Try to sync with any available remote (this is the part I can't seem to figure out. I wish git-annex could be detect and try to to push to all available remotes instead me having to track which remotes are available). 
+> `git annex [copy|move]` have the `--to=here` option which will copy/move files from remotes to local repo. It would be exceptionally useful to have a `--to=reachable` option to send files to any reachable remote instead of having to copy/moves to each remote individually.
+
+By default, sync syncs with *all* available remotes. 
+
+How exactly are your repo's remotes set up?
+
+What does it to when syncing that you don't want it to?
+
+"""]]
diff --git a/doc/forum/How_to_mv_file___40__symlink__41___to_another_dir_in_the_same_repo_without_unlocking_it.mdwn b/doc/forum/How_to_mv_file___40__symlink__41___to_another_dir_in_the_same_repo_without_unlocking_it.mdwn
new file mode 100644
index 0000000000..a9de67337c
--- /dev/null
+++ b/doc/forum/How_to_mv_file___40__symlink__41___to_another_dir_in_the_same_repo_without_unlocking_it.mdwn
@@ -0,0 +1 @@
+This could be useful for restructuring the dir structures.
diff --git a/doc/forum/How_to_mv_file___40__symlink__41___to_another_dir_in_the_same_repo_without_unlocking_it/comment_1_a272d179a77682e8c64bd4fc20cddee0._comment b/doc/forum/How_to_mv_file___40__symlink__41___to_another_dir_in_the_same_repo_without_unlocking_it/comment_1_a272d179a77682e8c64bd4fc20cddee0._comment
new file mode 100644
index 0000000000..645205f190
--- /dev/null
+++ b/doc/forum/How_to_mv_file___40__symlink__41___to_another_dir_in_the_same_repo_without_unlocking_it/comment_1_a272d179a77682e8c64bd4fc20cddee0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2019-01-14T12:36:04Z"
+ content="""
+You can just move it with any file manager or `git mv`.
+
+git-annex will fix the moved symlink before it is committed.
+"""]]
diff --git a/doc/forum/How_to_organise_backup_to_S3__63__.mdwn b/doc/forum/How_to_organise_backup_to_S3__63__.mdwn
new file mode 100644
index 0000000000..25ead06aae
--- /dev/null
+++ b/doc/forum/How_to_organise_backup_to_S3__63__.mdwn
@@ -0,0 +1,10 @@
+Hello,
+
+what is the best way to use git-annex as a backup tool to S3? As far as I know, even if all data is copied to S3, I need a checkout of the git repo, correct? And of course the private key used.
+
+- Is there a way to also save the repository data to S3? To have something like ```git annex restore-from-external-remote ...```
+
+- If not, how do you organise the backup so that it is disaster proof? Upload the repo to some other external server regularly?
+
+Thanks,
+Florian
diff --git a/doc/forum/How_to_organise_backup_to_S3__63__/comment_1_13c6421a3637e30193dc77b54dec4b8d._comment b/doc/forum/How_to_organise_backup_to_S3__63__/comment_1_13c6421a3637e30193dc77b54dec4b8d._comment
new file mode 100644
index 0000000000..0679b05d7d
--- /dev/null
+++ b/doc/forum/How_to_organise_backup_to_S3__63__/comment_1_13c6421a3637e30193dc77b54dec4b8d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-12-05T17:30:31Z"
+ content="""
+You can use any git addon that allows git repositories to be pushed to S3
+to store your git repository there, and then everything is on S3. 
+
+Or yes, you can push the git repository to any other git hosting provider
+you want to, to back it up.
+"""]]
diff --git a/doc/forum/How_to_organise_backup_to_S3__63__/comment_2_e0ae05276ef7e1dcb21ef0986b6f7531._comment b/doc/forum/How_to_organise_backup_to_S3__63__/comment_2_e0ae05276ef7e1dcb21ef0986b6f7531._comment
new file mode 100644
index 0000000000..e176eababe
--- /dev/null
+++ b/doc/forum/How_to_organise_backup_to_S3__63__/comment_2_e0ae05276ef7e1dcb21ef0986b6f7531._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Horus"
+ avatar="http://cdn.libravatar.org/avatar/8f0ee08b98ea5bba76c3fe112c08851c"
+ subject="comment 2"
+ date="2017-12-06T11:45:33Z"
+ content="""
+Hi,
+
+thanks for your reply. The repo server I used to store just the repository does not need to have git-annex installed, correct? As long as I do not intend to use it for exchanging files... 
+
+This message can be ignored?
+
+    Remote xgm does not have git-annex installed; setting annex-ignore
+
+    This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote xgm
+"""]]
diff --git a/doc/forum/How_to_organise_backup_to_S3__63__/comment_3_7697112a04cdc9a53551257d71143eb5._comment b/doc/forum/How_to_organise_backup_to_S3__63__/comment_3_7697112a04cdc9a53551257d71143eb5._comment
new file mode 100644
index 0000000000..5c30dc647e
--- /dev/null
+++ b/doc/forum/How_to_organise_backup_to_S3__63__/comment_3_7697112a04cdc9a53551257d71143eb5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-12-08T19:35:51Z"
+ content="""
+Right, you've split the cloud storage into annex and git parts, so it's
+fine for the git part to not support annex then.
+"""]]
diff --git a/doc/forum/How_to_overwrite_local_changes__63__.mdwn b/doc/forum/How_to_overwrite_local_changes__63__.mdwn
new file mode 100644
index 0000000000..904bc086be
--- /dev/null
+++ b/doc/forum/How_to_overwrite_local_changes__63__.mdwn
@@ -0,0 +1,7 @@
+Hello,
+
+I have a repo Desktop (client), a repo Server (transfer) and a repo Notebook (Client). Usually first thing I do in the morning is go git annex sync --content the changes to the laptop. Today I accidently modified some files on the laptop before I synced. After I syncing I know have some files foo.variant-afd1 and foo.variant-a6d3 with which I don't know what to do.
+
+How can I discard local changes and copy all changes from the transfer repo to the laptop? Local changes should be overwritten.
+
+Thanks!
diff --git a/doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment b/doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment
new file mode 100644
index 0000000000..05dbbed761
--- /dev/null
+++ b/doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-06T18:51:43Z"
+ content="""
+Sorry that nobody answered your question until now..
+
+These .variant files preserve both versions of the files that were
+committed in the two different repositories. If you can identify which
+variant you don't want, you can just delete that one, and rename the other
+.variant file back to the original file name.
+
+There's no really great way to tell which variant is which. 
+I'd look at the contents of the variants of the file, unless there are
+too many files to look at.
+
+Another approach is to look at the git log, find the commit that merged
+the unwanted changed (and created these variant files), and `git revert` that
+merge, and the earlier commit that was made accidentally.
+"""]]
diff --git a/doc/forum/How_to_play_a_video_from_WSL2_on_Windows_VLC.mdwn b/doc/forum/How_to_play_a_video_from_WSL2_on_Windows_VLC.mdwn
new file mode 100644
index 0000000000..8fee5a4f03
--- /dev/null
+++ b/doc/forum/How_to_play_a_video_from_WSL2_on_Windows_VLC.mdwn
@@ -0,0 +1,17 @@
+I was trying to check out the videos in the downloads repository associated with this project, but I don't know how to get them to play.
+
+In WSL2, I ran:
+
+```
+git clone https://downloads.kitenet.net/.git
+cd downloads.kitenet.net
+git annex get ./videos/git-annex/git-annex-assistant-intro.mp4
+```
+
+The download was successful, but trying to play the video using VLC on Windows resulted in the following error:
+
+```
+VLC is unable to open the MRL 'file://wsl.localhost/Ubuntu-20.04/home/username/annex/downloads.kitenet.net/videos/git-annex/git-annex-assistant-intro.mp4'.
+```
+
+I suppose this is because VLC doesn't know what to do with the symlink, but I don't know how to deal with the problem.
diff --git a/doc/forum/How_to_play_a_video_from_WSL2_on_Windows_VLC/comment_1_4b2b04e4cd61d08dfa44b2cc86023ba2._comment b/doc/forum/How_to_play_a_video_from_WSL2_on_Windows_VLC/comment_1_4b2b04e4cd61d08dfa44b2cc86023ba2._comment
new file mode 100644
index 0000000000..2c8807fc3e
--- /dev/null
+++ b/doc/forum/How_to_play_a_video_from_WSL2_on_Windows_VLC/comment_1_4b2b04e4cd61d08dfa44b2cc86023ba2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-01-16T19:14:09Z"
+ content="""
+I suppose you could use: `git-annex adjust --unlock` 
+
+Those videos can just be streamed from the web in any case.
+<https://downloads.kitenet.net/videos/git-annex/>
+"""]]
diff --git a/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks.mdwn b/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks.mdwn
new file mode 100644
index 0000000000..403e2cafa5
--- /dev/null
+++ b/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks.mdwn
@@ -0,0 +1,13 @@
+Hi,
+
+Thank you very much for this software. I'm working in a research institute and we are very interested into using git-annex with DataLad to manage our datasets.
+
+We aim to provide a datasets repository accessible through the local network on a single file system. Some of our datasets are multi TB with a few millions of files. It will be managed by a few people but the primary users, the researchers, will only have read access. We would like to use hardlinks everywhere to avoid infrequent reading errors related to symlinks and save space when we want to propose different versions of the datasets with slight changes. The file system will be backed-up so we don't really need multi copies of the same files on a single file system.
+
+We seam to be able to achieve this using the `direct` mode in git-annex version 5 but it seams that the `unlock` mode in version 7 does copies instead of hardlinks. I'm wondering how we could achieve the same behaviour as in version 5. I believe I've read in the doc that there's a maximum of 2 hardlinks for a single file but I can't remember where or see if that is still the case. If that is still the case, I couldn't find if there is a setting to set or remove this maximum.
+
+We've tested with git-annex local version 5 / build 7.20190819, local version 7 / build 7.20190819 and local version 7 / build 7.20191106. [Here is a gist](https://gist.github.com/satyaog/b08a6e5d1eee75217ba823d38b84fb8b) containing test scripts for each setup. The `.annex-cache` part can be ignored for this topic. I've used Miniconda3-4.3.30 on Ubuntu 18.04.2 LTS to setup the environments.
+
+Thank you,
+
+Satya
diff --git a/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_1_b59a72142e8f752d7b68a63a6ac1bbfe._comment b/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_1_b59a72142e8f752d7b68a63a6ac1bbfe._comment
new file mode 100644
index 0000000000..d341a02d36
--- /dev/null
+++ b/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_1_b59a72142e8f752d7b68a63a6ac1bbfe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="using hardlinks"
+ date="2019-11-18T19:21:18Z"
+ content="""
+I don't have a full answer, but [[tips/local_caching_of_annexed_files]] might have relevant info.
+
+There is also the `annex.thin` setting; but check some [caveats](https://git-annex.branchable.com/bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data/) related to it.
+"""]]
diff --git a/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_2_e4bfea21f664a0cb1aa8ec18ee88fc50._comment b/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_2_e4bfea21f664a0cb1aa8ec18ee88fc50._comment
new file mode 100644
index 0000000000..359626b214
--- /dev/null
+++ b/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_2_e4bfea21f664a0cb1aa8ec18ee88fc50._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="satya.ortiz-gagne@a4c92de91eb4fd5ae8fc9893bb4fd674a19f2e59"
+ nickname="satya.ortiz-gagne"
+ avatar="http://cdn.libravatar.org/avatar/79c93025f174cd2aff98fbb952702c09"
+ subject="Re: using hardlinks"
+ date="2019-11-18T20:46:22Z"
+ content="""
+Thanks for your comment. I've looked into [local caching of annexed files](https://git-annex.branchable.com/tips/local_caching_of_annexed_files) and most of it can be found in the scenario [described in the test gist](https://gist.github.com/satyaog/b08a6e5d1eee75217ba823d38b84fb8b).
+
+The two settings `annex.thin` and `annex.hardlink` are also set in the two git-annex repositories of the test. Thanks for letting me know about the caveats. Based on the tests that I've executed, it would seam that [`git-annex unlock`](https://git-annex.branchable.com/git-annex-unlock/) now copies the file to avoid the mentioned issue as I noticed different inodes? I understand that this prevents unwanted lost of data while using git-annex but I would actually like to have a hardlink instead of a copy. I'm wondering if it's possible.
+"""]]
diff --git a/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_3_ee247d9316df963fd584df2199b80fe2._comment b/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_3_ee247d9316df963fd584df2199b80fe2._comment
new file mode 100644
index 0000000000..d272eb88a1
--- /dev/null
+++ b/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_3_ee247d9316df963fd584df2199b80fe2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="using hardlinks"
+ date="2019-11-19T17:51:08Z"
+ content="""
+I again don't have a full answer, but maybe you could customize git's [post-checkout hook](https://git-scm.com/docs/githooks#_post_checkout)?  (You'd need to still call the hook that git-annex installs.)
+
+Also, I've thrown together a [[FUSE filesystem|https://github.com/broadinstitute/viral-ngs/blob/is-dx-benchmarks/tools/git-annex-remotes/git-annex-on-demand.py]] that fetches git-annexed files on demand, maybe that could be adapted.  It only works with locked files and symlinks though.
+
+What is the reason you don't want to use locked files?   You can have different [[worktrees|tips/Using_git-worktree_with_annex]] with symlinks of locked files pointing into the same annex.
+"""]]
diff --git a/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_4_51548724d72e2cc6cb2c6e8c3b82e3e4._comment b/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_4_51548724d72e2cc6cb2c6e8c3b82e3e4._comment
new file mode 100644
index 0000000000..b75702da37
--- /dev/null
+++ b/doc/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/comment_4_51548724d72e2cc6cb2c6e8c3b82e3e4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="satya.ortiz-gagne@a4c92de91eb4fd5ae8fc9893bb4fd674a19f2e59"
+ nickname="satya.ortiz-gagne"
+ avatar="http://cdn.libravatar.org/avatar/79c93025f174cd2aff98fbb952702c09"
+ subject="using hardlinks"
+ date="2020-01-10T16:11:47Z"
+ content="""
+Thanks for your help. Yes I believe that post-checkout hook could do the trick but I really like your idea of using a FUSE filesystem. Thanks a lot for sharing. I also believe this could be the base to progressively get the content of an indexed archive (like .zip) as it's getting needed.
+
+The worktree is a very interesting feature but I'm also using [DataLad 0.11.8](https://www.datalad.org/) which is unfortunately incompatible with it for the moment.
+
+As for my objective to not use locked files, I initially though that the script of a library I was using to preprocess some data was failing because of the fact the files were symlinks but I couldn't reproduce. Unfortunately, too many factor changed so I'm just going to assume I was doing something wrong. Still, it would sometimes be useful to work with unlocked files in the case I'm doing a multi-phases (with multi-commits) preprocessing of a big file. In that case, a phase would modify the file, trigger a copy by unlocking it and annex the modified file. I would be interested into skipping the copy to save a significant amount of time and space since the intermediate states of the file are only temporary. The checksums are still interesting to make sure the phase correctly executed. But that is very specific and will not happen too often so I'm fine with workarounds.
+"""]]
diff --git a/doc/forum/How_to_prevent_the_assistant_from_downloading_all_data__63__.mdwn b/doc/forum/How_to_prevent_the_assistant_from_downloading_all_data__63__.mdwn
new file mode 100644
index 0000000000..1b1ddff469
--- /dev/null
+++ b/doc/forum/How_to_prevent_the_assistant_from_downloading_all_data__63__.mdwn
@@ -0,0 +1,9 @@
+I have a repository on my laptop with a single remote on a USB drive. Both were created without the assistant.
+
+The remote holds all the content. My understanding is that this would be a "backup" repository, using the group definitions.
+
+The local repository generally holds no content. When I want a file, I make sure the remote is available, and then I `git annex get` it.
+
+This works fine in git annex, but I'm now experimenting with the assistant. As soon as I fire up the assistant, it starts downloading all of the data from the remote. I don't ever want it to automatically get any content from the remote. If it sees new content in the repository, I would like it to push that out to the remote. But never get anything from the remote, and never drop anything that is in the repository.
+
+How can I setup this behaviour in the assistant? I have set the remote's repository group to "backup". The local repository is not in any group, since none of the groups fit my model for this repo.
diff --git a/doc/forum/How_to_prevent_the_assistant_from_downloading_all_data__63__/comment_1_fd8b287758ad77b3527ae71017cffabf._comment b/doc/forum/How_to_prevent_the_assistant_from_downloading_all_data__63__/comment_1_fd8b287758ad77b3527ae71017cffabf._comment
new file mode 100644
index 0000000000..326158d95a
--- /dev/null
+++ b/doc/forum/How_to_prevent_the_assistant_from_downloading_all_data__63__/comment_1_fd8b287758ad77b3527ae71017cffabf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 1"
+ date="2013-01-20T08:11:37Z"
+ content="""
+Run 'git annex vicfg', locate the preferred content setting for your repository, uncomment it and set it to 'present'. Then it shouldn't move content automatically.
+"""]]
diff --git a/doc/forum/How_to_prevent_the_assistant_from_downloading_all_data__63__/comment_2_e8e75b4451aaf55461edf2f3d68797ed._comment b/doc/forum/How_to_prevent_the_assistant_from_downloading_all_data__63__/comment_2_e8e75b4451aaf55461edf2f3d68797ed._comment
new file mode 100644
index 0000000000..790567ecaa
--- /dev/null
+++ b/doc/forum/How_to_prevent_the_assistant_from_downloading_all_data__63__/comment_2_e8e75b4451aaf55461edf2f3d68797ed._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 2"
+ date="2013-01-24T02:01:00Z"
+ content="""
+A recent commit allows you to just choose \"manual mode\" in the webapp to get the same effect.
+"""]]
diff --git a/doc/forum/How_to_recover_from_failed_branch_updates__63__.mdwn b/doc/forum/How_to_recover_from_failed_branch_updates__63__.mdwn
new file mode 100644
index 0000000000..6a227a99d3
--- /dev/null
+++ b/doc/forum/How_to_recover_from_failed_branch_updates__63__.mdwn
@@ -0,0 +1,28 @@
+Due to the issue reported in [[bugs/Failed_adjusted_branch_update_after_error_in_drop]], my git-annex repo is now is a limbo state:
+
+
+```
+$ git branch --show-current
+adjusted/master(unlockpresent)
+
+$ git annex drop dirF/
+drop dirF/a/a1.txt ok
+drop dirF/a/a2.txt ok
+[...]
+error: Your local changes to the following files would be overwritten by checkout:
+    dirF/a/a1.txt
+    dirF/a/a2.txt
+    [...]
+
+Aborting
+
+  Updating adjusted branch failed.
+(recording state in git...)
+$ git status
+HEAD detached at 9d92415fb
+nothing to commit, working tree clean
+```
+
+What is the recommended course of action to (safely) return to the `adjusted/master(unlockpresent)` branch?
+
+Is it safe to just use `git annex adjust --unlock-present`?
diff --git a/doc/forum/How_to_recover_from_failed_branch_updates__63__/comment_1_f296d4870a6fdef5c57bc8bb1a1e0474._comment b/doc/forum/How_to_recover_from_failed_branch_updates__63__/comment_1_f296d4870a6fdef5c57bc8bb1a1e0474._comment
new file mode 100644
index 0000000000..ed6f496d2d
--- /dev/null
+++ b/doc/forum/How_to_recover_from_failed_branch_updates__63__/comment_1_f296d4870a6fdef5c57bc8bb1a1e0474._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-23T19:30:12Z"
+ content="""
+You can just run "git checkout adjusted/master(unlockpresent)"
+to switch back to that branch. 
+
+It's fine to switch between adjusted and other branches, though the way git-annex
+failed and left your head detached is certainly a bug.
+"""]]
diff --git a/doc/forum/How_to_recover_from_failed_branch_updates__63__/comment_2_0edc7239488f78345f9e624ef210ebac._comment b/doc/forum/How_to_recover_from_failed_branch_updates__63__/comment_2_0edc7239488f78345f9e624ef210ebac._comment
new file mode 100644
index 0000000000..252e2f7c2e
--- /dev/null
+++ b/doc/forum/How_to_recover_from_failed_branch_updates__63__/comment_2_0edc7239488f78345f9e624ef210ebac._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="gioele@678b7c03f524f2669b179b603f65352fcc16774e"
+ nickname="gioele"
+ avatar="http://cdn.libravatar.org/avatar/366dbda84e78aff8a8a070622aeb63ce"
+ subject="comment 2"
+ date="2023-03-31T20:16:04Z"
+ content="""
+Thanks!
+
+For the record, this is what git will say after `git checkout \"adjusted/master(unlockpresent)\"`
+
+```
+Warning: you are leaving 1 commit behind, not connected to
+any of your branches:
+
+  9d92415fb git-annex adjusted branch
+
+If you want to keep it by creating a new branch, this may be a good time
+to do so with:
+
+ git branch <new-branch-name> 9d92415fb
+
+Switched to branch 'adjusted/master(unlockpresent)'
+```
+"""]]
diff --git a/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__.mdwn b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__.mdwn
new file mode 100644
index 0000000000..8dc580b9b3
--- /dev/null
+++ b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__.mdwn
@@ -0,0 +1,11 @@
+I am investigating how to create special remotes using the library  Lykos153 / AnnexRemote. I have copied [this file](https://github.com/Lykos153/AnnexRemote/blob/master/examples/git-annex-remote-directory) locally, renamed it, set it up as needed, but can not initialise a remote with it. 
+
+I get this:
+
+    git annex initremote foo type=external externaltype=precomp encryption=none directory=/z/old/1111   
+    initremote foo 
+    git-annex: Unexpected parameters: directory
+    failed
+    git-annex: initremote: 1 failed
+
+The order of the arguments make no difference. Do I need to somehow register parameters now, that was not required before? Or something else?
diff --git a/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_1_6dd92d0737b72b927fc6b82636084c54._comment b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_1_6dd92d0737b72b927fc6b82636084c54._comment
new file mode 100644
index 0000000000..6004dd0abe
--- /dev/null
+++ b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_1_6dd92d0737b72b927fc6b82636084c54._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-07-22T15:07:06Z"
+ content="""
+This should only happen if your program is responding to LISTCONFIGS
+with a list that does not include that parameter.
+
+If it responds with UNSUPPORTED-REQUEST, all configs will be allowed.
+
+I'm not familiar with the python library, but I guess it is doing that, and
+probably has a way to specify what configs to list.
+"""]]
diff --git a/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_2_789445dff9a5905ed105ac344f6949ad._comment b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_2_789445dff9a5905ed105ac344f6949ad._comment
new file mode 100644
index 0000000000..e32342de19
--- /dev/null
+++ b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_2_789445dff9a5905ed105ac344f6949ad._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="Improperly documented code."
+ date="2020-08-06T02:52:50Z"
+ content="""
+I found out how to do it after reading his source code for the [Google Drive remote](github.com/Lykos153/git-annex-remote-gdrive).
+
+Feel free to have a look around my remotes <github.com/cardoso-neto/git-annex-remote-manytars> <github.com/cardoso-neto/git-annex-remote-manyzips> which use his [helper module](github.com/Lykos153/AnnexRemote).
+
+To summarize it, you should override __init__ and list your configs there.
+"""]]
diff --git a/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_3_93e91e2ab98c35d4cb6082eea01b6abc._comment b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_3_93e91e2ab98c35d4cb6082eea01b6abc._comment
new file mode 100644
index 0000000000..6e53f06e23
--- /dev/null
+++ b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_3_93e91e2ab98c35d4cb6082eea01b6abc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="Correction."
+ date="2020-08-06T03:09:12Z"
+ content="""
+I meant this Google Drive remote: <github.com/Lykos153/git-annex-remote-googledrive> not the gdrive one that was discontinued.
+"""]]
diff --git a/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_4_64c0d3c061ff463f9ce16b52d2a70a1f._comment b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_4_64c0d3c061ff463f9ce16b52d2a70a1f._comment
new file mode 100644
index 0000000000..61300bb843
--- /dev/null
+++ b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_4_64c0d3c061ff463f9ce16b52d2a70a1f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="Fixing URLs."
+ date="2020-08-06T03:14:57Z"
+ content="""
+Apparently none of them worked, so here they are again:
+
+[github/Lykos153/git-annex-remote-googledrive](https://github.com/Lykos153/git-annex-remote-googledrive)
+
+[github/cardoso-neto/git-annex-remote-manytars](https://github.com/cardoso-neto/git-annex-remote-manytars)
+
+[github/cardoso-neto/git-annex-remote-manyzips](https://github.com/cardoso-neto/git-annex-remote-manyzips)
+
+[github/Lykos153/AnnexRemote](https://github.com/Lykos153/AnnexRemote)
+"""]]
diff --git a/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_5_d1c47c1a2f9b4dd570c0ebd9fbd1ad8b._comment b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_5_d1c47c1a2f9b4dd570c0ebd9fbd1ad8b._comment
new file mode 100644
index 0000000000..8f09bbd5fa
--- /dev/null
+++ b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_5_d1c47c1a2f9b4dd570c0ebd9fbd1ad8b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-08-06T17:53:39Z"
+ content="""
+These are some interesting special remotes. I don't know how general the
+use case for them is (and I wonder if something like bup or ddar meets the
+same basic use case), but it seems perhaps worth including them in the big
+list of special remotes. What do you think?
+"""]]
diff --git a/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_6_e0753fef2b93ae5a114894dbdc014ec4._comment b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_6_e0753fef2b93ae5a114894dbdc014ec4._comment
new file mode 100644
index 0000000000..2e55cae22f
--- /dev/null
+++ b/doc/forum/How_to_register_arguments_for_an_external_special_remote__63__/comment_6_e0753fef2b93ae5a114894dbdc014ec4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="omg"
+ date="2020-08-07T02:41:10Z"
+ content="""
+This feels like such an honor. hahah
+
+I would absolutely love that.
+
+Just give me a few days to get it working with `pip` (so people don't have to mess around with their $PATH), document it better, and run `git annex testremote` a bazillion times on it.
+
+Thank you for being awesome, Joey, and writing this awesome tool.
+"""]]
diff --git a/doc/forum/How_to_remove_annex_on_osx__63__.mdwn b/doc/forum/How_to_remove_annex_on_osx__63__.mdwn
new file mode 100644
index 0000000000..b142e3f21c
--- /dev/null
+++ b/doc/forum/How_to_remove_annex_on_osx__63__.mdwn
@@ -0,0 +1,5 @@
+I tried to remove git annex and it seems to have completely broken my git. Anytime I try to clone it says:
+
+-bash: /Applications/git-annex.app/Contents/MacOS/git: No such file or directory
+
+How do I fix?
diff --git a/doc/forum/How_to_remove_annex_on_osx__63__/comment_1_18fc46bdb5bc44916e355a9900e9c0d1._comment b/doc/forum/How_to_remove_annex_on_osx__63__/comment_1_18fc46bdb5bc44916e355a9900e9c0d1._comment
new file mode 100644
index 0000000000..2f26998c43
--- /dev/null
+++ b/doc/forum/How_to_remove_annex_on_osx__63__/comment_1_18fc46bdb5bc44916e355a9900e9c0d1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-12-08T16:43:07Z"
+ content="""
+`git-annex` for mac comes with a bundled version of git usually located at `/Applications/git-annex.app/Contents/MacOS/git`.  It looks like some application you are using found that location of git and decided to use it. When you deleted the git-annex.app directory your app could no longer find git there. **Are you getting this error message from the Github Desktop app?**
+
+Most likely you just need to install a standalone version of git (if you have never done that) from <https://git-scm.com/> or Homebrew if you are into that, or if you use Github Desktop just go to `Github Desktop > Install Command Line Tool…`. You could also check to make sure you don't have some hardcoded alias for git setup in `~/.bash_profile`, but that seems unlikely.
+"""]]
diff --git a/doc/forum/How_to_rename_a_remote__63__.mdwn b/doc/forum/How_to_rename_a_remote__63__.mdwn
new file mode 100644
index 0000000000..be2355a079
--- /dev/null
+++ b/doc/forum/How_to_rename_a_remote__63__.mdwn
@@ -0,0 +1 @@
+I recently created WebDAV remote to my annex which I assumed to be just for testing purposes at the time, so I gave it a strange and long-wided name. It turned out, though, that the remote is stable, works fine, and that I'm going to keep it. Now, I would like to give it a snappier and more descriptive name than the one I originally chose. Is that possible somehow?
diff --git a/doc/forum/How_to_rename_a_remote__63__/comment_1_a9bfbd82f7bb47661f0d9e0e0d904332._comment b/doc/forum/How_to_rename_a_remote__63__/comment_1_a9bfbd82f7bb47661f0d9e0e0d904332._comment
new file mode 100644
index 0000000000..31f44c8f6f
--- /dev/null
+++ b/doc/forum/How_to_rename_a_remote__63__/comment_1_a9bfbd82f7bb47661f0d9e0e0d904332._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.194"
+ subject="comment 1"
+ date="2013-01-18T18:20:43Z"
+ content="""
+You can rename a git remote with just \"git remote rename <old> <new>\". However, for a special remote, git-remote will fail to rename it unless you first add a dummy remote.<name>.fetch value in .git/config. You can remove it later.
+
+So, for example:
+
+<pre>
+git config remote.$uglyname.fetch dummy
+git remote rename $uglyname $nicename
+git config remote.$nicename.fetch \"\"
+</pre>
+
+(The webapp handles doing this when you edit a remote's name, BTW.)
+
+---
+
+There's actually another place the name of a special remote is recorded, in `remote.log`. That name is only used when you use `git annex initremote` though. It actually is possible to change it, by using `initremote` to change the vale of the name field. Example:
+
+<pre>
+git annex initremote $uglyname name=$newname
+</pre>
+
+Note that for some types of special remotes, this will require you to re-specify some other configuration. For example, with a directory special remote, it wanted me to include a directory= parameter.
+"""]]
diff --git a/doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__.mdwn b/doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__.mdwn
new file mode 100644
index 0000000000..a21d6d6d29
--- /dev/null
+++ b/doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__.mdwn
@@ -0,0 +1,65 @@
+I have just done a sync in a direct mode repo:
+
+    git-annex sync sshremote
+
+It has quite a few conflicts (both sides adding the same file with same content). But somehow the merge won't conclude. Here's some log:
+
+    $ git-annex sync sshremote
+    commit  ok
+    pull sshremote 
+    warning: no common commits
+    remote: Counting objects: 32162, done.
+    remote: Compressing objects: 100% (31192/31192), done.
+    remote: Total 32162 (delta 3), reused 32162 (delta 3)
+    Receiving objects: 100% (32162/32162), 3.39 MiB | 1.61 MiB/s, done.
+    Resolving deltas: 100% (3/3), done.
+    From sshremote:/repo
+     * [new branch]      annex/direct/master -> sshremote/annex/direct/master
+     * [new branch]      git-annex  -> sshremote/git-annex
+     * [new branch]      master     -> sshremote/master
+     * [new branch]      synced/master -> sshremote/synced/master
+
+    Auto-merging file1
+    CONFLICT (add/add): Merge conflict in file1
+    Auto-merging file2
+    CONFLICT (add/add): Merge conflict in file2
+    Auto-merging file3
+    CONFLICT (add/add): Merge conflict in file3
+    Auto-merging file4
+    CONFLICT (add/add): Merge conflict in file4
+    Automatic merge failed; fix conflicts and then commit the result.
+    file1: needs merge
+    file2: needs merge
+    file3: needs merge
+    file4: needs merge
+    ^C
+
+I waited for a few minutes, and checked that both cpu and disk activity is near zero on both server. So I interrupted it, thinking it might be some locking issue. 
+
+But now I cannot sync with the remote anymore because the merge is still in process. How should I resolve the conflicts? I could do it manually if I cannot use annex's auto merge.
+
+    $ git-annex sync sshremote
+    commit  ok
+    pull sshremote 
+
+    fatal: You have not concluded your merge (MERGE_HEAD exists).
+    Please, commit your changes before you can merge.
+
+    fatal: You have not concluded your merge (MERGE_HEAD exists).
+    Please, commit your changes before you can merge.
+    failed
+
+    $ git merge --abort
+    fatal: This operation must be run in a work tree
+
+Update: this is running on OSX with:
+
+    git-annex version: 5.20131221-g00d1673
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav glacier hook
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3 5
+    upgrade supported from repository versions: 0 1 2 4
+
diff --git a/doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__/comment_1_8e2a14842b44844f90c80b862a1b3a6d._comment b/doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__/comment_1_8e2a14842b44844f90c80b862a1b3a6d._comment
new file mode 100644
index 0000000000..3b1383376b
--- /dev/null
+++ b/doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__/comment_1_8e2a14842b44844f90c80b862a1b3a6d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2014-01-01T20:31:21Z"
+ content="""
+I think you can fix at least the immediate problem by deleting the .git/MERGE_HEAD file.
+
+
+"""]]
diff --git a/doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__/comment_2_031ab6b5a2765ed9e2b185b24a8cbd78._comment b/doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__/comment_2_031ab6b5a2765ed9e2b185b24a8cbd78._comment
new file mode 100644
index 0000000000..d8c4ded898
--- /dev/null
+++ b/doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__/comment_2_031ab6b5a2765ed9e2b185b24a8cbd78._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkYmMFDdf3GJ9Oba6NCVkzGc4JyB9WavMs"
+ nickname="Xinruo"
+ subject="Thanks"
+ date="2014-01-02T00:41:27Z"
+ content="""
+That did the trick! 
+"""]]
diff --git a/doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__/comment_3_93f20519483837c59a75821621e22dee._comment b/doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__/comment_3_93f20519483837c59a75821621e22dee._comment
new file mode 100644
index 0000000000..7cfc2a7f21
--- /dev/null
+++ b/doc/forum/How_to_resolve_a_interrupted_merge_in_direct_mode__63__/comment_3_93f20519483837c59a75821621e22dee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 3"
+ date="2014-01-02T02:05:05Z"
+ content="""
+AFAICS, git-merge was still running when you ctrl-c'd it. So this is coming before git-annex processes the merge to update the work tree.
+
+I don't know why it would take so long to run, especially if it was not using CPU or disk. You might try to reproduce the problem, passing --debug to git-annex, and perhaps strace the git-merge process to see what it's doing.
+"""]]
diff --git a/doc/forum/How_to_restore_symlinks.mdwn b/doc/forum/How_to_restore_symlinks.mdwn
new file mode 100644
index 0000000000..30fb07001b
--- /dev/null
+++ b/doc/forum/How_to_restore_symlinks.mdwn
@@ -0,0 +1 @@
+Somehow the symlinks have vanished from one directory of my repository. How can I restore them?
diff --git a/doc/forum/How_to_restore_symlinks/comment_1_c67e752cf7d5431096fab4b3304790a7._comment b/doc/forum/How_to_restore_symlinks/comment_1_c67e752cf7d5431096fab4b3304790a7._comment
new file mode 100644
index 0000000000..d9e14dd164
--- /dev/null
+++ b/doc/forum/How_to_restore_symlinks/comment_1_c67e752cf7d5431096fab4b3304790a7._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnldTTAP8PAifJUmqhRar6RAWNWlRcencw"
+ nickname="Marco"
+ subject="git annex fix"
+ date="2012-11-24T08:51:19Z"
+ content="""
+You can try
+    git annex fix yourDirectory
+
+Hope that helps.
+"""]]
diff --git a/doc/forum/How_to_restore_symlinks/comment_2_f9ec6096595e2c149c48924e3b54542f._comment b/doc/forum/How_to_restore_symlinks/comment_2_f9ec6096595e2c149c48924e3b54542f._comment
new file mode 100644
index 0000000000..689f321261
--- /dev/null
+++ b/doc/forum/How_to_restore_symlinks/comment_2_f9ec6096595e2c149c48924e3b54542f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 2"
+ date="2012-11-25T18:35:56Z"
+ content="""
+The key thing to realize is that the symlinks used by git-annex are checked into git like any other file would be. So you can use the entire git toolkit to manage them. 
+
+For example, you could run `git status` to see if git shows them as recently deleted, and then use `git checkout $file` to restore the deleted files. 
+
+Or perhaps the deletion has been committed to git, and then you'd use `git log --stat` to find the commit that deleted your files, and `git revert` could be used to undo it.
+
+(`git annex fix` is not related to this and won't help.)
+"""]]
diff --git a/doc/forum/How_to_restore_symlinks/comment_3_4ff80729787a2a4e2baf05dd1db37da3._comment b/doc/forum/How_to_restore_symlinks/comment_3_4ff80729787a2a4e2baf05dd1db37da3._comment
new file mode 100644
index 0000000000..ce0be74b00
--- /dev/null
+++ b/doc/forum/How_to_restore_symlinks/comment_3_4ff80729787a2a4e2baf05dd1db37da3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="jbee"
+ ip="178.25.68.205"
+ subject="Thanks"
+ date="2012-11-28T11:52:24Z"
+ content="""
+> deletion has been committed to git, and then you'd use git log --stat to find the commit that deleted your files, and git revert could be used to undo it.
+
+That did the trick.
+
+Thanks Joey, for the answer and the magnificence that is git-annex.
+"""]]
diff --git a/doc/forum/How_to_retroactively_annex_a_file_already_in_a_git_repo.mdwn b/doc/forum/How_to_retroactively_annex_a_file_already_in_a_git_repo.mdwn
new file mode 100644
index 0000000000..981a53ba0b
--- /dev/null
+++ b/doc/forum/How_to_retroactively_annex_a_file_already_in_a_git_repo.mdwn
@@ -0,0 +1,5 @@
+I worked out how to retroactively annex a large file that had been checked into a git repo some time ago.  I thought this might be useful for others, so I am posting it here.
+
+> This is a great tip, so I've moved it to
+> [[tips|tips/How_to_retroactively_annex_a_file_already_in_a_git_repo]].
+> --[[Joey]] 
diff --git a/doc/forum/How_to_revert_metadata_changes.mdwn b/doc/forum/How_to_revert_metadata_changes.mdwn
new file mode 100644
index 0000000000..429640effb
--- /dev/null
+++ b/doc/forum/How_to_revert_metadata_changes.mdwn
@@ -0,0 +1,25 @@
+Hi,
+
+I accidentally changed some metadata tags for all annexed files in a directory (by omitting the filename to the git annex metadata call). How can I revert that change?
+
+I tried a git reset --hard on the git-annex branch, but after checking out master and adding a new file the changes magically reappeared.
+
+git-annex version: 5.20141125
+
+To reproduce do:
+
+    git init; git annex init
+    echo Hi > a.txt; git annex add a.txt
+    git commit -m 'Initial add'
+    git annex metadata --set name=bla
+    git annex metadata --set name=blu
+    git checkout git-annex
+    git reset --hard HEAD^
+    git checkout master
+    git annex metadata a.txt # name=bla
+    echo Huch > b.txt; git annex add b.txt
+    git annex metadata a.txt # name=blu again
+
+Cheers,
+
+Markus
diff --git a/doc/forum/How_to_revert_metadata_changes/comment_1_de40f1a3f364ca6d2f9bb489f4d64cb3._comment b/doc/forum/How_to_revert_metadata_changes/comment_1_de40f1a3f364ca6d2f9bb489f4d64cb3._comment
new file mode 100644
index 0000000000..da47be164d
--- /dev/null
+++ b/doc/forum/How_to_revert_metadata_changes/comment_1_de40f1a3f364ca6d2f9bb489f4d64cb3._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-01T19:23:29Z"
+ content="""
+`git-annex metadata` used to affect all files under the current directory
+if you left off the files to update. That changed a while ago to prevent
+that fairly common mistake, pity your git-annex is too old to have that
+fixed.
+
+You're on sort of the right track with the git-annex branch, but there are some
+complications:
+
+1. .git/annex/index is the index file for the git-annex branch. When you
+   change the git-annex branch manually, you also need to delete that
+   file. This will cause git-annex to re-generate its index from the new
+   contents of the branch.
+2. Resetting the git-annex branch to a previous rev won't "stick"
+   if the problematic rev has already been pushed to other repositories.
+   git-annex will automatically re-merge the git-annex branches from other
+   repos at some point and get the problem rev back. Instead you'll need to
+   make a commit to the git-annex branch that undoes the changes made by the
+   problem rev. (eg `git revert`)
+3. The contents of the git-annex branch are merged by essentially
+   taking the union of the local and remote contents.
+   So if some other clone of the repository still has the
+   problematic data in its git-annex branch, when git-annex union
+   merges that in, the problem data will come back again, even if you've
+   made a local commit that reverts its addition.
+
+So, you can easily deal with #1; it wouldn't be hard to do #2, but #3
+will be a real sticking point, if the bad data has been pushed out to any
+other repos.
+
+In that case, the only thing to do is to record new information on the
+git-annex branch, so git-annex knows that even if this metadata was set
+before, it's not set any longer. The way to do that is just use
+`git annex metadata --set name-=bla`
+"""]]
diff --git a/doc/forum/How_to_see_what_will_go_to_annex_vs_git.mdwn b/doc/forum/How_to_see_what_will_go_to_annex_vs_git.mdwn
new file mode 100644
index 0000000000..88f629bc69
--- /dev/null
+++ b/doc/forum/How_to_see_what_will_go_to_annex_vs_git.mdwn
@@ -0,0 +1,10 @@
+I am importing lots of files from various sources, and want to make sure that I don't inadvertently commit big files to git. On a file-by-file basis, it's easy enough to tell if it matches the inclusion pattern. But for lots of files, I find myself doing:
+
+1. `git annex add .`
+2. Look for the "non-large file; adding content to git repository" message
+3. `git reset`
+4. `git annex config --set annex.largefiles ...` to add the new file extension to the list
+
+`git add` doesn't provide any info on what goes where.
+
+So is there a way to see, in a given directory, what would be annexed and what would be stored in git when doing `git add` / `git annex add` ?
diff --git a/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_1_d26ea587da51a6f663d64ebb19976a2b._comment b/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_1_d26ea587da51a6f663d64ebb19976a2b._comment
new file mode 100644
index 0000000000..763e722ffb
--- /dev/null
+++ b/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_1_d26ea587da51a6f663d64ebb19976a2b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 1"
+ date="2021-07-04T00:28:09Z"
+ content="""
+`git config annex.addsmallfiles false` will make it so `git annex add` only adds files that should be annexed. So I can `git annex add` first, and then if I have any files left over that should have been annexed, I can add their file suffixes to the inclusion list. Slick!
+"""]]
diff --git a/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_2_316becb188245c1fbbe6daa63505bc34._comment b/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_2_316becb188245c1fbbe6daa63505bc34._comment
new file mode 100644
index 0000000000..7c8dbcecbc
--- /dev/null
+++ b/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_2_316becb188245c1fbbe6daa63505bc34._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-07-05T16:13:05Z"
+ content="""
+Good solution. And if it somehow added a file to annex that you want in git
+you can `git annex unannex` easily enough.
+
+There is not any way to query without adding, query commands like
+`git-annex find` only operate on annexed files so it would need to be
+a new mode added to the command. Or I suppose `git annex add --dry-run`
+could be made to, but don't know that I really like the idea. I like
+your solution better than these ideas though.
+"""]]
diff --git a/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_3_93f3bc4f8e9e2aeef4e417bba2041ee4._comment b/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_3_93f3bc4f8e9e2aeef4e417bba2041ee4._comment
new file mode 100644
index 0000000000..44d56ab6e9
--- /dev/null
+++ b/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_3_93f3bc4f8e9e2aeef4e417bba2041ee4._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 3"
+ date="2021-07-06T19:13:17Z"
+ content="""
+`git annex add --dry-run` is actually the first thing I tried :)
+
+I came across `git-annex-matchexpression` and was able to put together [this script](https://gist.github.com/patmaddox/61ddf773f7b65bd2b42cee7f4e5e574d) that neatly shows me what untracked files will go where:
+
+```
+% ./bin/whereto.rb
+files to annex:
+	- projects/chicken/hello.wav
+
+files to git:
+	- bin/whereto.rb
+	- projects/chicken/bar
+	- projects/chicken/foo
+
+annex.largefiles:
+	include=*.dorico or include=*.mp3 or include=*.pdf or include=*.mxl or include=*.mscz or include=*.xml or include=*.RPP or include=*.wav or include=*.aif*
+```
+"""]]
diff --git a/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_4_558abc4b928649ff3b199a7154c052bf._comment b/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_4_558abc4b928649ff3b199a7154c052bf._comment
new file mode 100644
index 0000000000..e15ea7c92a
--- /dev/null
+++ b/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_4_558abc4b928649ff3b199a7154c052bf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 4"
+ date="2021-10-24T22:42:35Z"
+ content="""
+Would you consider adding a command like this to `git-annex`? I almost always want to work with untracked files at first, which means using `git add` to add them (because `git-annex` doesn't have an `--unlocked` option afaik). Adding them to git by mistake is not good. And really it's just helpful to know when I have new files, are they going to git or to annex.
+"""]]
diff --git a/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_5_ce998d6fc7868a2f129bad755d04b186._comment b/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_5_ce998d6fc7868a2f129bad755d04b186._comment
new file mode 100644
index 0000000000..58dd34f6e0
--- /dev/null
+++ b/doc/forum/How_to_see_what_will_go_to_annex_vs_git/comment_5_ce998d6fc7868a2f129bad755d04b186._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-10-27T18:16:06Z"
+ content="""
+You can use `git annex add --force-small/--force-large` to explicitly
+specify.
+
+annex.addunlocked can make git-annex add add annexed files unlocked, 
+although of course git-annex unlock after adding has the same result.
+"""]]
diff --git a/doc/forum/How_to_set_backend_based_on_file_size_in_.gitattributes.mdwn b/doc/forum/How_to_set_backend_based_on_file_size_in_.gitattributes.mdwn
new file mode 100644
index 0000000000..75a4ca7c06
--- /dev/null
+++ b/doc/forum/How_to_set_backend_based_on_file_size_in_.gitattributes.mdwn
@@ -0,0 +1,16 @@
+Hi there,
+
+In my repos, I want files larger than 500MB to use the WORM backend. So when I'm adding large files, I do it in 2 passes. I first run this:
+    
+    git annex add --largerthan=500MB --backend=WORM .
+
+to add only files larger than 500MB. The remaining files that are smaller than 500MB I then add using default backend:
+
+    git annex add
+
+Is it possible to set annex.backend in .gitattributes so that adding files larger than 500MB automatically use the WORM backend? Can I use expressions such as largerthan or smallerthan? From the example [here](https://git-annex.branchable.com/backends/), it seems that it can only be set based on file type. 
+
+
+Regards,
+
+Eric
diff --git a/doc/forum/How_to_set_backend_based_on_file_size_in_.gitattributes/comment_1_c8ac6b924d4446d4a1a12fb34532fd69._comment b/doc/forum/How_to_set_backend_based_on_file_size_in_.gitattributes/comment_1_c8ac6b924d4446d4a1a12fb34532fd69._comment
new file mode 100644
index 0000000000..878d589ad3
--- /dev/null
+++ b/doc/forum/How_to_set_backend_based_on_file_size_in_.gitattributes/comment_1_c8ac6b924d4446d4a1a12fb34532fd69._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-01-15T16:15:39Z"
+ content="""
+annex.backend only matches on file name, so can't be used for this. I think
+your current two pass approach is the only way to do it currently.
+"""]]
diff --git a/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__.mdwn b/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__.mdwn
new file mode 100644
index 0000000000..8ee5eeea56
--- /dev/null
+++ b/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__.mdwn
@@ -0,0 +1,15 @@
+This seems like something that should be completely obvious, but I've been trying to get it working for a while without success.
+
+I have a few machines (at least 3) at different locations. I want them all to be synced with a remote server that I have. I've installed git-annex on the server, and setting up the assistant on one of the machines, I can create the remote repository, and all seems to work (it spits out info about syncing... though I don't have any easy way of checking if it's working, as all I have is the one client). 
+
+It says in the webapp that setting up a remote git repository in transfer mode will make it easy to have other clients. But I'm wondering how to set that up. I tried just adding the same server with the same path on another machine, but it doesn't seem to be syncing, and I imagine that it is trying to create a fresh repo there instead of syncing with an existing one.
+
+So, how do I set this up? I don't mind adding git remotes, ssh keys, etc, manually, but I haven't been able to figure out what I should be doing! My end goal is to have one annex that is synced between the many computers (ala Dropbox, as the assistant is supposed to be).
+
+Note that the configuration of the test machines:
+client 1 - debian, git-annex built from current cabal
+server - debian, git-annex from apt
+client2 - mac osx, git-annex built from current cabal
+
+Thanks,
+Daniel
diff --git a/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_1_bedaf308cfc70b9e751914a400ebcbc2._comment b/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_1_bedaf308cfc70b9e751914a400ebcbc2._comment
new file mode 100644
index 0000000000..b6a884aa54
--- /dev/null
+++ b/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_1_bedaf308cfc70b9e751914a400ebcbc2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 1"
+ date="2012-11-08T21:29:26Z"
+ content="""
+Just adding the same server with the same path is the right thing to do, it will use the existing repo.
+
+Probably the problem you're having is that one client doesn't know when the other client has sent data to the server. I've recently been adding XMPP (Jabber) support to deal with that. That is not yet in a released version of git-annex, but it is available in git master.
+"""]]
diff --git a/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_2_d665b1514253c8aa487ebf8b2728e3b1._comment b/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_2_d665b1514253c8aa487ebf8b2728e3b1._comment
new file mode 100644
index 0000000000..9cb54839f1
--- /dev/null
+++ b/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_2_d665b1514253c8aa487ebf8b2728e3b1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlsfh8P7pN2OBr24ztT_7AyYQLCcVqqa-4"
+ nickname="Daniel"
+ subject="comment 2"
+ date="2012-11-09T17:49:32Z"
+ content="""
+The master is segfaulting on one of my machines (the mac), but XMMP sounds good in general.
+
+In the meantime - does git annex sync do what the assistant does? Or is there a command to tell the assistant to check for remote changes? (or a way to get it to auto-poll)
+"""]]
diff --git a/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_3_aef42387a3673ab6710fb23e878d7e17._comment b/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_3_aef42387a3673ab6710fb23e878d7e17._comment
new file mode 100644
index 0000000000..2249c9964b
--- /dev/null
+++ b/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_3_aef42387a3673ab6710fb23e878d7e17._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.11.120"
+ subject="comment 3"
+ date="2012-11-13T17:57:49Z"
+ content="""
+I recently dealt with a segfault caused by a bug in the haskell gnutls library. It could be that's what you were seeing. It's fixed in gnutls (>= 0.1.4)
+
+Yes, you can run `git annex sync` by hand. It does the same syncing of the git repository that the assistant does. I don't think making the assistant poll is a good idea.
+"""]]
diff --git a/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_4_bfbcc041db472f4808979e6b3d7c4be2._comment b/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_4_bfbcc041db472f4808979e6b3d7c4be2._comment
new file mode 100644
index 0000000000..7bd4870a3c
--- /dev/null
+++ b/doc/forum/How_to_set_up_two_assistants_with_one_shared_transfer_repository__63__/comment_4_bfbcc041db472f4808979e6b3d7c4be2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniCRkhl_W87gOK5eElfsef3FoUsUFpAr4"
+ nickname="Alexandre"
+ subject="Simplifying this kind of setup"
+ date="2012-12-10T14:33:08Z"
+ content="""
+Maybe it is possible to avoid the XMPP account setup and transferring via XMPP, maybe getting notifications through the SSH connection is possible.
+
+I'm thinking about a \"git-annex-shell server\" unix socket to which clients would connect using the SSH connection and get update notifications from other clients.
+"""]]
diff --git a/doc/forum/How_to_shrink_transfer_repo__63__.mdwn b/doc/forum/How_to_shrink_transfer_repo__63__.mdwn
new file mode 100644
index 0000000000..8e368087f1
--- /dev/null
+++ b/doc/forum/How_to_shrink_transfer_repo__63__.mdwn
@@ -0,0 +1,27 @@
+Hello,
+
+I have two repositories (Asaru and Horus) that are both ```group=client``` and ```wanted=standard```. The other one, Astarte is ```group=transfer``` and ```wanted=standard```. Pretty standard I think.
+
+```
+repository mode: direct
+trusted repositories: 0
+semitrusted repositories: 5
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        58001764-966d-4076-ae99-4ef6de25df39 -- Asaru [here]
+        8165bdf1-907e-4bbe-9c35-22fbf6f8cb00 -- Astarte [astarte]
+        cca0c3c8-593a-4395-936c-1093f0f762e8 -- Horus
+untrusted repositories: 0
+```
+
+I always sync on the two client repos like that ```git annex add . && git annex sync --content```. The transfer repo is growing larger and larger. ```git annex dropunused N``` says, that it ```could only verify the existence of 0 out of 1 necessary copies```.
+
+What is the best way to clean up the transfer repo?
+
+1. Make the two client repos trusted? The three repos have been created manually, not through the assistant. Is that what the assistant does, too?
+2. Try to get the two client repos into touch with each other and try to use ```dropunsed --from=astarte```?
+
+What is the recommended way for that?
+
+Thanks,
+Florian
diff --git a/doc/forum/How_to_shrink_transfer_repo__63__/comment_1_6b110311f4c147dc315c4f610cf56afa._comment b/doc/forum/How_to_shrink_transfer_repo__63__/comment_1_6b110311f4c147dc315c4f610cf56afa._comment
new file mode 100644
index 0000000000..5c1c71475d
--- /dev/null
+++ b/doc/forum/How_to_shrink_transfer_repo__63__/comment_1_6b110311f4c147dc315c4f610cf56afa._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="Horus"
+ subject="comment 1"
+ date="2016-03-03T18:17:35Z"
+ content="""
+Ok, I try to do 2) but it still fails:
+
+```
+dropunused 265 (from astarte...) (unsafe) 
+  Could only verify the existence of 0 out of 1 necessary copies
+
+  Rather than dropping this file, try using: git annex move
+
+  (Use --force to override this check, or adjust numcopies.)
+failed
+```
+
+all repositories are reachable directly.
+"""]]
diff --git a/doc/forum/How_to_shrink_transfer_repo__63__/comment_2_8e596cd606935d82bd6604f5c9c500a2._comment b/doc/forum/How_to_shrink_transfer_repo__63__/comment_2_8e596cd606935d82bd6604f5c9c500a2._comment
new file mode 100644
index 0000000000..edccafb1ec
--- /dev/null
+++ b/doc/forum/How_to_shrink_transfer_repo__63__/comment_2_8e596cd606935d82bd6604f5c9c500a2._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-03-07T17:52:21Z"
+ content="""
+Normally, files should be dropped from the transfer repository once they
+have reached all known client repositories. The drop should be done by
+the client repositories, so the transfer repo doesn't need access to the
+client repos to verify that they have a copy.
+
+But your problem is with *unused* files that are hanging around in
+the transfer repo. This can happen if a file reaches the transfer repo and
+then gets deleted from a client, and so the other clients never download it. 
+
+To clean out those files, run: `git annex dropunused --from astarte --force`
+
+You need to "use the force" because the unused file is only present in the
+transfer repo. If you want to get rid of its content for good, that's fine.
+A safer option is to move the unused file to the local repo: `git annex
+move --unused --from astarte`
+"""]]
diff --git a/doc/forum/How_to_shrink_transfer_repo__63__/comment_3_c536a946b717e9bdcb883b58cd0336ae._comment b/doc/forum/How_to_shrink_transfer_repo__63__/comment_3_c536a946b717e9bdcb883b58cd0336ae._comment
new file mode 100644
index 0000000000..4d0cee3318
--- /dev/null
+++ b/doc/forum/How_to_shrink_transfer_repo__63__/comment_3_c536a946b717e9bdcb883b58cd0336ae._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Horus"
+ subject="comment 3"
+ date="2016-03-07T20:11:03Z"
+ content="""
+Thanks, that worked!
+"""]]
diff --git a/doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__.mdwn b/doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__.mdwn
new file mode 100644
index 0000000000..91d7a886b6
--- /dev/null
+++ b/doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__.mdwn
@@ -0,0 +1,40 @@
+I have one Annex meant to be kept in sync across two computers by the assistant. These computers can't connect directly, so I use a transfer repository (at rsync.net) and xmpp. Recently the two repositories have started to diverge: files added here do not appear there and vice versa, files modified here are not updated there and vice versa. It may be related to this bug: [[bugs/Jabber__47__xmpp_not_supported_on_Debian_Wheezy_backport/]] since one of the two installed versions of git-annex is 5.20140117~bpo70+1, but I do not know whether the divergence started the day I upgraded to this version.
+
+I tried this:
+
+    git-annex fsck --from rsync.net_annex
+
+on both machines. No error is reported, but files are missing here and there and files differ here and there.
+
+I stopped the assistant on both machines and tried to sync with:
+
+    git-annex sync 
+
+and got:
+
+    commit  
+    ok
+    pull 'XXX'
+    fatal: Unable to find remote helper for 'xmpp'
+    failed
+    push 'XXX'
+        Pushing to XXX failed 
+        (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
+    failed
+    git-annex: sync: 2 failed
+
+where 'XXX' stands for my jabber account. I then tried:
+
+    git-annex sync rsync.net_annex
+
+but got:
+
+    git-annex: cannot sync special remotes: rsync.net_annex
+
+    
+
+This situation is unfortunate because the user is not made aware of anything failing. The assistant is running, the webapp shows files being uploaded to the transfer repository, but the two repositories are actually diverging.
+
+How can I synchronize these two repositories?
+
+Thanks,
diff --git a/doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__/comment_1_1c913395f076ee203caaab057da8afbe._comment b/doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__/comment_1_1c913395f076ee203caaab057da8afbe._comment
new file mode 100644
index 0000000000..7bf4585054
--- /dev/null
+++ b/doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__/comment_1_1c913395f076ee203caaab057da8afbe._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="downgrading is not an easy option"
+ date="2014-01-30T05:44:48Z"
+ content="""
+In order to check whether this is related to  [[https://git-annex.branchable.com/bugs/Jabber__47__xmpp_not_supported_on_Debian_Wheezy_backport/]] I tried to downgrade git-annex to the previous version that was available on wheezy-backports (git-annex_4.20131106~bpo70+1_i386.deb) but then I get:
+
+    git-annex: Repository version 5 is not supported. Upgrade git-annex.
+    failed
+
+
+"""]]
diff --git a/doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__/comment_2_081793c52bf15c74a7f48a67c49ff818._comment b/doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__/comment_2_081793c52bf15c74a7f48a67c49ff818._comment
new file mode 100644
index 0000000000..8d4d49a778
--- /dev/null
+++ b/doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__/comment_2_081793c52bf15c74a7f48a67c49ff818._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="clean up"
+ date="2014-01-31T19:55:30Z"
+ content="""
+ok, now that git-annex has been updated to 5.20140117~bpo70+2 things start flowing again, so it was actually caused by [[http://git-annex.branchable.com/bugs/Jabber__47__xmpp_not_supported_on_Debian_Wheezy_backport/]]. Now there is a certain number of files called 'filename.variant.06b8' for instance. That is a bit messy.
+
+I do not know wheter/how it would be possible to inform the user that something is going wrong, but certainely it would be better to avoid failing completely silently.
+
+It would be useful if the webapp could give more precise information about the files the assistant is manipulating. For instance: \"now uploading file 'bla', updating version last uploaded from 'remote' on 'date'\".
+"""]]
diff --git a/doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__/comment_3_f8e0376beb486cf8ce52384ff511ecf2._comment b/doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__/comment_3_f8e0376beb486cf8ce52384ff511ecf2._comment
new file mode 100644
index 0000000000..99bfbba0a8
--- /dev/null
+++ b/doc/forum/How_to_solve__problem_with_diverging_repositories_handled_by_the_assistant__63__/comment_3_f8e0376beb486cf8ce52384ff511ecf2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="71.80.94.56"
+ subject="comment 3"
+ date="2014-02-07T19:07:11Z"
+ content="""
+Normally the webapp will tell you whenever it fails to sync with a remote. However, in this case, it had XMPP support compiled right out of it, so had no idea that remote even existed, and never tried to sync with it, so had no failure to report.
+
+
+The \".variant\" files are because you must have made files with the same names in the 2 repositories while they were disconnected.
+"""]]
diff --git a/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__.mdwn b/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__.mdwn
new file mode 100644
index 0000000000..52a277a6e5
--- /dev/null
+++ b/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__.mdwn
@@ -0,0 +1,4 @@
+
+I'm trying to find a way of syncing data across multiple platforms, including an android device. The latter I want to sync the data so that it's on the devices SD filesystem and independent of network. As far as I can tell git-annex's client is the only one that can do this, all other self hosted storage clients I've found are only network viewers (owncloud, seafile), which is no good to me. I want to sync my ABC sheet music collection onto it, viewable independent of network access, updating changes automatically. Other parts of the data set (i.e. large collection of cannon cr2 raws), I want synced between my laptop and desktop.
+
+I've set up git annex with a central git repo and another client directory which syncs fine to the server (set as a 'full backup'). Now I want to download this whole archive onto the android device. I've set up the client on the device and it works and will upload to the server, however I can't see any way of getting it to download. Surely git-annex has the capability to pull data?
diff --git a/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_1_c4e972c8635f2fa460cd6621f3d993c6._comment b/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_1_c4e972c8635f2fa460cd6621f3d993c6._comment
new file mode 100644
index 0000000000..d01ab86310
--- /dev/null
+++ b/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_1_c4e972c8635f2fa460cd6621f3d993c6._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-09T20:37:49Z"
+ content="""
+Yes, it absolutely does. On Android, git-annex defaults to making
+its repository be a "source" repository, which means it doesn't try
+to get a copy of every file. You can edit the repository in the webapp,
+and select "client" and it will go ahead and download every file it can
+get. See [[preferred_content/standard_groups]].
+
+It sounds like you might want to have the android device only
+get copies of certian files, and ignore others (the raws).
+Doing that is a little more complicated; it involves writing a
+[[preferred_content]] expression. You can do this by first exiting
+the webapp, and the at the git-annex app's console:
+
+	cd /sdcard/annex
+	git annex wanted . "include=sheetmusic/* and exclude=raws/*"
+
+Then when you start the webapp back up, it will get the sheet music 
+and not the raws. Adjust paths in that to suite..
+"""]]
diff --git a/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_2_e06abc9a2f7cf055523f3d35e4eed9bc._comment b/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_2_e06abc9a2f7cf055523f3d35e4eed9bc._comment
new file mode 100644
index 0000000000..c8ba6b1f0e
--- /dev/null
+++ b/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_2_e06abc9a2f7cf055523f3d35e4eed9bc._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="robert_hickman"
+ subject="comment 2"
+ date="2015-02-10T01:40:47Z"
+ content="""
+Thank you Joey, The setting should be added to the local, with the remote set to 'full backup'?
+
+I've tried updating that setting to client but it still doesn’t seem to be working. Looking at the log, there is a line 'fatal: not a valid object name refs/remotes/adesktop_annex/annex/direct/master'. Also it appears to have attempted to sync but quit on an invalid FAT file name. Should this stop syncing altogether? Or can it just ignore/report these problem files.
+
+Also thanks for saying how to do part-downloads, I was wandering if it could do that.
+"""]]
diff --git a/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_3_81d128be0fa60475062e795f34d920f7._comment b/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_3_81d128be0fa60475062e795f34d920f7._comment
new file mode 100644
index 0000000000..086f28e738
--- /dev/null
+++ b/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_3_81d128be0fa60475062e795f34d920f7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="robert_hickman"
+ subject="comment 3"
+ date="2015-02-10T01:49:39Z"
+ content="""
+I'm also seeing a duplicate parent error at the end of the log.
+
+How can I clear the log? It took quite a while to get this running so there is quite a bit of irreverent stuff in it.
+"""]]
diff --git a/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_4_43615e11f1c6d08f5850458d540f5bac._comment b/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_4_43615e11f1c6d08f5850458d540f5bac._comment
new file mode 100644
index 0000000000..59afac274c
--- /dev/null
+++ b/doc/forum/How_to_sync_data_down_from_a___39__full_backup__39____63__/comment_4_43615e11f1c6d08f5850458d540f5bac._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="robert_hickman"
+ subject="comment 4"
+ date="2015-02-10T01:55:06Z"
+ content="""
+Last log content:
+
+(started...) Already up-to-date. error: duplicate parent c2aa8406693d1a3cdec09fb3be8002865cbc8d36 ignored warning: no threads support, ignoring --threads [2015-02-10 01:44:51 GMT] Pusher: Syncing with adesktop_annex warning: no threads support, ignoring --threads fatal: Unable to create '/home/annex/annex/gc.pid.lock': File exists. If no other git process is currently running, this probably means a git process crashed in this repository earlier. Make sure no other git process is running and remove the file manually to continue. To ssh://annex@git-annex-a-desktop-annex_22_annex/~/annex/ e99e004..5b09ad8 git-annex -> synced/git-annex c2aa840..f64d9e3 annex/direct/master -> synced/master error: Ref refs/heads/synced/git-annex is at 5b09ad85ff8d0ba013e4e135e386818eec0cc810 but expected e99e0040176275beb7553f89774f1b14697fccd8 error: Ref refs/heads/synced/master is at e3482dc007f109d0773cf50fd0de2ca2c213cc24 but expected c2aa8406693d1a3cdec09fb3be8002865cbc8d36 remote: error: failed to lock refs/heads/synced/git-annex remote: error: failed to lock refs/heads/synced/master To ssh://annex@git-annex-a-desktop-annex_22_annex/~/annex/ ! [remote rejected] git-annex -> synced/git-annex (failed to lock) ! [remote rejected] annex/direct/master -> synced/master (failed to lock) error: failed to push some refs to 'ssh://annex@git-annex-a-desktop-annex_22_annex/~/annex/' Already up-to-date. error: duplicate parent e3482dc007f109d0773cf50fd0de2ca2c213cc24 ignored warning: no threads support, ignoring --threads To ssh://annex@git-annex-a-desktop-annex_22_annex/~/annex/ e3482dc..e97d44a annex/direct/master -> synced/master
+"""]]
diff --git a/doc/forum/How_to_sync_without_enumerating_files__63__.mdwn b/doc/forum/How_to_sync_without_enumerating_files__63__.mdwn
new file mode 100644
index 0000000000..b67da98d8a
--- /dev/null
+++ b/doc/forum/How_to_sync_without_enumerating_files__63__.mdwn
@@ -0,0 +1,7 @@
+I regularly get this:
+
+    It took 148.17 seconds to enumerate untracked files. 'status -uno'
+    may speed it up, but you have to be careful not to forget to add
+    new files yourself (see 'git help status').
+
+How can I run git-annex sync without enumerating untracked files? Can I add the -uno switch somehow?
diff --git a/doc/forum/How_to_sync_without_enumerating_files__63__/comment_1_ad78c67ae1bb4dc8ed800779c0298158._comment b/doc/forum/How_to_sync_without_enumerating_files__63__/comment_1_ad78c67ae1bb4dc8ed800779c0298158._comment
new file mode 100644
index 0000000000..f79b3592fc
--- /dev/null
+++ b/doc/forum/How_to_sync_without_enumerating_files__63__/comment_1_ad78c67ae1bb4dc8ed800779c0298158._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-10-31T17:15:33Z"
+ content="""
+Well, `git annex sync` does not itself run `git status`. 
+
+Try running git-annex with the --debug option, it will say what git
+commands it runs, and that should help find out which git command is
+complaining.
+
+My guess is it's `git commit`, which  is probably getting the status
+unncessarily for a commit message template, despite a commit message
+being specified. If so, `git annex sync --no-commit` would avoid
+that.
+"""]]
diff --git a/doc/forum/How_to_use_--jobs__61__10_by_default__63__.mdwn b/doc/forum/How_to_use_--jobs__61__10_by_default__63__.mdwn
new file mode 100644
index 0000000000..5df570471e
--- /dev/null
+++ b/doc/forum/How_to_use_--jobs__61__10_by_default__63__.mdwn
@@ -0,0 +1 @@
+Whenever I do `git annex add`, I want it to use `--jobs=10`. By default. Without me having to write `--jobs=10` every time. How can I achieve this?
diff --git a/doc/forum/How_to_use_--jobs__61__10_by_default__63__/comment_1_3c47ad3f0c17e475ea42438a42085f9c._comment b/doc/forum/How_to_use_--jobs__61__10_by_default__63__/comment_1_3c47ad3f0c17e475ea42438a42085f9c._comment
new file mode 100644
index 0000000000..e9bf844c27
--- /dev/null
+++ b/doc/forum/How_to_use_--jobs__61__10_by_default__63__/comment_1_3c47ad3f0c17e475ea42438a42085f9c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-02-20T18:37:14Z"
+ content="""
+`git config annex.jobs 10`
+
+That will work, assuming you don't mind other commands also using 10 jobs.
+There is not a way to git config different job numbers for different
+commands.
+
+A shell script or alias would also be a good solution.
+"""]]
diff --git a/doc/forum/How_to_view_progress_of_in-progress_upload__63__.mdwn b/doc/forum/How_to_view_progress_of_in-progress_upload__63__.mdwn
new file mode 100644
index 0000000000..31b7e0676b
--- /dev/null
+++ b/doc/forum/How_to_view_progress_of_in-progress_upload__63__.mdwn
@@ -0,0 +1,17 @@
+Hello,
+
+I have a large (3.3 GB) file uploading to a Backblaze B2 remote ... when I first issued the `git annex copy --to` command, it showed a nice progress bar.  However, it didn't finish on the first attempt (probably due to system hibernation or something).  
+
+At first I couldn't get it to resume; I used `git annex whereis` to confirm that it wasn't in the remote (and confirmed manually), then I tried to reissue the `git annex copy` command to resume, but I got an error: copy failed: "transfer already in progress, or unable to take transfer lock".
+
+I'm not sure how, but I got it to resume ... I think it was `git annex copy --failed --to=(remote)` ... I know that it resumed because I can see the network traffic, confirmed in nethogs that it is coming from git-annex-remote-b2, and issuing `git annex info` reports the file is uploading under `transfers in progress`.
+
+What I'm wondering, is how can I get information on the progress of the upload, how much it's done and has left, etc?  Or even a progress bar, since the initial `copy` command gave a nice progress bar?
+
+I've been searching the documentation, man pages, and web, but haven't found anything so far ... please forgive me and let me know if I missed this somewhere.
+
+Thank you.
+
+PS: I love git annex; it's taken me a while to grok it and start using it usefully (despite my being already a somewhat experienced git user); but the steep-ish learning curve is worth it, for a file management system with flexible, distributed backends, that I can have control over, and with versioning.  Thank you very much for creating and sharing and continuing to work on it.
+
+-- aaronw
diff --git a/doc/forum/How_to_view_progress_of_in-progress_upload__63__/comment_1_794cc9bdf728c96dd7c50cf402573cf5._comment b/doc/forum/How_to_view_progress_of_in-progress_upload__63__/comment_1_794cc9bdf728c96dd7c50cf402573cf5._comment
new file mode 100644
index 0000000000..d4e1f55a1a
--- /dev/null
+++ b/doc/forum/How_to_view_progress_of_in-progress_upload__63__/comment_1_794cc9bdf728c96dd7c50cf402573cf5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-01-17T17:21:23Z"
+ content="""
+If git-annex is not providing a progress display, it's because
+the remote is not reporting any progress to it.
+
+It may be that the Backblaze B2 remote doesn't report progress when
+resuming an interrupted upload, for some reason.
+"""]]
diff --git a/doc/forum/How_to_view_progress_of_in-progress_upload__63__/comment_2_6347e08b599239b6416957e9a7114157._comment b/doc/forum/How_to_view_progress_of_in-progress_upload__63__/comment_2_6347e08b599239b6416957e9a7114157._comment
new file mode 100644
index 0000000000..e3491dc912
--- /dev/null
+++ b/doc/forum/How_to_view_progress_of_in-progress_upload__63__/comment_2_6347e08b599239b6416957e9a7114157._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="aaron@784fd85903b38afc8a44d117ba95e3dcce0bd230"
+ nickname="aaron"
+ avatar="http://cdn.libravatar.org/avatar/5675f02765c91919c6a70f2a71681925"
+ subject="Ah, ok."
+ date="2019-01-30T16:36:12Z"
+ content="""
+Thank you for the clarification.
+"""]]
diff --git a/doc/forum/How_to_work_with_transfer_repos_manually__63__.mdwn b/doc/forum/How_to_work_with_transfer_repos_manually__63__.mdwn
new file mode 100644
index 0000000000..8ec42dba42
--- /dev/null
+++ b/doc/forum/How_to_work_with_transfer_repos_manually__63__.mdwn
@@ -0,0 +1,18 @@
+Hello,
+
+I have 3 repos, desktop, external and server. desktop and server are sometimes connected, sometimes they should sync using the server. I want to do it manually without the assistent, since I love to learn it that way before I let the assistent do the work.
+
+client and desktop are "wanted standard" and "group client". server is "group transfer".
+
+desktop and server have each other and server in their remotes. server has no remotes.
+
+Is this setup fine that way?
+
+How to use it with the transfer repo?
+
+"git annex sync && git annex copy --to server --auto" after changing files?
+"git annex sync && git annex copy --from server --auto" to update?
+
+Will the on the server automatically be dropped? Or do the server needs to have a active role, i.e. called via ssh?
+
+Thanks!
diff --git a/doc/forum/How_to_work_with_transfer_repos_manually__63__/comment_1_3dec369405e6b6a4a6e5121546c03712._comment b/doc/forum/How_to_work_with_transfer_repos_manually__63__/comment_1_3dec369405e6b6a4a6e5121546c03712._comment
new file mode 100644
index 0000000000..c6d3f9dae3
--- /dev/null
+++ b/doc/forum/How_to_work_with_transfer_repos_manually__63__/comment_1_3dec369405e6b6a4a6e5121546c03712._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-20T15:29:41Z"
+ content="""
+If you use `git annex sync --content`, it will do a full sync,
+including uploading any necessary files to the transfer repo,
+downloading any files that are on the transfer repo, and
+dropping files from the transfer repo once they've been
+transferred to the client repos.
+"""]]
diff --git a/doc/forum/How_to_work_with_transfer_repos_manually__63__/comment_1_b8f3c09b470d99578a4a17064498dd39._comment b/doc/forum/How_to_work_with_transfer_repos_manually__63__/comment_1_b8f3c09b470d99578a4a17064498dd39._comment
new file mode 100644
index 0000000000..51a473ed1f
--- /dev/null
+++ b/doc/forum/How_to_work_with_transfer_repos_manually__63__/comment_1_b8f3c09b470d99578a4a17064498dd39._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9SYh6N-JUMkYkW4aOk55zC3Vr9KonDV4"
+ nickname="Florian"
+ subject="comment 1"
+ date="2014-10-20T10:51:16Z"
+ content="""
+Ok, git annex copy --to server --auto and git annex get on the receiver did the trick.
+
+But how can I drop files from the transfer server that both clients have? I tried git annex drop . or git annex drop --auto . but it just did nothing.
+
+Thx!
+"""]]
diff --git a/doc/forum/How_to_work_with_transfer_repos_manually__63__/comment_3_be2c594bc1d162cfb1acc3a01fc284f2._comment b/doc/forum/How_to_work_with_transfer_repos_manually__63__/comment_3_be2c594bc1d162cfb1acc3a01fc284f2._comment
new file mode 100644
index 0000000000..393cd44973
--- /dev/null
+++ b/doc/forum/How_to_work_with_transfer_repos_manually__63__/comment_3_be2c594bc1d162cfb1acc3a01fc284f2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2014-10-20T18:53:31Z"
+ content="""
+git annex drop --auto --from server
+"""]]
diff --git a/doc/forum/Howto_remove_a_repository__63__.mdwn b/doc/forum/Howto_remove_a_repository__63__.mdwn
new file mode 100644
index 0000000000..4eb4e68699
--- /dev/null
+++ b/doc/forum/Howto_remove_a_repository__63__.mdwn
@@ -0,0 +1,4 @@
+Hello,
+
+I have added a few repositories for testing purpose and would like to remove them.
+Is it possible to remove a repository through assistant? 
diff --git a/doc/forum/Howto_remove_a_repository__63__/comment_1_b55fa4e92bb457ecaa5ca8f5cee7be1d._comment b/doc/forum/Howto_remove_a_repository__63__/comment_1_b55fa4e92bb457ecaa5ca8f5cee7be1d._comment
new file mode 100644
index 0000000000..642da6575f
--- /dev/null
+++ b/doc/forum/Howto_remove_a_repository__63__/comment_1_b55fa4e92bb457ecaa5ca8f5cee7be1d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-17T19:05:27Z"
+ content="""
+There's no UI for it in the assistant. [[Relevant bug report|bugs/The_webapp_doesn't_allow_deleting_repositories]]
+"""]]
diff --git a/doc/forum/Howto_remove_unused_files.mdwn b/doc/forum/Howto_remove_unused_files.mdwn
new file mode 100644
index 0000000000..db770457b0
--- /dev/null
+++ b/doc/forum/Howto_remove_unused_files.mdwn
@@ -0,0 +1,31 @@
+Hello.
+
+My case: I have somehow managed to get my repo, with quite much stuff inside it messed up.
+
+There is single directory 'cities' containing quite many files (>10k) that i would rather see gone (and keep the tar.bz version of it ..). I tried doing 
+
+    git drop --force
+
+that works fine, but the files are still there after sync. 
+
+git annex unused says just 'ok' so i guess it thinks they are still used somewhere. I tried to look where, but i ended up just doing git annex drop -f my_remote_here test_file_name for each of my remotes. This doesnt help. 
+How can i get rid of these files? Doing git annex fsck shows that 
+
+
+So, try to search what is the key:
+
+     % ls -lah cities/diskcache/config.cfg
+     lrwxrwxrwx 1 XX XXX 190 Nov 29 05:52 cities/diskcache/config.cfg -> ../../../../.git/annex/objects/qm/M6/SHA256-s32--4f5ce34d1b0b8d854a315530b2fdcbfa9c3067636a2aa5433a04402db4151dce/SHA256-s32--4f5ce34d1b0b8d854a315530b2fdcbfa9c3067636a2aa5433a04402db4151dce
+     sundberg@sundberg-MS-7680 ~/git-repository/ubuntu.iso/Archive/Maps
+     % git log --stat --all -SSHA256-s32--4f5ce34d1b0b8d854a315530b2fdcbfa9c3067636a2aa5433a04402db4151dce/SHA256-s32--4f5ce34d1b0b8d854a315530b2fdcbfa9c3067636a2aa5433a04402db4151dce
+     commit 51a57a023774ff80408210828f298f5c42a7e0be
+     Author: XXXX
+     Date:   Sun Dec 9 13:42:40 2012 +0200
+        git-annex automatic sync
+     Archive/Maps/cities/diskcache/config.cfg |    1 +
+     1 file changed, 1 insertion(+)
+
+So how can i deduce what is the remote i should try to clean up ?
+
+
+Thanks!
diff --git a/doc/forum/Howto_remove_unused_files/comment_1_f2a7948268ce3cb3967a9fdd8ccc570a._comment b/doc/forum/Howto_remove_unused_files/comment_1_f2a7948268ce3cb3967a9fdd8ccc570a._comment
new file mode 100644
index 0000000000..b2bf64397b
--- /dev/null
+++ b/doc/forum/Howto_remove_unused_files/comment_1_f2a7948268ce3cb3967a9fdd8ccc570a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkbv1oKTKhbBp0Ljh_WGU7BFSWWxBr7D3U"
+ nickname="Pauli"
+ subject="Just to add"
+ date="2013-04-02T19:01:09Z"
+ content="""
+
+When i do 'git annex get .' on my usb-remote i get these kind of prints:
+
+    get Archive/Maps/cities/diskcache/voices/slovenian_f/slovenian_female/g5ext_000 (not available) 
+    No other repository is known to contain the file.
+    failed
+
+
+No repository contains the file? Well why cannot i then get it removed from the listing .. 
+"""]]
diff --git a/doc/forum/Howto_remove_unused_files/comment_2_9b4d198c2d8a52adef3d166a8196fc0d._comment b/doc/forum/Howto_remove_unused_files/comment_2_9b4d198c2d8a52adef3d166a8196fc0d._comment
new file mode 100644
index 0000000000..ef4219e2fb
--- /dev/null
+++ b/doc/forum/Howto_remove_unused_files/comment_2_9b4d198c2d8a52adef3d166a8196fc0d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkbv1oKTKhbBp0Ljh_WGU7BFSWWxBr7D3U"
+ nickname="Pauli"
+ subject="comment 2"
+ date="2013-04-02T19:10:18Z"
+ content="""
+Just to continue my monolog: doing 'git rm -r cities' followed with git annex sync did the trick. Why didn't i find this anywhere ..
+"""]]
diff --git a/doc/forum/Howto_remove_unused_files/comment_3_441d10901d5c055ac3ed2a6cb61c075c._comment b/doc/forum/Howto_remove_unused_files/comment_3_441d10901d5c055ac3ed2a6cb61c075c._comment
new file mode 100644
index 0000000000..ffb941ac88
--- /dev/null
+++ b/doc/forum/Howto_remove_unused_files/comment_3_441d10901d5c055ac3ed2a6cb61c075c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-04-02T21:21:21Z"
+ content="""
+git-annex adds large file capabilities to git, but it leaves all the regular git commands there for you to use. So the answer to \"how do I do &lt;something I'd normally do with a git command&gt;\" is always \"run the git command\". You only need to use git-annex to add large files to git, and to move their content around between repositories. Hope that helps clear that up.
+"""]]
diff --git a/doc/forum/Huge_differences_in_sync_times_in_different_directories_of_same_machines.mdwn b/doc/forum/Huge_differences_in_sync_times_in_different_directories_of_same_machines.mdwn
new file mode 100644
index 0000000000..c936fbd65d
--- /dev/null
+++ b/doc/forum/Huge_differences_in_sync_times_in_different_directories_of_same_machines.mdwn
@@ -0,0 +1,127 @@
+I am confused by the differences in the time between updates of different
+repositories in the same machines and of the same repository in different
+machines. I am using the assistant (in all machines, 
+'git annex assitant --autostart').
+
+
+
+For instance, I have three machines synced as
+
+A <-> B <-> C
+
+and I have two directories being synced. The configuration (except for
+directory names) is the same and looks like
+
+
+```
+[annex]
+        uuid = something
+        version = 5
+        direct = true
+        autoupgrade = true
+        autocommit = true
+        startupscan = true
+[remote "machine_repo"]
+        url = ssh://xxxxxx/~/repo/
+        fetch = +refs/heads/*:refs/remotes/machine_repo/*
+        annex-uuid = xxxxxxxxxxxxx
+
+```
+
+
+I modify or add a file in one of the directories in A, and it quickly
+(less than 30 seconds) appears in B and shortly after that in C.
+
+In another directory, however, more than 30 minutes can go by without C
+ever changing (even if B gets the change almost immediately). Looking at
+the logs I cannot understand what is happening. This is the case of a
+file, ```A_sentinel_file_A ```, created at 01:46.
+
+In B (where it appears almost immediately)  I can see
+
+
+```
+[2015-03-02 01:46:17 CET] Pusher: Syncing with 123.456.789.101_somedir 
+To ssh://ramon@git-annex-Machine_C-ramon_22_annex.2Done.2Dway.2F/~/some-dir/
+   794df9f..ae8c3f0  git-annex -> synced/git-annex
+Automatic merge went well; stopped before committing as requested
+[2015-03-02 01:47:03 CET] Committer: Committing changes to git
+[2015-03-02 01:47:03 CET] Pusher: Syncing with 123.456.789.101_somedir 
+
+A_sentinel_file_A
+             18 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2015-03-02 01:47:04 CET] Transferrer: Uploaded A_sentinel_file_A
+To ssh://ramon@git-annex-Machine_C-ramon_22_annex.2Done.2Dway.2F/~/some-dir/
+   ae8c3f0..b043335  git-annex -> synced/git-annex
+   75269bc..b61c7a5  annex/direct/master -> synced/master
+[2015-03-02 01:47:04 CET] Committer: Committing changes to git
+[2015-03-02 01:47:06 CET] Pusher: Syncing with 123.456.789.101_somedir 
+To ssh://ramon@git-annex-Machine_C-ramon_22_annex.2Done.2Dway.2F/~/some-dir/
+   b043335..fc9279c  git-annex -> synced/git-annex
+```
+
+
+And in C (the machine with IP 123.456.789.101, above)  I can see
+
+
+```
+[2015-03-02 01:46:13 CET] RemoteControl: Syncing with Machine_B_somedir 
+From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+   593d908..794df9f  git-annex  -> Machine_B_somedir/git-annex
+   593d908..235149d  synced/git-annex -> Machine_B_somedir/synced/git-annex
+   a1596b3..75269bc  synced/master -> Machine_B_somedir/synced/master
+[2015-03-02 01:46:17 CET] RemoteControl: Syncing with Machine_B_somedir 
+From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+   a1596b3..75269bc  annex/direct/master -> Machine_B_somedir/annex/direct/master
+   794df9f..ae8c3f0  git-annex  -> Machine_B_somedir/git-annex
+   a1596b3..75269bc  master     -> Machine_B_somedir/master
+[2015-03-02 01:46:27 CET] RemoteControl: Syncing with Machine_B_somedir 
+From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+   ae8c3f0..632caa4  git-annex  -> Machine_B_somedir/git-annex
+   235149d..632caa4  synced/git-annex -> Machine_B_somedir/synced/git-annex
+[2015-03-02 01:47:02 CET] RemoteControl: Syncing with Machine_B_somedir 
+From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+   632caa4..56ac968  synced/git-annex -> Machine_B_somedir/synced/git-annex
+   75269bc..b61c7a5  synced/master -> Machine_B_somedir/synced/master
+[2015-03-02 01:47:02 CET] RemoteControl: Syncing with Machine_B_somedir 
+From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+   632caa4..b043335  git-annex  -> Machine_B_somedir/git-annex
+[2015-03-02 01:47:07 CET] RemoteControl: Syncing with Machine_B_somedir 
+From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+   75269bc..b61c7a5  annex/direct/master -> Machine_B_somedir/annex/direct/master
+   b043335..fc9279c  git-annex  -> Machine_B_somedir/git-annex
+   75269bc..b61c7a5  master     -> Machine_B_somedir/master
+[2015-03-02 01:47:15 CET] RemoteControl: Syncing with Machine_B_somedir 
+From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+   fc9279c..a4642a8  git-annex  -> Machine_B_somedir/git-annex
+   56ac968..a4642a8  synced/git-annex -> Machine_B_somedir/synced/git-annex
+(merging synced/git-annex Machine_B_somedir/git-annex into git-annex...)
+(recording state in git...)
+[2015-03-02 02:17:23 CET] RemoteControl: Syncing with Machine_B_somedir 
+From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+   a4642a8..bfaba72  git-annex  -> Machine_B_somedir/git-annex
+   a4642a8..bfaba72  synced/git-annex -> Machine_B_somedir/synced/git-annex
+   b61c7a5..29ff91e  synced/master -> Machine_B_somedir/synced/master   
+   
+```
+
+Why did Machine C did not show the updated file at 01:47, which is when, I
+think, machine B pushes it there? Or at 02:17 when both machines again
+seem to talk to each other? Regardless, at 02:27 the file still was not
+there. Yes, of course, if I issue a
+
+```
+git annex sync --content
+```
+
+then the file is shown in Machine C. But I should not need to do that.
+
+
+
+In contrast, as I said, there is another directory, with identical
+configuration, where these things do not happen and changes show
+immediately (both directories, for now, only have tiny test files).
+
+What am I doing wrong? This is too big a difference to make sense to me.
+
+
diff --git a/doc/forum/Huge_differences_in_sync_times_in_different_directories_of_same_machines/comment_1_445766c0f646e9cb5b45b863ad87e85a._comment b/doc/forum/Huge_differences_in_sync_times_in_different_directories_of_same_machines/comment_1_445766c0f646e9cb5b45b863ad87e85a._comment
new file mode 100644
index 0000000000..5c1ddf127b
--- /dev/null
+++ b/doc/forum/Huge_differences_in_sync_times_in_different_directories_of_same_machines/comment_1_445766c0f646e9cb5b45b863ad87e85a._comment
@@ -0,0 +1,136 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnbPKLjBONawBd74MKJZo05juCqdsP1jAU"
+ nickname="Ramon"
+ subject="comment 1"
+ date="2015-03-02T01:47:32Z"
+ content="""
+Ooops, the formatting got all messed up. Here it is again:
+
+I am confused by the differences in the time between updates of different
+repositories in the same machines and of the same repository in different
+machines. I am using the assistant (in all machines, 
+'git annex assitant --autostart').
+
+
+
+For instance, I have three machines synced as
+
+A <-> B <-> C
+
+and I have two directories being synced. The configuration (except for
+directory names) is the same and looks like
+
+
+
+    [annex]
+            uuid = something
+            version = 5
+            direct = true
+            autoupgrade = true
+            autocommit = true
+            startupscan = true
+    [remote \"machine_repo\"]
+            url = ssh://xxxxxx/~/repo/
+            fetch = +refs/heads/*:refs/remotes/machine_repo/*
+            annex-uuid = xxxxxxxxxxxxx
+    
+
+
+
+I modify or add a file in one of the directories in A, and it quickly
+(less than 30 seconds) appears in B and shortly after that in C.
+
+In another directory, however, more than 30 minutes can go by without C
+ever changing (even if B gets the change almost immediately). Looking at
+the logs I cannot understand what is happening. This is the case of a
+file, ```A_sentinel_file_A ```, created at 01:46.
+
+In B (where it appears almost immediately)  I can see
+
+
+    [2015-03-02 01:46:17 CET] Pusher: Syncing with 123.456.789.101_somedir 
+    To ssh://ramon@git-annex-Machine_C-ramon_22_annex.2Done.2Dway.2F/~/some-dir/
+       794df9f..ae8c3f0  git-annex -> synced/git-annex
+    Automatic merge went well; stopped before committing as requested
+    [2015-03-02 01:47:03 CET] Committer: Committing changes to git
+    [2015-03-02 01:47:03 CET] Pusher: Syncing with 123.456.789.101_somedir 
+    
+    A_sentinel_file_A
+                 18 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+    [2015-03-02 01:47:04 CET] Transferrer: Uploaded A_sentinel_file_A
+    To ssh://ramon@git-annex-Machine_C-ramon_22_annex.2Done.2Dway.2F/~/some-dir/
+       ae8c3f0..b043335  git-annex -> synced/git-annex
+       75269bc..b61c7a5  annex/direct/master -> synced/master
+    [2015-03-02 01:47:04 CET] Committer: Committing changes to git
+    [2015-03-02 01:47:06 CET] Pusher: Syncing with 123.456.789.101_somedir 
+    To ssh://ramon@git-annex-Machine_C-ramon_22_annex.2Done.2Dway.2F/~/some-dir/
+       b043335..fc9279c  git-annex -> synced/git-annex
+
+
+
+And in C (the machine with IP 123.456.789.101, above)  I can see
+
+
+
+    [2015-03-02 01:46:13 CET] RemoteControl: Syncing with Machine_B_somedir 
+    From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+       593d908..794df9f  git-annex  -> Machine_B_somedir/git-annex
+       593d908..235149d  synced/git-annex -> Machine_B_somedir/synced/git-annex
+       a1596b3..75269bc  synced/master -> Machine_B_somedir/synced/master
+    [2015-03-02 01:46:17 CET] RemoteControl: Syncing with Machine_B_somedir 
+    From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+       a1596b3..75269bc  annex/direct/master -> Machine_B_somedir/annex/direct/master
+       794df9f..ae8c3f0  git-annex  -> Machine_B_somedir/git-annex
+       a1596b3..75269bc  master     -> Machine_B_somedir/master
+    [2015-03-02 01:46:27 CET] RemoteControl: Syncing with Machine_B_somedir 
+    From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+       ae8c3f0..632caa4  git-annex  -> Machine_B_somedir/git-annex
+       235149d..632caa4  synced/git-annex -> Machine_B_somedir/synced/git-annex
+    [2015-03-02 01:47:02 CET] RemoteControl: Syncing with Machine_B_somedir 
+    From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+       632caa4..56ac968  synced/git-annex -> Machine_B_somedir/synced/git-annex
+       75269bc..b61c7a5  synced/master -> Machine_B_somedir/synced/master
+    [2015-03-02 01:47:02 CET] RemoteControl: Syncing with Machine_B_somedir 
+    From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+       632caa4..b043335  git-annex  -> Machine_B_somedir/git-annex
+    [2015-03-02 01:47:07 CET] RemoteControl: Syncing with Machine_B_somedir 
+    From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+       75269bc..b61c7a5  annex/direct/master -> Machine_B_somedir/annex/direct/master
+       b043335..fc9279c  git-annex  -> Machine_B_somedir/git-annex
+       75269bc..b61c7a5  master     -> Machine_B_somedir/master
+    [2015-03-02 01:47:15 CET] RemoteControl: Syncing with Machine_B_somedir 
+    From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+       fc9279c..a4642a8  git-annex  -> Machine_B_somedir/git-annex
+       56ac968..a4642a8  synced/git-annex -> Machine_B_somedir/synced/git-annex
+    (merging synced/git-annex Machine_B_somedir/git-annex into git-annex...)
+    (recording state in git...)
+    [2015-03-02 02:17:23 CET] RemoteControl: Syncing with Machine_B_somedir 
+    From ssh://git-annex-Machine_B-ramon_22_annex.2Done.2Dway/~/some-dir
+       a4642a8..bfaba72  git-annex  -> Machine_B_somedir/git-annex
+       a4642a8..bfaba72  synced/git-annex -> Machine_B_somedir/synced/git-annex
+       b61c7a5..29ff91e  synced/master -> Machine_B_somedir/synced/master   
+       
+
+
+Why did Machine C did not show the updated file at 01:47, which is when, I
+think, machine B pushes it there? Or at 02:17 when both machines again
+seem to talk to each other? Regardless, at 02:27 the file still was not
+there. Yes, of course, if I issue a
+
+```
+    git annex sync --content
+```
+
+then the file is shown in Machine C. But I should not need to do that.
+
+
+
+In contrast, as I said, there is another directory, with identical
+configuration, where these things do not happen and changes show
+immediately (both directories, for now, only have tiny test files).
+
+
+
+
+
+"""]]
diff --git a/doc/forum/Huge_differences_in_sync_times_in_different_directories_of_same_machines/comment_2_b3953f30fb817ee3753f888a871de51f._comment b/doc/forum/Huge_differences_in_sync_times_in_different_directories_of_same_machines/comment_2_b3953f30fb817ee3753f888a871de51f._comment
new file mode 100644
index 0000000000..58d019be98
--- /dev/null
+++ b/doc/forum/Huge_differences_in_sync_times_in_different_directories_of_same_machines/comment_2_b3953f30fb817ee3753f888a871de51f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-06T20:07:08Z"
+ content="""
+I think there might be some bug where the assistant does not notice that
+the synced/master branch has been updated, and doesn't immediately merge it
+into the local master branch. This seems to be borne out by your log.
+
+[[bugs/assistant_sometimes_does_not_merge_changes_from_remote]] might be
+related.
+"""]]
diff --git a/doc/forum/Idly_syncing_back_and_forth_creates_commits.mdwn b/doc/forum/Idly_syncing_back_and_forth_creates_commits.mdwn
new file mode 100644
index 0000000000..ee1c6a0102
--- /dev/null
+++ b/doc/forum/Idly_syncing_back_and_forth_creates_commits.mdwn
@@ -0,0 +1,7 @@
+Say I have a git annex repository with one regular remote.  The status of both remotes is clean.
+
+If I run `git annex sync` in the main remote, it will not create any commits.
+
+However, running sync alternatively in both remotes will keep creating regular and merge commits.
+
+I wonder if it would be possible to avoid this behavior.
diff --git a/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_1_e6a60889876bd49855fe60849db147ef._comment b/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_1_e6a60889876bd49855fe60849db147ef._comment
new file mode 100644
index 0000000000..afbefcdb90
--- /dev/null
+++ b/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_1_e6a60889876bd49855fe60849db147ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2022-09-15T15:55:31Z"
+ content="""
+This is expected if you have any special remotes with remote.<remote>.annex-tracking-branch configured.
+"""]]
diff --git a/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_2_1053e88c417e8b46648f645a466145e2._comment b/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_2_1053e88c417e8b46648f645a466145e2._comment
new file mode 100644
index 0000000000..63a12651c3
--- /dev/null
+++ b/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_2_1053e88c417e8b46648f645a466145e2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="eph@6377f195575d4a04abc70f20e0b00dffcc597d00"
+ nickname="eph"
+ avatar="http://cdn.libravatar.org/avatar/81a297ec8f90be36b16e5f530aea0719"
+ subject="comment 2"
+ date="2022-09-16T09:30:43Z"
+ content="""
+I did not configure any special remotes.  The only ones that are shown by `git annex info` are `web` and `bittorrent`, but I believe that this is the default.  Are these the culprit?
+"""]]
diff --git a/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_3_577f62d506a66770e746a50fc103901d._comment b/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_3_577f62d506a66770e746a50fc103901d._comment
new file mode 100644
index 0000000000..d0e6aafed0
--- /dev/null
+++ b/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_3_577f62d506a66770e746a50fc103901d._comment
@@ -0,0 +1,110 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-09-16T16:40:02Z"
+ content="""
+The built in web and bittorrent special remotes are not at fault.
+
+I don't know what is causing this, but am interested in finding out.
+I have not seen this behavior in a long time. Back when git-annex had
+direct mode, it did sometimes behave this way, IIRC, but that was a long
+time ago. What version of git-annex are you using?
+
+It would be helpful if you could show an example of this happening,
+with details about what the commits look like and what the output
+is of `git-annex sync` when they are created.
+
+When I try this, it doesn't happen:
+
+	joey@darkstar:~/tmp/bench/bar>cd ../foo
+	joey@darkstar:~/tmp/bench/foo>git-annex sync
+	commit
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	pull bar
+	ok
+	joey@darkstar:~/tmp/bench/foo>cd ../bar
+	joey@darkstar:~/tmp/bench/bar>git-annex sync
+	commit
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	pull foo
+	ok
+	joey@darkstar:~/tmp/bench/bar>cd ../foo
+	joey@darkstar:~/tmp/bench/foo>git-annex sync
+	commit
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	pull bar
+	ok
+	joey@darkstar:~/tmp/bench/foo>cd ../bar
+	joey@darkstar:~/tmp/bench/bar>git-annex sync
+	commit
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	pull foo
+	ok
+
+After making a change, it quickly settles down:
+
+	joey@darkstar:~/tmp/bench/bar>date > new
+	joey@darkstar:~/tmp/bench/bar>git-annex add
+	add new 
+	ok                                
+	(recording state in git...)
+	gijoey@darkstar:~/tmp/bench/bar>git-annex sync
+	commit 
+	[master f9e0940] git-annex in bar
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 new
+	ok
+	pull foo 
+	ok
+	push foo 
+	Enumerating objects: 16, done.
+	Counting objects: 100% (16/16), done.
+	Delta compression using up to 4 threads
+	Compressing objects: 100% (8/8), done.
+	Writing objects: 100% (11/11), 969 bytes | 484.00 KiB/s, done.
+	Total 11 (delta 3), reused 0 (delta 0), pack-reused 0
+	To ../foo
+	   eeaea21..4127372  git-annex -> synced/git-annex
+	   e8cb8fe..f9e0940  master -> synced/master
+	ok
+	joey@darkstar:~/tmp/bench/bar>cd ../foo
+	joey@darkstar:~/tmp/bench/foo>git-annex sync
+	commit 
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	merge synced/master 
+	Updating e8cb8fe..f9e0940
+	Fast-forward
+	 new | 1 +
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 new
+	ok
+	pull bar 
+	From ../bar
+	   a5cd9dd..4127372  git-annex     -> bar/git-annex
+	   e8cb8fe..f9e0940  master        -> bar/master
+	   e8cb8fe..f9e0940  synced/master -> bar/synced/master
+	ok
+	joey@darkstar:~/tmp/bench/foo>cd ../bar
+	joey@darkstar:~/tmp/bench/bar>git-annex sync
+	commit 
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	pull foo 
+	From ../foo
+	   e8cb8fe..f9e0940  master     -> foo/master
+	ok
+
+Making different changes in the two repositories at the same time similarly
+settles down quickly, after one merge commit.
+"""]]
diff --git a/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_4_0079c41305493873521d3af45075a2c4._comment b/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_4_0079c41305493873521d3af45075a2c4._comment
new file mode 100644
index 0000000000..96c27ae4f4
--- /dev/null
+++ b/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_4_0079c41305493873521d3af45075a2c4._comment
@@ -0,0 +1,277 @@
+[[!comment format=mdwn
+ username="eph@6377f195575d4a04abc70f20e0b00dffcc597d00"
+ nickname="eph"
+ avatar="http://cdn.libravatar.org/avatar/81a297ec8f90be36b16e5f530aea0719"
+ subject="comment 4"
+ date="2022-09-17T21:19:13Z"
+ content="""
+Hi joey,
+
+thanks for looking into this.  I am using git-annex from Debian stable.  No special configuration.  The following complete log demonstrates what I mean.  I only edited my real name and email address out from the git log.
+
+```
+cwg@drac:/tmp% git annex version
+git-annex version: 8.20210223
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+cwg@drac:/tmp% git init a
+Initialized empty Git repository in /tmp/a/.git/
+cwg@drac:/tmp% cd a
+cwg@drac:/tmp/a% git annex init
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
+cwg@drac:/tmp/a% seq 10 >foo
+cwg@drac:/tmp/a% git annex add foo
+add foo
+ok
+(recording state in git...)
+cwg@drac:/tmp/a% git commit -am 'add foo'
+[main (root-commit) f551362] add foo
+ 1 file changed, 1 insertion(+)
+ create mode 120000 foo
+cwg@drac:/tmp/a% cd ..
+cwg@drac:/tmp% git clone a b
+Cloning into 'b'...
+done.
+cwg@drac:/tmp% cd b
+cwg@drac:/tmp/b% git annex init
+init  (merging origin/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+ok
+(recording state in git...)
+cwg@drac:/tmp/b% seq 20 >bar
+cwg@drac:/tmp/b% git annex add bar
+add bar
+ok
+(recording state in git...)
+cwg@drac:/tmp/b% git commit -am 'add bar'
+[main d064d80] add bar
+ 1 file changed, 1 insertion(+)
+ create mode 120000 bar
+cwg@drac:/tmp/b% git annex copy --to origin bar
+copy bar (to origin...)
+ok
+(recording state in git...)
+cwg@drac:/tmp/b% git annex sync
+commit
+On branch main
+Your branch is ahead of 'origin/main' by 1 commit.
+  (use \"git push\" to publish your local commits)
+
+nothing to commit, working tree clean
+ok
+pull origin
+remote: Enumerating objects: 6, done.
+remote: Counting objects: 100% (6/6), done.
+remote: Compressing objects: 100% (4/4), done.
+remote: Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
+Unpacking objects: 100% (5/5), 496 bytes | 496.00 KiB/s, done.
+From /tmp/a
+   728f1f6..d8ad263  git-annex  -> origin/git-annex
+ok
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+push origin
+Enumerating objects: 32, done.
+Counting objects: 100% (31/31), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (20/20), done.
+Writing objects: 100% (24/24), 2.21 KiB | 1.10 MiB/s, done.
+Total 24 (delta 6), reused 0 (delta 0), pack-reused 0
+To /tmp/a
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      main -> synced/main
+ok
+cwg@drac:/tmp/b% cd ../a
+cwg@drac:/tmp/a% git annex sync
+commit
+On branch main
+nothing to commit, working tree clean
+ok
+merge synced/main
+Merge made by the 'recursive' strategy.
+ bar | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 bar
+ok
+cwg@drac:/tmp/a% cd -
+/tmp/b
+cwg@drac:/tmp/b% git annex sync
+commit
+On branch main
+Your branch is ahead of 'origin/main' by 1 commit.
+  (use \"git push\" to publish your local commits)
+
+nothing to commit, working tree clean
+ok
+pull origin
+remote: Enumerating objects: 1, done.
+remote: Counting objects: 100% (1/1), done.
+remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
+Unpacking objects: 100% (1/1), 223 bytes | 223.00 KiB/s, done.
+From /tmp/a
+   f551362..df99aad  main        -> origin/main
+   d064d80..df99aad  synced/main -> origin/synced/main
+
+Already up to date!
+Merge made by the 'recursive' strategy.
+
+Already up to date.
+ok
+push origin
+Enumerating objects: 1, done.
+Counting objects: 100% (1/1), done.
+Writing objects: 100% (1/1), 248 bytes | 248.00 KiB/s, done.
+Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
+To /tmp/a
+   df99aad..9baa35b  main -> synced/main
+ok
+cwg@drac:/tmp/b% cd -
+/tmp/a
+cwg@drac:/tmp/a% git annex sync
+commit
+On branch main
+nothing to commit, working tree clean
+ok
+merge synced/main
+Already up to date!
+Merge made by the 'recursive' strategy.
+ok
+cwg@drac:/tmp/a% cd -
+/tmp/b
+cwg@drac:/tmp/b% git annex sync
+commit
+On branch main
+Your branch is ahead of 'origin/main' by 1 commit.
+  (use \"git push\" to publish your local commits)
+
+nothing to commit, working tree clean
+ok
+pull origin
+remote: Enumerating objects: 1, done.
+remote: Counting objects: 100% (1/1), done.
+remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
+Unpacking objects: 100% (1/1), 219 bytes | 219.00 KiB/s, done.
+From /tmp/a
+   df99aad..c89cab6  main        -> origin/main
+   9baa35b..c89cab6  synced/main -> origin/synced/main
+
+Already up to date!
+Merge made by the 'recursive' strategy.
+
+Already up to date.
+ok
+push origin
+Enumerating objects: 1, done.
+Counting objects: 100% (1/1), done.
+Writing objects: 100% (1/1), 249 bytes | 249.00 KiB/s, done.
+Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
+To /tmp/a
+   c89cab6..fe3e4ec  main -> synced/main
+ok
+cwg@drac:/tmp/b% cd -
+/tmp/a
+cwg@drac:/tmp/a% git annex sync
+commit
+On branch main
+nothing to commit, working tree clean
+ok
+merge synced/main
+Already up to date!
+Merge made by the 'recursive' strategy.
+ok
+cwg@drac:/tmp/a% cd -
+/tmp/b
+cwg@drac:/tmp/b% git annex sync
+commit
+On branch main
+Your branch is ahead of 'origin/main' by 1 commit.
+  (use \"git push\" to publish your local commits)
+
+nothing to commit, working tree clean
+ok
+pull origin
+remote: Enumerating objects: 1, done.
+remote: Counting objects: 100% (1/1), done.
+remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
+Unpacking objects: 100% (1/1), 221 bytes | 221.00 KiB/s, done.
+From /tmp/a
+   c89cab6..4a018a6  main        -> origin/main
+   fe3e4ec..4a018a6  synced/main -> origin/synced/main
+
+Already up to date!
+Merge made by the 'recursive' strategy.
+
+Already up to date.
+ok
+push origin
+Enumerating objects: 1, done.
+Counting objects: 100% (1/1), done.
+Writing objects: 100% (1/1), 247 bytes | 247.00 KiB/s, done.
+Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
+To /tmp/a
+   4a018a6..8a29705  main -> synced/main
+ok
+cwg@drac:/tmp/b% git log --graph
+*   commit 8a29705a4d1ccb3d2e08284198ac27d974144cee (HEAD -> main, origin/synced/main, synced/main)
+|\  Merge: fe3e4ec 4a018a6
+| | Author: cwg@drac
+| | Date:   Sat Sep 17 23:07:58 2022 +0200
+| |
+| |     Merge remote-tracking branch 'refs/remotes/origin/main'
+| |
+| *   commit 4a018a641d75f0d385399c97bc8ec220b25de252 (origin/main, origin/HEAD)
+| |\  Merge: c89cab6 fe3e4ec
+| |/  Author: cwg@drac
+|/|   Date:   Sat Sep 17 23:07:54 2022 +0200
+| |
+| |       Merge branch 'refs/heads/synced/main'
+| |
+* | commit fe3e4ec39d818b97a666ebeffeb68f026145493e
+|\| Merge: 9baa35b c89cab6
+| | Author: cwg@drac
+| | Date:   Sat Sep 17 23:07:47 2022 +0200
+| |
+| |     Merge remote-tracking branch 'refs/remotes/origin/main'
+| |
+| *   commit c89cab61a76e4488f1c979ba1d7ba0f9c9756e68
+| |\  Merge: df99aad 9baa35b
+| |/  Author: cwg@drac
+|/|   Date:   Sat Sep 17 23:07:40 2022 +0200
+| |
+| |       Merge branch 'refs/heads/synced/main'
+| |
+* | commit 9baa35b4a28cd0f4002a90ea4670a21896b1e5a0
+|\| Merge: d064d80 df99aad
+| | Author: cwg@drac
+| | Date:   Sat Sep 17 23:07:32 2022 +0200
+| |
+| |     Merge remote-tracking branch 'refs/remotes/origin/main'
+| |
+| *   commit df99aad6ba5b4ce375834f909519561b4feaaac1
+| |\  Merge: f551362 d064d80
+| |/  Author: cwg@drac
+|/|   Date:   Sat Sep 17 23:07:16 2022 +0200
+| |
+| |       Merge branch 'refs/heads/synced/main'
+| |
+* | commit d064d809e24868543c6609757750a6dc9cd58274
+|/  Author: cwg@drac
+|   Date:   Sat Sep 17 23:06:15 2022 +0200
+|
+|       add bar
+|
+* commit f55136210ce7844a21a415ba0154d136fd15508f
+  Author: cwg@drac
+  Date:   Sat Sep 17 23:05:09 2022 +0200
+
+      add foo
+```
+"""]]
diff --git a/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_5_4879d44cc69022a71fc8baf8f31a890f._comment b/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_5_4879d44cc69022a71fc8baf8f31a890f._comment
new file mode 100644
index 0000000000..f655c0915c
--- /dev/null
+++ b/doc/forum/Idly_syncing_back_and_forth_creates_commits/comment_5_4879d44cc69022a71fc8baf8f31a890f._comment
@@ -0,0 +1,175 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-09-20T15:53:54Z"
+ content="""
+I can't reproduce that behavior with either the current git-annex
+head, or with git-annex 8.20210223, running the same sequence of commands.
+
+I think that you have git configured not to do fast-forward merges. If you
+compare your transcipt with mine (below), your has "Merge made by the
+'recursive' strategy" where mine has a Fast-forward.
+
+The fast-forwards cause there to be no remaining differences between
+the repos, while making a merge commit means there is always a remaining
+change. Presumably, git would behave the same if you were manually
+doing git pulls and pushes, rather than using git-annex sync.
+
+Probably you have merge.ff set to false, or some similar configuration.
+
+	$ cat ~/sh
+	#!/bin/sh
+	git annex version
+	chmod +w -R a b
+	rm -rf a b
+	git init a
+	cd a
+	git annex init
+	seq 10 > foo
+	git annex add foo
+	git commit -am 'add foo'
+	cd ..
+	git clone a b
+	cd b
+	git annex init
+	seq 20 > bar
+	git annex add bar
+	git commit -am 'add bar'
+	git annex copy --to origin bar
+	git annex sync
+	cd ../a
+	git annex sync
+	cd ../b
+	git annex sync
+	cd ../a
+	git annex sync
+	cd ../b
+	git annex sync
+	cd ../a
+	git annex sync
+	cd ../b
+	git annex sync
+	git log --graph
+	$ sh ~/sh
+	git-annex version: 8.20210128-g5e5829a8d
+	build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+	dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+	key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+	remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+	operating system: linux x86_64
+	supported repository versions: 8
+	upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+	Initialized empty Git repository in /home/joey/tmp/git-annex.linux/bench/a/.git/
+	init  (scanning for unlocked files...)
+	ok
+	(recording state in git...)
+	add foo 
+	ok                                
+	(recording state in git...)
+	[master (root-commit) 9a73c26] add foo
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 foo
+	Cloning into 'b'...
+	done.
+	init  (merging origin/git-annex into git-annex...)
+	(recording state in git...)
+	(scanning for unlocked files...)
+	ok
+	(recording state in git...)
+	add bar 
+	ok                                
+	(recording state in git...)
+	[master d7d507b] add bar
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 bar
+	copy bar (to origin...) 
+	ok                                
+	(recording state in git...)
+	commit 
+	On branch master
+	Your branch is ahead of 'origin/master' by 1 commit.
+	  (use "git push" to publish your local commits)
+	
+	nothing to commit, working tree clean
+	ok
+	pull origin 
+	remote: Enumerating objects: 6, done.
+	remote: Counting objects: 100% (6/6), done.
+	remote: Compressing objects: 100% (4/4), done.
+	remote: Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
+	Unpacking objects: 100% (5/5), 487 bytes | 81.00 KiB/s, done.
+	From /home/joey/tmp/git-annex.linux/bench/a
+	   4153d9e..c70f135  git-annex  -> origin/git-annex
+	ok
+	(merging origin/git-annex into git-annex...)
+	(recording state in git...)
+	push origin 
+	Enumerating objects: 32, done.
+	Counting objects: 100% (31/31), done.
+	Delta compression using up to 4 threads
+	Compressing objects: 100% (20/20), done.
+	Writing objects: 100% (24/24), 2.23 KiB | 2.23 MiB/s, done.
+	Total 24 (delta 5), reused 0 (delta 0), pack-reused 0
+	To /home/joey/tmp/git-annex.linux/bench/a
+	 * [new branch]      git-annex -> synced/git-annex
+	 * [new branch]      master -> synced/master
+	ok
+	commit 
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	merge synced/master 
+	Updating 9a73c26..d7d507b
+	Fast-forward
+	 bar | 1 +
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 bar
+	ok
+	commit 
+	On branch master
+	Your branch is ahead of 'origin/master' by 1 commit.
+	  (use "git push" to publish your local commits)
+	
+	nothing to commit, working tree clean
+	ok
+	pull origin 
+	From /home/joey/tmp/git-annex.linux/bench/a
+	   9a73c26..d7d507b  master     -> origin/master
+	ok
+	commit 
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	commit 
+	On branch master
+	Your branch is up to date with 'origin/master'.
+	
+	nothing to commit, working tree clean
+	ok
+	pull origin 
+	ok
+	commit 
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	commit 
+	On branch master
+	Your branch is up to date with 'origin/master'.
+	
+	nothing to commit, working tree clean
+	ok
+	pull origin 
+	ok
+	* commit d7d507b48282c7496063b7fda83eb3b3add12bb9 (HEAD -> master, origin/synced/master, origin/master, origin/HEAD, synced/master)
+	| Author: Joey Hess <joeyh@joeyh.name>
+	| Date:   Tue Sep 20 12:08:37 2022 -0400
+	| 
+	|     add bar
+	| 
+	* commit 9a73c269c77ca51c72a9730364907e32fa7a4b1d
+	  Author: Joey Hess <joeyh@joeyh.name>
+	  Date:   Tue Sep 20 12:08:36 2022 -0400
+	  
+	      add foo
+
+"""]]
diff --git a/doc/forum/Ignoring_folders__63__.mdwn b/doc/forum/Ignoring_folders__63__.mdwn
new file mode 100644
index 0000000000..55c7884a2d
--- /dev/null
+++ b/doc/forum/Ignoring_folders__63__.mdwn
@@ -0,0 +1 @@
+What is the correct way to ignore subfolders or files?  Just use .gitignore?  Or is there a git-annex specific way?  For example, partial download files.
diff --git a/doc/forum/Ignoring_folders__63__/comment_1_5fbf4d1ae75434118876470b04e2fd72._comment b/doc/forum/Ignoring_folders__63__/comment_1_5fbf4d1ae75434118876470b04e2fd72._comment
new file mode 100644
index 0000000000..f699f19d24
--- /dev/null
+++ b/doc/forum/Ignoring_folders__63__/comment_1_5fbf4d1ae75434118876470b04e2fd72._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-10T16:17:47Z"
+ content="""
+Use .gitignore, there's no need of a git-annex specific way.
+"""]]
diff --git a/doc/forum/Ignoring_folders__63__/comment_2_1adafdf1fddf8e1256e51b0f56d3a89e._comment b/doc/forum/Ignoring_folders__63__/comment_2_1adafdf1fddf8e1256e51b0f56d3a89e._comment
new file mode 100644
index 0000000000..e0095b077e
--- /dev/null
+++ b/doc/forum/Ignoring_folders__63__/comment_2_1adafdf1fddf8e1256e51b0f56d3a89e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="browneej@96fb43ae83ff25c968e65939805b60f3e42f1e06"
+ nickname="browneej"
+ subject="comment 2"
+ date="2016-05-10T22:44:46Z"
+ content="""
+Awesome, thanks.
+"""]]
diff --git a/doc/forum/Import_availability_info___40__logs__47__refs__47__remotes__41___from_another_repo__63__.mdwn b/doc/forum/Import_availability_info___40__logs__47__refs__47__remotes__41___from_another_repo__63__.mdwn
new file mode 100644
index 0000000000..33a8c085f1
--- /dev/null
+++ b/doc/forum/Import_availability_info___40__logs__47__refs__47__remotes__41___from_another_repo__63__.mdwn
@@ -0,0 +1,3 @@
+Is it possible to transfer list of remotes and their file availability information (which files are found on which remotes) from another repository?
+
+My use case would be to combine several repositories that have no copies of the actual files, but which do know of remotes that have them, so that the new composite repository would also know where to get each file.
diff --git a/doc/forum/Import_availability_info___40__logs__47__refs__47__remotes__41___from_another_repo__63__/comment_1_32586d9e43dc0c5d0a9e94671586f763._comment b/doc/forum/Import_availability_info___40__logs__47__refs__47__remotes__41___from_another_repo__63__/comment_1_32586d9e43dc0c5d0a9e94671586f763._comment
new file mode 100644
index 0000000000..23ab14189c
--- /dev/null
+++ b/doc/forum/Import_availability_info___40__logs__47__refs__47__remotes__41___from_another_repo__63__/comment_1_32586d9e43dc0c5d0a9e94671586f763._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-06T19:48:20Z"
+ content="""
+Sure, you can just add one repository as a remote of the other, 
+and `git fetch` and then git-annex will automatically combine
+all the information about remotes and locations of files.
+"""]]
diff --git a/doc/forum/Import_existing_files.mdwn b/doc/forum/Import_existing_files.mdwn
new file mode 100644
index 0000000000..c2957ecf26
--- /dev/null
+++ b/doc/forum/Import_existing_files.mdwn
@@ -0,0 +1,17 @@
+I have not used git-annex before but I wonder whether this is for me.
+
+I have some big existing directories, e.g. with family pictures (several 100 GBs), e.g. in `~/Pictures`. I already have multiple copies of this pictures directory on multiple medias (other (remote) servers, hard drives, some DVDs, etc).
+
+I wonder about the recommended workflow now. In the documentation, it is explained how to create a new Git Annex Repo, where I would copy over the data. But I don't want to copy over the data. I want to keep them in `~/Pictures`, and also make use of other existing copies (I cannot even modify some of them anymore, such as my readonly DVDs).
+
+I thought that Git-Annex would just help me keep track of multiple copies. How would I import such a directory?
+
+I read briefly about Git Worktree, and I wonder whether that is supposed to be for this use case?
+
+Or maybe this should be a bare repo?
+
+Or should I create the new Git Annex Repo directly in `~/Pictures`? I.e. I would do `cd ~/Pictures; git init; git annex init`? How would I now add the other copies of `Pictures`? How would I deal with readonly copies of `Pictures` like DVDs?
+
+Also, I don't just want to store the pictures but also other stuff (e.g. `~/Music`). I'm not sure if I should create separate repos for that, or whether it makes more sense to keep them all in one big repo?
+
+I read [[how it works]] and [[workflow]] but this does not really answers my questions.
diff --git a/doc/forum/Import_existing_files/comment_1_890dea22857d0a38260009602ccf0ec6._comment b/doc/forum/Import_existing_files/comment_1_890dea22857d0a38260009602ccf0ec6._comment
new file mode 100644
index 0000000000..cee0768196
--- /dev/null
+++ b/doc/forum/Import_existing_files/comment_1_890dea22857d0a38260009602ccf0ec6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2020-12-29T23:30:46Z"
+ content="""
+Hi, <br>
+I recommend you to move `~/Pictures` inside a new directory, so that it's at `~/annex/pictures/Pictures`, then initialize the annex `~/annex/pictures` (e.g. `cd ~/annex/pictures; git init; git annex init; git annex add .; git annex sync`). <br>
+For copies that are writable (e.g. external hdd), you should clone that annex onto it, beside the existing data. Then you can use `git annex reinject --known ../existing-Pictures/*.jpg` (unfortunately `git annex reinject` doesn't work recursively) to move them inside the annex. If `git annex reinject` leaves any files in `../existing-Pictures/`, these files where/are not part of the original `~/Pictures` and (because they are unknown) are not copied into the annex.<br>
+You can abuse directory special remotes to track copies on read-only media. E.g. `git annex initremote DVD-01 type=directory encryption=none importtree=yes directory=/mnt/DVD-26/`. Then you can import the DVD to a dummy branch, without copying the content: `git annex import --no-content --from=DVD-01 dummy-DVD-01` This will still update the location log of files in the annex that also are on the DVD so git annex now knows that there are copies of whatever files on the DVD.<br>
+IMHO it's a good idea to create separate repos as adding to many files to a single repo can slow down git-annex.<br>
+You might also want to run `git annex config --set annex.dotfiles true` before adding any files or else dotfiles will be added to git directly.
+
+"""]]
diff --git a/doc/forum/Import_existing_files/comment_2_362ce3b030970db82c8dd0d98791186b._comment b/doc/forum/Import_existing_files/comment_2_362ce3b030970db82c8dd0d98791186b._comment
new file mode 100644
index 0000000000..45887ce220
--- /dev/null
+++ b/doc/forum/Import_existing_files/comment_2_362ce3b030970db82c8dd0d98791186b._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="comment 2"
+ date="2021-01-01T22:30:34Z"
+ content="""
+Hi, thanks for the answer.
+
+What if I would want to leave `~/Pictures` as-is, and not move it, nor change it? I would prefer that. I just want to add its content to a Git Annex repo, and easily sync future changes as well to the repo (e.g. after I added more files, or renamed some files, or updated some files).
+
+Why `git annex sync` and not `git commit`? I always did only `git commit` so far.
+
+Why `git annex reinject` and not `git annex import` or `cp|mv` & `git annex add`?
+Also, why would I not add files which were/are not part of the original `~/Pictures`? The original `~/Pictures` would not have contained all of the pictures, as they are somewhat distributed. So I want to add unknown files as well.
+
+Why would I import the DVD to a dummy branch? I would want it all in my master/main branch, or not? (I also don't quite understand why I would want branches at all?)
+I also potentially want to `git annex get` such a file at some point.
+
+What are \"too many files\" for a single repo? And why is that a problem?
+I am just adding a Google Takeout archive to Git Annex ([via](https://github.com/albertz/chrome-ext-google-takeout-downloader/)), and it will contain also many of the files of `~/Pictures` (although not all; and sometimes, but not always, in smaller quality, but often also in original quality), but also many other files. So it's already pretty mixed up.
+Or does it make sense to just share the Annex object storage (`.git/annex/objects`) in multiple repos?
+Or do you mean that as the intended use case for branches actually?
+
+What dotfiles does `annex.dotfiles` include? Just all `.*`?
+Why would I not want to add dotfiles? I think I would want to just archive the whole directory as-is.
+
+Also, after reading a bit further, and trying it out a bit, I don't quite understand:
+
+Given some file path (e.g. `Picture/BestPics2020/a.jpg`), how can I find other paths of the same file? (E.g. I would also have the file stored under `Picture/2020/01/a.jpg` or so.) Is that with `git annex list`? I'm not sure this lists all paths. So far I only see a single path always.
+
+I'm not really sure how to use `git annex import` properly, in case the file is already annexed under a different path. In any case, I also want to add the new path (new name).
+
+Sorry for the many follow-up questions, but this is still all somewhat unclear to me.
+
+"""]]
diff --git a/doc/forum/Import_existing_files/comment_3_69188f669e6fe5ca1a8c34c3dc3ec201._comment b/doc/forum/Import_existing_files/comment_3_69188f669e6fe5ca1a8c34c3dc3ec201._comment
new file mode 100644
index 0000000000..aed6dac420
--- /dev/null
+++ b/doc/forum/Import_existing_files/comment_3_69188f669e6fe5ca1a8c34c3dc3ec201._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2021-01-02T15:05:01Z"
+ content="""
+You can of course just use `~/Pictures` directly as a repository. So `cd ~/Pictures; git init; git annex init`.
+
+`git annex sync` does a little more things than just `git commit`. For example, it also automatically commits deletion of files.
+
+Sorry, I thought the existing copies of your Photos where just backups of your `~/Pictures`. In that case I suggest you to `mv` the files into the annex and then just `git annex add` them. For DVD's import to a sub-directory of your master branch instead of a dummy branch and without the `--no-content` option.
+
+\"Too many files\" depends on you liking. The more files the slower some operations get, like `git annex sync`. I suggest you to set something like `git annex config --set annex.largefiles 'largerthan=32kb'`. This way, small files get added to git itself instead of git-annex, which speeds up git-annex operations if there are a lot of small files. Note that these small files will be in every clone of the repo and can't be `git annex drop`ed.
+
+The various configuration options are documented in the main [[git-annex]] manpage, at the bottom. Without the `annex.dotfiles` option, dotfiles (any file starting with \".\" and anything inside directories starting with \".\") will still be added, but to git itself with the disadvantages mentioned above.
+
+You can get the key/hash for that file with `git annex info <file>`, and then search for other files with the same content with `find . -lname '*<key>'`.
+
+You can just `cp/mv` the files in the annex and `git annex add` them. Note that for duplicate files in the annex, only one copy of the data/file content will be stored.
+"""]]
diff --git a/doc/forum/Import_existing_files/comment_4_9c7677838ad28d540a2a514d718f9f1d._comment b/doc/forum/Import_existing_files/comment_4_9c7677838ad28d540a2a514d718f9f1d._comment
new file mode 100644
index 0000000000..b0836dd5d2
--- /dev/null
+++ b/doc/forum/Import_existing_files/comment_4_9c7677838ad28d540a2a514d718f9f1d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="comment 4"
+ date="2021-01-04T12:04:04Z"
+ content="""
+That is the best solution with `find`? There is no reverse index? I made a separate forum entry for this question [here](https://git-annex.branchable.com/forum/Reverse_index_key_to_list_of_file_paths/), to discuss that a bit more separately.
+
+Why exactly does `git annex sync` (or other ops) get slower on bigger repos? In principle it could be implemented in a way that it should not get slower (basically always avoiding any need to iterate through all objects, which should always be possible to avoid by having some indices for any operations which needs that).
+
+Does it make sense to split up the repo, but share the Git Annex object files (shared `.git/annex/objects`)?
+
+"""]]
diff --git a/doc/forum/Import_existing_files/comment_5_d88cedb3d70342071621c1695c8aeb05._comment b/doc/forum/Import_existing_files/comment_5_d88cedb3d70342071621c1695c8aeb05._comment
new file mode 100644
index 0000000000..a1062d4244
--- /dev/null
+++ b/doc/forum/Import_existing_files/comment_5_d88cedb3d70342071621c1695c8aeb05._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-01-04T17:17:08Z"
+ content="""
+I think you're really overcomplicating things. Some really basic use of
+git-annex as described in the [[walkthrough]] will work fine in the
+situation you describe. Ie, initialize a git-annex repository in
+~/Pictures. If you have some other servers or hard drives that also have
+pictures, initialize git-annex repositories on those as well. Connect these
+repositories that all hold pictures together, by adding git remotes
+pointing to the other pictures repositories.
+
+Then when you `git push` (or `git-annex sync`), git-annex will automatically
+learn if some picture is stored in multiple of the repositories. You'll be
+able to run commands like `git-annex find --copies 2` or `git-annex drop`
+to operate on that information. Similarly, if Picture/BestPics2020/a.jpg
+and Picture/2020/01/a.jpg were the same content, git-annex will notice that
+when you add them to the annex, and will automatically deduplicate.
+
+If you have readonly DVDs or whatever, yes those can be handled in ways
+like Lukey describes, but why bother trying to deal with all those edge
+cases before you're using git-annex at all?
+
+As far as too many files, git has issues with the index file becoming
+slower with more files, but you need huge numbers of files for this to be a
+significant problem -- think millions. git-annex commands that need to
+operate on all files necessarily take longer when there are more files,
+but git-annex always lets you only operate on a subset of files, such as
+the ones in the current directory, so this is not a significant scalability
+problem. Worrying about speed before something is slow is a kind of
+premature optimisation; git-annex has actually been optimised in cases where
+it was slow.
+"""]]
diff --git a/doc/forum/Import_existing_files/comment_6_be5331f1203b9610259a84c783b429b0._comment b/doc/forum/Import_existing_files/comment_6_be5331f1203b9610259a84c783b429b0._comment
new file mode 100644
index 0000000000..1bbdc572a6
--- /dev/null
+++ b/doc/forum/Import_existing_files/comment_6_be5331f1203b9610259a84c783b429b0._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="comment 6"
+ date="2021-01-06T14:59:00Z"
+ content="""
+Thanks for the answer.
+
+Maybe the forum post title here was chosen badly. It's not just about how to import existing files, but also/mainly I was trying to figure out whether Git Annex fits my needs (for a quite big archive of data). That's why I had all these questions. Also because this was not exactly clear to me after reading the docs.
+
+What's still not exactly clear to me is whether it is not a better idea to keep the Annex repo separate from the checked out files. I don't like all the symlinks too much, and a couple of applications behave strange (because they follow the symlinks). I would prefer a solution where the (maybe bare) repo is separate from the checked out tree.
+
+That is why I asked about Git Worktree. But this is still not clear to me.
+
+I also read about [Git Annex Direct mode](https://git-annex.branchable.com/git-annex-direct/), which sounds like it is exactly that? But apparently this is not supported anymore? Why?
+
+I also read about the [Git Annex Assistant](https://git-annex.branchable.com/assistant/), which also sounds like this? But the docs are somewhat sparse, and its not totally clear how this is done, and why the main Git Annex cannot do that, while Git Annex Assistant can do that. But discussions like [this](https://git-annex.branchable.com/design/assistant/desymlink/) sound very relevant (that describes many of the issues I have with symlinks). But I would not specifically want to do it all automatically (I think that's the purpose of the assistant) but do it explicitly (like adding files to the annex, i.e. using the commands `git annex add` etc).
+
+I think this should be possible without having to watch live for changes (via inotify or so) (where it anyway would be easy to miss changes). E.g. `git status` seems to be very fast at such checks. I'm not exactly sure how it does it but I assume it does some fast checks for changed mtime or maybe other things. Some filesystems might also provide other means. E.g. if the file was copied with a reflink (`cp --reflink`) (which anyway makes sense to not store the data twice, and which is much more efficient), it could check whether the reflink has changed. Or otherwise using hardlinks and locking the files (readonly), and unlocking them would make them writeable (that's ok if unlocked files are less efficient to handle, as this would be a rare action).
+
+"""]]
diff --git a/doc/forum/Import_options.mdwn b/doc/forum/Import_options.mdwn
new file mode 100644
index 0000000000..543d1a4ec8
--- /dev/null
+++ b/doc/forum/Import_options.mdwn
@@ -0,0 +1,14 @@
+Thank you for adding import options to handle duplicates. Very handy when consolidating data from various sources.
+
+Can deletion of the source files be decoupled from annex duplication/deduplication options? For example, I would like to import source files without deleting them and at the same time do not import duplicates.
+
+Better yet, since deletion of source files is potentially dangerous, a delete option could be required for deletion to be performed. Example:
+
+git annex import --deduplicate --delete_all_source_files
+git annex import --deduplicate --delete_source_duplicates
+
+Also, it would be great to have import "status" option which goes over files to be imported and logs their status ( to be imported, duplicate etc. ) without actually performing any changes. It would be great for testing and trial runs.
+
+I hope the above make sense. It would make import feature more flexible.
+
+Cheers, 
diff --git a/doc/forum/Import_options/comment_1_118a5f978090a3909299876a01c0adec._comment b/doc/forum/Import_options/comment_1_118a5f978090a3909299876a01c0adec._comment
new file mode 100644
index 0000000000..3475a0d734
--- /dev/null
+++ b/doc/forum/Import_options/comment_1_118a5f978090a3909299876a01c0adec._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkeJKC5Sy0stmcTWyePOLEVv0G-x1yaT_w"
+ nickname="Josef"
+ subject="wishlist"
+ date="2013-09-26T11:11:19Z"
+ content="""
+Posted the above yesterday before realizing that it should probably go to wishlist requests. I am sorry about that.
+
+Basically it is a request to extend import options and perhaps make the options easier to use/understand.
+
+Suggested Import Options:
+
+- source directory,
+- destination directory,
+- deduplicate in annex ( yes, no )
+- delete source files ( yes, no )
+- trial run ( screen output only )
+
+Many thanks for a great product!
+
+"""]]
diff --git a/doc/forum/Import_options/comment_2_21da91f08cb6b28ae3e79ade033db516._comment b/doc/forum/Import_options/comment_2_21da91f08cb6b28ae3e79ade033db516._comment
new file mode 100644
index 0000000000..a3e2596248
--- /dev/null
+++ b/doc/forum/Import_options/comment_2_21da91f08cb6b28ae3e79ade033db516._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkeJKC5Sy0stmcTWyePOLEVv0G-x1yaT_w"
+ nickname="Josef"
+ subject="Additional Comments"
+ date="2013-09-30T21:33:31Z"
+ content="""
+Imported several thousand files to annex and would like to add the following comments:
+
+- it would be great to have an option to exclude hidden dot files from import,
+
+- empty directories should be deleted when files located in the directories are deleted,
+
+- \"git annex add\" seems to process directories and files alphabetically, unfortunately import processes files in a different order, which makes it hard to predict which files are deleted when deduplicating,
+
+Cheers,
+
+"""]]
diff --git a/doc/forum/Improving_the_git-annex_forum.mdwn b/doc/forum/Improving_the_git-annex_forum.mdwn
new file mode 100644
index 0000000000..30d7a29737
--- /dev/null
+++ b/doc/forum/Improving_the_git-annex_forum.mdwn
@@ -0,0 +1,23 @@
+Dear git-annex community,
+
+git-annex has a great documentation, consisting of the wiki articles and the converted man page. On the other hand, in my opinion there is room for improvement when it comes to the forum. It's lacking quite some features you expect from a modern forum, e.g.
+
+- Slick UI
+- User friendly way to (un)subscribe to threads
+- Bump threads on new replies (that may be a matter of taste)
+- Reply via mail
+- Ability to pin posts (at least I've never seen it)
+- Weird markdown formatting, e.g. marking code by indenting by 4 characters, which is hard to achieve for many lines at once inside a browsers text field (Joey already told me pre does job, too)
+- no private messages
+and more...
+
+Therefore I think, that a better forum would significantly improve git-annex's user experience!
+
+I'm hosting a Discourse forum for some time now and think it's quite a decent, user- and admin friendly software. I would be happy to host a forum for git-annex on my own server, e.g. on a subdomain of git-annex.branchable.com.
+
+I had exchanged some mails with Joey about that, he asked me to take this discussion to the forum...
+
+What are your opinions on that matter?
+
+Best,
+Florian
diff --git a/doc/forum/Improving_the_git-annex_forum/comment_1_63c52c977689a5da34fec65391c25fd6._comment b/doc/forum/Improving_the_git-annex_forum/comment_1_63c52c977689a5da34fec65391c25fd6._comment
new file mode 100644
index 0000000000..0231987f63
--- /dev/null
+++ b/doc/forum/Improving_the_git-annex_forum/comment_1_63c52c977689a5da34fec65391c25fd6._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-01-15T17:33:12Z"
+ content="""
+Thanks, Florian for raising this topic.
+
+Granting the missing features you list (and perhaps adding that people seem
+to sometimes find it annoying to log in successfully here), I wonder how
+much those features are limiting use of this forum, if at all. I suppose
+one way to find out would be to move to another forum and see if traffic
+increases (or SNR or engagement improves).
+
+For myself, having the forum integrated in the git-annex repo is quite
+helpful to me, since I automatically track it along with all the other
+changes to the website, and am sure to see every single post here,
+and it meets my offline/low bandwidth needs. Also I sometimes promote
+forum posts to bug reports or make a commit following up to a forum
+post with a requested feature or fix.
+
+I suspect that the git-annex community is kind of split between people who
+are more comfortable in web forums, and people who are used to mailing
+lists, who are currently being left entirely out in the cold (and probably
+using the irc channel more). It could be that mailman3 with its mix of
+forum and mailing list could better unify the two groups. Or perhaps
+there's no point in trying to do that, and a simple mailing list would be a
+bigger win than changing the forum?
+
+I'm ok with however git-annex users choose to get together and
+talk about it, including ways that I can't/won't use myself (including
+non-free stuff like Slack..). To that end, if people want to get a
+git-annex community going somewhere, be it another forum, or reddit, or
+whatever, I'm fine with the website directing users to it.
+"""]]
diff --git a/doc/forum/Improving_the_git-annex_forum/comment_2_7b4b8d78148f41df332d8f9125ca9842._comment b/doc/forum/Improving_the_git-annex_forum/comment_2_7b4b8d78148f41df332d8f9125ca9842._comment
new file mode 100644
index 0000000000..6557c3be96
--- /dev/null
+++ b/doc/forum/Improving_the_git-annex_forum/comment_2_7b4b8d78148f41df332d8f9125ca9842._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Horus"
+ avatar="http://cdn.libravatar.org/avatar/8f0ee08b98ea5bba76c3fe112c08851c"
+ subject="comment 2"
+ date="2018-02-28T09:09:20Z"
+ content="""
+Thanks, Joey for being open to suggestions!
+
+I was holding my reply back for while to see if more feedbacks comes in. It seems everybody is ok with the current forum. I'm still open to setting up a test forum. Discourse, the forum I have in mind let you couple the forum with a mailing list quite easily.
+
+Best,
+Florian
+
+
+"""]]
diff --git a/doc/forum/Improving_the_git-annex_forum/comment_3_71d5568d2ac64f83dba11100124addd1._comment b/doc/forum/Improving_the_git-annex_forum/comment_3_71d5568d2ac64f83dba11100124addd1._comment
new file mode 100644
index 0000000000..fc025a39bf
--- /dev/null
+++ b/doc/forum/Improving_the_git-annex_forum/comment_3_71d5568d2ac64f83dba11100124addd1._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 3"
+ date="2018-05-03T15:16:58Z"
+ content="""
+For me, the most difficult thing is keeping informed of responses to my questions.
+
+It looks like adding a comment, or creating a new thread, does have the “email comments to me” checkbox but this is un-checked by default. Maybe it should be checked by default? I must be forgetting to check this box. It seems a lot of people ask a question on the forum then never return to read the response, maybe they aren't subscribing? Or maybe there can be a new user preference subscribe to threads I comment on by default, which would check this box for us. That way users who want to stay informed via git checkouts on the forum don't have to worry about un-checking the email comments to me box all the time.
+
+   +++ User friendly way to (un)subscribe to threads
+
+Agreed, it would be nice to have an unsubscribe/subscribe button on every forum thread. I don't know how to do this from Preferences, my PageSpecs don't seem to be working right now.
+
+  ++++ Bump threads on new replies (that may be a matter of taste)
+
+Yes, I think that would be nice. I do care about seeing active threads first. It would also be good to see some visual notification for threads with no responses.
+
+  ++++ Weird markdown formatting
+
+My main issue is being unable to quote people with nice formatting. The default for Markdown quoting, Right bracket, doesn't format well in this forum, so I end up using space plus-plus-plus…
+
+
+
+
+
+
+
+
+"""]]
diff --git a/doc/forum/Improving_the_git-annex_forum/comment_4_847be68ea1992e6c2ceb2c79cfb65f5f._comment b/doc/forum/Improving_the_git-annex_forum/comment_4_847be68ea1992e6c2ceb2c79cfb65f5f._comment
new file mode 100644
index 0000000000..46db4ca821
--- /dev/null
+++ b/doc/forum/Improving_the_git-annex_forum/comment_4_847be68ea1992e6c2ceb2c79cfb65f5f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="test PageSpec"
+ date="2018-05-03T15:32:16Z"
+ content="""
+Also, related to Subscribing. I have created a PageSpec in my user preferences. How can I test this? IE I want to past my PageSpec string somewhere and see which results on https://git-annex.branchable.com/ that PageSpec would return.
+"""]]
diff --git a/doc/forum/Init_a_directory_special_remote_with_already_existing_files.mdwn b/doc/forum/Init_a_directory_special_remote_with_already_existing_files.mdwn
new file mode 100644
index 0000000000..40aa41a4f0
--- /dev/null
+++ b/doc/forum/Init_a_directory_special_remote_with_already_existing_files.mdwn
@@ -0,0 +1,17 @@
+Hi,
+
+I've been a git-annex user for few years now, and I'm progressively migrating old rsync backups into git-annex. Most of the time I create new fresh repos or special remotes and re-upload all data into it. But I'm now facing an issue with this workflow: one of the remote disk I use has a very low connection. Since it has already a complete up-to-date plain copy of all files, I'd like to avoid the "re-upload" phase.
+
+I was thinking of using a directory/rsync special remote, and feed it with the existing local content. But the file names & paths are not the usual plain ones. 
+
+- is this a good idea ?
+
+- if yes, what is the way to retrieve the "special remote" path of each file ? I'm not against scripting a little if necessary.
+
+- if no, what can I do ?
+
+Few additional notes:
+
+- I can't ssh to the remote, this is a windows share with a FAT fs underneath.
+
+- I think I can assume all the remote files are good, they are transfered and checked by rsync.
diff --git a/doc/forum/Init_a_directory_special_remote_with_already_existing_files/comment_1_f2a2f7309145d26d124c73ce6fcb32a5._comment b/doc/forum/Init_a_directory_special_remote_with_already_existing_files/comment_1_f2a2f7309145d26d124c73ce6fcb32a5._comment
new file mode 100644
index 0000000000..47be769a49
--- /dev/null
+++ b/doc/forum/Init_a_directory_special_remote_with_already_existing_files/comment_1_f2a2f7309145d26d124c73ce6fcb32a5._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-03-28T00:59:41Z"
+ content="""
+I think if you don't mind scripting checkout Joey's comment in this thread: [\"Preseeding\" a special remote](https://git-annex.branchable.com/forum/__34__Preseeding__34___a_special_remote/).
+
+Otherwise maybe the following will work. You'll still need to download all of the files to hash them.
+
+UNTESTED:
+Lets say your Windows share data is at mnt/share/data
+
+ * create a new repo on your Windows share at mnt/share/repo1
+ * [git-annex-import](https://git-annex.branchable.com/git-annex-import/) all of your files into the new repo. This probably would download all of the files to generate the hash, then hopefully do a file rename avoiding the re-upload step.
+ * then create a new [directory remote](http://git-annex.branchable.com/special_remotes/directory/) for repo1 at say, mnt/share/remote1
+ * then do a [git-annex-move](https://git-annex.branchable.com/git-annex-move/) of all the files from mnt/share/repo1 to your new empty remote
+ * you could then make a clone of that repo locally, now you have a nice looking working tree locally
+ * then add mnt/share/remote1 as a new remote to your local clone
+
+If you don't care about hashing you could use the [WORM](http://git-annex.branchable.com/backends/) backend avoiding the initial download.
+
+I think, If you don't care about having a nice working tree you could probably use the web special remote and just leave all the files in their messy rsynced state. IE create a local repo, then do `git annex addurl --fast <path>` for each file on your Windows share. See joey's comment on addurl in this [DVD thread](http://git-annex.branchable.com/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/)
+
+
+"""]]
diff --git a/doc/forum/Init_a_directory_special_remote_with_already_existing_files/comment_2_c1740ce07be483d198880f5844fea7e0._comment b/doc/forum/Init_a_directory_special_remote_with_already_existing_files/comment_2_c1740ce07be483d198880f5844fea7e0._comment
new file mode 100644
index 0000000000..7c0708eb2c
--- /dev/null
+++ b/doc/forum/Init_a_directory_special_remote_with_already_existing_files/comment_2_c1740ce07be483d198880f5844fea7e0._comment
@@ -0,0 +1,52 @@
+[[!comment format=mdwn
+ username="oliv5kta@248adc7a643dc1f0ecef26925e357de176d0f6f3"
+ nickname="oliv5kta"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 2"
+ date="2018-04-25T17:49:48Z"
+ content="""
+Thks for the answer, I found many interesting info. I ended up scripting my own crappy stuff, please see below:
+
+-------------
+    # Populate a special remote directory with files from the input source
+    # The current repository is used to find out keys & file names,
+    # but is not used directly to copy/move the files from
+    # WHERE selects which files & repo to look for
+    # MOVE=1 moves files instead of copying them
+
+    alias annex_populate='MOVE= _annex_populate'
+
+    alias annex_populatem='MOVE=1 _annex_populate'
+
+    _annex_populate() {
+      local DST=\"${1:?No dst directory specified...}\"
+      local SRC=\"${2:-$PWD}\"
+      local WHERE=\"${3:-${WHERE:---include '*'}}\"
+      eval git annex find \"$WHERE\" --format='\${file}\\000\${hashdirlower}\${key}/\${key}\\000' | xargs -r0 -n2 sh -c '
+        MOVE=\"$1\"; SRC=\"$2/$4\"; DST=\"$3/$5\"
+        if [ -r \"$SRC\" ]; then
+          echo \"$SRC -> $DST\"
+          mkdir -p \"$(dirname \"$DST\")\"
+          if [ -n \"$MOVE\" -a ! -h \"$SRC\" ]; then
+            mv -f -T \"$SRC\" \"$DST\"
+          else
+            rsync -K -L --protect-args \"$SRC\" \"$DST\"
+          fi
+        fi
+      ' _ \"$MOVE\" \"$SRC\" \"$DST\"
+    }
+
+-------------
+Basic usage: annex_populate(m) /my/destination/folder/ /my/source/folder
+
+Principle: we get each file key from the current repository, then build the special remote backend filename and launch the copy/move operation.
+
+Warning:
+
+  1. before using it, make a backup of your data !
+
+  2. it was very little tested: it worked for me and I stopped there. Like many scripts in my toolbox, it may malfunction in different cases than mine.
+
+  3. it should copy files unless you define MOVE=X (or have it defined in your shell ! beware).
+
+"""]]
diff --git a/doc/forum/Initial_macOS_setup_between_two_local_Macs.mdwn b/doc/forum/Initial_macOS_setup_between_two_local_Macs.mdwn
new file mode 100644
index 0000000000..eadab35172
--- /dev/null
+++ b/doc/forum/Initial_macOS_setup_between_two_local_Macs.mdwn
@@ -0,0 +1,32 @@
+I’m trying to start syncing between two Macs. This is my first time trying to use `git-annex`.
+
+I have Mac #1 with macOS v14 Sonoma, which is an Apple Silicon Mac.
+
+Mac #2, an Intel Macs, has macOS v13 Ventura.
+
+I installed `git-annex` via the disk image (dmg) on both. Each computer has version 10.20231228-g181e14467ffee9d198529efb74c38242e51107c3.
+
+On Mac #1, I start “git-annex” by double-clicking on it in the Finder. It starts up the assistant in Safari. I create a starting git-annex repo there, with a path in my macOS user home folder — or at least I *try*, because the progress of loading the page never finishes after many minutes of waiting and no indication of any further progress.
+
+I found that if I quit `git-annex` in Activity Monitor and then re-launch it, I see the `git-annex` repo listed.
+
+From there, I select `git-annex` Assistant > Configuration > Repositories > Local Computer. I input a Secret Phase, click the “Start Pairing” button, and all seems relatively okay. There is a “Pair in progress” notice in the Assistant, with a “Cancel” button.
+
+On Mac #2, I start “git-annex” in the Finder, and it launches in Safari. I create an initial git-annex repo. Again, this never seems to complete.
+
+I quit `git-annex` in Activity Monitor and then re-launch it, I see the git-annex repo listed as I did on Mac #1.
+
+Mac #2 shows the “<me on another computer> is sending a pair request” notice, with a “Respond” button. I click “Respond,” enter the same Secret Phrase, and click “Finish pairing.”
+
+At this point, Assistant on Mac #1 shows “PairListener crashed: failed setting up ssh authorized keys” with a ”Restart Thread” button. Clicking the button does not seem to help.
+
+Here are things I’ve also checked and/or tried:
+
+1. Enabled “Remote Login” (SSH) in System Settings > General > Sharing on each computer. (I did this before any attempts to share any `git-annex` repositories between the two computers.) This is limited to only my macOS user account on both Macs.
+1. macOS Firewall is set to default (i.e. shows up as “Inactive” on both Macs.
+1. Mac #2 is using Little Snitch (an alternative firewall) in “Silent (Allow)” mode. I don’t get any alerts from its app about `git-annex` or `ssh`, and it is set to allow incoming and outbound traffic. Even with Little Snitch in “Alert Mode,” I do not get any information about `git-annex` or `ssh`.
+1. Doing a manual setup without Assistant, using the “walkthrough” instructions. This has always resulting in “Remote origin does not have git-annex installed” errors, which I surmise are due to the `authorized_keys` and `config` settings for SSH, or just needing a more-permissive-than-macOS-defaults SSH setup.
+1. Starting setup with Assistant, then trying to manually fill in the SSH configuration gaps. This means I’m trying to cobble together what I assume should be the `authorized_keys` and `config` settings for SSH manually. I’ve used the `git-annex` man pages and some ChatGPT to try to sort that out. I haven’t sorted this out yet. I also haven’t been able to have Git work over SSH between the two computers for this purpose. While doing this, I noted that Mac #1 didn’t have any SSH changes made by git-annex Assistant — but interestingly, Mac #2 did get at least the `authorized_keys` changes. It is possible if I simplify what was doing manually, I may get better luck. Mac #2 already has an `~/.ssh/config` setup and `~/.ssh/authorized_keys`.
+1. Assistant setup, after adding the “git-annex.app” to the Full Disk Access list in System Settings > Privacy & Security. I quit all `git-annex` processes and restarted the app from the Finder afterwards on both computers. Same results.
+
+I’m at a bit of a loss here. Thanks in advance for any ideas that could help get this going.
diff --git a/doc/forum/Install_git_annex_v6_in_Ubuntu_14.04_Trusty.mdwn b/doc/forum/Install_git_annex_v6_in_Ubuntu_14.04_Trusty.mdwn
new file mode 100644
index 0000000000..27d53bda6b
--- /dev/null
+++ b/doc/forum/Install_git_annex_v6_in_Ubuntu_14.04_Trusty.mdwn
@@ -0,0 +1 @@
+How can I get v6 for ubuntu trusty?
diff --git a/doc/forum/Install_git_annex_v6_in_Ubuntu_14.04_Trusty/comment_1_9c715cbb0550cad29402dd2fca1917f9._comment b/doc/forum/Install_git_annex_v6_in_Ubuntu_14.04_Trusty/comment_1_9c715cbb0550cad29402dd2fca1917f9._comment
new file mode 100644
index 0000000000..5223290e95
--- /dev/null
+++ b/doc/forum/Install_git_annex_v6_in_Ubuntu_14.04_Trusty/comment_1_9c715cbb0550cad29402dd2fca1917f9._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-05T19:40:48Z"
+ content="""
+I'd suggest using the Linux standalone build if your distribution
+has not yet packaged a new enough version of git-annex.
+
+Or file a bug on your distribution of course, to get them to be more
+proactive. git-annex v6 is at this point 9 months old, and has been
+in Debian since at least May, so I don't know why Ubuntu would be lagging
+on it.
+"""]]
diff --git a/doc/forum/Install_without_root__63__.mdwn b/doc/forum/Install_without_root__63__.mdwn
new file mode 100644
index 0000000000..9a5152b4ba
--- /dev/null
+++ b/doc/forum/Install_without_root__63__.mdwn
@@ -0,0 +1,3 @@
+Hi there,
+
+I would like to install git-annex on a server, but do not have root access.  I am not an experienced linux user and was wondering what the best approach is.  I could clone the git repo but am at a loss what to do next.  Any help would be appreciated!
diff --git a/doc/forum/Install_without_root__63__/comment_1_097bbbde8a91e1d0cee9da6cba23ae5c._comment b/doc/forum/Install_without_root__63__/comment_1_097bbbde8a91e1d0cee9da6cba23ae5c._comment
new file mode 100644
index 0000000000..05d2a40f92
--- /dev/null
+++ b/doc/forum/Install_without_root__63__/comment_1_097bbbde8a91e1d0cee9da6cba23ae5c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2019-06-20T23:48:36Z"
+ content="""
+Use [[install/conda]] .
+"""]]
diff --git a/doc/forum/Install_without_root__63__/comment_2_891cd24fb0806ae9087cd83d22d8ce6e._comment b/doc/forum/Install_without_root__63__/comment_2_891cd24fb0806ae9087cd83d22d8ce6e._comment
new file mode 100644
index 0000000000..16abac6a31
--- /dev/null
+++ b/doc/forum/Install_without_root__63__/comment_2_891cd24fb0806ae9087cd83d22d8ce6e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 2"
+ date="2019-06-21T07:38:36Z"
+ content="""
+Using `conda` doesn't work if it isn't installed and they don't have root..
+
+The [Linux standalone](https://git-annex.branchable.com/install/Linux_standalone/) is very useful for these situations.
+"""]]
diff --git a/doc/forum/Install_without_root__63__/comment_3_23fe7b46c6f48072618f05c1368a8917._comment b/doc/forum/Install_without_root__63__/comment_3_23fe7b46c6f48072618f05c1368a8917._comment
new file mode 100644
index 0000000000..7de451f354
--- /dev/null
+++ b/doc/forum/Install_without_root__63__/comment_3_23fe7b46c6f48072618f05c1368a8917._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2019-06-21T13:49:36Z"
+ content="""
+You don’t need to be root to install conda.  Just download the [installer script](https://docs.conda.io/en/latest/miniconda.html), `chmod u+x`  it to make it executable, run it, and specify an installation directory in your folder.
+"""]]
diff --git a/doc/forum/Install_without_root__63__/comment_4_f015ab0bfed0b440b915c233be73c316._comment b/doc/forum/Install_without_root__63__/comment_4_f015ab0bfed0b440b915c233be73c316._comment
new file mode 100644
index 0000000000..10ae7562a6
--- /dev/null
+++ b/doc/forum/Install_without_root__63__/comment_4_f015ab0bfed0b440b915c233be73c316._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="stephanlindner"
+ avatar="http://cdn.libravatar.org/avatar/78cc245bf89bdcc1005e5443cd8e8b2c"
+ subject="comment 4"
+ date="2019-06-21T19:10:32Z"
+ content="""
+I can confirm that this worked for me.  I installed conda using the installed, then installed git-annex via conda.  Thanks, this is great!
+"""]]
diff --git a/doc/forum/Integrating_annex_get_into_git_checkout_with_hooks.mdwn b/doc/forum/Integrating_annex_get_into_git_checkout_with_hooks.mdwn
new file mode 100644
index 0000000000..5482f78dac
--- /dev/null
+++ b/doc/forum/Integrating_annex_get_into_git_checkout_with_hooks.mdwn
@@ -0,0 +1,7 @@
+I am considering using git annex for an existing work project that is getting bloated with compressed tarballs. We have a team of 7, so making the annex invisible to day to day use is important.
+
+Are there any git hooks that will make the process of git checkout/merge etc automatically do a git annex get ..., our do I have to write these myself?
+
+
+
+
diff --git a/doc/forum/Integrating_annex_get_into_git_checkout_with_hooks/comment_1_7258d0203a0578d0f4e0221295511237._comment b/doc/forum/Integrating_annex_get_into_git_checkout_with_hooks/comment_1_7258d0203a0578d0f4e0221295511237._comment
new file mode 100644
index 0000000000..ed8b0dbe3d
--- /dev/null
+++ b/doc/forum/Integrating_annex_get_into_git_checkout_with_hooks/comment_1_7258d0203a0578d0f4e0221295511237._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-01T20:38:09Z"
+ content="""
+git-annex doesn't set up such hooks, but you can easily make a
+post-checkout and/or post-merge hook that runs, eg "git-annex get"
+
+You might also want a pre-push hook that does "git annex copy --to origin"
+to make sure they upload their annexed files. 
+
+Or, change workflows to use `git annex sync --content`
+"""]]
diff --git a/doc/forum/Integrating_annex_get_into_git_checkout_with_hooks/comment_2_9ca7b7dfc039c443c4afa9b6ea7c78bd._comment b/doc/forum/Integrating_annex_get_into_git_checkout_with_hooks/comment_2_9ca7b7dfc039c443c4afa9b6ea7c78bd._comment
new file mode 100644
index 0000000000..588d82272f
--- /dev/null
+++ b/doc/forum/Integrating_annex_get_into_git_checkout_with_hooks/comment_2_9ca7b7dfc039c443c4afa9b6ea7c78bd._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="ColinW"
+ subject="Re Comment 1"
+ date="2016-01-01T22:39:14Z"
+ content="""
+Yes, it looks simple enough to setup. Just have to test all the git use-cases to ensure it all works before migrating everyone to (transparently) use it. There are only a few big files (~80Mb), so most people won't need to worry about the annex.
+The way I'm going to do it is:
+1. Put hook scripts into git under ./myhooks, so that a git pull will automatically update to latest hooks.
+2. After cloning the git repo, run a setup script to create symlinks from ./.git/hooks/post-checkout etc to the ./myhooks and also setup the annex with something like:
+   git annex init dummy-annex
+   git remote add dummy-annex {ip}:/dummy-annex.git
+
+So the developer does not have to notice the annex.
+Thanks Joey. 
+"""]]
diff --git a/doc/forum/Integrating_git-annex_with_Windows_Git_Extensions__63__.mdwn b/doc/forum/Integrating_git-annex_with_Windows_Git_Extensions__63__.mdwn
new file mode 100644
index 0000000000..2bb88ab0ef
--- /dev/null
+++ b/doc/forum/Integrating_git-annex_with_Windows_Git_Extensions__63__.mdwn
@@ -0,0 +1,10 @@
+I installed the Windows git-annex, and had to run the following command from Git Bash (in Admin mode) in order to get git to see git-annex:
+
+$ ln -s /C/Program\ Files\ \(x86\)/Git/usr/bin/git-annex.exe git-annex.exe
+
+Was this 
+1) a known install issue that I missed somewhere?
+2) a failure in my particular installation?
+3) or was I supposed to put C:\Program Files (x86)\Git\usr\bin in my Windows path?
+
+Wasn't sure if we needed a docs update...
diff --git a/doc/forum/Integrating_git-annex_with_Windows_Git_Extensions__63__/comment_1_2dac6e3ccf559d98f74c456c0ca7aafc._comment b/doc/forum/Integrating_git-annex_with_Windows_Git_Extensions__63__/comment_1_2dac6e3ccf559d98f74c456c0ca7aafc._comment
new file mode 100644
index 0000000000..0cb400e0e2
--- /dev/null
+++ b/doc/forum/Integrating_git-annex_with_Windows_Git_Extensions__63__/comment_1_2dac6e3ccf559d98f74c456c0ca7aafc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="browneej@96fb43ae83ff25c968e65939805b60f3e42f1e06"
+ nickname="browneej"
+ subject="git-annex on windows additional"
+ date="2016-05-10T23:26:48Z"
+ content="""
+PS Program Files (x86)\Git\cmd did get added to the path during install, but git-annex.cmd simply ran 'git annex %*' at the cli.
+"""]]
diff --git a/doc/forum/Integrating_git-annex_with_Windows_Git_Extensions__63__/comment_2_181c6c87c64e4fbe798c108537c6a597._comment b/doc/forum/Integrating_git-annex_with_Windows_Git_Extensions__63__/comment_2_181c6c87c64e4fbe798c108537c6a597._comment
new file mode 100644
index 0000000000..e6ed07f9c7
--- /dev/null
+++ b/doc/forum/Integrating_git-annex_with_Windows_Git_Extensions__63__/comment_2_181c6c87c64e4fbe798c108537c6a597._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-12T19:24:39Z"
+ content="""
+Git for Windows has an option at install time to add it to the path.
+What you pick there should control whether git-annex is in the path or not,
+outside of Git Bash.
+
+In Git Bash, /usr/bin/ is in PATH, so the git-annex.exe in there should be
+seen by git.
+"""]]
diff --git a/doc/forum/Invalid_cross-device_link.mdwn b/doc/forum/Invalid_cross-device_link.mdwn
new file mode 100644
index 0000000000..4dd104c150
--- /dev/null
+++ b/doc/forum/Invalid_cross-device_link.mdwn
@@ -0,0 +1,9 @@
+I want to import from an SD card to a mounted annex:
+
+    user@laptop:/media/.../annex/Pictures/(master)$ git annex import /media/.../sdcard/Download/QuickTransfer
+    [...]
+    git-annex: /media/.../sdcard/Download/QuickTransfer/20150428_192110.jpg: rename: unsupported operation (Invalid cross-device link)
+    [...]
+
+Why is it trying to make a cross-device link? As long as it can read the files, 
+it should be OK, no?
diff --git a/doc/forum/Invalid_cross-device_link/comment_1_46c35e04c8f8cb7205f08aa71cc4912a._comment b/doc/forum/Invalid_cross-device_link/comment_1_46c35e04c8f8cb7205f08aa71cc4912a._comment
new file mode 100644
index 0000000000..96b88cad64
--- /dev/null
+++ b/doc/forum/Invalid_cross-device_link/comment_1_46c35e04c8f8cb7205f08aa71cc4912a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-22T17:19:38Z"
+ content="""
+I do this all the time (most recently 12 hours ago), and have never seen
+this problem. At least not in recent memory.
+
+You didn't say which version of git-annex you are using. Perhaps you
+need to upgrade from some old and broken version...
+
+Looking at the current code, it first tries a rename, and if that
+fails for a reason such as the two locations being on different devices,
+it falls back to using `cp`.
+"""]]
diff --git a/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term.mdwn b/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term.mdwn
new file mode 100644
index 0000000000..76ff2f35c4
--- /dev/null
+++ b/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term.mdwn
@@ -0,0 +1,20 @@
+I finally managed to dig a bit into annex, but I am still unsure if it's the right tool for me. It certainly feels close.
+Maybe I'll describe what I am looking for:
+
+- on my laptop (and maybe a second machine) I want to have a repo with the metadata of all my files (files as in music, video, photos, books, documents, things that I want to keep - but not a backup of my work files)
+- I want to have x number of external hard drives and a cloud account that form my storage
+- I want to be able to say "these files go into the cloud", "these files just stay on local storage"
+- I want to be able to say how many copies should exist (music=1, video=1, photos=2, ...)
+- I want all files in storage to be encrypted, at least in the cloud
+- I want to be able tot verify that my files are free (and stay free) of bit rot
+- I want to be able to locate which files are on which disk so I can attach it if needed
+- I want to be able to "materialize" files on my client machines as I need them, and drop the back to storage when I don't anymore
+- I want to be able to recover my repo if my laptop gets stolen
+- If the whole setup somehow breaks I would like to still be able to get access to the files on the drives
+- If a storage drive dies I want to be able to add a new one that takes over (with little manual work)
+- I don't want to think about disk sizes. If one drive is full - store it on the other drive. If all is full - let me know.
+- I don't need these files to be versioned, in fact I don't want them to be versioned as they are mostly binary and will take up unnecessary space
+- I want to use healthy project with more than one contributor (bus, virus, ... you never know)
+
+To me it seems annex checks most of the boxes - but on some I didn't manage to find out yet.
+Any input on whether I could make annex work for me?
diff --git a/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_1_9984f65d6e89f0f88b33cbd499e859eb._comment b/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_1_9984f65d6e89f0f88b33cbd499e859eb._comment
new file mode 100644
index 0000000000..35446a2ae7
--- /dev/null
+++ b/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_1_9984f65d6e89f0f88b33cbd499e859eb._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2020-11-27T18:46:04Z"
+ content="""
+Compared to other projects, git-annex meets most of your requirements (1-13; and 14 with a quirk). I myself have been looking for alternatives to git-annex (mainly for performance reasons), but there simply are none. <br>
+To not version Files (14), you can delete/drop old versions by listing unused keys (using `git-annex-unused`), then force drop them and mark them as dead (using `git annex dead --key`).
+"""]]
diff --git a/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_2_d7bdfeb33bac7f139b0bdc1c6fb53237._comment b/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_2_d7bdfeb33bac7f139b0bdc1c6fb53237._comment
new file mode 100644
index 0000000000..08832f7c89
--- /dev/null
+++ b/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_2_d7bdfeb33bac7f139b0bdc1c6fb53237._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="tcurdt@9d3ccb47a593bf70ac547ddae8fa634048b87ddf"
+ nickname="tcurdt"
+ avatar="http://cdn.libravatar.org/avatar/cdf5f524330ccabaeda576749a34a30b"
+ subject="comment 2"
+ date="2020-11-28T16:49:47Z"
+ content="""
+Thanks for the input, Lukey.
+Can you expand on the performance issues? What became the bottleneck for you? and when?
+"""]]
diff --git a/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_3_7dc224cb0b88bf07879e03717efffa17._comment b/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_3_7dc224cb0b88bf07879e03717efffa17._comment
new file mode 100644
index 0000000000..04a1d7bc97
--- /dev/null
+++ b/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_3_7dc224cb0b88bf07879e03717efffa17._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2020-11-29T15:37:21Z"
+ content="""
+My problem is that `git annex sync --content --all` takes more time the more annexed files there are. For a repo here with ~260000 files, it takes ~3 Minutes (on an 11 Year old Athlon II X2 245).
+"""]]
diff --git a/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_4_a538f8a4272b5ce134607dc7201e3f04._comment b/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_4_a538f8a4272b5ce134607dc7201e3f04._comment
new file mode 100644
index 0000000000..e438b9a041
--- /dev/null
+++ b/doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term/comment_4_a538f8a4272b5ce134607dc7201e3f04._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-12-15T17:19:00Z"
+ content="""
+@Lukey, I seem to remember the speed of that recently doubled, so 
+I guess despite the low-ish bus factor, there's some hope it will continue
+to get faster. :)
+"""]]
diff --git a/doc/forum/Is_S3___34__Standard-Infrequent_Access__34___storage_class_supported__63__.mdwn b/doc/forum/Is_S3___34__Standard-Infrequent_Access__34___storage_class_supported__63__.mdwn
new file mode 100644
index 0000000000..f8760be5de
--- /dev/null
+++ b/doc/forum/Is_S3___34__Standard-Infrequent_Access__34___storage_class_supported__63__.mdwn
@@ -0,0 +1 @@
+Does `git-annex` support retrieving files from S3 if the remote objects have been moved to the "Standard-Infrequent Access" storage class via a AWS lifecyle rule?
diff --git a/doc/forum/Is_S3___34__Standard-Infrequent_Access__34___storage_class_supported__63__/comment_1_ddc2a1f2b1d810a40b459896993d2e8d._comment b/doc/forum/Is_S3___34__Standard-Infrequent_Access__34___storage_class_supported__63__/comment_1_ddc2a1f2b1d810a40b459896993d2e8d._comment
new file mode 100644
index 0000000000..44d2f5cd76
--- /dev/null
+++ b/doc/forum/Is_S3___34__Standard-Infrequent_Access__34___storage_class_supported__63__/comment_1_ddc2a1f2b1d810a40b459896993d2e8d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-21T16:11:30Z"
+ content="""
+Retrieval will work just fine.
+
+As for storing files with this storage class already set, it's implemented
+in the `s3-classes` branch, but merging that is blocked on a patch being
+made to the aws library.
+"""]]
diff --git a/doc/forum/Is___96__sync_--cleanup__96___by_default_a_bad_idea__63__.mdwn b/doc/forum/Is___96__sync_--cleanup__96___by_default_a_bad_idea__63__.mdwn
new file mode 100644
index 0000000000..8b3fb05a84
--- /dev/null
+++ b/doc/forum/Is___96__sync_--cleanup__96___by_default_a_bad_idea__63__.mdwn
@@ -0,0 +1,3 @@
+While going through the docs, I found that `sync --cleanup` will remove the `synced/*` branches after completing a sync.
+
+Is there any reason why it would be a bad idea to use that flag as a default for my own use. I like the clean aspect of not having those branches around, but I don't know if there's a good reason why I would want to keep them.
diff --git a/doc/forum/Is___96__sync_--cleanup__96___by_default_a_bad_idea__63__/comment_1_51e5f78a1cbd37598f3f0f6746df7320._comment b/doc/forum/Is___96__sync_--cleanup__96___by_default_a_bad_idea__63__/comment_1_51e5f78a1cbd37598f3f0f6746df7320._comment
new file mode 100644
index 0000000000..e944e69bc3
--- /dev/null
+++ b/doc/forum/Is___96__sync_--cleanup__96___by_default_a_bad_idea__63__/comment_1_51e5f78a1cbd37598f3f0f6746df7320._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-11-14T16:45:31Z"
+ content="""
+`git-annex sync --cleanup` does not do any of the pushing and pulling that
+`git-annex sync` does without the option. So you would want to run the
+command once without the option, and then once with it.
+
+Besides being extra work, `git-annex sync --cleanup` can delete sync
+branches that have not yet been merged. That's the point of it after all;
+the docs for it discuss a situation where you would want it to do that. But
+usually you do want to let the sync branches be merged.
+
+My recommendation would be to not use the option unless you actually need
+it.
+"""]]
diff --git a/doc/forum/Is_an_automagic_upgrade_of_the_object_directory_safe__63__.mdwn b/doc/forum/Is_an_automagic_upgrade_of_the_object_directory_safe__63__.mdwn
new file mode 100644
index 0000000000..5643f6b7a0
--- /dev/null
+++ b/doc/forum/Is_an_automagic_upgrade_of_the_object_directory_safe__63__.mdwn
@@ -0,0 +1,9 @@
+Consider the following two use cases:
+
+* I have a git-annex repo on a portable medium and carry it around between several machines. I use it on a non-important system with the most current git-annex installed, automagic upgrade happens. I am now forced to upgrade git-annex on all other machines. Bonus points if this happens in the background and I don't even notice it until it's too late.
+
+* My system crashes and I use a rescue CD to access local data, including git-annex. The rescue CD includes a newer version of git-annex and once my system is restored, I am forced to upgrade git-annex locally.
+
+My suggestion would be not to upgrade automatically, but to either ask the user if this is OK or to error out and request that they run git annex update by hand.
+
+Optionally, this could be done via a local config variable which should default to error or ask, not upgrade.
diff --git a/doc/forum/Is_an_automagic_upgrade_of_the_object_directory_safe__63__/comment_1_c25900b9d2d62cc0b8c77150bcfebadf._comment b/doc/forum/Is_an_automagic_upgrade_of_the_object_directory_safe__63__/comment_1_c25900b9d2d62cc0b8c77150bcfebadf._comment
new file mode 100644
index 0000000000..8420d7bb3a
--- /dev/null
+++ b/doc/forum/Is_an_automagic_upgrade_of_the_object_directory_safe__63__/comment_1_c25900b9d2d62cc0b8c77150bcfebadf._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-03-18T00:38:51Z"
+ content="""
+These are good examples; I think you've convinced me at least for upgrades going forward after v2. I'm not sure we have enough users and outdated git-annex installations to worry about it for v1.
+
+(Hoping such upgrades are rare anyway.. Part of the point of changes made in v2 was to allow lots of changes to be made later w/o needing a v3.)
+
+Update: Upgrades from v1 to v2 will no longer be handled automatically
+now.
+"""]]
diff --git a/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__.mdwn b/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__.mdwn
new file mode 100644
index 0000000000..4fb3d05af9
--- /dev/null
+++ b/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__.mdwn
@@ -0,0 +1,18 @@
+So suppose you put an existing folder under git-annex control, like this:
+
+    cd Archive_of_all_my_files
+    git init .
+    git annex init "Archive Folder"
+    git annex add .
+
+And now you forget the last step:
+
+    git commit -am "init"
+
+Instead, you fool around with git. After all, isn't git designed to keep your data safe and make sure there's no way you can accidentally lose it? The only branch that exists is 'git-annex', so you switch to that branch to see what it is:
+
+    git checkout git-annex
+
+This command switches to the branch git-annex and makes a mess in the working directory. And you can't switch back to master since master does not have any commits. Is there a clean way to go back? I tried 'git checkout --orphan master', but the messy files stayed in the working directory. In the meantime, there should probably be a warning on the walkthrough page.
+
+I think git / git annex should warn you before switching the branch in this rare situation.
diff --git a/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_1_f9decde3955f10148febc4646fba5a68._comment b/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_1_f9decde3955f10148febc4646fba5a68._comment
new file mode 100644
index 0000000000..ed1c52d449
--- /dev/null
+++ b/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_1_f9decde3955f10148febc4646fba5a68._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 1"
+ date="2013-07-02T05:28:00Z"
+ content="""
+Yes, any git repository where there has not been an initial commit made is in an unusal situation. I've often felt this is a design flaw of git; it could start off with an empty root 00000 commit and avoid this complexity.
+
+There are probably all kinds of fancy git commands that can be used to get out of the situation you describe, but finessing a perfect exit from a situation that has happened in the first 5 minutes of using a new repository seems like overkill. Just run `git annex unannex` to move all your files out of git-annex; run `git rm -rf .` to delete the files from the git-annex branch; run `rm -rf .git`, and you're back where you started with some files and no git repository.
+
+... And no, neither git nor git-annex make any promises about keeping your data secure until you have both committed it and sent it somewhere else.
+"""]]
diff --git a/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_2_ed32a48edce4f150bedf24cfe91de254._comment b/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_2_ed32a48edce4f150bedf24cfe91de254._comment
new file mode 100644
index 0000000000..946fcefa7f
--- /dev/null
+++ b/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_2_ed32a48edce4f150bedf24cfe91de254._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 2"
+ date="2013-07-02T05:29:00Z"
+ content="""
+Oh and no, I don't think it's useful to bog down the walkthrough with warnings and caveats about this type of thing.
+"""]]
diff --git a/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_3_ef9618850e5e688bac3c646983f00ed8._comment b/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_3_ef9618850e5e688bac3c646983f00ed8._comment
new file mode 100644
index 0000000000..f29fc8f813
--- /dev/null
+++ b/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_3_ef9618850e5e688bac3c646983f00ed8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnHRhCe3qwVKQ8_NOGGSYJnAMW6FFyKbOc"
+ nickname="Holger"
+ subject="comment 3"
+ date="2013-07-02T05:52:10Z"
+ content="""
+Thanks for your helpful response. The cleaning procedure that you propose is perfectly fine.
+
+I wasn't suggesting to put up a big warning sign; I just feel like the walkthrough would be a little smoother if it explained something like: hey, 'git annex add .' just moved all of your precious files to '.git/annex/' and renamed them in a way that may scare you. But don't worry: if, at any point, you want to get them out again and put them back in their original place, just run 'git annex unannex'.
+"""]]
diff --git a/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_4_4bf460c5826c36b205e418c4f3f7d770._comment b/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_4_4bf460c5826c36b205e418c4f3f7d770._comment
new file mode 100644
index 0000000000..9d5dc042c5
--- /dev/null
+++ b/doc/forum/Is_git-annex_in_a_precarious_state_before_the_initial_commit__63__/comment_4_4bf460c5826c36b205e418c4f3f7d770._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="87.194.19.134"
+ subject="comment 4"
+ date="2013-10-22T11:28:52Z"
+ content="""
+I've had this a few times (or situations very similar).
+
+    git init
+is now always followed by
+
+    git commit -m \"CREATE GIT REPOSITORY\" --allow-empty
+
+.. which I should really set as an alias :)
+"""]]
diff --git a/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools.mdwn b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools.mdwn
new file mode 100644
index 0000000000..0ad353c4b9
--- /dev/null
+++ b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools.mdwn
@@ -0,0 +1,12 @@
+Hello,
+
+at first I want to thank for the work on git annex. I started using git annex for managing my media files (digital photo and video data), which means loads of raw photographs and big video files that I have spread over some harddisks and need to keep track of locations and backups. Works quite well so far.
+
+A few years ago I build a small tool to offload camera memory cards with checksum/hash verification as it is common on film sets, copying all the content of the card and afterwards rereading and comparing all files to catch bitflips in transfer etc. All that while allowing copying to multiple target devices at the same time.
+
+I'd now like to include this workflow with git annex, allowing me to copy a memory card onto two or more annexed directories with this copy & verify workflow while using this hash directly for git annex and having both copies checked into annex at the end instead of like now copying and adding to annex afterwards. What would be an elegant solution?
+
+My naive thinking would be to move the file to the .git/annex/objects/ folder after hash creation and get it correctly registered in the annex management data somehow. Reason is to reduce the time consumed as I have the copy & verify anyway and would prefer to have it annex ready with as little overhead as possible.
+
+Cheers,
+Ingmar
diff --git a/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_1_5c593876993bef4dfaa052278a3ba5be._comment b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_1_5c593876993bef4dfaa052278a3ba5be._comment
new file mode 100644
index 0000000000..1893d0e71a
--- /dev/null
+++ b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_1_5c593876993bef4dfaa052278a3ba5be._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2019-10-19T21:10:55Z"
+ content="""
+Try [[git-annex-setkey]] or (safer) [[git-annex-reinject]]; more generally, check the PLUMBING COMMANDS section of the [[man page|git-annex]].
+"""]]
diff --git a/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_2_02ecc1b9f370f6bba84dd598030e0fcd._comment b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_2_02ecc1b9f370f6bba84dd598030e0fcd._comment
new file mode 100644
index 0000000000..4889716487
--- /dev/null
+++ b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_2_02ecc1b9f370f6bba84dd598030e0fcd._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-10-21T18:52:22Z"
+ content="""
+Both git-annex setkey and git-annex reinject check 
+the hash of the file before moving it into the annex. But you can set
+annex.verify=false to prevent setkey from hashing.
+
+Eg, if you know you have a file `/mnt/foo` with size 11 and
+SHA1 hash x, you can use this shell code to add the file to
+the git-annex repository:
+
+	KEY=SHA1-s11--x
+	OBJECT=$(git annex examinekey $KEY --format='.git/annex/objects/${hashdirmixed}${key}/${key}')
+	ln -s $OBJECT foo
+	git add foo
+	git -c annex.verify=false annex setkey $KEY /mnt/foo
+
+To scale this to handle a lot of files, you can use the --batch option to
+examinekey to avoid starting a lot of processes. There is not currently
+a --batch option for setkey (maybe there should be), but setting
+annex.alwayscommit=false will speed up repeated runs of it some.
+"""]]
diff --git a/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_4_7d9d45716e9e847f3bde214949796222._comment b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_4_7d9d45716e9e847f3bde214949796222._comment
new file mode 100644
index 0000000000..8b94b6661c
--- /dev/null
+++ b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_4_7d9d45716e9e847f3bde214949796222._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="irieger"
+ avatar="http://cdn.libravatar.org/avatar/83622f3c2fedea51e69f9a3986f95d73"
+ subject="comment 3"
+ date="2019-10-22T06:54:43Z"
+ content="""
+Hey, thank you for those comments.
+
+Tried your example joey and it seems to do exactly what I was thinking of. Now I have the roadmap I will adapt my tool to.
+
+Just a few more small questions:
+
+1.) How can I trigger the *(recording state in git...)* after throwing in files with *git -c annex.verify=false -c annex.alwayscommit=false annex setkey ...*?
+
+2.) Can setkey be used on multiple repositories for the same file and then have the file exists in multiple copies after this without an *annex copy*? (Of course only one symlink generation and *git add*)
+
+So thanks again for the fast replies.
+
+-- Ingmar
+"""]]
diff --git a/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_4_ba3422afc8ae83bd822616cc1a99a5b9._comment b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_4_ba3422afc8ae83bd822616cc1a99a5b9._comment
new file mode 100644
index 0000000000..541b20db21
--- /dev/null
+++ b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_4_ba3422afc8ae83bd822616cc1a99a5b9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="re: setkey"
+ date="2019-10-28T22:12:51Z"
+ content="""
+\"How can I trigger the (recording state in git...) after throwing in files with git -c annex.verify=false -c annex.alwayscommit=false annex setkey ...\" -- [[manpage|git-annex]] says \"You can later commit the data by running git annex merge (or by automatic merges) or git annex sync.  You should beware running git gc when using this configuration, since it could garbage collect objects that are staged in git-annex's index but not yet committed.\"  I myself was wondering if there is a more lightweight way of doing this.
+
+\"Can setkey be used on multiple repositories for the same file and then have the file exists in multiple copies after this without an annex copy?\" -- I think setkey *moves* the file into annex?  [[git-annex-import]] has a `--duplicate` flag to preserve the original, but setkey doesn't.  Check out also [[tips/local_caching_of_annexed_files]] for how to use one annex as backing storage for several repos.
+"""]]
diff --git a/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_5_d8c402765b3a5896db91605f43149001._comment b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_5_d8c402765b3a5896db91605f43149001._comment
new file mode 100644
index 0000000000..93343ce502
--- /dev/null
+++ b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_5_d8c402765b3a5896db91605f43149001._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="irieger"
+ avatar="http://cdn.libravatar.org/avatar/83622f3c2fedea51e69f9a3986f95d73"
+ subject="comment 5"
+ date="2019-11-04T08:30:07Z"
+ content="""
+Ok, thanks.
+
+My second question was formulated not quite well. Of course I meant multiple checkouts of this one repository. That in the end is my use case that I have multiple checksum verified copies of all my images/movie clips in one go.
+
+Did quite a bit of testing over the past weeks and stuff seams working well so far.
+
+Here is a sample bash script I used to experiment that shows the workflow if anyone is interested. (Just an example, seems to do basically the same as git annex add $FILE as it is):
+
+    #!/bin/bash
+    
+    FILE=$1
+    echo \"Adding file '$FILE'\"
+    
+    HASH=$(sha256sum \"$FILE\" | sed 's/[^a-fA-F0-9].*//')
+    SIZE=$(stat --printf=\"%s\" \"$FILE\")
+    EXT=$(echo \"${FILE##*.}\" | tr '[:upper:]' '[:lower:]')
+    KEY=\"SHA256E-s${SIZE}--${HASH}.${EXT}\"
+    OBJECT=$(git annex examinekey $KEY --format='.git/annex/objects/${hashdirmixed}${key}/${key}')
+    
+    echo \"    ext:    $EXT\"
+    echo \"    sha256: $HASH\"
+    echo \"    size:   $SIZE\"
+    echo \"    KEY:    $KEY\"
+    echo \"    OBJECT: $OBJECT\"
+    
+    git -c annex.verify=false -c annex.alwayscommit=false annex setkey \"$KEY\" \"$FILE\"
+    ln -s \"$OBJECT\" \"$FILE\"
+    git add \"$FILE\"
+
+Kind regards,
+Ingmar
+"""]]
diff --git a/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_6_2d78e647a46cfbb002cf66e6318043ab._comment b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_6_2d78e647a46cfbb002cf66e6318043ab._comment
new file mode 100644
index 0000000000..1fe3d65311
--- /dev/null
+++ b/doc/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/comment_6_2d78e647a46cfbb002cf66e6318043ab._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 6"
+ date="2019-11-04T16:40:52Z"
+ content="""
+Great that it's working.
+
+Not sure if relevant to your case, but one other way to have multiple checkouts of one repo is [[tips/Using_git-worktree_with_annex]].  Each checkout must be of a different branch though.  On the plus side, they all share one annex, so there is only one copy of each annexed file (for locked files).
+"""]]
diff --git a/doc/forum/Is_it_possible_to_cherry_pick_from_a_repo__63__.mdwn b/doc/forum/Is_it_possible_to_cherry_pick_from_a_repo__63__.mdwn
new file mode 100644
index 0000000000..bcd90e4c19
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_cherry_pick_from_a_repo__63__.mdwn
@@ -0,0 +1,5 @@
+I have a large USB hard disk where I store all my projects and a computer with a rather small SSD.
+The SSD holds only projects that are active, they are my "working copy". 
+Whenever I connect the USB drive to the computer, I want it to be updated from the SSD.
+
+What would be the best possible setup for that? Is it possible at all? How would I tag certain projects as active?
diff --git a/doc/forum/Is_it_possible_to_cherry_pick_from_a_repo__63__/comment_1_82efe5c0b37fdcb31b6a4ca62b66123f._comment b/doc/forum/Is_it_possible_to_cherry_pick_from_a_repo__63__/comment_1_82efe5c0b37fdcb31b6a4ca62b66123f._comment
new file mode 100644
index 0000000000..68253107e9
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_cherry_pick_from_a_repo__63__/comment_1_82efe5c0b37fdcb31b6a4ca62b66123f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-03-25T18:26:30Z"
+ content="""
+Yes, of course. This is a core feature of git-annex ans is done with [[git-annex-preferred-content]]. <br>
+First step is to let the usb drive want anything with `git annex wanted here anything`. Then you need to tell git-annex what files you want on the SSD. There are multiple ways to do that:
+
+The simplest one is to set the preferred-content expression on the SSD to something like `include=path/to/project_a or include=path/to/project_b or include=...` and so on.
+
+Or you can just decide manually what files to keep on the SSD with `git annex get`. Then you set the preferred-content expression to just `present`. I think that this should work pretty well with your workflow, since new files will appear first on the SSD and thus are already present.
+
+Tags are the most complicated way to do this. You basically set the preferred-content expression to something like `metadata=tag=keeponssd`. Then you tag the files you want to keep on the SSD with `git annex metadata --force -t keeponssd path/to/project_a` (--force makes it recursive). The disadvantage is that if you add new files, you have to manually tag them too or else they will be dropped with the next `git annex sync --content --all`.
+
+To update/sync changes back to the usb drive, you just run `git annex sync --content --all`. With --all, it will also copy old versions of files to the usb drive.
+"""]]
diff --git a/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__.mdwn b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__.mdwn
new file mode 100644
index 0000000000..1d19bf27e4
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__.mdwn
@@ -0,0 +1,3 @@
+I'm slowly adding metadata to https://github.com/ocharles/papers. For now, I'm mainly interested in setting `year` and `author` fields on files. There are a lot of files here though, so it's difficult to to work out which need metadata and which don't.
+
+Would it be possible to have a `git annex metadata -s author='*'` also have all files in the top level if they don't have an author set at all, or something? Basically, I'm looking for a way to get a view where files don't have `author` set at all, so I can fix that.
diff --git a/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_1_f452c911b24ba40aef3be5bdaac9f9ee._comment b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_1_f452c911b24ba40aef3be5bdaac9f9ee._comment
new file mode 100644
index 0000000000..032811d3c2
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_1_f452c911b24ba40aef3be5bdaac9f9ee._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2016-04-29T10:04:55Z"
+ content="""
+You can do this, but it involves setting that field's value to something.
+
+    git annex metadata -s field?=untagged
+
+This will tag all files that don't have any 'field' values with 'untagged', so when you switch to the view, they will show up under 'untagged' (and you move/commit them to tag them).
+"""]]
diff --git a/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_2_7373ec002ca78f4f382ef9297f39639e._comment b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_2_7373ec002ca78f4f382ef9297f39639e._comment
new file mode 100644
index 0000000000..e8b2f29408
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_2_7373ec002ca78f4f382ef9297f39639e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ollie@6d66b5a4b0992998efe3e4c244a66708bf5d96f3"
+ nickname="ollie"
+ subject="comment 2"
+ date="2016-04-29T15:04:17Z"
+ content="""
+Thanks! That will do the job :)
+"""]]
diff --git a/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_3_cda315119bd3ccce74bc3df8dd56bf1a._comment b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_3_cda315119bd3ccce74bc3df8dd56bf1a._comment
new file mode 100644
index 0000000000..46b724ec92
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_3_cda315119bd3ccce74bc3df8dd56bf1a._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-05-03T17:48:07Z"
+ content="""
+Actually, you can do it without setting the field to a dummy value.
+
+For example, to find all files without an author metadata:
+
+	git annex find --not --metadata 'author=*'
+
+Same switches can be used with other commands, including the metadata
+command.
+
+You can also use the git-annex view command to enter a branch that only
+contains the files without metadata set:
+
+	git annex view 'author!=*'
+
+(Unfortunately, adding metadata to a file does not currently update this
+view branch.)
+"""]]
diff --git a/doc/forum/Is_it_possible_to_make_git-sync_not_nullify_symlinks__63__.mdwn b/doc/forum/Is_it_possible_to_make_git-sync_not_nullify_symlinks__63__.mdwn
new file mode 100644
index 0000000000..9c41acb707
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_make_git-sync_not_nullify_symlinks__63__.mdwn
@@ -0,0 +1,23 @@
+Hey,
+
+I've found that git annex works great as a way to publish websites to a web server.  I can edit my website on my computer, `git annex sync` my working directory to the VPS, and then `git annex get files-I-want-to-publish`.  This works great.  I can maintain my normal working directory structure on the VPS and I don't have to worry about people seeing files I DIDN'T want to publish, since the dead symlinks just show up as 404s.
+
+There's one small problem.  
+
+Say:
+
+ 1) I've already published a file using `git annex get file-to-update`
+
+ 2) I update that file on my computer
+
+ 3) I do `git annex sync`
+
+ 4) I do `git annex get file-to-update`
+
+Between steps 3 and 4, file-to-update goes from being an accessible web resource to being a dead symlink.  It's not really a problem for me, as hardly anyone visits my site. But it would be nice if I could make `sync` leave the old symlink to the old file until I `get`ed the new one.
+
+Is this possible?
+
+PS: For those who might follow in my footsteps, remember that you probably don't want people reading the contents of your .git dir, so make a re-write rule for this!
+
+Timothy
diff --git a/doc/forum/Is_it_possible_to_make_git-sync_not_nullify_symlinks__63__/comment_1_d6f2d2cdc5f4ffde9eee9f3a8c215a06._comment b/doc/forum/Is_it_possible_to_make_git-sync_not_nullify_symlinks__63__/comment_1_d6f2d2cdc5f4ffde9eee9f3a8c215a06._comment
new file mode 100644
index 0000000000..0c20b9dd69
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_make_git-sync_not_nullify_symlinks__63__/comment_1_d6f2d2cdc5f4ffde9eee9f3a8c215a06._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 1"
+ date="2013-08-07T16:18:52Z"
+ content="""
+I'd recommend that you just copy your files to the repository to publish them before running git-annex sync.
+
+Alternatively, unless your web pages are very large, you can just check them into git directly, still use git-annex sync if you want (and still using git-annex for large files), and avoid the complication of being able to have files that are listed in the repository but whose content is not present.
+"""]]
diff --git a/doc/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__.mdwn b/doc/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__.mdwn
new file mode 100644
index 0000000000..155e78c4b5
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__.mdwn
@@ -0,0 +1,25 @@
+I have a server on a network (```SRV1```), several clients (```CLI-N```) on another and a ```archive``` repo on AWS Glacier. ```CLI```s can access ```SRV1```, but ```SRV1``` cannot access ```CLI```s network. I'd like to use git-annex to synchronize files between clients and archival on Glacier.
+
+My current setup:
+
+- ```SRV1``` contains:
+  - ```transfer``` repository (```T1```)
+  - glacier ```archive``` repo (```G1```)
+- ```CLI-01``` contains:
+  - ```user files``` repo (```U1```)
+  - ```transfer``` repository (```T1```)
+- ```CLI-02``` contains:
+  - ```user files``` repo (```U1```)
+  - ```transfer``` repository (```T1```)
+- ```CLI-N``` (...)
+
+- **OBS**:
+   - ```SRV1``` uses ```aws tools``` and ```glacier-cli``` to access Glacier
+   - *I would rather not to have to install ```aws tools``` & ```glacier-cli``` on client machines*
+   - ```CLI```s use *ssh/rsync* with secret key to access ```SRV1```
+
+I would like that ```T1```would serve as a gateway for *a)* synchronizing ```user files``` amongst clients; *a.1)* including moving and dropping files moved to ```archive``` by other clients; *b)* send ```archive``` files to ```G1```; and *c)* get files from ```G1``` and deliver to clients when content is moved out of ```archive```.
+
+As is seem close to working, but when a ```CLI``` pulls a file out of ```archive``` the recovery processes *(c)* fails. I expected ```transfer``` to fetch the file and then ```CLI``` would sync eventually, but does not seem to happen.
+
+Is this even possible with this setup? If not, what changes would you recommend for the scenario above to work?
diff --git a/doc/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__/comment_1_a35571c77eaab5bcc0d841543a13162f._comment b/doc/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__/comment_1_a35571c77eaab5bcc0d841543a13162f._comment
new file mode 100644
index 0000000000..d4755acb02
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__/comment_1_a35571c77eaab5bcc0d841543a13162f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="transfer repos"
+ date="2020-07-05T17:25:49Z"
+ content="""
+[Transfer](https://git-annex.branchable.com/preferred_content/standard_groups/) repositories unfortunately do not behave that way. You can setup G1 to get content sitting in T1 since T1 will store content until G1 has it. But, in terms of the other direction, doing a `git annex get` from T1 won't ask SRV1 to get a file from G1 (I don't think).
+
+The easiest way I can think of to achieve what you are looking for would be to create your own special remote on SRV1 (lets call it P1) that proxies the requests the way you need. Using [hook](https://git-annex.branchable.com/special_remotes/hook/) you could create a special remote that when asked for a file, ssh-es into SRV1 and then runs a script on SRV1 that does a `git annex get` on G1. Then, a few hours later, you can do a get again to get the file.
+
+I think a reasonable workaround, that ensures some measure of safety would be to just create some read-only credentials for your Glacier. Then add your Glacier repo to all the clients, so you can at least do gets from your clients.
+
+—Andrew
+"""]]
diff --git a/doc/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__/comment_2_c8f185b0751ccd17a657e954cbeb2864._comment b/doc/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__/comment_2_c8f185b0751ccd17a657e954cbeb2864._comment
new file mode 100644
index 0000000000..3111a70591
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__/comment_2_c8f185b0751ccd17a657e954cbeb2864._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="flpgdt@f64318f00d9e1c9535e11f5d27c80c1d799cce00"
+ nickname="flpgdt"
+ avatar="http://cdn.libravatar.org/avatar/df837a3ae490227608cc38a7c9edfc7a"
+ subject="comment 2"
+ date="2020-07-07T16:54:46Z"
+ content="""
+thanks for the input. I will rethink this a bit, might share if come up with something interesting.
+
+kind regards.
+"""]]
diff --git a/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__.mdwn b/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__.mdwn
new file mode 100644
index 0000000000..28448932dc
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__.mdwn
@@ -0,0 +1,11 @@
+I'm using git annex sync to keep the `master` branch of various remotes in sync.  Predictably, while the `synced/master` branch gets synced fine, the machine running git annex sync fails to push to the remote's `master` branch, since it's currently checked out:
+
+    ok
+    push indian
+     Everything up-to-date
+    remote: error: refusing to update checked out branch: refs/heads/master
+    To ssh://indian-wired/home/adam/org
+     ! [remote rejected] master -> master (branch is currently checked out)
+    error: failed to push some refs to 'ssh://adam@indian-wired/home/adam/org'
+
+Is there a way to get annex sync to only try to push to the remote's `synced/master` and not `master`?  I see the `--no-push` option, but presumably this would prevent pushing to both, which is obviously not what I want.
diff --git a/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_1_e74ddd1bf47f856369568b1fcd8d4f9c._comment b/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_1_e74ddd1bf47f856369568b1fcd8d4f9c._comment
new file mode 100644
index 0000000000..0dc0892433
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_1_e74ddd1bf47f856369568b1fcd8d4f9c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 1"
+ date="2020-05-28T17:55:10Z"
+ content="""
+I don't think there's a way to do that.  I think your main options are
+
+  * set `receive.denyCurrentBranch` to \"updateInstead\" or
+
+  * handle the pushing and fetching yourself.  Follow up with a `git
+    annex merge` or with a `git annex sync` invocation that prevents
+    it from pushing/pulling.
+
+    I haven't used it myself, but my understanding is that `sync`s
+    recently added `--only-annex` is intended to support this case and
+    frees you from worrying about managing git-annex branches.
+"""]]
diff --git a/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_2_c47c27ce283cc4fcb80949860e2a4927._comment b/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_2_c47c27ce283cc4fcb80949860e2a4927._comment
new file mode 100644
index 0000000000..e0efd8eede
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_2_c47c27ce283cc4fcb80949860e2a4927._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-05-28T20:00:36Z"
+ content="""
+Usually, git-annex detects this situation and hides the error message
+from the git push of master.
+
+It only hides the error message if it mentions "denyCurrentBranch".
+The usual error message in this situation does. I think there must be
+something in the git configuration (on the remote) that does not.
+
+Perhaps something to do with receive.denyCurrentBranch? Yes, it seems that
+if it's set to "refuse", I get the same error.
+
+It would be nice if git-annex could recognize that error and hide it too,
+which I suppose would involve looking for
+"refusing to update checked out branch", and probably would need git to be
+run with localization disabled.
+
+If you can unset receive.denyCurrentBranch in the remote's git config, it will 
+avoid the problem for you..
+"""]]
diff --git a/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_3_47511f7b731cdefd108241bedb116f68._comment b/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_3_47511f7b731cdefd108241bedb116f68._comment
new file mode 100644
index 0000000000..6d03f3a72c
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_3_47511f7b731cdefd108241bedb116f68._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 3"
+ date="2020-05-28T20:41:48Z"
+ content="""
+Joey, sorry for the misinformation, and thanks for the correction.
+"""]]
diff --git a/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_4_07a190aa19006611739cccfc5aac5a6f._comment b/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_4_07a190aa19006611739cccfc5aac5a6f._comment
new file mode 100644
index 0000000000..e64080b55b
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_stop_annex_sync_from_trying_to_push_to_checked_out_branches__63__/comment_4_07a190aa19006611739cccfc5aac5a6f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="comment 4"
+ date="2020-05-31T11:03:05Z"
+ content="""
+Thanks. Yes, I have it set to `refuse` globally in `~/.gitconfig`.  I definitely don't want to unset it since that could really screw up my working trees.  Your idea of disabling localization (`LANG=C` or similar, I guess?) and checking for \"refusing to update checked out branch\" sounds reasonable, but I would prefer a way to just stop it even *trying* to update anything other than `synced/$BRANCH`.
+"""]]
diff --git a/doc/forum/Is_parallel_fsck_for_two_or_more_different_directories_possible__63__.mdwn b/doc/forum/Is_parallel_fsck_for_two_or_more_different_directories_possible__63__.mdwn
new file mode 100644
index 0000000000..41eef70205
--- /dev/null
+++ b/doc/forum/Is_parallel_fsck_for_two_or_more_different_directories_possible__63__.mdwn
@@ -0,0 +1,31 @@
+I can put `git-annex fsck` in a loop to check a large directory like this:
+
+`-S` starts an incremental check, `-m` continues the started incremental check, `&>>` appends all output (both `stdout` and `stderr`) into the `fsck.log` file. 
+
+```
+$ git-annex fsck -S large-directory --from remote-repo --time-limit=60s &>>~/log/fsck.log
+#...
+#...
+#...
+$ while (sleep 10); do
+  git-annex fsck -m large-directory --from remote-repo --time-limit=1h &>>~/log/fsck.log
+#...
+#...
+#...
+done;
+```
+
+I need the loop because the connection to `remote-repo` fails after some time (or because remote server error) and needs a reconnect, after that, everything is ok.
+
+Suppose, I have many large directories and it would be faster to check them if I could run them parallelly. Many small files, they do not take too much bandwidth but more I/O and network communication.
+
+I know that the progress of `fsck` is stored in a database (now after every 1000 files or 5 minutes or `--time-limit`) but is the checked directory (large-directory) is taken into account when starting/storing the progress? 
+
+**Is the checked directory/path in the primary-key?** Or is it much more complicated?
+
+If I could start checking many directories in the same time, `fsck` would finish much faster (think about thousands of small icon files). Is it just me or somebody else could profit from this?
+
+(This is _not_ a feature request, I would like to know if anybody needs this, if possible at all.)
+
+Thanks,
+parhuzamos
diff --git a/doc/forum/Is_parallel_fsck_for_two_or_more_different_directories_possible__63__/comment_1_34af73f211cce966927757f7deec88eb._comment b/doc/forum/Is_parallel_fsck_for_two_or_more_different_directories_possible__63__/comment_1_34af73f211cce966927757f7deec88eb._comment
new file mode 100644
index 0000000000..b456480357
--- /dev/null
+++ b/doc/forum/Is_parallel_fsck_for_two_or_more_different_directories_possible__63__/comment_1_34af73f211cce966927757f7deec88eb._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-04T20:14:00Z"
+ content="""
+This is actually something that got worse when fsck changed to using a
+database, rather than its old sticky-bit based hack. Parallel fsck used to
+work entirely perfectly, they could even be run on the same directories w/o
+processing files redundantly.
+
+Now, it's safe to run multiple fsck processes in parallel. However, since
+the database is only occasionally updated, if the two fscks are working on
+the same directory, one won't know that the other has already fscked a
+file, and they'll tend to do redundant work.
+
+It'll work fine if you give concurrent fscks different directories
+or sets of files to work on. The git-annex key (ie, symlink target of a
+file) is the primary-key.
+
+Also, I'd at some point like to make git-annex fsck -J work. With
+concurrent fsck jobs running in the same process, it could easily divide
+work up amoung them. The only tricky part is the output of the concurrent
+jobs would be scrambled and interleaved..
+"""]]
diff --git a/doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__.mdwn b/doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__.mdwn
new file mode 100644
index 0000000000..09ca5fe360
--- /dev/null
+++ b/doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__.mdwn
@@ -0,0 +1 @@
+I found [this suggestion](http://stackoverflow.com/a/2873039) on Stack Overflow. Is this safe to use in git annex? I don't know how the internals work. I have a very large annex and I don't want to screw it up.
diff --git a/doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__/comment_1_c250362236a33d8dc9bf5ed825318c40._comment b/doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__/comment_1_c250362236a33d8dc9bf5ed825318c40._comment
new file mode 100644
index 0000000000..073a91d35f
--- /dev/null
+++ b/doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__/comment_1_c250362236a33d8dc9bf5ed825318c40._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-17T15:59:16Z"
+ content="""
+I don't fully understand what core.preloadindex does, but according to
+git's documentation, it's enabled by default. So, it seems pretty safe. :)
+
+Let's anwser the general question: When is a git config tweak not safe to
+use with a git-annex repository? Well, git-annex just stores symlinks in
+git. And, it maintains a separate git-annex branch with its own data, which
+it makes commits to behind the scenes, using its own .git/annex/index file.
+Otherwise, a git-annex repo is like any other git repo.
+
+It follows that, unless the git config tweak somehow breaks symlink
+support, or somehow breaks git-annex's use of the .git/annex/index file,
+the git config tweak should be safe to use with git-annex.
+
+An example of a config tweak that's not entirely safe is to configure
+gc.pruneexpire to a very short time period. That could result in git
+objects that .git/annex/index refers to being pruned before git-annex can
+commit them to the git-annex branch.
+"""]]
diff --git a/doc/forum/Is_there_a___34__git_annex_cat-file__34___type_command__63__.mdwn b/doc/forum/Is_there_a___34__git_annex_cat-file__34___type_command__63__.mdwn
new file mode 100644
index 0000000000..898cb0a2ff
--- /dev/null
+++ b/doc/forum/Is_there_a___34__git_annex_cat-file__34___type_command__63__.mdwn
@@ -0,0 +1,20 @@
+Out of curiosity, is there an equivalent to `git cat-file` with `git annex`?
+
+The motivation is our usage of Bazel as a build system, which during test enforces hermiticity, and thus is very persnickity about modifying your workspace (e.g., the Git repository) while the test is being run, and usually isolates execution to a chroot'd sandbox of sorts.
+
+Ideally, the workflows I'd like are:
+
+A. Developer
+
+- 1. Clones repository.
+- 2. Inits `git annex`, and does `git annex get .` to fetch all required files.
+- 3. Runs `bazel test //repo:my_test`, which will symlink the existing large file into the sandbox, and run without a hitch.
+
+B. Tentative Contributor
+
+- 1. Clones repository. Pokes around.
+- 2. Runs `bazel test //repo:my_test`. Since the large file does not exist, under the hood `git annex cat-file` is called to directly add the file to sandbox (possibly caching it somewhere, such that `git annex get` will use the already fetch'd file).
+
+
+May I ask if this doable with simple visible commands?
+If not, is there a way to achieve this that is special remote-agnostic?
diff --git a/doc/forum/Is_there_a___34__git_annex_cat-file__34___type_command__63__/comment_1_fe3dc778b35119d3ede2d341cac7a15b._comment b/doc/forum/Is_there_a___34__git_annex_cat-file__34___type_command__63__/comment_1_fe3dc778b35119d3ede2d341cac7a15b._comment
new file mode 100644
index 0000000000..f087e8de87
--- /dev/null
+++ b/doc/forum/Is_there_a___34__git_annex_cat-file__34___type_command__63__/comment_1_fe3dc778b35119d3ede2d341cac7a15b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-09-29T19:49:29Z"
+ content="""
+Think of `git annex get` as more like `git pull` than `git cat-file`. 
+It necessarily needs to modify the repository to get the contents of files.
+
+What about making a temporary clone of the git repository that's
+writable in the sandbox?
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_get_back_to_clean-state_after_unworking_annex_assistant_configuration_attempt__63__.mdwn b/doc/forum/Is_there_a_way_to_get_back_to_clean-state_after_unworking_annex_assistant_configuration_attempt__63__.mdwn
new file mode 100644
index 0000000000..cf5a5c8be4
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_get_back_to_clean-state_after_unworking_annex_assistant_configuration_attempt__63__.mdwn
@@ -0,0 +1,28 @@
+I am trying to synchronize "Linux Workstation" and "Android Tablet" with annex assistant through RSync remote and my google account.
+
+I keep failing horribly :-) I followed http://git-annex.branchable.com/assistant/remote_sharing_walkthrough/,
+but I seem to either do the steps in wrong order, because I never managed to materialize the files on my Android device.
+
+Steps went thusly:
+
+1. L) install annex on linux and run assistant and select repository dir
+2. L) add rsync remote, set folder to android_docs
+3. L) add jabber account -> I see progress bars and it seems to sync just fine
+4. A) install annex on android, specify repository
+5. A) add the "share with other devices repository"
+6. A) login with my google account
+7. A) sync fails because I am on failing wifi network
+8. A) try to add RSync remote, accidentaly specify annex folder
+9. A) realize mistake, try to remove rsync repo
+10. A) hangs on "cleaning step"
+11. A) battery dies
+12. A) charge battery, start android, move to functional wifi network
+13. A) start annex assistant, hangs in terminal (don't remember error message :-/)
+14. A) remove repo folder from android, remove annex,download apk again, reinstall
+15. A) run annex, select folder, add the "share with other devices repository", login with google account
+16. L) See fail syncing on linux "fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists."
+17. A) android seems that it finished syncig, asks for remote repository
+18. A) specify my rsync account with correct folder "android_docs"
+19. A) Could not resolve hostname git-annex-$servername-$username_$port_$directory
+
+I am starting to thing, that randomly creating and removing repositories is not the way forward, so I'd like to get to clean state and redo my setup :)
diff --git a/doc/forum/Is_there_a_way_to_get_back_to_clean-state_after_unworking_annex_assistant_configuration_attempt__63__/comment_1_d77fbbbe3a7438a1e79f175df1f69ef3._comment b/doc/forum/Is_there_a_way_to_get_back_to_clean-state_after_unworking_annex_assistant_configuration_attempt__63__/comment_1_d77fbbbe3a7438a1e79f175df1f69ef3._comment
new file mode 100644
index 0000000000..8dc0692e63
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_get_back_to_clean-state_after_unworking_annex_assistant_configuration_attempt__63__/comment_1_d77fbbbe3a7438a1e79f175df1f69ef3._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawldUCypSR21BObbzC0Uf8NVd1vZnjYlXZc"
+ nickname="Adam"
+ subject="Ok, found it :-)"
+ date="2014-10-04T10:11:55Z"
+ content="""
+I think I found reliable although a bit excessive way to get back to clean state:
+
+1. stop all the running daemons
+2. on android, remove folder git-annex.home
+3. on linux, remove ~/.config/git-annex and ~/.ssh/git-annex
+4. on both attempted repositories I removed .git folder  
+5. I removed everything I have stored on rsync.net
+
+Then I re-did the steps on good wifi network an plugged in to power source on both devices :-)
+It seems that important step is to wait for the annex to share the remote repo with the other device (took ~5 minutes)
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__.mdwn b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__.mdwn
new file mode 100644
index 0000000000..4b689e4976
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__.mdwn
@@ -0,0 +1,5 @@
+I'm using the version of git-annex in debian bullseye (8.20210223) and a newly
+created repository (v8). When I put a new file into the repository, the assistant
+notices and adds it, but the file is then unlocked. Is there a way to tell the
+assistant to add files in locked mode? This repository is in the "source" group,
+so contents get dropped soon and the pointer files regularly confuse me :)
diff --git a/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_1_70c8e23c87a6c48e728a6685e7189e98._comment b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_1_70c8e23c87a6c48e728a6685e7189e98._comment
new file mode 100644
index 0000000000..ae1d509e06
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_1_70c8e23c87a6c48e728a6685e7189e98._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-09-16T15:00:49Z"
+ content="""
+Yes, by setting the `annex.addunlocked` config option to `false`
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_2_c0c6e38fe99dd273764071574c8b3c1d._comment b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_2_c0c6e38fe99dd273764071574c8b3c1d._comment
new file mode 100644
index 0000000000..210592cf16
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_2_c0c6e38fe99dd273764071574c8b3c1d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="weinzwang"
+ avatar="http://cdn.libravatar.org/avatar/e73d7d9e358f3b974d283fb0834cc5d9"
+ subject="comment 2"
+ date="2021-09-16T20:56:29Z"
+ content="""
+Thanks for the hint - this doesn't seem to make any difference though. If I unterstand the manpage correctly, adding files in locked form is the default anyway. I tried it to be sure:
+
+    # git config --get annex.addunlocked
+    false
+
+and restarted the assistant. The behaviour is the same as before, files are added unlocked.
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_3_c80d15f6844e29dee2bf7ba0a6d6d093._comment b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_3_c80d15f6844e29dee2bf7ba0a6d6d093._comment
new file mode 100644
index 0000000000..6ee33fab06
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_3_c80d15f6844e29dee2bf7ba0a6d6d093._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2021-09-17T15:24:47Z"
+ content="""
+It could also be due to being on a adjusted unlocked branch. Try `git checkout master`
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_4_a8ebda7dd8d52e6c1137dbb646e21e5c._comment b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_4_a8ebda7dd8d52e6c1137dbb646e21e5c._comment
new file mode 100644
index 0000000000..0090a3b66d
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_4_a8ebda7dd8d52e6c1137dbb646e21e5c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="weinzwang"
+ avatar="http://cdn.libravatar.org/avatar/e73d7d9e358f3b974d283fb0834cc5d9"
+ subject="comment 4"
+ date="2021-09-17T18:57:41Z"
+ content="""
+That's also not it:
+
+    ### git branch
+      git-annex
+    * master
+      synced/master
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_5_022f36242ef57158feab0918f41a7ff1._comment b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_5_022f36242ef57158feab0918f41a7ff1._comment
new file mode 100644
index 0000000000..e3e0554149
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_5_022f36242ef57158feab0918f41a7ff1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joshmen"
+ avatar="http://cdn.libravatar.org/avatar/b182b7f2c9a8b168dd912bfe55bf2c2c"
+ subject="Same here"
+ date="2021-09-19T17:03:26Z"
+ content="""
+Confirming that assistant also adds files unlocked for me and I haven't found a way to change this (this is one of the main reasons I've moved away from using assistant to manual sync). If there is a way to change this behavior, I'd be glad to know about it!
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_6_5527d611a132f3e9bc0d71c593abf673._comment b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_6_5527d611a132f3e9bc0d71c593abf673._comment
new file mode 100644
index 0000000000..aa6c3ea1d4
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_6_5527d611a132f3e9bc0d71c593abf673._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-09-27T16:38:12Z"
+ content="""
+The assistant adds files unlocked because it's intended to work for
+unsophisticated users who would be confused to have the file they saved
+suddenly turn into a symlink. For that matter, even a sophisticated user
+might find reasons to be annoyed at that happening without them doing
+anything.
+
+While it could treat annex.addunlocked not being set to add files unlocked,
+but honor if if it's set, it seems potentially confusing to make unset and
+false have different meanings. Also if annex.addunlocked were set globally,
+there would be no way to put it in the "unset" state in the local repo.
+Maybe it would be better as a separate config setting for the assistant,
+eg `annex.assistant.honor.addunlocked`
+
+I do not think this will be very easy to implement, unfortunately.
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_7_92bf43545c46d302089820cfdd03141b._comment b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_7_92bf43545c46d302089820cfdd03141b._comment
new file mode 100644
index 0000000000..e205116f56
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_7_92bf43545c46d302089820cfdd03141b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2024-01-05T21:00:52Z"
+ content="""
+so there remains no way to configure assistant to add files in regular locked mode where files would \"migrate\" to become symlinks after having been added to annex?
+
+Our use case is the \"data acquisition\" box (for repronim's reprostim project) which we are configuring to collect videos, which are then to be transferred to another box. Size will be large, we will rely on branches and copies/moves of the files, so having them to be symlinks is kinda \"mandatory\" to keep operations fast and to not waste space.
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_8_a6ae8bc3b5caf0d3d49a919ab5ec5778._comment b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_8_a6ae8bc3b5caf0d3d49a919ab5ec5778._comment
new file mode 100644
index 0000000000..b300907a88
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_8_a6ae8bc3b5caf0d3d49a919ab5ec5778._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 8"
+ date="2024-01-06T09:22:54Z"
+ content="""
+Not that I know of. Simplest solution for you would be probably a `while true;git annex assist`done` instead of the assistant.
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_9_7fcc62493d261c22149f85f48bb95efc._comment b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_9_7fcc62493d261c22149f85f48bb95efc._comment
new file mode 100644
index 0000000000..87f4262044
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/comment_9_7fcc62493d261c22149f85f48bb95efc._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2024-01-18T17:08:57Z"
+ content="""
+That seems like a resonable use case to me,
+I've opened a todo
+[[todo/allow_configuring_assistant_to_add_files_locked]].
+
+I have not revisited looking at how hard it would be to
+implement such a config option. @yarikoptic if you're 
+needing this for ReproNim I could prioritize doing that.
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__.mdwn b/doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__.mdwn
new file mode 100644
index 0000000000..5844e7cf44
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__.mdwn
@@ -0,0 +1,11 @@
+Hello all,
+
+I work for a company that produces books using InDesign and marketing assets for these books in Photoshop/Illustrator.
+
+What we're ultimately looking for is a system that allows us to make changes (primarily to the books) and log the changes to the file so we can keep track of what has been edited when.
+
+Ideally, we'd also be able to pull up an older version of the file if needed. So if we have 10 commits and are on commit #10, we could pull up commit #7 if needed and see that file as it was back when it was committed the 7th time.
+
+I hope I explained what I'm looking for clearly. Is this something git-annex could help wtih?
+
+Thanks
diff --git a/doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__/comment_1_e30310472df6ed2928dfd63464c6bae7._comment b/doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__/comment_1_e30310472df6ed2928dfd63464c6bae7._comment
new file mode 100644
index 0000000000..af153fd295
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__/comment_1_e30310472df6ed2928dfd63464c6bae7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2018-02-27T10:59:02Z"
+ content="""
+You can write the changes in the commit message as you would for using git with coding, if that is what you mean..?
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__/comment_2_f093b16307bd369399574fc651569b73._comment b/doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__/comment_2_f093b16307bd369399574fc651569b73._comment
new file mode 100644
index 0000000000..208146ef1a
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__/comment_2_f093b16307bd369399574fc651569b73._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Jeff"
+ avatar="http://cdn.libravatar.org/avatar/99a3c8987afede93f4e5d3212b43ad5f"
+ subject="comment 2"
+ date="2018-02-28T14:43:52Z"
+ content="""
+Yep, that's what I mean! And would I be able to revert to previous commits like if I were using Github to track code? If it's for large files, does it just make a hidden copy of each version of a file every time I add a new commit?
+
+Thanks!
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__/comment_3_1edab7e44e7eae6d8f06a917704b17ec._comment b/doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__/comment_3_1edab7e44e7eae6d8f06a917704b17ec._comment
new file mode 100644
index 0000000000..0e32b81708
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_log_what_changed_in_files_committed__44___similar_to_how_git_normally_works_for_coding_files__63__/comment_3_1edab7e44e7eae6d8f06a917704b17ec._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-02-28T18:02:04Z"
+ content="""
+Yes, git-annex retains all past versions of files, just like git does. You
+can check out a past version of the repository, the same as you would in a
+git repository (because it is a git repository..)
+
+(There are exceptions, like then `git annex unused` has been used to
+save space and delete some past revisions.)
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_override_the_import_destination__63__.mdwn b/doc/forum/Is_there_a_way_to_override_the_import_destination__63__.mdwn
new file mode 100644
index 0000000000..0fa5c51422
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_override_the_import_destination__63__.mdwn
@@ -0,0 +1,5 @@
+I want to import a file that's on my filesystem as a/b/c, but have it end up in the repo at $REPO/d/e/f -- but only if it's not already present, i.e. using `--skip-duplicates`.  There are two requirements here; `git annex import` will meet one of them (dedup), and copy+`git annex add` will meet the other (arbitrary destination).  Is there a way to meet both at once?
+
+(Actually, for my current use case, what I really want is to import a/b/c to $REPO/a/b/c -- but _not_ to import all the rest of the tree under a/.  Can't get there either.  If I say `git annex import a/b/c`, the directory structure isn't preserved; the file ends up at $REPO/c.  For this specific use case, a `--preserve-directories` option to `import` would be splendid, but that's rather specific; being able to specify an arbitrary destination would be a more general solution.)
+
+Thanks.
diff --git a/doc/forum/Is_there_a_way_to_override_the_import_destination__63__/comment_1_5f094cc606eebd2aeeaaa4b861cf2c21._comment b/doc/forum/Is_there_a_way_to_override_the_import_destination__63__/comment_1_5f094cc606eebd2aeeaaa4b861cf2c21._comment
new file mode 100644
index 0000000000..27d17f99e4
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_override_the_import_destination__63__/comment_1_5f094cc606eebd2aeeaaa4b861cf2c21._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-08-03T17:37:59Z"
+ content="""
+`git-annex import` imports files into the current working directory,
+so make whatever subdirectory structure you want, cd into the place
+and import to there.
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_unannex_some_file___63__.mdwn b/doc/forum/Is_there_a_way_to_unannex_some_file___63__.mdwn
new file mode 100644
index 0000000000..78aa6744a4
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_unannex_some_file___63__.mdwn
@@ -0,0 +1,3 @@
+Having by mistake annex a full repo i look for a way of unannex some file to make them
+managed by the "standard" git proccess again - mostly some source code file -
+Is there a way  to do that ?
diff --git a/doc/forum/Is_there_a_way_to_unannex_some_file___63__/comment_1_82095cef37dd815bcd1d101a1715e3c7._comment b/doc/forum/Is_there_a_way_to_unannex_some_file___63__/comment_1_82095cef37dd815bcd1d101a1715e3c7._comment
new file mode 100644
index 0000000000..0f87f1460c
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_unannex_some_file___63__/comment_1_82095cef37dd815bcd1d101a1715e3c7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Horus"
+ avatar="http://cdn.libravatar.org/avatar/8f0ee08b98ea5bba76c3fe112c08851c"
+ subject="comment 1"
+ date="2017-09-07T09:30:53Z"
+ content="""
+Well, there is ```git unannex ...``` 
+
+<https://git-annex.branchable.com/git-annex-unannex/>
+
+Is that what you're looking for?
+"""]]
diff --git a/doc/forum/Is_there_a_way_to_unannex_some_file___63__/comment_2_3b05e9eaa554b70594f0195dfcef831d._comment b/doc/forum/Is_there_a_way_to_unannex_some_file___63__/comment_2_3b05e9eaa554b70594f0195dfcef831d._comment
new file mode 100644
index 0000000000..d911c5efec
--- /dev/null
+++ b/doc/forum/Is_there_a_way_to_unannex_some_file___63__/comment_2_3b05e9eaa554b70594f0195dfcef831d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="karel-de-macil"
+ avatar="http://cdn.libravatar.org/avatar/46688332185c941113a9c9827cb093e9"
+ subject="comment 2"
+ date="2017-09-08T08:31:36Z"
+ content="""
+yes exactly , thanks alot...
+"""]]
diff --git a/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__.mdwn b/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__.mdwn
new file mode 100644
index 0000000000..0f9b9924b8
--- /dev/null
+++ b/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__.mdwn
@@ -0,0 +1,19 @@
+Depending on how I am getting my network connection there are cases where I want to never access a remote.  BUT it depends on the network connection.
+
+For example, when I'm roaming (and paying excessively for each byte)
+
+- I really don't want my music annex to *ever* hit some site (like S3 / Glacier), BUT
+- I do want to be able to get from a remote (like Glacier) for my work annex.
+
+But if I'm home, then all's fair.
+
+That means I can't do something simple like blocking a particular address/IP with DNS (or whatever).  Or even not having the remote listed.
+
+So... I was thinking of using `annex-cost-command` to allow me to set the cost of remotes, based on (say) my IP, but also the annex.  Thus it would result in
+
+- [roaming] + [work-annex] == veryExpensiveRemoteCost
+- [roaming] + [music-annex] == Blocked
+
+However I still need a way to say "never, ever, ever" for the cost of some remotes.
+
+Is this possible?  (With my cursory looking at the code, I can't see anything.)
diff --git a/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_1_3760d5b8c8012405eef17e4d07cf151c._comment b/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_1_3760d5b8c8012405eef17e4d07cf151c._comment
new file mode 100644
index 0000000000..1d6373527d
--- /dev/null
+++ b/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_1_3760d5b8c8012405eef17e4d07cf151c._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="olaf"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="comment 1"
+ date="2017-08-15T23:28:58Z"
+ content="""
+Just to clarify...
+
+There will be situations where I will want to access other remotes (either networked or special, like an external drive) when I'm blocking access to others (like Glacier).
+
+So, for the music annex example when I'm roaming:
+
+- Remote: external drive  -->  low cost
+- Remote: other machine on my local network  -->  medium cost
+- Remote: youtube --> high cost  (if, for example, my data provider gives me a certain amount of free youtube streaming...)
+- Remote: Glacier  -->  NO
+
+...and in this case if there are files that are only available on Glacier, I'm happy to live without them.
+
+And for the work example, again when roaming:
+
+- Remote: external drive  -->  low cost
+- Remote: other machine on my local network  -->  medium cost
+- Remote: Glacier  -->  high cost
+
+...but if there is a file I need on Glacier and no where else, then just get it.
+
+
+
+"""]]
diff --git a/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_2_b95ce6b13ae45a2fca05260a7f77148f._comment b/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_2_b95ce6b13ae45a2fca05260a7f77148f._comment
new file mode 100644
index 0000000000..d5f78140ce
--- /dev/null
+++ b/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_2_b95ce6b13ae45a2fca05260a7f77148f._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-08-17T15:59:13Z"
+ content="""
+Cost settings only affect sort order, they don't allow completely blocking
+use of a remote.
+
+I feel that it would be perhaps the wrong design to extend cost settings
+into blocking a remote.
+
+There's also the `remote.<name>.annex-start-command` hook. However,
+failure to run its command does not prevent git-annex from trying to access
+a remote.
+
+I think it would be reasonable to add a hook
+`remote.<name>.annex-check-command`. If set, the command would have
+to succed, or git-annex would refuse to use the remote.
+"""]]
diff --git a/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_3_1c8f023b8d7a50cfce6d3464b12e446b._comment b/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_3_1c8f023b8d7a50cfce6d3464b12e446b._comment
new file mode 100644
index 0000000000..0278e8637e
--- /dev/null
+++ b/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_3_1c8f023b8d7a50cfce6d3464b12e446b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-08-17T16:06:44Z"
+ content="""
+Another good reason to have a separate config is it should probably
+block `git annex sync` from pulling/pushing the remote. Cost does not
+affect pulling and pushing.
+
+The two config settings `annex-ignore` and
+`annex-sync` are the non-dynamic ways to control this. 
+So perhaps the way that annex-cost-command is the dynamic form of
+annex-cost, there ought to be annex-ignore-command and annex-sync-command.
+
+That also allows for situations like a network where you want git-annex
+sync to only push the git repository but not annexed contents.
+"""]]
diff --git a/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_4_f1e234e80a6873b33986bec8d51c1001._comment b/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_4_f1e234e80a6873b33986bec8d51c1001._comment
new file mode 100644
index 0000000000..3bcce95be3
--- /dev/null
+++ b/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_4_f1e234e80a6873b33986bec8d51c1001._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-08-17T17:53:59Z"
+ content="""
+I've implemented annex-ignore-command and annex-sync-command. Enjoy!
+"""]]
diff --git a/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_5_2c43830a95cd8955da20cc6dba27a9b6._comment b/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_5_2c43830a95cd8955da20cc6dba27a9b6._comment
new file mode 100644
index 0000000000..2f1286ca5d
--- /dev/null
+++ b/doc/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/comment_5_2c43830a95cd8955da20cc6dba27a9b6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="olaf"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="comment 5"
+ date="2017-08-18T04:18:13Z"
+ content="""
+Brilliant - Thanks Joey!
+
+...and that's why I donated.  :-)
+"""]]
diff --git a/doc/forum/Is_there_any_delta_handling_for_file_modifications__63__.mdwn b/doc/forum/Is_there_any_delta_handling_for_file_modifications__63__.mdwn
new file mode 100644
index 0000000000..30463a496d
--- /dev/null
+++ b/doc/forum/Is_there_any_delta_handling_for_file_modifications__63__.mdwn
@@ -0,0 +1,20 @@
+Hi!
+
+I have few large files, which will be slightly modified from time to time. Consider the following example:
+
+    $ git init
+    $ git annex init "somerepo"
+    $ dd if=/dev/urandom of=foo bs=50M count=1
+    $ git annex add foo
+    $ git commit -m "foo added"
+    $ git annex unlock foo
+    $ echo "modification" >> foo
+    $ git annex add foo
+    $ git -m commit "modification 1 of foo"
+    $ echo "another modification" >> foo
+    $ git annex add foo
+    $ git -m commit "modification 2 of foo"
+
+I would have expected ending up with a full copy of foo, and a delta storage for the first version and the first modification. Instead, three full-sized copies are created within the .git/annex/objects directory, even though the modifications only added a few characters.
+
+Is there any way to not always store a full copy of each file for each modification, but only a delta?
diff --git a/doc/forum/Is_there_any_delta_handling_for_file_modifications__63__/comment_1_d901ac998c9fdb844c593d782c31cc73._comment b/doc/forum/Is_there_any_delta_handling_for_file_modifications__63__/comment_1_d901ac998c9fdb844c593d782c31cc73._comment
new file mode 100644
index 0000000000..bbc7df6d2c
--- /dev/null
+++ b/doc/forum/Is_there_any_delta_handling_for_file_modifications__63__/comment_1_d901ac998c9fdb844c593d782c31cc73._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-04T17:53:50Z"
+ content="""
+git-annex does not do deltas. However, the bup and ddar special remotes
+can both be used to store annexed files and will automatically do delta
+compression.
+"""]]
diff --git a/doc/forum/Is_there_any_delta_handling_for_file_modifications__63__/comment_2_e46cb391ce377c3a8eb40155a5d0f001._comment b/doc/forum/Is_there_any_delta_handling_for_file_modifications__63__/comment_2_e46cb391ce377c3a8eb40155a5d0f001._comment
new file mode 100644
index 0000000000..2883d29e32
--- /dev/null
+++ b/doc/forum/Is_there_any_delta_handling_for_file_modifications__63__/comment_2_e46cb391ce377c3a8eb40155a5d0f001._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="git-annex@c063eec406e857662ac6bbb814defa6aebde6417"
+ nickname="git-annex"
+ subject="any plans to add this?"
+ date="2016-02-21T12:12:43Z"
+ content="""
+Presumably this is a desirable feature for faster syncing of modifications to large files, so are there any plans to add it?
+"""]]
diff --git a/doc/forum/Issues_with_IPFS_special_remote.mdwn b/doc/forum/Issues_with_IPFS_special_remote.mdwn
new file mode 100644
index 0000000000..73c6ac1c7e
--- /dev/null
+++ b/doc/forum/Issues_with_IPFS_special_remote.mdwn
@@ -0,0 +1,7 @@
+I'm trying to make git-annex work with the ipfs special remote here: (https://git-annex.branchable.com/special_remotes/ipfs/). Publishing to IPFS works, but I cannot retrieve the files onto another machine through git-annex
+
+Running `git-annex copy --to ipfs` does copy files onto ipfs, I can access them through the CIDs (through an IPFS gateway like ipfs.io/ipfs/<CID>), and I can view the annexed files on running `git annex whereis`
+
+But, `git annex whereis` on the other computer gives an empty output. (even after running `git annex sync` on both systems). `git annex copy --from ipfs` also gives no output on the other system.
+
+Is there something obvious that I'm missing?
diff --git a/doc/forum/Issues_with_IPFS_special_remote/comment_10_d13e439c3c242606d8b4377831e38a2b._comment b/doc/forum/Issues_with_IPFS_special_remote/comment_10_d13e439c3c242606d8b4377831e38a2b._comment
new file mode 100644
index 0000000000..bcaf9e14db
--- /dev/null
+++ b/doc/forum/Issues_with_IPFS_special_remote/comment_10_d13e439c3c242606d8b4377831e38a2b._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-06-21T15:38:06Z"
+ content="""
+Hmm, github has found some way to break usual git operation here,
+by making the git-annex branch be the one that git checks out
+on clone.
+
+I was able to reproduce that with the bare repository on github,
+the list of branches in their UI started with synced/git-annex, 
+and cloning that repo resulted in that branch being checked out.
+
+Compare with a bare repository on a regular ssh server, git clone
+picks master as the head branch, because the bare git repo has HEAD
+set to master. (That happens at init time, the init 
+branch name is configurable now.)
+
+Seems that github is assuming that the first branch pushed is the head
+branch. It may be that's the best they can do, since the git push protocol
+does not specify what the HEAD is, and they don't want to default to a name
+like "master".
+
+If git-annex sync pushed master before git-annex and synced/master, it
+would avoid this problem. But pushing master to a non-bare remote often
+fails due to non-fast-forward, and so the stderr of the master push is
+discarded to avoid displaying an error message. Which also
+prevents seeing the progress display for that push. So, it pushes
+synced/master before master in order for the data transfer and progress
+display to be done there. It is possible to at least push git-annex
+after synced/master, but that will leave github defaulting to synced/master
+in this case, which remains weird behavior. Oh well, it's a behavior
+apparently specific to github, and I can't see a good way for git-annex
+to avoid it given its other constraints.
+"""]]
diff --git a/doc/forum/Issues_with_IPFS_special_remote/comment_11_e53b0158471605950896cafac7aac4da._comment b/doc/forum/Issues_with_IPFS_special_remote/comment_11_e53b0158471605950896cafac7aac4da._comment
new file mode 100644
index 0000000000..30c0245c78
--- /dev/null
+++ b/doc/forum/Issues_with_IPFS_special_remote/comment_11_e53b0158471605950896cafac7aac4da._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2021-06-21T16:25:13Z"
+ content="""
+Changed the sync order as I discussed.
+"""]]
diff --git a/doc/forum/Issues_with_IPFS_special_remote/comment_1_74c586e5af079f0d6c42975ac294e766._comment b/doc/forum/Issues_with_IPFS_special_remote/comment_1_74c586e5af079f0d6c42975ac294e766._comment
new file mode 100644
index 0000000000..e8cffd4485
--- /dev/null
+++ b/doc/forum/Issues_with_IPFS_special_remote/comment_1_74c586e5af079f0d6c42975ac294e766._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-06-18T14:50:44Z"
+ content="""
+You have to setup a way so the two remotes can push/pull the git data itself too. You could add each other as git remotes or setup a git server somewhere that both repos talk to.
+"""]]
diff --git a/doc/forum/Issues_with_IPFS_special_remote/comment_2_283aafce5dc1735310daa8329a432002._comment b/doc/forum/Issues_with_IPFS_special_remote/comment_2_283aafce5dc1735310daa8329a432002._comment
new file mode 100644
index 0000000000..dc1bd9e13e
--- /dev/null
+++ b/doc/forum/Issues_with_IPFS_special_remote/comment_2_283aafce5dc1735310daa8329a432002._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="kinshukkashyap.me@35751535d5ebba69df2f2ead4f868251d1aadacf"
+ nickname="kinshukkashyap.me"
+ avatar="http://cdn.libravatar.org/avatar/3b7e38fd42309b3ecebf85e0619fc3d8"
+ subject="comment 2"
+ date="2021-06-18T15:11:23Z"
+ content="""
+Yes I have a repository on Github. Starting with an empty repo, I clone it on both machines, then run all the git-annex commands (first enabling the remote, then adding the file, then copy to remote, then sync).
+Is this what you meant?
+"""]]
diff --git a/doc/forum/Issues_with_IPFS_special_remote/comment_3_fa017d01e9eca59074adf2224e20994b._comment b/doc/forum/Issues_with_IPFS_special_remote/comment_3_fa017d01e9eca59074adf2224e20994b._comment
new file mode 100644
index 0000000000..ea88c687cb
--- /dev/null
+++ b/doc/forum/Issues_with_IPFS_special_remote/comment_3_fa017d01e9eca59074adf2224e20994b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="setting up sync"
+ date="2021-06-18T18:54:59Z"
+ content="""
+Are you running `git-annex-sync` with the `--content` flag?
+"""]]
diff --git a/doc/forum/Issues_with_IPFS_special_remote/comment_4_e49c62ca2e0f0d455469d5bc4483aff3._comment b/doc/forum/Issues_with_IPFS_special_remote/comment_4_e49c62ca2e0f0d455469d5bc4483aff3._comment
new file mode 100644
index 0000000000..4518851c35
--- /dev/null
+++ b/doc/forum/Issues_with_IPFS_special_remote/comment_4_e49c62ca2e0f0d455469d5bc4483aff3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kinshukkashyap.me@35751535d5ebba69df2f2ead4f868251d1aadacf"
+ nickname="kinshukkashyap.me"
+ avatar="http://cdn.libravatar.org/avatar/3b7e38fd42309b3ecebf85e0619fc3d8"
+ subject="comment 4"
+ date="2021-06-19T10:22:58Z"
+ content="""
+No, I'm not using the `--content` flag. I thought that was for syncing content as well, rather than just the locations of files?
+"""]]
diff --git a/doc/forum/Issues_with_IPFS_special_remote/comment_5_2147808f9b15be995988e2c71bc0b271._comment b/doc/forum/Issues_with_IPFS_special_remote/comment_5_2147808f9b15be995988e2c71bc0b271._comment
new file mode 100644
index 0000000000..c67894a4af
--- /dev/null
+++ b/doc/forum/Issues_with_IPFS_special_remote/comment_5_2147808f9b15be995988e2c71bc0b271._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 5"
+ date="2021-06-19T12:14:33Z"
+ content="""
+Hmm, it should work as you described it. Did you run `git annex sync` on the 2nd repo _after_ running `git annex sync` on the 1st repo (where you copied the files to the ipfs remote)? Can you post the output of the following actions, in that order:
+
+    repo1# git annex copy somefile --to=ipfs
+    repo1# git annex sync
+    repo2# git annex sync
+"""]]
diff --git a/doc/forum/Issues_with_IPFS_special_remote/comment_6_3a34db5281419578201f5f74cf97a830._comment b/doc/forum/Issues_with_IPFS_special_remote/comment_6_3a34db5281419578201f5f74cf97a830._comment
new file mode 100644
index 0000000000..24c6aa84b9
--- /dev/null
+++ b/doc/forum/Issues_with_IPFS_special_remote/comment_6_3a34db5281419578201f5f74cf97a830._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 6"
+ date="2021-06-19T18:31:59Z"
+ content="""
+>No, I'm not using the --content flag. I thought that was for syncing content as well, rather than just the locations of files?
+
+You're right, sorry, I misread your post.  For syncing just the location info `--content` is not needed.
+"""]]
diff --git a/doc/forum/Issues_with_IPFS_special_remote/comment_7_765fef6f0b5da3e5c87c029fea2362a1._comment b/doc/forum/Issues_with_IPFS_special_remote/comment_7_765fef6f0b5da3e5c87c029fea2362a1._comment
new file mode 100644
index 0000000000..a729b1f6c4
--- /dev/null
+++ b/doc/forum/Issues_with_IPFS_special_remote/comment_7_765fef6f0b5da3e5c87c029fea2362a1._comment
@@ -0,0 +1,128 @@
+[[!comment format=mdwn
+ username="kinshukkashyap.me@35751535d5ebba69df2f2ead4f868251d1aadacf"
+ nickname="kinshukkashyap.me"
+ avatar="http://cdn.libravatar.org/avatar/3b7e38fd42309b3ecebf85e0619fc3d8"
+ subject="comment 7"
+ date="2021-06-20T06:54:37Z"
+ content="""
+Here's a detailed sequence of what I'm doing:
+I made an empty repository on github. Then, on machine #1:
+
+
+    $ git init
+    Reinitialized existing Git repository in /home/kinshuk/code/annex-again/.git/
+
+
+    $ git annex init origin
+    init origin (scanning for unlocked files...)
+
+      Remote origin not usable by git-annex; setting annex-ignore
+    ok
+    (recording state in git...)
+
+
+    $ git annex initremote ipfs type=external externaltype=ipfs encryption=none
+    initremote ipfs ok
+    (recording state in git...)
+
+
+    $ vim test1.txt
+    $ git annex add test1.txt 
+    add test1.txt 
+    ok                                
+    (recording state in git...)
+
+
+    $ git annex copy --to ipfs
+    copy test1.txt (to ipfs...) 
+    ok
+    (recording state in git...)
+
+
+    $ git annex whereis
+    whereis test1.txt (2 copies) 
+          27123293-bec2-49a6-ac67-8c87fe72ffd6 -- origin [here]
+           e7582073-415a-48d2-9dec-29c58311fd21 -- [ipfs]
+
+      ipfs: ipfs:QmUk36hewmeivRKf1LKYvn2sG1ALqnt2NtAxaJAHJrrSH8
+    ok
+
+
+    $ git annex sync
+    commit 
+    [master (root-commit) d2860cd] git-annex in origin
+     1 file changed, 1 insertion(+)
+     create mode 120000 test1.txt
+    ok
+    pull origin 
+    ok
+    push origin 
+    Enumerating objects: 26, done.
+    Counting objects: 100% (26/26), done.
+    Delta compression using up to 4 threads
+    Compressing objects: 100% (20/20), done.
+    Writing objects: 100% (26/26), 2.33 KiB | 1.16 MiB/s, done.
+    Total 26 (delta 3), reused 0 (delta 0)
+    remote: Resolving deltas: 100% (3/3), done.
+    To https://github.com/plsrgb/annex-again
+     * [new branch]      git-annex -> synced/git-annex
+     * [new branch]      master -> synced/master
+    ok
+
+
+    $ git annex log
+    + Sun, 20 Jun 2021 12:02:21 IST test1.txt | e7582073-415a-48d2-9dec-29c58311fd21 -- [ipfs]
+    + Sun, 20 Jun 2021 12:02:08 IST test1.txt | 27123293-bec2-49a6-ac67-8c87fe72ffd6 -- origin
+
+Then I clone the repository from github on machine #2:
+
+    $ git annex sync
+    commit 
+    On branch synced/git-annex
+    Your branch is up to date with 'origin/synced/git-annex'.
+
+    nothing to commit, working tree clean
+    ok
+    pull origin 
+    ok
+    push origin 
+    Enumerating objects: 9, done.
+    Counting objects: 100% (9/9), done.
+    Delta compression using up to 12 threads
+    Compressing objects: 100% (6/6), done.
+    Writing objects: 100% (6/6), 750 bytes | 750.00 KiB/s, done.
+    Total 6 (delta 2), reused 0 (delta 0), pack-reused 0
+    remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
+    To https://github.com/plsrgb/annex-again
+       c95a7b3..d9cc5d1  git-annex -> synced/git-annex
+     * [new branch]      synced/git-annex -> synced/synced/git-annex
+    ok
+    To https://github.com/plsrgb/annex-again ! [rejected]        synced/git-annex -> synced/git-annex (non-fast-forward)error: failed to push some refs to 'https://github.com/plsrgb/annex-again'hint: Updates were rejected because the tip of your current branch is behindhint: its remote counterpart. Integrate the remote changes (e.g.hint: 'git pull ...') before pushing again.hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+
+
+To resolve this, I run git pull, then run sync again:
+
+    $ git pull
+    Updating c95a7b3..d9cc5d1
+    Fast-forward
+     remote.log | 2 +-
+     uuid.log   | 1 +
+     2 files changed, 2 insertions(+), 1 deletion(-)
+
+
+    $ git annex sync
+    commit 
+    On branch synced/git-annex
+    Your branch is up to date with 'origin/synced/git-annex'.
+
+    nothing to commit, working tree clean
+    ok
+    pull origin 
+    ok
+    push origin 
+    Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
+    To https://github.com/plsrgb/annex-again
+       c95a7b3..d9cc5d1  synced/git-annex -> synced/synced/git-annex
+    ok
+
+"""]]
diff --git a/doc/forum/Issues_with_IPFS_special_remote/comment_8_edd64d315651d5c7d5e1f802b68b8b68._comment b/doc/forum/Issues_with_IPFS_special_remote/comment_8_edd64d315651d5c7d5e1f802b68b8b68._comment
new file mode 100644
index 0000000000..205f3b17c3
--- /dev/null
+++ b/doc/forum/Issues_with_IPFS_special_remote/comment_8_edd64d315651d5c7d5e1f802b68b8b68._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 8"
+ date="2021-06-20T07:15:04Z"
+ content="""
+Ah that explains it. You have to switch to the `master` branch on the 2nd repository with `git checkout master`.
+"""]]
diff --git a/doc/forum/Issues_with_IPFS_special_remote/comment_9_07b1f3c1e744e910f1738925d79e3d1a._comment b/doc/forum/Issues_with_IPFS_special_remote/comment_9_07b1f3c1e744e910f1738925d79e3d1a._comment
new file mode 100644
index 0000000000..ba066a424a
--- /dev/null
+++ b/doc/forum/Issues_with_IPFS_special_remote/comment_9_07b1f3c1e744e910f1738925d79e3d1a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="kinshukkashyap.me@35751535d5ebba69df2f2ead4f868251d1aadacf"
+ nickname="kinshukkashyap.me"
+ avatar="http://cdn.libravatar.org/avatar/3b7e38fd42309b3ecebf85e0619fc3d8"
+ subject="comment 9"
+ date="2021-06-20T07:44:34Z"
+ content="""
+That works! That completely slipped my mind.
+
+Thanks a lot!
+"""]]
diff --git a/doc/forum/Issues_with_non-sync_workflow.mdwn b/doc/forum/Issues_with_non-sync_workflow.mdwn
new file mode 100644
index 0000000000..11c3a96f51
--- /dev/null
+++ b/doc/forum/Issues_with_non-sync_workflow.mdwn
@@ -0,0 +1,13 @@
+I recently stumbled across git-annex and quickly fell down the rabbit hole of possibilities. Thanks for creating it; it's exactly what I needed.
+
+I started out with the sync command, but almost immediately realized it wasn't for me when I saw it was committing to my own branches. I discovered the config settings to limit these behaviors, but I decided I wanted to kick the tires and try git-annex without sync first, since I'm quite comfortable with and diligent about pulling, pushing, and rebasing across my machines, even with the extra branch to manage. I might end up sticking without sync even once I'm more familiar, since I don't really like the extra sync branches or the merge commits. I can definitely see why they're preferable for most users, though, since it does cost you some time to get a cleaner history.
+
+My approach was to create a worktree for the git-annex branch via `git worktree add .git-annex; echo '/.git-annex/' >> .gitignore`. This makes browsing the git-annex internals and pushing, pulling, and rebasing the branch only a `cd` away.
+
+Upon trying commands like `get` and `copy`, however, it became apparent that the worktree contents and index for the git-annex branch behaved strangely. I'm not 100% sure what's going on, but they usually look like what happens when you reset a branch to a future commit but use `--soft` instead of `--hard`, meaning all the changes it would require to take the branch from the new future commit on HEAD to the previous HEAD end up in the worktree and the staging area, which is rather disorienting. I don't think it ever caused a legitimate issue, at least. I'm guessing this is because git-annex does not expect its branch to ever be checked out, and so it operates purely on objects in `.git`, so the worktree just end up behind whenever a git-annex operation records state.
+
+Is this by design? Would it affect normal git-annex operation to support worktrees more cleanly for when people do want to browse the branch (e.g. by checking if the git-annex branch has an active worktree and resetting it after recording state)? Otherwise, does anyone have any suggested alternatives for keeping track of what's going on with git-annex internals without having to constantly `git show` and `git log`? Worktrees are really nice for this. Checking out git-annex directly isn't great, because it means I temporarily lose access to my actual files.
+
+Also, the copy command seems to record its state changes at both the source and the destination, meaning you always have to drop one of the resulting commits to the git-annex branch. Anything I can do to streamline that?
+
+Can anyone who generally avoids the sync command offer advice? I'd love to flesh out [workflow 6](https://git-annex.branchable.com/workflow/) a bit.
diff --git a/doc/forum/Issues_with_non-sync_workflow/comment_1_99f89201446005f77d9278a7a889638d._comment b/doc/forum/Issues_with_non-sync_workflow/comment_1_99f89201446005f77d9278a7a889638d._comment
new file mode 100644
index 0000000000..9265f1caaa
--- /dev/null
+++ b/doc/forum/Issues_with_non-sync_workflow/comment_1_99f89201446005f77d9278a7a889638d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-04-19T16:28:06Z"
+ content="""
+I don't think anything git-annex can do would make git worktree behave the
+way you want it to behave, except for a whole separate mode of operation
+that writes to the git-annex branch via writing to the worktree for it and
+committing.
+"""]]
diff --git a/doc/forum/Issues_with_non-sync_workflow/comment_2_f27ec2462e5a8f6f96c6e2b7dd3f87ca._comment b/doc/forum/Issues_with_non-sync_workflow/comment_2_f27ec2462e5a8f6f96c6e2b7dd3f87ca._comment
new file mode 100644
index 0000000000..9b4b04a62e
--- /dev/null
+++ b/doc/forum/Issues_with_non-sync_workflow/comment_2_f27ec2462e5a8f6f96c6e2b7dd3f87ca._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="lh"
+ avatar="http://cdn.libravatar.org/avatar/d31bade008d7da493d9bfb37d68fd825"
+ subject="comment 2"
+ date="2022-04-19T18:15:53Z"
+ content="""
+But the worktree won't confuse git-annex in any way, right?
+
+If that's the case, I guess I'll just remember to hard reset the worktree every time I want to work with it. As long as git-annex doesn't ever leave things uncommitted on its branch, that should be fine.
+"""]]
diff --git a/doc/forum/Issues_with_non-sync_workflow/comment_3_db02b002a977b57be0102d8ac7c2037f._comment b/doc/forum/Issues_with_non-sync_workflow/comment_3_db02b002a977b57be0102d8ac7c2037f._comment
new file mode 100644
index 0000000000..3b553bcaed
--- /dev/null
+++ b/doc/forum/Issues_with_non-sync_workflow/comment_3_db02b002a977b57be0102d8ac7c2037f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="lh"
+ avatar="http://cdn.libravatar.org/avatar/d31bade008d7da493d9bfb37d68fd825"
+ subject="comment 3"
+ date="2022-04-19T18:40:57Z"
+ content="""
+If I had set annex.alwayscommit=false, would that make resetting the worktree potentially dangerous if I hadn't merged yet?
+"""]]
diff --git a/doc/forum/Issues_with_non-sync_workflow/comment_4_a93d502253cf9f164fbcd23ca755db9d._comment b/doc/forum/Issues_with_non-sync_workflow/comment_4_a93d502253cf9f164fbcd23ca755db9d._comment
new file mode 100644
index 0000000000..87af99bb23
--- /dev/null
+++ b/doc/forum/Issues_with_non-sync_workflow/comment_4_a93d502253cf9f164fbcd23ca755db9d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="lh"
+ avatar="http://cdn.libravatar.org/avatar/d31bade008d7da493d9bfb37d68fd825"
+ subject="comment 4"
+ date="2022-05-09T19:18:01Z"
+ content="""
+Still curious about how `annex.alwayscommit=false` tracks modifications and whether mucking with a `git-annex` worktree could cause data loss with this option enabled.
+"""]]
diff --git a/doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo.mdwn b/doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo.mdwn
new file mode 100644
index 0000000000..c7f821b2b0
--- /dev/null
+++ b/doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo.mdwn
@@ -0,0 +1,63 @@
+Greetings,
+
+Two more issues have come up.  
+
+1) webapp (and assistant) don't always seem to inherit ssh-agent keys (I've setup a passwordless key for gitlab).  It usually takes multiple cycles of killing off ssh and annex-related daemons before a new instance will not fail auth with gitlab - is there a more solid way of doing this?
+
+2) When I do get auth, the assistant / webui will notice file changes (i.e moving a small file that doesn't match annex.largefiles, but the changes don't get committed to origin (gitlab - metadata only).  The log file is below - thougts?
+
+[2019-11-13 20:24:33.378362] main: starting assistant version 7.20191106
+[2019-11-13 20:24:33.439501] TransferScanner: Syncing with origin
+(scanning...) [2019-11-13 20:24:33.529954] Watcher: Performing startup scan
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+fatal: Pathspec 'workflow/cc-archive-exif/LICENSE' is in submodule 'workflow/cc-archive-exif'
+
+git cat-file EOF: user error
+
+fd:39: hFlush: resource vanished (Broken pipe)
+
+fd:39: hFlush: resource vanished (Broken pipe)
+(started...)
+[2019-11-13 20:24:34.481957] Committer: Committing changes to git
+(recording state in git...)
+> GitLab: Disallowed command
+ControlSocket .git/annex/ssh/git@gitlab.com already exists, disabling multiplexing
+[2019-11-13 20:24:35.42995] Pusher: Syncing with origin
+Everything up-to-date
+> GitLab: Disallowed command
+Everything up-to-date
+> GitLab: Disallowed command
+> GitLab: Disallowed command
+> GitLab: Disallowed command
+> GitLab: Disallowed command
+> GitLab: Disallowed command
+
+fd:39: hFlush: resource vanished (Broken pipe)
+
+fd:39: hFlush: resource vanished (Broken pipe)
+[2019-11-13 20:26:09.256217] main: Syncing with origin
+Everything up-to-date
+> GitLab: Disallowed command
+
+fd:39: hFlush: resource vanished (Broken pipe)
+[2019-11-13 20:27:31.922901] Committer: Committing changes to git
+(recording state in git...)
+[2019-11-13 20:27:31.956249] Pusher: Syncing with origin
+Everything up-to-date
+
+fd:39: hFlush: resource vanished (Broken pipe)
+[2019-11-13 20:28:35.846741] Committer: Committing changes to git
+(recording state in git...)
+[2019-11-13 20:28:35.87987] Pusher: Syncing with origin
+Everything up-to-date
+> GitLab: Disallowed command
+> GitLab: Disallowed command
diff --git a/doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo/comment_1_b61139816f55dbc4f7eac22207f243c0._comment b/doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo/comment_1_b61139816f55dbc4f7eac22207f243c0._comment
new file mode 100644
index 0000000000..71e8b6fe65
--- /dev/null
+++ b/doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo/comment_1_b61139816f55dbc4f7eac22207f243c0._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="git-annex@17927e6dc041ab425c14217a97a685adf3ecf44f"
+ nickname="git-annex"
+ avatar="http://cdn.libravatar.org/avatar/66e5c6e044d726597ce5a0ad68f86fe4"
+ subject="Sometimes it sorta works"
+ date="2019-11-14T17:24:11Z"
+ content="""
+So, sometimes (often), it says it synched in the webapp, but no changes show up in any branch on gitlab.  However, sometimes it works.  For example, sometimes after killing everything off (including any ssh sessions) and restarting the webapp, a file I added to the repo locally as a test will show up in the gitlab repo.  When I then move that file, the webapp/assistant wakes up, syncs (says it was successful), and the \"delete\" is processed in the gitlab repo (the old file is deleted), but the \"add\" (the file showing up with a new name) doesn't.  
+
+
+"""]]
diff --git a/doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo/comment_2_f6196f814ed388d276947ffcc92ff37c._comment b/doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo/comment_2_f6196f814ed388d276947ffcc92ff37c._comment
new file mode 100644
index 0000000000..456146b110
--- /dev/null
+++ b/doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo/comment_2_f6196f814ed388d276947ffcc92ff37c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="git-annex@17927e6dc041ab425c14217a97a685adf3ecf44f"
+ nickname="git-annex"
+ avatar="http://cdn.libravatar.org/avatar/66e5c6e044d726597ce5a0ad68f86fe4"
+ subject="comment 2"
+ date="2019-11-19T17:18:18Z"
+ content="""
+bump?  Any thoughts?
+"""]]
diff --git a/doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo/comment_3_1556ebbb2a8db4aa859e3852160df044._comment b/doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo/comment_3_1556ebbb2a8db4aa859e3852160df044._comment
new file mode 100644
index 0000000000..65d4bf4858
--- /dev/null
+++ b/doc/forum/Issues_with_webapp___47___assistant_and_gitlab_as_a_metadata_only_repo/comment_3_1556ebbb2a8db4aa859e3852160df044._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="git-annex@17927e6dc041ab425c14217a97a685adf3ecf44f"
+ nickname="git-annex"
+ avatar="http://cdn.libravatar.org/avatar/66e5c6e044d726597ce5a0ad68f86fe4"
+ subject="git add or git commit does not trigger assistant, but git rm does"
+ date="2019-11-20T01:37:15Z"
+ content="""
+More diagnostics on this one..
+
+I create a file that is below the size threshold for annex, but I do have a gitlab upstream.
+
+1) echo \"foo\" > foo  -  Assistant (or webapp) does not fire
+2) git add foo -  Assistant/webapp does not fire
+3) git commit -am \"random testing\"  - assistant does not fire
+4) git annex sync - foo ends up in gitlab
+
+I remove a file
+
+1) git rm foo  - Assistant fires and file is removed from gitlab
+
+Is this the expected behavior?  If so, why does a git rm trigger annex assistant/webapp, but a git add does not? 
+
+
+"""]]
diff --git a/doc/forum/JavaScript__47__TypeScript_API_for_git-annex_available.mdwn b/doc/forum/JavaScript__47__TypeScript_API_for_git-annex_available.mdwn
new file mode 100644
index 0000000000..68813017e1
--- /dev/null
+++ b/doc/forum/JavaScript__47__TypeScript_API_for_git-annex_available.mdwn
@@ -0,0 +1,13 @@
+Hello,
+
+I just released easy-git-annex v2.0.0. It is a wrapper over the Git and git-annex command lines. It is written in TypeScript and can also be used by JavaScript.
+
+The package is available from https://www.npmjs.com/package/easy-git-annex.
+
+The source repository is https://github.com/jstritch/easy-git-annex.
+
+If you find a problem or want to request a new feature, please create an issue at the repository. The Discussions section is for questions, show and tell, and other relevant subjects.
+
+I hope this package helps the git-annex community.
+
+John
diff --git a/doc/forum/JavaScript__47__TypeScript_API_for_git-annex_available/comment_1_69cdea649eb79fa796fb3713dc0ac23f._comment b/doc/forum/JavaScript__47__TypeScript_API_for_git-annex_available/comment_1_69cdea649eb79fa796fb3713dc0ac23f._comment
new file mode 100644
index 0000000000..867ba149bc
--- /dev/null
+++ b/doc/forum/JavaScript__47__TypeScript_API_for_git-annex_available/comment_1_69cdea649eb79fa796fb3713dc0ac23f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-04-06T17:13:13Z"
+ content="""
+I've added it to [[related_software]].
+"""]]
diff --git a/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__.mdwn b/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__.mdwn
new file mode 100644
index 0000000000..2c70e371ae
--- /dev/null
+++ b/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__.mdwn
@@ -0,0 +1,3 @@
+A question for Joey: What's the expected schedule for v6 repos becoming solid enough to make them the default? Is it next on the priority list or are you still waiting for some git patches to propagate through or something like that?
+
+I'm asking because I make extensive use of v5 direct mode repos. They sometimes give me a bit of trouble in ways which I hope indirect, unlocked, thin v6 repos could fix. However, I don't want to switch to v6 as long as Joey considers it too experimental/unfinished to be made the default repo format. So I'm trying to decide whether I should put in the effort to investigate the issues I'm having (which are annoying but not catastrophic), or just wait until v6 is ready for prime time.
diff --git a/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_1_08d3fd14a57b5d4dfb2cac411aba757f._comment b/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_1_08d3fd14a57b5d4dfb2cac411aba757f._comment
new file mode 100644
index 0000000000..84d0ca100f
--- /dev/null
+++ b/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_1_08d3fd14a57b5d4dfb2cac411aba757f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="current status of v6"
+ date="2018-04-21T19:47:10Z"
+ content="""
+I too would be grateful to know Joey's view on the state of v6.  I would like to replace my direct mode repos.
+
+I'm not sure that the criteria for v6 being suitable for production is that Joey is willing to set it as the default -- there might be reasons other than stability/bugginess not to set it as the default.
+"""]]
diff --git a/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_2_ff5b55e81c0d48968e59e1783943f286._comment b/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_2_ff5b55e81c0d48968e59e1783943f286._comment
new file mode 100644
index 0000000000..00e87120c0
--- /dev/null
+++ b/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_2_ff5b55e81c0d48968e59e1783943f286._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="qiang.fang@ddaed0de00c2925f8036e6c61ce6e12654263ada"
+ nickname="qiang.fang"
+ avatar="http://cdn.libravatar.org/avatar/5a55c6bcb3eaacde1355f9aca0d9384a"
+ subject="comment 2"
+ date="2018-04-26T09:14:54Z"
+ content="""
+The todo list is here
+https://git-annex.branchable.com/todo/smudge/
+"""]]
diff --git a/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_3_f63a66196db731fb04d8e078136eeb3d._comment b/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_3_f63a66196db731fb04d8e078136eeb3d._comment
new file mode 100644
index 0000000000..ec929fa6dc
--- /dev/null
+++ b/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_3_f63a66196db731fb04d8e078136eeb3d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 3"
+ date="2018-04-27T17:15:24Z"
+ content="""
+Seems like the main thing is waiting for patches to git to migrate to systems like Debian stable.
+
+Joey, have your patches been merged?
+"""]]
diff --git a/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_4_a7ea99c0b8bdc257c0c3453bdb5ce1ca._comment b/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_4_a7ea99c0b8bdc257c0c3453bdb5ce1ca._comment
new file mode 100644
index 0000000000..6d496530d9
--- /dev/null
+++ b/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__/comment_4_a7ea99c0b8bdc257c0c3453bdb5ce1ca._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 4"
+ date="2018-05-10T17:51:35Z"
+ content="""
+I just checked -- they have not been merged.
+"""]]
diff --git a/doc/forum/Keybase_encrypted_git_as_a_remote__63__.mdwn b/doc/forum/Keybase_encrypted_git_as_a_remote__63__.mdwn
new file mode 100644
index 0000000000..d474986265
--- /dev/null
+++ b/doc/forum/Keybase_encrypted_git_as_a_remote__63__.mdwn
@@ -0,0 +1,6 @@
+Hello,
+
+Does anybody have experience of the new keybase encrypted git as a remote for git annex?
+
+Details can be found here: https://keybase.io/blog/encrypted-git-for-everyone
+
diff --git a/doc/forum/Keybase_encrypted_git_as_a_remote__63__/comment_1_38d868bf2e93c43091f9f337d9ec840d._comment b/doc/forum/Keybase_encrypted_git_as_a_remote__63__/comment_1_38d868bf2e93c43091f9f337d9ec840d._comment
new file mode 100644
index 0000000000..082c0c0664
--- /dev/null
+++ b/doc/forum/Keybase_encrypted_git_as_a_remote__63__/comment_1_38d868bf2e93c43091f9f337d9ec840d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="501st_alpha1"
+ avatar="http://cdn.libravatar.org/avatar/b6fde94dbf127b822f7b6109399d50c9"
+ subject="Figured out how to sync with Keybase"
+ date="2019-03-07T06:52:25Z"
+ content="""
+While it doesn't \"just work\", I was able to get a solution set up that allows me to use a Keybase encrypted Git repo as a remote.  I added the encrypted remote (with URL e.g. `keybase://private/<user>/<repo>.git`).  A plain `git annex sync` worked, since that just syncs the normal Git branches.  When I tried to do a sync with `--content`, it failed with `unable to check keybase`.  My current workaround is to add a special remote that points to KBFS, e.g. `git annex initremote keybase-rsync type=rsync directory=/keybase/private/<user>/git-annex-files/<repo>/ encryption=none`.  I originally tried a `directory` special remote, but when I did `git annex sync --content keybase-directory`, it worked for a while, but I started getting `rename: interrupted (Interrupted system call)` and similar errors.  Switching to an rsync remote fixed the errors.  I added a script [here](https://github.com/501st-alpha1/scott-script/blob/eba2827ebc1b61fe6b0c2fb2acc9b8cf6641465c/git-annex-add-keybase) to automate that plus a few other checks.
+
+Part way through the sync, I ran into an issue where it would hang immediately after sending a file to KBFS.  As documented [here](https://github.com/keybase/client/issues/16467), running `run_keybase` to restart all the Keybase services fixed the issue for me.
+"""]]
diff --git a/doc/forum/Lacking_webapp_on_Trisquel__47__Ubuntu_Precise.mdwn b/doc/forum/Lacking_webapp_on_Trisquel__47__Ubuntu_Precise.mdwn
new file mode 100644
index 0000000000..d85eefc2cb
--- /dev/null
+++ b/doc/forum/Lacking_webapp_on_Trisquel__47__Ubuntu_Precise.mdwn
@@ -0,0 +1,7 @@
+I'd like to have git-annex assistant running so I can use it to sync files, but when I downloaded and ran it the webapp was missing.  
+
+I've recently begun using Trisquel, or rather the KDE version Triskel.  The current Trisquel is built from Ubuntu Precise, 12.04, the current LTS version.  Thus it seems that I'm a bit behind the current Ubuntu software, and my impression is that this relates to my problem.
+
+In [a post](http://git-annex.branchable.com/forum/Cannot_launch_webapp_on_ubuntu_12.04_using_ppa/) on this forum I read that a version of git-annex was built without the webapp, and that this had since been corrected.  It appears from my git-annex version data that I have an older version, though I downloaded it only two days ago, and it's older than the corrected version.  Is this because my Ubuntu stuff is out of date? 
+
+More importantly, is there any way I can get webapp running on my current OS, or must I wait until Trisquel gets to 13.04?
diff --git a/doc/forum/Lacking_webapp_on_Trisquel__47__Ubuntu_Precise/comment_1_6bd27bd31833336c1df783253378ccae._comment b/doc/forum/Lacking_webapp_on_Trisquel__47__Ubuntu_Precise/comment_1_6bd27bd31833336c1df783253378ccae._comment
new file mode 100644
index 0000000000..43c8ae525f
--- /dev/null
+++ b/doc/forum/Lacking_webapp_on_Trisquel__47__Ubuntu_Precise/comment_1_6bd27bd31833336c1df783253378ccae._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 1"
+ date="2013-07-17T19:36:27Z"
+ content="""
+There is a PPA for Ubuntu Precise, which includes the webapp.
+
+Or you can use the standalone tarball, which works nearly everywhere.
+"""]]
diff --git a/doc/forum/Large_Uploads_to_S3__63__.mdwn b/doc/forum/Large_Uploads_to_S3__63__.mdwn
new file mode 100644
index 0000000000..a72df425fb
--- /dev/null
+++ b/doc/forum/Large_Uploads_to_S3__63__.mdwn
@@ -0,0 +1,12 @@
+I set up a new git annex repo with an S3 remote. Uploading small files works file, but the process fails on larger files (>1 GB) with the following error. 
+
+    copy prosper/loaninfo.p (checking s3...) (to s3...) 
+    99%          10.7MB/s 0s
+    S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, s3ErrorCode = "RequestTimeout", s3ErrorMessage = "Your socket connection to the server was not read from or written to within the timeout period. Idle connections     will be closed.", s3ErrorResource = Nothing, s3ErrorHostId = Just "< a base64 encoded string>", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+
+I tried these different options while setting up remote, but nothing worked.
+partsize=1GiB
+partsize=400MiB
+chunk=100MiB
+
+What am I doing wrong? Should I try an even smaller chunk sie
diff --git a/doc/forum/Large_Uploads_to_S3__63__/comment_1_c1fd2ed0b74ce58f818ab53158e581f3._comment b/doc/forum/Large_Uploads_to_S3__63__/comment_1_c1fd2ed0b74ce58f818ab53158e581f3._comment
new file mode 100644
index 0000000000..f09812ec30
--- /dev/null
+++ b/doc/forum/Large_Uploads_to_S3__63__/comment_1_c1fd2ed0b74ce58f818ab53158e581f3._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-05T16:52:24Z"
+ content="""
+Googling for that message suggests it's pretty common for large file
+uploads amoung different AWS implementations for different programming
+languages. The error message is coming from AWS not git-annex.
+
+If this is happening with a single file transfer, I'm pretty sure git-annex
+is not keeping the S3 connection idle. (If one file transfer succeeded, and
+then a later one in the same git-annex run failed, that might indicate that
+the S3 connection was being reused and timed out in between.)
+
+Based on things like <https://github.com/aws/aws-cli/issues/401>,
+this seems to be down to a network connection problem, especially on
+residential internet connections, such as the link
+getting saturated by something else and so the transfer stalling out.
+
+I think that finding a chunk size that works is your best bet. That
+will let uploads be resumed more or less where they left off.
+
+It might make sense for git-annex to retry an upload that fails this way,
+but imagine if it were a non-chunked 1 gb file and it failed part way
+through every time. That would waste a lot of bandwidth.
+"""]]
diff --git a/doc/forum/Large_Windows_annexes_with___42__nix_remotes.mdwn b/doc/forum/Large_Windows_annexes_with___42__nix_remotes.mdwn
new file mode 100644
index 0000000000..b9c5037815
--- /dev/null
+++ b/doc/forum/Large_Windows_annexes_with___42__nix_remotes.mdwn
@@ -0,0 +1,33 @@
+# Scenario
+
+On multiple Windows systems, I have several directories with related, but somewhat different content.
+
+<pre>E:\Dir\V1\...
+      \V2\...
+      ...
+      \Untracked
+E:\V1-Related
+E:\V2-Related
+  ...</pre>
+
+V1 and V2 each contain dozens of directories with hundreds of files totaling 10s of gigabytes.  The content is very similar, but may have a few differences.  Some, but not all of the directories in E:\Dir should be tracked.
+
+V1- and V2-related directories each contain 10-20 thousand subdirectories with 100K-200K files totaling from 50-200GB per base directory.  Again, there is a lot of overlap between the V*-related directories.
+
+Also, the *-related directory content is related to the V# directories, but cannot be stored in the same place.  There may be 5-10GB of overlap between them.
+
+Then there is my main storage system which is running FreeNAS.  I'd like it to retain copies of all content for protection, backup, and redundancy.  That way I can drop stuff locally from various computers with much smaller drives and still have it.  This system can either be accessed by SMB or via SSH or rsync. It should be possible for me to build git-annex for FreeBSD or to run a Linux VM on it.
+
+# Questions
+
+Is direct mode supported at all on NTFS?  I'd like to avoid the file duplication and copying.  I see it gets flagged as a broken file system. (No need to explain, I worked in the guts of Cygwin.)
+
+Is using git-annex and the available tools even realistic with so many files?  I've read a lot of the forum and tip posts, but my head is still swimming.
+
+How might I best track V# and V#-related together?  Or should I could keep them in separate annexes and just script them together.
+
+What is the best way to keep V#-related in the root directory?  I've considered adding an E:\annex because .git in the root directory can be problematic.  If I do, how would I associate those directories with the annex?  GIT_DIR?
+
+I've noticed using git-annex over a locally mounted drive letter or using a UNC path is *slow*.  I assume it's being treated as local and running multiple passes across the network while reading, writing, checksumming and verifying them.  I base this on seeing uplink and downlink saturation while syncing.  What would be the best, most performant solution for accessing it?
+
+Finally, is there anyway to tip, donate or contribute to you?
diff --git a/doc/forum/Large_Windows_annexes_with___42__nix_remotes/comment_1_a38e0ecef49a81a1d2b3d2eaabab65ab._comment b/doc/forum/Large_Windows_annexes_with___42__nix_remotes/comment_1_a38e0ecef49a81a1d2b3d2eaabab65ab._comment
new file mode 100644
index 0000000000..11ba2c0d15
--- /dev/null
+++ b/doc/forum/Large_Windows_annexes_with___42__nix_remotes/comment_1_a38e0ecef49a81a1d2b3d2eaabab65ab._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-01-19T16:45:30Z"
+ content="""
+direct-mode doesn't exist anymore, it is replaced with the [[annex.thin config|https://git-annex.branchable.com/tips/unlocked_files]] (See \"using less disk space\"). And yes, it works on NTFS.
+
+It definitely isn't going to be fast, the numbers you gave suggests that there will be ~1000000 files per repository (For the V*-related dirs). Still you should try it and see if it's fast enough for you. Some tips to improve performance: Don't use `include=`/`exclude=` in preferred-content-expressions and [[Repositories with large number of files|https://git-annex.branchable.com/tips/Repositories_with_large_number_of_files/]]. My experimental script [[here|https://git-annex.branchable.com/todo/Incremental_git_annex_sync_--content_--all/]] might also be worth a try.
+
+Having the root of the repo on the root of the drive and then excluding everything that shouldn't be in the repo via `.gitignore` can be a vivable approach. But with that many files I'd create one repo per directory. It could also be done with git worktrees.
+
+Don't use git-annex on top of a network share, in that case run it directly on the server. git-annex is designed to run on local drives/storage. Also, git-annex on windows is way slower than on linux.
+
+You can donate via [[Patreon|https://www.patreon.com/joeyh]] and [[Liberapay|https://liberapay.com/joeyh/]].
+
+"""]]
diff --git a/doc/forum/Large_Windows_annexes_with___42__nix_remotes/comment_1_c59077a9d6500df0cd88ac5a18085085._comment b/doc/forum/Large_Windows_annexes_with___42__nix_remotes/comment_1_c59077a9d6500df0cd88ac5a18085085._comment
new file mode 100644
index 0000000000..02a30fba5e
--- /dev/null
+++ b/doc/forum/Large_Windows_annexes_with___42__nix_remotes/comment_1_c59077a9d6500df0cd88ac5a18085085._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-01-19T15:58:37Z"
+ content="""
+Direct mode was only supported by old versions of git-annex. It did work on
+windows. The replacement (adusted unlocked branches + annex.thin) is better
+in every way except one: On windows (and some filesystems like FAT), it is
+not able to avoid storing 2 copies of files, because git-annex isn't able
+to hard link files there. If there was a reasonable way to do that on
+windows, that could be a big improvement, but I have not dug into whether
+windows has anything similar enough to hard link for git-annex to use it.
+
+git-annex scales to hundreds of thousands of files.
+
+If I had two directories like your V# and V#-related, I might make them
+each into their own repository, and set them each as a git remote of the
+other. That would let git-annex know that identical files have two copies.
+(Or, the parent directory could be made into a git-annex repository, which
+would let git-annex deduplicate identical files, but since that needs
+symlink support, it won't happen on windows.)
+
+You can certianly use GIT_DIR with git-annex.
+
+Generally the best thing to do with storage on the other side of a network
+connection is to run git-annex on it locally, or use it as some kind of
+special remote.
+"""]]
diff --git a/doc/forum/Large_Windows_annexes_with___42__nix_remotes/comment_2_bfc92cb2117b26eec95687950827c78b._comment b/doc/forum/Large_Windows_annexes_with___42__nix_remotes/comment_2_bfc92cb2117b26eec95687950827c78b._comment
new file mode 100644
index 0000000000..793cd19507
--- /dev/null
+++ b/doc/forum/Large_Windows_annexes_with___42__nix_remotes/comment_2_bfc92cb2117b26eec95687950827c78b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-01-19T16:11:42Z"
+ content="""
+As far as support goes, see [[thanks]].
+"""]]
diff --git a/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects.mdwn b/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects.mdwn
new file mode 100644
index 0000000000..fe9167e975
--- /dev/null
+++ b/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects.mdwn
@@ -0,0 +1,14 @@
+I have an old repository, and I'm not sure what I have done with it, but it seems to be broken in an interesting fashion.
+
+    $ ls -l pix/image001.jpg 
+    lrwxrwxrwx 1 la la 187 Sep  5 11:31 pix/image001.jpg -> ../.git/annex/objects/G7/J7/SHA256-s99372--0458b0b72b394a719b72032971b880a8dfafa65e8048ec6fc6c861fc3ea5e702/SHA256-s99372--0458b0b72b394a719b72032971b880a8dfafa65e8048ec6fc6c861fc3ea5e702
+    $ ls -lL pix/image001.jpg 
+    ls: cannot access pix/image001.jpg: No such file or directory
+    $ find .git/annex/objects/ -type f -name '*0458b0b72*'
+    .git/annex/objects/477/75c/SHA256-s99372--0458b0b72b394a719b72032971b880a8dfafa65e8048ec6fc6c861fc3ea5e702/SHA256-s99372--0458b0b72b394a719b72032971b880a8dfafa65e8048ec6fc6c861fc3ea5e702
+    $ git config annex.version
+    5
+
+So the symlinks use a layout where index directories have two-letter names, but the actual layout in the annex uses directory names with three hexadecimal digits.
+
+Is there some straightforward way to fix this or do I need to figure the index format and hack up a script to convert the annex repository?
diff --git a/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_1_854786810dc4246cdaa38ff10c55bbca._comment b/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_1_854786810dc4246cdaa38ff10c55bbca._comment
new file mode 100644
index 0000000000..d4565f25b6
--- /dev/null
+++ b/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_1_854786810dc4246cdaa38ff10c55bbca._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lealanko"
+ subject="comment 1"
+ date="2015-09-06T13:11:44Z"
+ content="""
+I think I figured it out: the repository was originally [[bare|bare repositories]], and I converted it to non-bare manually. But that doesn't work, because bare annex repositories use [[a different directory layout|internals/hashing]].
+
+I can understand why the hex-based layout is preferred (it's more portable), but deliberate incompatibility with the symlinks isn't very nice. I wish there was a way to upgrade the entire repository to a format that used the hex paths for symlinks, so bare and non-bare repositories used the same layout.
+"""]]
diff --git a/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment b/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment
new file mode 100644
index 0000000000..46ddb5f167
--- /dev/null
+++ b/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-09-09T18:18:17Z"
+ content="""
+I wish this incompatibility didn't exist either, but the transition to use
+consistently 3 letter hash directories would be too much to ask of all the
+users. And there are ways to convert a bare to non-bare that don't have
+this problem, like making a clone and using `git annex move --all --from
+origin`
+
+There's an easy way to finish your conversion from bare to non-bare.
+Just move .git/annex/objects to old-objects, and run `git annex add
+old-objects --backend=SHA256`. That will rename all the files into the right places for a
+non-bare repository, so your existing symlinks will work. You can then
+`rm -rf old-objects` to clean up.
+
+Note that method assumes that SHA256 is the backend of everything in that
+repo. If not, it gets a bit trickier; you'd need to use `git-annex
+setkey'
+"""]]
diff --git a/doc/forum/Let_watch_selectively_annex_files.mdwn b/doc/forum/Let_watch_selectively_annex_files.mdwn
new file mode 100644
index 0000000000..f56b19452a
--- /dev/null
+++ b/doc/forum/Let_watch_selectively_annex_files.mdwn
@@ -0,0 +1,27 @@
+Hello,
+
+First of all, thanks to Joey for developing git-annex, good job!
+
+I have a small feature request: when running git annex watch, new files are automatically added to the annex. It would be nice to let this depend on an attribute: add a file to annex if an attribute is set, otherwise do a regular git add.
+
+My use-case is the following: I have a repository containing documents I'm working on (mostly LaTeX), which I'd like to be regular files in git (no annex), and a bunch of extra documentation (pdfs) and images, which I'd like to go to the annex. I currently set a git-attribute (addtoannex), and use a shell script to selectively add files to annex as follows:
+
+Content of .gitattributes:
+
+    *.png addtoannex
+    *.jpg addtoannex
+
+Snippet of add script:
+
+    git check-attr addtoannex "$FILE" | grep -q ": set$"
+    if [ $? -eq 0 ]; then
+        git annex add "$FILE"
+    else
+        git add "$FILE"
+    fi
+
+It would be great if the watcher could honour an attribute.
+
+best regards,
+
+Tom
diff --git a/doc/forum/Let_watch_selectively_annex_files/comment_1_8379de87d16502d9aadf252da01e4d9a._comment b/doc/forum/Let_watch_selectively_annex_files/comment_1_8379de87d16502d9aadf252da01e4d9a._comment
new file mode 100644
index 0000000000..415b088941
--- /dev/null
+++ b/doc/forum/Let_watch_selectively_annex_files/comment_1_8379de87d16502d9aadf252da01e4d9a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.125"
+ subject="comment 1"
+ date="2013-02-07T18:10:14Z"
+ content="""
+This has been requested a couple of times in different places.
+
+The problem with using a git attribute is it only allows basic matching on filenames. Some users would prefer to use the size of the file. So if/when this gets implemented it will probably not use a git attribute, but some other config setting.
+"""]]
diff --git a/doc/forum/Let_watch_selectively_annex_files/comment_2_2219ff6b4dc927eb2a299cd1af90aed8._comment b/doc/forum/Let_watch_selectively_annex_files/comment_2_2219ff6b4dc927eb2a299cd1af90aed8._comment
new file mode 100644
index 0000000000..d6cee26d5c
--- /dev/null
+++ b/doc/forum/Let_watch_selectively_annex_files/comment_2_2219ff6b4dc927eb2a299cd1af90aed8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-06-11T14:28:56Z"
+ content="""
+See [[tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant]]
+"""]]
diff --git a/doc/forum/Link_to_local_remote_instead_of_broken_link_when_possible__63__.mdwn b/doc/forum/Link_to_local_remote_instead_of_broken_link_when_possible__63__.mdwn
new file mode 100644
index 0000000000..dfe8afe2c9
--- /dev/null
+++ b/doc/forum/Link_to_local_remote_instead_of_broken_link_when_possible__63__.mdwn
@@ -0,0 +1,4 @@
+Hi,
+
+Suppose I have an annexed file whose content is stored on an extenal hard drive.
+When the hard drive is mounted, is it possible to have immediately access to this file without transfering it, by modifying the symlink to point to the file content on the hard drive instead of having a broken link?
diff --git a/doc/forum/Link_to_local_remote_instead_of_broken_link_when_possible__63__/comment_1_ce0464d5fca6ada9f1477831fd47ce09._comment b/doc/forum/Link_to_local_remote_instead_of_broken_link_when_possible__63__/comment_1_ce0464d5fca6ada9f1477831fd47ce09._comment
new file mode 100644
index 0000000000..ee6ec690e9
--- /dev/null
+++ b/doc/forum/Link_to_local_remote_instead_of_broken_link_when_possible__63__/comment_1_ce0464d5fca6ada9f1477831fd47ce09._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 1"
+ date="2014-04-02T18:25:16Z"
+ content="""
+See [[todo/union_mounting]]
+"""]]
diff --git a/doc/forum/Links_or_actual_files__63___Confused__33__.mdwn b/doc/forum/Links_or_actual_files__63___Confused__33__.mdwn
new file mode 100644
index 0000000000..8d7ef2c172
--- /dev/null
+++ b/doc/forum/Links_or_actual_files__63___Confused__33__.mdwn
@@ -0,0 +1,21 @@
+I don't think it's a bug or a todo, just a request for clarification.
+
+So, I installed git-annex first on a Mac, and created the initial repository, and started dropping stuff into it. All fine.
+
+Created a second repository on an external (but never disconnected, also does Time Machine) drive. All fine. Everything's there.
+
+Went across the room to my Linux desktop, installed git-annex, and tried to pair it to my Mac's git-annex repo. Hit <a href="http://git-annex.branchable.com/bugs/bad_comment_in_ssh_public_key_ssh-rsa/#comment-0ee00f307909723fdf8c73695787f067">this bug</a>, installed latest git-annex from tarball and got past that and got the pairing done. Syncing happened, all looked well...
+
+But when I look in the annex dir on that Linux machine, I now just see symlinks to the actual files in the repo's .git/annex stuff. It kinda works, but it's a bit distracting, especially if you open such a file in any desktop app and you can see it's got the target of the link (some sha-value filename.ext) rather than the sensibly-named link. Including files created and coped into that annex on that machine. (In Nautilus they all show with symlink & lock emblems.)
+
+Look again at some documentation, and apparently it's <a href="http://git-annex.branchable.com/how_it_works/">supposed to do this</a>
+
+Which makes me wonder why it *isn't* doing it on the Mac I started the repository on?
+
+Went to another mac (laptop) and installed git-annex, and set up pairing to the first mac - as far as I can tell, doing the exact same procedure as I did under Linux. TBH through the webapp there's not much scope for doing it a different way. Files sync across...
+
+And there they are, the actual files, directly in the annex dir, not symlinks.
+
+(I am by the way confirming this at the commandline, it's not just what Finder/Nautilus may be displaying to me graphically.)
+
+Now, seeing the actual files in the annex directory is what I *prefer*; but I'm a: confused as to why the Macs are doing it that way but Linux isn't, and b: given the "how it works" link, why everything isn't using the links.
diff --git a/doc/forum/Links_or_actual_files__63___Confused__33__/comment_1_779cee2448d7070b1dd636d01296c01e._comment b/doc/forum/Links_or_actual_files__63___Confused__33__/comment_1_779cee2448d7070b1dd636d01296c01e._comment
new file mode 100644
index 0000000000..0122cf45bc
--- /dev/null
+++ b/doc/forum/Links_or_actual_files__63___Confused__33__/comment_1_779cee2448d7070b1dd636d01296c01e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.51"
+ subject="comment 1"
+ date="2013-09-12T17:58:24Z"
+ content="""
+When you create a git-annex repository using the webapp, it uses [[direct_mode]]. That is not the default if you create a repository by hand at the command line, although you can enable it if you prefer it.
+"""]]
diff --git a/doc/forum/Links_or_actual_files__63___Confused__33__/comment_2_bccda88697ab7beec0b9fe9ee0230688._comment b/doc/forum/Links_or_actual_files__63___Confused__33__/comment_2_bccda88697ab7beec0b9fe9ee0230688._comment
new file mode 100644
index 0000000000..c6a851eff0
--- /dev/null
+++ b/doc/forum/Links_or_actual_files__63___Confused__33__/comment_2_bccda88697ab7beec0b9fe9ee0230688._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA"
+ nickname="Rachel"
+ subject="webapp/direct"
+ date="2013-09-12T18:17:51Z"
+ content="""
+well, i did it using the webapp both times; i've barely scratched at the git-annex commandline so far.
+
+However... I then tried to repeat it on another linux box (running ubuntu saucy and the version of git-annex in that repo) and it worked as expected: Real files in the annex directory, ie: as I understand it, direct mode.
+
+So, went back to the first linux box (running ubuntu raring), and cleared everything off, quit and started again, doing the same thing again, and *it* did the direct mode thing itself this time.
+
+Which I think leaves me with it the way I want it. :-)
+
+My only guess is, maybe it got set up in non-direct mode when I first started using the older git-annex in the raring repos, before failing with the bad comment in ssh public key bug, at which point I switched to the downloaded-today tarball and just tried to resume. Starting from scratch with the newer version worked.
+
+I'm sure more questions to come later; am a Dropbox fugitive by way of ownCloud (won't-fix bug on version upgrades) basically trying to replicate that kind of convenience. But those are for other postings.
+"""]]
diff --git a/doc/forum/Links_or_actual_files__63___Confused__33__/comment_3_c2a9da3f03b55ff294dc0d2010380119._comment b/doc/forum/Links_or_actual_files__63___Confused__33__/comment_3_c2a9da3f03b55ff294dc0d2010380119._comment
new file mode 100644
index 0000000000..5df67c6057
--- /dev/null
+++ b/doc/forum/Links_or_actual_files__63___Confused__33__/comment_3_c2a9da3f03b55ff294dc0d2010380119._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.51"
+ subject="comment 3"
+ date="2013-09-12T20:22:44Z"
+ content="""
+Yep, relatively ancient (from last year) versions of the webapp didn't use direct mode by default, and have various bugs as well.
+"""]]
diff --git a/doc/forum/List_annexed_files_in_chronological_order__63__.mdwn b/doc/forum/List_annexed_files_in_chronological_order__63__.mdwn
new file mode 100644
index 0000000000..f4003c6563
--- /dev/null
+++ b/doc/forum/List_annexed_files_in_chronological_order__63__.mdwn
@@ -0,0 +1 @@
+How can I get git-annex to list the annexed files in the order they have been added?
diff --git a/doc/forum/List_annexed_files_in_chronological_order__63__/comment_1_825c950574b3a2f083554f474c9f7b50._comment b/doc/forum/List_annexed_files_in_chronological_order__63__/comment_1_825c950574b3a2f083554f474c9f7b50._comment
new file mode 100644
index 0000000000..30387e78d5
--- /dev/null
+++ b/doc/forum/List_annexed_files_in_chronological_order__63__/comment_1_825c950574b3a2f083554f474c9f7b50._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-01-05T16:45:08Z"
+ content="""
+This is a general git question, not a git-annex question. That is, any
+command that can list the files in a git repo, in whatever order you want,
+will also work in a git-annex repo.
+
+You probably want to use `git log --stat`, possibly with some more options
+to control the output format.
+"""]]
diff --git a/doc/forum/List_if_files_are_stored_in_annex_or_in_git.mdwn b/doc/forum/List_if_files_are_stored_in_annex_or_in_git.mdwn
new file mode 100644
index 0000000000..68eca86317
--- /dev/null
+++ b/doc/forum/List_if_files_are_stored_in_annex_or_in_git.mdwn
@@ -0,0 +1,7 @@
+I‘ve decided to get my head wrapped around setting up `annex.largefiles` and stop manually deciding to `git add` or `git annex add` files as I go. I fumbled a bit, unsure if I had configured things correctly as it appeared that `git add` was still adding my large files into git history. I forgot that `git add` is configured to add annexed files unlocked and so the symlink I was expecting to see wasn't there. `git annex list` and `git annex find` helped me to see which files where staged to be committed into annex storage.
+
+What I would like to be able to do is to more easily list files which are not present in annex storage and are tracked into git storage. I have had a play with `git annex find` and the matching options however I have been unable to display a list of files that I have added as small files. Is there a way to achieve this?
+
+What I think would be ideal is for `git annex list` to show this information or another command which can print a tree with files in either of the two storage modes.
+
+Thanks for any help!
diff --git a/doc/forum/List_if_files_are_stored_in_annex_or_in_git/comment_1_9206087f7320982ef26ef401d39a394f._comment b/doc/forum/List_if_files_are_stored_in_annex_or_in_git/comment_1_9206087f7320982ef26ef401d39a394f._comment
new file mode 100644
index 0000000000..e38ee78ef8
--- /dev/null
+++ b/doc/forum/List_if_files_are_stored_in_annex_or_in_git/comment_1_9206087f7320982ef26ef401d39a394f._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-06-14T18:38:13Z"
+ content="""
+`git annex find`, like all git-annex commands except for `add`, 
+skips over non-annexed files.
+
+What you can do is get a list of all annexed files:
+
+	git annex find --include '*' | sort > annexed-files
+
+And get a list of all files git knows:
+
+	git -c core.quotepath=off ls-files | sort > all-files
+
+And then find files that are in the second list but not the first:
+
+	comm -1 -3 annexed-files all-files
+"""]]
diff --git a/doc/forum/List_if_files_are_stored_in_annex_or_in_git/comment_2_2eeef9505e976288e7a09f31d0c09dda._comment b/doc/forum/List_if_files_are_stored_in_annex_or_in_git/comment_2_2eeef9505e976288e7a09f31d0c09dda._comment
new file mode 100644
index 0000000000..488d43cf38
--- /dev/null
+++ b/doc/forum/List_if_files_are_stored_in_annex_or_in_git/comment_2_2eeef9505e976288e7a09f31d0c09dda._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="james@06209b7878fcf3b5c46b8028dacb3cec6609369c"
+ nickname="james"
+ avatar="http://cdn.libravatar.org/avatar/a11da294e0e89c859bd11a3b1dbb0dda"
+ subject="comment 2"
+ date="2021-06-17T18:14:45Z"
+ content="""
+That’s great, thanks! I decided to allow some more files to be added as `smallfiles` when I saw the outcome of adding my files.
+
+Going to see if I can wrangle some GNU-Fu and get this into a one liner. 
+
+"""]]
diff --git a/doc/forum/Local_and_remote_in_direct_mode.mdwn b/doc/forum/Local_and_remote_in_direct_mode.mdwn
new file mode 100644
index 0000000000..128d8eab61
--- /dev/null
+++ b/doc/forum/Local_and_remote_in_direct_mode.mdwn
@@ -0,0 +1,7 @@
+I have two machines (A and B ) both have a directory called "inbox"
+I want to sync these two directories. So I ran git annex assistant on machine A and set up a remote to B with **ssh** and selected **client: a repository on your computer**.
+
+The end result is that I have something that looks like a git bare repo on machine B and I have no files on A from machine B.
+
+What am I doing wrong? What shall I do to achieve my goal?
+It is kind of dropbox functionality what I want. (Which I never used for security/policy reasons.)
diff --git a/doc/forum/Local_and_remote_in_direct_mode/comment_1_45f89ebcb6092d1b2582feebc8a5e9d7._comment b/doc/forum/Local_and_remote_in_direct_mode/comment_1_45f89ebcb6092d1b2582feebc8a5e9d7._comment
new file mode 100644
index 0000000000..f7244cabc8
--- /dev/null
+++ b/doc/forum/Local_and_remote_in_direct_mode/comment_1_45f89ebcb6092d1b2582feebc8a5e9d7._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-19T18:05:58Z"
+ content="""
+The \"Remote server using ssh\" option in the webapp is intended to set up a bare git repository on a server, not a non-bare git repository on a client.
+
+For what you want, both your computers need to be running the git-annex assistant.
+
+* If the computers are on the same network, pick the \"Local computer\" option on one to start a pairing process with the other.
+* If the computers are not on the same network, but can (apparently) access one-another by ssh, then you're a lucky guy. :) But the webapp doesn't cater to this unusual configuration (unless the local pairing option above works). All you need to do though, it manually add a git remote on each that points to the already existing, git-annex assistant managed repository on the other. Eg: `git remote add B ssh://machineB:/~/annex`
+* If the computers are not on the same network, and cannot access each other directly using ssh, you will need
+to use the XMPP option, and a transfer remote that both can access.
+"""]]
diff --git a/doc/forum/Local_and_remote_in_direct_mode/comment_2_90eeb2bffdb2db8032f9a0eac630ed56._comment b/doc/forum/Local_and_remote_in_direct_mode/comment_2_90eeb2bffdb2db8032f9a0eac630ed56._comment
new file mode 100644
index 0000000000..539ad1357f
--- /dev/null
+++ b/doc/forum/Local_and_remote_in_direct_mode/comment_2_90eeb2bffdb2db8032f9a0eac630ed56._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Petter_petterson"
+ ip="89.160.15.173"
+ subject="comment 2"
+ date="2014-09-16T08:15:05Z"
+ content="""
+Doing git remote add B ssh://machineB:/~/annex still makes the repository on machineB a bare one, just try it and check git config -l | grep core.bare...
+"""]]
diff --git a/doc/forum/Local_and_remote_in_direct_mode/comment_3_859ec2b3a8e938073b2099fdc5781109._comment b/doc/forum/Local_and_remote_in_direct_mode/comment_3_859ec2b3a8e938073b2099fdc5781109._comment
new file mode 100644
index 0000000000..f39c95c037
--- /dev/null
+++ b/doc/forum/Local_and_remote_in_direct_mode/comment_3_859ec2b3a8e938073b2099fdc5781109._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-09-18T17:55:21Z"
+ content="""
+Petter_petterson, I think you're mistaken about that. If you were right, that would be a massive bug in git -- nothing git-annex specific about that command after all.
+"""]]
diff --git a/doc/forum/Locating_errors_on_fsck.mdwn b/doc/forum/Locating_errors_on_fsck.mdwn
new file mode 100644
index 0000000000..3e1fcd8bc5
--- /dev/null
+++ b/doc/forum/Locating_errors_on_fsck.mdwn
@@ -0,0 +1,7 @@
+When I run `git-annex fsck` I see a lot of output passing by the screen. In the end, after many hours, I see an error count.
+
+Now, how do I see what files had problems and what is wrong with them? I can't see any option mentioning a log file or similar mechanism in the man page. Would I need to re-run the command and discard STDOUT? At this point I'm not even sure that would work.
+
+What is the proper way to run `fsck` so that I can examine the problems it finds?
+
+Thank you.
diff --git a/doc/forum/Locating_errors_on_fsck/comment_1_5a4c54b59f2a3f8519f2dab608a1e92d._comment b/doc/forum/Locating_errors_on_fsck/comment_1_5a4c54b59f2a3f8519f2dab608a1e92d._comment
new file mode 100644
index 0000000000..90428a4923
--- /dev/null
+++ b/doc/forum/Locating_errors_on_fsck/comment_1_5a4c54b59f2a3f8519f2dab608a1e92d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-04T19:34:54Z"
+ content="""
+You can just discard the stdout, all errors/warnings that it outputs to
+stderr mention the name of the file that has the problem.
+"""]]
diff --git a/doc/forum/Locating_errors_on_fsck/comment_2_0277bac79694efffba0e59706aa66c63._comment b/doc/forum/Locating_errors_on_fsck/comment_2_0277bac79694efffba0e59706aa66c63._comment
new file mode 100644
index 0000000000..291cfa0495
--- /dev/null
+++ b/doc/forum/Locating_errors_on_fsck/comment_2_0277bac79694efffba0e59706aa66c63._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="Thanks"
+ date="2018-10-17T22:34:20Z"
+ content="""
+Thank you for your reply. It was quite helpful.
+"""]]
diff --git a/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning.mdwn b/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning.mdwn
new file mode 100644
index 0000000000..e7062ff29c
--- /dev/null
+++ b/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning.mdwn
@@ -0,0 +1,20 @@
+I have a git annex repository which I use to store versioned binaries in a regular git repository. We also use submodules in the repository (the sources of the versioned binaries) but the binaries are not in the submodules. This has worked great for us.
+
+Recently, there have been a number of changes (I got a new laptop, moved to fedora 20, renamed the repository, etc...) that happened at once. Now when I checkout a clean working version of the repository and then run git annex get . and then do an unlock and a lock on the file I get the "Locking this file would discard any changes you have made to it. Use 'git annex add' to stage your changes. (Or, use --force to override)" warning.
+
+I have tried to isolate this as much as possible but can't find what caused this. On a co-worker's laptop it seems to work fine so far. A clean repository didn't fix it. An old repository didn't fix it (though I recall it working there previously on this laptop). It did work and just stopped recently.
+
+    $ git annex version
+    git-annex version: 5.20140107
+    build flags: Assistant Inotify DBus Quvi TDFA
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+    remote types: git gcrypt bup directory rsync web glacier hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+    $ git annex lock --debug --verbose vendors/unittest-xml-reporting-1.5.0.tar.gz  # (some names changed to protect the innocent)
+    [2014-02-05 12:54:45 IST] read: git ["--git-dir=/home/user/loppa_deuce/loppa/.git","--work-tree=/home/user/loppa_deuce/loppa","diff","--name-only","--diff-filter=T","-z","--","vendors/unittest-xml-reporting-1.5.0.tar.gz"]
+    [2014-02-05 12:54:45 IST] chat: git ["--git-dir=/home/user/loppa_deuce/loppa/.git","--work-tree=/home/user/loppa_deuce/loppa","cat-file","--batch"]
+    [2014-02-05 12:54:45 IST] read: git ["--git-dir=/home/user/loppa_deuce/loppa/.git","--work-tree=/home/user/loppa_deuce/loppa","diff","--name-only","--diff-filter=T","-z","--cached","--","vendors/unittest-xml-reporting-1.5.0.tar.gz"]
+    lock vendors/unittest-xml-reporting-1.5.0.tar.gz git-annex: Locking this file would discard any changes you have made to it. Use 'git annex add' to stage your changes. (Or, use --force to override)
diff --git a/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_1_25a04c7345f5b626aa71524603c833ed._comment b/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_1_25a04c7345f5b626aa71524603c833ed._comment
new file mode 100644
index 0000000000..84f556d654
--- /dev/null
+++ b/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_1_25a04c7345f5b626aa71524603c833ed._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmfVOIl06X7NKio-NBYZ-cfw5LFVqHMX8o"
+ nickname="Daniel"
+ subject="Hash is the same"
+ date="2014-02-05T11:13:12Z"
+ content="""
+I forgot to mention that I also checked the hash of the file to make sure that nothing changed the file and nothing changed. Just quick unlock/lock triggers it.
+"""]]
diff --git a/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_2_7146a3c69749b9b1001fffc6e7a8bcda._comment b/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_2_7146a3c69749b9b1001fffc6e7a8bcda._comment
new file mode 100644
index 0000000000..cc5e853169
--- /dev/null
+++ b/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_2_7146a3c69749b9b1001fffc6e7a8bcda._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmfVOIl06X7NKio-NBYZ-cfw5LFVqHMX8o"
+ nickname="Daniel"
+ subject="New git-annex package to blame"
+ date="2014-02-05T14:23:40Z"
+ content="""
+I downgraded my git-annex version, rechecked out the repository and now everything works.
+    $ git annex version
+    git-annex version: 4.20130827
+    build flags: Assistant Inotify
+
+"""]]
diff --git a/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_3_fd39e6ceffd9bf0709658c34945d8699._comment b/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_3_fd39e6ceffd9bf0709658c34945d8699._comment
new file mode 100644
index 0000000000..5b23df8707
--- /dev/null
+++ b/doc/forum/Locking_and_then_unlocking_a_file_results_in_file_changed_warning/comment_3_fd39e6ceffd9bf0709658c34945d8699._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="206.74.132.139"
+ subject="comment 3"
+ date="2014-02-06T17:05:45Z"
+ content="""
+Recent versions of git-annex have tried to extend the --force option to be needed in any operation that can possibly cause data loss. This includes locking a file, since that throws away any changes.
+
+Note that `git annex lock` does not check if the file is unmodified. For a few reasons including 
+
+* some backends don't include a checksum
+* it would be expensive to check a checksum
+* the file could get modified after or during a checksum check, and those modifications would be missed
+
+If you are sure you want to throw away any changes, use --force as suggested. If not, use `git annex add $file`, and assuming you're using a checksumming backend, it will notice the file has not changed and do what you want `git annex lock $file` to have done in this case.
+"""]]
diff --git a/doc/forum/Looking_at_the_webapp_on_OSX.mdwn b/doc/forum/Looking_at_the_webapp_on_OSX.mdwn
new file mode 100644
index 0000000000..b2c514d835
--- /dev/null
+++ b/doc/forum/Looking_at_the_webapp_on_OSX.mdwn
@@ -0,0 +1,18 @@
+Not logging this in the bugs section, but poking at the new webapp feature...
+
+<pre>
+laplace:annex jtang$ git annex webapp -d
+[2012-07-26 19:02:50 IST] read: git ["--git-dir=/Users/jtang/annex/.git","--work-tree=/Users/jtang/annex","show-ref","git-annex"] 
+[2012-07-26 19:02:50 IST] read: git ["--git-dir=/Users/jtang/annex/.git","--work-tree=/Users/jtang/annex","show-ref","--hash","refs/heads/git-annex"] 
+[2012-07-26 19:02:50 IST] read: git ["--git-dir=/Users/jtang/annex/.git","--work-tree=/Users/jtang/annex","log","refs/heads/git-annex..731005d121426a38b206c4544da02cdb3b974974","--oneline","-n1"] 
+[2012-07-26 19:02:50 IST] read: git ["--git-dir=/Users/jtang/annex/.git","--work-tree=/Users/jtang/annex","log","refs/heads/git-annex..d36d8d88847decc2320f0be22892ad94a8abe594","--oneline","-n1"] 
+[2012-07-26 19:02:50 IST] read: git ["--git-dir=/Users/jtang/annex/.git","--work-tree=/Users/jtang/annex","log","refs/heads/git-annex..57bcddc14d03b61028f7002e2dabcc5181d74f3d","--oneline","-n1"] 
+[2012-07-26 19:02:50 IST] read: git ["--git-dir=/Users/jtang/annex/.git","--work-tree=/Users/jtang/annex","log","refs/heads/git-annex..372aceaf49b60ebe31cc3fe2e52ba4fbe99c134f","--oneline","-n1"] 
+[2012-07-26 19:02:50 IST] chat: git ["--git-dir=/Users/jtang/annex/.git","--work-tree=/Users/jtang/annex","cat-file","--batch"] 
+[2012-07-26 19:02:50 IST] read: git ["config","--null","--list"] 
+[2012-07-26 19:02:50 IST] call: open ["file:///Users/jtang/annex/.git/annex/webapp.html"] 
+The file /Users/jtang/annex/.git/annex/webapp.html does not exist.
+git-annex: failed to start web browser on url file:///Users/jtang/annex/.git/annex/webapp.html
+</pre>
+
+I would have expected the open command to open up http://localhost:port/ instead of a file on my machine. Anyway, its just an observation on the current state of the webapp feature, not expecting it to work enough for me to test it ;)
diff --git a/doc/forum/Looking_at_the_webapp_on_OSX/comment_1_68820f2f469356633c1abb18a47e0c59._comment b/doc/forum/Looking_at_the_webapp_on_OSX/comment_1_68820f2f469356633c1abb18a47e0c59._comment
new file mode 100644
index 0000000000..9aa05c8f0a
--- /dev/null
+++ b/doc/forum/Looking_at_the_webapp_on_OSX/comment_1_68820f2f469356633c1abb18a47e0c59._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.189"
+ subject="comment 1"
+ date="2012-07-26T18:17:40Z"
+ content="""
+This could happen if you already had an old version of git-annex assistant running in that repository.
+
+Try:
+
+git annex assistant --stop ; git annex webapp
+"""]]
diff --git a/doc/forum/Looking_at_the_webapp_on_OSX/comment_2_4ce86546d8a135df9cfab46b4612fa0b._comment b/doc/forum/Looking_at_the_webapp_on_OSX/comment_2_4ce86546d8a135df9cfab46b4612fa0b._comment
new file mode 100644
index 0000000000..b24956b8c7
--- /dev/null
+++ b/doc/forum/Looking_at_the_webapp_on_OSX/comment_2_4ce86546d8a135df9cfab46b4612fa0b._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="jtang"
+ ip="79.97.135.214"
+ subject="comment 2"
+ date="2012-07-26T20:42:37Z"
+ content="""
+The last few commits fixed the webapp startup quirk, it doesn't work yet for me as the watch command is probably failing
+
+<pre>
+laplace:annex jtang$ git annex webapp  -d
+[2012-07-26 21:41:15 IST] read: git [\"--git-dir=/Users/jtang/annex/.git\",\"--work-tree=/Users/jtang/annex\",\"show-ref\",\"git-annex\"] 
+[2012-07-26 21:41:15 IST] read: git [\"--git-dir=/Users/jtang/annex/.git\",\"--work-tree=/Users/jtang/annex\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] 
+[2012-07-26 21:41:15 IST] read: git [\"--git-dir=/Users/jtang/annex/.git\",\"--work-tree=/Users/jtang/annex\",\"log\",\"refs/heads/git-annex..731005d121426a38b206c4544da02cdb3b974974\",\"--oneline\",\"-n1\"] 
+[2012-07-26 21:41:15 IST] read: git [\"--git-dir=/Users/jtang/annex/.git\",\"--work-tree=/Users/jtang/annex\",\"log\",\"refs/heads/git-annex..d36d8d88847decc2320f0be22892ad94a8abe594\",\"--oneline\",\"-n1\"] 
+[2012-07-26 21:41:15 IST] read: git [\"--git-dir=/Users/jtang/annex/.git\",\"--work-tree=/Users/jtang/annex\",\"log\",\"refs/heads/git-annex..57bcddc14d03b61028f7002e2dabcc5181d74f3d\",\"--oneline\",\"-n1\"] 
+[2012-07-26 21:41:15 IST] read: git [\"--git-dir=/Users/jtang/annex/.git\",\"--work-tree=/Users/jtang/annex\",\"log\",\"refs/heads/git-annex..372aceaf49b60ebe31cc3fe2e52ba4fbe99c134f\",\"--oneline\",\"-n1\"] 
+[2012-07-26 21:41:15 IST] chat: git [\"--git-dir=/Users/jtang/annex/.git\",\"--work-tree=/Users/jtang/annex\",\"cat-file\",\"--batch\"] 
+[2012-07-26 21:41:15 IST] read: git [\"config\",\"--null\",\"--list\"] 
+git-annex: failed to start git-annex assistant
+</pre>
+
+it doesn't segfault or anything, it just states that the assistant command failed to start :P
+"""]]
diff --git a/doc/forum/Looking_at_the_webapp_on_OSX/comment_3_6d398a2cceff14a1b774b85ee1725073._comment b/doc/forum/Looking_at_the_webapp_on_OSX/comment_3_6d398a2cceff14a1b774b85ee1725073._comment
new file mode 100644
index 0000000000..a139537def
--- /dev/null
+++ b/doc/forum/Looking_at_the_webapp_on_OSX/comment_3_6d398a2cceff14a1b774b85ee1725073._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.189"
+ subject="comment 3"
+ date="2012-07-26T22:07:25Z"
+ content="""
+I've been improving this code path, so make sure you're current. I just made it wait for longer than the 10 seconds it was waiting before giving up. 
+
+If it still fails, try running `git-annex assistant --debug --foreground`
+in one terminal, wait for it to start up, and then run `git annex webapp` in another.
+If that still fails, check if `.git/annex/webapp.html` exists.
+"""]]
diff --git a/doc/forum/Looking_at_the_webapp_on_OSX/comment_4_5e503787a4b1d3534c5e20da5480b763._comment b/doc/forum/Looking_at_the_webapp_on_OSX/comment_4_5e503787a4b1d3534c5e20da5480b763._comment
new file mode 100644
index 0000000000..fde217e63c
--- /dev/null
+++ b/doc/forum/Looking_at_the_webapp_on_OSX/comment_4_5e503787a4b1d3534c5e20da5480b763._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.189"
+ subject="comment 4"
+ date="2012-07-26T22:08:53Z"
+ content="""
+Oh, wait, you're right, if the assistant process that watch forks off is segfaulting, that error message is about the best we can hope for. You can try the manual startup of the assistant to confirm it's crashing..
+"""]]
diff --git a/doc/forum/Looking_at_the_webapp_on_OSX/comment_5_c735841bc230efc61594ea013fc2902b._comment b/doc/forum/Looking_at_the_webapp_on_OSX/comment_5_c735841bc230efc61594ea013fc2902b._comment
new file mode 100644
index 0000000000..47f7be6033
--- /dev/null
+++ b/doc/forum/Looking_at_the_webapp_on_OSX/comment_5_c735841bc230efc61594ea013fc2902b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 5"
+ date="2012-07-27T15:53:50Z"
+ content="""
+I can confirm that the watch command is crashing when i start it up manually.
+"""]]
diff --git a/doc/forum/Looking_at_the_webapp_on_OSX/comment_6_0e489fbfc89d282e9eb47f1b814ff70c._comment b/doc/forum/Looking_at_the_webapp_on_OSX/comment_6_0e489fbfc89d282e9eb47f1b814ff70c._comment
new file mode 100644
index 0000000000..9014923867
--- /dev/null
+++ b/doc/forum/Looking_at_the_webapp_on_OSX/comment_6_0e489fbfc89d282e9eb47f1b814ff70c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jtang"
+ ip="79.97.135.214"
+ subject="comment 6"
+ date="2012-07-27T18:21:17Z"
+ content="""
+FYI, the webapp starts up and sends me to a web browser with the correct page ;) this is after the other issue of [[Watch command as of commit 6cecc26206c4a539999b04664136c6f785211a41 segfaults]] got fixed.
+"""]]
diff --git a/doc/forum/Lost_git_repository._Recovery_from_S3_remote__63__.mdwn b/doc/forum/Lost_git_repository._Recovery_from_S3_remote__63__.mdwn
new file mode 100644
index 0000000000..6cd392a600
--- /dev/null
+++ b/doc/forum/Lost_git_repository._Recovery_from_S3_remote__63__.mdwn
@@ -0,0 +1,14 @@
+Greetings friends.
+
+In an unfortunate event, I lost my git repository for my annex. 😬
+
+The only thing left is the annex files in an S3 bucket.
+
+Is it possible to recover the repository?
+
+Is it possible to recover the files?
+
+All the files in S3 bucket are in this format:
+GPGHMACSHA1--000b36e47d7ebd51f5ca2b8d294dea2d530c79c8
+
+I'd appreciate any help! 🙏
diff --git a/doc/forum/Lost_git_repository._Recovery_from_S3_remote__63__/comment_1_a9028f00461ec1eddbeb699dadcbab72._comment b/doc/forum/Lost_git_repository._Recovery_from_S3_remote__63__/comment_1_a9028f00461ec1eddbeb699dadcbab72._comment
new file mode 100644
index 0000000000..6dae8e786d
--- /dev/null
+++ b/doc/forum/Lost_git_repository._Recovery_from_S3_remote__63__/comment_1_a9028f00461ec1eddbeb699dadcbab72._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2023-03-20T17:59:11Z"
+ content="""
+Not a chance. git-annex uses symetric encryption, storing the key in the git-annex branch. See [[design/encryption/]].
+
+Are you sure you don't have other clones of the repo?
+
+How exactly did you loose the repo? Maybe its possible to recover it?
+"""]]
diff --git a/doc/forum/Lost_git_repository._Recovery_from_S3_remote__63__/comment_2_0dbf6fcd15007ba66323ecf2b154ad2e._comment b/doc/forum/Lost_git_repository._Recovery_from_S3_remote__63__/comment_2_0dbf6fcd15007ba66323ecf2b154ad2e._comment
new file mode 100644
index 0000000000..9c14f9185b
--- /dev/null
+++ b/doc/forum/Lost_git_repository._Recovery_from_S3_remote__63__/comment_2_0dbf6fcd15007ba66323ecf2b154ad2e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-03-21T17:54:02Z"
+ content="""
+@Lukey is probably right. The one exception would be if the
+S3 remote was set up with encryption=pubkey. Then the files
+stored in the bucket would be simply encrypted to your gpg public key, and
+could be decrypted without needing any other information that you've lost.
+
+(The filenames would still not be able to be recovered.)
+"""]]
diff --git a/doc/forum/Lots_of_4k_symlinks.mdwn b/doc/forum/Lots_of_4k_symlinks.mdwn
new file mode 100644
index 0000000000..7f90f874db
--- /dev/null
+++ b/doc/forum/Lots_of_4k_symlinks.mdwn
@@ -0,0 +1,24 @@
+Hi, 
+
+this is a minor issue and probably there is no better solution, but nevertheless I would like to point it out and maybe discuss a little about the issue.
+
+Given that the symlinks generated by annex are pretty large in size (they point to a file named by a large hash number), ext4 is using an entire block (4K) of storage instead of [embedding the symlink into the inode][inode] itself. For the "archivist use case" of annex, this might lead to tens or hundreds of MBs of disk occupied by symlinks which actually don't add up to more than a few MBs.
+
+Here is a real world example:
+
+```
+(ins)carlos@carlos home$ du -hs music/
+56M	music/
+(ins)carlos@carlos home$ du -bhs music/
+3.3M	music/
+(ins)carlos@carlos home$ ln -s /tmp/x x
+(ins)carlos@carlos home$ du x
+0	x
+(ins)carlos@carlos home$ ln -s /tmp/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx
+(ins)carlos@carlos home$ du xx
+4	xx
+```
+
+Cheers, Carlos
+
+[inode]: https://kernelnewbies.org/Linux_3.8#head-372b38979138cf2006bd0114ae97f889f67ef46a
diff --git a/doc/forum/Lots_of_4k_symlinks/comment_1_96384eaeef1d067a24678c7aa3613063._comment b/doc/forum/Lots_of_4k_symlinks/comment_1_96384eaeef1d067a24678c7aa3613063._comment
new file mode 100644
index 0000000000..10a9bbdc23
--- /dev/null
+++ b/doc/forum/Lots_of_4k_symlinks/comment_1_96384eaeef1d067a24678c7aa3613063._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2017-04-24T13:55:02Z"
+ content="""
+> For the \"archivist use case\" of annex, this might lead to tens or hundreds of MBs of disk occupied by symlinks which actually don't add up to more than a few MBs.
+
+    $ pwd
+    /home/sorting_annex/mnt/keyfile
+    $ du -shc *-*
+    ...
+    33M     fd0dc9d3-ad62-429e-ba1b-acc26a453ca4
+    33M     fd2fc989-bea7-4ffb-bbc8-2e34cd0e5be5
+    33M     fd79bbd4-d41e-4ea8-acc8-86437c5eed7c
+    33M     ffbd042e-f6d9-4450-9a57-8ed1086f587c
+    2.7G    total
+    $
+
+Just a bit :P (yes, that is 2.7G of symlinks *so far*)
+"""]]
diff --git a/doc/forum/Lots_of_4k_symlinks/comment_2_be9617e8cbc231069c44bc9f077ce673._comment b/doc/forum/Lots_of_4k_symlinks/comment_2_be9617e8cbc231069c44bc9f077ce673._comment
new file mode 100644
index 0000000000..1b2d91eed1
--- /dev/null
+++ b/doc/forum/Lots_of_4k_symlinks/comment_2_be9617e8cbc231069c44bc9f077ce673._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-05-09T21:07:11Z"
+ content="""
+You also get better seek speed with packed inodes.
+
+With default 256 byte inodes, there seems to be 59 bytes to play with.
+(Determined experimentally.) 
+
+Note that disks over 4 tb default to 32 kilobyte inodes, so probably most
+spinning hard disks these days *do* pack regular git-annex symlinks
+efficiently. (I don't have a 4 tb disk online to check this.. And I doubt
+CandyAngel was counting only the sizes of symlinks and not git repos
+or at least directory inodes to hold all the symlinks.)
+
+With a prefix like ".git/annex/objects/zX/Wx/S-s1000000000-"
+that leaves 20 bytes out of the 59 for the hash.
+
+That's not enough data to be cryptographically secure, but if
+we use SHA1 or MD5 as the base hash, it wouldn't be anyway. 15 bytes
+of hash state will base64 encode to 20 bytes. SHA1 is a 20 byte hash;
+MD5 is a 16 byte hash. So even MD5 would need to be truncated a little bit.
+Chances of (non-malicious) collision would still be small, only 256
+times as likely as a (non-malicious) MD5 collision. It could easily be made
+harder than MD5/SHA1 to maliciously collide by using truncated SHA2.
+
+(Files larger than 9.3 gb would still have too long symlinks due to the size
+field. The size field could also be omitted or encoded more efficiently,
+but omitting it would reduce git-annex's ability to not overfill disk
+and I don't think re-encoding buys enough to bother.)
+"""]]
diff --git a/doc/forum/Lots_of_4k_symlinks/comment_3_80b3a84e6d79871bbbef13d4bc87cc37._comment b/doc/forum/Lots_of_4k_symlinks/comment_3_80b3a84e6d79871bbbef13d4bc87cc37._comment
new file mode 100644
index 0000000000..d350dc2f5a
--- /dev/null
+++ b/doc/forum/Lots_of_4k_symlinks/comment_3_80b3a84e6d79871bbbef13d4bc87cc37._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-05-09T22:49:01Z"
+ content="""
+My analysis above assumes no subdirectories.
+
+To leave space for even a single "../" would need to drop to 13 bytes
+of hash state. 1/79228162514264337593543950336 chance of 2 files colliding.
+Not comfortable with something so worse than md5, and that still doesn't help
+when files are 2 directories deep. Droping to 11 bytes for that,
+1/1208925819614629174706176 chance is starting to get into could really
+happen territory.
+"""]]
diff --git a/doc/forum/Lots_of_4k_symlinks/comment_4_be12d26936b3502445e880be997b8877._comment b/doc/forum/Lots_of_4k_symlinks/comment_4_be12d26936b3502445e880be997b8877._comment
new file mode 100644
index 0000000000..8737c0c1b4
--- /dev/null
+++ b/doc/forum/Lots_of_4k_symlinks/comment_4_be12d26936b3502445e880be997b8877._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 4"
+ date="2017-05-10T09:21:34Z"
+ content="""
+> And I doubt CandyAngel was counting only the sizes of symlinks and not git repos or at least directory inodes to hold all the symlinks.)
+
+In that repository, it is only top level directories (no sub directories) and each directory in it only has symlinks (up to 8000 of them). Directories are **mkdir $(uuidgen -r)**, hence the wildcard for du.
+
+It would be including the directory size to hold all the inodes, but it definitely *isn't counting .git* as this annex spans 3 drives with 6TB of content so far. Well, 6 drives because of \"numcopies 2\" :P
+
+I will calculate this a different way and only count symlinks, when I have access to it again.
+"""]]
diff --git a/doc/forum/Lots_of_4k_symlinks/comment_5_ab3884748f3271a77ba3320f25d74414._comment b/doc/forum/Lots_of_4k_symlinks/comment_5_ab3884748f3271a77ba3320f25d74414._comment
new file mode 100644
index 0000000000..c1f4289755
--- /dev/null
+++ b/doc/forum/Lots_of_4k_symlinks/comment_5_ab3884748f3271a77ba3320f25d74414._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 5"
+ date="2017-05-10T12:44:08Z"
+ content="""
+    $ find -name .git -prune -o -type l | wc -l
+    1034886
+
+Just over a million symlinks.. very convenient :)
+
+    $ find -name .git -prune -o -type l -printf '%s\n' | awk '{sum+=$1} END {print sum/1024**3}'
+    195.9 # 195MB actual size
+    $ find -name .git -prune -o -type l -print0 | du -ch --files0-from=- | tail -n1
+    4.0G    total # 4GB disk usage
+
+And in comparison to my earlier comment 2 weeks ago:
+
+    $ du -shc *-* | tail -n3
+    33M     fd79bbd4-d41e-4ea8-acc8-86437c5eed7c
+    33M     ffbd042e-f6d9-4450-9a57-8ed1086f587c
+    4.1G    total
+
+So directory inode sizes are dwarfed by the 4K disk usage but ~198b actual usage of the symlinks (~96% wasted space?).
+"""]]
diff --git a/doc/forum/Lots_of_4k_symlinks/comment_6_fa72056ee788ac0f2c15bb57d9876cf6._comment b/doc/forum/Lots_of_4k_symlinks/comment_6_fa72056ee788ac0f2c15bb57d9876cf6._comment
new file mode 100644
index 0000000000..6e4c89631d
--- /dev/null
+++ b/doc/forum/Lots_of_4k_symlinks/comment_6_fa72056ee788ac0f2c15bb57d9876cf6._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 6"
+ date="2017-05-10T12:45:59Z"
+ content="""
+Oops,
+
+    find -name .git -prune -o -type l -printf '%s\n' | awk '{sum+=$1} END {print sum/1024**3}'
+
+should have been
+
+    find -name .git -prune -o -type l -printf '%s\n' | awk '{sum+=$1} END {print sum/1024**2}'
+
+That'll teach me to prematurely copy it :P
+"""]]
diff --git a/doc/forum/Lots_of_4k_symlinks/comment_7_bd6b81815e5888c26d7a8a96e565519e._comment b/doc/forum/Lots_of_4k_symlinks/comment_7_bd6b81815e5888c26d7a8a96e565519e._comment
new file mode 100644
index 0000000000..148778f02b
--- /dev/null
+++ b/doc/forum/Lots_of_4k_symlinks/comment_7_bd6b81815e5888c26d7a8a96e565519e._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2017-05-11T15:57:10Z"
+ content="""
+Note that the analysis in my earlier comment assumes that the
+.git/annex/objects/xx/yy/key/ directory is removed. As long as those
+per-key directories are used, the symlinks cannot possibly be made short enough
+to pack.
+
+There have been some
+other requests for that (datalad requested it because all those per-key
+directories use disk space, add to the size of the git repo, and slow down
+traversal). However, git-annex relies on those directories to prevent
+accidential rm -rf deleting the annexed objects and prevent some symlink
+following programs from editing/corrupting the annexed objects (the
+per-key directories are left mode 400 most of the time). So it would be
+fairly complicated to add a tuning that eliminated those while locking
+down the permissions some other way (eg, making the `yy` directories mode
+400 except when one or more thread/process needs to write to them), and since
+it would have to be a tuning, it would introduce a lot of conditional
+complexity into the code.
+"""]]
diff --git a/doc/forum/Lyve_Home.mdwn b/doc/forum/Lyve_Home.mdwn
new file mode 100644
index 0000000000..b9e0917695
--- /dev/null
+++ b/doc/forum/Lyve_Home.mdwn
@@ -0,0 +1,6 @@
+Lyve Home is an interesting device to store personal photos and videos. It is a 2TB hard drive that stores all your photos. It tries to replicate the files on every device you connect (computer, phone, etc.) and keeps at least two copies of each photo. The photos are not stored in the cloud, Lyve only stores metadata in the cloud.
+
+http://www.youtube.com/watch?v=sOE5uWqS6YQ
+
+This is something that could be easily made with git-annex and a small computer, like a Raspberry Pi, and a hard drive. 
+
diff --git a/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__.mdwn b/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__.mdwn
new file mode 100644
index 0000000000..9927743d42
--- /dev/null
+++ b/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__.mdwn
@@ -0,0 +1,5 @@
+I set the backend to MD5E with git config, but when I try to import files I get this error:
+
+    git-annex: unknown backend MD5E
+
+MD5 doesn't work either. Have these been removed as backend options? They are listed [here](http://git-annex.branchable.com/backends/).
diff --git a/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_1_e21fa57a2f2dc4e99737877c6a48cbfe._comment b/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_1_e21fa57a2f2dc4e99737877c6a48cbfe._comment
new file mode 100644
index 0000000000..549b1153d0
--- /dev/null
+++ b/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_1_e21fa57a2f2dc4e99737877c6a48cbfe._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-15T15:59:10Z"
+ content="""
+These have not been removed.
+
+Since they were first added in git-annex version 5.20150205,
+the most likely reason for your problem is if you're using an older version
+of git-annex than that. `git annex version` will tell you.
+"""]]
diff --git a/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_2_5025d16f59f314711e49537e542b7c83._comment b/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_2_5025d16f59f314711e49537e542b7c83._comment
new file mode 100644
index 0000000000..0756c3f3ae
--- /dev/null
+++ b/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_2_5025d16f59f314711e49537e542b7c83._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="ghen1"
+ subject="comment 2"
+ date="2015-07-17T09:52:02Z"
+ content="""
+Yes, I am using an older version. Thank you for the help.
+"""]]
diff --git a/doc/forum/Make_GA_aware_of_externally-made_copies.mdwn b/doc/forum/Make_GA_aware_of_externally-made_copies.mdwn
new file mode 100644
index 0000000000..761a1ba7c1
--- /dev/null
+++ b/doc/forum/Make_GA_aware_of_externally-made_copies.mdwn
@@ -0,0 +1,15 @@
+I use a backup service which mirrors the contents of directories to The Cloud^(TM). One of the dirs I make it mirror is a directory special remote with encryption and chunking which I move data into.  
+Now I would like to make GA aware of the second copy that the mirroring service creates of that special remote.
+
+I use BTRFS as the underlying FS, so my idea is it to store the special remote inside a subvolume and then snapshot it before sending it off to mirror. (The same could probably be done with hardlinks as special remotes are read- and unlink-only.) This way I've got a local directory which represents the state of the remote mirror once the service's tool is done uploading it.
+
+My idea was to then let GA know about it in the form of a second directory special remote to give me the correct numcopies count.
+
+The problem I have run into here is that there does not seem to be a way to get GA to "import" pre-existing state of a directory special remote. I just can't get it to recognise the existance of the keys inside it.
+
+I could probably hack up an something that could query the mirrored keys directly and maybe make a special remote out of that but the same problem would apply here as it's still a special remote that changes outside of GA's control.
+
+Is there a way of doing what I want that I may have overlooked? Is there a better way of making GA aware of this external copy perhaps?
+
+Thanks,
+- Atemu
diff --git a/doc/forum/Make_GA_aware_of_externally-made_copies/comment_1_0e2edea494810a8614f628ec46b934e4._comment b/doc/forum/Make_GA_aware_of_externally-made_copies/comment_1_0e2edea494810a8614f628ec46b934e4._comment
new file mode 100644
index 0000000000..778e02856d
--- /dev/null
+++ b/doc/forum/Make_GA_aware_of_externally-made_copies/comment_1_0e2edea494810a8614f628ec46b934e4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-05-02T18:36:56Z"
+ content="""
+Hi,
+I tested it with `encryption=shared` and it works, but not with chunking. When creating the 2nd remote, you have to look up the cipher of the first one with `git cat-file blob git-annex:remote.log` and pass it to initremote with `cipher=`. Finally, after externally copying everything from the 1st remote to the 2nd remote, you have to run `git annex fsck --fast --all --from=remote2` to make git-annex aware of the copies.
+"""]]
diff --git a/doc/forum/Make_GA_aware_of_externally-made_copies/comment_2_b7fcfd87efb17d5159ec49eb218fbd8e._comment b/doc/forum/Make_GA_aware_of_externally-made_copies/comment_2_b7fcfd87efb17d5159ec49eb218fbd8e._comment
new file mode 100644
index 0000000000..665cc13c26
--- /dev/null
+++ b/doc/forum/Make_GA_aware_of_externally-made_copies/comment_2_b7fcfd87efb17d5159ec49eb218fbd8e._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-05-04T13:54:45Z"
+ content="""
+I think it should be possible to get this to work with chunking, if you
+have git-annex version 8.20201103 or newer, and if you configure the second
+special remote with the same chunk size.
+
+git-annex records state about a special remote's chunks, and that state is
+not available for the second special remote. Which used to prevent accessing
+chunks when the information is not available, but that version made it fall
+back to trying chunks of the configured chunk size.
+
+See the bug report that resulted in that change for details:
+[[bugs/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks]]
+
+Oh also this only works with keys that have a recorded size. Which is most
+of them, but git-annex addurl --fast adds keys without a recorded size.
+
+---
+
+An alternative you might consider is to use the --sameas flag to initremote
+when setting up the second remote. Then git-annex would consider the two
+remotes as one repository, which means it only considers them to be one
+copy, but also it can retrieve content from either.
+
+If git-annex only had a way to treat a repository a more than 1 copy, that
+would do just what you want. I do think there might be the possibility to
+add such a feature, but it would need some thought.
+[[todo/repositories_that_count_as_more_than_one_copy]]
+"""]]
diff --git a/doc/forum/Make_GA_aware_of_externally-made_copies/comment_3_c1d69396c7bb208b6f82f2f65a282cfb._comment b/doc/forum/Make_GA_aware_of_externally-made_copies/comment_3_c1d69396c7bb208b6f82f2f65a282cfb._comment
new file mode 100644
index 0000000000..369552eaea
--- /dev/null
+++ b/doc/forum/Make_GA_aware_of_externally-made_copies/comment_3_c1d69396c7bb208b6f82f2f65a282cfb._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 3"
+ date="2021-05-04T17:19:57Z"
+ content="""
+I used the exact same settings for the second special remote as the first one: `type=directory chunk=50MiB encryption=hybrid mac=HMACSHA256`.
+
+GA was 8.20200810 though because my server machine is built from the stable Nixpkgs channel; I will test that again with the most recent version tomorrow.
+
+`--sameas` won't help here; the special remotes are accessible via the same FS (the second is just a btrfs snapshot of the first) and they'd still only count as one copy. That's the same situation I have right now.
+
+Counting it as two copies would work but there is a large delay between having moved the files to the special remote and them actually being mirrored (residential internet upload) which means the numcopies of somewhat newly added files wouldn't be correct. It'd be a step up though.
+"""]]
diff --git a/doc/forum/Make_GA_aware_of_externally-made_copies/comment_4_b0d7ef111f4862d6b759cde45696a676._comment b/doc/forum/Make_GA_aware_of_externally-made_copies/comment_4_b0d7ef111f4862d6b759cde45696a676._comment
new file mode 100644
index 0000000000..478bcf6f09
--- /dev/null
+++ b/doc/forum/Make_GA_aware_of_externally-made_copies/comment_4_b0d7ef111f4862d6b759cde45696a676._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 4"
+ date="2021-05-05T07:33:07Z"
+ content="""
+It worked! Thank you so much you two!
+
+The cipher was indeed different for some reason, what could cause that?
+"""]]
diff --git a/doc/forum/Make_whereis_output_more_compact.mdwn b/doc/forum/Make_whereis_output_more_compact.mdwn
new file mode 100644
index 0000000000..5503e716f3
--- /dev/null
+++ b/doc/forum/Make_whereis_output_more_compact.mdwn
@@ -0,0 +1,13 @@
+Hi there,
+
+first of all, great job done on annex! I think I finally found what I was looking for to organize all my data.
+
+My question: when I do git annex whereis Music, I get a detailed list of every single song and its remote locations. I have tens of thousands of songs, so just typing git annex whereis Music gives me way too much information. 
+Here is my proposition: in my case, every file of the Music folder resides in the same remote. So, wouldn't it be better to show just one line of output telling me that Music is on remote bla and blub, and then I know that all files in Music are in remotes bla and blub?
+
+Is that possible now already or would that be a feature request? What do you think?
+
+Cheers,
+Moritz.
+
+PS: I know that I can specify filters, e.g. git annex whereis --in bla --and --not --in blub. That is great!
diff --git a/doc/forum/Making_Firefox_not_dereference_symlinks_on_open.mdwn b/doc/forum/Making_Firefox_not_dereference_symlinks_on_open.mdwn
new file mode 100644
index 0000000000..5680cbd026
--- /dev/null
+++ b/doc/forum/Making_Firefox_not_dereference_symlinks_on_open.mdwn
@@ -0,0 +1,3 @@
+Firefox has the nasty habit that it will force-dereference symlinks when locally opening files (i. e., opening an annexed document will cause it to be opened in .git/annex/objects/…). Since this will break relative links within HTML files, this would make Firefox pretty useless when working with a git annex containing HTML files. (Apparently this behavior is [desired](https://bugzilla.mozilla.org/show_bug.cgi?id=803999) upstream and might not be fixed.)
+
+Seems I’m not the only one who would like to work with annexed HTML files, though. On the [Debian bugtracker](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691099), another user shared a handy shim which can be used in LD_PRELOAD and which will force Firefox to open symlinks in-place. Thought I’d share this here in case it’s of use to anyone.
diff --git a/doc/forum/Making_Firefox_not_dereference_symlinks_on_open/comment_1_a7b092f2291fa515279cf7dce23df20d._comment b/doc/forum/Making_Firefox_not_dereference_symlinks_on_open/comment_1_a7b092f2291fa515279cf7dce23df20d._comment
new file mode 100644
index 0000000000..b4addb92dc
--- /dev/null
+++ b/doc/forum/Making_Firefox_not_dereference_symlinks_on_open/comment_1_a7b092f2291fa515279cf7dce23df20d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 1"
+ date="2014-07-31T11:43:16Z"
+ content="""
+Sorry, it escaped my attention there’s a dedicated tips forum. Maybe this should be moved there.
+"""]]
diff --git a/doc/forum/Making_a_git-annexy_symlink___34__known__34____63__.mdwn b/doc/forum/Making_a_git-annexy_symlink___34__known__34____63__.mdwn
new file mode 100644
index 0000000000..8d298ae830
--- /dev/null
+++ b/doc/forum/Making_a_git-annexy_symlink___34__known__34____63__.mdwn
@@ -0,0 +1,7 @@
+Currently, if you git-add a symlink copied from another git-annex, git-annex will 'fix' it so it points to where the files would be in its new annex object store, but doesn't create the corresponding file for the key on the git-annex branch, so git-annex doesn't actually "know" about the file.
+
+This means running *git annex reinject --known* won't reinject the content for the symlink (e.g. "Not known content; skipping").
+
+I tried running git-annex-fsck hoping it would create the file (with the information that 0 copies exist) but it doesn't do that..?
+
+Any advice on how to go about resolving this? Preferably a "lightweight" way as this repository has a lot of such transplanted symlinks.. :)
diff --git a/doc/forum/Making_a_git-annexy_symlink___34__known__34____63__/comment_1_e04edbe950a41887c4c11a226ca77dce._comment b/doc/forum/Making_a_git-annexy_symlink___34__known__34____63__/comment_1_e04edbe950a41887c4c11a226ca77dce._comment
new file mode 100644
index 0000000000..ad898c5e89
--- /dev/null
+++ b/doc/forum/Making_a_git-annexy_symlink___34__known__34____63__/comment_1_e04edbe950a41887c4c11a226ca77dce._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-10T17:04:20Z"
+ content="""
+fsck sees that the (lack of) location
+log accurately states that the content is not present, and so avoids
+writing to the log.
+
+If fsck always wrote to the log when content was not present, running
+fsck in sparse repos would bloat the location logs unncessarily.
+
+But I suppose that it makes sense for fsck to notice that the key
+was not known and write to the log in this particular case.
+I've gone ahead and made that change.
+
+It's not clear to me though, why this workflow of copying over symlinks,
+and adding them and reinjecting is better than just moving over content and
+adding it.
+"""]]
diff --git a/doc/forum/Making_a_git-annexy_symlink___34__known__34____63__/comment_2_de77cc2bee45706c4bbe407d8846778e._comment b/doc/forum/Making_a_git-annexy_symlink___34__known__34____63__/comment_2_de77cc2bee45706c4bbe407d8846778e._comment
new file mode 100644
index 0000000000..1d84df8825
--- /dev/null
+++ b/doc/forum/Making_a_git-annexy_symlink___34__known__34____63__/comment_2_de77cc2bee45706c4bbe407d8846778e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2016-05-10T17:44:38Z"
+ content="""
+It protects against adding in corrupted files without noticing.
+
+If I move the symlink as a real file, the receiving git-annex will rehash it and, if it is corrupted, effectively change the symlink to a corrupt file with no way to tell this has occured.
+
+This method leaves the transplanted symlink broken (and may be fixed by a reinject of a good copy of the file from another drive) and the corrupt content would be left behind by the reinject. This makes it very obvious something has happened.
+
+Thank you for making these changes to support my use case. I really hope it doesn't break anyone else's!
+"""]]
diff --git a/doc/forum/Making_a_public_read-write_git-annex_repo.mdwn b/doc/forum/Making_a_public_read-write_git-annex_repo.mdwn
new file mode 100644
index 0000000000..e7cc7c6639
--- /dev/null
+++ b/doc/forum/Making_a_public_read-write_git-annex_repo.mdwn
@@ -0,0 +1,9 @@
+For [the workshop](https://cfp.tuebix.org/tuebix-2023/talk/THBBK7/) I'll host on Saturday I'm still wondering how to make a quick'n'dirty publicly accessible git-annex repo where all participants can just push and pull and do git annex stuff with.
+
+Options:
+
+- Use one of my servers, make a new user, add all of the participants' ssh keys (works)
+- Make a https/git protocol git server without auth (no annex possible, right?)
+- Use the assistant to set up local pairing and have it do the key setup (should work, though I don't know if it's reliable in that uni WiFi)
+
+Any more ideas?
diff --git a/doc/forum/Making_a_public_read-write_git-annex_repo/comment_1_8279171695a9a7a7501d5ee8c7bab66c._comment b/doc/forum/Making_a_public_read-write_git-annex_repo/comment_1_8279171695a9a7a7501d5ee8c7bab66c._comment
new file mode 100644
index 0000000000..349d094399
--- /dev/null
+++ b/doc/forum/Making_a_public_read-write_git-annex_repo/comment_1_8279171695a9a7a7501d5ee8c7bab66c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2023-06-27T08:54:45Z"
+ content="""
+Maybe a bare git repo on a nfs or smb share? I'm not sure if concurrent pushes work right with that.
+
+It's probably also a good idea to set `git annex config --set annex.dotfiles true`, so no one gets into a situation where they have to resolve a merge conflict manually.
+"""]]
diff --git a/doc/forum/Making_a_public_read-write_git-annex_repo/comment_2_2cd770a12bfe3b44531b024c41570758._comment b/doc/forum/Making_a_public_read-write_git-annex_repo/comment_2_2cd770a12bfe3b44531b024c41570758._comment
new file mode 100644
index 0000000000..c104e370ae
--- /dev/null
+++ b/doc/forum/Making_a_public_read-write_git-annex_repo/comment_2_2cd770a12bfe3b44531b024c41570758._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="alanz"
+ avatar="http://cdn.libravatar.org/avatar/f944654706f02de229470497c3fc25b4"
+ subject="comment 2"
+ date="2023-06-27T10:53:21Z"
+ content="""
+Maybe use a shared SyncThing folder
+"""]]
diff --git a/doc/forum/Making_a_public_read-write_git-annex_repo/comment_3_19694d397813fe1bb949fd3b6ae49f4b._comment b/doc/forum/Making_a_public_read-write_git-annex_repo/comment_3_19694d397813fe1bb949fd3b6ae49f4b._comment
new file mode 100644
index 0000000000..e03291ab8f
--- /dev/null
+++ b/doc/forum/Making_a_public_read-write_git-annex_repo/comment_3_19694d397813fe1bb949fd3b6ae49f4b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Sync-ception"
+ date="2023-06-27T13:51:58Z"
+ content="""
+> Maybe use a shared SyncThing folder 
+
+😂 That kinda defeats the purpose of teaching git-annex, doesn't it?
+"""]]
diff --git a/doc/forum/Making_a_public_read-write_git-annex_repo/comment_4_c8b104eb34efdd7c7670f2133081d1d8._comment b/doc/forum/Making_a_public_read-write_git-annex_repo/comment_4_c8b104eb34efdd7c7670f2133081d1d8._comment
new file mode 100644
index 0000000000..3e01f8b465
--- /dev/null
+++ b/doc/forum/Making_a_public_read-write_git-annex_repo/comment_4_c8b104eb34efdd7c7670f2133081d1d8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-06-28T17:27:21Z"
+ content="""
+You can use https and have an annex in the repo, but it will be read-only.
+
+In a classroom setting, `git-annex multicast` can sometimes be useful.
+You'd still need a publically writable git repository hosted somewhere.
+
+I'd use ssh though, and automate the key enrollment.
+"""]]
diff --git a/doc/forum/Making_a_public_read-write_git-annex_repo/comment_5_48e247fddb0d302102c74cac7f2228ff._comment b/doc/forum/Making_a_public_read-write_git-annex_repo/comment_5_48e247fddb0d302102c74cac7f2228ff._comment
new file mode 100644
index 0000000000..4869f5998a
--- /dev/null
+++ b/doc/forum/Making_a_public_read-write_git-annex_repo/comment_5_48e247fddb0d302102c74cac7f2228ff._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="WiFi without broadcasting"
+ date="2023-06-30T07:56:03Z"
+ content="""
+Turns out, both WiFi networks here disallow broadcasting, so the local pairing of the webapp doesn't work. Just tried it with two laptops, the pairing request is never shown.
+
+So the server solution with SSH keys it is, then!
+"""]]
diff --git a/doc/forum/Making_git-annex_a_self-funded_project__63__.mdwn b/doc/forum/Making_git-annex_a_self-funded_project__63__.mdwn
new file mode 100644
index 0000000000..29eddaa0cb
--- /dev/null
+++ b/doc/forum/Making_git-annex_a_self-funded_project__63__.mdwn
@@ -0,0 +1,10 @@
+With the fundraiser having met its stretch goal of $15,000, I was thinking of how to keep git-annex going beyond another year.  What about selling stuff?  Not just merch (though being able to buy stickers would be neat), but useful things that would complement the software, like selling hardware for a small remote that you could plug into your home network, or even set up at a friend's house to have online, but offsite.
+
+
+Something like a CubieBoard2 and an HDD for annexes preloaded with all the necessary software and a git-annex apt repo for keeping it updated.  Everything would come in a nice little enclosure with a git-annex logo on it; you plug in the power, the ethernet, and boom it's ready to go, with no terminal magic (but it's there if you want it!).  You could create them on-demand without having to keep much of a stock (except maybe the enclosure), so there's practically no risk.
+
+
+
+Aesthetically, I was thinking of something that exposed as little of the insides as possible.  Basically just power, ethernet, and USB ports.
+
+Maybe material for another Kickstarter?
diff --git a/doc/forum/Making_git-annex_a_self-funded_project__63__/comment_1_4a1ba95b7231ba973ddb672d2419e28c._comment b/doc/forum/Making_git-annex_a_self-funded_project__63__/comment_1_4a1ba95b7231ba973ddb672d2419e28c._comment
new file mode 100644
index 0000000000..03ddae4832
--- /dev/null
+++ b/doc/forum/Making_git-annex_a_self-funded_project__63__/comment_1_4a1ba95b7231ba973ddb672d2419e28c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="GLITTAH"
+ ip="94.126.178.1"
+ subject="comment 1"
+ date="2013-07-27T01:56:47Z"
+ content="""
+Other ideas welcome!
+"""]]
diff --git a/doc/forum/Making_git-annex_a_self-funded_project__63__/comment_2_7c476ae92e63c991f229708678874ca2._comment b/doc/forum/Making_git-annex_a_self-funded_project__63__/comment_2_7c476ae92e63c991f229708678874ca2._comment
new file mode 100644
index 0000000000..70e470c85c
--- /dev/null
+++ b/doc/forum/Making_git-annex_a_self-funded_project__63__/comment_2_7c476ae92e63c991f229708678874ca2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 2"
+ date="2013-07-28T00:21:39Z"
+ content="""
+A few people have suggested that idea. I don't know if I want to get into the HW business.
+"""]]
diff --git a/doc/forum/Making_git-annex_less_necessary.mdwn b/doc/forum/Making_git-annex_less_necessary.mdwn
new file mode 100644
index 0000000000..086c051398
--- /dev/null
+++ b/doc/forum/Making_git-annex_less_necessary.mdwn
@@ -0,0 +1,5 @@
+http://git-annex.branchable.com/walkthrough/ says "Git wants to first stage the entire contents of the file in its index. That can be slow for big files (sorta why git-annex exists in the first place)."<br/>
+What is git doing that git-annex isn't, other than copying the file to .git/objects rather than just moving it to .git/annex/objects, prepending it with "blob"+length, and compressing it? If git were changed to store the "blob"+length as part of the object filename rather than as part of the object file content, have a config option to use uncompressed objects for large files (and not try to pack them when creating pack files), and were used on a filesystem such as zfs or btrfs which does COW so the copy would be as fast as a move, then what speed advantage would git-annex still have over git? I realize git-annex has more features than just big file handling, and has the worm backend for even faster handling, but I'm just talking about the case with the default sha backend.<br/>
+Have such changes been proposed for git? It seems that for anybody already familiar with the git codebase, adding the config option for uncompressed objects and moving the storage location for "blob"+length would be easy changes to make, and I see no downside to them. It wouldn't break backwards compatibility because the object filename being hash."blob".length rather than just hash would indicate that the new object format is in use, and a ".raw" filename extension could be used for uncompressed objects (or more sensibly, in the new format, no additional extension for uncompressed, and ".compressed" for compressed).<br/>
+This would also eliminate the need for a git-annex object store separate from the git object store, and the complexities involved with having them separate, and the need for symlinks, and the complexities they cause. I don't think that relying on COW for speed is unreasonable once btrfs becomes the default in major Linux distros (the bsds already have zfs and hammerfs); right now part of what git-annex is doing is just working around the functional deficiency of non-COW filesystems.<br/>
+P.S. I recommend a "plain" option for the page type when submitting comments on your wiki, so I don't have to put HTML line break markup at the end of my lines.
diff --git a/doc/forum/Making_git-annex_less_necessary/comment_1_03faaa3866778d24cd03887b85dc9954._comment b/doc/forum/Making_git-annex_less_necessary/comment_1_03faaa3866778d24cd03887b85dc9954._comment
new file mode 100644
index 0000000000..3396643f66
--- /dev/null
+++ b/doc/forum/Making_git-annex_less_necessary/comment_1_03faaa3866778d24cd03887b85dc9954._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.245"
+ subject="comment 1"
+ date="2012-05-08T18:22:12Z"
+ content="""
+git's code base makes lots of assumptions hardcoding the size of the hash, etc. (grep its source for magic numbers 40 and 42...) I'd like to see git get parameratised hashes. SHA1 insecurity may evenutally push it in that direction. However, when I asked the git developers about this at the Gittogether last year, there were several ideas floated that would avoid parameterisation, and a lot of good thoughts about problems parameterised hashes would cause.
+
+Moving data into git proper would still leave the problems unique to large data of not being able to store it all on every clone. Which means a git-annex like thing is needed to track where the data resides and move it around.
+
+(BTW, in markdown, you separate paragraphs with blank lines. Like in email.)
+"""]]
diff --git a/doc/forum/Making_git-annex_less_necessary/comment_2_2db02a94dffd525885c9d7fc6c5fa464._comment b/doc/forum/Making_git-annex_less_necessary/comment_2_2db02a94dffd525885c9d7fc6c5fa464._comment
new file mode 100644
index 0000000000..4b1dbd271b
--- /dev/null
+++ b/doc/forum/Making_git-annex_less_necessary/comment_2_2db02a94dffd525885c9d7fc6c5fa464._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/IAg3idYGk.joxsJb2WCxl20gig.0.8hS#d5165"
+ nickname="Kelly"
+ subject="comment 2"
+ date="2012-05-10T15:01:15Z"
+ content="""
+I think my comment a couple days ago got caught in the spam filter, so I'm reposting. 
+What were the ideas to avoid parameterisation? What were the problems of parameterisation, other than just the current hardcoded assumptions?
+
+Speaking of hash insecurity, http://static.usenix.org/events/hotos03/tech/full_papers/henson/henson_html/node8.html says compare-by-hash is a bad idea. As I understand, git doesn't have an option of verifying content matches when the hash matches when adding data to the object store (like zfs's \"dedup=verify\" option, which you can use even when using sha256), because the assumption is that the risk of collision (or at least just the risk of accidental collision) is negligible. Would it be worthwhile to add this option to git-annex?
+
+"""]]
diff --git a/doc/forum/Making_git-annex_less_necessary/comment_3_429ec656e0ac02f98843f8d7f3c02d6a._comment b/doc/forum/Making_git-annex_less_necessary/comment_3_429ec656e0ac02f98843f8d7f3c02d6a._comment
new file mode 100644
index 0000000000..41b7570e12
--- /dev/null
+++ b/doc/forum/Making_git-annex_less_necessary/comment_3_429ec656e0ac02f98843f8d7f3c02d6a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/IAg3idYGk.joxsJb2WCxl20gig.0.8hS#d5165"
+ nickname="Kelly"
+ subject="comment 2"
+ date="2012-05-09T01:22:13Z"
+ content="""
+What were the ideas to avoid parameterisation? What were the problems of parameterisation, other than just the current hardcoded assumptions?
+
+Speaking of hash insecurity, http://static.usenix.org/events/hotos03/tech/full_papers/henson/henson_html/node8.html says compare-by-hash is a bad idea. As I understand, git doesn't have an option of verifying content matches when the hash matches when adding data to the object store (like zfs's \"dedup=verify\" option, which you can use even when using sha256), because the assumption is that the risk of collision (or at least just the risk of accidental collision) is negligible. Would it be worthwhile to add this option to git-annex?
+
+"""]]
diff --git a/doc/forum/Making_git-annex_less_necessary/comment_4_384813dd022dfd9c1ef14e0f1479a123._comment b/doc/forum/Making_git-annex_less_necessary/comment_4_384813dd022dfd9c1ef14e0f1479a123._comment
new file mode 100644
index 0000000000..40f0e02b0a
--- /dev/null
+++ b/doc/forum/Making_git-annex_less_necessary/comment_4_384813dd022dfd9c1ef14e0f1479a123._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/"
+ nickname="chrysn"
+ subject="comment 2"
+ date="2012-05-11T17:40:20Z"
+ content="""
+from my layman's standpoint, i think it would be feasible. i've suggested this previously, but not pushed it too much. quoting from [[my user page|users/chrysn]]:
+
+* **would like git-annex to**: not be required any more as git itself learns to use cow filesystems to avoid abundant disk usage and gets better with sparser checkouts (git-annex might then still be a simpler tool that watches over what can be safely dropped for a sparser checkout)
+
+*concerning hash sizes or parameterized hashes*: the problems with hash sizes could be avoided if instead of putting the objects in the \"normal\" object dir, barefiles would be managed in a similar way as packs are. when a new files gets added, they'd be cow-copied to ``.git/objects/bare/${HA}/${SH}``, and ``.git/objects/bareprefix/${HA}/${SH}`` would contain the \"blob ${SIZE}\0\" prefix that gets concatenated to the object body to form the object itself.
+
+(maybe it'd even be sufficient to *just store the size* in the bareprefix, as all those objects would be blobs, but then again, some flexibility won't hurt.)
+
+if the *pack file format* is flexible enough, the bareprefix files can get packed too. for the adventerous user who modifies bigfiles, the pack file mechanisms should be made aware of their presence, and be able to store deltas between them. the operations for applying those deltas would be difficult to optimize, and could be added at a later stage. a typical example could be storing a pdf file -- the pdf file format is designed for appending, so chances are the new version is just the old version plus several k at the end.
+
+neither of that would affect git's *wire protocol*, so no compatibility problems. (it would be advisable to find a reasonable way to do sparse checkouts, though; something like \"server, pack and send your master, but make it sparse and don't include blobs >1mb\").
+"""]]
diff --git a/doc/forum/Making_git-annex_preserve_file_name__44___and_directory.mdwn b/doc/forum/Making_git-annex_preserve_file_name__44___and_directory.mdwn
new file mode 100644
index 0000000000..045a5b66bf
--- /dev/null
+++ b/doc/forum/Making_git-annex_preserve_file_name__44___and_directory.mdwn
@@ -0,0 +1,10 @@
+Hello,
+I have recordings of skype meetings with my teammates, all stored in google-drive. I can link to them just fine, but I thought it might be interesting to have git-annex manage them. 
+
+The problem is that I have to share these recordings with team mates. I therefore can't send them the hashed, and encrypted file. 
+
+For example, if I have a file at `attachments/video.mkv`, I want to be able to store it on google-drive at `annexed-attachments/video.mkv`. I thought that [backends](https://git-annex.branchable.com/backends/) might hold the answer, but I don't think so anymore.
+
+Even a point in the right direction would be appreciated. 
+
+
diff --git a/doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_1_03a5369518a96c0550e68af520ed0060._comment b/doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_1_03a5369518a96c0550e68af520ed0060._comment
new file mode 100644
index 0000000000..a60428d6e6
--- /dev/null
+++ b/doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_1_03a5369518a96c0550e68af520ed0060._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="re: Making git-annex preserve file name, and directory"
+ date="2022-04-20T04:03:46Z"
+ content="""
+See [[`git-annex-export`|git-annex-export]].
+"""]]
diff --git a/doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_2_64863e149cc62a778b006ffe2bf82d06._comment b/doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_2_64863e149cc62a778b006ffe2bf82d06._comment
new file mode 100644
index 0000000000..1e568576b2
--- /dev/null
+++ b/doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_2_64863e149cc62a778b006ffe2bf82d06._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="datamanager"
+ avatar="http://cdn.libravatar.org/avatar/7d4ca7c5e571d4740ef072b83a746c12"
+ subject="re: See git-annex-export. "
+ date="2022-04-20T14:47:59Z"
+ content="""
+Thank you! 
+
+I'm assuming that since [rclone-special remotes aren't explicitly stated to support exporttree](https://git-annex.branchable.com/tips/using_Google_Drive/) that I should use [git-annex-remote-googledrive](https://github.com/Lykos153/git-annex-remote-googledrive) instead, correct? 
+"""]]
diff --git a/doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_3_bbd3ea45cf560031856e9e8416b4d126._comment b/doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_3_bbd3ea45cf560031856e9e8416b4d126._comment
new file mode 100644
index 0000000000..e73f0033e8
--- /dev/null
+++ b/doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_3_bbd3ea45cf560031856e9e8416b4d126._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="datamanager"
+ avatar="http://cdn.libravatar.org/avatar/7d4ca7c5e571d4740ef072b83a746c12"
+ subject="I had to come out of the rabbit hole"
+ date="2022-04-20T15:28:13Z"
+ content="""
+After diving that rabbit hole, I got stuck: it looks like the project's application is not yet verified, and I can't use my own application because google doesn't like it's redirect URI. That's a bummer. 
+"""]]
diff --git a/doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_4_2c36e30b3e2f6874c63e03307207a6b9._comment b/doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_4_2c36e30b3e2f6874c63e03307207a6b9._comment
new file mode 100644
index 0000000000..fc290138c0
--- /dev/null
+++ b/doc/forum/Making_git-annex_preserve_file_name__44___and_directory/comment_4_2c36e30b3e2f6874c63e03307207a6b9._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-05-02T18:35:56Z"
+ content="""
+See this issue:
+<https://github.com/DanielDent/git-annex-remote-rclone/issues/35>
+
+That also has some discussion about git-annex-remote-googledrive 
+seeming to not be allowed by google and how to get around that problem.
+"""]]
diff --git a/doc/forum/Malicious_autoenabled_remotes.mdwn b/doc/forum/Malicious_autoenabled_remotes.mdwn
new file mode 100644
index 0000000000..7e48e5d502
--- /dev/null
+++ b/doc/forum/Malicious_autoenabled_remotes.mdwn
@@ -0,0 +1,9 @@
+I've been trying to figure out whether git-annex can be used to make a user unknowingly download data from a malicious source. The general question here is, assuming a git/git-annex server that I can fully trust to be safe and secure (let's call it `trustedserver`):
+
+*Is it possible, when performing (for example) `git clone git@trustedserver:user/repo && cd repo && git annex init` for annex to set up and enable a remote that is **not** on `trustedserver`?*
+
+I'm trying to imagine a scenario where someone with access to the repository (a person who I share files with) can set up a remote to a different server (e.g., `badremote`), set it to `autoenable=true`, and sync changes. Would this enable the other user to put files on `badremote` that are not on `trustedserver` but are tracked by annex? More importantly, if this happens and I perform a `git clone` → `git annex init` → `git annex sync --content`, would I be downloading files from `badremote` without specifically enabling it?
+
+
+Thanks,
+Achilleas
diff --git a/doc/forum/Malicious_autoenabled_remotes/comment_1_c82464f40eb1442aadd0f1e89b72f41e._comment b/doc/forum/Malicious_autoenabled_remotes/comment_1_c82464f40eb1442aadd0f1e89b72f41e._comment
new file mode 100644
index 0000000000..0a1d230ed8
--- /dev/null
+++ b/doc/forum/Malicious_autoenabled_remotes/comment_1_c82464f40eb1442aadd0f1e89b72f41e._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-05-09T20:45:17Z"
+ content="""
+`git-annex init` will try to auto-enable special remotes that have
+been configured with autoenable=true.
+
+So if someone can push to the repository on trustedserver, they can
+set up such a special remote and cause your later clones of it to enable
+the special remote. Sync will then push content to their special remote.
+They could also check in additional annexed file to the git repository,
+and put their contents on their special remote, and sync would then
+download the contents from there.
+
+Of course, someone who can do this has to have write access to the
+git repository on trustedserver, and if they can write to the git repository,
+they can also send annexed file to there, unless you've prevented that
+somehow.
+
+I had not really considered the autoenable=true as a potential security
+problem, so it's good to think about it that way. I don't know if we have a
+real security problem here though. It seems to rely on the attacker
+having write access to the trustedserver so far.
+
+I suppose the attacker could instead convince you to pull from a clone that
+they control, and after you've pulled once, clones made from your
+repository (or trustedserver after you push to there) will then autoenable
+their special remote unexpectedly. Perhaps the goal then is to get git
+annex sync to unexpectedly send file contents there, so they can collect
+all your annexed files. Pulling from their repository once thus turns into
+sending them all your annexed files going forward.
+
+So I am starting to see this as a security problem.. 
+
+Note that pulling from someone untrusted can also change other settings in
+the git-annex branch (since it's automatically merged), which can probably
+screw up the repository fairly well in other ways, like setting numcopies
+to 0 and messing with preferred content expressions such that git-annex
+wants to drop all files, or copy files to repositories where you don't want
+them to go, etc.
+"""]]
diff --git a/doc/forum/Malicious_autoenabled_remotes/comment_2_37456c0a159453fa984c5a003578d1eb._comment b/doc/forum/Malicious_autoenabled_remotes/comment_2_37456c0a159453fa984c5a003578d1eb._comment
new file mode 100644
index 0000000000..6de3506f86
--- /dev/null
+++ b/doc/forum/Malicious_autoenabled_remotes/comment_2_37456c0a159453fa984c5a003578d1eb._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="achilleas.k@14be77d42a1252fab5ec9dbf4e5ea03c5833e8c8"
+ nickname="achilleas.k"
+ avatar="http://cdn.libravatar.org/avatar/ed6c67c4d8e6c6850930e16eaf85a771"
+ subject="comment 2"
+ date="2017-05-22T14:40:21Z"
+ content="""
+Hey, thanks for the feedback and your thoughts. Should have gotten back to you sooner on this.
+
+I wanted to share with you my thoughts about getting around this issue, from the point of view of the `trustedserver` administrator, and get your input on this.
+
+I want to run a server that uses git and git annex for data storage. I want users of this server to feel safe that when they clone a repository and sync content, they're not pulling things from an untrusted server. I was thinking of modifying annex configurations serverside, perhaps as a *post-receive* hook. The idea would be to go through the remotes on the serveride, bare git repository, and mark all unknown (ssh, rsync, etc) remotes as a `dead`.
+
+Would this cause any issues for the receiver or the sender? Other than potentially making files for the receiver unavailable (which is what I want), would it possibly put the repository in a state where the original sender can't push more changes, because of a disagreement between configurations?
+
+I've played around with the idea a bit and I think the idea is pretty safe, but I might be missing something.
+
+Thanks!
+
+Achilleas
+"""]]
diff --git a/doc/forum/Malicious_autoenabled_remotes/comment_3_608213f5d0df482b731ae1502cdd87af._comment b/doc/forum/Malicious_autoenabled_remotes/comment_3_608213f5d0df482b731ae1502cdd87af._comment
new file mode 100644
index 0000000000..702be5fbb4
--- /dev/null
+++ b/doc/forum/Malicious_autoenabled_remotes/comment_3_608213f5d0df482b731ae1502cdd87af._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-05-24T17:27:20Z"
+ content="""
+The server can certainly do filtering or blocking of changes to the
+git-annex branch to prevent this kind of abuse.
+
+Marking a repository as dead will indeed prevent it from being
+auto-enabled. It will not cause later synchronisation problems. It seems
+like a perhaps too big hammer though. Cloning from such a server, and then
+pushing back to it would make your clone be marked as dead on the next
+pull!
+
+And marking dead doesn't prevent malicious changes to preferred
+content settings etc.
+
+Filtering in the `pre-receive` hook should be very doable. See
+[[internals]] for the git-annex branch documentation.
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__.mdwn b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__.mdwn
new file mode 100644
index 0000000000..acd9066ec8
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__.mdwn
@@ -0,0 +1,118 @@
+I have come up with a moderately complex solution to a particular use case that I have and am posting it here in case it is useful to someone else, and to get suggestions on how to improve it.
+
+#The problem:
+
+I have a large number of files that are accessed infrequently and stored off-line on DVD-Rs.  I need to keep track of which files are on which disc so that when I want a file I can find it.
+
+#The solution:
+
+I currently keep a text file to track which files are on which discs.  I would like to organize all the files in a proper filesystem using git annex, allowing me better organization and the ability to keep some smaller related files online near the annexed large files.
+
+#Requirements:
+
+1) Easily locate the DVD-R containing any specific offline file
+
+This is easily taken care of with git annex whereis
+
+2) Automatically de-duplicate stored files with the same contents
+
+This is taken care of with one of the hash backends (E.G. SHA256)
+
+3) The DVD-Rs still need to be usable without git or git-annex (E.G. The stored files should retain their normal human readable names)
+
+This requirement rules out dir and rsync special remotes, they store the files named according to their hash.  I have settled on making each disc a separate repo which will satisfy this requirement.
+
+
+#Future goals:
+
+4) Easily incorporate the current DVD-Rs into the new system
+
+I haven't found a way to fulfill this goal yet.  I have some convoluted ideas, but nothing so easy as mount disc, run git annex command.
+
+
+#The solution in detail
+Suppose you have the following tree:
+
+<pre>
+~/mainrepo/thing1/file1.bin
+~/mainrepo/thing1/description1.txt
+~/mainrepo/thing2/file2.bin
+~/mainrepo/thing2/description2.txt
+</pre>
+
+You want to store thing1 on disc1 and thing2 on disc2, but you'd like to keep the descriptions online because they are small and useful for figuring out which thing you want later.
+
+1) Create the main repo and annex the files:
+
+<pre>
+cd ~/mainrepo
+git init
+git annex init mainrepo
+git annex add .
+git commit -m 'added files'
+</pre>
+
+2) Create two new unrelated repos and populate them with their respective data and annex:
+
+<pre>
+cd /tmp
+mkdir disc1repo disc2repo
+cd disc1repo
+cp ~/mainrepo/thing1/* .
+git init
+git annex init disc1
+git annex add .
+git commit -m 'added files'
+cd ../disc2repo
+cp ~/mainrepo/thing2/* .
+git init
+git annex init disc2
+git annex add .
+git commit -m 'added files'
+</pre>
+
+3) This is optional, but after annexing the files in these new repos, I replace the symlinks pointing into to the .git/annex/objects/ directory with hard links.  This makes the DVD-Rs usable from operating systems that can't deal with symlinks.  (mkisofs handles hard links correctly)
+
+<pre>
+cd /tmp
+find disc1repo/ disc2repo/ -type l -execdir sh -c "mv -iv {} {}.symlink && ln -L {}.symlink {} && rm {}.symlink" \;
+</pre>
+
+4) Burn these repos onto DVD-Rs:
+
+<pre>
+cd /tmp
+#make isos
+mkisofs -volid disc1 -rational-rock -joliet -joliet-long -udf -full-iso9660-filenames -iso-level 3 -o disc1.iso disc1repo/
+mkisofs -volid disc2 -rational-rock -joliet -joliet-long -udf -full-iso9660-filenames -iso-level 3 -o disc2.iso disc2repo/
+#burn the isos (untested command)
+cdrecord -v -dao disc1.iso
+cdrecord -v -dao disc2.iso
+</pre>
+
+5) Mount the DVD-Rs and add as a remote and fetch, then drop from the mainrepo:
+
+<pre>
+cd ~/mainrepo
+#disc1
+mount /mnt/cdrom
+git remote add disc1 /mnt/cdrom
+git fetch disc1
+git annex drop thing1/thing1.bin
+umount /mnt/cdrom
+#disc2
+mount /mnt/cdrom
+git remote add disc2 /mnt/cdrom
+git fetch disc2
+git annex drop thing2/thing2.bin
+umount /mnt/cdrom
+</pre>
+
+6) Enjoy!  You can now find out what disc things are on simply using git annex whereis, and you can git annex get them or simply use them directly from the disc.
+
+
+I'd appreciate any comments and helpful suggestions.  Especially how to simplify the process or easily integrate all the things I already have stored on discs.
+
+Maybe it would be possible to create a special remote using the hooks for the DVD-Rs.
+
+Even though it is a bit tedious and complicated, the current process could be automated using a script.
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_10_a061d300b718ad943c940e122cc57220._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_10_a061d300b718ad943c940e122cc57220._comment
new file mode 100644
index 0000000000..488e9aa7bf
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_10_a061d300b718ad943c940e122cc57220._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="Web remote works"
+ date="2012-11-25T22:30:46Z"
+ content="""
+Thanks for the suggestion Joey, I found a way to make the web remotes work for adding the files from existing discs.  I wound up adding a symlink farm to the repo with a link for each disk pointing at the mount point.  This way when I try to retrieve a file, I see the URL which contains the name of the disc:
+
+    $ git annex get bigfile.bin
+    get bigfile.bin (from web...) 
+    curl: (37) Couldn't open file /var/tmp/repo/storage/dvd13/bigfile.bin
+    
+      Unable to access these remotes: web
+    
+      Try making some of these repositories available:
+            00000000-0000-0000-0000-000000000001 -- web
+    failed
+    git-annex: get: 1 failed
+
+It took me a while as the version of git-annex in portage was rather old and I just didn't get around to updating git-annex on Gentoo for while.  If anybody wants to get git-annex 3.20121112 running under Gentoo I detailed the process I used at <http://git-annex.mysteryvortex.com>
+
+Now I'll have to try out the assistant!  (Though I didn't get the webapp to compile due to a shakespeare-js error)
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_11_76529080054407570611b4357ce4f3ed._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_11_76529080054407570611b4357ce4f3ed._comment
new file mode 100644
index 0000000000..8823ecf416
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_11_76529080054407570611b4357ce4f3ed._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="Bad ebuilds"
+ date="2012-12-01T02:45:37Z"
+ content="""
+Just an update for anybody that used the ebuilds I created from the link above.  They did not create the git-annex-shell symlink which can cause git-annex to start ignoring your remotes.  More details and fixed ebuilds are now on the page.
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_12_9acf5ce41a023f3848a51891cceeb51b._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_12_9acf5ce41a023f3848a51891cceeb51b._comment
new file mode 100644
index 0000000000..aa742361da
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_12_9acf5ce41a023f3848a51891cceeb51b._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~arand"
+ nickname="arand"
+ subject="comment 12"
+ date="2013-03-11T10:34:42Z"
+ content="""
+Without having read this, I've reported a very similar wishlist item at:
+[http://git-annex.branchable.com/todo/wishlist:_recursive_directory_remote_setup__47__addurl](http://git-annex.branchable.com/todo/wishlist:_recursive_directory_remote_setup__47__addurl)
+
+combining a recursive addurl (in my case using --fast) script with the suggestions regarding symlinks here, it's somewhat workable:
+
+    ln -s /media/cdrom /var/tmp/mycdrom123
+    ~/utv/scripts/annex-importdir /var/tmp/mycdrom123
+
+Ideally though, for optical media it would have a couple of more features (some already noted above):
+
+* Ability to form a (reasonably) unique identifier from a disc, using the label and the date of creation
+  * Ability for Annex to identify discs using this and ask for the correct disc if the file does not match (accomodating RW discs where label and date might change, or simply disc copies)
+    * Example: `not the original disc... trying anyway... file hash mismatch... please enable the remote disc with \"MYLABEL\" and creation date \"2001-01-01\"`
+* Option to checksum without importing the actual objects into the annex
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_13_0a343a8fdad66765371ca22581b35b84._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_13_0a343a8fdad66765371ca22581b35b84._comment
new file mode 100644
index 0000000000..2b3cf5839f
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_13_0a343a8fdad66765371ca22581b35b84._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Not a priority in itself, still feels like a missing piece."
+ date="2016-10-26T12:29:50Z"
+ content="""
+> I have a large number of files that are accessed infrequently and stored off-line on DVD-Rs. I need to keep track of which files are on which disc so that when I want a file I can find it.
+> (...)
+> 4) Easily incorporate the current DVD-Rs into the new system
+
+This last item would make `git-annex` suitable to catalog existing WORM media.
+
+In the past I have used some programs but was never satisfied with their graphical-UI-first approach or closed format.  For example: gtktalog, cdcat, cdcollect, where is it, virtual volume view, gnome catalog, basenji.  Ref: https://alternativeto.net/software/cdcollect/?platform=linux . 
+
+I also used at some point a plain old `find|{stat;md5}|gzip > ~/catalogs/my_volume_id.gz` then `grep mystring ~/catalogs/*gz` which, at the end of the day, has an overall good cost/benefit ratio.
+
+IMHO git-annex has a sane foundation and the potential to do better than those tools.
+
+Technically this looks indeed similar to a web special remote, but needs to accommodate for arbitrary mount point and keep count of copies.
+
+To be honest, the DVD use case is not a priority for me at the moment, but it feels like a missing piece in an otherwise good puzzle.  As if handling this case nicely would actually benefit other, more modern use cases.
+
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_14_b315c50d796d73bfc35acebee1836f40._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_14_b315c50d796d73bfc35acebee1836f40._comment
new file mode 100644
index 0000000000..abbb8c7b06
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_14_b315c50d796d73bfc35acebee1836f40._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="username"
+ avatar="http://cdn.libravatar.org/avatar/3c17ce77d299219a458fc2eff973239a"
+ subject="comment 14"
+ date="2021-09-28T22:56:16Z"
+ content="""
+Inspired by the OP I devised a slightly modified method for cataloguing my optical media library.
+
+The goal is having a main git-annex repo tracking what's on HDD, while adding the optical media as one-time remotes for location tracking and easy future inspection of their contents without having to physically insert the disc in the drive and mounting it.
+
+The current contents of the HDD and the contents of the total set of the optical discs are not a 1:1 match, both have files not present in the other.
+
+Current plan:
+
+1. copy already burnt discs to a directory on disk and create a git-annex repo with the same configuration as the main catalogue repo, using the disc label as description:
+```
+git annex init disc_label && git annex config --set annex.dotfiles true && git config annex.backend MD5 && git config annex.gitaddtoannex false
+```
+
+2. add the optical disc repo as remote in the main repo:
+```
+git remote add CD1 /mnt/CD1/ && git annex sync --no-push -jobs=cpus && git annex sync --cleanup && git remote remove CD1
+```
+
+3. create a branch for easily \"mounting\" each disc with git checkout without needing to
+```git log --oneline | grep disc_label```
+for finding the relevant commit hash:
+```
+git branch CD1 XXXXXXXXXX
+```
+
+4. edit working tree as desired, then override git-annex sync's automatic commit:
+```
+git add . && git commit --quiet --amend --message=\"add CD1\"
+```
+
+5. repeat for other discs
+
+
+The main repo should end up looking like so, each optical disc \"dangling\" from the main branch that tracks the HDD contents:
+
+```
+$ git log --graph --oneline
+*   XXXXXXXXXX (HEAD -> master) add DVD1
+|\  
+| * XXXXXXXXXX (DVD1) DVD1
+*   XXXXXXXXXX  add CD1
+|\  
+| * XXXXXXXXXX (CD1) CD1
+*   XXXXXXXXXX  init
+```
+
+and any file given as argument to ```git annex whereis``` should be easily traceable:
+
+```
+$ git-annex whereis file
+whereis file (4 copies) 
+  	XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -- HDD [here]
+  	XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -- CD1
+  	XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -- DVD1
+  	XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -- BD1
+ok
+```
+
+Seems good enough for me but considering I can barely wrap my head around all that git and git-annex are capable of I'm posting here hoping for a sanity check that this solution does work as expected and/or suggestions for improvements before fully committing to it.
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_15_9ddd6278ea00c5594083347b5b9b8405._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_15_9ddd6278ea00c5594083347b5b9b8405._comment
new file mode 100644
index 0000000000..1d46c5150c
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_15_9ddd6278ea00c5594083347b5b9b8405._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2021-10-11T16:07:38Z"
+ content="""
+git-annex now has the ability to import a tree of files from a
+directory special remote, which results in a remote tracking branch, the
+same as you'd have after fetching a git remote.
+
+	git-annex initremote dvd type=directory directory=/path/to/DVD encryption=none importtree=yes
+	git-annex import master --from dvd --no-content
+
+The --no-content option avoids copying files to the local disk, although
+their content still will have to be read to hash them. If you want to
+copy the files from the disk at the same time, omit that option.
+
+After that, you can use the dvd/master branch it created in whatever way
+you desire. Also if you want the discs files to end up in a subdirectory,
+that can be specified when you import, eg "master:dvd" will put the files
+into a dvd/ subdirectory.
+
+Using this with multiple discs would probably work best if there was a way
+to mount each DVD to its own unique location.
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_16_c3f6cb58dd2328b7af8dd2657c2e2a1e._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_16_c3f6cb58dd2328b7af8dd2657c2e2a1e._comment
new file mode 100644
index 0000000000..ba211048f5
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_16_c3f6cb58dd2328b7af8dd2657c2e2a1e._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="username"
+ avatar="http://cdn.libravatar.org/avatar/3c17ce77d299219a458fc2eff973239a"
+ subject="directory special remote"
+ date="2021-10-17T22:15:51Z"
+ content="""
+Thanks for the suggestion.
+I've looked into directory special remotes and using them for the optical media appears to undermine the intent of step 3 in my previous reply, of \"mounting\" each disc using ```git checkout DISC_LABEL```, because the master branch contents are combined with the imported directory special remote contents.
+
+The ```git checkout``` should leave the working directory with an 1:1 copy of the directory tree of the imported disc, except with all files replaced by broken annex symlinks.
+
+But I'm considering the opposite now: using the directory special remote not for the optical discs but for the master branch of the repo instead, the one that tracks the local HDD tree:
+
+    git-annex initremote HDD type=directory directory=/path/to/HDD encryption=none importtree=yes
+
+The local dataset I want to use as the seed for the catalogue has multiple hardlinks so making a git-annex repository directly within it is out of the question as it would lead to duplicated data.
+
+The initial plan to work around that was making a reflink copy of the directory tree, initialising the git-annex repo therein, and regularly update its master branch by replacing the git working directory with a brand new reflink clone and ```git-annex add```'ing it.
+
+If I understood git-annex right, this would imply a full re-read of the whole dataset because of the changed inode numbers of the new reflink clone, despite the contents, filenames, and mtimes of most files being 100% identical.
+
+However, it seems that using a directory special remote would neatly circumvent that (at least until the current HDD dies and I'm forced to ```mkfs``` in the replacement) because git-annex would be smart enough to detect renames by looking at the stable inode and mtime of the moved files.
+
+The local dataset is around 250K files and 4TiB in real size, ballooning to over 8TiB if hardlinked files were counted as copies. The updates (using ```git-annex import master --from HDD --no-content```) to the catalogue master branch would happen with frequency somewhere between monthly to every 2 years.
+
+2 questions:
+
+1. Am I correct in assuming that re-importing a special remote would only read the newly added files and correctly detect all renames and deletions without re-reading, no matter how much time passes between re-imports of the master branch?
+
+2. Are there any downsides (scalability, memory use, etc) to using a directory special remote for this use case instead of a regular git-annex repository?
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_17_455ab8b72c477769d68eb4348e911234._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_17_455ab8b72c477769d68eb4348e911234._comment
new file mode 100644
index 0000000000..7e4e9dc4c5
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_17_455ab8b72c477769d68eb4348e911234._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 17"
+ date="2021-10-18T15:36:06Z"
+ content="""
+>Thanks for the suggestion. I've looked into directory special remotes and using them for the optical media appears to undermine the intent of step 3 in my previous reply, of \"mounting\" each disc using git checkout DISC_LABEL, because the master branch contents are combined with the imported directory special remote contents.
+
+Huh? Of course you can import to a separate branch.
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_18_679ad639cbba7f9a4d28131219d20178._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_18_679ad639cbba7f9a4d28131219d20178._comment
new file mode 100644
index 0000000000..fdf131035d
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_18_679ad639cbba7f9a4d28131219d20178._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="username"
+ avatar="http://cdn.libravatar.org/avatar/3c17ce77d299219a458fc2eff973239a"
+ subject="comment 18"
+ date="2021-10-18T19:54:29Z"
+ content="""
+I wasn't clear enough, or maybe I did something wrong when testing the directory special remote.
+
+When using standard git-annex repositories for everything as explained in comment 14 I get this:
+
+```
+$ git log --graph --oneline
+*   5555555555 (HEAD -> master) amended commit 2
+|\  
+| * 4444444444 (DVD1) DVD1
+*   3333333333  amended commit 1
+|\  
+| * 2222222222 (CD1) CD1
+*   1111111111  init
+```
+
+The master branch tracks only the contents of my local HDD (note that in step 4 I edit the working directory to my liking and amend the automatic ```git-annex sync``` commit), and the CD1 branch contains only what's in that disc and nothing else, such that ```git checkout 2222222222``` or ```git checkout CD1``` replaces everything in the working directory with the contents of CD1, similar to mounting the physical disc and browsing its filesystem.
+
+Using the directory special remote, the contents of my master branch are combined with the contents of the special remote, so the same ```git checkout CD1``` command wouldn't replicate exactly what's on CD1, the master branch directory tree would still be present after the branch switch.
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_19_854531569edbb5c152c4d6b0d764a6c5._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_19_854531569edbb5c152c4d6b0d764a6c5._comment
new file mode 100644
index 0000000000..83a122f2e4
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_19_854531569edbb5c152c4d6b0d764a6c5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 19"
+ date="2021-10-19T17:17:47Z"
+ content="""
+Again, you can just run `git annex import --from=CD1 CD1`, which will import everything on the CD1 special remote to a branch named \"CD1\" which is completely independ from the master branch (it won't even share the same history).
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_1_25e65ee3949e7d918376298cf11585f2._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_1_25e65ee3949e7d918376298cf11585f2._comment
new file mode 100644
index 0000000000..e406f1b6f8
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_1_25e65ee3949e7d918376298cf11585f2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="Have you seen the dar utility?"
+ date="2012-10-20T19:03:37Z"
+ content="""
+http://dar.linux.free.fr/doc/index.html
+
+Would be nice to have this as another remote option for git-annex, since I too would like to have static (and possibly incrementally extended) remotes that span multiple DVDs
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_20_a80b9ce3a78fb44c9d60e877146d9e59._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_20_a80b9ce3a78fb44c9d60e877146d9e59._comment
new file mode 100644
index 0000000000..27047bee59
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_20_a80b9ce3a78fb44c9d60e877146d9e59._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="username"
+ avatar="http://cdn.libravatar.org/avatar/3c17ce77d299219a458fc2eff973239a"
+ subject="comment 20"
+ date="2021-10-23T15:53:57Z"
+ content="""
+Aha, that's what I was missing!
+
+I was working under the wrong assumption that the git-annex location tracking was tied in some way to the master branch and that alternate branches required shared history with master to have their contents tracked.
+
+Wholly independent branches for each disc is exactly what I want, thanks Lukey and Joey for your suggestions.
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_2_8a71ca048f9de29a198a6afb17d5315e._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_2_8a71ca048f9de29a198a6afb17d5315e._comment
new file mode 100644
index 0000000000..abff8702ec
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_2_8a71ca048f9de29a198a6afb17d5315e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="&quot;free-form&quot; special remote / dar utility"
+ date="2012-10-20T22:11:23Z"
+ content="""
+dar looks familiar, I'm sure I have run across it in the past.  However, it is not suitable in this case; see requirement #3 above that the DVD-Rs be usable without git or git-annex.
+
+What would work we be some sort of special remote that allows free-form data.  Imagine that you create the DVD-R with the files on it, then you mount it and add the mount directory as a free-form special remote.  git-annex checksums all the files under the specified directory and stores the relative path to each file somewhere.  Then, when you want to fetch a specific hash from the remote it looks up the relative path, adds it to the base directory and transfers it into the local .git/annex/objects/ store.
+
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_3_e3d1d3a3d3d831432ec940a8ab6f31e9._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_3_e3d1d3a3d3d831432ec940a8ab6f31e9._comment
new file mode 100644
index 0000000000..973e97319e
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_3_e3d1d3a3d3d831432ec940a8ab6f31e9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://lj.rossia.org/users/imz/"
+ ip="79.165.57.104"
+ subject="Yes, I agree, such a special remote for free-form read-only media would be convnient."
+ date="2012-10-20T23:58:45Z"
+ content="""
+I have already stored a lot of large files on DVDs. I did that for arhiving, so I cared that there are several copies. But I want this to be more automated.
+
+I take my disc (or one created by someone else, without any knowledge of Git), checksum its contents in git-annex, and in the projects where I'm using this content, I can check that the file is archived on at least N discs.
+
+Also, I might enhance the content -- this would be refected in a Git commit, so then I want also to be able to check that the new version has also ben archived on severeal discs.
+
+A special remote for such free-form read-only media would be very convenient.
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_4_26a33eae98b4faaf6baf6635e3d28a8f._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_4_26a33eae98b4faaf6baf6635e3d28a8f._comment
new file mode 100644
index 0000000000..44d547dd9c
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_4_26a33eae98b4faaf6baf6635e3d28a8f._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="Some free-form remote ideas"
+ date="2012-10-21T02:07:40Z"
+ content="""
+This is starting to get interesting.  A free-form remote would definitely simplify my use case, and also solve the \"future goal\" of easily incorporating my already existing DVD-Rs.
+
+I haven't really looked into the git-annex internals up to this point, but looking at the [[special_remotes/hook]] page there doesn't seem to be a hook for init which would be needed to populate git-annex's index of files in the remote.  (git-annex seems to assume that new special remotes are empty)
+
+Another problem is where to store the hash to path relation information.  On a RW remote it would be stored in the remote, but here we need to keep it in the repo somehow.  This could be in the git-annex branch, or possibly another branch created specifically for this purpose.
+
+1) initremote needs to:
+
+* hash the contents of all the remote's files
+* update git-annex's index of the remote's contents
+* store the paths to the hashes in the repo
+
+2) store and remove should just fail.
+
+3) retrieve and check present seem straight forward.
+
+The assistant blog mentions adding support for read only remotes but I don't know anything about it: [[design/assistant/blog/day_65__transfer_polish]] (I'm still on 3.20120605)
+
+Let me know if there is anything I haven't thought of yet.
+
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_5_49ac298d39c824b0e52a239961463e09._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_5_49ac298d39c824b0e52a239961463e09._comment
new file mode 100644
index 0000000000..b06891cd83
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_5_49ac298d39c824b0e52a239961463e09._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.23"
+ subject="comment 5"
+ date="2012-10-21T05:36:36Z"
+ content="""
+I encourage playing around with the hook special remote and see how far you can make it go.
+
+I may be doing something vaguely like this for [[design/assistant/desymlink]], although I'm pretty sure it would still have a git repository associated with the directory of regular files.
+
+One option is to use the web special remote, with file:// urls. Assuming a given disc will always end up mounted somewhere stable, such as /media/dvd1, /media/dvd2, etc, you could then just `git annex addurl file:///media/dvd1/$file`. `git annex whereis` will show the url, which has enough info to work out the disk to mount.
+
+The web special remote did not support file:// urls, but I've just fixed that. The only downside is that, while it will identify files duplicated across disks, and `whereis` will show multiple urls for such files, there's only one web special remote, and so it only counts as 1 copy. This could perhaps be improved; git-annex may eventually get support for remotes reporting how many copies of a file they contain.
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_6_55a4a3616ea59654da1c2f9902561e3b._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_6_55a4a3616ea59654da1c2f9902561e3b._comment
new file mode 100644
index 0000000000..ab971dab5e
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_6_55a4a3616ea59654da1c2f9902561e3b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://www.openid.albertlash.com/openid/"
+ ip="74.96.185.87"
+ subject="It works!"
+ date="2012-10-24T22:00:31Z"
+ content="""
+This works great! I first tried it with WORM, no-go. I can see why the SHA backends are so powerful, they appear to circumvent the commits which git usually uses for merging. When I first do the merge, it reports this:
+
+warning: no common commits
+
+Compared to how I've managed CD/DVD backups in the past, this is a quantum leap forward, and I don't find it convoluted in comparison. Yes, there is dar, but I prefer this method. In my case, its the perfect solution for original files, which in generally are treated as immutable, and not accessed very often. They are usually large, too! I'm using them for digital pictures.
+
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_7_92a2af3e0e328bb48bcc67a69187ee57._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_7_92a2af3e0e328bb48bcc67a69187ee57._comment
new file mode 100644
index 0000000000..736fc6ce20
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_7_92a2af3e0e328bb48bcc67a69187ee57._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="web and hook special remotes"
+ date="2012-10-24T23:26:53Z"
+ content="""
+Hi Joey,
+
+Thanks for the advice.  I had thought of the web special remote; but as you may have noticed from my example, I don't use automount so my DVDs and CDs all get mounted in the same place. (/mnt/cdrom) so the web special remote won't work for me.
+
+I'll try to play around with the hook special remote this weekend.  I had a thought it might be interesting to have it search for the DVDs in some common places or even by parsing the mounted file systems, and allow an override or augmentation through git config.
+
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_8_f6e39e71882d55cdc061166aea3e2bd3._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_8_f6e39e71882d55cdc061166aea3e2bd3._comment
new file mode 100644
index 0000000000..84705d4cd7
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_8_f6e39e71882d55cdc061166aea3e2bd3._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="no need to merge"
+ date="2012-10-24T23:52:30Z"
+ content="""
+Albert,
+
+Thanks for feedback!  I'm glad that somebody else found the method I worked out useful.  As I'm going to try and turn it into a proper special remote, let me know if there is any particular use case or feature you'd like me to address.
+
+Note that in my testing, I found that you don't actually need to merge the DVD's branch into the local branch you are using for git annex to be able to find the files on it that are identical to files in your local branch.
+
+I haven't played around with cloning the repo, but I will try that this weekend.  I'm thinking it *might* be necessary to create local branches from the DVD remotes so that they'll get carried along when you clone the repo.
+
+As far as the repos on the DVD's not having a shared ancestry with main repo, that was a conscious choice that I made.  I wanted to add as little extra data to the DVDs as possible since I usually fill them to the brim anyway.  I didn't feel that it would be beneficial for the DVD's to know about the history of the main repo and other files that they don't contain.  Furthermore, besides all the links and history, you'd be replicating all the files in the main repo that aren't annexed.
+
+If you want to avoid the error, but still have a local branch for the DVD repos you should be able to do something like the following:
+
+<b>WARNING:</b> these commands are untested!
+<pre>
+git checkout -b disc1 disc1/master
+git checkout -b disc2 disc2/master
+</pre>
+
+Working from the original example, you should then get local branches for the DVDs that don't have a common ancestor with your master local repo.  I haven't actually tested that though.  Testing will have to wait for this weekend.
+"""]]
diff --git a/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_9_6c45a6264d69e22800c329a0f8a2d470._comment b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_9_6c45a6264d69e22800c329a0f8a2d470._comment
new file mode 100644
index 0000000000..5a3f2885c1
--- /dev/null
+++ b/doc/forum/Managing_a_large_number_of_files_archived_on_many_pieces_of_read-only_medium___40__E.G._DVDs__41__/comment_9_6c45a6264d69e22800c329a0f8a2d470._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.138"
+ subject="comment 9"
+ date="2012-10-25T03:33:29Z"
+ content="""
+@Steve, it seems to me you could still use the web special remote, just pointing it at an url that goes through a symlink to the mount point.
+"""]]
diff --git a/doc/forum/Managing_multiple_annexes_with_assistant__63__.mdwn b/doc/forum/Managing_multiple_annexes_with_assistant__63__.mdwn
new file mode 100644
index 0000000000..30e059743f
--- /dev/null
+++ b/doc/forum/Managing_multiple_annexes_with_assistant__63__.mdwn
@@ -0,0 +1,13 @@
+Is it possible to run more than one instance of the assistant in an account?
+
+A particular example is that I might have two annexes:
+
+1. for my music, and
+2. for some personal documents.
+
+I would like to have my music annex paired with my work laptop and have all the automagical power of git-annex-assistant working for me.  However I don't want to put my personal documents on a work machine, hence the second annex.
+
+(I think) An ideal world would have the assistant managing both annexes.  Is this possible?
+
+
+I know my question is similar to [one annex versus many annexes?](http://git-annex.branchable.com/forum/one_annex_versus_many_annexes__63__/) but I think it is different enough to warrant a new thread...
diff --git a/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_1_ba8c70e4a46441b48ad910625636eee5._comment b/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_1_ba8c70e4a46441b48ad910625636eee5._comment
new file mode 100644
index 0000000000..675b5b71c2
--- /dev/null
+++ b/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_1_ba8c70e4a46441b48ad910625636eee5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.23"
+ subject="comment 1"
+ date="2012-10-19T17:08:39Z"
+ content="""
+If you go to the upper-right menu in the webapp, and select \"New repository\", you can add a separate independant repository. The assistant's autostart will run it on both of them when you log in.
+"""]]
diff --git a/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_2_4b4f0a7d84a51ae92536e2c190256069._comment b/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_2_4b4f0a7d84a51ae92536e2c190256069._comment
new file mode 100644
index 0000000000..86fa9ebabc
--- /dev/null
+++ b/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_2_4b4f0a7d84a51ae92536e2c190256069._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkk3K0AUduAybbBO_LRRGKOe2zcGeezbzI"
+ nickname="Nathan"
+ subject="Webapp spins when adding a second annex"
+ date="2012-11-20T04:55:05Z"
+ content="""
+I was trying to add a second annex (repository) via the webapp, but it seems like the process never completes: the browser just spins (\"connecting...\"). If I kill the webapp process and restart, I can see the second annex in the list of repositories, but clicking on it gives the same behaviour. Interestingly, the path *is* added to ~/.config/git-annex/autostart, and the webapp does create the path, if needed, and initializes it as a git annex. I've reproduced this on two different machines, both running Ubuntu 12.10 and git annex 3.20121112.
+
+Is there anything I can do to help debug?
+"""]]
diff --git a/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_3_86daadc565f96db5db13b6dbcbc66db3._comment b/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_3_86daadc565f96db5db13b6dbcbc66db3._comment
new file mode 100644
index 0000000000..6ad879d76d
--- /dev/null
+++ b/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_3_86daadc565f96db5db13b6dbcbc66db3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 3"
+ date="2012-11-25T18:59:37Z"
+ content="""
+@Nathan at this point, you should have two separate git-annex processes running, one for each repository. You can try opening a shell, changing to the new repository, and running `git annex webapp --debug` to get debugging information on the new one.
+"""]]
diff --git a/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_4_e43d71ddfdfdb7bcb13bfb894de6a5ec._comment b/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_4_e43d71ddfdfdb7bcb13bfb894de6a5ec._comment
new file mode 100644
index 0000000000..78570a08d3
--- /dev/null
+++ b/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_4_e43d71ddfdfdb7bcb13bfb894de6a5ec._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 4"
+ date="2012-11-28T20:13:11Z"
+ content="""
+@Nathan, I have just noticed and fixed a problem that could cause this to happen if you were using the standalone tarball (or OSX app) builds. It would not affect git-annex installed by other methods.
+"""]]
diff --git a/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_5_e94d33be83b45918d1a39d6e16fba4b4._comment b/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_5_e94d33be83b45918d1a39d6e16fba4b4._comment
new file mode 100644
index 0000000000..ae9c5c5b60
--- /dev/null
+++ b/doc/forum/Managing_multiple_annexes_with_assistant__63__/comment_5_e94d33be83b45918d1a39d6e16fba4b4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkk3K0AUduAybbBO_LRRGKOe2zcGeezbzI"
+ nickname="Nathan"
+ subject="comment 5"
+ date="2012-12-11T04:15:49Z"
+ content="""
+Thanks, Joey; I was using the standalone build, and it seems to be behaving better now.
+"""]]
diff --git a/doc/forum/Managing_multiple_repositories_concurrently__63__.mdwn b/doc/forum/Managing_multiple_repositories_concurrently__63__.mdwn
new file mode 100644
index 0000000000..60942584b8
--- /dev/null
+++ b/doc/forum/Managing_multiple_repositories_concurrently__63__.mdwn
@@ -0,0 +1,5 @@
+I have the webapp setup to manage 4 different repositories.
+
+One repository had many gigabytes to upload to a remote. As this was moving along, I wanted to check on the status of one of the other repositories. I knew that this second repository had a lot of data to download. When I switched to the second repo in the webapp, I noticed in my network monitor that the amount of upstream bandwidth I was using dropped and the amount of downstream bandwidth increased. I switched back to the first repo, and my downstream bandwidth dropped and the upstream bandwidth increased.
+
+It looks like git-annex stopped uploading data from the first repo when I switched to the second, and stopped downloading data to the second repo when I switched to the first. Is this correct? I was under the impression that switching repositories in the webapp simply changed the view that I was looking at, but that the assistant would still be managing all the repositories I had setup -- uploading/downloading/syncing concurrently.
diff --git a/doc/forum/Managing_multiple_repositories_concurrently__63__/comment_1_ebec1ddad71e961cdc9b21cbddfbcdaf._comment b/doc/forum/Managing_multiple_repositories_concurrently__63__/comment_1_ebec1ddad71e961cdc9b21cbddfbcdaf._comment
new file mode 100644
index 0000000000..c1c5cd9179
--- /dev/null
+++ b/doc/forum/Managing_multiple_repositories_concurrently__63__/comment_1_ebec1ddad71e961cdc9b21cbddfbcdaf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-17T18:53:26Z"
+ content="""
+Each repository gets its own git-annex assistant daemon, which is entirely separate from the daemons used by other repositories. 
+
+The only affect that switching which repository is in view in the webapp can have is it can start a daemon running on a repository that for some reason did not already have the daemon running. This could happen if it was not set to autostart on login, for example.
+"""]]
diff --git a/doc/forum/Manipulate_a_git-annex_repo_from_an_Android_app.mdwn b/doc/forum/Manipulate_a_git-annex_repo_from_an_Android_app.mdwn
new file mode 100644
index 0000000000..bafd5d9e9b
--- /dev/null
+++ b/doc/forum/Manipulate_a_git-annex_repo_from_an_Android_app.mdwn
@@ -0,0 +1,21 @@
+I use the command line almost every hour, I'm familiar with it. But it's a pita on the phone.
+
+I'd like to create an "graphical" Android application that lists/browses the repo's content and allows the user to manipulate the files/directories.
+
+git-annex for Android (5.0) is installed and working fine. I was messing around (on my rooted phone) with the rwx permissions to run the git-annex binary from my app as it's a different user and has no access to those binaries by default. But no success yet: 
+
+```
+shell@jfltexx:/storage/sdcard1/repo $ /data/data/ga.androidterm/lib/lib.git-annex.so list
+
+lib.git-annex.so: git: createProcess: runInteractiveProcess: exec: permission denied (Permission denied)
+```
+
+Question 1: How should I set up the permissions to be able to successfully run any git-annex command from my (non-commercial, private) Android app?
+
+Question 2: What if I include all the git-annex binaries in my app as a resource and write them to disk after install and execute them? (Permissions should work.)
+
+
+Use case: family videos are stored in a repo at home. This repo is cloned to my phone's sdcard. I want to browse the repo on my phone and mark some directories to be transferred from home to phone. My app would be a simple frontend for git-annex where you can browse and do some basic stuff: get, drop, manipulate metadata (and of course start playing a video).
+
+Thank you for any ideas,
+Bence
diff --git a/doc/forum/Manipulate_a_git-annex_repo_from_an_Android_app/comment_1_c59ec715eb02fbdd63780b2450ff2de1._comment b/doc/forum/Manipulate_a_git-annex_repo_from_an_Android_app/comment_1_c59ec715eb02fbdd63780b2450ff2de1._comment
new file mode 100644
index 0000000000..8a09376027
--- /dev/null
+++ b/doc/forum/Manipulate_a_git-annex_repo_from_an_Android_app/comment_1_c59ec715eb02fbdd63780b2450ff2de1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-12-02T17:05:03Z"
+ content="""
+Android's security model may not be friendly to code reuse. You might need
+to put both git-annex and your program in the same app.
+
+I know this is something others want too. Maybe you can find or make a file
+manager type app that integrates with git-annex get/drop and could be
+included in the git-annex android app?
+"""]]
diff --git a/doc/forum/Manipulate_a_git-annex_repo_from_an_Android_app/comment_2_20ee5f900a2ff6154c0d90263579723e._comment b/doc/forum/Manipulate_a_git-annex_repo_from_an_Android_app/comment_2_20ee5f900a2ff6154c0d90263579723e._comment
new file mode 100644
index 0000000000..e95d090e54
--- /dev/null
+++ b/doc/forum/Manipulate_a_git-annex_repo_from_an_Android_app/comment_2_20ee5f900a2ff6154c0d90263579723e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="cbaines"
+ subject="comment 2"
+ date="2015-12-21T12:40:52Z"
+ content="""
+I am also interested in this.
+
+It might be better to use intents [1], such that git-annex on Android can provide an interface for any app to ask it to perform actions on repositories.
+
+Joey, is there any kind of api in the current Android app?
+
+1: https://developer.android.com/reference/android/content/Intent.html
+"""]]
diff --git a/doc/forum/Manual_Setup_of_a_Central_Repo.mdwn b/doc/forum/Manual_Setup_of_a_Central_Repo.mdwn
new file mode 100644
index 0000000000..82a1c70bae
--- /dev/null
+++ b/doc/forum/Manual_Setup_of_a_Central_Repo.mdwn
@@ -0,0 +1 @@
+My current setup involves 3 computers, one desktop one laptop and a vps. In my current setup I have created annex repos on the server and cloned from it, both machines sync to the server. All three use non base repos. Now I have another annex folder on the desktop that I would like to sync between the three. Both machines are behind NAT so server can not communicate with the machines. In order to init the repo on the vps, I was thinking of setting up a temporary VPN/port forward between the desktop and the VPS then clone from the desktop finally remove the remote section in .git/config on the server so VPS becomes the master again. First of all is there an easier way to do this? if not is it safe to do this? or is it going to cause problems down the line.
diff --git a/doc/forum/Manual_Setup_of_a_Central_Repo/comment_1_3a163fd5629dc40423f1290a78ae1c07._comment b/doc/forum/Manual_Setup_of_a_Central_Repo/comment_1_3a163fd5629dc40423f1290a78ae1c07._comment
new file mode 100644
index 0000000000..e5630b3319
--- /dev/null
+++ b/doc/forum/Manual_Setup_of_a_Central_Repo/comment_1_3a163fd5629dc40423f1290a78ae1c07._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 1"
+ date="2013-08-26T18:46:06Z"
+ content="""
+You could certainly do that. I don't think it's the easiest way.
+
+Note that this is essentially a git question. It really has nothing to do with git-annex, unless you want to use the git-annex assistant, which can sync a repository over XMPP without needing a central git repository at all.
+
+If I had this problem with git in general, I would make a new empty repository on the server, and push the local repository I have on the one machine to it. Then on the other machine, I would clone from the server. Problem solved, I think?
+"""]]
diff --git a/doc/forum/Manual_commit_message_in_direct_mode.mdwn b/doc/forum/Manual_commit_message_in_direct_mode.mdwn
new file mode 100644
index 0000000000..d74c366073
--- /dev/null
+++ b/doc/forum/Manual_commit_message_in_direct_mode.mdwn
@@ -0,0 +1,3 @@
+I am just returning to git-annex after some time. The last time I was using it, the [[/todo/direct_mode_guard]] was not yet in place, and I could supply my own commit messages even in a direct mode repository using `git commit`. Now that the guard is in place, is there a built-in way to provide a commit message that will be used instead of "git-annex automatic sync" by `git annex sync`? 
+
+I have tried doing a manual commit with `git --git-dir=/path/to/local/.git --work-tree=/path/to/local -c core.bare=false commit -m 'Manual Commit Message'`, and it seems to work. Does this do the same thing as the part of `git annex sync` that commits any outstanding changes before syncing with remotes?
diff --git a/doc/forum/Manual_commit_message_in_direct_mode/comment_1_32f95eefec25bb127ed96248446c21b1._comment b/doc/forum/Manual_commit_message_in_direct_mode/comment_1_32f95eefec25bb127ed96248446c21b1._comment
new file mode 100644
index 0000000000..bb53d4458e
--- /dev/null
+++ b/doc/forum/Manual_commit_message_in_direct_mode/comment_1_32f95eefec25bb127ed96248446c21b1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 1"
+ date="2014-05-27T16:10:29Z"
+ content="""
+Yes, you can use the `-c core.bare=false` trick to bypass the direct mode guard if you want to. Just bear in mind that it's very easy to shoot yourself in the foot by passing -a or filenames to git commit, which then checks the whole large file into git..
+"""]]
diff --git a/doc/forum/Manual_commit_message_in_direct_mode/comment_2_bf1d10067379c802ac5020d8becd6d35._comment b/doc/forum/Manual_commit_message_in_direct_mode/comment_2_bf1d10067379c802ac5020d8becd6d35._comment
new file mode 100644
index 0000000000..facb5ce334
--- /dev/null
+++ b/doc/forum/Manual_commit_message_in_direct_mode/comment_2_bf1d10067379c802ac5020d8becd6d35._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnxvt4mc32O0ctvPGhhII_ZKsHUiaD2o7I"
+ nickname="William"
+ subject="comment 2"
+ date="2014-05-28T04:40:27Z"
+ content="""
+Joey, thanks for clarifying that. I learned about the perils of using regular git commands in direct mode before the guard was implemented, so I will use with care. Specifying a commit message is really the only case where I am tempted to bypass the the `git annex` subcommands in direct mode. 
+
+
+"""]]
diff --git a/doc/forum/Manual_local_pairing_without_webapp__63__.mdwn b/doc/forum/Manual_local_pairing_without_webapp__63__.mdwn
new file mode 100644
index 0000000000..68e1dd00e7
--- /dev/null
+++ b/doc/forum/Manual_local_pairing_without_webapp__63__.mdwn
@@ -0,0 +1,5 @@
+I haven't found anything on this, is there a way to do local pairing without starting the assistant (ideally from the CLI)?
+
+The assistant is pretty heavy, does lots of stuff automatically I might not want it to in many situations (commit, sync) and a GUI is often more cumbersome than a CLI in my experience.
+
+The main use-case would be for headless systems where I might want to give a user/machine access to an annex repo without granting them full access to the system.
diff --git a/doc/forum/Manual_local_pairing_without_webapp__63__/comment_1_1f280e38bf5fa81d3a8cc4887f32e590._comment b/doc/forum/Manual_local_pairing_without_webapp__63__/comment_1_1f280e38bf5fa81d3a8cc4887f32e590._comment
new file mode 100644
index 0000000000..91028a1635
--- /dev/null
+++ b/doc/forum/Manual_local_pairing_without_webapp__63__/comment_1_1f280e38bf5fa81d3a8cc4887f32e590._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-08T17:02:04Z"
+ content="""
+The assistant's local pairing uses a custom method to discover
+other assistants on the LAN, but then all it does is exchange ssh public
+keys, and each configures ssh to let the other's ssh public key in,
+limiting it to running `git-annex-shell` and limiting git-annex-shell
+to access the one repository.
+
+It's pretty easy to set up the same kind of ssh public 
+key configuration yourself manually. Just generate a public key, and on the
+other host add it to `.ssh/authorized_keys`. The git-annex-shell man page
+has an example of what to put in `authorized_keys` to fully lock it down.
+
+There could be room in `git-annex p2p` to implement something like the
+assistant's local pairing. But I don't know if it's called for since
+setting up a locked down ssh key is straightforward, at least
+compared with its current use case of setting up a tor hidden service
+and limiting who can access it.
+"""]]
diff --git a/doc/forum/Manual_local_pairing_without_webapp__63__/comment_2_d83cc10b2359eb3578c6c4dd299cf308._comment b/doc/forum/Manual_local_pairing_without_webapp__63__/comment_2_d83cc10b2359eb3578c6c4dd299cf308._comment
new file mode 100644
index 0000000000..91ad428c79
--- /dev/null
+++ b/doc/forum/Manual_local_pairing_without_webapp__63__/comment_2_d83cc10b2359eb3578c6c4dd299cf308._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 2"
+ date="2022-03-04T20:27:30Z"
+ content="""
+Setting up locked-down ssh keys may seem trivial to you since you've thoroughly investigated the topic for implementing them for the assistant's pairing mechanism but I'm pretty sure your average git-annex user doesn't know how to do that or would do it wrong. I certainly wouldn't trust myself doing that on my own.
+
+Support for pairing on the CLI via P2P was implemented not too long ago (which is great!) but I'd like to stick with regular IP as it's more efficient and I've got my network set up for remote access pretty well already.
+"""]]
diff --git a/doc/forum/Manual_mode_option_in_assistant_auto-syncs.mdwn b/doc/forum/Manual_mode_option_in_assistant_auto-syncs.mdwn
new file mode 100644
index 0000000000..49b58e529e
--- /dev/null
+++ b/doc/forum/Manual_mode_option_in_assistant_auto-syncs.mdwn
@@ -0,0 +1,11 @@
+Hi,
+
+I've recently set-up a server which uses Southpaw's Tactic DAM system and I've initialised a git-annex directory using the assistant which will manage any files which Tactic puts into the git-annex. I plan to make some remote repositories to Amazon S3, friends and some local machines on my home network. The server is running Ubuntu 64-bit and so I've written an upstart job which runs 'git-annex assistant --autostart' as the user 'git-annex' as this user doesn't log-in and run the xdg autostart .desktop at all.
+
+I saw that you can set the purpose of each repository which it will sync to and noticed 'Manual Mode.' From the description, it seems it will only work if I do explicit git-annex commands to it which would be perfect for me as I'd like to write tools which run git-annex add/get/drop/etc. manually on some remotes like ones to friends as I don't want them to sync to everything or any files that they produce, only files which they request with a special tool that I'll write and have Tactic marshal the file changes/names/etc.
+
+I've set those remotes to manual-mode via the assistant and tried copying a file to the remote's directory, but it auto-synced the file anyway. Maybe I'm getting confused at how manual mode works but I'd like to only explicitly set which files to add to the repo by a command and not just 'any' file which gets placed into that directory. If this is more of a wishlist request I guess just move this post into there and I'll reword it as a wish request.
+
+I don't need to use the assistant if that makes more sense, but I would like to be able to still monitor things as the webapp makes for a great GUI to check for that stuff. I can't wait for the https version  of webapp too, I currently run git-annex webapp --listen=<ip>:<port> and then run the link it outputs on my desktop machine to manage it from the server.
+
+Thanks, and this is such a great bit of software, especially as my Internet connection is really bad for 2013 standards, and having the option for friends/remote servers to sync up via an encrypted S3 or box.com account is great!
diff --git a/doc/forum/Manual_mode_option_in_assistant_auto-syncs/comment_1_4a0468b6ca2ffff8ef8f19800597567d._comment b/doc/forum/Manual_mode_option_in_assistant_auto-syncs/comment_1_4a0468b6ca2ffff8ef8f19800597567d._comment
new file mode 100644
index 0000000000..56e68f779b
--- /dev/null
+++ b/doc/forum/Manual_mode_option_in_assistant_auto-syncs/comment_1_4a0468b6ca2ffff8ef8f19800597567d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 1"
+ date="2013-08-24T16:20:29Z"
+ content="""
+In the assistant, putting a repository in manual mode prevents the assistant from automatically downloading every file that is added to other clones of the repository. As you've noticed, it does not prevent the assistant from automatically adding new files that are put into the local repository, or from uploading those files to other clients that want them (ie, clients not themselves set to use manual mode).
+
+You can prevent the assistant from noticing when you add new files to a repository by clicking on \"syncing enabled\" in the first repository in the list. (The repository labeled as \"here\".) You can then `git annex add` the files you want to add by hand, and manually `copy annex copy` them to other repositories, and manually `git annex sync`.
+"""]]
diff --git a/doc/forum/Manual_webapp_behaviour_on_ARM.mdwn b/doc/forum/Manual_webapp_behaviour_on_ARM.mdwn
new file mode 100644
index 0000000000..8b7b8fe278
--- /dev/null
+++ b/doc/forum/Manual_webapp_behaviour_on_ARM.mdwn
@@ -0,0 +1,15 @@
+Hello,
+
+I have a Samsung ARM Chromebook running Ubuntu with crouton (chroot in chromeos). I want to use git-annex, and add the chromebook as a second "device" to my already set up git-annex repo on my main pc. That repo is one folder set up with the assistant, and it has one encrypted ssh(rsync) remote.
+
+I've read that the webapp is not available on ARM, and I've also found a topic with a simple script to replicate git-annex-assistant steps: http://git-annex.branchable.com/forum/Running_assistant_steps_manually/. So, I've used the `cabal` steps to install git-annex manually, which is working.
+
+I want to use git-annex in a dropbox-like fashion, folder and file sync between these two devices (and maybe later on another encrypted ssh remote). However I'm in need of some guidance regarding the command line usage and such.
+
+My questions are:
+
+- How do I "add" the chromebook repo to the existing git-annex setup?
+- The machines are not on at the same time. One is my main workstation and the chromebook is my "mobile friend". The encrypted ssh remote is on a VPS, that is always on.
+  - How do I configure the syncing between the main machine, the chromebook and the encrypted ssh remote on the vps? If possible, bi-directional.
+
+If it is possible, both explanation and command line examples would help a lot. 
diff --git a/doc/forum/Manual_webapp_behaviour_on_ARM/comment_1_5431a57aa7d659faf0aee12e638dd1ba._comment b/doc/forum/Manual_webapp_behaviour_on_ARM/comment_1_5431a57aa7d659faf0aee12e638dd1ba._comment
new file mode 100644
index 0000000000..f045b5c3ec
--- /dev/null
+++ b/doc/forum/Manual_webapp_behaviour_on_ARM/comment_1_5431a57aa7d659faf0aee12e638dd1ba._comment
@@ -0,0 +1,56 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnudiRFAyVAwehTACPhuNV_dhhWsHKIACw"
+ nickname="Jose"
+ subject="git annex on chromebook"
+ date="2015-03-12T18:32:18Z"
+ content="""
+I know I'm commenting on something old but I was looking this topic up and felt this may help any future questions. :S
+
+* its just like any other machine with git annex. You can connect your instance of git annex that runs in the chroot (crouton) with your existing set up like normal. usb, ssh, xmpp+cloud
+
+* you will need a transfer repository, that vps should do nicely (I use a few USB drives)
+
+    * this depends if the VPS also has git annex installed or not. 
+if it does, great! If you want it configured for you, you can run git annex webapp to add a remote server and give it the details to connect to your VPS via ssh. Then tell it where your transfer repository will be and that should be it. If you plan on sharing this repo with your friend, or if you want more control over the data, you may want to set up your ssh repo via the command line instead. you may be able to add encryption and share your repository without necessarily letting your friend have access to everything on your account (if you have separate accounts)
+
+
+if it does not, also doable. Again if you want simple configuration git annex webapp will prompt you for credentials; in this case it may as you to encrypt the data (http://git-annex.branchable.com/encryption/). 
+
+* how to add an ssh remote via commandline (please don't just copy paste, a simple google of the commands will help you understand what they are doing)
+
+$ cd ~/Downloads/Documents
+
+$ git init
+
+$ git annex init \"chromebook\"
+
+$ git remote add my-ssh ssh://user@google.com/home/user/annex/Documents #I recommend you use an 'ssh alias' so you can just do 'ssh://alias1/home/user/annex/Documents'
+
+$ git annex add
+
+$ git annex sync
+
+$ git annex sync --content #I do not remember but I believe it may be necessary to do this for some versions of git annex.
+
+git annex may or may not complain about git annex being installed on your machine. (it does for me each time I do this... perhaps I'm missing a step?)
+If you know git annex is installed in the $PATH of your server (also your machine) then you can just run
+
+$  git config remote.my-ssh.annex-ignore false
+
+$  git annex sync
+
+$  git annex sync --content
+
+
+* how come I can not see my annexed files on chromeos but I can on crouton?
+because you are using git annex in 'indirect' mode
+
+$ cd ~/Downloads/Documents
+
+$ git annex direct
+
+You can also 'unlock' the files too but you will need to run git annex unlock every time you need to read/write a file using. 
+
+$ git annex unlock 
+
+"""]]
diff --git a/doc/forum/Manually_moving_annex_objects_to_new_repo.mdwn b/doc/forum/Manually_moving_annex_objects_to_new_repo.mdwn
new file mode 100644
index 0000000000..0aba25fd49
--- /dev/null
+++ b/doc/forum/Manually_moving_annex_objects_to_new_repo.mdwn
@@ -0,0 +1,12 @@
+I want to create a repo with the contents of an old repo, but with a fresh commit history, etc. I do not care about preserving the old repo.
+
+However, I just want to make sure that the following steps will not result in the new repo being broken in some way:
+
+1. Create a new git annex repo.
+2. Copy all of the symlinks from the old repo to the new one.
+3. Move .git/annex/objects from the old repo to the new one.
+4. Then "git annex add" everything in the new repo and commit.
+
+Please let me know also if there is a better way to achieve the same results.
+
+Thanks for your help.
diff --git a/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_1_f9b894bafc5ab19ec7b0b500ddfe00ef._comment b/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_1_f9b894bafc5ab19ec7b0b500ddfe00ef._comment
new file mode 100644
index 0000000000..b885ca1bde
--- /dev/null
+++ b/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_1_f9b894bafc5ab19ec7b0b500ddfe00ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="starting over with a new commit history"
+ date="2020-01-25T01:07:19Z"
+ content="""
+You could [squash all commits](https://stackoverflow.com/questions/25356810/git-how-to-squash-all-commits-on-branch) on all your branches to one commit.  See also [[git-annex-forget]] .
+"""]]
diff --git a/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_2_6125e6a7d6b15dee7bf6a6bfe99bcf73._comment b/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_2_6125e6a7d6b15dee7bf6a6bfe99bcf73._comment
new file mode 100644
index 0000000000..cae3575085
--- /dev/null
+++ b/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_2_6125e6a7d6b15dee7bf6a6bfe99bcf73._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 2"
+ date="2020-01-25T01:11:42Z"
+ content="""
+Create the new repository and then add the \"source\" repository as a [local cache](/tips/local_caching_of_annexed_files).
+
+This will allow you to copy the symlinks to the new repository and `git annex get` the content, in any order you like, with all the safety precautions of git-annex. The fact that it came from the cache isn't stored either, so it is added cleanly!
+
+I use this method very heavily and it works really well.
+"""]]
diff --git a/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_3_8203d8e0444471b9360b679f49f67fac._comment b/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_3_8203d8e0444471b9360b679f49f67fac._comment
new file mode 100644
index 0000000000..e13fc58680
--- /dev/null
+++ b/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_3_8203d8e0444471b9360b679f49f67fac._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="erewhon"
+ avatar="http://cdn.libravatar.org/avatar/b9bd5ad7176ebe149d0f051dcfe0a63e"
+ subject="Thank you"
+ date="2020-02-02T18:44:51Z"
+ content="""
+Thank you both for the suggestions. I am going to give the approach using the local cache a try.
+"""]]
diff --git a/doc/forum/Massive_drop_in_performance_with_--jobs_option.mdwn b/doc/forum/Massive_drop_in_performance_with_--jobs_option.mdwn
new file mode 100644
index 0000000000..bccb0d9dc9
--- /dev/null
+++ b/doc/forum/Massive_drop_in_performance_with_--jobs_option.mdwn
@@ -0,0 +1,9 @@
+Old version:  5.20150916-1
+New version:  5.20151208-1
+
+
+I have noticed that with the addition of the progress display, the actual overall performance of the transfer drop very noticeably from these two versions.  I am very tempted to keep the old version around to just handle the transfers.
+
+Also, I decided to build a newer version from git, using debuild.  I noticed that the libghc-persistant dependencies have no trailing commas.  I added the commas, built the package and had two errors in one of the tests.  I removed these dependencies from the control file and I am currently performing a rebuild (they were not present in 12/08 version).
+
+Build complete.  Tests passed.  Parallel transfers seem to be back up to speed.  Thanks!
diff --git a/doc/forum/Massive_drop_in_performance_with_--jobs_option/comment_2_8a9b5bc3b8a8ef947f2620422307c465._comment b/doc/forum/Massive_drop_in_performance_with_--jobs_option/comment_2_8a9b5bc3b8a8ef947f2620422307c465._comment
new file mode 100644
index 0000000000..b00eb61a0b
--- /dev/null
+++ b/doc/forum/Massive_drop_in_performance_with_--jobs_option/comment_2_8a9b5bc3b8a8ef947f2620422307c465._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-01-07T22:13:14Z"
+ content="""
+Version 5.20151019 is right between the two versions given, and probably
+contains the reason for the drop in performance: That version started
+checksumming files after receiving them to verify that their content is
+good.
+
+If so, this will get back the old level of performance:
+
+	git config annex.verify false
+
+If the performance problem were actually related to the new progress
+display, passing --quiet will disable that display. If you can show that
+simply passing --quiet speeds up transfers significantly somehow,
+I'd be happy to investigate further.
+
+
+----
+
+@umeboshi I don't think your comment is really related to the original question.
+If you run gets of a bunch of files in parallel, and two of the files
+have the same content, you can get this situation where a transfer of
+the content is already in progress.
+"""]]
diff --git a/doc/forum/Massive_drop_in_performance_with_--jobs_option/comment_2_c9fea9db7116e7ee82a09c23f22b54e9._comment b/doc/forum/Massive_drop_in_performance_with_--jobs_option/comment_2_c9fea9db7116e7ee82a09c23f22b54e9._comment
new file mode 100644
index 0000000000..cfc5f2684c
--- /dev/null
+++ b/doc/forum/Massive_drop_in_performance_with_--jobs_option/comment_2_c9fea9db7116e7ee82a09c23f22b54e9._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="umeboshi"
+ subject="comment 2"
+ date="2016-01-02T23:13:15Z"
+ content="""
+I have been getting more failures than I used to when using -J with get and copy commands.
+
+The dirannex remote is a local directory remote.
+
+```
+get 74/024842a88350573fa70e33f6dea9d274.jpg (from web...) ok
+get 74/02c67a1850ee54848d0203c48a613d74.jpg (from dirannex...) ok
+get 75/024b4a9e700c51aeb9a51d7566a19c75.jpg (transfer already in progress, or unable to take transfer lock) 
+  Unable to access these remotes: web
+
+  Try making some of these repositories available:
+        00000000-0000-0000-0000-000000000001 -- web
+failed
+```
+
+```
+git-annex copy -J5 --to dirannex
+<snip>
+(transfer already in progress, or unable to take transfer lock) failed
+git-annex: copy: 5 failed
+```
+
+
+
+"""]]
diff --git a/doc/forum/Matching_options_not_working_in_windows_7.mdwn b/doc/forum/Matching_options_not_working_in_windows_7.mdwn
new file mode 100644
index 0000000000..14db45ae4d
--- /dev/null
+++ b/doc/forum/Matching_options_not_working_in_windows_7.mdwn
@@ -0,0 +1,18 @@
+Hi there,
+
+I'm trying to set up a new git-annex repo. I want to use the WORM backend for files larger than 200MB.
+So I use the following command when adding files:
+
+    git annex add --largerthan=200MB --backend=WORM .
+
+But this does not seem to work. No files are added. I tried several variants of the command like:
+
+    git annex add --largerthan 200MB --backend=WORM .
+    git annex add --largerthan "200 MB" --backend=WORM .
+
+Do not work also. Am I missing anything?
+
+I'm using **Git 2.28.0.windows.1** and **git-annex 8.20200815-g335aae266** on a newly-created repository in an NTFS partition.
+I used the following command to initialize the repo:
+
+    git init && git annex init
diff --git a/doc/forum/Matching_options_not_working_in_windows_7/comment_1_616f6c6d26088207ce9c044f4b61eec5._comment b/doc/forum/Matching_options_not_working_in_windows_7/comment_1_616f6c6d26088207ce9c044f4b61eec5._comment
new file mode 100644
index 0000000000..61358d859f
--- /dev/null
+++ b/doc/forum/Matching_options_not_working_in_windows_7/comment_1_616f6c6d26088207ce9c044f4b61eec5._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-10-19T18:59:30Z"
+ content="""
+Lucky for you, I tried it on linux, and it also fails there.
+
+I think the problem is, --largerthan and --smallerthan only work on annexed
+files, not on files you want to add to the annex. This is probably a bug.
+
+What does work is to configure annex.largefiles and disable
+annex.addsmallfiles:
+
+git config annex.largefiles 'largerthan=200mb'
+git config annex.addsmallfiles false
+"""]]
diff --git a/doc/forum/Matching_options_not_working_in_windows_7/comment_2_b0319c1214c26f64058eb9c38ef6fb0d._comment b/doc/forum/Matching_options_not_working_in_windows_7/comment_2_b0319c1214c26f64058eb9c38ef6fb0d._comment
new file mode 100644
index 0000000000..47f7f691a1
--- /dev/null
+++ b/doc/forum/Matching_options_not_working_in_windows_7/comment_2_b0319c1214c26f64058eb9c38ef6fb0d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-10-19T19:12:25Z"
+ content="""
+Opened a bug, [[bugs/add_--largerthan_reversion]]
+"""]]
diff --git a/doc/forum/Matching_options_not_working_in_windows_7/comment_3_d834a6cb0ae1bd47e5280b10ecbaa72d._comment b/doc/forum/Matching_options_not_working_in_windows_7/comment_3_d834a6cb0ae1bd47e5280b10ecbaa72d._comment
new file mode 100644
index 0000000000..39e329445f
--- /dev/null
+++ b/doc/forum/Matching_options_not_working_in_windows_7/comment_3_d834a6cb0ae1bd47e5280b10ecbaa72d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="ericm"
+ avatar="http://cdn.libravatar.org/avatar/67ca64c5a99fb142fc2e3916333881ca"
+ subject="comment 3"
+ date="2020-10-20T13:45:09Z"
+ content="""
+This worked for me:
+
+    git -c annex.largefiles=largerthan=200mb -c annex.addsmallfiles=false annex add --backend=WORM .
+
+Then this adds the remaining files:
+
+    git annex add .
+
+Thanks for the help!
+"""]]
diff --git a/doc/forum/MegaAnnex_not_working.mdwn b/doc/forum/MegaAnnex_not_working.mdwn
new file mode 100644
index 0000000000..3eff4b7414
--- /dev/null
+++ b/doc/forum/MegaAnnex_not_working.mdwn
@@ -0,0 +1,32 @@
+When copying to a megaannex remote, it hangs after a while, and I get this:
+
+    copy Boomarks/Android (gpg) Traceback (most recent call last):
+      File "/usr/local/bin//git-annex-remote-mega", line 511, in <module>
+        common.startRemote()
+      File "/home/zack/megaannex/lib/CommonFunctions.py", line 557, in startRemote
+        sys.modules["__main__"].checkpresent(line)
+      File "/usr/local/bin//git-annex-remote-mega", line 483, in checkpresent
+        folder = setFolder(conf["folder"], common.ask("DIRHASH " + line[1]))
+      File "/usr/local/bin//git-annex-remote-mega", line 401, in setFolder
+        folder = createFolder(conf["folder"], 2)
+      File "/usr/local/bin//git-annex-remote-mega", line 378, in createFolder
+        res = m.create_folder(subject, folder)
+      File "/usr/lib/python2.7/site-packages/mega/mega.py", line 617, in create_folder
+        'i': self.request_id})
+      File "/usr/lib/python2.7/site-packages/mega/mega.py", line 110, in _api_request
+        timeout=self.timeout)
+      File "/usr/lib/python2.7/site-packages/requests/api.py", line 88, in post
+        return request('post', url, data=data, **kwargs)
+      File "/usr/lib/python2.7/site-packages/requests/api.py", line 44, in request
+        return session.request(method=method, url=url, **kwargs)
+      File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 354, in request
+        resp = self.send(prep, **send_kwargs)
+      File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 460, in send
+        r = adapter.send(request, **kwargs)
+      File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 250, in send
+        raise SSLError(e)
+    requests.exceptions.SSLError: The read operation timed out
+    (external special remote protocol error, unexpectedly received "" (unable to parse command)) failed
+
+
+Any help would be appreciated, thanks!
diff --git a/doc/forum/MegaAnnex_not_working/comment_1_5aa3fd366d4c78ca79bb58005a49791c._comment b/doc/forum/MegaAnnex_not_working/comment_1_5aa3fd366d4c78ca79bb58005a49791c._comment
new file mode 100644
index 0000000000..c2e7353dbc
--- /dev/null
+++ b/doc/forum/MegaAnnex_not_working/comment_1_5aa3fd366d4c78ca79bb58005a49791c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-11T19:42:24Z"
+ content="""
+This looks to me like the connection to Mega fails, so either they have a server down, or a network problem, or perhaps the API that the megaannex remote was relying on might have been removed..
+"""]]
diff --git a/doc/forum/MegaAnnex_not_working/comment_2_f3eaf1ee06ebac951514d865f298f9d3._comment b/doc/forum/MegaAnnex_not_working/comment_2_f3eaf1ee06ebac951514d865f298f9d3._comment
new file mode 100644
index 0000000000..e9fd01f147
--- /dev/null
+++ b/doc/forum/MegaAnnex_not_working/comment_2_f3eaf1ee06ebac951514d865f298f9d3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqaNwDQ367zpW6cIRviLz6zJZZFODgoEI"
+ nickname="Zack"
+ subject="comment 2"
+ date="2014-07-19T12:48:08Z"
+ content="""
+I believe it may have been removed, unfortunately. :(
+"""]]
diff --git a/doc/forum/Merging_two_git-annex_repositories_together__63__.mdwn b/doc/forum/Merging_two_git-annex_repositories_together__63__.mdwn
new file mode 100644
index 0000000000..fb3c9d01ed
--- /dev/null
+++ b/doc/forum/Merging_two_git-annex_repositories_together__63__.mdwn
@@ -0,0 +1,7 @@
+Hello!
+
+I’ve got two repos, both are using git-annex.
+
+Can I somehow merge them together, into one?
+
+Thank you!
diff --git a/doc/forum/Merging_two_git-annex_repositories_together__63__/comment_1_b96bb95cdbbc78c0b4b348861e2264bd._comment b/doc/forum/Merging_two_git-annex_repositories_together__63__/comment_1_b96bb95cdbbc78c0b4b348861e2264bd._comment
new file mode 100644
index 0000000000..46be89f739
--- /dev/null
+++ b/doc/forum/Merging_two_git-annex_repositories_together__63__/comment_1_b96bb95cdbbc78c0b4b348861e2264bd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="openmedi"
+ avatar="http://cdn.libravatar.org/avatar/563ffaff3b492c579bd8f094472e4506"
+ subject="comment 1"
+ date="2017-02-25T20:35:52Z"
+ content="""
+I think you could add those two repositories as remotes of each other and merge them with the `--allow-unrelated-histories` option. But I'm not sure if this is a good idea, or not. But some googling in that direction might yield some useful information. Good luck!
+"""]]
diff --git a/doc/forum/Merging_two_git-annex_repositories_together__63__/comment_2_539a33b268be5c6954f3112d89dd34ef._comment b/doc/forum/Merging_two_git-annex_repositories_together__63__/comment_2_539a33b268be5c6954f3112d89dd34ef._comment
new file mode 100644
index 0000000000..5059bc45df
--- /dev/null
+++ b/doc/forum/Merging_two_git-annex_repositories_together__63__/comment_2_539a33b268be5c6954f3112d89dd34ef._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 2"
+ date="2017-02-26T00:59:21Z"
+ content="""
+No, actually everything just works. ♥
+
+It’s amazing! Thank you!
+"""]]
diff --git a/doc/forum/Messed_up_repo_by_syncing_to_wrong_remote.mdwn b/doc/forum/Messed_up_repo_by_syncing_to_wrong_remote.mdwn
new file mode 100644
index 0000000000..2521ec6251
--- /dev/null
+++ b/doc/forum/Messed_up_repo_by_syncing_to_wrong_remote.mdwn
@@ -0,0 +1,40 @@
+I screwed up my (pretty urgently-needed) git-annex repo by adding a completely wrong remote (like, an entirely different git directory) and then doing "git annex sync [name]"
+
+The repos in question:
+
+
+    /foo/good   -   A repo on a hard drive
+    /bar/good   -   The same repo on my local computer
+    /bar/bad    -   An entirely unrelated repo on my local computer
+
+What I did was basically:
+
+    cd /bar
+    git clone /foo/good
+    cd good
+    git annex init bar
+    cd /foo/good
+    git remote add bar /bar/bad   # BAD!
+    git annex sync bar
+
+This pulled in the entire history of this 100% unrelated git repo. I realize what I've done, do "git reflog" and find the last good commit, and:
+
+    git reset --hard [last-good-commit]
+    git status
+    git fsck
+    git annex fsck
+    git log
+
+Everything looks normal.
+
+Then I:
+
+    git remote remove bar
+    git remote add bar /bar/good
+    git annex sync bar
+
+And I get the whole /bar/bad repo's history again!
+
+There are lots of other weird things I've encountered now I'm in this state, but to keep this as simple as I can: what should I do in this situation?!
+
+Thank you!!
diff --git a/doc/forum/Messed_up_repo_by_syncing_to_wrong_remote/comment_1_d1358e46d488532e1922a1bf7c471980._comment b/doc/forum/Messed_up_repo_by_syncing_to_wrong_remote/comment_1_d1358e46d488532e1922a1bf7c471980._comment
new file mode 100644
index 0000000000..53ba6e96a1
--- /dev/null
+++ b/doc/forum/Messed_up_repo_by_syncing_to_wrong_remote/comment_1_d1358e46d488532e1922a1bf7c471980._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2019-03-13T08:33:37Z"
+ content="""
+1) Delete the incorrect remote and any local branches it has created
+2) Revert branches to commits before the sync (including the git-annex branch)
+3) Delete .git/annex/index (safe to do so, git-annex will rebuild it)
+4) Make sure .git/annex/journal is empty
+
+It's been a while since I've needed to do this, but I think that covers everything needed. I'm in the IRC channel (GMT/BST waking hours) if you need any further help!
+"""]]
diff --git a/doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another.mdwn b/doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another.mdwn
new file mode 100644
index 0000000000..ac06b99900
--- /dev/null
+++ b/doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another.mdwn
@@ -0,0 +1,44 @@
+Hi there,
+
+I want to migrate from git-annex-remote-hubic to git-annex-remote-rclone to access the same hubic remote, same container, same data. So ideally I just want to switch to rclone but reuse the old content (since uploading to hubic is so sloooooow). 
+
+My old remote is called hubic, my new one hubic2 in my git annex repo.
+Both are reported as similar by git annex info -F hubic/hubic2 :
+
+    remote: hubic
+    description: [hubic]
+    uuid: 396e481c-5fc9-4933-b6a4-b1398fb7c61b
+    trust: trusted
+    cost: 225.0
+    type: external
+    externaltype: hubic
+    encryption: pubkey (to gpg keys: XXX)
+    chunking: none
+
+    remote: hubic2
+    description: [hubic2]
+    uuid: adaea02d-920c-48fa-811d-c27e51bda85f
+    trust: semitrusted
+    cost: 250.0
+    type: external
+    externaltype: rclone
+    encryption: pubkey (to gpg keys: XXX)
+    chunking: none
+
+Yes, the GPG key is the same. I only have one configured on this machine.
+
+However, when I fsck for a file that is on hubic or on hubic2 I only get a positive result for hubic. The chatlogs of both fsck reveal that the key that fsck is looking for is different for the different remotes.
+ 
+    git-annex-remote-hubic[1] <-- CHECKPRESENT GPGHMACSHA1--64e155e3010f69e909e629c6d9fdacae5c0c3bef
+respectively:
+
+    git-annex-remote-rclone[1] <-- CHECKPRESENT GPGHMACSHA1--5cf9edd1a413c561775f8920fc7b21410be6c5a4
+
+There is one thing I noticed though:
+Although in the remote-hubic case I have not chunking configured, I see with *rclone lsl* that I have some files in chunks up there.
+However, the file I am using for this test is only 2MB and it is not chunked on the remote.
+
+What am I missing, what am I doing wrong? While writing this I thought of the following: Is there an intermediate key used for the actual encryption or for the encryption of the filenames? If yes how can I access it or make it available to the new remote?
+
+Thanks,
+Marek
diff --git a/doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another/comment_1_6e8e3350ae26b6c59daa56b7e86cc46a._comment b/doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another/comment_1_6e8e3350ae26b6c59daa56b7e86cc46a._comment
new file mode 100644
index 0000000000..e3a63b3f91
--- /dev/null
+++ b/doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another/comment_1_6e8e3350ae26b6c59daa56b7e86cc46a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-05-30T15:21:57Z"
+ content="""
+Yes, there is an intermediate encryption key.
+
+What may work is to use `git annex enableremote` on the original remote
+with `externaltype=rclone`, which will make it use the other program.
+
+Whether this will work depends on implementation details of both special
+remotes. If they use the same names/urls/whatever to access the data stored
+in them, it should work.
+"""]]
diff --git a/doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another/comment_2_db4b772371ee49c743605c728e23c91a._comment b/doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another/comment_2_db4b772371ee49c743605c728e23c91a._comment
new file mode 100644
index 0000000000..36fccdd80f
--- /dev/null
+++ b/doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another/comment_2_db4b772371ee49c743605c728e23c91a._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="marek@33e8ba4fbc201af14a2badcc0656024401f5c916"
+ nickname="marek"
+ avatar="http://cdn.libravatar.org/avatar/65a60e8f5183feeeef8cef815bf73e61"
+ subject="Fixed a first problem and then ran into bigger problems"
+ date="2018-05-31T09:29:30Z"
+ content="""
+By using 
+    git show git-annex:remote.log
+
+one can extract the cipher from the old remote and set it with
+
+    git annex enableremote $newremote cipher=$CIPHER
+
+However, then I ran into a new problem. The git-annex-remote-hubic special remote created files with leading slashes (/GPGHMACSHA1--00021a41c3143f1e52f16af93625d1072e861543).
+Rclone, and I don`t even mean git-annex-remote-rclone, cannot access these files. It interprets the slash as directory separator which leads to those files not being found.
+
+I guess I will just reupload to fix the slash error in the first place. Or find a Hubic client that can deal with slashes and rename the objects remotely.
+"""]]
diff --git a/doc/forum/Migrate_mark_files_dead.mdwn b/doc/forum/Migrate_mark_files_dead.mdwn
new file mode 100644
index 0000000000..75af507c73
--- /dev/null
+++ b/doc/forum/Migrate_mark_files_dead.mdwn
@@ -0,0 +1,254 @@
+Through several migrations, and migrations leave duplicate files.
+
+The man page warns about this and tells to use `annex unused` to find them.
+I'd usually copy the new files around, drop the old ones and mark the old ones dead,
+but alas, manual things are not always done.
+
+To clean up after sloppy migrations,
+or after deciding that I really want to get rid of the old files,
+I'd like a tool to
+
+* find files that were migrated,
+* do some sanity checks,
+* drop them from all the remotes (with extreme prejudice, as even unused files are usually subject to numcopies), and
+* declare them dead (which can only happen once they're gone from all remotes).
+
+I've written a tool that does all these. It's available below (copy-paste; attachments seem to be disabled);
+see its head for documentation.
+This is a tool for forcibly dropping files,
+so use with the adaequate caution and at your own risk.
+
+Since, I can reclaim my disk space *and* run `git annex fsck --all` with good results again.
+
+--[[chrysn]]
+
+```python
+#!/usr/bin/env python3
+
+"""
+Perform in sequence, with a stops for confirmation before acting:
+
+* Enumerate files that were replaced with same-sized ones of different hashes;
+  these were probably migrated.
+* Show commits in which these happened. The user should verify these were all migrations.
+* Check that no to-be-dropped file are part of the current HEAD.
+* Run an fsck (without --all, just on the present files) to ensure that no
+  recent migrations created local-only files if local-only doesn't satisfy numcopies.
+* FORCE DROP THEM FROM ALL REMOTES.
+* Mark them dead.
+
+Marking files as dead will stop when a remote is encountered that has a copy
+but is not accessible; this is a consequence of `dead` not working while known
+copies are around.
+
+This is not tuned for performance; it tries to avoid any O(n^2) or worse
+behavior, and should complete data acquisition (or at least produce output)
+within minutes even on a 150000 file, 1000 commit repository. (The slowest
+parts being the fsck and the enumeration of whereis data take the longest
+time).
+
+The actual dropping takes quite a while, as each drop and dead are done
+individually. (Some commands have --batch but not for --key). There are no
+checks to reduce work if files were already declared dead. To avoid cluttering
+the git-annex branch's history, the full run is rolled into a single commit.
+
+Warnings:
+
+Things like this are notoriously hard to run with a backup in place (because
+your backup probably *is* another git-annex from which files will be removed
+here); volume level snapshots can be helpful here, as they allow you to run
+things and evaluate the outcome while retaining a way to roll back.
+
+Use at your own risk.
+"""
+
+import json
+import os.path
+import stat
+import subprocess
+import sys
+from typing import Optional
+
+from dulwich import diff_tree, walk
+from dulwich.repo import Repo
+
+if not __debug__:
+    raise RuntimeError("I'm using asserts for validation here, please don't make me rewrite them to ifs")
+
+if not os.path.exists('.git'):
+    raise RuntimeError("Just to make sure the fsck catches everything, please run in an annex's root")
+
+repo = Repo('.')
+
+def hash_from_link(link: bytes) -> str:
+    """Return the hash of a git-annex link if a link looks like one"""
+    if b'/.git/annex/' not in link:
+        return
+    link = link.decode('utf8') # whoever uses non-UTF8 file extensions won't have my pity
+    link = link.lstrip('./')
+    link = link.removeprefix('git/annex/objects/')
+    if link.count('/') > 1:
+        # newer XX/YY/hash/hash scheme
+        link = link[6:]
+    dirname, _, filename = link.partition('/')
+    assert dirname == filename
+    return filename
+
+def parse_hash(h: str) -> (str, Optional[int], str):
+    """Given a hash, the hash algorithm, the file size if indicated, and the hash value"""
+    if ':' in h: # hoping it never shows up in an extension
+        # old style
+        halg, hval = h.split(':', 1)
+        return (halg, None, hval)
+    halg_params, _, hval = h.partition('--')
+    size = None
+    halg, *params = halg_params.split('-')
+    for p in params:
+        if p[0] == 's':
+            size = int(p[1:])
+        else:
+            raise ValueError("Unknown extension: %s" % p)
+    # hval may need trimming still for extensions
+    return (halg, size, hval)
+
+# Commits in which migrations happened, mapped to set of all reasons found there
+migrating_commits = {}
+
+# Old / migrated hashes that are to be removed
+hashes_to_kill = set()
+
+seen_commits = set()
+new_commits = {repo.head(),}
+while new_commits:
+    current_commits = new_commits
+    seen_commits = seen_commits.union(current_commits)
+    new_commits = set()
+    for c in current_commits:
+        c = repo[c]
+
+        new_commits = new_commits.union(c.parents)
+
+        if len(c.parents) != 1:
+            # Not expecting any migrations in merge commits
+            continue
+
+        for (eold, enew) in diff_tree.walk_trees(repo, repo[c.parents[0]].tree, c.tree, True):
+            if eold.sha == enew.sha:
+                continue
+            if eold.mode != stat.S_IFLNK or enew.mode != stat.S_IFLNK:
+                continue
+            old_full = hash_from_link(repo[eold.sha].data)
+            new_full = hash_from_link(repo[enew.sha].data)
+            if old_full is None or new_full is None:
+                continue # was not a git-annex link
+            old_hash, old_len, old_hashval = parse_hash(old_full)
+            new_hash, new_len, new_hashval = parse_hash(new_full)
+
+            if (old_hash, old_len, old_hashval) == (new_hash, new_len, new_hashval):
+                migration_type = "git annex version upgrade"
+                assert ':' in old_full, "Well what else could it be?"
+                # While they were migrations, git-annex really has made sure
+                # they got carried over; modern git annex operations don't even
+                # work on them any more
+                continue
+            elif (old_hash, old_hashval) == (new_hash, new_hashval) and \
+                    old_len is None and new_len is not None:
+                migration_type = "Length added"
+            elif old_hash != new_hash and \
+                    (old_len is None or old_len == new_len):
+                migration_type = "Hash change from %s to %s" % (old_hash, new_hash)
+            else:
+                print("Spurious migration", old_full, new_full)
+                print((old_hash, old_len, old_hashval))
+                print((new_hash, new_len, new_hashval))
+                raise RuntimeError("Not understanding this migration, exiting")
+
+            assert old_full != new_full, "We don't want to drop still in used keys, and these should have been caught before"
+
+            hashes_to_kill.add(old_full)
+
+            migrating_commits.setdefault(c, set()).add(migration_type)
+
+    new_commits = new_commits.difference(seen_commits)
+
+print("These commits were found to have migrations:\n")
+for (commit, reasons) in sorted(migrating_commits.items(), key=lambda cr: cr[0].commit_time):
+    print("Author:", commit.author.decode('utf8'))
+    print(commit.message.decode('utf8').strip())
+    print("Migrations:", ", ".join(reasons))
+    print()
+
+print("Hashes that were migrated away from: %d" % len(hashes_to_kill))
+
+# a real tree and not a digraph, so easier than the commit walking
+files_checked = 0
+bad_files = []
+trees_to_check = [repo[repo.head()].tree]
+while trees_to_check:
+    old_trees = trees_to_check
+    trees_to_check = []
+    for t in list(old_trees):
+        for item in repo[t].items():
+            if item.mode == stat.S_IFDIR:
+                trees_to_check.append(item.sha)
+            if item.mode == stat.S_IFLNK:
+                link = repo[item.sha].data
+                full = hash_from_link(link)
+                if full in hashes_to_kill:
+                    bad_files.append(item.path)
+                files_checked += 1
+if bad_files:
+    print("Some hashes that have been migrated away from were still around, files with these names:")
+    print(bad_files)
+    sys.exit(1)
+print("Checked %d symlinks in HEAD, none of them points to an old hash any more" % files_checked)
+
+print("performing a non-`--all` fsck...")
+subprocess.check_call('git annex fsck --fast --quiet', shell=True)
+print("Checked that the files that *are* in the tree are properly distributed.")
+
+print("Gathering whereis data to decide where to drop from...")
+whereall = subprocess.Popen(['git', 'annex', 'whereis', '--json', '--all'], stdout=subprocess.PIPE)
+hashes_to_kill_remotes = {}
+for line in whereall.stdout:
+    wherethis = json.loads(line)
+    if wherethis['key'] not in hashes_to_kill:
+        continue
+
+    remotes = {None if r['here'] else r['uuid'] for r in wherethis['whereis'] + wherethis['untrusted']}
+    if remotes:
+        hashes_to_kill_remotes[wherethis['key']] = remotes
+if hashes_to_kill_remotes:
+    wheretodrop = {r or "here" for r in set.union(*hashes_to_kill_remotes.values())}
+else:
+    wheretodrop = set()
+print(f"Found {len(hashes_to_kill_remotes)} migrated hashes still around on remotes {wheretodrop}")
+
+print()
+print("If you want to really drop all of them, enter `force drop and declare them dead` here:")
+line = input()
+if line != "force drop and declare them dead":
+    print("Good choice. (Sorry if you mistyped...)")
+    sys.exit(0)
+
+try:
+    subprocess.check_call(["git", "-c", "annex.commitmessage=updates before running migrate-mark-dead.py", "annex", "merge"])
+    annex_no_autocommit = ["git", "-c", "annex.alwayscommit=false", "annex"]
+    # Network first, to ensure the password prompts come fast even when most files are dead already
+    for (i, (key, remotes)) in enumerate(hashes_to_kill_remotes.items()):
+        for r in remotes:
+            if r is None:
+                # Can't be run with `--from here`
+                subprocess.check_call(annex_no_autocommit + ['drop', '--force', '--key', key])
+            else:
+                subprocess.check_call(annex_no_autocommit + ['drop', '--force', '--key', key, '--from', r])
+
+        if (i % 10 == 0):
+            print(f"Dropped {i} ({100 * i/len(hashes_to_kill_remotes):.1f}% of) present hashes")
+    for i, key in enumerate(hashes_to_kill):
+        subprocess.check_call(annex_no_autocommit + ['dead', '--key', key])
+        if (i % 100 == 0):
+            print(f"Marked {i} ({100 * i/len(hashes_to_kill):.1f}% of) unused hashes as dead")
+finally:
+    subprocess.check_call(["git", "-c", "annex.commitmessage=ran migrate-mark-dead.py", "annex", "merge"])
+```
diff --git a/doc/forum/Migrate_mark_files_dead/comment_1_fa155c961d5aecbe055f67d8ace0c208._comment b/doc/forum/Migrate_mark_files_dead/comment_1_fa155c961d5aecbe055f67d8ace0c208._comment
new file mode 100644
index 0000000000..9130f8c0c5
--- /dev/null
+++ b/doc/forum/Migrate_mark_files_dead/comment_1_fa155c961d5aecbe055f67d8ace0c208._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="annex-to-annex"
+ date="2021-08-13T22:08:57Z"
+ content="""
+[annex-to-annex](https://manpages.debian.org/buster-backports/libgit-annex-perl/annex-to-annex.1p.en.html) does something similar.
+"""]]
diff --git a/doc/forum/Migrate_mark_files_dead/comment_2_a4512fb8a59f3a4d4ee85651a979f00f._comment b/doc/forum/Migrate_mark_files_dead/comment_2_a4512fb8a59f3a4d4ee85651a979f00f._comment
new file mode 100644
index 0000000000..79f5494cb9
--- /dev/null
+++ b/doc/forum/Migrate_mark_files_dead/comment_2_a4512fb8a59f3a4d4ee85651a979f00f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="annex-to-annex"
+ date="2021-08-15T11:47:30Z"
+ content="""
+Thanks for the pointer, I was unaware of that tool. Indeed for local-only repositories, annex-to-annex avoids these troubles altogether. I suppose that with remotes, running annex-to-annex on all of them in a coordinated fashion does too.
+
+IIUC, the annex-to-annex-dropunused tool does similar cleanup to this, provided annex-to-annex was used in the first place. It seems not to mark these files as dead, so a `git annex fsck --all` will from thereon fail.
+"""]]
diff --git a/doc/forum/Migrate_mark_files_dead/comment_3_a10dbdd505742d5cf03fd435e206d9a2._comment b/doc/forum/Migrate_mark_files_dead/comment_3_a10dbdd505742d5cf03fd435e206d9a2._comment
new file mode 100644
index 0000000000..54777f5f4b
--- /dev/null
+++ b/doc/forum/Migrate_mark_files_dead/comment_3_a10dbdd505742d5cf03fd435e206d9a2._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-08-24T16:47:31Z"
+ content="""
+A change in git-annex 8.20210630 is relevant to this discussion:
+
+	  * Dropping an unused object with drop --unused or dropunused will
+	    mark it as dead, preventing fsck --all from complaining about it
+	    after it's been dropped from all repositories.
+
+So, you should not need to remember to mark files as dead. Just cleaning
+up from the migration once will suffice. Of course, you'll still need to do
+whatever dropping of the unused content from remotes you want to do.
+"""]]
diff --git a/doc/forum/Missing_git-annex.linux__47__runshell.mdwn b/doc/forum/Missing_git-annex.linux__47__runshell.mdwn
new file mode 100644
index 0000000000..3ad7e85c13
--- /dev/null
+++ b/doc/forum/Missing_git-annex.linux__47__runshell.mdwn
@@ -0,0 +1,44 @@
+Hi,
+
+I've said up two clients to sync locally as well as over ssh-rsync.
+
+However, locally one client is complaining about missing `runshell` at a location where `git annex` is not installed.  The log is below.  On the assistent overview it just says "unfinished repository".  Note that I am able to ssh into the other machine and from the other machine I'm also able to ssh into this machine.
+
+
+I'm using the latest prebuild binary package (git-annex-bin at Archlinux AUR).  So my `git annex` setup contains 
+
+    $> pacman -Ql git-annex-bin 
+    git-annex-bin /usr/
+    git-annex-bin /usr/bin/
+    git-annex-bin /usr/bin/git-annex
+    git-annex-bin /usr/bin/git-annex-shell
+
+    $> pacman -Qi git-annex-bin # with chops
+    Name           : git-annex-bin
+    Version        : 4.20130909-1
+    Description    : Precompiled version of git-annex, webapp and assistant
+    included.
+    Architecture   : x86_64
+
+Here is a log of one event where it fails to transfer.  
+
+    [2013-09-28 18:06:38 CEST] TransferScanner: queued Upload NoUUID config/emacs.d/ac-l-dict/amsmath-c-a-* Nothing : expensive scan found missing object
+    [2013-09-28 18:06:38 CEST] Transferrer: Transferring: Upload NoUUID config/dotfiles/stardict/dic/stardict-oxford-2.4.2/oxford.ifo Nothing
+    [2013-09-28 18:06:38 CEST] call: git-annex ["transferkeys","--readfd","96","--writefd","94"]
+    [2013-09-28 18:06:38 CEST] read: git ["--git-dir=/home/rasmus/annex/.git","--work-tree=/home/rasmus/annex","show-ref","git-annex"]
+    [2013-09-28 18:06:38 CEST] read: git ["--git-dir=/home/rasmus/annex/.git","--work-tree=/home/rasmus/annex","show-ref","--hash","refs/heads/git-annex"]
+    [2013-09-28 18:06:38 CEST] read: git ["--git-dir=/home/rasmus/annex/.git","--work-tree=/home/rasmus/annex[","log2","0r1e3f-s/0h9e-ad2s8/ g1i8t-annex..90df78a0910a6f2998655e6:06:38 CEST] 127.0.0.1 GET /transfers/NotificationId%201 Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 Aurora/26.0a2
+    ea47d478ea0589b54","--oneline","-n1"]
+    [2013-09-28 18:06:38 CEST] read: git ["--git-dir=/home/rasmus/annex/.git","--work-tree=/home/rasmus/annex","log","refs/heads/git-annex..5f6870ed24e5ded1764765bbfef2b85aff046569","--oneline","-n1"]
+    [2013-09-28 18:06:38 CEST] chat: git ["--git-dir=/home/rasmus/annex/.git","--work-tree=/home/rasmus/annex","cat-file","--batch"]
+    [2013-09-28 18:06:38 CEST] read: ssh ["-S","/home/rasmus/annex/.git/annex/ssh/00b8ef4cb08290718ba625d9bd86ca0b","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","rasmus@git-annex-192.168.1.107-rasmus_annex","git-annex-shell 'configlist' '/~/annex/'"]
+    /home/rasmus/.ssh/git-annex-shell: line 4: /opt/git-annex.linux/runshell: No such file or directory
+    [2013-09-28 18:06:38 CEST] call: git ["--git-dir=/home/rasmus/annex/.git","--work-tree=/home/rasmus/annex","fetch","--quiet","192.168.1.107_annex"]
+    [2013-09-28 18:06:38 CEST] 127.0.0.1 GET /transfers/NotificationId%201 Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 Aurora/26.0a2
+    [2013-09-28 18:06:38 CEST] 127.0.0.1 GET /log Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 Aurora/26.0a2
+    /home/rasmus/.ssh/git-annex-shell: line 4: /opt/git-annex.linux/runshell: No such file or directory
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+    git-annex: Unknown UUID
diff --git a/doc/forum/Missing_git-annex.linux__47__runshell/comment_1_f29a5105649579ef15e79d983c4e1f8e._comment b/doc/forum/Missing_git-annex.linux__47__runshell/comment_1_f29a5105649579ef15e79d983c4e1f8e._comment
new file mode 100644
index 0000000000..a10c4aaf0f
--- /dev/null
+++ b/doc/forum/Missing_git-annex.linux__47__runshell/comment_1_f29a5105649579ef15e79d983c4e1f8e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.80"
+ subject="comment 1"
+ date="2013-09-30T16:08:40Z"
+ content="""
+You apparently at one point installed git-annex from the prebuilt tarball, in `/opt/git-annex.linux/`. It set up a ~/.ssh/git-annex-shell that points to this location. If you no longer have it installed that way, you can remove that file.
+"""]]
diff --git a/doc/forum/Mixed_content_repos_with_import_and_export.mdwn b/doc/forum/Mixed_content_repos_with_import_and_export.mdwn
new file mode 100644
index 0000000000..02d2e3d6f1
--- /dev/null
+++ b/doc/forum/Mixed_content_repos_with_import_and_export.mdwn
@@ -0,0 +1,7 @@
+Is it possible to get mixed content repositories working in conjunction with a directory special remote using importtree/exporttree?
+
+`git annex add` adheres to the `annex.largefiles` setting (`mimetype=text/*`), but importing or syncing from the remote invariably adds text files to the annex, including if the file was originally added to git and then modified on the remote.
+
+I want `annex.synccontent` set to `true` but have tried it both ways.
+
+What am I missing?
diff --git a/doc/forum/Mixed_content_repos_with_import_and_export/comment_1_0486a067491456d92220ca638e3095bf._comment b/doc/forum/Mixed_content_repos_with_import_and_export/comment_1_0486a067491456d92220ca638e3095bf._comment
new file mode 100644
index 0000000000..54ccaf060e
--- /dev/null
+++ b/doc/forum/Mixed_content_repos_with_import_and_export/comment_1_0486a067491456d92220ca638e3095bf._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-16T18:17:19Z"
+ content="""
+This is one of the still open items in [[todo/import_tree]],
+namely "Need to support annex.largefiles when importing"
+
+I don't think there's any major issue implementing it, other than it being
+a bit of bother due to things like matching on mime type. I've lifted that
+todo out to [[todo/import_tree_should_honor_annex.largefiles]] so hopefully
+it'll be more of an action item on my todo list rather than buried away.
+"""]]
diff --git a/doc/forum/Mixed_content_repos_with_import_and_export/comment_2_d0e73dbcf22704cf1c9af8a56533aebe._comment b/doc/forum/Mixed_content_repos_with_import_and_export/comment_2_d0e73dbcf22704cf1c9af8a56533aebe._comment
new file mode 100644
index 0000000000..8e1c2e4a32
--- /dev/null
+++ b/doc/forum/Mixed_content_repos_with_import_and_export/comment_2_d0e73dbcf22704cf1c9af8a56533aebe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 2"
+ date="2020-06-17T19:34:13Z"
+ content="""
+Thanks for your reply, Joey. I hadn't caught that it was an open todo, which of course explains it.
+
+This is the missing piece of the puzzle in a valued workflow of mine. After being constantly amazed by what git-annex enables me to do, it's about time I head over to Patreon to help see it realized (in due time, of course).
+"""]]
diff --git a/doc/forum/Mixed_content_repos_with_import_and_export/comment_3_d15b0e5a034deeac85806790e53aefaf._comment b/doc/forum/Mixed_content_repos_with_import_and_export/comment_3_d15b0e5a034deeac85806790e53aefaf._comment
new file mode 100644
index 0000000000..e38f53454e
--- /dev/null
+++ b/doc/forum/Mixed_content_repos_with_import_and_export/comment_3_d15b0e5a034deeac85806790e53aefaf._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-06-23T19:38:10Z"
+ content="""
+Good news, it's implemented, will be in the daily builds soon and the next
+release. 
+
+Also you sponsored the [[day's work on it|devblog/day_625__import_tree_largefiles]] --
+thanks for the Patreon support!
+"""]]
diff --git a/doc/forum/Mixed_content_repos_with_import_and_export/comment_4_3f7d0f8d1a48d60612aa8477e32fb6f1._comment b/doc/forum/Mixed_content_repos_with_import_and_export/comment_4_3f7d0f8d1a48d60612aa8477e32fb6f1._comment
new file mode 100644
index 0000000000..fcef479263
--- /dev/null
+++ b/doc/forum/Mixed_content_repos_with_import_and_export/comment_4_3f7d0f8d1a48d60612aa8477e32fb6f1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 4"
+ date="2020-06-24T22:37:46Z"
+ content="""
+Nicely done Joey, that's quite a treat! As a further token of appreciation, I'll sponsor another day's work before having to settle on a level more sustainable for me.
+"""]]
diff --git a/doc/forum/Mixed_content_repos_with_import_and_export/comment_5_9f11132002d2fee9917e91a7b80a94b3._comment b/doc/forum/Mixed_content_repos_with_import_and_export/comment_5_9f11132002d2fee9917e91a7b80a94b3._comment
new file mode 100644
index 0000000000..3e97d977fc
--- /dev/null
+++ b/doc/forum/Mixed_content_repos_with_import_and_export/comment_5_9f11132002d2fee9917e91a7b80a94b3._comment
@@ -0,0 +1,84 @@
+[[!comment format=mdwn
+ username="amerlyq+annex@12121d70a602f094228689a0a24d348d478a8af1"
+ nickname="amerlyq+annex"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="adb special remote"
+ date="2020-12-21T06:36:32Z"
+ content="""
+Does fixed \"largefiles\" currently works only for \"directory\" remote? 
+What about \"adb\"? Or the next problem is the general one?
+
+    # [How-To Reproduce]: git-annex version: 8.20201127-gdad8442572
+    cd /tmp
+    mkdir books
+    cd books
+    git init .
+    git config --local user.name annex
+    git config --local user.email test
+    
+    git annex init test
+    git annex config --set annex.largefiles 'not mimetype=text/*'
+    
+    echo hello > README.rst
+    git add README.rst
+    git commit -m init
+    
+    mkdir new old
+    for f in old/1 old/2 new/3 new/4; do (head -c100 /dev/zero;echo $f) > $f; done
+    git annex add
+    git commit -m annex
+    
+    git-annex initremote android type=adb androiddirectory=/storage/0000-0000/books encryption=none exporttree=yes importtree=yes
+    git config remote.android.annex-tracking-branch master
+
+
+Syncing twice will result in replacing \"git\" file by \"annexed\" one.
+Moreover, it will be using SHA1 instead of default SHA256E (and totally ignore annex.backend option), which is confusing.
+
+    $ git annex sync --content
+    commit
+    On branch master
+    nothing to commit, working tree clean
+    ok
+    list android ok
+    update refs/remotes/android/master ok
+    
+    Already up to date!
+    Merge made by the 'recursive' strategy.
+    export android README.rst
+    /tmp/amer/export140847-1: 1 file pushed, 0 skipped. 0.1 MB/s (6 bytes in 0.000s)
+    ok
+    export android new/3
+    .git/annex/objects/kJ/Q4/SHA256E-s106--29...0 skipped. 1.3 MB/s (106 bytes in 0.000s)
+    ok
+    export android new/4
+    .git/annex/objects/5X/pv/SHA256E-s106--be...0 skipped. 1.9 MB/s (106 bytes in 0.000s)
+    ok
+    export android old/1
+    .git/annex/objects/1k/J6/SHA256E-s106--d5...0 skipped. 2.3 MB/s (106 bytes in 0.000s)
+    ok
+    export android old/2
+    .git/annex/objects/Gw/31/SHA256E-s106--52...0 skipped. 1.7 MB/s (106 bytes in 0.000s)
+    ok
+    (recording state in git...)
+    
+    $ git annex sync --content
+    commit
+    On branch master
+    nothing to commit, working tree clean
+    ok
+    list android ok
+    update refs/remotes/android/master ok
+    
+    Updating 803974d..f340cca
+    Fast-forward
+    README.rst | 2 +-
+    1 file changed, 1 insertion(+), 1 deletion(-)
+    mode change 100644 => 120000 README.rst
+    (recording state in git...)
+    
+    $ readlink README.rst
+    .git/annex/objects/gK/P3/SHA1--ce013625030ba8dba906f756967f9e9ca394464a/SHA1--ce013625030ba8dba906f756967f9e9ca394464a
+
+I seem not able to find related bug/todo/forum and can't wrap around my head what's going on here, assuming it was fixed.
+"""]]
diff --git a/doc/forum/Modification_time_of_files_retained_in_synchronized_remote_copies__63__.mdwn b/doc/forum/Modification_time_of_files_retained_in_synchronized_remote_copies__63__.mdwn
new file mode 100644
index 0000000000..3cd519a6db
--- /dev/null
+++ b/doc/forum/Modification_time_of_files_retained_in_synchronized_remote_copies__63__.mdwn
@@ -0,0 +1,5 @@
+I've noticed how, when files are synchronized/transferred from one repository (annex?) to another by the assistant, the files in the «remote» repository do no retain the modification time of the original files.
+From what I know git does not save file-specific metadata (ownership/timestamps/etc.).
+Since I've just started using git-annex, and I'd very much like for backup copies to retain the mtime of the originals, I would like to ask whether I am experiencing a malfunction or whether this is expected behaviour.
+
+Regards
diff --git a/doc/forum/Modification_time_of_files_retained_in_synchronized_remote_copies__63__/comment_1_2b13584998108af0522b898c5d396ba4._comment b/doc/forum/Modification_time_of_files_retained_in_synchronized_remote_copies__63__/comment_1_2b13584998108af0522b898c5d396ba4._comment
new file mode 100644
index 0000000000..1d5bf00a5f
--- /dev/null
+++ b/doc/forum/Modification_time_of_files_retained_in_synchronized_remote_copies__63__/comment_1_2b13584998108af0522b898c5d396ba4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="comment 1"
+ date="2014-09-19T21:31:23Z"
+ content="""
+I just saw your post and agree with you. Maybe we shall create a bug report. I would also need to keep my files in original timestamps. (may not mind about permissions though).
+"""]]
diff --git a/doc/forum/Modus_operandi_for_local_full_backup.mdwn b/doc/forum/Modus_operandi_for_local_full_backup.mdwn
new file mode 100644
index 0000000000..587c188529
--- /dev/null
+++ b/doc/forum/Modus_operandi_for_local_full_backup.mdwn
@@ -0,0 +1,20 @@
+Hello, 
+I've been for several hours soaking up on git annex and I don't see how to efficiently achieve the following. Your thoughts welcome.
+
+Let's say I have a computer with a main disk and a backup disk. I currently use rsnapshot to rsync from main to backup and take periodic snapshots. Once the backup disk is filled up I archive it and I start with a fresh one.
+
+This is neat but for the lack of intelligent history. I'm contemplating moving to a VCS solution so changes through time can be tracked more easily.
+
+Let's say I want to move to git-annex as a way of keeping history, maybe even across backup disks. The common part would be to rsync from main to backup and then commit. I see the following showstoppers:
+
+1) If I put the backup repo in direct mode, past versions of files are lost since they never enter either plain git nor annex control.
+
+2) If I put the backup repo in indirect mode, rsync destroys all soft links resulting in unnecessary copying over. It also seems to cause further breakage when a regular file appears where there was a symlink. I know no rsync option to sync through links to the target files (rsync -K only works for folders).
+
+3) I could put the repo in direct mode, rsync, commit, put in indirect to save versions, and repeat at every backup. Seems kinda inefficient, there are hundreds of gigas in files.
+
+4) I can't have the main disk under annex and use the back disk as a remote because the main disk contains many git repos (whose history I don't mind losing with rsync -C, or I wouldn't consider git-annex for backup at all). Also I'm not partial to populate the main disk with something only related to backup.
+
+If rsync -K worked with files there would be no problem. I'm missing the right flag here? Or something else that can be done on the git-annex side?
+
+Thanks in advance.
diff --git a/doc/forum/Modus_operandi_for_local_full_backup/comment_1_fa8ac55ebd94312a36b284047b6cf932._comment b/doc/forum/Modus_operandi_for_local_full_backup/comment_1_fa8ac55ebd94312a36b284047b6cf932._comment
new file mode 100644
index 0000000000..b6cc7e9896
--- /dev/null
+++ b/doc/forum/Modus_operandi_for_local_full_backup/comment_1_fa8ac55ebd94312a36b284047b6cf932._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="why use rsync at all?"
+ date="2015-11-11T01:13:00Z"
+ content="""
+i basically exclude git-annex repositories from my backups now. i have a `numcopies` setting to a satisfactory number (say 2 or 3) that ensures that there are at least 2 copies of every file. then i send copies off to external drives, when they are full, i create a new repository on a new drive.
+
+old versions are kept as long as you don't `dropunused`. 
+"""]]
diff --git a/doc/forum/Modus_operandi_for_local_full_backup/comment_2_fc2ac75608e91018f67c3753e9b09f76._comment b/doc/forum/Modus_operandi_for_local_full_backup/comment_2_fc2ac75608e91018f67c3753e9b09f76._comment
new file mode 100644
index 0000000000..5556f6697a
--- /dev/null
+++ b/doc/forum/Modus_operandi_for_local_full_backup/comment_2_fc2ac75608e91018f67c3753e9b09f76._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="alejandro@2e9e229fdf45d44cd300a5681432552693d458ab"
+ nickname="alejandro"
+ subject="comment 2"
+ date="2015-11-11T08:29:09Z"
+ content="""
+Hi anarcat, if I understand you correctly you're using method 4) in my original post. That is, having the source of backups as a git annex repo. However, all my readings on this site seem to indicate poor interaction with nested git repositories, that I would have. Isn't that so?
+"""]]
diff --git a/doc/forum/Modus_operandi_for_local_full_backup/comment_3_6089f53d8af5746f2a410d0214567943._comment b/doc/forum/Modus_operandi_for_local_full_backup/comment_3_6089f53d8af5746f2a410d0214567943._comment
new file mode 100644
index 0000000000..f388d57b85
--- /dev/null
+++ b/doc/forum/Modus_operandi_for_local_full_backup/comment_3_6089f53d8af5746f2a410d0214567943._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 3"
+ date="2015-11-11T14:53:11Z"
+ content="""
+that is so: git annex doesn't \"backup\" very well other git repositories. it's probably possible, but that's not really what git-annex is designed for. git-annex is [[not]] a backup system: it's more like an archival system. so if you want to backup your whole system and keep history, the [[not]] page recommends [[bup]], but i would also recommend [borg](http://borgbackup.readthedocs.org/).
+
+if you have git repos: backup those using your regular backup system, git-annex won't help you there. you can clone the repos using git, use rsync and whatnot. git itself keeps history and unless you royally mess up, git is pretty forgiving.
+
+for large files: create topical git-annex repositories. i have one for \"music\", \"video\", \"podcasts\", and so on. those are managed on a per-repo basis.
+
+so when i do my \"backups\" (which include \"archiving\" as well now), i connect the hard drives in my computer, run the `borg` (or `bup`) backup and then run `git annex sync --content` on all my git-annex repositories. that way new files in the git-annex repositories are synced to the external drive and files not managed by git-annex (yes, including non-git-annex git repos) are backed up as well.
+
+hope that helps
+"""]]
diff --git a/doc/forum/Modus_operandi_for_local_full_backup/comment_4_4c27aae1361465993fb60997bb0eadf8._comment b/doc/forum/Modus_operandi_for_local_full_backup/comment_4_4c27aae1361465993fb60997bb0eadf8._comment
new file mode 100644
index 0000000000..7daf4a7a23
--- /dev/null
+++ b/doc/forum/Modus_operandi_for_local_full_backup/comment_4_4c27aae1361465993fb60997bb0eadf8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="alejandro@2e9e229fdf45d44cd300a5681432552693d458ab"
+ nickname="alejandro"
+ subject="comment 4"
+ date="2015-11-11T15:22:05Z"
+ content="""
+I see, so your comments basically match my grasp on the situation. Thanks for the borg pointer, I have been reading on bup too and from posts in the mailing list I'm afraid it might not be mature enough for my particular use case.
+"""]]
diff --git a/doc/forum/Move_files_in_git_annex___40__direct_mode__41__.mdwn b/doc/forum/Move_files_in_git_annex___40__direct_mode__41__.mdwn
new file mode 100644
index 0000000000..7974a3e42f
--- /dev/null
+++ b/doc/forum/Move_files_in_git_annex___40__direct_mode__41__.mdwn
@@ -0,0 +1,22 @@
+Hi guys, I have a git annex repo under `/path`.
+
+I ran:
+
+```
+cd /path/subdir2
+mv ../subdir1/stuff* .
+git annex add
+git annex sync
+```
+
+Then I went to another repo (clone of the first) and did:
+
+```
+cd /paht1
+git annex sync
+git annex get .
+```
+
+Now I got the stuff from under `subdir2` in my second repo, just that the same stuff is also still under `subdir1` - how do I make git-annex aware of this change?
+
+Also, someone suggested running `git annex watch`
diff --git a/doc/forum/Move_files_in_git_annex___40__direct_mode__41__/comment_1_6426aca2296b5e03b333d5253ae7d88c._comment b/doc/forum/Move_files_in_git_annex___40__direct_mode__41__/comment_1_6426aca2296b5e03b333d5253ae7d88c._comment
new file mode 100644
index 0000000000..4482ac4096
--- /dev/null
+++ b/doc/forum/Move_files_in_git_annex___40__direct_mode__41__/comment_1_6426aca2296b5e03b333d5253ae7d88c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-29T17:39:13Z"
+ content="""
+Well, that should work; the files should get moved in the second clone
+automatically when it's synced.
+
+Just tested it, seems to work ok.
+
+What does `git annex status` say in the second repo?
+"""]]
diff --git a/doc/forum/Move_history.mdwn b/doc/forum/Move_history.mdwn
new file mode 100644
index 0000000000..2efaf3fbad
--- /dev/null
+++ b/doc/forum/Move_history.mdwn
@@ -0,0 +1,5 @@
+I have recently noticed that my .git directory in one copy of my git annex repository has ballooned to about 500GB (on a direct mode network).
+
+Is there any way to move the history to another repository? I guess 500GB isn't that bad on my archive repositories, but for one of my deployment machines this much space for files I don't use isn't really acceptable.
+
+Alternatively, and since this repo is quite a bit older, I think I could also just delete some of the history. Is there any way to do that?
diff --git a/doc/forum/Move_history/comment_10_da64814a7dfc2322200130a17bb79923._comment b/doc/forum/Move_history/comment_10_da64814a7dfc2322200130a17bb79923._comment
new file mode 100644
index 0000000000..078b5b9efb
--- /dev/null
+++ b/doc/forum/Move_history/comment_10_da64814a7dfc2322200130a17bb79923._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Chymera"
+ avatar="http://cdn.libravatar.org/avatar/555d585d6d78c68894ac90fd1e984309"
+ subject="comment 10"
+ date="2019-01-06T01:25:10Z"
+ content="""
+it did indeed look like data from an unintended and interrupted \"git annex add *\", deleted it and now the space issue has resolved. Thank you.
+"""]]
diff --git a/doc/forum/Move_history/comment_11_46ce6990e5921238f98749af830ac5ec._comment b/doc/forum/Move_history/comment_11_46ce6990e5921238f98749af830ac5ec._comment
new file mode 100644
index 0000000000..41ad394f00
--- /dev/null
+++ b/doc/forum/Move_history/comment_11_46ce6990e5921238f98749af830ac5ec._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2019-01-17T20:01:51Z"
+ content="""
+There were actually a few ways git-annex could be interrupted and leave
+droppings in misctmp.
+
+This is now dealt with, a subsequent run of git-annex will clean up
+leftover files from a previous interrupted run.
+"""]]
diff --git a/doc/forum/Move_history/comment_1_b720837e8e4ab8f4b0648f8ac336a605._comment b/doc/forum/Move_history/comment_1_b720837e8e4ab8f4b0648f8ac336a605._comment
new file mode 100644
index 0000000000..51a4b1e2c1
--- /dev/null
+++ b/doc/forum/Move_history/comment_1_b720837e8e4ab8f4b0648f8ac336a605._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-12-30T21:58:55Z"
+ content="""
+If you run `git annex info` you can see how much of this space is from actual annexed objects `local annex size`. Anyhow if the files aren't associated with any files in your working tree and you don't want them you can remove them with the `unused` command, there are some pointers here: <http://git-annex.branchable.com/walkthrough/unused_data/>.
+"""]]
diff --git a/doc/forum/Move_history/comment_2_17b8c2fd3ac706cd666ad5f5c0a21715._comment b/doc/forum/Move_history/comment_2_17b8c2fd3ac706cd666ad5f5c0a21715._comment
new file mode 100644
index 0000000000..27e21bc9e1
--- /dev/null
+++ b/doc/forum/Move_history/comment_2_17b8c2fd3ac706cd666ad5f5c0a21715._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Chymera"
+ avatar="http://cdn.libravatar.org/avatar/555d585d6d78c68894ac90fd1e984309"
+ subject="comment 2"
+ date="2019-01-02T12:08:19Z"
+ content="""
+>  If you run git annex info you can see how much of this space is from actual annexed objects local annex size
+
+I don't understand what you mean, `git annex info` tells me nothing about the repository size, and I have no idea where to enter the “local annex size” string.
+At any rate, no, I have already run `git annex dropunused` to get rid of all unused files. All the rest seems to be needed for some reason. My question was whether I can move all of this history to one of my volumes which have more space on them.
+"""]]
diff --git a/doc/forum/Move_history/comment_3_9ff881c26c3bd7f3a61595ffc1df743a._comment b/doc/forum/Move_history/comment_3_9ff881c26c3bd7f3a61595ffc1df743a._comment
new file mode 100644
index 0000000000..8ce73a7e53
--- /dev/null
+++ b/doc/forum/Move_history/comment_3_9ff881c26c3bd7f3a61595ffc1df743a._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 3"
+ date="2019-01-03T01:32:28Z"
+ content="""
+There are various ways to forget history, both in git and git-annex. I don't have enough clarity into what history is taking up space in your repository to give you a good answer. Answering the following questions will give me more insight into where the space is being used up, then I can give you some ideas on how to reclaim it:
+
+Is the repo in question direct or indirect (I am not sure what you meant by \"direct mode network\")? Output of `git annex info | grep \"repository mode\"` command will tell you this.
+
+What git-annex repo version is the repo in question? Output of `git annex version | grep \"local repository version\"` command will tell you this.
+
+If you cd into the repo in question and run `git-annex info` it gives you various information about what git-annex thinks about the repository. One of the outputs of this command is \"local annex size\" which tells you how much space this repo is taking up. In a direct mode repo this should be the same size as you get from sizing all the files in your working directory excluding the .git directory (`du -sh --exclude=.git` on Linux). Otherwise in an indirect mode repo, the \"local annex size\" given by `git-annex info` should match the size of the `.git/annex/objects` directory.
+
+If you cd into the repo in question what are the outputs of the following commands.
+
+Size of git annex objects (In a direct mode repo this should be very small):
+
+    du -sh .git/annex/objects/
+ 
+
+Size of git objects (This just tells you how much history is stored in git. This should also be small (unless you store a lot of large files in git, which you probably don't since you are using git-annex):
+
+    du -sh .git/objects/
+
+Size of working tree (this will tell you file content present in this repo):
+
+    git annex info | grep \"size of annexed files in working tree\"
+
+
+
+
+"""]]
diff --git a/doc/forum/Move_history/comment_4_d0c97744e9ccca21e4023f657e9f5f30._comment b/doc/forum/Move_history/comment_4_d0c97744e9ccca21e4023f657e9f5f30._comment
new file mode 100644
index 0000000000..d70626c5b1
--- /dev/null
+++ b/doc/forum/Move_history/comment_4_d0c97744e9ccca21e4023f657e9f5f30._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="Chymera"
+ avatar="http://cdn.libravatar.org/avatar/555d585d6d78c68894ac90fd1e984309"
+ subject="comment 4"
+ date="2019-01-03T19:33:01Z"
+ content="""
+```
+chymera@clusterhost ~/ni_data/ofM.dr $ git annex info | grep \"repository mode\"
+repository mode: direct
+chymera@clusterhost ~/ni_data/ofM.dr $ git annex version | grep \"local repository version\"
+local repository version: 5
+```
+
+> One of the outputs of this command is \"local annex size\" which tells you how much space this repo is taking up. 
+
+this does not happen, `git-annex info | grep \"local annex size\"` returns nothing.
+
+```
+chymera@clusterhost ~/ni_data $ du -sh .git/annex/objects/
+1.6G  .git/annex/objects/
+chymera@clusterhost ~/ni_data $ du -sh .git/objects/
+218M    .git/objects/
+chymera@clusterhost ~/ni_data $ du -sh
+779G
+chymera@clusterhost ~/ni_data $ du -sh .git/
+501G    .git/ 
+```
+"""]]
diff --git a/doc/forum/Move_history/comment_6_0655707fe70710408b93b5f53f8d6f26._comment b/doc/forum/Move_history/comment_6_0655707fe70710408b93b5f53f8d6f26._comment
new file mode 100644
index 0000000000..ad78f21f89
--- /dev/null
+++ b/doc/forum/Move_history/comment_6_0655707fe70710408b93b5f53f8d6f26._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="Chymera"
+ avatar="http://cdn.libravatar.org/avatar/555d585d6d78c68894ac90fd1e984309"
+ subject="comment 6"
+ date="2019-01-03T19:43:23Z"
+ content="""
+    chymera@clusterhost ~/ni_data/ofM.dr $ git annex info | grep \"repository mode\"
+    repository mode: direct
+    chymera@clusterhost ~/ni_data/ofM.dr $ git annex version | grep \"local repository version\"
+    local repository version: 5
+    chymera@clusterhost ~/ni_data $ du -sh .git/annex/objects/
+    1.6G .git/annex/objects/
+    chymera@clusterhost ~/ni_data $ du -sh .git/objects/
+    218M .git/objects/
+    chymera@clusterhost ~/ni_data $ du -sh
+    779G
+    chymera@clusterhost ~/ni_data $ du -sh .git/
+    501G .git/ 
+
+"""]]
diff --git a/doc/forum/Move_history/comment_6_f2e1d20e269648358b1eced616727e63._comment b/doc/forum/Move_history/comment_6_f2e1d20e269648358b1eced616727e63._comment
new file mode 100644
index 0000000000..9a7759768a
--- /dev/null
+++ b/doc/forum/Move_history/comment_6_f2e1d20e269648358b1eced616727e63._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="Chymera"
+ avatar="http://cdn.libravatar.org/avatar/555d585d6d78c68894ac90fd1e984309"
+ subject="comment 6"
+ date="2019-01-03T22:56:25Z"
+ content="""
+    git annex info | grep \"size of annexed files in working tree\"
+
+This does nothing but hang and I am not sure whether it's git annex or grep that hangs:
+
+    chymera@clusterhost /mnt/overflow $ ps aux | ag annex
+    chymera   5884  0.0  0.0 139920  3388 pts/7    S+   23:53   0:00 git annex info
+    chymera   5885  0.0  0.0 133216   900 pts/7    S+   23:53   0:00 grep --colour=auto size of annexed files in working tree
+    chymera   5886  6.4  0.0 1074610112 102528 pts/7 Dl+ 23:53   0:05 /usr/bin/git-annex info
+    chymera   5905  0.0  0.0  11304  1084 pts/8    S+   23:55   0:00 ag annex
+    chymera@clusterhost /mnt/overflow $ ps aux | ag git
+    chymera   5884  0.0  0.0 139920  3388 pts/7    S+   23:53   0:00 git annex info
+    chymera   5886  6.3  0.0 1074610112 102528 pts/7 Dl+ 23:53   0:05 /usr/bin/git-annex info
+    chymera   5893  0.0  0.0 258580  4492 pts/7    S+   23:54   0:00 git --git-dir=.git --work-tree=. --literal-pathspecs -c core.bare=false cat-file --batch
+    chymera   5894  0.0  0.0 139920  3740 pts/7    S+   23:54   0:00 git --git-dir=.git --work-tree=. --literal-pathspecs -c core.bare=false cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+    chymera   5909  0.0  0.0  11304  1032 pts/8    S+   23:55   0:00 ag git
+    chymera@clusterhost /mnt/overflow $ ps aux | ag grep
+    chymera   5885  0.0  0.0 133216   900 pts/7    S+   23:53   0:00 grep --colour=auto size of annexed files in working tree
+    chymera   5913  0.0  0.0  11304  1072 pts/8    S+   23:55   0:00 ag grep
+
+"""]]
diff --git a/doc/forum/Move_history/comment_7_acd690861b31e55352497b32b7c0fd6e._comment b/doc/forum/Move_history/comment_7_acd690861b31e55352497b32b7c0fd6e._comment
new file mode 100644
index 0000000000..a14abaeb00
--- /dev/null
+++ b/doc/forum/Move_history/comment_7_acd690861b31e55352497b32b7c0fd6e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 7"
+ date="2019-01-03T23:48:03Z"
+ content="""
+Aaah, sorry, yeah, `git-annex info` is very slow its checks many things locally and remotely… (i've seen it run for 30min+ on some of my repos). No, worries I don't think we'll learn too much more from that command than we learned from the `du` commands.
+
+You indeed do have some un-accounted for space in `.git`, I usually expect most of the space to be in the git-annex or git objects folders but that only accounts for 1.6 of the 501 GB in your .git folder.
+
+What are the outputs of `du -h -d 1 .git/` thats a level-1 listing of files in .git, and `du -h -d 1 .git/annex/` thats for files in the annex specific folder? That will help narrow down where the space is eaten up from. Perhaps `.git/annex/misctmp` or `.git/annex/tmp` are the culprits.
+"""]]
diff --git a/doc/forum/Move_history/comment_8_0e4b1629d2bb9d360a1ba65494dd8ccd._comment b/doc/forum/Move_history/comment_8_0e4b1629d2bb9d360a1ba65494dd8ccd._comment
new file mode 100644
index 0000000000..8639cc25b5
--- /dev/null
+++ b/doc/forum/Move_history/comment_8_0e4b1629d2bb9d360a1ba65494dd8ccd._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="Chymera"
+ avatar="http://cdn.libravatar.org/avatar/555d585d6d78c68894ac90fd1e984309"
+ subject="comment 8"
+ date="2019-01-04T03:52:22Z"
+ content="""
+Additionally, I notice that the git annex version my repo has (5) is 2 versions old. Given the git-annex availability on my distributions, I think I could bump this to 6 --- do you suggest I do this now or after I have this issue handled?
+
+    chymera@clusterhost ~/ni_data $ du -h -d 1 .git/
+    12K     .git/info
+    52K     .git/hooks
+    218M    .git/objects
+    501G  .git/annex
+    124K    .git/refs
+    172K    .git/logs
+    501G    .git/
+
+
+    chymera@clusterhost ~/ni_data $ du -h -d 1 .git/annex/
+    499G    .git/annex/misctmp
+    4.0K    .git/annex/ssh
+    8.3M    .git/annex/journal
+    60K     .git/annex/keys
+    30M     .git/annex/transfer
+    1.6G    .git/annex/objects
+    4.0K    .git/annex/tmp
+    501G    .git/annex/
+"""]]
diff --git a/doc/forum/Move_history/comment_9_1153476304000f417292fdce1f9727bf._comment b/doc/forum/Move_history/comment_9_1153476304000f417292fdce1f9727bf._comment
new file mode 100644
index 0000000000..a33f901050
--- /dev/null
+++ b/doc/forum/Move_history/comment_9_1153476304000f417292fdce1f9727bf._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 9"
+ date="2019-01-04T12:49:51Z"
+ content="""
+Aaah. All the space is in `.git/annex/misctmp`. This is essentially a directory for git annex to stage things temporarily, but I don't know too much about what gets put in this directory and when it is safe to delete it (the only official documentation is in [internals](http://git-annex.branchable.com/internals/)).
+
+One person had their `.git/annex/misctmp` dir fill up after [interrupting the assistant during transfers](https://git-annex.branchable.com/forum/misctmp_filling_up/), another person had their misctmp fill up [after interrupting git annex while it was switching to direct mode](https://git-annex.branchable.com/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/).
+
+Maybe one of those situations applies to you? Perhaps take a look at some of the files in misctmp and try to evaluate if you feel they are safe to delete? They should have somewhat recognizable names. I don't know if running `git annex fsck` will cleanup any of these files (Joey?).
+
+I would personally not rush into upgrading from v5. v6 has been deprecated so, with the latest git-annex, it will auto-upgrade v6 to v7 (so you can't have a v6 repo anymore). So your only options are staying on v5 or upgrading to v7. But, there are some significant differences (currently) that you need to be aware of. v7 no longer supports direct mode (it has features that are similar but not equivalent in all situations). v7 (and v6) take control of `git add` so files are actually added to the annex (not git) when you use this command unless you have configured largefiles (this makes it a bit more difficult to maintain repos that have a mix of git and git-annex files. And unlocked/locked files are treated differently.
+"""]]
diff --git a/doc/forum/Move_unsynced_file_in_direct_mode.mdwn b/doc/forum/Move_unsynced_file_in_direct_mode.mdwn
new file mode 100644
index 0000000000..015b5f58e7
--- /dev/null
+++ b/doc/forum/Move_unsynced_file_in_direct_mode.mdwn
@@ -0,0 +1,97 @@
+When I rename unsynced files in a direct mode repo, the original symlink gets removed from git, but the new symlink doesn't get added back by autocommit or by explicitly using `git annex add`.
+
+First, I create a file in a git-annex repo:
+
+        $ mkdir annex1
+        $ cd annex1
+        $ git init
+        Initialized empty Git repository in /home/cwarden/annex1/.git/
+        $ git annex init
+        init  ok
+        (Recording state in git...)
+        $ echo test > test1
+        $ git annex add test1
+        add test1 ok
+        (Recording state in git...)
+        $ git annex sync
+        commit  ok
+        $ ls -l
+        total 4
+        lrwxrwxrwx 1 cwarden cwarden 178 Sep 12 10:14 test1 -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
+        $ cat test1
+        test
+
+Now, I clone the repo and enable autocommit and direct mode in the second repo:
+
+        $ cd ..
+        $ git clone annex1 annex2
+        Cloning into 'annex2'...
+        done.
+        $ cd annex2
+        $ git config annex.autocommit true
+        $ git annex direct
+        commit
+        On branch master
+        Your branch is up-to-date with 'origin/master'.
+
+        nothing to commit, working directory clean
+        ok
+        direct  ok
+
+I drop the file, then rename it:
+
+        $ git annex drop test1
+        (merging origin/git-annex into git-annex...)
+        (Recording state in git...)
+        $ mv test1 test2
+        $ ls -l
+        total 4
+        lrwxrwxrwx 1 cwarden cwarden 178 Sep 12 10:14 test2 -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
+        $ git annex sync
+        commit  (Recording state in git...)
+        ok
+        pull origin
+        ok
+        push origin
+        Counting objects: 6, done.
+        Delta compression using up to 4 threads.
+        Compressing objects: 100% (5/5), done.
+        Writing objects: 100% (6/6), 674 bytes | 0 bytes/s, done.
+        Total 6 (delta 1), reused 0 (delta 0)
+        To /home/cwarden/annex1
+                2772756..ffcb7a1  annex/direct/master -> synced/master
+         * [new branch]      git-annex -> synced/git-annex
+        ok
+        (Recording state in git...)
+
+Now, I want to get the renamed file:
+
+        $ git annex get test2
+        $ ls -l
+        total 4
+        lrwxrwxrwx 1 cwarden cwarden 178 Sep 12 10:14 test2 -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
+        $ cat test2
+        cat: test2: No such file or directory
+
+Explicitly adding test2 doesn't work:
+
+        $ git annex add test2
+        $ git annex get test2
+        $ cat test2
+        cat: test2: No such file or directory
+
+`git annex fsck` doesn't help:
+
+        $ git annex fsck
+        $ cat test2
+        cat: test2: No such file or directory
+
+The only way I've found to get the renamed file back into git is to use `core.bare=false`, but the [documentation](http://git-annex.branchable.com/direct_mode/) says that "there should be no good reason to need to do this, ever".
+
+        $ git -c core.bare=false add test2
+        $ git -c core.bare=false commit -m'force renamed file back into git'
+        $ git annex get test2
+        $ cat test2
+        test
+
+Is there a better solution?
diff --git a/doc/forum/Move_unsynced_file_in_direct_mode/comment_1_12a797cba753168dfde9e6339c00f481._comment b/doc/forum/Move_unsynced_file_in_direct_mode/comment_1_12a797cba753168dfde9e6339c00f481._comment
new file mode 100644
index 0000000000..73a164da26
--- /dev/null
+++ b/doc/forum/Move_unsynced_file_in_direct_mode/comment_1_12a797cba753168dfde9e6339c00f481._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-09-18T18:27:37Z"
+ content="""
+Well, you can run `git annex assistant` or `git annex watch` and it will automatically notice the moved file and commit it. I think this is what you were trying to do when you set annex.autocommit to true (which is the default so accomplished nothing).
+
+But your example does show a bug: `git annex add` should add the dangling symlink to git in direct mode, as it already does in indirect mode. Fixed in [[!commit 44e7d6e1fe6e13091adbd572f66412e3601df3c5]].
+"""]]
diff --git a/doc/forum/Move_unsynced_file_in_direct_mode/comment_2_f3aec24668c35780a033f2b035df10ee._comment b/doc/forum/Move_unsynced_file_in_direct_mode/comment_2_f3aec24668c35780a033f2b035df10ee._comment
new file mode 100644
index 0000000000..971e70cdca
--- /dev/null
+++ b/doc/forum/Move_unsynced_file_in_direct_mode/comment_2_f3aec24668c35780a033f2b035df10ee._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="xn"
+ ip="71.59.214.243"
+ subject="comment 2"
+ date="2014-09-18T19:03:30Z"
+ content="""
+Thanks for tracking down that bug and for clearing up my confusion about `annex.autocommit`, Joey.
+
+I didn't realize `annex.autocommit=true` is only used by `git annex assistant` and `git annex watch`.  I thought that running `git annex sync` with `annex.autocommit=true` would also commit the change.
+
+A few small changes to `git-annex(1)` could clarify:
+
+    sync [remote ...]
+         ...
+         The sync process involves first committing all local *staged* changes...
+
+    annex.autocommit
+       Set to false to prevent git-annex assistant and *git-annex watch* from automatically committing changes to files in the repository.
+
+"""]]
diff --git a/doc/forum/Moving_S3_special_remote.mdwn b/doc/forum/Moving_S3_special_remote.mdwn
new file mode 100644
index 0000000000..d80237492e
--- /dev/null
+++ b/doc/forum/Moving_S3_special_remote.mdwn
@@ -0,0 +1 @@
+I want to move the contents of my S3 special remote. I've already kicked off the transfer with `rclone sync s3:bucketfoo s3:bucketbar/annex` to move the encrypted chunks to a new bucket under a new prefix. Once that finishes (in a few days), can I just run `git annex enableremote [new params]` or will I run into problems?
diff --git a/doc/forum/Moving_S3_special_remote/comment_1_b030a7afcbf1a329bb35260cf338ff96._comment b/doc/forum/Moving_S3_special_remote/comment_1_b030a7afcbf1a329bb35260cf338ff96._comment
new file mode 100644
index 0000000000..d4f0760101
--- /dev/null
+++ b/doc/forum/Moving_S3_special_remote/comment_1_b030a7afcbf1a329bb35260cf338ff96._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="a@92214b2eae95307f511e06845d2cb5b5931b00a3"
+ nickname="a"
+ avatar="http://cdn.libravatar.org/avatar/d76a578b33d7d7bb570e176909fa8fb1"
+ subject="Re: Moving S3 special remote"
+ date="2020-11-05T03:44:52Z"
+ content="""
+And the answer is that running `git annex enableremote bucket=bucketbar fileprefix=annex/` works just fine.
+"""]]
diff --git a/doc/forum/Moving_S3_special_remote/comment_2_3c4b8afa81590a1f1e2291a08d633b16._comment b/doc/forum/Moving_S3_special_remote/comment_2_3c4b8afa81590a1f1e2291a08d633b16._comment
new file mode 100644
index 0000000000..ee5b1bb1d4
--- /dev/null
+++ b/doc/forum/Moving_S3_special_remote/comment_2_3c4b8afa81590a1f1e2291a08d633b16._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="wting"
+ avatar="http://cdn.libravatar.org/avatar/ff65dc4f3eb58490220b89a7984c4d02"
+ subject="comment 2"
+ date="2020-11-19T03:12:36Z"
+ content="""
+Thanks for sharing the answer you found, it helped me out as well.
+
+To add on, modifying a special remote via `git annex enableremote myspecialremote autoenable=true && git annex sync` also propagates the updated configuration to reachable repositories. That said, you have to manually remove and re-enable remote to get the new configuration for each repo.
+"""]]
diff --git a/doc/forum/Moving_large_files_within_the_repo_without_copying___63__.mdwn b/doc/forum/Moving_large_files_within_the_repo_without_copying___63__.mdwn
new file mode 100644
index 0000000000..55d51f21df
--- /dev/null
+++ b/doc/forum/Moving_large_files_within_the_repo_without_copying___63__.mdwn
@@ -0,0 +1,19 @@
+Is there a way to move a large file without "git annex unlock"ing it (Which takes very long for copying and then rehashing the file)?
+Using a simple "mv" or "git mv" results in broken symlinks, if the target directory is on a different hierarchy level:
+
+Example:
+
+Initial State:
+
+    $ ls -Hl Pictures:
+    Pictures/showImages.jpg -> ../.git/annex/objects/90/32/SHA1-s8737--a8bfb285d0ae394cb75c86f1eb9f703fb678a51e/SHA1-s8737--a8bfb285d0ae394cb
+
+Move: 
+
+    $ mv Pictures/showImages.jpg .
+
+Result: 
+
+    $ ls -H showImages.jpg
+    ls: cannot access showImages.jpg: No such file or directory
+    
diff --git a/doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_1_9e3290138133d5a23a80f72342f47ec4._comment b/doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_1_9e3290138133d5a23a80f72342f47ec4._comment
new file mode 100644
index 0000000000..d1df9cf514
--- /dev/null
+++ b/doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_1_9e3290138133d5a23a80f72342f47ec4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 1"
+ date="2012-11-28T13:28:21Z"
+ content="""
+Just commit, git-annex will fix the symlinks. Or do it manually with 'git annex fix'.
+"""]]
diff --git a/doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_2_232b77894dda51d02cbc34bd25d3213b._comment b/doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_2_232b77894dda51d02cbc34bd25d3213b._comment
new file mode 100644
index 0000000000..0559e79543
--- /dev/null
+++ b/doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_2_232b77894dda51d02cbc34bd25d3213b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlgyVag95OnpvSzQofjyX0WjW__MOMKsl0"
+ nickname="Sehr"
+ subject="Does not work"
+ date="2012-11-28T14:50:16Z"
+ content="""
+    $ git annex fix 
+
+Does not change anything. and
+
+    $ git annex fix showImages.jpg
+    git-annex: showImages.jpg not found
+"""]]
diff --git a/doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_3_d35ac1bdb3fa6e303ad92348ba174158._comment b/doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_3_d35ac1bdb3fa6e303ad92348ba174158._comment
new file mode 100644
index 0000000000..d4d25a7056
--- /dev/null
+++ b/doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_3_d35ac1bdb3fa6e303ad92348ba174158._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 3"
+ date="2012-11-28T15:03:42Z"
+ content="""
+In my tests 'git annex fix' works only on symlinks in directories alredy known to git. So if you created a new directory inside your annex, be sure to 'git add' the directory before running 'git annex fix'.
+
+HTH,
+Karsten
+"""]]
diff --git a/doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_4_4b443ec6b47eaabe214d0c2222083e4a._comment b/doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_4_4b443ec6b47eaabe214d0c2222083e4a._comment
new file mode 100644
index 0000000000..cf09b261ae
--- /dev/null
+++ b/doc/forum/Moving_large_files_within_the_repo_without_copying___63__/comment_4_4b443ec6b47eaabe214d0c2222083e4a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlgyVag95OnpvSzQofjyX0WjW__MOMKsl0"
+ nickname="Sehr"
+ subject="comment 4"
+ date="2012-11-28T15:14:49Z"
+ content="""
+Thanks. It seems that the file itself has to be added to git annex to be able to bet git annex fixed!
+"""]]
diff --git a/doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout.mdwn b/doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout.mdwn
new file mode 100644
index 0000000000..3ed022b481
--- /dev/null
+++ b/doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout.mdwn
@@ -0,0 +1,4 @@
+Hi,
+Is there any way I can move or copy file content of older version without doing checkout to that version, by passing commit hash as parameter in move command itself? 
+
+Thank you
diff --git a/doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout/comment_1_f114b75b29123453758b493fae7f5167._comment b/doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout/comment_1_f114b75b29123453758b493fae7f5167._comment
new file mode 100644
index 0000000000..a53c6bbd69
--- /dev/null
+++ b/doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout/comment_1_f114b75b29123453758b493fae7f5167._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"
+ nickname="Rafael"
+ subject="comment 1"
+ date="2012-05-15T07:59:57Z"
+ content="""
+I had a similiar question in forum/new_microfeatures/. I would like to fetch/copy all the annexed content from a repo, be it on the current branch, another branch, or corresponds to an old version of a file. A command like \"git annex copy --all --from=source [path]\" would then ensure I have access to all the content I need even if I have later no longer access to source. Sure I could use rsync.
+"""]]
diff --git a/doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout/comment_2_e377b7614c2961b460a10e285f3db274._comment b/doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout/comment_2_e377b7614c2961b460a10e285f3db274._comment
new file mode 100644
index 0000000000..18ff153ad0
--- /dev/null
+++ b/doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout/comment_2_e377b7614c2961b460a10e285f3db274._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.51"
+ subject="comment 2"
+ date="2012-05-15T17:00:10Z"
+ content="""
+Yes, I think that [[todo/add_-all_option]] is the right approach for this. Seems unlikely you'd have some files' hashes handy without having them checked out, but operating on all content makes sense.
+
+That page discusses some problems implementing it for some commands, but should not pose a problem for `move`. It would also be possible to support `get` and `copy`, except `--auto` couldn't be used with `--all`. Even `fsck` could support it.
+"""]]
diff --git a/doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout/comment_3_d251958795ab0867c65cf182e54a6ffe._comment b/doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout/comment_3_d251958795ab0867c65cf182e54a6ffe._comment
new file mode 100644
index 0000000000..63d1e68006
--- /dev/null
+++ b/doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout/comment_3_d251958795ab0867c65cf182e54a6ffe._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 3"
+ date="2013-07-03T18:10:29Z"
+ content="""
+Now the --all option is built. You can, for example, run `git annex copy --all --to backup`
+"""]]
diff --git a/doc/forum/Multiple_group_groupwanted_settings_help.mdwn b/doc/forum/Multiple_group_groupwanted_settings_help.mdwn
new file mode 100644
index 0000000000..49781d91fe
--- /dev/null
+++ b/doc/forum/Multiple_group_groupwanted_settings_help.mdwn
@@ -0,0 +1,34 @@
+Help me figure this out. I can't get it to work.
+
+Here's my hypothetical repo setup: a1 a2 b1 b2
+
+All of these are connected to each other.
+
+Settings are as follows:
+
+    group a1 = a 1
+    group a2 = a 2
+    group b1 = b 1
+    group b2 = b 2
+
+    wanted a1 = groupwanted
+    wanted a2 = groupwanted
+    wanted b1 = groupwanted
+    wanted b2 = groupwanted
+
+    groupwanted 1 = not copies=1:1
+    groupwanted 2 = not copies=2:1
+    groupwanted a = not copies=a:1
+    groupwanted b = not copies=b:1
+
+    numcopies default = 2
+    config annex.synccontent = true
+
+The behavior I want is: Group "a" repos will only have 1 copy of a file, and group "b" repos will only have 1 copy of a file.
+Similarly, group "1" repos will only have 1 copy of a file, and group "2" repos will only have 1 copy of a file.
+
+So, for example, a file could be stored in a1 and b2, or a2 and b1, but NOT a1 and a2 (both are group "a") or a1 and b1 (both are group "1").
+
+But it doesn't work. When I add a file to a1, it is not copied to b2 on sync. The documentation says repos can have multiple groups, but I'm not sure how the groupwanted settings of multiple groups work together.
+
+Is this even possible?
diff --git a/doc/forum/Multiple_group_groupwanted_settings_help/comment_1_e78d0aa6b23225c509b9e97549fe915b._comment b/doc/forum/Multiple_group_groupwanted_settings_help/comment_1_e78d0aa6b23225c509b9e97549fe915b._comment
new file mode 100644
index 0000000000..134f074a36
--- /dev/null
+++ b/doc/forum/Multiple_group_groupwanted_settings_help/comment_1_e78d0aa6b23225c509b9e97549fe915b._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-06-12T16:17:30Z"
+ content="""
+groupwanted expressions are only used when there is only one that the
+repository could use. The repository can be in two groups and if only one
+of the groups has a groupwanted expression, it will be used, but if both
+do, neither expression will be used. 
+
+This limitation to exactly one expression also holds for standard
+preferred content expressions (which is documented).
+git-annex does not try to combine together two expressions with OR.
+Why not? Well, consider the standard preferred content expressions for the 
+client and transfer groups. The one for transfer looks at whether client
+repositories have the content:
+`not (inallgroup=client and copies=client:2) ...`
+
+If a repository is both a transfer repository and a client at the same
+time, that would make it want to have content as long as not all clients
+contain the content -- so once all other clients get the content, the
+repository would want to drop its copy. But then, it would see that
+not all client repositories now have the content (since it doesn't!) and
+want to get it. And potentially round and round.. 
+
+git-annex actually detects and prevents this kind of drop/get cycle
+(probably), but the right behavior of combining those two groupwanted
+expressions is at best undefined. So it's better to have the user write
+down an expression with what they really want to happen than try to OR
+expressions.
+
+I've updated the docs for groupwanted to note that it's only used when one 
+of a repos's groups has it.
+"""]]
diff --git a/doc/forum/Multiple_group_groupwanted_settings_help/comment_2_b3d95d5c03c7b985d39a4d5a45ba3dec._comment b/doc/forum/Multiple_group_groupwanted_settings_help/comment_2_b3d95d5c03c7b985d39a4d5a45ba3dec._comment
new file mode 100644
index 0000000000..b981e34b32
--- /dev/null
+++ b/doc/forum/Multiple_group_groupwanted_settings_help/comment_2_b3d95d5c03c7b985d39a4d5a45ba3dec._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="ghen1"
+ avatar="http://cdn.libravatar.org/avatar/efd0e92b6198291138f0cd7aedbf86b6"
+ subject="comment 2"
+ date="2018-06-13T17:18:49Z"
+ content="""
+Thank you for clarifying. I've worked out a setup that seems to do what I want. The rules are a little messier, but not too bad:
+
+    group a1 = a 1 a1store
+    group a2 = a 2 a2store
+    group b1 = b 1 b1store
+    group b2 = b 2 b2store
+    
+    wanted a1 = groupwanted
+    wanted a2 = groupwanted
+    wanted b1 = groupwanted
+    wanted b2 = groupwanted
+    
+    groupwanted a1store = not copies=1:1 and not copies=a:1
+    groupwanted a2store = not copies=2:1 and not copies=a:1
+    groupwanted b1store = not copies=1:1 and not copies=b:1
+    groupwanted b2store = not copies=2:1 and not copies=b:1
+    
+    numcopies default = 2
+    config annex.synccontent = true
+
+"""]]
diff --git a/doc/forum/Multiple_interface_to_the_same_annex.mdwn b/doc/forum/Multiple_interface_to_the_same_annex.mdwn
new file mode 100644
index 0000000000..54f4ae2d91
--- /dev/null
+++ b/doc/forum/Multiple_interface_to_the_same_annex.mdwn
@@ -0,0 +1,29 @@
+I would like to get available the access to the annex of my repository as remote with rsync protocol (read only).
+The idea is not to have a redundant copy of the annex but to add an other option to connect to the annex.
+
+If I create an rsync remote I obtain something like
+
+	00000000-0000-0000-0000-000000000001 -- web<br/>
+
+ 	00000000-0000-0000-0000-000000000002 -- bit torrent
+
+ 	044cf7ac-d2b1-4f84-8bbc-747ac4659c8f -- rsync
+
+ 	a0e14705-ef07-4b8a-9a00-8724fd936a91 -- origin /my-repo/.git/annex
+
+The remote "rsync" points to the same location of the annex /my-repo/.git/annex
+
+If I add a file
+
+ 	git annex add file1
+
+and then I check where it is available
+
+ 	git annex whereis file 1
+
+I obtain that it is not available on 'rsync'
+
+Therefore if someone has a copy of the repository, without access to the origin annex,
+there is no way to use the additional access through 'rsync'
+
+What is the right way to configure the 'rsync' remote in such a way behave like an alias for the origin annex?
diff --git a/doc/forum/Multiple_interface_to_the_same_annex/comment_1_ea9e3a987112d8bf6421be234bf61d3c._comment b/doc/forum/Multiple_interface_to_the_same_annex/comment_1_ea9e3a987112d8bf6421be234bf61d3c._comment
new file mode 100644
index 0000000000..df21114bcb
--- /dev/null
+++ b/doc/forum/Multiple_interface_to_the_same_annex/comment_1_ea9e3a987112d8bf6421be234bf61d3c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-12-13T16:55:21Z"
+ content="""
+Creating a separate special remote pointing to the same content is not a
+good idea. This will confuse git-annex's location tracking, and in some
+cases can lead to data loss, since git-annex will assume it can safely
+delete a file from one of the "two" repositories, since it thinks the
+"other" one will still have the content of the file.
+
+Instead, you need a way to configure a regular git remote,
+pointing at the repository, that is read-only, or is accessed over rsync,
+or whatever your requirements are. 
+"""]]
diff --git a/doc/forum/Multiple_machine_remotes_on_external_drive.mdwn b/doc/forum/Multiple_machine_remotes_on_external_drive.mdwn
new file mode 100644
index 0000000000..70c910d380
--- /dev/null
+++ b/doc/forum/Multiple_machine_remotes_on_external_drive.mdwn
@@ -0,0 +1,7 @@
+I have a question about remotes behavior on external drives.
+
+Say I have two machines A and B each with a git annex repository at `~/repo`, and an external drive C with the same repository at `/repo`.
+
+I can add C remotes for A and B at, for example, `/media/hdd/repo`, but I'm not certain how it works for C.
+
+Do I stick C into A and add a remote A at path `~/repo`, then stick C into B and add a remote B with the same path `~/repo`?  Does git annex handle this sanely?
diff --git a/doc/forum/Multiple_prefered_content_groups.mdwn b/doc/forum/Multiple_prefered_content_groups.mdwn
new file mode 100644
index 0000000000..f3b00fe91c
--- /dev/null
+++ b/doc/forum/Multiple_prefered_content_groups.mdwn
@@ -0,0 +1,66 @@
+Hello,
+
+I have a repo alpha
+
+```
+florian@asaru ~/git-annex % tree
+.
+└── alpha
+    ├── archive
+    │   └── some_archived_file
+    └── some_file
+```
+
+which is standard/client.
+
+Another repo beta, cloned from alpha is also standard/client. ```git annex sync --content``` makes beta get all the content. Perfect!
+
+Another repo delta, also cloned from alpha is:
+
+```
+% git annex wanted . && git annex group .
+standard
+archive backup
+```
+Manpage of git-annex-group says a repo could be in multiple groups.
+
+I expect the groups to be combined. archive makes the other repos drop content in archive/ when it has reached this repo, backup to also retain deleted files.
+
+But ```git annex sync --content``` gets no files:
+
+```
+florian@asaru ~/git-annex/delta (git)-[master] % git annex sync --content
+commit  
+Auf Branch master
+Ihr Branch ist auf dem selben Stand wie 'origin/master'.
+nichts zu committen, Arbeitsverzeichnis unverändert
+ok
+pull origin 
+ok
+```
+```
+florian@asaru ~/git-annex/delta (git)-[master] % git annex info          
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 5
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        19d4aafe-0d6d-4bb8-913d-6f0541a6ee11 -- Alpha [origin]
+        6da720cc-4583-429d-bde0-724b7f9e494a -- Delta [here]
+        8523418a-0c1b-4987-a048-c967fc5ec1e7 -- Beta
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 123.11 gigabytes (+1 megabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 2
+size of annexed files in working tree: 2.59 megabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+        SHA256E: 2
+```
+
+What is wrong there? My mental model or some git-annex issue?
+
+Thanks,
+Florian
diff --git a/doc/forum/Multiple_prefered_content_groups/comment_1_b401d234c0730412053f0f6a6f9cf2d6._comment b/doc/forum/Multiple_prefered_content_groups/comment_1_b401d234c0730412053f0f6a6f9cf2d6._comment
new file mode 100644
index 0000000000..f47fe5eefc
--- /dev/null
+++ b/doc/forum/Multiple_prefered_content_groups/comment_1_b401d234c0730412053f0f6a6f9cf2d6._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-11T16:39:44Z"
+ content="""
+What git-annex actually does when a repository is in multiple groups
+is that the "standard" preferred content expression has no effect.
+Because this is an ambiguous configuration and it's not clear what you
+want.
+
+I don't think that you can combine preferred content expressions for
+multiple groups and always get behavior that makes sense. In particular,
+it seems likely that in some situations you'd want to combine them with AND
+but in other situations with OR.
+
+So, the best thing for you to do is probably to manually write a preferred
+content expression that clearly expresses what you want. Note that you
+can have a repository that's in the archive group, but instead of "standard"
+has its own custom preferred content expression. In your case, I think you
+want to do that; keeping the repository in the archive group will retain
+the behavior of other repositories dropping archived files once they reach
+it.
+
+Seems that for the preferred content setting for this repositry, you
+want the same one used for backup repositories, "anything".
+
+So:
+
+	git annex group . archive
+	git annex ungroup . backup
+	git anenx wanted . anything
+"""]]
diff --git a/doc/forum/Multiple_prefered_content_groups/comment_2_a91177f4f02500e8fa6594933e128ef0._comment b/doc/forum/Multiple_prefered_content_groups/comment_2_a91177f4f02500e8fa6594933e128ef0._comment
new file mode 100644
index 0000000000..84aef3011e
--- /dev/null
+++ b/doc/forum/Multiple_prefered_content_groups/comment_2_a91177f4f02500e8fa6594933e128ef0._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Horus"
+ subject="comment 2"
+ date="2016-07-14T08:32:11Z"
+ content="""
+Ah, ok, then it makes sense.
+
+Maybe it's an idea to expand the standard expression for client groups in a way that they drop a file if it has reached a backup repo (additionally to a archive repo)?
+
+Thanks!
+"""]]
diff --git a/doc/forum/Multiple_remotes_with_the_same_path.mdwn b/doc/forum/Multiple_remotes_with_the_same_path.mdwn
new file mode 100644
index 0000000000..55d9ee1df6
--- /dev/null
+++ b/doc/forum/Multiple_remotes_with_the_same_path.mdwn
@@ -0,0 +1,67 @@
+This is a followup to <https://git-annex.branchable.com/forum/basic_usage_questions/> – I'm actually testing the "two repos at same URL" situation now, with git-annex 6.20160211 and 6.20160221.
+
+So I have a git-annex repo on two hosts at `rain:~/Attic/Software`, `frost:~/Attic/Software`, and a third clone at `/mnt/portable_HD/Attic/Software`. This means that the repo on the portable HD has two remotes with identical paths, but corresponding to different repositories:
+
+    rain    /home/grawity/Attic/Software
+    frost   /home/grawity/Attic/Software
+
+[I was told earlier](/forum/basic_usage_questions) that this configuration would work fine and git-annex would not get confused. However, that doesn't seem to be the case (unless I misunderstood what it considers to be the "right thing"?) I see that whenever I run a command like `git annex info` on the portable\_HD repo, it overrides `remote.{rain,frost}.annex-uuid` with whatever UUID it sees right now – resulting in `git annex info` output such as:
+
+    ┌ frost /run/media/grawity/vol4_grimoire/Attic/Software master
+    ┘ git config -l | grep annex-uuid
+    remote.origin.annex-uuid=0ebc2083-f95e-4637-bd3e-09db8471daf3
+    remote.rain.annex-uuid=3e342a37-6c35-40e5-99a1-1f140e6c363d    <--
+    remote.frost.annex-uuid=524b8690-9b3e-48d4-b1a8-c0edb35c1ccf   <--
+    remote.fs1.annex-uuid=ed83c81c-1a95-4acb-b76c-b6724fe88873
+    
+    ┌ frost /run/media/grawity/vol4_grimoire/Attic/Software master
+    ┘ git annex info --fast --verbose --debug
+    repository mode: indirect
+    trusted repositories: [2016-02-29 08:09:29.284136] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+    [2016-02-29 08:09:29.286872] process done ExitSuccess
+    [2016-02-29 08:09:29.286954] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+    [2016-02-29 08:09:29.289167] process done ExitSuccess
+    [2016-02-29 08:09:29.289316] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..fc873fc472a8c5d0db3c91a3868d9adc072f7076","-n1","--pretty=%H"]
+    [2016-02-29 08:09:29.291836] process done ExitSuccess
+    [2016-02-29 08:09:29.291941] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..23c27db2f2a02515ba39e7d0bb8653fa786b6aea","-n1","--pretty=%H"]
+    [2016-02-29 08:09:29.294762] process done ExitSuccess
+    [2016-02-29 08:09:29.294869] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..690a90da7fc28be67d5053c0a6c3050cca614eaa","-n1","--pretty=%H"]
+    [2016-02-29 08:09:29.301018] process done ExitSuccess
+    [2016-02-29 08:09:29.30112] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..94375fb892d1c9f5b70bdd5917c85c5c18a13168","-n1","--pretty=%H"]
+    [2016-02-29 08:09:29.3031] process done ExitSuccess
+    [2016-02-29 08:09:29.303182] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..4a7f17e644e86776b510606beb6f3cb3819d8256","-n1","--pretty=%H"]
+    [2016-02-29 08:09:29.304916] process done ExitSuccess
+    [2016-02-29 08:09:29.305455] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+    [2016-02-29 08:09:29.308946] read: git ["config","--null","--list"]
+    [2016-02-29 08:09:29.312347] process done ExitSuccess
+    [2016-02-29 08:09:29.312939] read: git ["config","--null","--list"]
+    [2016-02-29 08:09:29.3179] process done ExitSuccess
+    [2016-02-29 08:09:29.318494] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","remote.rain.annex-uuid","524b8690-9b3e-48d4-b1a8-c0edb35c1ccf"]
+    [2016-02-29 08:09:29.320648] process done ExitSuccess
+    [2016-02-29 08:09:29.320735] read: git ["config","--null","--list"]
+    [2016-02-29 08:09:29.327697] process done ExitSuccess
+    0
+    semitrusted repositories: 9
+    	00000000-0000-0000-0000-000000000001 -- web
+     	00000000-0000-0000-0000-000000000002 -- bittorrent
+     	0ebc2083-f95e-4637-bd3e-09db8471daf3 -- origin
+     	3e14eb23-1b16-4b52-8798-56efb550ab00 -- [vol4_grimoire]:/Attic/Software [here]
+     	3e342a37-6c35-40e5-99a1-1f140e6c363d -- grawity@rain:~/Attic/Software              <--
+     	524b8690-9b3e-48d4-b1a8-c0edb35c1ccf -- grawity@frost:~/Downloads/Software [rain]  <--
+     	b9c0c485-07e5-4166-b5ac-ba971faab98a -- [vol3_tombstone]:/Attic/Software
+     	c3c6dd39-ebc7-475a-9992-f99ca01a7f3a -- grawity@wolke:~/Attic/Software
+     	ed83c81c-1a95-4acb-b76c-b6724fe88873 -- fs1:/Attic/Software [fs1]
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: 920.96 gigabytes (+1 megabyte reserved)
+    
+    ┌ frost /run/media/grawity/vol4_grimoire/Attic/Software master
+    ┘ git config -l | grep annex-uuid
+    remote.origin.annex-uuid=0ebc2083-f95e-4637-bd3e-09db8471daf3
+    remote.rain.annex-uuid=524b8690-9b3e-48d4-b1a8-c0edb35c1ccf    <--
+    remote.frost.annex-uuid=524b8690-9b3e-48d4-b1a8-c0edb35c1ccf   <--
+    remote.fs1.annex-uuid=ed83c81c-1a95-4acb-b76c-b6724fe88873
+
+Notice how the `[rain]` remote tag now shows up next to the wrong remote. Among other things, **this means I cannot use `git annex find --in frost --not --in rain`** and similar commands (unless I specify all the UUIDs by hand). And even though I trust git-annex to not lose any data, this behavior is a bit confusing.
+
+Is it possible that git-annex could detect such situations and avoid updating an UUID if it's _already attached_ to another remote?
diff --git a/doc/forum/Multiple_remotes_with_the_same_path/comment_1_78f2d8e3906c11ba5753478d08973bd2._comment b/doc/forum/Multiple_remotes_with_the_same_path/comment_1_78f2d8e3906c11ba5753478d08973bd2._comment
new file mode 100644
index 0000000000..5f9f7426ae
--- /dev/null
+++ b/doc/forum/Multiple_remotes_with_the_same_path/comment_1_78f2d8e3906c11ba5753478d08973bd2._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-02-29T15:47:39Z"
+ content="""
+git-annex is not getting confused; it's looking at the current content of
+the remote and using that uuid. Failing to do so would constitute
+confusion.
+
+If you want the remote to only work when the drive is plugged into a single
+host, you need to make the remote path only reach a repository on that
+host. One way would be a symlink, eg `/home/grawity/Attic/rain-Software ->
+Software` on rain.
+
+Or, just use the repository description, eg
+`--in grawity@rain:~/Attic/Software`. Note that the description can be
+changed to something easier to type.
+"""]]
diff --git a/doc/forum/Multiple_remotes_with_the_same_path/comment_2_8cd3edf2e71e904f1b651abdfd7a4499._comment b/doc/forum/Multiple_remotes_with_the_same_path/comment_2_8cd3edf2e71e904f1b651abdfd7a4499._comment
new file mode 100644
index 0000000000..f18404a6d4
--- /dev/null
+++ b/doc/forum/Multiple_remotes_with_the_same_path/comment_2_8cd3edf2e71e904f1b651abdfd7a4499._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ subject="comment 2"
+ date="2016-02-29T17:25:17Z"
+ content="""
+Hmm, I still think that avoiding duplicating uuids would be smarter behavior, but the host symlinks will do just fine. Thanks for the suggestion.
+"""]]
diff --git a/doc/forum/Multiple_repos_on_same_path.mdwn b/doc/forum/Multiple_repos_on_same_path.mdwn
new file mode 100644
index 0000000000..d90a9f0fb0
--- /dev/null
+++ b/doc/forum/Multiple_repos_on_same_path.mdwn
@@ -0,0 +1,12 @@
+I want to use git-annex to manage some data which I keep at, say, /home/my_user/data .
+I have multiple external storage devices for this repo, such as /run/media/my_user/data1 e
+
+BUT, I also have multiple machines, e.g. my desktop and my laptop. 
+These all have the data under /home/my_user/data, as I like to keep my paths consistent. 
+So, when I connect my external media to these machines, practically they see the same repo path, though these are different repos.
+
+1. Should I try to create multiple repos with the same path, or should I just add one
+
+2. Can I expect any major issues from this set-up?
+
+  
diff --git a/doc/forum/Multiple_repos_on_same_path/comment_1_67ed823c4c40f5acf12b48eb75d7afa8._comment b/doc/forum/Multiple_repos_on_same_path/comment_1_67ed823c4c40f5acf12b48eb75d7afa8._comment
new file mode 100644
index 0000000000..5ab93d9ed5
--- /dev/null
+++ b/doc/forum/Multiple_repos_on_same_path/comment_1_67ed823c4c40f5acf12b48eb75d7afa8._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="https://sunny256.wordpress.com/"
+ nickname="sunny256"
+ subject="Create symlink in the root directory"
+ date="2015-05-12T13:04:18Z"
+ content="""
+My way of dealing with this is to create a symlink in the root directory that point to the root directory, like
+
+[[!format sh \"\"\"
+$ cd /
+$ sudo ln -sv . compname
+[sudo] password for sunny: hunter2
+'compname' -> '.'
+$ ls -l compname
+lrwxrwxrwx 1 root root 1 May 12 14:52 compname -> .
+$
+\"\"\"]]
+
+where `compname` is the hostname for the computer. Now you can create paths like
+
+[[!format sh \"\"\"
+git remote add comp-a /comp-a/home/my_user/data/repo
+git remote add comp-b /comp-b/home/my_user/data/repo
+\"\"\"]]
+
+This is also useful in other scripts where fetching data from the right directory on the wrong computer is bad. Also, this is a cheap way for a script to determine which computer it's running on:
+
+[[!format sh \"\"\"
+test -L \"/comp-a\" && echo Running on computer comp-a
+\"\"\"]]
+
+"""]]
diff --git a/doc/forum/Multiple_repos_on_same_path/comment_2_e1c4ac71eb0f9ff6ae1701b3a6d738dd._comment b/doc/forum/Multiple_repos_on_same_path/comment_2_e1c4ac71eb0f9ff6ae1701b3a6d738dd._comment
new file mode 100644
index 0000000000..65a233c725
--- /dev/null
+++ b/doc/forum/Multiple_repos_on_same_path/comment_2_e1c4ac71eb0f9ff6ae1701b3a6d738dd._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-20T17:38:10Z"
+ content="""
+sunny256 has a nice approach with the symlinks to make the paths
+to the remores explicitly contain the machine name.
+
+However, if you want to keep it simple, it's perfectly fine for a
+remote's path to point to a directory which has different
+repositories mounted on it at different times. I do this in my own
+removable media drives, so the "host" remote uses /home/joey/sound,
+for example.
+
+This is safe to do because git-annex always checks the UUID of the
+remote before using it. For a local path like this, it will automatically
+update the cached annex-uuid of the remote when it finds a repo with a
+different UUID mounted. (For a path to a repo on a remote server, it uses
+other methods to verify that it's accessing the repo with the UUID it
+expected.)
+
+The only thing I'd be careful about doing is switching the repository that
+is mounted at a path with another one while git-annex is running, since it
+only checks at startup and won't notice the substitution and could get
+confused.
+"""]]
diff --git a/doc/forum/Multisession_compatible__63__.mdwn b/doc/forum/Multisession_compatible__63__.mdwn
new file mode 100644
index 0000000000..6c117a5ba5
--- /dev/null
+++ b/doc/forum/Multisession_compatible__63__.mdwn
@@ -0,0 +1,8 @@
+Thanks for the great tool!
+
+Is git-annex multisession compatible? I'm assuming that an "add" for example, will switch to the git-annex branch, commit data, and switch back to the previous branch. Is this protected by a Lock of some sort so that if two separate processes are interacting with the same repo/annex simultaneously there won't be any corruption?
+
+If not, is this something I could add within my python class that is implementing the interface to the Annex?
+
+Thanks,
+Mark
diff --git a/doc/forum/Multisession_compatible__63__/comment_1_dab5a92416314a7d4c02663d4e46cd60._comment b/doc/forum/Multisession_compatible__63__/comment_1_dab5a92416314a7d4c02663d4e46cd60._comment
new file mode 100644
index 0000000000..9dc228316a
--- /dev/null
+++ b/doc/forum/Multisession_compatible__63__/comment_1_dab5a92416314a7d4c02663d4e46cd60._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-02-04T16:30:30Z"
+ content="""
+git-annex has quite extensive locking, so it's entirely safe to run any
+combination of any git-annex commands at the same time.
+
+(It doesn't actually check out the git-annex branch when making commits to
+it BTW.)
+"""]]
diff --git a/doc/forum/Multisession_compatible__63__/comment_2_1c8d0f97d353c3e1d290edbe0a48b359._comment b/doc/forum/Multisession_compatible__63__/comment_2_1c8d0f97d353c3e1d290edbe0a48b359._comment
new file mode 100644
index 0000000000..1eedafdd54
--- /dev/null
+++ b/doc/forum/Multisession_compatible__63__/comment_2_1c8d0f97d353c3e1d290edbe0a48b359._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="mark@6b90344cdab3158eacb94a3944460d138afc9bef"
+ nickname="mark"
+ subject="comment 2"
+ date="2016-02-04T18:23:07Z"
+ content="""
+Thanks Joey for the response.
+
+This brings up two questions. 
+
+1) In my setup I have my own \"sync\" of just the git-annex branch with the remote after git annex operations. (I didn't want the master branch synch of \"git annex sync\". In this sync of mine I switch branches to do a pull/push on the git-annex branch. I found that I had to put file locks around all other git annex operations in order for things to keep from getting messed up in git. Is this because if I switch to another branch the git annex add (for example) won't work correctly even though it doesn't switch branches?
+
+2) I could avoid the whole issue if I could \"pull -rebase\" and push the git-annex branch without switching branches. Is there a way to do that?
+
+Thanks! -Mark
+"""]]
diff --git a/doc/forum/Multisession_compatible__63__/comment_2_c1dc4294cc2a43cfecfb7279d6411924._comment b/doc/forum/Multisession_compatible__63__/comment_2_c1dc4294cc2a43cfecfb7279d6411924._comment
new file mode 100644
index 0000000000..0d4c1505f3
--- /dev/null
+++ b/doc/forum/Multisession_compatible__63__/comment_2_c1dc4294cc2a43cfecfb7279d6411924._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-02-05T16:37:48Z"
+ content="""
+Well obviously if you have the git-annex branch checked out, any operation
+involving the work tree is not going to operate on the usual work tree.
+So obviously `git add` and `git annex add` are not going to do what you
+want them to do (unless you want them to add files to the checked-out
+git-annex branch). I'm not sure what other problems you might run into
+doing that.
+
+git-annex uses the .git/annex/index file to stage commits to the git-annex
+branch. Using that index file might help with rebasing or other operations
+on the branch. 
+
+It's certianly
+theoretically possible to rebase without touching the work tree and only
+using such an index file, but I don't know if git's rebase works that way.
+I also don't see any particular benefit to rebasing the git-annex branch.
+"""]]
diff --git a/doc/forum/Multisession_compatible__63__/comment_4_b7148c3afd31ce1effd135a4f7c92dbc._comment b/doc/forum/Multisession_compatible__63__/comment_4_b7148c3afd31ce1effd135a4f7c92dbc._comment
new file mode 100644
index 0000000000..6d0129fe6e
--- /dev/null
+++ b/doc/forum/Multisession_compatible__63__/comment_4_b7148c3afd31ce1effd135a4f7c92dbc._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="mark@6b90344cdab3158eacb94a3944460d138afc9bef"
+ nickname="mark"
+ subject="comment 4"
+ date="2016-02-05T17:32:22Z"
+ content="""
+Thanks again. Good information.
+
+So does \"git annex sync\" do any branch checkout?
+
+I'm using git annex to manage regression test outputs for audio. I don't want \"git annex sync\" because I want annex gets, etc. to be basically automatic. But I need to make sure when a test starts that the git-annex branch is up-to-date in case updated reference outputs were checked in elsewhere. So I want to sync the git-annex branch (but not the master because someone maybe locally testing code changes to vet the impact). I'm not a git expert, but it appears that you can't pull (or more specifically merge) outside of your working directory, so I'm simply switching branches to pull/push the git annex branch, but as we've discussed that isn't multisession safe.
+
+So, if you're able to do the git annex sync without a branch checkout, then there is hope that I can do a subset (just a sync of the git-annex branch) without a branch checkout.
+
+If I'm displaying a fundamental misunderstanding or missing something obvious, I'm all ears.
+"""]]
diff --git a/doc/forum/Multisession_compatible__63__/comment_5_d0ddac05268d978e950c91e76b023ffe._comment b/doc/forum/Multisession_compatible__63__/comment_5_d0ddac05268d978e950c91e76b023ffe._comment
new file mode 100644
index 0000000000..65a5694036
--- /dev/null
+++ b/doc/forum/Multisession_compatible__63__/comment_5_d0ddac05268d978e950c91e76b023ffe._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-02-05T17:34:37Z"
+ content="""
+`git annex sync` does not check out the git-annex branch; nothing in git-annex does.
+
+git-annex checks for any remote/git-annex branches that have not been
+merged yet and auto-merges them, whenever it's run. So, probably all you
+need to do is `git fetch` and possibly `git push` of the branch.
+"""]]
diff --git a/doc/forum/Multisession_compatible__63__/comment_6_e2319f774eda62600c27ab9d2d0d1e50._comment b/doc/forum/Multisession_compatible__63__/comment_6_e2319f774eda62600c27ab9d2d0d1e50._comment
new file mode 100644
index 0000000000..d85de4c977
--- /dev/null
+++ b/doc/forum/Multisession_compatible__63__/comment_6_e2319f774eda62600c27ab9d2d0d1e50._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="mark@6b90344cdab3158eacb94a3944460d138afc9bef"
+ nickname="mark"
+ subject="comment 6"
+ date="2016-02-05T18:18:58Z"
+ content="""
+Ah, that is very helpful information. I'll explore that. Any reason the fetch should not use the \"+\" to work with non-fast-forward updates?
+
+I greatly appreciate your time. Thanks!
+"""]]
diff --git a/doc/forum/Multisession_compatible__63__/comment_7_0e6c8ab32c589f0d971d4c208a8d1645._comment b/doc/forum/Multisession_compatible__63__/comment_7_0e6c8ab32c589f0d971d4c208a8d1645._comment
new file mode 100644
index 0000000000..49d21874f4
--- /dev/null
+++ b/doc/forum/Multisession_compatible__63__/comment_7_0e6c8ab32c589f0d971d4c208a8d1645._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="mark@6b90344cdab3158eacb94a3944460d138afc9bef"
+ nickname="mark"
+ subject="comment 7"
+ date="2016-02-05T22:35:19Z"
+ content="""
+Seems to be working with \"+\" fetch. I did have to put the fetch before the git annex commands and the push afterward or some of the changed git state from the git annex operations was lost (for example a drop and subsequent get wouldn't work because the drop wasn't probably tracked).
+
+Mark
+"""]]
diff --git a/doc/forum/Must_all_nodes_be_accessible_to_one_another__63__.mdwn b/doc/forum/Must_all_nodes_be_accessible_to_one_another__63__.mdwn
new file mode 100644
index 0000000000..fc06eb437c
--- /dev/null
+++ b/doc/forum/Must_all_nodes_be_accessible_to_one_another__63__.mdwn
@@ -0,0 +1,9 @@
+The [[walkthrough|https://git-annex.branchable.com/walkthrough/#index3h2]] says:
+
+> Notice that both repos are set up as remotes of one another. This lets either get annexed files from the other. You'll want to do that even if you are using git in a more centralized fashion.
+
+This is not always practical. I use a centralized setup where all of my devices sync (manually) with a bare repo on a server at home over the internet. Clients can access the server but the server cannot access the clients.
+
+Is it safe to use Git Annex in this way? Are there any pitfalls or gotchas I should be aware of? Is this setup any more (or less) risky when using a non-bare central repo?
+
+Thanks for this great piece of software!
diff --git a/doc/forum/Must_all_nodes_be_accessible_to_one_another__63__/comment_1_7af462f69b9efc3bbe18d0dbc839cb39._comment b/doc/forum/Must_all_nodes_be_accessible_to_one_another__63__/comment_1_7af462f69b9efc3bbe18d0dbc839cb39._comment
new file mode 100644
index 0000000000..f192a37757
--- /dev/null
+++ b/doc/forum/Must_all_nodes_be_accessible_to_one_another__63__/comment_1_7af462f69b9efc3bbe18d0dbc839cb39._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="weinzwang"
+ avatar="http://cdn.libravatar.org/avatar/e73d7d9e358f3b974d283fb0834cc5d9"
+ subject="Should be safe"
+ date="2021-09-21T07:55:57Z"
+ content="""
+I've been using git-annex with very similar setups for many years and never had any problems. I can't say anything about bare repos being more or less risky than non-bare ones, I've been using both on my server. Repos that can't see each other is a very common setup.
+"""]]
diff --git a/doc/forum/Must_all_nodes_be_accessible_to_one_another__63__/comment_2_882d9e6b7b2297dfd29266bbd429b046._comment b/doc/forum/Must_all_nodes_be_accessible_to_one_another__63__/comment_2_882d9e6b7b2297dfd29266bbd429b046._comment
new file mode 100644
index 0000000000..5fa717a92c
--- /dev/null
+++ b/doc/forum/Must_all_nodes_be_accessible_to_one_another__63__/comment_2_882d9e6b7b2297dfd29266bbd429b046._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-09-21T17:22:22Z"
+ content="""
+It is perfectly safe. It can take some additional configuration
+to get the clients sending the objects that the other clients want
+to the server.
+"""]]
diff --git a/doc/forum/My_first_impressions_after_some_weeks_with_git-annex_assistant.mdwn b/doc/forum/My_first_impressions_after_some_weeks_with_git-annex_assistant.mdwn
new file mode 100644
index 0000000000..0614554add
--- /dev/null
+++ b/doc/forum/My_first_impressions_after_some_weeks_with_git-annex_assistant.mdwn
@@ -0,0 +1,57 @@
+This post is a personal story, a bug report, and a feature request.
+
+I discovered `git-annex assistant` by accident a couple of weeks (months?) ago. I was very impressed by the technical smartness and decided it was worth a try. My current configuration (everything done through the assistant web GUI) is:
+
+* Two machines that act as client repositories and are usually in the same LAN. Both of them run OS X Mountain Lion.
+* One transfer repository which was Box.com, but then I switched to Amazon S3 (today, I’ll explain why).
+* The repository consists of mixed files and is ~4 GB big (very small plain text files, PDFs, some MP3 files, the biggest files are about 20–50 MB). The Finder reports that the repository is ~40 GB big while `du -sh` reports 4.4 GB. It’s probably just a silly Finder bug, but it would be great to know why this happens.
+* I have version 4.20130324 on both clients. The OS X versions seems to be always a little bit behind. It would be great if it could match with other platforms.
+
+Here are some issues which I think are worth mentioning:
+
+1. I had some issues with the assistant, because I initially launched it from the mounted DMG. `git-annex assistant` set the environment up, but it configured the wrong paths (to `/Volumes` instead `/Applications` where the bundle later went). This has caused issues with authentication and some ssh keys. `git-annex` was confused which keys to use and I had to manually remove the first ones from the `.ssh/` directory. This could be very confusing for technically not so savvy users, because the error messages in the GUI were confusing.
+
+2. I’m still very confused about the behavior of `git-annex assistant` when it launches. The application icon bounces in the Dock for quite a long time, then it looks like the process would’ve crashed (I can only *Force Quit* it from the Dock). Then the icon disappears after some minutes / half an hour. I was unsure if the assistant would run if I would *Force Quit* it (yes). The behavior is very strange on OS X. It would be great to have at least a normal icon which bounces a couple of times, stays in the Dock without appearing like a non-responding app, and that launches the web GUI when a user clicks on it. Optimal would be just a menu bar icon which would show the current progress, let me launch the web GUI, check for updates, pause & resume all transfers, and restart & quit `git-annex assistant`.
+
+3. The initial sync went great and pretty fast. I was also impressed by the speed `git-annex` picks up new changes and synchronizes them to other repositories. After adding the Box.com transfer repository everything got worse. Files that were added to one of the client repositories were never synced to the other machine, despite making sure that the client repositories appeared above the Box.com repository in `git-annex assistant`. The transfer was very slow (that’s probably due to the API rate limits of Box.com) and I got the impression that the files were uploaded multiple times (probably true, because the assistant couldn’t upload them in the first place and then just tried it again giving me the impression that it was stuck in some kind of loop). I tried to manually click on a couple of hundred play buttons in the queue in the hope that there would somewhere appear the item which should’ve been synced to the other machine in the first place. I also attached some log messages to the end of this post which could be helpful. At this point `git-annex assistant` basically stopped working for me. I lived somehow with it in the hope that it would upload everything to Box.com in the upcoming days, but it never got better, even after a couple of weeks (in the meantime we copied files manually over an attached network storage which lived outside of the repository). Today I bit the bullet and switched to Amazon S3. All files were uploaded in a couple of minutes and it looks like this setup would be more reliable. It’ll cost us a couple of $ each month, but it’s OK, because it actually works.
+
+4. I read somewhere that transfer repositories where meant to keep only files that are not present on all client repositories. With my configuration `git-annex` just uploads everything to the transfer repository (no matter if it’s Box.com or Amazon S3). Is this the correct behavior? Did I get something wrong or is this just not implemented yet? It’s OK in the current version, but it would be great to store only the missing files in the future.
+
+5. After I switched to Amazon S3 some encrypted file names appear in my queue. They are gone after I restart `git-annex assistant` or when I manually remove them with the `X` button. Is this a bug?
+
+6. It is confusing that the web GUI shows that the transfer failed when the second machine is offline. While technically this is true, it would be much more assuring to know that the client is just offline. If something fails I get the impression that it is broken, but the client was only unreachable and that’s just a temporary state that’ll get automatically fixed when the client goes online again. Adding green / red lights to the repository with a mouse over description would be probably a good idea. Reporting that the client is unreachable instead of showing the error message would also be more appropriate.
+
+7. The biggest issue I have now is that `git-annex assistant` randomly crashes on both machines. I don’t know if this is a known issue or if this an OS X only issue, but it is slightly annoying. If you want to make sure that files really synchronized, you’ve to start `git-annex assistant` just to check if it still runs. I hope that this will get fixed as soon as possible. I would love to help you with debug logs, but I don’t know where to look. There’s nothing meaningful in the system log or the debug log.
+
+8. If the issues with Box.com are because of their API rate limits, I would make this clearer when adding new Box.com repositories or I would remove the feature altogether, because they actually make `git-annex assistant` unusable.
+
+To sum everything up: my biggest issues so far are the constant crashes and the strange behavior of the Dock icon. I’m still pretty impressed by the technical smartness and that the software is available at all. Thank you very much—Joey—for letting us use this software on a daily basis. I’m glad that you launched the Kickstarter campaign. I don’t know if it’s much of a hassle, but a second Kickstarter to make sure that development will continue would be probably a good idea. I would like to help with logs, but I don’t know how. Please let me know if there’s something I can do.
+
+**Box.com logs:**
+
+    87%          16.0KB/s 2s[2013-04-22 15:14:35 CEST] Pusher: Syncing with 10.0.1.4_jcshared
+    To ssh://rafael@git-annex-10.0.1.4-rafael/~/jc-shared/
+       7428090..f0d2f9e  git-annex -> synced/git-annex
+       9d2cb35..1f7b678  master -> synced/master
+    Already up-to-date.
+    Already up-to-date.
+    gpg: [stdout]: write error: Broken pipe
+    gpg: DBG: deflate: iobuf_write failed
+    gpg: build_packet failed: file write error
+    gpg: [stdout]: write error: Broken pipe
+    gpg: iobuf_flush failed on close: file write error
+    gpg: symmetric encryption of `[stdin]' failed: file write error
+    ResponseTimeout
+    git-annex: fd:41: hPutBuf: resource vanished (Broken pipe)
+    ResponseTimeout
+    (gpg)
+    87%          16.0KB/s 2sgpg: [stdout]: write error: Broken pipe
+    gpg: DBG: deflate: iobuf_write failed
+    gpg: build_packet failed: file write error
+    gpg: [stdout]: write error: Broken pipe
+    gpg: iobuf_flush failed on close: file write error
+    gpg: symmetric encryption of `[stdin]' failed: file write error
+    ResponseTimeout
+    git-annex: fd:54: hPutBuf: resource vanished (Broken pipe)
+    send: resource vanished (Connection reset by peer)
+    ResponseTimeout
diff --git a/doc/forum/My_first_impressions_after_some_weeks_with_git-annex_assistant/comment_1_9d4019a54fb508e286a5d6d2660361d9._comment b/doc/forum/My_first_impressions_after_some_weeks_with_git-annex_assistant/comment_1_9d4019a54fb508e286a5d6d2660361d9._comment
new file mode 100644
index 0000000000..10e10e06c4
--- /dev/null
+++ b/doc/forum/My_first_impressions_after_some_weeks_with_git-annex_assistant/comment_1_9d4019a54fb508e286a5d6d2660361d9._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-23T21:41:31Z"
+ content="""
+This is a lot of stuff. It would be better to file individual detailed bug reports if you want any of this looked at in depth. Otherwise, I just read it to get an impression of how things are working, or not, for you, and try to hit some of the main points:
+
+* The OSX app icon behavior is probably because OSX does not realize that this is supposed to be a daemon. I don't know how to fix that. Clicking on the app icon is supposed to launch the web app, and has been reported to do so by others. I have no access to an OSX desktop.
+
+* Transfer repositories only keep files that have not yet reached all your client repositories. However, it's possible that files
+  may be uploaded to a transfer repository unnecessarily (if there is some other path for the file to get to the other client
+  repositories, ie if you've locally paired them). In this case, the file will be uploaded and then later removed from the transfer
+  repository, without being used.
+
+* I have never seen encrypted filenames appear in the webapp. I don't see how that could happen TBH.
+
+* git-annex logs information to `.git/annex/debug.log` within your repository. You can go to Configuration -> Preferences to enable
+  additional debug logging. I absolutely need these logs to help debug almost any problems with the assistant.
+
+* \"Clicking a couple of hundred play buttons\" could result in it trying to make a couple of hundred uploads to box.com
+  at the same time. This is probably not a good idea.
+
+* The fragment of log you posted shows me some problem that caused gpg to fail to encrypt a file before sending it to somewhere,
+  but it's lacking all context (and starts when the file transfer is already 87% complete!) so I can't say more. I need to see the whole log to make any informed guesses about what might be going on.
+"""]]
diff --git a/doc/forum/My_first_impressions_after_some_weeks_with_git-annex_assistant/comment_2_109534a45881ce94a4586c8a83945f9f._comment b/doc/forum/My_first_impressions_after_some_weeks_with_git-annex_assistant/comment_2_109534a45881ce94a4586c8a83945f9f._comment
new file mode 100644
index 0000000000..33b2aa393e
--- /dev/null
+++ b/doc/forum/My_first_impressions_after_some_weeks_with_git-annex_assistant/comment_2_109534a45881ce94a4586c8a83945f9f._comment
@@ -0,0 +1,85 @@
+[[!comment format=mdwn
+ username="EmanueleAina"
+ ip="93.38.211.231"
+ subject="comment 2"
+ date="2013-09-11T17:55:14Z"
+ content="""
+I seem to hit the same issue (`ResponseTimeout`) on box.com, but I don't have any log file under .git/annex.
+
+The timeout is quite unpredictable, sometimes I'm able to transfer less than 20% of the file while sometimes it fails after reaching 51%. The file is quite big, 6.2G.
+
+Unfortunately, after the first upload fails, `git-annex` seems to think that the file has been uploaded successfully and will refuse to copy it again. Even `whereis` will list the box.com location.
+
+I think there are really two bugs: the one triggering the timeouts, and the fact that `git-annex` thinks that the failing upload succeeded and is unable to recover the interrupted upload.
+
+Here's the log I got on the shell. Let me know how I can provide any additional information needed. Thanks!
+
+	$ git annex copy --verbose --debug home.tar.gz --to box.com
+	[2013-09-11 17:42:52 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"show-ref\",\"git-annex\"]
+	[2013-09-11 17:42:52 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+	[2013-09-11 17:42:52 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"log\",\"refs/heads/git-annex..1e029f92c5c82b094cbe70b55927996c31579e2e\",\"--oneline\",\"-n1\"]
+	[2013-09-11 17:42:52 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"log\",\"refs/heads/git-annex..1090c21b121fd8b6e2ab49a772c8eab5235a3930\",\"--oneline\",\"-n1\"]
+	[2013-09-11 17:42:52 CEST] chat: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"cat-file\",\"--batch\"]
+	[2013-09-11 17:42:52 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"home.tar.gz\"]
+	copy home.tar.gz (gpg) [2013-09-11 17:42:52 CEST] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"]
+	(checking box.com...) (to box.com...) 
+	[2013-09-11 17:42:57 CEST] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"11\",\"--symmetric\",\"--force-mdc\",\"--no-textmode\"]
+	35%      660.8KB/s 1h44mResponseTimeout
+	gpg: [stdout]: write error: Broken pipe
+	gpg: DBG: deflate: iobuf_write failed
+	gpg: build_packet failed: file write error
+	gpg: [stdout]: write error: Broken pipe
+	gpg: iobuf_flush failed on close: file write error
+	gpg: [stdout]: write error: Broken pipe
+	gpg: iobuf_flush failed on close: file write error
+	gpg: symmetric encryption of `[stdin]' failed: file write error
+	git-annex: fd:13: hPutBuf: resource vanished (Broken pipe)
+	failed
+	git-annex: copy: 1 failed
+	$ git annex copy --verbose --debug home.tar.gz --to box.com
+	[2013-09-11 19:38:26 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"show-ref\",\"git-annex\"]
+	[2013-09-11 19:38:26 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+	[2013-09-11 19:38:26 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"log\",\"refs/heads/git-annex..1e029f92c5c82b094cbe70b55927996c31579e2e\",\"--oneline\",\"-n1\"]
+	[2013-09-11 19:38:26 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"log\",\"refs/heads/git-annex..1090c21b121fd8b6e2ab49a772c8eab5235a3930\",\"--oneline\",\"-n1\"]
+	[2013-09-11 19:38:26 CEST] chat: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"cat-file\",\"--batch\"]
+	[2013-09-11 19:38:26 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"home.tar.gz\"]
+	copy home.tar.gz (gpg) [2013-09-11 19:38:26 CEST] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"]
+	(checking box.com...) ok
+	$ git annex whereis --verbose --debug home.tar.gz             
+	[2013-09-11 19:38:57 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"show-ref\",\"git-annex\"]
+	[2013-09-11 19:38:57 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+	[2013-09-11 19:38:57 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"log\",\"refs/heads/git-annex..1e029f92c5c82b094cbe70b55927996c31579e2e\",\"--oneline\",\"-n1\"]
+	[2013-09-11 19:38:57 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"log\",\"refs/heads/git-annex..1090c21b121fd8b6e2ab49a772c8eab5235a3930\",\"--oneline\",\"-n1\"]
+	[2013-09-11 19:38:57 CEST] chat: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"cat-file\",\"--batch\"]
+	[2013-09-11 19:38:57 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"home.tar.gz\"]
+	whereis home.tar.gz (2 copies) 
+		d7db543e-5463-11e2-b7dd-9f423f798cc4 -- here (em@ocracy:/data/backup)
+		e71fa45e-5463-11e2-a14e-93ca09c272da -- box.com
+	ok
+	$ git annex fsck --verbose --debug home.tar.gz
+	[2013-09-11 19:39:05 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"home.tar.gz\"]
+	[2013-09-11 19:39:05 CEST] chat: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.numcopies\",\"--\"]
+	fsck home.tar.gz [2013-09-11 19:39:05 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"show-ref\",\"git-annex\"]
+	[2013-09-11 19:39:05 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+	[2013-09-11 19:39:05 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"log\",\"refs/heads/git-annex..1e029f92c5c82b094cbe70b55927996c31579e2e\",\"--oneline\",\"-n1\"]
+	[2013-09-11 19:39:05 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"log\",\"refs/heads/git-annex..1090c21b121fd8b6e2ab49a772c8eab5235a3930\",\"--oneline\",\"-n1\"]
+	[2013-09-11 19:39:05 CEST] chat: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"cat-file\",\"--batch\"]
+	(checksum...) [2013-09-11 19:39:05 CEST] read: sha256sum [\"/data/backup/.git/annex/objects/mG/kp/SHA256E-s6640317400--dcf0a535728f3f3f787db6339b740a4a6f6529e5ce1d238f28574499a8172670.tar.gz/SHA256E-s6640317400--dcf0a535728f3f3f787db6339b740a4a6f6529e5ce1d238f28574499a8172670.tar.gz\"]
+	ok
+	$ git annex fsck --verbose --debug home.tar.gz --from box.com
+	[2013-09-11 19:42:15 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"show-ref\",\"git-annex\"]
+	[2013-09-11 19:42:15 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+	[2013-09-11 19:42:15 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"log\",\"refs/heads/git-annex..1e029f92c5c82b094cbe70b55927996c31579e2e\",\"--oneline\",\"-n1\"]
+	[2013-09-11 19:42:15 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"log\",\"refs/heads/git-annex..1090c21b121fd8b6e2ab49a772c8eab5235a3930\",\"--oneline\",\"-n1\"]
+	[2013-09-11 19:42:15 CEST] chat: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"cat-file\",\"--batch\"]
+	[2013-09-11 19:42:15 CEST] read: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"home.tar.gz\"]
+	[2013-09-11 19:42:15 CEST] chat: git [\"--git-dir=/data/backup/.git\",\"--work-tree=/data/backup\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.numcopies\",\"--\"]
+	fsck home.tar.gz (gpg) [2013-09-11 19:42:15 CEST] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"]
+	(checking box.com...) 
+	[2013-09-11 19:42:28 CEST] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"10\",\"--decrypt\"]
+	gpg: decrypt_message failed: eof
+	ok
+
+
+
+"""]]
diff --git a/doc/forum/NTFS_drive_mounted_on_Linux.mdwn b/doc/forum/NTFS_drive_mounted_on_Linux.mdwn
new file mode 100644
index 0000000000..a34dc13022
--- /dev/null
+++ b/doc/forum/NTFS_drive_mounted_on_Linux.mdwn
@@ -0,0 +1,6 @@
+Maybe someone here can help me with this. I'm trying out git-annex as a way to handle my photo collection. My case is as follows.
+I have a laptop running Manjaro. I have my photo collection on a USB drive formatted NTFS so I can also use it on Windows systems. I'd like to use git-annex to selectively check out files from that drive to my laptop. The files are (immutable) .NEF raw files and .xmp text files that I could track with regular git.
+
+The problem is that NTFS mounted on Linux does not seem to honour the write bit, so git-annex detects a crippled file system and defaults to unlocked mode. Effectively this halves the storage capacity of my external drive (with every file in both the annex and the working directory), which is of course less than ideal.
+
+Is there a way to handle this? Did I configure my mounting options incorrectly, or is git-annex not the right tool for this job and should I just use rsync?
diff --git a/doc/forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote.mdwn b/doc/forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote.mdwn
new file mode 100644
index 0000000000..d7867f9870
--- /dev/null
+++ b/doc/forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote.mdwn
@@ -0,0 +1,29 @@
+There are SSH keys in ~/.ssh to a remote server that I added as a git annex remote. On my Debian box, I am able to `git annex copy` and `git annex move` to and from the remote to a local repo at `~/archive` with no problems. I also have no problems with external USB drives formatted ext4. 
+
+I have an external usb drive formatted NTFS that I connect to a Debian box. I added the remote server like the others and when I try to copy or move to and from it, this error code shows up. 
+
+
+
+    pull archive 
+    Control socket connect(.git/annex/ssh/f7be67fcc0a6f016ba90edcdd8e02e1f): Connection refused
+    Failed to connect to new control master
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+    failed
+    push archive 
+    Control socket connect(.git/annex/ssh/f7be67fcc0a6f016ba90edcdd8e02e1f): Connection refused
+    Failed to connect to new control master
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+
+    Pushing to archive failed.
+
+
+
+I think it is because of NTFS and the ssh key stored in `~/.ssh`, but I don't know what is going on. 
+
+Thanks!
diff --git a/doc/forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote/comment_1_b2d2bf6be441dc2e4443d06ef8db7134._comment b/doc/forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote/comment_1_b2d2bf6be441dc2e4443d06ef8db7134._comment
new file mode 100644
index 0000000000..d5a0d6460a
--- /dev/null
+++ b/doc/forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote/comment_1_b2d2bf6be441dc2e4443d06ef8db7134._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawksOCeakibYmGDt3wLLo4nkY0FkB72I2Uo"
+ nickname="Source"
+ subject="comment 1"
+ date="2015-03-07T02:50:19Z"
+ content="""
+I think I have tracked down part of the issue. It due to the options that are called by `git-annex` when trying to `rsync` between the NTFS local hard drive and the SSH remote. 
+
+I got `rsync` to work by using `rsync -vrc source dest` as options (outside of git-annex). Found [here](http://askubuntu.com/questions/112863/rsync-not-working-between-ntfs-fat-and-ext).
+
+Is there any way to change the rsync options put out by git-annex when copying/moving to and from local ntfs drives on linux?
+"""]]
diff --git a/doc/forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote/comment_2_75abe6da74cd0432e616e391f5be6fe3._comment b/doc/forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote/comment_2_75abe6da74cd0432e616e391f5be6fe3._comment
new file mode 100644
index 0000000000..49dd5f4ef2
--- /dev/null
+++ b/doc/forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote/comment_2_75abe6da74cd0432e616e391f5be6fe3._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-03-16T17:14:50Z"
+ content="""
+This control socket message sounds like the actual problem is
+that unix sockets cannot be used on this filesystem. git-annex
+puts the socket there to make ssh connection caching work.
+
+So, I think you need to disable ssh connection caching: 
+`git config annex.sshcaching false`
+
+I was able to reproduce a similar failure on nfts on linux.
+"""]]
diff --git a/doc/forum/Need_new_build_instructions_for_Debian_stable.mdwn b/doc/forum/Need_new_build_instructions_for_Debian_stable.mdwn
new file mode 100644
index 0000000000..7db19697c3
--- /dev/null
+++ b/doc/forum/Need_new_build_instructions_for_Debian_stable.mdwn
@@ -0,0 +1,5 @@
+The instructions for building git-annex on [[install/Debian]] stable don't seem to be valid anymore.
+
+1. `dpkg-checkbuilddeps` is looking for the wrong packages, e.g. libghc-missingh-dev instead of libghc6-missingh-dev.
+
+2. Not all dependencies are available in the Squeeze repositories anymore (at least not Crypto and hS3), if I am not mistaken.
diff --git a/doc/forum/Need_new_build_instructions_for_Debian_stable/comment_1_8c1eea6dfec8b7e1c7a371b6e9c26118._comment b/doc/forum/Need_new_build_instructions_for_Debian_stable/comment_1_8c1eea6dfec8b7e1c7a371b6e9c26118._comment
new file mode 100644
index 0000000000..e464c84da1
--- /dev/null
+++ b/doc/forum/Need_new_build_instructions_for_Debian_stable/comment_1_8c1eea6dfec8b7e1c7a371b6e9c26118._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-04-26T15:27:49Z"
+ content="""
+I have updated the instructions.
+"""]]
diff --git a/doc/forum/Need_new_build_instructions_for_Debian_stable/comment_2_f6ff8306c946219dbe39bb8938a349ab._comment b/doc/forum/Need_new_build_instructions_for_Debian_stable/comment_2_f6ff8306c946219dbe39bb8938a349ab._comment
new file mode 100644
index 0000000000..40f570610a
--- /dev/null
+++ b/doc/forum/Need_new_build_instructions_for_Debian_stable/comment_2_f6ff8306c946219dbe39bb8938a349ab._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="gernot"
+ ip="213.196.216.21"
+ subject="comment 2"
+ date="2011-04-26T18:56:44Z"
+ content="""
+Thanks for the update, Joey. I think you forgot to change libghc-missingh-dev to libghc6-missingh-dev for the copy & paste instructions though.
+
+Also, after having checked that I have everything installed I'm still getting this error:
+
+	...
+	[15 of 77] Compiling Annex            ( Annex.hs, Annex.o )
+
+	Annex.hs:19:35:
+		Module `Control.Monad.State' does not export `state'
+	make[1]: *** [git-annex] Error 1
+	make[1]: Leaving directory `/home/gernot/dev/git-annex'
+	dh_auto_build: make -j1 returned exit code 2
+	make: *** [binary] Error 2
+
+"""]]
diff --git a/doc/forum/Need_new_build_instructions_for_Debian_stable/comment_3_bcda70cbfc7c1a14fa82da70f9f876e2._comment b/doc/forum/Need_new_build_instructions_for_Debian_stable/comment_3_bcda70cbfc7c1a14fa82da70f9f876e2._comment
new file mode 100644
index 0000000000..8b41116431
--- /dev/null
+++ b/doc/forum/Need_new_build_instructions_for_Debian_stable/comment_3_bcda70cbfc7c1a14fa82da70f9f876e2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-04-26T23:40:33Z"
+ content="""
+Both problems fixed.
+"""]]
diff --git a/doc/forum/Need_some_help_installing_on_freeBSD.mdwn b/doc/forum/Need_some_help_installing_on_freeBSD.mdwn
new file mode 100644
index 0000000000..8a2e7a13ae
--- /dev/null
+++ b/doc/forum/Need_some_help_installing_on_freeBSD.mdwn
@@ -0,0 +1,48 @@
+Hi there,
+
+**I'm trying to install git-annex on my NAS which is freeNAS running freeBSD. 
+I've created a jail for it and installed via: pkg install hs-git-annex**
+
+I've seen on this page: http://www.freshports.org/devel/hs-git-annex/ that there are Configuration Options. 
+I assume to use those I'd have to have compiled it myself from the ports like this: 
+To install the port: cd /usr/ports/devel/hs-git-annex/ && make install clean
+
+So in this case of using the pkg, how can I check the way git-annex was compiled? 
+Anyone else ever used it on freeBSD and can give some input please? 
+
+**Figured out how to see this info:**
+
+git-annex version
+git-annex version: 5.20150727
+build flags: Assistant Webapp Webapp-secure Pairing S3 WebDAV Kqueue XMPP DNS Feeds Quvi TDFA Database
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+
+**So apparently box.com isn't supported in this build?**
+
+I installed via a web terminal, not via a normal ssh connection so when I came back the installation with all dependencies was finished but I couldn't scroll back to see all warning, only caught this last part of the screen; anyone got any idea if git-annex is supposed to run fine on FreeBSD 9.3-RELEASE-p26 amd64? 
+
+**part of the text I caught:**
+  IN_CLOSE_WRITE                                                               
+                                                                                
+Symbolic Link notifications:                                                    
+   IN_DONT_FOLLOW                                                               
+   IN_ATTRIB                                                                    
+   IN_MOVE_SELF                                                                 
+   IN_DELETE_SELF                                                               
+                                                                                
+Kernel patches to address the missing directory and symbolic link               
+notifications are available from:                                               
+                                                                                
+https://github.com/dmatveev/libinotify-kqueue/tree/master/patches               
+                                                                                
+=============================================================================   
+You might want to consider increasing the kern.maxfiles tunable if you plan     
+to use this library for applications that need to monitor activity of a lot     
+of files.                                                                       
+                                                                                
+If the default on your system is too low, add the following line to             
+/boot/loader.conf, then reboot the system:                                      
+                                                                                
+    kern.maxfiles="25000"                                                       
+============================================================================= 
diff --git a/doc/forum/Need_some_help_installing_on_freeBSD/comment_1_3962871e646280e2c4fdff8a08bed485._comment b/doc/forum/Need_some_help_installing_on_freeBSD/comment_1_3962871e646280e2c4fdff8a08bed485._comment
new file mode 100644
index 0000000000..58186a9b16
--- /dev/null
+++ b/doc/forum/Need_some_help_installing_on_freeBSD/comment_1_3962871e646280e2c4fdff8a08bed485._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 1"
+ date="2015-10-05T18:53:20Z"
+ content="""
+it also seems like the git annex webapp command needs lsof, had to install it separately.
+
+I then figured out one has to start the webapp with a listen command to prevent it from opening a browser.
+*git annex webapp --listen=internal_IP*
+
+Not sure how this option will work: Start the git-annex assistant at boot or on login. - as I assume I get a different auth URL with every start?
+Any help available to get *git annex webapp --listen=internal_IP* to auto-start with every reboot?
+"""]]
diff --git a/doc/forum/Need_some_help_installing_on_freeBSD/comment_2_528fdd2c385809b971eceee1eb70ee38._comment b/doc/forum/Need_some_help_installing_on_freeBSD/comment_2_528fdd2c385809b971eceee1eb70ee38._comment
new file mode 100644
index 0000000000..414d4518f1
--- /dev/null
+++ b/doc/forum/Need_some_help_installing_on_freeBSD/comment_2_528fdd2c385809b971eceee1eb70ee38._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 2"
+ date="2015-10-05T19:07:51Z"
+ content="""
+oh, and once I closed the webapp, I saw on the console that it needed more info:
+
+git config --global user.email \"you@example.com\"
+git config --global user.name \"Your Name\"
+"""]]
diff --git a/doc/forum/Need_some_help_installing_on_freeBSD/comment_3_5ae3cd6e24a25d6dc803ec2adea0414f._comment b/doc/forum/Need_some_help_installing_on_freeBSD/comment_3_5ae3cd6e24a25d6dc803ec2adea0414f._comment
new file mode 100644
index 0000000000..080c22a4de
--- /dev/null
+++ b/doc/forum/Need_some_help_installing_on_freeBSD/comment_3_5ae3cd6e24a25d6dc803ec2adea0414f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-10-06T20:05:24Z"
+ content="""
+The WebDAV support means it does support box.com. Looking at the
+version info, this freebsd build seems to have more or less every possible
+option enabled. Nice job freebsd porters!
+"""]]
diff --git a/doc/forum/Need_some_help_installing_on_freeBSD/comment_4_1dcc43aaad2099bb1684873d24da668f._comment b/doc/forum/Need_some_help_installing_on_freeBSD/comment_4_1dcc43aaad2099bb1684873d24da668f._comment
new file mode 100644
index 0000000000..3b8f06f05d
--- /dev/null
+++ b/doc/forum/Need_some_help_installing_on_freeBSD/comment_4_1dcc43aaad2099bb1684873d24da668f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-10-06T20:07:43Z"
+ content="""
+To start the assistant, use "git annex assistant". You
+can then run "git annex webapp" as desired to open the webapp,
+communicating with the assistant if it was already running.
+"""]]
diff --git a/doc/forum/Need_some_help_installing_on_freeBSD/comment_5_527bf6df2485c5e906f1d50930ec01fe._comment b/doc/forum/Need_some_help_installing_on_freeBSD/comment_5_527bf6df2485c5e906f1d50930ec01fe._comment
new file mode 100644
index 0000000000..5351794710
--- /dev/null
+++ b/doc/forum/Need_some_help_installing_on_freeBSD/comment_5_527bf6df2485c5e906f1d50930ec01fe._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 5"
+ date="2015-10-07T20:12:20Z"
+ content="""
+thanks, I'll try and use only the assistant, not the webapp on the NAS, any links on how to get started apart from typing git annex? 
+any first steps to take, a particular order in which to do things?
+"""]]
diff --git a/doc/forum/Need_some_help_to_fix_my_repository.mdwn b/doc/forum/Need_some_help_to_fix_my_repository.mdwn
new file mode 100644
index 0000000000..e4f6fb593f
--- /dev/null
+++ b/doc/forum/Need_some_help_to_fix_my_repository.mdwn
@@ -0,0 +1,31 @@
+Hi, 
+first sorry for my poor english it's not my native language.
+
+I have one repository on my laptop and two repository on usb disk. Made with following  walkthrough (creating a repository and adding a remote).
+
+Yesterday I have a backup of my repository on usb disk before add some file with
+
+cd /media/usb/annex;git fetch laptop; git merge laptop/master&&git annex get .&&git annex sync
+
+Now the repository on my usb disk is a mess.
+Every file before the commit are lost. 
+For example : 
+ After the sync : file Z.7z 
+Z.7z: broken symbolic link to `../../../../.git/annex/objects/2K/49/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
+
+The file ../../../../.git/annex/objects/2K/49/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 doesn't exist.
+
+On the repository before the sync (inside the Backup) :
+file Z.7z 
+Z.7z: symbolic link to `../../../../.git/annex/objects/J1/f4/SHA256-s696365035--d2dcc67bf2f05fcfc7f42723b2d415d4f057a2eeadc282b40f5bc3724534f2f4/SHA256-s696365035--d2dcc67bf2f05fcfc7f42723b2d415d4f057a2eeadc282b40f5bc3724534f2f4'
+
+The file ../../../../.git/annex/objects/J1/f4/SHA256-s696365035--d2dcc67bf2f05fcfc7f42723b2d415d4f057a2eeadc282b40f5bc3724534f2f4/SHA256-s696365035--d2dcc67bf2f05fcfc7f42723b2d415d4f057a2eeadc282b40f5bc3724534f2f4  still exist in the repository after the sync.
+
+3 questions, if somebody could help me :
+
+ - what I do wrong ?
+ - why the- symlink for every file had change after "cd /media/usb/annex;git fetch laptop; git merge laptop/master&&git annex get .&&git annex sync"
+ - how could I fix my repository ? recover file from the backup ? how ? Copy every file to start my repository from a new clean state ?
+ 
+
+
diff --git a/doc/forum/Need_some_help_to_fix_my_repository/comment_1_f0d279c530b796b2c93d793f85d147e8._comment b/doc/forum/Need_some_help_to_fix_my_repository/comment_1_f0d279c530b796b2c93d793f85d147e8._comment
new file mode 100644
index 0000000000..6f9a8078f9
--- /dev/null
+++ b/doc/forum/Need_some_help_to_fix_my_repository/comment_1_f0d279c530b796b2c93d793f85d147e8._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-22T20:00:12Z"
+ content="""
+1. Use `git log --stat` to find the commit that changed your file `Z.7z`
+2. Use `git revert` to revert that commit
+
+That will put things back the way they were.
+
+You should then investigate what caused the bad commit to be made. It seems to have involved the file being reset to be 0 bytes in size.
+"""]]
diff --git a/doc/forum/Need_some_help_to_fix_my_repository/comment_2_a3fcfa1f8eadec5fa8a9efacca174048._comment b/doc/forum/Need_some_help_to_fix_my_repository/comment_2_a3fcfa1f8eadec5fa8a9efacca174048._comment
new file mode 100644
index 0000000000..bded393bf0
--- /dev/null
+++ b/doc/forum/Need_some_help_to_fix_my_repository/comment_2_a3fcfa1f8eadec5fa8a9efacca174048._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkyQL8VPwrSf8LA0k8PKDWFCEKFH3O5Jds"
+ nickname="marco"
+ subject="Brvo"
+ date="2013-04-22T23:33:10Z"
+ content="""
+Bravo. Mon Hero.
+
+You save my data ! I can't find what happen but thanks a lot.
+"""]]
diff --git a/doc/forum/Need_some_help_to_fix_my_repository/comment_3_7878f9b76ddfa3392c9ec6a1810cb745._comment b/doc/forum/Need_some_help_to_fix_my_repository/comment_3_7878f9b76ddfa3392c9ec6a1810cb745._comment
new file mode 100644
index 0000000000..67657110a4
--- /dev/null
+++ b/doc/forum/Need_some_help_to_fix_my_repository/comment_3_7878f9b76ddfa3392c9ec6a1810cb745._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="glad I could help"
+ date="2013-04-23T21:16:47Z"
+ content="""
+I'm curious if your repository is using direct mode, and is perhaps on a FAT filesystem, or other filesystem that does not support symlinks?
+
+One way this could have happened is due to a bug in `git annex sync` when used on such a filesystem. I've just fixed this bug in commit 07580dc3dfb2f4d9af9a20bc172cbc32953c49d6
+"""]]
diff --git a/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__.mdwn b/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__.mdwn
new file mode 100644
index 0000000000..3584569b64
--- /dev/null
+++ b/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__.mdwn
@@ -0,0 +1,23 @@
+I've two huge annex repos (about 100G) with all my photos.
+One is on my laptop and it uses indirect mode; the other one is on my NAS and I mount it into a CIFS folder, then it uses direct mode because of the crippled fs.
+Each repo is remote of the other one. The NAS repo belongs to backup group with the standard preferred content.
+I changed about 1000 photos in my PC repo (mainly renamed them) and I wanted to sync changes to the NAS repo, so I went through this sequence:
+
+* "git annex add" and "git annex sync" on my PC => OK;
+
+* "git annex sync" on the NAS repo => it started copying all the content BUT I stopped it because I had not enough time to wait at that very moment;
+
+* again "git anne sync" on the NAS repo => I had more time to wait BUT it didn't resume the copy from the PC repo, it just said something like "all done, nothing to do"
+
+* I checked that several files were missing on the NAS that I had modified/renamed on the PC repo so I did "git annex add" again on the PC => nothing new to add, nothing to do;
+
+* I did again "git annex sync" on the PC repo => it deleted also from my PC repo all the photos that were also missing on the NAS repo;
+
+* I've also checked for unused files on the PC repo and it now gives about 1000 files.
+
+So here are my questions:
+
+1. where was I wrong?
+
+2. can I restore my photos on my PC repo (which uses indirect mode) ?
+
diff --git a/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_1_af0ed0730645c1e3c9a4946acd48c18a._comment b/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_1_af0ed0730645c1e3c9a4946acd48c18a._comment
new file mode 100644
index 0000000000..8f2905c6f3
--- /dev/null
+++ b/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_1_af0ed0730645c1e3c9a4946acd48c18a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-06-06T18:18:36Z"
+ content="""
+It's not clear from your description when the files got deleted or why, but you can use `git log --stat` to find out. Then you can `git revert` the problem commit.
+"""]]
diff --git a/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_2_12f3c2bb2458b69e6355c8f94bab868f._comment b/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_2_12f3c2bb2458b69e6355c8f94bab868f._comment
new file mode 100644
index 0000000000..4c30d0f4c5
--- /dev/null
+++ b/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_2_12f3c2bb2458b69e6355c8f94bab868f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="feulif"
+ ip="151.27.145.89"
+ subject="Thank you"
+ date="2014-06-08T08:36:40Z"
+ content="""
+Thank you so much!
+That solved my problem and restored my precious photos!
+
+Now I see there are similar issues in the forum already, but I was searching for the bad keywords (like \"restore unused\") and I could not find them.
+
+By the way, your software is outstanding.
+"""]]
diff --git a/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_3_b233b4daac32c452776e1e3d9a29f2cc._comment b/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_3_b233b4daac32c452776e1e3d9a29f2cc._comment
new file mode 100644
index 0000000000..faec248bfb
--- /dev/null
+++ b/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_3_b233b4daac32c452776e1e3d9a29f2cc._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-06-09T19:44:49Z"
+ content="""
+What did the bad commit that you ended up reverting look like?
+
+It seems to me that something must have went wrong due to your interrupting the first sync on the NAS. Perhaps this left it with newly added files not yet moved into place in the tree. So the next time you synced, this would cause it to see that the files seemed to have been deleted and make a commit reflecting that.
+
+This, then is a bug in how direct mode handles merges. [[bugs/direct_mode_merge_interrupt]]
+"""]]
diff --git a/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_4_8e079e92929dcfdf19f6adec16f800e5._comment b/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_4_8e079e92929dcfdf19f6adec16f800e5._comment
new file mode 100644
index 0000000000..0e079a6944
--- /dev/null
+++ b/doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_4_8e079e92929dcfdf19f6adec16f800e5._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="feulif"
+ ip="151.27.145.89"
+ subject="comment 4"
+ date="2014-06-10T18:43:34Z"
+ content="""
+Here is the log of the \"bad\" commit:
+
+    commit 38e0e1ef009b820f008b46f53c24d9835ca0f9a6
+    Author: me <me@myself.com>
+    Date:   Wed Jun 4 00:04:37 2014 +0200
+    
+    git-annex automatic sync
+
+     folder/subfolder1/subfolder2/photo.jpg          | 1 +
+     [...]
+     [...]
+     [...]
+     folder/subfolder1/subfolderN/video.MOV          | 1 +
+     2266 files changed, 2266 insertions(+)
+
+I stopped (ctrl-c) when it was adding the video.
+"""]]
diff --git a/doc/forum/New_Arch_Linux_package_for_git-annex.mdwn b/doc/forum/New_Arch_Linux_package_for_git-annex.mdwn
new file mode 100644
index 0000000000..30deda362a
--- /dev/null
+++ b/doc/forum/New_Arch_Linux_package_for_git-annex.mdwn
@@ -0,0 +1,7 @@
+I have added a new git-annex package in Arch Linux's official repository [1]. I plan to keep it tracking latest release, and the delay should be within a few days after a new release appears.
+
+It would be great to update the installation instructions for Arch,  also please let me know if there is any problem with the package.
+
+Thank you!
+
+[1] https://www.archlinux.org/packages/community/x86_64/git-annex/
diff --git a/doc/forum/New_Arch_Linux_package_for_git-annex/comment_1_5881a5974ec1c4f701775c30b814ee2f._comment b/doc/forum/New_Arch_Linux_package_for_git-annex/comment_1_5881a5974ec1c4f701775c30b814ee2f._comment
new file mode 100644
index 0000000000..39bed8dabe
--- /dev/null
+++ b/doc/forum/New_Arch_Linux_package_for_git-annex/comment_1_5881a5974ec1c4f701775c30b814ee2f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-15T17:06:09Z"
+ content="""
+This looks nice.. You can edit the install page yourself; this is a wiki.
+"""]]
diff --git a/doc/forum/New_Arch_Linux_package_for_git-annex/comment_2_f41f9248f4d5039309e8fd98524e86bc._comment b/doc/forum/New_Arch_Linux_package_for_git-annex/comment_2_f41f9248f4d5039309e8fd98524e86bc._comment
new file mode 100644
index 0000000000..ac0a1db71c
--- /dev/null
+++ b/doc/forum/New_Arch_Linux_package_for_git-annex/comment_2_f41f9248f4d5039309e8fd98524e86bc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~felixonmars"
+ nickname="felixonmars"
+ subject="comment 2"
+ date="2016-01-16T11:35:22Z"
+ content="""
+Thanks. I have updated the page :)
+"""]]
diff --git a/doc/forum/New_Arch_Linux_package_for_git-annex/comment_3_ab1f6e45625e6ab80770d4ff65ec4242._comment b/doc/forum/New_Arch_Linux_package_for_git-annex/comment_3_ab1f6e45625e6ab80770d4ff65ec4242._comment
new file mode 100644
index 0000000000..69fbbc8785
--- /dev/null
+++ b/doc/forum/New_Arch_Linux_package_for_git-annex/comment_3_ab1f6e45625e6ab80770d4ff65ec4242._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 3"
+ date="2016-01-18T23:23:48Z"
+ content="""
+As someone who uses Arch a lot.. thank you so much!
+"""]]
diff --git a/doc/forum/New_external_special_remote_for_rclone.mdwn b/doc/forum/New_external_special_remote_for_rclone.mdwn
new file mode 100644
index 0000000000..5ec948db41
--- /dev/null
+++ b/doc/forum/New_external_special_remote_for_rclone.mdwn
@@ -0,0 +1,7 @@
+Hi folks, I'm working on a new external special remote for rclone named "git-annex-remote-rclone-goyle", or "garrgoyle" for short. (I chose a unique name to disambiguate from the preexisting [git-annex-remote-rclone](https://github.com/git-annex-remote-rclone/git-annex-remote-rclone) project.)
+
+Like git-annex-remote-rclone, garrgoyle only supports the [external special remote protocol](https://git-annex.branchable.com/design/external_special_remote_protocol/). In the near future, I'd like to add support for the *simple export interface* (see [export_and_import_appendix](https://git-annex.branchable.com/design/external_special_remote_protocol/export_and_import_appendix/)).
+
+Garrgoyle seems to be faster than git-annex-remote-rclone. Anecdotally, it was 10x faster when I asked to copy ~20 files that were already present on a "drive" remote. I think the difference is that garrgoyle pays the rclone startup cost once, rather than once per action.
+
+I've uploaded a PR to rclone's GitHub repo <https://github.com/rclone/rclone/pull/7654>. If anyone is willing to alpha test, I would greatly appreciate it! Feedback on the PR is also welcome.
diff --git a/doc/forum/New_external_special_remote_for_rclone/comment_1_8845852338bbb7e46c0d5585d5884faf._comment b/doc/forum/New_external_special_remote_for_rclone/comment_1_8845852338bbb7e46c0d5585d5884faf._comment
new file mode 100644
index 0000000000..fe900d7054
--- /dev/null
+++ b/doc/forum/New_external_special_remote_for_rclone/comment_1_8845852338bbb7e46c0d5585d5884faf._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-03-04T21:10:44Z"
+ content="""
+Cool! Do let us know when it's available and we can add it to the list of
+special remotes.
+
+WRT the simple export interface, there is a PR on git-annex-remote-rclone
+that adds it
+<https://github.com/git-annex-remote-rclone/git-annex-remote-rclone/pull/62>.
+But, it got hung up on a question of avoiding possible data loss if two
+git-annexes are exporting the same file. That sounds like a problem you
+will need to consider in your implementation too.
+"""]]
diff --git a/doc/forum/New_external_special_remote_for_rclone/comment_2_4057e28ed32aeab048f7c97a733f180f._comment b/doc/forum/New_external_special_remote_for_rclone/comment_2_4057e28ed32aeab048f7c97a733f180f._comment
new file mode 100644
index 0000000000..ad8c8cb048
--- /dev/null
+++ b/doc/forum/New_external_special_remote_for_rclone/comment_2_4057e28ed32aeab048f7c97a733f180f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="d@403a635aa8eaa8bfa8613acb6a375d9e06ed7001"
+ nickname="d"
+ avatar="http://cdn.libravatar.org/avatar/b79468a0d03ec3ec7acbae547c4fa994"
+ subject="comment 2"
+ date="2024-03-26T14:07:19Z"
+ content="""
+This has now been merged into rclone, but it's not yet shipped in a release. It is now a subcommand of rclone (`rclone gitannex`) rather than a standalone command. When invoked with `-h`, it prints some rough installation instructions, which are also available here: <https://github.com/rclone/rclone/blob/master/cmd/gitannex/gitannex.md>.
+
+As for the concurrent transfers problem, I was told by rclone's maintainer that on backends where partially uploaded files are visible, the backend automatically writes to a temp location and renames when the transfer is complete [[GitHub thread](https://github.com/rclone/rclone/pull/7654#discussion_r1512964399)]. I want to delve into this a little more and do something in `rclone gitannex` when the backend does not have this two-step-transfer property (maybe it should print a warning, or maybe just abort).
+"""]]
diff --git a/doc/forum/New_external_special_remote_for_rclone/comment_3_4412a5a25ac933de71772afd23cd66bd._comment b/doc/forum/New_external_special_remote_for_rclone/comment_3_4412a5a25ac933de71772afd23cd66bd._comment
new file mode 100644
index 0000000000..1a4bf82eb6
--- /dev/null
+++ b/doc/forum/New_external_special_remote_for_rclone/comment_3_4412a5a25ac933de71772afd23cd66bd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-03-26T17:38:07Z"
+ content="""
+See [[todo/external_special_remotes_not_using_git-annex-remote_in_name]]
+for possible changes in git-annex related to this.
+"""]]
diff --git a/doc/forum/New_external_special_remote_for_rclone/comment_4_9a23f4e9d673b4dcf60b3425fa4df4aa._comment b/doc/forum/New_external_special_remote_for_rclone/comment_4_9a23f4e9d673b4dcf60b3425fa4df4aa._comment
new file mode 100644
index 0000000000..57a410e607
--- /dev/null
+++ b/doc/forum/New_external_special_remote_for_rclone/comment_4_9a23f4e9d673b4dcf60b3425fa4df4aa._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2024-03-26T17:39:25Z"
+ content="""
+Looking at the docs at
+<https://github.com/git-annex-remote-rclone/git-annex-remote-rclone>
+there are a lot of options for different directory layouts. Do you have any
+plans to support those? It seems it might be useful for migration of
+existing special remotes, if nothing else.
+
+I guess that "rcloneprefix=" in this is the same as "prefix="
+in git-annex-remote-rclone?
+
+I've added a mention of this to [[special_remotes/rclone]].
+"""]]
diff --git a/doc/forum/New_external_special_remote_for_rclone/comment_5_cf45b8efbb296013493e7756cdfcf291._comment b/doc/forum/New_external_special_remote_for_rclone/comment_5_cf45b8efbb296013493e7756cdfcf291._comment
new file mode 100644
index 0000000000..635194bcc9
--- /dev/null
+++ b/doc/forum/New_external_special_remote_for_rclone/comment_5_cf45b8efbb296013493e7756cdfcf291._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="d@403a635aa8eaa8bfa8613acb6a375d9e06ed7001"
+ nickname="d"
+ avatar="http://cdn.libravatar.org/avatar/b79468a0d03ec3ec7acbae547c4fa994"
+ subject="comment 5"
+ date="2024-03-27T13:26:34Z"
+ content="""
+> Looking at the docs at <https://github.com/git-annex-remote-rclone/git-annex-remote-rclone> there are a lot of options for different directory layouts. Do you have any plans to support those? It seems it might be useful for migration of existing special remotes, if nothing else.
+
+This wasn't on my roadmap, but I think it's worth prioritizing. It would enable users to migrate between these special remote implementations without requiring double the storage space on the remote and a proportional amount of patience. I've added this to milestone 2 in my [tracking comment](https://github.com/rclone/rclone/issues/7625#issuecomment-1951403856) on GitHub.
+
+> I guess that \"rcloneprefix=\" in this is the same as \"prefix=\" in git-annex-remote-rclone?
+
+Correct. I intentionally chose to start all config names with \"rclone\". I think this makes it a little easier for users to grok the initremote command, since other key-value pairs like `encryption=hybrid` also show up there. I suppose I could also support config names without the rclone prefix without much trouble, and it might make it easier for users to migrate. I'll have to mull on that. Also added to the tracking comment linked above.
+
+> I've added a mention of this to rclone.
+
+Awesome! Thanks for adding my project! Two edits:
+
+* The command should be `rclone gitannex -h`. Without `-h`, it will start speaking the external special remote protocol at the user ;)
+* The link should be <https://github.com/rclone/rclone/blob/master/cmd/gitannex/gitannex.md> -- looks like you accidentally pasted the link for git-annex-remote-rclone.
+
+
+"""]]
diff --git a/doc/forum/New_external_special_remote_for_rclone/comment_6_36a0260f013ccbd06460dea83fe22278._comment b/doc/forum/New_external_special_remote_for_rclone/comment_6_36a0260f013ccbd06460dea83fe22278._comment
new file mode 100644
index 0000000000..23769242c0
--- /dev/null
+++ b/doc/forum/New_external_special_remote_for_rclone/comment_6_36a0260f013ccbd06460dea83fe22278._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2024-03-27T20:00:04Z"
+ content="""
+Fixed those. (Note that you can edit the page yourself!)
+"""]]
diff --git a/doc/forum/New_external_special_remote_for_rclone/comment_7_4d7f07a872ef3cc2c4928dcd1580bd0a._comment b/doc/forum/New_external_special_remote_for_rclone/comment_7_4d7f07a872ef3cc2c4928dcd1580bd0a._comment
new file mode 100644
index 0000000000..fab02c082a
--- /dev/null
+++ b/doc/forum/New_external_special_remote_for_rclone/comment_7_4d7f07a872ef3cc2c4928dcd1580bd0a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="d@403a635aa8eaa8bfa8613acb6a375d9e06ed7001"
+ nickname="d"
+ avatar="http://cdn.libravatar.org/avatar/b79468a0d03ec3ec7acbae547c4fa994"
+ subject="comment 7"
+ date="2024-03-27T22:11:47Z"
+ content="""
+Ah, I did not realize that! I thought I could only post on the forum for some reason.
+"""]]
diff --git a/doc/forum/New_git-annex_integration_mode_for_Emacs_users.mdwn b/doc/forum/New_git-annex_integration_mode_for_Emacs_users.mdwn
new file mode 100644
index 0000000000..0513e0df8f
--- /dev/null
+++ b/doc/forum/New_git-annex_integration_mode_for_Emacs_users.mdwn
@@ -0,0 +1,3 @@
+I've started a another project to provide Emacs integration for git-annex: [[https://github.com/jwiegley/git-annex-el]]
+
+My problem with the existing mode is that it didn't feel at all Emacsy, while my mode just piggy backs on existing paradigms, like using `C-x C-q` in a locked file to make it editable, and allowing you to browse and lock/unlock annexed files from Dired.
diff --git a/doc/forum/New_user_misunderstandings.mdwn b/doc/forum/New_user_misunderstandings.mdwn
new file mode 100644
index 0000000000..d1b1df180b
--- /dev/null
+++ b/doc/forum/New_user_misunderstandings.mdwn
@@ -0,0 +1,24 @@
+New user? Can't figure out the basics? Add it here - what you wanted, what you tried.
+
+#### I wanted to keep track of some files I had all organized in a directory outside of my ~/annex:
+
+    $ cd ~/annex
+    $ git annex add /path/to/some/photos
+    fatal: '/path/to/some/photos' is outside repository
+
+ But git-annex doesn't work that way. I had to do this instead
+
+    $ rsync -a /path/to/some/photos
+    $ git annex add photos
+    (Recording state in git...)
+    $ git annex status
+    ... lots of helpful info...
+
+#### I just have the OS/X app, can I do commandline stuff?
+
+yes
+
+    $ /Applications/git-annex.app/Contents/MacOS/git-annex add photos/
+    (Recording state in git...)
+
+but perhaps there is a better way.
diff --git a/doc/forum/New_user_misunderstandings/comment_1_c1785924109b5d5cde9aa3d3460cf955._comment b/doc/forum/New_user_misunderstandings/comment_1_c1785924109b5d5cde9aa3d3460cf955._comment
new file mode 100644
index 0000000000..b15f5cfb76
--- /dev/null
+++ b/doc/forum/New_user_misunderstandings/comment_1_c1785924109b5d5cde9aa3d3460cf955._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.117"
+ subject="comment 1"
+ date="2012-12-17T16:21:36Z"
+ content="""
+For importing your photos, you can use `git annex import /path/to/some/photos` .. this will move them from the given location into the current directory, and add them to the annex. It preserves subdirectory structure too.
+
+For using the OSX app at the command line, the only thing that is guaranteed to work properly is to run `/Applications/git-annex.app/Contents/MacOS/runshell`, which will modify your PATH and other environment appropriately.
+"""]]
diff --git a/doc/forum/Newb_question_on_sneekernet_sync.mdwn b/doc/forum/Newb_question_on_sneekernet_sync.mdwn
new file mode 100644
index 0000000000..7703bbec18
--- /dev/null
+++ b/doc/forum/Newb_question_on_sneekernet_sync.mdwn
@@ -0,0 +1,7 @@
+Hi,
+
+I have set up git-annex to sync a folder located on laptop A, USB Key, and laptop B.   After reading the walkthrough, I don't quite understand the proper procedure to keep in sync.  Should I run git-annex sync from within the sync directory on the USB Key on laptop A and then from within the sync folder on the USB Key when plugged into laptop B?  Or do I have to run git-annex sync from within the sync directory on the laptops, then the USB Key?  And/or do I have to run git-annex get on the sync directory on the USB key before syncing to the second laptop?
+
+Also I should not normally be making changes on laptops A and B at the same time, but if that were the case, is there any difference in what I would run to sync the changes?
+
+Thanks!
diff --git a/doc/forum/Newb_question_on_sneekernet_sync/comment_1_409cc5ba605d63331b386066d32f797b._comment b/doc/forum/Newb_question_on_sneekernet_sync/comment_1_409cc5ba605d63331b386066d32f797b._comment
new file mode 100644
index 0000000000..691d401372
--- /dev/null
+++ b/doc/forum/Newb_question_on_sneekernet_sync/comment_1_409cc5ba605d63331b386066d32f797b._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkutSE8_3fFAETmO_E598zja4gKwYXbb8E"
+ nickname="Сергей"
+ subject="comment 1"
+ date="2015-04-08T12:31:33Z"
+ content="""
+Well, working with git annex, you should think of two things:
+
+1. location of annex information (git commit tree), let's call it INFO
+2. location of files contents, let's call it CONTENT
+
+So, for your sneekernet scenario these general steps are required:
+
+1. sync INFO between Laptop A and USB
+2. transfer required CONTENT from LAPTOP A to USB
+3. sync INFO between Laptop B and USB
+4. transfer required CONTENT from USB to Laptop B
+
+Let's describe your options on every step:
+
+1. issue `git annex sync` on Laptop A. Either from within USB or Laptop repo, I prefer Laptop because of automatic commit.
+2. 
+   * issue `git annex copy <files> --to=<usb-remote-name>` from within Laptop A repo
+   * issue `git annex get <files>` from within USB repo. This is not possible if you have bare repo on USB.
+3. issue `git annex sync` on Laptop B
+4. same as 2, but transfer to Laptop B
+
+Also, using `git annex sync --content`, you don't need to manually transfer CONTENT, see [--content](https://git-annex.branchable.com/git-annex-sync/). But in this case you somewhat loose control of what is transferred.
+
+If you make changes on both laptops at the same time no extra steps required. In case of conflict both versions saved in working directory, see [automatic conflict resolution](http://git-annex.branchable.com/automatic_conflict_resolution/).
+"""]]
diff --git a/doc/forum/Newbie_question_for_a_simple_task.mdwn b/doc/forum/Newbie_question_for_a_simple_task.mdwn
new file mode 100644
index 0000000000..49db807956
--- /dev/null
+++ b/doc/forum/Newbie_question_for_a_simple_task.mdwn
@@ -0,0 +1,11 @@
+Hi,
+
+I am pretty confident, that this is a newbie question. Nevertheless, I did not find the answer (or the solution) event after looking at the screencasts and reading through the files.
+
+I want to sync 2 clients on different networks though a ssh cloud server begin a full backup.
+Also, I would like to do this for 2 different folders on the clients and server.
+I mean : client 1, 2 and the server sync a repo named "DATA" and also sync another repo named "IMAGES"
+
+Setting the client1 as local client repo and also ssh remote repo works quite well, it uploads everything to the server. Then I make the same on the second client, and it does not start to download everything from the server...
+
+Any clue ?
diff --git a/doc/forum/Newbie_question_for_a_simple_task/comment_1_51cf643c8d843dd2ab49c83aaf4fd218._comment b/doc/forum/Newbie_question_for_a_simple_task/comment_1_51cf643c8d843dd2ab49c83aaf4fd218._comment
new file mode 100644
index 0000000000..3f34ca14a2
--- /dev/null
+++ b/doc/forum/Newbie_question_for_a_simple_task/comment_1_51cf643c8d843dd2ab49c83aaf4fd218._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Régis"
+ subject="comment 1"
+ date="2015-02-23T09:20:54Z"
+ content="""
+Ok, I found PART of the answer here : <https://git-annex.branchable.com/forum/Two_computers__44___one_networked_repository__44___no_Jabber_-_how_to_setup_sync__63___/>
+
+It is mentioned to use Jabber to make both clients message each other when there is something new to sync. What about my setup with 2 groups of repos syncing together each for itself ? I read somewhere, that the jabber account will sync ALL repos. Is the solution to create 2 Jabber accounts ?
+"""]]
diff --git a/doc/forum/Newbie_question_for_a_simple_task/comment_2_a9d18e6fb1c6b064f50467c23bc89d2e._comment b/doc/forum/Newbie_question_for_a_simple_task/comment_2_a9d18e6fb1c6b064f50467c23bc89d2e._comment
new file mode 100644
index 0000000000..8002298a23
--- /dev/null
+++ b/doc/forum/Newbie_question_for_a_simple_task/comment_2_a9d18e6fb1c6b064f50467c23bc89d2e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-02-25T19:18:58Z"
+ content="""
+Since you have a ssh server, it's better to avoid jabber. Install
+git-annex 5.20140405 or newer on the server, and the clients will
+use it to communicate with one-another.
+"""]]
diff --git a/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__.mdwn b/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__.mdwn
new file mode 100644
index 0000000000..eb1aa3b50b
--- /dev/null
+++ b/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__.mdwn
@@ -0,0 +1,5 @@
+I'm brand new to git-annex and am having trouble getting going.  I've got an annex and I get messages like "Ran daily sanity check" and "Synced with web", but I can't get connected to a Jabber account.  I've been using my Gmail account, which works fine for logging into this forum but gives me the message "Unable to connect to the Jabber server. Maybe you entered the wrong password?" when I try to configure the Jabber account.
+
+I'm using version 3.20121112ubuntu2.  I think a later version might exist but I don't know how to reach it; I've done the standard install for Ubuntu-style OSs (I'm running Kubuntu right now), and that's the git-annex version that arrives.
+
+Any suggestions?  Sorry for the simplistic startup question, but it looks like this will be a great tool once I get it running.
diff --git a/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_1_59158afcedac18a7285d57491b2a468a._comment b/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_1_59158afcedac18a7285d57491b2a468a._comment
new file mode 100644
index 0000000000..45b4a9bdff
--- /dev/null
+++ b/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_1_59158afcedac18a7285d57491b2a468a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 1"
+ date="2013-07-27T22:13:49Z"
+ content="""
+Since 2012 git-annex has had massive improvements to its Jabber support. See [[/install/Ubuntu]] to get a current version.
+"""]]
diff --git a/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_2_2a70ac08bb95774415b09dab7d7f8605._comment b/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_2_2a70ac08bb95774415b09dab7d7f8605._comment
new file mode 100644
index 0000000000..777a238510
--- /dev/null
+++ b/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_2_2a70ac08bb95774415b09dab7d7f8605._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlutNrg7ajiNAfi5gqJfD8crv0aimZa27k"
+ nickname="Chuck"
+ subject="Now I'm really confused 8-/"
+ date="2013-07-28T05:26:02Z"
+ content="""
+Yes, I followed the directions on that page and executed \"sudo apt-get install git-annex\" on my 13.04 (Raring) system.  I did it again just now to verify, and I got the same result from \"git-annex version\", namely \"3.20121112ubuntu2\".  Do I need to add a repo for Raring as for Precise? 
+"""]]
diff --git a/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_3_92a52b523ed4c68b70ddcabc2a050b76._comment b/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_3_92a52b523ed4c68b70ddcabc2a050b76._comment
new file mode 100644
index 0000000000..9b1d95e788
--- /dev/null
+++ b/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_3_92a52b523ed4c68b70ddcabc2a050b76._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmKKg3Vmzk7KwRGRKjHVdtyoj1JfxLX6NM"
+ nickname="Tom"
+ subject="comment 3"
+ date="2013-10-01T18:33:05Z"
+ content="""
+I've got the same issue on Xubuntu 13.04. I installed using this script: https://github.com/zerodogg/scriptbucket/blob/master/gitannex-install
+
+`git-annex version` makes no mention of DNS or ADNS
+
+`host` command is installed on my machine. any suggestions on how best to fix for this setup?
+"""]]
diff --git a/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_4_c52a75761ea107f6d69c09bac64f0f0a._comment b/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_4_c52a75761ea107f6d69c09bac64f0f0a._comment
new file mode 100644
index 0000000000..b15edfa5a6
--- /dev/null
+++ b/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_4_c52a75761ea107f6d69c09bac64f0f0a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmKKg3Vmzk7KwRGRKjHVdtyoj1JfxLX6NM"
+ nickname="Tom"
+ subject="comment 4"
+ date="2013-10-02T21:27:36Z"
+ content="""
+Update to my comment above - it seems my problem is related to ejabberd as discussed here: <http://git-annex.branchable.com/forum/XMPP_authentication_failure/>
+
+Think I might change my server to [Prosody](https://prosody.im/) and see what happens then.
+
+
+"""]]
diff --git a/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_5_2685e3a87464ccd37d593516d94ba5cf._comment b/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_5_2685e3a87464ccd37d593516d94ba5cf._comment
new file mode 100644
index 0000000000..84d6832ff3
--- /dev/null
+++ b/doc/forum/Newbie_stuck_at___34__Unable_to_connect_to_the_Jabber_server__34__/comment_5_2685e3a87464ccd37d593516d94ba5cf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkr_EUIHZ8CTtOGm-j-guMBzaYuOzrXJwg"
+ nickname="Christoph"
+ subject="be aware of the 2-step verification"
+ date="2013-10-15T20:03:12Z"
+ content="""
+if you enabled the \"2-step verification\" in our google account (Account -> Security -> 2-step verification: Status: ON) you have to make a \"Application-specific passwords\" for your Jabber login.
+
+NoXorius
+"""]]
diff --git a/doc/forum/No_SSL_traffic_for_S3__63__.mdwn b/doc/forum/No_SSL_traffic_for_S3__63__.mdwn
new file mode 100644
index 0000000000..c2f4e3717f
--- /dev/null
+++ b/doc/forum/No_SSL_traffic_for_S3__63__.mdwn
@@ -0,0 +1,8 @@
+As far I can tell, the encryption mentioned on the wiki for S3 [1] refers to file-level encryption. That is, it encrypts files with GPG before storing them (or after retrieving them) from S3. However, even if I have GPG encryption off, I still want S3 requests to use SSL encryption. As far as I can tell, HTTPS isn't used with S3 remotes. Is there any way to enable it (if so, it should be the default)?
+
+I am using git-annex version: 3.20120406
+
+Cheers,
+--acrefoot
+
+[1] http://git-annex.branchable.com/special_remotes/S3/
diff --git a/doc/forum/No_SSL_traffic_for_S3__63__/comment_1_f509bf273896180e6df8c771438dd093._comment b/doc/forum/No_SSL_traffic_for_S3__63__/comment_1_f509bf273896180e6df8c771438dd093._comment
new file mode 100644
index 0000000000..808d4c0351
--- /dev/null
+++ b/doc/forum/No_SSL_traffic_for_S3__63__/comment_1_f509bf273896180e6df8c771438dd093._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 1"
+ date="2013-01-15T20:25:42Z"
+ content="""
+<http://hackage.haskell.org/package/hS3> is a Haskell library for S3, which git-annex uses. It does not support HTTPS. I'm sure its author would appreciate help, or maybe even just gentle motivation.
+
+FWIW, I think that S3's authorization is designed to be pretty secure even over an un-encrypted transport.
+It uses HMAC to sign the request with your AWS credentials securely, and includes a date that is hopefully used to avoid replay attacks.
+"""]]
diff --git a/doc/forum/No_SSL_traffic_for_S3__63__/comment_2_358635d19c82202c63014ca84de7fc3b._comment b/doc/forum/No_SSL_traffic_for_S3__63__/comment_2_358635d19c82202c63014ca84de7fc3b._comment
new file mode 100644
index 0000000000..edf1b63381
--- /dev/null
+++ b/doc/forum/No_SSL_traffic_for_S3__63__/comment_2_358635d19c82202c63014ca84de7fc3b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnRIwPkmDOZSpul-Lx61_jUGHh9f_F3od8"
+ nickname="Michael"
+ subject="comment 2"
+ date="2013-01-15T20:47:50Z"
+ content="""
+The authorization is fine, but it's scary to see your data floating along the wire in plain-text :)
+"""]]
diff --git a/doc/forum/No_known_copies_exist_of.mdwn b/doc/forum/No_known_copies_exist_of.mdwn
new file mode 100644
index 0000000000..c4b31a9539
--- /dev/null
+++ b/doc/forum/No_known_copies_exist_of.mdwn
@@ -0,0 +1,31 @@
+I just created a repo and added some content as described here:
+https://writequit.org/articles/getting-started-with-git-annex.html
+
+Some of the directories I added ended up fine, while others have lot's of broken symlinks.
+
+    git annex fsck file
+gives me :
+
+    ** No known copies exist of file
+    failed
+    git-annex: fsck: 1 failed
+
+
+and
+
+    git annex get file
+
+gives me:
+
+    get file (not available) 
+      No other repository is known to contain the file.
+    failed
+    git-annex: get: 1 failed
+
+
+The objects directory is about the same size as the repo was before I annexed it.
+
+Any ideas on how to troubleshoot further?
+
+
+Thanks!
diff --git a/doc/forum/No_luck_getting_forgetfulness_does_not_propagate.mdwn b/doc/forum/No_luck_getting_forgetfulness_does_not_propagate.mdwn
new file mode 100644
index 0000000000..cd5b187703
--- /dev/null
+++ b/doc/forum/No_luck_getting_forgetfulness_does_not_propagate.mdwn
@@ -0,0 +1,26 @@
+I am not having any luck throwing away historical data using `git annex forget`. According to the manpage "the forgetfulness will automatically propagate out", but what I observe is that the old metadata is merged right back into the branch with the truncated metadata:
+
+```
+$ git annex forget --force --drop-dead
+$ git annex sync B3
+$ git log --branches --remotes --oneline --graph
+*   e7cf462ada (B3/synced/git-annex, B3/git-annex, git-annex) merging B3/git-annex into git-annex
+|\  
+| * 7f8b737a01 update
+* | 41bef1e3db merging B3/git-annex into git-annex
+|\| 
+| * 383a53bf9a update
+| *   2607574ed0 merging B3/git-annex into git-annex
+| |\  
+| | * dc46f334c9 update
+| * | c4c25c52a7 new branch for transition ["forget git history","forget dead remotes"]
+|  /  
+* / d3a1042f9e new branch for transition ["forget git history","forget dead remotes"]
+ /
+ |
+(here comes all of the old history)
+```
+
+What else do I have to do to make this happen?
+
+Thanks for your support! -- Jonas
diff --git a/doc/forum/No_luck_getting_forgetfulness_does_not_propagate/comment_1_b4aaabb50743dd11b70ce0cd2b85df5e._comment b/doc/forum/No_luck_getting_forgetfulness_does_not_propagate/comment_1_b4aaabb50743dd11b70ce0cd2b85df5e._comment
new file mode 100644
index 0000000000..ba52697a8b
--- /dev/null
+++ b/doc/forum/No_luck_getting_forgetfulness_does_not_propagate/comment_1_b4aaabb50743dd11b70ce0cd2b85df5e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jonas@ab8487518c600ac0c785f4f6ca641c219f2bcfdc"
+ nickname="jonas"
+ avatar="http://cdn.libravatar.org/avatar/059a5820c6189aa2661f80f3abc62112"
+ subject="comment 1"
+ date="2022-02-06T23:30:17Z"
+ content="""
+s/does not/to/
+"""]]
diff --git a/doc/forum/No_luck_getting_forgetfulness_does_not_propagate/comment_2_81c98f50953860c15473e958c55d1e4b._comment b/doc/forum/No_luck_getting_forgetfulness_does_not_propagate/comment_2_81c98f50953860c15473e958c55d1e4b._comment
new file mode 100644
index 0000000000..711f847646
--- /dev/null
+++ b/doc/forum/No_luck_getting_forgetfulness_does_not_propagate/comment_2_81c98f50953860c15473e958c55d1e4b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-02-07T16:43:26Z"
+ content="""
+I'm sure this used to work, but I've confirmed it no longer does
+and opened a bug report [[sync_does_not_propagate_forgetfulness]]
+
+Update: The bug I found is fixed. I'm fairly sure it caused the problem you
+saw as well, although I have not tried to reproduce your exact situation.
+
+Once you upgrade to the next release of git-annex (or tomorrow's daily
+build), you will need to re-run the git-annex forget command, and then it
+should propagate that new forgetting properly.
+"""]]
diff --git a/doc/forum/No_luck_getting_forgetfulness_does_not_propagate/comment_3_350cc2d2025655804a58ed520a157c2e._comment b/doc/forum/No_luck_getting_forgetfulness_does_not_propagate/comment_3_350cc2d2025655804a58ed520a157c2e._comment
new file mode 100644
index 0000000000..f55cf4a76d
--- /dev/null
+++ b/doc/forum/No_luck_getting_forgetfulness_does_not_propagate/comment_3_350cc2d2025655804a58ed520a157c2e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jonas@ab8487518c600ac0c785f4f6ca641c219f2bcfdc"
+ nickname="jonas"
+ avatar="http://cdn.libravatar.org/avatar/059a5820c6189aa2661f80f3abc62112"
+ subject="comment 3"
+ date="2022-02-08T18:04:45Z"
+ content="""
+Now it works. Thanks a lot!
+"""]]
diff --git a/doc/forum/No_output_from_git-annex_status_v5.20131224-g692aa01.mdwn b/doc/forum/No_output_from_git-annex_status_v5.20131224-g692aa01.mdwn
new file mode 100644
index 0000000000..b13cab9bf9
--- /dev/null
+++ b/doc/forum/No_output_from_git-annex_status_v5.20131224-g692aa01.mdwn
@@ -0,0 +1,16 @@
+I'm running version 5.20131224-g692aa01 standalone tarball on linux x86_64 (Linux Mint 15). When I run `git-annex status` in the terminal I get no output. 
+
+I've tried:
+
+* system linked (`ln -s`) the `git-annex`, `git-annex-shell`, and `git-annex-webapp` to `~/bin/` which is on my PATH
+* run the `runshell` program from the terminal 
+
+Other things to consider:
+
+* I've just upgraded the repo from version 3 to version 5
+* Repo was created using git-annex version 3 
+* I don't use assistant or the webapp
+* Only used from my terminal
+* Repo is in indirect mode
+
+What do I need to do to see the results of `git-annex status`? in my terminal?
diff --git a/doc/forum/No_output_from_git-annex_status_v5.20131224-g692aa01/comment_1_b014f1edcb7ce39da9b582683d3b80c0._comment b/doc/forum/No_output_from_git-annex_status_v5.20131224-g692aa01/comment_1_b014f1edcb7ce39da9b582683d3b80c0._comment
new file mode 100644
index 0000000000..cffcbab75e
--- /dev/null
+++ b/doc/forum/No_output_from_git-annex_status_v5.20131224-g692aa01/comment_1_b014f1edcb7ce39da9b582683d3b80c0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2013-12-26T23:06:34Z"
+ content="""
+Run `git annex info` instead. That is what older versions of git-annex called `git annex status`
+
+Meanwhile, `git annex status` is now like `git status` -- it shows an overview of uncommitted changes in your work tree.
+"""]]
diff --git a/doc/forum/No_output_from_git-annex_status_v5.20131224-g692aa01/comment_2_24602de6cfe1f3d988c5105e7266a518._comment b/doc/forum/No_output_from_git-annex_status_v5.20131224-g692aa01/comment_2_24602de6cfe1f3d988c5105e7266a518._comment
new file mode 100644
index 0000000000..b09cf9757f
--- /dev/null
+++ b/doc/forum/No_output_from_git-annex_status_v5.20131224-g692aa01/comment_2_24602de6cfe1f3d988c5105e7266a518._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica Semrick"
+ subject="Thanks!"
+ date="2013-12-27T01:37:36Z"
+ content="""
+Not sure how I missed that :D
+"""]]
diff --git a/doc/forum/Non-ASCII_filenames.mdwn b/doc/forum/Non-ASCII_filenames.mdwn
new file mode 100644
index 0000000000..45316f9c3c
--- /dev/null
+++ b/doc/forum/Non-ASCII_filenames.mdwn
@@ -0,0 +1,64 @@
+Hello. git-annex has been a wonderful program but I still find the occasional annoyances now and then. These tend to be small issues such as this one that I'm having with only one repository (other clones seem fine):
+
+I use latin-1 directory names, such as "animação". This particular repository insists that all files under that particular directory are untracked. E.g. `"anima\303\247\303\243o/Anita/banner.jpg"`
+If I ask git-annex `git-annex whereis animação/Anita/banner.jpg`, it will promptly show it knows where it is. Thus, the data seems to be safe, it appears to be just an issue of git reading the filesystem.
+
+It is quite annoying to see all those hundreds of file names scrolling by every time I sync. Can someone suggest something to help me solve this issue? Here is some more information.
+
+    git-annex version: 7.20190912-gab739242a3
+    build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+    dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.3 feed-1.2.0.0 ghc-8.6.5 http-client-0.6.4 persistent-sqlite-2.10.5 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+    operating system: linux x86_64
+    supported repository versions: 7
+    upgrade supported from repository versions: 0 1 2 3 4 5 6
+    local repository version: 7
+
+The filesystem is an ext4.
+
+    tune2fs 1.45.3 (14-Jul-2019)
+    Filesystem volume name:   Toshiba3
+    Last mounted on:          /media/gus/Toshiba3
+    Filesystem UUID:          8be65206-e627-417b-9ead-2ff0a78bc42e
+    Filesystem magic number:  0xEF53
+    Filesystem revision #:    1 (dynamic)
+    Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
+    Filesystem flags:         signed_directory_hash 
+    Default mount options:    user_xattr acl
+    Filesystem state:         clean
+    Errors behavior:          Continue
+    Filesystem OS type:       Linux
+    Inode count:              183148544
+    Block count:              732566385
+    Reserved block count:     73256
+    Free blocks:              44132786
+    Free inodes:              183067035
+    First block:              0
+    Block size:               4096
+    Fragment size:            4096
+    Group descriptor size:    64
+    Reserved GDT blocks:      1024
+    Blocks per group:         32768
+    Fragments per group:      32768
+    Inodes per group:         8192
+    Inode blocks per group:   512
+    Flex block group size:    16
+    Filesystem created:       Tue Jul 11 14:43:53 2017
+    Last mount time:          Sat Sep 21 11:49:39 2019
+    Last write time:          Sat Sep 21 11:49:39 2019
+    Mount count:              192
+    Maximum mount count:      -1
+    Last checked:             Tue Jul 11 14:43:53 2017
+    Check interval:           0 (<none>)
+    Lifetime writes:          3387 GB
+    Reserved blocks uid:      0 (user root)
+    Reserved blocks gid:      0 (group root)
+    First inode:              11
+    Inode size:	          256
+    Required extra isize:     32
+    Desired extra isize:      32
+    Journal inode:            8
+    Default directory hash:   half_md4
+    Directory Hash Seed:      2f0f1511-b2fd-4d47-a528-c91f3caf50b9
+    Journal backup:           inode blocks
diff --git a/doc/forum/Not_enough_free_space.mdwn b/doc/forum/Not_enough_free_space.mdwn
new file mode 100644
index 0000000000..fea6a185ce
--- /dev/null
+++ b/doc/forum/Not_enough_free_space.mdwn
@@ -0,0 +1,42 @@
+Hello. git-annex has been working fine for me for quite some time. But at this moment it has left me in a pickle.
+
+One of my remotes appears to have decided to move to an unlocked state. It is located on an ext4 filesystem and after I ran `git-annex sync` it started replacing broken symlinks with small text files and non-broken symlinks with a copy of the file it was pointing to. I did create a _different_ repository that, for technical reasons, needed to run entirely in the unlocked mode. It seems this setting has propagated to this repository?
+
+The repository seems to have filled my entire filesystem. I already moved everything else I had (before I noticed this was a serious problem) and git-annex kept expanding.
+
+From `git-annex info`:
+
+```
+available local disk space: 8.77 megabytes (+1 megabyte reserved)
+local annex size: 1.76 terabytes
+size of annexed files in working tree: 5.1 terabytes
+```
+
+My hard disk is _not_ 5 TB in size, it is 2 TB and is already full! With git-annex! I really need to scale back the ambitions of this repository.
+
+The contents of `.git/annex/transfer` were removed. All operations I tried ended up with multiple messages like
+
+```
+  not enough free space, need 1.03 GB more (use --force to override this check or adjust annex.diskreserve)
+[2022-09-18 12:53:58.539936066] (Annex.InodeSentinal) /mnt/hotswap/annex/projects/mujka/export-testrun-004.avi inode cache empty
+```
+
+and then hanging. I recall an sqlite error message also complaining about lack of space, but I don't see it now.
+
+I tried to move some files from the `annex/object` store temporarily as to provide some additional breathing room (hoping that git-annex would not notice they were gone, but I had copies in other repositories), and tried to lock files again or move content elsewhere. The newly freed space was gobbled up and my attempted operation was ignored. So those were a few steps taken backwards.
+
+The version information is below, if it helps.
+
+```
+git-annex version: 10.20220822-gfa94d41c1
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.0.4 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+I am now reaching a point where I don't know what to do. I think I ran out of good ideas on how to keep this repository under control. Nuking it _is_ a possibility, but if this happens to another repository, I'm in trouble. So I'm reaching out to more knowledgeable people to help me figure out what is going on and how to address it nicely. Please help me. Thank you.
diff --git a/doc/forum/Not_enough_free_space/comment_1_4721e6e6c263c2a624d6cc77f6575860._comment b/doc/forum/Not_enough_free_space/comment_1_4721e6e6c263c2a624d6cc77f6575860._comment
new file mode 100644
index 0000000000..d367a81dfd
--- /dev/null
+++ b/doc/forum/Not_enough_free_space/comment_1_4721e6e6c263c2a624d6cc77f6575860._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2022-09-19T10:03:38Z"
+ content="""
+You could check when the files were unlocked with `git log -u` and then `git reset --hard` to that commit (you may loose uncommited changes). Or switch on the `annex.thin` config. Or  disable the git-annex sumudge/clean filters.
+"""]]
diff --git a/doc/forum/Not_enough_free_space/comment_2_69e5a25b63457e702436b54d26f6d482._comment b/doc/forum/Not_enough_free_space/comment_2_69e5a25b63457e702436b54d26f6d482._comment
new file mode 100644
index 0000000000..5e8f74fff5
--- /dev/null
+++ b/doc/forum/Not_enough_free_space/comment_2_69e5a25b63457e702436b54d26f6d482._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="comment 2"
+ date="2022-09-19T13:49:15Z"
+ content="""
+Thank you for your suggestions, Lukey.
+
+The log does not explicitly indicate any lock/unlock operation, but it does show that there were only merge/sync actions on the remote recently, and one of them (likely the last one) may have something to do with it. So I think that may be the best way to go.
+
+The `annex.thin` config setting seems quite clever, also.
+
+How would I disable the smudge/clean filters? That would prevent the update of the files outside of the git object storage, and the repository would be in a state similar to that of a bare repository -- am I understanding it correctly? Also seems like a fine answer.
+
+Finally, it seems to me that the locked/unlocked state of a file is propagated outside of a repository. I wish that was more explicit in the documentation, as I took file unlocking as a replacement for a _direct mode_ repository, since _only one_ of my repositories needs to interact with software that does not follow symbolic links.
+
+I think there is a way to disable the _push_ from a repository. I read about it somewhere. This seems like a necessity now.
+"""]]
diff --git a/doc/forum/Not_enough_free_space/comment_3_c6ad0934136448a014f6b1c317bba3e6._comment b/doc/forum/Not_enough_free_space/comment_3_c6ad0934136448a014f6b1c317bba3e6._comment
new file mode 100644
index 0000000000..da7bdac67a
--- /dev/null
+++ b/doc/forum/Not_enough_free_space/comment_3_c6ad0934136448a014f6b1c317bba3e6._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-09-20T17:37:53Z"
+ content="""
+I think that the documentation of [[git-annex-unlock]] is pretty clear
+about this:
+
+       Unlocking a file changes how it is stored in the git repository
+       (from a symlink to a pointer file), so this command will make
+       a change that you can commit.
+
+To get the equivilant of the old direct mode, where files are unlocked in
+one repository without affecting other clones, use `git-annex adjust --unlock`.
+"""]]
diff --git a/doc/forum/Not_enough_free_space/comment_4_c05f95ae6d69cdc214a2b31ebc296a3b._comment b/doc/forum/Not_enough_free_space/comment_4_c05f95ae6d69cdc214a2b31ebc296a3b._comment
new file mode 100644
index 0000000000..cdce83bd34
--- /dev/null
+++ b/doc/forum/Not_enough_free_space/comment_4_c05f95ae6d69cdc214a2b31ebc296a3b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-09-20T17:43:18Z"
+ content="""
+Since unlocking makes a change to a file that git can commit,
+you can certianly find the commit that made this change if you look hard
+enough. Probably not one of the merge commits themselves, but one of the
+commits that was merged. I'd maybe try `git log -u` on a file that I know
+has otherwise not changed for a while. When the diff shows
+that the mode of the file has changed from 120000 to 100644,
+that's the change from a locked symlink to an unlocked file.
+
+To disable the smudge/clean filters, edit `.git/config`
+and delete the block of config under `[filter "annex"]`
+"""]]
diff --git a/doc/forum/Not_enough_free_space/comment_5_f8206862e22fa354d97cc3d9d2af8d5c._comment b/doc/forum/Not_enough_free_space/comment_5_f8206862e22fa354d97cc3d9d2af8d5c._comment
new file mode 100644
index 0000000000..ba66f1fa79
--- /dev/null
+++ b/doc/forum/Not_enough_free_space/comment_5_f8206862e22fa354d97cc3d9d2af8d5c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="comment 5"
+ date="2022-09-20T22:07:30Z"
+ content="""
+Thank you, helpful community, for your assistance.
+
+joey, I stand corrected regarding the documentation. I guess it was the magnitude of the consequences of that detail that took me by surprise.
+"""]]
diff --git a/doc/forum/Not_enough_free_space/comment_6_06d27155323cf5609b17c4e1197ab9ac._comment b/doc/forum/Not_enough_free_space/comment_6_06d27155323cf5609b17c4e1197ab9ac._comment
new file mode 100644
index 0000000000..cda22f3bd4
--- /dev/null
+++ b/doc/forum/Not_enough_free_space/comment_6_06d27155323cf5609b17c4e1197ab9ac._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-09-21T17:42:44Z"
+ content="""
+Gus, did you manage to recover from the situation?
+
+I did some experimenting to see what it looks like when this happens.
+Here I am in a filesystem with 76 mb free, and annex.diskreserve is set to
+75 mb. The "big" file is 100 mb in size:
+
+	joey@darkstar:~/mnt/r2>git pull
+	remote: Enumerating objects: 5, done.
+	remote: Counting objects: 100% (5/5), done.
+	remote: Compressing objects: 100% (3/3), done.
+	remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
+	Unpacking objects: 100% (3/3), 328 bytes | 328.00 KiB/s, done.
+	From /home/joey/tmp/bench/r
+	   2dc7cd3..3699920  master     -> origin/master
+	Updating 2dc7cd3..3699920
+	Fast-forward
+	 big | 2 +-
+	 1 file changed, 1 insertion(+), 1 deletion(-)
+	 mode change 120000 => 100644 big
+	  not enough free space, need 100.99 MB more (use --force to override this check or adjust annex.diskreserve)
+	  not enough free space, need 101 MB more (use --force to override this check or adjust annex.diskreserve)
+	git-annex: unable to populate worktree file ./big
+	  not enough free space, need 101.02 MB more (use --force to override this check or adjust annex.diskreserve)
+	git-annex: git status will show big to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git update-index -q --refresh big
+	  not enough free space, need 101.02 MB more (use --force to override this check or adjust annex.diskreserve)
+	git-annex: git status will show big to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git update-index -q --refresh big
+
+So git-annex avoids filling up the entire disk in this situation
+when annex.diskreserve is configured. I suppose that you don't have
+it configured, so it defaulted to only 1 mb -- and then other
+things than unlocked files used up that remaining space.
+
+I've opened to todo that would have avoided the worst of
+your experience:
+[[todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default]].
+"""]]
diff --git a/doc/forum/Not_enough_free_space/comment_7_7cf8cf6d15324b840336be561423d34b._comment b/doc/forum/Not_enough_free_space/comment_7_7cf8cf6d15324b840336be561423d34b._comment
new file mode 100644
index 0000000000..f6a4803103
--- /dev/null
+++ b/doc/forum/Not_enough_free_space/comment_7_7cf8cf6d15324b840336be561423d34b._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="comment 7"
+ date="2022-09-21T22:30:20Z"
+ content="""
+Greeting, joey. I have not. I am waiting for some quiet free time in which I am well rested, to reduce the possibility of messing things up more. :-)
+
+In the meantime, I am seeing, in my `.git/config`:
+
+```
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+        diskreserve = 1000MB
+```
+
+I think that reserve is for _git_, not _git-annex_. I may as well start setting that variable. I am using git-annex, in part, because I need to have my stuff spread across multiple media.
+
+Looking at your example output, I am getting a less helpful result. Possibly due to what you explain. However I am concerned with the possibility of your \"to do\" is being too specific. Detecting free disk space is not easy (I also use BTRFS, so I know that!). Maybe transferring / growing more than X GB it would print a warning (that would not interfere with automatic usage)? Or easily rollback that last incomplete file to ensure the metadata and other files write cleanly. Certainly you know better than me what works and what is needed.
+
+By the way, if anyone would be interested in writing a book on git-annex, with all these nice tips, I would buy a copy! (I am also willing to provide feedback for a WIP)
+
+Finally, I would also like to add that, looking once more at the log I can see the file mode change, as you said. I now have confirmation that the suspected _sync_ caused this problem.
+
+Thank you once again for all your help.
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back.mdwn b/doc/forum/Not_sure_how_to_get_my_s3_remote_back.mdwn
new file mode 100644
index 0000000000..86f8da4548
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back.mdwn
@@ -0,0 +1,31 @@
+My situation goes something like this:
+
+I have a machine with an annex and a number of special remotes (s3, box, and an rsync'd nas).  I also have a git remote that's doesn't have git annex on it, so it's just got the git branches.  That machine has some problems so I start getting the annex set up on a different machine.  These are the steps that I went through:
+
+* clone from the git remote
+* git annex doesn't think this is an actual annex at this point, so `git annex init` it
+* Now I can start the webapp `git annex webapp`
+* My rsync'd remote works and the assistant starts downloading the files from there (which is great, it's the local network one) but the box and s3 remotes are disabled (sure, not a huge deal).
+* Click enable on the box remote, I have to specify that it's a full backup remote
+* Things start copying from box as well, so I disable it until everything from the local network is done
+* Click enable on the s3 remote and it wants my AWS creds
+* Download those and add it
+* Set the remote up the same way, as a full backup.
+
+At this point, all my files have copied from the rsync remote, so I enable the other remotes.
+
+Now I want to make sure that all the remotes are set up and working properly.
+
+I turn off the webapp, turn off direct mode (I think it was indirect mode by default, but I'd been playing with things before then), and `git annex drop <file>` a file that I don't particularly care about.  Everything drops successfully.
+
+I'm able to `git annex get -f <rsync remote> <file>` and from `<box remote>` successfully, but when I try to get from the s3 remote, it doesn't give me any output and doesn't download the file.
+
+Having used regular git annex without the assistant before, I try re-initing the remote `git annex initremote <s3>`.  It complains that there's no type, so I `git annex initremote <s3> type=S3`, then it complains about encryption.  `git annex initremote <s3> type=S3 encryption=shared`.  It says it worked, but I `git annex get -f <s3> <file>` still doesn't do anything.
+
+After more looking around, it turns out that I may have created a second remote with the same name as the original s3 remote... (figure that out).  I use the webapp to rename the remotes so they're different, but neither of them will `get -f` successfully.
+
+At this point, I turn to you and ask what the heck I did wrong.  I tried editing the remote.log and uuid.log files to remove the new s3 remote (and I figured out which one was which) from the git-annex branch.  I also marked the new s3 remote as dead, but I still can't get access to s3.
+
+`git annex fsck -f <s3>` doesn't actually seem to hit s3 (I seem to recall that it used to, it calculated checksums), it just checks some git local information.
+
+I don't mind deleting my current checkout and starting from the clone step again if you think I've made too much of a mess.  At least I know I can get my files off my rsync remote and box :)
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_10_ed35a6ec605e8f79ec107856af6d1a46._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_10_ed35a6ec605e8f79ec107856af6d1a46._comment
new file mode 100644
index 0000000000..eda042c832
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_10_ed35a6ec605e8f79ec107856af6d1a46._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 10"
+ date="2013-04-26T20:33:03Z"
+ content="""
+Oh.. I got confused by you talking about the box remote. Lines you pasted look ok anyway.
+
+Ok, looking at the S3 remote then...
+
+> I did notice that initially the s3 remote was named \"annex\". That was probably the web interface's doing, way back when I added it.
+
+So, you can never change the names used to refer to remotes in remote.log. These names can be different from the names used to refer to the same remotes in .git/config. (Which can vary from repository to repository anyway..) So, if you originally added a s3 remote and called it \"annex\", you still need to use that name when running initremote elsewhere to add that remote to your repository.
+
+The remote with name \"s3\" added in the 11:26 is a separate s3 remote, and I think one you don't want. (And have marked dead?)
+
+I think all you need to do is \"git annex initremote annex\" to add the s3 remote you want to your new repository.
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_11_e48b6efa42159dc83e1be11bfb54abcd._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_11_e48b6efa42159dc83e1be11bfb54abcd._comment
new file mode 100644
index 0000000000..41da88a8d3
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_11_e48b6efa42159dc83e1be11bfb54abcd._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkZktNHFhxC1kYA9KKdKpYJO4clq9WDsjE"
+ nickname="Jason"
+ subject="comment 11"
+ date="2013-04-26T20:37:51Z"
+ content="""
+Ah, I see.  It looks like that did solve my problem.
+
+Yes, I did mark the old s3 remote as dead.
+
+At least now I know how to fix it if it ever happens again.  I wonder if I'll ever be able to recreate it...
+
+Thanks!
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_12_b58232d0e3fa4649565c0c7d4ce2e82e._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_12_b58232d0e3fa4649565c0c7d4ce2e82e._comment
new file mode 100644
index 0000000000..8b13675fe7
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_12_b58232d0e3fa4649565c0c7d4ce2e82e._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 12"
+ date="2013-04-26T20:52:36Z"
+ content="""
+It's easy to recreate. As I understand it, the entire process went something like this:
+
+git annex initremote annex type=S3 encryption=blahblah # possibly this was done in the webapp?
+
+git remote rename annex s3 # also possibly done in the webapp
+
+# clone to different computer, and on the new clone:
+
+git annex initremote s3
+
+git-annex: Specify the type of remote with type=
+
+git annex initremote s3 type=S3 encryption=blahblah
+
+The last line creates a *new* remote.
+
+I'm inclined to think the main confusing thing here is that initremote is used to both create a new special remote, and to configure the repository to use an already existing special remote that was created elsewhere. If you had to use `enableremote` for the latter,
+things could be less confusing:
+
+# clone to different computer, and on the new clone:
+
+git annex enableremote s3
+
+git-annex: No existing special remote named s3. Choose from one of these existing special remotes: annex
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_13_85368b60091dc3ce2efb58013ffe9f83._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_13_85368b60091dc3ce2efb58013ffe9f83._comment
new file mode 100644
index 0000000000..c51377dbbe
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_13_85368b60091dc3ce2efb58013ffe9f83._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkZktNHFhxC1kYA9KKdKpYJO4clq9WDsjE"
+ nickname="Jason"
+ subject="comment 13"
+ date="2013-04-26T21:16:30Z"
+ content="""
+I tend to agree with you.  At first I liked the idea that initremote could be used to re-initialize a remote, but then I got confused about what the name of that remote was.  I suppose git annex status could have told me.  I kept wanting to have something like \"git annex remote\" (which would list them) and then \"git annex remote init\" to initialize them.  That way the remote actions would follow the same sort of interface as \"git remote\", where you could list, init, create, edit, rename, enable, disable, kill (dead?), etc.  The main drawback I see with that is having too many levels to type.
+
+I really like the idea of having the ability to \"git annex remote show s3\" and it will tell me what the type, uuid, options, etc are for that remote.
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_14_e65281bef23e0076936c508728a87897._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_14_e65281bef23e0076936c508728a87897._comment
new file mode 100644
index 0000000000..31fd9d60b0
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_14_e65281bef23e0076936c508728a87897._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 14"
+ date="2013-04-26T22:25:04Z"
+ content="""
+Have now split out an enableremote command.
+
+<pre>
+joey@gnu:~/tmp/annex>git annex initremote foo                                 
+git-annex: There is already a special remote named \"foo\". (Use enableremote to enable an existing special remote.)
+joey@gnu:~/tmp/annex>git annex enableremote
+git-annex: Specify the name of the special remote to enable. Known special remotes: foo
+</pre>
+
+Also, I wrote something wrong before. It *is* possible to change the name used by initremote (now enableremote).
+
+With the current release of git-annex:
+
+`git annex initremote annex name=mys3`
+
+With the next release:
+
+`git annex enableremote annex name=mys3`
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_1_fffb59ad5a197d2980dd0ec35cf4aafa._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_1_fffb59ad5a197d2980dd0ec35cf4aafa._comment
new file mode 100644
index 0000000000..d8d754309c
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_1_fffb59ad5a197d2980dd0ec35cf4aafa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-24T23:56:54Z"
+ content="""
+What you describe, `git annex get $file --from remote` silently not doing anything, is the expected behavior if the remote doesn't have the file. This allows you to eg, run `git annex get . --from remote` and get all files that the remote does have while skipping the rest.
+
+Did you ever try looking at `git annex whereis $file` ? 
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_2_0cfcc2075bff556b9fde5acc3dc1d599._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_2_0cfcc2075bff556b9fde5acc3dc1d599._comment
new file mode 100644
index 0000000000..c673737c1b
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_2_0cfcc2075bff556b9fde5acc3dc1d599._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkZktNHFhxC1kYA9KKdKpYJO4clq9WDsjE"
+ nickname="Jason"
+ subject="comment 2"
+ date="2013-04-25T00:20:59Z"
+ content="""
+When I run `git annex whereis $file` it tells me it's available at box, s3, my rsync remote, the original repo (from the machine I created the annex on), and my temporary usb stick repo (nothing wrong with redundancy...).  So it seems that git annex thinks the file is available in the s3 remote, even though it's refusing to download it.
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_3_6fe2ff1282fb14a4ce26ef8dc775d07e._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_3_6fe2ff1282fb14a4ce26ef8dc775d07e._comment
new file mode 100644
index 0000000000..187993a5ab
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_3_6fe2ff1282fb14a4ce26ef8dc775d07e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-04-25T00:50:01Z"
+ content="""
+Does the uuid that whereis prints next to the name of the s3 remote match the annex.<remote>.uuid setting for that remote in .git/config?
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_4_64338d2d77dcbabd16b55eb145f40dc6._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_4_64338d2d77dcbabd16b55eb145f40dc6._comment
new file mode 100644
index 0000000000..d4a05ce8e2
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_4_64338d2d77dcbabd16b55eb145f40dc6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkZktNHFhxC1kYA9KKdKpYJO4clq9WDsjE"
+ nickname="Jason"
+ subject="comment 4"
+ date="2013-04-25T01:18:00Z"
+ content="""
+Oh! That might be it!  During the whole \"I have two remotes with the name s3\" situation, it seems that both of them in my .git/config ended up with the same uuid, even though the original one had a different uuid.  If I change it back, I end up getting an access denied when I try to `git annex get ...`.  Progress!
+
+I thought that you were supposed to do a `git annex initremote s3` from a clone to enable a remote with the credentials stored in the repo.  It seems that internally something still thinks that the \"s3\" remote has the new uuid.  When I run that command it changes the uuid back to the new (invalid) one.
+
+Is there a way I can totally remove the bad s3 (which I've partially renamed to s3thefirst) remote from my history/repo (I'm pretty sure it's been synced back up to origin at this point) or properly rename it so it doesn't keep getting confused?  Hopefully that will address my problem.
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_5_dd66c9ea0c83388f6826751944330d10._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_5_dd66c9ea0c83388f6826751944330d10._comment
new file mode 100644
index 0000000000..58fba2ca8f
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_5_dd66c9ea0c83388f6826751944330d10._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 5"
+ date="2013-04-25T02:14:18Z"
+ content="""
+Yes, when you run `git annex initremote $remotename` with no other parameters, it enables a remote from the stored configuration.
+Which does not include `AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID`; you need to set those and then
+you should not get access denied.
+
+You seem to say your .git/config contains two remotes with the same name, but I don't think that's possible.
+
+I don't know how you could end up with two remotes with the same name in `git show git-annex:remote.log`, unless the two were added in separate repositories which were then synced together. Since this is not a usual situation there's not any UI to deal with it. I've just committed a change that will make `initremote` prefer remotes that have not been marked dead when there's a naming comflict.
+
+However, I'm more curious how this situation came about.  I have not been able to reproduce the problem when enabling a S3 remote using the webapp.
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_6_dc0c5e395e4c443b7227afdb157194e5._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_6_dc0c5e395e4c443b7227afdb157194e5._comment
new file mode 100644
index 0000000000..c9c352c352
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_6_dc0c5e395e4c443b7227afdb157194e5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 6"
+ date="2013-04-25T02:18:56Z"
+ content="""
+What you could do to help track down how this occurred is to check out the `git-annex` branch, and use `git blame` to find out when the second remote with the same name was first added to the `remote.log` file.
+
+Then you should be able to tell, either from the email address used for that commit, or at least the date of the commit, whether this occurred recently when you enabled the S3 remote in the webapp, or perhaps at some time in the past.
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_7_3c0ea4c76cdd889707f7308576e3efa0._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_7_3c0ea4c76cdd889707f7308576e3efa0._comment
new file mode 100644
index 0000000000..b325328947
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_7_3c0ea4c76cdd889707f7308576e3efa0._comment
@@ -0,0 +1,65 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkZktNHFhxC1kYA9KKdKpYJO4clq9WDsjE"
+ nickname="Jason"
+ subject="comment 7"
+ date="2013-04-26T19:10:15Z"
+ content="""
+http://pastebin.com/CM2EfQ21
+
+This is what the commit log looks like for the remote.log file.  There is some interesting stuff in here.  I'll try to highlight the changes without giving too much of the important bits away.
+
+The I commit at 2013-04-22 11:57 is when I added the box remote:
+
+0490d177-78e2-421b-a004-47d88ee7a2e3 chunksize=10mb cipher=... davcreds=... embedcreds=yes name=box.com type=webdav url=https://www.box.com/dav/annex timestamp=1366657062.972357s
+1d0ab67c-6a43-11e2-9feb-df22c6d1e308 bucket=annex-1d0ab67c-6a43-11e2-9feb-df22c6d1e308 cipher=... datacenter=US host=s3.amazonaws.com name=annex port=80 storageclass=REDUCED_REDUNDANCY type=S3 timestamp=1359484726.520727s
+
+The contents also includes my nas remote, but I will omit that for brevity's sake.  I did notice that initially the s3 remote was named \"annex\".  That was probably the web interface's doing, way back when I added it.
+
+The next commit at 2013-04-24 10:55 seems to have added encryption=shared and highRandomQuality=false to the nas remote (I think this was when I re-enabled the nas remote through the webapp).
+
+The commit at 2013-04-24 11:05 looks like it added similar stuff to the box remote (added highRandomQuality=false).  Probably this was from enabling it then as well.
+
+At 2013-04-24 11:12 the s3 remote had highRandomQuality=false added also.
+
+At 2013-04-24 11:26, a new remote was added:
+
+4d86972d-9b0a-4095-bc50-f9bec8144c30 bucket=s3-4d86972d-9b0a-4095-bc50-f9bec8144c30 cipher=... datacenter=US host=s3.amazonaws.com name=s3 port=80 storageclass=STANDARD type=S3 timestamp=1366828017.8792s
+
+Very possibly this was me doing a `git annex initremote ...` thinking that the s3 remote was actually named s3 (somehow, I feel like I would have checked that, but I'm going to chalk that up to my own stupidity).
+
+Then at 2013-04-24 11:35, the new s3 remote was changed... but it seems like only the timestamp was altered.  I suspect this was from another command line change, but I don't remember exactly what I did at that point.  Probably a reference in a different file was also modified, but I'm not looking at those.
+
+At 2013-04-24 11:37, again the new s3 remote was changed, but again it was just the timestamp.
+
+In the merge at 2013-04-24 15:15, a bunch of things happened.  This may be where stuff went wrong.  I do find it weird because it should have just been a fast forward, given what the history looks like.  I suspect that this was caused by a `git annex sync`, but I'm not 100% sure.
+
+In this commit the following happened:
+
+* The box remote was duplicated (with different davcreds and one having highRandomQuality=false)
+* The annex remote was duplicated (with highRandomQuality=false in one)
+* The nas remote was duplicated (one with encryption=shared and highRandomQuality=false and the other without)
+
+In addition, within that commit, my uuid.log file also had duplication that seems to be where part of the confusion comes from:
+
+* The 1d0ab67c-6a43-11e2-9feb-df22c6d1e308 remote shows up twice, once named \"annex\" and the other time named \"s3\".
+* The 4d86972d-9b0a-4095-bc50-f9bec8144c30 remote is only include once in there, but its name is also \"s3\".
+* Other remotes are duplicated, with different timestamps, but no overlapping uuids.
+
+Then at 2013-04-24 18:13, I think things try to fix themselves:
+
+* The older box remote (I guess based on timestamp) is removed.  Now there's only one.
+* The older 1d0ab67c-6a43-11e2-9feb-df22c6d1e308 remote (still named annex) is removed.  Now there's only one there too.
+* The single 4d86972d-9b0a-4095-bc50-f9bec8144c30 remote is updated with a new timestamp.
+* The older nas remote is also removed.
+
+No duplicates exist in this file and no cross-references exist either.
+
+The uuid.log file seems to be the place where the annex remote is renamed to s3.  I have no idea what caused that, but it was probably me.
+
+* In 2013-04-24 11:12, everything is fine in the uuid.log file.  The annex timestamp is updated, but no problems.
+* In 2013-04-24 11:13 (which doesn't show up when I look at the remote.log changes, because it didn't change that), a file's location log is updated and the 1d0ab67c-6a43-11e2-9feb-df22c6d1e308 remote is renamed from annex to s3 in uuid.log, but not in remotes.log.
+* In 2013-04-24 11:26, 4d86972d-9b0a-4095-bc50-f9bec8144c30 is added to remotes.log with the name s3 and to uuid.log with the name s3 (which is now a duplicate of the renamed 1d0ab67c-6a43-11e2-9feb-df22c6d1e308, but only in uuid.log).
+
+All of this seems horribly confusing and I don't envy your trying to unwind it.
+
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_8_36519ee4499a19f0864e4fcd264e9933._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_8_36519ee4499a19f0864e4fcd264e9933._comment
new file mode 100644
index 0000000000..39a1ce51d5
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_8_36519ee4499a19f0864e4fcd264e9933._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 8"
+ date="2013-04-26T20:06:34Z"
+ content="""
+Most of this is perfectly normal. The duplication of lines are normal; when two git-annex branches are union merged, it's as if it runs `cat branch1:file branch2:file | uniq > file`. When there are conflicting lines for the same uuid, the one with the newest timestamp is used.
+
+The description of the remote in uuid.log is also not relevant to this bug.
+
+This is the key part:
+
+> The box remote was duplicated (with different davcreds and one having highRandomQuality=false)
+
+As you note, 2013-04-24 15:15 was a merge. So there must have been two branches before, which had different box remotes with different davcreds. 
+
+It would probably help if you can paste those lines as they looked after that merge (omitting most of the davcreds).
+
+Also, I'd like to see the box line from the 11:05 commit.
+"""]]
diff --git a/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_9_85b23f375e53469fb09b24b945b3aba9._comment b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_9_85b23f375e53469fb09b24b945b3aba9._comment
new file mode 100644
index 0000000000..be9bd3c0df
--- /dev/null
+++ b/doc/forum/Not_sure_how_to_get_my_s3_remote_back/comment_9_85b23f375e53469fb09b24b945b3aba9._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkZktNHFhxC1kYA9KKdKpYJO4clq9WDsjE"
+ nickname="Jason"
+ subject="comment 9"
+ date="2013-04-26T20:21:05Z"
+ content="""
+Two box lines after 15:15 merge:
+
+0490d177-78e2-421b-a004-47d88ee7a2e3 chunksize=10mb cipher=... davcreds=... embedcreds=yes highRandomQuality=false name=box.com type=webdav url=https://www.box.com/dav/annex timestamp=1366826729.945023s
+0490d177-78e2-421b-a004-47d88ee7a2e3 chunksize=10mb cipher=... davcreds=... embedcreds=yes name=box.com type=webdav url=https://www.box.com/dav/annex timestamp=1366657062.972357s
+
+After the 11:05 commit, the box line looked like this:
+
+0490d177-78e2-421b-a004-47d88ee7a2e3 chunksize=10mb cipher=... davcreds=... embedcreds=yes highRandomQuality=false name=box.com type=webdav url=https://www.box.com/dav/annex timestamp=1366826729.945023s
+
+I am curious why you want to know about box, when s3 is the one that I'm having trouble with...
+"""]]
diff --git a/doc/forum/OSX_Finder_extension.mdwn b/doc/forum/OSX_Finder_extension.mdwn
new file mode 100644
index 0000000000..2b0e6c374f
--- /dev/null
+++ b/doc/forum/OSX_Finder_extension.mdwn
@@ -0,0 +1,5 @@
+OSX 10.10 / Yosemite introduces the [Finder Sync extension][] which allows any app / extension to display informational badges in Finder. This could be used to indicate the sync status (there are some stories which claim the extensions got added because Dropbox used an undocumented API previously). I had a quick look and it would not be too difficult to implement a simple extension which reads the metadata from the `.git/annex` directory and shows a sync / transfer status icon.
+
+Just wanted to throw the idea out there, I might even start building it.
+
+[Finder Sync Extension]: https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/ExtensibilityPG/Finder.html
diff --git a/doc/forum/OSX_Finder_extension/comment_1_4aa37c3fbe3c260d71f2ed16fd4f20bc._comment b/doc/forum/OSX_Finder_extension/comment_1_4aa37c3fbe3c260d71f2ed16fd4f20bc._comment
new file mode 100644
index 0000000000..4b018ce116
--- /dev/null
+++ b/doc/forum/OSX_Finder_extension/comment_1_4aa37c3fbe3c260d71f2ed16fd4f20bc._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="SchemaCzar"
+ subject="PLEASE!!! PLEASE BUILD IT!!!"
+ date="2015-11-13T16:10:44Z"
+ content="""
+I am completely dying for this
+"""]]
diff --git a/doc/forum/OSX_Finder_extension/comment_2_e16092041890f81dc65a6ab28b2224a6._comment b/doc/forum/OSX_Finder_extension/comment_2_e16092041890f81dc65a6ab28b2224a6._comment
new file mode 100644
index 0000000000..0949047982
--- /dev/null
+++ b/doc/forum/OSX_Finder_extension/comment_2_e16092041890f81dc65a6ab28b2224a6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="released Finder integration"
+ date="2018-03-07T23:23:47Z"
+ content="""
+I just released an app, still in beta that provides Finder integration for git-annex. It relies on Core Data so it actually requires macOS 10.12 or later. If there is enough need/requests it could probably be updated to support OS-X 10.10 by switching from Core Data to sqllite directly.
+
+The app is called [git-annex-turtle](https://github.com/andrewringler/git-annex-turtle) and available on github.
+
+—Andrew
+"""]]
diff --git a/doc/forum/OSX_Mavericks_anyone__63__.mdwn b/doc/forum/OSX_Mavericks_anyone__63__.mdwn
new file mode 100644
index 0000000000..b19133680c
--- /dev/null
+++ b/doc/forum/OSX_Mavericks_anyone__63__.mdwn
@@ -0,0 +1,3 @@
+Was anyone able to run git annex on Mavericks?
+
+Didn't have time for qualified troubleshooting, sorry
diff --git a/doc/forum/OSX_Mavericks_anyone__63__/comment_1_3075b02aeb57adcbf4addf9fb4c123ba._comment b/doc/forum/OSX_Mavericks_anyone__63__/comment_1_3075b02aeb57adcbf4addf9fb4c123ba._comment
new file mode 100644
index 0000000000..1657d676d8
--- /dev/null
+++ b/doc/forum/OSX_Mavericks_anyone__63__/comment_1_3075b02aeb57adcbf4addf9fb4c123ba._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://mike.magin.org/"
+ nickname="mmagin"
+ subject="a little"
+ date="2013-10-24T17:02:18Z"
+ content="""
+Some syncing and copying, nothing other than normal remotes and one S3 remote.
+Haven't even done an \"add\" yet.
+
+Not an assistant user.  Still running 4.20130422-gb9341fd on this computer.
+"""]]
diff --git a/doc/forum/OSX_Mavericks_anyone__63__/comment_2_c2b6110fc4a3d3481ed8a4b48efb9635._comment b/doc/forum/OSX_Mavericks_anyone__63__/comment_2_c2b6110fc4a3d3481ed8a4b48efb9635._comment
new file mode 100644
index 0000000000..bfc43d682a
--- /dev/null
+++ b/doc/forum/OSX_Mavericks_anyone__63__/comment_2_c2b6110fc4a3d3481ed8a4b48efb9635._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Alex"
+ ip="217.8.62.35"
+ subject="not at all"
+ date="2013-10-24T19:50:11Z"
+ content="""
+I'd love to see an updated OS X build for Mavericks.
+
+Currently I'm getting this error:
+
+    dyld: Symbol not found: _objc_debug_taggedpointer_mask
+      Referenced from: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
+      Expected in: /Applications/git-annex.app/Contents/MacOS/bundle/I
+     in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
+    Trace/BPT trap: 5
+
+"""]]
diff --git a/doc/forum/OSX_Mavericks_anyone__63__/comment_3_7df9ba63cb1f385681242b4b58d6a87c._comment b/doc/forum/OSX_Mavericks_anyone__63__/comment_3_7df9ba63cb1f385681242b4b58d6a87c._comment
new file mode 100644
index 0000000000..691fd9064c
--- /dev/null
+++ b/doc/forum/OSX_Mavericks_anyone__63__/comment_3_7df9ba63cb1f385681242b4b58d6a87c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="67.223.19.96"
+ subject="comment 3"
+ date="2013-10-24T19:53:08Z"
+ content="""
+Mavericks is being discussed [[here|bugs/git annex doesn't work in Max OS X 10.9]]
+"""]]
diff --git a/doc/forum/OSX_Mavericks_anyone__63__/comment_4_740fee31c4ca9d84428f97f63ffc075a._comment b/doc/forum/OSX_Mavericks_anyone__63__/comment_4_740fee31c4ca9d84428f97f63ffc075a._comment
new file mode 100644
index 0000000000..3ad5c23446
--- /dev/null
+++ b/doc/forum/OSX_Mavericks_anyone__63__/comment_4_740fee31c4ca9d84428f97f63ffc075a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Alex"
+ ip="217.8.62.35"
+ subject="comment 4"
+ date="2013-10-24T19:55:56Z"
+ content="""
+Thanks, Joey!
+"""]]
diff --git a/doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set.mdwn b/doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set.mdwn
new file mode 100644
index 0000000000..5e417b14c9
--- /dev/null
+++ b/doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set.mdwn
@@ -0,0 +1,12 @@
+This is a tip for users who wish to use remotes which are based on OSX systems and have used macports to install some of the required utilities for git-annex to work.
+
+The default behaviour of OSX's sshd is to have a "highly restricted" restricted environment. The defaults that it allows is
+
+    jtang@x00:~ $ ssh x00 echo \$PATH
+    /usr/bin:/bin:/usr/sbin:/sbin
+
+One solution is to enable *PermitUserEnvironment yes* in `/etc/sshd_config` and then in your own `~/.ssh/environment` file you could add something like (the below is an example)
+
+    PATH=/Users/jtang/bin:/opt/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/X11/bin:/Users/jtang/.cabal/bin:/opt/local/libexec/gnubin
+
+If the above is not done, cloning from the OSX host will fail if git is not installed in /usr/bin (which it probably won't be).
diff --git a/doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set/comment_1_a136ff877389f0930c066ba118edd9fd._comment b/doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set/comment_1_a136ff877389f0930c066ba118edd9fd._comment
new file mode 100644
index 0000000000..0cbf79c8d5
--- /dev/null
+++ b/doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set/comment_1_a136ff877389f0930c066ba118edd9fd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.114"
+ subject="comment 1"
+ date="2014-04-24T18:08:00Z"
+ content="""
+If you use git-annex from the OSX .dmg, it will set up a ~/.ssh/git-annex-shell, which is the only command that is needed when git-annex is using an OSX server as a remote. Since version 5.20140421, the webapp will also use ~/.ssh/git-annex-wrapper, which the .dmg also sets up, to run some commands like git. 
+
+The upshot is that this should not affect git-annex when installed from the .dmg on the OSX server. If you build git-annex from source yourself, you do need to make sure that it and git end up in PATH.
+"""]]
diff --git a/doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set/comment_2_5fcc52a62770fb932a4a2101f5badbc0._comment b/doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set/comment_2_5fcc52a62770fb932a4a2101f5badbc0._comment
new file mode 100644
index 0000000000..bb8f3ee8d7
--- /dev/null
+++ b/doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set/comment_2_5fcc52a62770fb932a4a2101f5badbc0._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="ewen"
+ subject="Linux to OS X ~/.ssh/git-annex-shell"
+ date="2014-11-15T00:02:02Z"
+ content="""
+I installed git-annex on OS/X 10.9 (Mavericks) from the DMG file (the 10.10 DMG file from 2014-11-11, since there was no longer one linked for Mavericks -- it does seem to work locally on 10.9).  Separately I installed git-annex 5.20141024~bpo70+1 on Debian Wheezy, from Backports.  I created a git-annex on the OS X system, and was then trying to set up another git-annex of that on the Linux system, initiated from the Linux system.  After some ssh tunnel magic (due to a firewall stopping git-annex's dream that everything can ssh into everything else without problems), I was able to \"git clone\" and \"git annex init\" on the Linux system.  But ran into problems trying to initiate a \"git annex sync\" from the Linux end.
+
+In particular I got this \"bash: git-annex-shell: command not found\" report, despite the fact that the OS X side *does* have \"~/.ssh/git-annex-shell\" (apparently set up when I ran git-annex on the OS X side first), and on the OS/X side running \"~/.ssh/git-annex-shell\" does work (well it says \"bad parameters\" and gives a list of commands).
+
+It's not clear to me how git-annex is expecting that ~/.ssh/git-annex-shell will end up being found by the ssh connection initiated from the Linux side.  AFAICT from \"git annex sync --debug REMOTE\" (and strace), all that the client end is running is a bare \"git-annex-shell\", so (a) it'd only be searching the path (as per original post), (b) it shouldn't be affected by the different expansion of ~ on Linux and OS/X (/home/ewen and /Users/ewen respectively -- the OS defaults), and (c) AFAICT nothing is adding ~/.ssh to the PATH.  Maybe running something more from the DMG than just the command line \"git-annex\" sets something else up, which I'm expected to set up by hand, that makes \"~/.ssh/git-annex-shell\" be found?
+
+I ended up working around it by noticing that the ssh shell was reading ~/.bashrc (which adds some of my local directories to the PATH), so I was able to add yet another helper script in that directory (~/.bin/, in my case).  Beware it does have to be a direct symlink to the directory with the rest of the git-annex files though, not via another symlink, because the helper scripts only do one level of readlink.  After that it seems to work.
+
+(Possibly these \"make this command available on the PATH at this time\" dependencies could stand to be better documented on the OS X install page?)
+
+Ewen
+"""]]
diff --git a/doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set/comment_3_521f34c340ad54cef6458a8b6cfff8a9._comment b/doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set/comment_3_521f34c340ad54cef6458a8b6cfff8a9._comment
new file mode 100644
index 0000000000..088aa75511
--- /dev/null
+++ b/doc/forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set/comment_3_521f34c340ad54cef6458a8b6cfff8a9._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2014-12-02T17:42:36Z"
+ content="""
+When the git-annex webapp is used to add a ssh repository, it
+installs a ssh key in `~/.ssh/authorized_keys`, which makes
+ssh run `~/.ssh/git-annex-shell` if necessary.
+
+This is not done for you if you set up a ssh remote using git at the
+commend line. In that case, arranging for git-annex-shell to be in PATH
+on the remote host somehow is left up to you.
+"""]]
diff --git a/doc/forum/OSX__39__s_haskell-platform_statically_links_things.mdwn b/doc/forum/OSX__39__s_haskell-platform_statically_links_things.mdwn
new file mode 100644
index 0000000000..537c85d019
--- /dev/null
+++ b/doc/forum/OSX__39__s_haskell-platform_statically_links_things.mdwn
@@ -0,0 +1,17 @@
+This isn't really a bug of git-annex, but a problem with haskell-platform/ghc6.12.x so this post might need to be moved to a better place (maybe tips).
+
+OSX's haskell-platform doesn't have the dynamic libraries available, as far as I know it just isn't supported therefore git-annex will always be statically built on OSX, so wrappers like <http://tsocks.sourceforge.net/> or [[!google dsocks]] for preloading connect() calls won't work. 
+
+<pre>
+jtang@x00:~/annex $ tsocks git annex get .
+dyld: could not load inserted library: /opt/local/lib/libtsocks.dylib
+
+error: git-annex died of signal 5
+</pre>
+
+The side effect of this means that users who are behind restrictive firewalls that allow only ssh via a socks proxy, they will need to configure ssh to use something like <http://bent.latency.net/bent/git/goto-san-connect-1.85/src/connect.html>.
+
+<pre>
+host remotemyhost
+        ProxyCommand connect -S proxy.mydomain:1080 -R local %h %p
+</pre>
diff --git a/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available.mdwn b/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available.mdwn
new file mode 100644
index 0000000000..1f02b568c3
--- /dev/null
+++ b/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available.mdwn
@@ -0,0 +1,36 @@
+I noticed this in my log file...
+
+<pre>
+[2015-05-21 18:10:02 CDT] main: starting assistant version 5.20150508-gf71c23f
+(started...) gpg: keyring `/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg' created
+...
+[2015-05-21 18:10:02 CDT] Upgrader: Checking if an upgrade is available.
+...
+[2015-05-21 18:10:02 CDT] call: curl ["-s","-f","-L","-C","-","-#","-o","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig","http://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg.info.sig","--user-agent","git-annex/5.20150419-g900e1b6"]
+[2015-05-21 18:10:03 CDT] call: gpg ["--no-default-keyring","--no-auto-check-trustdb","--no-options","--homedir","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex-gpg.tmp.0","--keyring","/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg","--verify","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig"]
+gpg: Signature made Fri May  8 15:10:28 2015 CDT using DSA key ID 89C809CB
+gpg: Can't check signature: public key not found
+[2015-05-21 18:10:03 CDT] Upgrader: Failed to check if upgrade is available.
+</pre>
+
+So I copied trustedkeys.gpg from the bundle folder to the MacOS folder, replacing the newly created trustedkeys.gpg and now I get this... which is better... ;-)
+
+<pre>
+[2015-05-21 18:17:24 CDT] main: starting assistant version 5.20150508-gf71c23f
+...
+[2015-05-21 18:17:25 CDT] Upgrader: Checking if an upgrade is available.
+...
+[2015-05-21 18:17:25 CDT] call: curl ["-s","-f","-L","-C","-","-#","-o","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info","http://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg.info","--user-agent","git-annex/5.20150508-gf71c23f"]
+...
+[2015-05-21 18:17:25 CDT] call: curl ["-s","-f","-L","-C","-","-#","-o","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig","http://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg.info.sig","--user-agent","git-annex/5.20150508-gf71c23f"]
+[2015-05-21 18:17:25 CDT] call: gpg ["--no-default-keyring","--no-auto-check-trustdb","--no-options","--homedir","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex-gpg.tmp.0","--keyring","/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg","--verify","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig"]
+gpg: Signature made Fri May  8 15:10:28 2015 CDT using DSA key ID 89C809CB
+gpg: /var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>"
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-05-21 18:17:25 CDT] Upgrader: No new version found.
+</pre>
+
+FYI
diff --git a/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available/comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment b/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available/comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment
new file mode 100644
index 0000000000..39eae02a8b
--- /dev/null
+++ b/doc/forum/OSX__58___Upgrader__58___Failed_to_check_if_upgrade_is_available/comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-22T17:35:11Z"
+ content="""
+Aha, this is a path propel to the trustedkeys.gpg file, it's in bundle/
+in the OSX app, and git-annex tells gpg to look in the parent directory
+instead.
+
+Fixed in git. Unfortunately I can't fix old versions of git-annex so
+OSX users will need to manually upgrade to version 5.20150522 to get this
+fix.
+"""]]
diff --git a/doc/forum/Odd_Hybrid_Symlinks_To_Content.mdwn b/doc/forum/Odd_Hybrid_Symlinks_To_Content.mdwn
new file mode 100644
index 0000000000..5e3b4d8b4a
--- /dev/null
+++ b/doc/forum/Odd_Hybrid_Symlinks_To_Content.mdwn
@@ -0,0 +1,27 @@
+I've somehow managed to get my indirect repository to symlink to literal content instead of object files. 
+
+By this I mean literally the symlink is pointing at the contents of the file as the filename.
+
+So if I have a blah.txt file with this content:
+
+* First line
+* second line
+
+And I ls -al to view the symlink pointer, it shows up as this:
+
+* blah.txt -> First line?second line
+
+It literally has the contents of the file as the destination filename.
+
+I've tried a couple things I could think of to re-symlink the files, but they don't seem to do anything as they think everything is fine:
+
+* git annex indirect //returns nothing
+* git annex lock blah.txt //returns nothing
+* git annex fix blah.txt //returns nothing
+* git annex fsck //returns nothing
+
+I'm actually able to find several of these files hanging around by searching for all symlinks that don't point to something in the .git directory.
+
+Is there a way for me to replace the symlinks with correct symlinks to the objects in .git/annex? Can it even figure out which ones it was supposed to point to if the symlinks are messed up (are filenames -> content hashes stored anywhere else)?
+
+Else I might have to go do some manual rebasing and history editing to try to undo the bad commits manually. I've synced this repo to another direct repo so I'll need to figure out how to manually fix that repo too (using proxy).  From what I can tell the annex/direct/master seems to be same as master and synced/master branches? Is there an [[internals]] page for direct branches besides [[direct_mode]] so I know what should be fixed where?
diff --git a/doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist.mdwn b/doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist.mdwn
new file mode 100644
index 0000000000..dc7ef44eec
--- /dev/null
+++ b/doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist.mdwn
@@ -0,0 +1,45 @@
+When a changed version of a file is created after `git annex unlock && change-file && git annex add` the old file inside `.git/annex/objects` is retained and cannot be removed with `git annex drop`.
+When I checkout a commit which has the old version of the file I can easily `git annex drop` it and then it also vanishes from `.git/annex/objects`.
+
+Look at the following script which reproduces the behavior.
+Is this behavior intended?
+
+My use case is a big music library which does not fit onto my laptop.
+So for updating the metadata in the files I basically run `git annex get <folder> && git annex unlock <folder>` then update all files in that folder and then run `git annex add <folder> && git commit && git copy --to remote && git annex drop <folder>`.
+This works perfectly but the problem is, that all old versions of changed files are retained in `.git/annex/objects` which in no time filled my drive to 100%.
+
+EDIT: As a clarification, I would expect git-annex to also drop the old versions of the file if enough copies exist…
+
+The script:
+
+    #!/usr/bin/env bash
+    cd /tmp
+    git init client
+    cd client
+    git annex init
+    git annex numcopies 1
+    dd if=/dev/zero of=zero bs=1M count=4
+    git annex add zero
+    git commit -m 'Checkin'
+    cd ..
+    git clone client remote
+    cd client
+    git remote add remote ../remote
+    git annex sync
+    git annex copy --to remote
+    git annex drop zero
+    git annex get zero
+    git annex unlock zero
+    echo test >> zero
+    git annex add zero
+    git commit -m 'Update'
+    git annex copy --to remote
+    git annex drop zero
+    cd ..
+    tree {client,remote}/.git/annex/objects
+    cd client
+    git checkout master~
+    git annex drop zero
+    git checkout master
+    cd ..
+    tree {client,remote}/.git/annex/objects
diff --git a/doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist/comment_1_d43c3b97af1d9d2d4534b40a43567420._comment b/doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist/comment_1_d43c3b97af1d9d2d4534b40a43567420._comment
new file mode 100644
index 0000000000..b467597216
--- /dev/null
+++ b/doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist/comment_1_d43c3b97af1d9d2d4534b40a43567420._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="guzik.sergey@9391b6c15e4938a539e36fbe5bab71df07111d2e"
+ nickname="guzik.sergey"
+ avatar="http://cdn.libravatar.org/avatar/69073e903eefa0bc2755123b26441a2f"
+ subject="comment 1"
+ date="2019-01-13T14:50:44Z"
+ content="""
+The behaviour you described is intended, git annex preserves all versions of all files. Those old file are refered in git annex documentation as `unused`, so you can search for this term. Following are main commands:
+
+- [git annex unused](https://git-annex.branchable.com/git-annex-unused/)
+- [git annex dropunused](https://git-annex.branchable.com/git-annex-dropunused/)
+- [git annex drop --unused](https://git-annex.branchable.com/git-annex-drop/)
+"""]]
diff --git a/doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist/comment_2_81e3664c6746fbeb2d76cca7160cf58a._comment b/doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist/comment_2_81e3664c6746fbeb2d76cca7160cf58a._comment
new file mode 100644
index 0000000000..e0a171f641
--- /dev/null
+++ b/doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist/comment_2_81e3664c6746fbeb2d76cca7160cf58a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jonas"
+ avatar="http://cdn.libravatar.org/avatar/33f6268ae24acfbdc02a1c80f6ff5e8e"
+ subject="comment 2"
+ date="2019-01-13T20:21:30Z"
+ content="""
+Thanks for the comment. I somehow forgot to mention that in my post, that `unused` does virtually nothing in this case.
+If you stop my example after the first `tree` invocation and then in the `client` repository do `git annex unused` it tells you that there are no unused files. And hence neither `dropunused` or `drop --unused` does anything more.
+
+So somehow I'm still stuck with this old version of the file which is duplicated and hence should be found and deletable, if I'm not mistaken.
+"""]]
diff --git a/doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist/comment_3_d5b2b68f22796c3ecd2929f47db3601e._comment b/doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist/comment_3_d5b2b68f22796c3ecd2929f47db3601e._comment
new file mode 100644
index 0000000000..9f552476de
--- /dev/null
+++ b/doc/forum/Old_versions_of_files_are_not_dropped_even_though_enough_copies_exist/comment_3_d5b2b68f22796c3ecd2929f47db3601e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jonas"
+ avatar="http://cdn.libravatar.org/avatar/33f6268ae24acfbdc02a1c80f6ff5e8e"
+ subject="comment 3"
+ date="2019-01-13T20:40:09Z"
+ content="""
+Ok, after upgrading my repository to v7 (apparently repositories are still created as v5) git annex finds the unused versions and lets me drop them.
+"""]]
diff --git a/doc/forum/One_repo_with_multiple_remotes.mdwn b/doc/forum/One_repo_with_multiple_remotes.mdwn
new file mode 100644
index 0000000000..a9d306cb16
--- /dev/null
+++ b/doc/forum/One_repo_with_multiple_remotes.mdwn
@@ -0,0 +1,20 @@
+I have three machines with the same repository in all of the machines.
+  
+  - cat-laptop:~/personal
+  - dog:~/personal
+  - turtle:~/personal
+ 
+All of them are connected to each other in `client mode`, and were
+paired via the `Assistant` as `Local Computers`.
+
+`dog:~/personal` is accessible through the LAN and externally to the
+internet.
+
+Will there be a problem if I add `dog:~/personal` as a `Remote Server`
+through the assistant  with a different hostname and port to
+`cat-laptop:~/personal`? And does git-annex know what remote to use if
+`cat-laptop` is connected to the same LAN as `dog`?
+
+My  worries are file collisions, missing commits, or any lose of
+updates because of one repository treated as multiple remotes in other
+client repositories.
diff --git a/doc/forum/One_repo_with_multiple_remotes/comment_1_4b9b3137396a3e830fe96726401270b8._comment b/doc/forum/One_repo_with_multiple_remotes/comment_1_4b9b3137396a3e830fe96726401270b8._comment
new file mode 100644
index 0000000000..e4e7fb321f
--- /dev/null
+++ b/doc/forum/One_repo_with_multiple_remotes/comment_1_4b9b3137396a3e830fe96726401270b8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 1"
+ date="2018-03-21T12:17:45Z"
+ content="""
+That's not a problem at all. The repositories are identified by their UUID, so there's no danger of annex counting too many copies. Local remotes have a lower cost, so git-annex should prefer them, but you're probably going to encounter connection errors when you're not inside the LAN, so have a look at the annex-ignore-command option (see [manpage](https://git-annex.branchable.com/git-annex)).
+"""]]
diff --git a/doc/forum/OpenOffice___47___Libre_Office.mdwn b/doc/forum/OpenOffice___47___Libre_Office.mdwn
new file mode 100644
index 0000000000..f28ad62598
--- /dev/null
+++ b/doc/forum/OpenOffice___47___Libre_Office.mdwn
@@ -0,0 +1,5 @@
+I'm trying to use git-annex for keeping my company invoices data. It seems a good idea because it's encrypted and whatnot, I'd never upload them to Dropbox. However, Libre Office refuses to work with files copied to annex-tracked folder. It's likely a flaw in LO/OOo, but maybe someone here knows a way to make the two work together.
+
+When opening a spreadsheet, I'm getting a "Document in use - document locked by: Unknown User - Open read-only or open a copy" dialog. I tried opening a copy and saving under a different filename , but I can only save once - any subsequent saves to the same filename result in an error.
+
+A graphic version of my story: http://f.gdr.name/annex-ooo-1.png http://f.gdr.name/annex-ooo-2.png
diff --git a/doc/forum/OpenOffice___47___Libre_Office/comment_1_98ed542fedd820d47bf8deb7d3232725._comment b/doc/forum/OpenOffice___47___Libre_Office/comment_1_98ed542fedd820d47bf8deb7d3232725._comment
new file mode 100644
index 0000000000..68dbee1661
--- /dev/null
+++ b/doc/forum/OpenOffice___47___Libre_Office/comment_1_98ed542fedd820d47bf8deb7d3232725._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 1"
+ date="2013-01-02T19:10:28Z"
+ content="""
+Files in git-annex are locked normally. You can use `git annex unlock` to unlock a file for editing. Or you can use the new [[direct_mode]].
+"""]]
diff --git a/doc/forum/OpenOffice___47___Libre_Office/comment_2_f313fdaa23863c2ae99cfbfe9ec2e1e0._comment b/doc/forum/OpenOffice___47___Libre_Office/comment_2_f313fdaa23863c2ae99cfbfe9ec2e1e0._comment
new file mode 100644
index 0000000000..394f6fb012
--- /dev/null
+++ b/doc/forum/OpenOffice___47___Libre_Office/comment_2_f313fdaa23863c2ae99cfbfe9ec2e1e0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~gdr-go2"
+ nickname="gdr-go2"
+ subject="Thanks"
+ date="2013-01-02T19:58:44Z"
+ content="""
+Direct mode has solved the problem. Great new addition.
+"""]]
diff --git a/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory.mdwn b/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory.mdwn
new file mode 100644
index 0000000000..94953b60e7
--- /dev/null
+++ b/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory.mdwn
@@ -0,0 +1,34 @@
+I do the following:
+
+    # create repo
+    git init repo
+    git -C ./repo annex init --version=6
+    git -C ./repo config annex.thin true
+    # add big file
+    cd repo
+    cp /tmp/bigfile . # 12GB file on system with 8GB RAM
+    git annex add bigfile
+    # commit
+    git commit -m 'msg'
+
+On the commit, I get "fatal: Out of memory, realloc failed". I found out that "git add" leads to the same error with big files, so I use "git annex add".
+
+I do this on an NFS4 disk. The same on the local EXT4 disk works.
+
+I have noticed that annex creates a link for the file on EXT4 but not on NFS4. This seems suspicious.
+
+Version information:
+
+    git version
+    git version 2.16.2
+
+    git annex version
+    build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+    dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.1 persistent-sqlite-2.6.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+    local repository version: 6
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
diff --git a/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_1_2e89bcc3fbd069e5d9eb12c1c19993ad._comment b/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_1_2e89bcc3fbd069e5d9eb12c1c19993ad._comment
new file mode 100644
index 0000000000..95c0388366
--- /dev/null
+++ b/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_1_2e89bcc3fbd069e5d9eb12c1c19993ad._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yves.noirjean@3f9b06d19a920fbf5c82340c362e5971b00d4af2"
+ nickname="yves.noirjean"
+ avatar="http://cdn.libravatar.org/avatar/2f1ad9d443c037337d91f29781560344"
+ subject="comment 1"
+ date="2018-06-08T15:17:16Z"
+ content="""
+I wanted to try it with a repository using v5 indirect mode. This tells me:
+
+      Filesystem allows writing to files whose write bit is not set.
+    git-annex: This repository seems to be on a crippled filesystem, you must use direct mode.
+
+Is that the case with NFS4 in general or might the disk not be mounted properly?
+"""]]
diff --git a/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_2_cf8065e697a0a83cf3461672cb6421e0._comment b/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_2_cf8065e697a0a83cf3461672cb6421e0._comment
new file mode 100644
index 0000000000..51edcafd5a
--- /dev/null
+++ b/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_2_cf8065e697a0a83cf3461672cb6421e0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yves.noirjean@3f9b06d19a920fbf5c82340c362e5971b00d4af2"
+ nickname="yves.noirjean"
+ avatar="http://cdn.libravatar.org/avatar/2f1ad9d443c037337d91f29781560344"
+ subject="comment 2"
+ date="2018-06-18T11:25:18Z"
+ content="""
+The issue has been resolved. The unix file permissions were not applied, but the NFS4 permissions. So git annex did not trust that files without write flags could not be changed. Therefore, it didn't move the files and create symlinks. This somehow lead to git allocating a lot of memory during commit.
+"""]]
diff --git a/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_3_e6bd4eb070a094116e13064dca6d5bb5._comment b/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_3_e6bd4eb070a094116e13064dca6d5bb5._comment
new file mode 100644
index 0000000000..94ae963a3f
--- /dev/null
+++ b/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_3_e6bd4eb070a094116e13064dca6d5bb5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yves.noirjean@3f9b06d19a920fbf5c82340c362e5971b00d4af2"
+ nickname="yves.noirjean"
+ avatar="http://cdn.libravatar.org/avatar/2f1ad9d443c037337d91f29781560344"
+ subject="comment 3"
+ date="2018-06-21T16:15:05Z"
+ content="""
+Actually, I am still interested in a response.
+
+I would prefer to use annex.addunlocked = true, which would use hardlinks.
+"""]]
diff --git a/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_4_42adc29a2c3216910a3bcda04d6f6a6b._comment b/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_4_42adc29a2c3216910a3bcda04d6f6a6b._comment
new file mode 100644
index 0000000000..7efefbffb1
--- /dev/null
+++ b/doc/forum/Out_of_memory_on_NFS4_with_files_bigger_than_available_memory/comment_4_42adc29a2c3216910a3bcda04d6f6a6b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 4"
+ date="2018-07-09T13:44:15Z"
+ content="""
+Yes, see Joey's notes at [smudge](http://git-annex.branchable.com/todo/smudge/) *“When git add is run with a large file, it allocates memory for the whole file content, even though it's only going to stream it to the clean filter. My proposed smudge/clean interface patch also fixed this problem, since it made git not read the file at all.”* I believe that `git annex add` will avoid this issue as you have seen.
+
+See also [unlocked files](http://git-annex.branchable.com/tips/unlocked_files/):
+
+   - `git config annex.addunlocked true` tells git annex to add all files as unlocked
+   - `git config annex.thin true` tells git annex to only keep one copy of unlocked files by using hardlinks
+
+I believe both of these settings only have an effect on a V6 repo. I assume for your desires you will want to use both settings. Did you try setting both of these on your V6 repo then doing a `git annex add`?
+
+The unlocked page and smudge page also talk about various limitations of the thin setting, for example from the smudge page: *“…with annex.thin no attempt is made to protect the object from being modified. If a user wants to protect object contents from modification, they should use git annex add, not git add, or they can git annex lock after adding, or not enable annex.thin.”*
+"""]]
diff --git a/doc/forum/Overwriting_data_without_getting_it.mdwn b/doc/forum/Overwriting_data_without_getting_it.mdwn
new file mode 100644
index 0000000000..ccd23b74e7
--- /dev/null
+++ b/doc/forum/Overwriting_data_without_getting_it.mdwn
@@ -0,0 +1,3 @@
+My collaborators and I use git annex to track various large data files (among some smaller metadata files managed by ordinary git).  Some of these data files need to change completely -- the old ones were just wrong.  So I do a git checkout, but don't `git annex get` because it would just be a waste of time and bandwidth.  This means that my "data files" are just broken symlinks.  Now, I find that by making the necessary directories under `.git/annex/objects/`, I can write to these files in the usual way.  The symlinks are preserved, and the files they link to now exist and are full of my corrected data.  This seems like it's a problem because the hash has presumably changed.  (I'm still a little fuzzy on how exactly git-annex works.)  Also, git/git-annex doesn't seem to realize that anything has changed.  Is this recoverable?
+
+Would it have been better to just `git rm` (or something) the original version of the file, commit that, and then add the new data?  And if so, how should I go about this now that I've created these many very large files?  If not, what would be the preferred way to do this?
diff --git a/doc/forum/Overwriting_data_without_getting_it/comment_1_f1c0199ee9bffcc84287370b89361294._comment b/doc/forum/Overwriting_data_without_getting_it/comment_1_f1c0199ee9bffcc84287370b89361294._comment
new file mode 100644
index 0000000000..a6092b1f21
--- /dev/null
+++ b/doc/forum/Overwriting_data_without_getting_it/comment_1_f1c0199ee9bffcc84287370b89361294._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-06-12T16:57:52Z"
+ content="""
+I think you're making this more complicated than it needs to be. You don't need to mess around with .git/annex/objects at all. You can replace git-annex symlinks with new files and git annex add the new content.
+
+For example:
+
+[[!format sh \"\"\"
+joey@gnu:~/tmp/repo>git annex drop --force foo
+drop foo ok
+(Recording state in git...)
+joey@gnu:~/tmp/repo>ls
+foo@
+joey@gnu:~/tmp/repo>rm foo
+joey@gnu:~/tmp/repo>echo \"new good contents\" > foo
+joey@gnu:~/tmp/repo>git annex add foo
+add foo (checksum...) ok
+(Recording state in git...)
+joey@gnu:~/tmp/repo>git commit -m add
+[master ec3ed14] add
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+\"\"\"]]
+"""]]
diff --git a/doc/forum/Overwriting_data_without_getting_it/comment_2_6a1d08dbca206129ef6cf8aa97daeee1._comment b/doc/forum/Overwriting_data_without_getting_it/comment_2_6a1d08dbca206129ef6cf8aa97daeee1._comment
new file mode 100644
index 0000000000..698d00c35b
--- /dev/null
+++ b/doc/forum/Overwriting_data_without_getting_it/comment_2_6a1d08dbca206129ef6cf8aa97daeee1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkxmke7K8gEXleVRuQvCK5LHPLIzQA6s0E"
+ nickname="Michael"
+ subject="comment 2"
+ date="2013-06-12T17:14:11Z"
+ content="""
+Yes, it seems I was making this more complicated than it needed to be.  Just a plain rm seems to work.  But just to be clear, I never had the data so I don't need to drop it, right?  (By which I mean, is there some other function of drop that I don't understand?)
+"""]]
diff --git a/doc/forum/Overwriting_data_without_getting_it/comment_3_52958e76e506fdbb6b533681ab619b3b._comment b/doc/forum/Overwriting_data_without_getting_it/comment_3_52958e76e506fdbb6b533681ab619b3b._comment
new file mode 100644
index 0000000000..19292b8707
--- /dev/null
+++ b/doc/forum/Overwriting_data_without_getting_it/comment_3_52958e76e506fdbb6b533681ab619b3b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-06-12T17:15:26Z"
+ content="""
+Right. I just put the drop in there to get my repository to the state you described.
+"""]]
diff --git a/doc/forum/PDF-related_error_when_running_git-annex-add_or_git-annex-status.mdwn b/doc/forum/PDF-related_error_when_running_git-annex-add_or_git-annex-status.mdwn
new file mode 100644
index 0000000000..0200168519
--- /dev/null
+++ b/doc/forum/PDF-related_error_when_running_git-annex-add_or_git-annex-status.mdwn
@@ -0,0 +1,15 @@
+When I run either "git annex add" or "git annex status" on a repository with PDF files, I'm getting the following errors:
+
+    Syntax Warning: May not be a PDF file (continuing anyway)
+    Syntax Error: Couldn't read xref table
+    Syntax Warning: PDF file is damaged - attempting to reconstruct xref table...
+    Syntax Error: Couldn't find trailer dictionary
+    Syntax Error: Couldn't read xref table
+
+I checked the PDFs and I can open them.
+
+What is triggerring these errors? Frequently these errors freezes the git-annex process and I have no choice but to kill one by one all the spawned git processes.
+
+Again, I'm in Windows 7, using Git 2.28.0.windows.1 and git-annex 8.20200815-g335aae266 on a newly-created repository in an NTFS partition.
+
+
diff --git a/doc/forum/PDF-related_error_when_running_git-annex-add_or_git-annex-status/comment_1_4df2625cc1f1de8f164aa9500eb80e13._comment b/doc/forum/PDF-related_error_when_running_git-annex-add_or_git-annex-status/comment_1_4df2625cc1f1de8f164aa9500eb80e13._comment
new file mode 100644
index 0000000000..e85e204c65
--- /dev/null
+++ b/doc/forum/PDF-related_error_when_running_git-annex-add_or_git-annex-status/comment_1_4df2625cc1f1de8f164aa9500eb80e13._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-05-03T12:33:32Z"
+ content="""
+Git on Windows configures a diff driver by default, which is probably throwing these errors (For whathever reason... sigh). It's the `diff.astextplain.textconv` setting that you have to unset. I.e. Launch Git Bash as Administrator and run `git config --unset --system diff.astextplain.textconv`.
+"""]]
diff --git a/doc/forum/Paths_changed_in_.git__47__annex__47__objects.mdwn b/doc/forum/Paths_changed_in_.git__47__annex__47__objects.mdwn
new file mode 100644
index 0000000000..4d0a889894
--- /dev/null
+++ b/doc/forum/Paths_changed_in_.git__47__annex__47__objects.mdwn
@@ -0,0 +1,31 @@
+Hello,
+
+Has anyone encountered this issue:
+
+I have a repository in version 7. It has various remotes and clones from my frantic attempts to recover my data without really knowing what I'm doing. Anyways, the files in the repository are text files with hashes in them:
+
+
+    cat demo_beheer.gpkg
+    /annex/objects/SHA256E-s204800--a518c074bc22f673f0c73191a01426fef0a7d8b262a17d2729a4a3ac51da40ce.gpkg
+
+
+But in `.git/annex/objects` there are two-letter directories. I can find this file in there, but its name is different than the above. All the .gpkg files under `.git/annex/objects` are intact (I can open them), and also appear to be versions of the same file (the `demo_beheer.gpkg` one I'm looking for).
+
+
+    find -name '*.gpkg' -type f
+    ./.git/annex/objects/Gz/v4/SHA256E-s204800--01120000361af90c29ee27a51ef7a6157bc413dc768d8ba495b7df8360c6dbfe.gpkg/SHA256E-s204800--01120000361af90c29ee27a51ef7a6157bc413dc768d8ba495b7df8360c6dbfe.gpkg
+    ./.git/annex/objects/mV/6j/SHA256E-s204800--222d8fe6975a07a6305b27a453c7db62df0518458d53252bee2f8bac16d1329c.gpkg/SHA256E-s204800--222d8fe6975a07a6305b27a453c7db62df0518458d53252bee2f8bac16d1329c.gpkg
+    ./.git/annex/objects/Q3/30/SHA256E-s204800--71d2d90cb98ea98806b6f9ae479ffae7d2d7f6b1fb6ea970c108ef0b7b0a52ec.gpkg/SHA256E-s204800--71d2d90cb98ea98806b6f9ae479ffae7d2d7f6b1fb6ea970c108ef0b7b0a52ec.gpkg
+    ./.git/annex/objects/X7/QJ/SHA256E-s204800--d3ce397eb2f1d5080641e15a8d28a5ebabf56ce03b756ed6ceb93fec0d390c72.gpkg/SHA256E-s204800--d3ce397eb2f1d5080641e15a8d28a5ebabf56ce03b756ed6ceb93fec0d390c72.gpkg
+    ./.git/annex/transfer/failed/download/a3f8a46a-60fe-58e2-901b-2c093bcc22d3/SHA256E-s3989504--78a7d01d5b7331cb867464c5787264292b39905533be58822a63c9f6d9ea8b3d.gpkg
+    ./.git/annex/transfer/failed/download/a3f8a46a-60fe-58e2-901b-2c093bcc22d3/SHA256E-s1929216--03c015bdd9ac6efadf5d855bed734fb20531938d93d70c075cfc47b5f3f3a64b.gpkg
+    ./.git/annex/transfer/failed/download/a3f8a46a-60fe-58e2-901b-2c093bcc22d3/SHA256E-s946176--49fe39ceb46d2518bfff4dfe2e1e83c043ad76f13871c4143a5fff68540d943c.gpkg
+    ./.git/annex/transfer/failed/download/a3f8a46a-60fe-58e2-901b-2c093bcc22d3/SHA256E-s204800--a518c074bc22f673f0c73191a01426fef0a7d8b262a17d2729a4a3ac51da40ce.gpkg
+    ./.git/annex/transfer/failed/download/a3f8a46a-60fe-58e2-901b-2c093bcc22d3/SHA256E-s51445760--a44651f781e5fce11bc498ba7fc30a0b79e5f7e282226852ef949f45888fb6eb.gpkg
+    ./.git/annex/transfer/failed/download/a3f8a46a-60fe-58e2-901b-2c093bcc22d3/SHA256E-s4091904--3eb3df304d9fab549dcc657198c88bfc300f8c11836ecc62ae68538a67e3d430.gpkg
+    ./.git/annex/transfer/failed/download/a3f8a46a-60fe-58e2-901b-2c093bcc22d3/SHA256E-s63684608--e5ff8eb805b96c7e231b7450514d101397a98a11f9320416d78084b9cad58e93.gpkg
+    ./demo_beheer.gpkg
+
+Is this a recognized result of some slip-up I've made? I can't remember what exactly I did to reach here other than try to clone the repo various times, and I might have messed up some paths because of struggling with the gcrypt url formats. I can of course provide more details if that would help. Alternatively, does someone have an idea of how I could recover these files simply, to start over?
+
+Help would be much appreciated.
diff --git a/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_1_e89aa61303d97bfd433e24173867723a._comment b/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_1_e89aa61303d97bfd433e24173867723a._comment
new file mode 100644
index 0000000000..e73ec845f7
--- /dev/null
+++ b/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_1_e89aa61303d97bfd433e24173867723a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="fasthans@87884c78197fe1a25ac25ae7fa1d930c147e9592"
+ avatar="http://cdn.libravatar.org/avatar/6d89ddec3053d8df7e57cf2f28c8cdcd"
+ subject="prior research"
+ date="2020-01-07T19:07:17Z"
+ content="""
+I forgot to mention, all I've been able to find that seemed related was this post: https://git-annex.branchable.com/bugs/fix_git-annex_paths___47___objects___40__repository_not_available__41__/
+
+but I couldn't figure out if this was a similar problem to mine.
+"""]]
diff --git a/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_2_3e467d256ef7c2f4d469073c00cacbca._comment b/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_2_3e467d256ef7c2f4d469073c00cacbca._comment
new file mode 100644
index 0000000000..f1ff0f671d
--- /dev/null
+++ b/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_2_3e467d256ef7c2f4d469073c00cacbca._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-01-07T19:24:31Z"
+ content="""
+"/annex/objects/SHA256E-s204800--a518c074bc22f673f0c73191a01426fef0a7d8b262a17d2729a4a3ac51da40ce.gpkg" is
+used when an annexed object in a v7 repository is unlocked.
+
+If you run `git annex lock` on it, it will be turned backed into a symlink to
+the .git/annex/objects file.
+
+Normally unlocked files have that pointer replaced with the file content when 
+it's available, and only when the file content is not available would you see
+that pointer. I guess you've done something to get your repository into this
+state where the content is present but the unlocked file is not populated with 
+it. It's likely that running `git annex fsck` on the file would fix that problem.
+"""]]
diff --git a/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_3_119c181afe351a412e8a13c59175ec45._comment b/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_3_119c181afe351a412e8a13c59175ec45._comment
new file mode 100644
index 0000000000..a08729f665
--- /dev/null
+++ b/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_3_119c181afe351a412e8a13c59175ec45._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-01-07T19:31:14Z"
+ content="""
+Looking more closely at your list of files, your repository does not
+contain a copy of the current version of demo_beheer.gpkg, which is
+"SHA256E-s204800--a518c074bc22f673f0c73191a01426fef0a7d8b262a17d2729a4a3ac51da40ce.gpkg"
+
+There's evidence you tried to download that key from somewhere, but the
+download failed.
+
+So, it seems that your repository is not in any unsual state, you're just
+confused about how an unlocked file that is not present looks. Probably
+commands like these will be useful:
+
+	git annex get demo_beheer.gpkg
+	git annex whereis demo_beheer.gpkg
+"""]]
diff --git a/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_4_0a9cec8f4e26c2e2365b54b29c91ee3d._comment b/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_4_0a9cec8f4e26c2e2365b54b29c91ee3d._comment
new file mode 100644
index 0000000000..c5ebf224b9
--- /dev/null
+++ b/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_4_0a9cec8f4e26c2e2365b54b29c91ee3d._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="fasthans@87884c78197fe1a25ac25ae7fa1d930c147e9592"
+ avatar="http://cdn.libravatar.org/avatar/6d89ddec3053d8df7e57cf2f28c8cdcd"
+ subject="comment 4"
+ date="2020-01-08T12:08:23Z"
+ content="""
+Thanks for your attention, Joey.
+
+Hmm. `git annex fsck` reports 'ok' for all files. After that, running get/whereis I get:
+
+````
+git annex get demo_beheer.gpkg
+get demo_beheer.gpkg (not available) 
+  Try making some of these repositories available:
+        a3f8a46a-60fe-58e2-901b-2c093bcc22d3 -- smdata_encrypted_remote_wd_elements_small
+failed
+git-annex: get: 1 failed
+````
+
+this is the remote in question, which is accessible (it's on the same drive as the current repo)
+
+````
+git remote -v
+smdata_encrypted_remote_wd_elements_small       gcrypt::/media/hans/Elements/smdata_encrypted_remote_wd_elements_small/ (fetch)
+smdata_encrypted_remote_wd_elements_small       gcrypt::/media/hans/Elements/smdata_encrypted_remote_wd_elements_small/ (push)
+````
+
+However, I can run `git annex sync smdata_remote_wd_elements_small`, which does complete successfully, so why is it not accessible with `get` or `copy`?
+
+If I `lock` demo_beheer.gpkg, it turns into this symlink:
+
+````
+lrwxrwxrwx 1 hans hans 198 sep  2 07:32 demo_beheer.gpkg -> .git/annex/objects/px/Mg/SHA256E-s204800--a518c074bc22f673f0c73191a01426fef0a7d8b262a17d2729a4a3ac51da40ce.gpkg/SHA256E-s204800--a518c074bc22f673f0c73191a01426fef0a7d8b262a17d2729a4a3ac51da40ce.gpkg
+````
+
+of which the target indeed does not exist (the directory exists, not the file). However, git annex get still fails after locking (and a subsequent sync) and I am at a loss to know why.
+
+This wouldn't be due to the nature of the remote, or my URL for it, or something? Decryption works fine when syncing.
+
+
+"""]]
diff --git a/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_5_df986910016ce53a6155edf96f4c312d._comment b/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_5_df986910016ce53a6155edf96f4c312d._comment
new file mode 100644
index 0000000000..675ecc6841
--- /dev/null
+++ b/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_5_df986910016ce53a6155edf96f4c312d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-01-08T18:24:43Z"
+ content="""
+`git-annex sync` does not, by default, download the content of annexed
+files. Use `git annex get`
+"""]]
diff --git a/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_6_c4fe35a93ed32f7b14c5ffd5a4a8ec27._comment b/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_6_c4fe35a93ed32f7b14c5ffd5a4a8ec27._comment
new file mode 100644
index 0000000000..80afc809c8
--- /dev/null
+++ b/doc/forum/Paths_changed_in_.git__47__annex__47__objects/comment_6_c4fe35a93ed32f7b14c5ffd5a4a8ec27._comment
@@ -0,0 +1,77 @@
+[[!comment format=mdwn
+ username="hans"
+ avatar="http://cdn.libravatar.org/avatar/8bf4f81bbfce61274f5def013dde7083"
+ subject="comment 6"
+ date="2020-01-16T14:22:03Z"
+ content="""
+I have been trying `get` and `copy` and `whereis`. They all report failure and suggest making the remote `a3f8a46a-60fe-58e2-901b-2c093bcc22d -- smdata_encrypted_remote_wd_elements_small` available.
+
+The remote with this name is available -- at least, I can `sync` with it. However, in `.git/config` the `annex-uuid` is `97d51497-158f-54ef-baef-77a720c9d758`.
+
+as far as I can tell -- I'm shooting in the dark here -- that isn't the issue, because if I change the uuid in `.git/config` it still gives the same error, now with the changed uuid.
+
+So, let me review my mental model of this situation, which will hopefully reveal the gaping holes:
+
+normally, content tracking means each repo knows which other repos have copies of the file. In locked mode, as you said, the file is a symlink to the annexed object and if that target is missing the symlink is simply broken. In unlocked mode, the file is present at its correct location but if it is missing it is replaced with a text file with an annex object path as the contents.
+
+So, my content has somehow gone missing.
+
+Not knowing very much about git-annex's internals, my next question would be: how can I look for this content? I can't explore the files in the remote manually, since they are encrypted. This is what happens if I clone that bare repo again:
+
+```
+$mkdir test && cd test
+$git init
+$git remote add origin gcrypt::/media/hans/Elements/smdata_encrypted_remote_wd_elements_small
+$git annex init
+init  ok
+(recording state in git...)
+$git annex whereis demo_beheer.gpkg
+whereis demo_beheer.gpkg (0 copies) failed #ok, so I need to sync first
+$git annex sync
+commit 
+On branch master
+nothing to commit, working tree clean
+ok
+pull origin 
+gcrypt: Decrypting manifest
+gpg: Signature made do 16 jan 2020 14:08:44 CET
+gpg:                using RSA key xxxxxxxxxxxxxxxxxxxxxx
+gpg: Good signature from \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\" [ultimate]
+From gcrypt::/media/hans/Elements/smdata_encrypted_remote_wd_elements_small
+ * [new branch]        synced/master    -> origin/synced/master
+ * [new branch]        synced/git-annex -> origin/synced/git-annex
+ * [new branch]        git-annex        -> origin/git-annex
+ok
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+push origin 
+gcrypt: Decrypting manifest
+gpg: Signature made do 16 jan 2020 14:08:44 CET
+gpg:                using RSA key xxxxxxxxxxxxx
+gpg: Good signature from \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\" [ultimate]
+Enumerating objects: 8, done.
+Counting objects: 100% (8/8), done.
+Compressing objects: 100% (6/6), done.
+Total 8 (delta 1), reused 1 (delta 0)
+gcrypt: Encrypting to: --throw-keyids --default-recipient-self
+gcrypt: Requesting manifest signature
+gpg: using \"xxxxxxxxxxxxxxxxxx\" as default secret key for signing
+To gcrypt::/media/hans/Elements/smdata_encrypted_remote_wd_elements_small
+   10150f10..79a49878  git-annex -> synced/git-annex
+ok
+#try again
+$git annex whereis demo_beheer.gpkg
+whereis demo_beheer.gpkg (1 copy) 
+        a3f8a46a-60fe-58e2-901b-2c093bcc22d3 -- smdata_encrypted_remote_wd_elements_small
+ok
+```
+
+So: the `git-annex` branch is indicating that the content is available in this bare remote, but is that not true? Is there a way for me to determine (with or without git-annex) if the content is actually there or not?
+
+From the speed at which the `git annex get` command returns its error message I get the impression that it's not actually checking the remote, but determining from the local `git-annex` branch that the content is not in the remote. Is that correct? Why does it then suggest making that remote available? In that case, is there a way to figure out if and when the `git-annex` branch logs have diverged from reality, OR alternatively how to find out if there is content in that repository?
+
+What is also really bugging me is that I have the content of some files available in one of my clones, but I can't access them via git-annex. My files are of such a number and format that manually fishing them out of `.git/annex/objects` is not feasible (e.g. shapefiles which consist of about six different files).
+
+
+Finally, the most relevant git-annex command I've been able to find is `git annex unused`, which gives me some interesting information in the bare repository (1900+ unused objects), but `addunused` doesn't seem to  bring things back.
+"""]]
diff --git a/doc/forum/Per_directory_numcopies.mdwn b/doc/forum/Per_directory_numcopies.mdwn
new file mode 100644
index 0000000000..a151c937a8
--- /dev/null
+++ b/doc/forum/Per_directory_numcopies.mdwn
@@ -0,0 +1,5 @@
+I have some photo backups that I would like to have 2 copies but the rest can be one. 
+
+Is there any way to create numcopies rules per directory, rather than by filetype?
+
+I really enjoy this program Joey, thanks!
diff --git a/doc/forum/Per_directory_numcopies/comment_1_33497e3a46926595920eb3dcdb58447c._comment b/doc/forum/Per_directory_numcopies/comment_1_33497e3a46926595920eb3dcdb58447c._comment
new file mode 100644
index 0000000000..cb6a9579d8
--- /dev/null
+++ b/doc/forum/Per_directory_numcopies/comment_1_33497e3a46926595920eb3dcdb58447c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="markusk"
+ subject="comment 1"
+ date="2015-03-03T21:04:55Z"
+ content="""
+Look for \".gitattributes\" files in http://git-annex.branchable.com/walkthrough/backups/ and the \"annex.numcopies\" option to use inside these files. You can place the files at any location. 
+
+
+"""]]
diff --git a/doc/forum/Per_directory_numcopies/comment_2_00572e3c15e5a9d253fb4ea57b45ff0d._comment b/doc/forum/Per_directory_numcopies/comment_2_00572e3c15e5a9d253fb4ea57b45ff0d._comment
new file mode 100644
index 0000000000..d75f37ec05
--- /dev/null
+++ b/doc/forum/Per_directory_numcopies/comment_2_00572e3c15e5a9d253fb4ea57b45ff0d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawksOCeakibYmGDt3wLLo4nkY0FkB72I2Uo"
+ nickname="Source"
+ subject="comment 2"
+ date="2015-03-05T01:27:52Z"
+ content="""
+That's exactly what I was looking for, Thanks!
+"""]]
diff --git a/doc/forum/Performance_implications_of_triply_nested_objects_directory.mdwn b/doc/forum/Performance_implications_of_triply_nested_objects_directory.mdwn
new file mode 100644
index 0000000000..7a6e548b1f
--- /dev/null
+++ b/doc/forum/Performance_implications_of_triply_nested_objects_directory.mdwn
@@ -0,0 +1,23 @@
+Posting this in case anyone might find it interesting.
+
+I had noticed impractical and abysmally slow performance when tracking a huge number of files (150k) in a git-annex. In direct mode, the repo was outright unusable, but even in indirect mode, many operations where painfully slow; even operations beyond the well-known offender, «git annex findunused», e.g., the seemingly harmless «git annex info».
+
+I also noticed that the performance was hugely improved on my (otherwise comparable) machine running btrfs, and I wondered how this might be. From previous benchmarks, I had gained the impression that ext4 and btrfs are on par, performance-wise, and you choose btrfs for the features rather than performance. Now, after trying to update my back-ups via rsync, I have had an idea how the contrast between the two machines might might be accounted for. Specifically, I noted that, after converting my 150k folder into a git-annex repo, ascertaining that the back-up is current via rsync would take ~15 minutes, where it used to take mere seconds before. This could then only be due to the demands on directory traversal introduced by the annex-layout.
+
+Accordingly, I wanted to see whether the traversal would be something that explains the difference in performance between btrfs and ext4, so I ran a tiny benchmark, traversing the .git folder on my home drive (ext4, SATA) and the backup drive (btrfs, USB3), and I was astounded by the difference:
+
+zardoz [ /mnt/bak/m-annex ]$ time tree .git >/dev/null
+
+tree .git >/dev/null  14,23s user 2,78s system 24% cpu 1:09,69 total
+
+zardoz [ ~/m-annex ]$ time tree .git >/dev/null
+
+tree .git >/dev/null  26,40s user 0,96s system 1% cpu 23:37,94 total
+
+While running, I peeked into the io using iotop, and observed around 500K/s during traversal on ext4 vs. 5M/s on btrfs.
+
+While I was aquainted with the dogma that file-systems hate to have a single folder with a bazillion files, sources on the net seem to indicate that having lots and lots of sparse folders is even worse, and given the one-file-per-folder structure of the annex objects store, this would then potentially explain the heavy thrashing on ext4.
+
+Something I am wondering now: Which operations in git-annex (or plain git) incite that sort of directory traversal? One candidate which occurred to me is «git annex unused», and the differences in performance between ext4 and btrfs are on the same order as in the above benchmark. Originally, Joey related somewhere that the search in «unused» is expensive; but if traversal is involved, it could actually be that this has even more impact than searching git history.
+
+In any case, if anyone wants to track a very large number of files via git-annex, ext4 seems to be not the ideal file-system for this.
diff --git a/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_1_068a8f120d188b8fa5d3e5b687fd02dc._comment b/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_1_068a8f120d188b8fa5d3e5b687fd02dc._comment
new file mode 100644
index 0000000000..0a368b3a31
--- /dev/null
+++ b/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_1_068a8f120d188b8fa5d3e5b687fd02dc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-14T18:33:25Z"
+ content="""
+I'm afraid that you're comparing apples (SATA drives) and oranges (USB drives).
+"""]]
diff --git a/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_2_cc0f5be21fd1523bdddc7bcf6ff04435._comment b/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_2_cc0f5be21fd1523bdddc7bcf6ff04435._comment
new file mode 100644
index 0000000000..e47565d676
--- /dev/null
+++ b/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_2_cc0f5be21fd1523bdddc7bcf6ff04435._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.49.247.112"
+ subject="comment 2"
+ date="2014-07-14T19:34:31Z"
+ content="""
+I suppose you misread something. Note that the 60s traversal was on the (slower) /external/ drive, and the 24minute traversal on the (faster) internal one, so if anything, the results become more pronounced because of the comparison.
+
+In the meantime I converted the internal drive to btrfs, and the traversal time on SATA is now 30s, as opposed to the >20min on ext.
+"""]]
diff --git a/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_3_1133795276371c86cdd52b25a8b20c52._comment b/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_3_1133795276371c86cdd52b25a8b20c52._comment
new file mode 100644
index 0000000000..6b875932d0
--- /dev/null
+++ b/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_3_1133795276371c86cdd52b25a8b20c52._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="134.147.14.84"
+ subject="comment 3"
+ date="2014-07-15T07:29:37Z"
+ content="""
+The ext-community seems to
+[corroborate](http://www.redhat.com/archives/ext3-users/2013-March/msg00007.html)
+the observation that having many sparse directories scales extremely
+poorly, though this still leaves me curious as to how btrfs deals
+with.
+
+One thing I read is that btrfs stores a secondary index on directories
+and uses this index in the readdir() syscall; this secondary index
+works in such a way that inodes are likely to be traversed in
+sequential on-disk order, while for ext, the readdir() results will be
+ordered by inode number, yielding a random access pattern.
+
+I must confess I’ve always liked to think of the file-system as a
+cheap data-base, but apparently that is not such a good idea (i. e.,
+it’s not cheap at all, in the long run). On the other hand (supposing
+that operations like «git annex unused» do indeed work by traversing
+the object tree), it probably wouldn’t be easy coming up with a scheme
+that scales better. For traversal-bound operations, one might maintain
+a database, but it would be a hassle to ensure that this in always in
+sync with the file-system.
+
+"""]]
diff --git a/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_4_4e44289e6913797844e103f9cdf4c5a2._comment b/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_4_4e44289e6913797844e103f9cdf4c5a2._comment
new file mode 100644
index 0000000000..ea0b82f715
--- /dev/null
+++ b/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_4_4e44289e6913797844e103f9cdf4c5a2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 4"
+ date="2014-07-21T17:19:42Z"
+ content="""
+<https://microca.st/clacke/note/kKMqYM4DQtOPzMe065oHiA> suggests using -I 512 -O inline_data (\"bignode\")
+"""]]
diff --git a/doc/forum/Performance_of_V6__44___V7__44___V8_repos.mdwn b/doc/forum/Performance_of_V6__44___V7__44___V8_repos.mdwn
new file mode 100644
index 0000000000..0566f53f42
--- /dev/null
+++ b/doc/forum/Performance_of_V6__44___V7__44___V8_repos.mdwn
@@ -0,0 +1,8 @@
+Hey folks (and Joey), I am trying to understand the performance impact of changes in v6 -> v7 -> v8 mode. Apologies since I haven't kept up with the changes (was using older version for quite a bit) and some of these might already be well documented/known.
+
+Essentially, back in v6 and earlier, I was pretty happy with the design idea the git annex doesn't use smudge/clean filters since their performance is far from ideal. However, I see that in newer versions of repos, this has become more of a thing. I have read a few docs (https://git-annex.branchable.com/todo/git_smudge_clean_interface_suboptiomal/, https://git-annex.branchable.com/todo/only_pass_unlocked_files_through_the_clean__47__smudge_filter/) but there's still a few thing I don't understand.
+
+1) Are smudge/clean filter used all the time now? Does this mean that we are taking a performance hit compared to older git annex versions?
+2) Can someone explain when smudge/clean filters get used? Is it only in repos that use unlock/adjust? I don't use either of them, and would love to know if these are being used unnecessarily.
+
+Thanks in advance!
diff --git a/doc/forum/Performance_of_V6__44___V7__44___V8_repos/comment_1_981279bae881a07185707c29e6c58b28._comment b/doc/forum/Performance_of_V6__44___V7__44___V8_repos/comment_1_981279bae881a07185707c29e6c58b28._comment
new file mode 100644
index 0000000000..3fbfccae9e
--- /dev/null
+++ b/doc/forum/Performance_of_V6__44___V7__44___V8_repos/comment_1_981279bae881a07185707c29e6c58b28._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-21T18:50:00Z"
+ content="""
+There is no change at all for performance when annexed files are symlinks.
+
+If the annexed file is unlocked, it will use smudge/clean filters.
+
+If you have non-annexed files in the git repo, git will also run those
+through the smudge/clean filters.
+
+git calls the clean filter when it sees a file has been modified.
+Things like git status and git add. It caches the result until the file is
+modified again. The smudge filter is only called when git is checking out
+a file (git checkout or a change from a git pull etc).
+"""]]
diff --git a/doc/forum/Performance_of_V6__44___V7__44___V8_repos/comment_2_01e6d32c85524a23399a33b5fb12ec06._comment b/doc/forum/Performance_of_V6__44___V7__44___V8_repos/comment_2_01e6d32c85524a23399a33b5fb12ec06._comment
new file mode 100644
index 0000000000..8c5c668d22
--- /dev/null
+++ b/doc/forum/Performance_of_V6__44___V7__44___V8_repos/comment_2_01e6d32c85524a23399a33b5fb12ec06._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="codelix"
+ avatar="http://cdn.libravatar.org/avatar/667ff4d0387694f28236639bab0faf2c"
+ subject="comment 2"
+ date="2020-05-21T19:17:55Z"
+ content="""
+Thanks for the super quick response Joey.
+
+That then sounds like `git add` and `git annex add` do get a performance impact (since they run smudge/clean which is not mandatory, or is no-op) even if I don't use unlock or adjust. Is that right? Is there a repo setting that will make it not use them?
+
+My understanding is that git pre/post commit hooks are the ones that are useful for standard symlink approach and dont need smudge/clean at all. Please correct me if I am wrong.
+
+Also, just want to say I appreciate all the effort that you do for this. I have tons of data managed with this and should probably write up that story of how I manage my files.
+"""]]
diff --git a/doc/forum/Performance_of_V6__44___V7__44___V8_repos/comment_3_71e8d6ed7b1a6088cdb5abb5667ee619._comment b/doc/forum/Performance_of_V6__44___V7__44___V8_repos/comment_3_71e8d6ed7b1a6088cdb5abb5667ee619._comment
new file mode 100644
index 0000000000..ee3c35d418
--- /dev/null
+++ b/doc/forum/Performance_of_V6__44___V7__44___V8_repos/comment_3_71e8d6ed7b1a6088cdb5abb5667ee619._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-05-21T19:27:40Z"
+ content="""
+`git annex add` does not result in the smudge filter being run.
+
+You could configure git not to run the filters ever (see git docs) but then
+git-annex features involving unlocked files will of course break.
+
+Could I suggest that, in general, you wait until you have actually
+seen git-annex behave badly before worrying about it? (This is in the
+context of also having seen some other comments you made elsewhere.)
+That also lets you file concrete bug reports, rather than posting worries
+that may be ungrounded.
+"""]]
diff --git a/doc/forum/Permission_denied_-_what_is_wrong__63__.mdwn b/doc/forum/Permission_denied_-_what_is_wrong__63__.mdwn
new file mode 100644
index 0000000000..689ec7a0de
--- /dev/null
+++ b/doc/forum/Permission_denied_-_what_is_wrong__63__.mdwn
@@ -0,0 +1,28 @@
+I just set up one local repo and one remote server repo (accessible via SSH) that are synced with each other. However, when I add a file to the local repo it never appears on the remote repo. From the log:
+
+***************************************************************************
+    (scanning...) [2016-01-18 14:55:26.566983] Watcher: Performing startup scan
+    [2016-01-18 14:55:26.584387] Committer: Committing changes to git
+    (recording state in git...)
+    (started...) 
+    Permission denied, please try again.
+    Permission denied, please try again.
+    Permission denied (publickey,password,keyboard-interactive).
+    rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+    rsync error: unexplained error (code 255) at /SourceCache/rsync/rsync-45/rsync/io.c(453) [sender=2.6.9]
+    
+      rsync failed -- run git annex again to resume file transfer
+    [2016-01-18 14:55:30.429824] main: Syncing with lacieannex 
+    
+    Permission denied, please try again.
+    Permission denied, please try again.
+    Permission denied (publickey,password,keyboard-interactive).
+    rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+    rsync error: error in rsync protocol data stream
+      rsync failed -- run git annex again to resume file transfer
+     (code 12) at /SourceCache/rsync/rsync-45/rsync/io.c(453) [sender=2.6.9]
+***************************************************************************
+
+I suspect there is something with the ssh authentication. I tried to remove all keys from my known_hosts that was related to the server (a handful since I had accessed it at server.local, server.lan, 192.168.1.3, fqdn:2222 etc). My plan was to re-run the setup screen where you enter the details about the remote server, including your username and password, but that step seems unavailable after the initial setup.
+
+How do I fix the issues above?
diff --git a/doc/forum/Permission_denied_-_what_is_wrong__63__/comment_1_b850a32cce4c9782e59fc91076b6cae7._comment b/doc/forum/Permission_denied_-_what_is_wrong__63__/comment_1_b850a32cce4c9782e59fc91076b6cae7._comment
new file mode 100644
index 0000000000..91a09860cd
--- /dev/null
+++ b/doc/forum/Permission_denied_-_what_is_wrong__63__/comment_1_b850a32cce4c9782e59fc91076b6cae7._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-19T20:26:57Z"
+ content="""
+The remote server is rejecting your ssh key to log into it.
+
+If you used the web app to set this up, it will have generated a ssh key
+just for this server, and put it in `~/.ssh/git-annex/` on the client.
+
+You need to check your `~/.ssh/authorized_keys` file on the server
+and make sure that the ssh key is listed in it. Checking the server's
+ssh log file may also help track down why it's rejecting the login.
+"""]]
diff --git a/doc/forum/Permission_denied_-_what_is_wrong__63__/comment_2_e8d2170e5f830d0f98bc8251caf8bc5e._comment b/doc/forum/Permission_denied_-_what_is_wrong__63__/comment_2_e8d2170e5f830d0f98bc8251caf8bc5e._comment
new file mode 100644
index 0000000000..766b3dbf02
--- /dev/null
+++ b/doc/forum/Permission_denied_-_what_is_wrong__63__/comment_2_e8d2170e5f830d0f98bc8251caf8bc5e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="db"
+ subject="comment 2"
+ date="2016-01-23T23:06:03Z"
+ content="""
+In fact, I have 2x2 keys on my local machine
+
+key.git-annex-fqdn-db_2222_db.2Fannex
+key.git-annex-fqdn-db_2222_db.2Fannex.pub
+key.git-annex-fqdn-db_22_annex
+key.git-annex-fqdn-db_22_annex.pub
+
+Why duplicates? The \"public 2222\" key is in my  ~/.ssh/authorized_keys but not the \"public 22\"-key.
+"""]]
diff --git a/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__.mdwn b/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__.mdwn
new file mode 100644
index 0000000000..caa9fc85a3
--- /dev/null
+++ b/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__.mdwn
@@ -0,0 +1,36 @@
+Hello,
+
+I've a strange (for me ;-)) problem.
+<br>I'm trying to use git-annex with 2 debian wheezy (packages from backports)
+<br>I've put my ssh pub key on the server in the autorized_keys for my username account (and for the root account to be sure)
+my username account is member of the sudo group (not sure it's required)
+
+I can create an ssh session directly to the server with :
+
+    ssh username@remoteserver.lan -p 62322
+
+and work inside this session.
+
+    Sep 14 03:42:35 file sshd[8849]: Accepted publickey for username from 80.201.25.4 port 32969 ssh2
+    Sep 14 03:42:35 file sshd[8849]: pam_unix(sshd:session): session opened for user username by (uid=0)
+    ...
+    Sep 14 05:13:14 file sshd[8851]: Received disconnect from 80.201.25.4: 11: disconnected by user
+    Sep 14 05:13:14 file sshd[8849]: pam_unix(sshd:session): session closed for user username
+
+But when I use the git-annex assistant on the same workstation with the same remote server and port,
+<br>the 1st step is OK,
+<br>but when I've to choose between git or rsync encrypted, I'm choosing git and receive :
+
+    "Permission denied (publickey)."
+
+On the server I can only see that the ssh session is immediately closed after opened and before the choice git or rsync is made.
+
+    Sep 14 05:13:42 file sshd[8882]: Accepted publickey for username from 80.201.25.4 port 32984 ssh2
+    Sep 14 05:13:42 file sshd[8882]: pam_unix(sshd:session): session opened for user username by (uid=0)
+    Sep 14 05:13:42 file sshd[8886]: Received disconnect from 80.201.25.4: 11: disconnected by user
+    Sep 14 05:13:42 file sshd[8882]: pam_unix(sshd:session): session closed for user username
+
+Do you think it's the problem ? or whatelse ...
+<br>and could you guide me to a possible solution ?
+
+Best regards
diff --git a/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_1_6c74f0b43c457fe97b2d8630ca4fde29._comment b/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_1_6c74f0b43c457fe97b2d8630ca4fde29._comment
new file mode 100644
index 0000000000..8d22157726
--- /dev/null
+++ b/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_1_6c74f0b43c457fe97b2d8630ca4fde29._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2013-11-08T18:24:27Z"
+ content="""
+The webapp sets up a dedicated ssh public key when you add a ssh repository in there.
+
+You might see some useful debugging info your your problem in ~/annex/.git/annex/daemon.log
+"""]]
diff --git a/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_2_b7a384e853e1756a684774348fad29e6._comment b/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_2_b7a384e853e1756a684774348fad29e6._comment
new file mode 100644
index 0000000000..ecf26daa10
--- /dev/null
+++ b/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_2_b7a384e853e1756a684774348fad29e6._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="Auroch"
+ ip="87.65.174.80"
+ subject="OK,thanx for this"
+ date="2013-11-09T09:10:42Z"
+ content="""
+The problem is not solve, but with your informations, I think i've found somehting.
+
+Is it possible that the problem is linked to my situation of port-forwarding ?
+The remoteserver is a host (proxmox) with iptable port forwarding 62322 to the real port 22 of the VM hosting the git where I try to connect.
+
+So could the problem seems to be that some actions are taken on the host and not the VM ... correct ?
+
+    [2013-11-09 09:51:33 CET] read: ssh-keygen [\"-F\",\"bla.remote.tld\"]
+    [2013-11-09 09:51:33 CET] read: ssh [\"-oNumberOfPasswordPrompts=0\",\"-n\",\"-p\",\"62322\",\"user@bla.remote.tld\",\"sh -c 'echo git-annex-probe loggedin;if which git-annex-shell; then echo git-annex-probe git-annex-shell; fi;if which rsync; then echo git-annex-probe rsync; fi;if which ~/.ssh/git-annex-shell; then echo git-annex-probe ~/.ssh/git-annex-shell; fi'\"]
+    [2013-11-09 09:51:35 CET] chat: ssh [\"user@bla.remote.tld\",\"sh -c 'mkdir -p '\\"'\\"'annex'\\"'\\"'&&cd '\\"'\\"'annex'\\"'\\"'&&if [ ! -d .git ]; then git init --bare --shared; fi&&git annex init'\"]
+
+If it's correct, have you an idea for solving this ?
+
+best regards
+
+"""]]
diff --git a/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_3_3a8a7f51cb04a92c576549d379b57248._comment b/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_3_3a8a7f51cb04a92c576549d379b57248._comment
new file mode 100644
index 0000000000..546f647edb
--- /dev/null
+++ b/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_3_3a8a7f51cb04a92c576549d379b57248._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 3"
+ date="2013-11-09T18:07:56Z"
+ content="""
+Well, it does look like your git-annex did not pass the port to the second command. 
+
+What version are you using? I've just tested with a ssh server only listening on 2222 and it used the port throughout.
+
+You might try upgrading to a recent version. I know that version 4.20130627, at least, had a bug with the ssh port.
+"""]]
diff --git a/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_4_582ad3ba0c62a77b08a10b37a780c670._comment b/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_4_582ad3ba0c62a77b08a10b37a780c670._comment
new file mode 100644
index 0000000000..c8d8c8b520
--- /dev/null
+++ b/doc/forum/Permission_denied___40__publickey__41___On_second_Step_...___63__/comment_4_582ad3ba0c62a77b08a10b37a780c670._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Auroch"
+ ip="87.65.174.80"
+ subject="comment 4"
+ date="2013-11-09T19:24:54Z"
+ content="""
+I've the wheezy-backports version
+
+    i   4.20131002~bpo70+1                                                        wheezy-backports                                      100
+
+I'll have to wait an update and I'll come back to you.
+
+Thanx this amazing work !
+
+"""]]
diff --git a/doc/forum/Permissions_error_with_ssh_key_authentication_to_remote.mdwn b/doc/forum/Permissions_error_with_ssh_key_authentication_to_remote.mdwn
new file mode 100644
index 0000000000..d0742910fa
--- /dev/null
+++ b/doc/forum/Permissions_error_with_ssh_key_authentication_to_remote.mdwn
@@ -0,0 +1,24 @@
+I am using git-annex to set up a file distribution system with git commands as the interface. I have configured a unix user account with .ssh key so that calls to the git remote are authenticated automatically. I have set the ownership and permissions for that user account. I can ssh into the remote with that account no problem. But when I run `git annex get` to retrieve the source data from the annex, I get a typical permissions error. I have tried `chown'ing` and `chmod'ing` many combinations, but always get the same error. 
+Looking for help to diagnose and fix this issue.  Let me know if there are other commands I can run to hone in.  
+
+
+    > git ls-remote
+    Warning: No xauth data; using fake authentication data for X11 forwarding.
+    From username@distro.myserver.edu:/path/to/remote/repo/.git
+    f4d9c5e4735f4c6b057d0c43090c80c09b7ab9ae        HEAD
+    49b3b4c81c3ce78443bb00c594cce51a4fa2c034        refs/heads/git-annex
+    f4d9c5e4735f4c6b057d0c43090c80c09b7ab9ae        refs/heads/master
+    
+    > git remote -v
+    origin  username@distro.myserver.edu:/path/to/remote/repo/.git (fetch)
+    origin  username@distro.myserver.edu:/path/to/remote/repo/.git (push)
+    
+    > git annex get sub-STJ82860572941V0120181112132504070/dwi/sub-STJ82860572941V0120181112132504070_dwi__dup-10.nii.gz
+    get sub-STJ82860572941V0120181112132504070/dwi/sub-STJ82860572941V0120181112132504070_dwi__dup-10.nii.gz (not available) 
+      Try making some of these repositories available:
+            fcfe03d6-3638-4ae2-baca-67c4c28e74bb -- username@myserver:/path/to/remote/annex
+    failed
+    git-annex: get: 1 failed
+
+
+Cross post: https://stackoverflow.com/questions/53418582/permissions-error-with-ssh-key-authentication-to-remote-git-annex-get-file
diff --git a/doc/forum/Permissions_error_with_ssh_key_authentication_to_remote/comment_1_39a096f92f0280db9502397b9fc55541._comment b/doc/forum/Permissions_error_with_ssh_key_authentication_to_remote/comment_1_39a096f92f0280db9502397b9fc55541._comment
new file mode 100644
index 0000000000..945375bf91
--- /dev/null
+++ b/doc/forum/Permissions_error_with_ssh_key_authentication_to_remote/comment_1_39a096f92f0280db9502397b9fc55541._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-04T17:16:41Z"
+ content="""
+That does not look like a permissions error, I mean it could be one, but
+all you show is git-annex not being able to access the repository, which
+could be any kind of configuration problem.
+"""]]
diff --git a/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available.mdwn b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available.mdwn
new file mode 100644
index 0000000000..f36602af75
--- /dev/null
+++ b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available.mdwn
@@ -0,0 +1 @@
+I try to use git-annex to manage my photographs. With most cameras, I do shoot raw+jpeg, but sometimes or from some sources there are only jpegs. Is there a possibility to automatically detect the raw+jpeg pairs (same basename, in the same directory, matching raw+jpeg extensions, would be the rule) and drop these jpegs from my notebooks repository, but keep the jpegs that do not have a complementing raw?
diff --git a/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_1_3f365138be319ac2c81bdefb3f59b0d8._comment b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_1_3f365138be319ac2c81bdefb3f59b0d8._comment
new file mode 100644
index 0000000000..fbf1447e0d
--- /dev/null
+++ b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_1_3f365138be319ac2c81bdefb3f59b0d8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2018-10-15T07:33:40Z"
+ content="""
+This sounds like it could be built around my own suggestion of [[todo/Bidirectional_metadata]].
+
+There, Joey mentions that the datalad project uses a special remote. Perhaps one could be made where it does the JPG/NEF mapping and reports the JPG as available if the NEF is, allowing the NEF to count as a copy.
+
+I wouldn't personally do this unless the JPG can be reliably reproduced from the NEF *exactly* though!
+"""]]
diff --git a/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_2_0186f593ec084e12216ad2f7da49474e._comment b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_2_0186f593ec084e12216ad2f7da49474e._comment
new file mode 100644
index 0000000000..ca2072a856
--- /dev/null
+++ b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_2_0186f593ec084e12216ad2f7da49474e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Chris"
+ avatar="http://cdn.libravatar.org/avatar/02b67b7ebace8cb6433504ba9a17d4a4"
+ subject="comment 2"
+ date="2018-10-15T09:07:44Z"
+ content="""
+Thanks for the idea. The reason I want to get rid of the jpegs is not that I see them as derivatives of the raw (for my most recent camera they are since it can reprocess the raws), but that I consider them less important. On my notebook computer I do not have enough space to keep all the files anymore. Therefore I want to get rid of the less important ones, which means that later I want to also remove the raws with less than 2 stars rating, and the movie clips I do not work on currently. On the external hard disk, all the files are present anytime. The backup is separate, the git-annex setup is just for extending my notebooks hard disk drive since industry fails for years to come up with 2.5\" drives larger than 2 TB in 9.5 mm height. So I think what you are describing is another use case. Automatically recognizing raw+jpeg pairs would just be partial automation of my workflow. Or did I miss something?
+"""]]
diff --git a/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_4_0bc307a3fbe000059b23cf681d125ce6._comment b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_4_0bc307a3fbe000059b23cf681d125ce6._comment
new file mode 100644
index 0000000000..1df21259ff
--- /dev/null
+++ b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_4_0bc307a3fbe000059b23cf681d125ce6._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 4"
+ date="2018-10-15T12:59:49Z"
+ content="""
+Hm.. if you want to just drop the JPGs which have known RAW versions, you can set some metadata to say it has a RAW version (again, I'd just set it to the key of the RAW as it makes it easier to get/find later) and then drop JPGs which have that field set.
+
+    git annex metadata -s derived_from_raw=SHA256E-s[...].RAW DCIM_0001.JPG
+    git annex drop --metadata 'derived_from_raw=*' --include '*.JPG'
+
+Need to check the `--metadata` matching filter works as intended there..
+
+Given your criteria is only \"file in the current directory with the same name, but different extension\", you could script the population of that metadata field.
+
+This will drop the JPGs where you've indicated it has a RAW even if that RAW isn't present though. I'm not entirely sure what behavior you want..
+"""]]
diff --git a/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_4_0dc16ef1d592be0dfeb63c28014a70b2._comment b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_4_0dc16ef1d592be0dfeb63c28014a70b2._comment
new file mode 100644
index 0000000000..83b912118e
--- /dev/null
+++ b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_4_0dc16ef1d592be0dfeb63c28014a70b2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Chris"
+ avatar="http://cdn.libravatar.org/avatar/02b67b7ebace8cb6433504ba9a17d4a4"
+ subject="comment 4"
+ date="2018-10-15T21:43:03Z"
+ content="""
+I was hoping that there is a possibility that git-annex recognizes the files I do not want on my notebook based on the rule I described and drops them as soon as their copy arrived at the USB disk automatically (e.g. with the next sync command), and never pulls them back unless explicitly stated (especially, `sync --content` should not transfer them back). What you are describing is basically a manual tagging and dropping of the images. Of course I could write a script to drop the jpegs, but this would be very slow for 100000 images, and I was hoping for some more automated way from within git-annex.
+"""]]
diff --git a/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_5_9eb36b5b43b77de790f99ae1d764e4ea._comment b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_5_9eb36b5b43b77de790f99ae1d764e4ea._comment
new file mode 100644
index 0000000000..0f168d1308
--- /dev/null
+++ b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_5_9eb36b5b43b77de790f99ae1d764e4ea._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 5"
+ date="2018-10-15T22:23:06Z"
+ content="""
+You could set the preferred content to not include files with that metadata, so they would be dropped by `git annex drop --auto` and not brought back by `git annex sync`.
+
+git-annex still has to handle all those files and information related to them, manually or not, so it'll be just as slow. Not that 100K files is a lot to me anymore :P (my largest annex is in the 10s of millions..).
+"""]]
diff --git a/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_6_a34d404dbecd6730c1cc28af9c0eac26._comment b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_6_a34d404dbecd6730c1cc28af9c0eac26._comment
new file mode 100644
index 0000000000..7a9e698bf2
--- /dev/null
+++ b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_6_a34d404dbecd6730c1cc28af9c0eac26._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Chris"
+ avatar="http://cdn.libravatar.org/avatar/02b67b7ebace8cb6433504ba9a17d4a4"
+ subject="comment 6"
+ date="2018-10-16T11:07:30Z"
+ content="""
+That means I update the metadata periodically by a script such as
+
+    for k in `find . -name \"*.CR2\"`; do
+        if [ -e `dirname $k`/`basename $k .CR2`.JPG ]; then
+            <set metadata>
+        fi
+    done
+
+and add a corresponding preferred content setting? I'll try that. Btw, is there a possibility to use the xmp files of my raw converter (darktable) as source for metadata? I want to do the same with images that have a low star rating (<1 star should not be synchronized to the notebook computer and dropped from there as soon as they are on the external disk), and I hope there is a possibility to not double this metadata but directly use the xmp output. The xmp files are checked into the git regularly (without git annex).
+"""]]
diff --git a/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_7_88b04371b3906f01c7b33d110838dc71._comment b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_7_88b04371b3906f01c7b33d110838dc71._comment
new file mode 100644
index 0000000000..76f8556347
--- /dev/null
+++ b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_7_88b04371b3906f01c7b33d110838dc71._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 7"
+ date="2018-10-16T12:57:55Z"
+ content="""
+git-annex doesn't \"use\" the content of files for anything, except at specific points like deriving the key. You can make it automatically copy metadata from a file into git-annex when added (see [[tips/automatically_adding_metadata]]) but it won't keep them in sync, as far as I know. Personally, I strip metadata from the images entirely and put everything into git-annex's metadata.
+
+I would just make a script which has the behavior you want and run it when disk space is a concern  or put it in cron (gets a list of 1-star or JPGs with RAWs, passes it to `git annex drop --batch`).
+
+Otherwise, creating a special remotes that will return `CHECKPRESENT-SUCCESS` for keys you want to drop, so you can set the preferred content to only want files that are \"not present\" in that special remote might work?
+"""]]
diff --git a/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_8_b3e9100b92aaed66b22c76141f7c08d5._comment b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_8_b3e9100b92aaed66b22c76141f7c08d5._comment
new file mode 100644
index 0000000000..642ea6adf7
--- /dev/null
+++ b/doc/forum/Photos__44___raw_and_jpeg__58___drop_jpeg_if_raw_is_available/comment_8_b3e9100b92aaed66b22c76141f7c08d5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Chris"
+ avatar="http://cdn.libravatar.org/avatar/02b67b7ebace8cb6433504ba9a17d4a4"
+ subject="comment 8"
+ date="2018-10-16T15:15:17Z"
+ content="""
+Hm, the raw converter reads and writes metadata from the “sidecar” xmp files, so it would not work to have it only in git-annex. Therefore, a full sync would be required, but luckily this is one-directional, so it should be possible. I think that's the way to go for me.
+
+Thanks for your effort helping me with my stupid questions :).
+
+And disk space is my main concern here, as mentioned above. I really need solutions since I did not know where to put new images, which unfortunately coincided with the birth of my 2nd child and I caught myself taking less photographs of her because I did not know where to put them (and having them accessible from the photo management/raw converter). Therefore, I decided to finally seriously try git-annex which I watch almost from the beginning of the project.
+
+Thanks again :)
+"""]]
diff --git a/doc/forum/Plans_on_tunable_to_remove_sha-inside-sha_single-file-dirs.mdwn b/doc/forum/Plans_on_tunable_to_remove_sha-inside-sha_single-file-dirs.mdwn
new file mode 100644
index 0000000000..df9226fcb1
--- /dev/null
+++ b/doc/forum/Plans_on_tunable_to_remove_sha-inside-sha_single-file-dirs.mdwn
@@ -0,0 +1,20 @@
+I still don't like repeated name inside each symlink.
+
+I enabled every tunable I found to make it sane for me: ./git/annex/objects/xxx/SHA256-.../SHA256-...
+I expect to have no more than 1.000.000 files which I care about even if I live till 100 years, which nicely fit into performance window of filesystem of 4096 folders with 5000 files each.
+I don't care about readonly files -- I have BTRFS snapshots and weekly backups for the case of unintentional disaster and corruption of some files till SHA don't match anymore.
+I don't care about nice distributed lock-free mechanics of git annex -- I always commit each new annex file as separate commit and don't mess with scripting git write operations in my repo.
+What I care is symlinks length -- to fit into my screen width in terminal file manager, repo performance and underlying git repo size -- all of which are dependent on the length of path till the real file.
+
+What I found reading git-annex forum/todo/bugs and datalad issues for two month -- all are old discussions, ideas and maybe obsolete plans.
+I even found somewhere proposal for single-lock model of working for git-annex.
+
+* https://git-annex.branchable.com/design/new_repo_versions/
+* https://github.com/datalad/datalad/issues/32
+
+Yet what I did not found is the status of the idea to add such tunable to git-annex.
+Deadly unsafe tunable to drop nested SHA-SHA folder would totally satisfy me -- and I would immediately go writing scripts to replay whole my git history onto the freshly initialized git-annex with new symlinks.
+Especially if waiting for "more safe" single-lock git-annex w/o SHA-SHA may take years.
+
+So, what is the status of plans?
+Do you have any idea how many years (or month?) left to wait until the idea will brew enough to become vital and git-annex codebase transforms into more suitable state to implement such tunable?
diff --git a/doc/forum/Plans_on_tunable_to_remove_sha-inside-sha_single-file-dirs/comment_1_616f610876e08828e6ad6b89b9e561be._comment b/doc/forum/Plans_on_tunable_to_remove_sha-inside-sha_single-file-dirs/comment_1_616f610876e08828e6ad6b89b9e561be._comment
new file mode 100644
index 0000000000..cef372e1c6
--- /dev/null
+++ b/doc/forum/Plans_on_tunable_to_remove_sha-inside-sha_single-file-dirs/comment_1_616f610876e08828e6ad6b89b9e561be._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="re: shorter symlinks"
+ date="2020-03-03T19:04:03Z"
+ content="""
+Related: [[todo/shorter_keys_through_better_encoding]]
+
+
+"""]]
diff --git a/doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update.mdwn b/doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update.mdwn
new file mode 100644
index 0000000000..37ba9a94f0
--- /dev/null
+++ b/doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update.mdwn
@@ -0,0 +1,74 @@
+Hi, if anyone can suggest some steps to take to diagnose a sudden performance problem in my git-annex repo, I'd appreciate it.
+
+I have been using git annex for several years on this same repo and performance has never been a problem.
+I recently did a OS update of all my packages (arch linux), which updated git annex, and now performance is really bad whenever I run `git status` or `git commit` in the repo (performance is fine in git repos without git annex). For an example of how bad the performance is, I first noticed the problem when trying to make a commit, and I waited 20 minutes before cancelling with Ctrl+C. The update took me from package version "8.20210310-16" to "8.20210803-63". After noticing the problem I updated again to package version "8.20210803-81", since I was hoping there might be a fix in the most recent version, but that didn't resolve it. Those versions might be specific to arch linux, so if that's the case and anybody needs the true versions let me know and I can try to figure out which git-annex commit they are at.
+
+To try to get a sense of what is going on, I started by running `GIT_TRACE_PERFORMANCE=1 git commit`. There seems to be one command that git is running that has a non-trivial time difference between other commands, and its
+
+    18:14:31.968248 trace.c:487             performance: 247.576906378 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)'
+
+The time difference between this command and the next is over 1 second, and it seems that `git commit` is running this type of command many times. I posted a sample of the full output below.
+
+When searching the web for that git command, I came across this conversation: https://git-annex.branchable.com/todo/speed_up_git_annex_sync_--content_--all/
+
+Could that be related to my issue?
+
+What should I do next to figure out what the problem is?
+ 
+I posted the output of `git annex version` and `git annex info` below in case that is helpful.
+
+Thanks!
+
+----------
+
+`git annex version`:
+
+    git-annex version: 8.20210803-g9cae7c5bb
+    build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+    dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-9.0.2 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+    operating system: linux x86_64
+    supported repository versions: 8
+    upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+    local repository version: 8
+
+
+`git annex info` (omitting repository info):
+
+    available local disk space: 146.18 gigabytes (+1 megabyte reserved)
+    local annex keys: 2120
+    local annex size: 2.59 gigabytes
+    annexed files in working tree: 1945
+    size of annexed files in working tree: 2.55 gigabytes
+    bloom filter size: 32 mebibytes (0.4% full)
+    backend usage:
+            SHA256E: 1945
+
+
+sample of the output of `GIT_TRACE_PERFORMANCE=1 git commit`:
+
+    18:14:31.949865 trace.c:487             performance: 0.031945775 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)' --buffer
+    18:14:31.950372 trace.c:487             performance: 0.031692879 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs cat-file '--batch=%(objectname) %(objecttype) %(objectsize)' --buffer
+    18:14:31.963858 trace.c:487             performance: 0.007070777 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs hash-object --stdin-paths --no-filters
+    18:14:31.967006 trace.c:487             performance: 247.578879398 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+    18:14:31.968248 trace.c:487             performance: 247.576906378 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)'
+    18:14:33.217226 trace.c:487             performance: 0.000427304 s: git command: git config --null --list
+    18:14:33.244772 read-cache.c:2398       performance: 0.011644939 s:  read cache .git/index
+    18:14:33.245219 read-cache.c:2398       performance: 0.001136355 s:  read cache .git/index
+    18:14:33.263160 trace.c:487             performance: 0.001024382 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs show-ref --hash refs/annex/last-index
+    18:14:33.274091 read-cache.c:2398       performance: 0.001037856 s:  read cache .git/index
+    18:14:33.284793 unpack-trees.c:1802     performance: 0.000024725 s:    traverse_trees
+    18:14:33.284872 unpack-trees.c:418      performance: 0.000001050 s:    check_updates
+    18:14:33.284917 unpack-trees.c:1892     performance: 0.000349269 s:   unpack_trees
+    18:14:33.289148 diff-lib.c:629          performance: 0.004585392 s:  diff-index
+    18:14:33.289220 trace.c:487             performance: 0.017392572 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs -c filter.annex.smudge= -c filter.annex.clean= -c diff.external= diff d62ecb841c32ff0d62df4f8ca7cb0567616cf415 --staged --raw -z --no-abbrev -G/annex/objects/ --no-renames --ignore-submodules=all --no-ext-diff
+    18:14:33.294517 trace.c:487             performance: 0.025457813 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)' --buffer
+    18:14:33.297215 trace.c:487             performance: 0.024423869 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs cat-file '--batch=%(objectname) %(objecttype) %(objectsize)' --buffer
+    18:14:33.303299 trace.c:487             performance: 0.000746262 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs hash-object --stdin-paths --no-filters
+    18:14:33.305448 trace.c:487             performance: 0.076031969 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+    18:14:33.308580 trace.c:487             performance: 0.075975445 s: git command: git --git-dir=.git --work-tree=. --literal-pathspecs cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)'
+    18:14:34.537129 trace.c:487             performance: 0.000424618 s: git command: git config --null --list
+    18:14:34.570720 read-cache.c:2398       performance: 0.008743858 s:  read cache .git/index
+    18:14:34.573279 read-cache.c:2398       performance: 0.001075431 s:  read cache .git/index
+    
diff --git a/doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update/comment_1_68429f9e44ce24250c608da8ffffe643._comment b/doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update/comment_1_68429f9e44ce24250c608da8ffffe643._comment
new file mode 100644
index 0000000000..fc65820127
--- /dev/null
+++ b/doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update/comment_1_68429f9e44ce24250c608da8ffffe643._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ainohzoa"
+ avatar="http://cdn.libravatar.org/avatar/0d6a2dbd95f6c4f410cc41d32beaebe9"
+ subject="Now it's working normally again"
+ date="2022-01-14T21:10:13Z"
+ content="""
+After running a `git status` today (the first time running it was slow as usual) the problem seems to have gone away. Perhaps it just needed to rebuild some kind of cache or something. I believe that I had waited for a `git status` command to completely finish before, so maybe it takes several tries to resolve this performance problem? Or possibly I'm misremembering and I never actually waited for the `git status` command to fully finish. I'm baffled by this, but happy that it's back to normal. I'll post an update if the problem comes back. 
+"""]]
diff --git a/doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update/comment_2_cefd5742da29e19f5ab3406698a13f9f._comment b/doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update/comment_2_cefd5742da29e19f5ab3406698a13f9f._comment
new file mode 100644
index 0000000000..1f18a3cd72
--- /dev/null
+++ b/doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update/comment_2_cefd5742da29e19f5ab3406698a13f9f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-01-25T16:36:20Z"
+ content="""
+git can sometimes get into a situation where it is unsure about the status
+of working tree files, and when those files are not git-annex symlinks but
+either unlocked git-annex files or regular files checked into git, it needs
+to run `git-annex smudge` once per file. That can take a long time when it
+somehow needs to check many files.
+
+This kind of slowdown is largely avoided by setting:
+
+	git config filter.annex.process 'git-annex filter-process'
+
+Which will be handled automatically by a future upgrade.
+"""]]
diff --git a/doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update/comment_3_ab005dba805922597a533ddd661f20c8._comment b/doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update/comment_3_ab005dba805922597a533ddd661f20c8._comment
new file mode 100644
index 0000000000..5301bfd2b0
--- /dev/null
+++ b/doc/forum/Please_diagnose__58_____96__git_status__96___is_slow_after_update/comment_3_ab005dba805922597a533ddd661f20c8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="I have seen this"
+ date="2022-03-16T16:10:51Z"
+ content="""
+`git-annex sync` has been very slow on one of my repositories the last few times I ran it. An operation that used to run in well less than a minute (via USB 2.0) was now taking upwards of one hour. I do have many files there that are not being tracked by git.
+
+I followed *ainohzoa*'s description to confirm I was seeing the same issue and tried the process that worked for them: running `git status` twice. Although it took a few hours to complete, things went back to normal after that. Thank you, *ainohzoa*.
+"""]]
diff --git a/doc/forum/Please_fix_compatibility_with_ghc_7.0.mdwn b/doc/forum/Please_fix_compatibility_with_ghc_7.0.mdwn
new file mode 100644
index 0000000000..d49081bf34
--- /dev/null
+++ b/doc/forum/Please_fix_compatibility_with_ghc_7.0.mdwn
@@ -0,0 +1 @@
+I'm having trouble installing the latest git-annex. It depends on 'base >= 4.5 && base < 5', but ghc 7.0 only ships base 3.0. I've tried upgrading ghc to 7.4 but that breaks a whole bunch of other things; for example, the Crypto module fails to compile, preventing me from installing ghc. Please fix compatibility with ghc 7.0.
diff --git a/doc/forum/Please_fix_compatibility_with_ghc_7.0/comment_1_d1d10217ebd0151e947b3a6cd37399ce._comment b/doc/forum/Please_fix_compatibility_with_ghc_7.0/comment_1_d1d10217ebd0151e947b3a6cd37399ce._comment
new file mode 100644
index 0000000000..04b8ce6750
--- /dev/null
+++ b/doc/forum/Please_fix_compatibility_with_ghc_7.0/comment_1_d1d10217ebd0151e947b3a6cd37399ce._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-03-11T15:50:11Z"
+ content="""
+There is a `ghc7.0` branch in [[git|download]] that is being maintained to work with that version.
+"""]]
diff --git a/doc/forum/Please_help__44___half_my_files_disappeared.mdwn b/doc/forum/Please_help__44___half_my_files_disappeared.mdwn
new file mode 100644
index 0000000000..b8a1a0186b
--- /dev/null
+++ b/doc/forum/Please_help__44___half_my_files_disappeared.mdwn
@@ -0,0 +1,14 @@
+Hello, I was writing a message to ask for help but I found a solution for my problem so I deleted it but now I think it could be useful to someone else so hereafter is my initial message and my workaround.
+
+
+> Hello, this time I am very very frightened by the odds but I am still looking for your help. Long story short: windows update.
+
+> Yesterday, everything was fine with my local git-annex using WSL. This morning, windows had updated itself to version 1803 automatically, (by the way, thanks to Microsoft for their forced updates), and half my locked files are gone. I tried git annex fix ., nothing, I tried to find the associated keys with find .git/annex/objects -name 'sha...', nothing. git annex whereis <file> says the file is here whereas git annex fsck <file> fails telling the file's content is missing.
+
+> Now, it seems like the only remaining files have links pointing to annex/objects directories that are exclusively composed of uppercase letters or numbers. Looking more closely to the objects folders, it seems like they are all strangely duplicated depending on the spelling: for example the variations zZ, Zz, ZZ, zz which all have the same subdirectories and files. Is this the way those directories should be named or did Windows break everything?
+
+> The last thing that keeps me hoping is that the hard drive usage seems to be the same as before but with the apparent duplication of object directories, my hopes are fading away pretty fast... If anyone can help me, or even finish to turn my hopes down, I am listening.
+
+I solved this by using the shiny feature that lets a Windows user revert the OS to previous version once yet another a big flaw has been found in the 1803 version.
+Strangely, after the revert, all my files were back to their normal state, as I left them before the upgrade.
+I hope none of you will need this ;)
diff --git a/doc/forum/Please_help__44___half_my_files_disappeared/comment_1_ba7c79dd7805aa9ec1b90d643f6bf555._comment b/doc/forum/Please_help__44___half_my_files_disappeared/comment_1_ba7c79dd7805aa9ec1b90d643f6bf555._comment
new file mode 100644
index 0000000000..2cf06bda26
--- /dev/null
+++ b/doc/forum/Please_help__44___half_my_files_disappeared/comment_1_ba7c79dd7805aa9ec1b90d643f6bf555._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-09-24T15:14:49Z"
+ content="""
+Glad you recovered ok.
+
+It sounds like windows may be doing something horrible with case
+insensitivity in the file system. It's normal for .git/annex/objects/
+to contain subdirectories with names that only differ by case.
+
+If Windows used to respond to a request for .git/annex/object/XY with
+the contents of that, but now instead responds with the contents of the xy
+directory, it should be possible to rearrange things so git-annex still
+works, but I would not recommend doing it with live data without backups.
+"""]]
diff --git a/doc/forum/Please_help_me_help_my_photographer_friends.mdwn b/doc/forum/Please_help_me_help_my_photographer_friends.mdwn
new file mode 100644
index 0000000000..035819f9bf
--- /dev/null
+++ b/doc/forum/Please_help_me_help_my_photographer_friends.mdwn
@@ -0,0 +1,18 @@
+Hi everyone,
+
+first thanks for the great software and community support. I am a big fan of git-annex for the longest time, even participated the kickstarter back then. Throughout this time, I also have helping a few professional photographers to manage their files. I can very much relate to Joeys original story for the assistant, thus felt the potential for it to be very useful for them.
+
+However, even though I use git-annex personally and even tried a few projects with it, I did not manage to create the solution I envisioned for my friends. The use case is more about managing space, backing up and archiving. I will give more details below, but I am starting to lose hope. I tried a couple of approaches ([gateway][1], [rsync.net][2]) to no avail, but I still have the feeling it should be possible. Therefore, I bring forth my idea to put it out of its misery:
+
+  - The goal is to (a) use the glacier archive feature to get rid of closed projects, freeing up space and (b) to have a “cloud backup” of the worktree. The backup ideally would be something I could ``git clone`` in case of a disaster and still would be able to recover archived files from glacier (by moving it out of “archive” folder).
+
+  - Very importantly restriction, these users have no tech background, thus the whole process must be automated and as error free as possible. On the other hand, it does not need to be online, or even use the assistant at all.  It would be fine to have rules like “takes 24h to recover an archive” (because of ``cron`` or whatever). 
+
+One optional feature is finding a use for the tons of external hard drives they hoarded over the years. The biggest hope here is not to have to rely on cheap hardware to store a lifework as soon as possible. Even though I try to help them to catalog projects and maintain multiple copies, it is inevitable that now and then something fails. I was really hopping git-annex would help here.
+
+Thanks in advance and all the best!
+
+f.
+
+[1]: https://git-annex.branchable.com/forum/Is_it_possible_to_setup_a_git-annex_Glacier_gatway__63__/
+[2]: https://git-annex.branchable.com/forum/using_rsync.net_as_backup_and_glacier_as_archive/
diff --git a/doc/forum/Please_publish_new_releases_not_shorter_than_11_days.mdwn b/doc/forum/Please_publish_new_releases_not_shorter_than_11_days.mdwn
new file mode 100644
index 0000000000..f67d2d797d
--- /dev/null
+++ b/doc/forum/Please_publish_new_releases_not_shorter_than_11_days.mdwn
@@ -0,0 +1,6 @@
+Hi,
+i am following debian testing. The latest git-annex publication has manged to replace the former version on the last possible moment. Now another 10 days waiting.
+Would be nice if you can coordinate with testing.
+
+Thank you for git-annex. 
+Jürgen
diff --git a/doc/forum/Please_publish_new_releases_not_shorter_than_11_days/comment_1_da3d39de5be47ebe8b25a42ed1f36510._comment b/doc/forum/Please_publish_new_releases_not_shorter_than_11_days/comment_1_da3d39de5be47ebe8b25a42ed1f36510._comment
new file mode 100644
index 0000000000..1fb259c98c
--- /dev/null
+++ b/doc/forum/Please_publish_new_releases_not_shorter_than_11_days/comment_1_da3d39de5be47ebe8b25a42ed1f36510._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-03T19:57:24Z"
+ content="""
+I do coordinate with testing. That version had no possibility of ever reaching testing, since it failed to build on several architectures.
+"""]]
diff --git a/doc/forum/Podcast_syncing_use-case.mdwn b/doc/forum/Podcast_syncing_use-case.mdwn
new file mode 100644
index 0000000000..6b3c81cabc
--- /dev/null
+++ b/doc/forum/Podcast_syncing_use-case.mdwn
@@ -0,0 +1,34 @@
+I've been trying to use git-annex with the following strategy.
+
+* Download podcasts into the annex `gpodder-downloads`
+* Check the podcasts into the annex using `git annex add`.
+* Copy the podcasts over to my mp3 player in the annex `usb-ariaz`.
+  This is a FAT-formatted mp3 player, so I have been using a bare
+  repository.  
+* Move the podcasts to a different annex called `gpodder-on-usbdisk`
+  to indicate that they have been successfully put on the mp3 player.
+* `chmod` the files on the mp3 player to `0600` so that I can delete
+  them from the player when I am done listening to them.
+  
+Then I go for a run or something and listen to a bunch of podcasts,
+deleting them after I have listened to them.  When I get back, I would
+like to find the files that I have listened to and remove them from
+the annexes that are not on the mp3 player.  What I have been hoping
+is that something like
+
+    ~/gpodder-on-usbdisk $ git annex find --not --in usb-ariaz --print0 | xargs -0 git rm
+    ~/gpodder-on-usbdisk $ git annex unused
+    ~/gpodder-on-usbdisk $ git annex dropunused `seq X`
+	
+would work.  However, it appears that `git-annex find` does not
+actually check to see that the file contents are present, but only
+looks at the `git-annex` branch of the `usb-ariaz` repository.  Since
+I have not changed that with my sneaky deletions, it has no way of
+knowing that the files have been deleted.
+
+Is there any way to do this properly?  (And by properly, I don't mean
+"don't delete the files".  That is really the only way I have of
+marking that I have listened to podcasts on this particular mp3 player.)
+
+I tried setting the `usb-ariaz` repository to be untrusted, but that
+did not change the behavior of `git annex find`.
diff --git a/doc/forum/Podcast_syncing_use-case/comment_1_ace6f9d3a950348a3ac0ff592b62e786._comment b/doc/forum/Podcast_syncing_use-case/comment_1_ace6f9d3a950348a3ac0ff592b62e786._comment
new file mode 100644
index 0000000000..fe396c39f3
--- /dev/null
+++ b/doc/forum/Podcast_syncing_use-case/comment_1_ace6f9d3a950348a3ac0ff592b62e786._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-11-27T17:56:31Z"
+ content="""
+Right, --in goes by git-annex's [[location_tracking]] information; actually checking if a remote still has the files would make --in too expensive in many cases.
+
+So you need to give `gpodder-on-usbdisk` current information. You can do that by going to `usb-ariaz` and doing a `git annex fsck`. That will find the deleted files and update the location information. Then, back on `gpodder-on-usbdisk`, `git pull usb-ariaz`, and then you can proceed with the commands you showed.
+"""]]
diff --git a/doc/forum/Podcast_syncing_use-case/comment_2_930a6620b4d516e69ed952f9da5371bb._comment b/doc/forum/Podcast_syncing_use-case/comment_2_930a6620b4d516e69ed952f9da5371bb._comment
new file mode 100644
index 0000000000..97eb3c681c
--- /dev/null
+++ b/doc/forum/Podcast_syncing_use-case/comment_2_930a6620b4d516e69ed952f9da5371bb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://cgray.myopenid.com/"
+ nickname="cgray"
+ subject="comment 2"
+ date="2011-11-27T22:10:44Z"
+ content="""
+Thanks, that works perfectly!
+"""]]
diff --git a/doc/forum/Poor_man__39__s_IMAP.mdwn b/doc/forum/Poor_man__39__s_IMAP.mdwn
new file mode 100644
index 0000000000..af53ddc197
--- /dev/null
+++ b/doc/forum/Poor_man__39__s_IMAP.mdwn
@@ -0,0 +1,6 @@
+I have an e-mail server configured to save my mail in ~/Maildir on an account that is available over ssh. I'd like to keep emailserver:~/Maildir in a two-way sync with laptop:~/Mail/private essentially creating a poor man's IMAP — without setting up and maintaining an actual IMAP server. **Is it an appropriate use of git-annex or would another tool be more fitting? And how do I go about doing it?** I'd like to sync the files, the content, not just information about the files or other meta-data. 
+
+I tried setting it up with the webUI to the assistant but it only offers encrypted storage[1] on the remote server. I looked into setting it up manually but "git-annex does not notice when files are added to remote rsync repositories."[2]
+
+[1] http://git-annex.branchable.com/bugs/Remote_repositories_have_to_be_setup_encrypted/  
+[2] from comments on http://git-annex.branchable.com/special_remotes/rsync/
diff --git a/doc/forum/Poor_man__39__s_IMAP/comment_1_258ff23c462dc88b88ced405c4f5040f._comment b/doc/forum/Poor_man__39__s_IMAP/comment_1_258ff23c462dc88b88ced405c4f5040f._comment
new file mode 100644
index 0000000000..8965f18be3
--- /dev/null
+++ b/doc/forum/Poor_man__39__s_IMAP/comment_1_258ff23c462dc88b88ced405c4f5040f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://a-or-b.myopenid.com/"
+ ip="220.244.41.108"
+ subject="comment 1"
+ date="2013-08-14T06:45:56Z"
+ content="""
+I'd say that git-annex is the wrong tool.
+
+OfflineIMAP ([[http://offlineimap.org]]) is simple to set up, is easy to secure over ssh and does exactly what you want.
+
+"""]]
diff --git a/doc/forum/Poor_man__39__s_IMAP/comment_2_c88d1abdda4cb526a6ee45a710c75bc4._comment b/doc/forum/Poor_man__39__s_IMAP/comment_2_c88d1abdda4cb526a6ee45a710c75bc4._comment
new file mode 100644
index 0000000000..4ab7af46ba
--- /dev/null
+++ b/doc/forum/Poor_man__39__s_IMAP/comment_2_c88d1abdda4cb526a6ee45a710c75bc4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://a-or-b.myopenid.com/"
+ ip="220.244.41.108"
+ subject="comment 2"
+ date="2013-08-14T06:53:04Z"
+ content="""
+From my massive amount of googling, i.e. 2min, apparently mbsync ([[http://isync.sourceforge.net/mbsync.html]]) is good too.
+
+I've never used it, so YMMV.
+"""]]
diff --git a/doc/forum/Poor_man__39__s_IMAP/comment_3_3847e371db1c2788c075e7dca1fbd33e._comment b/doc/forum/Poor_man__39__s_IMAP/comment_3_3847e371db1c2788c075e7dca1fbd33e._comment
new file mode 100644
index 0000000000..a8ed314756
--- /dev/null
+++ b/doc/forum/Poor_man__39__s_IMAP/comment_3_3847e371db1c2788c075e7dca1fbd33e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://spindritf.myopenid.com/"
+ nickname="spindritf"
+ subject="comment 3"
+ date="2013-08-14T07:30:30Z"
+ content="""
+Offlineimap connects to an IMAP server and I was hoping to avoid running one. Thanks though. 
+"""]]
diff --git a/doc/forum/Poor_man__39__s_IMAP/comment_4_cf6cc21f2cf2aa5c949844e24a7b4075._comment b/doc/forum/Poor_man__39__s_IMAP/comment_4_cf6cc21f2cf2aa5c949844e24a7b4075._comment
new file mode 100644
index 0000000000..bcb6982164
--- /dev/null
+++ b/doc/forum/Poor_man__39__s_IMAP/comment_4_cf6cc21f2cf2aa5c949844e24a7b4075._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 4"
+ date="2013-08-14T11:11:59Z"
+ content="""
+IMHO It is not the wrong tool for the job, after all the whole point of assistant is to sync folder across machines. I have a similar setup. I have two folders on two machines plus an encrypted repo on an ssh server. On both folders (local/server) i keep webapp running they sync using the encrypted repo/xmpp. The only downside to this approach is that VPS has two copies of every file one in the folder on in the encrypted git repo.
+"""]]
diff --git a/doc/forum/Poor_man__39__s_IMAP/comment_5_d861fa69475ce526841b3195be8ee356._comment b/doc/forum/Poor_man__39__s_IMAP/comment_5_d861fa69475ce526841b3195be8ee356._comment
new file mode 100644
index 0000000000..d5621bb4a9
--- /dev/null
+++ b/doc/forum/Poor_man__39__s_IMAP/comment_5_d861fa69475ce526841b3195be8ee356._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://spindritf.myopenid.com/"
+ nickname="spindritf"
+ subject="comment 5"
+ date="2013-08-14T18:08:22Z"
+ content="""
+> IMHO It is not the wrong tool for the job, after all the whole point of assistant is to sync folder across machines.
+
+That's what I thought. OK, so how do I do it? Should I set up this rsync special remote and run sync every once in a while. When starting the e-mail client for example? 
+"""]]
diff --git a/doc/forum/Poor_man__39__s_IMAP/comment_6_1e81bd4bb62652bc674cdcd7ed57ac5c._comment b/doc/forum/Poor_man__39__s_IMAP/comment_6_1e81bd4bb62652bc674cdcd7ed57ac5c._comment
new file mode 100644
index 0000000000..7e07204561
--- /dev/null
+++ b/doc/forum/Poor_man__39__s_IMAP/comment_6_1e81bd4bb62652bc674cdcd7ed57ac5c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 6"
+ date="2013-08-16T09:14:52Z"
+ content="""
+You can either keep running 2 webapps paired using xmpp running all the time that gives you push like notifications or if you are ok with syncing every once in a while you can have a check mail script that adds files on the server commits them then calls git annex sync locally,
+
+    ssh $1 \"cd /path/to/annex/;git add .;git commit 'Update'\";git annex sync
+
+should do the trick. The latter method you just need to annex repos no encrypted third repo. Just init your git annex repo on the server and clone on the laptop thats it.
+"""]]
diff --git a/doc/forum/Poor_man__39__s_IMAP/comment_7_b3929281dff6078d77f1b9ae42e25bb6._comment b/doc/forum/Poor_man__39__s_IMAP/comment_7_b3929281dff6078d77f1b9ae42e25bb6._comment
new file mode 100644
index 0000000000..aba4cd0de9
--- /dev/null
+++ b/doc/forum/Poor_man__39__s_IMAP/comment_7_b3929281dff6078d77f1b9ae42e25bb6._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 7"
+ date="2013-08-23T18:30:04Z"
+ content="""
+I don't feel that git-annex is the best thing to use for this. Maildir has some specific semantics for the filenames used in it that let imap clients resolve inconsistencies, such as a message that was read on machine A, and deleted on machine B. git-annex is unlikely to work as well.
+
+However, I have to say that the very beginning of this thread has a wrong statement in it. 
+
+> I tried setting it up with the webUI to the assistant but it only offers encrypted storage[1] on the remote server.
+
+If you install git and git-annex on your remote server, the git-annex assistant will detect this, and offer the choice between a regular git repository, and encrypted storage. If you don't have them installed, it tells you you don't, offers to let you retry once you do install them, and offers encrypted storage as the only option that works given what's installed on the server.
+
+(Also, the bug you linked to in [1] has nothing at all to do with what you were talking about.)
+"""]]
diff --git a/doc/forum/Poor_man__39__s_IMAP/comment_8_69506e8c519196f44b9ed15b32f00106._comment b/doc/forum/Poor_man__39__s_IMAP/comment_8_69506e8c519196f44b9ed15b32f00106._comment
new file mode 100644
index 0000000000..18b99a880c
--- /dev/null
+++ b/doc/forum/Poor_man__39__s_IMAP/comment_8_69506e8c519196f44b9ed15b32f00106._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="konubinix"
+ ip="82.243.233.186"
+ subject="And with a lots of mails?"
+ date="2013-08-27T06:44:56Z"
+ content="""
+Hi,
+
+I have a question quite similar, but for a different purpose. I use OfflineImap for imap synchronisation, but in my current situation, I travel a lot between two places: one connected to the Internet and the other not connected.
+
+When I am connected to the Internet, I may synchronize mails, then I rsync my ~/Mail directory to a usb key so that I have access to them in the place without connection. The mails filenames may be changed as Joeyh mentioned while I read or delete them. I rsync them back to the usb key before going back to the place with Internet connection, where the OfflineImap synchronization may occur.
+
+This solution, with rsynced key, works well. But I would love a history of what was done with file names and may be able to retrieve an old mail.
+
+I figured out that that the git annex was a really good solution for that.
+
+The main drawback from my point of view is that I have around 100 000 mails (some would say that's \"[Not much mail](http://notmuchmail.org/)\"), and I am afraid that git will be quite slow with that amount of files.
+
+Did anyone experience an annexed repository with so many items it in?
+
+Best
+"""]]
diff --git a/doc/forum/Portable_version_of_git-annex_for_windows.mdwn b/doc/forum/Portable_version_of_git-annex_for_windows.mdwn
new file mode 100644
index 0000000000..e4c0bb7374
--- /dev/null
+++ b/doc/forum/Portable_version_of_git-annex_for_windows.mdwn
@@ -0,0 +1,22 @@
+Problem: I don't have admin access on all the computers I want to plug my USB with git-annex on.
+Solution: Make git & git-annex portable.
+
+The only catch is I'm not familiar enough with git to be able to actually tell if the more specialized git-annex working properly. The commands execute without crashing so I suspect it's fine but I was hoping someone else more competent could try this out and let me know if I it's working so I can add it to the tips section. Thanks in advance!
+
+Ingredients:
+
+* Portable version of msysgit: <http://code.google.com/p/msysgit/downloads/list>
+
+* Windows git-annex installer: <http://git-annex.branchable.com/install/>
+
+* 7-zip (portable version optional): <http://portableapps.com/apps/utilities/7-zip_portable>
+
+Steps:
+
+1. Use 7-zip to extract the contents of the git-annex installer into their own folder.
+
+2. Extract the portable version of git and copy all files extracted from git-annex installer into the "cmd" folder.
+
+3. Run it!
+
+Edit: the markdown is eating my attempts to create a numbered list and making them a paragraph instead. Apologies!
diff --git a/doc/forum/Portable_version_of_git-annex_for_windows/comment_1_e5e60fa8d104a09152a8164d5a906aec._comment b/doc/forum/Portable_version_of_git-annex_for_windows/comment_1_e5e60fa8d104a09152a8164d5a906aec._comment
new file mode 100644
index 0000000000..2d5b22ee87
--- /dev/null
+++ b/doc/forum/Portable_version_of_git-annex_for_windows/comment_1_e5e60fa8d104a09152a8164d5a906aec._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="rtwolf"
+ ip="69.165.155.234"
+ subject="comment 1"
+ date="2014-01-07T17:38:19Z"
+ content="""
+Seems windows version of git-annex only runs in direct mode so I got the dreaded \"fatal: this operation must be run in a work tree\" error. Ran \"git config core.bare false\" which fixed it.
+
+More info on direct mode: <http://git-annex.branchable.com/direct_mode/>
+"""]]
diff --git a/doc/forum/Portable_version_of_git-annex_for_windows/comment_2_d8d1aa0920351e880ba6678bb97585de._comment b/doc/forum/Portable_version_of_git-annex_for_windows/comment_2_d8d1aa0920351e880ba6678bb97585de._comment
new file mode 100644
index 0000000000..3602e88c6a
--- /dev/null
+++ b/doc/forum/Portable_version_of_git-annex_for_windows/comment_2_d8d1aa0920351e880ba6678bb97585de._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="rtwolf"
+ ip="69.165.155.234"
+ subject="comment 2"
+ date="2014-01-07T17:41:25Z"
+ content="""
+Correction to above. Don't run that command, just use git annex sync instead.
+
+Also, git annex drop gives just a blank line. Maybe it doesn't work in direct mode either?
+"""]]
diff --git a/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote.mdwn b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote.mdwn
new file mode 100644
index 0000000000..21921cd291
--- /dev/null
+++ b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote.mdwn
@@ -0,0 +1,24 @@
+Here is a line from the debug log...
+
+    [2016-09-08 13:08:37.01053] chat: ssh
+      ["-oNumberOfPasswordPrompts=0","-oStrictHostKeyChecking=no",
+       "9553@git-annex-.usw.2Ds009.2Ersync.2Enet-9553_22_annex",
+       "mkdir -p .ssh;touch .ssh/authorized_keys;dd of=.ssh/authorized_keys oflag=append conv=notrunc;mkdir -p annex"]
+
+The hostname I entered was ordinary: `usw-s009.rsync.net`... but as you can see, the `user@host:port` string is mangled.
+
+I'm using git tag `6.20160907` with changes to `git-annex.cabal` and `stack.yaml` to force use of `concurrent-output-1.7.7` since `1.7.6` had a bug that kept it from building on Windows (I guess?).
+
+Oh, this is on Windows, in case that wasn't clear...
+
+I think the bug is in `${git-annex-root}/Assistant/Ssh.hs` or `${git-annex-root}/Assistant/Pairing/MakeRemote.hs`.  The `.2D` and `.2E` bits in the mangled string make me think that the `-` and `.` characters in my hostname are being replaced by some Haskell representation of those values (`2D` in hexadecimal in ASCII is `-`, `2E` is `.`).
+
+But I've never even written hello world in Haskell so my path ends there.
+
+I'm happy to pull some tag or branch from github and run `stack install` over again and try adding the rsync.net remote again.
+
+I hope this helps!
+
+Cheers,
+
+--Dave
diff --git a/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_1_dba203d6c701365685f1a0d4269633a3._comment b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_1_dba203d6c701365685f1a0d4269633a3._comment
new file mode 100644
index 0000000000..129c430862
--- /dev/null
+++ b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_1_dba203d6c701365685f1a0d4269633a3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="dave@2ab82f485adf7e2ce787066e35f5f9789bff430b"
+ nickname="dave"
+ subject="output of git annex version"
+ date="2016-09-08T18:48:43Z"
+ content="""
+    $ git annex version
+    git-annex version: 6.20160907-gad0a7f6
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV ConcurrentOutput TorrentParser Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E
+                        SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: unknown
+    supported repository versions: 5 6
+    upgrade supported from repository versions: 2 3 4 5
+    operating system: mingw32 x86_64
+
+"""]]
diff --git a/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_2_47b14e71ce0dd653a300dabe8ab0ac3a._comment b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_2_47b14e71ce0dd653a300dabe8ab0ac3a._comment
new file mode 100644
index 0000000000..180be858c0
--- /dev/null
+++ b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_2_47b14e71ce0dd653a300dabe8ab0ac3a._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="dave@2ab82f485adf7e2ce787066e35f5f9789bff430b"
+ nickname="dave"
+ subject="Similar issue on Debian machine"
+ date="2016-09-08T20:04:45Z"
+ content="""
+OK, let's try this on a GNU machine (debian, sid) running a git-annex from the official debian repos:
+
+    $ git annex version
+    git-annex version: 6.20160808
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify
+                 XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512
+                        SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
+Now, this time, the error message in the web app says something ordinary: `Permission denied (publickey,password,keyboard-interactive).`.  However, I see this in the log:
+
+    [2016-09-08 14:56:36.125939] read: ssh-keygen [\"-F\",\"usw-s009.rsync.net\"]
+    [2016-09-08 14:56:36.134026] process done ExitSuccess
+    [2016-09-08 14:56:36.1344] chat: ssh [
+        \"-oNumberOfPasswordPrompts=0\",
+        \"9553@git-annex-.usw.2Ds009.2Ersync.2Enet-9553_22_annex\",
+        \"mkdir -p .ssh;touch .ssh/authorized_keys;dd of=.ssh/authorized_keys oflag=append conv=notrunc;mkdir -p annex\"
+    ]
+    [2016-09-08 14:56:36.71948] process done ExitFailure 255
+
+As you can see, that string mangling is present there too.
+"""]]
diff --git a/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_3_753ff00c43be5f9bef6bcb529ad68bb9._comment b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_3_753ff00c43be5f9bef6bcb529ad68bb9._comment
new file mode 100644
index 0000000000..ddb6db24fd
--- /dev/null
+++ b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_3_753ff00c43be5f9bef6bcb529ad68bb9._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-09-21T17:08:41Z"
+ content="""
+That mangling of the hostname is completely normal.
+
+Your problem description lacked a description of an actual problem.
+Is something not working, or were you put off by this ugly looking
+hostname? If something is not working, what is the error message?
+"""]]
diff --git a/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_4_43f04bfbaeb4f04a5980ade59a36ae91._comment b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_4_43f04bfbaeb4f04a5980ade59a36ae91._comment
new file mode 100644
index 0000000000..6b317e8ea3
--- /dev/null
+++ b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_4_43f04bfbaeb4f04a5980ade59a36ae91._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-09-21T17:18:35Z"
+ content="""
+The error message "Permission denied (publickey,password,keyboard-interactive)"
+seems to be saying you entered the wrong password for rsync.net.
+"""]]
diff --git a/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_5_6dd6819103814056d8b71356804be56a._comment b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_5_6dd6819103814056d8b71356804be56a._comment
new file mode 100644
index 0000000000..a27494ca3d
--- /dev/null
+++ b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_5_6dd6819103814056d8b71356804be56a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="dave@2ab82f485adf7e2ce787066e35f5f9789bff430b"
+ nickname="dave"
+ subject="re: mangling is normal"
+ date="2016-09-21T21:12:16Z"
+ content="""
+... ok, here's the original message from the (web) UI:
+
+    ssh: Could not resolve hostname git-annex-.usw.2ds009.2ersync.2enet-9553_22_annex: Name or service not known
+
+I had figured the debug log might be helpful... Pardon me... :)
+"""]]
diff --git a/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_6_b90f349f00ea283d018681505b4feaf5._comment b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_6_b90f349f00ea283d018681505b4feaf5._comment
new file mode 100644
index 0000000000..1232f3195a
--- /dev/null
+++ b/doc/forum/Possible_bug_in_setting_up_Rsync.net_remote/comment_6_b90f349f00ea283d018681505b4feaf5._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="dave@2ab82f485adf7e2ce787066e35f5f9789bff430b"
+ nickname="dave"
+ subject="re: regular ssh remote"
+ date="2016-09-21T21:30:24Z"
+ content="""
+I tried adding my rsync.net space as a regular (ssh) remote instead of as an rsync.net remote.  I got this in the webapp:
+
+    Failed to ssh to the server. Transcript: 
+
+(sic)
+
+This time the debug log shows this:
+
+    [2016-09-21 16:19:15.0106417] read: ssh-keygen [\"-F\",\"usw-s009.rsync.net\"]
+    [2016-09-21 16:19:15.2376417] process done ExitSuccess
+    [2016-09-21 16:19:15.2376417] chat: ssh [
+      \"-oNumberOfPasswordPrompts=0\",
+      \"-oStrictHostKeyChecking=yes\",
+      \"-n\",
+      \"-p\",
+      \"22\",
+      \"9553@usw-s009.rsync.net\",
+      \"sh -c 'echo '\\"'\\"'git-annex-probe loggedin'\\"'\\"';if which git-annex-shell; then echo '\\"'\\"'git-annex-probe git-annex-shell'\\"'\\"'; fi;if which git; then echo '\\"'\\"'git-annex-probe git'\\"'\\"'; fi;if which rsync; then echo '\\"'\\"'git-annex-probe rsync'\\"'\\"'; fi;if which ~/.ssh/git-annex-shell; then echo '\\"'\\"'git-annex-probe ~/.ssh/git-annex-shell'\\"'\\"'; fi;if which ~/.ssh/git-annex-wrapper; then echo '\\"'\\"'git-annex-probe ~/.ssh/git-annex-wrapper'\\"'\\"'; fi;cd '\\"'\\"'annex'\\"'\\"' && git config --list'\"]
+    [2016-09-21 16:19:17.4001417] process done ExitFailure 1
+
+
+For what it is worth:
+
+    $ ssh -oNumberOfPasswordPrompts=0 -oStrictHostKeyChecking=yes -n -p 22 9553@usw-s009.rsync.net sh -c 'echo hello'
+
+THAT fails with exit code 1.  But that's just because it's rsync.net, a restricted shell...  (The same command with just 'ls' works!)
+
+I'm back to thinking that it's actually trying to resolve the mangled string.  However, I've been known to be completely wrong before!
+"""]]
diff --git a/doc/forum/Possible_to_restore_from_an_encrypted_s3_remote__63__.mdwn b/doc/forum/Possible_to_restore_from_an_encrypted_s3_remote__63__.mdwn
new file mode 100644
index 0000000000..6502a5ad5d
--- /dev/null
+++ b/doc/forum/Possible_to_restore_from_an_encrypted_s3_remote__63__.mdwn
@@ -0,0 +1,5 @@
+I tried creating a new git annex repo on my desktop and adding the remote but I think I got an error about both repos not having the same idea. I might be wrong.
+
+Is it possible to init a git annex repo on my desktop using an encrypted s3 remote?
+
+thanks
diff --git a/doc/forum/Possible_to_restore_from_an_encrypted_s3_remote__63__/comment_1_98033f3324bf78af886fa0f003f5eff8._comment b/doc/forum/Possible_to_restore_from_an_encrypted_s3_remote__63__/comment_1_98033f3324bf78af886fa0f003f5eff8._comment
new file mode 100644
index 0000000000..83b3f73c73
--- /dev/null
+++ b/doc/forum/Possible_to_restore_from_an_encrypted_s3_remote__63__/comment_1_98033f3324bf78af886fa0f003f5eff8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-03-04T21:17:26Z"
+ content="""
+You need to clone to git repository where you initialized the special
+remote the first time, then `git-annex enableremote` will enable using it
+from the clone.
+"""]]
diff --git a/doc/forum/Possible_to_restore_from_an_encrypted_s3_remote__63__/comment_2_ddd6a56d583fd5b9d676365f4ebd9b68._comment b/doc/forum/Possible_to_restore_from_an_encrypted_s3_remote__63__/comment_2_ddd6a56d583fd5b9d676365f4ebd9b68._comment
new file mode 100644
index 0000000000..48c4394cfc
--- /dev/null
+++ b/doc/forum/Possible_to_restore_from_an_encrypted_s3_remote__63__/comment_2_ddd6a56d583fd5b9d676365f4ebd9b68._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="bbigras"
+ avatar="http://cdn.libravatar.org/avatar/f1c0201e3f1435eaab02c803a33c52ae"
+ subject="comment 2"
+ date="2024-03-06T17:03:50Z"
+ content="""
+I'm not sure I understand what you mean.
+
+Do you mean that I should clone the s3 bucket with a tool like git-remote-s3? I'm not sure how to do that.
+
+I tried downloading the whole bucket from backblaze, but since I enabled encryption on the bucket, backblaze doesn't let me download the encrypted files. I'm not sure yet if I can get those files using their api.
+
+Just in case I didn't explain correctly what I'm trying to do, I'm trying to do something like this, on a new computer with a fresh ~/Document:
+
+```bash
+❯ cd ~/Documents
+❯ git init
+Initialized empty Git repository in /home/bbigras/Documents/.git/
+❯ git annex init
+init  ok
+(recording state in git...)
+❯ git annex initremote backblaze type=S3 signature=v4 host=s3.us-west-000.backblazeb2.com bucket=my-bucket protocol=https encryption=hybrid keyid=my-key-id
+initremote backblaze (encryption setup) (to gpg keys: my-key-id) (checking bucket...)
+  The bucket already exists, and its annex-uuid file indicates it is used by a different special remote.
+
+git-annex: Cannot reuse this bucket.
+failed
+initremote: 1 failed
+```
+"""]]
diff --git a/doc/forum/Post-Kickstarter.mdwn b/doc/forum/Post-Kickstarter.mdwn
new file mode 100644
index 0000000000..d774ca25b1
--- /dev/null
+++ b/doc/forum/Post-Kickstarter.mdwn
@@ -0,0 +1,5 @@
+We're nearing the end of the year of development funded by Kickstarter. I'm curious to know what the future of the project looks like.
+
+I assume that development will decrease from its current levels as you focus more of your energy on activities that put bread on the table, but is git-annex still something that you foresee actively working on or will it be in more of a feature-freeze-bug-fix stage?
+
+As a backer my only regret is that during the campaign I wasn't able to donate as much as I would have liked. The project has exceeded my expectations since then. I don't know that another Kickstarter campaign is worth the effort, but if you were to ask for donations to fund another month or two or three I would gladly donate. Or perhaps implement a feature-bounty program where users could donate money toward development of a particular feature they would like to see added. Or perhaps you're sick of working for the Internet!
diff --git a/doc/forum/Preferred_content_settings_for_sets_of_backup_drives__63__.mdwn b/doc/forum/Preferred_content_settings_for_sets_of_backup_drives__63__.mdwn
new file mode 100644
index 0000000000..6ddb1e011d
--- /dev/null
+++ b/doc/forum/Preferred_content_settings_for_sets_of_backup_drives__63__.mdwn
@@ -0,0 +1,3 @@
+I have one main 4TB annex and 4 2TB drives that I would like to use for long-term backups. The plan is to have two complete backups, one at home and one in a different state, and swap + update them occasionally. If I put an annex on each drive, how can I tell git annex that every file should be duplicated to one or the other from each set? Like this:
+
+main and (backup1a or backup1b) and (backup2a or backup2b)
diff --git a/doc/forum/Preferred_content_settings_for_sets_of_backup_drives__63__/comment_1_54cdea3a60d61dad6332af31b2968bdd._comment b/doc/forum/Preferred_content_settings_for_sets_of_backup_drives__63__/comment_1_54cdea3a60d61dad6332af31b2968bdd._comment
new file mode 100644
index 0000000000..7f02010dbf
--- /dev/null
+++ b/doc/forum/Preferred_content_settings_for_sets_of_backup_drives__63__/comment_1_54cdea3a60d61dad6332af31b2968bdd._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-06T17:38:55Z"
+ content="""
+Repository groups are a good way to do this. Eg: 
+
+	git annex group backup1a backup1
+	git annex group backup1b backup1
+	git annex group backup2a backup2
+	git annex group backup2b backup2
+	git annex wanted backup1a "not copies=backup1:1"
+	git annex wanted backup1b "not copies=backup1:1"
+	git annex wanted backup2a "not copies=backup2:1"
+	git annex wanted backup2b "not copies=backup2:1"
+"""]]
diff --git a/doc/forum/Preferred_content_settings_for_sets_of_backup_drives__63__/comment_2_c21e128f6bdd5408607b51c963854d4d._comment b/doc/forum/Preferred_content_settings_for_sets_of_backup_drives__63__/comment_2_c21e128f6bdd5408607b51c963854d4d._comment
new file mode 100644
index 0000000000..d85c266099
--- /dev/null
+++ b/doc/forum/Preferred_content_settings_for_sets_of_backup_drives__63__/comment_2_c21e128f6bdd5408607b51c963854d4d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jeff"
+ avatar="http://cdn.libravatar.org/avatar/6f3f360b92a588e1b0999bbd4707ce12"
+ subject="comment 2"
+ date="2017-06-07T21:24:36Z"
+ content="""
+Thanks! I missed that you can put group names in the \"copies=\" part.
+"""]]
diff --git a/doc/forum/Preferred_contents_based_on_presence_in_repo.mdwn b/doc/forum/Preferred_contents_based_on_presence_in_repo.mdwn
new file mode 100644
index 0000000000..8436c25fd4
--- /dev/null
+++ b/doc/forum/Preferred_contents_based_on_presence_in_repo.mdwn
@@ -0,0 +1,5 @@
+For [preferred content expressions](https://git-annex.branchable.com/git-annex-preferred-content/), is there an option analogous to the "--in=repo" [matching option](https://git-annex.branchable.com/git-annex-matching-options/)?
+
+I was surprised not to find it, but maybe I have overlooked something.
+
+Many thanks
diff --git a/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_1_2109fe43fccc6576e782a2e765eb6b50._comment b/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_1_2109fe43fccc6576e782a2e765eb6b50._comment
new file mode 100644
index 0000000000..5746c77d01
--- /dev/null
+++ b/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_1_2109fe43fccc6576e782a2e765eb6b50._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="can use copies=groupname:number"
+ date="2020-03-05T20:26:01Z"
+ content="""
+You could use the approach mentioned in the `preferred-content`
+manpage:
+
+    Preferred content expressions have no equivalent to the `--in`
+    option, but groups can accomplish similar things. You can add
+    repositories to groups, and match against the groups in a
+    preferred content expression. So rather than `--in=usbdrive`,
+    put all the USB drives into a \"transfer\" group, and use
+    `copies=transfer:1`
+
+"""]]
diff --git a/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_2_f3adab92e7015245735f4bcad1d7a146._comment b/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_2_f3adab92e7015245735f4bcad1d7a146._comment
new file mode 100644
index 0000000000..559fddb88c
--- /dev/null
+++ b/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_2_f3adab92e7015245735f4bcad1d7a146._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="erewhon"
+ avatar="http://cdn.libravatar.org/avatar/b9bd5ad7176ebe149d0f051dcfe0a63e"
+ subject="comment 2"
+ date="2020-03-07T23:14:56Z"
+ content="""
+Thanks, I missed that in the man page.
+
+Is there a rationale for not having the option for preferred contents?
+"""]]
diff --git a/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_3_6aaf8226051e9dd104da206b032cfe5a._comment b/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_3_6aaf8226051e9dd104da206b032cfe5a._comment
new file mode 100644
index 0000000000..8e90e2ebd9
--- /dev/null
+++ b/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_3_6aaf8226051e9dd104da206b032cfe5a._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="re: rationale"
+ date="2020-03-09T22:17:51Z"
+ content="""
+> Is there a rationale for not having the option for preferred contents?
+
+Hmm, I wouldn't be able to answer this myself, but digging around a
+bit it looks like there used to be an `in=` option.  Here's the
+rationale given in that commit:
+
+```
+CommitDate: Fri Oct 19 16:09:21 2012 -0400
+40aab719dfe9c3bd240656c1ff387cad0ba8d96d
+
+Replace \"in=\" with \"present\" in preferred content expressions
+
+in= was problimatic in two ways. First, it referred to a remote by name,
+but preferred content expressions can be evaluated elsewhere, where that
+remote doesn't exist, or a different remote has the same name. This name
+lookup code could error out at runtime. Secondly, in= seemed pretty useless.
+in=here did not cause content to be gotten, but it did let present content
+be dropped.
+
+present is more useful, although \"not present\" is unstable and should be
+avoided.
+```
+
+"""]]
diff --git a/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_4_ffda2c94cbccab1d462a4e333816773b._comment b/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_4_ffda2c94cbccab1d462a4e333816773b._comment
new file mode 100644
index 0000000000..125a793691
--- /dev/null
+++ b/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_4_ffda2c94cbccab1d462a4e333816773b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="erewhon"
+ avatar="http://cdn.libravatar.org/avatar/b9bd5ad7176ebe149d0f051dcfe0a63e"
+ subject="comment 4"
+ date="2020-03-11T16:11:54Z"
+ content="""
+Thanks for digging this out. It makes sense.
+"""]]
diff --git a/doc/forum/Prepare_simple_USB_backup___40__for_WAF__41__.mdwn b/doc/forum/Prepare_simple_USB_backup___40__for_WAF__41__.mdwn
new file mode 100644
index 0000000000..d2586d8e17
--- /dev/null
+++ b/doc/forum/Prepare_simple_USB_backup___40__for_WAF__41__.mdwn
@@ -0,0 +1,5 @@
+I recently started using this awesome tool for backing up and location tracking personal data across multiple laptops, servers and usb drives. I want to create a simple backup archive on bunch of usb hdds so my family can have access to this data without having to learn any tool or me being around.
+
+I am able to do "rsync -PavLh" from my annex to usb drive and create a full simple backup. However, i lose location tracking with that since git-annex won't know what files are already copied. How do i prepare a simple exFat or NTFS usb with all data clearly visible without sim links or anything so that anyone can use it?
+
+Is it good idea to just create an annex on ntfs drive and then mark it unlocked before disconnecting? That way, however, connects that ntfs drive to a windows machine, they can just see directories without symlink shenanigans. Any other alternative? Any way to always mark a repo unlocked?
diff --git a/doc/forum/Prepare_simple_USB_backup___40__for_WAF__41__/comment_1_a02dd00950793814ea9617e0eec738ba._comment b/doc/forum/Prepare_simple_USB_backup___40__for_WAF__41__/comment_1_a02dd00950793814ea9617e0eec738ba._comment
new file mode 100644
index 0000000000..fc25b4eeb7
--- /dev/null
+++ b/doc/forum/Prepare_simple_USB_backup___40__for_WAF__41__/comment_1_a02dd00950793814ea9617e0eec738ba._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Spellbind8200"
+ avatar="http://cdn.libravatar.org/avatar/ca9df5665bccf2918715685e2ec40a09"
+ subject="Found unlock"
+ date="2022-11-29T09:05:43Z"
+ content="""
+Nvm, i just read detailed documentation on \" git annex adjust --unlock\" and that does seem to do the trick. 
+"""]]
diff --git a/doc/forum/Preserving_Directories_in_Metadata_Views.mdwn b/doc/forum/Preserving_Directories_in_Metadata_Views.mdwn
new file mode 100644
index 0000000000..dfc45cb4b6
--- /dev/null
+++ b/doc/forum/Preserving_Directories_in_Metadata_Views.mdwn
@@ -0,0 +1,47 @@
+I want to use metadata views to sort files into top-level directories based on a tag, but then preserve the directory structure underneath that. I'm having trouble with this.
+
+Say I have an annex at `~/annex` with a structure like this:
+
+    $ tree
+    .
+    ├── foo
+    │   └── bar
+    │       ├── one.txt
+    │       ├── three.txt
+    │       └── two.txt
+    └── waldo
+        └── fred
+            ├── a.txt
+            ├── b.txt
+            └── c.txt
+
+I tag some of the files with `blah`:
+
+    $ git annex metadata -t blah foo/bar/*
+
+Now I want to change my view to only see those files with a certain tag, but I want to maintain their directory structure, ie I want to end up with something like this:
+
+    $ tree
+    .
+    ├── blah
+    │   └── foo
+    │       └── bar
+    │           ├── one.txt
+    │           ├── three.txt
+    │           └── two.txt
+
+If I do `git annex view blah` I see the files `one.txt`, `two.txt` and `three.txt` but they are in the top level of `~/annex`. The `foo` and `bar` directories are not present.
+
+If I do `git annex view blah "/=*"` then the files I present under the `foo` directory, but the `bar` subdirectory is not there.
+
+It would also be fine if I could just hide the files that did not have the `blah` tag, so that I ended up with this:
+
+    $ tree
+    .
+    ├── foo
+    │   └── bar
+    │       ├── one.txt
+    │       ├── three.txt
+    │       └── two.txt
+
+Is something like this possible?
diff --git a/doc/forum/Preserving_Directories_in_Metadata_Views/comment_1_30332d3828324455600b0b452e3b6c5a._comment b/doc/forum/Preserving_Directories_in_Metadata_Views/comment_1_30332d3828324455600b0b452e3b6c5a._comment
new file mode 100644
index 0000000000..f07a32715b
--- /dev/null
+++ b/doc/forum/Preserving_Directories_in_Metadata_Views/comment_1_30332d3828324455600b0b452e3b6c5a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="psxvoid"
+ avatar="http://cdn.libravatar.org/avatar/fde068fbdeabeea31e3be7aa9c55d84b"
+ subject="This behavior should be the default one"
+ date="2024-02-10T08:11:30Z"
+ content="""
+This behavior needs to be the default. Though, I understand that everyone have different needs.
+
+At least it may be better to configure the behavior via a command argument, e.g. by default `git annex view` preserves the directory structure.
+
+And when `--plain` argument is provided, then it would behave as it currently does - the directory structure is not preserved.
+
+Personally, I do not see any use cases for the active behavior because usually I set tags to many files (thousands), and it's not practical for me to see thousand files in a single directory (view tag). As a more real-world example - I've tried to prepare files to be burned into BDXL disk, and for that purpose I tagged the files I want to burn as `bdxl-disk-1` tag. I then used `ncdu` to analyze the space taken by that tag. But then when I started \"fine tuning\" what should and should not go to that disk, I found it too difficult because `git annex view` places all tagged files into a single directory.
+
+Are there any workarounds? I'm using git annex version `10.20231228`.
+"""]]
diff --git a/doc/forum/Preserving_Directories_in_Metadata_Views/comment_2_0decf76e18bb9fbc9b55e94f647a466d._comment b/doc/forum/Preserving_Directories_in_Metadata_Views/comment_2_0decf76e18bb9fbc9b55e94f647a466d._comment
new file mode 100644
index 0000000000..7289595c72
--- /dev/null
+++ b/doc/forum/Preserving_Directories_in_Metadata_Views/comment_2_0decf76e18bb9fbc9b55e94f647a466d._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="psxvoid"
+ avatar="http://cdn.libravatar.org/avatar/fde068fbdeabeea31e3be7aa9c55d84b"
+ subject="Update: workaround with branches"
+ date="2024-02-10T10:53:56Z"
+ content="""
+Seems like there is a way to use git annex as I would like, though it may not be obvious.
+
+In order to organize files and then burn them on to BDXL, instead of using tags, I've just switched to a new branch.
+e.g.:
+
+```sh
+git checkout -b view/bdxl
+```
+
+and then moved files and folders to a new folder which I intend to burn later. I've also assigned `git annex tag bdxl-disk-1 . --force` directly in this folder, so later I can see which files are burned even on the main branch (because tags are tied to git annex content and shared across branches).
+
+P.S.: In any case, preserving the folder structure on the first `git annex view tag=*` may be much more powerful and intuitive.
+"""]]
diff --git a/doc/forum/Preserving_extended_attributes.mdwn b/doc/forum/Preserving_extended_attributes.mdwn
new file mode 100644
index 0000000000..5533daeea9
--- /dev/null
+++ b/doc/forum/Preserving_extended_attributes.mdwn
@@ -0,0 +1,5 @@
+Hey,
+
+I was wondering if it is currently possible to let the assistant (or git-annex in general) preserve extended attributes. I didn't find any options hinting at this, although it should be possible at least in theory by using the metadata system of git-annex...
+
+Considering that some applications use extended attributes to store custom meta data (like tags etc.), I think it would be valuable to have such an option...
diff --git a/doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__.mdwn b/doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__.mdwn
new file mode 100644
index 0000000000..d89bcee290
--- /dev/null
+++ b/doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__.mdwn
@@ -0,0 +1,77 @@
+Hello,
+
+I have the problem that, while git-annex preserves the file access rights (user, group, others) for the actual file, it does not make sure that others can access this file through the directory tree above said file:
+
+    /tmp $ mkdir test
+    /tmp $ chown claudius:media test
+    /tmp $ chmod 750 test
+    /tmp $ ls -dl test
+    drwxr-x--- 2 claudius media 40 2012-01-23 19:27 test/
+    /tmp $ cd test
+    /tmp/test $ git init --shared=all
+    Initialized empty shared Git repository in /tmp/test/.git/
+    /tmp/test $ git annex init "test"
+    init test ok
+    /tmp/test $ echo 123 > abc
+    /tmp/test $ chmod 640 abc
+    /tmp/test $ chown claudius:media abc
+    /tmp/test $ ls -l
+    total 4
+    -rw-r----- 1 claudius media 4 2012-01-23 19:27 abc
+    /tmp/test $ git annex add .
+    add abc (checksum...) ok
+    (Recording state in git...)
+    /tmp/test $ ls -l
+    total 4
+    lrwxrwxrwx 1 claudius claudius 176 2012-01-23 19:27 abc -> .git/annex/objects/8F/pj/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+    /tmp/test $ ls -l .git/annex/objects/8F/pj/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+    -r--r----- 1 claudius media 4 2012-01-23 19:27 .git/annex/objects/8F/pj/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+    /tmp/test $ ls -lR .git/annex/objects/
+    .git/annex/objects/:
+    total 0
+    drwx--S--- 3 claudius claudius 60 2012-01-23 19:28 8F/
+    
+    .git/annex/objects/8F:
+    total 0
+    drwx--S--- 3 claudius claudius 60 2012-01-23 19:28 pj/
+    
+    .git/annex/objects/8F/pj:
+    total 0
+    dr-x--S--- 2 claudius claudius 60 2012-01-23 19:28 SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/
+    
+    .git/annex/objects/8F/pj/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b:
+    total 4
+    -r--r----- 1 claudius media 4 2012-01-23 19:27 SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+    /tmp/test $ stat .git/annex/objects/
+      File: `.git/annex/objects/'
+      Size: 60        	Blocks: 0          IO Block: 4096   directory
+    Device: 11h/17d	Inode: 2365970     Links: 3
+    Access: (2700/drwx--S---)  Uid: ( 1000/claudius)   Gid: ( 1000/claudius)
+    Access: 2012-01-23 19:28:10.614948386 +0100
+    Modify: 2012-01-23 19:28:10.614948386 +0100
+    Change: 2012-01-23 19:28:10.614948386 +0100
+     Birth: -
+
+The use case is that I have a rather large collection of music I would like to manage with git-annex in various locations (all of it on my external hard drive, some on my notebook etc. This music is played by MPD, which can access the collection because it is in the "media" group. After changing to git-annex, however, this fails.
+
+I tried to avoid this specific problem by declaring the git repository to be shared, which does appear to have some effect on the other files in .git:
+
+    /tmp/test $ ls -l .git
+    total 16
+    drwx--S---  5 claudius claudius 160 2012-01-23 19:28 annex/
+    drwxrwsr-x  2 claudius claudius  40 2012-01-23 19:27 branches/
+    -rw-rw-r--  1 claudius claudius 218 2012-01-23 19:27 config
+    -rw-rw-r--  1 claudius claudius  73 2012-01-23 19:27 description
+    -rw-rw-r--  1 claudius claudius  23 2012-01-23 19:27 HEAD
+    drwxrwsr-x  2 claudius claudius 220 2012-01-23 19:27 hooks/
+    -rw-rw-r--  1 claudius claudius 104 2012-01-23 19:28 index
+    drwxrwsr-x  2 claudius claudius  60 2012-01-23 19:27 info/
+    drwxrwsr-x  3 claudius claudius  60 2012-01-23 19:27 logs/
+    drwxrwsr-x 15 claudius claudius 300 2012-01-23 19:28 objects/
+    drwxrwsr-x  4 claudius claudius  80 2012-01-23 19:27 refs/
+
+I could obviously try to change the rights of annex/, annex/objects etc., but I would like to avoid having to adapt them each time a new folder is added somewhere below annex/objects/.
+
+My knowledge of git and especially git-annex is not too good, so it might well be that I missed something obvious. Any hints? :)
+
+(And thank you, of course, for taking the time to read all this)
diff --git a/doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__/comment_1_5dd978f9b5a0771f44ab9e086bf5a07f._comment b/doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__/comment_1_5dd978f9b5a0771f44ab9e086bf5a07f._comment
new file mode 100644
index 0000000000..d2da5e94df
--- /dev/null
+++ b/doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__/comment_1_5dd978f9b5a0771f44ab9e086bf5a07f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-01-23T19:00:40Z"
+ content="""
+You say you started the repo with \"git init --shared\" .. but what that's really meant for is bare repositories, which can have several users pushing into it, not a non-bare repository.
+
+The strange mode on the directories \"dr-x--S---\" and files \"-r--r-----\" must be due to your umask setting though. My umask is 022 and the directories and files under `.git/annex/objects` are \"drwxr-xr-x\" and \"-r--r--r--\", which allows anyone to read them unless an upper directory blocks it -- and with this umask, none do unless I explicitly remove permissions from one to lock down a repository.
+
+About mpd, the obvious fix is to run mpd not as a system user but as yourself. I put \"@reboot mpd\" in my crontab to do this.
+
+
+"""]]
diff --git a/doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__/comment_2_9f51947b35ee04e473655e20d56c740a._comment b/doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__/comment_2_9f51947b35ee04e473655e20d56c740a._comment
new file mode 100644
index 0000000000..5d632ab860
--- /dev/null
+++ b/doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__/comment_2_9f51947b35ee04e473655e20d56c740a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlB7-aXsqwzOi2BIR_Q4sUF8sjj24H6F3c"
+ nickname="Claudius"
+ subject="comment 2"
+ date="2012-01-23T19:39:17Z"
+ content="""
+Thank you for your comment! Indeed, setting the umask to, for example, 022 has the desired effect that annex/objects etc. are executable (and in this special case also writable), my previous umask setting was 077; the \"strange\" permissions on the git directories was probably due to --shared=all, and the mode of \"440\" on the files within the git-annex tree is correct (the original file was 640 and stripped of its write permission).
+
+Using this umask setting and newgrp to switch the default group, I was successfully able to set up the repositories.
+
+However, I would like to suggest adding the execute bit to the directories below .git/annex/objects/ per default, even if the umask of the current shell differs. As the correct rights are already preserved in the actual files (minus their write permission) together with correct owner and group, the files are still protected the same way as previously, and because +x does not allow directory listings, no additional information can leak out either. Not having to set the umask to something \"sensible\" before operating git-annex would be a huge plus, too :)
+
+The reason why I am not running MPD as my user is that I am a bit wary of running an application even exposed to the local network as my main user, and I see nothing wrong with running it as its own user.
+
+Thank you again for your help and the time you put into this project!
+"""]]
diff --git a/doc/forum/Preserving_the_v5_experience.mdwn b/doc/forum/Preserving_the_v5_experience.mdwn
new file mode 100644
index 0000000000..df928a10b2
--- /dev/null
+++ b/doc/forum/Preserving_the_v5_experience.mdwn
@@ -0,0 +1,14 @@
+The v5 version had a few advantages over the v7 version (at least when no direct mode was involved); in particular:
+
+1. Annexed and plain git files could be kept in parallel
+2. Files that are under annex control are immediately recognized as such (in file managers by displaying a symlink icon)
+3. Never is a file readable with its wrong content (an absent file reads as ENOTFOUND rather than "/annex/...")
+4. Never do changes resulting from users' workflows (who checks out what where, who locks something) show up in the actual git history.
+
+I'd like to configure my annex repositories to give those properties, but that may need some more options:
+
+* Setting `* annex.largefiles=nothing` in `.gitattributes` restores 1 (and can still be customized)
+* Customizing it or users locking files still leaves files in their v7locked state where they can be accidentally read or otherwise look like plain available files (2-4). Having a `annex.neverlock` option that plain-out rejects adding files in locked mode or locking them would keep history and file list clean. That should be a `git annex config` option.
+* There could still be an `git annex adjust --locked` that gives users the option to have a locked adjust branch (or lock files in their own adjusted branch) without those changes propagating into every user's history.
+
+When `neverlock` is active and `git add` is run on a largefile, it could reject adding the file, place the users in a `--lock` adjusted branch, or add the file in a locked state.
diff --git a/doc/forum/Preserving_the_v5_experience/comment_1_9b188fecb7eaeb3ec3ba47f4c5e17e37._comment b/doc/forum/Preserving_the_v5_experience/comment_1_9b188fecb7eaeb3ec3ba47f4c5e17e37._comment
new file mode 100644
index 0000000000..733433c2b0
--- /dev/null
+++ b/doc/forum/Preserving_the_v5_experience/comment_1_9b188fecb7eaeb3ec3ba47f4c5e17e37._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2019-09-25T15:26:39Z"
+ content="""
+\"Having a annex.neverlock option that plain-out rejects adding files in locked mode\" -- did you mean unlocked mode?
+
+A related suggestion: [[todo/auto-lock_files_after_one_edit]]
+"""]]
diff --git a/doc/forum/Preserving_the_v5_experience/comment_2_d2da6d56980b535431d7f0360f58d04c._comment b/doc/forum/Preserving_the_v5_experience/comment_2_d2da6d56980b535431d7f0360f58d04c._comment
new file mode 100644
index 0000000000..12f22c52b8
--- /dev/null
+++ b/doc/forum/Preserving_the_v5_experience/comment_2_d2da6d56980b535431d7f0360f58d04c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-09-25T17:24:21Z"
+ content="""
+Related: [[forum/lets_discuss_git_add_behavior]]
+
+I agree that (1)-(4) were good properties.  (4) could be mitigated by using `git commit --amend` to merge the lock/unlock change with the previous commit.  But if the previous commit has been pushed to a shared repo, this could cause problems.  Something like [[todo/auto-lock_files_after_one_edit]] would restore (1)-(4), at the cost of requiring manual unlock to edit again as in v5.
+"""]]
diff --git a/doc/forum/Preserving_the_v5_experience/comment_3_b15c92675cf6a5087ced6a649dd1b6c7._comment b/doc/forum/Preserving_the_v5_experience/comment_3_b15c92675cf6a5087ced6a649dd1b6c7._comment
new file mode 100644
index 0000000000..df902e16df
--- /dev/null
+++ b/doc/forum/Preserving_the_v5_experience/comment_3_b15c92675cf6a5087ced6a649dd1b6c7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="smithclarkson001@2d22c4a26d6e52831b460b949377a8c9d6139a94"
+ nickname="smithclarkson001"
+ avatar="http://cdn.libravatar.org/avatar/e050ab885958a05800aa3360200e2ec1"
+ subject="comment 3"
+ date="2019-09-27T13:16:01Z"
+ content="""
+\"Having a annex.neverlock option that plain-out rejects adding files in locked mode\" -- did you mean unlocked mode?
+
+A related suggestion: auto-lock files after one edit
+
+Make sense.
+"""]]
diff --git a/doc/forum/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted.mdwn b/doc/forum/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted.mdwn
new file mode 100644
index 0000000000..cbe5fc0923
--- /dev/null
+++ b/doc/forum/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted.mdwn
@@ -0,0 +1,13 @@
+Hello! <br>
+
+&nbsp;&nbsp;&nbsp;&nbsp; I am running `Termux` on a `Huawei P20` running `Android 9.x`; when syncing content, I seem to keep getting this on most / all annexed objects:
+
+```bash
+/data/data/com.termux/files/home/git-annex.linux/shimmed/cp/cp: preserving times for '.git/annex/othertmp/*': Operation not permitted
+```
+
+where `*` is replaced by whatever object is in the folder. I don't know if this is a permissions issue or not, but it is kind of annoying, and takes time from the sync process itself. <br>
+
+&nbsp;&nbsp;&nbsp;&nbsp; Is there any way to change the shimmed `cp` to ignore times? <br>
+
+&nbsp;&nbsp;&nbsp;&nbsp; Thank you kindly for the help!
diff --git a/doc/forum/Preventing_annex.ignore_for_remote.mdwn b/doc/forum/Preventing_annex.ignore_for_remote.mdwn
new file mode 100644
index 0000000000..f305556d41
--- /dev/null
+++ b/doc/forum/Preventing_annex.ignore_for_remote.mdwn
@@ -0,0 +1,3 @@
+Sometimes through misconfiguration I have situations where the git server is reachable but annex fails to reach the annex-shell.  If I set `annex.ignore` explicitly to `false` for a remote, will that prevent git-annex from setting it to true in these situations?
+
+I want to be able to set it so that even if a remote is detected to not support annex, it should still regard it as an annex remote.
diff --git a/doc/forum/Preventing_annex.ignore_for_remote/comment_1_ec28f3ed75f2abad3d01a90c5b79c4b8._comment b/doc/forum/Preventing_annex.ignore_for_remote/comment_1_ec28f3ed75f2abad3d01a90c5b79c4b8._comment
new file mode 100644
index 0000000000..223838073d
--- /dev/null
+++ b/doc/forum/Preventing_annex.ignore_for_remote/comment_1_ec28f3ed75f2abad3d01a90c5b79c4b8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 1"
+ date="2020-09-21T14:38:24Z"
+ content="""
+> If I set annex.ignore explicitly to false for a remote, will that
+> prevent git-annex from setting it to true in these situations?
+
+Based on light testing and grepping, I think `annex.ignore` will still
+be set to true in that case
+"""]]
diff --git a/doc/forum/Preventing_annex.ignore_for_remote/comment_2_57703f8d610aae7fadb8980e77a408b0._comment b/doc/forum/Preventing_annex.ignore_for_remote/comment_2_57703f8d610aae7fadb8980e77a408b0._comment
new file mode 100644
index 0000000000..777ccbe897
--- /dev/null
+++ b/doc/forum/Preventing_annex.ignore_for_remote/comment_2_57703f8d610aae7fadb8980e77a408b0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="achilleas.k@14be77d42a1252fab5ec9dbf4e5ea03c5833e8c8"
+ avatar="http://cdn.libravatar.org/avatar/ed6c67c4d8e6c6850930e16eaf85a771"
+ subject="comment 2"
+ date="2020-09-21T14:42:01Z"
+ content="""
+Thanks for checking.  I'll have to keep an eye on it I suppose.  Not a major problem, just something to watch.
+"""]]
diff --git a/doc/forum/Previous_versions_in_direct_mode__63__.mdwn b/doc/forum/Previous_versions_in_direct_mode__63__.mdwn
new file mode 100644
index 0000000000..2958346e73
--- /dev/null
+++ b/doc/forum/Previous_versions_in_direct_mode__63__.mdwn
@@ -0,0 +1,3 @@
+I am in Windows and therefore forced to use direct mode. After reading for a long while I still have not found a way of "git annex get" previous versions. Is this supported? is it only the last version in the repository?
+
+any chance to use indirect mode in Windows? In theory Windows supports NTFS symlinks, why is this not supported?
diff --git a/doc/forum/Previous_versions_in_direct_mode__63__/comment_1_352d460acd5500587e679d934180eee4._comment b/doc/forum/Previous_versions_in_direct_mode__63__/comment_1_352d460acd5500587e679d934180eee4._comment
new file mode 100644
index 0000000000..b81e6c85e4
--- /dev/null
+++ b/doc/forum/Previous_versions_in_direct_mode__63__/comment_1_352d460acd5500587e679d934180eee4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2013-12-24T20:56:00Z"
+ content="""
+git-annex for windows is targeting being used with msysgit, and msysgit does not seem to support symlinks. That's one good reason. Since cywin's git does support symlinks, it might be possible to get git-annex to use it and support indirect mode.
+
+Doing anything about this is probably \"patches accepted\" territory for me. I'm mostly interested in porting git-annex to Windows so it can be used on computers owned by non-technical users, to interoperate with git-annex on more capable operating systems.
+"""]]
diff --git a/doc/forum/Problem_compiling_current_master.mdwn b/doc/forum/Problem_compiling_current_master.mdwn
new file mode 100644
index 0000000000..5c796ecde8
--- /dev/null
+++ b/doc/forum/Problem_compiling_current_master.mdwn
@@ -0,0 +1,14 @@
+While trying to compile the current master I run in the following error:
+
+    Utility/Yesod.hs:21:14:
+        Couldn't match expected type `String'
+                    with actual type `WidgetFileSettings'
+        Expected type: String -> Q Exp
+          Actual type: WidgetFileSettings -> FilePath -> Q Exp
+        In the expression: widgetFileNoReload
+        In an equation for `widgetFile': widgetFile = widgetFileNoReload
+    make: *** [git-annex] Fehler 1
+
+I installed all dependencies from the INSTALL document. What is wrong?
+
+[[!tag forumbug]] [[bugs/done]]
diff --git a/doc/forum/Problem_compiling_current_master/comment_1_135df61ec850c06e3b48ccfef7b5b031._comment b/doc/forum/Problem_compiling_current_master/comment_1_135df61ec850c06e3b48ccfef7b5b031._comment
new file mode 100644
index 0000000000..676cc697d6
--- /dev/null
+++ b/doc/forum/Problem_compiling_current_master/comment_1_135df61ec850c06e3b48ccfef7b5b031._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.16"
+ subject="comment 1"
+ date="2012-08-29T15:51:15Z"
+ content="""
+I think you're building with the Makefile, not with cabal, and have the recent yesod 1.1.0 release installed. The Makefile contains a -DWITH_OLD_YESOD that you need to remove in that situation.
+"""]]
diff --git a/doc/forum/Problem_compiling_current_master/comment_2_fb3e27b6014e84bd919a7a4a95e39ef9._comment b/doc/forum/Problem_compiling_current_master/comment_2_fb3e27b6014e84bd919a7a4a95e39ef9._comment
new file mode 100644
index 0000000000..61c6f3be67
--- /dev/null
+++ b/doc/forum/Problem_compiling_current_master/comment_2_fb3e27b6014e84bd919a7a4a95e39ef9._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmU_2tE75oyG0h2ZPN4lcroIKEMC8G-otE"
+ nickname="Michael"
+ subject="comment 2"
+ date="2012-08-30T11:32:24Z"
+ content="""
+That helped now the compile stops at:
+
+    Utility/WebApp.hs:106:9:
+        Ambiguous occurrence `liftIO'
+        It could refer to either `Yesod.liftIO',
+                                 imported from `Yesod' at Utility/WebApp.hs:14:1-12
+                                 (and originally defined in `transformers-0.2.2.0:Control.Monad.IO.Class')
+                              or `Control.Monad.IO.Class.liftIO',
+                                 imported from `Control.Monad.IO.Class' at Utility/WebApp.hs:18:1-29
+    make: *** [git-annex] Fehler 1
+
+
+
+"""]]
diff --git a/doc/forum/Problem_compiling_current_master/comment_3_b737b3945103c5e2aa798b4e65fbce06._comment b/doc/forum/Problem_compiling_current_master/comment_3_b737b3945103c5e2aa798b4e65fbce06._comment
new file mode 100644
index 0000000000..12c4b1af08
--- /dev/null
+++ b/doc/forum/Problem_compiling_current_master/comment_3_b737b3945103c5e2aa798b4e65fbce06._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.16"
+ subject="comment 3"
+ date="2012-08-30T17:07:44Z"
+ content="""
+I've fixed this.. I think. I don't have this problem with the version of yesod I have here.
+"""]]
diff --git a/doc/forum/Problem_compiling_current_master/comment_4_28c1b335ae388d4e1f22b711ac1c001f._comment b/doc/forum/Problem_compiling_current_master/comment_4_28c1b335ae388d4e1f22b711ac1c001f._comment
new file mode 100644
index 0000000000..d16e17c139
--- /dev/null
+++ b/doc/forum/Problem_compiling_current_master/comment_4_28c1b335ae388d4e1f22b711ac1c001f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmU_2tE75oyG0h2ZPN4lcroIKEMC8G-otE"
+ nickname="Michael"
+ subject="comment 4"
+ date="2012-08-31T08:04:18Z"
+ content="""
+Success! Now it compiles fine on Ubuntu 12.04 with make. Thank you.
+"""]]
diff --git a/doc/forum/Problem_with_Anaconda_and_git-annex_on_Windows.mdwn b/doc/forum/Problem_with_Anaconda_and_git-annex_on_Windows.mdwn
new file mode 100644
index 0000000000..617f8e8de6
--- /dev/null
+++ b/doc/forum/Problem_with_Anaconda_and_git-annex_on_Windows.mdwn
@@ -0,0 +1 @@
+I have a problem with using git-annex with Anaconda (I'm using Windows 10). I have installed Git (using "conda install -c conda-forge git" under Anaconda prompt) and then git-annex (in the Anaconda3/Library directory, as suggested e.g., here: http://handbook.datalad.org/en/inm7/intro/installation.html#windows-10). However, Anaconda doesn't seem to recognize git-annex at all (for example, running "git annex test" gives the error that "annex" is not a valid git command). At the same time I can run git and git-annex using Windows command line). I'd appreciate any help (is it somehow a problem with installation paths or something deeper?).
diff --git a/doc/forum/Problem_with_corrupt_SQLite_DB.mdwn b/doc/forum/Problem_with_corrupt_SQLite_DB.mdwn
new file mode 100644
index 0000000000..7cc2a5ddfb
--- /dev/null
+++ b/doc/forum/Problem_with_corrupt_SQLite_DB.mdwn
@@ -0,0 +1,17 @@
+Apparently, I managed to corrupt an SQLite DB when `git-annex get` ran out of space.  This prevents git-annex operations from
+working at all now.
+
+For example:
+
+    % git annex find --in .
+    sqlite worker thread crashed: SQLite3 returned ErrorError while attempting to perform prepare "SELECT null from content limit 1": no such table: content
+    git-annex: sqlite query crashed
+
+One of the few mentions of SQLite being used is in incremental fsck
+([[design/caching_database]]).  I did run incremental fsck in
+another repository a few days before this.  The fsck finished
+without issues, so I'd be happy with a solution that involves simply
+deleting the DB or something.
+
+- git-annex version: 6.20160527-gb7d4774
+- All repositories/remotes: version 5, indirect
diff --git a/doc/forum/Problem_with_corrupt_SQLite_DB/comment_1_4e10e6d1882feba8d0c1ad058e01143c._comment b/doc/forum/Problem_with_corrupt_SQLite_DB/comment_1_4e10e6d1882feba8d0c1ad058e01143c._comment
new file mode 100644
index 0000000000..ecb3206ee4
--- /dev/null
+++ b/doc/forum/Problem_with_corrupt_SQLite_DB/comment_1_4e10e6d1882feba8d0c1ad058e01143c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-31T15:53:32Z"
+ content="""
+Delete .git/annex/keys/db
+
+This database is not really needed unless your repository is in v6 mode.
+"""]]
diff --git a/doc/forum/Problem_with_corrupt_SQLite_DB/comment_2_98020b857e5b52ebbbaaeba1313f2697._comment b/doc/forum/Problem_with_corrupt_SQLite_DB/comment_2_98020b857e5b52ebbbaaeba1313f2697._comment
new file mode 100644
index 0000000000..d85b6a16e7
--- /dev/null
+++ b/doc/forum/Problem_with_corrupt_SQLite_DB/comment_2_98020b857e5b52ebbbaaeba1313f2697._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="gernot"
+ subject="comment 2"
+ date="2016-06-02T18:33:59Z"
+ content="""
+Perfect, thank you!
+"""]]
diff --git a/doc/forum/Problem_with_corrupt_SQLite_DB/comment_3_079359513b6b9fcf0030f49df0eaf64d._comment b/doc/forum/Problem_with_corrupt_SQLite_DB/comment_3_079359513b6b9fcf0030f49df0eaf64d._comment
new file mode 100644
index 0000000000..1bc48c8586
--- /dev/null
+++ b/doc/forum/Problem_with_corrupt_SQLite_DB/comment_3_079359513b6b9fcf0030f49df0eaf64d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="avar"
+ avatar="http://cdn.libravatar.org/avatar/57332d67a86eb51e06bf78d2baf42c3c"
+ subject="comment 3"
+ date="2017-06-16T20:37:47Z"
+ content="""
+What about if you are in v6 mode? I just read the wiki about that version upgrade, sounds exciting, but I got this with <v6 and I'm definitely not switching over if some sqlite error can hose my entire checkout. How do you actually recover from this when sqlite is a hard dependency?
+"""]]
diff --git a/doc/forum/Problem_with_corrupt_SQLite_DB/comment_4_6a5f8590e6a60be5afe6bc6ffce1c94e._comment b/doc/forum/Problem_with_corrupt_SQLite_DB/comment_4_6a5f8590e6a60be5afe6bc6ffce1c94e._comment
new file mode 100644
index 0000000000..fd0a05fe2b
--- /dev/null
+++ b/doc/forum/Problem_with_corrupt_SQLite_DB/comment_4_6a5f8590e6a60be5afe6bc6ffce1c94e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-06-26T16:20:29Z"
+ content="""
+In a v6 repository, the sqlite database is used to keep track of unlocked
+files. If all files are locked, the sqlite database can still be deleted
+safely.
+
+I've done some experimentation with deleting the sqlite database when there
+are unlocked files, and it seems that running `git annex fsck` manages to
+recover the deleted state and restores the database.
+
+Also, since git-annex uses sqlite in WAL mode, it may be possible to
+recover the database to the last good state by deleting
+`.git/annex/keys/db-wal`. You'd still want to run `git annex fsck`.
+"""]]
diff --git a/doc/forum/Problems_syncing_with_box.com.mdwn b/doc/forum/Problems_syncing_with_box.com.mdwn
new file mode 100644
index 0000000000..e536ccdb60
--- /dev/null
+++ b/doc/forum/Problems_syncing_with_box.com.mdwn
@@ -0,0 +1,26 @@
+I have a repository synchronized between two PCs and box.com . I chose encryption for box.com. Today on my work computer I changed files, on box.com I see that there are changed files today. When I got home, I still see files with yesterday's date.
+One thing to mention is that currently the work PC is not accessible. 
+
+1. How do I debug this problem? I have logging set to debug via web console, saved, restarted daemon, but after restart the debug checkbox is unchecked.
+From logs it looks like that after failing to connect to work pc via ssh it gives up:
+
+    [2013-05-09 21:42:52 CEST] main: Syncing with box.com
+this is first and last line mentioning box today, I restarted the daemon several times around 22:14 :
+
+    [2013-05-09 22:11:40 CEST] TransferScanner: Syncing with [work pc repo]
+    Already up-to-date.
+    
+    (scanning...) [2013-05-09 22:11:40 CEST] Watcher: Performing startup scan
+    Already up-to-date.
+    
+    (started...) ssh: connect to host [work pc] port 22: No route to host
+    fatal: The remote end hung up unexpectedly
+
+
+2. where is the configuration for box.com stored? How can I check gpg key ID mentioned at http://git-annex.branchable.com/tips/using_box.com_as_a_special_remote/
+3. how do I manually trigger sync with box.com? git fetch box.com neither git annex sync box.com doesn't work.
+
+
+---
+Version: 4.20130501
+Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
diff --git a/doc/forum/Problems_syncing_with_box.com/comment_1_8db642849da4d42cd9a43142e2b7cb70._comment b/doc/forum/Problems_syncing_with_box.com/comment_1_8db642849da4d42cd9a43142e2b7cb70._comment
new file mode 100644
index 0000000000..b60fc03e0c
--- /dev/null
+++ b/doc/forum/Problems_syncing_with_box.com/comment_1_8db642849da4d42cd9a43142e2b7cb70._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-13T17:56:35Z"
+ content="""
+From what you've described, the box.com special remote is the only remote you have connecting your two computers.
+
+But special remotes are only used to transfer the contents of files. They do not have the content of the git repository.
+
+You need to set up a git remote that both computers can access. Or you can use the webapp to set up XMPP to sync between the computers directly. If you start the webapp, it will detect you're missing a git remote, and suggest setting up XMPP. [[/assistant/xmppnudge.png]]
+"""]]
diff --git a/doc/forum/Problems_syncing_with_box.com/comment_2_cd18f33647aebc04af5469e4ce1fbcd2._comment b/doc/forum/Problems_syncing_with_box.com/comment_2_cd18f33647aebc04af5469e4ce1fbcd2._comment
new file mode 100644
index 0000000000..d156622df8
--- /dev/null
+++ b/doc/forum/Problems_syncing_with_box.com/comment_2_cd18f33647aebc04af5469e4ce1fbcd2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="tomas"
+ ip="188.167.111.235"
+ subject="Problems syncing with box.com"
+ date="2013-05-19T19:56:09Z"
+ content="""
+Thanks for the answer Joey.
+My setup is really 2 PCs that are usually not turned on at the same time (usually) and are unable to connect directly (usually). I've dropped box.com because there are bugs. When I sync a file, I see a broken link sometimes. That happens even in situation when the two PCs see each other. Other repos work as expected. So I assume this is a box.com issue. I tried to remove the box repo from both sides, but it is still in 'cleaning out' state even after few days and a lot of daemon restarts. I also have a queue to box. If I delete the transfers, they would appear later. Any way of sorting that out?
+I know that reporting bugs like this is not really efficient. What would be the best way to make it reproducible? E.g. using vagrant and two VMs?
+
+"""]]
diff --git a/doc/forum/Problems_using_blake2_backend.mdwn b/doc/forum/Problems_using_blake2_backend.mdwn
new file mode 100644
index 0000000000..1ffeb1c039
--- /dev/null
+++ b/doc/forum/Problems_using_blake2_backend.mdwn
@@ -0,0 +1,26 @@
+Hello, I'm having some problems using any BLAKE2 backend (tried with BLAKE2B512E, BLAKE2S256E, and BLAKE2SP256E) on an AMD Turion II Neo N40L Dual-Core Processor. Using default, WORM, or SHA3_512E backend works but after switching to a BLAKE2 variant `git annex add` and `git annex migrate` exit with a SIGILL: `add testfile2 error: git-annex died of signal 4`.
+
+## information from coredumpctl
+
+          Signal: 4 (ILL)
+    Command Line: /usr/bin/git-annex add testfile2
+         Message: Process 2481 (git-annex) of user 1000 dumped core.
+                  
+                  Stack trace of thread 2481:
+                  #0  0x00007f0db668e3e6 n/a (libHScryptonite-0.25-5E9EuEAz1M1JrY25iIyNbL-ghc8.6.3.so)
+                  #1  0x00007f0db66901f5 blake2b_final (libHScryptonite-0.25-5E9EuEAz1M1JrY25iIyNbL-ghc8.6.3.so)
+                  #2  0x00007f0db6637950 cryptonitezm0zi25zm5E9EuEAzz1M1JrY25iIyNbL_CryptoziHashziBlake2b_zdfHashAlgorithmBlake2bzu15_info (libHScryptonite-0.25-5E9EuEAz1M1JrY25iIyNbL-ghc8.6.3.so)
+
+## git annex version
+    git-annex version: 7.20181211-g426bdbf11
+    build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+    dependency versions: aws-0.21 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.3 http-client-0.5.14 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+    operating system: linux x86_64
+    supported repository versions: 5 7
+    upgrade supported from repository versions: 0 1 2 3 4 5 6
+    local repository version: 7
+This is the newest version available in the archlinux repository.
+
+I'd really like to use blake2 since it's a lot faster than sha2/3 and safer than WORM. Any idea on how to solve this issue?
diff --git a/doc/forum/Problems_using_blake2_backend/comment_1_f3ffd27a9b515e867041b6cebfeeafad._comment b/doc/forum/Problems_using_blake2_backend/comment_1_f3ffd27a9b515e867041b6cebfeeafad._comment
new file mode 100644
index 0000000000..0516ea4319
--- /dev/null
+++ b/doc/forum/Problems_using_blake2_backend/comment_1_f3ffd27a9b515e867041b6cebfeeafad._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-01-22T21:21:22Z"
+ content="""
+This means that the C implementation of blake2 in the cryptonite library
+is optimised using an instruction not supported by your CPU.
+
+My first guess is it's SSE, which gets enabled when cryptonite is built
+with the `support_sse` build flag. That flag is not enabled by default;
+but perhaps archlinux has enabled it?
+"""]]
diff --git a/doc/forum/Problems_using_submodules_with_git-annex__63__.mdwn b/doc/forum/Problems_using_submodules_with_git-annex__63__.mdwn
new file mode 100644
index 0000000000..39ebe855c1
--- /dev/null
+++ b/doc/forum/Problems_using_submodules_with_git-annex__63__.mdwn
@@ -0,0 +1 @@
+Are there any problems using submodules with git-annex? I have not tried it yet, I'm just asking.
diff --git a/doc/forum/Problems_using_submodules_with_git-annex__63__/comment_1_c7a927736d419d3c31c912001ff16ee4._comment b/doc/forum/Problems_using_submodules_with_git-annex__63__/comment_1_c7a927736d419d3c31c912001ff16ee4._comment
new file mode 100644
index 0000000000..3c2f5addba
--- /dev/null
+++ b/doc/forum/Problems_using_submodules_with_git-annex__63__/comment_1_c7a927736d419d3c31c912001ff16ee4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 1"
+ date="2012-07-05T17:04:34Z"
+ content="""
+I haven't tried it either, but I think it should work ok, as long as you bear in mind that to git-annex, each submodule will be treated as a separate git repository.
+"""]]
diff --git a/doc/forum/Problems_using_submodules_with_git-annex__63__/comment_2_26f6581b5969eb2cb77495c40de88951._comment b/doc/forum/Problems_using_submodules_with_git-annex__63__/comment_2_26f6581b5969eb2cb77495c40de88951._comment
new file mode 100644
index 0000000000..a9e9398341
--- /dev/null
+++ b/doc/forum/Problems_using_submodules_with_git-annex__63__/comment_2_26f6581b5969eb2cb77495c40de88951._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://mildred.fr/"
+ nickname="Mildred"
+ subject="submodules with git-annex in direct mode"
+ date="2014-04-27T14:05:20Z"
+ content="""
+Does this work well even with direct mode ?
+How is this managed in direct mode ?
+
+Coming back from direct mode to indirect mode (required when I want to run git commands) I found that the .gitmodules file was an annex symlink (to .git/annex/objects/...). I just recovered from corrupt repository and may have made mistakes, but is this a risk under normal curcumstances ?
+"""]]
diff --git a/doc/forum/Problems_when_cloning_a_repository.mdwn b/doc/forum/Problems_when_cloning_a_repository.mdwn
new file mode 100644
index 0000000000..374aca26ec
--- /dev/null
+++ b/doc/forum/Problems_when_cloning_a_repository.mdwn
@@ -0,0 +1,22 @@
+Hi,
+
+On a linux server I created a (direct) git annex repository:
+
+    $ ls -a
+    .  ..  apps  attic  devel  games  .git  portable  tools
+
+On a Windows client, I want to check it out:
+
+    me@client /cygdrive/c/tmp
+    $ git clone ssh://me@server/srv/data/bin bin
+    Cloning into 'bin'...
+
+But git annex checks only half of it out :-(
+
+    me@client /cygdrive/c/tmp
+    $ ls -a bin
+    .  ..  .git  attic  games
+
+Any ideas? Sorry, I am very new to git-annex (and git).
+
+Thanks!
diff --git a/doc/forum/Problems_when_cloning_a_repository/comment_1_191c091c384d8d97d24f8a77e8ff90ee._comment b/doc/forum/Problems_when_cloning_a_repository/comment_1_191c091c384d8d97d24f8a77e8ff90ee._comment
new file mode 100644
index 0000000000..bb0d294c76
--- /dev/null
+++ b/doc/forum/Problems_when_cloning_a_repository/comment_1_191c091c384d8d97d24f8a77e8ff90ee._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="178.79.137.64"
+ subject="comment 1"
+ date="2014-05-08T12:50:58Z"
+ content="""
+What files are in the directories that are missing?
+Are they committed into the repository?
+"""]]
diff --git a/doc/forum/Problems_when_cloning_a_repository/comment_2_74ccbb09677444478074e9eab405fbaf._comment b/doc/forum/Problems_when_cloning_a_repository/comment_2_74ccbb09677444478074e9eab405fbaf._comment
new file mode 100644
index 0000000000..5f4ee08f7c
--- /dev/null
+++ b/doc/forum/Problems_when_cloning_a_repository/comment_2_74ccbb09677444478074e9eab405fbaf._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="171.67.174.99"
+ subject="comment 2"
+ date="2014-05-09T01:02:22Z"
+ content="""
+Thanks.
+
+As you can see everything except attic and games is missing.
+
+As far as I understand, yes, they are committed. How can I check?
+On the server I issued
+    git annex add .
+
+\"git annex status\" does not output anything. Remember: I use direct mode.
+"""]]
diff --git a/doc/forum/Problems_when_cloning_a_repository/comment_3_3436e26dd9fe07233a070d4e95d81cdf._comment b/doc/forum/Problems_when_cloning_a_repository/comment_3_3436e26dd9fe07233a070d4e95d81cdf._comment
new file mode 100644
index 0000000000..65470841a5
--- /dev/null
+++ b/doc/forum/Problems_when_cloning_a_repository/comment_3_3436e26dd9fe07233a070d4e95d81cdf._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="171.67.174.99"
+ subject="comment 3"
+ date="2014-05-09T06:06:54Z"
+ content="""
+Finally I found it: https://git-annex.branchable.com/bugs/assistant_doesn__39__t_sync_empty_directories/
+
+Empty directories.
+
+Wow! I was not aware that git is actually a step BACKWARDS in this regard :-(
+
+That was already a big problem half a century ago in CVS, finally fixed in SVN and git re-introduces the issue? Sad :-(
+
+
+"""]]
diff --git a/doc/forum/Problems_with_Assistant_on_Android.mdwn b/doc/forum/Problems_with_Assistant_on_Android.mdwn
new file mode 100644
index 0000000000..74b958b76c
--- /dev/null
+++ b/doc/forum/Problems_with_Assistant_on_Android.mdwn
@@ -0,0 +1 @@
+I try to sync a server and Android device via git annex assistant. I cannot connect to the server on the Android device, however (I can connect via a PC). It seems that ssh is not included in Android and needed by Annex. How can I get ssh/Assistant get working on Android?
diff --git a/doc/forum/Problems_with_FAT_links.mdwn b/doc/forum/Problems_with_FAT_links.mdwn
new file mode 100644
index 0000000000..fb3924a235
--- /dev/null
+++ b/doc/forum/Problems_with_FAT_links.mdwn
@@ -0,0 +1,52 @@
+# The problem:
+
+I use a v5 indirect mode repository in GNU/Linux, and a v5 direct mode repository on an external FAT HDD (that, therefore, cannot use *regular* symlinks).
+The problem is that I am noticing some of those pseudo-symlinks creeping into my indirect mode repository (I'll be calling them *FAT links* for disambiguation, please let me know if they have a proper name [.map files?]).
+
+This gets weird, because my two repositories are sync'ed, but do not act as I would expect.
+
+## Example:
+
+Indirect repository has the following files:
+
+* A (real file)
+* B (symlink)
+* **C (FAT link)** <- trouble maker
+
+Direct repository has these:
+
+* A (FAT link)
+* B (real file)
+* C (real file)
+
+The direct repository seems to be working fine, and in both places files A and B work as expected. But the indirect repository ignores the FAT links. `git status` or `git-annex status` do not see them, nor does `git-annex find`, `git-annex info` or `git-annex whereis`. They all act as if those files were not there.
+
+I thought that maybe if I removed file C, and ran some `git-annex sync`, the repository on my HDD would notify its companion that it had a file called C, and the new correct symlink would be created now that there was no conflict with the file name. So I did a simple `rm C` and one `git-annex sync` on each repository. What happened was that file C got deleted, and I had to dive into the `git-annex unused` to get it back, as it was my only copy of it (I wish there was a way to see the filenames on that output, but I made it!).
+
+I also tried `git-annex fix` on one of these FAT links, but it appears to fall outside of its competences (or it simply does not see the file, like those other commands). `git-annex fsck` skips these files too, BTW.
+
+# Now what?
+
+In total I have several hundreds of files in this situation. Maybe there is some simple or proper way to convert these back into the real symlinks they ought to be. I don't have the time to go into scripting mode to *try* to fix this issue, so I try to gain some guidance from those who know more than I do.
+
+I don't know how these FAT links came about. I did have some problem [like these reported here](https://git-annex.branchable.com/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/). If I recall correctly, in a direct repository in a FAT filesystem, running `git-annex drop FILE && git-annex sync` would replace FILE by a FAT link, and then this error would propagate to the other indirect repository. However, this is not the problem I am experiencing, since the original files are fine.
+Where should I go from here?
+
+I just noticed that `git log` has something to say about these FAT files. Maybe it helps *someone* to trace the origin (I can't decipher git-annex's logs yet). For most files it says this:
+
+    Merge: 71b3d64 8d1afcf
+    Date:   Sun Mar 13 09:53:06 2016 +0000
+        Merge branch 'refs/heads/synced/master' into annex/direct/master
+
+    Date:   Sun Mar 13 09:51:48 2016 +0000
+        git-annex in stratus PC
+
+For two files, it says the following:
+
+    Date:   Tue Aug 9 15:51:32 2016 +0100
+        git-annex in stratus PC
+
+"stratus PC" refers to my indirect repository.
+
+Thank you for your time.
+-- Gus
diff --git a/doc/forum/Problems_with_FAT_links/comment_1_1628c68ef7bdaedb01fcb897a447bb91._comment b/doc/forum/Problems_with_FAT_links/comment_1_1628c68ef7bdaedb01fcb897a447bb91._comment
new file mode 100644
index 0000000000..0054e1f6cc
--- /dev/null
+++ b/doc/forum/Problems_with_FAT_links/comment_1_1628c68ef7bdaedb01fcb897a447bb91._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-10-26T18:18:57Z"
+ content="""
+I don't know what you mean when you say "FAT link". Do you mean it's a
+regular file that contains what looks like the pointer of a symlink?
+"""]]
diff --git a/doc/forum/Problems_with_FAT_links/comment_2_734850345a66d5df38c468ffaa1182cd._comment b/doc/forum/Problems_with_FAT_links/comment_2_734850345a66d5df38c468ffaa1182cd._comment
new file mode 100644
index 0000000000..d726295afe
--- /dev/null
+++ b/doc/forum/Problems_with_FAT_links/comment_2_734850345a66d5df38c468ffaa1182cd._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="Yes"
+ date="2016-10-27T10:28:23Z"
+ content="""
+Exactly, the files that perform the role of symlinks on filsystems that do not support them adequately.
+The files that have only things like
+
+    ../../.git/annex/objects/jF/fq/SHA256E-s496058976--a687727e1b0e7cab74fa160f2dc17d0fbbffcf44939fc44e59f803de21617e19.avi/SHA256E-s496058976--a687727e1b0e7cab74fa160f2dc17d0fbbffcf44939fc44e59f803de21617e19.iso
+
+I do not know the proper name for them. Also, the git-annex standard information:
+
+    git-annex version: 6.20160613-g1e4e6f4
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
+Thank you very much for all your work and dedication to git-annex.
+
+"""]]
diff --git a/doc/forum/Problems_with_FAT_links/comment_3_2728cd609cb5e792d1dc722d450e4c8d._comment b/doc/forum/Problems_with_FAT_links/comment_3_2728cd609cb5e792d1dc722d450e4c8d._comment
new file mode 100644
index 0000000000..ab1e25e28f
--- /dev/null
+++ b/doc/forum/Problems_with_FAT_links/comment_3_2728cd609cb5e792d1dc722d450e4c8d._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="Add more information"
+ date="2016-10-27T12:05:39Z"
+ content="""
+I looked up more information, and this is getting strange. I verified the time of last change for the \"FAT link\" files in my indirect repository. **All** of them say 2016-03-13 11:43:55.3, including the two files that, `git log` says were last manipulated in August 9, and reside in a different area of the repository.
+
+Here is my `git log` has to say about this particular moment:
+
+    commit 2fe1a5834031838563acda9cbdb33ca4c13ec413
+    Date:   Sun Mar 13 11:43:34 2016 +0000
+    
+        git-annex in Toshiba USB HDD
+
+I wish these logs were more descriptive. :-/ If it said the hostname, $PWD and the command line, I could follow along.
+"""]]
diff --git a/doc/forum/Problems_with_FAT_links/comment_4_0a5f0239b3b6376672c8d91eaf68a460._comment b/doc/forum/Problems_with_FAT_links/comment_4_0a5f0239b3b6376672c8d91eaf68a460._comment
new file mode 100644
index 0000000000..02cb830d37
--- /dev/null
+++ b/doc/forum/Problems_with_FAT_links/comment_4_0a5f0239b3b6376672c8d91eaf68a460._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-10-31T18:32:54Z"
+ content="""
+There have been some problems some time ago with the symlink bit getting
+lost on information in the git repository when git-annex makes commits
+on a FAT filesystem.
+
+That was resolved in early 2014, and there's a test case to make sure that
+particular problem doesn't come back, so make sure
+you are not using a git-annex version from before then.
+
+Please check that core.symlinks is set to false. Can check it by running
+`git config core.symlinks` and see if it outputs "false"
+
+I have tried to reproduce on FAT, `git annex drop` followed by `git annex
+sync`, does not seem to do anything to the symlink here. If you can
+reproduce such a thing happening, it's certianly a bug.
+"""]]
diff --git a/doc/forum/Problems_with_FAT_links/comment_5_3c9dd1e2586b27911422066ca71f5298._comment b/doc/forum/Problems_with_FAT_links/comment_5_3c9dd1e2586b27911422066ca71f5298._comment
new file mode 100644
index 0000000000..67f9466567
--- /dev/null
+++ b/doc/forum/Problems_with_FAT_links/comment_5_3c9dd1e2586b27911422066ca71f5298._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="Why overwrite the files?"
+ date="2016-11-03T18:13:54Z"
+ content="""
+Thank you for looking into my problem.
+
+My version of git-annex is recent, and `core.symlinks` is set to *false*. So it must have been something else. I too have not been able to reproduce the error. It seems this problem will remain a mystery for now.
+
+-----
+
+On a related matter, when I `git-annex drop` a file on FAT direct mode, the file is replaced by the symlink-like file. I would like to understand the rational for that. I think that, on the past, `git-annex` may have added that file (or better, *I* may have done so, with a less careful `add`) and replaced the file's contents.
+
+I think that replacing the \"good\" data of a file with something \"useless\" is counter-intuitive, and may trip people. I would expect `git-annex drop` to either remove the file or to leave it alone for manual removal or manipulation.
+
+As you seem quite careful about the possibility of data loss, it seems there is a relevant detail that I am failing to grasp. Even if the \"proper\" way to remove a file in FAT direct mode is to use `rm`, `git-annex drop` does not seem like a bad choice.
+
+Would you mind saying a few words about this, Joey? I feel a bit uneasy without understanding *why* the file is overwritten.
+"""]]
diff --git a/doc/forum/Problems_with_large_numbers_of_files.mdwn b/doc/forum/Problems_with_large_numbers_of_files.mdwn
new file mode 100644
index 0000000000..1dbddd3e28
--- /dev/null
+++ b/doc/forum/Problems_with_large_numbers_of_files.mdwn
@@ -0,0 +1,8 @@
+I'm trying to use git-annex to archive scientific data. I'm often dealing with large numbers of files, sometimes 10k or more. When I try to git-annex add these files I get this error:
+
+
+    Stack space overflow: current size 8388608 bytes.
+    Use `+RTS -Ksize' to increase it.
+
+
+This is with the latest version of git-annex and a current version of git on OS 10.6.7. After this error occurs, I am unable to un-annex the files and I'm forced to recover from a backup. 
diff --git a/doc/forum/Problems_with_large_numbers_of_files/comment_1_08791cb78b982087c2a07316fe3ed46c._comment b/doc/forum/Problems_with_large_numbers_of_files/comment_1_08791cb78b982087c2a07316fe3ed46c._comment
new file mode 100644
index 0000000000..94043a7001
--- /dev/null
+++ b/doc/forum/Problems_with_large_numbers_of_files/comment_1_08791cb78b982087c2a07316fe3ed46c._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2011-04-05T07:27:46Z"
+ content="""
+Heh, cool, I was thinking throwing about 28million files at git-annex. Let me know how it goes, I suspect you have just run into a default limits OSX problem.
+
+You probably just need to up some system limits (you will need to read the error messages that first appear) then do something like
+
+<pre>
+# this is really for the run time, you can set these settings in /etc/sysctl.conf
+sudo sysctl -w kern.maxproc=2048
+sudo sysctl -w kern.maxprocperuid=1024
+
+# tell launchd about having higher limits
+sudo echo \"limit maxfiles 1024 unlimited\" >> /etc/launchd.conf
+sudo echo \"limit maxproc 1024 2048\" >> /etc/launchd.conf
+</pre>
+
+There are other system limits which you can check by doing a \"ulimit -a\", once you make the above changes, you will need to reboot to make the changes take affect. I am unsure if the above will help as it is an example of what I did on 10.6.6 a few months ago to fix some forking issues. From the error you got you will probably need to increase the stacksize to something bigger or even make it unlimited if you feel lucky, the default stacksize on OSX is 8192, try making it say 10times that size first and see what happens.
+"""]]
diff --git a/doc/forum/Problems_with_large_numbers_of_files/comment_2_0392a11219463e40c53bae73c8188b69._comment b/doc/forum/Problems_with_large_numbers_of_files/comment_2_0392a11219463e40c53bae73c8188b69._comment
new file mode 100644
index 0000000000..8ea5531f43
--- /dev/null
+++ b/doc/forum/Problems_with_large_numbers_of_files/comment_2_0392a11219463e40c53bae73c8188b69._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-04-05T17:46:03Z"
+ content="""
+This message comes from ghc's runtime memory manager. Apparently your ghc defaults to limiting the stack to 80 mb.
+Mine seems to limit it slightly higher -- I have seen haskell programs successfully grow as large as 350 mb, although generally not intentionally. :)
+
+Here's how to adjust the limit at runtime, obviously you'd want a larger number:
+
+<pre>
+# git-annex +RTS -K100 -RTS find
+Stack space overflow: current size 100 bytes.
+Use `+RTS -Ksize -RTS' to increase it.
+</pre>
+
+I've tried to avoid git-annex using quantities of memory that scale with the number of files in the repo, and I think in general successfully -- I run it on 32 mb and 128 mb machines, FWIW. There are some tricky cases, and haskell makes it easy to accidentally write code that uses much more memory than would be expected.
+
+One well known case is `git annex unused`, which *has* to build a structure of every annexed file. I have been considering using a bloom filter or something to avoid that.
+
+Another possible case is when running a command like `git annex add`, and passing it a lot of files/directories. Some code tries to preserve the order of your input after passing it through `git ls-files` (which destroys ordering), and to do so it needs to buffer both the input and the result in ram.
+
+It's possible to build git-annex with memory profiling and generate some quite helpful profiling data. Edit the Makefile and add this to GHCFLAGS: `-prof -auto-all -caf-all -fforce-recomp` then when running git-annex, add the parameters: `+RTS -p -RTS` , and look for the git-annex.prof file.
+"""]]
diff --git a/doc/forum/Problems_with_large_numbers_of_files/comment_3_537e9884c1488a7a4bcf131ea63b71f7._comment b/doc/forum/Problems_with_large_numbers_of_files/comment_3_537e9884c1488a7a4bcf131ea63b71f7._comment
new file mode 100644
index 0000000000..8e4101e37e
--- /dev/null
+++ b/doc/forum/Problems_with_large_numbers_of_files/comment_3_537e9884c1488a7a4bcf131ea63b71f7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-04-05T18:02:05Z"
+ content="""
+Oh, you'll need profiling builds of various haskell libraries to build with profiling support. If that's not easily accomplished, if you could show me the form of the command you're running, and also how git annex unannex fails, that would be helpful for investigating.
+"""]]
diff --git a/doc/forum/Problems_with_large_numbers_of_files/comment_4_7cb65d013e72bd2b7e90452079d42ac9._comment b/doc/forum/Problems_with_large_numbers_of_files/comment_4_7cb65d013e72bd2b7e90452079d42ac9._comment
new file mode 100644
index 0000000000..bac9fd7cad
--- /dev/null
+++ b/doc/forum/Problems_with_large_numbers_of_files/comment_4_7cb65d013e72bd2b7e90452079d42ac9._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkhdKAhe3l_UyGt5SdfRBPYVwe-9f8P2dM"
+ nickname="Justin"
+ subject="comment 4"
+ date="2011-04-05T21:14:12Z"
+ content="""
+@joey
+
+OK, I'll try increasing the stack size and see if that helps.
+
+For reference, I was running:
+
+git annex add .
+
+on a directory containing about 100k files spread over many nested subdirectories. I actually have more than a dozen projects like this that I plan to keep in git annex, possibly in separate repositories if necessary. I could probably tar the data and then archive that, but I like the idea of being able to see the structure of my data even though the contents of the files are on a different machine.
+
+After the crash, running:
+
+git annex unannex
+
+does nothing and returns instantly. What exactly is 'git annex add' doing? I know that it's moving files into the key-value store and adding symlinks, but I don't know what else it does.
+
+--Justin
+
+
+
+If 
+
+"""]]
diff --git a/doc/forum/Problems_with_large_numbers_of_files/comment_5_86a42ee3173a5d38f803e64b79496ab3._comment b/doc/forum/Problems_with_large_numbers_of_files/comment_5_86a42ee3173a5d38f803e64b79496ab3._comment
new file mode 100644
index 0000000000..7dcccef2e5
--- /dev/null
+++ b/doc/forum/Problems_with_large_numbers_of_files/comment_5_86a42ee3173a5d38f803e64b79496ab3._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 5"
+ date="2011-04-07T16:41:00Z"
+ content="""
+I think what is happening with \"git annex unannex\" is that \"git annex add\" crashes before it can \"git add\" the symlinks. unannex only looks at files that \"git ls-files\" shows, and so files that are not added to git are not seen. So, this can be recovered from by looking at git status and manually adding the symlinks to git, and then unannex.
+
+That also suggests that \"git annex add .\" has done something before crashing. That's consistent with you passing it < 2 parameters; it's not just running out of memory trying to expand and preserve order of its parameters (like it might if you ran \"git annex add experiment-1/ experiment-2/\")
+
+I'm pretty sure I know where the space leak is now. git-annex builds up a queue of git commands, so that it can run git a minimum number of times. Currently, this queue is only flushed at the end. I had been meaning to work on having it flush the queue periodically to avoid it growing without bounds, and I will prioritize doing that.
+
+(The only other thing that \"git annex add\" does is record location log information.)
+"""]]
diff --git a/doc/forum/Problems_with_large_numbers_of_files/comment_6_4551274288383c9cc27cbf85b122d307._comment b/doc/forum/Problems_with_large_numbers_of_files/comment_6_4551274288383c9cc27cbf85b122d307._comment
new file mode 100644
index 0000000000..fff8f7cdde
--- /dev/null
+++ b/doc/forum/Problems_with_large_numbers_of_files/comment_6_4551274288383c9cc27cbf85b122d307._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 6"
+ date="2011-04-07T18:09:13Z"
+ content="""
+I've committed the queue flush improvements, so it will buffer up to 10240 git actions, and then flush the queue.
+
+There may be other memory leaks at scale (besides the two I mentioned earlier), but this seems promising. I'm well into running `git annex add` on a half million files and it's using 18 mb ram and has flushed the queue several times. This run
+will fail due to running out of inodes for the log files, not due to memory. :)
+"""]]
diff --git a/doc/forum/Problems_with_large_numbers_of_files/comment_7_d18cf944352f8303799c86f2c0354e8e._comment b/doc/forum/Problems_with_large_numbers_of_files/comment_7_d18cf944352f8303799c86f2c0354e8e._comment
new file mode 100644
index 0000000000..7d2ad5eba7
--- /dev/null
+++ b/doc/forum/Problems_with_large_numbers_of_files/comment_7_d18cf944352f8303799c86f2c0354e8e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 7"
+ date="2011-04-08T21:55:36Z"
+ content="""
+http://xfs.org/index.php/XFS_FAQ#Q:_Performance:_mkfs.xfs_-n_size.3D64k_option
+"""]]
diff --git a/doc/forum/Propagate_changes_and_remove_adjusted_branch.mdwn b/doc/forum/Propagate_changes_and_remove_adjusted_branch.mdwn
new file mode 100644
index 0000000000..f4bd813e58
--- /dev/null
+++ b/doc/forum/Propagate_changes_and_remove_adjusted_branch.mdwn
@@ -0,0 +1,55 @@
+*This post is moved from the git-annex-adjust manpage, thanks @joey for the hint on where to put it* 
+
+Adjusted branches are important to my data science project, because my programs cannot deal with the read-only symlinks to annex'ed files.
+
+But I find this command confusing, especially that
+
+1. Calling on an unlocked adjusted branch, `git annex adjust --unlock` propagates commits back to the master branch differently than `git annex sync --no-push --no-pull --no-content` does.
+
+2. I can't find a way to "un-adjust" a branch without resorting to lower-level git commands.
+
+## Problem 1:
+
+Say I have done `git annex adjust --unlock` and then have done more commits. The history now looks like this:
+
+    * My new commit 2  (HEAD -> adjusted/master(unlocked))
+    * My new commit 1  (HEAD -> adjusted/master(unlocked))
+    * git-annex adjusted branch
+    * Last old commit (master, basis/adjusted/master(unlocked))
+    * Previous commits
+
+If I execute now `git annex adjust --unlock` again, the commits are propagated back to the original branch, but my HEAD is still on the original adjusted branch. So both the master branch and my adjusted branch grow over time which clutters the history and is confusing.
+
+    *     My new commit 2  (master)
+    | *   My new commit 2  (HEAD -> adjusted/master(unlocked))
+    * |   My new commit 1
+    | *   My new commit 1
+    | *   git-annex adjusted branch
+    |/
+    * Last old commit (basis/adjusted/master(unlocked))
+    * Previous commits
+
+On the other hand, if I do `git annex sync --no-push --no-pull --no-content`, the commits are propagated back to master, and a new adjusted branch is created on top of that:
+
+    * git-annex adjusted branch (HEAD -> adjusted/master(unlocked))
+    *     My new commit 2  (master, basis/adjusted/master(unlocked))
+    *     My new commit 1
+    | *   My new commit 2  [abandoned old adjusted branch]
+    | *   My new commit 1
+    | *   git-annex adjusted branch
+    |/
+    * Last old commit
+    * Previous commits
+
+This behaviour makes much more sense to me! Why does it take the modified sync command to do this? Why is this not done as well when re-calling `git annex adjust --unlock`? The sync command seems a counter-intuitive place to do this, using the adjust command would be far more intuitive for me and I think also for other users.
+
+## Problem 2
+
+I see no easy way of "un-adjusting" an adjusted branch. Currently I do
+
+    git sync --no-push --no-pull --no-content
+    git checkout master
+    git branch -D "adjusted/master(unlock)" 
+    git branch -D "refs/basis/adjusted/master(unlock)"
+
+That's a lot of text for the inverse operation of `git annex adjust --unlock` and also I have to take care myself to not forget and loose commits I did on the adjusted branch. Did I miss an easier way? If not, I think it would be a great addition.
diff --git a/doc/forum/Propagate_changes_and_remove_adjusted_branch/comment_1_84651b939b10b84df5e685393546732e._comment b/doc/forum/Propagate_changes_and_remove_adjusted_branch/comment_1_84651b939b10b84df5e685393546732e._comment
new file mode 100644
index 0000000000..ddebe6b828
--- /dev/null
+++ b/doc/forum/Propagate_changes_and_remove_adjusted_branch/comment_1_84651b939b10b84df5e685393546732e._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-31T17:21:01Z"
+ content="""
+Re-running `git-annex adjust` when you're already in that adjusted branch
+avoids pulling any changes from the original branch into the branch. It
+only propagates changes you've made back over to the original branch.
+
+Running `git-annex sync` pulls in changes from the original branch before
+propagating commits. That pull happens to result in the git history shape you
+like.
+
+Re-running `git-annex adjust` really only became much of a thing at all
+to support `--hide-missing` and `--unlock-present`, which both make an
+adjusted branch that may need to be updated even without pulling from the
+original branch. I don't think it has much utility in an `--unlock`
+branch. The man page says to use `git-annex sync` before mentioning
+re-running it.
+
+As far as un-adjusting goes, it's basically a matter of `git checkout` of
+the original branch, which is easy enough. The rest of your commands
+involve propagating changes from it back to the original branch, which
+it seems to me someone may or may not want to do, depending on what
+happened to their adjusted branch. I suppose that deleting the basis branch
+ref does argue in favor of making a git-annex command to handle this,
+but it seems to me all that ref is going to do when not deleted is cause a
+small number of git objects to not get gc'd later in an unusual
+circumstance (when the original branch gets rebased).
+"""]]
diff --git a/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn
new file mode 100644
index 0000000000..1f15d66553
--- /dev/null
+++ b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn
@@ -0,0 +1,15 @@
+[Thanks Joey for correcting the docs on `git annex undo --depth`, and thanks for the `git-revert` suggestion as a replacement!](http://git-annex.branchable.com/direct_mode/#comment-b6dcfc80842008e7f9f5b8f612b27867)
+
+**Context: Creating an OSX GUI for assistant managed direct mode repos to help with restoring old file versions.**
+
+I saw this in the `git revert` docs and thought that `git annex proxy -- git checkout annex/direct/master~$depth -- $filename` might best suit my needs of restoring a previous version of a file. (I liked the idea of presenting the user with a depth rather than a hash.)
+
+>Note: git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset[1], particularly the --hard option. If you want to extract specific files as they were in another commit, you should see git-checkout[1], specifically the git checkout -- syntax. Take care with these alternatives as both will discard uncommitted changes in your working directory.
+
+What I've found is that your suggestion of `git revert` is nice because it wouldn't create a conflict, as `git checkout` does. 
+
+So annex, thorough as it is, creates a `$filename.variant-local.$ext` file after the auto conflict resolution to preserve the original. `git revert` is neater, history wise, because there is no conflict as git knows exactly what's changing and from whence it came, rather than just some new file content showing up from who knows where with `git checkout`. 
+
+The issue it seems is that `git revert` works on a commit basis, while `git checkout` can operate on files. If I'm correct in this it would be good to know if annex uses one commit per file, for sure, every time? If this is the case, there would be no problem using the better in most every other way `git revert`.
+
+Though, I'm still not clear how to use the "depth" referencing with `git revert` rather than hashes, any suggestions?
diff --git a/doc/forum/Pruning_out_unwanted_Git_objects.mdwn b/doc/forum/Pruning_out_unwanted_Git_objects.mdwn
new file mode 100644
index 0000000000..36397b2670
--- /dev/null
+++ b/doc/forum/Pruning_out_unwanted_Git_objects.mdwn
@@ -0,0 +1,3 @@
+I have a backups repository with a few files in it, that at one point had some huge filesets erroneously added to it.  As a result, even though there are only 23,334 annexed files, the number of non-dangling Git objects in the repository comes to 593,584.
+
+Normally I would use `git filter-branch` to clear out the deadwood in situations like this, since it is a completely private repository.  What I'm wondering is, is any such thing possible with git-annex, or is the best option just to start over, copy all the files into the new repository, and then `git-add` them all?
diff --git a/doc/forum/Pruning_out_unwanted_Git_objects/comment_1_0cf7a12bfa2957260f4b2f79b0cadf2f._comment b/doc/forum/Pruning_out_unwanted_Git_objects/comment_1_0cf7a12bfa2957260f4b2f79b0cadf2f._comment
new file mode 100644
index 0000000000..fbf538afa5
--- /dev/null
+++ b/doc/forum/Pruning_out_unwanted_Git_objects/comment_1_0cf7a12bfa2957260f4b2f79b0cadf2f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="comment 1"
+ date="2013-08-29T07:23:13Z"
+ content="""
+Maybe one way to solve this that would be general is to have some kind of `prune-history` command, which keeps only the HEAD and drops everything else.  Because there are some repositories that I want to manage with `git-annex` for many reasons, but I don't care about keep history around at all.
+"""]]
diff --git a/doc/forum/Pruning_out_unwanted_Git_objects/comment_2_7472943c02cfe2808b0d566e06caa1a5._comment b/doc/forum/Pruning_out_unwanted_Git_objects/comment_2_7472943c02cfe2808b0d566e06caa1a5._comment
new file mode 100644
index 0000000000..0c26463514
--- /dev/null
+++ b/doc/forum/Pruning_out_unwanted_Git_objects/comment_2_7472943c02cfe2808b0d566e06caa1a5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="comment 2"
+ date="2013-08-30T06:18:42Z"
+ content="""
+This was answered quite thoroughly in:http://git-annex.branchable.com/forum/safely_dropping_git-annex_history/
+"""]]
diff --git a/doc/forum/Pruning_out_unwanted_Git_objects/comment_3_6a1e7a83d94394454fc085f6d2728cd7._comment b/doc/forum/Pruning_out_unwanted_Git_objects/comment_3_6a1e7a83d94394454fc085f6d2728cd7._comment
new file mode 100644
index 0000000000..90951961f3
--- /dev/null
+++ b/doc/forum/Pruning_out_unwanted_Git_objects/comment_3_6a1e7a83d94394454fc085f6d2728cd7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4830:1600:187::2"
+ subject="comment 3"
+ date="2013-09-04T06:36:15Z"
+ content="""
+`git annex forget` automates this now. Needs a version of git-annex supporting it installed on *all* the computers you use the repo on.
+"""]]
diff --git a/doc/forum/Pull_files_through_cloud.mdwn b/doc/forum/Pull_files_through_cloud.mdwn
new file mode 100644
index 0000000000..09d8d663b2
--- /dev/null
+++ b/doc/forum/Pull_files_through_cloud.mdwn
@@ -0,0 +1,10 @@
+I'm not sure if the feature I want exists in git-annex, so this might be a question for the wishlist.
+
+Can I use a cloud server as a middle-man for pulling files from a host that's unreachable at the moment? My situation is:
+  - Desktop, behind cg-nat, can talk to Cloud. Multiple TB of files.
+  - Cloud provider, generally accessible, just a few GB of space.
+  - Notebook, when at home can talk to desktop, on the go can only talk to cloud.
+
+I would like to (in the notebook), request a file to the cloud, and have the cloud pull it from the desktop to be retrieved by the notebook (Or the cloud broker the double-NAT hole punching, but that's much harder).
+
+My current (crude) solution is a script running in the desktop that every few minutes reads a textfile in the cloud with the paths that should be pushed there, so when I need a file in the notebook I add its path to the textfile, and after a few minutes I can sync and pull it from the cloud. But is there a more automated solution?
diff --git a/doc/forum/Pull_files_through_cloud/comment_1_ae71f9876c8376ba0d0ab424bfb66e72._comment b/doc/forum/Pull_files_through_cloud/comment_1_ae71f9876c8376ba0d0ab424bfb66e72._comment
new file mode 100644
index 0000000000..e8e22c91c4
--- /dev/null
+++ b/doc/forum/Pull_files_through_cloud/comment_1_ae71f9876c8376ba0d0ab424bfb66e72._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-08-11T18:25:51Z"
+ content="""
+A better solution is to use [metadata](https://git-annex.branchable.com/git-annex-metadata/). You just tag the files you want in the cloud and for the cloud remote set a preferred-content expression like `metadata=tag=cloud`. And then I think you can just run the [git-annex-assistant] on the desktop and it'll automatically sync the files if metadata for a file changes.
+"""]]
diff --git a/doc/forum/Pull_files_through_cloud/comment_2_f4dfc4b212e23f7443abfb28b5613f63._comment b/doc/forum/Pull_files_through_cloud/comment_2_f4dfc4b212e23f7443abfb28b5613f63._comment
new file mode 100644
index 0000000000..5a2c5e7151
--- /dev/null
+++ b/doc/forum/Pull_files_through_cloud/comment_2_f4dfc4b212e23f7443abfb28b5613f63._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="gabrielhidasy@c3d26e2c0b3e669d012f06736616088b42ad0dbe"
+ nickname="gabrielhidasy"
+ avatar="http://cdn.libravatar.org/avatar/8ae80704e96034c418e126326da2e7c8"
+ subject="Closing the loop"
+ date="2021-09-17T23:56:46Z"
+ content="""
+The metadata solution worked well, except that my cloud remote is unable to run the assistant to pull files from the desktop, and the assistant in the desktop was not pushing. 
+That is fixed by running ```git annex sync --content cloud``` every few minutes in the desktop.
+"""]]
diff --git a/doc/forum/Purge_a_remote.mdwn b/doc/forum/Purge_a_remote.mdwn
new file mode 100644
index 0000000000..f1b04ead2d
--- /dev/null
+++ b/doc/forum/Purge_a_remote.mdwn
@@ -0,0 +1,2 @@
+How could I delete and purge a remote? I want to remove all traces of it
+but I can't find out how to achieve this.
diff --git a/doc/forum/Purge_a_remote/comment_1_78b3b77f457c65d31fd8a5abf714905d._comment b/doc/forum/Purge_a_remote/comment_1_78b3b77f457c65d31fd8a5abf714905d._comment
new file mode 100644
index 0000000000..a7eff3a99c
--- /dev/null
+++ b/doc/forum/Purge_a_remote/comment_1_78b3b77f457c65d31fd8a5abf714905d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-05T16:17:22Z"
+ content="""
+In the git-annex webapp, each repository has a settings menu with \"delete repository\".
+"""]]
diff --git a/doc/forum/Purge_a_remote/comment_2_dc65719157dee63b3979563ed57ee0ce._comment b/doc/forum/Purge_a_remote/comment_2_dc65719157dee63b3979563ed57ee0ce._comment
new file mode 100644
index 0000000000..86827c529a
--- /dev/null
+++ b/doc/forum/Purge_a_remote/comment_2_dc65719157dee63b3979563ed57ee0ce._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw"
+ nickname="dxtrish"
+ subject="comment 2"
+ date="2013-11-05T17:46:02Z"
+ content="""
+When I use that Delete button it seems to still have records of it
+because when I delete the repo on the other end and create a new bare
+one it complains about some UUID mismatch.
+"""]]
diff --git a/doc/forum/Purge_a_remote/comment_3_63e0280273b816fa4b837724e102f813._comment b/doc/forum/Purge_a_remote/comment_3_63e0280273b816fa4b837724e102f813._comment
new file mode 100644
index 0000000000..621bda5085
--- /dev/null
+++ b/doc/forum/Purge_a_remote/comment_3_63e0280273b816fa4b837724e102f813._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 3"
+ date="2013-11-05T18:03:26Z"
+ content="""
+Hmm well, it's true that deleting a repository does not clean out any git remotes that other repositories might have configured using it, and the uuid of the old remote is cached in there. This is only a problem if you put back another repository in the same location as the old one. `git remote remove` should clean that up for you.
+"""]]
diff --git a/doc/forum/Purge_a_remote/comment_4_7fad1c4798ca03a4095ac3241c279f6d._comment b/doc/forum/Purge_a_remote/comment_4_7fad1c4798ca03a4095ac3241c279f6d._comment
new file mode 100644
index 0000000000..afb4dc92e3
--- /dev/null
+++ b/doc/forum/Purge_a_remote/comment_4_7fad1c4798ca03a4095ac3241c279f6d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw"
+ nickname="dxtrish"
+ subject="comment 4"
+ date="2013-11-06T14:24:21Z"
+ content="""
+That is exactly what I have wanted to do a couple of times now and 'git remote remove' does not seem to remove it all either.
+When I try to create a new repository in the same place it still complains about that darn UUID :)
+
+What is working is to manually add the new UUID to .git/config
+"""]]
diff --git a/doc/forum/Purge_whereis.mdwn b/doc/forum/Purge_whereis.mdwn
new file mode 100644
index 0000000000..d5b614898b
--- /dev/null
+++ b/doc/forum/Purge_whereis.mdwn
@@ -0,0 +1,9 @@
+Hey there,
+
+I am playing around with git-annex to handle my files and backup's. Sometimes, I wish to delete a file entirely from my local repo and any other repo that contains the file.
+
+First, I drop the file from my local repo and run git-annex sync --content. Then I run git annex whereis and drop the file from other repo's. Subsequently, I run git annex whereis to ensure that the file has been dropped and does not exist in any repo.
+
+However, git annex still tracks the file, but I just have 0 copies of it. How do I remove/delete/disable tracking of a single file or multiple files?
+
+The reason why I have deleted the file is that I don't want it in any of my repo's any longer. 
diff --git a/doc/forum/Purge_whereis/comment_1_89d2446e3c9a58ab7b2a85ff941f7c8d._comment b/doc/forum/Purge_whereis/comment_1_89d2446e3c9a58ab7b2a85ff941f7c8d._comment
new file mode 100644
index 0000000000..848d1b75bb
--- /dev/null
+++ b/doc/forum/Purge_whereis/comment_1_89d2446e3c9a58ab7b2a85ff941f7c8d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="cbaines"
+ subject="comment 1"
+ date="2015-12-21T12:32:55Z"
+ content="""
+If you want to stop tracking a file, just delete it, and then run git annex sync.
+
+There are some other commands (and settings in the assistant) for managing unused content. That is, files in the annex that are no longer referenced/used.
+"""]]
diff --git a/doc/forum/Purge_whereis/comment_2_0307ce47de9b719adc2096600d94dff6._comment b/doc/forum/Purge_whereis/comment_2_0307ce47de9b719adc2096600d94dff6._comment
new file mode 100644
index 0000000000..66e7bd6f15
--- /dev/null
+++ b/doc/forum/Purge_whereis/comment_2_0307ce47de9b719adc2096600d94dff6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="frost.kristian@75a6b6a25121f985cd8708f98c691d41716ac720"
+ nickname="frost.kristian"
+ subject="comment 2"
+ date="2015-12-21T13:08:49Z"
+ content="""
+It seems I have to enable syncing from the webapp. I thought doing git annex sync would do the same?
+"""]]
diff --git a/doc/forum/Purge_whereis/comment_3_e87b53ebbf8053bb17caeb2aed871212._comment b/doc/forum/Purge_whereis/comment_3_e87b53ebbf8053bb17caeb2aed871212._comment
new file mode 100644
index 0000000000..bdfe711f22
--- /dev/null
+++ b/doc/forum/Purge_whereis/comment_3_e87b53ebbf8053bb17caeb2aed871212._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="cbaines"
+ subject="comment 3"
+ date="2015-12-21T13:33:34Z"
+ content="""
+I just did a quick test, running git annex sync does commit the removal of files for me.
+"""]]
diff --git a/doc/forum/Purge_whereis/comment_4_72b6c28d8a4865ad8c84b1f7dfefb78a._comment b/doc/forum/Purge_whereis/comment_4_72b6c28d8a4865ad8c84b1f7dfefb78a._comment
new file mode 100644
index 0000000000..0e0cab11ce
--- /dev/null
+++ b/doc/forum/Purge_whereis/comment_4_72b6c28d8a4865ad8c84b1f7dfefb78a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="frost.kristian@75a6b6a25121f985cd8708f98c691d41716ac720"
+ nickname="frost.kristian"
+ subject="comment 4"
+ date="2015-12-21T17:47:13Z"
+ content="""
+I did some digging. When creating a repo from the webapp, it is per default in direct mode. In direct mode, I am not able to run any git commands such as git commit. Subsequently, when running git annex sync. Files added when sync is disabled from the webapp are not committed.
+
+Is git-annex behaving as expected here?
+"""]]
diff --git a/doc/forum/Purge_whereis/comment_5_966e0285639a41ee9db3e9fb337e2699._comment b/doc/forum/Purge_whereis/comment_5_966e0285639a41ee9db3e9fb337e2699._comment
new file mode 100644
index 0000000000..7dbe3d3a9a
--- /dev/null
+++ b/doc/forum/Purge_whereis/comment_5_966e0285639a41ee9db3e9fb337e2699._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-01-01T20:35:18Z"
+ content="""
+Described behavior sounds right to me. If you've clicked on "syncing
+enabled" in the webapp for the local repository, so it's changed to
+"syncing disabled" then the webapp won't automatically commit file
+deletions/adds. Click on it again and it'll catch up with any changes you
+made while it was disabled.
+"""]]
diff --git a/doc/forum/Push__47__Pull_with_the_Assistant.mdwn b/doc/forum/Push__47__Pull_with_the_Assistant.mdwn
new file mode 100644
index 0000000000..315ad38d85
--- /dev/null
+++ b/doc/forum/Push__47__Pull_with_the_Assistant.mdwn
@@ -0,0 +1 @@
+If I use git-annex with a centralized bare git repository as [described here](http://git-annex.branchable.com/tips/centralized_git_repository_tutorial/), will the Assistant automatically `git push` and `git pull` the master and git-annex branches? Or does it basically just do a `git annex sync`?
diff --git a/doc/forum/Push__47__Pull_with_the_Assistant/comment_1_f7b63d379c2d21794adf8658f546f8a7._comment b/doc/forum/Push__47__Pull_with_the_Assistant/comment_1_f7b63d379c2d21794adf8658f546f8a7._comment
new file mode 100644
index 0000000000..0477218bc6
--- /dev/null
+++ b/doc/forum/Push__47__Pull_with_the_Assistant/comment_1_f7b63d379c2d21794adf8658f546f8a7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.11.120"
+ subject="comment 1"
+ date="2012-11-17T20:25:03Z"
+ content="""
+The assistant will push, pull, and merge the master and git-annex branches (which is exactly what git annex sync does). 
+
+Additionally, the assistant will transfer file contents to the bare repository, either to make it have a copy of everything, or as needed to transfer to other repositories that also use that bare repository. This behavior is configurable using the webapp.
+"""]]
diff --git a/doc/forum/Push__47__Pull_with_the_Assistant/comment_2_aec8cc20576e7ffd5a8be4348d1a0073._comment b/doc/forum/Push__47__Pull_with_the_Assistant/comment_2_aec8cc20576e7ffd5a8be4348d1a0073._comment
new file mode 100644
index 0000000000..20be4c6ce3
--- /dev/null
+++ b/doc/forum/Push__47__Pull_with_the_Assistant/comment_2_aec8cc20576e7ffd5a8be4348d1a0073._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="annexuser"
+ ip="85.159.236.214"
+ subject="comment 2"
+ date="2012-11-17T20:44:53Z"
+ content="""
+When I make a change in the repository and run a plain old `git annex sync`, it pushes out to any other available annex, but not to my bare hub. If I run `git annex sync` a second time it tells me that I'm ahead of the hub:
+
+    commit
+    # On branch master
+    # Your branch is ahead of 'hub/master' by 1 commit.
+    #
+    nothing to commit, working directory clean
+    ok
+
+In order to push the changes out to the hub I have to do `git push --all`.
+
+The same thing with pulling. If I make a change on the annex, push it to the hub, and then go to a second annex that knows about the hub but not the first annex, a `git annex sync` does not pull the changes in from the hub. I have to do `git pull` to get them.
+
+Do I have something setup incorrectly?
+"""]]
diff --git a/doc/forum/Pusher_crashed__44___attempt_to_repair_hangs__44___broken_symlinks.mdwn b/doc/forum/Pusher_crashed__44___attempt_to_repair_hangs__44___broken_symlinks.mdwn
new file mode 100644
index 0000000000..4c1bcc129b
--- /dev/null
+++ b/doc/forum/Pusher_crashed__44___attempt_to_repair_hangs__44___broken_symlinks.mdwn
@@ -0,0 +1,77 @@
+Sorry that I put all this in the same thread but I don't know what happened and how it is related.
+
+I have just a simple setup: git-annex client with assistant (Windows 7) and on a server (Debian, no assistant).
+
+Suddenly weird things started to happen
+
+1.) On Windows, when I start the assistant, it writes "Attempting to repair THINKTANK:c:\data\annex [here]" but it runs forever and never stops
+
+2.) On Windows, when I get "Pusher crashed: failed to read sha from git write-tree [Restart Thread]". When I click "Restart Thread" nothing happens but the message from (1) persists.
+
+3.) When I run "git annex fsck" on the client I get thousands of messages like
+
+    fsck Fotos/2014/DSC_0303.JPG
+      ** No known copies exist of Fotos/2014/DSC_0303.JPG
+    failed
+
+Here the same:
+
+    $ git annex whereis "Fotos/2014/DSC_0303.JPG"
+    whereis Fotos/2014/DSC_0303.JPG (0 copies) failed
+    git-annex: whereis: 1 failed
+
+4.) When I do "git annex status" a whole bunch of files are displayed with "M" (modified) although they are not, they are not even checked out and should be only at the server ...
+
+5.) On the server, files that should ALWAYS be on the server (configured as "full backup") suddenly wiped data that was also made available on the client. The symlinks are dangling symlinks and contain just binary data:
+
+    ls -l
+    lrwxrwxrwx  1 4 Aug  2 08:55 DSC_0011.JPG -> ????
+    lrwxrwxrwx  1 4 Aug  2 08:55 DSC_0012.JPG -> ????
+    lrwxrwxrwx  1 4 Aug  2 08:55 DSC_0013.JPG -> ????
+    lrwxrwxrwx  1 4 Aug  2 08:55 DSC_0014.JPG -> ????
+    lrwxrwxrwx  1 4 Aug  2 08:55 DSC_0015.JPG -> ????
+    lrwxrwxrwx  1 4 Aug  2 08:55 DSC_0018.JPG -> ????
+    lrwxrwxrwx  1 4 Aug  2 08:55 DSC_0019.JPG -> ????
+    lrwxrwxrwx  1 4 Aug  2 08:55 DSC_0020.JPG -> ????
+
+6.) "git annex fsck" on the server is still successful, returning no errors!
+
+7.) Manually executing "git annex sync --content" on both sides does not change anything and does not output any error messages.
+
+8.) On the client:
+
+    $ git annex group here
+    error: invalid object 100644 3b3767ae65e5c6d2e3835af3d55fbf2f9e145c8b for '000/0e6/SHA256Es193806--b6d4689fba8e15acd6497f9a7e584c93ea0c8c2199ad32eadac79d59b9f49814.JPG.log'
+    fatal: git-write-tree: error building trees
+    manual
+    (Recording state in git...)
+    git-annex: failed to read sha from git write-tree
+
+    $ git annex wanted here
+    error: invalid object 100644 3b3767ae65e5c6d2e3835af3d55fbf2f9e145c8b for '000/0e6/SHA256Es193806--b6d4689fba8e15acd6497f9a7e584c93ea0c8c2199ad32eadac79d59b9f49814.JPG.log'
+    fatal: git-write-tree: error building trees
+    exclude="*" and present
+    git-annex: failed to read sha from git write-tree
+
+9.) Ok I don't know what happened I did nothing special but it seems that the repository is broken :( :(
+
+    $ git annex --verbose --debug repair
+    [...]
+    [2014-08-02 13:27:38 Pacific Daylight Time] read: git ["--git-dir=C:\\Data\\annex\\.git","--work-tree=C:\\Data\\annex","-c","core.bare=false","show","ef3fe549f457783dbbd877b467b4e54b0ebc813c"]
+    Running git fsck ...
+    
+    git-annex: DeleteFile "C:\\Data\\annex\\.git\\objects\\2a\\54bb281c80c91ea7a732c0d48db0c5acc0ca2c": permission denied (Access is denied.)
+    failed
+    git-annex: repair: 1 failed
+
+But this file exists, I can read, write and delete to this file manually, there is definitely no permission denied ...
+
+
+
+Oh no, so desparate :-( Any ideas?
+
+As it seems the client repository is broken but how can it be then that also files on the server repository get deleted which shouldn't be deleted?
+And how can it be that there are not only broken symlinks but symlinks that have just binary garbage as target and "fsck" returns success?
+
+(I am happy to share all log files privately but I do not want to publish them here because they contain sensitive data)
+
diff --git a/doc/forum/Pusher_crashed__44___attempt_to_repair_hangs__44___broken_symlinks/comment_1_c89b64b0dc7c5a760a84a9d2cfd8982c._comment b/doc/forum/Pusher_crashed__44___attempt_to_repair_hangs__44___broken_symlinks/comment_1_c89b64b0dc7c5a760a84a9d2cfd8982c._comment
new file mode 100644
index 0000000000..38bd4daf8c
--- /dev/null
+++ b/doc/forum/Pusher_crashed__44___attempt_to_repair_hangs__44___broken_symlinks/comment_1_c89b64b0dc7c5a760a84a9d2cfd8982c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="128.12.90.218"
+ subject="comment 1"
+ date="2014-09-12T02:47:37Z"
+ content="""
+I try it once again - any hints for me?
+I haven't done anything since then because I do not know how to proceed here (except creating everything new from scratch).
+
+Is more information needed? If yes, what?
+"""]]
diff --git a/doc/forum/Pusher_crashed__44___attempt_to_repair_hangs__44___broken_symlinks/comment_2_c511691c4ea6c77e63ef85c28c921be9._comment b/doc/forum/Pusher_crashed__44___attempt_to_repair_hangs__44___broken_symlinks/comment_2_c511691c4ea6c77e63ef85c28c921be9._comment
new file mode 100644
index 0000000000..3ca5ec6d2c
--- /dev/null
+++ b/doc/forum/Pusher_crashed__44___attempt_to_repair_hangs__44___broken_symlinks/comment_2_c511691c4ea6c77e63ef85c28c921be9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-02-09T20:56:15Z"
+ content="""
+You see "-> ???" for symlink targets, and you are unable to delete
+files that you own, and git is unable to read objects that should be in the
+repository.
+
+This all suggests that your disk is broken. You need to check your
+filesystem for corruption, etc.
+"""]]
diff --git a/doc/forum/Pushing_an_existing_git_annex_repo_to_a_remote_ssh_host.mdwn b/doc/forum/Pushing_an_existing_git_annex_repo_to_a_remote_ssh_host.mdwn
new file mode 100644
index 0000000000..f453c59e29
--- /dev/null
+++ b/doc/forum/Pushing_an_existing_git_annex_repo_to_a_remote_ssh_host.mdwn
@@ -0,0 +1 @@
+I have an existing repo on my local machine, with a mirror that I sync on the flash drive as well, using a remote, as described in the walkthrough. I'd like to create another repo on my remote server and have that work as a mirror as well, using ssh and rsync too. The only resources I've found regarding creating a remote over ssh imply that the repo is already on the host, is this a necessary step in creating a ssh remote? I was thinking in the terms of creating a git annex repository, adding a remote, then pushing it much like how git works, yet I can't find anything like that in the documentation.
diff --git a/doc/forum/Pushing_an_existing_git_annex_repo_to_a_remote_ssh_host/comment_1_4008b735809161d5950b7991d69d3f68._comment b/doc/forum/Pushing_an_existing_git_annex_repo_to_a_remote_ssh_host/comment_1_4008b735809161d5950b7991d69d3f68._comment
new file mode 100644
index 0000000000..90a212f360
--- /dev/null
+++ b/doc/forum/Pushing_an_existing_git_annex_repo_to_a_remote_ssh_host/comment_1_4008b735809161d5950b7991d69d3f68._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-10-03T17:16:34Z"
+ content="""
+It works just like git works, since a git-annex repository is a git
+repository. Set up the git repository on the remote host and then add it as
+a remote.
+
+In order for git-annex to be able to store the content of annexed files on
+the remote host, git-annex will need to be installed on that host.
+"""]]
diff --git a/doc/forum/Pushing_git_repo_to_AWS_S3_from_behind_proxy.mdwn b/doc/forum/Pushing_git_repo_to_AWS_S3_from_behind_proxy.mdwn
new file mode 100644
index 0000000000..03676502ba
--- /dev/null
+++ b/doc/forum/Pushing_git_repo_to_AWS_S3_from_behind_proxy.mdwn
@@ -0,0 +1,9 @@
+I want to setup my remote git repo on S3
+Referred to
+http://git-annex.branchable.com/tips/using_Amazon_S3/
+http://git-annex.branchable.com/special_remotes/S3/
+
+I need support for AWS.config param proxy_uri
+http://docs.amazonwebservices.com/AWSRubySDK/latest/AWS.html
+
+Can some one help?
diff --git a/doc/forum/Question__58___git-annex-only_repo___63__.mdwn b/doc/forum/Question__58___git-annex-only_repo___63__.mdwn
new file mode 100644
index 0000000000..e6b5ab6636
--- /dev/null
+++ b/doc/forum/Question__58___git-annex-only_repo___63__.mdwn
@@ -0,0 +1,3 @@
+Is there a way to declare (init) a git-annex-only repository?
+
+I mean if the repository will only contain large (or maybe binary) files without any source-code... In that case all files added to the repo should be managed by git-annex automatically. Is this currently possible?
diff --git a/doc/forum/Question__58___git-annex-only_repo___63__/comment_10_ada27f7b8c7dc3c388e6c56ef095e682._comment b/doc/forum/Question__58___git-annex-only_repo___63__/comment_10_ada27f7b8c7dc3c388e6c56ef095e682._comment
new file mode 100644
index 0000000000..b0fe83dd62
--- /dev/null
+++ b/doc/forum/Question__58___git-annex-only_repo___63__/comment_10_ada27f7b8c7dc3c388e6c56ef095e682._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="boustanihani@93604388a6a2b8df16f3e34157232801a67c1021"
+ nickname="boustanihani"
+ subject="comment 10"
+ date="2015-07-06T22:00:36Z"
+ content="""
+Thanks :) Just one last question, how what happens when 2 users edit the same file in parallel, how does git-annex deal with this by default? Does the newer one overwrite the old one or do we get some info like \"unable to auto-merge\"...
+"""]]
diff --git a/doc/forum/Question__58___git-annex-only_repo___63__/comment_11_531e6a091c8d005626e4e8290ba317d7._comment b/doc/forum/Question__58___git-annex-only_repo___63__/comment_11_531e6a091c8d005626e4e8290ba317d7._comment
new file mode 100644
index 0000000000..7f485a418f
--- /dev/null
+++ b/doc/forum/Question__58___git-annex-only_repo___63__/comment_11_531e6a091c8d005626e4e8290ba317d7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2015-07-06T22:13:24Z"
+ content="""
+If using git-annex sync or git-annex merge to do the merging, it will
+automatically resolve the merge conflict and put both conflicting versions
+of the file in the tree under different filenames.
+
+Of course, you can also use regular git commands to pull and merge your
+master branch; then you'd get a regular git merge conflict.
+"""]]
diff --git a/doc/forum/Question__58___git-annex-only_repo___63__/comment_1_321632cc794c00181932f5737db9aff0._comment b/doc/forum/Question__58___git-annex-only_repo___63__/comment_1_321632cc794c00181932f5737db9aff0._comment
new file mode 100644
index 0000000000..b69abb3bdf
--- /dev/null
+++ b/doc/forum/Question__58___git-annex-only_repo___63__/comment_1_321632cc794c00181932f5737db9aff0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="Yes"
+ date="2015-06-23T12:12:52Z"
+ content="""
+Yes, you can do this. Simply set up a git annex repo and you are ready to go.
+If you have the assistant running in the background it will take care of committing and distributing the files around.
+"""]]
diff --git a/doc/forum/Question__58___git-annex-only_repo___63__/comment_2_941b62a63c11caa1ada5d544c2e926ca._comment b/doc/forum/Question__58___git-annex-only_repo___63__/comment_2_941b62a63c11caa1ada5d544c2e926ca._comment
new file mode 100644
index 0000000000..fdde45be61
--- /dev/null
+++ b/doc/forum/Question__58___git-annex-only_repo___63__/comment_2_941b62a63c11caa1ada5d544c2e926ca._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="boustanihani@93604388a6a2b8df16f3e34157232801a67c1021"
+ nickname="boustanihani"
+ subject="comment 2"
+ date="2015-06-23T12:42:46Z"
+ content="""
+you mean there is no need for track then ?
+"""]]
diff --git a/doc/forum/Question__58___git-annex-only_repo___63__/comment_3_0c0dad1ffa11f2f8708906d310a189db._comment b/doc/forum/Question__58___git-annex-only_repo___63__/comment_3_0c0dad1ffa11f2f8708906d310a189db._comment
new file mode 100644
index 0000000000..d61393dc8f
--- /dev/null
+++ b/doc/forum/Question__58___git-annex-only_repo___63__/comment_3_0c0dad1ffa11f2f8708906d310a189db._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="comment 3"
+ date="2015-06-24T07:23:28Z"
+ content="""
+What do you mean by track?
+
+If you are using the assistant, it will take care for you. It will add, commit and distribute files.
+
+If you are using the command line without the assistant, you should have a look at the [[walkthrough]]. You can play around with repositories in /tmp before you push all your important data into it ;)
+"""]]
diff --git a/doc/forum/Question__58___git-annex-only_repo___63__/comment_4_426160c2237db790b133b9c9f0abd4b2._comment b/doc/forum/Question__58___git-annex-only_repo___63__/comment_4_426160c2237db790b133b9c9f0abd4b2._comment
new file mode 100644
index 0000000000..ff771d16cc
--- /dev/null
+++ b/doc/forum/Question__58___git-annex-only_repo___63__/comment_4_426160c2237db790b133b9c9f0abd4b2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="boustanihani@93604388a6a2b8df16f3e34157232801a67c1021"
+ nickname="boustanihani"
+ subject="comment 4"
+ date="2015-06-24T10:14:18Z"
+ content="""
+Thanks I'll take a look at git-annex assistant, all new to me :)
+
+Never mind about track, I thought git-annex is similar to git-lfs where you should manually call \"track...\" on files whose content should not be added to git...
+"""]]
diff --git a/doc/forum/Question__58___git-annex-only_repo___63__/comment_5_36bd0a398b385e65df7eda26fa5c50d0._comment b/doc/forum/Question__58___git-annex-only_repo___63__/comment_5_36bd0a398b385e65df7eda26fa5c50d0._comment
new file mode 100644
index 0000000000..fe9c9714f8
--- /dev/null
+++ b/doc/forum/Question__58___git-annex-only_repo___63__/comment_5_36bd0a398b385e65df7eda26fa5c50d0._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 5"
+ date="2015-06-24T12:14:02Z"
+ content="""
+you are correct. \"git add\" *will* add a file into git directly. \"git annex add\" is like \"git track\"...
+"""]]
diff --git a/doc/forum/Question__58___git-annex-only_repo___63__/comment_6_32fb6930bcaac36d00b088d8ee09face._comment b/doc/forum/Question__58___git-annex-only_repo___63__/comment_6_32fb6930bcaac36d00b088d8ee09face._comment
new file mode 100644
index 0000000000..ce10012ee9
--- /dev/null
+++ b/doc/forum/Question__58___git-annex-only_repo___63__/comment_6_32fb6930bcaac36d00b088d8ee09face._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="boustanihani@93604388a6a2b8df16f3e34157232801a67c1021"
+ nickname="boustanihani"
+ subject="comment 6"
+ date="2015-06-24T14:06:35Z"
+ content="""
+cool thanks :)
+
+Is it also possible to version control large binary files using git-annex assistant ??
+
+I mean to be able to switch back to earlier versions when needed...
+
+Is there something like a way to specify how  many older versions should be kept in the repo? This would be a nice feature for preserving disk space...
+"""]]
diff --git a/doc/forum/Question__58___git-annex-only_repo___63__/comment_7_8278ee493da14aac86e928d2349d8173._comment b/doc/forum/Question__58___git-annex-only_repo___63__/comment_7_8278ee493da14aac86e928d2349d8173._comment
new file mode 100644
index 0000000000..56aae7d1d3
--- /dev/null
+++ b/doc/forum/Question__58___git-annex-only_repo___63__/comment_7_8278ee493da14aac86e928d2349d8173._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="somewhat"
+ date="2015-06-24T16:28:42Z"
+ content="""
+git-annex doesn't deliberately keep all versions of the files. however, if you change a file (using [[git-annex-edit]]), it will keep the old copy, which will become [[walkthrough/unused_data/]]. that data will be purged by the assistant after a while (if configured to do so) but you can also archive it, etc... 
+
+so in a way, yes, it is versionned, but the unused data is somewhat more 'brittle' than the current dataset.
+"""]]
diff --git a/doc/forum/Question__58___git-annex-only_repo___63__/comment_8_3e24c9f9042d6abdafaae45015645b11._comment b/doc/forum/Question__58___git-annex-only_repo___63__/comment_8_3e24c9f9042d6abdafaae45015645b11._comment
new file mode 100644
index 0000000000..0011ebb203
--- /dev/null
+++ b/doc/forum/Question__58___git-annex-only_repo___63__/comment_8_3e24c9f9042d6abdafaae45015645b11._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="boustanihani@93604388a6a2b8df16f3e34157232801a67c1021"
+ nickname="boustanihani"
+ subject="comment 8"
+ date="2015-06-25T21:13:01Z"
+ content="""
+Is it possible to force git-annex to keep all versions for some or all files??
+
+Or (maybe better) specify how many old versions to keep (for example keep the last 20 versions or so...) ?
+"""]]
diff --git a/doc/forum/Question__58___git-annex-only_repo___63__/comment_9_182c66e98086dbfde29b615d0cf0e8e4._comment b/doc/forum/Question__58___git-annex-only_repo___63__/comment_9_182c66e98086dbfde29b615d0cf0e8e4._comment
new file mode 100644
index 0000000000..b9432bb03c
--- /dev/null
+++ b/doc/forum/Question__58___git-annex-only_repo___63__/comment_9_182c66e98086dbfde29b615d0cf0e8e4._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2015-07-06T18:47:23Z"
+ content="""
+If you use indirect mode, and avoid passing --force to any git-annex
+commands, then git-annex will ensure that it always keeps all versions of
+all files.
+
+Any command that would delete any data requires the --force option.
+
+If your repo uses direct mode, we can't make this guarantee, because
+the files are left directly in your work tree and you can edit or delete
+them manually and there's nothing git-annex can do to stop that.
+
+There is not currently a way to keep a particular number of old versions of
+a file. This comes down to picking the versions to keep or drop when
+running `git annex dropunused` (with --force of course).
+"""]]
diff --git a/doc/forum/Questions_about_borg_special_remotes.mdwn b/doc/forum/Questions_about_borg_special_remotes.mdwn
new file mode 100644
index 0000000000..f36b5df8d5
--- /dev/null
+++ b/doc/forum/Questions_about_borg_special_remotes.mdwn
@@ -0,0 +1,12 @@
+This is a fantastic improvement and one I'm eager to put to use. But are there specific requirements not outlined in the manpages or tips thread?
+
+I'm having mixed success so far, but after my tribulations on an Apple Silicon machine I'm inclined to suspect the macOS environment (though on an Intel machine this time). 
+
+Early tests on an experimental repo worked fine: I backed up my git annex repo using the Vorta GUI and initiated the special remote, pointing to the borg repo, which was not encrypted. Everything worked as expected, including syncing and manually dropping unused files.
+
+Doing the same thing on my real repo, with an existing *encrypted* borg repo, I get stuck being repeatedly asked for my passphrase. Looking at the debug info, after accepting my passphrase git annex seems to go through every existing archive one at a time, outputting stuff like this but not doing much:
+`[2021-05-18 13:33:36.703495] (Utility.Process) process [50690] read: borg ["list","--format","{size}{NUL}{path}{NUL}{extra}{NUL}",`
+
+I created a new archive with borg directly from the command line, too, but no change. borg seems to be doing its thing, locking the repo with each requested iteration.
+
+Also, the syntax in the example on the tips page may not be entirely correct, AFAICT.
diff --git a/doc/forum/Questions_about_borg_special_remotes/comment_1_bbeb30671d707f2a1d7ac0dbf342136e._comment b/doc/forum/Questions_about_borg_special_remotes/comment_1_bbeb30671d707f2a1d7ac0dbf342136e._comment
new file mode 100644
index 0000000000..771e323465
--- /dev/null
+++ b/doc/forum/Questions_about_borg_special_remotes/comment_1_bbeb30671d707f2a1d7ac0dbf342136e._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-05-21T15:50:59Z"
+ content="""
+git-annex lets borg do whatever passphrase prompting it needs,
+and git-annex necessarily needs to run borg more than once, to scan all
+archives that it has not scanned before for annexed content. Also,
+getting files from a borg repository involves running borg once per file. 
+So using it with a repo with a passphrase will probably be
+inconvenient, unless you use `BORG_PASSPHRASE` or `BORG_PASSCOMMAND`.
+
+If there was a good way for git-annex to know if borg would need a
+passphrase, it could prompt for it a single time and provide it to borg,
+but I don't know if there's a good way to ask borg if a repository needs a
+passphrase. The only half-decent way I can find is to try to do something
+like `BORG_PASSPHRASE=wrong borg info` and see if it fails due to the wrong
+passphrase, or works due to not needing a passphrase.
+
+> Also, the syntax in the example on the tips page may not be entirely correct, AFAICT.
+
+Please be more specific.
+"""]]
diff --git a/doc/forum/Questions_about_borg_special_remotes/comment_2_5c10ff05b8e1714aa9b413d6b01e275e._comment b/doc/forum/Questions_about_borg_special_remotes/comment_2_5c10ff05b8e1714aa9b413d6b01e275e._comment
new file mode 100644
index 0000000000..21d578a14a
--- /dev/null
+++ b/doc/forum/Questions_about_borg_special_remotes/comment_2_5c10ff05b8e1714aa9b413d6b01e275e._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 2"
+ date="2021-05-22T05:16:44Z"
+ content="""
+Well, that certainly explains it. Not only that, it makes perfect sense. The borg repo in question has about a hundred archives so I soon grew tired. ```BORG_PASSPHRASE``` seems obvious in retrospect, of course the GUI does that for me in my day-to-day use.
+
+Trying to use some of the really clever combinations on offer is challenging to a novice user. I sometimes feel like my ambition is to be a half-decent conductor, only I'm periodically also expected to step down and tune the harpsichord. Mind you, this isn't criticism – it's one of the principles that makes git-annex so great. borg is a solo performer, adding it to the ensemble is my choice and making it blend well with the rest of the instruments is up to me.
+
+On third, careful look, I don't believe there's any error on the tips page.
+
+Thanks!
+
+
+"""]]
diff --git a/doc/forum/Reappearing_repos_in_webapp_and_vicfg.mdwn b/doc/forum/Reappearing_repos_in_webapp_and_vicfg.mdwn
new file mode 100644
index 0000000000..41a64630d4
--- /dev/null
+++ b/doc/forum/Reappearing_repos_in_webapp_and_vicfg.mdwn
@@ -0,0 +1,43 @@
+Hi,
+
+Whenever I do a git annex vicfg (as pasted below) the long gone repo 40da403e-6f74-4705-aae0-433aa656b55e keeps automatically being added back into the configuration.  Worse in the webapp this manifests itself as a repository list item that's empty of text (and when buttons are clicked there's a complaint about missing UUIDs).
+
+In addition to removing the lines via git-annex vicfg, I've switched my repository into indirect mode, manually checked out the the git-annex branch and deleted the offending key from the preferred content and group files (it oddly didn't appear in the uuid file).  However they keep coming back :-(
+
+Everything seems to be okay bar this rogue entry which in the web-app irrationally bothers me.
+
+I'm running the very latest git-annex release.
+
+Any thoughts?
+
+Cheers,
+
+Matt.
+
+
+    # git-annex configuration
+    #
+    # Changes saved to this file will be recorded in the git-annex branch.
+    #
+    # Lines in this file have the format:
+    #   setting uuid = value
+    
+    # Repository trust configuration
+    # (Valid trust levels: trusted semitrusted untrusted dead)
+    # (for mattford63 (matt@descartes.rss.mhs.man.ac.uk:~/current))
+    trust 88733342-45ef-420f-8f1b-9a5ed8d8e070 = semitrusted
+    
+    # Repository groups
+    # (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted)
+    # (Separate group names with spaces)
+    # (for )
+    group 40da403e-6f74-4705-aae0-433aa656b55e = client
+    # (for mattford63 (matt@descartes.rss.mhs.man.ac.uk:~/current))
+    group 88733342-45ef-420f-8f1b-9a5ed8d8e070 = client
+
+    # Repository preferred contents
+    # (for )
+    content 40da403e-6f74-4705-aae0-433aa656b55e = standard
+    # (for mattford63 (matt@descartes.rss.mhs.man.ac.uk:~/current))
+    content 88733342-45ef-420f-8f1b-9a5ed8d8e070 = standard
+    
diff --git a/doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_1_bd977e864ae89816fa7f4ff69879b15f._comment b/doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_1_bd977e864ae89816fa7f4ff69879b15f._comment
new file mode 100644
index 0000000000..983dd8478c
--- /dev/null
+++ b/doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_1_bd977e864ae89816fa7f4ff69879b15f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 1"
+ date="2013-07-02T16:56:42Z"
+ content="""
+Run: `git annex dead 40da403e-6f74-4705-aae0-433aa656b55e`
+"""]]
diff --git a/doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_2_05749f9e75689d0111339b7126c12300._comment b/doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_2_05749f9e75689d0111339b7126c12300._comment
new file mode 100644
index 0000000000..bd56c6670a
--- /dev/null
+++ b/doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_2_05749f9e75689d0111339b7126c12300._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
+ nickname="Matt"
+ subject="comment 2"
+ date="2013-07-02T19:48:19Z"
+ content="""
+Hi,
+
+I should have mentioned I can't do this either:
+
+    ~/current $ git annex dead 40da403e-6f74-4705-aae0-433aa656b55e
+    dead 40da403e-6f74-4705-aae0-433aa656b55e git-annex: there is no available git remote named \"40da403e-6f74-4705-aae0-433aa656b55e\"
+
+I can't quite remember how I removed the remote - it was a whilst back, I think maybe I just edited it out of the git config file....
+"""]]
diff --git a/doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_3_b1531994eea0fbbf4cb097e604378a53._comment b/doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_3_b1531994eea0fbbf4cb097e604378a53._comment
new file mode 100644
index 0000000000..a079e3b123
--- /dev/null
+++ b/doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_3_b1531994eea0fbbf4cb097e604378a53._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 3"
+ date="2013-07-02T19:58:30Z"
+ content="""
+It seems that the uuid is present in the group.log and preferred-content.log files in the git-annex branch, but not in the uuid.log file. I missed that in your description before. That's weird, don't know how that could happen.
+
+However, when I manually configure things this way, I do not see the repository in the webapp. Which makes sense; uuid.log is the canonical list of repositories.
+
+I guess if I were you I'd manually edit the uuid into uuid.log and then mark it dead.
+"""]]
diff --git a/doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_4_f1eba3e8aa4116e3c20747ec1d6e24e5._comment b/doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_4_f1eba3e8aa4116e3c20747ec1d6e24e5._comment
new file mode 100644
index 0000000000..6c5e8835e8
--- /dev/null
+++ b/doc/forum/Reappearing_repos_in_webapp_and_vicfg/comment_4_f1eba3e8aa4116e3c20747ec1d6e24e5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
+ nickname="Matt"
+ subject="comment 4"
+ date="2013-07-02T20:45:29Z"
+ content="""
+I tried as you suggested.  It worked as far in so far that I was able to mark the repository dead.  However, I still see an empty line in the web app so perhaps this odd repo isn't the cause (but I'm deeply suspicious of it).  Looking at the HTML source the line in the web-app does not have any UUID at all (see the screen shot [here](http://dancingfrog.hopto.org/~matt/git-annex.png)).
+
+What causes the code to add back a previously deleted repository (I vaguely remember something about this being due to the merge algorithm...and why one can only mark repos as deleted)?  Why would it only add back to the group and trust logs and not the UUID?  The code that generates the web-app HTML must use something else or things in addition to the UUID log?
+
+The logs don't really say much - how can I help debug this further?
+"""]]
diff --git a/doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo.mdwn b/doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo.mdwn
new file mode 100644
index 0000000000..990f939cbe
--- /dev/null
+++ b/doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo.mdwn
@@ -0,0 +1,46 @@
+Hello,
+
+I am currently testing out git-annex (git-annex version: 10.20220223-ge37f0f227)*. I like it a lot, but have one question,
+(I'll try to keep it succinct)
+
+Sample setup:
+
+- main repo (untrusted, manual group) --> Small drive, contains only currently needed files.
+- multiple remote archive repo's (trusted, archive group) --> (two for this test)
+- numcopies=2
+
+So far works as expected (two copies created in archives)
+
+Situation: I replace a couple of the oldest archive drives each year. (or one may fail)
+
+- drive to remove is marked dead + unwanted (as per the tips/help)
+- new drive is added (clone repo etc.)
+- fsck correctly identifies files as missing a copy, files locally available are copied to the new archive, other files are however not copied from another archive drive (which is connected and availabe).
+
+  doing:
+
+	- git annex copy --auto --from=data2
+	- git annex copy --auto --to=data4	// (this part is prolly not needed with assistant)
+
+  does work, but does an unnecessary copy to the main repo first, also note that in the real situation this drive won't be large enough to keep all the files, so would need a lot of to-and-fro'ing (and also needs cleanup afterwards).
+  
+I solved it** (for now) by converting the archives from raw to full repo's + adding the other archive to its remotes so a direct copy can be done (ie. git annex copy --auto / sync --content directly from the archive drive).
+- tedious but doable.
+
+
+Maybe I'm missing something? or I am doing it wrong? :-)
+If not: it would be nice if this worked irrespective of files being available locally, or to be able to do:
+	
+- git annex copy --auto --from=data2 --to=data4
+
+this way the separate archives do not need to be converted, and everything can be done from the central repo.
+(I prefer the archives being raw repo's, they shouldn't be messed with)
+
+Suggestions?
+
+Thanks
+KachoOji
+
+
+"* upgraded from v8 from debian repo
+ ** You could also clone the drive (dd), but that won't work if it failed.
diff --git a/doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/comment_1_901272a6f738bfe8a0289c4900fd0c20._comment b/doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/comment_1_901272a6f738bfe8a0289c4900fd0c20._comment
new file mode 100644
index 0000000000..03582311a5
--- /dev/null
+++ b/doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/comment_1_901272a6f738bfe8a0289c4900fd0c20._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="transitive transfers"
+ date="2022-04-22T17:01:13Z"
+ content="""
+Past discussions of this: [[todo/transitive_transfers]].
+"""]]
diff --git a/doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/comment_2_aec1d16cb47b59dd4f2811b2956e5fdf._comment b/doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/comment_2_aec1d16cb47b59dd4f2811b2956e5fdf._comment
new file mode 100644
index 0000000000..5d0f76da8a
--- /dev/null
+++ b/doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/comment_2_aec1d16cb47b59dd4f2811b2956e5fdf._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="tanakaoji@cd5ba49c38f0a3b42b7e7bf56c4379d9024cd840"
+ nickname="tanakaoji"
+ avatar="http://cdn.libravatar.org/avatar/ccc61e285ed2498e328a131b13cfe712"
+ subject="comment 2"
+ date="2022-04-22T20:39:30Z"
+ content="""
+Ah, thank you for the link, I did skim the forum, but did not come across it.
+
+I don't replace drives daily, so it's not that big of a problem, just a nice to have.
+Currently I'm managing my data archive/backups manually, so it will already be a lot more efficient :-)
+
+"""]]
diff --git a/doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/comment_3_652d9957ead7dbf4feb3ba096137d22b._comment b/doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/comment_3_652d9957ead7dbf4feb3ba096137d22b._comment
new file mode 100644
index 0000000000..b1563feaed
--- /dev/null
+++ b/doc/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/comment_3_652d9957ead7dbf4feb3ba096137d22b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2022-04-25T17:12:19Z"
+ content="""
+`git annex sync/copy/move` also works in bare repos. But you'll definitely need to add the archive drives as remotes of each other.
+"""]]
diff --git a/doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__.mdwn b/doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__.mdwn
new file mode 100644
index 0000000000..975746526b
--- /dev/null
+++ b/doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__.mdwn
@@ -0,0 +1,69 @@
+# Situation/trouble
+
+I have a set of big repos.  Each full replica manages about 172.000 annexed files plus a number of small regular files in git history, for a total of about 1.8TB. At filesystem level, `find` reports about 924.000 entries (directories, files, symlinks).
+
+That worked rather well for a while except that a number of operations are slow (even outside git-annex, e.g. a plain `find` takes more than our hour the first time).  Also, the git part got rather heavy.  Hundreds of megabytes that should have been annexed were committed as regular files and vice versa.
+
+The whole setup even survived some catastrophe rather well, for example 6 months ago when the first 1.5GB of one hard drive was accidentally overwritten.  `fsck` with an alternate superblock fixed the lower level, while `git annex repair` fixed the rest nicely.
+
+Last night, though, the git parts got corrupted and I'm struggling to get things back to a sane state.  `git log` shows only recent history then fails.  Various attempts with `git annex repair` failed so far, I'll try again adding a new local "bare" git clone of the server as remote for `git annex repair` to use.
+
+Storage media and filesystems seem sane, still.  Software has been unchanged for a long time:
+
+* client run Ubuntu 16.04 with locally compiled git-annex version: 6.20161001-gade6ab4
+* server runs with locally compiled (in a Debian unstable chroot) git-annex version: 6.20161011-g3135d35 .
+
+
+# Considered solution
+
+I'm considering:
+
+* recreating a new set of replicas
+* each replica on same filesystem as old one
+* recreated only from the checked-out tree and the `.git/annex.objects` tree.
+* *without* copying data (re-reading on import is okay, but no room on a 2TB disk for duplicating 1.8TB)
+* non-constraint: this will lose detailed history which is an inconvenience we can live with.
+
+# Solution, practically
+
+## (1) Assuming `git annex fsck` can take into account objects manually placed into `.git/annex/objects`
+
+	mkdir $newrepo
+	cd $newrepo
+	git init
+	git annex init
+	cp -al $oldrepo/* $newrepo/ # ignores .git and other .* (dotfiles)
+	cp -al $oldrepo/.git/annex/objects/* $newrepo/.git/annex/objects/*
+	git annex fsck # will this find and use result of cp ?
+	# git annex fsck will also tell if some checked-out files lack their annexed data
+	git remote add ...(other replicas)...
+	git annex sync ...(other replicas)...
+	git annex unused # will tell if some files don't appear in checked-out tree?
+
+## (2) Else...
+
+	mkdir $newrepo
+	cd $newrepo
+	git init
+	git annex init
+	cp -al $oldrepo/* $newrepo/ # ignores .git and other .* (dotfiles)
+	cp -al $oldrepo/.git/annex/objects/* ${newrepo}.objectdup
+	git annex reinject --known ${newrepo}.objectdup  # will that perform a copy? I must not in this case.
+	# or something like find "${newrepo}.objectdup" -type f -exec git annex reinject --known {} \;
+	git annex fsck # will tell if some checked-out files lack their annexed data
+	git remote add ...(other replicas)...
+	git annex sync ...(other replicas)...
+	# if some files in $oldrepo/.git/annex/objects/* don't appear in checked-out tree, the won't be picked up by reinject and remain in ${newrepo}.objectdup
+
+# Questions
+
+No one wins when a lot of time is spent on dead ends. :-) Before I
+spend time testing if solutions 1 and 2 can work, is there any caveat
+to mention?
+
+For example, perhaps one must clone from a common empty ancestor
+instead of creating independent annexed then sync?
+
+What else? Is the whole approach sane? Doomed? Anything simpler/better?
+
+Thanks a lot.
diff --git a/doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__/comment_1_456772b5b0deb0c121d7feb5dcf41979._comment b/doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__/comment_1_456772b5b0deb0c121d7feb5dcf41979._comment
new file mode 100644
index 0000000000..a6389d995d
--- /dev/null
+++ b/doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__/comment_1_456772b5b0deb0c121d7feb5dcf41979._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2017-07-21T09:25:25Z"
+ content="""
+My solution is very roundabout but preserves a lot of information, but did involve buying another drive (and exclusively using v5 indirect mode!).
+
+I create a new repository (on the new drive) which I import all the contents of the \"keyfiles\" (contents of .git/annex/objects). Then I create another repository with the filelinks (symlinks pointing to .git/annex/objects). After adding the keyfiles remote to this, this lets me see which content is present and valid, which got corrupted, is missing etc.
+
+Then I can move the valid content from this recovery annex into a proper annex and try and repair/find the corrupted/missing.
+"""]]
diff --git a/doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__/comment_2_410f329fb47f13afc59b5b37b88a8c3a._comment b/doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__/comment_2_410f329fb47f13afc59b5b37b88a8c3a._comment
new file mode 100644
index 0000000000..fc76a02c24
--- /dev/null
+++ b/doc/forum/Rebuild_a_set_of_repos_from_checked-out_trees_and_.git__47__annex__47__objects__63__/comment_2_410f329fb47f13afc59b5b37b88a8c3a._comment
@@ -0,0 +1,84 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Indeed git annex fsck can take into account objects manually placed into .git/annex/objects"
+ date="2017-07-28T05:03:30Z"
+ content="""
+Thanks @CandyAngel.  This is similar to wat I'm doing and somehow validates.
+I'm trying to repair on the same filesystem without long recopy.
+I don't understand why your solution is specific to v5 indirect mode.
+
+# Indeed git annex `fsck` can take into account objects manually placed into `.git/annex/objects`.
+
+Let's create a repo:
+
+    mkdir repo1
+    cd repo1/
+    ls -al
+    git init
+    git annex init repo1
+    ls -a
+    ls -al
+    echo 1 > 1
+    git annex add 1
+    git annex sync
+
+    git annex fsck
+    git annex repair --verbose
+
+Everything is fine.
+
+Let's say this repo has its git structures broken and we rebuild it from checked-out tree and `.git/annex/objects`.  We'll lose tree history and location tracking history but recover content.
+
+    cd ..
+    mkdir repo2
+    cd repo2
+    git init
+    git annex init repo2
+
+Ok we have an empty repo.  Let's import tree.
+
+    cp -al ../repo1/* .
+    ls -al
+    git annex add .
+    git annex repair --verbose
+
+    Running git fsck ...
+    No problems found.
+    ok
+
+Notice that `git annex repair` does not care about annexed objects, only history data.
+
+    git annex fsck
+
+But `fsck` notices about missing objects.
+
+    fsck 1
+      ** No known copies exist of 1
+    failed
+    (recording state in git...)
+    git-annex: fsck: 1 failed
+
+So, in a sense, `git annex fsck` and `git annex repair` operate on nearly independent things.
+
+Let's get annexed objects back.
+
+    ls -al # red shows symlink is broken
+    cp -al ../repo1/.git/annex/objects/ .git/annex/
+    find .git/annex/objects/
+    ls -al # grey shows symlink is okay
+    git annex fsck
+
+Hooray, `fsck` notices that objects are back.
+
+    fsck 1 (fixing location log) (checksum...) ok
+    (recording state in git...)
+
+# Conclusion
+
+I can use approach (1).  Extra benefit: it will notice if some files got corrupted on the filesystem.
+
+Approach (2) would mean, if any file was corrupted on the filesystem, it would have been considered the correct content, and I'd prefer to avoid that.
+
+"""]]
diff --git a/doc/forum/RecentChanges__58___link_to_the_diff__63__.mdwn b/doc/forum/RecentChanges__58___link_to_the_diff__63__.mdwn
new file mode 100644
index 0000000000..6c15de14e1
--- /dev/null
+++ b/doc/forum/RecentChanges__58___link_to_the_diff__63__.mdwn
@@ -0,0 +1 @@
+In the RecentChanges page on the forum, it'd be good to have a link to the diff for the change, in addition to the existing link to the changed page.
diff --git a/doc/forum/RecentChanges__58___link_to_the_diff__63__/comment_1_85254a327ffed22b407d25610558c15b._comment b/doc/forum/RecentChanges__58___link_to_the_diff__63__/comment_1_85254a327ffed22b407d25610558c15b._comment
new file mode 100644
index 0000000000..4d209148ae
--- /dev/null
+++ b/doc/forum/RecentChanges__58___link_to_the_diff__63__/comment_1_85254a327ffed22b407d25610558c15b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2019-01-15T08:30:10Z"
+ content="""
+There already is one. It's right before the link to the page (has 3D glasses image).
+
+    <span class=\"pagelinks\">
+      <a href=\"http://source.git-annex.branchable.com/?p=source.git;a=blobdiff;f=doc/forum/RecentChanges__58___link_to_the_diff__63__.mdwn;h=6c15de14e1b020c43bd11132726d62942ab96f42;hp=0000000000000000000000000000000000000000;hb=27cf71e7e4b1a8e556000375c96bc30bc1b8fae7;hpb=9953e3d3530aa48cd26dd3e69fd81488f83164a9\" title=\"diff\" rel=\"nofollow\">
+        <img src=\"../wikiicons/diff.png\" alt=\"diff\">
+      </a>
+      <a href=\"/ikiwiki.cgi?do=goto&amp;page=forum%2FRecentChanges__58___link_to_the_diff__63__\" rel=\"nofollow\">forum/RecentChanges: link to the diff?</a>
+    </span>
+"""]]
diff --git a/doc/forum/Recomended_Setup_for_Syncthing_Remote.mdwn b/doc/forum/Recomended_Setup_for_Syncthing_Remote.mdwn
new file mode 100644
index 0000000000..56ace65c32
--- /dev/null
+++ b/doc/forum/Recomended_Setup_for_Syncthing_Remote.mdwn
@@ -0,0 +1,5 @@
+Hello!
+
+&nbsp;&nbsp;&nbsp;&nbsp; So with Android 10, Syncthing may be facing some issues regarding where we can put our files on the device. However, the Syncthing-Fork from the Google Play store has granular control over when sync tasks can run, which I very much require; I was thinking of combining git-annex and Syncthing by syncing the `.git/annex/objects` directory, but I am still *very* new to this. Can anyone advise me what the best setup would be for the procedure, according to [`syncthing special remote`](https://git-annex.branchable.com/todo/syncthing_special_remote/)?
+
+&nbsp;&nbsp;&nbsp;&nbsp; Thank you kindly for the help!
diff --git a/doc/forum/Recommended_number_of_repositories.mdwn b/doc/forum/Recommended_number_of_repositories.mdwn
new file mode 100644
index 0000000000..9e9f2838d6
--- /dev/null
+++ b/doc/forum/Recommended_number_of_repositories.mdwn
@@ -0,0 +1,4 @@
+With git it is easy to create one repository per project, and it almost always makes sense to do so.  When using git-annex, what is the recommended setup?
+
+Should one have a single annex containing all files, or is it recommended to create different repositories for things like 'photos', 'music', 'isos' ?
+
diff --git a/doc/forum/Recommended_number_of_repositories/comment_1_3ef256230756be8a9679b107cdbfd018._comment b/doc/forum/Recommended_number_of_repositories/comment_1_3ef256230756be8a9679b107cdbfd018._comment
new file mode 100644
index 0000000000..46ce0e8d53
--- /dev/null
+++ b/doc/forum/Recommended_number_of_repositories/comment_1_3ef256230756be8a9679b107cdbfd018._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="depends ..."
+ date="2011-11-04T19:59:24Z"
+ content="""
+It makes sense to have separate repositories when you have well-defined uses for them. 
+
+I have a separate repository just for music and podcasts, which I can put various places where I have no need of the overhead of a tree of other files.
+
+If you're using it for whatever arbitrary large files you accumulate, I find it's useful to have them in one repository. This way I can rearrange things as makes sense. It might make sense to have \"photos\" and \"isos\" as categories today, but next year you might prefer to move those under 2011/{photos,isos}. It would certainly make sense to have different repositories for home, work, etc.
+
+How to split repositories up for a home directory is a general problem that the [vcs-home](http://vcs-home.branchable.com)
+project has surely considered at one time or another.
+"""]]
diff --git a/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes.mdwn b/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes.mdwn
new file mode 100644
index 0000000000..f6aebafd67
--- /dev/null
+++ b/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes.mdwn
@@ -0,0 +1,8 @@
+Hi,
+I'm still wrapping my head around various aspects of the relationship between git and git-annex in everyday use.
+
+I have a set of files whose original filenames I want to keep, but only very rarely work with. That is, the everyday, "normal" use for these files will happen with the filenames changed. I want to have the watcher running in this repository, handling syncing with remotes, changes in filenames and directory structure etc.
+
+How would you set this up? A shared clone (not sure I fully get how that works), a separate branch for the original filenames that is checked out when needed (i.e. everyday changes are committed to master) or something else?
+
+Many thanks!  
diff --git a/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_1_ec1c86e41ce3ee243df9a5008db87070._comment b/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_1_ec1c86e41ce3ee243df9a5008db87070._comment
new file mode 100644
index 0000000000..decd65cd1d
--- /dev/null
+++ b/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_1_ec1c86e41ce3ee243df9a5008db87070._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2019-04-16T13:10:03Z"
+ content="""
+Depends on how often and what \"work\" is done with the original filenames. Can you explain more what you are trying to do?
+
+Perhaps you can use metadata/metadata views.. though this would give you the original filename as a directory, containing a file with the current filename. e.g. ~/annex/originalfilename.txt/currentfilename.txt
+"""]]
diff --git a/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_2_47b248b36146c5ad9986b69c8d212b4e._comment b/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_2_47b248b36146c5ad9986b69c8d212b4e._comment
new file mode 100644
index 0000000000..e9713bb32f
--- /dev/null
+++ b/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_2_47b248b36146c5ad9986b69c8d212b4e._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 2"
+ date="2019-04-16T15:12:57Z"
+ content="""
+Thanks for your reply.
+
+One example is when working with scanned images and digitized sound recordings:
+
+The original file names [`unmodified`] are needed to source which analog original they are paired with in an archival system beyond my control, but as I manually work with these files, the structure changes to [`modified`], which I'd like to be the repo's default state. So when new data arrives (via a remote) new files should be checked into the [`unmodified`] state with their original file names, and then be worked on in the [`modified`] state. I'd like this [`unmodified`] state to be singular, as opposed to checking out a specific commit for a specific subset of files.
+
+Another, perhaps simpler, example is music files:
+They come in various combinations of file and folder names as they are ripped from CD or downloaded. I'd like an external program (beets) to handle organizing these files (the symlinks, really) into a folder structure, as I need them to be presented in a particular way to an indexer/player, i.e. as [`modified`]. So again, I'd like to ingest (from a remote) into git-annex using the original file names (if needed at a later point) while still letting beets move things around structurally. At some point in time, I'd like to be able to easily hop back to my music library in its [`unmodified`] state without having to find the particular point in time when I added that particular subset.
+
+I'm trying to achieve this with as little manual massaging as possible.
+
+Metadata and views are a great option to have, but from what I understand not the right fit here.
+
+This was long but I hope it made some sense.
+"""]]
diff --git a/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_3_47951337fa2155b797b40fe19446ef51._comment b/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_3_47951337fa2155b797b40fe19446ef51._comment
new file mode 100644
index 0000000000..843fb9013e
--- /dev/null
+++ b/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_3_47951337fa2155b797b40fe19446ef51._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-05-07T15:15:10Z"
+ content="""
+It seems to me that what you are describing is fundamentally a branch,
+call it "orig". Whenever you add a new file, you do so in a repository
+with the orig branch checked out. Then you `git merge orig` into a
+repository with the master branch checked out, and get on with renaming the
+files.
+
+I would be wary of changing the branch that is checked out when the
+git-annex watcher/assistant is running as that might confuse it. I would
+probably just make a separate clone of the repository that has the orig
+branch checked out all the time, do the imports into there, and then 
+`git annex move` the file contents over to the main repository.
+"""]]
diff --git a/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_4_12ae880e559bde5f75cb0c451b56b322._comment b/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_4_12ae880e559bde5f75cb0c451b56b322._comment
new file mode 100644
index 0000000000..f1598d157b
--- /dev/null
+++ b/doc/forum/Recommended_way_to_work_with_semi-permanent_filename_changes/comment_4_12ae880e559bde5f75cb0c451b56b322._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 4"
+ date="2019-05-08T17:23:24Z"
+ content="""
+Thanks for answering, Joey. I was basically arriving at this. With the number of files and folders I'm dealing with, keeping the branches separated does seem to make the most sense. For less involved scenarios, having imported into \"orig\", a simple `git checkout orig /path/to/file` from master does the trick nicely.
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck.mdwn b/doc/forum/Recover_files__44___annex_stuck.mdwn
new file mode 100644
index 0000000000..b3e46471f8
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck.mdwn
@@ -0,0 +1,28 @@
+I have a directory with 6TB of data in it. I tried to use git annex to back it up to three 3TB drives, I didn't want to use RAID as it sucks, and I didn't want to use tar as I wanted my files easily available.
+
+I added my remotes successfully, then I ran ``git annex add .``
+
+That mostly worked, although it understandably took ages, although it missed several GB of files here and there.
+
+Next I tried to do ``git commit -a -m added``, hoping that this would copy all of my files to the remotes.  It didn't it just died with the error 
+
+    fatal: No HEAD commit to compare with (yet)
+    fatal: No HEAD commit to compare with (yet)
+    Stack space overflow: current size 8388608 bytes.
+    Use `+RTS -Ksize -RTS' to increase it.
+
+So I freaked out and decided to undo the mess and just go with tar instead, since at this point every git command takes multiple minutes and fails with the same error as above.
+
+I tried to run ``git anne unannex .``, but I got this error:
+
+``
+unannex GWAS/by-download-number/27081.log.gz fatal: No HEAD commit to compare with (yet)
+``
+
+So now I can't do anything without committing the files it seems, and I somehow need to grow the git cache, although when I search online for `+RTS -Ksize -RTS', I get nothing. 
+
+Does anyone know how to increase the cache size, or how to unannex the files without this HEAD error?
+
+Thanks,
+
+Mike
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_10_6d85c3ec73ddc0682d9643f4d5eeda70._comment b/doc/forum/Recover_files__44___annex_stuck/comment_10_6d85c3ec73ddc0682d9643f4d5eeda70._comment
new file mode 100644
index 0000000000..1a8cca6009
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_10_6d85c3ec73ddc0682d9643f4d5eeda70._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="comment 10"
+ date="2014-06-18T20:15:42Z"
+ content="""
+``git ls-files --cached | wc -l`` returns: 1882028
+
+As far as I can tell, the largest objects in .git/objects are 65kb, there are just a bunch of them (257). Also, my repo contains 1,886,125 files and directories total, most in a single directory (after git annex add completed, that one directory contained 8.3GB of symlinks.
+
+``git-annex add .`` just completed successfully, I am now running ``git commit -a -m added``, it is chugging away and taking its time.
+
+Is there an obvious upper limit to the number of files or the total size of files that git annex can handle? For example, is 1 million files too many? How about 6TB? or 9TB? For this repo I think I have a little less than 2m files, and the total size of the repo is greater than 6TB. Is that too much? Should I split it into multiple repos?
+
+I also have a question just about the utility of git-annex for this purpose. I don't need to backup this data, I just want to have it off the big hard drive and onto a bunch of small drives. I have added 3 4TB drives as remotes and I want all of the data stored on them, I will take them offline and put them in a safe. Ideally my file and directory structure will remain intact as symlinks, and then when I want to access a file in the future, I can run ``git annex get <file>``, connect the drive that git annex tells me to, and then get that file, use it, and then drop it when I am done. From all of my reading it seems like that is a good usage for git annex, but I want to check with you and see if that makes sense to you. Also, can I just run ``git annex drop --auto --numcopies=1``  to get git annex to move all of the files to my remote repositories?
+
+Thanks for all of your help, and let me know if there are any other debug steps you would like me to run. I am still waiting for git commit to run, and for an exact repo size for you.
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_11_52e799bb6f24a1ebed58fad6cebd3a71._comment b/doc/forum/Recover_files__44___annex_stuck/comment_11_52e799bb6f24a1ebed58fad6cebd3a71._comment
new file mode 100644
index 0000000000..d5fc3e7ae6
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_11_52e799bb6f24a1ebed58fad6cebd3a71._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.203"
+ subject="comment 11"
+ date="2014-06-18T20:54:31Z"
+ content="""
+Ok, my suspicion is that the root problem is having a large number of file in a single directory. That would cause the git tree objects to get big, and it may 
+be that git-annex somewhere buffers a whole tree object in memory, although I cannot think of where off the top of my head.
+
+git-annex scales to any size of files (limited only by checksumming time unless you use the WORM backend to avoid checksumming). git-annex tries to scale at least as good as git does to a large quantity of files in a repository. git doesn't handle a million files in a repository very fast, due to a number of issues including how the index works. I have never tested git-annex with more than 1 million files, and not all in the same directory.
+
+Other than the number of files, your use case seems reasonable. `git annex drop` will drop files that you have already copied to enough of the remotes (using eg, `git-annex copy`).
+
+Above you show a git-annex add failing after 5 files. I suspect you truncated that output, and it processed rather more files. git-annex only says \"(Recording state in git...)\" once it's added all the files, or after it's added around 10 thousand files and still has more to do). It seems to have failed at the point where the files are staged into the index.
+
+I'm building a 2 million file in one directory repo on a fast server now to see if I can reproduce this.
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_12_686a285bc7e950aae67856c47e7cb21e._comment b/doc/forum/Recover_files__44___annex_stuck/comment_12_686a285bc7e950aae67856c47e7cb21e._comment
new file mode 100644
index 0000000000..0428dfd309
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_12_686a285bc7e950aae67856c47e7cb21e._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="comment 12"
+ date="2014-06-18T22:28:27Z"
+ content="""
+Yes, you are right. ``git-annex add`` got through almost all of the files in the first run, which I did a week ago, I am not sure how long it took, several days I think (which is fine, time isn't that important here).
+
+I re-ran ``git-annex add .`` yesterday after having trouble with ``git commit``, which is when I uncovered these problems. I think you are right that the problem appears when git-annex is staging files into the index. No problems occurred during checksumming or moving files.
+
+Also, the repo isn't as large as I thought, it if 4.1TB, so it makes sense that the issue is number of files, not files size.
+
+``git add`` and ``git commit`` are now working fine, all git operations (e.g. ``git status``) are now taking around 30s to 1 min, which is acceptable. 
+
+I am going to try and move the data to the remotes now. Is there anything special I need to do since the remotes are smaller than the current repo? The remotes are just single drives with ext4 filesystems and an empty repo on them. I ideally want to fill each drive as much as possible, and have the current repo contain no files, how do I do that? Can I just run ``git-annex move --to mito_backup1`` and then when it is full run a second command of ``git-annex move --to mito_backup2``.  Is it better to use ``git-annex copy`` instead of ``move`` and then use ``drop`` after?
+
+Thanks! 
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_13_a4d62d494b340458e6535d573bade965._comment b/doc/forum/Recover_files__44___annex_stuck/comment_13_a4d62d494b340458e6535d573bade965._comment
new file mode 100644
index 0000000000..e68933b5c7
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_13_a4d62d494b340458e6535d573bade965._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.203"
+ subject="comment 13"
+ date="2014-06-18T22:43:08Z"
+ content="""
+It will be faster to use `git annex move`, assuming you want to only have 1 copy of each file, and not more. git-annex will stop storing files on a drive once it gets close to full (annex.diskreserve), and you can safely interrupt it and switch to the next drive.
+
+Do you have any special git configuration? In particular I'm curious about any annex.queuesize setting, which if set to something really high would make `git annex add` buffer a lot of filenames and stage them all at once. (However, I just noticed that annex.queuesize didn't cause as large a queue to be used as intended, so it would need to have been set to some really enormous value to run it out of stack space.)
+
+Also, see [[scalability]].
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_14_c10f0fe1440ccd170804a433db2267ee._comment b/doc/forum/Recover_files__44___annex_stuck/comment_14_c10f0fe1440ccd170804a433db2267ee._comment
new file mode 100644
index 0000000000..71c8d239db
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_14_c10f0fe1440ccd170804a433db2267ee._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="comment 14"
+ date="2014-06-18T22:51:28Z"
+ content="""
+As far as I know I am using the defaults, I didn't customize anything. I am thinking of switching to the WORM backend though as I think it will make things a little faster, but I haven't done that yet.
+
+Also, I actually compiled cabal-install with the ghc flag ``-rtsopts`` and git-annex with flags ``-rtsopts -with-rtsopts=-K1000m``. Due to the amount of memory available, I am not worried if git-annex leaks memory and uses 1GB of memory during operations, but I have been watching it with htop, and its memory usage is usually very small.
+
+
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_15_14446cafac6c33a3f95b5344c42c0bef._comment b/doc/forum/Recover_files__44___annex_stuck/comment_15_14446cafac6c33a3f95b5344c42c0bef._comment
new file mode 100644
index 0000000000..bc1faa82cf
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_15_14446cafac6c33a3f95b5344c42c0bef._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="comment 15"
+ date="2014-06-19T21:19:01Z"
+ content="""
+Everything seems to be working fine now, but I have another question:
+
+Is there any way to speed up the copying of many small files? It looks like git-annex is calling rsync for each individual file, which is very fast for large files, but on my directories with many small files, the total speed is working on to just a few MB an hour - it has only transferred 1GB in the last 4 hours.
+
+I am using the WORM backed with the ``-b WORM`` flag, but I wonder if there is a different move method implemented? For example many calls to ``mv`` will be much faster than many calls to ``rsync``. 
+
+Thanks!
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_16_63c19f58b7e95e39ba25a735bdcc0bcf._comment b/doc/forum/Recover_files__44___annex_stuck/comment_16_63c19f58b7e95e39ba25a735bdcc0bcf._comment
new file mode 100644
index 0000000000..c55edddf97
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_16_63c19f58b7e95e39ba25a735bdcc0bcf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.203"
+ subject="comment 16"
+ date="2014-06-19T22:16:21Z"
+ content="""
+git-annex could be made to always use cp for local transfers, see Remote/Git.hs rsyncOrCopyFile and change `ifM (sameDeviceIds src dest) (docopy, dorsync)` to just `docopy`
+
+However, I doubt that will be a significant speedup. It's more likely that the overhead around copying a file and updating the location tracking etc adds up with millions of small files.
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_17_8e5c7572ab8d1f0e41fedf6f805b942a._comment b/doc/forum/Recover_files__44___annex_stuck/comment_17_8e5c7572ab8d1f0e41fedf6f805b942a._comment
new file mode 100644
index 0000000000..4761bcf3ab
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_17_8e5c7572ab8d1f0e41fedf6f805b942a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="comment 17"
+ date="2014-06-21T01:56:48Z"
+ content="""
+Would git-annex be able to detect if I manually moved some files? At this point it looks like the transfer will take multiple weeks... if I just moved the files from .git/annex directly from one repo to the other I could make the transfer significantly faster, but would that corrupt the repo?
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_18_e5357c63107f79571bd3ff609b4406a7._comment b/doc/forum/Recover_files__44___annex_stuck/comment_18_e5357c63107f79571bd3ff609b4406a7._comment
new file mode 100644
index 0000000000..0398980b44
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_18_e5357c63107f79571bd3ff609b4406a7._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 18"
+ date="2014-07-04T18:03:54Z"
+ content="""
+You can manually move files and use `git annex fsck`, but it is not likely to be any faster.
+
+---
+
+After letting a 2 million file import run while I was away on vacation, I came back to it, and it indeed ran out of memory:
+
+<pre>
+add 999996 ok
+add 999997 ok
+(Recording state in git...)
+[2014-06-21 11:49:28 JEST] feed: xargs [\"-0\",\"git\",\"--git-dir=/home/joey/tmp/r/.git\",\"--work-tree=/home/joey/tmp/r\",\"add\",\"--\"]
+add 999998 ok
+add 999999 ok
+[2014-06-21 11:49:49 JEST] read: git [\"--git-dir=/home/joey/tmp/r/.git\",\"--work-tree=/home/joey/tmp/r\",\"diff\",\"--name-only\",\"--diff-filter=T\",\"-z\",\"--\",\".\"]
+(Recording state in git...)
+[2014-06-21 11:52:24 JEST] feed: xargs [\"-0\",\"git\",\"--git-dir=/home/joey/tmp/r/.git\",\"--work-tree=/home/joey/tmp/r\",\"add\",\"--\"]
+Stack space overflow: current size 8388608 bytes.
+Use `+RTS -Ksize -RTS' to increase it.
+</pre>
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_19_3316652073710f39965cd49ceea5c4ff._comment b/doc/forum/Recover_files__44___annex_stuck/comment_19_3316652073710f39965cd49ceea5c4ff._comment
new file mode 100644
index 0000000000..828b07d41f
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_19_3316652073710f39965cd49ceea5c4ff._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 19"
+ date="2014-07-04T18:18:41Z"
+ content="""
+[[bugs/runs_of_of_memory_adding_2_million_files]]
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_1_d605f755c363d56cf5f1060ad06ee173._comment b/doc/forum/Recover_files__44___annex_stuck/comment_1_d605f755c363d56cf5f1060ad06ee173._comment
new file mode 100644
index 0000000000..18c1c0e9bb
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_1_d605f755c363d56cf5f1060ad06ee173._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.203"
+ subject="comment 1"
+ date="2014-06-18T16:22:13Z"
+ content="""
+What version of git-annex are you using? And what version of git? Is your git-annex repository in direct mode or indirect mode?
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_2_f3ee184a4d3b8d82a8a362a6c03a54a3._comment b/doc/forum/Recover_files__44___annex_stuck/comment_2_f3ee184a4d3b8d82a8a362a6c03a54a3._comment
new file mode 100644
index 0000000000..7c46785bf2
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_2_f3ee184a4d3b8d82a8a362a6c03a54a3._comment
@@ -0,0 +1,54 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="Frustrating"
+ date="2014-06-18T16:29:31Z"
+ content="""
+OK, this is a little frustrating. I found this post from three years ago: [[http://git-annex.branchable.com/forum/Problems_with_large_numbers_of_files/]] and I decided to try a newer version of git-annex.
+
+I uninstalled ghc and haskell from Scientific Linux because all of these Red Hat based distros have ancient packages.
+
+I installed the latest git from source, the latest ghc linux x86_64 binary, and then the latest haskell platform from source. Then I used cabal to install all dependencies for git annex with ``cabal install --only-dependencies git-annex``. Finally I installed git annex from source.
+
+I then tried to run ``git-annex add .`` in my directory and got the following error:
+
+    #> git annex add .
+    add AllStudies.txt.csv.gz ok
+    add GWAS/action.txt.gz ok
+    add GWAS/archive/dump2.txt.gz ok
+    add GWAS/archive/dump3.txt.gz ok
+    add GWAS/by-download-number/27080.log.gz ok
+    (Recording state in git...)
+    Stack space overflow: current size 8388608 bytes.
+    Use `+RTS -Ksize -RTS' to increase it.
+
+
+Ok, I was hoping that the latest version would just work, no luck. So I did what it told me to:
+
+``git-annex +RTS -K1000000 -RTS add .``
+
+That gave the error:
+
+``
+    git-annex: Most RTS options are disabled. Link with -rtsopts to enable them.
+``
+
+Grr.
+
+So I went into the Makefile and added the line ``-rtsopts -with-rtsopts=\"-K1000m\"`` after every call to ghc I could find. I also added ``ghc-options: -with-rtsopts=\"-K100000\"`` to my ~/.cabal/config file.
+
+Now when I run ``make`` I get this error:
+
+
+    if [ \"cabal \" = ./Setup ]; then ghc --make Setup; fi
+    cabal  configure
+    cabal: Most RTS options are disabled. Link with -rtsopts to enable them.
+    make: *** [Build/SysConfig.hs] Error 1
+
+
+Do I have to manually compile the entire Haskell Platform with the -rtsopts flag in order to get this to work?
+
+I can't find any easy-to-follow information anywhere that shows me how to just increase the memory limit. My server has 48 cores, 192GB of memory, over 1TB of scratch space, and over 60TB of storage. I really want to be able to use git-annex to easily move files from our large RAID arrays onto archive drives, and be able to intelligently get that data back whenever I want, I don't understand why I am being limited to 8MB of memory for this.
+
+Any advice would be fantastic, thank you.
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_3_341b47663d133411587ec70ef2b178c6._comment b/doc/forum/Recover_files__44___annex_stuck/comment_3_341b47663d133411587ec70ef2b178c6._comment
new file mode 100644
index 0000000000..77a7c93c8b
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_3_341b47663d133411587ec70ef2b178c6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="Version"
+ date="2014-06-18T16:32:32Z"
+ content="""
+Hi Joeyh,
+
+Thanks for the reply. I am using git version 2.0.0.390.gcb682f8, not sure what version of git-annex, but I downloaded it from github about 20 minutes ago.
+
+Thanks!
+
+-Mike
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_4_66c0d9284d5edbac189a64b03c4fe50a._comment b/doc/forum/Recover_files__44___annex_stuck/comment_4_66c0d9284d5edbac189a64b03c4fe50a._comment
new file mode 100644
index 0000000000..5d153e2481
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_4_66c0d9284d5edbac189a64b03c4fe50a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.203"
+ subject="comment 4"
+ date="2014-06-18T16:35:29Z"
+ content="""
+You can find out the version of git-annex by running: git-annex version
+
+You can find out if your repository is in direct or indirect mode by running: git config annex.direct
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_5_8b32f6597f447f88bee7a80698fb4df6._comment b/doc/forum/Recover_files__44___annex_stuck/comment_5_8b32f6597f447f88bee7a80698fb4df6._comment
new file mode 100644
index 0000000000..cf656f3eae
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_5_8b32f6597f447f88bee7a80698fb4df6._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="Versions"
+ date="2014-06-18T16:40:14Z"
+ content="""
+``git-annex version`` returns:
+
+    git-annex version: 5.20140618-gc2f1c63 
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+    local repository version: unknown
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+``git config annex.direct`` exits with error code 1 and doesn't return any information, however I never explicitly set direct mode, and the repository is all symlinked, so my assumption is that it is in indirect mode. Would direct mode be better for such a large repo?
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_6_4cc81169e99a453cdb6e83e57e638f37._comment b/doc/forum/Recover_files__44___annex_stuck/comment_6_4cc81169e99a453cdb6e83e57e638f37._comment
new file mode 100644
index 0000000000..52e04dfc85
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_6_4cc81169e99a453cdb6e83e57e638f37._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="Reinstall GHC or Cabal?"
+ date="2014-06-18T16:49:35Z"
+ content="""
+Do I need to reinstall ghc or cabal with rtsopts enabled somehow in order to be able to compile git-annex with -K1000m?
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_7_2d104cf4682e04906f8ca0ced7288cf1._comment b/doc/forum/Recover_files__44___annex_stuck/comment_7_2d104cf4682e04906f8ca0ced7288cf1._comment
new file mode 100644
index 0000000000..6ea7b45f64
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_7_2d104cf4682e04906f8ca0ced7288cf1._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.203"
+ subject="comment 7"
+ date="2014-06-18T17:14:40Z"
+ content="""
+Ok, so the repository is in indirect mode, and this rules out a large quantity of problems that could have been caused by direct mode (no, I don't recommend using direct mode).
+
+If you want to build git-annex with the +RTS option enabled, you just need to pass -rtsopts to ghc when building git-annex. (Not -with-rtsopts ...) 
+That *might* let you pump up the memory and bypass whatever the problem is, or at least find out how much memory it's trying to allocate, which might be a useful clue. But I would be much more interested in debugging and fixing the actual problem, since git-annex should not normally need to allocate a 8+ mb chunk of memory.
+
+The  \"No HEAD commit to compare with (yet)\" failure mode was removed from git in 2011. You must have been using old versions of git and git-annex before you upgraded. Perhaps they have left the repository in some broken state.
+
+What size does `du -hsc .git/objects` report? How about `du -h .git/index`?
+
+Are git commands that do not involve git-annex still taking a long time to run or failing in some way? (Note that `git commit` has a hook that runs git-annex; you can bypass that with `git commit --no-verify`)
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_8_d356c4fce9f1197e5292f9dedf85bbc9._comment b/doc/forum/Recover_files__44___annex_stuck/comment_8_d356c4fce9f1197e5292f9dedf85bbc9._comment
new file mode 100644
index 0000000000..df1af4f06b
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_8_d356c4fce9f1197e5292f9dedf85bbc9._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="comment 8"
+ date="2014-06-18T17:31:58Z"
+ content="""
+The git available through yum is git 1.7.1, which looks like it was released in 2010 or earlier. (I really wish I had a different version of linux on this server). It is possible that in some way screwed up the repo.
+
+I figured out how to compile cabal and git-annex with rtsopts, so I can now set higher memory levels, but I am happy to help debug the problem too, as I would really love a fully functional git-annex.
+
+git commands now run quickly, thanks to the new git I think.
+
+``du -hsc .git/objects`` returns: ``8.1G    .git/objects``
+
+``du -h .git/index`` returns: ``437M    .git/index``
+
+I am currently running the command ``git-annex +RTS -K1000m -RTS add .``, it is chugging away doing something, but is not printing any messages yet after 11 minutes of running, it is a 6TB directory though, and there are a lot of concurrent IO operations on that disk right now.
+
+I am also running ``du -h --max-depth=1`` on the root repo directory, and also ``find | wc -l``, so that I can tell you the exact size of the dir and the total number of files too.  These operations combined may take more than an hour though, I will send details when the commands complete.
+
+Let me know if you want me to stop the ``git-annex +RTS -K1000m -RTS add .`` command and run git-annex some other way.
+"""]]
diff --git a/doc/forum/Recover_files__44___annex_stuck/comment_9_856c7e1575f5d99530ecd54004315487._comment b/doc/forum/Recover_files__44___annex_stuck/comment_9_856c7e1575f5d99530ecd54004315487._comment
new file mode 100644
index 0000000000..c092d99f50
--- /dev/null
+++ b/doc/forum/Recover_files__44___annex_stuck/comment_9_856c7e1575f5d99530ecd54004315487._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.203"
+ subject="comment 9"
+ date="2014-06-18T17:36:44Z"
+ content="""
+Both of those du's look extremely large. How many files are listed by `git ls-files --cached | wc -l` ?
+
+I don't think that there's any point in running `git annex add` while you're still having some problem. I am curious though how much memory the git-annex add you have running has used.
+
+If I were you, I'd look in .git/objects for large files (> 100kb, say).
+"""]]
diff --git a/doc/forum/Recover_repository_from_bup_repository.mdwn b/doc/forum/Recover_repository_from_bup_repository.mdwn
new file mode 100644
index 0000000000..473bfb62e2
--- /dev/null
+++ b/doc/forum/Recover_repository_from_bup_repository.mdwn
@@ -0,0 +1 @@
+I screwed up one of my repositories, so I decided to start from clean slate. I have a remote bup repository that has all of my previous repository data. Now, I want to get it back. How I can do this?
diff --git a/doc/forum/Recover_repository_from_bup_repository/comment_1_6e3b1ff58fbdc10bcaca6d660eb1156f._comment b/doc/forum/Recover_repository_from_bup_repository/comment_1_6e3b1ff58fbdc10bcaca6d660eb1156f._comment
new file mode 100644
index 0000000000..9b95472e44
--- /dev/null
+++ b/doc/forum/Recover_repository_from_bup_repository/comment_1_6e3b1ff58fbdc10bcaca6d660eb1156f._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-21T15:59:55Z"
+ content="""
+If your bup repository is a git-annex special remote, it contains only 
+the contents of annexed files, but not the rest of the git repository data
+(no filenames, no pointers to git-annex keys, etc).
+
+Also, the files in it may be encrypted in a variety of ways depending on
+how you set up that git-annex special remote. If encryption was used, most
+likely it needs information that was stored in the git repository to
+decrypt it.
+
+So, your best bet is to restore your git-annex repository from a backup or
+a clone of that repository. Then you can just `git annex enableremote` the
+bup special remote and use `git-annex get` as usual. If you didn't have a
+backup or a clone of the git-annex repository, then important 
+information is lost.
+
+Without the git-annex repository, you can manually get the contents of the
+files from the bup repository. In the bup repository, run `git branch`;
+this will print out the names of all the git-annex keys that were stored
+there. Then you can use `bup join` to extract the content of each key:
+
+	bup join -r /path/to/bup/repository $key > $key.content
+
+Without the git-annex repository, there's no record of what the filename
+was, but you can extract the content this way.
+
+But, if the key names start with "GPG" the the data is stored in bup
+encrypted and you are probably out of luck (although if you used
+encryption=pubkey when setting up the bup special remote, you
+can use gpg to decrypt the files after `bup join`).
+"""]]
diff --git a/doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget.mdwn b/doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget.mdwn
new file mode 100644
index 0000000000..0df8689985
--- /dev/null
+++ b/doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget.mdwn
@@ -0,0 +1,11 @@
+Hello there!
+
+I sent a part of my files to a special rsync remote ```git annex move --all --to rsync_remote```
+Then I rewrote the history of my repository ```git annex forget```
+And some days later I try ```git annex whereis file``` which tells me there is no copy left and ````git annex info rsync_remote``` which outputs no annexed keys.
+Now, I know the data is still in the rsync special remote because looking for the files SHA keys, I am able to find their annex objects directories.
+The annex objects directories are different between the local git annex and the special rsync remote, supposedly because of my rewrite.
+
+Is there any simple way to repair that? To tell git-annex that the keys are accessible in the special rsync remote?
+I might be able to recover the data doing something like copying all the rsync directory locally and reinjecting files but it seems over complicated while the keys are valid.
+Moreover, the computer with the special rsync remote is a distant one whith limited support (I can't install git-annex on it) so it would be very slow to copy all the data through the network.
diff --git a/doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget/comment_1_265563f95a8ec5918314afc7e6226b56._comment b/doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget/comment_1_265563f95a8ec5918314afc7e6226b56._comment
new file mode 100644
index 0000000000..077398fc36
--- /dev/null
+++ b/doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget/comment_1_265563f95a8ec5918314afc7e6226b56._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2018-09-19T11:03:54Z"
+ content="""
+I think `git annex fsck --fast --from $remote` will make the local annex relearn all the files the remote has without transferring them.
+"""]]
diff --git a/doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget/comment_2_4da1d3f6a37b8772838bae762d4c43be._comment b/doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget/comment_2_4da1d3f6a37b8772838bae762d4c43be._comment
new file mode 100644
index 0000000000..7542ce4072
--- /dev/null
+++ b/doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget/comment_2_4da1d3f6a37b8772838bae762d4c43be._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="webanck"
+ avatar="http://cdn.libravatar.org/avatar/cd273f76ef8c4218510b4f50ef7e1f3d"
+ subject="comment 2"
+ date="2018-09-19T11:40:56Z"
+ content="""
+Indeed, this command did the trick!
+I didn't even think about using ```fsck``` because the ```git annex info``` was returning 0 references.
+Thanks a lot!
+"""]]
diff --git a/doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget/comment_3_5aff48172bb767ed03e96812e4f89f38._comment b/doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget/comment_3_5aff48172bb767ed03e96812e4f89f38._comment
new file mode 100644
index 0000000000..2d54185f6a
--- /dev/null
+++ b/doc/forum/Recovering_data_from_rsync_special_remote_after_git-annex-forget/comment_3_5aff48172bb767ed03e96812e4f89f38._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-10-04T19:05:23Z"
+ content="""
+Can you please provide more information about what you did to get into this
+state? Running `git annex forget` does not cause git-annex to forget about
+content that is present in a remote.
+"""]]
diff --git a/doc/forum/Recovering_deleted_file_in_direct_mode.mdwn b/doc/forum/Recovering_deleted_file_in_direct_mode.mdwn
new file mode 100644
index 0000000000..9dc1bdaf1f
--- /dev/null
+++ b/doc/forum/Recovering_deleted_file_in_direct_mode.mdwn
@@ -0,0 +1,13 @@
+I accidentally deleted a file from a git-annex repository with a plain "rm". How can I restore it from other repositories that have it?
+
+I tried using
+
+    git annex copy --from $REMOTE $REMOVED_FILE
+
+but git-annex complaints about
+
+    $REMOVED_FILE not found
+
+I suppose that I could switch to indirect mode and do checkout and older version, but I'd prefer not to. My repository contains thousands of quite big files; it would take a lot of time and the probability of something going wrong during the conversion is quite high (see other bugs reported during import).
+
+I'm using git-annex 5.20141024-g613f396.
diff --git a/doc/forum/Recovering_deleted_file_in_direct_mode/comment_1_a3e6fc93669ec76656c84793d1f59149._comment b/doc/forum/Recovering_deleted_file_in_direct_mode/comment_1_a3e6fc93669ec76656c84793d1f59149._comment
new file mode 100644
index 0000000000..0b23bbc784
--- /dev/null
+++ b/doc/forum/Recovering_deleted_file_in_direct_mode/comment_1_a3e6fc93669ec76656c84793d1f59149._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-28T19:22:54Z"
+ content="""
+> the probability of something going wrong during the conversion is quite high (see other bugs reported during import)
+
+I don't know what bugs you speak of. If the probability of something going
+wrong is quite high, then you must have a reproducible test case. Submit a
+bug with such a test case, and I can fix it.
+"""]]
diff --git a/doc/forum/Recovering_deleted_file_in_direct_mode/comment_2_98c01a756c5f2dda28cffa5dd1dea385._comment b/doc/forum/Recovering_deleted_file_in_direct_mode/comment_2_98c01a756c5f2dda28cffa5dd1dea385._comment
new file mode 100644
index 0000000000..007160ab25
--- /dev/null
+++ b/doc/forum/Recovering_deleted_file_in_direct_mode/comment_2_98c01a756c5f2dda28cffa5dd1dea385._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 2"
+ date="2014-11-12T21:00:41Z"
+ content="""
+A new `git annex proxy` command was just added that allows safely running commands like `git revert` in a direct mode repsitory.
+
+So, you might do:
+
+    rm myfile # oops!
+    git annex sync
+    git annex proxy -- git revert HEAD
+    git annex get myfile
+
+The sync is needed to commit the deletion, and then that commit gets reverted. Finally, you can use git-annex get to download the file from some other repository that still has a copy. (Assuming you didn't delete the last copy.)
+"""]]
diff --git a/doc/forum/Recovering_from_a_cross-merge.mdwn b/doc/forum/Recovering_from_a_cross-merge.mdwn
new file mode 100644
index 0000000000..bde8138b41
--- /dev/null
+++ b/doc/forum/Recovering_from_a_cross-merge.mdwn
@@ -0,0 +1,80 @@
+Intro
+=====
+
+This experience report
+describes steps I've taken for recovering from a situation where
+an *unrelated* git-annex's remote was accidentally merged into a repository.
+
+It is posted to the forum for use by anyone who finds themselves in the same situation
+(especially myself…).
+
+The root cause of the issue was a copy-pasted `git remote add` gone wrong,
+and a subsequent `git annex sync`, that "contaminated" the rest of my remotes.
+That led to `git annex info` showing the union of all the repositories available to the two repositories,
+and `fsck --all` runs looking for files from any repository.
+
+It should go without saying, but here it is anyway:
+
+**Following these steps can eventualy lead to data loss**.
+
+The precautions I've taken are
+
+* knowing that two complete copies of the data sets exist,
+* having a filesystem level snapshot of a least one of those copies, and
+* not starting any file dropping until all remotes have completed fscks at the end.
+
+Identifying the last good state
+===============================
+
+By looking for the first occurrence of the UUID of one of the bad new remotes
+in `git log --patch git-annex`,
+I've identified the last good git-annex state before the merge.
+
+Tagging that as `git tag before-accidental-merging-with-other-server 83c1b945c2428cefa968aec587229f6a87649de6`.
+
+
+Removing potentially mergable information
+=========================================
+
+git-annex is eager to pull in updates lying around --
+while this is usually a good thing,
+here it incurs the danger of resurrecting the accident.
+
+On all remotes that were accessed since the accident,
+I've executed this to remove both the local synced/git-annex branch
+and any memory of cached remote branches:
+
+    $ git branch -D synced/git-annex
+    $ git branch -r | sed 's@remotes/@@' | xargs git branch -d -r
+
+and restore the git-annex branch:
+
+    $ git branch -f git-annex 83c1b945c2428cefa968aec587229f6a87649de6
+
+That proved to be insufficient --
+after I had first only done this,
+things looked good for a while and then after the first `git annex fsck --fast`,
+the remotes were back again.
+
+The only file large enough to contain the offending data in .git/annex was .git/annex/index,
+so I've removed that backed by [[internals]]' statement of it being safe to remove:
+
+    $ rm .git/annex/index
+
+(did that on all remotes; on bare ones it's `annex/index`, obviously).
+
+Verification
+============
+
+To ensure everyone is on the same page,
+I've run `git annex sync`;
+its speed already showed that now there's no information about a second repository being transferred.
+
+Subsequently, I've run `git annex fsck --all` in all locations.
+(That *did* show that I should previously have marked some keys as dead when they were migrated from SHA256E to SHA256,
+but that's beside the point here).
+
+Even after a sync following the above,
+no traces of the bad merge (be it in the form of a repository or of a file from there) have shown up any more.
+
+-- [[chrysn]]
diff --git a/doc/forum/Recovery_after_freeze_while_importing_files.mdwn b/doc/forum/Recovery_after_freeze_while_importing_files.mdwn
new file mode 100644
index 0000000000..f67e7fb44b
--- /dev/null
+++ b/doc/forum/Recovery_after_freeze_while_importing_files.mdwn
@@ -0,0 +1,3 @@
+My PC froze while git-annex was in the process of importing a file. It was in the final stage of updating git status when the freeze occurred. git status shows the imported file under "changes to be committed" as "new file."
+
+I don't know how git-annex works under the hood, so I don't know how the freeze might've affected the repo. I don't want to lose my files. What do you recommend is the best way of recovering from this and making sure there are no errors?
diff --git a/doc/forum/Recovery_after_freeze_while_importing_files/comment_1_d033b77b9417468e13076ff9302f2963._comment b/doc/forum/Recovery_after_freeze_while_importing_files/comment_1_d033b77b9417468e13076ff9302f2963._comment
new file mode 100644
index 0000000000..c9d004c7aa
--- /dev/null
+++ b/doc/forum/Recovery_after_freeze_while_importing_files/comment_1_d033b77b9417468e13076ff9302f2963._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-12-02T17:09:24Z"
+ content="""
+Doesn't sound like a problem. Have you tried committing the file?
+"""]]
diff --git a/doc/forum/Recovery_after_freeze_while_importing_files/comment_2_e14f330de3e9ebfa9a99c32e65d59d11._comment b/doc/forum/Recovery_after_freeze_while_importing_files/comment_2_e14f330de3e9ebfa9a99c32e65d59d11._comment
new file mode 100644
index 0000000000..3a897cc027
--- /dev/null
+++ b/doc/forum/Recovery_after_freeze_while_importing_files/comment_2_e14f330de3e9ebfa9a99c32e65d59d11._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="ghen1"
+ subject="comment 2"
+ date="2014-12-18T11:28:35Z"
+ content="""
+I did, and everything seems fine.
+"""]]
diff --git a/doc/forum/Reduce_disk_space_by_dropping_older_versions_in_local_git_annex.mdwn b/doc/forum/Reduce_disk_space_by_dropping_older_versions_in_local_git_annex.mdwn
new file mode 100644
index 0000000000..1b7ebfcff9
--- /dev/null
+++ b/doc/forum/Reduce_disk_space_by_dropping_older_versions_in_local_git_annex.mdwn
@@ -0,0 +1,9 @@
+Looking at using git-annex, I wonder if there is a way of removing previous versions from a local git repository annex. We have a 'gold' copy of the repository and will also have of the annex, so dropping a local copy is fine.
+
+If I checkout older git tags, then the git repo annex fills up with those old annex file versions, and I would like a way of flushing out the old versions to minimise the disk space.
+
+I tried git annex drop, but that appears to only drop the current version.
+
+Does git-annex understand that all the versions of a file are related, or is this relationship only discoverable from the symlink in the git repo?
+
+It is not a deal-breaker, but I would like a single command I can give my team if they are running short on disk space.
diff --git a/doc/forum/Reduce_disk_space_by_dropping_older_versions_in_local_git_annex/comment_1_2a84bf661e0cbd5c8a558d3dbf5aef65._comment b/doc/forum/Reduce_disk_space_by_dropping_older_versions_in_local_git_annex/comment_1_2a84bf661e0cbd5c8a558d3dbf5aef65._comment
new file mode 100644
index 0000000000..553c2248a8
--- /dev/null
+++ b/doc/forum/Reduce_disk_space_by_dropping_older_versions_in_local_git_annex/comment_1_2a84bf661e0cbd5c8a558d3dbf5aef65._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-15T19:31:32Z"
+ content="""
+`git annex unused` is the way to find such old versions of files, and
+then you can use commands like `git annex move --unused --to gold` or
+`git annex dropunused`
+
+By default, `git annex unused` assumes that if any branch or tag points to
+a version of a file, that version is used. If you want it to consider tags
+as unused, run:
+
+	git annex unused --used-refspec='+refs/heads/*'
+"""]]
diff --git a/doc/forum/Reinject_does_not_have_expected_content_of_file.mdwn b/doc/forum/Reinject_does_not_have_expected_content_of_file.mdwn
new file mode 100644
index 0000000000..bf15ad85ee
--- /dev/null
+++ b/doc/forum/Reinject_does_not_have_expected_content_of_file.mdwn
@@ -0,0 +1,44 @@
+Hi,
+
+I am trying to recover files from Hubic that were at some point uploaded with a leading slash in the filename. This made it impossible to get them with the git annex rclone extension because rclone interprets the leading slash as a directory move. So I wrote a script using the swiftclient python lib to download the files anyway. Then I am decrypting them with the ga_decrypt shell script and I am trying to reinject them into my local repo. For some files, the --known flag just works and injects the contents to the symlink that is broken. For some cases, I have to submit the src and dst filename and for some cases even then git-annex will tell me that the content does not match the expected content of the file. 
+
+This is the process that I follow:
+
+For the file that is only on hubic I do a git-annex get file. The error message (since hubic integration is not working for that repo) gives me the key that I need to look that file up in hubic (what would be a cleaner way?):
+    
+    git annex get 2012-06-23\ 15\:17\:23.mp4
+    get 2012-06-23 15:17:23.mp4 (from hubic...) 
+    mv: cannot stat '/tmp/rclone-annex-tmp.diesZi1ZL/GPGHMACSHA1--b22130c742403960d80c0e9c78314e3d7034ba79': No such file or directory
+
+      Unable to access these remotes: hubic
+
+      Try making some of these repositories available:
+            396e481c-5fc9-4933-b6a4-b1398fb7c61b -- [hubic]
+    failed
+    git-annex: get: 1 failed
+
+
+I prepend the leading slash and download that file manually from hubic. I use ga_decrypt and get files that actually are readable (in this case a video). 
+However, when I do git-annex reinject src dst I get (I removed the colons because I wanted to rule out a bug):
+
+    git-annex: 2012-06-23_151723.mp4 does not have expected content of ../Pictures/Marek Handy/2012/2012-06-23_151723.mp4
+    failed
+    git-annex: reinject: 1 failed
+
+Ok so apparently, git annex does not like that content for that file. Also if I do git-annex calckey on the downloaded and decrypted file I get a different key than the original key.
+
+    git-annex calckey 2012-06-23_151723.mp4
+    SHA256E-s19520577--116c8b3101916fb1d81bf6816cc1b616a8eb30b5fe7b293053cfdd41fa178b0a.mp4
+
+but ls -l on the file gives me:
+
+    ls -larth ../Pictures/Marek\ Handy/2012/2012-06-23\ 15\:17\:23.mp4 
+    lrwxrwxrwx 1 marek marek 201 Aug  6 17:28 '../Pictures/Marek Handy/2012/2012-06-23 15:17:23.mp4' -> ../../../.git/annex/objects/jQ/mk/SHA256E-s19120318--2631ff42deb7419e97dc46e7423937694c40d09b336d9b8e7aa2c5fe94e73cc7    /SHA256E-s19120318--2631ff42deb7419e97dc46e7423937694c40d09b336d9b8e7aa2c5fe94e73cc7
+
+
+I appreciate any hints to what went wrong or where maybe my thinking is wrong?
+
+Thank you,
+Marek
+
+
diff --git a/doc/forum/Reloading_.git__47__config_mid-sync.mdwn b/doc/forum/Reloading_.git__47__config_mid-sync.mdwn
new file mode 100644
index 0000000000..0c2ef14fd9
--- /dev/null
+++ b/doc/forum/Reloading_.git__47__config_mid-sync.mdwn
@@ -0,0 +1 @@
+There are some settings (rsync bandwidth settings are my use case) I'd like to reload after assistant starts, possibly mid-sync. Does assistant support SIGHUP, etc? What's the correct way to change bandwidth settings?
diff --git a/doc/forum/Reloading_.git__47__config_mid-sync/comment_1_69e8879e0fed0e1b1589a721f9c6e3c7._comment b/doc/forum/Reloading_.git__47__config_mid-sync/comment_1_69e8879e0fed0e1b1589a721f9c6e3c7._comment
new file mode 100644
index 0000000000..d39b21ffbf
--- /dev/null
+++ b/doc/forum/Reloading_.git__47__config_mid-sync/comment_1_69e8879e0fed0e1b1589a721f9c6e3c7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="comment 1"
+ date="2014-07-23T15:02:04Z"
+ content="""
+Assistant does not support SIGHUP. There is a menu item (top right menu) that can restart it.
+"""]]
diff --git a/doc/forum/Relocating_annex_directory.mdwn b/doc/forum/Relocating_annex_directory.mdwn
new file mode 100644
index 0000000000..f2e271333e
--- /dev/null
+++ b/doc/forum/Relocating_annex_directory.mdwn
@@ -0,0 +1 @@
+I have around 70 GBs of data spread around 4 repositories on a Linux (Ubuntu) box. My problem is I need to reformat the drive they are on. I would like to move them to an external usb drive temporarily during reinstall then move them back to their original location. When I started with annex I did try to mv annexFolder/ toNewLoc/ which failed leaving behind a corrupt repo. What is a safe way to move an annex folder? My primary connection is a 3G modem so I am trying to avoid re downloading everything. Another thing I am trying to avoid is cloning the repos to the external drive, reinstall, clone it back to the internal drive and mark original and external repos as dead, but AFAIK those dead repos will show up in the output of whereis, so everytime I reformat I gonna have two extra dead repos.
diff --git a/doc/forum/Relocating_annex_directory/comment_1_13ff5438baa1db110beb6aab3a783def._comment b/doc/forum/Relocating_annex_directory/comment_1_13ff5438baa1db110beb6aab3a783def._comment
new file mode 100644
index 0000000000..5136941c50
--- /dev/null
+++ b/doc/forum/Relocating_annex_directory/comment_1_13ff5438baa1db110beb6aab3a783def._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2013-08-16T03:42:00Z"
+ content="""
+moving the annex should work fine, provided:
+
+* You are moving it to a proper unix filesystem - NOT fat32
+* The assistant is shutdown. If it is running, bad things will happen.
+"""]]
diff --git a/doc/forum/Relocating_annex_directory/comment_2_6d88ff03fcf00ae872442e8a86c968ed._comment b/doc/forum/Relocating_annex_directory/comment_2_6d88ff03fcf00ae872442e8a86c968ed._comment
new file mode 100644
index 0000000000..e7b361675f
--- /dev/null
+++ b/doc/forum/Relocating_annex_directory/comment_2_6d88ff03fcf00ae872442e8a86c968ed._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 2"
+ date="2013-08-24T18:56:11Z"
+ content="""
+`git annex whereis` does not show dead repositories. 
+
+Anyway Justin is of course right: Provided the assistant is not running in a repository, the repository is just a collection of files in a directory, and can be moved around, tarred up, untarred, etc just like any other repository. If the assistant is running it may become unhappy if its repository vanishes out from underneath it.
+"""]]
diff --git a/doc/forum/Remote__39__s_git-annex-shell_not_detected.mdwn b/doc/forum/Remote__39__s_git-annex-shell_not_detected.mdwn
new file mode 100644
index 0000000000..5d9223ff98
--- /dev/null
+++ b/doc/forum/Remote__39__s_git-annex-shell_not_detected.mdwn
@@ -0,0 +1,20 @@
+When doing `git annex get fname` in a repo A with 2 remotes on LAN (B and C), it says they don't have git annex installed so it sets the `annex-ignore` flag. However, they do have it, and I can `annex-get` files from C to B. Versions of git and git-annex vary between the machines. Any idea what could be causing it? Perhaps A's git needs an update?
+
+
+A:
+
+* Ubuntu. 
+* git 1.9.1
+* git-annex 5.20140412ubuntu1
+
+B: 
+
+* Fedora 22
+* git 2.3.2 (installed through Nix package manager, so its in a nonstandard path)
+* git-annex 5.20140717 (installed normally, in /usr/bin)
+
+C: 
+
+* Fedora 22
+* git 2.3.2 (installed through Nix package manager, so its in a nonstandard path)
+* git-annex 5.20150219 (installed through Nix
diff --git a/doc/forum/Remote__39__s_git-annex-shell_not_detected/comment_1_8354782cf0fab248e607c7eae59d6bb2._comment b/doc/forum/Remote__39__s_git-annex-shell_not_detected/comment_1_8354782cf0fab248e607c7eae59d6bb2._comment
new file mode 100644
index 0000000000..ff17520ff4
--- /dev/null
+++ b/doc/forum/Remote__39__s_git-annex-shell_not_detected/comment_1_8354782cf0fab248e607c7eae59d6bb2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-09T14:13:50Z"
+ content="""
+I'd guess that however you have installed git-annex does not result in
+git-annex-shell being in PATH until .bashrc or similar is loaded. 
+
+Since bash refuses to load any such files when a command like "ssh thehost
+git-annex-shell" is run, you can't install git-annex-shell that way. You
+have to install it somewhere in the default PATH.
+"""]]
diff --git a/doc/forum/Remote__39__s_git-annex-shell_not_detected/comment_2_35e5d9b427963fc7b9618eb522bd1273._comment b/doc/forum/Remote__39__s_git-annex-shell_not_detected/comment_2_35e5d9b427963fc7b9618eb522bd1273._comment
new file mode 100644
index 0000000000..825e749f1c
--- /dev/null
+++ b/doc/forum/Remote__39__s_git-annex-shell_not_detected/comment_2_35e5d9b427963fc7b9618eb522bd1273._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-08-09T21:20:05Z"
+ content="""
+I've added [[tips/get_git-annex-shell_into_PATH]] explaining this problem
+and solutions in detail.
+"""]]
diff --git a/doc/forum/Remote__39__s_git-annex-shell_not_detected/comment_2_7fb6168197c3f16de9775a60b7941cde._comment b/doc/forum/Remote__39__s_git-annex-shell_not_detected/comment_2_7fb6168197c3f16de9775a60b7941cde._comment
new file mode 100644
index 0000000000..2ee4e40349
--- /dev/null
+++ b/doc/forum/Remote__39__s_git-annex-shell_not_detected/comment_2_7fb6168197c3f16de9775a60b7941cde._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/1938c4c8-6bd7-4fbe-8784-f00dc5dd9fcb"
+ nickname="johnny-tedesco"
+ subject="comment 2"
+ date="2015-08-09T19:56:52Z"
+ content="""
+Thanks! I'll look into it
+"""]]
diff --git a/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__.mdwn b/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__.mdwn
new file mode 100644
index 0000000000..c494dc9f88
--- /dev/null
+++ b/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__.mdwn
@@ -0,0 +1,5 @@
+As the heading suggests. Here's a gif of my issue:
+
+<a href="//imgur.com/l1shlsX">View post on imgur.com</a>
+
+The other remotes don't seem to be working either.
diff --git a/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_1_04144280b69a7ba0cfa4fa3e1b5ef4ec._comment b/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_1_04144280b69a7ba0cfa4fa3e1b5ef4ec._comment
new file mode 100644
index 0000000000..a39edfacdb
--- /dev/null
+++ b/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_1_04144280b69a7ba0cfa4fa3e1b5ef4ec._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 1"
+ date="2016-05-10T14:40:18Z"
+ content="""
+This was solved by letting the assistant repair the repo (which took almost a whole night!). [See also.](http://git-annex.branchable.com/forum/How_to_find_out_if_assistant_is_still_repairing__63__/)
+"""]]
diff --git a/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_2_2c0340e5eac6d712045614886a8403a5._comment b/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_2_2c0340e5eac6d712045614886a8403a5._comment
new file mode 100644
index 0000000000..7498b1635d
--- /dev/null
+++ b/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_2_2c0340e5eac6d712045614886a8403a5._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-12T19:36:19Z"
+ content="""
+Enormous animated gif shows:
+
+1. List of remotes. "Kapsel" remote has "Syncing disabled"
+2. Apparently user clicks on that, although it's not entirely clear.
+   Page seems to reload and still has "Syncing disabled" for Kapsel.
+3. User goed to Edit repository for Kapsel. That page has "Syncing enabled"
+   checked.
+4. User saves and remote list still has it disabled.
+
+I guess my suggestion is, first to tell us what version of git-annex you're
+using, and second, take a look at .git/annex/daemon.log inside the git
+repository. There's probaby something to help narrow the problem down in
+the log.
+
+It would probably also help to paste the .git/config stanza for
+the remote.
+"""]]
diff --git a/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_3_2b1ac09cb8b5f5ec62a201785c2f6531._comment b/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_3_2b1ac09cb8b5f5ec62a201785c2f6531._comment
new file mode 100644
index 0000000000..9e2745c107
--- /dev/null
+++ b/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_3_2b1ac09cb8b5f5ec62a201785c2f6531._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-05-12T19:52:49Z"
+ content="""
+Looking at the code, the RepoList looks at syncRemotes to decide if a
+remote is syncing or not. The edit form instead looks at remoteAnnexSync
+from the remote's gitconfig. So, seems syncRemotes for some reason does
+not include this remote, despite its gitconfig saying to sync with it.
+
+Well, calcSyncRemotes starts with remoteAnnexSync but also excludes Dead
+repos. And indeed, when a repo is dead, it behaves as shown.
+
+So, `git annex semitrust Kapsel` should get it back to syncing with that
+remote. Assuming it's not dead for a reason.
+
+The webapp UI doesn't currently indicate when a remote is dead. I think you
+can only get into this state by running `git annex dead` at the command line
+though.
+
+Simple fix is to not make the webapp display dead remotes in the
+RepoList at all. Done.
+"""]]
diff --git a/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_4_a8e68a41e069803d89f18d1645876298._comment b/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_4_a8e68a41e069803d89f18d1645876298._comment
new file mode 100644
index 0000000000..b303c3afae
--- /dev/null
+++ b/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_4_a8e68a41e069803d89f18d1645876298._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 4"
+ date="2016-05-14T13:21:04Z"
+ content="""
+Indeed it was a question of trust. Something that the assistant should notify me about. Maybe it should even be a setting in the assistant. No feedback here is just not a good idea.
+"""]]
diff --git a/doc/forum/Remote_listed_in_whereis_but_not_in_info.mdwn b/doc/forum/Remote_listed_in_whereis_but_not_in_info.mdwn
new file mode 100644
index 0000000000..d7f7f18e0d
--- /dev/null
+++ b/doc/forum/Remote_listed_in_whereis_but_not_in_info.mdwn
@@ -0,0 +1,29 @@
+I came across the following strange behaviour:
+
+    $ git annex whereis "2013-WS/ecl/Algorithms for Scoring Coreference Chains.pdf"
+    whereis 2013-WS/ecl/Algorithms for Scoring Coreference Chains.pdf (4 copies) 
+   	    04140d86-2ad5-4807-a789-f478dbf477c7 -- [mojzesz]
+   	    622fce61-6702-448f-8eee-9a31d8a67e14 -- here
+   	    8bb266ed-453d-4489-9d8a-de38b2bc77c2
+   	    d8149441-8b4d-4d37-bed4-c0f709165f32 -- [alonzo]
+    ok
+
+I have no idea what that remote without a name is. Is there a way to find that out?
+
+Plus, it is not shown by
+
+    $ git annex info
+    repository mode: indirect
+    trusted repositories: 0
+    semitrusted repositories: 3
+	    04140d86-2ad5-4807-a789-f478dbf477c7 -- [mojzesz]
+ 	    622fce61-6702-448f-8eee-9a31d8a67e14 -- here
+ 	    d8149441-8b4d-4d37-bed4-c0f709165f32 -- [alonzo]
+    untrusted repositories: 4
+	    00000000-0000-0000-0000-000000000001 -- web
+ 	    00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	    11d4b299-0170-49b3-8b71-7ea2c47f212b -- nexus5
+ 	    dd22c018-65f8-4fa7-b880-48616016e272 -- miracle
+    ...
+
+Also, is there a way to mark that remote as dead?
diff --git a/doc/forum/Remote_listed_in_whereis_but_not_in_info/comment_1_85cc355213f894e8c1aeece432de67c3._comment b/doc/forum/Remote_listed_in_whereis_but_not_in_info/comment_1_85cc355213f894e8c1aeece432de67c3._comment
new file mode 100644
index 0000000000..1db8b0c196
--- /dev/null
+++ b/doc/forum/Remote_listed_in_whereis_but_not_in_info/comment_1_85cc355213f894e8c1aeece432de67c3._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-11-07T18:05:49Z"
+ content="""
+For this to happen, the repository must somehow not be listed in uuid.log,
+but the location log for the file includes its uuid. Normally, any time a
+git-annex repo is initialized, it gets recorded in uuid.log.
+
+One way that could have happened is if `git annex reinit` was run
+with some uuid that was not known in uuid.log. Or, if `git config
+annex.uuid` were manually set.
+
+I don't think it's a problem, other than you not knowing where this
+repository is -- unless some file is only present in that repository. 
+
+You can run `git annex dead` with the uuid as a parameter to mark it dead,
+or you could `git annex describe` with the uuid as a parameter to give
+it a description.
+"""]]
diff --git a/doc/forum/Remote_listed_in_whereis_but_not_in_info/comment_2_ddede3236f1d91ac4f0117b76267a021._comment b/doc/forum/Remote_listed_in_whereis_but_not_in_info/comment_2_ddede3236f1d91ac4f0117b76267a021._comment
new file mode 100644
index 0000000000..736f98ef6a
--- /dev/null
+++ b/doc/forum/Remote_listed_in_whereis_but_not_in_info/comment_2_ddede3236f1d91ac4f0117b76267a021._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="robert.schuetz@7942237bf71a2ae4f5d3cb047d167612b8c9e311"
+ nickname="robert.schuetz"
+ avatar="http://cdn.libravatar.org/avatar/89879460a9e84b9c736d982d9489d3d9"
+ subject="comment 2"
+ date="2017-11-07T19:14:18Z"
+ content="""
+Surprisingly, I can't use the UUID:
+
+    $ git annex dead 8bb266ed-453d-4489-9d8a-de38b2bc77c2
+    dead 8bb266ed-453d-4489-9d8a-de38b2bc77c2 git-annex: there is no available git remote named \"8bb266ed-453d-4489-9d8a-de38b2bc77c2\"
+"""]]
diff --git a/doc/forum/Remote_listed_in_whereis_but_not_in_info/comment_3_607d5b01eb95906391337f7351e0193c._comment b/doc/forum/Remote_listed_in_whereis_but_not_in_info/comment_3_607d5b01eb95906391337f7351e0193c._comment
new file mode 100644
index 0000000000..f2ba0e6074
--- /dev/null
+++ b/doc/forum/Remote_listed_in_whereis_but_not_in_info/comment_3_607d5b01eb95906391337f7351e0193c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-11-07T19:35:17Z"
+ content="""
+Ah right, it looks in `uuid.log` to make sure the UUID provided is
+valid. Bit of a catch 22 there.
+
+Here's a way that will work:
+
+	git config remote.unknown.url foo
+	git config remote.unknown.annex-uuid 8bb266ed-453d-4489-9d8a-de38b2bc77c2
+	git annex dead unknown
+	git remote rm unknown
+"""]]
diff --git a/doc/forum/Remote_server_only_for_the_git_repository.mdwn b/doc/forum/Remote_server_only_for_the_git_repository.mdwn
new file mode 100644
index 0000000000..12f4c5c78f
--- /dev/null
+++ b/doc/forum/Remote_server_only_for_the_git_repository.mdwn
@@ -0,0 +1,3 @@
+Hi, I'm using git-annex 5.2014012 with the webapp and I've added two repositories: a remote server and a box.com account. When I add a file it is uploaded properly to both remotes as you would expect.
+
+The problem is that I would like the files to only be uploaded to box.com, and the remote server only store the git repository. Is there any way of saying to git-annex to not sync files to a remote server?
diff --git a/doc/forum/Remote_server_only_for_the_git_repository/comment_1_d4d8d8cfebf9a98ca8878c5684d5bb50._comment b/doc/forum/Remote_server_only_for_the_git_repository/comment_1_d4d8d8cfebf9a98ca8878c5684d5bb50._comment
new file mode 100644
index 0000000000..c97184cb82
--- /dev/null
+++ b/doc/forum/Remote_server_only_for_the_git_repository/comment_1_d4d8d8cfebf9a98ca8878c5684d5bb50._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 1"
+ date="2014-02-06T13:30:33Z"
+ content="""
+You can tell git-annex to ignore the repo (assuming git repo is called origin)
+
+     git config remote.origin.annex-ignore true
+"""]]
diff --git a/doc/forum/Remote_server_only_for_the_git_repository/comment_2_a62dec8ab98ac7bd65059a9e425a01e2._comment b/doc/forum/Remote_server_only_for_the_git_repository/comment_2_a62dec8ab98ac7bd65059a9e425a01e2._comment
new file mode 100644
index 0000000000..d02994628c
--- /dev/null
+++ b/doc/forum/Remote_server_only_for_the_git_repository/comment_2_a62dec8ab98ac7bd65059a9e425a01e2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
+ nickname="Jon Ander"
+ subject="comment 2"
+ date="2014-02-07T11:36:32Z"
+ content="""
+Thanks, that seams to be exactly what I need.
+Any change of adding this option to the webapp?
+"""]]
diff --git a/doc/forum/Remote_type_to_make_portable_HDD_like_normal_but_indexed.mdwn b/doc/forum/Remote_type_to_make_portable_HDD_like_normal_but_indexed.mdwn
new file mode 100644
index 0000000000..152990af2c
--- /dev/null
+++ b/doc/forum/Remote_type_to_make_portable_HDD_like_normal_but_indexed.mdwn
@@ -0,0 +1,13 @@
+Hello,
+
+I am pretty paranoid when it comes to my backups. I have a couple of live backups, but also take snapshots now and again and store these on offline hard drives in different places. I would like to use git-annex to keep track of what backup files I have and where. I encrypt all of my backup files, so the hard drive/repository does not need to be encrypted and I would prefer that so that there were fewer things that can go wrong -- I ideally want the files just sitting on the disk as a list of .gpg files, but with git annex able to tell me what I put on there/that the file I need is on there/count it towards any “number of copies” calculations.
+
+I have had a quick play with git annex and it seems I only have a couple of options:
+1) an (encrypted or unencrypted) bare repository, which I’m not keen on because I can’t see my files happily sitting there; or
+2) a clone of the whole git repository, but I’m concerned that this means any access details to things like my box.com account or whatever would be sitting on the drive in plaintext.
+
+Is there something else that I’ve missed or misunderstood?
+
+Many thanks!
+
+Aaron
diff --git a/doc/forum/Remote_type_to_make_portable_HDD_like_normal_but_indexed/comment_1_7caf32756f799b67b0c0588ea5e17a20._comment b/doc/forum/Remote_type_to_make_portable_HDD_like_normal_but_indexed/comment_1_7caf32756f799b67b0c0588ea5e17a20._comment
new file mode 100644
index 0000000000..26b472ef77
--- /dev/null
+++ b/doc/forum/Remote_type_to_make_portable_HDD_like_normal_but_indexed/comment_1_7caf32756f799b67b0c0588ea5e17a20._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Aaron"
+ subject="Any thoughts Joey?"
+ date="2016-09-10T15:15:44Z"
+ content="""
+Sorry to bump, but I'm trying to figure out what I'm going to use for a disk that I want to leave on the other side of the world in the next few weeks :).
+
+Any suggestions, Joey?
+"""]]
diff --git a/doc/forum/Remote_type_to_make_portable_HDD_like_normal_but_indexed/comment_2_36c202f5883b66a431ae5e72c5ecede1._comment b/doc/forum/Remote_type_to_make_portable_HDD_like_normal_but_indexed/comment_2_36c202f5883b66a431ae5e72c5ecede1._comment
new file mode 100644
index 0000000000..53f94b677e
--- /dev/null
+++ b/doc/forum/Remote_type_to_make_portable_HDD_like_normal_but_indexed/comment_2_36c202f5883b66a431ae5e72c5ecede1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-09-21T19:54:43Z"
+ content="""
+Suggest you use git-remote-gcrypt to encrypt the git repository stored on
+the backup drive. This will encrypt the whole git repository with
+your gpg key, and git-annex can also use it as a remote, and will encrypt
+the annexed files stored there too.
+
+See [[tips/fully_encrypted_git_repositories_with_gcrypt]].
+"""]]
diff --git a/doc/forum/Remove_unused_content_from_S3_special_remote.mdwn b/doc/forum/Remove_unused_content_from_S3_special_remote.mdwn
new file mode 100644
index 0000000000..84dc69bbf8
--- /dev/null
+++ b/doc/forum/Remove_unused_content_from_S3_special_remote.mdwn
@@ -0,0 +1,11 @@
+I've made a small mess of things and hoping I could get some advice to clean things up.
+
+I was experimenting with using a special remote (backblaze over s3). I had it synced to a repo, working fine, but then I wanted to re-use the bucket for another repo (and I removed the annex-uuid file so I can re-init -- I realize now that there is a better way).
+
+I'm in a situation now where the bucket has: 
+  - all the content for my current repo
+  - content from my previous repo (unencrypted, but unwanted by me)
+
+Is there a way to tell git-annex to "remove all files/keys from the special remote that aren't in my current repo"?
+
+I tried "git annex unused --from=backblaze", but this finds nothing.
diff --git a/doc/forum/Remove_unused_content_from_S3_special_remote/comment_1_acfd4eab2cd80d722479dbb410ccfe2e._comment b/doc/forum/Remove_unused_content_from_S3_special_remote/comment_1_acfd4eab2cd80d722479dbb410ccfe2e._comment
new file mode 100644
index 0000000000..8b6d882076
--- /dev/null
+++ b/doc/forum/Remove_unused_content_from_S3_special_remote/comment_1_acfd4eab2cd80d722479dbb410ccfe2e._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-03-16T19:08:41Z"
+ content="""
+There is not a way to do that using only git-annex.
+
+If the new S3 remote is encrypted and the old one was unencrypted,
+you can easily tell which files in the bucket are encrypted and not based
+on their names and delete those. The encrypted files have names starting
+with "GPGHMAC"
+
+If the new S3 remote is not encrypted, you can generate a list of all
+the keys that are expected to be in it like this:
+
+	git-annex whereis --all --in dir --format='${hashdirlower}${key}\n' | sort > wanted
+
+If you then use some S3 tool to generate a list of all the files in the
+bucket, and put that list in a file named "all", you can then use
+`comm` to find the files that are in "all" that are not in "wanted":
+
+	sort all > all-sorted
+	comm -1 -3 wanted all-sorted
+
+Then you can use some S3 tool to delete the other files.
+"""]]
diff --git a/doc/forum/Remove_unused_content_from_S3_special_remote/comment_2_adc602d325b8639ac5bfed088c504e1e._comment b/doc/forum/Remove_unused_content_from_S3_special_remote/comment_2_adc602d325b8639ac5bfed088c504e1e._comment
new file mode 100644
index 0000000000..fd35df6d88
--- /dev/null
+++ b/doc/forum/Remove_unused_content_from_S3_special_remote/comment_2_adc602d325b8639ac5bfed088c504e1e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="rafd"
+ avatar="http://cdn.libravatar.org/avatar/3b62606b59d2d76ac21e16073dbd2424"
+ subject="comment 2"
+ date="2022-03-17T16:09:38Z"
+ content="""
+Thanks joey. I was able to make it work similar to how you suggested.
+"""]]
diff --git a/doc/forum/Remove_variants_from_all_repositories___40__and_possibly_restore_the_original_naming__41__.mdwn b/doc/forum/Remove_variants_from_all_repositories___40__and_possibly_restore_the_original_naming__41__.mdwn
new file mode 100644
index 0000000000..8a62a6e406
--- /dev/null
+++ b/doc/forum/Remove_variants_from_all_repositories___40__and_possibly_restore_the_original_naming__41__.mdwn
@@ -0,0 +1 @@
+I, by mistake, added some files directly to the remote locations and my local repository, afterwards, using `git annex get '*'` to get "all" the new files from the remotes I created some `file.variant-xxxx.ext` files. For me this is undesirable. I'm sure the files are almost the same (I'm presuming some metadata got changed, they are audio files) so I want to remove one keeping the other and removing the `variant-xxxx` string. Is there a way this is possible without manually drooping/renaming all these files?
diff --git a/doc/forum/Remove_variants_from_all_repositories___40__and_possibly_restore_the_original_naming__41__/comment_1_dfc64d8618e07177bb196d9af4474698._comment b/doc/forum/Remove_variants_from_all_repositories___40__and_possibly_restore_the_original_naming__41__/comment_1_dfc64d8618e07177bb196d9af4474698._comment
new file mode 100644
index 0000000000..7f31058901
--- /dev/null
+++ b/doc/forum/Remove_variants_from_all_repositories___40__and_possibly_restore_the_original_naming__41__/comment_1_dfc64d8618e07177bb196d9af4474698._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-01-05T20:12:56Z"
+ content="""
+Probably the best thing to do is to use `git log --stat` 
+to find the commits that were made on the remote that added the conflicting
+files. Also find the merge commit that created the variant
+files. You can then `git revert` the merge commit, and follow up by `git
+revert` the commits that added the conflicting files. This will bring your
+working tree back to the state it was in originally.
+
+Alternatively, if your current repo has the contents present for 
+the variants of the files you want to keep, while the remote repos contain
+the contents of the variants you want to delete, you could use this command
+to delete the variants that don't have their contents in the local repo:
+
+	git annex find --include='*.variant-*' --not --in here --print0 | xargs -0 rm
+"""]]
diff --git a/doc/forum/Removing_files_not_found_by_git_annex_unused.mdwn b/doc/forum/Removing_files_not_found_by_git_annex_unused.mdwn
new file mode 100644
index 0000000000..ce0aedc51d
--- /dev/null
+++ b/doc/forum/Removing_files_not_found_by_git_annex_unused.mdwn
@@ -0,0 +1,29 @@
+Hi,
+
+I've removed some large files with git remove, but seem to be unable to remove the corresponding annex content.
+
+Example:
+
+kheymann@corax:~/annex$ find -name "*s24576--10daa3d9007edad720dc057e4272a9c6cda930bef34a83e3bc1d93f1c55b9cac" 
+
+./.git/annex/objects/jF/j7/SHA256-s24576--10daa3d9007edad720dc057e4272a9c6cda930bef34a83e3bc1d93f1c55b9cac
+
+./.git/annex/objects/jF/j7/SHA256-s24576--10daa3d9007edad720dc057e4272a9c6cda930bef34a83e3bc1d93f1c55b9cac/SHA256-s24576--10daa3d9007edad720dc057e4272a9c6cda930bef34a83e3bc1d93f1c55b9cac
+
+kheymann@corax:~/annex$ git annex dropkey -vvv --backend SHA256 s24576--10daa3d9007edad720dc057e4272a9c6cda930bef34a83e3bc1d93f1c55b9cac
+
+No output but the files remain in the annex. Git annex fsck and git annex unused run without listing files to be removes. What can I do apart from deleting the files manually from the annex?
+
+Some info:
+
+    kheymann@corax:~/annex$ git annex version
+    git-annex version: 3.20121017
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3
+    upgrade supported from repository versions: 0 1 2
+
+Any hints?
+
+Best, 
+Karsten
diff --git a/doc/forum/Removing_files_not_found_by_git_annex_unused/comment_1_420c6230e68de0a0ac7d7da91ac60801._comment b/doc/forum/Removing_files_not_found_by_git_annex_unused/comment_1_420c6230e68de0a0ac7d7da91ac60801._comment
new file mode 100644
index 0000000000..f932f779cf
--- /dev/null
+++ b/doc/forum/Removing_files_not_found_by_git_annex_unused/comment_1_420c6230e68de0a0ac7d7da91ac60801._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 1"
+ date="2012-11-09T19:37:24Z"
+ content="""
+Please ignore my previous post, by following the instructions in the comment in http://git-annex.branchable.com/walkthrough/unused_data/ I was able to get rid of the data.
+"""]]
diff --git a/doc/forum/Removing_git-annex_repo/comment_1_58fcceb96647a8c7f33d188ae908f3bd._comment b/doc/forum/Removing_git-annex_repo/comment_1_58fcceb96647a8c7f33d188ae908f3bd._comment
new file mode 100644
index 0000000000..d03ca6b4e0
--- /dev/null
+++ b/doc/forum/Removing_git-annex_repo/comment_1_58fcceb96647a8c7f33d188ae908f3bd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.144"
+ subject="comment 1"
+ date="2014-09-25T15:44:16Z"
+ content="""
+chmod u+w -R ~/annex/.git
+"""]]
diff --git a/doc/forum/Rename_local_repository_for_git-annex-info.mdwn b/doc/forum/Rename_local_repository_for_git-annex-info.mdwn
new file mode 100644
index 0000000000..1c26974314
--- /dev/null
+++ b/doc/forum/Rename_local_repository_for_git-annex-info.mdwn
@@ -0,0 +1,32 @@
+I initialized local repository with
+
+    git-annex init $HOSTNAME --version=6
+
+unfortunately I didn't change HOSTNAME on a new machine and it was 'localhost.localdomain'. I didn't notice that before I cloned a git-annex repository.
+
+Now in the remote repository when I run `git-annex info` (and same in local repository), I see
+
+    $ git-annex info
+    ...
+    semitrusted repositories: 6
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	0085(maybe it's not secure to write it on the internet)-e8f803a -- localhost.localdomain
+    ...
+
+(and other repositories. By the way, I never initialized 'web' and 'bittorent', where did they get from?)
+
+I would like 'localhost.localdomain' to become my real $HOSTNAME, so that I would distinguish that machine. How could I do that?
+
+I found [How to rename a remote](https://git-annex.branchable.com/forum/How_to_rename_a_remote__63__/), but my 'localhost' is not listed in git-remotes. 
+
+I grep-ed .git for 'localhost.localdomain', and changed `.git/COMMIT_EDITMSG`. However, after running git-annex sync it returns to 'localhost.localdomain'.
+
+    $ more .git/COMMIT_EDITMSG
+    git-annex in Acer
+    $ git-annex sync
+    ...
+    $ more .git/COMMIT_EDITMSG
+    git-annex in localhost.localdomain
+
+I would like to change 'localhost' to my real machine name both on the remote repository from which I cloned and on local repository. Thank you.
diff --git a/doc/forum/Rename_local_repository_for_git-annex-info/comment_1_6df9b666f7d948b9e03b2ecf9858f6c5._comment b/doc/forum/Rename_local_repository_for_git-annex-info/comment_1_6df9b666f7d948b9e03b2ecf9858f6c5._comment
new file mode 100644
index 0000000000..5c08afa2a9
--- /dev/null
+++ b/doc/forum/Rename_local_repository_for_git-annex-info/comment_1_6df9b666f7d948b9e03b2ecf9858f6c5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-12-05T17:32:58Z"
+ content="""
+That's not the name of the repository, it's a description of the
+repository.
+
+You can use `git annex describe` to adjust the description of that
+or any repository. This will affect all clones of the repository
+once the description change is synced out to them.
+"""]]
diff --git a/doc/forum/Rename_local_repository_for_git-annex-info/comment_2_a13ef241d6d24b4abee3eedff18032a8._comment b/doc/forum/Rename_local_repository_for_git-annex-info/comment_2_a13ef241d6d24b4abee3eedff18032a8._comment
new file mode 100644
index 0000000000..6080a6fdbe
--- /dev/null
+++ b/doc/forum/Rename_local_repository_for_git-annex-info/comment_2_a13ef241d6d24b4abee3eedff18032a8._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="jodumont"
+ avatar="http://cdn.libravatar.org/avatar/343b334cbc4b2bff019ab6b525a2c9ed"
+ subject="how to rename/remove the [here] ??"
+ date="2021-02-19T04:56:46Z"
+ content="""
+I'm able to change the description of my repo but not the name, which is by default and in that case **[here]**
+
+> user@machine:/srv/data$ git-annex info  
+trusted repositories: 0  
+semitrusted repositories: 3  
+00000000-0000-0000-0000-000000000001 -- web  
+00000000-0000-0000-0000-000000000002 -- bittorrent  
+xxxxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxxx -- sub.domain.tld:/srv/data **[here]**  
+untrusted repositories: xxx  
+transfers in progress: xxxx  
+available local disk space: 2.03 petabytes (+1 gigabyte reserved)  
+
+## How I could edit the name and/or name it properly when I init it ?
+
+"""]]
diff --git a/doc/forum/Rename_local_repository_for_git-annex-info/comment_3_c75652b23bc4554d43593d1984c9c5d9._comment b/doc/forum/Rename_local_repository_for_git-annex-info/comment_3_c75652b23bc4554d43593d1984c9c5d9._comment
new file mode 100644
index 0000000000..3d268b811c
--- /dev/null
+++ b/doc/forum/Rename_local_repository_for_git-annex-info/comment_3_c75652b23bc4554d43593d1984c9c5d9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2021-02-19T07:28:12Z"
+ content="""
+AFAIK, the `[here]` can't be changed, it just means \"it is this local repository\". Now, if you add another repository as a git remote, then it'll show `<description>[<name of git remote>]` for the git remote.
+"""]]
diff --git a/doc/forum/Rename_local_repository_for_git-annex-info/comment_4_695a821eee66f8c4d4e22518edd15c40._comment b/doc/forum/Rename_local_repository_for_git-annex-info/comment_4_695a821eee66f8c4d4e22518edd15c40._comment
new file mode 100644
index 0000000000..f744fc196b
--- /dev/null
+++ b/doc/forum/Rename_local_repository_for_git-annex-info/comment_4_695a821eee66f8c4d4e22518edd15c40._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-02-22T16:30:37Z"
+ content="""
+Yes, "here" is hardcoded. It could be made configurable in the git config,
+if there's actually a good reason to want to.
+"""]]
diff --git a/doc/forum/Repair_in_steps__63__.mdwn b/doc/forum/Repair_in_steps__63__.mdwn
new file mode 100644
index 0000000000..b8b40142c6
--- /dev/null
+++ b/doc/forum/Repair_in_steps__63__.mdwn
@@ -0,0 +1,5 @@
+If I understand correctly, 'git annex repair' first runs 'git fsck' and then tries to repair the repository by connecting to available remotes.
+
+It can take a long time when 'git annex repair' runs 'git fsck' (at least 14 hours in my case). For me, it is not very convenient to have the remotes available during this entire time. It would be nice if I could connect to them only when necessary. This makes me wonder if it is possible to separate the running of git fsck from the operation of connecting to the remotes to repair the local repository. Or similarly, it would be nice to be able to run 'git annex repair' again quickly if it had just ran.
+
+Thanks for any help on this
diff --git a/doc/forum/Repair_in_steps__63__/comment_1_6a512ab2d6ea583a1913c9837e953760._comment b/doc/forum/Repair_in_steps__63__/comment_1_6a512ab2d6ea583a1913c9837e953760._comment
new file mode 100644
index 0000000000..37071f1947
--- /dev/null
+++ b/doc/forum/Repair_in_steps__63__/comment_1_6a512ab2d6ea583a1913c9837e953760._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-04T17:07:55Z"
+ content="""
+The command uses `git fsck` to get a list of git objects that are missing
+from the repository. It then tries to get those objects from remotes. So,
+skipping the fsck is not really possible.
+
+Also in some cases, it may need to fsck again after the initial pass.
+
+You must have an exceptionally large git repo (and/or slow computer) for git
+fsck to take more than several minutes.
+
+I wonder if passing --connectivity-only to git fsck speeds it up
+significantly for you? Actually corrupted blobs are probably much rarer
+than blobs that are just missing, so it might be that git annex repair
+could optionally use that to run fsck faster.
+"""]]
diff --git a/doc/forum/Replace_glacier-cli__63__.mdwn b/doc/forum/Replace_glacier-cli__63__.mdwn
new file mode 100644
index 0000000000..3557cc2529
--- /dev/null
+++ b/doc/forum/Replace_glacier-cli__63__.mdwn
@@ -0,0 +1,13 @@
+I was looking for a good way to archive files to Glacier, and git-annex seems like an excellent approach.
+
+After struggling for a while with the glacier-cli project, I just don't feel that it is well maintained.
+
+ - I have to manually symlink it in place of its dependency's glacier binary.
+ - There are patches to boto that are required for it to work, which are have never been merged. And it seems from the errors I am getting that similar edits are now required in many more places.
+ - It is locked into supporting only an older version of boto.
+
+That just seems like not a great place to be starting out with an archiving project.
+
+I was wondering if you thought it might be feasible to get rid of that dependency with something else, perhaps this haskell aws project that seems to be actively maintained?
+
+https://github.com/aristidb/aws
diff --git a/doc/forum/Replace_glacier-cli__63__/comment_1_318cd0ca9f4e997161ed22fffa5d5da3._comment b/doc/forum/Replace_glacier-cli__63__/comment_1_318cd0ca9f4e997161ed22fffa5d5da3._comment
new file mode 100644
index 0000000000..f87c8e4f6d
--- /dev/null
+++ b/doc/forum/Replace_glacier-cli__63__/comment_1_318cd0ca9f4e997161ed22fffa5d5da3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-02-08T17:17:10Z"
+ content="""
+There's been an open feature request on the haskell aws
+for 5 years to support glacier <https://github.com/aristidb/aws/issues/81>
+at this point I am doubtful anything will ever happen there.
+
+The most likely approach seems to be to use the amazonka library, which
+supports S3 with a Glacier lifecycle. git-annex's S3 remote could be
+rewritten to use that.
+
+I think it should be possible to set up a S3 bucket and configure it with
+some web tool to have a Glacier lifecycle, and then use the existing
+git-annex S3 support to access it. Except for the problem documented at
+[[todo/wishlist__58___Restore_s3_files_moved_to_Glacier]].
+"""]]
diff --git a/doc/forum/Replace_glacier-cli__63__/comment_2_c91e393951825cdcceac845e234d7497._comment b/doc/forum/Replace_glacier-cli__63__/comment_2_c91e393951825cdcceac845e234d7497._comment
new file mode 100644
index 0000000000..ac7596a4b3
--- /dev/null
+++ b/doc/forum/Replace_glacier-cli__63__/comment_2_c91e393951825cdcceac845e234d7497._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="moaxey"
+ avatar="http://cdn.libravatar.org/avatar/06abae5b84ce9bbcd39c1cbf49817d29"
+ subject="Thanks"
+ date="2018-02-19T20:57:09Z"
+ content="""
+I have it working smoothly now with glacier-cli.
+"""]]
diff --git a/doc/forum/Replace_glacier-cli__63__/comment_3_405aad8dd28ea035226f7fda470fde33._comment b/doc/forum/Replace_glacier-cli__63__/comment_3_405aad8dd28ea035226f7fda470fde33._comment
new file mode 100644
index 0000000000..bcabcb13e2
--- /dev/null
+++ b/doc/forum/Replace_glacier-cli__63__/comment_3_405aad8dd28ea035226f7fda470fde33._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="switching to amazonka"
+ date="2018-02-21T18:15:05Z"
+ content="""
+Switching to amazonka would have the benefit of supporting SSL traffic for S3, which is a feature I would enjoy (see git-annex forum thread [No SSL traffic for S3?](http://git-annex.branchable.com/forum/No_SSL_traffic_for_S3__63__/)). I have no experience with the amazonka library though, so I can't comment on it.
+
+—Andrew
+"""]]
diff --git a/doc/forum/Replace_glacier-cli__63__/comment_4_a863eb91006df199fcdbc98f42b2d40b._comment b/doc/forum/Replace_glacier-cli__63__/comment_4_a863eb91006df199fcdbc98f42b2d40b._comment
new file mode 100644
index 0000000000..1a30822dee
--- /dev/null
+++ b/doc/forum/Replace_glacier-cli__63__/comment_4_a863eb91006df199fcdbc98f42b2d40b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="abimelech@632162f535b3bbc90e3336b14ceef969c41c05a2"
+ nickname="abimelech"
+ avatar="http://cdn.libravatar.org/avatar/057e618fbf211a3733e9fef66030c0b9"
+ subject="I've been using amazonka-glacier to stream uploads to glacier"
+ date="2018-06-27T21:50:45Z"
+ content="""
+Could write a command-line app for it. I also have a couple open PRs against amazonka to fix the glacier support.
+"""]]
diff --git a/doc/forum/Replace_glacier-cli__63__/comment_5_fda6c754437385afa0851e680bf17cf0._comment b/doc/forum/Replace_glacier-cli__63__/comment_5_fda6c754437385afa0851e680bf17cf0._comment
new file mode 100644
index 0000000000..3da6bc450b
--- /dev/null
+++ b/doc/forum/Replace_glacier-cli__63__/comment_5_fda6c754437385afa0851e680bf17cf0._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-07-02T16:39:16Z"
+ content="""
+@abimelech, why don't you work up a branch that makes the glacier special
+remote be implemented with amazonka. If you want to start with a
+separate utility that git-annex runs, that would be ok, but I think that
+the goal should be for git-annex to end up using amazonka itself.
+
+Once that happens, switching the S3
+special remote from aws to amazonka would be a natural next step, which I'd
+be inclined to work on myself. Seems easier to take this path than an
+immediate leap to amazonka for everything.
+"""]]
diff --git a/doc/forum/Replace_glacier-cli__63__/comment_6_2e7b5b6cc7c2e33be36c3c510adec01c._comment b/doc/forum/Replace_glacier-cli__63__/comment_6_2e7b5b6cc7c2e33be36c3c510adec01c._comment
new file mode 100644
index 0000000000..074731304f
--- /dev/null
+++ b/doc/forum/Replace_glacier-cli__63__/comment_6_2e7b5b6cc7c2e33be36c3c510adec01c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="abimelech@632162f535b3bbc90e3336b14ceef969c41c05a2"
+ nickname="abimelech"
+ avatar="http://cdn.libravatar.org/avatar/057e618fbf211a3733e9fef66030c0b9"
+ subject="comment 6"
+ date="2018-07-07T00:09:48Z"
+ content="""
+I've never used git-annex, so I'm not particularly enthusiastic about developing for it. If someone could describe what glacier actions are needed I could maybe code something up.
+In any case, wouldn't we want to wait until a version of amazonka with functioning glacier support is released? Unless you'd want to add my git fork of the repo as a dependency...
+"""]]
diff --git a/doc/forum/Replacing_a_special_remote_by_another_one.mdwn b/doc/forum/Replacing_a_special_remote_by_another_one.mdwn
new file mode 100644
index 0000000000..bc831d54bc
--- /dev/null
+++ b/doc/forum/Replacing_a_special_remote_by_another_one.mdwn
@@ -0,0 +1,3 @@
+Hi!
+
+I'm using a rclone special remote for Wasabi, with hybrid encryption. I'd like to switch to S3 remote instead of rclone (as Wasabi is S3-compatible). Is it possible? I'd like to keep the same uploaded files, with the same encryption.
diff --git a/doc/forum/RepoFS__58___File_system_view_of_Git_repositories.mdwn b/doc/forum/RepoFS__58___File_system_view_of_Git_repositories.mdwn
new file mode 100644
index 0000000000..9918dcb6a0
--- /dev/null
+++ b/doc/forum/RepoFS__58___File_system_view_of_Git_repositories.mdwn
@@ -0,0 +1 @@
+Of potential interest: [RepoFS: File system view of Git repositories](https://www.sciencedirect.com/science/article/pii/S2352711018300712)
diff --git a/doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex.mdwn b/doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex.mdwn
new file mode 100644
index 0000000000..bcf2a87a39
--- /dev/null
+++ b/doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex.mdwn
@@ -0,0 +1,11 @@
+Hi,
+
+I'm trying to figure out if it's possible to have a remote that allows access from _clients without git-annex_. That is a remote type that presents itself as a client repo. I'm probably missing something obvious.
+
+Ideally I'd like to use my Nokia N900 phone as a ssh remote from which I can open files on any computer when the device is connected via usb in mass storage mode. This would allow me to access my files when I'm using a computer at work or at a friends house without installing git-annex. The phone has an ext3 partition so links are possible. Naturally I'd have to ensure the files I want are on the device before I leave the house.
+
+I'd also like to be able to scp files from my ssh remote when on git-annex less devices. Unfortunately the ssh/rsync repo presents no links or normal filenames.
+
+Git annex, and the assistant is working really smoothly between my local computers and my server on the internet. Setting things up with the webapp is super simple. Great work!
+
+
diff --git a/doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex/comment_1_077c492fd37d335f74a5c886ff0d524f._comment b/doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex/comment_1_077c492fd37d335f74a5c886ff0d524f._comment
new file mode 100644
index 0000000000..4e724ff55e
--- /dev/null
+++ b/doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex/comment_1_077c492fd37d335f74a5c886ff0d524f._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 1"
+ date="2013-01-20T20:20:06Z"
+ content="""
+This is off the top of my head, so I may be wrong on details:
+
+An ssh remote, or a USB remote, when you create it with the assistant, is a bare repo.  The files in it are not visible or accessible except through a clone of it (such as your client repo).
+
+You *could* make an SSH remote or USB remote as a *non-bare repo*, in which case the files within it would be visible and accessible just like on a client repo.  You could set that up using the command line; the assistant doesn't do it, but once you got it set up on the command line the assistant would use it just like normal.
+
+There is a catch though.  Though potentially available, the files in that repo don't actually show up until you run \"git annex sync\" in that repo.  Because git annex does not update the checked out branch of a remote.  So you'd have to cd into that repo manually and run \"git annex sync\" to make the latest-and-greatest files available.
+
+Here's how I'd do this...
+
+If the git annex assistant is running, turn it off.
+
+follow the instructions here: http://git-annex.branchable.com/walkthrough/  under \"adding a remote\" on your usb drive.  You now have a non-bare remote.
+
+Fire up the assistant and you'll see that that is now one of your remotes.  Configure it to \"backup\" or whatever you want.  Let the assistant fill it up with content.
+
+When you want to take it someplace, get on the command line and \"cd /wherever/my/usb/drive/is/annex\" and then do: \"git annex sync\" -- that will update the links to the content so you can actually see it.
+
+You now have all your content available on your USB drive.
+
+You can do a similar process to manually create a non-bare SSH remote, and you can ssh in and run \"git annex sync\" to update its links and make the content available, which you can then retrieve va scp or sftp, or for that matter, you could configure a web server or WebDAV to serve it up if you like.
+
+The only complication is running git-annex sync to update your links.
+
+Again, this is all off the top of my head, I haven't looked up or tested anything here so I welcome correction.  But I think what you want to do can be pretty straightforward if you're willing to go behind Assistant's back to do the setup work, and run \"git annex sync\" when you need to.
+"""]]
diff --git a/doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex/comment_2_00e6576e3e60d2650461eeb0f918e6e5._comment b/doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex/comment_2_00e6576e3e60d2650461eeb0f918e6e5._comment
new file mode 100644
index 0000000000..64f111921a
--- /dev/null
+++ b/doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex/comment_2_00e6576e3e60d2650461eeb0f918e6e5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 2"
+ date="2013-01-21T07:02:17Z"
+ content="""
+An alternative to running git annex sync in the non-bare remote is running an assistant there.
+"""]]
diff --git a/doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex/comment_3_c36a9562c53ac683b62fc4471405aa2a._comment b/doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex/comment_3_c36a9562c53ac683b62fc4471405aa2a._comment
new file mode 100644
index 0000000000..db7dec37f2
--- /dev/null
+++ b/doc/forum/Repo_accessible_from___34__dumb__34___client_without_git-annex/comment_3_c36a9562c53ac683b62fc4471405aa2a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3HGoDpnOPob5jOjvIootmkve1-nCpRiI"
+ nickname="Kalle"
+ subject="Thanks for the help"
+ date="2013-01-21T20:40:39Z"
+ content="""
+I take it all the above requires mounting an sshfs filsystem of the remote client to run the git-annex or the assistant \"locally\" on the desktop or laptop. Or am I missing something.
+
+For the usb usecase a normal mount would suffice of course.
+
+The lack of automation means running a rsync script from (or to) the phone is easier. Not as clever though :( and means running a separate \"system\" for distributing files to the phone.
+
+Thanks again!
+
+"""]]
diff --git a/doc/forum/Repository_backup.mdwn b/doc/forum/Repository_backup.mdwn
new file mode 100644
index 0000000000..39501f7005
--- /dev/null
+++ b/doc/forum/Repository_backup.mdwn
@@ -0,0 +1,5 @@
+What's the best way of backing up the git repository itself? I feel fairly comfortable using a special remote to create an offsite backup in S3 or Glacier or whatnot, but restoring from those still requires I have a working repository somewhere that can map chunks back to files, no? 
+
+I can probably just create a repo that has no content, tar it up, and store it on my backup medium (or on bitbucket or wherever), but that seems kinda hackish--it'd be nice to handle this within git-annex. In fact, it'd be really neat if I could handle this with any existing special remote--for example, if there were a way to commit and restore the git repo state (and symlink tree) to the remote. But that doesn't seem to exist. Is there a recommended approach for this? Am I just missing something obvious?
+
+Thanks. 
diff --git a/doc/forum/Repository_backup/comment_1_4d3197a1fefeb744e8b1e1b5fcf9b104._comment b/doc/forum/Repository_backup/comment_1_4d3197a1fefeb744e8b1e1b5fcf9b104._comment
new file mode 100644
index 0000000000..c668a4b6d7
--- /dev/null
+++ b/doc/forum/Repository_backup/comment_1_4d3197a1fefeb744e8b1e1b5fcf9b104._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-25T18:14:42Z"
+ content="""
+The best way is to make a git remote and let `git-annex sync`
+sync with it. You can put the git remote on github, gitorious, any
+server with ssh, any server with rsync, a local backup drive, etc.
+
+Special remotes are key/value storage; this is not a very good
+match for the access patterns needed for a git remote.
+"""]]
diff --git a/doc/forum/Repository_backup/comment_2_e362221ef3d13bd417b2b6b0c51738a8._comment b/doc/forum/Repository_backup/comment_2_e362221ef3d13bd417b2b6b0c51738a8._comment
new file mode 100644
index 0000000000..e84be7f22a
--- /dev/null
+++ b/doc/forum/Repository_backup/comment_2_e362221ef3d13bd417b2b6b0c51738a8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnb2yfWzJ2lYQw1UTm6XVZ4y8qashNagZA"
+ nickname="Daniel"
+ subject="Re: comment1"
+ date="2015-02-26T12:48:56Z"
+ content="""
+Thanks for the tip!
+
+Yeah, I get that special remotes aren't meant for this, and backing up a bare (i.e. contentless) git repo somewhere else is pretty trivial. My only point was that it'd be nice to have a single unified offsite backup--if you backup the content to S3, say, and the git repo itself to Github, you now have two points of failure and, in some sense, twice the management hassle. (I now need both my Amazon and Github credentials to restore, for example.) 
+
+This seems somewhat undesirable in a backup system. 
+
+An easy way around this may be for me to just have a wrapper script that first backs up content to the special remote and then copies the .git repo (minus the objects) to the same place. So it's something I can easily enough work around. 
+"""]]
diff --git a/doc/forum/Repository_backup/comment_3_ead30baf0a6d718569feb4002ba19b9e._comment b/doc/forum/Repository_backup/comment_3_ead30baf0a6d718569feb4002ba19b9e._comment
new file mode 100644
index 0000000000..3db7f7d18d
--- /dev/null
+++ b/doc/forum/Repository_backup/comment_3_ead30baf0a6d718569feb4002ba19b9e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="git-annex.branchable.com@69b3f2da2837a3d9de8eab0b93771008294b7d69"
+ nickname="git-annex.branchable.com"
+ subject="Does a tar of `.git` solve the problem"
+ date="2016-01-28T19:03:08Z"
+ content="""
+Just wondering if tarring .git (excluding .git/annex of course}) into a file in the root of the repo will serve this purpose? Seems like it would to me... How would one restore from this... it'd be (practically) a bare repo right?
+"""]]
diff --git a/doc/forum/Repository_backup/comment_4_6f20653dff70aaaea4460a5efb28081f._comment b/doc/forum/Repository_backup/comment_4_6f20653dff70aaaea4460a5efb28081f._comment
new file mode 100644
index 0000000000..fa44e679bf
--- /dev/null
+++ b/doc/forum/Repository_backup/comment_4_6f20653dff70aaaea4460a5efb28081f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-01-29T18:02:14Z"
+ content="""
+Storing a tarball of the .git repository as a file inside the repository
+presents a chicken and egg problem when it comes to restoring it. You'll
+have to find the object file that git-annex has stored in the special
+remote. If the special remote is encrypted, you may not be able to decrypt
+it without the key stored in the repository. Etc.
+
+Better to make a clone of the git repository elsewhere.
+"""]]
diff --git a/doc/forum/Repository_backup/comment_5_287510b4e8b9043fe361b7c5dc1f4e9f._comment b/doc/forum/Repository_backup/comment_5_287510b4e8b9043fe361b7c5dc1f4e9f._comment
new file mode 100644
index 0000000000..2fac3bccc1
--- /dev/null
+++ b/doc/forum/Repository_backup/comment_5_287510b4e8b9043fe361b7c5dc1f4e9f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="sts"
+ subject="comment 5"
+ date="2016-06-27T19:36:58Z"
+ content="""
+I always backup my git-annex repos using 'git bundle create ... --all' which is similar to a git clone, but much more convenient for backups, because it is just a single file :).
+"""]]
diff --git a/doc/forum/Repository_operations_stuck_suddenly.mdwn b/doc/forum/Repository_operations_stuck_suddenly.mdwn
new file mode 100644
index 0000000000..f244b90ca4
--- /dev/null
+++ b/doc/forum/Repository_operations_stuck_suddenly.mdwn
@@ -0,0 +1,9 @@
+Just stopped a `git status` call that was stuck for hours on the following line:
+
+    refresh index:  13% (30610/235456)
+
+That problem suddenly occurred this weekend after I `git annex add`ed some files. I haven't called status or anything before, but last time I used that drive it worked well.
+
+Other commands like `git commit` also just don't do anything and can't overcome a `S+` state. Problem happens on both macOS and Linux hosts. Nothing in the kernel log that indicates drive IO problems or something similar.
+
+Any idea what might lead to this?
diff --git a/doc/forum/Repository_operations_stuck_suddenly/comment_1_b0fa5b0e1b507e9a99e62849b1d66b7e._comment b/doc/forum/Repository_operations_stuck_suddenly/comment_1_b0fa5b0e1b507e9a99e62849b1d66b7e._comment
new file mode 100644
index 0000000000..027a9e75e4
--- /dev/null
+++ b/doc/forum/Repository_operations_stuck_suddenly/comment_1_b0fa5b0e1b507e9a99e62849b1d66b7e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2023-06-27T09:01:00Z"
+ content="""
+Next time, you could attach to the stuck git command with `gdb` see where it hangs. Could very well be something with the git-annex smudge/clean filters.
+"""]]
diff --git a/doc/forum/Repository_operations_stuck_suddenly/comment_2_ff76dc687c2f632b39240d5e242d41f4._comment b/doc/forum/Repository_operations_stuck_suddenly/comment_2_ff76dc687c2f632b39240d5e242d41f4._comment
new file mode 100644
index 0000000000..6a5920d5ab
--- /dev/null
+++ b/doc/forum/Repository_operations_stuck_suddenly/comment_2_ff76dc687c2f632b39240d5e242d41f4._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-06-28T17:09:07Z"
+ content="""
+If it gets fully stuck and the number is not increasing at all, I'd second
+the suggestion to gdb, or run git with `GIT_TRACE=1 GIT_TRACE_PACKET=1`
+
+If it's increasingly but slowly, it might be that you have an older version
+of git-annex, or a repository using git-annex format v8. That makes git
+have to run git-annex once per file it needs to update the status of.
+(Why git needs to update the status of so many files I don't know, but
+there are certianly situations where it could.)
+Upgrading to git-annex v10 lets git run git-annex only once, so will be a
+lot faster.
+"""]]
diff --git a/doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__.mdwn b/doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__.mdwn
new file mode 100644
index 0000000000..9c19b9b8c7
--- /dev/null
+++ b/doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__.mdwn
@@ -0,0 +1,9 @@
+Greetings.  Here is my desired usage scenario:
+
+I have setup a server and three laptops which I am syncing over ssh. Each laptop may access the server, but because different people are using each of the laptops, they may not sync between laptops for security/privacy.
+
+Each of the laptops will be adding content to the repository, and each of the laptops will be using the new content that the others have added.
+
+Currently, in order to make all content available to all users, I'm having to ssh into the server and use `git annex get .` every time new content is added from one of the laptops, which is a pain. Is there a way to require a local copy of all content in a given repository so that is pulled/pushed automatically? I would like for each laptop to be able to add new content to their copies of the repository and sync with the server, after which each other laptop can access the content through the server.
+
+Thanks!
diff --git a/doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__/comment_1_8adf9c6d2a3ef29120703bfa1b8f9ae2._comment b/doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__/comment_1_8adf9c6d2a3ef29120703bfa1b8f9ae2._comment
new file mode 100644
index 0000000000..12aef24737
--- /dev/null
+++ b/doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__/comment_1_8adf9c6d2a3ef29120703bfa1b8f9ae2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-21T19:46:44Z"
+ content="""
+This is generally handled by using either `git annex sync --content`, which will make the laptops upload new files to the server before they push the git repository to it, or by using the git-annex assistant (on the laptops or perhaps on the server) to automatically copy files. Either way, you configure [[preferred_content]] settings to control which repositories want which  files.
+"""]]
diff --git a/doc/forum/Required_Content_Always_True___40____61____62___cannot_drop__41__.mdwn b/doc/forum/Required_Content_Always_True___40____61____62___cannot_drop__41__.mdwn
new file mode 100644
index 0000000000..0e4332efc5
--- /dev/null
+++ b/doc/forum/Required_Content_Always_True___40____61____62___cannot_drop__41__.mdwn
@@ -0,0 +1,82 @@
+Hey there,
+
+I am having the issue that git-annex reports files to be required even though it should not be.
+
+The setup is as follows (The groups that the repo is part of is specified in brackets):
+
+- Main repo (`origin`, `server`) on a server
+    - Regularly syncs all its data two two backup repos (`server`, `backup`, `backup_server`)
+        - These two backup repos are trusted, as they are not reachable by clients
+- Client repo (`client`) on PC
+    - Syncs with other clients via the server
+    - Manually syncs with a backup repo (`backup` `offline`, `backup_offline`) on a disk
+    - Each client has two remotes, the server (named `origin`) and the backup drive (named `usb`)
+
+I want that the required content is everything present, that is not yet (all of them):
+
+1. in the server repo
+2. in both server backup repos
+3. in a backup repo on an external drive
+
+I specify that using `git annex required . "present and (copies=origin:0 or (not copies=backup_server:2) or copies=backup_offline:0)"`.
+
+Now I want to drop file `A`
+
+File `A` is present on 5 repos. However, I cannot delete it, as it is "apparently" not on the server (i.e. `copies=origin:0` is true).
+
+```
+$ git annex whereis A
+whereis A (5 copies)
+  	0cdca96a-e44d-4168-a3a0-8ab846451e74 -- Server_Backup2
+   	44039708-f0d9-4ed0-833b-4d146d419b5d -- jeanclaude [here]
+   	4ac4c649-b37c-403e-94e0-9497a7bc2a91 -- Server_Backup1
+   	c0d1b661-1e19-4956-b290-ff62abc6d61a -- jc_backup_wd6tb [usb]
+   	da3e14a5-188f-4a65-bf93-8fce9e409d09 -- [origin]
+ok
+
+$ git annex drop A --explain
+drop A [ A matches required content: present[TRUE] and ( copies=origin:0[TRUE] ) ]
+
+  That file is required content. It cannot be dropped!
+
+  (Use --force to override this check, or adjust required content configuration.)
+failed
+drop: 1 failed
+```
+
+What is it saying that it is not no `origin`? Is there something wrong with my setup? Does the drop command try to *lock* file `A` on all remotes (except on the server backups, as they are trusted)?
+
+
+Me doing some "debugging":
+
+```
+$ git annex required . "present and (copies=origin:1 or (not copies=backup_server:2) or copies=backup_offline:0)"
+required . ok
+(recording state in git...)
+
+$ git annex drop A --explain
+drop A [ A matches required content: present[TRUE] and ( copies=origin:1[TRUE] ) ]
+
+  That file is required content. It cannot be dropped!
+
+  (Use --force to override this check, or adjust required content configuration.)
+failed
+drop: 1 failed
+
+$ git annex required . "present and (copies=origin:10 or (not copies=backup_server:2) or copies=backup_offline:0)"
+required . ok
+(recording state in git...)
+
+$ git annex drop 2022/220513-PolybandInConcert/220513_220256.cr3 --explain
+drop A [ A matches required content: present[TRUE] and ( copies=origin:10[FALSE] or not copies=backup_server:2[TRUE] or copies=backup_offline:0[TRUE] ) ]
+
+  That file is required content. It cannot be dropped!
+
+  (Use --force to override this check, or adjust required content configuration.)
+failed
+drop: 1 failed
+```
+
+How can the number of copies on `origin` be `0` and `1` at the same time? Or do I misunderstand something completely? It also reports that the file in none of the backups (neither local nor remote).
+
+Thanks a lot your your time and effort!
diff --git a/doc/forum/Required_Content_Always_True___40____61____62___cannot_drop__41__/comment_1_1db8c68e8d82ed169b4687dfb5da1ba6._comment b/doc/forum/Required_Content_Always_True___40____61____62___cannot_drop__41__/comment_1_1db8c68e8d82ed169b4687dfb5da1ba6._comment
new file mode 100644
index 0000000000..9b1b94397a
--- /dev/null
+++ b/doc/forum/Required_Content_Always_True___40____61____62___cannot_drop__41__/comment_1_1db8c68e8d82ed169b4687dfb5da1ba6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2023-11-11T16:13:28Z"
+ content="""
+AFAIK, copies=<group>:<x> matches if the group *contains at least* x copies.
+"""]]
diff --git a/doc/forum/Required_Content_Always_True___40____61____62___cannot_drop__41__/comment_2_ea362bb99294571f0b0e808e87b7d422._comment b/doc/forum/Required_Content_Always_True___40____61____62___cannot_drop__41__/comment_2_ea362bb99294571f0b0e808e87b7d422._comment
new file mode 100644
index 0000000000..f9e24a613a
--- /dev/null
+++ b/doc/forum/Required_Content_Always_True___40____61____62___cannot_drop__41__/comment_2_ea362bb99294571f0b0e808e87b7d422._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jcjgraf"
+ avatar="http://cdn.libravatar.org/avatar/9dda752f83ac44906fefbadb35e8a6ac"
+ subject="comment 2"
+ date="2023-11-14T21:25:24Z"
+ content="""
+Oh well, that I could have come up with myself. Thanks for your hint @Lukey!
+"""]]
diff --git a/doc/forum/Restoring_files__63__.mdwn b/doc/forum/Restoring_files__63__.mdwn
new file mode 100644
index 0000000000..d0bf86d90b
--- /dev/null
+++ b/doc/forum/Restoring_files__63__.mdwn
@@ -0,0 +1,11 @@
+One of my users created a git annex repository a while ago and has since left the lab, and I think they messed it up badly.
+
+It looks like all of the data is present in the annex directory, but there are no files in main directory, other than the .git folder. The master branch seems to be gone, and the only branch left is called git-annex.
+
+git log gives the error "fatal: bad default revision 'HEAD'" when I first do git log, because the branch that I am on doesn't exist (the master branch). Changing to the git-annex branch works, but then I can't go back to the master branch because it doesn't exist.
+
+git annex unannex doesn't seem to do anything. Is there any way to get the data back following this kind of mess up?
+
+Thanks for your help
+
+-Mike
diff --git a/doc/forum/Restoring_files__63__/comment_1_735b98419b3ba6207cc364426b03ce74._comment b/doc/forum/Restoring_files__63__/comment_1_735b98419b3ba6207cc364426b03ce74._comment
new file mode 100644
index 0000000000..81cf3612b6
--- /dev/null
+++ b/doc/forum/Restoring_files__63__/comment_1_735b98419b3ba6207cc364426b03ce74._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="Chel"
+ subject="comment 1"
+ date="2015-06-30T06:32:59Z"
+ content="""
+If there are no branches, other than git-annex, then you do not have git history.
+
+If it is really the old repository with deleted branches and not a newly created
+one, then there is a possibility, that the git history has not been fully
+deleted/garbage-collected yet (i.e. there are old objects and packs in
+`.git/objects` and `.git/objects/pack`). It that case:
+
+1. *Do not run* git commands until you create a backup of the .git directory,
+   because some usual git commands automatically launch `git gc --auto`, which
+   removes some old unreachable objects (and maybe reflog entries).
+
+2. See if there are some reflogs of deleted branches or HEAD left in `.git/logs`.
+   Reflogs will give you commit ids that branches’ tips pointed to. But usually
+   reflogs are deleted with their branches.
+
+3. As the last resort, use `git fsck --dangling` to find objects, that may be
+   the commits of deleted branches. See also other options of `git fsck` command.
+
+Of course, all that is not necessary if you have a clone of the repo somewhere.
+Then just fetch the history from it.
+
+Git history will give you the history of modifications in the repository, the
+content of not annexed files (that were stored directly in git) and the names
+of annexed files (represented as symlinks).
+
+If all you need is just the contents of annexed files, then look at
+`.git/annex/objects`.  
+**But**: if the repository was in direct mode, then `.git/annex/objects` *may*
+contain only *old* versions of files. The current versions of annexed files
+in direct mode are stored in the working directory, which is empty in your case.
+
+The git-annex branch contains just the location log of the content of annexed
+files, i.e. which git-annex repositories and when stored the contents.
+
+"""]]
diff --git a/doc/forum/Restricting_SSH_+_supply_key.mdwn b/doc/forum/Restricting_SSH_+_supply_key.mdwn
new file mode 100644
index 0000000000..59dd72fdc6
--- /dev/null
+++ b/doc/forum/Restricting_SSH_+_supply_key.mdwn
@@ -0,0 +1,7 @@
+Just two very simple questions:
+
+1.) Is there a way to restrict the SSH key for git annex by supplying a command= ? Even better, is it also possible to supply a directory in which the repository is? (I do not want chroot - too complicated but a soft check would be sufficient for me).
+
+2.) Can I tell git and git-ssh which pubkey to use WITHOUT changing system-/user wide config (e.g.., .ssh/*)? If it is indeed not possible, what's the best way to do it in Windows?
+
+Thanks!
diff --git a/doc/forum/Restricting_SSH_+_supply_key/comment_10_8bbd0b6488c23ce8b182bd6b1765c94b._comment b/doc/forum/Restricting_SSH_+_supply_key/comment_10_8bbd0b6488c23ce8b182bd6b1765c94b._comment
new file mode 100644
index 0000000000..2bcf658b96
--- /dev/null
+++ b/doc/forum/Restricting_SSH_+_supply_key/comment_10_8bbd0b6488c23ce8b182bd6b1765c94b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="ooooh"
+ date="2014-07-16T22:21:36Z"
+ content="""
+Thank *you* for taking the time to figure that out!
+ 
+I agree on moving the .vbs files. I have done so. (Well, you have to run the git-annex-uninstall.exe to remove the old ones, but that shouldn't matter.)
+Testing of an autobuild would be appreciated.
+"""]]
diff --git a/doc/forum/Restricting_SSH_+_supply_key/comment_11_3b946519c9f52569ce60ac04bdc3380a._comment b/doc/forum/Restricting_SSH_+_supply_key/comment_11_3b946519c9f52569ce60ac04bdc3380a._comment
new file mode 100644
index 0000000000..6283053771
--- /dev/null
+++ b/doc/forum/Restricting_SSH_+_supply_key/comment_11_3b946519c9f52569ce60ac04bdc3380a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""fixed"""
+ date="2014-10-28T20:19:04Z"
+ content="""
+I seem to have forgotten to follow up here, but I think I fixed
+this problem some time ago, in [[!commit 5afc8b28e03f4d242fa81a9a93384714d12d4e5c]].
+"""]]
diff --git a/doc/forum/Restricting_SSH_+_supply_key/comment_1_cac35ac1ac0b300ddfac5ffc74291bce._comment b/doc/forum/Restricting_SSH_+_supply_key/comment_1_cac35ac1ac0b300ddfac5ffc74291bce._comment
new file mode 100644
index 0000000000..edcb5307e6
--- /dev/null
+++ b/doc/forum/Restricting_SSH_+_supply_key/comment_1_cac35ac1ac0b300ddfac5ffc74291bce._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-10T19:41:54Z"
+ content="""
+1. Yes, use [[git-annex-shell]].
+
+2. The best way to do this is to use a dummy hostname in the git url for the remote. Then in .ssh/config, you can add a Host stanza that sets the real Hostname and also specifies the IdentityFile to use for that host.
+
+Incidentially, the git-annex webapp takes care of both of these things for you automatically when setting up a remote on a ssh server.
+"""]]
diff --git a/doc/forum/Restricting_SSH_+_supply_key/comment_2_e9803dd1794b4d078efa9435ff5ba295._comment b/doc/forum/Restricting_SSH_+_supply_key/comment_2_e9803dd1794b4d078efa9435ff5ba295._comment
new file mode 100644
index 0000000000..e3ae82116e
--- /dev/null
+++ b/doc/forum/Restricting_SSH_+_supply_key/comment_2_e9803dd1794b4d078efa9435ff5ba295._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="171.67.173.91"
+ subject="comment 2"
+ date="2014-07-11T21:43:11Z"
+ content="""
+Hey Joey,
+
+Cool, that's great! Thanks!
+
+As for the client side. I assume you probably don't know too much about the git setup on Windows ... but maybe (or someone else has an idea :)
+
+1.) The ssh client config for git is \"c:\Program Files (x86)\Git\etc\ssh\ssh_config\" which is *very* unhandy since it's system wide! If it would at least be in the user profile ... (as mentioned, within the \".git\" directory of the repository would be the best)
+
+2.) Even if I create a \"Host\" and use \"IdentityFile\", ssh still queries the agent! This is absolutely unwanted and slows down things! I have a particular key \"git-annex.key\" and *only* this should be tried - no agent. The reason why the agent is especially problematic for me is that I use a special agent which \"locks\" itself after some inactivity and requires to re-enter the passwords.
+
+Thank you!
+
+"""]]
diff --git a/doc/forum/Restricting_SSH_+_supply_key/comment_3_1c3beb859e76cb69d2bacd2473ec72b7._comment b/doc/forum/Restricting_SSH_+_supply_key/comment_3_1c3beb859e76cb69d2bacd2473ec72b7._comment
new file mode 100644
index 0000000000..5412405e7e
--- /dev/null
+++ b/doc/forum/Restricting_SSH_+_supply_key/comment_3_1c3beb859e76cb69d2bacd2473ec72b7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 3"
+ date="2014-07-14T20:20:28Z"
+ content="""
+Re the ssh config on Windows, my windows VM has a per-user .ssh/config inside c:\Documents and Settings\$user. This is where the assistant stores configurations so I know it works.
+
+The soution to ssh still trying to use the agent is probably to set \"IdentitiesOnly yes\" in the stanza for a host. This is what the assistant does, anyway.
+"""]]
diff --git a/doc/forum/Restricting_SSH_+_supply_key/comment_4_1c541fc9a44e5cfb13c7d3ef0eeba2c7._comment b/doc/forum/Restricting_SSH_+_supply_key/comment_4_1c541fc9a44e5cfb13c7d3ef0eeba2c7._comment
new file mode 100644
index 0000000000..cba554860f
--- /dev/null
+++ b/doc/forum/Restricting_SSH_+_supply_key/comment_4_1c541fc9a44e5cfb13c7d3ef0eeba2c7._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="128.12.90.218"
+ subject="comment 4"
+ date="2014-07-15T03:11:18Z"
+ content="""
+Hi Joey,
+
+Sorry that I bother so much with this.
+Thank you so much for your answer. At least with the command line it works now. I had it in %USERPROFILE%/.ssh/ssh_config (where I think it's supposed to be) rather than %USERPROFILE%/.ssh/config. In this file I have a stanza \"Host annex\" with Hostname, Port and IdentityFile set. When I call \"ssh annex\" from the command line everything works. It seems that it also works when I use e.g. \"git annex sync\" from the command line.
+
+However, if I use the webapp, the daemon.log is full of:
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+    ssh: Could not resolve hostname annex: hostname nor servname provided, or not known
+    fatal: Could not read from remote repository.
+
+Is it possible that the assistant ignores the ssh config or does something differently?
+
+Thanks again!
+
+"""]]
diff --git a/doc/forum/Restricting_SSH_+_supply_key/comment_5_4dbd5605f2638de0a3edfb3886a47938._comment b/doc/forum/Restricting_SSH_+_supply_key/comment_5_4dbd5605f2638de0a3edfb3886a47938._comment
new file mode 100644
index 0000000000..26792873d1
--- /dev/null
+++ b/doc/forum/Restricting_SSH_+_supply_key/comment_5_4dbd5605f2638de0a3edfb3886a47938._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="128.12.90.218"
+ subject="comment 5"
+ date="2014-07-15T04:03:16Z"
+ content="""
+After some debugging I found another weird thing which is I think the reason. If I execute
+    git annex get file.jpg
+
+everything works. But if I do
+
+    \"c:\program files (x86)\git\bin\git.exe\" annex get file.jpg
+
+it fails, claiming it can't connect to host \"annex\". I found that there are 3 (!) git.exe installed. When I choose
+
+    \"c:\program files (x86)\git\cmd\git.exe\" annex get file.jpg
+
+it works again. When I use \"which git\" in cygwin, it also points me to the \"cmd/git.exe\" version.
+So I think this is a bug and git annex assistant should call the executeable in \"cmd\" rather than \"bin\".
+Why are there three versions of git.exe at all (one more is in directory libexec/git-core)?
+
+"""]]
diff --git a/doc/forum/Restricting_SSH_+_supply_key/comment_6_a9c5b424a6acb2da152bf87b2e7617bb._comment b/doc/forum/Restricting_SSH_+_supply_key/comment_6_a9c5b424a6acb2da152bf87b2e7617bb._comment
new file mode 100644
index 0000000000..ef15c43a28
--- /dev/null
+++ b/doc/forum/Restricting_SSH_+_supply_key/comment_6_a9c5b424a6acb2da152bf87b2e7617bb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 6"
+ date="2014-07-15T19:20:13Z"
+ content="""
+msgit seems to install it in both places, I am not sure why. Either one works ok when I try to use them. The msgit installer puts \"c:\program files (x86)\git\cmd\\" into PATH so I assume that's the one you're supposed to use.
+"""]]
diff --git a/doc/forum/Restricting_SSH_+_supply_key/comment_7_93b7c2a5947fb6904c88cd5c120e404c._comment b/doc/forum/Restricting_SSH_+_supply_key/comment_7_93b7c2a5947fb6904c88cd5c120e404c._comment
new file mode 100644
index 0000000000..caeec29e59
--- /dev/null
+++ b/doc/forum/Restricting_SSH_+_supply_key/comment_7_93b7c2a5947fb6904c88cd5c120e404c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="128.12.90.218"
+ subject="comment 7"
+ date="2014-07-15T20:33:07Z"
+ content="""
+Thanks Joey,
+
+The problem is more that git-annex assistant takes the wrong (which is in \"bin\" rather than \"cmd\"). I think this is a bug. Because this way the connection does not work in git-annex assistant the same way it does not work with the version in \"bin\" ...
+
+I think when git-annex assistant just calls the git.exe from path (which should be cmd/git.exe) then it should work.
+
+Regards
+Niki
+
+"""]]
diff --git a/doc/forum/Restricting_SSH_+_supply_key/comment_8_beaa350751eca4642545d1b83e528dd7._comment b/doc/forum/Restricting_SSH_+_supply_key/comment_8_beaa350751eca4642545d1b83e528dd7._comment
new file mode 100644
index 0000000000..0d236d5e58
--- /dev/null
+++ b/doc/forum/Restricting_SSH_+_supply_key/comment_8_beaa350751eca4642545d1b83e528dd7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 8"
+ date="2014-07-16T18:10:09Z"
+ content="""
+git-annex only ever runs git from PATH; I never hardcode paths to programs.
+
+You can verify this by running it with the --debug flag to see the exact commands it runs.
+"""]]
diff --git a/doc/forum/Restricting_SSH_+_supply_key/comment_9_2faceeaf0d39f82e5d624eae19e4ca53._comment b/doc/forum/Restricting_SSH_+_supply_key/comment_9_2faceeaf0d39f82e5d624eae19e4ca53._comment
new file mode 100644
index 0000000000..8ed240a818
--- /dev/null
+++ b/doc/forum/Restricting_SSH_+_supply_key/comment_9_2faceeaf0d39f82e5d624eae19e4ca53._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="204.17.143.10"
+ subject="comment 9"
+ date="2014-07-16T20:54:54Z"
+ content="""
+Hi Joey,
+
+Thanks for taking care about all these Windows troubles (Windows and POSIX is unfortunately a big mess).
+
+I finally found the issue now and maybe the bug is related to msysgit. I guess you don't know too much about it so I will report to the msysgit folks.
+
+However, there is still an (easy to fix) \"bug\" related to git-annex I think. I shortly describe the issue and a possible fix:
+
+1.) As mentioned above, from the 3 git.exe, only the one in \"cmd\" should be called! It seems to be a wrapper for the \"bin\"-version. If the git.exe from \"bin\" is called something with the environment is wrong (e.g., ssh_config can not be found)
+
+2.) cmd/git.exe is in %PATH% so usually no problem
+
+3.) However, git-annex-autostart.vbs is in \"bin\" folder. Therefore, when called from there PWD is the \"bin\" folder and when calling \"git.exe\" without absolute path, this overwrites %PATH% because it's the current directory (of course, such behavior does not appear on UNIX).
+
+4.) Now the git-annex assistant daemon always calls the wrong git.exe resulting in a broken config
+
+
+Short term fix for users: Create a shortcut to git-annex-autostart.vbs and change the working directory to anything else
+
+Long term fix for git-annex option 1: Do a chdir in the vbs file before calling git. This is not so good because where to?
+
+Long term fix for git-annex option 2: Just place the vbs files in the parent directory (where \"Git Bash.vbs\" is). This looks like the cleanest solution to me.
+
+
+"""]]
diff --git a/doc/forum/Restricting_git-annex-shell_to_a_specific_repository.mdwn b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository.mdwn
new file mode 100644
index 0000000000..bed019e415
--- /dev/null
+++ b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository.mdwn
@@ -0,0 +1,25 @@
+Is there a way to restrict git-annex-shell to a specific directory?
+Currently, if git-annex is paired to a remote repository, it adds this to the authorized_keys:
+
+
+    $ cat ~/.ssh/authorized_keys
+    command="~/.ssh/git-annex-shell",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB3...
+
+    $ cat ~/.ssh/git-annex-shell 
+    #!/bin/sh
+    set -e
+    exec git-annex-shell -c "$SSH_ORIGINAL_COMMAND"
+
+That gives whoever has the pubkey the right to access all repositories of one user.
+It would be nice to have a manual way to limit the access to a specific repository like 
+
+
+    $ cat ~/.ssh/git-annex-shell 
+    #!/bin/sh
+    set -e
+    export GIT_ANNEX_SHELL_REPO=~/annex
+    exec git-annex-shell -c "$SSH_ORIGINAL_COMMAND"
+
+
+Or maybe some chroot hackery is the way to go?
+
diff --git a/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_1_66544520bff71181e4a03ca583b0b458._comment b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_1_66544520bff71181e4a03ca583b0b458._comment
new file mode 100644
index 0000000000..141f964945
--- /dev/null
+++ b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_1_66544520bff71181e4a03ca583b0b458._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.194"
+ subject="comment 1"
+ date="2012-11-05T16:40:39Z"
+ content="""
+I've added a `GIT_ANNEX_SHELL_DIRECTORY` environment variable, that, if set, prevents git-annex-shell from operating on any other directory.
+
+I've made the assistant include that setting in `authorized_keys` that it sets up. For example:
+
+    command=\"GIT_ANNEX_SHELL_DIRECTORY=/home/me/annex ~/.ssh/git-annex-shell\" ...
+"""]]
diff --git a/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_2_2a210255e8535712c71fa183e56ab600._comment b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_2_2a210255e8535712c71fa183e56ab600._comment
new file mode 100644
index 0000000000..42b6c1758e
--- /dev/null
+++ b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_2_2a210255e8535712c71fa183e56ab600._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://olg.myid.net/"
+ ip="93.218.131.119"
+ subject="comment 2"
+ date="2012-11-05T23:34:20Z"
+ content="""
+Wow, thank you for implementing this so quickly!
+
+
+Just one question: As far as I understood git-annex-shell relays all unknown commands to git-shell. In this case are there the same restrictions active, too?
+
+Thanks again...
+"""]]
diff --git a/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_3_52cd4bd9694b2100b0e0dd2eafa9e828._comment b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_3_52cd4bd9694b2100b0e0dd2eafa9e828._comment
new file mode 100644
index 0000000000..e198f8e09a
--- /dev/null
+++ b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_3_52cd4bd9694b2100b0e0dd2eafa9e828._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 3"
+ date="2012-11-05T23:42:10Z"
+ content="""
+All commands usually run by `git-shell` have the repository directory as their last parameter, and git-annex-shell depends on that being the case and checks them. It's possible to add some commands to git-shell by putting them in a special directory, and if those commands don't take the directory last, they wouldn't work.
+"""]]
diff --git a/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_4_4712a74774f60c29704d1e0f598caa78._comment b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_4_4712a74774f60c29704d1e0f598caa78._comment
new file mode 100644
index 0000000000..b50f13757b
--- /dev/null
+++ b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_4_4712a74774f60c29704d1e0f598caa78._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 4"
+ date="2015-05-26T16:59:02Z"
+ content="""
+seems to me this should be migrated to a tip, no?
+"""]]
diff --git a/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_5_27aa66428410cb8e77fcebccd2c6d1f4._comment b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_5_27aa66428410cb8e77fcebccd2c6d1f4._comment
new file mode 100644
index 0000000000..b6c4af1991
--- /dev/null
+++ b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_5_27aa66428410cb8e77fcebccd2c6d1f4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-05-27T18:59:11Z"
+ content="""
+It might make sense to be added to some tip that's about setting up
+git-annex-shell with untrusted users. 
+
+The git-annex-shell man pages documents this already of course.
+"""]]
diff --git a/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_6_b3a0db1c2f11770b7c6f13964f2d1784._comment b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_6_b3a0db1c2f11770b7c6f13964f2d1784._comment
new file mode 100644
index 0000000000..bd0fdd0d02
--- /dev/null
+++ b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_6_b3a0db1c2f11770b7c6f13964f2d1784._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="clarified manpage"
+ date="2016-04-04T20:00:39Z"
+ content="""
+i have (hopefully) clarified the [[git-annex-shell]] manpage to clearly state how to setup a restricted repository. hopefully, that will avoid further mistakes. :) i am still unclear as to why the wrapper script is necessary, but that's a different issue. --[[anarcat]]
+"""]]
diff --git a/doc/forum/Retrieve_previous_version_in_direct_mode.mdwn b/doc/forum/Retrieve_previous_version_in_direct_mode.mdwn
new file mode 100644
index 0000000000..c74b55b368
--- /dev/null
+++ b/doc/forum/Retrieve_previous_version_in_direct_mode.mdwn
@@ -0,0 +1,5 @@
+I use the assistant with a local directory in direct mode. I have read in different places that direct mode does not ensure that past versions of files are preserved.
+
+What precisely happens to past versions? Under which conditions are past versions kept?
+
+How would I go about retrieving the past version of a file in direct mode?
diff --git a/doc/forum/Retrieve_previous_version_in_direct_mode/comment_1_ca3a999ed64c42b8df810115de205d2f._comment b/doc/forum/Retrieve_previous_version_in_direct_mode/comment_1_ca3a999ed64c42b8df810115de205d2f._comment
new file mode 100644
index 0000000000..dce26832b4
--- /dev/null
+++ b/doc/forum/Retrieve_previous_version_in_direct_mode/comment_1_ca3a999ed64c42b8df810115de205d2f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 1"
+ date="2013-10-21T22:16:16Z"
+ content="""
+If you change a direct mode file and that file has not yet been transferred to some other repository, you've changed the only copy of the file, and so you cannot get back the old version.
+
+Other than that, git-annex always preserves old versions of direct mode files, the same as it preserves old versions of indirect mode files.
+
+To get back an old version of a file, use `git annex indirect` to get out of direct mode, use regular git commands to check out the version of the repository that has the file you need, and use `git annex get` to retrieve the file if it's not available in the local repository.
+"""]]
diff --git a/doc/forum/Retrieve_previous_version_in_direct_mode/comment_2_1292b34ff6d9976b2bd08748e1ba4e7a._comment b/doc/forum/Retrieve_previous_version_in_direct_mode/comment_2_1292b34ff6d9976b2bd08748e1ba4e7a._comment
new file mode 100644
index 0000000000..47ab2b742d
--- /dev/null
+++ b/doc/forum/Retrieve_previous_version_in_direct_mode/comment_2_1292b34ff6d9976b2bd08748e1ba4e7a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="Disk space?"
+ date="2013-11-02T01:33:10Z"
+ content="""
+Sorry, I'm confused: does using regular client repositories in direct mode still store old versions of files?  If so, for how long?  I don't have unlimited disk space, and if it stored in git every copy of every file forever, especially large ones, I'd run out of space...and then what?
+"""]]
diff --git a/doc/forum/Retrieve_previous_version_in_direct_mode/comment_3_699e816c0397f6db924feeab906f1151._comment b/doc/forum/Retrieve_previous_version_in_direct_mode/comment_3_699e816c0397f6db924feeab906f1151._comment
new file mode 100644
index 0000000000..77fa9b0e7c
--- /dev/null
+++ b/doc/forum/Retrieve_previous_version_in_direct_mode/comment_3_699e816c0397f6db924feeab906f1151._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 3"
+ date="2013-11-02T17:36:23Z"
+ content="""
+You can use `git annex unused` and `git annex dropunused` to remove old versions of files.
+"""]]
diff --git a/doc/forum/Retrieve_previous_version_in_direct_mode/comment_4_d900388753de5870b7b9c0e8b8c06ed7._comment b/doc/forum/Retrieve_previous_version_in_direct_mode/comment_4_d900388753de5870b7b9c0e8b8c06ed7._comment
new file mode 100644
index 0000000000..deb26163eb
--- /dev/null
+++ b/doc/forum/Retrieve_previous_version_in_direct_mode/comment_4_d900388753de5870b7b9c0e8b8c06ed7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="comment 4"
+ date="2013-11-02T22:30:07Z"
+ content="""
+Thank you.  Just curious, are there plans to put that in the webapp?
+"""]]
diff --git a/doc/forum/Retrieve_previous_version_in_direct_mode/comment_5_1360b936aa389a0ab5e5e453824b2ece._comment b/doc/forum/Retrieve_previous_version_in_direct_mode/comment_5_1360b936aa389a0ab5e5e453824b2ece._comment
new file mode 100644
index 0000000000..c921758b42
--- /dev/null
+++ b/doc/forum/Retrieve_previous_version_in_direct_mode/comment_5_1360b936aa389a0ab5e5e453824b2ece._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="How to do this on Mac OSX"
+ date="2014-05-08T22:46:49Z"
+ content="""
+So I have a local repository on my MBP and a backup repository on S3. 
+How do I now restore OLD or deleted file versions on my MBP with git-annex assistant?
+"""]]
diff --git a/doc/forum/Reusing_existing_annex.uuid.mdwn b/doc/forum/Reusing_existing_annex.uuid.mdwn
new file mode 100644
index 0000000000..2d438e8a28
--- /dev/null
+++ b/doc/forum/Reusing_existing_annex.uuid.mdwn
@@ -0,0 +1,27 @@
+I recently replaced a disk that was failing with a new disk. Rather than just clone and create a new remote, I decided I'd reuse the existing anex.uuid, since I wanted to mount the replacement disk in the same spot/using the same name as before. The annex.uuid was the one I saw [here](http://git-annex.branchable.com/forum/Truly_purging_dead_repositories/#comment-b89d6a7ab50180c901f53761f8a1a99d). 
+
+I have multiple disks that I store full copies of each of my repositories on; several are just regular git-annex remotes, and some are gcrypt remotes. All of them are local disks. 
+
+When I ran a `git annex sync` in the repo with the reused UUID, the repo, and subsequently the other non-encrypted repos that I synced to, have lost knowledge of the encrypted repos, e.g. when I run `git-annex info`, I do not see the encrypted repos in that list. Even more strangely, this only happened in 2 out of 7 repos; 5 of the repos retained the knowledge of the gcrypt repos. 
+
+The steps I used to recreate all of the repos was:
+
+```
+mkdir resued-uuid
+cd reused-uuid
+git init
+git config annex.uuid xxxxxxxxxxx-xxxxxxxx-xxxxxxxxx
+git annex init "My reused uuid repo"
+git annex fsck (as directed to run in the linked comment, but this didn't do anything because there were no files in the repo and the repo did not have other repos' remotes added to it)
+git remote add existing-repo ~/some/repo/path
+git annex sync
+git annex sync --content (all content copied over; subsequent fscks' don't reveal any damaged files)
+```
+
+I'm curious as to any insight as to why this might have happened and what went wrong.
+
+How can I add existing gcrypt remotes to the repos that are missing them.
+
+Does git annex copy some part of .git/config around to different repos?  
+
+Can I just copy part of a .git/config with the grcrypt remotes listed there and sync them up? 
diff --git a/doc/forum/Reusing_existing_annex.uuid/comment_1_dc3d6efbf5c076bedd0c7a75ff5314bc._comment b/doc/forum/Reusing_existing_annex.uuid/comment_1_dc3d6efbf5c076bedd0c7a75ff5314bc._comment
new file mode 100644
index 0000000000..5347a42e86
--- /dev/null
+++ b/doc/forum/Reusing_existing_annex.uuid/comment_1_dc3d6efbf5c076bedd0c7a75ff5314bc._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-12-19T17:48:48Z"
+ content="""
+Take a look at remote.log in the git-annex branch; it should list all your
+gcrypt and other special remotes. If some seem to be missing, you could
+examine the git log of that file and see what happened.
+
+I don't see how forcing reuse of a uuid could lead to this.
+"""]]
diff --git a/doc/forum/Reusing_existing_annex.uuid/comment_2_cdb21c9c47c8a116e82062c9354d9339._comment b/doc/forum/Reusing_existing_annex.uuid/comment_2_cdb21c9c47c8a116e82062c9354d9339._comment
new file mode 100644
index 0000000000..e100e5952f
--- /dev/null
+++ b/doc/forum/Reusing_existing_annex.uuid/comment_2_cdb21c9c47c8a116e82062c9354d9339._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica"
+ subject="comment 2"
+ date="2015-12-21T06:02:21Z"
+ content="""
+The gcrypt remotes are present in the remotes.log file, but I can't seem to push or sync to them.
+
+How do I get them added back to the repo such that using `git annex sync` syncs the content?
+"""]]
diff --git a/doc/forum/Reusing_existing_annex.uuid/comment_3_5544f712897e06024342aa1bdd68df1a._comment b/doc/forum/Reusing_existing_annex.uuid/comment_3_5544f712897e06024342aa1bdd68df1a._comment
new file mode 100644
index 0000000000..ae763b1e8f
--- /dev/null
+++ b/doc/forum/Reusing_existing_annex.uuid/comment_3_5544f712897e06024342aa1bdd68df1a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica"
+ subject="Copy from .git/config"
+ date="2016-01-09T06:44:59Z"
+ content="""
+Copying the values for the encrypted remotes from a back-up copy of .git/config seems to have worked. 
+"""]]
diff --git a/doc/forum/Reverse_index_key_to_list_of_file_paths.mdwn b/doc/forum/Reverse_index_key_to_list_of_file_paths.mdwn
new file mode 100644
index 0000000000..d6171bab6f
--- /dev/null
+++ b/doc/forum/Reverse_index_key_to_list_of_file_paths.mdwn
@@ -0,0 +1,8 @@
+I understand from [here](https://git-annex.branchable.com/forum/Import_existing_files/#comment-29ece0290fa1314ca48caf8f435570d2) that there is no reverse index from a key to list of file paths pointing to that key (i.e. pointing to the value).
+
+`find . -lname '*<key>'` would be an extremely slow operation on a big repo as it would go through the whole repo. And this is probably a common operation I frequently want to do.
+
+What if I would want to build one? How would I make sure that potential moves/renames will update the index?
+
+I understand from [here](https://git-annex.branchable.com/git-annex-metadata/) that you can attach meta information to a key (via `git annex metadata`). This sounds as it would be useful to contain such reverse information, right?
+
diff --git a/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_1_acae766349a036040a03e75fa8ed34c6._comment b/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_1_acae766349a036040a03e75fa8ed34c6._comment
new file mode 100644
index 0000000000..dbcdb86a05
--- /dev/null
+++ b/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_1_acae766349a036040a03e75fa8ed34c6._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-01-04T15:58:24Z"
+ content="""
+> How would I make sure that potential moves/renames will update the index?
+
+If I had a good answer to that question I would have built it already.
+
+I mean, a post-commit hook can notice changed after the fact, but noticing
+them when they've just been staged is harder.
+
+It does not make sense to store such an index in the git-annex branch,
+because it's redundant information to what's already stored in git trees.
+
+This is discussed in [[todo/cache_key_info]].
+"""]]
diff --git a/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_2_716efb07d216d9a063bb9498c8e76ea1._comment b/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_2_716efb07d216d9a063bb9498c8e76ea1._comment
new file mode 100644
index 0000000000..45f73bfee5
--- /dev/null
+++ b/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_2_716efb07d216d9a063bb9498c8e76ea1._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="comment 2"
+ date="2021-01-06T11:15:42Z"
+ content="""
+Thanks for the answer.
+
+How does `git status` checks for changes? I feel it is quite fast at that.
+
+So you could update the persistent database by post-commit hook, and have a temporary virtual overlay when used which takes current staged changes also into account. And maybe you can also add a `--fast` option, which would skip this part, because the user probably knows when to expect staged changes.
+
+I think this would be pretty useful. This would also change somewhat the whole way how I would use the Annex. I expect that I have this case quite often, that some file content is referenced from multiple file paths.
+
+"""]]
diff --git a/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_3_6b75bd75623004f05f609a39e95250ab._comment b/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_3_6b75bd75623004f05f609a39e95250ab._comment
new file mode 100644
index 0000000000..fc523c098c
--- /dev/null
+++ b/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_3_6b75bd75623004f05f609a39e95250ab._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="nguenthe@0f416ab0ba07a395eb8a0c85732e0105e4970e10"
+ nickname="nguenthe"
+ avatar="http://cdn.libravatar.org/avatar/0e245fd49594e98b19d4c57efcb134ad"
+ subject="comment 3"
+ date="2021-02-09T17:06:24Z"
+ content="""
+I just figured this out today!
+
+In v8 repos, every annexed file gets replaced by a text string like this:
+
+```
++/annex/objects/SHA256E-s320029--488e29f5584ba4e474db95aa42fbb58ddb92f2a59bc0b24a91171acb4d8f4828.png
+```
+
+((
+
+you can see them with `git log -p` or
+
+```
+$ git show HEAD:vlcsnap-2019-03-22-03h42m47s659.png
+/annex/objects/SHA256E-s320029--488e29f5584ba4e474db95aa42fbb58ddb92f2a59bc0b24a91171acb4d8f4828.png
+```
+
+))
+
+So to get the reverse pointer, you can use `git grep`:
+
+```
+$ git grep SHA256E-s320029--488e29f5584ba4e474db95aa42fbb58ddb92f2a59bc0b24a91171acb4d8f4828.png HEAD
+HEAD:vlcsnap-2019-03-22-03h42m47s659.png:/annex/objects/SHA256E-s320029--488e29f5584ba4e474db95aa42fbb58ddb92f2a59bc0b24a91171acb4d8f4828.png
+```
+"""]]
diff --git a/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_4_e54268d93837b3b8e216ec6af074f3c6._comment b/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_4_e54268d93837b3b8e216ec6af074f3c6._comment
new file mode 100644
index 0000000000..6c3db9d361
--- /dev/null
+++ b/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_4_e54268d93837b3b8e216ec6af074f3c6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nguenthe@0f416ab0ba07a395eb8a0c85732e0105e4970e10"
+ nickname="nguenthe"
+ avatar="http://cdn.libravatar.org/avatar/0e245fd49594e98b19d4c57efcb134ad"
+ subject="comment 4"
+ date="2021-02-09T17:09:15Z"
+ content="""
+`git grep` might be just as slow as `find` in the end, but so far it has always been very fast for me. Maybe I just don't have a hyper-huge number of files.
+"""]]
diff --git a/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_5_022728be6cd3ac168a74d16baf29c0e1._comment b/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_5_022728be6cd3ac168a74d16baf29c0e1._comment
new file mode 100644
index 0000000000..5895b8bc71
--- /dev/null
+++ b/doc/forum/Reverse_index_key_to_list_of_file_paths/comment_5_022728be6cd3ac168a74d16baf29c0e1._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-02-15T17:25:05Z"
+ content="""
+git grep doesn't use an index per se, but is probably faster
+than `find` at least sometimes. And probably somewhat faster than things
+involving `git-annex find` too.
+
+It's unfortunate that `git grep` doesn't search on the content of symlink
+texts, so that can't be used to find locked files.
+
+The equivilant using git-annex find, which will find both types:
+
+	git annex find --format '${key}\n' | grep SHA256E-s320029--488e29f5584ba4e474db95aa42fbb58ddb92f2a59bc0b24a91171acb4d8f4828.png
+"""]]
diff --git a/doc/forum/Revert_file_linkage_to_original_files.mdwn b/doc/forum/Revert_file_linkage_to_original_files.mdwn
new file mode 100644
index 0000000000..ba83cfd150
--- /dev/null
+++ b/doc/forum/Revert_file_linkage_to_original_files.mdwn
@@ -0,0 +1,9 @@
+I've recently found the following problem:
+
+I really really want to get back my original folder structure - which includes the real files, not the symlinks. I've searched for quite a while, but I simply could not find an acceptable solution...
+
+So I thought I would like to ask you guys here, if anybody experienced similar problems (or at least knows a solution for my problem)?
+
+Greetings
+
+Pethor
diff --git a/doc/forum/Revert_file_linkage_to_original_files/comment_1_898ca2c9976e92d22470c7404aa9813f._comment b/doc/forum/Revert_file_linkage_to_original_files/comment_1_898ca2c9976e92d22470c7404aa9813f._comment
new file mode 100644
index 0000000000..a72a2cfdd4
--- /dev/null
+++ b/doc/forum/Revert_file_linkage_to_original_files/comment_1_898ca2c9976e92d22470c7404aa9813f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 1"
+ date="2013-08-15T09:02:38Z"
+ content="""
+Sounds like you want to switch to [[direct mode]].
+
+(Or possibly to run `git annex unannex`, if you don't want to use git-annex for these files.)
+"""]]
diff --git a/doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn b/doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn
new file mode 100644
index 0000000000..08aa843cfd
--- /dev/null
+++ b/doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn
@@ -0,0 +1,3 @@
+I have made some mistakes while using `git annex import` in direct mode. Now I see that some files have been erroneously added and there are other problems. I have not yet used `git annex sync`.
+
+How can I tell git-annex in direct mode (or bare git) to forget about all these changes and revert back to the last known good (pre-import) state? This means also removing the few imported files and recreate their links.
diff --git a/doc/forum/Revert_to_a_precedent_state_in_direct_mode/comment_1_1ae9f7defbab44621c3108973a4f683a._comment b/doc/forum/Revert_to_a_precedent_state_in_direct_mode/comment_1_1ae9f7defbab44621c3108973a4f683a._comment
new file mode 100644
index 0000000000..88f7fc895d
--- /dev/null
+++ b/doc/forum/Revert_to_a_precedent_state_in_direct_mode/comment_1_1ae9f7defbab44621c3108973a4f683a._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-06-04T19:03:05Z"
+ content="""
+I wish that I had a good answer for you, but since you're using direct mode, I really do not!
+
+You can run this to see the status:
+
+    git -c core.bare=false status
+
+That's safe. Everything below has a good chance of losing data if not used carefully.
+
+You can run a command like this to *delete* an unwanted file (that is shown as a new file in the above).
+
+    git -c core.bare=false rm -f unwanted_file
+
+If the status shows a file as being modified, you can run this to throw away the modified version. This does not put back the old version! It will leave you with a broken symlink.
+
+    git -c core.bare=false reset modified_file
+    git -c core.bare=false checkout modified_file
+    git annex fsck
+
+If you're lucky, you can then `git annex get` to get the old version from some other repository that still has it.
+"""]]
diff --git a/doc/forum/Revert_to_a_precedent_state_in_direct_mode/comment_2_0bcfc0e89de7072bfdf1e3cdeaa16a1b._comment b/doc/forum/Revert_to_a_precedent_state_in_direct_mode/comment_2_0bcfc0e89de7072bfdf1e3cdeaa16a1b._comment
new file mode 100644
index 0000000000..36102071bf
--- /dev/null
+++ b/doc/forum/Revert_to_a_precedent_state_in_direct_mode/comment_2_0bcfc0e89de7072bfdf1e3cdeaa16a1b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWBvsZvSsAL8P2ye3F0OBStjFCVnOImzM"
+ nickname="Jarno"
+ subject="How about with the 'proxy' command?"
+ date="2014-11-28T18:47:17Z"
+ content="""
+Why does this not work?
+
+    git annex proxy -- git reset HEAD
+
+"""]]
diff --git a/doc/forum/Revert_to_a_precedent_state_in_direct_mode/comment_3_e49a37f92a3dd7d386e1e5f37ab37df4._comment b/doc/forum/Revert_to_a_precedent_state_in_direct_mode/comment_3_e49a37f92a3dd7d386e1e5f37ab37df4._comment
new file mode 100644
index 0000000000..fc3e9c6ba3
--- /dev/null
+++ b/doc/forum/Revert_to_a_precedent_state_in_direct_mode/comment_3_e49a37f92a3dd7d386e1e5f37ab37df4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2014-12-01T22:40:05Z"
+ content="""
+Yes, the new `git annex proxy` command was added partly thanks to this
+thread, and you can use it like that.
+
+There's also a new `git annex undo` command that's easier to use than the
+proxy command. It just undoes the last change you made to the file or
+directory you specify.
+"""]]
diff --git a/doc/forum/Revisiting_migration_and_multiple_keys.mdwn b/doc/forum/Revisiting_migration_and_multiple_keys.mdwn
new file mode 100644
index 0000000000..13e009d2fe
--- /dev/null
+++ b/doc/forum/Revisiting_migration_and_multiple_keys.mdwn
@@ -0,0 +1,22 @@
+I have several workflows that rely on regular key migrations, and I would love to explore some ways that migrating keys could be improved.
+
+I see there has already been discussion about this:
+[[todo/alternate_keys_for_same_content]]
+
+I don't know how often this comes up, but it comes up a lot for me. I have several data sources that I regularly index and mirror by constructing keys based on md5 and size, and assemble a repo with the known filename. (gdrive, many software distribution sites, and others).
+
+So, I have a queue-repo, and I have the flexibilty of populating it later. I could even have a queue repo with just URL keys. Then I can handle ingestion and migration later.
+
+
+I would love to have a simple programatic way of recording that one key is the authoritative key for another key, like for MD5 -> SHA256 migrations.
+
+There don't seem to be any really great solutions to the prolem of obsolete keys. Merging will often re-introduce them, even if they have been excised. Marking them as dead stil keeps them around, and doesn't preserve information about what key now represents the same object.
+
+I have written helper scripts, and tools like git-annex-filter-branch are also very helpful. But I like having the flexibility of many repos that may not regularly be in sync with each other, and a consistent history.
+
+
+This would break things for sure, but what if during a migration, a symlink was made in the git-annex branch from the prev key to the migrated key. The union merge driver could defer to the upgraded or prefered backend. If an out of date repo tries syncing with an already upgraded key, the merge driver can see that the migration for that key has already happened, merge the obsolete key entries, and overwrite it back to a symlink during merge.
+
+A less drastic approach might be to expand the location log format to indiciate a canonical "successor" key, instead of just being dead.
+
+It might seem like a lot of complexity, but it would also in my opinion make a more consistent and flexible data model.
diff --git a/doc/forum/Revisiting_migration_and_multiple_keys/comment_1_a85c3c7af6b1e01f887e0e1ffe2cde6f._comment b/doc/forum/Revisiting_migration_and_multiple_keys/comment_1_a85c3c7af6b1e01f887e0e1ffe2cde6f._comment
new file mode 100644
index 0000000000..efeeece885
--- /dev/null
+++ b/doc/forum/Revisiting_migration_and_multiple_keys/comment_1_a85c3c7af6b1e01f887e0e1ffe2cde6f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-11-30T06:51:53Z"
+ content="""
+Hi! If I understand you correctly, your problem is that you often migrate keys to another backend, and there are situations involving merges of repos far away from each other in history that cause merge conflicts, which results in the dead old pre-migration key being reintroduced?
+
+I never use key backend migration and I don't fully understand your workflow. Could you provide a reproducible example of your problem (incl  all commands)? This would help a lot.
+"""]]
diff --git a/doc/forum/Revisiting_migration_and_multiple_keys/comment_2_b5545aba08c7af2f8f56caba66232c41._comment b/doc/forum/Revisiting_migration_and_multiple_keys/comment_2_b5545aba08c7af2f8f56caba66232c41._comment
new file mode 100644
index 0000000000..5c15c5c516
--- /dev/null
+++ b/doc/forum/Revisiting_migration_and_multiple_keys/comment_2_b5545aba08c7af2f8f56caba66232c41._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-11-30T20:49:53Z"
+ content="""
+There seem to be difficulties with both performance and with security in
+storing information in the git-annex branch to declare that one key
+is replaced by another one.
+
+I wonder if there are any pain points that could be handled better without
+recording such information in the git-annex branch. What do your helper
+scripts do?
+"""]]
diff --git a/doc/forum/Revisiting_migration_and_multiple_keys/comment_3_a712ec9b616ca45976154fd0c98ae1c4._comment b/doc/forum/Revisiting_migration_and_multiple_keys/comment_3_a712ec9b616ca45976154fd0c98ae1c4._comment
new file mode 100644
index 0000000000..8fa84204a5
--- /dev/null
+++ b/doc/forum/Revisiting_migration_and_multiple_keys/comment_3_a712ec9b616ca45976154fd0c98ae1c4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-11-30T20:55:02Z"
+ content="""
+I wonder if it would suffice to have a way for git-annex to record that key
+A migrated to B, but not treat that as meaning that it should get B's
+content when it wants A, or vice-versa.
+
+Instead, when a repository learns that A was elsewhere migrated to B, it
+could hardlink its content for A to B and update the location log for
+B to say is has a copy. The same as if `git-annex migrate` were run locally.
+(It could even hash the content and verify it got B.)
+
+That wouldn't help if a special remote has the content of A, and 
+git-annex wants to get the content of B.
+"""]]
diff --git a/doc/forum/Revisiting_migration_and_multiple_keys/comment_4_7d367f38250a4a3454299170700d5c6c._comment b/doc/forum/Revisiting_migration_and_multiple_keys/comment_4_7d367f38250a4a3454299170700d5c6c._comment
new file mode 100644
index 0000000000..dc7ac4b638
--- /dev/null
+++ b/doc/forum/Revisiting_migration_and_multiple_keys/comment_4_7d367f38250a4a3454299170700d5c6c._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="unqueued"
+ avatar="http://cdn.libravatar.org/avatar/3bcbe0c9e9825637ad7efa70f458640d"
+ subject="comment 4"
+ date="2023-12-01T02:09:07Z"
+ content="""
+@joey
+
+It isn't a huge problem, but I keep coming back to it. The only workflow I still use where this comes up is for my filesharing assets repo. I just ended up leaving it as MD5E, because much of it is downstream from gdrive shares, and I almost never have all of the content in one place at a time.
+
+
+This is one of the scripts I sometimes use, although I wrote it awhile ago before I found out about git-annex-filter-branch
+<https://gist.github.com/unqueued/06b5a5c14daa8224a659c5610dce3132>
+
+But I mostly rely on splitting off subset repos with no history, processing them in some way, and then re-absorbing them back into a larger repo.
+
+I actually started a repo that would track new builds for Microsoft Dev VMs: <https://github.com/unqueued/official-microsoft-vms-annex>
+
+But for my bigger repos, I almost never have all of the data in the same place at the same time.
+
+
+@nobodyinperson
+
+> Hi! If I understand you correctly, your problem is that you often migrate keys to another backend, and there are situations involving merges of repos far away from each other in history that cause merge conflicts, which results in the dead old pre-migration key being reintroduced?
+
+Well, there aren't any conflicts, they just get silently reintroduced, which isn't the end of the world, especially if they get marked as dead. But they clutter the git-annex branch, and over time, with large repos, it may become a problem. There isn't any direct relationship between the previous key and the migrated key.
+
+So, if I have my `linux_isos` repo, and I do git-annex-migrate on it, but say only isos for the year 2021 are in my specific repo at that moment, then the symlinks will be updated and the new sha256 log log files will be added to my git-annex branch.
+
+And if you sync with another repo that also has the same files in the backend, they will still be in the repo, but just inaccessible.
+
+And I feel like there's enough information to efficiently track the lifecycle of a key.
+
+
+I'm exhuming my old scripts and cleaning them up, but essentially, you can get everything you need to assemble an MD5E annex from a Google Drive share by doing `rclone lsjson -R --hash rclone-drive-remote:`
+
+And to get the keys, you could pipe it into something like this:
+`perl -MJSON::PP -ne 'BEGIN { $/ = undef; $j = decode_json(<>); } foreach $e (@{$j}) { next if $e->{\"IsDir\"} || !exists $e->{\"Hashes\"}; print \"MD5-s\" . $e->{\"Size\"} . \"--\" . $e->{\"Hashes\"}->{\"MD5\"} . \"\t\" . $e->{\"Path\"} . \"\n\"; }' `
+
+That's just part of a project I have with a Makefile that indexes, assembles and then optionally re-serves an rclone gdrive remote. I will try to post it later tonight. It was just a project I made for fun.
+
+And there are plenty of other places where you can get enough info to assemble a repo ahead of time, and essentially turn it into a big queue.
+
+
+You can find all sorts of interesting things to annex.
+
+https://old.reddit.com/r/opendirectories sometimes has interesting stuff.
+
+Here are some public Google Drive shares:
+
+* [Bibliotheca Anonoma](https://drive.google.com/drive/folders/0B7WYx7u6HJh_Z3FjU2F0NFNyQWs)
+* [Esoteric Library](https://drive.google.com/drive/folders/0B0UEkmH7vYJZRWxfSmdRbFJGNWc)
+* [EBookDroid - Google Drive](https://drive.google.com/drive/folders/0B6y-A-HTzyBiYnpIRHMzR1pueFU)
+* [The 510 Archives - Google Drive](https://drive.google.com/drive/folders/0ByCvxnHNk90SMzIxZWIwYWYtYzljNy00ZGU2LWI3ODctYzRjMmE0MGY3NTA1)
+* [Some ebooks](https://drive.google.com/drive/folders/1SReXFt16DYpTdFsSsT5Nzkj33VAYOQLa)
+
+
+"""]]
diff --git a/doc/forum/Revisiting_migration_and_multiple_keys/comment_5_93b85fbe5c36e986cf7c1fc87070c04c._comment b/doc/forum/Revisiting_migration_and_multiple_keys/comment_5_93b85fbe5c36e986cf7c1fc87070c04c._comment
new file mode 100644
index 0000000000..b42947b7b8
--- /dev/null
+++ b/doc/forum/Revisiting_migration_and_multiple_keys/comment_5_93b85fbe5c36e986cf7c1fc87070c04c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-12-01T18:42:07Z"
+ content="""
+I've spent a while thinking about this and came up with the ideas at
+[[todo/distributed_migration]].
+
+I think that probably would handle your use case.
+"""]]
diff --git a/doc/forum/Revisiting_migration_and_multiple_keys/comment_6_3db8d28e13f6508e22e8488a6faaa8b2._comment b/doc/forum/Revisiting_migration_and_multiple_keys/comment_6_3db8d28e13f6508e22e8488a6faaa8b2._comment
new file mode 100644
index 0000000000..83a860c358
--- /dev/null
+++ b/doc/forum/Revisiting_migration_and_multiple_keys/comment_6_3db8d28e13f6508e22e8488a6faaa8b2._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="unqueued"
+ avatar="http://cdn.libravatar.org/avatar/3bcbe0c9e9825637ad7efa70f458640d"
+ subject="comment 6"
+ date="2023-12-19T18:50:08Z"
+ content="""
+Whoa, thanks for implementing that Joey! Can't wait to give it a try!
+
+
+FYI, one of the cases I was talking about before where I repeatedly import keys in MD5E format, is that construct an annex repo, set web urls, and deal with mirroring further down the pipeline.
+
+Code isn't great, just something I threw together years ago:
+https://github.com/unqueued/annex-drive-share
+
+Because it is gdrive, I can get MD5s and filenames with rclone urls for web remotes.
+
+The way I use it is to init a new annex repo (reusing the same uuid), and then absorb into primary downstream repo overwriting filenames and letting sync update any new keys with the primary repo. Considered using subtree.
+
+It does end up causing merge commits to build up in the git-annex branch, but I might want to run this on a server without sharing an entire repo.
+
+It happens to make sense for me because I have an unlimited @edu gdrive account and it can work great for some workflows as an intermediate file store.
+"""]]
diff --git a/doc/forum/Robustness_on_failing_hardware.mdwn b/doc/forum/Robustness_on_failing_hardware.mdwn
new file mode 100644
index 0000000000..ec32cbfe70
--- /dev/null
+++ b/doc/forum/Robustness_on_failing_hardware.mdwn
@@ -0,0 +1,30 @@
+Hi everyone,
+
+
+I've had a bad git-annex day and I left some musings on my first use of it. There's a question though at the end if you don't need to read that.
+
+
+today I've spend some time trying to deal with a failing SHA256E backend. Or more precise, I'm patienting a refurbished Athlon board[*] without case and that seems to give a lot of errors. I've put up some shielding at the SDRAM which helped a lot on the checksumming, but now its the network department is having a hard time. 
+
+This is basicly an effort to recover an old 1.5TB USB NTFS disks with bit rot, a failed ext4 and recover collections from other aging USB/desktop disks. There is some new hardware on the way, to restore another (proper) box with some ECC memory. That should fix my problems, I think. I've never dealt with a problem like this before. Before git-annex I would have been using rsync -azc or mostly -azu, but I've never had problems like this before. 
+
+It has me pondering a bit though. To help git-annex i've done manual rsync -azc transfers, with some although a very low success--I wonder if its the lack of casing, lack of ground, or simply the non-ecc that is the cause. But that is not really the question.
+
+rsync does not at first glance have an option to configure the amount of retries, but -azc does try and gives a checksum failure another try before giving up. I had never seen rsync do that before even though I've been using it for a decade. I guess that shows how rare this problem should be, but its still creeping me a bit. I've never had checksummed media file collections, so I really cant be sure about integrity, can I?
+
+The behaviour of the SHA256E backend is a bit hysterical in this environment. Running a full annex fsck always results in some bad files. The bigger the file the harder it is to get a checksum match. I guess if I wanted to continue I should wrap the fsck step in a shell script that can reinject and fsck again and does do not needless re-checks in one run. It should figure it out in the end with a bit of more time.
+
+My other reaction would be to throw more checksums at it, from simple to complex. Something between filesize and sha256. I guess the whole would then have some different modes of retries and behaviours of failure maybe. Or levels of trust in the integrity. Maybe using simpler checksums would make the situation more bearable, since the problem is not disk-related iow. if the file is there and has checked out ok, then the re-fsck itself and bad memory/shielding are the culprits. 
+
+tldr;
+
+git-annex has no retry at all. I have seen it can take a -i <keyfile> somewhere. For robustness, it would be nice if there was a rsync -c mode. It would confirm the object was transferred correctly too. My workflow is to 'annex fsck' at the remote after copying files there. Is it correct to presume that using 'annex move' in my case, would have made the sending repo dropping files even though the remote still has only corrupted copies?
+
+I'm new to git-annex but been wanting something like git annex for a long time. Made some attempts myself, and too pondered how to use venerable GIT but never figured something out. What I'm saying though is I may want to dig around to see what I can do with Haskell. 
+
+I'm thinking a backend with some more checksums, maybe then some option to fsck to request only partial check of the key. Has something like a faster/less-thorough fsck using smaller checksums ever come up? And might this be a way to go at this? What do you think.
+
+
+
+
+[*] Asus M2A7A-AM SE w/ AMD Athlon 64 X2 5200+ Dual Core 2.7 
diff --git a/doc/forum/Robustness_on_failing_hardware/comment_1_d89ffbebe59d05fb2c47d957792cf97e._comment b/doc/forum/Robustness_on_failing_hardware/comment_1_d89ffbebe59d05fb2c47d957792cf97e._comment
new file mode 100644
index 0000000000..baac15e81f
--- /dev/null
+++ b/doc/forum/Robustness_on_failing_hardware/comment_1_d89ffbebe59d05fb2c47d957792cf97e._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-06T16:09:22Z"
+ content="""
+If the remote that git-annex is moving files to uses rsync as its transport
+(ie, is a regular git remote, or a rsync special remote), then
+the receiving rsync process verifies a checksum of the file it's receiving.
+So, if the sender sends incorrect data, or calculates the wrong checksum
+for the right data, the rsync will fail, and git-annex won't delete the
+local copy of the file. I guess that if the sending rsync reads bad data
+from disk, these checksums won't prevent the bad data being sent to the
+remote though. (Some other special remotes don't have a transfer checksum
+at all.)
+
+If I had hardware this broken, I'd be glad that `git annex fsck` detected
+it, and would move the storage to good hardware and run my fsck there to
+learn the actual state of my repository. Re-running checksums or using
+multiple checksum types to work around badly broken hardware seems like a
+losing idea to me.
+"""]]
diff --git a/doc/forum/Running_assistant_on_a_server___40__no_X_available__41__.mdwn b/doc/forum/Running_assistant_on_a_server___40__no_X_available__41__.mdwn
new file mode 100644
index 0000000000..4116577bb2
--- /dev/null
+++ b/doc/forum/Running_assistant_on_a_server___40__no_X_available__41__.mdwn
@@ -0,0 +1,2 @@
+How can I run the assistant on a server and access the webinterface over the network from my client pc?
+The use case I have in mind is that the server can automatically synchronize files, pushed over XMPP.
diff --git a/doc/forum/Running_assistant_on_a_server___40__no_X_available__41__/comment_1_dd75d78ef63f2689199a302ed1846017._comment b/doc/forum/Running_assistant_on_a_server___40__no_X_available__41__/comment_1_dd75d78ef63f2689199a302ed1846017._comment
new file mode 100644
index 0000000000..ec31212e54
--- /dev/null
+++ b/doc/forum/Running_assistant_on_a_server___40__no_X_available__41__/comment_1_dd75d78ef63f2689199a302ed1846017._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 1"
+ date="2013-01-17T08:30:54Z"
+ content="""
+You don't need the webapp to run the assistant, but if you want, you can forward it to your local system. You will find the URL in .git/annex/url and have to extract the port from it (http://127.0.0.1:<someport>/.../), afterwards forward that port either via ssh port forwarding or via a webserver acting as a reverse proxy.
+"""]]
diff --git a/doc/forum/Running_assistant_on_a_server___40__no_X_available__41__/comment_2_df654df60c5fa6a84d786d248928a352._comment b/doc/forum/Running_assistant_on_a_server___40__no_X_available__41__/comment_2_df654df60c5fa6a84d786d248928a352._comment
new file mode 100644
index 0000000000..ff43a083d8
--- /dev/null
+++ b/doc/forum/Running_assistant_on_a_server___40__no_X_available__41__/comment_2_df654df60c5fa6a84d786d248928a352._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 2"
+ date="2013-01-17T16:29:39Z"
+ content="""
+If this is a true server, with a static IP (or some dynamic DNS), there is no need to run the assistant on it; clients using the assistant can ssh in and sync data to it directly.
+
+Anyway, you can git config web.browser to run some script with the url it will be passed to the webapp when the webapp is started. I sometimes configure it to just echo the url out; it'd also be possible to automate
+setting up a redirection for a remote browser, I suppose.
+"""]]
diff --git a/doc/forum/Running_assistant_steps_manually.mdwn b/doc/forum/Running_assistant_steps_manually.mdwn
new file mode 100644
index 0000000000..b3b683433b
--- /dev/null
+++ b/doc/forum/Running_assistant_steps_manually.mdwn
@@ -0,0 +1,20 @@
+Unfortunately one of the machines that I am running git-annex on is too old to handle the watcher thread.
+
+The error message is:
+
+    Watcher crashed: Need at least OSX 10.7.0 for file-level FSEvents
+
+
+I am however interested in duplicating the assistant steps manually.  I'm happy to accept that I won't have the great, auto-magic, coverage, but, how I run the steps that the assistant runs?
+
+I'm guessing there is a:
+
+    git annex add .
+    git commit -m "[blah]"
+    git annex sync
+
+but how do I get the pushing to backup/transfer/whatever remotes to work?  And what order should I do these?
+
+What I would *like* to do is get a script that runs all of the needed annex steps and then kick it off in a cron job 2-5 times a day.
+
+Any thoughts?
diff --git a/doc/forum/Running_assistant_steps_manually/comment_1_e14e0a1d55d01cb4f67a94bbe349b872._comment b/doc/forum/Running_assistant_steps_manually/comment_1_e14e0a1d55d01cb4f67a94bbe349b872._comment
new file mode 100644
index 0000000000..6629ff024c
--- /dev/null
+++ b/doc/forum/Running_assistant_steps_manually/comment_1_e14e0a1d55d01cb4f67a94bbe349b872._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-19T20:18:11Z"
+ content="""
+Essentially, you want to run this:
+
+<pre>
+git annex add
+git annex sync
+for remote in $(git remote); do
+    git annex copy --auto --to $remote
+    git annex get --auto --from $remote
+done
+git annex drop --auto
+</pre>
+
+Of course this cannot sync with XMPP remotes. Otherwise it will get you to essentially the same place as the assistant.
+"""]]
diff --git a/doc/forum/Running_assistant_steps_manually/comment_2_3192f614c929b8060d4fbde56a7adec1._comment b/doc/forum/Running_assistant_steps_manually/comment_2_3192f614c929b8060d4fbde56a7adec1._comment
new file mode 100644
index 0000000000..b6c10ee880
--- /dev/null
+++ b/doc/forum/Running_assistant_steps_manually/comment_2_3192f614c929b8060d4fbde56a7adec1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnRai_qFYPVvEgC6i1nlM1bh-C__jbhqS0"
+ nickname="Matthew"
+ subject="Looks great"
+ date="2013-08-29T12:45:10Z"
+ content="""
+This looks great as I have:
+
+ * A preference for multiple small repositories.
+ * Old versions for `git-annex` due to being on Ubuntu LTS for my server.
+ * A Samsung Galaxy Nexus which somehow seems too slow to run the assistant.
+
+So these steps combined with some locking and maybe `inotify` seem perfect
+"""]]
diff --git a/doc/forum/Running_out_of__inodes.mdwn b/doc/forum/Running_out_of__inodes.mdwn
new file mode 100644
index 0000000000..417de18de0
--- /dev/null
+++ b/doc/forum/Running_out_of__inodes.mdwn
@@ -0,0 +1,17 @@
+When syncing with a huge git annex repository on usb disk, my small laptop partition runs out of inodes.
+
+Any workaround for this?
+
+- Use bare repository?
+
+    Some git annex command are not supported.
+    This makes managing (particularly adding) files difficult.
+
+- Use a loop file partition with tiny block size and large inode numbers?
+
+    Operations on a huge git repository are slow.
+    On a loop file partition will be slower.
+
+- Maybe shrink the partition and make room for a specific partition for git annex repository?
+
+Any opinions?   
diff --git a/doc/forum/Running_out_of__inodes/comment_1_abc73d9ad662ef642337b683bf0a0253._comment b/doc/forum/Running_out_of__inodes/comment_1_abc73d9ad662ef642337b683bf0a0253._comment
new file mode 100644
index 0000000000..11f2f7b7eb
--- /dev/null
+++ b/doc/forum/Running_out_of__inodes/comment_1_abc73d9ad662ef642337b683bf0a0253._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.51"
+ subject="comment 1"
+ date="2013-09-12T20:37:05Z"
+ content="""
+Define \"huge\"? Checking out a git repository necessarily requires one inode per file in the repository, plus a smaller quantity for the things in .git. A git-annex repository  is much the same as any other git repository.
+
+Even when I make a really tiny 100 mb ext4 filesystem, it defaults to 25000 inodes, which would be enough to contain a checkout of my second largest git-annex repository. 
+
+Anyway, using git branches seems like a reasonable workaround, to the extent I understand your problem. Make a branch with the files in it you want to have available on the small drive, or check out an empty branch on the small drive and `git annex add` files in there. You can merge the branch back into your master branch on the large drive.
+"""]]
diff --git a/doc/forum/Running_out_of__inodes/comment_2_30d58cb046b13d6ddd435ad0ae2f0ae1._comment b/doc/forum/Running_out_of__inodes/comment_2_30d58cb046b13d6ddd435ad0ae2f0ae1._comment
new file mode 100644
index 0000000000..4ec867ec53
--- /dev/null
+++ b/doc/forum/Running_out_of__inodes/comment_2_30d58cb046b13d6ddd435ad0ae2f0ae1._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="git-annex+git consumes lots of inodes. They are cheap, don't limit their amount when creating a filesystem."
+ date="2016-11-04T09:56:45Z"
+ content="""
+TL;DR: don't play with `inode_ratio` when creating a filesystem. You will certainly get more storage space, up to 1.5%. But the numerous symlinks maintained by git-annex will consume a lot of inodes. You don't want your filesystem to fail to create any new file when doing a big `git annex add` or worse, `git repack` or `git gc` or `git repair`, right ?
+
+## Git annex heavily uses symlinks and dirs, which consumes several inodes per file.
+
+I ran out of inodes on two of my disks, with different git-annex repositories.
+
+Joeyh wrote:
+
+> Checking out a git repository necessarily requires one inode per file in the repository, plus a smaller quantity for the things in .git. A git-annex repository is much the same as any other git repository.
+
+I believe that in `.git/annex/objects`, the structure consumes two inodes, one for the directory and one for the actual file storing data.  Is it right?
+
+So, when a file is checked out and managed by `git-annex`, is consumes 3 inodes, right?
+
+Plus possibly many inodes used temporarily when doing some git operations.  E.g. `git repair`. Man page says: \"Since this command unpacks all packs in the repository, you may want to run git gc afterwards.\"
+
+So, at least 4 inodes per file ?
+
+## Optimising space by reducing inodes is no longer worth the trouble.
+
+External disks were formatted years ago maximizing disk space (for details see [http://serverfault.com/a/523210](http://serverfault.com/a/523210) ).
+The assumption was that nearly all files were more than 4 megabytes in size, so the ext2 `inode_ratio` was 4194304.
+This assumption was very true and all went well until `git-annex` entered the game.
+
+In the case of a git-annex repository, if there is at least 4 inodes per actual image file, `inode_ratio` must be at most the average file size divided by 4.
+
+I considered an inode ratio at 64k. With most files far above 1 megabyte, that leaves room for much more than 16 inodes for housekeeping.  You don't know in advance how the usage will evolve.  Perhaps you will need to do one or more git clones of the same annexed data, especially in a recovery situation, which will quickly multiply the number of consumed inodes.
+
+`mkfs.ext4` chooses by itself `inode_ratio=16384`. Filesystem capacity is 1.5% smaller than with the minimum number of inode.  I'll just stick with that.
+
+```
+time mkfs.ext4 -E lazy_itable_init -L \"MyWonderFulLabel\" -O sparse_super -m 0 /dev/sdb1
+```
+
+(Yes, `-m 0` removes the 5% reserved space for root, and yes, filesystem performance drops dramatically then full beyond 90% then 95%. That parameter can be tuned with tune2fs at any time. In doubt, remove it.)
+
+"""]]
diff --git a/doc/forum/Running_out_of__inodes/comment_3_31926fc5c095a1d12d4005958047a3d0._comment b/doc/forum/Running_out_of__inodes/comment_3_31926fc5c095a1d12d4005958047a3d0._comment
new file mode 100644
index 0000000000..5c29ac38f6
--- /dev/null
+++ b/doc/forum/Running_out_of__inodes/comment_3_31926fc5c095a1d12d4005958047a3d0._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="inodes of git vs. git-annex"
+ date="2022-02-23T12:18:54Z"
+ content="""
+An observation I've just made cleaning up after a surprising (to me back then, not to the reader seeing the context here) \"disk full\" condition on a half-empty disk:
+
+On my system it was not git-annex's objects and symlinks (with its mere several thousand inodes) but git (with millions of them) that filled up the system during `git gc`.
+
+Running `git prune` helped me get out of the immediate situation, but any `git gc` filled up the disk again. This appears to be a general problem when repacking large git repositories in some states (producing 8M files intermediately). In the end, I resorted to moving .git/objects to a dedicated btrfs partition (which doesn't suffer from inode exhaustion).
+
+An alternative could be forgetting history, this should also help getting down the number of git objects.
+"""]]
diff --git a/doc/forum/S3_Host_Question.mdwn b/doc/forum/S3_Host_Question.mdwn
new file mode 100644
index 0000000000..f114d7c930
--- /dev/null
+++ b/doc/forum/S3_Host_Question.mdwn
@@ -0,0 +1,11 @@
+I have two machines A & B.  Each have their our repository.
+
+On machine A I have created a remotehost (S3) and have synced successfully.
+
+I am trying to link machine B to the same remote host.  I keep getting an error on the initremote command on machine B.
+
+I tried using the same command as I did on A and it is not working.   Is there a different command to link machine B to an existing remote repository?
+
+Any help is appreciated.
+
+Rob
diff --git a/doc/forum/S3_Host_Question/comment_1_8c8ecea703405753e47e0da5e8325929._comment b/doc/forum/S3_Host_Question/comment_1_8c8ecea703405753e47e0da5e8325929._comment
new file mode 100644
index 0000000000..b8d63e5fdd
--- /dev/null
+++ b/doc/forum/S3_Host_Question/comment_1_8c8ecea703405753e47e0da5e8325929._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 1"
+ date="2013-12-13T08:37:24Z"
+ content="""
+On machine B you don't initremote you enableremote,
+
+
+    git annex enableremote mys3
+"""]]
diff --git a/doc/forum/S3_Host_Question/comment_2_3d6fa3147d59a5e0d10b005388b23c7a._comment b/doc/forum/S3_Host_Question/comment_2_3d6fa3147d59a5e0d10b005388b23c7a._comment
new file mode 100644
index 0000000000..cef33d3542
--- /dev/null
+++ b/doc/forum/S3_Host_Question/comment_2_3d6fa3147d59a5e0d10b005388b23c7a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnKhw0-Tu5oHjeoz_gAP4Nu5V9uo8ta3hM"
+ nickname="Robert"
+ subject="unknown special remote"
+ date="2013-12-13T15:12:37Z"
+ content="""
+How does machine B know about the remote?  Machines A & B are separate and don't share references. Am I missing a step? 
+"""]]
diff --git a/doc/forum/S3_Host_Question/comment_3_797edf3ad41561ab8960f3b28d20611e._comment b/doc/forum/S3_Host_Question/comment_3_797edf3ad41561ab8960f3b28d20611e._comment
new file mode 100644
index 0000000000..a0dbae5bdc
--- /dev/null
+++ b/doc/forum/S3_Host_Question/comment_3_797edf3ad41561ab8960f3b28d20611e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 3"
+ date="2013-12-14T09:05:26Z"
+ content="""
+remote info is recorded in git once you clone the git repo it knows about machine a and s3 repo.
+"""]]
diff --git a/doc/forum/S3_copies__58___unsafe_to_drop_from_another_repo__63__.mdwn b/doc/forum/S3_copies__58___unsafe_to_drop_from_another_repo__63__.mdwn
new file mode 100644
index 0000000000..35c363d8a4
--- /dev/null
+++ b/doc/forum/S3_copies__58___unsafe_to_drop_from_another_repo__63__.mdwn
@@ -0,0 +1,5 @@
+Hi!
+
+A file is present in my local repository (v7), and in a special encrypted repository using S3. Numcopies is set to 1. Whenever I try to drop the file, git-annex says it's "Unable to lock down 1 copy of file that is required to safely drop it" after having been "checking repository-s3... (unsafe)".
+
+What does "unsafe" means? When I fsck the file in repository-s3, everything's fine and the file is present.
diff --git a/doc/forum/S3_copies__58___unsafe_to_drop_from_another_repo__63__/comment_1_536a526a78a775142ad66c0689411c6a._comment b/doc/forum/S3_copies__58___unsafe_to_drop_from_another_repo__63__/comment_1_536a526a78a775142ad66c0689411c6a._comment
new file mode 100644
index 0000000000..a5841f99de
--- /dev/null
+++ b/doc/forum/S3_copies__58___unsafe_to_drop_from_another_repo__63__/comment_1_536a526a78a775142ad66c0689411c6a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="TroisSinges"
+ avatar="http://cdn.libravatar.org/avatar/f4c62f9ebe09016b8852b04f1dd6612f"
+ subject="comment 1"
+ date="2019-10-13T23:59:23Z"
+ content="""
+git-annex version is 7.20190912-gab739242a3 (on Linux x86_64)
+"""]]
diff --git a/doc/forum/S3_copies__58___unsafe_to_drop_from_another_repo__63__/comment_2_48d27b557d31f25fc4b2fc7e4ef55df3._comment b/doc/forum/S3_copies__58___unsafe_to_drop_from_another_repo__63__/comment_2_48d27b557d31f25fc4b2fc7e4ef55df3._comment
new file mode 100644
index 0000000000..a7ba86abb0
--- /dev/null
+++ b/doc/forum/S3_copies__58___unsafe_to_drop_from_another_repo__63__/comment_2_48d27b557d31f25fc4b2fc7e4ef55df3._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-10-21T17:23:30Z"
+ content="""
+Hmm, that's a surprising error message to see in this situation.
+
+It sort of looks like git-annex has been unable to lock the local copy of
+the content to indicate that it's in the process of dropping it. I can
+reproduce the error message if I purposefully make it not provide a content
+removal lock. But, I cannot find a code path where a content removal lock
+is not actually provided when dropping from the local repo. 
+(`Command.Drop.performLocal` always passes  `Just contentlock` to `doDrop`.)
+
+Can you paste a full transcript of this happening so I can be sure I
+understand what you're doing and seeing?
+"""]]
diff --git a/doc/forum/S3_remote_not_available.mdwn b/doc/forum/S3_remote_not_available.mdwn
new file mode 100644
index 0000000000..e89a8ead71
--- /dev/null
+++ b/doc/forum/S3_remote_not_available.mdwn
@@ -0,0 +1,31 @@
+One of my remotes is S3 (named s3). I used to be able to run
+
+    $ git annex sync s3 --content
+
+But now I'm getting the following error:
+
+    commit  
+    On branch master
+    nothing to commit, working directory clean
+    ok
+    git-annex: there is no available git remote named "s3"
+
+My `.git/config` file contains following lines which I would assume mean that the remote is there:
+
+    [remote "s3"]
+            annex-s3 = true
+            annex-uuid = bd9af194-b736-4114-a689-9a8bf212fb18
+            fetch = 
+            annex-sync = false
+
+As far as I can tell only change I did was to install newer version of git-annex, currently I have:
+
+    git-annex version: 6.20160418
+    build flags: Assistant Webapp Pairing Testsuite WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 6
+    supported repository versions: 5 6
+    upgrade supported from repository versions: 0 1 2 4 5
+
+How do I recover access to that remote?
diff --git a/doc/forum/S3_remote_not_available/comment_1_0caf92239fb1475cf03de45f0d25291d._comment b/doc/forum/S3_remote_not_available/comment_1_0caf92239fb1475cf03de45f0d25291d._comment
new file mode 100644
index 0000000000..1f6fcd8fca
--- /dev/null
+++ b/doc/forum/S3_remote_not_available/comment_1_0caf92239fb1475cf03de45f0d25291d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-04T17:17:00Z"
+ content="""
+The version info you posted shows that your git-annex is not built with
+support for S3. The "remote types" line should list S3 and does not.
+
+If you got this from a distribution, could you let the distribution know
+that they are building git-annex without S3 support?
+
+If you built it yourself, you probably built it without the haskell aws
+library installed, or with some dependency issue that prevented that
+library from being used.
+"""]]
diff --git a/doc/forum/S3_remote_not_available/comment_2_5895bd050237d08314e3595d93455830._comment b/doc/forum/S3_remote_not_available/comment_2_5895bd050237d08314e3595d93455830._comment
new file mode 100644
index 0000000000..d2397cb15a
--- /dev/null
+++ b/doc/forum/S3_remote_not_available/comment_2_5895bd050237d08314e3595d93455830._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Lukasz"
+ subject="Thank you, indeed that was the problem"
+ date="2016-05-04T17:47:36Z"
+ content="""
+Indeed after getting git-annex from https://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg my problem was solved. Turns out the version from Homebrew-cask doesn't support S3 and I vaguely remember that it was the case first time I tried.
+
+Thank you for the help and for the great piece of software
+"""]]
diff --git a/doc/forum/S3_remote_not_available/comment_3_b685f1d172cca4c488a517024c86ba21._comment b/doc/forum/S3_remote_not_available/comment_3_b685f1d172cca4c488a517024c86ba21._comment
new file mode 100644
index 0000000000..1b8682baed
--- /dev/null
+++ b/doc/forum/S3_remote_not_available/comment_3_b685f1d172cca4c488a517024c86ba21._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-05-04T18:13:39Z"
+ content="""
+Hmm, there should be no reason for homebrew to not built it with S3
+support. Could you file a bug report there?
+"""]]
diff --git a/doc/forum/S3_remote_not_available/comment_4_ff5ce14bd27b32fc1707426f8c2a5487._comment b/doc/forum/S3_remote_not_available/comment_4_ff5ce14bd27b32fc1707426f8c2a5487._comment
new file mode 100644
index 0000000000..c050d67fca
--- /dev/null
+++ b/doc/forum/S3_remote_not_available/comment_4_ff5ce14bd27b32fc1707426f8c2a5487._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Lukasz"
+ subject="comment 4"
+ date="2016-05-04T18:29:54Z"
+ content="""
+I must have done something wrong. It works perfectly after reinstalling it from Homebrew-cask.
+"""]]
diff --git a/doc/forum/SSH_remote_transfers_queued_but_no_movement.mdwn b/doc/forum/SSH_remote_transfers_queued_but_no_movement.mdwn
new file mode 100644
index 0000000000..de5001f007
--- /dev/null
+++ b/doc/forum/SSH_remote_transfers_queued_but_no_movement.mdwn
@@ -0,0 +1,3 @@
+I created a local repository using the assistant, followed by setting up a remote ssh 'full backup' repository. While the assistant is running, changes in the local repository are detected and transfers are initiated, but they stay at 0%. How can I go about trouble-shooting this? I've made the remote annex directories 777 permissions for testing, but no change.
+
+Thanks
diff --git a/doc/forum/SSH_remote_transfers_queued_but_no_movement/comment_1_fea4e2317f850d6166480cddba088ae5._comment b/doc/forum/SSH_remote_transfers_queued_but_no_movement/comment_1_fea4e2317f850d6166480cddba088ae5._comment
new file mode 100644
index 0000000000..d9bf5a97f1
--- /dev/null
+++ b/doc/forum/SSH_remote_transfers_queued_but_no_movement/comment_1_fea4e2317f850d6166480cddba088ae5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-09-18T19:41:39Z"
+ content="""
+First, take a look at the output of `ps fax` .. you should see a `git-annex assistant` process and near it there ought to be a `git annex transferkeys` process. See if that process has any children under it, like perhaps a rsync. If so, it might just be stalled talking to the host for some reason.
+
+The best way to debug it further is probably to run `git annex copy --to $remote` at the command line, passing the name of your remote repository. See if it also stalls there. If so, add a --debug and you can see the actual rsync commands it's using, and perhaps work out the problem from there.
+"""]]
diff --git a/doc/forum/Same_Jabber_account_for_different_annexes.mdwn b/doc/forum/Same_Jabber_account_for_different_annexes.mdwn
new file mode 100644
index 0000000000..f58d4abd06
--- /dev/null
+++ b/doc/forum/Same_Jabber_account_for_different_annexes.mdwn
@@ -0,0 +1 @@
+Is it possible to use the same jabber account for different annexes? I think I've mixed up several repositories by using the same jabber account for synchronizing...
diff --git a/doc/forum/Same_Jabber_account_for_different_annexes/comment_1_90c3954fe11980eef42b5f5d34f83488._comment b/doc/forum/Same_Jabber_account_for_different_annexes/comment_1_90c3954fe11980eef42b5f5d34f83488._comment
new file mode 100644
index 0000000000..e39b7b52be
--- /dev/null
+++ b/doc/forum/Same_Jabber_account_for_different_annexes/comment_1_90c3954fe11980eef42b5f5d34f83488._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-11T15:02:40Z"
+ content="""
+This is a limitation of how jabber is currently used. You need different accounts to sync different repositories over jabber. Supporting using 1 account is the main open todo item on the [[design/assistant/xmpp]] page.
+"""]]
diff --git a/doc/forum/Same_Jabber_account_for_different_annexes/comment_2_802600b3568e5f94d0550092b22975db._comment b/doc/forum/Same_Jabber_account_for_different_annexes/comment_2_802600b3568e5f94d0550092b22975db._comment
new file mode 100644
index 0000000000..6be7841efd
--- /dev/null
+++ b/doc/forum/Same_Jabber_account_for_different_annexes/comment_2_802600b3568e5f94d0550092b22975db._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="paulvt"
+ ip="2001:1af8:ff19:0:a288:b4ff:fe2c:f600"
+ subject="Resources"
+ date="2013-07-13T08:14:35Z"
+ content="""
+XMPP resources (carrying annex.uuid) cannot be of any help here?
+"""]]
diff --git a/doc/forum/Same_file_sent_to_a_webdav_remote_in_transfer_group_multiple_time_during_syncing.mdwn b/doc/forum/Same_file_sent_to_a_webdav_remote_in_transfer_group_multiple_time_during_syncing.mdwn
new file mode 100644
index 0000000000..05a3d61bbf
--- /dev/null
+++ b/doc/forum/Same_file_sent_to_a_webdav_remote_in_transfer_group_multiple_time_during_syncing.mdwn
@@ -0,0 +1,8 @@
+Suppose there are three repo: A, B and transfer, transfer is a webdav remote.
+
+1. I add file-1 to A, do a sync content, file-1 is sent to transfer.
+2. I add file-2 to A, do a sync content, I expect only file-2 to be sent to transfer, but file-1 is sent another time. 
+
+How can I avoid that?
+
+Does other special remote like the rsync special remote has this issue?
diff --git a/doc/forum/Same_files_are_synced_over_and_over_again.mdwn b/doc/forum/Same_files_are_synced_over_and_over_again.mdwn
new file mode 100644
index 0000000000..73c6696439
--- /dev/null
+++ b/doc/forum/Same_files_are_synced_over_and_over_again.mdwn
@@ -0,0 +1,58 @@
+Hello,
+
+I have posted a similiar (same?) problem already some weeks ago: <https://git-annex.branchable.com/forum/File_downloaded_again_and_again/> But since there has been another problem which was fixed, I dare to repost.
+
+I have three repos: marduk (anything / archive) and horus (standard / client) and asaru (standard / client).
+
+Whenever I do a ```git annex sync --content`` the same files are synced over and over again:
+
+```
+florian@horus ~/Documents (git)-[master] % git annex sync --content
+commit  
+On branch master
+nothing to commit, working directory clean
+ok
+pull marduk 
+ok
+get .localized (from marduk...) 
+SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+              0 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+(checksum...) ok
+get Bewerbung/thermoplast.aux (from marduk...) 
+SHA256E-s8--3345a075a22fb3bbc04567a1e5660ed0240d53f5881f458a2234dcd42a78d335.aux
+              8 100%    7.81kB/s    0:00:00 (xfr#1, to-chk=0/1)
+(checksum...) ok
+drop archive/Programmierung/zope/lib/python/Homefolder/.svn/empty-file (locking marduk...) ok
+drop archive/Schule/Geschichte/Biographie 3/biographie.aux (locking marduk...) ok
+pull marduk 
+ok
+(recording state in git...)
+push marduk 
+Counting objects: 8, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (8/8), done.
+Writing objects: 100% (8/8), 661 bytes | 0 bytes/s, done.
+Total 8 (delta 6), reused 0 (delta 0)
+To ssh://marduk.local/home/florian/Documents
+   d151eb6..c31839b  git-annex -> synced/git-annex
+ok
+git annex sync --content  81,50s user 7,19s system 50% cpu 2:54,56 total
+```
+
+When I execute the same command again, the same files are synced again. On the other repos it's the same behavior.
+
+git annex does not seem to record presence of that file:
+
+```
+florian@horus ~/Documents (git)-[master] % git annex whereis Bewerbung/thermoplast.aux
+whereis Bewerbung/thermoplast.aux (1 copy) 
+        f30dd4f0-5a03-4022-8f45-7c2620c4c058 -- Marduk [marduk]
+ok
+```
+
+Is it a bug? Any more information I can provide?
+
+EDIT: A pastebin of the output of a sync run without and with ```--debug```: <http://pastebin.com/raw/ad2T8jeV>
+
+Thanks!
+Florian
diff --git a/doc/forum/Same_files_are_synced_over_and_over_again/comment_1_1260b5ede5a88a95e98855363455ca41._comment b/doc/forum/Same_files_are_synced_over_and_over_again/comment_1_1260b5ede5a88a95e98855363455ca41._comment
new file mode 100644
index 0000000000..87b51550b2
--- /dev/null
+++ b/doc/forum/Same_files_are_synced_over_and_over_again/comment_1_1260b5ede5a88a95e98855363455ca41._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Horus"
+ subject="comment 1"
+ date="2016-08-26T08:32:05Z"
+ content="""
+Nobody having any clue on that?
+"""]]
diff --git a/doc/forum/Searching_metadata_and_file_content__63__.mdwn b/doc/forum/Searching_metadata_and_file_content__63__.mdwn
new file mode 100644
index 0000000000..c13ff36607
--- /dev/null
+++ b/doc/forum/Searching_metadata_and_file_content__63__.mdwn
@@ -0,0 +1,11 @@
+Hi
+
+Is there any (built-in or otherwise) way to search git-annex metadata and file content?  Ideally I think something that knows about git-annex would be helpful because of files moving around / going away due to metadata driven views, dangling symlinks etc.
+
+I'm imagining:
+
+* Something based on Lucene (solr/elasticsearch) or Xapian for fast searches
+* Probably ideally using git-annex metadata to track which files move where on disk
+* Maybe use of inotify to let it know when git annex has moved file content around or added/removed it from a working tree
+
+Thanks everybody, and Joey for making git annex and being an inspiration
diff --git a/doc/forum/Searching_metadata_and_file_content__63__/comment_1_25ac180194a59b659e0b02bb95dd26aa._comment b/doc/forum/Searching_metadata_and_file_content__63__/comment_1_25ac180194a59b659e0b02bb95dd26aa._comment
new file mode 100644
index 0000000000..8b72cc5854
--- /dev/null
+++ b/doc/forum/Searching_metadata_and_file_content__63__/comment_1_25ac180194a59b659e0b02bb95dd26aa._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="konubinix"
+ subject="recoll"
+ date="2015-08-18T13:30:21Z"
+ content="""
+I personally use recoll to do that. It is not perfect but works well.
+
+To extract the metadata, I use a script called git-annex_dump_tags.sh whose content is:
+	set -eu
+	FILE=\"${1}\"
+	DIR=\"$(dirname \"${FILE}\")\"
+	FILE_NO_DIR=\"$(basename \"${FILE}\")\"
+	cd \"${DIR}\"
+	git annex metadata \"${FILE_NO_DIR}\"|\
+	    tail -n+2|\
+	    head -n-1|\
+	    sed -r 's/^ +//'|\
+	    sed -r 's/^([^=]+)=(.+)$/\1 = \2/'
+
+Then in the recoll configuration, I added
+	[~/perso]
+	metadatacmds = ; rclmulti_gitannex = git-annex_dump_tags.sh %f
+
+More information can be found in [link the recoll manual](http://www.lesbonscomptes.com/recoll/usermanual/usermanual.html#RCL.INSTALL.CONFIG.RECOLLCONF).
+
+Then you'll have to indicate what key to use in the indexing by updating the \"fields\" file. For instance, you could add:
+	[prefixes]
+	ack = XYACK
+	year = XYMONTH
+	month = XYMONTH
+	day = XYDAY
+
+	[stored]
+	ack=
+	year=
+	month=
+	day=
+
+I generally use the ack metadata in my bibliography to indicate whether I read the paper or not (ack=no or ack=yes). I can get access to all the paper I did not read yet, that were added in August 2015, and that deal with gaussian processes with the query
+	recoll -t -q ack:no year:2015 month:8 gaussian processes
+
+It was not easy to setup, but it does the job.
+
+Hope that helps.
+"""]]
diff --git a/doc/forum/Searching_metadata_and_file_content__63__/comment_2_5dd29566dacb5ca70340d54b469c40a5._comment b/doc/forum/Searching_metadata_and_file_content__63__/comment_2_5dd29566dacb5ca70340d54b469c40a5._comment
new file mode 100644
index 0000000000..9bd3c27424
--- /dev/null
+++ b/doc/forum/Searching_metadata_and_file_content__63__/comment_2_5dd29566dacb5ca70340d54b469c40a5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="konubinix"
+ subject="link to the files"
+ date="2015-08-18T13:37:12Z"
+ content="""
+The previous comment did not display the files correctly.
+
+[link the script to dump the tags](https://raw.githubusercontent.com/Konubinix/Devel/master/bin/konix_git-annex_dump_tags.sh)
+
+[link the fields file](https://raw.githubusercontent.com/Konubinix/Devel/master/config/recoll/fields)
+
+"""]]
diff --git a/doc/forum/Searching_metadata_and_file_content__63__/comment_3_67715b73349dc92e9746b234024057ef._comment b/doc/forum/Searching_metadata_and_file_content__63__/comment_3_67715b73349dc92e9746b234024057ef._comment
new file mode 100644
index 0000000000..56986b55c1
--- /dev/null
+++ b/doc/forum/Searching_metadata_and_file_content__63__/comment_3_67715b73349dc92e9746b234024057ef._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-08-19T17:11:41Z"
+ content="""
+Nice script to use recoil, and I imagine similar approaches could be used
+to integrate with other search engines.
+
+Note that `git annex metadata --json` yields a format better suited to
+machine parsing. Especially because metadata values can contain arbitrary
+content, even potentially newlines.
+
+There are plans to eventually make git-annex use a caching database for
+things, including metadata. This would automatically get updated whenever there
+are changes to the metadata, and SQL queries could then be run against it.
+Or, `git annex metadata` queries could boil down to SQL queries and so run
+a lot faster than they do now.
+"""]]
diff --git a/doc/forum/Searching_metadata_and_file_content__63__/comment_4_b8fbd129664c9680cd77f89185974741._comment b/doc/forum/Searching_metadata_and_file_content__63__/comment_4_b8fbd129664c9680cd77f89185974741._comment
new file mode 100644
index 0000000000..fc94528faa
--- /dev/null
+++ b/doc/forum/Searching_metadata_and_file_content__63__/comment_4_b8fbd129664c9680cd77f89185974741._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jean.jordaan@4bb3bd508a9eb0a4bab5d1b587dadd2b6c4a7edc"
+ nickname="jean.jordaan"
+ subject="recoll: there's a Unity Lens for it"
+ date="2015-08-26T13:04:12Z"
+ content="""
+I see there is an Ubuntu Unity search lens for recoll: http://www.webupd8.org/2012/03/recoll-lens-full-text-search-unity-lens.html
+It should be possible to integrate git-annex metadata with that ..
+"""]]
diff --git a/doc/forum/Securing_a_shared_ssh_server.mdwn b/doc/forum/Securing_a_shared_ssh_server.mdwn
new file mode 100644
index 0000000000..3e0006cb36
--- /dev/null
+++ b/doc/forum/Securing_a_shared_ssh_server.mdwn
@@ -0,0 +1,3 @@
+Hi, I'd like to share files with friends, to do so we need a shared server to exchange the files. I could setup an ssh access on one of my servers but I don't want others to have a full access. I assume I can restrict this using a `command='wrapper-around-git'` prefix in `.ssh/authorized_keys`, where `wrapper-around-git` is simply a script that checks if `SSH_ORIGINAL_COMMAND` is an authorised command and runs it. This is exactly the approach used with Mercurial (hg-ssh) and presumably git also relies on this mechanism.
+
+But to do so, I need to know what commands can be executed over ssh when using git-annex assistant. Could you document about this? Thanks!
diff --git a/doc/forum/Securing_a_shared_ssh_server/comment_1_ea971b57d94db5b8d487f728faa5e9a8._comment b/doc/forum/Securing_a_shared_ssh_server/comment_1_ea971b57d94db5b8d487f728faa5e9a8._comment
new file mode 100644
index 0000000000..f82a57295b
--- /dev/null
+++ b/doc/forum/Securing_a_shared_ssh_server/comment_1_ea971b57d94db5b8d487f728faa5e9a8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-24T15:35:16Z"
+ content="""
+The git-annex assistant automatically sets up a ssh key that is locked down this way when you select \"ssh server\" in the webapp.
+
+The command you need to allow to run is git-annex-shell. This has been designed to be secure.
+"""]]
diff --git a/doc/forum/Securing_a_shared_ssh_server/comment_2_421a19f6e1fb40db6ee205daf8e3f867._comment b/doc/forum/Securing_a_shared_ssh_server/comment_2_421a19f6e1fb40db6ee205daf8e3f867._comment
new file mode 100644
index 0000000000..3d92c8b273
--- /dev/null
+++ b/doc/forum/Securing_a_shared_ssh_server/comment_2_421a19f6e1fb40db6ee205daf8e3f867._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkwjBDXkP9HAQKhjTgThGOxUa1B99y_WRA"
+ nickname="Franck"
+ subject="comment 2"
+ date="2013-05-24T15:47:36Z"
+ content="""
+Thanks for your quick answer! But this is true only for servers where git-annex is installed. On a server that just does SSH, things must be different. So, I've started to use the SSH `command=` mechanism to log the commands and discovered so far four of them:
+
+ * `sh -c 'echo git-annex-probe...` and `sh -c 'mkdir -p ...` when the server is first connected by a client
+ * `rsync --server -vre.iLsf --partial-dir .rsync-partial . DIR/` and `rsync --server --sender -e31.14 --inplace . DIR//bd1/469/TEXT` when files are transfered between clients
+
+I want to derive patterns from this but if you could give them to me (ie, tell me which parts are fixed and which are variable) this will be safer. Moreover, I'm quite sure there are somme commands missing from my logs... By the way, parameter `-e31.14` to `rsync` surprises me because `-e` is supposed to set the remote shell (like `--rsh`).
+
+Cheers, Franck
+"""]]
diff --git a/doc/forum/Securing_a_shared_ssh_server/comment_3_acdbf92f646dbbf691621f08b3d94c26._comment b/doc/forum/Securing_a_shared_ssh_server/comment_3_acdbf92f646dbbf691621f08b3d94c26._comment
new file mode 100644
index 0000000000..ea48a2caf0
--- /dev/null
+++ b/doc/forum/Securing_a_shared_ssh_server/comment_3_acdbf92f646dbbf691621f08b3d94c26._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-05-27T19:14:37Z"
+ content="""
+I am confident that it will be *easier* to install git-annex-shell on your ssh server than it will be to lock down rsync. 
+
+All you need to do is go get the standalone linux tarball of git-annex, untar it, and add its directory to PATH.
+
+You can google for perl scripts that lock down rsync, but I have never been happy with any of the ones I found.
+"""]]
diff --git a/doc/forum/Securing_a_shared_ssh_server/comment_4_67533d08e1b8706b844262e9c483d982._comment b/doc/forum/Securing_a_shared_ssh_server/comment_4_67533d08e1b8706b844262e9c483d982._comment
new file mode 100644
index 0000000000..107c7b3cce
--- /dev/null
+++ b/doc/forum/Securing_a_shared_ssh_server/comment_4_67533d08e1b8706b844262e9c483d982._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkwjBDXkP9HAQKhjTgThGOxUa1B99y_WRA"
+ nickname="Franck"
+ subject="comment 4"
+ date="2013-05-28T06:34:04Z"
+ content="""
+Thanks, but my server is a synology nas and as you know from another thread of comments, having git-annex work on it is not that simple. ;-)
+Moreover, I'd like to be able to use ssh accounts where I don't have a root access and not necessarily git. So, a general method to restrict ssh would interest me. 
+
+But your answer seems to suggest that almost arbitrary rsync commands may be given. If so, I agree that there are few hopes to build a secured jail around this... But if really a limited subset of commands is used, I think it should be possible to check them securely. 
+
+Now on I'm focused on having git-annex work because this looks like the most promising way. But I'll have another question regarding it: I noticed that we can restrict access to a specific repository using an appropriate environnement variable. But it's it possible to provide a list of repositories instead of just one? My collaborators will typically have access to several shares but not to all of them. 
+
+Thanks for your responsiveness, after trying tens of candidates git-annex appears to be the only serious solution to replace Dropbox and I'm really glad that you actively help your users! 
+"""]]
diff --git a/doc/forum/Securing_a_shared_ssh_server/comment_5_bf193e02b388b4358632a169d2425b5c._comment b/doc/forum/Securing_a_shared_ssh_server/comment_5_bf193e02b388b4358632a169d2425b5c._comment
new file mode 100644
index 0000000000..d0f78da92e
--- /dev/null
+++ b/doc/forum/Securing_a_shared_ssh_server/comment_5_bf193e02b388b4358632a169d2425b5c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 5"
+ date="2013-05-29T16:56:37Z"
+ content="""
+I can't say what options rsync will choose to pass to the server, when the rsync special remote uses rsync. It's up to that command.
+
+`GIT_ANNEX_SHELL_DIRECTORY` currently only supports specifying one directory. 
+"""]]
diff --git a/doc/forum/Securing_a_shared_ssh_server/comment_6_50d391992cd444080ebc70db30b215c5._comment b/doc/forum/Securing_a_shared_ssh_server/comment_6_50d391992cd444080ebc70db30b215c5._comment
new file mode 100644
index 0000000000..fce7ab3dfb
--- /dev/null
+++ b/doc/forum/Securing_a_shared_ssh_server/comment_6_50d391992cd444080ebc70db30b215c5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkwjBDXkP9HAQKhjTgThGOxUa1B99y_WRA"
+ nickname="Franck"
+ subject="comment 6"
+ date="2013-05-29T17:41:25Z"
+ content="""
+OK, I understand now why it is complicated to secure rsync, the best I can hope is to chroot it on a restricted account. Thanks! And the \"currently\" regarding ˋGIT_ANNEX_SHELL_DIRECTORYˋ gives me hope about a future change.  :-)
+Cheers, Franck
+"""]]
diff --git a/doc/forum/Sending_requests_across_the_network.mdwn b/doc/forum/Sending_requests_across_the_network.mdwn
new file mode 100644
index 0000000000..db53224776
--- /dev/null
+++ b/doc/forum/Sending_requests_across_the_network.mdwn
@@ -0,0 +1,15 @@
+Hi,
+
+Is it possible to have git-annex send requests across the repository network? Say I have a network topology like this:  
+Home (annex) <-> Cloud (S3) <-> Laptop (annex)  
+
+Home has all files, cloud has zero, and laptop has subset of files. Let's also assume Laptop can't talk to Home directly (maybe it's behind a NAT), but both Home and Laptop are connected to the internet.  
+If I'm away on my laptop, can I retrieve a file from Home "through" Cloud?
+
+That is, Laptop checking its remotes and none of them have the file I want, so it checks remotes of remotes, etc. I'm not sure if git-annex knows the topology (seems likely considering it can generate the graphviz image). It also seems there is a communication medium of Jabber/XMPP where it could communicate between internet-connected git-annex servers (which might not otherwise be able to talk to each other directly)? So the fact that Cloud isn't a git-annex server, just a dumb key/value store would be okay?
+
+I realize that I could set it up so Home mirrors everything to Cloud and then that eventually mirrors over to Laptop, but let's assume both Cloud and Laptop have small storage capacities, so on-demand fetching would be needed.
+
+This is basically the same usecase as the USB transfer drive to sync two annexes not on the same network, but automated.
+
+Thanks!
diff --git a/doc/forum/Sending_requests_across_the_network/comment_1_8ff713d4c968705061bf2044ea0fe5a0._comment b/doc/forum/Sending_requests_across_the_network/comment_1_8ff713d4c968705061bf2044ea0fe5a0._comment
new file mode 100644
index 0000000000..8cb4575c10
--- /dev/null
+++ b/doc/forum/Sending_requests_across_the_network/comment_1_8ff713d4c968705061bf2044ea0fe5a0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://ypid.wordpress.com/"
+ ip="213.153.84.215"
+ subject="preferred content …"
+ date="2014-07-02T07:26:59Z"
+ content="""
+Hi
+
+This can be accomplished with the use of [[/preferred_content/]].
+"""]]
diff --git a/doc/forum/Sending_requests_across_the_network/comment_2_cb29e5346a8775d87d30b18b7fc005a7._comment b/doc/forum/Sending_requests_across_the_network/comment_2_cb29e5346a8775d87d30b18b7fc005a7._comment
new file mode 100644
index 0000000000..87e6976fe9
--- /dev/null
+++ b/doc/forum/Sending_requests_across_the_network/comment_2_cb29e5346a8775d87d30b18b7fc005a7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 2"
+ date="2014-07-02T17:25:51Z"
+ content="""
+The network topology shown has only a S3 special remote connecting the two repositories. This only provides a place to store file contents, it does not allow syncing the contents of git repositories. 
+
+You need either XMPP(Jabber) for that, or a git remote on some other server. Once there is a way for the git repository to sync, the Home repository will see when Laptop is missing a file it wants (configured via the preferred content mentioned above), and upload it to S3.
+"""]]
diff --git a/doc/forum/Sending_requests_across_the_network/comment_3_9859c46db3527ad329c8e0df06edd153._comment b/doc/forum/Sending_requests_across_the_network/comment_3_9859c46db3527ad329c8e0df06edd153._comment
new file mode 100644
index 0000000000..c63404e0e8
--- /dev/null
+++ b/doc/forum/Sending_requests_across_the_network/comment_3_9859c46db3527ad329c8e0df06edd153._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="neocryptek@659edac901ffbc8e541a974f8f18987eeafc63bd"
+ nickname="neocryptek"
+ avatar="http://cdn.libravatar.org/avatar/d9bfdefa9b503f1ac4844a686618374e"
+ subject="comment 3"
+ date="2016-11-13T22:39:44Z"
+ content="""
+Thanks, that makes sense.
+
+All git annex repositories using the same branch will have the same (symlink) working directory right (assuming entire network has been synced eventually)?
+"""]]
diff --git a/doc/forum/Sending_requests_across_the_network/comment_4_b228914d2a3d7838ebc8f1cae4d8b59a._comment b/doc/forum/Sending_requests_across_the_network/comment_4_b228914d2a3d7838ebc8f1cae4d8b59a._comment
new file mode 100644
index 0000000000..3577a7e0b0
--- /dev/null
+++ b/doc/forum/Sending_requests_across_the_network/comment_4_b228914d2a3d7838ebc8f1cae4d8b59a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="a case for request routing"
+ date="2019-10-20T19:42:03Z"
+ content="""
+This could also be what you're after (just a design)? https://git-annex.branchable.com/design/requests_routing/
+
+This is something I would love to see implemented too. Especially as an addition to get / drop / fsck commands.
+"""]]
diff --git a/doc/forum/Sending_requests_across_the_network/comment_5_3dba5baa95b43f542fe3737397b8c7a8._comment b/doc/forum/Sending_requests_across_the_network/comment_5_3dba5baa95b43f542fe3737397b8c7a8._comment
new file mode 100644
index 0000000000..f81d4968fb
--- /dev/null
+++ b/doc/forum/Sending_requests_across_the_network/comment_5_3dba5baa95b43f542fe3737397b8c7a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 5"
+ date="2019-10-21T02:02:31Z"
+ content="""
+Possibly related: [speculate-can-get: extension of speculate-present](https://git-annex.branchable.com/todo/speculate-can-get___58___extension_of_speculate-present/)
+"""]]
diff --git a/doc/forum/Sending_requests_across_the_network/comment_6_6ef44abc1c279abf315b949d2f947fa4._comment b/doc/forum/Sending_requests_across_the_network/comment_6_6ef44abc1c279abf315b949d2f947fa4._comment
new file mode 100644
index 0000000000..6954f666a7
--- /dev/null
+++ b/doc/forum/Sending_requests_across_the_network/comment_6_6ef44abc1c279abf315b949d2f947fa4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 6"
+ date="2019-10-21T02:02:47Z"
+ content="""
+Possibly related: [speculate-can-get: extension of speculate-present](https://git-annex.branchable.com/todo/speculate-can-get___58___extension_of_speculate-present/)
+"""]]
diff --git a/doc/forum/Setting_required_to___34__groupwanted__34___doesn__39__t_work__44___but_copying_the_groupwanted_expression_does..mdwn b/doc/forum/Setting_required_to___34__groupwanted__34___doesn__39__t_work__44___but_copying_the_groupwanted_expression_does..mdwn
new file mode 100644
index 0000000000..c885ae7db1
--- /dev/null
+++ b/doc/forum/Setting_required_to___34__groupwanted__34___doesn__39__t_work__44___but_copying_the_groupwanted_expression_does..mdwn
@@ -0,0 +1,27 @@
+I'm trying to give all my repositories the same requirements by putting them in a group "`common_requirements`" with a `groupwanted` expression. However, it looks like the requirement is not actually being applied:
+
+    $ git annex required .
+    groupwanted
+    $ git annex group .
+    common_requirements
+    $ git annex groupwanted common_requirements
+    include=dump/angel-openbsd/* and not copies=not_angel-openbsd:3
+    $ git annex fsck --quiet
+    [no output]
+
+The `fsck` should be complaining that some files are not present. If I set the `required` expression directly instead of using `groupwanted`, I get the behaviour I expected:
+
+    $ git annex fsck --quiet
+      ** Required content dump/angel-openbsd/2020-09-12T01:20:52Z_level_0/_.bzip2 is missing from these repositories:
+            91c090a3-a8fc-4540-83ec-57493967c708 -- em [here]
+      ** Required content dump/angel-openbsd/2020-09-12T01:20:52Z_level_0/_home.bzip2 is missing from these repositories:
+            91c090a3-a8fc-4540-83ec-57493967c708 -- em [here]
+    ... (some output omitted)
+    git-annex: fsck: 10 failed
+
+Any idea what could cause `git annex required groupwanted` to behave differently from just copying the groupwanted expression in this case? Note that the repo is not in any other groups (see output of `git annex group .` above). I tried to reproduce this with some fresh toy repositories but wasn't able to --- in my controlled setting, `git annex required groupwanted` did what I wanted.
+
+A couple notes about the context here:
+
+* `dump/angel-openbsd` contains dumps of my host "`angel-openbsd`", and I want them to be stored in at last two repos other than `angel-openbsd` (no point in storing backups on the same computer). This repo should really be in the `not_angel-openbsd` group but I took it out of that group to make sure the issue isn't multiple conflicting `groupwanted` expressions.
+* I would really like to have a global "requirements" setting that generalizes `numcopies`. My `common_requirements` group is a hack to try to achieve this, but I think I will run into trouble if I want to actually use git-annex's `groupwanted` functionality for anything else.
diff --git a/doc/forum/Setup_of_rsync_special_remote_with_non-standard_ssh_port.mdwn b/doc/forum/Setup_of_rsync_special_remote_with_non-standard_ssh_port.mdwn
new file mode 100644
index 0000000000..85755e982d
--- /dev/null
+++ b/doc/forum/Setup_of_rsync_special_remote_with_non-standard_ssh_port.mdwn
@@ -0,0 +1,13 @@
+I want to setup a rsync special remote on my server with a non-standard ssh port.
+
+I tried the following steps:
+
+    git annex initremote rsync-encrypted type=rsync rsyncurl=1.2.3.4:/encrypted-annex encryption=AAAAAAAAA
+    git config remote.rsync-encrypted.annex-rsync-options "-e \'ssh -p 443\'"
+
+But I just get this error:
+
+    [2012-11-22 21:04:30 CET] read: rsync ["-e","'ssh","-p","443'","--progress","--recursive","--partial","-- partial-dir=.rsync-partial","/home/marco/annex/.git/annex/tmp/rsynctmp/15309/","1.2.3.4:/encrypted-annex"]
+    Missing trailing-' in remote-shell command.
+
+I tried some ways to escape the config but I don't have a clue. Anybody?
diff --git a/doc/forum/Setup_of_rsync_special_remote_with_non-standard_ssh_port/comment_1_1eb6990e93ec92cb6fd7dbee59f31072._comment b/doc/forum/Setup_of_rsync_special_remote_with_non-standard_ssh_port/comment_1_1eb6990e93ec92cb6fd7dbee59f31072._comment
new file mode 100644
index 0000000000..5af84acc07
--- /dev/null
+++ b/doc/forum/Setup_of_rsync_special_remote_with_non-standard_ssh_port/comment_1_1eb6990e93ec92cb6fd7dbee59f31072._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="comment 1"
+ date="2012-11-22T22:44:11Z"
+ content="""
+Add the host to your .ssh/config like this
+
+Host myotherpc
+     HostName 10.0.0.10
+     Port 2222
+
+"""]]
diff --git a/doc/forum/Setup_of_rsync_special_remote_with_non-standard_ssh_port/comment_2_c85d5167e7ccce1ecf1de396e72ce7bc._comment b/doc/forum/Setup_of_rsync_special_remote_with_non-standard_ssh_port/comment_2_c85d5167e7ccce1ecf1de396e72ce7bc._comment
new file mode 100644
index 0000000000..c336be0d1c
--- /dev/null
+++ b/doc/forum/Setup_of_rsync_special_remote_with_non-standard_ssh_port/comment_2_c85d5167e7ccce1ecf1de396e72ce7bc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnldTTAP8PAifJUmqhRar6RAWNWlRcencw"
+ nickname="Marco"
+ subject="~/.ssh/config"
+ date="2012-11-23T05:08:47Z"
+ content="""
+Thank you very much. Works like a charm.
+"""]]
diff --git a/doc/forum/Several_concurrent_operations.mdwn b/doc/forum/Several_concurrent_operations.mdwn
new file mode 100644
index 0000000000..1b7a383fde
--- /dev/null
+++ b/doc/forum/Several_concurrent_operations.mdwn
@@ -0,0 +1 @@
+Is it safe to have several `git annex` processes running concurrently in the same repo or in multiple repositories? For example, I have several repositories syncing to each other. Now I run `git annex sync` on them sequentially. Is it safe to run them concurrently?
diff --git a/doc/forum/Several_concurrent_operations/comment_1_885edabc67687e727ab1a111d7d10d1f._comment b/doc/forum/Several_concurrent_operations/comment_1_885edabc67687e727ab1a111d7d10d1f._comment
new file mode 100644
index 0000000000..4c1f739d14
--- /dev/null
+++ b/doc/forum/Several_concurrent_operations/comment_1_885edabc67687e727ab1a111d7d10d1f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-08-15T15:43:00Z"
+ content="""
+git-annex is concurrency safe
+"""]]
diff --git a/doc/forum/Several_concurrent_operations/comment_2_581e53306e47ddb826c030333f9ae9c2._comment b/doc/forum/Several_concurrent_operations/comment_2_581e53306e47ddb826c030333f9ae9c2._comment
new file mode 100644
index 0000000000..9bee88f4c8
--- /dev/null
+++ b/doc/forum/Several_concurrent_operations/comment_2_581e53306e47ddb826c030333f9ae9c2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~liori"
+ nickname="liori"
+ avatar="http://cdn.libravatar.org/avatar/e1d0fdc746b3d21bb147160d40815e37b257b9119774d21784939b2d3ba95a91"
+ subject="comment 2"
+ date="2018-08-17T21:58:03Z"
+ content="""
+So, indeed it works. However, syncing a large archive (2TB, ~1M objects) over several USB HDDs at the same time ended up a bad idea: inevitably at some point every process tried syncing with the same, slowest, repository, and lack of good I/O concurrency on a USB-connected HDD killed all performance. I'm guessing that introducing some targetted locking could probably help, or even maybe just randomizing the order in which repositories are pulled from/pushed to.
+"""]]
diff --git a/doc/forum/Several_concurrent_operations/comment_3_fe49537fa9e0a284705543b010e7aea9._comment b/doc/forum/Several_concurrent_operations/comment_3_fe49537fa9e0a284705543b010e7aea9._comment
new file mode 100644
index 0000000000..bd057a3fa3
--- /dev/null
+++ b/doc/forum/Several_concurrent_operations/comment_3_fe49537fa9e0a284705543b010e7aea9._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-10-08T16:42:29Z"
+ content="""
+If you use the --jobs option, git-annex will actually balance load amoung
+multiple remotes that have the same cost. Which will prevent everything
+bottlenecking on a single repository.
+
+Alternatively, configure the cost of the slow repository to be higher than
+the other drives, and then things like `git annex get` will avoid using the
+slow one if a faster one is available.
+"""]]
diff --git a/doc/forum/Several_lines_for_one_remote_in_remote.log.mdwn b/doc/forum/Several_lines_for_one_remote_in_remote.log.mdwn
new file mode 100644
index 0000000000..73d11ae615
--- /dev/null
+++ b/doc/forum/Several_lines_for_one_remote_in_remote.log.mdwn
@@ -0,0 +1,3 @@
+Hi!
+
+I found more than one line per special remote in git-annex:remote.log file. Is it the same for you?
diff --git a/doc/forum/Several_lines_for_one_remote_in_remote.log/comment_1_fdfb0099924f19fcbf334498d31f1656._comment b/doc/forum/Several_lines_for_one_remote_in_remote.log/comment_1_fdfb0099924f19fcbf334498d31f1656._comment
new file mode 100644
index 0000000000..9c1b709c26
--- /dev/null
+++ b/doc/forum/Several_lines_for_one_remote_in_remote.log/comment_1_fdfb0099924f19fcbf334498d31f1656._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="format of log files on the git-annex branch"
+ date="2019-04-30T17:52:41Z"
+ content="""
+I think only the line with the latest timestamp matters; this format lets [[git-annex-sync]] resolve merge conflicts on the git-annex branch by simply merging the set of lines in the two files. The [[internals]] webpage does refer repeatedly to \"one line per repository\".  @joeyh can you clarify?
+"""]]
diff --git a/doc/forum/Several_lines_for_one_remote_in_remote.log/comment_2_f45a9c92de2d0271e6a427810794b0e4._comment b/doc/forum/Several_lines_for_one_remote_in_remote.log/comment_2_f45a9c92de2d0271e6a427810794b0e4._comment
new file mode 100644
index 0000000000..e01a763e49
--- /dev/null
+++ b/doc/forum/Several_lines_for_one_remote_in_remote.log/comment_2_f45a9c92de2d0271e6a427810794b0e4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-05-06T16:24:25Z"
+ content="""
+Only the most recent line is used.
+"""]]
diff --git a/doc/forum/Share_only_certain_files_of_a_repo___40__Assistant__41__.mdwn b/doc/forum/Share_only_certain_files_of_a_repo___40__Assistant__41__.mdwn
new file mode 100644
index 0000000000..53d0e0165c
--- /dev/null
+++ b/doc/forum/Share_only_certain_files_of_a_repo___40__Assistant__41__.mdwn
@@ -0,0 +1,6 @@
+Hi,
+
+When using git-annex assistant, is there a possibility to share only certain files or directories from a repository (similar to what Dropbox can do), or do we have to share whole repositories so far?
+Could this be a nice wishlist item, or is there a strong reason against adding this feature to git-annex?
+
+Thanks a lot!
diff --git a/doc/forum/Share_only_certain_files_of_a_repo___40__Assistant__41__/comment_1_ec0d56cb31b918023a9184cee168b406._comment b/doc/forum/Share_only_certain_files_of_a_repo___40__Assistant__41__/comment_1_ec0d56cb31b918023a9184cee168b406._comment
new file mode 100644
index 0000000000..8fa6f7b40b
--- /dev/null
+++ b/doc/forum/Share_only_certain_files_of_a_repo___40__Assistant__41__/comment_1_ec0d56cb31b918023a9184cee168b406._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.255.110"
+ subject="comment 1"
+ date="2013-09-09T19:44:57Z"
+ content="""
+Everyone can see the names of every file that is put into the git repository. Whether the contents of those files is transferred from the machine where they were created to other clones of the repository is configurable using [[preferred_content]], but it's not really intended as an access control mechanism.
+"""]]
diff --git a/doc/forum/Share_with_friend_copies_only_sym_links.mdwn b/doc/forum/Share_with_friend_copies_only_sym_links.mdwn
new file mode 100644
index 0000000000..8f31b63372
--- /dev/null
+++ b/doc/forum/Share_with_friend_copies_only_sym_links.mdwn
@@ -0,0 +1,38 @@
+I just setup git-annex across three macs, using git-annex assistant.  I have one repository working fine, which successfully syncs between two of my own accounts on two different machines, via S3.
+
+Now I'm trying to get the "share with a friend" feature to work.  The problem is that only Mac Alias's / sym links are created, for example:
+
+Machine 1:
+- Copy file into ~/annex/
+
+Machine 2:
+- The file is synced as a sym-link, with a link into a file in .git that doesn't exist.
+
+The config is:
+- Version: 4.20130909-ga29f960 - Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi
+- Two macs
+- Share with friend over Jabber
+- Use Box as the cloud sync service with encryption enabled.  Box is setup as a transfer repository.
+
+I've looked through the logs in .git/annex/daemon.log* and there doesn't look to be any problems.
+
+This is what the log looks like:
+
+    [2013-09-14 19:55:47 PDT] Committer: Adding 20120101-..084-1.jpg
+    failed
+    add /Users/nick/Shared/20120101-GOPR0084-1.jpg (checksum...) ok 
+    add /Users/nick/Shared/20120101-GOPR0084-1.jpg (checksum...) ok 
+    add /Users/nick/Shared/20120101-GOPR0084-1.jpg (checksum...) ok 
+    add /Users/nick/Shared/20120101-GOPR0084-1.jpg (checksum...) ok 
+    add /Users/nick/Shared/20120101-GOPR0084-1.jpg (checksum...) [2013-09-14 19:55:47 PDT] Committer: Committing changes to git
+    [2013-09-14 19:55:48 PDT] XMPPSendPack: Syncing with USER2 
+    Already up-to-date.
+    To xmpp::USER2@gmail.com
+       7b65b15..183b91c  git-annex -> refs/synced/6163ef8e-c36a-4b09-919b-9c18ade55234/bmlja2JsYWNrMUBnbWFpbC5jb20=/git-annex
+       3104275..96afa09  master -> refs/synced/6163ef8e-c36a-4b09-919b-9c18ade55234/bmlja2JsYWNrMUBnbWFpbC5jb20=/master
+    [2013-09-14 19:55:49 PDT] XMPPSendPack: Syncing with USER2 
+    Everything up-to-date
+    recv: resource vanished (Connection reset by peer)
+
+
+Any ideas what I should look at next?  Thanks in advance :-)
diff --git a/doc/forum/Share_with_friend_copies_only_sym_links/comment_1_a8d22dfefb219f0c9130cc294364b198._comment b/doc/forum/Share_with_friend_copies_only_sym_links/comment_1_a8d22dfefb219f0c9130cc294364b198._comment
new file mode 100644
index 0000000000..84217711aa
--- /dev/null
+++ b/doc/forum/Share_with_friend_copies_only_sym_links/comment_1_a8d22dfefb219f0c9130cc294364b198._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.105"
+ subject="comment 1"
+ date="2013-09-19T17:41:47Z"
+ content="""
+git-annex can only share the contents of files with a friend when you both have access to a transfer repository. Your friend's git-annex webapp should detect that it does not have such a repository, and should be displaying an alert like this:
+
+[[assistant/cloudnudge.png]]
+(But in this case it should say \"Unable to download files from YourName\")
+
+So, you need to give your friend access to the S3 repository that you're already using to keep your 2 computers in sync. Or, set up some other transfer repository that you both can access.
+
+There is a way in S3 to create another key that can read and write to a S3 bucket. You can then give that key to your friend.
+
+Or, you could set up a shared git repository on a ssh server you both have access to. Or, set up a box.com remote -- the webapp will offer to store the box.com credentials and share them with your friend.
+"""]]
diff --git a/doc/forum/Shared_Encryption_does_not_Work_as_Expected.mdwn b/doc/forum/Shared_Encryption_does_not_Work_as_Expected.mdwn
new file mode 100644
index 0000000000..660006a5ba
--- /dev/null
+++ b/doc/forum/Shared_Encryption_does_not_Work_as_Expected.mdwn
@@ -0,0 +1,11 @@
+I recently started to set up a share that would be synced between multiple machines.  Since I control all of them I thought it might be cool to try using the suggested "shared encryption".  This seems to have been a mistake.
+
+My project folder is now a big mess of symlinks to read-only files.  
+
+I can fix this with a "cp -RH" and get my data back and I can muddle through fixing the permissions but this leads me to two conclusions:
+
+1.  I did something wrong but I don't know what.  Should I have created the ssh remote first and the local repo second?  
+
+2.  This feature should either be hidden or the UI should be much more explicit about how to use it properly.  This cost me quite a bit of time and frustration.
+
+I really like git-annex so I would appreciate any comments or suggestions.
diff --git a/doc/forum/Shared_Encryption_does_not_Work_as_Expected/comment_1_793c71a1efcf160e1829bec3ef0b1be6._comment b/doc/forum/Shared_Encryption_does_not_Work_as_Expected/comment_1_793c71a1efcf160e1829bec3ef0b1be6._comment
new file mode 100644
index 0000000000..25424d4a0c
--- /dev/null
+++ b/doc/forum/Shared_Encryption_does_not_Work_as_Expected/comment_1_793c71a1efcf160e1829bec3ef0b1be6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica Semrick"
+ subject="details"
+ date="2014-11-16T04:42:36Z"
+ content="""
+Hello, 
+
+It is hard to say what happened without an error message or description of what you did. Perhaps you can share those details.
+"""]]
diff --git a/doc/forum/Shared_Encryption_does_not_Work_as_Expected/comment_2_6b603265a2fc78bd2df54102bf94234f._comment b/doc/forum/Shared_Encryption_does_not_Work_as_Expected/comment_2_6b603265a2fc78bd2df54102bf94234f._comment
new file mode 100644
index 0000000000..bec7954c8e
--- /dev/null
+++ b/doc/forum/Shared_Encryption_does_not_Work_as_Expected/comment_2_6b603265a2fc78bd2df54102bf94234f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2014-12-02T17:37:49Z"
+ content="""
+Symlinks to read-only files in .git/annex/objects is how a git-annex
+repository normally looks.
+
+Perhaps you want to use [[direct_mode]]?
+
+This has nothing to do with shared encryption that I can see.
+"""]]
diff --git a/doc/forum/Shared_directory_with_non_git-annex_users.mdwn b/doc/forum/Shared_directory_with_non_git-annex_users.mdwn
new file mode 100644
index 0000000000..b6e9d5aaaa
--- /dev/null
+++ b/doc/forum/Shared_directory_with_non_git-annex_users.mdwn
@@ -0,0 +1,15 @@
+Hello,
+
+I want to use git-annex on a directory that also other persons, without git-annex use, i.e. modify, add and remove files to.
+
+What need I consider when doing that?
+
+ * Use indirect mode
+ * The the .git directory somewhere else?
+ * Be prepared that a ```git annex get``` can always bring up checksum problems because someone modified the file
+
+I assume git-annex checksums before pushing to the repo, so that I don't otherwrite someone elses changes.
+
+What else?
+
+Thanks!
diff --git a/doc/forum/Shared_directory_with_non_git-annex_users/comment_1_a56cb4993982e030eb9fd4cdb3b0c368._comment b/doc/forum/Shared_directory_with_non_git-annex_users/comment_1_a56cb4993982e030eb9fd4cdb3b0c368._comment
new file mode 100644
index 0000000000..698967e7ab
--- /dev/null
+++ b/doc/forum/Shared_directory_with_non_git-annex_users/comment_1_a56cb4993982e030eb9fd4cdb3b0c368._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="http://xgm.de/oid/"
+ nickname="Florian"
+ avatar="http://cdn.libravatar.org/avatar/4c5c0e290374d76c713f482e41f60a3cbee0fa64bb94c6da94e5a61a50824811"
+ subject="comment 1"
+ date="2017-09-24T04:21:11Z"
+ content="""
+Ok, I tried it using ```GIT_DIR``` and ```GIT_WORK_TREE```:
+
+    Current directory is ~/git-annex, ./work exists and is populated with some files.
+
+    % GIT_DIR=~/git-annex/git GIT_WORK_TREE=~/git-annex/work git init
+    % GIT_DIR=~/git-annex/git GIT_WORK_TREE=~/git-annex/work git annex init \"server\"
+    % GIT_DIR=~/git-annex/git GIT_WORK_TREE=~/git-annex/work git annex direct
+    % GIT_DIR=~/git-annex/git GIT_WORK_TREE=~/git-annex/work git annex add .
+    [... file are addded ...]
+    % GIT_DIR=~/git-annex/git GIT_WORK_TREE=~/git-annex/work git annex sync
+    [... file are synced ...]
+    
+    % git clone git remote
+    % cd remote
+    % git annex init \"remote\"
+    % git annex sync
+    
+    
+    % git annex get a.out
+    get a.out
+      Unable to access these remotes: origin
+    
+      Try making some of these repositories available:
+            ed208c9f-a963-4000-a505-c3fe9dab0042 -- server [origin]
+    failed
+    git-annex: get: 1 failed
+    
+    
+    % git annex whereis a.out
+    whereis a.out (1 copy)
+            ed208c9f-a963-4000-a505-c3fe9dab0042 -- server [origin]
+    ok
+
+
+The remote is of course available, it's all local.
+
+What is still wrong?
+
+Thanks,
+Florian
+
+
+"""]]
diff --git a/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex.mdwn b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex.mdwn
new file mode 100644
index 0000000000..6001cdd50a
--- /dev/null
+++ b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex.mdwn
@@ -0,0 +1,16 @@
+Hi,
+
+I'm trying to update the script provided in topic "Decrypting files in special remotes without git-annex" to add support for different MAC algorithms, chunks and sharedpubkey encryption scheme.
+
+I can already decrypt the files using my GPG keys directly, and I'm trying to make the key lookup function to work.
+
+I have difficulties to parse git-annex source code, I cannot find the exact way the special remote keys are computed. I used the script from "yibe" as a starting point (refer to comment #1) because it is in pure bash I can understand:
+
+- From the doc, sharedpubkey cipher is unencrypted in the remote, it is only base64-ed and limited to 256 characters. So I added:
+cipher="$(echo -n "$cipher" | base64 -d | head -c 256)" like it is done for the "shared" encryption scheme.
+
+- From Yibe's script, chunks keys have an extra "-S<chunk_max_size>-C<chunk_number>--" values inside the annex key. But I doubt this part. I tried with and without it: no success.
+
+- Yibe's script handles MAC algorithms correctly. I see no issue there.
+
+In the end, I cannot get the right remote keys for my test file. Question: is there a documentation somewhere about all this encoding chain?
diff --git a/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_10_d214446e2b5a95a6e14b288457e53305._comment b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_10_d214446e2b5a95a6e14b288457e53305._comment
new file mode 100644
index 0000000000..47d6d32375
--- /dev/null
+++ b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_10_d214446e2b5a95a6e14b288457e53305._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 10"
+ date="2018-07-20T22:48:47Z"
+ content="""
+I managed to get the lookup_key() working with sharedpubkey, chunks and mac SHA512, by combining Joey's cipher and yibe's script.
+
+I have to clean the script before posting, but it is basically Yibe's script [(at the bottom of this page)](https://git-annex.branchable.com/tips/Decrypting_files_in_special_remotes_without_git-annex/) with the sharedpubkey cipher above, and nothing more.
+
+    +    elif [ \"$encryption\" = \"sharedpubkey\" ] ; then
+    +        cipher=\"$(echo -n \"$cipher\" | base64 -d)
+    +\"
+        fi
+
+It is working good for my test file, but this file is made of 1 chunk only. Before relying on the script, more tests should be done with bigger files, e.g more chunks.
+
+Anyway, thks to all of you for your help.
+
+"""]]
diff --git a/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_11_d7cf8754a3e923d3f90be44ebd224d18._comment b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_11_d7cf8754a3e923d3f90be44ebd224d18._comment
new file mode 100644
index 0000000000..264dfd892b
--- /dev/null
+++ b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_11_d7cf8754a3e923d3f90be44ebd224d18._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 11"
+ date="2018-07-20T23:03:37Z"
+ content="""
+The original script with sharedpubkey support is available [here](https://raw.githubusercontent.com/oliv5/profile/master/pbin/git-annex-decrypt.sh)
+
+Yibe's enhanced script with sharedpubkey, different mac and chunk support is available [here](https://raw.githubusercontent.com/oliv5/profile/master/pbin/git-annex-decrypt-2.sh). Chunk management should be verified before relying on it, I haven't done it yet except for a basic case (1 chunk per file). Mac support seems ok.
+"""]]
diff --git a/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_1_cf81a5c0d055875a858dd1e6a137b53c._comment b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_1_cf81a5c0d055875a858dd1e6a137b53c._comment
new file mode 100644
index 0000000000..a43883348c
--- /dev/null
+++ b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_1_cf81a5c0d055875a858dd1e6a137b53c._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-07-09T01:25:22Z"
+ content="""
+[internals](https://git-annex.branchable.com/internals/) is the place to start for all of this documentation.
+
+I believe that the special remote key names (written by Joey) are the same as the keys you see in `.git` which are documented here: 
+[key format](https://git-annex.branchable.com/internals/key_format/), you can see this is independent of encryption scheme, and [hashing](https://git-annex.branchable.com/internals/hashing/) talks about the nested directories structure, which you would also need to know.
+
+Some more context on the [Decrypting files in special remotes without git-annex](https://git-annex.branchable.com/tips/Decrypting_files_in_special_remotes_without_git-annex/) tip is at the related forum post [Future proofing / disaster recovery with an encrypted special remote](http://git-annex.branchable.com/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/). Encryption documentation is at [encryption](https://git-annex.branchable.com/encryption/).
+
+But, since you don't actually want to experiment with how keys are stored, and you don't mind relying on `git-annex` I think an easier way to experiment with different encryption schemes would be to [implement your own special remote](https://git-annex.branchable.com/special_remotes/external/), that page contains an `example.sh` code block which is well documented. With `example.sh` you would just need to change `doretrieve` to decrypt before retrieving and `dostore` encrypt before storing.
+
+
+"""]]
diff --git a/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_2_82be119d86818f63da519fa1669d8cdd._comment b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_2_82be119d86818f63da519fa1669d8cdd._comment
new file mode 100644
index 0000000000..c723f63bc8
--- /dev/null
+++ b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_2_82be119d86818f63da519fa1669d8cdd._comment
@@ -0,0 +1,82 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 2"
+ date="2018-07-15T22:46:05Z"
+ content="""
+Thks. My apologies for the long answer delay.
+
+Let's clarify what I'm trying to do: from the files of an encrypted special remote, with their data and filenames encrypted, I'd like to recover the original files back, without using git-annex at all, just in case one day I 'm not able to use git-annex anymore. This is the purpose of the script presented in [Future proofing / disaster recovery with an encrypted special remote](https://git-annex.branchable.com/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/)
+
+*\"I believe that the special remote key names (written by Joey) are the same as the keys you see in .git\"*
+
+This is wrong, and the confusion is this: the local repository key does not change (it is not encrypted), but the file sent to the special remote uses an encrypted key (filename if you prefer). Yes, the file sent to the special remote has its data encrypted and its filename hashed and encrypted too.
+
+*\"I think an easier way to experiment with different encryption schemes would be to implement your own special remote\"*
+
+I did almost this actually: I'm using git-annex \"--debug\" command switch which shows all git commands under the hood. In these, I can see the final encrypted key, which is different than the original one.
+
+An exemple is better than a long speech: I'm using a rclone special remote with the \"shared pubkey\" encryption scheme (see [Encryption](https://git-annex.branchable.com/encryption/), section sharedpubkey). In my local test repo, I have a single file. I can upload and download the file from the special remote as expected.
+
+Local filename: ./test.pdf
+
+Local file: .git/annex/objects/F3/pf/SHA256E-s127597--abc14a6cf4ebb79fdc2eb0d1bf9c304cfce30959661e72e98536faf1bb1b393b.pdf/SHA256E-s127597--abc14a6cf4ebb79fdc2eb0d1bf9c304cfce30959661e72e98536faf1bb1b393b.pdf
+
+Local key: SHA256E-s127597--abc14a6cf4ebb79fdc2eb0d1bf9c304cfce30959661e72e98536faf1bb1b393b.pdf
+
+Special remote debug log: <code>git annex get ./test.pdf --debug</code>
+
+    [2018-07-08 11:37:17.92299562] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+    [2018-07-08 11:37:17.926091484] process done ExitSuccess
+    [2018-07-08 11:37:17.926263261] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2018-07-08 11:37:17.929194789] process done ExitSuccess
+    [2018-07-08 11:37:17.929657888] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..bc15cac806cf0e178b4a4edb29d59ec34a8124cd\",\"--pretty=%H\",\"-n1\"]
+    [2018-07-08 11:37:17.931914542] process done ExitSuccess
+    [2018-07-08 11:37:17.932438022] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+    [2018-07-08 11:37:17.933180259] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+    [2018-07-08 11:37:17.93938515] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"./test.pdf\"]
+    get test.pdf (from myremote...) 
+    [2018-07-08 11:37:17.947328106] chat: /home/olivier/bin/git-annex-remote-rclone []
+    [2018-07-08 11:37:17.949286944] git-annex-remote-rclone[1] --> VERSION 1
+    [2018-07-08 11:37:17.949439446] git-annex-remote-rclone[1] <-- EXTENSIONS INFO
+    [2018-07-08 11:37:17.949976023] git-annex-remote-rclone[1] --> UNSUPPORTED-REQUEST
+    [2018-07-08 11:37:17.950062015] git-annex-remote-rclone[1] <-- PREPARE
+    [2018-07-08 11:37:17.950285846] git-annex-remote-rclone[1] --> GETCONFIG prefix
+    [2018-07-08 11:37:17.950360356] git-annex-remote-rclone[1] <-- VALUE mystore
+    [2018-07-08 11:37:17.953250415] git-annex-remote-rclone[1] --> GETCONFIG target
+    [2018-07-08 11:37:17.953381013] git-annex-remote-rclone[1] <-- VALUE storage
+    [2018-07-08 11:37:17.956128895] git-annex-remote-rclone[1] --> GETCONFIG rclone_layout
+    [2018-07-08 11:37:17.956253609] git-annex-remote-rclone[1] <-- VALUE lower
+    [2018-07-08 11:37:17.958960866] git-annex-remote-rclone[1] --> PREPARE-SUCCESS
+    [2018-07-08 11:37:17.959086461] git-annex-remote-rclone[1] <-- TRANSFER RETRIEVE GPGHMACSHA512--9cbf6fe8def32a6b434c8bfc8991916ff425a0c990be48fffe647c5ab7a6b294ba38e96fa58aebd59eb5b14d0e98475b241cd6098f08f2c10953b999d1bcd01c .git/annex/tmp/GPGHMACSHA512--9cbf6fe8def32a6b434c8bfc8991916ff425a0c990be48fffe647c5ab7a6b294ba38e96fa58aebd59eb5b14d0e98475b241cd6098f08f2c10953b999d1bcd01c
+    [2018-07-08 11:37:17.9597168] git-annex-remote-rclone[1] --> DIRHASH-LOWER GPGHMACSHA512--9cbf6fe8def32a6b434c8bfc8991916ff425a0c990be48fffe647c5ab7a6b294ba38e96fa58aebd59eb5b14d0e98475b241cd6098f08f2c10953b999d1bcd01c
+    [2018-07-08 11:37:17.959807775] git-annex-remote-rclone[1] <-- VALUE 00a/620/
+    [2018-07-08 11:37:19.129883435] git-annex-remote-rclone[1] --> TRANSFER-SUCCESS RETRIEVE GPGHMACSHA512--9cbf6fe8def32a6b434c8bfc8991916ff425a0c990be48fffe647c5ab7a6b294ba38e96fa58aebd59eb5b14d0e98475b241cd6098f08f2c10953b999d1bcd01c
+    [2018-07-08 11:37:19.130224384] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--decrypt\"]
+    [2018-07-08 11:37:19.248666938] process done ExitSuccess
+
+    (checksum...) ok
+    [2018-07-08 11:37:19.2521772] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+    [2018-07-08 11:37:19.252634291] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+    [2018-07-08 11:37:19.259545841] process done ExitSuccess
+    [2018-07-08 11:37:19.259672048] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2018-07-08 11:37:19.262905258] process done ExitSuccess
+    (recording state in git...)
+    [2018-07-08 11:37:19.26348496] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+    [2018-07-08 11:37:19.280879681] process done ExitSuccess
+    [2018-07-08 11:37:19.281192446] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"9fa3141c6ae10188ede17ecd10b71b9f679c32f9\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"]
+    [2018-07-08 11:37:19.285386915] process done ExitSuccess
+    [2018-07-08 11:37:19.285622336] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"81296ea05b728e9440c9d9927121c9b02aca33d4\"]
+    [2018-07-08 11:37:19.289082082] process done ExitSuccess
+    [2018-07-08 11:37:19.290328762] process done ExitSuccess
+    [2018-07-08 11:37:19.290683887] process done ExitSuccess
+    [2018-07-08 11:37:19.290954281] process done ExitSuccess
+    [2018-07-08 11:37:19.291245651] process done ExitSuccess
+
+As you can see, the hashed key is:
+
+00a/620/GPGHMACSHA512--9cbf6fe8def32a6b434c8bfc8991916ff425a0c990be48fffe647c5ab7a6b294ba38e96fa58aebd59eb5b14d0e98475b241cd6098f08f2c10953b999d1bcd01c
+
+It has been hashed (openssl HMACSHA512) and encrypted with GPG. I'd like to be able to recover the original key (SHA256E-s127597--abc14a6cf4ebb79fdc2eb0d1bf9c304cfce30959661e72e98536faf1bb1b393b.pdf) without git-annex. Then I have backup-ed the map between local keys and original filenames, so I'm able to get my file back without using git-annex.
+
+"""]]
diff --git a/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_3_9852ed3def9f7c73924d8be88b8581e5._comment b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_3_9852ed3def9f7c73924d8be88b8581e5._comment
new file mode 100644
index 0000000000..82ceebb07b
--- /dev/null
+++ b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_3_9852ed3def9f7c73924d8be88b8581e5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="remote encrypted keys"
+ date="2018-07-16T12:09:22Z"
+ content="""
+Aaah. I see you have commented on the [Future proofing / disaster recovery with an encrypted special remote](http://git-annex.branchable.com/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/) as well. I'll try to test with `sharedpubkey` if I get a chance.
+
+Have you tried looking at the generated cipher? `git show git-annex:remote.log | grep 'name='\"your-remote-name \"`? Did you try adding `IFS= read -rd '' cipher < <( printf \"$cipher\n\" )`?
+"""]]
diff --git a/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_4_cd56ee6915acb9389876b7a4b7c0e728._comment b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_4_cd56ee6915acb9389876b7a4b7c0e728._comment
new file mode 100644
index 0000000000..a063c28025
--- /dev/null
+++ b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_4_cd56ee6915acb9389876b7a4b7c0e728._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 4"
+ date="2018-07-16T17:04:06Z"
+ content="""
+Yes, I had a look at the cipher, and I cannot tell much about it. It is ... random :) And yes, I tried the removal of the '\n' characters like in pubkey encryption scheme, with no success so far.
+
+I'll post my test script, which is a basic variation of the one given in [Decrypting_files_in_special_remotes_without_git-annex](https://git-annex.branchable.com/tips/Decrypting_files_in_special_remotes_without_git-annex/) to make multiple calls to lookup_key().
+"""]]
diff --git a/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_5_feda43ef61bc7676c3fd8c9308605650._comment b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_5_feda43ef61bc7676c3fd8c9308605650._comment
new file mode 100644
index 0000000000..8f8f936b06
--- /dev/null
+++ b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_5_feda43ef61bc7676c3fd8c9308605650._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 5"
+ date="2018-07-16T22:58:30Z"
+ content="""
+OK. Thanks for all of the patience with the back-and-forth. After trying to follow these steps and re-reading your posts I believe that what you are trying to do is unfortunately not possible with your current setup.
+
+Although you are using public keys to encrypt your content, `git-annex` is hashing the original key names (using a one-way hash) aka SHA1 Digest signed with your public key before storing on the special remote. The public key is just used by the digest algorithm for signing and does not enable you to recover the hashed key. The `git-annex` special remote protocol does not require special remotes to actually store `git-annex` keys, it only requires that special remotes can retrieve content *given* a key.
+
+In Joey's source code `Crypto.hs` in reference to this key generation process he does have a comment to this effect, \"The encryption does not need to be reversable\". I assume Joey used hashes for simplicity and so the filenames could stay short.
+
+In [Future proofing / disaster recovery with an encrypted special remote](http://git-annex.branchable.com/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/) Joey also mentions “That's what's \"special\" about special remotes vs regular git remotes: They only store the content of annexed files and not the git repository. Back up the git repository separately”
+
+So, it seems, in order to recover the original key names you will either have to keep a backup of the original repository or create a new special remote that stores these in a recoverable fashion (instead of using a digest). Perhaps some git commit hook that zips up the `.git` directory and adds it to your repository could be of use?
+"""]]
diff --git a/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_6_da33ab62284728f832257014c351f151._comment b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_6_da33ab62284728f832257014c351f151._comment
new file mode 100644
index 0000000000..bccc57fb6d
--- /dev/null
+++ b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_6_da33ab62284728f832257014c351f151._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 6"
+ date="2018-07-18T22:35:44Z"
+ content="""
+Hi,
+I understand your points, but I think there is a little misunderstanding.
+
+I agree there may be no way to revert the hashing, even given the public key and its corresponding private key (that I have of course, to be able to decrypt the files content). But this is not what I'm trying to do; actually, I want to do the opposite: from the local key, compute the hashed key. In other words, I want to do exactly what git-annex does already internally, but in a little shell script, independent of git-annex (in case git-annex is unusable one day, a.k.a the \"disaster\").
+
+This is the whole purpose of the function \"lookup_key()\" of the shell script of page [Future proofing / disaster recovery with an encrypted special remote](https://git-annex.branchable.com/forum/Future_proofing___47___disaster_recovery_with_an_encrypted_special_remote/): the functions tries to hash/use the keys the same way git-annex does. It prints the final hashed key used in the special remote. This function allows a user to find which file in the special remote corresponds to a given file in the local repository.
+
+This mapping \"local file name\" / \"local key\" / \"special remote hashed key\" is what I want to backup. In case of trouble to run git-annex one day, this mapping would allow me to rename my special remote files to their original filename, after downloading them using third party-tools (sftp, scp, rsync, whatever) and decrypting their content using my private key. All this without git-annex and its special remote third-party script.
+
+Do you see what I'm trying to do ? I rely much on this lookup_key() function, which is basically already implemented inside git-annex. My main pb is I don't understand Haskell, I can only lurk around in the code, but I didn't identify the sequence of operations about these hashed keys.
+
+"""]]
diff --git a/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_7_eb448e997e4dc77c845bc4a9462ee128._comment b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_7_eb448e997e4dc77c845bc4a9462ee128._comment
new file mode 100644
index 0000000000..4bd78cfe77
--- /dev/null
+++ b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_7_eb448e997e4dc77c845bc4a9462ee128._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2018-07-19T16:57:22Z"
+ content="""
+I have addressed the sharedpubkey thing in the other thread.
+
+Chunk keys may have a -S as well as the -C, if the special remote was
+set up with new-style chunking enabled.
+
+A remote can have several different chunk sizes over its
+lifetime; the chunk size used for a given key is in the .log.cnk file
+in the git-annex branch, documented in [[internals]].
+
+The easy way to test if you are generating
+the right key, prior to HMAC encrypting it, is to set up a non-encrypted
+special remote with the same chunking configuration, and look at the chunk
+keys used when files are stored in it.
+"""]]
diff --git a/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_8_7001fb7530f2ee1591b400195f702cd9._comment b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_8_7001fb7530f2ee1591b400195f702cd9._comment
new file mode 100644
index 0000000000..4793a181db
--- /dev/null
+++ b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_8_7001fb7530f2ee1591b400195f702cd9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 8"
+ date="2018-07-19T18:18:39Z"
+ content="""
+This does not seem to resolve the issue. I've filed a bug report with an easy to reproduce case using just local directory remotes. `sharedpubkey` seems to be using a different method than `shared` to created encrypted filenames.
+"""]]
diff --git a/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_9_a27a661e8b589cffb4acad3591586433._comment b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_9_a27a661e8b589cffb4acad3591586433._comment
new file mode 100644
index 0000000000..0143d601f3
--- /dev/null
+++ b/doc/forum/Shared_pubkeys__58___decrypting_files_in_special_remotes_without_git-annex/comment_9_a27a661e8b589cffb4acad3591586433._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2018-07-19T20:30:18Z"
+ content="""
+I tested the script fragement that I posted.
+
+The obvious difference between shared and sharedpubkey, if you look
+at that script fragement, is that shared only uses the first 256 bytes
+of the cipher to encrypt filenames, while sharedpubkey uses the entire
+cipher. 
+"""]]
diff --git a/doc/forum/Shared_repository_without_git-annex_on_central_server.mdwn b/doc/forum/Shared_repository_without_git-annex_on_central_server.mdwn
new file mode 100644
index 0000000000..424174a28e
--- /dev/null
+++ b/doc/forum/Shared_repository_without_git-annex_on_central_server.mdwn
@@ -0,0 +1,10 @@
+Hi,
+
+I went through the documentation but could not find a clear statement about central repositories (or I did not understand it).
+
+I plan to use a central server to store and sync documents from my local PC and my laptop. I do not trust this server so I want to use gcrypt to only save encrypted information remote. The server provides git and rsync access but does not have git-annex installed. My main source of information is: [fully encrypted git repositories with gcrypt](https://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/). On that page is a hint that you can use a server without git-annex but I am not sure if I really understand the documentation as the [centralized git repository tutorial](https://git-annex.branchable.com/tips/centralized_git_repository_tutorial/on_your_own_server/) states you need git-annex on the centralized server.
+
+Is there an option to use a centralized git repository without git-annex installed on the central server?
+
+Thank you very much and kind regards,
+Frank
diff --git a/doc/forum/Shared_repository_without_git-annex_on_central_server/comment_1_286c963b30eee46b261d64937cf66d06._comment b/doc/forum/Shared_repository_without_git-annex_on_central_server/comment_1_286c963b30eee46b261d64937cf66d06._comment
new file mode 100644
index 0000000000..97026460a7
--- /dev/null
+++ b/doc/forum/Shared_repository_without_git-annex_on_central_server/comment_1_286c963b30eee46b261d64937cf66d06._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="comment 1"
+ date="2017-01-16T12:16:37Z"
+ content="""
+You can set the server up as a normal git remote to store file changelogs, and then also as an rsync special remote to store file data.  See https://git-annex.branchable.com/special_remotes/rsync/
+"""]]
diff --git a/doc/forum/Shared_repository_without_git-annex_on_central_server/comment_2_d1f803b68c3789854e483da1318d043d._comment b/doc/forum/Shared_repository_without_git-annex_on_central_server/comment_2_d1f803b68c3789854e483da1318d043d._comment
new file mode 100644
index 0000000000..b8200fc482
--- /dev/null
+++ b/doc/forum/Shared_repository_without_git-annex_on_central_server/comment_2_d1f803b68c3789854e483da1318d043d._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-06-09T17:47:45Z"
+ content="""
+The gcrypt special remote will work without git-annex being installed
+on the server. The server only needs git and rsync. I think the
+tip is fairly clear about that when it says
+
+"While this will work without git-annex being installed on the server, it
+is recommended to have it installed."
+
+Without git-annex being available on the remote server, some things
+like `git annex notifychanges` and content locking during dropping won't
+work with that remote. The basics should work well enough to use it that
+way.
+"""]]
diff --git a/doc/forum/Sharing_annex_with_local_clones.mdwn b/doc/forum/Sharing_annex_with_local_clones.mdwn
new file mode 100644
index 0000000000..756075ef90
--- /dev/null
+++ b/doc/forum/Sharing_annex_with_local_clones.mdwn
@@ -0,0 +1 @@
+Hi, is there any particular problem with symlinking one .git/annex to share between multiple repos?
diff --git a/doc/forum/Sharing_annex_with_local_clones/comment_1_2b60e13e5f7b8cee56cf2ddc6c47f64d._comment b/doc/forum/Sharing_annex_with_local_clones/comment_1_2b60e13e5f7b8cee56cf2ddc6c47f64d._comment
new file mode 100644
index 0000000000..892bc50f52
--- /dev/null
+++ b/doc/forum/Sharing_annex_with_local_clones/comment_1_2b60e13e5f7b8cee56cf2ddc6c47f64d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="don't do that"
+ date="2012-03-19T18:23:13Z"
+ content="""
+Suppose you do that to repos A and B. Now, in A, you `git annex drop` a file that is only present in those repositories. A checks B to make sure it still has a copy of the file. It sees the (same) file there, so assumes it's safe to drop. The file is removed from A, also removing it from B, and losing data.
+
+It is possible to configure A and B to mutually distrust one-another and avoid this problem, but there will be other problems too.
+
+Instead, git-annex supports using `cp --reflink=auto`, which on filesystems supporting Copy On Write (eg, btrfs), avoids duplicating contents when A and B are on the same filesystem.
+"""]]
diff --git a/doc/forum/Sharing_annex_with_local_clones/comment_2_24ff2c1eb643077daa37c01644cebcd2._comment b/doc/forum/Sharing_annex_with_local_clones/comment_2_24ff2c1eb643077daa37c01644cebcd2._comment
new file mode 100644
index 0000000000..88f495da63
--- /dev/null
+++ b/doc/forum/Sharing_annex_with_local_clones/comment_2_24ff2c1eb643077daa37c01644cebcd2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnhsaESlYphzLTzpJy5IxxGFxxctIhWYfo"
+ nickname="Bryon"
+ subject="comment 2"
+ date="2012-03-19T18:46:13Z"
+ content="""
+Ah, OK. Is there a configuration step to set this up, or is this included magic in a new enough git-annex client?
+"""]]
diff --git a/doc/forum/Sharing_annex_with_local_clones/comment_3_5359b8eada24d27be83214ac0ae62f23._comment b/doc/forum/Sharing_annex_with_local_clones/comment_3_5359b8eada24d27be83214ac0ae62f23._comment
new file mode 100644
index 0000000000..3e5fd11545
--- /dev/null
+++ b/doc/forum/Sharing_annex_with_local_clones/comment_3_5359b8eada24d27be83214ac0ae62f23._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnhsaESlYphzLTzpJy5IxxGFxxctIhWYfo"
+ nickname="Bryon"
+ subject="comment 3"
+ date="2012-03-19T18:55:03Z"
+ content="""
+Nevermind, found it. (git-annex 0.08)
+"""]]
diff --git a/doc/forum/Sharing_annex_with_local_clones/comment_4_5c870c49d8093e1a2895224cc6e91ca0._comment b/doc/forum/Sharing_annex_with_local_clones/comment_4_5c870c49d8093e1a2895224cc6e91ca0._comment
new file mode 100644
index 0000000000..5bdaa17003
--- /dev/null
+++ b/doc/forum/Sharing_annex_with_local_clones/comment_4_5c870c49d8093e1a2895224cc6e91ca0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkr_KjpfjbrD4ln15NsBBn7c9j90U6uwqY"
+ nickname="Nicolas"
+ subject="comment 4"
+ date="2014-11-04T23:05:46Z"
+ content="""
+On file system not supporting reflink is there another solution for sharing annex with local clones ?
+"""]]
diff --git a/doc/forum/Sharing_annex_with_local_clones/comment_5_0bf4c0aa3258b156a3df794d5fabb6a2._comment b/doc/forum/Sharing_annex_with_local_clones/comment_5_0bf4c0aa3258b156a3df794d5fabb6a2._comment
new file mode 100644
index 0000000000..5fb2eaec60
--- /dev/null
+++ b/doc/forum/Sharing_annex_with_local_clones/comment_5_0bf4c0aa3258b156a3df794d5fabb6a2._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2014-11-06T19:50:54Z"
+ content="""
+Yes, there's another option since git-annex version 5.20140915.
+
+annex.hardlink can be set to true, and then `git annex get` will
+simply hardlink the files into place. 
+
+Note the caution about using this option:
+
+              Use with caution --  This  can  invalidate  numcopies  counting,
+              since  with hard links, fewer copies of a file can exist. So, it
+              is a good idea to  mark  a  repository  using  this  setting  as
+              untrusted.
+
+And, there's a nice easy way to set up local clone that is configured this way:
+
+              When  a repository is set up using git clone --shared, git-annex
+              init will automatically set annex.hardlink and mark the  reposi‐
+              tory as untrusted.
+"""]]
diff --git a/doc/forum/Sharing_annex_with_local_clones/comment_6_d2ebe3cc20ec8b7c778c7b22aa62896c._comment b/doc/forum/Sharing_annex_with_local_clones/comment_6_d2ebe3cc20ec8b7c778c7b22aa62896c._comment
new file mode 100644
index 0000000000..9f9d8ee251
--- /dev/null
+++ b/doc/forum/Sharing_annex_with_local_clones/comment_6_d2ebe3cc20ec8b7c778c7b22aa62896c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="calmofthestorm"
+ avatar="http://cdn.libravatar.org/avatar/9d97e9bcb1cf7680309e37cd69fab408"
+ subject="Thanks, this does exactly what I want"
+ date="2020-06-15T07:25:30Z"
+ content="""
+I'm always impressed that when I Google for how to do some very specific thing with git-annex, there's typically already an easy to use option that does exactly that. The default behavior when a git repo is cloned with --shared is excellent user experience, and precisely matches my intuition for how it should behave.
+"""]]
diff --git a/doc/forum/Sharing_over_SMB__47__NFS_while_running_assistant__63__.mdwn b/doc/forum/Sharing_over_SMB__47__NFS_while_running_assistant__63__.mdwn
new file mode 100644
index 0000000000..365f30dc22
--- /dev/null
+++ b/doc/forum/Sharing_over_SMB__47__NFS_while_running_assistant__63__.mdwn
@@ -0,0 +1,15 @@
+I have a large collection of media files (music, tv shows, movies, random things I've recorded from television and converted from VHS, random videos from the internet that I've saved) that are stored safely on my TrueNAS box. I've been toying with the idea of importing them into git-annex - I am already using annex for other things, and it's great. :-)
+
+
+Currently, the TrueNAS machine shares these files out over the network as Samba and NFS shares. There's a couple of subdirs that get modified frequently by the likes of Sonarr and Radarr downloading stuff from Usenet - these are running on a Windows machine, which has the shares mounted via Samba. I would like to have git-annex deal with these files, but I have concerns around how (a) the shares would work, (b) how to deal with autonomous file changes from the likes of Radarr and (c) any potential corruption issues stemming from the two.
+
+I did a small scale test where I created a jail on my TrueNAS box, mounted the shared drive and created a test subdirectory and filled it with 40GBs of exemplar data. After importing this data into annex, I found that running annex assistant in the jail and modifying the directory (over the Samba share from the machine that runs Sonarr/Radarr) seemed to work well enough - in that there was a commit corresponding to whatever changed without me intervening. This seems ok, and even viewing the media over the Samba share on a Windows machine (to my surprise) worked fine - it didn't even care or seem to notice that the files were now technically stored as symlinks.
+
+I was happy to see this largely go ok, so my plan is (right now) to simply create a couple of different annexes using the existing file trees and continue as normal (no changes to how shares work, or to Sonarr or Radarr). To deal with Sonarr and Radarr's changes to the files, I'd run an annex assistant in the jail for each of the folders to make the commits automatically as the machine makes changes to files over the Samba share.
+
+Is this a terrible idea? What sort of issues am I likely to have?
+
+
+
+
+
diff --git a/doc/forum/Should_transfer_to_a_special_remote_verify_source_content__63__.mdwn b/doc/forum/Should_transfer_to_a_special_remote_verify_source_content__63__.mdwn
new file mode 100644
index 0000000000..091e11c909
--- /dev/null
+++ b/doc/forum/Should_transfer_to_a_special_remote_verify_source_content__63__.mdwn
@@ -0,0 +1,74 @@
+A [DataLad issue](https://github.com/datalad/datalad/issues/4795) was
+raised about users inadvertently corrupting locked files.  That led to
+an example where a user could copy corrupted content over to a special
+remote, and the content isn't flagged until a `get` call.  (A slightly
+different example, based on a directory remote and without
+`exporttree=yes`, is included below.)
+
+In the case of a regular remote, the `copy` call would fail earlier
+with
+
+```
+  verification of content failed
+
+  failed to send content to remote
+
+
+  verification of content failed
+
+  failed to send content to remote
+failed
+git-annex: copy: 1 failed
+```
+
+Should something similar happen when copying or exporting to a special
+remote?  Perhaps verification before transfer to a special remote
+isn't worth it, but the successful transfer surprised me given the
+behavior when transferring to regular remotes.
+
+[[!format sh """
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/dl-XXXXXXX)"
+
+mkdir d
+git init a
+(
+    cd a
+    git annex init
+
+    echo one >one
+    git annex add one
+    git commit -mone
+
+    one_resolved=$(readlink -f one)
+    chmod +w $one_resolved
+    echo more >>$one_resolved
+    chmod -w $one_resolved
+
+    git annex initremote d type=directory directory="$PWD"/../d encryption=none
+    git annex copy --to=d
+    git annex drop one
+    git annex get one
+)
+"""]]
+
+```
+[...]
+copy one (to d...) 
+ok                              
+(recording state in git...)
+drop one ok
+(recording state in git...)
+get one (from d...) 
+                                
+  verification of content failed
+
+  Unable to access these remotes: d
+
+  Try making some of these repositories available:
+  	e6878750-3a21-4ae9-b9ae-a241f17176a4 -- [d]
+failed
+git-annex: get: 1 failed
+```
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
diff --git a/doc/forum/Should_transfer_to_a_special_remote_verify_source_content__63__/comment_1_6de754a926c5ad0e2da6cf6a1c58ce69._comment b/doc/forum/Should_transfer_to_a_special_remote_verify_source_content__63__/comment_1_6de754a926c5ad0e2da6cf6a1c58ce69._comment
new file mode 100644
index 0000000000..914a5eca88
--- /dev/null
+++ b/doc/forum/Should_transfer_to_a_special_remote_verify_source_content__63__/comment_1_6de754a926c5ad0e2da6cf6a1c58ce69._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="verifying source contents"
+ date="2020-09-02T15:35:18Z"
+ content="""
+This would especially make sense when sending files to a trusted special remote, where the file may be the only copy.
+Maybe, set the mtime of all files (and directories) in .git/annex/objects to some sentinel value after they're written, then check if the mtime still has that value before sending the file elsewhere?
+
+If a special remote [[supports named pipes|todo/let_external_remotes_declare_support_for_named_pipes]], the verification could be done on-the-fly as the file is streamed to the remote.
+
+
+"""]]
diff --git a/doc/forum/Simple_check_out_with_assistant__63__.mdwn b/doc/forum/Simple_check_out_with_assistant__63__.mdwn
new file mode 100644
index 0000000000..755b237e49
--- /dev/null
+++ b/doc/forum/Simple_check_out_with_assistant__63__.mdwn
@@ -0,0 +1,2 @@
+I want to use the annex assistant instead of the command line. Which is the recommended method to check out a file that I want to edit?
+
diff --git a/doc/forum/Simple_check_out_with_assistant__63__/comment_1_ade8a0743ef1ec933c8a40ed64eeac2d._comment b/doc/forum/Simple_check_out_with_assistant__63__/comment_1_ade8a0743ef1ec933c8a40ed64eeac2d._comment
new file mode 100644
index 0000000000..dbb018b53f
--- /dev/null
+++ b/doc/forum/Simple_check_out_with_assistant__63__/comment_1_ade8a0743ef1ec933c8a40ed64eeac2d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmaXxj2aPZrtRkWzwswTNep8hFif1cXykw"
+ nickname="Erik"
+ subject="Follow-up: check-in"
+ date="2012-11-08T08:59:14Z"
+ content="""
+And the obvious follow-up question: How to I check in and sync the file that I just edited? (Note: I want to avoid the command line)
+"""]]
diff --git a/doc/forum/Simple_question_about_web_remote.mdwn b/doc/forum/Simple_question_about_web_remote.mdwn
new file mode 100644
index 0000000000..1805405076
--- /dev/null
+++ b/doc/forum/Simple_question_about_web_remote.mdwn
@@ -0,0 +1,27 @@
+Hello. I have been having some trouble with downloading podcasts. I have read the guide, but I was getting the following error message:
+
+```
+  verification of content failed
+
+  Unable to access these remotes: web
+
+  Try making some of these repositories available:
+  	00000000-0000-0000-0000-000000000001 -- web
+failed
+git-annex: get: 1 failed
+```
+I have tried several times. Some times it seemed to work, others it did not — it was not very structured, so I do not recall the details. Recently I recreated the entire stuff from scratch and was downloading files, and after I upgraded to 6.20160318 it stopped working and just gives me the error message above, after downloading the file.
+
+I tried looking up information about the web remote, but it mentions nothing about "making the web remote available" or something that I found to address this subject. So I am confused. What is wrong with my web repository? Why did it stop working? How can I fix it? How can I prevent this from happening in the future? Thank you.
+
+Here is the version information:
+
+```
+git-annex version: 6.20160318
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 6
+supported repository versions: 5 6
+upgrade supported from repository versions: 0 1 2 4 5
+```
diff --git a/doc/forum/Simple_question_about_web_remote/comment_1_a732a7264b60faed29782a034c0bc592._comment b/doc/forum/Simple_question_about_web_remote/comment_1_a732a7264b60faed29782a034c0bc592._comment
new file mode 100644
index 0000000000..4b39005f2f
--- /dev/null
+++ b/doc/forum/Simple_question_about_web_remote/comment_1_a732a7264b60faed29782a034c0bc592._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-12T17:33:08Z"
+ content="""
+The web remote is automatically available (so long as you have an internet
+connection) and does not need any configuration to use.
+
+What's going on here is, after git-annex downloads a file from the web
+remote, as from any remote, it verifies its checksum. Seems that the
+checksum of the content at an url on the web has changed. So, git-annex
+rejects the bad data.
+
+(Note that git-annex only started verifying checksums of downloads in
+version 5.20151019.)
+
+Now, sometimes you don't care if eg, a podcast file might get modified
+after `git-annex importfeed` initially adds it, and you want to just
+download whatever file is on the web now, and treat any contents coming
+from the web at different times as equivilant.
+
+The way to do that is to use --relaxed when running git-annex addurl or
+importfeed.
+"""]]
diff --git a/doc/forum/Simple_question_about_web_remote/comment_2_274810bdc176984c056304e17668c63b._comment b/doc/forum/Simple_question_about_web_remote/comment_2_274810bdc176984c056304e17668c63b._comment
new file mode 100644
index 0000000000..2e6db099d1
--- /dev/null
+++ b/doc/forum/Simple_question_about_web_remote/comment_2_274810bdc176984c056304e17668c63b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Gus"
+ subject="Branching questions"
+ date="2016-04-29T12:11:35Z"
+ content="""
+Thank you for your help. I would still like to ask a few related questions.
+
+1. I was unaware that RSS feeds provide a form of checksum. Are they stored as the filename? I still find it unlikely that the old file was changed in the few minutes between git-annex importing the feed and me asking for the file. However, maybe the file was changed, the feed was not updated and podcast downloading software are not as strict as git-annex.
+
+2. How should I proceed in order to update my podcasts. This is something I do not understand and I should play a bit with git-annex to figure out: there are multiple ways to remove files. As I understand it:
+  - I could `rm` the file. This removes the link. git still remembers the file and keeps it.
+  - I could `git rm` the file and commit. This could keep the file or remove it. git remembers the file's history and keeps its last state. However, in git-annex I am not sure what is kept in .git/. Can I re-add the file?
+  - I could `git-annex drop` the file. git-annex ensures the minimum number of copies, so this makes me believe that git totally forgets about the file (no last state copy). However, in the podcast tips you say that dropped files are not redownloaded. So this leaves me confused.
+
+I tried to `git rm -r` the podcast directory, and now I cannot importfeed it again. :-S Hmm... It is nothing important, but could you explain me what is going on, please?
+"""]]
diff --git a/doc/forum/Simple_question_about_web_remote/comment_3_984a3b05bcc6b24430210d9ae039a026._comment b/doc/forum/Simple_question_about_web_remote/comment_3_984a3b05bcc6b24430210d9ae039a026._comment
new file mode 100644
index 0000000000..93ac6c4026
--- /dev/null
+++ b/doc/forum/Simple_question_about_web_remote/comment_3_984a3b05bcc6b24430210d9ae039a026._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-05-03T18:14:51Z"
+ content="""
+The checksum is not coming from the RSS feed. If you ran `git-annex
+importfeed` without `--fast`, it downloaded the content and checksummed it
+locally, and this checksum becomes the one it expects to have when
+downloading the file again. If you ran `git annex importfeed` with `--fast`, 
+it doesn't get a checksum, but it does record the current size of the file
+as reported by the web server. 
+
+Either the size or the checksum changing could be what caused the
+verification problem. It's possible that the web server reports a bogus
+size somehow (I've seen this happen before), or the web server might
+be some kind of CDN that is serving up different file contents at
+different times for whatever reason.
+
+If you use `git rm` or commit a `rm`, then any content of the file is
+retained in the git-annex repository, at least until you use `git annex
+unused` to remove it. You can check out old versions of the branch and the
+file content will still be there.
+
+If you use `git annex drop`, it drops the content from the local
+repository. git-annex still knows about the file, and `git annex get` can
+get the content again, perhaps by downloading it from the web again.
+
+Since git-annex still knows about the file even if it's removed or dropped,
+`git annex importfeed` avoids re-importing such files from a rss feed.
+"""]]
diff --git a/doc/forum/Simple_question_about_web_remote/comment_4_510abbb4deca924020b87f1eb7d61005._comment b/doc/forum/Simple_question_about_web_remote/comment_4_510abbb4deca924020b87f1eb7d61005._comment
new file mode 100644
index 0000000000..a44d75dd0f
--- /dev/null
+++ b/doc/forum/Simple_question_about_web_remote/comment_4_510abbb4deca924020b87f1eb7d61005._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Gus"
+ subject="Restarting"
+ date="2016-05-17T10:36:55Z"
+ content="""
+My attempt to redo the podcast repository adding the `--fast` flag seems to be successful. Thank you.
+
+However, I would still like to ask you one thing about the delete operations.
+When would you use `git rm` instead of `git-annex drop` (in a repository that uses only git-annex to store the files)?
+
+Oh, and I'll also sneak in a small question that is unrelated to the above, since I don't think it deserves its own topic:
+Is git-annex safe to operate in parallel tasks? Can I be adding file A and move file B and rename file C from the same repository at the same time, without the integrity of the repository being compromised?
+
+
+"""]]
diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts.mdwn b/doc/forum/Slightly_finer_control_over_file_whereabouts.mdwn
new file mode 100644
index 0000000000..2caf332af4
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts.mdwn
@@ -0,0 +1,18 @@
+I have previously been confused by how to have a bit more manual control over where files are (as in [[bugs/git-annex_immediately_re-gets_dropped_files/]]).
+
+I thought perhaps something like an archive directory would work, but as I might want different computers to have different content, perhaps a per-computer archive repository.
+
+To that end, I have
+
+<pre>walter@dionysus:~/annex$ git annex content .
+(exclude=archive/dionysus/* or (not (copies=archive:1 or copies=smallarchive:1))) or (not copies=semitrusted+:1)
+ok</pre>
+
+which is a modified version of the archive [[preferred_content]], but with the intention that I change the part after `exclude` to be different for each client.
+I also set the group to client for this client (dionysus).
+
+However, it does not seem to drop files when I move them into `archive/dionysus/`, and I cannot see anything in the logs to suggest why.
+
+What am I doing wrong here? Or, is this the wrong approach?
+
+--Walter
diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_10_bcb883d46a637dd1a8ef9a92733d202a._comment b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_10_bcb883d46a637dd1a8ef9a92733d202a._comment
new file mode 100644
index 0000000000..5064de49dc
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_10_bcb883d46a637dd1a8ef9a92733d202a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 10"
+ date="2013-11-08T18:32:12Z"
+ content="""
+If I could comprehensively fix that bug I would.
+
+But, it's supposed to already be fixed when using direct mode. Were you using indirect mode when you saw the problem?
+"""]]
diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_11_b7a8b9eaf114f883866fbf2be51b622f._comment b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_11_b7a8b9eaf114f883866fbf2be51b622f._comment
new file mode 100644
index 0000000000..7155b560f4
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_11_b7a8b9eaf114f883866fbf2be51b622f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
+ nickname="Walter"
+ subject="comment 11"
+ date="2013-11-09T06:02:36Z"
+ content="""
+No, this was using direct mode.
+"""]]
diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_1_6236bcfa9beba705ead3ec2141c5d835._comment b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_1_6236bcfa9beba705ead3ec2141c5d835._comment
new file mode 100644
index 0000000000..b9f598a1f0
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_1_6236bcfa9beba705ead3ec2141c5d835._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.105"
+ subject="comment 1"
+ date="2013-09-19T17:57:22Z"
+ content="""
+That sound like it should work. I suggest you play around with `git annex drop --auto` at the command line. It will probably tell you why it is unable to drop a file if the problem is something like not enough copies located elsewhere. Or, if it doesn't try to drop the file at all, you'll know your preferred content expression makes it want to keep the file.
+"""]]
diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_2_ea935b37ca93e73c85d04df7c9bf6057._comment b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_2_ea935b37ca93e73c85d04df7c9bf6057._comment
new file mode 100644
index 0000000000..50f113aa33
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_2_ea935b37ca93e73c85d04df7c9bf6057._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
+ nickname="Walter"
+ subject="comment 2"
+ date="2013-09-19T22:22:03Z"
+ content="""
+So, it sort of works...
+
+I realised that I don't have `archive` repository but instead `backup` ones, so adding that makes `git annex drop --auto` want to drop files in archive/dionysus.
+
+However, the webapp then gets them. This I don't understand.
+"""]]
diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_3_f89a8e38283ac4c8c4a3b74c413d67a1._comment b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_3_f89a8e38283ac4c8c4a3b74c413d67a1._comment
new file mode 100644
index 0000000000..41bb0cb58e
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_3_f89a8e38283ac4c8c4a3b74c413d67a1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.105"
+ subject="comment 3"
+ date="2013-09-20T00:15:07Z"
+ content="""
+does `git annex get --auto` also get them?
+"""]]
diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_4_07a0a754a089c46ff69dc97ea7ba9384._comment b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_4_07a0a754a089c46ff69dc97ea7ba9384._comment
new file mode 100644
index 0000000000..30e3965af0
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_4_07a0a754a089c46ff69dc97ea7ba9384._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
+ nickname="Walter"
+ subject="comment 4"
+ date="2013-09-20T02:41:22Z"
+ content="""
+I am testing on my laptop, and the content expression there is
+`(exclude=archive/kronos/* ) or (not copies=semitrusted+:1)`
+to simplify things; I interpret this to mean it wants everything not in archive/kronos, and it wants things there where that's the only copy.
+
+The problem is that `git annex drop --auto` does indeed drop things, but `git annex get --auto` gets them; surely it should not be possible for that to happen?
+
+I also tried the preferred content expression of `(exclude=archive/kronos/* )`, and the same thing happens.
+
+The version of git-annex that I am using is
+<pre>git-annex version: 4.20130919-g9be7762
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS Feeds Quvi
+local repository version: 4
+default repository version: 3
+supported repository versions: 3 4
+upgrade supported from repository versions: 0 1 2</pre>
+"""]]
diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_5_e884c001a556a0c693d1cc9a97c068ac._comment b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_5_e884c001a556a0c693d1cc9a97c068ac._comment
new file mode 100644
index 0000000000..50e5cf9afe
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_5_e884c001a556a0c693d1cc9a97c068ac._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4830:1600:187::2"
+ subject="comment 5"
+ date="2013-09-20T15:31:18Z"
+ content="""
+Ok. This seems to be a bug in git-annex then. While it's surprisingly difficult to do so, it tries to interpet preferred content expressions in a stable way -- that is, they should not want to get a file when it's missing and then want to drop it when it's present.
+"""]]
diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_6_3e8674b5857e4994dfbc26be4f4b2855._comment b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_6_3e8674b5857e4994dfbc26be4f4b2855._comment
new file mode 100644
index 0000000000..eff5d9339e
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_6_3e8674b5857e4994dfbc26be4f4b2855._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4830:1600:187::2"
+ subject="comment 6"
+ date="2013-09-20T15:36:25Z"
+ content="""
+I tried to reproduce this behavior, but failed. My configuration was 2 repos, A and B, with B the origin of A. A was configured with \"exclude=archive/kronos/*\"
+(also tried \"(exclude=archive/kronos/* ) or (not copies=semitrusted+:1)\")
+
+<pre>
+joey@darkstar:~/tmp/A>git annex get --auto
+joey@darkstar:~/tmp/A>git annex get
+get archive/kronos/foo (from origin...) ok
+(Recording state in git...)
+joey@darkstar:~/tmp/A>git annex drop --auto
+drop archive/kronos/foo ok
+(Recording state in git...)
+joey@darkstar:~/tmp/A>git annex get --auto
+joey@darkstar:~/tmp/A>
+</pre>
+
+... Which is how you want it to behave.
+
+So I wonder if it's something else in your configuration. The best thing to do would be if you can come up with a series of commands I can follow to build repositories that exhibit the problem.
+"""]]
diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_7_7aeabc2e52a39423e83fbd04560e8f91._comment b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_7_7aeabc2e52a39423e83fbd04560e8f91._comment
new file mode 100644
index 0000000000..145a913e90
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_7_7aeabc2e52a39423e83fbd04560e8f91._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4830:1600:187::2"
+ subject="comment 7"
+ date="2013-09-20T15:37:48Z"
+ content="""
+Also, please check if you're running into [[bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time]]
+"""]]
diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_8_53b95449cfad2fe0f72d2ad642822c03._comment b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_8_53b95449cfad2fe0f72d2ad642822c03._comment
new file mode 100644
index 0000000000..d866380f20
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_8_53b95449cfad2fe0f72d2ad642822c03._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
+ nickname="Walter"
+ subject="comment 8"
+ date="2013-09-20T20:30:52Z"
+ content="""
+Hmm, that could be it; the same content is both inside and outside the archive directory.
+
+What I really want to do (because maybe I'm not going about this the best way) is to use the assistant not in manual mode, but allow for some repos not having some files.
+I thought by placing them in an archive directory, then they would be dropped, and to get them again, I can just delete from the archive dir, and they will be got (as the file is also outside the archive dir.
+
+But, if that is not going to work, is there a better way to manage that?
+
+By the way, I really appreciate all the work you put into this awesome project.
+"""]]
diff --git a/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_9_a17c102a45e4fc3f101a79acb8eb4081._comment b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_9_a17c102a45e4fc3f101a79acb8eb4081._comment
new file mode 100644
index 0000000000..56d22c7fdf
--- /dev/null
+++ b/doc/forum/Slightly_finer_control_over_file_whereabouts/comment_9_a17c102a45e4fc3f101a79acb8eb4081._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
+ nickname="Walter"
+ subject="comment 9"
+ date="2013-09-23T21:58:42Z"
+ content="""
+Thinking about this further, I'm not entirely sure what I want. I think the confusion arises from git-annex sometimes (mostly) caring about file *contents* (ie dependent on the hash of the file), but sometimes (preferred content, not sure of anywhere else) caring about file *location*.
+
+What I think I actually want is a way of specifying locations that are not synced, such that if the file is changed somewhere (on another computer), the new version should not be downloaded. But, if the same content is in another location as well, the behaviour should be stable, I don't know how that should work though.
+
+So, perhaps the best strategy is to have an explicit list of locations that I don't want, in the preferred content expression, if it could cope with files being in and out of some location at the same time. I think this would be easiest if I could avoid manually editing the expression all the time, maybe make a file with a list of file locations, if it would be possible for git-annex to handle that? I think it isn't at the moment, and my haskell is non-existent. That way, I could write some helper to add and remove files from this list. For example `dont-want file1 file2 dir1` would add these locations to a file, and `want file1 file2 dir1` would remove them from this list. Actually, I suppose I could make it just create an appropriate preferred-content expression, and then it doesn't need to support some file of locations.
+
+So, after that ramble, I guess I'm envisaging a preferred content expression like `content=(exclude=path/to/file1 and exclude=path/to/file1 and exclude=path/to/dir1/*) or (some statement about numcopies)`, which I imagine updating whenever I decide I do/don't want some file. The only obstacle to this working is [[bugs/Handling of files inside and outside archive directory at the same time]] (as I understand that bug, could be wrong on the implications of it), meaning (of course) if there are two files with the same content, and I exclude one of them, and not the other, then it both wants and doesn't want the file, and it (and I) get really confused.
+
+I suppose a short-term (well, slow) solution is to find duplicates of files I don't want, and if that exists either add the duplicate to my content expression (to say I don't want it), or remove the one I don't want from the expression (to say I do). This doesn't work well for when the content of one of the files changes (and so they are no longer duplicates), but I think I would search for them each time I generate the expression, so at that time it would no longer find the duplicate.
+
+So, @joey, I guess my question is, what are the chances of that bug being resolved somehow? Or if that is not likely to happen soon, I might try to implement my solution outline from the previous two paragraphs.
+"""]]
diff --git a/doc/forum/Slow_direct_mode_repository.mdwn b/doc/forum/Slow_direct_mode_repository.mdwn
new file mode 100644
index 0000000000..7a175c2c1b
--- /dev/null
+++ b/doc/forum/Slow_direct_mode_repository.mdwn
@@ -0,0 +1,48 @@
+Hello.
+
+I have been using a portable USB disc for storing media. After several weeks of inactivity, when I used it with git-annex again I noticed it was running very slowly. I mean, it is an USB 2.0 connection, `git-annex sync` would take a few minutes, but now it takes *many hours*.
+
+When adding files to it (`git-annex add`), I would see the list of files passing by at the speed I would expect, but then, at the end, I would have to wait; the next day I saw the operation had completed. `git-annex status` makes me wait a similar amount of time, and `git-annex sync` also makes me wait, even when it has nothing to do — I saw `top` reporting 100% CPU usage, `iotop` saying `git` and `fuse` were saturating the USB connection to its maximum.
+
+File operations outside of `git-annex` seem to work fine, so I can't blame the hardware or the filesystem (NTFS mounted with `fuse`).
+
+I would like to know your thought about this problem, that I was not noticing before. Here is the regular information to help you form an oppinion:
+
+    % time git annex status --debug
+    [2016-09-07 20:20:46.093990203] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","status","-uall","-z"]
+    [2016-09-08 15:05:23.239573491] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","cat-file","--batch"]
+    [2016-09-08 15:08:25.605689622] process done ExitSuccess
+    git annex status --debug  33802.97s user 1162.38s system 51% cpu 18:47:39.54 total
+
+
+    % git-annex info
+    repository mode: direct
+    trusted repositories: 0
+    semitrusted repositories: 4
+    	00000000-0000-0000-0000-000000000001 -- web
+     	00000000-0000-0000-0000-000000000002 -- bittorrent
+     	069de9a2-dc53-4c0a-82e0-a61a1f29e6b3 -- stratos PC [stratos]
+     	49b5b3a4-56ac-4cf2-aed9-1c23d3181c97 -- Toshiba USB HDD [here]
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: 120.41 gigabytes (+1 megabyte reserved)
+    local annex keys: 6303
+    local annex size: 1.87 terabytes
+    annexed files in working tree: 7412
+    size of annexed files in working tree: 2.24 terabytes
+    bloom filter size: 32 mebibytes (1.3% full)
+    backend usage: 
+    	SHA256E: 7412
+
+
+    % git-annex version
+    git-annex version: 6.20160613-g1e4e6f4
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
+Thank you for your time.
diff --git a/doc/forum/Slow_direct_mode_repository/comment_1_63656f103d418b35712a68f771ed559c._comment b/doc/forum/Slow_direct_mode_repository/comment_1_63656f103d418b35712a68f771ed559c._comment
new file mode 100644
index 0000000000..9c57bf1824
--- /dev/null
+++ b/doc/forum/Slow_direct_mode_repository/comment_1_63656f103d418b35712a68f771ed559c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Gus"
+ subject="Never mind"
+ date="2016-09-10T09:15:56Z"
+ content="""
+I tried to reboot the system. I am getting normal speeds again. That was a relief!
+
+I'm sorry to have bothered you.
+"""]]
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows.mdwn b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows.mdwn
new file mode 100644
index 0000000000..3cbd7f4459
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows.mdwn
@@ -0,0 +1,3 @@
+Copying a large file from windows (msysgit 1.9.5.msysgit.1, git-annex 20150406) to a bare repository on debian wheezy (git 1.9.1 git-annex 20141024)  I can only get around 2 MB/s transfer speed.  I tested using normal windows copy (smb) and got around 10 MB/s, while the git-annex copy was still going on.  I tried plain ssh and got 9 MB/s.  So, something to do with git-annex is being slow it seems.  Any ideas on how to remedy this, or is it a known issue?
+
+Note: Problem not seen going from linux to linux... waaaayyy faster (40 MB/s) to put it lightly (10 min vs all day)  The destination server is the same.
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_1_dd4ebb10ac87e3ee6158b7e7b1273a81._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_1_dd4ebb10ac87e3ee6158b7e7b1273a81._comment
new file mode 100644
index 0000000000..e6bdd2c4e7
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_1_dd4ebb10ac87e3ee6158b7e7b1273a81._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T20:30:19Z"
+ content="""
+There's not a lot of places where git-annex could make this slower.
+git-annex copy is just running rsync to the ssh server.
+
+Have you tried benchmarking rsync of a large file to the server w/o
+git-annex? rsync does do considerably more client-side work than does
+scp, in order to support resuming, so that might be it.
+"""]]
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_2_9ebd40fe286f6c13f1021bf360e9c48e._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_2_9ebd40fe286f6c13f1021bf360e9c48e._comment
new file mode 100644
index 0000000000..9ad9acb7da
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_2_9ebd40fe286f6c13f1021bf360e9c48e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlh1G1u_AMJEyADqlfuzV2cePniocDyK6A"
+ nickname="Adam"
+ subject="comment 2"
+ date="2015-04-13T14:21:12Z"
+ content="""
+rsync is indeed slow...  The version bundled with msysgit is being used, and I read it has performance issues.  Will try a different version of rsync, perhaps in cygwin.
+"""]]
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_c169ad6205c998f3d44f9c0859071b2d._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_c169ad6205c998f3d44f9c0859071b2d._comment
new file mode 100644
index 0000000000..13a8541886
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_c169ad6205c998f3d44f9c0859071b2d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlh1G1u_AMJEyADqlfuzV2cePniocDyK6A"
+ nickname="Adam"
+ subject="comment 3"
+ date="2015-04-13T17:23:15Z"
+ content="""
+Verified to be rsync 3.0.9 that is bundled with git annex which is causing the slowdown. Updated to cwRsync 3.1.1 and it was fast again.
+"""]]
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_4_aee3fc6be01bb75709451eea0decf112._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_4_aee3fc6be01bb75709451eea0decf112._comment
new file mode 100644
index 0000000000..ed2f3cc358
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_4_aee3fc6be01bb75709451eea0decf112._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-04-18T19:12:19Z"
+ content="""
+Well, git-annex bundles a copy of rsync, and the one that it includes 
+is the one from cygwin.
+
+It sounds like there's a newer version, also from cygwin, that is faster?
+
+I've pinged the git-annex Windows autobuilder admin to see if we can
+upgrade that.
+"""]]
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_5_b1841fc129a9ce6d1c22840ee648f958._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_5_b1841fc129a9ce6d1c22840ee648f958._comment
new file mode 100644
index 0000000000..147ca76828
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_5_b1841fc129a9ce6d1c22840ee648f958._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-04-18T19:26:25Z"
+ content="""
+<https://www.itefix.net/cwrsync>
+
+Hmm, ok, so that's not the cygwin rsync and it has a gui and bundles its
+own ssh that won't behave the same as the one bundled with git-annex.
+
+Maybe at least some of the speed improvements could be had by just
+upgrading the rsync and ssh from cygwin though..
+"""]]
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_6_1ce9bb47dadd2b1c500b2a20fd669907._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_6_1ce9bb47dadd2b1c500b2a20fd669907._comment
new file mode 100644
index 0000000000..43f5c3f2ee
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_6_1ce9bb47dadd2b1c500b2a20fd669907._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlh1G1u_AMJEyADqlfuzV2cePniocDyK6A"
+ nickname="Adam"
+ subject="comment 6"
+ date="2015-04-20T17:40:38Z"
+ content="""
+There are pathing issues with other applications if I add cygwin to the path or are you saying copy over cygwin's copy?  I did have issues with ssh and had to copy all the files to the bin dir rather than the cmd dir to get it to work.  This also screwed up my home dir, making c:\ my home.  I went with it, since I'm the only user, and copied my .ssh folder to C:\... not the most secure option, but it worked.  (Note: it seemed to ignore the $HOME env variable)
+
+"""]]
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_7_4b78b200b884c4ac7c052055b3e26784._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_7_4b78b200b884c4ac7c052055b3e26784._comment
new file mode 100644
index 0000000000..a49eacd140
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_7_4b78b200b884c4ac7c052055b3e26784._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlh1G1u_AMJEyADqlfuzV2cePniocDyK6A"
+ nickname="Adam"
+ subject="comment 7"
+ date="2015-04-20T17:43:11Z"
+ content="""
+I'm not using cygwin for git-annex.  I'm using msysgit and git's command window.
+"""]]
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_8_97ef11581c5dc6eeeabb4b244bdc6c30._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_8_97ef11581c5dc6eeeabb4b244bdc6c30._comment
new file mode 100644
index 0000000000..9363c0bfa7
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_8_97ef11581c5dc6eeeabb4b244bdc6c30._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 8"
+ date="2015-04-20T17:43:48Z"
+ content="""
+We've updated the autobuilder, so the daily build now has the most recent rsync and ssh from cygwin included in it. I'd be curious if that improves the speed any.
+"""]]
diff --git a/doc/forum/So_this_is_embarrassing__59___git_export_not_working.mdwn b/doc/forum/So_this_is_embarrassing__59___git_export_not_working.mdwn
new file mode 100644
index 0000000000..e2cc928c00
--- /dev/null
+++ b/doc/forum/So_this_is_embarrassing__59___git_export_not_working.mdwn
@@ -0,0 +1,243 @@
+Always worked before, doesn't work now. I just get this.
+
+```
+git annex export master --to film-depot --verbose
+export film-depot .gitattributes ok
+export film-depot .gitignore ok
+export film-depot 00-GIT-ANNEX ok
+export film-depot README.md ok
+(recording state in git...)
+```
+
+Previously I had 99 movie files that would export to my external drive. Now no dice.
+
+```
+[2021-12-06 22:22:25.524608] (Utility.Process) process [72333] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2021-12-06 22:22:25.529718] (Utility.Process) process [72333] done ExitSuccess
+[2021-12-06 22:22:25.530949] (Utility.Process) process [72334] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-12-06 22:22:25.536689] (Utility.Process) process [72334] done ExitSuccess
+[2021-12-06 22:22:25.537822] (Utility.Process) process [72335] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..59ceb4035e85ed634375596e4a44c5b3ad300652","--pretty=%H","-n1"]
+[2021-12-06 22:22:25.5423] (Utility.Process) process [72335] done ExitSuccess
+[2021-12-06 22:22:25.5431] (Utility.Process) process [72336] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..8c7c4c0941afc7d9a05294dad06414fd0333eba9","--pretty=%H","-n1"]
+[2021-12-06 22:22:25.549488] (Utility.Process) process [72336] done ExitSuccess
+[2021-12-06 22:22:25.550436] (Utility.Process) process [72337] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..f442bffc235f879ec4fb31dfcbf89b3ac778b520","--pretty=%H","-n1"]
+[2021-12-06 22:22:25.5569] (Utility.Process) process [72337] done ExitSuccess
+[2021-12-06 22:22:25.557738] (Utility.Process) process [72338] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..eb25a989c75c43bc36c99c4ccf28ef17123a1f5e","--pretty=%H","-n1"]
+[2021-12-06 22:22:25.566045] (Utility.Process) process [72338] done ExitSuccess
+[2021-12-06 22:22:25.56697] (Utility.Process) process [72339] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..6eda2fa9081d65baf6758e608fad471fd0e9dc3e","--pretty=%H","-n1"]
+[2021-12-06 22:22:25.576185] (Utility.Process) process [72339] done ExitSuccess
+[2021-12-06 22:22:25.577034] (Utility.Process) process [72340] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..89670c26510137760b55e0cc3b8378968e9f7b01","--pretty=%H","-n1"]
+[2021-12-06 22:22:25.584382] (Utility.Process) process [72340] done ExitSuccess
+[2021-12-06 22:22:25.591735] (Utility.Process) process [72341] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-12-06 22:22:25.592642] (Utility.Process) process [72342] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-12-06 22:22:25.597233] (Utility.Process) process [72343] read: git ["config","--null","--list"]
+[2021-12-06 22:22:25.600309] (Utility.Process) process [72343] done ExitSuccess
+[2021-12-06 22:22:25.601475] (Utility.Process) process [72344] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","rev-parse","--verify","--quiet","master:"]
+[2021-12-06 22:22:25.604843] (Utility.Process) process [72344] done ExitSuccess
+[2021-12-06 22:22:25.607159] (Utility.Process) process [72345] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","mktree","--batch","-z"]
+[2021-12-06 22:22:25.607845] (Utility.Process) process [72346] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-tree","--full-tree","-z","-r","-t","--","bf9aa984fda078c0f7e2ae3f416f7366a1bd6906"]
+[2021-12-06 22:22:25.613684] (Utility.Process) process [72346] done ExitSuccess
+[2021-12-06 22:22:25.613994] (Utility.Process) process [72345] done ExitSuccess
+[2021-12-06 22:22:25.615026] (Utility.Process) process [72347] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/master"]
+[2021-12-06 22:22:25.62044] (Utility.Process) process [72347] done ExitSuccess
+[2021-12-06 22:22:25.625281] (Annex.Branch) read export.log
+[2021-12-06 22:22:25.626277] (Annex.Branch) set export.log
+[2021-12-06 22:22:25.627203] (Utility.Process) process [72348] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-12-06 22:22:25.632737] (Utility.Process) process [72348] done ExitSuccess
+[2021-12-06 22:22:25.633737] (Utility.Process) process [72349] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","rev-parse","--verify","--quiet","59ceb4035e85ed634375596e4a44c5b3ad300652:"]
+[2021-12-06 22:22:25.637618] (Utility.Process) process [72349] done ExitSuccess
+[2021-12-06 22:22:25.63843] (Utility.Process) process [72350] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","mktree","--batch","-z"]
+[2021-12-06 22:22:25.639126] (Utility.Process) process [72351] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-tree","--full-tree","-z","-t","--","ba3ecb9e4da6ac71d242696ed0d48d2fcaa45e05"]
+[2021-12-06 22:22:25.643712] (Utility.Process) process [72351] done ExitSuccess
+[2021-12-06 22:22:25.65106] (Utility.Process) process [72350] done ExitSuccess
+[2021-12-06 22:22:25.651934] (Utility.Process) process [72352] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","commit-tree","d1d9c03e2594032e2e01eec9965d978406ea910d","--no-gpg-sign","-p","59ceb4035e85ed634375596e4a44c5b3ad300652"]
+[2021-12-06 22:22:25.657279] (Utility.Process) process [72352] done ExitSuccess
+[2021-12-06 22:22:25.658145] (Utility.Process) process [72353] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","commit-tree","ba3ecb9e4da6ac71d242696ed0d48d2fcaa45e05","--no-gpg-sign","-p","e0c16268cb18fdcb965f08c1257e43de24c577dd"]
+[2021-12-06 22:22:25.663939] (Utility.Process) process [72353] done ExitSuccess
+[2021-12-06 22:22:25.664818] (Utility.Process) process [72354] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-ref","refs/heads/git-annex","c89b7490febb74f3224165fab88e4eb14f05b37a"]
+[2021-12-06 22:22:25.670076] (Utility.Process) process [72354] done ExitSuccess
+[2021-12-06 22:22:25.671381] (Utility.Process) process [72355] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","diff-tree","-z","--raw","--no-renames","-l0","-r","bf9aa984fda078c0f7e2ae3f416f7366a1bd6906","bf9aa984fda078c0f7e2ae3f416f7366a1bd6906","--"]
+[2021-12-06 22:22:25.67517] (Utility.Process) process [72355] done ExitSuccess
+[2021-12-06 22:22:25.67536] (Annex.Branch) read export.log
+[2021-12-06 22:22:25.675925] (Annex.Branch) set export.log
+[2021-12-06 22:22:25.676667] (Utility.Process) process [72356] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-tree","--full-tree","-z","-r","--","bf9aa984fda078c0f7e2ae3f416f7366a1bd6906"]
+[2021-12-06 22:22:25.681325] (Utility.Process) process [72357] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-12-06 22:22:25.68243] (Utility.Process) process [72358] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-12-06 22:22:25.686724] (Annex.Branch) read b24/e7d/GIT--06be486d36bd2b4cb8314b7084dca8b7252f7199.log
+export film-depot .gitattributes ok
+[2021-12-06 22:22:25.687565] (Annex.Branch) read 8eb/f8d/GIT--e43b0f988953ae3a84b00331d0ccf5f7d51cb3cf.log
+export film-depot .gitignore ok
+[2021-12-06 22:22:25.688064] (Annex.Branch) read 80f/4f8/GIT--e69de29bb2d1d6434b8b29ae775ad8c2e48c5391.log
+export film-depot 00-GIT-ANNEX ok
+[2021-12-06 22:22:25.688591] (Annex.Branch) read 087/1f9/WORM-s1116285116-m1593796806--A,32Beautiful,32Mind,32,402001,41,321080p.mkv.log
+[2021-12-06 22:22:25.689105] (Annex.Branch) read b6a/0bf/WORM-s1037772729-m1595036949--Alien,32,401979,41,32720p.mkv.log
+[2021-12-06 22:22:25.689592] (Annex.Branch) read fc1/47e/WORM-s2584124634-m1593818075--Aliens,32,401986,41,32SE,321080p.mp4.log
+[2021-12-06 22:22:25.690021] (Annex.Branch) read c32/8d4/WORM-s1598749320-m1589682846--American,32Pie,32,401999,41,321080p.mp4.log
+[2021-12-06 22:22:25.69048] (Annex.Branch) read c61/d77/WORM-s2118257276-m1525912572--American,32Pie,32II,32,402001,41,32720p.mp4.log
+[2021-12-06 22:22:25.691044] (Annex.Branch) read a91/0bf/WORM-s2117183986-m1571443864--American,32Pie,32Wedding,32,402003,41,321080p.mp4.log
+[2021-12-06 22:22:25.69149] (Annex.Branch) read 6e0/e37/WORM-s2524668661-m1636382981--Armageddon,32,401998,41,321080p.mp4.log
+[2021-12-06 22:22:25.692829] (Annex.Branch) read e65/e2a/WORM-s2049268430-m1634226615--Avengers,,,32Age,32of,32Ultron,32,402015,41,321080p.mp4.log
+[2021-12-06 22:22:25.693395] (Annex.Branch) read 0dc/df0/WORM-s1175417895-m1555550689--Avengers,,,32Infinity,32War,32,402018,41.mkv.log
+[2021-12-06 22:22:25.697988] (Annex.Branch) read a08/5cc/WORM-s1073479115-m1536010249--Avengers,,,32The,32,402012,41,32720p.mkv.log
+[2021-12-06 22:22:25.698657] (Annex.Branch) read ae6/34b/WORM-s1942991012-m1595715198--Back,32to,32the,32Future,32,401985,41,321080p.mp4.log
+[2021-12-06 22:22:25.699122] (Annex.Branch) read 9a6/a47/WORM-s2108282730-m1636257924--Beverly,32Hills,32Cop,322,32,401987,41,321080p.mp4.log
+[2021-12-06 22:22:25.699818] (Annex.Branch) read 7cb/426/WORM-s1785804434-m1636253231--Beverly,32Hills,32Cop,32III,32,401994,41,321080p.mp4.log
+[2021-12-06 22:22:25.700452] (Annex.Branch) read d14/a70/WORM-s2036895920-m1595715206--Black,32Hawk,32Down,32,402001,41,321080p.mp4.log
+[2021-12-06 22:22:25.700903] (Annex.Branch) read bc1/18b/WORM-s2620361196-m1526994937--Contact,32,401997,41,321080p.mp4.log
+[2021-12-06 22:22:25.701508] (Annex.Branch) read 2de/e6b/WORM-s1937651408-m1595715213--Crimson,32Tide,32,401995,41,321080p.mp4.log
+[2021-12-06 22:22:25.70195] (Annex.Branch) read f38/990/WORM-s2211439503-m1595715222--Die,32Hard,32,401988,41,321080p.mp4.log
+[2021-12-06 22:22:25.702438] (Annex.Branch) read 95c/68d/WORM-s902398239-m1530225214--Doctor,32Strange,32,402016,41,32720p.mp4.log
+[2021-12-06 22:22:25.703064] (Annex.Branch) read 137/b62/WORM-s1768193827-m1563842861--Edge,32of,32Tomorrow,32,402014,41,321080p.mp4.log
+[2021-12-06 22:22:25.703694] (Annex.Branch) read a03/fcb/WORM-s1917114368-m1560119371--Enders,32Game,32,402013,41.avi.log
+[2021-12-06 22:22:25.7043] (Annex.Branch) read e1b/f67/WORM-s1828312956-m1586061932--Enemy,32at,32the,32Gates,32,402001,41,321080p.mkv.log
+[2021-12-06 22:22:25.704724] (Annex.Branch) read c9d/3b1/WORM-s2706201822-m1586047240--Enemy,32of,32the,32State,32,401998,41,321080p.mp4.log
+[2021-12-06 22:22:25.705143] (Annex.Branch) read 930/182/WORM-s848757174-m1518370060--Field,32of,32Dreams,32,401989,41.mp4.log
+[2021-12-06 22:22:25.705724] (Annex.Branch) read afa/30f/WORM-s2104549496-m1595715258--Fifth,32Element,,,32The,32,401997,41,321080p.mp4.log
+[2021-12-06 22:22:25.706178] (Annex.Branch) read 551/6ba/WORM-s1339997270-m1636253775--Final,32Fantasy,32The,32Spirits,32Within,32,402001,41,321080p.mkv.log
+[2021-12-06 22:22:25.706805] (Annex.Branch) read 91d/c72/WORM-s2237782219-m1613505958--First,32Knight,32,401995,41,321080p.mp4.log
+[2021-12-06 22:22:25.707349] (Annex.Branch) read ddc/080/WORM-s2637057735-m1542757748--Fugitive,,,32The,32,401993,41,32720p.mkv.log
+[2021-12-06 22:22:25.707983] (Annex.Branch) read 152/91b/WORM-s2342003785-m1518370156--Galaxy,32Quest,32,401999,41.mkv.log
+[2021-12-06 22:22:25.708543] (Annex.Branch) read e7a/984/WORM-s1756467527-m1595109447--Ghostbusters,32,401984,41,321080p.mp4.log
+[2021-12-06 22:22:25.708988] (Annex.Branch) read 0e8/ff6/WORM-s3933229071-m1602373090--Gladiator,32,402000,41,321080p.mkv.log
+[2021-12-06 22:22:25.709365] (Annex.Branch) read 87a/3d3/WORM-s1690337749-m1636382985--Groundhog,32Day,32,401993,41,321080p.mp4.log
+[2021-12-06 22:22:25.709988] (Annex.Branch) read 3bd/e70/WORM-s2046008512-m1555550686--Harry,32Brown,32,402009,41,321080p.mp4.log
+[2021-12-06 22:22:25.710588] (Annex.Branch) read 972/247/WORM-s1073833682-m1584242874--Hart,39s,32War,32,402002,41,32720p.mp4.log
+[2021-12-06 22:22:25.711033] (Annex.Branch) read a95/4ec/WORM-s790627159-m1518370226--Hunt,32for,32Red,32October,,,32The.mkv.log
+[2021-12-06 22:22:25.711609] (Annex.Branch) read d45/158/WORM-s1048990304-m1636829207--In,32the,32Heat,32of,32the,32Night,32,401967,41,32720p.mkv.log
+[2021-12-06 22:22:25.712203] (Annex.Branch) read 0f6/7f5/WORM-s2479265386-m1595715232--Inception,32,402010,41,321080p.mp4.log
+[2021-12-06 22:22:25.712624] (Annex.Branch) read b9f/faa/WORM-s1855071446-m1525796911--Independence,32Day,32,401996,41.mp4.log
+[2021-12-06 22:22:25.713269] (Annex.Branch) read bb9/0bf/WORM-s2123742199-m1595715241--Indiana,32Jones,32and,32the,32L-86e667a21adfdf59df66cde8e3c653de.log
+[2021-12-06 22:22:25.713841] (Annex.Branch) read 7d3/b92/WORM-s1832093728-m1634098515--Indiana,32Jones,32and,32the,32Raiders,32of,32the,32Lost,32Ark,32,401981,41,321080p.mp4.log
+[2021-12-06 22:22:25.714393] (Annex.Branch) read 7fe/c79/WORM-s3384564503-m1636826013--Inglourious,32Basterds,32,402009,41,321080p.mkv.log
+[2021-12-06 22:22:25.714964] (Annex.Branch) read 1b1/94b/WORM-s2640394877-m1598221200--Insider,,,32The,32,401999,41,321080p.mp4.log
+[2021-12-06 22:22:25.715363] (Annex.Branch) read 496/2db/WORM-s2431697820-m1636258658--Interstellar,32,402014,41,321080p.mp4.log
+[2021-12-06 22:22:25.716042] (Annex.Branch) read ec2/268/WORM-s1282009570-m1518370381--Iron,32Man.mkv.log
+[2021-12-06 22:22:25.716841] (Annex.Branch) read d9c/575/WORM-s2280602670-m1596874458--Kelly,39s,32Heroes,32,401970,41,321080p.mp4.log
+[2021-12-06 22:22:25.7175] (Annex.Branch) read fb8/a6a/WORM-s1532588342-m1518370430--King,32Author.mkv.log
+[2021-12-06 22:22:25.71824] (Annex.Branch) read 1e8/0c4/WORM-s2362174469-m1596874396--L.A.,32Confidential,32,401997,41,321080p.mp4.log
+[2021-12-06 22:22:25.718719] (Annex.Branch) read bdf/208/WORM-s2580319882-m1597519936--Last,32Samurai,,,32The,32,402003,41,321080p.mp4.log
+[2021-12-06 22:22:25.719159] (Annex.Branch) read c83/4b8/WORM-s2200470144-m1518370504--Last,32of,32the,32Mohicans,,,32-3e3f78ef1cecfd2d87dd70a706077bfb.log
+[2021-12-06 22:22:25.719718] (Annex.Branch) read 7ca/016/WORM-s1615545853-m1597087605--Lethal,32Weapon,32,401987,41,321080p.mp4.log
+[2021-12-06 22:22:25.720106] (Annex.Branch) read fbe/3b4/WORM-s1041661875-m1636833567--Lethal,32Weapon,322,32,401989,41,32720p.mkv.log
+[2021-12-06 22:22:25.720762] (Annex.Branch) read bfb/f3d/WORM-s832138999-m1536079832--Letters,32From,32Iwo,32Jima,32,402006,41,32720p.mkv.log
+[2021-12-06 22:22:25.721395] (Annex.Branch) read e18/c6d/WORM-s2246486055-m1523923497--Lord,32Of,32The,32Rings,,,32The-8d99f15c7937db1ce3c48c84d452f106.log
+[2021-12-06 22:22:25.721973] (Annex.Branch) read d9e/f96/WORM-s3806431573-m1524068665--Lord,32of,32the,32Rings,,,32The-a01e8f7ccb49401f72481cac93bbce95.log
+[2021-12-06 22:22:25.722584] (Annex.Branch) read bfa/477/WORM-s2248342870-m1524067831--Lord,32Of,32The,32Rings,,,32The-dddba4061a1be729c40b94630b22efb3.log
+[2021-12-06 22:22:25.723152] (Annex.Branch) read 911/69b/WORM-s2173429952-m1597087612--Manchurian,32Candidate,,,32The,32,402004,41,321080p.mp4.log
+[2021-12-06 22:22:25.723603] (Annex.Branch) read ab2/50d/WORM-s2538513668-m1518370740--Mask,32of,32Zorro,,,32The.mp4.log
+[2021-12-06 22:22:25.724229] (Annex.Branch) read ab8/84c/WORM-s1990201957-m1563568759--Oblivion,32,402013,41,321080p.mp4.log
+[2021-12-06 22:22:25.724791] (Annex.Branch) read fe2/13e/WORM-s865388563-m1518370822--Office,32Space.mkv.log
+[2021-12-06 22:22:25.725374] (Annex.Branch) read b86/aa5/WORM-s2144329193-m1636914388--Pirates,32of,32the,32Caribbean,-e8703135133e2788f38446549a5159ef.log
+[2021-12-06 22:22:25.725957] (Annex.Branch) read efa/8d7/WORM-s1185325919-m1518868254--Postman,,,32The,32,401997,41.mp4.log
+[2021-12-06 22:22:25.72656] (Annex.Branch) read 87d/859/WORM-s2059690008-m1585382324--Prestige,,,32The,32,402006,41,321080p.mkv.log
+[2021-12-06 22:22:25.726965] (Annex.Branch) read 41e/61a/GIT--9ec57d0596ccb70cfd6255cb85d89d00fce5a43a.log
+export film-depot README.md ok
+[2021-12-06 22:22:25.727519] (Annex.Branch) read 68f/38d/WORM-s948100504-m1574090603--Regarding,32Henry,32,401991,41,32720p.mp4.log
+[2021-12-06 22:22:25.727919] (Annex.Branch) read 817/23b/WORM-s878672153-m1574033361--Risky,32Business,32,401983,41,32720p.mp4.log
+[2021-12-06 22:22:25.72833] (Annex.Branch) read 1da/bbf/WORM-s1231862861-m1518370935--Rock,,,32The.mkv.log
+[2021-12-06 22:22:25.728893] (Annex.Branch) read f32/87e/WORM-s1816321857-m1598221210--Rocketeer,,,32The,32,401991,41,321080p.mp4.log
+[2021-12-06 22:22:25.729545] (Annex.Branch) read f5c/cbf/WORM-s2787891812-m1630883712--Rogue,32One,32A,32Star,32Wars,32Story,32,402016,41,321080p.mkv.log
+[2021-12-06 22:22:25.730174] (Annex.Branch) read dc3/69b/WORM-s1544737178-m1524572776--Serenity,32,402005,41,32720p.mp4.log
+[2021-12-06 22:22:25.730906] (Annex.Branch) read 831/8c8/WORM-s2384387600-m1598221224--Shawshank,32Redemption,,,32The,32,401994,41,321080p.mp4.log
+[2021-12-06 22:22:25.731345] (Annex.Branch) read e8f/5db/WORM-s1979737445-m1584227786--Sneakers,32,401992,41,321080p.mp4.log
+[2021-12-06 22:22:25.732205] (Annex.Branch) read 234/d7a/WORM-s3665537220-m1634232478--Star,32Trek,32II,32The,32Wrath,32of,32Khan,32,401982,41,321080p.mkv.log
+[2021-12-06 22:22:25.733026] (Annex.Branch) read cc6/1f9/WORM-s1853412510-m1638068017--Star,32Trek,32III,32The,32Search,32for,32Spock,32,401984,41,321080p.mkv.log
+[2021-12-06 22:22:25.733609] (Annex.Branch) read 23e/96e/WORM-s2133269783-m1638593594--Star,32Trek,32IV,32The,32Voyage,32Home,32,401986,41,321080p.mkv.log
+[2021-12-06 22:22:25.734223] (Annex.Branch) read 95e/21c/WORM-s2313033711-m1638593604--Star,32Trek,32The,32Motion,32Picture,32,401979,41,321080p.mkv.log
+[2021-12-06 22:22:25.734777] (Annex.Branch) read 998/5e9/WORM-s1632505949-m1638593600--Star,32Trek,32V,32The,32Final,32Frontier,32,401989,41,321080p.mkv.log
+[2021-12-06 22:22:25.735323] (Annex.Branch) read 57c/f2d/WORM-s1725216326-m1638593601--Star,32Trek,32VI,32The,32Undiscovered,32Country,32,401991,41,321080p.mkv.log
+[2021-12-06 22:22:25.735905] (Annex.Branch) read 786/e15/WORM-s2297779450-m1603679910--Stargate,32,401994,41,32720p.mkv.log
+[2021-12-06 22:22:25.73647] (Annex.Branch) read 393/ea3/WORM-s2168164654-m1601834448--Starship,32Troopers,32,401997,41,321080p.mp4.log
+[2021-12-06 22:22:25.736868] (Annex.Branch) read 532/60a/WORM-s2312036493-m1582511386--Terminator,322,,,32Judgment,32Day,32,401991,41,321080p.mkv.log
+[2021-12-06 22:22:25.737335] (Annex.Branch) read d47/eb9/WORM-s1824450643-m1601834456--Terminator,323,,,32Rise,32of,32-84776e11fa5dc1fb1fecfe410230caa5.log
+[2021-12-06 22:22:25.737736] (Annex.Branch) read c74/c2a/WORM-s1499960820-m1636255738--Terminator,32Genisys,32,402015,41,321080p.mp4.log
+[2021-12-06 22:22:25.738318] (Annex.Branch) read 31c/59e/WORM-s1426550835-m1599521599--Terminator,,,32The,32,401984,41,321080p.mkv.log
+[2021-12-06 22:22:25.738713] (Annex.Branch) read d81/d11/WORM-s2506262160-m1637273233--The,32Matrix,32,401999,41,321080p.mp4.log
+[2021-12-06 22:22:25.739251] (Annex.Branch) read 531/658/WORM-s1203158836-m1518370785--Mummy,,,32The.mkv.log
+[2021-12-06 22:22:25.73977] (Annex.Branch) read 0b3/5e4/WORM-s1945784875-m1518370865--Patriot,,,32The.mkv.log
+[2021-12-06 22:22:25.740366] (Annex.Branch) read 0f3/e1c/WORM-s1938608286-m1599511452--Three,32Kings,32,401999,41,321080p.mp4.log
+[2021-12-06 22:22:25.74077] (Annex.Branch) read f38/7ec/WORM-s1463832198-m1518371391--Three,32Musketeers,,,32The,32,401993,41.avi.log
+[2021-12-06 22:22:25.741289] (Annex.Branch) read b7b/e4c/WORM-s2041175346-m1601834465--Training,32Day,32,402001,41,321080p.mp4.log
+[2021-12-06 22:22:25.741684] (Annex.Branch) read 289/8d3/WORM-s2094454430-m1601834475--Tron,32Legacy,32,402010,41,321080p.mp4.log
+[2021-12-06 22:22:25.742067] (Annex.Branch) read 960/971/WORM-s5853485850-m1638199114--Underworld,32,402003,41,321080p.mkv.log
+[2021-12-06 22:22:25.742606] (Annex.Branch) read af1/ce9/WORM-s1720391416-m1586034793--Untouchables,,,32The,32,401987,41,321080p.mkv.log
+[2021-12-06 22:22:25.743017] (Annex.Branch) read 239/3b9/WORM-s1827306623-m1563582252--Valkyrie,32,402008,41,321080p.mp4.log
+[2021-12-06 22:22:25.743606] (Annex.Branch) read 148/196/WORM-s1836438038-m1584843373--WarGames,32,401983,41,321080p.mp4.log
+[2021-12-06 22:22:25.743988] (Annex.Branch) read a18/b70/WORM-s1481063951-m1518371518--Watchmen,,,32The.mkv.log
+[2021-12-06 22:22:25.744522] (Annex.Branch) read 01c/42b/WORM-s2648951821-m1584890677--Where,32Eagles,32Dare,32,401968,41,321080p.mp4.log
+[2021-12-06 22:22:25.744909] (Annex.Branch) read 531/f42/WORM-s2173033800-m1584848357--Willow,32,401988,41,321080p.mp4.log
+[2021-12-06 22:22:25.745316] (Annex.Branch) read e2b/244/WORM-s1151346022-m1574909969--Witness,32,401985,41,32720p.mkv.log
+[2021-12-06 22:22:25.745758] (Annex.Branch) read 044/bea/WORM-s1077510790-m1476055956--X-Men,,,32Apocalypse,32,402016,41.mkv.log
+[2021-12-06 22:22:25.7463] (Annex.Branch) read 04d/db6/WORM-s1618758250-m1520576862--X-Men,,,32Days,32Of,32Future,32Past,32,402014,41.mkv.log
+[2021-12-06 22:22:25.746896] (Annex.Branch) read 1e7/136/WORM-s1656445231-m1530398504--X-Men,,,32Last,32Stand,,,32The,32,402006,41,32720p.mkv.log
+[2021-12-06 22:22:25.74734] (Utility.Process) process [72356] done ExitSuccess
+[2021-12-06 22:22:25.74821] (Utility.Process) process [72359] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/remotes/film-depot/master"]
+[2021-12-06 22:22:25.75349] (Utility.Process) process [72359] done ExitSuccess
+[2021-12-06 22:22:25.754349] (Utility.Process) process [72360] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/remotes/film-depot/master","--full-history","--no-abbrev","--format=%T %H %P"]
+[2021-12-06 22:22:25.758299] (Utility.Process) process [72360] done ExitFailure (-13)
+[2021-12-06 22:22:25.759069] (Utility.Process) process [72361] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-ref","refs/remotes/film-depot/master","9d18fec41a08dbcd0377a792d987be7c158fedbc"]
+[2021-12-06 22:22:25.762365] (Utility.Process) process [72361] done ExitSuccess
+[2021-12-06 22:22:25.769741] (Utility.Process) process [72362] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","hash-object","-w","--stdin-paths","--no-filters"]
+[2021-12-06 22:22:25.770564] (Utility.Process) process [72363] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index-info"]
+[2021-12-06 22:22:25.777266] (Utility.Process) process [72363] done ExitSuccess
+[2021-12-06 22:22:25.778167] (Utility.Process) process [72364] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-12-06 22:22:25.783594] (Utility.Process) process [72364] done ExitSuccess
+(recording state in git...)
+[2021-12-06 22:22:25.78468] (Utility.Process) process [72365] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","write-tree"]
+[2021-12-06 22:22:25.791959] (Utility.Process) process [72365] done ExitSuccess
+[2021-12-06 22:22:25.792898] (Utility.Process) process [72366] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","commit-tree","e5e18bf030c0e281b800e7b033c6132564bfff31","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2021-12-06 22:22:25.798507] (Utility.Process) process [72366] done ExitSuccess
+[2021-12-06 22:22:25.79938] (Utility.Process) process [72367] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-ref","refs/heads/git-annex","429f678d58abe674707f99a1d45d586c125fb3cd"]
+[2021-12-06 22:22:25.804332] (Utility.Process) process [72367] done ExitSuccess
+[2021-12-06 22:22:25.805644] (Utility.Process) process [72357] done ExitSuccess
+[2021-12-06 22:22:25.805969] (Utility.Process) process [72358] done ExitSuccess
+[2021-12-06 22:22:25.806327] (Utility.Process) process [72341] done ExitSuccess
+[2021-12-06 22:22:25.80658] (Utility.Process) process [72342] done ExitSuccess
+[2021-12-06 22:22:25.807287] (Utility.Process) process [72362] done ExitSuccess
+```
+
+```
+git annex find . --in here | wc -l
+      99
+```
+
+This seems to work, but is not what I've done in the past.
+
+```
+gcp -v -r -L *.mkv *.avi *.mp4 /Volumes/WDCGREEN/films
+```
+
+I don't understand why this no longer works.
+
+```
+[remote "film-depot"]
+	annex-directory = /Volumes/WDCGREEN/films
+	annex-uuid = 59db1192-02ff-440a-86d4-xxxx
+	annex-ignore = false
+	skipFetchAll = true
+```
+
+```
+git annex info
+trusted repositories: 0
+semitrusted repositories: 7
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	06c02460-42ec-4834-8f07-xxx -- [mini]
+ 	45e3416d-d142-4aee-b041-xxx -- [quorra]
+ 	5922636d-02d1-4c4c-aae7-xxx -- MBP
+ 	59db1192-02ff-440a-86d4-xxx -- [film-depot]
+ 	b6234538-c1ba-4f90-bbbf-xxx -- WD-1TB-USB [here]
+```
+
+
+```
+git-annex version: 8.20210803
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.5 http-client-0.7.8 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+```
diff --git a/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_1_70a68381641ea3369cd19e2864de753c._comment b/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_1_70a68381641ea3369cd19e2864de753c._comment
new file mode 100644
index 0000000000..7fe99b479c
--- /dev/null
+++ b/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_1_70a68381641ea3369cd19e2864de753c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-12-07T17:01:34Z"
+ content="""
+If you have already exported a file to a special remote, doing an export
+again will skip that same file and not display anything[1]. So without you
+showing me anything else, it looks like that is what the situation is, and
+nothing is wrong. If you think something is wrong, you'll need to explain
+in more detail what it is.
+
+----
+
+[1] Except sometimes for file that are checked into git and not git-annex, 
+which explains why only .gitignore and README and such are displated.
+"""]]
diff --git a/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_2_57ce71a398b0e2c947164e97ba8d0e2d._comment b/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_2_57ce71a398b0e2c947164e97ba8d0e2d._comment
new file mode 100644
index 0000000000..443b20ab4d
--- /dev/null
+++ b/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_2_57ce71a398b0e2c947164e97ba8d0e2d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="jasonb@ab4484d9961a46440958fa1a528e0fc435599057"
+ nickname="jasonb"
+ avatar="http://cdn.libravatar.org/avatar/c7330f4da122c671b935fc1d58bb02b1"
+ subject="comment 2"
+ date="2021-12-08T00:46:39Z"
+ content="""
+Oh, so in my haste to complete the task, I `rm -Rf *` the target directory, and when the files still didn't copy, and just ran `cp`. I don't know if I still have output to that effect, though. But I did have quite a few files with new names, so I was puzzled that those files were not copied because no files with those names or hashes had ever been exported to this annex remote.
+
+I don't know if there is some local database or log of what git annex thinks is on a special remote that I can paste to demonstrate the discrepancy?
+
+Thanks.
+"""]]
diff --git a/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_3_b7dcb0a5e69e620278d1aa4d6f5829cd._comment b/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_3_b7dcb0a5e69e620278d1aa4d6f5829cd._comment
new file mode 100644
index 0000000000..268ee3fa25
--- /dev/null
+++ b/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_3_b7dcb0a5e69e620278d1aa4d6f5829cd._comment
@@ -0,0 +1,79 @@
+[[!comment format=mdwn
+ username="jasonb@ab4484d9961a46440958fa1a528e0fc435599057"
+ nickname="jasonb"
+ avatar="http://cdn.libravatar.org/avatar/c7330f4da122c671b935fc1d58bb02b1"
+ subject="comment 3"
+ date="2021-12-08T16:25:31Z"
+ content="""
+```
+git annex sync --no-content --no-push --no-pull
+commit
+On branch master
+nothing to commit, working tree clean
+ok
+
+git log -n3
+commit 9d18fec41a08dbcd0377a792d987be7c158fedbc (HEAD -> master, film-depot/master, MBP/synced/master, MBP/master, synced/master)
+```
+
+Originally, it seemed to work and exported the files that I expected; What confused me is there were not in the directory on the export target.
+
+```
+git annex export master --to film-depot
+export film-depot .gitattributes ok
+export film-depot .gitignore ok
+export film-depot 00-GIT-ANNEX ok
+export film-depot American Pie 2 (2001) 720p.mp4 ok
+export film-depot Armageddon (1998) 1080p.mp4 (not available) failed
+export film-depot Avengers, Age of Ultron (2015) 1080p.mp4 ok
+export film-depot Beverly Hills Cop 2 (1987) 1080p.mp4 (not available) failed
+export film-depot Beverly Hills Cop III (1994) 1080p.mp4 (not available) failed
+export film-depot Final Fantasy The Spirits Within (2001) 1080p.mkv (not available) failed
+export film-depot Groundhog Day (1993) 1080p.mp4 (not available) failed
+export film-depot In the Heat of the Night (1967) 720p.mkv ok
+export film-depot Indiana Jones and the Raiders of the Lost Ark (1981) 1080p.mp4
+ok
+export film-depot Inglourious Basterds (2009) 1080p.mkv
+ok
+export film-depot Interstellar (2014) 1080p.mp4 (not available) failed
+export film-depot King Arthur (2004).mkv ok
+export film-depot Last of the Mohicans, The (1992).mkv ok
+export film-depot Lethal Weapon 2 (1989) 720p.mkv
+ok
+export film-depot Pirates of the Caribbean Curse of the Black Pearl (2003) 1080p.mp4
+ok
+export film-depot README.md ok
+export film-depot Rock, The (1996).mkv ok
+export film-depot Rogue One A Star Wars Story (2016) 1080p.mkv
+ok
+export film-depot Star Trek II The Wrath of Khan (1982) 1080p.mkv
+ok
+export film-depot Star Trek III The Search for Spock (1984) 1080p.mkv
+ok
+export film-depot Star Trek IV The Voyage Home (1986) 1080p.mkv
+ok
+export film-depot Star Trek The Motion Picture (1979) 1080p.mkv
+ok
+export film-depot Star Trek V The Final Frontier (1989) 1080p.mkv
+ok
+export film-depot Star Trek VI The Undiscovered Country (1991) 1080p.mkv
+ok
+export film-depot Terminator Genisys (2015) 1080p.mp4 (not available) failed
+export film-depot The Matrix (1999) 1080p.mp4
+ok
+export film-depot The Mummy (1999).mkv ok
+export film-depot The Patriot (2000).mkv ok
+export film-depot Underworld (2003) 1080p.mkv
+ok
+(recording state in git...)
+export: 7 failed
+```
+
+So I went and recovered those files from another annex that had them, and re-ran the export. No errors.
+
+But also, it didn't export the files that it couldn't find; It's like after the first failed attempt, that was it. Even with the files present, it did not export them.
+
+So that's what led to the `rm -Rf` and finally the `cp`.
+
+Maybe I can reset it all by reinitializing the export remote somehow?
+"""]]
diff --git a/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_4_a5822d922a107e2a0e8972b7f55d92cc._comment b/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_4_a5822d922a107e2a0e8972b7f55d92cc._comment
new file mode 100644
index 0000000000..8b1b3a1b90
--- /dev/null
+++ b/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_4_a5822d922a107e2a0e8972b7f55d92cc._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-12-08T16:42:47Z"
+ content="""
+Your use of `git-annex sync --no-content` doesn't make much sense,
+of course that will not cause it to export any content because you told it
+not to. Also there is configuration needed for git-annex sync to export
+a branch to a remote and you have not shown that you performed such
+configuration, and the output of the command seems to indicate you have
+not.
+
+Your `git annex export master --to film-depot` seems to have behaved
+correctly, since the content of some files were not present it was not able
+to export those. Running `git annex get` and then re-running that command
+will make update the export with the missing files. I have tested that.
+"""]]
diff --git a/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_5_edbc4191d6444dfe50f4c1d7bbab572d._comment b/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_5_edbc4191d6444dfe50f4c1d7bbab572d._comment
new file mode 100644
index 0000000000..1eede925a1
--- /dev/null
+++ b/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_5_edbc4191d6444dfe50f4c1d7bbab572d._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="jasonb@ab4484d9961a46440958fa1a528e0fc435599057"
+ nickname="jasonb"
+ avatar="http://cdn.libravatar.org/avatar/c7330f4da122c671b935fc1d58bb02b1"
+ subject="comment 5"
+ date="2021-12-09T16:20:48Z"
+ content="""
+Yes, once I saw those errors, I went back and did a `get annex copy --from <remote>` and recovered them. But what happened after that it seems I can't provide evidence of is running `git annex export ...` did not export the recovered files. It puzzlingly showed output that it was copying the files.
+
+(The `git annex sync --no-content` was because I've gotten used to running that for other repos where not doing that will copy files into a repo where I intentionally need them dropped. In this case, the goal was just to make sure the git branches properly reflected any file adds, deletes, and renames.)
+
+But on the target device, there was no evidence that the files were there. I ran an `ls` and they weren't present. I can't fathom why. But further attempts to export the files were unsuccessful. It seems you can't re-export files that already were copied. But they were nonetheless absent. I suppose this sounds fantastical, and somehow it is probably user error.
+
+And this is the remote definition.
+
+```
+[remote \"film-depot\"]
+	annex-directory = /Volumes/WDCGREEN/films
+	annex-uuid = 59db1192-02ff-440a-86d4-xxxx
+	skipFetchAll = true
+	annex-ignore = false
+```
+
+In any case, I'd successfully done exports here in the past, and had the files appear at the destination. So I'm doing something wrong, somehow.
+
+Can I just \"reset\" the export remote and start over again fresh?
+
+Thanks.
+"""]]
diff --git a/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_6_b5072042bda56ad5a781aab8419ede74._comment b/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_6_b5072042bda56ad5a781aab8419ede74._comment
new file mode 100644
index 0000000000..aade494365
--- /dev/null
+++ b/doc/forum/So_this_is_embarrassing__59___git_export_not_working/comment_6_b5072042bda56ad5a781aab8419ede74._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-12-09T17:55:31Z"
+ content="""
+You can run `git annex fsck --from film-depot` and it will notice any files
+that are somehow missing, and re-running the export will then upload those
+missing files again.
+
+I do not see any way that it could say it was exporting files to the remote
+and then the files did not get stored there, but it reported success. It
+seems most likely that you somehow deleted those files after the fact.
+"""]]
diff --git a/doc/forum/Some_files_missing_extension_in_annex.mdwn b/doc/forum/Some_files_missing_extension_in_annex.mdwn
new file mode 100644
index 0000000000..bae149b3c1
--- /dev/null
+++ b/doc/forum/Some_files_missing_extension_in_annex.mdwn
@@ -0,0 +1,11 @@
+I hadn't noticed this before, but I added some files in the past and, finally looking at them today, the file extension is missing in the annex. This confuses OS X something awful, so it opens the file in TextEdit instead of VLC. If I open the file directly using VLC, it works.
+
+I just dropped and re-added the file that has an extension. It lacked it before:
+
+    ls -l 10*
+    lrwxr-xr-x  1 jasonb  staff  215 Sep 16 15:23 10 Minute Ab Chisel.mkv -> ../.git/annex/objects/zw/mG/WORM-s103155193-m1516830000--Masters,32Hammer,32and,32Chisel-a67ed6d2a3dfd5fe29be62146fbd0c04/WORM-s103155193-m1516830000--Masters,32Hammer,32and,32Chisel-a67ed6d2a3dfd5fe29be62146fbd0c04
+    lrwxr-xr-x  1 jasonb  staff  209 Sep 16 15:04 10 Minute Ab Hammer.mkv -> ../.git/annex/objects/jx/5p/WORM-s117692368-m1537124682--Masters,32Hammer,32and,32Chisel%10,32Minute,32Ab,32Hammer.mkv/WORM-s117692368-m1537124682--Masters,32Hammer,32and,32Chisel%10,32Minute,32Ab,32Hammer.mkv
+
+Is there something I can do to recover my file extensions besides manually dropping and re-adding each file?
+
+Thanks.
diff --git a/doc/forum/Some_files_missing_extension_in_annex/comment_1_12ab578a4390c0f5896106906997de4b._comment b/doc/forum/Some_files_missing_extension_in_annex/comment_1_12ab578a4390c0f5896106906997de4b._comment
new file mode 100644
index 0000000000..09f12fbccd
--- /dev/null
+++ b/doc/forum/Some_files_missing_extension_in_annex/comment_1_12ab578a4390c0f5896106906997de4b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jasonb@ab4484d9961a46440958fa1a528e0fc435599057"
+ nickname="jasonb"
+ avatar="http://cdn.libravatar.org/avatar/c7330f4da122c671b935fc1d58bb02b1"
+ subject="comment 1"
+ date="2018-09-16T20:25:39Z"
+ content="""
+Doing a git annex unannex and then a git annex add fixes it. Now sure how this happened originally.
+"""]]
diff --git a/doc/forum/Some_files_missing_extension_in_annex/comment_2_7fa25274fb00ba823b112d587c52df76._comment b/doc/forum/Some_files_missing_extension_in_annex/comment_2_7fa25274fb00ba823b112d587c52df76._comment
new file mode 100644
index 0000000000..4c5f186563
--- /dev/null
+++ b/doc/forum/Some_files_missing_extension_in_annex/comment_2_7fa25274fb00ba823b112d587c52df76._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jasonb@ab4484d9961a46440958fa1a528e0fc435599057"
+ nickname="jasonb"
+ avatar="http://cdn.libravatar.org/avatar/c7330f4da122c671b935fc1d58bb02b1"
+ subject="comment 2"
+ date="2018-09-16T20:32:08Z"
+ content="""
+Unfortunately, my remotes don't know anything about the change, so when I push it, the symlinks point to files that don't exist, even though the data is still in the annex with the original mysterious filenames.
+
+How to get git-annex to recover the existing data?
+"""]]
diff --git a/doc/forum/Some_files_missing_extension_in_annex/comment_3_b05b478e91f58bd4ccd6d8ccf3b7ddf1._comment b/doc/forum/Some_files_missing_extension_in_annex/comment_3_b05b478e91f58bd4ccd6d8ccf3b7ddf1._comment
new file mode 100644
index 0000000000..6fcd56ce6e
--- /dev/null
+++ b/doc/forum/Some_files_missing_extension_in_annex/comment_3_b05b478e91f58bd4ccd6d8ccf3b7ddf1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-10-04T18:27:26Z"
+ content="""
+You used the WORM backend which is not the default backend, and which does
+not preserve the extension inside the symlink target in all cases.
+
+You'll need to re-upload the data to the remotes since you've added it back
+under a different key. It would also be possible to use `git annex
+reinject` on the remote, pointing it at the old content's filename.
+"""]]
diff --git a/doc/forum/Some_mounted_devices_not_detected.mdwn b/doc/forum/Some_mounted_devices_not_detected.mdwn
new file mode 100644
index 0000000000..6146ef14fb
--- /dev/null
+++ b/doc/forum/Some_mounted_devices_not_detected.mdwn
@@ -0,0 +1,3 @@
+Automounted USB devices are not detected by the git-annex webapp on my Debian testing/squeeze installation, only drives with entries in /etc/fstab show up in the device list. Is there any way to tweak/get around this?
+
+I'm running version 4.20131106 (couldn't manage to build the package for sid). 
diff --git a/doc/forum/Some_mounted_devices_not_detected/comment_1_0ba07b95f12f57ea63bb450b88430c45._comment b/doc/forum/Some_mounted_devices_not_detected/comment_1_0ba07b95f12f57ea63bb450b88430c45._comment
new file mode 100644
index 0000000000..5cd472c8e6
--- /dev/null
+++ b/doc/forum/Some_mounted_devices_not_detected/comment_1_0ba07b95f12f57ea63bb450b88430c45._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 1"
+ date="2013-11-24T16:04:23Z"
+ content="""
+can you post an example line from /proc/mounts for one of these devices?
+"""]]
diff --git a/doc/forum/Some_mounted_devices_not_detected/comment_2_4f8c7bcd0f20dafa5635a3580ec8d1f6._comment b/doc/forum/Some_mounted_devices_not_detected/comment_2_4f8c7bcd0f20dafa5635a3580ec8d1f6._comment
new file mode 100644
index 0000000000..60512d418b
--- /dev/null
+++ b/doc/forum/Some_mounted_devices_not_detected/comment_2_4f8c7bcd0f20dafa5635a3580ec8d1f6._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmyEv6SesaYeke389mHdiHlavirPkGHzHI"
+ nickname="Albin"
+ subject="comment 2"
+ date="2013-11-26T14:35:58Z"
+ content="""
+I missed your reply on IRC. Sorry for that!
+
+Here's an example from /proc/mounts:
+
+   /dev/sdf1 /media/SoderUSB ext4 rw,nosuid,nodev,noexec,relatime,errors=remount-ro,data=ordered 0 0
+
+"""]]
diff --git a/doc/forum/Some_mounted_devices_not_detected/comment_3_06c0db7d670d9b82823102d22db15a36._comment b/doc/forum/Some_mounted_devices_not_detected/comment_3_06c0db7d670d9b82823102d22db15a36._comment
new file mode 100644
index 0000000000..53c76e210b
--- /dev/null
+++ b/doc/forum/Some_mounted_devices_not_detected/comment_3_06c0db7d670d9b82823102d22db15a36._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 3"
+ date="2013-11-26T19:59:42Z"
+ content="""
+Hmm, that looks fine.
+
+Perhaps the user you're running git-annex as cannot write to `/media/SoderUSB` ? The webapp avoids listing places you can't write, since it would fail to make a repository there. (Also because this is an easy way for it to avoid listing `/`, `/usr`, or whatever other OS-level mounts a system might have..)
+"""]]
diff --git a/doc/forum/Some_mounted_devices_not_detected/comment_4_80820a29361c5be4a94672dacfdefa6f._comment b/doc/forum/Some_mounted_devices_not_detected/comment_4_80820a29361c5be4a94672dacfdefa6f._comment
new file mode 100644
index 0000000000..03b917a69a
--- /dev/null
+++ b/doc/forum/Some_mounted_devices_not_detected/comment_4_80820a29361c5be4a94672dacfdefa6f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmyEv6SesaYeke389mHdiHlavirPkGHzHI"
+ nickname="Albin"
+ subject="comment 4"
+ date="2013-11-27T17:33:22Z"
+ content="""
+Actually, that (write permissions) seems to have been the problem. Thanks! Can't imagine why pmount would not mount a device writable by my user, though.
+"""]]
diff --git a/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff.mdwn b/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff.mdwn
new file mode 100644
index 0000000000..3d93d80269
--- /dev/null
+++ b/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff.mdwn
@@ -0,0 +1,22 @@
+I'm using git-annex to manage my photos on my laptop, and have my NAS (which is just a debian linux system with lots of disks) as one of my remotes. I use my NAS as a backup, and to free up space on my laptop.
+
+But somehow I now have lots of directories in my main root directory of the photos directory. it looks like [0-9a-f][0-9a-f][0-9a-f], so I have 000, ... a00, ... ddd, ..., all the way to fff. Thousands of them. Each one has a few directories that also match [0-9a-f][0-9a-f][0-9a-f], and each one has a file with names of the git annex object filename.
+
+e.g.:
+
+    $ cat e1d/760/SHA256-s4061375--7909e266f340ff8bc692e073e776ceda267042adf790275a2d851f2c7eb1ca83.log 
+    1338931894.759394s 1 1adfa84c-af51-11e1-b075-0b1206d553bc
+    1338992164.202818s 1 721d82ae-afbb-11e1-b78f-f396ebf52c05
+    1339862991.346546s 1 721d82ae-afbb-11e1-b78f-f396ebf52c05
+    1339946933.224915s 1 224d85b4-b86f-11e1-b11e-3333ce526126
+    1339964057.205993s 1 224d85b4-b86f-11e1-b11e-3333ce526126
+    1343495865.083951s 1 721d82ae-afbb-11e1-b78f-f396ebf52c05
+    1344788941.403528s 1 721d82ae-afbb-11e1-b78f-f396ebf52c05
+    1351802706.679542s 1 721d82ae-afbb-11e1-b78f-f396ebf52c05
+    1362423729.820711s 1 721d82ae-afbb-11e1-b78f-f396ebf52c05
+
+My remote (NAS) has these files & directories as well as my laptop. The regular photo directory hierarchy is there as well, the files work, can be copied etc. "git status" say nothing has changed. Those files are tracked by git (they have lot messages). Everything just works, it's just that there's loads of these directories? Can I remove them? How can I clear it up? I can't remember when these directories/files were added, I only noticed it today.
+
+I don't know if I had my remote (NAS) as a bare git repo and used it as that, then somehow used it as a non-bare one, would that cause this?
+
+Can I remove them? Where did they come from? What's going on?
diff --git a/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_1_20147b287fd995fa8ac9e868b5974d8a._comment b/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_1_20147b287fd995fa8ac9e868b5974d8a._comment
new file mode 100644
index 0000000000..1f5018e34a
--- /dev/null
+++ b/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_1_20147b287fd995fa8ac9e868b5974d8a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-10T19:50:38Z"
+ content="""
+The files that you describe are normally tucked away on the git-annex branch of the git repository, where they're neither seen nor heard.
+
+The most likely cause of your problem would be if you have done a \"git checkout git-annex\"  ... or worse, a \"git merge git-annex\".
+
+So, check what branch you have checked out, and if it's the git-annex branch, you'll want to change back to master. If you've got master checked out and have these files, you can use `git log --stat` and see if there's a commit that added a bunch of these files to your master branch. Then you can revert that commit.
+"""]]
diff --git a/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_2_f6d977a534264b4368401e1b13628931._comment b/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_2_f6d977a534264b4368401e1b13628931._comment
new file mode 100644
index 0000000000..e902380633
--- /dev/null
+++ b/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_2_f6d977a534264b4368401e1b13628931._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~rorymcc"
+ nickname="rorymcc"
+ subject="comment 2"
+ date="2014-08-11T18:37:46Z"
+ content="""
+Thanks for your reply. I think I might have done a \"git merge git-annex\" at some point (or many times), because I thought that was what you were supposed to do... :( PEBKAC I'll try to fix up my repository. Thanks.
+"""]]
diff --git a/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_3_d534da276b79a40fdb7d8d158f6eae26._comment b/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_3_d534da276b79a40fdb7d8d158f6eae26._comment
new file mode 100644
index 0000000000..214444c61a
--- /dev/null
+++ b/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_3_d534da276b79a40fdb7d8d158f6eae26._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~rorymcc"
+ nickname="rorymcc"
+ subject="comment 3"
+ date="2014-08-11T18:41:05Z"
+ content="""
+Would just standard \"git rm ./000/\" etc. in master be OK? Instead of hunting down and reverting all the commits? 
+"""]]
diff --git a/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment b/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment
new file mode 100644
index 0000000000..74a3a2a756
--- /dev/null
+++ b/doc/forum/Somehow_have_lots_of_directories_in_root__58___000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 4"
+ date="2014-08-12T17:50:15Z"
+ content="""
+Sure, it's fine to delete the files. The same info will be committed to git either way.
+"""]]
diff --git a/doc/forum/Special_remote_public_key_encryption_issue.mdwn b/doc/forum/Special_remote_public_key_encryption_issue.mdwn
new file mode 100644
index 0000000000..aed35ad31b
--- /dev/null
+++ b/doc/forum/Special_remote_public_key_encryption_issue.mdwn
@@ -0,0 +1,18 @@
+I'm unable to set up a standard architecture: 2 computers sharing some files, talking via a jabber account and transferring files via e.g. box.com.
+Steps:
+
+Computer 1: 
+a) Install git-annex, open up the assistant, create a new repository, add a jabber account
+b) Add a box.com account using
+WEBDAV_USERNAME=[username] WEBDAV_PASSWORD=[password] git annex initremote box.com type=webdav url=https://dav.box.com/dav/git-annex chunksize=75mb encryption=pubkey keyid=[key id].
+All seemed fine.
+
+Computer 2:
+a) same
+b) at this point I saw the option of adding box.com as a cloud storage. I clicked enable and got the message
+
+user error (gpg ["--quiet","--trust-model","always","--decrypt"] exited 2)
+
+In the meantime, on Computer 1 I saw the same option. I clicked enable and got the same message.
+
+It all works fine if I use shared encryption.
diff --git a/doc/forum/Special_remote_public_key_encryption_issue/comment_1_a9caafea017a3c148f89d4ddeee15a4c._comment b/doc/forum/Special_remote_public_key_encryption_issue/comment_1_a9caafea017a3c148f89d4ddeee15a4c._comment
new file mode 100644
index 0000000000..6c5a35c3a3
--- /dev/null
+++ b/doc/forum/Special_remote_public_key_encryption_issue/comment_1_a9caafea017a3c148f89d4ddeee15a4c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-05-16T18:22:26Z"
+ content="""
+Which is why the assistant uses shared encryption by default..
+
+You have set up a webdav repository using a gpg key that is on computer 1. To be able to access this repository on computer 2 you'll need to either copy the gpg private key from computer 1, or give computer 2 its own key and, on computer 1, add that key as one that can access the webdav repository.
+"""]]
diff --git a/doc/forum/Special_remote_public_key_encryption_issue/comment_2_adfa582d611ca501e21110282df07315._comment b/doc/forum/Special_remote_public_key_encryption_issue/comment_2_adfa582d611ca501e21110282df07315._comment
new file mode 100644
index 0000000000..8e27535307
--- /dev/null
+++ b/doc/forum/Special_remote_public_key_encryption_issue/comment_2_adfa582d611ca501e21110282df07315._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="hyperio"
+ ip="62.31.92.216"
+ subject="Still not working"
+ date="2014-05-17T12:22:17Z"
+ content="""
+Thank you for your reply. I copied over the public key from computer 2 to computer 1 and tried to add it using git annex enableremote box.com keyid+=[keyid]. I am then asked for the passphrase for my private key on computer 1. Afterwards I am asked for the passphrase for the private key on computer 2... why? Obviously I don't have it so I get 
+
+gpg: can't query passphrase in batch mode
+gpg: decryption failed: secret key not available
+
+git-annex: user error (gpg [\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--decrypt\"] exited 2)
+
+Why would I need computer 2's secret key? Or I might just get it completely wrong.
+Also, can the passphrase be remembered somewhere, so that I can use the assistant? (otherwise I think it won't work, because I would have to type the passphrase at every synchronisation attempt).
+
+Sorry for my confusion, thanks for your support.
+"""]]
diff --git a/doc/forum/Special_remote_public_key_encryption_issue/comment_3_eac16bf98a6e87461ba2f3ab7e990b2b._comment b/doc/forum/Special_remote_public_key_encryption_issue/comment_3_eac16bf98a6e87461ba2f3ab7e990b2b._comment
new file mode 100644
index 0000000000..692b307b10
--- /dev/null
+++ b/doc/forum/Special_remote_public_key_encryption_issue/comment_3_eac16bf98a6e87461ba2f3ab7e990b2b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="216.145.95.162"
+ subject="comment 3"
+ date="2014-05-17T17:02:15Z"
+ content="""
+I dont think it's possible for gpg to prompt for a passphrase when all it has is a public key, so I think you copied the private key too.
+
+gpg agents can cache your passphrase.
+"""]]
diff --git a/doc/forum/Special_remote_public_key_encryption_issue/comment_6_097f52aaf178340b3abb5bfc80f0d447._comment b/doc/forum/Special_remote_public_key_encryption_issue/comment_6_097f52aaf178340b3abb5bfc80f0d447._comment
new file mode 100644
index 0000000000..93fa8b5b9c
--- /dev/null
+++ b/doc/forum/Special_remote_public_key_encryption_issue/comment_6_097f52aaf178340b3abb5bfc80f0d447._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="hyperio"
+ ip="62.31.92.216"
+ subject="Still not working"
+ date="2014-05-17T17:25:39Z"
+ content="""
+I exported the public key on computer 2 with gpg --armor --export [keyid] and just imported it on computer 1...
+"""]]
diff --git a/doc/forum/Special_remote_without_chmod.mdwn b/doc/forum/Special_remote_without_chmod.mdwn
new file mode 100644
index 0000000000..46ace443b1
--- /dev/null
+++ b/doc/forum/Special_remote_without_chmod.mdwn
@@ -0,0 +1,12 @@
+Apparently, the tablet computer I'm using (Galaxy Tab 2, non-rooted) does not export the sd cards via mass storage protocol (UMS) any more. In order to be able to use a special remote for my mp3-files,  I installed an ftp/ssh server on the tablet device and used curlftpfs/sshfs (fuse file systems) to mount the sd cards on my local Linux machine. In this way, it is is quite easy to setup the special remote (e.g. "git-annex initremote galaxy-tab type=directory directory=$HOME/mnt/galaxy-tab encryption=none"). 
+
+Problems arise, when files are transferred to the special remote. From the logs of the ftp server, I can see that the actual copy operation is successful (the data is written to the file system), but the subsequent "chmod" that changes the permissions to read-only fails. The output on the console of a "git-annex copy -t galaxy-tab" is 
+
+    copy 01 some.mp3 (to galaxy-tab...) 
+    failed                  
+    git-annex: copy: 1 failed
+
+
+Therefore my question: is it possible to perform a file transfer to a special remote (type=directory) without the final "chmod"-operation?
+
+Thank you.
diff --git a/doc/forum/Special_remote_without_chmod/comment_1_4f5f9506cae72a1f321296fc5a5f339a._comment b/doc/forum/Special_remote_without_chmod/comment_1_4f5f9506cae72a1f321296fc5a5f339a._comment
new file mode 100644
index 0000000000..225cfa6cb5
--- /dev/null
+++ b/doc/forum/Special_remote_without_chmod/comment_1_4f5f9506cae72a1f321296fc5a5f339a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 1"
+ date="2012-11-25T22:00:12Z"
+ content="""
+That could be hacked into directory as a configuration setting, but I think it makes more sense to add a proper sftp special remote, and avoid the rather complex stack you're using.
+"""]]
diff --git a/doc/forum/Special_remotes_description_misleading.mdwn b/doc/forum/Special_remotes_description_misleading.mdwn
new file mode 100644
index 0000000000..1bd0db0595
--- /dev/null
+++ b/doc/forum/Special_remotes_description_misleading.mdwn
@@ -0,0 +1,17 @@
+Hello,
+
+IMHO the description of the special remotes at https://git-annex.branchable.com/special_remotes/ is misleading:
+
+> But, git-annex also extends git's concept of remotes, with these special types of remotes. These can be used just like any normal remote by git-annex. They cannot be used by other git commands though.
+
+AFAIK (and just tested it with a webdav remote), a special remote can not be used to transfer tracking information, only content. So that, in order to connect to repos that can not talk to each other, a special remote is not sufficient. You additionally need a ordinary git repo to transfer the tracking information.
+
+* Is that correct? Is there a way to use a special remote to transfer tracking information? (would love that!)
+
+The description above sounds for me, as I can simply use a special remote like a normal remote, which is not the case.
+
+Just a documentation improvement suggestions.
+
+Best Thanks,
+Florian
+
diff --git a/doc/forum/Special_remotes_description_misleading/comment_1_5226553dd5f529e3e4882ea18c3be600._comment b/doc/forum/Special_remotes_description_misleading/comment_1_5226553dd5f529e3e4882ea18c3be600._comment
new file mode 100644
index 0000000000..81a00008f9
--- /dev/null
+++ b/doc/forum/Special_remotes_description_misleading/comment_1_5226553dd5f529e3e4882ea18c3be600._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Horus"
+ avatar="http://cdn.libravatar.org/avatar/8f0ee08b98ea5bba76c3fe112c08851c"
+ subject="comment 1"
+ date="2019-03-04T08:59:21Z"
+ content="""
+Another small thing, at <https://git-annex.branchable.com/special_remotes/rsync/> I think `annex-rsync-transport` should be `annex.rsync-transport`. At least for me, it only worked that way.
+"""]]
diff --git a/doc/forum/Special_remotes_description_misleading/comment_2_616cc2f7d729682c69a9379df785dda5._comment b/doc/forum/Special_remotes_description_misleading/comment_2_616cc2f7d729682c69a9379df785dda5._comment
new file mode 100644
index 0000000000..70bb2bd6c0
--- /dev/null
+++ b/doc/forum/Special_remotes_description_misleading/comment_2_616cc2f7d729682c69a9379df785dda5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-03-22T13:58:06Z"
+ content="""
+Thanks, I see how that could be confusing and have adjusted the
+description.
+
+annex-rsync-transport will work, but you have to put it in the
+configuration of the remote you want it to apply to. annex.rsync-transport
+sets it for all rsync remotes.
+"""]]
diff --git a/doc/forum/Specifying_private_key_for_ssh_remote.mdwn b/doc/forum/Specifying_private_key_for_ssh_remote.mdwn
new file mode 100644
index 0000000000..512910984d
--- /dev/null
+++ b/doc/forum/Specifying_private_key_for_ssh_remote.mdwn
@@ -0,0 +1,7 @@
+As most of us know, the webapp/assistant already show option to specify the private key for ssh remote...except there the fact it has a little quirk:
+Basically it doesn't let you (at least on my end) specify folder starting with a dot (.ssh in this case) and i was obliged to move the private key out of it to be able to specify it.
+
+Now i would love to know if there a way to do this on the cli/command line too, since i only know how to do it on the webapp (for specifying the private key) as i think its only a viable quirk for the webapp and not the cli.
+
+EDIT: nvm, the assistant/webapp doesn't seem to have an option to specify the private key for the ssh remote either...
+
diff --git a/doc/forum/Specifying_private_key_for_ssh_remote/comment_1_94d38f788ab5bc34da9ba56c2fb729b5._comment b/doc/forum/Specifying_private_key_for_ssh_remote/comment_1_94d38f788ab5bc34da9ba56c2fb729b5._comment
new file mode 100644
index 0000000000..2df2ea4b3b
--- /dev/null
+++ b/doc/forum/Specifying_private_key_for_ssh_remote/comment_1_94d38f788ab5bc34da9ba56c2fb729b5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="hobbes@b2cacef69071743c3a831e60511062f7e014e52f"
+ nickname="hobbes"
+ avatar="http://cdn.libravatar.org/avatar/44b70169c4d862b3619812c360aa8f1e"
+ subject="Ssh config"
+ date="2019-11-03T23:49:05Z"
+ content="""
+I would look into `man ssh_config. You can set up hosts and specific identities for those hosts.
+"""]]
diff --git a/doc/forum/Speed_up_remote_transfers.mdwn b/doc/forum/Speed_up_remote_transfers.mdwn
new file mode 100644
index 0000000000..04ebdc8f9d
--- /dev/null
+++ b/doc/forum/Speed_up_remote_transfers.mdwn
@@ -0,0 +1,5 @@
+I am currently trying to transfer git-annex managed files to my server.
+
+I am getting them with `git annex /path`. However, these are very many small files, and git annex seems to take a tiny break in between them, so the process takes considerably longer than uploading a single file of the same size would.
+
+Do you have any suggestions for improving my transfer speed in this case?
diff --git a/doc/forum/Speed_up_remote_transfers/comment_1_bd97e1c47338322c5232cea7cdbc26fc._comment b/doc/forum/Speed_up_remote_transfers/comment_1_bd97e1c47338322c5232cea7cdbc26fc._comment
new file mode 100644
index 0000000000..f4e9194dd4
--- /dev/null
+++ b/doc/forum/Speed_up_remote_transfers/comment_1_bd97e1c47338322c5232cea7cdbc26fc._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2015-06-06T14:57:35Z"
+ content="""
+I did this using a couple of tools (off the top of my head):
+
+git annex find path/ --format '${key}\n' > /tmp/keyslist (outputs a list of keys)
+find .git/annex/objects -type f | grep -wFf /tmp/keyslist > /tmp/filelist (outputs a list of files)
+
+Then I use 'resync -avhP --files-from=/tmp/filelist . othermachine:some/tmp/dir' to transfer the files to the other machine.
+
+Then I 'git annex import some/tmp/dir' to inject the content, then just delete the additional symlinks (and reset the index).
+
+This speeds things up a bit. Even more speed can be had using tar/netcat.
+
+Hope this points you in the right direction.
+"""]]
diff --git a/doc/forum/Speed_up_remote_transfers/comment_2_723b3b69d47c947e5cbe8e94b84df022._comment b/doc/forum/Speed_up_remote_transfers/comment_2_723b3b69d47c947e5cbe8e94b84df022._comment
new file mode 100644
index 0000000000..bca1f6eccd
--- /dev/null
+++ b/doc/forum/Speed_up_remote_transfers/comment_2_723b3b69d47c947e5cbe8e94b84df022._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-06-09T19:45:26Z"
+ content="""
+I'd suggest running 2 or more concurrent transfers. Either by just running
+the same "git annex get" command multiple times, or by using "git annex get -J2"
+if you've got a new enough version of git-annex that has that feature.
+"""]]
diff --git a/doc/forum/Split_annex_into_multiple.mdwn b/doc/forum/Split_annex_into_multiple.mdwn
new file mode 100644
index 0000000000..2ebdf63d53
--- /dev/null
+++ b/doc/forum/Split_annex_into_multiple.mdwn
@@ -0,0 +1,16 @@
+Lets say I have an annex, called Global in some location A. The plan is to mirror it to some location B.
+
+I suddenly decide that Global has become too unwieldy, and I wish to split it up. 
+
+I "rsync -Lhav" the entire annex over to B, so it turns back into raw files (as I'm a little worried about the broken symlinks some have mentioned when using uninit).
+I then reorganize all the files in B into five new annexes. Yay.
+
+Now, I clone those five repos back onto A. How can I use the content of the original repo "Global" to populate the new annexes?
+
+**Approach 1**: delete Global, use git-annex copy (slow, wasteful use of precious disk life)
+
+**Approach 2**: uninit Global, deal with whatever broken symlink mess *may* occur, and then use reinject. Reinject doesn't seem to work recursively afaik (ok, I can use find -type f -exec I guess...), and doesn't seem to want to work on files that are sitting inside an annex already (i.e. the uninit is not optional)
+
+So besides these two, are there any approaches I'm overlooking?
+
+Context: entire photo collection. split into e.g. parents digitized photos, my photos, etc
diff --git a/doc/forum/Split_annex_into_multiple/comment_1_e934b404f738cbd67df928fd6769e3ff._comment b/doc/forum/Split_annex_into_multiple/comment_1_e934b404f738cbd67df928fd6769e3ff._comment
new file mode 100644
index 0000000000..84451b86a8
--- /dev/null
+++ b/doc/forum/Split_annex_into_multiple/comment_1_e934b404f738cbd67df928fd6769e3ff._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-05T19:09:03Z"
+ content="""
+Recent git-annex's support `git annex reinject --known`
+
+You can do this -- but do note that it leaves Global in an unusable state,
+so only do it if you don't plan to use that repository again:
+
+	chmod -R +w $Global/.git/annex/objects/
+	git annex reinject --known $(find $Global/.git/annex/objects/ -type f)
+
+BTW, splitting the files amoung several git branches is also a useful
+thing to do in this situation. Splitting amoung branches avoids most of
+git's problems with a repository having too many files in it.
+"""]]
diff --git a/doc/forum/Split_annex_into_multiple/comment_2_eec6bc8c49c08411a4bb2cf7cc1c4697._comment b/doc/forum/Split_annex_into_multiple/comment_2_eec6bc8c49c08411a4bb2cf7cc1c4697._comment
new file mode 100644
index 0000000000..1957eb2ac8
--- /dev/null
+++ b/doc/forum/Split_annex_into_multiple/comment_2_eec6bc8c49c08411a4bb2cf7cc1c4697._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="archimedes"
+ avatar="http://cdn.libravatar.org/avatar/5b2ed40aabedcb1b8c2c0ce69f55a1e1"
+ subject="comment 2"
+ date="2017-04-05T20:01:44Z"
+ content="""
+So actually \"import --reinject-duplicates\" solves the issue of reinject not being recursive.
+
+
+That trick on .git/annex/objects/ is cunning, but the destruction of Global before everything has been finished is discomforting...if only there was a \"--reinject-duplicates --duplicate\" option for import.
+
+No chance that I can make a recursive copy of .git/annex/objects with hardlinks can I? To then use with reinject-duplicates? 
+"""]]
diff --git a/doc/forum/Ssh_remote_on_NAS.mdwn b/doc/forum/Ssh_remote_on_NAS.mdwn
new file mode 100644
index 0000000000..27bca5a510
--- /dev/null
+++ b/doc/forum/Ssh_remote_on_NAS.mdwn
@@ -0,0 +1,34 @@
+Hello,
+
+I finally have git annex working on my NAS (QNAP TS-119P II) thanks to the stand-alone arm pre-build package.
+
+I've just extracted all the files on my NAS and I've linked all the exec files from the git-annex.linux folder to links placed in a path folder, so that I can run git annex everywhere on the NAS.
+
+    [~] # git annex version
+    git-annex version: 5.20140528-g92a0591
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+
+Now I'm trying to set it up as an SSH remote of my laptop repository, but I get this error:
+
+    git clone ssh://admin@nas:/share/HDA_DATA/myDir ./
+    Cloning into '.'...
+    admin@nas's password: 
+    sh: git-upload-pack: command not found
+    fatal: Could not read from remote repository.
+    
+    Please make sure you have the correct access rights
+    and the repository exists.
+
+I've checked that git-upload-pack is available both on my laptop and on the NAS and the "myDir" folder is supposed to be readable for the admin user on the NAS, even if the user I use on the laptop and on the NAS for git annex is different from the one I use to login. In fact, if I try to scp files from the annex folder then I don't get any permissions error.
+
+    scp admin@192.168.132.66:/share/HDA_DATA/myDir/* ./
+    admin@192.168.132.66's password: 
+    doctest                                                100%    5     0.0KB/s   0.0KB/s   00:00    
+    doctest2                                               100%   51     0.1KB/s   0.1KB/s   00:01
+
+Is there something else I should look at, in order to fix it and make it work?
+
+Thanks,
+Fabio
diff --git a/doc/forum/Ssh_remote_on_NAS/comment_1_1dd8a0d0e70a1fb36fce62e89c99b404._comment b/doc/forum/Ssh_remote_on_NAS/comment_1_1dd8a0d0e70a1fb36fce62e89c99b404._comment
new file mode 100644
index 0000000000..6563a9bb60
--- /dev/null
+++ b/doc/forum/Ssh_remote_on_NAS/comment_1_1dd8a0d0e70a1fb36fce62e89c99b404._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-11T19:46:05Z"
+ content="""
+How did you set your PATH? Note that the bash shell provides a lot of dotfiles which you can set the PATH in -- and reuses to read any single one of them when a noninteractive login is made to run a command.
+
+It might help to install git on the NAS. It's included in the git-annex tarball, but not in a way that will put it on PATH; only in a way that will let git-annex use it.
+"""]]
diff --git a/doc/forum/Ssh_remote_on_NAS/comment_2_261601313d8825c52322949b8509bc74._comment b/doc/forum/Ssh_remote_on_NAS/comment_2_261601313d8825c52322949b8509bc74._comment
new file mode 100644
index 0000000000..1cc8fb4443
--- /dev/null
+++ b/doc/forum/Ssh_remote_on_NAS/comment_2_261601313d8825c52322949b8509bc74._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="feulif"
+ ip="20.133.1.1"
+ subject="comment 2"
+ date="2014-07-15T18:03:56Z"
+ content="""
+> How did you set your PATH? Note that the bash shell provides a lot of dotfiles which you can set the PATH in -- and reuses to read any single one of them when a noninteractive login is made to run a command.
+
+Actually I didn't set the PATH: I've just sim-linked executable files from git-annex stand-alone folder to a directory that was in my PATH already.
+
+> It might help to install git on the NAS. It's included in the git-annex tarball, but not in a way that will put it on PATH; only in a way that will let git-annex use it.
+
+It was installed, bud I've removed it because it was \"conflicting\" with the one used by git-annex. That is, when I ran any \"git annex ...\" command, git was complaining it could not find git-annex (because my nas was running the installed git binary file).
+Without git, I don't have this conflict anymore and I can effectively use git-annex when I'm logged in my NAS, but I still can't add it as an SSH remote.
+
+"""]]
diff --git a/doc/forum/Ssh_remote_on_NAS/comment_3_ed602f4f972b78bce4f62bdfca8cfe47._comment b/doc/forum/Ssh_remote_on_NAS/comment_3_ed602f4f972b78bce4f62bdfca8cfe47._comment
new file mode 100644
index 0000000000..7ddb9dc8de
--- /dev/null
+++ b/doc/forum/Ssh_remote_on_NAS/comment_3_ed602f4f972b78bce4f62bdfca8cfe47._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 3"
+ date="2014-07-15T18:55:58Z"
+ content="""
+I don't think it was a good idea to remove git from the NAS. To set up a git remote, you necessarily need to have git installed on the remote.
+
+`git annex` should work as long as git-annex is somewhere in PATH -- unless your build of git is very strange and does not check PATH for git-foo commands.
+Even if this was the case, you could run `git-annex` instead.
+"""]]
diff --git a/doc/forum/Ssh_remote_on_NAS/comment_4_423244f174123318f1ece7b5794aeea5._comment b/doc/forum/Ssh_remote_on_NAS/comment_4_423244f174123318f1ece7b5794aeea5._comment
new file mode 100644
index 0000000000..9b0a03ecf1
--- /dev/null
+++ b/doc/forum/Ssh_remote_on_NAS/comment_4_423244f174123318f1ece7b5794aeea5._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="feulif"
+ ip="151.27.171.22"
+ subject="comment 4"
+ date="2014-07-17T22:24:45Z"
+ content="""
+First of all, I understand this is more a nas-related issue rather than a git-annex-related one, so thank you for your support and valuable software.
+
+But I'm still struggling with this error.
+
+Now I've reinstalled git on the NAS and, as previously, I can run every git command when I'm logged in.
+But when I try to sync my PC with the git remote on the NAS, then I get this error:
+
+
+    git annex sync
+    sh: git-annex-shell: command not found
+    sh: git-upload-pack: command not found
+    fatal: Could not read from remote repository.
+    
+    Please make sure you have the correct access rights
+    and the repository exists.
+    commit  
+    ok
+    git-annex: no branch is checked out
+
+Can this be really related to some access right? What user is git annex using when syncing with an SSH remote (e.g. admin) ? the one I specified when setting up the remote? where is it complaining about git-upload-pack non found, on the nas or on the PC I'm syncing from?
+
+"""]]
diff --git a/doc/forum/Ssh_remote_on_NAS/comment_5_07348ed61ccdd93417365f1525a05bf2._comment b/doc/forum/Ssh_remote_on_NAS/comment_5_07348ed61ccdd93417365f1525a05bf2._comment
new file mode 100644
index 0000000000..c8e631226f
--- /dev/null
+++ b/doc/forum/Ssh_remote_on_NAS/comment_5_07348ed61ccdd93417365f1525a05bf2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2014-10-28T20:26:08Z"
+ content="""
+git-upload-pack is a git command, which is not present in PATH
+on your NAS when git sshes in and tries to run it. 
+"""]]
diff --git a/doc/forum/Ssh_remote_on_NAS/comment_6_26d444afe2edea3500f80bb5c62ba491._comment b/doc/forum/Ssh_remote_on_NAS/comment_6_26d444afe2edea3500f80bb5c62ba491._comment
new file mode 100644
index 0000000000..af180a980c
--- /dev/null
+++ b/doc/forum/Ssh_remote_on_NAS/comment_6_26d444afe2edea3500f80bb5c62ba491._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="torpidus"
+ subject="comment 6"
+ date="2016-03-16T22:23:26Z"
+ content="""
+Hello Fabio,
+I came across this posting from you one year ago. Since I'm also using a QNAP NAS for hosting several of my git-annex repos, it would be very valuable to hear some details about your setup. My setup currently consists of a virtual machine hosted on the NAS with an ordinary linux, nothing special. Would love to have git-annex installed on the NAS operating system rather, which is unfortunately not that easy.
+
+
+Even in case you may not have been able to solve the issue described in this thread, can you maybe tell for example how you solved the issue of the QNAP operating system purging self-installed software? Or how you managed to let the pre-installed SSH daemon let other users than \"admin\" log-in?
+
+
+Probably we're the first ones ever trying this, so it would be very useful to collect all about QNAP NAS and the usage of git-annex on these devices.
+"""]]
diff --git a/doc/forum/Ssh_remote_on_NAS/comment_7_3c70f8b9ac2a77462c6f21929c02d9d3._comment b/doc/forum/Ssh_remote_on_NAS/comment_7_3c70f8b9ac2a77462c6f21929c02d9d3._comment
new file mode 100644
index 0000000000..6f6c687ca7
--- /dev/null
+++ b/doc/forum/Ssh_remote_on_NAS/comment_7_3c70f8b9ac2a77462c6f21929c02d9d3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Fabio"
+ avatar="http://cdn.libravatar.org/avatar/2bf56b78ae28b64d6131ba3115df238b"
+ subject="comment 7"
+ date="2017-01-30T22:26:46Z"
+ content="""
+Hello Torpidus,
+I've never managed to get SSH working properly on my NAS because of the issues you have reported and so I eventually gave up with using git-annex on it.
+But I'm back here every now and then to check how this wonderful software is going on and if anyone has made it work on my NAS :)
+
+"""]]
diff --git a/doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects.mdwn b/doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects.mdwn
new file mode 100644
index 0000000000..043a3f2db6
--- /dev/null
+++ b/doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects.mdwn
@@ -0,0 +1,39 @@
+I recently migrated some of my repositories from WORM to SHA1E, and
+noticed after finishing conversion and dropping all WORM keys that
+there are some stale files and directories left over in the
+.git/annex/objects directory. These seem to fall into two categories:
+
+1. There are some empty directories meant for WORM-keys. Strangely, I
+don’t believe the content of these keys has ever been present on this
+machine, and the corresponding .log files do not contain the local
+UUID. What might be the deal with those?
+
+Another set of empty WORM directories housed content I unannexed and
+checked into regular git on my other remote, and then pulled locally.
+A subsequent «dropunused» seems to have left the empty directories
+after dropping their content.
+
+I suppose the stale directories can be safely pruned away?
+
+One thing I noticed is that, while the terminal leaf in the objects
+directory is usually sticky (mode +t), the stale directories to
+content I unannexed are all non-sticky. Maybe this gives some
+indication where things got stuck? A few (though not all) of the other
+terminal directories are non-sticky, as well.
+
+2. There are some .map and .cache files leftover in
+.git/annex/objects. This is an indirect repository, but I briefly
+switched it to direct once. The stale files seem to belong to content
+with which I had some difficulties when «git annex add»’ing the files
+(I recall I had to add them multiple times before they were correctly
+indexed). I now examined these files again and noticed they were
+tracked via regular git. I «git rm»’ed them and readded them into the
+annex. Can the stale .cache and .map files be safely deleted?
+
+I noticed some of these keys have the format
+«WORM-s123-m-123456789--name», with an additional dash before the
+mtime. Has there been a format change, or does this indicate a
+problem?
+
+Best regards,
+Z.
diff --git a/doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects/comment_1_2aa80b317863a99e676a375d907d0e84._comment b/doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects/comment_1_2aa80b317863a99e676a375d907d0e84._comment
new file mode 100644
index 0000000000..34cbb011a3
--- /dev/null
+++ b/doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects/comment_1_2aa80b317863a99e676a375d907d0e84._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-02T16:23:35Z"
+ content="""
+I cannot see a way that eg, `dropunused` could leave empty object directories. The few functions that remove content from a repository call `cleanObjectLoc` to prune the empty directories that result. Of course, the empty directories can be safely removed.
+
+IIRC older versions of direct mode might have made stale .cache and .map before. They can be deleted if you're not using direct mode.
+
+The only way I can see that a dash could come before the 'm' and the mtime is if the mtime were negative. I don't know how that would happen, but the code has certainly never put a dash there, and 
+WORM-s123-m-123456789--name is not a valid git-annex key; git-annex cannot parse it.
+"""]]
diff --git a/doc/forum/Standard_groups__47__preferred_contents.mdwn b/doc/forum/Standard_groups__47__preferred_contents.mdwn
new file mode 100644
index 0000000000..89e2b848c7
--- /dev/null
+++ b/doc/forum/Standard_groups__47__preferred_contents.mdwn
@@ -0,0 +1,14 @@
+Sorry that I am not stop asking questions - I am trying to wrap my head around annex still - and I do not fully understand the standard groups/preferred contents yet.
+
+
+First, basic: Is the "preferred content group" an attribute of a repository or of a remote? E.g., when I use assistant, I can set this property for a *remote* repository. Will this property be synced to all other clients then or is it only valid for this particular client?
+
+Second, I think the standard groups do still not cover what I want and I wonder if this could be done with preferred contents somehow? What I want:
+
+* Generally only the structure should be synced, no contents (i.e. "manual" is the closest)
+
+* When I (manually) do "git annex get" on a file this file should be synced whenever it changes locally *or* remotely (until I drop it again). Currently it seems that when it changes remotely, it is "dropped" again so I need to manually use "git annex get" again
+
+* When I (manually) do "git annex get" on a directory, it should be (recursively) synced whenever it or any file changes locally or remotely (until I drop it again). Currently nothing seems to sync at all in this case (except the meta data)
+
+Thanks!
diff --git a/doc/forum/Standard_groups__47__preferred_contents/comment_1_143aa3095d7222c869c36a5039282e35._comment b/doc/forum/Standard_groups__47__preferred_contents/comment_1_143aa3095d7222c869c36a5039282e35._comment
new file mode 100644
index 0000000000..343a049e7a
--- /dev/null
+++ b/doc/forum/Standard_groups__47__preferred_contents/comment_1_143aa3095d7222c869c36a5039282e35._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="sts"
+ ip="134.147.73.126"
+ subject="comment 1"
+ date="2014-07-18T21:16:50Z"
+ content="""
+> First, basic: Is the \"preferred content group\" an attribute of a repository or of a remote? E.g., when I use assistant, I can set this property for a remote repository. Will this property be synced to all other clients then or is it only valid for this particular client?
+
+Yeah, it syncs the content group between the remotes, so you have to set it only in one repository and the information gets synced across the network.
+
+> Second, I think the standard groups do still not cover what I want and I wonder if this could be done with preferred contents somehow? What I want:
+> Generally only the structure should be synced, no contents (i.e. \"manual\" is the closest)
+
+Well, I guess you have to manually create a git repo (but no annex repo!) on your remote. Once you add the remote the assistant should tell you that he can only sync the metadata, but no contents.
+
+"""]]
diff --git a/doc/forum/Standard_groups__47__preferred_contents/comment_2_65bef012eb113986a2e9b02470a6cbd1._comment b/doc/forum/Standard_groups__47__preferred_contents/comment_2_65bef012eb113986a2e9b02470a6cbd1._comment
new file mode 100644
index 0000000000..df204b0582
--- /dev/null
+++ b/doc/forum/Standard_groups__47__preferred_contents/comment_2_65bef012eb113986a2e9b02470a6cbd1._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmMLeU-zCzx2mc5pL2XT8a1UNkQwHAHjg8"
+ nickname="daniele"
+ subject="comment 2"
+ date="2014-07-19T00:38:58Z"
+ content="""
+    Generally only the structure should be synced, no contents (i.e. \"manual\" is the closest)
+    Currently it seems that when it changes remotely, it is \"dropped\" again so I need to manually use \"git annex get\" again
+
+Maybe this could work? 
+
+(in preferred content) exclude=\"*\" and present
+
+So that what is present is preferred and not dropped, everything else is not downloaded unless the user explicitly asks to get it.
+"""]]
diff --git a/doc/forum/Standard_groups__47__preferred_contents/comment_3_202a7e2820e0adf079ccd14a7993ad25._comment b/doc/forum/Standard_groups__47__preferred_contents/comment_3_202a7e2820e0adf079ccd14a7993ad25._comment
new file mode 100644
index 0000000000..523aa742a5
--- /dev/null
+++ b/doc/forum/Standard_groups__47__preferred_contents/comment_3_202a7e2820e0adf079ccd14a7993ad25._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="204.17.143.10"
+ subject="comment 3"
+ date="2014-07-22T00:11:34Z"
+ content="""
+Unfortunately the same :(
+
+Testcase:
+1.) Create a file 'file' on the server, git annex add/sync etc.
+2.) On the client: git annex wanted here 'exclude=\"*\" and present'
+3.) On the client: git annex get file . The file is now present on the client
+4.) Change the file on the server, git annex sync
+5.) git annex sync --content on the client
+
+Result: File is dropped again on client
+
+
+
+
+"""]]
diff --git a/doc/forum/Standard_groups__47__preferred_contents/comment_4_e0faf9ebd3162e0de860eba0fd28c67c._comment b/doc/forum/Standard_groups__47__preferred_contents/comment_4_e0faf9ebd3162e0de860eba0fd28c67c._comment
new file mode 100644
index 0000000000..50acdbc4a7
--- /dev/null
+++ b/doc/forum/Standard_groups__47__preferred_contents/comment_4_e0faf9ebd3162e0de860eba0fd28c67c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="204.17.143.10"
+ subject="comment 4"
+ date="2014-07-22T00:24:46Z"
+ content="""
+... and for the directories the same:
+
+1.) Create a (sub-)directory 'subdir' with files and sync everything
+2.) On the client: git annex get subdir . The subdirectory is now present, all files under it downloaded.
+3.) On the server create a new file in 'subdir' and git annex add; git annex sync --content
+4.) git annex sync --content on the client
+
+Result: Content of the files is not synced to client 
+"""]]
diff --git a/doc/forum/Standard_groups__47__preferred_contents/comment_5_eb47696244931173bddcbeb8d5f78637._comment b/doc/forum/Standard_groups__47__preferred_contents/comment_5_eb47696244931173bddcbeb8d5f78637._comment
new file mode 100644
index 0000000000..fa5c47ee2e
--- /dev/null
+++ b/doc/forum/Standard_groups__47__preferred_contents/comment_5_eb47696244931173bddcbeb8d5f78637._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmMLeU-zCzx2mc5pL2XT8a1UNkQwHAHjg8"
+ nickname="daniele"
+ subject="comment 5"
+ date="2014-07-22T00:29:20Z"
+ content="""
+wait, is the group working together with the preferred content?
+
+Usually you set a repository in a group and then you tell annex that particular group has this preferred content expression (which by default is set to 'standard'). So you could add the repo to 'client' group then set the group 'client' to that preferred content expression. If you only want that particular client to have that expression you can play around with \"groupwanted\", or even define your own group I guess.
+
+Use \"git annex vicfg\" to quickly check both \"group\" and \"wanted\" settings together.
+
+"""]]
diff --git a/doc/forum/Standard_groups__47__preferred_contents/comment_6_c70c9fa97bce8e4eb9b3880d8f843aef._comment b/doc/forum/Standard_groups__47__preferred_contents/comment_6_c70c9fa97bce8e4eb9b3880d8f843aef._comment
new file mode 100644
index 0000000000..435d7f7d2e
--- /dev/null
+++ b/doc/forum/Standard_groups__47__preferred_contents/comment_6_c70c9fa97bce8e4eb9b3880d8f843aef._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="204.17.143.10"
+ subject="comment 6"
+ date="2014-07-23T05:20:47Z"
+ content="""
+Hi daniele,
+
+I am not completely sure what you mean but I as far as I understand as soon as I set \"wanted\" to anything other than \"default\" the standard groups do not apply at all.
+I can't use vicfg because I use windows and this command hangs ... probably because there is no vi.
+
+However, I can still check the expressions:
+
+    $ git annex group here
+    manual
+    $ git annex wanted here
+    exclude=\"*\" and present
+    $
+
+Have you tried this? Does it work in your case?
+Because the standard preferred contents also contains \"present\" so I assume it would behave the same.
+Is maybe \"present\" broken or the behavior different than expected?
+
+
+"""]]
diff --git a/doc/forum/Standard_groups__47__preferred_contents/comment_7_413593ea0663874196305c9eb602e7c4._comment b/doc/forum/Standard_groups__47__preferred_contents/comment_7_413593ea0663874196305c9eb602e7c4._comment
new file mode 100644
index 0000000000..32bfa6bc00
--- /dev/null
+++ b/doc/forum/Standard_groups__47__preferred_contents/comment_7_413593ea0663874196305c9eb602e7c4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2014-10-28T20:23:55Z"
+ content="""
+See [[bugs/present_files__47__directories_are_dropped_after_a_sync]]
+"""]]
diff --git a/doc/forum/Standards_usage_pattern__63__.mdwn b/doc/forum/Standards_usage_pattern__63__.mdwn
new file mode 100644
index 0000000000..280e909a5b
--- /dev/null
+++ b/doc/forum/Standards_usage_pattern__63__.mdwn
@@ -0,0 +1,8 @@
+Hi,
+
+I have few devices: 2x android, 2x windows, 2x linux and I would like to share at least one folder on all of them.
+None of the devices have public IPs and some regularly change location (work laptops). Because the XMPP support is missing on windows I couldn't find a way to synchronize the repositories (the keys) or did I miss something in the documentation?
+How can I archieve "seamless" synchronization when I start the webapp on the devices?
+
+Thank you,
+Karol
diff --git a/doc/forum/Standards_usage_pattern__63__/comment_1_1ccbfaefe3bbaf767e999cd1c61debfb._comment b/doc/forum/Standards_usage_pattern__63__/comment_1_1ccbfaefe3bbaf767e999cd1c61debfb._comment
new file mode 100644
index 0000000000..d96585f9b3
--- /dev/null
+++ b/doc/forum/Standards_usage_pattern__63__/comment_1_1ccbfaefe3bbaf767e999cd1c61debfb._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9SYh6N-JUMkYkW4aOk55zC3Vr9KonDV4"
+ nickname="Florian"
+ subject="comment 1"
+ date="2014-11-19T22:01:19Z"
+ content="""
+I think you need at least one server that is reachable from every device and serves as a transfer repository. XMPP is only needed to inform peers about changes. Usual the assistant performs a startup check and detects changes that way. You can't sync content over XMPP. 
+All that is very afaik, I hope for corrections if wrong. 
+"""]]
diff --git a/doc/forum/Starting_assistant_from_CLI.mdwn b/doc/forum/Starting_assistant_from_CLI.mdwn
new file mode 100644
index 0000000000..8a4bc3d1bf
--- /dev/null
+++ b/doc/forum/Starting_assistant_from_CLI.mdwn
@@ -0,0 +1,9 @@
+I am unable to start the git-annex assistant/webapp.
+
+I use OpenBox as desktop manager and the assistant/webapp is not available through the menu.
+
+Trying to use the CLI, all my attempts fail with a message saying that it(?) is not a git repository!? Since the video show that on first start the assistant/webapp allows a choice of a directory and then creates it, I am not sure as to what git initialized directory does the assistant/webapp requires in this instance. And I also guess that means invoking the webapp from that directory rather than from the directory that contains the standalone git-annex.
+
+Any help would be appreciated as git-annex really seems to be the app I am looking for.  :)
+
+Thanks
diff --git a/doc/forum/Starting_assistant_from_CLI/comment_1_afd51ddb0f1bb3cac528e1d96829ef83._comment b/doc/forum/Starting_assistant_from_CLI/comment_1_afd51ddb0f1bb3cac528e1d96829ef83._comment
new file mode 100644
index 0000000000..05c7a12d40
--- /dev/null
+++ b/doc/forum/Starting_assistant_from_CLI/comment_1_afd51ddb0f1bb3cac528e1d96829ef83._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 1"
+ date="2014-04-14T15:35:17Z"
+ content="""
+running,
+
+    git annex webapp
+
+should launch the web app.
+"""]]
diff --git a/doc/forum/Starting_assistant_from_CLI/comment_2_76c34c00cf2065809b15a594023a688b._comment b/doc/forum/Starting_assistant_from_CLI/comment_2_76c34c00cf2065809b15a594023a688b._comment
new file mode 100644
index 0000000000..d0ce4b28fe
--- /dev/null
+++ b/doc/forum/Starting_assistant_from_CLI/comment_2_76c34c00cf2065809b15a594023a688b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlqL3QbH6hrzf4XT-OW5IcMj6zSrMWl2dg"
+ nickname="Michel"
+ subject="comment 2"
+ date="2014-04-14T22:45:23Z"
+ content="""
+Unfortunately, no, I tried this and many other variants, (I tried again just now, to be sure, and I still get the \"git-annex: Not in a git repository.\" message.
+
+Thanks for trying to help. It is very much appreciated.
+
+"""]]
diff --git a/doc/forum/Starting_assistant_from_CLI/comment_3_f7826867f78b1adbfc2dad2fad4d6720._comment b/doc/forum/Starting_assistant_from_CLI/comment_3_f7826867f78b1adbfc2dad2fad4d6720._comment
new file mode 100644
index 0000000000..fbe70c4038
--- /dev/null
+++ b/doc/forum/Starting_assistant_from_CLI/comment_3_f7826867f78b1adbfc2dad2fad4d6720._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 3"
+ date="2014-04-17T20:48:56Z"
+ content="""
+Yes, the webapp is supposed to be able to be started from anywhere. 
+
+1. If you make a git annex repository and run `git annex webapp` from inside it, it'll start up the webapp on that repository. 
+2. If `~/.config/git-annex/autostart` lists some git repositories, the webapp will start up in the first listed one.
+3. Otherwise, the webapp will walk you through making a new repository.
+
+Most likely problem then is #2. If you used the webapp once, say in ~/annex and then deleted ~/annex/.git directory, it would try to start up in ~/annex, but it's no longer a git repository so it cannot start. This was a bug, so I've fixed it. 
+You could work around that problem by deleting `~/.config/git-annex/autostart` too.
+
+If it's some other problem, you can work around it by going the #1 route and making a git repository by hand (\"git init annex; cd annex; git annex init\") and running the webapp in there.
+"""]]
diff --git a/doc/forum/Starting_assistant_from_CLI/comment_4_fa7055a232a1dcb743db47308f7acf0b._comment b/doc/forum/Starting_assistant_from_CLI/comment_4_fa7055a232a1dcb743db47308f7acf0b._comment
new file mode 100644
index 0000000000..4eea29c5fd
--- /dev/null
+++ b/doc/forum/Starting_assistant_from_CLI/comment_4_fa7055a232a1dcb743db47308f7acf0b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlqL3QbH6hrzf4XT-OW5IcMj6zSrMWl2dg"
+ nickname="Michel"
+ subject="comment 4"
+ date="2014-04-18T00:20:47Z"
+ content="""
+Thank you.
+
+The problem was indeed with having a file containing a non-existent ~/.config/git-annex/autostart.
+
+I can now continue my evaluation of what looks like a very fine and useful piece of software.
+
+Thanks again for the help.
+"""]]
diff --git a/doc/forum/Starting_assistant_from_CLI/comment_5_8d657646080bf2b99b7792993b877502._comment b/doc/forum/Starting_assistant_from_CLI/comment_5_8d657646080bf2b99b7792993b877502._comment
new file mode 100644
index 0000000000..f327bab3be
--- /dev/null
+++ b/doc/forum/Starting_assistant_from_CLI/comment_5_8d657646080bf2b99b7792993b877502._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="jodumont"
+ avatar="http://cdn.libravatar.org/avatar/343b334cbc4b2bff019ab6b525a2c9ed"
+ subject="Explanation for a noGUI usage"
+ date="2021-02-19T04:39:34Z"
+ content="""
+I had that issue, git-annex is installed on a noGUI remote machine so the directory and the file **~/.config/git-annex/autostart** didn't exist.
+I think it worth to mention than you could create by hand **~/.config/git-annex/autostart**
+
+> mkdir ~/.config/git-annex/; touch ~/.config/git-annex/autostart
+
+and in simply add the path of your git-annex you want to start such as **/srv/data** for this example (*which contain a .git/annex/ directory*) then you are ready to go
+
+> cd /srv/data; git annex assistant --autostart
+"""]]
diff --git a/doc/forum/Steps_for_setting_up_Google_Cloud_Storage___40__GSC__41__.mdwn b/doc/forum/Steps_for_setting_up_Google_Cloud_Storage___40__GSC__41__.mdwn
new file mode 100644
index 0000000000..84fcfb4d5b
--- /dev/null
+++ b/doc/forum/Steps_for_setting_up_Google_Cloud_Storage___40__GSC__41__.mdwn
@@ -0,0 +1 @@
+Are the recommended steps for setting up an annex on Google Cloud Storage (GCS) documented anywhere? The info I'm able to find seems to be from years ago. I'm struggling to get the combination of the GCS configuration to allow access and picking which of the multiple ways to initialize the annex.
diff --git a/doc/forum/Steps_for_setting_up_Google_Cloud_Storage___40__GSC__41__/comment_1_addbedd6ee8a534c5c4f0e639c05591c._comment b/doc/forum/Steps_for_setting_up_Google_Cloud_Storage___40__GSC__41__/comment_1_addbedd6ee8a534c5c4f0e639c05591c._comment
new file mode 100644
index 0000000000..31736026d5
--- /dev/null
+++ b/doc/forum/Steps_for_setting_up_Google_Cloud_Storage___40__GSC__41__/comment_1_addbedd6ee8a534c5c4f0e639c05591c._comment
@@ -0,0 +1,79 @@
+[[!comment format=sh
+ username="globallyunique@da2274b36ca296fe35912b9fd7387e3a5bd17c7c"
+ nickname="globallyunique"
+ avatar="http://cdn.libravatar.org/avatar/b25877ad636e36714dbe62f9d5d0fea1"
+ subject="GCS using S3: removeKey when not present: FAIL "
+ date="2020-05-14T20:39:21Z"
+ content="""
+I mostly got it to work but running: \"git annex testremote cloud\" is all green OKs except it produces one failure for each file of: fails with the message: removeKey when not present:                      FAIL (0.35s)
+
+Annex was setup by:
+git annex initremote --force cloud      type=S3      host=storage.googleapis.com protocol=https port=80 bucket=gitannex-datalad encryption=none
+git annex wanted cloud \"anything\"
+
+testremote cloud (generating test keys...) Remote Tests
+  unavailable remote
+    removeKey:                                       OK (0.16s)
+    storeKey:                                          HttpExceptionRequest Request {
+    host                 = \"gitannex-datalad.!dne!\"
+    port                 = 443
+    secure               = True
+    requestHeaders       = [(\"Date\",\"Thu, 14 May 2020 13:31:06 GMT\"),(\"Content-Type\",\"application/octet-stream\"),(\"Authorization\",\"<REDACTED>\"),(\"x-amz-storage-class\",\"STANDARD\")]
+    path                 = \"/SHA256E-s1048576--805e60b26375f68e670a266aee7698085d9eb8ddf56f6c5ec1497f1e667384fa.this-is-a-test-key\"
+    queryString          = \"\"
+    method               = \"PUT\"
+    proxy                = Nothing
+    rawBody              = False
+    redirectCount        = 10
+    responseTimeout      = ResponseTimeoutDefault
+    requestVersion       = HTTP/1.1
+  }
+   (ConnectionFailure Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [AI_ADDRCONFIG], addrFamily = AF_UNSPEC, addrSocketType = Stream, addrProtocol = 6, addrAddress = <assumed to be undefined>, addrCanonName = <assumed to be undefined>}, host name: Just \"gitannex-datalad.!dne!\", service name: Just \"443\"): does not exist (nodename nor servname provided, or not known))
+OK (0.02s)
+    checkPresent:                                    OK
+    retrieveKeyFile:                                 OK
+    retrieveKeyFileCheap:                            OK
+  key size Just 1048576; NoChunks; encryption none
+    removeKey when not present:                      FAIL (0.35s)
+      ./Command/TestRemote.hs:206:
+      failed
+    present False:                                   OK (0.13s)
+    storeKey:                                        OK (1.63s)
+    present True:                                    OK (0.15s)
+    storeKey when already present:                   OK (1.65s)
+    present True:                                    OK (0.10s)
+    retrieveKeyFile:                                 OK (0.34s)
+    fsck downloaded object:                          OK
+    retrieveKeyFile resume from 33%:                 OK (0.18s)
+    fsck downloaded object:                          OK
+    retrieveKeyFile resume from 0:                   OK (0.17s)
+    fsck downloaded object:                          OK
+    retrieveKeyFile resume from end:                 OK (0.16s)
+    fsck downloaded object:                          OK
+    removeKey when present:                          OK (0.11s)
+    present False:                                   OK (0.08s)
+  key size Just 1048576; NoChunks; encryption none
+    removeKey when not present:                      FAIL (0.30s)
+      ./Command/TestRemote.hs:206:
+      failed
+    present False:                                   OK (0.12s)
+    storeKey:                                        OK (1.60s)
+    present True:                                    OK (0.11s)
+    storeKey when already present:                   OK (2.08s)
+    present True:                                    OK (0.10s)
+    retrieveKeyFile:                                 OK (0.26s)
+    fsck downloaded object:                          OK
+    retrieveKeyFile resume from 33%:                 OK (0.19s)
+    fsck downloaded object:                          OK
+    retrieveKeyFile resume from 0:                   OK (0.16s)
+    fsck downloaded object:                          OK
+    retrieveKeyFile resume from end:                 OK (0.17s)
+    fsck downloaded object:                          OK
+    removeKey when present:                          OK (0.12s)
+    present False:                                   OK (0.12s)
+  key size Just 1048576; UnpaddedChunks 10485; encryption none
+    removeKey when not present:                      FAIL (0.33s)
+      ./Command/TestRemote.hs:206:
+      failed
+
+"""]]
diff --git a/doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt.mdwn b/doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt.mdwn
new file mode 100644
index 0000000000..4812c6f0b4
--- /dev/null
+++ b/doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt.mdwn
@@ -0,0 +1,12 @@
+Hello,
+
+my final goal is to store files on an untrusted external server/USB drive in an encrypted git repository.
+
+- First I set up the external git repository with `git init --bare /path/to/external`
+- Second I add the special remote with `git annex initremote encrypted-origin type=gcrypt gitrepo=/path/to/external encryption=hybrid keyid=$keyid`
+- Then I sync with `git annex sync`
+- Then I copy the files to the remote with `git annex copy -t encrypted-origin`
+
+I can now see the annexed files in the remote repository **unencrypted**. I do not want the copied files to be readable on the remote.
+
+Is that the intended behaviour, or did I do something wrong?
diff --git a/doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt/comment_1_5a643827a1ced7c0b9bba5303f71a52c._comment b/doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt/comment_1_5a643827a1ced7c0b9bba5303f71a52c._comment
new file mode 100644
index 0000000000..c6d9c686cb
--- /dev/null
+++ b/doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt/comment_1_5a643827a1ced7c0b9bba5303f71a52c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="codecircuit"
+ avatar="http://cdn.libravatar.org/avatar/8a2041fb0484e333aa769009d49c4061"
+ subject="comment 1"
+ date="2020-02-28T11:29:27Z"
+ content="""
+Ok, I assume it is better to just take the `rsync` or `directory` special remote
+"""]]
diff --git a/doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt/comment_2_92e1aef2ce26210b15a908e2cf729b80._comment b/doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt/comment_2_92e1aef2ce26210b15a908e2cf729b80._comment
new file mode 100644
index 0000000000..44b211a270
--- /dev/null
+++ b/doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt/comment_2_92e1aef2ce26210b15a908e2cf729b80._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 2"
+ date="2020-02-28T16:17:08Z"
+ content="""
+Which version do you use? There was a [bug](https://git-annex.branchable.com/bugs/gcrypt_special_remote_not_working/) in an earlier version of this month which was [fixed](https://git-annex.branchable.com/devblog/day_619__important_bugfix_release_and_v8_too/) with [7.20200226](https://git-annex.branchable.com/news/version_7.20200226/).
+"""]]
diff --git a/doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt/comment_3_12a72b294e2808b09bff6788cf2b19dd._comment b/doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt/comment_3_12a72b294e2808b09bff6788cf2b19dd._comment
new file mode 100644
index 0000000000..b8a6e35c92
--- /dev/null
+++ b/doc/forum/Store_annexed_files_encrypted_on_special_remote_with_gcrypt/comment_3_12a72b294e2808b09bff6788cf2b19dd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-02-28T17:49:52Z"
+ content="""
+This was a bug in git-annex versions before 7.20200226.
+It's since been fixed.
+
+<https://git-annex.branchable.com/bugs/gcrypt_special_remote_not_working/>
+"""]]
diff --git a/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn b/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
new file mode 100644
index 0000000000..175bc2b4ce
--- /dev/null
+++ b/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
@@ -0,0 +1,13 @@
+I'm looking for a way to count/track annex data copied to LTO tapes.
+
+In my use case I'm splitting many terabytes of data to separate repositories on several hard drives, backing them up on tapes, and keeping track of all this with remotes in a central repository (with lots of dropped content). All good with the HDs, but I'm at a loss about how to handle the copies on tapes.
+
+Three alternatives I've come up with so far:
+
+1. Simply tar the repositories from the HDs to the tapes. Problem: no way to notify git annex of the existence of these manual copies. Or is there?
+2. Remote (special or normal) on LTFS (linear posix compatible file system on top of tape). Problems:
+    1. `git annex get`ing a dropped directory from there would cause files to be accessed in random order, right? Or is the retrieve guaranteed to happen in the same order as the files in the directory were written by `git annex copy`?
+    2. LTFS has a big block size (512KB) => wasted space when lots of small files. (Not a major problem, though.)
+3. Write a special (read-only) remote hook for `tar`. Problem: `git annex get` would make one hook *RETRIEVE* request per file, leading to random access again, while the only effective way would be to get a list of all files to be retrieved, and then returning them in the order they turn up from the tar package (or even ingest the whole tar file to .git/annex/).
+
+Thoughts?
diff --git a/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_1_9ae9ca3983f7d4209fd1de65d982731d._comment b/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_1_9ae9ca3983f7d4209fd1de65d982731d._comment
new file mode 100644
index 0000000000..805042e0c5
--- /dev/null
+++ b/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_1_9ae9ca3983f7d4209fd1de65d982731d._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T21:00:00Z"
+ content="""
+All your solutions are reasonable, but you're right that none of them
+avoid random-access. And git-annex is generally not built in a way that
+makes it easy to avoid random-access.
+
+But, I think it's tractable with a special remote.
+
+Consider a special remote that has two retrieval modes.
+In one mode, it always fails to retrieve keys, but keeps a list. In the
+second mode, it starts up by going through its list, retreives everything
+in order to a temporary directory, and then when asked to retrieve a key,
+just moves it from the temp dir into place. This is somewhat similar to how
+Amazon Glacier works, and like git-annex's glacier support, it would result
+in the first `git-annex get` failing, and a second `git annex get` being
+needed to finish the retrival.
+
+That could be improved.. Make the special remote fail to retrive keys,
+and keep a list. On shutdown, it then sorts the list, retrieves the keys
+in order, and runs `git annex setkey` to move the content into the annex.
+Still a little bit weird, because `git annex get` would seem to fail
+and then pause at the end for a long time, after which the files would
+actually end up being present. 
+
+(Also, I er, removed `git annex setkey` in
+2011, because it didn't seem very useful, but this is in fact a use case
+for it, so I've added it back now.)
+"""]]
diff --git a/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_2_6d16d00c7ef8d846e370e1b298a7bc7a._comment b/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_2_6d16d00c7ef8d846e370e1b298a7bc7a._comment
new file mode 100644
index 0000000000..ed00112b17
--- /dev/null
+++ b/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_2_6d16d00c7ef8d846e370e1b298a7bc7a._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""another approach"""
+ date="2015-07-02T22:25:25Z"
+ content="""
+You could make a special remote that streams the whole tar file from the
+tape, and uses `git annex setkey` to add each file from the tarball to the
+annex.
+
+Done this way, the first file that `git annex get` processed would actually
+cause *every* file to be gotten from the tape. As it continued on to
+subsequent files, the `git annex get` would see their content was already
+present and skip them.
+
+Of course, the downside is it works on a whole tape at a time, so if you
+don't want to load the whole tape into the filesystem, you wouldn't want to
+use this approach.
+"""]]
diff --git a/doc/forum/Storing_git_repos_in_git-annex.mdwn b/doc/forum/Storing_git_repos_in_git-annex.mdwn
new file mode 100644
index 0000000000..964040cf0a
--- /dev/null
+++ b/doc/forum/Storing_git_repos_in_git-annex.mdwn
@@ -0,0 +1,27 @@
+I tried to use the [old thread](http://git-annex.branchable.com/forum/Git_repos_in_git_annex__63__/?updated#comment-9fca5cf31ccfd3d78c78cb65f7672340) for this, but threads don't get bumped when they are updated, so I guess I'll have to start a new one...
+
+Here is the relevant [bug report](http://git-annex.branchable.com/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X).
+
+Here's my scenario: I have been using Dropbox for several years.  I want to move to git-annex.
+
+For some time I used Bazaar repos inside Dropbox.  A couple of times I accidentally modified files on one computer before another finished syncing, and the repo became mildly corrupted, but I recovered it okay.
+
+Recently I switched from bzr to git, and so far, so good.  I'm careful not to make any changes to my files before Dropbox is finished syncing, so everything works fine.
+
+Now I'm testing git-annex as a replacement for Dropbox again.  But when I add a directory containing a git repo to an annex, git-annex ignores the .git directory, so the repo isn't synced.
+
+I read this forum thread, and I read the bug report, but there don't appear to be any real solutions.
+
+This seems like what should be a fairly common use case: a user has a directory of simple text files, like shell scripts or org-mode files.  He uses git to version-control them, and he uses Dropbox to sync the files and the git repo automatically between computers.  Now the user wants to use git-annex instead, but if he does this, it will mean having to choose between:
+
+* No longer using git to version-control the files
+* Only using git on a single system, which means that he can't make commits or do any other git operations when using other systems
+* Keeping separate git repos on each system, and making the same commits manually on each one...which would be a mess
+* Keeping separate git repos on each system, and using a script to make commits automatically--which would mean commits wouldn't be any more useful than a simple timed backup script
+
+I guess I could just use git instead of Dropbox or git-annex, but then I must choose between either:
+
+* Only being able to sync repos when both systems are online
+* Having to store repos in plaintext on remote servers
+
+This is one of my primary use cases for Dropbox/git-annex.  I'd really appreciate any help in figuring this out.  Thanks.
diff --git a/doc/forum/Storing_git_repos_in_git-annex/comment_1_ac7b52c0b0f75d79760ffe6a9b5c8759._comment b/doc/forum/Storing_git_repos_in_git-annex/comment_1_ac7b52c0b0f75d79760ffe6a9b5c8759._comment
new file mode 100644
index 0000000000..cb5b39ffc2
--- /dev/null
+++ b/doc/forum/Storing_git_repos_in_git-annex/comment_1_ac7b52c0b0f75d79760ffe6a9b5c8759._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-05-16T17:29:15Z"
+ content="""
+Why not just use git the way it's designed: Make a git repository on one computer. Clone to another computer. Commit changes on either whenever you like, and pull/push whenever you like. No need for any dropbox to help git sync, it can do so perfectly well on its own.
+
+If you have a lot of repositories, see <http://myrepos.branchable.com/>
+
+I continue to be unimpressed and unmotived by this use case. Posting more forum threads with the same lame reasons won't help. But at least you did say:
+
+> For some time I used Bazaar repos inside Dropbox.  A couple of times I accidentally modified files on one computer before another finished syncing
+, and the repo became mildly corrupted, but I recovered it okay.
+
+> Recently I switched to git, and so far, so good.  I'm careful not to make any changes to my files before Dropbox is finished syncing, so everythin
+g works fine.
+
+So, you used dropbox, and corrupted data.  But that was ok. And now you're very careful to avoid doing things that will corrupt data. But that's ok. Yeah, that seems like a really good decision, given all the excellent possibilities out there.`</snark>`
+"""]]
diff --git a/doc/forum/Storing_git_repos_in_git-annex/comment_3_3bec1f02ff1a61791e3cbb428c7acb4c._comment b/doc/forum/Storing_git_repos_in_git-annex/comment_3_3bec1f02ff1a61791e3cbb428c7acb4c._comment
new file mode 100644
index 0000000000..69da79a89c
--- /dev/null
+++ b/doc/forum/Storing_git_repos_in_git-annex/comment_3_3bec1f02ff1a61791e3cbb428c7acb4c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="comment 3"
+ date="2014-05-17T00:23:02Z"
+ content="""
+Well, like Pere, I am rather surprised by your response, Joey.  I've been an enthusiastic supporter and follower of git-annex for a long time now, and have been looking forward to using it.  I didn't expect a snarky reply...and you said yourself that it was snarky.  Maybe you had a bad day or something?  :)
+
+I don't understand why this request or idea is so controversial to you.  I have several computers, and I use git to store basic text files like shell scripts and config files--a very common situation.  I use Dropbox to sync them automatically between computers.  I could use just git, and push/pull manually, but the whole point of having computers is for them to do things for me, automatically.  The purpose of the git-annex assistant, as I understand it, is to do exactly that.  Doing the push/pull manually would be a step backwards.  And giving up manual control of the git repository, losing the ability to track changes to my files, would be a huge step backwards.
+
+This seems like it must be a very common use case among Linux users, especially ones who use the shell, git, etc.  If git-annex isn't good for this situation, what is?  Surely there's a better way than opening a shell and running \"git pull\" every time I walk from one computer to the other.
+"""]]
diff --git a/doc/forum/Storing_git_repos_in_git-annex/comment_4_76ddbd27cc2f3785bb5aaebb0bb6e087._comment b/doc/forum/Storing_git_repos_in_git-annex/comment_4_76ddbd27cc2f3785bb5aaebb0bb6e087._comment
new file mode 100644
index 0000000000..9d0b024c1e
--- /dev/null
+++ b/doc/forum/Storing_git_repos_in_git-annex/comment_4_76ddbd27cc2f3785bb5aaebb0bb6e087._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="comment 4"
+ date="2014-05-17T00:41:04Z"
+ content="""
+I should have also mentioned, the network topology is an issue that git-annex helps solve.  When my computers are on the same LAN, they could obviously sync directly with each other using git.  But when they are not on the same network, or when one of them is not online, a transfer repo is needed.  Dropbox and git-annex make this simple by handling it for me.  
+
+But if I did all my syncing with git manually, it could end up being quite a mess.  If I took my laptop with me and left the house without syncing it first, I'd have to sync with my server on the Internet.  But if I forgot to push from my desktop computer before I left, the server would be out-of-date, and I'd be stuck.
+
+Dropbox handles this for me by automatically syncing as soon as I make changes.  git-annex does the same thing, but doesn't work with nested git repos.  But giving up the nested git repo would mean giving up version control of my files.  As a developer, you understand why that's not an option!  :)
+
+Again, this seems like a very natural problem to run into, and I don't understand why it is controversial to want git-annex to handle this the way Dropbox or other sync software (e.g. SpiderOak, Wuala) can.
+"""]]
diff --git a/doc/forum/Storing_git_repos_in_git-annex/comment_5_f9520cbc6669622aa342acad35581943._comment b/doc/forum/Storing_git_repos_in_git-annex/comment_5_f9520cbc6669622aa342acad35581943._comment
new file mode 100644
index 0000000000..95bf6a0d4d
--- /dev/null
+++ b/doc/forum/Storing_git_repos_in_git-annex/comment_5_f9520cbc6669622aa342acad35581943._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 5"
+ date="2014-05-18T12:55:47Z"
+ content="""
+My, 2 cents. I used to do the same keep my git repos in Dropbox. I do not push/pull to dropbox I just keep them in there so they sync between my machines. My use case is that I am in the middle of a change and I need to switch computers (home/office) I can continue where I left of on another machine otherwise you have to make wierd commits with broken code. So IMHO it is perfectly reasonable for a single person to keep his git repo in git-annex assuming I don't use it as a central repo where other people pull push.
+
+Plus one giant problem with git annex is that there is no way to revert a file in direct repo. It only sync and reverting to old files take a lot of effort (convert to indirect checkout commit save file to a temp location convert back to direct mode place the file back its place.) with a git repo in annex I can just use git to revert files.
+
+On the other hand, git likes to create a lot of small files and sync them can take a lot of time. annex copies on file at a time.
+
+That said, at one point I did experiment putting a git repo in annex for testing (using --git-dir option) it did work so it should not be that big of a deal to add the support.
+"""]]
diff --git a/doc/forum/Storing_git_repos_in_git-annex/comment_6_4a5ddb1980b9ba0378531a8d4fb93523._comment b/doc/forum/Storing_git_repos_in_git-annex/comment_6_4a5ddb1980b9ba0378531a8d4fb93523._comment
new file mode 100644
index 0000000000..d0a162c77a
--- /dev/null
+++ b/doc/forum/Storing_git_repos_in_git-annex/comment_6_4a5ddb1980b9ba0378531a8d4fb93523._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 6"
+ date="2022-01-13T18:19:31Z"
+ content="""
+The main problem is that the git developers stubbornly refuse to support nested git repos, so it's impossible for git-annex to support it. However I found a good workaround, see [[tips/using_nested_git_repositories/]].
+"""]]
diff --git a/doc/forum/Storing_git_repos_in_git-annex/comment_9_d5676400e7148b7d3408f2bdb3d54b7d._comment b/doc/forum/Storing_git_repos_in_git-annex/comment_9_d5676400e7148b7d3408f2bdb3d54b7d._comment
new file mode 100644
index 0000000000..23610fa715
--- /dev/null
+++ b/doc/forum/Storing_git_repos_in_git-annex/comment_9_d5676400e7148b7d3408f2bdb3d54b7d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaYy6kTuKAHmsa4BtGls2oqa42Jo2w2v0"
+ nickname="Pere"
+ subject="So, you are more clever than your users, isn't?"
+ date="2014-05-16T18:13:34Z"
+ content="""
+Joey, your comment is really disappointing. I also use Dropbox as a central git repo and it works great for me. Maybe you find this stupid, but there is a lot of people with good reasons to do so. I agree that this is your software project, thus you have the right not to support this use case, but you don't have the right to treat the users that want this feature as you did in your comment. Next time you do a new crowdfunding campaign, I not sure I'll be between the donors again.
+"""]]
diff --git a/doc/forum/Storing_uncontrolled_files_in_an_annex.mdwn b/doc/forum/Storing_uncontrolled_files_in_an_annex.mdwn
new file mode 100644
index 0000000000..e2111f0b95
--- /dev/null
+++ b/doc/forum/Storing_uncontrolled_files_in_an_annex.mdwn
@@ -0,0 +1,3 @@
+Is there a way to store a file in an annex repo without the assistant trying to commit it? My particular issue is that git annex watch tries to add my .thunderbird folder, and I don't want it in annex. Is that a supported use case?
+
+Also, for my better understanding, does watch keep track of what files it saw last time and only look for new things on startup? Or does it try to commit anything that's not already in git (whether symlink or not)?
diff --git a/doc/forum/Storing_uncontrolled_files_in_an_annex/comment_1_175645a90be0c79221c129308adf643e._comment b/doc/forum/Storing_uncontrolled_files_in_an_annex/comment_1_175645a90be0c79221c129308adf643e._comment
new file mode 100644
index 0000000000..2932efa399
--- /dev/null
+++ b/doc/forum/Storing_uncontrolled_files_in_an_annex/comment_1_175645a90be0c79221c129308adf643e._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 1"
+ date="2012-12-16T00:10:39Z"
+ content="""
+wow, are you git annexing your whole home directory?  that sounds extreme and problematic, since everything in git annex becomes read-only!!
+
+This how to make git annex ignore something though: make git ignore it in the first place.
+
+Stop the git assistant if it's running.
+
+create a file called \".gitignore\" in the root of your annex directory; add a line to that file for everything you want git (and therefore git annex) to ignore, e.g. \".thunderbird\"
+
+
+e.g.:
+
+    echo '.thunderbird' > '.gitignore'
+
+check that file into git:
+
+
+    git add .gitignore
+    git commit -m 'check in .gitignore'
+
+Now you should be able to start up git-annex again and have it ignore .thunderbird, or any other path you put in .gitignore
+"""]]
diff --git a/doc/forum/Storing_uncontrolled_files_in_an_annex/comment_2_d29f214eadfe3bfd098bbc3bcf07129a._comment b/doc/forum/Storing_uncontrolled_files_in_an_annex/comment_2_d29f214eadfe3bfd098bbc3bcf07129a._comment
new file mode 100644
index 0000000000..395f08d245
--- /dev/null
+++ b/doc/forum/Storing_uncontrolled_files_in_an_annex/comment_2_d29f214eadfe3bfd098bbc3bcf07129a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andy"
+ ip="108.92.50.62"
+ subject="Thanks!"
+ date="2012-12-16T00:31:09Z"
+ content="""
+That does what I needed. I'd forgotten about that. :)
+"""]]
diff --git a/doc/forum/Storing_uncontrolled_files_in_an_annex/comment_3_286b502e7906cca50e9e747db735bc88._comment b/doc/forum/Storing_uncontrolled_files_in_an_annex/comment_3_286b502e7906cca50e9e747db735bc88._comment
new file mode 100644
index 0000000000..f23854cbf3
--- /dev/null
+++ b/doc/forum/Storing_uncontrolled_files_in_an_annex/comment_3_286b502e7906cca50e9e747db735bc88._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.117"
+ subject="comment 3"
+ date="2012-12-17T16:32:31Z"
+ content="""
+AFAIK, the assistant does *not* currently honor .gitgnore completely. There are parts of it that do, and places where running git commands to check .gitignore would be very expensive, and so I've TODOed it for later, as I'll need to write my own .gitignore parser. 
+
+So, use caution..
+"""]]
diff --git a/doc/forum/Strategy_for_dealing_with_an_old_archive_drive.mdwn b/doc/forum/Strategy_for_dealing_with_an_old_archive_drive.mdwn
new file mode 100644
index 0000000000..6fa6158722
--- /dev/null
+++ b/doc/forum/Strategy_for_dealing_with_an_old_archive_drive.mdwn
@@ -0,0 +1,12 @@
+Hi there, I have an old archive drive with ~300k files, ~2 TB data. They're files that I would like to use in my work, but I've had to move them off my machine due to space. I periodically copy files off of the archive when I need to work with them. This of course is before I had even heard of `git-annex`.
+
+So now I'm wondering how I can start to integrate these files into my work. Two basic ideas I have are:
+
+1. `git-annex` the whole thing right away, and `git annex get` them onto my local machine as needed.
+2. Start an empty annex on the archive drive. Move files from the old archive location into the annex as needed.
+
+So basically I'm wondering between annexing the whole thing to start, or gradually building up the annex.
+
+I have no idea how well `git-annex` will work with 300k files / 2 TB data.
+
+How would you approach incorporating an old archive drive into a new annex?
diff --git a/doc/forum/Strategy_for_dealing_with_an_old_archive_drive/comment_1_7405e507dd15f207445be1e5099e02f3._comment b/doc/forum/Strategy_for_dealing_with_an_old_archive_drive/comment_1_7405e507dd15f207445be1e5099e02f3._comment
new file mode 100644
index 0000000000..213f660a68
--- /dev/null
+++ b/doc/forum/Strategy_for_dealing_with_an_old_archive_drive/comment_1_7405e507dd15f207445be1e5099e02f3._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-21T21:19:54Z"
+ content="""
+2TB of data is no problem. git does start to slow down as the number of
+files in a tree increases, with 200,000 or so where it might start to become
+noticable. With this many files, updating .git/index will need to write out
+something like 50mb of data to disk.
+
+(git has some "split index" stuff that is supposed to help with this, but
+I have not had the best experience with it.)
+
+Committing the files to a branch other than master might be a reasonable
+compromise. Then you can just copy the git-annex symlinks over to master as
+needed, or check out the branch from time to time.
+
+The main bottleneck doing that would be that the git-annex branch will also
+contain 1 location log file per annexed file, and writing to
+.git/annex/index will slow down a bit with so many files too. But,
+git-annex has a lot of optimisations around batching writes to its index that
+should make the impact minimal.
+"""]]
diff --git a/doc/forum/Strategy_for_dealing_with_an_old_archive_drive/comment_2_bafde6d22fdb5106c2e4a519e5945072._comment b/doc/forum/Strategy_for_dealing_with_an_old_archive_drive/comment_2_bafde6d22fdb5106c2e4a519e5945072._comment
new file mode 100644
index 0000000000..9d5cb19067
--- /dev/null
+++ b/doc/forum/Strategy_for_dealing_with_an_old_archive_drive/comment_2_bafde6d22fdb5106c2e4a519e5945072._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 2"
+ date="2021-04-21T22:33:55Z"
+ content="""
+> Committing the files to a branch other than master might be a reasonable compromise. Then you can just copy the git-annex symlinks over to master as needed, or check out the branch from time to time.
+
+I think that could work nicely. I do like the idea of having my files annexed, and distributing them across machines that way, so this strikes me as a good compromise.
+
+Thank you for the idea!
+"""]]
diff --git a/doc/forum/Structure_needs_cleaning_git-annex__58___fd__58__15__58___hGetLine__58___end_of_file.mdwn b/doc/forum/Structure_needs_cleaning_git-annex__58___fd__58__15__58___hGetLine__58___end_of_file.mdwn
new file mode 100644
index 0000000000..0621f303b4
--- /dev/null
+++ b/doc/forum/Structure_needs_cleaning_git-annex__58___fd__58__15__58___hGetLine__58___end_of_file.mdwn
@@ -0,0 +1,24 @@
+I get this error after a hard reboot of the device when running git annex sync
+
+
+    fatal: Cannot open '/media/usbplatte/Podcasts/.git/annex/journal/e2f_ae4_SHA256E-s8388114--55d0a8881d06e24584ad9a94a6c5a369ea301309e0626497ea8c67bc65c3d0b2.mp3.log.web': Die Struktur muss bereinigt werden
+
+    git-annex: fd:15: hGetLine: end of file
+    fatal: Cannot open '/media/usbplatte/Podcasts/.git/annex/journal/e2f_ae4_SHA256E-s8388114--55d0a8881d06e24584ad9a94a6c5a369ea301309e0626497ea8c67bc65c3d0b2.mp3.log.web': Die Struktur muss bereinigt werden
+
+    git-annex: fd:15: hGetLine: end of file
+
+I ran 
+
+    git annex fsck
+
+and
+
+    git annex repair
+
+Both commands finished with Status Ok.
+
+How can I save the repo?
+
+TIA
+juh
diff --git a/doc/forum/Structure_needs_cleaning_git-annex__58___fd__58__15__58___hGetLine__58___end_of_file/comment_1_7bcc0111015985bde398a2a1a02b28ba._comment b/doc/forum/Structure_needs_cleaning_git-annex__58___fd__58__15__58___hGetLine__58___end_of_file/comment_1_7bcc0111015985bde398a2a1a02b28ba._comment
new file mode 100644
index 0000000000..02c18f876f
--- /dev/null
+++ b/doc/forum/Structure_needs_cleaning_git-annex__58___fd__58__15__58___hGetLine__58___end_of_file/comment_1_7bcc0111015985bde398a2a1a02b28ba._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="juh"
+ subject="SOLVED"
+ date="2016-06-06T15:45:12Z"
+ content="""
+I solved the problem with fsck the disk.
+"""]]
diff --git a/doc/forum/Structure_needs_cleaning_git-annex__58___fd__58__15__58___hGetLine__58___end_of_file/comment_2_b1dfc6168bb7127312d3e06cc0939b8d._comment b/doc/forum/Structure_needs_cleaning_git-annex__58___fd__58__15__58___hGetLine__58___end_of_file/comment_2_b1dfc6168bb7127312d3e06cc0939b8d._comment
new file mode 100644
index 0000000000..9fbac07dd9
--- /dev/null
+++ b/doc/forum/Structure_needs_cleaning_git-annex__58___fd__58__15__58___hGetLine__58___end_of_file/comment_2_b1dfc6168bb7127312d3e06cc0939b8d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-06-09T19:19:07Z"
+ content="""
+	LANG=de_DE.UTF-8 errno -s 'Die Struktur muss bereinigt werden'
+	EUCLEAN 117 Die Struktur muss bereinigt werden
+
+This seems to be a failure mode of XFS filesystems, where when it needs to
+be fscked, it throws EUCLEAN.
+"""]]
diff --git a/doc/forum/Stuck_in_a_bad_state.mdwn b/doc/forum/Stuck_in_a_bad_state.mdwn
new file mode 100644
index 0000000000..9b83f26888
--- /dev/null
+++ b/doc/forum/Stuck_in_a_bad_state.mdwn
@@ -0,0 +1,10 @@
+So I managed to muck stuff up pretty bad with git-annex assistant and wondering if there is a reasonable way to fix the situation without blowing everything away and starting over at this point.  So my setup is kind of laid out like this:
+I have the main annex folder in my home folder at this location: /home/<username>/annex  I have a full backup on a separate drive on the same system which is mounted to /mnt/store and there is a sym link to it in my home folder so ~/store and annex folder goes to ~/store/annex on that drive.  I sync with one other computer that comes and goes online on the local folder (I don't use a transfer repository).  Then I have an rsync.net account that is also set to full backup, I originally setup annex to use this with a self generated key that it would keep in git and it had synced and everything seemed good.  I later determined that I would rather use my own encryption key that I have backed up in a different way.  It seems the only way to change that is to delete the rsync.net remote and re-add it with the key that I want to use.  So I told it to delete it in the web-gui, it has been stuck cleaning out for about a month now.  A thread keeps dying and I keep restarting it according to the gui.  There is an error in the logs, but it looks like it is trying to connect to both the computer that isn't always up and rsync.net and dying with it:
+
+```
+[2016-07-20 09:40:26.563762726] NetWatcherFallback: Syncing with 192.168.1.118_annex, rsync.net_annex 
+ssh: connect to host 192.168.1.118 port 22: No route to host
+fatal: Could not read from remote repository.
+```
+
+So at this point, I am contemplating just copying all the files out of the annex folders and deleting all the annex stuff and configuration and all the stores and starting over basically unless there is another approach that I can kill the rsync.net annex remote, delete the stuff directly on rsync, setup a new rsync.net remote.
diff --git a/doc/forum/Stupid_mistake__58___recoverable__63__.mdwn b/doc/forum/Stupid_mistake__58___recoverable__63__.mdwn
new file mode 100644
index 0000000000..8e25d70812
--- /dev/null
+++ b/doc/forum/Stupid_mistake__58___recoverable__63__.mdwn
@@ -0,0 +1,31 @@
+Hi,
+
+I was a bit hasty the other day and did something stupid.  I
+added a new folder to git annex.  Something like
+
+    git annex add my-important folder
+
+my-important folder contains a lot of files and it took a couple
+of minutes to add.  When I then tried to do
+
+    git commit -am 'added files'
+
+per the walkthrough I got an error (9, as I recall).  I thought
+I'd added too many files or something so I wanted to start over
+and perhaps I didn't fully understand the mechanisms of annex I
+did the following
+
+    git reset --hard .
+
+Unfortunately, did replaced my files with a bunch of symlinks,
+rather than making git annex forget and go back to the previous
+stage as I had hoped.
+
+I have managed to recover most of my files from backup, but some
+of them I still can't recover.  Is there any way back?  It seems
+I still have the files in my git folder.
+
+Thanks,
+Rasmus
+
+PS: Sorry, I shouldn't have made this text rather than Markdown.
diff --git a/doc/forum/Stupid_mistake__58___recoverable__63__/comment_1_00ceb3a5e37825c4bbc806f532893706._comment b/doc/forum/Stupid_mistake__58___recoverable__63__/comment_1_00ceb3a5e37825c4bbc806f532893706._comment
new file mode 100644
index 0000000000..ebc8073f7a
--- /dev/null
+++ b/doc/forum/Stupid_mistake__58___recoverable__63__/comment_1_00ceb3a5e37825c4bbc806f532893706._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-01T18:24:20Z"
+ content="""
+The file contents are still there in `.git/annex/objects/`. 
+
+When I run `git reset --hard`, it deletes any files that have been added, but not committed. You say you still have symlinks to the content. If so, you can just `git add` the symlinks and be back how git-annex wants things to be.
+
+If, instead, you are missing the symlinks, then since you never committed the symlinks to git, there is no record anywhere in git of the filenames that go with the file contents. 
+
+What you can do is ask git-annex to put back symlinks to the file contents:
+
+<pre>
+git annex unused
+git annex addunused 1-10000
+</pre>
+
+This will make you have a bunch of files in the repository with names starting with \"unused\". You can then rename them manually.
+
+BTW, I would of course be interested in any error message from `git commit`.
+"""]]
diff --git a/doc/forum/Stupid_mistake__58___recoverable__63__/comment_2_cbedc29678d9b6af3b3c0bb1915d2391._comment b/doc/forum/Stupid_mistake__58___recoverable__63__/comment_2_cbedc29678d9b6af3b3c0bb1915d2391._comment
new file mode 100644
index 0000000000..f552cfb186
--- /dev/null
+++ b/doc/forum/Stupid_mistake__58___recoverable__63__/comment_2_cbedc29678d9b6af3b3c0bb1915d2391._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Rasmus"
+ ip="213.120.148.111"
+ subject="comment 2"
+ date="2013-04-01T23:23:55Z"
+ content="""
+Joey,
+
+Thanks for your useful tips and for providing this software.  It seems incredibly powerful and useful.  I made a copy of the folder which I messed up.  I will try the tips and report back (I'm on the road right now).
+
+The other day all the Haskell deps worked out and I managed to build git annex.  Hopefully, this will give more reliable results as it seemed that some of my bugs were caused by the 32bit prebuild on 64bit.  If I succeed in recreating my files I will try to recreate the error :)
+"""]]
diff --git a/doc/forum/Stupid_mistake__58___recoverable__63__/comment_3_86aa4d92a1330811862da1ba568b3037._comment b/doc/forum/Stupid_mistake__58___recoverable__63__/comment_3_86aa4d92a1330811862da1ba568b3037._comment
new file mode 100644
index 0000000000..b642cde987
--- /dev/null
+++ b/doc/forum/Stupid_mistake__58___recoverable__63__/comment_3_86aa4d92a1330811862da1ba568b3037._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="Rasmus"
+ ip="213.120.148.111"
+ subject="comment 3"
+ date="2013-04-02T23:25:45Z"
+ content="""
+Joey,
+
+Sorry for asking again, but I haven't been able to resolve this using the symlinks.
+
+Consider this file 
+
+    ElgarCEH.pdf -> ../.git/annex/objects/g6/q8/SHA256E-759787--3ec5f8d64cc4f84dec74ed7f0f7a640b3e672a03faf0f5fc3daf0b823d596f03.pdf/SHA256E-759787--3ec5f8d64cc4f84dec74ed7f0f7a640b3e672a03faf0f5fc3daf0b823d596f03.pdf
+
+The file that the symlink points to doesn't exist.  I'm not sure it should.  The file with {.map,.cahce} extensions does exist, in this case 
+
+    sh>ls ../.git/annex/objects/g6/q8/SHA256E-s759787--3ec5f8d64cc4f84dec74ed7f0f7a640b3e672a03faf0f5fc3daf0b823d596f03.pdf/
+       SHA256E-s759787--3ec5f8d64cc4f84dec74ed7f0f7a640b3e672a03faf0f5fc3daf0b823d596f03.pdf.cache
+       SHA256E-s759787--3ec5f8d64cc4f84dec74ed7f0f7a640b3e672a03faf0f5fc3daf0b823d596f03.pdf.map
+
+The content of the .cache file is 
+
+    1703824 411810 1350480334
+
+and the content of the .map file is 
+
+    documents/ElgarCEH.pdf
+
+However, for all of the following
+
+    git add ElgarCEH.pdf
+    git add --force ElgarCEH.pdf
+    git annex add ElgarCEH.pdf
+
+the files are not staged, and I get the message usual
+
+    no changes added to commit.
+
+with `git log`.
+
+So do I need to something more in order to get `git` to add my symlinks?
+"""]]
diff --git a/doc/forum/Stupid_mistake__58___recoverable__63__/comment_4_6d15bf8a3c3c27cc92957070161675a9._comment b/doc/forum/Stupid_mistake__58___recoverable__63__/comment_4_6d15bf8a3c3c27cc92957070161675a9._comment
new file mode 100644
index 0000000000..97a4cd0db1
--- /dev/null
+++ b/doc/forum/Stupid_mistake__58___recoverable__63__/comment_4_6d15bf8a3c3c27cc92957070161675a9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-04-02T23:39:48Z"
+ content="""
+If you `git add` a file and `git commit` says \"no changes added to commit\", what would you think would be the reason?
+
+I'd think it was because the file was already committed to git. So that must be the case with your symlink.
+
+You seem to have told git-annex to do something to the content of that file. You could use `git annex whereis` to find where it is, or `git annex get` to get it. (Assuming you have not used `git annex drop --force` on the file to nuke its content earlier.)
+"""]]
diff --git a/doc/forum/Stupid_mistake__58___recoverable__63__/comment_5_f836b9b1d03d94c49e3798961790b2ba._comment b/doc/forum/Stupid_mistake__58___recoverable__63__/comment_5_f836b9b1d03d94c49e3798961790b2ba._comment
new file mode 100644
index 0000000000..d28c247e1f
--- /dev/null
+++ b/doc/forum/Stupid_mistake__58___recoverable__63__/comment_5_f836b9b1d03d94c49e3798961790b2ba._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="Rasmus"
+ ip="213.120.148.111"
+ subject="comment 5"
+ date="2013-04-03T00:45:05Z"
+ content="""
+> [links not being added].
+Right.  Obliviously.  Sorry.
+
+
+I think the problem is more severe as all of the files have somehow ended up in the .git/objects folder.  I have no idea how, but I have been unsuccessful with both methods (the second methods gives me 
+    
+    getFileStatus: does not exist (No such file or directory)
+
+which I guess is related to the fact that my files somehow ended up in the git objects folder rather than the git annex objects folder.
+
+I appreciated the help.
+
+Cheers,
+Rasmus
+"""]]
diff --git a/doc/forum/Submodule_.git_not_converted_to_symlink.mdwn b/doc/forum/Submodule_.git_not_converted_to_symlink.mdwn
new file mode 100644
index 0000000000..52ecfe53e2
--- /dev/null
+++ b/doc/forum/Submodule_.git_not_converted_to_symlink.mdwn
@@ -0,0 +1,13 @@
+According to [this page](https://git-annex.branchable.com/submodules/), `git-annex` should automatically convert the `.git` file of submodules into a symlink.  However, I have a repository where on some machines, this doesn't happen.
+
+    $ file .git
+    .git: ASCII text
+
+
+    $ git-annex info
+    git-annex: First run: git-annex init
+
+    $ file .git
+    .git: ASCII text
+
+Even more mysteriously, it works on some *other* checkouts of the repository *on the same machine*.
diff --git a/doc/forum/Submodule_.git_not_converted_to_symlink/comment_1_5d95da69235eb3c6b60227544380a4e8._comment b/doc/forum/Submodule_.git_not_converted_to_symlink/comment_1_5d95da69235eb3c6b60227544380a4e8._comment
new file mode 100644
index 0000000000..841d1e146d
--- /dev/null
+++ b/doc/forum/Submodule_.git_not_converted_to_symlink/comment_1_5d95da69235eb3c6b60227544380a4e8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="athas@60e56fd42a78bbbce444d175865ce4d66ba1a779"
+ nickname="athas"
+ avatar="http://cdn.libravatar.org/avatar/f6ddda1fabf459f90ca590f9499033c4"
+ subject="Update"
+ date="2021-10-15T16:37:34Z"
+ content="""
+Ignore the remark about different behaviour on the same machine; I was looking at the wrong thing.
+
+It does appear that GitHub Actions does not correctly fetch the `annex` directory for submodules, which must be the source of the error.
+"""]]
diff --git a/doc/forum/Submodule_.git_not_converted_to_symlink/comment_2_351c58b21d36770729c52991901d668c._comment b/doc/forum/Submodule_.git_not_converted_to_symlink/comment_2_351c58b21d36770729c52991901d668c._comment
new file mode 100644
index 0000000000..1a9bc12033
--- /dev/null
+++ b/doc/forum/Submodule_.git_not_converted_to_symlink/comment_2_351c58b21d36770729c52991901d668c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-10-15T17:49:00Z"
+ content="""
+The conversion is made when you run `git annex init`, which you have
+apparently not done..
+
+If the git-annex branch were available, it would automatically initialize
+and convert, so you may be on to something if you meant to say it did not
+fetch the git-annex branch.
+"""]]
diff --git a/doc/forum/Submodule_.git_not_converted_to_symlink/comment_3_636fe0ff273cd8987168e3095929aa7f._comment b/doc/forum/Submodule_.git_not_converted_to_symlink/comment_3_636fe0ff273cd8987168e3095929aa7f._comment
new file mode 100644
index 0000000000..ab1ae150c3
--- /dev/null
+++ b/doc/forum/Submodule_.git_not_converted_to_symlink/comment_3_636fe0ff273cd8987168e3095929aa7f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="athas@60e56fd42a78bbbce444d175865ce4d66ba1a779"
+ nickname="athas"
+ avatar="http://cdn.libravatar.org/avatar/f6ddda1fabf459f90ca590f9499033c4"
+ subject="GitHub Actions"
+ date="2021-10-15T20:53:06Z"
+ content="""
+It appears the `checkout` action on GitHub Actions mangles submodules that use `git-annex`.  The solution is to ask the checkout action to do a deep clone:
+
+    - uses: actions/checkout@v2
+      with:
+        submodules: recursive # for git-annex to work.
+        fetch-depth: 0        #
+
+"""]]
diff --git a/doc/forum/Suggestion__58___Put_ssh_server_back_into_android_version.mdwn b/doc/forum/Suggestion__58___Put_ssh_server_back_into_android_version.mdwn
new file mode 100644
index 0000000000..1f8730514b
--- /dev/null
+++ b/doc/forum/Suggestion__58___Put_ssh_server_back_into_android_version.mdwn
@@ -0,0 +1,9 @@
+Hi!
+
+Just tried various android ssh servers which do work, but have no access to the command line tools shipped with git annex.
+
+From what I gather from the planning docs, sshd was stripped from the android tools to save space. If this were the case, it (naively) seems to me it would have to be simple to re-enable.
+
+Rationale: It would make it super convenient to use command line git annex on my phone alongside the assistant, through letting me type on my desktop. Not to mention that the command line tools shipped with git annex are by far the best around for android work.
+
+Carlo
diff --git a/doc/forum/Suggestion__58___Put_ssh_server_back_into_android_version/comment_1_5c2f376a82458c6387560355940419d3._comment b/doc/forum/Suggestion__58___Put_ssh_server_back_into_android_version/comment_1_5c2f376a82458c6387560355940419d3._comment
new file mode 100644
index 0000000000..9a39a2e4c9
--- /dev/null
+++ b/doc/forum/Suggestion__58___Put_ssh_server_back_into_android_version/comment_1_5c2f376a82458c6387560355940419d3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-02T19:42:13Z"
+ content="""
+sshd was removed from the bundle because it's not needed for git-annex to be used on Android, and it would be very complicated to get it to work. (And would require rooting the device at least for port 22 and probably also since sshd needs to run as root generally.)
+
+If there are android ssh servers that let you choose which user to log in as, you could log in as the app_NN user corresponding to the git-annex android app, and have all the tools available, once you ran runshell. I belive there's also an equivilant to su on android that lets you change to an app_NN user, although you probably already need root.
+
+I think it's more usual to use adb in these situations.
+"""]]
diff --git a/doc/forum/Suggestion__58___Put_ssh_server_back_into_android_version/comment_2_6321dec0b2f22f841f3cb986e063113f._comment b/doc/forum/Suggestion__58___Put_ssh_server_back_into_android_version/comment_2_6321dec0b2f22f841f3cb986e063113f._comment
new file mode 100644
index 0000000000..b1ce5a1a5b
--- /dev/null
+++ b/doc/forum/Suggestion__58___Put_ssh_server_back_into_android_version/comment_2_6321dec0b2f22f841f3cb986e063113f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="comment 2"
+ date="2013-11-03T09:48:53Z"
+ content="""
+Ah, the \"very complicated to get it to work\" part is what I didn't know, thanks for explaining and or the tips.
+"""]]
diff --git a/doc/forum/Suggestion__58___downgrade_error.mdwn b/doc/forum/Suggestion__58___downgrade_error.mdwn
new file mode 100644
index 0000000000..7cf5af54a0
--- /dev/null
+++ b/doc/forum/Suggestion__58___downgrade_error.mdwn
@@ -0,0 +1,5 @@
+I have a git-annex repository in a portable hard drive. Some times I plug it into one computer, others I plug it into another one. So that it is reachable in both situations, I have it also added as an ssh remote, using the same `annex-uuid`. This works well, but now I always get a fatal error `fatal: Could not read from remote repository.` when I have the same unit plugged in.
+
+May I suggest that this be downgraded to a "warning" or an "info"? After all, the same repository (annex-uuid) was discovered and processed, but at another location (url). It does not need to sound so cataclysmic. Perhaps it does not even need to try the ssh if it found the same repository at a "cheaper" location; and if it is not found here, only declare a failure if it was unavailable at another url.
+
+Thank you for your time (and your fine work).
diff --git a/doc/forum/Symantec_endpoint_protection_raises_WS.Reputation.1_on_git-annex_windows_installer.mdwn b/doc/forum/Symantec_endpoint_protection_raises_WS.Reputation.1_on_git-annex_windows_installer.mdwn
new file mode 100644
index 0000000000..16be75923e
--- /dev/null
+++ b/doc/forum/Symantec_endpoint_protection_raises_WS.Reputation.1_on_git-annex_windows_installer.mdwn
@@ -0,0 +1,13 @@
+Hello,
+
+I downloaded git-annex-installer.exe from https://downloads.kitenet.net/git-annex/windows/current/git-annex-installer.exe . 
+When I try to run it on my work windows 7 64-bit laptop, Symantec Encpoint Protection complains with a WS.Reputation.1 flag that the file has a low reputation and quarantines the file. 
+
+I searched online trying to find why git-annex is flagged as such by Symantec but was unable to find anything.
+I prefer not to build from source if possible as this is my work laptop and it would require that I install Haskell, MingW, and Cygwin. 
+
+Any pointers/suggestions would be greatly appreciated.
+
+Thanks,
+
+Ahmad
diff --git a/doc/forum/Symantec_endpoint_protection_raises_WS.Reputation.1_on_git-annex_windows_installer/comment_1_3b1da8ce0dcf43efcdc9b264ef21fb3a._comment b/doc/forum/Symantec_endpoint_protection_raises_WS.Reputation.1_on_git-annex_windows_installer/comment_1_3b1da8ce0dcf43efcdc9b264ef21fb3a._comment
new file mode 100644
index 0000000000..7cbed378f5
--- /dev/null
+++ b/doc/forum/Symantec_endpoint_protection_raises_WS.Reputation.1_on_git-annex_windows_installer/comment_1_3b1da8ce0dcf43efcdc9b264ef21fb3a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-16T17:29:39Z"
+ content="""
+Does "low reputation" mean "few users", or "we have a reason to distrust
+this"? In the former case, I obviously can't do anything, and in the latter
+case, I'd need to know what problem they think it has.
+"""]]
diff --git a/doc/forum/Symlink_points_to_old_version.mdwn b/doc/forum/Symlink_points_to_old_version.mdwn
new file mode 100644
index 0000000000..257a7d5aa3
--- /dev/null
+++ b/doc/forum/Symlink_points_to_old_version.mdwn
@@ -0,0 +1,13 @@
+Hello everyone,
+
+I have some PDF documents in a git annex repository. I appended a page to (several) of these PDF documents the following way:
+
+- `git annex edit file.pdf`
+- Append page to file.pdf
+- `git annex add file.pdf`
+- `git commit`
+
+If I now look at file.pdf it will not have the appended page. But if do `git annex edit file.pdf` again I will get the version with the appended page. `git annex add file.pdf` and the page "disappears" again. Anyone got any tips on how to solve this "mystery"?
+
+All the best,
+Per
diff --git a/doc/forum/Symlink_points_to_old_version/comment_1_c9c777333a01865e95332ea7ff1e6cf7._comment b/doc/forum/Symlink_points_to_old_version/comment_1_c9c777333a01865e95332ea7ff1e6cf7._comment
new file mode 100644
index 0000000000..febe4c9a8b
--- /dev/null
+++ b/doc/forum/Symlink_points_to_old_version/comment_1_c9c777333a01865e95332ea7ff1e6cf7._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-13T15:46:00Z"
+ content="""
+The symlink should point to the new version, unless git-annex is catastropically
+broken, and this can be easily demonstrated that git-annex is not catastropically
+broken:
+
+	joey@darkstar:~/tmp/demo>cat foo.pdf 
+	original pdf
+	joey@darkstar:~/tmp/demo>git annex edit foo.pdf
+	unlock foo.pdf (copying...) ok
+	joey@darkstar:~/tmp/demo>echo "added page" >> foo.pdf 
+	joey@darkstar:~/tmp/demo>git annex add foo.pdf
+	add foo.pdf ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/demo>git commit -m foo
+	[master 8d7f117] foo
+	 1 file changed, 1 insertion(+), 1 deletion(-)
+	joey@darkstar:~/tmp/demo>cat foo.pdf 
+	original pdf
+	added page
+
+So, what's really going on for you to see what you see when you look at the
+pdf? My guess is that your pdf editor/viewer is doing something bad/smart when
+it encounters the symlink. Perhaps it's loading an old cached version of the
+pdf rather than following the symlink or something.
+
+When you use `git annex edit`, the file stops being a symlink, and
+so whatever smart/bad behavior is causing the problem is avoided.
+
+If this is the case, switching to direct mode would avoid the problem.
+(`git annex direct`)
+
+If I were using a program and verfied that it has such bad/smart behavior
+on symlinks, I'd complain vigorously to its creators; it should't matter
+if a program is asked to open a symlink or not, it should behave the same either way.
+Unfortunately, it seems that some programs go out of their way to get
+this wrong and all we can do about it is filed bugs and/or use direct mode.
+"""]]
diff --git a/doc/forum/Symlink_points_to_old_version/comment_2_9bf097d27a64743a420cba0136787165._comment b/doc/forum/Symlink_points_to_old_version/comment_2_9bf097d27a64743a420cba0136787165._comment
new file mode 100644
index 0000000000..7563a1ed55
--- /dev/null
+++ b/doc/forum/Symlink_points_to_old_version/comment_2_9bf097d27a64743a420cba0136787165._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/StKYI.ZuofVB3xNCCzjJo.V7Fg--#11600"
+ nickname="Per K"
+ subject="comment 2"
+ date="2015-05-14T09:31:09Z"
+ content="""
+Thank you for the response. Sorry I didn't think of the possibility that the PDF reader could be the problem. I have done the same operation many times and never encountered this problem before though. The culprit is Apple's Preview.app. It now shows the new version and to my knowledge I haven't done anything in the meantime. Guess it is just time passed that has fixed \"the problem\".
+
+Thank you!
+"""]]
diff --git a/doc/forum/Sync_All_Missing_Content__63__.mdwn b/doc/forum/Sync_All_Missing_Content__63__.mdwn
new file mode 100644
index 0000000000..326afa3038
--- /dev/null
+++ b/doc/forum/Sync_All_Missing_Content__63__.mdwn
@@ -0,0 +1 @@
+I have a git annex repo I'm using to sync to a couple of computers, plus backup to Glacier.  git annex sync --content normally works fine, but recently I've added some large files with git annex that also have multiple versions, and I see that when I do git annex sync --content, only the current version of the file content gets transferred.  I see that the --all option exists as well, which seems like it should do what I need, but when I run git annex sync --content --all it appears to start trying to sync _all_ content, even if it's already present on both machines.  And if I try to use it on my glacier remote, it seems to be trying to pull from Glacier as well, which of course fails because you can't immediately access a Glacier file.  Is there any combination of options that can do what I'm looking for here, to transfer all content but only a delta between what's present on the current machine and the remote?
diff --git a/doc/forum/Sync_All_Missing_Content__63__/comment_1_fbe27e8dc9dd85e860b3382f99426c14._comment b/doc/forum/Sync_All_Missing_Content__63__/comment_1_fbe27e8dc9dd85e860b3382f99426c14._comment
new file mode 100644
index 0000000000..a2e7974150
--- /dev/null
+++ b/doc/forum/Sync_All_Missing_Content__63__/comment_1_fbe27e8dc9dd85e860b3382f99426c14._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 1"
+ date="2018-03-23T18:41:20Z"
+ content="""
+Did you set a [preferred content](https://git-annex.branchable.com/git-annex-preferred-content/) for this remote? `git annex wanted <remote> anything` should tell git annex to sync all file versions when running `git annex sync --content`.
+
+Or (better) use the backup group:
+
+
+    git annex wanted <remote> standard
+    git annex group <remote> backup
+
+
+
+"""]]
diff --git a/doc/forum/Sync_All_Missing_Content__63__/comment_2_d77b7f56dcb8bf384f5a19bf54fe629e._comment b/doc/forum/Sync_All_Missing_Content__63__/comment_2_d77b7f56dcb8bf384f5a19bf54fe629e._comment
new file mode 100644
index 0000000000..040576f425
--- /dev/null
+++ b/doc/forum/Sync_All_Missing_Content__63__/comment_2_d77b7f56dcb8bf384f5a19bf54fe629e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="misc@e661ec6eb62aa0134e4ac4ca16f98640acf5c627"
+ nickname="misc"
+ avatar="http://cdn.libravatar.org/avatar/78f317f1cdf5dfdaa295207a6dbf1311"
+ subject="comment 2"
+ date="2018-03-27T05:53:43Z"
+ content="""
+That's exactly what I needed, thanks!
+"""]]
diff --git a/doc/forum/Sync_Enabled__47__Disabled_Status.mdwn b/doc/forum/Sync_Enabled__47__Disabled_Status.mdwn
new file mode 100644
index 0000000000..196a67899d
--- /dev/null
+++ b/doc/forum/Sync_Enabled__47__Disabled_Status.mdwn
@@ -0,0 +1 @@
+In the webapp I can see which repos have syncing enabled or disabled, and toggle the property by clicking the current status. How can I do this in the terminal? I want to be able to see the current syncing status of the repository, and to change it, without opening the webapp.
diff --git a/doc/forum/Sync_Enabled__47__Disabled_Status/comment_1_cfe98bdd50cea0fd0e36a42892262084._comment b/doc/forum/Sync_Enabled__47__Disabled_Status/comment_1_cfe98bdd50cea0fd0e36a42892262084._comment
new file mode 100644
index 0000000000..2649c7d575
--- /dev/null
+++ b/doc/forum/Sync_Enabled__47__Disabled_Status/comment_1_cfe98bdd50cea0fd0e36a42892262084._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-04-04T16:18:11Z"
+ content="""
+The webapp is changing the git configuration 
+"remote.<name>.annex-sync" to false to disable and back to true to enable.
+
+You can use `git config` to change that yourself. 
+
+However, if you have the assistant running in the background and make such
+a git configuration change, it won't notice the change, and will keep
+running with the old configuration. So you'll want to restart it by running
+`git annex assistant --stop; git annex assistant`
+"""]]
diff --git a/doc/forum/Sync_files_from_remote_to_remote.mdwn b/doc/forum/Sync_files_from_remote_to_remote.mdwn
new file mode 100644
index 0000000000..a723c33f33
--- /dev/null
+++ b/doc/forum/Sync_files_from_remote_to_remote.mdwn
@@ -0,0 +1,5 @@
+Not sure if this use case is supported, but I have the following setup - I use git-annex to store my Lightroom catalog and photos. My local machine does not contain all files, `.mov` files for example are excluded via the preferred content mechanism. The full backup is on a remote server using ssh.
+
+Now I want to create another copy of the data (encrypted) from my local machine to a USB stick or similar. I found that the locally excluded files are not synced. In order to copy all the data I first need to change the preferred content config, execute `git-annex get` to fetch the data, then copy via `git-annex sync myusbremote --content`, then change the local preferred content pattern, then run `git annex drop --auto` to delete the local unwanted content again.
+
+I was wondering if there's a way to sync from one remote to another, without storing any data locallly ? Something like `git-annex sync --from ... --to ...`.
diff --git a/doc/forum/Sync_files_from_remote_to_remote/comment_1_c5247657a5b3cd68fd55112efe97ef99._comment b/doc/forum/Sync_files_from_remote_to_remote/comment_1_c5247657a5b3cd68fd55112efe97ef99._comment
new file mode 100644
index 0000000000..66ee6ce6ae
--- /dev/null
+++ b/doc/forum/Sync_files_from_remote_to_remote/comment_1_c5247657a5b3cd68fd55112efe97ef99._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica Semrick"
+ subject="assistant or cron"
+ date="2015-01-11T04:00:04Z"
+ content="""
+I'd either (1) run the assistant on your server or (2) write a simple cron script that runs git-annex sync --content on the server.
+"""]]
diff --git a/doc/forum/Sync_files_from_remote_to_remote/comment_2_634e399d21271f26f7f77c15c5fb132b._comment b/doc/forum/Sync_files_from_remote_to_remote/comment_2_634e399d21271f26f7f77c15c5fb132b._comment
new file mode 100644
index 0000000000..4a0038f9d4
--- /dev/null
+++ b/doc/forum/Sync_files_from_remote_to_remote/comment_2_634e399d21271f26f7f77c15c5fb132b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Jan"
+ subject="comment 2"
+ date="2015-01-11T08:54:52Z"
+ content="""
+this would work, but the server is on a remote machine and the USB drive I want to sync to is connected to my local machine.
+"""]]
diff --git a/doc/forum/Sync_files_from_remote_to_remote/comment_3_b89701582b40e2c337a1a49733877210._comment b/doc/forum/Sync_files_from_remote_to_remote/comment_3_b89701582b40e2c337a1a49733877210._comment
new file mode 100644
index 0000000000..73c9cc0bcd
--- /dev/null
+++ b/doc/forum/Sync_files_from_remote_to_remote/comment_3_b89701582b40e2c337a1a49733877210._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnm19dBCRphmtjXfopm_NpvnRwz-qIJ2Tw"
+ nickname="Remi"
+ subject="May be use a prefered content expression about what is in the usb stick"
+ date="2015-01-11T09:14:47Z"
+ content="""
+Is there a full git repos on the usb stick? if yes You could add a remote on it and run `git annex --content` from there.
+
+You could also try to change the preferred content of your local machine to include something like \"--not --in=usb\". With this you local repos will download file not in the usb stick, copy it to the usb stick and then remove it from the local repos. (I didn't check exactly the syntax of the preferred content, so my expression could be incorrect, but I hope you get the idea)
+"""]]
diff --git a/doc/forum/Sync_files_from_remote_to_remote/comment_4_b3ad93e032c3c9d2312970711540bf92._comment b/doc/forum/Sync_files_from_remote_to_remote/comment_4_b3ad93e032c3c9d2312970711540bf92._comment
new file mode 100644
index 0000000000..ad730a3ead
--- /dev/null
+++ b/doc/forum/Sync_files_from_remote_to_remote/comment_4_b3ad93e032c3c9d2312970711540bf92._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Jan"
+ subject="comment 4"
+ date="2015-01-13T09:35:10Z"
+ content="""
+Thanks for your answers. But I want to encrypt the content, so initialising a repo on the stick is not a possibility if I understand it correctly. And wouldn't `--not --in=usb` exclude a lot of content I actually want ? (Haven't tried it yet)
+"""]]
diff --git a/doc/forum/Sync_files_from_remote_to_remote/comment_5_bdf293d30692311983d0586231535bd4._comment b/doc/forum/Sync_files_from_remote_to_remote/comment_5_bdf293d30692311983d0586231535bd4._comment
new file mode 100644
index 0000000000..4ea668070c
--- /dev/null
+++ b/doc/forum/Sync_files_from_remote_to_remote/comment_5_bdf293d30692311983d0586231535bd4._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnm19dBCRphmtjXfopm_NpvnRwz-qIJ2Tw"
+ nickname="Remi"
+ subject="comment 5"
+ date="2015-01-13T12:45:47Z"
+ content="""
+Well my idea wasn't to have only this in the preferred content. You
+can use \"or\" expression.
+
+That said, I've just check the manual, and it seem that there is no --in for
+preferred content... But you could add your usb repos say to the
+archival group (git annex group usb archival), Then use something like
+like `\"include=* and ( exclude=*.mov or not inallgroup=archival )\"`
+(this is untested, but I hope you get the idea).
+
+With such a preferred content, you local repository should get (and
+keep) the .mov not in usb, and should drop them when they are send
+there.
+
+"""]]
diff --git a/doc/forum/Sync_files_from_remote_to_remote/comment_6_fda62d735035213f2a0b5b2fc95991ab._comment b/doc/forum/Sync_files_from_remote_to_remote/comment_6_fda62d735035213f2a0b5b2fc95991ab._comment
new file mode 100644
index 0000000000..9ab809aea4
--- /dev/null
+++ b/doc/forum/Sync_files_from_remote_to_remote/comment_6_fda62d735035213f2a0b5b2fc95991ab._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2015-01-20T18:51:06Z"
+ content="""
+Remi's idea of using [[preferred_content]] can be made to work.
+
+There's no `git annex copy --from A --to B`. It would need to locally spool
+each file into the current repo, and being an unusual corner case has not
+seemed worth doing so far.
+"""]]
diff --git a/doc/forum/Sync_files_from_remote_to_remote/comment_7_77c6550397435e9601fbae467be90976._comment b/doc/forum/Sync_files_from_remote_to_remote/comment_7_77c6550397435e9601fbae467be90976._comment
new file mode 100644
index 0000000000..bbacebbdcc
--- /dev/null
+++ b/doc/forum/Sync_files_from_remote_to_remote/comment_7_77c6550397435e9601fbae467be90976._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Jan"
+ subject="comment 7"
+ date="2016-02-03T02:49:01Z"
+ content="""
+I can confirm that Remi's suggestion does work as expected, thanks!
+
+    $ git annex sync --content
+    get 2014/2014-06-14/IMG_1448.JPG (from origin...) (checksum...) ok
+    copy 2014/2014-06-14/IMG_1448.JPG copy 2014/2014-06-14/IMG_1448.JPG (to usb...) ok
+    drop 2014/2014-06-14/IMG_1448.JPG ok
+"""]]
diff --git a/doc/forum/Sync_files_from_remote_to_remote/comment_8_4d3c05acc310a21f6c8ab77fb2638a8c._comment b/doc/forum/Sync_files_from_remote_to_remote/comment_8_4d3c05acc310a21f6c8ab77fb2638a8c._comment
new file mode 100644
index 0000000000..279929f2ac
--- /dev/null
+++ b/doc/forum/Sync_files_from_remote_to_remote/comment_8_4d3c05acc310a21f6c8ab77fb2638a8c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="konubinix"
+ subject="git-annex-getcopy.sh"
+ date="2016-02-03T12:32:55Z"
+ content="""
+To do that, I created a simple bash script that get locally the files and then copies them to the remote
+
+https://github.com/Konubinix/Devel/blob/master/bin/git-annex-getcopy.sh
+
+I hope that helps.
+"""]]
diff --git a/doc/forum/Sync_files_via_remote_server.mdwn b/doc/forum/Sync_files_via_remote_server.mdwn
new file mode 100644
index 0000000000..8f88433115
--- /dev/null
+++ b/doc/forum/Sync_files_via_remote_server.mdwn
@@ -0,0 +1,5 @@
+I have two local devices set up with the same remote server (a bare repo following https://git-annex.branchable.com/tips/centralized_git_repository_tutorial/on_your_own_server/)
+
+I can sync and move files to/from each device. But I can't see the files pushed by one device on the other (or vice-versa).
+
+So from desktop I sync file "a" and from android I sync file "b" but I can't do "git annex copy b --from origin" on the desktop.
diff --git a/doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__.mdwn b/doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__.mdwn
new file mode 100644
index 0000000000..3356e3ae81
--- /dev/null
+++ b/doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__.mdwn
@@ -0,0 +1 @@
+Can I have an rsync.net remote sync directly to s3? I want to use rsync.net's faster network, rather than uploading the same file twice from my slower connection. rsync.net doesn’t provide `git-annex-script` so I don’t know if there’s a way to do that. Thanks, Pat
diff --git a/doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__/comment_1_68e73ffa29338214fa030c5f0e2823c6._comment b/doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__/comment_1_68e73ffa29338214fa030c5f0e2823c6._comment
new file mode 100644
index 0000000000..2abdee9ae1
--- /dev/null
+++ b/doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__/comment_1_68e73ffa29338214fa030c5f0e2823c6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="re: Sync from one remote to another"
+ date="2021-04-17T19:34:19Z"
+ content="""
+I don't think there's currently a way to tell git-annex to tell rsync.net to copy to s3; see [[todo/transitive_transfers]].  But if you do the in-cloud copying yourself outside of git-annex, you can use [[`git-annex-import --no-content`|git-annex-import]] to record in git-annex the location of the copies in s3.  See also [[todo/sync_fast_import]].
+"""]]
diff --git a/doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__/comment_3_3d57de3c12527e5a4b30ff7982ae749d._comment b/doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__/comment_3_3d57de3c12527e5a4b30ff7982ae749d._comment
new file mode 100644
index 0000000000..fac14df975
--- /dev/null
+++ b/doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__/comment_3_3d57de3c12527e5a4b30ff7982ae749d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 3"
+ date="2021-04-18T01:19:53Z"
+ content="""
+rsync.net provides `rclone` - so I wonder if there's some way for `git-annex` to use that? Maybe it could `rclone` from rsync.net to s3 and use that faster connection.
+"""]]
diff --git a/doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__/comment_3_94b40e68418f732322c9a01418688165._comment b/doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__/comment_3_94b40e68418f732322c9a01418688165._comment
new file mode 100644
index 0000000000..f4266364c9
--- /dev/null
+++ b/doc/forum/Sync_from_one_remote_to_another___40__rsync.net_to_s3__41____63__/comment_3_94b40e68418f732322c9a01418688165._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 3"
+ date="2021-04-17T20:21:57Z"
+ content="""
+Okay so it sounds like if I want to store stuff on rsync.net and s3, and use a faster connection, I'll need to set up a VPS instance as a transfer remote. Then I upload files from my local machine to the transfer remote, and have it upload to rsync.net and S3. Are there any other options that I'm overlooking?
+"""]]
diff --git a/doc/forum/Sync_only_what_is_not_available_from_my_central_git_repo.mdwn b/doc/forum/Sync_only_what_is_not_available_from_my_central_git_repo.mdwn
new file mode 100644
index 0000000000..223e5eaeda
--- /dev/null
+++ b/doc/forum/Sync_only_what_is_not_available_from_my_central_git_repo.mdwn
@@ -0,0 +1,7 @@
+I work in a distributed startup.  We have a master repository on GitHub.  At the office we have modern hunky Linux desktops (seriously more powerful than any of our laptops).
+
+I (and others) have hard deadlines at the end of the day (typically child commitments).  If I leave from a meeting or brainstorming session without having pushed all of my work into the cloud then I cannot continue working from home.  This is because our office is behind multiple levels of NAT over which we have no control.  Hence I am unable to remote into my machine in order to push work up to GitHub or scp it to my laptop.
+
+Is there a way to get git-annex to sync only files that do not correspond to git objects available from our GitHub repository?  Because our source tree is quite large (2.5GB including tests and test data) I would not want git-annex to sync the entire tree.  And when I checkout a different branch I would not want git-annex to sync all changes between the previously checked-out branch and the new branch.  Rather I would like git-annex to discard any previously synced objects, note the identity of the new branch and the values of all files (object) not available from the upstream state of that branch on GitHub.
+
+Thanks in advance for any suggestions.
diff --git a/doc/forum/Sync_only_what_is_not_available_from_my_central_git_repo/comment_1_b31d02c97447996495de73705ac39f71._comment b/doc/forum/Sync_only_what_is_not_available_from_my_central_git_repo/comment_1_b31d02c97447996495de73705ac39f71._comment
new file mode 100644
index 0000000000..b7f343b133
--- /dev/null
+++ b/doc/forum/Sync_only_what_is_not_available_from_my_central_git_repo/comment_1_b31d02c97447996495de73705ac39f71._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="gjost"
+ ip="75.140.92.244"
+ subject="comment 1"
+ date="2014-05-20T15:19:35Z"
+ content="""
+> If I leave from a meeting or brainstorming session without having pushed all of my work into the cloud then I cannot continue working from home. This is because our office is behind multiple levels of NAT over which we have no control. Hence I am unable to remote into my machine in order to push work up to GitHub or scp it to my laptop.
+
+This is not a git-annex solution, but you could use Pagekite to SSH to your work machine from home.
+
+
+"""]]
diff --git a/doc/forum/Sync_only_what_is_not_available_from_my_central_git_repo/comment_2_098465ae8af32931779d2cd63750d5dc._comment b/doc/forum/Sync_only_what_is_not_available_from_my_central_git_repo/comment_2_098465ae8af32931779d2cd63750d5dc._comment
new file mode 100644
index 0000000000..95a8721dff
--- /dev/null
+++ b/doc/forum/Sync_only_what_is_not_available_from_my_central_git_repo/comment_2_098465ae8af32931779d2cd63750d5dc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.3"
+ subject="comment 2"
+ date="2014-05-21T18:11:45Z"
+ content="""
+It seems to me that simply running `git annex sync --content` before you go home would do what you need. Have you tried using git-annex? 
+
+Some of the things you're saying don't entirely make sense to me, and so I suspect you're perhaps worrying about problems that don't exist, or that git-annex deals with nicely.
+"""]]
diff --git a/doc/forum/Sync_with_one_offline_peer.mdwn b/doc/forum/Sync_with_one_offline_peer.mdwn
new file mode 100644
index 0000000000..6ee05c6e67
--- /dev/null
+++ b/doc/forum/Sync_with_one_offline_peer.mdwn
@@ -0,0 +1,11 @@
+Hello,
+
+I use the assistant to set up two repositories A and B synced using jabber. A third repository C on my server is used as rsync transfer. Syncing works fine between both repos when both are online.
+
+But when either A or B is offline the sync does not happen when it comes online again, though the file was synced to C.
+
+Is this because C is only a rsync repository and can't hold metadata? How can I achieve that the sync happens also when one of the repositories is offline?
+
+I also tried using the static build of git annex on my server. It seemed to run fine but during the setup the assistant got an error about too many command line arguments. On A und B I use the ArchLinux AUR build (https://aur.archlinux.org/packages/git-annex-standalone/), on C I use the static build. Could it be a version mismatch?
+
+Thanks!
diff --git a/doc/forum/Sync_with_one_offline_peer/comment_1_3859d842d4f7e2ef44877b05ebe881fb._comment b/doc/forum/Sync_with_one_offline_peer/comment_1_3859d842d4f7e2ef44877b05ebe881fb._comment
new file mode 100644
index 0000000000..5fe670d35c
--- /dev/null
+++ b/doc/forum/Sync_with_one_offline_peer/comment_1_3859d842d4f7e2ef44877b05ebe881fb._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnsuhFUIfWNT-Q-C02FDaSQqceFDge5M9w"
+ nickname="Florian"
+ subject="comment 1"
+ date="2013-09-09T21:49:17Z"
+ content="""
+Another try on the layout:
+
+Hello,
+
+I use the assistant to set up two repositories A and B synced using jabber. A third repository C on my server is used as rsync transfer. Syncing works fine between both repos when both are online.
+
+But when either A or B is offline the sync does not happen when it comes online again, though the file was synced to C.
+
+Is this because C is only a rsync repository and can't hold metadata? How can I achieve that the sync happens also when one of the repositories is offline?
+
+I also tried using the static build of git annex on my server. It seemed to run fine but during the setup the assistant got an error about too many command line arguments. On A und B I use the ArchLinux AUR build (https://aur.archlinux.org/packages/git-annex-standalone/), on C I use the static build. Could it be a version mismatch?
+
+Thanks!
+"""]]
diff --git a/doc/forum/Sync_with_one_offline_peer/comment_2_c9ba3983b37b0c1868269616fd81e518._comment b/doc/forum/Sync_with_one_offline_peer/comment_2_c9ba3983b37b0c1868269616fd81e518._comment
new file mode 100644
index 0000000000..20b82dd3e5
--- /dev/null
+++ b/doc/forum/Sync_with_one_offline_peer/comment_2_c9ba3983b37b0c1868269616fd81e518._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.51"
+ subject="comment 2"
+ date="2013-09-12T21:13:36Z"
+ content="""
+Yes, the rsync repository is not a git repository and so does not hold metadata. If you can install git-annex on your server, you can add a regular git repository there, and then the clients can sync to it even when the other is offline.
+
+This is also why I an working on adding support for [[special_remotes/gcrypt]] repositories, so you can have a fully encrypted git repository on the server and sync through that.
+
+>   during the setup the assistant got an error about too many command line arguments
+
+I have never heard about such a problem. You should file a bug report with the details.
+"""]]
diff --git a/doc/forum/Sync_with_one_offline_peer/comment_3_28b9c003b4560c3ce90c9ebf808b091b._comment b/doc/forum/Sync_with_one_offline_peer/comment_3_28b9c003b4560c3ce90c9ebf808b091b._comment
new file mode 100644
index 0000000000..332cd83c35
--- /dev/null
+++ b/doc/forum/Sync_with_one_offline_peer/comment_3_28b9c003b4560c3ce90c9ebf808b091b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnsuhFUIfWNT-Q-C02FDaSQqceFDge5M9w"
+ nickname="Florian"
+ subject="comment 3"
+ date="2013-09-13T10:52:33Z"
+ content="""
+Thanks for your reply. The bug report is at <http://git-annex.branchable.com/bugs/git-annex:_Argument_list_too_long/>
+
+I'll be happy to provide any more help if I can!
+"""]]
diff --git a/doc/forum/Sync_without_jabber_account.mdwn b/doc/forum/Sync_without_jabber_account.mdwn
new file mode 100644
index 0000000000..b459f33103
--- /dev/null
+++ b/doc/forum/Sync_without_jabber_account.mdwn
@@ -0,0 +1,9 @@
+Hi,
+
+It is possible to keep devices sync only using a box.com account as a transfer remote, without Jabber? I can't use Jabber because of firewall restrictions.
+
+It would be nice to be able to use the transfer remote, in my case box.net, as the sync "provider", for example by polling a file with the needed changes in a pre-defined interval.
+
+Regards,
+
+Stone
diff --git a/doc/forum/Sync_without_jabber_account/comment_1_3e95ac2e67451f953cf0538094109f8b._comment b/doc/forum/Sync_without_jabber_account/comment_1_3e95ac2e67451f953cf0538094109f8b._comment
new file mode 100644
index 0000000000..1a601848c1
--- /dev/null
+++ b/doc/forum/Sync_without_jabber_account/comment_1_3e95ac2e67451f953cf0538094109f8b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 1"
+ date="2013-07-17T19:06:59Z"
+ content="""
+We don't currently have a way to store a git repository on box.com, and you need such a git repo on a server somewhere if you're not using Jabber.
+
+Of course you can mount the box.com, using either davfs2 or something else, and put a bare git repository in its directory, and if you set this up on multiple computers, it might just work (or they might both try to write to it at the same time and fail.. I have not tried).
+"""]]
diff --git a/doc/forum/Synchronize_large_files___40__VM_images__41__.mdwn b/doc/forum/Synchronize_large_files___40__VM_images__41__.mdwn
new file mode 100644
index 0000000000..71de3ee7cf
--- /dev/null
+++ b/doc/forum/Synchronize_large_files___40__VM_images__41__.mdwn
@@ -0,0 +1,10 @@
+Hi, 
+
+i'm thinking to use git-annex to synchronize my virtual machine directory (Virtualbox) between 3 pc. It's quite big: more than 200GB and some of the images are 40Gb in size.
+
+The synchronization will be over a lan (obviously). It is already in place with 2pc and unison but the configuration of the 3rd pc is cumbersome. 
+Does anybody have experiences with git-annex and such amount of data?
+
+Thanks in advance
+
+Gabriele
diff --git a/doc/forum/Synchronize_large_files___40__VM_images__41__/comment_1_619f6ed2d7da5832ab253d61b6dd8044._comment b/doc/forum/Synchronize_large_files___40__VM_images__41__/comment_1_619f6ed2d7da5832ab253d61b6dd8044._comment
new file mode 100644
index 0000000000..292ee3b7bf
--- /dev/null
+++ b/doc/forum/Synchronize_large_files___40__VM_images__41__/comment_1_619f6ed2d7da5832ab253d61b6dd8044._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 1"
+ date="2012-11-28T18:01:31Z"
+ content="""
+This volume of data should be no problem for git-annex.
+
+The only catch would be if you're running those VM images and want to sync them as they're changed. With git-annex, you'd need to `git annex unlock` a file to allow it to be modified, and then `git annex add` it back and commit changes made to it.
+"""]]
diff --git a/doc/forum/Synchronize_large_files___40__VM_images__41__/comment_2_bbd98d0b5d77dc7efc55ef8c2a18d612._comment b/doc/forum/Synchronize_large_files___40__VM_images__41__/comment_2_bbd98d0b5d77dc7efc55ef8c2a18d612._comment
new file mode 100644
index 0000000000..bc04122df2
--- /dev/null
+++ b/doc/forum/Synchronize_large_files___40__VM_images__41__/comment_2_bbd98d0b5d77dc7efc55ef8c2a18d612._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/hVbIabkhqO11.DpKUWBoztFSLD5q#8cbe8"
+ nickname="Murat"
+ avatar="http://cdn.libravatar.org/avatar/52d95e40aca820c1993077ef9aa676c75700a072511c143f6db6b78be6b1b212"
+ subject="Why is it takins too long?"
+ date="2017-04-18T16:26:06Z"
+ content="""
+Hi,
+due to my requirement I need to revert vm image every time before running it via \"git reset --hard\" which is really fast on the other hand \"git annex unlock\" takes really long, I run git-annex on Centos 6 and git-annex version git-annex-3.20120522-2.1.el6.x86_64, if I update git-annex version can it help to fasten \"unlock\"?
+
+thanks a lot
+
+"""]]
diff --git a/doc/forum/Synchronize_large_files___40__VM_images__41__/comment_3_6488bbe6f39e7154f950530498e9b548._comment b/doc/forum/Synchronize_large_files___40__VM_images__41__/comment_3_6488bbe6f39e7154f950530498e9b548._comment
new file mode 100644
index 0000000000..9c55e48f7c
--- /dev/null
+++ b/doc/forum/Synchronize_large_files___40__VM_images__41__/comment_3_6488bbe6f39e7154f950530498e9b548._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-05-11T17:06:23Z"
+ content="""
+The reason `git annex unlock` is slow is because it makes a copy
+of the entire file. The file is left as-is in the annex so the
+old version is available later, and the unlocked copy is made available for
+modification.
+
+More recent versions of git-annex support v6 mode, which has a annex.thin
+configuration that makes `git annex unlock` not do this copy, so it's very
+fast. But then no copy of the old version of the file will be made,
+and so you won't be able to revert to the old version. Which seems to be
+an important part of your workflow.
+
+Another way to make `git annex unlock` fast is to use a file system that
+supports Copy On Write (CoW). git-annex will use CoW automatically when
+available, and then unlocking doesn't need to actually copy the file,
+but the old version will still be preserved. Btrfs is the only filesystem
+I know of that supports CoW, although there may be others.
+"""]]
diff --git a/doc/forum/Synchronize_two_latops_with_a_ssh_remote.mdwn b/doc/forum/Synchronize_two_latops_with_a_ssh_remote.mdwn
new file mode 100644
index 0000000000..1cf693b5fd
--- /dev/null
+++ b/doc/forum/Synchronize_two_latops_with_a_ssh_remote.mdwn
@@ -0,0 +1,3 @@
+Using the command `git-annex webapp` I was able to configure a local repository on my laptop A that is synchronized with a remote repository using ssh. This latter has sync enabled and it is encrypted. I also put it in the *full backup* group.
+
+Now, I would like to synchronize my laptop B with the remote repository with ssh. Using the webapp, I tried to do the same thing I did with my laptop A. However now, my both laptop are synchronized with the remote repository but they do not share any file between them. How can I achieve that ?
diff --git a/doc/forum/Syncing_Compressed_files.mdwn b/doc/forum/Syncing_Compressed_files.mdwn
new file mode 100644
index 0000000000..dd2f5adea7
--- /dev/null
+++ b/doc/forum/Syncing_Compressed_files.mdwn
@@ -0,0 +1 @@
+I don't see anywhere in the documentation that specifies this, but git-annex hasn't been syncing any kind of compressed file for me like zip files or 7z compressed files.  Haven't tried gzip files.  It has been working fine with other files like PDFs, video, images etc.  Was wanting to know if that is expected behaviour or if something is wrong?
diff --git a/doc/forum/Syncing_Compressed_files/comment_1_e44598cd735830a8df9a29e0031d34f1._comment b/doc/forum/Syncing_Compressed_files/comment_1_e44598cd735830a8df9a29e0031d34f1._comment
new file mode 100644
index 0000000000..bc20f3eb0f
--- /dev/null
+++ b/doc/forum/Syncing_Compressed_files/comment_1_e44598cd735830a8df9a29e0031d34f1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-29T17:44:15Z"
+ content="""
+git-annex doesn't differentiate between different sorts of files in any
+way.
+
+Are you sure you're adding these compressed files to the repo?
+"""]]
diff --git a/doc/forum/Syncing_Compressed_files/comment_2_db1ea446ae9720fe1651c56da38e7088._comment b/doc/forum/Syncing_Compressed_files/comment_2_db1ea446ae9720fe1651c56da38e7088._comment
new file mode 100644
index 0000000000..595ccc7b25
--- /dev/null
+++ b/doc/forum/Syncing_Compressed_files/comment_2_db1ea446ae9720fe1651c56da38e7088._comment
@@ -0,0 +1,158 @@
+[[!comment format=mdwn
+ username="moird"
+ subject="comment 2"
+ date="2016-01-29T18:42:12Z"
+ content="""
+Using assistant on a folder.  Any files that are dropped in that folder will immediately be synced as far as I can tell except for a couple of zip files.  I turned on debug logging to look at it, and it looks like the watcher is not being called when the zip file is being copied into the folder, but is when the file is being removed from the folder.  Compared to when a regular file is dropped into the folder where it will run without issue:
+
+    [2016-01-27 06:51:26.988169] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+    [2016-01-27 06:51:26.990623] process done ExitSuccess
+    [2016-01-27 06:51:26.990908] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2016-01-27 06:51:26.992654] process done ExitSuccess
+    [2016-01-27 06:51:26.992981] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/annex/direct/master\"]
+    [2016-01-27 06:51:26.995703] process done ExitSuccess
+    [2016-01-27 06:51:26.995998] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"write-tree\"]
+    [2016-01-27 06:51:26.997896] process done ExitSuccess
+    [2016-01-27 06:51:26.998196] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"rev-parse\",\"db03e812e512e24afe7f4b440a6ca174aa33cbdd:\"]
+    [2016-01-27 06:51:27.000111] process done ExitSuccess
+    [2016-01-27 06:51:27.00038] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2016-01-27 06:51:27.001926] process done ExitSuccess
+    [2016-01-27 06:51:27.002223] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+    [2016-01-27 06:51:27.00406] process done ExitSuccess
+    [2016-01-27 06:51:27.004382] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"synced/master\"]
+    [2016-01-27 06:51:27.006269] process done ExitSuccess
+    [2016-01-27 06:51:27.006567] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"master\"]
+    [2016-01-27 06:51:27.008293] process done ExitSuccess
+    [2016-01-27 06:51:27.008992] Pusher: Syncing with annex 
+    [2016-01-27 06:51:27.009551] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+    [2016-01-27 06:51:27.010828] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+    [2016-01-27 06:51:27.013085] process done ExitSuccess
+    [2016-01-27 06:51:27.013608] process done ExitSuccess
+    [2016-01-27 06:51:27.014011] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2016-01-27 06:51:27.01584] process done ExitSuccess
+    (recording state in git...)
+    [2016-01-27 06:51:27.016212] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"write-tree\"]
+    [2016-01-27 06:51:27.018706] process done ExitSuccess
+    [2016-01-27 06:51:27.018978] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"commit-tree\",\"29075d2d02995138a1774809a34c5220f54cea52\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"]
+    [2016-01-27 06:51:27.021681] process done ExitSuccess
+    [2016-01-27 06:51:27.021966] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"update-ref\",\"refs/heads/git-annex\",\"c833bef56cf282eefb957347e2a1938ef8568da6\"]
+    [2016-01-27 06:51:27.024413] process done ExitSuccess
+    [2016-01-27 06:51:27.025057] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2016-01-27 06:51:27.027394] process done ExitSuccess
+    [2016-01-27 06:51:27.027759] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+    [2016-01-27 06:51:27.030137] process done ExitSuccess
+    [2016-01-27 06:51:27.030507] Pusher: pushing to [Remote { name =\"annex\" }]
+    [2016-01-27 06:51:27.030554] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+    [2016-01-27 06:51:27.033305] process done ExitSuccess
+    [2016-01-27 06:51:27.033621] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2016-01-27 06:51:27.035758] process done ExitSuccess
+    [2016-01-27 06:51:27.036238] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c833bef56cf282eefb957347e2a1938ef8568da6\",\"-n1\",\"--pretty=%H\"]
+    [2016-01-27 06:51:27.039257] process done ExitSuccess
+    [2016-01-27 06:51:27.039752] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..7e6f7d4c9ff0bdb8f942c8edcb8a5a2581e7adb2\",\"-n1\",\"--pretty=%H\"]
+    [2016-01-27 06:51:27.043657] process done ExitSuccess
+    [2016-01-27 06:51:27.044082] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+    [2016-01-27 06:51:27.047843] process done ExitSuccess
+    [2016-01-27 06:51:27.048343] ConfigMonitor: reloading config numcopies.log
+    [2016-01-27 06:51:27.04847] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annex\",\"+git-annex:synced/git-annex\",\"annex/direct/master:synced/master\"]
+    [2016-01-27 06:51:27.050624] Cronner: reloading changed activities
+    To /home/daniel/store/annex
+       7e6f7d4..c833bef  git-annex -> synced/git-annex
+    [2016-01-27 06:51:27.290878] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+    [2016-01-27 06:51:27.291094] process done ExitSuccess
+    [2016-01-27 06:51:27.292194] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annex\",\"git-annex\",\"master\"]
+    [2016-01-27 06:51:27.293901] process done ExitSuccess
+    [2016-01-27 06:51:27.294222] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2016-01-27 06:51:27.297276] process done ExitSuccess
+    [2016-01-27 06:51:27.297782] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c833bef56cf282eefb957347e2a1938ef8568da6\",\"-n1\",\"--pretty=%H\"]
+    [2016-01-27 06:51:27.300978] process done ExitSuccess
+    [2016-01-27 06:51:27.301324] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..7e6f7d4c9ff0bdb8f942c8edcb8a5a2581e7adb2\",\"-n1\",\"--pretty=%H\"]
+    [2016-01-27 06:51:27.304226] process done ExitSuccess
+    [2016-01-27 06:51:27.309109] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+    [2016-01-27 06:51:27.30931] process done ExitSuccess
+    [2016-01-27 06:51:27.3116] process done ExitSuccess
+    [2016-01-27 06:51:27.311946] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2016-01-27 06:51:27.314424] process done ExitSuccess
+    [2016-01-27 06:51:27.314803] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c833bef56cf282eefb957347e2a1938ef8568da6\",\"-n1\",\"--pretty=%H\"]
+    [2016-01-27 06:51:27.317614] process done ExitSuccess
+    [2016-01-27 06:51:29.311876] Pusher: Syncing with annex 
+    [2016-01-27 06:51:29.312427] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2016-01-27 06:51:29.315265] process done ExitSuccess
+    [2016-01-27 06:51:29.315673] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+    [2016-01-27 06:51:29.318964] process done ExitSuccess
+    [2016-01-27 06:51:29.319639] Pusher: pushing to [Remote { name =\"annex\" }]
+    [2016-01-27 06:51:29.32004] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annex\",\"+git-annex:synced/git-annex\",\"annex/direct/master:synced/master\"]
+    Everything up-to-date
+    [2016-01-27 06:51:29.329677] process done ExitSuccess
+    [2016-01-27 06:51:29.330047] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annex\",\"git-annex\",\"master\"]
+    [2016-01-27 06:51:29.339748] process done ExitSuccess
+    [2016-01-27 06:52:27.059869] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+    [2016-01-27 06:52:27.064751] process done ExitSuccess
+    [2016-01-27 06:55:25.738944] Watcher: file deleted Documents/Innovation.zip
+    [2016-01-27 06:55:25.75008] Committer: committing 1 changes
+    [2016-01-27 06:55:25.75047] Committer: Committing changes to git
+    (recording state in git...)
+    [2016-01-27 06:55:25.750868] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+    [2016-01-27 06:55:25.753501] process done ExitSuccess
+    [2016-01-27 06:55:25.753793] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2016-01-27 06:55:25.755492] process done ExitSuccess
+    [2016-01-27 06:55:25.755827] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/annex/direct/master\"]
+    [2016-01-27 06:55:25.75798] process done ExitSuccess
+    [2016-01-27 06:55:25.758268] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"write-tree\"]
+    [2016-01-27 06:55:25.760247] process done ExitSuccess
+    [2016-01-27 06:55:25.760524] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"rev-parse\",\"db03e812e512e24afe7f4b440a6ca174aa33cbdd:\"]
+    [2016-01-27 06:55:25.762615] process done ExitSuccess
+    [2016-01-27 06:55:25.762953] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2016-01-27 06:55:25.764649] process done ExitSuccess
+    [2016-01-27 06:55:25.764895] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+    [2016-01-27 06:55:25.766833] process done ExitSuccess
+    [2016-01-27 06:55:25.767095] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"synced/master\"]
+    [2016-01-27 06:55:25.769018] process done ExitSuccess
+    [2016-01-27 06:55:25.769381] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"master\"]
+    [2016-01-27 06:55:25.771227] process done ExitSuccess
+    [2016-01-27 06:55:25.771526] Pusher: Syncing with annex 
+    [2016-01-27 06:55:25.771855] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2016-01-27 06:55:25.773533] process done ExitSuccess
+    [2016-01-27 06:55:25.773778] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+    [2016-01-27 06:55:25.775489] process done ExitSuccess
+    [2016-01-27 06:55:25.775781] Pusher: pushing to [Remote { name =\"annex\" }]
+    [2016-01-27 06:55:25.776187] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annex\",\"+git-annex:synced/git-annex\",\"annex/direct/master:synced/master\"]
+    Everything up-to-date
+    [2016-01-27 06:55:25.783416] process done ExitSuccess
+    [2016-01-27 06:55:25.78379] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annex\",\"git-annex\",\"master\"]
+    [2016-01-27 06:55:25.792144] process done ExitSuccess
+    [2016-01-27 06:56:55.488921] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2016-01-27 06:56:55.491198] process done ExitSuccess
+    [2016-01-27 06:56:55.491606] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+    [2016-01-27 06:56:55.494862] process done ExitSuccess
+    [2016-01-27 06:56:55.495272] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+    [2016-01-27 06:56:55.49766] process done ExitSuccess
+    [2016-01-27 06:56:55.498193] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2016-01-27 06:56:55.50149] process done ExitSuccess
+    [2016-01-27 06:56:55.501967] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c833bef56cf282eefb957347e2a1938ef8568da6\",\"-n1\",\"--pretty=%H\"]
+    [2016-01-27 06:56:55.505598] process done ExitSuccess
+    [2016-01-27 06:56:55.506265] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2016-01-27 06:56:55.508634] process done ExitSuccess
+    [2016-01-27 06:56:55.50908] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+    [2016-01-27 06:56:55.512201] process done ExitSuccess
+    [2016-01-27 07:01:34.745946] Watcher: add Videos/SPOT0001.avi
+    [2016-01-27 07:01:34.757341] read: lsof [\"-F0can\",\"+d\",\".git/annex/misctmp/\"]
+    lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/120/gvfs
+          Output information may be incomplete.
+    [2016-01-27 07:01:34.922312] process done ExitFailure 1
+
+      Videos/SPOT0001.avi still has writers, not adding
+    [2016-01-27 07:01:34.92397] Watcher: add Videos/SPOT0001.avi
+    [2016-01-27 07:01:35.93566] read: lsof [\"-F0can\",\"+d\",\".git/annex/misctmp/\"]
+    lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/120/gvfs
+          Output information may be incomplete.
+    [2016-01-27 07:01:36.076194] process done ExitFailure 1
+    [2016-01-27 07:01:36.076529] Committer: Adding SPOT0001.avi
+    add Videos/SPOT0001.avi [2016-01-27 07:01:36.077018] read: sha256sum [\".git/annex/misctmp/SPOT00017523927541474612399.avi\"]
+    [2016-01-27 07:01:36.173532] process done ExitSuccess
+    [2016-01-27 07:01:36.18156] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"hash-object\",\"-t\",\"blob\",\"-w\",\"--stdin\",\"--no-filters\"]
+    [2016-01-27 07:01:36.183854] process done ExitSuccess
+    ok
+    << trimmed because it worked >>
+
+I did end up leaving the zip in the folder, but I have tried in different subfolders and different zips, just not tar.gzs...
+"""]]
diff --git a/doc/forum/Syncing_Compressed_files/comment_3_885c045c8ddfccbd426a6bc1bc053435._comment b/doc/forum/Syncing_Compressed_files/comment_3_885c045c8ddfccbd426a6bc1bc053435._comment
new file mode 100644
index 0000000000..32e67c3f00
--- /dev/null
+++ b/doc/forum/Syncing_Compressed_files/comment_3_885c045c8ddfccbd426a6bc1bc053435._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-01-29T18:50:57Z"
+ content="""
+Is this on Linux? It may be some kind of problem with inotify..
+"""]]
diff --git a/doc/forum/Syncing_Compressed_files/comment_4_d619d9b7ad4ca3f2fa9505ea928d5bf7._comment b/doc/forum/Syncing_Compressed_files/comment_4_d619d9b7ad4ca3f2fa9505ea928d5bf7._comment
new file mode 100644
index 0000000000..65f44a0f6c
--- /dev/null
+++ b/doc/forum/Syncing_Compressed_files/comment_4_d619d9b7ad4ca3f2fa9505ea928d5bf7._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="moird"
+ subject="comment 4"
+ date="2016-01-29T19:43:21Z"
+ content="""
+yes, this is arch linux.  It seems to be more of an issue of the extension, I was toying with a zip file and renaming it and like if the extension was zipper then it would sync the file.  It would not sync the file if it was named with gz.  Was messing with inotifywatch and it is seeing the zip file creation:
+
+    total  create  filename
+    2      2       /home/daniel/annex/.git/refs/remotes/annex/synced/
+    2      2       /home/daniel/annex/.git/
+    1      1       /home/daniel/annex/.git/refs/heads/synced/
+    1      1       /home/daniel/annex/.git/refs/heads/
+    1      1       /home/daniel/annex/.git/refs/remotes/annex/
+    1      1       /home/daniel/annex/
+
+On successful files syncing will show the hashed annex folders 
+"""]]
diff --git a/doc/forum/Syncing_Compressed_files/comment_5_0c7af752cc35013273a07a5fa1f71f6e._comment b/doc/forum/Syncing_Compressed_files/comment_5_0c7af752cc35013273a07a5fa1f71f6e._comment
new file mode 100644
index 0000000000..574ba4e811
--- /dev/null
+++ b/doc/forum/Syncing_Compressed_files/comment_5_0c7af752cc35013273a07a5fa1f71f6e._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="moird"
+ subject="comment 5"
+ date="2016-01-30T19:01:28Z"
+ content="""
+well that figures... I forgot I had a global .gitignore file and it by default filtered out compressed files like zips and such.  Removed that restarted the agents, everything is good.
+"""]]
diff --git a/doc/forum/Syncing_machines_on_different_networks.mdwn b/doc/forum/Syncing_machines_on_different_networks.mdwn
new file mode 100644
index 0000000000..6851a6c016
--- /dev/null
+++ b/doc/forum/Syncing_machines_on_different_networks.mdwn
@@ -0,0 +1,9 @@
+I've been using git-annex locally for a couple months. So far I've only used it to keep track of files on my laptop and local usb hard drives. Now I would like to add a network into the picture, and hopefully start to move away from Dropbox.
+
+I have Dropbox on two computers: my home machine and my work machine. The home machine is only on when I'm at home and the work machine is only on when I'm at work, so the computers are never on at the same time and thus can never communicate directly. What are my options for keeping annexes on these two machines in sync?
+
+Initially I was hoping that I could use an S3 special remote for this, but I see that special remotes only hold the actual file data, not any of the git stuff. So I can't push my changes to S3 at work and then pull those changes in at home.
+
+From what I can tell from the documentation, the only way I can handle this problem is to have an annex sitting on a VPS or someplace that both my home and work machines can talk to. Is that correct? That would be ok, but if I'm going to put my annex out there in the cloud somewhere, I want the files to be encrypted. It looks like git-annex only supports encryption of file data with special remotes, not a full annex. Is there no way to have some sort of encrypted git-annex hub?
+
+I backed the assistant and have been following the development blog, but I haven't tried it out yet. Am I correct in thinking that nothing in the assistant will address this particular issue?
diff --git a/doc/forum/Syncing_machines_on_different_networks/comment_1_1c3523c722c178a96b096a68b9be4165._comment b/doc/forum/Syncing_machines_on_different_networks/comment_1_1c3523c722c178a96b096a68b9be4165._comment
new file mode 100644
index 0000000000..dcc59017b4
--- /dev/null
+++ b/doc/forum/Syncing_machines_on_different_networks/comment_1_1c3523c722c178a96b096a68b9be4165._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 1"
+ date="2012-11-02T07:21:15Z"
+ content="""
+I might be thinking too simple, but can't you just put another annex repository on an usbdrive and use it to carry the metadata around? Add it as a remote to both compuers annex repositories and sync when you come/leave. As it does not have to carry the actual data some 100M will usually suffice. Just don't use any special remotes, but simply a cloned git repository.
+"""]]
diff --git a/doc/forum/Syncing_machines_on_different_networks/comment_2_d7b14ffee65072329cfe9ab08a0dba50._comment b/doc/forum/Syncing_machines_on_different_networks/comment_2_d7b14ffee65072329cfe9ab08a0dba50._comment
new file mode 100644
index 0000000000..6f0f044967
--- /dev/null
+++ b/doc/forum/Syncing_machines_on_different_networks/comment_2_d7b14ffee65072329cfe9ab08a0dba50._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="annexuser"
+ ip="50.125.40.225"
+ subject="comment 2"
+ date="2012-11-02T19:41:27Z"
+ content="""
+That's what I've started to do. It gets the job done, but I don't like that I have to remember to plug in the stick and sync to it at the end of the work day, and then plug in the stick and sync from it when I get home. I'm hoping that there is some way to accomplish the syncing automagically, more akin to the Dropbox experience.
+"""]]
diff --git a/doc/forum/Syncing_machines_on_different_networks/comment_3_65d1dae9b76fccb5f2b8fd8c69b60075._comment b/doc/forum/Syncing_machines_on_different_networks/comment_3_65d1dae9b76fccb5f2b8fd8c69b60075._comment
new file mode 100644
index 0000000000..2fa7ac055c
--- /dev/null
+++ b/doc/forum/Syncing_machines_on_different_networks/comment_3_65d1dae9b76fccb5f2b8fd8c69b60075._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.194"
+ subject="comment 3"
+ date="2012-11-04T19:44:11Z"
+ content="""
+You need two things:
+
+1. A special remote in the cloud. S3, or rsync.net, or whatever.
+2. A git repository hosted in the cloud. You could just use github (paying them if you want to avoid it being public).
+
+Is it possible to have an encrypted git remote repository? It's not directly supported by git. The way git needs to be able to request arbitrary objects by SHA, kind of prevents encrypting things to any useful level. The only way I can think of to do that would be to use some cloud storage that can be mounted as a filesystem, and store an encrypted filesystem containing the git repo in a file inside that. Not easy.
+
+The git-annex assistant is going to get around this by not requiring a central git repository and transferring git data peer-to-peer, but that will require both the peers be on the network at the same time.
+"""]]
diff --git a/doc/forum/Syncing_machines_on_different_networks/comment_4_2ec67428af69d6c0ea051c6a67d58905._comment b/doc/forum/Syncing_machines_on_different_networks/comment_4_2ec67428af69d6c0ea051c6a67d58905._comment
new file mode 100644
index 0000000000..34d37ce4fd
--- /dev/null
+++ b/doc/forum/Syncing_machines_on_different_networks/comment_4_2ec67428af69d6c0ea051c6a67d58905._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="annexuser"
+ ip="50.125.40.225"
+ subject="comment 4"
+ date="2012-11-05T02:07:00Z"
+ content="""
+Thanks for the feedback.
+
+I'm thinking the smartest move will be for me to invest in some sort of wall-wart, like a SheevaPlug or RasberryPi. I can use that as the centralized hub and still avoid putting my files on the big bad interwebs.
+"""]]
diff --git a/doc/forum/Syncing_machines_on_different_networks/comment_5_5ce093f82a2aad3fd8d7ccd5fdcab94f._comment b/doc/forum/Syncing_machines_on_different_networks/comment_5_5ce093f82a2aad3fd8d7ccd5fdcab94f._comment
new file mode 100644
index 0000000000..c3d9d52b22
--- /dev/null
+++ b/doc/forum/Syncing_machines_on_different_networks/comment_5_5ce093f82a2aad3fd8d7ccd5fdcab94f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 5"
+ date="2012-11-05T06:43:25Z"
+ content="""
+Just a small add-up: I've already used a truecrypt volume file on a dropbox successfully, although not for a git repository. Maybe that's worth a try.
+"""]]
diff --git a/doc/forum/Syncing_machines_on_different_networks/comment_6_a55982c28d7b90e0b70ec2bb5e594e08._comment b/doc/forum/Syncing_machines_on_different_networks/comment_6_a55982c28d7b90e0b70ec2bb5e594e08._comment
new file mode 100644
index 0000000000..d5ccdcf87c
--- /dev/null
+++ b/doc/forum/Syncing_machines_on_different_networks/comment_6_a55982c28d7b90e0b70ec2bb5e594e08._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="annexuser"
+ ip="24.16.193.140"
+ subject="comment 6"
+ date="2012-11-05T17:20:50Z"
+ content="""
+Right now I use Dropbox with encfs. I could do the same thing with git-annex, but it's kind of a hassle.
+"""]]
diff --git a/doc/forum/Syncing_machines_on_different_networks/comment_7_c519d546e1a2a4e834609f3de3a605b0._comment b/doc/forum/Syncing_machines_on_different_networks/comment_7_c519d546e1a2a4e834609f3de3a605b0._comment
new file mode 100644
index 0000000000..ea4aeeaf2b
--- /dev/null
+++ b/doc/forum/Syncing_machines_on_different_networks/comment_7_c519d546e1a2a4e834609f3de3a605b0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="Quick Cloud Tip"
+ date="2012-11-21T13:16:54Z"
+ content="""
+If you have broadband, get a raspberry pi and hook up a thumb drive. Then allow ssh access through your router for really cheap cloud storage.
+"""]]
diff --git a/doc/forum/Syncing_machines_on_different_networks/comment_8_84a822238ddbaf211cce5f527c3559d3._comment b/doc/forum/Syncing_machines_on_different_networks/comment_8_84a822238ddbaf211cce5f527c3559d3._comment
new file mode 100644
index 0000000000..78c3190dbd
--- /dev/null
+++ b/doc/forum/Syncing_machines_on_different_networks/comment_8_84a822238ddbaf211cce5f527c3559d3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="163.1.167.50"
+ subject="s3ql"
+ date="2012-11-29T17:58:35Z"
+ content="""
+I am achieving success on this issue using afuse to automatically mount an s3ql volume.  Though of course you have to manually push and pull from the git repo.
+"""]]
diff --git a/doc/forum/Syncing_with___39__include__39___rule_for_duplicate_files.mdwn b/doc/forum/Syncing_with___39__include__39___rule_for_duplicate_files.mdwn
new file mode 100644
index 0000000000..6121691b25
--- /dev/null
+++ b/doc/forum/Syncing_with___39__include__39___rule_for_duplicate_files.mdwn
@@ -0,0 +1,17 @@
+I have the following problem. I have file in git annex repo which is in two places in this repo.
+So there are two links to the file in the working tree.
+Let say (for clarity) that its path is: a/foo and b/foo.
+
+And when I do:
+
+    git annex wanted . "include=a/*"
+    git annex sync --content
+
+git-annex downloads the file and then drops it
+(i.e. it try to get a/foo and then drop b/foo).
+
+What should I do to avoid droping the file when include only
+one link to the file?
+
+The only one solution to the problem I've found is to use
+deprecated 'direct' mode, but let's say I want to do this the right way.
diff --git a/doc/forum/Syncing_with___39__include__39___rule_for_duplicate_files/comment_1_5d776e90c24c4eed14ae01c6019c76b8._comment b/doc/forum/Syncing_with___39__include__39___rule_for_duplicate_files/comment_1_5d776e90c24c4eed14ae01c6019c76b8._comment
new file mode 100644
index 0000000000..db2f4ea643
--- /dev/null
+++ b/doc/forum/Syncing_with___39__include__39___rule_for_duplicate_files/comment_1_5d776e90c24c4eed14ae01c6019c76b8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-10-16T18:52:52Z"
+ content="""
+Unfortunately this is an open bug in git-annex:
+[[bugs/indeterminite_preferred_content_state_for_duplicated_file]]
+"""]]
diff --git a/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__.mdwn b/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__.mdwn
new file mode 100644
index 0000000000..9315d92180
--- /dev/null
+++ b/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__.mdwn
@@ -0,0 +1,4 @@
+I created an "full archive" repo on my local pc and an encrypted "full backup" repo on Box.com. I 'm copying files on the local repo and they are getting encrypted and uploaded to Box. Superb so far :)
+
+What I am wondering though is, suppose my local pc dies. How do I get the data out of Box unencrypted from a new pc?
+
diff --git a/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_1_cd55d06a4065b9d3f14d50674c3fcaf7._comment b/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_1_cd55d06a4065b9d3f14d50674c3fcaf7._comment
new file mode 100644
index 0000000000..5a5ec35894
--- /dev/null
+++ b/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_1_cd55d06a4065b9d3f14d50674c3fcaf7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 1"
+ date="2013-09-22T21:18:17Z"
+ content="""
+Just clone the repository on another computer or usb drive and enable box.com remote as long as you have the clone of the repo you can download your files back.
+"""]]
diff --git a/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_2_25cbdf478091af9923090e049c432a7d._comment b/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_2_25cbdf478091af9923090e049c432a7d._comment
new file mode 100644
index 0000000000..69db183e28
--- /dev/null
+++ b/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_2_25cbdf478091af9923090e049c432a7d._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="John"
+ ip="109.242.130.160"
+ subject="comment 2"
+ date="2013-09-22T22:20:22Z"
+ content="""
+Thank you Hamza!
+
+I 'm new on git, so please excuse my trivial questions:
+
+a) I am using the git-annex assistant, is it something I can do from there or is it command line only?
+I googled a bit and from what I can tell, I should make a directory on the usb drive, go there and do 
+> $ git clone /path/to/fullArchiveRepo
+
+Would that be correct?
+
+b) Assuming I 've done it correctly, then I put the USB on a drawer and leave it there for a month. In the meantime, I 've been using the repo on my pc and more files have been archived encrypted on Box.com. Then my local pc dies. When I plug the usb on the new pc, will I be able to recover all the encrypted files, or only those up to 1 month ago?
+
+c) What is the proper process to use the cloned repo on a new pc? Plug the usb drive, open the git-annex assistant and go through the \"create new repo\" but use the path for the existing repo on the usb? Then add another repo from Box (with the same account and the same directory there? Would that work?
+
+Thank you for your time & knowledge! :)
+"""]]
diff --git a/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_3_7e71d355457d6b1a0391d4cdae6895e6._comment b/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_3_7e71d355457d6b1a0391d4cdae6895e6._comment
new file mode 100644
index 0000000000..81de3fc459
--- /dev/null
+++ b/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_3_7e71d355457d6b1a0391d4cdae6895e6._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 3"
+ date="2013-09-23T00:34:24Z"
+ content="""
+I do not use the assistant I prefer command line but try adding an USB drive (last I used it it had the option) It should do the clone and init it check the resulting folder if it contains a .git/ folder you have a clone of your git repo.
+
+a) For manual cloning follow http://git-annex.branchable.com/walkthrough/adding_a_remote/
+
+b) you need to keep syncing to the clone too. asistant should automatically sync to that repo. AFAIK asisstant detects when the usb repo is plugged and automatically syncs to it (again I do not use it but I seem to remember one of joey's talks showing that. YMMV)
+
+If you lose all your repos then you lose the keys to un encrypt files they are gone!, if you have a outdated repo you can get the files back using the key stored in it but without the directory structure.
+
+Correct workflow depends on how you use annex. I sync 3 computers with annex so if one dies I can clone the repo from another one. But if you are only using it on a single computer I would use a clone on an external usb drive that is always connected, so you have two clones one on the internal disk and one on the external disk so you can survive one of the drives crashing.
+"""]]
diff --git a/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_4_a73f67f2fcf0762fbd7c8366b3844af6._comment b/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_4_a73f67f2fcf0762fbd7c8366b3844af6._comment
new file mode 100644
index 0000000000..7e649f858c
--- /dev/null
+++ b/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_4_a73f67f2fcf0762fbd7c8366b3844af6._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.220"
+ subject="comment 4"
+ date="2013-09-23T20:18:38Z"
+ content="""
+Other good options to supplement an offline backup drive:
+
+* A clone of the repository on another computer of yours, or on an Adroid tablet or phone.
+* An encrypted git repository stored on a remote ssh server. (Supported by recent git-annex releases, although the assistant does not yet have a UI to set this up it's not very hard to do it manually at the command line and then the assistant will use it.)
+"""]]
diff --git a/doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__.mdwn b/doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__.mdwn
new file mode 100644
index 0000000000..988ec30295
--- /dev/null
+++ b/doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__.mdwn
@@ -0,0 +1,11 @@
+Hello Joey,
+
+I just want to know if file transfers between three inter-connected repositories somehow gets syncronized. I have a laptop, a local file server in my home and a virtual server on the internet.
+
+Both my laptop and my file server are configured with a full git repository and connected through pairing and xmpp. The server on the internet is configured as a rsync special remote.
+
+I want the local file server to hold a copy of everything in my annex, the rsync remote should get everything except the folder "media" (too large to upload and not that important) and the laptop whatever I manually decide (preferred content is set to "present").
+
+I have added some files to the repository on the local file server and transferred their content to my laptop by using "git annex get". But when I started the web interface, I saw that those files who are present on both the file server and on the laptop get uploaded to the remote server from both computers, often the same file at the same time. Previously I though the two assistants would somehow talk to each other via xmpp so that doubled effort like that would be avoided. I'm also worried about data consistency because two apparently separate processes rsync to the same remote repository at the same time.
+
+So my question would be: Is your xmpp protocol designed to deal with situations like this and I did not set it up correctly or is what I'm trying to accomplish simply not (yet) possible?
diff --git a/doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__/comment_1_ca5192a26950627a1c2efcb55d6d2fa3._comment b/doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__/comment_1_ca5192a26950627a1c2efcb55d6d2fa3._comment
new file mode 100644
index 0000000000..dccd1d8d5e
--- /dev/null
+++ b/doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__/comment_1_ca5192a26950627a1c2efcb55d6d2fa3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 1"
+ date="2013-01-14T16:22:33Z"
+ content="""
+git-annex does not currently prevent multiple uploads of the same file to a rsync special remote. It is able to guard against this when uploading to a git remote, since then the remote runs git-annex-shell, which can detect when an upload is already running. You might want to convert your rsync remote to a git remote.
+
+I hope that rsyncing the same file twice at the same time is safe, but it's certainly excessively expensive.
+"""]]
diff --git a/doc/forum/Termux_Android_8.1_Proot_Error.mdwn b/doc/forum/Termux_Android_8.1_Proot_Error.mdwn
new file mode 100644
index 0000000000..91e7cf4538
--- /dev/null
+++ b/doc/forum/Termux_Android_8.1_Proot_Error.mdwn
@@ -0,0 +1,17 @@
+Hi,
+
+I'm trying to get git-annex working on my Google Pixel running Android version 8.1 through Termux but I'm having some difficulty.
+
+I copy-pasta'd the instructions found here: <https://git-annex.branchable.com/tips/install_on_Android_in_Termux/> until I got the following error when trying to run git-annex.linux/runshell
+
+    Running on Android.. Adding git-annex to PATH for you, and tuning for optimal behavior
+    proot error: execve("/data/data/com.termux/files/home/git-annex.linux/bin/sh"): No such file or directory
+    proot info: possible causes
+      * the program is a script but its interpreter (eg. /bin/sh) was not found;
+      * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
+      * the program is a foreign binary but qemu was not specified;
+      * qemu does not work correctly (if specified);
+      * the loader was not found or doesn't work.
+    fatal error: see `proot --help`.
+
+If I could get some help troubleshooting this that would be great. Thanks!
diff --git a/doc/forum/Termux_Android_8.1_Proot_Error/comment_1_1ef5f1b83e1bc0061d9fb1bba601a692._comment b/doc/forum/Termux_Android_8.1_Proot_Error/comment_1_1ef5f1b83e1bc0061d9fb1bba601a692._comment
new file mode 100644
index 0000000000..2ea415da1c
--- /dev/null
+++ b/doc/forum/Termux_Android_8.1_Proot_Error/comment_1_1ef5f1b83e1bc0061d9fb1bba601a692._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-07-02T16:10:36Z"
+ content="""
+termux-fix-shebang has been reported to fix that problem, some of the
+comments to the page you linked to discuss it.
+"""]]
diff --git a/doc/forum/Thank_you.mdwn b/doc/forum/Thank_you.mdwn
new file mode 100644
index 0000000000..d92baf14d5
--- /dev/null
+++ b/doc/forum/Thank_you.mdwn
@@ -0,0 +1,5 @@
+Dear Joey,
+
+Thank you very much for git-annex. This is an awesome software. I'm using it every day, for music, movies, softwares, photos... Using encryption with S3 is so convenient. Moreover, it seems you put a lot of effort in its documentation. Thank you for that, too.
+
+PS : even if I've been using gti-annex for a few years, I just discovered the --jobs parameter. It speeds up downloads and uploads **a lot**.
diff --git a/doc/forum/Thank_you/comment_1_3be1d5e92c3abc222713c75169b43dfb._comment b/doc/forum/Thank_you/comment_1_3be1d5e92c3abc222713c75169b43dfb._comment
new file mode 100644
index 0000000000..c118968bfd
--- /dev/null
+++ b/doc/forum/Thank_you/comment_1_3be1d5e92c3abc222713c75169b43dfb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ghen1"
+ avatar="http://cdn.libravatar.org/avatar/efd0e92b6198291138f0cd7aedbf86b6"
+ subject="comment 1"
+ date="2020-06-22T20:40:08Z"
+ content="""
+I second this. I've used it every day since discovering it to manage file storage across several locations. Would have had to hack something together on my own otherwise, and that wouldn't be easy. git-annex is one of the best ideas ever.
+"""]]
diff --git a/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__.mdwn b/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__.mdwn
new file mode 100644
index 0000000000..627e3b7360
--- /dev/null
+++ b/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__.mdwn
@@ -0,0 +1,3 @@
+Sometimes I'm doing something crazy like working in a large GIMP file, and I just want to be able to keep "committing" the changes to the annex but I hate running into the problem of having to keep unlocking the file over and over again while saving.  I guess one solution to this might be to use git-annex assistant?  But I'm not sure I really want a daemon running, and I don't want this auto-added... I just want to be able to leave the file unlocked while I'm actively working on it, then eventually say "I'm done with this!" and set it back to a state where it's locked.
+
+Basically, I hate running into "permission denied" errors all the time when I'm saving!  I guess I could do some sort of command where I commit to the annex and then immediately unlock again... is there a better way?
diff --git a/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_1_3cbe520b184d323219cb402ff046c3b4._comment b/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_1_3cbe520b184d323219cb402ff046c3b4._comment
new file mode 100644
index 0000000000..fac3628923
--- /dev/null
+++ b/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_1_3cbe520b184d323219cb402ff046c3b4._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="http://identi.ca/cwebber/"
+ nickname="cwebber"
+ subject="Reasonable solution?"
+ date="2012-11-27T21:24:49Z"
+ content="""
+I think I have built a reasonable solution... this function checks a specific file into git and then immediately unlocks it.
+
+    function git-annex-unlocked-commit {
+        if [ $# -ne 2 ]; then
+            echo \"Wrong number of args.\"
+            return 1
+        fi
+    
+        if [ ! -e \"$1\" ]; then
+            echo \"Need a filename!\"
+            return 1
+        fi
+    
+        read -p \"Really do an unlocked commit? (y/n): \"
+        if [ \"$REPLY\" == \"y\" ]; then
+            git commit $1 -m \"$2\" && git annex unlock $1
+        fi
+    }
+
+Use it like:
+
+    git-annex-unlocked-commit mediagoblin_postcard.xcf \"Starting to fill in spencer\"
+"""]]
diff --git a/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_2_6afe7f593e955db2eefe87d9fa01882b._comment b/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_2_6afe7f593e955db2eefe87d9fa01882b._comment
new file mode 100644
index 0000000000..c515372b13
--- /dev/null
+++ b/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_2_6afe7f593e955db2eefe87d9fa01882b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 2"
+ date="2012-11-27T21:27:33Z"
+ content="""
+The only thing I would do differently is \"git annex add\" the file before \"git commit\". This is more efficient for large files since it avoids git looking at the whole file content.
+"""]]
diff --git a/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_3_209399487fc4f76b29f03ad82dbc2d6f._comment b/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_3_209399487fc4f76b29f03ad82dbc2d6f._comment
new file mode 100644
index 0000000000..c59c7fe6f8
--- /dev/null
+++ b/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_3_209399487fc4f76b29f03ad82dbc2d6f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://identi.ca/cwebber/"
+ nickname="cwebber"
+ subject="comment 3"
+ date="2012-11-27T21:30:11Z"
+ content="""
+Just in case, since I don't see licensing stuff on this wiki: copyright to that code waived under CC0. :) http://creativecommons.org/publicdomain/zero/1.0/
+"""]]
diff --git a/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_4_f33fd6f72cb9ad7dd20a04c82199413b._comment b/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_4_f33fd6f72cb9ad7dd20a04c82199413b._comment
new file mode 100644
index 0000000000..ba6baad91e
--- /dev/null
+++ b/doc/forum/The_ability_to_leave_a_file_unlocked_for_a_bit_while_committing_it_repeatedly__63__/comment_4_f33fd6f72cb9ad7dd20a04c82199413b._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://identi.ca/cwebber/"
+ nickname="cwebber"
+ subject="comment 4"
+ date="2012-11-27T23:58:10Z"
+ content="""
+Ah, thanks Joey... here's an updated version:
+
+    function git-annex-unlocked-commit {
+        if [ $# -ne 2 ]; then
+            echo \"Wrong number of args.\"
+            return 1
+        fi
+    
+        if [ ! -e \"$1\" ]; then
+            echo \"Need a filename!\"
+            return 1
+        fi
+    
+        read -p \"Really do an unlocked commit? (y/n): \"
+        if [ \"$REPLY\" == \"y\" ]; then
+            git add $1 && git commit $1 -m \"$2\" && git annex unlock $1
+        fi
+    }
+
+"""]]
diff --git a/doc/forum/The_future_of_Direct_Mode.mdwn b/doc/forum/The_future_of_Direct_Mode.mdwn
new file mode 100644
index 0000000000..8c295eb1f4
--- /dev/null
+++ b/doc/forum/The_future_of_Direct_Mode.mdwn
@@ -0,0 +1,32 @@
+Hello everyone. I could use some pointers from experienced users. Here is my use-case:
+
+I have a number of portable storage devices where I store media files. They serve a number of purposes:
+
+  1. as archives and backup where I put away the data I am not using to allow for more free space on my work PC;
+
+  2. as storage for the media I play on a media playing device (that only supports Windows filesystems);
+
+  3. as transport medium to share files with other people (that are Windows-users).
+
+I wanted to use git-annex to manage/organize/locate all these devices, but without breaking too much my system. Most files are not super-important, and I intend to keep multiple copies of those that are.
+The main issue is that points 2 and 3 require that the real files need to be accessible directly. I *could* work around this using an extra device, but that would be much less practical, as I would need to go to the PC and transfer the large files over USB, so I am trying to avoid that.
+
+Here is what I learned so far:
+
+  - Indirect mode is OK on my PC. No problem there. However, it won't work on VFAT or NTFS, so I can't use it on the portable devices.
+
+  - Direct mode seems to work fine on the portable devices, but is now deprecated. It won't work on the V6 repositories.
+
+  - The new V6 repositories allows for the unlocking of files, replacing the link-like files (on Windows filesystems) with the real files, that allows me to browse them on the media player (by path and name). I did not find a way to keep them always unlocked by default, so I guess I would need to unlock them manually. Also, I would be keeping an extra copy of each file, since `annex.thin` won't work. In addition, as I don't expect to be editing any these files (not on these devices, at least), the loss of half the storage capacity is wasteful and undesirable.
+
+  - Special remotes `directory` and `rsync` do not keep the original structure of the system, and for this reason do not fit for my purposes.
+
+For now I can create V5 repositories and use direct mode on the external devices. I think this could work quite well, but I have the following questions:
+
+  1. Am I missing something that could help me?
+
+  2. Will using V5 repositories be somewhat future-proof? I mean, will I be able to create V5 repositories in the future? How much of a bad idea would it be to start using git-annex depending on "old versions"? I understand that direct mode will continue to be supported, but deprecation indicates it is a bad idea.
+
+  3. I am guessing that "direct mode" will not be making a comeback, but it does have its uses — however, I did not expect that my case was an unusual one. Is there anything on V6 repositories that would make new version more adequate to my requirements? I would not mind having the files read-only or facing similar restrictions if it helped simplify things.
+
+Thank you for your time.
diff --git a/doc/forum/The_future_of_Direct_Mode/comment_1_f16f6e41f01d59ccef9666a2ec46d294._comment b/doc/forum/The_future_of_Direct_Mode/comment_1_f16f6e41f01d59ccef9666a2ec46d294._comment
new file mode 100644
index 0000000000..64f7373c27
--- /dev/null
+++ b/doc/forum/The_future_of_Direct_Mode/comment_1_f16f6e41f01d59ccef9666a2ec46d294._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-02-12T18:21:38Z"
+ content="""
+I guess that fully getting rid of direct mode is a couple of years out.
+
+First, [[design/adjusted_branches]] needs to be implemented, to allow
+locked files to appear as unlocked automatically when a repository is
+checked out on a device that doesn't support symlinks.
+
+Then, a git-annex version with good enough support for v6 unlocked files
+needs to have been around long enough that basically everyone has upgraded.
+So in various stable and long term support version of linux distros, etc.
+Only at that point could direct mode repositories be automatically updated
+to v6 repositories.
+
+And yeah, it's potentially a problem that annex.thin doesn't work on
+Windows or FAT, and so converting such a repository doubles the disk use.
+I've added a note to [[todo/smudge]] to remember this is a potential thing
+to be improved before getting rid of direct mode. I think there are a
+couple of approaches that could avoid the problem.
+
+So, I recommend not being put off from using direct mode today out of
+worries that it might be removed 3 years from now.
+
+(You mentioned repeatedly unlocking. You shouldn't need to do that.
+In a V6 repository, when you unlock a file, that changes how it's
+represented in the git repository, so you can commit that change and it
+will be unlocked in other clones too. And if you `git add` large files,
+they'll be unlocked by default and you don't need to unlock them.)
+"""]]
diff --git a/doc/forum/The_future_of_Direct_Mode/comment_2_c7408d45d0a2a854020e4169fe757d51._comment b/doc/forum/The_future_of_Direct_Mode/comment_2_c7408d45d0a2a854020e4169fe757d51._comment
new file mode 100644
index 0000000000..e0448a9615
--- /dev/null
+++ b/doc/forum/The_future_of_Direct_Mode/comment_2_c7408d45d0a2a854020e4169fe757d51._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Gus"
+ subject="Thanks"
+ date="2016-02-12T21:47:53Z"
+ content="""
+Thank you for your help.
+"""]]
diff --git a/doc/forum/This_account_is_restricted_by_rssh._Allowed_commands__58___scp_rsync__160__.mdwn b/doc/forum/This_account_is_restricted_by_rssh._Allowed_commands__58___scp_rsync__160__.mdwn
new file mode 100644
index 0000000000..932c78a9a8
--- /dev/null
+++ b/doc/forum/This_account_is_restricted_by_rssh._Allowed_commands__58___scp_rsync__160__.mdwn
@@ -0,0 +1,5 @@
+Hello,
+
+I'm using the git-annex assistant (in Mac Mavericks) and I'm trying to create a new remote rsync repo, I have the details and everything but I can't do it over ssh, I need the call to use rsync otherwise I get: **This account is restricted by rssh. Allowed commands: scp rsync ** . Can this be changed manually? How can I create a remote rsync repo?
+
+Thanks
diff --git a/doc/forum/This_account_is_restricted_by_rssh._Allowed_commands__58___scp_rsync__160__/comment_1_68e911629da672473bd6188407a68be2._comment b/doc/forum/This_account_is_restricted_by_rssh._Allowed_commands__58___scp_rsync__160__/comment_1_68e911629da672473bd6188407a68be2._comment
new file mode 100644
index 0000000000..b6fa2d1a18
--- /dev/null
+++ b/doc/forum/This_account_is_restricted_by_rssh._Allowed_commands__58___scp_rsync__160__/comment_1_68e911629da672473bd6188407a68be2._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-02T15:33:58Z"
+ content="""
+You can set it up manually at the command line, and one it's set up, the assistant will be able to transfer files to it using rsync. See [[special_remotes/rsync]] for some setup examples. Note that the rsync server will need to be configured, somehow, to let you log in without giving a password -- one typical way this might be set up is using .ssh/authorized_keys on the rsync server.
+
+The assistant doesn't try to set up rsync special remotes because this is not very common, and there's no one way it can use to set up a ssh key so it can log in without a password
+that will work across different rsync server setups. It does support setting up rsync.net just because that's one I know how to handle.
+
+
+"""]]
diff --git a/doc/forum/Thoughts_on_glacier_remotes_for_archive_purposes.mdwn b/doc/forum/Thoughts_on_glacier_remotes_for_archive_purposes.mdwn
new file mode 100644
index 0000000000..74d81a029e
--- /dev/null
+++ b/doc/forum/Thoughts_on_glacier_remotes_for_archive_purposes.mdwn
@@ -0,0 +1,22 @@
+Hello everyone,
+
+We are distributing large datasets with git-annex under our own infrastructure (for scientific purposes) and we need to implement long term backups on a different site. What is most important for us is to backup the original data files which are expensive to produce. These backups should only be retrieved in case of a disaster, so retrieval costs and delays don't really matter, what matters the most is to keep storage costs as low as possible. Amazon Glacier is therefore a good fit for this purpose.
+
+At first sight the easiest way was to use glacier special remotes, as it makes it very easy to backup the files we need with `git annex copy`. Another advantage is hybrid encryption : git-annex allows flexible end-to-end encryption with decryption keys redundancy.
+
+*However*, there seems to be a few pitfalls :
+
+1. What if a disaster occurs and we lose the git repository all the whole history/git-annex branch ? Could we still recover the data itself with this strategy ? First assuming no encryption, then assuming encryption and that we have access to only the cipher (stored in remote.log) and at least one decryption private key. Since we would not be able to `git-annex get` the files, it will be painful - but I am wondering if this is even possible at all as for instance Glacier vaults don't seem to store filenames...
+
+2. Datasets might undergo updates after being archived. We are not very interested in backing up these updates or very infrequently, as Glacier archives are meant to backup the underlying data in our case. But what if e.g. some large files are moved or merged ? Will this break `git annex get` ? 
+
+3. [glacier-cli](https://github.com/basak/glacier-cli) does not seem to be actively maintained. For instance, it breaks with python3 (had to use python2.7 to git annex get files). Glacier is meant for long term backups. Wouldn't it be a problem if breaking changes occur at some level (AWS/boto) and glacier-cli remains outdated ? It seems to be more plausible than a failure with Glacier itself.
+
+Based on these considerations, I am wondering whether we should consider other options, including :
+
+ - not using glacier but s3 w/ glacier storage class
+ - not using git-annex at all for the archives but rclone for instance
+
+I am also wondering if glacier would be suited for frequent backups, without uncontrolled costs - even though this is not really our need here, the most important is to have a copy of the data after it's been organised and cleaned up.
+
+Thank you for your insights !
diff --git a/doc/forum/Thoughts_on_glacier_remotes_for_archive_purposes/comment_1_c874e49e668baa1fed293318cef88dd0._comment b/doc/forum/Thoughts_on_glacier_remotes_for_archive_purposes/comment_1_c874e49e668baa1fed293318cef88dd0._comment
new file mode 100644
index 0000000000..72cfcf5479
--- /dev/null
+++ b/doc/forum/Thoughts_on_glacier_remotes_for_archive_purposes/comment_1_c874e49e668baa1fed293318cef88dd0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2020-11-24T18:35:16Z"
+ content="""
+I don't have any experience with S3, but there is a [[git remote s3 helper|https://github.com/bgahagan/git-remote-s3]]. So you can store data via s3 special remote and the metadata via git-remote-s3.
+"""]]
diff --git a/doc/forum/Thoughts_on_glacier_remotes_for_archive_purposes/comment_2_28926e01b82de55352702182730a6b4b._comment b/doc/forum/Thoughts_on_glacier_remotes_for_archive_purposes/comment_2_28926e01b82de55352702182730a6b4b._comment
new file mode 100644
index 0000000000..cd13d415b0
--- /dev/null
+++ b/doc/forum/Thoughts_on_glacier_remotes_for_archive_purposes/comment_2_28926e01b82de55352702182730a6b4b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="basak"
+ avatar="http://cdn.libravatar.org/avatar/b85cacece5b347853dc35d97371b9e0c"
+ subject="comment 2"
+ date="2020-12-02T02:12:58Z"
+ content="""
+1. Realistically, you do need the git branches to restore, as well as the contents of the special remote. This applies to git-annex and special remotes in general. Otherwise you'll have all the content, but not the filenames the content belong to. It is relatively easy to back the git branches up though - they're small (metadata only, if you add all data files through git-annex) and git being natively distributed makes it easy. You do need to do it though - which means that relying on Glacier special remote for disaster recovery isn't on its own enough.
+
+2. git-annex uses content addressed storage. If you make a change (see `git annex lock` and `git annex unlock`), you're effectively adding a new file, and you can decide whether to keep the old file or not. git-annex will handle whichever you leave in your git branch and regardless of what it's named.
+
+3. I'm the glacier-cli author and I'm still around. Are you the person who filed the issue on Python 3 support the other day? I haven't had a chance to look yet. Mostly glacier-cli is trivial (it's really not much code - take a look!), \"done\", and I'll take PRs to fix it to work against the latest boto library version, which is what I assume is the problem. I would have wrote it against Python 3 to start with only boto didn't support Python 3 at the time. glacier-cli is designed to be a \"thin\" wrapper - it doesn't use any special format - your git-annex data just ends up in Glacier as-is, so it should be extractable with relatively straightforward effort with any other tool, not just glacier-cli. However glacier-cli is still just something I wrote and maintain in my spare time, so if you aren't confident diving in to fix something if I'm not available or vanish, and you're not sure about finding someone else to do that either, then that's fair enough.
+"""]]
diff --git a/doc/forum/Time_for_another_user_survey__63__.mdwn b/doc/forum/Time_for_another_user_survey__63__.mdwn
new file mode 100644
index 0000000000..66b10ca7ce
--- /dev/null
+++ b/doc/forum/Time_for_another_user_survey__63__.mdwn
@@ -0,0 +1,2 @@
+Hi, <br>
+I guess it's time for another user survey.
diff --git a/doc/forum/Time_for_another_user_survey__63__/comment_1_e746e11d30049906758a015059658e16._comment b/doc/forum/Time_for_another_user_survey__63__/comment_1_e746e11d30049906758a015059658e16._comment
new file mode 100644
index 0000000000..04db7d708f
--- /dev/null
+++ b/doc/forum/Time_for_another_user_survey__63__/comment_1_e746e11d30049906758a015059658e16._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-30T16:51:50Z"
+ content="""
+Is git still doing user surveys? I used to do the git-annex survey at the
+same time, which was usually in the fall, and had some of the same
+questions to be able to compare data. But the last git survey I can
+find mentioned was in 2016.
+"""]]
diff --git a/doc/forum/Timeline_of_git_reinject__63__.mdwn b/doc/forum/Timeline_of_git_reinject__63__.mdwn
new file mode 100644
index 0000000000..af6761de4b
--- /dev/null
+++ b/doc/forum/Timeline_of_git_reinject__63__.mdwn
@@ -0,0 +1,50 @@
+# Context
+
+I'm currently using `git annex reinject --known` to deduplicate directories containing dozens number of huge (up to 4-13 Gb) files.
+Let's focus on one example big file.
+
+The file being reinjected is not already available in `.git/annex/objects`. It will be after `git annex reinject --known` completes.
+The file being reinjected is on a different filesystem on the same disk. This might be important.
+
+# Time taken to process one file.
+
+It's done in the background on a server and yields a log that shows how much time passes.
+
+It looks like:
+
+```
+reinject my_big_file.dv    (7 minutes pass)
+(checksum...)    (20 minutes pass)
+ok
+```
+
+`my_big_file.dv` is 8.7G big. 
+
+With the USB2 bandwith available, reading that file can take between 7 and 12 minutes.
+
+# What happens?
+
+* 7 minutes is a reasonable time to read the whole file
+* after "checksum..." appears, 20 minutes pass which is a reasonable time to move the file to the partition containing git-annex repository ... or to read it twice?
+
+This looks "mostly reasonable", perhaps a little long.
+
+Source code in Hash.hs says:
+
+	mstat <- liftIO $ catchMaybeIO $ getFileStatus file
+	case (mstat, fast) of
+		(Just stat, False) -> do
+			filesize <- liftIO $ getFileSize' file stat
+			showAction "checksum"
+			check <$> hashFile hash file filesize
+		_ -> return True
+
+
+I expected "checksum..." to appear *before* the checksum is actually computed, and source code appears to confirm that (trying to compensate ignorance of Haskell with knowledge of OCaml, pure functions, closures, functional programming, including C# and reactive programming).
+
+# Questions
+
+* Is it true that checksum is computed after "checksum..." appears?
+* Why do 7 minute pass before "checksum..." appear? What happens?
+* What happens in the 20 minutes after "checksum..." appear and before "ok"?
+
diff --git a/doc/forum/Timeline_of_git_reinject__63__/comment_1_e88d612590d3cd0c2ea824c1e8a38678._comment b/doc/forum/Timeline_of_git_reinject__63__/comment_1_e88d612590d3cd0c2ea824c1e8a38678._comment
new file mode 100644
index 0000000000..50d9aa68fb
--- /dev/null
+++ b/doc/forum/Timeline_of_git_reinject__63__/comment_1_e88d612590d3cd0c2ea824c1e8a38678._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-07T16:02:28Z"
+ content="""
+What turns out to have been going on here is the file was first checksummed
+silently to get the key and see if it is --known, 
+and then checksummed a second time (with the message displayed) as part of
+the reinject process.
+
+So, the second checksum is not needed in --known mode and I've made it not
+be done.
+
+It might be that the "(checksum)" message should be displayed during the
+intial checksum of the file. git-annex used to always say when it
+checksummed, but [[!commit 64160a96795d03ee791faa4757057200934687bc]] got
+rid of that in most cases. I guess that "reinject bigfile <13 minute wait> ok"
+is acceptable output though.
+"""]]
diff --git a/doc/forum/Timeout_sync_faster__63__.mdwn b/doc/forum/Timeout_sync_faster__63__.mdwn
new file mode 100644
index 0000000000..6bebcdac56
--- /dev/null
+++ b/doc/forum/Timeout_sync_faster__63__.mdwn
@@ -0,0 +1,8 @@
+I've re-connected my PC and laptop directly again (previously, they could only see each other via a NAS) to get location tracking to work at its best but now that I have, there's an issue:
+
+My laptop is a MBP that goes to sleep and, on battery, can't even be woken up. When it does this, trying to sync with it completely stalls git-annex. It doesn't even push my local changes to the NAS anymore because it's waiting on the laptop that won't ever answer until I manually wake it.
+
+I don't care if that machine is unreachable temporarily, it happens. Ideally git-annex shouldn't be dead-set on trying to sync with it or even treat being unable to sync with it as an error.  
+Can I reach that behaviour or at least stop it from stalling somehow (a timeout perhaps)?
+
+I've looked through the options but couldn't find anything that seemed relevant.
diff --git a/doc/forum/Timeout_sync_faster__63__/comment_1_eb4c13c1ad9803f402215478c0baab2b._comment b/doc/forum/Timeout_sync_faster__63__/comment_1_eb4c13c1ad9803f402215478c0baab2b._comment
new file mode 100644
index 0000000000..f82edbd8b4
--- /dev/null
+++ b/doc/forum/Timeout_sync_faster__63__/comment_1_eb4c13c1ad9803f402215478c0baab2b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 1"
+ date="2021-05-19T17:13:45Z"
+ content="""
+After observing the issue over the past few days, it has become a bit clearer now.
+
+The stalling happens when both machines are on, have synced and then one of them goes offline. The assistant never recovers from the loss of connection and since this also stalls manual syncs, this might be because of the SSH caching thingy? I will try disabling it and see whether that helps.
+
+I guess this probably is a bug then; could this post be moved (and possibly renamed) or should I create a separate bug for this?
+"""]]
diff --git a/doc/forum/Timeout_sync_faster__63__/comment_2_16d655b754d2d512c2b01bac8276f31c._comment b/doc/forum/Timeout_sync_faster__63__/comment_2_16d655b754d2d512c2b01bac8276f31c._comment
new file mode 100644
index 0000000000..8fec7152d2
--- /dev/null
+++ b/doc/forum/Timeout_sync_faster__63__/comment_2_16d655b754d2d512c2b01bac8276f31c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-05-21T16:19:44Z"
+ content="""
+You may want to set ServerAliveInterval in your ssh config,
+or some of the related options like ServerAliveCountMax and
+TCPKeepAlive. See `man ssh_config`
+
+I think that normally, ssh does detect when a connection to a server has
+gone away, just due to the tcp connection dropping. But that may take some
+time to happen.
+"""]]
diff --git a/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories.mdwn b/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories.mdwn
new file mode 100644
index 0000000000..898d4870ae
--- /dev/null
+++ b/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories.mdwn
@@ -0,0 +1 @@
+In my documents folder I have some Mercurial and Git repositories. Are there any side effects if I track the whole directory with git annex?
diff --git a/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_1_9fc3f6c2f7379755e0084a850fa9acd4._comment b/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_1_9fc3f6c2f7379755e0084a850fa9acd4._comment
new file mode 100644
index 0000000000..c61ea9a4d5
--- /dev/null
+++ b/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_1_9fc3f6c2f7379755e0084a850fa9acd4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2013-12-27T19:05:59Z"
+ content="""
+I don't recommend using git-annex that way.
+
+.git directories cannot be checked into git, so will just be skipped. A hg repository will be checked in, but you can get into all kinds of bad situations if making commits to the \"same\" hg repository in two different locations. You will end up having to manually resolve conflicted merges to the files used by your distributed version control system, which defeats the point of using distributed version control.
+"""]]
diff --git a/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_2_f024d6a105143af1e06aafe49661ee06._comment b/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_2_f024d6a105143af1e06aafe49661ee06._comment
new file mode 100644
index 0000000000..50b94ffaf6
--- /dev/null
+++ b/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_2_f024d6a105143af1e06aafe49661ee06._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnX1msQxnLoSeu7q-i-c9BWghonsN7Qmns"
+ nickname="Jan Ulrich"
+ subject="Thanks!"
+ date="2013-12-27T20:02:20Z"
+ content="""
+Ok, I feared that answer. I'll have to change my directory structure. 
+"""]]
diff --git a/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_3_aff0093c38bda8b093f05e8cbe8775e9._comment b/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_3_aff0093c38bda8b093f05e8cbe8775e9._comment
new file mode 100644
index 0000000000..7108ddea3a
--- /dev/null
+++ b/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_3_aff0093c38bda8b093f05e8cbe8775e9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 3"
+ date="2013-12-27T20:08:07Z"
+ content="""
+Well, you can always use .gitignore to ignore the whole content of the directory that you don't want git-annex to handle.
+"""]]
diff --git a/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_4_c889050d3079edefc4633451bd5baff8._comment b/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_4_c889050d3079edefc4633451bd5baff8._comment
new file mode 100644
index 0000000000..55f9f2534e
--- /dev/null
+++ b/doc/forum/Tracking_a_directory_with_some_hg_and_git_repositories/comment_4_c889050d3079edefc4633451bd5baff8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnvVfFLW4CTKs7UjdiLIsOn_cxj1Jnh64I"
+ nickname="Charl"
+ subject="use case: changing workstations mid-way through development session"
+ date="2014-03-23T21:22:15Z"
+ content="""
+An important use case for me with automatic synchronization, is being able to change computers mid-way through a development session. I used to do this with dropbox for years: I'd work in a git checkout, then take another laptop to go work elsewhere, and just continue in the \"same\" synchronized git repo. Having to remember to commit and push a long list of repos before changing workstations is error-prone. Also, I prefer to commit when a discrete atom of work has been completed, and to push when a topic branch is good and ready to be merged (for example), not every time that I feel like changing workstations. :) Dropbox never dropped a stitch in all this time. As long as all laptops are in a 1) connected and 2) synced up state, switching is possible.
+
+The limitation of not being able to sync the .git directories in git checkouts means that this use case can't currently be supported by git-annex (assistant). Is a work-around possible, or is this something that can't ever be supported due to the limitations of git itself?
+
+"""]]
diff --git a/doc/forum/Transfer_remotes.mdwn b/doc/forum/Transfer_remotes.mdwn
new file mode 100644
index 0000000000..eb03f3166e
--- /dev/null
+++ b/doc/forum/Transfer_remotes.mdwn
@@ -0,0 +1,3 @@
+Hi!
+
+I have a laptop A on which I setup a box.com special remote as a transfer encrypted repository. It is quite unclear to me how I should configure laptop B to use the same box.com remote and share files between the two machines.
diff --git a/doc/forum/Transfer_remotes/comment_1_c08cf3bda00d7f20a3ca3d0fdba19c9c._comment b/doc/forum/Transfer_remotes/comment_1_c08cf3bda00d7f20a3ca3d0fdba19c9c._comment
new file mode 100644
index 0000000000..7b5de17a0d
--- /dev/null
+++ b/doc/forum/Transfer_remotes/comment_1_c08cf3bda00d7f20a3ca3d0fdba19c9c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
+ nickname="Tobias"
+ subject="Screencast"
+ date="2013-04-11T09:59:24Z"
+ content="""
+Maybe this screencasts helps: [git-annex assistant remote sharing](http://git-annex.branchable.com/videos/git-annex_assistant_remote_sharing/)
+"""]]
diff --git a/doc/forum/Transfer_remotes/comment_2_98930629d398329f1161135464a966a5._comment b/doc/forum/Transfer_remotes/comment_2_98930629d398329f1161135464a966a5._comment
new file mode 100644
index 0000000000..1ce26e5b20
--- /dev/null
+++ b/doc/forum/Transfer_remotes/comment_2_98930629d398329f1161135464a966a5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://cyprio.net/"
+ nickname="oz"
+ subject="versions?"
+ date="2013-04-15T22:50:31Z"
+ content="""
+Well, in the screencast it seems to work alright.
+
+I only get a \"Syncing with laptop B\" on one side, nothing more happens. I'm not sure if there is a recommended version to follow this screencast, or if the versions need to match (I'm syncing between macos & linux/debian, and the mac packages are lagging behind).
+
+My guess is that the assistant is simply \"not there yet\": using git-annex manually works just fine, but the assistant... ew. :/
+"""]]
diff --git a/doc/forum/Transparent_compression_of_files.mdwn b/doc/forum/Transparent_compression_of_files.mdwn
new file mode 100644
index 0000000000..2b3a28a35f
--- /dev/null
+++ b/doc/forum/Transparent_compression_of_files.mdwn
@@ -0,0 +1,5 @@
+Hi,
+
+I have a lot of files which are around 80MB and can be easily compressed down to ~55MB. I did some tests with brotli and decompression was reasonable fast, at least fast enough that I would probably not notice given my current transfer speeds. In order to save disk space I would like to able to transparently compress my files. That means, a file is stored compressed in git-annex's blob store and decompressed when I `get` it.
+
+I understand that gpg does compression, but I don't want to deal with encryption, all my repos are local. I've looked at the code and from what I could see the Hash-Backends are rather simple. However, that's probably not the right place. Is this a planned feature? Would it be hard to implement? Of course, ideally the compression algorithm should be configurable. E.g. by just doing a syscall to `brotli` or `gzip`.
diff --git a/doc/forum/Transparent_compression_of_files/comment_1_7242325defa000572ca8e78e29012451._comment b/doc/forum/Transparent_compression_of_files/comment_1_7242325defa000572ca8e78e29012451._comment
new file mode 100644
index 0000000000..a2a96f1b77
--- /dev/null
+++ b/doc/forum/Transparent_compression_of_files/comment_1_7242325defa000572ca8e78e29012451._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 1"
+ date="2020-02-13T12:29:40Z"
+ content="""
+It's quite easy to implement an [external special remote](https://git-annex.branchable.com/special_remotes/external/) that does transparent compression. You can use the example implementations of the directory remote as a starting point (see [Bash](https://git-annex.branchable.com/special_remotes/external/example.sh/) or [Python](https://github.com/Lykos153/AnnexRemote/blob/master/examples/git-annex-remote-directory)). Then just modify the dostore() and doretrieve() functions to your liking. You probably don't want to support exporting when compression is enabled, though.
+"""]]
diff --git a/doc/forum/Transparent_compression_of_files/comment_2_a75e32b0825de0b405c45de14b9711c0._comment b/doc/forum/Transparent_compression_of_files/comment_2_a75e32b0825de0b405c45de14b9711c0._comment
new file mode 100644
index 0000000000..a1ba8b4d4b
--- /dev/null
+++ b/doc/forum/Transparent_compression_of_files/comment_2_a75e32b0825de0b405c45de14b9711c0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="jochen.keil@38b1f86ab65128dab3e62e726403ceee4f5141bf"
+ nickname="jochen.keil"
+ avatar="http://cdn.libravatar.org/avatar/a1329c0b3a262017553cc5497aa12c18"
+ subject="comment 2"
+ date="2020-02-14T12:04:53Z"
+ content="""
+Thanks for your hint, I appretiate that and I think it could be done that way.
+
+However, on closer thought I was wondering if git-annex is the right tool for job. I had the impression that my idea came more from a hammer and nail situation. So, FUSE came to my mind. I popped it into google and found this: https://github.com/FS-make-simple/fusecompress
+Unfortunately this does not look very active though.
+
+Now, since I'm already at the FS layer I can look into ZFS compression. My repos are already on ZFS but I haven't looked at the built-in compression yet. I think I'll evaluate that first. If none of that is satisfactory I'll turn to git-annex again :)
+"""]]
diff --git a/doc/forum/Transparent_compression_of_files/comment_3_a876239d4a2fe96f2e2fe1c16e7f202b._comment b/doc/forum/Transparent_compression_of_files/comment_3_a876239d4a2fe96f2e2fe1c16e7f202b._comment
new file mode 100644
index 0000000000..d4d34b9563
--- /dev/null
+++ b/doc/forum/Transparent_compression_of_files/comment_3_a876239d4a2fe96f2e2fe1c16e7f202b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jochen.keil@38b1f86ab65128dab3e62e726403ceee4f5141bf"
+ nickname="jochen.keil"
+ avatar="http://cdn.libravatar.org/avatar/a1329c0b3a262017553cc5497aa12c18"
+ subject="comment 3"
+ date="2020-11-09T13:15:40Z"
+ content="""
+Just a quick update:
+
+I've enabled zfs compression on my backup storage and couldn't be happier. Same goes for btrfs volumes. If one would like to narrow it down it's easy to create separate volumes (for zfs and btrfs) with different compression settings. I think that's the way to go, adding compression to btrfs would be just re-inventing the wheel.
+"""]]
diff --git a/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows.mdwn b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows.mdwn
new file mode 100644
index 0000000000..08da616a86
--- /dev/null
+++ b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows.mdwn
@@ -0,0 +1,19 @@
+Hi, just trying to set up git-annex-assistant on freshly installed windows 10. I've run the web app and created a local repo. I also grabbed the tarball on my server and ran "git-annex" with no arguments (?). I'm now trying to add remote server using ssh. I add the correct details and click "Check this server", at which point it displays "Testing Server, Checking ssh connection to the server. This could take a minute". indefinitely.
+
+I've checked the log and don't see any ssh errors, but I do see some weirdness:
+
+```
+(scanning...) [2015-06-29 19:02:36 GMT Summer Time] Watcher: Performing startup scan
+(started...) rerrrrrrceereeeevccecccc:vvcvvvv ::v::::f  :    aff ffffiaafaaaaliiaiiiiellilllldeeleeee ddedddd(  d    N(( ((((oNN(NNNN ooNooooe  o    ree eeeerrrerrrrorrrrrrrrooroooo)rrorrrr
+))r))))
+
+)
+
+rerrrceeevccc:vvv :::f   afffiaaaliiiellldeee ddd(   N(((oNNN oooe   reeerrrrorrrrooo)rrr
+)))
+
+rerrrrrrrrrrrrrceeeeeeeeeeeeevccccccccccccc:vvvvvvvvvvvvv :::::::::::::f             afffffffffffffiaaaaaaaaaaaaaliiiiiiiiiiiiiellllllllllllldeeeeeeeeeeeee ddddddddddddd(             N(((((((((((((oNNNNNNNNNNNNN oooooooooooooe             reeeeeeeeeeeeerrrrrrrrrrrrrrorrrrrrrrrrrrrrooooooooooooo)rrrrrrrrrrrrr
+)))))))))))))
+```
+
+Not sure what that is but it might be relevant? Any help would be appreciated.
diff --git a/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_1_0055392bfead0dd1d9dc1a196a6e5269._comment b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_1_0055392bfead0dd1d9dc1a196a6e5269._comment
new file mode 100644
index 0000000000..74a4ae025b
--- /dev/null
+++ b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_1_0055392bfead0dd1d9dc1a196a6e5269._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T20:53:54Z"
+ content="""
+This particular feature is unfortunately currently broken on Windows.
+
+I have developed a fix, but am waiting on it getting into a library I use.
+See [[bugs/windows_ssh_webapp_password_entry_broken]].
+
+As a workaround, if you can manually set up a passwordless ssh key on
+Windows, and configure the remote server to let you log in using that key,
+the webapp can then be used to add a repository on the server.
+"""]]
diff --git a/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_2_3ec8af32b8148d31aaa3ba781b4dcf89._comment b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_2_3ec8af32b8148d31aaa3ba781b4dcf89._comment
new file mode 100644
index 0000000000..c16f7e3775
--- /dev/null
+++ b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_2_3ec8af32b8148d31aaa3ba781b4dcf89._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="acous"
+ subject="comment 2"
+ date="2015-07-07T22:25:40Z"
+ content="""
+Thanks, that did the trick. Am I right to assume that git-remote-gcrypt is not compatible with windows? I have cygwin set up which I could try to install it into, but I expect git-annex-assistant only has access to stuff available from the standard command prompt.
+"""]]
diff --git a/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_3_8ddec87534a9025c26394fecd5456b84._comment b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_3_8ddec87534a9025c26394fecd5456b84._comment
new file mode 100644
index 0000000000..07fefd2166
--- /dev/null
+++ b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_3_8ddec87534a9025c26394fecd5456b84._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-15T16:05:01Z"
+ content="""
+git-remote-gcrpyt unfortunately is written as a shell script, so getting it
+to work on windows would probably be very hard unless it can be run with
+cygwin's shell somehow.
+"""]]
diff --git a/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_4_9c12c508f62f2e76d09f4ed15af9c74e._comment b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_4_9c12c508f62f2e76d09f4ed15af9c74e._comment
new file mode 100644
index 0000000000..e24dab7812
--- /dev/null
+++ b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_4_9c12c508f62f2e76d09f4ed15af9c74e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="graboluk@f6de53961ab0f884e203f602f65eb5cdc0fb7513"
+ nickname="graboluk"
+ subject="is it also broken in debian testing?"
+ date="2015-09-25T17:50:32Z"
+ content="""
+I'm using debian testing version 5.20150731. I've set up an account git-annex on my private server, I've checked that I can login to it just fine, but the box \"Testing server...\" is there indefinitely (I'm trying a login with password)
+"""]]
diff --git a/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_5_b496f6938bd463de501eaa5c1850ce5c._comment b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_5_b496f6938bd463de501eaa5c1850ce5c._comment
new file mode 100644
index 0000000000..b1fdaacee1
--- /dev/null
+++ b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_5_b496f6938bd463de501eaa5c1850ce5c._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-11-18T19:12:02Z"
+ content="""
+@graboluk no, this problem was specific to Windows.
+"""]]
diff --git a/doc/forum/Trouble_installing_from_cabal_on_debian-testing.mdwn b/doc/forum/Trouble_installing_from_cabal_on_debian-testing.mdwn
new file mode 100644
index 0000000000..d83d5737b3
--- /dev/null
+++ b/doc/forum/Trouble_installing_from_cabal_on_debian-testing.mdwn
@@ -0,0 +1,17 @@
+I'm having trouble install from cabal on Debian-testing since the new beta released.
+
+    % sudo aptitude remove --purge cabal-install
+    % rm -rf $HOME/.cabal
+    % sudo aptitude install cabal-install
+    % cabal update
+    % cabal install git-annex
+
+The output all follows this general syntax:
+
+    <package> depends on <anotherpackage> which failed to install
+
+On the flip side, I upgrade my Debian to sid and it installed just fine through aptitude.
+
+(Apologies for my English, and if this is simply a user error)
+
+[[!tag forumbug]] [[bugs/done]]
diff --git a/doc/forum/Trouble_installing_from_cabal_on_debian-testing/comment_1_0d3e9d7cffafc34bc212557e8bbb987d._comment b/doc/forum/Trouble_installing_from_cabal_on_debian-testing/comment_1_0d3e9d7cffafc34bc212557e8bbb987d._comment
new file mode 100644
index 0000000000..d312ba7b17
--- /dev/null
+++ b/doc/forum/Trouble_installing_from_cabal_on_debian-testing/comment_1_0d3e9d7cffafc34bc212557e8bbb987d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.141"
+ subject="comment 1"
+ date="2012-09-25T16:13:08Z"
+ content="""
+The difficulty with using cabal on Debian testing (and unstable) is that Debian has an older version of Yesod, and I have not managed to get cabal to work with both versions at once.
+
+If you build using the Makefile, it currently uses the old version of Yesod, so that'll work.
+
+The [package from unstable](http://packages.debian.org/sid/git-annex) should install ok on testing.
+"""]]
diff --git a/doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site.mdwn b/doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site.mdwn
new file mode 100644
index 0000000000..3c81f6ec94
--- /dev/null
+++ b/doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site.mdwn
@@ -0,0 +1,35 @@
+I'm trying to set up a public repository that is cloneable from my web site,
+similar to what is mentioned at
+https://git-annex.branchable.com/tips/setup_a_public_repository_on_a_web_site/
+
+I've got a repo from my laptop that I can push to my web server, and I can list
+the contents of the `.git` directory:
+
+    $ curl https://example.com/annex/.git/
+    <html>
+    <head><title>Index of /annex/.git/</title></head>
+    <body bgcolor="white">
+    <h1>Index of /annex/.git/</h1><hr><pre><a href="../">../</a>
+    <a href="annex/">annex/</a>                 12-Mar-2017 17:42                   -
+    <a href="branches/">branches/</a>           12-Mar-2017 17:38                   -
+    <a href="hooks/">hooks/</a>                 12-Mar-2017 17:38                   -
+    <a href="info/">info/</a>                   12-Mar-2017 17:38                   -
+    <a href="logs/">logs/</a>                   12-Mar-2017 17:38                   -
+    <a href="objects/">objects/</a>             12-Mar-2017 17:40                   -
+    <a href="refs/">refs/</a>                   12-Mar-2017 17:38                   -
+    <a href="HEAD">HEAD</a>                     12-Mar-2017 17:39                  23
+    <a href="config">config</a>                 12-Mar-2017 17:40                 269
+    <a href="description">description</a>       12-Mar-2017 17:38                  73
+    <a href="index">index</a>                   12-Mar-2017 17:41                1200
+    </pre><hr></body>
+    </html>
+
+However, when I try to clone it to simulate what I expect people to do, I get:
+
+    $ git clone https://exmaple.com/annex/.git
+    Cloning into 'annex...
+    fatal: repository 'https://example.com/annex/.git/' not found
+
+I've configured with `git config core.sharedrepository world` and `git config
+receive.denyCurrentBranch updateInstead`, but it doesn't seem to be working as I
+can't clone the repository over https.
diff --git a/doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site/comment_1_34a858688c46faf624fa7d98b05e6519._comment b/doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site/comment_1_34a858688c46faf624fa7d98b05e6519._comment
new file mode 100644
index 0000000000..e42a45af3c
--- /dev/null
+++ b/doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site/comment_1_34a858688c46faf624fa7d98b05e6519._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-07T20:31:26Z"
+ content="""
+Hmm, that all looks ok. I wonder if you forgot to run `git
+update-server-info`?
+
+<https://downloads.kitenet.net/.git/> is an example of such a repo, which
+you can clone. So it certianly works if you set it up right.
+"""]]
diff --git a/doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site/comment_2_409103144cf803ced9d81d3380ca76fb._comment b/doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site/comment_2_409103144cf803ced9d81d3380ca76fb._comment
new file mode 100644
index 0000000000..bd2e5fb4b6
--- /dev/null
+++ b/doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site/comment_2_409103144cf803ced9d81d3380ca76fb._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="lee@7614f42c1a6cc84dbc813df25d2f75ed54948e17"
+ nickname="lee"
+ avatar="http://cdn.libravatar.org/avatar/bcacd00a7f05c4772329cf9f446c7987"
+ subject="comment 2"
+ date="2017-04-07T21:10:34Z"
+ content="""
+> I wonder if you forgot to run git update-server-info?
+
+That was it! Thanks!
+
+I actually didn't forget to run this, but I did not realize that it needed to be run on the *server*, so I was running it on my local annex instead. Now that I've run it everything works!
+"""]]
diff --git a/doc/forum/Truly_purging_dead_repositories.mdwn b/doc/forum/Truly_purging_dead_repositories.mdwn
new file mode 100644
index 0000000000..8a231439c4
--- /dev/null
+++ b/doc/forum/Truly_purging_dead_repositories.mdwn
@@ -0,0 +1 @@
+Since I'm just starting out with git-annex, I've had several false starts in getting things setup nicely between three machines.  In the course of so doing, I've ended up with several repositories which no longer exist, and which I've marked dead.  However, this is making the "git annex status" report a bit ugly, since these repositories no longer exist and can never exist again. Is there a way to truly purge dead repositories from my annex?  I'd be fine with a command that must be ran in tandem on all annexes before doing a sync...
diff --git a/doc/forum/Truly_purging_dead_repositories/comment_1_a4c75d49714b3543a9f1617a15d4a2d1._comment b/doc/forum/Truly_purging_dead_repositories/comment_1_a4c75d49714b3543a9f1617a15d4a2d1._comment
new file mode 100644
index 0000000000..6b778ed567
--- /dev/null
+++ b/doc/forum/Truly_purging_dead_repositories/comment_1_a4c75d49714b3543a9f1617a15d4a2d1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.23"
+ subject="comment 1"
+ date="2012-10-18T02:20:25Z"
+ content="""
+If you really want to, check out the git-annex branch and delete the line from uuid.log, and do this on every repo in tandem. But it seems a lot of bother for something that is entirely hidden except for this one place.
+"""]]
diff --git a/doc/forum/Truly_purging_dead_repositories/comment_2_3da60a02e7323a204c5c5dd02ba04d6c._comment b/doc/forum/Truly_purging_dead_repositories/comment_2_3da60a02e7323a204c5c5dd02ba04d6c._comment
new file mode 100644
index 0000000000..8a89eee961
--- /dev/null
+++ b/doc/forum/Truly_purging_dead_repositories/comment_2_3da60a02e7323a204c5c5dd02ba04d6c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.23"
+ subject="comment 2"
+ date="2012-10-18T02:23:54Z"
+ content="""
+Another possibilty is to reuse the dead uuids for later repos. You can do this by just setting annex.uuid in .git/config before you run `git annex init`, and then run `git annex fsck`.
+"""]]
diff --git a/doc/forum/Truly_purging_dead_repositories/comment_3_2576e45436008ff5a7ae5a38cade658e._comment b/doc/forum/Truly_purging_dead_repositories/comment_3_2576e45436008ff5a7ae5a38cade658e._comment
new file mode 100644
index 0000000000..2b78ab0e02
--- /dev/null
+++ b/doc/forum/Truly_purging_dead_repositories/comment_3_2576e45436008ff5a7ae5a38cade658e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="Another idea"
+ date="2012-10-18T05:38:07Z"
+ content="""
+What if git annex status didnn't show dead repository unless I specified \"git annex status --dead\"?  If you're OK with that, I'll try adding it.
+"""]]
diff --git a/doc/forum/Truly_purging_dead_repositories/comment_4_477e3c213c5a5d4a33afd42a5b94c718._comment b/doc/forum/Truly_purging_dead_repositories/comment_4_477e3c213c5a5d4a33afd42a5b94c718._comment
new file mode 100644
index 0000000000..3f39803b24
--- /dev/null
+++ b/doc/forum/Truly_purging_dead_repositories/comment_4_477e3c213c5a5d4a33afd42a5b94c718._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4830:1600:187::2"
+ subject="comment 4"
+ date="2013-09-04T06:44:42Z"
+ content="""
+Status no longer shows dead repositories.
+
+See also, answer here: <http://git-annex.branchable.com/forum/How_to_delete_a_remote__63__/#comment-7ebf3804709a5aa64f1ca057a7df74f9>
+"""]]
diff --git a/doc/forum/Trying_to_delete_an_S3_repo_fails.mdwn b/doc/forum/Trying_to_delete_an_S3_repo_fails.mdwn
new file mode 100644
index 0000000000..6544fd1f3d
--- /dev/null
+++ b/doc/forum/Trying_to_delete_an_S3_repo_fails.mdwn
@@ -0,0 +1,3 @@
+[2015-10-03 22:10:53.948377] TransferScanner: warning TransferScanner crashed: unknown response from git cat-file ("refs/heads/git-annex:706/2a9/SHA256E-s13840914--38cdcf384aee777000693f58f1302684bf18f577045c1340d7aeb72b6d6f2233.dmg.log.cnk missing","refs/heads/git-annex:b8f/4d2/SHA256E-s26301635--ce2f215486df83c6ada74a81679ff78f717404d0637bfd51ecbf0330c21db12b.dmg.log")
+
+What exactly is this telling me?
diff --git a/doc/forum/Trying_to_delete_an_S3_repo_fails/comment_1_d8ab7757cd224439d55a18bfec405772._comment b/doc/forum/Trying_to_delete_an_S3_repo_fails/comment_1_d8ab7757cd224439d55a18bfec405772._comment
new file mode 100644
index 0000000000..88e301ac7a
--- /dev/null
+++ b/doc/forum/Trying_to_delete_an_S3_repo_fails/comment_1_d8ab7757cd224439d55a18bfec405772._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-10-04T19:33:36Z"
+ content="""
+This message suggests that your git repository has somehow lost an object
+that was committed to it. Suggest you run `git annex repair` to fix
+whatever the problem might be.
+"""]]
diff --git a/doc/forum/Trying_to_delete_an_S3_repo_fails/comment_2_94653e0c2c9e3e3be45c383442c7ec9b._comment b/doc/forum/Trying_to_delete_an_S3_repo_fails/comment_2_94653e0c2c9e3e3be45c383442c7ec9b._comment
new file mode 100644
index 0000000000..c120784df0
--- /dev/null
+++ b/doc/forum/Trying_to_delete_an_S3_repo_fails/comment_2_94653e0c2c9e3e3be45c383442c7ec9b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 2"
+ date="2015-10-05T06:28:17Z"
+ content="""
+Thanks, is there a docs page somewhere about all the different  command line switches or can I determine those via \"git annex help\" maybe?
+"""]]
diff --git a/doc/forum/Trying_to_setup_2_full_backup_repos_that_sync_with_eachother.mdwn b/doc/forum/Trying_to_setup_2_full_backup_repos_that_sync_with_eachother.mdwn
new file mode 100644
index 0000000000..95d7483480
--- /dev/null
+++ b/doc/forum/Trying_to_setup_2_full_backup_repos_that_sync_with_eachother.mdwn
@@ -0,0 +1,30 @@
+So I'm liking git-annex alot but trying to setup something up
+by using the webapp wasn't very successful.
+
+I have serverA machineB laptopC laptopD
+
+Now what I want to setup is:
+
+serverA       machineB
+repo   <sync> repo
+
+Basically I want A and B to constantly sync with each
+other for a fullbackup repo on each. But I also want both A and B to
+have the full checkout local.
+
+Then I have C and D just be clients and pull whatever they need from A or B.
+
+What I've gotten working atm:
+On A I setup the repo(not bare - I want access to the contents)). On B I ran
+a clone from A. That way B always syncs to A.
+
+Setup both repos to be fullbackup. I've tried to setup A to also sync
+from B but the webapp fails at doing it - and when I retry it fails
+again but this time with an error in the log that the remote already exists.
+
+Would I need to setup things manually for this scenario? Or is it not even possible?
+
+Do I just setup a normal remote? Or will this loop break things?
+
+When I'm done setting it all up I'd like to have the assistant
+running on both systems to do the syncs for me.
diff --git a/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback.mdwn b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback.mdwn
new file mode 100644
index 0000000000..934617888f
--- /dev/null
+++ b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback.mdwn
@@ -0,0 +1,39 @@
+So after more than a year I think I am slowly beginning grasping git-annex. I'd like to put all my questions and ideas into this one thread, maybe you guys can help me sort things out. I'll number everything so you're more than welcome to chime in with regards to a particular item only. Happy to get links to read up stuff, don't hesitate to just paste a link if you think it is useful.
+
+	*1.* Right or wrong: I can only "work" with files in "CLIENT" repositories, not with backup, archive or anything else?
+
+	*2.* How does the copying or synching work? Is it comparable to rsync? How good is it at solving conflicts?
+
+	*3.* Can I get some feedback if git-annex is a solution for my scenario?
+
+*I have 1 Macbook, 1 NAS (Freenas running freeBSD) and access to S3 and box.com as well as a few external HDs.*
+My current setup involves a lot of manual copying, (very careful usage of) rsync and basically ends up me having a copy/backup of everything on the NAS and the files I currently work with on my Macbook.
+
+
+*Ideally I'd want to achieve something like this:*
+
+	- Have all files on the NAS
+	- Only have current work files on my Macbook
+	- Use external HDs only when necessary or transferign stuff
+	- S3 and box.com can be used however needed.
+
+	*4.* DOCUMENTS
+So in case I am travelling without Macbook, I use another PC or my Android phone to connect to my router at home via VPN then access a share on my NAS, work on a file, print it, save it back so whenever my MACbook is online again, it syncs the latest version.
+To achieve this with got-annex I guess I need the repository on the NAS to be a client repo, right? But the problem I see is that if I move a sub-folder from Docs into Archive, i.e. a folder of manuals I don't need on my MACbook all the time, it also gets moved out of the client repo on the NAS into an archive repo so how would I access it remotely if necessary?
+Also, talking about archiving, doesn't this get messy if you have a complicated folder structure inside a repo? How would you put stuff back from archives exactly where it was? 
+Sorry if this sounds a bit silly but I rely on a very precise folder system, everything is properly placed where I know it will be so if I now drag/drop all sorts of files/folders into archive I'll never figure out what's what again.
+
+	*5.* MUSIC
+This should be fairly easy, all my music is on my NAS and on my macbook, whenever I add music to my macbook it'll automatically sync to the NAS.
+
+	*6.* PICTURES
+This is where it gets complicated.
+I have a folder: Pictures with subfolders for each year, aka 2010, 2011 ... 2015 and inside is a sub folder for each photographed event. Now these pics get too big for my macbook so I'd like all images to be on my NAS, available for access, and to be able to simply archive say 2014. Now the question is if later I remember I need access to a particular event in 2014, can I browse that folder and un-archive that particular folder?
+
+	*7.* Also, say I'd like to be able to take a folder/sub-folder of images with me for external editing on a HD, and when coming back with them I'd like them to be synced back when I plug the HD back in, what type of repository would i have to set this HD to?
+
+	*8.* Obviously I'd need to setup a different repository for each Documents, Pictures, Music with their own settings, right?
+
+        *9.* At the moment it is not possible to have separate number of minimum number of copies per repository?
+
+So, what do you think, is git-annex suitable for my needs? Partially at least?
diff --git a/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_1_86a86f1f3ea2e778e4022689391b887b._comment b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_1_86a86f1f3ea2e778e4022689391b887b._comment
new file mode 100644
index 0000000000..4ef121bf9d
--- /dev/null
+++ b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_1_86a86f1f3ea2e778e4022689391b887b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
+ nickname="Carl"
+ subject="comment 1"
+ date="2015-10-04T17:58:48Z"
+ content="""
+I think it can be a good fit. Let me try to answer some of your questions in the order that seems most reasonable to me
+
+*8* It is not a strict requirement to hav different repos for the different things, but I guess it might simplify things. Plus You can start with one of them and when that is properly set up continue with the next one.
+
+*5* your music solution seems simple enough. Numcopies=2 and everything should work. 
+
+*1*, *4*, *9* There is nothing magic with client remotes. It is just a group, that has some default rules. You can create your own groups and also change their rules. For my documents, I have two custom groups, \"offsite\" and \"cloud\". I have set up rules so that files prefer to be in one offsite remote and one cloud remote. However until I had possibility to plug my computer into an off site disc and sync it all files want to be in two cloud remotes. 
+
+*4*, *6* I personally do not run the assistant, but do everything on the command line. For me the setup where old things that I will probably never access again lies in an archive folder, if I do need it I can get the file back wit a simple \"git annex get $filename\". For my documents tree I only add files and folder or move folders into an archive folder. (Also note that archive folders can be located anywhere in your file tree, and that you can have arbitrarily many
+"""]]
diff --git a/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_2_77d61eceec24d2f41f044a643d8542cc._comment b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_2_77d61eceec24d2f41f044a643d8542cc._comment
new file mode 100644
index 0000000000..42e7ab19f5
--- /dev/null
+++ b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_2_77d61eceec24d2f41f044a643d8542cc._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 2"
+ date="2015-10-07T20:22:16Z"
+ content="""
+Hi Carl, thanks for the feedback.
+
+I'll be very slowly in replying, taking some late night classes this week but I WILL ask more questions once I get around to try some tests with dummy data.
+
+Meanwhile here is one question that has been bugging me for days now:
+
+Take the following scenario:
+
+- client repo setup on NAS
+- client repo setup on MAcbook
+- backup and archive repos elsewhere (doesn't matter for this question)
+
+So NAS and MACbook are in sync when I decide I don't need a specific folder on the MACbook and archive it.
+
+The big question:
+Will it be archived on the NAS too or not? (assistant running on both devices and please assume there are enough copies of this folder in backup and archive repos)
+
+This is really an important part of understanding git-annex for me as it would simply be a sync tool if it archives on both devices but if it does not it solves my problem of being able to decide waht data to carry with me on my MACbook and still be able to use a VPN and access a share on the NAS (the client repo folder).
+"""]]
diff --git a/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_3_529cada8df4888c12254818c26231835._comment b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_3_529cada8df4888c12254818c26231835._comment
new file mode 100644
index 0000000000..3803624c81
--- /dev/null
+++ b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_3_529cada8df4888c12254818c26231835._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
+ nickname="Carl"
+ subject="comment 3"
+ date="2015-10-09T08:45:25Z"
+ content="""
+As I understand your question, you will move some files into an \"archive-folder\" The client repo in your mac will then check if it allowed to drop the file. It seem that it will as there are enough copies on S3 et al. After syncing the file structure on the git repo will be updated on your NAS, as it is a client it will also check if it allowed to drop, and as enough copies are available it will. 
+
+If this is not what you want, then you do not want to have your NAS as a client. My setup is not dissimilar from yours, and my home server (corresponding to your NAS) is in the backup group. It thus wants to hold on to everything.
+"""]]
diff --git a/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_4_1561613ff2f0f3d7b42159d09ae1c7f7._comment b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_4_1561613ff2f0f3d7b42159d09ae1c7f7._comment
new file mode 100644
index 0000000000..c7c32dc62a
--- /dev/null
+++ b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_4_1561613ff2f0f3d7b42159d09ae1c7f7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 4"
+ date="2015-10-10T10:16:14Z"
+ content="""
+Hi Carl,
+
+thanks for clarifying so the question is, if I don't use my NAS as a client, what other function can I assign, I'd really want to access its files via shares too. Can I make it a backup but keep the files \"in the clear\" so I am able to access them via a share?
+"""]]
diff --git a/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_5_59991756981681648070d03e2277ccbb._comment b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_5_59991756981681648070d03e2277ccbb._comment
new file mode 100644
index 0000000000..ca0a79c1cb
--- /dev/null
+++ b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_5_59991756981681648070d03e2277ccbb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
+ nickname="Carl"
+ subject="comment 5"
+ date="2015-10-10T18:53:58Z"
+ content="""
+The type of group you have does not change if you have the files accesable from the filenames or not. As long as it is a git remote, that in not bare, or a direct git-annex remote you are good to go. 
+"""]]
diff --git a/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_6_eeafd62249d44b89d1091f0be79b3086._comment b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_6_eeafd62249d44b89d1091f0be79b3086._comment
new file mode 100644
index 0000000000..c9f91a709d
--- /dev/null
+++ b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_6_eeafd62249d44b89d1091f0be79b3086._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 6"
+ date="2015-10-11T16:51:06Z"
+ content="""
+you lost me there. so I'm using the command line on the NAS not the webapp but on the MACbook I do use the webapp.
+so when creating a repo through the webapp I chose:  Remote server - Set up a repository on a remote server using ssh. and then I can chose between: Unencrypted repository, Simple shared encryption and Encrypt with GnuPG key
+
+Unfortunately the descriptions aren't quite that self-explanatory. So far I have tested the 3rd option but here files get stored inside .git/annex/objects so I cannot access the files straight away. 
+I'll be testing a few more option awaiting a reply here, maybe I'll figure it out on my own. 
+The config of hte created repo on the NAS contained this:
+[core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = true
+        sharedrepository = 1
+"""]]
diff --git a/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_7_24a20071d43ded3be9c4c68a637ca4f5._comment b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_7_24a20071d43ded3be9c4c68a637ca4f5._comment
new file mode 100644
index 0000000000..ce05261124
--- /dev/null
+++ b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_7_24a20071d43ded3be9c4c68a637ca4f5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
+ nickname="Carl"
+ subject="comment 7"
+ date="2015-10-12T18:21:21Z"
+ content="""
+I am not fluent in the webapp. Usually I use the commandline and follow the walktrough on the homepage. Your problem in not being able to see the files is that the NAS has a bare repo. You want a non bare.
+"""]]
diff --git a/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_8_8ad6bd5fce8f9bc1622f225c162ae167._comment b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_8_8ad6bd5fce8f9bc1622f225c162ae167._comment
new file mode 100644
index 0000000000..190cf74339
--- /dev/null
+++ b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_8_8ad6bd5fce8f9bc1622f225c162ae167._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 8"
+ date="2015-10-17T14:54:12Z"
+ content="""
+Thanks for bearing with me Carl, you mention the walkthrough and the command line so lets see:
+
+on my nas I follow the walkthrough:
+
+# mkdir ~/annex
+# cd ~/annex
+# git init
+# git annex init
+
+which yields in a BARE repo:
+
+cat .git/config 
+[core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = false
+        logallrefupdates = true
+[user]
+        name = gitannex
+        email = gitannex
+[annex]
+        uuid = 36bca403-027b-4e90-9504-123456789012
+        version = 5
+
+So where do I stand now? You mention I need a non-bare repo and suggested to follow the walkthrough. Kinda stuck here now and I really would like to get to use gitannex.
+
+
+Maybe joey will give some advice?
+
+Would you mind sharing more of your setup? Theory or practical advice welcome :-)
+
+
+regarding an earlier question of mine, about how the syncing works: 
+I understand its not possible to have git-annex running somewhere centrally and have two clients who only access parts of a repo?
+
+i.e. on \"server\" have Documents with subfolder a) and b)  then have 2 clients, i.e. Macbooka and Macbookb which would each only sync the a) respectively b) folders out of the complete repo?
+"""]]
diff --git a/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_9_6406fcf0021ac8266b4f2ef850be0fa0._comment b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_9_6406fcf0021ac8266b4f2ef850be0fa0._comment
new file mode 100644
index 0000000000..bc2a6685b4
--- /dev/null
+++ b/doc/forum/Trying_to_wrap_my_head_around_git-annex__44___need_some_feedback/comment_9_6406fcf0021ac8266b4f2ef850be0fa0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2015-10-19T17:37:32Z"
+ content="""
+git init will never create a bare git repository (unless you specify
+--bare), and a normal bare repository doesn't have a .git directory.
+
+So I suspect that your repository is using git-annex's direct
+mode, which only sets core.bare as an implementation detail. Likely
+you trimmed off the end of the .git/config, where it said "direct = true"
+"""]]
diff --git a/doc/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__.mdwn b/doc/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__.mdwn
new file mode 100644
index 0000000000..5495e26498
--- /dev/null
+++ b/doc/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__.mdwn
@@ -0,0 +1,18 @@
+Hi,
+
+Here is my setup:
+
+* I have a locally networked server Server-A with a large storage hard drive auto-mounted.
+* I have two personal client computers: Client-A and Client-B.
+* Client-A is my primary (desktop) computer. 
+* Client-B is my secondary (laptop) computer that I use less often.
+* Git-annex is installed on all 3 computers and I use git-annex assistant on both Client-A and Client-B.
+* Both Client-A and Client-B need to share the same repository/files.
+
+
+What is the best or recommended git-annex assistant repository configuration for this setup? Ideally I want Server-A to have a full backup of the shared repository. I currently have a client repository for both Client-A and Client-B. Also, both Client-A and Client-B have a "full backup" repository pointing to the same repository hosted on Server-A. Is this OK? Should only one of the the client's have this repository as a "full backup"? Will this current setup also have git annex assistant auto-sync the repositories between the clients? I have both clients setup right now and they have both successfully cloned the shared repository, but I have noticed that they have yet to sync up modifications made on the other client. An alternative setup I can think of would be to have Client-A keep its current configuration and have Client-B switch the "full backup" repository to be just a "transfer" repository.
+
+I hope my intentions are clear. Please give me your recommendations.
+
+Regards,
+Blake
diff --git a/doc/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__/comment_1_b8702892280447193e6e80be22a580a0._comment b/doc/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__/comment_1_b8702892280447193e6e80be22a580a0._comment
new file mode 100644
index 0000000000..915e7209bd
--- /dev/null
+++ b/doc/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__/comment_1_b8702892280447193e6e80be22a580a0._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlkA6XinbeOdnEDxEGQUWyjqPGh0kdMXr4"
+ nickname="Blake"
+ subject="update"
+ date="2013-10-30T07:19:56Z"
+ content="""
+It seems both Client-A and Client-B ARE actually syncing with this current setup. I think Client-B was just delayed due to the initial startup scan. So I guess at this point I am more or less asking if having both Client-A and Client-B have the remote repository being a \"full backup\" type is appropriate or if there is a better configuration that achieves what I am hoping to have.
+
+Regards,
+Blake
+"""]]
diff --git a/doc/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__/comment_2_50cafde7e30b928480d1f142ddd763d2._comment b/doc/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__/comment_2_50cafde7e30b928480d1f142ddd763d2._comment
new file mode 100644
index 0000000000..4495401b21
--- /dev/null
+++ b/doc/forum/Two_computer_setup__58_____34__transfer__34___or___34__full_backup__34___repository_groups__63__/comment_2_50cafde7e30b928480d1f142ddd763d2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 2"
+ date="2013-11-01T16:47:18Z"
+ content="""
+git-annex keeps track of the repository group on a per repository basis. That is, if the repository on Server-A is a full backup, both Client-A and Client-B will consider it to be one, and use it appropriately. You can't have just Client-A think it's a full backup; this setting will be automatically synced to Client-B.
+
+Your setup sounds ok, although you might need to set up a XMPP account in order for Client-A and Client-B to immediately message one-another when they have new changes to sync. Otherwise, they might only poll Server-A occasionally for changes.
+"""]]
diff --git a/doc/forum/Two_computers__44___one_networked_repository__44___no_Jabber_-_how_to_setup_sync__63___.mdwn b/doc/forum/Two_computers__44___one_networked_repository__44___no_Jabber_-_how_to_setup_sync__63___.mdwn
new file mode 100644
index 0000000000..64426eb4d1
--- /dev/null
+++ b/doc/forum/Two_computers__44___one_networked_repository__44___no_Jabber_-_how_to_setup_sync__63___.mdwn
@@ -0,0 +1,7 @@
+Hello there,
+
+I've got two computers, let's call them Alice and Bob, which should share the same repository. Alice and Bob are never online at the same time, and the remote repository setup as "transfer file repository" is an account on Box.com. So Jabber is obviously no option.
+
+I've tried setting up this with the webapp, but it's not working as intended: Bob never pulls the content from Alice from the remote repository. 
+
+How can I setup this to make it work with the remote repository in the web app? I am kinda at a loss right now. 
diff --git a/doc/forum/Two_computers__44___one_networked_repository__44___no_Jabber_-_how_to_setup_sync__63___/comment_1_b90aef011d853ad9feb6f8edc08bf7d9._comment b/doc/forum/Two_computers__44___one_networked_repository__44___no_Jabber_-_how_to_setup_sync__63___/comment_1_b90aef011d853ad9feb6f8edc08bf7d9._comment
new file mode 100644
index 0000000000..11e06cd406
--- /dev/null
+++ b/doc/forum/Two_computers__44___one_networked_repository__44___no_Jabber_-_how_to_setup_sync__63___/comment_1_b90aef011d853ad9feb6f8edc08bf7d9._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-01-20T19:15:50Z"
+ content="""
+Since Alice and Bob are never online at the same time, you need
+a central git repository somewhere. 
+
+This could be on a linux server, perhaps even with git-annex installed.
+Or, you could just make a repository on github or gitorious. No need
+for git-annex.
+
+Wherever it is, add the central repository as a git remote on Alice and
+Bob, and they'll each use it to drop off the current state of their
+git repo, and sync up with the changes from each other.
+"""]]
diff --git a/doc/forum/USB_backup_with_files_visible.mdwn b/doc/forum/USB_backup_with_files_visible.mdwn
new file mode 100644
index 0000000000..747de85ffe
--- /dev/null
+++ b/doc/forum/USB_backup_with_files_visible.mdwn
@@ -0,0 +1,7 @@
+Quick question: I want to create a repository on my removable USB drive that will acquire all files (eg. "full backup" repository group), but where the files will be visible and usable if you load the drive on another computer.
+
+How do I do that from within the assistant?
+
+Thanks,
+
+Zellyn
diff --git a/doc/forum/USB_backup_with_files_visible/comment_10_b90b18ca57f9299f1920254bb2aa699b._comment b/doc/forum/USB_backup_with_files_visible/comment_10_b90b18ca57f9299f1920254bb2aa699b._comment
new file mode 100644
index 0000000000..763a3ce544
--- /dev/null
+++ b/doc/forum/USB_backup_with_files_visible/comment_10_b90b18ca57f9299f1920254bb2aa699b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 10"
+ date="2014-11-25T20:41:56Z"
+ content="""
+When you actually think about how users would try to use this proposed system, you get here: <http://git-annex.branchable.com/forum/usability:_creating_an_archive_on_a_new_external_drive/> Ie, if a removable drive shows all of a user's files, then they'll  try to edit them, and since the assistant can't run on removable drives (makes them kinda hard to remove), such changes by the user won't get committed.
+"""]]
diff --git a/doc/forum/USB_backup_with_files_visible/comment_1_2832f8ae24dfb0f101e06f7c18283028._comment b/doc/forum/USB_backup_with_files_visible/comment_1_2832f8ae24dfb0f101e06f7c18283028._comment
new file mode 100644
index 0000000000..d70d859bf5
--- /dev/null
+++ b/doc/forum/USB_backup_with_files_visible/comment_1_2832f8ae24dfb0f101e06f7c18283028._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 1"
+ date="2013-07-02T17:00:41Z"
+ content="""
+This is not something the assistant really handles yet. The issue is that if you have a non-bare repository on the USB drive, something has to run `git annex sync` in it when changes are pushed to it, to update it to display the files that are in the repository.
+
+One way to do this is to set up a non-bare repository by hand and add a git post-receive hook that runs `git annex sync`
+
+Update: Another way, recently added is
+<https://git-annex.branchable.com/making_a_remote_repo_update_when_changes_are_pushed_to_it/>
+This new approach even supports FAT filesystems!
+"""]]
diff --git a/doc/forum/USB_backup_with_files_visible/comment_2_6163e01aa441f8435091f026cc6da337._comment b/doc/forum/USB_backup_with_files_visible/comment_2_6163e01aa441f8435091f026cc6da337._comment
new file mode 100644
index 0000000000..591dc847d9
--- /dev/null
+++ b/doc/forum/USB_backup_with_files_visible/comment_2_6163e01aa441f8435091f026cc6da337._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQafKy7hNSEolLs6TvbgUnkklTctUY9LI"
+ nickname="Zellyn"
+ subject="comment 2"
+ date="2013-07-02T17:10:59Z"
+ content="""
+Aah, perfect. I did in fact set up a non-bare git annex on the drive. I was just lacking the `git annex sync` command. Thanks!
+"""]]
diff --git a/doc/forum/USB_backup_with_files_visible/comment_3_ee92ff320eb5d9a031bdd1896aee0d86._comment b/doc/forum/USB_backup_with_files_visible/comment_3_ee92ff320eb5d9a031bdd1896aee0d86._comment
new file mode 100644
index 0000000000..98a3c1cc5d
--- /dev/null
+++ b/doc/forum/USB_backup_with_files_visible/comment_3_ee92ff320eb5d9a031bdd1896aee0d86._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="post-receive hook looks troublesome"
+ date="2013-07-03T16:11:13Z"
+ content="""
+I just tried setting up a post-receive hook with just \"git annex sync\" in it.
+The end result is that files (git annex symlinks, really) are getting removed somehow as a result after a couple of git annex sync's done manually.
+It would be nice if this actually worked.
+
+"""]]
diff --git a/doc/forum/USB_backup_with_files_visible/comment_4_437c8342c0b65e3a89129800313eb73c._comment b/doc/forum/USB_backup_with_files_visible/comment_4_437c8342c0b65e3a89129800313eb73c._comment
new file mode 100644
index 0000000000..a45b05b25c
--- /dev/null
+++ b/doc/forum/USB_backup_with_files_visible/comment_4_437c8342c0b65e3a89129800313eb73c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 4"
+ date="2013-07-03T19:54:21Z"
+ content="""
+Seems to me that any such problems would be caused by the environment variables git sets in the hook, or possibly the current working directory in use when the hook runs. So it might take some finessing to get right.
+
+Meanwhile, I've committed a change that makes `git annex merge` merge in changes synced to the repo from other repositories. So that can be used the same way `git annex sync` can, but without the added overhead of committing, pushing, and pulling.
+"""]]
diff --git a/doc/forum/USB_backup_with_files_visible/comment_5_5e10cffe8465ea4ecaa71c03a4c29ea4._comment b/doc/forum/USB_backup_with_files_visible/comment_5_5e10cffe8465ea4ecaa71c03a4c29ea4._comment
new file mode 100644
index 0000000000..20853a4a0d
--- /dev/null
+++ b/doc/forum/USB_backup_with_files_visible/comment_5_5e10cffe8465ea4ecaa71c03a4c29ea4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 5"
+ date="2013-07-04T05:11:46Z"
+ content="""
+Oh!  git annex merge is very nice.
+"""]]
diff --git a/doc/forum/USB_backup_with_files_visible/comment_6_add048a16837f7940a859f21426cdbe9._comment b/doc/forum/USB_backup_with_files_visible/comment_6_add048a16837f7940a859f21426cdbe9._comment
new file mode 100644
index 0000000000..95f7495741
--- /dev/null
+++ b/doc/forum/USB_backup_with_files_visible/comment_6_add048a16837f7940a859f21426cdbe9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="Confused"
+ date="2013-11-03T00:13:47Z"
+ content="""
+Sorry, I'm confused.  I set up a Full Backup repo on a second hard drive, but the files are visible in its directory just like in my Client repos' directories.  Are the files not supposed to be visible?  Is something wrong?
+"""]]
diff --git a/doc/forum/USB_backup_with_files_visible/comment_7_de227ca9911fe57d7a6d3e037f574fe9._comment b/doc/forum/USB_backup_with_files_visible/comment_7_de227ca9911fe57d7a6d3e037f574fe9._comment
new file mode 100644
index 0000000000..0f74efac08
--- /dev/null
+++ b/doc/forum/USB_backup_with_files_visible/comment_7_de227ca9911fe57d7a6d3e037f574fe9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 7"
+ date="2013-11-03T01:09:16Z"
+ content="""
+You can set it up that way, but the often confusing behavior (including not being able to umount a drive that has the git-annex assistant deamon running in it!) is why the webapp attempt to steer users toward making bare reposotories on USB drives.
+
+If you click on \"Add another repository\" -> \"Removable drive\", you get a bare repository.
+
+If you click on upper-right menu -> \"Add another local repository\" and enter a path, and tell it to combine the repositories, you get a synced non-bare repository, and potentially problems unmounting the drive since you now have 2 assistant daemons running.
+
+I have now added a further link to the nice removable drive path to that second UI path.
+"""]]
diff --git a/doc/forum/USB_backup_with_files_visible/comment_8_0c0ed0e038f7f0e2d2d4ed69b7b29fbc._comment b/doc/forum/USB_backup_with_files_visible/comment_8_0c0ed0e038f7f0e2d2d4ed69b7b29fbc._comment
new file mode 100644
index 0000000000..6511343e86
--- /dev/null
+++ b/doc/forum/USB_backup_with_files_visible/comment_8_0c0ed0e038f7f0e2d2d4ed69b7b29fbc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="comment 8"
+ date="2013-11-03T01:13:26Z"
+ content="""
+Thanks for the explanation, Joey.  I just posted a [comment](http://git-annex.branchable.com/bugs/Unnecessary_remote_transfers/#comment-f7110e694a9951d8ab546b8dec568bfa) about this on the bug report too.  Maybe the problem is simply that the Removable Drive option doesn't allow using internal, non-removable drives.
+
+BTW, I don't know if this is relevant, but I only see one \"git-annex assistant\" process running.
+"""]]
diff --git a/doc/forum/USB_backup_with_files_visible/comment_9_dfb830fb00c10b797c3d26179e6dfefd._comment b/doc/forum/USB_backup_with_files_visible/comment_9_dfb830fb00c10b797c3d26179e6dfefd._comment
new file mode 100644
index 0000000000..f73f186717
--- /dev/null
+++ b/doc/forum/USB_backup_with_files_visible/comment_9_dfb830fb00c10b797c3d26179e6dfefd._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmicVKRM8vJX4wPuAwlLEoS2cjmFXQkjkE"
+ nickname="Thomas"
+ subject="post-receive hook is not an option with FAT drives"
+ date="2014-11-20T15:53:29Z"
+ content="""
+Hi Joey,
+
+I tried to solve this use case with a post-receive hook and had to realize that FAT does not support the executable bit and thus the hook doesn't run. I've found several requests for the use case described here and I think it would be desirable, if the assistant/webapp could solve it without commandline-hacks.
+
+So I want to stick my thumbdrive in my work desktop and the assistant notices that it's available and starts copying stuff on it and runs git annex merge afterwards.
+
+I also had to manually set annex.diskreserve to a smaller value since annex wants to reserve more space (10G) than is available on most thumb drives. I think git-annex init should be more clever about the default diskreserve value, e.g. set it to a percentage of the total disk size.
+"""]]
diff --git a/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant.mdwn b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant.mdwn
new file mode 100644
index 0000000000..6b1c03d9a4
--- /dev/null
+++ b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant.mdwn
@@ -0,0 +1,22 @@
+1. Set up two computers with a client repository.
+2. Add a removable drive repository and set it to transfer group.
+3. Start adding files to computer #1 repository. See how the files get synced to the usb drive.
+4. Connect the usb drive to computer #2 and see the files getting transferred to computer #2. Everything is looking good.
+
+
+5. Connect the usb drive to computer #1 again. 
+6. Add a file that is larger than the remaining size of the usb drive, BUT smaller than the original size of the usb drive.
+7. The file does not get transferred to the usb drive due to lack of disk space.
+
+I would expect the assistant to make some space on the usb drive. Removing the files it knows has been transferred to computer #2, and then transfer the new file to the usb drive. But this does not seem to happen. 
+
+Have I missed something about how the transfer group is supposed to work?
+
+ 
+Using version:
+git-annex version: 4.20130802-g0a52f02
+build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+
+Pre built tar file.
+
+
diff --git a/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_1_0a6f6054d70009979f4a036e24b7c500._comment b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_1_0a6f6054d70009979f4a036e24b7c500._comment
new file mode 100644
index 0000000000..f298b56cde
--- /dev/null
+++ b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_1_0a6f6054d70009979f4a036e24b7c500._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 1"
+ date="2013-08-24T19:22:05Z"
+ content="""
+The assistant is supposed to remove files from transfer repositories once the file has been transferred to all known clients.  This generally seems to work, with all the transfer repositories I've tested it with. Nothing is special about USB drives compared with other transfer repositories.
+
+Perhaps you have not configured the USB drive as a transfer repository? Or perhaps you have another client repository (even a client repository you had once but have now deleted).
+"""]]
diff --git a/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_2_f9eef3019fe690e90c1228d62a16f70a._comment b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_2_f9eef3019fe690e90c1228d62a16f70a._comment
new file mode 100644
index 0000000000..7f761419c5
--- /dev/null
+++ b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_2_f9eef3019fe690e90c1228d62a16f70a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="even a client repository you had once but have now deleted"
+ date="2014-07-09T22:08:44Z"
+ content="""
+if this client repository has been deleted, why does it still have an impact? What is the user supposed to do to use a transfer repository if some day another client which was deleted has existed? 
+
+Old repositories seem to remain for ever in the webapp. You can try to delete them with the webapp, they will stay there. You can disable them, they will stay there. If you want to try to delete them again in the webapp, you first have to enable them again and nothing ever happens. There seems to be basically no way to delete repositories which have some day existed...
+"""]]
diff --git a/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_3_7fb74f7fab6c1baff4ffc270cf15ef0a._comment b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_3_7fb74f7fab6c1baff4ffc270cf15ef0a._comment
new file mode 100644
index 0000000000..df8333cb3c
--- /dev/null
+++ b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_3_7fb74f7fab6c1baff4ffc270cf15ef0a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 3"
+ date="2014-07-11T19:29:06Z"
+ content="""
+The webapp certianly allows deleting repositories.
+
+But, you can always go in and manually do it:
+
+<pre>
+git annex dead $uuid
+git annex group $uuid unwanted
+</pre>
+"""]]
diff --git a/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_4_5925b609aff0954f2860269cff107284._comment b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_4_5925b609aff0954f2860269cff107284._comment
new file mode 100644
index 0000000000..31a7e63d80
--- /dev/null
+++ b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_4_5925b609aff0954f2860269cff107284._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="comment 4"
+ date="2014-07-17T19:48:30Z"
+ content="""
+I may be facing one unexpected behavior, but your statement that the \"webapp certainely allows to delete repositories\" does not match my experience. It does offer this option, but this option has failed on me so many times that I have learnt to live with a couple of repositories disabled, sitting here. Trying to delete them starts some process (emptying the repository, starting deletion process) but ends up in nothing. At least one of them does not seem to have a name anymore (probably what you refer to as $uuid) since only the part in square bracket is visible in the webapp. I concluded that this was what the webapp was supposed to do. 
+"""]]
diff --git a/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_5_45062d5776f8aefb0850d70f2a517c75._comment b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_5_45062d5776f8aefb0850d70f2a517c75._comment
new file mode 100644
index 0000000000..3dbae84a07
--- /dev/null
+++ b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_5_45062d5776f8aefb0850d70f2a517c75._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="comment 5"
+ date="2014-07-18T08:13:08Z"
+ content="""
+by the way: the commands you suggest do not seem to match what I read here:
+
+http://git-annex.branchable.com/forum/How_to_delete_a_remote__63__/
+
+
+"""]]
diff --git a/doc/forum/Ubuntu_PPA.mdwn b/doc/forum/Ubuntu_PPA.mdwn
new file mode 100644
index 0000000000..b97cc1aec5
--- /dev/null
+++ b/doc/forum/Ubuntu_PPA.mdwn
@@ -0,0 +1,3 @@
+Is there a PPA that Ubuntu people are using to track the latest git-annex?
+
+The [Ubuntu install page](http://git-annex.branchable.com/install/Ubuntu/) mentions [https://launchpad.net/~rubiojr/+archive/git-annex](https://launchpad.net/~rubiojr/+archive/git-annex) which hasn't been updated for a while.
diff --git a/doc/forum/Ubuntu_PPA/comment_1_b55535258b1b4bcfc802235f0cba075d._comment b/doc/forum/Ubuntu_PPA/comment_1_b55535258b1b4bcfc802235f0cba075d._comment
new file mode 100644
index 0000000000..d91a0d1eb8
--- /dev/null
+++ b/doc/forum/Ubuntu_PPA/comment_1_b55535258b1b4bcfc802235f0cba075d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmeki7KlfJpAAN9CUmi9EdwhwBmIhDMYuE"
+ nickname="Marvin"
+ subject="comment 1"
+ date="2013-03-11T09:40:43Z"
+ content="""
+im also looking for a PPA with newer git-annex versions. mostly because of the glacier support...
+"""]]
diff --git a/doc/forum/Ubuntu_PPA/comment_2_adc4d644fed058d1811acf0b35db9c18._comment b/doc/forum/Ubuntu_PPA/comment_2_adc4d644fed058d1811acf0b35db9c18._comment
new file mode 100644
index 0000000000..bc91500c76
--- /dev/null
+++ b/doc/forum/Ubuntu_PPA/comment_2_adc4d644fed058d1811acf0b35db9c18._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmVICFY2CDP08xdsPr3cgmScomy9HA-1sk"
+ nickname="Andrew"
+ subject="comment 2"
+ date="2013-03-13T02:31:52Z"
+ content="""
+It's perfectly possible (though slightly messy) to install git-annex on Ubuntu via [[/install/cabal]], though you need to find and install all the required dependencies yourself (haskell, libidn, libgnutls, libgsasl etc). If you want to get crazy with this look at <http://developer.ubuntu.com/packaging/html/>
+"""]]
diff --git a/doc/forum/Ubuntu_PPA/comment_3_fc9cd51558c47718f243437202a11803._comment b/doc/forum/Ubuntu_PPA/comment_3_fc9cd51558c47718f243437202a11803._comment
new file mode 100644
index 0000000000..4c77308d05
--- /dev/null
+++ b/doc/forum/Ubuntu_PPA/comment_3_fc9cd51558c47718f243437202a11803._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="fmarier"
+ ip="121.98.93.240"
+ subject="My PPA (Ubuntu Precise) has git-annex 4.20130417"
+ date="2013-04-27T11:12:26Z"
+ content="""
+I just went through the pain of backporting 90+ Haskell packages from Debian unstable: https://launchpad.net/~fmarier/+archive/ppa
+"""]]
diff --git a/doc/forum/Ubuntu_PPA/comment_4_3a8bbd0a7450a7f5323cd13144824aea._comment b/doc/forum/Ubuntu_PPA/comment_4_3a8bbd0a7450a7f5323cd13144824aea._comment
new file mode 100644
index 0000000000..335cc57ba4
--- /dev/null
+++ b/doc/forum/Ubuntu_PPA/comment_4_3a8bbd0a7450a7f5323cd13144824aea._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://grossmeier.net/"
+ nickname="greg"
+ subject="All PPAs are outdated"
+ date="2013-05-08T17:38:04Z"
+ content="""
+My work preinstalled Ubuntu machine is now on Raring, and even there the version of git-annex is only 3.20121112ubuntu3; too old to have the webapp option enabled :/ The two PPAs mentioned here aren't configured to build for Raring, so even though the one from François has a build from May 1st (7 days ago), it doesn't help me ;)
+
+François: mind updating your PPA to support Raring? Thanks much if you do!
+
+Either that, or I'll take the time some day to do a proper install on this machine (read: Debian). ;-)
+"""]]
diff --git a/doc/forum/Ubuntu_PPA/comment_5_2e1beaeebda0201c635db8b276cedf20._comment b/doc/forum/Ubuntu_PPA/comment_5_2e1beaeebda0201c635db8b276cedf20._comment
new file mode 100644
index 0000000000..0d94ba6f22
--- /dev/null
+++ b/doc/forum/Ubuntu_PPA/comment_5_2e1beaeebda0201c635db8b276cedf20._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 5"
+ date="2013-05-08T23:25:37Z"
+ content="""
+If you are on raring you can still use
+
+    deb http://ppa.launchpad.net/fmarier/ppa/ubuntu precise main
+
+It's worked fine for me so far.
+"""]]
diff --git a/doc/forum/Ubuntu_PPA/comment_6_bd99fb70399fc58d98781a89c6d38428._comment b/doc/forum/Ubuntu_PPA/comment_6_bd99fb70399fc58d98781a89c6d38428._comment
new file mode 100644
index 0000000000..8252fe5d93
--- /dev/null
+++ b/doc/forum/Ubuntu_PPA/comment_6_bd99fb70399fc58d98781a89c6d38428._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkx5V3MTbzCXS3J7Mn9FEq8M9bPPYMkAHY"
+ nickname="Pedro"
+ subject="comment 6"
+ date="2013-05-20T15:52:40Z"
+ content="""
+Be careful that the fmarier ppa includes more than just git-annex.
+"""]]
diff --git a/doc/forum/Ubuntu_PPA/comment_7_c3f7ec8573934c59d70a48e36e321c13._comment b/doc/forum/Ubuntu_PPA/comment_7_c3f7ec8573934c59d70a48e36e321c13._comment
new file mode 100644
index 0000000000..849381ec29
--- /dev/null
+++ b/doc/forum/Ubuntu_PPA/comment_7_c3f7ec8573934c59d70a48e36e321c13._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://openid.fmarier.org/"
+ nickname="fmarier"
+ subject="New location for my git-annex PPA"
+ date="2013-06-15T07:42:13Z"
+ content="""
+My Ubuntu Precise PPA has moved here: https://launchpad.net/~fmarier/+archive/git-annex
+
+It contains version 20130601 of git-annex.
+
+As Pedro suggested, it's now in a separate PPA with only git-annex and the 220 Haskell packages it depends on.
+"""]]
diff --git a/doc/forum/Ubuntu_PPA/comment_8_feecd478a4d44cb5ffc7020c646174ba._comment b/doc/forum/Ubuntu_PPA/comment_8_feecd478a4d44cb5ffc7020c646174ba._comment
new file mode 100644
index 0000000000..51fde1f039
--- /dev/null
+++ b/doc/forum/Ubuntu_PPA/comment_8_feecd478a4d44cb5ffc7020c646174ba._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawntodrSgODU27WUCyN2PV7TC14YMkyaoxQ"
+ nickname="Dennis"
+ subject="Ubuntu Trusty 14.04"
+ date="2015-01-24T03:19:41Z"
+ content="""
+I am running into the same issue with Ubuntu Trusty 14.04. The version shipped is 5.20140412ubuntu1, but I would like to try a more recent version to see if an issue I experience still persists. Is there any up-to-date PPA available for Trusty?
+"""]]
diff --git a/doc/forum/Un-git-annex__63__.mdwn b/doc/forum/Un-git-annex__63__.mdwn
new file mode 100644
index 0000000000..68e8068fc1
--- /dev/null
+++ b/doc/forum/Un-git-annex__63__.mdwn
@@ -0,0 +1,6 @@
+Hi,
+
+I am using git-annex assistant on my Fedora Linux computer. Everything seems to be working perfectly, however I have noticed that almost all of my files are now symbolic links to cryptic file names located in the .git/ directory. Oddly though it seems files inside git-annex assistant does not move/symbolic link files within git repositories inside my git-annex assist directories. My question is: how can I safely uninstall git-annex from my machine and restore all files to their non-symbolic link states? When I click on the settings drop-down for a repository inside git-annex assistant and choose disable it goes to the same page as the delete option. Any ideas?
+
+Regards,
+Blake
diff --git a/doc/forum/Un-git-annex__63__/comment_1_6059265afb66190d325083e0f28bcf33._comment b/doc/forum/Un-git-annex__63__/comment_1_6059265afb66190d325083e0f28bcf33._comment
new file mode 100644
index 0000000000..907293f99d
--- /dev/null
+++ b/doc/forum/Un-git-annex__63__/comment_1_6059265afb66190d325083e0f28bcf33._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 1"
+ date="2013-10-06T06:45:14Z"
+ content="""
+\"git annex uninit\" is the command which will revert an entire git annex repository back to a bunch of ordinary files, untracked by git annex (or git).  I'm not sure whether there is a way to issue that command from the assistant though.
+
+
+"""]]
diff --git a/doc/forum/Un-git-annex__63__/comment_2_fac4bfb81dbbf0dc82059aace261eb51._comment b/doc/forum/Un-git-annex__63__/comment_2_fac4bfb81dbbf0dc82059aace261eb51._comment
new file mode 100644
index 0000000000..2b1a7381ae
--- /dev/null
+++ b/doc/forum/Un-git-annex__63__/comment_2_fac4bfb81dbbf0dc82059aace261eb51._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlOc-EOD5ZyggsAp6lOnU7x5MxizwLtUXA"
+ nickname="Hendrik"
+ subject="comment 2"
+ date="2013-10-06T18:35:14Z"
+ content="""
+I had uninit'd my annex several time for testing git-annex. What I discovered was that is worked reliably but for all files that are duplicates. For duplicates only 1 of the files got restored properly.  All that was 1 year ago - so your results my differ. I had found a piece of script in the forum / tips sections that will show all duplicates.
+
+Hope this helps...
+"""]]
diff --git a/doc/forum/Unable_to_change_RSS_feeds.mdwn b/doc/forum/Unable_to_change_RSS_feeds.mdwn
new file mode 100644
index 0000000000..02bccd6c3a
--- /dev/null
+++ b/doc/forum/Unable_to_change_RSS_feeds.mdwn
@@ -0,0 +1,8 @@
+Hello. It seems that one of the RSS feed I was using for a podcast is now pointing to a missing server, and so I started getting the error `Unable to access these remotes: web`.
+I found another feed that does not have this problem, but I have not been able to update my git annex repository with this new URL.
+
+I have tried to add the new feed to the feed list and `importfeed` and have tried to use `addurl` to provide an alternate source, but that did not change anything. I tried to remove files and run `importfeed` but `info` always gives the same URL and `get` fails.
+
+What is the proper way to go about this? I am using `importfeed --relaxed --fast --template=...` to pull in the information.
+
+Thank you for any help you can provide.
diff --git a/doc/forum/Unable_to_change_RSS_feeds/comment_1_9f6517f3c6dc8cd4e27d0011efcf2bb5._comment b/doc/forum/Unable_to_change_RSS_feeds/comment_1_9f6517f3c6dc8cd4e27d0011efcf2bb5._comment
new file mode 100644
index 0000000000..414ff36b5f
--- /dev/null
+++ b/doc/forum/Unable_to_change_RSS_feeds/comment_1_9f6517f3c6dc8cd4e27d0011efcf2bb5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-08T16:38:08Z"
+ content="""
+Please show the commands you are trying to run, particularly the git-annex
+addurl, and show how it does not do what you want it to do.
+"""]]
diff --git a/doc/forum/Unable_to_change_RSS_feeds/comment_2_9ed0f746a199bb0ce474b2e9fa4f0a9e._comment b/doc/forum/Unable_to_change_RSS_feeds/comment_2_9ed0f746a199bb0ce474b2e9fa4f0a9e._comment
new file mode 100644
index 0000000000..6c450fbbb6
--- /dev/null
+++ b/doc/forum/Unable_to_change_RSS_feeds/comment_2_9ed0f746a199bb0ce474b2e9fa4f0a9e._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="Thanks"
+ date="2018-10-17T22:46:36Z"
+ content="""
+Hello and thank you for taking an interest and offering your time to help me out, Joey.
+
+I keep a file with a list of podcasts I follow and the relevant (old) URL in it is `https://rss.art19.com/freakonomics-radio`. I import them all with `xargs git annex importfeed --relaxed --fast --template='${feedtitle}/${itempubdate}-${itemtitle}${extension}' < feeds.txt`..
+
+It seems that some files that are referenced in this RSS feed are no longer valid.
+
+    $ git-annex info 2014_10_16-How_Can_Tiny_Norway_Afford_to_Buy_So_Many_Teslas____.mp3
+    file: 2014_10_16-How_Can_Tiny_Norway_Afford_to_Buy_So_Many_Teslas____.mp3
+    size: 0 bytes (+ 1 unknown size)
+    key: URL--http://feedproxy.google.com/,12-63d190ce967f261870566fc1551cb690
+    present: false
+
+I tried to find another RSS feed for this show and came across the more \"official\" `http://freakonomics.com/feed/`.
+
+This was all quite some time ago and I don't recall many details. Since those days I managed to get around this by downloading the files from the archives. It may also be that the feeds have changed since then. I have also upgraded my system (including the version of git-annex), which was kept back many months.
+I was still downloading the old files that I do not see in the RSS feeds now — this may be related to the problem.
+
+The `addurl` does seem to work now, and I can't reproduce the problem I had back then. I'll take this off the table.
+Yet, I do wish that `info` would mention all the URLs associated to the file. It would help pinpoint the problem in such a situation. I still don't know if the importfeed is doing its thing (adding URLS) or not.
+
+Anyway, once more, my appreciation for your interest, your time and your work.
+"""]]
diff --git a/doc/forum/Understanding___34__deletion__34___and___34__dropping__34_____38___cleanup_of_history.mdwn b/doc/forum/Understanding___34__deletion__34___and___34__dropping__34_____38___cleanup_of_history.mdwn
new file mode 100644
index 0000000000..9c6c3df73e
--- /dev/null
+++ b/doc/forum/Understanding___34__deletion__34___and___34__dropping__34_____38___cleanup_of_history.mdwn
@@ -0,0 +1,9 @@
+Hi!
+
+I have a few questions according to deletion and dropping with git-annex:
+
+1. I couldn't figure out what unused files really are. What is *unused* related to? (Head of) branches? How does a file become unused?  
+2. If I'm working in indirect mode, I can safely `git rm` files and restore them later, by checking out the corresponding commit. Consider several git-annex repos being in sync, where the repository contains a nested directory structure. Is there a way to completely remove all deletes files within some directory (which might but not must be the root of the repo), that have been deleted for more than X days? For example I would want to run something like `git annex drop-deleted --from-folder some/subdirectory/ --older-than 5`. Is there a way to achieve this?
+3. Just like 2, is there a way to remove (the content of) all non-current *versions* of all file that are older than Y days?
+
+Thanks in advance!
diff --git a/doc/forum/Understanding___34__deletion__34___and___34__dropping__34_____38___cleanup_of_history/comment_1_08dbad67df1d8f07d3883c6fed2fe0c4._comment b/doc/forum/Understanding___34__deletion__34___and___34__dropping__34_____38___cleanup_of_history/comment_1_08dbad67df1d8f07d3883c6fed2fe0c4._comment
new file mode 100644
index 0000000000..84ec31fd87
--- /dev/null
+++ b/doc/forum/Understanding___34__deletion__34___and___34__dropping__34_____38___cleanup_of_history/comment_1_08dbad67df1d8f07d3883c6fed2fe0c4._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-04T19:55:54Z"
+ content="""
+`git-annex unused` finds files that are not used by the heads of any
+branches or tags. These files may still be referred to in individual
+commits in git history, or there could be no commits at all that 
+refer to them. It's up to you to decide whether these are really
+"unused" or not.
+
+git-annex doesn't currently have an concept of file age. You can
+look at git history to find that out, but it's quite expensive 
+to do that for a lot of files, and so a --older-than option
+would make it pretty slow.
+"""]]
diff --git a/doc/forum/Undo_Git_Annex_Changes_To_Linked_Files.mdwn b/doc/forum/Undo_Git_Annex_Changes_To_Linked_Files.mdwn
new file mode 100644
index 0000000000..c299041f02
--- /dev/null
+++ b/doc/forum/Undo_Git_Annex_Changes_To_Linked_Files.mdwn
@@ -0,0 +1,7 @@
+Hello,
+
+I was recently evaluating git-annex as a file sync tool, but I've got my files in a state where they are a mess.  The short version is that I have a local repo, and then an Encrypted S3 remote.  Once I encrypted the files, they got renamed and so forth and the files are now just symbolic links to files within the .git directory somewhere.   This has made some of them unusable for me and I need to revert the files back to not being symlinks any longer.  How would I go about doing that?
+
+Thanks,
+
+Brandon
diff --git a/doc/forum/Undo_Git_Annex_Changes_To_Linked_Files/comment_1_568dde820c2608d86d05b07444146a26._comment b/doc/forum/Undo_Git_Annex_Changes_To_Linked_Files/comment_1_568dde820c2608d86d05b07444146a26._comment
new file mode 100644
index 0000000000..21cf455229
--- /dev/null
+++ b/doc/forum/Undo_Git_Annex_Changes_To_Linked_Files/comment_1_568dde820c2608d86d05b07444146a26._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 1"
+ date="2013-07-28T00:09:45Z"
+ content="""
+Run:
+
+`git annex get $file`
+`git annex unannex $file`
+
+$file will now be back how it was before you used git-annex. Can also run above on whole directories.
+"""]]
diff --git a/doc/forum/Undo_Git_Annex_Changes_To_Linked_Files/comment_2_a8cf71cdf1217d9c8596cd9006eb83f5._comment b/doc/forum/Undo_Git_Annex_Changes_To_Linked_Files/comment_2_a8cf71cdf1217d9c8596cd9006eb83f5._comment
new file mode 100644
index 0000000000..2e9c387ad4
--- /dev/null
+++ b/doc/forum/Undo_Git_Annex_Changes_To_Linked_Files/comment_2_a8cf71cdf1217d9c8596cd9006eb83f5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmRFsVANDSwNHzCWk-iP2_nXnfYKPJWziE"
+ nickname="Brandon"
+ subject="comment 2"
+ date="2013-07-28T03:26:23Z"
+ content="""
+Thanks, much appreciated.  Got all of my files back successfully.
+"""]]
diff --git a/doc/forum/Undo_git_merge_git-annex.mdwn b/doc/forum/Undo_git_merge_git-annex.mdwn
new file mode 100644
index 0000000000..bc299174cb
--- /dev/null
+++ b/doc/forum/Undo_git_merge_git-annex.mdwn
@@ -0,0 +1,3 @@
+After accidentally typing git merge git-annex, I am now wondering how to clean up the resulting chaos...
+
+Any tips?
diff --git a/doc/forum/Undo_git_merge_git-annex/comment_1_0b15f7a8c3bca87dcbf748a229e13a4b._comment b/doc/forum/Undo_git_merge_git-annex/comment_1_0b15f7a8c3bca87dcbf748a229e13a4b._comment
new file mode 100644
index 0000000000..bbc6117f7b
--- /dev/null
+++ b/doc/forum/Undo_git_merge_git-annex/comment_1_0b15f7a8c3bca87dcbf748a229e13a4b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="frederik@ffbea6a549cb3f460d110386c0f634c1ddc6a68a"
+ nickname="frederik"
+ subject="comment 1"
+ date="2016-03-04T14:06:17Z"
+ content="""
+git revert -m 1 [sha_of_merge] seems to have done the trick
+"""]]
diff --git a/doc/forum/Undo_git_merge_git-annex/comment_2_c5a8839c53145a3b0d44950096c5180f._comment b/doc/forum/Undo_git_merge_git-annex/comment_2_c5a8839c53145a3b0d44950096c5180f._comment
new file mode 100644
index 0000000000..4db2007616
--- /dev/null
+++ b/doc/forum/Undo_git_merge_git-annex/comment_2_c5a8839c53145a3b0d44950096c5180f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-03-07T17:25:08Z"
+ content="""
+`git reflog` is a handy command to get to know, for getting out of
+situations along the lines of "I did $something wrong and want to get back
+to a previous version of a branch"
+"""]]
diff --git a/doc/forum/Unknown_remote_type_S3.mdwn b/doc/forum/Unknown_remote_type_S3.mdwn
new file mode 100644
index 0000000000..ae8432286c
--- /dev/null
+++ b/doc/forum/Unknown_remote_type_S3.mdwn
@@ -0,0 +1,5 @@
+I have an annex set up with an s3 special remote. It works fine on one computer. I cloned the annex to a USB stick, plugged the stick into a second computer and cloned the annex to that machine. When I try to `git annex initremote cloud` on the second machine, I get the following error:
+
+    git-annex: Unknown remote type S3
+
+The second machine is running git-annex 3.20121017.
diff --git a/doc/forum/Unknown_remote_type_S3/comment_1_2aea2cd51286c809427d16519606cd37._comment b/doc/forum/Unknown_remote_type_S3/comment_1_2aea2cd51286c809427d16519606cd37._comment
new file mode 100644
index 0000000000..80e1b11aa1
--- /dev/null
+++ b/doc/forum/Unknown_remote_type_S3/comment_1_2aea2cd51286c809427d16519606cd37._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 1"
+ date="2012-11-07T18:57:17Z"
+ content="""
+It's possible to build git-annex without S3 support. I think a few Linux distros ship it this way due to not having all the necessary haskell libraries.
+"""]]
diff --git a/doc/forum/Unknown_remote_type_S3/comment_2_06f775062cd30767979fe56bcb3cf7bf._comment b/doc/forum/Unknown_remote_type_S3/comment_2_06f775062cd30767979fe56bcb3cf7bf._comment
new file mode 100644
index 0000000000..75864aedc5
--- /dev/null
+++ b/doc/forum/Unknown_remote_type_S3/comment_2_06f775062cd30767979fe56bcb3cf7bf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="annexuser"
+ ip="24.16.193.140"
+ subject="comment 2"
+ date="2012-11-07T20:12:27Z"
+ content="""
+That was the issue. Thank you!
+"""]]
diff --git a/doc/forum/Unlock_files_when_assistant_is_running__63__.mdwn b/doc/forum/Unlock_files_when_assistant_is_running__63__.mdwn
new file mode 100644
index 0000000000..0c514368ab
--- /dev/null
+++ b/doc/forum/Unlock_files_when_assistant_is_running__63__.mdwn
@@ -0,0 +1,13 @@
+I just started using the assistant on an existing annex. I fire up the assistant like so:
+
+    $ git annex webapp
+
+Everything syncs and looks to be working fine. In another terminal, I then create a new file:
+
+    $ touch testfile.txt
+
+The assistant sees that file, immediately adds it and syncs. Ok. So now I want to edit that file.
+
+    $ git annex unlock testfile.txt
+
+As soon as I unlock the file, the assistant re-adds it to the annex and syncs, preventing me from editing the file. How can I edit files with the assistant running?
diff --git a/doc/forum/Unlock_files_when_assistant_is_running__63__/comment_1_3f4aadf0c856c81e15c6f5ae7f1992b4._comment b/doc/forum/Unlock_files_when_assistant_is_running__63__/comment_1_3f4aadf0c856c81e15c6f5ae7f1992b4._comment
new file mode 100644
index 0000000000..f17fc56345
--- /dev/null
+++ b/doc/forum/Unlock_files_when_assistant_is_running__63__/comment_1_3f4aadf0c856c81e15c6f5ae7f1992b4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 1"
+ date="2012-11-11T16:06:42Z"
+ content="""
+I suspect you have an old build of the assistant. Version 3.20121009 was supposed to fix this.
+
+I re-tested with current git head today, and found I was able to unlock a file, repeatedly edit it in place without the assistant re-adding it, and then run \"git annex add\" and the assistant auto-committed the changed file. Better behavior than I was expecting in fact -- the ability to repeatedly edit is a pleasant surprise.
+"""]]
diff --git a/doc/forum/Unlock_files_when_assistant_is_running__63__/comment_2_a76797ee9e05e43af7947508cadd7bed._comment b/doc/forum/Unlock_files_when_assistant_is_running__63__/comment_2_a76797ee9e05e43af7947508cadd7bed._comment
new file mode 100644
index 0000000000..5567205235
--- /dev/null
+++ b/doc/forum/Unlock_files_when_assistant_is_running__63__/comment_2_a76797ee9e05e43af7947508cadd7bed._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="annexuser"
+ ip="24.16.193.140"
+ subject="comment 2"
+ date="2012-11-12T20:09:20Z"
+ content="""
+    $ git annex version                                                   
+    git-annex version: 3.20121017
+"""]]
diff --git a/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked.mdwn b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked.mdwn
new file mode 100644
index 0000000000..7c8e55fc4e
--- /dev/null
+++ b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked.mdwn
@@ -0,0 +1,13 @@
+Hello!
+
+How can I have just a single directory unlocked at all times?
+
+• I’m running the Assistant.
+
+• If a new file is created in it, I’d like it to be added to annex BUT automatically unlocked (kept editable).
+
+• If such an unlocked file is changed, I’d like the Assistant to sync the change.
+
+How can this be configured?
+
+Thank you!
diff --git a/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_1_cd08064d171bea606df1cb7dafbdd381._comment b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_1_cd08064d171bea606df1cb7dafbdd381._comment
new file mode 100644
index 0000000000..36c6b89f0b
--- /dev/null
+++ b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_1_cd08064d171bea606df1cb7dafbdd381._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 1"
+ date="2017-08-16T11:03:03Z"
+ content="""
+So something along the lines of direct mode but *just for one* subdirectory.
+"""]]
diff --git a/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_2_6da3347c2d9243a9fe61fd75999d6f36._comment b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_2_6da3347c2d9243a9fe61fd75999d6f36._comment
new file mode 100644
index 0000000000..5efa8f82ab
--- /dev/null
+++ b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_2_6da3347c2d9243a9fe61fd75999d6f36._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 2"
+ date="2017-08-16T12:47:48Z"
+ content="""
+Whoa.
+
+I just upgraded my repo to v6 (6.20170520), and it seems that a running assistant is adding every new file unlocked. :-o
+
+How can I control which file will get added unlocked and which locked by the assistant?
+"""]]
diff --git a/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_3_78dfedd93393709d3d7e417b779109d4._comment b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_3_78dfedd93393709d3d7e417b779109d4._comment
new file mode 100644
index 0000000000..22a5974c3f
--- /dev/null
+++ b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_3_78dfedd93393709d3d7e417b779109d4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 3"
+ date="2017-08-16T12:58:24Z"
+ content="""
+But it’s better. As a dirty workaround, I could add a cron job/timer that would periodically git-annex-lock all files *except* that single directory I want unlocked.
+
+But a static configuration—say, in .gitattributes—would be way better. ♥
+
+Or is there a way to configure that already?
+"""]]
diff --git a/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_4_bdd6cb9cdf2366e5d930c0cdd80b3984._comment b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_4_bdd6cb9cdf2366e5d930c0cdd80b3984._comment
new file mode 100644
index 0000000000..a2efa3955d
--- /dev/null
+++ b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_4_bdd6cb9cdf2366e5d930c0cdd80b3984._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-08-17T15:56:25Z"
+ content="""
+There's the annex.addunlocked setting which controls this in v6
+repositories, but it's currently limited to true/false, can't configure
+different behavior in different directories.
+
+I'd probably need a motivating example to make it configurable in
+.gitattributes. Having a hard time currently understanding how that would
+be useful.
+"""]]
diff --git a/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_5_7a2109bbe16de4c05db48763d00bfaf1._comment b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_5_7a2109bbe16de4c05db48763d00bfaf1._comment
new file mode 100644
index 0000000000..df3883bd22
--- /dev/null
+++ b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_5_7a2109bbe16de4c05db48763d00bfaf1._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="michalrus"
+ avatar="http://cdn.libravatar.org/avatar/83c0b6e7f9d20f09a892263c4903bbae"
+ subject="comment 5"
+ date="2017-08-17T17:53:24Z"
+ content="""
+My particular example is that I’m using git-annex:
+
+• mostly as an archive (esp. in family files context),
+
+• but also as a sort-of FLOSS Dropbox for some specific files, that we’re editing.
+
+I’d like to prevent easy (accidental, really) editing of those archived files.
+
+Does this make sense?
+
+Thank you!
+"""]]
diff --git a/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_6_9ed97ec6e540f2b795bf5bc11fcfdc90._comment b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_6_9ed97ec6e540f2b795bf5bc11fcfdc90._comment
new file mode 100644
index 0000000000..e02442d79c
--- /dev/null
+++ b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_6_9ed97ec6e540f2b795bf5bc11fcfdc90._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="jenkin.schibel@286264d9ceb79998aecff0d5d1a4ffe34f8b8421"
+ nickname="jenkin.schibel"
+ avatar="http://cdn.libravatar.org/avatar/692d82fb5c42fc86d97cc44ae0fb61ca"
+ subject="i would like to have this feature revisted, collaberative wiki editing"
+ date="2021-08-26T15:20:27Z"
+ content="""
+i have recently found a use case for a feature like this.
+
+My use case is that i have an annex that hosts and backs up all my familys files.  most of these files are things like pictures.  but some of these are also going to be files that my family and i are actively modifying (i.e a personal wiki)  and whenever we add a new file to the wiki files, it would be nice to have the assistant automatically add and synchronize changes, but it always adds the new ones as locked files, so we have to go in and unlock them.  So i think it would e useful to have a configuration where you give it a list of directories you where you would like git-annex to add the files and any files added to these directories are immediately unlocked  I realize that we could probably just go with the workflow of adding these mostly text files to git instead of git-annex, but i like being able to backup these files to all of the \"special\" backup remotes that i have the other files synchronizing with.
+
+hope this made sense
+"""]]
diff --git a/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_7_c6f1dd606d2aa9aa473cdd3a6d92bd33._comment b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_7_c6f1dd606d2aa9aa473cdd3a6d92bd33._comment
new file mode 100644
index 0000000000..430c3779b6
--- /dev/null
+++ b/doc/forum/Unlocked_directory__63___Having_all_its_new_files_unlocked/comment_7_c6f1dd606d2aa9aa473cdd3a6d92bd33._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-09-06T19:50:02Z"
+ content="""
+The annex.addunlocked config is able to do this, since version 7.20191230.
+It can be set to a [[git-annex-matching-expression]]
+eg "include=wiki/*" would make files in the top-level wiki directory always
+be added unlocked, and other files would be added locked.
+Matching on file extensions etc is also possible.
+"""]]
diff --git a/doc/forum/Unlocked_files_confusion.mdwn b/doc/forum/Unlocked_files_confusion.mdwn
new file mode 100644
index 0000000000..6dfca5e097
--- /dev/null
+++ b/doc/forum/Unlocked_files_confusion.mdwn
@@ -0,0 +1,40 @@
+**EDIT:** Is there a way to apply ```annex.addunlocked``` permanently to a single file? It would be great if it could be added to the ```annex.largefiles``` options. This way a repository could have locked large files, unlocked large files, and regular files added directly to git.
+
+Leaving my confusion below for reference (Sorry should have read the unlocked files page more before I posted).
+
+---  
+
+I'm having trouble getting unlocked files in version 7 repositories to work and I think I'm pretty confused (what I mean is that it's not git annex's fault).
+
+I have my Calibre library in a git-annex repo. I want ```metadata.db```, Calibre's sqlite database to stay unlocked but I don't get the expected results.
+Also I put ```metadata.db annex.largefiles=nothing``` in my ```.gitattributes``` file, could this be causing an issue?
+ 
+Version information:  
+  
+OS X 10.14  
+
+    $ git annex version
+    git-annex version: 7.20190322
+    ...
+    local repository version: 7
+
+Edit metadata for book in Calibre and then (using git add here to just make sure):  
+
+    $ git add metadata.db
+    $ git commit -m "metadata changes"
+    [master 5602968d1] metadata changes
+      1 file changed, 0 insertions(+), 0 deletions(-)
+    $ git annex find metadata.db
+    $ echo $?
+    0 
+
+Are git annex pointer files hardlinks? I tried:  
+
+    $ ls -i metadata.db
+    1497387 metadata.db
+    $ find . -inum 1497387
+    metadata.db 
+
+I was expecting a second file there?
+
+Anyway, thanks for any help with this. 
diff --git a/doc/forum/Unlocked_files_confusion/comment_1_6442aa304b4d44bfc6bc038f4b55f37a._comment b/doc/forum/Unlocked_files_confusion/comment_1_6442aa304b4d44bfc6bc038f4b55f37a._comment
new file mode 100644
index 0000000000..51e5230475
--- /dev/null
+++ b/doc/forum/Unlocked_files_confusion/comment_1_6442aa304b4d44bfc6bc038f4b55f37a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-07-19T17:02:59Z"
+ content="""
+Your .gitattributes setting configured git-annex to not
+treat metadata.db as a large file, so its content gets added to git.
+
+git-annex does not hard link locked files by ddefault, setting annex.thin
+can make it do so.
+
+There is not currently a way to configure whether a file
+is added locked or unlocked by filename. I have opened a todo
+about it, [[todo/annex.addunlocked_in_gitattributes]].
+"""]]
diff --git a/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__.mdwn b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__.mdwn
new file mode 100644
index 0000000000..b5f54fc67f
--- /dev/null
+++ b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__.mdwn
@@ -0,0 +1,13 @@
+I'm working on setting things up for making archives on both hard drives and possibly optical media.  I want them readable without needing to have Linux or git-annex, so I'm going to be using NTFS (for HDDs) and UDF (for optical).  So I'm using adjust --unlocked everywhere.  I don't want anything mucking with the source data; making hard links, tweaking timestamps, etc.
+
+Additionally, timestamps are highly relevant for me to preserve.
+
+Initially I thought I might be able to use the directory remote with importdirectory, but I ran into a lot of performance problems with my 150,000-file setup, as well as the bug at [[/bugs/Files_recorded_with_other_file__39__s_checksums/]].  So I'm trying to work without the special remote at all, which seems to be much more performant and, I suspect, less buggy.
+
+So now I'm thinking of having a repo on each drive, and rsyncing the content to it.  I can easily enough exclude .git.  Then I git annex add, git annex sync, and I think I've got what I need.
+
+The question is, why, with unlocked mode, do we have to have the files also stored in .git/annex?  Of course, most (though not all) files will be hardlinked to them.  But as we know, when we modify a file, it invalidates its checksum, so I'm not really seeing what this adds.
+
+If we didn't have to do this, I could just add git-annex to the source repo itself, secure in the notion that if I only push out from there, it will never modify anything there at all.  Then I could just pull elsewhere.
+
+On the targets, I guess it doesn't hurt too much since it's hardlinked.
diff --git a/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_1_d35829cd466139e0e77a79c251a79ad8._comment b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_1_d35829cd466139e0e77a79c251a79ad8._comment
new file mode 100644
index 0000000000..feccf87b64
--- /dev/null
+++ b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_1_d35829cd466139e0e77a79c251a79ad8._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-09T18:54:08Z"
+ content="""
+Suppose git-annex did behave that way. Now suppose that you ran:
+
+	git config annex.largefiles 'include=*'
+	git add largefile
+	git commit -m 'added a large file to git-annex (unlocked)'
+	git stash
+
+Then git would have deleted the only copy of largefile, which
+was the one stored in the working tree. You would have lost data.
+The hard links, annoying as they are, avoid this problem.
+
+> But as we know, when we modify a file, it invalidates its checksum
+
+Right, and if you're going to be running things that open and modify
+files, then it is not safe to set annex.thin. 
+"echo foo > largefile" will modify the file and lose the original version.
+
+The difference is that you have to run something that does usually
+modify the file to lose data (with annex.thin set). 
+Running a git command that is normally entirely safe will not lose data.
+
+So the user of annex.thin only needs to keep in mind that some things that
+would usually modify a file will lose the previous version of it,
+unless they've copied it to another remote. They don't have to live in fear
+of running a command that is usually safe and reversable and that causing
+data loss.
+"""]]
diff --git a/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_2_07861ab33ec31659ec3cfa8520580fd4._comment b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_2_07861ab33ec31659ec3cfa8520580fd4._comment
new file mode 100644
index 0000000000..4fd8f9fdde
--- /dev/null
+++ b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_2_07861ab33ec31659ec3cfa8520580fd4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 2"
+ date="2022-09-10T00:32:57Z"
+ content="""
+In my case, I really don't care about losing the old version of a file.  I have ZFS snapshots and backups to take care of that. I do use thin, and that particular issue doesn't really bother me.  I wounder if a \"superthin\" where there is no hardlinking into .git/annex at all would be possible?  I'm aware that, yes, that could make previous versions unavailable and so forth.
+"""]]
diff --git a/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_3_ce7ff5d0ea390649af64a296fecf9113._comment b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_3_ce7ff5d0ea390649af64a296fecf9113._comment
new file mode 100644
index 0000000000..51c2f12e88
--- /dev/null
+++ b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_3_ce7ff5d0ea390649af64a296fecf9113._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-09-13T19:10:48Z"
+ content="""
+If you're using ZFS, you should not need to set annex.thin at all;
+git-annex will use reflinks between annex object files and unlocked working
+tree files, the annex object file will not use any additional disk space.
+"""]]
diff --git a/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_4_b7eead64e39b5ebb1a22131b4e35251e._comment b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_4_b7eead64e39b5ebb1a22131b4e35251e._comment
new file mode 100644
index 0000000000..0e779dfec3
--- /dev/null
+++ b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_4_b7eead64e39b5ebb1a22131b4e35251e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 4"
+ date="2022-09-14T15:09:20Z"
+ content="""
+ZFS doesn't support reflinks. XFS does.
+"""]]
diff --git a/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_5_97fd65626991b1e8012e15595941d25d._comment b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_5_97fd65626991b1e8012e15595941d25d._comment
new file mode 100644
index 0000000000..a9c0c944f3
--- /dev/null
+++ b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_5_97fd65626991b1e8012e15595941d25d._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-09-15T16:27:54Z"
+ content="""
+Ah, oops..  I was thinking about BTRFS..
+
+However, getting back to the original motivation of jgoerzen to
+request this, it seems to come down to making a hard link being seen as
+"mucking with the source data". That seems like a very weak reason to make
+such a very large change to git-annex, that would only be safe in a
+small and poorly defined set of circumstances.
+
+And it would be a large change, because currently git-annex can broadly
+assume that any time a .git/annex/objects/ file exists, the content
+is present in the repository. Every place that makes that assumption
+would need to instead check if any of the known work tree files that use
+the object are populated with the content (or at least are not annex
+pointer files).
+
+(jgoerzen also mentions timestamps, but git-annex preserves those
+when ingesting files. Of course timestamp data is not recorded in the git
+repository unless you use some other tool to do so.)
+"""]]
diff --git a/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_6_f2572320e3cc93c7dd6db51e78f31c10._comment b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_6_f2572320e3cc93c7dd6db51e78f31c10._comment
new file mode 100644
index 0000000000..09e7405c9a
--- /dev/null
+++ b/doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_6_f2572320e3cc93c7dd6db51e78f31c10._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 6"
+ date="2022-09-19T14:49:02Z"
+ content="""
+I understand what you're saying here, and at this point this is probably not super relevant due to the large change it would represent, but just thought I'd further clarify the use case....
+
+I, in some cases, use hard links fairly intentionally.  \"This file is both a photo and a record of something; let me show it in both places.\"  I don't want things hardlinked together that previously weren't, and don't want existing hardlinks broken.  Now this is for my daily use; for long-term archiving, it isn't all that important.  So I don't want hard links being adjusted on the source, but don't care so much about the destination (at least so long as broken hardlinks don't result in excessive increases in storage space requirements; but my main area where that would occur has 10s of millions of files, so won't be using git-annex for other reasons.)
+
+Also in some cases, I have a read-only directory (whether from NFS mount or something else).  It is easy enough to mount a .git onto it, via a bind-mount or anything else, but trying to modify the actual content of course wouldn't work.
+
+Anyhow, thanks for the conversation!
+"""]]
diff --git a/doc/forum/Unlocking_files_gives_symlink_content.mdwn b/doc/forum/Unlocking_files_gives_symlink_content.mdwn
new file mode 100644
index 0000000000..ec341c7d93
--- /dev/null
+++ b/doc/forum/Unlocking_files_gives_symlink_content.mdwn
@@ -0,0 +1,14 @@
+I am just beginning to use git-annex so it is possible that the following issue was caused by my own mistake. It cropped up after commiting a number of files that had been moved between subfolders, and added with `git add -A` etc.
+
+When files are locked, I am able to view their contents. However, when I unlock certain files, their contents appear to be replaced by the contents of the symlink. Locking them again allows me to view their contents. For instance, with one unlocked file, say `test.md`, I get
+
+    $ cat test.md
+    /annex/objects/SHA256E-s535--d37feb3390801b601a9cee77f6467f01aaabbb293149d20d75df26172a3594fd.md
+
+Some files still behave as expected.
+
+My git-annex repo is in my Linux home folder on an ext4 partition. My repo uses git-annex version 6.
+
+I did have a look at [this discussion](https://git-annex.branchable.com/forum/git_annex_file_content_replaced_with_symlink_content/) but none of the solutions there seemed to do the trick.
+
+Any help is much appreciated.
diff --git a/doc/forum/Unlocking_files_gives_symlink_content/comment_1_f8032a5ea72f2cd833a626a197f94ba2._comment b/doc/forum/Unlocking_files_gives_symlink_content/comment_1_f8032a5ea72f2cd833a626a197f94ba2._comment
new file mode 100644
index 0000000000..91091ff906
--- /dev/null
+++ b/doc/forum/Unlocking_files_gives_symlink_content/comment_1_f8032a5ea72f2cd833a626a197f94ba2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-16T15:25:25Z"
+ content="""
+Please note that repository version 6, which you are using, is still experimental, it has
+known bugs and probably unknown bugs.
+
+I think this is an unknown bug, probably something has gotten inconsistent
+in the keys database and it doesn't realize it has the content.
+
+I found one way to cause this, filed a bug:
+[[bugs/v6_unlock_confused_by_touch]]
+"""]]
diff --git a/doc/forum/Unlocking_files_gives_symlink_content/comment_2_f50b8ef54737798183490d5a660248f2._comment b/doc/forum/Unlocking_files_gives_symlink_content/comment_2_f50b8ef54737798183490d5a660248f2._comment
new file mode 100644
index 0000000000..a3a1df0e75
--- /dev/null
+++ b/doc/forum/Unlocking_files_gives_symlink_content/comment_2_f50b8ef54737798183490d5a660248f2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="erewhon_smith@6671dff14d578cb6d55a3ca285f2c54151b69f60"
+ nickname="erewhon_smith"
+ avatar="http://cdn.libravatar.org/avatar/b9bd5ad7176ebe149d0f051dcfe0a63e"
+ subject="comment 2"
+ date="2018-10-17T18:45:59Z"
+ content="""
+Joey, thanks for the response, not to mention also for this brilliant piece of software. I understand version 6 still being experimental.
+
+Do you have any thoughts on how I can repair my repository at this point so that unlocking files gives me back their contents?
+"""]]
diff --git a/doc/forum/Unlocking_files_gives_symlink_content/comment_3_29e467b112a94736147708c6892dae9c._comment b/doc/forum/Unlocking_files_gives_symlink_content/comment_3_29e467b112a94736147708c6892dae9c._comment
new file mode 100644
index 0000000000..8e63b4e35d
--- /dev/null
+++ b/doc/forum/Unlocking_files_gives_symlink_content/comment_3_29e467b112a94736147708c6892dae9c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 3"
+ date="2018-11-11T23:13:29Z"
+ content="""
+Did you try Joey's suggestion? “Another way to get out of this situation would be to edit the files, and remove the initial lines so it contains a single line that is the link target of the symlink (the bit with .git/annex/objects in it). Then, git annex fsck would be able to fix up the files.”
+
+What is the output of `readlink test.md` when test.md is locked?
+"""]]
diff --git a/doc/forum/Update_on_remote_repo.mdwn b/doc/forum/Update_on_remote_repo.mdwn
new file mode 100644
index 0000000000..4977c41597
--- /dev/null
+++ b/doc/forum/Update_on_remote_repo.mdwn
@@ -0,0 +1,6 @@
+Hello,
+
+using the git-annex assistant I can activate auto update on the client machines. What about the server that serves as transfer repository? It needs to have git-annex installed. Is there any possibility of auto update there? What is the recommended procedure?
+
+Thanks,
+Florian
diff --git a/doc/forum/Update_on_remote_repo/comment_1_d58cfe914d6c36d8bff8d1342e1c2102._comment b/doc/forum/Update_on_remote_repo/comment_1_d58cfe914d6c36d8bff8d1342e1c2102._comment
new file mode 100644
index 0000000000..d4a7a62e6f
--- /dev/null
+++ b/doc/forum/Update_on_remote_repo/comment_1_d58cfe914d6c36d8bff8d1342e1c2102._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-12-02T17:05:05Z"
+ content="""
+You can run the git-annex assistant in any (non-bare) git repository,
+including one on the server.
+
+A git post-receive hook is another way to update a repository on
+a server. See [[tips/setup_a_public_repository_on_a_web_site]]
+"""]]
diff --git a/doc/forum/Updating_a_podcast_episode_checksum.mdwn b/doc/forum/Updating_a_podcast_episode_checksum.mdwn
new file mode 100644
index 0000000000..a34890155c
--- /dev/null
+++ b/doc/forum/Updating_a_podcast_episode_checksum.mdwn
@@ -0,0 +1,27 @@
+I've been experimenting with `git-annex` as a podcatcher and really loving it so far. I've just hit one small snag I'm unclear on how best to resolve.
+
+I initially added a feed with a command like the following
+
+```
+git annex importfeed --fast --template='example-podcast/${itempubdate}-${itemtitle}${extension}' https://example.org/example.rss
+git annex get example-podcast/*
+```
+
+This downloaded nearly all of the episodes of the podcast. Several episodes, however, failed with errors like the following:
+
+```
+get 2020_03_12-The_Covenanters.mp3 (from web...) 
+                                   
+  verification of content failed
+
+  Unable to access these remotes: web
+
+  Try making some of these repositories available:
+  	00000000-0000-0000-0000-000000000001 -- web
+failed
+git-annex: get: 1 failed
+```
+
+Based on [this thread](https://git-annex.branchable.com/forum/Simple_question_about_web_remote/) I gather that the problem is that one file size was returned when I ran `importfeed` and another was returned on the subsequent `get`. What I'd like to download all of the episodes that failed to download (i.e. all of those that are not present in the annex right now) and update their checksums to match the file size currently returned by their respective URLs.
+
+I would prefer not to switch to a URL backend, because as I understand it this would mean that at some time in the future the file could be updated on the webserver and my local copy could be overwritten. For that reason, I would like to update the checksums for all podcast episodes this one time, so I can finish downloading the series and be assured that these versions of the episodes will be preserved. 
diff --git a/doc/forum/Updating_a_podcast_episode_checksum/comment_1_8a4c7119f55dba5ff3cb858dbc96f1a5._comment b/doc/forum/Updating_a_podcast_episode_checksum/comment_1_8a4c7119f55dba5ff3cb858dbc96f1a5._comment
new file mode 100644
index 0000000000..5d3a806355
--- /dev/null
+++ b/doc/forum/Updating_a_podcast_episode_checksum/comment_1_8a4c7119f55dba5ff3cb858dbc96f1a5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-04-27T16:27:49Z"
+ content="""
+What you can do is run `git annex whereis` on the file,
+and paste the url to `git annex addurl`. Once it downloads it to a 
+new file, you can rename that over top of the old file.
+
+(BTW, `git annex importfeed --fast` uses the URL backend,
+which you mentioned you did not want to use. Easily dealt with
+by running `git annex migrate` on the files.)
+"""]]
diff --git a/doc/forum/Updating_repository_permissions.mdwn b/doc/forum/Updating_repository_permissions.mdwn
new file mode 100644
index 0000000000..5d85f4893c
--- /dev/null
+++ b/doc/forum/Updating_repository_permissions.mdwn
@@ -0,0 +1,18 @@
+Hello everyone,
+
+I would like to make a repository readable and writable over ssh for all users of a given group.
+
+A [quick search](https://stackoverflow.com/a/29646155) led me to the following procedure :
+
+```bash
+cd <project_dir>/                         # Enter inside the project directory
+git config core.sharedRepository group    # Update the git's config
+chgrp -R <group-name> .                   # Change files and directories' group
+chmod -R g+w .                            # Change permissions
+chmod g-w .git/objects/pack/*             # Git pack files should be immutable
+find -type d -exec chmod g+s {} +         # New files get directory's group id
+```
+
+My question is simple : is it safe to apply it to a git-annex repository as well ?
+
+Thank you for your help.
diff --git a/doc/forum/Upspin.mdwn b/doc/forum/Upspin.mdwn
new file mode 100644
index 0000000000..0ef764130a
--- /dev/null
+++ b/doc/forum/Upspin.mdwn
@@ -0,0 +1,5 @@
+As soon as I read about Upspin, I thought about git-annex.  Could Upspin's interfaces be beneficial to the project and provide a standardization for naming, permissions and access control?
+
+I realize some of these concepts are not yet part of git-annex, but I thought I'd drop the note and give you the opportunity to evaluate the extent in which Upspin makes sense in the context of git-annex.
+
+https://upspin.io/
diff --git a/doc/forum/Upspin/comment_1_30adffff50a043c14b765ebdc6d637d2._comment b/doc/forum/Upspin/comment_1_30adffff50a043c14b765ebdc6d637d2._comment
new file mode 100644
index 0000000000..7281f29298
--- /dev/null
+++ b/doc/forum/Upspin/comment_1_30adffff50a043c14b765ebdc6d637d2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="unicell@9c0b0afd4176d5933d4b5c41350ebe61488c1df0"
+ nickname="unicell"
+ avatar="http://cdn.libravatar.org/avatar/ac836d39c7be1503f636843bdcd7b199"
+ subject="comment 1"
+ date="2017-02-23T23:05:10Z"
+ content="""
+Wondering exactly the same thing
+"""]]
diff --git a/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster.mdwn b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster.mdwn
new file mode 100644
index 0000000000..5c1432d15b
--- /dev/null
+++ b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster.mdwn
@@ -0,0 +1,2 @@
+I am looking to add a uri of files on my institution's HPC cluster to my local git annex with the git annex addurl command. I am able to get transfers over http working, but want to know if other protocols such as sftp or rsync are also available.
+What is your advice for accessing files from HPC systems for which the files are not in a remote annex (due to other limitations).
diff --git a/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_10_55d285c796f04049e26b6810c7c879ad._comment b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_10_55d285c796f04049e26b6810c7c879ad._comment
new file mode 100644
index 0000000000..10e090a0b4
--- /dev/null
+++ b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_10_55d285c796f04049e26b6810c7c879ad._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="DavidD"
+ avatar="http://cdn.libravatar.org/avatar/9e7cced3eede4bf75fb932bfdd4f8847"
+ subject="comment 10"
+ date="2022-08-29T21:19:56Z"
+ content="""
+Am I correct in stating that storing credentials in a .netrc file is the only way to authenticate during a file download?
+"""]]
diff --git a/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_11_7c7c0b3442902dbe0b9f875e0f1b634a._comment b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_11_7c7c0b3442902dbe0b9f875e0f1b634a._comment
new file mode 100644
index 0000000000..307fee8b18
--- /dev/null
+++ b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_11_7c7c0b3442902dbe0b9f875e0f1b634a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2022-09-16T16:57:36Z"
+ content="""
+git-annex doesn't prompt for passwords for files downloaded from the web,
+and it only stores the password if it's included in the url given to it. 
+
+So if you don't want to store the password in the git repository, storing
+it in an outside file like the netrc file seems like the only way.
+
+I wonder if the web special remote is a good fit for what you're doing at
+all. It's not intended for authenticated access, but for access to files on
+the public web. It may be that you would be better off using a
+special-purpose remote that handles the downloads and passwords in whatever
+way makes sense for the HPC cluster. See [[special_remotes/external]].
+"""]]
diff --git a/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_1_bc5ffcf6d3b72c1ed7b7763549880560._comment b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_1_bc5ffcf6d3b72c1ed7b7763549880560._comment
new file mode 100644
index 0000000000..816bee69c8
--- /dev/null
+++ b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_1_bc5ffcf6d3b72c1ed7b7763549880560._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-15T15:46:40Z"
+ content="""
+git-annex can be used with any url scheme that curl supports, but you have to
+configure it to allow using it. See the documentation 
+of annex.security.allowed-url-schemes in the git-annex man page.
+
+You will also have to set annex.security.allowed-ip-addresses
+to "all".
+
+It seems that even with both settings, git-annex still avoids using curl
+for unsupported url schemes, unless you also set annex.web-options
+to some option used by curl. That forces it to use curl. I set it to
+"--netrc". You will probably need to use that option anyway since I think
+curl needs configuration in a netrc file to authenticate for sftp.
+
+(I feel that it's a bug that annex.web-options needs to be set to make it
+use curl, and I've fixed that in master.)
+"""]]
diff --git a/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_2_3bd66bf73386821c3837fe9da841fd1e._comment b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_2_3bd66bf73386821c3837fe9da841fd1e._comment
new file mode 100644
index 0000000000..75b7dea257
--- /dev/null
+++ b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_2_3bd66bf73386821c3837fe9da841fd1e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="DavidD"
+ avatar="http://cdn.libravatar.org/avatar/9e7cced3eede4bf75fb932bfdd4f8847"
+ subject="comment 2"
+ date="2022-08-17T19:03:19Z"
+ content="""
+I am really quite new to git annex (but am excited to familiarize myself with it!), so I don't know how to modify settings. I've tried this:
+$ git annex config --set annex.security.allowed-ip-addresses \"all\"
+git-annex: annex.security.allowed-ip-addresses is not a configuration setting that can be stored in the git-annex branch
+
+I am also having a difficult time parsing through the webpage to find the documentation on the allowed-url-schemes setting.
+"""]]
diff --git a/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_3_a5bd659bc98d6879b5175dc53915fdc8._comment b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_3_a5bd659bc98d6879b5175dc53915fdc8._comment
new file mode 100644
index 0000000000..cbe98cc19c
--- /dev/null
+++ b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_3_a5bd659bc98d6879b5175dc53915fdc8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 3"
+ date="2022-08-19T14:23:27Z"
+ content="""
+    git annex config --set annex.security.allowed-ip-addresses \"all\"
+
+-> 
+
+    git config annex.security.allowed-ip-addresses \"all\"
+
+It seems git-annex doesn't store this info in the git-annex branch. Probably because it's a security critical setting and you wouldn't want that to be set for you when cloning a public repo.
+"""]]
diff --git a/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_4_9ec91c1eb9fe119c52831a4ce5c44e25._comment b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_4_9ec91c1eb9fe119c52831a4ce5c44e25._comment
new file mode 100644
index 0000000000..faa8a68dff
--- /dev/null
+++ b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_4_9ec91c1eb9fe119c52831a4ce5c44e25._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-08-19T16:57:42Z"
+ content="""
+The documentation about these git config settings is in the
+main [[git-annex]] man page in the CONFIGURATION section.
+"""]]
diff --git a/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_5_bc7a29f8da461439cfb3cb270403181b._comment b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_5_bc7a29f8da461439cfb3cb270403181b._comment
new file mode 100644
index 0000000000..cb8158f965
--- /dev/null
+++ b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_5_bc7a29f8da461439cfb3cb270403181b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="DavidD"
+ avatar="http://cdn.libravatar.org/avatar/9e7cced3eede4bf75fb932bfdd4f8847"
+ subject="comment 5"
+ date="2022-08-19T19:42:55Z"
+ content="""
+Thank you both for the help, I have got this working!
+"""]]
diff --git a/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_6_4c8eb6c893ccd0a075500f4b9d4bccd9._comment b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_6_4c8eb6c893ccd0a075500f4b9d4bccd9._comment
new file mode 100644
index 0000000000..2ed02c9427
--- /dev/null
+++ b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_6_4c8eb6c893ccd0a075500f4b9d4bccd9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="DavidD"
+ avatar="http://cdn.libravatar.org/avatar/9e7cced3eede4bf75fb932bfdd4f8847"
+ subject="comment 6"
+ date="2022-08-19T20:07:49Z"
+ content="""
+However, I have just noticed that my user authentication gets stored in git annex (which I would like to avoid). I came across this comment in a tip from quite a number of years ago (https://git-annex.branchable.com/tips/using_the_web_as_a_special_remote/) which stated that \"If you want to protect the password from being exposed to anyone who gets a clone of the repository, just download manually, and then git annex add the file.\" Is this still the case?
+"""]]
diff --git a/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_7_12f6a1b93c36095f12e2a721311dee2a._comment b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_7_12f6a1b93c36095f12e2a721311dee2a._comment
new file mode 100644
index 0000000000..cf6884604f
--- /dev/null
+++ b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_7_12f6a1b93c36095f12e2a721311dee2a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="addurl and authentication"
+ date="2022-08-21T21:13:56Z"
+ content="""
+This comment from the same page might help: \"wget by default consults ~/.netrc where you could specify your account information (man netrc for more detail)\".
+"""]]
diff --git a/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_8_83228ff27a74b575b77f0e380e13cc8a._comment b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_8_83228ff27a74b575b77f0e380e13cc8a._comment
new file mode 100644
index 0000000000..c9ad530336
--- /dev/null
+++ b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_8_83228ff27a74b575b77f0e380e13cc8a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-08-22T15:52:19Z"
+ content="""
+If you pass an url to `git-annex addurl` that contains authentication data,
+it will be stored like any other url.
+"""]]
diff --git a/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_9_23ae2824d52b1f165b02294b0f89d704._comment b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_9_23ae2824d52b1f165b02294b0f89d704._comment
new file mode 100644
index 0000000000..96c2cd280b
--- /dev/null
+++ b/doc/forum/Use_addurl_with_a_file_on_an_HPC_cluster/comment_9_23ae2824d52b1f165b02294b0f89d704._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="DavidD"
+ avatar="http://cdn.libravatar.org/avatar/9e7cced3eede4bf75fb932bfdd4f8847"
+ subject="comment 9"
+ date="2022-08-22T17:54:19Z"
+ content="""
+I'd prefer not to have my credentials stored in plain text.
+
+When I run curl with the \"--user my_username\" key-value pair, it requests my password for the server. Does git-annex allow this authentication request from curl to be passed to the user and returned so that the password isn't stored anywhere on disk?
+"""]]
diff --git a/doc/forum/Use_assistant_to_sync_just_git_repos__63__.mdwn b/doc/forum/Use_assistant_to_sync_just_git_repos__63__.mdwn
new file mode 100644
index 0000000000..db4efbbe1b
--- /dev/null
+++ b/doc/forum/Use_assistant_to_sync_just_git_repos__63__.mdwn
@@ -0,0 +1,11 @@
+Hi,
+
+So lately I've been using git-annex to sync repos with only markdown files for Obsidian. Running `git annex sync --no-content` works well for this. But I have to remember when I've updated my Obsidian files on one system and make sure to sync to other repos.
+
+Could I use the assistant for this? For repos with annexed files, I've always preferred to manually manage my repos, so I've never used the assistant.
+
+Ideally, as I commit changes, it tries to sync them to other systems, and if those systems are offline (my MBP is closed for example and the ssh connection therefore times out), nothing explodes.
+
+Is this possible? Is it possible with a half dozen similar repos? Can a single agent do this or do I need to start one for each repo?
+
+Thanks!
diff --git a/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_1_d487c7097db97e316f086742e851b01f._comment b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_1_d487c7097db97e316f086742e851b01f._comment
new file mode 100644
index 0000000000..c6314b772c
--- /dev/null
+++ b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_1_d487c7097db97e316f086742e851b01f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-12-09T19:01:13Z"
+ content="""
+The assistant should do this, you'll have to set up the git repos yourself
+though, not using the webapp, since that only sets up git-annex repos.
+"""]]
diff --git a/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_2_f0bb3c9461a6b84ca034ebfff814dc77._comment b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_2_f0bb3c9461a6b84ca034ebfff814dc77._comment
new file mode 100644
index 0000000000..7464be9ea6
--- /dev/null
+++ b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_2_f0bb3c9461a6b84ca034ebfff814dc77._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jasonb@ab4484d9961a46440958fa1a528e0fc435599057"
+ nickname="jasonb"
+ avatar="http://cdn.libravatar.org/avatar/c7330f4da122c671b935fc1d58bb02b1"
+ subject="comment 2"
+ date="2021-12-12T02:49:28Z"
+ content="""
+Is it possible to configure it to sync only, and not auto-commit? Making a few changes to a markdown file in Obsidian, I see a commit each time I press CTRL-S; I tend to save often, so this creates quite a few commits.
+
+Thanks!
+"""]]
diff --git a/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_3_809b8a20c4de0da47e3f6bf794043744._comment b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_3_809b8a20c4de0da47e3f6bf794043744._comment
new file mode 100644
index 0000000000..6e38d66d58
--- /dev/null
+++ b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_3_809b8a20c4de0da47e3f6bf794043744._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-12-13T16:47:45Z"
+ content="""
+Set annex.autocommit to false.
+"""]]
diff --git a/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_4_fc4f3e2692c98e8168c8cbc696726f98._comment b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_4_fc4f3e2692c98e8168c8cbc696726f98._comment
new file mode 100644
index 0000000000..cdf9816a2a
--- /dev/null
+++ b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_4_fc4f3e2692c98e8168c8cbc696726f98._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jasonb@ab4484d9961a46440958fa1a528e0fc435599057"
+ nickname="jasonb"
+ avatar="http://cdn.libravatar.org/avatar/c7330f4da122c671b935fc1d58bb02b1"
+ subject="comment 4"
+ date="2021-12-16T23:41:55Z"
+ content="""
+That's fantastic. I'm working on an init script and a launchd configuration for OS X that I can post once it's working. It's more of an experiment, but someone else might find it useful to customize.
+
+Thanks.
+"""]]
diff --git a/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_5_e9d1f0a0b10a16079f06b63251806b0e._comment b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_5_e9d1f0a0b10a16079f06b63251806b0e._comment
new file mode 100644
index 0000000000..5706d386e7
--- /dev/null
+++ b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_5_e9d1f0a0b10a16079f06b63251806b0e._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="jasonb@ab4484d9961a46440958fa1a528e0fc435599057"
+ nickname="jasonb"
+ avatar="http://cdn.libravatar.org/avatar/c7330f4da122c671b935fc1d58bb02b1"
+ subject="comment 5"
+ date="2021-12-27T18:51:14Z"
+ content="""
+For anyone that finds this in the future, on OS X you can setup the agent to run at login with a launchd script similar to the following:
+
+```
+<?xml version=\"1.0\" encoding=\"UTF-8\"?>
+<!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">
+<plist version=\"1.0\">
+<dict>
+  <key>Label</key>
+  <string>com.example.gitannexassistant</string>
+
+  <key>ProgramArguments</key>
+  <array>
+    <string>/usr/local/bin/git-annex</string>
+    <string>assistant</string>
+    <string>--autostart</string>
+  </array>
+
+  <key>EnvironmentVariables</key>
+  <dict>
+    <key>PATH</key>
+    <string>/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin</string>
+  </dict>
+
+  <key>Nice</key>
+  <integer>1</integer>
+
+  <key>RunAtLoad</key>
+  <true/>
+
+  <key>StandardErrorPath</key>
+  <string>/tmp/gitannexassistant.err</string>
+
+  <key>StandardOutPath</key>
+  <string>/tmp/gitannexassistant.out</string>
+</dict>
+</plist>
+```
+
+You'll need to put it into:
+
+`~/Library/LaunchAgents/com.example.gitannexassistant.plist`
+
+And load it with `launchctl load ~/Library/LaunchAgents/com.example.gitannexassistant.plist`
+
+But don't forget to populate `~/.config/git-annex/autostart` with each repo, one per line.
+
+Enjoy!
+"""]]
diff --git a/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_6_0bd5e37ad9428eb38d2fdb84e58a0c2a._comment b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_6_0bd5e37ad9428eb38d2fdb84e58a0c2a._comment
new file mode 100644
index 0000000000..258757f5e5
--- /dev/null
+++ b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_6_0bd5e37ad9428eb38d2fdb84e58a0c2a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 6"
+ date="2022-03-05T18:47:10Z"
+ content="""
+So I tried `annex.autocommit=false` but, contrary to what the man page suggests and what Joey said, the that also disables syncing.  
+It's actually the very setting the assistant modifies when toggling *syncing* on a repo.
+
+How can I configure the assistant such that it only syncs commits I have added manually and does not create commits on its own?
+"""]]
diff --git a/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_7_4ba1e89d84fedfd6508f37717310893d._comment b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_7_4ba1e89d84fedfd6508f37717310893d._comment
new file mode 100644
index 0000000000..2bb5a8eb43
--- /dev/null
+++ b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_7_4ba1e89d84fedfd6508f37717310893d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-03-31T16:59:13Z"
+ content="""
+@Atemu would have been a good idea to file a bug about that.
+
+I think the assistant would probably eventually get around to pushing a
+commit that you made with annex.autocommit=false, but it did not promptly
+notice such commits and push them.
+
+I've made a small change that does make it promptly push commits that
+were made to the current branch.
+"""]]
diff --git a/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_8_d57eb0b4d41600a6709c03f00a9091be._comment b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_8_d57eb0b4d41600a6709c03f00a9091be._comment
new file mode 100644
index 0000000000..8eedc319ea
--- /dev/null
+++ b/doc/forum/Use_assistant_to_sync_just_git_repos__63__/comment_8_d57eb0b4d41600a6709c03f00a9091be._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 8"
+ date="2022-04-01T07:53:15Z"
+ content="""
+Oh! Didn't know that was a bug.
+
+Syncing works just fine with autocommit=false in my limited tests just now, thanks!
+"""]]
diff --git a/doc/forum/Use_case__58___Main_machine__44___portable_drive__44___backup_machine.mdwn b/doc/forum/Use_case__58___Main_machine__44___portable_drive__44___backup_machine.mdwn
new file mode 100644
index 0000000000..92885a01b6
--- /dev/null
+++ b/doc/forum/Use_case__58___Main_machine__44___portable_drive__44___backup_machine.mdwn
@@ -0,0 +1,26 @@
+Hello everybody, I need some setup advice.
+
+I want to set up a portability and data security (in the sense of redundancy) scenario for a user with some, but not exulting, tech skills.
+A directory that contains progressing work should be synced with incoming data and backed up.
+
+## Locations
+
+- Main machine (laptop), containing all software to process data and write result files
+- USB thumb drive, will occassionally receive additional data at the faculty (no root access/possibility to install annex or even git there)
+- Offline file server (ssh/sftp through wired lan), backing up all data
+
+## Goals
+
+- The laptop and USB drive should stay in sync in both directions; processed work must appear on the USB, data copied onto the USB must appear on the main machine (copies of files, not links).
+- All data should be backed up on the file server.
+- The user should not be required to stage/commit files from the command line, this should be handled automatically (annex assistant?)
+
+
+## Questions
+
+- This sounds a bit like the "nomad" scenario described, but not totally like it. Is git annex the proper tool for the job?
+- How do I set that scenario up? Especially, who is a remote of what and why, and how do I make sure I got a copy of every file in every location without doing it all manually?
+
+At the moment this is all done with a number of grsync sessions. It works, but if anything is done in the wrong order, current data is overwritten by older one (this could be resolved using git, but would require manual staging/commiting, what we want to avoid).
+
+Can you help me on that?
diff --git a/doc/forum/Use_case__58___Main_machine__44___portable_drive__44___backup_machine/comment_1_d2991b94eb067f0a6e47cd77f922411d._comment b/doc/forum/Use_case__58___Main_machine__44___portable_drive__44___backup_machine/comment_1_d2991b94eb067f0a6e47cd77f922411d._comment
new file mode 100644
index 0000000000..5f915607a5
--- /dev/null
+++ b/doc/forum/Use_case__58___Main_machine__44___portable_drive__44___backup_machine/comment_1_d2991b94eb067f0a6e47cd77f922411d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/hi7yosAfnufqtL0Mb123WhWS.Yel7LOeB6A-#1512c"
+ nickname="-"
+ subject="One more requirement"
+ date="2016-08-02T06:58:04Z"
+ content="""
+Oh, I forgot: data must be writable at least on the main machine, possibly on the thumb drive, too.
+"""]]
diff --git a/doc/forum/Use_case__58___Main_machine__44___portable_drive__44___backup_machine/comment_2_0b778710b23eab1413256e289f0aa180._comment b/doc/forum/Use_case__58___Main_machine__44___portable_drive__44___backup_machine/comment_2_0b778710b23eab1413256e289f0aa180._comment
new file mode 100644
index 0000000000..9a4530b41a
--- /dev/null
+++ b/doc/forum/Use_case__58___Main_machine__44___portable_drive__44___backup_machine/comment_2_0b778710b23eab1413256e289f0aa180._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-09-21T19:59:25Z"
+ content="""
+Use git-annex repositories on both the laptop and the thumb drive.
+
+You can start by setting up the repository on the thumb drive,
+and then git clone it to the laptop.
+
+Use `git annex direct` to make them use direct mode, so that
+files can be edited.
+
+You can run the git-annex assistant in the repository on the laptop
+(~/annex is the usual place for such a repository). This way
+changes to files there will automatically be committed to git.
+
+There's not currently a good way to have the assistant also commit
+any files that were added to the thumb drive, or merge in changes
+from the laptop to the thumb drive. Running the assistant in the repository
+on the thumb drive would take care of both, but fails when the thumb
+drive gets unplugged.
+
+What you can do is write a simple shell script to sync up the thumb drive.
+Something like this:
+
+	#!/bin/sh
+	set -e
+	cd /media/thumbdrive
+	git annex add
+	git annex sync -m "syncing thumb drive"
+"""]]
diff --git a/doc/forum/Use_case__58___backup_on_multiple_USB_Drives.mdwn b/doc/forum/Use_case__58___backup_on_multiple_USB_Drives.mdwn
new file mode 100644
index 0000000000..b70009e2a6
--- /dev/null
+++ b/doc/forum/Use_case__58___backup_on_multiple_USB_Drives.mdwn
@@ -0,0 +1,19 @@
+Hello, I have a question about my tipical use case.
+
+I have a laptop with limited ssd space, 3 USB disks and I want to keep them in sync without using my laptop space.
+
+I specify:
+I want
+/media/disk1/Backup
+/media/disk2/Backup
+/media/disk3/Backup
+to be identical and synced, I can connect all the 3 drives to my laptop when I want to sync.
+Usually I add a batch of photos from the pc to one of the disk and git annex sync the files for me.
+
+BUT...
+
+In my future-proof environment I really prefer to have my files stored in "direct" mode in all of the 3 repositories, is this possible?
+So if something bad will happen I can just plug the disk in a brand new laptop and access my backup.
+
+How can I achieve this result?
+Thank you for your help
diff --git a/doc/forum/Use_case__58___backup_on_multiple_USB_Drives/comment_1_5d45ee72f91af9ec8384b178af77bc2d._comment b/doc/forum/Use_case__58___backup_on_multiple_USB_Drives/comment_1_5d45ee72f91af9ec8384b178af77bc2d._comment
new file mode 100644
index 0000000000..63cf5695fb
--- /dev/null
+++ b/doc/forum/Use_case__58___backup_on_multiple_USB_Drives/comment_1_5d45ee72f91af9ec8384b178af77bc2d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2019-02-01T01:51:16Z"
+ content="""
+Are you using the assistant or command-line?
+"""]]
diff --git a/doc/forum/Use_case__58___backup_on_multiple_USB_Drives/comment_2_502fedae83c3b6e0b32897ce4c1a8317._comment b/doc/forum/Use_case__58___backup_on_multiple_USB_Drives/comment_2_502fedae83c3b6e0b32897ce4c1a8317._comment
new file mode 100644
index 0000000000..87912e32ed
--- /dev/null
+++ b/doc/forum/Use_case__58___backup_on_multiple_USB_Drives/comment_2_502fedae83c3b6e0b32897ce4c1a8317._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-02-07T20:12:47Z"
+ content="""
+You don't need direct mode for this at all and there's no benefit to using
+it in most cases.
+
+You can just use regular git clones on the backup disks, and sync to them.
+Running "git annex merge" in the clone on the backup disk at any time will
+advance it to the most recently synced version with all the files in it,
+and you can do that when you plug it into the new laptop.
+"""]]
diff --git a/doc/forum/Use_case_for_addurl.mdwn b/doc/forum/Use_case_for_addurl.mdwn
new file mode 100644
index 0000000000..ee18107bd3
--- /dev/null
+++ b/doc/forum/Use_case_for_addurl.mdwn
@@ -0,0 +1,8 @@
+Hi,
+
+
+question. What is exactly the use-case for addurl. To add unique files as if they where never changing resources?
+
+There is a --relaxed flag to enable some leniency in redownloading the file it seems. But how would one go about updating a file from the web, drop it first?
+Or do I have to add pseudo queries or hashes to the URLs to keep them unique and manage any versioning that way perhaps?
+
diff --git a/doc/forum/Use_case_for_addurl/comment_1_2205b1857158cca4f6e2225c53bec1d5._comment b/doc/forum/Use_case_for_addurl/comment_1_2205b1857158cca4f6e2225c53bec1d5._comment
new file mode 100644
index 0000000000..608370c58c
--- /dev/null
+++ b/doc/forum/Use_case_for_addurl/comment_1_2205b1857158cca4f6e2225c53bec1d5._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-11-10T18:59:13Z"
+ content="""
+The use case is to be able to `git annex addurl` in one repository
+and `git annex get` in another checkout, without needing to remember 
+the url yourself. Or to use `git annex whereis` to look up the url
+associated with a file.
+
+When --relaxed is used, you're telling git-annex you want to treat
+the current and future content of the url as close enough to the same
+as to not matter. I wouldn't use it if I expected the content of an url to 
+change significantly, and git-annex is not able to help with manageing such
+differences.
+"""]]
diff --git a/doc/forum/Use_case_with_syncing_only_a_subset_possible__63__.mdwn b/doc/forum/Use_case_with_syncing_only_a_subset_possible__63__.mdwn
new file mode 100644
index 0000000000..0d102b0d40
--- /dev/null
+++ b/doc/forum/Use_case_with_syncing_only_a_subset_possible__63__.mdwn
@@ -0,0 +1,13 @@
+I'm trying to figure out if git-annex can be used for the following use case:
+
+- 2 repos in direct mode A and B
+- A is on a local filesystem, B could be a NFS mountpoint or ssh
+- B contains a number of toplevel directories, A contains a subset of those
+- For the subset in A all changes in those directories that happen on A or B should be synced automatically between both repos, including file removals.
+- A can decide to not carry a toplevel dir any more, but it must still exist in B.
+- A can copy new toplevel dirs from B and those should be synced from then on.
+
+I've been looking at the docs and played with two test repos, but I cannot seem to make the above work. To me it looks like I would need a possibility include/exclude paths from syncing via a regex.
+
+Thanks,
+Felix
diff --git a/doc/forum/Use_case_with_syncing_only_a_subset_possible__63__/comment_1_a0a272a0931b27e5c94b93e42656b62c._comment b/doc/forum/Use_case_with_syncing_only_a_subset_possible__63__/comment_1_a0a272a0931b27e5c94b93e42656b62c._comment
new file mode 100644
index 0000000000..3e930b5424
--- /dev/null
+++ b/doc/forum/Use_case_with_syncing_only_a_subset_possible__63__/comment_1_a0a272a0931b27e5c94b93e42656b62c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.51"
+ subject="comment 1"
+ date="2013-09-12T20:39:51Z"
+ content="""
+I guess you might be using the git-annex assistant. If you were just using git-annex at the command line, you could simply only run `git annex get` on the files or directories you wanted to get.
+
+You can control which directories the git-annex assistant downloads/uploads files for using [[preferred_content]] expressions. Or the easy solution is to use the webapp to put the repository into \"manual mode\" and then manually run `git annex get` as described above to get just the files you want. (And `git annex copy --to remote` to share new files you make.)
+"""]]
diff --git a/doc/forum/Use_existing_S3_bucket.mdwn b/doc/forum/Use_existing_S3_bucket.mdwn
new file mode 100644
index 0000000000..5f215b5cb8
--- /dev/null
+++ b/doc/forum/Use_existing_S3_bucket.mdwn
@@ -0,0 +1,8 @@
+Hello,
+
+is it possible to use an existing AWS S3 bucket (one I created in the AWS web interface) when executing initremote? I tried but git annex failed with s3ErrorCode = "BucketAlreadyOwnedByYou".
+
+Background is that http://git-annex.branchable.com/special_remotes/S3/ only mentions EU for datacenter. But there are three possible EU datacenters now. So I created a bucket in EU (Frankfurt) and tried to use this one with bucket=mybucket
+
+Best Thanks!
+
diff --git a/doc/forum/Use_existing_S3_bucket/comment_1_ed0ead0b09ddbe52d42150a281d84f5c._comment b/doc/forum/Use_existing_S3_bucket/comment_1_ed0ead0b09ddbe52d42150a281d84f5c._comment
new file mode 100644
index 0000000000..87c4c1345c
--- /dev/null
+++ b/doc/forum/Use_existing_S3_bucket/comment_1_ed0ead0b09ddbe52d42150a281d84f5c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-13T18:01:40Z"
+ content="""
+It's not supposed to fail when the bucket already exists. There is an
+explicit check to see whether the bucket exists in current versions.
+
+Unfortunately, git-annex can't support the Frankfurt datacenter,
+until this API problem gets fixed <https://github.com/aristidb/aws/pull/199>
+
+In my tests, it doesn't fail that way when the bucket already exists.
+I didn't create the bucket in Frankfurt though, and it could be
+that due to the API problem it fails to notice that the bucket in Frankfurt
+already exists.
+"""]]
diff --git a/doc/forum/Use_existing_S3_bucket/comment_2_6b108846fca4a514d507f56d1052fdde._comment b/doc/forum/Use_existing_S3_bucket/comment_2_6b108846fca4a514d507f56d1052fdde._comment
new file mode 100644
index 0000000000..5e9fa1fd51
--- /dev/null
+++ b/doc/forum/Use_existing_S3_bucket/comment_2_6b108846fca4a514d507f56d1052fdde._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://xgm.de/oid/"
+ nickname="Horus"
+ avatar="http://cdn.libravatar.org/avatar/4c5c0e290374d76c713f482e41f60a3cbee0fa64bb94c6da94e5a61a50824811"
+ subject="comment 2"
+ date="2017-02-14T18:03:27Z"
+ content="""
+Ok, I can confirm it works with an existing bucket in Europe/Ireland.
+
+Looks like I shouldn't count on being able to use Frankfurt anytime soon, since this PR has not been worked on since april last year.
+
+Best Thanks!
+"""]]
diff --git a/doc/forum/Use_local_files_instead_of_re-downloading_from_S3_remote.mdwn b/doc/forum/Use_local_files_instead_of_re-downloading_from_S3_remote.mdwn
new file mode 100644
index 0000000000..67e7971d2c
--- /dev/null
+++ b/doc/forum/Use_local_files_instead_of_re-downloading_from_S3_remote.mdwn
@@ -0,0 +1,3 @@
+I have a question on setting up a new repo. Is it possible to initialize a new repo using files which are already local on say my laptop, instead of downloading them from a S3 remote repository? Sorry if this is unclear. But I'm trying to make use of the files that are local on my laptop so I don's have to go through the ordeal of downloading them from S3.
+
+I should also mention that I don't have a complete set of all the files locally on the laptop vs. what's already in the S3 repository.
diff --git a/doc/forum/Use_local_files_instead_of_re-downloading_from_S3_remote/comment_1_cfb6021a36eee087705967a69967f327._comment b/doc/forum/Use_local_files_instead_of_re-downloading_from_S3_remote/comment_1_cfb6021a36eee087705967a69967f327._comment
new file mode 100644
index 0000000000..0d1f74e833
--- /dev/null
+++ b/doc/forum/Use_local_files_instead_of_re-downloading_from_S3_remote/comment_1_cfb6021a36eee087705967a69967f327._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 1"
+ date="2013-05-27T18:13:43Z"
+ content="""
+Hi,
+
+just copy the local File into the annex again, replacing the symlinks. If you have the assistant running, it should re-add the files automatically, otherwise you can 'git annex add' them manually. 
+"""]]
diff --git a/doc/forum/Use_local_files_instead_of_re-downloading_from_S3_remote/comment_2_7268b194ba72331858bc3274996b780e._comment b/doc/forum/Use_local_files_instead_of_re-downloading_from_S3_remote/comment_2_7268b194ba72331858bc3274996b780e._comment
new file mode 100644
index 0000000000..b066c85db9
--- /dev/null
+++ b/doc/forum/Use_local_files_instead_of_re-downloading_from_S3_remote/comment_2_7268b194ba72331858bc3274996b780e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-05-27T18:47:17Z"
+ content="""
+You can also use `git annex reinject` to feed in contents of specific files, without needing to directly touch the files in the repository.
+
+Or, you can check all the local files into a temporary directory. Either the assistant or a manual `git annex add` will 
+notice if these files have the same content as files already in the repository. The files will then be available in two locations, the temp directory and wherever it was checked into your repository before. You can then delete the temp directory.
+"""]]
diff --git a/doc/forum/Use_on_large_media_collection_without_modifying_it.mdwn b/doc/forum/Use_on_large_media_collection_without_modifying_it.mdwn
new file mode 100644
index 0000000000..4c2d10f6f9
--- /dev/null
+++ b/doc/forum/Use_on_large_media_collection_without_modifying_it.mdwn
@@ -0,0 +1,34 @@
+Hi everyone,
+
+I want to lay out a couple of use cases here.
+
+I have several large (1 TB +) media collections.  Some are often mounted read-only.  Others are very sensitive to changes -- I definitely don't want to risk anything that might munge timestamps, etc.  So my requirements are:
+
+1. Must not modify the files in the existing collection in any way. No changing timestamps, no converting them to hard or sym links, etc.
+2. Must not store an additional copy of the data locally (I don't have space for that)
+3. Must be able to handle the data store being read-only mounted (.git can be read-write)
+
+I want to use this for, in order of importance:
+
+1. Archival to external USB drives.  Currently I do this with rsync and it's a real mess figuring out what's where and what to do when a drive fills up.
+2. Being able to easily selectively copy some of the files to a laptop or Linux-using tablet for offline viewing
+3. Being able to queue up files to add from a laptop/tablet
+
+I'm not worried about the .git directory itself; I can bind-mount the existing store to be a subdirectory under a git-annex repo, so that would be fine.
+
+So here's what I've looked into so far.  All of these are run with `git annex adjust --unlock` (or the assistant, which does the same thing):
+
+- A directory remote with importtree=yes would work well for use case #1.  However, since the rsync backend doesn't support importtree, it would be challenging for #2 (I guess I could make it work via sshfs, but that gets a bit nasty)
+- I tried bind-mounting the existing data under a git-annex repo to use that as the source.  This does work; however, presumably because it can't hard link the files into .git/annex, it results in doubling the storage space requirements for the data.  That's not usable for me.
+- I thought maybe a transport repo would help.  So I could have, basically, `source->transport<->laptop` and `source->transport->archive`.  The problem here is that git-annex can't copy directly from source to laptop or archive in this scenario without duplicating the data in transport.  So I still can't just use get from the laptop to get things unless I use 2x the space, which again, I don't want to do.
+- I thought about maybe adding git-annex directly to an existing directory.  That risks changing things about it (since it is necessarily read-write to git-annex).  I'm not really comfortable with that yet.
+
+Incidentally, I mentioned timestamps and didn't say how I'll preserve them for the archive drives.  I can use mtree from Debian's mtree-netbsd package and do something like this on the source directory:
+
+`mtree -c -R nlink,uid,gid,mode  -p /PATH/TO/REPO -X <(echo './.git') > /tmp/spec`
+
+And on the destination, restore the timestamps with:
+
+`mtree -t -U -e < /tmp/spec`
+
+I imagine some clever hooks would let me do this automatically, but I don't really feel the need for that.  I think this is easier, for me, than the discussion at [[todo/does_not_preserve_timestamps]].
diff --git a/doc/forum/Use_on_large_media_collection_without_modifying_it/comment_1_76307d95cf46992fbc5f084f9c056edc._comment b/doc/forum/Use_on_large_media_collection_without_modifying_it/comment_1_76307d95cf46992fbc5f084f9c056edc._comment
new file mode 100644
index 0000000000..c7b1535780
--- /dev/null
+++ b/doc/forum/Use_on_large_media_collection_without_modifying_it/comment_1_76307d95cf46992fbc5f084f9c056edc._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2022-09-03T21:32:29Z"
+ content="""
+First of all you really want to look into/migrate to reflink-capable filesystems like XFS or btrfs. 
+
+I don't know why you'd need to use the rsync special-remote for case #2. You create git-annex repos on your usb drive,
+add the existing collection as a directory special-remote with `--import-tree` and import everything. Then you clone the
+repo to your laptop and can `git annex sync/get/copy` from the usb drive however you like. I think you can even `git annex enableremote` the
+import special-remote on your laptop, and then git-annex will get files directly from it. Heck, you could even `git annex import --no-content`
+and only have the file metadata imported, but none of the content actually stored in git-annex and then you can selectively `git annex get` files directly from the special-remote.
+
+Also, you may want to set `git annex config --set annex.dotfiles true` on each of you repos. All of these options are documented in the [[git-annex]] manpage (also look at the [[git-annex-config]] manpage).
+"""]]
diff --git a/doc/forum/Use_on_large_media_collection_without_modifying_it/comment_2_b89b598844b0709a5b6709d0fb2ef60c._comment b/doc/forum/Use_on_large_media_collection_without_modifying_it/comment_2_b89b598844b0709a5b6709d0fb2ef60c._comment
new file mode 100644
index 0000000000..57dff1e673
--- /dev/null
+++ b/doc/forum/Use_on_large_media_collection_without_modifying_it/comment_2_b89b598844b0709a5b6709d0fb2ef60c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 2"
+ date="2022-09-03T22:45:42Z"
+ content="""
+Thank you for these thoughts!
+
+I should have mentioned that I intend the USB drives to often live offsite, so they would be disconnected.  You are quite correct, though, that if they are onsite I could think of them as the sort of \"hub\" repository and do everything from them like that.
+
+Doing the enableremote for the special directory remote on the laptop does require it to be mounted as a filesystem there, hence my mention of sshfs.  That can work but is a bit clunky.
+"""]]
diff --git a/doc/forum/Use_on_large_media_collection_without_modifying_it/comment_3_2d707dc516dad666fb2a647f65fcedcf._comment b/doc/forum/Use_on_large_media_collection_without_modifying_it/comment_3_2d707dc516dad666fb2a647f65fcedcf._comment
new file mode 100644
index 0000000000..3f9d251c58
--- /dev/null
+++ b/doc/forum/Use_on_large_media_collection_without_modifying_it/comment_3_2d707dc516dad666fb2a647f65fcedcf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 3"
+ date="2022-09-03T23:26:27Z"
+ content="""
+Forgot to mention - I'm on ZFS, which while it is a CoW filesystem, doesn't support cp --reflink.  For various reasons, a migration to ZFS or btrfs isn't very practical for me.
+"""]]
diff --git a/doc/forum/Use_on_large_media_collection_without_modifying_it/comment_4_4529364f2919bd05f53da94cf8ba4268._comment b/doc/forum/Use_on_large_media_collection_without_modifying_it/comment_4_4529364f2919bd05f53da94cf8ba4268._comment
new file mode 100644
index 0000000000..ad42a4de31
--- /dev/null
+++ b/doc/forum/Use_on_large_media_collection_without_modifying_it/comment_4_4529364f2919bd05f53da94cf8ba4268._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="unqueued"
+ avatar="http://cdn.libravatar.org/avatar/3bcbe0c9e9825637ad7efa70f458640d"
+ subject="comment 4"
+ date="2023-11-05T21:32:17Z"
+ content="""
+Just putting this out there, but if you are on ZFS or BTRFS, you can just duplicate the subvolume/dataset, remove what you want, and send it. It will by default verify your data integrity, and it is often faster.
+
+On BTRFS, it is easy to `btrfs sub create send.RW; cp --reflink=always .git/annex/objects send.RW; btrfs sub snap -r send.RW send.RO; btrfs sub del send.RW`
+
+Then, on the target, I can reflink copy into the target repo's .git/annex/objects, and the `git annex fsck --all --fast`, since the send operation verified the integrity.
+
+
+Sometimes, if the target repo does not exist, I can take a snapshot of an entire repo, and then enter it, then re-init it with the target uuid, force drop what I don't want, and then send it. If you're dealing with hundreds of thousands of files, it can be more practical to do that.
+
+If you want to verify the integrity of an annexed file on ZFS or BTRFS, all you have to do is read it, and let the filesystem verify the checksums for you.
+
+If you want a nice progress display, you can just do `pv myfile > /dev/null`
+
+I considered making a git-annex-scrub script that would check if the underlying fs supports integrity verification, then just read the file and update the log.
+
+BTRFS uses hardware accelerated crc32, which is fine for bitrot, but it is not secure from intentional tampering.
+"""]]
diff --git a/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__.mdwn b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__.mdwn
new file mode 100644
index 0000000000..1ef6345bb9
--- /dev/null
+++ b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__.mdwn
@@ -0,0 +1,7 @@
+Hi.
+
+I couldn't find a way to pass the passphrase, required to open the gpg keypair for an encrypted special remote, to "git annex sync --content".
+I need this for my backup script. Is it possible to use an environment variable or a passphrase file?
+
+Best regards,
+sfowijowa
diff --git a/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_1_b177f16daeab7f02022f18154cfa1c3c._comment b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_1_b177f16daeab7f02022f18154cfa1c3c._comment
new file mode 100644
index 0000000000..b5dc5b4ebf
--- /dev/null
+++ b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_1_b177f16daeab7f02022f18154cfa1c3c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-15T15:55:31Z"
+ content="""
+Any method that can be used to provide a passphrase to gpg should work. 
+
+For example, gpg-agent can cache the passphrase.
+
+Or, you could use gpg's passphrase-file option to make it read the
+passphrase from a file. This could be put in ~/.gnupg/gpg.conf.
+Although this configuration is probably no more secure than just removing
+the passphrase from the gpg key..
+"""]]
diff --git a/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_2_6d88e5a48de78e6add0e4e4b6ebc3f1b._comment b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_2_6d88e5a48de78e6add0e4e4b6ebc3f1b._comment
new file mode 100644
index 0000000000..99b64002ff
--- /dev/null
+++ b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_2_6d88e5a48de78e6add0e4e4b6ebc3f1b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="sfowijowa"
+ subject="comment 2"
+ date="2015-07-17T18:20:06Z"
+ content="""
+Hi, I am using the \"--passphrase-file\" option outside git-annex to sign the files that have to be backed up:
+\"gpg --batch --passphrase-file /home/user/.gnupg/pass.txt --no-tty --yes --detach-sign /tmp/root.tar.gz\" Unfortunately, I couldn't find a way to pass this option to gpg with git-annex. In duplicity, for example, you can pass gpg options with \"dupclitiy --gpg-options '--passphrase-file /home/user/.gnupg/pass.txt'\" Best regards
+"""]]
diff --git a/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_3_a2eb4244788eebba5167cd32a73ff204._comment b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_3_a2eb4244788eebba5167cd32a73ff204._comment
new file mode 100644
index 0000000000..96a14aaba8
--- /dev/null
+++ b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_3_a2eb4244788eebba5167cd32a73ff204._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-20T16:30:10Z"
+ content="""
+I gave you one way in my previous comment; you can put any gpg option in
+~/.gnupg/gpg.conf, just leave off the leading dashes.
+
+Another way is the annex.gnupg-options git configuration setting,
+see git-annex's man page.
+"""]]
diff --git a/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__.mdwn b/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__.mdwn
new file mode 100644
index 0000000000..d33fda6008
--- /dev/null
+++ b/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__.mdwn
@@ -0,0 +1 @@
+On BTRFS it is possible to use [reflinks / clones](https://en.wikipedia.org/wiki/Btrfs#Cloning). This is the equivalent of hardlinks except that when the file is modified, a copy is performed (copy on write). Perhaps git-annex could detect the availability of this feature and use it in case it is available (and the repository and the file are in the same filesystem).
diff --git a/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_1_85806316ed28d7a891f04fab4027141b._comment b/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_1_85806316ed28d7a891f04fab4027141b._comment
new file mode 100644
index 0000000000..b175204e55
--- /dev/null
+++ b/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_1_85806316ed28d7a891f04fab4027141b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://thkoch2001.myopenid.com/"
+ nickname="thkoch"
+ subject="It would also be nice, if git-annex would use btrfs reflinks on unlock"
+ date="2013-08-24T12:46:40Z"
+ content="""
+I don't know whether git-annex already does use btrfs reflinks, but I suspect, that I double the size of my git-annex repo folder on disk when I unlink all files.
+"""]]
diff --git a/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_2_ecb411a2c4d67917b734a90bd460d44b._comment b/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_2_ecb411a2c4d67917b734a90bd460d44b._comment
new file mode 100644
index 0000000000..a4ade57926
--- /dev/null
+++ b/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_2_ecb411a2c4d67917b734a90bd460d44b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 2"
+ date="2013-08-24T15:54:02Z"
+ content="""
+git-annex has always used cp --reflink=auto, including when it cp's the file in `git annex unlock`.
+
+You can verify this with --debug.
+"""]]
diff --git a/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_3_83dc719be1883d5369d27a787a5b5705._comment b/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_3_83dc719be1883d5369d27a787a5b5705._comment
new file mode 100644
index 0000000000..f5c132449d
--- /dev/null
+++ b/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_3_83dc719be1883d5369d27a787a5b5705._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="sylvain.joyeux@5c33d7abae4df5f574fc4b8791d02054d245bf62"
+ nickname="sylvain.joyeux"
+ subject="not on the directory special remote"
+ date="2016-01-20T11:39:35Z"
+ content="""
+I'm trying to share videos across my (many) presentations using annex. My idea was to have a local annex directory remote that is used by all the presentation gits.
+
+However, it seems that copying from a directory special remote does not use reflink. Is that right ?
+
+Thanks for git-annex !
+
+Sylvain
+"""]]
diff --git a/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_4_bbe2e6359f7b754bde9d61b5a8d5e672._comment b/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_4_bbe2e6359f7b754bde9d61b5a8d5e672._comment
new file mode 100644
index 0000000000..a269048833
--- /dev/null
+++ b/doc/forum/Use_reflinks_on_BTRFS_instead_of_symlinks___63__/comment_4_bbe2e6359f7b754bde9d61b5a8d5e672._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-01-20T18:43:13Z"
+ content="""
+It's true; the directory special remote copies the files in and out. The
+main reason this is done is to get a useful progress display, which using
+`cp` wouldn't provide. Of course, if cp were using reflinks, it'd be so
+fast that a progress display would not be necessary! But often, reflinks
+cannot be used.
+
+It might be a good enhancement for the directory special remote to be
+configurable to use cp --reflink, or even autodetect if reflinks can be
+used (although I don't know how it would detect that).
+
+OTOH, you might be better off using `git clone --shared`. Recent versions
+of git-annex can hard-link objects between shared clones.
+"""]]
diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too.mdwn b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too.mdwn
new file mode 100644
index 0000000000..37dd1bc24c
--- /dev/null
+++ b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too.mdwn
@@ -0,0 +1,11 @@
+I use git everywhere i can to manage versions, but I have a usecase that is probably very common, but i could not see in the howto lists.
+
+I have a shared fileserver(FS) that is managed by others and is full of the equivalent of binary blobs (media, word docs etc). Binary blobs of course are something that git cannot normally do anything meaningful with. That is diff/patch for managing the evolution of any given file. Binary blobs have a different lifecycle of course, and i see annex as the solution for managing that.
+
+The remote FS is being used as an SMB server to windows and linux clients. The FS has other capabilities that i can use other than SMB mount including rsync and ssh. As it is running samba it also uses symlinks underneath the the SMB to manage shared folders, which can be seen when mounted in unix mode. This means the FS landscape is different when using samba as compared to rsync and ssh, as some paths may be symlinked in. The symlinks should not effect this use case, but I mention them because I don't know how annex would manage this.
+
+The basic scenario is that i have a set of project files and folders in tree on the remote FS. I want to use git to pull these binary files from the FS to edit locally while also seein/capturing changes made to files in that tree by other people not using git. Then i want to push my edits back, without effecting the files that i have no responsibility for (but have write access to). 
+
+Think a team of people with various technical capabilities working on changing binary blobs in this remote directory tree. I want to manage my interactions with portions of that remote FS tree via git (annex) with a local mirror (preferably actually containing only the files i care about) so that i can manipulate them locally, clone to other work machines and generally play about with and then push back while watching the whole tree and capturing changes others make (during sync/merge/push/pull?). Because i do not manage it, or own the contents, i also need to be able to maintain the some of the permissions (guid/uid) of the remote and untouched files. 
+
+Can you give me any suggestions?
diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_1_30205c1ba18e5dca2314f593e1a0e236._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_1_30205c1ba18e5dca2314f593e1a0e236._comment
new file mode 100644
index 0000000000..7f170975a6
--- /dev/null
+++ b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_1_30205c1ba18e5dca2314f593e1a0e236._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkI9pq1WH6MWeExXHVQVEsniT3DdFv4AB8"
+ nickname="Roberto"
+ subject="My usecase too"
+ date="2014-01-12T23:43:18Z"
+ content="""
+Just wanted to thank your for describing my very same use case. Unfortunately I still haven't wrapped my head around git annex to accommodate such scenario.
+"""]]
diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_2_f8df728de28218a6b060ae9f08adac79._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_2_f8df728de28218a6b060ae9f08adac79._comment
new file mode 100644
index 0000000000..576007b62b
--- /dev/null
+++ b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_2_f8df728de28218a6b060ae9f08adac79._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~timo-linux"
+ nickname="Tim O'Callaghan"
+ subject="Would GIT_DIR or GIT_WORK_TREE be valid for this?"
+ date="2014-01-14T07:29:31Z"
+ content="""
+For example if i mounted this filesystem and used annex and GIT_ env variables to watch it? Presumably in direct mode, because i don't want to remove the source files, but i do want to manage my source files. 
+"""]]
diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_3_ba438b3a371261ee841665f1ae57eba2._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_3_ba438b3a371261ee841665f1ae57eba2._comment
new file mode 100644
index 0000000000..9184495b51
--- /dev/null
+++ b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_3_ba438b3a371261ee841665f1ae57eba2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~timo-linux"
+ nickname="Tim O'Callaghan"
+ subject="What about annex mirror? "
+ date="2014-01-14T08:00:42Z"
+ content="""
+I cannot find any documentation on it, is it appropriate for this situation? 
+"""]]
diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_4_9f72e6c7c14a77330297526aef260762._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_4_9f72e6c7c14a77330297526aef260762._comment
new file mode 100644
index 0000000000..d43019ce04
--- /dev/null
+++ b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_4_9f72e6c7c14a77330297526aef260762._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://cstork.org/"
+ nickname="Chris Stork"
+ subject="Many peoples' use case"
+ date="2014-01-14T09:39:05Z"
+ content="""
+Well, a description of this use case is posted every few weeks in different forms. Here are two, including my own: ;-)
+
+* [[Using git annex with a SMB  47  FTP TV NAS with preconfigured dirs]]
+* [[Direct special remotes]]
+"""]]
diff --git a/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment
new file mode 100644
index 0000000000..321fa9c53f
--- /dev/null
+++ b/doc/forum/Usecase__58___Tree_of_files_on_a_remote_SMB_server_that_i_need_to_leave_there__44____while_also_cloning_and_syncing_too/comment_5_a06e8c9b4e30c1cd6cbed40d2db50abc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~timo-linux"
+ nickname="Tim O'Callaghan"
+ subject="Still have not found a reasonable solution for this myself."
+ date="2014-02-03T14:34:14Z"
+ content="""
+And it seems i'm not the only one, So I'd like to bump the topic. 
+
+Can someone at least tell me if it is possible with annex/annex-gui or not? 
+"""]]
diff --git a/doc/forum/User_name_with_whitespace_not_working_with___34____40__+__41___Local_computer__34__.mdwn b/doc/forum/User_name_with_whitespace_not_working_with___34____40__+__41___Local_computer__34__.mdwn
new file mode 100644
index 0000000000..441baebcfd
--- /dev/null
+++ b/doc/forum/User_name_with_whitespace_not_working_with___34____40__+__41___Local_computer__34__.mdwn
@@ -0,0 +1,9 @@
+When using the "(+) Local computer" feature, I get the error message
+
+Internal Server Error: wrong number of words in ssh public key
+
+This is due to the use of pattern matching in this line https://github.com/RichiH/git-annex/blob/master/Assistant/Ssh.hs#L73 and because the key comment contains spaces. And of course it cotains spaces, on windows people often use their full name as user name. I will fill a bug later.
+
+My question is, how can I work around this bug? The client with this public key is running windows. How can I influence or at least see how this public key looks like? I could not find any documentation on this.
+
+[[!tag forumbug]] [[bugs/done]]
diff --git a/doc/forum/User_name_with_whitespace_not_working_with___34____40__+__41___Local_computer__34__/comment_1_f803fc1fb340587fc4b55640fbae6604._comment b/doc/forum/User_name_with_whitespace_not_working_with___34____40__+__41___Local_computer__34__/comment_1_f803fc1fb340587fc4b55640fbae6604._comment
new file mode 100644
index 0000000000..e0f28a20d8
--- /dev/null
+++ b/doc/forum/User_name_with_whitespace_not_working_with___34____40__+__41___Local_computer__34__/comment_1_f803fc1fb340587fc4b55640fbae6604._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-04T18:04:51Z"
+ content="""
+Please report bugs at [[bugs]], not in the forum.
+
+I've fixed this one.
+"""]]
diff --git a/doc/forum/Using_Git-Annex___40__Assistant__41___to_manage_photos_with_Shotwell.mdwn b/doc/forum/Using_Git-Annex___40__Assistant__41___to_manage_photos_with_Shotwell.mdwn
new file mode 100644
index 0000000000..d3e2cef009
--- /dev/null
+++ b/doc/forum/Using_Git-Annex___40__Assistant__41___to_manage_photos_with_Shotwell.mdwn
@@ -0,0 +1,13 @@
+Hello,
+
+I'm very excited about Git Annex and Git Annex Assistant.
+
+One big issue that I have is that I currently have all of my photos (70-80GB) on a HTPC because it has a large hard drive. I have a decent laptop/screen set-up where I would prefer to manage the photos, but the hard drive in there is a small SSD. 
+
+I use Shotwell to manage my photos (currently on the HTPC). I would be happy to keep things simple and only access them on the laptop. I have 100GB of box.com storage (and another 100GB of Mega.co.nz storage, but I don't think that is supported by GAA yet).
+
+Ideally, what I would like is for a cache of, say, 10GB of my recently-accessed photos to live on my laptop, with the remaining 70GB living on both my HTPC and box.com. If I ever needed the underlying files for non-cached files (say if I was trying to view full-quality versions of them or send them to someone), it could try to pull these from my HTPC over the local network or, if I was "on the road", box.com. As I understand it, Shotwell has its own database and a set of thumbnails etc that you can use to manage and browse your photos while very rarely accessing the underlying photos.
+
+Is this possible with the existing GAA/Shotwell, or does one or the other require changes? Could I solve the problem by using something like the sharebox Git-Annex FUSE filesystem, so that Shotwell thinks that the files are local, but runs away and grabs them if they are remote?
+
+I would appreciate any thoughts that anyone has - particularly if anyone has made this work. 
diff --git a/doc/forum/Using_Git-Annex___40__Assistant__41___to_manage_photos_with_Shotwell/comment_1_5e8d54daf6b7ff357619ac65fe39a2d7._comment b/doc/forum/Using_Git-Annex___40__Assistant__41___to_manage_photos_with_Shotwell/comment_1_5e8d54daf6b7ff357619ac65fe39a2d7._comment
new file mode 100644
index 0000000000..7ec8ac2fc0
--- /dev/null
+++ b/doc/forum/Using_Git-Annex___40__Assistant__41___to_manage_photos_with_Shotwell/comment_1_5e8d54daf6b7ff357619ac65fe39a2d7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-27T19:09:50Z"
+ content="""
+Mega can be used via [[/tips/megaannex]]. I don't have personal experience with it, but if you set up a repository manually using that, the assistant can use that repository just as it uses any other repository.
+
+git-annex at the command line is great for small local repositories that pull files from various larger remotes as needed. You just run \"git annex get\" when you want a file and \"git annex drop\" when you want to free disk space. You can also use this mode with the assistant, by configuring the local repository to be in \"manual mode\".
+
+By default though, the way the assistant handles this kind of use case is with `archive` directories. It tries to move any files in an archive directory away from your local disk, and it tries to get any files not in an archive directory to be locally available. So you can just move files around between directories to control where they are stored. See [[assistant/archival_walkthrough]] for details an an example video.
+"""]]
diff --git a/doc/forum/Using_Linux_static_builds.mdwn b/doc/forum/Using_Linux_static_builds.mdwn
new file mode 100644
index 0000000000..ee856f72c1
--- /dev/null
+++ b/doc/forum/Using_Linux_static_builds.mdwn
@@ -0,0 +1,25 @@
+Hello,
+
+I want to use git-annex on a couple of machines that are not under my control (and one that is). For that I use the provided static build, but encountered several problems:
+
+I suppose the first step for command line use is to execute runshell:
+
+On one machine:
+
+flindner@yoko:~> software/git-annex.linux/runshell 
+/bin/bash: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by /home/flindner/software/git-annex.linux//lib/x86_64-linux-gnu/libreadline.so.6)
+
+Is there anything I can do about it?
+
+On the other machine:
+
+flindner@bladefoam2:~$ software/git-annex.linux/runshell 
+bash-4.1$ 
+
+It starts a bare, non-configured shell instance. Can I modifiy and source the script to only set the environment and not start up a new shell?
+
+Another question: If using ssh:// remotes, how can I tell git-annex the first command to set up the environment need in order to execute command via SSH?
+
+Thanks,
+
+Florian
diff --git a/doc/forum/Using_Linux_static_builds/comment_1_22fd266cbe68af3e754a10f1f1295e9b._comment b/doc/forum/Using_Linux_static_builds/comment_1_22fd266cbe68af3e754a10f1f1295e9b._comment
new file mode 100644
index 0000000000..b40ae76952
--- /dev/null
+++ b/doc/forum/Using_Linux_static_builds/comment_1_22fd266cbe68af3e754a10f1f1295e9b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.149"
+ subject="comment 1"
+ date="2012-10-09T15:10:45Z"
+ content="""
+Yes, it seems glibc 2.11 is the oldest version you can get away with. At least until we get a build machine with some truely ancient libc, but modern versions of everything else. Statically linking libc, or including it in the tarball are unfortunatly not technically possible.
+
+You don't need to use runshell if you just want to use the assistant. Which is what this static build is really targeted for. If you want to use all of git-annex, you're probably better off installing it properly.
+It is possible to use \"runshell git annex\" to run a single command inside the shell. Or even make shell script wrappers that do that.. but it seems more difficult than installing git-annex normally.
+
+The static build can be used with ssh. The git-annex assistant should set things up properly. If you want to do it by hand, when it does is configure the ssh key to run ~/.ssh/git-annex-shell, and that file is then made a shell script that runs `runshell git-annex-shell -c \"$SSH_ORIGINAL_COMMAND\"`
+"""]]
diff --git a/doc/forum/Using_Linux_static_builds/comment_2_36f69f30117ff8696425a754ab19a08b._comment b/doc/forum/Using_Linux_static_builds/comment_2_36f69f30117ff8696425a754ab19a08b._comment
new file mode 100644
index 0000000000..4f43034a32
--- /dev/null
+++ b/doc/forum/Using_Linux_static_builds/comment_2_36f69f30117ff8696425a754ab19a08b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnsuhFUIfWNT-Q-C02FDaSQqceFDge5M9w"
+ nickname="Florian"
+ subject="comment 2"
+ date="2012-10-10T10:48:04Z"
+ content="""
+Installing it properly seems to be quite a bit of effort, given the long list of Haskell dependencies. Most of the machines I plan to use it on are not under my control and seem to be somewhat outdated. What way of installing it properly would you suggest?
+"""]]
diff --git a/doc/forum/Using_Linux_static_builds/comment_3_64506833dad0202626239e00d1eb6490._comment b/doc/forum/Using_Linux_static_builds/comment_3_64506833dad0202626239e00d1eb6490._comment
new file mode 100644
index 0000000000..af301bd7e4
--- /dev/null
+++ b/doc/forum/Using_Linux_static_builds/comment_3_64506833dad0202626239e00d1eb6490._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://colberg.org/"
+ ip="2001:470:1d:4d4:2d4b:7654:2c00:b95c"
+ subject="comment 3"
+ date="2012-11-12T05:05:39Z"
+ content="""
+Hi Florian,
+
+I maintain a makefile for GNU/Linux systems that builds git-annex from scratch using a single command.
+
+    git clone http://git.colberg.org/packages.git
+
+    nice make -f packages.mk CONCURRENCY_LEVEL=16 PREFIX=$HOME/usr/rhel6-x64_64 install-git-annex
+
+The makefile fetches pre-compiled GHC 6.x (x86_64), which works on old systems (e.g. RHEL 5), builds a recent GHC 7.x from source, a minimal Haskell environment with cabal-install, and finally git-annex. I have succesfully compiled git-annex on RHEL 5.x and 6.x, and CentOS 6.x.
+
+If the build fails using the system's GCC, there is also a newer GCC in the same makefile:
+
+    nice make -f packages.mk CONCURRENCY_LEVEL=16 PREFIX=$HOME/usr/rhel6-x64_64 install-gcc
+
+Regards,
+Peter
+"""]]
diff --git a/doc/forum/Using___34__sync__34___to_sink_all_branches__63__.mdwn b/doc/forum/Using___34__sync__34___to_sink_all_branches__63__.mdwn
new file mode 100644
index 0000000000..99ddcc3281
--- /dev/null
+++ b/doc/forum/Using___34__sync__34___to_sink_all_branches__63__.mdwn
@@ -0,0 +1,9 @@
+Is there a way to sync all (or a subset of) local branches, not just the currently checked out branch?
+
+Does this make sense at all, or does this show I am missing some important point in git-annex?
+
+I am asking because I would like to use git-annex to keep git repositories with normal git files (with versioned and branched content) in sync.
+
+If it's not currently possible, could you provide some pointers on where to start, if I wanted to change to Haskell source?
+
+Thnx
diff --git a/doc/forum/Using___34__sync__34___to_sink_all_branches__63__/comment_1_ef3d5c5e2600ffa36dd933c8a42cdf96._comment b/doc/forum/Using___34__sync__34___to_sink_all_branches__63__/comment_1_ef3d5c5e2600ffa36dd933c8a42cdf96._comment
new file mode 100644
index 0000000000..2b060197ba
--- /dev/null
+++ b/doc/forum/Using___34__sync__34___to_sink_all_branches__63__/comment_1_ef3d5c5e2600ffa36dd933c8a42cdf96._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlgyVag95OnpvSzQofjyX0WjW__MOMKsl0"
+ nickname="Sehr"
+ subject="comment 1"
+ date="2012-10-29T17:04:30Z"
+ content="""
+Ok, this is what I have come up with:
+
+Merges can only be done on checked out branches. That's why the only way to do this without breaking the whole idea of git-annex (sync) is to check out each branch and run it separately. 
+
+What would be the easiest way to do this? Considering possible unsaved changes in worktree and index?
+
+Maybe simply using git-clone /tmp locally, which uses hardlinks for .git/objects/ which should make it perform ok?
+
+
+"""]]
diff --git a/doc/forum/Using___34__sync__34___to_sink_all_branches__63__/comment_2_424b0c6fdfe87ca08f5d408b7684ab08._comment b/doc/forum/Using___34__sync__34___to_sink_all_branches__63__/comment_2_424b0c6fdfe87ca08f5d408b7684ab08._comment
new file mode 100644
index 0000000000..1c4b9445b6
--- /dev/null
+++ b/doc/forum/Using___34__sync__34___to_sink_all_branches__63__/comment_2_424b0c6fdfe87ca08f5d408b7684ab08._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlgyVag95OnpvSzQofjyX0WjW__MOMKsl0"
+ nickname="Sehr"
+ subject="comment 2"
+ date="2012-10-29T18:52:59Z"
+ content="""
+It turns out, this is even easier: 
+
+As the behavior of \"git-annex sync\" includes performing a \"git commit -a\", any pending changes in the work tree will be committed anyway. This means, that it is safe to simply checkout and sync any branch, one wants to sync.
+"""]]
diff --git a/doc/forum/Using___34__sync__34___to_sink_all_branches__63__/comment_3_adaf9114c69f1268330adcebd8018fa0._comment b/doc/forum/Using___34__sync__34___to_sink_all_branches__63__/comment_3_adaf9114c69f1268330adcebd8018fa0._comment
new file mode 100644
index 0000000000..146785ad3b
--- /dev/null
+++ b/doc/forum/Using___34__sync__34___to_sink_all_branches__63__/comment_3_adaf9114c69f1268330adcebd8018fa0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.194"
+ subject="comment 3"
+ date="2012-11-04T20:08:02Z"
+ content="""
+Yes, that's right, `git annex sync` handles the current branch, and you can use it on different branches if desired.
+
+(It is actually possible to merge non-checked out branches, but I have not implemented that for sync.)
+"""]]
diff --git a/doc/forum/Using___39__git_add__39___in_mixed_content_repository__63__.mdwn b/doc/forum/Using___39__git_add__39___in_mixed_content_repository__63__.mdwn
new file mode 100644
index 0000000000..45f6f73e65
--- /dev/null
+++ b/doc/forum/Using___39__git_add__39___in_mixed_content_repository__63__.mdwn
@@ -0,0 +1,46 @@
+I am attempting to follow the instructions at [[tips/largefiles]] "Configuring mixed content repositories"
+
+After following these instructions, I expect that `git add` will make a decision whether a file goes to 'git-annex' or 'git`.
+
+However, what I observe is: 
+
+* `git-annex add *`  will honor the largefiles setting
+
+* `git add  *`  will NOT honor the largefiles setting
+
+Is there some additional configuration that I need for newer repository versions?
+
+
+I used the following test:
+
+
+    #!/bin/bash
+    curl -Lo https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz  | tar -xvzf -
+    export PATH=./git-annex.linux/:$PATH
+    # Follow steps from https://git-annex.branchable.com/forum/exclude_files_from_annex/
+    git init
+    git annex init
+    git config annex.largefiles "largerthan=100kb and not (include=*.c or include=*.h)"
+    dd if=/dev/urandom of=bigfile1 bs=1M count=1
+    dd if=/dev/urandom of=bigfile2 bs=1M count=1
+    echo 'main() { printf("hello, world!\n") }' > hello.c
+    git annex add bigfile1 
+    if [ ! -L bigfile1 ] ; then
+        echo bigfile1 is not a symlink after git annex add
+        ls -algd ./bigfile1
+    fi
+    git add bigfile2 
+    if [ ! -L bigfile2 ] ; then
+        echo bigfile2 is not a symlink after git add
+        ls -algd ./bigfile2
+    fi
+    git commit -m "Commit!"
+    if [ ! -L bigfile2 ] ; then
+        echo bigfile2 is not a symlink after git commit
+        ls -algd ./bigfile2
+    fi
+
+'bigfile1' is a symlink as expected.
+'bigfile2' never becomes a symlink and is checked into the git repository
+
+
diff --git a/doc/forum/Using___39__git_add__39___in_mixed_content_repository__63__/comment_1_4b524cbbd40aedeb7d44f0c6dec9ffa1._comment b/doc/forum/Using___39__git_add__39___in_mixed_content_repository__63__/comment_1_4b524cbbd40aedeb7d44f0c6dec9ffa1._comment
new file mode 100644
index 0000000000..89e0a620c4
--- /dev/null
+++ b/doc/forum/Using___39__git_add__39___in_mixed_content_repository__63__/comment_1_4b524cbbd40aedeb7d44f0c6dec9ffa1._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-04-17T17:37:45Z"
+ content="""
+Take a look at `git diff --cached bigfile2` and you will see that what has
+been checked into git is a git-annex key. 
+
+This is an unlocked annexed file, which is like a locked annexed file but
+is represented in git differently.
+
+`git add` adds files locked because the interface that git-annex is using
+to hook into it does not let it stage a symlink into git.
+
+You can `git-annex lock bigfile2` to convert it to a symlink.
+"""]]
diff --git a/doc/forum/Using_a_glacier_remote_as_a_backup.mdwn b/doc/forum/Using_a_glacier_remote_as_a_backup.mdwn
new file mode 100644
index 0000000000..2baaa7f914
--- /dev/null
+++ b/doc/forum/Using_a_glacier_remote_as_a_backup.mdwn
@@ -0,0 +1,28 @@
+Hallo everybody,
+
+I have an ARM based Synology NAS and I would like to use git annex to replace the "backup" solution provided by Synology. The basic idea is that I want files in a safe place when the house burns down or they get removed by accident.
+
+Since I only care about the latest version and want to make really sure local programs (cifs service, photostation and so on) do not run into trouble caused by symlinks, I guess direct mode is what I want. I have been tinkering around and things seem to be working for the most part. A few questions remain:
+
+Assuming I have all files synced to glacier and then accidentally remove all content and try to recover with the bare repo - with metadata but without content. the situation looks like this. 
+
+    ➜  syno-archive git:(annex/direct/master) git annex status test.txt
+    D test.txt
+    ➜  syno-archive git:(annex/direct/master)
+    
+I try to get my files back out of glacier:
+
+    ➜  syno-archive git:(annex/direct/master) git annex get test.txt   
+    get test.txt (from glacier...) 
+    ok                      
+    (Recording state in git...)
+    ➜  syno-archive git:(annex/direct/master)
+
+Contrary to my expectation, text.txt did not appear on disk.
+
+Given the bare repo, you would one recover all content (thousands of files)? I expected "git annex get --all" to do the trick. 
+
+PS: This is from git-annex version 5.20141125
+
+regards
+Andreas
diff --git a/doc/forum/Using_a_glacier_remote_as_a_backup/comment_1_bb6022943ec739b1e80351c76f259e89._comment b/doc/forum/Using_a_glacier_remote_as_a_backup/comment_1_bb6022943ec739b1e80351c76f259e89._comment
new file mode 100644
index 0000000000..c6899e4222
--- /dev/null
+++ b/doc/forum/Using_a_glacier_remote_as_a_backup/comment_1_bb6022943ec739b1e80351c76f259e89._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-11T16:58:01Z"
+ content="""
+Your status shows that test.txt is deleted.
+`git annex get` does not un-delete files, it just gets the *content*
+of a file (whether that file is deleted or not).
+
+You can use normal git commands to un-delete the file. Ie, "git checkout
+text.txt". If you're using direct mode, you can't use such commands, but
+can use "git annex undo" to undo a deletion.
+
+Normally, if you have a bare repo, you'll want to clone it to get a non-bare
+repo. I suspect you did something else that resulted in your repo being in
+this state were files are deleted.
+"""]]
diff --git a/doc/forum/Using_a_glacier_remote_as_a_backup/comment_2_41d47f0ca2e05e3296face5f89b819da._comment b/doc/forum/Using_a_glacier_remote_as_a_backup/comment_2_41d47f0ca2e05e3296face5f89b819da._comment
new file mode 100644
index 0000000000..66b08b2fee
--- /dev/null
+++ b/doc/forum/Using_a_glacier_remote_as_a_backup/comment_2_41d47f0ca2e05e3296face5f89b819da._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnwNDA50ZupMvOgpgDqzDRyu5B-mYlVwa4"
+ nickname="Andreas"
+ subject="comment 2"
+ date="2015-05-12T06:52:04Z"
+ content="""
+Actually, I just removed all annexed files to try out disaster recovery. I stumbled across the `undo` command. Unfortunately, it does not seem available on Ubuntu running version 5.20141125 shipped by vivid (`git-annex: Unknown command 'undo'`).
+
+Am I missing something, or how do I get a version supporting `undo`?
+
+thanks
+Andreas
+
+
+"""]]
diff --git a/doc/forum/Using_a_glacier_remote_as_a_backup/comment_3_e572b7bd25b4e7f6c6f83c7354d7407f._comment b/doc/forum/Using_a_glacier_remote_as_a_backup/comment_3_e572b7bd25b4e7f6c6f83c7354d7407f._comment
new file mode 100644
index 0000000000..ac8530baa6
--- /dev/null
+++ b/doc/forum/Using_a_glacier_remote_as_a_backup/comment_3_e572b7bd25b4e7f6c6f83c7354d7407f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-06T20:01:45Z"
+ content="""
+git-annex undo first appeared in version 5.20141203 of git-annex.
+"""]]
diff --git a/doc/forum/Using_a_single_backup_repo_for_multiple_independent_client_repos__63__.mdwn b/doc/forum/Using_a_single_backup_repo_for_multiple_independent_client_repos__63__.mdwn
new file mode 100644
index 0000000000..985bff87c9
--- /dev/null
+++ b/doc/forum/Using_a_single_backup_repo_for_multiple_independent_client_repos__63__.mdwn
@@ -0,0 +1,36 @@
+I don't know if this is an "unusual setup" or something that should be supported, but it seems like a reasonable use case to me, so here goes:
+
+I have three systems: a desktop, a laptop, and a little netbook.  I have one main annex that is currently synced between the desktop and the laptop at ~/annex on both, and to a secondary, Full Backup repo on the desktop, under /mnt.
+
+I have some music on my laptop, and I like to sync ~/Music between the laptop and the netbook.  So I thought I'd make a new git-annex repo at ~/Music on both and sync them.  I want this to be kept separate from ~/annex.
+
+I also thought it would be good to backup the music, so I thought I'd connect laptop:~/Music to the Full Backup repo at desktop:/mnt.  So I paired the repo at laptop:~/Music to the repo at desktop:/mnt.
+
+So I had set up these repos:
+
+* desktop:
+  * /mnt  (Full Backup)
+  * ~/annex  (Client)
+* laptop:
+  * ~/annex  (Client)
+  * ~/Music  (Client)
+* netbook:
+  * ~/Music  (Client)
+
+As I feared--but I wasn't sure, since I'm new to git-annex--since the desktop:/mnt repo was connected to laptop:~/Music, and desktop:~/mnt was also connected to desktop:~/annex,  this caused everything in laptop:~/Music to be synced to desktop:~/annex, because they were part of the same "set" of repos; they were all in the same .git/config files.
+
+So now I have a few problems:
+
+1.  How do I get all these music files out of my ~/annex repos?  I tried removing the remote repos from ~/annex/.git/config and then running 'git-annex unused', but that didn't result in it thinking all the music files were unused.  Do I have to delete them all manually?  (There are a *lot* of directories from ~/Music now in ~/annex).
+
+2.  It seems that desktop:~/annex/.git is...now over 600 MB, even though few of the actual music files have synced over.  Is it possible to clean out ~/annex/.git and restore it to the pre-mess state without starting from scratch?
+
+3.  Is it possible--or reasonable--to use a single Full Backup repo for multiple independent client repos?  That is, is it possible to do that without the independent client repos "cross-pollinating"?  Or do I need to use separate Full Backup repos for each "set" of client repos?
+
+4.  I'm not sure if this is a separate problem, but I just want to make sure I understand the best way to handle things like this.  I wanted to disconnect desktop:~/annex from laptop:~/Music, but I thought that if I used the webapp to "Delete" the laptop:~/Music repo, it would actually start deleting the music files in laptop:~/Music, after moving them to desktop:~/annex.  Am I correct that that would have happened?  If so, "Deleting" a repo seems like a dangerous operation that should warn and prompt the user.  Maybe an "unlink repo" option needs to be available to simply disconnect two repos and leave their respective contents intact.
+
+I apologize if these are newbie problems.  Despite reading every dev blog entry--both before and after the switchover--I'm still new to actually using git-annex.  I'm not sure if it's supposed to work this way or if I'm using it wrong.
+
+If I am using it wrong...well, I can imagine other git-annex newbies doing similar things and ending up with similar messes, so maybe this needs to...be considered or something.  :)  Since I'm still experimenting with git-annex, I haven't put any "live" data in it, so I can blow away all the annexes and start over, but I would like to learn how to properly fix a situation like this in case I goof up in the future.
+
+Thanks for your help.
diff --git a/doc/forum/Using_a_single_backup_repo_for_multiple_independent_client_repos__63__/comment_1_c61c28600f1079fb03ddabc950307f27._comment b/doc/forum/Using_a_single_backup_repo_for_multiple_independent_client_repos__63__/comment_1_c61c28600f1079fb03ddabc950307f27._comment
new file mode 100644
index 0000000000..b7119aa2d0
--- /dev/null
+++ b/doc/forum/Using_a_single_backup_repo_for_multiple_independent_client_repos__63__/comment_1_c61c28600f1079fb03ddabc950307f27._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-05T16:14:34Z"
+ content="""
+1. Turn off the assistant, switch to indirect mode (`git annex indirect`), use `git log --stat` to find the commit(s) that added the music files, and `git revert` the commits, in reverse chronological order. Or delete the files manually.
+2. You have merged two git repositories. Without some serious git repository surgery (ie, resetting to an old version and deleting the reflog), the full history of both is going to remain stored in git going forward. However, a simple `git gc` might pack that down to a much smaller amount of disk space.
+3. Combining two repositories merges their git histories. You then have two clones of one repository containing the full contents and git history of both. Don't do that if that's not what you want. The webapp is always careful to tell you when an action will combine two repositories.
+4. Once you have combined two repositories, you have two synced repositories that contain the same data. Deleting one of them will just delete one copy of the data. It won't result in data loss, but neither will it untangle the two git trees that were previously combined.
+"""]]
diff --git a/doc/forum/Using_for_Music_repo.mdwn b/doc/forum/Using_for_Music_repo.mdwn
new file mode 100644
index 0000000000..25f1365fb8
--- /dev/null
+++ b/doc/forum/Using_for_Music_repo.mdwn
@@ -0,0 +1,13 @@
+Hi, 
+
+I am looking into using git-annex to sync my Music between 3 sources: desktop, laptop, backup, but I'm not sure if this will work ok.
+
+I notice on the wiki that:  "Normally, the content of files in the annex is prevented from being modified. That's a good thing, because it might be the only copy, you wouldn't want to lose it in a fumblefingered mistake."
+
+But most music players will download artwork, and some of course will dynamically modify/rename files according to meta data.  And I may be downloading and/or playing music on both the desktop and laptop.  So obviously I wouldn't want to be manually unlocking individual files here.  It would kinda interrupt the music listening experience.  So how would this work?
+
+I am assuming that I would always have to do a git annex add *.mp3 *.flac *.jpg before doing a git annex sync.  But can I just keep everything unlocked?  Any side effects here?  Will this work or should I just use rsync?
+
+Regards,
+
+bk
diff --git a/doc/forum/Using_for_Music_repo/comment_1_3488ed85ad98f14cb17f229225ece26e._comment b/doc/forum/Using_for_Music_repo/comment_1_3488ed85ad98f14cb17f229225ece26e._comment
new file mode 100644
index 0000000000..d414ecb806
--- /dev/null
+++ b/doc/forum/Using_for_Music_repo/comment_1_3488ed85ad98f14cb17f229225ece26e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-18T20:01:50Z"
+ content="""
+You can use [[direct_mode]] to keep all files unlocked all the time.
+
+You can use the [[forum/`git_annex_assistant`_command_replace_all_files_with_pointer_file.]] to automatically commit whatever changes are made to the directory, as well as automatically sync them to your other computers.
+"""]]
diff --git a/doc/forum/Using_for_Music_repo/comment_2_c794648878cfc77558f8db862271f997._comment b/doc/forum/Using_for_Music_repo/comment_2_c794648878cfc77558f8db862271f997._comment
new file mode 100644
index 0000000000..9ce8743076
--- /dev/null
+++ b/doc/forum/Using_for_Music_repo/comment_2_c794648878cfc77558f8db862271f997._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmgXUaPZHcAY8Wv4sTnX88CbJfYdYdKO-Y"
+ nickname="Boyd"
+ subject="comment 2"
+ date="2013-04-18T23:33:10Z"
+ content="""
+Thanks Joey!  Anyway I see that with Fedora, I don't have the 'assistant'.  I don't even seem to have the 'direct mode'.  Also tried to do a cabal install git-annex, but ran into dependency hell.  Oh well, this is goin on the back burner for a while.  Looks very promising though!
+
+Boyd
+
+[root@zbox Music]# git annex direct
+git-annex: Unknown command 'direct'
+
+Did you mean one of these?
+	reinject
+
+[root@zbox Music]# git annex version
+git-annex version: 3.20120615
+local repository version: 3
+default repository version: 3
+supported repository versions: 3
+upgrade supported from repository versions: 0 1 2
+[root@zbox Music]# 
+
+"""]]
diff --git a/doc/forum/Using_for_Music_repo/comment_3_8c5e820f5ff7d717d64b1fd66927941b._comment b/doc/forum/Using_for_Music_repo/comment_3_8c5e820f5ff7d717d64b1fd66927941b._comment
new file mode 100644
index 0000000000..842a83052d
--- /dev/null
+++ b/doc/forum/Using_for_Music_repo/comment_3_8c5e820f5ff7d717d64b1fd66927941b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-04-19T18:05:49Z"
+ content="""
+Fedora has an old version of git-annex. You can use the [[install/Linux_standalone]] tarball.
+"""]]
diff --git a/doc/forum/Using_git-annex.mdwn b/doc/forum/Using_git-annex.mdwn
new file mode 100644
index 0000000000..0e2be4e81b
--- /dev/null
+++ b/doc/forum/Using_git-annex.mdwn
@@ -0,0 +1,73 @@
+Hi,
+
+I have created a git annex repo, added data. I then went to check it out in another location in the following way (my goal is to checkout origin, add a test file, push it back to origin).
+ git clone ../test_repo/
+
+   282  17:19   cd test_repo/
+
+   283  17:19   ls
+
+   284  17:19   git status
+
+   285  17:22   git annex init DEV
+
+   286  17:22   touch test.txt
+
+   287  17:22   vi test.txt
+
+   288  17:22   git annex merge
+
+   289  17:22   git annex add test.txt
+
+   290  17:22   git commit -am "test"
+
+   291  17:23   git push origin master git-annex 
+
+However I am getting the following error
+
+Counting objects: 3, done.
+
+Delta compression using up to 48 threads.
+
+Compressing objects: 100% (3/3), done.
+
+Writing objects: 100% (3/3), 364 bytes | 0 bytes/s, done.
+
+Total 3 (delta 1), reused 0 (delta 0)
+
+remote: error: refusing to update checked out branch: refs/heads/master
+
+remote: error: By default, updating the current branch in a non-bare repository
+
+remote: error: is denied, because it will make the index and work tree inconsistent
+
+remote: error: with what you pushed, and will require 'git reset --hard' to match
+
+remote: error: the work tree to HEAD.
+
+remote: error: 
+
+remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
+
+remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
+
+remote: error: its current branch; however, this is not recommended unless you
+
+remote: error: arranged to update its work tree to match what you pushed in some
+
+remote: error: other way.
+
+remote: error: 
+
+remote: error: To squelch this message and still keep the default behaviour, set
+
+remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
+
+To /test_repo/
+
+ ! [remote rejected] master -> master (branch is currently checked out)
+
+error: failed to push some refs to '/test_repo/'
+
+
+What am I missing?
diff --git a/doc/forum/Using_git-annex/comment_1_ac386ca07e9aaf009c264f3deed83832._comment b/doc/forum/Using_git-annex/comment_1_ac386ca07e9aaf009c264f3deed83832._comment
new file mode 100644
index 0000000000..9e0e8ff665
--- /dev/null
+++ b/doc/forum/Using_git-annex/comment_1_ac386ca07e9aaf009c264f3deed83832._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-31T20:40:18Z"
+ content="""
+git does not allow pushing into a non-bare repsitory. This is why
+bare repositories exist.
+
+You have basically 3 choices:
+
+1. Go to the first repo you made, and `git pull` from the other repo
+   into it. Pulling in this direction will work.
+2. Set up a bare repo that both the non-bare repos use.
+3. Use `git annex sync`, which avoids this problem. You need to run
+   it in both repos in order to get them to sync with one-another.
+"""]]
diff --git a/doc/forum/Using_git-annex/comment_2_bf5e13a490e16943acd2732f093695fc._comment b/doc/forum/Using_git-annex/comment_2_bf5e13a490e16943acd2732f093695fc._comment
new file mode 100644
index 0000000000..97ec4fb98e
--- /dev/null
+++ b/doc/forum/Using_git-annex/comment_2_bf5e13a490e16943acd2732f093695fc._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawktbkKjilg70XC9XBFpIgVhtfLYH-0UMHY"
+ nickname="Tad"
+ subject="comment 2"
+ date="2014-11-06T15:39:12Z"
+ content="""
+Ok so when I create my origin and after I add files to it, when I run git annex sync I get
+
+Invalid command: 'git-annex-shell 'configlist' '/~/gitfile.git''
+  You appear to be using ssh to clone a git:// URL.
+  Make sure your core.gitProxy config option and the
+  GIT_PROXY_COMMAND environment variable are NOT set.
+warning: no common commits
+
+and then it hangs. Is git-annex not accepting git via ssh?
+"""]]
diff --git a/doc/forum/Using_git-annex/comment_3_471c9268b028f47ef3fac3f0be14b2b1._comment b/doc/forum/Using_git-annex/comment_3_471c9268b028f47ef3fac3f0be14b2b1._comment
new file mode 100644
index 0000000000..4dfa8916d0
--- /dev/null
+++ b/doc/forum/Using_git-annex/comment_3_471c9268b028f47ef3fac3f0be14b2b1._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2014-11-06T19:42:33Z"
+ content="""
+git-annex certianly works with git over ssh. You seem to not have git-annex
+installed on your git server, which will limit what you can do with it.
+
+I cannot find the message "You appear to be using ssh to clone a git:// URL." 
+in either git or git-annex's code base. Perhaps the message is coming from
+something like gitosis or gitolite on your git server?
+
+It's hard to give advice when you're not said anything about how you've set
+things up.
+"""]]
diff --git a/doc/forum/Using_git-annex_as_a_library.mdwn b/doc/forum/Using_git-annex_as_a_library.mdwn
new file mode 100644
index 0000000000..3727679dd0
--- /dev/null
+++ b/doc/forum/Using_git-annex_as_a_library.mdwn
@@ -0,0 +1 @@
+I am looking to use git-annex as a library/tool to bring syncing to another application. Is there any documentation or open examples of doing something like this?
diff --git a/doc/forum/Using_git-annex_as_a_library/comment_10_cfded5c6325007c3f3f83818bd2e1dbc._comment b/doc/forum/Using_git-annex_as_a_library/comment_10_cfded5c6325007c3f3f83818bd2e1dbc._comment
new file mode 100644
index 0000000000..8583952330
--- /dev/null
+++ b/doc/forum/Using_git-annex_as_a_library/comment_10_cfded5c6325007c3f3f83818bd2e1dbc._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="unqueued"
+ avatar="http://cdn.libravatar.org/avatar/3bcbe0c9e9825637ad7efa70f458640d"
+ subject="comment 10"
+ date="2024-04-10T12:26:49Z"
+ content="""
+For my two cents, I have found git-annex to be a simple enough format that I have only needed basic helper scripts.
+
+But many operations can be done with one or a few lines of code.
+
+Git can do much of the heavy lifting for you in terms of looking stuff up from the git-annex branch, and I find the formats to be quite regular and easy to parse.
+
+I am thinking of bringing some of this together into a PHP library.
+
+But maybe I should just post my pure git-annex bash/perl one-liners.
+"""]]
diff --git a/doc/forum/Using_git-annex_as_a_library/comment_1_1f8e74c5856f21c53d5a91892cbef0c6._comment b/doc/forum/Using_git-annex_as_a_library/comment_1_1f8e74c5856f21c53d5a91892cbef0c6._comment
new file mode 100644
index 0000000000..6ba664aead
--- /dev/null
+++ b/doc/forum/Using_git-annex_as_a_library/comment_1_1f8e74c5856f21c53d5a91892cbef0c6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlaQ9Hd5o_wjCIcfC9MAx8GRli5-LyBang"
+ nickname="George"
+ subject="comment 1"
+ date="2013-06-29T16:07:45Z"
+ content="""
+I should say specifically interfacing with git-annex
+"""]]
diff --git a/doc/forum/Using_git-annex_as_a_library/comment_2_11a243fa7d8ac947aa9a798228dbd191._comment b/doc/forum/Using_git-annex_as_a_library/comment_2_11a243fa7d8ac947aa9a798228dbd191._comment
new file mode 100644
index 0000000000..4177d7d208
--- /dev/null
+++ b/doc/forum/Using_git-annex_as_a_library/comment_2_11a243fa7d8ac947aa9a798228dbd191._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 2"
+ date="2013-06-30T18:08:52Z"
+ content="""
+I think there are two approaches to doing this.
+
+1. Use the git-annex command line interface from your program. You can use the --json switch to enable machine-parsable output of many git-annex commands. If something needs work to be more suitable to be used as \"plumbing\" in this way, we can improve it to meet your needs.
+
+2. Use the git-annex Haskell code as a library for your program. The git-annex assistant is a great example of how far you can take this. It has the benefit that by accessing git-annex's internals, you can sometimes do things more efficiently than by using the CLI. Much of git-annex's code is already well modularized and suitable for use as a library in this way. The build system doesn't currently spit out git-annex libraries, but it would not be hard to make it do so. Of course this would entail writing at least some of your program in Haskell.
+"""]]
diff --git a/doc/forum/Using_git-annex_as_a_library/comment_3_ac52304a096ebc66967352efaffb060a._comment b/doc/forum/Using_git-annex_as_a_library/comment_3_ac52304a096ebc66967352efaffb060a._comment
new file mode 100644
index 0000000000..cda6e0799a
--- /dev/null
+++ b/doc/forum/Using_git-annex_as_a_library/comment_3_ac52304a096ebc66967352efaffb060a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Alexcei"
+ ip="92.255.239.77"
+ subject="comment 3"
+ date="2014-03-25T05:43:36Z"
+ content="""
+With version 5.20140127 first approach became impossible. Why did you decide to remove json supported by the majority of command?
+"""]]
diff --git a/doc/forum/Using_git-annex_as_a_library/comment_4_d502fea60bf3a82f8a50f72a90a80c25._comment b/doc/forum/Using_git-annex_as_a_library/comment_4_d502fea60bf3a82f8a50f72a90a80c25._comment
new file mode 100644
index 0000000000..642fda2fef
--- /dev/null
+++ b/doc/forum/Using_git-annex_as_a_library/comment_4_d502fea60bf3a82f8a50f72a90a80c25._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.41"
+ subject="comment 4"
+ date="2014-03-26T18:31:30Z"
+ content="""
+I didn't. I removed the --json options from commands that didn't necessarily output valid json when used with it. There are numerous commands that support --json (find, whereis, info, status, metadata, examinekey), and I'm open to adding it to other commands -- but it's probably not feasible to make commands like `get` output json, since their output includes progress info printed by rsync etc.
+"""]]
diff --git a/doc/forum/Using_git-annex_as_a_library/comment_5_a4ab4173620b72ac0a24d575fa9c810c._comment b/doc/forum/Using_git-annex_as_a_library/comment_5_a4ab4173620b72ac0a24d575fa9c810c._comment
new file mode 100644
index 0000000000..70f2ad9353
--- /dev/null
+++ b/doc/forum/Using_git-annex_as_a_library/comment_5_a4ab4173620b72ac0a24d575fa9c810c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkuFJVGp6WVvJtIV5JYb8IqN8mRvSGQdI"
+ nickname="Emilio Jesús"
+ subject="Would you accept a patch?"
+ date="2014-08-03T01:18:54Z"
+ content="""
+Dear Joey,
+
+I am also interested in using git-annex as a Haskell library, would you accept a patch to the .cabal file then?
+
+Thanks,
+Emilio
+"""]]
diff --git a/doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment b/doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment
new file mode 100644
index 0000000000..8591e79aa0
--- /dev/null
+++ b/doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 6"
+ date="2014-08-12T17:48:34Z"
+ content="""
+There are a couple of problems with using the haskell code as a library that would need to be addressed:
+
+* I can't guarantee much about providing every interface in a compatible way going forward. It might make sense to pick out some key interfaces and make those stable, but I don't know what the right choices would be.
+* If all of git-annex is a library, `cabal build` will build everything a second time. This is annoying when trying to do a fast edit/build/test cycle, but I don't know a way to make cabal not do it. AFAIK cabal build flags cannot be used to disable building a library.
+"""]]
diff --git a/doc/forum/Using_git-annex_as_a_library/comment_7_909628f1edd0d3448498fc434c61a3a4._comment b/doc/forum/Using_git-annex_as_a_library/comment_7_909628f1edd0d3448498fc434c61a3a4._comment
new file mode 100644
index 0000000000..63d06ba09f
--- /dev/null
+++ b/doc/forum/Using_git-annex_as_a_library/comment_7_909628f1edd0d3448498fc434c61a3a4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2023-11-21T20:23:19Z"
+ content="""
+Hmm, `cabal build` does not build the library 2x in the case of propellor,
+which has a similar split between the propellor library and the executables
+that depend on it. Perhaps cabal has improved that since I posted my
+comment.
+"""]]
diff --git a/doc/forum/Using_git-annex_as_a_library/comment_8_cef28b8639b6c6e84804b485fb5037f1._comment b/doc/forum/Using_git-annex_as_a_library/comment_8_cef28b8639b6c6e84804b485fb5037f1._comment
new file mode 100644
index 0000000000..400e1913af
--- /dev/null
+++ b/doc/forum/Using_git-annex_as_a_library/comment_8_cef28b8639b6c6e84804b485fb5037f1._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-11-21T20:25:55Z"
+ content="""
+A lot of git-annex's end user functionality is in the `Command/*` modules.
+Much of the code in those is not in a form that would be useful in a
+library, unless the library was structured to run a `Command`.
+
+If the goal is say, to add a file to git-annex, and then to be able to
+get and drop the file, and `Command.Add`, `Command.Get`, and `Command.Drop`
+were not in the library, you'd have to put together the eqivilant of what
+those commands do out of the internal library code:
+
+* `Command.Add` essentially uses `Annex.Ingest` followed by calling into
+  `Logs.Location` to update the location log. 
+* `Command.Drop` uses `Annex.NumCopies` to construct a drop proof and passes
+  it off to `Annex.Drop`.
+* `Command.Get` handles trying different remotes itself, calling into 
+  `Annex.Transfer`.
+
+So the library structure works for git-annex as a thing for Command modules
+to use, but not great for other things. The assistant actually imports some
+Command modules, eg it uses Command.Add.addFile. Similarly it would be
+possible to call Command.Get.getKey.
+
+Maybe it would be better to have a library interface that does mirror the
+git-annex command line, so you could run eg:
+
+	runCommand (Command.Add.cmd) (AddOptions {...}) "somefile"
+	runCommand (Command.Drop.cmd) (DropOptions {...}) "somefile"
+
+That would necessarily have output like those commands too (unless quiet
+mode were enabled).
+
+It would take some work to get there from the current state.
+"""]]
diff --git a/doc/forum/Using_git-annex_as_a_library/comment_9_6d8ebdedf76fdf0c267444a7a07e225e._comment b/doc/forum/Using_git-annex_as_a_library/comment_9_6d8ebdedf76fdf0c267444a7a07e225e._comment
new file mode 100644
index 0000000000..649b836902
--- /dev/null
+++ b/doc/forum/Using_git-annex_as_a_library/comment_9_6d8ebdedf76fdf0c267444a7a07e225e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="oadams"
+ avatar="http://cdn.libravatar.org/avatar/ac166a5f89f10c4108e5150015e6751b"
+ subject="comment 9"
+ date="2023-12-16T21:37:21Z"
+ content="""
+A belated thanks for the follow-up from https://git-annex.branchable.com/forum/Using_git_annex_as_a_library/
+
+Not that its useful for anyone here, but just FWIW after some more playing around I decided to keep things minimal and not depend on git-annex as a library. Although what I'm making naturally pairs well with git-annex it doesn't really require it, so adding the dependency just complicates things.
+"""]]
diff --git a/doc/forum/Using_git-annex_to_manage_git_repositories.mdwn b/doc/forum/Using_git-annex_to_manage_git_repositories.mdwn
new file mode 100644
index 0000000000..a2733c0db7
--- /dev/null
+++ b/doc/forum/Using_git-annex_to_manage_git_repositories.mdwn
@@ -0,0 +1,5 @@
+I am interested in using git-annex to manage git repositories, and I am wondering if it is possible and if anyone has experience with it?
+
+I have done some searching, and I know that many people have asked for support for a Dropbox-like workflow, where Git repositories are mirrored everywhere.  I also know that no such support seems forthcoming, however this is not my goal.  Rather, I would like to use git-annex to track the location of many repositories.  I keep a lot of repositories and would like to offload them onto other storage devices and keep track of where each repository is stored.
+
+Perhaps entire Git repositories can be added as a single unit for tracking in git-annex?
diff --git a/doc/forum/Using_git-annex_to_manage_git_repositories/comment_1_f221717814f62e0779d691d2f601ab12._comment b/doc/forum/Using_git-annex_to_manage_git_repositories/comment_1_f221717814f62e0779d691d2f601ab12._comment
new file mode 100644
index 0000000000..593496b630
--- /dev/null
+++ b/doc/forum/Using_git-annex_to_manage_git_repositories/comment_1_f221717814f62e0779d691d2f601ab12._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica"
+ subject="Yes and no..."
+ date="2015-04-04T04:13:48Z"
+ content="""
+
+> I am interested in using git-annex to manage git repositories, and I am wondering if it is possible and if anyone has experience with it?
+
+That is not what git-annex is for. git-annex adds large file support to git.
+
+> I have done some searching, and I know that many people have asked for support for a Dropbox-like workflow, where Git repositories are mirrored everywhere. 
+
+The git-annex assistant will automatically sync your files for you. It is similar to dropbox but not entirely the same.
+
+> I also know that no such support seems forthcoming, however this is not my goal. 
+
+I don't know what would give you that idea, the git-annex assistant has already been released.
+
+> Rather, I would like to use git-annex to track the location of many repositories. I keep a lot of repositories and would like to offload them onto other storage devices and keep track of where each repository is stored.
+
+git-annex is not the right tool for that. Maybe you want something like myrepos, which is always written by Joey.
+
+> Perhaps entire Git repositories can be added as a single unit for tracking in git-annex?
+
+Seems unlikely as it is out of scope for git-annex.
+"""]]
diff --git a/doc/forum/Using_git-annex_to_manage_git_repositories/comment_2_ab24098c2f4519cbbfdcd00ba3e21d2b._comment b/doc/forum/Using_git-annex_to_manage_git_repositories/comment_2_ab24098c2f4519cbbfdcd00ba3e21d2b._comment
new file mode 100644
index 0000000000..87fe1768bf
--- /dev/null
+++ b/doc/forum/Using_git-annex_to_manage_git_repositories/comment_2_ab24098c2f4519cbbfdcd00ba3e21d2b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-04-06T17:01:32Z"
+ content="""
+This is not what git-annex was designed to do, so I don't think it's the
+right tool for the job.
+
+I suggest <http://myrepos.branchable.com/>
+"""]]
diff --git a/doc/forum/Using_git-annex_to_manage_git_repositories/comment_3_5cf9e2ff83bb76650469444c80fee4fb._comment b/doc/forum/Using_git-annex_to_manage_git_repositories/comment_3_5cf9e2ff83bb76650469444c80fee4fb._comment
new file mode 100644
index 0000000000..115cea9061
--- /dev/null
+++ b/doc/forum/Using_git-annex_to_manage_git_repositories/comment_3_5cf9e2ff83bb76650469444c80fee4fb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk_STgv_0fB-y1x_fgzUI10Bg-aajJyMyc"
+ nickname="猫"
+ subject="comment 3"
+ date="2015-04-08T06:30:06Z"
+ content="""
+I'll take a closer look at myrepos, but it doesn't seem to do location tracking, which is the main feature of git-annex that I'm looking for.
+"""]]
diff --git a/doc/forum/Using_git-annex_via_command_line_in_OS_X.mdwn b/doc/forum/Using_git-annex_via_command_line_in_OS_X.mdwn
new file mode 100644
index 0000000000..5eba701bdd
--- /dev/null
+++ b/doc/forum/Using_git-annex_via_command_line_in_OS_X.mdwn
@@ -0,0 +1,3 @@
+After installing the binary for Mac OS X and including some larger directories, my computer now seems quite busy (for the last days) with the import process. I see a process called git-annex causing the load, so it seems OK. As the git-annex assistant seems to hang quite a bit, I would like to see the progress using a command line interface. However, I cannot use the "git annex" command as I get the message "git: 'annex' is not a git command. See 'git --help'."
+
+I guess this is my normal git version, installed by homebrew (the OS X version for apt-get) that does not know anything about the installed binary. Can I still use the CLI with this version? Or better, is there or will there be a way to install git-annex from source, or even better using "brew install git-annex"?
diff --git a/doc/forum/Using_git-annex_via_command_line_in_OS_X/comment_1_1c9e121f60fb6868c07f1a53b03c4ed0._comment b/doc/forum/Using_git-annex_via_command_line_in_OS_X/comment_1_1c9e121f60fb6868c07f1a53b03c4ed0._comment
new file mode 100644
index 0000000000..1f51e6c971
--- /dev/null
+++ b/doc/forum/Using_git-annex_via_command_line_in_OS_X/comment_1_1c9e121f60fb6868c07f1a53b03c4ed0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaZYaspvzx1lQiM56UQo-X82BnPiAaiEY"
+ nickname="Martin"
+ subject="comment 1"
+ date="2013-08-19T18:07:04Z"
+ content="""
+One more question. When running the git-annex binary the webapp opens. After closing the window I cannot access the webapp anymore. Using the IP + port number (http://127.0.0.1:53027/) does not work. Would be handy to have a bookmark for the webapp that works as long as the assistant is running.
+"""]]
diff --git a/doc/forum/Using_git-annex_via_command_line_in_OS_X/comment_2_52d8ffba82e29ac2722a8e43e469cc47._comment b/doc/forum/Using_git-annex_via_command_line_in_OS_X/comment_2_52d8ffba82e29ac2722a8e43e469cc47._comment
new file mode 100644
index 0000000000..b30773cd22
--- /dev/null
+++ b/doc/forum/Using_git-annex_via_command_line_in_OS_X/comment_2_52d8ffba82e29ac2722a8e43e469cc47._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaZYaspvzx1lQiM56UQo-X82BnPiAaiEY"
+ nickname="Martin"
+ subject="git-annex via comand line"
+ date="2013-08-19T21:53:11Z"
+ content="""
+Just found the page how to install the CLI on OS X: http://git-annex.branchable.com/install/OSX/
+That solved all my questions for now.
+"""]]
diff --git a/doc/forum/Using_git_annex_as_a_library.mdwn b/doc/forum/Using_git_annex_as_a_library.mdwn
new file mode 100644
index 0000000000..c76f98e9a6
--- /dev/null
+++ b/doc/forum/Using_git_annex_as_a_library.mdwn
@@ -0,0 +1,6 @@
+I've started writing a small tool in Haskell to manage data processing pipelines. I'm interested in using git-annex as a library as part of this (since the idea is that the raw data is tracked in git-annex and git). I'm wondering what the best way to go about doing it is.
+
+If I set my stack.yaml `extra-deps` to point to the git repository and run `stack build` then stack visibly goes and downloads the package. But from there I can't actually import any modules in my own Haskell program. When I use `import Git` or `import Annex.HashObject` then I get a compile error along the lines of `Could not find module ‘Annex.HashObject’`.
+
+Do you have any pointers for how I might best use git-annex as a library? Thanks for your help, sorry if it's so basic as I'm new to the Haskell tooling ecosystem.
+
diff --git a/doc/forum/Using_git_annex_as_a_library/comment_1_42cd26878e4e5c2c238c1227e3c372d9._comment b/doc/forum/Using_git_annex_as_a_library/comment_1_42cd26878e4e5c2c238c1227e3c372d9._comment
new file mode 100644
index 0000000000..d4ce3acd23
--- /dev/null
+++ b/doc/forum/Using_git_annex_as_a_library/comment_1_42cd26878e4e5c2c238c1227e3c372d9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="oadams"
+ avatar="http://cdn.libravatar.org/avatar/ac166a5f89f10c4108e5150015e6751b"
+ subject="comment 1"
+ date="2023-11-07T08:30:21Z"
+ content="""
+I should add that I have just seen this discussion https://git-annex.branchable.com/forum/Using_git-annex_as_a_library/. Perhaps I should have posted there, but either way I'm wondering if things are different these days?
+"""]]
diff --git a/doc/forum/Using_git_annex_as_a_library/comment_2_1323238fc63e121fbc0f408a23d1ada5._comment b/doc/forum/Using_git_annex_as_a_library/comment_2_1323238fc63e121fbc0f408a23d1ada5._comment
new file mode 100644
index 0000000000..882691e075
--- /dev/null
+++ b/doc/forum/Using_git_annex_as_a_library/comment_2_1323238fc63e121fbc0f408a23d1ada5._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-11-21T20:17:10Z"
+ content="""
+Hmm, I followed up on that other page to avoid fragmenting the discussion.
+"""]]
diff --git a/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks.mdwn b/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks.mdwn
new file mode 100644
index 0000000000..3420c129f7
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks.mdwn
@@ -0,0 +1,8 @@
+Hallo,
+
+I have got a Samsung Galaxy Note 10.1 I want to sync with a remote ssh-Server, but the tablet only supports exFAT and FAT file Systems, so I cannot use symlinks.
+
+Does any solution exist for this? 
+
+Mebus
+
diff --git a/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_1_b9f202a30ba7e3bc264064d24454c099._comment b/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_1_b9f202a30ba7e3bc264064d24454c099._comment
new file mode 100644
index 0000000000..f5d4b3cdd5
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_1_b9f202a30ba7e3bc264064d24454c099._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 1"
+ date="2013-10-22T17:37:44Z"
+ content="""
+The sad state of affairs that in the supposedly modern 21st century, popular operating systems are regressing in functionality? 
+
+Yes, git-annex can deal with this. `git annex init` will detect when it's run on a crippled filesystem and enable various workarounds, including [[direct_mode]].
+
+The git-annex android app deals with all this automatically when creating a repository.
+"""]]
diff --git a/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_2_1334a8d9f4bb60f3bf3ebabc656d98d9._comment b/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_2_1334a8d9f4bb60f3bf3ebabc656d98d9._comment
new file mode 100644
index 0000000000..493aaf65e3
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_2_1334a8d9f4bb60f3bf3ebabc656d98d9._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Mebus"
+ ip="2001:4dd0:ff00:29::2"
+ subject="comment 2"
+ date="2013-10-31T23:39:42Z"
+ content="""
+Hallo,
+
+I tried it again.
+
+On the Android tablet I get many files, which have got a size of 200 Bytes. And they should at least be a view kB.
+
+Why?
+
+Mebus
+
+
+"""]]
diff --git a/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_3_076f22d05fad140068a540e4d835106f._comment b/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_3_076f22d05fad140068a540e4d835106f._comment
new file mode 100644
index 0000000000..0fb4f61e2b
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_3_076f22d05fad140068a540e4d835106f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 3"
+ date="2013-11-01T16:42:33Z"
+ content="""
+Files in the git repository whose content has not yet been downloaded will appear as these short placeholder files when using a filesystem that does not support symlinks. Once the files have been downloaded, that is replaced with their actual content. You may need to set up a way to your android tablet to download the files from the place they're being created.
+"""]]
diff --git a/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_4_c8446ee1b817f1824fa0df07e742015c._comment b/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_4_c8446ee1b817f1824fa0df07e742015c._comment
new file mode 100644
index 0000000000..cd42b6c158
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_4_c8446ee1b817f1824fa0df07e742015c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Mebus"
+ ip="2001:4dd0:ff00:29::2"
+ subject="comment 4"
+ date="2013-11-11T20:24:11Z"
+ content="""
+Does it have to be the place, where they were created or can this also be a central server, I pushed everything to?
+
+Mebus
+
+
+"""]]
diff --git a/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_5_f746c1b85ee8e4b57b6819ccceabd28b._comment b/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_5_f746c1b85ee8e4b57b6819ccceabd28b._comment
new file mode 100644
index 0000000000..676e7b6f10
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/comment_5_f746c1b85ee8e4b57b6819ccceabd28b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 5"
+ date="2013-11-13T16:37:46Z"
+ content="""
+The git-annex app will download the files from any remote you set up that has a copy of the file. A transfer remote in the cloud would work well.
+"""]]
diff --git a/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs.mdwn b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs.mdwn
new file mode 100644
index 0000000000..1e64430385
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs.mdwn
@@ -0,0 +1,5 @@
+I've got a Freebox Revolution set-top box / TV NAS at home, with some preconfigured layou for videos, photos and music.
+
+I'd like to use it as a git-annex remote, but am afraid there's no support for FTP (authenticated) or SMB shares exported by the NAS (I don't think it supports other protocols even though runs Linux internally, AFAIK).
+
+Is there any option to store much on that NAS and sync it with git-annex ?
diff --git a/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_1_bd73c8d10028e1b45da9ea8f657e5064._comment b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_1_bd73c8d10028e1b45da9ea8f657e5064._comment
new file mode 100644
index 0000000000..d5e8d54043
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_1_bd73c8d10028e1b45da9ea8f657e5064._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://cstork.org/"
+ nickname="Chris Stork"
+ subject="Similar to &quot;direct special remotes&quot;"
+ date="2013-08-16T17:57:26Z"
+ content="""
+You have a very similar problem as I do.
+
+See my post where I called this [direct special remotes](http://git-annex.branchable.com/forum/Direct_special_remotes/).
+"""]]
diff --git a/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_2_16c3c994ee8fcb466e52ca0e812e5915._comment b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_2_16c3c994ee8fcb466e52ca0e812e5915._comment
new file mode 100644
index 0000000000..93eef73220
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_2_16c3c994ee8fcb466e52ca0e812e5915._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://olivier.berger.myopenid.com/"
+ nickname="obergix"
+ subject="Except I don't have rsync/sftp on the NAS AFAICT"
+ date="2013-08-17T08:56:37Z"
+ content="""
+There seemed to be some hope with rsync in your case, but not mine. Thanks anyway for the pointer.
+"""]]
diff --git a/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_3_ac60f6edb76bdd541711e472eec9591a._comment b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_3_ac60f6edb76bdd541711e472eec9591a._comment
new file mode 100644
index 0000000000..8729a8481e
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_3_ac60f6edb76bdd541711e472eec9591a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://olivier.berger.myopenid.com/"
+ nickname="obergix"
+ subject="Experimenting with a CIFS mount point of the NAS and direct mode"
+ date="2013-08-17T22:11:19Z"
+ content="""
+I've been experimenting with a direct mode repo on a CIFS mount of the SMB share of the NAS.
+
+Unfortunately, it seems I can't propagate changes made on the laptop to the mount point by issueing a git pull or merge, as it is part of the unsafe commands that don't support direct mode (see details in <http://git-annex.branchable.com/direct_mode/#comment-fca93776b9526341e6aae4fe2c53038c>)... direct mode wouldn't be very useful then : I intend to mirror on the NAS the files I've been managing locally. For instance I will sort my photos in subdirs, on the laptop, and intend to mirror that on the NAS.
+"""]]
diff --git a/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_4_2194f0600d9a90f0d9c947ea9cc213a3._comment b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_4_2194f0600d9a90f0d9c947ea9cc213a3._comment
new file mode 100644
index 0000000000..4a59acdeb7
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_4_2194f0600d9a90f0d9c947ea9cc213a3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 4"
+ date="2013-08-23T17:55:39Z"
+ content="""
+Just run `git annex sync` to update the direct mode repository on your NAS.
+"""]]
diff --git a/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_5_eb7d13f6b6fa674a2536bde51bfc3fd1._comment b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_5_eb7d13f6b6fa674a2536bde51bfc3fd1._comment
new file mode 100644
index 0000000000..e014efb86c
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_5_eb7d13f6b6fa674a2536bde51bfc3fd1._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="http://olivier.berger.myopenid.com/"
+ nickname="obergix"
+ subject="So it seems I have found a sequence that seems to be operating fine"
+ date="2013-08-23T20:28:45Z"
+ content="""
+Here's a script, which I think makes it work, using git clone, git annex copy and git annex sync :
+    # The \"master\" remote which is with default indirect mode, on a Linux FS
+    BASE1=~/tmp
+    REPO1=$BASE1/annex-test
+    
+    # The \"slave\" remote on the NAS (a Samba server), which has been mounted with cifs, and thus will be in direct mode
+    BASE2=/mnt/freebox-server/
+    REPO2=$BASE2/annex-test
+    
+    cd $BASE1
+    mkdir $REPO1
+    cd $REPO1
+    git init
+    git annex init \"my laptop\"
+    
+    cd $REPO1
+    cp -Lr ~/some_large_files ./
+    git annex add some_large_files
+    git commit -m \"added\"
+    
+    cd $BASE2    
+    git clone $REPO1 $REPO2
+    cd $REPO2
+    
+    git annex init \"freebox server\"
+    # This is not really needed, but if you want to replicate on a non cifs mount
+    git annex direct
+    
+    cd $REPO1
+    git remote add freebox-server $REPO2
+    
+    git annex copy --to freebox-server
+    git annex sync
+    
+    cd $REPO2
+    git remote add laptop $REPO1
+    #git annex sync
+
+After this, you should have your .git and plain \"direct\" files on the NAS, mirrored from what's on the laptop.
+
+Hope this helps.
+"""]]
diff --git a/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_6_ae323b16ddb9342e91be955408eca3b1._comment b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_6_ae323b16ddb9342e91be955408eca3b1._comment
new file mode 100644
index 0000000000..44d3f5a85c
--- /dev/null
+++ b/doc/forum/Using_git_annex_with_a_SMB__47__FTP_TV_NAS_with_preconfigured_dirs/comment_6_ae323b16ddb9342e91be955408eca3b1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 6"
+ date="2013-08-24T15:58:28Z"
+ content="""
+You can run any of these operations in any order and it will work. Ie, this is far more complicated and detailed than it needs to be. Just run git-annex commands in any order to do what you want to do. If they don't, file a (detailed) bug report.
+"""]]
diff --git a/doc/forum/Using_hashdirlower_layout_for_S3_special_remote.mdwn b/doc/forum/Using_hashdirlower_layout_for_S3_special_remote.mdwn
new file mode 100644
index 0000000000..8fdddeae5d
--- /dev/null
+++ b/doc/forum/Using_hashdirlower_layout_for_S3_special_remote.mdwn
@@ -0,0 +1,3 @@
+Hi,
+
+Is it possible to use hashdirlower layout with S3 special remote, instead of storing all the files in the root of the bucket?
diff --git a/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_1_ff8c84af9d08dfe7d8e502d1b84732f4._comment b/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_1_ff8c84af9d08dfe7d8e502d1b84732f4._comment
new file mode 100644
index 0000000000..fcdece4245
--- /dev/null
+++ b/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_1_ff8c84af9d08dfe7d8e502d1b84732f4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="TroisSinges"
+ avatar="http://cdn.libravatar.org/avatar/f4c62f9ebe09016b8852b04f1dd6612f"
+ subject="comment 1"
+ date="2019-09-02T22:19:04Z"
+ content="""
+Hmmm, this is strange, because according to <http://git-annex.branchable.com/special_remotes/S3/#comment-e9d48ba37aa5b01c236ab894057660b7>, files should be \"stored in a hashed directory structure with the names of their key used\". This isn't the case for me, using S3 special remote for Wasabi.
+"""]]
diff --git a/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_2_9f22f7f14fab759caa1ddecda435311c._comment b/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_2_9f22f7f14fab759caa1ddecda435311c._comment
new file mode 100644
index 0000000000..4abb0ddaeb
--- /dev/null
+++ b/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_2_9f22f7f14fab759caa1ddecda435311c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-05T15:29:57Z"
+ content="""
+That comment was just bad wording or possibly I conflated S3 with how other
+remotes that do use hash directories work. I've corrected the comment.
+
+According to Amazon's documentation, S3 does not have a concept of
+directories; "foo/bar" and "foo_bar" and "foo\\bar" are all just opaque
+strings as far as it's concerned. So I don't see any point in using hash
+directories with S3.
+"""]]
diff --git a/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_3_d90ee84a9b0cf190961d92d089dbf7a6._comment b/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_3_d90ee84a9b0cf190961d92d089dbf7a6._comment
new file mode 100644
index 0000000000..38ecb27a80
--- /dev/null
+++ b/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_3_d90ee84a9b0cf190961d92d089dbf7a6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="directories on S3"
+ date="2019-09-05T18:40:20Z"
+ content="""
+\"S3 does not have a concept of directories; \"foo/bar\" and \"foo_bar\" and \"foo\bar\" are all just opaque strings as far as it's concerned\" -- just to note: (1) AWS [CLI](https://aws.amazon.com/cli/) commands like `aws s3 ls` and `aws s3 cp`  do have the concept of directories; (2) An [S3 tips page](https://www.sumologic.com/insight/10-things-might-not-know-using-s3/) says that \"latency on S3 operations depends on key names since prefix similarities become a bottleneck at more than about 100 requests per second. If you have need for high volumes of operations, it is essential to consider naming schemes with more variability at the beginning of the key names, like alphanumeric or hex hash codes in the first 6 to 8 characters, to avoid internal “hot spots” within S3 infrastructure.\"
+"""]]
diff --git a/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_4_5aa6dff353af7beffdd56652d6fc6d3e._comment b/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_4_5aa6dff353af7beffdd56652d6fc6d3e._comment
new file mode 100644
index 0000000000..5adf3611ee
--- /dev/null
+++ b/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_4_5aa6dff353af7beffdd56652d6fc6d3e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="TroisSinges"
+ avatar="http://cdn.libravatar.org/avatar/f4c62f9ebe09016b8852b04f1dd6612f"
+ subject="comment 4"
+ date="2019-09-05T19:12:30Z"
+ content="""
+Thanks Joey for your answer. However, even if directories are indeed totally virtual in S3, file paths are split using \"/\" characters when using S3 web console, for example (it's the same for Wasabi, for example). It's quite convenient!
+
+Moreover, some S3-compatible services do create directories using \"/\" delimiters.
+"""]]
diff --git a/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_5_79519a4c0fc25d41226a7048cd3a8306._comment b/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_5_79519a4c0fc25d41226a7048cd3a8306._comment
new file mode 100644
index 0000000000..d5df12266e
--- /dev/null
+++ b/doc/forum/Using_hashdirlower_layout_for_S3_special_remote/comment_5_79519a4c0fc25d41226a7048cd3a8306._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-09-06T17:53:00Z"
+ content="""
+The stuff @Ilya found about prefix similaries causing bottlenecks in S3
+infra is interesting. git-annex keys have a common prefix, and have
+the hash at the end. So it could have a performance impact.
+
+But that info also seems out of date when it talks about 6-8 characters
+prefix length. And the rate limit has also been raised significantly, to
+3000-5000 ops/sec per prefix. See 
+<https://stackoverflow.com/questions/52443839/s3-what-exactly-is-a-prefix-and-what-ratelimits-apply>
+
+From that, it seems S3 does actually treat '/' as a prefix delimiter.
+(Based on a single not very clear email from Amazon support and not
+documented anywhere else..) So a single level of hash "directories"
+could increase the rate limit accordingly.
+
+If a git-annex exceeded those rate limits, it would start getting 503
+responses from S3, so it wouldn't slow down but would instead fail whatever
+operation it was doing. I can't recall anyone complaining of 503's from
+S3.
+"""]]
diff --git a/doc/forum/Using_integer_ranges_with_metadata.mdwn b/doc/forum/Using_integer_ranges_with_metadata.mdwn
new file mode 100644
index 0000000000..1cdbe50671
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata.mdwn
@@ -0,0 +1,40 @@
+I keep my movie collection in an annex. I recently wrote a python script that pulls information about each movie down from IMDB and stores it as metadata on the annexed file. One of the attributes I'm storing is `rating`. For instance, the metadata for my copy of Blade Runner looks like this:
+
+    $ git annex metadata blade_runner.mkv
+    metadata blade_runner.mkv
+      director="Ridley Scott"
+      director-lastchanged=2016-04-20@04-21-33
+      genre="Sci-Fi"
+      genre="Thriller"
+      genre-lastchanged=2016-04-20@04-21-33
+      lastchanged=2016-04-20@04-21-33
+      rating=8.2
+      rating-lastchanged=2016-04-20@04-21-33
+      runtime=117
+      runtime-lastchanged=2016-04-20@04-21-33
+      title="Blade Runner"
+      title-lastchanged=2016-04-20@04-21-33
+      year=1982
+      year-lastchanged=2016-04-20@04-21-33
+    ok
+
+I can now use the metadata to ask git annex to show me all movies with a rating of 8.2.
+
+    $ git annex find --metadata rating=8.2
+    blade_runner.mkv
+
+However, that isn't very useful. What I want to do is specify a range. For example, I want to ask git annex to show me all movies with a rating above 8:
+
+    $ git annex find --metadata rating=>8
+
+Or, show me all movies with a rating between 6 and 9
+
+    $ git annex find --metadata rating=>6 rating=<9
+
+Is something like this possible?
+
+I'd like to do something similar with the `year` attribute. Right now I can use metadata views to group movies by their release year, which is pretty neat.
+
+    $ git annex view "year=*"
+
+But I would also like to be able to give a range so that I could group movies by release decade, for example.
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_1_36298a679379e807892cd6af18ec1dd6._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_1_36298a679379e807892cd6af18ec1dd6._comment
new file mode 100644
index 0000000000..11795051a9
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_1_36298a679379e807892cd6af18ec1dd6._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-20T17:51:43Z"
+ content="""
+This is a great idea! So great that I got in the ol' time machine,
+set the dial for February 29th 2016, and convinced past-me to implement it
+then.
+
+(For some reason, past-me decided to make the syntax `field>=number` and
+`field<=number` instead of the syntax you suggested. He can be a bit of a
+stick in the mud with his own outdated ideas that he holds onto tightly.)
+"""]]
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_2_064e2c5706d1acc0f9e4576ff80407f7._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_2_064e2c5706d1acc0f9e4576ff80407f7._comment
new file mode 100644
index 0000000000..cc95e48166
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_2_064e2c5706d1acc0f9e4576ff80407f7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="pigmonkey"
+ subject="comment 2"
+ date="2016-04-20T18:20:43Z"
+ content="""
+Perfect. It works great! Thanks.
+
+Is this documented anywhere? I see it in the [release notes](https://git-annex.branchable.com/news/version_6.20160229/) now, but I didn't see anything mentioned in the metadata, metadata driven views or metadata design pages, or the git-annex-metadata man page. I'm not sure where I should look to see how else I can query the metadata.
+"""]]
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_3_c3ce727f93cce19db1f76de9f7216cee._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_3_c3ce727f93cce19db1f76de9f7216cee._comment
new file mode 100644
index 0000000000..bdd36a4341
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_3_c3ce727f93cce19db1f76de9f7216cee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-04-20T18:25:20Z"
+ content="""
+It's documented in [[git-annex-matching-options]] and
+[[git-annex-preferred-content]].
+"""]]
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_4_c3301d1b2b57994666947fd518fb9922._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_4_c3301d1b2b57994666947fd518fb9922._comment
new file mode 100644
index 0000000000..e08fb7d0ec
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_4_c3301d1b2b57994666947fd518fb9922._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="cstork"
+ subject="comment 4"
+ date="2016-04-21T14:35:46Z"
+ content="""
+Could you share your IMDB -> metadata script?  It would be interesting to see what works in practice.
+
+I was about to write something similar and why duplicate work? :-)
+"""]]
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_5_9d310fac003f1cd9e6ca9bc96a210def._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_5_9d310fac003f1cd9e6ca9bc96a210def._comment
new file mode 100644
index 0000000000..619eb3ce02
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_5_9d310fac003f1cd9e6ca9bc96a210def._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="pigmonkey"
+ subject="comment 5"
+ date="2016-04-21T16:57:03Z"
+ content="""
+Absolutely!
+
+<https://github.com/pigmonkey/metamovie>
+
+It's a quick hack job, but has been working so far. I haven't played around with [[tips/automatically adding metadata]] yet. The filename based search does the right thing 99% of the time (at least for my file names), but I still always want to confirm that it is using the right movie data, so I'm running the script manually and keeping it interactive.
+"""]]
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_6_ead2b08bf4631547c34486ce58559017._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_6_ead2b08bf4631547c34486ce58559017._comment
new file mode 100644
index 0000000000..785b0e4eb3
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_6_ead2b08bf4631547c34486ce58559017._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="cstork"
+ subject="comment 6"
+ date="2016-04-23T16:43:11Z"
+ content="""
+Thanks a lot!
+"""]]
diff --git a/doc/forum/Using_standard_groups_and_sync_to_preserve_history__58___--all_not_recognised.mdwn b/doc/forum/Using_standard_groups_and_sync_to_preserve_history__58___--all_not_recognised.mdwn
new file mode 100644
index 0000000000..f191503e3c
--- /dev/null
+++ b/doc/forum/Using_standard_groups_and_sync_to_preserve_history__58___--all_not_recognised.mdwn
@@ -0,0 +1,33 @@
+My copy of *git-annex* refuses to sync all, namely when I try it I get the following error
+
+    $ git annex sync --content --all
+    git-annex: unrecognized option `--all'
+
+    Usage: git-annex sync [REMOTE ...] [option ...]
+        --content  also transfer file contents
+
+    To see additional options common to all commands, run: git annex help options
+
+This contradicts the advice on [preferred content](http://git-annex.branchable.com/preferred_content/) set out under **difference: unused**, 
+and I cannot see any other options in my man page that would address the lack of this option.
+
+The problem I am trying to solve is that I wish to preserve all history on the backup drives.  Namely, if I do the following
+
+    touch test-of-annex-backup.txt
+    git annex add test-of-annex-backup.txt
+    git commit --message='test: Create empty test-of-annex-backup.txt file'
+    git annex edit test-of-annex-backup.txt
+    echo "This line creates version 2 of this file" > test-of-annex-backup.txt
+    git annex add test-of-annex-backup.txt
+    git commit --message='test: Create version 2 of test-of-annex-backup.txt'
+    git annex sync --content --all
+
+I expect to see 2 copies of `test-of-annex-backup.txt` be copied to each accessible annex repository in the `backup` group
+
+I tried googling for `"git annex sync --content --all"`, but I only find pages telling me that this is what I should use, and none saying the option has been deprecated.
+
+I am very confused, as this seems to me an almost stereotypical use of *git-annex*, and yet I cannot see how to do it
+
+thanks
+
+Andrew
diff --git a/doc/forum/Using_standard_groups_and_sync_to_preserve_history__58___--all_not_recognised/comment_1_c3dd239d4b5b372229f2cec42a8a6eb4._comment b/doc/forum/Using_standard_groups_and_sync_to_preserve_history__58___--all_not_recognised/comment_1_c3dd239d4b5b372229f2cec42a8a6eb4._comment
new file mode 100644
index 0000000000..935b46a01b
--- /dev/null
+++ b/doc/forum/Using_standard_groups_and_sync_to_preserve_history__58___--all_not_recognised/comment_1_c3dd239d4b5b372229f2cec42a8a6eb4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-25T19:28:03Z"
+ content="""
+It looks like the documentation is wrong; `git annex sync` has never
+supported `--all` or `--unused`. I've fixed the documentation. If you do
+need this, please file a todo item so I can remember to try to implement
+it. Should be doable, but not trivially so.
+"""]]
diff --git a/doc/forum/Using_standard_groups_and_sync_to_preserve_history__58___--all_not_recognised/comment_2_b76dd79aabe87ec717eea164aa965d74._comment b/doc/forum/Using_standard_groups_and_sync_to_preserve_history__58___--all_not_recognised/comment_2_b76dd79aabe87ec717eea164aa965d74._comment
new file mode 100644
index 0000000000..2b5a8672b2
--- /dev/null
+++ b/doc/forum/Using_standard_groups_and_sync_to_preserve_history__58___--all_not_recognised/comment_2_b76dd79aabe87ec717eea164aa965d74._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkWHj0RxNMfuwvFzo2d-V6vBKOYwW_Fnfk"
+ nickname="Andrew"
+ subject="Thanks for the clarification"
+ date="2015-03-07T03:00:14Z"
+ content="""
+I will post the todo, and in the meantime I can script a `git annex copy --unused` followed by a `git annex sync --content` to capture the full history in the archive
+
+regards
+
+Andrew
+"""]]
diff --git a/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn
new file mode 100644
index 0000000000..8d3c840246
--- /dev/null
+++ b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn
@@ -0,0 +1,5 @@
+I'm looking to use the Git-Annex Assistant to backup a single repository that is present on and synced between two computers (a home and a working computer). Ideally, each computer uses rsync.net for both of these service, while at the same time treating the cloud storage service as untrusted (so anything stored or tranferred through there is encrypted). Is it possible to do this using solely rsync.net (without the addition of some XMPP service)? According to the software, using shared encryption allows anyone with a clone of the repository to decrypt files on a remote, but the simplest way to make this clone seems to be to first clone to a removable drive, and then from the drive to the second computer (and then deleting the records of the clone to the drive). I'm unsure if by then setting up the backup at rsync.net for the second computer, whether the software will create a second backup that acts independently of the first, neglecting any syncing, or if it will recognize the backup as one of the same repository. I'm also unsure as to whether the software will even sync if the backup is recognized, or whether a tranfer repository at rsync.net is also necessary to complete the setup. Could you perhaps give me some advice on how to achieve this setup, or point me to some information that may help me along?
+
+(If the setup is unclear, I'm essentially trying to replicate something like SpiderOak with the Git-Annex Assistant, without using an XMPP service)
+
+[Edit: It may be easier to just use Git-Annex (no assistant), so that works too]
diff --git a/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service/comment_1_7070f6e7e05fba7686d8620d62906a83._comment b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service/comment_1_7070f6e7e05fba7686d8620d62906a83._comment
new file mode 100644
index 0000000000..07cc634340
--- /dev/null
+++ b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service/comment_1_7070f6e7e05fba7686d8620d62906a83._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-02T15:54:44Z"
+ content="""
+rsync.net alone is not sufficient, because it's only used for storing the (encrypted) contents of files, not for syncing the git repository, or finding out when there other computer has made a change to the repository.
+
+You can use rsync.net plus xmpp. However, xmpp is not encrypted when it passes through the xmpp server.
+
+A fully encrypted option is to install git-anex on a server accessible by ssh, and then use the assistant to set up an encrypted git repository on the server. No xmpp needed in this configuration.
+"""]]
diff --git a/doc/forum/Verification.mdwn b/doc/forum/Verification.mdwn
new file mode 100644
index 0000000000..cbce0b4085
--- /dev/null
+++ b/doc/forum/Verification.mdwn
@@ -0,0 +1,9 @@
+Hi,
+
+I have a simple Client Mac <> FullBackup on remote SSH <> Client On Mac setup which seems to work great.
+
+I have 2 questions :
+- Whenever a new file is created or changed it can takes a few hours until the second client gets the file. Is this normal ?
+- How Can I make sure, that all the files are on the FullBackup ?
+
+Many thank !
diff --git a/doc/forum/Verification/comment_1_d56818a8f5b3a94ecf5159c76f24768c._comment b/doc/forum/Verification/comment_1_d56818a8f5b3a94ecf5159c76f24768c._comment
new file mode 100644
index 0000000000..d9684d922d
--- /dev/null
+++ b/doc/forum/Verification/comment_1_d56818a8f5b3a94ecf5159c76f24768c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-27T18:51:52Z"
+ content="""
+Well, it depends on how big the files are, but taking a few hours to sync
+might indicate that your repositories are not immediately notifying
+one-another of changes. It might be falling back to polling every half
+an hour for new changes.
+
+You could fix that by setting up XMPP, or better, by installing git-annex
+5.20140421 or newer on the SSH server; then the clients would immediately
+notify when there are changes.
+
+You can find out if all files are present on the server by running
+`git annex find --not --in $server` on one of the clients. Any files
+it prints out have not been stored in the server.
+"""]]
diff --git a/doc/forum/Verification/comment_2_7df45d1e20a32458791603d5b9fe3dc4._comment b/doc/forum/Verification/comment_2_7df45d1e20a32458791603d5b9fe3dc4._comment
new file mode 100644
index 0000000000..c98a210b6a
--- /dev/null
+++ b/doc/forum/Verification/comment_2_7df45d1e20a32458791603d5b9fe3dc4._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Régis"
+ subject="comment 2"
+ date="2015-02-27T21:38:05Z"
+ content="""
+Thanks for this speedy answer !
+
+I have version 5.20150219 installed on all the clients and on the server.
+The ssh server is a gcrypt repository. Could this be the reason of the clients not being notificated of the  changes ??
+
+Also, in theory, some file on one of the repositories could get corrupted, deleted, whatever. How can I make the repo check if everything is like intended on the other repos ? 
+For example, I made a test renaming a file within the objects directory on the remote ssh server and ran git annex fchk, but it reported nothing...
+
+Many thanks again !
+"""]]
diff --git a/doc/forum/Verification/comment_3_74db3ec8b03f48912306e48b8d5f7242._comment b/doc/forum/Verification/comment_3_74db3ec8b03f48912306e48b8d5f7242._comment
new file mode 100644
index 0000000000..962707277e
--- /dev/null
+++ b/doc/forum/Verification/comment_3_74db3ec8b03f48912306e48b8d5f7242._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Régis"
+ subject="comment 3"
+ date="2015-02-28T18:33:27Z"
+ content="""
+Also, I noted a difference between encrypted (gcrypt) repos and unencrypted repos. The second ones have the other icon saying that it is live messaging. The encrypted one have a standard icon.
+Is it a technical limitation that encrypted repos can not live message ? And could it be the reason why the sync is not happening itself until i manually choose \"sync\" from the menu ?
+"""]]
diff --git a/doc/forum/Verification/comment_4_eb4d936a9bd577f58483b278ae5dc5f6._comment b/doc/forum/Verification/comment_4_eb4d936a9bd577f58483b278ae5dc5f6._comment
new file mode 100644
index 0000000000..f1d04e83f1
--- /dev/null
+++ b/doc/forum/Verification/comment_4_eb4d936a9bd577f58483b278ae5dc5f6._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-03-16T18:36:45Z"
+ content="""
+You can use `git annex fsck` to verify your repository contents.
+If you want to verify a local repository, the best thing to do is
+to run `git annex fsck` there. If you cannot do that, you can use
+`git annex fsck --from remoterepo --fast` to verify a remote. If you leave
+off the --fast it will download all file contents to completely verify
+them.
+
+I suggest you read git-annex's documentation, there is plenty of it about
+using git-annex fsck to verify repositories.
+"""]]
diff --git a/doc/forum/Verification/comment_5_c327c72ceced27920681d5f93bc256c8._comment b/doc/forum/Verification/comment_5_c327c72ceced27920681d5f93bc256c8._comment
new file mode 100644
index 0000000000..e07a572547
--- /dev/null
+++ b/doc/forum/Verification/comment_5_c327c72ceced27920681d5f93bc256c8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-03-16T18:39:01Z"
+ content="""
+The lack of "live messaging" for gcrypt repos is a bug. I'm fixing
+it now and the next version of git-annex will have remotedaemon
+properly supporting gcrypt repos.
+"""]]
diff --git a/doc/forum/Version_5_repo_with_git-annex_client_8.20211123___63__.mdwn b/doc/forum/Version_5_repo_with_git-annex_client_8.20211123___63__.mdwn
new file mode 100644
index 0000000000..1b29e5ea1c
--- /dev/null
+++ b/doc/forum/Version_5_repo_with_git-annex_client_8.20211123___63__.mdwn
@@ -0,0 +1,28 @@
+Hi, I need some client/server version advice. I've been keeping a git-annex repo for many years. It's currently centralized on a CentOS Linux release 7.9.2009 server, /usr/bin/git-annex is version **5.20140221** and has git 2.25.0 server-side. My new client machine is Debian testing Linux, where /usr/bin/git-annex is version **8.20211123**, and has git 2.35.1 client-side
+
+```
+server$ /usr/bin/git-annex version
+git-annex version: 5.20140221
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+```
+
+The /usr/bin/git clone command works fine ("Your branch is up to date with 'origin/master'."). But when I run **/usr/bin/git annex sync --content** (just like I do on other machines), I get a few errors like the following:
+
+```
+nothing to commit, working tree clean
+ok
+pull origin 
+ok
+get readme.md (from origin...) 
+  Transfer failed
+  Unable to access these remotes: origin
+  Maybe add some of these git remotes (git remote add ...):
+        0edb4d98-3f58-4114-be5d-2d7b5cb574d2 -- me@othermachine:~/people/me/awesome/code
+failed
+```
+
+It is not easy to install git-annex version 5 on the client, and if possible I'd rather not run such an old version. Should I expect a version 8 client to interoperate with a grand old version 5 repo with git-annex 5 on the server ?
+
+Thanks, Keith
diff --git a/doc/forum/Version_5_repo_with_git-annex_client_8.20211123___63__/comment_1_780fb88d5cfcde6e8a8b6f025be6a043._comment b/doc/forum/Version_5_repo_with_git-annex_client_8.20211123___63__/comment_1_780fb88d5cfcde6e8a8b6f025be6a043._comment
new file mode 100644
index 0000000000..ee2e384ce9
--- /dev/null
+++ b/doc/forum/Version_5_repo_with_git-annex_client_8.20211123___63__/comment_1_780fb88d5cfcde6e8a8b6f025be6a043._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-18T16:11:54Z"
+ content="""
+In version 8.20211028, git-annex dropped support for interoperating with
+remotes that have git-annex version 6.20180312 or older installed.
+
+You will need to upgrade git-annex on your server.
+(Or downgrade your client to a release slightly older than 8.20211028.)
+"""]]
diff --git a/doc/forum/View_for_locally_existing_files.mdwn b/doc/forum/View_for_locally_existing_files.mdwn
new file mode 100644
index 0000000000..31c92536de
--- /dev/null
+++ b/doc/forum/View_for_locally_existing_files.mdwn
@@ -0,0 +1,8 @@
+Hi,
+
+Is there a way to make a "view" that only shows me files that are locally existing (meaning: where the binary is present in the repo I am working on)?
+
+I had a look at documentation and the forum but I did not find anything fitting (I honestly assume that I overlooked it somewhere). To me views, vfilter and such do not appear to meet my needs since they are only working on metadata.
+
+Why do I need this?
+I am starting to manage my music collection with git annex. On most devices I only have a fraction of the globally available collection. I would like to see only those symlinks that actually lead to binary files. This way I would not to confuse music players with broken symlinks and know at a glance what I can actually listen to right now.
diff --git a/doc/forum/View_for_locally_existing_files/comment_1_8ede4c8f1ca48e34629c46a77ba01f11._comment b/doc/forum/View_for_locally_existing_files/comment_1_8ede4c8f1ca48e34629c46a77ba01f11._comment
new file mode 100644
index 0000000000..ed0a26d773
--- /dev/null
+++ b/doc/forum/View_for_locally_existing_files/comment_1_8ede4c8f1ca48e34629c46a77ba01f11._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2022-12-01T20:49:35Z"
+ content="""
+`git annex adjust --hide-missing`
+"""]]
diff --git a/doc/forum/View_for_locally_existing_files/comment_2_e8d7672850518f4859643a0ee40e57e1._comment b/doc/forum/View_for_locally_existing_files/comment_2_e8d7672850518f4859643a0ee40e57e1._comment
new file mode 100644
index 0000000000..07b04eec80
--- /dev/null
+++ b/doc/forum/View_for_locally_existing_files/comment_2_e8d7672850518f4859643a0ee40e57e1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="agschaid"
+ avatar="http://cdn.libravatar.org/avatar/7789d7511c5da25d71021be4ddb7fe18"
+ subject="comment 2"
+ date="2022-12-01T21:12:11Z"
+ content="""
+Thank you! That is simply perfect.
+"""]]
diff --git a/doc/forum/View_performance_with_7__44__000_files.mdwn b/doc/forum/View_performance_with_7__44__000_files.mdwn
new file mode 100644
index 0000000000..21491c77f5
--- /dev/null
+++ b/doc/forum/View_performance_with_7__44__000_files.mdwn
@@ -0,0 +1,26 @@
+I've imported about half of my photos into an annex on an external HDD,
+using metadata extensively for EXIF info, including place names.
+
+Checking out a new view is slower than I expected, at ~6 minutes.
+Is this expected behavior, am I pushing the limits of file count already?
+
+Is there anything I can do to speed things up?
+
+    % ls -1 | wc -l
+        7050
+    
+    % git branch -vv
+      git-annex                      4e590d4 update
+    * master                         985ba54 add jen's phone backups
+      views/Year=_;Month=_;Address=_ 795a58b refs/heads/views/Year=_;Month=_;Address=_
+    
+    % /usr/bin/time -p git annex view "Year=*" "Address=*" 
+    view  (searching...)
+    
+    Checking out files: 100% (12789/12789), done.
+    Switched to branch 'views/Year=_;Address=_'
+    ok
+    real       376.80
+    user        17.98
+    sys          9.66
+
diff --git a/doc/forum/View_performance_with_7__44__000_files/comment_1_e45ea752100d09d29efb6136a722eab3._comment b/doc/forum/View_performance_with_7__44__000_files/comment_1_e45ea752100d09d29efb6136a722eab3._comment
new file mode 100644
index 0000000000..cf6f140b2a
--- /dev/null
+++ b/doc/forum/View_performance_with_7__44__000_files/comment_1_e45ea752100d09d29efb6136a722eab3._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmvzzyDA8uXFz8yokeCrepbh8PwWe_WrjE"
+ nickname="Michael"
+ subject="debug output"
+ date="2014-06-16T14:17:06Z"
+ content="""
+So after looking for a debug flag, I see that it's spending all its time in cat-file, which I guess is probably not a surprise:
+
+    % /usr/bin/time -p git annex view \"Year=*\" \"Address=*\" -d
+    view  [2014-06-16 06:29:12 PDT] read: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"symbolic-ref\",\"HEAD\"]
+    [2014-06-16 06:29:12 PDT] read: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"show-ref\",\"refs/heads/master\"]
+    [2014-06-16 06:29:12 PDT] read: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"symbolic-ref\",\"HEAD\"]
+    [2014-06-16 06:29:12 PDT] read: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"show-ref\",\"refs/heads/master\"]
+    (searching...)
+    [2014-06-16 06:29:12 PDT] read: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"/Volumes/Four TB Backup/Photos\"]
+    [2014-06-16 06:29:12 PDT] feed: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"update-index\",\"-z\",\"--index-info\"]
+    [2014-06-16 06:29:12 PDT] chat: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+    [2014-06-16 06:29:12 PDT] read: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"show-ref\",\"git-annex\"]
+    [2014-06-16 06:29:12 PDT] read: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2014-06-16 06:29:12 PDT] read: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"log\",\"refs/heads/git-annex..4e590d433e01886e2823c3316d18b7e3cbafe227\",\"--oneline\",\"-n1\"]
+    [2014-06-16 06:29:12 PDT] chat: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"cat-file\",\"--batch\"]
+    [2014-06-16 06:34:54 PDT] read: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"write-tree\"]
+    [2014-06-16 06:34:55 PDT] chat: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"commit-tree\",\"c0fd1ea9ccae70a7353a2e787089b88115a42b7a\"]
+    [2014-06-16 06:34:55 PDT] call: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"update-ref\",\"refs/heads/views/Year=_;Address=_\",\"249c37d78e45d1fccfcb00f40337e05cb69fb64c\"]
+    
+    [2014-06-16 06:34:55 PDT] call: git [\"--git-dir=/Volumes/Four TB Backup/Photos/.git\",\"--work-tree=/Volumes/Four TB Backup/Photos\",\"checkout\",\"views/Year=_;Address=_\"]
+    Checking out files: 100% (12789/12789), done.
+    Switched to branch 'views/Year=_;Address=_'
+    ok
+    real       362.14
+    user        18.16
+    sys          7.70
+
+"""]]
diff --git a/doc/forum/View_performance_with_7__44__000_files/comment_2_b1942eed65e9b5c046095a094191a38c._comment b/doc/forum/View_performance_with_7__44__000_files/comment_2_b1942eed65e9b5c046095a094191a38c._comment
new file mode 100644
index 0000000000..91259f3351
--- /dev/null
+++ b/doc/forum/View_performance_with_7__44__000_files/comment_2_b1942eed65e9b5c046095a094191a38c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 2"
+ date="2014-06-16T17:52:34Z"
+ content="""
+View's don't scale to lots of files yet. Discussed in [[design/caching_database]]
+"""]]
diff --git a/doc/forum/View_performance_with_7__44__000_files/comment_3_e6e19339c9d72cf8eaae32ef4269e850._comment b/doc/forum/View_performance_with_7__44__000_files/comment_3_e6e19339c9d72cf8eaae32ef4269e850._comment
new file mode 100644
index 0000000000..01ac676cbf
--- /dev/null
+++ b/doc/forum/View_performance_with_7__44__000_files/comment_3_e6e19339c9d72cf8eaae32ef4269e850._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmvzzyDA8uXFz8yokeCrepbh8PwWe_WrjE"
+ nickname="Michael"
+ subject="comment 3"
+ date="2014-06-16T18:19:20Z"
+ content="""
+@joeyh, thanks - is that code all up to date here: https://github.com/joeyh/git-annex/tree/database ?
+
+I'd be interested in helping test it.
+"""]]
diff --git a/doc/forum/View_special_remote_information__63__.mdwn b/doc/forum/View_special_remote_information__63__.mdwn
new file mode 100644
index 0000000000..31382040bf
--- /dev/null
+++ b/doc/forum/View_special_remote_information__63__.mdwn
@@ -0,0 +1 @@
+How is it possible to view the URL etc of a special remote with git annex? I checked out a git annex repository and would like to know where the files where fetched from. 
diff --git a/doc/forum/View_special_remote_information__63__/comment_1_7c106e0679890f7279c73b5c52d648e2._comment b/doc/forum/View_special_remote_information__63__/comment_1_7c106e0679890f7279c73b5c52d648e2._comment
new file mode 100644
index 0000000000..0a3914b3e4
--- /dev/null
+++ b/doc/forum/View_special_remote_information__63__/comment_1_7c106e0679890f7279c73b5c52d648e2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-16T18:00:33Z"
+ content="""
+Recent versions of git-annex have expanded `git annex info $remote`
+to be able to show some info for special remotes. What is
+shown depends on the type of remote. For example, it will show
+the bucket used for a S3 remote, or the url used for a WebDAV remote.
+"""]]
diff --git a/doc/forum/WARNING__58___linker__58__git-annex_has_text_relocations.mdwn b/doc/forum/WARNING__58___linker__58__git-annex_has_text_relocations.mdwn
new file mode 100644
index 0000000000..2d9ee1324f
--- /dev/null
+++ b/doc/forum/WARNING__58___linker__58__git-annex_has_text_relocations.mdwn
@@ -0,0 +1,7 @@
+I have configured git-annex on my Nexus 5. Even though it works fantastic, it shows some warning messages.
+
+1: 'git-annex sync' :  WARNING: linker: git-annex has text relocations. This is wasting memory and is a security risk. Please fix.
+
+2: 'git log': error: cannot run less. No such file or directory.
+
+Both the commands will work has expected with these warnings. What could be the issue here.
diff --git a/doc/forum/WARNING__58___linker__58__git-annex_has_text_relocations/comment_1_fee360353f0b46aab6ee7a902c0837bb._comment b/doc/forum/WARNING__58___linker__58__git-annex_has_text_relocations/comment_1_fee360353f0b46aab6ee7a902c0837bb._comment
new file mode 100644
index 0000000000..8d9af9624e
--- /dev/null
+++ b/doc/forum/WARNING__58___linker__58__git-annex_has_text_relocations/comment_1_fee360353f0b46aab6ee7a902c0837bb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.146"
+ subject="comment 1"
+ date="2014-03-05T20:38:03Z"
+ content="""
+<http://stackoverflow.com/questions/20141538/mylib-so-has-text-relocations-this-is-wasting-memory-and-is-a-security-risk-pl>  
+Says that should have been fixed in ndk-r8c's gcc, but git-annex is already built with ndk-r9b. It might be though, that the llvm compiler still has the problem. In any case, I doubt there is a real security issue here, it's probably just a binary exploit hardening thing.
+
+As for the git log, git users the less pager by default, but of course it's not necessary and so not included on Android. You can `git config core.pager cat` to get around this.
+"""]]
diff --git a/doc/forum/Walkthrough_does_not_work_for_me__44___what_am_i_doing_wrong__63__.mdwn b/doc/forum/Walkthrough_does_not_work_for_me__44___what_am_i_doing_wrong__63__.mdwn
new file mode 100644
index 0000000000..c6cb35912f
--- /dev/null
+++ b/doc/forum/Walkthrough_does_not_work_for_me__44___what_am_i_doing_wrong__63__.mdwn
@@ -0,0 +1,16 @@
+I'm trying to use git-annex as a dropbox-replacement, but I'm hitting unexpected things although I'm doing exactly what I see in the walkthrough screencast and/or the walkthrough commands. I'm using Ubuntu 13.10, installed git-annex with apt-get. It is version 4.20130815.
+
+1) I launch the webapp and create an ~/annex folder as my initial repo. I copy some small text files in it, I see in webapp that they are added. 
+2) I add a new "Removable Storage" repo, in my usb drive. I do not touch any other settings, leave it as is. (ie in transfer group for example). It is successfully added to the repo list and I see sync complete and files synced on the webapp.
+3) When I check the contents of the usb disk annex folder, I see the following, while I was expecting to see the files I synced instead.
+
+emre@emrenb:~$ ls /media/emre/348B-78F0/annex/
+annex  branches  config  description  HEAD  hooks  info  objects  refs
+
+However, I expect the below which is the content of my ~/annex folder:
+emre@emrenb:~$ ls annex/
+unison-sync.log  unison-1.log  unison-2.log  unison.log
+
+In the walkthrough video, when Joey adds a USB storage, the filenames & thir contents sync to the usb drive. Why doesn't it work for me? 
+
+Note that I tried also android app and also the zipped tarball build. Same result, I never see actual files. 
diff --git a/doc/forum/Walkthrough_does_not_work_for_me__44___what_am_i_doing_wrong__63__/comment_1_cdac15fec6fc41d5487b7f653fa718a4._comment b/doc/forum/Walkthrough_does_not_work_for_me__44___what_am_i_doing_wrong__63__/comment_1_cdac15fec6fc41d5487b7f653fa718a4._comment
new file mode 100644
index 0000000000..437e2ecdc1
--- /dev/null
+++ b/doc/forum/Walkthrough_does_not_work_for_me__44___what_am_i_doing_wrong__63__/comment_1_cdac15fec6fc41d5487b7f653fa718a4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3HGoDpnOPob5jOjvIootmkve1-nCpRiI"
+ nickname="Kalle"
+ subject="Default removable storage repo not readable without git annex"
+ date="2013-10-21T08:50:50Z"
+ content="""
+Hi,
+
+Sounds to me you are expecting the files to be readable by a filemanager? By default a removable drive repo is only readable by git-annex.
+
+The standard use case is to move files between computers with git-annex installed. I agree this is not what you´d expect.
+
+Read <http://git-annex.branchable.com/forum/USB_backup_with_files_visible/> and the last post of <http://git-annex.branchable.com/forum/Can__39__t_get_git-annex_merge_to_work_from_git_hook/> for more info.
+"""]]
diff --git a/doc/forum/Walkthrough_does_not_work_for_me__44___what_am_i_doing_wrong__63__/comment_2_82050b7dc367ca5968ab0306db9bd7e3._comment b/doc/forum/Walkthrough_does_not_work_for_me__44___what_am_i_doing_wrong__63__/comment_2_82050b7dc367ca5968ab0306db9bd7e3._comment
new file mode 100644
index 0000000000..edcc49a35d
--- /dev/null
+++ b/doc/forum/Walkthrough_does_not_work_for_me__44___what_am_i_doing_wrong__63__/comment_2_82050b7dc367ca5968ab0306db9bd7e3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 2"
+ date="2013-10-21T22:29:14Z"
+ content="""
+Kalle is right (I seem to keep saying that, Kalle!)
+
+Following the walkthrough commands will get you a non-bare git repository on a removable drive, and you can run \"git annex sync\" in there periodically and see all the files in your repository on the removable drive. The webapp does not make that kind of repository though, and in the screencast I'm showing the normal behavior of the webapp.
+"""]]
diff --git a/doc/forum/Walkthrough_for_direct_mode__63__.mdwn b/doc/forum/Walkthrough_for_direct_mode__63__.mdwn
new file mode 100644
index 0000000000..b3fae29447
--- /dev/null
+++ b/doc/forum/Walkthrough_for_direct_mode__63__.mdwn
@@ -0,0 +1 @@
+Hello Joey, I would be very much interested in a walkthrough for direct mode, as detailed as the one currently published. I see the comments in the current walkthrough on some differences to direct mode, but to me it is not obvious what best practices for git-annex use would be in direct mode, with and without the assistant. For a mix of Linux, OS X and Windows installations in the homes, it may also be interesting to see how to best set up the individual machines. Many thanks - 
diff --git a/doc/forum/Want_to_stop_using_Git-Annex.mdwn b/doc/forum/Want_to_stop_using_Git-Annex.mdwn
new file mode 100644
index 0000000000..a076cf1b06
--- /dev/null
+++ b/doc/forum/Want_to_stop_using_Git-Annex.mdwn
@@ -0,0 +1,9 @@
+Hi
+
+I created a git annex repo in one of my drives. But now all my files have turned into symbolic links.
+I need to remove the git repo and get my files back. How can I do that.
+
+Some of the softwares am using will not follow symbolic links, so need put the files back properly as soon as  possible.
+
+Please help.
+Thank you in advance :)
diff --git a/doc/forum/Want_to_stop_using_Git-Annex/comment_1_32e37515bd4f5d22ff9aedd3c9d98046._comment b/doc/forum/Want_to_stop_using_Git-Annex/comment_1_32e37515bd4f5d22ff9aedd3c9d98046._comment
new file mode 100644
index 0000000000..9937e5d0ca
--- /dev/null
+++ b/doc/forum/Want_to_stop_using_Git-Annex/comment_1_32e37515bd4f5d22ff9aedd3c9d98046._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://ypid.wordpress.com/"
+ ip="213.153.84.215"
+ subject="Direct mode"
+ date="2014-06-27T07:36:40Z"
+ content="""
+Hi
+
+[[direct_mode/]] is your friend.
+"""]]
diff --git a/doc/forum/Want_to_stop_using_Git-Annex/comment_2_e29e6d052ef3677ad7d5615721f3fe33._comment b/doc/forum/Want_to_stop_using_Git-Annex/comment_2_e29e6d052ef3677ad7d5615721f3fe33._comment
new file mode 100644
index 0000000000..0eddeb201c
--- /dev/null
+++ b/doc/forum/Want_to_stop_using_Git-Annex/comment_2_e29e6d052ef3677ad7d5615721f3fe33._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 2"
+ date="2014-07-02T17:04:29Z"
+ content="""
+git annex uninit
+"""]]
diff --git a/doc/forum/Wanted___39__present__39___makes_sync_slow_on_thin_copy_of_large_annex..mdwn b/doc/forum/Wanted___39__present__39___makes_sync_slow_on_thin_copy_of_large_annex..mdwn
new file mode 100644
index 0000000000..69ad9a51e2
--- /dev/null
+++ b/doc/forum/Wanted___39__present__39___makes_sync_slow_on_thin_copy_of_large_annex..mdwn
@@ -0,0 +1,22 @@
+I have a large annex (~200k files) on a server with a thin checkout on my laptop.
+
+The scenario I was trying to achieve is to by default have:
+
+- All files always present on the server
+- Only files added locally/pulled manually on the laptop
+
+It seems this can be achieved by setting preferred content to `present` on the laptop, required `*` on the server and then regularly calling
+
+```
+$ git annex sync --content
+```
+
+However, this is very slow (compared to --no-content, which takes seconds), it seems to iterate the whole repository for presence.
+
+I'm not too familiar with git-annex's internals, but it seems finding a sparse set of present files is already implemented efficiently:
+
+```
+$ time git annex find --in=here
+```
+
+takes 5 seconds to complete on the laptop.
diff --git a/doc/forum/Wanted_content_based_on_date_added.mdwn b/doc/forum/Wanted_content_based_on_date_added.mdwn
new file mode 100644
index 0000000000..12c12e892e
--- /dev/null
+++ b/doc/forum/Wanted_content_based_on_date_added.mdwn
@@ -0,0 +1,12 @@
+Hi,
+
+I was wondering whether it was possible to configure git annex in a way, that new content is held in a specific repository until it is considered old.
+
+I found that "git config annex.genmetadata true" creates year and month tags in the metadata. However, creating the wanted expression poses a problem. Afaik there is no way to access the current year/month in a wanted expression and no way to do arithmetic in a wanted expression. Furthermore, I do not know, when the assistant checks wanted expressions for matches? I assume it does so only when something changes in git or when the wanted expressions change but not in regular intervals?
+
+I guess I could whip up a cronjob that changes the wanted expression every month and do the calculations outside of git annex but this seems somehow wrong. 
+
+Is this a problem other users share or maybe have already solved?
+
+Cheers,
+Marek
diff --git a/doc/forum/Wanted_content_based_on_date_added/comment_1_af2a6e6cba4cdfe24e9ee2c819a007eb._comment b/doc/forum/Wanted_content_based_on_date_added/comment_1_af2a6e6cba4cdfe24e9ee2c819a007eb._comment
new file mode 100644
index 0000000000..a10b909b30
--- /dev/null
+++ b/doc/forum/Wanted_content_based_on_date_added/comment_1_af2a6e6cba4cdfe24e9ee2c819a007eb._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-20T16:07:52Z"
+ content="""
+The assistant re-checks preferred content as rarely as it can get away with,
+since that can be an expensive process. Basically, it checks it when
+starting up, and when a remote is added or edited, and when it detects
+certian kinds of divergences between the local repository and a remote.
+
+I agree that it's not possible to express an expiry using a preferred
+content expression.
+
+What would work better is if you can move the old files to some other
+directory via a cron job or whatever means. Then it's easy to configure it
+not to want files in that directory.
+"""]]
diff --git a/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429.mdwn b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429.mdwn
new file mode 100644
index 0000000000..6f88a9c3b2
--- /dev/null
+++ b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429.mdwn
@@ -0,0 +1,23 @@
+# Warning: linker on each command in Android 8.20210429
+
+Recently (about 2 or 3 weeks ago) each 'git annex <command>' in Termux for Android throws multiple warnings. The exact warning message is this:
+
+`WARNING: linker: Warning: failed to find generated linker configuration from "/linkerconfig/ld.config.txt"`
+
+The amount of warnings depends on the command:
+
+* `$ git annex --version` --> 2 warnings
+* `git annex status` --> 3 warnings
+* `$ git annex sync origin` --> 80 warnings
+
+The issue was already raised in the Termux matrix/discord, as i suspected it might by coming from Termux. They suspect it is a vendor specific problem, although one of them could also reproduce it via `git-annex-install` on a pixel4a.
+
+The warning stems from the function `get_ld_config_file_path` in linker.cpp as part of the Android source code. I could not find any call to this in git-annex's source code, so it seems like it is called through some dependency.
+
+As this issue greatly affects the usability of git-annex on Android, i would very much appreciate any work to solve this (if possible, i.e. if the issue is even caused by git-annex).
+
+## System description
+* Samsung Galaxy S20 FE (SM-G780G) with latest Android (12) from Samsung
+* Termux installed via F-Droid version 0.118.0
+* git-annex version 8.20210429-g538780eba
+* LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec.so
diff --git a/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_1_02c38a5dc1c2213dd5f12c4b7fb0c72e._comment b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_1_02c38a5dc1c2213dd5f12c4b7fb0c72e._comment
new file mode 100644
index 0000000000..7dd95a24f5
--- /dev/null
+++ b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_1_02c38a5dc1c2213dd5f12c4b7fb0c72e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-23T15:21:12Z"
+ content="""
+I notice this warning is mentioned here:
+<https://github.com/termux/proot-distro/blob/master/README.md>
+
+git-annex does use proot on android, that is necessary for some locking
+system calls to work, which Android for some reason blocks otherwise.
+"""]]
diff --git a/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_2_02e5631245348bcef541360b5ca0e9e5._comment b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_2_02e5631245348bcef541360b5ca0e9e5._comment
new file mode 100644
index 0000000000..a5d7eefde7
--- /dev/null
+++ b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_2_02e5631245348bcef541360b5ca0e9e5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="moortgat-pick"
+ avatar="http://cdn.libravatar.org/avatar/4abd6c7dedbeec25547cc4a7b26f702a"
+ subject="comment 2"
+ date="2022-02-24T09:41:44Z"
+ content="""
+Good catch, this was also mentioned by the termux community. As i understood it, proot is used for installing things in termux. However, the warnings occur during runtime in git-annex. Could proot still be the cause?
+"""]]
diff --git a/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_3_12c9af06c1473de6740b782ca42d6a5a._comment b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_3_12c9af06c1473de6740b782ca42d6a5a._comment
new file mode 100644
index 0000000000..e40a72c7c8
--- /dev/null
+++ b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_3_12c9af06c1473de6740b782ca42d6a5a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-02-24T16:28:16Z"
+ content="""
+git-annex runs inside proot on android, so each time it (or the git bundled
+with it) is shipped, proot prints this warning.
+"""]]
diff --git a/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_4_daa8522e3be6a0563d7cd107e79577b8._comment b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_4_daa8522e3be6a0563d7cd107e79577b8._comment
new file mode 100644
index 0000000000..fd550ed0c8
--- /dev/null
+++ b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_4_daa8522e3be6a0563d7cd107e79577b8._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="anamyk"
+ avatar="http://cdn.libravatar.org/avatar/2604c4a7a2c85eaab0fb26adda0f0c35"
+ subject="comment 4"
+ date="2022-02-28T18:13:29Z"
+ content="""
+I have the same issue.
+
+@joey Does 'shipped' mean only upon git-annex installation on termux or each time I run a command? 
+Because I do get this warning several times during runtime, each time I run a git annex command.
+
+It helps to pinpoint the error to proot, but on their [git](https://github.com/termux/proot-distro) they talk about this warning occurring only during installation, not several time during use. 
+
+I tried:
+1. installing proot specifically in termux with `pkg install proot-distro`: -> installed two new packages, but warning still there
+2. new git annex install on termux:
+    - `$ pkg up`
+    - `$ source git-annex-install`
+    - saw the aforementioned linker warning once
+    - when e.g. using `$ git annex sync origin` the warning still shows up 
+
+Next steps to try:
+1. new termux install on android
+2. try older termux version 
+
+Any other tips/ideas how to fix this?
+"""]]
diff --git a/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_5_32c3cae8fb69c42747bb3ec4f3926dfb._comment b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_5_32c3cae8fb69c42747bb3ec4f3926dfb._comment
new file mode 100644
index 0000000000..9ac129497b
--- /dev/null
+++ b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_5_32c3cae8fb69c42747bb3ec4f3926dfb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anamyk"
+ avatar="http://cdn.libravatar.org/avatar/2604c4a7a2c85eaab0fb26adda0f0c35"
+ subject="comment 5"
+ date="2022-03-01T22:52:50Z"
+ content="""
+linker Warning also exists on termux version 0.117
+"""]]
diff --git a/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_6_95e16558f7010627ef4136043f63b937._comment b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_6_95e16558f7010627ef4136043f63b937._comment
new file mode 100644
index 0000000000..09dbec5506
--- /dev/null
+++ b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_6_95e16558f7010627ef4136043f63b937._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 6"
+ date="2022-03-05T21:46:22Z"
+ content="""
+Try nix-on-droid. It also uses proot (for everything actually) but Nix has an entirely different linking model to traditional distributions.
+
+Just open `nix-shell -p git git-annex` or add those two to your `environment.packages` in `~/.config/nixpkgs/nix-on-droid.nix` and then `nix-on-droid switch`. (Using `nix-env` is also possible but I wouldn't recommend it.)
+"""]]
diff --git a/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_7_733131f7608bc0309c034a954f297275._comment b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_7_733131f7608bc0309c034a954f297275._comment
new file mode 100644
index 0000000000..12bbbb9369
--- /dev/null
+++ b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_7_733131f7608bc0309c034a954f297275._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-03-07T16:09:41Z"
+ content="""
+@Atemu great tip! I had seen nix-on-droid and wondered about it.
+
+I have added some instructions based on your comment
+to [[/Android]].
+
+Looks like `git-annex webapp` does not work in nix-on-droid,
+because it cannot open a web page. Perhaps there is some way to
+do that; on termux git-annex uses xdg-open, but I tried it on nix-on-droid
+and it does not work. For now I documented nix-on-droid as an alternative
+for users who want to use git-annex at the command line.
+"""]]
diff --git a/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_8_c73d26803fcc932edd7049efd0318aab._comment b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_8_c73d26803fcc932edd7049efd0318aab._comment
new file mode 100644
index 0000000000..8745f9883e
--- /dev/null
+++ b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_8_c73d26803fcc932edd7049efd0318aab._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="anamyk"
+ avatar="http://cdn.libravatar.org/avatar/2604c4a7a2c85eaab0fb26adda0f0c35"
+ subject="comment 8"
+ date="2022-03-08T07:49:38Z"
+ content="""
+Thank you for the tip @Atemu. I will try that out.  
+
+In the meantime (and since [termux-proot-distro-devs say the warning is harmless](https://github.com/termux/proot-distro/blob/master/README.md#known-issues)), I managed to filter out only the aforementioned \"WARNING: linker:\"... from the cli output:  
+`$ git annex <command> 2> >(grep -v \"WARNING: linker:\" >&2)`  
+or as an alias in shellrc   
+`alias ga = 'git annex $1 2> >(grep -n \"WARNING: linker:\" >&2)'`
+"""]]
diff --git a/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_9_3eb65e0d204832d7d8700a85b3f4e51e._comment b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_9_3eb65e0d204832d7d8700a85b3f4e51e._comment
new file mode 100644
index 0000000000..acc4e4e815
--- /dev/null
+++ b/doc/forum/Warning__58___linker_on_each_command_Android_8.20210429/comment_9_3eb65e0d204832d7d8700a85b3f4e51e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anamyk"
+ avatar="http://cdn.libravatar.org/avatar/2604c4a7a2c85eaab0fb26adda0f0c35"
+ subject="comment 9"
+ date="2022-03-08T08:11:16Z"
+ content="""
+FYI I raised an issue over on [termux-proot-github](https://github.com/termux/proot-distro/issues/201) some suggested to run proot in isolated mode. But I dont know how to do that using git annex, since in cli I never acutually come in contact with the `proot` commands. But maybe that give some more inside.
+"""]]
diff --git a/doc/forum/Watch__47__assistant__47__webapp_documentation.mdwn b/doc/forum/Watch__47__assistant__47__webapp_documentation.mdwn
new file mode 100644
index 0000000000..3d185ba800
--- /dev/null
+++ b/doc/forum/Watch__47__assistant__47__webapp_documentation.mdwn
@@ -0,0 +1,12 @@
+Hello,
+
+I'm not sure about the differences and interactions between watch / assistant / webapp / direct mode. I think I figured the following out, can someone confirm this, and perhaps a few words to the documentation / man page?
+
+- git annex watch uses inotify to find new files, and runs git annex add on them (it does not do regular git add)
+- git annex assistant does the same as watch, but also runs git annex sync for each new file (does it also enable direct mode?)
+- git annex webapp does the same as assistant, and also starts a webapp (in my case it immediately started sending files to origin, without asking for confirmation, which was surprising, I guess this is because I have * annex.numcopies=2 set, and there was only one copy. Still I interpreted the documentation as if it would only show me an interface, not start doing things right away.)
+
+Do these commands do anything else than what I described above?
+
+best regards,
+Tom
diff --git a/doc/forum/Watch__47__assistant__47__webapp_documentation/comment_1_adb377589dbae7fc91001df235c6b48e._comment b/doc/forum/Watch__47__assistant__47__webapp_documentation/comment_1_adb377589dbae7fc91001df235c6b48e._comment
new file mode 100644
index 0000000000..556cf4f9b8
--- /dev/null
+++ b/doc/forum/Watch__47__assistant__47__webapp_documentation/comment_1_adb377589dbae7fc91001df235c6b48e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.125"
+ subject="comment 1"
+ date="2013-02-07T18:12:17Z"
+ content="""
+Most of this is explained pretty well on the [[man page|git-annex]]. 
+
+`git annex webapp` doesn't do anything on its own, other than start the assistant if it is not already running, and point your browser at its built-in webapp. Starting the assistant manually will always have the same effect as opening the webapp.
+
+The assistant syncs files as configured by the preferred content settings of repositories. There's an interface to disable this syncing in the webapp, or change the setting to something that doesn't prefer all content be synced to a repository. This syncing of content is different from `git annex sync`, which only syncs git repository data. It's more like running `git annex copy --auto`
+
+The assistant enables direct mode when a new repository is created (using the webapp). It does not enable direct mode when run in an existing repository.
+"""]]
diff --git a/doc/forum/Way_to_add_file_in_other_directory_without_change__63__.mdwn b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__.mdwn
new file mode 100644
index 0000000000..33b4165131
--- /dev/null
+++ b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__.mdwn
@@ -0,0 +1,14 @@
+Hi, 
+I am trying to use annex, but couldn't find a way. It will be very
+helpful if anyone can help.
+
+I have NAS mounted on specific directory /mnt/nas/ 
+Suppose whole directory in it is READ-ONLY and keep the file, structure as it is now.
+
+I want to "annex add" files in that directory like 
+git annex addurl file:///mnt/nas/a.mp4 
+
+But it seems addurl is only for http/https and "directory special remote" have to change the whole structure of the directory.
+Is there any alternative I can try?
+
+Thanks.
diff --git a/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_1c324fdc46fe9db3778bf21d9fbdd021._comment b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_1c324fdc46fe9db3778bf21d9fbdd021._comment
new file mode 100644
index 0000000000..6096d7abf3
--- /dev/null
+++ b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_1c324fdc46fe9db3778bf21d9fbdd021._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 2"
+ date="2023-01-01T13:28:46Z"
+ content="""
+Hi! Take a look at  `git annex import` and its various  options, it sounds like that's what you're after.
+"""]]
diff --git a/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_9d18e0752ae4b1ded9611759fbe2eeec._comment b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_9d18e0752ae4b1ded9611759fbe2eeec._comment
new file mode 100644
index 0000000000..4e9ce6695f
--- /dev/null
+++ b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_2_9d18e0752ae4b1ded9611759fbe2eeec._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="acadx0@9d7ca00c5a85a700a7209ab4fc2505189ded1aa3"
+ nickname="acadx0"
+ avatar="http://cdn.libravatar.org/avatar/b108d0f7ce179702be9003ca890a0131"
+ subject="try 2"
+ date="2023-01-01T04:00:54Z"
+ content="""
+Okay I got git annex addurl file:/// working with this config.
+
+```
+[annex \"security\"]
+	allowed-url-schemes = http https file
+	allowed-http-addresses = all
+```
+
+But it copies the file to local directory, is there a way to make it 
+just calculate checksum without copying(downloading) it?
+
+Or if there's just alternative way please let me know.
+"""]]
diff --git a/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_3_61841267c85651158652b20b137fb5fb._comment b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_3_61841267c85651158652b20b137fb5fb._comment
new file mode 100644
index 0000000000..7ccf9c0c34
--- /dev/null
+++ b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_3_61841267c85651158652b20b137fb5fb._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="acadx0@9d7ca00c5a85a700a7209ab4fc2505189ded1aa3"
+ nickname="acadx0"
+ avatar="http://cdn.libravatar.org/avatar/b108d0f7ce179702be9003ca890a0131"
+ subject="hmm"
+ date="2023-01-01T16:49:37Z"
+ content="""
+thanks, but It seems git annex import is just same as 
+
+```
+cd ~/annex/
+cp /mnt/nas/FILE FILE
+git annex add FILE
+
+or
+
+git annex addurl file:///mnt/nas/FILE
+```
+
+Is there a way to avoid copying file when trying to add file in annex repository, but do all the required operations like checksum calculation (as it is already accessible in local filesystem through nas)
+"""]]
diff --git a/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_4_f414a1d2c54eda4602d224a937d413b7._comment b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_4_f414a1d2c54eda4602d224a937d413b7._comment
new file mode 100644
index 0000000000..3753b32f2a
--- /dev/null
+++ b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_4_f414a1d2c54eda4602d224a937d413b7._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-01-02T18:54:55Z"
+ content="""
+This is a job for a directory special remote with importtree=yes
+
+	git-annex initremote nas type=directory directory=/mnt/nas encryption=none importtree=yes
+	git-annex import master --from nas --no-content
+	git merge --allow-unrelated-histories nas/master
+
+As shown this will merge all files in /mnt/nas into your master branch,
+without downloading the content. You can `git-annex get` files from there
+later. It's also possible to import the files into a subdirectory, see
+[[git-annex-import]]. 
+
+If you want to only add a single file, you can replace the 
+`git merge` with something else, or configure the preferred content
+expression of the remote to only match that file.
+"""]]
diff --git a/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_5_8290c580d2788dbefb4e41cb9671eecb._comment b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_5_8290c580d2788dbefb4e41cb9671eecb._comment
new file mode 100644
index 0000000000..fb52d7871e
--- /dev/null
+++ b/doc/forum/Way_to_add_file_in_other_directory_without_change__63__/comment_5_8290c580d2788dbefb4e41cb9671eecb._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="aca"
+ avatar="http://cdn.libravatar.org/avatar/b108d0f7ce179702be9003ca890a0131"
+ subject="thanks"
+ date="2023-01-25T14:01:08Z"
+ content="""
+Thanks joey. This is almost close to what I wanted. 
+But I wanted to naviagate and open the file without \"annex get\" the content.
+When I add file in this way, dead symbolic link is created and it would end like  
+
+```
+a.mp4 -> .git/annex/objects/w6/X8/***.mp4/***.mp4
+```
+
+It would be great if it can be something like this
+
+```
+a.mp4 -> .git/annex/objects/w6/X8/***.mp4/***.mp4 -> /mnt/nas/a.mp4
+```
+
+It might not be proper feature, just asking if it's possible or alternative way for doing this.
+
+Or
+
+Is there way to get the original directory of the file? Something like this  
+```
+$ git annex {somecommand} a.mp4 # Output: /mnt/nas/a.mp4
+```
+
+I couldn't find a way to do this with `whereis`. If it's possible I could just write custom xdg-open command. 
+
+"""]]
diff --git a/doc/forum/Way_to_copy_files___40__the_symbolic_links__41__.mdwn b/doc/forum/Way_to_copy_files___40__the_symbolic_links__41__.mdwn
new file mode 100644
index 0000000000..b397ea28ee
--- /dev/null
+++ b/doc/forum/Way_to_copy_files___40__the_symbolic_links__41__.mdwn
@@ -0,0 +1,12 @@
+I'm using git-annex with the SHA256 backend. When I git annex add a file, it becomes a symbolic link and the real content goes in a file whose name includes the SHA256 hash.
+
+Suppose the original filename (which is a symbolic link now) is named A. I want to have another filename B point to A. In a non-annex directory I'd create a symbolic link B -> A or a hardlink B that is the same file as A.
+
+Within the git annex directory, I don't want to use another symbolic link B -> A -> keyfile. Instead, I want two symbolic links straight to the content:
+
+* B -> keyfile
+* A -> keyfile
+
+This appears to be more elegant, and A or B can be independently unlinked without the other becoming a dangling link. It is also what git annex would do if A and B are added with the same content separately. I want a command that creates B: git annex ln A B
+
+Apologies if there is already such a git annex command. There doesn't seem to be a direct equivalent in cp's arguments or rsync's arguments to fixup the relative link path while copying it, and it needs a longer series of piped commands. As the link would be created within the annex directory, having git annex provide a single command to do it would be most useful.
diff --git a/doc/forum/Way_to_copy_files___40__the_symbolic_links__41__/comment_1_5f452eeb652e1bbec54cddc3735a6d4a._comment b/doc/forum/Way_to_copy_files___40__the_symbolic_links__41__/comment_1_5f452eeb652e1bbec54cddc3735a6d4a._comment
new file mode 100644
index 0000000000..0ad2a90b27
--- /dev/null
+++ b/doc/forum/Way_to_copy_files___40__the_symbolic_links__41__/comment_1_5f452eeb652e1bbec54cddc3735a6d4a._comment
@@ -0,0 +1,17 @@
+[[!comment format=sh
+ username="muks@6bded6d879d80c43cdf4893fabb785876eea0a7b"
+ nickname="muks"
+ avatar="http://cdn.libravatar.org/avatar/2bb3204407446ec2adfe5c41be26cc1e"
+ subject="comment 1"
+ date="2020-12-11T02:18:29Z"
+ content="""
+# What I want is achieved by this longer command:
+
+ln -s $(realpath --relative-to=. $(readlink -m $FILE_SRC)) $FILE_DEST && \
+     git add $FILE_DEST
+
+# Instead, a git annex command to perform the above with
+# the following syntax would be useful:
+
+git annex ln $FILE_SRC $FILE_DEST
+"""]]
diff --git a/doc/forum/Way_to_copy_files___40__the_symbolic_links__41__/comment_2_56617a9d760e7528d7b30ed479e5070a._comment b/doc/forum/Way_to_copy_files___40__the_symbolic_links__41__/comment_2_56617a9d760e7528d7b30ed479e5070a._comment
new file mode 100644
index 0000000000..94e8bd1531
--- /dev/null
+++ b/doc/forum/Way_to_copy_files___40__the_symbolic_links__41__/comment_2_56617a9d760e7528d7b30ed479e5070a._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 2"
+ date="2020-12-11T15:29:26Z"
+ content="""
+> I want a command that creates B: git annex ln A B
+
+> Apologies if there is already such a git annex command. There
+> doesn't seem to be a direct equivalent in cp's arguments or rsync's
+> arguments to fixup the relative link path while copying it, and it
+> needs a longer series of piped commands.
+
+I'm not aware of a git-annex command that does this, but you can just
+copy the link and `git annex add` it.  git-annex will fix up the
+levels if needed.
+
+```
+$ cp -d d/foo.txt bar.txt
+$ git annex add bar.txt
+
+$ git show :d/foo.txt
+../.git/annex/objects/8Z/1J/SHA256-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c/SHA256-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c
+$ git show :bar.txt
+.git/annex/objects/8Z/1J/SHA256-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c/SHA256-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c
+```
+
+"""]]
diff --git a/doc/forum/Way_to_copy_files___40__the_symbolic_links__41__/comment_3_8c8f09c8a916dd44d787a02f1570bd82._comment b/doc/forum/Way_to_copy_files___40__the_symbolic_links__41__/comment_3_8c8f09c8a916dd44d787a02f1570bd82._comment
new file mode 100644
index 0000000000..6d3a92b951
--- /dev/null
+++ b/doc/forum/Way_to_copy_files___40__the_symbolic_links__41__/comment_3_8c8f09c8a916dd44d787a02f1570bd82._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="muks@6bded6d879d80c43cdf4893fabb785876eea0a7b"
+ nickname="muks"
+ avatar="http://cdn.libravatar.org/avatar/2bb3204407446ec2adfe5c41be26cc1e"
+ subject="comment 3"
+ date="2020-12-12T10:35:07Z"
+ content="""
+The method you suggest appears to work, and it is sufficient. Thank you for replying.
+"""]]
diff --git a/doc/forum/Way_to_list_missing_files.mdwn b/doc/forum/Way_to_list_missing_files.mdwn
new file mode 100644
index 0000000000..3b1f1553ce
--- /dev/null
+++ b/doc/forum/Way_to_list_missing_files.mdwn
@@ -0,0 +1 @@
+Is there a way to have git-annex list missing files / broken links within a repository? This seems like it would be a common thing to want to do, and I feel like I've done it before, but I can find nothing about this anywhere. It may just be that I'm not searching using the right terminology.
diff --git a/doc/forum/Way_to_list_missing_files/comment_1_d302a4b64cfca76e8af756018768ff08._comment b/doc/forum/Way_to_list_missing_files/comment_1_d302a4b64cfca76e8af756018768ff08._comment
new file mode 100644
index 0000000000..66ca9f17f6
--- /dev/null
+++ b/doc/forum/Way_to_list_missing_files/comment_1_d302a4b64cfca76e8af756018768ff08._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2022-07-17T09:33:04Z"
+ content="""
+`git annex find --not --in=here`
+"""]]
diff --git a/doc/forum/Web_app_on_server_without_X11__63__.mdwn b/doc/forum/Web_app_on_server_without_X11__63__.mdwn
new file mode 100644
index 0000000000..cb880cf292
--- /dev/null
+++ b/doc/forum/Web_app_on_server_without_X11__63__.mdwn
@@ -0,0 +1,3 @@
+When I run git-annex-webapp, a browser is opened and I am redirected to the assistant. However, how can I run the web app and just have it start the server process without opening a browser, and navigating to the page from a remote computer?
+
+Thanks!
diff --git a/doc/forum/Web_app_on_server_without_X11__63__/comment_1_bee409ad389e5fb5f3e8de4b5c68278d._comment b/doc/forum/Web_app_on_server_without_X11__63__/comment_1_bee409ad389e5fb5f3e8de4b5c68278d._comment
new file mode 100644
index 0000000000..f428ece1e1
--- /dev/null
+++ b/doc/forum/Web_app_on_server_without_X11__63__/comment_1_bee409ad389e5fb5f3e8de4b5c68278d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="81.111.193.130"
+ subject="comment 1"
+ date="2014-09-10T14:32:21Z"
+ content="""
+[Running the assistant headless](http://git-annex.branchable.com/design/assistant/blog/day_232__headless_webapp/).
+
+Hope this helps.
+"""]]
diff --git a/doc/forum/Web_interface_to_git-annex__63__.mdwn b/doc/forum/Web_interface_to_git-annex__63__.mdwn
new file mode 100644
index 0000000000..cd4f838713
--- /dev/null
+++ b/doc/forum/Web_interface_to_git-annex__63__.mdwn
@@ -0,0 +1,5 @@
+Is there currently such a thing as a Web interface for viewing files in a git-annex repository, and being able to carry out git-annex operations like get/drop?
+
+There are several different Web-based file browsers available, which work fine on a git-annex repo but don't let you do annex operations. I could also run a generic WebDAV server and client, but that has the same problem.
+
+The eventual use case is to expose the interface behind an HTTPS reverse proxy that will handle authentication, so no authentication functionality is needed.
diff --git a/doc/forum/Web_interface_to_git-annex__63__/comment_1_371586edbeca15724121a5123bce66d6._comment b/doc/forum/Web_interface_to_git-annex__63__/comment_1_371586edbeca15724121a5123bce66d6._comment
new file mode 100644
index 0000000000..aebf504f7e
--- /dev/null
+++ b/doc/forum/Web_interface_to_git-annex__63__/comment_1_371586edbeca15724121a5123bce66d6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-20T18:04:32Z"
+ content="""
+I don't know of such a thing that is explicitly web-based.
+
+See [[tips/file_manager_integration]] for how to set up
+several file managers to be able to do get/drop. I don't see any reason
+some web-based file manager couldn't have similar hooks to the ones used
+there.
+"""]]
diff --git a/doc/forum/Webapp_not_watching_repos.mdwn b/doc/forum/Webapp_not_watching_repos.mdwn
new file mode 100644
index 0000000000..b751b65637
--- /dev/null
+++ b/doc/forum/Webapp_not_watching_repos.mdwn
@@ -0,0 +1 @@
+I am using the webapp to watch 3 repositories. When I run git annex webapp it starts watching one of the repos but unless I switch to other repos it does not start noticing changes after switching to each repo once it works as intended.
diff --git a/doc/forum/Webapp_not_watching_repos/comment_1_02735050122afdb6498d91b462d32767._comment b/doc/forum/Webapp_not_watching_repos/comment_1_02735050122afdb6498d91b462d32767._comment
new file mode 100644
index 0000000000..9b0d61af10
--- /dev/null
+++ b/doc/forum/Webapp_not_watching_repos/comment_1_02735050122afdb6498d91b462d32767._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2013-12-27T19:02:28Z"
+ content="""
+Each separate repository needs to have a separate `git annex assistant` process handling it.
+
+Normally, these would all be started when `git annex assistant --autostart` is run, typically when you log into a desktop environment.
+
+So, on Linux, this is done via a .desktop file (or you can arrange for the command to be run as the right user at boot if not using a desktop); on OSX it's done via a .plist file. On Windows and Android, nothing handles the autostarting yet.
+"""]]
diff --git a/doc/forum/Webapp_not_watching_repos/comment_2_8ab2d4c18ddc99774e44c4f4401bfa57._comment b/doc/forum/Webapp_not_watching_repos/comment_2_8ab2d4c18ddc99774e44c4f4401bfa57._comment
new file mode 100644
index 0000000000..63573b0231
--- /dev/null
+++ b/doc/forum/Webapp_not_watching_repos/comment_2_8ab2d4c18ddc99774e44c4f4401bfa57._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 2"
+ date="2013-12-27T22:40:06Z"
+ content="""
+I don't have a desktop env. just plain xmonad, so the correct sequence to start the webapp is,
+
+    git annex assistant --autostart && git annex webapp
+
+right?
+"""]]
diff --git a/doc/forum/Webapp_not_watching_repos/comment_3_b448aa5a95a57a5228b361390e5fc838._comment b/doc/forum/Webapp_not_watching_repos/comment_3_b448aa5a95a57a5228b361390e5fc838._comment
new file mode 100644
index 0000000000..92fd3cb459
--- /dev/null
+++ b/doc/forum/Webapp_not_watching_repos/comment_3_b448aa5a95a57a5228b361390e5fc838._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 3"
+ date="2013-12-29T17:59:53Z"
+ content="""
+In this case, I would probably put `git annex assistant --autostart` in `.xinitrc`, or even make a @reboot cron job that starts it. The webapp can then be opened with `git annex webapp` at any time. (The webapp is not a separate process and does not need to be started at login.)
+"""]]
diff --git a/doc/forum/Webapp_on_ARM.mdwn b/doc/forum/Webapp_on_ARM.mdwn
new file mode 100644
index 0000000000..c9766dd8cf
--- /dev/null
+++ b/doc/forum/Webapp_on_ARM.mdwn
@@ -0,0 +1,6 @@
+Webapp on ARM?
+==============
+
+Since the webapp is apparently now available on Android (not tested yet, but I plan to do it soon ;)), I was wondering what was the status of the webapp on ARM. Does it build, does it work, and if it does would it be possible to enable it in the Debian package for the next release?
+
+For the record, I'm using git-annex on my NAS (Synology DS413j). I'm using the Debian armel package and running it in an Arch Linux chroot (a very simple setup). It works really well, and I'm extremely satisfied with git-annex. Thanks a lot for all your work, Joey *et al.*!
diff --git a/doc/forum/Webapp_on_ARM/comment_1_82ac40cef5b59070136527b8d81a5ce2._comment b/doc/forum/Webapp_on_ARM/comment_1_82ac40cef5b59070136527b8d81a5ce2._comment
new file mode 100644
index 0000000000..00e3fed262
--- /dev/null
+++ b/doc/forum/Webapp_on_ARM/comment_1_82ac40cef5b59070136527b8d81a5ce2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.1.10"
+ subject="comment 1"
+ date="2013-07-22T19:13:38Z"
+ content="""
+To build the WebApp on arm, you need a ghc that supports template haskell on arm. While I have heard persistent rumors of such a thing existing, I have yet to see it.
+
+It's possible to build the WebApp on arm without that, but it's a complicated process, involving first building on x86 with the same versions of the haskell libraries that you have on the arm system, and then using the EvilSplicer to generate a source tree with the template haskell expanded, which can then be built on arm. This build process is not really suitable for a Debian package.
+"""]]
diff --git a/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app.mdwn b/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app.mdwn
new file mode 100644
index 0000000000..055a09e2ac
--- /dev/null
+++ b/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app.mdwn
@@ -0,0 +1,12 @@
+I am having some weird issues with git annex under OS X.  I am new to git annex, and am generally familiar with git.  I really like the concept of git-annex and am trying to lean how to fit it into my workflow, but Im running into problems.  
+
+I have a folder that I would like to keep in sync across multiple computers and thumb drives.  Right now this folder consists of other folders and PDF files.  After initializing git and git-annex, all of the files turn into symlinks, as expected.  
+
+Looking at this folder in OSX's finder, none of the symlinks have preview images unfortunately, as expected.  Also, when trying to open the file (or symlink, and in this case PDFs) in finder, it opens the console which outputs a bunch of crap and then nothing happens.  Right clicking on the symlink in finder and using Open with... the default application to open the symlink to the PDF is OSX's Preview.app, as expected, however for some reason this isn't being used when simple double clicking.  If you click on the Preview.app option under the right click menu, Preview.app launches, but never opens the file.  Selecting an alternative such as the Skim.app pdf viewer (if installed) successfully launches the application and opens the file.  
+
+My questions are:
+1. What is the cause of not being able to launch the file in the correct app by simply double clicking it?  Do I have something mis-configued?  Is it a bug with git-annex?  Is git-annex simply not set up to work with finder yet?
+2. How come preview can't open the file but skim can?  This might be directly related to the above question, but maybe not.
+3. Is it possible to get file previews for the symlinks in your annex folder?  Are there plans to enable this kind of thing in the future, if even possible? 
+
+Details about my setup.  I am running on a 32-bit Core Duo Macbook pro from 2006, so enviably I have to run 10.6.8 and its the highest OS version I can reach right now.  All my CLI packages are installed and up to date with Mac Homebrew.  I am running git version 1.7.12.  I freshly installed haskell-platform: stable 2012.2.0.0 via homebrew.  From there I installed git-annex-3.20120825.
diff --git a/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_1_8c8d86790a9d31518f9bb96a2d2dafee._comment b/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_1_8c8d86790a9d31518f9bb96a2d2dafee._comment
new file mode 100644
index 0000000000..4234eac2bc
--- /dev/null
+++ b/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_1_8c8d86790a9d31518f9bb96a2d2dafee._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.30"
+ subject="comment 1"
+ date="2012-09-09T17:22:58Z"
+ content="""
+It is unfortunate that certain badly-coded programs fall over on symlinks. In theory, any program that doesn't try to be too smart for its own good will see a symlink as just like the file it links to, and should behave the same. This is the theory that led me to use symlinks in git-annex. But some programs say \"oh, a symlink! Let's see what file that's pointing at, and behave differently!\" I don't understand the mindset that leads to this kind of program being written, unless it's a program like `cp`, that has very good reasons for (at your command) following symlinks or not.
+
+I know absolutely nothing about Mac OSX, having never used it (except for in a ssh session while porting git-annex to it). But I have seen a similar problem with the FBReader ebook viewer. [Bug report](http://bugs.debian.org/685433)
+
+I was able to work around that bug by migrating my files to the SHA256E backend. This ensures that the keys stored in git-annex have extensions like .pdf etc, similar to the symlinks that point to them. You might try migrating some of your files too, and see if it makes OSX behave better. Although I thought OSX didn't rely on file extensions to determine file type.. 
+
+Anyway, the command is:
+
+    git annex migrate --backend=SHA256E
+
+I have been considering switching the default backend to SHA256E to avoid this type of problem. Your testing will be important grist for that decision.
+"""]]
diff --git a/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_2_b538dc2c6f122b9ce5f7569de1b03f3e._comment b/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_2_b538dc2c6f122b9ce5f7569de1b03f3e._comment
new file mode 100644
index 0000000000..ee09be502c
--- /dev/null
+++ b/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_2_b538dc2c6f122b9ce5f7569de1b03f3e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://mike.magin.org/"
+ nickname="mmagin"
+ subject="comment 2"
+ date="2012-09-11T15:27:58Z"
+ content="""
+I've been using git-annex mostly on Mac OS X, and it rapidly caused me to switch to SHA256E.  I'd certainly be in favor of it being the default.  Aside from [[bugs/fsck thinks file content is bad when it isn't]] (fixed by the time I encountered it), I have had no issues with it so far.
+"""]]
diff --git a/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_3_16e6724fa184392d4decbe0c4eb6efe6._comment b/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_3_16e6724fa184392d4decbe0c4eb6efe6._comment
new file mode 100644
index 0000000000..0315feb642
--- /dev/null
+++ b/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_3_16e6724fa184392d4decbe0c4eb6efe6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkurjhi0CRJvgm7QNaZDWS9hitBtavqIpc"
+ nickname="Bret"
+ subject="comment 3"
+ date="2012-09-12T09:23:51Z"
+ content="""
+Sorry for the delayed response.  I am in the middle of an apartment move.
+
+I tried changing my default PDF viewer to Skim to see if that improved anything.  Nada.  Same thing.  Finder opens the terminal and outputs a bunch of nonsense.  
+
+I tried `git annex migrate --backend=SHA256E` and it seemed to really improve things from finders point of view.  Still not icon previews, but you can launch every file by double clicking it and preview is able to follow the symlink.  
+
+Note, I am on OS X 10.6.  I cant upgrade to 10.7+ due to my laptops aging processor (10.7+ requires 64-bit intel chips) and thus can't test git-annex on a more modern OS version.  Someone should test it out on a newer version of OS X before chaining any defaults, however, it seems to really improve things for the setup I have.
+"""]]
diff --git a/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_4_e514fe2d4d0ad6a10e281939e6ab4266._comment b/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_4_e514fe2d4d0ad6a10e281939e6ab4266._comment
new file mode 100644
index 0000000000..aa50ab57c8
--- /dev/null
+++ b/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_4_e514fe2d4d0ad6a10e281939e6ab4266._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 4"
+ date="2012-09-12T20:32:52Z"
+ content="""
+I see a migration to SHA256E currently outputs:
+
+migrate issue.txt (checksum...) (Recording state in git...)
+ok
+
+Is that verifying the existing checksum or re-computing it to re-name the file?  If the latter, couldn't the SHA256 to SHA256E migration just rename the file?
+
+I would be worried about this process hiding data corruption.. If it isn't using the old checksum but instead re-computing a new one then it would be easy to miss the fact that a files checksum changed during this process.
+"""]]
diff --git a/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_5_e0eec765f72f7bf6f5a2a92c9b5dacad._comment b/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_5_e0eec765f72f7bf6f5a2a92c9b5dacad._comment
new file mode 100644
index 0000000000..254a524aa3
--- /dev/null
+++ b/doc/forum/Weird_behavior_with_OS_X_Finder_and_Preview.app/comment_5_e0eec765f72f7bf6f5a2a92c9b5dacad._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.30"
+ subject="comment 5"
+ date="2012-09-14T04:20:27Z"
+ content="""
+Good catch, I've made it verify the old checksum first.
+
++/- E migrations are not currently optimised.
+"""]]
diff --git a/doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__.mdwn b/doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__.mdwn
new file mode 100644
index 0000000000..cf006ff74b
--- /dev/null
+++ b/doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__.mdwn
@@ -0,0 +1,11 @@
+Hi git-annexers,
+
+The git-annex website has two articles on encryption: [https://git-annex.branchable.com/encryption/](https://git-annex.branchable.com/encryption/) and [https://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/](https://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/).
+
+What is the difference between "vanilla" git-annex encryption and the workflow described in the "fully encrypted git repositories with gcrypt" guide?
+
+I'm having a hard time figuring out whether one is more secure than the other. Or when I'd want to use one vs. the other.
+
+Can anyone help shed some light?
+
+Thank you.
diff --git a/doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__/comment_1_e4e9c6858fe905b17154e19cbe7ee2f5._comment b/doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__/comment_1_e4e9c6858fe905b17154e19cbe7ee2f5._comment
new file mode 100644
index 0000000000..c5aac133d5
--- /dev/null
+++ b/doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__/comment_1_e4e9c6858fe905b17154e19cbe7ee2f5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="re: the difference between encryption and gcrypt"
+ date="2022-12-22T19:58:40Z"
+ content="""
+git-annex encryption encrypts only the file contents stored in the remotes, but not the filenames or the commit history; gcrypt encrypts these latter parts.
+"""]]
diff --git a/doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__/comment_2_359e52a73f236bce4e8e31e76436fba7._comment b/doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__/comment_2_359e52a73f236bce4e8e31e76436fba7._comment
new file mode 100644
index 0000000000..446ba4591e
--- /dev/null
+++ b/doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__/comment_2_359e52a73f236bce4e8e31e76436fba7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="alvseth"
+ avatar="http://cdn.libravatar.org/avatar/4618511682dacfd6835c3e843b4e97a0"
+ subject="re: re: the difference between encryption and gcrypt"
+ date="2022-12-22T23:22:33Z"
+ content="""
+> git-annex encryption encrypts only the file contents stored in the remotes, but not the filenames or the commit history; gcrypt encrypts these latter parts.
+
+For maximum security, should I use both? Or does gcrypt also encrypt file contents?
+"""]]
diff --git a/doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__/comment_3_d43cf2928e2ebbf2793911e49cffd671._comment b/doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__/comment_3_d43cf2928e2ebbf2793911e49cffd671._comment
new file mode 100644
index 0000000000..e44289f4d8
--- /dev/null
+++ b/doc/forum/What__39__s_the_difference_between_encryption___38___gcrypt__63__/comment_3_d43cf2928e2ebbf2793911e49cffd671._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-12-26T17:10:24Z"
+ content="""
+When a remote is a git repository that supports git-annex,
+using a gcrypt special remote encrypts both the git repository and file
+contents.
+
+Other special remotes only store annexed file contents, not git
+repositories, so using encryption= with those is sufficient to encrypt
+their full contents.
+"""]]
diff --git a/doc/forum/What_am_I_doing_wrong_with_move__63__.mdwn b/doc/forum/What_am_I_doing_wrong_with_move__63__.mdwn
new file mode 100644
index 0000000000..0bf0980c71
--- /dev/null
+++ b/doc/forum/What_am_I_doing_wrong_with_move__63__.mdwn
@@ -0,0 +1,48 @@
+I still have little experience with git-annex, so I may be missing something fairly obvious.
+
+I have been moving files between two repositories. Things *seemed* to be going well, but today I noticed that I was missing some content that I have just moved. I would like some help to figure out where I went wrong to avoid doing worse mistakes in the future.
+
+What I did was to run the command `git-annex move --from=toshiba` to move a bunch of files from my USB unit to my current repository and then I ran `git-annex sync` on both ends. Afterwards I noticed that the content of the files was not available, so I tried to track one of them.
+What I could see in my local indirect repository was a broken symbolic link pointing to `../.git/annex/objects/ZQ/WF/SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg/SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg`.
+
+`git-annex info` gave me similar information:
+
+    file: Heavy Metal 1981.jpg
+    size: 241 bytes
+    key: SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg
+
+`git-annex whereis` locates the file still on its origin:
+
+    whereis Heavy Metal 1981.jpg (1 copy) 
+  	    49b5b3a4-56ac-4cf2-aed9-1c23d3181c97 -- Toshiba USB HDD [toshiba]
+    ok
+
+On my external HDD drive, where I have an indirect mode repository, the file has already been replaced by a reference (241 bytes).
+
+    $ cat "Heavy Metal 1981.jpg"
+    ../../../../../../../../../media/TOSHIBA EXT/annex/.git/annex/objects/4z/gf/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg
+
+`git-annex log` remembers something about the operation:
+
+    + Tue, 17 May 2016 12:22:43 WEST Heavy Metal 1981.jpg | 49b5b3a4-56ac-4cf2-aed9-1c23d3181c97 -- Toshiba USB HDD [toshiba]
+
+I tried to `git-annex get "Heavy Metal 1981.jpg"`, and now I have a working symlink on my PC. However it does not point to the image, but to the same 241 bytes reference file that I have on my external HDD.
+
+`git-annex whereis` now mentions 2 locations to my file, but none of the working dirs holds its contents. So, where are the contents of the file? Lost somewhere? It appears that git-annex took the indirect mode reference file and took it for the real file contents -- and that is not good.
+
+I looked at the output of `git-annex unused`, cross-referenced with `git log --stat -S` and I managed to find it somewhere in the list of unused files in my PC's repository, but not on the external drive.
+
+Still, at this point I'm a little worried. I would like to understand what I could have done to cause this mess. Also, how I can clean it up (the rest of the files remain as broken links at the moment).
+
+I have a couple more drives I wanted to add to this setup, but you can understand that I hesitate a little bit at the moment. Maybe I have "lost" more data than I realize.
+
+The version details:
+
+    git-annex version: 6.20160511
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 5 6
+    upgrade supported from repository versions: 0 1 2 4 5
+    operating system: linux x86_64
diff --git a/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_1_a49d98426ef8dd17e6cca6b5fba5c9bf._comment b/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_1_a49d98426ef8dd17e6cca6b5fba5c9bf._comment
new file mode 100644
index 0000000000..d1c96f4f38
--- /dev/null
+++ b/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_1_a49d98426ef8dd17e6cca6b5fba5c9bf._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-17T18:04:53Z"
+ content="""
+It sounds like the symlink in the git repository has been changed to point
+to some other content that the content it had originally. Since git tracks
+past versions of files, you should be able to use `git log` on the file to
+find out when this hapened and you can use `git checkout` to check out the
+original version of the file, or `git revert` the commit that changed it to
+point to the wrong content. The content of the file should still be stored
+in the git annex, so you should be able to access it this way.
+
+Now, it kind of sounds like something added the git-annex link for a
+file, as it would appear on the FAT filesytem, to git-annex as the new 
+content of the file. It would certianly be a bug if a git-annex command
+did that.
+
+What does `git annex info` (with no other parameters) report when you run it in the repository on
+the USB drive? What filesystem is in use on the USB drive?
+"""]]
diff --git a/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_2_eeae2f172b4481fcb08745fc28aa4d4e._comment b/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_2_eeae2f172b4481fcb08745fc28aa4d4e._comment
new file mode 100644
index 0000000000..2ec35684c7
--- /dev/null
+++ b/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_2_eeae2f172b4481fcb08745fc28aa4d4e._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="Gus"
+ subject="Thank you"
+ date="2016-05-19T11:27:15Z"
+ content="""
+The external unit seems to hold a NTFS. Here is the `git-annex info` output:
+
+    repository mode: direct
+    trusted repositories: 0
+    semitrusted repositories: 4
+    	00000000-0000-0000-0000-000000000001 -- web
+     	00000000-0000-0000-0000-000000000002 -- bittorrent
+     	069de9a2-dc53-4c0a-82e0-a61a1f29e6b3 -- stratus PC [stratus]
+     	49b5b3a4-56ac-4cf2-aed9-1c23d3181c97 -- Toshiba USB HDD [here]
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: 4.42 gigabytes (+1 megabyte reserved)
+    local annex keys: 5556
+    local annex size: 1.66 terabytes
+    annexed files in working tree: 6618
+    size of annexed files in working tree: 1.1 terabytes
+    bloom filter size: 32 mebibytes (1.1% full)
+    backend usage: 
+    	SHA256E: 6618
+
+However, `git status` says:
+
+    fatal: This operation must be run in a work tree
+
+Which is not the same message as \"no git found here\", but is also not what I expected to see. `git log` seems to work but says nothing about the file at hand.
+
+On the PC side, however, I can see three commits on the file (I wish the commit message contained the command line with arguments, rather than the less descriptive \"git-annex in Toshiba USB HDD\").
+Using `git show` and `git cat-file` I managed to determine the following:
+
+March 4: the initial version of the file was committed.
+
+May 17 11:51: the file's content changed to `../../../../../../../../../media/TOSHIBA EXT/annex/.git/annex/objects/kx/3W/SHA256E-s96418--c6164e17d88914b2e6781e2cb8e7b91e9669ddf2d9ee6f5cbb17f3212bccfba4.jpg/SHA256E-s96418--c6164e17d88914b2e6781e2cb8e7b91e9669ddf2d9ee6f5cbb17f3212bccfba4.jpg`. This is blob `../.git/annex/objects/4z/gf/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg`.
+
+May 17 12:22 the file's content changed again to `../../../../../../../../../media/TOSHIBA EXT/annex/.git/annex/objects/4z/gf/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg`, i.e., a reference to the previous object. This is blob `../.git/annex/objects/ZQ/WF/SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg/SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg`.
+
+What else can I do in order to work out what went wrong? Is having concurrent commands manipulating the same repository a bad idea?
+"""]]
diff --git a/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_3_f2770f86138d9b8489fbf9a25462b4ce._comment b/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_3_f2770f86138d9b8489fbf9a25462b4ce._comment
new file mode 100644
index 0000000000..e0c0d3aaf4
--- /dev/null
+++ b/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_3_f2770f86138d9b8489fbf9a25462b4ce._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Gus"
+ subject="I think I have figured out something"
+ date="2016-06-05T22:42:17Z"
+ content="""
+When I `git-annex drop --force` a file from my direct repository, it gets replaced by a symbolic-link-like file, containing a path.
+Then, when I `git-annex sync` the repository to propagate the changes I have made, the file's content gets updated as if the file has been replaced.
+
+My question is then: why does the original file gets replaced by the link-like file when I drop it?
+"""]]
diff --git a/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_4_76aa27cdeefb1413baaa1c891ccd4d0d._comment b/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_4_76aa27cdeefb1413baaa1c891ccd4d0d._comment
new file mode 100644
index 0000000000..a801357916
--- /dev/null
+++ b/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_4_76aa27cdeefb1413baaa1c891ccd4d0d._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-06-09T19:51:10Z"
+ content="""
+The symbolic-link-like file is in fact, a symlink, which is what git-annex
+uses to represent an annexed file in git. If your filesystem does
+not support symlinks, git writes the link location to a regular file
+instead.
+
+git annex drop removes the content of a file from the local repository, but
+its symlink remains checked into git. So, the content of the file is
+replaced by the symlink in your working tree.
+
+That symlink should be the same thing git already had recorded for the
+file.
+
+Based on your earlier comment, it does seem that the symlink standin file
+that git uses is being treated as new content for the file, and getting
+annexed. That would be a bug.
+
+Is that happening when you run `git annex sync` on Linux, or is it on Windows?
+
+What else can you tell or show me to help me reproduce your problem? 
+I've tried setting up an NTFS filesystem, putting a git-annex repository on it, and dropping a file;
+git-annex sync did not do the wrong thing when I tried it.
+"""]]
diff --git a/doc/forum/What_can_be_done_in_case_of_conflict.mdwn b/doc/forum/What_can_be_done_in_case_of_conflict.mdwn
new file mode 100644
index 0000000000..42167a6091
--- /dev/null
+++ b/doc/forum/What_can_be_done_in_case_of_conflict.mdwn
@@ -0,0 +1,7 @@
+Hi,
+
+How can I resolve the conflict when it occurs?
+
+Suppose I have 2 branches (master, current), When I merge these branches or while doing cherry-pick, if I get conflict how can I resolve it?
+
+Thank You
diff --git a/doc/forum/What_can_be_done_in_case_of_conflict/comment_1_5ca86b099dfa08a50f656ea03bf1dcd9._comment b/doc/forum/What_can_be_done_in_case_of_conflict/comment_1_5ca86b099dfa08a50f656ea03bf1dcd9._comment
new file mode 100644
index 0000000000..6f1d241300
--- /dev/null
+++ b/doc/forum/What_can_be_done_in_case_of_conflict/comment_1_5ca86b099dfa08a50f656ea03bf1dcd9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-04-23T14:29:03Z"
+ content="""
+You handle conflicts in annexed files the same as you would handle them in other binary files checked into git.
+
+For example, you might choose to `git rm` or `git add` the file to resolve the conflict.
+
+[[Previous_discussion|forum/A_really_stupid_question]]
+"""]]
diff --git a/doc/forum/What_can_be_done_in_case_of_conflict/comment_2_69ee17959a92bb8359c0fd7b2a9d8dfb._comment b/doc/forum/What_can_be_done_in_case_of_conflict/comment_2_69ee17959a92bb8359c0fd7b2a9d8dfb._comment
new file mode 100644
index 0000000000..f4293d9c11
--- /dev/null
+++ b/doc/forum/What_can_be_done_in_case_of_conflict/comment_2_69ee17959a92bb8359c0fd7b2a9d8dfb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlYu7QmD7wrbHWkoxuriaA9XcijM-g5vrQ"
+ nickname="Royal"
+ subject="Resolving conflict"
+ date="2012-04-24T03:59:31Z"
+ content="""
+Hi,
+Now I am able to resolve the conflict.
+Thank you.
+"""]]
diff --git a/doc/forum/What_can_be_done_in_case_of_conflict/comment_3_017f4bac57a040c496e0c9d068dcfd9e._comment b/doc/forum/What_can_be_done_in_case_of_conflict/comment_3_017f4bac57a040c496e0c9d068dcfd9e._comment
new file mode 100644
index 0000000000..a0d3ded394
--- /dev/null
+++ b/doc/forum/What_can_be_done_in_case_of_conflict/comment_3_017f4bac57a040c496e0c9d068dcfd9e._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlYu7QmD7wrbHWkoxuriaA9XcijM-g5vrQ"
+ nickname="Royal"
+ subject="Resolving conflict"
+ date="2012-04-23T15:49:30Z"
+ content="""
+Thanks for the reply.
+
+I am executing the following commands.
+
+git init main
+cd main
+git annex init main
+echo a > a
+git annex add a
+git commit -m Initial
+git annex unlock a
+echo aa > a
+git annex add a
+git commit -m first
+git annex unlock a
+echo aaa > a
+git annex add a
+git commit -m second
+git log
+git cherry-pick <Hash of first commit>
+
+--------------------
+Error: 
+
+error: could not apply 2be8f38... first
+hint: after resolving the conflicts, mark the corrected paths
+hint: with 'git add <paths>' or 'git rm <paths>'
+hint: and commit the result with 'git commit'
+
+How can resolve the the above conflict.
+If I see the content of the file I will get the content of second commit.
+Is there any way I can get the content for first commit(Like in git we have 'theirs' option.)
+
+Thank you.
+"""]]
diff --git a/doc/forum/What_does___34__disable__47__enable_expiry_after_X_days__34___mean__63__.mdwn b/doc/forum/What_does___34__disable__47__enable_expiry_after_X_days__34___mean__63__.mdwn
new file mode 100644
index 0000000000..e95e27a755
--- /dev/null
+++ b/doc/forum/What_does___34__disable__47__enable_expiry_after_X_days__34___mean__63__.mdwn
@@ -0,0 +1 @@
+Git-annex assistant configuration has an item saying "disable/enable expiry after X days".  What does it mean?  Am I the only one confused by this?
diff --git a/doc/forum/What_does___34__disable__47__enable_expiry_after_X_days__34___mean__63__/comment_1_face45c85e4713325bb23bbca7b07502._comment b/doc/forum/What_does___34__disable__47__enable_expiry_after_X_days__34___mean__63__/comment_1_face45c85e4713325bb23bbca7b07502._comment
new file mode 100644
index 0000000000..adae1861a1
--- /dev/null
+++ b/doc/forum/What_does___34__disable__47__enable_expiry_after_X_days__34___mean__63__/comment_1_face45c85e4713325bb23bbca7b07502._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-31T20:21:52Z"
+ content="""
+Well, let's see.. You've gone into the Configuration and picked "Unused
+files". The full text in front of you is:
+
+<pre>
+Managing unused files
+
+Old versions of files and deleted files can be preserved inside this repository.
+
+This might be useful, if you ever need to access those old or deleted files. But they'll also use up disk space. There are three ways to deal with this
+
+1. Set up a backup or archive repository, on a removable drive or in the cloud, and the unused files will be moved to it, freeing up space. 
+   [Add a new repository]
+2. Or, you can let unused files expire after a period of time. 
+   [Disable expiry / Enable expiry] after [7] days. [Save changes]
+</pre>
+
+So yes, if I read only item #2, and possibly skip the first sentence of it
+and look at only the "Disable expiry / Enable expiry",
+it seems a litte confusing, possibly, but if I read the 2 paragraphs
+of explaination above it, not so much?
+
+What do you find confusing about this form as a whole?
+"""]]
diff --git a/doc/forum/What_does_a___91__RepoName__93___means__63__.mdwn b/doc/forum/What_does_a___91__RepoName__93___means__63__.mdwn
new file mode 100644
index 0000000000..fa1841f69f
--- /dev/null
+++ b/doc/forum/What_does_a___91__RepoName__93___means__63__.mdwn
@@ -0,0 +1,5 @@
+Hello,
+
+sometimes, ```git annex info``` shows a (special remote) repository's name in [Brackets], sometimes not. Every theory (depending on enabled / not enabled) I had so far, is disproved by my next step. What does it means when the name is in brackets?
+
+Thanks!
diff --git a/doc/forum/What_does_a___91__RepoName__93___means__63__/comment_1_9b1cb4beea0f67d7e7375e7ec189b802._comment b/doc/forum/What_does_a___91__RepoName__93___means__63__/comment_1_9b1cb4beea0f67d7e7375e7ec189b802._comment
new file mode 100644
index 0000000000..c8dc7ce906
--- /dev/null
+++ b/doc/forum/What_does_a___91__RepoName__93___means__63__/comment_1_9b1cb4beea0f67d7e7375e7ec189b802._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-12-05T16:44:45Z"
+ content="""
+The name in brackets is the name of the git remote, if any, corresponding
+to the repository.
+"""]]
diff --git a/doc/forum/What_does_a___91__RepoName__93___means__63__/comment_2_a233086f100fec27cd26f4d39c25a385._comment b/doc/forum/What_does_a___91__RepoName__93___means__63__/comment_2_a233086f100fec27cd26f4d39c25a385._comment
new file mode 100644
index 0000000000..cac61f40d8
--- /dev/null
+++ b/doc/forum/What_does_a___91__RepoName__93___means__63__/comment_2_a233086f100fec27cd26f4d39c25a385._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://xgm.de/oid/"
+ nickname="Flo"
+ avatar="http://cdn.libravatar.org/avatar/4c5c0e290374d76c713f482e41f60a3cbee0fa64bb94c6da94e5a61a50824811"
+ subject="comment 2"
+ date="2017-12-06T08:39:10Z"
+ content="""
+Sure, that I know. But what does it mean for a S3 type special remote? 
+
+
+    repository mode: indirect
+    trusted repositories: 0
+    semitrusted repositories: 6
+           00000000-0000-0000-0000-000000000001 -- web
+           00000000-0000-0000-0000-000000000002 -- bittorrent
+           4cc98291-9ee9-4331-b089-b57d3d03ab0e -- Horus [horus]
+           8c201bd1-9089-4a4c-a795-7b5def64e470 -- [S3]
+           a2d60179-3e1e-49d9-90bf-f98b8a77590d -- Asaru [local]
+           ebb96a27-c997-46b5-b896-bb4f313f6e76 -- External_2TB [here]
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: 536.31 gigabytes (+1 megabyte reserved)
+
+I have seen the S3 remote without brackets at some repo, with at others.
+
+"""]]
diff --git a/doc/forum/What_does_a___91__RepoName__93___means__63__/comment_3_4b62bf0c03fed86270a7873a8835dc7f._comment b/doc/forum/What_does_a___91__RepoName__93___means__63__/comment_3_4b62bf0c03fed86270a7873a8835dc7f._comment
new file mode 100644
index 0000000000..b642d060f9
--- /dev/null
+++ b/doc/forum/What_does_a___91__RepoName__93___means__63__/comment_3_4b62bf0c03fed86270a7873a8835dc7f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-12-08T19:36:59Z"
+ content="""
+The "[S3]" means that the special remote's name is "S3".
+So, you can run `git annex copy --to S3` or something like that and it will
+use that special remote.
+
+This particular remote has no description set, which is why it only
+displays the name.
+"""]]
diff --git a/doc/forum/What_happened_to_the_walkthrough__63__.mdwn b/doc/forum/What_happened_to_the_walkthrough__63__.mdwn
new file mode 100644
index 0000000000..e8098d29a1
--- /dev/null
+++ b/doc/forum/What_happened_to_the_walkthrough__63__.mdwn
@@ -0,0 +1 @@
+As of right now (2012-05-24 at 18:00 UTC), the [[Walkthrough]] page is basically empty. Its entire contents are "A walkthrough of the basic features of git-annex." No links (other than the autogenerated "what links to this page" list at the bottom) and no contents. Any idea what happened?
diff --git a/doc/forum/What_happened_to_the_walkthrough__63__/comment_1_70db0e3cfb1318e95671c23726e5541d._comment b/doc/forum/What_happened_to_the_walkthrough__63__/comment_1_70db0e3cfb1318e95671c23726e5541d._comment
new file mode 100644
index 0000000000..cbf852dbfb
--- /dev/null
+++ b/doc/forum/What_happened_to_the_walkthrough__63__/comment_1_70db0e3cfb1318e95671c23726e5541d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2012-05-24T19:18:55Z"
+ content="""
+It seems the pages that are supposed to be inlined are not being found even though they are in `doc/walkthrough/`.
+"""]]
diff --git a/doc/forum/What_happened_to_the_walkthrough__63__/comment_2_f9305dd19b9b5f35e66d915b8c30374b._comment b/doc/forum/What_happened_to_the_walkthrough__63__/comment_2_f9305dd19b9b5f35e66d915b8c30374b._comment
new file mode 100644
index 0000000000..9720adfbc6
--- /dev/null
+++ b/doc/forum/What_happened_to_the_walkthrough__63__/comment_2_f9305dd19b9b5f35e66d915b8c30374b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 2"
+ date="2012-05-24T20:15:19Z"
+ content="""
+Broken last night during upgrade, fixed now, thanks for noticing.
+"""]]
diff --git a/doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__.mdwn b/doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__.mdwn
new file mode 100644
index 0000000000..8bcc1dc781
--- /dev/null
+++ b/doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__.mdwn
@@ -0,0 +1,77 @@
+Step by step:
+
+git annex add ./hugePictureFolder<br>
+// no it's to big and taking to long, let's not do this<br>
+CRTL+D<br>
+git annex --force drop ./hugePictureFolder<br>
+git status<br>
+fatal: bad default revision 'HEAD'<br>
+git reset --hard git-annex<br>
+git status // ok<br>
+ls <br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 000<br>
+drwxr-xr-x  9 rolas rolas      4096 Vas 16 11:40 001<br>
+drwxr-xr-x 11 rolas rolas      4096 Vas 16 11:40 002<br>
+drwxr-xr-x 12 rolas rolas      4096 Vas 16 11:40 003<br>
+drwxr-xr-x  6 rolas rolas      4096 Vas 16 11:40 004<br>
+drwxr-xr-x 12 rolas rolas      4096 Vas 16 11:40 005<br>
+drwxr-xr-x 11 rolas rolas      4096 Vas 16 11:40 006<br>
+drwxr-xr-x 13 rolas rolas      4096 Vas 16 11:40 007<br>
+drwxr-xr-x  6 rolas rolas      4096 Vas 16 11:40 008<br>
+drwxr-xr-x 13 rolas rolas      4096 Vas 16 11:40 009<br>
+drwxr-xr-x 14 rolas rolas      4096 Vas 16 11:40 00a<br>
+drwxr-xr-x 16 rolas rolas      4096 Vas 16 11:40 00b<br>
+drwxr-xr-x 11 rolas rolas      4096 Vas 16 11:40 00c<br>
+drwxr-xr-x  9 rolas rolas      4096 Vas 16 11:40 00d<br>
+drwxr-xr-x 20 rolas rolas      4096 Vas 16 11:40 00e<br>
+drwxr-xr-x 18 rolas rolas      4096 Vas 16 11:40 00f<br>
+drwxr-xr-x 14 rolas rolas      4096 Vas 16 11:40 010<br>
+drwxr-xr-x 11 rolas rolas      4096 Vas 16 11:40 011<br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 012<br>
+drwxr-xr-x 12 rolas rolas      4096 Vas 16 11:40 013<br>
+drwxr-xr-x  7 rolas rolas      4096 Vas 16 11:40 014<br>
+drwxr-xr-x 16 rolas rolas      4096 Vas 16 11:40 015<br>
+drwxr-xr-x  7 rolas rolas      4096 Vas 16 11:40 016<br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 017<br>
+drwxr-xr-x  9 rolas rolas      4096 Vas 16 11:40 018<br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 019<br>
+drwxr-xr-x  8 rolas rolas      4096 Vas 16 11:40 01a<br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 01b<br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 01c<br>
+drwxr-xr-x  8 rolas rolas      4096 Vas 16 11:40 01d<br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 01e<br>
+drwxr-xr-x 11 rolas rolas      4096 Vas 16 11:40 01f<br>
+drwxr-xr-x 15 rolas rolas      4096 Vas 16 11:40 020<br>
+drwxr-xr-x 13 rolas rolas      4096 Vas 16 11:40 021<br>
+drwxr-xr-x  5 rolas rolas      4096 Vas 16 11:40 022<br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 023<br>
+drwxr-xr-x  9 rolas rolas      4096 Vas 16 11:40 024<br>
+drwxr-xr-x 12 rolas rolas      4096 Vas 16 11:40 025<br>
+drwxr-xr-x  8 rolas rolas      4096 Vas 16 11:40 026<br>
+drwxr-xr-x 12 rolas rolas      4096 Vas 16 11:40 027<br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 028<br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 029<br>
+drwxr-xr-x  9 rolas rolas      4096 Vas 16 11:40 02a<br>
+drwxr-xr-x  9 rolas rolas      4096 Vas 16 11:40 02b<br>
+drwxr-xr-x  6 rolas rolas      4096 Vas 16 11:40 02c<br>
+drwxr-xr-x  7 rolas rolas      4096 Vas 16 11:40 02d<br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 02e<br>
+drwxr-xr-x  5 rolas rolas      4096 Vas 16 11:40 02f<br>
+drwxr-xr-x 13 rolas rolas      4096 Vas 16 11:40 030<br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 031<br>
+drwxr-xr-x 10 rolas rolas      4096 Vas 16 11:40 032<br>
+...<br>
+...<br>
+<br>
+What did I Do? Can I do CTRL+D? If yes, what should I do to recover?<br>
+<br>
+Thanks<br>
+Rolandas<br>
+ <br>
+$ git --version<br>
+git version 2.3.0<br>
+<br>
+$ git annex version<br>
+git-annex version: 5.20140412ubuntu1<br>
+<br>
+
diff --git a/doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__/comment_1_0ba60f9625ccda45d59adbd385f5fe98._comment b/doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__/comment_1_0ba60f9625ccda45d59adbd385f5fe98._comment
new file mode 100644
index 0000000000..931bab540a
--- /dev/null
+++ b/doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__/comment_1_0ba60f9625ccda45d59adbd385f5fe98._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnPgn611P6ym5yyL0BS8rUzO0_ZKRldMt0"
+ nickname="Samuel"
+ subject="Reseting to the git-annex branch"
+ date="2015-02-17T09:21:12Z"
+ content="""
+Well, it appears you explicitely asked for reseting to the git-annex branch with the following command
+  git annex reset --hard git-annex
+To go back to the master branch, containing the symlinks, just do
+  git annex checkout master
+
+"""]]
diff --git a/doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__/comment_3_f0a2ec3d0b05d84fb05a1708313a6762._comment b/doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__/comment_3_f0a2ec3d0b05d84fb05a1708313a6762._comment
new file mode 100644
index 0000000000..d06b509651
--- /dev/null
+++ b/doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__/comment_3_f0a2ec3d0b05d84fb05a1708313a6762._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawldTFGlKsKUyq6F6CJ22CNBnmYJ0LQbLUQ"
+ nickname="Rolandas"
+ subject="comment 3"
+ date="2015-02-18T06:58:59Z"
+ content="""
+Jes, it was an entirely new git repo and I removed .git folder and start over.<br>
+The question was is there some sort of „UNDO“ in this case.<br>
+I get it now.<br>
+I will read internals documentation.<br>
+Thank You very much!<br>
+"""]]
diff --git a/doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__/comment_3_f628f146a0c652f812c09f78bd574b77._comment b/doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__/comment_3_f628f146a0c652f812c09f78bd574b77._comment
new file mode 100644
index 0000000000..b5814c7c7c
--- /dev/null
+++ b/doc/forum/What_happens_after_terminated_add_of_huge_picture_folder__63__/comment_3_f628f146a0c652f812c09f78bd574b77._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-02-17T21:31:42Z"
+ content="""
+There is never a reason to run "git reset --hard git-annex"! For that matter,
+don't mess with the git-annex branch if you have not read and understand
+the [[internals]] documentation. Even if you have, it's entirely the wrong
+thing to be messing with in this situation. It has nothing at all to do
+with your problem, except that after running that completely random reset
+command, you now have two problems..
+
+The right answer to your interrupted add is something like:
+
+* `git reset --hard master`
+* Or, run the `git-annex add` command again and let it resume
+* Or, run `git commit` to commit any changes the add made,
+  followed by `git annex unannex` to back out adding those files.
+
+Or, if this is an entirely new git repo that you have
+never committed to before 
+(my guess based on the "bad default revision 'HEAD'"),
+just `rm -rf .git` and start over.
+"""]]
diff --git a/doc/forum/What_happens_when_in_the_git-annex_assistant_you___34__Add_another_local_repository__34___on_an_existing_repository__63__.mdwn b/doc/forum/What_happens_when_in_the_git-annex_assistant_you___34__Add_another_local_repository__34___on_an_existing_repository__63__.mdwn
new file mode 100644
index 0000000000..870f8913eb
--- /dev/null
+++ b/doc/forum/What_happens_when_in_the_git-annex_assistant_you___34__Add_another_local_repository__34___on_an_existing_repository__63__.mdwn
@@ -0,0 +1 @@
+I want to add an existing repository using the assistant. Is that the way?
diff --git a/doc/forum/What_happens_when_in_the_git-annex_assistant_you___34__Add_another_local_repository__34___on_an_existing_repository__63__/comment_1_d844cfe5f9907a766e871b64d68966c2._comment b/doc/forum/What_happens_when_in_the_git-annex_assistant_you___34__Add_another_local_repository__34___on_an_existing_repository__63__/comment_1_d844cfe5f9907a766e871b64d68966c2._comment
new file mode 100644
index 0000000000..0c70448895
--- /dev/null
+++ b/doc/forum/What_happens_when_in_the_git-annex_assistant_you___34__Add_another_local_repository__34___on_an_existing_repository__63__/comment_1_d844cfe5f9907a766e871b64d68966c2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="71.80.94.56"
+ subject="comment 1"
+ date="2014-02-07T19:03:30Z"
+ content="""
+Sure, you can use that menu item. If you try it out and enter in the path of a repository, you'll see that it offers to either let you combine the two repositories together, or leave them as two unconnected repositories with different files managed by the assistant.
+"""]]
diff --git a/doc/forum/What_is_going_on_here__63__.mdwn b/doc/forum/What_is_going_on_here__63__.mdwn
new file mode 100644
index 0000000000..28dfb43249
--- /dev/null
+++ b/doc/forum/What_is_going_on_here__63__.mdwn
@@ -0,0 +1,187 @@
+Hello,
+
+I was using git-annex some time ago and have just started using it back. I came across a weird difference between an older and the current version of git-annex, which I don't understand.
+Consider this script:
+
+```
+#!/bin/bash -x
+
+repo_url=git@gitlab.com:filipg/test-area5.git
+storage_dir=/home/filipg/storage15
+work_dir=test-area5
+
+git --version
+git-annex version
+
+mkdir $work_dir
+cd $work_dir
+git init
+git annex init
+git remote add origin $repo_url
+echo 'Hello world!' > test.txt
+git add test.txt
+dd if=/dev/urandom of=test.bin bs=1 count=1000000
+git annex add test.bin
+git commit -m 'init'
+git push origin master
+
+mkdir -p $storage_dir
+git annex initremote shared-storage type=directory directory=$storage_dir encryption=none
+ls -l $storage_dir
+git annex copy test.bin --to shared-storage
+ls -l $storage_dir
+
+cd ..
+
+git clone $repo_url ${work_dir}-copy
+cd ${work_dir}-copy
+wc -c test.bin
+
+git annex init
+git annex initremote shared-storage type=directory directory=$storage_dir encryption=none
+ls -l $storage_dir
+git annex get test.bin --from shared-storage
+wc -c test.bin
+```
+
+It works as expected on a machine with an older version of git-annex:
+
+```
+[...]
++ git --version
+git version 2.7.4
++ git-annex version
+git-annex version: 5.20151208-1build1
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA TorrentParser Database
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
++ mkdir test-area8
+[...]
++ wc -c test.bin
+1000000 test.bin
+```
+
+whereas the `test.bin` file is not retrieved on a different machine with a newer version of git-annex:
+
+```
+$ LANG=C ./go.sh
++ repo_url=git@gitlab.com:filipg/test-area5.git
++ storage_dir=/home/filipg/storage15
++ work_dir=test-area5
++ git --version
+git version 2.29.2
++ git-annex version
+git-annex version: 8.20201103-g2dabd4cc2d
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.27 DAV-1.3.4 feed-1.3.0.1 ghc-8.10.2 http-client-0.7.2.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
++ mkdir test-area5
++ cd test-area5
++ git init
+Initialized empty Git repository in /home/filipg/ext/git-annex-test/test-area5/.git/
++ git annex init
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
++ git remote add origin git@gitlab.com:filipg/test-area5.git
++ echo 'Hello world!'
++ git add test.txt
++ dd if=/dev/urandom of=test.bin bs=1 count=1000000
+1000000+0 records in
+1000000+0 records out
+1000000 bytes (1.0 MB, 977 KiB) copied, 1.55659 s, 642 kB/s
++ git annex add test.bin
+add test.bin
+ok
+(recording state in git...)
++ git commit -m init
+[master (root-commit) ae9c146] init
+ 2 files changed, 2 insertions(+)
+ create mode 120000 test.bin
+ create mode 100644 test.txt
++ git push origin master
+Enumerating objects: 4, done.
+Counting objects: 100% (4/4), done.
+Delta compression using up to 8 threads
+Compressing objects: 100% (3/3), done.
+Writing objects: 100% (4/4), 363 bytes | 363.00 KiB/s, done.
+Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
+remote:
+remote:
+remote: The private project filipg/test-area5 was successfully created.
+remote:
+remote: To configure the remote, run:
+remote:   git remote add origin git@gitlab.com:filipg/test-area5.git
+remote:
+remote: To view the project, visit:
+remote:   https://gitlab.com/filipg/test-area5
+remote:
+remote:
+remote:
+To gitlab.com:filipg/test-area5.git
+ * [new branch]      master -> master
++ mkdir -p /home/filipg/storage15
++ git annex initremote shared-storage type=directory directory=/home/filipg/storage15 encryption=none
+
+  Unable to parse git config from origin
+
+  Remote origin does not have git-annex installed; setting annex-ignore
+
+  This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote origin
+initremote shared-storage ok
+(recording state in git...)
++ ls -l /home/filipg/storage15
+total 0
++ git annex copy test.bin --to shared-storage
+copy test.bin (to shared-storage...)
+ok
+(recording state in git...)
++ ls -l /home/filipg/storage15
+total 8
+drwxr-xr-x 3 filipg filipg 4096 Nov 29 20:56 9c0
+drwxr-xr-x 2 filipg filipg 4096 Nov 29 20:56 tmp
++ cd ..
++ git clone git@gitlab.com:filipg/test-area5.git test-area5-copy
+Cloning into 'test-area5-copy'...
+remote: Enumerating objects: 4, done.
+remote: Counting objects: 100% (4/4), done.
+remote: Compressing objects: 100% (3/3), done.
+remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
+Receiving objects: 100% (4/4), done.
++ cd test-area5-copy
++ wc -c test.bin
+wc: test.bin: No such file or directory
++ git annex init
+init  (scanning for unlocked files...)
+
+  Unable to parse git config from origin
+
+  Remote origin does not have git-annex installed; setting annex-ignore
+
+  This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote origin
+ok
+(recording state in git...)
++ git annex initremote shared-storage type=directory directory=/home/filipg/storage15 encryption=none
+initremote shared-storage ok
+(recording state in git...)
++ ls -l /home/filipg/storage15
+total 8
+drwxr-xr-x 3 filipg filipg 4096 Nov 29 20:56 9c0
+drwxr-xr-x 2 filipg filipg 4096 Nov 29 20:56 tmp
++ git annex get test.bin --from shared-storage
++ wc -c test.bin
+wc: test.bin: No such file or directory
+```
+
+Any ideas? Was there a substantial model in git-annex conceptual model between the version 5 and 8?
+
+
+
+
+
+
+ 
diff --git a/doc/forum/What_is_going_on_here__63__/comment_1_499bf04c32c86a747bd7c38d13f5de50._comment b/doc/forum/What_is_going_on_here__63__/comment_1_499bf04c32c86a747bd7c38d13f5de50._comment
new file mode 100644
index 0000000000..b6f5b083da
--- /dev/null
+++ b/doc/forum/What_is_going_on_here__63__/comment_1_499bf04c32c86a747bd7c38d13f5de50._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2020-11-29T20:57:25Z"
+ content="""
+From a quick glance, you don't sync the `git-annex` branch (which tracks the location of files) across the two repos, so the 2nd repo doesn't know that the file is in the `shared-storage` remote. I suspect that `git annex get` silently skips the file, see this excerpt from the [[git-annex-get]] manpage:
+>* `--from=remote`
+>
+>  Normally git-annex will choose which remotes to get the content
+>  from, preferring remotes with lower costs. Use this option to specify
+>  which remote to use. 
+>  
+>  **Any files that are not available on the remote will be silently skipped.**
+
+If you don't pass the `--from=` option, it will probably complain that the there are no known copies of the file instead. <br>
+Instead, I suggest you to keep the `git-annex` branch in sync with `git annex sync --only-annex`. It can also directly get/copy the files if you pass the `--content` option.
+"""]]
diff --git a/doc/forum/What_is_going_on_here__63__/comment_2_0acd71ec48c69da62886e69afa496120._comment b/doc/forum/What_is_going_on_here__63__/comment_2_0acd71ec48c69da62886e69afa496120._comment
new file mode 100644
index 0000000000..daad155a80
--- /dev/null
+++ b/doc/forum/What_is_going_on_here__63__/comment_2_0acd71ec48c69da62886e69afa496120._comment
@@ -0,0 +1,54 @@
+[[!comment format=mdwn
+ username="filipg@7e6a4a5ad3a393bcea174bf8fd6664deffc76c25"
+ nickname="filipg"
+ avatar="http://cdn.libravatar.org/avatar/3eae35237b5c224a29148e6debacb5f9"
+ subject="comment 2"
+ date="2020-11-30T07:20:34Z"
+ content="""
+Thanks, Lukey, for your comment. It helped indeed, this works:
+
+```
+#!/bin/bash -x
+
+repo_url=git@gitlab.com:filipg/test-area9.git
+storage_dir=/home/filipg/storage19
+work_dir=test-area9
+
+git --version
+git-annex version
+
+mkdir $work_dir
+cd $work_dir
+git init
+git annex init
+git remote add origin $repo_url
+echo 'Hello world!' > test.txt
+git add test.txt
+dd if=/dev/urandom of=test.bin bs=1 count=1000000
+git annex add test.bin
+git commit -m 'init'
+git push origin master
+
+mkdir -p $storage_dir
+git annex initremote shared-storage type=directory directory=$storage_dir encryption=none
+ls -l $storage_dir
+git annex copy test.bin --to shared-storage
+ls -l $storage_dir
+git annex sync --only-annex
+
+cd ..
+
+git clone $repo_url ${work_dir}-copy
+cd ${work_dir}-copy
+wc -c test.bin
+
+git annex init
+git annex sync --only-annex
+git annex enableremote shared-storage type=directory directory=$storage_dir encryption=none
+ls -l $storage_dir
+git annex get test.bin --from shared-storage
+wc -c test.bin
+```
+
+But still the question why the previous version worked in git-annex 5 remains... So you can't specify remotes in such a way (manually, without syncing) in git-annex 8?
+"""]]
diff --git a/doc/forum/What_is_going_on_here__63__/comment_3_a1221c0a0585b7e60643a8e4a50b282b._comment b/doc/forum/What_is_going_on_here__63__/comment_3_a1221c0a0585b7e60643a8e4a50b282b._comment
new file mode 100644
index 0000000000..b96052df0f
--- /dev/null
+++ b/doc/forum/What_is_going_on_here__63__/comment_3_a1221c0a0585b7e60643a8e4a50b282b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2020-11-30T07:36:40Z"
+ content="""
+You could set the `remote.<name>.annex-speculate-present` git config to true and try again.
+"""]]
diff --git a/doc/forum/What_is_going_on_here__63__/comment_4_a9fa5282774cc32ece9196b864435957._comment b/doc/forum/What_is_going_on_here__63__/comment_4_a9fa5282774cc32ece9196b864435957._comment
new file mode 100644
index 0000000000..0e9cc37113
--- /dev/null
+++ b/doc/forum/What_is_going_on_here__63__/comment_4_a9fa5282774cc32ece9196b864435957._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-12-15T17:08:21Z"
+ content="""
+git-annex initremote creates a *new* special remote. 
+(Back in version 4.20130501, initremote was also used
+to enable an existing special remote so maybe you're remembering that, but
+that was well before v5 anyway.)
+
+So, when you clone your gitlab repo, which you have not pushed the
+git-annex branch to, and then initremote shared-storage, you are making a
+brand new remote, not enabling the one you created earlier. 
+(If you had pushed the git-annex branch, the second initremote would
+have complained that there was already a special remote by that name.) 
+
+It's not possible that this brand new remote contains the content of
+test.bin, at least as far as git-annex knows. Because it's brand new, and
+so, presumably empty.
+
+I'm not sure what specific thing in the older version of git-annex
+might have made that appear to work. But it certianly seems that
+what you're doing does not make any sense, and I would not have expected
+it to work with any version of git-annex.
+
+Nothing to do with v5 or v8 repository mode has anything to do with
+this, certianly.
+"""]]
diff --git a/doc/forum/What_is_going_on_here__63__/comment_5_8e35d10c208d0d1e93254a1a275fcba6._comment b/doc/forum/What_is_going_on_here__63__/comment_5_8e35d10c208d0d1e93254a1a275fcba6._comment
new file mode 100644
index 0000000000..9a25ac9a23
--- /dev/null
+++ b/doc/forum/What_is_going_on_here__63__/comment_5_8e35d10c208d0d1e93254a1a275fcba6._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-12-15T17:53:40Z"
+ content="""
+Seems that 5.20151208 (I tried it) attempts to get content from the remote
+specified with --from even though the git-annex branch's location log 
+doesn't say the remote contains that content. It stats the expected
+location on the remote, notices there's a file there, and ignores the
+location log.
+
+That was changed in [[!commit cd1676d6048ff7307518df94ea22a23e711be29d]],
+and the change had a good reason motivating it. It would be possible to add
+back a check of Remote.hasKeyCheap when the location log doesn't think it
+has a copy, but that would make every copy from a directory remote slower
+to handle this edge case and I don't think that's warranted.
+
+As noted, annex-speculate-present does work if you really need that for
+some reason.
+" ""]]
diff --git a/doc/forum/What_is_going_on_here__63__/comment_6_536adad665f481a15d4096360d0106c1._comment b/doc/forum/What_is_going_on_here__63__/comment_6_536adad665f481a15d4096360d0106c1._comment
new file mode 100644
index 0000000000..6c209adf4f
--- /dev/null
+++ b/doc/forum/What_is_going_on_here__63__/comment_6_536adad665f481a15d4096360d0106c1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-12-15T18:42:30Z"
+ content="""
+On second thought, it can check as before and only
+if the remote doesn't have the key, fall back to using information from the
+log. That will be faster, and will avoid changing the behavior you were
+relying on. Implemented that.
+"""]]
diff --git a/doc/forum/What_is_the_assistant_up_to__63__.mdwn b/doc/forum/What_is_the_assistant_up_to__63__.mdwn
new file mode 100644
index 0000000000..623268f7e4
--- /dev/null
+++ b/doc/forum/What_is_the_assistant_up_to__63__.mdwn
@@ -0,0 +1,5 @@
+Is there a way to see what the assistant is doing right now, what failed, etc. ?
+I am running the assistant on a remote server so the Webapp's interface is not easily available.
+
+I was hoping to have something that is easier to read than the daemon.log
+
diff --git a/doc/forum/What_is_the_assistant_up_to__63__/comment_1_9baa0e54c19105c7cce946c19c587866._comment b/doc/forum/What_is_the_assistant_up_to__63__/comment_1_9baa0e54c19105c7cce946c19c587866._comment
new file mode 100644
index 0000000000..f007f5d301
--- /dev/null
+++ b/doc/forum/What_is_the_assistant_up_to__63__/comment_1_9baa0e54c19105c7cce946c19c587866._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="marekj"
+ avatar="http://cdn.libravatar.org/avatar/65a60e8f5183feeeef8cef815bf73e61"
+ subject="git annex info"
+ date="2016-12-21T12:58:37Z"
+ content="""
+I found that git annex info provides information on current transfers. Using -F it provides what I want.
+"""]]
diff --git a/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__.mdwn b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__.mdwn
new file mode 100644
index 0000000000..6dd5c16df3
--- /dev/null
+++ b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__.mdwn
@@ -0,0 +1 @@
+Since all the annexed (in indirect mode) files are symlinks to topdir/.git/annex/...   moving files among directories at different levels is not that straightforward since symlinks would get broken.  And since there is not 'annex mv' command -- what is the best way?  (unlock is not the resolution since it copies the file, which might be prohibitively large and inefficient)
diff --git a/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_1_02d305f307b4d2ff7acd98cb36508a2f._comment b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_1_02d305f307b4d2ff7acd98cb36508a2f._comment
new file mode 100644
index 0000000000..9eae8ef7ab
--- /dev/null
+++ b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_1_02d305f307b4d2ff7acd98cb36508a2f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-06-12T16:42:54Z"
+ content="""
+You can move the symlinks however you like (git mv, or regular mv and git add).
+
+To fix up broken symlinks, you can either run `git annex fix`, or just commit the move. The pre-commit hook fixes up links automatically.
+"""]]
diff --git a/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_2_9f7daf0a3e53b2cf64b2b64ca6fbfd9b._comment b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_2_9f7daf0a3e53b2cf64b2b64ca6fbfd9b._comment
new file mode 100644
index 0000000000..b21a63d33d
--- /dev/null
+++ b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_2_9f7daf0a3e53b2cf64b2b64ca6fbfd9b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="Rationale behind deleting and readding the symlinks on a move or rename"
+ date="2020-08-20T18:36:47Z"
+ content="""
+I couldn't find an explanation for this using the search bar, so I thought this would be as good a place as any to ask this.
+
+Even when I run `git mv` on git annexed file, git annex always changes it for what looks like a combo of `git rm old_symlink; git add new_symlink`
+
+I guess it does this when that pre-commit hook you mentioned runs.
+Why?
+"""]]
diff --git a/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_3_06b137018b4c995afc8891032704c1d8._comment b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_3_06b137018b4c995afc8891032704c1d8._comment
new file mode 100644
index 0000000000..e0bc699a9a
--- /dev/null
+++ b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_3_06b137018b4c995afc8891032704c1d8._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="comment 3"
+ date="2020-08-20T20:08:05Z"
+ content="""
+Correction:
+
+Why do moves that require changes to the symlinks to change result in a delete+add combo?
+
+Code to reproduce just for the sake of completion:
+
+```bash
+mkdir protein
+echo whey > protein/milk
+
+git init
+git annex init
+git annex add
+git commit -m \"asd\"
+
+# perfectly normal rename
+git mv protein amino-acids
+git commit -m changed
+# rename {protein => amino-acids}/milk (100%)
+
+# behavior I don't get
+git mv amino-acids/milk atoms
+git commit -m hmmm
+# delete mode 120000 amino-acids/milk
+# create mode 120000 atoms
+```
+
+I'm sorry if this has been already explained previously.
+I couldn't find it.
+"""]]
diff --git a/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_4_138d9067831e26407404b993199d5a0f._comment b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_4_138d9067831e26407404b993199d5a0f._comment
new file mode 100644
index 0000000000..3152b5e5f0
--- /dev/null
+++ b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_4_138d9067831e26407404b993199d5a0f._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 4"
+ date="2020-08-20T20:34:23Z"
+ content="""
+Git tracks the symlink.  After your first commit, here's what is
+tracked for protein/milk:
+
+```
+$ git show HEAD:protein/milk
+../.git/annex/objects/M4/kf/SHA256E-s5--ccfd6ff816d055a64ff4421370d71bc5cdb2a1e0a8afa62b69bb52dd0781f00c/SHA256E-s5--ccfd6ff816d055a64ff4421370d71bc5cdb2a1e0a8afa62b69bb52dd0781f00c
+```
+
+And after your second commit:
+
+```
+$ git show HEAD:amino-acids/milk
+../.git/annex/objects/M4/kf/SHA256E-s5--ccfd6ff816d055a64ff4421370d71bc5cdb2a1e0a8afa62b69bb52dd0781f00c/SHA256E-s5--ccfd6ff816d055a64ff4421370d71bc5cdb2a1e0a8afa62b69bb52dd0781f00c
+```
+
+Note that it's exactly the same content, and Git will (by default)
+present it as a rename.
+
+In your final commit, the link that Git tracks changes:
+
+```
+$ git show HEAD:atoms
+.git/annex/objects/M4/kf/SHA256E-s5--ccfd6ff816d055a64ff4421370d71bc5cdb2a1e0a8afa62b69bb52dd0781f00c/SHA256E-s5--ccfd6ff816d055a64ff4421370d71bc5cdb2a1e0a8afa62b69bb52dd0781f00c
+```
+
+Notice that the leading part of the link changed, corresponding to the
+movement out of the subdirectory.
+
+"""]]
diff --git a/doc/forum/What_is_the_difference_between___34__local_computer__34___and___34__remote_server__34__.mdwn b/doc/forum/What_is_the_difference_between___34__local_computer__34___and___34__remote_server__34__.mdwn
new file mode 100644
index 0000000000..7222e07b58
--- /dev/null
+++ b/doc/forum/What_is_the_difference_between___34__local_computer__34___and___34__remote_server__34__.mdwn
@@ -0,0 +1,3 @@
+What is the difference between "local computer" and "remote server" in the assistant's repository configuration menu? How does git-annex treat the targets differently? 
+
+
diff --git a/doc/forum/What_is_the_difference_between___34__local_computer__34___and___34__remote_server__34__/comment_1_68734a118b7dc0c88ba67eca20953a55._comment b/doc/forum/What_is_the_difference_between___34__local_computer__34___and___34__remote_server__34__/comment_1_68734a118b7dc0c88ba67eca20953a55._comment
new file mode 100644
index 0000000000..167d008f9a
--- /dev/null
+++ b/doc/forum/What_is_the_difference_between___34__local_computer__34___and___34__remote_server__34__/comment_1_68734a118b7dc0c88ba67eca20953a55._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 1"
+ date="2013-01-25T22:39:20Z"
+ content="""
+Local computer pairs with another computer on your LAN. You don't need an account on that computer, it can belong to someone else and has to be running the webapp as well for them to verify the pairing. 
+
+Remote server is for people with a ssh server out there, and does not require it be running the assistant, or even have git-annex installed. (Though it works better if at least git-annex is installed on it.)
+"""]]
diff --git a/doc/forum/What_operations_are_safe_to_interrupt__63__.mdwn b/doc/forum/What_operations_are_safe_to_interrupt__63__.mdwn
new file mode 100644
index 0000000000..ea89f8e277
--- /dev/null
+++ b/doc/forum/What_operations_are_safe_to_interrupt__63__.mdwn
@@ -0,0 +1,34 @@
+# Context
+
+* Git annex does a lot under the hood: replace files with symlinks, check and adjust moved links, etc.
+* Git annex allows to mix and match with plain git commands.
+* Operations may be interrupted by signal (Ctrl-C), by network failure (especially in mobile situation), by power failure (laptop on battery).
+
+Git itself is mostly transactional: most actions can be interrupted and everything looks like they were never started.
+
+I'm confident that you Joey have an eye for details and do the safe thing.  Yet parameters above open up for a lot of combinations, some of which might not actually do what's intended, or are perhaps safe only for someone who knows where *not* to put a foot.
+
+# Example
+
+For example, nearly 5 years ago you wrote about interrupted `git annex add`: in [git annex add crash and subsequent recovery](https://git-annex.branchable.com/forum/git_annex_add_crash_and_subsequent_recovery/) 
+
+> Thought I'd mention how to clean up from interrupting git annex add. When you do that, it doesn't get a chance to git add the files it's added (this is normally done at the end, or sometimes at points in the middle when you're adding a lot of files). Which is also why fsck, whereis, and unannex wouldn't operate on them, since they only deal with files in git.
+> So the first step is to manually use git add on any symlinks.
+>  I've made git annex add recover when ran a second time. 
+
+# Questions
+
+* Which operations are safe to interrupt? What will be the result? No change? Partial but valid result? Messy result? With what consequences?
+* What operations should *not* be performed after an interrupted one?
+
+For example, let's say I've started a `git annex sync`. While it works, I realize there are unwanted changes. If I interrupt what is the result? Can I safely use manual git commands to add or remove some files to index, make separated commits, then git sync again?
+
+I'm using a v5 repository, indirect mode, mixed content. Is it different in v6? In direct mode? In mixed vs non-mixed content repository?
+
+# Wish a dedicated page in git-annex documentation
+
+IMHO this is an important, difficult and changing topic, which would deserve its own "when things go wrong" topic pages, like [fsck: when things go wrong](https://git-annex.branchable.com/walkthrough/fsck__58___when_things_go_wrong/) and [transferring files: When things go wrong](https://git-annex.branchable.com/walkthrough/transferring_files__58___When_things_go_wrong/).
+
+Perhaps just starting with broad rules like "Commands foo and bar are ok, baz is mostly ok just repeat it" or "in any on-trivial case, do `git annex sync` last after you check twice that any necessary commit is done" would be very appreciated.
+
+Thank you.
diff --git a/doc/forum/What_operations_are_safe_to_interrupt__63__/comment_1_03d8ddc049cf073e5579ca829b352367._comment b/doc/forum/What_operations_are_safe_to_interrupt__63__/comment_1_03d8ddc049cf073e5579ca829b352367._comment
new file mode 100644
index 0000000000..432db2626c
--- /dev/null
+++ b/doc/forum/What_operations_are_safe_to_interrupt__63__/comment_1_03d8ddc049cf073e5579ca829b352367._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-07T14:43:46Z"
+ content="""
+Note that git is not entirely robust against being interrupted.
+In particular, interrupting a commit can leave a stale lock file in place,
+and committing will then fail until the user manually goes in and removes
+the lock file.
+
+I'd say that git-annex is overall more robust against interruptions
+than git is, except that git-annex uses git so of course inherits 
+its limitations.
+
+git-annex tries to handle all interruptions sanely. Ie, files are always
+moved into place atomically so partial writes are not a problem, stale lock
+files are not a problem, and any recordkeeping that might be lost by an
+interruption should be able to be recovered by running the interrupted
+command again, or perhaps `git annex fsck`.
+
+The only problem that I can think of with interuptions is that
+since git-annex uses temp files in `.git/annex/tmp` extensively, 
+if it's interrupted nothing will clean up those temp files.
+"""]]
diff --git a/doc/forum/What_operations_are_safe_to_interrupt__63__/comment_2_207435949b2674ea82390c66549873e5._comment b/doc/forum/What_operations_are_safe_to_interrupt__63__/comment_2_207435949b2674ea82390c66549873e5._comment
new file mode 100644
index 0000000000..42d1aa4c5f
--- /dev/null
+++ b/doc/forum/What_operations_are_safe_to_interrupt__63__/comment_2_207435949b2674ea82390c66549873e5._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="psxvoid"
+ avatar="http://cdn.libravatar.org/avatar/fde068fbdeabeea31e3be7aa9c55d84b"
+ subject="The issue with slow connection and huge repo - no batches"
+ date="2023-12-27T06:08:59Z"
+ content="""
+This issue is quite important when you reach a certain point/scenarios.
+
+I'm using a git annex repo that have ~300GB of annexed files; I wanted to push them to a remote server in another country.
+This server has limited bandwidth around 1MB/s. I also have a limited data plan at home. That is why I was planning to
+`git annex copy --to my-slow-remote-server` at work, were the data plan is unlimited. But after spending around 4 hours
+during the copy I realized that when I do `Ctrl+C` then the copy operation interrupts and it seems like it's not resumable,
+because \"git annex\" does not record any state in git after interrupting the copy operation.
+
+To solve this issue I'm planning to write a custom script - similar to [finding duplicate files](https://git-annex.branchable.com/tips/finding_duplicate_files/).
+The goal of this script would be:
+
+1. To \"split\" large files by their size (e.g. bigger than 5GB) using `git annex find=*`, and upload them individually.
+2. To \"split\" small files by folders in batches (e.g. 5GB), and then do `cd <dir> & git annex copy . --to my-slow-remote-server`
+
+It will allow me to upload all files in batches in a course of several days/weeks.
+But I it will also probably take me a weekend or more to handle it correctly.
+
+So, the questions are:
+
+1. Are there any easier ways to upload huge repo on a slow connection in batches?
+2. Is there anything in progress or planned that will solve this issue?
+"""]]
diff --git a/doc/forum/What_operations_are_safe_to_interrupt__63__/comment_4_279302a0f5bb0a8d8d87182e03c6b475._comment b/doc/forum/What_operations_are_safe_to_interrupt__63__/comment_4_279302a0f5bb0a8d8d87182e03c6b475._comment
new file mode 100644
index 0000000000..9349051f0f
--- /dev/null
+++ b/doc/forum/What_operations_are_safe_to_interrupt__63__/comment_4_279302a0f5bb0a8d8d87182e03c6b475._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="psxvoid"
+ avatar="http://cdn.libravatar.org/avatar/fde068fbdeabeea31e3be7aa9c55d84b"
+ subject="Works: Try annex.queuesize and --not --in"
+ date="2023-12-28T05:33:13Z"
+ content="""
+> \"setting `annex.queuesize` to a low value to commit more frequently to the git-annex branch (I think that it does that)\"
+
+Aha, that what I missed!
+
+> \"(maybe that confused you)\"
+
+Indeed, my original observations weren't entirely correct. Seems like git annex does record it's state periodically.
+For some big files where copying took ~1 hour, after running `git annex copy` again it was done almost
+immediately. And as you suggested `--not --in=slowremote` should speedup the initial process.
+
+It laterally saved me hours, thanks a lot!
+
+P.S.: Still, it may be probably a good idea to record the progress state to git annex on `ctrl+c` and show a friendly message e.g. \"The operation is interrupted and the progress is recorded. You can safely resume it by running `git annex copy` again.\"
+"""]]
diff --git a/doc/forum/What_operations_are_safe_to_interrupt__63__/comment_5_8d36d42e34f5deae04bfa83c568b89d5._comment b/doc/forum/What_operations_are_safe_to_interrupt__63__/comment_5_8d36d42e34f5deae04bfa83c568b89d5._comment
new file mode 100644
index 0000000000..2c5641bc82
--- /dev/null
+++ b/doc/forum/What_operations_are_safe_to_interrupt__63__/comment_5_8d36d42e34f5deae04bfa83c568b89d5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Try annex.queuesize and --not --in"
+ date="2023-12-27T07:51:00Z"
+ content="""
+Git annex can normally resume any operation seamlessly. It can resume from aborted copying and shouldn't need to start over. I suggest:
+
+- setting [annex.queuesize](https://git-annex.branchable.com/git-annex/) to a low value to commit more frequently to the `git-annex` branch (I think that it does that)
+- skipping already-present files by specifying `git annex --copy --to=slowremote --not --in=slowremote`, that should speed up the initial phase of finding what to copy and also not display the files that are already copied (maybe that confused you)
+"""]]
diff --git a/doc/forum/What_to_do_if_special_remotes_refuses_drops__63__.mdwn b/doc/forum/What_to_do_if_special_remotes_refuses_drops__63__.mdwn
new file mode 100644
index 0000000000..512e89528c
--- /dev/null
+++ b/doc/forum/What_to_do_if_special_remotes_refuses_drops__63__.mdwn
@@ -0,0 +1,9 @@
+I have a special remote that I would like to delete and have marked it as such in the assistant. Although this was before my myriad of problems with git annex itself wanting to repair the repo all the time. Right now if I take a loog into my daemon.log I see the following error over and over again:
+
+```
+drop skydrive foo.bar 
+  This file could not be removed
+failed
+```
+
+I checked if I can login into my account and it works just fine. So I assume that this might be a bug? Is it somehow possible to forego the cleaning out of the special remote and just mark it as deleted for good? Thanks in advance!
diff --git a/doc/forum/What_to_do_if_special_remotes_refuses_drops__63__/comment_1_0b523b2b6c361346c36ad456bbbac645._comment b/doc/forum/What_to_do_if_special_remotes_refuses_drops__63__/comment_1_0b523b2b6c361346c36ad456bbbac645._comment
new file mode 100644
index 0000000000..cf808aac4b
--- /dev/null
+++ b/doc/forum/What_to_do_if_special_remotes_refuses_drops__63__/comment_1_0b523b2b6c361346c36ad456bbbac645._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-18T15:39:20Z"
+ content="""
+It could certianly be a bug in the special remote implementation. It's also
+possible for some special remotes to intentionally not be able to remove
+content (this is the case with the web special remote, and the bup special
+remote at least).
+
+You can manually remove the special remote, by editing .git/config and
+deleting the stanza for that remote. You may want to run `git annex dead
+$remotename` first, if you don't intend to ever use that special remote
+again.
+"""]]
diff --git a/doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__.mdwn b/doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__.mdwn
new file mode 100644
index 0000000000..1504d10cd6
--- /dev/null
+++ b/doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__.mdwn
@@ -0,0 +1 @@
+What do I do when I have set up git-annex to back up a folder to an encrypted remote on a vps, and my laptop was stolen? This recently happened, and luckally I had another backup, but what would I do in the case that I have 1 computer using git-annex, backung ip a folder to an encrypted ssh remote on a vps, and I loose the computer? How do I get the data back then?
diff --git a/doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__/comment_1_67ee446ca6d66e2c259ea771c2c9a2b2._comment b/doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__/comment_1_67ee446ca6d66e2c259ea771c2c9a2b2._comment
new file mode 100644
index 0000000000..832c931b42
--- /dev/null
+++ b/doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__/comment_1_67ee446ca6d66e2c259ea771c2c9a2b2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 1"
+ date="2013-07-26T03:57:06Z"
+ content="""
+I'm glad you had another backup. That is wise.
+
+When you have a special remote, that does not store your git repository, but only the contents of files. So if you lose all copies of your git repositories, you have lost all record of the file name associated with a file. It's the same as if `fsck` rescued inodes to `lost+found`; you'd have to manually rename the files to new names.
+
+Then there's the added complication of the encryption. This depends on how it was set up. If you set up the remote using a GPG key (and didn't lose the key too), you can manually use that key to decrypt the files. On the other hand, if it generated its own key and stored it in the git repo (default with the assistant), then when you lose all copies of the git repo, the key is gone, and your encrypted files are useless.
+"""]]
diff --git a/doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__/comment_2_6d3cce3c8048e4aea8f0ed76473f6af1._comment b/doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__/comment_2_6d3cce3c8048e4aea8f0ed76473f6af1._comment
new file mode 100644
index 0000000000..308df9a182
--- /dev/null
+++ b/doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__/comment_2_6d3cce3c8048e4aea8f0ed76473f6af1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 2"
+ date="2013-07-26T15:04:31Z"
+ content="""
+I thought the key was checked into .git in any case, but encrypted in the case of GPG.  So .git gone => everything gone in any case.
+"""]]
diff --git a/doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__/comment_3_bd506e1ca7307660b3b9769eb97beddb._comment b/doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__/comment_3_bd506e1ca7307660b3b9769eb97beddb._comment
new file mode 100644
index 0000000000..4591a559e0
--- /dev/null
+++ b/doc/forum/What_to_do_when_computer_is_lost_and_only_an_encrypted_ssh_remote_is_left__63__/comment_3_bd506e1ca7307660b3b9769eb97beddb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 3"
+ date="2013-07-26T16:45:26Z"
+ content="""
+Michael, you're right. Thanks for fact checking my late night comment! ;)
+"""]]
diff --git a/doc/forum/When_--git-dir_is_not_in_--work-tree.mdwn b/doc/forum/When_--git-dir_is_not_in_--work-tree.mdwn
new file mode 100644
index 0000000000..65fd55d3e7
--- /dev/null
+++ b/doc/forum/When_--git-dir_is_not_in_--work-tree.mdwn
@@ -0,0 +1,108 @@
+
+First of all: Thank you **VERY** much for `git-annex`, it's awesome.
+
+I am running into a weird problem where `git-annex init` complains that `Git refuses to operate in this repository` (in turn because `--local can only be used inside a git repository`) in a setup with separated `--git-dir` and `--work-tree` (a pretty usual scenario for managing one's dotfiles with a hidden bare git repository checked out to `$HOME`):
+
+## Environment
+
+I am running Manjaro/Arch Linux. For reproducibility, here is a Docker setup:
+
+```Dockerfile
+FROM archlinux
+
+RUN pacman -Syu --noconfirm git-annex
+```
+
+```bash
+sudo docker build -t archlinux-with-git-annex .
+```
+
+## `git-annex` works in a normal setup
+
+```bash
+sudo docker run --rm archlinux-with-git-annex sh -xc 'git config --global init.defaultBranch main;mkdir repo;cd repo;git init;git config user.email me@example.com;git config user.name Me;git annex init'
+```
+
+```bash
++ git config --global init.defaultBranch main
++ mkdir repo
++ cd repo
++ git init
+Initialized empty Git repository in /repo/.git/
++ git config user.email me@example.com
++ git config user.name Me
++ git annex init
+init  ok
+(recording state in git...)
+```
+
+## `git-annex init` fails when separating `--git-dir` and `--work-tree`
+
+```bash
+sudo docker run --rm archlinux-with-git-annex sh -xc '
+    cd
+    git annex version
+    git config --global init.defaultBranch main
+    function mygit (){ git --git-dir="$HOME/.dotfiles" --work-tree="$HOME" $@; }
+    mygit init
+    mygit annex init
+    git config --global --add safe.directory $HOME
+    GIT_TRACE=1 mygit annex init --debug
+    '
+```
+
+```bash
++ cd
++ git annex version
+git-annex version: 10.20220822-gfa94d41c1
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.0.4 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
++ git config --global init.defaultBranch main
++ mygit init
++ git --git-dir=/root/.dotfiles --work-tree=/root init
+Initialized empty Git repository in /root/.dotfiles/
++ mygit annex init
++ git --git-dir=/root/.dotfiles --work-tree=/root annex init
+init  
+failed
+git-annex: Git refuses to operate in this repository,
+probably because it is owned by someone else.
+
+To add an exception for this directory, call:
+        git config --global --add safe.directory /root
+
+init: 1 failed
++ git config --global --add safe.directory /root
++ GIT_TRACE=1
++ mygit annex init --debug
++ git --git-dir=/root/.dotfiles --work-tree=/root annex init --debug
+12:04:10.518062 git.c:749               trace: exec: git-annex init --debug
+12:04:10.518089 run-command.c:654       trace: run_command: git-annex init --debug
+12:04:10.754502 git.c:460               trace: built-in: git config --null --list
+init  [2022-09-20 12:04:10.756872773] (Utility.Process) process [32] read: git ["config","--local","--list"]
+[2022-09-20 12:04:10.76296344] (Utility.Process) process [32] done ExitFailure 128
+[2022-09-20 12:04:10.763551946] (Git.Config) config output: 12:04:10.758714 git.c:460               trace: built-in: git config --local --list
+fatal: --local can only be used inside a git repository
+
+
+git-annex: Git refuses to operate in this repository,
+probably because it is owned by someone else.
+
+To add an exception for this directory, call:
+        git config --global --add safe.directory /root
+
+failed
+init: 1 failed
+```
+
+
+The `probably because it is owned by someone else.` is obviously not the problem here. Also not the `safe.directory` thing. Setting it to `*` also doesn't help.
+
+I wonder why `git` complains that `--local can only be used inside a git repository`. Sounds like `git-annex` executes `git` in the wrong place when specifying `--git-dir` and/or `--work-tree` or it doesn't propagate it correctly.
+
+Any ideas?
diff --git a/doc/forum/When_--git-dir_is_not_in_--work-tree/comment_1_0169812633d92bed8883e903e03056e3._comment b/doc/forum/When_--git-dir_is_not_in_--work-tree/comment_1_0169812633d92bed8883e903e03056e3._comment
new file mode 100644
index 0000000000..ddfa0d1338
--- /dev/null
+++ b/doc/forum/When_--git-dir_is_not_in_--work-tree/comment_1_0169812633d92bed8883e903e03056e3._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-20T18:08:29Z"
+ content="""
+Simpler test case:
+
+	joey@darkstar:~/src/git-annex>cd /tmp
+	joey@darkstar:/tmp>mkdir foo
+	joey@darkstar:/tmp>cd foo
+	joey@darkstar:/tmp/foo>git --git-dir=`pwd`/.dotfiles --work-tree=`pwd` init
+	Initialized empty Git repository in /tmp/foo/.dotfiles/
+	joey@darkstar:/tmp/foo>git --git-dir=`pwd`/.dotfiles --work-tree=`pwd` annex init
+	init  
+	git-annex: Git refuses to operate in this repository,
+	probably because it is owned by someone else.
+	
+	To add an exception for this directory, call:
+		git config --global --add safe.directory /tmp/foo
+	
+	failed
+
+Anything like this is clearly a bug.
+And this forum is not the place to file bug reports. Doing so risks
+it being forgotten about because who is going to go back and check old
+forum threads to see if they were a bug that didn't get fixed?
+
+Here, I opened a bug report: [[bugs/When_--git-dir_is_not_in_--work-tree]]
+"""]]
diff --git a/doc/forum/When_--git-dir_is_not_in_--work-tree/comment_2_0c101e5b017f56897599c2cbd37b1754._comment b/doc/forum/When_--git-dir_is_not_in_--work-tree/comment_2_0c101e5b017f56897599c2cbd37b1754._comment
new file mode 100644
index 0000000000..6f25880923
--- /dev/null
+++ b/doc/forum/When_--git-dir_is_not_in_--work-tree/comment_2_0c101e5b017f56897599c2cbd37b1754._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2022-09-22T06:24:04Z"
+ content="""
+Thank you joey, you're awesome! 👍
+"""]]
diff --git a/doc/forum/When_to_reuse_UUIDs_and_avoiding_UUID_clutter.mdwn b/doc/forum/When_to_reuse_UUIDs_and_avoiding_UUID_clutter.mdwn
new file mode 100644
index 0000000000..fc5b75ff15
--- /dev/null
+++ b/doc/forum/When_to_reuse_UUIDs_and_avoiding_UUID_clutter.mdwn
@@ -0,0 +1,15 @@
+I wanted to discuss cases for UUID reuse
+
+One reason is to mutate a special remote type. For example, a directory special remote to an rsync special remote and vice versa, passing along the uuid argument to initremote. Changing the directory layout is not hard. And you may wish to re-layout your .git/annex/objects directory to a different directory prefix and upload it to a cloud provider. If it supports an rclone remote that has hashing, you can verify it without having to redownload.
+
+Another good reason is to reuse a uuid is to avoid uuid namespace clutter.
+If you know ahead of time that you are storing data in repos that may later be merged, it makes sense to have a template annex repo to base a new repo off of, as well as store common settings and uuids.
+
+For example, I have a uuid space for multimedia annexes (peertube, youtube, podcasts, etc).
+
+The template comes preloaded with a uuid.log and remote.log. If my hostname is in the uuid.log, I reinit with that.
+
+If I must merge unrelated histories with conflicting name/uuid values, I first prefix my names with something. After a merge, I can do some gymnastics to make sure that the proper keys are set present for the respective uuid/name that I have chosen, and make the obsolete uuid/name dead. Simply making them dead is not enough, because even if a special remote uuid is marked dead, if the name is the same, it will still cause a conflict, so prefixing uuid/name collisions is importnat.
+
+I currently have a several annex template repos for different purposes (disk images, multimedia, etc). I have been meaning to automate this process more.
+
diff --git a/doc/forum/Where_are_my_remote_ssh_files__63__.mdwn b/doc/forum/Where_are_my_remote_ssh_files__63__.mdwn
new file mode 100644
index 0000000000..704f95ff09
--- /dev/null
+++ b/doc/forum/Where_are_my_remote_ssh_files__63__.mdwn
@@ -0,0 +1,10 @@
+<img src=http://s.natalian.org/2015-03-10/where-are-the-files.png>
+
+I managed to sync files to a remote ssh store "bible" with `git annex sync --content` however, where I ssh to bible, I was surprised not to see any of the JPG files that were copied there.
+
+
+What am I missing?
+
+# Solution
+
+I need to run `git annex sync` on the host bible too!
diff --git a/doc/forum/Where_did_my_files_go__63__.mdwn b/doc/forum/Where_did_my_files_go__63__.mdwn
new file mode 100644
index 0000000000..f7d811d8fa
--- /dev/null
+++ b/doc/forum/Where_did_my_files_go__63__.mdwn
@@ -0,0 +1,20 @@
+I import some files that I've seen before somewhere:
+
+    $ git annex import --deduplicate .../download
+    ...
+    import download/What_is_The_Digital_Fiction_Factory-Conker_Media.pdf (duplicate) ok
+    ...
+
+But the resulting download directory is empty, and `list` doesn't show any of the files:
+
+    $ git annex list --allrepos What_is_The_Digital_Fiction_Factory-Conker_Media.pdf
+    here
+    |...
+    |...
+    |...
+    |...
+    |...
+    |...
+    git-annex: What_is_The_Digital_Fiction_Factory-Conker_Media.pdf not found
+
+How do I find out where this file can be found?
diff --git a/doc/forum/Where_did_my_files_go__63__/comment_1_3ff3ffa95eb2745ff9ec2a903e071d97._comment b/doc/forum/Where_did_my_files_go__63__/comment_1_3ff3ffa95eb2745ff9ec2a903e071d97._comment
new file mode 100644
index 0000000000..f0b2ae3e7e
--- /dev/null
+++ b/doc/forum/Where_did_my_files_go__63__/comment_1_3ff3ffa95eb2745ff9ec2a903e071d97._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnVnsqEy82M-MuS2gLri-az83wSQ6lXSrc"
+ nickname="Jean"
+ subject="comment 1"
+ date="2015-05-06T09:21:19Z"
+ content="""
+I did a dump of all known files: `$ git annex whereis > ../git-annex-whereis`
+No sign of the imported file. 
+"""]]
diff --git a/doc/forum/Where_did_my_files_go__63__/comment_2_9d902e66ca19b3332f4454f694d4a12e._comment b/doc/forum/Where_did_my_files_go__63__/comment_2_9d902e66ca19b3332f4454f694d4a12e._comment
new file mode 100644
index 0000000000..b1b186ab98
--- /dev/null
+++ b/doc/forum/Where_did_my_files_go__63__/comment_2_9d902e66ca19b3332f4454f694d4a12e._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-05-06T18:04:35Z"
+ content="""
+I don't think you're using a recent version of git-annex, the "(duplicate)"
+message has changed to something else a while ago.
+
+Also, that message is only shown if you pass the --deduplicate flag, which
+you don't show in your transcript.
+
+That flag does what it says on the tin: If the file is a duplicate of one
+git-annex has seen before, the file is deleted from the import location.
+(The next version of git-annex does add an additional check that the
+content of the file is present in the annex.)
+"""]]
diff --git a/doc/forum/Where_is_the_S3_config__63__.mdwn b/doc/forum/Where_is_the_S3_config__63__.mdwn
new file mode 100644
index 0000000000..fbb2726a47
--- /dev/null
+++ b/doc/forum/Where_is_the_S3_config__63__.mdwn
@@ -0,0 +1,10 @@
+Some time ago I created an S3 remote that uses a Digital Ocean "space", which is S3 compatible. It works fine and I've copied some content there and can get it from there. Before I trust this remote though I want to understand where the configuration is that points it to digital ocean. When I look at .git/config there is this section:
+
+    [remote "cloud"]
+        annex-s3 = true
+        annex-uuid = <a UUID>
+        annex-ignore = false
+
+I've looked around and inside the annex subdirectory but haven't been able to find where the config is stored that I must have entered to create this remote. Is the annex-uuid a key to a database with the config? How do I view it?
+
+Thanks for git-annex BTW
diff --git a/doc/forum/Where_is_the_S3_config__63__/comment_1_63009ad122cfafc9682e06f984eaefe1._comment b/doc/forum/Where_is_the_S3_config__63__/comment_1_63009ad122cfafc9682e06f984eaefe1._comment
new file mode 100644
index 0000000000..f3ecfc3aa0
--- /dev/null
+++ b/doc/forum/Where_is_the_S3_config__63__/comment_1_63009ad122cfafc9682e06f984eaefe1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 1"
+ date="2020-06-23T13:29:37Z"
+ content="""
+Take a look at the git-annex branch, in particular remote.log.
+
+    git cat-file -p git-annex:remote.log
+
+"""]]
diff --git a/doc/forum/Where_is_the_S3_config__63__/comment_2_61403be4cc347fecedd8b19d6604e6d3._comment b/doc/forum/Where_is_the_S3_config__63__/comment_2_61403be4cc347fecedd8b19d6604e6d3._comment
new file mode 100644
index 0000000000..0b247e5a97
--- /dev/null
+++ b/doc/forum/Where_is_the_S3_config__63__/comment_2_61403be4cc347fecedd8b19d6604e6d3._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-06-23T20:10:24Z"
+ content="""
+This is a good question, because where git-annex stores information needed
+to use a special remote varies depending on the special remote, and
+is not really documented very well. But, you can work it out, by thinking
+about the 4 ways git-annex can possibly store it.
+
+1. The git-annex branch's remote.log file is used for most configuration.
+   For a S3 special remote, it's almost all stored there, except for
+   credentials.
+
+2. Credentials, passwords, etc needed to access a special remote may be
+   cached in .git/annex/creds/. The S3 remote stores 
+   the `AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID` there, so it will
+   work without the environment variables set.
+
+   (Sometimes this is also stored in remote.log, but only when you use
+   embedcreds=yes and only when the remote's [[encryption]] makes it safe
+   to do so.)
+
+3. .git/config is only used for configurations that it makes sense be local
+   to a given repository clone. For most special remotes, it does not make
+   sense to store stuff there, but eg, the directory special remote stores
+   the path there, because the path to the special remote can be relative
+   to the git repository.
+
+4. It can not store something, and rely on an environment variable being set,
+   or some program it's using having a config file elsewhere.
+"""]]
diff --git a/doc/forum/Where_is_the_content__63__.mdwn b/doc/forum/Where_is_the_content__63__.mdwn
new file mode 100644
index 0000000000..0d79bbb093
--- /dev/null
+++ b/doc/forum/Where_is_the_content__63__.mdwn
@@ -0,0 +1,8 @@
+On Android 4.4.4, I can install the most recent git annex. I want to join a git annex running on my linux server. Git annex on android seems to be able to contact remote, and it asks if I want to 'merge' with it. I hope that did not mean erase the remote.  Anyway, the sync says it is proceeding, but when it is done, I cannot find a folder with remote copies of files. 
+
+I figure either it worked, or it destroyed my remote. 
+
+After new install, I have folders /sdcard/annex and /sdcard/git-annex.home. I don't find a new folder with name of remote repo, don't understand why.
+
+Help?
+
diff --git a/doc/forum/Where_is_the_content__63__/comment_1_812e1cf740cbfa449ab3ef4dd5f2df08._comment b/doc/forum/Where_is_the_content__63__/comment_1_812e1cf740cbfa449ab3ef4dd5f2df08._comment
new file mode 100644
index 0000000000..423bd82d28
--- /dev/null
+++ b/doc/forum/Where_is_the_content__63__/comment_1_812e1cf740cbfa449ab3ef4dd5f2df08._comment
@@ -0,0 +1,132 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkpIIYg6Fl7OFsOHVPEchZYj68A3dk4lVg"
+ nickname="Paul"
+ subject="install log"
+ date="2014-07-15T12:02:59Z"
+ content="""
+Installation starting to /data/data/ga.androidterm
+ac90d4f57076a59cac3a8017b89ac9b5ab4e5021
+installing busybox
+installing git-annex
+installing git-shell
+installing git-upload-pack
+installing git
+installing gpg
+installing rsync
+installing ssh
+installing ssh-keygen
+linking ./libexec/git-core/git-show to git
+linking ./libexec/git-core/git-cherry-pick to git
+linking ./libexec/git-core/git-revert to git
+linking ./libexec/git-core/git-rerere to git
+linking ./libexec/git-core/git to git
+linking ./libexec/git-core/git-cat-file to git
+linking ./libexec/git-core/git-archive to git
+linking ./libexec/git-core/git-apply to git
+linking ./libexec/git-core/git-repack to git
+linking ./libexec/git-core/git-replace to git
+linking ./libexec/git-core/git-verify-pack to git
+linking ./libexec/git-core/git-name-rev to git
+linking ./libexec/git-core/git-grep to git
+linking ./libexec/git-core/git-format-patch to git
+linking ./libexec/git-core/git-log to git
+linking ./libexec/git-core/git-read-tree to git
+linking ./libexec/git-core/git-fast-export to git
+linking ./libexec/git-core/git-mktag to git
+linking ./libexec/git-core/git-cherry to git
+linking ./libexec/git-core/git-stage to git
+linking ./libexec/git-core/git-blame to git
+linking ./libexec/git-core/git-help to git
+linking ./libexec/git-core/git-tag to git
+linking ./libexec/git-core/git-column to git
+linking ./libexec/git-core/git-clone to git
+linking ./libexec/git-core/git-pack-redundant to git
+linking ./libexec/git-core/git-rev-list to git
+linking ./libexec/git-core/git-ls-files to git
+linking ./libexec/git-core/git-update-index to git
+linking ./libexec/git-core/git-merge-tree to git
+linking ./libexec/git-core/git-shortlog to git
+linking ./libexec/git-core/git-pack-refs to git
+linking ./libexec/git-core/git-fsck to git
+linking ./libexec/git-core/git-mv to git
+linking ./libexec/git-core/git-index-pack to git
+linking ./libexec/git-core/git-upload-archive to git
+linking ./libexec/git-core/git-unpack-file to git
+linking ./libexec/git-core/git-merge-recursive to git
+linking ./libexec/git-core/git-checkout to git
+linking ./libexec/git-core/git-mailsplit to git
+linking ./libexec/git-core/git-whatchanged to git
+linking ./libexec/git-core/git-remote-fd to git
+linking ./libexec/git-core/git-fsck-objects to git
+linking ./libexec/git-core/git-diff to git
+linking ./libexec/git-core/git-diff-tree to git
+linking ./libexec/git-core/git-check-ref-format to git
+linking ./libexec/git-core/git-status to git
+linking ./libexec/git-core/git-annotate to git
+linking ./libexec/git-core/git-bisect--helper to git
+linking ./libexec/git-core/git-mktree to git
+linking ./libexec/git-core/git-check-ignore to git
+linking ./libexec/git-core/git-clean to git
+linking ./libexec/git-core/git-merge to git
+linking ./libexec/git-core/git-var to git
+linking ./libexec/git-core/git-get-tar-commit-id to git
+linking ./libexec/git-core/git-remote-ext to git
+linking ./libexec/git-core/git-stripspace to git
+linking ./libexec/git-core/git-send-pack to git
+linking ./libexec/git-core/git-fetch to git
+linking ./libexec/git-core/git-ls-remote to git
+linking ./libexec/git-core/git-init to git
+linking ./libexec/git-core/git-notes to git
+linking ./libexec/git-core/git-commit to git
+linking ./libexec/git-core/git-receive-pack to git
+linking ./libexec/git-core/git-prune to git
+linking ./libexec/git-core/git-update-server-info to git
+linking ./libexec/git-core/git-gc to git
+linking ./libexec/git-core/git-show-ref to git
+linking ./libexec/git-core/git-merge-subtree to git
+linking ./libexec/git-core/git-describe to git
+linking ./libexec/git-core/git-branch to git
+linking ./libexec/git-core/git-checkout-index to git
+linking ./libexec/git-core/git-prune-packed to git
+linking ./libexec/git-core/git-ls-tree to git
+linking ./libexec/git-core/git-hash-object to git
+linking ./libexec/git-core/git-push to git
+linking ./libexec/git-core/git-for-each-ref to git
+linking ./libexec/git-core/git-verify-tag to git
+linking ./libexec/git-core/git-diff-files to git
+linking ./libexec/git-core/git-check-attr to git
+linking ./libexec/git-core/git-mailinfo to git
+linking ./libexec/git-core/git-check-mailmap to git
+linking ./libexec/git-core/git-fetch-pack to git
+linking ./libexec/git-core/git-diff-index to git
+linking ./libexec/git-core/git-add to git
+linking ./libexec/git-core/git-config to git
+linking ./libexec/git-core/git-merge-ours to git
+linking ./libexec/git-core/git-symbolic-ref to git
+linking ./libexec/git-core/git-init-db to git
+linking ./libexec/git-core/git-pack-objects to git
+linking ./libexec/git-core/git-rm to git
+linking ./libexec/git-core/git-write-tree to git
+linking ./libexec/git-core/git-show-branch to git
+linking ./libexec/git-core/git-fmt-merge-msg to git
+linking ./libexec/git-core/git-count-objects to git
+linking ./libexec/git-core/git-reset to git
+linking ./libexec/git-core/git-reflog to git
+linking ./libexec/git-core/git-rev-parse to git
+linking ./libexec/git-core/git-update-ref to git
+linking ./libexec/git-core/git-patch-id to git
+linking ./libexec/git-core/git-commit-tree to git
+linking ./libexec/git-core/git-merge-file to git
+linking ./libexec/git-core/git-credential to git
+linking ./libexec/git-core/git-unpack-objects to git
+linking ./libexec/git-core/git-bundle to git
+linking ./libexec/git-core/git-merge-index to git
+linking ./libexec/git-core/git-remote to git
+linking ./libexec/git-core/git-merge-base to git
+linking ./bin/git-upload-archive to git
+linking ./bin/git-receive-pack to git
+linking ./libexec/git-core/git-shell to git-shell
+linking ./libexec/git-core/git-upload-pack to git-upload-pack
+Installation complete
+
+"""]]
diff --git a/doc/forum/Where_is_the_content__63__/comment_2_5e2cfdfab6c4f84fe7a19447b417b5a7._comment b/doc/forum/Where_is_the_content__63__/comment_2_5e2cfdfab6c4f84fe7a19447b417b5a7._comment
new file mode 100644
index 0000000000..45b7b024e4
--- /dev/null
+++ b/doc/forum/Where_is_the_content__63__/comment_2_5e2cfdfab6c4f84fe7a19447b417b5a7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 2"
+ date="2014-07-15T18:37:34Z"
+ content="""
+It'll be in `/sdcard/annex` by defualt, unless you told the webapp to put it somewhere else when it asked where to put the repository. `/sdcard/annex` is a git repository which should contain all the files from the remote (not in any separate subdirectory, that's not how git works). If it does not, you can run commands like `git log --stat` in that repository to see what files have been added/removed, or `git annex status` to check the status of the files.
+"""]]
diff --git a/doc/forum/Where_is_the_content__63__/comment_3_bd4cbc8f256a94ffde4f57d2c406a9ec._comment b/doc/forum/Where_is_the_content__63__/comment_3_bd4cbc8f256a94ffde4f57d2c406a9ec._comment
new file mode 100644
index 0000000000..5b736b4100
--- /dev/null
+++ b/doc/forum/Where_is_the_content__63__/comment_3_bd4cbc8f256a94ffde4f57d2c406a9ec._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkpIIYg6Fl7OFsOHVPEchZYj68A3dk4lVg"
+ nickname="Paul"
+ subject="text relocations refusal"
+ date="2014-07-16T02:19:27Z"
+ content="""
+I'm afraid I've ruined the remote repo. For directory, I wrote \"mediashare\" because that's where I want copy to go.  i don't want it in default \"annex\". In git assistant, it is unclearbwhst directory means.   Mount point for cooy of remote? 
+
+Well, this is all I get now...
+
+1|u0_a127@manta:/sdcard $ cd annex
+u0_a127@manta:/sdcard/annex $ git annex status
+WARNING: linker: git-annex has text relocations. This is wasting memory and is a security risk. Please fix.
+
+
+"""]]
diff --git a/doc/forum/Where_is_the_content__63__/comment_4_a36b35d47472b5db779b0489bf3d4893._comment b/doc/forum/Where_is_the_content__63__/comment_4_a36b35d47472b5db779b0489bf3d4893._comment
new file mode 100644
index 0000000000..69b929810e
--- /dev/null
+++ b/doc/forum/Where_is_the_content__63__/comment_4_a36b35d47472b5db779b0489bf3d4893._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 4"
+ date="2014-07-16T20:41:17Z"
+ content="""
+That warning about text relocations always happens on Android and is not relevant to whatever problem you're having.
+
+If git-annex status does not print anything else, then it seems you have a git-annex repository in /sdcard/annex. If you entered \"mediashare\" in the webapp, you might have another repository in another location. When you open the webapp, it tells you the location of the repository in the upper-right corner -- \"Repository: $location\"
+"""]]
diff --git a/doc/forum/Which_branches_are___34__required__34__.mdwn b/doc/forum/Which_branches_are___34__required__34__.mdwn
new file mode 100644
index 0000000000..576d583529
--- /dev/null
+++ b/doc/forum/Which_branches_are___34__required__34__.mdwn
@@ -0,0 +1,31 @@
+Hi,
+
+I have the problem where in one repository I should not have any files anymore (according to git annex list --in .) but the annex directory still is very big (several GB). Git unused does not return any unused files so I guess they must be referenced somewhere. I do not use tags so it must be a branch. Could you tell me which of these branches are required by git annex and which are superfluous?
+
+I have two repositories (at some point I had more): origin and exp and two special remotes (hubic and acd). exp is connected to hubic and acd.
+
+on exp I have more space usage than indicated by git annex list
+ exp has the following branches:
+
+    ~/annex$ git branch -a
+      git-annex
+    * master
+      synced/git-annex
+      synced/master
+      remotes/origin/HEAD -> origin/master
+      remotes/origin/git-annex
+      remotes/origin/master
+      remotes/origin/synced/git-annex
+      remotes/origin/synced/master
+
+I have read the page on the internal workings and so far pretty much of all the wiki but if someone could point me to a description (if one exists) that explains which branch is used for what that would be great!
+
+I understand that upon "git annex sync" a repo pulls the $REMOTE/master into remotes/$REMOTE/master and $REMOTE/synced/master into remotes/$REMOTE/synced/master. 
+"git annex sync" on $REMOTE will push master to another repo into synced/master.
+
+Cheers,
+Marek
+
+
+ 
+
diff --git a/doc/forum/Which_branches_are___34__required__34__/comment_1_78d9ac05c66b7ccec031e0c57095af39._comment b/doc/forum/Which_branches_are___34__required__34__/comment_1_78d9ac05c66b7ccec031e0c57095af39._comment
new file mode 100644
index 0000000000..779f0f6571
--- /dev/null
+++ b/doc/forum/Which_branches_are___34__required__34__/comment_1_78d9ac05c66b7ccec031e0c57095af39._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-28T17:18:43Z"
+ content="""
+`git-annex unused` looks at all branches, both local branches and branches
+pulled from remotes. You could try the `--used-refspec` option to make
+that command only look at certian branches. Or delete old branches/remotes
+you're not using any longer.
+"""]]
diff --git a/doc/forum/Which_cloud_providers_are_supported__63___.mdwn b/doc/forum/Which_cloud_providers_are_supported__63___.mdwn
new file mode 100644
index 0000000000..9f8afc3fc0
--- /dev/null
+++ b/doc/forum/Which_cloud_providers_are_supported__63___.mdwn
@@ -0,0 +1,3 @@
+So Box.net and Amazon is supported, any way to get google drive in there?
+
+thanks for cool software!
diff --git a/doc/forum/Which_cloud_providers_are_supported__63___/comment_1_1f9398840144e0452a2fed9336046547._comment b/doc/forum/Which_cloud_providers_are_supported__63___/comment_1_1f9398840144e0452a2fed9336046547._comment
new file mode 100644
index 0000000000..9d8f0ecf75
--- /dev/null
+++ b/doc/forum/Which_cloud_providers_are_supported__63___/comment_1_1f9398840144e0452a2fed9336046547._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.140"
+ subject="comment 1"
+ date="2013-07-18T17:40:36Z"
+ content="""
+[[tips/googledriveannex]]
+
+See [[special_remotes]] for a full list of things people have gotten to work.
+"""]]
diff --git a/doc/forum/Why_are_ignored_files_being_deleted__63__.mdwn b/doc/forum/Why_are_ignored_files_being_deleted__63__.mdwn
new file mode 100644
index 0000000000..b7b857e941
--- /dev/null
+++ b/doc/forum/Why_are_ignored_files_being_deleted__63__.mdwn
@@ -0,0 +1,22 @@
+How do we get into the following situation?
+First we complain about an ignored file (why not just ignore it?),
+and then apparently we delete the ignored file.
+
+    [...]
+    import Pictures/2005/11/16/.IMG_0819.tmpwrite.JPG (duplicate) ok
+    (Recording state in git...)
+    The following paths are ignored by one of your .gitignore files:
+    Pictures/2008/11/27/.img_1315.tmpwrite.jpg
+    Use -f if you really want to add them.
+    fatal: no files added
+    git-annex: user error (xargs ["-0","git","--git-dir=/.../annex/.git","--work-tree=/.../annex","add","--"] exited 123)
+
+    # eek, the file that we complained about has vanished!
+    $ rm ../Pictures/2008/12/27/.img_1315.tmpwrite.jpg
+    rm: cannot remove ‘../Pictures/2008/11/27/.img_1315.tmpwrite.jpg’: No such file or directory
+
+Expected:
+- leave ignored files untouched. Maybe report "Skipped ignored files."
+
+Actual:
+- Stop import, but delete the ignored file as side effect.
diff --git a/doc/forum/Why_are_ignored_files_being_deleted__63__/comment_1_3081bda5bb600fc564185499ddfb5cf9._comment b/doc/forum/Why_are_ignored_files_being_deleted__63__/comment_1_3081bda5bb600fc564185499ddfb5cf9._comment
new file mode 100644
index 0000000000..1693b286af
--- /dev/null
+++ b/doc/forum/Why_are_ignored_files_being_deleted__63__/comment_1_3081bda5bb600fc564185499ddfb5cf9._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnVnsqEy82M-MuS2gLri-az83wSQ6lXSrc"
+ nickname="Jean"
+ subject="Ignored file imported, in spite of error message"
+ date="2015-04-08T09:08:53Z"
+ content="""
+Today I'm seeing this:
+
+    git-annex: user error (xargs [\"-0\",\"git\",\"--git-dir=/.../annex/.git\",\"--work-tree=/.../annex\",\"add\",\"--\"] exited 123)
+    failed
+    (Recording state in git...)
+    The following paths are ignored by one of your .gitignore files:
+    btsync/DCIM (1)/Camera 1/20150101090842.jpg.tmp
+    Use -f if you really want to add them.
+    fatal: no files added
+
+    git-annex: user error (xargs [\"-0\",\"git\",\"--git-dir=/.../annex/.git\",\"--work-tree=/.../annex\",\"add\",\"--\"] exited 123)
+    failed
+    (Recording state in git...)
+    ^C
+
+This repeats until I kill the import.
+
+Subsequently I see that the ignored file was in fact imported:
+
+    $ ls -lh \"btsync/DCIM (1)/Camera 1/20150101090842.jpg.tmp\"
+    lrwxrwxrwx 1 user user 203 Jan 11 14:11 btsync/DCIM (1)/Camera 1/20150101090842.jpg.tmp -> ../../../.git/annex/objects/0K/GX/SHA256E-s0--e3b0c44298ec1c149aebe4c8996eb92427ae41e4649b934ca495991b7852b855.jpg.tmp/SHA256E-s0--e3b0c44298ec1c149aebe4c8996eb92427ae41e4649b934ca495991b7852b855.jpg.tmp
+
+In this case the original file was not deleted, because I used `import --duplicate`:
+
+    $ ls -lh \"../btsync/DCIM (1)/Camera 1/20150101090842.jpg.tmp\"
+    -rw-rw-r-- 1 user user 0 Jan 11 14:11 ../btsync/DCIM (1)/Camera 1/20150101090842.jpg.tmp
+
+
+"""]]
diff --git a/doc/forum/Why_are_ignored_files_being_deleted__63__/comment_2_178aa574855a3bfffab4b21f90a84092._comment b/doc/forum/Why_are_ignored_files_being_deleted__63__/comment_2_178aa574855a3bfffab4b21f90a84092._comment
new file mode 100644
index 0000000000..d23ad6ff4d
--- /dev/null
+++ b/doc/forum/Why_are_ignored_files_being_deleted__63__/comment_2_178aa574855a3bfffab4b21f90a84092._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-04-29T17:48:12Z"
+ content="""
+It seems this was also filed as a bug report
+<http://git-annex.branchable.com/bugs/git_annex_import:_ignored_names_fatal/> so I'll deal with it there.
+"""]]
diff --git a/doc/forum/Why_are_new_repos_v5__63___Should_I_be_concerned__63__.mdwn b/doc/forum/Why_are_new_repos_v5__63___Should_I_be_concerned__63__.mdwn
new file mode 100644
index 0000000000..22edabb887
--- /dev/null
+++ b/doc/forum/Why_are_new_repos_v5__63___Should_I_be_concerned__63__.mdwn
@@ -0,0 +1,5 @@
+I'm fairly new to git-annex. Just spent the better part of an hour scratching my head about locked and unlocked files, until I realized that *my repository is v5, even though git-annex on all my machines is v6!*
+
+Is there a good reason repos created using v6 default to v5 rather than v6? I.e., not-yet-implemented features that will cause me a headache? Just want to make sure I'm not inviting more trouble if I update the repository to v6. Otherwise, I'd like to move ahead and do that, since I want to have an easier workflow for maintaining frequently edited binary files across my machines.
+
+Thanks.
diff --git a/doc/forum/Why_are_new_repos_v5__63___Should_I_be_concerned__63__/comment_1_b7fc905780f941314c99b94a87e0438a._comment b/doc/forum/Why_are_new_repos_v5__63___Should_I_be_concerned__63__/comment_1_b7fc905780f941314c99b94a87e0438a._comment
new file mode 100644
index 0000000000..4cbe446058
--- /dev/null
+++ b/doc/forum/Why_are_new_repos_v5__63___Should_I_be_concerned__63__/comment_1_b7fc905780f941314c99b94a87e0438a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="RonnyPfannschmidt"
+ avatar="http://cdn.libravatar.org/avatar/c5379a3fe2188b7571858c49f9db63c6"
+ subject="comment 1"
+ date="2018-07-30T21:09:11Z"
+ content="""
+as per [[upgrades/#index1h2]] the upgrade to v6 repos is currently manual due to the finer details of git smudge handling and direct mode vs lock/unlock
+
+since v6 repos do behave differently the updates are manual
+
+"""]]
diff --git a/doc/forum/Why_are_we_stopping_at_a_duplicate__63__.mdwn b/doc/forum/Why_are_we_stopping_at_a_duplicate__63__.mdwn
new file mode 100644
index 0000000000..2f296c2820
--- /dev/null
+++ b/doc/forum/Why_are_we_stopping_at_a_duplicate__63__.mdwn
@@ -0,0 +1,7 @@
+What does the following mean? I would expect that if we encounter a duplicate while using the `--deduplicate` option, the duplicate file would be removed from the import location and import would continue. Does that mean that the newly encountered `img_0405.jpg` is different from the one previously seen? 
+Could the error message perhaps be improved?
+
+    .../usbdisk/annex(master)$ git annex import --deduplicate ../Pictures/
+    import Pictures/2008/10/12/img_0405.jpg git-annex: not overwriting existing Pictures/2008/10/12/img_0405.jpg (use --force to override)
+
+Many other duplicates are being tidied away.
diff --git a/doc/forum/Why_are_we_stopping_at_a_duplicate__63__/comment_1_dd3b610032cd3091effdb3f0828f45a8._comment b/doc/forum/Why_are_we_stopping_at_a_duplicate__63__/comment_1_dd3b610032cd3091effdb3f0828f45a8._comment
new file mode 100644
index 0000000000..0c2a1659c8
--- /dev/null
+++ b/doc/forum/Why_are_we_stopping_at_a_duplicate__63__/comment_1_dd3b610032cd3091effdb3f0828f45a8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-29T17:47:08Z"
+ content="""
+The --deduplicate option deals with duplicated file contents. This is 
+a filename that is already in your git repo, git annex import avoids
+overwriting that with a different imported file unless you tell it --force.
+"""]]
diff --git a/doc/forum/Why_can__39__t_encryption_be_enabled_for_removable_drives__63__.mdwn b/doc/forum/Why_can__39__t_encryption_be_enabled_for_removable_drives__63__.mdwn
new file mode 100644
index 0000000000..9ff6f11fb6
--- /dev/null
+++ b/doc/forum/Why_can__39__t_encryption_be_enabled_for_removable_drives__63__.mdwn
@@ -0,0 +1,7 @@
+I currently have a pair of hard drives that I store backups etc on and that I would like to use as archive repositories for Git-Annex. I want everything on these to be encrypted, because I can't guarantee physical security of them.
+
+When I am setting up a removable drive as a repository, there is no option to encrypt to it. I understand that there is a "Directory" special remote, but it seems odd to have to use a different special remote that is not built into the webapp. Wouldn't it be good to have a checkbox for encryption when setting up a removable drive as a repository?
+
+Is there something that I'm missing here?
+
+Thanks for a great piece of software!
diff --git a/doc/forum/Why_can__39__t_encryption_be_enabled_for_removable_drives__63__/comment_1_4341898d5ae4f09a5b06d24f5fe6192d._comment b/doc/forum/Why_can__39__t_encryption_be_enabled_for_removable_drives__63__/comment_1_4341898d5ae4f09a5b06d24f5fe6192d._comment
new file mode 100644
index 0000000000..0ddf26666b
--- /dev/null
+++ b/doc/forum/Why_can__39__t_encryption_be_enabled_for_removable_drives__63__/comment_1_4341898d5ae4f09a5b06d24f5fe6192d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 1"
+ date="2013-07-16T19:45:42Z"
+ content="""
+git-annex stores a clone of the git repository on the removable drive. To encrypt a git remote, you can use the [git-remote-gcrypt](https://github.com/blake2-ppc/git-remote-gcrypt) tool. This will work with git-annex, but it needs integration into the webapp to support setting it up, and further integration so git-annex can detect when a git remote is encrypted and also encrypt the contents of file is stores there.
+"""]]
diff --git a/doc/forum/Why_does_git_annex_does_not_want_that_file__63__.mdwn b/doc/forum/Why_does_git_annex_does_not_want_that_file__63__.mdwn
new file mode 100644
index 0000000000..3dac8e4ae5
--- /dev/null
+++ b/doc/forum/Why_does_git_annex_does_not_want_that_file__63__.mdwn
@@ -0,0 +1,33 @@
+Hello,
+
+I have an repo that uses standard groups / wanted expressions:
+
+    % git annex wanted . && git annex group .               
+    standard
+    archive backup
+
+I use the two groups so that the repo wants anything (backup) and is recognized as an archive repo, so other repos drop files in archive/.
+
+    % git annex drop fortune
+    drop fortune (checking S3...) ok
+    (recording state in git...)
+
+fine. But:
+
+    % git annex get --auto
+
+does nothing. I do not understand, why the repo does not want the file. Same for git annex sync --content.
+
+    % git annex whereis fortune
+    whereis fortune (3 copies) 
+            19317658-7d40-4412-94ba-a2525e625283 -- Asaru
+            2f41eb74-5f33-4737-bb6b-1cd31dd67ee5 -- External
+            728648bf-5276-4a86-9df9-9a30f4783027 -- [S3]
+    ok
+
+Asaru is standard/client, S3 is standard/backup and External has no group / wanted set.
+
+
+
+Thanks,
+Florian
diff --git a/doc/forum/Why_does_git_annex_does_not_want_that_file__63__/comment_1_44cd6ca1f7215395e19ce654513197a9._comment b/doc/forum/Why_does_git_annex_does_not_want_that_file__63__/comment_1_44cd6ca1f7215395e19ce654513197a9._comment
new file mode 100644
index 0000000000..709bc80fdf
--- /dev/null
+++ b/doc/forum/Why_does_git_annex_does_not_want_that_file__63__/comment_1_44cd6ca1f7215395e19ce654513197a9._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-01-15T18:20:20Z"
+ content="""
+The problem is that you have the repository in two groups.
+
+The way that `standard` works is that the repository has to be in
+exactly one group and then it will use the preferred content for that
+group. It does not know what to do when there are two groups being
+combined.
+
+Solution for you is to run: 
+
+	git annex wanted . anything
+
+Since backup repositories have a copy of every file, matching anything is
+what you want it to do. Since it's also in the archive group, other archive
+repositories will treat it as an archive too, so once a file reaches your
+combo backup and archive repository, it will be removed from other
+archives.
+
+Of course, you could also OR the preferred content expression for backup
+with the preferred content expression for archive, but that would have the
+same result since "anything OR archive" matches anything.
+
+But we can't just OR the two preferred content expressions for two groups
+in general. Consider the client and archive preferred content expressions:
+
+	(include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1
+
+	(not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1
+
+These are contradictory when a repository is in both the client and archive
+groups; the client doesn't want anything that's in an archive, but if the
+repository is both a client and an archive, it doesn't want any content
+that it has!
+"""]]
diff --git a/doc/forum/Why_does_the_bup_remote_use___126____47__.bup__63__.mdwn b/doc/forum/Why_does_the_bup_remote_use___126____47__.bup__63__.mdwn
new file mode 100644
index 0000000000..c250ef7c1e
--- /dev/null
+++ b/doc/forum/Why_does_the_bup_remote_use___126____47__.bup__63__.mdwn
@@ -0,0 +1,5 @@
+I created a test remote using the command:
+
+    git annex initremote mybup type=bup encryption=none buprepo=/tmp/mybup
+
+I can copy files to and from the remote just fine.  However, every time I do so it makes changes inside `~/.bup`.  If I delete `~/.bup` it will recreate it.  Is this expected?  Are the files in `~/.bup` of any consequence?
diff --git a/doc/forum/Why_does_the_bup_remote_use___126____47__.bup__63__/comment_1_da9c7c0e93aefc2da7409de5b138d86f._comment b/doc/forum/Why_does_the_bup_remote_use___126____47__.bup__63__/comment_1_da9c7c0e93aefc2da7409de5b138d86f._comment
new file mode 100644
index 0000000000..cbb3c8d6d9
--- /dev/null
+++ b/doc/forum/Why_does_the_bup_remote_use___126____47__.bup__63__/comment_1_da9c7c0e93aefc2da7409de5b138d86f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="Ah"
+ date="2012-10-18T23:52:03Z"
+ content="""
+I get now why ~/.bup is being used: -r DIR specifies a local DIR as the bup directory, but ~/.bup is still used for the local temp files.  It would be nice, therefore, if BUP_DIR were set in the case that -r specifies a local directory, so that only that directory is used.  Unless, of course, that leads to space limitations in the bup directory.  Hmm... maybe this should just be left as is in that case.
+"""]]
diff --git a/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__.mdwn b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__.mdwn
new file mode 100644
index 0000000000..ccf059f0c1
--- /dev/null
+++ b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__.mdwn
@@ -0,0 +1,42 @@
+If I `git-annex add` a directory, with some files inside, and then move into the directory to execute `git commit -m message`, then `git commit` fails with: `git-annex: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)`. Why?
+
+Notice that if I do the same operations within a standard git repository (not annex), then `git commit` works with no problems, as expected.
+
+As it is described above, this difference between git-annex and git seems a minor issue, but I got stuck into that for a while when I stumbled into it in a more complex scenario. 
+
+Steps to reproduce the issue:
+
+    > mkdir annex
+    > cd annex
+    /annex> git init
+    Initialized empty Git repository in /tmp/zzz/annex/.git/
+    /annex (master)> git-annex init
+    init  ok
+    (recording state in git...)
+    /annex (master)> mkdir a
+    /annex (master)> cd a
+    /annex/a (master)> echo foo > bar
+    /annex/a (master)> git annex add bar
+    add bar ok
+    (recording state in git...)
+    /annex/a (master)> git commit -m "bar added"
+    git-annex: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
+
+
+Differently, within a standard git repository, the equivalent `git commit` does not fail:
+
+    > mkdir repo
+    > cd repo
+    /repo> git init
+    Initialized empty Git repository in /tmp/zzz/repo/.git/
+    /repo (master)> mkdir a
+    /repo (master)> cd a
+    /repo/a (master)> echo foo > bar
+    /repo/a (master)> git add bar
+    /repo/a (master)> git commit -m "bar added"
+    [master (root-commit) 203c996] bar added
+     1 file changed, 1 insertion(+)
+     create mode 100644 a/bar
+
+
+In any case, a big thank for making `git-annex`, it is a really great piece of software!
diff --git a/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_10_abae8a95b60f17052a5e2ac30a7ece32._comment b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_10_abae8a95b60f17052a5e2ac30a7ece32._comment
new file mode 100644
index 0000000000..a0e6e86e65
--- /dev/null
+++ b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_10_abae8a95b60f17052a5e2ac30a7ece32._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="AndyPerry"
+ avatar="http://cdn.libravatar.org/avatar/42114bc1ad6d16de30842b297a91ec45"
+ subject="comment 10"
+ date="2018-09-14T13:20:42Z"
+ content="""
+I have built from source and it works. Can the MacOS repository be updated soon to have a version with the fix?
+"""]]
diff --git a/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_1_dfd69ac96065f8146f5ea87b957cca6e._comment b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_1_dfd69ac96065f8146f5ea87b957cca6e._comment
new file mode 100644
index 0000000000..5e0c73ba53
--- /dev/null
+++ b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_1_dfd69ac96065f8146f5ea87b957cca6e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="inecas@fe552cc962c331a5cb1499e80bd5b2aa0808d987"
+ nickname="inecas"
+ avatar="http://cdn.libravatar.org/avatar/08cb45efffe7995a6bcbb904e9066f79"
+ subject="comment 1"
+ date="2018-09-07T07:25:53Z"
+ content="""
+I see this issue as well, it started appearing after updating git-annex-6.20180626-1 to git-annex-6.20180807-1 (Fedora distribution).
+Downgrading helped resolving this issue for me for now.
+"""]]
diff --git a/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_2_8d36f559d7f8b61f5633f0d24b424cec._comment b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_2_8d36f559d7f8b61f5633f0d24b424cec._comment
new file mode 100644
index 0000000000..29f643f8c1
--- /dev/null
+++ b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_2_8d36f559d7f8b61f5633f0d24b424cec._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2"
+ nickname="emanuele.olivetti"
+ avatar="http://cdn.libravatar.org/avatar/f51cc5c6c3a0eb28faa6491c3cbcfcce"
+ subject="comment 2"
+ date="2018-09-07T12:27:28Z"
+ content="""
+Shall I file it as a bug/regression then?
+"""]]
diff --git a/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_3_a318582d30f5483f3738e8f0f1a2e1df._comment b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_3_a318582d30f5483f3738e8f0f1a2e1df._comment
new file mode 100644
index 0000000000..2cf8809c13
--- /dev/null
+++ b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_3_a318582d30f5483f3738e8f0f1a2e1df._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-09-11T17:45:41Z"
+ content="""
+This seems like the same or related to the problem discussed here:
+<http://git-annex.branchable.com/bugs/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/>
+
+It seems you are not using v6 mode, but perhaps you also have a broken old
+version of git?
+"""]]
diff --git a/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_4_bc2e255f8732f6ec02e90a6623ffc8af._comment b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_4_bc2e255f8732f6ec02e90a6623ffc8af._comment
new file mode 100644
index 0000000000..1326e58709
--- /dev/null
+++ b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_4_bc2e255f8732f6ec02e90a6623ffc8af._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-09-11T19:54:45Z"
+ content="""
+It seems likely I've just fixed this in git-annex [[!commit fdbdf64d87e2980e8399d1182ccb43bd0f013b16]]
+but since I can't reproduce the problem from your transcript I can't say
+for sure.
+"""]]
diff --git a/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_5_691dc07b192f077f50611544d488b394._comment b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_5_691dc07b192f077f50611544d488b394._comment
new file mode 100644
index 0000000000..df0ba9d451
--- /dev/null
+++ b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_5_691dc07b192f077f50611544d488b394._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2"
+ nickname="emanuele.olivetti"
+ avatar="http://cdn.libravatar.org/avatar/f51cc5c6c3a0eb28faa6491c3cbcfcce"
+ subject="comment 5"
+ date="2018-09-12T10:45:03Z"
+ content="""
+Thanks Joey for looking into this one. I use git v2.7.4, currently shipped with Ubuntu 16.04, which may not be very recent. I don't use v6 because it is not the default in git-annex, at least till now. Should I?
+I'll try the recent commit you mention, as soon as it will be available in the Linux standalone version or in Neurodebian (currently 6.20180807-g48d11a5df and 6.20180807+git230-gaa291acfe-1~ndall+1) and I will report here shortly after.
+"""]]
diff --git a/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_6_71d7a08600dcba07dd895ddf6ad1331a._comment b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_6_71d7a08600dcba07dd895ddf6ad1331a._comment
new file mode 100644
index 0000000000..83a38e2227
--- /dev/null
+++ b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_6_71d7a08600dcba07dd895ddf6ad1331a._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2"
+ nickname="emanuele.olivetti"
+ avatar="http://cdn.libravatar.org/avatar/f51cc5c6c3a0eb28faa6491c3cbcfcce"
+ subject="comment 6"
+ date="2018-09-13T14:56:51Z"
+ content="""
+My mistake. The last Linux standalone version, 6.20180807-g48d11a5df, works correctly and does not show the issue anymore:
+
+    $ mkdir annex
+    $ cd annex
+    $ git init
+    Initialized empty Git repository in /tmp/annex/.git/
+    $ git annex init
+    init  ok
+    (recording state in git...)
+    $ mkdir a
+    $ cd a
+    $ echo foo > bar
+    $ git annex add bar
+    add bar ok
+    (recording state in git...)
+    $ git commit -m \"bar added\"
+    [master (root-commit) 4cf38d9] bar added
+     1 file changed, 1 insertion(+)
+     create mode 120000 a/bar
+
+Thank you for fixing the issue and thanks again for git-annex!
+"""]]
diff --git a/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_7_a5d60323c2c6b2d263514b33ad774aa9._comment b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_7_a5d60323c2c6b2d263514b33ad774aa9._comment
new file mode 100644
index 0000000000..a6fcb4a2f0
--- /dev/null
+++ b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_7_a5d60323c2c6b2d263514b33ad774aa9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="AndyPerry"
+ avatar="http://cdn.libravatar.org/avatar/42114bc1ad6d16de30842b297a91ec45"
+ subject="comment 7"
+ date="2018-09-14T09:49:57Z"
+ content="""
+I get the same error/failure on MacOS. I have git-annex 6.20180807
+I made a very simple change, deleting an old symlink, but the commit fails as mentioned in this thread.
+"""]]
diff --git a/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_8_83e52bd3d66ce87ba7d2913d21c76b08._comment b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_8_83e52bd3d66ce87ba7d2913d21c76b08._comment
new file mode 100644
index 0000000000..d7d319a1d7
--- /dev/null
+++ b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_8_83e52bd3d66ce87ba7d2913d21c76b08._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="AndyPerry"
+ avatar="http://cdn.libravatar.org/avatar/42114bc1ad6d16de30842b297a91ec45"
+ subject="comment 8"
+ date="2018-09-14T11:39:41Z"
+ content="""
+I installed the *latest* via `brew install git-annex`. Is there another repository I can use to get a newer version? 
+I'd rather not have top build from source as the pre-reqs are not tools I'd use for anything else.
+"""]]
diff --git a/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_9_0bd122e2e664d29dca027719721b1523._comment b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_9_0bd122e2e664d29dca027719721b1523._comment
new file mode 100644
index 0000000000..8be5f1fa7c
--- /dev/null
+++ b/doc/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/comment_9_0bd122e2e664d29dca027719721b1523._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2"
+ nickname="emanuele.olivetti"
+ avatar="http://cdn.libravatar.org/avatar/f51cc5c6c3a0eb28faa6491c3cbcfcce"
+ subject="comment 9"
+ date="2018-09-14T12:24:14Z"
+ content="""
+Check the app bundle (pre-built) that you can download from <http://git-annex.branchable.com/install/OSX/>. If it is the analogous of the Linux standalone file, then it should be version 6.20180807-g48d11a5df, which solves the bug discussed in this page. It would be nice if you send feedback here after trying.
+"""]]
diff --git a/doc/forum/Why_is_git_annex_status_slow__63__.mdwn b/doc/forum/Why_is_git_annex_status_slow__63__.mdwn
new file mode 100644
index 0000000000..5c659b61d4
--- /dev/null
+++ b/doc/forum/Why_is_git_annex_status_slow__63__.mdwn
@@ -0,0 +1,20 @@
+It seems that `git annex status` is much slower than `git status`, at least in direct mode. The man page does not give any hint about why it should be slower.
+
+Does `git annex status` do something that `git status` does not?
+
+Here is an example in a repo with 8000+ files in direct mode and with no modified files:
+
+
+    $ time git -c core.bare=false status --porcelain > /dev/null
+
+    real   0m0.096s
+    user   0m0.042s
+    sys    0m0.071s
+
+    $ time git annex status
+
+    real   0m17.144s
+    user   0m10.555s
+    sys    0m1.934s
+
+It is strange to see that `git annex status` is ~200 times slower than the bare `git status`.
diff --git a/doc/forum/Why_is_git_annex_status_slow__63__/comment_1_a5139c5a9fc94486cf62fc9a9fa9f8d9._comment b/doc/forum/Why_is_git_annex_status_slow__63__/comment_1_a5139c5a9fc94486cf62fc9a9fa9f8d9._comment
new file mode 100644
index 0000000000..f21fcac488
--- /dev/null
+++ b/doc/forum/Why_is_git_annex_status_slow__63__/comment_1_a5139c5a9fc94486cf62fc9a9fa9f8d9._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-11-03T17:08:50Z"
+ content="""
+`git status` looks at the index and work tree. In an indirect mode
+repository, `git annex status` does too, and is not significantly slower.
+
+In direct mode, `git annex status` has to look up from git the key
+that corresponds to each file in the work tree. This is the main
+thing that slows it down.
+
+(See the code for details, it's quite clear.)
+
+The best workaround is proably to pass git-annex status a subdirectory
+that you're interested in, so it can only look at the contents of that one
+directory.
+"""]]
diff --git a/doc/forum/Why_is_git_annex_status_slow__63__/comment_2_2f61c2cdf9d1ffd298fd906207012818._comment b/doc/forum/Why_is_git_annex_status_slow__63__/comment_2_2f61c2cdf9d1ffd298fd906207012818._comment
new file mode 100644
index 0000000000..02b158b703
--- /dev/null
+++ b/doc/forum/Why_is_git_annex_status_slow__63__/comment_2_2f61c2cdf9d1ffd298fd906207012818._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkutSE8_3fFAETmO_E598zja4gKwYXbb8E"
+ nickname="Сергей"
+ subject="Slow on windows but not on linux"
+ date="2015-04-07T18:20:23Z"
+ content="""
+If this is by design and `git annex status` should take more time in direct mode then what I'm experiencing is strange. On windows every 100M file adds approximately 1 second to `status` duration (on my laptop), but on linux it does not. On linux `git annex status` even in direct mode takes milliseconds. What is wrong with my setup?
+"""]]
diff --git a/doc/forum/Why_is_git_annex_status_slow__63__/comment_3_8d9e5a1aef2648d7a844623e6237d551._comment b/doc/forum/Why_is_git_annex_status_slow__63__/comment_3_8d9e5a1aef2648d7a844623e6237d551._comment
new file mode 100644
index 0000000000..54d2b24c49
--- /dev/null
+++ b/doc/forum/Why_is_git_annex_status_slow__63__/comment_3_8d9e5a1aef2648d7a844623e6237d551._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-09T17:44:01Z"
+ content="""
+The sizes of the files should not affect how fast git-annex status runs. 
+
+But, direct mode certianly does. git-annex has to do significantly more
+work in direct mode to figure out the status of a file. Including querying
+git. In indirect mode, it can just stat the symlink and see if its content
+is present, which is much faster.
+
+(There's probably also some other inneficiencies in Windows.)
+"""]]
diff --git a/doc/forum/Will_git-annex_solve_my_problem__63__.mdwn b/doc/forum/Will_git-annex_solve_my_problem__63__.mdwn
new file mode 100644
index 0000000000..0aa2ded520
--- /dev/null
+++ b/doc/forum/Will_git-annex_solve_my_problem__63__.mdwn
@@ -0,0 +1,7 @@
+Here's my current situation:
+
+I have a box which creates about a dozen files periodically. All files add up to about 1GB in size. The files are text and sorted. I then rsync the files to n servers. The rsync diff algorithm transfers way less than n * 1GB because the files are largely the same. However, this distribution technique is inefficient because I must run n rsync processes in parallel and the rsync diff algorithm takes a lot of CPU.
+
+How could I use git-annex instead of rsync?
+
+Because the box producing the new files also has the old files, then presumably git could calculate the diffs for each file once instead of n times as with the rsync solution? Then only the diffs need be distributed to the n servers... using git-annex? And finally the newly updated version of the dozen files needs to be available on each of the n servers. Ideally, the diffs would not mount up over time on either the publishing server or the n servers, thus causing out of disk problems etc. How to deploy git-annex to solve my problem?
diff --git a/doc/forum/Will_git-annex_solve_my_problem__63__/comment_1_35acbdd1a7727df204d776c2e8f02b53._comment b/doc/forum/Will_git-annex_solve_my_problem__63__/comment_1_35acbdd1a7727df204d776c2e8f02b53._comment
new file mode 100644
index 0000000000..a4f27f46ed
--- /dev/null
+++ b/doc/forum/Will_git-annex_solve_my_problem__63__/comment_1_35acbdd1a7727df204d776c2e8f02b53._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-27T22:48:16Z"
+ content="""
+git-annex will not perform better than rsync. It uses rsync. It also does not yet use old versions of files as a rsync basis when transferring a new version of a file, so is not as efficient in this scenario.
+"""]]
diff --git a/doc/forum/Will_git-annex_solve_my_problem__63__/comment_2_230256c19ac139dea207d89c06f70782._comment b/doc/forum/Will_git-annex_solve_my_problem__63__/comment_2_230256c19ac139dea207d89c06f70782._comment
new file mode 100644
index 0000000000..2b7b7e5f7b
--- /dev/null
+++ b/doc/forum/Will_git-annex_solve_my_problem__63__/comment_2_230256c19ac139dea207d89c06f70782._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkaBh9VNJ-RZ26wJZ4BEhMN1IlPT-DK6JA"
+ nickname="Alex"
+ subject="Bup"
+ date="2013-04-03T05:47:41Z"
+ content="""
+I think bup will solve your use case. Make a local bup repo and backup there then clone that repo n times. If you run git annex on top of bup you can then retrieve the subset of files you need at each destination. This will work best if you don't need every file on every remote or if your network is much slower than local disk access. 
+"""]]
diff --git a/doc/forum/Will_git_annex_work_on_a_FAT32_formatted_key__63__.mdwn b/doc/forum/Will_git_annex_work_on_a_FAT32_formatted_key__63__.mdwn
new file mode 100644
index 0000000000..f458ba72e0
--- /dev/null
+++ b/doc/forum/Will_git_annex_work_on_a_FAT32_formatted_key__63__.mdwn
@@ -0,0 +1,3 @@
+FAT32 does not support symlinks, so I wonder if there's going to be a problem with that.
+
+Generally speaking, I am wondering about portability of git annex on windows and on android...
diff --git a/doc/forum/Will_git_annex_work_on_a_FAT32_formatted_key__63__/comment_1_426482e6eb3a27687a48f24f6ef2332f._comment b/doc/forum/Will_git_annex_work_on_a_FAT32_formatted_key__63__/comment_1_426482e6eb3a27687a48f24f6ef2332f._comment
new file mode 100644
index 0000000000..119c9e535a
--- /dev/null
+++ b/doc/forum/Will_git_annex_work_on_a_FAT32_formatted_key__63__/comment_1_426482e6eb3a27687a48f24f6ef2332f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-03-07T19:13:14Z"
+ content="""
+See [[bugs/fat_support]]. A bare git repo will have to be used to avoid symlink problems, at least for now. The other problem is that git-annex key files have colons in their filenames.
+"""]]
diff --git a/doc/forum/Will_git_annex_work_on_a_FAT32_formatted_key__63__/comment_2_af4f8b52526d8bea2904c95406fd2796._comment b/doc/forum/Will_git_annex_work_on_a_FAT32_formatted_key__63__/comment_2_af4f8b52526d8bea2904c95406fd2796._comment
new file mode 100644
index 0000000000..ca599b2857
--- /dev/null
+++ b/doc/forum/Will_git_annex_work_on_a_FAT32_formatted_key__63__/comment_2_af4f8b52526d8bea2904c95406fd2796._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-03-19T15:37:22Z"
+ content="""
+Now it's fully supported, so long as you put a bare git repo on your key.
+"""]]
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access.mdwn b/doc/forum/Windows_-_You_don__39__t_have_access.mdwn
new file mode 100644
index 0000000000..a12d46ad9f
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access.mdwn
@@ -0,0 +1,42 @@
+git version: 1.9.5.msysgit.1
+git-annex version: 5.20150710-g8fd7052
+
+I have a repo up on GitLab. I have annex’d files in that repo. On a Linux server I can “git annex sync” and then “git annex get” just fine. On Windows when I try to run “git annex sync” I get:
+
+GitLab: You don't have access
+
+  Remote origin does not have git-annex installed; setting annex-ignore
+
+  This could be a problem with the git-annex installation on the remote. Please make sure that git-a
+nnex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex inst
+allation, run: git config remote.origin.annex-ignore false
+commit  ok
+pull origin
+git-annex.exe: unknown command git@gitlab.server.com
+…
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+failed
+git-annex: sync: 1 failed
+
+I have access to the repo however. I can git pull/push…whatever. It’s just annex that is having problems with access and I’m not sure why. Here is my git config:
+
+[core]
+        repositoryformatversion = 0
+        filemode = false
+        bare = false
+        logallrefupdates = true
+        symlinks = false
+        ignorecase = true
+        hideDotFiles = dotGitOnly
+[remote "origin"]
+        url = git@gitlab.company.com:repo.git
+        fetch = +refs/heads/*:refs/remotes/origin/*
+        annex-ignore = false
+[annex]
+        uuid = 2noa1e70-9f88-4did-843c-3f8sdf3495990
+        sshcaching = false
+        crippledfilesystem = true
+        version = 5
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access/comment_1_5c1da63922cc71483c9519e8670d532b._comment b/doc/forum/Windows_-_You_don__39__t_have_access/comment_1_5c1da63922cc71483c9519e8670d532b._comment
new file mode 100644
index 0000000000..ad11ef8dfc
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access/comment_1_5c1da63922cc71483c9519e8670d532b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-20T17:51:33Z"
+ content="""
+The "GitLab: You don't have access" seems to be gitlab refusing to run
+git-annex-shell when asked to. Only the gitlab people could help you with
+that. (Gitlab does seem to work with git-annex today when I try it,
+I had some similar problems with their implementation refusing to
+start git-annex-shell earlier.)
+
+OTOH, the "git-annex.exe: unknown command git@gitlab.server.com"
+looks like you ran into this bug:
+<http://git-annex.branchable.com/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/>
+Since I have still not managed to reproduce or get to the bottom of that
+bug report, any information about it would be useful.
+"""]]
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access/comment_2_aa6ea60465df9fab7990bd6f510b74c5._comment b/doc/forum/Windows_-_You_don__39__t_have_access/comment_2_aa6ea60465df9fab7990bd6f510b74c5._comment
new file mode 100644
index 0000000000..dd64dd7f00
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access/comment_2_aa6ea60465df9fab7990bd6f510b74c5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="fusionx86@2cab672ef75a8502e153ceb90177dde38985dba9"
+ nickname="fusionx86"
+ subject="comment 2"
+ date="2015-07-20T18:59:29Z"
+ content="""
+GitLab is working fine with annex. I'm able to annex sync and sync --content on Linux and OSX without any problems. It's just Windows client I'm struggling with. I'll look at the bug you linked and post back with anything interesting.
+"""]]
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access/comment_3_593a8a54fa80258d5048f5c061992664._comment b/doc/forum/Windows_-_You_don__39__t_have_access/comment_3_593a8a54fa80258d5048f5c061992664._comment
new file mode 100644
index 0000000000..798aa125a7
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access/comment_3_593a8a54fa80258d5048f5c061992664._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-20T19:03:58Z"
+ content="""
+Pretty sure that the only difference gitlab can see between your Windows
+and Linux boxes there is the ssh key that they're using. So, maybe you need
+to add the Windows box's ssh key to the gitlab repo, or there's a problem
+in that area.
+"""]]
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access/comment_4_aa28602eb0b7fa7103eaf90dc1d5cf8f._comment b/doc/forum/Windows_-_You_don__39__t_have_access/comment_4_aa28602eb0b7fa7103eaf90dc1d5cf8f._comment
new file mode 100644
index 0000000000..89778431ca
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access/comment_4_aa28602eb0b7fa7103eaf90dc1d5cf8f._comment
@@ -0,0 +1,54 @@
+[[!comment format=mdwn
+ username="fusionx86@2cab672ef75a8502e153ceb90177dde38985dba9"
+ nickname="fusionx86"
+ subject="comment 4"
+ date="2015-07-20T20:14:07Z"
+ content="""
+The bug you linked does look like the same thing I'm seeing. I decided to install cygwin on the same server to see if it made a difference. It started adding files this time and I thought I had a solution, but then it threw the same error about access.
+----
+$ git annex sync --verbose
+
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+
+  Enabling direct mode.
+commit  (recording state in git...)
+add Bin/FastMM_FullDebugMode.dll ok
+add Bin/Res/bar_blank.gif ok
+add Bin/Res/bar_blank_gray.gif ok
+add Bin/Res/bar_gray.gif ok
+add Bin/Res/bar_left.gif ok
+add Bin/Res/bar_middle.gif ok
+add Bin/Res/bar_right.gif ok
+add Bin/Res/btn_back_0.gif ok
+add Bin/Res/btn_back_1.gif ok
+add Bin/Res/btn_back_2.gif ok
+add Bin/Res/btn_back_3.gif ok
+...
+(recording state in git...)
+ok
+pull origin git-annex.exe: unknown command git@gitlab.company.com
+
+Usage: git-annex command [option ...]
+...
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+
+  Pushing to origin failed.
+
+  (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
+failed
+(recording state in git...)
+git-annex.exe: sync: 2 failed
+----
+
+So it seemed to get a little further, but still fails. The key $HOME/.ssh/id_rsa has full access to the repo and I'm able to push/pull with git just fine. Not sure what else to try for annex sync.
+
+"""]]
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access/comment_5_f9041e48b911dbdd37ad3c1bbc801709._comment b/doc/forum/Windows_-_You_don__39__t_have_access/comment_5_f9041e48b911dbdd37ad3c1bbc801709._comment
new file mode 100644
index 0000000000..b77d09c122
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access/comment_5_f9041e48b911dbdd37ad3c1bbc801709._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="fusionx86@2cab672ef75a8502e153ceb90177dde38985dba9"
+ nickname="fusionx86"
+ subject="comment 5"
+ date="2015-07-20T20:41:00Z"
+ content="""
+Also, I created git-annex-shell.exe as a copy of git-annex.exe which you recommended here: https://git-annex.branchable.com/bugs/no_git-annex_shell_on_Windows/.
+
+I also made sure UAC and Windows Firewall were disabled and they already were.
+
+What environment variables should exist to support annex? I see references to GIT_ANNEX_SSHOPTION and GIT_SSH, but those aren't currently configured on my Windows server. The git, git-annex and git-annex-shell files are in the global path and accessible from anywhere.
+"""]]
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access/comment_6_7656eb72bb9e39db59092557c57a2489._comment b/doc/forum/Windows_-_You_don__39__t_have_access/comment_6_7656eb72bb9e39db59092557c57a2489._comment
new file mode 100644
index 0000000000..c78501a873
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access/comment_6_7656eb72bb9e39db59092557c57a2489._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="fusionx86@2cab672ef75a8502e153ceb90177dde38985dba9"
+ nickname="fusionx86"
+ subject="comment 6"
+ date="2015-07-24T18:10:20Z"
+ content="""
+Any other ideas on this problem? I was planning to use annex for large/binary files, but we have a lot of developers that would need to run it on Windows as well and I'm not sure how to roll it out when I can't get it working myself on a Windows build server. I think I saw somewhere that you have tested it on WinXP. Any chance you could download an evaluation copy of a later version (Win7/8.1/2008R2/2012R2) and try again? Annex is a great tool and would like to incorporate it into our SCM and deployment workflow if possible. Thanks.
+"""]]
diff --git a/doc/forum/Windows_-_gpg_fails_with_shared_encryption.mdwn b/doc/forum/Windows_-_gpg_fails_with_shared_encryption.mdwn
new file mode 100644
index 0000000000..fea1ffe9d6
--- /dev/null
+++ b/doc/forum/Windows_-_gpg_fails_with_shared_encryption.mdwn
@@ -0,0 +1,82 @@
+I have an rclone special remote that I can get my Windows computer to see, but it seems to be messing up actually getting the file:
+
+By the looks of it, either the temp file that GPG uses doesn't get made, or it gets made but with incorrect contents:
+
+```
+$ git annex get --debug 'Samples/Recorded/1-Audio 0001 [2021-12-08 093649].aif'
+[2022-01-05 14:22:52.4414076] (Utility.Process) process [8196] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2022-01-05 14:22:52.4594467] (Utility.Process) process [8196] done ExitSuccess
+[2022-01-05 14:22:52.4615933] (Utility.Process) process [16468] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","refs/heads/main"]
+[2022-01-05 14:22:52.4934873] (Utility.Process) process [16468] done ExitSuccess
+[2022-01-05 14:22:52.4974156] (Utility.Process) process [16656] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-files","--stage","-z","--","Samples/Recorded/1-Audio 0001 [2021-12-08 093649].aif"]
+[2022-01-05 14:22:52.5004149] (Utility.Process) process [3996] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2022-01-05 14:22:52.5035735] (Utility.Process) process [17168] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2022-01-05 14:22:52.5243346] (Utility.Process) process [17136] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+get Samples/Recorded/1-Audio 0001 [2021-12-08 093649].aif [2022-01-05 14:22:52.5593587] (Utility.Process) process [22208] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2022-01-05 14:22:52.5862972] (Utility.Process) process [22208] done ExitSuccess
+[2022-01-05 14:22:52.5902901] (Utility.Process) process [18248] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2022-01-05 14:22:52.610443] (Utility.Process) process [18248] done ExitSuccess
+[2022-01-05 14:22:52.6143883] (Utility.Process) process [19620] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..3671f1ffc7c0744725c504a01fc8a67fa4539a4a","--pretty=%H","-n1"]
+[2022-01-05 14:22:52.6462441] (Utility.Process) process [19620] done ExitSuccess
+[2022-01-05 14:22:52.6482446] (Utility.Process) process [20716] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..3cf61e8a81a8ee97dbfbdf0a86323380e0bc942a","--pretty=%H","-n1"]
+[2022-01-05 14:22:52.6822859] (Utility.Process) process [20716] done ExitSuccess
+[2022-01-05 14:22:52.6910388] (Utility.Process) process [16484] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","hash-object","-w","--stdin-paths","--no-filters"]
+[2022-01-05 14:22:52.7008252] (Utility.Process) process [6724] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2022-01-05 14:22:52.7066723] (Utility.Process) process [12884] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index-info"]
+[2022-01-05 14:22:52.7106744] (Utility.Process) process [17688] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","diff-index","--raw","-z","-r","--no-renames","-l0","--cached","refs/heads/git-annex","--"]
+[2022-01-05 14:22:52.7624402] (Utility.Process) process [17688] done ExitSuccess
+[2022-01-05 14:22:52.7678167] (Utility.Process) process [12884] done ExitSuccess
+(from pcloud_annex...)
+[2022-01-05 14:22:52.8412254] (Utility.Process) process [18812] chat: bash ["C:\\Users\\REDACTED\\Documents\\Mine\\programs\\bin\\git-annex-remote-rclone"]
+[2022-01-05 14:22:52.9153659] (Annex.ExternalAddonProcess) bash[1] --> VERSION 1
+[2022-01-05 14:22:52.9155845] (Annex.ExternalAddonProcess) bash[1] <-- EXTENSIONS INFO GETGITREMOTENAME ASYNC
+[2022-01-05 14:22:52.9155845] (Annex.ExternalAddonProcess) bash[1] --> UNSUPPORTED-REQUEST
+[2022-01-05 14:22:52.9155845] (Annex.ExternalAddonProcess) bash[1] <-- PREPARE
+[2022-01-05 14:22:52.9155845] (Annex.ExternalAddonProcess) bash[1] --> GETCONFIG prefix
+[2022-01-05 14:22:52.9155845] (Annex.ExternalAddonProcess) bash[1] <-- VALUE test_annex
+[2022-01-05 14:22:53.0371658] (Annex.ExternalAddonProcess) bash[1] --> GETCONFIG target
+[2022-01-05 14:22:53.0371658] (Annex.ExternalAddonProcess) bash[1] <-- VALUE pcloud_test_annex
+[2022-01-05 14:22:53.1413009] (Annex.ExternalAddonProcess) bash[1] --> GETCONFIG rclone_layout
+[2022-01-05 14:22:53.1413009] (Annex.ExternalAddonProcess) bash[1] <-- VALUE lower
+[2022-01-05 14:22:53.2805175] (Annex.ExternalAddonProcess) bash[1] --> PREPARE-SUCCESS
+[2022-01-05 14:22:53.2805175] (Annex.ExternalAddonProcess) bash[1] <-- TRANSFER RETRIEVE GPGHMACSHA512--ceb25ebd86f4098b366419fbed8fc388e421cc38429ce2da09688b1ba4575333cea33b1920455c2d4b4dfc28a1d7027d91be028f059322b10d1d9a0731adbedb .git\annex\tmp\GPGHMACSHA512--ceb25ebd86f4098b366419fbed8fc388e421cc38429ce2da09688b1ba4575333cea33b1920455c2d4b4dfc28a1d7027d91be028f059322b10d1d9a0731adbedb
+[2022-01-05 14:22:53.2805175] (Annex.ExternalAddonProcess) bash[1] --> DIRHASH-LOWER GPGHMACSHA512--ceb25ebd86f4098b366419fbed8fc388e421cc38429ce2da09688b1ba4575333cea33b1920455c2d4b4dfc28a1d7027d91be028f059322b10d1d9a0731adbedb
+[2022-01-05 14:22:53.2805175] (Annex.ExternalAddonProcess) bash[1] <-- VALUE 34d\c20\
+[2022-01-05 14:23:01.8937568] (Annex.ExternalAddonProcess) bash[1] --> TRANSFER-SUCCESS RETRIEVE GPGHMACSHA512--ceb25ebd86f4098b366419fbed8fc388e421cc38429ce2da09688b1ba4575333cea33b1920455c2d4b4dfc28a1d7027d91be028f059322b10d1d9a0731adbedb
+[2022-01-05 14:23:01.9017536] (Utility.Process) process [5260] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-file","C:\\Users\\REDACTED\\AppData\\Local\\Temp\\gpg8159","--decrypt"]
+gpg: decryption failed: Bad session key
+[2022-01-05 14:23:02.2915591] (Utility.Process) process [5260] done ExitFailure 2
+[2022-01-05 14:23:02.2915591] (Annex.ExternalAddonProcess) bash[1] <-- TRANSFER RETRIEVE GPGHMACSHA512--952a317030848a0bcc83728f8fdba124b24763f32395b48481c1ac4f1645067be126ec1711008a14cfd62920284cc34e4a0f12d0617826c402b632dafc31578e .git\annex\tmp\GPGHMACSHA512--952a317030848a0bcc83728f8fdba124b24763f32395b48481c1ac4f1645067be126ec1711008a14cfd62920284cc34e4a0f12d0617826c402b632dafc31578e
+[2022-01-05 14:23:02.2925835] (Annex.ExternalAddonProcess) bash[1] --> DIRHASH-LOWER GPGHMACSHA512--952a317030848a0bcc83728f8fdba124b24763f32395b48481c1ac4f1645067be126ec1711008a14cfd62920284cc34e4a0f12d0617826c402b632dafc31578e
+[2022-01-05 14:23:02.2925835] (Annex.ExternalAddonProcess) bash[1] <-- VALUE da7\9eb\
+2022/01/05 14:23:03 ERROR : : error reading source directory: directory not found
+2022/01/05 14:23:03 ERROR : Attempt 1/3 failed with 1 errors and: directory not found
+2022/01/05 14:23:03 ERROR : : error reading source directory: directory not found
+2022/01/05 14:23:03 ERROR : Attempt 2/3 failed with 1 errors and: directory not found
+2022/01/05 14:23:04 ERROR : : error reading source directory: directory not found
+2022/01/05 14:23:04 ERROR : Attempt 3/3 failed with 1 errors and: directory not found
+2022/01/05 14:23:04 Failed to copy: directory not found
+[2022-01-05 14:23:04.1235177] (Annex.ExternalAddonProcess) bash[1] --> TRANSFER-FAILURE RETRIEVE GPGHMACSHA512--952a317030848a0bcc83728f8fdba124b24763f32395b48481c1ac4f1645067be126ec1711008a14cfd62920284cc34e4a0f12d0617826c402b632dafc31578e
+
+  user error (gpg ["--quiet","--trust-model","always","--batch","--passphrase-file","C:\\Users\\REDACTED\\AppData\\Local\\Temp\\gpg8159","--decrypt"] exited 2)
+
+  Unable to access these remotes: pcloud_annex
+
+  Maybe add some of these git remotes (git remote add ...):
+        bab5704a-562e-43eb-8bbb-71f181f043e8 -- BandName@computer-a:~/Splice/Christmas Steve Vocals
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+[2022-01-05 14:23:04.1457308] (Utility.Process) process [17136] done ExitSuccess
+[2022-01-05 14:23:04.1457308] (Utility.Process) process [17168] done ExitSuccess
+[2022-01-05 14:23:04.1466597] (Utility.Process) process [3996] done ExitSuccess
+[2022-01-05 14:23:04.1466597] (Utility.Process) process [16656] done ExitSuccess
+[2022-01-05 14:23:04.1576581] (Utility.Process) process [18812] done ExitSuccess
+[2022-01-05 14:23:04.1740489] (Utility.Process) process [6724] done ExitSuccess
+[2022-01-05 14:23:04.188721] (Utility.Process) process [16484] done ExitSuccess
+get: 1 failed
+```
+
+I don't know how to proceed. As I understand it, shared encryption shares a key between the git repos. What file stores the shared encryption key so I could see if it's the same in both places?
+
+Is there anything else obviously dumb I'm doing?
diff --git a/doc/forum/Windows_-_gpg_fails_with_shared_encryption/comment_1_708da81b0678576a240ce7a388806e07._comment b/doc/forum/Windows_-_gpg_fails_with_shared_encryption/comment_1_708da81b0678576a240ce7a388806e07._comment
new file mode 100644
index 0000000000..7e9d5713f5
--- /dev/null
+++ b/doc/forum/Windows_-_gpg_fails_with_shared_encryption/comment_1_708da81b0678576a240ce7a388806e07._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-01-05T19:44:24Z"
+ content="""
+The shared encryption key is what git-annex passes to gpg as
+"C:\\Users\\REDACTED\\AppData\\Local\\Temp\\gpg8159".
+
+From the other forum thread,
+[[Failing_to_get_files_from_rclone_special_remote]], 
+you had many special remotes that somehow existed with
+the same name.
+
+There's a big question mark over how you even got into that state.
+initremote does not let two special remotes with the same name be created
+in the same repository so normally it would be rather hard to accomplish
+once, let alone multiple times. Without understanding more, it's hard for
+me to guess what has happened.
+
+It also might be some problem with your gpg on windows. 
+googling for "gpg: decryption failed: Bad session key" seems to find that
+the problem is split between the wrong encryption key and some kind of gpg
+bugs.
+
+If you still have the data, would deleting that special remote and starting
+over with setting up a new one (with a different name!) be an option?
+"""]]
diff --git a/doc/forum/Windows_-_gpg_fails_with_shared_encryption/comment_2_9f5d0e8d0c6eff548318b54797cefd09._comment b/doc/forum/Windows_-_gpg_fails_with_shared_encryption/comment_2_9f5d0e8d0c6eff548318b54797cefd09._comment
new file mode 100644
index 0000000000..850d80e8c3
--- /dev/null
+++ b/doc/forum/Windows_-_gpg_fails_with_shared_encryption/comment_2_9f5d0e8d0c6eff548318b54797cefd09._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="arekmenner@f0f5403c5cbc803fedaf860e3a6f839a41075e3b"
+ nickname="arekmenner"
+ avatar="http://cdn.libravatar.org/avatar/ec065e4a23146814e887fdcd16a1ee44"
+ subject="reply"
+ date="2022-01-06T15:13:15Z"
+ content="""
+Very much so. I'll try to start this whole computer from a clean setup and we'll see where we get from there.
+
+My guess at what happened was it was a combination of interleaved inits/enables in desperation. In particular, any time a \"get\" failed it asked me to \"enableremote\" which I tried several times.
+"""]]
diff --git a/doc/forum/Windows_S3_host_issue.mdwn b/doc/forum/Windows_S3_host_issue.mdwn
new file mode 100644
index 0000000000..02cd879073
--- /dev/null
+++ b/doc/forum/Windows_S3_host_issue.mdwn
@@ -0,0 +1,11 @@
+I am trying to connect to dreamhost's objects (S3) platform.  I am using the windows version.  
+Am I specifying the host correctly? Any help is appreciated.
+
+$ git-annex initremote host="objects.dreamhost.com" cloud keyid=XXXXX type=S3
+
+initremote host=objects.dreamhost.com (encryption setup) (hybrid cipher with gpg
+ key 70827ADCDE25DA0F) (checking bucket...)
+git-annex: user error (openTCPConnection: host lookup failure for "host=objects.
+dreamhost.com-f5573b49-3668-4f94-a1da-aa55085c45e8.s3.amazonaws.com")
+failed
+git-annex.exe: initremote: 1 failed
diff --git a/doc/forum/Windows_S3_host_issue/comment_1_8c0a1e84713a04a25fdc1f74919d34aa._comment b/doc/forum/Windows_S3_host_issue/comment_1_8c0a1e84713a04a25fdc1f74919d34aa._comment
new file mode 100644
index 0000000000..7382cafa6e
--- /dev/null
+++ b/doc/forum/Windows_S3_host_issue/comment_1_8c0a1e84713a04a25fdc1f74919d34aa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 1"
+ date="2013-12-12T17:38:21Z"
+ content="""
+No, you cannot quote part of a parameter like that. git-annex thinks you are trying to use a host that includes the quote marks you put around it. 
+
+Since you're using Windows, I can't give any advice on how to use quoting at the shell/cmd prompt. However, I don't see any need for quoting here anyway.
+"""]]
diff --git a/doc/forum/Windows_S3_host_issue/comment_2_06ecc76797c430b27a2e24776761d043._comment b/doc/forum/Windows_S3_host_issue/comment_2_06ecc76797c430b27a2e24776761d043._comment
new file mode 100644
index 0000000000..3e918120ee
--- /dev/null
+++ b/doc/forum/Windows_S3_host_issue/comment_2_06ecc76797c430b27a2e24776761d043._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk_bIB1Vadfc_GfPLKX_ScfWFCcaGyk8Ac"
+ nickname="Rob"
+ subject="Remove quotes"
+ date="2013-12-13T04:44:22Z"
+ content="""
+I tried the command with and without quotes it results in the same error.  I think the issue is that the host is trying to resolve a concatenation of the hostname and amazon.com when in fact it should be resolving to the host name only.
+"""]]
diff --git a/doc/forum/Windows_S3_host_issue/comment_3_1715557daa15b9e9e17b4850141e62af._comment b/doc/forum/Windows_S3_host_issue/comment_3_1715557daa15b9e9e17b4850141e62af._comment
new file mode 100644
index 0000000000..e4645d07b0
--- /dev/null
+++ b/doc/forum/Windows_S3_host_issue/comment_3_1715557daa15b9e9e17b4850141e62af._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 3"
+ date="2013-12-16T17:07:17Z"
+ content="""
+Looking at this again, you forgot to tell it the name of the remote, so it took the first parameter (host=\"objects.dreamhost.com\" ) as the name. The rest probably follows from that mistake.
+
+use `git annex initremote mys3 host=...`
+"""]]
diff --git a/doc/forum/Windows_eol_issues.mdwn b/doc/forum/Windows_eol_issues.mdwn
new file mode 100644
index 0000000000..4bdf05721c
--- /dev/null
+++ b/doc/forum/Windows_eol_issues.mdwn
@@ -0,0 +1,552 @@
+This is just a heads-up with regards to end-of-line handling with git-annex.
+
+I've discussed in the past issues I've had with interoperability between Windows and Linux, the earliest I think being the CRLF eol in .git/hooks scripts created on Windows.
+
+I originally started using the Windows port when I had had minimal experience with git-annex. Since then, WSL has come along, coupled with better understanding of worlflows, overtaken an explicit need to use the Windows port, so I'm no longer going to use it for my primary workflows.
+
+But I will continue to check back with new releases of the Windows port to help improve it, as I think there will be users who for whatever reason must use the Windows port (I think Windows Subsystem Linux (WSL) isn't available on vanilla Windows I think... so there's that for example).
+
+In that vane, I'm demonstrating issues with end-of-line that I've noticed with the Windows port.
+
+Before I do that, I'd like to say... eol considerations have been a problem forever (eg. I observed meltdown when Cygwin dropped hybrid eol support many years ago), and Git for Windows itself has gotchas. I really value git-annex, and I want to be clear, this isn't whinging or complaining, just information.
+
+I'll summarise the problem. By default Git for Windows is setup for msdos CRLF line endings. That is, it expects text files to have CRLF line endings, and strips them to "normalise" the lines in storage.
+
+Under this default, the text files that substitute for unix symlinks are ending up with mixed eol. That is, the ones created by git-annex under Windows have LF only endings, and the ones that are created by merge from Unix have CRLF endings. Eg. from a workflow involving the creation of new repositories (note the hooks are created CRLF):
+
+[[!format  sh """
+...
+./.git/hooks/post-checkout:                               POSIX shell script, ASCII text executable, with CRLF line terminators
+./.git/hooks/post-merge:                                  POSIX shell script, ASCII text executable, with CRLF line terminators
+./.git/hooks/post-receive:                                POSIX shell script, ASCII text executable, with CRLF line terminators
+./.git/hooks/post-update.sample:                          POSIX shell script, ASCII text executable
+./.git/hooks/pre-applypatch.sample:                       POSIX shell script, ASCII text executable
+./.git/hooks/pre-commit:                                  POSIX shell script, ASCII text executable, with CRLF line terminators
+...
+./libc.so.6:                                              ASCII text, with CRLF line terminators
+./ntdll.dll:                                              ASCII text
+./wsl-os-release:                                         ASCII text, with CRLF line terminators
+"""]]
+
+From what I can tell, when you try to perform actions in an interoperable way, you get toggling between CRLF/LF. And some annex files get a compounding effect of CRLF endings.
+
+[[!format sh """
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ cat -vet .git/annex/mergedrefs
+95eca82f10ec85f9ed860af5a13ef48fe7801418^Irefs/heads/git-annex^M$
+436ed1bfa6abfc7be4ceeb39ea3b8bad976e27ca^Irefs/heads/git-annex^M^M$
+46a62f21bea952a3014a9fa875a010849ac4183f^Irefs/heads/git-annex^M^M^M$
+a05d9831a28c20babf0d414e0e4edee042b486d6^Irefs/heads/git-annex^M^M^M^M$
+a0bd57285fa715245deab6e5c117768c5da5d990^Irefs/heads/git-annex^M^M^M^M^M$
+"""]]
+
+Now, I know enough that I can probably avoid at least the former, by changing the git configuration for eol (though I have yet to test it). However, this vagary I suspect won't be changed by settings. That is, git-annex list, and probably some other git-annex commands, are inconsistent in their output of eol. git-annex list displays correctly in a Windows console, so I assume it is correctly outputting CRLF. But if I redirect the output to a file, the header correctly has CRLF, but the actually list entries do not:
+
+[[!format sh """
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ git-annex list > git-annex-list.out
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ file git-annex-list.out
+git-annex-list.out: ASCII text, with CRLF, LF line terminators
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ cat -vet git-annex-list.out
+here^M$
+|web^M$
+||bittorrent^M$
+|||^M$
+___ libc.so.6$
+___ ntdll.dll$
+"""]]
+
+Just to clarify, native Windows commands should have CRLF:
+
+[[!format  sh """
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ cmd /c
+Microsoft Windows [Version 10.0.19045.3570]
+(c) Microsoft Corporation. All rights reserved.
+
+@ C:\PublicData\Temp\git-annex-eol-demo.msw
+$ echo Hello > hello.txt
+
+@ C:\PublicData\Temp\git-annex-eol-demo.msw
+$ exit
+
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ cat -vet hello.txt
+Hello ^M$
+"""]]
+
+That's it. From here, I'll just detail the workflow that led me to this. Let's start with a WSL git repo.
+
+[[!format  sh """
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git version
+git version 2.39.2
+shaddy@mswhost-wsldebs:~$ git-annex version
+git-annex version: 10.20230321-1~ndall+1
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ cat wsl-os-release
+PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
+NAME="Debian GNU/Linux"
+VERSION_ID="12"
+VERSION="12 (bookworm)"
+VERSION_CODENAME=bookworm
+ID=debian
+HOME_URL="https://www.debian.org/"
+SUPPORT_URL="https://www.debian.org/support"
+BUG_REPORT_URL="https://bugs.debian.org/"
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git init
+hint: Using 'master' as the name for the initial branch. This default branch name
+hint: is subject to change. To configure the initial branch name to use in all
+hint: of your new repositories, which will suppress this warning, call:
+hint:
+hint:   git config --global init.defaultBranch <name>
+hint:
+hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
+hint: 'development'. The just-created branch can be renamed via this command:
+hint:
+hint:   git branch -m <name>
+Initialized empty Git repository in /home/shaddy/git-annex-eol-demo.wsl/.git/
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ find . -type f -print0 | xargs -0 file
+./.git/info/exclude:                    ASCII text
+./.git/hooks/commit-msg.sample:         POSIX shell script, ASCII text executable
+./.git/hooks/pre-receive.sample:        POSIX shell script, ASCII text executable
+./.git/hooks/pre-merge-commit.sample:   POSIX shell script, ASCII text executable
+./.git/hooks/pre-push.sample:           POSIX shell script, ASCII text executable
+./.git/hooks/fsmonitor-watchman.sample: Perl script text executable
+./.git/hooks/push-to-checkout.sample:   POSIX shell script, ASCII text executable
+./.git/hooks/update.sample:             POSIX shell script, ASCII text executable
+./.git/hooks/pre-commit.sample:         POSIX shell script, ASCII text executable
+./.git/hooks/pre-applypatch.sample:     POSIX shell script, ASCII text executable
+./.git/hooks/applypatch-msg.sample:     POSIX shell script, ASCII text executable
+./.git/hooks/pre-rebase.sample:         POSIX shell script, ASCII text executable
+./.git/hooks/prepare-commit-msg.sample: POSIX shell script, ASCII text executable
+./.git/hooks/post-update.sample:        POSIX shell script, ASCII text executable
+./.git/HEAD:                            ASCII text
+./.git/description:                     ASCII text
+./.git/config:                          ASCII text
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ cp /etc/os-release wsl-os-release
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ file wsl-os-release
+wsl-os-release: ASCII text
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git add wsl-os-release
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git commit -m wsl-os-release
+[master (root-commit) 64ebd49] wsl-os-release
+ 1 file changed, 9 insertions(+)
+ create mode 100644 wsl-os-release
+"""]]
+
+Now, in a git-bash.exe created window (that comes with Git for Windows):
+
+[[!format  sh """
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw
+$ git version
+git version 2.42.0.windows.2
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw
+$ git-annex version
+git-annex version: 10.20230927-g18f902efa9c53ffd75a16e25cc666334b1029ea8
+build flags: Assistant Webapp Pairing TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKE
+IN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S
+160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw
+$ git init
+hint: Using 'master' as the name for the initial branch. This default branch name
+hint: is subject to change. To configure the initial branch name to use in all
+hint: of your new repositories, which will suppress this warning, call:
+hint: 
+hint:   git config --global init.defaultBranch <name>
+hint: 
+hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
+hint: 'development'. The just-created branch can be renamed via this command:
+hint: 
+hint:   git branch -m <name>
+Initialized empty Git repository in C:/PublicData/Temp/git-annex-eol-demo.msw/.git/
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (master)
+$ find . -type f -print0 | xargs -0 file
+./.git/config:                          ASCII text
+./.git/description:                     ASCII text
+./.git/HEAD:                            ASCII text
+./.git/hooks/applypatch-msg.sample:     POSIX shell script, ASCII text executable
+./.git/hooks/commit-msg.sample:         POSIX shell script, ASCII text executable
+./.git/hooks/fsmonitor-watchman.sample: Perl script text executable
+./.git/hooks/post-update.sample:        POSIX shell script, ASCII text executable
+./.git/hooks/pre-applypatch.sample:     POSIX shell script, ASCII text executable
+./.git/hooks/pre-commit.sample:         POSIX shell script, ASCII text executable
+./.git/hooks/pre-merge-commit.sample:   POSIX shell script, ASCII text executable
+./.git/hooks/pre-push.sample:           POSIX shell script, ASCII text executable
+./.git/hooks/pre-rebase.sample:         POSIX shell script, ASCII text executable
+./.git/hooks/pre-receive.sample:        POSIX shell script, ASCII text executable
+./.git/hooks/prepare-commit-msg.sample: POSIX shell script, ASCII text executable
+./.git/hooks/push-to-checkout.sample:   POSIX shell script, ASCII text executable
+./.git/hooks/sendemail-validate.sample: POSIX shell script, ASCII text executable
+./.git/hooks/update.sample:             POSIX shell script, ASCII text executable
+./.git/info/exclude:                    ASCII text
+
+
+"""]]
+
+To keep things as simple as possible, I setup a "push" scheme to link the two repos. First, I demonstrate Unix -> Windows eol interplay and git-annex setup:
+
+[[!format  sh """
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git remote add msw /mnt/c/PublicData/Temp/git-annex-eol-demo.msw
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git push --set-upstream msw HEAD:fromwsl/master
+Enumerating objects: 3, done.
+Counting objects: 100% (3/3), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (2/2), done.
+Writing objects: 100% (3/3), 377 bytes | 377.00 KiB/s, done.
+Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
+To /mnt/c/PublicData/Temp/git-annex-eol-demo.msw
+ * [new branch]      HEAD -> fromwsl/master
+branch 'master' set up to track 'msw/fromwsl/master'.
+"""]]
+and push through to the first sign of trouble:
+[[!format  sh """
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (master)
+$ git merge fromwsl/master
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (master)
+$ file wsl-os-release
+wsl-os-release: ASCII text, with CRLF line terminators
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (master)
+$ git-annex init msw
+init msw
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Switched to branch 'adjusted/master(unlocked)'
+ok
+(recording state in git...)
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ cp /c/Windows/System32/ntdll.dll .
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ git-annex add ntdll.dll
+add ntdll.dll
+ok
+(recording state in git...)
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ git-annex sync
+commit
+warning: in the working copy of 'ntdll.dll', LF will be replaced by CRLF the next time Git touches it
+[adjusted/master(unlocked) b7cfd14] git-annex in msw
+ 1 file changed, 1 insertion(+)
+ create mode 100644 ntdll.dll
+ok
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ file ntdll.dll
+ntdll.dll: PE32+ executable (DLL) (console) x86-64, for MS Windows, 10 sections
+"""]]
+Now setup git-annex on WSL and grab ntdll.dll. Note the post-receive error. I forgot to change the eol on it first. Also, now setup a file for sending back to native Windows:
+[[!format  sh """
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git-annex init wsl
+init wsl ok
+(recording state in git...)
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git-annex info
+trusted repositories: 0
+semitrusted repositories: 4
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        1bc9600e-c005-49a8-ab3e-35f1cff640bd -- wsl [here]
+        80ece5fd-dab2-4271-a92f-e7c285c774c9 -- msw
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 1.02 terabytes (+100 megabytes reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 0
+size of annexed files in working tree: 0 bytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage:
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git-annex sync
+commit
+On branch master
+Your branch is up to date with 'msw/fromwsl/master'.
+
+nothing to commit, working tree clean
+ok
+pull msw
+remote: Enumerating objects: 12, done.
+remote: Counting objects: 100% (12/12), done.
+remote: Compressing objects: 100% (8/8), done.
+remote: Total 11 (delta 0), reused 0 (delta 0), pack-reused 0
+Unpacking objects: 100% (11/11), 1.04 KiB | 213.00 KiB/s, done.
+From /mnt/c/PublicData/Temp/git-annex-eol-demo.msw
+ * [new branch]      adjusted/master(unlocked) -> msw/adjusted/master(unlocked)
+ * [new branch]      git-annex                 -> msw/git-annex
+ * [new branch]      master                    -> msw/master
+ok
+(merging msw/git-annex into git-annex...)
+(recording state in git...)
+push msw
+Enumerating objects: 10, done.
+Counting objects: 100% (10/10), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (6/6), done.
+Writing objects: 100% (8/8), 737 bytes | 737.00 KiB/s, done.
+Total 8 (delta 2), reused 0 (delta 0), pack-reused 0
+fatal: cannot run hooks/post-receive: No such file or directory
+To /mnt/c/PublicData/Temp/git-annex-eol-demo.msw
+ * [new branch]      master -> synced/master
+ * [new branch]      git-annex -> synced/git-annex
+ok
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ ls -l
+total 4
+-rw-r--r-- 1 shaddy shaddy 267 Oct 26 10:52 wsl-os-release
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git-annex sync
+commit
+On branch master
+Your branch is up to date with 'msw/fromwsl/master'.
+
+nothing to commit, working tree clean
+ok
+pull msw
+remote: Enumerating objects: 7, done.
+remote: Counting objects: 100% (7/7), done.
+remote: Compressing objects: 100% (6/6), done.
+remote: Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
+Unpacking objects: 100% (6/6), 731 bytes | 182.00 KiB/s, done.
+From /mnt/c/PublicData/Temp/git-annex-eol-demo.msw
+ + c8f7ad8...c7101bd adjusted/master(unlocked) -> msw/adjusted/master(unlocked)  (forced update)
+   64ebd49..d2154f2  master                    -> msw/master
+   64ebd49..d2154f2  synced/master             -> msw/synced/master
+
+Updating 64ebd49..d2154f2
+Fast-forward
+ ntdll.dll | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 ntdll.dll
+
+Already up to date.
+ok
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ ls -l
+total 8
+lrwxrwxrwx 1 shaddy shaddy 198 Oct 26 11:04 ntdll.dll -> .git/annex/objects/5f/9X/SHA256E-s2028432--2c8154698c5d5162ec9751c8e6bba462d47f2293ced6be5763579af34334ada3.dll/SHA256E-s2028432--2c8154698c5d5162ec9751c8e6bba462d47f2293ced6be5763579af34334ada3.dll
+-rw-r--r-- 1 shaddy shaddy 267 Oct 26 10:52 wsl-os-release
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git-annex get ntdll.dll
+get ntdll.dll (from msw...)
+ok
+(recording state in git...)
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git-annex sync
+commit
+On branch master
+Your branch is ahead of 'msw/fromwsl/master' by 1 commit.
+  (use "git push" to publish your local commits)
+
+nothing to commit, working tree clean
+ok
+pull msw
+ok
+push msw
+Enumerating objects: 9, done.
+Counting objects: 100% (9/9), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (4/4), done.
+Writing objects: 100% (5/5), 457 bytes | 457.00 KiB/s, done.
+Total 5 (delta 1), reused 0 (delta 0), pack-reused 0
+fatal: cannot run hooks/post-receive: No such file or directory
+To /mnt/c/PublicData/Temp/git-annex-eol-demo.msw
+   46a62f2..436ed1b  git-annex -> synced/git-annex
+ok
+
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ cp /lib/x86_64-linux-gnu/libc.so.6 .
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git-annex add libc.so.6
+add libc.so.6
+ok
+(recording state in git...)
+shaddy@mswhost-wsldebs:~/git-annex-eol-demo.wsl$ git-annex sync
+commit
+[master 22a06f5] git-annex in wsl
+ 1 file changed, 1 insertion(+)
+ create mode 120000 libc.so.6
+ok
+pull msw
+remote: Enumerating objects: 9, done.
+remote: Counting objects: 100% (9/9), done.
+remote: Compressing objects: 100% (4/4), done.
+remote: Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
+Unpacking objects: 100% (5/5), 395 bytes | 131.00 KiB/s, done.
+From /mnt/c/PublicData/Temp/git-annex-eol-demo.msw
+   436ed1b..1c0face  git-annex  -> msw/git-annex
+ok
+(merging msw/git-annex into git-annex...)
+(recording state in git...)
+push msw
+Enumerating objects: 13, done.
+Counting objects: 100% (13/13), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (9/9), done.
+Writing objects: 100% (10/10), 1.20 KiB | 1.20 MiB/s, done.
+Total 10 (delta 0), reused 0 (delta 0), pack-reused 0
+fatal: cannot run hooks/post-receive: No such file or directory
+To /mnt/c/PublicData/Temp/git-annex-eol-demo.msw
+   436ed1b..95eca82  git-annex -> synced/git-annex
+   d2154f2..22a06f5  master -> synced/master
+ok
+"""]]
+
+And finally, corrupting git structure backing git-annex:
+
+[[!format  sh """
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ git-annex list --allrepos
+here
+|web
+||bittorrent
+|||wsl
+||||
+X__X ntdll.dll
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ git-annex drop --force ntdll.dll
+drop ntdll.dll ok
+(recording state in git...)
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ file ntdll.dll
+ntdll.dll: ASCII text
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ git-annex sync
+commit
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+ok
+merge synced/master master (Merging into master...)
+Updating d2154f2..22a06f5
+Fast-forward
+ libc.so.6 | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 libc.so.6
+(Merging into adjusted branch...)
+Updating c7101bd..99dbd2c
+Fast-forward
+ libc.so.6 | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 libc.so.6
+
+Already up to date.
+(Merging into adjusted branch...)
+Updating d0175a9..8153e87
+Fast-forward
+ok
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ file ntdll.dll  libc.so.6
+ntdll.dll: ASCII text
+libc.so.6: ASCII text, with CRLF line terminators
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ git-annex list > git-annex-list.out
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ cat -vet git-annex-list.out
+here^M$
+|web^M$
+||bittorrent^M$
+|||^M$
+___ libc.so.6$
+___ ntdll.dll$
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ find . -type f -print0 | xargs -0 file
+./.git/annex/adjust.lck:                                  empty
+./.git/annex/adjust.log:                                  ASCII text
+./.git/annex/fsck/fsck.lck:                               empty
+./.git/annex/fsck/fsckdb/db:                              SQLite 3.x database, last written using SQLite version 3033000, writer version 2, read version 2, file counter 2, database pages 3, cookie 0x1, schema 4, UTF-8, version-valid-for 2
+./.git/annex/gitqueue.lck:                                empty
+./.git/annex/index:                                       Git index, version 2, 3 entries
+./.git/annex/index.lck:                                   ASCII text, with CRLF line terminators
+./.git/annex/journal.lck:                                 empty
+./.git/annex/keysdb/db:                                   SQLite 3.x database, last written using SQLite version 3033000, writer version 2, read version 2, file counter 2, database pages 7, cookie 0x2, schema 4, UTF-8, version-valid-for 2
+./.git/annex/keysdb.cache:                                ASCII text, with no line terminators
+./.git/annex/keysdb.lck:                                  empty
+./.git/annex/mergedrefs:                                  ASCII text, with CRLF, CR line terminators
+./.git/annex/othertmp.lck:                                empty
+./.git/annex/restage.lck:                                 empty
+./.git/annex/sentinal:                                    empty
+./.git/annex/sentinal.cache:                              ASCII text, with no line terminators
+./.git/annex/smudge.lck:                                  empty
+./.git/annex/smudge.log:                                  empty
+./.git/COMMIT_EDITMSG:                                    ASCII text
+./.git/config:                                            ASCII text
+./.git/description:                                       ASCII text
+./.git/HEAD:                                              ASCII text
+./.git/hooks/applypatch-msg.sample:                       POSIX shell script, ASCII text executable
+./.git/hooks/commit-msg.sample:                           POSIX shell script, ASCII text executable
+./.git/hooks/fsmonitor-watchman.sample:                   Perl script text executable
+./.git/hooks/post-checkout:                               POSIX shell script, ASCII text executable, with CRLF line terminators
+./.git/hooks/post-merge:                                  POSIX shell script, ASCII text executable, with CRLF line terminators
+./.git/hooks/post-receive:                                POSIX shell script, ASCII text executable, with CRLF line terminators
+./.git/hooks/post-update.sample:                          POSIX shell script, ASCII text executable
+./.git/hooks/pre-applypatch.sample:                       POSIX shell script, ASCII text executable
+./.git/hooks/pre-commit:                                  POSIX shell script, ASCII text executable, with CRLF line terminators
+./.git/hooks/pre-commit.sample:                           POSIX shell script, ASCII text executable
+./.git/hooks/pre-merge-commit.sample:                     POSIX shell script, ASCII text executable
+./.git/hooks/pre-push.sample:                             POSIX shell script, ASCII text executable
+./.git/hooks/pre-rebase.sample:                           POSIX shell script, ASCII text executable
+./.git/hooks/pre-receive.sample:                          POSIX shell script, ASCII text executable
+./.git/hooks/prepare-commit-msg.sample:                   POSIX shell script, ASCII text executable
+./.git/hooks/push-to-checkout.sample:                     POSIX shell script, ASCII text executable
+./.git/hooks/sendemail-validate.sample:                   POSIX shell script, ASCII text executable
+./.git/hooks/update.sample:                               POSIX shell script, ASCII text executable
+./.git/index:                                             Git index, version 2, 3 entries
+./.git/info/attributes:                                   ASCII text, with CRLF line terminators
+./.git/info/exclude:                                      ASCII text
+./.git/logs/HEAD:                                         ASCII text
+./.git/logs/refs/heads/adjusted/master(unlocked):         ASCII text
+./.git/logs/refs/heads/fromwsl/master:                    ASCII text
+./.git/logs/refs/heads/git-annex:                         ASCII text
+./.git/logs/refs/heads/master:                            ASCII text
+./.git/logs/refs/heads/synced/git-annex:                  ASCII text
+./.git/logs/refs/heads/synced/master:                     ASCII text
+...
+./.git/ORIG_HEAD:                                         ASCII text
+./.git/refs/annex/last-index:                             ASCII text
+./.git/refs/basis/adjusted/master(unlocked):              ASCII text
+./.git/refs/heads/adjusted/master(unlocked):              ASCII text
+./.git/refs/heads/fromwsl/master:                         ASCII text
+./.git/refs/heads/git-annex:                              ASCII text
+./.git/refs/heads/master:                                 ASCII text
+./.git/refs/heads/synced/git-annex:                       ASCII text
+./.git/refs/heads/synced/master:                          ASCII text
+./git-annex-list.out:                                     ASCII text, with CRLF, LF line terminators
+./libc.so.6:                                              ASCII text, with CRLF line terminators
+./ntdll.dll:                                              ASCII text
+./wsl-os-release:                                         ASCII text, with CRLF line terminators
+
+shaddy@mswhost-w10 MINGW64 /c/PublicData/Temp/git-annex-eol-demo.msw (adjusted/master(unlocked))
+$ cat -vet .git/annex/mergedrefs
+95eca82f10ec85f9ed860af5a13ef48fe7801418^Irefs/heads/git-annex^M$
+436ed1bfa6abfc7be4ceeb39ea3b8bad976e27ca^Irefs/heads/git-annex^M^M$
+46a62f21bea952a3014a9fa875a010849ac4183f^Irefs/heads/git-annex^M^M^M$
+a05d9831a28c20babf0d414e0e4edee042b486d6^Irefs/heads/git-annex^M^M^M^M$
+a0bd57285fa715245deab6e5c117768c5da5d990^Irefs/heads/git-annex^M^M^M^M^M$
+
+"""]]
diff --git a/doc/forum/Windows_eol_issues/comment_1_72e4c3a200e3fceb2afd4df563eaa5d4._comment b/doc/forum/Windows_eol_issues/comment_1_72e4c3a200e3fceb2afd4df563eaa5d4._comment
new file mode 100644
index 0000000000..39531ff1b5
--- /dev/null
+++ b/doc/forum/Windows_eol_issues/comment_1_72e4c3a200e3fceb2afd4df563eaa5d4._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-10-26T18:36:59Z"
+ content="""
+The .git/annex/mergedrefs problem seems to indicate that `git show-ref` is
+outputting lines ending with CRLF. That's surprising to me, I thought git
+commands on Windows didn't output CRLF at least when piped.
+Can you show the output of that command fed through `cat -vet` please?
+
+In retrospect it would be better if annex pointer files did not end in a
+newline at all. It's not really necessary that they do, and that would
+avoid git for windows from messing with their content when merging them
+from elsewhere. However, AFAIK git-annex manages to not break despite git
+doing that to its pointer file, by ignoring CR in pointer files
+(see [[!commit 4d89a1ffd1b4bfd423c11c9e703e9d2fb0f5fb25]]). 
+So I'm not sure what problem you're demonstrating with that example merge?
+
+git-annex list is displaying CRLF for the header because it uses putStrLn
+for it, and putStrLn on Windows uses CRLF by default (due to the default NewlineMode
+on Windows). Then for the file list it uses ByteString.Char8.putStrLn, which does
+not use CRLF. Since those two are generally seen as equivilant and code is
+often switched between them to improve performance, it would be a real
+ongoing pain point to remember this gotcha. This makes me think that
+git-annex on windows ought to `hSetNewlineMode stdout noNewlineTranslation`
+so it consistently outputs without CRLF.
+
+About the CRLF in the hooks, I know it's been discussed somewhere before,
+but I can't remember where. IIRC there were some complexities involving
+what the bash bundled with git expected to find.
+"""]]
diff --git a/doc/forum/Windows_eol_issues/comment_2_77383b959d576c7930c726c55097c964._comment b/doc/forum/Windows_eol_issues/comment_2_77383b959d576c7930c726c55097c964._comment
new file mode 100644
index 0000000000..9d333158fc
--- /dev/null
+++ b/doc/forum/Windows_eol_issues/comment_2_77383b959d576c7930c726c55097c964._comment
@@ -0,0 +1,137 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 2"
+ date="2023-10-27T18:45:03Z"
+ content="""
+@joey, just out of curiosity (and concern) I took a peek into my .git/annex/mergedrefs files (within native Windows annexes
+ -- no WSL involved) and sure enough I had a similar presentation where CRs had become multiplied at the end
+of the lines. However, when you ask if `git show-ref` is outputting any lines ending with CRLF, that doesn't
+seem to be the case:
+
+[[!format sh \"\"\"
+jkniiv@AINESIS MINGW64 /c/git-annex-tested-binaries (adjusted/master(unlocked))
+$ git show-ref | cat -vet
+c10f7c4ed5751458b0c5fa687fa4fe1bcc538140 refs/annex/last-index$
+00ff347497e0c1d921b7f2484d092e9ac18657cb refs/basis/adjusted/master(unlocked)$
+a9f629165f81c026322bd4a58b2704dc557b5d48 refs/heads/adjusted/master(unlocked)$
+92e22121afd9d47fd63f27a0709d86da0485d2be refs/heads/git-annex$
+00ff347497e0c1d921b7f2484d092e9ac18657cb refs/heads/master$
+9b5e29d8c3bef88b9537864d6b3ae56d5c29a429 refs/heads/synced/git-annex$
+00ff347497e0c1d921b7f2484d092e9ac18657cb refs/heads/synced/master$
+782a184a8a9d11d2b7fc9f5990b33ebddc4ff9d0 refs/remotes/gatb-archive/git-annex$
+11803c78a1bfd54c4e5e0ee19d5de020f9990cb2 refs/remotes/gatb-archive/master$
+782a184a8a9d11d2b7fc9f5990b33ebddc4ff9d0 refs/remotes/gatb-archive/synced/git-annex$
+11803c78a1bfd54c4e5e0ee19d5de020f9990cb2 refs/remotes/gatb-archive/synced/master$
+941d08010d54724495fb5ccf69f6943083dec61f refs/remotes/gatb-bare/adjusted/master(unlocked)$
+92e22121afd9d47fd63f27a0709d86da0485d2be refs/remotes/gatb-bare/git-annex$
+00ff347497e0c1d921b7f2484d092e9ac18657cb refs/remotes/gatb-bare/master$
+92e22121afd9d47fd63f27a0709d86da0485d2be refs/remotes/gatb-bare/synced/git-annex$
+00ff347497e0c1d921b7f2484d092e9ac18657cb refs/remotes/gatb-bare/synced/master$
+ead34cd4d6a1dfb372b69d7acd88a70a96d5a547 refs/remotes/gatb-hetzner/git-annex$
+13bf1536cb3bcd22216f7696011327cb3bf1a81d refs/remotes/gatb-hetzner/master$
+ead34cd4d6a1dfb372b69d7acd88a70a96d5a547 refs/remotes/gatb-hetzner/synced/git-annex$
+13bf1536cb3bcd22216f7696011327cb3bf1a81d refs/remotes/gatb-hetzner/synced/master$
+65a00ffec41383ad7e06198e6aae3150b96032e2 refs/remotes/gawb4/git-annex$
+d2f6d4dadd5fa404c3c70b4e2713c3f73918cbf9 refs/remotes/gawb4/master$
+65a00ffec41383ad7e06198e6aae3150b96032e2 refs/remotes/gawb4/synced/git-annex$
+d2f6d4dadd5fa404c3c70b4e2713c3f73918cbf9 refs/remotes/gawb4/synced/master$
+
+jkniiv@AINESIS MINGW64 /c/git-annex-tested-binaries (adjusted/master(unlocked))
+$ git show-ref | od -a | head
+0000000   c   1   0   f   7   c   4   e   d   5   7   5   1   4   5   8
+0000020   b   0   c   5   f   a   6   8   7   f   a   4   f   e   1   b
+0000040   c   c   5   3   8   1   4   0  sp   r   e   f   s   /   a   n
+0000060   n   e   x   /   l   a   s   t   -   i   n   d   e   x  nl   0
+0000100   0   f   f   3   4   7   4   9   7   e   0   c   1   d   9   2
+0000120   1   b   7   f   2   4   8   4   d   0   9   2   e   9   a   c
+0000140   1   8   6   5   7   c   b  sp   r   e   f   s   /   b   a   s
+0000160   i   s   /   a   d   j   u   s   t   e   d   /   m   a   s   t
+0000200   e   r   (   u   n   l   o   c   k   e   d   )  nl   a   9   f
+0000220   6   2   9   1   6   5   f   8   1   c   0   2   6   3   2   2
+\"\"\"]]
+
+Just to prove my case, this is how .git/annex/mergedrefs looks like in the above repo:
+
+[[!format sh \"\"\"
+jkniiv@AINESIS MINGW64 /c/git-annex-tested-binaries (adjusted/master(unlocked))
+$ cat -vet .git/annex/mergedrefs
+92e22121afd9d47fd63f27a0709d86da0485d2be^Irefs/heads/git-annex^M$
+2e3dd770daa05dfaa023fc492fa13fd5af056694^Irefs/heads/git-annex^M^M$
+b8e586bb07a49c0c67616314e37783d21f18e70f^Irefs/heads/git-annex^M^M^M$
+6932d8306081c2506e2dc720cef6c6c4039044a5^Irefs/remotes/gatb-bare/git-annex^M^M^M^M$
+9b5e29d8c3bef88b9537864d6b3ae56d5c29a429^Irefs/heads/git-annex^M^M^M^M^M$
+ead34cd4d6a1dfb372b69d7acd88a70a96d5a547^Irefs/heads/git-annex^M^M^M^M^M^M$
+286d76b2cd3cceb25322021012ab3a6a478779bc^Irefs/heads/git-annex^M^M^M^M^M^M^M$
+05a146f6a8357e92e9b2dc6b4ed3dd63a5ccd467^Irefs/heads/git-annex^M^M^M^M^M^M^M^M$
+3946949105cc004919c2e1a41ebd5ee4553f40f3^Irefs/heads/git-annex^M^M^M^M^M^M^M^M^M$
+debedf463e5bd4f420271e6e4550c46c683e6c91^Irefs/heads/git-annex^M^M^M^M^M^M^M^M^M^M$
+8b56b9f04394bd6735e729fa9fd206493acd11ae^Irefs/heads/git-annex^M^M^M^M^M^M^M^M^M^M^M$
+c1d72955c7bb1e3ab71373ad1ed66066c03a40dd^Irefs/heads/git-annex^M^M^M^M^M^M^M^M^M^M^M^M$
+3268d0d1937f1f86f9794526330e0b5a8dbf7ac7^Irefs/heads/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M$
+db9a8f6f0631f13665f520e372dc1b425a197b73^Irefs/heads/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+fcd934175a3dab20cf9e66040126922febab3107^Irefs/heads/synced/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+782a184a8a9d11d2b7fc9f5990b33ebddc4ff9d0^Irefs/remotes/gatb-archive/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+f054b35273e9ee8797c4570782ebf8de923b8bec^Irefs/remotes/gatb-bare/synced/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+65a00ffec41383ad7e06198e6aae3150b96032e2^Irefs/remotes/gawb4/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+1ab48671d698ad56df6fae874ffb918b5b7c55da^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+cf6514421f552040f65a5f64f10cdb8644a91367^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+bcb6cb79e2822eb87a517909305ba7738af71fb7^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+57408550366738cb1440f8ad0052cef11170837d^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+14783b3c3383df28e86902758b024f09915fe79d^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+e1f481c2ff3be7da1c4adfa6148aa00bb652fecc^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+785fe3d81ea5ce4c1843b993e2487830133f6380^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+1c1ffa7bbec72b0bdc251561b82be283b149d814^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+7344df6135fc90d38f6ab2c7e184813849040b1b^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+5a434c6c53fee582bbf1a84941dcc21edc860f6b^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+e2c44e5214f06ab0897363677111124ac7b165bd^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+79d2b38753bce49828f6ed585f6891ae5d394e63^Irefs/remotes/gawb4/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+fa0d446f0e67658a40c4f1c6153522d7544afa16^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+1d2d0cca747460254d35a6a1717401a566fdc892^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+2ac05dcb208ef343b0baf21755cf268c3a3bea36^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+857832b466f608781c342ea946de42e2707a7f7d^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+cecf8c16a0cfc1e862e4c287305065ddfed215cc^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+e27eca9c36d4c9fe733ba4d8312091e3dab8eabd^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+c28cd1c09f3498073b5239dfb5a0c00396b0a0d3^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+ddf4486a7cf3219ad79ea72ab94611f65dcd8c75^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+cf5f396481de19336e6157f62fa4f76e02049f62^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+0757122bb58d08024ee8184c871cdff28746958a^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+3ba81bd06ffdc3598131acd83b9d9c825e547b9a^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+e77b6e375092ae03b13b7518e62148c6ac424c80^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+8e78173936ec9a134a12c80b4c0705098eff3793^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+a50f6a64b8d47dd1084b1b49817cc073b1f0ff9e^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+644a387e091a0878c2ad1b4d90d5ad4abf7e195e^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+f6432e124a8cadc45f96c7ab64ae1657d6417259^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+650a95c4d04438a91319e6fe214b103fa3599a33^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+e0e3a5ed05ccfca84c084850af21188b4262c63b^Irefs/remotes/gatb-hetzner/synced/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+0e84071b9352d587611d927636de4aaec95f01b9^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+fb38147c51706678ecb1c353e997a29604ee1a19^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+bfec3c6a4c93194f0b1a18117b6c5fae02b9f517^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+3fd7a8a29b00f2e11042d9fad7b3c24c5121a98c^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+f1c01aad6a1fcb7c6c3f13a74434eac34f4df397^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+d10cff285d737d6335a28e5966df21d333c0ce15^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+7cc02c1fbd05b1537cea55385e8f500c3c58b6a3^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+7424f6b424a4934945c22794291fa3e35734c66a^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+362f5ebc033bc8660bb45da356cfa78512a22922^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+b32c1c0152ddb3bb07981b471a7a44c2bb0cfae0^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+64df2acfeb780cb77a7b9a3882ba39fc29399616^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+53cb9f7c033c887bf76b7a5445161f846397d5dc^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+db2233280bc66f524fd1427c7fe8bfad732189b9^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+cee656c1fa1f53f84c7acdf9f88cd5dba86e9934^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+554e4ea4cb16b69964ce4a4e8be3eccb3f516e12^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+c93d2de1fc7173768730567839a7c335d45c055b^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+f71d65064f2d417e8198a6ebfdb47d1fa654412a^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+7d8914cd49d9ae8235a93c0f85e64822284ec955^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+396b17eec3f1cc1a1769fdbae3a26d5f32462777^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+c8276787b4aeb8db842bd718a1a2f55f4e9b2959^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+15c14cd9d37769315e6620b0a55f0d2428e54e50^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+ab2e5c00e0265c9c028477172c852d9cabf16c90^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+0ac85b5975b385669f7bc22d8cf79ccdb533162b^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+fef8eedd67a1178ec3ea9c4f0612eef238d10c7d^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+af383db2d08d956c150948d8fe330aad2298ae36^Irefs/remotes/gatb-hetzner/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+98aaf6d680c1ca1610634ff92500c7ce9734788c^Irefs/remotes/gatb-archive/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+ed4e3318763983db679d0b1fea727072afdca98e^Irefs/remotes/gatb-bare/git-annex^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M^M$
+\"\"\"]]
+
+Do you think we have a cause for concern? How should this file be formatted -- i.e. should there be multiple hashes for any one ref like above?
+"""]]
diff --git a/doc/forum/Windows_eol_issues/comment_3_926b386f5ca59f1c5232cf5cba69e12a._comment b/doc/forum/Windows_eol_issues/comment_3_926b386f5ca59f1c5232cf5cba69e12a._comment
new file mode 100644
index 0000000000..9180392629
--- /dev/null
+++ b/doc/forum/Windows_eol_issues/comment_3_926b386f5ca59f1c5232cf5cba69e12a._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-10-30T17:04:40Z"
+ content="""
+I would not be concerned about the contents of the mergedrefs file, since
+it is only an optimisation and at worst git-annex does a little extra work
+re-merging a branch it has already merged.
+
+I've fixed this in [[!commit eb42935e5822a43ec29c1c113d5df62ea676d119]].
+Several log files were affected as detailed in the commit, but it seems
+nothing really broke, only some optimisations were prevented from working,
+luckily.
+
+Also I checked git commands on windows and nothing I tried output CRLF to
+stdout on windows. So I've made git-annex follow suite, and disabled
+NewlineMode for stdout.
+"""]]
diff --git a/doc/forum/Windows_eol_issues/comment_4_dc470ae359ee4ce017770a89441a8b65._comment b/doc/forum/Windows_eol_issues/comment_4_dc470ae359ee4ce017770a89441a8b65._comment
new file mode 100644
index 0000000000..7ed6e8bd64
--- /dev/null
+++ b/doc/forum/Windows_eol_issues/comment_4_dc470ae359ee4ce017770a89441a8b65._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 4"
+ date="2023-10-30T21:32:07Z"
+ content="""
+Ok thanks, Joey, for the quick fix!
+"""]]
diff --git a/doc/forum/Windows_eol_issues/comment_5_e711bdfcee4ec9a2860662e8c65a9c0f._comment b/doc/forum/Windows_eol_issues/comment_5_e711bdfcee4ec9a2860662e8c65a9c0f._comment
new file mode 100644
index 0000000000..2faa2e4ce8
--- /dev/null
+++ b/doc/forum/Windows_eol_issues/comment_5_e711bdfcee4ec9a2860662e8c65a9c0f._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-11-02T17:28:49Z"
+ content="""
+Took a look at hook script line endings on windows, and found that they
+work both with CRLF endings and without the CR.
+
+It seems better to not use CR in them, because git for windows does not
+in the examples it writes, and because it will make the hooks portable if
+the repository gets moved to a unix system.
+
+So, I made `git-annex init` omit the CR when writing new hook scripts.
+Existing hook scripts that use CRLF will be preserved by git-annex.
+
+I have not been able to reproduce this problem with or without CR in hook
+scripts:
+
+	fatal: cannot run hooks/post-receive: No such file or directory
+"""]]
diff --git a/doc/forum/Windows_eol_issues/comment_6_62f748e40324bc988366e19088b33295._comment b/doc/forum/Windows_eol_issues/comment_6_62f748e40324bc988366e19088b33295._comment
new file mode 100644
index 0000000000..594da81fa5
--- /dev/null
+++ b/doc/forum/Windows_eol_issues/comment_6_62f748e40324bc988366e19088b33295._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ nickname="beryllium"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="comment 6"
+ date="2023-11-14T22:43:22Z"
+ content="""
+I'm so sorry for the delay in this response, and the fact that it is not a response. I thought I had turned on email notifications, and missed the responses. I've skimmed those at this point, but will read properly and respond to clarifications.
+
+
+"""]]
diff --git a/doc/forum/Windows_eol_issues/comment_7_f9b71ea2158c02dfa8a7c59891aea679._comment b/doc/forum/Windows_eol_issues/comment_7_f9b71ea2158c02dfa8a7c59891aea679._comment
new file mode 100644
index 0000000000..952592b2db
--- /dev/null
+++ b/doc/forum/Windows_eol_issues/comment_7_f9b71ea2158c02dfa8a7c59891aea679._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ nickname="beryllium"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="comment 7"
+ date="2023-11-21T09:25:33Z"
+ content="""
+Thanks joey for your response. And thank you for jkniiv for providing the output to git show-head, it matches what I see.
+
+With regards to the pointer file... I think the problem I have with it is.. well, first the avoidable warning:
+
+[[!format  sh \"\"\"
+warning: in the working copy of 'ntdll.dll', LF will be replaced by CRLF the next time Git touches it
+\"\"\"]]
+
+I guess also, because git-annex doesn't honour (??) git's actual expectations on line mode, you end up with git thinking a file is modified. Because git knows it as text, and in the default mode under Windows, it expects the text file to be CRLF.
+
+Also... I guess in a way, once Windows has acted on a file that came from unix, it now becomes a pointer file on disk. You can't get the benefit of the symlink to view the contents.
+
+Also also... I don't think I demonstrated it here, but I found that eventually, some merge would cause the line-ending to flip, and then there would be another unnecessary checkin of the pointer file.
+
+Sorry if this is all a bit abstract. I was working on large repos, oblivious to some of what I found and have pasted above, and was filling in the \"bitmap\" of my knowledge piecemeal.
+
+With the CRLF hooks, yes, I originally reported that. So in the above, not how I do a push msw to wsl only, and no pull from msw at wsl. That's because that type of pull would break, with the wsl/linux system() call interpreting the CR as part of the shebang, and being unable to execute the shell itself.
+
+"""]]
diff --git a/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__.mdwn b/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__.mdwn
new file mode 100644
index 0000000000..99dcc799b0
--- /dev/null
+++ b/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__.mdwn
@@ -0,0 +1,6 @@
+Hi, I'm trying to use git annex through git bash on windows, I've installed git (32 bit) and git annex yet I get the error mentioned above.
+
+I've already had a search and have tried sorting out my windows environment paths as well as moving git annex .exe files from cmd to bin, neither of which have fixed the issue. Any ideas?
+
+Thanks
+Joe
diff --git a/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_1_b051dc30bf5a0fc9f5710c664f487ea9._comment b/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_1_b051dc30bf5a0fc9f5710c664f487ea9._comment
new file mode 100644
index 0000000000..eba1455f1f
--- /dev/null
+++ b/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_1_b051dc30bf5a0fc9f5710c664f487ea9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-21T16:39:54Z"
+ content="""
+Please make sure you have Git For Windows, and the current version
+5.20150916 
+of git-annex installed. msysgit is no longer supported, and any
+older version of git-annex won't work with Git For Windows.
+
+Since you mention git-annex.exe in the cmd directory, I guess
+you probably have an old version installed. The current version
+does not put that file there.
+"""]]
diff --git a/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_2_8775a1483b29e2cc8f0456473c24e51e._comment b/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_2_8775a1483b29e2cc8f0456473c24e51e._comment
new file mode 100644
index 0000000000..d757ef7f1b
--- /dev/null
+++ b/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_2_8775a1483b29e2cc8f0456473c24e51e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="dfiorentino@645c87e5e4e39b138b9717d01441dc2e3914fe01"
+ nickname="dfiorentino"
+ subject="“Windows error: &quot;git: 'annex' is not a git command.&quot;” "
+ date="2015-09-22T18:54:38Z"
+ content="""
+I am having the same issue… “Windows error: \"git: 'annex' is not a git command.\"” I downloaded Git for Windows from https://downloads.kitenet.net/git-annex/windows/current/ and ran git-annex-installer.exe - 2015-09-16 11:43 	18M
+"""]]
diff --git a/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_3_cbaa3e0fa4e2347332b3929411f60d1d._comment b/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_3_cbaa3e0fa4e2347332b3929411f60d1d._comment
new file mode 100644
index 0000000000..e68f9b0809
--- /dev/null
+++ b/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_3_cbaa3e0fa4e2347332b3929411f60d1d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-09-22T19:33:09Z"
+ content="""
+@dfiorentino um, are you sure you have Git For Windows installed, and not the old
+msysgit? What does git --version say?
+
+(You don't download Git For Windows from where you said you downloaded it,
+so I think you're confused about something.)
+"""]]
diff --git a/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_4_3dc3cc824256b1f7530c7f516b0abbec._comment b/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_4_3dc3cc824256b1f7530c7f516b0abbec._comment
new file mode 100644
index 0000000000..d585818600
--- /dev/null
+++ b/doc/forum/Windows_error__58_____34__git__58_____39__annex__39___is_not_a_git_command.__34__/comment_4_3dc3cc824256b1f7530c7f516b0abbec._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="Basil_Peace"
+ avatar="http://cdn.libravatar.org/avatar/f59bd5c8401a86f90f98836dec27eeca"
+ subject="Still problems"
+ date="2022-07-12T01:28:10Z"
+ content="""
+I have the same error. Fresh git 2.37.0 and git-annex 10.20220526.
+
+Looks like adding `c:\Program Files\Git\usr\bin` to `PATH` can fix the issue for me.
+
+IIRC, Git for Windows asks during installation whether to add all tools to the PATH or just the main ones.
+And I prefer just the main tools, since I have separate iconv, GPG etc. installations.
+
+Is there any reason why git-annex is installed in Git dir? Why doesn't it use its own?
+If separate dir is not an option then I propose to add to `git-annex.cmd`:
+
+```
+@echo off
+setlocal
+set PATH=%~dp0..\usr\bin;%PATH%
+```
+
+`git annex` still won't work, but `git-annex` will.
+"""]]
diff --git a/doc/forum/Windows_installation_notes.mdwn b/doc/forum/Windows_installation_notes.mdwn
new file mode 100644
index 0000000000..3fb25ec050
--- /dev/null
+++ b/doc/forum/Windows_installation_notes.mdwn
@@ -0,0 +1,146 @@
+[[!toc]]
+
+# Introduction
+
+Hello.
+
+I've installed git-annex and git-annex assistant on Windows 7 in a corp environment (hello gotchas!).
+
+In this post I'll describe issues I encountered, how I fixed them, recommendations I have for the installer, and some results from a couple `git annex test` runs.
+
+# Background
+
+My regular domain user doesn't have permissions to write to `C:\Program Files (x86)`, so I use a secondary domain user which is in the Administrators group.  I use "Run as different user" to run installers, etc.  (cf. "Run as Administrator")
+
+During msysgit installation I checked "only bash, don't add to path, don't integrate with Explorer" etc, since I like my third-party applications isolated.
+
+# The installer
+
+## Where to install `git-annex.exe`
+
+The nightly build of git-annex/assistant from NEST (20140908) only prompts for the base path of the msysgit location and it installs files in `$BASE/bin` and `$BASE/cmd`...  I'll try manually copying files post-install to mitigate the path issues described in other posts on this forum.
+
+The msysgit installer (1.9.4-preview20140815) presents a certain screen with three radio options:
+
+1. git bash only
+2. just git in `cmd.exe`
+3. git + unix tools in `cmd.exe`.
+
+I *think* this is the meaning of each:
+
+1. cmd.exe's PATH is not touched.
+2. `$GITBASE/cmd` is added to PATH
+3. `$GITBASE/bin` is added to PATH
+
+Therefore, I think that if you do something so that `git-annex.exe` is added to both $GITBASE/cmd and $GITBASE/bin (perhaps a symlink or even a .lnk file) then all three user preference options will be covered.
+
+All I did was copy `$BASE/cmd/git-annex.exe` to `$BASE/bin/git-annex.exe` and now both `git annex` and `git-annex` work in my msysgit "git bash" console.  I didn't test `cmd.exe` since I selected option 1 in the msysgit installer.
+
+## Installer locations: user profile or system-wide?
+
+I found a shortcut for the webapp in Start Menu/Startup ... for the wrong user.  Please prompt the user during the installation: "Install startup link system-wide or for current user?"
+
+# git annex test results
+
+## `$HOME` defaulted to some mapped drive, whoops!
+
+The test suite has been running since before I started this post.  Is that normal? :)
+
+I notice that it emits "Detected a crippled filesystem", "Enabling direct mode." and other messages again and again.  If those checks are expensive, maybe the result should be memoized/cached.
+
+Oh goodness, the test is reading and writing to my "home directory": a remote filesystem I never use.  It's slow.  I'll have to configure msysgit to use a different, more local `$HOME`.  This a common problem on this workstation.  I'll let the test finish in case it reveals something useful to you, but this will not be how I use it going forward...
+
+I am unable to attach `testWithMappedDriveHomeDirConsoleOutput.txt` to this post.  1 out of 84 tests failed.  Here is the only case sensitive occurrence of FAIL in the console output, with some lines of context.
+
+    OK
+        info:                                             Detected a filesystem without fifo support.
+      Disabling ssh connection caching.
+      Detected a crippled filesystem.
+      Enabling direct mode.
+    git-annex: Data.BloomFilter.Util.suggestSizing: capacity too large to represent
+    FAIL
+          Exception: user error (git-annex ["info","--json"] exited 1)
+        version:                                          Detected a filesystem without fifo support.
+      Disabling ssh connection caching.
+      Detected a crippled filesystem.
+      Enabling direct mode.
+    git-annex version: 5.20140908-g378fbb1
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
+
+## test results with local NTFS `$HOME`
+
+...The console output is scrolling by much more quickly.
+
+2 out of 84 tests failed.
+
+        prop_past_sane:                                 OK
+          +++ OK, passed 1000 tests.
+        prop_duration_roundtrips:                       OK
+          +++ OK, passed 1000 tests.
+        prop_metadata_sane:                             OK
+          +++ OK, passed 1000 tests.
+        prop_metadata_serialize:                        OK
+          +++ OK, passed 1000 tests.
+        prop_branchView_legal:                          OK
+          +++ OK, passed 1000 tests.
+        prop_view_roundtrips:                           OK
+          +++I nOiKt,  Tpeasstsse
+    d  1 0i0n0i tt:e sts.
+        prop_viewedFile_rountrips:                      FAIL
+          *** Failed! Falsifiable (after 51 tests and 1 shrink):
+          "a:"
+          Use --quickcheck-replay '50 592211036 1831676953' to reproduce.
+      Unit Tests
+        add sha1dup:                                    init test repo
+      Detected a filesystem without fifo support.
+    
+      Disabling ssh connection caching.
+
+and
+
+    OK
+        info:                                             Detected a filesystem without fifo support.
+      Disabling ssh connection caching.
+      Detected a crippled filesystem.
+      Enabling direct mode.
+    git-annex: Data.BloomFilter.Util.suggestSizing: capacity too large to represent
+    FAIL
+          Exception: user error (git-annex ["info","--json"] exited 1)
+        version:                                          Detected a filesystem without fifo support.
+      Disabling ssh connection caching.
+      Detected a crippled filesystem.
+      Enabling direct mode.
+    git-annex version: 5.20140908-g378fbb1
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
+
+...Note the corruption.  I think this happens when I drag the scroll bar while console output is being emitted.  (msysgit's problem?)  I would presume and hope that this is a "display only" issue. UPDATE: see section Corruption below.
+
+# .vbs failure
+
+I copied the `git-annex.lnk` out of my admin user's start menu onto my desktop and double clicked it.  `wscript.exe` got stuck in a loop where new copies were being spawned over and over again (and old copies dieing at the same rate).
+
+I think I know why.  `git-annex.exe` isn't on the path... but `git-annex.lnk` is in the CWD (Desktop in this case).  Yeah, that is the problem.  The vbs attempts to run "git-annex webapp", and this .lnk points to a valid "executable": `git-annex-webapp.vbs`...  So it just calls itself with an argument over and over again.
+
+Workaround: invoke `git annex webapp` from the normal git bash console.
+
+# Corruption?
+
+In some section above I speculated that the "jittery" corruption I was seeing in my console was a "display only" problem caused by scrolling around while new characters were being printed to the console.  Now, I don't think so.
+
+The corruption can be seen in the Log in the webapp.  Here's an example from the top of the log:
+
+    [2014-09-08 13:37:45 Central Daylight Time] main: starting assistant version 5.20140908-g378fbb1
+    Launching web browser on file://d:\annex\.git\annex\webapp.html
+    [2014-09-08 13:37:45 Central Daylight Time] Cronner: You should enable consistency checking to protect your data. 
+    (scanning...) [2014-09-08 13:37:45 Central Daylight Time] Watcher: Performing startup scan
+    (started...) rreerrcceevvcc::vv  ::ff  aaffiiaalliieellddee  dd((  NN((ooNN  ooee  rreerrrroorrrroo))rr
+    
+    ))
+
+I have no clue about this!  (Well...  "I think it's trying to communicate!") 
+
+# Conclusion
+
+I hope this information is helpful.  I've enabled the 'email comments to me' option on this post and I'd be happy to perform further tests upon request.
+
+Cheers!
diff --git a/doc/forum/Windows_installation_notes/comment_1_54c253ab61fea4f5aaefa04bb078c7b0._comment b/doc/forum/Windows_installation_notes/comment_1_54c253ab61fea4f5aaefa04bb078c7b0._comment
new file mode 100644
index 0000000000..7b26547a09
--- /dev/null
+++ b/doc/forum/Windows_installation_notes/comment_1_54c253ab61fea4f5aaefa04bb078c7b0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T18:26:30Z"
+ content="""
+Not following the instructions to have git put itself into the path seems
+like a sure-fire way to shoot yourself in the foot.
+
+The loop problem is being discussed at
+<http://git-annex.branchable.com/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/>
+perhaps you'll be able to answer my questions about it there?
+"""]]
diff --git a/doc/forum/Windows_installation_notes/comment_2_c8c2744e30f2950d9830936d2bd51617._comment b/doc/forum/Windows_installation_notes/comment_2_c8c2744e30f2950d9830936d2bd51617._comment
new file mode 100644
index 0000000000..cab6b1dfd8
--- /dev/null
+++ b/doc/forum/Windows_installation_notes/comment_2_c8c2744e30f2950d9830936d2bd51617._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQOUUx4LVAk6EnstSLvdv7gZc0NsRlHXw"
+ nickname="Dave"
+ subject="comment 2"
+ date="2015-04-09T20:37:51Z"
+ content="""
+Sorry, joey, I haven't played with git annex on windows since my original post.
+
+I only have one new piece of information: some git annex related auto-start entry was added to the user profile of the account I used to perform the installation.  I noticed this when I logged in interactively as that user...
+
+See what I'm saying?  I have DOMAIN\dave.loyall and WORKSTATION\local.admin.  I have to use the latter to carry out installation, via \"Run as...\", but I need stuff to be installed into DOMAIN\dave.loyall's profile or the AllUsers profile (or whatever it is called).
+
+Meanwhile, more and more of my daily work is carried out in my GNU/Linux virtual machines.  I don't personally want/need anyone to prioritize windows-only deficiencies.
+"""]]
diff --git a/doc/forum/Windows_support.mdwn b/doc/forum/Windows_support.mdwn
new file mode 100644
index 0000000000..0e9e8dcb6e
--- /dev/null
+++ b/doc/forum/Windows_support.mdwn
@@ -0,0 +1,6 @@
+Hi,
+
+Do you have any news about Windows support?
+Is this something you're currently working on?
+
+Thanks!
diff --git a/doc/forum/Windows_support/comment_1_23fa9aa3b00940a1c1b3876c35eef019._comment b/doc/forum/Windows_support/comment_1_23fa9aa3b00940a1c1b3876c35eef019._comment
new file mode 100644
index 0000000000..95323ff997
--- /dev/null
+++ b/doc/forum/Windows_support/comment_1_23fa9aa3b00940a1c1b3876c35eef019._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-03-12T06:43:02Z"
+ content="""
+[[todo/windows_support]] has everything I know about making a windows port. This badly needs someone who understand Windows to dive into it. The question of how to create a symbolic link (or the relevant Windows equivilant) from haskell on Windows
+is a good starting point..
+"""]]
diff --git a/doc/forum/Windows_usage_instructions.mdwn b/doc/forum/Windows_usage_instructions.mdwn
new file mode 100644
index 0000000000..0b7b946251
--- /dev/null
+++ b/doc/forum/Windows_usage_instructions.mdwn
@@ -0,0 +1,25 @@
+Having a spot of bother in setting up for windows usage.
+
+I'm attempting to have a windows box syncing to a server (over ssh) and a linux box also syncing against that*
+
+So, on each machine I do
+
+ git init
+ git annex init
+
+
+On the windows and linux desktops I then do a 
+ 
+ git remote add server serverdetails.
+
+Now the problem is that if I don't add files to the repos on the machines, they won't sync as there is no branch checked out; and if I do then the first one is fine but the second will fail as it doesn't allow fast-forwards. What am I doing wrong? I've tried making the server repo bare / not bare.
+
+I'm using the latest nightly windows build, and a build from git from today (29d5bb94b4512cfe3072c9ff840cb0ce9f2af744)
+
+
+
+
+
+
+
+*Actually I'm trying to do something a little more complex than that, but this is the simplest version I can come up with.
diff --git a/doc/forum/Windows_usage_instructions/comment_1_d43dbd9406da3b9747b147715eca94ac._comment b/doc/forum/Windows_usage_instructions/comment_1_d43dbd9406da3b9747b147715eca94ac._comment
new file mode 100644
index 0000000000..6162b9540e
--- /dev/null
+++ b/doc/forum/Windows_usage_instructions/comment_1_d43dbd9406da3b9747b147715eca94ac._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmhfodZquCI_EEl-f3h7HkROTszlsQL6yA"
+ nickname="Joe"
+ subject="comment 1"
+ date="2013-06-16T11:29:36Z"
+ content="""
+This may be related to [this](http://git-annex.branchable.com/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/#comment-a023dca06c2bcb9636d8a332f8e95ae4)
+"""]]
diff --git a/doc/forum/Wishlist__58___Bittorrent-like_transfers.mdwn b/doc/forum/Wishlist__58___Bittorrent-like_transfers.mdwn
new file mode 100644
index 0000000000..7ec6632169
--- /dev/null
+++ b/doc/forum/Wishlist__58___Bittorrent-like_transfers.mdwn
@@ -0,0 +1,5 @@
+**EDIT: Mistakenly posted this thread in the forum.  I created a new post in [[todo|todo/Bittorrent-like_features]]
+
+Do you think it would be possible to have bittorrent-like transfers between remotes, so that no one remote gets pegged too hard with transfers? It would be great if you distribute your files between multiple bandwidth-capped remotes, and want fast down speed.  Obviously, this isn't a simple task, but the protocol is already there, it just needs to be adapted for the purpose (and re-written in Haskell...).  Maybe some day in the future after the more important stuff gets taken care of?  It could be an enticing stretch goal.
+
+PS: still working on getting BTC, will be donating soon!
diff --git a/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_1_13544d54fb0418af4ca9200cdb045d91._comment b/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_1_13544d54fb0418af4ca9200cdb045d91._comment
new file mode 100644
index 0000000000..73295478f9
--- /dev/null
+++ b/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_1_13544d54fb0418af4ca9200cdb045d91._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://a-or-b.myopenid.com/"
+ ip="203.45.2.230"
+ subject="comment 1"
+ date="2013-07-19T02:33:36Z"
+ content="""
+I agree.  I mentioned it briefly here:
+
+[[http://git-annex.branchable.com/design/assistant/polls/what_is_preventing_me_from_using_git-annex_assistant/#comment-5a5d46967b826f602c423d7f72ac6f5e]]
+
+
+I did *briefly* look into torrents and the like, but couldn't work out a way to lock it down so only authorized users could use either the tracker or connect to pull the data down...
+
+The security aspect is the kicker in my mind.
+"""]]
diff --git a/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_2_9a7dad35bf80c684ad97892420d7370c._comment b/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_2_9a7dad35bf80c684ad97892420d7370c._comment
new file mode 100644
index 0000000000..affd07efd9
--- /dev/null
+++ b/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_2_9a7dad35bf80c684ad97892420d7370c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="GLITTAH"
+ ip="37.130.227.133"
+ subject="comment 2"
+ date="2013-07-19T07:38:47Z"
+ content="""
+Okay I've got some ideas, but they need refining.  I should be posting more tomorrow.
+
+One thing I thought of though, there could be two types of torrent support:
+
+1.  You use a torrent file or magnet link as a special remote URL.  This remote is read-only, naturally, and you'd only be able to leech (and seed, I suppose) the file in the torrent.  Neat feature maybe.  I wasn't previously thinking of this.
+
+2. This isn't really bittorrent, just inspired by it.  You use a bittorrent-type protocol to transfer between your private remotes.  You could download from multiple remotes at once to get a file (like leeching, without a tracker, just pre-defined peers...aka remotes), or you could superseed to remotes to push a file, and have the remotes then share the parts of the file amongst themselves to each get a complete copy.  Remote groups could possibly be built on, or special groups could be coded in to define the swarm.  You update (add/remove) the swarm members locally, and push the changes to each of the old swarm members so they can add/remove other remotes (or themselves) from the swarm.  Possibly, you could just push the updated swarm list to one remote already in the swarm, it adopts the new list, and shares it with the rest of the swarm.  Each remote does the same.  Maybe the swarm list should be GPG-signed and verified before adopted and passed forward?
+
+The more I think about it, the more awesome I think it could be, but holy shit it would be a LOT of work.
+"""]]
diff --git a/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_3_e5de748bc5da12a4a01e08cde2407dd1._comment b/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_3_e5de748bc5da12a4a01e08cde2407dd1._comment
new file mode 100644
index 0000000000..ba8da25f03
--- /dev/null
+++ b/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_3_e5de748bc5da12a4a01e08cde2407dd1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="comment 3"
+ date="2013-07-19T07:50:09Z"
+ content="""
+Personally i think the easiest implementation to make would be smart transfers.
+
+You have a repo on your laptop, and a repo at work. And you have(say) 5 special remotes in between them that they need to use to transfer data.
+
+The laptop could upload 5 different files to those repositories. Wouldn't quite be bittorent transfer(not even close). But it would probably be much simpler to implement. And when syncing a lot of files(instead of just one really big one) the speed gain should really be about the same as if all the special remotes used some kind of bittorent thing.
+
+Just a thought.
+"""]]
diff --git a/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_4_e51530178f1e034c0fdd5c9aa9945567._comment b/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_4_e51530178f1e034c0fdd5c9aa9945567._comment
new file mode 100644
index 0000000000..d3e0d33145
--- /dev/null
+++ b/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_4_e51530178f1e034c0fdd5c9aa9945567._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="comment 4"
+ date="2013-07-19T07:51:39Z"
+ content="""
+Of course all files should be uploaded to all remote(to match with numcopies). but the initial push could be spread out over all existing remotes, to facility faster initial download/transfer.
+"""]]
diff --git a/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_5_81ea9c129d8c02097f09ef8c68f1bb11._comment b/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_5_81ea9c129d8c02097f09ef8c68f1bb11._comment
new file mode 100644
index 0000000000..1ef2b25ac3
--- /dev/null
+++ b/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_5_81ea9c129d8c02097f09ef8c68f1bb11._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="GLITTAH"
+ ip="37.130.227.133"
+ subject="comment 5"
+ date="2013-07-19T21:23:35Z"
+ content="""
+Disclaimer: I'm thinking out loud of what could make git-annex even more awesome.  I don't expect this to be implemented any time soon.  Please pardon any dumbassery.
+
+Much easier to implement, but having your remotes (optionally!) act like a swarm would be an awesome feature to have because you bring in a lot of new features that optimize storage, bandwidth, and overall traffic usage.  This would be made a lot easier if parts of it were implemented in small steps that added a nifty feature.  The best part is, each of these could be implemented by themselves, and they're all features that would be really useful.
+
+Step 1. Concurrent downloads of a file from remotes.
+
+This would make sense to have, it saves upload traffic on your remotes, and you also get faster DL speeds on the receiving end.
+
+
+Step 2. Implementing part of the super-seeding capabilities.
+
+You upload pieces of a file to different remotes from your laptop, and on your desktop you can download all those pieces and put them together again to get a complete file.  If you *really* wanted to get fancy, you could build in redundancy (ala RAID) so if a remote or two gets lost, you don't lose the entire file.  This would be a very efficient use of storage if you have a bunch of free cloud storage accounts (~1GB each) and some big files you want to back up.
+
+
+Step 3. Setting it up so that those remotes could talk to one another and share those pieces.  
+
+This is where it gets more like bittorrent.  Useful because you upload one copy and in a few hours, have say, 5 complete copies spread across your remotes.  You could add or remove remotes from a swarm locally, and push those changes to those remotes, which then adapt themselves to suit the new rules and share those with other remotes in the swarm (rules should be GPG-signed as a safety precaution).  Also, if/when deltas get implemented, you could push that delta to the swarm and have all the remotes adopt it.  This is cooler than regular bittorrent because the shared file can be updated.  As a safety precaution, the delta could be GPG signed so a corrupt file doesn't contaminate the entire swarm.  Each remote could have bandwidth/storage limits set in a dotfile.
+
+This is a high-level idea of how it might work, and it's also a HUGE set of features to add, but if implemented, you'd be saving a ton of resources, adding new use cases, and making git-annex more flexible.
+
+"""]]
diff --git a/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_6_3b5798414f89686526da3dfa72c0c4f2._comment b/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_6_3b5798414f89686526da3dfa72c0c4f2._comment
new file mode 100644
index 0000000000..7a027c909c
--- /dev/null
+++ b/doc/forum/Wishlist__58___Bittorrent-like_transfers/comment_6_3b5798414f89686526da3dfa72c0c4f2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="GLITTAH"
+ ip="37.130.227.133"
+ subject="comment 6"
+ date="2013-07-19T21:28:58Z"
+ content="""
+Obviously, Step 3 would only work on remotes that you have control of processes on, but if given login credentials to cloud storage remotes (potentially dangerous!) they could read/write to something like dropbox or rsync.
+
+Another thing, this would be completely trackerless.  You just use remote groups (or create swarm definitions) and share those with your remotes.  It's completely decentralized!
+"""]]
diff --git a/doc/forum/Wishlist__58___Don__39__t_make_files_readonly.mdwn b/doc/forum/Wishlist__58___Don__39__t_make_files_readonly.mdwn
new file mode 100644
index 0000000000..4d67f93b1a
--- /dev/null
+++ b/doc/forum/Wishlist__58___Don__39__t_make_files_readonly.mdwn
@@ -0,0 +1,3 @@
+Maybe this explained somewhere else, but what is the purpose of marking files readonly. To me this is an annoyance that doesn't make sense. I want to be able to change my files, having to go through an unlock step, to do that seems like unnecessary work. Interestingly, Microsoft's Team Foundation Server source control does the same thing and I don't like it there either.
+
+In addition why replace files with symlinks? Why not just leave the real files in place, or do the reverse and put the symlink to the file in the repository.
diff --git a/doc/forum/Wishlist__58___Don__39__t_make_files_readonly/comment_1_7148527961e2d27793810966588c8d35._comment b/doc/forum/Wishlist__58___Don__39__t_make_files_readonly/comment_1_7148527961e2d27793810966588c8d35._comment
new file mode 100644
index 0000000000..b7a6f55f47
--- /dev/null
+++ b/doc/forum/Wishlist__58___Don__39__t_make_files_readonly/comment_1_7148527961e2d27793810966588c8d35._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmL8pteP2jbYJUn1M3CbeLDvz2SWAA1wtg"
+ nickname="Kristian"
+ subject="comment 1"
+ date="2012-11-22T23:38:33Z"
+ content="""
+By using symlinks gits problems with big files goes away. You simply can't put 600 GB in a git repo - that's the way I use git-annex. Also having files read only by default eliminates the need to store two copies of all files in one form or another.
+
+
+"""]]
diff --git a/doc/forum/Wishlist__58___Is_it_possible_to___34__unlock__34___files_without_copying_the_file_data__63__.mdwn b/doc/forum/Wishlist__58___Is_it_possible_to___34__unlock__34___files_without_copying_the_file_data__63__.mdwn
new file mode 100644
index 0000000000..1a7930fec4
--- /dev/null
+++ b/doc/forum/Wishlist__58___Is_it_possible_to___34__unlock__34___files_without_copying_the_file_data__63__.mdwn
@@ -0,0 +1,6 @@
+I have a DLink Boxee media player and it can not play content from symbolic links, it needs to access regular media files. Unfortunately unlocking/locking is quite slow for such a large amount of data due to the required data copying, but it should not even be needed since I do not need write access to any file to watch the movie or to play the song.
+
+Is it currently possible or would it be possible to add a commands like "unlock" which would not copy the file data but simply move files out from the data store into the tree while still keeping the files read only? A corresponding "lock" command would also be needed to restore the normal symbolic link tree structure.
+
+Update:
+I tried the rsync special remote http://git-annex.branchable.com/special_remotes/rsync/ and it works but the file structure created reflects the data store not the view given by the symbolic links.
diff --git a/doc/forum/Wishlist__58___Is_it_possible_to___34__unlock__34___files_without_copying_the_file_data__63__/comment_1_1cf4ab29dfa2cff59b86305fc0018251._comment b/doc/forum/Wishlist__58___Is_it_possible_to___34__unlock__34___files_without_copying_the_file_data__63__/comment_1_1cf4ab29dfa2cff59b86305fc0018251._comment
new file mode 100644
index 0000000000..3ab518714d
--- /dev/null
+++ b/doc/forum/Wishlist__58___Is_it_possible_to___34__unlock__34___files_without_copying_the_file_data__63__/comment_1_1cf4ab29dfa2cff59b86305fc0018251._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-07-07T15:27:28Z"
+ content="""
+The rsync or directory special remotes would work if the media player uses metadata in the files, rather than directory locations.
+
+Beyond that there is the [[todo/smudge]] idea, which is hoped to be supported sometime.
+"""]]
diff --git a/doc/forum/Wishlist__58___Is_it_possible_to___34__unlock__34___files_without_copying_the_file_data__63__/comment_2_f5ebb7f43dcef861ecc13373fb1e263f._comment b/doc/forum/Wishlist__58___Is_it_possible_to___34__unlock__34___files_without_copying_the_file_data__63__/comment_2_f5ebb7f43dcef861ecc13373fb1e263f._comment
new file mode 100644
index 0000000000..9601003798
--- /dev/null
+++ b/doc/forum/Wishlist__58___Is_it_possible_to___34__unlock__34___files_without_copying_the_file_data__63__/comment_2_f5ebb7f43dcef861ecc13373fb1e263f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmL8pteP2jbYJUn1M3CbeLDvz2SWAA1wtg"
+ nickname="Kristian"
+ subject="Solution"
+ date="2011-07-31T15:24:25Z"
+ content="""
+Yes, it can read id3-tags and guess titles from movie filenames but it sometimes gets confused by the filename metadata provided by the WORM-backend.
+
+I think I have a good enough solution to this problem. It's not efficient when it comes to renames but handles adding and deletion just fine
+
+    rsync -vaL --delete source dest
+
+The -L flag looks at symbolic links and copies the actual data they are pointing to. Of course \"source\" must have all data locally for this to work.
+
+"""]]
diff --git a/doc/forum/Wishlist__58___Ways_of_selecting_files_based_on_meta-information.mdwn b/doc/forum/Wishlist__58___Ways_of_selecting_files_based_on_meta-information.mdwn
new file mode 100644
index 0000000000..1de06f7cda
--- /dev/null
+++ b/doc/forum/Wishlist__58___Ways_of_selecting_files_based_on_meta-information.mdwn
@@ -0,0 +1,15 @@
+It would be extremely useful to have some additional ways to select files (for git annex copy/move/get and maybe others) based on the meta-information available to git-annex, rather than just by file or directory name.
+
+An example of what I'd like to do is this:
+
+    host1$ git annex copy --to usb-drive --missing-on host2
+
+This would check location tracking information and copy each file from host1's annex which is not present on host2 onto the usb-drive annex -- i.e. it's what I want when I need to do a sneakernet synchronisation of host1 and host2 (for backup purposes, for example). Note that of course I could copy --to host2, assuming network connectivity, but that would take a long time.
+
+There's probably other selectors that we can imagine; an obvious one could be --present-on <annex> -- useful for judiciously dropping only those files that you have easily available in a local annex (as you may want to keep files that are hard to make available even if --numcopies would nominally be satisfied).
+
+Other similar ideas for file content selectors:
+
+ * Files that have less than n, exactly n or more than n copies -- for when you need to satisfy your --numcopies policy over sneakernet.
+ * Files that are present (or not present) on some trusted annex -- for making sure you have trusted copies of everything.
+ * Boolean combinations of these filters -- "git annex drop --present-on lanserver1 --or --present-on lanserver2" or similar syntax, although obviously doing this in full generality may be quite fiddly.
diff --git a/doc/forum/Wishlist__58___Ways_of_selecting_files_based_on_meta-information/comment_1_818f38aa988177d3a9415055e084f0fb._comment b/doc/forum/Wishlist__58___Ways_of_selecting_files_based_on_meta-information/comment_1_818f38aa988177d3a9415055e084f0fb._comment
new file mode 100644
index 0000000000..11b44b8094
--- /dev/null
+++ b/doc/forum/Wishlist__58___Ways_of_selecting_files_based_on_meta-information/comment_1_818f38aa988177d3a9415055e084f0fb._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="filtering based on git-commits"
+ date="2011-06-23T13:56:35Z"
+ content="""
+additional filter criteria could come from the git history:
+
+* `git annex get --touched-in HEAD~5..` to fetch what has recently been worked on
+* `git annex get --touched-by chrysn --touched-in version-1.0..HEAD` to fetch what i've been workin on recently (based on regexp or substring match in author; git experts could probably craft much more meaningful expressions)
+
+these options could also apply to `git annex find` -- actually, looking at the normal file system tools for such tasks, that might even be sufficient (think `git annex find --numcopies-gt 3 --present-on lanserver1 --drop` like `find -iname '*foo*' -delete`
+
+(i was about to open a new forum discussion for commit-based getting, but this is close enough to be usefully joint in a discussion)
+"""]]
diff --git a/doc/forum/Wishlist__58___Ways_of_selecting_files_based_on_meta-information/comment_2_97e2ed48bd552d02918c4f98f963e6e1._comment b/doc/forum/Wishlist__58___Ways_of_selecting_files_based_on_meta-information/comment_2_97e2ed48bd552d02918c4f98f963e6e1._comment
new file mode 100644
index 0000000000..787cf8f5d7
--- /dev/null
+++ b/doc/forum/Wishlist__58___Ways_of_selecting_files_based_on_meta-information/comment_2_97e2ed48bd552d02918c4f98f963e6e1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-09-19T18:46:35Z"
+ content="""
+This is now almost completely implemented. See [[walkthrough/powerful_file_matching]].
+
+"""]]
diff --git a/doc/forum/Wishlist__58___automatic_reinject.mdwn b/doc/forum/Wishlist__58___automatic_reinject.mdwn
new file mode 100644
index 0000000000..f975c75214
--- /dev/null
+++ b/doc/forum/Wishlist__58___automatic_reinject.mdwn
@@ -0,0 +1,14 @@
+I think it would be useful to supplement the `reinject` command with an automatic
+mode which calculates the checksum of the source file and injects the file if it
+is known to the repository (without the need to provide a destination filename).
+In addition, this could be done recursively if the user provides a directory to
+inject. All this can probably be done already with some plumbing, but a simple
+`reinject --auto` (or `scour`, or `scavenge`, if you like) would be a nice addition.
+Of course this would only work for the checksum backends.
+
+Example use cases would be:
+
+* Recovering data from lost+found easily
+* Making use of old (pre-git-annex) archival volumes with useful files
+  scattered among non-useful files
+* Sneaker-netting files between disconnected git-annex repositories
diff --git a/doc/forum/Wishlist__58___automatic_reinject/comment_1_6bf093f228353130e80e7a30bcf0075d._comment b/doc/forum/Wishlist__58___automatic_reinject/comment_1_6bf093f228353130e80e7a30bcf0075d._comment
new file mode 100644
index 0000000000..3b13217790
--- /dev/null
+++ b/doc/forum/Wishlist__58___automatic_reinject/comment_1_6bf093f228353130e80e7a30bcf0075d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="try the --known argument"
+ date="2018-10-25T17:30:29Z"
+ content="""
+This works now, with the reinject `--known` argument.
+"""]]
diff --git a/doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files.mdwn b/doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files.mdwn
new file mode 100644
index 0000000000..7bdd93654f
--- /dev/null
+++ b/doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files.mdwn
@@ -0,0 +1,10 @@
+I'm not sure if this _feature_ exists already wrapped or provided as a recipe for users or not yet. But it would be nice to be able to do a
+
+    git annex du [PATH]
+
+Such that the output that git annex would return is the total disk used locally in the PATH and the theoretical disk used by the PATH if it was fully populated locally. e.g.
+
+    $ git annex du FSL0001_ANALYSIS
+    $ Local: 1000kb, Annex: 2000kb
+
+or something along the lines of that?
diff --git a/doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files/comment_1_7abb1155081a23ce4829ee69b2064541._comment b/doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files/comment_1_7abb1155081a23ce4829ee69b2064541._comment
new file mode 100644
index 0000000000..bff5b2ea7e
--- /dev/null
+++ b/doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files/comment_1_7abb1155081a23ce4829ee69b2064541._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.25"
+ subject="comment 1"
+ date="2012-06-27T12:36:08Z"
+ content="""
+Use `du -L` for the disk space used locally. The other number is not currently available, but it would be nice to have. I also sometimes would like to have data on which backends are used how much, so making this `git annex status --subdir` is tempting. Unfortunatly, it's current implementation scans `.git/annex/objects`
+and not the disk tree (better for accurate numbers due to copies), so it would not be a very easy thing to add. Not massively hard, but not something I can pound out before I start work today..
+"""]]
diff --git a/doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files/comment_2_b4c6ebada7526263e04c70eac312fda9._comment b/doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files/comment_2_b4c6ebada7526263e04c70eac312fda9._comment
new file mode 100644
index 0000000000..551c685d4e
--- /dev/null
+++ b/doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files/comment_2_b4c6ebada7526263e04c70eac312fda9._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 2"
+ date="2012-06-27T12:45:42Z"
+ content="""
+I have a hacked up version of sharebox that does this.. I need to fix it up and push it to github..
+
+the short of it is that you can do
+
+    def calculate_size(path):
+        annexfile = os.path.basename(os.readlink(path))
+        #SHA256-s2007550713--....
+        size = annexfile.split(\"-\")[1]
+        return int(size[1:])
+
+to get the size of files.. a 'git-annex du' should be pretty straightforward...
+"""]]
diff --git a/doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files/comment_3_ded71b270b94617a8ebb3a713d46a274._comment b/doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files/comment_3_ded71b270b94617a8ebb3a713d46a274._comment
new file mode 100644
index 0000000000..ddc9ae1475
--- /dev/null
+++ b/doc/forum/Wishlist__58___getting_the_disk_used_by_a_subtree_of_files/comment_3_ded71b270b94617a8ebb3a713d46a274._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-03-11T05:27:38Z"
+ content="""
+You can now use \"git annex status .\"
+
+Example:
+
+<pre>
+git annex status roms
+directory: roms
+local annex keys: 1
+local annex size: 248 megabytes
+known annex keys: 277
+known annex size: 12 gigabytes
+</pre>
+"""]]
diff --git a/doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__.mdwn b/doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__.mdwn
new file mode 100644
index 0000000000..c3f915e7dd
--- /dev/null
+++ b/doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__.mdwn
@@ -0,0 +1 @@
+Logging to file would be nice when running git-annex as a daemon so when something fails or when certain events happens one can look at the logs to see what has failed, unless I'm missing something this probably should be on the wishlist or roadmap.
diff --git a/doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__/comment_1_42aa2b61b880f4048d874210212aa63b._comment b/doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__/comment_1_42aa2b61b880f4048d874210212aa63b._comment
new file mode 100644
index 0000000000..c0746a5a7c
--- /dev/null
+++ b/doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__/comment_1_42aa2b61b880f4048d874210212aa63b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.60"
+ subject="comment 1"
+ date="2012-06-23T14:30:22Z"
+ content="""
+The logging format could be improved, but the daemon already logs to .git/annex/daemon.log. It also automatically rotates the log file.
+"""]]
diff --git a/doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__/comment_2_3e201039fa0e611554171ee30e69a414._comment b/doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__/comment_2_3e201039fa0e611554171ee30e69a414._comment
new file mode 100644
index 0000000000..b1a76ce2d3
--- /dev/null
+++ b/doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__/comment_2_3e201039fa0e611554171ee30e69a414._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2012-06-23T08:00:12Z"
+ content="""
+actually, scratch that, i found it. it was in _.git/annex/daemon.log_ along with the other bits and pieces
+"""]]
diff --git a/doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__/comment_3_d1074724c44f3296cb438b2d526d8728._comment b/doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__/comment_3_d1074724c44f3296cb438b2d526d8728._comment
new file mode 100644
index 0000000000..eb18628290
--- /dev/null
+++ b/doc/forum/Wishlist__58___logging_to_file_when_running_as_a_daemon___40__for_the_assistant__41__/comment_3_d1074724c44f3296cb438b2d526d8728._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2012-07-03T14:48:16Z"
+ content="""
+Adding a date and timestamp would be a nice start to improving things.
+"""]]
diff --git a/doc/forum/Wishlist__58___mark_remotes_offline.mdwn b/doc/forum/Wishlist__58___mark_remotes_offline.mdwn
new file mode 100644
index 0000000000..046c62210f
--- /dev/null
+++ b/doc/forum/Wishlist__58___mark_remotes_offline.mdwn
@@ -0,0 +1,12 @@
+I have several remotes which are not always accessible. For example they can
+be on hosts only accessible by LAN or on a portable hard drive which is not
+plugged in. When running sync these remotes are checked as well, leading to
+unnecessary error messages and possibly git-annex waiting for a few minutes
+on each remote for a timeout.
+
+In this situation it would be useful to mark some remotes as offline
+(`git annex offline <remotename>`), so that git-annex would not even attempt
+to contact them. Then, I could configure my system to automatically, for example,
+mark a portable hard disk remote online when plugging it in, and offline when
+unplugging it, and similarly marking remotes offline and online depending on
+whether I have an internet connection or a connection to a specific network.
diff --git a/doc/forum/Wishlist__58___mark_remotes_offline/comment_1_9e3901f0123abb66034cce95cc5a941a._comment b/doc/forum/Wishlist__58___mark_remotes_offline/comment_1_9e3901f0123abb66034cce95cc5a941a._comment
new file mode 100644
index 0000000000..c24a786c96
--- /dev/null
+++ b/doc/forum/Wishlist__58___mark_remotes_offline/comment_1_9e3901f0123abb66034cce95cc5a941a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 1"
+ date="2012-07-06T13:04:07Z"
+ content="""
+You can already do this:
+
+    git config remote.foo.annex-ignore true
+
+There's no need to do anything for portable drives that are sometimes mounted and sometimes not -- git-annex will automatically avoid using repositories in directories that do not currently exist.
+
+I thought git-annex also had a way to run a command and use its exit status to control whether a repo was
+ignored or not, but it seems I never actually implemented that. It might be worth adding, although the command would necessarily run whenever git-annex is transferring data around.
+"""]]
diff --git a/doc/forum/Wishlist__58___mark_remotes_offline/comment_2_d10e3d90cf421ae425e64ab266ea811b._comment b/doc/forum/Wishlist__58___mark_remotes_offline/comment_2_d10e3d90cf421ae425e64ab266ea811b._comment
new file mode 100644
index 0000000000..e14cfa8225
--- /dev/null
+++ b/doc/forum/Wishlist__58___mark_remotes_offline/comment_2_d10e3d90cf421ae425e64ab266ea811b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawncBlzaDI248OZGjKQMXrLVQIx4XrZrzFo"
+ nickname="Perttu"
+ subject="comment 2"
+ date="2012-07-07T17:45:43Z"
+ content="""
+Ah, I didn't read the man page carefully enough. My apologies.
+
+Setting the ignore status based on an exit status would be
+even better, since this avoids re-writing a new config file for
+each repository each time I enter or exit my LAN.
+"""]]
diff --git a/doc/forum/Wishlist__58___options_for_syncing_meta-data_and_data.mdwn b/doc/forum/Wishlist__58___options_for_syncing_meta-data_and_data.mdwn
new file mode 100644
index 0000000000..d1df6628ea
--- /dev/null
+++ b/doc/forum/Wishlist__58___options_for_syncing_meta-data_and_data.mdwn
@@ -0,0 +1,13 @@
+Since _transfer queueing_  and syncing of data works now in the assistant branch (been playing with it), there are times when I really don't want to sync the data, I would like to just sync meta-data and manually do a _get_ on files that I would want or selectively sync data in a subtree.
+
+It would be nice to have the syncing/watch feature to have the option of syncing only *meta-data* or *meta-data and data*, I think this sort of option was already planned? It would also be nice to be able to automatically sync data for only a subtree.
+
+My use case is, I have a big stash of files somewhere at home or work, and I want to keep what I am actually using on my laptop and be able to selectively just take a subtree or a set of subtree's of files. I would not always want to suck down all the data but still have the functionally to add files and push them upstream and sync meta-data.
+
+that is...
+
+> * Site A: big master annex in a server room with lots of disk (or machines), watches a directory and syncs both data and meta-data, it should always try and pull data from all it's child repos. That way I will always have a master copy of my data somewhere, it would be even nicer if I could have clones of the annex, where each annex is on a different machine which is configured to only sync a subtree of files so I can distribute my annex across different systems and disks.
+>   * Site A: machine A: syncs Folder A
+>   * Site A: machine B: syncs Folder B
+>   * and so on with selectively syncing sites and directories
+> * Laptop: has a clone of the annex, and watches a directory, syncs meta-data as usual and only uploads files to a remote (all or a designated one) but it never downloads files automatically or it should only occur inside a selected subtree.
diff --git a/doc/forum/Wishlist__58___rename_files__47__dirs_w__47___special_characters_if_filesystem_is_FAT.mdwn b/doc/forum/Wishlist__58___rename_files__47__dirs_w__47___special_characters_if_filesystem_is_FAT.mdwn
new file mode 100644
index 0000000000..847ff01bd5
--- /dev/null
+++ b/doc/forum/Wishlist__58___rename_files__47__dirs_w__47___special_characters_if_filesystem_is_FAT.mdwn
@@ -0,0 +1,5 @@
+Hi Joey,
+    I recently tried cloning a music annex to a microSD card to play on rockbox (FAT only) with my Sansa Clip, but 'git clone' stops the first time it runs into something with a special character in a file or directory, like a colon in an album title.  After this happens, there doesn't seem to be a way to get a full annex file/directory listing for the annex; it only has up to where git failed since FAT can't handle the name.  Is it possible for git-annex to replace special characters in directory/filenames with a space or underscore if it's on a crippled filesystem?  Also, would it be possible to then clone from that annex to a non-crippled FS, preserving the original filenames with special characters?  I've been meaning to ask about this for a while, so I'm a teeny bit fuzzy on the specifics...if you want, I'll reproduce the problem and cough up some more details.
+
+
+PS: I love git-annex!
diff --git a/doc/forum/Wishlist__58___rename_files__47__dirs_w__47___special_characters_if_filesystem_is_FAT/comment_1_5d33bcbd862537f53edd91dcff2b8977._comment b/doc/forum/Wishlist__58___rename_files__47__dirs_w__47___special_characters_if_filesystem_is_FAT/comment_1_5d33bcbd862537f53edd91dcff2b8977._comment
new file mode 100644
index 0000000000..42fad62b9b
--- /dev/null
+++ b/doc/forum/Wishlist__58___rename_files__47__dirs_w__47___special_characters_if_filesystem_is_FAT/comment_1_5d33bcbd862537f53edd91dcff2b8977._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-06T21:13:44Z"
+ content="""
+I think this is a general git question, not specific to git-annex. At the point in time that you run `git clone` on the FAT filesystem, git-annex is not running at all.
+
+You could ask the git community about this. I know that git already has a core.precomposeunicode setting that is used to work around a somewhat similar problem on Mac OS.
+
+What git-annex *does* let you do is set up a [[directory_special_remote|special_remote/directory]] on the FAT filesystem. This way,
+there is no git repository there, and the filenames stored in git are not used at all on FAT. If your media player looks at mp3 metadata to get song titles, etc and doesn't care about the filenames at all, this would be a good option.
+"""]]
diff --git a/doc/forum/Workarounds_for_git-annex.mdwn b/doc/forum/Workarounds_for_git-annex.mdwn
new file mode 100644
index 0000000000..af0e9869d4
--- /dev/null
+++ b/doc/forum/Workarounds_for_git-annex.mdwn
@@ -0,0 +1,8 @@
+Hello Everyone,
+I created a set of scripts to work around some limitations in git-annex (although some of this is out of scope for git-annex ) like managing git repos inside a git-annex repo and (emulating) encryption=shared for gcrypt remotes. This is pretty much tailored to my own use-case, but maybe someone else is interested in this.
+
+You can find the Workarounds alongside a small Guide here:
+https://github.com/Lukey3332/git-annex-workarounds
+
+Regards,
+Lukey
diff --git a/doc/forum/Workflow_for_adding_files.mdwn b/doc/forum/Workflow_for_adding_files.mdwn
new file mode 100644
index 0000000000..cb631543fb
--- /dev/null
+++ b/doc/forum/Workflow_for_adding_files.mdwn
@@ -0,0 +1,32 @@
+What is the correct way to add/modify files such that the changes are synchronized?
+
+Suppose I have a server "server" and a windows client "client" (more after some time); everything direct mode.
+
+I created the repos on the server:
+
+     cd bin
+     git init
+     git annex init server
+     git annex direct
+     git annex add .
+     git annex sync
+
+On the (Windows) client using cygwin:
+
+     git annex clone ssh://me@server:/srv/bin
+     cd bin
+     git annex init client
+
+Then I want to add files on the client:
+
+     git annex add tools
+     git annex sync
+
+At this point I wonder that the data is not copied to the server but only metadata!
+I then used
+
+     git annex sync --content
+
+but then everything from the server is leeched as well (as if I could have called "git annex get .")
+
+What is the intented workflow such that added/modified files on the client always go to the server, modified/new files from the server are always pulled but ONLY if I previously got the file/directory via "get annex get"?
diff --git a/doc/forum/Workflow_for_adding_files/comment_1_a60dae97db827bc641d6256d1f382b5f._comment b/doc/forum/Workflow_for_adding_files/comment_1_a60dae97db827bc641d6256d1f382b5f._comment
new file mode 100644
index 0000000000..9774e69bf7
--- /dev/null
+++ b/doc/forum/Workflow_for_adding_files/comment_1_a60dae97db827bc641d6256d1f382b5f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnJO6OKamxo1HDLwdV-W3KV4GhJ5Qitl9M"
+ nickname="Frederik"
+ subject="comment 1"
+ date="2014-05-15T00:57:23Z"
+ content="""
+Check the description for manual out on [[http://git-annex.branchable.com/preferred_content/standard_groups/]]. I believe that's what you'll need.
+"""]]
diff --git a/doc/forum/Workflow_for_adding_files/comment_2_28dd15ac50f79fb07bacf8b8326c7edc._comment b/doc/forum/Workflow_for_adding_files/comment_2_28dd15ac50f79fb07bacf8b8326c7edc._comment
new file mode 100644
index 0000000000..c11be26673
--- /dev/null
+++ b/doc/forum/Workflow_for_adding_files/comment_2_28dd15ac50f79fb07bacf8b8326c7edc._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9SYh6N-JUMkYkW4aOk55zC3Vr9KonDV4"
+ nickname="Florian"
+ subject="comment 2"
+ date="2014-06-18T07:35:31Z"
+ content="""
+Just to be sure I understood the topic, this would be achieved in putting the repo in the manual transfer group?
+
+manual
+
+This gives you nearly full manual control over what content is stored in the repository. This allows using the assistant without it trying to keep a local copy of every file. Instead, you can manually run git annex get, git annex drop, etc to manage content. Only content that is already present is wanted.
+
+The exception to this manual control is that content that a client repository would not want is not wanted. So, files in archive directories are not wanted once their content has reached an archive repository.
+
+present and ($client)
+
+(Where $client is a copy of the preferred content expression used for clients.)
+<<<
+"""]]
diff --git a/doc/forum/Workflow_for_using_git-annex_only_on_external_drives.mdwn b/doc/forum/Workflow_for_using_git-annex_only_on_external_drives.mdwn
new file mode 100644
index 0000000000..734be10ea1
--- /dev/null
+++ b/doc/forum/Workflow_for_using_git-annex_only_on_external_drives.mdwn
@@ -0,0 +1,8 @@
+I am starting to use annex and feel a bit overwhelmed. I would appreciate guidance on this use case.
+
+1. Content must exist on multiple external drives only. I do not want those files in my internal HDD.
+2. Not all drives will have all files. Probably none will. Drives might be smaller than the full set.
+3. I should always have two copies of each file somewhere (and be warned if not).
+3. Some files already exist in some drives I intend to use annex with in this way. When setting annex in them, I had rather avoid having to transfer in files from another set up drive if those files already exist in the new drive.
+4. Some drives will necessarily be using FAT32.
+5. I will be adding new content over time.
diff --git a/doc/forum/Workflow_for_using_git-annex_only_on_external_drives/comment_1_c3c495efb7cdd242b51cc7fa7719d95f._comment b/doc/forum/Workflow_for_using_git-annex_only_on_external_drives/comment_1_c3c495efb7cdd242b51cc7fa7719d95f._comment
new file mode 100644
index 0000000000..95154d3d5e
--- /dev/null
+++ b/doc/forum/Workflow_for_using_git-annex_only_on_external_drives/comment_1_c3c495efb7cdd242b51cc7fa7719d95f._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="comment 1"
+ date="2017-07-20T17:53:04Z"
+ content="""
+(Another user here.)
+
+I can't take you by the hand but all this seems like regular use of git-annex.
+
+I was overwhelmed at the beginning, followed http://git-annex.branchable.com/walkthrough , visited a number of pages.
+I finally had something that worked.
+
+In some cases you might consider, instead of moving files then using git annex add, using https://git-annex.branchable.com/git-annex-import/ with or without some of the options.
+
+If you have specific problems, ask a more specific question.
+
+Happy journey!
+
+"""]]
diff --git a/doc/forum/Workflow_for_using_git-annex_only_on_external_drives/comment_2_f29471761e95b25e35e4cb09ad89737a._comment b/doc/forum/Workflow_for_using_git-annex_only_on_external_drives/comment_2_f29471761e95b25e35e4cb09ad89737a._comment
new file mode 100644
index 0000000000..6dbe05f3af
--- /dev/null
+++ b/doc/forum/Workflow_for_using_git-annex_only_on_external_drives/comment_2_f29471761e95b25e35e4cb09ad89737a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 2"
+ date="2017-07-21T09:15:40Z"
+ content="""
+1) Check out the source repository group, which will drop files once enough numcopies are available elsewhere
+2) This is pretty much why git-annex exists :)
+3) Set numcopies to 2 and use 'git annex fsck' to find out when there aren't enough copies
+4) You can use 'import' or 'reinject --known' to clean up known content outside of git-annex
+5) git-annex will run on 'crippled' filesystems like FAT32. Would recommend avoiding this if possible though
+6) This is presumed :)
+
+Sorry for brevity, but this should give some direction/keywords.
+"""]]
diff --git a/doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner.mdwn b/doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner.mdwn
new file mode 100644
index 0000000000..85395869e9
--- /dev/null
+++ b/doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner.mdwn
@@ -0,0 +1,22 @@
+Hi all,
+
+the last few days I wrote the first 1200 words of a Git annex book (in German), but I am unsure whether I shall continue. 
+
+I've written two books about non mainstream software, namely about the documentation generator Sphinx and the document converter Pandoc. I am using these programs myself on a daily basis so that I was quite sure to cover most of their features in the books. I even narrowed the scope of the Pandoc book to "book production" as this is what I do with it, leaving out some use cases such as slides or HTML production.
+
+Before I really start writing the book, I would like to get a clear and robust understanding of the program. As you can see, I don't write books about very popular software in order to sell a lot of copies, I write about software I really like. But I would not write about software that isn't used at all. 
+
+So to get a clear understand of Git annex I need a sparring partner who is willing to discuss usecases, viewpoints and the outline of the book. The following questions and problems are blocking my work:
+
+Some time ago I used Git annex to sync my desktop and my laptop. I used the webapp. My experiences were very bad. Git annex had a very bad performance slowing down my computer making it nearly unusable. I had numerous Unicode errors which let to a duplication of files. So I stopped using Git annex and switched to Syncthing, which does the job without any problems. Syncing computers with the webapp obviously is not be the usecase I would like to cover in the book. Today I use Git annex as a feedreader. 
+
+So why do I want to write a book about a software I do not really use? First of all I like the concept. I like the idea to manage big files in one tree while the content of many files is stored in remote archives. So this could be the idea of the book: sustainable management of big files. And after reading https://git-annex.branchable.com/design/iabackup/ I think that this could be the main use case of Git annex. 
+
+When I wrote about Sphinx and Pandoc I talked to people who used the software to a great extent. Sphinx is the the de facto standard to document Python code. So I was able to evaluate the software before I invested half a year of writing a book. I am not able to say whether Git annex is good for doing x or y, because my setup is way too small. 
+
+So I am looking for power users, for people who use Git annex to manage at least 1TB of data or more. Would you recommend Git annex to film professionals, to music professionals, to data miners, to universities, to your parents? Does it really makes your life easier? What are your experiences with the webapp? 
+
+I would be happy if you are willing to discuss these questions here, privately by mail or by chat eg. via Firefox Hello. 
+
+TIA
+juh
diff --git a/doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner/comment_1_ee783a968a5948e2f50bd2d090a2238b._comment b/doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner/comment_1_ee783a968a5948e2f50bd2d090a2238b._comment
new file mode 100644
index 0000000000..3eaa59b6b6
--- /dev/null
+++ b/doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner/comment_1_ee783a968a5948e2f50bd2d090a2238b._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 1"
+ date="2015-06-10T12:29:46Z"
+ content="""
+hi!
+
+I understand you may have had unicode problems with git-annex in the past: i had my [[own share|bugs/forget_corrupts_non-ascii_chars/]], but most bugs i filed were fixed (see [[users/anarcat/]] for a full list).
+
+I regularly use git-annex to manage my music, video and book collection. The total fileset is around 1-2TB, with thousands of files. Sometimes the music collection operations are a little slow because there are so many files, but in general i am *very* happy with the project. I don't use the webapp so much, because I feel the interface is too limited, and do a lot of things on the commandline.
+
+git-annex not only makes my life easier, it makes possible some things that were impossible before. I used to have a really hackish shell script to rsync part of my music collection to my laptop because it's too big to fit there completely. It wasn't working so well and there was no way to sync *new* music *back* in the main collection. Now I regularly can make changes to the music collection on the laptop without the files even being present. I can also import new files on the laptop easily when i meet people that want to share with me in my travels.
+
+i also work on the Isuma project, for which i will eventually do a longer write up here. For now, look at [[devblog/day_290__/]]. The project aims to manage over a terabyte of data across multiple devices spread over remote areas with limited bandwidth connexions. It's a distributed, two-way, CDN. So far it works well, and issues we have found have been quickly addressed by [[joeyh]].
+
+I would definitely recommend git-annex to film, music and university enthousiast. It is certainly worth the technical learning curve. For my parents, I am less sure. I mentioned the project, but they haven't found the use case for it yet, and they run Windows and OSX all over the place, which makes integration a little harder. With iPads, in particular, it seems that local storage is a thing of the past and everything goes \"in the cloud\". Which is in contradiction with git-annex a little, as it tries to take back control of your files.
+
+Anyways, happy to spar more if you have any more questions. Good luck with the book!
+"""]]
diff --git a/doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner/comment_2_259b67a887dd6aa327b752f455c24bff._comment b/doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner/comment_2_259b67a887dd6aa327b752f455c24bff._comment
new file mode 100644
index 0000000000..e7697132af
--- /dev/null
+++ b/doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner/comment_2_259b67a887dd6aa327b752f455c24bff._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2015-06-10T13:09:08Z"
+ content="""
+I'm happy to help if I can. Though I don't use the assistant (personally, though people \"at the other end\" of annexes I use do though) or special remotes, I do have at least one unusual use case which entails several terabytes over millions of files.
+
+In this case, I have a collection of harddrives and I am annexing all their contents into one large annex for quick backup/sorting later. This is well into git's problem with scaling to lots of files (I've posted a few tips on the site to minimise this impact).
+
+My other uses are more normal, such as managing photos and music and other digital assets such as games. I use the metadata quite a lot (e.g. I tag files I want to have available in Kodi, or tag game installer/archives to denote what operating system they are for).
+
+Being really picky about commits, several annexes I have have auto-commits on the git-annex branch disabled so I can control them. I'm even picky about doing things in such a way that they look nice in gitk! For example, I avoid cloning, because it makes the new annex appear at the bottom of gitk with its merge commit really far away, instead of a close merge (I can screenshot it if that isn't making any sense).
+
+I'm not sure if I would recommend it to someone who doesn't have someone who understands it nearby to help (just in case), but I would say it is definitely worth learning and using.
+
+In the book, I would say that you should mention that git-annex builds on git, and now people are building things on git-annex. For example, a project I am dabbling in is a VR environment which uses git and git-annex to manage its data: room definitions are stored as text files in git, with references to asset data (such as textures) which are 'git annex get'd as required. This is interesting as it means my co-developer can create/change rooms while I am in the VR environment and they change almost immediately. He changes the texture for the walls? It is downloaded and updated automatically. Imagine Second Life but with a (fully revertable) git-annex backend!
+"""]]
diff --git a/doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner/comment_3_a072a5c8f0798094d9ab0b7dc6c34f98._comment b/doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner/comment_3_a072a5c8f0798094d9ab0b7dc6c34f98._comment
new file mode 100644
index 0000000000..ff649fe609
--- /dev/null
+++ b/doc/forum/Writing_a_book_about_git-annex__58___I_need_a_sparring_partner/comment_3_a072a5c8f0798094d9ab0b7dc6c34f98._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="juh"
+ subject="Thanks"
+ date="2015-06-11T15:51:53Z"
+ content="""
+Thanks for your comments. I am very interested in things people build on top of git-annex. I am looking forward to read more about these projects. 
+
+Interesting that both of you don't use the webapp or the assistant. It was the first thing I used and it was disappointing, so now I try out the commandline. 
+
+I understand that managing an amount of files way too big for ones notebook or desktop is one of the main use cases. And this is a use case I definitely will cover in the book, if I write it at all. 
+
+Still evaluating... 
+
+
+"""]]
diff --git a/doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3.mdwn b/doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3.mdwn
new file mode 100644
index 0000000000..1a93839d75
--- /dev/null
+++ b/doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3.mdwn
@@ -0,0 +1,30 @@
+I've been trying out exporting to S3 with Wasabi, it has worked for some files, but for one large file I had to set a partsize value otherwise the upload would be rejected.
+
+Even with a partsize value, the upload still fails though. It gets right to the end and then fails with `WrongRequestBodyStreamSize`.
+
+```
+export wasabi 2020-01-24/guix_data_service_full.dump
+100%  7.31 GiB         45 MiB/s 0s
+  HttpExceptionRequest Request {
+    host                 = "data-guix-gnu-org-database-dumps.s3.wasabisys.com"
+    port                 = 443
+    secure               = True
+    requestHeaders       = [("Date","Sat, 22 Feb 2020 08:49:58 GMT"),("Authorization","<REDACTED>")]
+    path                 = "/2020-01-24/guix_data_service_full.dump"
+    queryString          = "partNumber=78&uploadId=MaRGWhxX1uZZ12IdGSSsc3rinnMgmKMfOcXRPuSo1zxzCviuBR37gxh_4gAmtvOmiRyqJjCMfgO4zhqKOB2Fi8WPLE2b7Iix-2gXkXgcIvLVlijoixwRS-UcllhHhG38"
+    method               = "PUT"
+    proxy                = Nothing
+    rawBody              = False
+    redirectCount        = 10
+    responseTimeout      = ResponseTimeoutDefault
+    requestVersion       = HTTP/1.1
+  }
+   (WrongRequestBodyStreamSize 31419314 29814466)
+failed
+```
+
+I've tried with partsizes from 100MB to 5GB, and I'm on a pretty recent version of git-annex: 7.20200219. I'm not sure if this is an issue in git-annex, or the aws or http-client dependencies.
+
+Thanks,
+
+Chris
diff --git a/doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3/comment_1_8b066ad9628073a3ae045087b4ea79b5._comment b/doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3/comment_1_8b066ad9628073a3ae045087b4ea79b5._comment
new file mode 100644
index 0000000000..665cb9118a
--- /dev/null
+++ b/doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3/comment_1_8b066ad9628073a3ae045087b4ea79b5._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-25T16:47:29Z"
+ content="""
+How large, in bytes, is the file you were trying to upload there,
+and what was the partsize?
+
+WrongRequestBodyStreamSize is an exception from the http-client
+library. It throws this when writing a request to the http server
+and the stream of data included in the request somehow does not have the
+length it expected.
+
+It expected 31419314 bytes and got only 29814466, and this appears
+to have been the last part of the file.
+
+Looking at the http-client code, it seems almost certainly due to a
+RequestBodyStream declaring an incorrect length of the stream. And,
+git-annex does use RequestBodyStream in particular in S3 multipart uploads.
+So it seems most likely a git-annex bug.
+"""]]
diff --git a/doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3/comment_2_c9eff9a83ea5ee71cbe87022be9d0875._comment b/doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3/comment_2_c9eff9a83ea5ee71cbe87022be9d0875._comment
new file mode 100644
index 0000000000..4c8ac43234
--- /dev/null
+++ b/doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3/comment_2_c9eff9a83ea5ee71cbe87022be9d0875._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="cbaines"
+ avatar="http://cdn.libravatar.org/avatar/1b15be83ec9e779dce940ce88cac603a"
+ subject="comment 2"
+ date="2020-03-25T22:40:12Z"
+ content="""
+Hi Joey,
+
+Sorry, missed your reply.
+
+I believe this is the size in bytes of the file I was trying to upload: 7850992066, and I'm not exactly sure what the partsize was, but I think it was 100MB.
+
+Thanks for looking in to this,
+
+Chris
+"""]]
diff --git a/doc/forum/Wrong_symlink_target_on_usb_drive.mdwn b/doc/forum/Wrong_symlink_target_on_usb_drive.mdwn
new file mode 100644
index 0000000000..661dc5bd3a
--- /dev/null
+++ b/doc/forum/Wrong_symlink_target_on_usb_drive.mdwn
@@ -0,0 +1,55 @@
+As I'm not sure whether this is my fault or a bug of git-annex, I'll post it in forum first.
+
+I have a normal v6 git-annex setup, with a desktop, laptop and usb stick.
+
+All repositories are in sync, also the usb drive.
+There are some unlocked files, which are fine.
+But there are also some locked files, which appear to be broken.
+Checking the target, there is a big difference between the paths. On the computers, it's `.git/annex/objects/0W/vj/SHA256E-s10230770--dcbf7418ff3c9698e9d98418fd07a52afec172aeef80aee2a84dcfdaeef859ed/SHA256E-s10230770--dcbf7418ff3c9698e9d98418fd07a52afec172aeef80aee2a84dcfdaeef859ed`.
+
+Also the usb drive links to this location, but the file does not exist.
+Searching with the firs part of the hash, I got some interesting result: the file was stored in `.git/annex/objects/1cc/840/SHA256E-s10230770--dcbf7418ff3c9698e9d98418fd07a52afec172aeef80aee2a84dcfdaeef859ed`.
+The difference is that the two first directories have three instead of two letters and only one layer.
+The hash remains the same, and the file is valid.
+
+```
+$ cd desktop
+$ git annex sync --content
+(success)
+$ readlink -f locked-file
+.git/annex/objects/0W/vj/SHA256E-s10230770--dcbf7418ff3c9698e9d98418fd07a52afec172aeef80aee2a84dcfdaeef859ed/SHA256E-s10230770--dcbf7418ff3c9698e9d98418fd07a52afec172aeef80aee2a84dcfdaeef859ed
+$ cd usb-drive
+$ readlink -f locked-file
+(no output → broken)
+$ find .git/annex/objects/ -name *SHA256E-s10230770*
+.git/annex/objects/1cc/840/SHA256E-s10230770--dcbf7418ff3c9698e9d98418fd07a52afec172aeef80aee2a84dcfdaeef859ed
+(file is at different place)
+```
+
+I did some troubleshooting and unspecific fixing.
+
+```
+$ git annex whereis locked-file
+whereis locked-file (3 copies) 
+   	d0a64b4b-054e-4c42-a64f-58a08591abab -- laptop
+   	e3013e6b-a06a-46a5-a67a-ce9ec0520d21 -- desktop
+   	ebd16ddb-548c-4078-b35e-087132523924 -- usb-drive [here]
+ok
+$ git annex fsck
+(everything fine, also unlocked-file was checked)
+$ git annex fix
+(no error, but no solution)
+$ git annex unlock locked-file
+(file is there and editable, great!)
+$ git annex lock locked-file
+(symlink is there and points… right, to the wrong location)
+$ git annex drop locked-file && git annex get locked-file
+(no change visible in work directory)
+```
+
+Specially on this drive disk space is important, so it would be for me a bad solution to keep them unlocked.
+
+As I mentioned earlier, this could be also my fault, as I have done some not-often used methods
+
+- I rebased the history and checked manually (without `git annex sync`) the `master` and `synced/master` branch to the same commit on all repositories, no errors reported
+- I used a v5 repository on laptop before syncing with the drive, then upgraded. I don't think it is the problem here as it works on desktop after the sync as wanted
diff --git a/doc/forum/Wrong_symlink_target_on_usb_drive/comment_1_9a50df886c0c23ee6f5586bd9f6b61c3._comment b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_1_9a50df886c0c23ee6f5586bd9f6b61c3._comment
new file mode 100644
index 0000000000..a82da1b4f1
--- /dev/null
+++ b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_1_9a50df886c0c23ee6f5586bd9f6b61c3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-10T16:16:36Z"
+ content="""
+What OS? 
+
+What filesystem is the drive formatted with? 
+
+What version of git-annex?
+"""]]
diff --git a/doc/forum/Wrong_symlink_target_on_usb_drive/comment_2_75df13154d3ea662119e9d701a0d9c97._comment b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_2_75df13154d3ea662119e9d701a0d9c97._comment
new file mode 100644
index 0000000000..976d66f536
--- /dev/null
+++ b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_2_75df13154d3ea662119e9d701a0d9c97._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="pixunil"
+ subject="more information"
+ date="2016-05-10T17:27:46Z"
+ content="""
+```
+$ lsb_release -a
+Distributor ID:	LinuxMint
+Description:	Linux Mint 17.3 Rosa
+Release:	17.3
+Codename:	rosa
+$ git annex version
+git-annex version: 6.20160505-gddbe008
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 6
+supported repository versions: 5 6
+upgrade supported from repository versions: 0 1 2 4 5
+operating system: linux x86_64
+```
+
+OS is on both computers the same, on ext4.
+The usb drive has 8GB and is NTFS formatted. About NTFS, I wasn't sure, so I left the partition as it was.
+
+I built git-annex with `stack` three times on top of the latest tag, the version number differed in minor afaik (but can't remember the old ones).
+I'm aware that I'm using an unstable version (forgot to mention it, sry about that), but it was on the two latest builds.
+I also don't know where the information is what the stable release is…
+"""]]
diff --git a/doc/forum/Wrong_symlink_target_on_usb_drive/comment_3_7f2fb4e7f0c0db9f9d9cbb637f02c9ff._comment b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_3_7f2fb4e7f0c0db9f9d9cbb637f02c9ff._comment
new file mode 100644
index 0000000000..50356feea4
--- /dev/null
+++ b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_3_7f2fb4e7f0c0db9f9d9cbb637f02c9ff._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-10T17:36:53Z"
+ content="""
+I suppose it must have something to do with NTFS, but I can't reproduce it
+on NTFS.. Normally git-annex will refuse to use symlinks on NTFS entirely.
+
+Can you please paste in the whole .git/config file of the repository?
+"""]]
diff --git a/doc/forum/Wrong_symlink_target_on_usb_drive/comment_4_f6ee6bfd5d82f0925f0e174b4c75e592._comment b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_4_f6ee6bfd5d82f0925f0e174b4c75e592._comment
new file mode 100644
index 0000000000..b80d950620
--- /dev/null
+++ b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_4_f6ee6bfd5d82f0925f0e174b4c75e592._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="pixunil"
+ subject="git config"
+ date="2016-05-10T17:59:10Z"
+ content="""
+```
+[core]
+	repositoryformatversion = 0
+	filemode = false
+	bare = false
+	logallrefupdates = true
+	symlinks = true
+[annex]
+	uuid = ebd16ddb-548c-4078-b35e-087132523924
+	crippledfilesystem = true
+	version = 6
+[filter \"annex\"]
+	smudge = git-annex smudge %f
+	clean = git-annex smudge --clean %f
+# remote and user omitted
+```
+
+Gotcha! `core.symlinks` is `true`!
+I set it to `false` and running `unlock` works fine, but after `lock` the file contents gets replaced with the two digits directories (not the three digits directories which are the place where the object is saved). Also, I can't unlock the file afterwards anymore.
+
+However, I would be fine if symlinks work fine on other file system (as mentioned, would be great for saving space and have the access to the files) or other method.
+"""]]
diff --git a/doc/forum/Wrong_symlink_target_on_usb_drive/comment_5_e5a152cef3c48ef05cb183907377f128._comment b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_5_e5a152cef3c48ef05cb183907377f128._comment
new file mode 100644
index 0000000000..8a5dd5530d
--- /dev/null
+++ b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_5_e5a152cef3c48ef05cb183907377f128._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-05-10T18:08:10Z"
+ content="""
+Ok, I reproduced the problem. Normally core.symlinks will be false
+by on NTFS. You have to manually set it to true to experience
+this problem AFAICS.
+
+I was able to lock a file (resulting in a broken symlink) and then successfully 
+unlock it and the content was back in place.
+
+git-annex always uses the lower case hash directory names when on a
+crippled filesystem, since that's more portable and avoids lots of
+potential problems. By configuring core.symlinks=true, you make git-annex
+support locking files using symlinks, but these symlinks can't point to the
+actual content location.
+
+I think it makes sense for git-annex to use the the mixed case hash
+directory names when core.symlinks=true even if the filesystem is crippled.
+There's some foot-shooting potential, since some crippled fileystems
+don't support the mixed-case hash directories. But, you have to manually
+set up this configuration. I've made a change along these lines.
+"""]]
diff --git a/doc/forum/Wrong_symlink_target_on_usb_drive/comment_6_be59fcc5633b352eefe993871df1ec4a._comment b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_6_be59fcc5633b352eefe993871df1ec4a._comment
new file mode 100644
index 0000000000..83fda1a207
--- /dev/null
+++ b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_6_be59fcc5633b352eefe993871df1ec4a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="pixunil"
+ subject="comment 6"
+ date="2016-05-10T20:45:56Z"
+ content="""
+Thanks for clearing it up, so I guess it was me.
+Otherwise, I have some questions:
+
+- Could I set `annex.crippledfilesystem` to `false` or is that dangerous on NTFS?
+- Do symlinks also on Window work? (direction of the slash)
+- Wouldn't it be better to modify the link target than the location of the objects?
+
+I'm also fine with redirecting me to a FAQ, thanks again for your time and efforts.
+"""]]
diff --git a/doc/forum/Wrong_symlink_target_on_usb_drive/comment_7_64e1cdf144a17319831a58b04b22b7ea._comment b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_7_64e1cdf144a17319831a58b04b22b7ea._comment
new file mode 100644
index 0000000000..a8ef69cc62
--- /dev/null
+++ b/doc/forum/Wrong_symlink_target_on_usb_drive/comment_7_64e1cdf144a17319831a58b04b22b7ea._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2016-05-10T21:00:06Z"
+ content="""
+You might be able to unset annex.crippledfilesystem. Or it might cause some
+stuff to break. Especially if you access this drive from Windows.
+
+AFAIK symlinks don't work in Windows; at least git-annex does not know how
+to create them on Windows. (Windows has symlink-ish things and git might be
+able to use them.)
+
+The link target is committed to the master branch, so you need to be able
+to check out that same branch in other clones and have it point at the
+content. So there can only be one link target used, and by default that's
+the mixed case one. See [[tuning]] for how to change that.
+"""]]
diff --git a/doc/forum/XBMC__44___NFS___38___git-annex_.mdwn b/doc/forum/XBMC__44___NFS___38___git-annex_.mdwn
new file mode 100644
index 0000000000..fc5cd702ad
--- /dev/null
+++ b/doc/forum/XBMC__44___NFS___38___git-annex_.mdwn
@@ -0,0 +1,27 @@
+Hi,
+
+this is not a git-annex problem, but more likely a way some software handles symlinks and/or do file-type detection.
+
+my setup is a following:
+- multiple pc/laptop (linux)
+- one NAS (debian) - main repo for music/films/photos - all in git-annex
+- a Raspberry Pi (Raspbmc) - connected to the TV
+
+I want to share all my films/music/.. to the Pi.
+So, i setup a r/o NFS and mounted that in the XBMC.
+So far this works, I see directories but XBMC do not recognize the media files.
+It works, if I "git-annex edit ..." the file.
+
+My _assumption_ is, that it follows the symlink, finds a file with no extension - and ignores that.
+In XBMC-config there is a list of supported filetypes by extension. ( .avi,.mpg,.foo,.bar )
+
+What I have think of so far:
+- tell XBMC somehow to load all the files (did not work)
+- having some kind of (FUSE?) filter, which hides the symlink in a transparent way
+- creating via script hard-links in a seperate folder with same structure, mount that.
+- using some alternative to NFS ( like ftp, smb ) or a other kind of media-server (server-side)
+
+any comments, ideas ? 
+If i find a solution, I'll post it here.
+
+.ka
diff --git a/doc/forum/XBMC__44___NFS___38___git-annex_/comment_1_86480f31d410e903766f82e6ecf83e1c._comment b/doc/forum/XBMC__44___NFS___38___git-annex_/comment_1_86480f31d410e903766f82e6ecf83e1c._comment
new file mode 100644
index 0000000000..e825225487
--- /dev/null
+++ b/doc/forum/XBMC__44___NFS___38___git-annex_/comment_1_86480f31d410e903766f82e6ecf83e1c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="Samba works"
+ date="2013-05-30T14:22:46Z"
+ content="""
+I use samba. Just need to set
+
+    unix extensions = no
+
+which causes samba to handle the symlinks internally.
+"""]]
diff --git a/doc/forum/XBMC__44___NFS___38___git-annex_/comment_2_d8ed4dd51d3050db691a8abdec24cd42._comment b/doc/forum/XBMC__44___NFS___38___git-annex_/comment_2_d8ed4dd51d3050db691a8abdec24cd42._comment
new file mode 100644
index 0000000000..0b3cb22c14
--- /dev/null
+++ b/doc/forum/XBMC__44___NFS___38___git-annex_/comment_2_d8ed4dd51d3050db691a8abdec24cd42._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-05-30T15:20:51Z"
+ content="""
+The default git-annex backend for over a year now is SHA256E, which includes the filename extension in the key to deal with programs that rely on them. If you're not using that backend, you can `git annex migrate` to it.
+
+Or you can turn on direct mode, which will certainly solve the problem.
+"""]]
diff --git a/doc/forum/XBMC__44___NFS___38___git-annex_/comment_3_42b80ee51ce25775bf4532f53a8ecfe3._comment b/doc/forum/XBMC__44___NFS___38___git-annex_/comment_3_42b80ee51ce25775bf4532f53a8ecfe3._comment
new file mode 100644
index 0000000000..00fbf6a208
--- /dev/null
+++ b/doc/forum/XBMC__44___NFS___38___git-annex_/comment_3_42b80ee51ce25775bf4532f53a8ecfe3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="ka7"
+ ip="2001:7b8:155d:0:222:64ff:fe16:dc52"
+ subject="comment 3"
+ date="2013-05-31T15:45:51Z"
+ content="""
+ah, great.
+I'll try the samba way.
+And i guess my git-annex is too old (using the git-annex version: 3.20120629~bpo60+2 from debian-backports)
+thanks !
+"""]]
diff --git a/doc/forum/XBMC__44___NFS___38___git-annex_/comment_4_01767f3f864954cf8080274e206da9d4._comment b/doc/forum/XBMC__44___NFS___38___git-annex_/comment_4_01767f3f864954cf8080274e206da9d4._comment
new file mode 100644
index 0000000000..58f00af15e
--- /dev/null
+++ b/doc/forum/XBMC__44___NFS___38___git-annex_/comment_4_01767f3f864954cf8080274e206da9d4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ka7"
+ ip="2001:7b8:155d:0:222:64ff:fe16:dc52"
+ subject="comment 4"
+ date="2013-05-31T18:46:29Z"
+ content="""
+after a quick check I realized that sha256E is available -- migrate and yepey!
+"""]]
diff --git a/doc/forum/XMPP_authentication_failure.mdwn b/doc/forum/XMPP_authentication_failure.mdwn
new file mode 100644
index 0000000000..3c4c41bc2a
--- /dev/null
+++ b/doc/forum/XMPP_authentication_failure.mdwn
@@ -0,0 +1,15 @@
+Hi,
+
+Not sure if this is a bug or not, so posting it here rather than in the bug tracker.
+
+Basically, I am unable to add an XMPP identity via the webapp, I continually  get the error message: "Unable to connect to the Jabber server. Maybe you entered the wrong password? (Error message: AuthenticationFailure)"
+
+I didn't enter the wrong password, I copy/pasted it from my password manager and the same account/password work fine with Pidgin. The log doesn't show anything of interest that I can see.
+
+Using git annex version 4.20130405 from Debain Unstable. The server is ejabberd running on my VPS with a self signed certificate.
+
+Anyone got any idea what might be going on?
+
+Cheers,
+
+Rob
diff --git a/doc/forum/XMPP_authentication_failure/comment_1_19c7c3aa79d209d613d2e061e3129690._comment b/doc/forum/XMPP_authentication_failure/comment_1_19c7c3aa79d209d613d2e061e3129690._comment
new file mode 100644
index 0000000000..a5862e58fb
--- /dev/null
+++ b/doc/forum/XMPP_authentication_failure/comment_1_19c7c3aa79d209d613d2e061e3129690._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-09T18:31:01Z"
+ content="""
+I installed ejabberd and was able to trivially reproduce this bug. Pidgin works, git-annex fails, and I just created the user with `ejabberdctl register`. Filed an upstream bug report against the haskell network-protocol-xmpp library, by email, since there's no upstream BTS:
+"""]]
diff --git a/doc/forum/XMPP_authentication_failure/comment_2_870059fed451e8377e5d382464ecc34b._comment b/doc/forum/XMPP_authentication_failure/comment_2_870059fed451e8377e5d382464ecc34b._comment
new file mode 100644
index 0000000000..bcf4e22ac6
--- /dev/null
+++ b/doc/forum/XMPP_authentication_failure/comment_2_870059fed451e8377e5d382464ecc34b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="robconnolly"
+ ip="203.167.218.84"
+ subject="comment 2"
+ date="2013-04-09T23:01:44Z"
+ content="""
+Excellent, thanks for the quick response/action!
+"""]]
diff --git a/doc/forum/XMPP_authentication_failure/comment_3_1a7ff955e9173f13d10b75f203792384._comment b/doc/forum/XMPP_authentication_failure/comment_3_1a7ff955e9173f13d10b75f203792384._comment
new file mode 100644
index 0000000000..587daa0edc
--- /dev/null
+++ b/doc/forum/XMPP_authentication_failure/comment_3_1a7ff955e9173f13d10b75f203792384._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-04-12T22:25:12Z"
+ content="""
+John has gotten back to me with some analysis. The authentication failure is when SCRAM-SHA-1 is used. Ejabberd is rejecting the client's authentication request with a reason of \"bad-protocol\". It's not clear if ejabberd is broken or if gsasl is generating a bad SCRAM-SHA-1 authentication. We're inclined toward the latter, and will be forwarding this on to ejabberd.
+
+The only way to turn off this authentication in ejabberd is to configure it to store passwords in plain text, or downgrade to a version older than 2.1.9, which first added it. Note that debian stable contains 2.1.5.3, so is not currently affected, for example.
+"""]]
diff --git a/doc/forum/XMPP_authentication_failure/comment_4_d59031ebc0dd3abc1f4c96878328362c._comment b/doc/forum/XMPP_authentication_failure/comment_4_d59031ebc0dd3abc1f4c96878328362c._comment
new file mode 100644
index 0000000000..e3e927818a
--- /dev/null
+++ b/doc/forum/XMPP_authentication_failure/comment_4_d59031ebc0dd3abc1f4c96878328362c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-04-17T13:26:45Z"
+ content="""
+Upstream bug report, with patch https://support.process-one.net/browse/EJAB-1632
+"""]]
diff --git a/doc/forum/XMPP_authentication_failure/comment_5_c37ef477bef7efdb79dd05dce90dfde6._comment b/doc/forum/XMPP_authentication_failure/comment_5_c37ef477bef7efdb79dd05dce90dfde6._comment
new file mode 100644
index 0000000000..37a3365d01
--- /dev/null
+++ b/doc/forum/XMPP_authentication_failure/comment_5_c37ef477bef7efdb79dd05dce90dfde6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkF8_uQjLYm5Mf5F_JuVW-BxlvzpWjvR_o"
+ nickname="Andrew"
+ subject="Wheezy is affected"
+ date="2013-05-25T12:00:21Z"
+ content="""
+Now that Wheezy is out, Debian Stable appears to be affected by this issue. It has ejabberd v2.1.10 .
+
+The patch on the linked bug report doesn't apply cleanly to v2.1.10. I'll try and look at this again tomorrow.
+"""]]
diff --git a/doc/forum/XMPP_authentication_failure/comment_6_48cabea4c2caf5b3bd854df3aaa17d3d._comment b/doc/forum/XMPP_authentication_failure/comment_6_48cabea4c2caf5b3bd854df3aaa17d3d._comment
new file mode 100644
index 0000000000..fe4ab07443
--- /dev/null
+++ b/doc/forum/XMPP_authentication_failure/comment_6_48cabea4c2caf5b3bd854df3aaa17d3d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 6"
+ date="2013-05-25T17:57:43Z"
+ content="""
+Debian has it fixed in 2.1.10-5 but this has unfortunately not made it to the wheezy release.
+"""]]
diff --git a/doc/forum/XMPP_authentication_failure/comment_7_14cd9b67806db93c3af055d88c9a910a._comment b/doc/forum/XMPP_authentication_failure/comment_7_14cd9b67806db93c3af055d88c9a910a._comment
new file mode 100644
index 0000000000..38a8733923
--- /dev/null
+++ b/doc/forum/XMPP_authentication_failure/comment_7_14cd9b67806db93c3af055d88c9a910a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkF8_uQjLYm5Mf5F_JuVW-BxlvzpWjvR_o"
+ nickname="Andrew"
+ subject="comment 7"
+ date="2013-05-25T20:27:32Z"
+ content="""
+Ah ha, so it is. I've installed ejabberd from Jessie onto my Wheezy box and now git-annex can authenticate.
+
+Thank you!
+"""]]
diff --git a/doc/forum/XMPP_authentication_failure/comment_8_151d3fd7d3cceb30fd20a8f3bd54036c._comment b/doc/forum/XMPP_authentication_failure/comment_8_151d3fd7d3cceb30fd20a8f3bd54036c._comment
new file mode 100644
index 0000000000..2700343ca2
--- /dev/null
+++ b/doc/forum/XMPP_authentication_failure/comment_8_151d3fd7d3cceb30fd20a8f3bd54036c._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnVTPaZaIfnZqDbkmW97pqxwi2QuZIJAF4"
+ nickname="Boris"
+ subject="jabberd also affected"
+ date="2013-06-25T13:00:46Z"
+ content="""
+I tried logging in to my local 'jabberd' server and got the same response:
+
+AuthenticationError \"No supported authentication mechanism\"
+
+checking the version gives:
+
+    jabberd -v
+    jabberd14 version 1.6.1.1
+
+    The following optional features have been enabled:
+    - support for IPv6.
+    - support for TLS using GNU TLS
+    - support for MySQL
+    - support for PostgreSQL
+
+--------------
+Can I do anything, investigate something?
+"""]]
diff --git a/doc/forum/XMPP_authentication_failure/comment_9_fbb9eba65fbb72201f08511945fbcf8c._comment b/doc/forum/XMPP_authentication_failure/comment_9_fbb9eba65fbb72201f08511945fbcf8c._comment
new file mode 100644
index 0000000000..e019056de6
--- /dev/null
+++ b/doc/forum/XMPP_authentication_failure/comment_9_fbb9eba65fbb72201f08511945fbcf8c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 9"
+ date="2013-06-25T17:18:56Z"
+ content="""
+Boris, that seems like an unrelated problem to the one affecting ejabberd. Different error message. 
+
+"""]]
diff --git a/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__.mdwn b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__.mdwn
new file mode 100644
index 0000000000..f29637c0df
--- /dev/null
+++ b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__.mdwn
@@ -0,0 +1,9 @@
+git-annex-assistant is so exciting...
+
+Can't set up XMPP sharing. The web app says "Wrong Password" for my gmail/home-google-apps/work-google-apps addresses, but they are correct.
+
+I'd love to send some debug output, can anyone tell me how to get it? Of course if I'm just doing something wrong and you have an FAQ link or similar, feel free to RTFM me :)
+
+I'm on Ubuntu 12.04 running https://downloads.kitenet.net/git-annex/linux/3.20121112/git-annex-standalone-amd64.tar.gz
+
+Carlo
diff --git a/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_1_1ba0735141fc6a21ac15913f4cacefae._comment b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_1_1ba0735141fc6a21ac15913f4cacefae._comment
new file mode 100644
index 0000000000..d3f408690c
--- /dev/null
+++ b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_1_1ba0735141fc6a21ac15913f4cacefae._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 1"
+ date="2012-11-13T14:38:28Z"
+ content="""
+Just an idea: Do you have two-factor-authorisation set up for your google account, you need to generate an application specific password, as the 'normal' password will not work.
+"""]]
diff --git a/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_2_16994dc86b87592fc62799e2d206d172._comment b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_2_16994dc86b87592fc62799e2d206d172._comment
new file mode 100644
index 0000000000..2c5f408e7b
--- /dev/null
+++ b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_2_16994dc86b87592fc62799e2d206d172._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.11.120"
+ subject="comment 2"
+ date="2012-11-13T17:21:35Z"
+ content="""
+@Karsten that seems likely.
+
+I've made a change so it shows the error message from the XMPP library I'm using. Which may or may not be useful..
+"""]]
diff --git a/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_3_6afd424edc4095b8f71b136de2a9e64d._comment b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_3_6afd424edc4095b8f71b136de2a9e64d._comment
new file mode 100644
index 0000000000..eab2e796bc
--- /dev/null
+++ b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_3_6afd424edc4095b8f71b136de2a9e64d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="XMPP"
+ date="2012-11-13T23:26:50Z"
+ content="""
+Just tried a fresh jabber.org address, same error.
+
+Will see if I can get the changed version built. Or are there nightlies?
+"""]]
diff --git a/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_4_1381b6a927410642c6a93aa8354be791._comment b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_4_1381b6a927410642c6a93aa8354be791._comment
new file mode 100644
index 0000000000..9cdca6fc1e
--- /dev/null
+++ b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_4_1381b6a927410642c6a93aa8354be791._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="Now Works! For jabber.org, gmail, but NOT google apps"
+ date="2012-11-27T11:40:43Z"
+ content="""
+Hi again!
+
+With the latest version, 3.20121126, pairing works for both something@gmail.com and something@jabber.org! Yay!
+
+What still fails is my google apps address, something@somedomain.com, seems to behave same as before. the assistant says
+
+  Unable to connect to the Jabber server. Maybe you entered the wrong password? (Error message: connect: timeout (Connection timed out))
+
+If you would like a google apps address on my domain, so you don't have to set up your own, just let me know.
+
+"""]]
diff --git a/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_5_c5b33c7a8aa8e6d0f9349510dac2366d._comment b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_5_c5b33c7a8aa8e6d0f9349510dac2366d._comment
new file mode 100644
index 0000000000..58fb0242b3
--- /dev/null
+++ b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_5_c5b33c7a8aa8e6d0f9349510dac2366d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 5"
+ date="2012-11-27T20:32:47Z"
+ content="""
+Hmm, I can't think of anything I've changed that would make it work where it didn't before.
+
+I suspect the google apps problem is because it looks for a SRV record in DNS to find the jabber server, and something is wrong there. Without knowing what \"something@somedomain.com\" is standing for, it's hard to tell. :)
+
+If you'd like to set me up something to test with, my email address is id@joeyh.name
+"""]]
diff --git a/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_6_9913d2983ba2744ed24911f74988e4c7._comment b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_6_9913d2983ba2744ed24911f74988e4c7._comment
new file mode 100644
index 0000000000..cc633e8fb5
--- /dev/null
+++ b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_6_9913d2983ba2744ed24911f74988e4c7._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="comment 6"
+ date="2012-11-29T15:37:46Z"
+ content="""
+Weird, 20121112 works too now.
+
+Looks like some kind of edge case... I'll let you know if I find it.
+
+"""]]
diff --git a/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_7_ad6f385a2b95803eb9d81dfe76359551._comment b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_7_ad6f385a2b95803eb9d81dfe76359551._comment
new file mode 100644
index 0000000000..de8403c52e
--- /dev/null
+++ b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_7_ad6f385a2b95803eb9d81dfe76359551._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlutNrg7ajiNAfi5gqJfD8crv0aimZa27k"
+ nickname="Chuck"
+ subject="I'm having this problem too"
+ date="2013-07-21T19:14:21Z"
+ content="""
+I'm a git-annex newbie looking for Dropbox-like functionality.  I've got git-annex and the webapp running on my desktop and laptop, and I believe I've got a Jabber account working since Kopete seems happy with my account info.  But when I enter the correct Gmail UID and password I get the above error.
+
+I'm running the version of git-annex that's current in the standard Ubuntu repos (I'm actually running Kubuntu if that matters), and that version is 20121112ubuntu2.  If this is an issue that was fixed in the 20121126 release, how would I get that?  Doing the standard install gets me the version I have now...
+"""]]
diff --git a/doc/forum/XMPP_problem_behind_router.mdwn b/doc/forum/XMPP_problem_behind_router.mdwn
new file mode 100644
index 0000000000..5eec76a07d
--- /dev/null
+++ b/doc/forum/XMPP_problem_behind_router.mdwn
@@ -0,0 +1,3 @@
+I'm trying to configure a jabber account for use with git-annex, but it seems that something's wrong as soon as I try to go through my router (wired or wireless).  Compared to directly connecting to my modem, wireshark shows a lot of TCP retransmissions, eventually resulting in "Unable to connect to the Jabber server. Maybe you entered the wrong password? (Error message: host gmail.com:5222 failed: connect: timeout (Connection timed out))" in the webapp.
+
+I've tried to configure the account both in the webapp and manually in the .git/annex/creds/xmpp file, but it doesn't seem to make a difference.  It's able to connect if I directly connect it to my modem, so I'm fairly sure it's not a problem at my computer or with the credentials.  It doesn't appear to be a problem at the firewall on the router, but I could certainly be missing something.  Are there some other tests I could try to narrow down the problem?
diff --git a/doc/forum/XMPP_problem_behind_router/comment_1_25a7f8dc5cf14cda4d76b2f8c6ca77d5._comment b/doc/forum/XMPP_problem_behind_router/comment_1_25a7f8dc5cf14cda4d76b2f8c6ca77d5._comment
new file mode 100644
index 0000000000..04b1965c00
--- /dev/null
+++ b/doc/forum/XMPP_problem_behind_router/comment_1_25a7f8dc5cf14cda4d76b2f8c6ca77d5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/wbh0dY54mcPwTpeOweuPQ8JiZrH3hg--#9b726"
+ nickname="Joe"
+ subject="comment 1"
+ date="2014-09-23T01:15:23Z"
+ content="""
+I forgot to mention that XMPP via other clients (e.g., empathy) works fine.
+"""]]
diff --git a/doc/forum/XMPP_problem_behind_router/comment_2_3186ebe32c30764b9fd53625dd3e4eda._comment b/doc/forum/XMPP_problem_behind_router/comment_2_3186ebe32c30764b9fd53625dd3e4eda._comment
new file mode 100644
index 0000000000..63387ae3dd
--- /dev/null
+++ b/doc/forum/XMPP_problem_behind_router/comment_2_3186ebe32c30764b9fd53625dd3e4eda._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.144"
+ subject="comment 2"
+ date="2014-09-25T15:48:39Z"
+ content="""
+I don't think that google XMPP server is at gmail.com. This suggests that the SRV record lookup to get from the email server to the xmpp server failed somehow. So, I'd look for a issue on the router's DNS server, or perhaps reconfigure DNS to bypass that server.
+"""]]
diff --git a/doc/forum/XMPP_problem_behind_router/comment_3_7fa8fe8cb92993c935ba2dbfb2aef728._comment b/doc/forum/XMPP_problem_behind_router/comment_3_7fa8fe8cb92993c935ba2dbfb2aef728._comment
new file mode 100644
index 0000000000..d8ee076f64
--- /dev/null
+++ b/doc/forum/XMPP_problem_behind_router/comment_3_7fa8fe8cb92993c935ba2dbfb2aef728._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/wbh0dY54mcPwTpeOweuPQ8JiZrH3hg--#9b726"
+ nickname="Joe"
+ subject="comment 3"
+ date="2014-09-29T01:38:14Z"
+ content="""
+Thanks, that seemed to be the problem!  My router's dnsmasq had the 'filterwin2k' option set, which apparently [blocks queries for SRV records](http://wiki.openwrt.org/doc/howto/dhcp.dnsmasq#sip-phones.and.dnsmasq).  This may be fixed in newer OpenWRT versions, but my device is no longer supported.
+"""]]
diff --git a/doc/forum/XMPP_problem_behind_router/comment_4_6497ca72904dfdefe4e02f8a55127a8e._comment b/doc/forum/XMPP_problem_behind_router/comment_4_6497ca72904dfdefe4e02f8a55127a8e._comment
new file mode 100644
index 0000000000..959b298c7d
--- /dev/null
+++ b/doc/forum/XMPP_problem_behind_router/comment_4_6497ca72904dfdefe4e02f8a55127a8e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="mdcotonopu@d25539d868f269dc6d1b838c21bb86205a40dab9"
+ nickname="mdcotonopu"
+ avatar="http://cdn.libravatar.org/avatar/7acb7ca4679a80a3ea544df55ae4959b"
+ subject="comment 4"
+ date="2017-01-11T09:35:48Z"
+ content="""
+Running high debug verbosity with DEBUG=* npm start indicates that the socket connection with the target XMPP server was started, but still the online event is never fired, and online is never logged. (The server times out at 150 seconds before anything can be logged.<a href=\"https://productriver.com/best-wireless-routers\">best 4 wireless routers</a>
+"""]]
diff --git a/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__.mdwn b/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__.mdwn
new file mode 100644
index 0000000000..a9db915dab
--- /dev/null
+++ b/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__.mdwn
@@ -0,0 +1,45 @@
+Hi,
+
+Some time ago I asked [[here|git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah]]
+about possible improvements in git `copy --fast --to`, since it was painfully slow
+on moderately large repos.
+
+Now I found a way to make it much faster for my particular use case, by
+accessing some annex internals. And I realized that maybe commands like `git
+annex find --in=repo` do not batch queries to the location log. This is based on
+the following timings, on a new repo (only a few commits) and about 30k files.
+
+    > time git annex find --in=skynet > /dev/null
+
+    real	0m55.838s
+    user	0m30.000s
+    sys	0m1.583s
+
+
+    > time git ls-tree -r git-annex | cut -d ' ' -f 3 | cut -f 1 | git cat-file --batch > /dev/null
+
+    real	0m0.334s
+    user	0m0.517s
+    sys	0m0.030s
+
+Those numbers are on linux (with an already warm file cache) and an ext4 filesystem on a SSD.
+
+The second command above is feeding a list of objects to a single `git cat-file`
+process that cats them all to stdout, preceeding every file dump by the object
+being cat-ed. It is a trivial matter to parse this output and use it for
+whatever annex needs.
+
+Above I wrote a `git ls-tree` on the git-annex branch for simplicity, but we could
+just as well do a `ls-tree | ... | git cat-file` on HEAD to get the keys for the
+annexed files matching some path and then feed those keys to a cat-file on
+the git-annex branch. And this still would be an order of magnitude faster than
+what currently annex seems to do.
+
+I'm assuming the bottleneck is in that annex does not batch the `cat-file`, as the rest of logic needed for a find will be fast. Is that right? 
+
+Now, if the queries to the location log for `copy --to` and `find` could be batched this way, the
+performance of several useful things to do, like checking how many annexed files
+we are missing, would be bastly improved. Hell, I could even put that number on
+the command line prompt!
+
+I'm not yet very fluent in Haskell, but I'm willing to help if this is something that makes sense and can be done.
diff --git a/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_1_01cbfc513c790faef3a3ede5315d3589._comment b/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_1_01cbfc513c790faef3a3ede5315d3589._comment
new file mode 100644
index 0000000000..6b4a6b2a05
--- /dev/null
+++ b/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_1_01cbfc513c790faef3a3ede5315d3589._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-06T22:21:33Z"
+ content="""
+git-annex uses cat-file --batch, yes. You can verify this with --debug. Or you can read Annex/CatFile.hs and Git/CatFile.hs
+
+git-annex has to ensure that the git-annex branch is up-to-date and that any info synced into the repository is merged into it. This can require several calls to git log. Your command does not do that. git-annex find also runs `git ls-files --cached`, which has to examine the state of the index and of files on disk, in order to only show files that are in the working tree. Your command also omits that.
+"""]]
diff --git a/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_2_fe28dfb360caa12d5d5bc186def3eb45._comment b/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_2_fe28dfb360caa12d5d5bc186def3eb45._comment
new file mode 100644
index 0000000000..4ba4c82646
--- /dev/null
+++ b/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_2_fe28dfb360caa12d5d5bc186def3eb45._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkkyBDsfOB7JZvPZ4a8F3rwv0wk6Nb9n48"
+ nickname="Abdó"
+ subject="comment 2"
+ date="2013-11-06T23:14:03Z"
+ content="""
+Ok, then I don't understand where annex spends its time. git annex takes 55
+seconds! vs less than a second for a batched query on all the keys in the
+location log. Checking that branches are in sync, or traversing the working dir
+shouldn't amount the extra 54 seconds! At least not on a recently synced repo
+with up to date index and clean working dir.
+
+> git-annex has to ensure that the git-annex branch is up-to-date and that any info synced into the repository is merged into it. This can require several calls to git log
+
+Ok, I understand that. Checking that should be typically fast though, isn't it? On a repo that has just been synced, it doesn't need to go very far on the log.
+
+> git-annex find also runs git ls-files --cached, which has to examine the state of the index and of files on disk, in order to only show files that are in the working tree
+
+I understand that too. For my particular use case, I know I do the `git copy` when the
+repo is in sync and the working dir has no uncommited changes. So I use HEAD to retrieve the keys for
+the files in the working tree. I do something like that:
+
+    time git ls-tree -r HEAD | grep -e '^120000' | cut -d ' ' -f 3 | cut -f 1 | git cat-file --batch > /dev/null
+
+    real	0m0.178s
+    user	0m0.277s
+    sys 	0m0.037s
+
+That plus some fast parsing of the output gets the list of keys for the files in HEAD in less than a second. Where do the 54 extra seconds hide, then?
+
+Mm... how does annex retrieve the keys for files in the working tree? Does it follow
+the actual symlinks on the filesystem? I can believe that following 30k symlinks may be slow (although not 55 second slow).
+
+Sorry for being so insistent on this... It is just that I do think the same can be done much faster, and such an improvement in performance would be very interesting, not only for me.
+"""]]
diff --git a/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_3_9bb30ab62febe4ef63bed49f831a473a._comment b/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_3_9bb30ab62febe4ef63bed49f831a473a._comment
new file mode 100644
index 0000000000..c92be8ad53
--- /dev/null
+++ b/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_3_9bb30ab62febe4ef63bed49f831a473a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 3"
+ date="2013-11-07T18:12:09Z"
+ content="""
+It's hard to say until some profiling has actually been done. Comparing apples and oranges, or perhaps better to say, orange blossoms and oranges, is not very useful. 
+"""]]
diff --git a/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_4_7832f0347a41b8204538c01b72487803._comment b/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_4_7832f0347a41b8204538c01b72487803._comment
new file mode 100644
index 0000000000..3e7eb01dba
--- /dev/null
+++ b/doc/forum/_Does_git_annex_find___40____38___friends__41___batch_queries_to_the_location_log__63__/comment_4_7832f0347a41b8204538c01b72487803._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkkyBDsfOB7JZvPZ4a8F3rwv0wk6Nb9n48"
+ nickname="Abdó"
+ subject="comment 4"
+ date="2013-11-07T18:40:27Z"
+ content="""
+Ok, thanks.
+
+I understand that annex is more sophisticated than what I'm proposing. I'm also
+not comparing apples to oranges, what I'm saying is this: All the
+logic and checking and git calls that I thought annex needs to do, take
+much much less time than those 55 seconds. So either I'm missing something big (about 98% of it in execution time), or
+annex is doing something very inefficient. That's all I'm saying, and I was
+hoping that you could clarify that, since you already know the code.
+
+Also I'm sorry for being so annoying. If annex were writen in C, I would either have understood those 55 seconds or sent you a patch making annex faster. Being in
+haskell means that it will take me considerably more time and effort. But if I manage to
+improve things and if it is ok with you I'll send you patches... eventually.
+"""]]
diff --git a/doc/forum/__171__Locking__187___files_until_synced.mdwn b/doc/forum/__171__Locking__187___files_until_synced.mdwn
new file mode 100644
index 0000000000..129927bdc1
--- /dev/null
+++ b/doc/forum/__171__Locking__187___files_until_synced.mdwn
@@ -0,0 +1,7 @@
+I’m currently trying to set up a sync which involves an SQLite3 database file that should always be in the same state on all systems at all times (since there is no readily available way of merging the data). Basically, I’m looking for a practical way that gives me some help in making sure the files never drift apart between my remotes. Since I’m forgetful and might forget syncing the repo before going home from the office, I was wondering whether there might be a good way to assist me in this. Has anyone had some good ideas in this direction, or is there a canonical solution?
+
+It occurred to me one way would be to instate a hook somewhere that links the database to /dev/null in all other remotes (so the software will fail to work if I start it without having synced), but it seems tricky. I guess would have to involve per-remote branches, which will be hard to do, since I need to use direct mode.
+
+A less complex method might be forcing a sync before shutting down the system resp. when booting up.
+
+Maybe other folks have had ideas for a practical, yet robust solution.
diff --git a/doc/forum/__171__Locking__187___files_until_synced/comment_1_8bf59f47fee0a8d5741fe209b5899863._comment b/doc/forum/__171__Locking__187___files_until_synced/comment_1_8bf59f47fee0a8d5741fe209b5899863._comment
new file mode 100644
index 0000000000..d327a58b4c
--- /dev/null
+++ b/doc/forum/__171__Locking__187___files_until_synced/comment_1_8bf59f47fee0a8d5741fe209b5899863._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 1"
+ date="2014-07-08T17:31:53Z"
+ content="""
+This is something git's distributed nature preludes. You might frankly be better with one of the centralized VCSs that supports locking in this specific case. Or, you can do some kind of \"lock server\" that the clients contact, layering a centralized approach on top of git.
+"""]]
diff --git a/doc/forum/__171__Locking__187___files_until_synced/comment_2_0c683547a6178e4303f0b1ed1f5605a5._comment b/doc/forum/__171__Locking__187___files_until_synced/comment_2_0c683547a6178e4303f0b1ed1f5605a5._comment
new file mode 100644
index 0000000000..b76f35da5e
--- /dev/null
+++ b/doc/forum/__171__Locking__187___files_until_synced/comment_2_0c683547a6178e4303f0b1ed1f5605a5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="134.147.14.84"
+ subject="comment 2"
+ date="2014-07-09T07:07:27Z"
+ content="""
+Yea, it’s basically just the isolated one file that needs «locking», so one could just try a different route. The idea with keeping state on a server sounds like a pretty good idea. I could just «echo» via SSH to my webserver some info on who has the file locked; then I could wrap the program that uses the SQLite3 DB in a script that checks whether it’s safe.
+"""]]
diff --git a/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__.mdwn b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__.mdwn
new file mode 100644
index 0000000000..20f6d696a5
--- /dev/null
+++ b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__.mdwn
@@ -0,0 +1,14 @@
+Hey,
+
+I lost some symlinks to my data and I do not know how to recover them. I was in view mode  with some tag folders already there. I added _new_ files from outside annex into some folder and 'git annex add' those files.
+
+What I expected: Git-Annex should add those files to the annex, move the symlinks to the root of the annex (because there is no other way to tell where to put them) and tag them with the specific tag. That is the way I would like to work, first tag, then organize in folder structure.
+
+Now that seems not to be a scenario which has been respected? Because I don't see my files... anywhere. Not in master branch nor in the view branch (I already did 'git annex vpop'). If that is not supported and never will be git-annex should not accept data from the outside world if it is currently in view mode.
+
+Now, how do I get my symlinks back? I guess the content is still there, but the links are missing and I don't find any reference or history log to revert that. 'git annex unused' does not show them either.
+
+I hope somebody can help me :)
+
+Cheers,
+Stephan
diff --git a/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_1_52e4453432184524d84d88f6382cac9d._comment b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_1_52e4453432184524d84d88f6382cac9d._comment
new file mode 100644
index 0000000000..2ecde6390d
--- /dev/null
+++ b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_1_52e4453432184524d84d88f6382cac9d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="sts"
+ ip="134.147.240.107"
+ subject="comment 1"
+ date="2014-08-11T11:39:44Z"
+ content="""
+OK, I could find the commit where I have added the data. I can 'git show' the commit and see the keys. I can also checkout the commit and I can see my data. Now I tried to create symlinks based on the keys I found in the commit, so whats the right way?
+
+    git annex examinekey SHA256E-s1390161393--1dcba6e914ad6a9133d374e3c55fbf9a58f036e64298262692c7f8e7cdb65852.mkv
+    SHA256E-s1390161393--1dcba6e914ad6a9133d374e3c55fbf9a58f036e64298262692c7f8e7cdb65852.mkv
+
+    git annex fromkey SHA256E-s1390161393--1dcba6e914ad6a9133d374e3c55fbf9a58f036e64298262692c7f8e7cdb65852.mkv e01.mkv
+    git-annex: key (SHA256E-s1390161393--1dcba6e914ad6a9133d374e3c55fbf9a58f036e64298262692c7f8e7cdb65852.mkv) is not present in backend
+
+I am not sure what to do now :-/.
+"""]]
diff --git a/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment
new file mode 100644
index 0000000000..e9122c069c
--- /dev/null
+++ b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 2"
+ date="2014-08-12T17:57:26Z"
+ content="""
+views are a somewhat new feature that still needs work, and you will find this question of what to do about a file added while in a view in the todo list [[here|design/metadata]].
+
+Since views are just git branches, you can check out the view branch where you added the file, and it'll still be there. You could merge the branch (probably not a good idea since the filenames are moved around in the view). 
+
+Using `fromkey` will also work, if you have the right key and the content is present in the annex -- I just tested it. 
+"""]]
diff --git a/doc/forum/__34__Pairing__34___more_than_two_computers.mdwn b/doc/forum/__34__Pairing__34___more_than_two_computers.mdwn
new file mode 100644
index 0000000000..099c7a6631
--- /dev/null
+++ b/doc/forum/__34__Pairing__34___more_than_two_computers.mdwn
@@ -0,0 +1,11 @@
+I need some help understanding here.
+
+We use AeroFS at work to sync the normal user files across computers. I'll quite likely be replacing that with git annex as soon as Windows port is stable enough.
+
+How it works is that you create a repo, and share it with one or more users. Then AeroFS discovers what other repos are online and if they're on the local network, and syncs from wherever is most convenient.
+
+This sounds a little like pairing, but with pairing you need to arrange more than 2 devices in a "star" or "chain". This is fine for my own devices, but it becomes brittle if you have lots of devices syncing from each other, which may or may not be online at any given time. The only way around it seems to be to pair each device with each other device, with the labor rising exponentially.
+
+Is this correct? Best compromise for my use case seems to be to just do a star setup and pair everything with an always-on machine. Do you agree?
+
+Thanks! Carlo
diff --git a/doc/forum/__34__Pairing__34___more_than_two_computers/comment_1_80f7a4bb3c66b11e566043407b611bbf._comment b/doc/forum/__34__Pairing__34___more_than_two_computers/comment_1_80f7a4bb3c66b11e566043407b611bbf._comment
new file mode 100644
index 0000000000..026681f79c
--- /dev/null
+++ b/doc/forum/__34__Pairing__34___more_than_two_computers/comment_1_80f7a4bb3c66b11e566043407b611bbf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 1"
+ date="2013-10-22T17:41:58Z"
+ content="""
+You're basically correct. Typically if you have a central machine, it's a server, so at that point you're not pairing, but are just adding a ssh server, or some other type of remote.
+
+I think that systems like AeroFS are pretty neat, but my goal is not really to build another one of those. I'd rather make git-annex be able to use such things as [[special_remotes]].
+"""]]
diff --git a/doc/forum/__34__Preseeding__34___a_special_remote.mdwn b/doc/forum/__34__Preseeding__34___a_special_remote.mdwn
new file mode 100644
index 0000000000..4b1342598c
--- /dev/null
+++ b/doc/forum/__34__Preseeding__34___a_special_remote.mdwn
@@ -0,0 +1,5 @@
+I have a remote repository that I have yet to add as a remote into git-annex, but which already contains data that I want git-annex to manage. I already know what the SHA256 hashes and sizes of all the files are, and I can arrange them to match what git-annex will expect.
+
+Is there a way that I can tell git-annex about the presence of the data, to save me having to download and re-upload everything, in a way that is safe? What I want seems to be similar to "git annex reinject" but for special remotes (and I'll take care of the renaming), but I don't see anything in the manpage that looks likely.
+
+I can quite easily create and commit the symlinks with correctly predicted names in my master branch. Will git-annex will treat these correctly?
diff --git a/doc/forum/__34__Preseeding__34___a_special_remote/comment_1_b0c46d0eba900d0f6169a2c698d7a222._comment b/doc/forum/__34__Preseeding__34___a_special_remote/comment_1_b0c46d0eba900d0f6169a2c698d7a222._comment
new file mode 100644
index 0000000000..6fae5c62e3
--- /dev/null
+++ b/doc/forum/__34__Preseeding__34___a_special_remote/comment_1_b0c46d0eba900d0f6169a2c698d7a222._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.3"
+ subject="comment 1"
+ date="2014-05-21T17:41:22Z"
+ content="""
+If you also have the files present locally, you can simply do `git annex copy --fast --to remote`. git-annex copy will first check to see if the remote has the file; seeing that it does it will update the location log.
+
+Another option, if you have shell access on the remote is to simply set up a git repository there, move the files into it and `git annex add` them, and merge that into your local repository.
+
+There is not currently any way to set the [[location_tracking]] information to tell git-annex that a file has appeared on a remote. Of course, you can modify the git-annex branch manually to do so. See [[internals]].
+"""]]
diff --git a/doc/forum/__34__Preseeding__34___a_special_remote/comment_2_5e63f5e6f45c11cc86b293ce8acad77f._comment b/doc/forum/__34__Preseeding__34___a_special_remote/comment_2_5e63f5e6f45c11cc86b293ce8acad77f._comment
new file mode 100644
index 0000000000..cdbf1e76de
--- /dev/null
+++ b/doc/forum/__34__Preseeding__34___a_special_remote/comment_2_5e63f5e6f45c11cc86b293ce8acad77f._comment
@@ -0,0 +1,65 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkexhIpGcYa22aPQtLm-StpHiF-MHYPh5w"
+ nickname="Robie"
+ subject="Solved"
+ date="2014-06-01T13:55:58Z"
+ content="""
+Thanks to Joey for pointing me in the right direction. I got this working now.
+
+There are approximately three steps:
+
+1. Obtain a mapping of git-annex key to friendly name, and rename all entries
+in the special remote to their git-annex keys.
+
+2. Create and commit symlinks in the `master` branch (or wherever you want them).
+
+3. Add location tracking entries to the `git-annex` branch for all entries.
+
+First, I created an \"index\" file describing the contents of my special remote,
+in the form \"KEY NAME\" where KEY is the git-annex key (I used SHA256) and NAME
+is the name I want to use for each file.
+
+## Step 1: Map and rename
+
+In my case I was \"importing\" a ddar remote, so I wrote a quick script
+(https://github.com/basak/ddar/blob/master/contrib/git-annex-convert.py) to
+generate this index as well as rename all ddar archive members to their
+git-annex keys instead.
+
+## Step 2: Create and commit symlinks
+
+Then, I created symlinks in my master branch using:
+
+    exec 3<index
+    while read key name <&3; do ln -s `git annex examinekey --format='.git/annex/objects/${hashdirmixed}${key}/${key}' \"$key\"` \"$name\"; git add \"$name\"; done
+    git commit -m'Import ddar repository contents'
+    exec 3<&-
+
+## Step 3: Add to location tracking
+
+First I set three variables:
+
+    remote_name=ddar  # set to the name of the ddar git-annex special remote
+    
+    uuid=`git config remote.\"$remote_name\".annex-uuid`
+    now=`printf %6fs $(date +%s)`
+
+Then I added the entries from `index` into location tracking as follows:
+
+    git checkout git-annex
+    exec 3<index
+    while read key name <&3; do log=`git annex examinekey --format='${hashdirlower}${key}.log' \"$key\"`; mkdir -p `dirname \"$log\"`; echo \"$now 1 $uuid\" >> \"$log\";git add \"$log\";done
+    exec 3<&-
+    git commit -m'Import knowledge of ddar repository contents'
+
+## Verifying
+
+`git-annex fsck --from ddar --fast` checks that the keys expected in the
+special remote can be found (replace the special remote name as needed).
+
+Skipping `--fast` will download all data to verify it. I didn't do this -
+instead I just sampled one entry which seemed to be OK.
+
+
+
+"""]]
diff --git a/doc/forum/__34__Scanning_for_files_to_transfer__34__.mdwn b/doc/forum/__34__Scanning_for_files_to_transfer__34__.mdwn
new file mode 100644
index 0000000000..e08be0b39d
--- /dev/null
+++ b/doc/forum/__34__Scanning_for_files_to_transfer__34__.mdwn
@@ -0,0 +1,9 @@
+I have a Git Annex repository on my laptop with currently 141094 files.
+
+I used "git config annex.startupscan false" to disable the startup scan.
+
+Yet the assistant still runs at high CPU consumption for extended periods of time after starting.
+
+In the webapp, the startup scan is shown as completed, but under "Transfers" it says "Scanning for files to transfer".
+
+What is the difference between "Performing startup scan" and "Scanning for files to transfer"?
diff --git a/doc/forum/__34__Scanning_for_files_to_transfer__34__/comment_1_4fa6d0d5264707886e1e9b5184090386._comment b/doc/forum/__34__Scanning_for_files_to_transfer__34__/comment_1_4fa6d0d5264707886e1e9b5184090386._comment
new file mode 100644
index 0000000000..cab618d639
--- /dev/null
+++ b/doc/forum/__34__Scanning_for_files_to_transfer__34__/comment_1_4fa6d0d5264707886e1e9b5184090386._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-06T17:03:12Z"
+ content="""
+The scan that is skipped is one of the files on disk in order to find
+changes that were made while the assistant was not running.
+
+What you are seeing is the full transfer scan. While annex.startupscan
+could be made to also skip that scan, a full transfer scan is not only run
+at startup, but after merging git-annex branch changes from a remote. So
+disabling it only at startup does not seem very useful.
+
+There could be an option to disable the full transfer scan ever running.
+However, this would make the assistant not notice certian transfers/drops
+that you would normally want it to do. For example, if a remote got a bunch
+of files in an archive/ directory from somewhere else, and the local
+repository contains those files, the full transfer scan is needed to notice
+that the archived files can now be removed from the local repository.
+In other situations, the local repository would not get files that it
+ought to contain.
+
+So, I think it might be better to make the expensive transfer scan run a
+little bit slower so it doesn't peg your CPU. I've added a 1/200th second
+delay after each file it checks. 
+
+That will make it use something like 
+5-10% of the CPU, instead of 100%. At the same time it doesn't slow down the
+total scan very much. In a repository with 5k files, it makes the scan 25
+seconds slower, which makes the assistant react that much slower -- but
+the expensive scan is only needed to make sure things turn out consistent,
+so its overall speed is not super important.
+
+Check it out, let me know if it's still using too much CPU. We could always
+make that 1/200th second tunable, or find a better value for it.
+"""]]
diff --git a/doc/forum/__34__best__34___portable_filesystem_for_external_drive__63__.mdwn b/doc/forum/__34__best__34___portable_filesystem_for_external_drive__63__.mdwn
new file mode 100644
index 0000000000..cf448fe057
--- /dev/null
+++ b/doc/forum/__34__best__34___portable_filesystem_for_external_drive__63__.mdwn
@@ -0,0 +1,3 @@
+question came up on [neurostars](https://neurostars.org/t/downloading-data-for-the-dartbrains-online-course/23430/7) and I had no good answer:  what would be the best filesystem to use on external drives which would be portable (mountable) across OSes and would provide git-annex with needed features (symlinks, permissions handling, and  locking?).
+
+I love BTRFS on Linux but I do not think it is (and neither ext* family) is portable.  Is there **any** filesystem which would be portable across Windows/OSX/Windows and still work with git-annex without needing adjusted-branches mode?
diff --git a/doc/forum/__34__best__34___portable_filesystem_for_external_drive__63__/comment_1_31e5e55e9f8f391309b16c6591bb0bb0._comment b/doc/forum/__34__best__34___portable_filesystem_for_external_drive__63__/comment_1_31e5e55e9f8f391309b16c6591bb0bb0._comment
new file mode 100644
index 0000000000..294dea9b39
--- /dev/null
+++ b/doc/forum/__34__best__34___portable_filesystem_for_external_drive__63__/comment_1_31e5e55e9f8f391309b16c6591bb0bb0._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="I don't think there is one"
+ date="2022-09-02T02:04:29Z"
+ content="""
+Firstly, I don't think there is an agreement on what proper file permissions mean on local filesystems
+across OSes. Without a central authority what one denies the other can easily allow thus bypassing
+permissions. So basically you are semantically only left with permission \"hints\" or \"suggestions\"
+-- this file is to be treated read only, that file is supposed to be executable and so on -- that is, without
+any reference to a common user/group authority.
+
+AFAIK, there's some cross-platform support for symlinks on say NTFS, at least between linux
+and windows. The problem is that NTFS symlinks are *typed* -- they are either directory or file
+symlinks and while git on windows can restore symlinks (with core.symlinks = true) post-checkout
+(for instance with `git restore`), it can't seem to be able to decide which kind it needs *during*
+checkout, so it simply places symlink contents as regular files at first and declares them modified.
+
+Considering that git's own handling of symlinks is lackluster on Windows, it's no wonder that Joey hasn't
+been very enthusiastic about adding the support for the regular indirect locked mode there.
+E.g., I'll refer you to this archived todo in Google's cache for context: <https://webcache.googleusercontent.com/search?q=cache:Bu24xB2MR94J:https://git-annex.branchable.com/todo/utilising_the_mklink_command_on_windows_to_utilise_symlinks_and_therefore_indirect_mode_on_windows/>
+
+As for locking, Joey can probably expand on that subject.
+
+All in all there are several obstacles to working with checked out files across platforms. As far as I can tell
+the only cross-platform format is a bare remote with permissive file modes which is of course a bit inconvenient
+for day-to-day work because usually you need that checked out worktree somewhere for your apps to operate on.
+"""]]
diff --git a/doc/forum/__34__best__34___portable_filesystem_for_external_drive__63__/comment_2_abb716dc8b39e1b20d8725d83a7cc662._comment b/doc/forum/__34__best__34___portable_filesystem_for_external_drive__63__/comment_2_abb716dc8b39e1b20d8725d83a7cc662._comment
new file mode 100644
index 0000000000..9cddcfaea7
--- /dev/null
+++ b/doc/forum/__34__best__34___portable_filesystem_for_external_drive__63__/comment_2_abb716dc8b39e1b20d8725d83a7cc662._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-13T16:52:30Z"
+ content="""
+Locking is not a concern. git-annex can lock files on a FAT
+filesystem as well as on any other. (Network filesystems tend to be the
+ones with problems with locking.) Lacking permissions do mean that a `rm -rf`
+is more likely to delete annex objects, but a removable drive has a real
+risk of accidentially being reformatted, or physically damaged, and you can
+untrust it if any of those risks are too large.
+
+I do think that a bare repo on a removable drive can work well,
+if the point of the drive is to sneakernet data back and forth, or offload
+storage. Keep your local clone on the best available filesystem the OS
+provides and work in there. Used in this way, FAT is no worse than S3.
+"""]]
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__.mdwn b/doc/forum/__34__du__34___equivalent_on_an_annex__63__.mdwn
new file mode 100644
index 0000000000..7485958c0b
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__.mdwn
@@ -0,0 +1,5 @@
+One reason to use git-annex is to save disk space by tossing files you don't use that often.
+
+I can find big files in the repository with git annex find --largerthan=100M, but is there a way to find large *directories*?  In an ordinary filesystem I'd use "du -h" with a maxdepth to get an idea of what parts of a directory are taking up my disk space, but obviously that won't work with git annex because all the content is in .git/annex.  Any ideas?
+
+(I can get a listing of file sizes in a directory with the handy -L flag of ls -- "ls -lL" shows me the sizes of the link targets -- but that won't summarize all the sizes of subdirectories.  Unless my ls-fu is just weak.)
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_10_a80eccce0bdb33748ab1ccba9b88a65f._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_10_a80eccce0bdb33748ab1ccba9b88a65f._comment
new file mode 100644
index 0000000000..1275a1d25a
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_10_a80eccce0bdb33748ab1ccba9b88a65f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="comment 10"
+ date="2020-06-26T20:29:26Z"
+ content="""
+... or even, more fancy:
+
+    git annex info --fast * --json | jq -j '.\"local annex size\", \"\t\", .directory, \"\t\", \"\n\"' | sort -h
+
+Downside: the json output doesn't give us something `sort` can really work with (it expects `M`, `G`, not `mebibytes`, `gibibytes`, which is arguably a bug...). But precision fanatics can also work around that with:
+
+    git annex info --fast * --json --bytes | jq -j '.\"local annex size\", \"\t\", .directory, \"\t\", \"\n\"' | sort -h
+
+Then you can go crazy trying to convert those numbers [back to something readable](https://unix.stackexchange.com/questions/346902/need-to-convert-bytes-to-gb-mb-kb-in-normal-decimal-format) in your own spare time... ;)
+"""]]
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_11_e3f82edf70d28f00d30cfd98f189cd86._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_11_e3f82edf70d28f00d30cfd98f189cd86._comment
new file mode 100644
index 0000000000..1c79810089
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_11_e3f82edf70d28f00d30cfd98f189cd86._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="wzhd"
+ avatar="http://cdn.libravatar.org/avatar/1795a91af84f4243a3bf0974bc8d79fe"
+ subject="Using fuse"
+ date="2022-05-14T03:10:18Z"
+ content="""
+Wrote a bare minimum [fuse fs](https://codeberg.org/wzhd/annexize/) so that du-like utilities like ncdu, gt5, gdu can be used.
+
+It reads each symlink target, try to get a number after `SHA256E-s`, and pretends it's regular file with that size. `git-annex add`ed files don't need to be locally available.
+
+Files can be deleted but no other operations are implemented.
+"""]]
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_12_041ae920e2e6fd83967dc98646452fa7._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_12_041ae920e2e6fd83967dc98646452fa7._comment
new file mode 100644
index 0000000000..bf3cbca594
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_12_041ae920e2e6fd83967dc98646452fa7._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="psxvoid"
+ avatar="http://cdn.libravatar.org/avatar/fde068fbdeabeea31e3be7aa9c55d84b"
+ subject="Using fuse annexize - works like a charm"
+ date="2024-01-07T04:11:37Z"
+ content="""
+Hey @wzhd,
+
+Thanks a lot for this tool - annexize works like a charm even in tags views!
+
+It's basically solve the most important problem for me:
+
+I can use ncdu for organizing files in my local git annex repository that
+does not contain any actual files (only file links), and then just sync
+with linked repos that do store those files.
+"""]]
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_1_a41bd02361aa961e5285aeaf1ea062be._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_1_a41bd02361aa961e5285aeaf1ea062be._comment
new file mode 100644
index 0000000000..0b69a41424
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_1_a41bd02361aa961e5285aeaf1ea062be._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://sunny256.sunbase.org/"
+ nickname="sunny256"
+ subject="comment 1"
+ date="2012-11-28T23:21:11Z"
+ content="""
+du(1) also accepts the -L option, so if you for example want to find what directories occupies most storage:
+
+    $ du -L | sort -n
+"""]]
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_2_28ba62a546f5cc8f416491423d743d8a._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_2_28ba62a546f5cc8f416491423d743d8a._comment
new file mode 100644
index 0000000000..019cb8b81c
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_2_28ba62a546f5cc8f416491423d743d8a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://sunny256.sunbase.org/"
+ nickname="sunny256"
+ subject="comment 2"
+ date="2012-11-28T23:24:11Z"
+ content="""
+And if you want to find the biggest files in a directory tree:
+
+    $ find -type l -print0 | xargs -0 du -L | sort -n | tail -500
+"""]]
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_3_8d97f40c1d14b7230f3656a00a99cf80._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_3_8d97f40c1d14b7230f3656a00a99cf80._comment
new file mode 100644
index 0000000000..0a11f7cc93
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_3_8d97f40c1d14b7230f3656a00a99cf80._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 3"
+ date="2012-11-29T02:03:24Z"
+ content="""
+Sweet!  I should have RTFM a bit more.  Thanks. :)
+"""]]
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_4_baa8fbbdd5c449a0dc2bb622cb4a47ce._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_4_baa8fbbdd5c449a0dc2bb622cb4a47ce._comment
new file mode 100644
index 0000000000..227c74b026
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_4_baa8fbbdd5c449a0dc2bb622cb4a47ce._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="comment 4"
+ date="2012-11-29T23:51:21Z"
+ content="""
+I've been thinking about writing a sort of git-annex du.  I'm surprised to find someone else looking for such a thing.  While \"du -L\" will tell you how much space is used by files you actually have, I was interested in knowing (approximately) how much space would be used if you were to git-annex get everything you don't yet have.
+
+There are many options and variations to think about, such as:
+
+* do you want to count duplicate files once or as many times as they appear (as if you 'git-annex lock'd them all)
+* maybe you want to know how much space is used by files that reside only on a certain remote or set of remotes
+* you might want to know how much space would be used by all the files you don't yet have, but not count the files you already have
+
+All of the backends so so far seem to store the size of the files in the filename, so my plan was to read it out of the links.  If anybody has a better idea about how to get the sizes of annexed files or options that would be handy for a git-annex du, let me know.  I'll see if I can get the start of something useful this weekend.  I'll post here when I have something to share.
+
+I'm also open to suggestions for the executable name.  Right now I'm thinking \"gadu\" for git-annex disk usage.
+"""]]
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_5_2ee6cbbfe54a2e7b6e8eb539c18e663d._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_5_2ee6cbbfe54a2e7b6e8eb539c18e663d._comment
new file mode 100644
index 0000000000..021614405d
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_5_2ee6cbbfe54a2e7b6e8eb539c18e663d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://sunny256.sunbase.org/"
+ nickname="sunny256"
+ subject="comment 5"
+ date="2012-11-30T00:29:44Z"
+ content="""
+Steve, that would be a very useful utility. I've been thinking of such a tool, but haven't gotten around to write it yet. It would be practical to have before copying big/many files from another drive. If I've been short of free space, I've executed `du -L` in the source directory, but that's a bit cumbersome.
+
+And \"gadu\" is a fine name, yes. Goes well along with my \"ga\" shortcut for \"git annex\", which I created two hours after I started using git-annex. I've probably saved thousands of keystrokes because of that. &#x263a;
+"""]]
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_6_48f6a2761a34b7f991325f1d24e2c5ff._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_6_48f6a2761a34b7f991325f1d24e2c5ff._comment
new file mode 100644
index 0000000000..1c456e24b3
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_6_48f6a2761a34b7f991325f1d24e2c5ff._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="gadu 0.01 is up"
+ date="2012-12-08T06:22:50Z"
+ content="""
+I've got an initial try at gadu up over at <http://git-annex.mysteryvortex.com/git-annex-utils.html>  I created a separate thread for it: <http://git-annex.branchable.com/forum/gadu_-_git-annex_disk_usage/>
+"""]]
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_7_d632baff41b8582f1a79bc5018c68545._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_7_d632baff41b8582f1a79bc5018c68545._comment
new file mode 100644
index 0000000000..6fa2659f93
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_7_d632baff41b8582f1a79bc5018c68545._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="Also try sizes"
+ date="2013-01-02T22:05:39Z"
+ content="""
+The \"sizes\" tool on Hackage is a git-annex aware du-like utility.  Just give it the \"-A\" flag to have it interpret annex symlinks as if they were normal files, and to also ignore files inside a .git/annex.
+"""]]
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_8_6a51c22d9893fa5b1503f5a14b1eb8ce._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_8_6a51c22d9893fa5b1503f5a14b1eb8ce._comment
new file mode 100644
index 0000000000..349c145cd5
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_8_6a51c22d9893fa5b1503f5a14b1eb8ce._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 8"
+ date="2015-03-31T03:11:06Z"
+ content="""
+i have used the [symlink patch of ncdu](http://dev.yorhel.nl/ncdu/bug/16) with good results here...
+"""]]
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_9_a2bda4c74ef09a58709c0c5f6ee1b726._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_9_a2bda4c74ef09a58709c0c5f6ee1b726._comment
new file mode 100644
index 0000000000..0e344a44d4
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_9_a2bda4c74ef09a58709c0c5f6ee1b726._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 9"
+ date="2015-06-24T21:40:07Z"
+ content="""
+... but nowadays, i use `git annex info --fast *`.
+"""]]
diff --git a/doc/forum/__34__git_add__34___vs___34__git_annex_add__34___in_v6.mdwn b/doc/forum/__34__git_add__34___vs___34__git_annex_add__34___in_v6.mdwn
new file mode 100644
index 0000000000..493344e52d
--- /dev/null
+++ b/doc/forum/__34__git_add__34___vs___34__git_annex_add__34___in_v6.mdwn
@@ -0,0 +1,5 @@
+Prior to v6, I used `git annex add` for files that should go into the annex, and `git add` for files that should be tracked in git normally.  With v6, `git add` silently adds to the annex instead, which surprised me because I didn't expect the file contents to still only reside only on the source computer after a push!  I don't have `annex.largefiles` set, but it seems like this is intended behavior.  Is there a way to return to v5 behavior for those two commands?  Is it safe to just remove the smudge/clean filter?  If so, is there a way to remove it in such a way that it propagates to all repositories?  (It's currently set in `.git/info/attributes`, which overrides `.gitattributes`).
+
+Having to come up a generic rule for `annex.largefiles` to cover all of my distinctions is difficult, and it's tedious to re-specify it for each new file.  I'd much rather just be able to continue using git as usual, and explicitly choose when to invoke git-annex.
+
+Jim
diff --git a/doc/forum/__34__git_add__34___vs___34__git_annex_add__34___in_v6/comment_1_285032a01ca754c539ce0634823db23c._comment b/doc/forum/__34__git_add__34___vs___34__git_annex_add__34___in_v6/comment_1_285032a01ca754c539ce0634823db23c._comment
new file mode 100644
index 0000000000..f27c0602ae
--- /dev/null
+++ b/doc/forum/__34__git_add__34___vs___34__git_annex_add__34___in_v6/comment_1_285032a01ca754c539ce0634823db23c._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-21T20:25:10Z"
+ content="""
+This is a documented behavior change in v6 mode. I'm willing to listen to
+arguments that the behavior change is a bad idea, but see below.
+
+To get the old behavior, you can use:
+
+	git -c 'annex.largefiles=exclude=*' add
+
+Unfortunately git won't let you alias git add to always pass that
+switch. But you could alias `git sadd` or something to use that switch.
+
+----
+
+The same behavior change also makes `git commit -a` use git-annex when file
+contents have changed, rather than the old hacky method which added the
+files to git and then undid that in a pre-commit hook. So there's quite a
+nice benefit there.
+
+And for that reason it doesn't make sense to add a configuration option to
+disable it, because such an option would break `git commit -a` of
+modified annexed files.
+
+Changing the gitattributes won't work because then the v6 repository won't
+get annexed files checked out properly.
+"""]]
diff --git a/doc/forum/__34__git_add__34___vs___34__git_annex_add__34___in_v6/comment_2_93eec60060bc7bca8dd1633b670f9a53._comment b/doc/forum/__34__git_add__34___vs___34__git_annex_add__34___in_v6/comment_2_93eec60060bc7bca8dd1633b670f9a53._comment
new file mode 100644
index 0000000000..721a1d0c1f
--- /dev/null
+++ b/doc/forum/__34__git_add__34___vs___34__git_annex_add__34___in_v6/comment_2_93eec60060bc7bca8dd1633b670f9a53._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 2"
+ date="2018-04-27T16:39:49Z"
+ content="""
+Is the `git annex -a` benefit one of performance?  I.e. the reason why the pre-commit hook approach was less good was that could be slower?
+"""]]
diff --git a/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4.mdwn b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4.mdwn
new file mode 100644
index 0000000000..c57a50c358
--- /dev/null
+++ b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4.mdwn
@@ -0,0 +1 @@
+As the title suggests, stopping the assistant through the terminal doesn't work as expected and I had to kill the assitant by hand, which in turn means, that git annex has to repair the repo. A workaround seems to be to start the assistant through "git annex webapp" and use the shutdown daemon button in the webapp. Before this workaround does work, you have to "git annex assistant --autostop" and restart, so that launchctl won't keep the daemon running.
diff --git a/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_1_34bd938e8cd0cba6ec48020932858485._comment b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_1_34bd938e8cd0cba6ec48020932858485._comment
new file mode 100644
index 0000000000..cb94b7225e
--- /dev/null
+++ b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_1_34bd938e8cd0cba6ec48020932858485._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 1"
+ date="2016-05-12T06:57:15Z"
+ content="""
+As it turns out, even this doesn't work hundred percent of the time, which is terrible! I rely on stoping the assistant once to at least three times a day to be able to skype without having to worry about my upload. My connection simply cannot handle both things at the same time. So what should I do?
+"""]]
diff --git a/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_2_3ec07e7f0e713e6fa925abb99c646bc7._comment b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_2_3ec07e7f0e713e6fa925abb99c646bc7._comment
new file mode 100644
index 0000000000..294c5042fd
--- /dev/null
+++ b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_2_3ec07e7f0e713e6fa925abb99c646bc7._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 2"
+ date="2016-05-12T07:49:33Z"
+ content="""
+I finally could reliably prevent git annex from fuzzinh with my skype sessions by using [little snitch](http://obdev.at/products/littlesnitch). I created a profile that prevents outgoing connections from git annex etc. and now I can leave git annex assistant running in the background. This is at the same time a good and a terrible solution, since I now need to run commercial software to prevent git annex from dictating how well my skype sessions are going and at the same time not relying on killing git annex processes by hand which in turn leads to git annex wanting repair itself all the time.
+"""]]
diff --git a/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_3_3dce000eb6db22e07ed2f53c4f62a1e0._comment b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_3_3dce000eb6db22e07ed2f53c4f62a1e0._comment
new file mode 100644
index 0000000000..8eaab758b3
--- /dev/null
+++ b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_3_3dce000eb6db22e07ed2f53c4f62a1e0._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-05-12T18:28:09Z"
+ content="""
+It seems to me that you could just click on "syncing enabled" in the
+webapp, to toggle it to "syncing disabled". This stops all data transfers
+without killing the program.
+
+The problem you describe with stopping doesn't quite make sense to me.
+
+For one things, `git annex assistant --autostop` does the exact same
+thing as changing directory into the repo and `git annex assistant --stop`.
+But, you seem to say that one works and the other doesn't.
+
+For another, `git annex assistant --stop` does exactly the same thing as
+killing the process by hand! That is, it sends it a TERM signal. 
+Perhaps you killed the process by hand with a stronger signal than TERM,
+but I don't see how even that would cause it to need to repair the repo.
+
+Why is launchd restarting the daemon when it exits?
+`~/Library/LaunchAgents/com.branchable.git-annex.assistant.plist`
+has RunAtLoad set, which AFAIK is supposed to make it run it once
+when you log in. It does not have KeepAlive set, so unless you've changed
+the configuration to include KeepAlive, I don't know why launchd would
+behave that way.
+"""]]
diff --git a/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_4_5bed42e467859d2310f3da35e55acd38._comment b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_4_5bed42e467859d2310f3da35e55acd38._comment
new file mode 100644
index 0000000000..2036ad6fff
--- /dev/null
+++ b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_4_5bed42e467859d2310f3da35e55acd38._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 4"
+ date="2016-05-14T13:24:06Z"
+ content="""
+I assume now that the problem is related to the [b2 special remote](https://github.com/encryptio/git-annex-remote-b2) which might be preventing git annex from shutting down. I don't know. What should I do and post here to help you triage this problem?
+"""]]
diff --git a/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_5_5cb379490b0e85c24bff48db8201c7d4._comment b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_5_5cb379490b0e85c24bff48db8201c7d4._comment
new file mode 100644
index 0000000000..2bf5237f04
--- /dev/null
+++ b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_5_5cb379490b0e85c24bff48db8201c7d4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-05-16T21:23:09Z"
+ content="""
+Why do you think that the b2 special remote is causing the problem?
+
+(Seems unlikely to me..)
+"""]]
diff --git a/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_6_46eb0f4dcbccea5140a26dca36c6f1d1._comment b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_6_46eb0f4dcbccea5140a26dca36c6f1d1._comment
new file mode 100644
index 0000000000..97caaaff46
--- /dev/null
+++ b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_6_46eb0f4dcbccea5140a26dca36c6f1d1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 6"
+ date="2016-05-16T23:11:34Z"
+ content="""
+I did assume so, because b2s process seems to be running when the assistant fails to shut down. But a new, maybe related problem might have come to light: I have/had a gitlab remote, that grew so big (30 gig) that they shut it down, in the sense that I can't access it anymore (even reading from it seems to have stoped working). I believe that this gitlab remote has some objects that aren't available anymore and git annex seems to try to repair stuff that is not repairable. As always: This is all said with a big \"maybe\", since I wouldn't know how to test my repo against that hypothesis. I have now done `git annex untrust gitlab` and will try if that helps. All this seem very mysterious to me, since I can't believe that I failed remote should prevent the repo to find an acceptable state.
+
+- git annex fsck states that there are 60 failed files (\"Only 1 of 2 trustworthy copies exist of…\" for all of them as far as I can see in the log)
+- git annex version 6.20160418  installed through homebrew
+- git annex repo version is 6
+"""]]
diff --git a/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory.mdwn b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory.mdwn
new file mode 100644
index 0000000000..ea0ad80ba8
--- /dev/null
+++ b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory.mdwn
@@ -0,0 +1,11 @@
+I tried to "git annex copy --to SSH-REMOTE" it says it sends it:
+copy Test (checking SSH-REMOTE...) (to SSH-REMOTE...) 
+SHA256E-s6--8283daccd02d2b2797da53446d367e39dc0fb1615bcae4274460f44455bd9822
+           6 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/1)
+
+sent 146 bytes  received 31 bytes  354.00 bytes/sec
+total size is 6  speedup is 0.03
+ok
+(Recording state in git...)
+
+But I can't find it in the working directory. Can anyone help me?
diff --git a/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_1_0c0a5999a92bf5880f2113177dc67cc2._comment b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_1_0c0a5999a92bf5880f2113177dc67cc2._comment
new file mode 100644
index 0000000000..18c41f1c97
--- /dev/null
+++ b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_1_0c0a5999a92bf5880f2113177dc67cc2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://www.rfc1149.net/"
+ nickname="Sam"
+ subject="comment 1"
+ date="2013-08-05T09:49:56Z"
+ content="""
+`git annex copy` will only push objects (content) into git annex private directory. You have to issue a `git annex merge` (or `git annex sync`) on the receiving end, or run `git annex assistant` there to update the working directory.
+
+Note that you can run `git annex merge` as a post-update hook if you want this to be done automatically.
+
+"""]]
diff --git a/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_2_c18083d9054f66f0bd51d63452af07eb._comment b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_2_c18083d9054f66f0bd51d63452af07eb._comment
new file mode 100644
index 0000000000..da0a869298
--- /dev/null
+++ b/doc/forum/__34__git_annex_copy_--to___60__REMOTE__62___.__34___doesn__39__t_send_it_to_working_directory/comment_2_c18083d9054f66f0bd51d63452af07eb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqaNwDQ367zpW6cIRviLz6zJZZFODgoEI"
+ nickname="Zack"
+ subject="It worked!"
+ date="2013-08-05T09:57:25Z"
+ content="""
+Thanks for the help, it worked.
+"""]]
diff --git a/doc/forum/__34__git_annex_drop__34___freezes_while___34__locking_origin...__34__.mdwn b/doc/forum/__34__git_annex_drop__34___freezes_while___34__locking_origin...__34__.mdwn
new file mode 100644
index 0000000000..b4e9b087df
--- /dev/null
+++ b/doc/forum/__34__git_annex_drop__34___freezes_while___34__locking_origin...__34__.mdwn
@@ -0,0 +1,12 @@
+Hi,
+
+I am using git annex 5.20151208-1build1 on my local machine and 5.20151208-g5ef6ed8 on "origin". I can not drop files anymore. "git annex sync --content" has the same problem when it tries to drop files:
+
+    $ git annex drop xyz
+    drop xyz (locking origin...)   <--  waits here for ever
+
+    $ git annex sync --content
+    [git annex is pulling and merging stuff]
+    drop xyz (locking origin...)   <--  waits here for ever
+
+What can I do? Thanks!
diff --git a/doc/forum/__34__git_annex_drop__34___freezes_while___34__locking_origin...__34__/comment_1_09fbe4362fea8f2a53a1f955b0519019._comment b/doc/forum/__34__git_annex_drop__34___freezes_while___34__locking_origin...__34__/comment_1_09fbe4362fea8f2a53a1f955b0519019._comment
new file mode 100644
index 0000000000..cfe473562b
--- /dev/null
+++ b/doc/forum/__34__git_annex_drop__34___freezes_while___34__locking_origin...__34__/comment_1_09fbe4362fea8f2a53a1f955b0519019._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-05T19:43:23Z"
+ content="""
+You're using a version of git-annex that is nearly 2 years old.
+Upgrading to a new version should be the very first thing you try in such a situation..
+
+Sounds like probably this changelog entry is relevant, from version 
+6.20160418.
+
+  * Fix hang when dropping content needs to lock the content on a
+    ssh remote, which occurred when the remote has git-annex version
+    5.20151019 or newer. (The bug was in the client side; the remote
+    git-annex-shell does not need to be upgraded.)
+
+And it appears that hang first appeared in git-annex version 5.20151009.
+"""]]
diff --git a/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error.mdwn b/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error.mdwn
new file mode 100644
index 0000000000..5fb7492bad
--- /dev/null
+++ b/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error.mdwn
@@ -0,0 +1,20 @@
+I tried cloning an annex repo between two drives "c:" and "d:". The part with "git clone" itself works, but when I try to execute "git annex get", rsync reports an error about a missing path starting with "/cygdrive".
+
+    Sameer@DESKTOP-6CJGO0T MINGW32 /d/a (annex/direct/master)
+    $ git annex get --not --in here
+    get world.txt (from origin...)
+    rsync: change_dir "/cygdrive/c/scratch/a" failed: No such file or directory (2)
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]
+    
+      rsync failed -- run git annex again to resume file transfer
+    
+      Unable to access these remotes: origin
+    
+      Try making some of these repositories available:
+            cda3a2c6-7ddc-4164-ad6d-fbb2720b24d7 -- DESKTOP-6CJGO0T:C:\scratch\a [origin]
+    failed
+    git-annex: get: 1 failed
+
+I am running git annex that was installed in the same directory as a 32-bit git version 2.6.4 for windows (mingw32).
+
+The question is, my windows drives are actually visible as "/c" and "/a" ... then why is rsync searching for "/cygdrive/c" etc? This is clearly not a Cygwin installation.
diff --git a/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_1_a1a881d7b0f0c32b1bfdd3bc5ee4dd18._comment b/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_1_a1a881d7b0f0c32b1bfdd3bc5ee4dd18._comment
new file mode 100644
index 0000000000..95bb2d6020
--- /dev/null
+++ b/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_1_a1a881d7b0f0c32b1bfdd3bc5ee4dd18._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="sameerds"
+ subject="bump!"
+ date="2016-01-08T07:31:18Z"
+ content="""
+Am I the only one seeing this? :(
+"""]]
diff --git a/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_3_50d0b68fcf0e239037a5d7950595b1d6._comment b/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_3_50d0b68fcf0e239037a5d7950595b1d6._comment
new file mode 100644
index 0000000000..f9a003ced7
--- /dev/null
+++ b/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_3_50d0b68fcf0e239037a5d7950595b1d6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="pkitslaar"
+ subject="Same here"
+ date="2016-01-10T07:50:14Z"
+ content="""
+I have the same issue.
+
+git-annex version: 6.20160108-ge94ef9b
+"""]]
diff --git a/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_3_9bc58c6c2333655870c5e42138f9749e._comment b/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_3_9bc58c6c2333655870c5e42138f9749e._comment
new file mode 100644
index 0000000000..55d0699fe8
--- /dev/null
+++ b/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_3_9bc58c6c2333655870c5e42138f9749e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="pkitslaar"
+ subject="Possible fix for rsync windows paths"
+ date="2016-01-11T10:25:22Z"
+ content="""
+I looked at the code that creates the paths for the rsync command on Windows.
+And it is using Cygwin style paths. However, the rsync version that is bundled with
+git-annex on Windows is taken from the MSYS2 distribution. This uses different path
+convention for drive letters (simply `/c` and `/d` for `C:\` and `D:\` etc..)
+
+I created a quick fix by adding a toMSYS2Path function and using that for rsync on Windows.
+I fix can be found here: <https://github.com/pkitslaar/git-annex/commit/6cd134ade1cf5b03259d04779e2767a07a2f6014>
+
+For me this works when I locally build git-annex and I can now \"get\" files from repositories on another drive.
+"""]]
diff --git a/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_4_958e887dd83b8b636df2d81ade0dbbf1._comment b/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_4_958e887dd83b8b636df2d81ade0dbbf1._comment
new file mode 100644
index 0000000000..a345023215
--- /dev/null
+++ b/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_4_958e887dd83b8b636df2d81ade0dbbf1._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="sameerds"
+ subject="cygwin/msys-independent fix?"
+ date="2016-01-12T04:07:39Z"
+ content="""
+Thank you, pkitslaar, for working this out! I will try it out ASAP and provide feedback. But generally, why can we not create Windows-style paths, and then rely on the underlying platform to do the right thing? I would expect that \"rsync\" or any other binary will accept \"C:\scratch\a\" as a valid path, and then translate it appropriately for its own host such as cygwin or msys. \"Clients\" of these binaries should not have to worry about such things.
+"""]]
diff --git a/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_5_24782f9b1012a2935466ac358acea97b._comment b/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_5_24782f9b1012a2935466ac358acea97b._comment
new file mode 100644
index 0000000000..d5d6f10993
--- /dev/null
+++ b/doc/forum/__34__git_annex_get__34___on_windows_fails_with_rsync_error/comment_5_24782f9b1012a2935466ac358acea97b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-01-13T16:29:42Z"
+ content="""
+rsync thinks that "C:foo" is the file foo on host C. This makes it not
+usable cross-drive on windows without some hack.
+
+So, this hack broke when the bundled rsync build was changed from the cygwin
+build to the msys build. I'll apply pkitslaar's patch.
+"""]]
diff --git a/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo.mdwn b/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo.mdwn
new file mode 100644
index 0000000000..9bacf28dc0
--- /dev/null
+++ b/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo.mdwn
@@ -0,0 +1,7 @@
+I found the command "git annex lock" very slow (much slower than the initial "git annex add" with SHA1), for a not so big directory, when run in a big repo.
+It seems that each underlying git command is not fast, so I thought it would be better to run them once with all files as arguments.
+I had to stop the lock command, and ran "git checkout ." (I did not change any file), is this a correct alternative?
+
+Thanks a LOT for this software, one that I missed since a long time (but wasn't able to write)!
+
+Rafaël
diff --git a/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_1_044f1c5e5f7a939315c28087495a8ba8._comment b/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_1_044f1c5e5f7a939315c28087495a8ba8._comment
new file mode 100644
index 0000000000..0e2773bda3
--- /dev/null
+++ b/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_1_044f1c5e5f7a939315c28087495a8ba8._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="fixed"
+ date="2011-05-31T18:51:13Z"
+ content="""
+Running `git checkout` by hand is fine, of course.
+
+Underlying problem is that git has some O(N) scalability of operations on the index with regards to the number of files in the repo. So a repo with a whole lot of files will have a big index, and any operation that changes the index, like the `git reset` this needs to do, has to read in the entire index, and write out a new, modified version. It seems that git could be much smarter about its index data structures here, but I confess I don't understand the index's data structures at all. I hope someone takes it on, as git's scalability to number of files in the repo is becoming a new pain point, now that scalability to large files is \"solved\". ;)
+
+Still, it is possible to speed this up at git-annex's level. Rather than doing a `git reset` followed by a git checkout, it can just `git checkout HEAD -- file`, and since that's one command, it can then be fed into the queueing machinery in git-annex (that exists mostly to work around this git malfescence), and so only a single git command will need to be run to lock multiple files.
+
+I've just implemented the above. In my music repo, this changed an lock of a CD's worth of files from taking ctrl-c long to 1.75 seconds. Enjoy!
+
+(Hey, this even speeds up the one file case greatly, since `git reset -- file` is slooooow -- it seems to scan the *entire* repository tree. Yipes.)
+"""]]
diff --git a/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_2_e854b93415d5ab80eda8e3be3b145ec2._comment b/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_2_e854b93415d5ab80eda8e3be3b145ec2._comment
new file mode 100644
index 0000000000..9e9e778ce9
--- /dev/null
+++ b/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_2_e854b93415d5ab80eda8e3be3b145ec2._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"
+ nickname="Rafaël"
+ subject="comment 2"
+ date="2011-05-31T21:43:22Z"
+ content="""
+Nice!
+So if I understand correctly, 'git reset -- file' was there to discard staged (but not commited) changes made to 'file', before checking out, so that it is equivalent to directly 'git checkout HEAD -- file' ?
+I'm curious about the \"queueing machinery in git-annex\": does it end up calling the one git command with multiple files as arguments? does it correspond to the message \"(Recording state in git...)\" ?
+Thanks!
+
+
+"""]]
diff --git a/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_3_95c110500bc54013bc1969c1a9c8f842._comment b/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_3_95c110500bc54013bc1969c1a9c8f842._comment
new file mode 100644
index 0000000000..87da0c396d
--- /dev/null
+++ b/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_3_95c110500bc54013bc1969c1a9c8f842._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-05-31T21:54:23Z"
+ content="""
+@Rafaël , you're correct on all counts.
+"""]]
diff --git a/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_4_a4fd212cb066cd53d0d66eb09f3b39a8._comment b/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_4_a4fd212cb066cd53d0d66eb09f3b39a8._comment
new file mode 100644
index 0000000000..ecb5ba913b
--- /dev/null
+++ b/doc/forum/__34__git_annex_lock__34___very_slow_for_big_repo/comment_4_a4fd212cb066cd53d0d66eb09f3b39a8._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="josch"
+ ip="2001:638:709:5:2ad2:44ff:fe4b:56aa"
+ subject="thanks a lot!"
+ date="2014-06-23T15:13:34Z"
+ content="""
+Thank you for the answer to this problem!
+
+I put 150k emails in maildir format in git annex. Adding them took a couple of hours and so did the first full sync. But after that things didnt noticibly slow down - that was a surprise!
+
+What but then I wanted to do a one-time sync using rsync. I didnt find out how to tell rsync to follow symlinks at the destination instead of replacing symlinks with normal files. So I first unlocked the 150k emails (which was moderately quick and probably only I/O bound) and then did the rsync using the --checksum option which worked well as well. The problems started when I wanted to lock the whole thing again. This took ages and even after two days it did not output that it was adding files at all. So I used `find -type f | split -a3 -l100` and then `for f in x*; do echo $f; git annex add `echo \`cat $f\``; rm $f; done`. This started off well and I could finally see files being added. Unfortunately when I came back after a couple of hours, the progress slowed down to a crawl of only one file every few seconds.
+
+The solution was to just `git checkout -- Mail` everything. This finished in a matter of seconds and left the new mail which was copied over by rsync intact.
+
+Thanks a lot for the tip!
+
+Let me hereby also report that git annex seems to work without problems when using it with offlineimap and notmuch. At least I did not run into any problems with that setup yet.
+"""]]
diff --git a/doc/forum/__34__git_annex_sync_--content__34___with_special_remote_of_type___34__directory__34__.mdwn b/doc/forum/__34__git_annex_sync_--content__34___with_special_remote_of_type___34__directory__34__.mdwn
new file mode 100644
index 0000000000..bab3167e5e
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync_--content__34___with_special_remote_of_type___34__directory__34__.mdwn
@@ -0,0 +1,17 @@
+Hello, I started using the "wanted" feature of git-annex.
+
+I have (besides others) one local repository ("neon"), and two special remotes "ldk" (rsync) and "storage" (directory).
+
+"wanted" and "group" are configured as (replaced UUIDs with names):
+
+    group "storage" = backup
+    wanted "storage" = standard
+    wanted "neon" = (exclude=pictures/* and exclude=video/*) or present
+
+Now, let's assume there is a file named "video/foo.mp4". It is only present in "ldk". I want it to be present in "storage", too.
+
+When I run "git annex sync --content" on "neon" the file "video/foo.mp4" is neither fetched to be placed in "neon" nor in "storage".
+
+Which command do I have to run to transfer the file "video/foo.mp4" from "ldk" to "storage" when run from "neon".
+
+Previously, I started with "git annex get \`git annex find --not --in storage\`" and then continued with "git annex copy \`git annex find --not --in storage\` --to storage". I was hoping that the wanted feature would simplify this.
diff --git a/doc/forum/__34__git_annex_sync_--content__34___with_special_remote_of_type___34__directory__34__/comment_1_c51363e109bcc5cd1df40c5d0ec993b3._comment b/doc/forum/__34__git_annex_sync_--content__34___with_special_remote_of_type___34__directory__34__/comment_1_c51363e109bcc5cd1df40c5d0ec993b3._comment
new file mode 100644
index 0000000000..b7d538ae9b
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync_--content__34___with_special_remote_of_type___34__directory__34__/comment_1_c51363e109bcc5cd1df40c5d0ec993b3._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-21T20:01:26Z"
+ content="""
+What's going on here is that git-annex does not know that you want to
+use "neon" as a repository that transfers content between "ldk" and
+"storage". The configuration for "neon" only makes it want a specific
+set of files, so it doesn't get other files from "ldk", and so does
+not have them to send to "storage".
+
+The solution is to change "neon"'s preferred content settings so it wants
+files that are not yet present in "storage".
+
+The [[transfer repository expression|preferred_content/standard_groups]]
+is one way to configure preferred content settings so that a repo
+will want to download files that other repos want to have. 
+
+	not (inallgroup=client and copies=client:2) and ($client)
+
+But that expression only works for transfer repsitories in between client
+repositories. Your "storage" repo is set to be a backup repository.
+
+So, we need something a little bit different.
+
+	not inallgroup=backup and include=*
+
+I think that would work, but I don't see a way to reconcile it with
+the configuration you already have for "neon". If neon wants to
+"exclude=pictures/* and exclude=video/*" then it will never get those
+and so can never send them on to "storage". And if neon wants all
+"present" files, then anything it does get for whatever reason
+will stay in it, which is just not how a transfer repo needs to work.
+
+What might work better is to set up a separate repository that can talk
+to "ldk" and "storage" (as well as perhaps pulling files from "neon"
+when available), and make it have that preferred content expression.
+"""]]
diff --git a/doc/forum/__34__git_annex_sync_--content__34___with_special_remote_of_type___34__directory__34__/comment_2_be52a6d21df4732c9f83463bb5e6f612._comment b/doc/forum/__34__git_annex_sync_--content__34___with_special_remote_of_type___34__directory__34__/comment_2_be52a6d21df4732c9f83463bb5e6f612._comment
new file mode 100644
index 0000000000..c2566bf60f
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync_--content__34___with_special_remote_of_type___34__directory__34__/comment_2_be52a6d21df4732c9f83463bb5e6f612._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/wS4b1K9kooKjDS5nqjBuZsN4Czwko0ECcg--#2eff3"
+ nickname="Markus"
+ subject="comment 2"
+ date="2015-04-22T10:47:26Z"
+ content="""
+Thank you. I settled on using `present or (not inallgroup=backup) or (exclude=pictures/* and exclude=video/*)`, which seems to be doing what I want. The most important thing to me is that files are transferred to the backup group. Some files might be left in pictures/ or video/ on \"neon\", but I can drop those from time to time if disk space is low.
+"""]]
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours.mdwn b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours.mdwn
new file mode 100644
index 0000000000..2804828f59
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours.mdwn
@@ -0,0 +1,40 @@
+Hi,
+
+The git annex seem has problem with many files.
+
+For synchronize, the operation lasts 8 hours. Here the sample for synchronizing to my local remote server (sbackup)
+
+start at **20:12** / end at **04:13** / total time = ~ **8 hours**
+
+    git annex sync sbackup
+    
+    [2015-04-13 20:12:26 CEST] call: git ["--git-dir=.git","--work-tree=.","push","sbackup","+git-annex:synced/git-annex","master:synced/master"]
+    Counting objects: 792155, done.
+    Delta compression using up to 4 threads.
+    Compressing objects: 100% (789727/789727), done.
+    Writing objects: 100% (792155/792155), 75.73 MiB | 2.35 MiB/s, done.
+    Total 792155 (delta 449604), reused 1 (delta 0)
+    To partage@192.168.253.53:/data/samba/git-annex/docshare
+      ae182f0..fad3aca  git-annex -> synced/git-annex
+      e0e67fe..5226a6f  master -> synced/master
+    [2015-04-14 04:13:05 CEST] read: git ["--git-dir=.git","--work-tree=.","push","sbackup","git-annex","master"]
+    ok
+
+Another problem, I do not know exactly how many files I own (i use **find . | wc -l** )
+
+.git = 1250633
+
+documents = 61124
+
+medias = 199504
+
+it seem i own ~250000 files, but in the .git **1.2 millions files**.
+
+The following command also very slow
+
+    git annex info
+
+
+What the best pratices for use git annex with many files > 500 000 or maintenance & reduction/cleaning method
+
+Thanks
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_1_e815ac48a17cc4296473d61e712d95e0._comment b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_1_e815ac48a17cc4296473d61e712d95e0._comment
new file mode 100644
index 0000000000..4cc665e044
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_1_e815ac48a17cc4296473d61e712d95e0._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2015-04-14T08:40:33Z"
+ content="""
+If you want a file count:
+
+    git annex find | wc -l
+
+is probably the best measure.
+
+I have an annex with about several million files in it and it is slow, but not as slow as you are describing. Have you done a repack/gc cycle?
+"""]]
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_2_d13a0af48b8831c81276a0b2c8e25303._comment b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_2_d13a0af48b8831c81276a0b2c8e25303._comment
new file mode 100644
index 0000000000..940922e6c2
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_2_d13a0af48b8831c81276a0b2c8e25303._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlXt6nnNs-3uw61EGYtxr_AVhJqXybwLR8"
+ nickname="Bruno"
+ subject="comment 2"
+ date="2015-04-15T17:51:18Z"
+ content="""
+@CandyAngel Thank you for your **git annex find** tips. But for git gc, it seem not working fine :)
+After i have executed the **git gc**, the **git annex info** return the result after **1h 45m**
+
+    % time git annex info
+    repository mode: indirect
+    trusted repositories: 0
+    semitrusted repositories: 5
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	181d4dae-2131-435e-9c00-b8c7f1bfc332 -- [sbackup]
+ 	2db1f8e7-0b29-4d61-8875-a4a4a42a79dd -- [dellcomputer]
+ 	703df355-73a6-4487-97fd-a3a5d6ae034e -- usbhomebackup [here]
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: 135.24 gigabytes (+1 megabyte reserved)
+    local annex keys: 275416
+    local annex size: 780.55 gigabytes
+    annexed files in working tree: 265888
+    size of annexed files in working tree: 751.49 gigabytes
+    bloom filter size: 16 mebibytes (55.1% full)
+    backend usage: 
+	SHA256E: 541304
+
+git annex info  83,95s user 50,68s system 2% **cpu 1:45:01,70 total**
+
+
+Can you explain exactly the git gc or git repack parameters that you use for optimizing git annex performance  ?
+
+Thanks
+
+"""]]
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_3_c50b62e5a84b861117a4405c2a2f5cfb._comment b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_3_c50b62e5a84b861117a4405c2a2f5cfb._comment
new file mode 100644
index 0000000000..20031b9529
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_3_c50b62e5a84b861117a4405c2a2f5cfb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 3"
+ date="2015-04-16T07:41:07Z"
+ content="""
+*git annex info* has check every file (not sure if it traverses *.git/annex/objects* specifically or not) to get \"local annex\" information. You can improve its performance by improving directory traversal in general (different filesystem or [changing the hashing method so it isn't Xx/Yy/KEY/FILE](https://github.com/datalad/datalad/issues/32)).
+
+The repack/gc speeds up operations for the git side of things, like syncing (pull/push), cloning and committing.
+
+Here's what I used:
+
+    git repack -ad
+    git gc
+
+This took git actions down from 1 hour+ to ~10 minutes (for a repo with 5.6 million objects).
+"""]]
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_4_0051e83196945b97e2f3ed14a58daaea._comment b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_4_0051e83196945b97e2f3ed14a58daaea._comment
new file mode 100644
index 0000000000..2fc762f77b
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_4_0051e83196945b97e2f3ed14a58daaea._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlXt6nnNs-3uw61EGYtxr_AVhJqXybwLR8"
+ nickname="Bruno"
+ subject="comment 4"
+ date="2015-04-16T11:47:50Z"
+ content="""
+Thanks @CandyAngle, 
+
+Effectively, your tips for reduce a time for some git-annex commands if works fine, i will see in the long term if that is work perfectly
+
+ex:, now **git annex sync** it work in **45s** ! :)
+
+Thanks
+"""]]
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_5_26de32ea240621e23717c55866ad9764._comment b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_5_26de32ea240621e23717c55866ad9764._comment
new file mode 100644
index 0000000000..907f32b940
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_5_26de32ea240621e23717c55866ad9764._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 5"
+ date="2015-04-16T21:08:32Z"
+ content="""
+My pleasure, glad it is working for you!
+
+Going forward, you should run *git repack* (without -ad) every now and again to pack new objects into pack files. You can use *git count-objects -v* to find out how many unpacked objects you have.
+"""]]
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_6_0714eca58513f1059fc246ee152078e7._comment b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_6_0714eca58513f1059fc246ee152078e7._comment
new file mode 100644
index 0000000000..fbf7265ffb
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_6_0714eca58513f1059fc246ee152078e7._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="candyangel@7b9260fff42e1f6f552e1348007f7409a9101e82"
+ nickname="candyangel"
+ subject="comment 6"
+ date="2015-05-20T14:14:32Z"
+ content="""
+I've just come across something else which has sped up git operations on the index a *lot*.
+
+My $annex/.git/index was over 500M which made operations on the index really slow (git add/rm etc.) as it gets rewritten out in its entirety, every time!
+
+    git update-index --index-version 4
+
+brought it down to 200M, making everything much, much faster!
+
+[There is a warning in the git documentation](http://git-scm.com/docs/git-update-index) that alternative git implementations might not understand it, so bear that in mind if you want to use it.
+"""]]
diff --git a/doc/forum/__34__git_annex_unused__34___doesn__39__t_find_unused_files_after_git_history_was_rewritten.mdwn b/doc/forum/__34__git_annex_unused__34___doesn__39__t_find_unused_files_after_git_history_was_rewritten.mdwn
new file mode 100644
index 0000000000..cbf9770c33
--- /dev/null
+++ b/doc/forum/__34__git_annex_unused__34___doesn__39__t_find_unused_files_after_git_history_was_rewritten.mdwn
@@ -0,0 +1,17 @@
+Hi,
+
+I recently cleaned my git history using:
+
+    git filter-branch --tree-filter 'rm -rf personal/Mail' --prune-empty HEAD
+    git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d
+    git gc
+
+I then ran:
+
+    git annex unused
+
+But was surprised to find that it didn't report any unused files. Not surprisingly (given that I didn't touch the annex data at all so far), when looking into `.git/annex/objects/` I still find the content of all the files that are now not used anymore.
+
+Is there a way to clean these up besides creating a fresh clone of the repository?
+
+Thanks!
diff --git a/doc/forum/__34__git_annex_unused__34___doesn__39__t_find_unused_files_after_git_history_was_rewritten/comment_1_8f2ced0b9039968f485943e1525dcf6e._comment b/doc/forum/__34__git_annex_unused__34___doesn__39__t_find_unused_files_after_git_history_was_rewritten/comment_1_8f2ced0b9039968f485943e1525dcf6e._comment
new file mode 100644
index 0000000000..b07cab8e2f
--- /dev/null
+++ b/doc/forum/__34__git_annex_unused__34___doesn__39__t_find_unused_files_after_git_history_was_rewritten/comment_1_8f2ced0b9039968f485943e1525dcf6e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-05T20:16:04Z"
+ content="""
+`git-annex unused` looks at all local branches, and all remote branches.
+If you only filter-branched a single branch, you could well have other
+branches that still refer to those files, so they would not be considered
+unused.
+"""]]
diff --git a/doc/forum/__34__next_time_Im_online_I_would_like_to_have_file_x_y_z__34__.mdwn b/doc/forum/__34__next_time_Im_online_I_would_like_to_have_file_x_y_z__34__.mdwn
new file mode 100644
index 0000000000..a5492dc861
--- /dev/null
+++ b/doc/forum/__34__next_time_Im_online_I_would_like_to_have_file_x_y_z__34__.mdwn
@@ -0,0 +1,5 @@
+git-annex is seriously cool, however I havent figured out an important detail:
+in the short presentation Richard Hartmann mentions the Nomad use case and says "... next time Im online I would like to have file x y z ... "
+How can this be achieved exactly? If I do a git annex copy/get then it will want to do it instantly, not queuing it.
+thanks a lot!
+Aron
diff --git a/doc/forum/__34__next_time_Im_online_I_would_like_to_have_file_x_y_z__34__/comment_1_bfeb1446dee4d2f52ef25fabfb8cc8f6._comment b/doc/forum/__34__next_time_Im_online_I_would_like_to_have_file_x_y_z__34__/comment_1_bfeb1446dee4d2f52ef25fabfb8cc8f6._comment
new file mode 100644
index 0000000000..0789316dc7
--- /dev/null
+++ b/doc/forum/__34__next_time_Im_online_I_would_like_to_have_file_x_y_z__34__/comment_1_bfeb1446dee4d2f52ef25fabfb8cc8f6._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2012-07-19T14:41:39Z"
+ content="""
+What I do for this is maintain a `todo` directory and `cp -a` + `git annex add` files I want to download into this directory.
+the `cp -a` maintains the symlinks and `git annex add` fixes them if needed.
+
+Also this works the same way if the situation is reversed and the machine you want to download the files onto is not online.  You can add files to the `todo` directory on the server, then once the client machine is online do a `git annex sync` + `git annex get todo`.
+"""]]
diff --git a/doc/forum/__34__next_time_Im_online_I_would_like_to_have_file_x_y_z__34__/comment_2_e60f2bbc1c058993472fd920edbc75fc._comment b/doc/forum/__34__next_time_Im_online_I_would_like_to_have_file_x_y_z__34__/comment_2_e60f2bbc1c058993472fd920edbc75fc._comment
new file mode 100644
index 0000000000..b0a8066ee8
--- /dev/null
+++ b/doc/forum/__34__next_time_Im_online_I_would_like_to_have_file_x_y_z__34__/comment_2_e60f2bbc1c058993472fd920edbc75fc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnbBRfl5F8gKRr1ko8Ai6FbEZStXXNF1S4"
+ nickname="Áron"
+ subject="comment 2"
+ date="2012-07-19T22:41:53Z"
+ content="""
+hmm not bad workaround but still not very comfortable, thanks though.
+"""]]
diff --git a/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo.mdwn b/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo.mdwn
new file mode 100644
index 0000000000..f13aed2c2f
--- /dev/null
+++ b/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo.mdwn
@@ -0,0 +1,17 @@
+i'm getting errors in ``git annex fsck`` on a shared bare git repo with git-annex 3.20120418 local repo version 3:
+
+``git-annex: ${PATH}/${MYREPO}.git/annex/objects/${HA}/${SH}/SHA1-${HASH}/SHA1-${HASH}: setFileMode: permission denied (Operation not permitted)``
+
+the repository is shared among several users in a common group, and the repo is set up with sticky group, and with appropriate umasks, everything should work.
+
+however, even with the file having permissions -rw-rw-r-- in the directory with permissions drwxrwsr-x, owned by someone else but by a group i'm currently in (as verified by issuing `groups`), i get said error message.
+
+a strace reveals that the failing syscall is:
+
+``[pid 17626] chmod("${FILENAME}", 0100555) = -1 EPERM (Operation not permitted)``
+
+(maybe related: git annex looks for the file in another ${HA}/${SH} combination (of three digits instead of two digits each) before, i take it this is just a new feature not used by the data in my repo? also, i should add that the repository dates back to git-annex 0.13.)
+
+as a workaround, i'm currently ``sudo chown``ing all files to me before the check.
+
+why does fsck try to set permissions even if they are ok? is this a bug in my setup, and if yes, how is a shared repository set up correctly?
diff --git a/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_1_3a5202ef2116ebb5559b6f4d920755fc._comment b/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_1_3a5202ef2116ebb5559b6f4d920755fc._comment
new file mode 100644
index 0000000000..5a5cafa721
--- /dev/null
+++ b/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_1_3a5202ef2116ebb5559b6f4d920755fc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-04-21T16:09:19Z"
+ content="""
+Well, the modes you show are wrong. Nothing in the annex should be writable. fsck needs to fix those. (It's true that it also always chmods even correct mode files/directories.. I've made a change avoiding that.)
+
+I have not thought or tried shared git annex repos with multiple unix users writing to them. ([[tips/Using_gitolite_with_git-annex]] would be an alternative.) Seems to me that removing content from the annex would also be a problem, since the directory will need to be chmodded to allow deleting the content from it, and that will fail if it's owned by someone else.  Perhaps git-annex needs to honor core.sharedRepository and avoid these nice safeguards on file modes then.
+"""]]
diff --git a/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_2_86663eeb75b0477f53c45f26c8e4b051._comment b/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_2_86663eeb75b0477f53c45f26c8e4b051._comment
new file mode 100644
index 0000000000..1c9bfbfe40
--- /dev/null
+++ b/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_2_86663eeb75b0477f53c45f26c8e4b051._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2012-04-21T23:46:42Z"
+ content="""
+All right, I've made all the changes so it supports `core.sharedRepository`.
+"""]]
diff --git a/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_3_c336b2b07cd006d378e5be9639ff17ec._comment b/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_3_c336b2b07cd006d378e5be9639ff17ec._comment
new file mode 100644
index 0000000000..fd75f2f856
--- /dev/null
+++ b/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_3_c336b2b07cd006d378e5be9639ff17ec._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="comment 3"
+ date="2012-04-23T14:14:28Z"
+ content="""
+thanks, that's great. will there be a way to have sharedRepository work for shared remotes (rsync, directory) too, or is that better taken care of by acls?
+
+@not thought of shared repos: we're having our family photo archive spread over our laptops, and backed up on our home storage server and on an rsync+encryption off-site server, with everyone naturally having their own accounts on all systems -- just if you need a use case.
+"""]]
diff --git a/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_4_1339cd27ca2955f30b01ecf4da7d6fe8._comment b/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_4_1339cd27ca2955f30b01ecf4da7d6fe8._comment
new file mode 100644
index 0000000000..568f11330c
--- /dev/null
+++ b/doc/forum/__34__permission_denied__34___in_fsck_on_shared_repo/comment_4_1339cd27ca2955f30b01ecf4da7d6fe8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 4"
+ date="2012-04-23T14:35:39Z"
+ content="""
+I'm not currently planning to support sharedRepository perms on special remotes. I suppose I could be convinced otherwise, it's perhaps doable for the ones you mention (rsync might be tricky). (bup special remote already supports it of course.)
+
+thanks for the use case!
+"""]]
diff --git a/doc/forum/__34__recovering__34___from_git-annex_usage.mdwn b/doc/forum/__34__recovering__34___from_git-annex_usage.mdwn
new file mode 100644
index 0000000000..916fbb669a
--- /dev/null
+++ b/doc/forum/__34__recovering__34___from_git-annex_usage.mdwn
@@ -0,0 +1,24 @@
+# Past Usage of git-annex
+
+I used to have git(-annex) repositories for different projects and data types...
+so I managed all my images in one repository, movies in an other and so on.
+At some point I had an central Server an moved files to that remote.
+
+So far so easy and good.
+
+# Current Situation
+
+Then there was the time, that I killed my central Server,
+and "lost" access to my files I moved there
+and "lost" also the synchronization path between my laptop and my desktop pc
+
+I have a backup of these remotes (scped to a external hdd), but currently have no
+clue how I teach my local repository that the central Server remote is now
+just a local hdd remote.
+
+Probably I am just confused how I handeled git-annex till now
+
+What would be a best practice to teach an repository that an remote has moved its location?
+And maybe recover my moved files, that are hopefully still somewhere around.
+
+~ Michael
diff --git a/doc/forum/__34__recovering__34___from_git-annex_usage/comment_1_4a2a68ec0d0075f0d2fd7e8c9fac5e75._comment b/doc/forum/__34__recovering__34___from_git-annex_usage/comment_1_4a2a68ec0d0075f0d2fd7e8c9fac5e75._comment
new file mode 100644
index 0000000000..21feb541d1
--- /dev/null
+++ b/doc/forum/__34__recovering__34___from_git-annex_usage/comment_1_4a2a68ec0d0075f0d2fd7e8c9fac5e75._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-10-27T16:20:32Z"
+ content="""
+Use `git remote set-url` to change the url of the remote
+that was on the server to the new path on the external hdd.
+"""]]
diff --git a/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__.mdwn b/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__.mdwn
new file mode 100644
index 0000000000..19aacf0215
--- /dev/null
+++ b/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__.mdwn
@@ -0,0 +1,34 @@
+After a `git annex copy --auto -t m3` I got this error:
+
+    (Recording state in git...)
+    error: unable to resolve reference refs/heads/git-annex: No such file or directory
+    fatal: Cannot lock the ref 'refs/heads/git-annex'.
+    git-annex: git [Param "update-ref",Param "refs/heads/git-annex",Param "d768b20f76ce40157214a713fb0ccb9cfc9134c2"] failed
+
+I did a `git annex sync m3` and got
+
+    [...]
+    push m3
+    Counting objects: 2976, done.
+    Delta compression using up to 2 threads.
+    Compressing objects: 100% (2052/2052), done.
+    Writing objects: 100% (2379/2379), 392.33 KiB, done.
+    Total 2379 (delta 1652), reused 460 (delta 316)
+    Auto packing the repository for optimum performance.
+    error: bad ref for refs/heads/git-annex
+    error: bad ref for refs/heads/git-annex
+    error: bad ref for refs/heads/git-annex
+    To /media/m3/annex
+    87c82c5..06219eb  git-annex -> synced/git-annex
+    be7ff5e..6625634  master -> synced/master
+    ok
+
+And then I ran the command git-annex was trying to run:
+
+    $ git update-ref refs/heads/git-annex d768b20f76ce40157214a713fb0ccb9cfc9134c2
+    error: Trying to write ref refs/heads/git-annex with nonexistent object d768b20f76ce40157214a713fb0ccb9cfc9134c2
+    fatal: Cannot update the ref 'refs/heads/git-annex'.
+
+`git fsck --full` gives no errors.
+
+What does this error mean?  Should I be worried?  Thanks.
diff --git a/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_1_e50188896df347f1d92e20a52053aa14._comment b/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_1_e50188896df347f1d92e20a52053aa14._comment
new file mode 100644
index 0000000000..b7ad4a13af
--- /dev/null
+++ b/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_1_e50188896df347f1d92e20a52053aa14._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-01T18:33:37Z"
+ content="""
+I'm afraid that this looks like a partially corrupted git repository to me. Something seems to have gone wrong with `.git/refs/heads/git-annex`. Also, git object d768b20f76ce40157214a713fb0ccb9cfc9134c2 seems to have been present before, and be gone now. 
+
+I would run `git fsck`, then look at what's happened in `.git/refs/heads`, and if the repository does seem to be damanged, re-clone it. (You can copy over `.git/config` and `.git/annex/` to keep your annexed data in the new clone.) You should probably also run `git annex fsck`, as it could have lost some location log changes.
+"""]]
diff --git a/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_2_d67793f7c969f64943d1fd54a1208c2b._comment b/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_2_d67793f7c969f64943d1fd54a1208c2b._comment
new file mode 100644
index 0000000000..1dff891217
--- /dev/null
+++ b/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_2_d67793f7c969f64943d1fd54a1208c2b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="163.1.166.255"
+ subject="comment 2"
+ date="2013-04-06T19:06:24Z"
+ content="""
+Thanks for taking the time to reply.
+
+1) The corruption spread between repositories so I resorted to restoring from a backup from some days ago, and then I restored newly added files by manually copying the symlinks from the old repo into the new one.  Of course I can't update the git-annex branch by hand.  I've run `git annex fsck`: does that re-create the location log information for the symlinks that I re-added, at least for the local repository even if it doesn't know about copies elsewhere?
+
+2) I initially tried to git clone from my restored backup, rather than just moving the restore into place.  But then while this clone showed no errors on a `git fsck --full`, any git-annex command, such as `init` (following [this](http://git-annex.branchable.com/tips/what_to_do_when_a_repository_is_corrupted/)), gives the following sort of error:
+
+    error: invalid object 100644 <long-SHA-string> for '<path to one of git annex's log files>'
+(unfortunately I lost my xterm so don't have one of my actual errors in full).  Can you think of any reason why doing a clone of the backup copy would cause this?  Instead I have just mv'd the backup copy into place and it works fine.
+"""]]
diff --git a/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_3_3523884833b5fd458a35f898797bf897._comment b/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_3_3523884833b5fd458a35f898797bf897._comment
new file mode 100644
index 0000000000..21511d2ecd
--- /dev/null
+++ b/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_3_3523884833b5fd458a35f898797bf897._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-04-08T17:23:24Z"
+ content="""
+1. I don't understand how corruption could spread between git repositories. git is supposed to use checksums to prevent bad data propigating. I would be running a lot of `git fsck` if I were you. Yes, `git annex fsck` will update location log information for files it finds in the local repository.
+
+2. Again this looks like something is corrupting your repository when git writes it. Perhaps bad memory? I think you need to get to the root of the problem with the corrupting git repositories.
+"""]]
diff --git a/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_4_02c32c2521ba1a1eaa19eaca7281f2a6._comment b/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_4_02c32c2521ba1a1eaa19eaca7281f2a6._comment
new file mode 100644
index 0000000000..25d07e8ad3
--- /dev/null
+++ b/doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_4_02c32c2521ba1a1eaa19eaca7281f2a6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="163.1.167.50"
+ subject="comment 4"
+ date="2013-04-17T17:02:11Z"
+ content="""
+I didn't think that git would let corruption spread either, but it did: the repository m3 which I showed a push to in my original post showed a broken refs/heads/git-annex too.  You can see it happening when git tries to repack m3 after pushing to it in my original post.
+
+I am pretty sure that my HDD on the machine where this first occurred needs replacing; I've marked the remote as untrusted.
+"""]]
diff --git a/doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__.mdwn b/doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__.mdwn
new file mode 100644
index 0000000000..a528cb83d7
--- /dev/null
+++ b/doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__.mdwn
@@ -0,0 +1,14 @@
+The git annex documentation gives an example of using get:
+
+# git annex sync laptop
+# git annex get .
+get my_cool_big_file (from laptop...) ok
+get iso/debian.iso (from laptop...) ok
+https://git-annex.branchable.com/walkthrough/#index5h2
+
+Is there a way to do the opposite, i.e. once synchronised with the remote repo called "laptop", directly put the actual file content directly into the "laptop"'s annex storage? E.g.
+
+# git annex sync laptop
+# git annex put .
+put my_cool_big_file (to laptop...) ok
+put iso/debian.iso (to laptop...) ok
diff --git a/doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__/comment_1_b2b7de0bf4494721b02280857474fd6c._comment b/doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__/comment_1_b2b7de0bf4494721b02280857474fd6c._comment
new file mode 100644
index 0000000000..5baab08c7c
--- /dev/null
+++ b/doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__/comment_1_b2b7de0bf4494721b02280857474fd6c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="hobbes@b2cacef69071743c3a831e60511062f7e014e52f"
+ nickname="hobbes"
+ avatar="http://cdn.libravatar.org/avatar/44b70169c4d862b3619812c360aa8f1e"
+ subject="comment 1"
+ date="2018-12-06T15:21:38Z"
+ content="""
+I think you're looking for `git-annex copy` ?
+"""]]
diff --git a/doc/forum/__39__wget_--mirror__39___like_behaviour.mdwn b/doc/forum/__39__wget_--mirror__39___like_behaviour.mdwn
new file mode 100644
index 0000000000..d13f3c2974
--- /dev/null
+++ b/doc/forum/__39__wget_--mirror__39___like_behaviour.mdwn
@@ -0,0 +1,7 @@
+Hi, is there a quick way to implement a 'wget --mirror' like behaviour with git-annex?
+
+I.e., I'd like to clone an entire website and adding it with original urls to my annex.
+
+I've tried 'git-annex addurl http://website.tld' only, but of course it downloads a single page, it does not descend recursively.
+
+Thanks
diff --git a/doc/forum/__39__wget_--mirror__39___like_behaviour/comment_1_9c874a74f25fa06b8e515482b4706032._comment b/doc/forum/__39__wget_--mirror__39___like_behaviour/comment_1_9c874a74f25fa06b8e515482b4706032._comment
new file mode 100644
index 0000000000..95cd6f075d
--- /dev/null
+++ b/doc/forum/__39__wget_--mirror__39___like_behaviour/comment_1_9c874a74f25fa06b8e515482b4706032._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-11T17:54:16Z"
+ content="""
+There is not, but if you can find a way to get wget or something to
+generate a list of urls and the files it downloaded them to, you can
+feed that into `git-annex addurl --batch` to teach git-annex what the urls
+are.
+
+There is a subsystem in git-annex that could in theory be used for this,
+[[git-annex-import]] can import trees of files from a special remote.
+
+But the complexity of mirroring a website makes me think I would not want
+to try to support it in the web special remote. I mean, just look at how
+many options wget has that you might use to control how the mirroring
+works.
+
+Other special remotes can support importing from specific types of websites
+though. Currently this is limited to built-in special remotes, such as S3,
+but it would be possible to expand it to support external special remotes
+as well. See [[todo/importtree_only_remotes]] for discussion about doing
+that.
+"""]]
diff --git a/doc/forum/__91__ERROR____93___unknown_archive_format_for_.mat_.tif_and_.json_files.mdwn b/doc/forum/__91__ERROR____93___unknown_archive_format_for_.mat_.tif_and_.json_files.mdwn
new file mode 100644
index 0000000000..422ff414f7
--- /dev/null
+++ b/doc/forum/__91__ERROR____93___unknown_archive_format_for_.mat_.tif_and_.json_files.mdwn
@@ -0,0 +1,29 @@
+Hi,
+
+Some context: While adding a new dataset to Datalad (https://www.datalad.org/) by giving the download URL, git-annex is working under the cover to manage data. In this case, I see that some .tif .json and .mat (maybe others I have not tried) files do not get added to annex as expected
+
+Here I have an example with a .mat file:
+
+```$ datalad download-url --archive url_to_mask.mat```
+
+The datalad command above has a flag ```--archive``` that allows passing downloaded files under the git annex control. Git-annex does not seem to be able to support archives for this file format
+
+```[INFO   ] Downloading 'https://2a9f4.8443.dn.glob.us/5/published/publication_170/submitted_data/2015_5_6_striatum/mask/2015-5-6_mask.mat' into '/data/conp/multimodal-FRDR-dataset' 
+download_url(ok): /data/conp/multimodal-FRDR-dataset/2015-5-6_mask.mat (file)                                                         
+add(ok): 2015-5-6_mask.mat (file)
+save(ok): /data/conp/multimodal-FRDR-dataset (dataset)
+
+[INFO   ] Adding content of the archive /data/conp/multimodal-FRDR-dataset/2015-5-6_mask.mat into annex <AnnexRepo path=/data/conp/multimodal-FRDR-dataset (<class 'datalad.support.annexrepo.AnnexRepo'>)> 
+
+[ERROR  ] unknown archive format for file `/data/conp/multimodal-FRDR-dataset/.git/annex/objects/34/x8/MD5E-s575--b5333e072291f215595c9c39cd2524e5.mat/MD5E-s575--b5333e072291f215595c9c39cd2524e5.mat' [__init__.py:get_archive_format:293] (PatoolError) 
+```
+
+What is it really going on here?
+
+Is this a bug or a possible addition to be implemented? Is there any way in git annex to avoid this issue?
+
+Thank you for your help,
+
+Regards
+Giulia
+
diff --git a/doc/forum/__91__ERROR____93___unknown_archive_format_for_.mat_.tif_and_.json_files/comment_1_debe9a878896ead4957db288203cae14._comment b/doc/forum/__91__ERROR____93___unknown_archive_format_for_.mat_.tif_and_.json_files/comment_1_debe9a878896ead4957db288203cae14._comment
new file mode 100644
index 0000000000..182988f621
--- /dev/null
+++ b/doc/forum/__91__ERROR____93___unknown_archive_format_for_.mat_.tif_and_.json_files/comment_1_debe9a878896ead4957db288203cae14._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-08-29T16:04:02Z"
+ content="""
+I don't think the problem will involve git-annex,
+because that error message is not emitted by git-annex.
+"""]]
diff --git a/doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2.mdwn b/doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2.mdwn
new file mode 100644
index 0000000000..e89271fe16
--- /dev/null
+++ b/doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2.mdwn
@@ -0,0 +1,18 @@
+Hi, another installation issue on Ubuntu Lucid:
+
+I started with a clean `~/.cabal` directory and did the following:
+
+    andreas@antares:~$ sudo aptitude install cabal-install
+    andreas@antares:~$ cabal update
+    andreas@antares:~$ cabal install git-annex -v --bindir=$HOME/
+
+However, I got some dpendancy error:
+
+    cabal: dependencies conflict: base-3.0.3.2 requires syb ==0.1.0.2 however
+    syb-0.1.0.2 was excluded because json-0.5 requires syb >=0.3.3
+
+Any ideas?
+
+Thanks for your help!
+
+[[!tag forumbug]] [[bugs/done]]
diff --git a/doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2/comment_1_fae6e88115d175239fc55cef4c33fb2c._comment b/doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2/comment_1_fae6e88115d175239fc55cef4c33fb2c._comment
new file mode 100644
index 0000000000..c04cc335b6
--- /dev/null
+++ b/doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2/comment_1_fae6e88115d175239fc55cef4c33fb2c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-01-15T19:53:35Z"
+ content="""
+This is now about different build failure than the bug you reported, which was already fixed. Conflating the two is just confusing.
+
+The error message about `syb` is because by using cabal-install on an Ubuntu system from 2010, you're mixing the very old versions of some haskell libraries in Ubuntu with the new versions cabal wants to install. The solution is to stop mixing two package management systems --
+
+* Either install git-annex without using cabal, and use apt-get to install all its dependencies from Ubuntu, assuming your distribution has all the necessary haskell libraries packaged.
+* Or `apt-get remove ghc`, and manually install a current version of [The Haskell Platform](http://hackage.haskell.org/platform/) and use cabal.
+"""]]
diff --git a/doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2/comment_2_4c7a75638e8717132ccde949018d6008._comment b/doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2/comment_2_4c7a75638e8717132ccde949018d6008._comment
new file mode 100644
index 0000000000..3a3106a635
--- /dev/null
+++ b/doc/forum/__91__Installation__93___base-3.0.3.2_requires_syb___61____61__0.1.0.2/comment_2_4c7a75638e8717132ccde949018d6008._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/fd55c6e3-966a-4626-865f-5d0f73e1eb88"
+ nickname="Andreas H."
+ subject="Thanks and sorry"
+ date="2012-01-15T20:54:55Z"
+ content="""
+Joey, thanks for you quick help! I'll try the manual haskell-platform install once I have quicker internet again, i.e. tomorrow.
+
+And sorry for the mess-up; I splitted the post into two. Hope it's clearer now.
+"""]]
diff --git a/doc/forum/__91__NEED_HELP__93___manual_ssh_remote_setup_with_shared_key.mdwn b/doc/forum/__91__NEED_HELP__93___manual_ssh_remote_setup_with_shared_key.mdwn
new file mode 100644
index 0000000000..f6cdb4c668
--- /dev/null
+++ b/doc/forum/__91__NEED_HELP__93___manual_ssh_remote_setup_with_shared_key.mdwn
@@ -0,0 +1,19 @@
+
+So much time gone by after the kickstarter and now I wanted to give it a kick finally.
+I set up everything on my linux desktop with no problems at all.
+
+I configured a ssh remote with shared encryption key.
+
+Then I tried to use this to share files with a windows Desktop. This is where problems started.
+
+1. Since there is no jabber sync I need to exchange keys manually. But although I read and googled for hours I just found that it would be there in the git repo somewhere in plain text. I didnt find a command to actually display it on the command line.
+2. I need to setup the (existing) ssh remote on windows manually, because I could not make the webapp recognize the ssh-keys from pageant. Also, unfortunately, all examples refer to s3. I didnt even find out which type I had to specify. There seems to be no comprehensive list of repository types for the cmdline and their required arguments respectively at all. The man page says "type=..." for the three-line description of shared encryption setups which appeared like a mockery to me. Since the remote does not have git metadata I also can not use git clone.
+3. The docs say initremote would only be used on fresh remotes, not existing ones. But enableremote only enables remotes that are already configured. So what am I to do here?
+
+Could someone tell me please
+
+1. How to find the shared key
+2. How to add the ssh remote properly
+3. Where 1 and 2 are documented
+
+Thank you!
diff --git a/doc/forum/__91__NEED_HELP__93___manual_ssh_remote_setup_with_shared_key/comment_1_811cab17410ba6e07ae7af3249cd98df._comment b/doc/forum/__91__NEED_HELP__93___manual_ssh_remote_setup_with_shared_key/comment_1_811cab17410ba6e07ae7af3249cd98df._comment
new file mode 100644
index 0000000000..7a6eafa7a7
--- /dev/null
+++ b/doc/forum/__91__NEED_HELP__93___manual_ssh_remote_setup_with_shared_key/comment_1_811cab17410ba6e07ae7af3249cd98df._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="71.80.94.56"
+ subject="comment 1"
+ date="2014-02-07T19:28:00Z"
+ content="""
+Sorry for the delay getting to this post.
+
+The lack of jabber support on Windows makes this a bit hard to set up. You instead need to make a git repository some place that both the Windows and Linux machines can both connect to. Once git-annex on both systems is syncing with that common git repository, the Windows system will learn about the encrypted remotes you have set up, and then `git annex enableremote` will be able to use them with no problem.
+
+Of course, if you don't trust your ssh server where you already made an encrypted remote, you may not want to store a un-encrypted git repository on it, and since Windows also doesn't support encrypted git repositories yet, you'd be sort of out of luck. (For now; Windows support is being improved.) 
+
+OTOH, if you just set up that encrypted rsync remote on the ssh server because the ssh server didn't have git-annex installed on it, you can easily also put a git repository on the ssh server, and the combination will be enough to let you sync between the 2 machines.
+"""]]
diff --git a/doc/forum/__91__Question__93___Mixing_.thin_and_default_repos__63__.mdwn b/doc/forum/__91__Question__93___Mixing_.thin_and_default_repos__63__.mdwn
new file mode 100644
index 0000000000..426d12be02
--- /dev/null
+++ b/doc/forum/__91__Question__93___Mixing_.thin_and_default_repos__63__.mdwn
@@ -0,0 +1,15 @@
+Have tested this setup locally - and it seems to work well.<br>
+Asking for a sanity check:<br>
+<br>
+One default repo.<br>
+One .thin repo.<br>
+Synching using sync and get.<br>
+<br>
+The fat repo retains all the historical versions of the file. <br>
+The thin repo holds only the newest version of the file. <br>
+<br>
+Can edit / sync both ways and the above two statements remain true.<br>
+<br>
+<br>
+Is this use case intended?<br>
+If so git-annex is brilliant =).<br>
diff --git a/doc/forum/__91__Question__93___Mixing_.thin_and_default_repos__63__/comment_1_41f7bb65b85c3ab54f692e04d26a2891._comment b/doc/forum/__91__Question__93___Mixing_.thin_and_default_repos__63__/comment_1_41f7bb65b85c3ab54f692e04d26a2891._comment
new file mode 100644
index 0000000000..645b714f6a
--- /dev/null
+++ b/doc/forum/__91__Question__93___Mixing_.thin_and_default_repos__63__/comment_1_41f7bb65b85c3ab54f692e04d26a2891._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-12-13T16:37:34Z"
+ content="""
+Do you mean annex.thin or just a repo that only holds the newest version of
+a file?
+
+Either way, yes, you can mix such differnet types of repos however you
+like.
+"""]]
diff --git a/doc/forum/__91__announce__93___metadata_extration_utility.mdwn b/doc/forum/__91__announce__93___metadata_extration_utility.mdwn
new file mode 100644
index 0000000000..3214f36d9b
--- /dev/null
+++ b/doc/forum/__91__announce__93___metadata_extration_utility.mdwn
@@ -0,0 +1,30 @@
+Let me announce 'metatag', a simple metadata extraction utility.
+
+The Design Idea is to make it completely event driven. There are string matching rules over added metadata,
+who invoke engines when matched, which in turn add more metadata and so on.
+Thus the whole metadata extraction process is controlled by those easily configurable rules. Processing a file or
+directory just starts by adding "/=filename" to the metadata, everything else bootstraps from that. After metadata
+got extracted there are exporters which implement different backends for storing this metadata (currently only a
+'print' and a 'gitannex' exporter are implemented)
+
+While still in a infancy state it already works for me. It now needs more rules and engines for metadata extraction
+and some more efforts to 'standardize' generated metadata. I'd like to welcome comments and contributions.
+
+A README about it can be found at
+
+ <http://git.pipapo.org/?p=metatag;a=blob_plain;f=README>
+
+The code is available under git from
+
+    git clone git://git.pipapo.org/metatag
+
+To make the contribution barrier as low as possible there is a public pushable 'mob' repository where everyone can
+send changes too at `git://git.pipapo.org/mob/metatag`
+
+after installing it, using it on a annexed directory is like
+
+    metatag -r -O gitannex,gitexclude -o gitannex:-stat ./
+
+There is a mailinglist for the project, you can subscribe at
+
+ <http://lists.pipapo.org/cgi-bin/mailman/listinfo/metatag>
diff --git a/doc/forum/__96__git_annex_assistant__96___command_replace_all_files_with_pointer_file..mdwn b/doc/forum/__96__git_annex_assistant__96___command_replace_all_files_with_pointer_file..mdwn
new file mode 100644
index 0000000000..df28fd21e2
--- /dev/null
+++ b/doc/forum/__96__git_annex_assistant__96___command_replace_all_files_with_pointer_file..mdwn
@@ -0,0 +1,31 @@
+## Expect behaviors
+`git annex assistant` doesn't annex the old files and annex "non-large files". According to the below quote from the [`git-annex assistant`](https://git-annex.branchable.com/git-annex-assistant/) document:
+
+> By default, all files added are added to the annex, the same as when you run git annex add. If you configure annex.largefiles, files that it does not match will instead be added with git add.
+
+## Actual behaviors
+Git annex replaces all old files (file is already stored by git before the `git annex` command) and newly added files with pointer files after using the `git annex assistant` command. Even I config `annex.largefiles` to include all files.
+
+
+
+
+[Example repo](https://github.com/BilderLoong/test)
+
+## Context
+
+Output of `git annex version`:
+
+```
+git-annex version: 10.20240129
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24.1 bloomfilter-2.0.1.2 crypton-0.34 DAV-1.3.4 feed-1.3.2.1 ghc-9.6.3 http-client-0.7.16 persistent-sqlite-2.13.3.0 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+System: macOS Monterey Version 12.6 (21G115)
+
diff --git a/doc/forum/__96__git_annex_copy__96____44___estimate_how_much_data_to_copy.mdwn b/doc/forum/__96__git_annex_copy__96____44___estimate_how_much_data_to_copy.mdwn
new file mode 100644
index 0000000000..dcc3377edf
--- /dev/null
+++ b/doc/forum/__96__git_annex_copy__96____44___estimate_how_much_data_to_copy.mdwn
@@ -0,0 +1,3 @@
+Hi,
+
+Is there any way to estimate how much data will be transferred and/or written down on the target repository of a `git annex copy` command? Something that would take into account that some data is already there, etc.
diff --git a/doc/forum/__96__git_annex_copy__96____44___estimate_how_much_data_to_copy/comment_1_785e4fe097ef2a2d51d84146fc91b2ca._comment b/doc/forum/__96__git_annex_copy__96____44___estimate_how_much_data_to_copy/comment_1_785e4fe097ef2a2d51d84146fc91b2ca._comment
new file mode 100644
index 0000000000..93a391e6cb
--- /dev/null
+++ b/doc/forum/__96__git_annex_copy__96____44___estimate_how_much_data_to_copy/comment_1_785e4fe097ef2a2d51d84146fc91b2ca._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-19T19:05:16Z"
+ content="""
+Using `git annex info .` in combination with the
+[[git-annex-matching-options]] is a good way to do such queries.
+
+The "size of annexed files in working tree" line gives the total size of
+the files that match that query.
+
+If you're copying files to a remote, run something like:
+
+	git annex info . --not --in $remote
+
+And if you're getting files, run something like:
+
+	git annex info . --not --in here
+"""]]
diff --git a/doc/forum/__96__git_annex_import__96___from_directory_loses_contents__63__.mdwn b/doc/forum/__96__git_annex_import__96___from_directory_loses_contents__63__.mdwn
new file mode 100644
index 0000000000..f229f71fd4
--- /dev/null
+++ b/doc/forum/__96__git_annex_import__96___from_directory_loses_contents__63__.mdwn
@@ -0,0 +1,76 @@
+I'm a bit confused by the behaviour of `git annex import` from directory special-remotes. It seems to move a file from git to the annex, and loses the file contents. Is this the expected behaviour?
+
+```
+$ mkdir export-directory
+
+$ mkdir repo
+
+$ cd repo/
+
+$ git init
+
+$ git annex init
+
+$ git annex initremote test type=directory directory=../export-directory encryption=none importtree=yes exporttree=yes
+
+$ git config remote.test.annex-tracking-branch master
+
+$ touch file.txt
+
+$ git annex add --force-small file.txt 
+
+$ git commit -m 'Add file to git'
+
+$ git annex sync --content (OR git annex export master --to test)
+
+$ ls -l
+total 0
+-rw-r--r-- 1 user user 0 Mar  2 18:56 file.txt
+
+$ git annex sync --content (OR git annex import master --from test && git annex merge test/master)
+
+$ ls -l
+total 4
+lrwxrwxrwx 1 user user 118 Mar  2 18:57 file.txt -> .git/annex/objects/25/F0/SHA1--e69de29bb2d1d6434b8b29ae775ad8c2e48c5391/SHA1--e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
+```
+
+file.txt is now a broken symlink to the annex - this is not what I expected.
+
+- I expected it to be a normal file.
+
+- If it is supposed to be moved to the annex, I would expect the file contents to be in the annex.
+
+```
+$ git annex whereis file.txt 
+whereis file.txt (0 copies) 
+  The following untrusted locations may also have copies:
+  	ce81dda1-e6cc-453a-9156-e067b8f70063 -- [test]
+failed
+git-annex: whereis: 1 failed
+
+$ git annex get file.txt --from test
+get file.txt (from test...) 
+(checksum...) 
+  verification of content failed
+failed
+git-annex: get: 1 failed
+```
+
+file.txt can not be retrieved from the remote - this is not what I expected.
+
+- I expected to be able to retrieve the file contents from the remote.
+
+--
+
+```
+$ git annex version
+git-annex version: 8.20200810
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.27 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+```
diff --git a/doc/forum/__96__git_annex_import__96___from_directory_loses_contents__63__/comment_1_776b5b8099125aad3bc8839d9cc1abeb._comment b/doc/forum/__96__git_annex_import__96___from_directory_loses_contents__63__/comment_1_776b5b8099125aad3bc8839d9cc1abeb._comment
new file mode 100644
index 0000000000..64ec49aa6c
--- /dev/null
+++ b/doc/forum/__96__git_annex_import__96___from_directory_loses_contents__63__/comment_1_776b5b8099125aad3bc8839d9cc1abeb._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-05T16:29:35Z"
+ content="""
+The conversion of the git file to an annexed file is a known problem, 
+<https://git-annex.branchable.com/todo/import_tree_annexes_files_that_were_exported_non-annexed/>
+
+The failure to get the content of the file when that happens is a bug
+though. (I think it may be a reversion as I seem to remember that working,
+but I could be mistaken.)
+
+It seems to be caused by an underlying inability to get the file:
+
+	get file.txt (from test...) (checksum...) 
+	  verification of content failed
+
+Which in turn is due to a confusion between two different SHA1s.
+When exporting a file stored in git, git-annex use the SHA1 git uses for it,
+but that is not actually the SHA1 of the file, but of the file size and file
+or something like that. Then when the file gets converted to an annexed
+file, it uses a git-annex get with that same SHA1. But git-annex expects
+the content of a SHA1 keyed file to match that SHA1, which is not the case here.
+
+So verification fails, and that's also why importing doesn't get the content.
+
+This is certainly a bug. I guess the best way to fix it would be to fix
+the above todo.
+"""]]
diff --git a/doc/forum/__96__git_annex_import__96___from_directory_loses_contents__63__/comment_2_c36d32db2b1dcd3cd36c68f2bb726f6f._comment b/doc/forum/__96__git_annex_import__96___from_directory_loses_contents__63__/comment_2_c36d32db2b1dcd3cd36c68f2bb726f6f._comment
new file mode 100644
index 0000000000..db24d689df
--- /dev/null
+++ b/doc/forum/__96__git_annex_import__96___from_directory_loses_contents__63__/comment_2_c36d32db2b1dcd3cd36c68f2bb726f6f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-03-05T18:35:54Z"
+ content="""
+This bug has been fixed.
+
+And next time you have a problem so blatent with a test case and
+everything, it's certianly a bug, so don't be afraid to file a bug report
+rather than using the forum. It's harder to close forum posts than
+bug reports!
+"""]]
diff --git a/doc/forum/__96__git_annex_sync__96___hangs.mdwn b/doc/forum/__96__git_annex_sync__96___hangs.mdwn
new file mode 100644
index 0000000000..5a6a3d8ad7
--- /dev/null
+++ b/doc/forum/__96__git_annex_sync__96___hangs.mdwn
@@ -0,0 +1,113 @@
+I am on a direct remote. I just deleted a directory, and would like to commit that change.
+
+After I run `git annex sync` I see a line which says `commit`, and that is all. I tried to wait it out a few hours, but nothing. Why does git annex hang?
+
+Here is the output of `strace git annex sync`:
+
+```
+chymera@zenbookhost /run/media/chymera/data3 $ strace git annex sync
+execve("/usr/bin/git", ["git", "annex", "sync"], [/* 78 vars */]) = 0
+brk(0)                                  = 0x1afa000
+mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f17d12c4000
+access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
+open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
+fstat(3, {st_mode=S_IFREG|0644, st_size=207886, ...}) = 0
+mmap(NULL, 207886, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f17d1291000
+close(3)                                = 0
+open("/lib64/libpcre.so.1", O_RDONLY|O_CLOEXEC) = 3
+read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\27\0\0\0\0\0\0"..., 832) = 832
+fstat(3, {st_mode=S_IFREG|0755, st_size=452672, ...}) = 0
+mmap(NULL, 2548328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f17d0e36000
+mprotect(0x7f17d0ea4000, 2093056, PROT_NONE) = 0
+mmap(0x7f17d10a3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6d000) = 0x7f17d10a3000
+close(3)                                = 0
+open("/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
+read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`#\0\0\0\0\0\0"..., 832) = 832
+fstat(3, {st_mode=S_IFREG|0755, st_size=88456, ...}) = 0
+mmap(NULL, 2183720, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f17d0c20000
+mprotect(0x7f17d0c35000, 2093056, PROT_NONE) = 0
+mmap(0x7f17d0e34000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x7f17d0e34000
+close(3)                                = 0
+open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
+read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@p\0\0\0\0\0\0"..., 832) = 832
+fstat(3, {st_mode=S_IFREG|0755, st_size=125536, ...}) = 0
+mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f17d1290000
+mmap(NULL, 2204816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f17d0a05000
+mprotect(0x7f17d0a1b000, 2093056, PROT_NONE) = 0
+mmap(0x7f17d0c1a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7f17d0c1a000
+mmap(0x7f17d0c1c000, 13456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f17d0c1c000
+close(3)                                = 0
+open("/lib64/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
+read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`#\0\0\0\0\0\0"..., 832) = 832
+fstat(3, {st_mode=S_IFREG|0755, st_size=31536, ...}) = 0
+mmap(NULL, 2128920, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f17d07fd000
+mprotect(0x7f17d0804000, 2093056, PROT_NONE) = 0
+mmap(0x7f17d0a03000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f17d0a03000
+close(3)                                = 0
+open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
+read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\33\2\0\0\0\0\0"..., 832) = 832
+fstat(3, {st_mode=S_IFREG|0755, st_size=1660320, ...}) = 0
+mmap(NULL, 3766680, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f17d0465000
+mprotect(0x7f17d05f3000, 2097152, PROT_NONE) = 0
+mmap(0x7f17d07f3000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18e000) = 0x7f17d07f3000
+mmap(0x7f17d07f9000, 14744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f17d07f9000
+close(3)                                = 0
+mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f17d128f000
+mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f17d128e000
+mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f17d128d000
+arch_prctl(ARCH_SET_FS, 0x7f17d128e700) = 0
+mprotect(0x7f17d07f3000, 16384, PROT_READ) = 0
+mprotect(0x7f17d0c1a000, 4096, PROT_READ) = 0
+mprotect(0x7f17d0a03000, 4096, PROT_READ) = 0
+mprotect(0x7f17d0e34000, 4096, PROT_READ) = 0
+mprotect(0x7f17d10a3000, 4096, PROT_READ) = 0
+mprotect(0x79b000, 4096, PROT_READ)     = 0
+mprotect(0x7f17d12c5000, 4096, PROT_READ) = 0
+munmap(0x7f17d1291000, 207886)          = 0
+set_tid_address(0x7f17d128e9d0)         = 2218
+set_robust_list(0x7f17d128e9e0, 24)     = 0
+rt_sigaction(SIGRTMIN, {0x7f17d0a0bb10, [], SA_RESTORER|SA_SIGINFO, 0x7f17d0a14d20}, NULL, 8) = 0
+rt_sigaction(SIGRT_1, {0x7f17d0a0bba0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f17d0a14d20}, NULL, 8) = 0
+rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
+getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
+open("/dev/null", O_RDWR)               = 3
+close(3)                                = 0
+rt_sigprocmask(SIG_UNBLOCK, [PIPE], NULL, 8) = 0
+rt_sigaction(SIGPIPE, {SIG_DFL, [PIPE], SA_RESTORER|SA_RESTART, 0x7f17d0499ee0}, {SIG_DFL, [], 0}, 8) = 0
+brk(0)                                  = 0x1afa000
+brk(0x1b1b000)                          = 0x1b1b000
+open("/usr/lib64/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
+fstat(3, {st_mode=S_IFREG|0644, st_size=106086208, ...}) = 0
+mmap(NULL, 106086208, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f17c9f39000
+close(3)                                = 0
+stat(".git", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
+access("/etc/gitconfig", R_OK)          = -1 ENOENT (No such file or directory)
+access("/home/chymera/.config/git/config", R_OK) = -1 ENOENT (No such file or directory)
+access("/home/chymera/.gitconfig", R_OK) = 0
+open("/home/chymera/.gitconfig", O_RDONLY) = 3
+fstat(3, {st_mode=S_IFREG|0644, st_size=147, ...}) = 0
+mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f17d12c3000
+read(3, "[user]\n\temail = h.chr@mail.ru\n\tn"..., 4096) = 147
+read(3, "", 4096)                       = 0
+close(3)                                = 0
+munmap(0x7f17d12c3000, 4096)            = 0
+access(".git/config", R_OK)             = 0
+open(".git/config", O_RDONLY)           = 3
+fstat(3, {st_mode=S_IFREG|0644, st_size=335, ...}) = 0
+mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f17d12c3000
+read(3, "[core]\n\trepositoryformatversion "..., 4096) = 335
+read(3, "", 4096)                       = 0
+close(3)                                = 0
+munmap(0x7f17d12c3000, 4096)            = 0
+pipe([3, 4])                            = 0
+clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f17d128e9d0) = 2219
+rt_sigaction(SIGINT, {0x4f4d70, [INT], SA_RESTORER|SA_RESTART, 0x7f17d0499ee0}, {SIG_DFL, [], 0}, 8) = 0
+rt_sigaction(SIGHUP, {0x4f4d70, [HUP], SA_RESTORER|SA_RESTART, 0x7f17d0499ee0}, {SIG_DFL, [], 0}, 8) = 0
+rt_sigaction(SIGTERM, {0x4f4d70, [TERM], SA_RESTORER|SA_RESTART, 0x7f17d0499ee0}, {SIG_DFL, [], 0}, 8) = 0
+rt_sigaction(SIGQUIT, {0x4f4d70, [QUIT], SA_RESTORER|SA_RESTART, 0x7f17d0499ee0}, {SIG_DFL, [], 0}, 8) = 0
+rt_sigaction(SIGPIPE, {0x4f4d70, [PIPE], SA_RESTORER|SA_RESTART, 0x7f17d0499ee0}, {SIG_DFL, [PIPE], SA_RESTORER|SA_RESTART, 0x7f17d0499ee0}, 8) = 0
+close(4)                                = 0
+read(3, "", 1)                          = 0
+close(3)                                = 0
+wait4(2219, commit  
+```
diff --git a/doc/forum/__96__git_annex_sync__96___hangs/comment_1_ffd16cb94b39b93dfb0a2932b70938fc._comment b/doc/forum/__96__git_annex_sync__96___hangs/comment_1_ffd16cb94b39b93dfb0a2932b70938fc._comment
new file mode 100644
index 0000000000..e373a3c572
--- /dev/null
+++ b/doc/forum/__96__git_annex_sync__96___hangs/comment_1_ffd16cb94b39b93dfb0a2932b70938fc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/yx5Y6EI1t.759Jsu63ZWqYclCmpOmxxd.ramtw--#7114a"
+ nickname="Ioanas"
+ subject="comment 1"
+ date="2015-06-04T14:10:17Z"
+ content="""
+nobody?
+"""]]
diff --git a/doc/forum/__96__git_annex_sync__96___hangs/comment_2_fad59a54d92ed7cb230f0f365fddb0f4._comment b/doc/forum/__96__git_annex_sync__96___hangs/comment_2_fad59a54d92ed7cb230f0f365fddb0f4._comment
new file mode 100644
index 0000000000..19c3b0abb5
--- /dev/null
+++ b/doc/forum/__96__git_annex_sync__96___hangs/comment_2_fad59a54d92ed7cb230f0f365fddb0f4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-20T17:35:42Z"
+ content="""
+Sorry didn't get to this until now.
+
+It would probably help to pass the --debug option to git-annex sync,
+and paste the output up to the point where it hangs.
+"""]]
diff --git a/doc/forum/__96__git_annex_sync__96___uses_too_much_space__63__/comment_1_29cd5e9acd78d8ac6b58fe535fee9650._comment b/doc/forum/__96__git_annex_sync__96___uses_too_much_space__63__/comment_1_29cd5e9acd78d8ac6b58fe535fee9650._comment
new file mode 100644
index 0000000000..bdf9861f14
--- /dev/null
+++ b/doc/forum/__96__git_annex_sync__96___uses_too_much_space__63__/comment_1_29cd5e9acd78d8ac6b58fe535fee9650._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnVnsqEy82M-MuS2gLri-az83wSQ6lXSrc"
+ nickname="Jean"
+ subject="comment 1"
+ date="2015-05-02T08:28:56Z"
+ content="""
+I tried reformatting the device with smaller blocksize and inode size, but this didn't help. 
+"""]]
diff --git a/doc/forum/__96__git_annex_sync__96___uses_too_much_space__63__/comment_2_7a24236bc511cbfa869aaeb431a003d2._comment b/doc/forum/__96__git_annex_sync__96___uses_too_much_space__63__/comment_2_7a24236bc511cbfa869aaeb431a003d2._comment
new file mode 100644
index 0000000000..60e1f22af8
--- /dev/null
+++ b/doc/forum/__96__git_annex_sync__96___uses_too_much_space__63__/comment_2_7a24236bc511cbfa869aaeb431a003d2._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-05-05T16:42:43Z"
+ content="""
+It's failing to pull the git repository from the remote because that
+git repository is apparently larger than 487 mb. That is not usual 
+when using git-annex, or even when using git unless you have millions
+of files in the git repository.
+
+Since you only have a few thousand files in the git repository,
+my guess is you have committed some large files directly to git,
+instead of using git-annex. So, you're seeing why git-annex exists...
+
+You should find the files in your git repository that are not git-annex
+symlinks, and are large files. You may need to use `git filter-branch`
+to remove the from your repository's history.
+"""]]
diff --git a/doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__.mdwn b/doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__.mdwn
new file mode 100644
index 0000000000..c9abafa6e8
--- /dev/null
+++ b/doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__.mdwn
@@ -0,0 +1,14 @@
+I find that it's possible for a repo to not get the content that it wants to have. It happens if the repo only points to remotes that don't have the content.
+
+`git annex get` will fail:
+
+    $ git annex get --want-get
+    get foo (not available) 
+      Maybe add some of these git remotes (git remote add ...):
+      	6ac12bd5-b585-4884-b0fe-a48fdc1b6365 -- b
+    failed
+    get: 1 failed
+
+But `git annex sync --content` passes, despite not getting any of the wanted content.
+
+Is there a way to make `git annex sync --content` error if it can't fetch wanted content, the way `git annex get` does?
diff --git a/doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__/comment_1_41d3a4774dd5ada5036247eb6f562392._comment b/doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__/comment_1_41d3a4774dd5ada5036247eb6f562392._comment
new file mode 100644
index 0000000000..4e72320fa7
--- /dev/null
+++ b/doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__/comment_1_41d3a4774dd5ada5036247eb6f562392._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 1"
+ date="2022-11-12T02:50:07Z"
+ content="""
+I guess I can `git annex sync --content && git annex get --auto` to make sure I get the content I want. Although at that point, it's probably better to do `git annex sync && git annex get --auto && git annex drop --auto`. I was expecting `sync` to handle the auto get/drop - which it usually does. But it silently passes even when it doesn't get the wanted content.
+
+Perhaps I should think of `sync` as a \"best effort\" mode? That is, it will download available content, but I shouldn't rely on it to download all wanted content - `get` is the job for that.
+"""]]
diff --git a/doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__/comment_2_a971d9d85eb7f86d4ea18a71bd0db25d._comment b/doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__/comment_2_a971d9d85eb7f86d4ea18a71bd0db25d._comment
new file mode 100644
index 0000000000..8a1e2aff7d
--- /dev/null
+++ b/doc/forum/__96__sync_--content__96___error_if_it_can__39__t_get_wanted__63__/comment_2_a971d9d85eb7f86d4ea18a71bd0db25d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-11-14T17:01:37Z"
+ content="""
+The rationelle for this difference is that 
+with `git-annex get` you are explicitly asking it to get
+the specified files (or all files), while with `git-annex sync --content`
+you are asking it to make the local and remote be in sync with respect to
+whether they contain the content or not. When neither local nor remote
+contains the content, they are still in sync.. 
+"""]]
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring.mdwn b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring.mdwn
new file mode 100644
index 0000000000..5d39ec77f8
--- /dev/null
+++ b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring.mdwn
@@ -0,0 +1,40 @@
+Currently I am trying to synchronize two folders between my NAS and my main computer. On both machines I can access the web app. However, once I try to pair these machines with a secret phrase I get the following error:
+ 
+illegal control characters in pairing message; ignoring
+
+The log on one machine is:
+
+[2016-03-18 14:25:16.861132] main: Pairing in progress
+Generating public/private rsa key pair.
+Your identification has been saved in /var/folders/_v/hkf9zbqs0bgd2vcnmr_qnlgm0000gn/T/git-annex-keygenN92651/key.
+Your public key has been saved in /var/folders/_v/hkf9zbqs0bgd2vcnmr_qnlgm0000gn/T/git-annex-keygenN92651/key.pub.
+The key fingerprint is:
+SHA256:beyV1f5MKFGaaH9p1CRMPmaVcYAmOyc/lhp7HCw668M username@iMac.home
+The key's randomart image is:
++---[RSA 2048]----+
+|             +=o*|
+|          ..o=.B.|
+|          o++ B o|
+|         ++..B = |
+|        S +*=.= o|
+|         oo.B+ o.|
+|       . ..B o  o|
+|        E o o    |
+|       .o+ .     |
++----[SHA256]-----+
+[2016-03-18 14:25:26.442301] main: Pairing in progress
+ 
+  illegal control characters in pairing message; ignoring
+ 
+  illegal control characters in pairing message; ignoring
+ 
+  illegal control characters in pairing message; ignoring
+ 
+  illegal control characters in pairing message; ignoring
+
+While on the other machine I get:
+
+[2016-03-18 14:25:35 CET] main: Pairing with username@iMac.home:~/Desktop/annex in progress
+
+
+
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_1_99975a677f832c410050ba721be6d904._comment b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_1_99975a677f832c410050ba721be6d904._comment
new file mode 100644
index 0000000000..0ebe49ec5b
--- /dev/null
+++ b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_1_99975a677f832c410050ba721be6d904._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-03-18T15:31:17Z"
+ content="""
+This probably has something to do with the hostname of the other host than
+the one that displays the error. Or possibly with the name of the user on
+that host, or the directory on that host where the git-annex repository is.
+
+Can you share that information, or at least the parts of it that are not
+regular alphabet characters?
+
+(There's also an outside possibility it could have found a control
+character in the ssh public key, but I don't see how.)
+"""]]
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_2_f4dd76879e2b2bd0da557ee6a539533c._comment b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_2_f4dd76879e2b2bd0da557ee6a539533c._comment
new file mode 100644
index 0000000000..6e732416f5
--- /dev/null
+++ b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_2_f4dd76879e2b2bd0da557ee6a539533c._comment
@@ -0,0 +1,95 @@
+[[!comment format=mdwn
+ username="butirsky@86ff3803c45a8a1e5fc253d2728ce493c8addf96"
+ nickname="butirsky"
+ avatar="http://cdn.libravatar.org/avatar/bf8e56c57b179935c6f52ebc4690c2bf"
+ subject="comment 2"
+ date="2017-01-18T13:19:43Z"
+ content="""
+Having the same issue, the error only on one side, syncing doesn't start:
+
+```
+[2017-01-18 15:25:30.603909] main: starting assistant version 5.20151208-1build1
+[2017-01-18 15:25:30.615017] Cronner: You should enable consistency checking to protect your data. 
+
+  No known volume monitor available through dbus; falling back to mtab polling
+(scanning...) [2017-01-18 15:25:31.040087] Watcher: Performing startup scan
+(started...) 
+(scanning...) [2017-01-18 15:27:19.254315] Watcher: Performing startup scan
+(started...) git-annex: Daemon is already running.
+warning: no common commits
+From /home/abutirsky/Desktop/annex
+ * [new branch]      annex/direct/master -> annex/annex/direct/master
+ * [new branch]      git-annex  -> annex/git-annex
+ * [new branch]      master     -> annex/master
+
+(merging annex/git-annex into git-annex...)
+(recording state in git...)
+
+Already up-to-date!
+Merge made by the 'recursive' strategy.
+[2017-01-18 15:29:18.003333] main: Syncing with annex 
+[2017-01-18 15:29:18.003518] Pusher: Syncing with annex 
+To /home/abutirsky/Desktop/annex
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+Everything up-to-date
+
+(nautilus:19391): GLib-GIO-CRITICAL **: g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections != NULL' failed
+
+(nautilus:19391): GLib-GIO-CRITICAL **: g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections != NULL' failed
+
+(nautilus:19391): Gtk-CRITICAL **: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
+
+(nautilus:19391): GLib-GObject-WARNING **: invalid (NULL) pointer instance
+
+(nautilus:19391): GLib-GObject-CRITICAL **: g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
+git-annex: Daemon is already running.
+(scanning...) [2017-01-18 15:34:47.539423] Watcher: Performing startup scan
+(started...) git-annex: Daemon is already running.
+git-annex: Daemon is already running.
+git-annex: Daemon is already running.
+
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+Generating public/private rsa key pair.
+Your identification has been saved in /tmp/git-annex-keygen.0/key.
+Your public key has been saved in /tmp/git-annex-keygen.0/key.pub.
+The key fingerprint is:
+SHA256:dJ9VU8CQ+hHL2fsta1E5PkxTvkqDThbyOainUXZvaY4 abutirsky@sml-pc-066
+The key's randomart image is:
++---[RSA 2048]----+
+|            .+.o+|
+|            o ..o|
+|        . .o =..o|
+|       . o.o=o.=o|
+|        So+o*.+o+|
+|        o..Boo+= |
+|       .. + o=ooo|
+|       ... .=.o o|
+|       .o  E o.o |
++----[SHA256]-----+
+[2017-01-18 15:48:44.423064] main: Pairing in progress
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+```
+"""]]
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_3_d437dc44114f59d5717c177831ae0d53._comment b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_3_d437dc44114f59d5717c177831ae0d53._comment
new file mode 100644
index 0000000000..52c0d8134b
--- /dev/null
+++ b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_3_d437dc44114f59d5717c177831ae0d53._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="butirsky@86ff3803c45a8a1e5fc253d2728ce493c8addf96"
+ nickname="butirsky"
+ avatar="http://cdn.libravatar.org/avatar/bf8e56c57b179935c6f52ebc4690c2bf"
+ subject="comment 3"
+ date="2017-01-18T13:21:45Z"
+ content="""
+Version of annex on the other side is 5.20140412ubuntu1, if it matters
+"""]]
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_dd29ac2b5615ff6f79458a36bce44306._comment b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_dd29ac2b5615ff6f79458a36bce44306._comment
new file mode 100644
index 0000000000..3b2ba3a2fa
--- /dev/null
+++ b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_dd29ac2b5615ff6f79458a36bce44306._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="butirsky@86ff3803c45a8a1e5fc253d2728ce493c8addf96"
+ nickname="butirsky"
+ avatar="http://cdn.libravatar.org/avatar/bf8e56c57b179935c6f52ebc4690c2bf"
+ subject="comment 4"
+ date="2017-01-18T16:52:21Z"
+ content="""
+Log from other side:
+
+```
+[2017-01-18 15:46:22 MSK] main: starting assistant version 5.20140412ubuntu1
+[2017-01-18 15:46:22 MSK] Cronner: You should enable consistency checking to protect your data. 
+(Recording state in git...)
+(scanning...) [2017-01-18 15:46:22 MSK] Watcher: Performing startup scan
+(started...) Generating public/private rsa key pair.
+Your identification has been saved in /tmp/git-annex-keygen.0/key.
+Your public key has been saved in /tmp/git-annex-keygen.0/key.pub.
+The key fingerprint is:
+aa:c0:c3:b8:ca:4d:5c:85:58:02:b6:a0:4a:64:18:dd echormonov@sml-pc-091
+The key's randomart image is:
++--[ RSA 2048]----+
+|+B.o .           |
+|B o E .          |
+|.o . . .         |
+|o     .          |
+|.    .  S        |
+| +. .  .         |
+|. =o  .          |
+|..oo .           |
+|+. ..            |
++-----------------+
+[2017-01-18 15:48:26 MSK] main: Pairing in progress
+[2017-01-18 15:48:44 MSK] PairListener: abutirsky@sml-pc-066:~/Desktop/gitrepo_test is sending a pair request.
+Generating public/private rsa key pair.
+Your identification has been saved in /tmp/git-annex-keygen.0/key.
+Your public key has been saved in /tmp/git-annex-keygen.0/key.pub.
+The key fingerprint is:
+28:e0:f4:a2:2c:a2:bc:7a:22:6e:4c:6d:8f:38:ac:b4 echormonov@sml-pc-091
+The key's randomart image is:
++--[ RSA 2048]----+
+|                 |
+|                 |
+|  o              |
+| o o   .         |
+|  + o . S        |
+|.o + .           |
+|Boo o            |
+|O*o. .           |
+|XEo              |
++-----------------+
+[2017-01-18 15:50:40 MSK] main: Pairing with abutirsky@sml-pc-066:~/Desktop/gitrepo_test in progress
+```
+
+By the way, any comment here is accessible for deletion by anyone. Seems like security hole
+"""]]
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_5_e07b69bb36cd8aa2c4fd689744f12df1._comment b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_5_e07b69bb36cd8aa2c4fd689744f12df1._comment
new file mode 100644
index 0000000000..62e073336e
--- /dev/null
+++ b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_5_e07b69bb36cd8aa2c4fd689744f12df1._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-01-31T16:50:18Z"
+ content="""
+Is "username@iMac.home" data that you obscured, or are you actually using
+an account called "username" with a hostname of "iMac.home"?
+
+As I said before, this is likely caused by some character that git-annex
+dooes not like in username or hostname of the other host than the one that
+displays the error.
+
+Hopefully one of you guys who can reproduce the problem can get this basic
+information to me, so I can try to get to the bottom of the problem.
+"""]]
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_6_f61a390f304e1f6d1e8c4a90cdfbd9b9._comment b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_6_f61a390f304e1f6d1e8c4a90cdfbd9b9._comment
new file mode 100644
index 0000000000..05cc831836
--- /dev/null
+++ b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_6_f61a390f304e1f6d1e8c4a90cdfbd9b9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="butirsky@86ff3803c45a8a1e5fc253d2728ce493c8addf96"
+ nickname="butirsky"
+ avatar="http://cdn.libravatar.org/avatar/bf8e56c57b179935c6f52ebc4690c2bf"
+ subject="comment 6"
+ date="2017-01-31T18:30:00Z"
+ content="""
+@joey, in my case all the user/host names are actual, and they do not include bad characters obviously
+"""]]
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_7_625df33e70f2f959c574d918a706648d._comment b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_7_625df33e70f2f959c574d918a706648d._comment
new file mode 100644
index 0000000000..e6303d1c46
--- /dev/null
+++ b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_7_625df33e70f2f959c574d918a706648d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2017-02-13T19:52:36Z"
+ content="""
+Seems we can rule out user/hostname/directory, which probably leaves
+the ssh public key as the culprit, but I'm not sure.
+
+So, I changed the error message to display the problem data,
+in [[!commit f36adc2dbc46ec50ee7c88962de0a0d1473681eb]]. Once you have a
+git-annex version with that commit, if you see the problem, paste in the
+error message and I should be able to get to the bottom of this.
+"""]]
diff --git a/doc/forum/_preferred_content__58___lastpresent.mdwn b/doc/forum/_preferred_content__58___lastpresent.mdwn
new file mode 100644
index 0000000000..e8730eb00c
--- /dev/null
+++ b/doc/forum/_preferred_content__58___lastpresent.mdwn
@@ -0,0 +1 @@
+Is there any kind of "lastpresent" in the preferred-content expression? If set, git-annex would see if "git log --follow $path -n 1" (or some configurable -n) was present.
diff --git a/doc/forum/_preferred_content__58___lastpresent/comment_1_7610cd866b256d36646b642eb5f8cae5._comment b/doc/forum/_preferred_content__58___lastpresent/comment_1_7610cd866b256d36646b642eb5f8cae5._comment
new file mode 100644
index 0000000000..d5910c6d03
--- /dev/null
+++ b/doc/forum/_preferred_content__58___lastpresent/comment_1_7610cd866b256d36646b642eb5f8cae5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 1"
+ date="2013-11-15T20:39:43Z"
+ content="""
+The idea seems to be to match files that have been deleted.
+
+I don't see how that could work; preferred content expressions are always matched against files in the working tree.
+
+Even if it were doable, it would be quite expensive if every preferred content query involved a `git log`...
+
+What are you trying to achieve with this?
+"""]]
diff --git a/doc/forum/_preferred_content__58___lastpresent/comment_2_d25666a173b78213d583f029fd166d06._comment b/doc/forum/_preferred_content__58___lastpresent/comment_2_d25666a173b78213d583f029fd166d06._comment
new file mode 100644
index 0000000000..4714034c36
--- /dev/null
+++ b/doc/forum/_preferred_content__58___lastpresent/comment_2_d25666a173b78213d583f029fd166d06._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn1QhtPvsRBV7pfaDW_ZTPFv_ZIxSzQ8Rg"
+ nickname="Paul Léo"
+ subject="comment 2"
+ date="2013-11-16T13:12:35Z"
+ content="""
+The aim is to be able to have some semi-automatic mode (using \"git-annex wanted . (lastpresent)\"), where file paths which you \"git-annex get\" one time always get updated to the latest version.
+
+Or, you could also use some variant of it the other way round (using \"git-annex wanted . (notlastpresent)\"): all files would be present by default, but paths which you \"git-annex drop\"ed once wouldn't become present again.
+"""]]
diff --git a/doc/forum/add_only_binary_files__63__.mdwn b/doc/forum/add_only_binary_files__63__.mdwn
new file mode 100644
index 0000000000..4b40db5dd7
--- /dev/null
+++ b/doc/forum/add_only_binary_files__63__.mdwn
@@ -0,0 +1 @@
+Is there a way to only add binary files with git annex add command?
diff --git a/doc/forum/add_only_binary_files__63__/comment_1_7ce3be5bafd62ce5ed78bcd9323039cc._comment b/doc/forum/add_only_binary_files__63__/comment_1_7ce3be5bafd62ce5ed78bcd9323039cc._comment
new file mode 100644
index 0000000000..e53cb1f0f3
--- /dev/null
+++ b/doc/forum/add_only_binary_files__63__/comment_1_7ce3be5bafd62ce5ed78bcd9323039cc._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-06T15:36:54Z"
+ content="""
+If you can configure `annex.largefiles` to match only binary files, then `git annex add` will respect it, and only add those files.
+
+For example, if you were working on a game written in C, and wanted to use git-annex only for the game art, but not the source code, you could configure it:
+
+    git config annex.largefiles 'largerthan=100kb and not (include=*.c or include=*.h)'
+
+This doesn't currently support looking at the file content to determine eg, its MIME type. That's been suggested as an added feature before.
+
+More simply, if you `git add` the non-binary files yourself first, `git annex add` will skip over those files and only add the other files.
+"""]]
diff --git a/doc/forum/adding_files_without_hashing_them.mdwn b/doc/forum/adding_files_without_hashing_them.mdwn
new file mode 100644
index 0000000000..a9aef308f4
--- /dev/null
+++ b/doc/forum/adding_files_without_hashing_them.mdwn
@@ -0,0 +1 @@
+I would like to be able to add files without having to hash its contents (like WORM) but being able to modify them and record its changes. Is this possible? In other words, I would like to provide other not-that-expensive mechanism for identifying files of a particular version.
diff --git a/doc/forum/adding_files_without_hashing_them/comment_1_c3113d7aff6b64a325a32b8b281df605._comment b/doc/forum/adding_files_without_hashing_them/comment_1_c3113d7aff6b64a325a32b8b281df605._comment
new file mode 100644
index 0000000000..56577ca1a7
--- /dev/null
+++ b/doc/forum/adding_files_without_hashing_them/comment_1_c3113d7aff6b64a325a32b8b281df605._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 1"
+ date="2014-09-16T19:50:41Z"
+ content="""
+You can edit files that use the WORM backend, as long as the editing changes their size or mtime, or both. If neither changes, git-annex won't be able to keep your edits separate when using WORM.
+
+A perhaps safer compromise can be to use the WORM backend initially, but them `git annex migrate --backend=SHA256E` when you have spare CPU cycles. 
+
+Or, when you commit a change to a file that had been using WORM, use `git annex add $wormy_file --backend=SHA256E` to make the new version use the better backend.
+"""]]
diff --git a/doc/forum/adding_remote_bup_repo_using_ssh.mdwn b/doc/forum/adding_remote_bup_repo_using_ssh.mdwn
new file mode 100644
index 0000000000..1c13d7f8e9
--- /dev/null
+++ b/doc/forum/adding_remote_bup_repo_using_ssh.mdwn
@@ -0,0 +1,42 @@
+I have two machines connected to my home network. machine A. Machine A has a git-annex repo which stores the data using a remote bup repo. The bup repo resides on Machine A itself. Now, I want to set up the same kind of environment in Machine B ( git annex repo backed down by bup remote). The only condition is that I need to re-use the bup repo in the machine A. So I went up like this:
+    
+    git clone ssh://192.168.1.33/path/to/git-annex-repo-on-machine-a
+
+This succeeded. The next step was to add a reference to the bup repo on machine A to this new git-annex repo in machine B. I went about like this:
+
+    git annex initremote mybup type=bup encryption=none buprepo=192.168.1.33:/path/to/bup-repo-on-machine-a
+
+This seems to work OK, except the fact that the following shows up:
+
+    Reinitialized existing Git repository in /Users/XXX/.bup/ 
+    Reinitialized existing Git repository in /Users/path/to/bup-repo-on-machine-a
+
+*Q1*: Why does git-annex create bup repos on the local folder while initializaing a remote bup repo?
+
+After that, I tried to get the file from the git repo using 
+
+    git annex get <file>  --from mybup
+
+..And nothing happened. This is the debug output from the last command :
+
+    read: git ["--git-dir=/private/tmp/annexed-setups/.git","--work-tree=/private/tmp/annexed-setups","show-ref","git-annex"]
+    read: git ["--git-dir=/private/tmp/annexed-setups/.git","--work-tree=/private/tmp/annexed-setups","show-ref","--hash","refs/heads/git-annex"]
+    read: git ["--git-dir=/private/tmp/annexed-setups/.git","--work-tree=/private/tmp/annexed-setups","log","refs/heads/git-   annex..c9af31cb3e563657e83b8b8e1f9a8de1ff690e4f","-n1","--pretty=%H"]
+    read: git ["--git-dir=/private/tmp/annexed-setups/.git","--work-tree=/private/tmp/annexed-setups","log","refs/heads/git-annex..b7b2af7f94af4770d5b4da7231bc3e41c0a6129d","-n1","--pretty=%H"]
+    read: git ["--git-dir=/private/tmp/annexed-setups/.git","--work-tree=/private/tmp/annexed-setups","log","refs/heads/git-annex..7b1017c5e68ec5a2b298b899bf723d0093fa0c7c","-n1","--pretty=%H"]
+    chat: git ["--git-dir=/private/tmp/annexed-setups/.git","--work-tree=/private/tmp/annexed-setups","cat-file","--batch"]
+    read: git ["--git-dir=/private/tmp/annexed-setups/.git","--work-tree=/private/tmp/annexed-setups","ls-files","--cached","-z","--","file.iso"]
+
+The file was not obtained from the remote. However, when I did 
+
+    git annex fsck --from mybup
+
+This resolved all the files properly and then when I did a 
+
+    git annex list. 
+
+it showed all files to be reachable from the mybup repo. 
+
+*Q2* Is this the correct workflow? 
+*Q3* Do I need to do a [costly] fsck for bup remote to properly work over ssh?
+
diff --git a/doc/forum/adding_remote_bup_repo_using_ssh/comment_1_d1ab38bccc415a94fa3906f7f5e823f3._comment b/doc/forum/adding_remote_bup_repo_using_ssh/comment_1_d1ab38bccc415a94fa3906f7f5e823f3._comment
new file mode 100644
index 0000000000..bd9d014596
--- /dev/null
+++ b/doc/forum/adding_remote_bup_repo_using_ssh/comment_1_d1ab38bccc415a94fa3906f7f5e823f3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-01-20T16:05:31Z"
+ content="""
+IIRC bup always initializes ~/.bup, even when using a remote repository.
+
+Your mistake is that you have run `git annex initremote` twice -- so now
+git-annex knows about two different remotes, which both happen to be backed
+by the same bup repository -- but git-annex doesn't know that.
+
+Instead, you should run `git annex initremote` in one repository, and then
+use `git annex enableremote` in clones of that repository to enable your
+bup remote.
+
+You will probably want to kill off the redundant bup remote with `git annex
+dead mybup` and then using `git annex enableremote` to enable the other one.
+"""]]
diff --git a/doc/forum/adding_remote_bup_repo_using_ssh/comment_2_6698ecb746e6edb25130c8dbceb36fc0._comment b/doc/forum/adding_remote_bup_repo_using_ssh/comment_2_6698ecb746e6edb25130c8dbceb36fc0._comment
new file mode 100644
index 0000000000..233ee88093
--- /dev/null
+++ b/doc/forum/adding_remote_bup_repo_using_ssh/comment_2_6698ecb746e6edb25130c8dbceb36fc0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-01-20T16:44:21Z"
+ content="""
+I've added a new section to the walkthrough about this:
+<http://git-annex.branchable.com/walkthrough/using_special_remotes/>
+"""]]
diff --git a/doc/forum/adjustedbranchrefresh_ignored__63__.mdwn b/doc/forum/adjustedbranchrefresh_ignored__63__.mdwn
new file mode 100644
index 0000000000..42cf9e9060
--- /dev/null
+++ b/doc/forum/adjustedbranchrefresh_ignored__63__.mdwn
@@ -0,0 +1,50 @@
+In some occasions `annex.adjustedbranchrefresh` is ignored when `git annex sync` is run in a branch created with `adjust --unlock-present`.
+
+If `annex.adjustedbranchrefresh` is set to 1, one would expect git-annex to automatically adjust the branch once a file has been `git annex add`-ed or the repository is `git annex sync`-ed. However this does not happen and a manual `git annex adjust --unlock-present` is required.
+
+Is this a bug or am I misunderstanding how `annex.adjustedbranchrefresh` is supposed to work?
+
+The following script reproduces this bug.
+
+```
+#!/bin/bash
+
+set -eux
+
+rm -Rvf /tmp/an-repo.git && mkdir /tmp/an-repo.git && cd /tmp/an-repo.git
+git init --bare
+n=$(date +%s) ; mkdir /tmp/ga-$n && cd /tmp/ga-$n
+git clone --no-local --no-hardlinks /tmp/an-repo.git
+cd an-repo/
+
+git config user.email "email@example.com" ; git config user.name "Name Name"
+git config annex.thin true
+git config annex.adjustedbranchrefresh 1
+git config remote.origin.annex-ignore true
+
+# 8.20201117 is the version in the standalone tarball of 8.20201127
+~/Applications/git-annex/8.20201117-ga314537cd/runshell bash -c '
+git annex init foobar
+
+echo "aaaa" > a && echo "bbbb" > b
+git annex add a b
+git annex sync
+
+git annex adjust --unlock-present
+git annex sync
+
+echo "cccc" > c && echo "dddd" > d
+git annex add c d
+
+echo "## before sync"
+stat -c "%n: %F" a b c d
+
+git annex sync
+echo "## after sync"
+stat -c "%n: %F" a b c d # should show four regular files, but shows two files and two symlinks
+
+git annex sync --content;
+echo "## after sync --content"
+stat -c "%n: %F" a b c d # ibid
+'
+```
diff --git a/doc/forum/adjustedbranchrefresh_ignored__63__/comment_1_999bd4a511c7fa39f5455df895c435f3._comment b/doc/forum/adjustedbranchrefresh_ignored__63__/comment_1_999bd4a511c7fa39f5455df895c435f3._comment
new file mode 100644
index 0000000000..7e5bc31366
--- /dev/null
+++ b/doc/forum/adjustedbranchrefresh_ignored__63__/comment_1_999bd4a511c7fa39f5455df895c435f3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-01-04T20:49:40Z"
+ content="""
+I agree, this is a bug. Copied to
+[[bugs/adjustedbranchrefresh_ignored_by_git_annex_add]].
+"""]]
diff --git a/doc/forum/advantages_of_SHA__42___over_WORM.mdwn b/doc/forum/advantages_of_SHA__42___over_WORM.mdwn
new file mode 100644
index 0000000000..5b544593f5
--- /dev/null
+++ b/doc/forum/advantages_of_SHA__42___over_WORM.mdwn
@@ -0,0 +1,5 @@
+Thanks for creating git-annex.
+
+I am confused about the advantages of the SHA* backends over WORM.  The "backends" page in this wiki says that with WORM, files "can be moved around, but should never be added to or changed".  But I don't see any difference to SHA* files as long as the premise of WORM that "any file with the same basename, size, and modification time has the same content" is true.  Using "git annex unlock", WORM files can be modified in the same way as SHA* files.
+
+If the storage I use is dependable (i.e. I don't need SHA checksums for detection of corruption), and I don't need to optimize for the case that the modification date of a file is changed but the contents stay the same, and if it is unlikely that several files will be identical, is there actually any advantage in using SHA*?
diff --git a/doc/forum/advantages_of_SHA__42___over_WORM/comment_1_96c354cac4b5ce5cf6664943bc84db1d._comment b/doc/forum/advantages_of_SHA__42___over_WORM/comment_1_96c354cac4b5ce5cf6664943bc84db1d._comment
new file mode 100644
index 0000000000..218027ca53
--- /dev/null
+++ b/doc/forum/advantages_of_SHA__42___over_WORM/comment_1_96c354cac4b5ce5cf6664943bc84db1d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-08-29T16:10:38Z"
+ content="""
+You're right -- as long as nothing changes a file without letting the modification time update, editing WORM files is safe.
+"""]]
diff --git a/doc/forum/agent_keep_deleting_local_file.mdwn b/doc/forum/agent_keep_deleting_local_file.mdwn
new file mode 100644
index 0000000000..01fc9f365f
--- /dev/null
+++ b/doc/forum/agent_keep_deleting_local_file.mdwn
@@ -0,0 +1,24 @@
+I realize this is git 101, and I apologize in advance, but I honestly have no idea how to debug this.
+
+I have two Macs, with git annex assistant running headless on both. I renamed a file on one system somewhere along the line, and now whenever the assistant syncs changes from system B to system A, I always find myself in a situation like this:
+
+```
+On branch master
+Your branch is behind 'mbp/master' by 1 commit, and can be fast-forwarded.
+  (use "git pull" to update your local branch)
+
+Changes not staged for commit:
+  (use "git add/rm <file>..." to update what will be committed)
+  (use "git restore <file>..." to discard changes in working directory)
+	deleted:    myfile.md
+```
+
+This file was originally myfile-1234.md or whatever, but I renamed it on system A, and those changes were synced. Today, on system B, that file exists as myfile.md as I'd expect. On system A, however, it always gets deleted whenever I make changes made to any file on system B that the assistant then syncs over.
+
+I've tried re-adding the file and committing, but it continues to be deleted every time system B syncs changes to system A.
+
+I don't know what to do except abandon this file path completely and just use a different filename that git doesn't think is deleted on one of the systems; the correct solution to this eludes me.
+
+I appreciate any suggestions that you might have.
+
+Thanks.
diff --git a/doc/forum/alternativeto.net___34__Like__34__.mdwn b/doc/forum/alternativeto.net___34__Like__34__.mdwn
new file mode 100644
index 0000000000..95e03dc21e
--- /dev/null
+++ b/doc/forum/alternativeto.net___34__Like__34__.mdwn
@@ -0,0 +1,3 @@
+When I went to alternativeto.net I noticed that SpiderOak is a featured application. I decided to search git-annex and see how "Like"-ed it is in comparison... there were 0 "Like"-s.
+
+I suggest going to <http://alternativeto.net/software/git-annex/> and "Like" git-annex.
diff --git a/doc/forum/ancient_linux_build_for_arm__63__.mdwn b/doc/forum/ancient_linux_build_for_arm__63__.mdwn
new file mode 100644
index 0000000000..789c1285b7
--- /dev/null
+++ b/doc/forum/ancient_linux_build_for_arm__63__.mdwn
@@ -0,0 +1,5 @@
+Hello, 
+
+I have old Synology DS413j with ARM 32bit and Linux 2.6.32 version. I wanted to use some TB of my disk space for INTERNETARCHIVE.BAK project. Unfortunately, the "ancient linux" build is only for the i386 platform. Is there any chance for a custom build? 
+
+Rafal
diff --git a/doc/forum/ancient_linux_build_for_arm__63__/comment_1_c4ebfb2136bb4b3e21a52aa23717b22a._comment b/doc/forum/ancient_linux_build_for_arm__63__/comment_1_c4ebfb2136bb4b3e21a52aa23717b22a._comment
new file mode 100644
index 0000000000..d2060ac53f
--- /dev/null
+++ b/doc/forum/ancient_linux_build_for_arm__63__/comment_1_c4ebfb2136bb4b3e21a52aa23717b22a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="gb@4a49bb1afcf3d183bba8f07297b0395808768c6c"
+ nickname="gb"
+ avatar="http://cdn.libravatar.org/avatar/51ed40932fbf8748c70b31fd7446d40e"
+ subject="Is IA.BAK still active?"
+ date="2020-06-16T16:51:40Z"
+ content="""
+BTW, is INTERNETARCHIVE.BAK still active?
+
+The official page at https://www.archiveteam.org/index.php?title=INTERNETARCHIVE.BAK says
+
+> IA.BAK has been broken and unmaintained since about December 2016. The above status page (<http://iabak.archiveteam.org/>) is not accurate as of December 2019.
+"""]]
diff --git a/doc/forum/ancient_linux_build_for_arm__63__/comment_1_f5a7d7e4ac5d9885230d08684416cff4._comment b/doc/forum/ancient_linux_build_for_arm__63__/comment_1_f5a7d7e4ac5d9885230d08684416cff4._comment
new file mode 100644
index 0000000000..8d306400c8
--- /dev/null
+++ b/doc/forum/ancient_linux_build_for_arm__63__/comment_1_f5a7d7e4ac5d9885230d08684416cff4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-16T16:05:01Z"
+ content="""
+Unfortunately my attempt at this earlier failed
+<https://git-annex.branchable.com/todo/add_ancient_armel_build/>
+
+And of course ancient systems are not getting any better over time, so the
+only thing that would succeed is to move the goalposts up some, eg from
+armel to armhf (arm 7). But that would almost certianly need a newer kernel
+than 2.6.32 to support it.
+"""]]
diff --git a/doc/forum/android_-_assistant_-_local_pairing_.mdwn b/doc/forum/android_-_assistant_-_local_pairing_.mdwn
new file mode 100644
index 0000000000..23339bfa41
--- /dev/null
+++ b/doc/forum/android_-_assistant_-_local_pairing_.mdwn
@@ -0,0 +1,15 @@
+Hello!
+
+I'm trying to *local pair* a recent build of assistant (7.20190129-ge3dce20cf) on android with debian (6.20170101.1).
+
+Either way around one assistant doesn't show the pair request of the other.
+
+When the debian box initiates the pairing android can see [the packets](http://git-annex.branchable.com/assistant/local_pairing_walkthrough/#comment-3eb46bd30deac03bda8eaba18a85751c) (in tcpdump) but there's nothing in the webapp.
+When I try initiating the pairing from android no pairing packets seem to show up (this is using tcpdump on android. I didn't check on the Debian box - I'm assuming they have to exist on Android first).
+
+
+Termux needs the ssh server to be started manually (I'm using the openssh package). Termux is (by default) configured to run it as the termux user, so it's on port 8022. I can ssh to that from debian.
+
+The Termux shell shows the hostname as "localhost" because that's what gethostname() returns (<https://github.com/termux/termux-packages/issues/352#issuecomment-458278586>). Could that be causing problems?
+
+What can I try next?
diff --git a/doc/forum/android_binary-only_download.mdwn b/doc/forum/android_binary-only_download.mdwn
new file mode 100644
index 0000000000..90204fbf42
--- /dev/null
+++ b/doc/forum/android_binary-only_download.mdwn
@@ -0,0 +1,9 @@
+It would be really neat if there was a way to get just the `git-annex` binary on Android, without getting the entire APK. This can be useful when one is already using their own shell and rootfs, for example I work with <a href="https://sites.google.com/site/taldewandroid/">this</a>.
+
+This way, one can just use parts of git-annex, without having to have a whole APK and its dependencies, and the space it takes up, etc.
+
+So would you be able to add a download link for this?
+
+
+
+Thanks for the wonderful project!
diff --git a/doc/forum/android_binary-only_download/comment_1_aab206e0bf0bb5ff47c7cc9795f12f92._comment b/doc/forum/android_binary-only_download/comment_1_aab206e0bf0bb5ff47c7cc9795f12f92._comment
new file mode 100644
index 0000000000..d8e6d81fce
--- /dev/null
+++ b/doc/forum/android_binary-only_download/comment_1_aab206e0bf0bb5ff47c7cc9795f12f92._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 1"
+ date="2013-07-02T16:57:43Z"
+ content="""
+This seems a pretty unusual use case. Can't you just unpack the apk (it's a regular zip file) and get out the parts you want?
+"""]]
diff --git a/doc/forum/android_installation.mdwn b/doc/forum/android_installation.mdwn
new file mode 100644
index 0000000000..448478e84b
--- /dev/null
+++ b/doc/forum/android_installation.mdwn
@@ -0,0 +1,7 @@
+I tried to install using termux (from F-Droid).
+
+On running source git-annex-install i get
+ unknown architecture armv81, cannot install
+
+actually, I have no idea whats going on.
+
diff --git a/doc/forum/android_installation/comment_1_8908256ecd48d7b5207799aa02102d87._comment b/doc/forum/android_installation/comment_1_8908256ecd48d7b5207799aa02102d87._comment
new file mode 100644
index 0000000000..2c1b952409
--- /dev/null
+++ b/doc/forum/android_installation/comment_1_8908256ecd48d7b5207799aa02102d87._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-09T15:25:24Z"
+ content="""
+The installer is running the command `uname -m` to find out what kind of
+processor your Android device has. It doesn't recognize "armv81"
+
+What you can try is to open the git-annex-install
+script in a text editor, and add a case under `uname -m` for
+"armv81". My guess is that this would work:
+
+	armv81) arch=arm64 ;;
+
+Or maybe this:
+
+	armv81) arch=arm ;;
+"""]]
diff --git a/doc/forum/android_installation/comment_2_3c2a1e7542993528250ad72079894364._comment b/doc/forum/android_installation/comment_2_3c2a1e7542993528250ad72079894364._comment
new file mode 100644
index 0000000000..d6090ba162
--- /dev/null
+++ b/doc/forum/android_installation/comment_2_3c2a1e7542993528250ad72079894364._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="tritigr"
+ avatar="http://cdn.libravatar.org/avatar/b48e7ad14f74123cd33968fc1b747cb5"
+ subject="comment 2"
+ date="2018-12-10T21:28:59Z"
+ content="""
+Hi Joey,
+
+thanks for helping.
+Unfortunately, installation with arm64 fails with something that 64bit executables are not supported.
+using \"armel\" installation seems ok, (\"git-annex is sucessfully installed; installation complete\")
+
+but then \"git annex webapp\" gives
+git: 'annex' is not a git command
+
+using \"arm\" (without the \"el\") gives Error 404 on downloading, so I guess you really meant \"armel\" (32 bits)
+
+Til
+"""]]
diff --git a/doc/forum/annex.largefile_include_from_file.mdwn b/doc/forum/annex.largefile_include_from_file.mdwn
new file mode 100644
index 0000000000..47e6b4bc1a
--- /dev/null
+++ b/doc/forum/annex.largefile_include_from_file.mdwn
@@ -0,0 +1,5 @@
+Hello!
+
+&nbsp;&nbsp;&nbsp;&nbsp; Is it possible to configure `annex.largefiles` to include or exclude any patterns from a file?
+
+Thank you kindly for the help!
diff --git a/doc/forum/annex.largefile_include_from_file/comment_1_9016a64a654151ab9a478686382193b4._comment b/doc/forum/annex.largefile_include_from_file/comment_1_9016a64a654151ab9a478686382193b4._comment
new file mode 100644
index 0000000000..934e3fe9cb
--- /dev/null
+++ b/doc/forum/annex.largefile_include_from_file/comment_1_9016a64a654151ab9a478686382193b4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2020-02-20T01:09:55Z"
+ content="""
+You can set it in `.gitattributes`, or with [[git-annex-config]].
+"""]]
diff --git a/doc/forum/annex.largefile_include_from_file/comment_2_09258e59eab492afc37efeac325c2de1._comment b/doc/forum/annex.largefile_include_from_file/comment_2_09258e59eab492afc37efeac325c2de1._comment
new file mode 100644
index 0000000000..09cfc8be6c
--- /dev/null
+++ b/doc/forum/annex.largefile_include_from_file/comment_2_09258e59eab492afc37efeac325c2de1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="titaniumfiles@5227364ee3e2f9207bc36b6ebb281fc7af6d3c16"
+ nickname="titaniumfiles"
+ avatar="http://cdn.libravatar.org/avatar/067eaf551eb18de259f4d88966622326"
+ subject="comment 2"
+ date="2020-02-20T02:02:05Z"
+ content="""
+But how would I get `include` to read from a file?
+"""]]
diff --git a/doc/forum/annex.largefile_include_from_file/comment_3_f857505bde5f03d9c17e8df0512c0e99._comment b/doc/forum/annex.largefile_include_from_file/comment_3_f857505bde5f03d9c17e8df0512c0e99._comment
new file mode 100644
index 0000000000..82b3ee9167
--- /dev/null
+++ b/doc/forum/annex.largefile_include_from_file/comment_3_f857505bde5f03d9c17e8df0512c0e99._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2020-02-20T03:50:50Z"
+ content="""
+Why, exactly, do you need to do that?   Can you say more about your scenario?
+"""]]
diff --git a/doc/forum/annex.largefile_include_from_file/comment_4_f9c2acc07dad646cd04a51ca85f45502._comment b/doc/forum/annex.largefile_include_from_file/comment_4_f9c2acc07dad646cd04a51ca85f45502._comment
new file mode 100644
index 0000000000..523a2c2317
--- /dev/null
+++ b/doc/forum/annex.largefile_include_from_file/comment_4_f9c2acc07dad646cd04a51ca85f45502._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="titaniumfiles@5227364ee3e2f9207bc36b6ebb281fc7af6d3c16"
+ nickname="titaniumfiles"
+ avatar="http://cdn.libravatar.org/avatar/067eaf551eb18de259f4d88966622326"
+ subject="comment 4"
+ date="2020-02-20T19:34:24Z"
+ content="""
+Sorry for the delay; basically, since I'm using git submodules inside the annex repo as well, while I might want to exclude certain files from my submodules, I still want them in the root annex repository; so I want to read all exclusions from, at the very least, the global `~/.gitignore` (which I *think* also affects `git annex`?) so that when adding to the annex, I'd still have the excluded files when cloning somewhere else.
+
+As a side question, does `git annex` honor `.gitignores` in sub-directories as well, for excluding files in said sub-directories?
+"""]]
diff --git a/doc/forum/annex.largefile_not_working.mdwn b/doc/forum/annex.largefile_not_working.mdwn
new file mode 100644
index 0000000000..d15de6b022
--- /dev/null
+++ b/doc/forum/annex.largefile_not_working.mdwn
@@ -0,0 +1,20 @@
+I seem to be having issues with annex.largefiles.  I initialize git and the annex, then I set largefiles to put everything in the annex, generate a 1Mb file, `git add` it, and commit it.  The file is copied and renamed to its hash value in .git/annex/objects but the file also remains in the main directory instead of being replaced with a symlink.  Here are my steps to create the issue:
+
+    git init
+    git annex init
+    git annex config --set annex.largefiles anything
+    fallocate -l 1M test.bin
+    git add test.bin
+    git commit -a -m "Test"
+
+I've also tried creating a .gitattributes file in the main directory with the following attribute:
+
+    * annex.largefiles=anything
+
+Still, nothing is symlinked.
+
+It works just fine when I run `git annex add test.bin`.  It puts the file in the annex and creates a symlink to it.
+
+I've tried this on Fedora 39 with git annex version 10.20230626 and on Ubuntu 22.04.2 LTS with git annex version 8.20210223.  These are both fresh machines that have never had git or git-annex run on them before.
+
+What am I doing wrong here?  Should I be filing a bug report?
diff --git a/doc/forum/annex.largefile_not_working/comment_1_b2ecb8b60603929bae91c3007817585f._comment b/doc/forum/annex.largefile_not_working/comment_1_b2ecb8b60603929bae91c3007817585f._comment
new file mode 100644
index 0000000000..200a8dcdce
--- /dev/null
+++ b/doc/forum/annex.largefile_not_working/comment_1_b2ecb8b60603929bae91c3007817585f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="comment 1"
+ date="2023-12-04T10:09:15Z"
+ content="""
+I think this is intended behavior when adding with `git add`, or at least it's what I've seen for long enough for me to have forgotten if it ever was different. `git annex add` will create symlinks, as will `git add  && git annex lock`.
+
+If this was actually a small file, you wouldn't see it hashed & copied under .git/annex/objects. You should also see in git log that the change is an addition of some git annex key, not a git blob diff as would be the case for a small file.
+
+NB: I'm just another user, @joey please correct me if this is wrong
+"""]]
diff --git a/doc/forum/annex.largefile_not_working/comment_2_18bc73688897728d0bcae6df1225e6e3._comment b/doc/forum/annex.largefile_not_working/comment_2_18bc73688897728d0bcae6df1225e6e3._comment
new file mode 100644
index 0000000000..22eb0c3027
--- /dev/null
+++ b/doc/forum/annex.largefile_not_working/comment_2_18bc73688897728d0bcae6df1225e6e3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-12-04T16:48:09Z"
+ content="""
+`git add` always adds the annexed file unlocked. You can `git-annex lock`
+the file is you want to convert it to a symlink.
+
+(The reason for this difference between `git add` and `git-annex add` is
+that there's simply no way for git-annex to tell `git add` to make the file
+be a symlink.)
+"""]]
diff --git a/doc/forum/annex.largefile_not_working/comment_3_81085c1a526ac804edba689043e58944._comment b/doc/forum/annex.largefile_not_working/comment_3_81085c1a526ac804edba689043e58944._comment
new file mode 100644
index 0000000000..d37f196648
--- /dev/null
+++ b/doc/forum/annex.largefile_not_working/comment_3_81085c1a526ac804edba689043e58944._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="brendan.ward@a2e11ad27f6b2fa2c556aea6811496e0d95dd0da"
+ nickname="brendan.ward"
+ avatar="http://cdn.libravatar.org/avatar/bc7899f1aa523365cdfadc2ba3f7913d"
+ subject="comment 3"
+ date="2023-12-05T03:24:29Z"
+ content="""
+Excellent.  Thanks for the help!
+"""]]
diff --git a/doc/forum/annex.largefiles__58___two_quesitons.mdwn b/doc/forum/annex.largefiles__58___two_quesitons.mdwn
new file mode 100644
index 0000000000..170aad7e63
--- /dev/null
+++ b/doc/forum/annex.largefiles__58___two_quesitons.mdwn
@@ -0,0 +1,9 @@
+Hi,
+
+I have two questions related to `annex.largefiles`, for which I was unable to find the answers.
+
+1. Is there a way to transfer my `annex.largefiles` from one repo to the other?  I noticed that the property was not adopted when cloning a repo.
+2. On one repo I noticed that I had not set a good `annex.largefiles`.  Can I tell `git annex` to *reevaluate* whether a file should be controlled as a "normal" file or a "largefile" give the updated `annex.largefiles`?
+
+Thanks,
+Rasmus
diff --git a/doc/forum/annex.largefiles__58___two_quesitons/comment_1_75fc6cd2315e9ad6897b94bcc527ddc1._comment b/doc/forum/annex.largefiles__58___two_quesitons/comment_1_75fc6cd2315e9ad6897b94bcc527ddc1._comment
new file mode 100644
index 0000000000..2be567c397
--- /dev/null
+++ b/doc/forum/annex.largefiles__58___two_quesitons/comment_1_75fc6cd2315e9ad6897b94bcc527ddc1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-26T15:56:59Z"
+ content="""
+1. No, annex.largefiles is a local git repository configuration.
+
+2. If you have a specific file in mind, and it is currently stored in the
+annex, you can always `git annex unannex $file` and then `git annex add` it
+back, which will re-check the current annex.largefiles configuration.
+"""]]
diff --git a/doc/forum/annex.largefiles__58___two_quesitons/comment_2_f34cf28c3f8354e6fc055d4dba6ed555._comment b/doc/forum/annex.largefiles__58___two_quesitons/comment_2_f34cf28c3f8354e6fc055d4dba6ed555._comment
new file mode 100644
index 0000000000..ab02f0e4a2
--- /dev/null
+++ b/doc/forum/annex.largefiles__58___two_quesitons/comment_2_f34cf28c3f8354e6fc055d4dba6ed555._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="cstork"
+ subject="comment 2"
+ date="2016-04-21T06:46:40Z"
+ content="""
+Just to prevent a potential misunderstanding: There are two ways to configure annex.largefiles.
+
+1. in `.git/config`, e.g., via `git config annex.largefiles=...`
+2. in `.gitattributes`
+
+The first configuration is specific to your local copy of the repository and does not travel with the content,
+whereas the second one does carry the configuration over to the other repos.
+"""]]
diff --git a/doc/forum/annex_merge_creates___34__synced__47____42____34___branches.mdwn b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches.mdwn
new file mode 100644
index 0000000000..b4f02bc565
--- /dev/null
+++ b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches.mdwn
@@ -0,0 +1,7 @@
+Hi,
+
+when I fetch from a central repository and `git annex merge` a synced/master branch is created. How can I disable this behaviour?
+
+Or is there a better workflow for getting and pushing updates from/to a central git repo?
+
+bye
diff --git a/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_1_4667fadb05c594b0a212bf455ee65298._comment b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_1_4667fadb05c594b0a212bf455ee65298._comment
new file mode 100644
index 0000000000..90643ca9b6
--- /dev/null
+++ b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_1_4667fadb05c594b0a212bf455ee65298._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 1"
+ date="2014-09-16T18:22:11Z"
+ content="""
+Why is this a problem? You can delete the branch at any time of course if it's in the way.
+
+It would be possible for `git-annex sync` to avoid creating the synced/master branch at all when syncing with a bare git repository, but this would actually make it less efficient and slower. Where currently it makes one push, updating the remote's master branch when possible, and forcing an update of its synced/master branch at the same time, it would instead need to first try to update remote's master, then check if that succeeded and if not force the update of synced/master. Also, it's not clear how to check if the push to master succeeded, since something else might update it further in a race.
+
+I suppose that `git annex sync/merge` could delete the local synced/* branches once it was done merging them. This wouldn't prevent `git pull` from pulling down those branches, though.
+"""]]
diff --git a/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_2_cb6971a766a28bd8c094d0b986272c65._comment b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_2_cb6971a766a28bd8c094d0b986272c65._comment
new file mode 100644
index 0000000000..5db94a7a00
--- /dev/null
+++ b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_2_cb6971a766a28bd8c094d0b986272c65._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlog_5wIICaMcrKTexlFNA6IO6UTp323aE"
+ nickname="Torkaly"
+ subject="comment 2"
+ date="2014-09-17T08:47:03Z"
+ content="""
+Thank you for the answer.
+
+There are no origin/synced/* branches, only a origin/git-annex and the local git-annex branch. What i need git annex merge to do, is to merge the fetched remote git-annex with the local git-annex. There is no need for creating or merging the synced-branches as there are no.
+
+"""]]
diff --git a/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_3_1a0384edd20cc379e53fe7d7f650f7e2._comment b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_3_1a0384edd20cc379e53fe7d7f650f7e2._comment
new file mode 100644
index 0000000000..cb80c07f9f
--- /dev/null
+++ b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_3_1a0384edd20cc379e53fe7d7f650f7e2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-09-18T17:39:19Z"
+ content="""
+`git annex merge` does not create any synced/* branches. These branches will be pulled down by `git pull` or `git annex sync`.
+"""]]
diff --git a/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_4_79219e920a6beb4bd3265571f59f51cb._comment b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_4_79219e920a6beb4bd3265571f59f51cb._comment
new file mode 100644
index 0000000000..8e07649484
--- /dev/null
+++ b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_4_79219e920a6beb4bd3265571f59f51cb._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlog_5wIICaMcrKTexlFNA6IO6UTp323aE"
+ nickname="Torkaly"
+ subject="comment 4"
+ date="2014-09-19T18:22:36Z"
+ content="""
+delete the *synced/master* branch:
+```
+$ git branch -d synced/master
+Branch synced/master entfernt (war 20ec8b3).
+```
+
+then call *annex merge*:
+```
+$ git annex merge
+merge git-annex ok
+```
+
+check branches:
+```
+$ git branch -a
+  git-annex
+* master
+  synced/master
+  remotes/origin/git-annex
+  remotes/origin/master
+```
+and there is the *synced/master* branch again.
+
+But that's not my problem. My problem was: how to use annex with a central repository.
+I done that by deleting all remote synced/* branches. And now I'm updating the git-annex branch by `git fetch`ing and
+`git annex merge`ing again.
+
+PS: the MD for code blocks is broken
+
+"""]]
diff --git a/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_5_39009651c3f65e2ecd225e17d157c8d8._comment b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_5_39009651c3f65e2ecd225e17d157c8d8._comment
new file mode 100644
index 0000000000..488f3ae7b3
--- /dev/null
+++ b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_5_39009651c3f65e2ecd225e17d157c8d8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-07-07T19:20:17Z"
+ content="""
+So, I was wrong about `git annex merge` creating the synced/master branch.
+
+There's no good reason for it to do that, so I've fixed it not to create
+it.
+"""]]
diff --git a/doc/forum/annexed_file_key_for_web_remote_with_SHA256E_backend.mdwn b/doc/forum/annexed_file_key_for_web_remote_with_SHA256E_backend.mdwn
new file mode 100644
index 0000000000..6c428e3752
--- /dev/null
+++ b/doc/forum/annexed_file_key_for_web_remote_with_SHA256E_backend.mdwn
@@ -0,0 +1,12 @@
+First off, thanks so much for your hard work, git-annex is amazing.
+
+I just started using the [web as a special remote](http://git-annex.branchable.com/tips/using_the_web_as_a_special_remote/) feature with the SHA256E backend, and I noticed that although the annexed file has the correct backend prefix (SHA256E) it does not have the extension of the file in the URL. The URL is `https://...IMG_1234.JPG` but the annexed file is `SHA256E-...832c99` with no extension.
+
+This is fine for most use cases, but I actually access an S3 remote directly from another app (independent of git-annex) to render photos, and in that app I'm using the extensions to figure out file types, so not having that info is slightly inconvenient.
+
+Is there any way to either:
+
+1. tell git-annex to preserve the extension of a file on the web in the annexed file, or
+2. alternatively, change the annexed filename (add the extension manually) without screwing anything up?
+
+Any help would be much appreciated, thanks!
diff --git a/doc/forum/annexed_file_key_for_web_remote_with_SHA256E_backend/comment_1_d1605a6e3b4d6863f4089218994ce564._comment b/doc/forum/annexed_file_key_for_web_remote_with_SHA256E_backend/comment_1_d1605a6e3b4d6863f4089218994ce564._comment
new file mode 100644
index 0000000000..8b78618a94
--- /dev/null
+++ b/doc/forum/annexed_file_key_for_web_remote_with_SHA256E_backend/comment_1_d1605a6e3b4d6863f4089218994ce564._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-06T15:43:06Z"
+ content="""
+You don't say what version of git-annex you're using. I tested with the current version, 4.20130405:
+
+[[!format sh \"\"\"
+joey@gnu:~/tmp/rr>git annex addurl http://localhost/~joey/header_background.png
+addurl localhost_~joey_header_background.png (downloading http://localhost/~joey/header_background.png ...) --2013-05-06 11:36:41--  http://localhost/~joey/header_background.png
+Resolving localhost (localhost)... ::1, 127.0.0.1, 127.0.1.1
+Connecting to localhost (localhost)|::1|:80... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 53693 (52K) [image/png]
+Saving to: ‘/home/joey/tmp/rr/.git/annex/tmp/URL--http&c%%localhost%~joey%header_background.png’
+
+100%[======================================>] 53,693      --.-K/s   in 0.001s  
+
+2013-05-06 11:36:41 (58.9 MB/s) - '/home/joey/tmp/rr/.git/annex/tmp/URL--http&c%%localhost%~joey%header_background.png' saved [53693/53693]
+
+(checksum...) ok
+(Recording state in git...)
+joey@gnu:~/tmp/rr>dir
+lrwxrwxrwx   1 joey joey  194 Sep 11  2010 localhost_~joey_header_background.png -> .git/annex/objects/M1/p0/SHA256E-s53693--3f065e8e2db1248765d0753cf483e40ae0eaf9bffe34b0cf738158815d0884e3.png/SHA256E-s53693--3f065e8e2db1248765d0753cf483e40ae0eaf9bffe34b0cf738158815d0884e3.png
+\"\"\"]]
+
+Looks like it's doing the right thing with the extension!
+"""]]
diff --git a/doc/forum/annexed_file_key_for_web_remote_with_SHA256E_backend/comment_2_d249ff27fa3d9ac3ca32485cdef49930._comment b/doc/forum/annexed_file_key_for_web_remote_with_SHA256E_backend/comment_2_d249ff27fa3d9ac3ca32485cdef49930._comment
new file mode 100644
index 0000000000..3d5814bc68
--- /dev/null
+++ b/doc/forum/annexed_file_key_for_web_remote_with_SHA256E_backend/comment_2_d249ff27fa3d9ac3ca32485cdef49930._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnkBYpLu_NOj7Uq0-acvLgWhxF8AUEIJbo"
+ nickname="Chris"
+ subject="comment 2"
+ date="2013-05-07T03:37:24Z"
+ content="""
+Thanks very much! That's great news. I'm using 3.20120629, I'll just update then.
+"""]]
diff --git a/doc/forum/archaeology_of_deleted_files.mdwn b/doc/forum/archaeology_of_deleted_files.mdwn
new file mode 100644
index 0000000000..a4ed66dc81
--- /dev/null
+++ b/doc/forum/archaeology_of_deleted_files.mdwn
@@ -0,0 +1,36 @@
+Earlier this week, I somehow lost a ton of files from my annex -- by switching on the command line from indirect to direct mode while the assistant was running, I think. I'm not sure.
+
+Anyway, by "lost" I mean "lost the symlinks to," because git-annex defaults to keeping content around till you tell it otherwise.  So I still had the content in the repos on my two backup drives.  All I needed was the symlinks back.
+
+But how to figure out exactly what I lost and get it back?
+
+I found that out here:
+
+http://stackoverflow.com/questions/953481/restore-a-deleted-file-in-a-git-repo
+
+Here's a magical formula you can use to find every single file deletion in the history of your repo:
+
+    git log --diff-filter=D --summary 
+
+That will give you every commit that deleted things, and what was deleted.
+
+To bring back all the files deleted in a given commit, where COMMITHASH is the commit hash, use this command:
+
+    git checkout COMMITHASH^1 -- .
+
+to bring back only a specific file:
+
+    git checkout COMMITHASH^1 -- path/to/file.txt
+
+to bring back only a subdirectory:
+
+    git checkout COMMITHASH^1 -- sub/directory
+
+that will bring them back into the staging area.  You can see which ones just reappeared by typing:
+
+    git status
+
+then you can actually make the restore permanent by typing: 
+
+    git commit -m "I just resurrected some files"
+
diff --git a/doc/forum/archaeology_of_deleted_files/comment_1_48f27df03ec18d2c27cf6b70dcf71dc5._comment b/doc/forum/archaeology_of_deleted_files/comment_1_48f27df03ec18d2c27cf6b70dcf71dc5._comment
new file mode 100644
index 0000000000..3647193b85
--- /dev/null
+++ b/doc/forum/archaeology_of_deleted_files/comment_1_48f27df03ec18d2c27cf6b70dcf71dc5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 1"
+ date="2013-01-25T14:07:36Z"
+ content="""
+seems I inadvertently got caught by Markdown -- I tried to write COMMITHASH-hat-1 and it turned into COMMITHASH superscript 1.
+
+Tilde (~) would also have worked instead of hat (^)
+"""]]
diff --git a/doc/forum/archaeology_of_deleted_files/comment_2_c698cd10c8038bac45bd1049506a27c3._comment b/doc/forum/archaeology_of_deleted_files/comment_2_c698cd10c8038bac45bd1049506a27c3._comment
new file mode 100644
index 0000000000..363d320791
--- /dev/null
+++ b/doc/forum/archaeology_of_deleted_files/comment_2_c698cd10c8038bac45bd1049506a27c3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 2"
+ date="2013-01-25T14:27:47Z"
+ content="""
+I fixed it for you
+"""]]
diff --git a/doc/forum/archival_and_multiple_users.mdwn b/doc/forum/archival_and_multiple_users.mdwn
new file mode 100644
index 0000000000..da451d9fb9
--- /dev/null
+++ b/doc/forum/archival_and_multiple_users.mdwn
@@ -0,0 +1,8 @@
+The assistant archival walk-through describes how files get removed from local repo if moved into archive repos.
+What if the files in question aren't needed immediately (and can be archived) for one user of a shared repo, but needed by someone else on their own machine?
+git-annex directory arrangement propagation wouldn't work for this case, it seems.  Could assistant handle this case?
+
+It looks like having a browser of the directory tree in git-annex assistant webpage with say right-click menu with "get" and "drop" would be the most flexible.
+
+Or maybe it could be more about integration with Linux etc file browsers (but then it's system specific, unlike with webapp).
+
diff --git a/doc/forum/archival_and_multiple_users/comment_1_fc4ee256f03a7c189d687caf4a34e21e._comment b/doc/forum/archival_and_multiple_users/comment_1_fc4ee256f03a7c189d687caf4a34e21e._comment
new file mode 100644
index 0000000000..090091a8a6
--- /dev/null
+++ b/doc/forum/archival_and_multiple_users/comment_1_fc4ee256f03a7c189d687caf4a34e21e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 1"
+ date="2013-07-24T15:30:51Z"
+ content="""
+A feature I would love to see is a file manager integrated with the webapp, so that you could browse your files and retrieve or drop them manually as if you were using the command line.  Then you could have your repo set on \"manual\" and not worry about those archive directories.  Just manually drop content if you got low on space.
+
+"""]]
diff --git a/doc/forum/archival_and_multiple_users/comment_2_a96d57d4bb567ac9b0b9167d5b1be011._comment b/doc/forum/archival_and_multiple_users/comment_2_a96d57d4bb567ac9b0b9167d5b1be011._comment
new file mode 100644
index 0000000000..cf97f28fdb
--- /dev/null
+++ b/doc/forum/archival_and_multiple_users/comment_2_a96d57d4bb567ac9b0b9167d5b1be011._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 2"
+ date="2013-07-25T18:42:59Z"
+ content="""
+I believe that the world has enough (or too many) file managers, and do not want to build another one just for git-annex. In any case \"git annex get\" or any GUI wrapping around it is not going to help with the described use case, because the problem is that the files are archived away in my offline drive, while you want to access them in your repository, which does not have access to that drive.
+
+The way to handle this situation is to copy or move the files you want out of the archive directory, and back to the parent directory. This move of the file will be synced from your repository to all the other repositories. When the repository that does have access to the archive notices this, it will get the files that have been moved out of the archive. Normal assistant syncing will then arrange to get them transferred back to the repository of the user who had wanted them.
+
+Of course, if the archive is on an offline drive, this won't happen until that drive is plugged back in.
+"""]]
diff --git a/doc/forum/archival_and_multiple_users/comment_3_bd44634b04732ffb91154c61ef9cf828._comment b/doc/forum/archival_and_multiple_users/comment_3_bd44634b04732ffb91154c61ef9cf828._comment
new file mode 100644
index 0000000000..20b67976e0
--- /dev/null
+++ b/doc/forum/archival_and_multiple_users/comment_3_bd44634b04732ffb91154c61ef9cf828._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 3"
+ date="2013-07-25T19:16:20Z"
+ content="""
+> The way to handle this situation is to copy or move the files you want out of the archive directory, and back to the parent directory. This move of the file will be synced from your repository to all the other repositories. When the repository that does have access to the archive notices this, it will get the files that have been moved out of the archive. Normal assistant syncing will then arrange to get them transferred back to the repository of the user who had wanted them.
+
+But won't it also transfer the same files into repos of all other users (who didn't want the files)?
+On a related note, allowing moving files for everyone could jeopardise integrity of the master archive.  Is there a way to limit what kind of ops the users can do (e.g. copy but not move)?
+
+Re offline drives, the case I was thinking of is actually where each user has access to e.g. special remotes directly.  So a manual get/put would solve the problem at hand.
+
+"""]]
diff --git a/doc/forum/archival_and_multiple_users/comment_4_b89a56a5f1cd641f87925c7a5f74bcec._comment b/doc/forum/archival_and_multiple_users/comment_4_b89a56a5f1cd641f87925c7a5f74bcec._comment
new file mode 100644
index 0000000000..332e0a0a00
--- /dev/null
+++ b/doc/forum/archival_and_multiple_users/comment_4_b89a56a5f1cd641f87925c7a5f74bcec._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 4"
+ date="2013-07-25T19:23:30Z"
+ content="""
+Moving files shouldn't jepardize anything. If a user makes a change they shouldn't have made, it can be reverted.
+
+If you have the archive drive available locally you can set your repository to manual mode and just use `git annex get` on content you want. Or you could set it to be a backup repository and the assistant would get all content.
+Or write a custom [[preferred_content]] expression for your repository to make it want files in `archive/stillusing/`
+
+
+"""]]
diff --git a/doc/forum/archival_and_multiple_users/comment_5_81293bf5dc8ad4552712c2083fd589c9._comment b/doc/forum/archival_and_multiple_users/comment_5_81293bf5dc8ad4552712c2083fd589c9._comment
new file mode 100644
index 0000000000..b7b93fdf4b
--- /dev/null
+++ b/doc/forum/archival_and_multiple_users/comment_5_81293bf5dc8ad4552712c2083fd589c9._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="comment 5"
+ date="2013-07-26T08:20:21Z"
+ content="""
+I think i agree that this should be implemented.
+
+Not only to be able to \"get/drop\" from the assistant without the use of archive folders.
+
+But mainly because i think this will be needed anyways, to do a \"recover previous version of file\" option. Which should definitely be in the web assistant.
+
+We can't expect family and friends to figure out all command line stuff, thus they need to use the assistant. And i really think it would be a shame to not have an easy way to recover old versions, when the old versions are actually stored.
+
+Always think about having a good WAF(Wife acceptance factor).
+
+Just my 2 bits (and a haircut).
+
+"""]]
diff --git a/doc/forum/armhf_binary.mdwn b/doc/forum/armhf_binary.mdwn
new file mode 100644
index 0000000000..442fb121d2
--- /dev/null
+++ b/doc/forum/armhf_binary.mdwn
@@ -0,0 +1,3 @@
+Does a armhf binary tarball exist anywhere? I'm running Ubuntu trusty on a armhf platform (beagleboard), and the repository package is out of date. I might try to get the standalone armel binary working using multiarch, but that seems only slightly less painful than compiling from scratch.
+
+Or am I better off changing to a debian boot image, and be done with it?
diff --git a/doc/forum/armhf_binary/comment_1_9ca7ff6cb1f5dfc1e5ce8527e7e0a45f._comment b/doc/forum/armhf_binary/comment_1_9ca7ff6cb1f5dfc1e5ce8527e7e0a45f._comment
new file mode 100644
index 0000000000..9a1e3a4af5
--- /dev/null
+++ b/doc/forum/armhf_binary/comment_1_9ca7ff6cb1f5dfc1e5ce8527e7e0a45f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 1"
+ date="2014-08-15T15:58:02Z"
+ content="""
+The standalone armel build should work fine on armhf, assuming that the kernel supports EABI, which I'm pretty sure it does (or multiarch armel would not work).
+"""]]
diff --git a/doc/forum/armhf_binary/comment_2_743ecf263d1ec1bc4f24e32c0a178f2b._comment b/doc/forum/armhf_binary/comment_2_743ecf263d1ec1bc4f24e32c0a178f2b._comment
new file mode 100644
index 0000000000..864d5f23c7
--- /dev/null
+++ b/doc/forum/armhf_binary/comment_2_743ecf263d1ec1bc4f24e32c0a178f2b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="justinl"
+ ip="184.17.213.135"
+ subject="works"
+ date="2014-09-10T17:59:48Z"
+ content="""
+Yep, the standalone armel build worked perfectly. Thanks!
+"""]]
diff --git a/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__.mdwn b/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__.mdwn
new file mode 100644
index 0000000000..e48bf4cf6b
--- /dev/null
+++ b/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__.mdwn
@@ -0,0 +1,10 @@
+Hi,
+
+I am trying to understand git-annex, and the walkthroughs on the page did help a lot. I *feel* that git-annex is the solution for my use case: having a large archive, several computers, NAS both at work and at home, being offline during commuting, …
+
+Everything seems to be clear for me when using the command line version. Using annex assistant looks promising, and it is easy to create repositories that match my usage. But now I see that these repositories are in direct mode by default; and I am not sure how this impacts my ability to work with large files. I do not want to end up with git (without annex) handling huge files.
+
+So - can somebody explain how direct mode affects this? Can I switch to indirect mode with the assistant? Am I asking the wrong questions? 
+
+thanks,
+Ulli
diff --git a/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_1_d90d1d599ce557af03c6f0f2ea188212._comment b/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_1_d90d1d599ce557af03c6f0f2ea188212._comment
new file mode 100644
index 0000000000..d762791da1
--- /dev/null
+++ b/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_1_d90d1d599ce557af03c6f0f2ea188212._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 1"
+ date="2013-11-09T17:36:01Z"
+ content="""
+Files in direct mode are stored in the git annex the same way as when using indirect mode. But you're perhaps right to be wary of using direct mode, it's been quite easy to mess up while using it at the command line until very recently when the [[todo/direct_mode_guard]] was implemented.
+
+You can switch repositories created using the assistant from direct to indirect mode if you like. The assistant works in either mode.
+"""]]
diff --git a/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_2_58b1af497cab132acb28cb5f9283ec2a._comment b/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_2_58b1af497cab132acb28cb5f9283ec2a._comment
new file mode 100644
index 0000000000..45cec4db56
--- /dev/null
+++ b/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_2_58b1af497cab132acb28cb5f9283ec2a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkXtBdMgE1d9nCz2iBc4f85xh4izZ_auU"
+ nickname="Ulrich"
+ subject="Thanks"
+ date="2013-11-12T08:57:36Z"
+ content="""
+Ok, thanks for the explanation. I still have to figure out what happens when I annex drop files on a direct repository, and how well all this plays with the Finder on Mac…
+"""]]
diff --git a/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_3_37d4fd8f69e8066b5aa19454b714e443._comment b/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_3_37d4fd8f69e8066b5aa19454b714e443._comment
new file mode 100644
index 0000000000..71a0919303
--- /dev/null
+++ b/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_3_37d4fd8f69e8066b5aa19454b714e443._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkXtBdMgE1d9nCz2iBc4f85xh4izZ_auU"
+ nickname="Ulrich"
+ subject="So what does &quot;git annex drop&quot; do in direct mode?"
+ date="2013-11-15T15:07:57Z"
+ content="""
+I just tried a git annex drop on a file in a direct mode repository, and that just did not change anything at all, as far as I can see. Actually I don't know what to expect, but doesn't that mean that I should have to switch to indirect mode in order to be able to drop large files to save space? 
+
+Funny is that git annex drop did not complain at all but just reported \"ok\" after quite a while. And when I tried to drop a file that was not available in any other repository, it failed (which is expected behavior). So what is it what was \"ok\"?
+
+"""]]
diff --git a/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_4_a974e2105774d4f82ad286ff0792ba84._comment b/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_4_a974e2105774d4f82ad286ff0792ba84._comment
new file mode 100644
index 0000000000..587d704d38
--- /dev/null
+++ b/doc/forum/assistant__44___direct_mode__44___large_files__44___command_line_-_how_do_these_play_together__63__/comment_4_a974e2105774d4f82ad286ff0792ba84._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 4"
+ date="2013-11-15T20:33:47Z"
+ content="""
+Drop in direct mode does the same thing as in indirect mode.
+
+If you are using git-annex on a crippled filesystem without symlinks, git-annex cannot represent a file whose content has been dropped using a broken symlink, so it instead represents it with a nearly empty file.
+"""]]
diff --git a/doc/forum/assistant_and_archive_folder.mdwn b/doc/forum/assistant_and_archive_folder.mdwn
new file mode 100644
index 0000000000..11f405736f
--- /dev/null
+++ b/doc/forum/assistant_and_archive_folder.mdwn
@@ -0,0 +1,13 @@
+I have a setup with a windows desktop and a linux laptop with both an annex repository, interconnected via a backup repository in the middle (connected via ssh).
+Both computers are setup as clients and all 3 machines are running the assistant.
+
+Today i tried creating an archive folder and a putting some files in it. To my understanding those files should have been dropped in the 2 machines but kept on the server.. instead I have them copied on each machine. Listing where the files are on both computers shows that both know that themselves and the server have a copy, but they don't know anything about each other.
+
+AFAIK it looks like the bug reported in https://git-annex.branchable.com/forum/question_about_assistant_and___47__archive__47__/
+
+laptop: git-annex version: 5.20151116+gitg5416a1a-1~ndall+1
+
+server: git-annex version: 5.20151109-g08bb3b1
+
+windows: the latest build on the website
+
diff --git a/doc/forum/assistant_and_archive_folder/comment_1_ab8808372b886fd1a9f55588d1cef602._comment b/doc/forum/assistant_and_archive_folder/comment_1_ab8808372b886fd1a9f55588d1cef602._comment
new file mode 100644
index 0000000000..c567bc3038
--- /dev/null
+++ b/doc/forum/assistant_and_archive_folder/comment_1_ab8808372b886fd1a9f55588d1cef602._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-20T16:53:04Z"
+ content="""
+How many copies have you configured git-annex to keep of each file?
+
+If it's 1 copy, the clients should be able to contact the server, see that
+it has the file, and drop it as it's in the achive folder. But if 2 copies
+are needed, neither client can verify that the other client has a copy, so
+both will hold onto their own copy for safety.
+"""]]
diff --git a/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__.mdwn b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__.mdwn
new file mode 100644
index 0000000000..c18dfb6ca8
--- /dev/null
+++ b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__.mdwn
@@ -0,0 +1,38 @@
+Hi,
+
+I have a question about encryption keys. 
+Basically I do not know how to use the data which was copied in case my local
+machine dies?
+
+
+## I have done the following:
+---
+1. copied my ssh public key to a remote server
+1. created a directory and started git annex assistant
+ 
+   mkdir ~/test_annex
+
+   cd ~/test_annex
+
+   git annex webapp
+
+1. clicked Repository->Add another local repository
+1. Assistant: Where do you want to put this new repository? Me: ~/test_annex "Make Repository"
+1. Assistant "Combine repositories?" Me: "Keep repositories separate"
+1. clicked "Add another repository" clicked "remote server"
+1. filled out "Adding a remote server using ssh" form and clicked "Check this server"
+1. choose "Use an encrypted rsync repository on the server"
+1. Assistant "Repository created" I select "Full backup" as repository group.
+
+So far so good. If I now add a file on my local machine into ~/test_annex something not human readable is created on the remote machine.
+
+What I do not understand is how I use this backup later. I am expecting something along the "hybrid encryption keys" scheme
+explained in this wiki. However I was not able to determine which of my gpg keys was used or how the data was encrypted.
+
+So my question is: "How do I use the encrypted backup remote on a second machine?"
+
+
+
+
+
+
diff --git a/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_1_70200f871b9df49261f32752a6bb0e67._comment b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_1_70200f871b9df49261f32752a6bb0e67._comment
new file mode 100644
index 0000000000..9d457a9d2d
--- /dev/null
+++ b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_1_70200f871b9df49261f32752a6bb0e67._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-10-27T21:19:45Z"
+ content="""
+When you create an encrypted rsync repository using the webapp like that, its encryption key is stored in your git repository, using the [[shared encryption scheme|encryption#index2h2]]. No gpg key needs to be used to decrypt files from the rsync repository; anyone with a clone of your git repository can do so.  This has its plusses and its minuses; the webapp picks that type of encryption because it's easy to use.
+
+So, the answer is to just make a clone of your repository on the other machine, and then you can use it. There are lots of ways to do that; if you stay in the webapp, go to Add Another Repisitory and any of the \"Share with your other devices\", \"Share with a friend\", or \"Local computer\" options are easy ways to do it.
+
+----
+
+Now, if you had, manually, set up a rsync repository encrypted with the [[hybrid encryption key scheme|encryption#index1h2]], to access it from another computer with clone of the repository you would need to have a gpg key that has been given access to the repository. So you would either copy your gpg secret key to the other computer, or if you don't want to trust that other computer with the your main gpg key, you could make another gpg secret key for that computer, and add that key as one of the keys that can access the encrypted repository. (Or, if the computer belonged to a friend, you could just get their gpg key, and add it.)
+"""]]
diff --git a/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_2_173da510b45f0320ae8aa2df9f14ae7b._comment b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_2_173da510b45f0320ae8aa2df9f14ae7b._comment
new file mode 100644
index 0000000000..dbf2178f5b
--- /dev/null
+++ b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_2_173da510b45f0320ae8aa2df9f14ae7b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Frank"
+ ip="31.19.114.93"
+ subject="Comment 2"
+ date="2013-11-07T19:45:16Z"
+ content="""
+Thank you very much for the explanation! Have fun!
+
+
+
+"""]]
diff --git a/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_3_1ecea12a4be5ad09013cddb62df6ab20._comment b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_3_1ecea12a4be5ad09013cddb62df6ab20._comment
new file mode 100644
index 0000000000..aaf3735899
--- /dev/null
+++ b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_3_1ecea12a4be5ad09013cddb62df6ab20._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/W6vhceUml87q0GB9MGH1qEeteW8-#ee26a"
+ nickname="Leandro"
+ subject="comment 3"
+ date="2014-05-17T17:39:04Z"
+ content="""
+So, just to clarify things a little bit: Suppose that you have a remote at box.com (shared encrypted), then the CEO at box.com would eventually be able to decrypt your files easily since the keys are store in the git repository without encryption. Is that right? 
+"""]]
diff --git a/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_4_af4bc222d1479482bd83952353c97f05._comment b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_4_af4bc222d1479482bd83952353c97f05._comment
new file mode 100644
index 0000000000..7b7b86c306
--- /dev/null
+++ b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_4_af4bc222d1479482bd83952353c97f05._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="216.145.95.162"
+ subject="comment 4"
+ date="2014-05-19T15:38:14Z"
+ content="""
+No, box.com cannot decrypt your files, because the git repository is not stored on box.com. 
+"""]]
diff --git a/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_5_c1d247fa128c0a0fc899284f5f95002c._comment b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_5_c1d247fa128c0a0fc899284f5f95002c._comment
new file mode 100644
index 0000000000..474bd6673b
--- /dev/null
+++ b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_5_c1d247fa128c0a0fc899284f5f95002c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="Understanding"
+ date="2014-09-19T21:24:19Z"
+ content="""
+If box does not have the encryption keys in this \"shared encryption\" scenario and if you had only your computer and this remote repo, does that mean losing your computer (ie your git repository) would mean also losing access to those encrypted content? So, actually an encrypted remote, even if marked as full backup, is not actually a backup unless you have a 3rd computer that has the same git repo, in the case of losing your original computer or accidentally wiping it...
+"""]]
diff --git a/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_6_cf877a3502802492cd2bc3012cb2d779._comment b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_6_cf877a3502802492cd2bc3012cb2d779._comment
new file mode 100644
index 0000000000..3765a67cc6
--- /dev/null
+++ b/doc/forum/assistant_created_encrypted__backup_remote__58___Howto_restore__63__/comment_6_cf877a3502802492cd2bc3012cb2d779._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.144"
+ subject="comment 6"
+ date="2014-09-25T15:59:34Z"
+ content="""
+Right.
+
+So, I think I should go change the description displayed by the webapp to \"full backup (file contents only)\" and \"full backup (entire git repository)\" or so. It's a little hard to word it precisely without making it hard to understand.
+
+Or, the webapp could display a nudge to make a clone when no other clones of the git repository exist. I think that's probably more valuable, so [[todo_added|todo/webapp_nudge_when_less_than_numcopies_clones]].
+"""]]
diff --git a/doc/forum/assistant_overzealously_moving_stuff_to_other_repos.mdwn b/doc/forum/assistant_overzealously_moving_stuff_to_other_repos.mdwn
new file mode 100644
index 0000000000..155d89985d
--- /dev/null
+++ b/doc/forum/assistant_overzealously_moving_stuff_to_other_repos.mdwn
@@ -0,0 +1,7 @@
+Debian Squeeze, git version 1.7.10.4, git-annex version 3.20121211
+
+The machine has a clone of the annex with preferred content string: `present or include=calibre/* or include=img/* or include=mail/* or include=music/* or include=sounds/*`
+
+This, I believe, should mean the assistant should never drop anything.  However for the past two days it's been moving files to an encrypted rsync remote so that there are two copies (there is another copy on an external HDD) and then it's dropping them from the current annex.  I want to keep the files here; can anyone think of any reason why they would be moved away?
+
+[[!tag forumbug]] [[bugs/done]]
diff --git a/doc/forum/assistant_overzealously_moving_stuff_to_other_repos/comment_1_6bd240edf1868615024ff11c24c3d52c._comment b/doc/forum/assistant_overzealously_moving_stuff_to_other_repos/comment_1_6bd240edf1868615024ff11c24c3d52c._comment
new file mode 100644
index 0000000000..ad4b23f29a
--- /dev/null
+++ b/doc/forum/assistant_overzealously_moving_stuff_to_other_repos/comment_1_6bd240edf1868615024ff11c24c3d52c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 1"
+ date="2012-12-19T17:19:28Z"
+ content="""
+I had similar issues when I tried to use \"present\" settings a while back, except it was with adding files.  I would add a file and then it would be immediately dropped (because it was not yet \"present\" while it was being added?).  I gave up and just started using \"archive\" subdirectories for things I didn't want to be present.  Even so I'm having some confusing issues with the assistant.  It keeps dropping certain files which are in \"backup\" repositories and therefore should never have anything dropped.  I haven't isolated what's going on to the degree I can get a good bug report together.  But I'm having a hard time trusting assistant and its content settings to do what I want.  I have a couple scripts that do things like:
+
+git annex copy --not --in=usbdrive --to=usbdrive
+
+to populate my backup repos, and these seem much more reliable than the assistant.
+
+"""]]
diff --git a/doc/forum/assistant_overzealously_moving_stuff_to_other_repos/comment_2_37c5e9a7669b5b94fbadb8792a765316._comment b/doc/forum/assistant_overzealously_moving_stuff_to_other_repos/comment_2_37c5e9a7669b5b94fbadb8792a765316._comment
new file mode 100644
index 0000000000..58292aa14b
--- /dev/null
+++ b/doc/forum/assistant_overzealously_moving_stuff_to_other_repos/comment_2_37c5e9a7669b5b94fbadb8792a765316._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.117"
+ subject="comment 2"
+ date="2012-12-19T18:20:50Z"
+ content="""
+I've found and fixed a bug in transfer log parsing that could cause the assistant to get confused about the name of the file it had just transferred, and think it was not preferred content and drop it. I think this was causing both problems reported above.
+"""]]
diff --git a/doc/forum/assistant_overzealously_moving_stuff_to_other_repos/comment_3_87aa4c5942929be81ddc1e2795d56f0e._comment b/doc/forum/assistant_overzealously_moving_stuff_to_other_repos/comment_3_87aa4c5942929be81ddc1e2795d56f0e._comment
new file mode 100644
index 0000000000..f4d6240bce
--- /dev/null
+++ b/doc/forum/assistant_overzealously_moving_stuff_to_other_repos/comment_3_87aa4c5942929be81ddc1e2795d56f0e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 3"
+ date="2012-12-20T00:05:08Z"
+ content="""
+Thanks, I'll give it another shot!
+
+"""]]
diff --git a/doc/forum/assistant_periodical_unused_moves.mdwn b/doc/forum/assistant_periodical_unused_moves.mdwn
new file mode 100644
index 0000000000..5725f8d236
--- /dev/null
+++ b/doc/forum/assistant_periodical_unused_moves.mdwn
@@ -0,0 +1,11 @@
+I am trying a setup to move files from/to work using a usb key that also has a acopy of the whole repository (if I have to access it from somewhere else without git-annex).
+
+At home there's a direct client repository, the usb is an indirect incrementalbackup and at work I have a indirect backup and a direct client repositories.
+
+
+What I am trying to obtain is to have a lightweight repository at home that doesn't hold backups, and the usb key to also move the unused files from home to work as a backup.
+I am trying to make the assistant do it for me and as far as I could read the assistant should periodically move unused files out of repositories of the group client to the (incremental)backup ones.
+
+
+Having the assistant running on home repository and the two work repositories should do the trick? considering that the usb key doesn't spend much time connected to a computer I have no idea how the assistant would do the periodcal move.
+Also i hope i got it right but files from incrementalbackup should be moved to backup repositories when they can be synchronized, but again, I don't know if a 5 minutes mount with the assistant running on the backup repository will actually do it.
diff --git a/doc/forum/assistant_periodical_unused_moves/comment_1_98e30e1f3ca63790c4a8ce11d29634ae._comment b/doc/forum/assistant_periodical_unused_moves/comment_1_98e30e1f3ca63790c4a8ce11d29634ae._comment
new file mode 100644
index 0000000000..275c5e85f8
--- /dev/null
+++ b/doc/forum/assistant_periodical_unused_moves/comment_1_98e30e1f3ca63790c4a8ce11d29634ae._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-06T19:36:22Z"
+ content="""
+The assistant checks once per day for unused files, and tries to
+transfer them to remotes at that point. Exactly when this runs varies,
+just once per day sometime. It shouldn't much matter when it runs;
+if the drive is not connected at the time, the transfers will fail 
+and be remembered to be retried later next time it gets connected.
+
+The webapp will detect if too many unused files are piling up
+and will display a message about it.
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders.mdwn b/doc/forum/assistant_to_have_synced_folders.mdwn
new file mode 100644
index 0000000000..6c5976d5c4
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders.mdwn
@@ -0,0 +1,9 @@
+hi.
+
+first i have to say... im a huge fan and running some git-annex repos for all sort of things. i trust git-annex my whole photo archiv and my tax documents ;-)
+
+i try to get my head around some scenarios i couldnt get working. i want a nextcloud/dropbox style sink between two boxes. i have set up my repo manually on my laptop some time ago. just like `git init && git annex init`. i cloned that on my server and ran `git annex init`; added the server repo as remote on my laptop. so `git annex sync --content` works on both ends. what i want is to run git annex assistant on both boxes... server and laptop. i add a new file on laptop and git annex assistant syncs it to my server. that works fine. but i thought that the git annex assistant notices it and does a git annex sync too, to pull changes in. i only get it working in one way. what am i doing wrong?
+
+in the screencast for the assistant it looks like it should work that way... with the only difference that it got setup within the webapp itself and a bare transfer repository on a server. is this transfer group server needed for make it working this way? 
+
+i also found [this](https://git-annex.branchable.com/tips/making_a_remote_repo_update_when_changes_are_pushed_to_it/) in the tips. does i have to set up like that?
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_10_3bf1a44e76855e4fbdd270f97a54bcc5._comment b/doc/forum/assistant_to_have_synced_folders/comment_10_3bf1a44e76855e4fbdd270f97a54bcc5._comment
new file mode 100644
index 0000000000..37c2886495
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_10_3bf1a44e76855e4fbdd270f97a54bcc5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 10"
+ date="2018-11-15T20:15:16Z"
+ content="""
+That all looks correct. Are both `ANNEX_1` and `ANNEX_2` listed in `~/.config/git-annex/autostart`? What happens if you now run `git-annex assistant --autostart` does it list both `ANNEX_1` and `ANNEX_2`? Does everything work OK then?
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_11_b5f9f527597acd8f44f529f85ac305fd._comment b/doc/forum/assistant_to_have_synced_folders/comment_11_b5f9f527597acd8f44f529f85ac305fd._comment
new file mode 100644
index 0000000000..d932b8eada
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_11_b5f9f527597acd8f44f529f85ac305fd._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="marvin@3296bf3c446430c3b2ebc32b5c784ee976620847"
+ nickname="marvin"
+ avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e"
+ subject="comment 11"
+ date="2018-11-20T11:06:31Z"
+ content="""
+yes. assistant runs ob both and gets autostarted. i dont have a other box to try it out. but slowly im giving up on using the assistant.
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_12_f38a88b82328ee2d2b411f3df5c3d043._comment b/doc/forum/assistant_to_have_synced_folders/comment_12_f38a88b82328ee2d2b411f3df5c3d043._comment
new file mode 100644
index 0000000000..6c07f21d3f
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_12_f38a88b82328ee2d2b411f3df5c3d043._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 12"
+ date="2018-12-08T16:56:11Z"
+ content="""
+Looking through your video, I think I have found at least one issue with the assistant. I logged in a todo here: <http://git-annex.branchable.com/todo/assistant_should_detect_added_remotes/>. It looks like assistant is not detecting your newly added remote (after hitting the combine button) which is why it wasn't syncing.
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_13_9b8631b1fb4c9992203efc2d29cfae8d._comment b/doc/forum/assistant_to_have_synced_folders/comment_13_9b8631b1fb4c9992203efc2d29cfae8d._comment
new file mode 100644
index 0000000000..f7d0487880
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_13_9b8631b1fb4c9992203efc2d29cfae8d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xsteadfastx"
+ avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e"
+ subject="comment 13"
+ date="2018-12-10T10:41:05Z"
+ content="""
+this is brilliant. thank you. i gave up and thought its something about my setup or something :) 
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_1_e2e49f5278b921f8817ad6ac89a6aaf8._comment b/doc/forum/assistant_to_have_synced_folders/comment_1_e2e49f5278b921f8817ad6ac89a6aaf8._comment
new file mode 100644
index 0000000000..a2331fd86d
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_1_e2e49f5278b921f8817ad6ac89a6aaf8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-11-01T12:24:10Z"
+ content="""
+If you want to be able to drop files into your server repo directly and have those files seen by git-annex and then synced back to your laptop you will need your server repo to be non-bare (IE a normal full git repository). Bare repositories are never monitored by git-annex assistant ([see somewhat related comments on that here](http://git-annex.branchable.com/bugs/OSX_Assistant_will_not_automatically_drop/#comment-e81c8bac6a39c90692a3eb695c8dc416)).
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_2_690a144201e7df5972fd48af8c1d46f7._comment b/doc/forum/assistant_to_have_synced_folders/comment_2_690a144201e7df5972fd48af8c1d46f7._comment
new file mode 100644
index 0000000000..7270e4cb9a
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_2_690a144201e7df5972fd48af8c1d46f7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="marvin@3296bf3c446430c3b2ebc32b5c784ee976620847"
+ nickname="marvin"
+ avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e"
+ subject="comment 2"
+ date="2018-11-02T08:57:39Z"
+ content="""
+server and laptop repos are not bare. there are normal checkout out git repos. there are not created by the assistant and i wonder if i have to do that if i want a dropbox like sync.
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_3_49b00584ef4388e130cce63f4f33572f._comment b/doc/forum/assistant_to_have_synced_folders/comment_3_49b00584ef4388e130cce63f4f33572f._comment
new file mode 100644
index 0000000000..0dbd65d89d
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_3_49b00584ef4388e130cce63f4f33572f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 3"
+ date="2018-11-02T22:03:15Z"
+ content="""
+Aaah OK. You don't necessarily need to add the repositories from assistant. If you create them from the command-line you need to manually add the full path to any repos you want the assistant to watch to a file located at `~/.config/git-annex/autostart`.
+
+So on your server you want that `~/.config/git-annex/autostart` file to contain the full path to the repo that is located on the server and for the `~/.config/git-annex/autostart` file on your laptop you want it to contain the full path to your laptop repo. You also need to start the assistant on both your laptop and your server by running `git-annex-assistant --autostart` on your laptop and on your server. You'll also want to verify that this autostart command is happening automatically at boot (which `git-annex` might have done for you).
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_4_53ceb18128de33311d65b39f34b3d9b7._comment b/doc/forum/assistant_to_have_synced_folders/comment_4_53ceb18128de33311d65b39f34b3d9b7._comment
new file mode 100644
index 0000000000..cb1186a209
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_4_53ceb18128de33311d65b39f34b3d9b7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="marvin@3296bf3c446430c3b2ebc32b5c784ee976620847"
+ nickname="marvin"
+ avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e"
+ subject="comment 4"
+ date="2018-11-05T18:21:53Z"
+ content="""
+i did all the steps you described. not even on my local box... two repos... assistant running on both repos (checked out repos with workdir)... processes run fine. i add files to repo A. it gets tranfered to repo B. the assistant on repo B does not merge. maybe thee post-receive hook is not working. as i thought it would merge with the synced branch in a auto way. i always have to run git annex sync do get the new files or repo A in repo B. i know you can set something up with \"git config receive.denyCurrentBranch updateInstead\". but i thought if i set something up with the assistant this would do this out of the box. or i have a thinking error. do i need a pushing tranfer repo in the middle connected with tor to get this done? i thought it would be more easy. but if i dont even get this working local.... i have no idea where my error is. if its something technical or in my understanding.
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_5_6db901470af7dc7e1da90839fc08c121._comment b/doc/forum/assistant_to_have_synced_folders/comment_5_6db901470af7dc7e1da90839fc08c121._comment
new file mode 100644
index 0000000000..12a23d6579
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_5_6db901470af7dc7e1da90839fc08c121._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 5"
+ date="2018-11-08T13:06:55Z"
+ content="""
+Could you post the output to `git annex version` are you on latest git-annex? As well can you post any information you are willing to share from `.git/config` on each of the repos in question. Also I would recommend creating two new repos from the web interface of git annex assistant (locally) and see if they behave as expected.
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_6_0ec093a51b3dab465907074beb423848._comment b/doc/forum/assistant_to_have_synced_folders/comment_6_0ec093a51b3dab465907074beb423848._comment
new file mode 100644
index 0000000000..68ec209055
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_6_0ec093a51b3dab465907074beb423848._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 6"
+ date="2018-11-08T13:10:23Z"
+ content="""
+Also you said “i always have to run git annex sync do get the new files or repo A in repo B”, did you mean you have to run `git annex sync --content`? Or did you mean you are just getting the filenames in sync without the content?
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_7_83fdf8c0027c860f37716f975838497a._comment b/doc/forum/assistant_to_have_synced_folders/comment_7_83fdf8c0027c860f37716f975838497a._comment
new file mode 100644
index 0000000000..86f09e9464
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_7_83fdf8c0027c860f37716f975838497a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="marvin@3296bf3c446430c3b2ebc32b5c784ee976620847"
+ nickname="marvin"
+ avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e"
+ subject="comment 7"
+ date="2018-11-12T08:48:33Z"
+ content="""
+to make my problems clear, i have reacorded my screen with a example :)
+
+https://youtu.be/3Ows2gF8gEM
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_8_52237edb2f6cbf9c96f7285ebf6abe6c._comment b/doc/forum/assistant_to_have_synced_folders/comment_8_52237edb2f6cbf9c96f7285ebf6abe6c._comment
new file mode 100644
index 0000000000..c2a5d15080
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_8_52237edb2f6cbf9c96f7285ebf6abe6c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 8"
+ date="2018-11-14T13:32:52Z"
+ content="""
+Thank you for recording the screencast. Yes, you did all of the steps correctly, that should have worked. Could you please post the output of:
+
+   * `git annex version`
+   * `.git/config` from each of the repos created in the screencast
+   * `.git/annex/daemon.log` from each of the repos created in the screencast
+
+So we can get some more insight into what the issue might be on your machine. Thank you for your patience and detail.
+"""]]
diff --git a/doc/forum/assistant_to_have_synced_folders/comment_9_a7a5a4c97663211e2fb4337117ec0cb0._comment b/doc/forum/assistant_to_have_synced_folders/comment_9_a7a5a4c97663211e2fb4337117ec0cb0._comment
new file mode 100644
index 0000000000..ef1bc7939e
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_9_a7a5a4c97663211e2fb4337117ec0cb0._comment
@@ -0,0 +1,69 @@
+[[!comment format=mdwn
+ username="marvin@3296bf3c446430c3b2ebc32b5c784ee976620847"
+ nickname="marvin"
+ avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e"
+ subject="comment 9"
+ date="2018-11-15T10:12:49Z"
+ content="""
+    $ git annex version                                                                                                                                                               Do 15 Nov 2018 11:05:05 CET
+    git-annex version: 7.20181105-gb20cea3
+    build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify TorrentParser MagicMime Feeds Testsuite
+    dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E          BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+    operating system: linux x86_64
+    supported repository versions: 5 7
+    upgrade supported from repository versions: 0 1 2 3 4 5 6
+
+
+then here to git configs
+
+
+    $ cat Downloads/ANNEX_1/.git/config                                                                                                                                    
+    [core]
+            repositoryformatversion = 0
+            filemode = true
+            bare = true
+            logallrefupdates = true
+    [annex]
+            uuid = a39f0a5e-6019-40a1-b606-dab31c6b76bd
+            version = 5
+            direct = true
+    [gc]
+            auto = 0
+    [remote \"ANNEX_2\"]
+            url = /home/preuss/Downloads/ANNEX_2
+            fetch = +refs/heads/*:refs/remotes/ANNEX_2/*
+            annex-uuid = ba1a8311-ec01-4ae8-b94e-87be76195369
+    [remote \"CKCBSN0288\"]
+            url = ../ANNEX_2
+            fetch = +refs/heads/*:refs/remotes/CKCBSN0288/*
+            annex-uuid = ba1a8311-ec01-4ae8-b94e-87be76195369
+
+
+and from the second repo
+
+    $ cat Downloads/ANNEX_2/.git/config                                                                                                                                               Do 15 Nov 2018 11:11:03 CET
+    [core]
+            repositoryformatversion = 0
+            filemode = true
+            bare = true
+            logallrefupdates = true
+    [annex]
+            uuid = ba1a8311-ec01-4ae8-b94e-87be76195369
+            version = 5
+            direct = true
+    [gc]
+            auto = 0
+    [remote \"CKCBSN0288\"]
+            url = ../ANNEX_1
+            fetch = +refs/heads/*:refs/remotes/CKCBSN0288/*
+            annex-uuid = a39f0a5e-6019-40a1-b606-dab31c6b76bd
+    [remote \"ANNEX_1\"]
+            url = /home/preuss/Downloads/ANNEX_1
+            fetch = +refs/heads/*:refs/remotes/ANNEX_1/*
+            annex-uuid = a39f0a5e-6019-40a1-b606-dab31c6b76bd
+
+and the worst thing is... the daemon.logs are empty.
+    
+"""]]
diff --git a/doc/forum/assistant_without_watch__63__.mdwn b/doc/forum/assistant_without_watch__63__.mdwn
new file mode 100644
index 0000000000..34aa3e4415
--- /dev/null
+++ b/doc/forum/assistant_without_watch__63__.mdwn
@@ -0,0 +1,13 @@
+"watch" is described as
+
+> With this running as a daemon in the background, you no longer need to manually run git commands  when  manipulating your files.
+
+and "assistant" is described as
+
+> Like watch, but also automatically syncs changes to other remotes.
+
+I would like the behaviour of assistant, without the watch part:
+
+I have an archive of large files, which I think would be useful to manage manually using git.  But I don't want to manually enforce the "numcopies=" requirement, playing with the assistant and webapp it seems really nice to have it take care of that.
+
+Is there currently an "assistant-without-watch" option?   If not, is it planned?
diff --git a/doc/forum/assistant_without_watch__63__/comment_1_be1f7c038426e53209a85ae1119269d5._comment b/doc/forum/assistant_without_watch__63__/comment_1_be1f7c038426e53209a85ae1119269d5._comment
new file mode 100644
index 0000000000..dc64ef7d2d
--- /dev/null
+++ b/doc/forum/assistant_without_watch__63__/comment_1_be1f7c038426e53209a85ae1119269d5._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.253.75"
+ subject="comment 1"
+ date="2013-02-22T22:31:29Z"
+ content="""
+Not quite. 
+
+Recent versions allow you to disable the automatic committing while the assistant is running by setting annex.autocommit=false .. or just by going into the webapp repository list and pausing syncing for the \"here\" repository.
+
+But, with automatic committing disabled, the assistant doesn't know when new files are added, so will not transfer them.  The rest of it still works, so for example if another clone of the repository makes changes
+the assistant will merge them in and download the new files.
+
+To transfer new files you created, you could use `git annex copy --auto --to someremote`, which will only copy them if needed to satisfy numcopies.
+"""]]
diff --git a/doc/forum/assitant__58___special_remote_server___40__needs_ssh_tunnel__41__.mdwn b/doc/forum/assitant__58___special_remote_server___40__needs_ssh_tunnel__41__.mdwn
new file mode 100644
index 0000000000..45c43f4434
--- /dev/null
+++ b/doc/forum/assitant__58___special_remote_server___40__needs_ssh_tunnel__41__.mdwn
@@ -0,0 +1,10 @@
+To connect to a remote server I have to tunnel it through a server I have access to. My .ssh/config for this connection looks like this:
+
+
+    Host server-at-home
+        HostName foo.bar.de
+        User foo
+        Port 222
+        ProxyCommand /usr/bin/ssh me@server-i-have-access-to /bin/nc -w 3700 %h %p
+
+Is it possible to create a connection using a similar configuration via the git-annex assistant?
diff --git a/doc/forum/assitant__58___special_remote_server___40__needs_ssh_tunnel__41__/comment_1_817a3ed424e4fb76fcd33295f2953250._comment b/doc/forum/assitant__58___special_remote_server___40__needs_ssh_tunnel__41__/comment_1_817a3ed424e4fb76fcd33295f2953250._comment
new file mode 100644
index 0000000000..b3e495dc22
--- /dev/null
+++ b/doc/forum/assitant__58___special_remote_server___40__needs_ssh_tunnel__41__/comment_1_817a3ed424e4fb76fcd33295f2953250._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 1"
+ date="2013-11-28T22:08:04Z"
+ content="""
+You can add/clone from the remote from the command line and webapp will use it. 
+"""]]
diff --git a/doc/forum/auto-fetching_annexed_files_on_open__40____41__.mdwn b/doc/forum/auto-fetching_annexed_files_on_open__40____41__.mdwn
new file mode 100644
index 0000000000..074e50a012
--- /dev/null
+++ b/doc/forum/auto-fetching_annexed_files_on_open__40____41__.mdwn
@@ -0,0 +1,8 @@
+It would make git-annex much simpler to use if annexed files could be transparently auto-fetched when programs try to read them, without requiring an explicit `git-annex-get`.
+
+What approaches have people tried to make this work, and what were the results / takeaways?
+
+Some related pages: [[news/sharebox_a_FUSE_filesystem_for_git-annex]]; [[todo/union_mounting]]; [[using fanotify|forum/expire_files__44___move_to_other_hosts]] .
+
+My attempt at a FUSE filesystem that calls `git-annex-get` as needed: [here](https://github.com/broadinstitute/viral-ngs/blob/is-dx-benchmarks/tools/git-annex-remotes/git-annex-on-demand.py).  However, it gets an annexed file as soon as a symlink to it is read, which can also happen when just listing a directory; it also only works with locked annexed files.
+
diff --git a/doc/forum/autobuilders_for_git-annex_to_aid_development.mdwn b/doc/forum/autobuilders_for_git-annex_to_aid_development.mdwn
new file mode 100644
index 0000000000..2c1280e514
--- /dev/null
+++ b/doc/forum/autobuilders_for_git-annex_to_aid_development.mdwn
@@ -0,0 +1,34 @@
+This is a continuation of the conversation from [[the comments|design/assistant/#comment-77e54e7ebfbd944c370173014b535c91]] section in the design of git-assistant. In summary, I've setup an auto builder which should help [[Joey]] have an easier time developing on git-annex on non-linux/debian platforms. This builder is currently running on OSX 10.7 with the 64bit version of Haskell Platform.
+
+The builder output can be found at <http://www.sgenomics.org/~jtang/gitbuilder-git-annex-x00-x86_64-apple-darwin10.8.0/>, the CGI on this site does not work as my OSX workstation is pushing the output from another location.
+
+The builder currently tries to build all branches except 
+
+* debian-stable
+* pristine-tar
+* setup
+
+It also does not build any of the tags as well, Joey had suggested to ignore the bpo named tags, but for now it's easier for me to not build any tags. To continue on this discussion, if anyone wants to setup a gitbuilder instance, here is the build.sh script that I am using.
+
+<pre>
+#!/bin/bash -x
+
+# Macports
+export PATH=/opt/local/bin:$PATH
+
+# Haskell userland
+export PATH=$PATH:$HOME/.cabal/bin
+
+# Macports gnu
+export PATH=/opt/local/libexec/gnubin:$PATH
+
+make || exit 3
+
+make -q test
+if [ "$?" = 1 ]; then
+        # run "make test", but give it a time limit in case a test gets stuck
+        ../maxtime 1800 make test || exit 4
+fi
+</pre>
+
+It's also using the branches-local script for sorting and prioritising the branches to build, this branches-local script can be found at the [autobuild-ceph](https://github.com/ceph/autobuild-ceph/blob/master/branches-local) repository. If there are other people interested in setting up their own instances of gitbuilder for git-annex, please let me know and I will setup an aggregator page to collect status of the builds. The builder runs and updates on a very regular basis.
diff --git a/doc/forum/autobuilders_for_git-annex_to_aid_development/comment_1_7e88f815e8d9652ef18ea6d54b118962._comment b/doc/forum/autobuilders_for_git-annex_to_aid_development/comment_1_7e88f815e8d9652ef18ea6d54b118962._comment
new file mode 100644
index 0000000000..82380cd602
--- /dev/null
+++ b/doc/forum/autobuilders_for_git-annex_to_aid_development/comment_1_7e88f815e8d9652ef18ea6d54b118962._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2012-07-02T16:25:55Z"
+ content="""
+I've some binaries for OSX which can be found at <http://www.sgenomics.org/~jtang/gitbuilder-git-annex-x00-x86_64-apple-darwin10.8.0-binary/dist/> its just the master branch, and it's built on a system that runs macports. Binaries are built and updated whenever there are changes made to the master branch of git-annex.
+"""]]
diff --git a/doc/forum/autobuilders_for_git-annex_to_aid_development/comment_2_fef17a10226af5671495c2929653c337._comment b/doc/forum/autobuilders_for_git-annex_to_aid_development/comment_2_fef17a10226af5671495c2929653c337._comment
new file mode 100644
index 0000000000..da3cd6e671
--- /dev/null
+++ b/doc/forum/autobuilders_for_git-annex_to_aid_development/comment_2_fef17a10226af5671495c2929653c337._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2012-09-29T09:01:11Z"
+ content="""
+I'm currently playing with the autobuilder to get it to do more sensible things so it may be broken for a day or two
+"""]]
diff --git a/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes.mdwn b/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes.mdwn
new file mode 100644
index 0000000000..34bae17fa5
--- /dev/null
+++ b/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes.mdwn
@@ -0,0 +1,3 @@
+I have two copies of a large collection of photos on two computers. I have been using rsync to keep them synchronized, but I would like to use git annex instead. I finished initializing one repo, and now its time to initialize the other repo before I can sync them up. But it seems redundant that the other repo will compute its own hashes although I know that the two contents are identical. Can't I just copy the keys and tell git annex to assume that any files seen have already been hashed?
+
+As a start, I cloned the .git from the first machine to the second. But that wasn't enough ... I now have an empty git-annex repo in the second machine. What else is missing?
diff --git a/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_1_7d0b479244fefd933193d921adcd897c._comment b/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_1_7d0b479244fefd933193d921adcd897c._comment
new file mode 100644
index 0000000000..538a070edb
--- /dev/null
+++ b/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_1_7d0b479244fefd933193d921adcd897c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/ZF7p46cPmpWtb9zvA8iTitPmiQ--#eb014"
+ nickname="Jason"
+ subject="I'm also having this issue"
+ date="2015-12-14T03:17:58Z"
+ content="""
+I have the exact same issue: two copies of photos and videos that I have been using rsync to maintain. Converted one disk to git-annex, cloned the repo and moved .git/ into the second but can't seem to find a fast way to move the files to the correct hash id in the annex dir and create the symlinks. I'm thinking it might be best to just do a `git init; git annex init; git annex add .; git commit` then add the remotes in both directions and \"sync\".
+"""]]
diff --git a/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_2_d42222ef94f4d409ac40e523f8211ffc._comment b/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_2_d42222ef94f4d409ac40e523f8211ffc._comment
new file mode 100644
index 0000000000..bfd8066ace
--- /dev/null
+++ b/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_2_d42222ef94f4d409ac40e523f8211ffc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/ZF7p46cPmpWtb9zvA8iTitPmiQ--#eb014"
+ nickname="Jason"
+ subject="It worked"
+ date="2015-12-14T04:46:46Z"
+ content="""
+The above process just completed. Of course it took a while to hash and create symlinks for the 20K+ files. The initial sync caused an expected \"Warning: no common commits\" however since the symlinks all pointed at the exact same hashed filenames there was nothing to merge. The sync did take several minutes, but it was much shorter than copying 120GB. I hope this helps someone else in the future.
+"""]]
diff --git a/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_3_dc93ae2a58de5620c440531f43f1237d._comment b/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_3_dc93ae2a58de5620c440531f43f1237d._comment
new file mode 100644
index 0000000000..539f574f6a
--- /dev/null
+++ b/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_3_dc93ae2a58de5620c440531f43f1237d._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-12-19T18:09:26Z"
+ content="""
+I'd say that method, or any similar set of steps, is the typical way to
+handle this.
+
+Sure, everything gets hashed twice. This is unlikely to waste enough time
+to make it worthwhile to develop a hack that only hashes once.
+
+If you really want to develop such a hack, the plumbing command that you
+can use to make it happen is `git annex setkey`. So, you'd add all the
+files to the first repository, and then use `git-annex find
+--format="${key} ${file}"` to list all the files and the keys that resulted
+from hashing them. Then in the second repository, you'd use that list to
+run `git annex setkey` and force the files into the annex without
+hashing them.
+
+This will probably turn out to be slower than just re-hashing the files
+would be, since you'll have to run `git annex setkey` once per file.
+Adding a `--batch` option that reads from stdin would probably be called
+for to get it fast enough to bother with. Although passing `-c
+annex.alwayscommit=false` might speed it up enough.
+"""]]
diff --git a/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_4_e6bb8a33608908d02eeb921d039f22b9._comment b/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_4_e6bb8a33608908d02eeb921d039f22b9._comment
new file mode 100644
index 0000000000..8560857a7a
--- /dev/null
+++ b/doc/forum/avoid_rehashing_when_converting_existing_backups_into_new_remotes/comment_4_e6bb8a33608908d02eeb921d039f22b9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 4"
+ date="2015-12-23T12:46:36Z"
+ content="""
+> This is unlikely to waste enough time to make it worthwhile to develop a hack that only hashes once.
+
+In my super-heavy use case, the second hashing of the files is *dwarfed* by the 45 minute wait for git to update .git/index, so I would agree with this.
+"""]]
diff --git a/doc/forum/avoiding_copies_across_mutiple_file_systems.mdwn b/doc/forum/avoiding_copies_across_mutiple_file_systems.mdwn
new file mode 100644
index 0000000000..605f53066e
--- /dev/null
+++ b/doc/forum/avoiding_copies_across_mutiple_file_systems.mdwn
@@ -0,0 +1,13 @@
+I first mentioned this issue in a thread about 4 years ago (https://git-annex.branchable.com/forum/git-annex_across_two_filesystems/), and at time was encouraged to instead open a new thread.   Priorities changed, and I'm only now returning to the issue.
+
+The situation we have is as follows:    We have a large collection of boundary condition data used in our weather/climate model.    Individual "experiments" are run against specific versions of this data and we would like to minimize the total storage footprint as well as time spent copying data at the beginning of an experiment.      The clones for the experiments would always be used in a read-only manner.  New files would never be added through these repos.
+
+At first glance,   using git-annex with `git clone --shared` would seem to be a good solution.     Unfortunately these experiments span a large number (~10) of separate cross-mounted filesystems and would result ~90% of the experiments still duplicating data rather than sharing across a hardlink.
+
+A couple of partial solutions suggest themselves.   (1)  Put all of the clones on the same filesystem as the primary repo, and then create a symlink within each experiment back to the corresponding clone.   (2) Maintain a secondary (fully populated) clone on each filesystem and ensure that the experiment setup script clones from the proper secondary.
+
+Option (1) is viable, but would require some negotiations with the computing center to ensure that there is a single filesystem that gives appropriate privileges to all of our users.   Tedious, but probably not a showstopper.
+
+Option (2) sounds like an improvement over having 90% of the experiments duplicating data locally, except ... because the secondary clones would need to support any recent model configuration, the 10x duplication of "all" data could be much larger than the hundreds of copies of the smaller subsets needed by individual experiments.
+
+Perhaps the ideal solution would be some sort of special "clone" that uses symlinks back to the primary repository.    These special clones would be read only, and could even disable "dangerous" git actions that would allow adding/modifying files.   `git-new-workdir` hints that something like this might be possible, but it does not appear to play nicely with git-annex in any event.
diff --git a/doc/forum/avoiding_copies_across_mutiple_file_systems/comment_1_2ff3e4d2af575b27b14a0a936ad8c52f._comment b/doc/forum/avoiding_copies_across_mutiple_file_systems/comment_1_2ff3e4d2af575b27b14a0a936ad8c52f._comment
new file mode 100644
index 0000000000..d642f3021a
--- /dev/null
+++ b/doc/forum/avoiding_copies_across_mutiple_file_systems/comment_1_2ff3e4d2af575b27b14a0a936ad8c52f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-05-05T18:08:49Z"
+ content="""
+Have I understood you correctly, you have a \"primary\" repository (with all data/keys present), accessible by the clients via NFS/cifs/whatever? And the clients(/\"experiments\") want to check out a specific version/branch from that repo?
+
+I think you have two alternatives to cloning it everywhere including all keys:
+
+a) Every client clones the git repo (and remove the \"origin\" remote to ensure that nothing flows back), creates a symlink from `.git/annex/objects` to `/path/to/primary/.git/annex/objects` and checks out whatever version/branch it wants. Easy.
+
+b) Every client uses the primary repo, but via its own worktree (See `git-worktree`). git-annex supports external worktrees, but I'm not sure what problems could arise in this particular setup. 
+"""]]
diff --git a/doc/forum/avoiding_copies_across_mutiple_file_systems/comment_2_96e72de1dc7cefdaa3beedc837639f57._comment b/doc/forum/avoiding_copies_across_mutiple_file_systems/comment_2_96e72de1dc7cefdaa3beedc837639f57._comment
new file mode 100644
index 0000000000..0fe3c45425
--- /dev/null
+++ b/doc/forum/avoiding_copies_across_mutiple_file_systems/comment_2_96e72de1dc7cefdaa3beedc837639f57._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-05-12T15:44:23Z"
+ content="""
+Symlinking .git/annex/objects back to the primary repo might just work. I
+seem to remember that parts of git-annex get slow or may even not work if
+.git/annex/objects is on a different filesystem than .git/annex/. So I'd
+try symlinking .git/annex back to the primary repo instead. Note that this
+limits how the clone can be used, if the user lacks permissions to write to
+the primary repo.
+
+The problem with git-worktree in your situation is that it actually
+needs to be run in the primary repo, and it modifies that repo,
+by eg creating .git/worktrees/. So users who do not have write access to
+the primary repo would not be able to do that, and you seemed to indicate
+it would be a problem getting all users write access to it.
+
+I think maybe you could have one replica of the primary repo per drive, and
+then individual experiments run on that drive are set up with git-worktree
+in the drive's replica. This way you would avoid permissions problems
+with the primary repo, and also the experiment runs on a presumably more
+local and faster drive. When setting up each experiment, you can `git annex
+get` the files it needs, which will pull them into the replica.
+
+Now, that does run the risk that all the replicas end up caching a lot of
+data from old experiments that is not being used by new experiments. So 
+you would want to find a way to clear out the unused data. 
+
+It seems helpful to that end that git worktree manages a branch for each
+worktree that's currently checked out.
+If each experiment used its own branch that contained only the files used
+in that experiment and not a lot of other files, then you could use
+`git annex unused --used-refspec=+refs/heads/*` to find data that was not
+used by any experiment that had a worktree using that replica.
+
+Alternatively, you could check, when removing an experiment's worktree from 
+the replica, if that was the last experiment using that replica. When it
+was, simply use `git annex drop --all` to clean out the replica.
+"""]]
diff --git a/doc/forum/avoiding_copies_across_mutiple_file_systems/comment_3_43db664a00fb9956ad392b5dc23565ca._comment b/doc/forum/avoiding_copies_across_mutiple_file_systems/comment_3_43db664a00fb9956ad392b5dc23565ca._comment
new file mode 100644
index 0000000000..c0de6a13af
--- /dev/null
+++ b/doc/forum/avoiding_copies_across_mutiple_file_systems/comment_3_43db664a00fb9956ad392b5dc23565ca._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://esgf-node.llnl.gov/esgf-idp/openid/tom_clune"
+ nickname="tom_clune"
+ avatar="http://cdn.libravatar.org/avatar/ab2fcb3663856220387ef216fa46d9717513d750fd9ee5a3504c4c7b560ad96e"
+ subject="comment 3"
+ date="2021-05-12T16:41:07Z"
+ content="""
+Sorry for the delay in responding.   I had a short vacation and jury duty that kept me from responding immediately.
+
+The symlink approach suggested by @Lukey appears to work quite well from my limited testing this far.       The git-worktree approach unfortunately required additional write permissions (as noted by @Joey) in the primary repository, and is thus not our preferred approach.
+
+As far as the performance consequences to the symlink option, my tests thus far did not show any obvious performance consequences related to multi-filesystem involvement.   Certainly my test repo (~100 files of 50 MB each) seemed to perform quite well, so a real test may effectively require deploying the full data set in this manner.
+
+I had previously tried @Joey's suggestion of symlinking just .git/annex rather than .git/annex/objects.     My recollection is that I got error messages, but will test again shortly.
+
+"""]]
diff --git a/doc/forum/avoiding_copies_across_mutiple_file_systems/comment_4_6584f98910d91746203405d57d17b8b0._comment b/doc/forum/avoiding_copies_across_mutiple_file_systems/comment_4_6584f98910d91746203405d57d17b8b0._comment
new file mode 100644
index 0000000000..a4373b9b83
--- /dev/null
+++ b/doc/forum/avoiding_copies_across_mutiple_file_systems/comment_4_6584f98910d91746203405d57d17b8b0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://esgf-node.llnl.gov/esgf-idp/openid/tom_clune"
+ nickname="tom_clune"
+ avatar="http://cdn.libravatar.org/avatar/ab2fcb3663856220387ef216fa46d9717513d750fd9ee5a3504c4c7b560ad96e"
+ subject="update"
+ date="2021-05-17T14:53:19Z"
+ content="""
+I just wanted to confirm that the suggestion of linking .git/annex (as opposed to .git/annex/objects)  appears to work as well.   I'm not sure what I did wrong on my earlier attempt.
+
+Performance measurements will not be available for quite some time, but anecdotally both approaches seem extremely fast.
+
+"""]]
diff --git a/doc/forum/backblaze_s3.mdwn b/doc/forum/backblaze_s3.mdwn
new file mode 100644
index 0000000000..27f3a0cff4
--- /dev/null
+++ b/doc/forum/backblaze_s3.mdwn
@@ -0,0 +1,13 @@
+Backblaze announced that they now have S3 storage for buckets created after May 4th.
+
+My current attempt to use it as an S3 remote has me with the following:
+export AWS_ACCESS_KEY_ID=keyID
+export AWS_SECRET_ACCESS_KEY=applicationID
+git-annex initremote backblaze type=S3 host=s3.us-west-000.backblazeb2.com (the full s3 endpoint) embedcreds=yes encryption=hybrid keyid=CA3D8351 bucket=<my bucket name> protocol=https
+
+and the output:
+
+initremote backblaze (encryption setup) (to gpg keys: 41AAE7DCCA3D8351) (checking bucket...) (creating bucket in US...)
+git-annex: S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = ""}, s3ErrorCode = "AuthorizationHeaderMalformed", s3ErrorMessage = "Authorization header does not contain a Credential", s3ErrorResource = Nothing, s3ErrorHostId = Nothing, s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+failed
+git-annex: initremote: 1 failed
diff --git a/doc/forum/backblaze_s3/comment_1_854390b9a781da82ecb85ad85eecad04._comment b/doc/forum/backblaze_s3/comment_1_854390b9a781da82ecb85ad85eecad04._comment
new file mode 100644
index 0000000000..357fdc5592
--- /dev/null
+++ b/doc/forum/backblaze_s3/comment_1_854390b9a781da82ecb85ad85eecad04._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-07T16:23:26Z"
+ content="""
+It may be that they are only supporting a newer version of the S3
+protocol that does authorization differently. The S3 library
+git-annex uses defaults to V2 not V4.
+
+I thought that library didn't properly support V4, but it seems it does,
+although I don't know if it works in all cases. So, I've added an
+initremote option for S3, signature=v4 .. give it a try.
+"""]]
diff --git a/doc/forum/backblaze_s3/comment_2_5f1407460b6a56a8e267f8eecf4427aa._comment b/doc/forum/backblaze_s3/comment_2_5f1407460b6a56a8e267f8eecf4427aa._comment
new file mode 100644
index 0000000000..5dd6a79ee6
--- /dev/null
+++ b/doc/forum/backblaze_s3/comment_2_5f1407460b6a56a8e267f8eecf4427aa._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="efraim@78c5af2ab57cf0d7aa23bae3dd0adb700c98217c"
+ nickname="efraim"
+ avatar="http://cdn.libravatar.org/avatar/6dc24928a791046ff66c8c7bd7a33099"
+ subject="comment 2"
+ date="2020-05-11T11:29:34Z"
+ content="""
+I rebuilt git-annex with the new signature v4 patch and I got it to work.
+
+I had to create a new application key that wasn't tied to a bucket or else I would get an 'access denied' error. I didn't set any prefix on the files uploaded.
+
+AWS_ACCESS_KEY_ID=keyID AWS_SECRET_ACCESS_KEY=applicationKey git-annex initremote backblaze type=S3 host=S3-endpoint bucket=bucketID protocol=https signature=v4
+
+This created a new bucket with the same bucketID as the one I previously created and intended to use, and with the name equal to the bucketID
+
+I suspect if I had done bucket=bucketName and not bucketID I could've used a bucket specific key but now that it's set up it's not worth it to me to try to change it.
+"""]]
diff --git a/doc/forum/backblaze_s3/comment_3_55362a91c4592775994999a843e648dc._comment b/doc/forum/backblaze_s3/comment_3_55362a91c4592775994999a843e648dc._comment
new file mode 100644
index 0000000000..767dfa91c7
--- /dev/null
+++ b/doc/forum/backblaze_s3/comment_3_55362a91c4592775994999a843e648dc._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-05-11T17:04:08Z"
+ content="""
+Thanks for verifying it works. I've updated [[tips/using_Backblaze_B2]] to
+mention this alternative, hopefully I got the config right. (Is the
+endpoint always the same?)
+"""]]
diff --git a/doc/forum/backblaze_s3/comment_4_bd008868a576bf09c6fa188dc8a5907c._comment b/doc/forum/backblaze_s3/comment_4_bd008868a576bf09c6fa188dc8a5907c._comment
new file mode 100644
index 0000000000..ce25cb1bc8
--- /dev/null
+++ b/doc/forum/backblaze_s3/comment_4_bd008868a576bf09c6fa188dc8a5907c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="efraim@78c5af2ab57cf0d7aa23bae3dd0adb700c98217c"
+ nickname="efraim"
+ avatar="http://cdn.libravatar.org/avatar/6dc24928a791046ff66c8c7bd7a33099"
+ subject="comment 4"
+ date="2020-05-12T13:16:51Z"
+ content="""
+my remote ended up being s3.us-west-000.backblazeb2.com but I take it the us-west string can be other regions, and the 000 is 002 in their press release. The code snippet you posted looks good.
+"""]]
diff --git a/doc/forum/backblaze_s3/comment_5_474ca16386680fd359474f05bfbd0375._comment b/doc/forum/backblaze_s3/comment_5_474ca16386680fd359474f05bfbd0375._comment
new file mode 100644
index 0000000000..05ee3ae225
--- /dev/null
+++ b/doc/forum/backblaze_s3/comment_5_474ca16386680fd359474f05bfbd0375._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="albert.lash+git-annex@db81cb2b56cce42192ed75e0be6ce4e73f5af364"
+ nickname="albert.lash+git-annex"
+ avatar="http://cdn.libravatar.org/avatar/f2147841ee06a111e95daa897260d53f"
+ subject="This worked for me too"
+ date="2021-03-13T22:56:57Z"
+ content="""
+Thanks for the explanation about the S3 keys and signature. I was able to set up a backblaze b2 special remote with an eu endpoint. The cost information on [this page on the go version of the b2 remote](https://github.com/encryptio/git-annex-remote-b2#improving-the-financial-cost-of-this-remote) is interesting - is it accurate?
+"""]]
diff --git a/doc/forum/backblaze_s3/comment_6_c84400e7dc58ed7e5db8c7883587e8f8._comment b/doc/forum/backblaze_s3/comment_6_c84400e7dc58ed7e5db8c7883587e8f8._comment
new file mode 100644
index 0000000000..0d198c14c6
--- /dev/null
+++ b/doc/forum/backblaze_s3/comment_6_c84400e7dc58ed7e5db8c7883587e8f8._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-03-22T18:39:46Z"
+ content="""
+I don't know what the financial costs of the API calls work out to,
+but it's true that setting a remote to a higher annex-cost makes git-annex
+avoid using it when possible. And also true that trusting a remote will
+avoid git-annex making API calls to verify that it still contains content.
+
+Bear in mind that trusting a repo can easily lead to data loss in
+situations where you remove content from it, which is
+documented in [[git-annex-trust]]. Indeed, recently git-annex has
+started warning about this when you try to trust a remote. If you are sure
+you'll never remove content from the remote, or will only ever access this
+remore from a single repository, you might be able to convince yourself
+you'll avoid situations where trusting it would lose data.
+"""]]
diff --git a/doc/forum/bainstorming__58___git_annex_push___38___pull.mdwn b/doc/forum/bainstorming__58___git_annex_push___38___pull.mdwn
new file mode 100644
index 0000000000..8a6c552b80
--- /dev/null
+++ b/doc/forum/bainstorming__58___git_annex_push___38___pull.mdwn
@@ -0,0 +1,28 @@
+Wouldn't it make sense to offer
+
+    git annex pull
+
+which would basically do
+
+    git pull
+    git annex get
+
+and
+
+    git annex push
+
+which would do
+
+    git annex commit .
+    git annex put # (the proposed "send to default annex" command)
+    git commit -a -m "$HOST $(date +%F-%H-%M-%S)" # or similar
+    git push
+
+Resulting in commands that are totally analogous to git push & pull: Sync all data from/to a remote.
+
+> Update:
+
+This is useful:
+
+    git config [--global] alias.annex-push '!git pull && git annex add . && git annex copy . --to $REMOTE --fast --quiet && git commit -a -m "$HOST $(date +%F--%H-%M-%S-%Z)" && git push'
+
diff --git a/doc/forum/bainstorming__58___git_annex_push___38___pull/comment_1_3a0bf74b51586354b7a91f8b43472376._comment b/doc/forum/bainstorming__58___git_annex_push___38___pull/comment_1_3a0bf74b51586354b7a91f8b43472376._comment
new file mode 100644
index 0000000000..3d69e8f290
--- /dev/null
+++ b/doc/forum/bainstorming__58___git_annex_push___38___pull/comment_1_3a0bf74b51586354b7a91f8b43472376._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-04-05T18:05:00Z"
+ content="""
+Maybe, otoh, part of the point of git-annex is that the data may be too large to pull down all of it.
+
+I find mr useful as a policy layer over top of git-annex, so \"mr update\" can pull down appropriate quantities of data from
+appropriate locations.
+"""]]
diff --git a/doc/forum/bainstorming__58___git_annex_push___38___pull/comment_2_b02ca09914e788393c01196686f95831._comment b/doc/forum/bainstorming__58___git_annex_push___38___pull/comment_2_b02ca09914e788393c01196686f95831._comment
new file mode 100644
index 0000000000..e0ecc1a819
--- /dev/null
+++ b/doc/forum/bainstorming__58___git_annex_push___38___pull/comment_2_b02ca09914e788393c01196686f95831._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 2"
+ date="2011-04-05T20:52:52Z"
+ content="""
+No-so-subtle sarcasm taken and acknowledged :)
+
+Arguably, git-annex should know about any local limits and not have them implemented via mr from the outside. I guess my concern boils down to having git-annex do the right thing all by itself with minimal user interaction. And while I really do appreciate the flexibility of chaining commands, I am a firm believer in exposing the common use cases as easily as possible.
+
+And yes, I am fully aware that not all annexes are created equal. Point in case, I would never use git annex pull on my laptop, but I would git annex push extensively.
+
+
+"""]]
diff --git a/doc/forum/balance_git_annex_remotes.mdwn b/doc/forum/balance_git_annex_remotes.mdwn
new file mode 100644
index 0000000000..9e10f91409
--- /dev/null
+++ b/doc/forum/balance_git_annex_remotes.mdwn
@@ -0,0 +1,9 @@
+What is the best way to balance files among your remotes? 
+
+use case:
+I have git annex remotes on N external drives, I would like to git annex move --auto --from=$most_used_repo --to= $least_used_repo
+
+expected result: 
+the free space on all my remotes should be more or less equal.
+
+is there a way to do this currently? 
diff --git a/doc/forum/bash_completion.mdwn b/doc/forum/bash_completion.mdwn
new file mode 100644
index 0000000000..649ad0457a
--- /dev/null
+++ b/doc/forum/bash_completion.mdwn
@@ -0,0 +1 @@
+I wrote more than 2 years ago a bash completion file for git-annex (did I miss an official version?) I just updated it today to match current version of git-annex, it is far from perfect, still incomplete, and probably buggy, but works for me. I tried to attach the file in case it could be useful to someone, but it seems that I can't; is it ok to paste the code directly?
diff --git a/doc/forum/bash_completion/comment_1_5c42c0c8e7fc3224bf5406880f9fd0c4._comment b/doc/forum/bash_completion/comment_1_5c42c0c8e7fc3224bf5406880f9fd0c4._comment
new file mode 100644
index 0000000000..7f2f0afd05
--- /dev/null
+++ b/doc/forum/bash_completion/comment_1_5c42c0c8e7fc3224bf5406880f9fd0c4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ringprince"
+ ip="134.76.140.110"
+ subject="comment 1"
+ date="2013-10-10T07:08:21Z"
+ content="""
+I hope it is.  I'd love to use it.
+"""]]
diff --git a/doc/forum/bash_completion/comment_2_6cbe3c825db99bf9188a0de8bb937d5b._comment b/doc/forum/bash_completion/comment_2_6cbe3c825db99bf9188a0de8bb937d5b._comment
new file mode 100644
index 0000000000..72d5e3fc41
--- /dev/null
+++ b/doc/forum/bash_completion/comment_2_6cbe3c825db99bf9188a0de8bb937d5b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 2"
+ date="2013-10-10T09:22:00Z"
+ content="""
+it is, please publish.
+"""]]
diff --git a/doc/forum/bash_completion/comment_3_948c40f1e46ca220d61365aebcd4f6d7._comment b/doc/forum/bash_completion/comment_3_948c40f1e46ca220d61365aebcd4f6d7._comment
new file mode 100644
index 0000000000..fbe659164e
--- /dev/null
+++ b/doc/forum/bash_completion/comment_3_948c40f1e46ca220d61365aebcd4f6d7._comment
@@ -0,0 +1,136 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkUwqII7LhbatqAQY1T5ZZOdPEFcQJKG6I"
+ nickname="Rafael"
+ subject="comment 3"
+ date="2013-10-13T16:14:34Z"
+ content="""
+This code needs the bash-completion file for git by Shawn O. Pearce, I think it is distributed by default on debian. Any feed-back or improvement is welcome! I'm far from expert, use at your own risks.
+
+
+    #!bash
+    #
+    # bash completion support for git-annex
+
+    # depends on git completion file (by Shawn O. Pearce):
+    [ -n \"$__git_whitespacelist\" ] || . $BASH_COMPLETION_DIR/git
+
+
+    # almost copy of __git_aliased_command
+    # requires 2 arguments: alias and main command (after git)
+    __git_aliased_subcommand ()
+    {
+        local word cmdline=$(git --git-dir=\"$(__gitdir)\" \
+            config --get \"alias.$1\")
+        for word in $cmdline; do
+            case \"$word\" in
+                \!*)	: shell command alias ;;
+                -*)	: option ;;
+                *=*)	: setting env ;;
+                git)	: git itself ;;
+                \"$2\")   : main command
+                    local found=1 ;;
+                *)
+                    [ -n \"${found-}\" ] && echo \"$word\"
+                    return
+            esac
+        done
+    }
+
+
+    _git_annex ()
+    {
+        _get_comp_words_by_ref -n =: cur words
+        # $ git annex 2>&1 |sed '1,6d '|grep -v '^$'|grep -v 'commands:$'|cut -c1-12
+        local subcommands=\"
+            add addurl assistant copy drop edit get import importfeed lock
+            mirror move rmurl sync unlock watch webapp content dead describe
+            direct enableremote group indirect init initremote semitrust
+            trust ungroup untrust vicfg addunused dropunused fix forget fsck
+            merge unused upgrade find help list log map status version
+            whereis migrate reinject unannex uninit dropkey
+            \"
+        # plumbing (to complete?): fromkey fuzztest pre-commit rekey test
+        # transferkey transferkeys xmppgit
+        local subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"
+        if [ -z \"$subcommand\" ]; then
+            ## search for aliased subcommand
+            ## works only if the alias is invoked just after git
+            ## (simpler, cf _git function)
+            local maybesubcom maybealias=${words[1]}
+            [ -n \"$maybealias\" ] && # false with a bash alias='git annex'
+            [ \"${maybealias:0:1}\" != '-' ] &&
+            maybesubcom=$(__git_aliased_subcommand \"$maybealias\" annex)
+            for subcommand in $subcommands \"\"; do
+                [ \"$maybesubcom\" = \"$subcommand\" ] && break
+            done
+            [ -z \"$subcommand\" ] &&
+            __gitcomp \"$subcommands\" &&
+            return
+        fi
+        case \"$cur\" in
+            --from=*|--to=*|--trust=*|--semitrust=*|--untrust=*|--in=*)
+                __gitcomp \"here $(__git_remotes)\" \"\" \"${cur##*=}\"
+                ;;
+            --*)
+                __gitcomp \"
+                    --force --fast --auto --all --unused --quiet --verbose --json --debug
+                    --no-debug --from= --to= --numcopies= --time-limit= --trust= --semitrust=
+                    --untrust= --trust-glacier-inventory --backend= --format= --user-agent=
+                    --exclude= --include= --in= --copies= --inbackend= --inallgroup=
+                    --smallerthan= --largerthan= --not --and --or
+                    \"
+                ;;
+            # -*)
+            # __gitcomp \"-( -) -c\"
+            # ;;
+            *)
+                case \"$subcommand\" in
+                    # subcommands with PATH (currently outputs wrongly \"uninit\",
+                    # and not \"reinject\")
+                    # $ tr ' ' '|' <<< $(git annex 2>&1 |sed '1,6d '|grep -v '^$' | \
+                    # grep -v 'commands:$'|grep PATH |cut -c1-12)
+                    add|copy|drop|edit|get|import|lock|mirror|move|unlock|fix| \
+                        fsck|find|list|log|status|whereis|migrate|unannex| \
+                        fromkey|pre-commit|rekey|reinject)
+                        COMPREPLY=() # complete with paths
+                        ;;
+                    addurl|importfeed|rmurl) # URL commands
+                        COMPREPLY=() # at least works with file://...
+                        ;;
+                    init|uninit|unused|merge|status|map|upgrade|version|assistant| \
+                        watch|webapp|direct|indirect|vicfg|forget|help) # | plumbing...
+                        COMPREPLY= # no more args expected
+                        # is 'COMPREPLY=' correct? (seems not standard practice...)
+                        ;;
+                    describe|trust|untrust|semitrust|sync|content|dead|group|ungroup)
+                        __gitcomp \"here $(__git_remotes)\"
+                        # TODO: handle git-annex special remotes
+                        ;;
+                    initremote|enableremote)
+                        case \"$cur\" in
+                            type=*)
+                                __gitcomp \"S3 bup directory rsync gcrypt webdav\" \"\" \"${cur##type=}\"
+                                ;;
+                            encryption=*)
+                                __gitcomp \"none hybrid shared pubkey\" \"\" \"${cur##encryption=}\"
+                                ;;
+
+                            buprepo=|directory=|rsyncurl=)
+                                COMPREPLY=()
+                                # use COMPREPLY (and compgen below) directly because
+                                #  __gitcomp does not handle '*=*' pattern, only '--*=*'
+                                # Writing a __gitannexcomp function may be worth it.
+                                ;;
+                            *)
+                                local initremoteopts=\"
+                                    type= encryption= buprepo= directory= rsyncurl= \"
+                                COMPREPLY=($(compgen -W \"$initremoteopts \" -- \"$cur\"))
+                                ;;
+                        esac
+                        ;;
+                esac
+                ;;
+        esac
+    }
+
+"""]]
diff --git a/doc/forum/bash_completion/comment_4_dbae348b230b780cda91ed8576b8f9fa._comment b/doc/forum/bash_completion/comment_4_dbae348b230b780cda91ed8576b8f9fa._comment
new file mode 100644
index 0000000000..525a613b0b
--- /dev/null
+++ b/doc/forum/bash_completion/comment_4_dbae348b230b780cda91ed8576b8f9fa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 4"
+ date="2013-10-15T17:53:21Z"
+ content="""
+@Rafael, you should put a license on that code..
+"""]]
diff --git a/doc/forum/bash_completion/comment_5_d45570fd750ae8d69dedc3edeef0cc10._comment b/doc/forum/bash_completion/comment_5_d45570fd750ae8d69dedc3edeef0cc10._comment
new file mode 100644
index 0000000000..d6797b5e14
--- /dev/null
+++ b/doc/forum/bash_completion/comment_5_d45570fd750ae8d69dedc3edeef0cc10._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-07-15T15:44:11Z"
+ content="""
+I've recently added built-in bash completion to git-annex, enabled by the
+`bash-completion.bash` file. It knows about all sub-commands,
+and all options, and will automatically always be up-to-date with the
+argument parser!
+
+Currently, it only works for completing "git-annex", not "git annex".
+I have submitted a patch to git's bash completion to make the latter work.
+"""]]
diff --git a/doc/forum/bash_completion/comment_6_2dbfa336ad8957ff0cafd8301ca1150f._comment b/doc/forum/bash_completion/comment_6_2dbfa336ad8957ff0cafd8301ca1150f._comment
new file mode 100644
index 0000000000..5cebfe08f3
--- /dev/null
+++ b/doc/forum/bash_completion/comment_6_2dbfa336ad8957ff0cafd8301ca1150f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d"
+ nickname="wsha.code+ga"
+ subject="comment 6"
+ date="2016-01-10T03:08:24Z"
+ content="""
+It seems that the `bash-completion.bash` file is not included in the standalone Linux tarball. Could it be added? It would be helpful at least for the Arch package in the AUR that is based on the tarball.
+"""]]
diff --git a/doc/forum/bash_completion/comment_7_2fd198746dc7351fe957e7a8150fcb89._comment b/doc/forum/bash_completion/comment_7_2fd198746dc7351fe957e7a8150fcb89._comment
new file mode 100644
index 0000000000..49b95e723a
--- /dev/null
+++ b/doc/forum/bash_completion/comment_7_2fd198746dc7351fe957e7a8150fcb89._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2016-01-11T16:22:02Z"
+ content="""
+It's not included in the standalone tarball because it wouldn't be
+installed in a usable location if it were included.
+
+I continue to think that the git-annex-bin package in Arch is not a good 
+choice. I get more complaints about problems with that package than any
+other distribution package of git-annex. Complicating the tarball to
+support that further is not appealing.
+"""]]
diff --git a/doc/forum/bash_completion/comment_8_7802f4bd08dddd24ac9d19ee7847735f._comment b/doc/forum/bash_completion/comment_8_7802f4bd08dddd24ac9d19ee7847735f._comment
new file mode 100644
index 0000000000..d73e0e7585
--- /dev/null
+++ b/doc/forum/bash_completion/comment_8_7802f4bd08dddd24ac9d19ee7847735f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew@1d92abee601373fe09908b30706c97ffce3da255"
+ nickname="andrew"
+ subject="comment 8"
+ date="2016-01-23T14:24:18Z"
+ content="""
+I think it might still be useful to have in the tarball -- we can symlink it into the right place.
+"""]]
diff --git a/doc/forum/basic_usage_questions.mdwn b/doc/forum/basic_usage_questions.mdwn
new file mode 100644
index 0000000000..cd6a5505b3
--- /dev/null
+++ b/doc/forum/basic_usage_questions.mdwn
@@ -0,0 +1,5 @@
+Seeking some clarification:
+
+ 1. I'm using direct mode. When I run `git annex sync --content` on repo A, all files get copied to repo B, but they remain hidden under `.git/annex/objects`. Is there a way to _automatically_ put them in repo B's working tree, without having to go to repo B and run `git annex sync` there as well? _(I'm sure I saw that happen earlier, but not anymore?)_
+
+ 1. I have two PCs and a portable HD. There are git-annex repos on PC_1 and USB_HD, with each other listed under `git remote`. Now I want to set up git-annex on PC_2. Is it okay to use the same repo path (~/Videos/) on both PCs? I'm concerned that it would confuse the USB_HD repo greatly, as it would end up having two "remotes" with identical paths.
diff --git a/doc/forum/basic_usage_questions/comment_1_c2a5fedc24f8c301d9042999a0371d9f._comment b/doc/forum/basic_usage_questions/comment_1_c2a5fedc24f8c301d9042999a0371d9f._comment
new file mode 100644
index 0000000000..91af0e3ac6
--- /dev/null
+++ b/doc/forum/basic_usage_questions/comment_1_c2a5fedc24f8c301d9042999a0371d9f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-06T15:50:13Z"
+ content="""
+1. You have to run something on the receiving remote to update its working
+tree. Running the assistant in that repository would be one easy option.
+
+2. This is fine, git-annex will notice if a repository on a path changes
+and do the right thing.
+"""]]
diff --git a/doc/forum/basic_usage_questions/comment_2_67d047a107b20874cb71ba311681e181._comment b/doc/forum/basic_usage_questions/comment_2_67d047a107b20874cb71ba311681e181._comment
new file mode 100644
index 0000000000..e6e0225789
--- /dev/null
+++ b/doc/forum/basic_usage_questions/comment_2_67d047a107b20874cb71ba311681e181._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ subject="comment 2"
+ date="2016-01-07T06:19:30Z"
+ content="""
+Alright, thanks. For #1, it sounds like something like Git's hooks/post-receive would be very useful here – can they be used with direct mode, or might git-annex have its own mechanism?
+
+---
+
+Also question 3 – what's the proper way to remove files and have the deletion propagate to all repos? I couldn't find it under \"Removing files\"... Is it `git annex drop --force`? Or should I just `rm` the files and hope that `git annex sync` will pick it up?
+
+The latter seems to work, although the files remain in `git annex unused`, and when I run `git annex dropunused` I again get warnings about \"0 out of 1 copies confirmed\" (so I have to use `--force` again), so it seems like a wrong way?
+
+(These are large read-only video files, I don't care about keeping revision history, only about syncing what I have. I haven't yet done any \"preferred content\" config either...)
+"""]]
diff --git a/doc/forum/basic_usage_questions/comment_3_94b4efa49efbee741c051227b3204562._comment b/doc/forum/basic_usage_questions/comment_3_94b4efa49efbee741c051227b3204562._comment
new file mode 100644
index 0000000000..604903aa0e
--- /dev/null
+++ b/doc/forum/basic_usage_questions/comment_3_94b4efa49efbee741c051227b3204562._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-01-15T19:14:07Z"
+ content="""
+You can use git's post-receive hook to run `git annex merge` to update a
+direct mode repository. See example in
+[[tips/setup_a_public_repository_on_a_web_site]].
+
+It's fine to use --force with dropunused if you really want to force
+deleting the only copy of a file. git-annex will never delete the last copy
+of a file without being forced as a safety measure.
+"""]]
diff --git a/doc/forum/batch_check_on_remote_when_using_copy.mdwn b/doc/forum/batch_check_on_remote_when_using_copy.mdwn
new file mode 100644
index 0000000000..633b61d6f9
--- /dev/null
+++ b/doc/forum/batch_check_on_remote_when_using_copy.mdwn
@@ -0,0 +1,34 @@
+When I copy my local repository with SHA* to a remote repo with SHA*, every single file is checked by itself which seems rather inefficient. When my remote is accessed via ssh, git-annex opens a new connections for every check. If you are not using a ssh key or key agent, this gets tedious...
+
+For all locked files, either git's built-in mechanisms should be used or, if that's not possible, a few hundred checksums (assuming SHA* backend) should be transfered at once and then checked locally before deciding that to transfer.
+
+Once all checks are done, one single transfer session should be started. Creating new sessions and waiting for TCP's slowstart to get going is a lot less than efficient.
+
+
+-- RichiH
+
+> (Use of SHA is irrelevant here, copy does not checksum anything.)
+> 
+> I think what you're seeing is
+> that `git annex copy --to remote` is slow, going to the remote repository
+> every time to see if it has the file, while `git annex copy --from remote`
+> is fast, since it looks at what files are locally present.
+> 
+> That is something I mean to improve. At least `git annex copy --fast --to remote`
+> could easily do a fast copy of all files that are known to be missing from
+> the remote repository. When local and remote git repos are not 100% in sync,
+> relying on that data could miss some files that the remote doesn't have anymore,
+> but local doesn't know it dropped. That's why it's a candidate for `--fast`.
+> 
+> I've just implemented that.
+> 
+> While I do hope to improve ssh usage so that it sshs once, and feeds
+> `git-annex-shell` a series of commands to run, that is a much longer-term
+> thing. --[[Joey]]
+
+>> FYI, in a repo with 1228 files, all small, repos _completely in sync_.
+
+    % git annex copy . --to foo # 1200 seconds
+    % git annex copy . --to foo --fast # 20 seconds
+
+>> RichiH
diff --git a/doc/forum/benefit_of_splitting_a_repository.mdwn b/doc/forum/benefit_of_splitting_a_repository.mdwn
new file mode 100644
index 0000000000..111feb2cf0
--- /dev/null
+++ b/doc/forum/benefit_of_splitting_a_repository.mdwn
@@ -0,0 +1,10 @@
+I am evaluating the best strategy to use git-annex to manage my media library. It consists of about 300.000 files totaling 1 TB of data.
+
+My question is, wheither it would be of advantage to split the repo into several smaller ones (Like Photos, Videos, Musik, Books, ...)?
+
+Would this affect performance of certain operations? I.e. Operations that have superlinear (O(n^a) with a > 1) complexity?
+
+I am thinking about "git annex unused", which takes 22 minutes on my machine performed on the full repo. 
+
+
+Do you have more interesting information on using git-annex in this scale?
diff --git a/doc/forum/benefit_of_splitting_a_repository/comment_1_93a86cb03b66e7ab5dd7146e7b86c9e8._comment b/doc/forum/benefit_of_splitting_a_repository/comment_1_93a86cb03b66e7ab5dd7146e7b86c9e8._comment
new file mode 100644
index 0000000000..72ea4f29bb
--- /dev/null
+++ b/doc/forum/benefit_of_splitting_a_repository/comment_1_93a86cb03b66e7ab5dd7146e7b86c9e8._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 1"
+ date="2012-11-28T18:16:10Z"
+ content="""
+`git-annex unused` needs to scan the entire repository. But it uses a bloom filter, so its complexity is O(n) to the number of keys.
+
+`git annex fsck` scans the entire repository and also reads all available file content. But we have incremental fsck support now.
+
+The rest of git-annex is designed to have good locality.
+
+The main problem you are likely to run into is innefficiencies with git's index file. This file records the status of every file in the repository, and commands like `git add` rewrite the whole file. git-annex uses a journal to minimise operations that need to rewrite the git index file, but this won't help you when you're using raw git commands in the repository.
+
+"""]]
diff --git a/doc/forum/benefit_of_splitting_a_repository/comment_2_4e2fed247298d620fee7be883a1e86a6._comment b/doc/forum/benefit_of_splitting_a_repository/comment_2_4e2fed247298d620fee7be883a1e86a6._comment
new file mode 100644
index 0000000000..c102243f40
--- /dev/null
+++ b/doc/forum/benefit_of_splitting_a_repository/comment_2_4e2fed247298d620fee7be883a1e86a6._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlgyVag95OnpvSzQofjyX0WjW__MOMKsl0"
+ nickname="Sehr"
+ subject="comment 2"
+ date="2012-12-02T19:24:59Z"
+ content="""
+The biggest problem I am facing actually is the git pack-objects command, which takes forever. 
+
+I am not starting it manually, but \"git annex sync\" is. 
+
+Any advice on how to make this faster?
+Does it make sense at all to pack a bunch of uncompressible simlinks?
+
+I already tried the delta=false attrigute, without any (major) effect.
+"""]]
diff --git a/doc/forum/best_practices_for_importing_photos__63__.mdwn b/doc/forum/best_practices_for_importing_photos__63__.mdwn
new file mode 100644
index 0000000000..2f57f3b35e
--- /dev/null
+++ b/doc/forum/best_practices_for_importing_photos__63__.mdwn
@@ -0,0 +1,13 @@
+What are everyone's tips for importing photos to make best use of metadata and views?
+
+Let's assume there's no need to be compatible with a photo manager app, but we may be importing lots of duplicates, and while content deduplication is great, I'd like to avoid naming problems too.
+
+Do you bother to rename your photos?
+
+Do you use EXIF metadata as git-annex metadata? Selectively or wholesale, with all the redundant tags in EXIF?
+
+If you do use a photo manager app, do you need to do anything special to make that work?
+
+Thanks for your responses everyone!
+
+-mike
diff --git a/doc/forum/best_practices_for_importing_photos__63__/comment_1_37f0ae4b552ec2a4a144ddcdc17c8453._comment b/doc/forum/best_practices_for_importing_photos__63__/comment_1_37f0ae4b552ec2a4a144ddcdc17c8453._comment
new file mode 100644
index 0000000000..3d17874ad5
--- /dev/null
+++ b/doc/forum/best_practices_for_importing_photos__63__/comment_1_37f0ae4b552ec2a4a144ddcdc17c8453._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="178.79.137.64"
+ subject="comment 1"
+ date="2014-04-15T14:25:04Z"
+ content="""
+git-annex's metadata and views made me stop hopping between programs (digikam, tagsistant etc.) to organise my photos (I had even just started working on my own FUSE tagging filesystem which was effectively going to be tagsistant, but with a git-annex'y backend).
+
+As usual, my method is probably a little odd :)
+
+Photos are 'git import'ed into a $(uuidgen) directory (so no worries about filename collisions) and tagged with media=Photograph and tag=untagged. Then I go through them and add relevant tags (one of which is \"xbmc\", no prizes for guessing how that works with the views :]) and move them into a more appropriate directory structure, using gqview and its \"sort manager\". This is really nice and fast, due to it only copying/moving symlinks!
+
+One thing I'm considering doing it putting a shim between git-annex and gqview, so that it generates entries in the sort manager which are appropriate for the current view. So, for example, if the view is location=*, the sort manager would have:
+
+    location=Malta
+    location=York
+
+While it wouldn't get updated if I create new tags (by creating directories in the view), it would save a lot of time creating them every time the view changes.
+"""]]
diff --git a/doc/forum/best_practices_for_importing_photos__63__/comment_2_7f96f0fe0fc073321bd7c5bbd9048425._comment b/doc/forum/best_practices_for_importing_photos__63__/comment_2_7f96f0fe0fc073321bd7c5bbd9048425._comment
new file mode 100644
index 0000000000..349ee432a3
--- /dev/null
+++ b/doc/forum/best_practices_for_importing_photos__63__/comment_2_7f96f0fe0fc073321bd7c5bbd9048425._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 2"
+ date="2014-04-17T20:11:59Z"
+ content="""
+It seems to me that there is a lot of cruft in EXIF that I would not want to bloat my git-annex branch with storing. That's why [[tips/automatically_adding_metadata]] imports only the listed fields. It's easy to add fields later and re-run the metadata importer on your existing files.
+
+I have not gotten as far as having any best practices to share. :)
+
+"""]]
diff --git a/doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system.mdwn b/doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system.mdwn
new file mode 100644
index 0000000000..5c9a2a4924
--- /dev/null
+++ b/doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system.mdwn
@@ -0,0 +1,6 @@
+Hi all,
+i'm looking for the right command to move a git annex repo througt filesystem without breaking all the symlink and so and without changing the id of the repo.
+My current hard drive have become to small to store all what i have so i have bought a new on and have mounted it in a directory named shared, now i want to
+move all my repo (repo1 repo2 etc...) too shared can anyone give me the best move option to do that ?
+
+best regards.
diff --git a/doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system/comment_1_50b0f3b42c5c7185c51451af80749718._comment b/doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system/comment_1_50b0f3b42c5c7185c51451af80749718._comment
new file mode 100644
index 0000000000..c02422e897
--- /dev/null
+++ b/doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system/comment_1_50b0f3b42c5c7185c51451af80749718._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 1"
+ date="2020-07-14T20:13:22Z"
+ content="""
+> i'm looking for the right command to move a git annex repo througt filesystem without breaking all the symlink
+
+Can't you just `mv` the top-level directory?  Symlinks are relative:
+
+```
+one -> .git/annex/objects/0J/J1/SHA256E-s4--2c8b08da5ce60398e1f19af0e5dccc744df274b826abe585eaba68c525434806/SHA256E-s4--2c8b08da5ce60398e1f19af0e5dccc744df274b826abe585eaba68c525434806
+```
+"""]]
diff --git a/doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system/comment_2_e3e30ca123cd840288655c25b688cd66._comment b/doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system/comment_2_e3e30ca123cd840288655c25b688cd66._comment
new file mode 100644
index 0000000000..0dd3c5612a
--- /dev/null
+++ b/doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system/comment_2_e3e30ca123cd840288655c25b688cd66._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ghen1"
+ avatar="http://cdn.libravatar.org/avatar/efd0e92b6198291138f0cd7aedbf86b6"
+ subject="comment 2"
+ date="2020-07-27T15:18:52Z"
+ content="""
+You can move the folder like any other folder.
+"""]]
diff --git a/doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system/comment_3_00418ada32a4d93dfd3334686e391a23._comment b/doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system/comment_3_00418ada32a4d93dfd3334686e391a23._comment
new file mode 100644
index 0000000000..ac33c4c176
--- /dev/null
+++ b/doc/forum/best_way_to_move_a_git_annex_repo_trought_file_system/comment_3_00418ada32a4d93dfd3334686e391a23._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-07-27T15:38:22Z"
+ content="""
+Yeah, this is not really a problem. Do note that, when a git-annex repo is
+moved to a new drive, this does change some of the internal details that
+git-annex keeps track of (inode numbers). If the repository has unlocked
+files in it, this can make git-annex's handling of those a little slow at
+first, until it learns the new details.
+"""]]
diff --git a/doc/forum/big_overhead.mdwn b/doc/forum/big_overhead.mdwn
new file mode 100644
index 0000000000..f16b95942b
--- /dev/null
+++ b/doc/forum/big_overhead.mdwn
@@ -0,0 +1,46 @@
+[[!meta title="unreachable git objects"]]
+
+Hi,
+
+I am been seeing quite big overheads using `git-annex`.  Is this is normal?
+
+The `.git/objects` folder is explosive in my system, often being larger
+than the content watched by git-annex.  Here's the actual statistics
+of my git-annex folders, where the fourth column is calculated as col3/(col2-col3).
+
+[[!table  data="""
+folder,size,size .git,relative size
+conf.annex,777536,720100,12.537433
+doc.annex,20351624,11260204,1.2385528
+images.annex,817064,435580,1.1418041
+misc.annex,803328,572476,2.4798399
+music.annex,23756116,9192740,0.63122314"""]]
+
+That is, four of five repos require more space for the `.git` folder than the actual files.  Most of this comes from the `objects` folder.  
+
+Number of files:
+
+[[!table data="""
+folder,no. files,no files .git,relative size
+conf.annex,11350,9539,5.2672557
+doc.annex,84954,66824,3.6858246
+images.annex,92787,91285,60.775632
+misc.annex,95461,95160,316.14618
+music.annex,16414,13520,4.6717346
+"""]]
+
+
+I use the assistant web interface, and direct
+mode.  I use two laptops running Linux that are synchronized
+directly over LAN at home or via a transfer repo on a ssh server
+where git-annex is installed.  The latter is set up using the web interface and the gcrypt repo.
+[Mostly, the transfer repo isn't working
+and I often end up with only symlinks on the computer where I did not edit the file in question, 
+but this is probably unrelated.]
+
+I have previously tried to fix it using `git gc` or `git annex forget`, but it doesn't seem to significantly reduce the sizes, and what it helps isn't persistent.
+
+Is this kind of 'overhead' something that one must accept when using
+`git-annex` or do such numbers indicate that something is wrong?
+
+Thanks.
diff --git a/doc/forum/big_overhead/comment_10_d5f4e353e7f711d8c38cdcc222339bca._comment b/doc/forum/big_overhead/comment_10_d5f4e353e7f711d8c38cdcc222339bca._comment
new file mode 100644
index 0000000000..2ebd56d30e
--- /dev/null
+++ b/doc/forum/big_overhead/comment_10_d5f4e353e7f711d8c38cdcc222339bca._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 10"
+ date="2014-09-18T17:27:36Z"
+ content="""
+In the meantime, I've been looking over the Annex.Branch code. 
+
+`stageJournal` is only ever called in code paths that commit the updated index, so those code paths cannot result in dangling objects unless git-annex is interrupted before it can commit. (This may explain some of my own repos having a few dangling refs, that were not commits; I could have ctrl-c'd git-annex.)
+
+It's possible for a forced update of the local git-annex branch, done by eg a push from another repo, to overwrite a commit made to it. In this case, the git-annex index is merged with the branch, resulting in a new commit, and the old commit that was overwritten will indeed be dangling. However, `git annex sync` doesn't overwrite the git-annex branch; it pushes to synced/git-annex, or does a `taggedPush` to a private ref. It is the case that both those pushes are forced pushes, so can overwrite a branch ref and leave the old commit it pointed to dangling. In the case of `taggedPush`, the old commit should be a parent of the new, so it won't dangle. In the case of synced/git-annex being overwritten, the old commit could dangle, but only until whatever repo pushed it syncs again, at which time it should get incorporated as one of the parents of the new synced/git-annex it pushes. So, I don't see how long-term dangling commits could happen this way, except for in the case where a repository stops syncing/goes missing/rebases its git-annex branch (ie, git-annex forget is used). (This may explain the 2 dangling commits I found on elephant; we did delete some clones of that repository recently.)
+
+At this point I'm not convinced that the dangling objects I found in my own repos are due to some systematic problem, the above seems like it could explain them, and the above is not a problem on the class of the one Rasmus is having. Of course, it's hard to be sure you've spotted all possible ways that a resource leak can happen, and that's what these dangling objects basically are.
+"""]]
diff --git a/doc/forum/big_overhead/comment_11_cbf25217e4149f2cfad4e2bf94f2b4ca._comment b/doc/forum/big_overhead/comment_11_cbf25217e4149f2cfad4e2bf94f2b4ca._comment
new file mode 100644
index 0000000000..e2a74068d7
--- /dev/null
+++ b/doc/forum/big_overhead/comment_11_cbf25217e4149f2cfad4e2bf94f2b4ca._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 11"
+ date="2014-09-18T17:32:09Z"
+ content="""
+I knew I *had* used \"Initial commit\" somewhere ... etckeeper uses that message. And commits as root. Could an etckeeper repo have somehow gotten merged into your git-annex repo? Seems strange, and the filenames and contents don't really look like /etc to me, but it otherwise somewhat fits.
+"""]]
diff --git a/doc/forum/big_overhead/comment_12_475d5af95adcfcd3a51e10f270205eb7._comment b/doc/forum/big_overhead/comment_12_475d5af95adcfcd3a51e10f270205eb7._comment
new file mode 100644
index 0000000000..53e15b7642
--- /dev/null
+++ b/doc/forum/big_overhead/comment_12_475d5af95adcfcd3a51e10f270205eb7._comment
@@ -0,0 +1,71 @@
+[[!comment format=mdwn
+ username="rasmus"
+ ip="146.185.23.178"
+ subject="comment 12"
+ date="2014-09-19T00:43:56Z"
+ content="""
+Hi Joey,
+
+Thanks for giving the thread a more appropriate title and thanks for the helpful messages. 
+
+Let me start with the easy points:
+
+
+* Looking at my log file of installed packages I have never used `etckeeper` on my system.  So unless it could have entered through `annex` then I think we can rule that one out. 
+* According to `git log` the repos are from January 2014 where I restarted my repos. 
+
+
+        commit 029a8e76ab5f66aa4390987130985550a1ccd69c
+        Author: Rasmus <w530@domain.eu>
+        Date:   Thu Jan 23 21:06:13 2014 +0100
+
+        created repository
+
+
+* When I start git repos I typically just use \"init\" so I don't think I did the 2012 commits. 
+* I checked out one of the 74mb files.  When I do `file test.blob` it shows `test.blob: GPG symmetrically encrypted data (CAST5 cipher)`.  But none of my normal passwords worked.  Could such a gpg'ed file be from local network connections where the assistant asks for a passphrase?  I'm pretty sure that my transfer repo has only been using `gcrypt` and I believe I \"restarted\" my repos because I switched to `gcrypt` repos.  Also, my transfer repo is 10Gb as well which sounds big for transfer repo. 
+
+I performed a similar \"analysis\" on the `conf.annex` repo which should contain mostly no binary files (some 16x16 pngs etc).  
+
+`conf.annex` has 727 unreachable objects and 3477 commits in total.  Of these 338 are commits.  Here's an example of a larger commit message of an unreachable commit.
+
+    commit 601c10f9512e8d3502d9dd52ef409560ebb5b7e0
+    Author: root <root@localhost>
+    Date:   Mon Dec 31 19:00:01 2012 -0400
+
+         Initial commit
+
+     diff --git a/6fbbea493cdec9d912d256374199cc4c012022d35524c8789a7aceeb953442a5 b/6fbbea493cdec9d912d256374199cc4c012022d35524c8789a7aceeb953442a5
+     new file mode 100644
+     index 0000000..ea5fcc3
+     Binary files /dev/null and b/6fbbea493cdec9d912d256374199cc4c012022d35524c8789a7aceeb953442a5 differ
+     diff --git a/91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a b/91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a
+     new file mode 100644
+     index 0000000..a86c1a9
+     Binary files /dev/null and b/91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a differ
+     diff --git a/9da3fcfc1635c674012c35d90c21adce3c35440e629d64fe117fe349a6b3e194 b/9da3fcfc1635c674012c35d90c21adce3c35440e629d64fe117fe349a6b3e194
+     new file mode 100644
+     index 0000000..ef1d71c
+     Binary files /dev/null and b/9da3fcfc1635c674012c35d90c21adce3c35440e629d64fe117fe349a6b3e194 differ
+     diff --git a/ad4ae79c29b3756f7e41257db7454f3c319112d06385a8bc12d28209a82f2594 b/ad4ae79c29b3756f7e41257db7454f3c319112d06385a8bc12d28209a82f2594
+     new file mode 100644
+     index 0000000..61d3e5b
+     Binary files /dev/null and b/ad4ae79c29b3756f7e41257db7454f3c319112d06385a8bc12d28209a82f2594 differ
+     diff --git a/bd0e9cb492077e0c090bc62892c8de438c51a956c8215b2c68de7caa7e2431cc b/bd0e9cb492077e0c090bc62892c8de438c51a956c8215b2c68de7caa7e2431cc
+     new file mode 100644
+     index 0000000..92e9bd7
+     Binary files /dev/null and b/bd0e9cb492077e0c090bc62892c8de438c51a956c8215b2c68de7caa7e2431cc differ
+
+Across all commits 6006 objects are mentioned, but only 371 are unique. 
+
+I checked out one blob and again `file` reports `GPG symmetrically encrypted data (CAST5 cipher)`.  Interesting for `conf.annex` I get this line when trying to decrypt
+
+    gpg: DBG: cleared passphrase cached with ID: SBF83A0F822D0F664
+
+
+For `doc.annex` I get
+
+    gpg: DBG: cleared passphrase cached with ID: S32DEAD1E8DD06A4D
+
+And on my other computer I see a third ID.  I'm not sure if this means anything when files are symmetrically encrypted, though. 
+"""]]
diff --git a/doc/forum/big_overhead/comment_13_1c8cc992f04fc63179094c494bd25025._comment b/doc/forum/big_overhead/comment_13_1c8cc992f04fc63179094c494bd25025._comment
new file mode 100644
index 0000000000..229ef256a7
--- /dev/null
+++ b/doc/forum/big_overhead/comment_13_1c8cc992f04fc63179094c494bd25025._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="I know what it is now"
+ date="2014-09-19T02:43:22Z"
+ content="""
+These objects are the ones written by git-remote-gcrypt when pushing to a remote. That's why the weird dates, root pseudo-commit, crazy filenames, and big gpg encrypted blobs. All countermeasures that git-remote-gcrypt uses to keep your encrypted git remote safe and not leak information about what's in it.
+
+So, this is a bug in git-remote-gcrypt. It needs to clean these objects up after pushing them! (Also after failed pushes.)
+"""]]
diff --git a/doc/forum/big_overhead/comment_14_cbfb3d557915258e72c65a4e84df77a9._comment b/doc/forum/big_overhead/comment_14_cbfb3d557915258e72c65a4e84df77a9._comment
new file mode 100644
index 0000000000..87632c9093
--- /dev/null
+++ b/doc/forum/big_overhead/comment_14_cbfb3d557915258e72c65a4e84df77a9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 14"
+ date="2014-09-19T02:59:36Z"
+ content="""
+<https://github.com/bluss/git-remote-gcrypt/issues/16>
+"""]]
diff --git a/doc/forum/big_overhead/comment_15_b973529bae549bcbaaae792f0403989b._comment b/doc/forum/big_overhead/comment_15_b973529bae549bcbaaae792f0403989b._comment
new file mode 100644
index 0000000000..a875cc34e1
--- /dev/null
+++ b/doc/forum/big_overhead/comment_15_b973529bae549bcbaaae792f0403989b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="rasmus"
+ ip="217.130.110.20"
+ subject="comment 15"
+ date="2014-09-19T06:29:58Z"
+ content="""
+Brilliant!  Thanks for taking time to analyze the issue and taking the bug to `gcrypt`.
+
+[I'm surprised that a different key than my git-annex key is used and that it's a symmetric key, but I will explore the technology on my own].
+"""]]
diff --git a/doc/forum/big_overhead/comment_1_0c184520c30a89bd2604ab7c0eb7ac45._comment b/doc/forum/big_overhead/comment_1_0c184520c30a89bd2604ab7c0eb7ac45._comment
new file mode 100644
index 0000000000..20c2ff6c02
--- /dev/null
+++ b/doc/forum/big_overhead/comment_1_0c184520c30a89bd2604ab7c0eb7ac45._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm8wY171R5c4u_jPmB6LU6n6Px2xePM4sE"
+ nickname="Efraim"
+ subject="comment 1"
+ date="2014-09-07T14:09:05Z"
+ content="""
+have you tried from the command line `git annex unused` to see if you have unused files in your repo? From the assistant, the option under configuration -> Unused files gives you an option to expire old files after a period of time so they get deleted from your repo.
+"""]]
diff --git a/doc/forum/big_overhead/comment_2_13a017c6c84511894ded2d89d86eb541._comment b/doc/forum/big_overhead/comment_2_13a017c6c84511894ded2d89d86eb541._comment
new file mode 100644
index 0000000000..25d010fe11
--- /dev/null
+++ b/doc/forum/big_overhead/comment_2_13a017c6c84511894ded2d89d86eb541._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="rasmus"
+ ip="109.201.154.150"
+ subject="comment 2"
+ date="2014-09-07T15:17:25Z"
+ content="""
+Thanks for help, Efraim.
+
+I'm not sure this is it.  On my other laptop, where the above statics were not calculated the `.git` folder of `doc.annex` is 26Gb (contents is 8.6Gb).  Meanwhile, unused files are 0.6Gb.  In `conf.annex` the `.git` folder is 3.2Gb, content is 70Mb and unused files is 2.2Mb.  I used the web interface to find the size of unused files.
+"""]]
diff --git a/doc/forum/big_overhead/comment_3_b4761cacc02396b5bdf34bcf3457cb91._comment b/doc/forum/big_overhead/comment_3_b4761cacc02396b5bdf34bcf3457cb91._comment
new file mode 100644
index 0000000000..f090e5b258
--- /dev/null
+++ b/doc/forum/big_overhead/comment_3_b4761cacc02396b5bdf34bcf3457cb91._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="Claes"
+ subject="repack parameters"
+ date="2014-09-07T21:53:10Z"
+ content="""
+Because git-annex tracks all the events of an annexed file for each repo -- added, dropped, copied etc -- and it tracks these in one object per file in the git-annex branch, it does indeed create a lot of objects. To improve both space and performance I made sure to add `git gc --auto` as a post-commit hook, as the objects in my case can quickly reach the tens or even hundreds of thousands.
+
+To further improve performance and space, you can choose to set `pack.window` and `pack.depth` to vastly higher values than the defaults (10 and 50, respectively), because there is a large amount of objects with very similar content. I did a `git repack --window 2500 --depth 1000 -f -a d` and brought down my repo from 3 GiB (packed!) to 300 MiB. Make sure to have a lot of memory and CPU available when doing this, or it will take forever. You can set `pack.window` ridiculously high if you like, as long as you limit it with `pack.windowMemory`, so that it makes use of all your available memory for comparing objects and finding the optimal delta.
+"""]]
diff --git a/doc/forum/big_overhead/comment_4_633f8538f368220eaca82b8bbfe9b49d._comment b/doc/forum/big_overhead/comment_4_633f8538f368220eaca82b8bbfe9b49d._comment
new file mode 100644
index 0000000000..a0001f71e1
--- /dev/null
+++ b/doc/forum/big_overhead/comment_4_633f8538f368220eaca82b8bbfe9b49d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="rasmus"
+ ip="109.201.154.209"
+ subject="Re: repack parameters"
+ date="2014-09-08T13:20:36Z"
+ content="""
+Thanks for your tips, Claes.  I was really aware of `git repack` and that set of parameters.
+
+I didn't mention, but sadly I'd run `git gc` on the repos just before collecting the above numbers.
+
+I tried to repack two repositories -- `doc.annex` and `config.annex` -- using the values you suggested.   However, it did not have any measurable effect (less than 100mb in both cases).  
+
+The number of unused files seem to be (much) less than 500 files in the repos.
+
+BTW: All of the extra size is in the `.git/objects/` folder.  `.git/annex/` is quite small (always much less than 1GB).  Would that indicate that large files are checked in with git sans annex somehow?
+"""]]
diff --git a/doc/forum/big_overhead/comment_5_599092b8d4f1fc8f378796328ef42931._comment b/doc/forum/big_overhead/comment_5_599092b8d4f1fc8f378796328ef42931._comment
new file mode 100644
index 0000000000..ee91a5b2bd
--- /dev/null
+++ b/doc/forum/big_overhead/comment_5_599092b8d4f1fc8f378796328ef42931._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="rasmus"
+ ip="109.201.154.183"
+ subject="comment 5"
+ date="2014-09-08T13:48:03Z"
+ content="""
+So `git prune` worked wonders on my repos, getting rid of GBs of stuff in the `.git/objects` folders.  I don't know why they weren't picked up by `git gc`.  In retrospect, it was perhaps a bit careless of me to run `git prune` directly, but hopefully I will be OK. . .
+"""]]
diff --git a/doc/forum/big_overhead/comment_6_adb4b4e7eb4dac7760f3425bae6cbbc2._comment b/doc/forum/big_overhead/comment_6_adb4b4e7eb4dac7760f3425bae6cbbc2._comment
new file mode 100644
index 0000000000..0bc1763a3d
--- /dev/null
+++ b/doc/forum/big_overhead/comment_6_adb4b4e7eb4dac7760f3425bae6cbbc2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="rasmus"
+ ip="193.145.48.43"
+ subject="comment 6"
+ date="2014-09-10T12:07:53Z"
+ content="""
+Seems `git prune` only worked as a temporary fix.  My `doc.annex/.git/objects` is 3.6Gb after two days.  I don't get why `git` sans `annex` is checking in stuff -- which I assume is the reason it's stored in `.git/objects`.
+"""]]
diff --git a/doc/forum/big_overhead/comment_7_a762eb55addf81c1c5350c7968598d0f._comment b/doc/forum/big_overhead/comment_7_a762eb55addf81c1c5350c7968598d0f._comment
new file mode 100644
index 0000000000..1ec6a6eef6
--- /dev/null
+++ b/doc/forum/big_overhead/comment_7_a762eb55addf81c1c5350c7968598d0f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 7"
+ date="2014-09-17T20:20:40Z"
+ content="""
+There are a few things that can cause git to leave unreachable objects. These include: Rebasing; interrupting a pull before it updates the refs; running git add on a file and then changing the file's content and adding it a second time before committing.
+
+I can think of one case where this happens when using git-annex at the command line: `git annex add $file; git mv $file other-directory; git commit` will result in a dangling object storing the old symlink target before the file was moved.
+
+It'd be useful to investigate, by using `git fsck --unreachable` to get a list of currently unreachable objects, and then use `git show` to look at the objects and try to determine where they came from. Ie, are they symlink targets or are they git-annex location log files (formatted as columns of timestamps and uuids). Any unreachable commits would be the most useful to investigate.
+
+I see a few loose objects here and there in my annexes, but not very many, and git-gc has cleaned up old ones (> 1 month old). Some of them seem to be location log files. I see those in both repositories where I use the assistant, and repositories where I use only command line git-annex. I was able to find 2 unreachable commits in a repository that runs the assistant full-time; both commits were \"merging origin/synced/git-annex into git-annex\". This suggests to me that perhaps the assistant merged the git-annex branch but that merge was overwritten by another thread that committed changes to the branch at the same time.
+
+You should also check the size of inodes on your system; a thousand small loose objects in .git/objects does not normally take up gigabytes of space; with typical inode sizes it might use up a few megabytes. With 1 mb inodes, those same thousand files would use 1 gb..
+"""]]
diff --git a/doc/forum/big_overhead/comment_8_4a66f57c6c0bdc6123618cb69a719be5._comment b/doc/forum/big_overhead/comment_8_4a66f57c6c0bdc6123618cb69a719be5._comment
new file mode 100644
index 0000000000..fdbebf4e4d
--- /dev/null
+++ b/doc/forum/big_overhead/comment_8_4a66f57c6c0bdc6123618cb69a719be5._comment
@@ -0,0 +1,65 @@
+[[!comment format=mdwn
+ username="rasmus"
+ ip="217.130.110.20"
+ subject="comment 8"
+ date="2014-09-18T11:28:45Z"
+ content="""
+Hi Joey,
+
+Thanks for your careful reply.  
+
+Easy things first:
+
+I *never* add anything from the terminal, though I may do checks and `git annex get`, since sometimes the assistance actually grab the updated files.  Until recently I started git annex automatically on boot, but at the moment it simply renders my laptop useless for too long -- presumably due to the errors investigated here.
+
+I use btrfs (don't ask me why).  Searching online, I did not find a way to find the size of inodes, but I assume that it's sensible?  tune2fs doesn't work but as I understand it is designed for ext*.
+
+What takes up space in my `.git/objects` is files of several Mb.  So at the moment the `pack` folder is 700mb.  In the next biggest folder there's three files that are 73,4mb and 8 files that are 4kb.  This pattern repeats.  A couple of large files (73,4 shows up quite a bit as well as 45) and many small files. 
+
+I have an astonishing amount of dangling objects.  In the `doc.annex` `git rev-list HEAD --count` gives 27354.  In this repo I have 1108 unreachable blobs and commits, respectively 569 and 539.  This probably explains why `git prune` solves my problem but I don't understand why all these large files reappears when I sync -- even after having run `git prune` on both laptops.  Could they come from the `annex` on my remote server?
+
+`git show` isn't nice on blobs, but here is an example of a dangling commit
+
+
+    commit 478425bef867782e8ff22aca24316e9421288c49
+    Author: root <root@localhost>
+    Date:   Mon Dec 31 19:00:01 2012 -0400
+
+        Initial commit
+
+    diff --git a/6e5039464b41f39088a4aece64ced787aa2b04ec2dd5ac6f6c6ca4b9a06a99e5 b/6e5039464b41f39088a4aece64ced787aa2b04ec2dd5ac6f6c6ca4b9a06a99e5
+    new file mode 100644
+    index 0000000..af12763
+    Binary files /dev/null and b/6e5039464b41f39088a4aece64ced787aa2b04ec2dd5ac6f6c6ca4b9a06a99e5 differ
+    diff --git a/8ae4ee273eb540fb71b78152d10010ea2dd3d1bb82afe410ecf3d811cb72bd6d b/8ae4ee273eb540fb71b78152d10010ea2dd3d1bb82afe410ecf3d811cb72bd6d
+    new file mode 100644
+    index 0000000..0a6af91
+    Binary files /dev/null and b/8ae4ee273eb540fb71b78152d10010ea2dd3d1bb82afe410ecf3d811cb72bd6d differ
+    diff --git a/91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a b/91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a
+    new file mode 100644
+    index 0000000..26d921e
+    Binary files /dev/null and b/91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a differ
+    diff --git a/9f7728197cfcd9792eef1ff5930a4ab580e38e64291037130f1ad0914e34a1fc b/9f7728197cfcd9792eef1ff5930a4ab580e38e64291037130f1ad0914e34a1fc
+    new file mode 100644
+    index 0000000..2a92974
+    Binary files /dev/null and b/9f7728197cfcd9792eef1ff5930a4ab580e38e64291037130f1ad0914e34a1fc differ
+    diff --git a/ac801235d97275e761efa12a76ee009472cae8549a0835d5be8bd3f6657047fb b/ac801235d97275e761efa12a76ee009472cae8549a0835d5be8bd3f6657047fb
+    new file mode 100644
+    index 0000000..543430c
+    Binary files /dev/null and b/ac801235d97275e761efa12a76ee009472cae8549a0835d5be8bd3f6657047fb differ
+    diff --git a/d400d0f616a980ea5e3ef68a1f9d670d1eeccbd27f34d1cb7ea976e1f98e2fb7 b/d400d0f616a980ea5e3ef68a1f9d670d1eeccbd27f34d1cb7ea976e1f98e2fb7
+    new file mode 100644
+    index 0000000..7b7eadd
+    Binary files /dev/null and b/d400d0f616a980ea5e3ef68a1f9d670d1eeccbd27f34d1cb7ea976e1f98e2fb7 differ
+    diff --git a/e988a26fbabe3f498e2a564096948eafb289ccadfb186423c1f63c5a3b2c19db b/e988a26fbabe3f498e2a564096948eafb289ccadfb186423c1f63c5a3b2c19db
+    new file mode 100644
+    index 0000000..3bd1dfa
+    Binary files /dev/null and b/e988a26fbabe3f498e2a564096948eafb289ccadfb186423c1f63c5a3b2c19db differ
+
+There are several things I don't understand.  Why is the author root?  I never run `git annex` with `sudo` or as root.  I think the date is bogus.  I'm pretty sure I wasn't even running `git annex` in 2012 much less working with this repo. . . What is weird is that this is the date for *all* lost commits!  (Same for Author).  Over all lost commits there are 2352 binary files that differ.  Of these there are 284 unique hashes. . .  I don't know what this means other than my repo being seriously messed up.  I don't understand what I did wrong to end up in this state as I have been fairly careful in mainly using the `webapp`.
+
+I wonder if the best way to proceed is to start over, or whether this repo can be recovered.
+
+Thanks,
+Rasmus
+"""]]
diff --git a/doc/forum/big_overhead/comment_9_5fa681ea0d6bd0dcac7142d40df9d54f._comment b/doc/forum/big_overhead/comment_9_5fa681ea0d6bd0dcac7142d40df9d54f._comment
new file mode 100644
index 0000000000..856f326f4f
--- /dev/null
+++ b/doc/forum/big_overhead/comment_9_5fa681ea0d6bd0dcac7142d40df9d54f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 9"
+ date="2014-09-18T16:54:10Z"
+ content="""
+That is a very strange commit by every metric. Weird author, weird date, weird filenames in it (not files that git-annex uses!), with apparently some weird binary content (which git-annex would not be committing). Even a weird commit message -- git-annex never makes a commit with a message of \"Initial commit\", and as far as I can tell using `git log -S`, it never has. (OTOH, it's a pretty common example message used in eg, git documentation.) So, I feel pretty sure that dangling commit was not made by git-annex.
+
+I think you need to take a look at some of the 4+mb unreachable blobs, to get some idea of what these files are. One way is to use git-show on the hash of one of the blobs to get its content, and then, perhaps pass it to `file` or `strings`. Or, you could stop the assistant, `git checkout 478425bef867782e8ff22aca24316e9421288c49` and have a look at this strange tree that was apparently committed in 2012 to see what's in there.
+
+It might be possible that the dangling commits come somehow from the remote server. I'm not 100% sure, but I think that a git pack can end up with dangling objects in it, and then git can pull down that pack to get other, non-dangling objects. You should use `git show` on the server on some of the dangling shas to see if they are present there.
+"""]]
diff --git a/doc/forum/browse_files_on_server.mdwn b/doc/forum/browse_files_on_server.mdwn
new file mode 100644
index 0000000000..1e96f08a04
--- /dev/null
+++ b/doc/forum/browse_files_on_server.mdwn
@@ -0,0 +1 @@
+Hi. I have a local repository on my computer and a transfer repository on my server. When I ssh into the server, I see the git repo, but none of the files. Is there a way to browse my files in the transfer repository?
diff --git a/doc/forum/browse_files_on_server/comment_1_5023c6f9f4a8a7724ff057076f64ec1d._comment b/doc/forum/browse_files_on_server/comment_1_5023c6f9f4a8a7724ff057076f64ec1d._comment
new file mode 100644
index 0000000000..55d162e134
--- /dev/null
+++ b/doc/forum/browse_files_on_server/comment_1_5023c6f9f4a8a7724ff057076f64ec1d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-05-29T13:40:04Z"
+ content="""
+You have to run `git annex sync` on the server too.
+"""]]
diff --git a/doc/forum/browse_files_on_server/comment_2_67096b34041fed07bbf1d0cb243e1efc._comment b/doc/forum/browse_files_on_server/comment_2_67096b34041fed07bbf1d0cb243e1efc._comment
new file mode 100644
index 0000000000..3f4e672b91
--- /dev/null
+++ b/doc/forum/browse_files_on_server/comment_2_67096b34041fed07bbf1d0cb243e1efc._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="frodo"
+ avatar="http://cdn.libravatar.org/avatar/a647438d8bd49248b7e2cfe0ce3ecd4e"
+ subject="comment 2"
+ date="2021-05-29T13:51:50Z"
+ content="""
+I tried running that, and got the following output:
+
+% git annex sync
+commit 
+fatal: this operation must be run in a work tree
+ok
+
+I can see through the web interface that the clients have uploaded the files to the server. I just can't browse them.
+"""]]
diff --git a/doc/forum/browse_files_on_server/comment_3_148f1aa0d46dcf51b855b6fb18b6a549._comment b/doc/forum/browse_files_on_server/comment_3_148f1aa0d46dcf51b855b6fb18b6a549._comment
new file mode 100644
index 0000000000..84fe921a95
--- /dev/null
+++ b/doc/forum/browse_files_on_server/comment_3_148f1aa0d46dcf51b855b6fb18b6a549._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2021-05-29T17:22:40Z"
+ content="""
+Then you have a bare git repo. You can convert it to a normal one like this:
+    
+    mkdir bla
+    mv bla.git bla/.git
+    cd bla
+    git config core.bare false
+    git checkout master
+"""]]
diff --git a/doc/forum/btsync_equivalent__63__.mdwn b/doc/forum/btsync_equivalent__63__.mdwn
new file mode 100644
index 0000000000..ce72b10c5d
--- /dev/null
+++ b/doc/forum/btsync_equivalent__63__.mdwn
@@ -0,0 +1,8 @@
+I am using bit torrent sync to sync folders and files between my server, my laptop and my smartphone.
+How similar, or different, is git-annex?
+
+Btsync allows me to sync files with no centralized server, encrypted, with some revision history (but I believe it is basic).
+
+
+
+/glattering
diff --git a/doc/forum/btsync_equivalent__63__/comment_1_6bfdc6f595a8aa8979a7c2a10925812f._comment b/doc/forum/btsync_equivalent__63__/comment_1_6bfdc6f595a8aa8979a7c2a10925812f._comment
new file mode 100644
index 0000000000..dd8b17f1a9
--- /dev/null
+++ b/doc/forum/btsync_equivalent__63__/comment_1_6bfdc6f595a8aa8979a7c2a10925812f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="2001:1928:1:9::1"
+ subject="comment 1"
+ date="2014-01-16T15:55:05Z"
+ content="""
+Maybe [[telehash|devblog/day_97__exciting_telehash_possiblities/]] is the free and open source answer to btsync?
+"""]]
diff --git a/doc/forum/bug-fix_release.mdwn b/doc/forum/bug-fix_release.mdwn
new file mode 100644
index 0000000000..c8faa66d00
--- /dev/null
+++ b/doc/forum/bug-fix_release.mdwn
@@ -0,0 +1,2 @@
+Given that the current git-annex release fails the DataLad test suite (due to [[bugs/annex_init_no_longer_generates_default_description]] ?), I'm a bit wary of making it the default release on conda-forge.  Would it be possible to make a bug-fix release?  Thanks!
+
diff --git a/doc/forum/bug-fix_release/comment_1_c3c23f4c0a8bdea8619479656af63af3._comment b/doc/forum/bug-fix_release/comment_1_c3c23f4c0a8bdea8619479656af63af3._comment
new file mode 100644
index 0000000000..9230f268e0
--- /dev/null
+++ b/doc/forum/bug-fix_release/comment_1_c3c23f4c0a8bdea8619479656af63af3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 1"
+ date="2019-06-20T19:42:35Z"
+ content="""
+> Given that the current git-annex release fails the DataLad test suite (due to annex init no longer generates default description ?)
+
+Yes, that bugs seems to be responsible for the failures.  FWIW the corresponding DataLad issue is <https://github.com/datalad/datalad/issues/3472>.
+"""]]
diff --git a/doc/forum/build_from_source_on_Linux_fails___40__out_of_memory__41__.mdwn b/doc/forum/build_from_source_on_Linux_fails___40__out_of_memory__41__.mdwn
new file mode 100644
index 0000000000..a492bd4c94
--- /dev/null
+++ b/doc/forum/build_from_source_on_Linux_fails___40__out_of_memory__41__.mdwn
@@ -0,0 +1,74 @@
+Hi
+
+When trying to do "make" in Linux x64_64, the process fails with an out-of-memory error. "top" shows that memory consumption reached 16GB during build.
+
+Grateful for any recommendations.
+
+Ciaron
+
+    which: no ikiwiki in <snip>
+    if [ "cabal " = ./Setup ]; then ghc --make Setup; fi
+    cabal  configure
+    Resolving dependencies...
+    [ 1 of 31] Compiling Utility.FileSize ( Utility/FileSize.hs, dist/setup/Utility/FileSize.o )
+    [ 2 of 31] Compiling Utility.PosixFiles ( Utility/PosixFiles.hs, dist/setup/Utility/PosixFiles.o )
+    [ 3 of 31] Compiling Utility.FileSystemEncoding ( Utility/FileSystemEncoding.hs, dist/setup/Utility/FileSystemEncoding.o )
+    [ 4 of 31] Compiling Utility.Applicative ( Utility/Applicative.hs, dist/setup/Utility/Applicative.o )
+    [ 5 of 31] Compiling Utility.Data     ( Utility/Data.hs, dist/setup/Utility/Data.o )
+    [ 6 of 31] Compiling Utility.Monad    ( Utility/Monad.hs, dist/setup/Utility/Monad.o )
+    [ 7 of 31] Compiling Utility.Exception ( Utility/Exception.hs, dist/setup/Utility/Exception.o )
+    [ 8 of 31] Compiling Utility.Misc     ( Utility/Misc.hs, dist/setup/Utility/Misc.o )
+    [ 9 of 31] Compiling Utility.Tmp      ( Utility/Tmp.hs, dist/setup/Utility/Tmp.o )
+    [10 of 31] Compiling Utility.Env      ( Utility/Env.hs, dist/setup/Utility/Env.o )
+    [11 of 31] Compiling Utility.UserInfo ( Utility/UserInfo.hs, dist/setup/Utility/UserInfo.o )
+    [12 of 31] Compiling Utility.Path     ( Utility/Path.hs, dist/setup/Utility/Path.o )
+    [13 of 31] Compiling Utility.OSX      ( Utility/OSX.hs, dist/setup/Utility/OSX.o )
+    [14 of 31] Compiling Utility.Process  ( Utility/Process.hs, dist/setup/Utility/Process.o )
+    [15 of 31] Compiling Utility.SafeCommand ( Utility/SafeCommand.hs, dist/setup/Utility/SafeCommand.o )
+    [16 of 31] Compiling Utility.Directory ( Utility/Directory.hs, dist/setup/Utility/Directory.o )
+    [17 of 31] Compiling Utility.ExternalSHA ( Utility/ExternalSHA.hs, dist/setup/Utility/ExternalSHA.o )
+    [18 of 31] Compiling Utility.Network  ( Utility/Network.hs, dist/setup/Utility/Network.o )
+    [19 of 31] Compiling Utility.PartialPrelude ( Utility/PartialPrelude.hs, dist/setup/Utility/PartialPrelude.o )
+    [20 of 31] Compiling Common           ( Common.hs, dist/setup/Common.o )
+    [21 of 31] Compiling Utility.DottedVersion ( Utility/DottedVersion.hs, dist/setup/Utility/DottedVersion.o )
+    [22 of 31] Compiling Git.Version      ( Git/Version.hs, dist/setup/Git/Version.o )
+    [23 of 31] Compiling Utility.FreeDesktop ( Utility/FreeDesktop.hs, dist/setup/Utility/FreeDesktop.o )
+    [24 of 31] Compiling Config.Files     ( Config/Files.hs, dist/setup/Config/Files.o )
+    [25 of 31] Compiling Assistant.Install.AutoStart ( Assistant/Install/AutoStart.hs, dist/setup/Assistant/Install/AutoStart.o )
+    [26 of 31] Compiling Assistant.Install.Menu ( Assistant/Install/Menu.hs, dist/setup/Assistant/Install/Menu.o )
+    [27 of 31] Compiling Build.Version    ( Build/Version.hs, dist/setup/Build/Version.o )
+    [28 of 31] Compiling Build.TestConfig ( Build/TestConfig.hs, dist/setup/Build/TestConfig.o )
+    [29 of 31] Compiling Build.Configure  ( Build/Configure.hs, dist/setup/Build/Configure.o )
+    [30 of 31] Compiling Build.DesktopFile ( Build/DesktopFile.hs, dist/setup/Build/DesktopFile.o )
+    [31 of 31] Compiling Main             ( dist/setup/setup.hs, dist/setup/Main.o )
+    Linking ./dist/setup/setup ...
+      checking version... 5.20150612-gf176464
+      checking UPGRADE_LOCATION... not available
+      checking git... yes
+      checking git version... 1.7.9
+      checking cp -a... yes
+      checking cp -p... yes
+      checking cp --preserve=timestamps... yes
+      checking cp --reflink=auto... no
+      checking xargs -0... yes
+      checking rsync... yes
+      checking curl... yes
+      checking wget... yes
+      checking wget supports -q --show-progress... no
+      checking bup... no
+      checking nice... yes
+      checking ionice... yes
+      checking nocache... no
+      checking gpg... gpg
+      checking lsof... lsof
+      checking git-remote-gcrypt... not available
+      checking ssh connection caching... no
+      checking sha1... sha1sum
+      checking sha256... sha256sum
+      checking sha512... sha512sum
+      checking sha224... sha224sum
+      checking sha384... sha384sum
+    Configuring git-annex-5.20150528...
+    setup: out of memory (requested 1048576 bytes)
+    make: *** [Build/SysConfig.hs] Error 1
+
diff --git a/doc/forum/build_from_source_on_Linux_fails___40__out_of_memory__41__/comment_1_cd004b531ae384e134e16600b64473e0._comment b/doc/forum/build_from_source_on_Linux_fails___40__out_of_memory__41__/comment_1_cd004b531ae384e134e16600b64473e0._comment
new file mode 100644
index 0000000000..a6445c3e93
--- /dev/null
+++ b/doc/forum/build_from_source_on_Linux_fails___40__out_of_memory__41__/comment_1_cd004b531ae384e134e16600b64473e0._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-06-14T16:48:36Z"
+ content="""
+This is cabal trying to resolve the dependencies and failing to find any
+solution, and trying harder and harder as it leaks memory somewhere.
+
+IIRC newer versions of cabal behave better in these situations, but the
+underlying problem is that there is a problem in your set of installed
+haskell libraries that prevents cabal finding a solution.
+
+cabal configure -v3 will show you the dependency resolver at work, and can be examined
+to find the details. But, the easy solution is probably to use stackage
+which will provide cabal with a canned dependency solution. Just copy
+`standalone/linux/cabal.config` to the top of the source tree and re-run
+cabal configure.
+"""]]
diff --git a/doc/forum/build_questions__58___Flag_HttpClientRestricted.mdwn b/doc/forum/build_questions__58___Flag_HttpClientRestricted.mdwn
new file mode 100644
index 0000000000..6b0fe83014
--- /dev/null
+++ b/doc/forum/build_questions__58___Flag_HttpClientRestricted.mdwn
@@ -0,0 +1,7 @@
+Some questions about building git-annex with `stack`:
+
+* What are the pros/cons of setting the new flags `HttpClientRestricted` and `GitLfs` to `True`/`False`?
+
+* `extra-deps` in [stack.yaml](https://git.joeyh.name/index.cgi/git-annex.git/tree/stack.yaml) specifies specific package versions, some of which are [older than the latest ones](https://hackage.haskell.org/package/http-client) on Hackage.  I find myself needing to [patch](https://github.com/notestaff/git-annex-feedstock/blob/is-update-to-8.20200720.1-new/recipe/0001-enable-magicmime-dbus.patch) some of these `extra-deps` to later ones; these still seem to meet the [git-annex.cabal constraints](https://git.joeyh.name/index.cgi/git-annex.git/tree/git-annex.cabal#n425), but I wanted to check if there's a specific reason the later versions aren't used in the standard `stack.yaml`.
+
+Thanks!
diff --git a/doc/forum/build_questions__58___Flag_HttpClientRestricted/comment_1_67ab203f26e7b446fe96e01ec3706540._comment b/doc/forum/build_questions__58___Flag_HttpClientRestricted/comment_1_67ab203f26e7b446fe96e01ec3706540._comment
new file mode 100644
index 0000000000..cb5d1baf57
--- /dev/null
+++ b/doc/forum/build_questions__58___Flag_HttpClientRestricted/comment_1_67ab203f26e7b446fe96e01ec3706540._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-08-10T17:53:04Z"
+ content="""
+These flags avoid pulling in some new external dependencies, which might
+not be available in a particular set of haskell packages
+or might fail to build (probably not). Since git-annex vendors a copy of
+those libraries, disabling them won't change the result. (But I'm going to
+drop those vendored libraries from it eventually.)
+
+The way the stack.yaml works is it pins every single dependency at a
+particular known-working version. That's the only reason to use it rather
+than cabal. Cabal is generally the easiest way to get a build with all the
+bleeding edge versions.
+
+I update the stack.yaml to more or less current versions periodically.
+(Specifically the versions chosen in a particular LTS release, which can
+be behind bleeding edge in some cases when there's breakage being sorted
+out there.) But my past several tries with newer lts versions have failed
+because the debian packages are too old to use them.
+"""]]
diff --git a/doc/forum/building_from_source__58___dependency_versions.mdwn b/doc/forum/building_from_source__58___dependency_versions.mdwn
new file mode 100644
index 0000000000..aefc199c48
--- /dev/null
+++ b/doc/forum/building_from_source__58___dependency_versions.mdwn
@@ -0,0 +1 @@
+@joeyh, can you check that this [patch](https://github.com/conda-forge/git-annex-feedstock/blob/master/recipe/0001-extra-deps-01.patch) of `stack.yaml` is safe, in particular that git-annex should work ok with the newer versions of `aws and `hslogger`?
diff --git a/doc/forum/building_from_source__58___dependency_versions/comment_1_442b37aa559512eb85695f0a9e3b8197._comment b/doc/forum/building_from_source__58___dependency_versions/comment_1_442b37aa559512eb85695f0a9e3b8197._comment
new file mode 100644
index 0000000000..83c5a4b781
--- /dev/null
+++ b/doc/forum/building_from_source__58___dependency_versions/comment_1_442b37aa559512eb85695f0a9e3b8197._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-08-24T16:30:29Z"
+ content="""
+The patch does not seem available, but as long as stack can build it, its
+fine to put any versions in there.
+
+I've upgraded the stack file today anyhow.
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source.mdwn b/doc/forum/building_the_standalone_distribution_from_source.mdwn
new file mode 100644
index 0000000000..eab4e9829e
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source.mdwn
@@ -0,0 +1,3 @@
+Are the instructions for building the [[standalone|install/Linux_standalone]] distribution officially documented somewhere?  Do I understand correctly that this can't be done from the [tarballs on Hackage](https://hackage.haskell.org/package/git-annex), and requires [[checking out the full source tree|install/fromsource]]?  Can `stack` still be used, or does this only work with `cabal`?
+
+Related thread: [[forum/standalone_tarballs_for_specific_versions]].
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_10_ae23bbd2da15e8ae115b4030994502cc._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_10_ae23bbd2da15e8ae115b4030994502cc._comment
new file mode 100644
index 0000000000..f0318b2368
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_10_ae23bbd2da15e8ae115b4030994502cc._comment
@@ -0,0 +1,98 @@
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="comment 10"
+ date="2020-08-11T22:10:25Z"
+ content="""
+After running the command you request this was the package plan conda came up with:
+
+```
+  added / updated specs:
+    - git-annex[build=alldep*]
+
+
+The following packages will be downloaded:
+
+    package                    |            build
+    ---------------------------|-----------------
+    c-ares-1.16.1              |       h516909a_0         108 KB  conda-forge
+    curl-7.71.1                |       he644dc0_4         139 KB  conda-forge
+    dbus-1.13.6                |       he372182_0         602 KB  conda-forge
+    expat-2.2.9                |       he1b5a44_2         191 KB  conda-forge
+    gettext-0.19.8.1           |    hc5be6a0_1002         3.6 MB  conda-forge
+    git-2.28.0                 |  pl526h5e3e691_1        15.9 MB  conda-forge
+    git-annex-8.20200810       |alldep_h988281c_100        12.2 MB  conda-forge
+    glib-2.65.0                |       h6f030ca_0         3.5 MB  conda-forge
+    gmp-6.2.0                  |       he1b5a44_2         811 KB  conda-forge
+    krb5-1.17.1                |       hfafb76e_2         1.5 MB  conda-forge
+    ld_impl_linux-64-2.34      |       hc38a660_9         612 KB  conda-forge
+    libcurl-7.71.1             |       hcdd3856_4         312 KB  conda-forge
+    libev-4.33                 |       h516909a_0         105 KB  conda-forge
+    libffi-3.2.1               |    he1b5a44_1007          47 KB  conda-forge
+    libiconv-1.15              |    h516909a_1006         2.0 MB  conda-forge
+    libmagic-5.39              |       hed695b0_0         280 KB  conda-forge
+    libnghttp2-1.41.0          |       hab1572f_1         709 KB  conda-forge
+    libssh2-1.9.0              |       hab1572f_5         225 KB  conda-forge
+    lsof-4.89                  |                0          84 KB  conda-forge
+    openssh-8.3p1              |       h5957347_0         1.3 MB  conda-forge
+    pcre-8.44                  |       he1b5a44_0         261 KB  conda-forge
+    perl-5.26.2                |    h516909a_1006        15.4 MB  conda-forge
+    popt-1.16                  |    h299ea2f_2002         184 KB  conda-forge
+    python-3.8.5               |h4d41432_2_cpython        71.0 MB  conda-forge
+    rsync-3.1.3                |    hed695b0_1002         287 KB  conda-forge
+    ------------------------------------------------------------
+                                           Total:       131.4 MB
+
+The following NEW packages will be INSTALLED:
+
+  c-ares             conda-forge/linux-64::c-ares-1.16.1-h516909a_0
+  curl               conda-forge/linux-64::curl-7.71.1-he644dc0_4
+  dbus               conda-forge/linux-64::dbus-1.13.6-he372182_0
+  expat              conda-forge/linux-64::expat-2.2.9-he1b5a44_2
+  gettext            conda-forge/linux-64::gettext-0.19.8.1-hc5be6a0_1002
+  git                conda-forge/linux-64::git-2.28.0-pl526h5e3e691_1
+  git-annex          conda-forge/linux-64::git-annex-8.20200810-alldep_h988281c_100
+  glib               conda-forge/linux-64::glib-2.65.0-h6f030ca_0
+  gmp                conda-forge/linux-64::gmp-6.2.0-he1b5a44_2
+  krb5               conda-forge/linux-64::krb5-1.17.1-hfafb76e_2
+  libcurl            conda-forge/linux-64::libcurl-7.71.1-hcdd3856_4
+  libev              conda-forge/linux-64::libev-4.33-h516909a_0
+  libiconv           conda-forge/linux-64::libiconv-1.15-h516909a_1006
+  libmagic           conda-forge/linux-64::libmagic-5.39-hed695b0_0
+  libnghttp2         conda-forge/linux-64::libnghttp2-1.41.0-hab1572f_1
+  libssh2            conda-forge/linux-64::libssh2-1.9.0-hab1572f_5
+  lsof               conda-forge/linux-64::lsof-4.89-0
+  openssh            conda-forge/linux-64::openssh-8.3p1-h5957347_0
+  pcre               conda-forge/linux-64::pcre-8.44-he1b5a44_0
+  perl               conda-forge/linux-64::perl-5.26.2-h516909a_1006
+  popt               conda-forge/linux-64::popt-1.16-h299ea2f_2002
+  python_abi         conda-forge/linux-64::python_abi-3.8-1_cp38
+  rsync              conda-forge/linux-64::rsync-3.1.3-hed695b0_1002
+
+The following packages will be UPDATED:
+
+  ld_impl_linux-64   pkgs/main::ld_impl_linux-64-2.33.1-h5~ --> conda-forge::ld_impl_linux-64-2.34-hc38a660_9
+  openssl              pkgs/main::openssl-1.1.1g-h7b6447c_0 --> conda-forge::openssl-1.1.1g-h516909a_1
+  python                 pkgs/main::python-3.8.5-hcff3b4d_0 --> conda-forge::python-3.8.5-h4d41432_2_cpython
+
+The following packages will be SUPERSEDED by a higher-priority channel:
+
+  ca-certificates    pkgs/main::ca-certificates-2020.6.24-0 --> conda-forge::ca-certificates-2020.6.20-hecda079_0
+  certifi               pkgs/main::certifi-2020.6.20-py38_0 --> conda-forge::certifi-2020.6.20-py38h32f6830_0
+  libffi                   pkgs/main::libffi-3.3-he6710b0_2 --> conda-forge::libffi-3.2.1-he1b5a44_1007
+```
+
+As a user, there were no noticeable differences.
+
+After running `git annex version` on this env, I noticed I got slightly older dependencies compared to the normal installation (`conda install -c conda-forge git-annex`).
+
+```
+$ diff git-annex git-annex=*=alldep*
+-git-annex version: 8.20200810-g693f2093a
++git-annex version: 8.20200810-g8b113bc
+-dependency versions: cryptonite-0.26 feed-1.3.0.1 ghc-8.8.3 persistent-sqlite-2.10.6.2
++dependency versions: cryptonite-0.25 feed-1.2.0.1 ghc-8.6.5 persistent-sqlite-2.9.3
+```
+
+If the dependencies were as up-to-date as the normal installation, I think I'd actually prefer this method, since it keeps things more contained and independent.
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_11_5c580c8fce388b9808c2afc778da853b._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_11_5c580c8fce388b9808c2afc778da853b._comment
new file mode 100644
index 0000000000..620ab65e18
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_11_5c580c8fce388b9808c2afc778da853b._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="Having cutting edge packages with conda is not that straighforward."
+ date="2020-08-14T18:55:17Z"
+ content="""
+I am always inclined to \"contain\" my dependencies inside separate environments, so I want to do what you recommended and use `git-annex=*=alldep*`. 
+But when I install it, I get outdated versions of really important programs (although only slightly outdated).
+
+```
+perl; 5.26.2; 5.30.0
+git;  2.23.0; 2.28.0
+```
+
+I also got some downgrades of stuff that was already inside the env:
+
+```
+The following packages will be SUPERSEDED by a higher-priority channel:
+
+  ca-certificates    pkgs/main::ca-certificates-2020.6.24-0 --> conda-forge::ca-certificates-2020.6.20-hecda079_0
+  libffi                   pkgs/main::libffi-3.3-he6710b0_2 --> conda-forge::libffi-3.2.1-he1b5a44_1007
+  python                 pkgs/main::python-3.8.5-hcff3b4d_0 --> conda-forge::python-3.8.3-cpython_he5300dc_0
+```
+
+Some googling later and I found this [github/conda-forge/git-annex-feedstock/.ci_support/linux_64_nodepFalse.yaml](https://github.com/conda-forge/git-annex-feedstock/blob/master/.ci_support/linux_64_nodepFalse.yaml), which does have `perl: - 5.26.2` *hard-coded*.
+However I also found the [README](https://github.com/conda-forge/git-annex-feedstock/blob/master/.ci_support/README) saying that file was auto-generated based on this one [feedstock/recipe/meta.yaml](https://github.com/conda-forge/git-annex-feedstock/blob/master/recipe/meta.yaml), which furthers the mystery as this `meta.yaml` does not have any specified version for `perl` and git only has a minimum version (`git >=2.22`).
+So it seems `conda` is grabbing older (than the most recent) versions, because those are the latest it has.
+
+`git 2.28.0` is available on `conda-forge`, though. So I'm using that now. And since `conda-forge` is overall more up-to-date...
+
+## This is how I decided to create my env:
+
+`conda create --name main --channel conda-forge python=3.8 git=2.28 git-annex=*=alldep*`
+
+Still no idea on how to update the *outdated* dependencies I stated on my previous post, though. They (cryptonite, feed, ghc, and persistent-sqlite) aren't even mentioned in the `git-annex-feedstock` repo.
+ 
+
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_12_9b0a7c108855d9db63092dd5f93bc5e5._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_12_9b0a7c108855d9db63092dd5f93bc5e5._comment
new file mode 100644
index 0000000000..f576e20470
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_12_9b0a7c108855d9db63092dd5f93bc5e5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="understanding why standalone conda package gets preferred"
+ date="2020-08-27T15:32:05Z"
+ content="""
+@cardoso-neto \"The only dependency that was installed when I conda-installed git-annex was this\" -- do you by chance remember the exact commands used to create that conda environment, before you tried installing git-annex into it?  (Or if you have the environment, can you do `conda list --explicit` in it?) I'd like to better understand why `conda install` prefers the standalone package [so often](https://anaconda.org/conda-forge/git-annex/files). I'll ask conda gurus, but first need a reproducible case where that happens seemingly unnecessarily.
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_13_27f987a16d931a02f5a4ab3f80bf327a._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_13_27f987a16d931a02f5a4ab3f80bf327a._comment
new file mode 100644
index 0000000000..4a16e6c5ec
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_13_27f987a16d931a02f5a4ab3f80bf327a._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="comment 13"
+ date="2020-08-28T00:20:30Z"
+ content="""
+I checked my .bash_history and it was `conda create -n $myname python=3.8` the command used.
+
+I just reran that and got the same result when I installed git-annex with `conda install -c conda-forge git-annex`.
+
+I also noticed you made the standalone dist warning message much prettier. Thanks for that. However, you forgot the `--channel` argument in your suggested install script. Here is a copypasta of your current message:
+
+```
+Executing transaction: / 
+##############################################################################
+#                                                                            #
+# Standalone distribution of git-annex was installed, instead of the         #
+# standard distribution, likely due to package conflicts in the target       #
+# environment.  The standalone distribution may have issues (e.g. be slower, #
+# or not pass the expected environment to some external programs);           #
+# the standard distribution should be used when possible.                    #
+# You can force installation of the standard version by adding =alldep* to   #
+# the build string, e.g.                                                     #
+# conda install git-annex=*=alldep*                                          #
+#                                                                            #
+# For more info on the standalone git-annex distribution see                 #
+# https://git-annex.branchable.com/install/Linux_standalone/                 #
+#                                                                            #
+##############################################################################
+
+done
+```   
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_14_44606ec8db82f75f37aabcd7df5c24bb._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_14_44606ec8db82f75f37aabcd7df5c24bb._comment
new file mode 100644
index 0000000000..158e70919f
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_14_44606ec8db82f75f37aabcd7df5c24bb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 14"
+ date="2020-08-28T01:02:48Z"
+ content="""
+Thanks for point out the channel omission in the message.
+
+I was able to reproduce the issue, but only with `conda create --override-channels -c defaults -n new-test-env-03 python=3.8 ` .  When I instead create the initial environment with `-c conda-forge`, the issue doesn't recur.  I guess it makes sense: packages in conda-forge are pinned to be more compatible with each other, but not necessarily with packages in `defaults`.
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_1_204eda1dc4b935ee357a6675ee14317b._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_1_204eda1dc4b935ee357a6675ee14317b._comment
new file mode 100644
index 0000000000..b959b89ad4
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_1_204eda1dc4b935ee357a6675ee14317b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-08-10T19:08:20Z"
+ content="""
+I've added some docs to the page about how to build it.
+
+BUILDER=stack will build it with stack.
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_2_ff968f9f9d6644b9e8607c8e76f45c1e._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_2_ff968f9f9d6644b9e8607c8e76f45c1e._comment
new file mode 100644
index 0000000000..0e3b4c835c
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_2_ff968f9f9d6644b9e8607c8e76f45c1e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="full source tarballs for specific releases?"
+ date="2020-08-10T21:14:04Z"
+ content="""
+Thanks a lot!  Do I understand correctly that this can't be done from the [tarballs on Hackage](https://hackage.haskell.org/package/git-annex), and requires [[checking out the full source tree|install/fromsource]]?  (And that there is URL from which the full source repo tarball for a given released version can be downloaded?)
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_3_e94f70e19b77c9ad6b6349fa65dcc60f._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_3_e94f70e19b77c9ad6b6349fa65dcc60f._comment
new file mode 100644
index 0000000000..c35e2e911d
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_3_e94f70e19b77c9ad6b6349fa65dcc60f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2020-08-10T21:52:29Z"
+ content="""
+(I meant, there is _no_ URL from which the full source repo tarball for a given released version can be downloaded?)
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_4_0b7824acaf031d8ba69700674c82f472._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_4_0b7824acaf031d8ba69700674c82f472._comment
new file mode 100644
index 0000000000..c1eb86db84
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_4_0b7824acaf031d8ba69700674c82f472._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-08-10T22:43:19Z"
+ content="""
+Right, the hackage tarball is only useful for cabal, it would not be
+practical to include everything else in it. Arguably there's small enough
+value in publishing it there that I ought to just drop it.
+
+I don't release other tarballs, but it is possible to get a stable tarball
+from git, eg 
+<https://git.joeyh.name/index.cgi/git-annex.git/snapshot/git-annex-8.20200720.1.tar.gz>
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_5_bfec6091cc312a9d4c87163b845454f6._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_5_bfec6091cc312a9d4c87163b845454f6._comment
new file mode 100644
index 0000000000..d93cf5b8f0
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_5_bfec6091cc312a9d4c87163b845454f6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="please keep the hackage tarballs"
+ date="2020-08-11T00:43:46Z"
+ content="""
+\" Arguably there's small enough value in publishing it there that I ought to just drop it\" -- the [conda-forge recipe](https://github.com/conda-forge/git-annex-feedstock/blob/master/recipe/meta.yaml#L48) is based on the hackage tarballs, as is the [homebrew formula](https://github.com/Homebrew/homebrew-core/blob/master/Formula/git-annex.rb#L4).
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_6_044da90b6cc18534de74ee5d38d6becb._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_6_044da90b6cc18534de74ee5d38d6becb._comment
new file mode 100644
index 0000000000..1ee8c4a61e
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_6_044da90b6cc18534de74ee5d38d6becb._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="Great tip about conda."
+ date="2020-08-11T13:22:58Z"
+ content="""
+I had no idea git-annex was on a conda channel even though it is clearly stated on the [install page](https://git-annex.branchable.com/install/).
+
+I just installed it with `conda install git-annex -c conda-forge` and, to my amazement, instead of `v8.20200226` (which was available on my focal fossa standard apt repos) being installed, `v8.20200810-g693f2093a` was installed.
+
+It was so easy to install and it is a version that was built just yesterday. I loved it.
+
+Please keep the plumbing that made this possible alive. 
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_7_5187f5f40bc47b5b079cfdd3eb5f1fc3._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_7_5187f5f40bc47b5b079cfdd3eb5f1fc3._comment
new file mode 100644
index 0000000000..1e9d121e37
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_7_5187f5f40bc47b5b079cfdd3eb5f1fc3._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="checking the conda-forge recipe"
+ date="2020-08-11T15:51:27Z"
+ content="""
+@cardoso-neto \"v8.20200810-g693f2093a was installed\" -- for the purpose of checking that the conda-forge installation worked correctly, can you tell me which exact package got installed, i.e. what is output by running
+
+`conda list --explicit | grep git-annex`
+
+?
+Thanks!
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_8_eb0c565043164c17b2a6d2c6361b6e35._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_8_eb0c565043164c17b2a6d2c6361b6e35._comment
new file mode 100644
index 0000000000..c8c957fcd9
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_8_eb0c565043164c17b2a6d2c6361b6e35._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="comment 8"
+ date="2020-08-11T19:57:03Z"
+ content="""
+This was the tarball conda used:
+
+`https://conda.anaconda.org/conda-forge/linux-64/git-annex-8.20200810-nodep_h1234567_0.tar.bz2`
+
+I noticed you updated the (/install/conda)[https://git-annex.branchable.com/install/conda/] with possible package conflict tips.
+
+The only dependency that was installed when I conda-installed git-annex was this:
+
+`python_abi conda-forge/linux-64::python_abi-3.8-1_cp38`
+
+Which struck me as odd, because I'm running python 3.8.5, not 3.8.1.
+Maybe they just have perfectly compatible ABIs, or maybe it's related to the problem you mentioned.
+I don't know.
+
+If there's any other test you want me to run, no problem.
+"""]]
diff --git a/doc/forum/building_the_standalone_distribution_from_source/comment_9_edb3a79772f81dd3ffd00b81e79f67e5._comment b/doc/forum/building_the_standalone_distribution_from_source/comment_9_edb3a79772f81dd3ffd00b81e79f67e5._comment
new file mode 100644
index 0000000000..51d916208a
--- /dev/null
+++ b/doc/forum/building_the_standalone_distribution_from_source/comment_9_edb3a79772f81dd3ffd00b81e79f67e5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="strange conda install behavior"
+ date="2020-08-11T20:19:46Z"
+ content="""
+What happens if you request the installation of the standard package with
+
+`conda install -c conda-forge git-annex=*=alldep*`
+
+?
+
+"""]]
diff --git a/doc/forum/bup_backups_to_amazon_cloud_drive.mdwn b/doc/forum/bup_backups_to_amazon_cloud_drive.mdwn
new file mode 100644
index 0000000000..04b0b6fe9b
--- /dev/null
+++ b/doc/forum/bup_backups_to_amazon_cloud_drive.mdwn
@@ -0,0 +1,12 @@
+I have the following setup:
+
+1. Removable hard drive (truecrypt)
+2. Removable hard drive (truecrypt)
+3. Amazon Cloud drive
+
+I usually use bup to make backups to (1) and (2) but now I would like to add (3). I would like to take advantage of git annex to sync/pull my backups easily, however git-annex doesn't like git inside git for some reason. Git annex give me the following features:
+
+1. Encryption using gnupg
+2. Pulling a backup is easy from remote then I run bup on the pulled backup.
+
+Any suggestion on how to accomplish this?
diff --git a/doc/forum/bup_backups_to_amazon_cloud_drive/comment_1_e8f6fdc70cedd5482da6a185c6c6b9b9._comment b/doc/forum/bup_backups_to_amazon_cloud_drive/comment_1_e8f6fdc70cedd5482da6a185c6c6b9b9._comment
new file mode 100644
index 0000000000..bd782a0e49
--- /dev/null
+++ b/doc/forum/bup_backups_to_amazon_cloud_drive/comment_1_e8f6fdc70cedd5482da6a185c6c6b9b9._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Tafnzart"
+ subject="comment 1"
+ date="2016-10-08T16:43:54Z"
+ content="""
+Please ignore the previous message. I found my way. Actually I was confused by git annex list thinking it lists remotes, while it does list files too. So I was able to have a directory called dot-bup inside annex without problem. Thank you for great tool!
+"""]]
diff --git a/doc/forum/cabal_install_fails_on_uuid.mdwn b/doc/forum/cabal_install_fails_on_uuid.mdwn
new file mode 100644
index 0000000000..606f7954dc
--- /dev/null
+++ b/doc/forum/cabal_install_fails_on_uuid.mdwn
@@ -0,0 +1,23 @@
+Hey, so I am trying to compile git-annex through cabal but it fails on building uuid. It gives me this strange error:
+
+    Resolving dependencies...
+    Configuring uuid-1.3.1...
+    Building uuid-1.3.1...
+    Preprocessing library uuid-1.3.1...
+    [ 1 of 10] Compiling Data.UUID.Builder ( Data/UUID/Builder.hs, dist/build/Data/UUID/Builder.o )
+    [ 2 of 10] Compiling Data.Word.Util   ( Data/Word/Util.hs, dist/build/Data/Word/Util.o )
+    [ 3 of 10] Compiling Data.UUID.Internal ( Data/UUID/Internal.hs, dist/build/Data/UUID/Internal.o )
+    Data/UUID/Internal.hs:394:20: Not in scope: `BL.fromStrict'
+    Data/UUID/Internal.hs:399:48: Not in scope: `BL.toStrict'
+    cabal: Error: some packages failed to install:
+    git-annex-4.20131002 depends on uuid-1.3.1 which failed to install.
+    uuid-1.3.1 failed during the building phase. The exception was:
+    ExitFailure 1
+
+Any advice on how to proceed?
+
+System is: Debian Wheezy (CrunchBang Waldorf) 64bit
+
+versions are:
+    uuid-dev: 2.20.1-5.3
+    cabal: 1.14.0
diff --git a/doc/forum/cabal_install_fails_on_uuid/comment_1_2a3963e21bc7ff526124b902cb0b6ad2._comment b/doc/forum/cabal_install_fails_on_uuid/comment_1_2a3963e21bc7ff526124b902cb0b6ad2._comment
new file mode 100644
index 0000000000..47fe7e5ff8
--- /dev/null
+++ b/doc/forum/cabal_install_fails_on_uuid/comment_1_2a3963e21bc7ff526124b902cb0b6ad2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 1"
+ date="2013-10-22T17:52:10Z"
+ content="""
+That version of the haskell uuid library installs ok on my Debian sid system. Seems to me you have a too old version of the haskell bytestring library, which added `fromStrict` in version 0.10.0.0. Probably `cabal install bytestring` will fix it up for you, but building git-annex from source using cabal is a complicated thing that can go wrong in many ways. Have you considered one of the prebuilt binaries?
+"""]]
diff --git a/doc/forum/cabal_install_fails_on_uuid/comment_2_1609525998e2b36c04d67f4d988139c0._comment b/doc/forum/cabal_install_fails_on_uuid/comment_2_1609525998e2b36c04d67f4d988139c0._comment
new file mode 100644
index 0000000000..0f308df0b4
--- /dev/null
+++ b/doc/forum/cabal_install_fails_on_uuid/comment_2_1609525998e2b36c04d67f4d988139c0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkj7tMEJKcZpNXIFkHAAcNi5qJFSFyjn6o"
+ nickname="thissideup"
+ subject="comment 2"
+ date="2013-10-23T11:15:20Z"
+ content="""
+I contacted the maintainer of the uuid-package and he fixed the issue in the current release, so everythings fine now. and: everything compiled beautifully. 
+
+But to answer your question: I tend to rather compile things myself if I don't find them (or a current enough version) in the repos - but that's purely personal. ;)
+"""]]
diff --git a/doc/forum/can_I_only_add_my_own_files__63__.mdwn b/doc/forum/can_I_only_add_my_own_files__63__.mdwn
new file mode 100644
index 0000000000..5554295824
--- /dev/null
+++ b/doc/forum/can_I_only_add_my_own_files__63__.mdwn
@@ -0,0 +1,27 @@
+Hi,
+
+[ sorry for the wrong bugreport in the last version of this entry ]
+
+It seems as if I can only add my own file to the annex, even if I have group write permissions.  Is that correct?  Can that be circumvented other than copying/deleting the large file?
+
+Here is some demonstration:
+
+    > git init
+    > git config user.name dtr
+    > git config user.email dtrn@dtrn.com
+    
+    > dd if/dev/zero of=test2.bin count=1000
+    
+    > ll
+    -rw-rw-r-- 1 dtr dtr 512000 Sep 16  2013 test2.bin
+    
+    > sudo chown someone test2.bin
+    > ll
+    -rw-rw-r-- 1 someone dtr 512000 Sep 16  2013 test2.bin
+    
+    > git annex init
+    > git annex add test2.bin
+    add test2.bin (checksum...) 
+    git-annex: /test-git-annex/.git/annex/objects/Fq/f6/SHA256-s512000--2d4da04b861bb9dbe77c871415931785a18138d6db035f1bbcd0cf8277c6fc23/SHA256-s512000--2d4da04b861bb9dbe77c871415931785a18138d6db035f1bbcd0cf8277c6fc23: setFileMode: permission denied (Operation not permitted)
+    failed
+    git-annex: add: 1 failed
diff --git a/doc/forum/can_I_only_add_my_own_files__63__/comment_1_767d647af9d0345f337338d6319071fa._comment b/doc/forum/can_I_only_add_my_own_files__63__/comment_1_767d647af9d0345f337338d6319071fa._comment
new file mode 100644
index 0000000000..80efaf04bd
--- /dev/null
+++ b/doc/forum/can_I_only_add_my_own_files__63__/comment_1_767d647af9d0345f337338d6319071fa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.220"
+ subject="comment 1"
+ date="2013-09-25T18:42:00Z"
+ content="""
+git-annex needs to be able to lock down files to ensure that nobody can write to them, and to do this it needs to remove the write bit, and you can't remove the write bit from a file you don't own.
+
+Note that if you configure git's core.sharedRepository when making a repository (git init --shared), then all files in both git and git-annex will be group writable. Put you and the other person you wanted to be able to write to the file in a group, and you can both access the repository. So that's the right way to do it.
+"""]]
diff --git a/doc/forum/can_I_only_add_my_own_files__63__/comment_2_0c3306ffb38b97b54e1e0436d12c1876._comment b/doc/forum/can_I_only_add_my_own_files__63__/comment_2_0c3306ffb38b97b54e1e0436d12c1876._comment
new file mode 100644
index 0000000000..5a63a71760
--- /dev/null
+++ b/doc/forum/can_I_only_add_my_own_files__63__/comment_2_0c3306ffb38b97b54e1e0436d12c1876._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ringprince"
+ ip="134.76.140.110"
+ subject="comment 2"
+ date="2013-09-26T06:32:48Z"
+ content="""
+Thanks a lot.  The solution with --shared was really helpful.
+"""]]
diff --git a/doc/forum/can__39__t_sync_content.mdwn b/doc/forum/can__39__t_sync_content.mdwn
new file mode 100644
index 0000000000..9e7a4cc49d
--- /dev/null
+++ b/doc/forum/can__39__t_sync_content.mdwn
@@ -0,0 +1,35 @@
+Hi,
+
+I'm completely new to git-annex, I'm trying to follow this guide:
+
+https://git-annex.branchable.com/tips/centralized_git_repository_tutorial/on_GitLab/
+
+All steps succeeded except the `git annex sync --content` which results in the following message:
+
+'Remote origin not usable by git-annex; setting annex-ignore'
+
+Here is an example of the output I receive:
+
+    $ git status
+    On branch master
+    Your branch is up-to-date with 'origin/master'.
+    nothing to commit, working directory clean
+    $
+    $ git push origin master git-annex
+    Everything up-to-date
+    $
+    $ git annex sync --content
+    
+      Remote origin not usable by git-annex; setting annex-ignore
+    commit  ok
+    pull origin
+    ok
+    pull origin
+    ok
+    $
+    $ git config remote.origin.url
+    https://user:pass@gitlab.com/user/repname.git
+
+Is it required to use the ssh protocol in order to get annex working?
+
+I'm using https since I'm behind a firewall, and the ssh protocol always time out. Is there anything I can do?
diff --git a/doc/forum/can__39__t_sync_content/comment_1_0d6c6f5967c91e7dda55fbf716dd88a0._comment b/doc/forum/can__39__t_sync_content/comment_1_0d6c6f5967c91e7dda55fbf716dd88a0._comment
new file mode 100644
index 0000000000..c851e51f58
--- /dev/null
+++ b/doc/forum/can__39__t_sync_content/comment_1_0d6c6f5967c91e7dda55fbf716dd88a0._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-05T14:04:39Z"
+ content="""
+It's possible to set up a http repo such that git-annex can use it, but
+gitlab's http repos are not set up this way. It might be worth asking them
+to do it. [[tips/setup_a_public_repository_on_a_web_site]] explains
+one way to set up a http repo for git-annex.
+
+But, even when git-annex is able to use a http repo, it can only
+download files from it. There's no support for uploading git-annex managed
+files to a remote http repo. This would need additional server-side support
+of some kind.
+"""]]
diff --git a/doc/forum/can__39__t_sync_content/comment_2_e9c476eeac7427950573c07313a8a175._comment b/doc/forum/can__39__t_sync_content/comment_2_e9c476eeac7427950573c07313a8a175._comment
new file mode 100644
index 0000000000..9b9d7a439d
--- /dev/null
+++ b/doc/forum/can__39__t_sync_content/comment_2_e9c476eeac7427950573c07313a8a175._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="dberebi@ca13ee3cf0ff9c61fdfea562ebf725e0b6dc40ef"
+ nickname="dberebi"
+ subject="comment 2"
+ date="2015-08-06T01:51:03Z"
+ content="""
+It doesn't solve my problem but at least now I know there is no way to do that behind such a firewall.
+
+Thanks for your reply!
+"""]]
diff --git a/doc/forum/can_git-annex_replace_ddm__63__.mdwn b/doc/forum/can_git-annex_replace_ddm__63__.mdwn
new file mode 100644
index 0000000000..8d49652c3d
--- /dev/null
+++ b/doc/forum/can_git-annex_replace_ddm__63__.mdwn
@@ -0,0 +1,13 @@
+Hi,
+a few years ago I wrote a tool called 'ddm'.  The code is overengineered and the script is more complicated then it should be,
+but I think it demonstrates some good use cases, and I wonder how well git-annex can fulfill the requirements for those use cases - maybe I should remove ddm and start hacking with git-annex instead.
+
+To answer this question, you should read the section about the possible dataset types on http://dieter.plaetinck.be/ddm_a_distributed_data_manager.html, and the example at the bottom of that page. it demonstrates the idea behind the "selection" dataset to always try to keep a subset (the most appropriate, based on the output of some script) of files "checked out".
+the introduction section on https://github.com/Dieterbe/ddm/raw/358f7cf92c0ba7b336dc97638351d4e324461afa/MANUAL should further clarify things, as well as give some more good use cases (as you can see it's a bit more about [semi-]automated workflows then purely tracking what's where)
+
+So I'm not sure, maybe the way to go for me is to make git-annex my "housekeeping about which data is where" backend and make ddm into a set of policies and tools on top of git-annex.
+
+Any input?
+
+Thanks,
+Dieter
diff --git a/doc/forum/can_git-annex_replace_ddm__63__/comment_1_aa05008dfe800474ff76678a400099e1._comment b/doc/forum/can_git-annex_replace_ddm__63__/comment_1_aa05008dfe800474ff76678a400099e1._comment
new file mode 100644
index 0000000000..eb824971f6
--- /dev/null
+++ b/doc/forum/can_git-annex_replace_ddm__63__/comment_1_aa05008dfe800474ff76678a400099e1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-02-14T22:08:54Z"
+ content="""
+Yes, there is value in layering something over git-annex to use a policy to choose what goes where.
+
+I use [mr](http://kitenet.net/~joey/code/mr/) to update and manage all my repositories, and since mr can be made to run arbitrary commands when doing eg, an update, I use its config file as such a policy layer. For example, my podcasts are pulled into my sound repository in a subdirectory; boxes that consume podcasts run \"git pull; git annex get podcasts --exclude=\"*/out/*\"; git annex drop podcasts/*/out\". I move podcasts to \"out\" directories once done with them (I have yet to teach mpd to do that for me..), and the next time I run \"mr update\" to update everything, it pulls down new ones and removes old ones.
+
+I don't see any obstacle to doing what you want. May be that you'd need better querying facilities in git-annex (so the policy layer can know what is available where), or finer control (--exclude is a good enough hammer for me, but maybe not for you).
+"""]]
diff --git a/doc/forum/can_git-annex_replace_ddm__63__/comment_2_008554306dd082d7f543baf283510e92._comment b/doc/forum/can_git-annex_replace_ddm__63__/comment_2_008554306dd082d7f543baf283510e92._comment
new file mode 100644
index 0000000000..ab114bb1c8
--- /dev/null
+++ b/doc/forum/can_git-annex_replace_ddm__63__/comment_2_008554306dd082d7f543baf283510e92._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://dieter-be.myopenid.com/"
+ nickname="dieter"
+ subject="comment 2"
+ date="2011-02-16T21:32:04Z"
+ content="""
+thanks Joey,
+
+is it possible to run some git annex command that tells me, for a specific directory, which files are available in an other remote? (and which remote, and which filenames?)
+I guess I could run that, do my own policy thingie, and run `git annex get` for the files I want.
+
+For your podcast use case (and some of my use cases) don't you think git [annex] might actually be overkill?  For example your podcasts use case, what value does git annex give over a simple rsync/rm script?
+such a script wouldn't even need a data store to store its state, unlike git. it seems simpler and cleaner to me.
+
+for the mpd thing, check http://alip.github.com/mpdcron/ (bad project name, it's a plugin based \"event handler\")
+you should be able to write a simple plugin for mpdcron that does what you want (or even interface with mpd yourself from perl/python/.. to use its idle mode to get events)
+
+Dieter
+"""]]
diff --git a/doc/forum/can_git-annex_replace_ddm__63__/comment_3_4c69097fe2ee81359655e59a03a9bb8d._comment b/doc/forum/can_git-annex_replace_ddm__63__/comment_3_4c69097fe2ee81359655e59a03a9bb8d._comment
new file mode 100644
index 0000000000..5cdd6aa0c6
--- /dev/null
+++ b/doc/forum/can_git-annex_replace_ddm__63__/comment_3_4c69097fe2ee81359655e59a03a9bb8d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-03-16T03:01:17Z"
+ content="""
+Whups, the comment above got stuck in moderation queue for 27 days. I will try to check that more frequently.
+
+In the meantime, I've implemented \"git annex whereis\" -- enjoy!
+
+I find keeping my podcasts in the annex useful because it allows me to download individual episodes or poscasts easily when low bandwidth is available (ie, dialup), or over sneakernet. And generally keeps everything organised.
+"""]]
diff --git a/doc/forum/canceling_wrong_repository_merge.mdwn b/doc/forum/canceling_wrong_repository_merge.mdwn
new file mode 100644
index 0000000000..e2d7009c0f
--- /dev/null
+++ b/doc/forum/canceling_wrong_repository_merge.mdwn
@@ -0,0 +1,3 @@
+so i mistakenly merged two unrelated repos together. i have "canceled" the merge as in reverted it by removing the created files, but then those zillion of small files will stick around the git repository forever.
+
+is there a way to use something like `git annex forget` for this? i know about things like [git rebase --onto](https://sethrobertson.github.io/GitFixUm/fixup.html#remove_deep) but that won't propagate across all repositories... can git-annex give me a hand here? --[[anarcat]]
diff --git a/doc/forum/canceling_wrong_repository_merge/comment_1_7230f2be014afcb40514ef521d53c170._comment b/doc/forum/canceling_wrong_repository_merge/comment_1_7230f2be014afcb40514ef521d53c170._comment
new file mode 100644
index 0000000000..4f82b38e67
--- /dev/null
+++ b/doc/forum/canceling_wrong_repository_merge/comment_1_7230f2be014afcb40514ef521d53c170._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 1"
+ date="2015-02-11T15:05:32Z"
+ content="""
+it turns out that using [this procedure](https://sethrobertson.github.io/GitFixUm/fixup.html#remove_deep) worked for me. i just had to reproduce it on all remotes.
+"""]]
diff --git a/doc/forum/canceling_wrong_repository_merge/comment_2_87aabff41a1c6aec773b8f52ead51105._comment b/doc/forum/canceling_wrong_repository_merge/comment_2_87aabff41a1c6aec773b8f52ead51105._comment
new file mode 100644
index 0000000000..83d5c4834a
--- /dev/null
+++ b/doc/forum/canceling_wrong_repository_merge/comment_2_87aabff41a1c6aec773b8f52ead51105._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="watch out for direct mode"
+ date="2015-02-16T23:22:19Z"
+ content="""
+so while `git rebase` can do magic, it will not work out of the box on direct mode repositories, unless you use `-c core.bare=false`, in which case you will totally shoot yourself in the foot because git will happily remove all those real files sitting in the checkout. you will need to `git annex indirect` before you do any of that magic. working on a clone of the git repo is also a good idea, if only for testing.
+
+i personnally destroyed my whole music collection doing such a cleanup of the history. fortunately, i had a recent archived clone of the repo, so things weren't so bad.
+
+but watch out for direct mode, as always.
+"""]]
diff --git a/doc/forum/canceling_wrong_repository_merge/comment_3_d6e45d7e4f4bdf0a08ab91a08e0c1be6._comment b/doc/forum/canceling_wrong_repository_merge/comment_3_d6e45d7e4f4bdf0a08ab91a08e0c1be6._comment
new file mode 100644
index 0000000000..1fbec86033
--- /dev/null
+++ b/doc/forum/canceling_wrong_repository_merge/comment_3_d6e45d7e4f4bdf0a08ab91a08e0c1be6._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="the actual process i use"
+ date="2015-02-17T00:58:38Z"
+ content="""
+So it seems i am able to forget all of this within the matter of a few days, and since this is so error prone, here goes a more detailed explanation.
+
+What I do is:
+
+<pre>
+git clone repo repo.test
+cd repo.test
+git annex indirect # be safe! this may take a while, but it's necessary!
+git tag bak # keep track of a good working state
+git log --stat --stat-count=3 # find the commits we want to trash
+git tag firstbad badbeef1 # the first commit we want to kill
+git tag keep dada1234 # the first commit we want to keep
+git rebase -p --onto firstbad^ keep # drop everything between firstbad (inclusive) and keep (exclusive)
+git diff --stat keep # make sure this did what we expected
+git branch -D annex/direct/master synced/master # destroy this old branch that still has refs to the old commits
+</pre>
+
+Then for each repo:
+
+<pre>
+cd repo
+git tag bak
+git fetch origin # sync the master branch in
+git remote prune origin # make sure the dropped branches are gone
+git annex indirect # be safe
+git reset --hard origin/master
+git branch -D synced/master annex/direct/master
+git diff --stat bak # should change
+</pre>
+
+It would be useful to have that transition propagate properly everywhere so I don't have to do this in every repo, but at least the above should work fairly reliably.
+"""]]
diff --git a/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX.mdwn b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX.mdwn
new file mode 100644
index 0000000000..59ca2e9fc7
--- /dev/null
+++ b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX.mdwn
@@ -0,0 +1,18 @@
+I have a remote rsync with gpg encryption and can restore without problems on my thinkpad (FreeBSD) - but not on my MacOSX:
+
+$ git annex whereis DSC_7615.JPG
+whereis DSC_7615.JPG (2 copies) 
+  	6855de17-c8fb-11e1-9948-f0def1c18073 -- thinkpad
+   	e388bcf6-c8fc-11e1-a96f-6ffcbceb4af4 -- backup (rsync xxxx)
+ok
+
+$ git annex get --from backup DSC_7615.JPG
+fatal: Could not switch to '../../../.git/annex/objects/Pw/XP/SHA256-s1028494--SHA256': No such file or directory
+
+git-annex: <file descriptor: 6>: hGetLine: end of file
+failed
+git-annex: get: 1 failed
+
+$ git annex version
+git-annex version: 3.20120629
+local repository version: 3
diff --git a/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_1_21f0101447623f5a0cf9e72c3ff463bb._comment b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_1_21f0101447623f5a0cf9e72c3ff463bb._comment
new file mode 100644
index 0000000000..c6c962c403
--- /dev/null
+++ b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_1_21f0101447623f5a0cf9e72c3ff463bb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2012-08-07T13:11:48Z"
+ content="""
+Do the remotes in `.git/config` look the same?
+"""]]
diff --git a/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_2_6234ca64bd03a0e15efbe8f5c204338a._comment b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_2_6234ca64bd03a0e15efbe8f5c204338a._comment
new file mode 100644
index 0000000000..5ae18235b8
--- /dev/null
+++ b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_2_6234ca64bd03a0e15efbe8f5c204338a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="hannes"
+ ip="130.226.133.37"
+ subject="they do"
+ date="2012-08-07T14:06:55Z"
+ content="""
+I was also able to copy from the macosx to the rsync backup...
+"""]]
diff --git a/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_3_5ac2b520a907e232984eb513ce088054._comment b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_3_5ac2b520a907e232984eb513ce088054._comment
new file mode 100644
index 0000000000..d80a01a0b2
--- /dev/null
+++ b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_3_5ac2b520a907e232984eb513ce088054._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="hannes"
+ ip="130.226.133.37"
+ subject="also, fsck works"
+ date="2012-08-07T14:12:20Z"
+ content="""
+git annex fsck -fbackup some-local-and-remote-file works fine.
+"""]]
diff --git a/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_4_183dd1c29f66539193e7c0b73f329430._comment b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_4_183dd1c29f66539193e7c0b73f329430._comment
new file mode 100644
index 0000000000..6ab9ebb259
--- /dev/null
+++ b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_4_183dd1c29f66539193e7c0b73f329430._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 4"
+ date="2012-08-07T17:53:35Z"
+ content="""
+I recently encountered this problem on OSX, and I'm pretty sure I fixed it. But I don't remember the details of how. I'm sorry I don't have more detail, but I recommend trying a newer version of git-annex. 
+
+And if the problem persists, --debug will show the git commands and should help identify the one that's being passed bad parameters.
+"""]]
diff --git a/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_5_c920d04ffe332caed9d223fa0ac42746._comment b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_5_c920d04ffe332caed9d223fa0ac42746._comment
new file mode 100644
index 0000000000..32420ac661
--- /dev/null
+++ b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_5_c920d04ffe332caed9d223fa0ac42746._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="remember now"
+ date="2012-08-07T19:37:22Z"
+ content="""
+This was a bug in determining the git version at compile time. Fixed in commit bafc50e05e098234d2d22886085d9844fc763e0e which was included in version 3.20120721.
+"""]]
diff --git a/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_6_7a3cf0853a8ec7b996e19b5e80145d21._comment b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_6_7a3cf0853a8ec7b996e19b5e80145d21._comment
new file mode 100644
index 0000000000..9ffb376a71
--- /dev/null
+++ b/doc/forum/cannot_fetch_from___40__gpg-encrypted__41___rsync_remote_on_MacOSX/comment_6_7a3cf0853a8ec7b996e19b5e80145d21._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="hannes"
+ ip="130.226.133.37"
+ subject="awesome, thanks"
+ date="2012-08-08T12:25:19Z"
+ content="""
+works with an updated git-annex!
+"""]]
diff --git a/doc/forum/cannot_sync___39__unused__39___files.mdwn b/doc/forum/cannot_sync___39__unused__39___files.mdwn
new file mode 100644
index 0000000000..cf9ca1d2a2
--- /dev/null
+++ b/doc/forum/cannot_sync___39__unused__39___files.mdwn
@@ -0,0 +1,45 @@
+Hi,
+
+I have setup a remote git-annex repository (ssh into some machine in our local network) which I will call "common_repo".  Multiple contributors will then be cloning this repo into their laptops (I will call "client_repos").
+
+When these client_repos change and do a "git annex sync <common_repo> --content", all the files from their laptops are successfully synchronised.  The problem arises when:
+
+<ol>
+  <li>CLIENT_A creates somefile.csv</li>
+  <li>CLIENT_A commits somefile.csv
+    <br/>i.e.:
+    <br/>&nbsp;&nbsp;&nbsp;&nbsp;git annex add somefile.csv
+    <br/>&nbsp;&nbsp;&nbsp;&nbsp;git commit -a -m "uploaded somefile.csv"
+  </li>
+  <li>CLIENT_A modifies somefile.csv</li>
+  <li> CLIENT_A commits modified somefile.csv
+     <br/>i.e.:
+     <br/>&nbsp;&nbsp;&nbsp;&nbsp;git add somefile.csv
+     <br/>&nbsp;&nbsp;&nbsp;&nbsp;git commit -a -m "updated somefile.csv"
+  </li>
+  <li>CLIENT_A synchronises with common_repo
+     <br/>i.e.: git annex sync <common_repo> --content
+  </li>
+</ol>
+
+If I check the .git/annex/objects of common_repo, I can't seem to find a copy of the unmodified somefile.csv.  It only has a copy of the latest somefile.csv.
+
+This is problematic if one client tries to checkout a revision of the project that uses the original somefile.csv.
+
+I learned that I can change the preferred content of git-annex.  So, the appropriate preset for common_repo seemed to be "backup".  After running the commands in common_repo:
+<blockquote>
+git annex wanted . standard<br/>
+git annex group . backup
+</blockquote>
+
+I've done another test of the scenario above, and common_repo is still missing the previous revision of the file!!  The preferred file content of common_repo should be "include=* or unused".  In my case, the previous version of somefile.csv will probably fall in the "unused" category.  But I still cannot find it.
+
+A workaround is using two commands from the client(s):
+<blockquote>
+git annex copy --to <common_repo> --all<br/>
+git annex sync <common_repo> --content
+</blockquote>
+
+But I can imagine my users forgetting to run 'copy' and my repo will go to shit over time.
+
+Any ideas why I can't synchronise 'unused' files?
diff --git a/doc/forum/cannot_sync___39__unused__39___files/comment_1_d7c88a5cdf8ce8206795ff7ab215d372._comment b/doc/forum/cannot_sync___39__unused__39___files/comment_1_d7c88a5cdf8ce8206795ff7ab215d372._comment
new file mode 100644
index 0000000000..51fc740cf0
--- /dev/null
+++ b/doc/forum/cannot_sync___39__unused__39___files/comment_1_d7c88a5cdf8ce8206795ff7ab215d372._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-06-15T17:56:45Z"
+ content="""
+The reason is that `git annex sync --content` only syncs files in the
+current work tree.
+<http://git-annex.branchable.com/todo/wishlist:_--all_option_for_sync/>
+"""]]
diff --git a/doc/forum/central_non-bare_and_git_push.mdwn b/doc/forum/central_non-bare_and_git_push.mdwn
new file mode 100644
index 0000000000..ecc81096ed
--- /dev/null
+++ b/doc/forum/central_non-bare_and_git_push.mdwn
@@ -0,0 +1,9 @@
+hi,
+
+i have a usecase that i think many people have. a cental server which should be non-bare to be able to browse the files also via webdav.
+multiple clients behind nat so only pushes via xmpp are possible.
+
+i set everything up without xmpp, it works but if files are updated, none of the clients gets a git push of course because ssh works only unidirectional.
+i couldnt figure out how to set up xmpp push and have a non-bare central repo at the same time because i have to choose between ssh and xmpp git remote on the clients to the server.
+
+thanks!
diff --git a/doc/forum/central_non-bare_and_git_push/comment_1_76d0c73c8985e860eb86333c63be6340._comment b/doc/forum/central_non-bare_and_git_push/comment_1_76d0c73c8985e860eb86333c63be6340._comment
new file mode 100644
index 0000000000..6bf3d1a5e7
--- /dev/null
+++ b/doc/forum/central_non-bare_and_git_push/comment_1_76d0c73c8985e860eb86333c63be6340._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 1"
+ date="2013-07-25T17:05:00Z"
+ content="""
+Simply set up xmpp on your clients in addition to the central repository you have now. When one client pushes over ssh to the central repo, it will use XMPP to inform other clients of the change.
+"""]]
diff --git a/doc/forum/checkout_view_to_directory_outside_of_annex.mdwn b/doc/forum/checkout_view_to_directory_outside_of_annex.mdwn
new file mode 100644
index 0000000000..5a198b64ea
--- /dev/null
+++ b/doc/forum/checkout_view_to_directory_outside_of_annex.mdwn
@@ -0,0 +1,23 @@
+i am working on a project where i need to copy many subsets of files stored in a single annex repo to separate folders outside of the annex repo (each subset to a separate folder).
+
+to select each subset, i'm using `git annex metadata --set <tag>=<value> <path>`.
+
+what i would like to do, ideally, is to leverage each `git annex view <tag>=<value>` invocation to directly check out the view's files to a specific directory outside of the annex repo.
+
+the use case is basically the "Copying objects" strategy of the [syncthing special remote discussion](http://git-annex.branchable.com/todo/syncthing_special_remote/), although rather than having the 'directory' special remote contain files in that remote's specific layout, i would like them to be checked out simply with their original file names.
+
+say i have these files in my main annex repo:
+
+    a.pdf (metadata: topic=haskell)
+    b.pdf (metadata: topic=haskell)
+    c.pdf (metadata: topic=iojs)
+    d.pdf (metadata: topic=python)
+    e.pdf (metadata: topic=haskell)
+
+if i issue `git annex view topic=haskell`, i have the files i want in my annex' root:
+
+    a.pdf
+    b.pdf
+    e.pdf
+
+obviously i could then simply run `rsync --exclude .git -aL --delete . ../other/dir`, which is totally fine, but maybe i'm just blindly missing something obvious and i could simply use something like `git annex --work-tree=../other/dir view topic=haskell` and see `a.pdf`, `b.pdf` and `e.pdf` appear in the target directory (i don't need any metadata in that directory, so only the plain files and no .git folder for a remote is fine).
diff --git a/doc/forum/checkout_view_to_directory_outside_of_annex/comment_1_a31a501bdc28eabc60588502f7219e50._comment b/doc/forum/checkout_view_to_directory_outside_of_annex/comment_1_a31a501bdc28eabc60588502f7219e50._comment
new file mode 100644
index 0000000000..a0d1f4dab7
--- /dev/null
+++ b/doc/forum/checkout_view_to_directory_outside_of_annex/comment_1_a31a501bdc28eabc60588502f7219e50._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-11T16:57:45Z"
+ content="""
+Well, you can certianly use --work-tree with git-annex. As a global git
+option, it has to be passed after the "git" and before the "annex". However,
+since the view is constructed by making symlinks to the annexed content,
+the result will be a directory full of symlinks, rather than the contents
+of the files. Also, it'll still update the repo  to think it has this view
+checked out, with confusing results.
+
+rsync seems to be a perfectly good way to do what you want, if you want
+to have copies of the files.
+
+Or, you might consider making a shared clone of the git repo wherever you 
+want that tree of files, and checking out the desired view in the clone.
+In a shared clone with a recent version of git-annex, running `git annex
+get` will quickly hard-link the files from the main repo (when possible).
+"""]]
diff --git a/doc/forum/checkout_view_to_directory_outside_of_annex/comment_2_b4abbb048ebcd3c4b59d20e103948fd8._comment b/doc/forum/checkout_view_to_directory_outside_of_annex/comment_2_b4abbb048ebcd3c4b59d20e103948fd8._comment
new file mode 100644
index 0000000000..fecf397411
--- /dev/null
+++ b/doc/forum/checkout_view_to_directory_outside_of_annex/comment_2_b4abbb048ebcd3c4b59d20e103948fd8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://mey.vn/"
+ subject="comment 2"
+ date="2015-08-12T10:54:29Z"
+ content="""
+thanks @joey - the shared clone strategy looks perfect as a way to leave the main repo alone while enjoying all the benefits of views.
+"""]]
diff --git a/doc/forum/checkout_view_to_directory_outside_of_annex/comment_3_2139407a3a556023a2458148a4a2c009._comment b/doc/forum/checkout_view_to_directory_outside_of_annex/comment_3_2139407a3a556023a2458148a4a2c009._comment
new file mode 100644
index 0000000000..b6e48b4ece
--- /dev/null
+++ b/doc/forum/checkout_view_to_directory_outside_of_annex/comment_3_2139407a3a556023a2458148a4a2c009._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="konubinix"
+ subject="git-new-workdir"
+ date="2015-08-15T12:48:30Z"
+ content="""
+I am not sure whether it would help, but to show views of my git-annex repositories without messing with the current working directory, I generally use git-new-workdir
+https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir
+
+It allows to checkout a separate branch in another directory. The new directory's .git directory contains symbolic links to the parent one, making sure that changes in the new work dir are propagated to the parent one.
+
+Hope that helps.
+"""]]
diff --git a/doc/forum/clear_box.com_repository.mdwn b/doc/forum/clear_box.com_repository.mdwn
new file mode 100644
index 0000000000..0de67cf623
--- /dev/null
+++ b/doc/forum/clear_box.com_repository.mdwn
@@ -0,0 +1 @@
+Using webapp I cannot get rid of box.com repository, it is locked in 'cleaning out' state for more than two weeks. How can I remove the repository from the list?
diff --git a/doc/forum/clear_box.com_repository/comment_1_2e839d8f974269c80a9fca183712350f._comment b/doc/forum/clear_box.com_repository/comment_1_2e839d8f974269c80a9fca183712350f._comment
new file mode 100644
index 0000000000..939e9b8938
--- /dev/null
+++ b/doc/forum/clear_box.com_repository/comment_1_2e839d8f974269c80a9fca183712350f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-06-14T16:21:54Z"
+ content="""
+We need to first understand why it's not finishing the process. Does the box.com repository still contain files? You can find out by running the command: `git annex find --in box.com` (substitute the name of your remote for box.com as needed).
+"""]]
diff --git a/doc/forum/clear_box.com_repository/comment_2_8f9c7248a148a24ae2aba39c4a79a6d1._comment b/doc/forum/clear_box.com_repository/comment_2_8f9c7248a148a24ae2aba39c4a79a6d1._comment
new file mode 100644
index 0000000000..9725c96e5a
--- /dev/null
+++ b/doc/forum/clear_box.com_repository/comment_2_8f9c7248a148a24ae2aba39c4a79a6d1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="tomas"
+ ip="188.167.111.235"
+ subject="comment 2"
+ date="2013-06-16T13:32:31Z"
+ content="""
+The result of that command returned without writing any files.
+"""]]
diff --git a/doc/forum/clear_box.com_repository/comment_3_f64ad21e5abfbf4e1f925b3d651bdba3._comment b/doc/forum/clear_box.com_repository/comment_3_f64ad21e5abfbf4e1f925b3d651bdba3._comment
new file mode 100644
index 0000000000..6b19da5c7d
--- /dev/null
+++ b/doc/forum/clear_box.com_repository/comment_3_f64ad21e5abfbf4e1f925b3d651bdba3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-06-17T17:34:04Z"
+ content="""
+In that case, I'd expect the assistant will notice it can remove the remote on the next full scan, and prompt you to finish the removal. Full scans are run in a few situations, but the only guaranteed way to run one is to stop and restart the assistant.
+
+You could also enable debug mode when starting it, I'm sure the log would be useful if it somehow doesn't behave how it should.
+"""]]
diff --git a/doc/forum/clear_box.com_repository/comment_4_f8c06ac9b23b51cf18d362c260fc47a9._comment b/doc/forum/clear_box.com_repository/comment_4_f8c06ac9b23b51cf18d362c260fc47a9._comment
new file mode 100644
index 0000000000..a36ca12370
--- /dev/null
+++ b/doc/forum/clear_box.com_repository/comment_4_f8c06ac9b23b51cf18d362c260fc47a9._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="tomas"
+ ip="188.167.111.235"
+ subject="comment 4"
+ date="2013-06-17T20:17:30Z"
+ content="""
+Hi, I cannot enable debug logging via webapp, because after restart the checkbox is unchecked again. I saw nothing at all in logs after restart, the box repo is still hanging there. I would prefer using command line to remove the last traces of this repository. 
+Another similar question - how do I unassociate two repositories? The web app warns me that about deleting repo, not sure if it would also wipe it out. Is there a CLI command to add and remove the associations (git remote rm?)? Overall great work, but I am lost with the webapp. It is good for learning the concepts, but I would love to know which commands it actually executes on the backend to make the gui -> cli transition easier.
+
+Version: 4.20130516.1
+Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+
+"""]]
diff --git a/doc/forum/clear_box.com_repository/comment_5_61d401b29322802cb25896503f3e6514._comment b/doc/forum/clear_box.com_repository/comment_5_61d401b29322802cb25896503f3e6514._comment
new file mode 100644
index 0000000000..122e054a93
--- /dev/null
+++ b/doc/forum/clear_box.com_repository/comment_5_61d401b29322802cb25896503f3e6514._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 5"
+ date="2013-06-17T23:53:24Z"
+ content="""
+Use the --debug switch to enable debugging on startup.
+"""]]
diff --git a/doc/forum/client_repositories_setup_problem.mdwn b/doc/forum/client_repositories_setup_problem.mdwn
new file mode 100644
index 0000000000..a7092c2b90
--- /dev/null
+++ b/doc/forum/client_repositories_setup_problem.mdwn
@@ -0,0 +1,156 @@
+I'm trying to setup git-annex for syncing two clients using a transfer repository. All of that without the webapp UI.
+
+Here's the reproducible scenario with a bash script:
+
+```bash
+#/usr/bin/env bash
+
+# Just a way to access the script's directory
+cd "$(dirname "$0")"
+DIR="$(pwd)"
+
+# Create the 1st client repository
+mkdir $DIR/client1
+cd $DIR/client1
+git init && git annex init
+
+# Create the 2nd client repository
+mkdir $DIR/client2
+cd $DIR/client2
+git init && git annex init
+
+# Create the transfer repository
+mkdir $DIR/share
+cd $DIR/share
+git init && git annex init
+
+# Setup the remotes and groups for the transfer repository
+cd $DIR/share
+git remote add client1 $DIR/client1
+git remote add client2 $DIR/client1
+git annex group . transfer
+git annex group client1 client
+git annex group client2 client
+git co -b main
+
+# Setup the remotes and groups for the 1st client repository.
+cd $DIR/client1
+git remote add share $DIR/share
+git annex group . client
+git annex group share transfer
+git co -b main
+
+# Setup the remotes and groups for the 2nd client repository.
+cd $DIR/client2
+git remote add share $DIR/share
+git annex group . client
+git annex group share transfer
+git co -b main
+
+# Run git-annex assistant for each repository
+cd $DIR/client1 && git annex assistant
+cd $DIR/client2 && git annex assistant
+cd $DIR/share && git annex assistant
+
+# Add a single file to the 1st client.
+cd $DIR/client1
+echo "My first file" >> file.txt
+```
+
+Result:
+
+client1: I see the auto-commit has been added for file.txt
+
+share: I get the following daemon logs:
+
+```
+(scanning...) (started...) 
+From /home/xxx/git-annex-scenarios/share-between-clients/client1
+ * [new branch]      git-annex  -> client2/git-annex
+(merging client2/git-annex into git-annex...)
+From /home/xxx/git-annex-scenarios/share-between-clients/client1
+ * [new branch]      git-annex  -> client1/git-annex
+
+merge: refs/remotes/client2/main - not something we can merge
+
+merge: refs/remotes/client2/synced/main - not something we can merge
+
+merge: refs/remotes/client1/main - not something we can merge
+
+merge: refs/remotes/client1/synced/main - not something we can merge
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+
+```
+
+client2: I get the following daemon logs:
+
+```
+From /home/xxx/git-annex-scenarios/share-between-clients/share
+ * [new branch]      git-annex  -> share/git-annex
+(merging share/git-annex into git-annex...)
+(recording state in git...)
+
+merge: refs/remotes/share/main - not something we can merge
+
+merge: refs/remotes/share/synced/main - not something we can merge
+
+```
+
+Then, I thought that maybe I needed to do an initial `git pull` for each repository. So I tried adding to the bash script the following lines:
+
+```bash
+# Need to do this if there are no commits in the 'client2' and 'share' repositories.
+# Or else, I'll get the following logs:
+#
+# merge: refs/remotes/share/main - not something we can merge
+# merge: refs/remotes/share/synced/main - not something we can merge
+sleep 3;
+cd $DIR/share
+git pull client1 main
+sleep 3;
+cd $DIR/client2
+git pull share main
+```
+
+But I'm still getting the same error:
+
+```
+(scanning...) (started...) 
+From /home/xxx/git-annex-scenarios/share-between-clients/share
+ * [new branch]      git-annex  -> share/git-annex
+(merging share/git-annex into git-annex...)
+(recording state in git...)
+
+merge: refs/remotes/share/main - not something we can merge
+
+merge: refs/remotes/share/synced/main - not something we can merge
+(recording state in git...)
+To /home/kolam/git-annex-scenarios/share-between-clients/share
+ + 28079ec...ca3c481 git-annex -> synced/git-annex (forced update)
+Everything up-to-date
+To /home/kolam/git-annex-scenarios/share-between-clients/share
+ + 28079ec...ca3c481 git-annex -> synced/git-annex (forced update)
+```
+
+However, even though I have that error, `file.txt` now appears in `client2`.
+But, the content of `file.txt` is:
+
+```
+/annex/objects/SHA256E-s14--14b99b7ab1e9777f7e1c2b482fe2cd95653c7cf35f
+459ef0b15bd0d75b2245c9.txt
+```
+
+and that link doesn't exist in my filesystem.
+Running `git annex whereis file.txt` in `client2` gives me:
+
+```
+whereis file.txt (0 copies) failed
+whereis: 1 failed
+```
+
+So my questions are:
+
+* did I miss something in the steps required to setup the repositories?
+* is there some documentation outlining the steps to do so without the webapp?
+* how can we enhance the UX for that scenario with better messages?
diff --git a/doc/forum/client_repositories_setup_problem/comment_1_be53f90b66de690b39f487d394866a66._comment b/doc/forum/client_repositories_setup_problem/comment_1_be53f90b66de690b39f487d394866a66._comment
new file mode 100644
index 0000000000..b15d985617
--- /dev/null
+++ b/doc/forum/client_repositories_setup_problem/comment_1_be53f90b66de690b39f487d394866a66._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-12-04T17:48:39Z"
+ content="""
+	git remote add client1 $DIR/client1
+	git remote add client2 $DIR/client1
+
+It seems to me you have a typo in the second line there.
+
+The other problem I noticed is, you are putting repositories in groups, but you
+never configure preferred content, and so the group settings will not be used.
+So you probably want to run `git-annex wanted here standard` in each of the
+repositories.
+
+With those fixes, it seems to work for me.
+"""]]
diff --git a/doc/forum/client_repositories_setup_problem/comment_2_f9660534c3f3346f322de57c2da0eb27._comment b/doc/forum/client_repositories_setup_problem/comment_2_f9660534c3f3346f322de57c2da0eb27._comment
new file mode 100644
index 0000000000..92ed584657
--- /dev/null
+++ b/doc/forum/client_repositories_setup_problem/comment_2_f9660534c3f3346f322de57c2da0eb27._comment
@@ -0,0 +1,87 @@
+[[!comment format=mdwn
+ username="kolam"
+ avatar="http://cdn.libravatar.org/avatar/4d2741e5e0b47928bc599b00397b5e59"
+ subject="comment 2"
+ date="2023-12-06T21:08:05Z"
+ content="""
+Thanks Joey! Your comment is right on point.
+
+Changed to the following and now it works as expected. The bash script is now:
+
+```
+#/usr/bin/env bash
+
+# Just a way to access the script's directory
+cd \"$(dirname \"$0\")\"
+DIR=\"$(pwd)\"
+
+# Create the 1st client repository
+mkdir $DIR/client1
+cd $DIR/client1
+git init && git annex init
+
+# Create the 2nd client repository
+mkdir $DIR/client2
+cd $DIR/client2
+git init && git annex init
+
+# Create the transfer repository
+mkdir $DIR/share
+cd $DIR/share
+git init && git annex init
+
+# Setup the remotes and groups for the transfer repository
+cd $DIR/share
+git remote add client1 $DIR/client1
+git remote add client2 $DIR/client2
+git annex wanted . standard
+git annex group . transfer
+git annex group client1 client
+git annex group client2 client
+git annex mincopies 2
+git annex numcopies 2
+git co -b main
+
+# Setup the remotes and groups for the 1st client repository.
+cd $DIR/client1
+git remote add share $DIR/share
+git annex wanted . standard
+git annex group . client
+git annex group share transfer
+# git annex config --set annex.addunlocked true
+git co -b main
+
+# Setup the remotes and groups for the 2nd client repository.
+cd $DIR/client2
+git remote add share $DIR/share
+git annex wanted . standard
+git annex group . client
+git annex group share transfer
+# git annex config --set annex.addunlocked true
+git co -b main
+
+# Start git-annex assistant for client1 only
+cd $DIR/client1 && git annex assistant
+
+# Add a single file to the 1st client.
+cd $DIR/client1
+touch file.txt
+
+# Wait for the commit to be auto created by git-annex-assistant.
+sleep 3;
+
+cd $DIR/share
+git pull client1 main
+git annex assistant
+cd $DIR/client2
+git pull share main
+git annex assistant
+
+cd $DIR/client1
+echo \"My first line\" >> file.txt
+```
+
+I have other issues following that, but I'll create separate forum questions for them.
+
+Thanks again Joey.
+"""]]
diff --git a/doc/forum/cloud_services_to_support.mdwn b/doc/forum/cloud_services_to_support.mdwn
new file mode 100644
index 0000000000..4d6bde1b54
--- /dev/null
+++ b/doc/forum/cloud_services_to_support.mdwn
@@ -0,0 +1,16 @@
+git-annex can already be used to store data in several cloud services:
+Amazon S3, rsync.net, Tahoe-LAFS, The Internet Archive.
+
+I would like to support as many other cloud services as possible/reasonable.
+
+* [[swift|todo/wishlist:_swift_backend]]
+* Dropbox (I had been reluctant to go there due to it using a non-free client,
+  which I have no interest in installing, but there is actually an API,
+  and already a
+  [haskell module to use it](http://hackage.haskell.org/package/dropbox-sdk).
+  Would need to register for an API key.
+  <http://www.dropbox.com/developers/start/core>.
+  Annoyingly, Dropbox reviews each app before granting it production status.
+  Whoops my interest level dropped by 99%.)
+
+Post others in the comments. --[[Joey]]
diff --git a/doc/forum/cloudcmd.mdwn b/doc/forum/cloudcmd.mdwn
new file mode 100644
index 0000000000..a572abf1ca
--- /dev/null
+++ b/doc/forum/cloudcmd.mdwn
@@ -0,0 +1,6 @@
+Hi,
+
+Glad to see this project appears to be doing well.  I just wanted to mention that there's a similar project called cloudcmd that has many of the same use cases in spirit: https://github.com/briangu/cloudcmd
+
+Cheers,
+Brian
diff --git a/doc/forum/commit_current_workdir_state_in_direct_mode.mdwn b/doc/forum/commit_current_workdir_state_in_direct_mode.mdwn
new file mode 100644
index 0000000000..63945f7901
--- /dev/null
+++ b/doc/forum/commit_current_workdir_state_in_direct_mode.mdwn
@@ -0,0 +1,5 @@
+I'd like to commit the current workdir state in direct mode in a script. This is what git annex watch does but I can not reliably start and stop git annex watch in a cron script.
+
+Is this already possible with the current api or could we have something like git annex watch --once?
+
+Thank you, Thomas Koch
diff --git a/doc/forum/commit_current_workdir_state_in_direct_mode/comment_1_748481ff00374f570284bd4571584874._comment b/doc/forum/commit_current_workdir_state_in_direct_mode/comment_1_748481ff00374f570284bd4571584874._comment
new file mode 100644
index 0000000000..50bd6661ce
--- /dev/null
+++ b/doc/forum/commit_current_workdir_state_in_direct_mode/comment_1_748481ff00374f570284bd4571584874._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 1"
+ date="2013-07-31T16:25:34Z"
+ content="""
+It should be sufficient to run: `git annex add; git annex sync`
+
+That adds any new files and then commits those along with any changed or deleted files.
+"""]]
diff --git a/doc/forum/compiling_on_MacOS.mdwn b/doc/forum/compiling_on_MacOS.mdwn
new file mode 100644
index 0000000000..c6732e3643
--- /dev/null
+++ b/doc/forum/compiling_on_MacOS.mdwn
@@ -0,0 +1,3 @@
+When compiling on MacOS using Stack, I get errors related to the iconv library:
+https://travis-ci.org/conda-forge/staged-recipes/builds/315444536?utm_source=github_status&utm_medium=notification
+Any suggestions on how to fix this?
diff --git a/doc/forum/compiling_on_MacOS/comment_1_143ae6d4f2704d4ab74e110a2d7a3c82._comment b/doc/forum/compiling_on_MacOS/comment_1_143ae6d4f2704d4ab74e110a2d7a3c82._comment
new file mode 100644
index 0000000000..93911b784a
--- /dev/null
+++ b/doc/forum/compiling_on_MacOS/comment_1_143ae6d4f2704d4ab74e110a2d7a3c82._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-12-31T16:41:06Z"
+ content="""
+I can only give the same anwser I gave in
+<https://github.com/conda-forge/staged-recipes/pull/4157>,
+that it seems to be using the wrong version of the iconv library, and that
+the `LIBRARY_PATH`, `LDFLAGS` etc settings your using seem likely to be
+causing the problem.
+
+I mean, you're simply using haskell's stack tool, you've not started to
+build git-annex at all at this point. If haskell's stack is really this
+broken on OSX, I'd think that a lot of people would have noticed. But if
+you can reproduce the problem without any strange environment variables
+being set, why not file a bug report at <https://github.com/commercialhaskell/stack/issues/new>.
+"""]]
diff --git a/doc/forum/comprehension_question__58___repository_vs._working_copy_in_direct_mode.mdwn b/doc/forum/comprehension_question__58___repository_vs._working_copy_in_direct_mode.mdwn
new file mode 100644
index 0000000000..350bcd7bd2
--- /dev/null
+++ b/doc/forum/comprehension_question__58___repository_vs._working_copy_in_direct_mode.mdwn
@@ -0,0 +1,10 @@
+(I put this in a separate topic because it is a different question)
+
+I still do not fully understand when (in direct mode!) a file is in the work copy and when in the repository.
+Because what git-annex always refers to a "repository" is actually a repository (i.e., the server part for subversion) *and* a work copy (the client part in subversion), right? (except for bare repositories which have only the former)
+
+When I change a file in the work copy, I still need to "git annex sync", right? But do I also need to "git annex sync --content" to move the changes from the work copy to the repository?
+
+Because I have a headless server where the annex should also be accessed via samba. When files are added/changed, the annex clients do not see the changes until I manually do a couple of "git annex sync" and "git annex sync --content" (it's not deterministic yet for me how often).
+
+Is this the intended behavior? If yes, is there a better way to automatically sync the changes on the headless server other than a cron job?
diff --git a/doc/forum/comprehension_question__58___repository_vs._working_copy_in_direct_mode/comment_1_a6b4db0cefa439f72b97089d48dfacbd._comment b/doc/forum/comprehension_question__58___repository_vs._working_copy_in_direct_mode/comment_1_a6b4db0cefa439f72b97089d48dfacbd._comment
new file mode 100644
index 0000000000..327c057053
--- /dev/null
+++ b/doc/forum/comprehension_question__58___repository_vs._working_copy_in_direct_mode/comment_1_a6b4db0cefa439f72b97089d48dfacbd._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-21T19:54:15Z"
+ content="""
+A git repository is a `.git` directory (or `git.bare` for a bare repository).
+
+A working tree is the directory that contains the `.git` directory.
+
+That is standard git terminology; git-annex does not change this at all really. The only difference is that a file added to git-annex is in both the repository and the working tree at the same time, rather than their being 2 local copies of the file (which would need twice the disk space so not good for large files).
+
+`git annex sync` commits any changes to files in the working tree, and pushes those changes to other remotes. You need to pass --content to also make git-annex upload the files to other remotes. Once a remote has been pushed to, you can run `git annex merge` in it to update its working tree to reflect the pushed changes (`git annex sync` also does that merge).
+
+To automatically sync changes to remotes, you can run the git-annex assistant.
+"""]]
diff --git a/doc/forum/conda-forge_build_problem.mdwn b/doc/forum/conda-forge_build_problem.mdwn
new file mode 100644
index 0000000000..81d0451a06
--- /dev/null
+++ b/doc/forum/conda-forge_build_problem.mdwn
@@ -0,0 +1,10 @@
+Attempt to build the conda-forge recipe for the latest git-annex version fails like this:
+https://circleci.com/gh/conda-forge/git-annex-feedstock/124?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
++ stack --local-bin-path /home/conda/feedstock_root/build_artifacts/git-annex_1544129313702/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/bin --extra-include-dirs /home/conda/feedstock_root/build_artifacts/git-annex_1544129313702/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/include --extra-lib-dirs /home/conda/feedstock_root/build_artifacts/git-annex_1544129313702/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/lib --stack-root /home/conda/feedstock_root/build_artifacts/git-annex_1544129313702/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/share/git-annex-7.20181205-0/stackroot setup
+Downloading lts-12.19 build plan ...
+Downloaded lts-12.19 build plan.
+No setup information found for ghc-8.4.4 on your platform.
+This probably means a GHC bindist has not yet been added for OS key 'linux64-gmp4'.
+Supported versions: ghc-7.8.4, ghc-7.10.2, ghc-7.10.3, ghc-8.0.1, ghc-8.0.2, ghc-8.2.1, ghc-8.2.2, ghc-8.4.2
+
+Is there a way to specify that ghc-8.4.2 is ok (if it is ok)?
diff --git a/doc/forum/conda-forge_build_problem/comment_1_22e01f5f110593796b539fc7630ccb3c._comment b/doc/forum/conda-forge_build_problem/comment_1_22e01f5f110593796b539fc7630ccb3c._comment
new file mode 100644
index 0000000000..2887544a3e
--- /dev/null
+++ b/doc/forum/conda-forge_build_problem/comment_1_22e01f5f110593796b539fc7630ccb3c._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-09T15:15:36Z"
+ content="""
+The way that stack works is the "resolver" value in stack.yaml
+points to a particular version of ghc and libraries that work with it.
+
+I don't think that stack allows overriding the version of ghc. What you can
+do is go to <http://stackage.org/> and find a snapshot that includes the
+ghc version you have available, and edit stack.yaml's "resolver" to use
+that. You may also need to pass --system-ghc to stack to make it use your
+installed ghc rather than trying to download it.
+
+Building with cabal, while more error prone, is another way to use whatever
+version of ghc you have installed already.
+"""]]
diff --git a/doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__.mdwn b/doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__.mdwn
new file mode 100644
index 0000000000..174f4f35d2
--- /dev/null
+++ b/doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__.mdwn
@@ -0,0 +1,7 @@
+I would like `git annex sync` to only sync `git-annex`'s bookkeeping metadata, and *not* my master branch or file content.
+
+I tried setting `annex.synconlyannex = true` (in `~/.gitconfig`), and was surprised to find that although that disables syncing of my master branch, it *enables* syncing of content.
+
+I can add `--no-content` on the command line, but I'd rather not type that every time. Is there a way to do it purely through `~/.gitconfig`? (Maybe consider it as a feature request?)
+
+(Motivation: I find it jarring when git annex creates git commits on my own branches without asking me. I already set `annex.autocommit = false`, but `git annex sync` will still make merge commits unless I set `annexsynconlyannex = true`.)
diff --git a/doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__/comment_1_ce9d638b8a07375a79a9ee04b02d6e95._comment b/doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__/comment_1_ce9d638b8a07375a79a9ee04b02d6e95._comment
new file mode 100644
index 0000000000..4df97f0f70
--- /dev/null
+++ b/doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__/comment_1_ce9d638b8a07375a79a9ee04b02d6e95._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-10-03T22:20:37Z"
+ content="""
+The merge commits that git-annex sync still makes with annex.autocommit
+set to false are the same as the merge commits that git pull makes
+(with the addition of merge conflict resolution that annex.resolvemerge
+can prevent).
+
+The idea with annex.synconlyannex is that a user, who has their own
+git workflow already and does not want to change it, can set that and use
+git-annex sync to sync all the git-annex data.
+
+Adding new configurability to git-annex sync is a tarpit: If left unchecked
+it will parameterize every single bit of it. So, having realized this,
+I prefer to only add new configurability only when I have a broad
+use case for it, like the one that led to annex.synconlyannex.
+
+It is easy enough to write a small shell script that syncs only the
+git-annex branch, using appropriately low-level commands:
+
+	#!/bin/sh
+	git fetch origin git-annex
+	git annex merge
+	git push origin git-annex
+"""]]
diff --git a/doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__/comment_2_11b9261bc5c32d3e36357afc021ac4e1._comment b/doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__/comment_2_11b9261bc5c32d3e36357afc021ac4e1._comment
new file mode 100644
index 0000000000..ec390af969
--- /dev/null
+++ b/doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__/comment_2_11b9261bc5c32d3e36357afc021ac4e1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="falsifian"
+ avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae"
+ subject="comment 2"
+ date="2021-10-05T20:55:32Z"
+ content="""
+Thanks joey, your script is useful and I can use it as a workaround if necessary.
+
+I still don't understand the reason behind the behaviour. Why does `annex.synconlyannex = true` cause content to be synced? Wouldn't it be simpler to just say content is synced iff `annex.synccontent` is set to true? (I leave at the default, `false`, because I don't want content to be synced, but that does not help.)
+
+"""]]
diff --git a/doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__/comment_3_07e6f767e38d9812b176ee3fdb00adf0._comment b/doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__/comment_3_07e6f767e38d9812b176ee3fdb00adf0._comment
new file mode 100644
index 0000000000..a9b271d362
--- /dev/null
+++ b/doc/forum/config_to_make_git_annex_sync_only_sync_metadata__63__/comment_3_07e6f767e38d9812b176ee3fdb00adf0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="falsifian"
+ avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae"
+ subject="comment 3"
+ date="2021-10-06T03:36:01Z"
+ content="""
+Clarification: `git annex sync --no-content ...` is working fine for me. So I don't need the script.
+
+I guess I can define a shell alias to fill in the `--no-content` part.
+"""]]
diff --git a/doc/forum/conflict_with_git-crypt.mdwn b/doc/forum/conflict_with_git-crypt.mdwn
new file mode 100644
index 0000000000..0484ea5c87
--- /dev/null
+++ b/doc/forum/conflict_with_git-crypt.mdwn
@@ -0,0 +1,3 @@
+[git-crypt](https://www.agwa.name/projects/git-crypt/) is executed as a filter for secrets specified in `.gitattributes` files. However, git-annex initialization results in `* filter=annex` being added to `$GIT_DIR/info/attributes`, which [has the highest precedence](https://www.git-scm.com/docs/gitattributes#_description), ultimately causing any git-crypt filtering to be bypassed.
+
+Is there a recommended workaround for this? Thanks!
diff --git a/doc/forum/conflict_with_git-crypt/comment_1_b81a3cd99ff04e21ef520a497c0bd46a._comment b/doc/forum/conflict_with_git-crypt/comment_1_b81a3cd99ff04e21ef520a497c0bd46a._comment
new file mode 100644
index 0000000000..bdef755ec0
--- /dev/null
+++ b/doc/forum/conflict_with_git-crypt/comment_1_b81a3cd99ff04e21ef520a497c0bd46a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-12-07T16:55:51Z"
+ content="""
+I guess this is about them both setting the filter attribute.
+
+git-annex does not write to .git/info/attributes after
+`git-annex init` so you can move the filter=annex line from there to
+another file, or change the line to only match on some files not `*`,
+or even delete it, if you want to.
+"""]]
diff --git a/doc/forum/conflict_with_git-crypt/comment_2_cda648fcc5f213af06fe98428910f561._comment b/doc/forum/conflict_with_git-crypt/comment_2_cda648fcc5f213af06fe98428910f561._comment
new file mode 100644
index 0000000000..cf4a401e89
--- /dev/null
+++ b/doc/forum/conflict_with_git-crypt/comment_2_cda648fcc5f213af06fe98428910f561._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="alt"
+ subject="comment 2"
+ date="2021-12-08T20:01:33Z"
+ content="""
+Thank you for your explanation! 
+
+Removing `* filter=annex` altogether causes problems when the repo has unlocked files, but removing it from `.git/info/attributes` and adding a `.gitattributes` file with the following contents at the repository root seems to allow both git-crypt and git-annex to work without issue:
+
+```
+* filter=annex
+my_secret filter=git-crypt diff=git-crypt
+```
+
+"""]]
diff --git a/doc/forum/conflict_with_git-crypt/comment_3_6e7ea4ed29e6b526c27979988d09d883._comment b/doc/forum/conflict_with_git-crypt/comment_3_6e7ea4ed29e6b526c27979988d09d883._comment
new file mode 100644
index 0000000000..74c5cfb08e
--- /dev/null
+++ b/doc/forum/conflict_with_git-crypt/comment_3_6e7ea4ed29e6b526c27979988d09d883._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-12-09T17:40:05Z"
+ content="""
+So both are setting the "filter" attribute. And trying 
+`git check-attr filter my_secret` it outputs "git-crypt"
+with the configuration you show, but with git-annex's .git/info/attributes,
+it outputs "annex".
+
+       When deciding what attributes are assigned to a path, Git consults
+       $GIT_DIR/info/attributes file (which has the highest precedence),
+       .gitattributes file in the same directory as the path in question, and
+       its parent directories up to the toplevel of the work tree (the further
+       the directory that contains .gitattributes is from the path in
+       question, the lower its precedence). Finally global and system-wide
+       files are considered (they have the lowest precedence).
+
+So by "highest precedence" it means it stops when it finds the attribute
+in that file. Unfortunate, but I kind of see why they would do that,
+since .git/info/attributes is a way to locally override .gitattributes
+files in the repo.
+
+git-annex could write to .gitattributes, but it feels cleaner to not
+need to modify the contents of the git repo in order to use the
+current version of git-annex with it.
+"""]]
diff --git a/doc/forum/confused_about_external_drives.mdwn b/doc/forum/confused_about_external_drives.mdwn
new file mode 100644
index 0000000000..9fdb5c979e
--- /dev/null
+++ b/doc/forum/confused_about_external_drives.mdwn
@@ -0,0 +1,30 @@
+First off, to get that off my chest: I am not using Gnome, KDE, XFCE or any "desktop manager" (well, not quite true, I use some bits of XFCE, but it's easier to assume I'm not).
+
+So automounting is always a little tricky for me, and I often use `pmount` to mount external drives and flash cards.
+
+Now, I have tried to add an external drive as a backup to one of my git-annex repositories. I zero'd the drive, added a GPT partition (I wanted labels), formatted it as `ext4` and then gave it to my user:
+
+    cfdisk /dev/sdd
+    mkfs -t ext4 /dev/sdd1
+    mount /dev/sdd1 /mnt
+    chown anarcat /mnt
+    umount /mnt
+
+Now, at this step I would have assumed the drive would be seen by the webapp, but that wasn't the case. Maybe I wasn't patient enough? In any case, at some point I got tired and went to the commandline to add the drive as a remote. I did the following:
+
+    mkdir -p /media/ata-WDC_WD15EADS-00P8B0_WD-WMAVU0748851-part1
+    mount /dev/disk/by-id/ata-WDC_WD15EADS-00P8B0_WD-WMAVU0748851-part1 /media/ata-WDC_WD15EADS-00P8B0_WD-WMAVU0748851-part1
+    cd /srv/mp3
+    git annex remote add backup /media/ata-WDC_WD15EADS-00P8B0_WD-WMAVU0748851-part1/mp3
+    git init /media/ata-WDC_WD15EADS-00P8B0_WD-WMAVU0748851-part1/mp3
+    git annex sync
+    git annex copy --to backup
+
+So that worked, and the webapp was now seeing `backup` as yet another repository, but not quite removeable. So failed. Scratching that, I stopped the assistant, and trashed the repository:
+
+    rm -rf /media/ata-WDC_WD15EADS-00P8B0_WD-WMAVU0748851-part1/mp3
+    git remote rm backup
+
+But now, oddly enough, the webapp would see the external drive after being restarted, and I was able to add that drive.
+
+What am I doing wrong? how is the assistant finding those drives? --[[anarcat]]
diff --git a/doc/forum/confused_about_external_drives/comment_1_8340e5ff17a4846b41789e4966fed70c._comment b/doc/forum/confused_about_external_drives/comment_1_8340e5ff17a4846b41789e4966fed70c._comment
new file mode 100644
index 0000000000..5b7ca01141
--- /dev/null
+++ b/doc/forum/confused_about_external_drives/comment_1_8340e5ff17a4846b41789e4966fed70c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="separation of concerns"
+ date="2013-12-29T17:57:36Z"
+ content="""
+It doesn't make sense for the git-annex assistant to try to somehow detect and mount drives. Every OS has its own way to do that.
+
+The assistant simply detects drives that have been mounted by the OS.
+
+There is absolutely no problem with manually setting up a git repository on a removable drive and using it with the assistant. This is identical to what the assistant would set up for an external drive (except perhaps being a non-bare repository). The assistant simply detects if any git remote whose url is a directory is inside a mount point when it sees a new device be mounted.
+"""]]
diff --git a/doc/forum/confused_about_external_drives/comment_2_ad10bd0ec14c16bcad089b3ebe64580e._comment b/doc/forum/confused_about_external_drives/comment_2_ad10bd0ec14c16bcad089b3ebe64580e._comment
new file mode 100644
index 0000000000..c0eb3d8c29
--- /dev/null
+++ b/doc/forum/confused_about_external_drives/comment_2_ad10bd0ec14c16bcad089b3ebe64580e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="2001:1928:1:9::1"
+ subject="comment 2"
+ date="2013-12-30T17:47:26Z"
+ content="""
+Fair enough, I guess. However, I must say that it seems that git-annex doesn't actually detect properly externally mounted hard drives. For example, here I have an annex in /srv/foo that is part of my system hard drive (but in a separate /srv partition). Then I made a backup annex in /backup/srv/foo that is on an external hard drive, yet the webapp sees those two repos as under its control - as in, i can choose both in the \"switch repository\" menu.
+
+Another drive I was able to add using the \"add external drive\" tool in the webapp doesn't show up in that list (and that's fine too!).
+"""]]
diff --git a/doc/forum/confusion_with_remotes__44___map.mdwn b/doc/forum/confusion_with_remotes__44___map.mdwn
new file mode 100644
index 0000000000..0ae75d4e99
--- /dev/null
+++ b/doc/forum/confusion_with_remotes__44___map.mdwn
@@ -0,0 +1,113 @@
+I'm starting out with git-annex and running into some confusion with setting up the remotes.
+
+I have three systems I'm trying to set up (domains edited):
+
+* psychosis: ssh://psychosis.foo.com/vid
+* bacon: ssh://bucket.foo.com/vid
+* bucket: ssh://bucket.bar.org/vid
+
+And one bare repository so that I can have a single place to push/pull:
+
+* origin: https://git.foo.com/jim/vid.git
+
+On psychosis:
+
+    psychosis$ git config --list | grep ^remote | sort
+    remote.bacon.annex-uuid=8f1f0898-f8c1-11e0-9bf2-b387af26ee63
+    remote.bacon.fetch=+refs/heads/*:refs/remotes/bacon/*
+    remote.bacon.url=ssh://bucket.foo.com/vid
+    remote.bucket.annex-uuid=82814942-f8e0-11e0-b053-e70a61e98e19
+    remote.bucket.fetch=+refs/heads/*:refs/remotes/bucket/*
+    remote.bucket.url=ssh://bucket.bar.org/vid
+    remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
+    remote.origin.url=https://git.foo.com/jim/vid.git
+    
+    psychosis$ git annex status
+    supported backends: WORM SHA1 SHA256 SHA512 SHA224 SHA384 SHA1E SHA256E SHA512E SHA224E SHA384E URL
+    supported remote types: git S3 bup directory rsync web hook
+    known repositories: 
+            09c0b436-f8de-11e0-842f-b7644539d57f -- here (psychosis)
+            82814942-f8e0-11e0-b053-e70a61e98e19 -- bucket
+    local annex keys: 2256
+    local annex size: 449 gigabytes
+    total annex keys: 2256
+    total annex size: 449 gigabytes
+    backend usage: 
+            WORM: 2256
+
+**First point of confusion**: Why doesn't "bacon" show up in "git annex status"?  I can "git annex copy --to bacon filename" and it will copy it there.  Is there some step of setting it up that I missed?  I basically just did "git remote add bacon ssh://bucket.foo.com/vid".
+
+Now I've started setting up the remotes on each host:
+
+On bacon:
+   
+    bacon$ git config --list | grep ^remote | sort
+    remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
+    remote.origin.url=https://git.foo.com/jim/vid.git
+    remote.psychosis.annex-uuid=09c0b436-f8de-11e0-842f-b7644539d57f
+    remote.psychosis.fetch=+refs/heads/*:refs/remotes/psychosis/*
+    remote.psychosis.url=ssh://psychosis.foo.com/vid
+    
+    bacon$ git annex status
+    supported backends: WORM SHA1 SHA256 SHA512 SHA224 SHA384 SHA1E SHA256E SHA512E SHA224E SHA384E URL
+    supported remote types: git S3 bup directory rsync web hook
+    known repositories: 
+            09c0b436-f8de-11e0-842f-b7644539d57f -- psychosis
+            8f1f0898-f8c1-11e0-9bf2-b387af26ee63 -- here (bacon)
+    temporary directory size: 366 megabytes (clean up with git-annex unused)
+    local annex keys: 1
+    local annex size: 308 bytes
+    total annex keys: 2256
+    total annex size: 449 gigabytes
+    backend usage: 
+            WORM: 2256
+
+On bucket:
+
+    bucket$ git config --list | grep ^remote | sort
+    remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
+    remote.origin.url=https://git.foo.com/jim/vid.git
+    remote.psychosis.annex-uuid=09c0b436-f8de-11e0-842f-b7644539d57f
+    remote.psychosis.fetch=+refs/heads/*:refs/remotes/psychosis/*
+    remote.psychosis.url=ssh://psychosis.foo.com/vid
+
+    bucket$ git annex status
+    supported backends: WORM SHA1 SHA256 SHA512 SHA224 SHA384 SHA1E SHA256E SHA512E SHA224E SHA384E URL
+    supported remote types: git S3 bup directory rsync web hook
+    known repositories: 
+            09c0b436-f8de-11e0-842f-b7644539d57f -- psychosis
+            82814942-f8e0-11e0-b053-e70a61e98e19 -- here (bucket)
+    temporary directory size: 183 megabytes (clean up with git-annex unused)
+    local annex keys: 3
+    local annex size: 550 megabytes
+    total annex keys: 2256
+    total annex size: 449 gigabytes
+    backend usage: 
+            WORM: 2256
+
+But I'm getting weird results if I try to show the map from psychosis:
+
+    psychosis$ git annex map
+    $ git annex map
+    map /vid/tv ok
+    map bacon (sshing...) 
+    ok
+    map bucket (sshing...) 
+    ok
+    map origin 
+    failed
+    map psychosis (sshing...) 
+    jim@psychosis.foo.com's password: 
+    ok
+    map psychosis (sshing...) 
+    jim@psychosis.foo.com's password: 
+    ok
+    
+      running: dot -Tx11 map.dot
+
+**Second confusion**: it's as if psychosis was considered a new remote each time?
+The generated map has psychosis listed with several redundant links:
+
+![Map](http://jim.sh/~jim/tmp/map.png)
+
+Is this some bug or do I just need to be hit with the clue bat?
diff --git a/doc/forum/confusion_with_remotes__44___map/comment_1_a38ded23b7f288292a843abcb1a56f38._comment b/doc/forum/confusion_with_remotes__44___map/comment_1_a38ded23b7f288292a843abcb1a56f38._comment
new file mode 100644
index 0000000000..97de93d9ec
--- /dev/null
+++ b/doc/forum/confusion_with_remotes__44___map/comment_1_a38ded23b7f288292a843abcb1a56f38._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-10-17T19:01:21Z"
+ content="""
+My guess is that psychosis has not pulled the git-annex branch since bacon was set up (or that bacon's git-annex branch has not been pushed to origin). git-annex status only shows remotes present in git-annex:uuid.log This may be a bug.
+
+The duplicate links in the map I don't quite understand. I only see duplicate links in my maps when I have the same repository configured as two different git remotes (for example, because the same repository can be accessed two different ways). You don't seem to have that in your config.
+"""]]
diff --git a/doc/forum/confusion_with_remotes__44___map/comment_2_cd1c98b1276444e859a22c3dbd6f2a79._comment b/doc/forum/confusion_with_remotes__44___map/comment_2_cd1c98b1276444e859a22c3dbd6f2a79._comment
new file mode 100644
index 0000000000..a61b126c0c
--- /dev/null
+++ b/doc/forum/confusion_with_remotes__44___map/comment_2_cd1c98b1276444e859a22c3dbd6f2a79._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-10-17T19:02:50Z"
+ content="""
+Actually, there is a hint that, while you ran the git annex map on psychosis, it decided to ssh to itself two times. That seems to be where the duplicate links came from, I guess you must have some git remotes you did not show.
+"""]]
diff --git a/doc/forum/confusion_with_remotes__44___map/comment_3_18531754089c991b6caefc57a5c17fe9._comment b/doc/forum/confusion_with_remotes__44___map/comment_3_18531754089c991b6caefc57a5c17fe9._comment
new file mode 100644
index 0000000000..4c77222619
--- /dev/null
+++ b/doc/forum/confusion_with_remotes__44___map/comment_3_18531754089c991b6caefc57a5c17fe9._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"
+ nickname="Jim"
+ subject="comment 3"
+ date="2011-10-17T19:50:06Z"
+ content="""
+No extra remotes (that I'm aware of); that output was only edited to change hostnames.
+
+On all three hosts, \"git push origin\" and \"git pull origin\" say everything is up to date.
+
+I'm using git-annex 3.20111011 on all hosts (although some were running 3.20110928 when I created the repositories).
+
+Regarding the multiple links, I've put a copy of the dot file [here](http://jim.sh/~jim/tmp/map.dot).
+It shows psychosis in three separate subgraphs, that are just getting rendered together as one,
+if that helps clarify anything.
+
+Wait, I just realized you said \"the git-annex branch\".  My origin only has \"master\".
+Do you mean the one specifically named \"git-annex\"?  I thought that was something that
+gets managed automatically, or is it something I need to manually check out and deal with?
+
+Any other info I could provide?
+
+
+"""]]
diff --git a/doc/forum/confusion_with_remotes__44___map/comment_4_3b89b6d1518267fcbc050c9de038b9ca._comment b/doc/forum/confusion_with_remotes__44___map/comment_4_3b89b6d1518267fcbc050c9de038b9ca._comment
new file mode 100644
index 0000000000..f6e5993c8e
--- /dev/null
+++ b/doc/forum/confusion_with_remotes__44___map/comment_4_3b89b6d1518267fcbc050c9de038b9ca._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"
+ nickname="Jim"
+ subject="comment 4"
+ date="2011-10-17T20:36:51Z"
+ content="""
+Ok, after pushing the \"git-annex\" branch to origin, then \"git annex status\" knows all repositories on all hosts, so that part makes sense now.  Thanks for the tip.  But the \"git annex map\" output hasn't changed.
+
+
+
+"""]]
diff --git a/doc/forum/confusion_with_remotes__44___map/comment_5_27801584325d259fa490f67273f2ff71._comment b/doc/forum/confusion_with_remotes__44___map/comment_5_27801584325d259fa490f67273f2ff71._comment
new file mode 100644
index 0000000000..77a2c4adbe
--- /dev/null
+++ b/doc/forum/confusion_with_remotes__44___map/comment_5_27801584325d259fa490f67273f2ff71._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"
+ nickname="Jim"
+ subject="comment 5"
+ date="2011-10-18T04:59:13Z"
+ content="""
+I think:
+
+* The first extra edge is because bucket had \"ssh://psychosis.foo.com/vid/\", while
+bacon had \"ssh://psychosis.foo.com/vid\" with no trailing slash.  That got lost in the hostname/path editing I did, sorry.
+Maybe those should be considered matching?
+* The second extra edge is because, when running \"git annex map\" from psychosis, it doesn't recognize the remote's
+remote URL as pointing back to itself.
+
+For the second case, after the \"spurious\" SSH, it could still recognize that the repositories are the same by the duplicated annex uuid, which currently shows up in `map.dot` twice.  I wonder what it would take to avoid the spurious SSH -- maybe some config that lists \"alternate\" URLs that should be considered the same as the current repository?  Or actually list URLs in uuid.log?  Fortunately, I think this only affects the map, so it's not a big problem.
+"""]]
diff --git a/doc/forum/confusion_with_remotes__44___map/comment_6_496b0d9b86869bbac3a1356d53a3dda4._comment b/doc/forum/confusion_with_remotes__44___map/comment_6_496b0d9b86869bbac3a1356d53a3dda4._comment
new file mode 100644
index 0000000000..412937f3fc
--- /dev/null
+++ b/doc/forum/confusion_with_remotes__44___map/comment_6_496b0d9b86869bbac3a1356d53a3dda4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 6"
+ date="2011-10-22T01:18:27Z"
+ content="""
+Hmm, I don't see the spurious ssh edge in the dot file -- that is, I don't see any ssh:// uris in it?
+"""]]
diff --git a/doc/forum/confusion_with_remotes__44___map/comment_7_9a456f61f956a3d5e81e723d5a90794c._comment b/doc/forum/confusion_with_remotes__44___map/comment_7_9a456f61f956a3d5e81e723d5a90794c._comment
new file mode 100644
index 0000000000..85ede3a89c
--- /dev/null
+++ b/doc/forum/confusion_with_remotes__44___map/comment_7_9a456f61f956a3d5e81e723d5a90794c._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"
+ nickname="Jim"
+ subject="comment 7"
+ date="2011-10-22T05:25:47Z"
+ content="""
+I think that's because the SSH was successful (I entered the password and let it connect), so it got the UUID and put that in the .dot instead.  The same UUID (for psychosis) then ended up in two different \"subgraph\" stanzas, and Graphviz just plotted them together as one node.
+
+<p>Maybe this will clarify:
+
+<p>On psychosis, run \"git annex map\" and press ^C at the ssh password prompt: [map-nossh.dot](http://jim.sh/~jim/tmp/map-nossh.dot)
+![Map](http://jim.sh/~jim/tmp/map-nossh.png)
+
+<p>On psychosis, run \"git annex map\" and type the correct password: [map-goodssh.dot](http://jim.sh/~jim/tmp/map-goodssh.dot)
+![Map](http://jim.sh/~jim/tmp/map-goodssh.png)
+
+As I see it:
+
+* psychosis (\"localhost\") connects to each of its remotes
+* some of them point back to ssh://psychosis
+* psychosis doesn't know that ssh://psychosis is itself, so it tries to connect
+* if successful:
+  * psychosis gets put twice in the .dot as if it was two different hosts, one \"local\" and one \"ssh://psychosis\"
+  * graphviz recognizes it as the same node because the UUID is the same, but graphviz still draws the extra connecting lines
+* if unsuccessful:
+  * ssh://psychosis is shown as an additional host that can't be reached
+"""]]
diff --git a/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts.mdwn b/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts.mdwn
new file mode 100644
index 0000000000..5c9b8f5115
--- /dev/null
+++ b/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts.mdwn
@@ -0,0 +1,6 @@
+Hi,
+I'd like to know if there's an easy way to control how "git annex sync" resolves conflicts. I use git annex (with wrappers I have written) to manage repos full of debs. The debs themselves never conflict, but the metadata does. So far this works great if people check out the repo, add some debs in, regenerate the metadata from the debs (using external scripts), and then shove it back into the central repo. Many people can do this for our shared project.
+
+This doesn't work well if two people have the repo checked out at the same time; when they "git annex sync" to shove the data back up, annex detects the merge conflict in the metadata and renames the files.
+
+What I'd like is a flag saying that while pushing the changes upstream, the sync will only perform fast-forwards and fail if that doesn't work so my wrappers can abort the user's workflow. Any advice would be appreciated.
diff --git a/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_1_48be720ff150112f30273960f677056c._comment b/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_1_48be720ff150112f30273960f677056c._comment
new file mode 100644
index 0000000000..37a0fa3c7c
--- /dev/null
+++ b/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_1_48be720ff150112f30273960f677056c._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-01T15:41:33Z"
+ content="""
+Failing at push seems too late; the user will already have a branch with
+the unwanted merge in it at that point and could have additional changes
+commited on top of it. And, only allowing fast-forward
+merges is probably not what you want either; regular non-conflicting git
+merges that are not fast-forwards will almost always be fine. If you did
+want to prevent any pushes containing non-fast-forward merges, you could
+do it with an `update` hook in the server's git repo.
+
+There is not currently a way to prevent `git annex sync` from
+auto-resolving a merge conflict, but I think there definitely should be.
+Something like `git config annex.resolvemerge false`.
+And, it probably makes sense to let that be configuration be propigated
+to all clones of a repository, by using
+`git-annex config annex.resolvemerge false`
+"""]]
diff --git a/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_2_c091e5a668b15aca7b2faa955beab403._comment b/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_2_c091e5a668b15aca7b2faa955beab403._comment
new file mode 100644
index 0000000000..f254f6e7d1
--- /dev/null
+++ b/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_2_c091e5a668b15aca7b2faa955beab403._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-06-01T16:16:44Z"
+ content="""
+I've implemented the annex.automerge configuration setting, for the next
+release. There's also a `git annex sync --no-resolvemerge`
+"""]]
diff --git a/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_2_d8dddf7b565273390ce4ba1c22dabf46._comment b/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_2_d8dddf7b565273390ce4ba1c22dabf46._comment
new file mode 100644
index 0000000000..c257a3debe
--- /dev/null
+++ b/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_2_d8dddf7b565273390ce4ba1c22dabf46._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="pgunn01@39c747700d10e9e9e4557a407cba2f88c22b202d"
+ nickname="pgunn01"
+ avatar="http://cdn.libravatar.org/avatar/0ca97d677b2cc6c5a262f3709ad93381"
+ subject="reply to joey"
+ date="2017-06-01T16:47:25Z"
+ content="""
+In our case (Not claiming a broader usage), failing at push is exactly what we want. We're using git-annex, with wrappers, as a transport mechanism for many-gigabyte debian repos, and in the end there's only one correct notion of what's in our repos. There's no local work that's of any significance, and we can catch problems clientside and redo as needed.
+
+A user will log onto a small number of hosts, pulldown the repo (with scripts I wrote that wrap annex), add some debs, regenerate the apt metadata, and then commit/push all that to S3/git. And then they'll remove their checkout.
+
+On the other side, on many repo hosts they'll get new delivered versions of the git repo, then refresh from S3, and then they're ready to serve the contents to the rest of our infra.
+
+(I realise this is probably a weird edge case for how people use annex; we use it because it lets us use git and see who's doing things, because it works well with our centralised git repos, and because those centralised git repos are not burdened with gigantic files)
+"""]]
diff --git a/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_4_c019c5b4d1c2a7941aed8791b6749f5b._comment b/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_4_c019c5b4d1c2a7941aed8791b6749f5b._comment
new file mode 100644
index 0000000000..8eb169ba93
--- /dev/null
+++ b/doc/forum/controlling_how___34__git_annex_sync__34___resolves_conflicts/comment_4_c019c5b4d1c2a7941aed8791b6749f5b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-06-01T17:14:28Z"
+ content="""
+Well, a git `update` hook is the only way to utterly prevent non-ff's being
+pushed.
+
+Since you're checking out the repository fresh each time, your scripts
+could use `git annex sync --no-pull`. That would fail if someone else
+pushed work to the repo in the meantime, and you could then use whatever
+git commands make sense for you to fetch and rebase on top of the new changes.
+"""]]
diff --git a/doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo.mdwn b/doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo.mdwn
new file mode 100644
index 0000000000..40735383ae
--- /dev/null
+++ b/doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo.mdwn
@@ -0,0 +1,34 @@
+Hi,
+I'm trying to convert a v5 classic, symlink repository into a v6 always unloked repository.
+
+
+I'm trying to follow along with: <http://git-annex.branchable.com/tips/unlocked_files>
+but something goes wrong in the process, so I'm sure I'm missing something.
+The repository is about 600G to start with on a ext4 filesystem, and I don't have another 600G of free space on disk, so I'm going with thin mode:
+
+1.       git annex upgrade 
+2.       git config annex.thin true 
+3.       git annex fix 
+4.       git annex unlock
+
+It's all good to this point. Everything gets unlocked and is fine. 
+Then I try to commit the changes with:
+
+     git annex sync
+
+The process seems to take 
+and incredibly long time (several hours) and then ends up running out of space. I check the repository with "du -sh"
+and it's almost double the size. Is there a reason for this? Is there a way to avoid this duplication of data. Shouldn't annex.thin do the trick?
+
+This is also strange: with "git annex info" I get
+
+     local annex keys: 3572
+     local annex size: 933.19 gigabytes
+     annexed files in working tree: 0
+     size of annexed files in working tree: 0 bytes
+
+the annex size should be about 540G and why are there no annexed files in the working tree?
+
+Is there a correct and faster way to migrate my repo to an always unlocked one which won't require hours of time and take all that disk space?
+
+thanks a lot, daniel
diff --git a/doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo/comment_1_e08eb54547bfd4dbfcc79a5a4a529647._comment b/doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo/comment_1_e08eb54547bfd4dbfcc79a5a4a529647._comment
new file mode 100644
index 0000000000..362609f524
--- /dev/null
+++ b/doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo/comment_1_e08eb54547bfd4dbfcc79a5a4a529647._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-03-14T16:48:33Z"
+ content="""
+Thank you for trying v6 unlocked mode; do note that it's still somewhat
+experimental.
+
+`git annex info` doesn't report correctly on unlocked files, which is why
+it has 0 in two places in the output you showed. I have just committed a
+fix for that problem.
+
+I don't know what would cause the unexpectedly small "local annex size".
+That should correspond to `du -hsc .git/annex/objects`; if it does then you
+seem to have fewer annexed objects than you expect for some reason.
+
+The behavior on sync sounds kind of like git commit is checking the whole
+contents of files into git, bypassing the annex. I don't know how that
+could happen, barring a misconfiguration, but it's at least the first thing
+to check. Check for gigabytes of data in .git/objects/ to see if that
+is the case. 
+
+If the above isn't the problem, can you see if the files in the work tree
+have a link count of 2? For example:
+
+	$ ls -l
+	-rw-r--r--  2 joey joey     30 Mar 14 12:49 foo
+	            ^
+
+If you don't see link count of 2, something has caused the annex.thin not
+to take effect. One possibility would be if the `git annex sync` merged in
+changes that moved a lot of files around. When that happens, git checks out
+the updated work tree, and git-annex currently is not able to preserve
+annex.thin in that case.
+"""]]
diff --git a/doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo/comment_2_85946916ac9c2a19c0d65e2b1a3e5832._comment b/doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo/comment_2_85946916ac9c2a19c0d65e2b1a3e5832._comment
new file mode 100644
index 0000000000..4c8f1b2387
--- /dev/null
+++ b/doc/forum/converting_a_v5_repo_to_an_always_unlocked_v6_repo/comment_2_85946916ac9c2a19c0d65e2b1a3e5832._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="susetux@ed6f4e20192c3eae018e1fc6442bf993d41b3848"
+ nickname="susetux"
+ subject="re"
+ date="2016-03-15T14:14:47Z"
+ content="""
+Hi, thanks for your quick feedback!
+
+So, I've investigated a bit and this is what I found:
+
+1. hardlinks are there: both \"ls -l\" and \"find -samefile\" report that most files (I haven't checked all of them though) are hardlinked, as expected, in the annex. So annex.thin is doing something.
+2. \"du -shc .git/annex/objects\" has the same size of the same command given on the whole annex, as expected  (du counts hard links only once, so it makes sense). It gives about 933G.
+3. 900G is well above what it should be: 530G of the indirect annex.
+4. This size is also reported in git annex info: \"local annex size: 933.19 gigabytes\"
+5. I tried locking the files again (and git annex fix), but the annex remained oversized.
+
+I currently deleted the annex and restored from a backup because I couldn't afford to keep it in an inconsistent state.
+It seems like this problem can be consistently reproduced. I had the same problem on a smaller annex (200G) which took a long time to commit and also inflated during the process. At the end of the process (it had enough space to finish) the size shrinked again, although it was still bigger than the original. I also tried with a test annex and random data a the problem seemed to still be there.
+
+
+"""]]
diff --git a/doc/forum/copy_--auto_copies_already_synced_files.mdwn b/doc/forum/copy_--auto_copies_already_synced_files.mdwn
new file mode 100644
index 0000000000..13a497a9da
--- /dev/null
+++ b/doc/forum/copy_--auto_copies_already_synced_files.mdwn
@@ -0,0 +1,24 @@
+Hello,
+
+I have two repos, both are standard/client and they are in sync:
+
+```
+% git annex sync marduk.dynv6 --content
+commit  ok
+pull marduk.dynv6 
+ok
+git annex sync marduk.dynv6 --content  64,35s user 4,54s system 88% cpu 1:18,15 total
+```
+I would ```copy --auto``` except to copy no files, but still, ```git annex copy --to=marduk.dynv6 --auto``` seems to copy all files:
+
+```
+% git annex copy --to=marduk.dynv6 --auto
+copy .gitignore (checking marduk.dynv6...) ok
+copy Alben/2Raumwohnung - Es wird Morgen/2Raumwohnung - 01 - Wolken ziehen vorbei.mp3 (checking marduk.dynv6...) ok
+copy Alben/2Raumwohnung - Es wird Morgen/2Raumwohnung - 02 - Spiel mit.mp3 (checking marduk.dynv6...) ok
+[... canceled]
+```
+Why is copy --auto copying these (presumably all) files here=
+
+Thanks!
+Florian
diff --git a/doc/forum/copy_--auto_copies_already_synced_files/comment_1_cc5e2e7630a33b73d1eb92eebe254cea._comment b/doc/forum/copy_--auto_copies_already_synced_files/comment_1_cc5e2e7630a33b73d1eb92eebe254cea._comment
new file mode 100644
index 0000000000..ae3b461513
--- /dev/null
+++ b/doc/forum/copy_--auto_copies_already_synced_files/comment_1_cc5e2e7630a33b73d1eb92eebe254cea._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Horus"
+ subject="comment 1"
+ date="2016-07-14T09:28:32Z"
+ content="""
+Addendum: It seems it is not really copying the files, but checking. The solution is probably using ```git annex copy --to=marduk.dynv6 --auto --fast``` which behaves like I expect it (copies nothing).
+"""]]
diff --git a/doc/forum/copy_--auto_copies_already_synced_files/comment_2_3cfd11d8199a4d5e442d207a1edb38e0._comment b/doc/forum/copy_--auto_copies_already_synced_files/comment_2_3cfd11d8199a4d5e442d207a1edb38e0._comment
new file mode 100644
index 0000000000..5fe0b215de
--- /dev/null
+++ b/doc/forum/copy_--auto_copies_already_synced_files/comment_2_3cfd11d8199a4d5e442d207a1edb38e0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-07-19T16:57:59Z"
+ content="""
+Right, it's checking if the file content is still present on the remote.
+Since that can take a while, or even lead to a ssh password prompt etc,
+it prints out the name of each file as it checks it. 
+
+--fast avoids that check, which is fine. I have gone back and forth on
+making --fast the default in this sitation.
+"""]]
diff --git a/doc/forum/copy_and_move__63__.mdwn b/doc/forum/copy_and_move__63__.mdwn
new file mode 100644
index 0000000000..88ce775034
--- /dev/null
+++ b/doc/forum/copy_and_move__63__.mdwn
@@ -0,0 +1,19 @@
+My use case is that I [import media](http://ix.io/h6m) from my iphone/gopro to my laptop. I then want to upload them to [Flickr](https://www.flickr.com/) (JPG/PNG) and S3 (MP4). However I want to keep a backup using git-annex onto a external USB drive.
+
+# How do I quickly copy and drop?
+
+I realise I can:
+
+1. git-annex add 2014-*
+* git-annex copy --to 2tbusbdrive
+* git-annex drop 2014-*
+
+But that's several steps. Is there a quicker way?
+
+# How do drop only files I've actually uploaded?
+
+In the past, I've just marked files as uploaded by `touch "$media.uploaded"` once my python Flickr script returns a successful error code. But I have no idea how to tell git-annex that this means the file can now be dropped, providing a copy exists on my **2tbusbdrive**.
+
+# Furthermore keeping a clean deck
+
+Tbh I don't want the old upload files/directories cluttering up my _uploadme_ directory. Can I just delete them or configure drop to remove the filename too?
diff --git a/doc/forum/copy_and_move__63__/comment_1_a24b1ab4608fcf8129c9890a5ae9e943._comment b/doc/forum/copy_and_move__63__/comment_1_a24b1ab4608fcf8129c9890a5ae9e943._comment
new file mode 100644
index 0000000000..3af1a21cee
--- /dev/null
+++ b/doc/forum/copy_and_move__63__/comment_1_a24b1ab4608fcf8129c9890a5ae9e943._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""the obvious answer"""
+ date="2015-03-26T15:17:05Z"
+ content="""
+`git annex move file --to remote`
+"""]]
diff --git a/doc/forum/copy_symlinks.mdwn b/doc/forum/copy_symlinks.mdwn
new file mode 100644
index 0000000000..5f74994742
--- /dev/null
+++ b/doc/forum/copy_symlinks.mdwn
@@ -0,0 +1,11 @@
+Hi,
+
+I'm always confused when I try to copy a file within an annex repository. I know that I can just copy the symlink, so I don't have to move the actual data around. But what do I do with the new symlink: "git add" or "git annex add"? And what happens when I do the wrong one?
+
+Since "git annex add FILE" usually creates a symlink to FILE (and then git add on the symlink) I wonder if I'll end up with a symlink to a symlink. Would be somehow logical but pretty confusing.
+
+So I think both "git add LINK" and "git annex add LINK" should behave identical when LINK is a copy of symlink of an annexed file. However, this would still be confusing, since one would not expect that both commands behave identical in some situations but different in other situations.
+
+So, what's the best way to copy an already annexed file (destination in the same repository)?
+
+Best, Mario
diff --git a/doc/forum/copy_symlinks/comment_1_950de173a042a7671a43adbab02e0669._comment b/doc/forum/copy_symlinks/comment_1_950de173a042a7671a43adbab02e0669._comment
new file mode 100644
index 0000000000..7350464a53
--- /dev/null
+++ b/doc/forum/copy_symlinks/comment_1_950de173a042a7671a43adbab02e0669._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2019-04-15T07:34:21Z"
+ content="""
+`git add` and `git annex add` do both behave the same on symlinks (at least, in indirect annexes).
+
+They are just staged (then fixed on commit, if required).
+"""]]
diff --git a/doc/forum/copy_symlinks/comment_2_198f3e9db08ebcdb7ec36b76cc1d9473._comment b/doc/forum/copy_symlinks/comment_2_198f3e9db08ebcdb7ec36b76cc1d9473._comment
new file mode 100644
index 0000000000..859c1ae2e9
--- /dev/null
+++ b/doc/forum/copy_symlinks/comment_2_198f3e9db08ebcdb7ec36b76cc1d9473._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="Thanks"
+ date="2019-04-16T11:07:10Z"
+ content="""
+Great, thanks for the confirmation.
+"""]]
diff --git a/doc/forum/copying_annex_between_remotes_manually__63__.mdwn b/doc/forum/copying_annex_between_remotes_manually__63__.mdwn
new file mode 100644
index 0000000000..6e3fc6d7a6
--- /dev/null
+++ b/doc/forum/copying_annex_between_remotes_manually__63__.mdwn
@@ -0,0 +1,5 @@
+I'm currently trying to migrate a git-annex repository to a new machine, one of whose remotes is the one from [this issue](https://git-annex.branchable.com/bugs/apparent_hang_in_git-annex-smudge/). I determined that the root cause there seemed to be under git rather than git-annex; in particular, any whole-repository operation would take multiple days to execute, for unclear reasons. Pulling the commit data to a new repository seems to fix this.
+
+I'm now trying to move all the annexed data from the original, broken remote to the new one. The default option here would be `git annex move`. However, when I run this, it apparently does some git operation for every key moved, taking hours to days; there are tens of thousands of keys, so this is obviously unworkable.
+
+Is there a way to simply mass-move the annexed data into the new repo, via rsync or similar, and then update the new repo's metadata all at once? The state of the old repository does not matter, since I intend to discard it as soon as this migration is done.
diff --git a/doc/forum/copying_annex_between_remotes_manually__63__/comment_1_c13a0cded3a5fee06106f101f122eb33._comment b/doc/forum/copying_annex_between_remotes_manually__63__/comment_1_c13a0cded3a5fee06106f101f122eb33._comment
new file mode 100644
index 0000000000..ca7ba701a9
--- /dev/null
+++ b/doc/forum/copying_annex_between_remotes_manually__63__/comment_1_c13a0cded3a5fee06106f101f122eb33._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="lell"
+ avatar="http://cdn.libravatar.org/avatar/4c4138a71d069e290240a3a12367fabe"
+ subject="Using fsck is an option?"
+ date="2024-02-22T07:47:36Z"
+ content="""
+Hi, this worked for me:
+
+```
+~$ mkdir ~/test/gta
+~$ cd ~/test/gta
+~/test/gta$ git init
+
+Initialized empty Git repository in /home/lell/test/gta/.git/
+
+~/test/gta$ git annex init
+~/test/gta$ git annex add file
+~/test/gta$ git commit -m test
+
+~/test/gta$ cd ..
+~/test$ git clone a b
+
+~/test$ cd gta/
+~/test/gta$ cd ..
+~/test$ git clone gta gta2
+~/test$ cd gta2
+
+~/test/gta2$ mkdir .git/annex/objects
+~/test/gta2$ cp -r ../gta/.git/annex/objects/* .git/annex/objects/
+~/test/gta2$ cp -r ../gta/.git/annex/objects .git/annex/objects
+~/test/gta2$ git annex list   # it does not yet know that the file is now also here
+here
+|origin
+||web
+|||bittorrent
+||||
+_X__ file
+~/test/gta2$ git annex fsck
+fsck file (fixing location log) (checksum...) ok
+(recording state in git...)
+$ git annex list   # now it knows
+here
+|origin
+||web
+|||bittorrent
+||||
+XX__ file
+```
+
+"""]]
diff --git a/doc/forum/copying_annex_between_remotes_manually__63__/comment_2_1237297cfb596d59a48c8359d43a3928._comment b/doc/forum/copying_annex_between_remotes_manually__63__/comment_2_1237297cfb596d59a48c8359d43a3928._comment
new file mode 100644
index 0000000000..b1abc59cc4
--- /dev/null
+++ b/doc/forum/copying_annex_between_remotes_manually__63__/comment_2_1237297cfb596d59a48c8359d43a3928._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="lell"
+ avatar="http://cdn.libravatar.org/avatar/4c4138a71d069e290240a3a12367fabe"
+ subject="comment 2"
+ date="2024-02-22T07:49:58Z"
+ content="""
+In the example above, of course I forgot one line that creates the file \"file\"  in the repository gta, e.g. like this `echo test > file`
+"""]]
diff --git a/doc/forum/copying_annex_between_remotes_manually__63__/comment_3_875474a913d23823e3866cca27cfa3ac._comment b/doc/forum/copying_annex_between_remotes_manually__63__/comment_3_875474a913d23823e3866cca27cfa3ac._comment
new file mode 100644
index 0000000000..19fff278ac
--- /dev/null
+++ b/doc/forum/copying_annex_between_remotes_manually__63__/comment_3_875474a913d23823e3866cca27cfa3ac._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="unqueued"
+ avatar="http://cdn.libravatar.org/avatar/3bcbe0c9e9825637ad7efa70f458640d"
+ subject="comment 3"
+ date="2024-04-10T12:46:53Z"
+ content="""
+I would just clone the repo to the new machine, do `git annex init`, and then rsync the contents of `.git/annex/objects`, and then do `git annex fsck --all` to have to recheck every key it knows about.
+
+Alternatively, if you're concerned that there might be keys that weren't properly recorded somehow, in your new repo, after `.git/annex/objects` has been transferred, you can create an ingestion directory with a flat layout of the copied keys:
+
+```bash
+mkdir ingest && find .git/annex/objects -type f | xargs mv ingest && git annex reinject --known ingest/*
+```
+
+Finally, if you just want to rebuild it from scratch, do cp with the `-cL` option. If you are on macOS, it will make a reflink copy, and follow the symlinks. Delete the target .git dir and re-create it.
+"""]]
diff --git a/doc/forum/correct_way_to_add_two_preexisting_datasets.mdwn b/doc/forum/correct_way_to_add_two_preexisting_datasets.mdwn
new file mode 100644
index 0000000000..bfc1a62721
--- /dev/null
+++ b/doc/forum/correct_way_to_add_two_preexisting_datasets.mdwn
@@ -0,0 +1,25 @@
+I've been syncronizing my data since long time, mainly using rsync or unison. Thus I had two 3.5Gb datasets set1 (usb drive, hfs+ partition) and set2 (hdd, ext4 ubuntu 13.04 box) which differed only in 50Mb (new on set1 ). This was double checked using diff -r before doing anything.
+
+I created a git annex repo in direct mode for set2 from command line, and after that I let the assistant scan it.
+After that created the repo for set1 and added it to the assistant. I think here comes my mistake (I think).
+
+Instead of keeping them apart, at told assistant to sync with set2.
+Why I think this was a mistake? Because set2 was indexed and set1 no, and I'm seeing a lot of file moving a copying, which in my humble opinion should not happen.
+What I expected it only the difference to be transferred from set1 to set2.
+What it seems to be doing is moving away all content in set1, and copying it back from set2. I think it will end correctly, but with a lot of unnecessary and risky operations.
+
+I think I should have independently added both datasets, let them be scanned and then connect to each other.
+So, now the questions:
+
+1. Is that the correct way to proceed?
+2. What if I have to identical files with different modifying times, I hope they are not synced, right?
+3. Is it posssible to achieve this behaviour of copying only the 50Mb?
+
+Thanks in advance and keep up the good work.
+Best regards,
+             Juan
+
+EDIT: a couple of questions more:
+
+4. after finishing, set2 ended with a lot of symlinks but only in one subfolder. To prevent this should I put numcopies in 2?
+5. This data is composed of input datasets and output simulations. Thus, I need to change them often, but not as often as code and in a very partial way (chunks of 50Mb). For me direct mode is the best (or plain git). However, I was wondering, it is possible to drop some files (even in direct mode) and use simlinks instead?
diff --git a/doc/forum/correct_way_to_add_two_preexisting_datasets/comment_1_c5c3ff25c9f5e34db222b5f4ae58b093._comment b/doc/forum/correct_way_to_add_two_preexisting_datasets/comment_1_c5c3ff25c9f5e34db222b5f4ae58b093._comment
new file mode 100644
index 0000000000..13e2a58d2b
--- /dev/null
+++ b/doc/forum/correct_way_to_add_two_preexisting_datasets/comment_1_c5c3ff25c9f5e34db222b5f4ae58b093._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 1"
+ date="2013-08-23T16:17:58Z"
+ content="""
+I did something similar for my videos, I've created the repo on one machine add the video files then cloned it on the other machine then reinjected the files in to the cloned repo.
+
+http://joeyh.name/blog/entry/moving_my_email_archives_and_packages_to_git-annex/
+"""]]
diff --git a/doc/forum/correct_way_to_add_two_preexisting_datasets/comment_2_ee3ecc86990ac5a8d0c4fdfb482a7594._comment b/doc/forum/correct_way_to_add_two_preexisting_datasets/comment_2_ee3ecc86990ac5a8d0c4fdfb482a7594._comment
new file mode 100644
index 0000000000..d1e259afd9
--- /dev/null
+++ b/doc/forum/correct_way_to_add_two_preexisting_datasets/comment_2_ee3ecc86990ac5a8d0c4fdfb482a7594._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 2"
+ date="2013-08-23T18:23:52Z"
+ content="""
+If you need to preserve mtimes, or differentiate between files with identical content but different mtimes, neither git nor git-annex is going to do what you want, since git doesn't care about preserving much file metadata.
+
+As far as importing two sets of files on two computers, the best thing to do is import each, and then let the two sync up. Otherwise, when you're running the assistant it will start downloading the first set you import to the second computer, before the second set is added there, and do extra work. Although once the duplicate files from the second set land in the second git repository, the assistant will avoid any additional redundant transfers.
+
+(The assistant never *moves* files, if both repositories are configured to be in the default client repository group. It only copies.)
+
+I don't understand question #1. \"set2 ended with a lot of symlinks but only in one subfolder\" doesn't make sense to me, or rather I could interpret it to mean any of dozen things (none of which seem likely)
+
+You can `git annex drop` files in direct mode. However, if you're running the assistant, it will try to get them back. You can configure your repository to be in manual mode to prevent the assistant doing that, or not use the assistant, or configure a [[preferred_content]] expression to make the assistant do something more custom like not try to get files located in a \"olddata\" directory.
+"""]]
diff --git a/doc/forum/correct_way_to_add_two_preexisting_datasets/comment_3_e29bf8b848da04c761dc601ac979ac14._comment b/doc/forum/correct_way_to_add_two_preexisting_datasets/comment_3_e29bf8b848da04c761dc601ac979ac14._comment
new file mode 100644
index 0000000000..d750e9581a
--- /dev/null
+++ b/doc/forum/correct_way_to_add_two_preexisting_datasets/comment_3_e29bf8b848da04c761dc601ac979ac14._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmTNrhkVQ26GBLaLD5-zNuEiR8syTj4mI8"
+ nickname="Juan"
+ subject="comment 3"
+ date="2013-08-25T13:00:04Z"
+ content="""
+Thanks. It is very clear now. I think I got it running. I have 2 direct mode copies in my ubuntu box and in the USB drive and one indirect in my ultrabook (small SSD).
+What I meant is that even in direct mode, after sync ended, the set I indexed first ended with the contents of a folder in the .git dir using symlinks. But it might have been a leftover of previous attempts.
+I think I got confused by the great amount of flexibility it provides.
+Thanks.
+"""]]
diff --git a/doc/forum/could_not_read_from_remote_repository.mdwn b/doc/forum/could_not_read_from_remote_repository.mdwn
new file mode 100644
index 0000000000..6103bfd36f
--- /dev/null
+++ b/doc/forum/could_not_read_from_remote_repository.mdwn
@@ -0,0 +1,36 @@
+hi, i'm trying to set up my notebook and desktop pc to sync my documents. so i used local computers in the web app as a sync option, but on my notebook i get the following error:
+
+    [2013-11-26 11:29:03 CET] main: Pairing in progress
+    X11 forwarding request failed
+    /home/max/.ssh/git-annex-shell: line 4: exec: git-annex-shell: not found
+    X11 forwarding request failed on channel 0
+    /home/max/.ssh/git-annex-shell: line 4: exec: git-annex-shell: not found
+    fatal: Could not read from remote repository.
+    
+    Please make sure you have the correct access rights
+    and the repository exists.
+    [2013-11-26 11:29:31 CET] PairListener: Syncing with desk_Private_Dokumente 
+    X11 forwarding request failed on channel 0
+    /home/max/.ssh/git-annex-shell: line 4: exec: git-annex-shell: not found
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+
+    merge: refs/remotes/desk_Private_Dokumente/master - not something we can merge
+
+    merge: refs/remotes/desk_Private_Dokumente/synced/master - not something we can merge
+    X11 forwarding request failed
+    /home/max/.ssh/git-annex-shell: line 4: exec: git-annex-shell: not found
+    X11 forwarding request failed on channel 0
+    /home/max/.ssh/git-annex-shell: line 4: exec: git-annex-shell: not found
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+
+my desktop succeeded in adding the repository. 
+
+any idea whats going wrong ?
+
+thanks
diff --git a/doc/forum/could_not_read_from_remote_repository/comment_1_27d4d1556a80c06505ed3d8a9422d082._comment b/doc/forum/could_not_read_from_remote_repository/comment_1_27d4d1556a80c06505ed3d8a9422d082._comment
new file mode 100644
index 0000000000..aaf0946931
--- /dev/null
+++ b/doc/forum/could_not_read_from_remote_repository/comment_1_27d4d1556a80c06505ed3d8a9422d082._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 1"
+ date="2013-11-26T20:18:26Z"
+ content="""
+The problem seems to be on your desktop computer. /home/max/.ssh/git-annex-shell is a script that is created if you install git-annex from the standalone tarball (assuming you're using linux?). It seems that your desktop has that script, but you must have deleted that instalation of git-annex (perhaps you switched to installing it some other way), so the script doesn't work. As long as you have git-annex-shell in your PATH somehow, you can just remove /home/max/.ssh/git-annex-shell
+"""]]
diff --git a/doc/forum/could_not_read_from_remote_repository/comment_2_cf7d5e231675921c3d98faab3613c92f._comment b/doc/forum/could_not_read_from_remote_repository/comment_2_cf7d5e231675921c3d98faab3613c92f._comment
new file mode 100644
index 0000000000..6775d9278d
--- /dev/null
+++ b/doc/forum/could_not_read_from_remote_repository/comment_2_cf7d5e231675921c3d98faab3613c92f._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnX1msQxnLoSeu7q-i-c9BWghonsN7Qmns"
+ nickname="Jan Ulrich"
+ subject="Same error after deleting .ssh/git-annex-shell"
+ date="2014-06-11T15:53:17Z"
+ content="""
+Hi,
+
+I get the error before and after I deleted .ssh/git-annex-shell on my Ubuntu desktop:
+
+    janulrimacbook2:Movies juh$ git annex sync
+    commit  ok
+    pull sokrates.local_Videos
+    bash: /home/juh/.ssh/git-annex-shell: Datei oder Verzeichnis nicht gefunden
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+    failed  
+    push sokrates.local_Videos
+    bash: /home/juh/.ssh/git-annex-shell: Datei oder Verzeichnis nicht gefunden 
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+
+      Pushing to sokrates.local_Videos failed.
+
+       (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
+    failed
+    git-annex: sync: 2 failed
+
+Git-annex version on macbook:
+
+    git-annex version: 5.20140605-gc2add53
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+Git-annex version on Ubuntu desktop:
+
+    git-annex version: 5.20140517
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+"""]]
diff --git a/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__.mdwn b/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__.mdwn
new file mode 100644
index 0000000000..37d3b6fb4e
--- /dev/null
+++ b/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__.mdwn
@@ -0,0 +1,2 @@
+I'd like to do something like git-annex-addurl, except the URL is not a web address but a domain-specific identifier.  Specifically, on the DNAnexus platform, each file is assigned an immutable ID like file-asdf432fdsa.   I want to configure git-annex so that it knows it can fetch the file using a specific command (not curl but 'dx download file-asdf432fdsa'); and so that it completely trusts that the file can always be fetched this way.  What would be the right combination of configurations/settings to make this work?  I was thinking of some combination of WORM backend configured just for DNAnexus files and a special remote, but not sure (this "special remote" would only support copying files from it, not to it; so it's more like "special web").
+Thanks for any suggestions!
diff --git a/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_1_55c2a5c932ccc5a2a49a54239cfba139._comment b/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_1_55c2a5c932ccc5a2a49a54239cfba139._comment
new file mode 100644
index 0000000000..8fdbba043d
--- /dev/null
+++ b/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_1_55c2a5c932ccc5a2a49a54239cfba139._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-09-11T16:56:14Z"
+ content="""
+What you're looking for is the [[design/external_special_remote_protocol]].
+When you build your own special remote using that protocol,
+it can use SETSTATE and GETSTATE to store and retrieve
+the immutable IDs.
+
+It should not be hard to write your own special remote. See
+[[this page|special_remotes/external]].
+
+The Datalad project has a bunch of special remotes doing things like this
+BTW.
+"""]]
diff --git a/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_2_db80224d61ca549557af558e9a5f099a._comment b/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_2_db80224d61ca549557af558e9a5f099a._comment
new file mode 100644
index 0000000000..8f35da21e8
--- /dev/null
+++ b/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_2_db80224d61ca549557af558e9a5f099a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2018-09-12T19:10:46Z"
+ content="""
+Maybe remote.<name>.annex-speculate-present could support being set to a regexp, such that all URLs matching the regexp would be speculated-present in the remote, rather than all URLs?  Then could say that all URLs of the form dx://file-xxxxxx should be speculated present in the DNAnexus remote.
+"""]]
diff --git a/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_3_8b69aa113bc35a042c90beddf8b0f3a9._comment b/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_3_8b69aa113bc35a042c90beddf8b0f3a9._comment
new file mode 100644
index 0000000000..2ef0700ee8
--- /dev/null
+++ b/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_3_8b69aa113bc35a042c90beddf8b0f3a9._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-09-12T19:26:31Z"
+ content="""
+annex-speculate-present is a boolean setting, I see that the docs didn't
+make that clear and have improved them.
+
+I don't see any value in speculating that urls are present in some specific
+remote; there's already sufficient support for remotes to register and
+claim urls. 
+
+See CLAIMURL in the external special remote protocol.
+The ipfs special remote is an example of a a remote that uses CLAIMURL to
+add support for a new type of url to git-annex.
+<https://git-annex.branchable.com/special_remotes/external/git-annex-remote-ipfs>
+"""]]
diff --git a/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_4_94e2fbb04c553b2c8c7992541e634017._comment b/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_4_94e2fbb04c553b2c8c7992541e634017._comment
new file mode 100644
index 0000000000..897569c5c9
--- /dev/null
+++ b/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_4_94e2fbb04c553b2c8c7992541e634017._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2018-09-12T19:33:04Z"
+ content="""
+If I run 'git-annex addurl dx://file-xxxxx', won't git-annex just try calling curl to fetch the URL, instead of querying special remotes?
+I guess I can add my own curl wrapper to the front of PATH, but that feels somewhat hacky.
+
+"""]]
diff --git a/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_5_33a833e1037df7ce0fa55876e4154250._comment b/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_5_33a833e1037df7ce0fa55876e4154250._comment
new file mode 100644
index 0000000000..c3522bffe1
--- /dev/null
+++ b/doc/forum/custom_URLs___40__use_case__58___dnanexus__41__/comment_5_33a833e1037df7ce0fa55876e4154250._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-10-04T19:28:32Z"
+ content="""
+No, as I mentioned upthread, git-annex supports external special remotes
+claiming urls.
+"""]]
diff --git a/doc/forum/dangling_blobs.mdwn b/doc/forum/dangling_blobs.mdwn
new file mode 100644
index 0000000000..dc3cfbd78d
--- /dev/null
+++ b/doc/forum/dangling_blobs.mdwn
@@ -0,0 +1,27 @@
+Revisiting an issue I reported a couple of months ago but never figured out. I am trying to use git annex assistant on two separate machines to automatically mirror files between them. But after I start the second assistant and add new files to the annex, I find that git fsck reports dangling blobs. Is there a conflict between the two assistants?
+
+On the server:
+
+    $ mkdir ~/annex
+    $ cd ~/annex
+    $ git init
+    $ git annex init u --version=6
+    $ echo This is test file 1. >testfile1.txt
+    $ git annex add testfile1.txt
+    $ git annex sync
+    $ git remote add ml2 ssh://laptop/Users/username/annex
+    $ git annex assistant
+
+After all that, I do this on the laptop:
+
+    $ cd ~/
+    $ git clone ssh://server/home/username/annex
+    $ cd annex
+    $ git annex init ml2 --version=6
+    $ git annex sync
+    $ git annex assistant
+
+At this point git fsck is happy. But when I add files to the annex on either machine and run git fsck, I get messages like:
+
+    Checking object directories: 100% (256/256), done.
+    dangling blob 31a30177d1e37faf8eac96524302a61713d3d522
diff --git a/doc/forum/dangling_blobs/comment_1_120681851a595909e19afcc0334383ec._comment b/doc/forum/dangling_blobs/comment_1_120681851a595909e19afcc0334383ec._comment
new file mode 100644
index 0000000000..df086c0b2c
--- /dev/null
+++ b/doc/forum/dangling_blobs/comment_1_120681851a595909e19afcc0334383ec._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-17T16:33:02Z"
+ content="""
+This message from git fsck does not indicate any kind of serious problem
+with the repository.
+
+A dangling blob can be added to a git repository when something gets
+staged but is then never included in a commit. For example, with the
+assistant, if a file is created, and then modified soon after, the
+original version would get staged, but before it was committed, the
+new version staged and included in the commit. 
+
+There are several other scenarios, involving the assistant and not, where
+that could happen.
+
+So, git is telling you that the git repository contains
+information that's not being used. Unless you are low on disk
+space this probably doesn't matter, and git will automatically
+clean up dangling blobs after a while (or see `git gc`).
+"""]]
diff --git a/doc/forum/dbus_and_magicmime_build_flags.mdwn b/doc/forum/dbus_and_magicmime_build_flags.mdwn
new file mode 100644
index 0000000000..1d9087ff09
--- /dev/null
+++ b/doc/forum/dbus_and_magicmime_build_flags.mdwn
@@ -0,0 +1 @@
+In stack.yaml, the 'dbus' and 'magicmime' flags are off by default.  What is the reason for that?  When building e.g. conda-forge package, is there reason not to build with these flags on? @joeyh
diff --git a/doc/forum/dbus_and_magicmime_build_flags/comment_1_9d2ae829a085582c69dcf994c26f5a0c._comment b/doc/forum/dbus_and_magicmime_build_flags/comment_1_9d2ae829a085582c69dcf994c26f5a0c._comment
new file mode 100644
index 0000000000..8c4ccdefa6
--- /dev/null
+++ b/doc/forum/dbus_and_magicmime_build_flags/comment_1_9d2ae829a085582c69dcf994c26f5a0c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-09-18T16:56:58Z"
+ content="""
+(Argh, this question fell into my backlog unnoticed!)
+
+These build flags depend on C libraries and stack can't install C libraries
+so enabling them would make the stack build not succeed on all systems.
+The build does #warn about features that are not enabled when building with
+the flags turned off.
+
+If you're able to install libdbus and libmagic, you should, and turn the
+build flags on.
+"""]]
diff --git a/doc/forum/dbus_and_magicmime_build_flags/comment_2_5421641e133cdadd0be5587b882ed3e5._comment b/doc/forum/dbus_and_magicmime_build_flags/comment_2_5421641e133cdadd0be5587b882ed3e5._comment
new file mode 100644
index 0000000000..eaaecee7c6
--- /dev/null
+++ b/doc/forum/dbus_and_magicmime_build_flags/comment_2_5421641e133cdadd0be5587b882ed3e5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-09-18T20:16:26Z"
+ content="""
+That's what I thought, just checking.  The [[conda install|install/conda]] builds with these flags on.
+"""]]
diff --git a/doc/forum/default_repo_version_is_still_5__63__.mdwn b/doc/forum/default_repo_version_is_still_5__63__.mdwn
new file mode 100644
index 0000000000..f7d7e9a997
--- /dev/null
+++ b/doc/forum/default_repo_version_is_still_5__63__.mdwn
@@ -0,0 +1 @@
+git-annex version: 6.20180807-gebc1bb5 supports creating version 6 repos, but by default creates version 5.  Are version 6 repos still in beta / not reliable?
diff --git a/doc/forum/default_repo_version_is_still_5__63__/comment_1_5f63f10cf79ef8ca33214ceaefd1271e._comment b/doc/forum/default_repo_version_is_still_5__63__/comment_1_5f63f10cf79ef8ca33214ceaefd1271e._comment
new file mode 100644
index 0000000000..7164e824df
--- /dev/null
+++ b/doc/forum/default_repo_version_is_still_5__63__/comment_1_5f63f10cf79ef8ca33214ceaefd1271e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-09-11T17:14:04Z"
+ content="""
+That's right, see [[todo/smudge]] for the current status of v6.
+There are known issues, it's been improved a lot in unreleated git-annex
+but even then, still known issues including memory leaks in git.
+"""]]
diff --git a/doc/forum/deploy.mdwn b/doc/forum/deploy.mdwn
new file mode 100644
index 0000000000..b9e0974122
--- /dev/null
+++ b/doc/forum/deploy.mdwn
@@ -0,0 +1,5 @@
+Greetings,
+
+I use the push-to-deploy pattern (as described in 4.1 http://gitolite.com/deploy.html). However, my git repo has large binary files that I'd like to annex. Is there an example of using git annex with a bare remote repository with the appropriate post-receive hook to accomplish the deploy?
+
+Thanks
diff --git a/doc/forum/deploy/comment_1_bd9855cc19f0f49620258564845f1f77._comment b/doc/forum/deploy/comment_1_bd9855cc19f0f49620258564845f1f77._comment
new file mode 100644
index 0000000000..1f4732b8df
--- /dev/null
+++ b/doc/forum/deploy/comment_1_bd9855cc19f0f49620258564845f1f77._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-05-11T17:13:35Z"
+ content="""
+I'm not sure that a bare repository is the best way to go about it.
+
+One way to do it is to have a non-bare repository, which gets updated when
+you push (by eg setting receive.denyNonFastforwards=false), and have that
+non-bare repository be the one you push to deploy to.
+
+While you could push first to a bare repository and have it then push on
+the the non-bare repository, that seems to mostly only complicate things,
+since you will need to find a way to copy the annexed file contents from
+the bare to the non-bare repository.
+"""]]
diff --git a/doc/forum/dev_machine_-__62___NAS_-__62___cloud.mdwn b/doc/forum/dev_machine_-__62___NAS_-__62___cloud.mdwn
new file mode 100644
index 0000000000..5fbec8173b
--- /dev/null
+++ b/doc/forum/dev_machine_-__62___NAS_-__62___cloud.mdwn
@@ -0,0 +1,7 @@
+I have a setup right now with a dev machine, a local NAS drive, and offsite cloud storage. I want annex content to flow that way: so I `git annex sync nas` from my dev box, then I SSH into the NAS and `git annex sync cloud`. It's this last part that I want to automate - I want to make sure that any content I sync to NAS, gets synced from NAS to cloud. I don't want my dev machine uploading directly to cloud unless I explicitly set that.
+
+Apparently I can't run assistant in a bare repository, which is what's on NAS. And, I'm not even sure assistant is the right thing, I think maybe it does more than just sync content.
+
+What's a good way to set this up so that when NAS receives `annex sync` content, it immediately does its own `annex sync` to cloud remote?
+
+One thing I can think of is set up a `update` / `post-receive` hook to touch a file on the NAS. Then have a cron job check for the file, and if it's there, start a cloud sync.
diff --git a/doc/forum/dev_machine_-__62___NAS_-__62___cloud/comment_1_f77818a766f2b41d13ced2bcf4447de0._comment b/doc/forum/dev_machine_-__62___NAS_-__62___cloud/comment_1_f77818a766f2b41d13ced2bcf4447de0._comment
new file mode 100644
index 0000000000..b33329dbd1
--- /dev/null
+++ b/doc/forum/dev_machine_-__62___NAS_-__62___cloud/comment_1_f77818a766f2b41d13ced2bcf4447de0._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-05-02T08:03:56Z"
+ content="""
+I guess you could just put something like this in your crontab:
+`*/5 * * * * cd /path/to/repo; flock -n .git/periodic-sync.lock git annex sync --content --all`
+
+As a optimization, you could only sync with `--content --all` if the git-annex branch changed since the last time it ran.
+"""]]
diff --git a/doc/forum/differenc_in_webapp_icons__63__.mdwn b/doc/forum/differenc_in_webapp_icons__63__.mdwn
new file mode 100644
index 0000000000..3b4f355a1d
--- /dev/null
+++ b/doc/forum/differenc_in_webapp_icons__63__.mdwn
@@ -0,0 +1,4 @@
+Hi,
+
+I'm wondering what the difference between the network signal and network sync icons are in the web-app?  Nothing stands out to me why some repos have one some the other?
+
diff --git a/doc/forum/differenc_in_webapp_icons__63__/comment_1_c38e2692b13a1b76777bf88312a03966._comment b/doc/forum/differenc_in_webapp_icons__63__/comment_1_c38e2692b13a1b76777bf88312a03966._comment
new file mode 100644
index 0000000000..69777eaff9
--- /dev/null
+++ b/doc/forum/differenc_in_webapp_icons__63__/comment_1_c38e2692b13a1b76777bf88312a03966._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.114"
+ subject="comment 1"
+ date="2014-04-26T23:03:46Z"
+ content="""
+The signal icon shows when there's a direct connection to another repositoriry. This leats your repository immediately learn when there is a change, triggering a sync. Without any signal icons, there's no fast syncing when changes are made, so the webapp will prompt for you to set up such a connection.
+"""]]
diff --git a/doc/forum/difference_between_full_backup_and_number_of_copies__63__.mdwn b/doc/forum/difference_between_full_backup_and_number_of_copies__63__.mdwn
new file mode 100644
index 0000000000..4223a2ded7
--- /dev/null
+++ b/doc/forum/difference_between_full_backup_and_number_of_copies__63__.mdwn
@@ -0,0 +1,9 @@
+If I have three repositories setup in the git annex webui as:
+
+full backup,
+
+and every file put into one of the repos seems to be propagated to the other two,
+
+what is the usage of the setting "number of copies" which is default to 1 but can be increased to 2 or 3? Does this setting matter in this context?
+
+I'm using assistant version 5.20140517.4
diff --git a/doc/forum/difference_between_full_backup_and_number_of_copies__63__/comment_1_df1850059a7a3006db7cb5c588dac3d7._comment b/doc/forum/difference_between_full_backup_and_number_of_copies__63__/comment_1_df1850059a7a3006db7cb5c588dac3d7._comment
new file mode 100644
index 0000000000..e58f5402b9
--- /dev/null
+++ b/doc/forum/difference_between_full_backup_and_number_of_copies__63__/comment_1_df1850059a7a3006db7cb5c588dac3d7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm8wY171R5c4u_jPmB6LU6n6Px2xePM4sE"
+ nickname="Efraim"
+ subject="comment 1"
+ date="2014-08-31T07:09:52Z"
+ content="""
+number of copies is the minimum number of copies that can exist when you try to drop a file from a repository/without git-annex telling you that you don't have enough copies and should protect your data better.  A full backup by default tries to get every file it can get its hands on, including old versions.
+"""]]
diff --git a/doc/forum/difference_between_uninit_and_unlock.mdwn b/doc/forum/difference_between_uninit_and_unlock.mdwn
new file mode 100644
index 0000000000..6f4d6def2e
--- /dev/null
+++ b/doc/forum/difference_between_uninit_and_unlock.mdwn
@@ -0,0 +1,10 @@
+What's the difference between
+
+    git annex uninit
+
+and 
+
+    git annex unlock *
+    rm -rf .git
+
+?
diff --git a/doc/forum/difference_between_uninit_and_unlock/comment_1_6b89cffc10650c087dbbfbdd3e099b5f._comment b/doc/forum/difference_between_uninit_and_unlock/comment_1_6b89cffc10650c087dbbfbdd3e099b5f._comment
new file mode 100644
index 0000000000..4db07242df
--- /dev/null
+++ b/doc/forum/difference_between_uninit_and_unlock/comment_1_6b89cffc10650c087dbbfbdd3e099b5f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-03T18:51:22Z"
+ content="""
+In a v5 repo in indirect mode, they're broadly equivilant.
+
+`git annex uninit` removes git config changes and hooks that `git annex
+init` sets up, and generally hand-holds the process.
+"""]]
diff --git a/doc/forum/distributed_borg.mdwn b/doc/forum/distributed_borg.mdwn
new file mode 100644
index 0000000000..e43d616390
--- /dev/null
+++ b/doc/forum/distributed_borg.mdwn
@@ -0,0 +1,37 @@
+The Borg special remote is indeed an exciting next step for this amazing
+project. I’m currently testing it with a small team. For remote collaboration,
+each of us has provisioned:
+
+- one workstation with a git-annex repo (accessible only to the workstation user)
+- one server (NAS) with a Borg repo (accessible to all team members)
+
+The idea was to implement a basic distributed topology by adding all the Borg
+repos as special remotes to all the git-annex repos. With such an implementation,
+a typical workflow would be:
+
+1. A team member:
+  **(a)** commits a change to the git-annex repo on the member’s own workstation,
+  **(b)** creates an archive of the updated git-annex repo in each of the Borg
+repos, and
+  **(c)** informs the member’s own git-annex repo of the new Borg archives by running `git annex sync`.
+2. All other team members inform their respective git-annex repos of the new
+Borg archives by simply running `git annex sync`.
+
+Step 1 worked, but Step 2 did not, so as a workaround, we added a bare
+git-annex repo alongside the Borg repo on each server, then added all the new
+bare repos as remotes to each of our respective workstation repos. It works
+but is less than ideal.
+
+My simplified question: can two git-annex repos share a Borg special remote?
+
+Joey commented back in December: “The Remote interface recently got
+importKey, which gets us unexpectedly a lot closer to making git-annex import
+--from borg a reality!” However, I’ve struggled to find any other clues.
+
+Potentially related issues (all of which appear to have been addressed):
+
+- [sync --content with borg does not get content](https://git-annex.branchable.com/todo/sync_--content_with_borg_does_not_get_content/)
+- [borg sync tree not grafted](https://git-annex.branchable.com/todo/borg_sync_tree_not_grafted/)
+- [use same vector clock for content identifier updates in import](https://git-annex.branchable.com/todo/use_same_vector_clock_for_content_identifier_updates_in_import/)
+
+Thanks!
diff --git a/doc/forum/distributed_borg/comment_1_133d5adb83e9df38c513e17d128486d1._comment b/doc/forum/distributed_borg/comment_1_133d5adb83e9df38c513e17d128486d1._comment
new file mode 100644
index 0000000000..f36a11245b
--- /dev/null
+++ b/doc/forum/distributed_borg/comment_1_133d5adb83e9df38c513e17d128486d1._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-05-27T16:08:07Z"
+ content="""
+This should be possible to set up. This is just a special remote that is
+accessible from several clones of the repository, and git-annex is able to
+get files that were sent from another clone to the special remote, once the
+git-annex branch gets synced between the two clones.
+
+You have to use `git annex initremote` a single time to set up the borg
+special remote, and then use `git annex enableremote` on every other clone
+to access it. Since initremote borg needs the borgrepo= parameter, which
+then gets used to access it from the other clones, it would make sense to
+use ssh user@host:path syntax, with a shared user account, or perhaps
+host:path if the permissions on the server allow multiple users to access
+the borg repo.
+"""]]
diff --git a/doc/forum/distributed_borg/comment_2_1dcf100a28991c664681d78ed4c12e39._comment b/doc/forum/distributed_borg/comment_2_1dcf100a28991c664681d78ed4c12e39._comment
new file mode 100644
index 0000000000..205e2f2b83
--- /dev/null
+++ b/doc/forum/distributed_borg/comment_2_1dcf100a28991c664681d78ed4c12e39._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="alt"
+ subject="comment 2"
+ date="2021-06-04T10:13:06Z"
+ content="""
+Leave it to the Grand Wizard himself :)
+
+With a few tweaks based on your explanation, this appears to be working smoothly. I think our issue was caused by attempting to connect repos that were individually initialized (i.e., with `git init`, `git annex init`, and `git annex initremote` on each workstation); by performing this initialization routine only on a single workstation, then following through with `git clone` and `git annex enableremote` on each additional workstation, the syncing works as expected.
+
+Thank you for your work and guidance! This is very exciting.
+
+The next thing to figure out is Borg repo mirroring to alleviate the overhead caused by Step 1(b) in the procedure above. Currently, the number of `borg create` operations each workstation must perform is multiplied by the number of Borg special remotes, which obviously doesn’t scale well. Ideally, a workstation could create an archive on a single server—say, the nearest available—offloading to the server the burden of creating archives on the remaining Borg repos. It sounds good in my head, but I struggle to find prior art for something like Borg-based swarms for eventual consistency.
+"""]]
diff --git a/doc/forum/distributed_borg/comment_3_f56ac8a714facc8aafb60d3da815021b._comment b/doc/forum/distributed_borg/comment_3_f56ac8a714facc8aafb60d3da815021b._comment
new file mode 100644
index 0000000000..c150843763
--- /dev/null
+++ b/doc/forum/distributed_borg/comment_3_f56ac8a714facc8aafb60d3da815021b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-06-04T17:53:51Z"
+ content="""
+Yeah, that's the pattern for any special remote: Initialize once and
+enableremote everywhere else. Otherwise you have a bunch of different
+special remotes that happened to be initialized more or less the same
+but git-annex doesn't know you consider them all to be the same place.
+
+I'd be keen to improve whatever docs might have led to the multiple
+initremote mistake. The man page for initremote does
+say to use enableremote in other clones. But maybe you were
+following a page like 
+[[tips/using_borg_for_efficient_storage_of_old_annexed_files]] and just
+assumed you'd follow that same procedure in each clone?
+"""]]
diff --git a/doc/forum/distributed_borg/comment_4_cf173923509ec826a1962f9a934b5a64._comment b/doc/forum/distributed_borg/comment_4_cf173923509ec826a1962f9a934b5a64._comment
new file mode 100644
index 0000000000..77599215d6
--- /dev/null
+++ b/doc/forum/distributed_borg/comment_4_cf173923509ec826a1962f9a934b5a64._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="alt"
+ subject="comment 4"
+ date="2021-06-05T13:07:47Z"
+ content="""
+Indeed, we had been following that page. Considering that a git-annex repo is stored in its entirety within a Borg archive, the explanation that “`git-annex` sync scans the borg repository to find out what annexed files are stored in it” likely led to the mistaken assumption that simply adding the special remote would be enough for git-annex to know how to handle it. (We had also tried specifying `subdir` to tell it exactly where to look but clearly were cargo culting by that point.)
+
+In retrospect, the outline of our intended implementation reveals a predisposition to make such an assumption: that the git-annex repo on each workstation would be “accessible only to the workstation user” suggests that there would be no provision for cloning in the first place. (Instead, there simply would be a bunch of repos that happened to be privately initialized more or less the same that all share a bunch of special remotes that also happened to be initialized more or less the same. Highly technical, I know!)
+
+Also, I had read the man pages, but due to Borg being an “unusual kind of remote”—a _special_ special remote, if you will—I was unsure how much of the information applied. Thus, the difference between `initremote` and `enableremote` in this case was not immediately clear.
+"""]]
diff --git a/doc/forum/do_not_use_git-annex_inside_your_Dropbox.mdwn b/doc/forum/do_not_use_git-annex_inside_your_Dropbox.mdwn
new file mode 100644
index 0000000000..2669903449
--- /dev/null
+++ b/doc/forum/do_not_use_git-annex_inside_your_Dropbox.mdwn
@@ -0,0 +1,5 @@
+Do not place git-annex enabled git repository inside your Dropbox folder! 
+
+You will encounter broken symlinks and git-annex complaining about lost files. Dropbox [doesn't preserve case of file names](https://www.dropbox.com/help/145/en) and this breaks storage of annexed files (.git/annex/objects/). For possible recovery see <http://git-annex.branchable.com/bugs/interference_with_Dropbox_results_in_data_loss>.
+
+
diff --git a/doc/forum/do_not_use_git-annex_inside_your_Dropbox/comment_1_5a1dc9da6e6861829e321446ec7991ee._comment b/doc/forum/do_not_use_git-annex_inside_your_Dropbox/comment_1_5a1dc9da6e6861829e321446ec7991ee._comment
new file mode 100644
index 0000000000..d5da4f0005
--- /dev/null
+++ b/doc/forum/do_not_use_git-annex_inside_your_Dropbox/comment_1_5a1dc9da6e6861829e321446ec7991ee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="sascha"
+ ip="2a02:8108:5c0:3ec:615a:1ac3:c7b9:a3a9"
+ subject="so how can i keep in sync a dropbox subfolder with a usbdrive"
+ date="2014-01-24T04:32:38Z"
+ content="""
+my usecase is i want to be able to be working on other computers on files that i have on my thumb-usb-drive. Back home i want to sync changes back to the subfolder of my local Dropbox-directory. Any suggestions?
+"""]]
diff --git a/doc/forum/does_git-annex_parallelize_different_remotes__63__.mdwn b/doc/forum/does_git-annex_parallelize_different_remotes__63__.mdwn
new file mode 100644
index 0000000000..a28bf37aeb
--- /dev/null
+++ b/doc/forum/does_git-annex_parallelize_different_remotes__63__.mdwn
@@ -0,0 +1,46 @@
+Hi!
+
+I'm wondering how clever git-annex is at parallelizing different
+remotes with different bandwidth. For example here I have a `origin`
+remote that is on the local LAN (so it's fast) and an `offsite-annex`
+remote that's, well, offsite, so it's much slower. If I run `git annex
+sync --content -J2`, it *looks* like it indiscriminately starts
+copying over files to either host without too much though:
+
+    $ git annex sync --content -J2
+    [...]
+    copy 2019/01/29/montreal/DSCF8148.JPG (to origin...) ok
+    copy 2019/01/29/montreal/DSCF8148.JPG (checking offsite-annex...) (to offsite-annex...) ok
+    copy 2019/01/29/montreal/DSCF8147.RAF (checking offsite-annex...) (to offsite-annex...) 
+    copy 2019/01/29/montreal/DSCF8148.RAF (to origin...) ok
+    copy 2019/01/29/montreal/DSCF8148.RAF (checking offsite-annex...) (to offsite-annex...) 
+
+The interactivity of this doesn't show well here, but what happens is
+this, in order:
+
+ 1. a first JPG is copied to origin and offsite-annex in parallel
+    (good)
+
+ 2. the origin (local) JPG transfer completes, a RAF file transfer
+    gets started to offsite-annex (not so great - a best strategy
+    would be to continue copying files to the local remote, as it's
+    fast and its bandwidth is now unused)
+
+ 3. the offsite-annex JPG transfer completes, a RAF transfer starts to
+    origin (good)
+
+ 4. that transfer completes, the same file is now copied to offsite
+    (again, not so great - local remote is now unused)
+
+What I think git-annex should be doing is try, as much as possible to
+saturate the different network links represented by the different
+remotes. In my case, files should be transfered on the local LAN as
+soon as possible: a single thread should be busy with that `origin`
+remote as long as files are missing there, while the other thread can
+slowly trickle files to `offsite`. Only when `origin` is full should
+both threads work on the `offsite` one. A simple heuristic would be
+"is there a thread already busy with that remote? if yes, see if
+another remote needs a file transfered that is not busy".
+
+Am I analysing this correctly? Is this a bug? or feature request?
+:) -- [[anarcat]]
diff --git a/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_1_764f43b51a075a8c94b433eda0cff946._comment b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_1_764f43b51a075a8c94b433eda0cff946._comment
new file mode 100644
index 0000000000..ac6947761d
--- /dev/null
+++ b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_1_764f43b51a075a8c94b433eda0cff946._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-02-07T19:29:55Z"
+ content="""
+If there are several remotes that it can use, and they all have the same
+cost, then yes, `git-annex get` will spread the load amoung them and not
+use higher cost remotes.
+So will `git-annex sync` when getting files from remotes.
+
+There is not currently any similar smart thing done when sending files to
+multiple remotes (or dropping from multiple remotes). 
+And it's kind of hard to see an efficient way to improve it. 
+
+The simplest way would be to loop over remotes ordered by cost and
+then inner loop over files, rather than the current method of looping over
+files with an inner loop over remotes. But in a large tree with many remotes,
+that has to traverse the tree multiple times, which would slow down the
+overall sync.
+
+If instead there's one thread per remote, then the slowest remote will
+fall behind the others, and there will need to be a queue of the files
+that still need to be sent to it -- and that queue could grow to use a lot
+of memory when the tree is large. There would need to be some bound
+on how far behind a thread gets before it stops adding more files and waits
+for it to catch up.
+"""]]
diff --git a/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_2_dff46561e15ba5f386dc9cecb9c88e20._comment b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_2_dff46561e15ba5f386dc9cecb9c88e20._comment
new file mode 100644
index 0000000000..66618e9ceb
--- /dev/null
+++ b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_2_dff46561e15ba5f386dc9cecb9c88e20._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="use cost then?"
+ date="2019-02-07T20:19:13Z"
+ content="""
+So I guess the answer here is to use \"cost\" to prioritize \"LAN-local\" repositories? Then we hit [[bugs/assistant_does_not_always_use_repo_cost_info_when_queueing_downloads]] but at least it will work in the general case...
+
+I think that, in my case, it means doing:
+
+    git config remote.origin.annex-cost 150
+
+... so that it's somewhere between local repositories (100) and remote (200). Would that solve my issue here? I don't have many files to transfer right now so I can't really test this until I import new photos, but I'll give it a shot! :)
+
+It would certainly be nice if git-annex was a little more clever with this - it could, for example, have a gray zone between \"remote\" and \"local\"... but I guess that's what the `annex-cost-command` is for...
+
+Thanks!
+"""]]
diff --git a/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_3_47269e2c40c5ce27ca197ddfd5ac85c3._comment b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_3_47269e2c40c5ce27ca197ddfd5ac85c3._comment
new file mode 100644
index 0000000000..1b87f402d5
--- /dev/null
+++ b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_3_47269e2c40c5ce27ca197ddfd5ac85c3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-02-07T20:29:19Z"
+ content="""
+That would make it do efficient parallelization of downloads, but not of
+the uploads that you showed it being bottlenecked on the slowest remote.
+"""]]
diff --git a/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_4_b9444184ab653718fca9df5c2068ad3c._comment b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_4_b9444184ab653718fca9df5c2068ad3c._comment
new file mode 100644
index 0000000000..8552e9400a
--- /dev/null
+++ b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_4_b9444184ab653718fca9df5c2068ad3c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="not uploads"
+ date="2019-02-07T20:59:13Z"
+ content="""
+ah. i somehow missed that... i was assuming a symmetry between the process of getting and sending files, after all it's similar: there's a list of files to move around, and we iterate of them the same way.
+
+cost doesn't apply to uploads? if so that would seem like a fair feature to add... :)
+"""]]
diff --git a/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_5_5098db1fad3290cba49ea1c1163cc168._comment b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_5_5098db1fad3290cba49ea1c1163cc168._comment
new file mode 100644
index 0000000000..fd12a7ef88
--- /dev/null
+++ b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_5_5098db1fad3290cba49ea1c1163cc168._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="parallelizing checksum and get"
+ date="2019-03-07T18:21:22Z"
+ content="""
+one thing I would definitely like to see parallelize is CPU and network. right now `git annex get` will:
+
+ 1. download file A
+ 2. checksum file A
+ 3. download file B
+ 4. checksum file B
+
+... serially. If parallelism (`-J2`) is enabled, the following happens, assuming files are roughly the same size:
+
+ 1. download file A and B
+ 2. checksum file A and B
+
+This is not much of an improvement... We can get away with maximizing the bandwidth usage *if* file transfers are somewhat interleaved (because of size differences) but the above degenerate case happens actually quite often. The alternative (`-J3` or more) might just download more files in parallel, which is not optimal.
+
+So could we at least batch the checksum jobs separately from downloads? This would already be an improvement and maximize resource usage while at the same time reducing total transfer time.
+
+Thanks! :)
+"""]]
diff --git a/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_6_ac6b01d2ff9dfe6060be5956d5adb632._comment b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_6_ac6b01d2ff9dfe6060be5956d5adb632._comment
new file mode 100644
index 0000000000..4c3e4fa7b6
--- /dev/null
+++ b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_6_ac6b01d2ff9dfe6060be5956d5adb632._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="or -c annex.verify=false"
+ date="2019-03-07T18:23:02Z"
+ content="""
+oh... i guess i can use `-c annex.verify=false` to workaround that problem as well... but that's kind of obscure, really. :)
+"""]]
diff --git a/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_7_101543247268097f7535660efe0d39d8._comment b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_7_101543247268097f7535660efe0d39d8._comment
new file mode 100644
index 0000000000..62898c3ac1
--- /dev/null
+++ b/doc/forum/does_git-annex_parallelize_different_remotes__63__/comment_7_101543247268097f7535660efe0d39d8._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2019-09-18T17:02:27Z"
+ content="""
+git-annex does separately parallelize checksums, since version 
+7.20190626.
+
+> cost doesn't apply to uploads? if so that would seem like a fair feature
+> to add... :)
+
+`git-annex sync --content` uploads to the lowest-cost remotes first,
+but it still generally still has to upload to the higher cost remotes too,
+unless preferred content has been set up to prevent it.
+"""]]
diff --git a/doc/forum/done_bugs_are_missing.mdwn b/doc/forum/done_bugs_are_missing.mdwn
new file mode 100644
index 0000000000..1121f431d0
--- /dev/null
+++ b/doc/forum/done_bugs_are_missing.mdwn
@@ -0,0 +1,5 @@
+Joey, did you mean to delete all of the [done bugs](http://git-annex.branchable.com/bugs/done/) during your [mass bug closures](http://git-annex.branchable.com/devblog/day_498__unexpected_release_prep/)?
+
+I usually like to check done bugs on the website to see what has been fixed in a release. But, it seems many of the fixed bugs are now missing. I had been looking to see if you fixed the webapp not launching on OS-X, but I couldn't find the bug report.
+
+—[Andrew](http://git-annex.branchable.com/users/andrew/)
diff --git a/doc/forum/done_bugs_are_missing/comment_1_400c15824ec84bd67583102a023edcf8._comment b/doc/forum/done_bugs_are_missing/comment_1_400c15824ec84bd67583102a023edcf8._comment
new file mode 100644
index 0000000000..5c65bfa60e
--- /dev/null
+++ b/doc/forum/done_bugs_are_missing/comment_1_400c15824ec84bd67583102a023edcf8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-05-31T03:15:37Z"
+ content="""
+Ooops. Hit post, before I finished.
+
+…but I couldn't find the bug report. I was pleasantly surprised when I did discover you had fixed this, so quickly! But the fix was only mentioned in the release notes. I think it is great to see the entire list of bugs you have fixed on the website, it shows how much effort you put into this project and how actively maintained it is. 
+"""]]
diff --git a/doc/forum/done_bugs_are_missing/comment_2_1fdcfb4ed807e424fe73f134c4ad9526._comment b/doc/forum/done_bugs_are_missing/comment_2_1fdcfb4ed807e424fe73f134c4ad9526._comment
new file mode 100644
index 0000000000..880b012f72
--- /dev/null
+++ b/doc/forum/done_bugs_are_missing/comment_2_1fdcfb4ed807e424fe73f134c4ad9526._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-05-31T15:50:05Z"
+ content="""
+The page was simply only listing the most recently closed 10
+bugs, and not all the others. I've changed it to list them all.
+
+(I do archive old closed bugs, generally about a year after the last
+activity on the bug, to keep the size of the wiki in check.)
+"""]]
diff --git a/doc/forum/done_bugs_are_missing/comment_3_6eb74e1bcf6b062b61b25e59b0b1ddc6._comment b/doc/forum/done_bugs_are_missing/comment_3_6eb74e1bcf6b062b61b25e59b0b1ddc6._comment
new file mode 100644
index 0000000000..2558227bbd
--- /dev/null
+++ b/doc/forum/done_bugs_are_missing/comment_3_6eb74e1bcf6b062b61b25e59b0b1ddc6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 3"
+ date="2018-05-31T17:43:21Z"
+ content="""
+Thanks!
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp.mdwn b/doc/forum/dot_git_slash_annex_slash_tmp.mdwn
new file mode 100644
index 0000000000..5f1262c7aa
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp.mdwn
@@ -0,0 +1,5 @@
+When I was checking out disk usage on my home directory, I noticed a bunch of files stored in .git/annex/tmp under their own filenames, rather than in .git/annex/objects.  Checking a couple, they seem to be redundant with stuff in .git/annex/objects.
+
+Is there any way to clean that stuff up?  Will the assistant eventually clean it up?
+
+Thanks!
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_10_14b74438bb1e3e02cff7926d774ba09a._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_10_14b74438bb1e3e02cff7926d774ba09a._comment
new file mode 100644
index 0000000000..fe7a71dcbf
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_10_14b74438bb1e3e02cff7926d774ba09a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 10"
+ date="2013-06-06T13:16:50Z"
+ content="""
+Huh, at some point this happened again.  Ended up with 8 gigs of files in that tmp dir.  Cleaning out again.  Yay, disk space!
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_11_b1f717342c1c8ea42a451caa2d936622._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_11_b1f717342c1c8ea42a451caa2d936622._comment
new file mode 100644
index 0000000000..c882a85731
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_11_b1f717342c1c8ea42a451caa2d936622._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="stoile"
+ ip="2a01:198:242:0:219:66ff:fef2:c021"
+ subject="Same problem here"
+ date="2013-11-16T12:10:55Z"
+ content="""
+I got the same problem on linux. Under what circumstances does \"git annex unused\" not find files in .git/annex/tmp? Maybe it is possible to improve \"git annex unused\"...
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_12_e2c6ad99333018c8c46e736da416b8ef._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_12_e2c6ad99333018c8c46e736da416b8ef._comment
new file mode 100644
index 0000000000..153a617b57
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_12_e2c6ad99333018c8c46e736da416b8ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkXtBdMgE1d9nCz2iBc4f85xh4izZ_auU"
+ nickname="Ulrich"
+ subject="Wow. Found >180 GB of data in annex/tmp"
+ date="2013-11-24T21:53:29Z"
+ content="""
+… no wonder my disk was filling up. On Mac OS X 10.9…
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_13_35ae9d6bcb8d9762a92e3564b686ed72._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_13_35ae9d6bcb8d9762a92e3564b686ed72._comment
new file mode 100644
index 0000000000..0cbeb8f5ea
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_13_35ae9d6bcb8d9762a92e3564b686ed72._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 13"
+ date="2013-12-12T20:01:09Z"
+ content="""
+The people who are apparently still having this problem need to provide details about the names of the files in the temp directory. Otherwise, I cannot fix whatever problem you are encountering.
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_14_92b1e8956513dbf52da31cec3f58e2c5._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_14_92b1e8956513dbf52da31cec3f58e2c5._comment
new file mode 100644
index 0000000000..b84e663ccc
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_14_92b1e8956513dbf52da31cec3f58e2c5._comment
@@ -0,0 +1,104 @@
+[[!comment format=mdwn
+ username="http://alan.petitepomme.net/"
+ nickname="Alan Schmitt"
+ subject="comment 14"
+ date="2014-04-04T11:07:31Z"
+ content="""
+I just discovered there were 30GB in this tmp directory. Here are the file names. It seems that the file names are partial (they are missing some characters: it seems most file names are missing the last 16 characters and the file extension). As I'm in dire need of disk space, I'm going to delete this files now.
+
+    schmitta@top-wifi ~/D/a/.g/a/tmp (GIT_DIR!)> pwd
+    /Users/schmitta/Documents/annex/.git/annex/tmp
+    schmitta@top-wifi ~/D/a/.g/a/tmp (GIT_DIR!)> ls -al
+    total 73802184
+    drwxr-xr-x  91 schmitta  staff        3094 16 mar 11:15 .
+    drwxr-xr-x  34 schmitta  staff        1156  4 avr 12:58 ..
+    -r--r--r--@  6 schmitta  staff   132882914  8 déc 20:17 12426.
+    -r--r--r--@  6 schmitta  staff   113471066  8 déc 20:15 12426.2-
+    -r--r--r--@  6 schmitta  staff   148673586  8 déc 20:24 12427.
+    -r--r--r--@  6 schmitta  staff    96197733  8 déc 20:09 12427.2-
+    -r--r--r--@  6 schmitta  staff   132882914  8 déc 20:17 12489.
+    -r--r--r--@  6 schmitta  staff   113471066  8 déc 20:15 12489.2-
+    -r--r--r--@  6 schmitta  staff   148673586  8 déc 20:24 12490.
+    -r--r--r--@  6 schmitta  staff    96197733  8 déc 20:09 12490.2-
+    -r--r--r--@  6 schmitta  staff   132882914  8 déc 20:17 12498.
+    -r--r--r--@  6 schmitta  staff   113471066  8 déc 20:15 12498.2-
+    -r--r--r--@  6 schmitta  staff   148673586  8 déc 20:24 12499.
+    -r--r--r--@  6 schmitta  staff    96197733  8 déc 20:09 12499.2-
+    -r--r--r--@  6 schmitta  staff   132882914  8 déc 20:17 12504.
+    -r--r--r--@  6 schmitta  staff   113471066  8 déc 20:15 12504.2-
+    -r--r--r--@  6 schmitta  staff   148673586  8 déc 20:24 12505.
+    -r--r--r--@  6 schmitta  staff    96197733  8 déc 20:09 12505.2-
+    -r--r--r--@  6 schmitta  staff   132882914  8 déc 20:17 12562.
+    -r--r--r--@  6 schmitta  staff   113471066  8 déc 20:15 12562.2-
+    -r--r--r--@  6 schmitta  staff   148673586  8 déc 20:24 12563.
+    -r--r--r--@  6 schmitta  staff    96197733  8 déc 20:09 12563.2-
+    -r--r--r--   2 schmitta  staff  1237391994 21 déc 19:27 BTSM With Flowerchild Li562
+    -r--r--r--   2 schmitta  staff  1097868668 18 déc 13:24 BTSM with Flowerchild 562
+    -r--r--r--   3 schmitta  staff   181962494  1 déc 05:19 Cosmos - A Personal Voyage - Episod422
+    -r--r--r--   3 schmitta  staff   199341564 17 déc 14:28 Cosmos - A Personal Voyage - Episod423
+    -r--r--r--   3 schmitta  staff   196677905  9 jan 08:36 Cosmos - A Personal Voyage - Episod424
+    -r--r--r--   3 schmitta  staff   196671683 26 déc 19:36 Cosmos - A Personal Voyage - Episod425
+    -r--r--r--   3 schmitta  staff   199297657 19 jan 14:33 Cosmos - A Personal Voyage - Episod426
+    -r--r--r--   3 schmitta  staff   194250261 18 jan 17:10 Cosmos - A Personal Voyage - Episod427
+    -r--r--r--   3 schmitta  staff   216726281 16 jan 16:26 Cosmos - A Personal Voyage - Episod428
+    -r--r--r--   3 schmitta  staff   204634401 16 jan 12:17 Cosmos - A Personal Voyage - Episod429
+    -r--r--r--   3 schmitta  staff   179412519 11 jan 11:29 Cosmos - A Personal Voyage - Episod430
+    -r--r--r--   3 schmitta  staff   181962494  1 déc 05:19 Cosmos - A Personal Voyage - Episod572
+    -r--r--r--   3 schmitta  staff   199341564 17 déc 14:28 Cosmos - A Personal Voyage - Episod573
+    -r--r--r--   3 schmitta  staff   196677905  9 jan 08:36 Cosmos - A Personal Voyage - Episod574
+    -r--r--r--   3 schmitta  staff   196671683 26 déc 19:36 Cosmos - A Personal Voyage - Episod575
+    -r--r--r--   3 schmitta  staff   199297657 19 jan 14:33 Cosmos - A Personal Voyage - Episod576
+    -r--r--r--   3 schmitta  staff   194250261 18 jan 17:10 Cosmos - A Personal Voyage - Episod577
+    -r--r--r--   3 schmitta  staff   216726281 16 jan 16:26 Cosmos - A Personal Voyage - Episod578
+    -r--r--r--   3 schmitta  staff   204634401 16 jan 12:17 Cosmos - A Personal Voyage - Episod579
+    -r--r--r--   3 schmitta  staff   179412519 11 jan 11:29 Cosmos - A Personal Voyage - Episod580
+    -r--r--r--   3 schmitta  staff   237284500 15 mai  2012 Cosmos - A Personal Voyage - Episode422
+    -r--r--r--   3 schmitta  staff   207386296 28 jan 18:39 Cosmos - A Personal Voyage - Episode423
+    -r--r--r--   3 schmitta  staff   194659898 28 jan 20:35 Cosmos - A Personal Voyage - Episode424
+    -r--r--r--   3 schmitta  staff   221944244 11 jan 07:18 Cosmos - A Personal Voyage - Episode425
+    -r--r--r--   3 schmitta  staff   237284500 15 mai  2012 Cosmos - A Personal Voyage - Episode572
+    -r--r--r--   3 schmitta  staff   207386296 28 jan 18:39 Cosmos - A Personal Voyage - Episode573
+    -r--r--r--   3 schmitta  staff   194659898 28 jan 20:35 Cosmos - A Personal Voyage - Episode574
+    -r--r--r--   3 schmitta  staff   221944244 11 jan 07:18 Cosmos - A Personal Voyage - Episode575
+    -r--r--r--   1 schmitta  staff   166417358 25 nov 08:47 Icy Plays - Kerbal Space Program - Better Than Starting Mann456
+    -r--r--r--   2 schmitta  staff  1110410229 28 déc 00:40 Kerbal Space Program - BTSM With Flowerchild Li562
+    -r--r--r--   1 schmitta  staff   898936971 26 déc 06:22 Let's Play Minecraft Better Than Wolves   Ep 10 _ HARDCORE _ Ooooh le petit mat572
+    -r--r--r--   1 schmitta  staff   816306596 27 déc 05:08 Let's Play Minecraft Better Than Wolves   Ep 11 _ HARDCORE _ Un peu de cannabis pour le moral 572
+    -r--r--r--   1 schmitta  staff   897143936 27 déc 10:42 Let's Play Minecraft Better Than Wolves   Ep 12 _ HARDCORE _ Chaud l'enf572
+    -r--r--r--   1 schmitta  staff   922364739 29 déc 08:30 Let's Play Minecraft Better Than Wolves   Ep 13 _ HARDCORE _ Walking dea572
+    -r--r--r--   1 schmitta  staff  1321555505  1 jan 02:15 Let's Play Minecraft Better Than Wolves   Ep 14 l HARDCORE l Couvre572
+    -r--r--r--   1 schmitta  staff   889592223  5 jan 02:07 Let's Play Minecraft Better Than Wolves   Ep 15 l HARDCORE l Pa572
+    -r--r--r--   1 schmitta  staff   153571799  6 jan 03:56 Let's Play Minecraft Better Than Wolves   Ep 16 l HARDCORE l Point de s572
+    -r--r--r--   1 schmitta  staff  1036932250  9 jan 07:36 Let's Play Minecraft Better Than Wolves   Ep 17 l HARDCORE l Satané meuh572
+    -r--r--r--   1 schmitta  staff  1289798767 11 jan 22:08 Let's Play Minecraft Better Than Wolves   Ep 18 l HARDCORE l Un Moulin572
+    -r--r--r--   1 schmitta  staff  1582120875 19 jan 15:39 Let's Play Minecraft Better Than Wolves   Ep 19 l HARDCORE l Explosion de ca572
+    -r--r--r--   1 schmitta  staff   728469432 13 fév 07:02 Let's Play Minecraft Better Than Wolves   Ep 2 _ HARDCORE _ Préparation pour l'explorat422
+    -r--r--r--   1 schmitta  staff   911653518 22 jan 13:35 Let's Play Minecraft Better Than Wolves   Ep 20 l HARDCORE l Minesha572
+    -r--r--r--   1 schmitta  staff  1377428597 28 jan 08:43 Let's Play Minecraft Better Than Wolves   Ep 21 l HARDCORE l Terreur en sous-sol o_O !572
+    -r--r--r--   1 schmitta  staff  1376224927  4 fév 03:24 Let's Play Minecraft Better Than Wolves   Ep 22 l HARDCORE l Machinerie infern572
+    -r--r--r--   1 schmitta  staff  1102293665 13 fév 03:56 Let's Play Minecraft Better Than Wolves   Ep 23 l HARDCORE l Piston chenil572
+    -r--r--r--   1 schmitta  staff  1835677068 19 fév 09:14 Let's Play Minecraft Better Than Wolves   Ep 24 l HARDCORE l Piston chenille et o_Oce572
+    -r--r--r--   1 schmitta  staff   753740284 30 déc 19:31 Let's Play Minecraft Better Than Wolves   Ep 3 _ HARDCORE _ First pioche en fer422
+    -r--r--r--   1 schmitta  staff  1019022279 30 déc 18:38 Let's Play Minecraft Better Than Wolves   Ep 5 _ HARDCORE _ Fonderie super desi572
+    -r--r--r--   1 schmitta  staff   788714805 30 déc 17:47 Let's Play Minecraft Better Than Wolves   Ep 6 _ HARDCORE _ Minage de la mor572
+    -r--r--r--   1 schmitta  staff   778987710 23 déc 19:56 Let's Play Minecraft Better Than Wolves   Ep 7 _ HARDCORE _ Diamant572
+    -r--r--r--   1 schmitta  staff   644564981 23 déc 23:06 Let's Play Minecraft Better Than Wolves   Ep 8 _ HARDCORE _ Et le poulet ma572
+    -r--r--r--   1 schmitta  staff   871173289 24 déc 10:44 Let's Play Minecraft Better Than Wolves   Ep 9 _ HARDCORE _ Araignée verte de la jun572
+    -r--------@  4 schmitta  staff   149520850 14 aoû  2010 OPLSS10-Mc422
+    -r--------@  4 schmitta  staff    95020824 14 aoû  2010 OPLSS10-Mc423
+    -r--------@  4 schmitta  staff    98980596  1 sep  2010 OPLSS10-Mc424
+    -r--------@  4 schmitta  staff   207525348  1 sep  2010 OPLSS10-Mc425
+    -r--------@  4 schmitta  staff   149520850 14 aoû  2010 OPLSS10-Mc534
+    -r--------@  4 schmitta  staff    95020824 14 aoû  2010 OPLSS10-Mc535
+    -r--------@  4 schmitta  staff    98980596  1 sep  2010 OPLSS10-Mc536
+    -r--------@  4 schmitta  staff   207525348  1 sep  2010 OPLSS10-Mc537
+    -r--------@  4 schmitta  staff   149520850 14 aoû  2010 OPLSS10-Mc572
+    -r--------@  4 schmitta  staff    95020824 14 aoû  2010 OPLSS10-Mc573
+    -r--------@  4 schmitta  staff    98980596  1 sep  2010 OPLSS10-Mc574
+    -r--------@  4 schmitta  staff   207525348  1 sep  2010 OPLSS10-Mc575
+    -r--r--r--@  2 schmitta  staff   150781568 10 mar 13:34 XD300-23_68HighlightsAResearchCntAugHuma469
+    -r--r--r--@  2 schmitta  staff   145745487 10 mar 13:36 XD300-24_68HighlightsAResearchCntAugHuma469
+    -r--r--r--@  2 schmitta  staff   142414085 10 mar 13:36 XD300-25_68HighlightsAResearchCntAugHuma469
+    -r--------@  2 schmitta  staff   548973365  7 jan 20:21 laumond-20120119449.mp4
+    -r--r--r--@  2 schmitta  staff  1820482781  8 mar 18:15 salt-020131469
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_15_839e29d41de9dcc8f01dfdc585a51d12._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_15_839e29d41de9dcc8f01dfdc585a51d12._comment
new file mode 100644
index 0000000000..36ad14e57c
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_15_839e29d41de9dcc8f01dfdc585a51d12._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="216.145.95.162"
+ subject="comment 15"
+ date="2014-05-19T15:43:52Z"
+ content="""
+Since version 5.20140517, the git-annex assistant will automatically clean up stale tmp files on startup.
+
+If not using the assistant, you can do it yourself..
+
+So far, all the tmp files people have been kind enough to share the details about with me seem to be created by the assistant when it locks a file down. I know this can result in dangling files if the computer is rebooted while the assistant is in the middle of doing that.
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_1_1a35ef8cb89e0cd392f6e9fcee1fb92c._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_1_1a35ef8cb89e0cd392f6e9fcee1fb92c._comment
new file mode 100644
index 0000000000..d00f681443
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_1_1a35ef8cb89e0cd392f6e9fcee1fb92c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 1"
+ date="2012-11-29T19:35:41Z"
+ content="""
+These are partially downloaded files. You can use `git annex unused` to clean them up. The assistant doesn't yet explicitly clean these up, but it does keep retrying (and when possible, resuming) failed downloads until they succeed, at which point the temp file is moved into the objects directory.
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_2_f4cc36c493d7c20fbaf949edd38e1252._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_2_f4cc36c493d7c20fbaf949edd38e1252._comment
new file mode 100644
index 0000000000..8aeaf63cfd
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_2_f4cc36c493d7c20fbaf949edd38e1252._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 2"
+ date="2012-11-29T19:53:33Z"
+ content="""
+that's odd... these files are on my client machine, and shouldn't be downloaded from anywhere, just uploaded to other places.  There are lots and lots of them.
+
+git-annex unused only found two files, and there are dozens and dozens of these files in my .git/annex/tmp directory.  
+
+Would it be safe to delete them by hand?
+
+(The only thing I can think of that might e relevant is, some of these have definitely been moved from place to place within my repo.  I use \"git mv\" when I do that.  Maybe I messed that up somehow, and git-annex thought they had disappeared and needed to be re-downloaded from a remote repo?)
+
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_3_69268f8aa29e807a56248f1fac86aa41._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_3_69268f8aa29e807a56248f1fac86aa41._comment
new file mode 100644
index 0000000000..d9863375ae
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_3_69268f8aa29e807a56248f1fac86aa41._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 3"
+ date="2012-11-29T20:22:01Z"
+ content="""
+No, moving files within the repository is unlikely to be related.
+
+If you can show me what the filenames look like I'll have a much better chance of getting somewhere, since they do not seem to be filenames that `git annex unused` knows how to deal with, and so I don't know what they could be.
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_4_0ffb0c803c232a1587f956f16113aeb7._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_4_0ffb0c803c232a1587f956f16113aeb7._comment
new file mode 100644
index 0000000000..11da788418
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_4_0ffb0c803c232a1587f956f16113aeb7._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 4"
+ date="2012-11-29T20:33:09Z"
+ content="""
+They're the full actual filenames (but not directories) of particular files in my repository, sometimes with numeric suffixes (or rather, numbers before the file suffixes), like this:
+
+746.DS_Store
+747.DS_Store
+748.DS_Store
+749.DS_Store
+Birdplane87712.mp4
+Birdplane87713.mp4
+Bodyrock87712.mp4
+Bodyrock87713.mp4
+Dubstep Violin- Lindsey Stirling- Crystallize746.mp4
+Dubstep Violin- Lindsey Stirling- Crystallize87712.mp4
+Dubstep Violin- Lindsey Stirling- Crystallize87713.mp4
+Handlebars (fan video)87712.mp4
+Handlebars (fan video)87713.mp4
+Handlebars (official)87712.mp4
+Handlebars (official)87713.mp4
+
+Most of them are videos, and I've moved videos around a lot in my repository, and made some mistakes doing so from time to time when I was first learning git-annex, and fooling around on the command line -- breaking symlinks and figuring out how to fix that with git-annex fix.
+
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_5_c303e28825241733d69fca74f2015fc6._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_5_c303e28825241733d69fca74f2015fc6._comment
new file mode 100644
index 0000000000..60896ab5c7
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_5_c303e28825241733d69fca74f2015fc6._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 5"
+ date="2012-11-29T20:47:36Z"
+ content="""
+Oh, another stupid thing I might have done -- 
+
+* added files to the repo, and not realizing it might take assistant a while to recognize and add them all, gotten impatient
+* added them myself, but did it with \"import\" instead of \"add\" so I was git-annex importing files from *inside* git-annex, with an assistant process running at the same time.
+
+Might not be relevant, just trying to think of weird things I've done.
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_6_3f0b376e37bd092b8d46c46bb1940e35._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_6_3f0b376e37bd092b8d46c46bb1940e35._comment
new file mode 100644
index 0000000000..0fc7f5c159
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_6_3f0b376e37bd092b8d46c46bb1940e35._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 6"
+ date="2012-11-29T20:53:34Z"
+ content="""
+Ah, I think I know what this is. When the assistant notices a new file appear, it makes a hard link in the temp directory to the new file, and waits for it to stop being written to. 
+
+If the hard link is broken before the assistant is done adding the file to the annex, it looks like it could leave the temp file behind. I've committed a change that should avoid that.
+
+Since some of these are OSX DS_Store files, and the rest have a strange number added (which git-annex did not do), I suspect you moved them into the annexed directory using the OSX Finder or something like that, and whatever was putting them into the directory first wrote them with the names we see here. Then, while git-annex was still processing them, they got renamed.
+
+I'd say you can safely delete them.
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_7_615641b3dd176d4b3a5bbfb521098e38._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_7_615641b3dd176d4b3a5bbfb521098e38._comment
new file mode 100644
index 0000000000..20e8b205f6
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_7_615641b3dd176d4b3a5bbfb521098e38._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 7"
+ date="2012-11-29T22:15:11Z"
+ content="""
+Sounds likely!!  I'll get to deleting, and when I get a chance I'll grab your latest commit and recompile.
+
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_8_4600fa9234a787004ea0e0dbb36184b9._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_8_4600fa9234a787004ea0e0dbb36184b9._comment
new file mode 100644
index 0000000000..3325f598a5
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_8_4600fa9234a787004ea0e0dbb36184b9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 8"
+ date="2012-11-29T22:15:55Z"
+ content="""
+(thanks very much!)
+"""]]
diff --git a/doc/forum/dot_git_slash_annex_slash_tmp/comment_9_4f5cd0d0d4db0479c1ad86ffdc5ae434._comment b/doc/forum/dot_git_slash_annex_slash_tmp/comment_9_4f5cd0d0d4db0479c1ad86ffdc5ae434._comment
new file mode 100644
index 0000000000..cc996c825d
--- /dev/null
+++ b/doc/forum/dot_git_slash_annex_slash_tmp/comment_9_4f5cd0d0d4db0479c1ad86ffdc5ae434._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl2Jj8q2upJL4ZQAc2lp7ugTxJiGtcICv8"
+ nickname="Michael"
+ subject="comment 9"
+ date="2013-02-20T10:23:12Z"
+ content="""
+I'm seeing this too, and the number being added to the file name is the PID of the git-annex process.
+"""]]
diff --git a/doc/forum/download_from_multiple_remotes_in_parallel.mdwn b/doc/forum/download_from_multiple_remotes_in_parallel.mdwn
new file mode 100644
index 0000000000..d749929be1
--- /dev/null
+++ b/doc/forum/download_from_multiple_remotes_in_parallel.mdwn
@@ -0,0 +1,9 @@
+Hey everyone, 
+
+I have the situation that there are two remote repositories A and B, both of which have several files that I want to get. The problem is that both A and B have limited upstream, so launching several threads downloading from A would not speed up the download, but downloading from A and B in parallel would help significantly.
+
+When I git-annex-get these files, my dream would be that specifying --jobs=2 has the effect that thread #1 only downloads from A and thread #2 only downloads from B. If this is the case, great, but if it is not (and I expect it to not be the case), is there any way to get files in parallel from A and B, but only ever having one connection to each of these repositories?
+
+Thanks a lot!
+
+
diff --git a/doc/forum/download_from_multiple_remotes_in_parallel/comment_1_81e2612ddaffefec81455e9ff706c4c9._comment b/doc/forum/download_from_multiple_remotes_in_parallel/comment_1_81e2612ddaffefec81455e9ff706c4c9._comment
new file mode 100644
index 0000000000..bb603c819d
--- /dev/null
+++ b/doc/forum/download_from_multiple_remotes_in_parallel/comment_1_81e2612ddaffefec81455e9ff706c4c9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-05T20:18:56Z"
+ content="""
+Currently the way to do this to run two git-annex get's in parallel, one
+--from A and the other --from B. They will avoid stepping on each other's
+toes.
+
+-J2 does not currently accomplish this; git-annex always defaults to
+using the remote with the lowest cost. It might be a nice improvement to
+have get round-robin when multiple remotes of the same cost contain files.
+[[todo/get_round_robin]]
+"""]]
diff --git a/doc/forum/downloading_from_moodle.mdwn b/doc/forum/downloading_from_moodle.mdwn
new file mode 100644
index 0000000000..ad38d7f1ff
--- /dev/null
+++ b/doc/forum/downloading_from_moodle.mdwn
@@ -0,0 +1,76 @@
+my school uses moodle for our classes.  We have to sign in and then manually click to download each file, assignment and video uploaded.  I asked the school's tech administrator if there was a direct way I could access the videos through the ssh access they've given us to one of the servers, but he said it wasn't possible.
+
+when I click on the link shown, the location I see is: http://moodle.jct.ac.il/mod/resource/view.php?id=135374
+Inspect element gives more information. the response from the server is:
+
+    Remote Address:147.161.6.59:80
+    Request URL:http://moodle.jct.ac.il/mod/resource/view.php?id=135374
+    Request Method:GET
+    Status Code:303 See Other
+    Request Headersview source
+    Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
+    Accept-Encoding:gzip,deflate,sdch
+    Accept-Language:en-US,en;q=0.8,he;q=0.6
+    Connection:keep-alive
+    Cookie:visid_incap_97364=qJx2WaKqQfGidGf9VfM6QWrnlFIAAAAAQUIPAAAAAAC5EXcbt00vqNu9jdVDwEDN; __utma=98014340.1409421308.1381214363.1381214363.1390387318.2; __utmz=98014340.1381214363.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); MoodleSession5771=7s1cfqfo4ahdtmna5h7vserg97; MOODLEID1_5771=%257F%25D39%2522N%25B4%25AFY
+    DNT:1
+    Host:moodle.jct.ac.il
+    Referer:http://moodle.jct.ac.il/course/view.php?id=20151
+    User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.67 Safari/537.36
+    Query String Parametersview sourceview URL encoded
+    id:135374
+    Response Headersview source
+    Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
+    Connection:Keep-Alive
+    Content-Encoding:gzip
+    Content-Language:he
+    Content-Length:503
+    Content-Type:text/html
+    Date:Mon, 16 Jun 2014 12:31:22 GMT
+    Expires:Thu, 19 Nov 1981 08:52:00 GMT
+    Keep-Alive:timeout=15, max=100
+    Location:http://moodle.jct.ac.il/pluginfile.php/288409/mod_resource/content/0/movie%205773/150151.5773.week1.wmv?forcedownload=1
+    Pragma:no-cache
+    Server:Apache/2.2.14 (Ubuntu)
+    Vary:Accept-Encoding
+    X-Powered-By:PHP/5.3.2-1ubuntu4.24
+
+this then pulls the following: 
+
+    Remote Address:147.161.6.59:80
+    Request URL:http://moodle.jct.ac.il/pluginfile.php/288409/mod_resource/content/0/movie%205773/150151.5773.week1.wmv?forcedownload=1
+    Request Method:GET
+    Status Code:200 OK
+    Request Headersview source
+    Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
+    Accept-Encoding:gzip,deflate,sdch
+    Accept-Language:en-US,en;q=0.8,he;q=0.6
+    Connection:keep-alive
+    Cookie:visid_incap_97364=qJx2WaKqQfGidGf9VfM6QWrnlFIAAAAAQUIPAAAAAAC5EXcbt00vqNu9jdVDwEDN; __utma=98014340.1409421308.1381214363.1381214363.1390387318.2; __utmz=98014340.1381214363.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); MoodleSession5771=7s1cfqfo4ahdtmna5h7vserg97; MOODLEID1_5771=%257F%25D39%2522N%25B4%25AFY
+    DNT:1
+    Host:moodle.jct.ac.il
+    Referer:http://moodle.jct.ac.il/course/view.php?id=20151
+    User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.67 Safari/537.36
+    Query String Parametersview sourceview URL encoded
+    forcedownload:1
+    Response Headersview source
+    Accept-Ranges:bytes
+    Cache-Control:max-age=86400
+    Connection:Keep-Alive
+    Content-Disposition:attachment; filename="150151.5773.week1.wmv"
+    Content-Length:1353673203
+    Content-Type:application/x-forcedownload
+    Date:Mon, 16 Jun 2014 12:31:23 GMT
+    ETag:675e7d2cffd7a79afd8686c59ff2533f9e3508b7
+    Expires:Tue, 17 Jun 2014 12:31:23 GMT
+    Keep-Alive:timeout=15, max=99
+    Last-Modified:Fri, 19 Jul 2013 17:06:54 GMT
+    Pragma:
+    Server:Apache/2.2.14 (Ubuntu)
+    X-Powered-By:PHP/5.3.2-1ubuntu4.24
+
+when I right-click on the second one in the inspect element window, I can select "copy as cURL" i get:
+
+    curl 'http://moodle.jct.ac.il/pluginfile.php/288409/mod_resource/content/0/movie%205773/150151.5773.week1.wmv?forcedownload=1' -H 'DNT: 1' -H 'Accept-Encoding: gzip,deflate,sdch' -H 'Accept-Language: en-US,en;q=0.8,he;q=0.6' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.67 Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Referer: http://moodle.jct.ac.il/course/view.php?id=20151' -H 'Cookie: visid_incap_97364=qJx2WaKqQfGidGf9VfM6QWrnlFIAAAAAQUIPAAAAAAC5EXcbt00vqNu9jdVDwEDN; __utma=98014340.1409421308.1381214363.1381214363.1390387318.2; __utmz=98014340.1381214363.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); MoodleSession5771=7s1cfqfo4ahdtmna5h7vserg97; MOODLEID1_5771=%257F%25D39%2522N%25B4%25AFY' -H 'Connection: keep-alive' --compressed
+
+if I append " > week1.wmv" to the end of that output it downloads fine.  How can I add this file to a git-annex repo?
diff --git a/doc/forum/downloading_from_moodle/comment_1_3f677130d268de4288e87cfa86ea055c._comment b/doc/forum/downloading_from_moodle/comment_1_3f677130d268de4288e87cfa86ea055c._comment
new file mode 100644
index 0000000000..a489859adf
--- /dev/null
+++ b/doc/forum/downloading_from_moodle/comment_1_3f677130d268de4288e87cfa86ea055c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-06-16T17:55:13Z"
+ content="""
+`git annex addurl` does not support storing cookies needed to access files. I doubt that makes sense anyway, since most login cookies expire.
+
+So, your best bet seems to just be to `git annex add` the file after you download it.
+"""]]
diff --git a/doc/forum/downloading_from_moodle/comment_2_dcef60ec144f123dadd165fb602ab950._comment b/doc/forum/downloading_from_moodle/comment_2_dcef60ec144f123dadd165fb602ab950._comment
new file mode 100644
index 0000000000..1529004333
--- /dev/null
+++ b/doc/forum/downloading_from_moodle/comment_2_dcef60ec144f123dadd165fb602ab950._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 2"
+ date="2014-06-16T17:59:20Z"
+ content="""
+Another option would be to set up some kind of http proxy that adds the login cookie to requests.. If you really wanted to use `git annex addurl`.
+"""]]
diff --git a/doc/forum/downloading_from_moodle/comment_3_d3efb767bf9b20f96242dcf64817bd4b._comment b/doc/forum/downloading_from_moodle/comment_3_d3efb767bf9b20f96242dcf64817bd4b._comment
new file mode 100644
index 0000000000..c9b1012254
--- /dev/null
+++ b/doc/forum/downloading_from_moodle/comment_3_d3efb767bf9b20f96242dcf64817bd4b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-06-16T18:04:48Z"
+ content="""
+Actually, a simpler option may be to set `annex.http-headers` in the git config, to the appropriate http headers that set the cookie.
+"""]]
diff --git a/doc/forum/downloading_mp4_by_default_with_importfeed.mdwn b/doc/forum/downloading_mp4_by_default_with_importfeed.mdwn
new file mode 100644
index 0000000000..88df821c18
--- /dev/null
+++ b/doc/forum/downloading_mp4_by_default_with_importfeed.mdwn
@@ -0,0 +1 @@
+Is it possible to download youtube videos in mp4 format by default with importfeed. Without any options git annex often downloads the webm format.  
diff --git a/doc/forum/downloading_mp4_by_default_with_importfeed/comment_1_c9e5a3700764faa33d2c68de6a8236dc._comment b/doc/forum/downloading_mp4_by_default_with_importfeed/comment_1_c9e5a3700764faa33d2c68de6a8236dc._comment
new file mode 100644
index 0000000000..07691d8233
--- /dev/null
+++ b/doc/forum/downloading_mp4_by_default_with_importfeed/comment_1_c9e5a3700764faa33d2c68de6a8236dc._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-30T15:27:57Z"
+ content="""
+git-annex uses quvi for these downloads. If quvi has a command-line 
+option to make it prefer mp4, you can pass it using the annex.quvi-options
+git configuration setting. Or maybe it has a config file. I don't
+know how to configure quvi to do that, but if it's possible to, you should
+be able to get git-annex to run it with that configuration.
+
+Update: Now git-annex uses youtube-dl, so you can use the
+annex.youtube-dl-options git configuration setting to configure youtube-dl
+to download your preferred format.
+"""]]
diff --git a/doc/forum/downloading_mp4_by_default_with_importfeed/comment_2_ade70b45f49eb3eaf127ba7b2bd37900._comment b/doc/forum/downloading_mp4_by_default_with_importfeed/comment_2_ade70b45f49eb3eaf127ba7b2bd37900._comment
new file mode 100644
index 0000000000..10ad1c4b90
--- /dev/null
+++ b/doc/forum/downloading_mp4_by_default_with_importfeed/comment_2_ade70b45f49eb3eaf127ba7b2bd37900._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="juh"
+ subject="comment 2"
+ date="2015-06-01T11:29:12Z"
+ content="""
+Ok, I look into that.
+"""]]
diff --git a/doc/forum/drop__47__whereis_not_showing_gcrypted_special_ssh_remote.mdwn b/doc/forum/drop__47__whereis_not_showing_gcrypted_special_ssh_remote.mdwn
new file mode 100644
index 0000000000..9445539b41
--- /dev/null
+++ b/doc/forum/drop__47__whereis_not_showing_gcrypted_special_ssh_remote.mdwn
@@ -0,0 +1,11 @@
+I have my laptop, my server and my usb drive. My server is a gcrypted remote via ssh. My laptop is just a repo that's referenced as a remote with a filepath.
+
+I do git annex copy --to server, and let it copy stuff. I repeat the same thing for the usb drive. 
+
+I run git annex sync and it does the whole sync dance successfully. it pushes stuff to both the usb drive and the server.
+
+Afterwards, I do git annex whereis, and I only get 2 copies showing - my laptop and my usb drive. Likewise, since I set numcopies to 2, it won't let me drop anything at all, because it doesn't know there's a copy on my server.
+
+Anything I can do about this? (What further info do you need?) 
+
+I should probably add that my server is a ubuntu machine, and so it runs version 5.20140412ubuntu1. My laptop runs a more recent 5.20140717-g5a7d4ff.
diff --git a/doc/forum/drop__47__whereis_not_showing_gcrypted_special_ssh_remote/comment_1_968bc2be595008790e9b93d82342714c._comment b/doc/forum/drop__47__whereis_not_showing_gcrypted_special_ssh_remote/comment_1_968bc2be595008790e9b93d82342714c._comment
new file mode 100644
index 0000000000..45699f4437
--- /dev/null
+++ b/doc/forum/drop__47__whereis_not_showing_gcrypted_special_ssh_remote/comment_1_968bc2be595008790e9b93d82342714c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="annexuser123"
+ ip="88.65.52.206"
+ subject="comment 1"
+ date="2014-08-04T18:00:00Z"
+ content="""
+To add further to this, the gcrypted remote does not show up in either the usb drive's git annex info, nor the laptop's git annex info. 
+
+Despite that, I can push to it and copy to it. 
+"""]]
diff --git a/doc/forum/drop__47__whereis_not_showing_gcrypted_special_ssh_remote/comment_2_2c14d88e55ea7d4edc90ce0091025f32._comment b/doc/forum/drop__47__whereis_not_showing_gcrypted_special_ssh_remote/comment_2_2c14d88e55ea7d4edc90ce0091025f32._comment
new file mode 100644
index 0000000000..a181940d2f
--- /dev/null
+++ b/doc/forum/drop__47__whereis_not_showing_gcrypted_special_ssh_remote/comment_2_2c14d88e55ea7d4edc90ce0091025f32._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 2"
+ date="2014-10-02T15:48:02Z"
+ content="""
+Sorry that it took me so long to get back to you.
+
+The git remote that corresponds to your server should have an annex-uuid setting. (Eg, remote.server.annex-uuid.) Look up the uuid. Then look in `git-annex info`. I'd expect the uuid to be listed there. It might be that somehow two repositories got the same uuid set (probability says no, but things find ways to break). If that did happen, I think it would replicate what you've reported, and in that case, the server's uuid would be listed by `git annex info`, but perhaps it would have the name of the usb drive.
+"""]]
diff --git a/doc/forum/drop_old_versions_of_a_file.mdwn b/doc/forum/drop_old_versions_of_a_file.mdwn
new file mode 100644
index 0000000000..95f103dcc9
--- /dev/null
+++ b/doc/forum/drop_old_versions_of_a_file.mdwn
@@ -0,0 +1,3 @@
+I have a music repository which has multiple versions of a music file(modified id3 tags etc,.) and in my music player same file is showing two times with two different id3 tags, one is from music directory and another is from .git-annex directory which is a older version(which I don't want to see).
+
+I was just wondering if there is a way I can drop old version of a file in android(direct mode).
diff --git a/doc/forum/drop_old_versions_of_a_file/comment_1_799a413248fb8f98efbf226b1bc4300d._comment b/doc/forum/drop_old_versions_of_a_file/comment_1_799a413248fb8f98efbf226b1bc4300d._comment
new file mode 100644
index 0000000000..09b01c8a8c
--- /dev/null
+++ b/doc/forum/drop_old_versions_of_a_file/comment_1_799a413248fb8f98efbf226b1bc4300d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-03-10T17:59:01Z"
+ content="""
+What you're looking for is `git annex unused` and `git annex dropunused`
+"""]]
diff --git a/doc/forum/dropped_files_keep_coming_back.mdwn b/doc/forum/dropped_files_keep_coming_back.mdwn
new file mode 100644
index 0000000000..bf0c308f83
--- /dev/null
+++ b/doc/forum/dropped_files_keep_coming_back.mdwn
@@ -0,0 +1,25 @@
+I have the following setup:
+
+* A 'working' repo in the manual group, called WORKING
+* 2 'backup' repos in the backup group, called A & B
+* A rclone/gdrive repo in the backup group, called GD
+* numfiles has been set to 3.
+
+A and B can directly see each-other via SSH and both can contact GD.
+WORKING can directly connect to A, B, and GD.
+
+I work on a set of files, git annex add them and eventually do a
+[[!format sh """
+$ git annex sync A --content
+"""]]
+
+At some point in time later (manual or chron) A does a git annex sync --content and the files end up in A, B and GD
+
+At some later point in time, I do a git annex drop of some of the files, and after the locks are done, the files are dropped.
+
+At yet some later point in time, after working on more files on WORKING, I do the git annex sync A --content again, and the files
+that were dropped are pulled back from A.  I would expect this if WORKING were a 'client' but it's manual, so it shouldn't be pulling it back
+
+I've checked and all three of A, B, and GD have the files in question.
+
+Thoughts?
diff --git a/doc/forum/dropped_files_keep_coming_back/comment_1_84655c21f59b3904c950ddccccde53d8._comment b/doc/forum/dropped_files_keep_coming_back/comment_1_84655c21f59b3904c950ddccccde53d8._comment
new file mode 100644
index 0000000000..840b942d21
--- /dev/null
+++ b/doc/forum/dropped_files_keep_coming_back/comment_1_84655c21f59b3904c950ddccccde53d8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-29T19:35:55Z"
+ content="""
+Does the repository have its preferred content expression set to
+"standard"?
+"""]]
diff --git a/doc/forum/dropped_files_keep_coming_back/comment_2_223550574fa69effabe57c4bf257e54b._comment b/doc/forum/dropped_files_keep_coming_back/comment_2_223550574fa69effabe57c4bf257e54b._comment
new file mode 100644
index 0000000000..3bad641bb8
--- /dev/null
+++ b/doc/forum/dropped_files_keep_coming_back/comment_2_223550574fa69effabe57c4bf257e54b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="git-annex@17927e6dc041ab425c14217a97a685adf3ecf44f"
+ nickname="git-annex"
+ avatar="http://cdn.libravatar.org/avatar/66e5c6e044d726597ce5a0ad68f86fe4"
+ subject="content expression is standard"
+ date="2020-06-04T20:28:01Z"
+ content="""
+Yes - it is set to standard.
+"""]]
diff --git a/doc/forum/dropped_files_keep_coming_back/comment_3_1a2ee19bfb3d56a2e2641dbcd89d8be2._comment b/doc/forum/dropped_files_keep_coming_back/comment_3_1a2ee19bfb3d56a2e2641dbcd89d8be2._comment
new file mode 100644
index 0000000000..e196bea5a2
--- /dev/null
+++ b/doc/forum/dropped_files_keep_coming_back/comment_3_1a2ee19bfb3d56a2e2641dbcd89d8be2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="git-annex@17927e6dc041ab425c14217a97a685adf3ecf44f"
+ nickname="git-annex"
+ avatar="http://cdn.libravatar.org/avatar/66e5c6e044d726597ce5a0ad68f86fe4"
+ subject="Actually they were not standard"
+ date="2020-06-04T21:05:30Z"
+ content="""
+The 'git annex wanted .' on the manual node returned nothing - so default.  I would have thought that that was 'standard'.  However, when setting it to standard, the files stopped rebounding.
+
+Christopher
+
+"""]]
diff --git a/doc/forum/dropped_files_keep_coming_back/comment_4_02a6e3591acfa410ed7c7917dc573663._comment b/doc/forum/dropped_files_keep_coming_back/comment_4_02a6e3591acfa410ed7c7917dc573663._comment
new file mode 100644
index 0000000000..8eac006385
--- /dev/null
+++ b/doc/forum/dropped_files_keep_coming_back/comment_4_02a6e3591acfa410ed7c7917dc573663._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="git-annex@17927e6dc041ab425c14217a97a685adf3ecf44f"
+ nickname="git-annex"
+ avatar="http://cdn.libravatar.org/avatar/66e5c6e044d726597ce5a0ad68f86fe4"
+ subject="Actually they were not standard"
+ date="2020-06-04T21:05:48Z"
+ content="""
+The 'git annex wanted .' on the manual node returned nothing - so default.  I would have thought that that was 'standard'.  However, when setting it to standard, the files stopped rebounding.
+
+Christopher
+
+"""]]
diff --git a/doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__.mdwn b/doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__.mdwn
new file mode 100644
index 0000000000..2fd18f9888
--- /dev/null
+++ b/doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__.mdwn
@@ -0,0 +1,24 @@
+I have Ubuntu and Debian systems, playing with git-annex. This is not mission critical data, just testing. I ended up with an extra duplicate of the media files on the laptop.
+
+The whereis listing is lots and lots like this:
+
+whereis 00-Unsorted/2008-RobustStats-AmerPsyc.pdf (3 copies)
+        67e69242-d57c-4b50-aaf9-74876b899962
+        9e0bc9e4-f8bf-11e3-b9c1-9b4158540a9d -- pols110.pols.ku.edu_mediashare (
+pdf and mp3)
+        d82d2e6f-9200-49cf-86a3-1d674a768971 -- here (pauljohn@dellap14:~/medias
+hare)
+ok
+
+(I'm pretty sure) This happened because I copied the media files to /home/pauljohn/mediashare/manuscripts manually, and then I used the git-annex assistant to set up the remote linkage to same content, from  the workstation, and it apparently copied in a whole new set. 
+
+How to clean this up? Without erasing everything and starting over?
+
+Can I guess? 
+
+Open a terminal and git remove manually 67e69242-d57c-4b50-aaf9-74876b899962 ???
+
+Thanks in advance if you care to advise me :)
+
+Paul Johnson
+http://pj.freefaculty.org
diff --git a/doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__/comment_1_bb6d749b758b17178227929bf7327fe1._comment b/doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__/comment_1_bb6d749b758b17178227929bf7327fe1._comment
new file mode 100644
index 0000000000..d528331cef
--- /dev/null
+++ b/doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__/comment_1_bb6d749b758b17178227929bf7327fe1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica Semrick"
+ subject="comment 1"
+ date="2014-06-24T04:24:12Z"
+ content="""
+You should first try `git-annex unused` and if that doesn't work just `git-annex drop` the unwanted files.
+"""]]
diff --git a/doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__/comment_2_d834df30633f7d5569797ee818cf38c3._comment b/doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__/comment_2_d834df30633f7d5569797ee818cf38c3._comment
new file mode 100644
index 0000000000..1f2cf2ff55
--- /dev/null
+++ b/doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__/comment_2_d834df30633f7d5569797ee818cf38c3._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkpIIYg6Fl7OFsOHVPEchZYj68A3dk4lVg"
+ nickname="Paul"
+ subject="please explain"
+ date="2014-07-01T13:45:08Z"
+ content="""
+Sorry. I just don't understand. 
+what am I doing wrong?  How to remove extra copy:
+
+<pre>
+whereis WaldTest/Vaeth_WaldTest.pdf (3 copies)
+        67e69242-d57c-4b50-aaf9-74876b899962
+        9e0bc9e4-f8bf-11e3-b9c1-9b4158540a9d -- pols110.pols.ku.edu_mediashare (pdf and mp3)
+        d82d2e6f-9200-49cf-86a3-1d674a768971 -- here (pauljohn@dellap14:~/mediashare)
+ok
+pauljohn@dellap14:~/mediashare/manuscripts$ git annex drop 67e69242-d57c-4b50-aaf9-74876b899962
+git-annex: 67e69242-d57c-4b50-aaf9-74876b899962 not found
+pauljohn@dellap14:~/mediashare/manuscripts$ git annex drop WaldTest/67e69242-d57c-4b50-aaf9-74876b899962
+git-annex: WaldTest/67e69242-d57c-4b50-aaf9-74876b899962 not found
+"""]]
diff --git a/doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__/comment_3_1e02eff33c9fa7bea03aa6d58b910175._comment b/doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__/comment_3_1e02eff33c9fa7bea03aa6d58b910175._comment
new file mode 100644
index 0000000000..b0061a9d0d
--- /dev/null
+++ b/doc/forum/duplicated_content___40__user_error__41__._How_to_fix__63__/comment_3_1e02eff33c9fa7bea03aa6d58b910175._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 3"
+ date="2014-07-03T19:20:49Z"
+ content="""
+\"67e69242-d57c-4b50-aaf9-74876b899962\" is the UUID of a git annnex repository that git-annex has on record as containing the file. Since it does not have a description set (which normally gets done automatically when setting up the repository), and is not one of the remotes of the repository where you ran `git annex whereis`, it's a bit hard to tell what repository that is.
+
+What I would do in this situation is:
+
+1. Look around my computers for a repository with that UUID. You can run this command in a repository to see its uuid: `git config annex.uuid`  
+2. If I found it, I'd run `git annex describe here \"something sensible\"` and maybe set it up as a remote of other repositories and then `git annex drop` the data from it if desired.
+3. If I was unable to find the repository, I might assume it was one I created before, and have removed. Then I'd tell git-annex that: `git annex dead 67e69242-d57c-4b50-aaf9-74876b899962` (if it turns out I was wrong and the repository turns up later, this can always be reversed by running `git annex semitrust 67e69242-d57c-4b50-aaf9-74876b899962`)
+"""]]
diff --git a/doc/forum/duplicates_with_suffixes_differing_only_in_case.mdwn b/doc/forum/duplicates_with_suffixes_differing_only_in_case.mdwn
new file mode 100644
index 0000000000..4084c7e7b2
--- /dev/null
+++ b/doc/forum/duplicates_with_suffixes_differing_only_in_case.mdwn
@@ -0,0 +1,27 @@
+I am using Google Cloud as a special remote to backup photos in one annex.
+
+It's in my interests, due to storage costs, to keep duplicates to a minimum. I've noticed that the cloud bucket has a lot more files than I would have expected.
+
+I performed the following to get the number of files in the bucket:
+
+[[!format sh """
+$ gsutil ls gs://cloud-<uuid>/ | wc -l
+<one large number>
+"""]]
+
+and of course, in the git-annex:
+
+[[!format sh """
+$ find . -path .git -o \( -type f -print \) | wc -l
+<one not as large number, about 60% of the larger number>
+"""]]
+
+When I took a sample of the list, I found may of the files that shared the exact key, but had, for example. both .jpg and .JPG suffixes.
+
+Some of these files, when checked with git-annex whereused --key=<each key with its cased suffix>, some were files I had maybe re-arranged in folders. I'm running a script at the moment to get a wider sample of what's happening with these duplicates.
+
+One of the problems I speculate may be coming into play is that I did originally copy files to the cloud remote via an older, Windows git-annex version (repo version I think at 5?).
+
+I think over time interoperability issues have ironed out, but this might be a remnant of when these were more prolific.... though I do still have one that I will report separately once I've gather more data.
+
+Any advise on how I might deal with the duplicates, get them deleted out of the bucket?
diff --git a/doc/forum/duplicates_with_suffixes_differing_only_in_case/comment_1_0c1bb4347902054ec97ef86eb903f060._comment b/doc/forum/duplicates_with_suffixes_differing_only_in_case/comment_1_0c1bb4347902054ec97ef86eb903f060._comment
new file mode 100644
index 0000000000..4395485dee
--- /dev/null
+++ b/doc/forum/duplicates_with_suffixes_differing_only_in_case/comment_1_0c1bb4347902054ec97ef86eb903f060._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ nickname="beryllium"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="comment 1"
+ date="2023-10-17T10:16:23Z"
+ content="""
+OK, please ignore. These scenarios account for only about 23 of the duplicates. There may still be, or have been, a problem.. maybe? Because I did add the same file in two different places,with the two case differing (but same) suffixes.
+
+I am running another audit to work out why I have so many more files in the cloud than reachable in the annex. I suppose it's because I removed files previously, but I'm not sure.
+
+"""]]
diff --git a/doc/forum/duplicates_with_suffixes_differing_only_in_case/comment_2_62bb4be1b31bd64a046763f68a2953ce._comment b/doc/forum/duplicates_with_suffixes_differing_only_in_case/comment_2_62bb4be1b31bd64a046763f68a2953ce._comment
new file mode 100644
index 0000000000..b07864e829
--- /dev/null
+++ b/doc/forum/duplicates_with_suffixes_differing_only_in_case/comment_2_62bb4be1b31bd64a046763f68a2953ce._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ nickname="beryllium"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="comment 2"
+ date="2023-10-17T10:28:51Z"
+ content="""
+Apologies again. I've realised that my count of the find command is totally wrong. It should be:
+
+[[!format sh \"\"\"
+$ find . -path .git -o \( \! -type d -print \) | wc -l
+<actually larger number... which is worrying in its own right>\"
+\"\"\"]]
+
+The reason being... for some reason I have some files that contain the key, and some actual symbolic links, all intermixed.
+
+Is there something I should do to make this all uniform?
+
+"""]]
diff --git a/doc/forum/duplicates_with_suffixes_differing_only_in_case/comment_3_99a2e752c75e5ad2ea36254627be8d18._comment b/doc/forum/duplicates_with_suffixes_differing_only_in_case/comment_3_99a2e752c75e5ad2ea36254627be8d18._comment
new file mode 100644
index 0000000000..59a5f68f6c
--- /dev/null
+++ b/doc/forum/duplicates_with_suffixes_differing_only_in_case/comment_3_99a2e752c75e5ad2ea36254627be8d18._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-10-20T17:52:06Z"
+ content="""
+git-annex preserves the filename extension as-is, it does not try to
+normalize it to lower case or anything. See discussion at
+[[todo/Lower-case_extension_for_SHA256E_and_similar]].
+
+You can configure git-annex to use SHA256 rather than the default SHA256E
+so the extension is not used and it will deduplicate better. Eg, in
+.gitattributes:
+
+	* annex.backend=SHA256
+
+You could then run `git-annex migrate` on existing files to switch them to
+that backend. Bear in mind that you would have to re-upload the files to
+your special remote, and would have to `git-annex dropunused --from`
+that remote to clean up the duplicate data stored there.
+"""]]
diff --git a/doc/forum/empty_directory_handling.mdwn b/doc/forum/empty_directory_handling.mdwn
new file mode 100644
index 0000000000..b806b2e2fe
--- /dev/null
+++ b/doc/forum/empty_directory_handling.mdwn
@@ -0,0 +1,3 @@
+I've just tried using git annex assistant for the first time, to synchronize a shared directory between machines. This shared directory contains a collection of bare git repositories for various projects. Unfortunately this doesn't seem to work, as to be recognised as valid bare repos, they need to have the ref/heads and ref/tags subdirectories. git annex assistant fails to synchronise these, as they are empty.
+
+What should I do? How can I make git annex reproduce the source directory structure when synchronising?
diff --git a/doc/forum/empty_directory_handling/comment_1_34ac97b9337b6230ed8a4748203fe543._comment b/doc/forum/empty_directory_handling/comment_1_34ac97b9337b6230ed8a4748203fe543._comment
new file mode 100644
index 0000000000..edf4984ea4
--- /dev/null
+++ b/doc/forum/empty_directory_handling/comment_1_34ac97b9337b6230ed8a4748203fe543._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-02T17:02:31Z"
+ content="""
+This is not a good idea. See <http://git-annex.branchable.com/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/#comment-29b91a7381453104e7bceea5e552cb85>
+"""]]
diff --git a/doc/forum/empty_directory_handling/comment_2_73a39e28d5a09ac342cb4195d263d91e._comment b/doc/forum/empty_directory_handling/comment_2_73a39e28d5a09ac342cb4195d263d91e._comment
new file mode 100644
index 0000000000..250c08adfd
--- /dev/null
+++ b/doc/forum/empty_directory_handling/comment_2_73a39e28d5a09ac342cb4195d263d91e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmlO6w9_FAVe3v6MdnkePxaTJqp0RPbGhM"
+ nickname="Tim"
+ subject="comment 2"
+ date="2014-07-04T04:00:25Z"
+ content="""
+Thanks - that thread was helpful. I now realise that what I was trying to do was not sensible, and I'll have to work out another approach.
+"""]]
diff --git a/doc/forum/enabling_git-annex-diffdriver_for_gitk.mdwn b/doc/forum/enabling_git-annex-diffdriver_for_gitk.mdwn
new file mode 100644
index 0000000000..c176764382
--- /dev/null
+++ b/doc/forum/enabling_git-annex-diffdriver_for_gitk.mdwn
@@ -0,0 +1,5 @@
+If `git` with `git-annex-diffdriver` is properly configured and works, is it possible to also get `gitk` to show these diffs?
+
+It seems that `gitk` in general does not apply diff-filters to symlinks and I was not able to find a way to make `gitk` show the same as `git` with `git-annex-diffdriver` does.
+
+Are there some tricks to make that possible somehow?
diff --git a/doc/forum/endless_password_prompt_loop.mdwn b/doc/forum/endless_password_prompt_loop.mdwn
new file mode 100644
index 0000000000..bfdd3c1dbc
--- /dev/null
+++ b/doc/forum/endless_password_prompt_loop.mdwn
@@ -0,0 +1,8 @@
+Hi,
+
+I setup a first repository on local disk, it went fine. Next I tried setting up repo on my nas to clone the files. I installed git-annex on the NAS (it's armel arch) and created the repository via webapp, I entered the password once. Git-annex started syncing the remote repo and after few seconds password pop-up hell broke loose. I was flooded with password-prompt pop-up windows. The synchronization was continuing regardless of correctly/incorrectly entered passwords. What's more, these popups grab the keyboard and you cannot do (appropriate word) with your system.
+
+I checked this topic: http://git-annex.branchable.com/forum/ssh_password/ and ssh config is in place on my computer and on the NAS.
+
+What is causing this and how can I get rid of this?
+
diff --git a/doc/forum/endless_password_prompt_loop/comment_1_cceba12ed25cd671c7cee5a28631163e._comment b/doc/forum/endless_password_prompt_loop/comment_1_cceba12ed25cd671c7cee5a28631163e._comment
new file mode 100644
index 0000000000..d162ff3e52
--- /dev/null
+++ b/doc/forum/endless_password_prompt_loop/comment_1_cceba12ed25cd671c7cee5a28631163e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 1"
+ date="2013-06-25T19:49:25Z"
+ content="""
+What version of git-annex? Did more than one password prompt window somehow appear at the same time? What is doing the ssh password prompting, is it ssh-askpass, or something provided by your desktop environment?
+
+What happens if you manually ssh from your computer to the NAS, using the special hostname that git-annex has configured (you can find this hostname in the `.git/config`). `ssh -v` is generally a good way to track these problems down.
+"""]]
diff --git a/doc/forum/endless_password_prompt_loop/comment_2_f0cb86b45eb289f35197c43f83660a8f._comment b/doc/forum/endless_password_prompt_loop/comment_2_f0cb86b45eb289f35197c43f83660a8f._comment
new file mode 100644
index 0000000000..45f87d136e
--- /dev/null
+++ b/doc/forum/endless_password_prompt_loop/comment_2_f0cb86b45eb289f35197c43f83660a8f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmUcCZeEK9HKV40JrcHMXAXpPKQPERt7iM"
+ nickname="Włodek"
+ subject="comment 2"
+ date="2013-07-10T22:00:47Z"
+ content="""
+Thanks for the answer. I found out that the public key auth is not working at all and ssh falls back to password auth, this is the reason for password prompts. What I don't know yet is why popups appear despite giving correct password. I'm looking for a solution. This can take some time though because my disk died few days ago = I cannot check versions. Once I've got it solved I'll post back.
+"""]]
diff --git a/doc/forum/endless_password_prompt_loop/comment_3_eb1dce6d9af6e19cf77df63da1a68425._comment b/doc/forum/endless_password_prompt_loop/comment_3_eb1dce6d9af6e19cf77df63da1a68425._comment
new file mode 100644
index 0000000000..58914c58e3
--- /dev/null
+++ b/doc/forum/endless_password_prompt_loop/comment_3_eb1dce6d9af6e19cf77df63da1a68425._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="damien.courousse"
+ subject="same behaviour when the remote repo is not reachable"
+ date="2015-05-01T15:47:55Z"
+ content="""
+hello,
+
+I experience the same behaviour : once git-annex is started using the assistant, the ssh askpass window keeps asking me for a password. 
+The repo is not reachable at this time (the server is down).
+
+What's really annoying is that the askpass window is sometimes hidden behind other windows, but it keeps grabbing keyboard events: it looks like the keyboard \"does not work\" anymore. Hopefully pressing escape shuts closes askpass.
+
+The askpass window still pop ups from time to time even once the assistant has been closed.
+
+Running git-annex version 5.20141125  on Debian (amd64) on jessie.
+"""]]
diff --git a/doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS.mdwn b/doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS.mdwn
new file mode 100644
index 0000000000..8d6f88f7d1
--- /dev/null
+++ b/doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS.mdwn
@@ -0,0 +1,52 @@
+Using [the precompiled git-annex distribution](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz), I have encountered a problem which looks like this:
+
+    git -c foo.bar=baz annex sync
+    error: bogus format in GIT_CONFIG_PARAMETERS
+    fatal: unable to parse command-line config
+    git-annex: user error (git ["config","--null","--list"] exited 128)
+
+I believe I understand what is causing this, and it's not a bug with git-annex.  But I thought it would be worth reporting here in case anyone else encounters similar issues in the future.
+
+On my system I have three different git installations:
+
+- The one in `/usr/bin/git` etc. provided by the distribution package (version 2.28.0)
+- One I've compiled myself in my home directory from a recent upstream `master`, accessible via `~/bin/git` (version 2.30.1.490.ge54fde04c8.dirty)
+- The one embedded in the git-annex bundle obtained from the above link, which I've put under `~/software/scm/git-annex.static/` (`~/software/scm/git-annex.static/shimmed/git/git --version` reports version 2.30.1)
+
+Normally `~/bin` is near the front of my `$PATH`, so my hand-compiled git is used whenever I run `git some-command`.  If I place the following executable script at `~/bin/git-show-config-params`:
+
+    #!/bin/sh
+    echo "$GIT_CONFIG_PARAMETERS"
+
+then it can be seen there's a difference between the versions in how `GIT_CONFIG_PARAMETERS` is constructed:
+
+    % ~/bin/git -c foo.bar=baz show-config-params
+    'foo.bar'='baz'
+    % /usr/bin/git -c foo.bar=baz show-config-params
+    'foo.bar=baz'
+    % ~/software/scm/git-annex.static/shimmed/git/git -c foo.bar=baz show-config-params
+    'foo.bar=baz'
+
+This appears to be due to [commit 294e949fa from 2021-01-25](https://git.kernel.org/pub/scm/git/git.git/commit/?id=294e949fa2dfd43097b2b5614470a3e43604663d) which first appeared in the tag `v2.31.0-rc0`.
+
+This commit is also required in order to successfully parse the new format:
+
+    % GIT_CONFIG_PARAMETERS="'foo.bar'='baz'" ~/software/scm/git-annex.static/shimmed/git/git branch
+    error: bogus format in GIT_CONFIG_PARAMETERS
+    fatal: unable to parse command-line config
+    % GIT_CONFIG_PARAMETERS="'foo.bar'='baz'" /usr/bin/git branch
+    error: bogus format in GIT_CONFIG_PARAMETERS
+    fatal: unable to parse command-line config
+    % GIT_CONFIG_PARAMETERS="'foo.bar'='baz'" ~/bin/git branch
+      git-annex
+    * master
+      synced/git-annex
+      synced/master
+
+So now we can fully understand the cause: when I run
+
+    git -c foo.bar=baz annex sync
+
+it first invokes the newer hand-compiled git with this patch, resulting in `GIT_CONFIG_PARAMETERS` being set to `'foo.bar'='baz'`.  That environment variable is then passed through various wrappers to `~/software/scm/git-annex.static/shimmed/git/git`, which does not know how to parse the new format, hence the `bogus format` error.
+
+The solution is to avoid using the newer development version of git as the "outer" git, since it's not backwards compatible in this respect.  If the two versions were switched around, i.e. the older one setting `GIT_CONFIG_PARAMETERS` and the newer parsing it, that would have worked fine, but of course that's not how the `git annex` wrapper system works.
diff --git a/doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS/comment_1_aa740c16099f24fd8a067ef23435d0d4._comment b/doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS/comment_1_aa740c16099f24fd8a067ef23435d0d4._comment
new file mode 100644
index 0000000000..d85905d5a9
--- /dev/null
+++ b/doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS/comment_1_aa740c16099f24fd8a067ef23435d0d4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-05T16:16:16Z"
+ content="""
+The git-annex.linux directory from the bundle does include a git, so if you
+put that directory in PATH first, it will avoid the problem.
+
+This should be a fairly transient problem, since the git-annex bundle is
+built with the version of git from debian unstable. Once the new git
+version gets released, it should fairly quickly get in there and the
+incompatability will stop being a problem.
+"""]]
diff --git a/doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS/comment_2_5bcd8554e33a716208ca205d7c0467df._comment b/doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS/comment_2_5bcd8554e33a716208ca205d7c0467df._comment
new file mode 100644
index 0000000000..8b8d47a8d3
--- /dev/null
+++ b/doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS/comment_2_5bcd8554e33a716208ca205d7c0467df._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-07-11T22:19:08Z"
+ content="""
+uff... ran into similar problem and since error is not really suggesting a reason for such odd behavior needed to search it up. In my case it was git-annex `10.20220624-1~ndall+1` which comes with `git` `2.30.2` and system-wide I have `2.35.1`.  Need to remember such a wisdom by heart unless may be the standalone build could somehow alert/complain into my face
+"""]]
diff --git a/doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS/comment_3_c3bca82915cc8bd35d3f41fc95436a18._comment b/doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS/comment_3_c3bca82915cc8bd35d3f41fc95436a18._comment
new file mode 100644
index 0000000000..5f68da24fb
--- /dev/null
+++ b/doc/forum/error__58___bogus_format_in_GIT__95__CONFIG__95__PARAMETERS/comment_3_c3bca82915cc8bd35d3f41fc95436a18._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-07-12T16:41:43Z"
+ content="""
+@yarik you're building git-annex standalone with the git from Debian stable
+right? If you updated it to a newer git 2.34 from backports, 
+you would not have this problem.
+
+Of the standalone builds of git-annex that I made, I think only the
+i386ancient one has an old enough git to have this problem.
+And probably people using that one will not have a recent version of
+git in the system and so won't be affected.
+"""]]
diff --git a/doc/forum/error__58___refs__47__heads__47__git-annex_does_not_point_to_a_valid_object__33__.mdwn b/doc/forum/error__58___refs__47__heads__47__git-annex_does_not_point_to_a_valid_object__33__.mdwn
new file mode 100644
index 0000000000..a39951bb50
--- /dev/null
+++ b/doc/forum/error__58___refs__47__heads__47__git-annex_does_not_point_to_a_valid_object__33__.mdwn
@@ -0,0 +1,17 @@
+for the command:
+
+    $ git annex info
+
+I get the following output:
+
+   repository mode: direct
+   trusted repositories: error: refs/heads/git-annex does not point to a valid object!
+   error: refs/heads/git-annex does not point to a valid object!
+   error: invalid object 100644 993859515190743e9bed7fc8e697d5ac4e2d03a0 for '01d/56e/SHA256E-s209799168--cb8450b63c699c5f8fb121e51ed7e387258d57c851b256af0e5ceeae9542ffd8.me.avi.log'
+   fatal: git-write-tree: error building trees
+   git-annex: failed to read sha from git write-tree
+
+Please help,
+Yuval Langer.
+
+BTW, the code formatting is kinda weird. Could you help with that as well?
diff --git a/doc/forum/error__58___refs__47__heads__47__git-annex_does_not_point_to_a_valid_object__33__/comment_1_d370b044da3bfebf9e4c90ce1e243587._comment b/doc/forum/error__58___refs__47__heads__47__git-annex_does_not_point_to_a_valid_object__33__/comment_1_d370b044da3bfebf9e4c90ce1e243587._comment
new file mode 100644
index 0000000000..cf7601d408
--- /dev/null
+++ b/doc/forum/error__58___refs__47__heads__47__git-annex_does_not_point_to_a_valid_object__33__/comment_1_d370b044da3bfebf9e4c90ce1e243587._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-05-15T20:22:40Z"
+ content="""
+This means that a git commit's data has gotten lost somehow. You can verify that by trying
+
+    git show 993859515190743e9bed7fc8e697d5ac4e2d03a0
+
+The most common reason for this to happen is if the system is shutdown unexpectedly while git-annex is running. Or, if this repository is on a removable drive, if it got removed before the data could be written.
+
+You can probably fix the problem by running:
+
+    git annex repair
+
+(Code formatting: Use 4 spaces.)
+"""]]
diff --git a/doc/forum/error_in_installation_of_base-4.5.0.0.mdwn b/doc/forum/error_in_installation_of_base-4.5.0.0.mdwn
new file mode 100644
index 0000000000..673222ed6d
--- /dev/null
+++ b/doc/forum/error_in_installation_of_base-4.5.0.0.mdwn
@@ -0,0 +1,14 @@
+Hi,
+
+I was trying to install git-annex, but then, I got a warning saying that I need to install base-4.5.0.0 first.
+
+So, I did "sudo cabal install base-4.5.0.0". Everything was going well, until I got this error:
+
+config.status: error: cannot find input file: `base.buildinfo.in'
+cabal: Error: some packages failed to install:
+base-4.5.0.0 failed during the configure step. The exception was:
+ExitFailure 1
+
+I tried to look for information on the internet, but I did not find anything useful.
+
+I know that this is not totally related to git-annex, but anyone has any thoughts on this?
diff --git a/doc/forum/error_in_installation_of_base-4.5.0.0/comment_1_0b2f79c014e0dd9badd52b8b6aa47e0c._comment b/doc/forum/error_in_installation_of_base-4.5.0.0/comment_1_0b2f79c014e0dd9badd52b8b6aa47e0c._comment
new file mode 100644
index 0000000000..5a52a28ab1
--- /dev/null
+++ b/doc/forum/error_in_installation_of_base-4.5.0.0/comment_1_0b2f79c014e0dd9badd52b8b6aa47e0c._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-04-22T05:39:28Z"
+ content="""
+git-annex needs ghc 7.4, that's why it depends on that base version that comes with it. So you either need to upgrade your ghc, or you can build from the `ghc7.0` branch in [[git|download]], like this:
+
+<pre>
+git clone git://git-annex.branchable.com/ git-annex
+cd git-annex
+git checkout ghc7.0
+cabal update
+cabal install --only-dependencies
+cabal configure
+cabal build
+cabal install --bindir=$HOME/bin
+</pre>
+"""]]
diff --git a/doc/forum/error_in_installation_of_base-4.5.0.0/comment_2_3badd64e48fbb174cd7de1ac9589bedf._comment b/doc/forum/error_in_installation_of_base-4.5.0.0/comment_2_3badd64e48fbb174cd7de1ac9589bedf._comment
new file mode 100644
index 0000000000..3ad1a11388
--- /dev/null
+++ b/doc/forum/error_in_installation_of_base-4.5.0.0/comment_2_3badd64e48fbb174cd7de1ac9589bedf._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkaT0B6s9jQuMzQUYRVBgWqtO7BhT_ZSaE"
+ nickname="Fernando Seabra"
+ subject="comment 2"
+ date="2012-04-22T14:09:33Z"
+ content="""
+Thanks for the fast response!
+
+Unfortunately, I had another problem:
+
+==================================
+Building git-annex-3.20120419...
+Utility/libdiskfree.c: In function ‘diskfree’:
+
+Utility/libdiskfree.c:61:0:
+     warning: ‘statfs64’ is deprecated (declared at /usr/include/sys/mount.h:379)
+[  6 of 157] Compiling Build.SysConfig  ( Build/SysConfig.hs, dist/build/git-annex/git-annex-tmp/Build/SysConfig.o )
+[ 15 of 157] Compiling Utility.Touch    ( dist/build/git-annex/git-annex-tmp/Utility/Touch.hs, dist/build/git-annex/git-annex-tmp/Utility/Touch.o )
+
+Utility/Touch.hsc:118:21: Not in scope: `noop'
+cabal: Error: some packages failed to install:
+git-annex-3.20120419 failed during the building phase. The exception was:
+ExitFailure 1
+==================================
+
+I also tried to look for information on the internet, and I did not find anything useful.
+Any idea of what happened?
+
+Thanks again!
+
+"""]]
diff --git a/doc/forum/error_in_installation_of_base-4.5.0.0/comment_3_d8190061ac1c683a7b699cf42e9db694._comment b/doc/forum/error_in_installation_of_base-4.5.0.0/comment_3_d8190061ac1c683a7b699cf42e9db694._comment
new file mode 100644
index 0000000000..d9de5089e9
--- /dev/null
+++ b/doc/forum/error_in_installation_of_base-4.5.0.0/comment_3_d8190061ac1c683a7b699cf42e9db694._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2012-04-22T15:23:26Z"
+ content="""
+That's my fault, I made a change last night that caused the noop problem. Fixed now.
+"""]]
diff --git a/doc/forum/error_in_installation_of_base-4.5.0.0/comment_4_49a4fcd2dc4f97d4055b5051feea5e3b._comment b/doc/forum/error_in_installation_of_base-4.5.0.0/comment_4_49a4fcd2dc4f97d4055b5051feea5e3b._comment
new file mode 100644
index 0000000000..ba99334511
--- /dev/null
+++ b/doc/forum/error_in_installation_of_base-4.5.0.0/comment_4_49a4fcd2dc4f97d4055b5051feea5e3b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkaT0B6s9jQuMzQUYRVBgWqtO7BhT_ZSaE"
+ nickname="Fernando Seabra"
+ subject="comment 4"
+ date="2012-04-22T16:08:55Z"
+ content="""
+Thanks, it worked now!
+"""]]
diff --git a/doc/forum/error_setting_up_centralized_server_on_OSX_-_failed_to_get_annex.uuid_configuration_of_repository_origin.mdwn b/doc/forum/error_setting_up_centralized_server_on_OSX_-_failed_to_get_annex.uuid_configuration_of_repository_origin.mdwn
new file mode 100644
index 0000000000..647557e7da
--- /dev/null
+++ b/doc/forum/error_setting_up_centralized_server_on_OSX_-_failed_to_get_annex.uuid_configuration_of_repository_origin.mdwn
@@ -0,0 +1,19 @@
+I'm attempting to set up a centralized git repository to use with git-annex as specified on https://git-annex.branchable.com/tips/centralized_git_repository_tutorial/on_your_own_server/
+
+I'm using macbooks as clients and servers. They are all running git-annex version 5.20150916 installed through homebrew. The server is running 10.10 Yosemite and the clients are running 10.9 Mavericks. There is a symlink on the server in ```/usr/bin/git-annex``` and ```/usr/bin/git-annex-shell``` to ```/usr/local/bin/git-annex``` and ```/usr/local/bin/git-annex-shell```, which then symlinks to the latest version in homebrew's directories. I did this because I was previously facing an error where git-annex was not found on the server (it would not work if you ran <code>ssh tom@server git-annex</code>).
+
+I'm currently at the step after cloning and cding into the repository on the client. When I attempt to run <code>git annex init 'Tom Macbook'</code>, I get the following error:
+
+```
+git annex init 'Tom Macbook'
+init Tom Macbook
+Failed to get annex.uuid configuration of repository origin
+
+Instead, got: "annex.uuid=\ncore.gcrypt-id=\n"
+
+This is unexpected; please check the network transport!
+ok
+(recording state in git...)
+```
+
+I'm really stumped here. Any suggestions? Thanks. Let me know if I can provide any further info. 
diff --git a/doc/forum/error_setting_up_centralized_server_on_OSX_-_failed_to_get_annex.uuid_configuration_of_repository_origin/comment_1_943ff286824bd59a164b161553d65698._comment b/doc/forum/error_setting_up_centralized_server_on_OSX_-_failed_to_get_annex.uuid_configuration_of_repository_origin/comment_1_943ff286824bd59a164b161553d65698._comment
new file mode 100644
index 0000000000..eed9dfda96
--- /dev/null
+++ b/doc/forum/error_setting_up_centralized_server_on_OSX_-_failed_to_get_annex.uuid_configuration_of_repository_origin/comment_1_943ff286824bd59a164b161553d65698._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-10-15T18:55:42Z"
+ content="""
+Yeah, this is a bug, and one I was able to reproduce. It was introduced in
+the last release of git-annex.
+
+Luckily, it's only a cosmetic bug. The `git annex init` does
+succeed, and your repo is left in an ok state. If you continue
+along the walkthrough path, adding some files and syncing with origin, it
+will proceed to set up the origin appropriately and everything should work.
+
+I'm gonna fix the bug of course. Indeed, it's fixed in git master now.
+"""]]
diff --git a/doc/forum/example_of_massively_disconnected_operation.mdwn b/doc/forum/example_of_massively_disconnected_operation.mdwn
new file mode 100644
index 0000000000..78ed6784b2
--- /dev/null
+++ b/doc/forum/example_of_massively_disconnected_operation.mdwn
@@ -0,0 +1,33 @@
+I found this archival drive that had been offline since October 26th 2010. Since I released git-annex 0.02 on October 27th, this must have been made using the very first release of git-annex, ever.
+
+So, I synced it back up! :) --[[Joey]]
+
+<pre>
+commit 4151f4595fe6205d4aed653617ab23eb3335130a
+Author: Joey Hess <id@joeyh.name>
+Date:   Tue Oct 26 02:18:03 2010 -0400
+
+joey> git pull
+remote: Counting objects: 428782, done.
+remote: Compressing objects: 100% (280714/280714), done.
+remote: Total 416692 (delta 150923), reused 389593 (delta 125143)
+Receiving objects: 100% (416692/416692), 44.71 MiB | 495 KiB/s, done.
+Resolving deltas: 100% (150923/150923), completed with 818 local objects.
+ * [new branch]      git-annex  -> origin/git-annex
+   1893f9c..9ebcc0e  master     -> origin/master
+Updating 1893f9c..9ebcc0e
+Checking out files: 100% (76884/76884), done.
+joey> git annex version
+git-annex version: 3.20110611
+local repository version: unknown
+default repository version: 3
+supported repository versions: 3
+upgrade supported from repository versions: 0 1 2
+joey> git config annex.version 0
+joey> git annex upgrade
+upgrade . (v0 to v1...) (v1 to v2) (moving content...) (updating symlinks...)  (moving location logs...) (v2 to v3) (merging origin/git-annex into git-annex...)
+
+  git-annex branch created
+  Be sure to push this branch when pushing to remotes.
+ok
+</pre>
diff --git a/doc/forum/exclude_files_from_annex.mdwn b/doc/forum/exclude_files_from_annex.mdwn
new file mode 100644
index 0000000000..c1707afb13
--- /dev/null
+++ b/doc/forum/exclude_files_from_annex.mdwn
@@ -0,0 +1,10 @@
+I'm wanting to do essentially [[/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/]], that is prevent git-annex from annexing certain files (by extension), and rather manage them in git only.
+
+This seems to work fine, and the assistant auto-adds them to git, and commits when I make changes, when in indirect mode.
+
+However, in a direct mode repository, then the files are automatically annexed, and even if I create them in an indirect repo, and then change it, they are annexed.
+
+Is this expected behaviour? Does the annex.largefiles setting only make sense in indirect mode?
+
+
+--Walter
diff --git a/doc/forum/exclude_files_from_annex/comment_1_82e7de5e631bae3b347815586274a936._comment b/doc/forum/exclude_files_from_annex/comment_1_82e7de5e631bae3b347815586274a936._comment
new file mode 100644
index 0000000000..23ad6aac92
--- /dev/null
+++ b/doc/forum/exclude_files_from_annex/comment_1_82e7de5e631bae3b347815586274a936._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-19T20:29:14Z"
+ content="""
+I don't seem to be seeing the problem you describe in direct mode:
+
+[[!format sh \"\"\"
+
+joey@gnu:~/tmp/r2>git init
+joey@gnu:~/tmp/r2>git annex init
+joey@gnu:~/tmp/r2>git config annex.largefiles \"largerthan=100kb and not (include=*.c or include=*.h)\"
+joey@gnu:~/tmp/r2>git annex direct
+joey@gnu:~/tmp/r2>git annex assistant 
+joey@gnu:~/tmp/r2>dd if=/dev/urandom of=bigfile bs=1M count=1
+1+0 records in
+1+0 records out
+joey@gnu:~/tmp/r2>echo \"main() { printf(\"hello, world!\n\") }\" > hello.c
+\"\"\"]]
+
+At that point, the bigfile was annexed, and the hello.c file was checked into git as a regular file.
+
+Are you sure you have annex.largefiles correctly configured to exclude the files you don't want to be annexed?
+"""]]
diff --git a/doc/forum/exclude_files_from_annex/comment_2_03d4599fdceb3dff184eed82824674bc._comment b/doc/forum/exclude_files_from_annex/comment_2_03d4599fdceb3dff184eed82824674bc._comment
new file mode 100644
index 0000000000..7d8f6ce772
--- /dev/null
+++ b/doc/forum/exclude_files_from_annex/comment_2_03d4599fdceb3dff184eed82824674bc._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
+ nickname="Walter"
+ subject="comment 2"
+ date="2013-05-19T21:35:37Z"
+ content="""
+This seems to have stopped happening, after I installed a newer version (from git) of git-annex.
+
+I might try and recreate it later, but for now it seems to work as expected.
+
+Thanks for your help.
+"""]]
diff --git a/doc/forum/expire_files__44___move_to_other_hosts.mdwn b/doc/forum/expire_files__44___move_to_other_hosts.mdwn
new file mode 100644
index 0000000000..9ead2f899c
--- /dev/null
+++ b/doc/forum/expire_files__44___move_to_other_hosts.mdwn
@@ -0,0 +1,19 @@
+Before turning this into a 'todo' item i'd like to discuss the possibilities...
+
+The idea is following:
+
+Having a Laptop with a rather small SSD or some other mobile device i'd like to move files away which are not needed anymore.
+The first thing is that the --to destination should be semi-automatically choosen, including ensuring enough replicas
+
+    git annex move --away <path..>
+
+should pick remotes which are suitable (either by configuration and/or other rules like disk utilization on the remote side).
+
+I am rather new to git-annex and wondering if there is currently already something which gives similar results, esp not need to hand pick the remotes where to move files.
+
+Further on there needs to be some way to find out which files are not needed anymore. On a first thought filtering by 'atime' would be nice, but nowadays mounting with noatime/relatime is common which would make this infeasible. To accomplish this, the assistant could (optionally) manage a lazy-atime by setting inotify or fanotify watches on all annexed files in a repository (close_nowrite) and queue/batch atime updates coarsely together. Then atimes on disk are only lazily updated (after some time expires, when the queue becomes full or at shutdown of the assistant), we can afford to loose some atime updates here in case of unexpected shutdowns (i rather wonder why the kernel has no lazy-atime option).
+
+Then the assistant (or by crontab) one can schedule some regular maintenance. There are certainly plenty of options to consider here, for example a mobile device might prefer only to send files if connected to Wlan, someone wants to move files away until a certain threshold of free disk space is reached etc...
+ 
+While at this, the assistant could also watch (fanotify) if someone tries to open a not available (dead symlinked) file, block that request, get the file and then proceed with the request.
+
diff --git a/doc/forum/expire_files__44___move_to_other_hosts/comment_1_ddcc2a00be1ae96a352d75a443458bcf._comment b/doc/forum/expire_files__44___move_to_other_hosts/comment_1_ddcc2a00be1ae96a352d75a443458bcf._comment
new file mode 100644
index 0000000000..a23a214948
--- /dev/null
+++ b/doc/forum/expire_files__44___move_to_other_hosts/comment_1_ddcc2a00be1ae96a352d75a443458bcf._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 1"
+ date="2013-07-30T19:14:25Z"
+ content="""
+I think that you're conflating two different features.
+
+First, there's the question of determining which remotes should store a file. The [[preferred_content]] expressions are a way to let the user define this in a way that makes sense for their setup. There's also the annex.diskreserve setting, to allow a remote to reject a file if it doesn't have space. The git-annex assistant can automatically apply those, and arrange to transfer files to all remotes that want a copy. Or you can do it on the command line using --auto. Perhaps it would be nice to have a `git annex copy --auto --to any`, to avoid needing to run copy multiple times to send to different remotes.
+
+Second, there's the concept of expiring files. I don't think relatime would prevent using atime for this (git-annex could just set the atime to 0 when it first gets a file to work around relatime), and I don't like the idea of inotify watching all files just to work around noatime. I suppose that the preferred content expressions could have an atime check operation added to them. Although I guess you could just as well use `find`..
+
+(Finally, I don't think there's a good way to block processes that are trying to open files that are not there, without using FuSE. And I don't know that a system that could block any program indefinitely waiting on some large files being pulled down from wherever would be one I'd want to use. This has prevented me from going down that path so far.)
+"""]]
diff --git a/doc/forum/expire_files__44___move_to_other_hosts/comment_2_7a4c3858c5eae409d04de3f9da43b57e._comment b/doc/forum/expire_files__44___move_to_other_hosts/comment_2_7a4c3858c5eae409d04de3f9da43b57e._comment
new file mode 100644
index 0000000000..ea1e680745
--- /dev/null
+++ b/doc/forum/expire_files__44___move_to_other_hosts/comment_2_7a4c3858c5eae409d04de3f9da43b57e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="cehteh"
+ ip="217.8.62.137"
+ subject="comment 2"
+ date="2013-07-30T20:29:11Z"
+ content="""
+I agree here are even more than 2 features involved.
+
+I'd appreciate a 'git annex copy --auto --to any' like feature. The point is that this should not only copy data until diskreserve is hit but distribute data in some (configureable) way around all remotes. Preferred content is one part of that, available disksize another. The user might also choose destinations depending on location and bandwidth and balance load over multiple servers until enough replicas are distributed. Details have to be worked out.
+
+Expiring content is another thing, i also thinking its most likely improper to add some atime watching thing to git-annex. Instead of that I am thinking to write a dedicated daemon which handles atime updates in userspace, this then could add some more rules to ignore accesses by other system tools (file indexers, users, etc). This makes such a expire facility completely independent from git annex and a user can choose if/what he likes.
+
+Filtering out files which are not accessed recently can then be done by 'find' or something similar and piped into 'git annex move/copy/drop'.
+
+And for your final note: fanotify can block accesses to files, it might be a bit ugly and certainly this is not for everyone, perhaps this could be externalized into some watching daemon too or if integrated to git-annex be treated very carefully and only be used if explicitly configured.
+
+"""]]
diff --git a/doc/forum/export_single_file.mdwn b/doc/forum/export_single_file.mdwn
new file mode 100644
index 0000000000..6c15e5db41
--- /dev/null
+++ b/doc/forum/export_single_file.mdwn
@@ -0,0 +1,3 @@
+I am following the instructions at [tips/publishing_your_files_to_the_public](https://git-annex.branchable.com/tips/publishing_your_files_to_the_public/) to export trees to a public remote. Often I want to just share a single file publicly with someone, not an entire folder (which is what export supports).
+
+For example I am using [git-annex-remote-googledrive](https://github.com/Lykos153/git-annex-remote-googledrive) and I have created a new folder with public read access from drive.google.com. If I set this folder up as an exporttree remote I could then export a local annexed sub-folder to it. What I really want though is to pick a single file to share publicly with someone and send that to my public folder. Does anyone have thoughts on an existing workflow that might achieve this?
diff --git a/doc/forum/export_single_file/comment_1_36d97e3c3f07411f3d367da546759ea5._comment b/doc/forum/export_single_file/comment_1_36d97e3c3f07411f3d367da546759ea5._comment
new file mode 100644
index 0000000000..bce75fa76c
--- /dev/null
+++ b/doc/forum/export_single_file/comment_1_36d97e3c3f07411f3d367da546759ea5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-11-17T18:17:27Z"
+ content="""
+And some more detail… I am implementing a feature in [git-annex-turtle](https://github.com/andrewringler/git-annex-turtle) where you can right-click on a file, select Share and have that file uploaded to some public place, then i'll let the user know the public URL so they can share it (perhaps by placing it in their copy-paste buffer). I thought at first I could use [git-annex export](http://git-annex.branchable.com/git-annex-export/) but I don't think it is really designed for this use case. I think export is meant to export a tree to a non-git-ish place and then merge changes into that remote tree as you make changes locally.
+"""]]
diff --git a/doc/forum/export_single_file/comment_2_ec3d3fb7beb3312571ffa471c39aaf95._comment b/doc/forum/export_single_file/comment_2_ec3d3fb7beb3312571ffa471c39aaf95._comment
new file mode 100644
index 0000000000..ca5edb60d8
--- /dev/null
+++ b/doc/forum/export_single_file/comment_2_ec3d3fb7beb3312571ffa471c39aaf95._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 2"
+ date="2018-11-17T19:13:24Z"
+ content="""
+OK. It looks like one way I could achieve this is by following these instructions [old method](https://git-annex.branchable.com/tips/publishing_your_files_to_the_public/old_method/). Basically just `git annex copy --to` the file to a public s3 repo without encryption and without chunking and with `public=yes` then grab the URL.
+
+It seems this should also work for any remote that supports `WHEREIS Key` for getting a URL from any key.
+"""]]
diff --git a/doc/forum/export_single_file/comment_3_0761201bf68e1086d263776eb953c1e1._comment b/doc/forum/export_single_file/comment_3_0761201bf68e1086d263776eb953c1e1._comment
new file mode 100644
index 0000000000..5f9812f6e1
--- /dev/null
+++ b/doc/forum/export_single_file/comment_3_0761201bf68e1086d263776eb953c1e1._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-12-09T15:22:09Z"
+ content="""
+`git annex export` only exports trees, but you can easily make a tree
+containing only a single file, and then export that. 
+
+For example:
+
+	mkdir exporttree
+	cp tests/tests1.mov exporttree
+	git annex add exporttree
+	git commit -m 'created export tree'
+	git annex export master:exporttree --to public
+
+If you don't want to commit that you can switch to a temporary branch
+and build the tree there. Or there are plenty of lower-level git commands
+to build trees.
+"""]]
diff --git a/doc/forum/export_tracking_not_enabled_when_branch_is_set.mdwn b/doc/forum/export_tracking_not_enabled_when_branch_is_set.mdwn
new file mode 100644
index 0000000000..2618dc3926
--- /dev/null
+++ b/doc/forum/export_tracking_not_enabled_when_branch_is_set.mdwn
@@ -0,0 +1,34 @@
+currently i am running into an issue when trying to export to my android device using the adb special remote, basically git annex won't export files to it after listing and importing them because it does not think the tracking branch is set, even though it is (ga is an alias i have for "git annex")
+
+
+    git remote
+    moto
+    motoE5
+    seagate2tb
+    seagate5tb
+    shouseServer
+    ga sync --content moto
+    commit
+    On branch master
+    Your branch is ahead of 'seagate5tb/master' by 12 commits.
+      (use "git push" to publish your local commits)
+
+    nothing added to commit but untracked files present (use "git add" to track)
+    ok
+    list moto ok
+    update refs/remotes/moto/master ok
+    Not updating export to moto to reflect changes to the tree, because export tracking is not enabled.  (Set remote.moto.annex-tracking-branch to enable it.)
+
+but when i run    
+
+    git config remote.moto.annex-tracking-branch
+
+i get a result because i have it set
+
+    master:devices/motoE5
+
+this seems to be a bug, but i wanted to make sure i wasn't doing something wrong before submitting a bug report.
+
+[[!tag forumbug]]
+
+> [[bugs/done]] --[[Joey]]
diff --git a/doc/forum/export_tracking_not_enabled_when_branch_is_set/comment_1_c007c52d0a038c26e4f8fc50a2d23a18._comment b/doc/forum/export_tracking_not_enabled_when_branch_is_set/comment_1_c007c52d0a038c26e4f8fc50a2d23a18._comment
new file mode 100644
index 0000000000..8ec3b8f6bf
--- /dev/null
+++ b/doc/forum/export_tracking_not_enabled_when_branch_is_set/comment_1_c007c52d0a038c26e4f8fc50a2d23a18._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-12-22T16:56:18Z"
+ content="""
+I think I see how this could happen. seekExportContent
+checks if remoteAnnexTrackingBranch is set. If it is, 
+it tries to list the tree for that branch, and also gets
+the export commit for that branch. If either of those actions fail, it
+displays the message you saw, the same as if remoteAnnexTrackingBranch
+had not been set.
+
+Hmm, I think the most likely reason is that master:devices/motoE5
+does not exist yet, so it fails to list the tree for it.
+
+If so, doing a single time `git-annex import --from moto master:devices/motoE5` 
+would probably make sync work.
+
+At least the message needs to be improved. It may also be that something
+needs to be done to prevent needing to run git-annex import before sync
+will work, or the documentation better document that you need to do it,
+or the message suggest doing it when this happens.
+
+I do notice that in the [[git-annex-import]] man page, the example
+does a single time `git-annex import` of the branch before setting the
+git config and using sync.
+
+I've promoted this thread to a bug report.
+"""]]
diff --git a/doc/forum/export_tracking_not_enabled_when_branch_is_set/comment_2_12c90792bd8c0c37bc53806843583733._comment b/doc/forum/export_tracking_not_enabled_when_branch_is_set/comment_2_12c90792bd8c0c37bc53806843583733._comment
new file mode 100644
index 0000000000..e798dd7d0d
--- /dev/null
+++ b/doc/forum/export_tracking_not_enabled_when_branch_is_set/comment_2_12c90792bd8c0c37bc53806843583733._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-12-23T17:45:07Z"
+ content="""
+Aha! I was able to reproduce it by following [[tips/android_sync_with_adb]],
+but only configure the remote with exporttree=yes, while leaving off the
+importtree=yes.
+
+	git init foo
+	cd foo
+	git-annex init
+	git-annex initremote d type=directory directory=../d encryption=none exporttree=yes
+	git config remote.d.annex-tracking-branch master:d
+	touch foo
+	git annex add foo
+	git-annex sync --content d
+
+Alternatively -- and I think this is probably what you did -- do include
+importtree=yes, but the special remote is actually empty, it does not
+include any files to import yet. And the directory you have configured to
+export does not exist in your repository.
+
+In both these cases, the export fails because it is unable to determine what
+to export to the remote, because the current branch does not contain the
+subdirectory that it's configured to export.
+
+I have fixed the warning message in this case, and the thing to do is just to
+create the subdirectory you configured it to export, and git add files to it.
+Or, in your case, you could put a file on the android device, which it would
+then import, and so get the subdirectory populated that way.
+"""]]
diff --git a/doc/forum/exporting_annexed_files.mdwn b/doc/forum/exporting_annexed_files.mdwn
new file mode 100644
index 0000000000..0b8d6f36b2
--- /dev/null
+++ b/doc/forum/exporting_annexed_files.mdwn
@@ -0,0 +1,4 @@
+Is there an easy way to export annexed files out of the repository? (e.g. to make a copy elsewhere, send a file by email...)
+
+Thanks,
+Denis.
diff --git a/doc/forum/exporting_annexed_files/comment_1_e08e4c79588e17fb2f1cdf53d9fab7ea._comment b/doc/forum/exporting_annexed_files/comment_1_e08e4c79588e17fb2f1cdf53d9fab7ea._comment
new file mode 100644
index 0000000000..69fc46245f
--- /dev/null
+++ b/doc/forum/exporting_annexed_files/comment_1_e08e4c79588e17fb2f1cdf53d9fab7ea._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.135"
+ subject="comment 1"
+ date="2012-06-15T19:25:59Z"
+ content="""
+Sure, you can simply:
+
+    cp annexedfile ~
+
+Or just attach the file right from the git repository to an email, like any other file. Should work fine.
+
+If you wanted to copy a whole directory to export, you'd need to use the -L flag to make cp follow the symlinks and copy the real contents:
+
+    cp -r -L annexeddirectory /media/usbdrive/
+"""]]
diff --git a/doc/forum/exporting_annexed_files/comment_2_15dc3024417b5b2ff3544a08beacab34._comment b/doc/forum/exporting_annexed_files/comment_2_15dc3024417b5b2ff3544a08beacab34._comment
new file mode 100644
index 0000000000..3621f9b895
--- /dev/null
+++ b/doc/forum/exporting_annexed_files/comment_2_15dc3024417b5b2ff3544a08beacab34._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://denis.laxalde.org/"
+ nickname="dlax"
+ subject="nautilus"
+ date="2012-06-15T19:57:31Z"
+ content="""
+Ah! I was fooled by nautilus which is not able to properly handle symlinks when copying. It copies links instead of target [[!gnomebug 623580]].
+"""]]
diff --git a/doc/forum/exporting_annexed_files/comment_3_86f0e0f767a84a0f583e121d36cb7d48._comment b/doc/forum/exporting_annexed_files/comment_3_86f0e0f767a84a0f583e121d36cb7d48._comment
new file mode 100644
index 0000000000..db6f90d881
--- /dev/null
+++ b/doc/forum/exporting_annexed_files/comment_3_86f0e0f767a84a0f583e121d36cb7d48._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.135"
+ subject="comment 3"
+ date="2012-06-16T03:26:37Z"
+ content="""
+That nautilous behavior is a bad thing when trying to export files out, but it's a good thing when just moving files around inside your repository...
+"""]]
diff --git a/doc/forum/exporttree__61__yes_always_untrusted__63__.mdwn b/doc/forum/exporttree__61__yes_always_untrusted__63__.mdwn
new file mode 100644
index 0000000000..fb030b9692
--- /dev/null
+++ b/doc/forum/exporttree__61__yes_always_untrusted__63__.mdwn
@@ -0,0 +1,5 @@
+The update for version 10.20220525 says:
+
+>Special remotes with importtree=yes or exporttree=yes are once again treated as untrusted, since files stored in them can be deleted or modified at any time.
+
+Even in an S3 special remote with versioning enabled?
diff --git a/doc/forum/exporttree__61__yes_always_untrusted__63__/comment_1_fb579729238a36d5c3369ed07dd772ae._comment b/doc/forum/exporttree__61__yes_always_untrusted__63__/comment_1_fb579729238a36d5c3369ed07dd772ae._comment
new file mode 100644
index 0000000000..165273ee4d
--- /dev/null
+++ b/doc/forum/exporttree__61__yes_always_untrusted__63__/comment_1_fb579729238a36d5c3369ed07dd772ae._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-31T16:53:47Z"
+ content="""
+Versioned remotes are still not untrusted.
+"""]]
diff --git a/doc/forum/external_special_remote_protocol_and_threads.mdwn b/doc/forum/external_special_remote_protocol_and_threads.mdwn
new file mode 100644
index 0000000000..93b370d4e2
--- /dev/null
+++ b/doc/forum/external_special_remote_protocol_and_threads.mdwn
@@ -0,0 +1,3 @@
+As the sync command just got a -J option I have started to use threads to transfer new files to multiple remotes in parallel. A question that arises is if I still can assume that only one instance of the special remote will be started. I tend to store quite some state in the special remote program that I use to connect to a cloud server, and running two instances in parallel might run in to all sorts of fun behavior.
+
+That said, I am of course aware that if I run multiple git annex commands I would run into these problems.
diff --git a/doc/forum/external_special_remote_protocol_and_threads/comment_1_f29c2b0f0f5e349e36eb47176e33498f._comment b/doc/forum/external_special_remote_protocol_and_threads/comment_1_f29c2b0f0f5e349e36eb47176e33498f._comment
new file mode 100644
index 0000000000..8448052da2
--- /dev/null
+++ b/doc/forum/external_special_remote_protocol_and_threads/comment_1_f29c2b0f0f5e349e36eb47176e33498f._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-10-02T16:14:20Z"
+ content="""
+Well, I can confirm that only one instance of any 
+external special remote will be run per git-annex process currently. 
+
+Actually, it's a bit more than that -- If multiple threads try to use the
+same external special remote at the same time, everything is necessarily
+serialized, and so using -J won't let multiple downloads happen at once
+from a single external special remote, although it may still usefuly
+parallelize amoung several remotes.
+
+Since that seems like something worth dealing with, perhaps by having a
+pool of external special remote processes, I don't feel comfortable making
+any promises about the behavior. And as you note, it's easy to get multiple
+procesess by running multiple git-annex commands, so that is something an
+external special remote needs to deal with anyway.
+"""]]
diff --git a/doc/forum/external_special_remote_protocol_and_threads/comment_2_df97223aad2c8c95ce109944d64a59fe._comment b/doc/forum/external_special_remote_protocol_and_threads/comment_2_df97223aad2c8c95ce109944d64a59fe._comment
new file mode 100644
index 0000000000..11ce16ac83
--- /dev/null
+++ b/doc/forum/external_special_remote_protocol_and_threads/comment_2_df97223aad2c8c95ce109944d64a59fe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
+ nickname="Carl"
+ subject="comment 2"
+ date="2015-10-04T07:49:02Z"
+ content="""
+Thanks for a clear answer. It seems that I am still in the sweet spot for using -J4. I.e transport everything to multiple remotes in parallel. 
+
+I do however take it as a recommendation to be careful, and will give it another consideration to be careful in case of doing more development work and releasing it.
+"""]]
diff --git a/doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__.mdwn b/doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__.mdwn
new file mode 100644
index 0000000000..633ff6f9bc
--- /dev/null
+++ b/doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__.mdwn
@@ -0,0 +1,26 @@
+First, I'm using a 2011 version because i'm getting this kind of errors from cabal install (on Fedora 16 and 17):
+
+    $ cabal install git-annex --bindir=$HOME/.local/bin
+    Resolving dependencies...
+    cabal: cannot configure git-annex-3.20120406. It requires base >=4.5 && <5
+    For the dependency on base >=4.5 && <5 there are these packages: base-4.5.0.0.
+    However none of them are available.
+    base-4.5.0.0 was excluded because of the top level dependency base -any
+
+So I installed a 2011 version and it worked.
+
+Now, when I add some files in the git annex repository I get an error:
+
+    $ git annex add Photo\ Library/2010/06/28/IMG_4926.JPG
+    add Photo Library/2010/06/28/IMG_4926.JPG (checksum...)
+    git-annex: Photo Library/2010/06/28/IMG_4926.JPG: getFileStatus: does not exist (No such file or directory)
+    failed
+    git-annex: add: 1 failed
+
+None of the other files in the same directory are a problem. The file content is not a problem either as I can move the file elsewhere and git annex add it w/o any problem. It's this file in this directory that causes the problem.
+
+Something interesting though. If I move the file elsewhere, and git annex add it, there is no problem. Now, if I git mv the file back into its original location, and git annex fix the file, the symbolic link is wrong: instead of pointing to `../../../../.git/annex/objects/somefile` it points to  `../../../annex/objects/somefile` (notice the missing `../.git/` part of the path).
+
+I can fix that by hand, and it works well, but that's very annoying. There are not much files having that bug though.
+
+[Mildred](http://mildred.fr)
diff --git a/doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__/comment_1_990197bf01351dc1ccbe1940d5084adb._comment b/doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__/comment_1_990197bf01351dc1ccbe1940d5084adb._comment
new file mode 100644
index 0000000000..7164de760d
--- /dev/null
+++ b/doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__/comment_1_990197bf01351dc1ccbe1940d5084adb._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://mildred.pip.verisignlabs.com/"
+ subject="Manually fixing links doesn't even work"
+ date="2012-04-12T15:46:54Z"
+ content="""
+I'm just answering myself: manually fixing symlinks doesn't always works. Sometimes the pre-commit hook will just rewrite the link to some wrong path.
+"""]]
diff --git a/doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__/comment_2_3bb1d21b7f0d0bd6d59190ae9d246d46._comment b/doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__/comment_2_3bb1d21b7f0d0bd6d59190ae9d246d46._comment
new file mode 100644
index 0000000000..2fa6cc01a6
--- /dev/null
+++ b/doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__/comment_2_3bb1d21b7f0d0bd6d59190ae9d246d46._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2012-04-12T16:29:58Z"
+ content="""
+This bug was fixed in git-annex 3.20120230. You have a few options to get the fix:
+
+* Upgrade to ghc 7.4, the need for which is the cause of the cabal error message you pasted.
+* Manually [[download]] from git, and `git checkout ghc7.0` -- that branch will build with your old ghc and has the fix.
+* cherry-pick commit 51338486dcf9ab86de426e41b1eb31af1d3a6c87
+"""]]
diff --git a/doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__/comment_3_692f268218690437138ae0540c879425._comment b/doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__/comment_3_692f268218690437138ae0540c879425._comment
new file mode 100644
index 0000000000..d5c84b431f
--- /dev/null
+++ b/doc/forum/fail_to_git_annex_add_some_files__58___getFileStatus__58___does_not_exist__40__v_3.20111231__41__/comment_3_692f268218690437138ae0540c879425._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://mildred.pip.verisignlabs.com/"
+ subject="Thank you a lot"
+ date="2012-04-13T07:28:10Z"
+ content="""
+Thank you,
+
+I imagined it was something like that.
+I 'm just sorry I posted that on the forum and not on the bugs section (I hadn't discovered it at that time). but now, if people search for this error, they should find this.
+
+Note for Fedora users: unfortunately GHC 7.4 will not be shipped with Fedora 17 (which is still not released). The [feature page](https://fedoraproject.org/wiki/Features/GHC74) mention it for Fedora 18. I feel like I am using debian ... outdated packages the day of the release.
+
+And many thanks for this wonderful piece of software.
+
+Mildred
+"""]]
diff --git a/doc/forum/failed_to_push_anonymously.mdwn b/doc/forum/failed_to_push_anonymously.mdwn
new file mode 100644
index 0000000000..196f6f71ca
--- /dev/null
+++ b/doc/forum/failed_to_push_anonymously.mdwn
@@ -0,0 +1,19 @@
+I have pushed changes to this wiki in the past using this URL as specified in the `Branchable` tab:
+
+    git://git-annex.branchable.com/
+
+Yet after writing the [[tips/hashdeep integration]] page, I wasn't able to push it to this git repo, and got the following error:
+
+    [1023]anarcat@curie:git-annex$ git push 
+    Décompte des objets: 5, fait.
+    Delta compression using up to 4 threads.
+    Compression des objets: 100% (5/5), fait.
+    Écriture des objets: 100% (5/5), 3.30 KiB | 3.30 MiB/s, fait.
+    Total 5 (delta 3), reused 0 (delta 0)
+    remote: fatal: Not a git repository (or any of the parent directories): .git
+    remote: 'git log --pretty=raw --raw --abbrev=40 --always -c -r d8de48ddee630f546bd71adff6024f875f6db4c2..5bce64b25e53849a6cd7f5973fed849898428efa --no-renames -- .' failed: 
+    To git://git-annex.branchable.com/
+     ! [remote rejected]     master -> master (pre-receive hook declined)
+    error: impossible de pousser des références vers 'git://git-annex.branchable.com/'
+
+Seems like there's something wrong on that end, or did I do something wrong? -- [[anarcat]]
diff --git a/doc/forum/failed_to_push_anonymously/comment_1_bdf93b0e9fb109b7a4052a99110f6079._comment b/doc/forum/failed_to_push_anonymously/comment_1_bdf93b0e9fb109b7a4052a99110f6079._comment
new file mode 100644
index 0000000000..5d8692632b
--- /dev/null
+++ b/doc/forum/failed_to_push_anonymously/comment_1_bdf93b0e9fb109b7a4052a99110f6079._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-07-02T16:45:07Z"
+ content="""
+<http://ikiwiki.info/bugs/git_test_receive_wrapper_fails/>
+"""]]
diff --git a/doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks.mdwn b/doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks.mdwn
new file mode 100644
index 0000000000..3ee7fae84d
--- /dev/null
+++ b/doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks.mdwn
@@ -0,0 +1,27 @@
+Dear all,
+        I had (snif!) and indirect repo with 2.7 of pdf files with filenames were manually added by me with author and title, and took years of work. I had them in a git annex repo from quite some time.  
+Now I'm trying to sync them to an usb drive. Main repo lives in an ubuntu box with ext4 filesystem. I failed many times to do this, both on fat and exfat external drives (direct).  
+As I was failing, I tried to to a test on the same local filesystem. So I have my main repo in /home/juan/papers and the other in /tmp/papers.  
+While trying to sync them using the assistant, i noticed that most of the folders and symlinks from the main repo just dissapeared. 
+I still have them in .git/annex/objects but I don't know how to recover the links. 
+I must say I'm an everyday git user, and big fan of git-annex but I'm trying to use it for six months without luck. I think I will quit after recovering the data, if possible.
+
+EDIT 1
+-------
+After digging around a bit, I found that I had the keys, and could find out the original filename, for example:
+
+    git log --stat -S 1279
+    commit a6362df13d728037875320a457182acb073d08ea
+    Author: Juan Cardelino <x@gmail.com>
+    Date:   Fri Nov 21 11:25:31 2014 -0200
+
+     2013_august/feature_matching_by_searching_maximum_clique_on_high_order_association.pdf | 1 +
+     LevelSets/fedkiw/stanford2002-06.pdf                                                   | 1 +
+     new/nfa/00106994.pdf                                                                   | 1 +
+     3 files changed, 3 insertions(+)
+
+How can I recover them?
+
+EDIT 2
+-------
+Seems that I overwritten my repo with a new repo. Because git log only shows 4 entries from today. Is it possible that the webapp has made that?
diff --git a/doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks/comment_1_3167052f67706797b00423a50f2ae7f1._comment b/doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks/comment_1_3167052f67706797b00423a50f2ae7f1._comment
new file mode 100644
index 0000000000..dd07c1924c
--- /dev/null
+++ b/doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks/comment_1_3167052f67706797b00423a50f2ae7f1._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-12-01T21:56:45Z"
+ content="""
+Well, git-annex just uses a regular git repo. It should not be possible to
+fully lose data. I suggest you run `git log
+--stat` and see if a commit deleted all your files. If so, you can revert
+that commit.
+
+If the git log really is only 4 commits deep, perhaps you got some other
+branch checked out somehow. Run `git reflog` to see the history of what
+branches have been checked out before, and you can use `git checkout` to go
+back to one of those past checkouts.
+
+Or, failing all that, you showed a commit
+a6362df13d728037875320a457182acb073d08ea which had one of your files,
+so `git checkout a6362df13d728037875320a457182acb073d08ea` will check out
+the tree as it appeared at the time of that commit.
+
+This is all git 101. AFAICS, you have not lost any data, and need to become
+more familiar with the basics of git.
+"""]]
diff --git a/doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks/comment_2_0082ac7a148db69293a4e37fa6d6c891._comment b/doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks/comment_2_0082ac7a148db69293a4e37fa6d6c891._comment
new file mode 100644
index 0000000000..06832ca8bd
--- /dev/null
+++ b/doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks/comment_2_0082ac7a148db69293a4e37fa6d6c891._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2014-12-02T17:34:41Z"
+ content="""
+I'm glad you were able to solve it!
+
+Now that you know what the bad commit is, can you tell me what it looks
+like? The assistant should not be committing deletions of all files, 
+unless all files actually were deleted...
+"""]]
diff --git a/doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks/comment_2_6411aa3e6f5c1515845f3223bbcdabf1._comment b/doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks/comment_2_6411aa3e6f5c1515845f3223bbcdabf1._comment
new file mode 100644
index 0000000000..6e9c75aaf7
--- /dev/null
+++ b/doc/forum/failing_to_add_an_usb_drive_made_me_lose_all_symlinks/comment_2_6411aa3e6f5c1515845f3223bbcdabf1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmTNrhkVQ26GBLaLD5-zNuEiR8syTj4mI8"
+ nickname="Juan"
+ subject="I figured it out"
+ date="2014-12-02T01:48:38Z"
+ content="""
+I'm not new to git, and I perfectly know how to revert commits, however, I was confused about how git annex and git play together. In particular I tried to use it as a black box with the assistant and that was a bad idea.
+After adding the usb drive as remote with the assitant, all symlinks got deleted. However, doing a checkout to the commit that messed up everything I got thing back to normal.
+Sadly, your message arrived a couple of hours late, I could have saved me a lot of time.
+Thanks for taking the time to answer.
+Sorry for the previous rant.
+Best regards,
+                      Juan
+"""]]
diff --git a/doc/forum/faking_location_information.mdwn b/doc/forum/faking_location_information.mdwn
new file mode 100644
index 0000000000..7c84e12e39
--- /dev/null
+++ b/doc/forum/faking_location_information.mdwn
@@ -0,0 +1,19 @@
+Hi
+
+I am using git-annex even if people I exchange data with (currently) don‘t use it for there data. My idea behind this is that I would like to know from where I got a file, whom I gave a file and who does (probably) still have a copy of the file. To do this you need to trick git-annex location tracking feature a bit. I successfully managed to achieve this in a simple data exchange which only consisted of me coping over files to one of my git-annex repos. I did the following to make git-annex believe that the files are in two repos without the need to *copy* them around the repos.
+
+This is what I did in this simple case:
+
+1. mounted the drive from someone
+2. made a clone of my git-annex repo on the filesystem which should hold the copy of the data
+3. initialized the cloned repo with `git annex init "Drive from person X"`
+4. imported the files to the cloned repo with `git annex import --duplicate $path_to_files_from_person_x`
+5. `git annex sync` in the cloned repo
+6. `git annex sync` in main repo
+7. `git annex move . --to origin` in the cloned repo
+
+The impotent part (and the limit) here was that you can not sync these two repos after you moved files to the main repo. The problem is that there will be situations where I will have to sync them also after moving files around (for example if I want to store new files in multiple repos (and not just one main repo), or if I also want to copy files over to drives from someone).
+
+Note: I have also worked out a solution to allow someone to choose which files he/she would like to get as described [on superuser.com](http://superuser.com/a/717689).
+
+Are there better ways to fake location information then the thing I came up with (except making multiple repos for one person/drive)? Can multiple remotes be merged to one remote?
diff --git a/doc/forum/fatal_-_corrupt_loose_object.mdwn b/doc/forum/fatal_-_corrupt_loose_object.mdwn
new file mode 100644
index 0000000000..608ed22ba9
--- /dev/null
+++ b/doc/forum/fatal_-_corrupt_loose_object.mdwn
@@ -0,0 +1,14 @@
+After an unobserved problem a few days ago, one of my git annex repositories has become corrupt
+
+    [frederik@maui Documents]$ git status
+    error: object file .git/objects/e2/98e448aa2473a52c0abaef99aed1bf1a5fe94e is empty
+    error: object file .git/objects/e2/98e448aa2473a52c0abaef99aed1bf1a5fe94e is empty
+    error: object file .git/objects/e2/98e448aa2473a52c0abaef99aed1bf1a5fe94e is empty
+    fatal: loose object e298e448aa2473a52c0abaef99aed1bf1a5fe94e (stored in .git/objects/e2/98e448aa2473a52c0abaef99aed1bf1a5fe94e) is corrupt
+
+Most advice I can find relating to this error centers around re-cloning the repository - as does [this wiki's disaster recovery page](https://git-annex.branchable.com/design/assistant/disaster_recovery/)
+
+I have 2 remotes that should have most if not all of the content of the local one, but they're on the internet and downloading all content will take a while. Are there any steps I can safely take before having to re-clone? I was unable to work out from the above page what the best steps in this particular situation are. `git fsck` also stops with the same fatal error as above.
+
+
+
diff --git a/doc/forum/fatal_-_corrupt_loose_object/comment_1_7b0da4185861fd5ff2a7345410678f82._comment b/doc/forum/fatal_-_corrupt_loose_object/comment_1_7b0da4185861fd5ff2a7345410678f82._comment
new file mode 100644
index 0000000000..c1cd00f0ab
--- /dev/null
+++ b/doc/forum/fatal_-_corrupt_loose_object/comment_1_7b0da4185861fd5ff2a7345410678f82._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="HOWTO"
+ date="2019-08-08T20:21:10Z"
+ content="""
+Hi,
+I think this is what you are looking for: 
+http://git-annex.branchable.com/tips/what_to_do_when_a_repository_is_corrupted/
+"""]]
diff --git a/doc/forum/fatal__58___Not_a_valid_object_name_repository.mdwn b/doc/forum/fatal__58___Not_a_valid_object_name_repository.mdwn
new file mode 100644
index 0000000000..d4492a4454
--- /dev/null
+++ b/doc/forum/fatal__58___Not_a_valid_object_name_repository.mdwn
@@ -0,0 +1,49 @@
+After inadvertently deleting my main repository on my local machine, I had to rebuild. This has worked ok, as far as I can tell at the moment. However, when listing the repository details, I get the listing below.
+
+My problem is that **S5** has three aliases: `S5 [S51]`, which I cannot rename to `S5` for some reason, and two other repos residing in `jg@jg-OptiPlex-9020-AIO:/media/jg/S5/annex`. When I try to query there details, I get the information at the bottom. I am a bit anxious, as I am unsure if I am dealing with prior instances that have been somehow overridden but are still being tracked.
+
+Any help in understanding the situation is appreciated. Ideally, I would like to remove the spurious repository references, provided they are not required.
+
+```sh
+jg@jg-OptiPlex-9020-AIO:~/Desktop/annex/VideoStreamFiles/space race$ git-annex info
+trusted repositories: 0
+semitrusted repositories: 15
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	246524b7-7cc2-4b3e-9559-4aa5992a4b94 -- S5 [S51]
+ 	2d8de5a5-4662-4bbb-bab0-51f39ec07d2e -- L1
+ 	39291601-0cc2-45aa-89f4-85e6d5bead99 -- L6
+ 	40897254-d2e8-4803-b291-a735d23fe03b -- [S2]
+ 	48e8f8c5-cb12-4b1d-9f50-30b39f38b6cb -- L5
+ 	63e417a1-b10c-45c2-8a90-44971b8b69bf -- [S1]
+ 	96d8d103-1bc5-41d8-be3e-804260a9ee8d -- jg@jg-OptiPlex-9020-AIO:/media/jg/S5/annex
+ 	a518d97d-4fb0-4018-95b1-2fc1b02a3081 -- L3
+ 	a7972a52-b3c2-4282-b690-a832dbbad982 -- [S3]
+ 	ae317911-25b1-418c-bcd2-a88d4f8d48f2 -- [S4]
+ 	af3e59fb-d2a8-418d-bde5-48b008f61fbb -- jg@jg-OptiPlex-9020-AIO:/media/jg/S5/annex
+ 	cb2c7d0c-b946-4e74-9362-3f4d56a5db5a -- jg@jg-Latitude-5500:~/annex [jglatitude5500.lan_annex]
+ 	ce573cf5-5007-4d5d-b540-ab73f393c32e -- jg@jg-OptiPlex-9020-AIO:~/Desktop/annex [here]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 14.23 megabytes (+100 megabytes reserved)
+local annex keys: 292
+local annex size: 120.26 gigabytes
+annexed files in working tree: 45158
+size of annexed files in working tree: 1 terabyte
+bloom filter size: 32 mebibytes (0.1% full)
+backend usage: 
+	SHA256E: 45158
+```
+
+
+```sh
+jg@jg-OptiPlex-9020-AIO:~/Desktop/annex/VideoStreamFiles/space race$ git-annex info  repository 96d8d103-1bc5-41d8-be3e-804260a9ee8d
+fatal: Not a valid object name repository
+info repository (not a directory or an annexed file or a treeish or a remote or a uuid) failed
+uuid: 96d8d103-1bc5-41d8-be3e-804260a9ee8d
+description: jg@jg-OptiPlex-9020-AIO:/media/jg/S5/annex
+trust: semitrusted
+remote annex keys: 0
+remote annex size: 0 bytes
+info: 1 failed
+```
diff --git a/doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_1_48f1ee21d24a99723ff455c0c9c96629._comment b/doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_1_48f1ee21d24a99723ff455c0c9c96629._comment
new file mode 100644
index 0000000000..78b6185b44
--- /dev/null
+++ b/doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_1_48f1ee21d24a99723ff455c0c9c96629._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="jgsuess@732b8c62c50d8595d7b1d58eea11e5019c2308b1"
+ nickname="jgsuess"
+ avatar="http://cdn.libravatar.org/avatar/35a99d1b5df046b206807941ce9795d3"
+ subject="wrong parameter used - `repository` is not a subcommand"
+ date="2023-12-31T09:41:13Z"
+ content="""
+If I call with UUID, I receive this. However, this still does not help me understand what the item is:
+
+```sh
+jg@jg-OptiPlex-9020-AIO:~/Desktop/annex/VideoStreamFiles/space race$ git-annex info af3e59fb-d2a8-418d-bde5-48b008f61fbb
+uuid: af3e59fb-d2a8-418d-bde5-48b008f61fbb
+description: jg@jg-OptiPlex-9020-AIO:/media/jg/S5/annex
+trust: semitrusted
+remote annex keys: 1
+remote annex size: 373.36 megabytes
+jg@jg-OptiPlex-9020-AIO:~/Desktop/annex/VideoStreamFiles/space race$ git-annex info 96d8d103-1bc5-41d8-be3e-804260a9ee8d
+uuid: 96d8d103-1bc5-41d8-be3e-804260a9ee8d
+description: jg@jg-OptiPlex-9020-AIO:/media/jg/S5/annex
+trust: semitrusted
+remote annex keys: 0
+remote annex size: 0 bytes
+```
+
+
+"""]]
diff --git a/doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_2_eef07cc389400c38b666da4e1adc255e._comment b/doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_2_eef07cc389400c38b666da4e1adc255e._comment
new file mode 100644
index 0000000000..9394321ce6
--- /dev/null
+++ b/doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_2_eef07cc389400c38b666da4e1adc255e._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="jgsuess@732b8c62c50d8595d7b1d58eea11e5019c2308b1"
+ nickname="jgsuess"
+ avatar="http://cdn.libravatar.org/avatar/35a99d1b5df046b206807941ce9795d3"
+ subject="Scanning for files in ghost repos"
+ date="2023-12-31T09:46:53Z"
+ content="""
+So I used the incantations below to scan for contents. Seems that one only holds a single file and the other does not hold anything at all. Is it the safe to declare them `dead` and will that lead to the replication of the file from `S1` to somewhere else?
+
+```sh
+jg@jg-OptiPlex-9020-AIO:~/Desktop/annex/VideoStreamFiles/space race$ git-annex whereis --all --in=af3e59fb-d2a8-418d-bde5-48b008f61fbb
+whereis SHA256E-s373363860--f10c801755cabc38d958adace3af29d767670c780b97c572d04a8dcd10ca0a9a.avi (2 copies) 
+  	63e417a1-b10c-45c2-8a90-44971b8b69bf -- [S1]
+   	af3e59fb-d2a8-418d-bde5-48b008f61fbb -- jg@jg-OptiPlex-9020-AIO:/media/jg/S5/annex
+ok
+jg@jg-OptiPlex-9020-AIO:~/Desktop/annex/VideoStreamFiles/space race$ git-annex whereis --all --in=96d8d103-1bc5-41d8-be3e-804260a9ee8d
+jg@jg-OptiPlex-9020-AIO:~/Desktop/annex/VideoStreamFiles/space race$ 
+
+```
+"""]]
diff --git a/doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_3_2760c9b8b755e1ed5e01b98ea3b99177._comment b/doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_3_2760c9b8b755e1ed5e01b98ea3b99177._comment
new file mode 100644
index 0000000000..b06d0cd1e1
--- /dev/null
+++ b/doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_3_2760c9b8b755e1ed5e01b98ea3b99177._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2023-12-31T14:41:18Z"
+ content="""
+Are these special remotes? You can get more info with `git cat-file blob git-annex:remote.log`. Warning, this will print encryption keys if you set up a encrypted special remote.
+
+Any yes, `git annex dead` should do the trick, it will not count files in the dead repo as a copy anymore.
+"""]]
diff --git a/doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_4_344561606daab9bc1a05ec3b857b2d62._comment b/doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_4_344561606daab9bc1a05ec3b857b2d62._comment
new file mode 100644
index 0000000000..815fd871e7
--- /dev/null
+++ b/doc/forum/fatal__58___Not_a_valid_object_name_repository/comment_4_344561606daab9bc1a05ec3b857b2d62._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jgsuess@732b8c62c50d8595d7b1d58eea11e5019c2308b1"
+ nickname="jgsuess"
+ avatar="http://cdn.libravatar.org/avatar/35a99d1b5df046b206807941ce9795d3"
+ subject="Not a special remote"
+ date="2024-01-10T08:54:57Z"
+ content="""
+No these are just disk drives. I feel that the structure is corrupted. I will have a look to see if that detail listing gives me more.
+"""]]
diff --git a/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory.mdwn b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory.mdwn
new file mode 100644
index 0000000000..ee0b49eb64
--- /dev/null
+++ b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory.mdwn
@@ -0,0 +1,112 @@
+I'm getting this error, not exactly sure why... Here's the output of running git annex sync in my pictures folder:
+
+	[2014-06-29 12:43:59 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","show-ref","git-annex"]
+	[2014-06-29 12:43:59 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","show-ref","--hash","refs/heads/git-annex"]
+	[2014-06-29 12:43:59 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/git-annex..7bf55ad4463cad9389cbb11e48334d151aacf45f","--oneline","-n1"]
+	[2014-06-29 12:43:59 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/git-annex..f3331818fc79b6e9523e483b9d97aaec5c8da845","--oneline","-n1"]
+	[2014-06-29 12:43:59 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/git-annex..6c3bee76aa98f5c789ddf89450b3bd52658171a6","--oneline","-n1"]
+	[2014-06-29 12:43:59 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/git-annex..9329bf7ae5609b19e81d9605fdc990c87c5816dc","--oneline","-n1"]
+	[2014-06-29 12:43:59 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/git-annex..ad7115c6108170dc54095f74632db339dbca4cdd","--oneline","-n1"]
+	[2014-06-29 12:43:59 Mitteleuropäische Sommerzeit] chat: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","cat-file","--batch"]
+	[2014-06-29 12:43:59 Mitteleuropäische Sommerzeit] read: git ["config","--null","--list"]
+	commit 
+	[2014-06-29 12:43:59 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","ls-files","--stage","-z","--others","--exclude-standard","--","C:\\Users\\Name\\Pictures"]
+	[2014-06-29 12:43:59 Mitteleuropäische Sommerzeit] chat: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","cat-file","--batch"]
+	(Recording state in git...)
+	[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","Hochzeit von NameB und NameC/2013-08-18_MVI_0583.MOV"]
+	fatal: Out of memory? mmap failed: No such file or directory
+	[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","Hochzeit von NameB und NameC/2013-08-18_MVI_0582.MOV"]
+	fatal: Out of memory? mmap failed: No such file or directory
+	[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","Hochzeit von NameB und NameC/2013-08-18_MVI_0417.MOV"]
+	fatal: Out of memory? mmap failed: No such file or directory
+	[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","Hochzeit von NameB und NameC/2013-08-17_MVI_9701.MOV"]
+	fatal: Out of memory? mmap failed: No such file or directory
+	[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2014/Hochzeit von Jana und Stefan/MVI_7168.MOV"]
+	[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2456.JPG"]
+	[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2452.JPG"]
+	[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2450.JPG"]
+	[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2449.JPG"]
+	[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2448.JPG"]
+	[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2447.JPG"]
+	[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2443.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2439.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2436.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2431.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2430.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2425.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2424.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2423.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2421.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2418.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2417.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2416.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2415.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2411.JPG"]
+	[2014-06-29 12:49:58 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2409.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2406.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2405.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2404.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2403.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2402.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2400.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2394.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2392.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2012/Event/IMG_2390.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0446.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0445.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0444.JPG"]
+	[2014-06-29 12:49:59 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0443.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0442.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0441.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0440.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0438.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0437.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0436.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0435.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0434.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0433.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0432.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0431.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0368.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0367.JPG"]
+	[2014-06-29 12:50:00 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0366.JPG"]
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0365.JPG"]
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","add","-f","2005/Amsterdam/CIMG0364.JPG"]
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","show-ref","--head"]
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","diff-index","-z","--raw","--no-renames","-l0","--cached","HEAD"]
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","symbolic-ref","HEAD"]
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","show-ref","--hash","refs/heads/annex/direct/master"]
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","write-tree"]
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","rev-parse","ec008c688692d3156b1aececf33a388f43e8c868:"]
+	ok
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","symbolic-ref","HEAD"]
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","show-ref","refs/heads/annex/direct/master"]
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","show-ref","--verify","-q","refs/heads/synced/master"]
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/annex/direct/master..refs/heads/synced/master","--oneline","-n1"]
+	pull HomeServerLocal
+	[2014-06-29 12:50:01 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","fetch","HomeServerLocal"]
+	[2014-06-29 12:50:02 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","show-ref","--verify","-q","refs/remotes/HomeServerLocal/annex/direct/master"]
+	[2014-06-29 12:50:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/annex/direct/master..refs/remotes/HomeServerLocal/annex/direct/master","--oneline","-n1"]
+	[2014-06-29 12:50:02 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","show-ref","--verify","-q","refs/remotes/HomeServerLocal/synced/master"]
+	[2014-06-29 12:50:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/synced/master..refs/remotes/HomeServerLocal/synced/master","--oneline","-n1"]
+	ok
+	[2014-06-29 12:50:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","show-ref","git-annex"]
+	[2014-06-29 12:50:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","show-ref","--hash","refs/heads/git-annex"]
+	[2014-06-29 12:50:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/git-annex..7bf55ad4463cad9389cbb11e48334d151aacf45f","--oneline","-n1"]
+	[2014-06-29 12:50:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/git-annex..f3331818fc79b6e9523e483b9d97aaec5c8da845","--oneline","-n1"]
+	[2014-06-29 12:50:02 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/git-annex..6c3bee76aa98f5c789ddf89450b3bd52658171a6","--oneline","-n1"]
+	[2014-06-29 12:50:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/git-annex..9329bf7ae5609b19e81d9605fdc990c87c5816dc","--oneline","-n1"]
+	[2014-06-29 12:50:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/heads/git-annex..ad7115c6108170dc54095f74632db339dbca4cdd","--oneline","-n1"]
+	[2014-06-29 12:50:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","branch","-f","synced/master"]
+	[2014-06-29 12:50:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","branch","-f","master"]
+	[2014-06-29 12:50:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","show-ref","--verify","-q","refs/remotes/HomeServerLocal/synced/master"]
+	[2014-06-29 12:50:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/remotes/HomeServerLocal/synced/master..refs/heads/synced/master","--oneline","-n1"]
+	[2014-06-29 12:50:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","show-ref","--verify","-q","refs/remotes/HomeServerLocal/git-annex"]
+	[2014-06-29 12:50:03 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","log","refs/remotes/HomeServerLocal/git-annex..git-annex","--oneline","-n1"]
+	push HomeServerLocal
+	[2014-06-29 12:50:03 Mitteleuropäische Sommerzeit] call: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","push","HomeServerLocal","+git-annex:synced/git-annex","annex/direct/master:synced/master"]
+	Everything up-to-date
+	[2014-06-29 12:50:04 Mitteleuropäische Sommerzeit] read: git ["--git-dir=C:\\Users\\Name\\Pictures\\.git","--work-tree=C:\\Users\\Name\\Pictures","push","HomeServerLocal","master"]
+	ok
+
+Any idea? Thanks in advance...
diff --git a/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_1_d98a155fa01d10ecff9058d79290156d._comment b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_1_d98a155fa01d10ecff9058d79290156d._comment
new file mode 100644
index 0000000000..989ab1a6a4
--- /dev/null
+++ b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_1_d98a155fa01d10ecff9058d79290156d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Idhup"
+ ip="91.58.248.157"
+ subject="System"
+ date="2014-06-29T19:26:42Z"
+ content="""
+Forgot to tell: This is a Win7 x64 system, running git 1.9.2.msysgit.0 and
+
+git-annex version: 5.20140517-gee56d21
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+"""]]
diff --git a/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_2_3b9ea7a1254ac5b50a5ab59cd331ec3f._comment b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_2_3b9ea7a1254ac5b50a5ab59cd331ec3f._comment
new file mode 100644
index 0000000000..2a575e0599
--- /dev/null
+++ b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_2_3b9ea7a1254ac5b50a5ab59cd331ec3f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 2"
+ date="2014-07-04T17:55:45Z"
+ content="""
+<http://git-annex.branchable.com/bugs/git_annex_add_out_of_memory__63___mmap_failed:_No_such_file_or_directory/>
+"""]]
diff --git a/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_3_5ee300034819c5825c676cd7e3af659f._comment b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_3_5ee300034819c5825c676cd7e3af659f._comment
new file mode 100644
index 0000000000..55345537e8
--- /dev/null
+++ b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_3_5ee300034819c5825c676cd7e3af659f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Idhup"
+ ip="91.58.248.157"
+ subject="Didn't work"
+ date="2014-07-06T17:46:01Z"
+ content="""
+Repacking in cygwin towards a smaller packsize did not help. I shrinked it down to 2 MB per packfile, I still got the errors.
+
+When checking the debug output, you can see that git crashes when adding some large-ish .mov files. I'm not even sure if git's supposed to add them or if something went wrong with Windows/DirectMode. I executed git reset to remove pending additions that weren't supposed to be there, but to no avail.
+
+Any ideas on how to fix that?
+"""]]
diff --git a/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment
new file mode 100644
index 0000000000..d0b89c59e5
--- /dev/null
+++ b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 4"
+ date="2014-07-10T20:16:28Z"
+ content="""
+[2014-06-29 12:49:57 Mitteleuropäische Sommerzeit] call: git [\"--git-dir=C:\\Users\\Name\\Pictures\\.git\",\"--work-tree=C:\\Users\\Name\\Pictures\",\"add\",\"-f\",\"Hochzeit von NameB und NameC/2013-08-17_MVI_9701.MOV\"]
+
+When does git-annex in direct mode run \"git add -f\"? In stageDirect, when a file has been modified that is not an annexed file, but already has been committed  directly to git.
+
+This certainly points in the direction of what the problem is with the repository. I think you need to take a look at `git log --stat \"Hochzeit von NameB und NameC/2013-08-18_MVI_0583.MOV\"` and see if it has been committed to git as a symlink or if it is indeed being stored as a Bin file in git. 
+
+Here's how the log would look for a regular git-annexed symlink:
+
+<pre>
+ $somefile | 1 +
+ 1 file changed, 1 insertion(+)
+</pre>
+
+And here for a binary file stored in git:
+
+<pre>
+ $somefile | Bin 0 -> 1016920 bytes
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+</pre>
+
+If you find the latter in the log, then the author and commit message of the commit adding it would be interesting.
+
+Hypothesis: Perhaps this repository started off on a Linux or OSX system, and you were using a git-annex older than 5.20131118, when the direct mode guard was added. You might have added this file back then and accidentally committed it directly to git.
+"""]]
diff --git a/doc/forum/fatal__58___export-tree_object_is_unavailable.mdwn b/doc/forum/fatal__58___export-tree_object_is_unavailable.mdwn
new file mode 100644
index 0000000000..cacfb23dcf
--- /dev/null
+++ b/doc/forum/fatal__58___export-tree_object_is_unavailable.mdwn
@@ -0,0 +1,15 @@
+Hello !
+
+I'm having a little issue with one of my annexes. Not sure how I got to this point, I might have reset the master branch in one of the repositories to undo changes at some point.
+
+```
+❯ git annex sync
+(merging origin/synced/git-annex into git-annex...)
+(recording state in git...)
+fatal: entry 'export.tree' object 92ab3e13460c6c7a6e9f19484d1808f22eab0077 is unavailable
+git-annex: fd:17: hClose: resource vanished (Broken pipe)
+```
+
+There is indeed an entry in git-annex:export.log with that checksum. I don't really care about the export, since its to a remote I don't use anymore. But I'm not sure how to make my annex usable again. Marking the remote as dead does not help. I've considered editing all the git-annex:export.log in all the repositories to remove the offending line, but that's quite some work and I'm not sure if that's enough or if I might do more damage.
+
+Any ideas ?
diff --git a/doc/forum/fatal__58___export-tree_object_is_unavailable/comment_1_e101855120be3639fce9f3725737b189._comment b/doc/forum/fatal__58___export-tree_object_is_unavailable/comment_1_e101855120be3639fce9f3725737b189._comment
new file mode 100644
index 0000000000..1d72ee2f57
--- /dev/null
+++ b/doc/forum/fatal__58___export-tree_object_is_unavailable/comment_1_e101855120be3639fce9f3725737b189._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="arnaud@c1d1cc612a3921dc06a417301be08a3e125478c4"
+ nickname="arnaud"
+ avatar="http://cdn.libravatar.org/avatar/c0defbf54541c499f6c0464588fc2ad0"
+ subject="comment 1"
+ date="2022-07-25T07:52:39Z"
+ content="""
+So I managed to find a copy of the missing tree in a packfile somewhere and saved my repo. I still wish I knew of an alternative solution. 
+"""]]
diff --git a/doc/forum/files_being_dropped_undesirably.mdwn b/doc/forum/files_being_dropped_undesirably.mdwn
new file mode 100644
index 0000000000..2a4d1bf7c9
--- /dev/null
+++ b/doc/forum/files_being_dropped_undesirably.mdwn
@@ -0,0 +1,47 @@
+I currently am using 3 repositories for my personal annex, and on each of them I'm running the assistant (they are normal git annex repositories). However all my files are migrating to my work desktop. My other two repositories seem to keep dropping them.
+
+Last night on my laptop I did a "git annex get *" to pull _all_ the files onto it. I saw in the .git/annex/daemon.log that each file was being dropped as soon as it was gotten. The output of "git annex get" showed files being transfered across, and the .git/annex/daemon.log showed files being dropped straight away. Currently I'd like to keep all my files on all my repositories (and perhaps later I'll revise that).
+
+Could someone please help me understand why annex is dropping my files, and what I could do to keep them on all my repositories?
+
+Here is the output of a get for a single file:
+
+    ~/Documents/personal-annex $ git annex get 2014/09/15/IMG_1123.JPG
+    get 2014/09/15/IMG_1123.JPG (from pea15.local_Documents_annexpersonal...)
+    SHA256E-s1841221--deeaa13935907ad606f941397bb57432c1eccfd5c361b8c16d2b19bfbe8437a6.JPG
+          1,841,221 100%   11.40MB/s    0:00:00 (xfr#1, to-chk=0/1)
+    ok
+    (Recording state in git...)
+
+
+Here is the corresponding daemon.log output:
+
+    [2014-10-09 09:11:34 AEDT] Committer: Committing changes to git
+    [2ok
+    (Recording state in git...)
+    (Recording state in git...)
+    (Recording state in git...)
+    drop 2014/09/15/IMG_1123.JPG 01(checking pea15.local_Documents_annexpersonal...) 4-10-09 09:11:34 AEDT] Pusher: Syncing with pea15.local_Documents_annexpersonal 
+    [2014-10-09 09:11:35 AEDT] Committer: Committing changes to git
+    To ssh://geoffc@git-annex-pea-15-geoffc_Documents.2Fannex.2Dpersonal/~/Documents/annex-personal/
+       04742c0..d1a5a36  git-annex -> synced/git-annex
+    [2014-10-09 09:11:38 AEDT] Pusher: Syncing with pea15.local_Documents_annexpersonal 
+    Everything up-to-date
+
+
+And here is a snippet from my .git/config:
+
+    [annex]
+            uuid = 57c4e6d1-0c6b-4c49-a235-4119d3864c14
+            version = 5
+            direct = true
+            #diskreserve = 2 gigabyte
+            autoupgrade = ask
+            debug = false
+            expireunused = false
+            autocommit = true
+    [remote "pea15.local_Documents_annexpersonal"]
+            url = ssh://geoffc@git-annex-pea-15-geoffc_Documents.2Fannex.2Dpersonal/~/Documents/annex-personal/
+            fetch = +refs/heads/*:refs/remotes/pea15.local_Documents_annexpersonal/*
+            annex-uuid = 2ef6bbfe-662f-48ba-aa52-8e2f82bcfb15
+            annex-cost = 175.0
diff --git a/doc/forum/files_being_dropped_undesirably/comment_1_d03f8ed7d3f3da58612bf238c1790fb4._comment b/doc/forum/files_being_dropped_undesirably/comment_1_d03f8ed7d3f3da58612bf238c1790fb4._comment
new file mode 100644
index 0000000000..887b12ac96
--- /dev/null
+++ b/doc/forum/files_being_dropped_undesirably/comment_1_d03f8ed7d3f3da58612bf238c1790fb4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Bram"
+ ip="81.20.68.186"
+ subject="Group and wanted expression"
+ date="2014-10-09T12:09:58Z"
+ content="""
+What are the group and wanted expressions for your repository?
+
+    git annex group .
+    git annex wanted .
+"""]]
diff --git a/doc/forum/files_being_dropped_undesirably/comment_2_7d885abebfec789348639494b1bb1829._comment b/doc/forum/files_being_dropped_undesirably/comment_2_7d885abebfec789348639494b1bb1829._comment
new file mode 100644
index 0000000000..7bdb9243ce
--- /dev/null
+++ b/doc/forum/files_being_dropped_undesirably/comment_2_7d885abebfec789348639494b1bb1829._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="go8ose"
+ ip="203.26.118.202"
+ subject="Group and wanted expression"
+ date="2014-10-09T22:19:01Z"
+ content="""
+Here is the group and wanted output on my laptop (that is dropping all the files):
+
+    ~/Documents/personal-annex $ git annex group .
+    unwanted
+    ~/Documents/personal-annex $ git annex wanted .
+    standard
+
+Here is the output on my desktop (that seems to be keeping all the files):
+
+    ~/Documents/annex-personal $ git annex group .
+    
+    ~/Documents/annex-personal $ git annex wanted .
+    
+
+
+
+Reading the manpage suggests I might want to change this. However I haven't seen in the man page a list of the standard predefined groups, nor an explanation of how each predefined group behaves. Is that documented somewhere else?
+"""]]
diff --git a/doc/forum/files_being_dropped_undesirably/comment_3_7c70b58f89408304055eefb1b166ef2e._comment b/doc/forum/files_being_dropped_undesirably/comment_3_7c70b58f89408304055eefb1b166ef2e._comment
new file mode 100644
index 0000000000..00d5115962
--- /dev/null
+++ b/doc/forum/files_being_dropped_undesirably/comment_3_7c70b58f89408304055eefb1b166ef2e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="go8ose"
+ ip="203.26.118.202"
+ subject="comment 3"
+ date="2014-10-09T22:31:49Z"
+ content="""
+To answer my question about documentation on the 'groups' and 'wanted' features, I've found [[preferred_content]] and [[preferred_content/standard_groups]].
+
+In my case I've now setup my laptop to use group 'client' for the '.' repository. Similarly I've set 'client' on my desktop. I found my home server was already set to 'backup'. I still don't understand \"git annex\" well enough to know what's going on. I thought with these settings that running \"git annex get --auto\" on my laptop would have fetched all the files, but it didn't. A \"git annex get *\" is fetching all the files though, so I'm achieving what I want.
+"""]]
diff --git a/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__.mdwn b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__.mdwn
new file mode 100644
index 0000000000..5a90d15355
--- /dev/null
+++ b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__.mdwn
@@ -0,0 +1,23 @@
+Basically, this is how it looks now (this is part of my music collection, but there are other directories with the same symptoms):
+
+    simon@simon-desktop /run/media/simon/TOSHIBA EXT/Stuff/Music/Amy Kuney - Breaking Bad Habits EP (2006) ±annex/direct/master » ls -l
+    insgesamt 4
+    -rwxrwxrwx 1 simon simon 196  7. Dez 13:37 01 So Help Me God.mp3
+    -rwxrwxrwx 1 simon simon 196  7. Dez 13:37 02 Sore Loser.mp3
+    -rwxrwxrwx 1 simon simon 196  7. Dez 13:37 03 How The Wind Must Feel.mp3
+    -rwxrwxrwx 1 simon simon 196  7. Dez 13:37 04 Sold Out.mp3
+    -rwxrwxrwx 1 simon simon 196  7. Dez 13:37 05 In The Dark.mp3
+    -rwxrwxrwx 1 simon simon 196  7. Dez 13:37 06 Breaking Bad Habits.mp3
+    -rwxrwxrwx 1 simon simon 196  7. Dez 13:37 AmyKuneyEP.jpg
+    simon@simon-desktop /run/media/simon/TOSHIBA EXT/Stuff/Music/Amy Kuney - Breaking Bad Habits EP (2006) ±annex/direct/master » cat 01\ So\ Help\ Me\ God.mp3 
+    ../../.git/annex/objects/M5/Pq/SHA256E-s213--96db10197b716998d35576c39fc2468bd197b5a4ba2bec14a78454b278d96498.mp3/SHA256E-s213--96db10197b716998d35576c39fc2468bd197b5a4ba2bec14a78454b278d96498.mp3%
+    simon@simon-desktop /run/media/simon/TOSHIBA EXT/Stuff/Music/Amy Kuney - Breaking Bad Habits EP (2006) ±annex/direct/master » ls ../../.git/annex/objects/M5
+    ls: Zugriff auf ../../.git/annex/objects/M5 nicht möglich: Datei oder Verzeichnis nicht gefunden
+    simon@simon-desktop /run/media/simon/TOSHIBA EXT/Stuff/Music/Amy Kuney - Breaking Bad Habits EP (2006) ±annex/direct/master » find ../../.git/annex | grep 96db10197b716998d3557                               2 ↵
+    ../../.git/annex/objects/a5b/e78/SHA256E-s213--96db10197b716998d35576c39fc2468bd197b5a4ba2bec14a78454b278d96498.mp3
+    ../../.git/annex/objects/a5b/e78/SHA256E-s213--96db10197b716998d35576c39fc2468bd197b5a4ba2bec14a78454b278d96498.mp3/SHA256E-s213--96db10197b716998d35576c39fc2468bd197b5a4ba2bec14a78454b278d96498.mp3.map
+    simon@simon-desktop /run/media/simon/TOSHIBA EXT/Stuff/Music/Amy Kuney - Breaking Bad Habits EP (2006) ±annex/direct/master » git annex info  
+    repository mode: direct
+
+So, I only have a bunch of text files containing file paths. The actual files are in .git/annex/objects somewhere, but not exactly in the path specified in those text files. I'm not sure how it ended up that way, I'm in direct mode after all.
+For starters, I would like to know how I can repair this mess.
diff --git a/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_1_4d07f87b433228fdaebce2805fc64492._comment b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_1_4d07f87b433228fdaebce2805fc64492._comment
new file mode 100644
index 0000000000..d8046026b9
--- /dev/null
+++ b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_1_4d07f87b433228fdaebce2805fc64492._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-15T19:01:22Z"
+ content="""
+git-annex uses broken symlinks for files in the git repository whose
+content is not currently present.
+
+On filesystems not supporting symlinks, git represents them by putting the
+symlink target in a regular file. This seems to be what you have here.
+
+Your `find` command shows that the content is *not* located in
+.git/annex/objects. It only found a .map file, not the content file.
+
+So, `git annex get` seems like the most likely thing that will get the
+content of these files from wherever it's stored.
+"""]]
diff --git a/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_2_97d24db6027270b9f2d759e98d5f428f._comment b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_2_97d24db6027270b9f2d759e98d5f428f._comment
new file mode 100644
index 0000000000..0990352b97
--- /dev/null
+++ b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_2_97d24db6027270b9f2d759e98d5f428f._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="simon.parzer@f837bbade0d93f560dc574b04e835b7875c4026f"
+ nickname="simon.parzer"
+ subject="comment 2"
+ date="2016-01-15T19:37:57Z"
+ content="""
+Well here is where it gets weird. I used \"git annex get\" to retrieve the file and it did something.
+
+    simon@simon-desktop /run/media/simon/TOSHIBA EXT/Stuff/Music/Amy Kuney - Breaking Bad Habits EP (2006) ±annex/direct/master » git annex get 01\ So\ Help\ Me\ God.mp3
+    get 01 So Help Me God.mp3 (from desktop-linux...) 
+    01 So Help Me God.mp3
+                 213 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+    (checksum...) ok
+    (recording state in git...)
+
+    simon@simon-desktop /run/media/simon/TOSHIBA EXT/Stuff/Music/Amy Kuney - Breaking Bad Habits EP (2006) ±annex/direct/master » ls -l
+    insgesamt 4
+    -rwxrwxrwx 1 simon simon 213 15. Jän 20:30 01 So Help Me God.mp3
+    ....
+
+    simon@simon-desktop /run/media/simon/TOSHIBA EXT/Stuff/Music/Amy Kuney - Breaking Bad Habits EP (2006) ±annex/direct/master » cat 01\ So\ Help\ Me\ God.mp3 
+    ..\..\..\..\..\.git\annex\objects\K8\xx\SHA256E-s3460908--ad74d891fd20ef771f933d3fea6247eb640b2d8c0ca4848065735992a07a4eb7.mp3\SHA256E-s3460908--ad74d891fd20ef771f933d3fea6247eb640b2d8c0ca4848065735992a07a4eb7.mp3%                          
+
+Yet the file still is only a fake symlink.
+On the other computer (desktop-linux) where it got the file from it's also only a symlink, but the actual file is somewhere in annex/objects
+
+    simon@simon-desktop /d/Stuff/Music/Amy Kuney - Breaking Bad Habits EP (2006) ±annex/direct/master » git annex whereis 01\ So\ Help\ Me\ God.mp3 
+    whereis 01 So Help Me God.mp3 (1 copy) 
+      	5e0f083c-d81f-4a4b-b1a5-35b45e057dea -- desktop pc [here]
+    ok
+    simon@simon-desktop /d/Stuff/Music/Amy Kuney - Breaking Bad Habits EP (2006) ±annex/direct/master » cat 01\ So\ Help\ Me\ God.mp3 
+    ..\..\..\..\..\.git\annex\objects\K8\xx\SHA256E-s3460908--ad74d891fd20ef771f933d3fea6247eb640b2d8c0ca4848065735992a07a4eb7.mp3\SHA256E-s3460908--ad74d891fd20ef771f933d3fea6247eb640b2d8c0ca4848065735992a07a4eb7.mp3%
+    simon@simon-desktop /d/Stuff/Music/Amy Kuney - Breaking Bad Habits EP (2006) ±annex/direct/master » find /d/Stuff/.git/annex/objects | grep a6247eb640b2d8c0ca48480
+    /d/Stuff/.git/annex/objects/48d/eb4/SHA256E-s3460908--ad74d891fd20ef771f933d3fea6247eb640b2d8c0ca4848065735992a07a4eb7.mp3
+    /d/Stuff/.git/annex/objects/48d/eb4/SHA256E-s3460908--ad74d891fd20ef771f933d3fea6247eb640b2d8c0ca4848065735992a07a4eb7.mp3/SHA256E-s3460908--ad74d891fd20ef771f933d3fea6247eb640b2d8c0ca4848065735992a07a4eb7.mp3.map
+
+
+"""]]
diff --git a/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_3_e61107dd83efecc3266217acad9c943b._comment b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_3_e61107dd83efecc3266217acad9c943b._comment
new file mode 100644
index 0000000000..dfc6b1fbd6
--- /dev/null
+++ b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_3_e61107dd83efecc3266217acad9c943b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-01-20T19:06:00Z"
+ content="""
+Try running `git-annex fsck` on the file; this may fix it up to make the
+content actually available. It might also output something useful to debug
+what went wrong.
+"""]]
diff --git a/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_4_362370f02ea77addf9efaed9cb4b433a._comment b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_4_362370f02ea77addf9efaed9cb4b433a._comment
new file mode 100644
index 0000000000..c344399555
--- /dev/null
+++ b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_4_362370f02ea77addf9efaed9cb4b433a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="simon.parzer@f837bbade0d93f560dc574b04e835b7875c4026f"
+ nickname="simon.parzer"
+ subject="comment 4"
+ date="2016-01-21T12:54:57Z"
+ content="""
+I already tried ```git annex fsck```, but it does not report any errors and the files remain unchanged. Here is the output.
+
+    simon@simon-desktop /d/Stuff/Music/Amy Kuney - Breaking Bad Habits EP (2006) ±annex/direct/master » git annex fsck 01\ So\ Help\ Me\ God.mp3
+    fsck 01 So Help Me God.mp3 (checksum...) ok
+    (recording state in git...)
+
+"""]]
diff --git a/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_5_4333c2f189cea3430104ece6769143bc._comment b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_5_4333c2f189cea3430104ece6769143bc._comment
new file mode 100644
index 0000000000..5c4c91fdfe
--- /dev/null
+++ b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_5_4333c2f189cea3430104ece6769143bc._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-01-29T17:49:47Z"
+ content="""
+Does `git annex info` show this repository as being in direct mode, or
+indirect mode? (It's the first line of its output.)
+
+I'm thinking you might somehow have a repository that is not really in
+direct mode despite the current branch being annex/direct/master.
+"""]]
diff --git a/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_6_8c4c2e8dc4706ca824cbbc9b2ed62be4._comment b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_6_8c4c2e8dc4706ca824cbbc9b2ed62be4._comment
new file mode 100644
index 0000000000..4df27e9999
--- /dev/null
+++ b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_6_8c4c2e8dc4706ca824cbbc9b2ed62be4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="simon.parzer@f837bbade0d93f560dc574b04e835b7875c4026f"
+ nickname="simon.parzer"
+ subject="comment 6"
+ date="2016-05-05T11:26:03Z"
+ content="""
+To sort of follow up on this after 3 months, ```git annex info``` displays ```repository mode: direct```
+
+I have given up on git annex in the meantime, it is a nightmare to sync between different operating systems/file systems.
+What might be \"wrong\" with my setup is that I have at least two machines that are dual-boot. So I'm using the same folder both in Windows and Linux. I also have an external HD with an annex repository that I plug in to different machines, and it apparently causes problems.
+Now I have to write a python script to recover my lost files from the bottomless abyss that is the .git/annex folder.
+"""]]
diff --git a/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_7_24b09f1263f6bc6b219085c17ced915c._comment b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_7_24b09f1263f6bc6b219085c17ced915c._comment
new file mode 100644
index 0000000000..c648d125da
--- /dev/null
+++ b/doc/forum/files_got_replaced_by_broken_symblinks__44___how_to_get_them_back__63__/comment_7_24b09f1263f6bc6b219085c17ced915c._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="simon.parzer@f837bbade0d93f560dc574b04e835b7875c4026f"
+ nickname="simon.parzer"
+ subject="Python script to recover git annex' lost files"
+ date="2016-05-05T12:01:46Z"
+ content="""
+Maybe someone else needs this at some point :|
+
+Use it at your own risk of course.
+
+    #!python3
+    
+    import os
+    import re
+    from shutil import copyfile
+    
+    targets = {}
+    
+    for path, dirs, files in os.walk('.'):
+        for f in files:
+            fp = os.path.join(path, f)
+            if fp.endswith('.py'): continue
+            fp_size = os.stat(fp).st_size
+            if fp_size < 72 or fp_size > 256: continue
+            with open(fp, 'r', encoding='latin1') as stream:
+                l = stream.readline()
+                hashmatch = re.match('.*SHA256E\-\w+\-\-(\w{16})', l)
+                if hashmatch:
+                    targets[hashmatch.group(1)] = os.path.abspath(fp)
+    
+    #print(targets)
+    
+    target = os.path.abspath('.')
+    while not os.path.exists('.git/annex/objects'):
+        os.chdir('..')
+    
+    for path, dirs, files in os.walk('.git/annex/objects'):
+        for f in files:
+            fp = os.path.join(path, f)
+            fp_size = os.stat(fp).st_size
+            if fp_size > 512:
+                hashmatch = re.match('.*SHA256E\-\w+\-\-(\w{16})', fp)
+                if hashmatch:
+                    hash = hashmatch.group(1)
+                    if hash in targets:
+                        print(fp, '->', targets[hash])
+                        copyfile(fp, targets[hash])
+
+"""]]
diff --git a/doc/forum/files_only_visible_in_.git_annex.mdwn b/doc/forum/files_only_visible_in_.git_annex.mdwn
new file mode 100644
index 0000000000..e011ea5831
--- /dev/null
+++ b/doc/forum/files_only_visible_in_.git_annex.mdwn
@@ -0,0 +1,15 @@
+Dear all, 
+
+I'm a beginner in using git annex and got the following strange situation:
+
+On my PC I have stored all the data and put them to git annex (don' know the standard nomenclature used here, but I guess its called setting up a repository)
+
+On my Laptop I have now also git-annex and can have access to my stored data by git-annex get (so far so good thats git-annex)
+
+Now comes the strange thing: 
+On my laptop, I can see all the links to my data (where it shows me a path like ../../.git/annex/objects/...) but at my PC, where all the data should have been stored, the folder is empty. When I follow the link which is shown on the laptop, on my PC, I get access to the data. Some somehow, the data is still on my PC but not stored in its original folders but in .git/annex/objects/...
+
+How can I get back my original folder from the .git/annex/objects on my PC?
+
+Thank you very much for your help
+Stefan
diff --git a/doc/forum/files_only_visible_in_.git_annex/comment_1_a967dc488d4fb0fd6079b0a1b087679f._comment b/doc/forum/files_only_visible_in_.git_annex/comment_1_a967dc488d4fb0fd6079b0a1b087679f._comment
new file mode 100644
index 0000000000..8bdcdb077c
--- /dev/null
+++ b/doc/forum/files_only_visible_in_.git_annex/comment_1_a967dc488d4fb0fd6079b0a1b087679f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="cbaines"
+ subject="comment 1"
+ date="2015-06-17T17:20:26Z"
+ content="""
+Could you post the output of \"git annex info\" on both your laptop and desktop?
+
+Also, what operating system are you using on both device?
+"""]]
diff --git a/doc/forum/files_only_visible_in_.git_annex/comment_2_e024e26b943f49a5e63c8fd1cd90a420._comment b/doc/forum/files_only_visible_in_.git_annex/comment_2_e024e26b943f49a5e63c8fd1cd90a420._comment
new file mode 100644
index 0000000000..d4285eee3e
--- /dev/null
+++ b/doc/forum/files_only_visible_in_.git_annex/comment_2_e024e26b943f49a5e63c8fd1cd90a420._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="graviton31415@3f1790ceea563b1bc76c318c7bfd6d4e817ecc5d"
+ nickname="graviton31415"
+ subject="comment 2"
+ date="2015-06-18T05:08:47Z"
+ content="""
+on my PC (where the data should be): git annex info gives:
+
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 2
+	00000000-0000-0000-0000-000000000001 -- web
+ 	e1664284-234f-4be1-8623-3fec7f406b57 -- here (Documents at myPC)
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 138.66 gigabytes (+1 megabyte reserved)
+local annex keys: 1616
+local annex size: 1.98 gigabytes
+annexed files in working tree: 125
+size of annexed files in working tree: 350.37 megabytes
+bloom filter size: 16 mebibytes (0.3% full)
+backend usage: 
+	SHA256E: 1741
+
+
+
+on my Laptop I get:
+
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 3
+	00000000-0000-0000-0000-000000000001 -- web
+ 	77106ecf-d208-4366-b70c-64def14c62bb -- here
+ 	e1664284-234f-4be1-8623-3fec7f406b57 -- origin (Documents at myPC)
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 207.67 gigabytes (+1 megabyte reserved)
+local annex keys: 7
+local annex size: 181.68 megabytes
+annexed files in working tree: 1567
+size of annexed files in working tree: 1.83 gigabytes
+bloom filter size: 16 mebibytes (0% full)
+backend usage: 
+	SHA256E: 1574
+
+
+On both systems, I'm using Ubuntu 14.04
+
+Thank you for your help,
+Stefan
+"""]]
diff --git a/doc/forum/files_only_visible_in_.git_annex/comment_3_2c3d5991056d5915225b2707ad7d25dd._comment b/doc/forum/files_only_visible_in_.git_annex/comment_3_2c3d5991056d5915225b2707ad7d25dd._comment
new file mode 100644
index 0000000000..ac6d42eebf
--- /dev/null
+++ b/doc/forum/files_only_visible_in_.git_annex/comment_3_2c3d5991056d5915225b2707ad7d25dd._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-06T18:58:17Z"
+ content="""
+Take a look at what git branch is checked out in your repository on the PC.
+It might have, eg, an old version of the "master" branch checked out,
+from before when the files were added.
+
+Checking out the right branch will get you your files visible.
+
+You might need to run `git annex sync` on the PC to pull in changes
+from the laptop.
+"""]]
diff --git a/doc/forum/files_vanishing.mdwn b/doc/forum/files_vanishing.mdwn
new file mode 100644
index 0000000000..f80adb51a2
--- /dev/null
+++ b/doc/forum/files_vanishing.mdwn
@@ -0,0 +1,12 @@
+Can anybody help me locate content that seems to have gone missing? 
+
+Setup is two repos, connected via ssh, both direct mode, both debian machines, repo A with 5.20150731-1 (testing), repo B with 5.20141125 (stable).
+
+Both repos where synchronising (in this case transfering files from A to B), when I was copying a few more hundred files (second set) into a folder in repo A. In the webapp I have seen the assistant pick them up and transfer them to repo B. This took an hour or so, after which I can still see the name of nine files from the second set (and "... and 626 more") in the status messages on the right as added and the same number of files as uploaded.
+
+Unfortunately, from the second set of files only the first two files can be found in A and B, none of the other few hundred.
+
+Running git-annex fsck in repo A did not return any errors.
+
+I would appreciate any pointers,
+Felix
diff --git a/doc/forum/files_vanishing/comment_1_eb69e88aee0005fca74dd540293e57ca._comment b/doc/forum/files_vanishing/comment_1_eb69e88aee0005fca74dd540293e57ca._comment
new file mode 100644
index 0000000000..8282b9e383
--- /dev/null
+++ b/doc/forum/files_vanishing/comment_1_eb69e88aee0005fca74dd540293e57ca._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-14T19:50:52Z"
+ content="""
+Suggest you run git log --stat to see if you can find a commit that deleted
+the missing files. Reverting the commit should then get the files back.
+
+There have been several bugs of this kind in direct mode. Using such an old
+git-annex from 2014 makes it more likely you'll hit an old bug like this.
+
+The new v6 repository mode should be much less likely to have this kind of
+bug.
+"""]]
diff --git a/doc/forum/finding_out_why_git_annex_import_failed.mdwn b/doc/forum/finding_out_why_git_annex_import_failed.mdwn
new file mode 100644
index 0000000000..664cf8542d
--- /dev/null
+++ b/doc/forum/finding_out_why_git_annex_import_failed.mdwn
@@ -0,0 +1,43 @@
+Hi,
+
+I keep importing data to my git annex, which gets bigger.
+
+Today while importing an old archive (with lots of files), git import failed with this unhelpful message:
+
+    $ git annex import /Users/public/Documents
+    import Documents/.DS_Store
+      not importing Documents/.DS_Store which is .gitignored (use --force to override)
+    failed
+    ...
+    import Documents/Recettes/recettes nicoises/20130511_201509.jpg ok
+    (recording state in git...)
+    git-annex: import: 10 failed
+    CallStack (from HasCallStack):
+      error, called at ./CmdLine/Action.hs:41:28 in main:CmdLine.Action
+
+It seems no data was lost: I could finish the import with "git commit" (and diff -R with the backup shows no difference). But I would like to know what did happen.
+And also what does the "10" mean in this context and how to get more information?
+
+Note that I might have a real problem on this system
+
+* many filenames have extend chars
+* I'm not sure the mac OS locale setup is OK
+* I'm quite low on disk space and inodes:
+
+      $ df
+      Filesystem    512-blocks       Used Available Capacity   iused   ifree %iused  Mounted on
+      /dev/disk1    1462744832 1441994016  20238816    99% 180313250 2529852   99%   /
+
+The version is
+
+    $ git annex version
+    git-annex version: 6.20161111
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: darwin x86_64
+
+Thank you!
diff --git a/doc/forum/finding_out_why_git_annex_import_failed/comment_1_276bbd2dab64e4bbc297e0e53e02215d._comment b/doc/forum/finding_out_why_git_annex_import_failed/comment_1_276bbd2dab64e4bbc297e0e53e02215d._comment
new file mode 100644
index 0000000000..b2bc2f403e
--- /dev/null
+++ b/doc/forum/finding_out_why_git_annex_import_failed/comment_1_276bbd2dab64e4bbc297e0e53e02215d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-10-02T16:53:28Z"
+ content="""
+The `.DS_Store` file matched an ignore in your repositories `.gitignore`
+file, and so it was not imported.  Like the message says..
+
+The "10 failed" means that there were 10 things that failed to import. 
+The one you showed and 9 you didn't include in the paste. Probably all for
+similar reasons.
+"""]]
diff --git a/doc/forum/first-time_setup_git-annex.mdwn b/doc/forum/first-time_setup_git-annex.mdwn
new file mode 100644
index 0000000000..735d746212
--- /dev/null
+++ b/doc/forum/first-time_setup_git-annex.mdwn
@@ -0,0 +1,7 @@
+I have a git installation on my web server (web faction hosting). It allows me to run repositories from my hosting account. 
+
+What I want is to use git-annex as a dropbox replacement. Specifically, the central repository being my web server and then using local installations on my 2 mac laptops (primarily), access through browser on windows, and access on android as well (browser or some other method). 
+
+I'm looking at the install instructions, walkthrough, etc. What I'm initially not clear on is whether I need to install git-annex on my (linux centOS) webserver and any machine through which I'm accessing the repo? Seems like that would be the case of course, but I wanted to validate. 
+
+Am I going to run into issues that folks might already be able to warn me about? Anything I need to know? 
diff --git a/doc/forum/first-time_setup_git-annex/comment_1_a58d83ee3a7c2251d9a775847223f8ca._comment b/doc/forum/first-time_setup_git-annex/comment_1_a58d83ee3a7c2251d9a775847223f8ca._comment
new file mode 100644
index 0000000000..8b86d7b179
--- /dev/null
+++ b/doc/forum/first-time_setup_git-annex/comment_1_a58d83ee3a7c2251d9a775847223f8ca._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-13T18:39:59Z"
+ content="""
+Sorry it took so long to get back to you.
+
+You do not necessarily have to have git-annex installed on your web server. But it will open up one of the nicest ways to use git-annex with a server, which is to put a bare git repository on the server, and let git-annex send the contents of large files to that repository. It's fine to install any old version of git-annex on the server, they're all forwards and backwards compatable.
+
+In any case, you need git-annex installed on any computers where you want to access the repository, certainly.
+
+"""]]
diff --git a/doc/forum/flickrannex_--_not_sure_I_get_it.mdwn b/doc/forum/flickrannex_--_not_sure_I_get_it.mdwn
new file mode 100644
index 0000000000..fa69d61587
--- /dev/null
+++ b/doc/forum/flickrannex_--_not_sure_I_get_it.mdwn
@@ -0,0 +1,7 @@
+flickrannex -- is it a way to upload your images to flickr by putting them in a git annex directory, and make them retrievable from it handily that way?
+
+Or is it a hack to exploit flickr's free storage, by allowing you to somehow wrap your files in images and uploading them?
+
+My python and knowledge of how git annex's hooks work is not good enough for me to be certain by reading the code.
+
+Thanks
diff --git a/doc/forum/flickrannex_--_not_sure_I_get_it/comment_1_57ea9f26760f970a70f09934d31a79b5._comment b/doc/forum/flickrannex_--_not_sure_I_get_it/comment_1_57ea9f26760f970a70f09934d31a79b5._comment
new file mode 100644
index 0000000000..3d5da7d374
--- /dev/null
+++ b/doc/forum/flickrannex_--_not_sure_I_get_it/comment_1_57ea9f26760f970a70f09934d31a79b5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-27T01:48:43Z"
+ content="""
+Little bit of both I think. Pictures uploaded by it are visible on flickr. You can configure a [[preferred_content]] expression so the flickr remote only wants *.jpg etc. Any other file is wrapped inside an image so flickr will accept it. It would probably be a good idea to configure git-annex to `untrust` your repository if using it this way.
+"""]]
diff --git a/doc/forum/flickrannex_--_not_sure_I_get_it/comment_2_ba93563b4ce1f6497a9f1d5e6eb0d1bb._comment b/doc/forum/flickrannex_--_not_sure_I_get_it/comment_2_ba93563b4ce1f6497a9f1d5e6eb0d1bb._comment
new file mode 100644
index 0000000000..cb9b65f6a0
--- /dev/null
+++ b/doc/forum/flickrannex_--_not_sure_I_get_it/comment_2_ba93563b4ce1f6497a9f1d5e6eb0d1bb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 2"
+ date="2013-05-27T01:57:25Z"
+ content="""
+Cool, thanks!  I ran into some issues setting it up, I'll take those to github (I hadn't been able to get as far as setting it up with an annex)
+"""]]
diff --git a/doc/forum/flickrannex_--_not_sure_I_get_it/comment_3_74f143965f48c89a3583acf1b6a7635a._comment b/doc/forum/flickrannex_--_not_sure_I_get_it/comment_3_74f143965f48c89a3583acf1b6a7635a._comment
new file mode 100644
index 0000000000..21fcde85d3
--- /dev/null
+++ b/doc/forum/flickrannex_--_not_sure_I_get_it/comment_3_74f143965f48c89a3583acf1b6a7635a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="I noticed you stopped filing issues on github"
+ date="2013-06-02T10:38:04Z"
+ content="""
+Does that mean the hook is working properly for you properly now?
+
+"""]]
diff --git a/doc/forum/flickrannex_--_not_sure_I_get_it/comment_4_493bb86dedfa91ccc0c9be4045953ee4._comment b/doc/forum/flickrannex_--_not_sure_I_get_it/comment_4_493bb86dedfa91ccc0c9be4045953ee4._comment
new file mode 100644
index 0000000000..dd474ef593
--- /dev/null
+++ b/doc/forum/flickrannex_--_not_sure_I_get_it/comment_4_493bb86dedfa91ccc0c9be4045953ee4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 4"
+ date="2013-06-02T20:27:08Z"
+ content="""
+it is, thank you!  working perfectly.
+"""]]
diff --git a/doc/forum/flickrannex_--_not_sure_I_get_it/comment_5_2c410aa478b21c0e6eb0e4d54bc8c362._comment b/doc/forum/flickrannex_--_not_sure_I_get_it/comment_5_2c410aa478b21c0e6eb0e4d54bc8c362._comment
new file mode 100644
index 0000000000..f55a894a89
--- /dev/null
+++ b/doc/forum/flickrannex_--_not_sure_I_get_it/comment_5_2c410aa478b21c0e6eb0e4d54bc8c362._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="comment 5"
+ date="2013-06-02T20:29:48Z"
+ content="""
+Good :)
+"""]]
diff --git a/doc/forum/folder_size_question.mdwn b/doc/forum/folder_size_question.mdwn
new file mode 100644
index 0000000000..51d11ca8bc
--- /dev/null
+++ b/doc/forum/folder_size_question.mdwn
@@ -0,0 +1,3 @@
+For test purposes I copied a folder into my local repository to do some tests. 
+I now had a look at the original folder size and the size of the repository and compared it to the original folder and the repo is about 2x bigger. How come?
+=> http://screencast.com/t/Tvqe5P22Ux
diff --git a/doc/forum/folder_size_question/comment_1_782cbf836335d86ff29853c34f00fec3._comment b/doc/forum/folder_size_question/comment_1_782cbf836335d86ff29853c34f00fec3._comment
new file mode 100644
index 0000000000..36bb93df3e
--- /dev/null
+++ b/doc/forum/folder_size_question/comment_1_782cbf836335d86ff29853c34f00fec3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-05-16T17:02:29Z"
+ content="""
+I don't have bandwidth to watch screencasts, so I can only guess.
+
+My first guess would be that you used `git add` to check the files into a git repository. This will exactly double the disk space, since each file is now stored in .git/ as well as in the working tree. This is a problem that git-annex solves.
+
+If you'd like to provide more information (cut and paste of details is useful), I can perhaps make more informed guesses. Or you could use `du` so see which files are taking up more space than you expect.
+"""]]
diff --git a/doc/forum/folder_size_question/comment_2_391aa62e4d8c496a58be4707522d8edb._comment b/doc/forum/folder_size_question/comment_2_391aa62e4d8c496a58be4707522d8edb._comment
new file mode 100644
index 0000000000..f031deb818
--- /dev/null
+++ b/doc/forum/folder_size_question/comment_2_391aa62e4d8c496a58be4707522d8edb._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="comment 2"
+ date="2014-05-16T17:15:59Z"
+ content="""
+I don't recall doing anything besides using the git annex assistant...
+
+That link is just a screen shot...
+
+anyway here is more info:
+
+du -h -s git-annex/*
+ 38M	git-annex/Finance
+8.0K	git-annex/archive
+
+BUT if I check the folder git-annex's properties it says: 
+
+45 980 806 bytes (80,4 MB on disk) for 8 420 items
+
+Is that normal?
+"""]]
diff --git a/doc/forum/folder_size_question/comment_3_1e850dbe36fafe0505b60dd2ce0bd5d7._comment b/doc/forum/folder_size_question/comment_3_1e850dbe36fafe0505b60dd2ce0bd5d7._comment
new file mode 100644
index 0000000000..978ffcf51e
--- /dev/null
+++ b/doc/forum/folder_size_question/comment_3_1e850dbe36fafe0505b60dd2ce0bd5d7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-05-16T19:07:10Z"
+ content="""
+Sounds to me like some GUI thing that is confused in some way. Which is, in my experience not unusual when it comes to GUI things and the actual size of files on disk. I'd trust `du`.
+"""]]
diff --git a/doc/forum/folder_size_question/comment_4_907f3b1cfe745abf94a6a8ba0dbd4396._comment b/doc/forum/folder_size_question/comment_4_907f3b1cfe745abf94a6a8ba0dbd4396._comment
new file mode 100644
index 0000000000..a32e9177a5
--- /dev/null
+++ b/doc/forum/folder_size_question/comment_4_907f3b1cfe745abf94a6a8ba0dbd4396._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="comment 4"
+ date="2014-05-17T10:56:22Z"
+ content="""
+I thinks its all the small files. 
+
+    du -hs /Users/ovi/Sharing/git-annex/
+     77M	/Users/ovi/Sharing/git-annex/
+
+    du -hs /Users/ovi/Sharing/git-annex/Finance/
+     38M	/Users/ovi/Sharing/git-annex/Finance/
+
+    du -hs /Users/ovi/Sharing/git-annex/.git/
+     39M	/Users/ovi/Sharing/git-annex/.git/
+
+The GUI shows: 
+    46 136 859 bytes (80,6 MB on disk) for 8 002 items
+
+And the hidden .git folder shows:
+    7 373 616 bytes (41 MB on disk) for 7 625 items
+
+So apparently there are a lot of very small files, smaller than the blocksize hence the info is skewed? Anyway, I think its alright?
+"""]]
diff --git a/doc/forum/forumbug.mdwn b/doc/forum/forumbug.mdwn
new file mode 100644
index 0000000000..a2535e289a
--- /dev/null
+++ b/doc/forum/forumbug.mdwn
@@ -0,0 +1,3 @@
+This forum is not for bug reports, but people ignore that and post them
+here anyway. Such posts get tagged with this forumbug tag, which makes
+them be listed in [[bugs]] rather than in the forum.
diff --git a/doc/forum/freebsd_git-annex_seems_to_be_in_an_upgrade_loop.mdwn b/doc/forum/freebsd_git-annex_seems_to_be_in_an_upgrade_loop.mdwn
new file mode 100644
index 0000000000..06ddda244d
--- /dev/null
+++ b/doc/forum/freebsd_git-annex_seems_to_be_in_an_upgrade_loop.mdwn
@@ -0,0 +1,16 @@
+I installed git-annex on my freenas running freebsd according to the instructions on this site. 
+every now and then it'll pop up (when using the webapp) telling me git-annex has been updated, do I want to restart. 
+if I say yes, the webapp dies, I have to manually stop git annex assistant --stop and after a few minutes of using the webapp it again tells me it has been updated...
+
+only saw this in the logs:
+UpgradeWatcher: A new version of git-annex has been installed. 
+
+
+Also, I connected 2 repos (on my NAS with freebsd and on my Macbook) but the NAS one can't connect to the MAcbook via SSH
+ssh: connect to host 192.168.178.33 port 22: Connection refused 
+
+How is this supposed to work? Obviously for now it shows its only syncing metadata with my MACbook: 
+syncing enabled (metadata only)
+
+Also, both repositories are bare, direct but when a file got pulled from the NAS to the MACbook it was a symlink and not the file itself, so what's wrong here?
+
diff --git a/doc/forum/freebsd_git-annex_seems_to_be_in_an_upgrade_loop/comment_1_ce8e7f58c3b81ec334436726be70bde5._comment b/doc/forum/freebsd_git-annex_seems_to_be_in_an_upgrade_loop/comment_1_ce8e7f58c3b81ec334436726be70bde5._comment
new file mode 100644
index 0000000000..d0548a5b3f
--- /dev/null
+++ b/doc/forum/freebsd_git-annex_seems_to_be_in_an_upgrade_loop/comment_1_ce8e7f58c3b81ec334436726be70bde5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 1"
+ date="2015-10-19T07:09:53Z"
+ content="""
+Also found this in the logs:
+
+> swap_pager_getswapspace(16): failed
+> swap_pager_getswapspace(6): failed
+> pid 85783 (lsof), uid 1001, was killed: out of swap space
+
+And I didn't do anything except create 2 repos, connect them, no files inside, still testing...
+"""]]
diff --git a/doc/forum/freebsd_git-annex_seems_to_be_in_an_upgrade_loop/comment_2_43cdcdfff3aaa4482e6182d3dd77b61a._comment b/doc/forum/freebsd_git-annex_seems_to_be_in_an_upgrade_loop/comment_2_43cdcdfff3aaa4482e6182d3dd77b61a._comment
new file mode 100644
index 0000000000..370513ae58
--- /dev/null
+++ b/doc/forum/freebsd_git-annex_seems_to_be_in_an_upgrade_loop/comment_2_43cdcdfff3aaa4482e6182d3dd77b61a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-10-19T17:42:25Z"
+ content="""
+I don't know of any freebsd build of git-annex that would use its
+self-upgrade facility. I don't provide one, and I don't see why the
+freebsd porters would enable that feature.
+
+I wonder if you're somehow using the linux standalone build on freebsd via
+some linux syscall compatability layer. Which is interesting if it works,
+but not suprising if it fails.. 
+
+In particular, it seems likely that the
+linux version of lsof wouldn't be very happy when run in a freebsd
+system, and perhaps that's why it's running out of memory.
+"""]]
diff --git a/doc/forum/fsck_gives_false_positives.mdwn b/doc/forum/fsck_gives_false_positives.mdwn
new file mode 100644
index 0000000000..2fae57c4ed
--- /dev/null
+++ b/doc/forum/fsck_gives_false_positives.mdwn
@@ -0,0 +1,6 @@
+Hi,
+
+I use git-annex 3.20120123 on a debian-testing amd-64 machine with software RAID6 and LVM2 on it. I needed to move the whole `/home` directory to another LV (the new LV is on encrypted PV, the old LV is encrypted and not properly aligned; I'm changing from encrypted `/home` only to encrypted everything except `/boot`), so I have used the `rsync -aAXH` from a `ro` mounted `/home` to a new LV mounted on `/mnt/home_2`. After the move was complete I run the `git annex fsck` on my (4TB of) data. The fsck finds some files bad, and moves them to the `..../bad` directory. So far so good, this is how it should be, right? But then- I have a file with sha1sum of all my files. So - I checked the 'bad' file against that. It was OK. Then I computed the SHA256 of the file - this is used by `git annex fsck`. It was OK, too. So how did it happen, that the file was marked as bad? Do I miss something here? Could it be related to the hardware (HDDs) and silent data corruption? Or is it the undesirable effect of rsync? Or maybe the fsck is at fault here?
+
+Any ideas?
+
diff --git a/doc/forum/fsck_gives_false_positives/comment_1_b91070218b9d5fb687eeee1f244237ad._comment b/doc/forum/fsck_gives_false_positives/comment_1_b91070218b9d5fb687eeee1f244237ad._comment
new file mode 100644
index 0000000000..c65eaf51d9
--- /dev/null
+++ b/doc/forum/fsck_gives_false_positives/comment_1_b91070218b9d5fb687eeee1f244237ad._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-02-14T16:58:33Z"
+ content="""
+Well, it should only move files to `.git/annex/bad/` if their filesize is wrong, or their checksum is wrong.
+
+You can try moving a file out of `.git/annex/bad/` and re-run fsck and see if it fails it again. (And if it does, paste in a log!) 
+
+To do that -- 
+Suppose you have a file `.git/annex/bad/SHA256-s33--5dc45521382f1c7974d9dbfcff1246370404b952` and you know that file `foobar` was supposed to have that content (you can check that `foobar` is a symlink to that SHA value). Then reinject it:
+
+`git annex reinject .git/annex/bad/SHA256-s33--5dc45521382f1c7974d9dbfcff1246370404b952 foobar`
+"""]]
diff --git a/doc/forum/fsck_gives_false_positives/comment_2_f51c53f3f6e6ee1ad463992657db5828._comment b/doc/forum/fsck_gives_false_positives/comment_2_f51c53f3f6e6ee1ad463992657db5828._comment
new file mode 100644
index 0000000000..1e0111e672
--- /dev/null
+++ b/doc/forum/fsck_gives_false_positives/comment_2_f51c53f3f6e6ee1ad463992657db5828._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="antymat"
+ ip="77.190.74.127"
+ subject="comment 2"
+ date="2012-02-14T22:48:37Z"
+ content="""
+Thanks, joey, but I still do not know, why the file that has been (and *is*) OK according to separate sha1 and sha256 checks, has been marked 'bad' by `fsck` and moved to `.git/annex/bad`. What could be a reason for that? Could have `rsync` caused it? I know too little about internal workings of `git-annex` to answer this question.
+
+But one thing I know for certain - the false positives should *not* happen, unless something *is* wrong with the file. Otherwise, if it is unreliable, if I have to check twice, it is useless. I might as well just keep checksums of all the files and do all checks by hand...
+"""]]
diff --git a/doc/forum/fsck_gives_false_positives/comment_3_692d6d4cd2f75a497e7d314041a768d2._comment b/doc/forum/fsck_gives_false_positives/comment_3_692d6d4cd2f75a497e7d314041a768d2._comment
new file mode 100644
index 0000000000..bd807f4048
--- /dev/null
+++ b/doc/forum/fsck_gives_false_positives/comment_3_692d6d4cd2f75a497e7d314041a768d2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2012-02-14T22:57:29Z"
+ content="""
+All that git annex fsck does is checksum the file and move it away if the checksum fails. 
+
+If bad data was somehow read from the disk that one time, what you describe could occur. I cannot think of any other way it could happen.
+"""]]
diff --git a/doc/forum/fsck_gives_false_positives/comment_4_7ceb395bf8a2e6a041ccd8de63b1b6eb._comment b/doc/forum/fsck_gives_false_positives/comment_4_7ceb395bf8a2e6a041ccd8de63b1b6eb._comment
new file mode 100644
index 0000000000..038d41620c
--- /dev/null
+++ b/doc/forum/fsck_gives_false_positives/comment_4_7ceb395bf8a2e6a041ccd8de63b1b6eb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="antymat"
+ ip="77.190.74.127"
+ subject="comment 4"
+ date="2012-02-15T07:13:12Z"
+ content="""
+OK, thanks. I was just wondering - since there are links in git(-annex), and a hard links too, that maybe the issue has been caused by `rsync`.
+
+I will keep my eye on that and run checks with my own checksum and `fsck` from time to time, and see what happens. I will post my results here, but the whole run (`fsck` or checksum) takes almost 2 days, so I will not do it too often... ;)
+"""]]
diff --git a/doc/forum/fsck_gives_false_positives/comment_5_86484a504c3bbcecd5876982b9c95688._comment b/doc/forum/fsck_gives_false_positives/comment_5_86484a504c3bbcecd5876982b9c95688._comment
new file mode 100644
index 0000000000..7f0fbf96a0
--- /dev/null
+++ b/doc/forum/fsck_gives_false_positives/comment_5_86484a504c3bbcecd5876982b9c95688._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 5"
+ date="2012-02-15T15:22:56Z"
+ content="""
+The symlinks are in the git repository. So if the rsync damanged one, git would see the change. And nothing that happens to the symlinks can affect fsck.
+
+git-annex does not use hard links at all.
+
+fsck corrects mangled file permissions. It is possible to screw up the permissions so badly that it cannot see the files at all (ie, chmod 000 on a file under .git/annex/objects), but then fsck will complain and give up, not move the files to bad.
+So I don't see how a botched rsync could result in fsck moving a file with correct content to bad.
+"""]]
diff --git a/doc/forum/fsck_gives_false_positives/comment_6_1d4fbbd212fa92967abda346323031f4._comment b/doc/forum/fsck_gives_false_positives/comment_6_1d4fbbd212fa92967abda346323031f4._comment
new file mode 100644
index 0000000000..294778cbfa
--- /dev/null
+++ b/doc/forum/fsck_gives_false_positives/comment_6_1d4fbbd212fa92967abda346323031f4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWQTrnPloMWiPFg8Y2Y5g-2IYe26D0KKw"
+ nickname="Jim"
+ subject="comment 6"
+ date="2012-07-07T16:18:06Z"
+ content="""
+It's also possible you got a one-time DRAM corruption.  You have to expect those to happen every so often unless you're using ECC memory.
+"""]]
diff --git a/doc/forum/ga-ncdu.mdwn b/doc/forum/ga-ncdu.mdwn
new file mode 100644
index 0000000000..d4b48c2097
--- /dev/null
+++ b/doc/forum/ga-ncdu.mdwn
@@ -0,0 +1,5 @@
+I've just written a quick script which provides an output which ncdu will use.
+
+It uses the size from the key for apparent size and the size of the file (if present) for the disk size so 'a' toggles between total size of the annex and the actually used disk space.
+
+Is there anyone else interested in having this? If so, I'll tidy it up and release it :)
diff --git a/doc/forum/ga-ncdu/comment_1_cde3f7bbd099b303bacdaa5e1588b71e._comment b/doc/forum/ga-ncdu/comment_1_cde3f7bbd099b303bacdaa5e1588b71e._comment
new file mode 100644
index 0000000000..6d7caee2c1
--- /dev/null
+++ b/doc/forum/ga-ncdu/comment_1_cde3f7bbd099b303bacdaa5e1588b71e._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="andy"
+ subject="comment 1"
+ date="2015-03-28T22:03:53Z"
+ content="""
+I'd take a look. I just downloaded ncdu prompted by your comment, and that would be helpful to get sane output regarding my annexed files.
+"""]]
diff --git a/doc/forum/ga-ncdu/comment_2_8d369dc264ccaf80490c1cb37a330239._comment b/doc/forum/ga-ncdu/comment_2_8d369dc264ccaf80490c1cb37a330239._comment
new file mode 100644
index 0000000000..ef5cb76f24
--- /dev/null
+++ b/doc/forum/ga-ncdu/comment_2_8d369dc264ccaf80490c1cb37a330239._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="markusk"
+ subject="Sounds nice !"
+ date="2015-03-28T22:41:45Z"
+ content="""
+
+I would be very glad if you would release it!
+"""]]
diff --git a/doc/forum/ga-ncdu/comment_3_c5ce3b663de76b50754de70b3fb23bf0._comment b/doc/forum/ga-ncdu/comment_3_c5ce3b663de76b50754de70b3fb23bf0._comment
new file mode 100644
index 0000000000..318441e7b5
--- /dev/null
+++ b/doc/forum/ga-ncdu/comment_3_c5ce3b663de76b50754de70b3fb23bf0._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 3"
+ date="2015-04-12T22:12:53Z"
+ content="""
+Whelp, didn't realise it had been over two weeks! Got caught up in other stuff (VR).
+
+[Here's the bitbucket repository!](https://bitbucket.org/CandyAngel/ga-ncdu)
+
+I've coded my own JSON output so it doesn't depend on any non-core Perl modules.
+
+Please let me know of any bugs, feature requests etc. Feedback would be appreciated, even just letting me know you are using it would be great!
+
+    ga-ncdu.pl ~/mah_annex | ncdu -f-
+"""]]
diff --git a/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz.mdwn b/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz.mdwn
new file mode 100644
index 0000000000..da8c030702
--- /dev/null
+++ b/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz.mdwn
@@ -0,0 +1,13 @@
+Hello. Am a newbie to Git Annex(ga), but love it already. I kept trying to index own important files for the past long time, but ended up all tangled up. With ga I now see a light at the end of the tunnel! (Hope it's not a train heading my way :)
+
+So thanks a bucket for writing Git Annex!
+
+I am an "archiver": Every file I add to ga repo is a never-to-be-changed file (it's checksum stays same throughout eternity, only metadata keeps changin). All I need ga for atm is to tag all files. Unfortunately we are talking about few hundred thousand files and the performance with the master git-annex-6.20170519 is not quite what one might hope for.
+
+From your design/caching_database doc I gather that the outlook with metadata is positive ( "For metadata, the story is much nicer. Querying for 30000 keys that all have a particular tag in their metadata takes 0.65s. So fast enough to be used in views." ), but  is not in a db (sqlite) yet in the master (git-annex-6.20170519) . I tried to dig through some of the Links there to find out which commit could I checkout and build to try out a cached metadata, but no avail.
+
+Since I don't ever change any file once it gets checked into the ga repo, does that simplify my possible use of current metadata cache code, or will I have to try to learn haskell and will I need to code stuff to get performance (creating views and such).
+
+TIA for any pointers, tips and cavats and THANKS AGAIN FOR WRITING GIT-ANNEX.
+
+  ganewbie01
diff --git a/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_1_0547fcabefe0b8e99a43977ffec3e28c._comment b/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_1_0547fcabefe0b8e99a43977ffec3e28c._comment
new file mode 100644
index 0000000000..db608ffb8e
--- /dev/null
+++ b/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_1_0547fcabefe0b8e99a43977ffec3e28c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="ganewbie01"
+ avatar="http://cdn.libravatar.org/avatar/a3b7d6e560486cb87c51cb0cf3328c8e"
+ subject="development branches inaccessible?"
+ date="2017-11-26T13:12:16Z"
+ content="""
+To not sit idle, I've been looking for development branches (specifically the one containing code that gave the rise to Joey's claim \"Querying for 30000 keys that all have a particular tag in their metadata takes 0.65s.\"), but could find only repos with the one branch - the master branch, which doesn't (naturally seem to) include the code for SQLite metadata tinkering.
+
+Is there someplace I could find such development branches please?
+"""]]
diff --git a/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_2_606281f102d8c3168cbc55142a996e05._comment b/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_2_606281f102d8c3168cbc55142a996e05._comment
new file mode 100644
index 0000000000..f503270d17
--- /dev/null
+++ b/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_2_606281f102d8c3168cbc55142a996e05._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="olaf"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="comment 2"
+ date="2017-11-27T05:39:04Z"
+ content="""
+Did you clone the repository?
+
+    $ git clone git://git-annex.branchable.com/ git-annex
+
+I see lots of branches (remember they are *remote* branches so you will need the `-a` flag):
+
+    $ git branch -a
+    * master
+      remotes/origin/HEAD -> origin/master
+      remotes/origin/atomic-store-test
+      remotes/origin/debian
+      remotes/origin/debian-jessie-backport
+      remotes/origin/debian-squeeze-backport
+      remotes/origin/debian-stable-security-fix
+      remotes/origin/debian-wheezy-backport
+      remotes/origin/ghc7.0
+      remotes/origin/improved-smudge-filters
+      remotes/origin/master
+      remotes/origin/newwinrelease
+      remotes/origin/no-direct-mode
+      remotes/origin/p2p-map
+      remotes/origin/setup
+      remotes/origin/smudge
+      remotes/origin/tweak-fetch
+      remotes/origin/uuid-type-rework
+      remotes/origin/winsplicehack
+
+You can checkout one of the branches like:
+
+    $ git checkout remotes/origin/setup
+
+Does that help?
+"""]]
diff --git a/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_3_ca138f01184631135d07835d79a95112._comment b/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_3_ca138f01184631135d07835d79a95112._comment
new file mode 100644
index 0000000000..a8933e1b4c
--- /dev/null
+++ b/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_3_ca138f01184631135d07835d79a95112._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="ganewbie01"
+ avatar="http://cdn.libravatar.org/avatar/a3b7d6e560486cb87c51cb0cf3328c8e"
+ subject="found it! ( I think ... or should I be still looking for &quot;database&quot; branch? )"
+ date="2017-11-28T01:03:05Z"
+ content="""
+hi, thanks for your reply;
+I've spent several hours today looking through the git-annex repo. I think it was a great idea to place the forums and everything in one repo! It provides sort of a \"running commentary\" on what was going on and why ...
+
+After a couple of hours looking through the repo using tig, I checked out the key commit \"bb242bdd82a438ebfc937609d8d13b512cb49943\" and found the foo.hs and fooes.hs files which are most likely the ones that Joey was writing about when he expressed hopes for metadata in an sqlite file. ( I didn't find a way to see \"old branches\" though, e.g. the one named `database`. Maybe if I study git more ... )
+
+Thanks for your reply to a silly newbie question anyway! I'll study this some more and see if I have some on-topic questions (hopefully they will be more educated by then :) )
+
+g'day!
+"""]]
diff --git a/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_4_750e5eaac44e53030be18858c03cbe6c._comment b/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_4_750e5eaac44e53030be18858c03cbe6c._comment
new file mode 100644
index 0000000000..fa96166ec1
--- /dev/null
+++ b/doc/forum/ga_dev_newbie_Q__58___pointers_to_start_playing_with_metadata_cache_plz/comment_4_750e5eaac44e53030be18858c03cbe6c._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-11-28T21:47:54Z"
+ content="""
+Yeah, you found the stuff. That's as far as the metadata cache idea has
+gotten yet. I've restored the missing "database" branch, which was just
+that commit you found.
+
+I do hope to circle back around to this eventually to speed up generating
+views and other metadata queries.
+
+But, as a programmer, you could create your own sqlite database and put
+metadata about your git-annex repository in it. Using
+`git annex metadata --batch --json` you can query git-annex
+for metadata about your files as fast as it can pull it out of git,
+and shove it into your database, and then write your own sql queries.
+
+That would be a good first step, because working with real-world
+data would help develop the sql schema and see if it'll be fast enough to
+bother with putting into git-annex.
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage.mdwn b/doc/forum/gadu_-_git-annex_disk_usage.mdwn
new file mode 100644
index 0000000000..e4109a2cfe
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage.mdwn
@@ -0,0 +1,7 @@
+Based on the thread over at [[forum/__34__du__34___equivalent_on_an_annex__63__]] I decided to finally write a du like utility for git-annex.  A 0.01 version is up over at <http://git-annex.mysteryvortex.com/git-annex-utils.html>.  It works, but I intend to make it smarter about handling git repos and annexed files, as well as adding more of the options available in the standard du utility.
+
+Currently it will tally up the sizes of links that look like they are annexed files.  I plan to make it actually interact with git and git-annex to verify the files are annexed and enable options like tallying files only from specific remotes, only missing files, not double counting files which are annexed multiple times but stored only once, etc...
+
+I'll have time to work on this on the weekends, and plan to get my git repo up soon.  After gadu is mostly complete I might work on some other tools.
+
+Releases are signed with a PGP key with fingerprint 5E1A 65D7 D5E9 56F1 C239  43DF C6C8 9A0B 6003 8953 (available on the website)
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_10_f632a62c4dbbf01b29f146893d7725f9._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_10_f632a62c4dbbf01b29f146893d7725f9._comment
new file mode 100644
index 0000000000..602cc43630
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_10_f632a62c4dbbf01b29f146893d7725f9._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="comment 10"
+ date="2013-01-14T01:54:12Z"
+ content="""
+No problem, glad to see it is useful.  I'm not exactly a web guy, but I want to get some sort of comment/discussion system up there soon so we aren't filling up Joey's web site with semi-offtopic discussion.  (also a little beautification is in order)
+
+Yes, contributions are welcome.  GPG/PGP encrypted email is the preferred mode of communication.
+
+Currently I ask for copyright assignment in case I want to change licenses in the future.  I pledge not to go to a non-free license, but the GPL3 license choice was fairly arbitrary.  I might want to add the \"or any later version\" clause, for example.  There is also potential for a library to be split off which might benefit from something like LGPL licensing or similar.  I haven't really studied the licensing situation since GPL3 came around, so I need to take some time to look into it.
+
+I don't want to have a licensing discussion here though as it would be offtopic.  Feel free to email me and we can discuss.
+
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_11_73461da2d55d040cb43e0db286975821._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_11_73461da2d55d040cb43e0db286975821._comment
new file mode 100644
index 0000000000..5f9a8bbecc
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_11_73461da2d55d040cb43e0db286975821._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 11"
+ date="2013-03-11T05:31:04Z"
+ content="""
+I don't want to steal gadu's thunder, and I really quite like having an ecosystem of tools develop around git-annex.
+
+With that said, \"git annex status .\" now shows the disk used for all files in the current directory and below. It also shows the number of keys, and the total amount of disk those keys would use.
+
+Additionally, you can use all the standard git-annex file limiting options. For example, here I'm finding out how much disk space is used by files located on a *remote* system:
+
+<pre>
+git annex status . --in turtle
+directory: .
+local annex keys: 0
+local annex size: 0 bytes
+known annex keys: 10
+known annex size: 3 gigabytes
+</pre>
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_12_6c4fb123091bde435c18ac3dfd5a9b77._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_12_6c4fb123091bde435c18ac3dfd5a9b77._comment
new file mode 100644
index 0000000000..d228e196de
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_12_6c4fb123091bde435c18ac3dfd5a9b77._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 12"
+ date="2013-03-11T05:33:09Z"
+ content="""
+BTW, I think gadu still has its own uses, due to having a du like output, that can list space used by subdirectories. You can do that with git annex status *, but it's much more verbose, and doesn't show a break down by deeper subdirectories.
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_13_8e0e86ae716ff018025808f417e1f7f6._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_13_8e0e86ae716ff018025808f417e1f7f6._comment
new file mode 100644
index 0000000000..b62b05ad89
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_13_8e0e86ae716ff018025808f417e1f7f6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkWHj0RxNMfuwvFzo2d-V6vBKOYwW_Fnfk"
+ nickname="Andrew"
+ subject="Update on determining disk usage"
+ date="2015-01-22T06:29:36Z"
+ content="""
+I just had a look at this question today as I learn git-annex.  I think the commands have changed since the last comment.  However, there remain several ways to determine disk usage, for example in the folder `Music`
+
+    git annex info Music
+
+but you could also use `du` with
+
+    du --human-readable --dereference Music
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_14_d8f69914b88feb3f3ed4f72c26dd74e5._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_14_d8f69914b88feb3f3ed4f72c26dd74e5._comment
new file mode 100644
index 0000000000..33fca774c4
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_14_d8f69914b88feb3f3ed4f72c26dd74e5._comment
@@ -0,0 +1,231 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="it's git annex info, not status"
+ date="2015-06-23T04:15:24Z"
+ content="""
+so the previous comments by joeyh were correct 2 years ago, but now git annex status behaves more like git-status than anything else, and will *not* give you disk usage.
+
+however, `git annex info` will, and if you use `--fast`, it works pretty fast as well. example, on my pictures collection:
+
+<pre>
+[1044]anarcat@marcos:Photos$ time git annex info --fast *
+directory: 1969
+local annex keys: 5
+local annex size: 10.95 megabytes
+annexed files in working tree: 5
+size of annexed files in working tree: 10.95 megabytes
+directory: 1970
+local annex keys: 26
+local annex size: 827.5 megabytes
+annexed files in working tree: 26
+size of annexed files in working tree: 827.5 megabytes
+directory: 1998
+local annex keys: 10
+local annex size: 3.31 megabytes
+annexed files in working tree: 10
+size of annexed files in working tree: 3.31 megabytes
+directory: 2004
+local annex keys: 49
+local annex size: 42.01 megabytes
+annexed files in working tree: 49
+size of annexed files in working tree: 42.01 megabytes
+directory: 2005
+local annex keys: 561
+local annex size: 379.23 megabytes
+annexed files in working tree: 561
+size of annexed files in working tree: 379.23 megabytes
+directory: 2006
+local annex keys: 932
+local annex size: 995.95 megabytes
+annexed files in working tree: 932
+size of annexed files in working tree: 995.95 megabytes
+directory: 2007
+local annex keys: 1162
+local annex size: 2.33 gigabytes
+annexed files in working tree: 1162
+size of annexed files in working tree: 2.33 gigabytes
+directory: 2008
+local annex keys: 658
+local annex size: 934.88 megabytes
+annexed files in working tree: 658
+size of annexed files in working tree: 934.88 megabytes
+directory: 2009
+local annex keys: 500
+local annex size: 836.65 megabytes
+annexed files in working tree: 500
+size of annexed files in working tree: 836.65 megabytes
+directory: 2010
+local annex keys: 1049
+local annex size: 1.85 gigabytes
+annexed files in working tree: 1049
+size of annexed files in working tree: 1.85 gigabytes
+directory: 2011
+local annex keys: 1206
+local annex size: 1.54 gigabytes
+annexed files in working tree: 1206
+size of annexed files in working tree: 1.54 gigabytes
+directory: 2012
+local annex keys: 2767
+local annex size: 10.52 gigabytes
+annexed files in working tree: 2767
+size of annexed files in working tree: 10.52 gigabytes
+directory: 2013
+local annex keys: 4071
+local annex size: 32.49 gigabytes
+annexed files in working tree: 4071
+size of annexed files in working tree: 32.49 gigabytes
+directory: 2014
+local annex keys: 6930
+local annex size: 27.34 gigabytes
+annexed files in working tree: 6930
+size of annexed files in working tree: 27.34 gigabytes
+directory: 2015
+local annex keys: 2134
+local annex size: 8.07 gigabytes
+annexed files in working tree: 2134
+size of annexed files in working tree: 8.07 gigabytes
+directory: rando-velo
+local annex keys: 184
+local annex size: 537.58 megabytes
+annexed files in working tree: 184
+size of annexed files in working tree: 537.58 megabytes
+directory: RMLL2008-Koumbit
+local annex keys: 11
+local annex size: 25.58 megabytes
+annexed files in working tree: 11
+size of annexed files in working tree: 25.58 megabytes
+5.47user 1.75system 0:14.70elapsed 49%CPU (0avgtext+0avgdata 30524maxresident)k
+121136inputs+0outputs (2major+18418minor)pagefaults 0swaps
+</pre>
+
+whereas without `--fast` is much slower, presumably because it's fetching the tracking information:
+
+<pre>
+[1045]anarcat@marcos:Photos$ time git annex info  *
+directory: 1969
+local annex keys: 5
+local annex size: 10.95 megabytes
+annexed files in working tree: 5
+size of annexed files in working tree: 10.95 megabytes
+numcopies stats:
+        numcopies +0: 5
+directory: 1970
+local annex keys: 26
+local annex size: 827.5 megabytes
+annexed files in working tree: 26
+size of annexed files in working tree: 827.5 megabytes
+numcopies stats:
+        numcopies +0: 26
+directory: 1998
+local annex keys: 10
+local annex size: 3.31 megabytes
+annexed files in working tree: 10
+size of annexed files in working tree: 3.31 megabytes
+numcopies stats:
+        numcopies +0: 10
+directory: 2004
+local annex keys: 49
+local annex size: 42.01 megabytes
+annexed files in working tree: 49
+size of annexed files in working tree: 42.01 megabytes
+numcopies stats:
+        numcopies +0: 49
+directory: 2005
+local annex keys: 561
+local annex size: 379.23 megabytes
+annexed files in working tree: 561
+size of annexed files in working tree: 379.23 megabytes
+numcopies stats:
+        numcopies +0: 561
+directory: 2006
+local annex keys: 932
+local annex size: 995.95 megabytes
+annexed files in working tree: 932
+size of annexed files in working tree: 995.95 megabytes
+numcopies stats:
+        numcopies +0: 932
+directory: 2007
+local annex keys: 1162
+local annex size: 2.33 gigabytes
+annexed files in working tree: 1162
+size of annexed files in working tree: 2.33 gigabytes
+numcopies stats:
+        numcopies +0: 1162
+directory: 2008
+local annex keys: 658
+local annex size: 934.88 megabytes
+annexed files in working tree: 658
+size of annexed files in working tree: 934.88 megabytes
+numcopies stats:
+        numcopies +0: 658
+directory: 2009
+local annex keys: 500
+local annex size: 836.65 megabytes
+annexed files in working tree: 500
+size of annexed files in working tree: 836.65 megabytes
+numcopies stats:
+        numcopies +0: 500
+directory: 2010
+local annex keys: 1049
+local annex size: 1.85 gigabytes
+annexed files in working tree: 1049
+size of annexed files in working tree: 1.85 gigabytes
+numcopies stats:
+        numcopies +0: 1049
+directory: 2011
+local annex keys: 1206
+local annex size: 1.54 gigabytes
+annexed files in working tree: 1206
+size of annexed files in working tree: 1.54 gigabytes
+numcopies stats:
+        numcopies +0: 1206
+directory: 2012
+local annex keys: 2767
+local annex size: 10.52 gigabytes
+annexed files in working tree: 2767
+size of annexed files in working tree: 10.52 gigabytes
+numcopies stats:
+        numcopies +0: 2767
+directory: 2013
+local annex keys: 4071
+local annex size: 32.49 gigabytes
+annexed files in working tree: 4071
+size of annexed files in working tree: 32.49 gigabytes
+numcopies stats:
+        numcopies +0: 4071
+directory: 2014
+local annex keys: 6930
+local annex size: 27.34 gigabytes
+annexed files in working tree: 6930
+size of annexed files in working tree: 27.34 gigabytes
+numcopies stats:
+        numcopies +0: 6930
+directory: 2015
+local annex keys: 2134
+local annex size: 8.07 gigabytes
+annexed files in working tree: 2134
+size of annexed files in working tree: 8.07 gigabytes
+numcopies stats:
+        numcopies +0: 2134
+directory: rando-velo
+local annex keys: 184
+local annex size: 537.58 megabytes
+annexed files in working tree: 184
+size of annexed files in working tree: 537.58 megabytes
+numcopies stats:
+        numcopies +0: 184
+directory: RMLL2008-Koumbit
+local annex keys: 11
+local annex size: 25.58 megabytes
+annexed files in working tree: 11
+size of annexed files in working tree: 25.58 megabytes
+numcopies stats:
+        numcopies +0: 11
+37.46user 5.70system 1:54.20elapsed 37%CPU (0avgtext+0avgdata 30704maxresident)k
+107912inputs+0outputs (2major+19426minor)pagefaults 0swaps
+</pre>
+
+14 seconds vs 114 seconds! almost an order of magnitude of difference...
+
+still, it seems to me `git annex info --fast $path` should be more clearly put forward as an alternative du solution for now. maybe this should be made into a tips page?
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_1_067d0ffe8900751bd2d2743254ac4d77._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_1_067d0ffe8900751bd2d2743254ac4d77._comment
new file mode 100644
index 0000000000..9699b6ee68
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_1_067d0ffe8900751bd2d2743254ac4d77._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="0.02 is up"
+ date="2012-12-08T14:20:16Z"
+ content="""
+I fixed some bugs that gave the wrong answer occasionally, and made gadu much smarter now.
+
+It now searches for the .git dir an makes sure the git-annex links are well formed before counting them.
+I also added a few more du like options.
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_2_ec8b57426e4d82c3392eb7dd683f2ddc._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_2_ec8b57426e4d82c3392eb7dd683f2ddc._comment
new file mode 100644
index 0000000000..04c6c3f650
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_2_ec8b57426e4d82c3392eb7dd683f2ddc._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://sunny256.sunbase.org/"
+ nickname="sunny256"
+ subject="comment 2"
+ date="2012-12-08T15:35:16Z"
+ content="""
+Have downloaded v0.02 and experimented a bit, and it seems to work nicely. A couple of things, though:
+
+- It displays the sizes in 512 byte blocks as default. I find that very confusing, and the standard `du`(1) from GNU coreutils uses 1024kB as default. AFAIK 512 byte blocks is an old way of measuring sizes from the really ancient UNIX days. Traditionally correct, maybe, but not very useful these days.
+- When not specifying a path, can it use \"`.`\" as default?
+- A human-readable format would've been nice, like 234M or 13G. The `du`(1) from GNU coreutils uses `-h` for this, but that option is already used for `--help`. And that's OK, I think `-h` should be reserved for that purpose. IMHO using `-h` as a synonym for `--human-readable` was a bad choice by coreutils, but it's too late to change that now.
+
+Is there any Git repository available for git-annex-utils somewhere? That's my preferred way of getting updates and follow the development.
+
+Anyway, thanks. :)
+
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_3_38296fef5a2dc5794c2dc09df676b8c1._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_3_38296fef5a2dc5794c2dc09df676b8c1._comment
new file mode 100644
index 0000000000..42e4f5a713
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_3_38296fef5a2dc5794c2dc09df676b8c1._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="gadu 0.03 is up"
+ date="2012-12-09T13:05:10Z"
+ content="""
+* 1K blocksize is now the default
+* \".\" is now the default path
+* implemented -B/--block-size option
+* --help is no longer -h, it only has a long option like du
+* implemented -h/--human-readable option
+
+du will take up to yottabytes for the --block-size option.  I had been fudging the sizes with a size_t thinking 16 exabytes was plenty big enough for now, but since I was implementing --block-size I went ahead and converted everything to use the GNU MP.  So libgmp is now a dependency.
+
+--human-readable probably doesn't have exactly the same output, but I think it is good enough.  I tried to make the options work mostly the same as du from core-utils.  Let me know if you find other discrepancies.
+
+I'll see about making the git tree available soon, but it may have to wait until next weekend.  I may also look into a forum for the website, or a mailing list.
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_4_1bcc94f9982c6cfd0888f3dba0f9221e._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_4_1bcc94f9982c6cfd0888f3dba0f9221e._comment
new file mode 100644
index 0000000000..807dac1b38
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_4_1bcc94f9982c6cfd0888f3dba0f9221e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://sunny256.sunbase.org/"
+ nickname="sunny256"
+ subject="comment 4"
+ date="2012-12-09T20:13:47Z"
+ content="""
+Thanks a lot, Steve. Awesome, got everything on my wishlist. :) A very useful utility, and works perfectly. Will be using this a lot. git-annex-utils is a good name for this, I'm sure if you place it on GitHub or somewhere else you'll get lots of contributions and this could grow to be a project containing many useful utilities for git-annex.
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_5_4365cd3031456fac1b563ee72984638e._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_5_4365cd3031456fac1b563ee72984638e._comment
new file mode 100644
index 0000000000..e2611dbaaf
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_5_4365cd3031456fac1b563ee72984638e._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="comment 5"
+ date="2012-12-10T04:07:53Z"
+ content="""
+I pay attention to feedback ;)
+
+I'm not done with it yet, I want to add in some options to limit what gets counted.
+
+For example:  If you have two annexed files that contain the same content using the same backend, they will be stored only once in the .git/annex/objects directory but be counted twice by gadu.
+
+I want to fix that, but I'll leave an option to keep that behavior if you want.  I also want to add options to count or not count files that exist in a certain repo.  It will be very easy to add options to only count files that you have or don't have locally as well.
+
+Making it pay attention to environment variables that git and git-annex do would also be a good idea. (like GIT_DIR, etc...)
+
+I'm open to good ideas that anybody has, unfortunately I can only work on it on the weekends for now.
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_6_2b03d7b857497cb811e992f85700cdcc._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_6_2b03d7b857497cb811e992f85700cdcc._comment
new file mode 100644
index 0000000000..9b8d049088
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_6_2b03d7b857497cb811e992f85700cdcc._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="markus"
+ ip="79.243.252.165"
+ subject="Great util!"
+ date="2012-12-28T17:45:27Z"
+ content="""
+Hi 
+
+gadu is a great util! The speed increase compared to \"du -smL\" will make it my fav. util for size calc! 
+
+ciao markus 
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_7_03a4dfaf3bd73d41c6f3c3fab0a6a922._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_7_03a4dfaf3bd73d41c6f3c3fab0a6a922._comment
new file mode 100644
index 0000000000..05f20ddcc2
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_7_03a4dfaf3bd73d41c6f3c3fab0a6a922._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="sizes has git-annex support"
+ date="2012-12-30T22:47:42Z"
+ content="""
+Just to note that I already added git-annex support to my \"sizes\" utility on Hackage several months back.  With -A, it shows you storage totals with annex symlinks computed fully resolved.
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_8_fc6ddb4dc075ee42368863c1b026dbf7._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_8_fc6ddb4dc075ee42368863c1b026dbf7._comment
new file mode 100644
index 0000000000..642ad3d961
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_8_fc6ddb4dc075ee42368863c1b026dbf7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Steve"
+ ip="92.104.175.136"
+ subject="git repo is now up"
+ date="2013-01-01T23:39:33Z"
+ content="""
+sunny256, the git repo is now accessible at <http://git.mysteryvortex.com>
+
+Markus, never used the -m option myself.  I added it in git it'll be in the next tarball.  (I plan to go through the du man page and add all appropriate options soon)
+
+John, I wasn't aware of your sizes utility.  I'll look into it.
+
+"""]]
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_9_f03254e518cbdda73e4b88e72476275d._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_9_f03254e518cbdda73e4b88e72476275d._comment
new file mode 100644
index 0000000000..d3ebbae61d
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_9_f03254e518cbdda73e4b88e72476275d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://sunny256.sunbase.org/"
+ nickname="sunny256"
+ subject="The git-annex-utils repo"
+ date="2013-01-09T09:39:16Z"
+ content="""
+Thanks for setting up the git-annex-utils repo, Steve. Will install the newest gadu(1) on my computers now. I'll probably contribute some patches for some utility scripts or programs, if that's OK. What's your preferred way to receive patches? GPG-encrypted mail to your address in the commit log?
+"""]]
diff --git a/doc/forum/gcrypt_os_x_app_vs_brew.mdwn b/doc/forum/gcrypt_os_x_app_vs_brew.mdwn
new file mode 100644
index 0000000000..98a2d5f5d3
--- /dev/null
+++ b/doc/forum/gcrypt_os_x_app_vs_brew.mdwn
@@ -0,0 +1,18 @@
+Gcrypt remotes work when using the git-annex command bundled in the git-annex.app. But gcrypt doesn't work when git-annex is installed via home-brew (brew install git-annex).
+
+The initial push will work, any subsequent commands (push/pull) will fail with:
+
+    gpg: anonymous recipient; trying secret key...
+    gpg: anonymous recipient; trying secret key...
+    gpg: anonymous recipient; trying secret key...
+    gpg: anonymous recipient; trying secret key...
+    gpg: decryption failed: No secret key
+    gcrypt: Failed to decrypt manifest!
+
+In both cases (app/brew) it tries the same keys. The app version will use its own version of gpg, which will trigger password prompts. With the brew version gpgtools is used, so I won't get any prompts. (Keychain)
+
+I tried "echo i | gpg -e -R XX -R XX | gpg -d" with the same recipients as the repo. It works well. 
+
+Has anybody hints or ideas what to try next?
+
+Best, Jean-Louis
diff --git a/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_cce5e2c16720cc8e32a4a479f50ce6b3._comment b/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_cce5e2c16720cc8e32a4a479f50ce6b3._comment
new file mode 100644
index 0000000000..bcf094073d
--- /dev/null
+++ b/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_cce5e2c16720cc8e32a4a479f50ce6b3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ganwell"
+ ip="178.174.3.221"
+ subject="Problem solved"
+ date="2014-08-14T23:53:05Z"
+ content="""
+It turns out gpgtools will save to wrong passphrase to the keychain without complaining. Thats why standard gpg worked and gpgtools didn't: There was a typo in the passphrase in the keychain.
+"""]]
diff --git a/doc/forum/gcrypt_os_x_app_vs_brew/comment_2_8df8ba1ccea0f68110593ed90a9cad6d._comment b/doc/forum/gcrypt_os_x_app_vs_brew/comment_2_8df8ba1ccea0f68110593ed90a9cad6d._comment
new file mode 100644
index 0000000000..fcdfba41de
--- /dev/null
+++ b/doc/forum/gcrypt_os_x_app_vs_brew/comment_2_8df8ba1ccea0f68110593ed90a9cad6d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 2"
+ date="2014-08-15T16:04:08Z"
+ content="""
+Note that you can avoid the trying of multiple keys by doing `git config gcrypt.publish-participants true` -- this is done by default by the assistant when setting up new gcrypt remotes. It needs my branch of git-remote-gcrypt, which is included in the osx app, I don't know which one is being used in brew.
+"""]]
diff --git a/doc/forum/gcrypt_os_x_app_vs_brew/comment_3_be4de1663a37f49a4e42d6b21c0178fe._comment b/doc/forum/gcrypt_os_x_app_vs_brew/comment_3_be4de1663a37f49a4e42d6b21c0178fe._comment
new file mode 100644
index 0000000000..99f3b7cbe9
--- /dev/null
+++ b/doc/forum/gcrypt_os_x_app_vs_brew/comment_3_be4de1663a37f49a4e42d6b21c0178fe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ganwell"
+ ip="46.14.43.36"
+ subject="brew doesn't include git-remote-gcrypt"
+ date="2014-08-19T21:54:16Z"
+ content="""
+Brew doesn't include git-remote-gcrypt, so I installed your fork of it manually. That works well and if you use a symlink to include it in the PATH you can easily update (pull) the repo. If one can install git-remote-gcrypt using brew, I don't know how.
+
+Best, Jean-Louis
+"""]]
diff --git a/doc/forum/get_and_copy_with_bare_repositories.mdwn b/doc/forum/get_and_copy_with_bare_repositories.mdwn
new file mode 100644
index 0000000000..846887f96d
--- /dev/null
+++ b/doc/forum/get_and_copy_with_bare_repositories.mdwn
@@ -0,0 +1,7 @@
+is `git annex get` and `git annex copy --to somewhere` expected to work with bare repos? the [[bare repositories]] page doesn't indicate otherwise, but a `git annex get` does plain nothing in my setup.
+
+if it's supposed not to work, there should be an error message saying that and an indication on the [[bare repositories]], otherwise, how can i trace it down?
+
+in case it is just unimplemented for lack of use cases: my setup consists of several laptops using parts of a 200gb+ photo collection, a central trusted server that should host everything, and an external encrypted remote backup. clients *should* copy everything they add to both central locations, but i'd prefer the trusted server to sync the two of them too.
+
+`get` and `copy` usually operate on the current directory, which in case of a bare repo does not contain any relevant files, but i tried explicitly specifying files too. `git annex` should either look them up in master, or always operate on all files (as indexed in the `git-annex` branch) unconditionally.
diff --git a/doc/forum/get_and_copy_with_bare_repositories/comment_1_a6e4628c0770e3f5e81348a6f29dd845._comment b/doc/forum/get_and_copy_with_bare_repositories/comment_1_a6e4628c0770e3f5e81348a6f29dd845._comment
new file mode 100644
index 0000000000..a19dd86310
--- /dev/null
+++ b/doc/forum/get_and_copy_with_bare_repositories/comment_1_a6e4628c0770e3f5e81348a6f29dd845._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.11.120"
+ subject="comment 1"
+ date="2012-11-13T17:30:31Z"
+ content="""
+git-annex commands only operate on files in the currently checked out working copy. You can send files to/from bare repos from non-bare repos. But you cannot do anything with them inside the bare repo, just as regular git doesn't let you commit inside a bare repo.
+
+There is talk about [[todo/add_-all_option]], which would be usable in bare repos.
+"""]]
diff --git a/doc/forum/get_and_copy_with_bare_repositories/comment_2_652fa1bae5c2bb63dcffcbda97a567c4._comment b/doc/forum/get_and_copy_with_bare_repositories/comment_2_652fa1bae5c2bb63dcffcbda97a567c4._comment
new file mode 100644
index 0000000000..fdf9f91a2b
--- /dev/null
+++ b/doc/forum/get_and_copy_with_bare_repositories/comment_2_652fa1bae5c2bb63dcffcbda97a567c4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 2"
+ date="2013-07-03T18:13:25Z"
+ content="""
+`git annex get` and `git annex copy`, as well as `git annex move` can now be used in a bare repository. In this mode, they behave as if --all were specified, and so operate on every single version of every single file.
+"""]]
diff --git a/doc/forum/get_content_of_a_file_from_a_file.mdwn b/doc/forum/get_content_of_a_file_from_a_file.mdwn
new file mode 100644
index 0000000000..3965ed488e
--- /dev/null
+++ b/doc/forum/get_content_of_a_file_from_a_file.mdwn
@@ -0,0 +1,5 @@
+I have two annex repositories A and B, the connection between them is terribly slow. There is a file in B that A wants to get, but incidentally A already has an exact copy of the file outside the annex repository. Is it possible for A to retrieve the content of that annexed file from its local copy rather than from B?
+
+The only idea I could come up with is to annex the file and then unannexing it, which does not seem optimal. I would prefer to not pollute the git log with these kinds of shenanigans.
+
+Any help is greatly appreciated!
diff --git a/doc/forum/get_content_of_a_file_from_a_file/comment_1_174fe84e87b31419295af3397db19671._comment b/doc/forum/get_content_of_a_file_from_a_file/comment_1_174fe84e87b31419295af3397db19671._comment
new file mode 100644
index 0000000000..a88b08e2e3
--- /dev/null
+++ b/doc/forum/get_content_of_a_file_from_a_file/comment_1_174fe84e87b31419295af3397db19671._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jd.schroeder@0c8632a8f2bffdd4b0de05a0a3660f32acdfeeca"
+ nickname="jd.schroeder"
+ subject="comment 1"
+ date="2016-07-29T19:09:44Z"
+ content="""
+Have a look at [[https://git-annex.branchable.com/git-annex-reinject/]]
+
+Good luck!
+"""]]
diff --git a/doc/forum/get_content_of_a_file_from_a_file/comment_2_9cc8905f867fedbf2b10c9ad84294543._comment b/doc/forum/get_content_of_a_file_from_a_file/comment_2_9cc8905f867fedbf2b10c9ad84294543._comment
new file mode 100644
index 0000000000..8a79b0fe5d
--- /dev/null
+++ b/doc/forum/get_content_of_a_file_from_a_file/comment_2_9cc8905f867fedbf2b10c9ad84294543._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="squid@d632da79105a546295e411392baaa70df380a4a2"
+ nickname="squid"
+ subject="comment 2"
+ date="2016-07-29T22:27:51Z"
+ content="""
+Hey, thank you very much! This is exactly what I was looking for. Unfortunately, FreeBSD sports version 5.20150727 where the --known option is not yet available, but that's a whole different problem that can be easily solved on a saturday.
+"""]]
diff --git a/doc/forum/get_fails.mdwn b/doc/forum/get_fails.mdwn
new file mode 100644
index 0000000000..9c7bdc8576
--- /dev/null
+++ b/doc/forum/get_fails.mdwn
@@ -0,0 +1,11 @@
+Running
+
+```git annex get . --from=remote```
+
+on a repository fails for particular annexed files despite the files being in the remote.
+
+I tried running `git annex fsck` in the repository but that did not seem to help.
+
+Any idea what the issue could be? 
+
+Thanks
diff --git a/doc/forum/get_fails/comment_1_9c81adaedf2b526f735ed39cb9d24709._comment b/doc/forum/get_fails/comment_1_9c81adaedf2b526f735ed39cb9d24709._comment
new file mode 100644
index 0000000000..9d2f7ff328
--- /dev/null
+++ b/doc/forum/get_fails/comment_1_9c81adaedf2b526f735ed39cb9d24709._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2020-04-13T00:53:59Z"
+ content="""
+Running with `--verbose --debug` might give more info on the cause.
+"""]]
diff --git a/doc/forum/get_fails/comment_2_4ef8a59e82e38861fd36befde1ff9542._comment b/doc/forum/get_fails/comment_2_4ef8a59e82e38861fd36befde1ff9542._comment
new file mode 100644
index 0000000000..02d80b06a1
--- /dev/null
+++ b/doc/forum/get_fails/comment_2_4ef8a59e82e38861fd36befde1ff9542._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="erewhon"
+ avatar="http://cdn.libravatar.org/avatar/b9bd5ad7176ebe149d0f051dcfe0a63e"
+ subject="comment 2"
+ date="2020-04-14T21:45:35Z"
+ content="""
+This seems like the the relevant information from `--debug`:
+
+```
+get picture.jpg (from remote...)
+[2020-04-14 22:15:30.071752896] read: cp [\"--reflink=always\",\"--preserve=timestamps\",\"../../../../../../remote/Biblio/.git/annex/objects/X1/X8/SHA256E-s46241--5daf3098b96800f3eaeef8219242ba549197c39a54d7c6ca1fbb0272e6781906.jpg/SHA256E-s46241--5daf3098b96800f3eaeef8219242ba549197c39a54d7c6ca1fbb0272e6781906.jpg\",\"../../../.git/annex/tmp/SHA256E-s46241--5daf3098b96800f3eaeef8219242ba549197c39a54d7c6ca1fbb0272e6781906.jpg\"]
+[2020-04-14 22:15:30.078134761] process done
+ExitFailure 1
+```
+
+"""]]
diff --git a/doc/forum/get_fails/comment_3_b4359d19a002a2903a895beae3888b4e._comment b/doc/forum/get_fails/comment_3_b4359d19a002a2903a895beae3888b4e._comment
new file mode 100644
index 0000000000..7ed8218860
--- /dev/null
+++ b/doc/forum/get_fails/comment_3_b4359d19a002a2903a895beae3888b4e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-04-27T16:15:41Z"
+ content="""
+Well, it does seem that the `cp` command is failing. Usually when cp fails,
+it displays an error message, so it would probably help to display the
+complete output when you run the git-annex command.
+"""]]
diff --git a/doc/forum/get_fails/comment_4_6227b1df801927cdf7a2edcc86bbdfee._comment b/doc/forum/get_fails/comment_4_6227b1df801927cdf7a2edcc86bbdfee._comment
new file mode 100644
index 0000000000..fc42a6609f
--- /dev/null
+++ b/doc/forum/get_fails/comment_4_6227b1df801927cdf7a2edcc86bbdfee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2021-06-30T14:26:33Z"
+ content="""
+I think we ran into this issue in DataLad while working on ZFS across volumes: see [datalad/issues/5750](https://github.com/datalad/datalad/issues/5750) for more info.
+"""]]
diff --git a/doc/forum/get_fails/comment_5_472d50770325a87cc0daae3e6067558c._comment b/doc/forum/get_fails/comment_5_472d50770325a87cc0daae3e6067558c._comment
new file mode 100644
index 0000000000..90ae90ca14
--- /dev/null
+++ b/doc/forum/get_fails/comment_5_472d50770325a87cc0daae3e6067558c._comment
@@ -0,0 +1,193 @@
+[[!comment format=mdwn
+ username="adina.wagner@2a4cac6443aada2bd2a329b8a33f4a7b87cc8eff"
+ nickname="adina.wagner"
+ avatar="http://cdn.libravatar.org/avatar/80b124ad61d6008fa0f6f0b4b0f7c2ef"
+ subject="comment 5"
+ date="2021-06-30T16:22:13Z"
+ content="""
+Just to migrate a bit of maybe-relevant information to this issue:
+
+
+With git-annex version ``8.20210310`` in a v8 repository, file retrieval from origin (a local path, but one a different ZFS volume) fails for a file that was created in a distributed workflow on a compute node, even though the file content is present in origin (as verified via ``git-annex fsck``).
+
+It seems to be a combination of system, git-annex version, and the way that the file in question came to life. 
+
+I only have a few \"breadcrumbs\" to the cause. For one, here is the debug output of retrieving this file with git annex ``8.20210310`` and higher versions (the latest snapshot I tried was from June this year).
+
+
+```
+(magma) adina@juseless in /tmp/memento-sss on git:master                                                              
+❱ git annex -v -d get sub-001/meg/sub-001_task-memento_proc-sss_meg.fif                                       
+[2021-06-16 17:46:07.800857089] process [3696034] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"s
+ymbolic-ref\",\"-q\",\"HEAD\"]                                                                                             
+[2021-06-16 17:46:07.803102514] process [3696034] done ExitSuccess                                                    
+[2021-06-16 17:46:07.803457883] process [3696035] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"s
+how-ref\",\"refs/heads/master\"]                                                                                         
+[2021-06-16 17:46:07.805656038] process [3696035] done ExitSuccess                                                    
+[2021-06-16 17:46:07.806171387] process [3696036] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"l
+s-files\",\"--stage\",\"-z\",\"--\",\"sub-001/meg/sub-001_task-memento_proc-sss_meg.fif\"]                                     
+[2021-06-16 17:46:07.806645086] process [3696037] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"c
+at-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]                                        
+[2021-06-16 17:46:07.807008445] process [3696038] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"c
+at-file\",\"--batch=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]                                              
+[2021-06-16 17:46:07.807465024] process [3696039] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"c
+at-file\",\"--batch=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]                                              
+get sub-001/meg/sub-001_task-memento_proc-sss_meg.fif [2021-06-16 17:46:07.812041813] process [3696040] read: git [\"--
+git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]                                           
+[2021-06-16 17:46:07.814947676] process [3696040] done ExitSuccess                                                    
+[2021-06-16 17:46:07.815368285] process [3696041] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"s
+how-ref\",\"--hash\",\"refs/heads/git-annex\"]                                                                             
+[2021-06-16 17:46:07.816996222] process [3696041] done ExitSuccess                                                    
+[2021-06-16 17:46:07.81766784] process [3696042] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"lo
+g\",\"refs/heads/git-annex..27c5aca9a00451712975cb05c5769a76b4aa0d0e\",\"--pretty=%H\",\"-n1\"]                              
+[2021-06-16 17:46:07.819557716] process [3696042] done ExitSuccess                                                    
+[2021-06-16 17:46:07.831766578] process [3696043] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"c
+at-file\",\"--batch\"]                                                                                                   
+[2021-06-16 17:46:07.832626286] process [3696044] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"c
+at-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]                                                   
+[2021-06-16 17:46:07.835034] process [3696045] read: git [\"config\",\"--null\",\"--list\"]                                 
+[2021-06-16 17:46:07.837243505] process [3696045] done ExitSuccess                                                    
+(from origin...)                                                                                                      
+[2021-06-16 17:46:08.10846678] process [3696047] read: cp [\"--reflink=always\",\"--preserve=timestamps\",\"/data/project/b
+rainpeach/memento-sss/.git/annex/objects/gX/13/MD5E-s2145810666--6dc9f68f36918eb0d4e2522ac0a3ec5a.fif/MD5E-s2145810666
+--6dc9f68f36918eb0d4e2522ac0a3ec5a.fif\",\".git/annex/tmp/MD5E-s2145810666--6dc9f68f36918eb0d4e2522ac0a3ec5a.fif\"]      
+[2021-06-16 17:46:08.110451355] process [3696047] done ExitFailure 1                                                  
+                                                                                                                      
+  failed to retrieve content from remote
+[2021-06-16 17:46:14.452454236] process [3696043] done ExitSuccess
+[2021-06-16 17:46:14.452774955] process [3696044] done ExitSuccess
+
+
+  failed to retrieve content from remote
+  Unable to access these remotes: origin
+[2021-06-16 17:46:19.631489338] process [3696371] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"c
+at-file\",\"--batch\"]
+[2021-06-16 17:46:19.632672226] process [3696372] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"c
+at-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+
+  Maybe add some of these git remotes (git remote add ...):
+        43d8b7cc-0a36-4b30-b275-5b1b4b3ecdb9 -- adina@cpu10:/tmp/ds
+failed
+[2021-06-16 17:46:19.635961178] process [3696371] done ExitSuccess
+[2021-06-16 17:46:19.636481017] process [3696372] done ExitSuccess
+[2021-06-16 17:46:19.636659226] process [3696039] done ExitSuccess
+[2021-06-16 17:46:19.637114375] process [3696038] done ExitSuccess
+[2021-06-16 17:46:19.637294665] process [3696037] done ExitSuccess
+[2021-06-16 17:46:19.637420785] process [3696036] done ExitSuccess
+git-annex: get: 1 failed
+```
+
+Note that ``cp --reflink=\"always\"`` fails on this system with \"Operation not supported\" if executed on its own.
+
+Next, I have rolled back git-annex to version ``8.20200330-1~bpo10+1`` on this system (a version where the workflow that now fails for us has succeeded), and file retrieval (using ``datalad get``) succeeds. 
+Still, there are a few details of this issue that I do not have a good enough understanding of.
+
+One, a ``git annex get`` debug output still looks fishy, because it seems that even though file retrieval via ``rsync`` succeeds, git-annex reports a failure (datalad does not bubble this failure up, so ``datalad get`` reports success)
+
+```
+adina@cpu10 in ~/test39 on git:cleaned_epochs_from_first_stimulus
+❱ git annex --debug get sub-001/meg/sub-001_task-memento_proc-sss_meg.fif
+[2021-06-30 17:33:49.728477371] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2021-06-30 17:33:49.731865736] process done ExitSuccess
+[2021-06-30 17:33:49.731981718] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/cleaned_epochs_from_first_stimulus\"]
+[2021-06-30 17:33:49.740968815] process done ExitSuccess
+[2021-06-30 17:33:49.741741152] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"sub-001/meg/sub-001_task-memento_proc-sss_meg.fif\"]
+[2021-06-30 17:33:49.744215456] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2021-06-30 17:33:49.744686577] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+get sub-001/meg/sub-001_task-memento_proc-sss_meg.fif [2021-06-30 17:33:49.752044898] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2021-06-30 17:33:49.75626739] process done ExitSuccess
+[2021-06-30 17:33:49.756560297] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2021-06-30 17:33:49.761823592] process done ExitSuccess
+[2021-06-30 17:33:49.762766313] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..92f8b4701dc825ce433f6be042be281ffe12326b\",\"--pretty=%H\",\"-n1\"]
+[2021-06-30 17:33:49.771567205] process done ExitSuccess
+[2021-06-30 17:33:49.78138944] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2021-06-30 17:33:49.782178708] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2021-06-30 17:33:49.789209722] read: git [\"config\",\"--null\",\"--list\"]
+[2021-06-30 17:33:49.793189149] process done ExitSuccess
+(from origin...) 
+[2021-06-30 17:33:49.812118624] read: cp [\"--reflink=always\",\"--preserve=timestamps\",\"../../../data/project/brainpeach/memento-sss/.git/annex/objects/gX/13/MD5E-s2145810666--6dc9f68f36918eb0d4e2522ac0a3ec5a.fif/MD5E-s2145810666--6dc9f68f36918eb0d4e2522ac0a3ec5a.fif\",\".git/annex/tmp/MD5E-s2145810666--6dc9f68f36918eb0d4e2522ac0a3ec5a.fif\"]
+[2021-06-30 17:33:49.814419614] process done ExitFailure 1
+[2021-06-30 17:33:49.814802862] read: rsync [\"--progress\",\"--inplace\",\"--perms\",\"../../../data/project/brainpeach/memento-sss/.git/annex/objects/gX/13/MD5E-s2145810666--6dc9f68f36918eb0d4e2522ac0a3ec5a.fif/MD5E-s2145810666--6dc9f68f36918eb0d4e2522ac0a3ec5a.fif\",\".git/annex/tmp/MD5E-s2145810666--6dc9f68f36918eb0d4e2522ac0a3ec5a.fif\"]
+100%  1.1 GiB         324 MiB/s 0s[2021-06-30 17:33:57.881996659] process done ExitSuccess
+(from origin...)                  
+[2021-06-30 17:33:57.891459866] read: rsync [\"--progress\",\"--inplace\",\"--perms\",\"../../../data/project/brainpeach/memento-sss/.git/annex/objects/gX/13/MD5E-s2145810666--6dc9f68f36918eb0d4e2522ac0a3ec5a.fif/MD5E-s2145810666--6dc9f68f36918eb0d4e2522ac0a3ec5a.fif\",\".git/annex/tmp/MD5E-s2145810666--6dc9f68f36918eb0d4e2522ac0a3ec5a.fif\"]
+100%  1.1 GiB         304 MiB/s 0s[2021-06-30 17:34:04.814109593] process done ExitSuccess
+                                  
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+  	43d8b7cc-0a36-4b30-b275-5b1b4b3ecdb9 -- adina@cpu10:/tmp/ds
+   	925547b2-8ee7-4856-be15-a247e762eb56 -- adina@juseless:/data/project/brainpeach/memento-sss [origin]
+failed
+[2021-06-30 17:34:04.823873316] process done ExitSuccess
+[2021-06-30 17:34:04.824383708] process done ExitSuccess
+[2021-06-30 17:34:04.824748416] process done ExitSuccess
+[2021-06-30 17:34:04.825197456] process done ExitSuccess
+git-annex: get: 1 failed
+
+```
+
+Second, this issue doesn't affect all files, and I haven't been able to create a reproducer yet. The issue has surfaced for us in distributed workflows where compute nodes of a cluster perform jobs, and push their results back to origin (that's why a second location of the file in my output exists at cpu10 - its the node it has originally been created on before it was pushed to origin). It does not affect files that haven't been created in a distributed fashion but lie right next to the files where file retrieval fails. Here is the debug output from retrieving different data from a different dataset in the same fashion:
+
+```
+adina@juseless in ~/scratch/memento-bids on git:master
+❱ git annex --debug get sub-001/meg/sub-001_acq-crosstalk_meg.fif
+
+[2021-06-30 18:05:39.354458024] process [3120711] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2021-06-30 18:05:39.357027239] process [3120711] done ExitSuccess
+[2021-06-30 18:05:39.357334809] process [3120712] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2021-06-30 18:05:39.369392179] process [3120712] done ExitSuccess
+[2021-06-30 18:05:39.370684287] process [3120713] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--stage\",\"-z\",\"--\",\"sub-001/meg/sub-001_acq-crosstalk_meg.fif\"]
+[2021-06-30 18:05:39.371346376] process [3120714] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+[2021-06-30 18:05:39.372152014] process [3120715] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+[2021-06-30 18:05:39.374255541] process [3120716] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+get sub-001/meg/sub-001_acq-crosstalk_meg.fif [2021-06-30 18:05:39.379270343] process [3120717] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2021-06-30 18:05:39.381834378] process [3120717] done ExitSuccess
+[2021-06-30 18:05:39.382109258] process [3120718] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2021-06-30 18:05:39.384463794] process [3120718] done ExitSuccess
+[2021-06-30 18:05:39.385120813] process [3120719] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..610e016c34619c5df9b81e35a3bef749c0a556f9\",\"--pretty=%H\",\"-n1\"]
+[2021-06-30 18:05:39.388050878] process [3120719] done ExitSuccess
+[2021-06-30 18:05:39.39918469] process [3120720] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2021-06-30 18:05:39.399882519] process [3120721] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2021-06-30 18:05:39.402873194] process [3120722] read: git [\"config\",\"--null\",\"--list\"]
+[2021-06-30 18:05:39.406106719] process [3120722] done ExitSuccess
+(from origin...) 
+[2021-06-30 18:05:39.438294596] process [3120724] read: cp [\"--reflink=always\",\"--preserve=timestamps\",\"/data/project/brainpeach/memento-bids/.git/annex/objects/J2/X9/MD5E-s27253--1549e4884af4cee94b94bf9a9345d3c5.fif/MD5E-s27253--1549e4884af4cee94b94bf9a9345d3c5.fif\",\".git/annex/tmp/MD5E-s27253--1549e4884af4cee94b94bf9a9345d3c5.fif\"]
+[2021-06-30 18:05:39.442899098] process [3120724] done ExitFailure 1
+[2021-06-30 18:05:39.450760045] process [3120720] done ExitSuccess
+[2021-06-30 18:05:39.451298664] process [3120721] done ExitSuccess
+[2021-06-30 18:05:39.456210596] process [3120725] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"filter.annex.smudge=\",\"-c\",\"filter.annex.clean=\",\"-c\",\"diff.external=\",\"diff\",\"--cached\",\"--raw\",\"-z\",\"--no-abbrev\",\"-G^/annex/objects/\",\"--diff-filter=AMUT\",\"--no-renames\",\"--ignore-submodules=all\",\"--no-ext-diff\"]
+[2021-06-30 18:05:39.459241931] process [3120725] done ExitSuccess
+[2021-06-30 18:05:39.465299851] process [3120726] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2021-06-30 18:05:39.46620159] process [3120727] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+ok
+[2021-06-30 18:05:39.483714491] process [3120726] done ExitSuccess
+[2021-06-30 18:05:39.48414226] process [3120727] done ExitSuccess
+[2021-06-30 18:05:39.48431099] process [3120716] done ExitSuccess
+[2021-06-30 18:05:39.4844599] process [3120715] done ExitSuccess
+[2021-06-30 18:05:39.48457984] process [3120714] done ExitSuccess
+[2021-06-30 18:05:39.484681599] process [3120713] done ExitSuccess
+[2021-06-30 18:05:39.49057526] process [3120728] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2021-06-30 18:05:39.491780998] process [3120729] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+[2021-06-30 18:05:39.497171329] process [3120729] done ExitSuccess
+[2021-06-30 18:05:39.497947118] process [3120730] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2021-06-30 18:05:39.501412142] process [3120730] done ExitSuccess
+(recording state in git...)
+[2021-06-30 18:05:39.502305251] process [3120731] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2021-06-30 18:05:39.532505381] process [3120731] done ExitSuccess
+[2021-06-30 18:05:39.53302693] process [3120732] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"1883f43ee06ac4d945e2ed4e4f59757ef63a9ae9\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"]
+[2021-06-30 18:05:39.538093292] process [3120732] done ExitSuccess
+[2021-06-30 18:05:39.538544301] process [3120733] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"cd11614c4d5b90afd36dc10973e52c41c24f1afb\"]
+[2021-06-30 18:05:39.544866951] process [3120733] done ExitSuccess
+[2021-06-30 18:05:39.554490845] process [3120734] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2021-06-30 18:05:39.555648263] process [3120735] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2021-06-30 18:05:39.565458357] process [3120734] done ExitSuccess
+[2021-06-30 18:05:39.565876866] process [3120735] done ExitSuccess
+[2021-06-30 18:05:39.566606815] process [3120728] done ExitSuccess
+
+```
+
+And finally, I am able to clone the first repository to my local computer (git-annex 8.20210223), and file retrieval via SSH works fine.
+
+I'll continue to try to create a reproducer, but maybe somebody has an idea based on what I have posted already. Sorry for the convoluted and complex issue description!
+"""]]
diff --git a/doc/forum/get_fails/comment_6_35174be903f055adf06af2fcdef807e3._comment b/doc/forum/get_fails/comment_6_35174be903f055adf06af2fcdef807e3._comment
new file mode 100644
index 0000000000..23d2f5bb14
--- /dev/null
+++ b/doc/forum/get_fails/comment_6_35174be903f055adf06af2fcdef807e3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-07-01T16:33:35Z"
+ content="""
+There is a bug report that looks very similar to what is being reported
+here, in particular the doubled "failed to retrieve" with no other
+information: <https://git-annex.branchable.com/bugs/__34__failed_to_send_content_to_remote__34__/>
+
+The most recent git-annex release adds some additional error messages in
+some cases that could be the reason for the failure. The fact that rsync
+succeeds and then the get fails suggests rather strongly that git-annex
+thinks the file got modified while rsync was running -- which the new
+version will display an informative message about.
+
+(Please do not use this forum for bug reports; it is not an effective BTS
+since nothing ever gets closed.)
+"""]]
diff --git a/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote.mdwn b/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote.mdwn
new file mode 100644
index 0000000000..cc9091ae5b
--- /dev/null
+++ b/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote.mdwn
@@ -0,0 +1,11 @@
+I'm not sure if this is my stupidity or if it's a bug, but
+
+    git annex copy --force --to REMOTE . 
+
+just zip's through really quickly and doesn't actually force a copy to a
+remote location. This is just following up on the
+[[bugs/git-annex_directory_hashing_problems_on_osx]]. I want to just do a force copy of all my data to my portable disk to really make sure that the data is really there. I would similarly would want to make sure I can force a 
+
+    git annex copy --force --from REMOTE .
+
+to pull down files from a remote.
diff --git a/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote/comment_1_3deb2c31cad37a49896f00d600253ee3._comment b/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote/comment_1_3deb2c31cad37a49896f00d600253ee3._comment
new file mode 100644
index 0000000000..d2692f26f0
--- /dev/null
+++ b/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote/comment_1_3deb2c31cad37a49896f00d600253ee3._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-04-03T16:49:01Z"
+ content="""
+How remote is REMOTE? If it's a directory on the same computer, then git-annex copy --to is actually quickly checking that each file is present on the remote, and when it is, skipping copying it again.
+
+If the remote is ssh, git-annex copy talks to the remote to see if it has the file. This makes copy --to slow, as Rich [[complained_before|forum/batch_check_on_remote_when_using_copy]]. :)
+
+So, copy --to does not trust location tracking information (unless --fast is specified), which means that it should be doing exactly what you want it to do in your situation -- transferring every file that is really not present in the destination repository already.
+
+Neither does copy --from, by the way. It always checks if each file is present in the current repository's annex before trying to download it.
+"""]]
diff --git a/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote/comment_2_627f54d158d3ca4b72e45b4da70ff5cd._comment b/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote/comment_2_627f54d158d3ca4b72e45b4da70ff5cd._comment
new file mode 100644
index 0000000000..1079303197
--- /dev/null
+++ b/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote/comment_2_627f54d158d3ca4b72e45b4da70ff5cd._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2011-04-03T16:59:47Z"
+ content="""
+Remote as in \"another physical machine\". I assumed that
+
+    git annex copy --force --to REMOTE .
+
+would have not trusted the contents in the current directory (or the remote that is being copied to) and then just go off and re-download/upload all the files and overwrite what is already there. I expected the combination of *--force* and copy *--to* that it would not bother to check if the files are there or not and just copy it regardless of the outcome.
+"""]]
diff --git a/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote/comment_3_3f49dab11aae5df0c4eb5e4b8d741379._comment b/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote/comment_3_3f49dab11aae5df0c4eb5e4b8d741379._comment
new file mode 100644
index 0000000000..c3df214988
--- /dev/null
+++ b/doc/forum/getting_git_annex_to_do_a_force_copy_to_a_remote/comment_3_3f49dab11aae5df0c4eb5e4b8d741379._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 3"
+ date="2011-04-03T17:12:35Z"
+ content="""
+On second thought maybe the current behaviour is better than what I am suggesting that the force command should do. I guess it's better to be safe than sorry.
+"""]]
diff --git a/doc/forum/ghost_semitrusted_repositories.mdwn b/doc/forum/ghost_semitrusted_repositories.mdwn
new file mode 100644
index 0000000000..9e00178b75
--- /dev/null
+++ b/doc/forum/ghost_semitrusted_repositories.mdwn
@@ -0,0 +1,28 @@
+I had one repo on HDD and another in an USB drive. After mount point changed, I went to the HDD repo folder and tried to use git remote-set url to point it to the new location, however I think I ended in a weird state. git-annex info shows this:
+
+    git-annex info
+    repository mode: indirect
+    trusted repositories: 0
+    semitrusted repositories: 5
+        00000000-0000-0000-0000-000000000001 -- web
+        26c0c4ba-6489-4416-a054-670d373f09bd -- juan@invasor.local:/Volumes/sapo_hfs/live/papers
+        61158820-db14-45b9-b9f9-8619d956388e -- [usb_papers]
+        d4456c86-fa2b-43a7-a132-027915390cf6 -- usb_papers
+        fed56814-08c6-11e3-bf3c-af5da9f7f388 -- sapo [here]
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: 255.46 gigabytes (+1 megabyte reserved)
+    local annex keys: 1252
+    local annex size: 2.55 gigabytes
+    annexed files in working tree: 1297
+    size of annexed files in working tree: 2.7 gigabytes
+    bloom filter size: 16 mebibytes (0.3% full)
+    backend usage: 
+        SHA256E: 2549
+
+usb_papers was the original usb repo, and now a new one [usb_papers] shows. webapp shows only sapo[here] and [usb_papers], the other 2 repos are unknown. I was digging around but couldn't find a way to remove them.
+Seems that the webapp managed to use the new URL, but said something about "fixing repo".
+Any suggestions?
+Thanks in advance.
+Best regards,
+              Juan
diff --git a/doc/forum/ghost_semitrusted_repositories/comment_1_99bea1a964da9c5603b8cfbdc19bcde8._comment b/doc/forum/ghost_semitrusted_repositories/comment_1_99bea1a964da9c5603b8cfbdc19bcde8._comment
new file mode 100644
index 0000000000..ced8645e28
--- /dev/null
+++ b/doc/forum/ghost_semitrusted_repositories/comment_1_99bea1a964da9c5603b8cfbdc19bcde8._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-11T19:40:32Z"
+ content="""
+    61158820-db14-45b9-b9f9-8619d956388e -- [usb_papers]
+
+This is the git remote you currently have set up.
+
+    d4456c86-fa2b-43a7-a132-027915390cf6 -- usb_papers
+
+This is the old remote from before.
+
+Take a look at the repository in the USB drive, and see what its annex.uuid is set to. git-annex doesn't change the UUID after a repository is set up, so the fact that you have two different UUIDs is puzzling. 
+
+If you really wanted to, you could remove the old repository from the list by running: `git annex dead d4456c86-fa2b-43a7-a132-027915390cf6`  
+But I would want to get to the bottom of what happened before doing that.
+"""]]
diff --git a/doc/forum/ghost_semitrusted_repositories/comment_2_fe5fe5539d06c6b1ef69f3ed805f1ab4._comment b/doc/forum/ghost_semitrusted_repositories/comment_2_fe5fe5539d06c6b1ef69f3ed805f1ab4._comment
new file mode 100644
index 0000000000..931783a0e1
--- /dev/null
+++ b/doc/forum/ghost_semitrusted_repositories/comment_2_fe5fe5539d06c6b1ef69f3ed805f1ab4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmTNrhkVQ26GBLaLD5-zNuEiR8syTj4mI8"
+ nickname="Juan"
+ subject="web remote"
+ date="2014-07-15T13:19:42Z"
+ content="""
+Ok. Got it. And what's up with the web remote? Why is it there, I didn't add that one.
+"""]]
diff --git a/doc/forum/ghost_semitrusted_repositories/comment_3_588325ef52c80cfc67d1dd80a9d5bd13._comment b/doc/forum/ghost_semitrusted_repositories/comment_3_588325ef52c80cfc67d1dd80a9d5bd13._comment
new file mode 100644
index 0000000000..1cdceff0d5
--- /dev/null
+++ b/doc/forum/ghost_semitrusted_repositories/comment_3_588325ef52c80cfc67d1dd80a9d5bd13._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 3"
+ date="2014-07-15T18:56:31Z"
+ content="""
+It's there to represent the world wide web when using eg, `git annex addurl`
+"""]]
diff --git a/doc/forum/git-annes_assistant_+_MAC_OSX_questions.mdwn b/doc/forum/git-annes_assistant_+_MAC_OSX_questions.mdwn
new file mode 100644
index 0000000000..d32e01a6e6
--- /dev/null
+++ b/doc/forum/git-annes_assistant_+_MAC_OSX_questions.mdwn
@@ -0,0 +1,16 @@
+After spending the whole last night playing with it, I think I have it figured out:
+
+it runs on my Macbook and I have added a free 50GB box.com account as archive and an S3 bucket as full-backup and set the min. number of file occurrences to keep to 2 so IF I delete anything on my Macbook, this should make sure I definitely have 2 more occurrences of each file on two separate storages.
+
+BUT here come the problems/questions
+
+- say I add a folder called: Documents, it has now apparently successfully synced to box.com and S3. I say apparently because there is no tool in the assistant to check
+- I can't seem to figure out how to delete the log of the assistant, its getting quite longish
+- I can't seem to figure out how to upgrade from 5.20140420 to 5.20140421
+- I move a file from a local repo to the archive folder but nothing happens except git-annex recording the move: (Recording state in git...)  /Users/ovi/Sharing/git-annex/Finance/1-564 Erkl. z. Gebiets- u. Steuereigenschaft 08_04.pdf still has writers, not adding [2014-05-09 17:22:43 SAST] Committer: Committing changes to git
+- the assistant doesn'T have any kind of gui for retrieving/deleting/finding stuff - I'm no stranger to the command line but I can't figure out how to add the /Applications/gitannex.app.5.20140421/Contents/MacOS to my path and if I go there and run runshell, most git-annex commands tell me: not in a git repository so all I can do right now, is look at things :-/
+- reading the description on the kickstarter page I must say I expected more. This is in no way comparable to Dropbox. 
+
+Don't get me wrong, this is the most promising project of its kind I came across if I can be pointed in the right direction :-)
+
+P.S. How does it work on the "inside"? i.e. I edit a file and git-annex picks it up and "syncs" - what is synced? The whole file? A diff? How can one restore older versions or even look to see what versions are available?
diff --git a/doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_1_e661f31acd08a6459842f7f95e5c062b._comment b/doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_1_e661f31acd08a6459842f7f95e5c062b._comment
new file mode 100644
index 0000000000..9b524ea3b7
--- /dev/null
+++ b/doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_1_e661f31acd08a6459842f7f95e5c062b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="partially solved"
+ date="2014-05-11T09:32:32Z"
+ content="""
+I managed to add the path and now I can use git annex command line.
+All my other questions and remarks are still open though :-)
+"""]]
diff --git a/doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_2_e71a9d1fcf1f945fec0b7834b6038e91._comment b/doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_2_e71a9d1fcf1f945fec0b7834b6038e91._comment
new file mode 100644
index 0000000000..d11f641a60
--- /dev/null
+++ b/doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_2_e71a9d1fcf1f945fec0b7834b6038e91._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkYmMFDdf3GJ9Oba6NCVkzGc4JyB9WavMs"
+ nickname="Xinruo"
+ subject="comment 2"
+ date="2014-05-11T15:15:50Z"
+ content="""
+> say I add a folder called: Documents, it has now apparently successfully synced to box.com and S3. I say apparently because there is no tool in the assistant to check
+
+From the command line, git annex whereis FILE will tell you which remotes have the file, or git annex list will list out this for a directory
+
+> I can't seem to figure out how to delete the log of the assistant, its getting quite longish
+
+They live in .git/annex/daemon.log*
+
+> I can't seem to figure out how to upgrade from 5.20140420 to 5.20140421
+
+> I move a file from a local repo to the archive folder but nothing happens except git-annex recording the move: (Recording state in git...) /Users/ovi/Sharing/git-annex/Finance/1-564 Erkl. z. Gebiets- u. Steuereigenschaft 08_04.pdf still has writers, not adding [2014-05-09 17:22:43 SAST] Committer: Committing changes to git
+
+It says the pdf still has writers.. Maybe the file is locked by another program? In this case the file is not going to be annexed, I believe, until the lock is revoked.
+
+"""]]
diff --git a/doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_3_372d9da8295d093b8b316f0a48b60ee1._comment b/doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_3_372d9da8295d093b8b316f0a48b60ee1._comment
new file mode 100644
index 0000000000..93f9ef414b
--- /dev/null
+++ b/doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_3_372d9da8295d093b8b316f0a48b60ee1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="comment 3"
+ date="2014-05-12T11:03:59Z"
+ content="""
+So basically, I need to check the log for a specific commit and then restore that one?
+No way to list i.e. all commits for a folder and restore the whole folder?
+Or list all commits for a fiel and then restore that one?
+
+Still learning all of this, any hints welcome.
+"""]]
diff --git a/doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_4_573537a49e082515bfb1be84c91b5d1b._comment b/doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_4_573537a49e082515bfb1be84c91b5d1b._comment
new file mode 100644
index 0000000000..01aac51119
--- /dev/null
+++ b/doc/forum/git-annes_assistant_+_MAC_OSX_questions/comment_4_573537a49e082515bfb1be84c91b5d1b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="comment 4"
+ date="2014-06-21T13:03:11Z"
+ content="""
+Any feedback on my last questions? 
+Is there a road map somewhere? Need to figure out if this is going somewhere soon or if I should look for another solution? 
+Any other kickstarter campaigns you're planning? Wouldn't mind chipping in if it means this goes somewhere fast(er) ;-)
+"""]]
diff --git a/doc/forum/git-annex-addunused_with_original_path+filename.mdwn b/doc/forum/git-annex-addunused_with_original_path+filename.mdwn
new file mode 100644
index 0000000000..351f194f75
--- /dev/null
+++ b/doc/forum/git-annex-addunused_with_original_path+filename.mdwn
@@ -0,0 +1,11 @@
+I lost/misplaced some files on two disks (about 5000+7000 files), which are now showing up as unused files.
+
+"git annex whereused --historical --unused" shows the original paths and filenames. 
+these are however not retained when restoring via "git-annex-addunused"
+
+Is there a way/option to restore these to the original paths + filenames?
+I don't see myself renaming all these files manually...*
+
+\* I have a backup, but that leaves a small window for dataloss as the disks are full, so I must dropunused first. So I would prefer a addunused if possible (will also be faster I presume).
+
+Thanks
diff --git a/doc/forum/git-annex-addunused_with_original_path+filename/comment_1_b24b20d6351d0373f9517438c33f05c1._comment b/doc/forum/git-annex-addunused_with_original_path+filename/comment_1_b24b20d6351d0373f9517438c33f05c1._comment
new file mode 100644
index 0000000000..7fce7dcc2d
--- /dev/null
+++ b/doc/forum/git-annex-addunused_with_original_path+filename/comment_1_b24b20d6351d0373f9517438c33f05c1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-06-13T17:06:21Z"
+ content="""
+There is not currently an easy way to do that. Although I suppose you could
+write a script to rename the files based on the filenames whereused
+outputs.
+
+I do think this would be a good enhancement. I've made a todo
+[[todo/git-annex-addunused-historical]].
+"""]]
diff --git a/doc/forum/git-annex-addunused_with_original_path+filename/comment_2_cddedfd83ee154f44b83f2414eb103d0._comment b/doc/forum/git-annex-addunused_with_original_path+filename/comment_2_cddedfd83ee154f44b83f2414eb103d0._comment
new file mode 100644
index 0000000000..479c354206
--- /dev/null
+++ b/doc/forum/git-annex-addunused_with_original_path+filename/comment_2_cddedfd83ee154f44b83f2414eb103d0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="KachoOji"
+ avatar="http://cdn.libravatar.org/avatar/ccc61e285ed2498e328a131b13cfe712"
+ subject="comment 2"
+ date="2022-06-14T15:32:48Z"
+ content="""
+Ok, thank you.
+"""]]
diff --git a/doc/forum/git-annex-import_questions.mdwn b/doc/forum/git-annex-import_questions.mdwn
new file mode 100644
index 0000000000..25603d044d
--- /dev/null
+++ b/doc/forum/git-annex-import_questions.mdwn
@@ -0,0 +1,2 @@
+Some questions about git-annex-import: (1) To where in the repository, exactly, are the files imported?  The manpage does not seem to specify.  What happens if two files with same basenames but different contents are imported from different paths -- where in the repository do they go?  (2) There is no --batch option; would that be hard to add? (3) Is there a way to import a file into the annex only, without creating a symlink to it from the working copy? (4) When you import a directory, does this recursively import the full tree under it?  Also, just to note, the command name may be confusing to users, because (5) it deletes the original files by default, which most import commands do not do, and (6) it is unrelated to git-annex-export.
+Thanks!
diff --git a/doc/forum/git-annex-import_questions/comment_1_e353e5ae20ba379c42fb39825c57147e._comment b/doc/forum/git-annex-import_questions/comment_1_e353e5ae20ba379c42fb39825c57147e._comment
new file mode 100644
index 0000000000..a88872d475
--- /dev/null
+++ b/doc/forum/git-annex-import_questions/comment_1_e353e5ae20ba379c42fb39825c57147e._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2019-01-01T19:36:35Z"
+ content="""
+ * files are imported recursively into the directory you call `git-annex import` from
+ * What happens if two files with same basenames but different contents are imported from different paths: git-annex will skip importing these files unless you specify --force
+ * When you import a directory, does this recursively import the full tree under it?: yes
+ * Also, just to note, the command name may be confusing to users, because (5) it deletes the original files by default, which most import commands do not do: see discussion here: <http://git-annex.branchable.com/bugs/Importing__95__Commands__95__Destructive__95__by__95__default/>
+ * it is unrelated to git-annex-export: the intent is for it to eventually be related to export, see TODO here: <http://git-annex.branchable.com/todo/import_tree/>
+
+And I don't know about your `--batch` question.
+
+With your `import a file into the annex only, without creating a symlink to it from the working copy` question:
+
+You could do:
+
+    git annex calckey path-of-file-not-in-repo
+    git annex setkey key-from-previous-command path-of-file-not-in-repo
+
+But perhaps if this is generally useful there could be a `git annex reinject --unknown` command added to git-annex, or a `--import-keys-only` command added to `import`.
+"""]]
diff --git a/doc/forum/git-annex-repair_not_able_to_see_external_remotes.mdwn b/doc/forum/git-annex-repair_not_able_to_see_external_remotes.mdwn
new file mode 100644
index 0000000000..dc053e69b2
--- /dev/null
+++ b/doc/forum/git-annex-repair_not_able_to_see_external_remotes.mdwn
@@ -0,0 +1,9 @@
+Hi everybody,
+
+I have an annex repository on an external hard drive. The repository has been corrupted, I think because the hard drive was disconnected when I was syncing the repo. In any case, I have tried fixing it with git-annex-repair. However, the error messages complain about not being able to read from the remote respositories, even when they are available.
+
+One possible issue is that I am trying to repair the hard drive from a different computer than it normally runs on. This means that I had to change the URLs for the remotes before running git-annex-repair. They are now what they should be on the current computer but, like I said, they are not recognized when I run git-annex-repair.
+
+Any thoughts on how to solve this issue? I really appreciate any help. Please let me know if there is more information you need from me.
+
+Thanks very much.
diff --git a/doc/forum/git-annex-repair_not_able_to_see_external_remotes/comment_1_b30811d84190110b9d084e42bd4a6282._comment b/doc/forum/git-annex-repair_not_able_to_see_external_remotes/comment_1_b30811d84190110b9d084e42bd4a6282._comment
new file mode 100644
index 0000000000..ffd71c3cfc
--- /dev/null
+++ b/doc/forum/git-annex-repair_not_able_to_see_external_remotes/comment_1_b30811d84190110b9d084e42bd4a6282._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-11-01T17:41:42Z"
+ content="""
+Hard to say without the error message and a version number, but this
+sound possibly like a bug that was fixed in version 8.20210630.
+"""]]
diff --git a/doc/forum/git-annex-sync_and_git-annex-config.mdwn b/doc/forum/git-annex-sync_and_git-annex-config.mdwn
new file mode 100644
index 0000000000..28419e8081
--- /dev/null
+++ b/doc/forum/git-annex-sync_and_git-annex-config.mdwn
@@ -0,0 +1 @@
+How does [[git-annex-sync]] interact with [[git-annex-config]] settings?  Does the latest-in-time setting silently take over?
diff --git a/doc/forum/git-annex-sync_and_git-annex-config/comment_1_1372a7d54e7ef017cc4fa34358c122e0._comment b/doc/forum/git-annex-sync_and_git-annex-config/comment_1_1372a7d54e7ef017cc4fa34358c122e0._comment
new file mode 100644
index 0000000000..58147d8146
--- /dev/null
+++ b/doc/forum/git-annex-sync_and_git-annex-config/comment_1_1372a7d54e7ef017cc4fa34358c122e0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-26T17:30:24Z"
+ content="""
+If you're asking about how changes to git-annex config or conflicting
+values being set in different places work, the most recent set value wins.
+"""]]
diff --git a/doc/forum/git-annex-sync_and_git-annex-config/comment_2_dd5cd6f18b3d0d9cf6ad97181fcbf4b1._comment b/doc/forum/git-annex-sync_and_git-annex-config/comment_2_dd5cd6f18b3d0d9cf6ad97181fcbf4b1._comment
new file mode 100644
index 0000000000..0b176677e4
--- /dev/null
+++ b/doc/forum/git-annex-sync_and_git-annex-config/comment_2_dd5cd6f18b3d0d9cf6ad97181fcbf4b1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="conflicting git-annex-config values"
+ date="2021-03-26T19:27:02Z"
+ content="""
+I guess I was wondering if that could lead to some surprises, e.g. if someone changes `annex.largefiles` and this propagates to other users without them realizing.  E.g. I'd want [`annex.gitaddtoannex` and `annex.supportunlocked` added as `git-annex-config` settings](todo/additional_git-annex-config_settings__63__) so they get set when someone first clones a repo, but the prospect of someone silently changing these settings in my existing clone gives pause.
+"""]]
diff --git a/doc/forum/git-annex-sync_and_git-annex-config/comment_3_46b1ab0fcc3b9e5a974d1bf1c4d912e6._comment b/doc/forum/git-annex-sync_and_git-annex-config/comment_3_46b1ab0fcc3b9e5a974d1bf1c4d912e6._comment
new file mode 100644
index 0000000000..799352f529
--- /dev/null
+++ b/doc/forum/git-annex-sync_and_git-annex-config/comment_3_46b1ab0fcc3b9e5a974d1bf1c4d912e6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2021-03-26T21:47:38Z"
+ content="""
+Also note that:
+>These settings can be overridden on a per-repository basis using `git config`.
+"""]]
diff --git a/doc/forum/git-annex-sync_and_git-annex-config/comment_4_e4e1d59b43fc954189306de242c37dcc._comment b/doc/forum/git-annex-sync_and_git-annex-config/comment_4_e4e1d59b43fc954189306de242c37dcc._comment
new file mode 100644
index 0000000000..c1be15d9a4
--- /dev/null
+++ b/doc/forum/git-annex-sync_and_git-annex-config/comment_4_e4e1d59b43fc954189306de242c37dcc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2021-03-26T23:15:04Z"
+ content="""
+Maybe all `git-annex-config` settings should  be “only read from the git-annex branch by git annex init, and is copied to the corresponding git config setting”, like `annex.securehashesonly` already is.
+"""]]
diff --git a/doc/forum/git-annex-sync_with_bitbucket.mdwn b/doc/forum/git-annex-sync_with_bitbucket.mdwn
new file mode 100644
index 0000000000..2c1526ef9f
--- /dev/null
+++ b/doc/forum/git-annex-sync_with_bitbucket.mdwn
@@ -0,0 +1,11 @@
+When doing `git-annex-sync` with a [Bitbucket](https://bitbucket.org) repository, I get the errors:
+
+>(master_env_v17) /web/personal/ilya > git annex sync
+>
+>Failed to get annex.uuid configuration of repository origin
+>
+>Instead, got: "logged in as notestaff\n\nYou can use git or hg to connect to Bitbucket. Shell access is disabled\n"
+>
+>This is unexpected; please check the network transport!
+
+What is the right way to fix this?  Thanks!
diff --git a/doc/forum/git-annex-sync_with_bitbucket/comment_1_b95e03d119c83ac061c470801b157d55._comment b/doc/forum/git-annex-sync_with_bitbucket/comment_1_b95e03d119c83ac061c470801b157d55._comment
new file mode 100644
index 0000000000..19e092d8ea
--- /dev/null
+++ b/doc/forum/git-annex-sync_with_bitbucket/comment_1_b95e03d119c83ac061c470801b157d55._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="Set remote.<name>.annex-ignore"
+ date="2019-06-19T14:18:19Z"
+ content="""
+I think in this case you should set remote.origin.annex-ignore to true.
+"""]]
diff --git a/doc/forum/git-annex-sync_with_bitbucket/comment_2_31f7eae218447a17f316a8d13dd97ca0._comment b/doc/forum/git-annex-sync_with_bitbucket/comment_2_31f7eae218447a17f316a8d13dd97ca0._comment
new file mode 100644
index 0000000000..f16c97f2a9
--- /dev/null
+++ b/doc/forum/git-annex-sync_with_bitbucket/comment_2_31f7eae218447a17f316a8d13dd97ca0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-06-19T16:51:31Z"
+ content="""
+But I do want git-annex-sync to sync the git-annex branch with that remote.
+Normally, git-annex deals with the case of git remotes that don't support git-annex-shell without giving an error.
+"""]]
diff --git a/doc/forum/git-annex-sync_with_bitbucket/comment_3_eddbd42891a1877148a8920f19fb780e._comment b/doc/forum/git-annex-sync_with_bitbucket/comment_3_eddbd42891a1877148a8920f19fb780e._comment
new file mode 100644
index 0000000000..e97855f4fc
--- /dev/null
+++ b/doc/forum/git-annex-sync_with_bitbucket/comment_3_eddbd42891a1877148a8920f19fb780e._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="annex-ignore and syncing"
+ date="2019-06-20T02:37:26Z"
+ content="""
+> But I do want git-annex-sync to sync the git-annex branch with that remote.
+
+When annex-ignore is true, git-annex won't try to store content there, but `git annex sync` should still sync with the remote.  From the `man git-annex`
+
+    This does not prevent git-annex sync (or the git-annex assistant) from
+    syncing the git repository to the remote.
+
+Setting `annex-sync=false` on the other hand will prevent `git annex sync` from syncing the remote unless it is explicitly named.
+
+> Normally, git-annex deals with the case of git remotes that don't support git-annex-shell without giving an error.
+
+AFAIK it deals with this by automatically setting annex-ignore on failure (fetching first to make sure it is not a connectivity issue).  I don't know why the error is getting through in this case.
+"""]]
diff --git a/doc/forum/git-annex-sync_without_syncing_master.mdwn b/doc/forum/git-annex-sync_without_syncing_master.mdwn
new file mode 100644
index 0000000000..4e8f6e05fb
--- /dev/null
+++ b/doc/forum/git-annex-sync_without_syncing_master.mdwn
@@ -0,0 +1,6 @@
+How do I run git-annex-sync without syncing master?
+
+i.e.
+
+* fetch and union merge the git-annex branch from every remote listed
+* push the updated git-annex branch to every remote listed
diff --git a/doc/forum/git-annex-sync_without_syncing_master/comment_1_8ed0014e53a7ab49d76c072de074adda._comment b/doc/forum/git-annex-sync_without_syncing_master/comment_1_8ed0014e53a7ab49d76c072de074adda._comment
new file mode 100644
index 0000000000..c870f76d02
--- /dev/null
+++ b/doc/forum/git-annex-sync_without_syncing_master/comment_1_8ed0014e53a7ab49d76c072de074adda._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="Chel"
+ avatar="http://cdn.libravatar.org/avatar/a42feb5169f70b3edf7f7611f7e3640c"
+ subject="comment 1"
+ date="2020-02-03T22:36:59Z"
+ content="""
+If I am not mistaken, you need to:
+
+1) manually fetch `git-annex` from everywhere,
+
+2) not have the `synced/master` branch (or it should be an ancestor of `master`),
+
+3) use [[git-annex-merge]] or `git annex sync --no-pull --no-push` (maybe just `--no-pull` is enough),
+
+4) manually push `git-annex` back to every other repository.
+
+Other remarks:
+
+- You can use `git annex sync --cleanup` to delete all `synced/*` branches.
+- Or you can check out another branch and run `git annex sync` — it will fetch all branches, but merge only the current.
+- I don't fully understand how `synced/git-annex` works, so maybe the real answer is more complex.
+"""]]
diff --git a/doc/forum/git-annex-sync_without_syncing_master/comment_2_585648a04a02760a1f16394c00728d79._comment b/doc/forum/git-annex-sync_without_syncing_master/comment_2_585648a04a02760a1f16394c00728d79._comment
new file mode 100644
index 0000000000..4c93dd0f42
--- /dev/null
+++ b/doc/forum/git-annex-sync_without_syncing_master/comment_2_585648a04a02760a1f16394c00728d79._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="jafpoU"
+ avatar="http://cdn.libravatar.org/avatar/b1016484e481ea844c1fe42ace53e88f"
+ subject="comment 2"
+ date="2020-02-04T03:35:48Z"
+ content="""
+Thank you!
+
+Just to confirm then, `git-annex-merge` will
+
+1. union merge any ref with basename `git-annex` onto `git-annex`
+2. union merge `synced/$branch` onto `$branch` where `$branch` is the checked out branch
+
+?
+
+My goal is for all remotes to have a consistent view of where the annexed files are, without auto-merging any normal branches.
+
+Is the process you described above the easiest way to achieve this?
+"""]]
diff --git a/doc/forum/git-annex-sync_without_syncing_master/comment_3_233c20435643d2701c94a2cf30ca6483._comment b/doc/forum/git-annex-sync_without_syncing_master/comment_3_233c20435643d2701c94a2cf30ca6483._comment
new file mode 100644
index 0000000000..2b1fd79229
--- /dev/null
+++ b/doc/forum/git-annex-sync_without_syncing_master/comment_3_233c20435643d2701c94a2cf30ca6483._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="Nick_P"
+ avatar="http://cdn.libravatar.org/avatar/abf8aa3ac1a976a6a292416b9c604581"
+ subject="comment 3"
+ date="2020-02-12T10:50:06Z"
+ content="""
+Relatedly, my team is struggling to identify the process for \"add and share a file\" - e.g., add the hash to git, and copy the content to a central git-annex remote, and push the git-annex branch information that the file is now in the central remote.
+
+We used 'git annex sync' and 'git annex sync --content' for a while, but this creates the synced/ branches which introduced confusion; and it's unclear why both --content and with args are needed; and if I remember, it also committed or pushed changes we didn't want it to.
+
+Now we do like this:
+
+     git checkout features/your-new-branch
+     git annex add my-new-file
+     git commit -m \".....\"
+     git push # pushes your \"features\" branch
+     git annex copy --to SharedRemote --jobs=5 <files or folders>
+     git fetch origin git-annex:refs/remotes/origin/git-annex
+     git annex merge
+     git push origin git-annex
+
+I've read through <https://git-annex.branchable.com/walkthrough/> , <https://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/> , <https://git-annex.branchable.com/sync/>
+
+Maybe the OP has the same confusion, that there seems to be a missing git-annex-sync that does only (a) copy to a remote and (b) the git-annex branch work - Anyone able to help out direct us to how it's intended to be done?
+"""]]
diff --git a/doc/forum/git-annex-sync_without_syncing_master/comment_4_a8f681ec33f2fef16b9b8eb6633f8fe4._comment b/doc/forum/git-annex-sync_without_syncing_master/comment_4_a8f681ec33f2fef16b9b8eb6633f8fe4._comment
new file mode 100644
index 0000000000..582d294c7f
--- /dev/null
+++ b/doc/forum/git-annex-sync_without_syncing_master/comment_4_a8f681ec33f2fef16b9b8eb6633f8fe4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Nick_P"
+ avatar="http://cdn.libravatar.org/avatar/abf8aa3ac1a976a6a292416b9c604581"
+ subject="comment 4"
+ date="2020-02-18T10:15:13Z"
+ content="""
+I think the new 'git annex sync --only-annex' will replace the last three lines of my sequence above. I aim to experiment to confirm that.
+
+https://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/#comment-52dbdba2331659011519bcc4bda4cf18
+"""]]
diff --git a/doc/forum/git-annex-sync_without_syncing_master/comment_5_a125638afe0cf57fe97e6051da943406._comment b/doc/forum/git-annex-sync_without_syncing_master/comment_5_a125638afe0cf57fe97e6051da943406._comment
new file mode 100644
index 0000000000..115c9ea42d
--- /dev/null
+++ b/doc/forum/git-annex-sync_without_syncing_master/comment_5_a125638afe0cf57fe97e6051da943406._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Nick_P"
+ avatar="http://cdn.libravatar.org/avatar/abf8aa3ac1a976a6a292416b9c604581"
+ subject="comment 5"
+ date="2020-02-18T10:17:25Z"
+ content="""
+(repeat with corrected formatting)
+
+I think the new `git annex sync --only-annex` will replace the last three lines of my sequence above. I aim to experiment to confirm that.
+
+<https://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/#comment-52dbdba2331659011519bcc4bda4cf18>
+"""]]
diff --git a/doc/forum/git-annex-watch_clarification.mdwn b/doc/forum/git-annex-watch_clarification.mdwn
new file mode 100644
index 0000000000..dbf553bbb5
--- /dev/null
+++ b/doc/forum/git-annex-watch_clarification.mdwn
@@ -0,0 +1,5 @@
+How does [[git-annex-watch]] handle files that are actively being written?  The documentation says it "takes care of automatically adding new files".  Is it guaranteed to wait until a file is no longer opened for writing, before adding the file?
+
+Also, is there a way to have newly added files be automatically copied to a specified remote?
+
+Thanks!
diff --git a/doc/forum/git-annex-watch_clarification/comment_1_66de424e6d09b67cb75f6ddfef1424b2._comment b/doc/forum/git-annex-watch_clarification/comment_1_66de424e6d09b67cb75f6ddfef1424b2._comment
new file mode 100644
index 0000000000..164bca7c36
--- /dev/null
+++ b/doc/forum/git-annex-watch_clarification/comment_1_66de424e6d09b67cb75f6ddfef1424b2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-09-18T16:19:18Z"
+ content="""
+Yes, it uses lsof and other strategies to avoid that problem.
+
+The assistant handles copying files to other remotes, so use it instead of
+watch if you want that.
+"""]]
diff --git a/doc/forum/git-annex-watch_clarification/comment_2_aa709c1ee602ae3211f36cba68c155c4._comment b/doc/forum/git-annex-watch_clarification/comment_2_aa709c1ee602ae3211f36cba68c155c4._comment
new file mode 100644
index 0000000000..64991533e6
--- /dev/null
+++ b/doc/forum/git-annex-watch_clarification/comment_2_aa709c1ee602ae3211f36cba68c155c4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-09-18T20:33:04Z"
+ content="""
+\"The assistant handles copying files to other remotes, so use it instead of watch if you want that\" -- but the assistant is a GUI, right?  My use case has to run in batch mode.  I just run [[`git-annex-sync`|git-annex-sync]] periodically.  I assume it's ok to both do that and have [[`git-annex-watch`|git-annex-watch]] running in the background?
+"""]]
diff --git a/doc/forum/git-annex-watch_clarification/comment_3_db050d4b4d08100c6be204cd64ebfbf3._comment b/doc/forum/git-annex-watch_clarification/comment_3_db050d4b4d08100c6be204cd64ebfbf3._comment
new file mode 100644
index 0000000000..80a32184a5
--- /dev/null
+++ b/doc/forum/git-annex-watch_clarification/comment_3_db050d4b4d08100c6be204cd64ebfbf3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="git-annex-add on a file that is being written by some process"
+ date="2019-10-08T17:03:33Z"
+ content="""
+Does `git-annex-add` also check for actively-written files, and wait until they're no longer being written before adding them?
+
+"""]]
diff --git a/doc/forum/git-annex-watch_clarification/comment_4_7255d87f5802a8d12204e4afc797070d._comment b/doc/forum/git-annex-watch_clarification/comment_4_7255d87f5802a8d12204e4afc797070d._comment
new file mode 100644
index 0000000000..e0b511e22d
--- /dev/null
+++ b/doc/forum/git-annex-watch_clarification/comment_4_7255d87f5802a8d12204e4afc797070d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-10-08T19:33:39Z"
+ content="""
+It does not, mostly because it would need to run lsof once per file, which
+would be significantly expensive. The daemon is able to batch changes and
+so run lsof less often.
+
+However, git-annex add does detect if a file is modified while it's being
+hashed, and will avoid adding it then. And it prevents against most ways
+the file could be modified except for if something has it open for write
+beforehand. In the worst case, the object in the annex gets written to,
+which later gets detected by fsck.
+"""]]
diff --git a/doc/forum/git-annex-watch_clarification/comment_5_4a1b1176bf2499db67ffea2cce3115df._comment b/doc/forum/git-annex-watch_clarification/comment_5_4a1b1176bf2499db67ffea2cce3115df._comment
new file mode 100644
index 0000000000..63d7cd9a26
--- /dev/null
+++ b/doc/forum/git-annex-watch_clarification/comment_5_4a1b1176bf2499db67ffea2cce3115df._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-10-08T19:40:32Z"
+ content="""
+The assistant can display a gui, but it can also run headless.
+
+Anyway, it's fine to use `git annex sync` or other things that move content
+around while `git annex watch` is running.
+"""]]
diff --git a/doc/forum/git-annex-watch_clarification/comment_6_69a3377204ea4b102d9c15fb160e71b2._comment b/doc/forum/git-annex-watch_clarification/comment_6_69a3377204ea4b102d9c15fb160e71b2._comment
new file mode 100644
index 0000000000..2f2512d724
--- /dev/null
+++ b/doc/forum/git-annex-watch_clarification/comment_6_69a3377204ea4b102d9c15fb160e71b2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="preventing git-annex-add of files open for writing"
+ date="2019-10-08T20:14:41Z"
+ content="""
+\"except for if something has it open for write beforehand\" -- maybe, `git-annex-add` could do a pre-pass where it finds all files to be added, chmods them to read-only to stop new open-for-write attempts, then runs lsof once to find any existing ones?  The files could be hardlinked into one temp dir then chmod and lsof run on that dir.
+
+"""]]
diff --git a/doc/forum/git-annex_6.20170520_doesn__39__t_build_with_QuickCheck_2.10.mdwn b/doc/forum/git-annex_6.20170520_doesn__39__t_build_with_QuickCheck_2.10.mdwn
new file mode 100644
index 0000000000..ce19721034
--- /dev/null
+++ b/doc/forum/git-annex_6.20170520_doesn__39__t_build_with_QuickCheck_2.10.mdwn
@@ -0,0 +1,8 @@
+    [  9 of 561] Compiling Utility.QuickCheck ( Utility/QuickCheck.hs, dist/build/git-annex/git-annex-tmp/Utility/QuickCheck.dyn_o )
+    
+    Utility/QuickCheck.hs:38:10: error:
+        Duplicate instance declarations:
+          instance Arbitrary EpochTime
+            -- Defined at Utility/QuickCheck.hs:38:10
+          instance [safe] Arbitrary Foreign.C.Types.CTime
+            -- Defined in ‘Test.QuickCheck.Arbitrary’
diff --git a/doc/forum/git-annex_6.20170520_doesn__39__t_build_with_QuickCheck_2.10/comment_1_0e25ab25c0fa3d41336e6b7551ef9e47._comment b/doc/forum/git-annex_6.20170520_doesn__39__t_build_with_QuickCheck_2.10/comment_1_0e25ab25c0fa3d41336e6b7551ef9e47._comment
new file mode 100644
index 0000000000..00aa8e5109
--- /dev/null
+++ b/doc/forum/git-annex_6.20170520_doesn__39__t_build_with_QuickCheck_2.10/comment_1_0e25ab25c0fa3d41336e6b7551ef9e47._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~felixonmars"
+ nickname="felixonmars"
+ avatar="http://cdn.libravatar.org/avatar/17284a3bb2e4ad9d3be8fab31f49865be9c1dc22143c728de731fe800a335d38"
+ subject="comment 1"
+ date="2017-06-28T17:45:48Z"
+ content="""
+This is the same as https://git-annex.branchable.com/bugs/Build_failure__58___Utility__47__QuickCheck.hs__58__38__58__10__58___error__58___Duplicate_instance_declarations/
+
+Somehow I missed it. Sorry for the duplicated report!
+"""]]
diff --git a/doc/forum/git-annex_SSH_server_+_cloud_remote.mdwn b/doc/forum/git-annex_SSH_server_+_cloud_remote.mdwn
new file mode 100644
index 0000000000..873b75650c
--- /dev/null
+++ b/doc/forum/git-annex_SSH_server_+_cloud_remote.mdwn
@@ -0,0 +1,13 @@
+I'd like to accomplish something like this:
+
+* shared git-annex remote hosted by SSH server
+* file contents stored in S3
+* everything encrypted
+
+The use case here is to achieve the availability of an SSH server (that is, multiple clients will sync to one, main server, eliminating a dependency on each other) and a single source of truth for the repository (i.e. eliminating P2P repo synchronization), and having the bulk of the disk space consumption living on S3 hosting.
+
+Is this possible? If so, any suggestions on how to do it? I understand how to do everything, except configure the SSH server to store annexed files on S3 hosting.
+
+Also, any thoughts on how much space the SSH server's git repo (without annexed files) could possibly grow to, with average use? Is it reasonable to say that it would never get bigger than 'tens of megabytes'? 
+
+Thank you!
diff --git a/doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___.mdwn b/doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___.mdwn
new file mode 100644
index 0000000000..247407dfea
--- /dev/null
+++ b/doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___.mdwn
@@ -0,0 +1,24 @@
+Hi,
+
+I ran into this problem:
+$ git annex mirror --from origin
+git-annex: getUserEntryForID: does not exist (no such user)
+
+I found in the forum that, if the the machine uses LDAP etc. I should be able to use the HOME and USER environment variables.
+
+I'm not quite sure what the user authentication management on the machine I'm on is and I'd rather not deal with the sysadmins.
+But I know that  the /etc/passwd file does not have my user listed.
+I do have the the HOME and USER variables properly set and exported. 
+
+$ echo $HOME $USER
+/nethome/iiossifov iiossifov
+
+In the git-annex source code I found that the error occurs in Utility/UserInfo.hs. 
+I can't read Haskell but my guess is that the problem is with the myUserGecos for which there is no environment variable fall back.
+
+I'm using the pre-build git-annex version: 6.20160527-gb7d4774
+
+Would you be able to advice me how to deal with the problem?
+
+Thank you,
+Ivan
diff --git a/doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___/comment_1_94d92b7e64ad31db8837dcf3d131cf23._comment b/doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___/comment_1_94d92b7e64ad31db8837dcf3d131cf23._comment
new file mode 100644
index 0000000000..a72c67ea63
--- /dev/null
+++ b/doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___/comment_1_94d92b7e64ad31db8837dcf3d131cf23._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-06-08T17:31:41Z"
+ content="""
+IIRC it's supposed to be possible to configure a system such as LDAP 
+so that `getpwuid` queries it, instead of failing as it seems to on your
+system, using `/etc/nsswitch.conf`. But I'm not sure about that or how to
+do it and you'd need to be the admin of the system.
+
+git-annex has three calls to `getpwuid` (aka getUserEntryForID`).
+In two of them it first looks at commonly set environment variables
+(HOME and USER/LOGNAME) and only uses `getpwuid` as a fallback.
+It seems reasonable to crash when git-annex can't determine the user's home
+directory or username in code that needs it, especially since all three
+environment variables are almost always going to be set.
+
+The third use is a GECOS lookup, and here there's no corresponding
+environment variable and git-annex can deal without knowing the full name
+of the user. So, I've made that not crash if `getpwuid` fails.
+
+(There's also a little-used code path where `getpwnam` is used 
+to expand `~` in a git remote path. Seems best to leave this crashing
+too if used on a system that does not have a working `getpwnam`.)
+
+So, you can try upgrading to an autobuild that has the fix, and if it still
+crashes, check that HOME and USER are set.
+"""]]
diff --git a/doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___/comment_2_c9474c4e925948d0cabdfe7f988e1ebe._comment b/doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___/comment_2_c9474c4e925948d0cabdfe7f988e1ebe._comment
new file mode 100644
index 0000000000..4db7b992d8
--- /dev/null
+++ b/doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___/comment_2_c9474c4e925948d0cabdfe7f988e1ebe._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="ivan.iossifov@2673267f2e818d14a75f506d41738323cbc0bd04"
+ nickname="ivan.iossifov"
+ subject="how do I get the autobuild?"
+ date="2016-06-13T13:56:12Z"
+ content="""
+Hi Joy,
+
+Thanks a lot for the quick reply! It's seems that's exactly what will solve my problem.
+But, I couldn't find how to download the latest autobuilds.
+Would mind pointing me to it?
+
+Thanks again,
+Ivan
+"""]]
diff --git a/doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___/comment_3_3a9e1cb8f36a44fd1917b5fc191776a3._comment b/doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___/comment_3_3a9e1cb8f36a44fd1917b5fc191776a3._comment
new file mode 100644
index 0000000000..7071886860
--- /dev/null
+++ b/doc/forum/git-annex__58___getUserEntryForID__58___does_not_exist___40__no_such_user__41___/comment_3_3a9e1cb8f36a44fd1917b5fc191776a3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-07-19T19:09:07Z"
+ content="""
+The June 13th release of git-annex included the fix for this problem.
+
+The Windows autobuild is linked to from
+<http://git-annex.branchable.com/install/Windows/>
+"""]]
diff --git a/doc/forum/git-annex__58___map__58___1_failed.mdwn b/doc/forum/git-annex__58___map__58___1_failed.mdwn
new file mode 100644
index 0000000000..10be60ca5b
--- /dev/null
+++ b/doc/forum/git-annex__58___map__58___1_failed.mdwn
@@ -0,0 +1,12 @@
+What exactly does that mean?
+I got that while exploring the git annex command:
+
+shiny-2:git-annex ovi$ pwd
+/Users/ovi/Sharing/git-annex
+shiny-2:git-annex ovi$ git annex map
+map /Users/ovi/Sharing/git-annex ok
+
+  running: dot -Tx11 /Users/ovi/Sharing/git-annex/.git/annex/map.dot
+
+failed
+git-annex: map: 1 failed
diff --git a/doc/forum/git-annex__58___map__58___1_failed/comment_1_35ff3256e823ab8cfc53276a2123ad5f._comment b/doc/forum/git-annex__58___map__58___1_failed/comment_1_35ff3256e823ab8cfc53276a2123ad5f._comment
new file mode 100644
index 0000000000..d1beb59096
--- /dev/null
+++ b/doc/forum/git-annex__58___map__58___1_failed/comment_1_35ff3256e823ab8cfc53276a2123ad5f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-05-16T16:29:54Z"
+ content="""
+`dot` is a command from the graphviz package. Perhaps you do not have it installed.
+"""]]
diff --git a/doc/forum/git-annex__58___map__58___1_failed/comment_2_b0826073ebbd2847f4ab0d9bdba2dce5._comment b/doc/forum/git-annex__58___map__58___1_failed/comment_2_b0826073ebbd2847f4ab0d9bdba2dce5._comment
new file mode 100644
index 0000000000..b8841dd362
--- /dev/null
+++ b/doc/forum/git-annex__58___map__58___1_failed/comment_2_b0826073ebbd2847f4ab0d9bdba2dce5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="comment 2"
+ date="2014-05-16T17:21:09Z"
+ content="""
+indeed I didn't have it... was it stated somewhere that I need it?
+
+Busy installing it now... going to kill my 3g Connection :-/
+
+sudo port install graphviz
+--->  Computing dependencies for graphviz
+--->  Dependencies to be installed: autoconf m4 automake fontconfig freetype gd2 jpeg libvpx tiff xpm xorg-libXext xorg-libX11 xorg-kbproto xorg-libXau xorg-xproto xorg-libXdmcp xorg-libxcb xorg-libpthread-stubs xorg-xcb-proto xorg-xextproto xorg-libXt xorg-libsm xorg-libice gts netpbm jasper jbigkit libLASi pango Xft2 xrender xorg-renderproto cairo libpixman xorg-xcb-util gobject-introspection libtool harfbuzz graphite2 poppler curl lcms2 openjpeg15 poppler-data urw-fonts webp xorg-libXaw xorg-libXmu
+"""]]
diff --git a/doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__.mdwn b/doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__.mdwn
new file mode 100644
index 0000000000..44e7059b54
--- /dev/null
+++ b/doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__.mdwn
@@ -0,0 +1,8 @@
+Hi. I have a git-annex repo on a FAT32 file system that only replies:
+
+    git-annex: openFile: resource busy (file is locked)
+
+to most commands. Any hint as to what I could do to fix it? It is a v7 repo.
+
+git-annex version: 7.20181121
+operating system: darwin x86_64
diff --git a/doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_1_0a5894ed2c5e0b8155e69ff85741a51a._comment b/doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_1_0a5894ed2c5e0b8155e69ff85741a51a._comment
new file mode 100644
index 0000000000..b2176d1273
--- /dev/null
+++ b/doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_1_0a5894ed2c5e0b8155e69ff85741a51a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="chocolate.camera@ec2ecab153906be21ac5f36652c33786ad0e0b60"
+ nickname="chocolate.camera"
+ avatar="http://cdn.libravatar.org/avatar/4f00dfc3ad590ef7492788b854ceba78"
+ subject="comment 1"
+ date="2019-01-04T16:11:12Z"
+ content="""
+I still do not know how to fix the repo. An Internet search seems to indicate the error comes from git annex' being written in Haskell: see [A newcomer's run-in with lazy I/O](https://ianthehenry.com/2016/3/9/lazy-io/).
+"""]]
diff --git a/doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_2_85dc89b0f0ad813321b034f3fd3a83a9._comment b/doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_2_85dc89b0f0ad813321b034f3fd3a83a9._comment
new file mode 100644
index 0000000000..6a46090d22
--- /dev/null
+++ b/doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_2_85dc89b0f0ad813321b034f3fd3a83a9._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-01-22T21:12:15Z"
+ content="""
+I mean, yes, that is an error message that can occur due to some newbie
+haskell mistake, OTOH I have been writing haskell for 10 years and
+generally don't make that mistake anymore and why would it only occur on
+OSX on FAT?
+
+Also, when I do that newbie mistake on purpose, the error message I get includes the
+name of the file that it's having trouble with. It's strange that the error
+message you show did not.
+
+	joey@darkstar:~>cp /etc/passwd foo
+	joey@darkstar:~>ghci
+	GHCi, version 8.4.4: http://www.haskell.org/ghc/  :? for help
+	Loaded GHCi configuration from /home/joey/.etc/.ghci
+	ghci> readFile  "foo" >>= writeFile "foo"
+	*** Exception: foo: openFile: resource busy (file is locked)
+
+This makes me wonder if you censored the filename from the message. The lack
+of specifics about exactly which git-annex commands do this and which don't
+also does not help me in trying to think about your problem.
+
+I suggest you use dtrace or something to examine the system calls that
+git-annex is making, which should give a hint about which file it's having
+the problem with.
+"""]]
diff --git a/doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_3_4462c0640e11e20a8655743ecc78eaaa._comment b/doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_3_4462c0640e11e20a8655743ecc78eaaa._comment
new file mode 100644
index 0000000000..ae97acc298
--- /dev/null
+++ b/doc/forum/git-annex__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_3_4462c0640e11e20a8655743ecc78eaaa._comment
@@ -0,0 +1,76 @@
+[[!comment format=mdwn
+ username="ply"
+ avatar="http://cdn.libravatar.org/avatar/1270501a59ed4a4042366b00295fe236"
+ subject="comment 3"
+ date="2019-05-17T20:55:48Z"
+ content="""
+Hello, I have similar problem, but with exFAT on macOS 10.13.6. Output is not stripped, it's no filename there:
+
+```
+$ git annex info --fast --debug               
+[2019-05-17 22:42:09.997466] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2019-05-17 22:42:12.914831] process done ExitSuccess
+[2019-05-17 22:42:12.915017] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2019-05-17 22:42:12.953171] process done ExitSuccess
+[2019-05-17 22:42:12.953815] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..a0409bc558f0ed6679bf591e80f9782f1cd81da3\",\"--pretty=%H\",\"-n1\"]
+[2019-05-17 22:42:12.995305] process done ExitSuccess
+[2019-05-17 22:42:12.996023] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2019-05-17 22:42:13.014492] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2019-05-17 22:42:13.029075] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2019-05-17 22:42:13.043862] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+[2019-05-17 22:42:13.050909] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"refs/heads/git-annex\",\"--\"]
+[2019-05-17 22:42:14.066638] process done ExitSuccess
+[2019-05-17 22:42:14.08207] process done ExitSuccess
+[2019-05-17 22:42:14.090912] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+[2019-05-17 22:42:15.852868] process done ExitSuccess
+(recording state in git...)
+[2019-05-17 22:42:15.868392] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2019-05-17 22:42:17.763573] process done ExitSuccess
+[2019-05-17 22:42:17.763746] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"20ab70e8f50d62cc8d9657eaaff71cce88dfaa21\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"]
+[2019-05-17 22:42:17.800472] process done ExitSuccess
+[2019-05-17 22:42:17.800747] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"e0259808f7fbed2ce7cf0d8080dabb8d208c0da1\"]
+[2019-05-17 22:42:17.867585] process done ExitSuccess
+
+git-annex: openFile: resource busy (file is locked)
+failed
+[2019-05-17 22:42:17.870299] process done ExitSuccess
+[2019-05-17 22:42:17.875024] process done ExitSuccess
+[2019-05-17 22:42:17.886388] process done ExitSuccess
+```
+
+I tried `sudo dtruss -f git annex info --fast --debug`, and this is an excerpt from the terminal:
+
+```
+82503/0x1b0045:  write(0x2, \"[2019-05-17 22:29:55.91659] process done ExitSuccess\n\0\", 0x35)		 = 53 0
+82503/0x1b0045:  mkdir(\".git/annex\0\", 0x1FF, 0x0)		 = -1 Err#17
+82503/0x1b0045:  stat64(\".git/annex\0\", 0x4200038E40, 0x0)		 = 0 0
+82503/0x1b0045:  getpid(0x0, 0x0, 0x0)		 = 82503 0
+82503/0x1b0045:  open(\".git/annex/index.lck82503-2.tmp\0\", 0x20A06, 0x180)		 = 13 0
+82503/0x1b0045:  fstat64(0xD, 0x420004D050, 0x0)		 = 0 0
+82503/0x1b0045:  stat64(\".git/annex\0\", 0x420004D1D0, 0x0)		 = 0 0
+82503/0x1b0045:  mkdir(\".git/annex\0\", 0x1FF, 0x0)		 = -1 Err#17
+82503/0x1b0045:  stat64(\".git/annex\0\", 0x420004D3A0, 0x0)		 = 0 0
+82503/0x1b0045:  open(\".git/annex/index.lck82503-3.tmp\0\", 0x20A06, 0x180)		 = 21 0
+82503/0x1b0045:  fstat64(0x15, 0x420004D580, 0x0)		 = 0 0
+82503/0x1b0045:  close(0xC)		 = 0 0
+82503/0x1b0045:  poll(0x7FFEEC5CC810, 0x1, 0x0)		 = 1 0
+82503/0x1b0045:  write(0x1, \"\n\0\", 0x1)		 = 1 0
+82503/0x1b0045:  poll(0x7FFEEC5CC810, 0x1, 0x0)		 = 1 0
+82503/0x1b0045:  write(0x2, \"git-annex: openFile: resource busy (file is locked)\n\0\", 0x34)		 = 52 0
+```
+
+Removing `.git/annex/*.lck*` hadn't helped.
+
+I use git-annex version 7.20190322 from Homebrew:
+
+```
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV FsEvents TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.2.2 http-client-0.5.14 persistent-sqlite-2.6.4 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: darwin x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 7
+```
+"""]]
diff --git a/doc/forum/git-annex__58___unknown_response_from_git_cat-file.mdwn b/doc/forum/git-annex__58___unknown_response_from_git_cat-file.mdwn
new file mode 100644
index 0000000000..b0bc4791fb
--- /dev/null
+++ b/doc/forum/git-annex__58___unknown_response_from_git_cat-file.mdwn
@@ -0,0 +1,10 @@
+I recently upgraded my annex from version 5 to version 6. In fact, there are two sister repos, one on an NTFS partition and the other on EXT4. I am getting the following error on the EXT4 repo:
+
+    git-annex: unknown response from git cat-file ("refs/heads/git-annex:79a/279/SHA256E-s1287921--0970d35c130c8f678fe9cd74508ee9944598aa211e410c0378833afa214ab0e9.jpg missing",Ref "refs/heads/git-annex:79a/279/SHA256E-s1287921--0970d35c130c8f678fe9cd74508ee9944598aa211e410c0378833afa214ab0e9.jpg\n.log")
+    CallStack (from HasCallStack):
+      error, called at ./Git/CatFile.hs:88:28 in main:Git.CatFile
+
+
+I see this message on the EXT4 repo if I run any usual commands like "git annex get" or "git annex list".
+
+I do not have any files with newlines in their names. I may have interrupted commands like "git add" and "git annex lock", so it's difficult to say how I ended up with the above situation. The most puzzling part is that under .git/annex/objects, the EXT4 repo has only two-letter directories while the NTFS repo has only three-letter directories, and there is no .git/annex/objects/79a/279 in either.
diff --git a/doc/forum/git-annex__58___unknown_response_from_git_cat-file/comment_1_96ad30294a6f18c0f73be1136de47632._comment b/doc/forum/git-annex__58___unknown_response_from_git_cat-file/comment_1_96ad30294a6f18c0f73be1136de47632._comment
new file mode 100644
index 0000000000..b9d423c0a3
--- /dev/null
+++ b/doc/forum/git-annex__58___unknown_response_from_git_cat-file/comment_1_96ad30294a6f18c0f73be1136de47632._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-08-03T17:41:16Z"
+ content="""
+I was able to reproduce the error message when I made a git-annex symlink
+that has a newline at the end of its link target. 
+
+So, it seems you must have one in your tree. Find it with:
+
+	find -ls | grep SHA256E-s1287921--0970d35c130c8f678fe9cd7
+
+Deleting the symlink that finds and replacing it with a new symlink without
+the newline at the end of its link target should fix the problem.
+
+It would be interesting to know how this symlink came to be. If you make
+another clone of the repository, do you get the same symlink? Was the file
+originally added to the NTFS repository and the bad symlink somehow came
+from there?
+
+Also, what git-annex version was used to add the bad symlink?
+"""]]
diff --git a/doc/forum/git-annex___38___ikiwiki_experiment.mdwn b/doc/forum/git-annex___38___ikiwiki_experiment.mdwn
new file mode 100644
index 0000000000..5b426a1808
--- /dev/null
+++ b/doc/forum/git-annex___38___ikiwiki_experiment.mdwn
@@ -0,0 +1,28 @@
+Hi,
+
+I've been experimenting with combining [ikiwiki](http://ikiwiki.info) with git-annex and it seems to work. Thought I'd post my process. I've [commented](http://ikiwiki.info/todo/git-annex_support/discussion/) on the ikiwiki website as well but perhaps it'd be of interest to git-annex folks.
+
+I have very little understanding of any of the tools involved and have just attempted to make it work using my limited knowledge. I don't use the web interface for ikiwiki which simplifies things.
+
+The [website in question](http://stockholm.kalleswork.net) just went online and is currently an archive of architectural photographs and the site relies heavily on the ikiwiki osm and album plugins.
+
+### Setting things up
+
+To start with I set up the wiki on the server and git clone to into `$wrkdir` on my laptop. I then initialize a git-annex repo in the `$srcdir` on the server. Leaving the `$gitdir` untouched. The `$scrdir` git-annex repo has to be in `direct` mode. Before doing any syncing I add `annex-ignore = true` and `annex-sync = false` to `.git/config` in the origin repo (`$gitdir`): this is to prevent polluting `$gitdir` with git-annex data. The same process is repeated in the `$wrkdir` on the laptop.
+
+### Pushing and syncing
+
+With this setup I can then `git add remote $srcdir`, `git add $file` and `git-push` mdwn files and other lightweight data from the laptop. While `git annex-add`, `git-annex sync` and `git-annex copy --to $srcdir` jpg's and other heavy files. All pure git commands work as expected with ikiwiki and the website recompiles etc.
+
+### Snags
+
+I'm frequently left with (non-dangling) symlinks in the `$srcdir` despite the annex repo being in direct mode. When this happens `git-annex fsck` sorts things out.
+
+Uploading image files does require a bit of manual work. But as this is done less frequently it's not much of an issue for me. I'm guessing that by doing things it the correct order (whatever that might be) I could avoid some of the manual work.
+
+The thing to keep in mind is to never `git-add` the typechanged annexed files in the $srcdir. In general I never use git commands in the $srcdir.
+
+The main problem is the symlinks though as they demand a manual `git-annex fsck`. I have no idea what causes the symlinks in a direct mode repo.
+
+Any comments? 
+
diff --git a/doc/forum/git-annex___38___ikiwiki_experiment/comment_1_9f74449ec91577dbf6095f4beafac293._comment b/doc/forum/git-annex___38___ikiwiki_experiment/comment_1_9f74449ec91577dbf6095f4beafac293._comment
new file mode 100644
index 0000000000..332f77bcc8
--- /dev/null
+++ b/doc/forum/git-annex___38___ikiwiki_experiment/comment_1_9f74449ec91577dbf6095f4beafac293._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="how about the web interface?"
+ date="2013-09-25T11:09:58Z"
+ content="""
+I understand you do not use the web interface - but what if you did? would it commit all those files into git?
+
+Could we add the git-annex files to a .gitignore file?
+"""]]
diff --git a/doc/forum/git-annex___38___ikiwiki_experiment/comment_2_e034585c8b51cc30b35c1f7ae68205bf._comment b/doc/forum/git-annex___38___ikiwiki_experiment/comment_2_e034585c8b51cc30b35c1f7ae68205bf._comment
new file mode 100644
index 0000000000..2201813fe4
--- /dev/null
+++ b/doc/forum/git-annex___38___ikiwiki_experiment/comment_2_e034585c8b51cc30b35c1f7ae68205bf._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3HGoDpnOPob5jOjvIootmkve1-nCpRiI"
+ nickname="Kalle"
+ subject="comment 2"
+ date="2013-09-25T11:58:42Z"
+ content="""
+I have very poor understanding of what ikiwiki actually does behind the scenes including how it uses the $srcdir and $gitdir.
+
+The only way I could see the web interface working would be to use the git-annex content expressions and having the assistant running on the server. That still doesn't prevent large files from being checked into git though? That all depends on which order ikiwiki can be made to do things.
+
+I might be able to test on a local wiki but that would have to wait a while.
+
+
+"""]]
diff --git a/doc/forum/git-annex___38___ikiwiki_experiment/comment_3_fbbd47c3dbe8de24b0df664e4afd5cb8._comment b/doc/forum/git-annex___38___ikiwiki_experiment/comment_3_fbbd47c3dbe8de24b0df664e4afd5cb8._comment
new file mode 100644
index 0000000000..63919bd22d
--- /dev/null
+++ b/doc/forum/git-annex___38___ikiwiki_experiment/comment_3_fbbd47c3dbe8de24b0df664e4afd5cb8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.220"
+ subject="comment 3"
+ date="2013-09-25T17:03:29Z"
+ content="""
+Interesting experiment.
+
+I don't know why you don't want to let git-annex sync its data to $gitdir.
+
+The symlinks could be occuring because of a bug in direct mode. (I have fixed many past bugs that caused that.) But just as likely it's because ikiwiki will run `git pull` in the srcdir.
+
+I think it would make more sense to use the underlay plugin and keep your annexed repository in a separate underlay. This would guarantee ikiwiki doesn't run git commands in there, and would ensure that nothing done with the web interface could mess with the annex.
+"""]]
diff --git a/doc/forum/git-annex___38___ikiwiki_experiment/comment_4_55da5c3c41c13b08590ce1ff8117cef6._comment b/doc/forum/git-annex___38___ikiwiki_experiment/comment_4_55da5c3c41c13b08590ce1ff8117cef6._comment
new file mode 100644
index 0000000000..6299326a89
--- /dev/null
+++ b/doc/forum/git-annex___38___ikiwiki_experiment/comment_4_55da5c3c41c13b08590ce1ff8117cef6._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3HGoDpnOPob5jOjvIootmkve1-nCpRiI"
+ nickname="Kalle"
+ subject="comment 4"
+ date="2013-09-25T18:28:40Z"
+ content="""
+@Joey
+
+    > I don't know why you don't want to let git-annex sync its data to $gitdir.
+
+Well neither do I! :) It seemed to be the way to avoid duplicating data while still having the images picked up by the ikiwiki album plugin. Wouldn't the files in the $gitdir end up duplicated in $srcdir?
+
+    > The symlinks could be occuring because of a bug in direct mode. 
+    > (I have fixed many past bugs that caused that.) But just as likely
+    > it's because ikiwiki will run git pull in the srcdir.
+
+When you mention it I've had similar problems with my vfat usb annex repos. Using the post-receive merge hook to make files visible for non git-annex devices about town. Nothing I can reliably recreate but I will keep my eye out for bugs.
+
+    > I think it would make more sense to use the underlay plugin and keep 
+    > your annexed repository in a separate underlay. 
+
+Yep that would be ideal. For my usecase the album plugin is vital and I can't understand how album would pick up and deal with images in an underlay dir. This is a bit OT for this site though most of my questions are ikiwiki related.
+"""]]
diff --git a/doc/forum/git-annex___38___ikiwiki_experiment/comment_5_f67823351164ddfe7d595685c3679652._comment b/doc/forum/git-annex___38___ikiwiki_experiment/comment_5_f67823351164ddfe7d595685c3679652._comment
new file mode 100644
index 0000000000..2701bd4af1
--- /dev/null
+++ b/doc/forum/git-annex___38___ikiwiki_experiment/comment_5_f67823351164ddfe7d595685c3679652._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3HGoDpnOPob5jOjvIootmkve1-nCpRiI"
+ nickname="Kalle"
+ subject="comment 5"
+ date="2013-09-26T06:56:49Z"
+ content="""
+Turns out using the underlay was a piece of cake! Just mirror the folder structure of the repo in your underlaydir put your jpegs there and off you go. Images are picked up by the album plugin and it all just works. No need to coax git-annex into doing odd stuff.
+
+Thought I'd post this for other ikiwikers.
+"""]]
diff --git a/doc/forum/git-annex___38___ikiwiki_experiment/comment_6_d5cc91164772849d027fed5f962d9000._comment b/doc/forum/git-annex___38___ikiwiki_experiment/comment_6_d5cc91164772849d027fed5f962d9000._comment
new file mode 100644
index 0000000000..1d3abdf5de
--- /dev/null
+++ b/doc/forum/git-annex___38___ikiwiki_experiment/comment_6_d5cc91164772849d027fed5f962d9000._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="step by step?"
+ date="2013-09-26T09:40:57Z"
+ content="""
+So how does this actually work in practice? Is the underlay directory a completely disconnected repository?
+
+Can we have step by step instructions on how to set this up?
+"""]]
diff --git a/doc/forum/git-annex___38___ikiwiki_experiment/comment_7_cb4ec7ed3c39d0649133191a85ea6ab3._comment b/doc/forum/git-annex___38___ikiwiki_experiment/comment_7_cb4ec7ed3c39d0649133191a85ea6ab3._comment
new file mode 100644
index 0000000000..8e387d89a5
--- /dev/null
+++ b/doc/forum/git-annex___38___ikiwiki_experiment/comment_7_cb4ec7ed3c39d0649133191a85ea6ab3._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3HGoDpnOPob5jOjvIootmkve1-nCpRiI"
+ nickname="Kalle"
+ subject="comment 7"
+ date="2013-09-26T13:05:53Z"
+ content="""
+@anarcat
+
+    > Can we have step by step instructions on how to set this up?
+
+[I described the ikiwiki album setup](http://ikiwiki.info/forum/ikiwiki_with_album___38___underlay_plugins/) on the ikiwiki website as there are no git-annex tricks anymore. Just standard behaviour.
+
+    > So how does this actually work in practice? Is the underlay directory a 
+    > completely disconnected repository?
+
+Yes they are completely separate repos. Really the underlay dir could be managed in any way you like svn, rsync, ftp etc. I didn't expect the album plugin to pick everything up but apparently it does! Perhaps underlays are completely integrated and appear as 'normal' to all of ikiwiki?
+"""]]
diff --git a/doc/forum/git-annex___38___ikiwiki_experiment/comment_8_86565e5e1508ff1862f88975446650a2._comment b/doc/forum/git-annex___38___ikiwiki_experiment/comment_8_86565e5e1508ff1862f88975446650a2._comment
new file mode 100644
index 0000000000..473551f657
--- /dev/null
+++ b/doc/forum/git-annex___38___ikiwiki_experiment/comment_8_86565e5e1508ff1862f88975446650a2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 8"
+ date="2013-09-26T13:10:25Z"
+ content="""
+Yes, I believe that is the way the underlay works - the files are just picked up.
+
+As for the ikiwiki forum post - maybe you should move it to the \"tips\" section? :)
+
+Thanks for the documentation!!
+"""]]
diff --git a/doc/forum/git-annex_across_two_filesystems.mdwn b/doc/forum/git-annex_across_two_filesystems.mdwn
new file mode 100644
index 0000000000..1e95a793c6
--- /dev/null
+++ b/doc/forum/git-annex_across_two_filesystems.mdwn
@@ -0,0 +1,30 @@
+Hi everyone,
+
+I need some suggestions on how to operate git-annex best in my setup.
+
+I need git-annex mainly for its ability to have directories of all my data on all my nodes but not for the data redundancy it can provide.
+I have one node that contains 2 filesystems that I want to merge in one git-annex repository. One filesystem (lets call it SAFE) is on top of a RAID1 between two 1TB hds. The other (BIG) is on top of a 3TB hd. SAFE holds data I do not want to loose (like digital pictures). BIG holds data that I can loose.
+
+I do not have enough disk space on other nodes to get rid of the RAID1.
+
+This is how I mount my filesystems:
+
+SAFE at ~/AllData/
+
+BIG at ~/AllData/bigfiles/
+
+The root of the git repository is at ~/AllData/ however when I do:
+
+git-annex add ~/AllData/bigfiles/file1
+It says:
+add bigfiles/file1 failed
+
+I assume that is because of file1 being on a different filesystem.
+
+Do I have to create two repositories: one for each filesystem or do you have any ideas on how to use git-annex best in this scenario?
+Having two repositories also has the disadvantage that I need two repositories on all other nodes am I right?
+
+Thanks for you suggestions
+
+
+
diff --git a/doc/forum/git-annex_across_two_filesystems/comment_1_53167648b8b70b41d19ca662a5f3687e._comment b/doc/forum/git-annex_across_two_filesystems/comment_1_53167648b8b70b41d19ca662a5f3687e._comment
new file mode 100644
index 0000000000..cd363948ca
--- /dev/null
+++ b/doc/forum/git-annex_across_two_filesystems/comment_1_53167648b8b70b41d19ca662a5f3687e._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-22T19:48:55Z"
+ content="""
+git-annex stores the contents of files inside `.git/annex/objects`. The `git annex add` is failing because it cannot `rename()` the file into that directory, because it is on a different filesystem. Even if it did a more expensive move of the file, it would not do what you want, because all the files would be moved to the `.git/annex/objects` directory, which is stored on your smaller drive.
+
+The way git-annex is intended to be used with multiple drives is this: 
+
+* Make a separate git repository on each drive.
+* Set up git remotes connecting these repositories together. You don't have to connect them all up, but at least make
+  the git repository on your main filesystem have a remote for each git repository on other drives.
+* Use `git annex sync` to keep the git repositories in sync. (Or do it manually with `git pull`)
+* When you want a file to be available in the local repository, use `git annex get $file` to get it.
+* When your local repository is getting too full, use `git annex drop` or `git annex move` to flush files
+  out to the other drive(s).
+
+The [[walkthrough]] goes through an example of adding a removable USB drive this way, but you can do the same thing for
+non-removable drives.
+
+> Having two repositories also has the disadvantage that I need two repositories on all other nodes am I right?
+
+No -- you combine the two repositories, so any clone of either one contains all the files in both. Other notes then only need one
+repository. However, for another node to be able to get files from both repositories on this node, it will need to have two git remotes configured, one for each repository.
+"""]]
diff --git a/doc/forum/git-annex_across_two_filesystems/comment_2_39adeebc1af9c437f1fc2e00c07509bf._comment b/doc/forum/git-annex_across_two_filesystems/comment_2_39adeebc1af9c437f1fc2e00c07509bf._comment
new file mode 100644
index 0000000000..ef57bdfec3
--- /dev/null
+++ b/doc/forum/git-annex_across_two_filesystems/comment_2_39adeebc1af9c437f1fc2e00c07509bf._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://pradermecker.myopenid.com/"
+ ip="81.244.215.244"
+ subject="comment 2"
+ date="2013-04-27T17:14:43Z"
+ content="""
+It works fine. After it is set up with the client as described, sync is automatic from the Assistant.
+
+What I find cumbersome is the fact that I need to manually call \"git annex sync\" on the remote (usb or local ssh) to view (generate) the link. Is there a way to avoid this extra step ?
+
+"""]]
diff --git a/doc/forum/git-annex_across_two_filesystems/comment_3_f4e3f28db005301adeef7ccd2c9998fb._comment b/doc/forum/git-annex_across_two_filesystems/comment_3_f4e3f28db005301adeef7ccd2c9998fb._comment
new file mode 100644
index 0000000000..52a8f55654
--- /dev/null
+++ b/doc/forum/git-annex_across_two_filesystems/comment_3_f4e3f28db005301adeef7ccd2c9998fb._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmp1ThsNNAbSn46ju-gwFELfStlhl8usJo"
+ nickname="Marek"
+ subject="I should have thought of this"
+ date="2013-04-30T19:55:19Z"
+ content="""
+Thanks joey, I thought of the object storage just yesterday and that the drive where it resides needs to be the big one. 
+
+I think that I will do it as you described with one addition:
+
+I set up the git-annex repository on my big drive. Lets call that BIG.
+Then I set up another on the smaller drive (or raid) and set both to sync. Lets call that RAID.
+
+BUT: Can I use num copies to tell BIG to only sync files in certain directories to RAID. Or will syncing sync everything regardless?
+
+Thanks for your help
+
+"""]]
diff --git a/doc/forum/git-annex_across_two_filesystems/comment_4_53fa7ac6f80e3281768a7bfd3d438b34._comment b/doc/forum/git-annex_across_two_filesystems/comment_4_53fa7ac6f80e3281768a7bfd3d438b34._comment
new file mode 100644
index 0000000000..bab1a8b02c
--- /dev/null
+++ b/doc/forum/git-annex_across_two_filesystems/comment_4_53fa7ac6f80e3281768a7bfd3d438b34._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmp1ThsNNAbSn46ju-gwFELfStlhl8usJo"
+ nickname="Marek"
+ subject="Another correction"
+ date="2013-04-30T20:11:57Z"
+ content="""
+sync just syncs the meta data but not the objects itself right? I have to do an explicit git-annex copy -to or copy -from?
+
+
+"""]]
diff --git a/doc/forum/git-annex_across_two_filesystems/comment_5_2e1be54c01970ef3456e8af4aaf00cbf._comment b/doc/forum/git-annex_across_two_filesystems/comment_5_2e1be54c01970ef3456e8af4aaf00cbf._comment
new file mode 100644
index 0000000000..83644a5548
--- /dev/null
+++ b/doc/forum/git-annex_across_two_filesystems/comment_5_2e1be54c01970ef3456e8af4aaf00cbf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 5"
+ date="2013-04-30T21:57:13Z"
+ content="""
+Yes, `git annex sync` only syncs the metadata. 
+
+If you have numcopies set to to, and run `git annex copy --to RAID --auto`, it will only copy files that have less than 2 copies. (Same with `git annex copy --from BIG --auto` or `git annex get --auto`)
+"""]]
diff --git a/doc/forum/git-annex_across_two_filesystems/comment_6_aa6b153478f79c78e778865a99f01373._comment b/doc/forum/git-annex_across_two_filesystems/comment_6_aa6b153478f79c78e778865a99f01373._comment
new file mode 100644
index 0000000000..4e05541ace
--- /dev/null
+++ b/doc/forum/git-annex_across_two_filesystems/comment_6_aa6b153478f79c78e778865a99f01373._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="thomas.l.clune@39f0ca5621ddc6cbe4550be3ca9a22ec70edc9a6"
+ nickname="thomas.l.clune"
+ avatar="http://cdn.libravatar.org/avatar/31edb934c0c30a68a44617fa0eea0f8f"
+ subject="git-annex - many filesystems"
+ date="2017-01-30T14:24:11Z"
+ content="""
+I believe I understood the earlier discussion about managing git-annex across multiple file-systems, but I'm facing a more extreme case and am hoping for some useful advice.
+
+We are exploring use of git-annex to manage the large boundary conditions used within our weather model.     For the most part, this seems to be an excellent fit.   But one of our goals is to limit data duplication among end users, and here there is a problem.   Even in the era of multi-petabyte file systems, needless duplication of data s a concern.
+
+In our computing facility there are many O(10-20) filesystems from which users run our model.    If each user creates their own clone from some master repo on filesystem A, many (but by no means all) files will have multiple copies across the other filesystems.   Worse, if multiple users running on filesystem X both cloned from A, we'd have multiple copies even on X as they would not know about the other local clone.    The current ad hoc system (i.e., without git-annex)  uses symbolic links to file system A and avoids the copies, but is otherwise quite limited in terms of managing variant input files and running in other computing environments.      
+
+One halfway solution would be to have a \"master\" repo on _each_ filesystem and then ensure that users made their repos set upstream remotes to _all_ of them.    We'd still have multiple copies across filesystems, but at least there would then be at most one copy of any given file on each filesystem.
+
+The other possibility is to somehow enforce a policy that all input files are to be accessed on filesystem A.      This is what we'll probably end up doing.   We'd kludge our existing scripts that set up symbolic links to point at clones on filesystem A.
+
+I would very much like there to be another option.
+
+Thanks in advance.
+"""]]
diff --git a/doc/forum/git-annex_across_two_filesystems/comment_7_b87281c6a8b068cec60d2d5b7d015a23._comment b/doc/forum/git-annex_across_two_filesystems/comment_7_b87281c6a8b068cec60d2d5b7d015a23._comment
new file mode 100644
index 0000000000..9de9286e3a
--- /dev/null
+++ b/doc/forum/git-annex_across_two_filesystems/comment_7_b87281c6a8b068cec60d2d5b7d015a23._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2017-01-30T17:54:47Z"
+ content="""
+Hmm, this is a rather old forum thread to be reactivating, maybe a new
+thread more about your specific use case, Thomas?
+
+Your master repository idea seems like a good one. If the master
+repository is cloned with `git clone --shared` then that clone will
+hard link files between it and the master repository (assuming
+a git-annex rather newer than the start date of this forum thread!), 
+so multiple repositories will only have one copy of the file. 
+Of course, since it uses hard links, master and clone need to
+be on the same drive.
+
+There are probably ways to improve git-annex to handle this kind of use
+case better. Maybe `git clone --shared` across filesystems should
+use symlinks rather than hard links or something like that.
+That might take some time to design and implement (it changes a core
+invariant of git-annex, that .git/annex/objects/ contains files, not
+symlinks).
+
+Happy to discuss other options..
+"""]]
diff --git a/doc/forum/git-annex_add_out_of_memory_error.mdwn b/doc/forum/git-annex_add_out_of_memory_error.mdwn
new file mode 100644
index 0000000000..594427d25e
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error.mdwn
@@ -0,0 +1,38 @@
+Greetings all!
+
+I have only been using git-annex for a few days, but I am loving it so far.
+
+I have run into one problem:
+
+At the top of a directory tree with some very large (GB+) blobs, I issue this command:
+
+find . -size +5M  -exec git-annex add --debug {} \;  2>&1 | tee -a ./annex-add.log
+
+When the command completes, I see a number of these types of errors in the log:
+
+    [2015-10-05 21:14:13.502615] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+    [2015-10-05 21:14:13.521586] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+    [2015-10-05 21:14:13.533095] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--name-only","--diff-filter=T","-z","--","./application/mozilla/firefox/linux/firefox-39.0/media/firefox-39.0.tar.bz2"]
+    [2015-10-05 21:14:13.545739] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"]
+    [2015-10-05 21:14:13.562727] process done ExitSuccess
+    [2015-10-05 21:14:13.564103] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]
+    [2015-10-05 21:14:13.56616] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+    [2015-10-05 21:14:13.58032] process done ExitSuccess
+    fatal: Out of memory, getdelim failed
+    [2015-10-05 21:14:13.582109] process done ExitFailure 128
+    ok
+    (recording state in git...)
+    git-annex: user error (git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"] exited 128)
+
+I've googled around and searched the forums/bug reports here without much success.
+I have tried setting the queuesize to smaller values, but that does not seem to help.
+
+I am using git-annex version: 5.20150930-g40fdbe9 on RHEL 6.
+
+I am happy to help debug further...
+
+Thanks,
+
+JC
+
+P.S. - Is it normal that some links in the .git dir are created without user write access?
diff --git a/doc/forum/git-annex_add_out_of_memory_error/comment_10_d90d392db9a4962f9f8eb0ee95bf2914._comment b/doc/forum/git-annex_add_out_of_memory_error/comment_10_d90d392db9a4962f9f8eb0ee95bf2914._comment
new file mode 100644
index 0000000000..3aacef337a
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error/comment_10_d90d392db9a4962f9f8eb0ee95bf2914._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="relates to being on NFS"
+ date="2017-08-09T17:26:40Z"
+ content="""
+pretty sure in that 
+
+[[! format sh \"\"\"
+yhalchen@discovery:/mnt/scratch/yoh/datalad$ git pull --ff-only origin master
+fatal: Out of memory, getdelim failed
+error: git://github.com/datalad/datalad did not send all necessary objects
+
+yhalchen@discovery:/mnt/scratch/yoh/datalad$ git pull --ff-only origin master
+fatal: Out of memory, getdelim failed
+error: git://github.com/datalad/datalad did not send all necessary objects
+
+yhalchen@discovery:/mnt/scratch/yoh/datalad$ git pull --ff-only origin master
+From git://github.com/datalad/datalad
+ * branch              master     -> FETCH_HEAD
+fatal: Out of memory, getdelim failed
+
+\"\"\"]]
+"""]]
diff --git a/doc/forum/git-annex_add_out_of_memory_error/comment_11_459f810fd06aab3ddeeba8207d774dc0._comment b/doc/forum/git-annex_add_out_of_memory_error/comment_11_459f810fd06aab3ddeeba8207d774dc0._comment
new file mode 100644
index 0000000000..2907187a7b
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error/comment_11_459f810fd06aab3ddeeba8207d774dc0._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2017-08-15T18:00:42Z"
+ content="""
+Yes, I think that the git-annex-standalone.deb is potentially broken
+by mismatches between the system locales and the bundled version of glibc.
+
+The git-annex standalone tarball was designed to be unpacked by the user
+who's going to use it; having root install it is not using it as it was
+designed. If you're going to have root install something, why not have them
+install a docker container or some other container format designed to be
+installed by root, that can completely isolate the application inside it?
+
+(As to the getdelim error specifically, here's a link to the thread where
+that bug in git was tracked down and patched
+<https://public-inbox.org/git/20170810202942.s232yr5stjxmmz4t@hopa.kiewit.dartmouth.edu/>.
+I'm still not clear on how locale issues might contribute to the getdelim
+error. It seems like something before the getdelim call is failing in this
+situation for whatever reason, and that might be the actual root cause.)
+"""]]
diff --git a/doc/forum/git-annex_add_out_of_memory_error/comment_12_d7d3785b65b0608424b25056c9e3a139._comment b/doc/forum/git-annex_add_out_of_memory_error/comment_12_d7d3785b65b0608424b25056c9e3a139._comment
new file mode 100644
index 0000000000..0f5299be7a
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error/comment_12_d7d3785b65b0608424b25056c9e3a139._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="davicastro"
+ avatar="http://cdn.libravatar.org/avatar/4e708663cf4d5b9e8cfea74caf4307fc"
+ subject="Consequences of this error message"
+ date="2018-06-04T14:16:23Z"
+ content="""
+Hi, can someone comment what is the consequences when the \"fatal: Out of memory, getdelim failed\" occurs? It happened to me in some files when adding a bunch but I don't see any side effects. Git fsck and Git annex fsck are OK. git annex unused makes sense. Could this error cause a file to not be added to the repository? (I'm not using NFS file system, git annex version: 6.20180409-gfb0780266, git version: 2.14.1. It might be due to actual out of memory, I'm not sure, I'm just concerned about the side effects).
+"""]]
diff --git a/doc/forum/git-annex_add_out_of_memory_error/comment_1_a2331032781c2fa3cdf22c0dc6b5b869._comment b/doc/forum/git-annex_add_out_of_memory_error/comment_1_a2331032781c2fa3cdf22c0dc6b5b869._comment
new file mode 100644
index 0000000000..e4207f4f96
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error/comment_1_a2331032781c2fa3cdf22c0dc6b5b869._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-10-06T19:31:44Z"
+ content="""
+This message about "getdelim" comes from git, not git-annex. It seems
+git hash-object is what's running out of memory, and probably
+when it's processing its input from stdin.
+
+That's pretty strange. git-annex just passes some filenames to git
+hash-object. Unless the system is for some reason very low on memory,
+it shouldn't choke on such a small input as a filename.
+
+This seems likely to be a git bug, so what version of git? Perhaps
+try a newer one..
+
+(Re: P.S.: It's normal for files in .git/annex/objects to not
+have write access.)
+"""]]
diff --git a/doc/forum/git-annex_add_out_of_memory_error/comment_2_de9d956d95cb41e2372eabbf672e0f67._comment b/doc/forum/git-annex_add_out_of_memory_error/comment_2_de9d956d95cb41e2372eabbf672e0f67._comment
new file mode 100644
index 0000000000..0d8fb4bccf
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error/comment_2_de9d956d95cb41e2372eabbf672e0f67._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="jec@8edf298ac8f8152bffcd4fdc1a310949d3547fe4"
+ nickname="jec"
+ subject="Git Version"
+ date="2015-10-07T20:24:05Z"
+ content="""
+Thank for the response Joey...
+
+Here's my git version:
+
+    [xxx@infrastructure ~]$ which git
+    /opt/git-annex.linux/git
+    [xxx@infrastructure ~]$ /opt/git-annex.linux/git --version
+    git version 2.6.0
+
+I've doubled the amount of RAM on that VM to 8GB - I'll see what happens when I try another run.
+
+"""]]
diff --git a/doc/forum/git-annex_add_out_of_memory_error/comment_3_91af8300d640c34ff2466c89ec7a234c._comment b/doc/forum/git-annex_add_out_of_memory_error/comment_3_91af8300d640c34ff2466c89ec7a234c._comment
new file mode 100644
index 0000000000..603409b90a
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error/comment_3_91af8300d640c34ff2466c89ec7a234c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-09-29T15:33:00Z"
+ content="""
+Had another report of this, and there NFS seemed to be involved in the
+circumstances of the crash.
+"""]]
diff --git a/doc/forum/git-annex_add_out_of_memory_error/comment_4_ef913a45e3d865d088cf11460cd88020._comment b/doc/forum/git-annex_add_out_of_memory_error/comment_4_ef913a45e3d865d088cf11460cd88020._comment
new file mode 100644
index 0000000000..e9b52c3c28
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error/comment_4_ef913a45e3d865d088cf11460cd88020._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-10-04T16:23:12Z"
+ content="""
+NFS was a red herring.
+
+We've tracked this down to the linux standalone tarball not including
+locale-archive, so it uses the system one, which may have a different
+format and so breaks glibc.
+
+I'm committing a fix that adds locale-archive to the linux standalone
+tarball.
+"""]]
diff --git a/doc/forum/git-annex_add_out_of_memory_error/comment_5_64008199df70f77ab64882339aa079f9._comment b/doc/forum/git-annex_add_out_of_memory_error/comment_5_64008199df70f77ab64882339aa079f9._comment
new file mode 100644
index 0000000000..85eb8c0fc5
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error/comment_5_64008199df70f77ab64882339aa079f9._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="issue seems to be out there"
+ date="2017-07-31T15:03:41Z"
+ content="""
+[https://github.com/datalad/datalad/issues/1678](https://github.com/datalad/datalad/issues/1678)
+git annex standalone is quite recent so those manpage workarounds should be in place
+
+
+"""]]
diff --git a/doc/forum/git-annex_add_out_of_memory_error/comment_5_6a8580087688b4bbfc3241292df5422e._comment b/doc/forum/git-annex_add_out_of_memory_error/comment_5_6a8580087688b4bbfc3241292df5422e._comment
new file mode 100644
index 0000000000..bd579e381a
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error/comment_5_6a8580087688b4bbfc3241292df5422e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-07-31T18:42:38Z"
+ content="""
+The locale generation done by the standalone tarball needs write access to
+its directory. If datalad is using the git-annex-standalone.deb, non-root
+user's won't be able to write to it, and it will still use the system
+locales.
+"""]]
diff --git a/doc/forum/git-annex_add_out_of_memory_error/comment_8_76a65b4edf4f6e3896f1593a197f24eb._comment b/doc/forum/git-annex_add_out_of_memory_error/comment_8_76a65b4edf4f6e3896f1593a197f24eb._comment
new file mode 100644
index 0000000000..134a832b3c
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error/comment_8_76a65b4edf4f6e3896f1593a197f24eb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 8"
+ date="2017-08-01T02:59:30Z"
+ content="""
+so does it mean we need to do some \"locale\" operation on those files while generating standalone .deb package?  or that syadmin installing git-annex standalone package should do before allowing users to use that git-annex installation where they would not have R/W access to git-annex installation?
+"""]]
diff --git a/doc/forum/git-annex_add_out_of_memory_error/comment_8_ffbb059664541c92dcbf97c150d9b951._comment b/doc/forum/git-annex_add_out_of_memory_error/comment_8_ffbb059664541c92dcbf97c150d9b951._comment
new file mode 100644
index 0000000000..3b8a23c926
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error/comment_8_ffbb059664541c92dcbf97c150d9b951._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="&quot;reproduces&quot; in a complete git installation "
+ date="2017-08-09T17:07:17Z"
+ content="""
+Installed a stretch based singularity container on a Centos 6.9 with 2.6.32-696.6.3.el6.x86_64 kernel and within it, I reliably get the message
+
+[[!format sh \"\"\"
+yhalchen@discovery:~/datalad$ git pull --ff-only origin master
+From git://github.com/datalad/datalad
+ * branch              master     -> FETCH_HEAD
+fatal: Out of memory, getdelim failed
+yhalchen@discovery:~/datalad$ echo $?
+128
+yhalchen@discovery:~/datalad$ git --version
+git version 2.11.0
+yhalchen@discovery:~/datalad$ which git
+/usr/bin/git
+yhalchen@discovery:~/datalad$ apt-cache policy git
+git:
+  Installed: 1:2.11.0-3
+  Candidate: 1:2.11.0-3
+  Version table:
+ *** 1:2.11.0-3 500
+        500 http://smaug.datalad.org:3142/debian stretch/main amd64 Packages
+        100 /var/lib/dpkg/status
+
+\"\"\"]]
+also note that message might come not the last one in the output (initial run for the command was different):
+
+[[!format sh \"\"\"
+yhalchen@discovery:~/datalad$ git pull --ff-only
+remote: Counting objects: 19, done.
+remote: Compressing objects: 100% (6/6), done.
+remote: Total 19 (delta 13), reused 19 (delta 13), pack-reused 0
+Unpacking objects: 100% (19/19), done.
+fatal: Out of memory, getdelim failed
+error: git://github.com/datalad/datalad did not send all necessary objects
+
+\"\"\"]]
+"""]]
diff --git a/doc/forum/git-annex_add_out_of_memory_error/comment_9_7ef671c0036c77ee5707a6e00dd4dd6a._comment b/doc/forum/git-annex_add_out_of_memory_error/comment_9_7ef671c0036c77ee5707a6e00dd4dd6a._comment
new file mode 100644
index 0000000000..7e2a167910
--- /dev/null
+++ b/doc/forum/git-annex_add_out_of_memory_error/comment_9_7ef671c0036c77ee5707a6e00dd4dd6a._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comes and goes!"
+ date="2017-08-09T17:11:37Z"
+ content="""
+ha -- and then later call succeeded! (damn... right before I was trying to debug it)
+
+[[!format sh \"\"\"
+yhalchen@discovery:~/datalad$ git pull --ff-only origin master
+From git://github.com/datalad/datalad
+ * branch              master     -> FETCH_HEAD
+Updating c0cd538d..39f80454
+
+Fast-forward
+ CHANGELOG.md                              |  16 ++++
+ CONTRIBUTING.md                           |   2 +-
+ COPYING                                   |   3 +-
+ datalad/__init__.py                       |  30 ++++---
+ datalad/distribution/tests/test_update.py |   4 +-
+ datalad/distribution/update.py            |   3 +
+ datalad/interface/test.py                 |  33 +++++++-
+ datalad/support/annexrepo.py              |  42 +++++++---
+ datalad/support/third/noseclasses.py      | 339 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ datalad/support/third/nosetester.py       | 450 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ datalad/tests/test_utils.py               |  13 +++
+ datalad/utils.py                          |  15 ++++
+ datalad/version.py                        |   2 +-
+ 13 files changed, 923 insertions(+), 29 deletions(-)
+ create mode 100644 datalad/support/third/noseclasses.py
+ create mode 100644 datalad/support/third/nosetester.py
+\"\"\"]]
+but comes back anyways ;)
+[[!format sh \"\"\"
+yhalchen@discovery:~/datalad$ git branch
+* (HEAD detached from 0.8.0)
+  master
+yhalchen@discovery:~/datalad$ git pull --ff-only origin master
+From git://github.com/datalad/datalad
+ * branch              master     -> FETCH_HEAD
+fatal: Out of memory, getdelim failed
+\"\"\"]]
+"""]]
diff --git a/doc/forum/git-annex_and_bup_-_the_other_way_around___63____63____63__.mdwn b/doc/forum/git-annex_and_bup_-_the_other_way_around___63____63____63__.mdwn
new file mode 100644
index 0000000000..ba005e37a8
--- /dev/null
+++ b/doc/forum/git-annex_and_bup_-_the_other_way_around___63____63____63__.mdwn
@@ -0,0 +1,28 @@
+I've been wondering about using `git-annex` and `bup` together - but _not_ with `bup` as the backend, but rather backing up `bup` repos using `git-annex`.
+
+Let me try to explain...
+
+* `bup` is a a great deduplicating backup tool, but it does not have encryption
+* `git-annex` is a awesome in so many ways.  Including 1) multiple copies, 2) encryption
+
+(I know the following reads like the motivation for `git-annex`, but let me add the word **backup**) 
+
+* Recovering large backups over the internet can be costly and time consuming
+* Local copies are fast, but are risky
+
+So I was wondering about having my `bup` repos in `git-annex`, with multiple copies, including, say, an encrypted S3 bucket and some local copies.
+
+Then, if I had a problem and needed to restore I could use my local copies for as much as I could and then only pull part of the backup from the complete remote backup.
+
+If that all works, I then have:
+
+1. A more complicated process than a simple backup tool  :-(
+2. Multiple complete backups available :-D
+3. Encrypted, offsite backups :-D
+4. Small transfers (`bup` uses the awesomness of `git` to dedup the hell out of your data) :-D
+
+---
+
+I've not done this yet, but was thinking it through.
+
+Can anyone share some opinions, thoughts, concerns or high-5s for the awesomeness of my idea?  ;-)
diff --git a/doc/forum/git-annex_and_bup_-_the_other_way_around___63____63____63__/comment_1_0bb5e21b4cbaaaa61fbdb2e0066f0ebf._comment b/doc/forum/git-annex_and_bup_-_the_other_way_around___63____63____63__/comment_1_0bb5e21b4cbaaaa61fbdb2e0066f0ebf._comment
new file mode 100644
index 0000000000..ae1721e9db
--- /dev/null
+++ b/doc/forum/git-annex_and_bup_-_the_other_way_around___63____63____63__/comment_1_0bb5e21b4cbaaaa61fbdb2e0066f0ebf._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="m8r-568niv@9cefd6353b1102081f43c2f5bc53afdddc153274"
+ nickname="m8r-568niv"
+ subject="comment 1"
+ date="2016-06-17T07:07:10Z"
+ content="""
+I've posted to the bup list.
+
+Some positive comments:
+
+[https://groups.google.com/d/topic/bup-list/ReIZxGpTQCo/discussion](https://groups.google.com/d/topic/bup-list/ReIZxGpTQCo/discussion)
+"""]]
diff --git a/doc/forum/git-annex_and_bup_-_the_other_way_around___63____63____63__/comment_2_ab6420f7bc18e8143201c603c09a0d7e._comment b/doc/forum/git-annex_and_bup_-_the_other_way_around___63____63____63__/comment_2_ab6420f7bc18e8143201c603c09a0d7e._comment
new file mode 100644
index 0000000000..e63f26c495
--- /dev/null
+++ b/doc/forum/git-annex_and_bup_-_the_other_way_around___63____63____63__/comment_2_ab6420f7bc18e8143201c603c09a0d7e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="m8r-568niv@9cefd6353b1102081f43c2f5bc53afdddc153274"
+ nickname="m8r-568niv"
+ subject="comment 2"
+ date="2016-06-19T22:56:17Z"
+ content="""
+Looks like I missed an obvious link/reference:
+
+[https://git-annex.branchable.com/tips/Bup_repositories_in_git-annex/](https://git-annex.branchable.com/tips/Bup_repositories_in_git-annex/)
+"""]]
diff --git a/doc/forum/git-annex_and_tagfs.mdwn b/doc/forum/git-annex_and_tagfs.mdwn
new file mode 100644
index 0000000000..1ef40aea1c
--- /dev/null
+++ b/doc/forum/git-annex_and_tagfs.mdwn
@@ -0,0 +1,14 @@
+Hi,
+
+Thanks for git-annex, really a great project.
+Another related feature which would be useful to have is described by tagfs [3][] [4][], experimental implementations such as [tagfs over fuse][1], and [tagsistant][2] exist, but having a solution within the power of git-annex would really be attractive.
+
+How hard would this be to implement within the existing infrastructure?
+Thanks.
+
+related post: [[multiple_sym_links___40__for_tagging_photos__41____63__]]
+
+[1]: http://code.google.com/p/tagfs/
+[2]: www.tagsistant.net/
+[3]: http://site.xam.de/2006/01-tagfs.pdf
+[4]: http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&ved=0CE4QFjAF&url=http%3A%2F%2Fweb.mit.edu%2F6.033%2F2011%2Fwwwdocs%2Fwriting-samples%2Fsbezek_dp1.pdf&ei=ILQkUdqxMueR0QWgx4CwDw&usg=AFQjCNE1eWeFxmaxzOLZYVsb0tomqWNQaw&bvm=bv.42661473,d.d2k
diff --git a/doc/forum/git-annex_and_tagfs/comment_1_887c74cb61d30198322ef74ebc80f950._comment b/doc/forum/git-annex_and_tagfs/comment_1_887c74cb61d30198322ef74ebc80f950._comment
new file mode 100644
index 0000000000..95739bd93f
--- /dev/null
+++ b/doc/forum/git-annex_and_tagfs/comment_1_887c74cb61d30198322ef74ebc80f950._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.210"
+ subject="comment 1"
+ date="2013-02-24T21:52:41Z"
+ content="""
+I welcome people doing this kind of thing with git-annex. Since you can have multiple files linking to the same content easily, it should be a reasonable platform with which to build something like this.
+"""]]
diff --git a/doc/forum/git-annex_and_tagfs/comment_2_8769d6e57061023c0828af3e38faafba._comment b/doc/forum/git-annex_and_tagfs/comment_2_8769d6e57061023c0828af3e38faafba._comment
new file mode 100644
index 0000000000..2bb4ec273e
--- /dev/null
+++ b/doc/forum/git-annex_and_tagfs/comment_2_8769d6e57061023c0828af3e38faafba._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="exaos"
+ subject="Be eager for the TagFS features on git-annex."
+ date="2014-12-09T01:15:23Z"
+ content="""
+Cann't wait to see these implemented. But I don't know programming. :-(
+"""]]
diff --git a/doc/forum/git-annex_and_tagfs/comment_3_d96948c444f9f485a329420b7c9e3b16._comment b/doc/forum/git-annex_and_tagfs/comment_3_d96948c444f9f485a329420b7c9e3b16._comment
new file mode 100644
index 0000000000..4bc1ccc1f9
--- /dev/null
+++ b/doc/forum/git-annex_and_tagfs/comment_3_d96948c444f9f485a329420b7c9e3b16._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Xyem"
+ subject="comment 3"
+ date="2014-12-15T08:38:58Z"
+ content="""
+Do the [metadata views](http://git-annex.branchable.com/tips/metadata_driven_views/) not do what you want?
+"""]]
diff --git a/doc/forum/git-annex_assistant_atempts_to_repair__44___but_never_finishes.mdwn b/doc/forum/git-annex_assistant_atempts_to_repair__44___but_never_finishes.mdwn
new file mode 100644
index 0000000000..75ba03dd32
--- /dev/null
+++ b/doc/forum/git-annex_assistant_atempts_to_repair__44___but_never_finishes.mdwn
@@ -0,0 +1 @@
+I'm using git-annex (git-annex-6.20160126 from homebrew) on osx and for a while now, it claims that it tries to repair my annex-dir on my osx machine, even though it never finishes (or fails) to do so. I'm not sure what's causing this and I also tried to use `git annex repair`, but this didn't help either (it ran forever but never finishes). I tried to run `git annex fsck` and saw that some larger video files were only in one other place and therefore couldn't be droped, which I think I fixed by doing `git annex add` then `git annex sync` and finally `git annex copy --auto -to $Remote`. I'm not sure how to proceed, the log file doesn't seem to tell me a whole lot either. It just tells me for some of my files "Unable to lock down 1 copy of file that is required to safely drop it." and tries to repair that stuff over and over and over… or at least that's what I guess happens.
diff --git a/doc/forum/git-annex_assistant_atempts_to_repair__44___but_never_finishes/comment_1_a12892b2881969ddd6faa92d860e1bc8._comment b/doc/forum/git-annex_assistant_atempts_to_repair__44___but_never_finishes/comment_1_a12892b2881969ddd6faa92d860e1bc8._comment
new file mode 100644
index 0000000000..92a3f70b7d
--- /dev/null
+++ b/doc/forum/git-annex_assistant_atempts_to_repair__44___but_never_finishes/comment_1_a12892b2881969ddd6faa92d860e1bc8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 1"
+ date="2016-03-19T17:08:19Z"
+ content="""
+I added an old external hdd to my setup and now it seems to be working again. I assume, that a lot of my remotes stoped working, or only working sometimes. I guess I have to use `testremote` and go from there…
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers.mdwn b/doc/forum/git-annex_assistant_with_2_dedicated_servers.mdwn
new file mode 100644
index 0000000000..1544b14eff
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers.mdwn
@@ -0,0 +1,11 @@
+Hello,
+
+I am looking for a solution to replicate lots of files between 2 servers (with dedicated IP address) over WAN. (I already looked at GlusterFS, DRBD, Bittorent-Sync and ownCloud, but comments are welcome). Now I am evaluating git-annex but it is (kind of) hard to get the concepts as I am not familiar with git.
+
+I could already connect the servers by following the steps of "remote sharing walkthrough" but I feel that using a 3rd special node (as "transfer repository" / rsync or ssh) is an overhead and should not be needed. But no matter how hard I tried, I couldn't make the 2 servers do a sync without a special node. 
+
+Could you please give me a hint how to do it? Or even better, some detailed steps. :)
+
+Thanks,
+
+David
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_10_533ade2215c879cd46782fd66a97b167._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_10_533ade2215c879cd46782fd66a97b167._comment
new file mode 100644
index 0000000000..ec7dc0f861
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_10_533ade2215c879cd46782fd66a97b167._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="David"
+ ip="178.21.48.117"
+ subject="comment 10"
+ date="2013-11-16T23:15:49Z"
+ content="""
+Great. Understood. :) Thanks.
+
+Although there is one more thing that I don't really understand. Why do we need 2 repositories. In my mind (without knowing git) I thout it would work with one repository, where both server1 and server2 can upload/download files and they got synced through this. 
+
+    server1 <-> repository (somewhere, eother server1 or server2) <-> server2
+
+Now they use different repositories and I don't get why. Also I don't get how conflict-handling can be done if there are 2 repositories for the 2 transfer-ways.
+
+Sorry to bother you with this.
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_11_c9ae51d7b772cf7a91d90925f74d2b60._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_11_c9ae51d7b772cf7a91d90925f74d2b60._comment
new file mode 100644
index 0000000000..f614d066dc
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_11_c9ae51d7b772cf7a91d90925f74d2b60._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 11"
+ date="2013-11-16T23:25:26Z"
+ content="""
+When using git, each place you access your files is a separate repository. Thus, you have:
+
+server1 (repository) <--> server2 (repository) 
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_12_41fbee0ec9bc890e309bcd48a58c3851._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_12_41fbee0ec9bc890e309bcd48a58c3851._comment
new file mode 100644
index 0000000000..d707de6e10
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_12_41fbee0ec9bc890e309bcd48a58c3851._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="David"
+ ip="178.21.48.117"
+ subject="comment 12"
+ date="2013-11-18T11:25:06Z"
+ content="""
+Hello,
+
+Thanks for your help and explanation. Now I had some time to test git-annex and I had a sad experience. I tried to sync the files from server1 to server2 (as described before). We are talking about 87000 small files (these are maildir folders and each file is an e-mail) with the total size of 19 Gbytes. After a few hours git-annex assistant consumed all memory on both servers ... and then all swap ... and then kernel killed git-annex. The servers have 512 MB RAM and 1 GB swap.
+
+According to the Scalability page (http://git-annex.branchable.com/scalability/) the \"memory usage should be constant\" and I am sure I didn't run \"git-annex unused\".
+
+Is this memory consumption normal or it might be a bug? What shall we do?
+
+Thanks,
+
+David
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_13_571cffc0beb8ba5fc936db6971cd3d62._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_13_571cffc0beb8ba5fc936db6971cd3d62._comment
new file mode 100644
index 0000000000..aefe988132
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_13_571cffc0beb8ba5fc936db6971cd3d62._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="David"
+ ip="178.21.48.117"
+ subject="comment 13"
+ date="2013-11-19T09:17:26Z"
+ content="""
+Please tell me if/how I can help you. For example if you need access to servers to test...
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_14_0fb62af673a4bc8183e8fef048ceedd4._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_14_0fb62af673a4bc8183e8fef048ceedd4._comment
new file mode 100644
index 0000000000..7a4b80aa9b
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_14_0fb62af673a4bc8183e8fef048ceedd4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 14"
+ date="2013-12-16T20:36:14Z"
+ content="""
+I see the assistant spike up to around 150 mb when adding a lot of files, then drop back down once it finishes one batch (limited to around 5000 files) and moves on to the next. 
+
+You might need to file a bug report with some more details so I can reproduce the problem.
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_1_53a79af2d8e3abe50b983bf91972b8f2._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_1_53a79af2d8e3abe50b983bf91972b8f2._comment
new file mode 100644
index 0000000000..f6f058988c
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_1_53a79af2d8e3abe50b983bf91972b8f2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 1"
+ date="2013-11-16T17:42:48Z"
+ content="""
+The [[assistant/remote sharing walkthrough]] assumes that the computers are not servers, so they might not be turned on at the same time, and cannot directly contect each other.
+
+With 2 servers, it's much simpler. Just add a git remote on each pointing at the git repository on the other server, and run the git-annex assistant on both to keep them in sync.
+
+You can add the git remote with `git remote add otherserver ssh://otherserver/path/to/repo`, or you can use the webapp to do it (Add another repository -> Remote server)
+
+(If your WAN puts the servers on the same virtual subnet, ie a VPN, you can also probably use local pairing over the WAN to get to the same setup by a different route.)
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_2_c0ba3e8b7fbf8a5ed718001cec8df676._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_2_c0ba3e8b7fbf8a5ed718001cec8df676._comment
new file mode 100644
index 0000000000..8c4bb5922c
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_2_c0ba3e8b7fbf8a5ed718001cec8df676._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="David"
+ ip="178.21.48.117"
+ subject="still need some clarification"
+ date="2013-11-16T22:02:46Z"
+ content="""
+Hello,
+
+Thanks for your reply. I guessed that there is an easier, direct way to do it. But unfortunately I still need some clarification. This is how I tried:
+
+1. Cleared everything to start from scratch.
+2. I started git-annex on server1: screen git annex webapp --listen=server1_ip, opened the webapp and created the local repository /media/mail
+3. I configured the XMPP account on server1.
+4. Started git-annex on server2: screen git annex webapp --listen=server2_ip, opened the webapp and created the local repository /media/mail
+5. I configured the XMPP account on server2.
+
+And here comes the confusing part:
+
+6. On server1 I clicked Add another repository / Remote server: and configured ssh server2 to the same folder: /media/mail. I chose client repository group instead of transfer. (I am not sure if I did it right) ... but server1 started sync-ing.
+7. On server2 I clicked Add another repository / Remote server: and configured ssh server1 to the same folder: /media/mail. Then I received an error message:
+
+    Failed to make repository
+    Something went wrong setting up the repository on the remote server.
+    
+    Transcript:
+    
+    init  error: could not lock config file /media/mail-test/mail/.git/config: Permission denied
+    git-annex: git [Param \"config\",Param \"annex.version\",Param \"3\"] failed
+
+Cold you please help me where I did wrong?
+
+Thanks,
+
+David
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_3_60c39bc8ef74e80e72381d514b6dd223._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_3_60c39bc8ef74e80e72381d514b6dd223._comment
new file mode 100644
index 0000000000..f9e405b70b
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_3_60c39bc8ef74e80e72381d514b6dd223._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 3"
+ date="2013-11-16T22:18:20Z"
+ content="""
+It seems to me that you probably told git-annex to log into server2 as a user that does not have write access to sever2:/media/mail. Check the username field in the remote repository form.
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_4_6241120b4325c905661ef72881f4d7af._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_4_6241120b4325c905661ef72881f4d7af._comment
new file mode 100644
index 0000000000..bb7c193895
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_4_6241120b4325c905661ef72881f4d7af._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="David"
+ ip="178.21.48.117"
+ subject="still need some clarification"
+ date="2013-11-16T22:31:07Z"
+ content="""
+Hey,
+
+Yes, you were right. The ssh user did not have privileges to read/write the folder. Now I have corrected this issue and things started sync-ing.
+
+But I am afraid, this is not exactly the thing I wanted to achieve. My goal was to sync from folder to folder ... and not from folder to repository both ways.
+
+So, what I would like to do is that if I create a file at server1 (e.g. /media/mail/test01.txt) then it should appear at server2 at /media/mail/test01.txt.
+
+How can I achieve this?
+
+Thanks a lot.
+
+David
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_5_cab00b8fa195340f4d3fdaf5af975b57._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_5_cab00b8fa195340f4d3fdaf5af975b57._comment
new file mode 100644
index 0000000000..179a65a99a
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_5_cab00b8fa195340f4d3fdaf5af975b57._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 5"
+ date="2013-11-16T22:55:34Z"
+ content="""
+Well, that's what should happen. What behavior are you seeing? What version of git-annex are you using?
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_6_e24df9a1c68724a912b8ac6533d9bd25._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_6_e24df9a1c68724a912b8ac6533d9bd25._comment
new file mode 100644
index 0000000000..a28e947dda
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_6_e24df9a1c68724a912b8ac6533d9bd25._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="David"
+ ip="178.21.48.117"
+ subject="comment 6"
+ date="2013-11-16T22:58:15Z"
+ content="""
+Hello,
+
+Yes, meanwhile files started appearing. :) Maybe I just did not wait enough time.
+
+So, I have just one more question. Shall I set the remote ssh repositories to client or transfer? I read the docs and understand the difference, but in my case I simply cannot decide. 
+
+Thanks a lot for your hard work and great support. 
+
+David
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_7_ace3dc7c60c710a04b0a587206b341c4._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_7_ace3dc7c60c710a04b0a587206b341c4._comment
new file mode 100644
index 0000000000..c41fe492f4
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_7_ace3dc7c60c710a04b0a587206b341c4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 7"
+ date="2013-11-16T23:04:29Z"
+ content="""
+In your situation, you do not have or need a repository whose only job is to transfer files between two other client repositories. So the right choice for your repositories is client -- or something else possibly -- but almost certainly not transfer.
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_8_9a96bc970a17ed62b0ceb7aa3f0a6f8b._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_8_9a96bc970a17ed62b0ceb7aa3f0a6f8b._comment
new file mode 100644
index 0000000000..1d0f1db52c
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_8_9a96bc970a17ed62b0ceb7aa3f0a6f8b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="David"
+ ip="178.21.48.117"
+ subject="comment 8"
+ date="2013-11-16T23:09:32Z"
+ content="""
+Okay. One last question. Could you please help me understand how this sync works now? 
+
+So for example if I save a file on server1, it gets pushed to server2's repository. But how is it translated back to a normal file from the repository?
+
+And in this case will this file be on server2's repository as well (so are there 2 copies on server2, one in the repository and one human-readabl)?
+
+Thanks!
+"""]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_9_ea88e0696f6e25e6904248a323f6cc36._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_9_ea88e0696f6e25e6904248a323f6cc36._comment
new file mode 100644
index 0000000000..cafac10772
--- /dev/null
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_9_ea88e0696f6e25e6904248a323f6cc36._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 9"
+ date="2013-11-16T23:11:58Z"
+ content="""
+Since you created these repositories with the webapp, they default to using [[direct_mode]]. git-annex handles putting the files in place when they are transferred to the repository. Only 1 copy is made, there is no separate copy in the repository.
+"""]]
diff --git a/doc/forum/git-annex_build_for_Nokia_N9___40__Meego_Harmattan__41___and_Sailfish_OS.mdwn b/doc/forum/git-annex_build_for_Nokia_N9___40__Meego_Harmattan__41___and_Sailfish_OS.mdwn
new file mode 100644
index 0000000000..e2be4fd22b
--- /dev/null
+++ b/doc/forum/git-annex_build_for_Nokia_N9___40__Meego_Harmattan__41___and_Sailfish_OS.mdwn
@@ -0,0 +1,7 @@
+Hi,
+
+Is there a chance to get a build of git-annex for the Nokia N9 smartphone with Meego Harmattan and later for Sailfish OS (Jolla phone)?
+Git is already available for Meego Harmattan: http://www.who.is.free.fr/wiki/doku.php?id=harmattan
+
+Cheers,
+Tobias
diff --git a/doc/forum/git-annex_build_for_Nokia_N9___40__Meego_Harmattan__41___and_Sailfish_OS/comment_1_301a51c48c3d54f9d37feace26a772f8._comment b/doc/forum/git-annex_build_for_Nokia_N9___40__Meego_Harmattan__41___and_Sailfish_OS/comment_1_301a51c48c3d54f9d37feace26a772f8._comment
new file mode 100644
index 0000000000..d6464b679a
--- /dev/null
+++ b/doc/forum/git-annex_build_for_Nokia_N9___40__Meego_Harmattan__41___and_Sailfish_OS/comment_1_301a51c48c3d54f9d37feace26a772f8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="paulvt"
+ ip="2001:1af8:ff19:0:a288:b4ff:fe2c:f600"
+ subject="comment 1"
+ date="2013-07-13T08:21:29Z"
+ content="""
+I've just checked and almost all of the depends that Debian Sid on my laptop has, the N9 has.  But in the case of build-depends, they are nowhere near since the entire Haskell stack is not available...
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up.mdwn b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up.mdwn
new file mode 100644
index 0000000000..493f06b797
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up.mdwn
@@ -0,0 +1,27 @@
+We're experiencing a zombie outbreak:
+
+```
+user 25976  0.0  0.0   6808  1240 ?        S    17:17   0:00          \_ /opt/git-annex.linux/exe/git --library-path /opt/git-annex.linux//lib/x86_64-linux-gnu: /opt/git-annex.linux/shimmed/git/git annex get --jobs 4 --batch -z
+user 26001 88.4  0.2 1076112312 41728 ?    Sl   17:17   4:09              \_ /opt/git-annex.linux/exe/git-annex --library-path /opt/git-annex.linux//lib/x86_64-linux-gnu: /opt/git-annex.linux/shimmed/git-annex/git-annex get --jobs 4 --batch -z
+user 26278  0.0  0.0      0     0 ?        Z    17:17   0:00                  \_ [git] <defunct>
+user 26279  0.0  0.0      0     0 ?        Z    17:17   0:00                  \_ [git] <defunct>
+user 26474  0.0  0.0      0     0 ?        Z    17:17   0:00                  \_ [git] <defunct>
+user 26475  0.0  0.0      0     0 ?        Z    17:17   0:00                  \_ [git] <defunct>
+user 26735  0.0  0.0      0     0 ?        Z    17:17   0:00                  \_ [git] <defunct>
+user 26737  0.0  0.0      0     0 ?        Z    17:17   0:00                  \_ [git] <defunct>
+...
+```
+
+over 1229 and climbing as I type.
+
+It's git-annex version: 8.20210331-g1fb59a63a
+
+I've now stopped and restarted the 'git-annex get', but without `--jobs 4`, and this time it appears to have two zombie git processes, but it's not increasing as it gets more objects.
+
+I'm unsure how to debug what is wrong, so seeking guidance.
+
+Tomorrow I'll start to see if I can reproduce with older/newer versions of git-annex.
+
+[[!tag forumbug]]
+
+[[bugs/done]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_10_3bc5af3b28094fc042c207e307fe0c18._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_10_3bc5af3b28094fc042c207e307fe0c18._comment
new file mode 100644
index 0000000000..c2b5191bd8
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_10_3bc5af3b28094fc042c207e307fe0c18._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-11-19T13:30:25Z"
+ content="""
+I have not managed to reproduce it using that script. I let it run for 5
+minutes (and 1 gb transferred).
+
+Since that commit points to stall detection, I hacked the code to
+constantly detect false stalls. But I am still not seeing any zombie git
+processes with that.
+
+If stall detection *is* involved, I'd expect that you would see
+"Transfer seems to have stalled" when reproducing the bug.
+
+Since stall detection could depend on available bandwidth etc, I wonder if
+the script reproduces the bug reliably enough for the bisection to be
+correct. It would be helpful to manually verify the bisection result,
+with a longer test period than the script used. And look for the above
+message when reproducing it.
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_12_89b9fe9c689515a8f874dee96864ff33._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_12_89b9fe9c689515a8f874dee96864ff33._comment
new file mode 100644
index 0000000000..6f91587616
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_12_89b9fe9c689515a8f874dee96864ff33._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2021-11-19T16:02:41Z"
+ content="""
+Reproduced the bug. Took laptop entirely offline, then `git-annex get -J5`
+in the repo @yoh provided above. Sometimes it happens immediately,
+sometimes it needs to wait a few minutes for DNS timeouts.
+
+Looks like one leaked git cat-file per time it failed to download in that
+situation.
+
+Should be able to take it from here..
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_12_b48f8d801305d9bde08060f06634b88e._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_12_b48f8d801305d9bde08060f06634b88e._comment
new file mode 100644
index 0000000000..c2df933601
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_12_b48f8d801305d9bde08060f06634b88e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2021-11-19T15:37:43Z"
+ content="""
+I found a case where zombie git processes could be started in theory, 
+but only when git-annex is run without -J. And only a few zombies I think.
+And I couldn't find a code path where it actually happened.
+So not the same as this bug. But it did involve setConcurrency, which 
+the bisected commit also involves (via forkState), so at least shows
+how that could cause a such a problem in theory. Fixed that.
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_13_41e0fada90d795b9be12929ed66231e1._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_13_41e0fada90d795b9be12929ed66231e1._comment
new file mode 100644
index 0000000000..8df3c1700f
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_13_41e0fada90d795b9be12929ed66231e1._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2021-11-19T16:22:47Z"
+ content="""
+Fixed.
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_14_4bd86a227f117dbf5d1b12fbcf873e62._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_14_4bd86a227f117dbf5d1b12fbcf873e62._comment
new file mode 100644
index 0000000000..b444f382e5
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_14_4bd86a227f117dbf5d1b12fbcf873e62._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 14"
+ date="2021-11-19T17:44:22Z"
+ content="""
+  > fixed in [8.20211117-12-g623a77560](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=623a775609c486b5cd3441c5bca7c3d4a988eae0) --[[yarikoptic]]
+
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_1_a63df20ab1888e4dc5e7f002b4a68b5f._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_1_a63df20ab1888e4dc5e7f002b4a68b5f._comment
new file mode 100644
index 0000000000..e5d6f17943
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_1_a63df20ab1888e4dc5e7f002b4a68b5f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="strmd"
+ avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
+ subject="comment 1"
+ date="2021-05-19T07:00:58Z"
+ content="""
+Not sure if related, but I had a large `sync --content` operation stall numerous times yesterday because of errors related to too many git processes. This was with `-J2` and many small files using Mac OS, latest git-annex version via Homebrew.
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_2_3908d1552421edb054dc1a56c449ad23._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_2_3908d1552421edb054dc1a56c449ad23._comment
new file mode 100644
index 0000000000..8f1d97ed7a
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_2_3908d1552421edb054dc1a56c449ad23._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Nick_P"
+ avatar="http://cdn.libravatar.org/avatar/abf8aa3ac1a976a6a292416b9c604581"
+ subject="comment 2"
+ date="2021-05-19T14:29:22Z"
+ content="""
+My testing suggests that this was introduced between 8.20210127 (is good), and 8.20210223 (is bad).
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_3_5adf7777f9495e28432a0d60a15493ee._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_3_5adf7777f9495e28432a0d60a15493ee._comment
new file mode 100644
index 0000000000..d6ea4a8d77
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_3_5adf7777f9495e28432a0d60a15493ee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Nick_P"
+ avatar="http://cdn.libravatar.org/avatar/abf8aa3ac1a976a6a292416b9c604581"
+ subject="comment 3"
+ date="2021-05-19T14:35:43Z"
+ content="""
+I have not yet checked if fixed in https://git-annex.branchable.com/news/version_8.20210428/ , since https://downloads.kitenet.net/.git/ appears to be not yet updated with that version
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_4_b8a7f87aa1e9101fbb3e1d4e29febff5._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_4_b8a7f87aa1e9101fbb3e1d4e29febff5._comment
new file mode 100644
index 0000000000..29309d0a22
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_4_b8a7f87aa1e9101fbb3e1d4e29febff5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-05-19T14:53:30Z"
+ content="""
+Pass --debug to git-annex, it will output the git commands it runs along
+with their pid in [brackets], correlate that to the pid of a zombie and
+tell me what the specific git command is that has the problem.
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_5_122c584af1b1b6894cfccd4e16d2d76a._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_5_122c584af1b1b6894cfccd4e16d2d76a._comment
new file mode 100644
index 0000000000..0f1cb41445
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_5_122c584af1b1b6894cfccd4e16d2d76a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Nick_P"
+ avatar="http://cdn.libravatar.org/avatar/abf8aa3ac1a976a6a292416b9c604581"
+ subject="comment 5"
+ date="2021-05-19T16:59:21Z"
+ content="""
+Using 8.20210223-1~ndall+1 ; 
+
+```
+chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+```
+
+
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_6_4668f6cc692c49a456418f783655602b._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_6_4668f6cc692c49a456418f783655602b._comment
new file mode 100644
index 0000000000..760bae8bee
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_6_4668f6cc692c49a456418f783655602b._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="Nick_P"
+ avatar="http://cdn.libravatar.org/avatar/abf8aa3ac1a976a6a292416b9c604581"
+ subject="comment 6"
+ date="2021-05-20T10:43:14Z"
+ content="""
+This is the result of my test framework at the moment, which aims to determine when this issue appeared:
+
+```
+version,measured after seconds,zombies
+8.20201104-g13bab4f2c,30,3
+8.20201104-g13bab4f2c,60,3
+8.20201104-g13bab4f2c,90,3
+8.20201104-g13bab4f2c,120,3
+8.20201104-g13bab4f2c,150,3
+8.20201128-g4262ba3c4,30,3
+8.20201128-g4262ba3c4,60,3
+8.20201128-g4262ba3c4,90,3
+8.20201128-g4262ba3c4,120,3
+8.20201128-g4262ba3c4,150,3
+8.20210128-g5e5829a8d,30,5
+8.20210128-g5e5829a8d,60,21
+8.20210128-g5e5829a8d,90,47
+8.20210128-g5e5829a8d,120,51
+8.20210128-g5e5829a8d,150,55
+8.20210224-gf951847c6,30,9
+8.20210224-gf951847c6,60,19
+8.20210224-gf951847c6,90,35
+8.20210224-gf951847c6,120,51
+8.20210224-gf951847c6,150,61
+8.20210429-g84ceedb26,30,3
+8.20210429-g84ceedb26,60,17
+8.20210429-g84ceedb26,90,35
+8.20210429-g84ceedb26,120,49
+8.20210429-g84ceedb26,150,55
+```
+
+I can add more versions to check if requested.
+
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_7_8e9feaea0e807cefee95166508c9c7de._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_7_8e9feaea0e807cefee95166508c9c7de._comment
new file mode 100644
index 0000000000..e08c4c62fb
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_7_8e9feaea0e807cefee95166508c9c7de._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-05-21T15:33:06Z"
+ content="""
+If you want to completely narrow down a commit, use `git bisect`
+between 4262ba3c4 and 5e5829a8d. With 400 commits in that range it should
+take less than 9 rebuilds.
+
+Do you have annex.retry or similar config set? That range includes a change
+that spins up a bunch of child git-annex processes when that is set,
+which seems like the kind of thing that could be relevant.
+
+Since git cat-file is usually started up once and left running for the
+lifetime of git-annex (and waited for at the end if it exits normally),
+it's hard to see how it could end up being run repeatedly otherwise.
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_8_02c5903bf4de4b94e6db84bc43b3b3d8._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_8_02c5903bf4de4b94e6db84bc43b3b3d8._comment
new file mode 100644
index 0000000000..3d1d25abfa
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_8_02c5903bf4de4b94e6db84bc43b3b3d8._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="god bless search"
+ date="2021-11-17T21:03:29Z"
+ content="""
+found this issue which was not `done`.
+
+I have ran into it again: on initial occasion I could not even ssh to that host because ~4000 `[git] <defunct>` processes forbid any other process to start according to the policy.
+Updated git-annex to standalone build from conda (8.20211012-geb95ed486), repeated again (on http://datasets.datalad.org/labs/hasson/narratives/derivatives/fmriprep/.git
+) with a plain `git annex get -J5 .` -- had to interrupt it when I saw that reached 1k of those.  Here is dump of annexy config variables so - no retries
+
+```
+(datalad) [d31548v@discovery7 fmriprep]$ git config --list | grep annex
+annex.pidlock=true
+remote.origin.annex-bare=false
+remote.origin.annex-uuid=348d8bd8-1142-4de1-b52e-6b9899faa1d5
+annex.uuid=75d12ed4-e3e4-4ad0-ba7e-ec11538966d2
+annex.version=8
+filter.annex.smudge=git-annex smudge -- %f
+filter.annex.clean=git-annex smudge --clean -- %f
+remote.fcp-indi.annex-s3=true
+remote.fcp-indi.annex-uuid=bf6f56f3-f6b7-4df8-9898-a4226dc71400
+```
+
+I wish Nick_P has shared the script -- I could try to bisect... otherwise someone needs to write one ;-)
+"""]]
diff --git a/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_9_b6780a99d7a175d2ff3e33e198c28a9d._comment b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_9_b6780a99d7a175d2ff3e33e198c28a9d._comment
new file mode 100644
index 0000000000..8d13e7bf2a
--- /dev/null
+++ b/doc/forum/git-annex_causing_zombie_git_processes_to_build_up/comment_9_b6780a99d7a175d2ff3e33e198c28a9d._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="bisection"
+ date="2021-11-18T02:29:01Z"
+ content="""
+if I bisected it right (didn't doublecheck manually), it is due to [8.20210127-107-gdd39e9e25 AKA 8.20210223~41](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=dd39e9e255a5684824ea75861f48f658eaaba288)
+
+<details>
+<summary>bisection script</summary> 
+
+```
+#!/bin/bash
+
+set -u
+
+u=http://datasets.datalad.org/labs/hasson/narratives/derivatives/fmriprep/.git
+d=/mnt/scrap/tmp/fmriprep
+
+[ -e \"$d\" ] || datalad clone \"$u\" \"$d\"
+cd \"$d\"
+git annex drop --all
+git annex get -J5 . >/dev/null &
+p=$!  # use pstree?
+for i in {1..200}; do # 200 sec seems to be enough
+    np=$(ps auxw | grep $USER | grep '\[git\] <defunct>' | wc -l)
+    echo -n \"$i $np \"
+    if [ $np -gt 10 ]; then { kill $p; exit 1; } fi
+    sleep 1
+done
+kill \"$p\" 
+echo done
+
+
+```
+</details>
+"""]]
diff --git a/doc/forum/git-annex_clients_with_only_a_gitLab_repo_and_GDrive_special_remote_in_common.mdwn b/doc/forum/git-annex_clients_with_only_a_gitLab_repo_and_GDrive_special_remote_in_common.mdwn
new file mode 100644
index 0000000000..a1177cbf1d
--- /dev/null
+++ b/doc/forum/git-annex_clients_with_only_a_gitLab_repo_and_GDrive_special_remote_in_common.mdwn
@@ -0,0 +1,20 @@
+Greetings,
+
+I'm setting up git-annex as the store for a darktable environment.  I have to assume that all of the backup and client machines can not necessarily see each-other.  Let's call them:
+client1
+client2
+backup
+usb (incr. backup - in case a client can't reach the gdrive)
+gitlab (upstream - do I need to group this as well - if so, what)
+gdrive (again, labeled as a backup so it will take everything)
+
+They all can reach both a gitlab repo (I know they don't support annex anymore) and a special remote for the large files (gdrive via the rclone remote to allow me to use a team drive)
+
+So either client1 or client2 will create or update content.  git-annex assistant on the client will sync that to gitlab and gdrive (I assume).
+
+The question is, will git-annex assistant on backup and the other client check to see if there have been updates to the gitlab upstream?  If so, how often?  If not, should I git-annex schedule a git-annex-sync on each client and backup to force it?  
+
+Thx
+Christopher
+
+
diff --git a/doc/forum/git-annex_clients_with_only_a_gitLab_repo_and_GDrive_special_remote_in_common/comment_1_10fa70e1e5e08e12ab7c1570881b38f8._comment b/doc/forum/git-annex_clients_with_only_a_gitLab_repo_and_GDrive_special_remote_in_common/comment_1_10fa70e1e5e08e12ab7c1570881b38f8._comment
new file mode 100644
index 0000000000..d9d17fd266
--- /dev/null
+++ b/doc/forum/git-annex_clients_with_only_a_gitLab_repo_and_GDrive_special_remote_in_common/comment_1_10fa70e1e5e08e12ab7c1570881b38f8._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-11-13T19:58:20Z"
+ content="""
+Recent versions of git-annex have a git-lfs special
+remote, and gitlab does support git-lfs, so git-annex
+can store data on it. That does not answer your question, just wanted to
+mention it.
+
+For the assistant to quickly notice changes, it needs to be able to talk to
+a git-annex-shell on the remote's server. As a fallback, it does poll
+remotes periodically that don't have git-annex on them.  That's done once
+per hour, and also when network connection changes are detected.
+
+If you need to poll more frequently, you can install a cron job that does a
+git pull.
+"""]]
diff --git a/doc/forum/git-annex_clients_with_only_a_gitLab_repo_and_GDrive_special_remote_in_common/comment_2_ff0dab8dc544f7aa8e4ebfbec8f2a081._comment b/doc/forum/git-annex_clients_with_only_a_gitLab_repo_and_GDrive_special_remote_in_common/comment_2_ff0dab8dc544f7aa8e4ebfbec8f2a081._comment
new file mode 100644
index 0000000000..0e4a37c0ec
--- /dev/null
+++ b/doc/forum/git-annex_clients_with_only_a_gitLab_repo_and_GDrive_special_remote_in_common/comment_2_ff0dab8dc544f7aa8e4ebfbec8f2a081._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="git-annex@17927e6dc041ab425c14217a97a685adf3ecf44f"
+ nickname="git-annex"
+ avatar="http://cdn.libravatar.org/avatar/66e5c6e044d726597ce5a0ad68f86fe4"
+ subject="comment 2"
+ date="2019-11-14T00:38:56Z"
+ content="""
+Thank's Joey - that's what I needed. 
+"""]]
diff --git a/doc/forum/git-annex_communication_channels.mdwn b/doc/forum/git-annex_communication_channels.mdwn
new file mode 100644
index 0000000000..8c56ac36a2
--- /dev/null
+++ b/doc/forum/git-annex_communication_channels.mdwn
@@ -0,0 +1,10 @@
+Thought I'd ask how y'all are finding the current communication by this forum/website/git repo only.
+
+Would there be a benefit to having an irc channel for git-annex?
+
+Maybe a mailing list? (Any persuasive reason why it would be better than this forum?)
+
+Are the existing RSS feeds on this site, for eg, new [[comments]] and posts to this forum, sufficient to keep up with
+things?
+
+--[[Joey]]
diff --git a/doc/forum/git-annex_communication_channels/comment_1_198325d2e9337c90f026396de89eec0e._comment b/doc/forum/git-annex_communication_channels/comment_1_198325d2e9337c90f026396de89eec0e._comment
new file mode 100644
index 0000000000..163aae02cc
--- /dev/null
+++ b/doc/forum/git-annex_communication_channels/comment_1_198325d2e9337c90f026396de89eec0e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2011-03-28T15:48:08Z"
+ content="""
+No matter what you end up doing, I would appreciate a git-annex-announce@ list.
+
+I really like the persistence of ikiwiki, but it's not ideal for quick communication. I would be fine with IRC and/or ML. The advantage of a ML over ikiwiki is that it doesn't seem to be as \"wasteful\" to mix normal chat with actual problem-solving.  But maybe that's merely my own perception.
+
+Speaking of RSS: I thought I had added a wishlist item to ikiwiki about providing per-subsite RSS feeds. For example there is no (obvious) way to subscribe to changes in http://git-annex.branchable.com/forum/git-annex_communication_channels/ .
+
+FWIW, I resorted to tagging my local clone of git-annex to keep track of what I've read, already.
+
+
+-- RichiH
+"""]]
diff --git a/doc/forum/git-annex_communication_channels/comment_2_c7aeefa6ef9a2e75d8667b479ade1b7f._comment b/doc/forum/git-annex_communication_channels/comment_2_c7aeefa6ef9a2e75d8667b479ade1b7f._comment
new file mode 100644
index 0000000000..09a2b8c1a5
--- /dev/null
+++ b/doc/forum/git-annex_communication_channels/comment_2_c7aeefa6ef9a2e75d8667b479ade1b7f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2011-03-28T18:35:50Z"
+ content="""
+I think the forums/website currently is sufficient, I do at times wish there was a mailing list or anonymous git push to the wiki as I find editing posts through the web browser is some times tedious (the lack of !fmt or alt-q bugs me at times ;) ). The main advantage of keeping stuff on the site/forum is that everything gets saved and passed on to anyone who checks out the git repo of the code base.
+"""]]
diff --git a/doc/forum/git-annex_communication_channels/comment_3_1ff08a3e0e63fa0e560cbc9602245caa._comment b/doc/forum/git-annex_communication_channels/comment_3_1ff08a3e0e63fa0e560cbc9602245caa._comment
new file mode 100644
index 0000000000..72a48445ed
--- /dev/null
+++ b/doc/forum/git-annex_communication_channels/comment_3_1ff08a3e0e63fa0e560cbc9602245caa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 3"
+ date="2011-03-28T20:47:23Z"
+ content="""
+Push access to the non-code bits of git-annex' ikiwiki would be very welcome indeed. Given the choice, I would rather edit everything in Vim than in a browser. -- RichiH
+"""]]
diff --git a/doc/forum/git-annex_communication_channels/comment_4_1ba6ddf54843c17c7d19a9996f2ab712._comment b/doc/forum/git-annex_communication_channels/comment_4_1ba6ddf54843c17c7d19a9996f2ab712._comment
new file mode 100644
index 0000000000..d6bba93651
--- /dev/null
+++ b/doc/forum/git-annex_communication_channels/comment_4_1ba6ddf54843c17c7d19a9996f2ab712._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="comment 4"
+ date="2011-04-13T17:53:26Z"
+ content="""
+.1 cents: Having IRC would be really nice for seeking quick help.   E.g. like I was trying to do now, google lead me to this page.
+"""]]
diff --git a/doc/forum/git-annex_communication_channels/comment_5_404b723a681eb93fee015cea8024b6bc._comment b/doc/forum/git-annex_communication_channels/comment_5_404b723a681eb93fee015cea8024b6bc._comment
new file mode 100644
index 0000000000..042dcc1f38
--- /dev/null
+++ b/doc/forum/git-annex_communication_channels/comment_5_404b723a681eb93fee015cea8024b6bc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkptNW1PzrVjYlJWP_9e499uH0mjnBV6GQ"
+ nickname="Christian"
+ subject="comment 5"
+ date="2011-04-14T11:24:59Z"
+ content="""
+I would also like an git-annex channel. Would be #git-annex@OFTC ok?
+"""]]
diff --git a/doc/forum/git-annex_communication_channels/comment_6_0d87d0e26461494b1d7f8a701a924729._comment b/doc/forum/git-annex_communication_channels/comment_6_0d87d0e26461494b1d7f8a701a924729._comment
new file mode 100644
index 0000000000..8dfd0f8203
--- /dev/null
+++ b/doc/forum/git-annex_communication_channels/comment_6_0d87d0e26461494b1d7f8a701a924729._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 6"
+ date="2011-04-15T19:32:08Z"
+ content="""
+We seem to be using #vcs-home @ OFTC for now. madduck is fine with it and joeyh pokes his head in there, as well. I just added a CIA bot to #vcs-home and this comment is a test if pushing works. -- RichiH
+"""]]
diff --git a/doc/forum/git-annex_communication_channels/comment_7_2c87c7a0648fe87c2bf6b4391f1cc468._comment b/doc/forum/git-annex_communication_channels/comment_7_2c87c7a0648fe87c2bf6b4391f1cc468._comment
new file mode 100644
index 0000000000..830d678ca1
--- /dev/null
+++ b/doc/forum/git-annex_communication_channels/comment_7_2c87c7a0648fe87c2bf6b4391f1cc468._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="anonymous git push"
+ date="2011-05-19T19:21:51Z"
+ content="""
+@Jimmy mentioned anonymous git push -- that is now enabled for this wiki. Enjoy!
+
+I may try to spend more time on #vcs-home -- or I can be summoned there from my other lurking places on irc, I guess.
+"""]]
diff --git a/doc/forum/git-annex_confused_by_a_case-preserving_filesystem__63__.mdwn b/doc/forum/git-annex_confused_by_a_case-preserving_filesystem__63__.mdwn
new file mode 100644
index 0000000000..8fc51db50d
--- /dev/null
+++ b/doc/forum/git-annex_confused_by_a_case-preserving_filesystem__63__.mdwn
@@ -0,0 +1,73 @@
+Hello,
+
+I use git annex to sync files between my home linux server and my mac os laptop (macbook).
+This is a report about some troubles I had recovering git-annexed files from the macbook hard-drive.
+
+The laptop had some hardware failure, so I bought another laptop (this time running linux), 
+and plugged the macbook hard drive on yet another linux computer to recover the data (some files which were
+added to the macbook annex but never synchronized to the server):
+
+* mount the hfsplus FS as read-only
+* cp -a (as root) the annex to /home/seb/macbook
+* use git annex as usual (from the linux computer) to push the files to the linux server.
+
+Later on, I noticed that some files were missing (for instance "Le retour du printemps.mp4").
+I eventually understood that it was related to HFS+ being case-insensitive (case-preserving. actually), and that by copying the annex to the linux partition I lost that property.
+
+here are commands which I run from the linux computer to reproduce the issue:
+
+    $ cd /home/seb/macbook
+    $ git annex version
+    git-annex version: 5.20140412ubuntu1
+    $ git annex whereis  "public/Videos/Documentaries/Nature/Le retour du printemps.mp4"
+    whereis public/Videos/Documentaries/Nature/Le retour du printemps.mp4 (1 copy) 
+            18b9c2cc-e3c1-4002-a0a2-7e07782fae2c -- here (navimac/annex)
+
+Trying to copy the file to the linux server
+
+    $ git annex copy  "public/Videos/Documentaries/Nature/Le retour du printemps.mp4" --to origin ; echo $?
+    0
+
+Here git-annex did not copy anything, but reported success, maybe a bug.
+Fsck does account the issue:
+
+    $ git annex fsck  "public/Videos/Documentaries/Nature/Le retour du printemps.mp4" 
+    fsck public/Videos/Documentaries/Nature/Le retour du printemps.mp4 (fixing location log) 
+      ** Based on the location log, public/Videos/Documentaries/Nature/Le retour du printemps.mp4
+      ** was expected to be present, but its content is missing.
+      ** No known copies exist of public/Videos/Documentaries/Nature/Le retour du printemps.mp4
+    failed
+    git-annex: fsck: 1 failed
+
+It turn out the file is there, but in gm/29 instead of gM/29:
+
+    $ ls -l  "public/Videos/Documentaries/Nature/Le retour du printemps.mp4"
+    lrwxrwxrwx 1 seb root 214 Apr 17  2017 public/Videos/Documentaries/Nature/Le retour du printemps.mp4 -> ../../../../.git/annex/objects/gM/29/SHA256E-s915126032--79eb20cad1b56adf4831b8a665b02c7de68aaaa4c9ca424a5a90e288abcec2aa.mp4/SHA256E-s915126032--79eb20cad1b56adf4831b8a665b02c7de68aaaa4c9ca424a5a90e288abcec2aa.mp4
+    $ ls -l .git/annex/objects/g{M,m}/29/SHA256E-s915126032--79eb20cad1b56adf4831b8a665b02c7de68aaaa4c9ca424a5a90e288abcec2aa.mp4/SHA256E-s915126032--79eb20cad1b56adf4831b8a665b02c7de68aaaa4c9ca424a5a90e288abcec2aa.mp4
+    ls: cannot access .git/annex/objects/gM/29/SHA256E-s915126032--79eb20cad1b56adf4831b8a665b02c7de68aaaa4c9ca424a5a90e288abcec2aa.mp4/SHA256E-s915126032--79eb20cad1b56adf4831b8a665b02c7de68aaaa4c9ca424a5a90e288abcec2aa.mp4: No such file or directory
+    -r--r--r-- 1 seb root 915126032 Apr 17  2017 .git/annex/objects/gm/29/SHA256E-s915126032--79eb20cad1b56adf4831b8a665b02c7de68aaaa4c9ca424a5a90e288abcec2aa.mp4/SHA256E-s915126032--79eb20cad1b56adf4831b8a665b02c7de68aaaa4c9ca424a5a90e288abcec2aa.mp4
+
+I think that if ran the git annex from the hfsplus partition directly (ie. not copying the annex to /home/seb/macbook), it would have worked.
+
+Moving the file where git annex expects to find it solves it all:
+
+    $ mkdir .git/annex/objects/gM
+    $ mv  .git/annex/objects/gm/29 .git/annex/objects/gM/
+    $ git annex fsck  "public/Videos/Documentaries/Nature/Le retour du printemps.mp4" 
+    fsck public/Videos/Documentaries/Nature/Le retour du printemps.mp4 (fixing location log) (checksum...)
+    ok
+    (Recording state in git...)
+
+    $ git annex copy  "public/Videos/Documentaries/Nature/Le retour du printemps.mp4" --to origin ; echo $?                                                                                                                                                 
+    copy public/Videos/Documentaries/Nature/Le retour du printemps.mp4 (checking origin...)
+    seb@192.168.0.1's password: 
+    (to origin...) 
+    SHA256E-s915126032--79eb20cad1b56adf4831b8a665b02c7de68aaaa4c9ca424a5a90e288abcec2aa.mp4
+        915,126,032 100%    3.44MB/s    0:04:13 (xfr#1, to-chk=0/1)
+    ok
+    (Recording state in git...)
+    0
+
+Maybe I could instead have used cpiofs to avoid renaming files. (But I have less than 10 files to rename anyway).
+
+I learned a lot about git annex today! Thank you again fot git-annex.
diff --git a/doc/forum/git-annex_does_not_protect_files_on_NTFS-Fuse.mdwn b/doc/forum/git-annex_does_not_protect_files_on_NTFS-Fuse.mdwn
new file mode 100644
index 0000000000..e8084f6ff5
--- /dev/null
+++ b/doc/forum/git-annex_does_not_protect_files_on_NTFS-Fuse.mdwn
@@ -0,0 +1,8 @@
+I've read that git-annex probes the host filesystem to determine whether it has the necessary features for an indirect annex. Indirect annexes are supposed to protect annexed files from accidental editing:
+
+    # echo oops > my_cool_big_file
+    bash: my_cool_big_file: Permission denied
+
+I have an NTFS drive to share files between my Windows and Linux systems (dual boot). On Linux fuse sets the file permissions to rwx for the user and nothing for the rest, and this cannot be changed. Files in the annex can be modified as in the above example.
+
+If git-annex detects whether a fs can handle indirect annexes or not, I suggest checking for this case if possible.
diff --git a/doc/forum/git-annex_does_not_protect_files_on_NTFS-Fuse/comment_1_4aef65f680e4801eb110fefa1f947f02._comment b/doc/forum/git-annex_does_not_protect_files_on_NTFS-Fuse/comment_1_4aef65f680e4801eb110fefa1f947f02._comment
new file mode 100644
index 0000000000..039d237406
--- /dev/null
+++ b/doc/forum/git-annex_does_not_protect_files_on_NTFS-Fuse/comment_1_4aef65f680e4801eb110fefa1f947f02._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-30T17:54:11Z"
+ content="""
+Good idea. Also, putting an indirect mode repo on a NTFS filesystem would
+probably yield confusing results when trying to use it on windows..
+
+I've put a check for this in with the other crippled FS checks that init
+does.
+"""]]
diff --git a/doc/forum/git-annex_does_not_respect_preferred_content_settings.mdwn b/doc/forum/git-annex_does_not_respect_preferred_content_settings.mdwn
new file mode 100644
index 0000000000..bb719e08d4
--- /dev/null
+++ b/doc/forum/git-annex_does_not_respect_preferred_content_settings.mdwn
@@ -0,0 +1,18 @@
+I have the following vicfg,
+
+    group UUID1 = PodA
+    group UUID2 = PodA
+    group UUID3 = PodA
+    group UUID4 = PodB
+
+    wanted UUID1 = groupwanted
+    wanted UUID2 = groupwanted
+    wanted UUID3 = groupwanted
+    wanted UUID4 = groupwanted
+
+    groupwanted PodA = present and not copies=PodA:1
+    groupwanted PodB = present and not copies=PodB:1
+
+at this point repos 1 2 3 combined has 1 copy of each file and repo 4 has full copy of all files. (used to move files around manually before grouping repos). 
+
+What I am trying to achieve is to have a copy of a file in one of the 3 repos (1 2 3) and one copy in 4. running git annex get --auto starts getting all files, files with copies on other disks. testing using git annex find --want-get --not --in . returns all remaining files not in the repo but has enough copies on other repos both PodA and PodB has copies. numofcopies is set to 2.
diff --git a/doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_1_ea347ea6ebdfe5ccfb0ed8786638f279._comment b/doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_1_ea347ea6ebdfe5ccfb0ed8786638f279._comment
new file mode 100644
index 0000000000..647a9d1e23
--- /dev/null
+++ b/doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_1_ea347ea6ebdfe5ccfb0ed8786638f279._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-11T17:49:32Z"
+ content="""
+Um, I'm pretty sure git-annex respects your preferred content settings.
+Whether the settings do what you think they do is another matter.
+
+When I tried replicating the same settings you show, "git annex get --auto"
+didn't want to get any files. That makes perfect sense, since
+"present" only succeeds if the file is already in the repo, so for files
+that are not, it fails, and so "present AND foo" fails, and so the file is
+not wanted.
+
+Lose the "present". All you need to make the files land on only 1 of the
+PodA repos is "not copies=PodA:1"
+"""]]
diff --git a/doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_2_5fac7c41c9841cea4234afa0a98b1636._comment b/doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_2_5fac7c41c9841cea4234afa0a98b1636._comment
new file mode 100644
index 0000000000..90c6303915
--- /dev/null
+++ b/doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_2_5fac7c41c9841cea4234afa0a98b1636._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 2"
+ date="2015-09-11T20:46:00Z"
+ content="""
+joey thanks for the reply, I've updated the expression to \"not copies=PodA:1\" but running \"git annex get --auto\" still wants to get all files that are already present in other repos in PodA. Say I have file asd.txt present in PodA repo 2 and PodB repo 4 content is already there. running get on repo 1 still gets the file in repo 1. 
+"""]]
diff --git a/doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_3_e2ea1843bbc9580ca7b4ec494f53b552._comment b/doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_3_e2ea1843bbc9580ca7b4ec494f53b552._comment
new file mode 100644
index 0000000000..1870bc743f
--- /dev/null
+++ b/doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_3_e2ea1843bbc9580ca7b4ec494f53b552._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 3"
+ date="2015-09-13T12:52:51Z"
+ content="""
+As a test I've created 4 new test repos (different test content) with your suggested settings, you are correct that with the settings everything works as it should but for some reason my actual repos does not honor those settings.
+"""]]
diff --git a/doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_4_59ede467a902f27b81f14e4706a7503a._comment b/doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_4_59ede467a902f27b81f14e4706a7503a._comment
new file mode 100644
index 0000000000..504afc907d
--- /dev/null
+++ b/doc/forum/git-annex_does_not_respect_preferred_content_settings/comment_4_59ede467a902f27b81f14e4706a7503a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-09-15T16:00:16Z"
+ content="""
+Are these repositories all in sync, so that git-annex in repo 1
+knows that repo 2 and repo 4 have already gotten the file?
+"""]]
diff --git a/doc/forum/git-annex_doesn__39__t_build_with_feed-1.0.0.0.mdwn b/doc/forum/git-annex_doesn__39__t_build_with_feed-1.0.0.0.mdwn
new file mode 100644
index 0000000000..bdcb7e0f22
--- /dev/null
+++ b/doc/forum/git-annex_doesn__39__t_build_with_feed-1.0.0.0.mdwn
@@ -0,0 +1,209 @@
+    [470 of 574] Compiling Command.ImportFeed ( Command/ImportFeed.hs, dist/build/git-annex/git-annex-tmp/Command/ImportFeed.dyn_o )
+
+    Command/ImportFeed.hs:139:61: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: URLString
+            Actual type: Text.Atom.Feed.URI
+        • In the first argument of ‘Enclosure’, namely ‘enclosureurl’
+        In the second argument of ‘($)’, namely ‘Enclosure enclosureurl’
+        In the second argument of ‘($)’, namely
+            ‘ToDownload f u i $ Enclosure enclosureurl’
+        |
+    139 |                         Just $ ToDownload f u i $ Enclosure enclosureurl
+        |                                                             ^^^^^^^^^^^^
+
+    Command/ImportFeed.hs:142:49: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: URLString
+            Actual type: Data.Text.Internal.Text
+        • In the first argument of ‘quviSupported’, namely ‘link’
+        In the first argument of ‘ifM’, namely ‘(quviSupported link)’
+        In the expression:
+            ifM
+            (quviSupported link)
+            (return $ Just $ ToDownload f u i $ QuviLink link, return Nothing)
+        |
+    142 |                 Just link -> ifM (quviSupported link)
+        |                                                 ^^^^
+
+    Command/ImportFeed.hs:143:71: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: URLString
+            Actual type: Data.Text.Internal.Text
+        • In the first argument of ‘QuviLink’, namely ‘link’
+        In the second argument of ‘($)’, namely ‘QuviLink link’
+        In the second argument of ‘($)’, namely
+            ‘ToDownload f u i $ QuviLink link’
+        |
+    143 |                         ( return $ Just $ ToDownload f u i $ QuviLink link
+        |                                                                       ^^^^
+
+    Command/ImportFeed.hs:214:54: error:
+        • Couldn't match type ‘[Char]’ with ‘Data.Text.Internal.Text’
+        Expected type: S.Set Data.Text.Internal.Text
+            Actual type: S.Set ItemId
+        • In the second argument of ‘S.member’, namely ‘(knownitems cache)’
+        In the expression: S.member itemid (knownitems cache)
+        In a case alternative:
+            Just (_, itemid) -> S.member itemid (knownitems cache)
+        |
+    214 |                 Just (_, itemid) -> S.member itemid (knownitems cache)
+        |                                                      ^^^^^^^^^^^^^^^^
+
+    Command/ImportFeed.hs:279:42: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe [Char]
+            Actual type: Maybe Text.RSS.Syntax.DateString
+        • In the second argument of ‘(<$>)’, namely
+            ‘getItemPublishDateString itm’
+        In the expression: replace "/" "-" <$> getItemPublishDateString itm
+        In a case alternative:
+            _ -> replace "/" "-" <$> getItemPublishDateString itm
+        |
+    279 |                 _ -> replace "/" "-" <$> getItemPublishDateString itm
+        |                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+    Command/ImportFeed.hs:293:44: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: String
+            Actual type: Data.Text.Internal.Text
+        • In the first argument of ‘toMetaValue’, namely ‘itemid’
+        In the second argument of ‘($)’, namely ‘toMetaValue itemid’
+        In the second argument of ‘M.singleton’, namely
+            ‘(S.singleton $ toMetaValue itemid)’
+        |
+    293 |                 (S.singleton $ toMetaValue itemid)
+        |                                            ^^^^^^
+
+    Command/ImportFeed.hs:299:26: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe String
+            Actual type: Maybe Data.Text.Internal.Text
+        • In the expression: feedtitle
+        In the expression: [feedtitle]
+        In the expression: ("feedtitle", [feedtitle])
+        |
+    299 |         [ ("feedtitle", [feedtitle])
+        |                          ^^^^^^^^^
+
+    Command/ImportFeed.hs:300:26: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe String
+            Actual type: Maybe Data.Text.Internal.Text
+        • In the expression: itemtitle
+        In the expression: [itemtitle]
+        In the expression: ("itemtitle", [itemtitle])
+        |
+    300 |         , ("itemtitle", [itemtitle])
+        |                          ^^^^^^^^^
+
+    Command/ImportFeed.hs:301:27: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe String
+            Actual type: Maybe Data.Text.Internal.Text
+        • In the expression: feedauthor
+        In the expression: [feedauthor]
+        In the expression: ("feedauthor", [feedauthor])
+        |
+    301 |         , ("feedauthor", [feedauthor])
+        |                           ^^^^^^^^^^
+
+    Command/ImportFeed.hs:302:27: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe String
+            Actual type: Maybe Data.Text.Internal.Text
+        • In the expression: itemauthor
+        In the expression: [itemauthor]
+        In the expression: ("itemauthor", [itemauthor])
+        |
+    302 |         , ("itemauthor", [itemauthor])
+        |                           ^^^^^^^^^^
+
+    Command/ImportFeed.hs:303:28: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe String
+            Actual type: Maybe Data.Text.Internal.Text
+        • In the expression: getItemSummary $ item i
+        In the expression: [getItemSummary $ item i]
+        In the expression: ("itemsummary", [getItemSummary $ item i])
+        |
+    303 |         , ("itemsummary", [getItemSummary $ item i])
+        |                            ^^^^^^^^^^^^^^^^^^^^^^^
+
+    Command/ImportFeed.hs:304:32: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe String
+            Actual type: Maybe Data.Text.Internal.Text
+        • In the expression: getItemDescription $ item i
+        In the expression: [getItemDescription $ item i]
+        In the expression:
+            ("itemdescription", [getItemDescription $ item i])
+        |
+    304 |         , ("itemdescription", [getItemDescription $ item i])
+        |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+    Command/ImportFeed.hs:305:27: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe String
+            Actual type: Maybe Data.Text.Internal.Text
+        • In the expression: getItemRights $ item i
+        In the expression: [getItemRights $ item i]
+        In the expression: ("itemrights", [getItemRights $ item i])
+        |
+    305 |         , ("itemrights", [getItemRights $ item i])
+        |                           ^^^^^^^^^^^^^^^^^^^^^^
+
+    Command/ImportFeed.hs:306:23: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe String
+            Actual type: Maybe Data.Text.Internal.Text
+        • In the expression: snd <$> getItemId (item i)
+        In the expression: [snd <$> getItemId (item i)]
+        In the expression: ("itemid", [snd <$> getItemId (item i)])
+        |
+    306 |         , ("itemid", [snd <$> getItemId (item i)])
+        |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+    Command/ImportFeed.hs:307:22: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe String
+            Actual type: Maybe Data.Text.Internal.Text
+        • In the expression: itemtitle
+        In the expression: [itemtitle, feedtitle]
+        In the expression: ("title", [itemtitle, feedtitle])
+        |
+    307 |         , ("title", [itemtitle, feedtitle])
+        |                      ^^^^^^^^^
+
+    Command/ImportFeed.hs:307:33: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe String
+            Actual type: Maybe Data.Text.Internal.Text
+        • In the expression: feedtitle
+        In the expression: [itemtitle, feedtitle]
+        In the expression: ("title", [itemtitle, feedtitle])
+        |
+    307 |         , ("title", [itemtitle, feedtitle])
+        |                                 ^^^^^^^^^
+
+    Command/ImportFeed.hs:308:23: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe String
+            Actual type: Maybe Data.Text.Internal.Text
+        • In the expression: itemauthor
+        In the expression: [itemauthor, feedauthor]
+        In the expression: ("author", [itemauthor, feedauthor])
+        |
+    308 |         , ("author", [itemauthor, feedauthor])
+        |                       ^^^^^^^^^^
+
+    Command/ImportFeed.hs:308:35: error:
+        • Couldn't match type ‘Data.Text.Internal.Text’ with ‘[Char]’
+        Expected type: Maybe String
+            Actual type: Maybe Data.Text.Internal.Text
+        • In the expression: feedauthor
+        In the expression: [itemauthor, feedauthor]
+        In the expression: ("author", [itemauthor, feedauthor])
+        |
+    308 |         , ("author", [itemauthor, feedauthor])
+        |                                   ^^^^^^^^^^
diff --git a/doc/forum/git-annex_doesn__39__t_build_with_feed-1.0.0.0/comment_1_0be4545b1d93232a721c5ae65030334c._comment b/doc/forum/git-annex_doesn__39__t_build_with_feed-1.0.0.0/comment_1_0be4545b1d93232a721c5ae65030334c._comment
new file mode 100644
index 0000000000..2c630f2676
--- /dev/null
+++ b/doc/forum/git-annex_doesn__39__t_build_with_feed-1.0.0.0/comment_1_0be4545b1d93232a721c5ae65030334c._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-09-24T19:58:47Z"
+ content="""
+Already fixed in git head.
+"""]]
diff --git a/doc/forum/git-annex_fails_on_Windows.mdwn b/doc/forum/git-annex_fails_on_Windows.mdwn
new file mode 100644
index 0000000000..6c10003eb0
--- /dev/null
+++ b/doc/forum/git-annex_fails_on_Windows.mdwn
@@ -0,0 +1,56 @@
+Not sure if this is a bug or user error. I'm trying to use git-annex on Windows 2008 R2, but it isn't working for me. Works fine on Linux. I have a local git repo and then added some binary files to annex. Then I used git annex sync --content to push ennex'd files up to git server. Then I can clone that repo and sync again to pull all the files down. On windows I just get error messages when I try to clone the repo and use annex to init or sync.
+
+git version: 1.8.0.msysgit.0
+git-annex version:
+git-annex version: 5.20150710-g8fd7052
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA TorrentP
+arser
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA51
+2 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook extern
+al
+local repository version: unknown
+supported repository version: 5
+upgrade supported from repository versions: 2 3 4
+
+If I try to init the cloned repo:
+
+$ git-annex init
+init  Unknown option: --literal-pathspecs
+usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
+           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
+           [-c name=value] [--help]
+           <command> [<args>]
+Unknown option: --literal-pathspecs
+usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
+           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
+           [-c name=value] [--help]
+           <command> [<args>]
+Unknown option: --literal-pathspecs
+usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
+           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
+           [-c name=value] [--help]
+           <command> [<args>]
+Unknown option: --literal-pathspecs
+usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
+           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
+           [-c name=value] [--help]
+           <command> [<args>]
+git-annex.exe: git [Param "config",Param "user.name",Param "user"] failed
+
+If I try to sync:
+
+$ git annex sync --content
+Unknown option: --literal-pathspecs
+usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
+           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
+           [-c name=value] [--help]
+           <command> [<args>]
+git-annex: First run: git-annex init
+
+What am I missing? I love the idea of annex and really need it for an urgent project I'm working on, but unfortunately I need to use it with Windows...in addition to Linux.
diff --git a/doc/forum/git-annex_fails_on_Windows/comment_1_451a2cdfa6f26e2bd319ebf4ce09da68._comment b/doc/forum/git-annex_fails_on_Windows/comment_1_451a2cdfa6f26e2bd319ebf4ce09da68._comment
new file mode 100644
index 0000000000..f429669017
--- /dev/null
+++ b/doc/forum/git-annex_fails_on_Windows/comment_1_451a2cdfa6f26e2bd319ebf4ce09da68._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-20T16:21:32Z"
+ content="""
+This is a mismatch between the version of git that git-annex was compiled
+to use, and the version of git that you have installed.
+
+You seem to have a git version older than 1.8.1.6 installed, since
+"--literal-pathspecs" was first added in that version. According
+to the [Windows installation instructions](http://git-annex.branchable.com/install/Windows),
+you need to install msysgit 1.9 to use git-annex.
+
+So, upgrade..
+"""]]
diff --git a/doc/forum/git-annex_fails_on_Windows/comment_2_57b4fd347f74b3536ab0f0a5d7709af8._comment b/doc/forum/git-annex_fails_on_Windows/comment_2_57b4fd347f74b3536ab0f0a5d7709af8._comment
new file mode 100644
index 0000000000..c10e85cd63
--- /dev/null
+++ b/doc/forum/git-annex_fails_on_Windows/comment_2_57b4fd347f74b3536ab0f0a5d7709af8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="fusionx86@2cab672ef75a8502e153ceb90177dde38985dba9"
+ nickname="fusionx86"
+ subject="comment 2"
+ date="2015-07-20T16:34:30Z"
+ content="""
+Thanks. I have another box with the latest version 1.9 which I thought I had tested this on. But I went back and tried again to find it does indeed work with a newer version. My fault for thinking I had tried this with 1.9. Thanks again...
+"""]]
diff --git a/doc/forum/git-annex_for_multiple_repositories___40__ssh_server__41__.mdwn b/doc/forum/git-annex_for_multiple_repositories___40__ssh_server__41__.mdwn
new file mode 100644
index 0000000000..9168bc5ef9
--- /dev/null
+++ b/doc/forum/git-annex_for_multiple_repositories___40__ssh_server__41__.mdwn
@@ -0,0 +1,73 @@
+For git-annex version 6 with 'thin'. [I want 1) not store date twice 2) to be able to have self-sufficient repository at different machines (i.e. not special remotes, which don't contain the git tree)].
+
+Say I've two machines A and B and the server S. 
+
+I setup a local repository on A:
+
+    git init
+    git-annex init $HOSTNAME --version=6
+    git config annex.thin true
+    git add .
+
+on S:
+
+    mkdir test
+    cd test
+    git init
+    git-annex init $HOSTNAME --version=6
+    git config annex.thin true
+
+on A:
+
+    git remote add S:~/test.git
+    git-annex sync --content
+
+on B:
+
+    git clone S:~/test.git
+    cd test
+    git-annex init $HOSTNAME --version=6
+    git config annex.thin true
+    git-annex sync
+
+(the reply)
+
+    ...
+    merge: refs/remotes/origin/master - not something we can merge
+
+    failed
+    push origin 
+    Counting objects: 6, done.
+    Delta compression using up to 4 threads.
+    Compressing objects: 100% (5/5), done.
+    Writing objects: 100% (6/6), 714 bytes | 0 bytes/s, done.
+    Total 6 (delta 1), reused 1 (delta 0)
+    remote: git-annex: unknown command post-receive
+    ...
+
+and the file contains only '/annex/objects/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'.
+
+Another time with another repo which I tried to sync from S at B, I got
+
+    $ git-annex sync --content
+    Initial commit
+
+    Untracked files: 
+(all my files untracked)
+
+    merge: refs/remotes/origin/master - not something we can merge
+
+    error: Untracked working tree file 'applications/algorithms/file.pdf' would be overwritten by merge.
+    fatal: read-tree failed
+    failed
+    git-annex: sync: 1 failed
+
+On walkthrough it's written how to sync with USB. How should one initialize remote repositories and use them e.g. as central repositories (though they should work probably not depending on 'central' or not they are)? 
+
+I've read a lot of manuals on git-annex and the forum; the questions here remain unanswered: 
+
+<http://git-annex.branchable.com/forum/git-annex_SSH_server_+_cloud_remote/>
+
+<http://git-annex.branchable.com/forum/Synchronize_two_latops_with_a_ssh_remote/>
+
+I hope this is a basic and popular usage of git-annex and that one can write a howto for that or at least answer this question.
diff --git a/doc/forum/git-annex_for_multiple_repositories___40__ssh_server__41__/comment_1_cb691410d2a9ef4393af5362000a768c._comment b/doc/forum/git-annex_for_multiple_repositories___40__ssh_server__41__/comment_1_cb691410d2a9ef4393af5362000a768c._comment
new file mode 100644
index 0000000000..dfe735e614
--- /dev/null
+++ b/doc/forum/git-annex_for_multiple_repositories___40__ssh_server__41__/comment_1_cb691410d2a9ef4393af5362000a768c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="ynikitenko"
+ avatar="http://cdn.libravatar.org/avatar/168d629704097ddc596f75ca32a687a3"
+ subject="Works"
+ date="2017-11-02T19:21:43Z"
+ content="""
+Surprisingly, these very same repositories work today. I don't know why this happened. Seems that the commands I wrote above work.
+
+I've also found a useful post with various git-annex usage cases (basically the one descibed in this post).
+
+[http://ewen.mcneill.gen.nz/blog/entry/2014-11-15-git-annex-to-manage-media-backups/](http://ewen.mcneill.gen.nz/blog/entry/2014-11-15-git-annex-to-manage-media-backups/)
+"""]]
diff --git a/doc/forum/git-annex_help_import_outdated__63__.mdwn b/doc/forum/git-annex_help_import_outdated__63__.mdwn
new file mode 100644
index 0000000000..6367fe1489
--- /dev/null
+++ b/doc/forum/git-annex_help_import_outdated__63__.mdwn
@@ -0,0 +1,13 @@
+Hi,
+
+I just saw that my installed version of git-annex is too old for:
+
+    git-annex import --reinject-duplicates [...]
+
+Thus, I downloaded the precompiled binary: git-annex-standalone-amd64.tar.gz	2017-05-10 16:19 	54M
+
+First of all, it works fine with this version. However, the "--reinject-duplicates" option is not shown, when calling:
+
+    ./git-annex help import  ## in ~/git-annex.linux/
+
+So, is the help page just outdated, or does git-annex help gets confused because I still have an older version of git-annex installed in the system?
diff --git a/doc/forum/git-annex_help_import_outdated__63__/comment_1_ada30e2fead4b5b8f5e53388f941eb07._comment b/doc/forum/git-annex_help_import_outdated__63__/comment_1_ada30e2fead4b5b8f5e53388f941eb07._comment
new file mode 100644
index 0000000000..b054e1520a
--- /dev/null
+++ b/doc/forum/git-annex_help_import_outdated__63__/comment_1_ada30e2fead4b5b8f5e53388f941eb07._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="comment 1"
+ date="2017-05-19T12:00:01Z"
+ content="""
+Okay, I did the same on a machine when git-annex was not installed before. Here everything works fine.
+
+So does git-annex help [...] open the locally installed manpages?
+
+I think it should show the help message that belongs to the running binary..
+
+"""]]
diff --git a/doc/forum/git-annex_help_import_outdated__63__/comment_2_ca898237f42af1205acab509e4d67d38._comment b/doc/forum/git-annex_help_import_outdated__63__/comment_2_ca898237f42af1205acab509e4d67d38._comment
new file mode 100644
index 0000000000..f5a9c8ae0a
--- /dev/null
+++ b/doc/forum/git-annex_help_import_outdated__63__/comment_2_ca898237f42af1205acab509e4d67d38._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-05-24T17:03:11Z"
+ content="""
+The man page is not outdated, see
+<https://git-annex.branchable.com/git-annex-import/>
+
+It seem that `git help`'s handling of MANPATH makes it not look
+first at the man pages from the standalone tarball in this case,
+and instead it displays the system man page.
+
+`git annex importfeed --help` will display the shorter documentation that's
+built into the binary.
+"""]]
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn
new file mode 100644
index 0000000000..e091460dcb
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn
@@ -0,0 +1 @@
+So, you provide ARM build. But you probably don't know that my NAS box runs OABI. No, you don't know, you can't know, and you shouldn't know. The only thing worth knowing is that writing great software in obscure and esoteric languages drastically limits its usage, impact, and collaboration around it. So, any idea of writing git-annex implementation in a sane, interpreted, "just works" language, e.g. Python? Thanks.
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment
new file mode 100644
index 0000000000..1cf6c84d6f
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 1"
+ date="2014-08-24T10:41:58Z"
+ content="""
+> git-annex implementation in a sane, interpreted, \"just works\" language, e.g. Python? Thanks.
+
+Good luck finding anything that works on OARM. Python itself does not support OABI:
+
+> This issue remains as \"won't fix\". ARM is supported; just OABI is not, and never will be. If anybody needs that, they will have to maintain their own fork of Python.
+
+(from <http://bugs.python.org/issue1762561#msg158974>)
+"""]]
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment
new file mode 100644
index 0000000000..32318b404a
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 2"
+ date="2014-08-24T11:04:21Z"
+ content="""
+Python on this system \"just works\". That's because Python is a project with a real community, so if one pundit said \"not supported\", dozen of people shrugged and typed \"make\", then packed up result for thousands to use.
+
+But don't get carried away by OABI, that was just one random example how deployment of git-annex is problematic. There're bigger issues like community involvement, being able to investigate and resolve issues, submit patches, bring new working ideas, make git-annex development and lifecycle sustainable, in the end - as vividly cared by the author.
+
+"""]]
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment
new file mode 100644
index 0000000000..8e613dd211
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 3"
+ date="2014-08-24T18:29:23Z"
+ content="""
+Sure, that's the plan. But first I'm doing my homework to understand how it got to that and how community copes with that. Maybe I don't get something and every open-source project should have a notice like: \"Installation from scratch. This is not recommended.\" (http://git-annex.branchable.com/install/). Interested in building software you run? Interested to help? Get lost, you won't get it. Am I surprised? Nope, I'm doing my homework and know where that Haskell thing came from. A piece of Microsoft was largely involved with it, so no surprise of such attitudes.
+
+Surely I'm not the only one who got jaundiced eye on git-annex: https://github.com/tv42/big : \"big is not like git-annex, because: it's not written in Haskell, so it might even work across distribution upgrades and platforms\". Certainly, stories of cvsup and unison, which are now where they should be - rest in peace, didn't help. So, once again, I'm interested to know how other people deal with this lack of proper compilation instructions, ability to get simple and easy tweaks, etc. - short of not using it, which seems to be a popular choice, despite all the git-annex coolness (I for one have been having its deployment in my queue fro half a year, instead of spending exactly a weekend to do tweaks I need and contribute them back).
+
+
+"""]]
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment
new file mode 100644
index 0000000000..8afa4c6fbc
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 4"
+ date="2014-08-24T18:31:25Z"
+ content="""
+Previous comment was written in response to a comment suggesting me to rewrite it in Python myself - which was then removed for some reason.
+
+"""]]
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment
new file mode 100644
index 0000000000..e58191a7f2
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ganwell"
+ ip="178.174.3.166"
+ subject="How I solved it..."
+ date="2014-08-26T23:03:09Z"
+ content="""
+I decided it was a bit harsh, so I removed comment. Here is how I solved problem:
+
+I have a server without much storage which runs the git-annex process, the data is stored on the NAS mounted via iSCSI. I never even thought of trying to compile git-annex on a NAS. I did things like that many years ago and it used to much time, whether the language was, common or not, didn't change much. Missing floating point units on the NAS killed performance of the programms I wanted to run anyways.
+"""]]
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_6_25ce5eddeb1b65aacd5d86e09c3719b8._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_6_25ce5eddeb1b65aacd5d86e09c3719b8._comment
new file mode 100644
index 0000000000..f9fa78e380
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_6_25ce5eddeb1b65aacd5d86e09c3719b8._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 6"
+ date="2014-09-16T19:19:00Z"
+ content="""
+There is too much negativity on this page, starting perhaps with its title.
+
+The \"this is not recommended\" is not because we don't want people to build git-annex from source. It's to try to dissuade users who just want to get git-annex installed, and who would be scared off by a transient build failure, from building from source, when there are many builds provided by Linux distributions, etc that would be better choices for them to get started. Hopefully the new page and new wording gets this across better: \"Experienced users should not find it too hard to build and install it from source.\"
+
+If someone wants to reimplement git-annex, or parts of it, I think that the existing documentation (eg [[internals]]) should get them most of the way there.
+
+"""]]
diff --git a/doc/forum/git-annex_memory_usage.mdwn b/doc/forum/git-annex_memory_usage.mdwn
new file mode 100644
index 0000000000..52868650c8
--- /dev/null
+++ b/doc/forum/git-annex_memory_usage.mdwn
@@ -0,0 +1,29 @@
+After running `git-annex add` for a bunch of large files, I saw this memory usage report (per the qacct command on an SGE cluster):
+
+[[!format sh """
+maxvmem      86.683G
+maxrss       40.617M
+maxpss       30.359M
+"""]]
+
+Is this memory usage expected?   (I also saw another git-annex job killed for exceeding memory usage, and saw the `top` command indicating high git-annex memory usage).   The number of files in the repo is small, and I assume `git-annex-add` doesn't need to read the whole file into memory, so what could explain the large `maxvmem` usage?
+
+
+[[!format sh """
+git annex version
+git-annex version: 10.20220127-gf616630
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+
+(rnaseq-04-env) [shlyakhi@ctchpcpx190 11:36 lewis19_ra]$ git config -l --global
+...
+annex.supportunlocked=false
+annex.gitaddtoannex=false
+
+"""]]
diff --git a/doc/forum/git-annex_memory_usage/comment_1_50753a133c200cdf6d855c65e6d4422b._comment b/doc/forum/git-annex_memory_usage/comment_1_50753a133c200cdf6d855c65e6d4422b._comment
new file mode 100644
index 0000000000..1c010a3810
--- /dev/null
+++ b/doc/forum/git-annex_memory_usage/comment_1_50753a133c200cdf6d855c65e6d4422b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-07T16:34:37Z"
+ content="""
+Is maxvmem what top would display as "VIRT"?
+
+Sometimes a few years ago, ghc started just mapping the entire available
+memory range, which makes it appear in VIRT that it's using the entire size
+of the system memory. Of course, the actual RSS is much lower. It appears to
+have been 40 mb for you.
+
+git-annex add can add files of arbitrary size without buffering them all in
+memory.
+"""]]
diff --git a/doc/forum/git-annex_move_does_not_appear_to_respect_numcopies.mdwn b/doc/forum/git-annex_move_does_not_appear_to_respect_numcopies.mdwn
new file mode 100644
index 0000000000..039ed005bb
--- /dev/null
+++ b/doc/forum/git-annex_move_does_not_appear_to_respect_numcopies.mdwn
@@ -0,0 +1,36 @@
+I have a git-annex repository checked out onto two separate drives (connected to the same machine). git-annex is aware of other copies of the repository on other drives that are not currently accessible. The local repository version is 5, and I'm running git-annex version 6.20170818. I have configured numcopies, and it displays correctly on both machines:
+
+```
+$ git annex numcopies
+2
+```
+
+However, I can't figure out how to use `git annex move` to match the behavior I'd expect. If I run:
+
+```
+$ git annex move my_file.txt --to otherdrive
+```
+
+it will copy `my_file.txt` to otherdrive and drop it from my primary drive, even though it's only aware of two copies. `git annex drop`, however, behaves as I'd expect.
+
+    $ git annex drop my_file.txt
+    drop my_file.txt (unsafe)
+        Could only verify the existence of 1 out of 2 necessary copies
+
+        Rather than dropping this file, try using: git annex move
+
+        (Use --force to override this check, or adjust numcopies.)
+
+It appears that `move` is equivalent to `git annex copy && git annex drop --force`, rather than `git annex copy && git annex drop`. That's surprising to me, but the message here implies that it's the intended behavior. In any case, I can't figure out which arguments to pass to `git-annex move` to simulate the behavior of `git annex copy && git annex drop` - that is, I want to move a file to a different drive (to free up space), but I do *not* want to drop it if I cannot ensure the correct number of copies exist. 
+
+
+Passing `--numcopies 2` doesn't do what I want either:
+
+```
+$ git annex move --numcopies 2 --to otherdrive my_file.txt 
+```
+
+will still copy the file to otherdrive and drop my local copy, leaving me with only one copy.
+
+
+Is there a mode for `git annex move` which behaves the desired way: moving a file to a different drive, while still ensuring that I don't end up with fewer than N verifiable copies (where N is the value already configured via `git-annex-numcopies`)?
diff --git a/doc/forum/git-annex_move_does_not_appear_to_respect_numcopies/comment_1_5dba0ff04c86c7b2697a0750fd1e4b5d._comment b/doc/forum/git-annex_move_does_not_appear_to_respect_numcopies/comment_1_5dba0ff04c86c7b2697a0750fd1e4b5d._comment
new file mode 100644
index 0000000000..52b85d16ac
--- /dev/null
+++ b/doc/forum/git-annex_move_does_not_appear_to_respect_numcopies/comment_1_5dba0ff04c86c7b2697a0750fd1e4b5d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2018-04-09T14:56:52Z"
+ content="""
+Well.. it actually says this in the source code for the move command:
+
+    - Note that unlike drop, this does not honor numcopies.
+    - A file's content can be moved even if there are insufficient copies to
+    - allow it to be dropped.
+
+So the behaviour seems to be known/intended. You told it to move the file, so it did.
+Perhaps it should output a warning if numcopies is not satisfied after the move?
+"""]]
diff --git a/doc/forum/git-annex_move_does_not_appear_to_respect_numcopies/comment_2_114cc3c9236ba930117cc14a0dddc3dd._comment b/doc/forum/git-annex_move_does_not_appear_to_respect_numcopies/comment_2_114cc3c9236ba930117cc14a0dddc3dd._comment
new file mode 100644
index 0000000000..dda1d00f07
--- /dev/null
+++ b/doc/forum/git-annex_move_does_not_appear_to_respect_numcopies/comment_2_114cc3c9236ba930117cc14a0dddc3dd._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-04-09T17:47:38Z"
+ content="""
+You're exactly right; the move command bypasses the normal numcopies check,
+in a way that is otherwise (AFAICR) only ever done when using --force.
+
+There's also no way to get exactly the behavior of a numcopies honoring
+move. As you note copy followed by drop has that behavior, but all the
+drops then happen at the end, which is clumsy. There's clearly a good case
+for an option to make move honor numcopies if it does not by default.
+I've added that as `git annex move --safe`.
+
+I feel that the divergence from everything else in honoring numcopies by
+default is important enough to treat as a bug, so I opened
+[[bugs/move_violates_numcopies]].
+"""]]
diff --git a/doc/forum/git-annex_on_OSX.mdwn b/doc/forum/git-annex_on_OSX.mdwn
new file mode 100644
index 0000000000..a00548366a
--- /dev/null
+++ b/doc/forum/git-annex_on_OSX.mdwn
@@ -0,0 +1 @@
+See [[install/OSX]].
diff --git a/doc/forum/git-annex_on_Samba_share.mdwn b/doc/forum/git-annex_on_Samba_share.mdwn
new file mode 100644
index 0000000000..0235820c06
--- /dev/null
+++ b/doc/forum/git-annex_on_Samba_share.mdwn
@@ -0,0 +1,9 @@
+I want to put my photos into a git-annex repository, syncing it with my girlfriends computer and our NAS.
+If possible, I'd like to be able to add files to the NAS and have them synced, so I guess a special remote doesn't work here.
+
+Unfortunately, git-annex doesn't run on my NAS directly (yet), so I thought of mounting the NAS with CIFS, and creating an annex there that syncs with the local ones.
+While this seems to work fine with one computer, I wonder what will happen if I mount the Samba share on my and my girlfriend's computer at the same time.
+
+In theory, the NAS supports Samba Unix extensions which includes POSIX locking, but a weird bug that prevents you from removing a named pipe from Samba, making git-annex init fail (sent a bug report to Synology). When I disable Unix extensions it works. It then detects a crippled file system though.
+
+Any thoughts?
diff --git a/doc/forum/git-annex_on_Samba_share/comment_1_3e9cfdf2c088e48c967ad08f79966742._comment b/doc/forum/git-annex_on_Samba_share/comment_1_3e9cfdf2c088e48c967ad08f79966742._comment
new file mode 100644
index 0000000000..dead483161
--- /dev/null
+++ b/doc/forum/git-annex_on_Samba_share/comment_1_3e9cfdf2c088e48c967ad08f79966742._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc"
+ nickname="Sören"
+ subject="Update"
+ date="2013-06-26T17:26:05Z"
+ content="""
+After reading trough this again, I'd like to rephrase my question.
+
+Is it safe if two independent assistants access the same repository at the same time (assuming locking works)?
+
+But, much more important, a big thanks for creating git-annex! I'm using it successfully to keep my files in sync at home and at work and I think it is a really amazing tool. So thanks for the hard work!
+"""]]
diff --git a/doc/forum/git-annex_on_Samba_share/comment_2_9d3df393b7b727653598453d94dd33db._comment b/doc/forum/git-annex_on_Samba_share/comment_2_9d3df393b7b727653598453d94dd33db._comment
new file mode 100644
index 0000000000..7b17cb2a2d
--- /dev/null
+++ b/doc/forum/git-annex_on_Samba_share/comment_2_9d3df393b7b727653598453d94dd33db._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 2"
+ date="2013-06-26T17:40:21Z"
+ content="""
+If you're asking if you can run two git-annex assistant programs inside the same repository at the same time, the answer is no. Assuming locking works (grin), the second program will detect the first is running and refuse to start.
+
+If your question is, can two or more git-annex assistant or other programs, running in separate repositories, access files in the same remote safely at the same time, the answer is yes! You can, for that matter, run multiple git-annex commands at the same time in the same repository, and they're also entirely safe, thanks to some locking it does.
+
+You should post your story to [[design/assistant/blog/day_288__success_stories]]!
+"""]]
diff --git a/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working.mdwn b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working.mdwn
new file mode 100644
index 0000000000..1a00326d79
--- /dev/null
+++ b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working.mdwn
@@ -0,0 +1,12 @@
+I am trying to get git-annex working on Ubuntu, specifically 13.04 and now 13.10 (I thought upgrading to a new distro. would fix the issue).
+
+I have tried:
+
+  * installing via apt-get install git-annex
+  * installing via cabal (full-build)
+
+Both times git-annex install successfully with no errors. I then start the webapp and create a repository (which git-annex creates successfully), I then add the folders and files I want it to sync. Git-annex finds the files and says it has began syncing them, but it never moves past the first batch of files it 'says' it had started syncing. I have waited 5+ hours at one point and nothing has changed. Also, the webapp is incredibly slow, it takes 15+ seconds to perform ANY action (such as saving options or viewing the logs). The issue definitely isn't my computer as I am using an high-end SSD, core i7, DDR3 RAM, etc... 
+
+Also the logs produce no errors of any kind and actually show git-annex adding files, most of the log entries say add 'filedirectory/filename.txt' as an example.
+
+I have gotten this to successfully work on Fedora, but Ubuntu (13.04/13.10) is having serious problems.
diff --git a/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_1_209956f3812450a43986d4ca5e647da6._comment b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_1_209956f3812450a43986d4ca5e647da6._comment
new file mode 100644
index 0000000000..2c4cbd2917
--- /dev/null
+++ b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_1_209956f3812450a43986d4ca5e647da6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 1"
+ date="2013-10-22T17:57:27Z"
+ content="""
+I don't really understand the problem you're describing. Is the problem with it uploading the files it's added to another remote? Does it sit there saying \"syncing with $remote\" forever? Or what?
+
+As to the webapp speed problem, it seems likely to me this is not related to CPU speed or load. It sounds rather like a DNS timeout problem, or an ipv6 to ipv4 fallback problem. Although since the URL to the webapp is http://127.0.0.1, it can't really be either of those..
+"""]]
diff --git a/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_3_12a58b8efe545e09b64760c87849839b._comment b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_3_12a58b8efe545e09b64760c87849839b._comment
new file mode 100644
index 0000000000..6e2d780ec8
--- /dev/null
+++ b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_3_12a58b8efe545e09b64760c87849839b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlEeLtIxQCU0qe4q5lbrZp8AcUSUUcRrkg"
+ nickname="Zach"
+ subject="comment 3"
+ date="2013-10-23T02:01:09Z"
+ content="""
+The problem is not with a remote annex. The issue I am having is git-annex never finishes syncing.
+
+Maybe a screenshot will help. http://i.imgur.com/9HSr8bl.png
+
+It never gets passed the Startup scan.
+"""]]
diff --git a/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_3_e0f7328603256f25c3be3706ecc9c76c._comment b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_3_e0f7328603256f25c3be3706ecc9c76c._comment
new file mode 100644
index 0000000000..413a807ad7
--- /dev/null
+++ b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_3_e0f7328603256f25c3be3706ecc9c76c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 3"
+ date="2013-10-23T15:27:40Z"
+ content="""
+Your screenshot shows git-annex is in the process of adding 6244 files. Depending on the size of those files, it could take some time to read their contents in order to calculate a checksum and add them to the repository. This would not normally take hours, unless your disk is very slow or the files are extremely big.
+
+You might get some useful information if you enable debugging (Configuration -> Preferences -> Enable debug logging) and look at the log.
+
+(This is not \"syncing\" btw. You have not set up any other repository for it to sync data with.)
+"""]]
diff --git a/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_4_6bb8e4522241556fb82784d9b834cbfe._comment b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_4_6bb8e4522241556fb82784d9b834cbfe._comment
new file mode 100644
index 0000000000..314d01e891
--- /dev/null
+++ b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_4_6bb8e4522241556fb82784d9b834cbfe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlEeLtIxQCU0qe4q5lbrZp8AcUSUUcRrkg"
+ nickname="Zach"
+ subject="comment 4"
+ date="2013-10-25T20:40:26Z"
+ content="""
+Everything works, it was just taking a while on one the folders; let it run overnight, and it was done.
+
+Thanks for the help!
+"""]]
diff --git a/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_5_89a5296b461d400b51006074a13a4560._comment b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_5_89a5296b461d400b51006074a13a4560._comment
new file mode 100644
index 0000000000..e6508fe54b
--- /dev/null
+++ b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_5_89a5296b461d400b51006074a13a4560._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 5"
+ date="2013-10-26T15:53:28Z"
+ content="""
+Can you confirm that the files in the directory it was adding were so large that it would normally take hours to checksum them all?
+"""]]
diff --git a/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_6_62daef4b4392c951b914a01b3effac11._comment b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_6_62daef4b4392c951b914a01b3effac11._comment
new file mode 100644
index 0000000000..4adcc568f5
--- /dev/null
+++ b/doc/forum/git-annex_on_Ubuntu_13.04_and_13.10_not_working/comment_6_62daef4b4392c951b914a01b3effac11._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlEeLtIxQCU0qe4q5lbrZp8AcUSUUcRrkg"
+ nickname="Zach"
+ subject="comment 6"
+ date="2013-10-26T21:05:07Z"
+ content="""
+The folder that took a while is actually only 291.5 MB total, containing 25,977 items in total. I know that is the folder that was having some issues because I committed each folder separately.
+"""]]
diff --git a/doc/forum/git-annex_on_archlinuxarm__44___armv6.mdwn b/doc/forum/git-annex_on_archlinuxarm__44___armv6.mdwn
new file mode 100644
index 0000000000..edfd0ad4eb
--- /dev/null
+++ b/doc/forum/git-annex_on_archlinuxarm__44___armv6.mdwn
@@ -0,0 +1,20 @@
+Hi!
+
+I can't get git-annex to run on my archlinuxARM sytem. It fails with
+
+    $ git annex test
+    error: git-annex died of signal 11
+
+ Its a RaspberryPi (model B I think) so its an ARM11 (armv6h if I'm not mistaken). I use archlinuxarm because I am familiar with the distribution and you can have a very lean system. There is a very crude package for git-annex arm and armv7 that is build like this: https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/git-annex/PKGBUILD . Crude, because it just takes the debian package, changes the version of libraries where apropriate and packs it as archlinux package. Two problems: 1) It's not been tested on armv6. 2) The 4.20130417 version does not exist anymore on the debian mirrors.
+
+1. The debian package is not marked as armv5 or armv7 specific and is runs on the RaspberryPi with Raspbian (but in an pretty old version if I remember correctly). So I would have imagined it runs on armv6h in general.\\
+2. I just did the same magic as in the linked PKGBUILD with a more current version to build the package but it still crashes. Can I get the old version anywhere to check if it works with that? 
+
+
+Cheers,
+  Hannes
+
+Background for whoever's interested :)
+I tried to set up a RaspberryPi to manage my files, contacts and calendars. That shouts out loud for owncloud because of its convenience (caldav, carddav, webdav and a nice interface bundled together). However, compared to git-annex owncloud is unbearably slow (on an RaspberryPi) and lacks git-annex's easy way to keep your files sorted even if you don't have them on your local disk.
+
+For these reasons I tried to install a hybrid git-annex/owncloud system. There, basically, the files are served by owncloud but at the same time also managed (and served) by git-annex (+ssh). As far as I can see that should not have any noticeable side effects in my use case (mostly single user). I have some external hard drives connected to the RaspberryPi of which I will just symlink the appropriate folders to the owncloud 'files' folder. This way I can also just take the drives with me and still have the same (UUID) git annex repository on them. Any comments?
diff --git a/doc/forum/git-annex_on_archlinuxarm__44___armv6/comment_1_88fa644df8614c2db0d092b3eb1d3156._comment b/doc/forum/git-annex_on_archlinuxarm__44___armv6/comment_1_88fa644df8614c2db0d092b3eb1d3156._comment
new file mode 100644
index 0000000000..516ec0017d
--- /dev/null
+++ b/doc/forum/git-annex_on_archlinuxarm__44___armv6/comment_1_88fa644df8614c2db0d092b3eb1d3156._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.51"
+ subject="comment 1"
+ date="2013-09-12T16:56:50Z"
+ content="""
+You seem to be trying to take a binary built for one distribution with one CPU architecture and use it on another distribution on another CPU architecture. It's not very susprising that this does not work.
+
+Compiling git-annex from source for your particular architecture and distribution should not be difficult.
+"""]]
diff --git a/doc/forum/git-annex_on_archlinuxarm__44___armv6/comment_2_b25ca7520ff7e339ec887a379d5100ee._comment b/doc/forum/git-annex_on_archlinuxarm__44___armv6/comment_2_b25ca7520ff7e339ec887a379d5100ee._comment
new file mode 100644
index 0000000000..c0a13cfa46
--- /dev/null
+++ b/doc/forum/git-annex_on_archlinuxarm__44___armv6/comment_2_b25ca7520ff7e339ec887a379d5100ee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNvX8PQVP5sLzQ78sKpB6VeH3Fu8HvZ5g"
+ nickname="Jeff"
+ subject="comment 2"
+ date="2014-01-26T04:29:09Z"
+ content="""
+I've actually been having a pretty tough time with it. Could you point me in the right direction? There's not any Haskell infrastructure on Arch ARM yet so I'd either be compiling the whole Haskell Platform or cross-compiling on x86_64 right?
+Thanks
+Jeff
+"""]]
diff --git a/doc/forum/git-annex_on_archlinuxarm__44___armv6/comment_3_eda0e90c1285396b1ab20ecc04ea6e29._comment b/doc/forum/git-annex_on_archlinuxarm__44___armv6/comment_3_eda0e90c1285396b1ab20ecc04ea6e29._comment
new file mode 100644
index 0000000000..5c8f96ac32
--- /dev/null
+++ b/doc/forum/git-annex_on_archlinuxarm__44___armv6/comment_3_eda0e90c1285396b1ab20ecc04ea6e29._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.46"
+ subject="comment 3"
+ date="2014-01-26T17:59:52Z"
+ content="""
+Well, yes, the first step will be getting a ghc for the architecture, and then it's just a matter of following [[install/cabal]]
+"""]]
diff --git a/doc/forum/git-annex_on_openSUSE.mdwn b/doc/forum/git-annex_on_openSUSE.mdwn
new file mode 100644
index 0000000000..08c3cd22fc
--- /dev/null
+++ b/doc/forum/git-annex_on_openSUSE.mdwn
@@ -0,0 +1,20 @@
+I run into some problems installing git-annex on openSuSE:
+
+1) cabal install ends up with the failure:
+
+-->>> ExitFailure 1 network-protocol-xmpp-0.4.6 depends on gnuidn-0.2.1 which failed to install.
+
+2) with the tarball the files are not synchronized, only linked
+
+Here the link to the discussion in a suseforum:
+
+https://forums.opensuse.org/showthread.php/506098-How-to-install-git-annex-on-13-1-2
+
+It would be great to see git-annex in the opensuse repos,
+maybe via the open build service, https://build.opensuse.org
+
+Are there other ways to install git-annex on opensuse successfully?
+
+Thanks in advance
+
+saneP
diff --git a/doc/forum/git-annex_on_openSUSE/comment_1_97313a8a7fc7f558b5956989442a0f0b._comment b/doc/forum/git-annex_on_openSUSE/comment_1_97313a8a7fc7f558b5956989442a0f0b._comment
new file mode 100644
index 0000000000..9a000b817a
--- /dev/null
+++ b/doc/forum/git-annex_on_openSUSE/comment_1_97313a8a7fc7f558b5956989442a0f0b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-27T20:53:23Z"
+ content="""
+To install gnuidn, you need to install the libidn C library.
+
+That is only needed for XMPP support. So you can avoid it with:
+cabal configure -f-XMPP
+
+There is already an openSUSE build, afaik.
+<https://git-annex.brachable.com/install/openSUSE/>
+"""]]
diff --git a/doc/forum/git-annex_on_openSUSE/comment_2_bbe6925ca465d13b050639c18abcd890._comment b/doc/forum/git-annex_on_openSUSE/comment_2_bbe6925ca465d13b050639c18abcd890._comment
new file mode 100644
index 0000000000..fe6fa73f20
--- /dev/null
+++ b/doc/forum/git-annex_on_openSUSE/comment_2_bbe6925ca465d13b050639c18abcd890._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="saneP"
+ subject="comment 2"
+ date="2015-03-28T14:05:17Z"
+ content="""
+No, there is no adequate package. Maybe it has been removed..
+
+"""]]
diff --git a/doc/forum/git-annex_on_osx_10.9.1_just_crashes__47__closes__47__doesn__39__t_run_on_launch.mdwn b/doc/forum/git-annex_on_osx_10.9.1_just_crashes__47__closes__47__doesn__39__t_run_on_launch.mdwn
new file mode 100644
index 0000000000..c5d4c40bcf
--- /dev/null
+++ b/doc/forum/git-annex_on_osx_10.9.1_just_crashes__47__closes__47__doesn__39__t_run_on_launch.mdwn
@@ -0,0 +1,7 @@
+on a Mac OSX 10.9.1 client I would like to try out git-annex.  
+
+I download the latest Mavericks build, extract from the .dmg and it just does not run.  I open the program, one "bounce" on the dock and it is gone, nothing happens.  
+
+I sadly do not have another OSX client to try it on.  But nothing shows in the Console.app or anything.
+
+Am I missing something?
diff --git a/doc/forum/git-annex_on_osx_10.9.1_just_crashes__47__closes__47__doesn__39__t_run_on_launch/comment_1_a47174f8438bfaa42fb8067bca77bf4c._comment b/doc/forum/git-annex_on_osx_10.9.1_just_crashes__47__closes__47__doesn__39__t_run_on_launch/comment_1_a47174f8438bfaa42fb8067bca77bf4c._comment
new file mode 100644
index 0000000000..3c9361cbdc
--- /dev/null
+++ b/doc/forum/git-annex_on_osx_10.9.1_just_crashes__47__closes__47__doesn__39__t_run_on_launch/comment_1_a47174f8438bfaa42fb8067bca77bf4c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.146"
+ subject="comment 1"
+ date="2014-03-05T22:30:00Z"
+ content="""
+The thing to do is to try to start git-annex from the command line in a terminal. This should get an error message that will help find out what's going wrong.
+"""]]
diff --git a/doc/forum/git-annex_on_osx_10.9.1_just_crashes__47__closes__47__doesn__39__t_run_on_launch/comment_2_567bb460cec7cd2135386acf4e7dceb4._comment b/doc/forum/git-annex_on_osx_10.9.1_just_crashes__47__closes__47__doesn__39__t_run_on_launch/comment_2_567bb460cec7cd2135386acf4e7dceb4._comment
new file mode 100644
index 0000000000..21141e45e7
--- /dev/null
+++ b/doc/forum/git-annex_on_osx_10.9.1_just_crashes__47__closes__47__doesn__39__t_run_on_launch/comment_2_567bb460cec7cd2135386acf4e7dceb4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.146"
+ subject="comment 2"
+ date="2014-03-07T15:17:50Z"
+ content="""
+Probably this was because the OSX build was missing the webapp. Fixed now.
+"""]]
diff --git a/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch.mdwn b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch.mdwn
new file mode 100644
index 0000000000..5d001bd937
--- /dev/null
+++ b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch.mdwn
@@ -0,0 +1 @@
+When running multiple git-annex commands in parallel on different [[worktrees|tips/Using_git-worktree_with_annex]] linked to the same repo, they all may be writing to the git-annex branch.  Could this potentially lead to errors/undefined behaviors, or is git-annex designed with this usage in mind?
diff --git a/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_1_3ece379be6645e75eff0d0acdc0a832f._comment b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_1_3ece379be6645e75eff0d0acdc0a832f._comment
new file mode 100644
index 0000000000..7ffa293e16
--- /dev/null
+++ b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_1_3ece379be6645e75eff0d0acdc0a832f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-05-06T17:58:45Z"
+ content="""
+git-annex is fully safe both with parallel --jobs and with multiple
+git-annex programs run at the same time. It makes extensive use of locking.
+
+(This assumes that git is also safe when multiple git jobs are running;
+ttbomk it is, although its locking around the index file is not very
+fine-grained.)
+"""]]
diff --git a/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_2_5aa79212878820270d9148275829727b._comment b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_2_5aa79212878820270d9148275829727b._comment
new file mode 100644
index 0000000000..b0afc05cce
--- /dev/null
+++ b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_2_5aa79212878820270d9148275829727b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-05-06T18:41:26Z"
+ content="""
+As far as different worktrees go, git-annex mostly doesn't distinguish
+between multiple worktrees, at the level of annexed content and the
+git-annex branch there is no difference between one worktree and another.
+So it will be just the same as running multiple git-annex commands in the
+same worktree.
+"""]]
diff --git a/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_2_8a46c0146f81d6d6147d8cfdc1277595._comment b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_2_8a46c0146f81d6d6147d8cfdc1277595._comment
new file mode 100644
index 0000000000..bf652897f1
--- /dev/null
+++ b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_2_8a46c0146f81d6d6147d8cfdc1277595._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-05-06T18:39:07Z"
+ content="""
+Thanks!
+
+I do see some failures during concurrent usage, with the error message
+
+fatal: Unable to create '/data/ilya-work/benchmarks/viral-ngs-benchmarks/.git/index.lock': File exists.
+
+Another git process seems to be running in this repository, e.g.
+an editor opened by 'git commit'. Please make sure all processes
+are terminated then try again. If it still fails, a git process
+may have crashed in this repository earlier:
+remove the file manually to continue.
+
+It seems that git does not have a built-in wait for the index lock to be released:
+<https://stackoverflow.com/questions/36208630/is-there-a-way-to-make-git-automatically-retry-commands-if-index-lock-exists>
+Maybe, for greater robustness, git-annex could add a wait for this, when it calls git.
+"""]]
diff --git a/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_4_aec9399cdf7b11011c9b577a6800b490._comment b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_4_aec9399cdf7b11011c9b577a6800b490._comment
new file mode 100644
index 0000000000..907f4f806b
--- /dev/null
+++ b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_4_aec9399cdf7b11011c9b577a6800b490._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-05-06T18:46:21Z"
+ content="""
+[[todo/only_allow_one_git_queue_to_be_flushed_at_a_time]]
+"""]]
diff --git a/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_5_aa4091341c7a067b46b57dea9dd02c22._comment b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_5_aa4091341c7a067b46b57dea9dd02c22._comment
new file mode 100644
index 0000000000..1f29b5485a
--- /dev/null
+++ b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_5_aa4091341c7a067b46b57dea9dd02c22._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 5"
+ date="2019-05-06T20:24:14Z"
+ content="""
+Thanks a lot!  With this fix, I might not even need the multiple worktrees.
+"""]]
diff --git a/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_6_7d6d0da2243967b9660d8222c546112d._comment b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_6_7d6d0da2243967b9660d8222c546112d._comment
new file mode 100644
index 0000000000..7558377b49
--- /dev/null
+++ b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_6_7d6d0da2243967b9660d8222c546112d._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 6"
+ date="2019-05-06T22:38:43Z"
+ content="""
+During parallel running of git-annex commands, I also get errors like
+
+git-annex: .git/annex/othertmp/inge59014-3: getFileStatus: does not exist (No such file or directory)
+failed
+
+git-annex: .git/annex/othertmp/ingest-assemble_den59014-8: removeLink: does not exist (No such file or directory)
+failed
+
+Is this also now fixed by [[todo/only_allow_one_git_queue_to_be_flushed_at_a_time]], or is it a separate issue?
+
+Also, is it correct that linked worktrees must be on the same filesystem as the main worktree, when using git-annex, because the linked worktrees must be on the same filesystem as .git/annex/othertmp ?
+"""]]
diff --git a/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_7_ae5fb82005702e9b5ed14fa37f80a91a._comment b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_7_ae5fb82005702e9b5ed14fa37f80a91a._comment
new file mode 100644
index 0000000000..361b575fda
--- /dev/null
+++ b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_7_ae5fb82005702e9b5ed14fa37f80a91a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2019-05-07T15:39:54Z"
+ content="""
+[[bugs/withOtherTmp_file_escapes]]
+
+I don't think you need to use the same filesystem, but it will be slower
+when git-annex can't hard link and has to fall back to copying.
+"""]]
diff --git a/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_8_b0bc7c10d97a03497354aef2b011e1f1._comment b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_8_b0bc7c10d97a03497354aef2b011e1f1._comment
new file mode 100644
index 0000000000..0c9879243f
--- /dev/null
+++ b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_8_b0bc7c10d97a03497354aef2b011e1f1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 8"
+ date="2019-05-07T15:50:52Z"
+ content="""
+\"I don't think you need to use the same filesystem\" -- I was thinking of the comment in [[internals]] that said, \".git/annex/othertmp has to be on the same filesystem as the work tree and git repository\".  Is that comment outdated?
+"""]]
diff --git a/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_9_deb88db3c97645b1aa180813401fa436._comment b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_9_deb88db3c97645b1aa180813401fa436._comment
new file mode 100644
index 0000000000..1870dd86f0
--- /dev/null
+++ b/doc/forum/git-annex_parallel_invocation_and_the_git-annex_branch/comment_9_deb88db3c97645b1aa180813401fa436._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2019-05-07T16:05:00Z"
+ content="""
+I think that has a good chance of being out of date; I can't think of any
+use of that temp directory that doesn't gracefully handle 
+the case of a hard link into it failing.
+"""]]
diff --git a/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram.mdwn b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram.mdwn
new file mode 100644
index 0000000000..82ca06b85f
--- /dev/null
+++ b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram.mdwn
@@ -0,0 +1,24 @@
+Hi all,
+
+git-annex basically renders my repository unmanageble.  What is the
+best and save (!) way to recover?
+
+Here is my situation:
+
+I have a fairly large repository with ~8000 managed files taking about
+65GB of disk space.
+
+git-annex worked well there.  But some programs choke on the
+symlinks.  So, I converted the repository to direct mode.  The
+transition worked well.
+
+Now git status reports a type change for the ~8000 files.
+
+But as soon as I run
+
+    git commit -m "typechange" even-only-one-of-the-files
+
+the process `git-annex pre-commit .` eats 3.5GB of ram, where I
+usually kill it, as I only have 4GB of ram....
+
+-- Andreas
diff --git a/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_1_ff16c7932b60b85c744bafc48bb040e4._comment b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_1_ff16c7932b60b85c744bafc48bb040e4._comment
new file mode 100644
index 0000000000..23e5e79e88
--- /dev/null
+++ b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_1_ff16c7932b60b85c744bafc48bb040e4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 1"
+ date="2013-09-18T07:19:49Z"
+ content="""
+AFAIK in direct mode you are not supposed to commit you just run
+
+    git annex sync
+
+and it will commit if files are changed. you only add new files annexed files are handled by sync
+
+"""]]
diff --git a/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_2_5599cddf579d18f70cab6e48d04ae99d._comment b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_2_5599cddf579d18f70cab6e48d04ae99d._comment
new file mode 100644
index 0000000000..337c1627fb
--- /dev/null
+++ b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_2_5599cddf579d18f70cab6e48d04ae99d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="ringprince"
+ ip="134.76.140.110"
+ subject="comment 2"
+ date="2013-09-18T12:27:38Z"
+ content="""
+Hi Hamza,
+
+thanks for that comment.  I thought `git annex sync` is just a wrapper around `git commit -a` (among others).
+
+Using `git annex sync` does not help, as it just means that now `git annex sync` eats all my memory until swapping starts.
+"""]]
diff --git a/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_3_412941e9385f63153b23695641e71deb._comment b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_3_412941e9385f63153b23695641e71deb._comment
new file mode 100644
index 0000000000..6349500caa
--- /dev/null
+++ b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_3_412941e9385f63153b23695641e71deb._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.105"
+ subject="comment 3"
+ date="2013-09-19T18:49:05Z"
+ content="""
+git-annex sync is a wrapper around git commit. But not -a! git commit -a will stage every one of your large files directly into the git repository, wasting much memory and worse, disk space. It is ok to use `git commit` or `git commit --staged` in direct mode after eg `git annex add`. But not `git commit -a` or `git commit even-only-one-of-the-files`. It's best to just use `git annex sync` rather than `git commit`, as it avoids finger memory causing you to run the wrong type of commit command. Please see [[direct_mode]] for the details.
+
+I was able to make pre-commit take a lot of memory by committing a 1 gb file directly to git. git-annex was buffering the whole file content in memory
+due to not thinking to check first if it was a symlink. I have fixed that bug.
+
+So I think you must have run that command you showed, and you now have a lot of data stored in your git repository that you had meant git-annex to handle. You might need to use git-filter-branch to remove it..
+
+This kind of thing is why I need to write the [[todo/direct_mode_guard]].
+"""]]
diff --git a/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_4_112ad140d9006c530db2121bec24de30._comment b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_4_112ad140d9006c530db2121bec24de30._comment
new file mode 100644
index 0000000000..e5ebfa3281
--- /dev/null
+++ b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_4_112ad140d9006c530db2121bec24de30._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="ringprince"
+ ip="134.76.140.110"
+ subject="comment 4"
+ date="2013-09-19T20:06:39Z"
+ content="""
+Let me ask a simple question:  All files are regular files (no symlinks).  If I can live with loosing the history, is it save to just remove the .git directory and start over?  Or do I risk anything?
+
+PS: .git is about 7GB
+"""]]
diff --git a/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_5_9178023b95683a649355f291165a1467._comment b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_5_9178023b95683a649355f291165a1467._comment
new file mode 100644
index 0000000000..7f5047ddd6
--- /dev/null
+++ b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_5_9178023b95683a649355f291165a1467._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.105"
+ subject="comment 5"
+ date="2013-09-19T20:57:18Z"
+ content="""
+You can safely delete the git repository in the situation you describe. Better yet: Tar it up, and check the tarball into git-annex with the other files when you start over. :) Then if I'm wrong, you still have that data.
+"""]]
diff --git a/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_6_9251203421c1c3c3aed7828c4b97ecb8._comment b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_6_9251203421c1c3c3aed7828c4b97ecb8._comment
new file mode 100644
index 0000000000..ebb378e959
--- /dev/null
+++ b/doc/forum/git-annex_pre-commit_eats_all_my_4GB_of_ram/comment_6_9251203421c1c3c3aed7828c4b97ecb8._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="ringprince"
+ ip="134.76.140.110"
+ subject="comment 6"
+ date="2013-09-19T22:27:38Z"
+ content="""
+Thanks a bunch!  That is what I did now.  Seems good.
+
+May I additionally suggest a change in the man page of git annex?  There I read
+
+    sync [remote ...]
+              ...
+              The sync process involves first committing all local changes (git commit -a), ...
+              ...
+
+which made me think, I could do `git commit -a` manually as well.
+"""]]
diff --git a/doc/forum/git-annex_s3_failure.mdwn b/doc/forum/git-annex_s3_failure.mdwn
new file mode 100644
index 0000000000..dc93f5182e
--- /dev/null
+++ b/doc/forum/git-annex_s3_failure.mdwn
@@ -0,0 +1,33 @@
+Hello,
+
+I have a repository that is set up to upload files to S3.
+
+I am testing the idea of fetching files by doing the following
+
+```
+mkdir tmp
+
+cd tmp
+
+git clone git@github.com:MyUserName/MyRepo.git
+
+git annex enableremote mys3
+
+git annex get .
+
+```
+
+I get error messages such as:
+
+```
+get files/a-tutorial-on-the-universality-and-expressiveness-of-fold.pdf (not available)                                                                
+  Maybe add some of these git remotes (git remote add ...):                
+        942f7e73-262b-4850-8a2b-ccb7c0e5666d -- <ommitted>
+                                                                                                                                                       
+  (Note that these git remotes have annex-ignore set: origin)       
+failed 
+```
+
+This happens even though the S3 environmental variables are properly set.
+
+Thank you for your help! This program seems awesome - I just need to figure out how to use it. 
diff --git a/doc/forum/git-annex_s3_failure/comment_1_099023ae32a6a3417cc9c8bdcce9a89d._comment b/doc/forum/git-annex_s3_failure/comment_1_099023ae32a6a3417cc9c8bdcce9a89d._comment
new file mode 100644
index 0000000000..25aa12efc0
--- /dev/null
+++ b/doc/forum/git-annex_s3_failure/comment_1_099023ae32a6a3417cc9c8bdcce9a89d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Steven"
+ avatar="http://cdn.libravatar.org/avatar/bc0cef8062401f1b84db320cb56c28bd"
+ subject="Using the --content flag"
+ date="2021-05-29T00:14:30Z"
+ content="""
+It seems like I had to use the following command:
+
+```
+git annex sync --content
+```
+
+After this, I saw all the files available. 
+
+I expected `git annex get .` to do that, but I might simply have the wrong mental model of all of this. 
+"""]]
diff --git a/doc/forum/git-annex_s3_failure/comment_2_c869b85bb2bea4a7a99e107f4a3cfb0f._comment b/doc/forum/git-annex_s3_failure/comment_2_c869b85bb2bea4a7a99e107f4a3cfb0f._comment
new file mode 100644
index 0000000000..fbf870f414
--- /dev/null
+++ b/doc/forum/git-annex_s3_failure/comment_2_c869b85bb2bea4a7a99e107f4a3cfb0f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 2"
+ date="2021-05-29T12:40:56Z"
+ content="""
+It could be that you have files that are not actually present in the mys3 remote. `git annex sync --content` only gets files that are present in connected repos, so it doesn't report a error if it can't get a particular file. `git annex get .` want's to actually get all files and reports errors for the files it can't get.
+"""]]
diff --git a/doc/forum/git-annex_s3_failure/comment_3_b9e52fe4d14104398d57a6bcc7f2deaf._comment b/doc/forum/git-annex_s3_failure/comment_3_b9e52fe4d14104398d57a6bcc7f2deaf._comment
new file mode 100644
index 0000000000..9c3c71bc5a
--- /dev/null
+++ b/doc/forum/git-annex_s3_failure/comment_3_b9e52fe4d14104398d57a6bcc7f2deaf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Steven"
+ avatar="http://cdn.libravatar.org/avatar/bc0cef8062401f1b84db320cb56c28bd"
+ subject="comment 3"
+ date="2021-05-29T14:06:25Z"
+ content="""
+Interesting explanation. I am not sure what files it was trying to get that were not on s3. Everything I have done is with an eye towards having all of the files in s3, but it is always possible I got something wrong.
+
+Thank you. 
+"""]]
diff --git a/doc/forum/git-annex_sync_content_available_from_which_version__63__.mdwn b/doc/forum/git-annex_sync_content_available_from_which_version__63__.mdwn
new file mode 100644
index 0000000000..511a0ba0ca
--- /dev/null
+++ b/doc/forum/git-annex_sync_content_available_from_which_version__63__.mdwn
@@ -0,0 +1,12 @@
+Hi,
+
+I'm on a centos 6.4 64bits & installed git-annex
+version : git-annex-3.20120522-2.1.el6.x86_64
+
+From my understanding of the help page, I should be able to sync content with :
+
+git annex sync --content
+
+but it is not recognized. The help tells me I may be able to use "get" but I'm unclear how...
+
+Thanks for any help
diff --git a/doc/forum/git-annex_sync_content_available_from_which_version__63__/comment_1_104e1b7e7643844f221f85dcbe9c9c4b._comment b/doc/forum/git-annex_sync_content_available_from_which_version__63__/comment_1_104e1b7e7643844f221f85dcbe9c9c4b._comment
new file mode 100644
index 0000000000..3b7967e32d
--- /dev/null
+++ b/doc/forum/git-annex_sync_content_available_from_which_version__63__/comment_1_104e1b7e7643844f221f85dcbe9c9c4b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-06-05T17:32:33Z"
+ content="""
+This feature was added in 5.20140210, which can be easily seen by reading the changelog.
+"""]]
diff --git a/doc/forum/git-annex_sync_fails_in_repo1_but_not_in_repo2.mdwn b/doc/forum/git-annex_sync_fails_in_repo1_but_not_in_repo2.mdwn
new file mode 100644
index 0000000000..222befd167
--- /dev/null
+++ b/doc/forum/git-annex_sync_fails_in_repo1_but_not_in_repo2.mdwn
@@ -0,0 +1,45 @@
+Hello,
+
+I am using two repos in direct mode that are connected via ssh.
+Syncing fails in one direction but works in the other, I don't understand how to fix that.
+
+## repo2 -> repo1 works:
+
+    server$ git-annex sync
+    commit  ok
+    pull repo1 
+    From client:~/media/img/db
+     + be62780...2d74673 master     -> client/master  (forced update)
+     + be62780...2d74673 synced/master -> client/synced/master  (forced update)
+    ok
+    push repo1 
+    Total 0 (delta 0), reused 0 (delta 0)
+    To client:~/media/img/db
+       2d74673..be62780  annex/direct/master -> synced/master
+    ok
+    server$ git-annex status
+    ? .t/repo
+    ? .t/tmprepo0
+    server$
+
+## repo1 -> repo2 fails:
+
+    client$ git-annex sync
+    commit  ok
+    pull repo2 
+    
+    fatal: You have not concluded your merge (MERGE_HEAD exists).
+    Please, commit your changes before you merge.
+    
+    fatal: You have not concluded your merge (MERGE_HEAD exists).
+    Please, commit your changes before you merge.
+    failed
+    git-annex: sync: 1 failed
+    client$ git-annex status
+    client$
+
+Hopefully somebody knows how to fix that.
+
+Regards,
+
+Felix
diff --git a/doc/forum/git-annex_sync_fails_in_repo1_but_not_in_repo2/comment_1_5cca2fbce3db1c691f43e43f9343f9bd._comment b/doc/forum/git-annex_sync_fails_in_repo1_but_not_in_repo2/comment_1_5cca2fbce3db1c691f43e43f9343f9bd._comment
new file mode 100644
index 0000000000..8f2bd5712a
--- /dev/null
+++ b/doc/forum/git-annex_sync_fails_in_repo1_but_not_in_repo2/comment_1_5cca2fbce3db1c691f43e43f9343f9bd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-01-15T18:19:02Z"
+ content="""
+It sounds like deleting `.git/MERGE_HEAD` might fix the problem in the repo
+with the problem.
+
+I don't know how you could have gotten the repository into that state..
+"""]]
diff --git a/doc/forum/git-annex_sync_fails_in_repo1_but_not_in_repo2/comment_2_1dfeb722edd54c68b4220d00c0a175e5._comment b/doc/forum/git-annex_sync_fails_in_repo1_but_not_in_repo2/comment_2_1dfeb722edd54c68b4220d00c0a175e5._comment
new file mode 100644
index 0000000000..b40f223947
--- /dev/null
+++ b/doc/forum/git-annex_sync_fails_in_repo1_but_not_in_repo2/comment_2_1dfeb722edd54c68b4220d00c0a175e5._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="felix.hagemann@b76e9ea0928cf33dacffc37ec3dbecf33171a8a5"
+ nickname="felix.hagemann"
+ avatar="http://cdn.libravatar.org/avatar/1f7e89860de517a494f35ebfb385288e"
+ subject="comment 2"
+ date="2018-01-16T19:26:03Z"
+ content="""
+Deleting `.git/MERGE_HEAD` sort of fixed the problem:
+
+        client$ git-annex sync
+        commit  ok
+        pull repo2 
+
+        Already up to date!
+        Automatic merge went well; stopped before committing as requested
+
+        error: duplicate parent be6278073504cfd19400c100b1871ba4324f55db ignored
+        ok
+        push repo2 
+        Counting objects: 1, done.
+        Writing objects: 100% (1/1), 209 bytes | 209.00 KiB/s, done.
+        Total 1 (delta 0), reused 0 (delta 0)
+        To repo2:/media/srv/img
+           be62780735..020ce83c1f  annex/direct/master -> synced/master
+        ok
+        client$ git-annex sync
+        commit  ok
+        pull repo2 
+        ok
+        client$
+
+Thanks!
+
+I have no idea how the repo got in that state. Syncing started to fail some time early December and for a few months I've been only using `git-annex assistant` and `git-annex webapp`.
+"""]]
diff --git a/doc/forum/git-annex_sync_here.mdwn b/doc/forum/git-annex_sync_here.mdwn
new file mode 100644
index 0000000000..9aa91ed2f4
--- /dev/null
+++ b/doc/forum/git-annex_sync_here.mdwn
@@ -0,0 +1,19 @@
+Hello,
+
+git-annex does a lot of convenient stuff, also locally. With git-annex sync [remote-name] the synchronization can be restricted to a single remote.
+
+However, I think being able to restrict sync to no remote at all, only doing the local stuff, would be helpful.
+
+The natural syntax for me would be git-annex sync here. But it says:
+
+    $ git-annex sync here
+    commit  ok
+    git-annex: there is no available git remote named "here"
+
+I think a workaround would be to do:
+
+    $ git-annex sync --no-push --no-pull
+
+Is that correct?
+
+Still, I think "git-annex sync here" would be a convenient shortcut.
diff --git a/doc/forum/git-annex_sync_here/comment_1_3ebef27614bd72b38404c1940007e68c._comment b/doc/forum/git-annex_sync_here/comment_1_3ebef27614bd72b38404c1940007e68c._comment
new file mode 100644
index 0000000000..7003ce5a4f
--- /dev/null
+++ b/doc/forum/git-annex_sync_here/comment_1_3ebef27614bd72b38404c1940007e68c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-05-24T17:06:29Z"
+ content="""
+Well, that does the same thing as `git commit -a`, so I don't see
+any benefit complicating the command with additional syntax.
+"""]]
diff --git a/doc/forum/git-annex_sync_here/comment_2_1b0543443759202ec6a85a26088ddb43._comment b/doc/forum/git-annex_sync_here/comment_2_1b0543443759202ec6a85a26088ddb43._comment
new file mode 100644
index 0000000000..ba3ff18cea
--- /dev/null
+++ b/doc/forum/git-annex_sync_here/comment_2_1b0543443759202ec6a85a26088ddb43._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="comment 2"
+ date="2017-05-25T12:47:18Z"
+ content="""
+git-annex sync does more than that. Especially merging the synced branches and, thus, showing files that were pushed into a repo from a remote. Also, git commit -a cannot be done in direct mode.
+But, I think I can just create an alias for git-annex sync --no-push --no-pull to save me some typing.
+"""]]
diff --git a/doc/forum/git-annex_teams___47___groups.mdwn b/doc/forum/git-annex_teams___47___groups.mdwn
new file mode 100644
index 0000000000..b499f3a6e4
--- /dev/null
+++ b/doc/forum/git-annex_teams___47___groups.mdwn
@@ -0,0 +1,5 @@
+Hi,
+
+Does git-annex (preferably assistant) have any management of users / groups or teams? Our use case is we have many users which should only have access to certain folders (repos). Is this a planned feature or any manual way to work around this for now?
+
+Thanks!
diff --git a/doc/forum/git-annex_teams___47___groups/comment_1_0450673ab74f184a47ac7bab568d26dc._comment b/doc/forum/git-annex_teams___47___groups/comment_1_0450673ab74f184a47ac7bab568d26dc._comment
new file mode 100644
index 0000000000..4b77da8f55
--- /dev/null
+++ b/doc/forum/git-annex_teams___47___groups/comment_1_0450673ab74f184a47ac7bab568d26dc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 1"
+ date="2013-06-25T17:10:17Z"
+ content="""
+Anyone with access to a git repository can access all the files stored in it. git-annex does not try to change this, so you need to find a way to have one repository for each group.
+"""]]
diff --git a/doc/forum/git-annex_tor_remote_not_working.mdwn b/doc/forum/git-annex_tor_remote_not_working.mdwn
new file mode 100644
index 0000000000..e93236fe7e
--- /dev/null
+++ b/doc/forum/git-annex_tor_remote_not_working.mdwn
@@ -0,0 +1,15 @@
+So i wanted to try local pairing for a while, but since i wanted to sync between local host and a remote server (which is heavily secured, firewall, block port except one available for ssh etc).
+Although, i could have used the ssh remote, but i couldn't found a flag to specify a private key file (might need to search more), since i'm using a separate private key + password to ssh into the remote server.
+
+Anyway, tor installed fine on both host and server, but even though tor was working fine by itself (tried it using sock5 and curl to test), git-annex couldn't initialize it, and was stuck on `Unable to connect to hidden service. It may not yet have propigated to the Tor network. (SocksErrorHostUnreachable) Will retry..` when using `git annex enable-tor` 
+I tried it on the assistant too with the same error in the logs.
+
+I'm using default setting on the torrc, I'm on ubuntu 19.04 x86_64 using 7.20190129 version of git-annex.
+
+P.S:I used this one liner to test if tor was working ` curl --socks5 localhost:9050 --socks5-hostname localhost:9050 -s https://check.torproject.org/ | cat | grep -m 1 Congratulations | xargs`, not sure if there better way/other to test it.
+
+EDIT: I updated the git-annex version on both the host and server, as i only now noticed they were old (and also since i tried a lot of other things and that was the last thing that could work).
+Using 7.20190819+git2-g908476a9b-1~ndall+1 from neuron's repo.
+Still not working and now stuck at `git-annex: tor failed to create hidden service, perhaps the tor service is not running` when doing `sudo git-annex enable-tor $(id -u)`
+(and yes, the tor service is indeed running, which make that weird)
+Obvious, but i also made sure to restart both tor and git-annex before and after upgrading in my consecutive attempts.
diff --git a/doc/forum/git-annex_tor_remote_not_working/comment_1_15cce70b24769832ccf9782d1215d605._comment b/doc/forum/git-annex_tor_remote_not_working/comment_1_15cce70b24769832ccf9782d1215d605._comment
new file mode 100644
index 0000000000..877f71187a
--- /dev/null
+++ b/doc/forum/git-annex_tor_remote_not_working/comment_1_15cce70b24769832ccf9782d1215d605._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-10-21T16:41:31Z"
+ content="""
+I've just tested it on Debian with tor version 0.4.1.6,
+and it worked for me.
+
+It seems to have gotten considerably further in the first error message
+you showed than in the second error message.
+
+It's easier to investigate the second problem. git-annex is expecting tor
+to have created a directory with a name starting
+with "/var/lib/tor/tor-annex_" and with the git-annex UUID of your
+repository in its name. Inside that directory, it expects to find a
+hostname file that contains a tor onion address.
+
+So tor is not creating that directory or that file, or the file
+contains something else. Which one it is will help narrow the problem.
+"""]]
diff --git a/doc/forum/git-annex_tor_remote_not_working/comment_2_e17a7f8a98f4614f46f05228f604a562._comment b/doc/forum/git-annex_tor_remote_not_working/comment_2_e17a7f8a98f4614f46f05228f604a562._comment
new file mode 100644
index 0000000000..138c3d96d0
--- /dev/null
+++ b/doc/forum/git-annex_tor_remote_not_working/comment_2_e17a7f8a98f4614f46f05228f604a562._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nordmagnus999"
+ avatar="http://cdn.libravatar.org/avatar/d5d5b418451be64f8fa5f56909fcc4c3"
+ subject="Tor and the UUID folder"
+ date="2019-10-21T18:43:36Z"
+ content="""
+I think it did indeed created (on the host) the required folder structure, and that it does contain a hostname file with the onion address inside (just checked).
+Not sure what's wrong here, but i believe i didn't checked if i was using latest version of tor on both the host and server (locally, its 0.3.5.8).
+didn't yet checked on the server yet as i launched a health stress check on the system, will get back to you on that one :) 
+"""]]
diff --git a/doc/forum/git-annex_tor_remote_not_working/comment_3_8ca1bc7358ad96ffb711d7ab1e4fd22a._comment b/doc/forum/git-annex_tor_remote_not_working/comment_3_8ca1bc7358ad96ffb711d7ab1e4fd22a._comment
new file mode 100644
index 0000000000..cf6b2ab882
--- /dev/null
+++ b/doc/forum/git-annex_tor_remote_not_working/comment_3_8ca1bc7358ad96ffb711d7ab1e4fd22a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-10-21T19:58:19Z"
+ content="""
+If tor did create what git-annex enable-tor expects to find, then
+re-running the command should get past that error. If running the command
+again immediately fails with the same error message, then whatever tor is
+setting up is not what git-annex expects.
+"""]]
diff --git a/doc/forum/git-annex_unused_not_dropping_deleted_files.mdwn b/doc/forum/git-annex_unused_not_dropping_deleted_files.mdwn
new file mode 100644
index 0000000000..1669461bc5
--- /dev/null
+++ b/doc/forum/git-annex_unused_not_dropping_deleted_files.mdwn
@@ -0,0 +1,34 @@
+I've been organizing my music collection deleted/replaces some files but git-annex unused does not show any unused files even though they are deleted and all repos are in sync.
+
+
+    git log --stat --all -S'SHA256E-s8034842--5c3475d7fef6f0c3545721f34e7cbfb6727a00708bdde192f0f1d53af251b444'
+    commit a0fecdc02f7564f8bce9726f6b934fefc11de58b
+    Date:   Thu Sep 12 17:04:53 2013 +0300
+
+        Deleted
+
+     .../Dido - Sitting On the Roof of the World.mp3    |    1 -
+     1 file changed, 1 deletion(-)
+
+    commit 7f216228fc0e6298f0290ee1d8646bc9b16eca10
+    Date:   Mon Aug 5 03:49:55 2013 +0200
+
+        Initial Import
+
+     .../Dido - Sitting On the Roof of the World.mp3    |    1 +
+     1 file changed, 1 insertion(+)`
+
+even though the file is deleted its still present in annex objects,
+
+    find .git -name '*5c3475d7fef6f0c3545721f34e7cbfb6727a00708bdde192f0f1d53af251b444*' -exec ls -al '{}' \;
+    total 7856
+    dr-xr-xr-x 2 user user    4096 Sep  9 01:24 .
+    drwxrwxr-x 3 user user    4096 Sep  9 01:24 ..
+    -r--r--r-- 1 user user 8034842 Aug  5 04:52 SHA256E-s8034842--5c3475d7fef6f0c3545721f34e7cbfb6727a00708bdde192f0f1d53af251b444.mp3
+    -r--r--r-- 1 user user 8034842 Aug  5 04:52 .git/annex/objects/Jz/74/SHA256E-s8034842--5c3475d7fef6f0c3545721f34e7cbfb6727a00708bdde192f0f1d53af251b444.mp3/SHA256E-s8034842--5c3475d7fef6f0c3545721f34e7cbfb6727a00708bdde192f0f1d53af251b444.mp3
+
+I got around 200 files that should be deleted but not showing up in unused. I though maybe one of the dead repos is causing the problem so i did a,
+
+    git annex forget --drop-dead
+
+and synced all repos. Still I can not get them to drop.
diff --git a/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_1_2152cfb09675e46e7492e198dd3ea094._comment b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_1_2152cfb09675e46e7492e198dd3ea094._comment
new file mode 100644
index 0000000000..72ed0bbe17
--- /dev/null
+++ b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_1_2152cfb09675e46e7492e198dd3ea094._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.2.134"
+ subject="comment 1"
+ date="2013-09-13T15:34:03Z"
+ content="""
+The most likely explanation is that you have a branch in git that still contains the deleted file, which will prevent unused from removing it. Try `git branch -a` to see all branches (a tag could also do it).
+"""]]
diff --git a/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_2_97e666dbac9de2a5e688921cba8a42e9._comment b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_2_97e666dbac9de2a5e688921cba8a42e9._comment
new file mode 100644
index 0000000000..134106482c
--- /dev/null
+++ b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_2_97e666dbac9de2a5e688921cba8a42e9._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 2"
+ date="2013-09-13T15:59:29Z"
+ content="""
+I did not create tags or branches, running returns,
+
+    git branch -a  
+
+      git-annex
+    * master
+      synced/git-annex
+      synced/master
+      remotes/origin/HEAD -> origin/master
+      remotes/origin/git-annex
+      remotes/origin/master
+      remotes/origin/synced/master
+
+"""]]
diff --git a/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_3_d7b0e9515bface28f3650b8aa20ec2f4._comment b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_3_d7b0e9515bface28f3650b8aa20ec2f4._comment
new file mode 100644
index 0000000000..666172b289
--- /dev/null
+++ b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_3_d7b0e9515bface28f3650b8aa20ec2f4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.2.134"
+ subject="comment 3"
+ date="2013-09-13T16:17:39Z"
+ content="""
+Depending on your git configuration, `git annex sync` might not be updating certian of these branches, such as remotes/origin/HEAD. You can check the branches out and see which still contains your deleted files.
+"""]]
diff --git a/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_4_5816f6cab42e27e724e735368f693b09._comment b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_4_5816f6cab42e27e724e735368f693b09._comment
new file mode 100644
index 0000000000..e1a503d232
--- /dev/null
+++ b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_4_5816f6cab42e27e724e735368f693b09._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 4"
+ date="2013-09-13T17:57:38Z"
+ content="""
+Which one of those branches I can safely delete? this is a central repo all other clients drop their stuff here it does not have any remotes (I did clones it from a client then removed origin section from config.)
+"""]]
diff --git a/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_5_8e97f39225515f0bf8b168dfd6a0efab._comment b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_5_8e97f39225515f0bf8b168dfd6a0efab._comment
new file mode 100644
index 0000000000..1da1f80db7
--- /dev/null
+++ b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_5_8e97f39225515f0bf8b168dfd6a0efab._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.2.134"
+ subject="comment 5"
+ date="2013-09-13T18:23:02Z"
+ content="""
+So this is a bare repository?
+
+It seems to have had an origin at one point; see the remotes/origin/* branches. If it no longer has that remote, then of course those branches will not be getting updated, and so will contain the old files and that's why unused won't find them. In that case, you could safely remove the remotes/origin/* branches.
+"""]]
diff --git a/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_6_bef37f8ec9c337387b79ffd6d56fe425._comment b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_6_bef37f8ec9c337387b79ffd6d56fe425._comment
new file mode 100644
index 0000000000..fe1c94eca3
--- /dev/null
+++ b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_6_bef37f8ec9c337387b79ffd6d56fe425._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 6"
+ date="2013-09-13T18:41:30Z"
+ content="""
+It is a non bare repo, I am using the following setup,
+
+http://git-annex.branchable.com/forum/Annex_dropping_files/
+"""]]
diff --git a/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_7_bff3bcf9f1b7c458afa98cdb18883153._comment b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_7_bff3bcf9f1b7c458afa98cdb18883153._comment
new file mode 100644
index 0000000000..f75c321ba0
--- /dev/null
+++ b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_7_bff3bcf9f1b7c458afa98cdb18883153._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2016-01-29T18:20:06Z"
+ content="""
+As someone else ran into a similar case of this, let me explain a little
+bit more..
+
+`git-annex unused` finds files that are not used by the currently checked
+out branch, or any other branch or tag. This includes remote branches.
+
+This is an important safeguard, because there might be a clone of the
+repository that intentionally still has that file checked out, and it
+wouldn't be good for `git-annex unused` to treat such a file as unused.
+
+But if there's an old remote, that's perhaps not getting updated any longer
+and has a branch that points to a file, `git annex unused` won't find that file
+as unused.
+
+So, one solution is to use `git remote rm` to delete the old remote. Or,
+otherwise get git to delete the old remote branch that is keeping the file
+around.
+
+The other solution is to run something like `git annex unused
+--used-refspec=+master` What this does is only considers the local master
+branch as used, and not any other branch or tags. I'd recommend only using
+this with caution.
+"""]]
diff --git a/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_8_7259b8e9616009472ad3a10426f3d8ea._comment b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_8_7259b8e9616009472ad3a10426f3d8ea._comment
new file mode 100644
index 0000000000..0e81791f14
--- /dev/null
+++ b/doc/forum/git-annex_unused_not_dropping_deleted_files/comment_8_7259b8e9616009472ad3a10426f3d8ea._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="viric@582d0845fdeae54b262502f49509b4577a5adbf8"
+ nickname="viric"
+ subject="Use --used-refspec"
+ date="2016-01-29T21:37:35Z"
+ content="""
+\"joeyh\" just helped me on irc, because I had this very same problem. I have git-annex repositories in A, and in external hard disks B, C, D, ...
+
+If I remove a file in A, I mean to 1) free space in A (drop) and 2) this to propagate later to the drives.
+
+No matter what \"git annex sync\" you do from A, the hard disks in your armchair will keep references to the file in their checkout, so A will refuse to drop the file contents until you run \"git annex sync\" from *each* of your external hard disks.
+
+What you need (and what I also needed) was to rule the drop/unused from A alone. You have to use \"git annex unused --used-refspec=+master\" from A, and that
+will only keep into account the contents referenced by your current A master, ignoring the checkouts of B, C, D, ...
+
+The \"used-refspec\" can even be set up in the git config.
+"""]]
diff --git a/doc/forum/git-annex_unused_on_directory_special_remote__63__.mdwn b/doc/forum/git-annex_unused_on_directory_special_remote__63__.mdwn
new file mode 100644
index 0000000000..41956fa361
--- /dev/null
+++ b/doc/forum/git-annex_unused_on_directory_special_remote__63__.mdwn
@@ -0,0 +1,15 @@
+Should git-annex unused work on a directory special remote? I tried the following:
+
+	$ git-annex unused --from SanDisk64GB4Torrented
+	unused SanDisk64GB4Torrented (checking for unused data...) ok
+	$ 
+
+However, despite git-annex list --in SanDisk64GB4Torrented demonstrating that there were no annex files in it, the size of the directory was still large. And I can see a file in tmp/ of that annex's directory:
+
+	$ ls tmp/
+	SHA256E-s2351316992--bdfba5df0bd72cffdb398fe885d9e36d052617647c0ae4fd0579a8fc785c95ba.iso
+	$ 
+
+Am I right to think that the file being present in tmp/ should cause git-annex unused to list it?
+
+I'm assuming it's fine to just remove the file. But I guess this might be a bug... so I'm putting it out there just in case.
diff --git a/doc/forum/git-annex_unused_on_directory_special_remote__63__/comment_1_5fb31042ed7c5c52969451b6fc0f4ddc._comment b/doc/forum/git-annex_unused_on_directory_special_remote__63__/comment_1_5fb31042ed7c5c52969451b6fc0f4ddc._comment
new file mode 100644
index 0000000000..9289a7bde6
--- /dev/null
+++ b/doc/forum/git-annex_unused_on_directory_special_remote__63__/comment_1_5fb31042ed7c5c52969451b6fc0f4ddc._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-02-27T16:16:31Z"
+ content="""
+That file was created by a git-annex copy to the special remote that was
+interrupted before it finished. It's safe to remove it.
+
+`git-annex unused` can't detect these kinds of things on special remotes
+(though it can in git-annex repositories). I do think it would be good if
+it were able to. Opened [[todo/improve_unused_for_special_remotes]].
+"""]]
diff --git a/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved.mdwn b/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved.mdwn
new file mode 100644
index 0000000000..a4386add79
--- /dev/null
+++ b/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved.mdwn
@@ -0,0 +1 @@
+The settings don't seem to be saving. If I edit it, then immediately open the file again, the settings are what they were before. This happens no matter what repo I do it from.
diff --git a/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_1_81111f59caea9f70cb9d597381e42c96._comment b/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_1_81111f59caea9f70cb9d597381e42c96._comment
new file mode 100644
index 0000000000..27a719853e
--- /dev/null
+++ b/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_1_81111f59caea9f70cb9d597381e42c96._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-12T17:26:35Z"
+ content="""
+Please paste the line that you've configured, and then show how it looks when you open vicfg again.
+"""]]
diff --git a/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_2_8ca9156d21d9f3db0d83d6aa9b69caa0._comment b/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_2_8ca9156d21d9f3db0d83d6aa9b69caa0._comment
new file mode 100644
index 0000000000..467d45740f
--- /dev/null
+++ b/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_2_8ca9156d21d9f3db0d83d6aa9b69caa0._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="ghen1"
+ ip="66.41.70.34"
+ subject="comment 2"
+ date="2014-10-12T21:03:01Z"
+ content="""
+The custom settings I had made before (the rest are still commented out):
+trust a8372263-6eba-47e2-9604-3e2c9bbb6d42 = trusted
+wanted 3e2bcb1e-39ad-4863-a9ce-a18a262644c1 = present or (not include=/Books/*)
+wanted a8372263-6eba-47e2-9604-3e2c9bbb6d42 = present or include=/Books/*
+
+I am trying to comment them out again.
+
+Based on your answer, I guessed that these settings don't just reset to default when they are commented out, so I tried changing the above trusted setting to semitrusted, and sure enough it worked.
+
+So it seems once these settings are made they can't be commented out again, and any invalid settings are ignored?
+"""]]
diff --git a/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_3_9da6ca0250ab0dcfc9a012df75e2e711._comment b/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_3_9da6ca0250ab0dcfc9a012df75e2e711._comment
new file mode 100644
index 0000000000..375ee1254b
--- /dev/null
+++ b/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_3_9da6ca0250ab0dcfc9a012df75e2e711._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 3"
+ date="2014-10-12T23:26:27Z"
+ content="""
+vicfg won't accept invalid input, if you make a type in the syntax it'll land you back in the editor with the problem line marked.
+
+But right, commenting out a line does not reset it to the default. Basically, once one of these settings is changed, there is no longer a default to go back to. You have to leave the line uncommented and change the value to what you want it to be. Ie, \"= semitrusted\" for the trust levels, and \"= \" for the wanted expressions.
+
+I think that vicfg should avoid this [[todo/vicfg_comment_gotcha]] and have filed that as a todo item.
+"""]]
diff --git a/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_4_55c52c45f3aaddfb63a1f53efe2ee582._comment b/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_4_55c52c45f3aaddfb63a1f53efe2ee582._comment
new file mode 100644
index 0000000000..0e73c48695
--- /dev/null
+++ b/doc/forum/git-annex_vicfg_preferred_content_settings_are_not_being_saved/comment_4_55c52c45f3aaddfb63a1f53efe2ee582._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2014-10-20T15:40:38Z"
+ content="""
+Right. In the meantime, I've fixed the behavior of vicfg when deleting
+lines, so it resets them to the default automatically.
+"""]]
diff --git a/doc/forum/git-annex_webapp_launch_behavior_is_confusing.mdwn b/doc/forum/git-annex_webapp_launch_behavior_is_confusing.mdwn
new file mode 100644
index 0000000000..d061913e82
--- /dev/null
+++ b/doc/forum/git-annex_webapp_launch_behavior_is_confusing.mdwn
@@ -0,0 +1,8 @@
+After first installing git-annex if I run `git-annex webapp` on Ubuntu 16.04.4 LTS (annex version 6.20180528-g5300386c2) then the process does not go to the background, but instead stays a foreground process. I can add files to a repo that assistant is watching and it will see them. But, if I then close the web browser and then kill the foreground process that launched the webapp, then all annex processes go away, and git-annex assistant is no longer running anywhere. IE if I then add a file to an assistant repo it won't be seen.
+
+If I reboot, then a bunch of annex processes are automatically started as daemons. Now my repos are watched again. If I launch git-annex webapp, this time the process immediately forks to the background which is different behavior.
+
+The behavior I would expect is that calling `git-annex webapp` should launch, the webapp dameon, load the page in a browser and call something like `git-annex assistant --autostart` as well.
+
+
+—[Andrew](http://git-annex.branchable.com/users/andrew/)
diff --git a/doc/forum/git-assistant_clarification.mdwn b/doc/forum/git-assistant_clarification.mdwn
new file mode 100644
index 0000000000..472f96c6a9
--- /dev/null
+++ b/doc/forum/git-assistant_clarification.mdwn
@@ -0,0 +1,11 @@
+I've noticed that if I'm using git-assistant, it wants to pull down all my files from other repos onto my laptop, even after I've dropped them.  (My laptop is set up as "client," my usb drive and an ssh server as "backup".)
+
+I want to use git annex to save space on my laptop, but of course when I'm running the assistant, it pulls everything down there, even things I've manually dropped.
+
+Is my "I want to save space, with a partial archive on my laptop" use case simply out of scope for the assistant?  So I should just be using the command line for my needs?  That's fine if that's the case.
+
+Or maybe something like this is what I should be doing?  http://git-annex.branchable.com/assistant/archival_walkthrough/  ?  so instead of manually "git annex drop"-ping files in place, I should set up a directory called "archive" on my machine, from which files will magically disappear and get backed up elsewhere?
+
+If it's the case that a directory named "archive" in your checkout has the magical property of having the assistant drop and archive its contents, that's awesome, maybe just what I need, but if that behavior is spelled out in so many words anywhere I managed to miss it.
+
+Apologies for all these questions, just enjoying the software immensely and wanting to get to know it.
diff --git a/doc/forum/git-assistant_clarification/comment_1_8f553e59da12f798b854a457b96b5778._comment b/doc/forum/git-assistant_clarification/comment_1_8f553e59da12f798b854a457b96b5778._comment
new file mode 100644
index 0000000000..03f9dc2735
--- /dev/null
+++ b/doc/forum/git-assistant_clarification/comment_1_8f553e59da12f798b854a457b96b5778._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 1"
+ date="2012-11-30T08:26:24Z"
+ content="""
+I'm second this request. Also, I'm posting this to enable the rss comment subscription button for this post.
+
+Maybe these design documents are interesting:
+
+<http://git-annex.branchable.com/design/assistant/transfer_control/>
+
+<http://git-annex.branchable.com/design/assistant/partial_content/>
+"""]]
diff --git a/doc/forum/git-assistant_clarification/comment_2_06cf62b599edea6ad8396776f0081494._comment b/doc/forum/git-assistant_clarification/comment_2_06cf62b599edea6ad8396776f0081494._comment
new file mode 100644
index 0000000000..90137e722f
--- /dev/null
+++ b/doc/forum/git-assistant_clarification/comment_2_06cf62b599edea6ad8396776f0081494._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 2"
+ date="2012-11-30T16:31:21Z"
+ content="""
+The archive directory is a new feature, but yes, it does work. Just use the webapp to edit the configuration of a remote, put it into the \"small archive\" group, and the contents of archive directories will be sent to it.
+
+This is a particular application of [[preferred_content]] settings, which give you a large amount of control over which data end up where when using the assistant.
+"""]]
diff --git a/doc/forum/git-assistant_clarification/comment_3_36f0bd6e7a824e6ef40a309850bb087b._comment b/doc/forum/git-assistant_clarification/comment_3_36f0bd6e7a824e6ef40a309850bb087b._comment
new file mode 100644
index 0000000000..1cf51c296c
--- /dev/null
+++ b/doc/forum/git-assistant_clarification/comment_3_36f0bd6e7a824e6ef40a309850bb087b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 3"
+ date="2012-11-30T18:49:37Z"
+ content="""
+Very cool!
+
+So not only is archive/ a magic subdirectory due to the \"preferred content settings\" for \"client,\" but *every* subdirectory named \"archive\" similarly drops content when possible.  That's awesome to know.
+
+Also if I really wanted to manually manage all my content and still have git-annex assistant running, I could simply use \"present\" for my preferred content settings on my laptop, and it would respect my manual gets and drops.
+
+Thank you!
+
+"""]]
diff --git a/doc/forum/git-like_git-annex_diff.mdwn b/doc/forum/git-like_git-annex_diff.mdwn
new file mode 100644
index 0000000000..59205d6242
--- /dev/null
+++ b/doc/forum/git-like_git-annex_diff.mdwn
@@ -0,0 +1,11 @@
+It took me some trial and error to get `git-annex diffdriver` to work close to the way I wanted (basically, the same way `git diff` works in a normal git repository with `color.ui` set to `always` with `git config`, so I thought I'd put my notes here for others:
+
+* Install `colordiff` (I couldn't figure out what `git`'s actual default diff program was or if it was possible to use it outside of `git diff`, so I went with this.
+* Create a wrapper script to pass to `git-annex diffdriver`. `LANG=C` was to avoid a warning produced by `perl` when it runs `colordiff`. `exit 0` is needed because `colordiff`/`diff` has a non-zero exit status when the files it is passed are not identical and `git` expects the external diff program to exit with status 0:
+
+        #!/usr/bin/env bash                                                             
+        LANG=C colordiff -c "$1" "$2"                                                   
+        exit 0
+
+* Put the wrapper script somewhere on `PATH`, make it executable, and name it something like `git-annex-diff-wrapper`.
+* Configure the repo to use the wrapper: `git config diff.external "git-annex diffdriver -- git-annex-diff-wrapper --"`
diff --git a/doc/forum/git-remote-gcrypt.mdwn b/doc/forum/git-remote-gcrypt.mdwn
new file mode 100644
index 0000000000..eaf5889e7c
--- /dev/null
+++ b/doc/forum/git-remote-gcrypt.mdwn
@@ -0,0 +1 @@
+Back in January Joey [mentioned](http://git-annex.branchable.com/design/assistant/blog/day_179__brief_updates/) the [git-remote-gcrypt](https://github.com/blake2-ppc/git-remote-gcrypt) and possibly adding support for it in the Assistant. I think this would be a great addition. Now that the first big Android push is complete, is there a schedule for this feature?
diff --git a/doc/forum/git-remote-gcrypt/comment_1_175c8c35d9bbb470fcc17697eb8cc6b8._comment b/doc/forum/git-remote-gcrypt/comment_1_175c8c35d9bbb470fcc17697eb8cc6b8._comment
new file mode 100644
index 0000000000..ca38da4cd9
--- /dev/null
+++ b/doc/forum/git-remote-gcrypt/comment_1_175c8c35d9bbb470fcc17697eb8cc6b8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-07T18:42:37Z"
+ content="""
+I have not put it on the schedule (and don't think I'll get to it this month), but I have added it to the [[roadmap|design/assistant]].
+
+The main use cases it adds are encrypting git remotes on ssh servers, and on USB drives. Both are useful for sure..
+
+It also opens the possibility of using github for encrypted git remotes, but with xmpp git push that is not a pressing use case. With significantly more work, encrypted git remotes could be stored on S3 etc, but again xmpp git push covers the same use cases.
+"""]]
diff --git a/doc/forum/git-remote-gcrypt/comment_2_fdcaf507e14c995636dd93a41e488df3._comment b/doc/forum/git-remote-gcrypt/comment_2_fdcaf507e14c995636dd93a41e488df3._comment
new file mode 100644
index 0000000000..a20fc7e761
--- /dev/null
+++ b/doc/forum/git-remote-gcrypt/comment_2_fdcaf507e14c995636dd93a41e488df3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="82.36.235.9"
+ subject="comment 2"
+ date="2013-03-12T09:33:17Z"
+ content="""
+The use case this is really good for, that XMPP push can't help with, is for when two paired machines are almost never both turned on at once.
+"""]]
diff --git a/doc/forum/git-remote-gcrypt/comment_3_f4e830f961dbe1c60ddd277b9d888133._comment b/doc/forum/git-remote-gcrypt/comment_3_f4e830f961dbe1c60ddd277b9d888133._comment
new file mode 100644
index 0000000000..03ac7b0f56
--- /dev/null
+++ b/doc/forum/git-remote-gcrypt/comment_3_f4e830f961dbe1c60ddd277b9d888133._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="annexuser"
+ ip="50.125.45.235"
+ subject="comment 3"
+ date="2013-05-25T22:58:16Z"
+ content="""
+I'm still hoping to see this. The feature received some attention on the [April poll](http://git-annex.branchable.com/design/assistant/polls/goals_for_April/).
+"""]]
diff --git a/doc/forum/git-remote-gcrypt_and_rsyncd.mdwn b/doc/forum/git-remote-gcrypt_and_rsyncd.mdwn
new file mode 100644
index 0000000000..bba80cd66c
--- /dev/null
+++ b/doc/forum/git-remote-gcrypt_and_rsyncd.mdwn
@@ -0,0 +1,32 @@
+In an attempt to simplify my setup, I have been trying to setup an encrypted repository on a `rsyncd`-based server via [`git-remote-gcrypt`](https://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/), which would house the file history and the annexed files themselves. I cannot provide an SSH connection to the server, so the `rsyncd` method seemed appealing.
+
+Using the rsync format url with "::" to signal the rsyncd method, the connection seems successful, but the initialization does not complete. 
+
+```
+git annex initremote gcrypt-rsyncd type=gcrypt gitrepo=rsync://***::a/test keyid=*** encryption=hybrid
+
+initremote gcrypt-rsyncd (encryption setup) (to gpg keys: ***) gcrypt
+ Decrypting manifest
+gpg: Signature made Wed Nov 22 22:23:16 2023 CET
+gpg:                using EDDSA key ***
+gpg: Good signature from "archive-990" [ultimate]
+gcrypt: Remote ID is :id:ya5ZivzWNEOUtVg2R0L9
+From gcrypt::rsync://***::a/test
+ * [new branch]      git-annex  -> gcrypt-rsyncd/git-annex
+gcrypt: Decrypting manifest
+gpg: Signature made Wed Nov 22 22:23:16 2023 CET
+gpg:                using EDDSA key ***
+gpg: Good signature from "archive-990" [ultimate]
+Everything up-to-date
+
+git-annex: git: createProcess: chdir: invalid argument (Bad file descriptor)
+failed
+initremote: 1 failed
+```
+
+Logs from the daemon show the following error:
+```
+rsync to a/test/annex/objects from ***
+```
+
+I don't know whether this error is imputable to `git-annex`, or `git-remote-gcrypt`, or my settings.
diff --git a/doc/forum/git-remote-gcrypt_and_rsyncd/comment_1_34dd343ed75918f5969f6a23dfae3317._comment b/doc/forum/git-remote-gcrypt_and_rsyncd/comment_1_34dd343ed75918f5969f6a23dfae3317._comment
new file mode 100644
index 0000000000..02246cf558
--- /dev/null
+++ b/doc/forum/git-remote-gcrypt_and_rsyncd/comment_1_34dd343ed75918f5969f6a23dfae3317._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-11-28T16:06:22Z"
+ content="""
+That is a pretty weird error message! It looks like git-annex may have run
+git but tried to pass it a working directory that does not exist. It would
+be interesting to know what git command, passing --debug would tell you.
+
+But: The gcrypt special remote is documented as needing gitrepo=rsync:// to
+operate over ssh. And git-remote-gcrypt interprets a rsync:// url as rsync
+over ssh (see its man page). Yes, "host::" in rsync indicates direct contact
+to a rsync daemon, not using ssh, but that will not work with git-remote-gcrypt
+to the best of my knowledge.
+"""]]
diff --git a/doc/forum/git-remote-gcrypt_and_rsyncd/comment_2_78b89867bd1af78a91826022651a57ad._comment b/doc/forum/git-remote-gcrypt_and_rsyncd/comment_2_78b89867bd1af78a91826022651a57ad._comment
new file mode 100644
index 0000000000..57057f4397
--- /dev/null
+++ b/doc/forum/git-remote-gcrypt_and_rsyncd/comment_2_78b89867bd1af78a91826022651a57ad._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="branch"
+ subject="comment 2"
+ date="2023-12-03T11:57:56Z"
+ content="""
+There is no specific log to highlight when running the command in `--debug`.
+
+```
+[2023-12-03 12:43:49.274023] (Utility.Process) process [40369] done ExitSuccess
+
+git-annex: git: createProcess: chdir: invalid argument (Bad file descriptor)
+failed
+[2023-12-03 12:43:49.276644] (Utility.Process) process [40197] done ExitSuccess
+initremote: 1 failed
+```
+
+I ended up refactoring my systems to allow the use of SSH, which seems to be the supported method, and to avoid any further issue down the line.
+"""]]
diff --git a/doc/forum/git-repair_doesn__39__t_build_with_GHC_8.0.2.mdwn b/doc/forum/git-repair_doesn__39__t_build_with_GHC_8.0.2.mdwn
new file mode 100644
index 0000000000..bd6ae58fd7
--- /dev/null
+++ b/doc/forum/git-repair_doesn__39__t_build_with_GHC_8.0.2.mdwn
@@ -0,0 +1,10 @@
+This should be related to directory 1.3.
+
+    Common.hs:3:16: error:
+        Conflicting exports for ‘getFileSize’:
+           ‘module X’ exports ‘X.getFileSize’
+             imported from ‘Utility.FileSize’ at Common.hs:32:1-28
+             (and originally defined at Utility/FileSize.hs:26:1-11)
+           ‘module X’ exports ‘X.getFileSize’
+             imported from ‘Utility.Directory’ at Common.hs:33:1-29
+             (and originally defined in ‘System.Directory’)
diff --git a/doc/forum/git-repair_doesn__39__t_build_with_GHC_8.0.2/comment_1_0a6ea834f6515b888e5c40fef08f4e2d._comment b/doc/forum/git-repair_doesn__39__t_build_with_GHC_8.0.2/comment_1_0a6ea834f6515b888e5c40fef08f4e2d._comment
new file mode 100644
index 0000000000..873e47324b
--- /dev/null
+++ b/doc/forum/git-repair_doesn__39__t_build_with_GHC_8.0.2/comment_1_0a6ea834f6515b888e5c40fef08f4e2d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-26T16:08:20Z"
+ content="""
+AFAIK, this was fixed already in git-repair's master branch.
+
+I've released a new git-repair with the fixes.
+"""]]
diff --git a/doc/forum/git-repair_doesn__39__t_build_with_GHC_8.0.2/comment_2_bb490f71aed0cfe119beac66cecae99c._comment b/doc/forum/git-repair_doesn__39__t_build_with_GHC_8.0.2/comment_2_bb490f71aed0cfe119beac66cecae99c._comment
new file mode 100644
index 0000000000..b9cb6a9642
--- /dev/null
+++ b/doc/forum/git-repair_doesn__39__t_build_with_GHC_8.0.2/comment_2_bb490f71aed0cfe119beac66cecae99c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~felixonmars"
+ nickname="felixonmars"
+ avatar="http://cdn.libravatar.org/avatar/17284a3bb2e4ad9d3be8fab31f49865be9c1dc22143c728de731fe800a335d38"
+ subject="comment 2"
+ date="2017-06-27T15:57:40Z"
+ content="""
+Works nice here. Thanks a lot!
+"""]]
diff --git a/doc/forum/git-status_typechange_in_direct_mode.mdwn b/doc/forum/git-status_typechange_in_direct_mode.mdwn
new file mode 100644
index 0000000000..6438fb890d
--- /dev/null
+++ b/doc/forum/git-status_typechange_in_direct_mode.mdwn
@@ -0,0 +1,48 @@
+Hi all,
+
+how can I get rid of all those 'typechange' messages in `git status`
+when in direct mode?
+
+Here is an example session:
+
+    > git init
+    Initialized empty Git repository in /some/path/.git/
+    > git config user.name dtrn
+    > git config user.email drn@drn.com
+    > git annex init
+    init  ok
+    (Recording state in git...)
+    > git annex direct
+    commit
+    # On branch master
+    #
+    # Initial commit
+    #
+    nothing to commit (create/copy files and use "git add" to track)
+    ok
+    direct  ok
+    > dd if=/dev/zero of=testfile.bin count=1000
+    1000+0 records in
+    1000+0 records out
+    512000 bytes (512 kB) copied, 0.00317424 s, 161 MB/s
+    > git annex add testfile.bin
+    add testfile.bin (checksum...) ok
+    (Recording state in git...)
+    > git commit -m "annexed testfile.bin"
+    ok
+    [master (root-commit) 281e740] annexed testfile.bin
+     1 file changed, 1 insertion(+)
+     create mode 120000 testfile.bin
+    >  git status
+    # On branch master
+    # Changes not staged for commit:
+    #   (use "git add <file>..." to update what will be committed)
+    #   (use "git checkout -- <file>..." to discard changes in working directory)
+    #
+    #       typechange: testfile.bin
+    #
+    no changes added to commit (use "git add" and/or "git commit -a")
+
+
+Regards,
+Andreas
diff --git a/doc/forum/git-status_typechange_in_direct_mode/comment_1_12c8b67aadbfa2b073e12997a55d49a7._comment b/doc/forum/git-status_typechange_in_direct_mode/comment_1_12c8b67aadbfa2b073e12997a55d49a7._comment
new file mode 100644
index 0000000000..31e476087d
--- /dev/null
+++ b/doc/forum/git-status_typechange_in_direct_mode/comment_1_12c8b67aadbfa2b073e12997a55d49a7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4830:1600:187::2"
+ subject="comment 1"
+ date="2013-09-20T15:24:25Z"
+ content="""
+These messages are normal in direct mode. 
+
+They happen because git status does not know about git-annex's direct mode. So it sees a file that has a symlink checked into git, but a normal file in place in the working tree. Thus, its type has changed. Short of hacking or wrapping git, or switching to indirect mode ;), there's not much that can be done about this.
+
+You might want to read [[direct_mode]] for more about this, and some of the problems it can cause when running certian git commands.
+"""]]
diff --git a/doc/forum/git-status_typechange_in_direct_mode/comment_2_005d1b17f3c2ae192aa30c6e5163989e._comment b/doc/forum/git-status_typechange_in_direct_mode/comment_2_005d1b17f3c2ae192aa30c6e5163989e._comment
new file mode 100644
index 0000000000..c598b212fe
--- /dev/null
+++ b/doc/forum/git-status_typechange_in_direct_mode/comment_2_005d1b17f3c2ae192aa30c6e5163989e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ringprince"
+ ip="134.76.140.110"
+ subject="comment 2"
+ date="2013-09-20T20:16:47Z"
+ content="""
+Thanks for the info and the quick reply.
+"""]]
diff --git a/doc/forum/git-subtree_support__63__.mdwn b/doc/forum/git-subtree_support__63__.mdwn
new file mode 100644
index 0000000000..a95277a235
--- /dev/null
+++ b/doc/forum/git-subtree_support__63__.mdwn
@@ -0,0 +1,9 @@
+Hi,
+
+I am a happy user of [git-subtree](http://github.com/apenwarr/git-subtree), and I wonder whether it integrates nicely with git-annex?
+
+My use-case looks like this: I have two annex repositories -- one at home and one at work. The annex at work is a strict subset of the one at home, i.e. all files that I have at work ought to be part of the annex at home, but not the other way round. Now, I realize that I could have one annex and selectively copy files to the checked out copy at work, but I don't want to do that because I don't want to have (broken) symlinks for all kinds of stuff visible on my machine at work that is not supposed to be there (such as MP3 files, etc.). Instead, I would like to use git-subtree to import the work annex into a sub-directory of the one at home, so that both annex are logically separate, but still the one at home always contains everything that the one at work contains.
+
+Is that possible?
+
+And if not, is there maybe another way to accomplish this kind of thing?
diff --git a/doc/forum/git-subtree_support__63__/comment_1_4f333cb71ed1ff259bbfd86704806aa6._comment b/doc/forum/git-subtree_support__63__/comment_1_4f333cb71ed1ff259bbfd86704806aa6._comment
new file mode 100644
index 0000000000..e4ded4c577
--- /dev/null
+++ b/doc/forum/git-subtree_support__63__/comment_1_4f333cb71ed1ff259bbfd86704806aa6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-01-03T17:00:53Z"
+ content="""
+I have no experience using git-subtree, but as long as the home repository has the work one as a git remote, it will automatically merge work's git-annex branch with its own git-annex branch, and so will know what files are present at work, and will be able to get them.
+
+Probably you won't want to make work have home as a remote, so work's git-annex will not know which files home has, nor will it be able to copy files to home (but home will be able to copy files to work).
+"""]]
diff --git a/doc/forum/git-subtree_support__63__/comment_2_73d2a015b1ac79ec99e071a8b1e29034._comment b/doc/forum/git-subtree_support__63__/comment_2_73d2a015b1ac79ec99e071a8b1e29034._comment
new file mode 100644
index 0000000000..9bac6e997b
--- /dev/null
+++ b/doc/forum/git-subtree_support__63__/comment_2_73d2a015b1ac79ec99e071a8b1e29034._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://peter-simons.myopenid.com/"
+ ip="77.188.44.113"
+ subject="comment 2"
+ date="2012-01-03T18:11:37Z"
+ content="""
+The point of git-subtree is that I can import another repository into sub-directory, i.e. I can have a directory called \"work\" that contains all files from the annex I have at work. If I make the other annex a remote and merge its contents, then all contents is going to be merged at the top-level, which is somewhat undesirable in my particular case.
+"""]]
diff --git a/doc/forum/git-subtree_support__63__/comment_3_c533400e22c306c033fcd56e64761b0b._comment b/doc/forum/git-subtree_support__63__/comment_3_c533400e22c306c033fcd56e64761b0b._comment
new file mode 100644
index 0000000000..83edaf743d
--- /dev/null
+++ b/doc/forum/git-subtree_support__63__/comment_3_c533400e22c306c033fcd56e64761b0b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2012-01-03T18:42:08Z"
+ content="""
+You can make it a remote without merging its contents. Git will not merge its contents by default unless it's named \"origin\". git-annex will be prefectly happy with that.
+"""]]
diff --git a/doc/forum/git-subtree_support__63__/comment_4_75b0e072e668aa46ff0a8d62a6620306._comment b/doc/forum/git-subtree_support__63__/comment_4_75b0e072e668aa46ff0a8d62a6620306._comment
new file mode 100644
index 0000000000..642f952e4d
--- /dev/null
+++ b/doc/forum/git-subtree_support__63__/comment_4_75b0e072e668aa46ff0a8d62a6620306._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://peter-simons.myopenid.com/"
+ ip="77.188.44.113"
+ subject="comment 4"
+ date="2012-01-03T19:17:36Z"
+ content="""
+Okay, I see, but is `git annex get --auto .` going to import all those files from the work remote into my home if the `master` branch of that remote isn't merged?
+"""]]
diff --git a/doc/forum/git-subtree_support__63__/comment_5_f5ec9649d9f1dc122e715de5533bc674._comment b/doc/forum/git-subtree_support__63__/comment_5_f5ec9649d9f1dc122e715de5533bc674._comment
new file mode 100644
index 0000000000..5b2f3dad55
--- /dev/null
+++ b/doc/forum/git-subtree_support__63__/comment_5_f5ec9649d9f1dc122e715de5533bc674._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 5"
+ date="2012-01-03T19:31:45Z"
+ content="""
+Yes; git-annex uses the git-annex branch independently of the branch you have checked out. You may find [[internals]] interesting reading, but the short answer is it will work.
+"""]]
diff --git a/doc/forum/git-subtree_support__63__/comment_6_85df530f7b6d76b74ac8017c6034f95e._comment b/doc/forum/git-subtree_support__63__/comment_6_85df530f7b6d76b74ac8017c6034f95e._comment
new file mode 100644
index 0000000000..77af85258b
--- /dev/null
+++ b/doc/forum/git-subtree_support__63__/comment_6_85df530f7b6d76b74ac8017c6034f95e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://peter-simons.myopenid.com/"
+ ip="77.188.44.113"
+ subject="comment 6"
+ date="2012-01-03T19:47:11Z"
+ content="""
+Very cool! Thank you for the explanation.
+"""]]
diff --git a/doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_.mdwn b/doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_.mdwn
new file mode 100644
index 0000000000..110c0d77f6
--- /dev/null
+++ b/doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_.mdwn
@@ -0,0 +1,29 @@
+Hello,
+
+I am a newbie git annex and english is not my native language. Please bare with me. After evaluation so many  options, I have decided to keep track of my family photo collection via git annex. My family photo collection is around 300gb and consisting of 120K items currently and its getting bigger fast. 
+
+Previously, I was using my home server and attached usb disks. I had also cold backup disks.  But keeping them in sync without making errors had been troublesome. 
+
+For this task, I decided to use three external usb disks along with a directory in my home server each keeping a git annex repository. I use my desktop as source annex repository to upload photos to these git annex repositories. I will keep external disks off site and rotate them off and on. 
+
+I have implemented this design but I have run into a problem. 
+
+Currently, there are five git annex repositories as described above. One of them is on the home serve internal disk,  three of them are in the usb disks. One is in my desktop harddrive. Apart from my desktop repository, all other repositories are configured as  "standard/backup". My desktop annex repository is configured as standard/manual. Each repository has four remotes of other repositories. They can all sync each other and get the contents. However currently I am receiving git message from all my backup repositories as follows. 
+
+````
+Auto packing the repository in background for optimum performance.
+See "git help gc" for manual housekeeping.
+warning: The last gc run reported the following. Please correct the root cause
+and remove .git/gc.log
+Automatic cleanup will not be performed until the file is removed.
+
+warning: There are too many unreachable loose objects; run 'git prune' to remove them.
+````
+
+I have tried `git prune --dry-run` as suggested some internet sites and I have seen that git wants to remove almost all annex blob files. 
+
+The annex repositories are mostly on btrfs file system, one is on ext4 file system, I do know if it matters. Git-annex versions are 10.20230126-9 in every machine (arch and manjaro). 
+
+`git annex unused` gives nothing. I am not using any encryption or any other git pluggable system other than git-annex. 
+
+Could you provide some insight please. Is there something wrong my repositories. It really took days to upload and sync all these repositories. Any help is much appreciated. 
diff --git a/doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_/comment_1_e3c37fc6e45de48a4d5c1eb36e8d44df._comment b/doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_/comment_1_e3c37fc6e45de48a4d5c1eb36e8d44df._comment
new file mode 100644
index 0000000000..c8a1b2803e
--- /dev/null
+++ b/doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_/comment_1_e3c37fc6e45de48a4d5c1eb36e8d44df._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="derphysiker"
+ avatar="http://cdn.libravatar.org/avatar/80623354932109c891c2e0ebf523b38f"
+ subject="comment 1"
+ date="2023-03-04T11:11:26Z"
+ content="""
+Did you have a look at
+
+<https://git-annex.branchable.com/tips/Repositories_with_large_number_of_files/>?
+
+What is your current object count (aka non-packed files)?:
+
+    git count-objects
+
+If you have many of them (multiple 10k) then it might be a good idea to repack them:
+
+    git repack -ad
+    git gc
+"""]]
diff --git a/doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_/comment_2_c77b9790da099a94ee368de6a557d4b2._comment b/doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_/comment_2_c77b9790da099a94ee368de6a557d4b2._comment
new file mode 100644
index 0000000000..7099de91e0
--- /dev/null
+++ b/doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_/comment_2_c77b9790da099a94ee368de6a557d4b2._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="benibilme"
+ avatar="http://cdn.libravatar.org/avatar/6c053ef48706932f4bd7ab184de4794a"
+ subject="Hello,"
+ date="2023-03-05T20:04:03Z"
+ content="""
+Thank you for the response. Yes, repacking and calling garbage collection solved the problem. I am not familiar with git plumbing commands, even though I have been using git for years, I have never needed using these commands. I had to look it up about what they do. I was afraid to lose files, because running prune with dry run options listed objects as many as my files. After your response, I applied on a backed up repository, it seemed I did not lose anything, and applied all other annex repositories, the problem has been solved.  
+
+I read the post you referenced after your pointing out, I would like ask if still `git update-index --index-version 4` is relevant for today. The post is 7 years old, by that time, git must have improved a lot. 
+
+I am also not quite sure about losing file tracking information. I like to keep this information. My annex repository which is in source standard group and does not have any actual content files is around 147mb. My full backup repositories are around 320gb and `git annex find` reports around 37500 files which is way less that I thought. 
+
+`git status` commands takes about 5 or 6 seconds to complete. Yesterday I have added around 30gb of new photos. From source repository in my desktop to four repositories (home server and attached three usb disks) over ssh took about a day. 
+
+Uploading is very slow with ssh. For each file, it copies to each remote in turn. It does not blast out all files to one remote in one connection. How can improve sync speed?    
+
+Thank you againt for the directions...  
+"""]]
diff --git a/doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_/comment_3_f0c6869f31a31803adec0fdc0befa178._comment b/doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_/comment_3_f0c6869f31a31803adec0fdc0befa178._comment
new file mode 100644
index 0000000000..d3f18c5947
--- /dev/null
+++ b/doc/forum/git__58____There_are_too_many_unreachable_loose_objecs_/comment_3_f0c6869f31a31803adec0fdc0befa178._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-03-06T16:31:40Z"
+ content="""
+By "all annex blob files", do you mean that all the files it wants to
+remove look like git-annex links?
+
+The way this can generally happen is if you `git add` a file
+(`git-annex add` would be the same) and then, without committing that, you 
+`git rm` it, or you change the file and run `git add` again on the new
+content. The original version of the file is not pointed to by any commit,
+so it's unreachable.
+
+So having a lot of such git objects is not itself evidence of a problem,
+if you have done that a lot. Or something similar, such as deleting a
+branch.
+"""]]
diff --git a/doc/forum/git__58_____39__annex__39___is_not_a_git_command_error_after_installing.mdwn b/doc/forum/git__58_____39__annex__39___is_not_a_git_command_error_after_installing.mdwn
new file mode 100644
index 0000000000..ac6560e491
--- /dev/null
+++ b/doc/forum/git__58_____39__annex__39___is_not_a_git_command_error_after_installing.mdwn
@@ -0,0 +1,38 @@
+Installed git and git annex precisely as directed on my Windows 7 system, but 'git annex test' fails with above mentioned error - as if it's not been installed.
+I tried uninstalling and reinstalling
+
+These are the contents of my git directory (from git bash prompt):
+
+-rw-r--r--    1 iainso   Administ      708 Dec 17 21:23 Git Bash.vbs
+
+-rw-r--r--    1 iainso   Administ    46106 Dec 17 21:23 ReleaseNotes.rtf
+
+drwxr-xr-x  147 iainso   Administ    40960 Jan 29 14:44 bin
+
+drwxr-xr-x   51 iainso   Administ    12288 Jan 29 16:10 cmd
+
+drwxr-xr-x    3 iainso   Administ        0 Jan 29 14:44 doc
+
+drwxr-xr-x   13 iainso   Administ     4096 Jan 29 14:44 etc
+
+-rw-r--r--    1 iainso   Administ      103 Jan 28 18:38 git-annex-autostart.vbs
+
+-rw-r--r--    1 iainso   Administ   232368 Jan 28 18:38 git-annex-licenses.txt
+
+-rwxr-xr-x    1 iainso   Administ    49799 Jan 29 16:10 git-annex-uninstall.exe
+
+-rw-r--r--    1 iainso   Administ       88 Jan 28 18:38 git-annex-webapp.vbs
+
+drwxr-xr-x    4 iainso   Administ        0 Jan 29 14:44 git-cheetah
+
+drwxr-xr-x   11 iainso   Administ     4096 Jan 29 14:44 lib
+
+drwxr-xr-x    3 iainso   Administ        0 Jan 29 14:43 libexec
+
+drwxr-xr-x    9 iainso   Administ        0 Jan 29 14:44 share
+
+drwxr-xr-x    5 iainso   Administ        0 Jan 29 14:44 ssl
+
+-rw-r--r--    1 iainso   Administ   635621 Jan 29 14:44 unins000.dat
+
+-rwxr-xr-x    1 iainso   Administ  1244929 Jan 29 14:42 unins000.exe
diff --git a/doc/forum/git__58_____39__annex__39___is_not_a_git_command_error_after_installing/comment_1_8a2e3be32800b7b8a6fa78bbdcba7608._comment b/doc/forum/git__58_____39__annex__39___is_not_a_git_command_error_after_installing/comment_1_8a2e3be32800b7b8a6fa78bbdcba7608._comment
new file mode 100644
index 0000000000..b856d79fd3
--- /dev/null
+++ b/doc/forum/git__58_____39__annex__39___is_not_a_git_command_error_after_installing/comment_1_8a2e3be32800b7b8a6fa78bbdcba7608._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk53Hn5PfMJ9Y0rmLdAeRGmgq7XSGWcoNA"
+ nickname="Iain"
+ subject="comment 1"
+ date="2015-01-29T16:28:59Z"
+ content="""
+Solved it, you need to add git/cmd to your windows path variable
+"""]]
diff --git a/doc/forum/git__58_____39__annex__39___is_not_a_git_command_error_after_installing/comment_2_451b3c89d1b98212d5c21efa4e535424._comment b/doc/forum/git__58_____39__annex__39___is_not_a_git_command_error_after_installing/comment_2_451b3c89d1b98212d5c21efa4e535424._comment
new file mode 100644
index 0000000000..9d09e096d6
--- /dev/null
+++ b/doc/forum/git__58_____39__annex__39___is_not_a_git_command_error_after_installing/comment_2_451b3c89d1b98212d5c21efa4e535424._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-02-04T17:51:26Z"
+ content="""
+Msysgit will add itself to the PATH if you check that box at installation
+time. If not, you probably can't run "git" either..
+"""]]
diff --git a/doc/forum/git_annex_add_crash_and_subsequent_recovery.mdwn b/doc/forum/git_annex_add_crash_and_subsequent_recovery.mdwn
new file mode 100644
index 0000000000..3f3b943a0b
--- /dev/null
+++ b/doc/forum/git_annex_add_crash_and_subsequent_recovery.mdwn
@@ -0,0 +1,25 @@
+Perhaps stupidly I added some very large bare git repos into a git-annex.
+
+This took a very long time, used lot's of memory, and then crashed.  I didn't catch the error (which is annoying) - sorry about that.  IIRC it is the same error if one Ctrl-c's the addition.
+
+I ran `git annex add .` a second time and eventually killed it (I perhaps should have waited - I now think it was working).
+
+A `git annex unannex` fixed up some files but somehow I managed to end up with tonnes of files all sym-linked into the git annex object directory but not somehow recognised as annexed files.  I'm assuming that they somehow didn't make it into git annex's meta-data layer (or equivalent).
+
+Commands such as `git annex {fsck,whereis,unannex} weirdfile` immediately returned without error.
+
+I've now spent a lot of manual time copying the files back. Doing the following, not the cleverest but I was a little panicky about my data...
+
+    find . -type l -exec mv \{} \{}.link \; #Move link names out of the way
+    find . -type l -exec cp \{} \{}.cp \; #Copy follows links so we can copy target back to link location
+    find . -type f -name "*.link.cp" | xargs -n 1 rename 's/\.link\.cp//' #Change to original name
+    find . -type l -exec rm \{} \; #Ditch the links
+    git annex unused
+    git annex dropunused `seq 9228`
+
+9228 files were found to be unused, this gives an idea of the scale of the number of "lost" files for want of a better term.
+
+A pretty poor bug report as these things go.  Anyone any idea what might have happened (it didn't seem space or memory related)?  Or how I might have fixed it a little more cleverly?
+
+For reference I am using stable Debian, git annex version 3.20111011.
+
diff --git a/doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_1_062d0153a379c1ba1df8585b90220d3d._comment b/doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_1_062d0153a379c1ba1df8585b90220d3d._comment
new file mode 100644
index 0000000000..e879441ff8
--- /dev/null
+++ b/doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_1_062d0153a379c1ba1df8585b90220d3d._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
+ nickname="Matt"
+ subject="comment 1"
+ date="2011-12-06T12:50:27Z"
+ content="""
+Ah HA!  Looks like I found the cause of this.
+
+    [matt@rss01:~/files/matt_ford]0> git annex add mhs
+    add mhs/Accessing_Web_Manager_V10.pdf ok
+    ....
+    add mhs/MAHSC Costing Request Form Dual
+    Organisations - FINAL v20 Oct 2010.xls git-annex: unknown response from git cat-file refs/heads/git-annex:8d5/ed4/WORM-s568832-m1323164214--MAHSC Costing Request Form Dual missing
+
+Spot the file name with a newline character in it!  This causes the error message above.  It seems that the files proceeding this badly named file are sym-linked but not registered.
+
+Perhaps a bug?
+"""]]
diff --git a/doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_2_6fc6be43c488c468a4811cd0a1360225._comment b/doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_2_6fc6be43c488c468a4811cd0a1360225._comment
new file mode 100644
index 0000000000..38f2434f49
--- /dev/null
+++ b/doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_2_6fc6be43c488c468a4811cd0a1360225._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-12-06T17:08:37Z"
+ content="""
+The bug with newlines is now fixed.
+
+Thought I'd mention how to clean up from interrupting `git annex add`.
+When you do that, it doesn't get a chance to `git add` the files it's
+added (this is normally done at the end, or sometimes at points in the middle when you're adding a *lot* of files).
+Which is also why fsck, whereis, and unannex wouldn't operate on them, since they only deal with files in git.
+
+So the first step is to manually use `git add` on any symlinks.
+
+Then, `git commit` as usual.
+
+At that point, `git annex unannex` would get you back to your starting state.
+"""]]
diff --git a/doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_3_45efaaf27d9b580c4c75cbcdc4f65b64._comment b/doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_3_45efaaf27d9b580c4c75cbcdc4f65b64._comment
new file mode 100644
index 0000000000..b58f81c5b7
--- /dev/null
+++ b/doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_3_45efaaf27d9b580c4c75cbcdc4f65b64._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
+ nickname="Matt"
+ subject="comment 3"
+ date="2011-12-07T07:39:15Z"
+ content="""
+Ah - very good to know that recovery is easier than the method I used.  
+
+I wonder if it could be made a feature to automatically and safely recover/resume from an interrupted `git add`?
+"""]]
diff --git a/doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_4_c560eae40867512b0af2cbef161fc8ac._comment b/doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_4_c560eae40867512b0af2cbef161fc8ac._comment
new file mode 100644
index 0000000000..8fca16cada
--- /dev/null
+++ b/doc/forum/git_annex_add_crash_and_subsequent_recovery/comment_4_c560eae40867512b0af2cbef161fc8ac._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 4"
+ date="2011-12-07T20:54:51Z"
+ content="""
+Good idea! I've made `git annex add` recover when ran a second time.
+"""]]
diff --git a/doc/forum/git_annex_add_freezes_on_direct_repo.mdwn b/doc/forum/git_annex_add_freezes_on_direct_repo.mdwn
new file mode 100644
index 0000000000..8c997724af
--- /dev/null
+++ b/doc/forum/git_annex_add_freezes_on_direct_repo.mdwn
@@ -0,0 +1,21 @@
+I've found that running git annex add on a directory in a direct repository freezes. Example output:
+
+    > git annex add Signs\ \(2002\ Film\) --debug
+    
+    [2015-02-22 10:10:04 GMT] read: git ["--git-dir=/Volumes/plato/Films/.git","--work-tree=/Volumes/plato/Films","-c","core.bare=false","ls-files","--others","--exclude-standard","-z","--","Signs (2002 Film)"]
+    [2015-02-22 10:10:04 GMT] chat: git ["--git-dir=/Volumes/plato/Films/.git","--work-tree=/Volumes/plato/Films","-c","core.bare=false","cat-file","--batch"]
+    add Signs (2002 Film)/VIDEO_TS/VIDEO_TS.BUP [2015-02-22 10:10:04 GMT] chat: git ["--git-dir=/Volumes/plato/Films/.git","--work-tree=/Volumes/plato/Films","-c","core.bare=false","check-attr","-z","--stdin","annex.backend","annex.numcopies","--"]
+    [2015-02-22 10:10:05 GMT] chat: git ["--git-dir=/Volumes/plato/Films/.git","--work-tree=/Volumes/plato/Films","-c","core.bare=false","hash-object","-t","blob","-w","--stdin","--no-filters"]
+    [2015-02-22 10:10:05 GMT] chat: git ["--git-dir=/Volumes/plato/Films/.git","--work-tree=/Volumes/plato/Films","-c","core.bare=false","cat-file","--batch"]
+    ok
+    add Signs (2002 Film)/VIDEO_TS/VIDEO_TS.IFO [2015-02-22 10:10:05 GMT] chat: git ["--git-dir=/Volumes/plato/Films/.git","--work-tree=/Volumes/plato/Films","-c","core.bare=false","hash-object","-t","blob","-w","--stdin","--no-filters"]
+    ok
+
+Lots of files, ending in:
+
+    add Signs (2002 Film)/VIDEO_TS/VTS_13_1.VOB [2015-02-22 10:56:49 GMT] chat: git ["--git-dir=/Volumes/plato/Films/.git","--work-tree=/Volumes/plato/Films","-c","core.bare=false","hash-object","-t","blob","-w","--stdin","--no-filters"]
+    ok
+    [2015-02-22 10:56:49 GMT] read: git ["--git-dir=/Volumes/plato/Films/.git","--work-tree=/Volumes/plato/Films","-c","core.bare=false","ls-files","--modified","-z","--","Signs (2002 Film)"]
+
+
+It then hung for just under two hours before I hit ctrl+C. The files are on a remote SMB server mounted via OS X (hence direct mode) and git annex is being run on an OS X machine. git version 2.3.0, git-annex version 5.20150205. Both installed using homebrew. Any thoughts?
diff --git a/doc/forum/git_annex_add_freezes_on_direct_repo/comment_1_290df6fdd3c9042308638f1e8b66b805._comment b/doc/forum/git_annex_add_freezes_on_direct_repo/comment_1_290df6fdd3c9042308638f1e8b66b805._comment
new file mode 100644
index 0000000000..2d1792e577
--- /dev/null
+++ b/doc/forum/git_annex_add_freezes_on_direct_repo/comment_1_290df6fdd3c9042308638f1e8b66b805._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlEXDOqKvKFW9zl1DY5U9ofpXpeDRf6eN4"
+ nickname="Freddie"
+ subject="comment 1"
+ date="2015-02-24T13:00:50Z"
+ content="""
+I should mention that it does not hang when run on files.
+"""]]
diff --git a/doc/forum/git_annex_add_freezes_on_direct_repo/comment_2_3aa5d0ef823592baab79382851385979._comment b/doc/forum/git_annex_add_freezes_on_direct_repo/comment_2_3aa5d0ef823592baab79382851385979._comment
new file mode 100644
index 0000000000..a99f7cfdfd
--- /dev/null
+++ b/doc/forum/git_annex_add_freezes_on_direct_repo/comment_2_3aa5d0ef823592baab79382851385979._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-02-25T18:17:45Z"
+ content="""
+So you're using git-annex in a directory that is not on the local computer,
+but that uses a network filesystem?
+
+That seems likely to be the cause of your problem. For example, such
+filesystem often have trouble with POSIX file locks that git-annex uses.
+"""]]
diff --git a/doc/forum/git_annex_add_freezes_on_direct_repo/comment_3_cba1ba0c8b0f2e0f4186e7695d9df569._comment b/doc/forum/git_annex_add_freezes_on_direct_repo/comment_3_cba1ba0c8b0f2e0f4186e7695d9df569._comment
new file mode 100644
index 0000000000..d283ea37e6
--- /dev/null
+++ b/doc/forum/git_annex_add_freezes_on_direct_repo/comment_3_cba1ba0c8b0f2e0f4186e7695d9df569._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlEXDOqKvKFW9zl1DY5U9ofpXpeDRf6eN4"
+ nickname="Freddie"
+ subject="comment 3"
+ date="2015-02-25T18:28:48Z"
+ content="""
+Yeah, that's right. I though direct mode would avoid those problems, but evidently not - thanks anyway! :)
+"""]]
diff --git a/doc/forum/git_annex_alternative.mdwn b/doc/forum/git_annex_alternative.mdwn
new file mode 100644
index 0000000000..d7c41e66d9
--- /dev/null
+++ b/doc/forum/git_annex_alternative.mdwn
@@ -0,0 +1,10 @@
+I really like git-annex and am thankfull to its creator!
+
+I especially like the high level of abstraction it provides when handling backups or syncing.
+
+But git and my ext4 filesystem and HDD just hate the amount of files/folder/symlinks it throws at them and I am asking, what the alternatives are. I am especially looking for the numcopies and "--auto" functionallity. 
+
+
+Most alternatives I checked out (eps. distributed redundant filesystems) come up with other burdens or restrictions.
+
+Do you have any experience with different systems?
diff --git a/doc/forum/git_annex_assistant_-_Changing_repository_information.mdwn b/doc/forum/git_annex_assistant_-_Changing_repository_information.mdwn
new file mode 100644
index 0000000000..c4ef39a8f9
--- /dev/null
+++ b/doc/forum/git_annex_assistant_-_Changing_repository_information.mdwn
@@ -0,0 +1 @@
+Here's one thing I don't fully understand yet. If I add a remote repository, like an archive repository on Box—or if I want to change a transfer repository to an archive repository—do I need to add it or change it separately on each of my computers? Or just one? 
diff --git a/doc/forum/git_annex_assistant_-_Changing_repository_information/comment_1_cde71a410200a7478180748fdcde0352._comment b/doc/forum/git_annex_assistant_-_Changing_repository_information/comment_1_cde71a410200a7478180748fdcde0352._comment
new file mode 100644
index 0000000000..fa0c615173
--- /dev/null
+++ b/doc/forum/git_annex_assistant_-_Changing_repository_information/comment_1_cde71a410200a7478180748fdcde0352._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 1"
+ date="2014-04-17T20:59:43Z"
+ content="""
+This information is stored on the git-annex branch, and so it is synced between repositories with the rest of git-annex's data. You only need to change it in one place.. But it's also fine to change it in multiple places if necessary.
+"""]]
diff --git a/doc/forum/git_annex_assistant__44___share_with_other_devices.mdwn b/doc/forum/git_annex_assistant__44___share_with_other_devices.mdwn
new file mode 100644
index 0000000000..faebb14a1b
--- /dev/null
+++ b/doc/forum/git_annex_assistant__44___share_with_other_devices.mdwn
@@ -0,0 +1,3 @@
+I am trying to share files between my PC at home at that at work using the walkthrough here: http://git-annex.branchable.com/assistant/remote_sharing_walkthrough/. However, I don't have the option on my machine to "Share with other devices". Any ideas why this would be missing? I am using Ubuntu 13.04 if that helps. 
+
+Update: it now works after a software update, I guess I just had an older version of git-annex. Now, I have version 4.20130723. 
diff --git a/doc/forum/git_annex_assistant_repository_history__63__.mdwn b/doc/forum/git_annex_assistant_repository_history__63__.mdwn
new file mode 100644
index 0000000000..d357b78876
--- /dev/null
+++ b/doc/forum/git_annex_assistant_repository_history__63__.mdwn
@@ -0,0 +1,7 @@
+Hi,
+
+Even after googling for a while, I'm still having a hard time finding an answer for this:
+
+How can I access the revision history information for an annex-assistant repository?  For example, to recover a file on one computer that another computer deleted.  Or, to view how another computer modified a file.
+
+Thanks!
diff --git a/doc/forum/git_annex_assistant_repository_history__63__/comment_1_6f87f31e18cefedcc6bce95dbeb85a0b._comment b/doc/forum/git_annex_assistant_repository_history__63__/comment_1_6f87f31e18cefedcc6bce95dbeb85a0b._comment
new file mode 100644
index 0000000000..7425ef1eba
--- /dev/null
+++ b/doc/forum/git_annex_assistant_repository_history__63__/comment_1_6f87f31e18cefedcc6bce95dbeb85a0b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-01-15T18:59:01Z"
+ content="""
+The repository is just a git repository, so you can use whatever git tools
+you like to examine its history. For example, gitk.
+"""]]
diff --git a/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah.mdwn b/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah.mdwn
new file mode 100644
index 0000000000..37b86c4623
--- /dev/null
+++ b/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah.mdwn
@@ -0,0 +1,15 @@
+I keep a repo synced between machines over ssh. Assuming all the files are in sync, so no actual file transfer needs to takes place, when I do
+
+```
+git annex copy --fast --quiet --to blah
+```
+
+is quite slow, about 10 seconds, using 100% CPU on one core, just to decide nothing needs to be done. On the other hand, doing
+
+```
+  git annex copy --fast --quiet --from blah
+```
+
+takes about 1 second.
+
+I'm confused, as it seems to me that, since I'm using --fast, both transactions should use only locally available data, and both should need about the same amount of computing. Am I missing something? Can this be fixed?
diff --git a/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_1_5b6e0b749b01a97a6b52a2c1cca6e35a._comment b/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_1_5b6e0b749b01a97a6b52a2c1cca6e35a._comment
new file mode 100644
index 0000000000..90d4292789
--- /dev/null
+++ b/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_1_5b6e0b749b01a97a6b52a2c1cca6e35a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 1"
+ date="2013-07-17T19:11:38Z"
+ content="""
+How many files are in the directory tree you're copying?
+
+`copy --fast --to` does indeed avoid the check to see if the remote already has the file before copying it.
+
+However, it still needs to look in the location log to see which files are already present on the remote. Whereas `copy --from` can do a single stat of the file on disk to see if it's present in the local repo. Location log lookups are about as fast as I can make them, but they still require requesting info from out of the git repository. If you have a lot of files this otherwise minor difference in speed can stack up..
+"""]]
diff --git a/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_2_8f2567f4c4f6db2078211a87689757d3._comment b/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_2_8f2567f4c4f6db2078211a87689757d3._comment
new file mode 100644
index 0000000000..c0bfe9df28
--- /dev/null
+++ b/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_2_8f2567f4c4f6db2078211a87689757d3._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkkyBDsfOB7JZvPZ4a8F3rwv0wk6Nb9n48"
+ nickname="Abdó"
+ subject="comment 2"
+ date="2013-07-17T20:45:17Z"
+ content="""
+That example I gave: 10 sec vs 1 sec is on a repository of pictures with about 6200 files on a SSD.
+
+Oh, I think I understand the source of the asymmetry, now! So, `git annex copy --to` queries the location log file by file? I've tested a `git grep` on the git-annex branch as follows
+
+```
+git grep -e <repo uuid> git-annex
+```
+
+and seems to be quite fast, less than a second on my test repo. Could git annex make use of this to speed up bulk queries to the location log?
+
+"""]]
diff --git a/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_3_ab98121076b88f351fc8cd9197e6bf64._comment b/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_3_ab98121076b88f351fc8cd9197e6bf64._comment
new file mode 100644
index 0000000000..d5f399b309
--- /dev/null
+++ b/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_3_ab98121076b88f351fc8cd9197e6bf64._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.140"
+ subject="comment 3"
+ date="2013-07-18T17:39:37Z"
+ content="""
+Using git grep like that would only be an optimisation when it's acting on every file in the repository. If it's only copying a subdirectory, or a single file, git grep is likely to come out much slower.
+"""]]
diff --git a/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_4_cb13328add1b7a812efd817ad3dd1a4f._comment b/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_4_cb13328add1b7a812efd817ad3dd1a4f._comment
new file mode 100644
index 0000000000..0c70777a46
--- /dev/null
+++ b/doc/forum/git_annex_copy_--fast_--to_blah_much_slower_than_--from_blah/comment_4_cb13328add1b7a812efd817ad3dd1a4f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkkyBDsfOB7JZvPZ4a8F3rwv0wk6Nb9n48"
+ nickname="Abdó"
+ subject="comment 4"
+ date="2013-07-18T22:58:24Z"
+ content="""
+I see. Thanks!
+"""]]
diff --git a/doc/forum/git_annex_copy_more_informative_about_why_some_files_are_not_copied.mdwn b/doc/forum/git_annex_copy_more_informative_about_why_some_files_are_not_copied.mdwn
new file mode 100644
index 0000000000..3bb2fe1768
--- /dev/null
+++ b/doc/forum/git_annex_copy_more_informative_about_why_some_files_are_not_copied.mdwn
@@ -0,0 +1,59 @@
+I just spend an hour to understand why the following command did not do anything:
+
+    $ git annex copy --to someremote SomeDirectory
+
+With SomeDirectory containing a lot of file that are not in the someremote repository.
+I just realized that the annex from which I run the command did not contain those files either.
+
+I then did
+
+    $ git annex get SomeDirectory
+
+So that now the git annex copy command correctly copies the files to the someremote remote.
+
+I hope I won't fall into that trap again, but I think it is very annoying not to know why nothing happened.
+
+Wouldn't it be great if the git annex copy command would indicate why some file are not copied, like:
+
+    $ git annex copy --to someremote SomeDirectory
+    Cannot copy SomeFile1 since it is not present in here, (hint: run git annex get first)
+    Cannot copy SomeFile2 since it is not present in here, (hint: run git annex get first)
+    Cannot copy SomeFile3 since it is not present in here, (hint: run git annex get first)
+    ...
+
+May be this kind of information could be provided if the verbose flag is set.
+
+Another awesome (totally subjectively speaking) way of doing it could be to get the file before copying it
+
+    $ git annex copy --to someremote SomeDirectory
+    Cannot copy SomeFile1 since it is not present in here, attempting getting it first
+    get SomeFile1 (from someotherremote...)
+    SHA256E-s109353088--71734pq1p4qo6qs1p156r48s2290q7p61p1658029p103591nrs1rr708s064p59
+         12,615,808 100%  161.27kB/s    0:01:16 (xfr#1, to-chk=0/1)
+    ok
+    copy SomeFile1 (checking someremote...) (to someremote...)
+    SHA256E-s109353088--71734pq1p4qo6qs1p156r48s2290q7p61p1658029p103591nrs1rr708s064p59
+         12,615,808 100%  161.27kB/s    0:01:16 (xfr#1, to-chk=0/1)
+    ok
+    Cannot copy SomeFile2 since it is not present in here, attempting getting it first
+    get SomeFile2 (from someotherremote...)
+    SHA256E-s109353088--71734pq1p4qo6qs1p156r48s2290q7p61p1658029p103591nrs1rr708s064p59
+         12,615,808 100%  161.27kB/s    0:01:16 (xfr#1, to-chk=0/1)
+    ok
+    copy SomeFile2 (checking someremote...) (to someremote...)
+    SHA256E-s109353088--71734pq1p4qo6qs1p156r48s2290q7p61p1658029p103591nrs1rr708s064p59
+         12,615,808 100%  161.27kB/s    0:01:16 (xfr#1, to-chk=0/1)
+    ok
+    Cannot copy SomeFile3 since it is not present in here, attempting getting it first
+    get SomeFile3 (from someotherremote...)
+    SHA256E-s109353088--71734pq1p4qo6qs1p156r48s2290q7p61p1658029p103591nrs1rr708s064p59
+         12,615,808 100%  161.27kB/s    0:01:16 (xfr#1, to-chk=0/1)
+    ok
+    copy SomeFile3 (checking someremote...) (to someremote...)
+    SHA256E-s109353088--71734pq1p4qo6qs1p156r48s2290q7p61p1658029p103591nrs1rr708s064p59
+         12,615,808 100%  161.27kB/s    0:01:16 (xfr#1, to-chk=0/1)
+    ok
+
+We could also specify from which remote to get the file with
+
+    $ git annex copy --to someremote --from someotherremote SomeDirectory
diff --git a/doc/forum/git_annex_copy_more_informative_about_why_some_files_are_not_copied/comment_1_75445fc0e01ee99bae1c1f5a60e314bc._comment b/doc/forum/git_annex_copy_more_informative_about_why_some_files_are_not_copied/comment_1_75445fc0e01ee99bae1c1f5a60e314bc._comment
new file mode 100644
index 0000000000..15373be70d
--- /dev/null
+++ b/doc/forum/git_annex_copy_more_informative_about_why_some_files_are_not_copied/comment_1_75445fc0e01ee99bae1c1f5a60e314bc._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="206.74.132.139"
+ subject="comment 1"
+ date="2014-02-02T21:13:21Z"
+ content="""
+I think that this behavior of git-annex is quite useful once you get used to it. It can sometimes trip up new users, but new users would not know about some --explain switch that made it say why it skipped each file. So, I consider this a documentation issue, and I've added a section to the walkthrough to help users learn about it:
+
+<http://git-annex.branchable.com/walkthrough/quiet_please:_When_git-annex_seems_to_skip_files/>
+
+As far as copy --from --to, it has been suggested before; I think there is even a todo about it somewhere, but such remote-to-remote transfers are expensive and I would hope it would not normally be used.
+"""]]
diff --git a/doc/forum/git_annex_copy_to_google_drive_is_very_slow.mdwn b/doc/forum/git_annex_copy_to_google_drive_is_very_slow.mdwn
new file mode 100644
index 0000000000..90bdea14d7
--- /dev/null
+++ b/doc/forum/git_annex_copy_to_google_drive_is_very_slow.mdwn
@@ -0,0 +1,11 @@
+I'm trying to use [datalad](http://www.datalad.org) to manage some scientific data repositories. Datalad uses git annex. 
+
+I've set up an annex for my datalad/git repository using [`git-annex-remote-rclone`](https://github.com/git-annex-remote-rclone/git-annex-remote-rclone). The setup went fine, but the transfers with a Gigabit connection are of the order of 50-100 kbs. I'm trying to troubleshoot the issue. I'm a new user of git annex. The repository has about 10 GB of stuff.
+
+I'm focusing on `git annex` because I sidestep datalad by using `git annex copy --to=gdrive2`, this is as slow as using `datalad push --to=gdrive2`, which makes sense as the latter is a thin wrapper around `git-annex-copy`.
+
+Using an external drive instead of Google Drive was a little better, but it still took hours to copy the 10 GB. Not sure what's going on.
+
+I'm running this on a M1 MacBook Pro.
+
+Any ideas on how to troubeshoot this? 
diff --git a/doc/forum/git_annex_copy_to_google_drive_is_very_slow/comment_1_f3085ef9ddff51ee4110cc1000d26da2._comment b/doc/forum/git_annex_copy_to_google_drive_is_very_slow/comment_1_f3085ef9ddff51ee4110cc1000d26da2._comment
new file mode 100644
index 0000000000..42f02aa943
--- /dev/null
+++ b/doc/forum/git_annex_copy_to_google_drive_is_very_slow/comment_1_f3085ef9ddff51ee4110cc1000d26da2._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-21T18:03:40Z"
+ content="""
+How large are the individual files?
+
+With small enough files, non-bandwidth related overhead and/or TCL slow
+start can take more time than copying the file does, preventing saturating
+a connection.
+
+It sometimes helps to use -J10 or so.
+
+The --fast option can also speed up `git-annex copy`,
+see the [[git-annex-copy]] man page for details about it.
+"""]]
diff --git a/doc/forum/git_annex_copy_to_google_drive_is_very_slow/comment_2_539dbce8852a9b6ae20ff0e55e74fc2a._comment b/doc/forum/git_annex_copy_to_google_drive_is_very_slow/comment_2_539dbce8852a9b6ae20ff0e55e74fc2a._comment
new file mode 100644
index 0000000000..c87249890a
--- /dev/null
+++ b/doc/forum/git_annex_copy_to_google_drive_is_very_slow/comment_2_539dbce8852a9b6ae20ff0e55e74fc2a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="carlos@4c213b52601d57b650b22d9a246c59aea2c8f859"
+ nickname="carlos"
+ avatar="http://cdn.libravatar.org/avatar/ef0152bec3818b24d9318f6e7013e104"
+ subject="comment 2"
+ date="2023-03-21T21:34:01Z"
+ content="""
+Hi Joey,
+
+This is my current effort to copy ~6.7 GB using Datalad (git annex with rclone+Gdrive in the background)
+
+```
+Total:  53%|█████████████████████████████████████████████████████████████████▏                                                        | 3.49G/6.53G [8:25:38<7:21:03, 115k Bytes/s]
+```
+
+There are many small files in this repository for sure, but I haven't been able to get specific advice as to whether these very small speeds (even copying to an external drive took many hours) are expected given the bottlenecks you mention. Any feedback is welcome. 
+"""]]
diff --git a/doc/forum/git_annex_drop_not_freeing_space_on_filesystem.mdwn b/doc/forum/git_annex_drop_not_freeing_space_on_filesystem.mdwn
new file mode 100644
index 0000000000..93f64f78c0
--- /dev/null
+++ b/doc/forum/git_annex_drop_not_freeing_space_on_filesystem.mdwn
@@ -0,0 +1,25 @@
+I am using git-annex to store the output of a build process that produces large binary files (~1GB). These files are built on a number of workers which then commit the files to a central server (git annex add && copy to origin)
+
+I am trying to delete some of the older builds but have been unable to see any disk space be freed on the server (Disk usage is identical before and after the delete).
+
+    df -h 
+    mcchicken-srv://repo 284G 114G 157G  43% /srv/repo
+
+To delete the files I have performed the following:
+
+* git clone <repo-url>
+* git annex drop <1gb_file>
+* git rm <1gb_file>
+* git commit
+* git annex sync
+* [log into server]
+* git annex sync
+* git annex unused
+* git annex dropunused
+
+
+I have also tried other variations of the above technique that I have found online, but to no avail.
+
+In all cases the files appear to not be in the repo when a clone is performed, However the disk usage on the server never decreases.
+
+How would I delete the older builds in a manner that will free up disk space?
diff --git a/doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_1_ce1b32c2765edb695e5d9dc8f0ac86e3._comment b/doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_1_ce1b32c2765edb695e5d9dc8f0ac86e3._comment
new file mode 100644
index 0000000000..eb0903def2
--- /dev/null
+++ b/doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_1_ce1b32c2765edb695e5d9dc8f0ac86e3._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-09T17:09:43Z"
+ content="""
+`git annex drop` removes the file's content from the local repository.
+It does not affect other repositories, such as in your case the server.
+You could use `git annex drop --from origin` to remove the file from
+the origin repository.
+
+If `git annex unused` is not listing the deleted file as unused, there
+must be some git tag or branch that still refers to it.
+
+Also, `git annex dropunused` won't remove the last copy of a file unless you pass
+`--force`
+"""]]
diff --git a/doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_3_248cb012c87605479fb17fa4aadc1185._comment b/doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_3_248cb012c87605479fb17fa4aadc1185._comment
new file mode 100644
index 0000000000..3f35c5016b
--- /dev/null
+++ b/doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_3_248cb012c87605479fb17fa4aadc1185._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-11-30T19:42:47Z"
+ content="""
+git annex drop can only drop files that the local repository knows about.
+Perhaps you forgot to update your local repo (eg with `git annex sync`) so
+it didn't know about the files in the remote and so couldn't drop them.
+
+Of course, git annex drop also will refuse to drop a file from a repository
+if that not preserve the required number of copies of the file. It will
+tell you if this is the case.
+
+You need to post more details. I can assure you that git annex drop drops
+content from a repository.
+"""]]
diff --git a/doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_3_de4aa12c84a6025497f8c743a397ef63._comment b/doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_3_de4aa12c84a6025497f8c743a397ef63._comment
new file mode 100644
index 0000000000..554ef36bdb
--- /dev/null
+++ b/doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_3_de4aa12c84a6025497f8c743a397ef63._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="jhannwong@c9c7a67b5632a4bbc0c959cfeb3d340e02f28565"
+ nickname="jhannwong"
+ subject="Nope, git-annex drop is still not reducing size of .git/annex"
+ date="2015-11-20T13:32:11Z"
+ content="""
+A remote has 200MB of file contents in .git/annex.
+
+A local repo issues a ``git annex drop --from=myremote``.
+
+The remote .git/annex still has 200MB of file contents.
+
+Sometimes it works. I'm guessing it has to do with the order of commands issued.
+"""]]
diff --git a/doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_4_368b2c07dc7d98534a77c6153e8486ae._comment b/doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_4_368b2c07dc7d98534a77c6153e8486ae._comment
new file mode 100644
index 0000000000..47e7498c40
--- /dev/null
+++ b/doc/forum/git_annex_drop_not_freeing_space_on_filesystem/comment_4_368b2c07dc7d98534a77c6153e8486ae._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-11-30T20:00:20Z"
+ content="""
+I notice you also filed the bug report
+[[bugs/Unable_to_take_transfer_lock]], where you said something about having
+copied the repository over SMB using `cp` and some kind of OSX copy and
+paste. 
+
+So, if you did that, it seems likely that you have 2 git repositories with
+the same annex.uuid setting. In fact this is confirmed by [another bug
+report](http://git-annex.branchable.com/bugs/remote_repo_marked_as___34__here__34__/) you filed.
+
+Since git-annex expects each repository to have a unique annex.uuid, this is
+going to confuse it badly. Don't do that. Use `git clone` to make a clone of
+a git repository.
+"""]]
diff --git a/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__.mdwn b/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__.mdwn
new file mode 100644
index 0000000000..b0ec9cf9eb
--- /dev/null
+++ b/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__.mdwn
@@ -0,0 +1,24 @@
+Whenever I try to get a file with a non-English character, git annex gives me trouble that I don't have with English filenames from the same repo.  I'm hesitant to file a bug report here since the problem seems to stem from rsync not being able to handle the characters.  Here's the output (everything enclosed in pointy brackets are redacted):
+
+    get <artist>/<album>/<track> (from origin...) 
+    git-annex: /home/<username>/Music/.git/annex/transfer/upload/53e11324-041f-11e2-93ca-27250d76416f/SHA256-s7941079--c5a31f15302d57563d8cd35e43ba34669b5485a99b617a83c89fba02fb2ca981: commitBuffer: invalid argument (invalid character)
+    protocol version mismatch -- is your shell clean?
+    (see the rsync man page for an explanation)
+    rsync error: protocol incompatibility (code 2) at compat.c(174) [Receiver=3.0.9]
+
+    git-annex-shell: sendkey: 1 failed
+      rsync failed -- run git annex again to resume file transfer
+
+      Unable to access these remotes: origin
+
+      Try making some of these repositories available:
+            604f093f-a980-4740-a9df-d21b580a2ba4 -- origin (<remote>)
+    failed
+
+
+
+It spits out similar errors for all files with Japanese/German/French/special characters, and ends with this on the last line:
+
+    git-annex: get: 138 failed
+
+[[!tag forumbug]] [[bugs/done]]
diff --git a/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_1_292ee7c8b37cbd13f03eb67d0359b99e._comment b/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_1_292ee7c8b37cbd13f03eb67d0359b99e._comment
new file mode 100644
index 0000000000..3542dbd220
--- /dev/null
+++ b/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_1_292ee7c8b37cbd13f03eb67d0359b99e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="sauluskahn"
+ ip="67.171.218.222"
+ subject="comment 1"
+ date="2012-09-21T21:40:30Z"
+ content="""
+Also, git annex is 3.20120825 on both machines, and rsync is 3.0.9
+
+Both have no problem handling the characters on their own, but when I try to rsync them I get trouble.
+"""]]
diff --git a/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_2_f6341119fcfde5d8160c8f603b1a6fea._comment b/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_2_f6341119fcfde5d8160c8f603b1a6fea._comment
new file mode 100644
index 0000000000..080dba0e97
--- /dev/null
+++ b/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_2_f6341119fcfde5d8160c8f603b1a6fea._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.141"
+ subject="comment 2"
+ date="2012-09-21T23:23:04Z"
+ content="""
+git-annex 3.20120825 is not an actual release, just some version number used in git head.
+
+This bug, TTBOMK, was introduced in version 3.20120721, and fixed by git commit 0b12db64d834979d49ed378235b0c19b34e4a4d6 last Sunday.
+"""]]
diff --git a/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_3_8ad3a1d1fe5995d61e5e137280bc76c3._comment b/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_3_8ad3a1d1fe5995d61e5e137280bc76c3._comment
new file mode 100644
index 0000000000..b61eff5065
--- /dev/null
+++ b/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_3_8ad3a1d1fe5995d61e5e137280bc76c3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.141"
+ subject="comment 3"
+ date="2012-09-21T23:23:52Z"
+ content="""
+I take that back about 3.20120825, it was so a real release! :) Anyway, bug is fixed in git head, and there will be a release along soon with it.
+"""]]
diff --git a/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_4_86b61b0484f3f4ecff657e46333b3d4f._comment b/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_4_86b61b0484f3f4ecff657e46333b3d4f._comment
new file mode 100644
index 0000000000..678c13b7af
--- /dev/null
+++ b/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_4_86b61b0484f3f4ecff657e46333b3d4f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="sauluskahn"
+ ip="67.171.218.222"
+ subject="comment 4"
+ date="2012-09-22T03:01:02Z"
+ content="""
+Sounds good, I'll get the next version through cabal and let you know if it's fixed.  Thanks for your time!
+"""]]
diff --git a/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_5_5ffac00d08d26acaba8c3513b24c4d65._comment b/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_5_5ffac00d08d26acaba8c3513b24c4d65._comment
new file mode 100644
index 0000000000..c328519d77
--- /dev/null
+++ b/doc/forum/git_annex_failing_to_get_non-English_filenames.__Rsync_problem__63__/comment_5_5ffac00d08d26acaba8c3513b24c4d65._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="sauluskahn"
+ ip="67.171.218.222"
+ subject="comment 5"
+ date="2012-09-22T03:02:15Z"
+ content="""
+>I'll let you know if it's *not* fixed.
+
+Typo.
+"""]]
diff --git a/doc/forum/git_annex_file_content_replaced_with_symlink_content.mdwn b/doc/forum/git_annex_file_content_replaced_with_symlink_content.mdwn
new file mode 100644
index 0000000000..654a1af9e2
--- /dev/null
+++ b/doc/forum/git_annex_file_content_replaced_with_symlink_content.mdwn
@@ -0,0 +1,32 @@
+I have a git-annex repository on a USB drive (full of pictures), however, when I go to the actual drive:
+
+    $ cd /run/media/hinmanm/MINIDRIVE1/pics
+    $ ls -lh australia-2014-03
+
+I get:
+
+    -rw-r--r--. 1 hinmanm hinmanm 1.1K Aug 22  2015 IMG_20140321_181130.jpg
+    -rw-r--r--. 1 hinmanm hinmanm 1.1K Aug 22  2015 IMG_20140321_181137.jpg
+    -rw-r--r--. 1 hinmanm hinmanm 1.1K Aug 22  2015 IMG_20140321_181221.jpg
+    -rw-r--r--. 1 hinmanm hinmanm 1.1K Aug 22  2015 IMG_20140321_181228.jpg
+    -rw-r--r--. 1 hinmanm hinmanm 1.1K Aug 22  2015 IMG_20140321_181233.jpg
+    ... hundreds more .jpg files that are all 1.1K ...
+
+It looks like the files think they are symlinks, instead of pictures:
+
+```
+$ cat australia-2014-03/IMG_20140321_181233.jpg
+XSym
+0201
+2ac7522707415dfe67ad5afa1ab3e516
+../.git/annex/objects/5F/Xw/SHA256E-s2499217--ad9525adf9a82e4ac83c89fd2bddfd2b2aef690ccbbddf38d91abc85f72509f6.jpg/SHA256E-s2499217--ad9525adf9a82e4ac83c89fd2bddfd2b2aef690ccbbddf38d91abc85f72509f6.jpg
+```
+
+Running `git-annex fsck` doesn't do anything, and trying to do `git-annex indirect` gives me:
+
+```
+$ git-annex indirect                                  
+git-annex: This repository seems to be on a crippled filesystem, you must use direct mode.
+```
+
+It looks like there is still a bunch of data in `.git/annex`, as its 6.7gb. Is there a way I can get the files back and get git-annex working again, right now none of my photos are available :(
diff --git a/doc/forum/git_annex_file_content_replaced_with_symlink_content/comment_1_f6f4be7161d4c35c7de1d9751ddbd3c3._comment b/doc/forum/git_annex_file_content_replaced_with_symlink_content/comment_1_f6f4be7161d4c35c7de1d9751ddbd3c3._comment
new file mode 100644
index 0000000000..c55ee2d954
--- /dev/null
+++ b/doc/forum/git_annex_file_content_replaced_with_symlink_content/comment_1_f6f4be7161d4c35c7de1d9751ddbd3c3._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="jimparis"
+ subject="comment 1"
+ date="2016-08-16T14:41:34Z"
+ content="""
+It seems like that is how [OSX stores symlinks on FAT filesystems](https://opensource.apple.com/source/msdosfs/msdosfs-185.2/msdosfs.kextproj/msdosfs.kmodproj/fat.h?txt) and how [Samba stores symlinks on Windows](https://wiki.samba.org/index.php/UNIX_Extensions#Storing_symlinks_on_Windows_servers).  Did you initially make the drive on one of those systems?  Using the same system again would probably make them appear like normal usable symlinks.
+
+At the very least, since you said `.git/annex` is full of data, I think you should be able to find the photo at the location listed in the last line of those files:
+
+```
+../.git/annex/objects/5F/Xw/SHA256E-s2499217--ad9525adf9a82e4ac83c89fd2bddfd2b2aef690ccbbddf38d91abc85f72509f6.jpg/SHA256E-s2499217--ad9525adf9a82e4ac83c89fd2bddfd2b2aef690ccbbddf38d91abc85f72509f6.jpg
+```
+
+"""]]
diff --git a/doc/forum/git_annex_file_content_replaced_with_symlink_content/comment_2_da848024c40eb65e6214bd95b73e078e._comment b/doc/forum/git_annex_file_content_replaced_with_symlink_content/comment_2_da848024c40eb65e6214bd95b73e078e._comment
new file mode 100644
index 0000000000..2e619f856d
--- /dev/null
+++ b/doc/forum/git_annex_file_content_replaced_with_symlink_content/comment_2_da848024c40eb65e6214bd95b73e078e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="thnetos"
+ subject="RE: comment 1"
+ date="2016-08-16T20:39:38Z"
+ content="""
+Thanks for the info, that was very helpful. This is indeed a FAT partition I created on OSX.
+
+Unfortunately, I no longer use OSX, so I don't have a machine that can read this data. I'll write a script to grab it from the contents of the symlink file itself to hopefully retrieve everything. In the future, I'll partition my external harddrives with ext4 :)
+
+Thanks again!
+"""]]
diff --git a/doc/forum/git_annex_file_content_replaced_with_symlink_content/comment_3_cc703ef5015527425572002295568923._comment b/doc/forum/git_annex_file_content_replaced_with_symlink_content/comment_3_cc703ef5015527425572002295568923._comment
new file mode 100644
index 0000000000..43f5107ce0
--- /dev/null
+++ b/doc/forum/git_annex_file_content_replaced_with_symlink_content/comment_3_cc703ef5015527425572002295568923._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-09-21T20:44:26Z"
+ content="""
+Gold star for @jimparis!
+
+Another way to get out of this situation would be to edit the files,
+and remove the initial lines so it contains a single line that is
+the link target of the symlink (the bit with .git/annex/objects in it).
+
+Then, `git annex fsck` would be able to fix up the files.
+"""]]
diff --git a/doc/forum/git_annex_get_--want-get_another__95__repo.mdwn b/doc/forum/git_annex_get_--want-get_another__95__repo.mdwn
new file mode 100644
index 0000000000..4ed0878766
--- /dev/null
+++ b/doc/forum/git_annex_get_--want-get_another__95__repo.mdwn
@@ -0,0 +1,68 @@
+Hi,
+
+Git-annex is really awesome. It has made my life really easier when having to
+move files around.
+
+Yet, I have been struggling with a use case that I cannot get working with git
+annex.
+
+In short, my request is: could it be possible to have --want-get and --want-drop
+accept a repository as argument to match the preferred content of that
+repository instead of here?
+
+Now, let me explain why I need this:a
+
+All my files are stored into a NAS accessible via a local network.
+
+I have an annex in my desktop computer. Using preferred content (via "git annex
+wanted") and "git annex get|drop --auto", I am able to almost automatically
+handle what files are put into my computer. What I do is to "git annex wanted"
+to indicate what I want to be here and launch a home made script that basically
+does "git annex get --auto" and "git annex drop --auto".
+
+Let's say I have a android phone to which I connect via ssh over adb. It
+contains a git repository but few files are in it. It has no wifi and so no
+access to the network, meaning no access to the NAS.
+
+The links between annexes then looks like:
+
+    NAS <-> Computer <-> Phone
+
+When I want to put a file into my phone, I generally launch "git annex get file"
+from my computer (then I get the file from the NAS) and "git annex copy --to
+phone file".
+
+I want to be able to automatise this a bit by playing with preferred content
+(like I do with my computer). This means that I want to launch "git annex
+wanted" to edit the preferred content of the phone annex and then "git annex get
+--auto" and launch "git annex copy --auto --to phone". This way, when I am not
+in front of my computer, I can still from my phone run "git annex wanted here
+'preferred content'" and hope for my synchronisation scripts (run in my
+computer) to put the good files into my phone.
+
+Obviously those commands won't work since the git annex get --auto command will
+only get what my computer wants, not what my phone wants.
+
+The intuitive (IMHO) way to do would be to launch:
+
+    git annex get --want-get phone
+	git annex copy --auto --to phone
+	git annex drop --auto
+
+With "--want-get repository" meaning, "Matches files that the preferred content
+settings for the repository make it want to get.".
+
+For the time being, I succeed in doing this with
+
+	OLD_WANTED=$(git annex wanted here)
+	git annex wanted here $(git annex wanted phone)
+	git annex copy --auto --to phone
+	git annex wanted ${OLD_WANTED}
+	git annex drop --auto
+
+This is complicated and adds two extra commits in the git-annex branch (one for
+each setting of git annex wanted) each time I call the script.
+
+What do you think?
+
+Thanks for reading.
diff --git a/doc/forum/git_annex_get_--want-get_another__95__repo/comment_1_0be0b3981ddd0743ff26cf6d396e521d._comment b/doc/forum/git_annex_get_--want-get_another__95__repo/comment_1_0be0b3981ddd0743ff26cf6d396e521d._comment
new file mode 100644
index 0000000000..7a58e35d62
--- /dev/null
+++ b/doc/forum/git_annex_get_--want-get_another__95__repo/comment_1_0be0b3981ddd0743ff26cf6d396e521d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.154"
+ subject="comment 1"
+ date="2014-03-12T17:15:23Z"
+ content="""
+Well, I suppose this is doable, but the way this scenario is generally handled is to make a transfer repository (which your desktop is serving as here) have a preferred content expression that makes it want files that the client repositories (phones) want, until the files have reached the clients:
+
+In your case you could have:
+
+    (not inallgroup=phones and ($phone_preferred_content)) or ($desktop_preferred_content)
+
+Where `$desktop_preferred_content` is whatever files the desktop actually wants on its own, and `$phone_preferred_content` is a copy of the preferred content setting for the phone.
+
+To make this work, you also need to put your phone in the phones group.
+"""]]
diff --git a/doc/forum/git_annex_get_--want-get_another__95__repo/comment_2_b1ead1085a87818625579bf1ef151b5d._comment b/doc/forum/git_annex_get_--want-get_another__95__repo/comment_2_b1ead1085a87818625579bf1ef151b5d._comment
new file mode 100644
index 0000000000..1f8ce270e8
--- /dev/null
+++ b/doc/forum/git_annex_get_--want-get_another__95__repo/comment_2_b1ead1085a87818625579bf1ef151b5d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.154"
+ subject="comment 2"
+ date="2014-03-12T17:16:59Z"
+ content="""
+BTW expressing this in the preferred content as above also has the benefit that you can use the new `git annex sync --content` on the desktop and it will automatically get files, copy the right ones to the phone, and drop any then-unwanted files.
+"""]]
diff --git a/doc/forum/git_annex_get_--want-get_another__95__repo/comment_3_cf2018852c84b0bf1ac061def6f0ac5d._comment b/doc/forum/git_annex_get_--want-get_another__95__repo/comment_3_cf2018852c84b0bf1ac061def6f0ac5d._comment
new file mode 100644
index 0000000000..c6bd20e1ff
--- /dev/null
+++ b/doc/forum/git_annex_get_--want-get_another__95__repo/comment_3_cf2018852c84b0bf1ac061def6f0ac5d._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm3vKzS4eOWYpKMoYXqMIjNsIg_nYF-loU"
+ nickname="Konubinix"
+ subject="That does it but not totally"
+ date="2014-03-13T11:36:02Z"
+ content="""
+I agree with the fact that it answers my initial question.
+
+Nevertheless, I guess it is really annoying to have to change the preferred content in two locations each time I change want to modify what is on my phone.
+Indeed, I quite often change what should be really present on my phone, depending on several factors (my mood, the time I will have in transports and the phase of the moon).
+
+The reason why I use \"git annex wanted\" is that it is straightforward: I just launch : \"git annex wanted phone include=some/file\" and that's all.
+
+With the solution you propose, I would have to each time additionally launch \"git annex wanted here '(not inallgroup=phones and (include=some/file)) or ($desktop_preferred_content)'\"
+
+Where I probably have to previously launch \"git annex wanted here\" to remember what is the preferred content of my computer (and put it in $desktop_preferred_content).
+
+Another option would be to run \"git annex vicfg\" and edit both fields manually, but IMHO this appears also to be too complicated relatively to the use case.
+
+About your second comment, I really enjoy the idea if \"git annex sync --content\", but it is really long in big repositories. I guess it is because I cannot restrict the command to a directory like I do with get, drop, move and copy.
+
+Besides, the use case wants to get the files whenever they are and copy them only to the phone. With git annex sync --content, the files are also put in the other repositories.
+
+For the time being, I prefer falling back to explicit commands that are much faster when I know a directory to sync \"git annex get --auto directory && git annex copy --auto --to phone directory\".
+
+For example, I just tried \"git annex sync --content phone\" and I killed it after 5 minutes and nothing was copied yet. With the set of two commands above, the synchronization of directory (get --to phone directory + drop --from here directory) took about 3 minutes.
+"""]]
diff --git a/doc/forum/git_annex_get_--want-get_another__95__repo/comment_4_22562e8f1f2f91b9f9a5939ec9006cb5._comment b/doc/forum/git_annex_get_--want-get_another__95__repo/comment_4_22562e8f1f2f91b9f9a5939ec9006cb5._comment
new file mode 100644
index 0000000000..25624c2c04
--- /dev/null
+++ b/doc/forum/git_annex_get_--want-get_another__95__repo/comment_4_22562e8f1f2f91b9f9a5939ec9006cb5._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm3vKzS4eOWYpKMoYXqMIjNsIg_nYF-loU"
+ nickname="Konubinix"
+ subject="Precision of the use case"
+ date="2014-03-13T11:47:59Z"
+ content="""
+I realized that the directory restriction described earlier is not clear. Let me explain it.
+
+Say I have a big repository of files with the following structure.
+
+A/...
+B/...
+C/...
+D/D1/...
+D/D2/...
+D/D3/...
+
+Imagine that each of A, B, C and D contains a lot of files.
+
+Now imagine that I have often put in the preferred content of my phone files in one of D1, D2 or D3. (for instance, include=D/D1/*)
+
+I implicitly know that I can restrict the command to D, and I can rely on preferred content to know what file from D I have to put into my phone.
+
+Then, I can run
+      $ git annex get --auto D
+      $ git annex copy --auto --to phone D
+      $ git annex drop --auto D
+
+This in my use case takes 3 minutes.
+
+When I run
+     $ git annex sync --content phone
+
+git annex goes recursively through A, B and C and that takes a long time (much more than 3 minutes). This time is really wasted since I know I only want to sync files from D.
+
+I cannot test the behavior of \"git annex sync --content\", but if I restrict the sync to phone, will it take the files from the NAS to put them on the phone?
+If I don't precise phone in the command line, it will try to sync with other repositories not in sync that I don't want to be in sync for the time being.
+"""]]
diff --git a/doc/forum/git_annex_get___60__file__62___fails___40__Action_blocked_by_GIT__41__.mdwn b/doc/forum/git_annex_get___60__file__62___fails___40__Action_blocked_by_GIT__41__.mdwn
new file mode 100644
index 0000000000..8e38629922
--- /dev/null
+++ b/doc/forum/git_annex_get___60__file__62___fails___40__Action_blocked_by_GIT__41__.mdwn
@@ -0,0 +1,11 @@
+Hi,
+  After a long time, and having a fresh machine, I cloned a repo I've been using without problems. When I try to get the content of some files, I get the following error:
+
+> git annex get  im/fixed_regions/melanomas/melanomas_mp/ejemplo18/mean_bounds.png
+
+get im/fixed_regions/melanomas/melanomas_mp/ejemplo18/mean_bounds.png (from origin...) 
+
+git-annex-shell: Action blocked by GIT_ANNEX_SHELL_LIMITED
+
+I've checked that the file is present in the origin remote. I'm sure it is a pretty silly thing, but it's been a while since I used git-annex.
+Thanks for the help and kudos for this great tool!
diff --git a/doc/forum/git_annex_get___60__file__62___fails___40__Action_blocked_by_GIT__41__/comment_1_476b96f4ffd57bfe6e66c5388a19e9a5._comment b/doc/forum/git_annex_get___60__file__62___fails___40__Action_blocked_by_GIT__41__/comment_1_476b96f4ffd57bfe6e66c5388a19e9a5._comment
new file mode 100644
index 0000000000..600ee7976b
--- /dev/null
+++ b/doc/forum/git_annex_get___60__file__62___fails___40__Action_blocked_by_GIT__41__/comment_1_476b96f4ffd57bfe6e66c5388a19e9a5._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-07-08T14:34:04Z"
+ content="""
+It seems that on the remote host there is something that sets
+the `GIT_ANNEX_SHELL_LIMITED` environment variable.
+
+That would not itself be enough to cause this problem normally.
+So I suspect that the remote host also has a very old
+version of git-annex installed on it. One that does not support
+that `git-annex shell p2pstdio` command. So it applies that environment
+variable when it would not normally apply.
+
+The solution then is to upgrade the remote host's git-annex to version
+6.20180228 or newer, which will support that command.
+"""]]
diff --git a/doc/forum/git_annex_get___60__file__62___fails___40__Action_blocked_by_GIT__41__/comment_2_6da3b78489ea140b321d780ef669bcd3._comment b/doc/forum/git_annex_get___60__file__62___fails___40__Action_blocked_by_GIT__41__/comment_2_6da3b78489ea140b321d780ef669bcd3._comment
new file mode 100644
index 0000000000..ebb7dedeaf
--- /dev/null
+++ b/doc/forum/git_annex_get___60__file__62___fails___40__Action_blocked_by_GIT__41__/comment_2_6da3b78489ea140b321d780ef669bcd3._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="drunken_sapo"
+ avatar="http://cdn.libravatar.org/avatar/95a4912e969b86df221626188ecc8f94"
+ subject="Confirmed your suspiction"
+ date="2022-07-23T02:28:18Z"
+ content="""
+Hi Joey, thanks for your tip and sorry for the delay in answering! I got stalled by other projects
+
+Here is how the landscape looks like:
+1) On the local machine:
+git-annex version: 10.20220526-gc6b112108
+2) On the remote machine:
+git-annex version: 6.20180227
+
+I will upgrade and let you know how it goes!
+Thanks so much again!
+"""]]
diff --git a/doc/forum/git_annex_get_creates_a_new_uuid.mdwn b/doc/forum/git_annex_get_creates_a_new_uuid.mdwn
new file mode 100644
index 0000000000..72dcd97373
--- /dev/null
+++ b/doc/forum/git_annex_get_creates_a_new_uuid.mdwn
@@ -0,0 +1,6 @@
+From git-annex(1), init should precede any operation of git-annex as a safety feature.
+
+However git cloning a repo and running `git annex get` created a new uuid for that repo, which got
+propagated via sync.
+
+Is this intended behaviour?
diff --git a/doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment b/doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment
new file mode 100644
index 0000000000..d2f3c4f734
--- /dev/null
+++ b/doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 1"
+ date="2013-07-30T20:24:06Z"
+ content="""
+From the man page:
+
+> Until a repository (**or one of its remotes**) has been initialized
+> git-annex will refuse to operate on it, to avoid accidentally
+> using it in a repository that was not intended to have an annex.
+
+So, yes, it assumes that if a repository has a git-annex branch already, git-annex is being used, and no explicit init is necessary. You can still run `git annex init` after the fact if you like.
+"""]]
diff --git a/doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi.mdwn b/doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi.mdwn
new file mode 100644
index 0000000000..ccdbfbc7fe
--- /dev/null
+++ b/doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi.mdwn
@@ -0,0 +1,11 @@
+Ok, so I just set up git-annex on by Raspberry Pi 3 B (from apt from the raspbian repos), and got it working with a phone backup workflow. (udev automation, the specifics are in [a gist](https://gist.github.com/astronouth7303/624b499d213e607617187fee6a190ed1), but I don't think I'm doing anything super weird?)
+
+I'm encountering a problem where it apparently just spins at 100% CPU on a small text file.
+
+The command that's hanging is `git-annex smudge --clean sdcard/Android/data/ccc71.bmw/support/crash_reports.txt`
+
+This has happened on this file from both `git annex add` and `git annex sync` (with and without `--content`).
+
+The file itself is 2006B in size, and just contains some plaintext information (some header-type data and a java backtrace). But this process has been running for over an hour, and it's taken exceptionally long before.
+
+This seems really abnormal? The repo is 8.7GB overall, and it's running on an RPi from a microSD card, but taking hours to perform repository operations seem off.
diff --git a/doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi/comment_1_06b5d0c9c6037ffdafab6c01763061de._comment b/doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi/comment_1_06b5d0c9c6037ffdafab6c01763061de._comment
new file mode 100644
index 0000000000..8acdd27112
--- /dev/null
+++ b/doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi/comment_1_06b5d0c9c6037ffdafab6c01763061de._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="jamie@b5676b90eec0401ca8faac7c972eaf5676891601"
+ nickname="jamie"
+ avatar="http://cdn.libravatar.org/avatar/b9aa71e237c7bc49af04ec66194be8e0"
+ subject="strace"
+ date="2019-03-16T22:17:37Z"
+ content="""
+I attached strace, and it seems to be deadlocked?
+
+It just spews this continuously:
+
+    --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=NULL}} ---
+    sigreturn({mask=[]})                    = 84432420
+    futex(0x5085624, FUTEX_WAIT_PRIVATE, 5795, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+    --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=NULL}} ---
+    sigreturn({mask=[]})                    = 84432420
+    futex(0x5085624, FUTEX_WAIT_PRIVATE, 5795, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+    --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=NULL}} ---
+    sigreturn({mask=[]})                    = 84432420
+    futex(0x5085624, FUTEX_WAIT_PRIVATE, 5795, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+    --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=NULL}} ---
+    sigreturn({mask=[]})                    = 84432420
+    futex(0x5085624, FUTEX_WAIT_PRIVATE, 5795, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+
+"""]]
diff --git a/doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi/comment_2_471a44594af15057dd4781e759013627._comment b/doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi/comment_2_471a44594af15057dd4781e759013627._comment
new file mode 100644
index 0000000000..4227d64808
--- /dev/null
+++ b/doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi/comment_2_471a44594af15057dd4781e759013627._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jamie@b5676b90eec0401ca8faac7c972eaf5676891601"
+ nickname="jamie"
+ avatar="http://cdn.libravatar.org/avatar/b9aa71e237c7bc49af04ec66194be8e0"
+ subject="comment 2"
+ date="2019-03-17T03:29:31Z"
+ content="""
+I just checked on it, it did eventually process that file, but `git annex sync` has been running for over 6 hours and is still going.
+"""]]
diff --git a/doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi/comment_3_66f89cded0da36e96099d29542f2455b._comment b/doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi/comment_3_66f89cded0da36e96099d29542f2455b._comment
new file mode 100644
index 0000000000..bf98faecb9
--- /dev/null
+++ b/doc/forum/git_annex_hanging_in_smudge_on_2k_file_on_rpi/comment_3_66f89cded0da36e96099d29542f2455b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jamie@b5676b90eec0401ca8faac7c972eaf5676891601"
+ nickname="jamie"
+ avatar="http://cdn.libravatar.org/avatar/b9aa71e237c7bc49af04ec66194be8e0"
+ subject="comment 3"
+ date="2019-03-19T03:32:32Z"
+ content="""
+Yeah... it's taking >24hrs to do the full unlock/add/sync cycle. That's going to be problematic.
+"""]]
diff --git a/doc/forum/git_annex_info__58___local_annex_keys__63__.mdwn b/doc/forum/git_annex_info__58___local_annex_keys__63__.mdwn
new file mode 100644
index 0000000000..e1a79f038a
--- /dev/null
+++ b/doc/forum/git_annex_info__58___local_annex_keys__63__.mdwn
@@ -0,0 +1,27 @@
+When I run `git annex info`, it stops to ask me for "local annex keys":
+
+    $ git annex info
+    repository mode: indirect
+    trusted repositories: 0
+    semitrusted repositories: 3
+            00000000-0000-0000-0000-000000000001 -- web
+            1xxxxxx7-6xx1-4xx1-8xx8-5xxxxxxxxxx1 -- here (usbdisk)
+            bxxxxxx6-bxxe-4xx2-bxxe-fxxxxxxxxxxf -- origin (local)
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: 36.25 gigabytes (+1 megabyte reserved)
+    local annex keys: 
+
+What are these "local annex keys"? 
+
+*Edit*: Ah! it wasn't asking me anything, just echoing my keystrokes. It was counting keys stored in the annex, and taking a while. Sorry for the noise!
+
+    [...]
+    local annex keys: 19586
+    local annex size: 33.96 gigabytes
+    annexed files in working tree: 19814
+    size of annexed files in working tree: 35.12 gigabytes
+    bloom filter size: 16 mebibytes (3.9% full)
+    backend usage: 
+            SHA256E: 39400
+
diff --git a/doc/forum/git_annex_init_timeout.mdwn b/doc/forum/git_annex_init_timeout.mdwn
new file mode 100644
index 0000000000..5bd64f943a
--- /dev/null
+++ b/doc/forum/git_annex_init_timeout.mdwn
@@ -0,0 +1,43 @@
+I'm trying git-annex for the first time and having some issues.
+
+I have a WD MyBook 2TB Cloud Drive and using OSX Sierra.
+
+I want to create an Annex on one the NAS smb shares and then a Amazon Cloud Drive replica for offsite backup.
+
+When I run `git annex init` from the mounted share in OSX it fails with the below:
+
+```
+git-annex init
+init
+  Detected a filesystem without POSIX fcntl lock support.
+
+  Enabling annex.pidlock.
+
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Disabling core.symlinks.
+
+  Enabling direct mode.
+A300 second timeout exceeded while waiting for pid lock file .git/annex/pidlock
+```
+
+Below are the results of `git-annex version`
+
+```
+git-annex version: 6.20170101
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: darwin x86_64
+```
+
+
+
+Is it possible to have an annex on a SMB share?
diff --git a/doc/forum/git_annex_init_timeout/comment_1_e456f5367af5a5a3a31fc982952079e3._comment b/doc/forum/git_annex_init_timeout/comment_1_e456f5367af5a5a3a31fc982952079e3._comment
new file mode 100644
index 0000000000..06aed071a9
--- /dev/null
+++ b/doc/forum/git_annex_init_timeout/comment_1_e456f5367af5a5a3a31fc982952079e3._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-10T18:06:28Z"
+ content="""
+git-annex needs flock locking to be supported by the filesystem it's used
+on. There's a workaround using pid locks, but that is apparently not
+working on OSX in your case. I've only tested it on Linux.
+
+I tried reproducing this on OSX by enabling annex.pidlock before using
+git-annex. But it worked ok.
+
+So, I suspect there may be a problem with the network filesystem's handling
+of the pidlock file. One likely problem is if it doesn't support hard
+links, since the pidlock file is hard linked into place.
+
+You can check if it supports hard links by running this on the drive where
+you had the problem:
+
+	touch foo
+	ln foo bar
+"""]]
diff --git a/doc/forum/git_annex_init_timeout/comment_2_bf15b686b07c5e6e95796affa497a541._comment b/doc/forum/git_annex_init_timeout/comment_2_bf15b686b07c5e6e95796affa497a541._comment
new file mode 100644
index 0000000000..c7f39ae530
--- /dev/null
+++ b/doc/forum/git_annex_init_timeout/comment_2_bf15b686b07c5e6e95796affa497a541._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-02-10T18:52:59Z"
+ content="""
+I was able to reproduce the problem with a FAT filesystem
+mounted on Linux, if I manually enabled annex.pidlock
+before git-annex init. Hard linking does not work on FAT, so that
+matches my earlier guess.
+
+I've committed a fix for this, so try again with a recent autobuild of
+git-annex and it will probably fix your problem.
+"""]]
diff --git a/doc/forum/git_annex_init_timeout/comment_3_1e733fad01e6b420c7fd9f7832e9b3f7._comment b/doc/forum/git_annex_init_timeout/comment_3_1e733fad01e6b420c7fd9f7832e9b3f7._comment
new file mode 100644
index 0000000000..a047306c0e
--- /dev/null
+++ b/doc/forum/git_annex_init_timeout/comment_3_1e733fad01e6b420c7fd9f7832e9b3f7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="git annex get ... transfer lock issues"
+ date="2017-04-23T07:36:08Z"
+ content="""
+The fix a couple of months ago appears to allow `git annex init` to complete on a SMB file share, which is great.  But FTR there are currently [issues with file transfers](https://git-annex.branchable.com/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/) (link is to bug report about failing to get transfer lock), so use with a NAS is still \"work in progress\".
+
+Ewen
+"""]]
diff --git a/doc/forum/git_annex_lock__47__unlock__47__fix_on_non-committed_files.mdwn b/doc/forum/git_annex_lock__47__unlock__47__fix_on_non-committed_files.mdwn
new file mode 100644
index 0000000000..3e7c562114
--- /dev/null
+++ b/doc/forum/git_annex_lock__47__unlock__47__fix_on_non-committed_files.mdwn
@@ -0,0 +1,15 @@
+In an ideal world, one could just use `git annex diffdriver` to compare annex'ed files. However, sometimes one might need an approach that is constructed simpler. For example, I want to run a comparison utility that is in a container which translates my paths for better reproducibility of scientific results. Or I have a colleage who is not familiar with all the intricacies of git annex and knows git just enough `git checkout` version 1, move it, the `git checkout` the second version and compare these two. Then the situation can arise that one has a symlink to `.git/annex/objects/...` which is named differently than what is saved in the tree. 
+
+In that case, `git annex unlock` refuses to work:
+
+```
+mv file file_version1
+git annex unlock file_version1
+error: pathspec 'file' did not match any file(s) known to git
+Did you forget to 'git add'?
+unlock: 1 failed
+```
+
+Similar story goes with `git lock` and `git fix`. I think it would be a nice behaviour if these commands would just do their work on the new file name. For example, git unlock would replace a symlink with its content even if the file is not committed with this name. 
+
+Is it possible to implement this in git annex?
diff --git a/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis.mdwn b/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis.mdwn
new file mode 100644
index 0000000000..f1aa5cc06d
--- /dev/null
+++ b/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis.mdwn
@@ -0,0 +1 @@
+I just started experimenting with git annex, and I found that I would like to have a way to figure out metadata (well, size. Maybe modification date) of a non-local file. I first checked if there is "git annex ls" (which could list known files in an ls-like way) and found "git annex whereis" as somewhat a replacement, but it does not give metadata information.
diff --git a/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_1_7fba10b85f4d9289c7782eccef46949e._comment b/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_1_7fba10b85f4d9289c7782eccef46949e._comment
new file mode 100644
index 0000000000..379b9f976b
--- /dev/null
+++ b/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_1_7fba10b85f4d9289c7782eccef46949e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-11-14T22:46:35Z"
+ content="""
+When  I want that, I ls -l the file and look at the symlink to the key. Ie, in SHA1-s10481423--efc7eec0d711212842cd6bb8f957e1628146d6ed the size is 10481423 bytes. 
+"""]]
diff --git a/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_2_7dcec124ea7d0291ed40d80e2ffd5c7e._comment b/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_2_7dcec124ea7d0291ed40d80e2ffd5c7e._comment
new file mode 100644
index 0000000000..3dd14bf010
--- /dev/null
+++ b/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_2_7dcec124ea7d0291ed40d80e2ffd5c7e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-11-14T22:48:03Z"
+ content="""
+It might make sense to put this functionality in git annex find. Perhaps a format string with a %s for example. 
+"""]]
diff --git a/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_3_24c54ed70220974b98700bf717d1e770._comment b/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_3_24c54ed70220974b98700bf717d1e770._comment
new file mode 100644
index 0000000000..67ff59d324
--- /dev/null
+++ b/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_3_24c54ed70220974b98700bf717d1e770._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="sudoman"
+ ip="216.15.125.93"
+ subject="ls symlink workaround; idea for a solution"
+ date="2014-09-29T18:58:23Z"
+ content="""
+as a workaround, you could make a bash alias for `ls -l` -> `ls -lL`. the problem with this is that links to other links are fully dereferenced.
+
+what looks like this in a non-git-annex directory with `ls -lh`:
+
+    total 3.8M
+    -rw-r--r-- 1 sudoman sudoman 3.8M Sep 29 13:56 42x3551_02.pdf
+    lrwxrwxrwx 1 sudoman sudoman   14 Sep 29 14:00 tmp -> 42x3551_02.pdf
+
+looks like this in an indirect git annex repo with `ls -lhL`:
+
+    total 7.5M
+    -r--r--r-- 1 sudoman sudoman 3.8M Sep 29 13:56 42x3551_02.pdf
+    -r--r--r-- 1 sudoman sudoman 3.8M Sep 29 13:56 tmp
+
+
+the ls alias is a bit hackish, but for some purposes it's an improvement.
+
+rsync may work as desired when using a command like `rsync -l --safe-links` (haven't tried it. users might want to experiment by adding `--exclude` to that command.)
+
+
+a potential solution for ls (and cp) could be the inclusion of a patched version under `git annex util ls`. writing shim programs using `LD_PRELOAD` instead of patching may drastically reduce the amount of code needing future security updates.
+
+"""]]
diff --git a/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__.mdwn b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__.mdwn
new file mode 100644
index 0000000000..592e26b936
--- /dev/null
+++ b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__.mdwn
@@ -0,0 +1,18 @@
+I'm testing out git-annex between a few computers one being a mac (osx 10.9) and a laptop (linux mint 16).  With a vps running git annex as a transfer annex.
+
+Anyway sync is *almost* working...
+
+When I add files on my mac's annex they upload, and go to my laptop as they should.
+
+When I add files on my laptop's annex they upload, and the mac "downloads" them but only creates broken symlinks to the files.
+
+
+I looked in the log and nothing out of the ordinary is happening... is this a bug with the osx version or what?
+
+
+**more info**  
+
+* the symlink on the osx annex is symlinking to a file in .git/annex/objects  
+* the osx annex changes the aliases to real files every time I restart the git annex daemon  
+
+Thanks!
diff --git a/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_1_6889c4452e636474b4e70798b404fed2._comment b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_1_6889c4452e636474b4e70798b404fed2._comment
new file mode 100644
index 0000000000..c97f26e860
--- /dev/null
+++ b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_1_6889c4452e636474b4e70798b404fed2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 1"
+ date="2013-12-12T17:11:59Z"
+ content="""
+It sounds like the contents of the files are being successfully transferred.
+
+It may be that you're using an old and buggy version of git-annex, in which the direct mode code lost track of things and so failed to update the tree correctly when receiving the content of a file. If so, you could fix it by upgrading git-annex and running `git annex fsck`.
+"""]]
diff --git a/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_2_978fc11c463a457382fddd668cd1d0dd._comment b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_2_978fc11c463a457382fddd668cd1d0dd._comment
new file mode 100644
index 0000000000..b3a848ffe3
--- /dev/null
+++ b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_2_978fc11c463a457382fddd668cd1d0dd._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkipQLNyt8RHREHpg2k5wdYeRSCCvSNSBg"
+ nickname="Tim"
+ subject="I had this same problem too"
+ date="2014-01-04T01:00:10Z"
+ content="""
+I was using the 2013-12-13 build and now I've upgrade to the 2014-01-03 build.  git-annex has symlinked some important workspace.xml files to nowhere.  One looks like this:
+
+workspace.xml -> ../../../.git/annex/objects/M2/8W/SHA256E-s68106--90e9cc4f617c9034db1bf462d058b82c59ade0be58de1d3a3e2f8c02606631c2.xml/SHA256E-s68106--90e9cc4f617c9034db1bf462d058b82c59ade0be58de1d3a3e2f8c02606631c2.xml
+
+The referenced file doesn't exist.  Actually, that entire M2 directory doesn't exist.
+
+This has cost me a lot of time trying to fix this.  I tried git-annex fsck and I get this message:
+
+ ** No known copies exist of XXXXXXX/workspace.xml
+
+\"XXXXXXX\" is a path I needed to obscure
+
+I can see it in the git-annex repo but it is a reference to a symlink that doesn't exist.  Is there any way to get this file back?  git-annex whereis tells me it is nowhere.  This appears to be real data loss.
+"""]]
diff --git a/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_3_4420bd3afaecd7536b02fc08cee82dbe._comment b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_3_4420bd3afaecd7536b02fc08cee82dbe._comment
new file mode 100644
index 0000000000..3f4ac940ee
--- /dev/null
+++ b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_3_4420bd3afaecd7536b02fc08cee82dbe._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkipQLNyt8RHREHpg2k5wdYeRSCCvSNSBg"
+ nickname="Tim"
+ subject="Sorry for the bad formatting on that last post"
+ date="2014-01-04T17:16:51Z"
+ content="""
+I have some additional information that may be helpful.  I had git-annex syncing my Mac with a Debian system.  It appears that at some point in time the Debian system's NFS connection disconnected and then may have reconnected with sshfs.  I don't know if this happened when the syncing issue occurred or not and I can't validate that since the machine was rebooted but it is possible that that caused git-annex on the Mac to choke while syncing and create the phantom symlink.  I am experiencing NFS issues at the moment so it may have contributed to this hiccup.
+"""]]
diff --git a/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_4_99286f17a87049c303f2aa34c0a90286._comment b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_4_99286f17a87049c303f2aa34c0a90286._comment
new file mode 100644
index 0000000000..d21d871458
--- /dev/null
+++ b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_4_99286f17a87049c303f2aa34c0a90286._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 4"
+ date="2014-01-06T15:48:36Z"
+ content="""
+@Tim, you do not seem to be having the problem that the OP described.
+
+It is completely normal for git-annex to represent a file whose content is not present in the repository as a broken symlink.
+Typically, git-annex preserves at least one copy of the file in one of your repositories. But if you `git annex add $file; git annex drop --force $file`, you will be left in exactly the situation you describe.
+
+You can use `git annex log $file` to see a log of which repositories contained a copy of the file in the past, and see what times the file was removed from each repository. This might give clues to what operation caused the last copy of the file to be lose.
+"""]]
diff --git a/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_5_39bad7441dcea4da4b389700301233de._comment b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_5_39bad7441dcea4da4b389700301233de._comment
new file mode 100644
index 0000000000..f7975fc0ee
--- /dev/null
+++ b/doc/forum/git_annex_on_osx_only_creating_symlinks__63____63__/comment_5_39bad7441dcea4da4b389700301233de._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkipQLNyt8RHREHpg2k5wdYeRSCCvSNSBg"
+ nickname="Tim"
+ subject="I'll start another thread"
+ date="2014-01-06T18:17:44Z"
+ content="""
+Let me start another thread then and not pollute this one.  Thanks!
+"""]]
diff --git a/doc/forum/git_annex_repair_--force_fails_without_explanation.mdwn b/doc/forum/git_annex_repair_--force_fails_without_explanation.mdwn
new file mode 100644
index 0000000000..3ce126a982
--- /dev/null
+++ b/doc/forum/git_annex_repair_--force_fails_without_explanation.mdwn
@@ -0,0 +1,34 @@
+I have a repo for which `git annex fsck --all` goes through without any complaints, and `git fsck` produces
+
+    Checking object directories: 100% (256/256), done.
+    error in tree 97abf6de76c0c56593f78d2f55b4c60d04345281: gitmodulesSymlink: .gitmodules is a symbolic link
+    Checking objects: 100% (998477/998477), done.
+    Checking connectivity: 998477, done.
+    dangling tree f9a2b542f57770c135631de1ae590475fc0caa54
+
+but running `git annex repair --force`,
+
+    repair Running git fsck ...
+    Unpacking all pack files.
+    Unpacking objects: 100% (998477/998477), 64.95 MiB | 359.00 KiB/s, done.
+    Initialized empty Git repository in /tmp/tmprepoqPmkhi/.git/
+    Trying to recover missing objects from remote A.
+    fatal: '[a path I censored]' does not appear to be a git repository
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+    Trying to recover missing objects from remote B.
+    Unpacking all pack files.
+    Unpacking objects: 100% (923941/923941), 63.54 MiB | 367.00 KiB/s, done.
+    [A couple of other cases of remotes not available.]
+    failed
+    git-annex: repair: 1 failed
+
+Is the failure likely related to the `gitmodulesSymlink` error? If so, what could I do about it? If not, how do I figure out what's going on?
+
+Regarding the `.gitmodules` complaint: The repo has a subfolder with its own `.git` and `.gitmodules`, and although nothing in there is commited into the main repo now, I did in the past accidentally, temporarily commit the `subfolder/.gitmodules` into the main repo.
+
+I don't actually find anything wrong with the repo, the only reason I'm running `repair` on it is because a remote of it is missing some files, although it claims to be all synced up.
+
+This is on version 8.20200226. I would be happy to try on a more recent one, if there's a way to do so on Ubuntu without compiling from source.
diff --git a/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_1_716cbfe900552a453965ac4abd44e7a4._comment b/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_1_716cbfe900552a453965ac4abd44e7a4._comment
new file mode 100644
index 0000000000..e735f48c10
--- /dev/null
+++ b/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_1_716cbfe900552a453965ac4abd44e7a4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2020-10-11T14:08:27Z"
+ content="""
+I don't think your problem is related to the \"git fsck\" error. Also, it doesn't look like the failure of \"git annex repair\" is related to the \"git fsck\" error either.
+What does \"git status\" say in the repo that is missing files?
+"""]]
diff --git a/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_2_f8ff4c8663d8b7bb30f7b7763be33501._comment b/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_2_f8ff4c8663d8b7bb30f7b7763be33501._comment
new file mode 100644
index 0000000000..f4b7420fbb
--- /dev/null
+++ b/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_2_f8ff4c8663d8b7bb30f7b7763be33501._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mhauru"
+ avatar="http://cdn.libravatar.org/avatar/2532433a0207ba772e6ca964e61899c0"
+ subject="comment 2"
+ date="2020-10-12T17:07:58Z"
+ content="""
+Thanks for trying to help! `git status` on the repo that's missing files (and has old versions of some other files, I just noticed) shows nothing remarkable: Some staged modifications, some other unstaged ones, and some untracked files, but they don't include the missing and/or out-of-date ones.
+"""]]
diff --git a/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_3_682cb114d133713f80bdda97a4435a5e._comment b/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_3_682cb114d133713f80bdda97a4435a5e._comment
new file mode 100644
index 0000000000..17bc5e103e
--- /dev/null
+++ b/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_3_682cb114d133713f80bdda97a4435a5e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2020-10-12T17:20:37Z"
+ content="""
+Hmm, is the broken repo actually on the same branch and same commit as a healthy repo?
+"""]]
diff --git a/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_4_cbc49405ab99e8722216739732ce394d._comment b/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_4_cbc49405ab99e8722216739732ce394d._comment
new file mode 100644
index 0000000000..2830733430
--- /dev/null
+++ b/doc/forum/git_annex_repair_--force_fails_without_explanation/comment_4_cbc49405ab99e8722216739732ce394d._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-10-12T19:04:49Z"
+ content="""
+This is not the kind of problem that `git-annex repair` can fix.
+The problems it fixes are all where one clone of a repo has gotten some
+object files corrupted by eg disk problems, but other clones still have
+good copies of those object files.
+
+The reason `git-annex repair` reports it failed is because it sees that
+`git fsck` is reporting a problem and the things it's tried to do didn't
+fix it.
+
+Are the "missing files" missing in that their annexed content is not
+present, or missing in that there is no annex symlink at all? In the former
+case, you need `git annex fsck` on those files, or `git-annex get`. In the
+latter case, if `git status` doesn't show a missing file as deleted, that
+would be a very strange problem with git.
+"""]]
diff --git a/doc/forum/git_annex_repairs_since_thursday.mdwn b/doc/forum/git_annex_repairs_since_thursday.mdwn
new file mode 100644
index 0000000000..c1763b1f90
--- /dev/null
+++ b/doc/forum/git_annex_repairs_since_thursday.mdwn
@@ -0,0 +1,5 @@
+I have not tried to get git annex to work in a bit. My troubles of recovering this annex repo have been documented [here](http://git-annex.branchable.com/forum/git_annex_wants_to_repair_every_time_it__39__s_running/), [here](http://git-annex.branchable.com/forum/how_to_disaster_recovery/) and [here](http://git-annex.branchable.com/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/). On Thurs day I thought I give it another try. Since Thursday it tries to repair two out of three repos: my local repo on my laptop and my repo on an external harddrive I have. The b2 special remote repo appears to be fine, or not checked, I'm not sure.
+
+What can I do, to get it working again?
+
+P.S.: In my mind this setup should work like this: I want to move contents from my laptop to the external hdd and to b2 so that there are two copies at all times. I want to use git annex so that I don't need to carry all that stuff around with me anymore, because space on my ssd is sparse.
diff --git a/doc/forum/git_annex_repairs_since_thursday/comment_1_38b4563db47ce9bdc52eab5506de20f8._comment b/doc/forum/git_annex_repairs_since_thursday/comment_1_38b4563db47ce9bdc52eab5506de20f8._comment
new file mode 100644
index 0000000000..89fa07cc73
--- /dev/null
+++ b/doc/forum/git_annex_repairs_since_thursday/comment_1_38b4563db47ce9bdc52eab5506de20f8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="openmedi"
+ avatar="http://cdn.libravatar.org/avatar/563ffaff3b492c579bd8f094472e4506"
+ subject="comment 1"
+ date="2017-02-19T15:27:08Z"
+ content="""
+It's now Sunday and I stopped all three running git-annex processes on my system, after git used about 80% of my cpu, the daemon.log showing nothing and git annex info -F not responding.
+"""]]
diff --git a/doc/forum/git_annex_repairs_since_thursday/comment_2_b072ad2864e1caa7459d17d3426c8eee._comment b/doc/forum/git_annex_repairs_since_thursday/comment_2_b072ad2864e1caa7459d17d3426c8eee._comment
new file mode 100644
index 0000000000..726227c43d
--- /dev/null
+++ b/doc/forum/git_annex_repairs_since_thursday/comment_2_b072ad2864e1caa7459d17d3426c8eee._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="openmedi"
+ avatar="http://cdn.libravatar.org/avatar/563ffaff3b492c579bd8f094472e4506"
+ subject="comment 2"
+ date="2017-02-19T22:03:26Z"
+ content="""
+I am now trying to just start again. I have initiated a completely new repo to which I'm now adding files from the old repo manually or rather I have already done so, set up two remotes (flash drive and external hdd) and have now a repo which hold at least those files which were unproblematic to move over.
+
+I try now to recover any lost files and at the same time try to get rid of the repo on my laptop. Therefore I initiated on my external drive for disk space reasons a cloned copy of my local repo to which I'm now `get`ing  everything via `git annex get -A`. After this is done, I'll move the missing files, if there are any, over to the new repo by hand and will drop all files on my laptop's repo (to make sure that the new external hdd repo includes everything) and then delete any and all repos and special remotes.
+
+A fresh start seems to be the best way to go, since the old repo just couldn't be repaired by the assistant or me for that matter - or so it seemed.
+"""]]
diff --git a/doc/forum/git_annex_sync__58___only_git-annex.mdwn b/doc/forum/git_annex_sync__58___only_git-annex.mdwn
new file mode 100644
index 0000000000..84ae140cdd
--- /dev/null
+++ b/doc/forum/git_annex_sync__58___only_git-annex.mdwn
@@ -0,0 +1,3 @@
+Hi,
+
+i have an already existing git repository with a branch (*master*) and i added git annex to it (*git annex init*). Now i want to synchronise the file tracking information with annex through *git annex sync*, but keep the master branch unsynchronised (i want push/pull it manually as there are not only annexed files but also code). What is the best approach for my setup?
diff --git a/doc/forum/git_annex_sync__58___only_git-annex/comment_1_2be68ed36a1e6bfc896d5aea9463d3c7._comment b/doc/forum/git_annex_sync__58___only_git-annex/comment_1_2be68ed36a1e6bfc896d5aea9463d3c7._comment
new file mode 100644
index 0000000000..bf90184aa9
--- /dev/null
+++ b/doc/forum/git_annex_sync__58___only_git-annex/comment_1_2be68ed36a1e6bfc896d5aea9463d3c7._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-20T15:19:13Z"
+ content="""
+Sounds like you should just use normal `git push`/`git pull` commands.
+Works fine with git-annex. 
+
+Just be sure to include the `git-annex` branch in your pushes.
+Eg, `git push origin master git-annex`
+
+You'll probably want to run `git annex merge` after pulling, to merge the
+local and remote git-annex branches.
+"""]]
diff --git a/doc/forum/git_annex_sync__58___only_git-annex/comment_2_50e137e4d278dfd0103a41aff0cfa3a9._comment b/doc/forum/git_annex_sync__58___only_git-annex/comment_2_50e137e4d278dfd0103a41aff0cfa3a9._comment
new file mode 100644
index 0000000000..10f3792b35
--- /dev/null
+++ b/doc/forum/git_annex_sync__58___only_git-annex/comment_2_50e137e4d278dfd0103a41aff0cfa3a9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlog_5wIICaMcrKTexlFNA6IO6UTp323aE"
+ nickname="Torkaly"
+ subject="comment 2"
+ date="2014-10-22T08:56:43Z"
+ content="""
+Thank you for your response.
+
+So annex looks like it's not really designed to work with an existing git repository, but only standalone?!
+"""]]
diff --git a/doc/forum/git_annex_sync__58___only_git-annex/comment_3_7753f8276478e0e05c10dba2b84bbc49._comment b/doc/forum/git_annex_sync__58___only_git-annex/comment_3_7753f8276478e0e05c10dba2b84bbc49._comment
new file mode 100644
index 0000000000..49a61c0b76
--- /dev/null
+++ b/doc/forum/git_annex_sync__58___only_git-annex/comment_3_7753f8276478e0e05c10dba2b84bbc49._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.96"
+ subject="comment 3"
+ date="2014-10-22T16:18:16Z"
+ content="""
+I struggle to see how you could draw that conclusion from what I said.
+
+git-annex will work fine in an existing git repository. You can mix regular git commands like `git add`, `git push`, `git pull`, `git merge` with git-annex commands like `git annex add`, `git annex copy --to origin`, `git annex get`, `git annex merge`, in the same repository.
+
+The `git annex sync` command effcetively runs `git commit; git pull; git annex merge; git push; git annex copy --to origin; git annex get`. If you don't want to run all those commands at once, you don't want to run `git annex sync`. That will not prevent you from using git-annex in any way.
+"""]]
diff --git a/doc/forum/git_annex_sync__58___only_git-annex/comment_5_52010f21a15d76d68986aa1fba29aaf1._comment b/doc/forum/git_annex_sync__58___only_git-annex/comment_5_52010f21a15d76d68986aa1fba29aaf1._comment
new file mode 100644
index 0000000000..cee2a9bd22
--- /dev/null
+++ b/doc/forum/git_annex_sync__58___only_git-annex/comment_5_52010f21a15d76d68986aa1fba29aaf1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlog_5wIICaMcrKTexlFNA6IO6UTp323aE"
+ nickname="Torkaly"
+ subject="comment 5"
+ date="2014-10-29T18:51:29Z"
+ content="""
+Hi,
+
+thank you for your response. I just want to control my branches (master, dev and so on ...) by myself, without sync/master or sync/dev and without merging it automatically. But the git-annex branch should be populated between the repositories \"magically\" (some kind of \"git annex syncannex\"). As annex can't deliver such a basic functionality i assumed, that it was not designed to work with existing \"real\" git repositories.
+"""]]
diff --git a/doc/forum/git_annex_sync__58___only_git-annex/comment_6_df94154fbbc4edbf7ff658f61bde48b5._comment b/doc/forum/git_annex_sync__58___only_git-annex/comment_6_df94154fbbc4edbf7ff658f61bde48b5._comment
new file mode 100644
index 0000000000..8772255eb4
--- /dev/null
+++ b/doc/forum/git_annex_sync__58___only_git-annex/comment_6_df94154fbbc4edbf7ff658f61bde48b5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-31T20:25:40Z"
+ content="""
+I have explained clearly in comment #1 above how to do what you want to do,
+using git-annex, so it is a pity if still think that "annex
+can't deliver such a basic functionality". 
+
+It can. I have explained how. I don't know how to explain any better.
+"""]]
diff --git a/doc/forum/git_annex_sync_destroys_data_on_shallow_clones.mdwn b/doc/forum/git_annex_sync_destroys_data_on_shallow_clones.mdwn
new file mode 100644
index 0000000000..1b88cd0a74
--- /dev/null
+++ b/doc/forum/git_annex_sync_destroys_data_on_shallow_clones.mdwn
@@ -0,0 +1,2 @@
+I just migrated binaries from native git file tracking to git annex. Then I went on to clone the repo on a different device. Because older commits still contain the binaries I did a shallow clone. After that I wanted to fetch a few binaries from annex and ran ```git annex init; git annex sync```. 
+To my surprise instead of somehow working out the annex metadata with the remote it just force pushed an empty git-annex branch to the remote. Luckily I was just testing things out and had a backup available but for people who rely on a service like gitlab to access their annex repository when traveling this can end up being a very nasty surprise. I don't exactly know how this could best be fixed but force pushing without asking isn't a good solution in my opinion. Maybe git-annex-init could check if a remote already has annex metadata and pull that. git-annex-sync could fail and give you the option to add a force flag or work out how to merge things (which shouldn't be too hard when the local metadata is completely empty)
diff --git a/doc/forum/git_annex_sync_destroys_data_on_shallow_clones/comment_1_431fef51e00f19cdf206a5ab97570be5._comment b/doc/forum/git_annex_sync_destroys_data_on_shallow_clones/comment_1_431fef51e00f19cdf206a5ab97570be5._comment
new file mode 100644
index 0000000000..072ffbd49d
--- /dev/null
+++ b/doc/forum/git_annex_sync_destroys_data_on_shallow_clones/comment_1_431fef51e00f19cdf206a5ab97570be5._comment
@@ -0,0 +1,84 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-10-20T18:14:38Z"
+ content="""
+Well, I tried to reproduce this, following your instructions to the extent
+there were clear.
+
+I made a repository, added some files to git, and committed. 
+Then `git rm --cached` the files, and `git-annex add` to add them to
+git-annex, and committed. So master had 2 commits, an older commit
+where the files were in git, and a newer commit where the files are in
+git-annex. The git-annex branch had a couple of commits as well.
+
+Then I cloned:
+
+	git clone --depth 1 localhost:/tmp/path/to/repo clone
+
+In the clone, that made master be a single commit. There was no
+origin/git-annex branch in the clone, like there normally would be
+in a non-shallow clone.
+
+Then I ran `git-annex init; git annex sync`:
+
+	joey@darkstar:/tmp/clone>git annex init
+	init  ok
+	(recording state in git...)
+	joey@darkstar:/tmp/clone>git annex sync
+	commit 
+	On branch master
+	Your branch is up to date with 'origin/master'.
+	
+	nothing to commit, working tree clean
+	ok
+	pull origin 
+	ok
+	push origin 
+	Enumerating objects: 6, done.
+	Counting objects: 100% (6/6), done.
+	Delta compression using up to 4 threads
+	Compressing objects: 100% (3/3), done.
+	Writing objects: 100% (5/5), 450 bytes | 450.00 KiB/s, done.
+	Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
+	To localhost:/tmp/repo
+	 * [new branch]      master -> synced/master
+	 * [new branch]      git-annex -> synced/git-annex
+	ok
+
+At this point, the git-annex branch in the remote repository is not
+destroyed. It contains a merge between the branch that was there before
+the clone and the git-annex branch that was synced from the clone.
+Looks just fine.
+
+In the clone, there is still no origin/git-annex branch, and the git-annex
+branch has only the changes that git-annex committed to it in the clone.
+
+So, the clone still doesn't know that it can get the annexed files from origin.
+But nothing is "destroyed".
+
+This does not seem like the best possible behavior, it would be better if,
+after git-annex sync, it fetched origin/git-annex (either the latest
+commit or all of them) and merged it into the local git-annex branch.
+
+What's going on is, the shallow clone gets remote.origin.fetch set
+to "+refs/heads/master:refs/remotes/origin/master". So, attempting
+to fetch any other branch from origin will always skip creating
+a tracking branch.
+
+All you have to do, then is 
+
+	git config '+refs/heads/*:refs/remotes/origin/*'
+
+That preserves master as a shallow clone, while letting
+the git-annex branch be fetched. Or, alternatively, `git fetch --unshallow`.
+
+Maybe git-annex sync could detect this situation and force fetch 
+the git-annex branch. (eg, git fetch origin git-annex, which does
+actually fetch the refs, followed by manually setting
+origin/git-annex to `FETCH_HEAD`) That would leave workflows using
+`git push` and `git pull` still with the problem. And it might be that
+someone who wants a shallow clone also wants the git-annex branch to be
+cloned shallowly and would object if its full history was fetched by that.
+I have not found a way yet to fetch the git-annex branch shallowly.
+"""]]
diff --git a/doc/forum/git_annex_sync_dies___40__sometimes__41__.mdwn b/doc/forum/git_annex_sync_dies___40__sometimes__41__.mdwn
new file mode 100644
index 0000000000..84f9d11257
--- /dev/null
+++ b/doc/forum/git_annex_sync_dies___40__sometimes__41__.mdwn
@@ -0,0 +1,22 @@
+I've set up git annex on my laptop and on a remote server using the gitolite v3 git-annex branch.
+When I 'git annex sync' from my laptop (mac OSX) to the server, and 'git annex copy . --to server' all works fine.
+
+Later, I tried to clone the repository on another machine (linux 2.6.32). again all is well. I 'git annex init' in the new clone and then try to 'git annex sync' -- now I run into problems.
+
+Specifically, the first request for the configlist (when I do 'git annex --debug sync' all is fine until the configlist request) somehow breaks and my ssh session shows:
+
+muxserver_listen bind(): Input/output error
+
+This seems to confuse the client, who now believes that git annex is not installed on the server (it is).
+
+If I issue the same command as git annex via ssh, all seems to work ok with the caveats below:
+
+I have a feeling it's related to the -o 'ControlPersist=yes' argument that git-annex appears to be giving ssh.  If I include this option when I run via ssh, ssh dies:
+
+>ssh git@server -o "ControlMaster=auto" -o "ControlPersist=yes" "git-annex-shell 'configlist' '/~/PRJ'"
+command-line: line 0: Bad configuration option: ControlPersist
+
+
+(note that it appears to be ok to leave "ControlMaster=auto" in).
+
+any thoughts?
diff --git a/doc/forum/git_annex_sync_dies___40__sometimes__41__/comment_1_48bbac0545bf13bbf04da723e418d037._comment b/doc/forum/git_annex_sync_dies___40__sometimes__41__/comment_1_48bbac0545bf13bbf04da723e418d037._comment
new file mode 100644
index 0000000000..9445421a42
--- /dev/null
+++ b/doc/forum/git_annex_sync_dies___40__sometimes__41__/comment_1_48bbac0545bf13bbf04da723e418d037._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 1"
+ date="2013-10-15T18:16:23Z"
+ content="""
+Since this seems to be a problem with ssh connection caching, you can disable that:
+
+git config annex.sshcaching false
+
+Seems like the problem would be in the version of ssh you have installed on your linux client. Or possibly some interaction between its version and the server's version. 
+
+Since linux 2.6.32 is quite old, I'll bet you have an old ssh too.. what version?
+"""]]
diff --git a/doc/forum/git_annex_sync_remove_all_recently_added_files.mdwn b/doc/forum/git_annex_sync_remove_all_recently_added_files.mdwn
new file mode 100644
index 0000000000..769811b218
--- /dev/null
+++ b/doc/forum/git_annex_sync_remove_all_recently_added_files.mdwn
@@ -0,0 +1,40 @@
+since a bit of time i have a strange probleme.
+My git annex environement look like this :
+
+A      E  
+|\    /  
+| C--D  
+|/    \  
+B      F.....G  
+
+the dot point because G is an external drive and can be plug anywhere else.
+let's say my last comit is **db1a9a**
+If i add some file on the repo from G and sync point to point like :
+i'm in G : 
+git annex sync F
+a new commit is created say **61dacd**
+go F
+git annex sync D
+go D
+git annex sync E ...etc
+
+at some point my commit 61dacd becomme the parent of a new commit i dono the source ... let's say **4fcdae**
+
+in git log i found 
+
+commit **4fcdae**... (HEAD -> master, B/synced/ma
+ster, B/master, C/synced/master, C/master, synced/master)
+
+and that commit just undo all the change done by the previous one, indeed : 
+
+git diff **4fcdae** **db1a9a**
+-> nothing
+
+this... force me to play with branch like every time and anoyed me alot. I don't understand what's happening here.
+Does any one have any clue/insight on what i can do to fix this/investigate ?
+
+All repo are at the commit db1a9a before i start...
+
+best regards
+
+
diff --git a/doc/forum/git_annex_sync_remove_all_recently_added_files/comment_1_6c059f7b2eb9d213bc0865739832b5d2._comment b/doc/forum/git_annex_sync_remove_all_recently_added_files/comment_1_6c059f7b2eb9d213bc0865739832b5d2._comment
new file mode 100644
index 0000000000..5a15fc286d
--- /dev/null
+++ b/doc/forum/git_annex_sync_remove_all_recently_added_files/comment_1_6c059f7b2eb9d213bc0865739832b5d2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="karel-de-macil"
+ avatar="http://cdn.libravatar.org/avatar/46688332185c941113a9c9827cb093e9"
+ subject="comment 1"
+ date="2020-07-23T10:17:06Z"
+ content="""
+just see i may-be should have put this in bug :( please forgive me.
+"""]]
diff --git a/doc/forum/git_annex_sync_remove_all_recently_added_files/comment_2_27a56e101f7c3fcba90b4c69fa39f4c4._comment b/doc/forum/git_annex_sync_remove_all_recently_added_files/comment_2_27a56e101f7c3fcba90b4c69fa39f4c4._comment
new file mode 100644
index 0000000000..8a0aa7b057
--- /dev/null
+++ b/doc/forum/git_annex_sync_remove_all_recently_added_files/comment_2_27a56e101f7c3fcba90b4c69fa39f4c4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="qiang.fang@ddaed0de00c2925f8036e6c61ce6e12654263ada"
+ nickname="qiang.fang"
+ avatar="http://cdn.libravatar.org/avatar/5a55c6bcb3eaacde1355f9aca0d9384a"
+ subject="comment 2"
+ date="2021-03-06T00:03:51Z"
+ content="""
+Are you working on different computers?
+Is the system time in sync?
+"""]]
diff --git a/doc/forum/git_annex_sync_update_remote.mdwn b/doc/forum/git_annex_sync_update_remote.mdwn
new file mode 100644
index 0000000000..d6aa2ffbc7
--- /dev/null
+++ b/doc/forum/git_annex_sync_update_remote.mdwn
@@ -0,0 +1,50 @@
+I have a repo on my cluster. On my system I cloned it by
+
+```
+[my_system] $ git clone ssh://jed//home/tdegeus/tmp/mydata cluster
+```
+
+This works fine to get files from the cluster. 
+
+However, I also want to send files from my system to the cluster and to be able to drop files on the cluster. The problem is, however, that I have no stable IP to SSH to my system, so I don't have a good way to add my system as remote on the cluster. I thought that running 
+
+```
+[my_system] $ git annex sync
+```
+
+from my laptop would be enough. But that does not seems to sufficiently update the repo on the cluster.
+
+From example on the cluster adding some files
+
+```
+[ssh->jed] $ git annex add foo.h5
+[ssh->jed] $ git commit -m "my message"
+```
+
+and then downloading on my system
+
+```
+[my_system] $ git annex sync
+[my_system] $ git annex get foo.h5
+[my_system] $ git annex sync
+```
+
+works fine.
+
+But then back on the cluster running
+
+```
+[ssh->jed] $ git annex drop foo.h5
+```
+
+results, erroneously, in 
+
+```
+foo.h5 a.h5 (unsafe)
+  Could only verify the existence of 0 out of 1 necessary copy
+
+  Maybe add some of these git remotes (git remote add ...):
+  	ee3f4fc7-db8f-4c45-8c40-92e96d046999 -- tdegeus:~/Downloads/annex/cluster
+
+  (Use --force to override this check, or adjust numcopies.)
+```
diff --git a/doc/forum/git_annex_sync_update_remote/comment_1_d6410587c442bd6323991f7839c1b5b2._comment b/doc/forum/git_annex_sync_update_remote/comment_1_d6410587c442bd6323991f7839c1b5b2._comment
new file mode 100644
index 0000000000..ee9a6d51bb
--- /dev/null
+++ b/doc/forum/git_annex_sync_update_remote/comment_1_d6410587c442bd6323991f7839c1b5b2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-04-29T14:46:46Z"
+ content="""
+Your repo you're executing git annex from needs to have direct access to the remote in question. There's no relaying.
+
+If just the changing IP address is the problem, consider using a DynDNS service like https://freends.afraid.org, it's free and works very well.
+"""]]
diff --git a/doc/forum/git_annex_sync_update_remote/comment_2_704cf62eb4add2459e509cc5fdbfeb68._comment b/doc/forum/git_annex_sync_update_remote/comment_2_704cf62eb4add2459e509cc5fdbfeb68._comment
new file mode 100644
index 0000000000..ca5066ef4a
--- /dev/null
+++ b/doc/forum/git_annex_sync_update_remote/comment_2_704cf62eb4add2459e509cc5fdbfeb68._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="tom@b87e4336a0d0785eb7d5853e390835a18797402f"
+ nickname="tom"
+ avatar="http://cdn.libravatar.org/avatar/ad14e568e362e17d4cbe9010d639f111"
+ subject="What is the underlying reason for needing a two-way SSH connection"
+ date="2023-05-01T08:34:46Z"
+ content="""
+Thanks for the tip.
+
+I wonder what the underlying reason is for needing a two-way remote. It would have been nice if for example
+
+```
+[my_system] $ git annex sync --force
+```
+
+would update the state of all available remotes. In that the only functionality that would not be available in the absence of a two-way remote is
+
+
+```
+[ssh->jed] $ git annex get myfile
+```
+
+But if one can live with that limitation it would simplify the setup and increase functionality. I do believe that it would also relax the `git-annex` dependency of the remote somewhat. Potentially, it would then only be needed at runtime on the remote. Not at runtime on the local system. That too would simplify the setup a lot (one can then use `git-annex` for a virtual environment that is not forced as the default base).
+"""]]
diff --git a/doc/forum/git_annex_sync_update_remote/comment_3_9b6ecb7342aab7f0320ed7567ee5fa0b._comment b/doc/forum/git_annex_sync_update_remote/comment_3_9b6ecb7342aab7f0320ed7567ee5fa0b._comment
new file mode 100644
index 0000000000..1442363be6
--- /dev/null
+++ b/doc/forum/git_annex_sync_update_remote/comment_3_9b6ecb7342aab7f0320ed7567ee5fa0b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="git-annex relaying syncs across remotes"
+ date="2023-05-01T08:50:10Z"
+ content="""
+It does update the state of all available remotes of the `my_system` you're executing git-annex from. I would also love to see git-annex propagate the changes across the graph of connected remotes as far as it gets. It already has permissions to run git-annex on the remote server, so it could trigger a `git annex sync` from there, then reaching out for all configured remotes it has configured itself. But I'm sure @joey has a good reason not to do this, it screams of potential race conditions and git locking weirdness. But I don't know 🤷
+"""]]
diff --git a/doc/forum/git_annex_sync_update_remote/comment_4_221e01e024595f444e629db510eb60be._comment b/doc/forum/git_annex_sync_update_remote/comment_4_221e01e024595f444e629db510eb60be._comment
new file mode 100644
index 0000000000..ec403fc301
--- /dev/null
+++ b/doc/forum/git_annex_sync_update_remote/comment_4_221e01e024595f444e629db510eb60be._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-05-01T17:02:17Z"
+ content="""
+One way is to run this on your system:
+
+	git-annex drop foo.h5 --from cluster
+
+If you really have a reason to want to run `git-annex drop` on the cluster
+itself, it needs to be able to connect back to your system in order to to
+verify that your system still has a copy of the file it's dropping.
+
+Imagine what would happen if you ran `git-annex drop` of the same file on
+your system and on the cluster at the same time, if that check were not
+done. The file would be dropped from both places and so you'd lose data.
+
+You can use `git-annex drop --force` on the cluster if you're sure that
+your system still has the content. But it's probably going to be better to
+just use `git-annex drop --from cluster` run on your system, which avoids
+the potential for a mistake causing data loss.
+"""]]
diff --git a/doc/forum/git_annex_test_on_windows.mdwn b/doc/forum/git_annex_test_on_windows.mdwn
new file mode 100644
index 0000000000..4e2f8dea65
--- /dev/null
+++ b/doc/forum/git_annex_test_on_windows.mdwn
@@ -0,0 +1,5 @@
+is it worth sharing back git annex test failures occourring on some windows setup ?
+i'm having 3 failures, what kind of report can i produce shall it be of any use ?
+is it enough a test log coming from git annex test > test.log 2>&1 ?
+thanks again
+
diff --git a/doc/forum/git_annex_test_on_windows/comment_1_258ac5cfa2f5d24e737d94dc48f06899._comment b/doc/forum/git_annex_test_on_windows/comment_1_258ac5cfa2f5d24e737d94dc48f06899._comment
new file mode 100644
index 0000000000..d7968c16ed
--- /dev/null
+++ b/doc/forum/git_annex_test_on_windows/comment_1_258ac5cfa2f5d24e737d94dc48f06899._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 1"
+ date="2013-11-15T20:53:17Z"
+ content="""
+Yes, it's fine to file a bug about test failures. Be sure you try with a current autobuild.
+
+The redirection you show would work on linux, I don't know about windows. But capturing a transcript of the test output is certainly what I need.
+"""]]
diff --git a/doc/forum/git_annex_uninit_creates_broken_symlinks.mdwn b/doc/forum/git_annex_uninit_creates_broken_symlinks.mdwn
new file mode 100644
index 0000000000..5ba13653c6
--- /dev/null
+++ b/doc/forum/git_annex_uninit_creates_broken_symlinks.mdwn
@@ -0,0 +1,7 @@
+Hi, I'm attempting to uninit my giant git annex repo for my home folder. I've upgraded this to the latest repo version that uses smudge files instead of direct mode.
+
+However, when I try to uninit it, I end up with many broken symlinks, similar to that described [here](https://git-annex.branchable.com/forum/Broken_symlinks_remain_after_drop/).
+
+Any suggestions on how I can best restore these files to my home directory and migrate to using annex for an annex folder for stuff I need to transfer?
+
+Thanks!
diff --git a/doc/forum/git_annex_uninit_creates_broken_symlinks/comment_1_b7fb7fac51f59b23aafbc8dcce0aef07._comment b/doc/forum/git_annex_uninit_creates_broken_symlinks/comment_1_b7fb7fac51f59b23aafbc8dcce0aef07._comment
new file mode 100644
index 0000000000..b6de55622f
--- /dev/null
+++ b/doc/forum/git_annex_uninit_creates_broken_symlinks/comment_1_b7fb7fac51f59b23aafbc8dcce0aef07._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-06T16:59:00Z"
+ content="""
+If you uninit a repository that does not have the content of some files
+locally present, you'll be left with broken symlinks for those files.
+
+The way to avoid this is to run `git annex get` to get the contents of
+all files downloaded into the repository before you uninit.
+"""]]
diff --git a/doc/forum/git_annex_vicfg___40__preferred_content__41___examples.mdwn b/doc/forum/git_annex_vicfg___40__preferred_content__41___examples.mdwn
new file mode 100644
index 0000000000..54676514ca
--- /dev/null
+++ b/doc/forum/git_annex_vicfg___40__preferred_content__41___examples.mdwn
@@ -0,0 +1,37 @@
+My problem: I want to free up some disk space by doing `git annex drop FOO`, but then when I do `git annex add BAR; git annex sync --content`, FOO reappears.
+
+Looking into the man pages, I need to set up `git annex vicfg` to make `sync --content` ignore (exclude) FOO.
+
+I am overwhelmed by the configuration file and would just like to see a minimal complete example configuration file that does what I want. In the long run I probably want to use options like "groupwanted" and such, but am not sure what a "group" is exactly.
+
+Grepping for 'exclude', my config file has this already in it:
+
+```
+# Standard preferred contents
+# (Used by wanted or groupwanted expressions containing "standard")
+# (For reference only; built-in and cannot be changed!)
+# standard client = (include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1
+```
+
+but I am not sure how to go about it. For one, the comment hints that I need to use a secondary `wanted` or `groupwanted` expression to reference the `standard` keyword to actually use it, but I am just confused by all of these interlocking components.
+
+Also, I see stuff like this:
+
+```
+# Repository preferred contents
+# (Set to "standard" to use a repository's group's preferred contents)
+# (for web)
+#wanted 00000000-0000-0000-0000-000000000001 = 
+# (for bittorrent)
+#wanted 00000000-0000-0000-0000-000000000002 = 
+# (for l@k0:/dev/shm/annex)
+#wanted 56e6081b-4282-4f07-b53c-9042240cd75e = 
+# (for k0)
+#wanted a71d805d-df77-42e7-97b0-ba7686c05083 = 
+# (for l@m0:/mnt/a/annex.git [origin])
+#wanted c5c012cc-2080-481f-81bc-7f449f33490b =                                                                                                                                     
+```
+
+and am confused by these UUIDs. Where do these UUIDs come from? Am I supposed to use UUIDs?
+
+If there is a link or another doc I missed, please point me in the right direction.
diff --git a/doc/forum/git_annex_vicfg___40__preferred_content__41___examples/comment_1_1e59c9476b206613285e4f39b2c9efa8._comment b/doc/forum/git_annex_vicfg___40__preferred_content__41___examples/comment_1_1e59c9476b206613285e4f39b2c9efa8._comment
new file mode 100644
index 0000000000..1c408e7ab0
--- /dev/null
+++ b/doc/forum/git_annex_vicfg___40__preferred_content__41___examples/comment_1_1e59c9476b206613285e4f39b2c9efa8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-30T16:30:58Z"
+ content="""
+If you're finding vicfg confusing, you don't have to use it; the same
+configuration can be done at the command line using `git annex wanted`.
+See [[preferred_content]] for documentation.
+
+If you just want to have full control over what files are stored in the
+local repository, the easiest way to do that is to run `git annex get` and
+`git annex drop` manually when you want or don't want a file's content,
+and don't pass --content to `git annex sync`.
+"""]]
diff --git a/doc/forum/git_annex_vicfg___40__preferred_content__41___examples/comment_2_9d0cfb1d221e3ac6ed15db9cefab60fa._comment b/doc/forum/git_annex_vicfg___40__preferred_content__41___examples/comment_2_9d0cfb1d221e3ac6ed15db9cefab60fa._comment
new file mode 100644
index 0000000000..a2d05304ad
--- /dev/null
+++ b/doc/forum/git_annex_vicfg___40__preferred_content__41___examples/comment_2_9d0cfb1d221e3ac6ed15db9cefab60fa._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="listx"
+ subject="comment 2"
+ date="2016-08-01T20:06:46Z"
+ content="""
+OK; but are the UUIDs documented anywhere? I'd prefer not to dive into the sources if possible. Thanks.
+"""]]
diff --git a/doc/forum/git_annex_vicfg___40__preferred_content__41___examples/comment_3_78bc3e56502e425f4f77bc35ed2199b8._comment b/doc/forum/git_annex_vicfg___40__preferred_content__41___examples/comment_3_78bc3e56502e425f4f77bc35ed2199b8._comment
new file mode 100644
index 0000000000..c1345862bb
--- /dev/null
+++ b/doc/forum/git_annex_vicfg___40__preferred_content__41___examples/comment_3_78bc3e56502e425f4f77bc35ed2199b8._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="listx"
+ subject="comment 3"
+ date="2016-08-04T02:07:55Z"
+ content="""
+I went ahead and used `git annex wanted . \"exclude=FOO\"` and it did what I wanted. For posterity, here are some other observations:
+
+- The file that `git annex vicfg` shows was updated to include the invocation of `git annex wanted`, like this:
+
+```
+...(truncated for brevity)...
+# Repository preferred contents                                                                                                                                                    
+# (Set to \"standard\" to use a repository's group's preferred contents)
+# (for k0)
+wanted a71d805d-df77-42e7-97b0-ba7686c05083 = exclude=FOO
+# (for web)
+...(truncated for brevity)...
+```
+
+()- I noticed that the UUID above matches the UUID found in my `.git/config` file, which looks like this:
+
+```
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+[remote \"origin\"]
+	url = m0:/mnt/a/annex.git
+	fetch = +refs/heads/*:refs/remotes/origin/*
+	annex-uuid = c5c012cc-2080-481f-81bc-7f449f33490b
+[branch \"master\"]
+	remote = origin
+	merge = refs/heads/master
+[annex]
+	uuid = a71d805d-df77-42e7-97b0-ba7686c05083
+	version = 5
+```
+
+.
+"""]]
diff --git a/doc/forum/git_annex_view__58___viewindex.lock__44___file_exists___40__it_doesn__39__t__41__.mdwn b/doc/forum/git_annex_view__58___viewindex.lock__44___file_exists___40__it_doesn__39__t__41__.mdwn
new file mode 100644
index 0000000000..1230f9f409
--- /dev/null
+++ b/doc/forum/git_annex_view__58___viewindex.lock__44___file_exists___40__it_doesn__39__t__41__.mdwn
@@ -0,0 +1,7 @@
+Hi!
+
+I tagged some files with `tag=telegram`, but upon trying to try out views with `git annex view tag=telegram` I get:
+
+https://del.dog/nifumairra.txt
+
+Any ideas? :(  The file viewindex.lock doesn't exist..
diff --git a/doc/forum/git_annex_view__58___viewindex.lock__44___file_exists___40__it_doesn__39__t__41__/comment_1_08e3d99b682e640b72d0094d593f9d53._comment b/doc/forum/git_annex_view__58___viewindex.lock__44___file_exists___40__it_doesn__39__t__41__/comment_1_08e3d99b682e640b72d0094d593f9d53._comment
new file mode 100644
index 0000000000..eaeb21dbdc
--- /dev/null
+++ b/doc/forum/git_annex_view__58___viewindex.lock__44___file_exists___40__it_doesn__39__t__41__/comment_1_08e3d99b682e640b72d0094d593f9d53._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-11T16:27:22Z"
+ content="""
+That looks like [[this bug|bugs/view]] which was fixed in version 8.20201103
+"""]]
diff --git a/doc/forum/git_annex_view_tags_failing.mdwn b/doc/forum/git_annex_view_tags_failing.mdwn
new file mode 100644
index 0000000000..044957f497
--- /dev/null
+++ b/doc/forum/git_annex_view_tags_failing.mdwn
@@ -0,0 +1,16 @@
+I'm on a windows 10 machine and not using wls.  I'm sorting through some photos and tagging them with people, but when I attempt to view my tags I can't.  Below is the command and output. I tried searching around a bit, but I'm not entirely sure where to start.  On my last commit I didn't open an editor, I used the -m flag, and I've checked Task Manager and except for the Git-Bash terminal, I don't see any git processes running.  I'm not familiar enough with the internals of git or git annex to understand where it could be going wrong and would really appreciate some help.  Thanks. 
+
+    $ git annex view tags=*
+    view (searching...) fatal: Unable to create 'D:\projects\2020-philippines\.git\annex\viewindex.lock': File exists.
+
+    Another git process seems to be running in this repository, e.g.
+    an editor opened by 'git commit'. Please make sure all processes
+    are terminated then try again. If it still fails, a git process
+    may have crashed in this repository earlier:
+    remove the file manually to continue.
+
+    git-annex: failed to read sha from git write-tree
+    CallStack (from HasCallStack):
+      error, called at .\Git\Sha.hs:23:15 in main:Git.Sha
+    failed
+    git-annex: view: 1 failed
diff --git a/doc/forum/git_annex_wants_to_repair_every_time_it__39__s_running.mdwn b/doc/forum/git_annex_wants_to_repair_every_time_it__39__s_running.mdwn
new file mode 100644
index 0000000000..db4b368a23
--- /dev/null
+++ b/doc/forum/git_annex_wants_to_repair_every_time_it__39__s_running.mdwn
@@ -0,0 +1,5 @@
+As I tried to explain [here](http://git-annex.branchable.com/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/): Every time I try to start annex, I have the problem that it wants to repair my repo. I'm not sure what's causing this and how to proceed. I would appreciate any pointers on how to triage the problem. There is a lot more info in the other thread.
+
+OS X: 10.11.4
+git: 2.8.3 (installed via brew)
+git annex: 6.20160527  (installed via brew)
diff --git a/doc/forum/git_annex_wants_to_repair_every_time_it__39__s_running/comment_1_c182b03bae6e691eb68465fedf5c77d5._comment b/doc/forum/git_annex_wants_to_repair_every_time_it__39__s_running/comment_1_c182b03bae6e691eb68465fedf5c77d5._comment
new file mode 100644
index 0000000000..585beea319
--- /dev/null
+++ b/doc/forum/git_annex_wants_to_repair_every_time_it__39__s_running/comment_1_c182b03bae6e691eb68465fedf5c77d5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 1"
+ date="2016-06-18T21:48:42Z"
+ content="""
+So there are no ideas on how to proceed from anyone? Was the way I have written this message in any way too complicated or was it for some reason formulated in a manner, that made it look too demanding of others peoples time? I was not intentionally doing so, but I would appreciate any kind of commend on how to better phrase the question or on how to improve it in a way that this issue can be solved. Thanks in advance!
+
+P.S.: Since people probably don't stumble onto this comment, I'll give it another week or so before I would open up a new post containing the same issue.
+"""]]
diff --git a/doc/forum/git_annex_wants_to_repair_every_time_it__39__s_running/comment_2_6b3427b2d3e1c5f4c0582be1020c89f8._comment b/doc/forum/git_annex_wants_to_repair_every_time_it__39__s_running/comment_2_6b3427b2d3e1c5f4c0582be1020c89f8._comment
new file mode 100644
index 0000000000..951365aec2
--- /dev/null
+++ b/doc/forum/git_annex_wants_to_repair_every_time_it__39__s_running/comment_2_6b3427b2d3e1c5f4c0582be1020c89f8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-09-05T20:10:18Z"
+ content="""
+This seems to be the same person with the same problem discussed in 
+[[how_to_disaster_recovery]].
+
+I'm glad that we seem to have gotten to the bottom of it over there.
+
+Posting the same question over and over just wastes my time, please don't.
+"""]]
diff --git a/doc/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name.mdwn b/doc/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name.mdwn
new file mode 100644
index 0000000000..0cc7ae530a
--- /dev/null
+++ b/doc/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name.mdwn
@@ -0,0 +1,21 @@
+Hi Joey,
+
+I'm trying to extract data from a git annex whereis --json, but discovered that in json, the output has two values with same name.
+For instance: 
+
+{
+ "command":"whereis",
+ "file":"filename.webm",
+ "note":"3 copies",
+ "whereis":[
+  {"uuid":"1b7d69fe-22e2-11e4-bc47-279f5115dfde","description":"chasqui","here":false},
+  {"uuid":"e5cc9824-450b-4340-b30f-c2d92c6a52f7","description":"coco","here":false},
+  {"uuid":"f84a1327-febb-4199-a106-9c3fd2288826","description":"[dpadua]","here":false}],
+ "note":"\t1b7d69fe-22e2-11e4-bc47-279f5115dfde -- chasqui\n \te5cc9824-450b-4340-b30f-c2d92c6a52f7 -- coco\n \tf84a1327-febb-4199-a106-9c3fd2288826 -- [dpadua]\n",
+ "untrusted":[],
+ "success":true
+}
+
+When I read the json from another program, it gets only the second value (and I wanted the first, the number of copies). I'm using git-annex version 5.20140831+b1
+
+
diff --git a/doc/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name/comment_1_3bfde59729b904aa1ef815427dd35ae6._comment b/doc/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name/comment_1_3bfde59729b904aa1ef815427dd35ae6._comment
new file mode 100644
index 0000000000..a027b5276c
--- /dev/null
+++ b/doc/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name/comment_1_3bfde59729b904aa1ef815427dd35ae6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-10T17:09:32Z"
+ content="""
+The \"3 copies\" string is not meant to be machine-parsable anyway. Why don't you just look at the whereis object in the json, and count the number of items in its list, which will give you the number of copies.
+"""]]
diff --git a/doc/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name/comment_2_d08a955a11953cc783f09bfba180dbd6._comment b/doc/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name/comment_2_d08a955a11953cc783f09bfba180dbd6._comment
new file mode 100644
index 0000000000..02bd6de1ff
--- /dev/null
+++ b/doc/forum/git_annex_whereis_--json_output_with_two_variables_with_same_name/comment_2_d08a955a11953cc783f09bfba180dbd6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkR2dZjxqujBXcitvsP_PeWG8A-LfLU_tg"
+ nickname="Fernão"
+ subject="comment 2"
+ date="2014-10-10T18:18:04Z"
+ content="""
+nice, it worked =)
+"""]]
diff --git a/doc/forum/git_annex_windows_and_rsync.mdwn b/doc/forum/git_annex_windows_and_rsync.mdwn
new file mode 100644
index 0000000000..c45cd8d2d7
--- /dev/null
+++ b/doc/forum/git_annex_windows_and_rsync.mdwn
@@ -0,0 +1,26 @@
+Issue with getting files from a Linux ssh/rsync repo.
+
+I have a centralized repo on a small linux VM that I synchronize my workstations with, most are linux machines but one is a windows one.  I installed msysgit and git-annex for windows, and then run the following:
+
+
+    git clone ssh://user@IP.ADDRESS/home/user/annex annex  
+    cd annex  
+    git annex init 'windows'  
+    git annex copy --from origin  
+
+
+So basically I am just trying to get a copy of the central repo onto this windows machine for starters and get:
+
+
+    rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+    rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.1] 
+    rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]  
+    rsync error: error in rsync protoco  rsync failed -- run git annex again to resume file transfer  
+    l dafailed
+    ta stream (code 12) atcopy  
+
+
+And I get this message for every file.
+
+
+I do have cygwin with rsync and ssh installed on this machine previously so I tried on a separate machine thinking there may be compatibility issues with no avail either.  I am not sure if this is an existing issue/work in progress with Windows/git-annex or if it is something I am just experiencing.  
diff --git a/doc/forum/git_annex_windows_and_rsync/comment_1_33249bf910446fcf98ffb2e7e35017bf._comment b/doc/forum/git_annex_windows_and_rsync/comment_1_33249bf910446fcf98ffb2e7e35017bf._comment
new file mode 100644
index 0000000000..270f499e9c
--- /dev/null
+++ b/doc/forum/git_annex_windows_and_rsync/comment_1_33249bf910446fcf98ffb2e7e35017bf._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-07T18:14:43Z"
+ content="""
+[[bugs/rsync_on_windows_broken_by_upgrade]]
+"""]]
diff --git a/doc/forum/git_annex_with_local_apache_webdav_server.mdwn b/doc/forum/git_annex_with_local_apache_webdav_server.mdwn
new file mode 100644
index 0000000000..db489fdfa8
--- /dev/null
+++ b/doc/forum/git_annex_with_local_apache_webdav_server.mdwn
@@ -0,0 +1,23 @@
+Hi, 
+
+trying to make git annex work locally with an apache webdav server.
+
+I have the webdav server working without issue on computers. When we try to init the repository there we get the following error:
+
+WEBDAV_USERNAME=user WEBDAV_PASSWORD=xxxxxx git annex initremote webdavtest type=webdav url=http://webdavserver/webdavsgare/annextest4 encryption=none 
+initremote webdavtest (testing WebDAV server...)
+
+git-annex: WebDAV failed to delete file: "Locked": user error
+failed
+git-annex: initremote: 1 failed
+
+
+Does anyone have any thoughts? I can post config of webdav if it helps, though the error I receive in the error_log of apache is as follows:
+
+This resource is locked and an "If:" header was not supplied to allow access to the resource.  [423, #0]
+
+but I can manage the files through command line, web interface and mounted drive with no issue.
+
+thank you in advance.
+
+Damien
diff --git a/doc/forum/git_annex_with_local_apache_webdav_server/comment_1_a3b89f90f9ac70e0a9b0711ede1cb810._comment b/doc/forum/git_annex_with_local_apache_webdav_server/comment_1_a3b89f90f9ac70e0a9b0711ede1cb810._comment
new file mode 100644
index 0000000000..7963f64f03
--- /dev/null
+++ b/doc/forum/git_annex_with_local_apache_webdav_server/comment_1_a3b89f90f9ac70e0a9b0711ede1cb810._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.146"
+ subject="comment 1"
+ date="2014-02-26T19:40:18Z"
+ content="""
+The webdav library that git-annex uses does some webdav file locking. When deleting a file, it first locks it. It sounds like your webdav server does not like to delete a file that has been locked. Whether this is in spec I don't know.
+
+I do know that got rid of all the webdav locking stuff in a revamp of git-annex's webdav support 2 days ago! git-annex does not need locking the way it uses webdav.
+
+However, the daily builds are still built with an old version of the DAV library, which still does the locking ... and will probably remain like that for some time. To get the new version without locking, you need to build git-annex from its git master on a system with http://hackage.haskell.org/package/DAV version 0.6.1. Building from source with cabal is one way to do it. I'll be releasing a build for Debian unstable in the next day or two.
+"""]]
diff --git a/doc/forum/git_annex_with_local_apache_webdav_server/comment_2_d8e9237cf6e7f7558f836ba1352f5517._comment b/doc/forum/git_annex_with_local_apache_webdav_server/comment_2_d8e9237cf6e7f7558f836ba1352f5517._comment
new file mode 100644
index 0000000000..2b60a9967e
--- /dev/null
+++ b/doc/forum/git_annex_with_local_apache_webdav_server/comment_2_d8e9237cf6e7f7558f836ba1352f5517._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7hS2LGu4sLUxLMdBA16PAMcVO7CDJmjw"
+ nickname="Damien"
+ subject="comment 2"
+ date="2014-03-10T12:16:43Z"
+ content="""
+I'm curious if anyone has set this up using a local apache webdav server?
+
+I'm stuck and could use some insight.
+
+thanks
+Damien
+"""]]
diff --git a/doc/forum/git_clone_over_ssh_hangs.mdwn b/doc/forum/git_clone_over_ssh_hangs.mdwn
new file mode 100644
index 0000000000..f385937d2e
--- /dev/null
+++ b/doc/forum/git_clone_over_ssh_hangs.mdwn
@@ -0,0 +1,17 @@
+I am trying to use git-annex to sync a folder with a backup drive over the network.
+I have followed the walkthrough and run a git annex init in a TrueNAS jail and now I am trying to use git clone through ssh to link the drive and the jail together.
+The problem is that the clone in the backup drive just hangs. It will enumerate the files and count them and then it just seems to do nothing.
+
+
+Command: git clone ssh://user@ip/mnt/dir ./driveBackup
+Output:
+Cloning into './repo'...
+remote: Enumerating objects: 1543, done.
+remote: Counting objects: 100% (1543/1543), done.
+
+...Hangs here nothing obvious happens...
+
+Running it in verbose mode reveals nothing. When you stop the clone it will complain about some sideband packet.
+
+I don't know if it helps, but I have set up passwordless ssh login and I have verified that it works by running ssh user@ip successfully from the backup system.
+Can someone help me please?
diff --git a/doc/forum/git_clone_over_ssh_hangs/comment_1_07ffe356ef5c441118cc9329060812f2._comment b/doc/forum/git_clone_over_ssh_hangs/comment_1_07ffe356ef5c441118cc9329060812f2._comment
new file mode 100644
index 0000000000..49cb60afe8
--- /dev/null
+++ b/doc/forum/git_clone_over_ssh_hangs/comment_1_07ffe356ef5c441118cc9329060812f2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-03-21T17:49:31Z"
+ content="""
+Well, this is a git question, not a git-annex question.
+There is no git-annex involved in what you showed.
+You might have better luck on a forum specific to git.
+
+(Especially if it really involves some problem with sidebound packets,
+which is deeper on git protocol than I can go.)
+"""]]
diff --git a/doc/forum/git_lfs_special_remote_implementation.mdwn b/doc/forum/git_lfs_special_remote_implementation.mdwn
new file mode 100644
index 0000000000..b30d016b3b
--- /dev/null
+++ b/doc/forum/git_lfs_special_remote_implementation.mdwn
@@ -0,0 +1,9 @@
+I'm thinking about how to implement a special remote that uses git-lfs (no promises to get it done).  I'm not sure if my thoughts are good since I've barely used remotes at all so far!
+
+I'm not sure when annex executes the various remote protocol commands (presumably it issues TRANSFER when pushing to the remote?), but I'm thinking something like this might be appropriate:
+
+The special remote is implemented as a local git-lfs working tree, which has not necessarily been pushed to an upstream remote supporting LFS (like gitlab or github).  Then, "TRANSFER" just arranges to copy the file to a file in the LFS repo -- named after the provided key -- and then `git add`, ensuring LFS is used.  Nothing is pushed from the git repo that implements the special remote, until the user explicitly does so.
+
+Does that sound sane and in keeping with how remotes work?
+
+Why do I want it to work this way?  Because if each TRANSFER is supposed to result in something stored, it seems odd to git push for every file stored to the remote.  As far as I can see, there's no FINISHED hook analogous to PREPARE at which time (after "all the files" are transferred, whatever that would mean) the special remote might choose to git push the LFS repo to gitlab/github?  If there were, I might choose instead to make the local working copy a hidden implementation detail of the special remote, which users of the LFS remote never directly see or use.
diff --git a/doc/forum/git_lfs_special_remote_implementation/comment_1_a61494b02c831e84903f28d9900850ac._comment b/doc/forum/git_lfs_special_remote_implementation/comment_1_a61494b02c831e84903f28d9900850ac._comment
new file mode 100644
index 0000000000..e903b3343f
--- /dev/null
+++ b/doc/forum/git_lfs_special_remote_implementation/comment_1_a61494b02c831e84903f28d9900850ac._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-04-09T15:12:22Z"
+ content="""
+See [[todo/LFS_API_support]].
+"""]]
diff --git a/doc/forum/git_pull_remote_git-annex.mdwn b/doc/forum/git_pull_remote_git-annex.mdwn
new file mode 100644
index 0000000000..349610693b
--- /dev/null
+++ b/doc/forum/git_pull_remote_git-annex.mdwn
@@ -0,0 +1,11 @@
+I thought I'd followed the walk through when initially setting up my repos.
+
+However I find that I have to do the following to sync my annex's.
+
+    git pull remote master
+    git checkout git-annex
+    git pull remote git-annex
+    git checkout master
+    git annex get .
+
+Has something gone wrong? I see no mention of syncing git-annex repos in the walk-through...
diff --git a/doc/forum/git_pull_remote_git-annex/comment_1_9c245db3518d8b889ecdf5115ad9e053._comment b/doc/forum/git_pull_remote_git-annex/comment_1_9c245db3518d8b889ecdf5115ad9e053._comment
new file mode 100644
index 0000000000..989ab9bcd8
--- /dev/null
+++ b/doc/forum/git_pull_remote_git-annex/comment_1_9c245db3518d8b889ecdf5115ad9e053._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-12-06T16:43:29Z"
+ content="""
+You're taking a very long and strange way to a place that you can reach as follows:
+
+<pre>
+git pull remote
+git annex get .
+</pre>
+
+Which is just as shown in [[walkthrough/getting_file_content]]. 
+
+In particular, \"git pull remote\" first fetches all branches from the remote, including the git-annex branch.
+When you say \"git pull remote master\", you're preventing it from fetching the git-annex branch. 
+If for some reason you want the slightly longer way around, it is:
+
+<pre>
+git pull remote master
+git fetch remote git-annex
+git annex get .
+</pre>
+
+Or, eqivilantly but with less network connections:
+
+<pre>
+git fetch remote
+git merge remote/master
+git annex get .
+</pre>
+
+BTW, notice that this is all bog-standard git branch pulling stuff, not specific to git-annex in the least.
+Consult your extensive and friendly git documentation for details. :)
+"""]]
diff --git a/doc/forum/git_pull_remote_git-annex/comment_2_0f7f4a311b0ec1d89613e80847e69b42._comment b/doc/forum/git_pull_remote_git-annex/comment_2_0f7f4a311b0ec1d89613e80847e69b42._comment
new file mode 100644
index 0000000000..198f95cee8
--- /dev/null
+++ b/doc/forum/git_pull_remote_git-annex/comment_2_0f7f4a311b0ec1d89613e80847e69b42._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
+ nickname="Matt"
+ subject="comment 2"
+ date="2011-12-06T23:23:29Z"
+ content="""
+Doh! Total brain melt on my part. Thanks for the additional info.  Not taking my time and reading things properly - kept assuming that the full remote pull failed due to the warning:
+
+    You asked to pull from the remote 'rss', but did not specify
+    a branch. Because this is not the default configured remote
+    for your current branch, you must specify a branch on the command line.
+
+Rookie mistake indeed.
+"""]]
diff --git a/doc/forum/git_pull_remote_git-annex/comment_3_1aa89725b5196e40a16edeeb5ccfa371._comment b/doc/forum/git_pull_remote_git-annex/comment_3_1aa89725b5196e40a16edeeb5ccfa371._comment
new file mode 100644
index 0000000000..0ead32dad2
--- /dev/null
+++ b/doc/forum/git_pull_remote_git-annex/comment_3_1aa89725b5196e40a16edeeb5ccfa371._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
+ nickname="Matt"
+ subject="comment 3"
+ date="2011-12-21T16:06:25Z"
+ content="""
+hmmmm - I'm still not sure I get this.
+
+If I'm using a whole bunch of distributed annexs with no central repo, then I can not do a `git pull remote` without either specifying the branch to use or changing default tracked remote via `git branch --set-upstream`.  The former like you note doesn't pull the git-annex branch down the latter only works one-at-a-time.
+
+The docs read to me as though I ought to be able to do a `git pull remote ; git annex get .` using anyone of my distributed annexs.
+
+Am I doing something wrong?  Or is the above correct?
+"""]]
diff --git a/doc/forum/git_pull_remote_git-annex/comment_4_646f2077edcabc000a7d9cb75a93cf55._comment b/doc/forum/git_pull_remote_git-annex/comment_4_646f2077edcabc000a7d9cb75a93cf55._comment
new file mode 100644
index 0000000000..6ba1796939
--- /dev/null
+++ b/doc/forum/git_pull_remote_git-annex/comment_4_646f2077edcabc000a7d9cb75a93cf55._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="I think Matt is right."
+ date="2011-12-23T14:04:44Z"
+ content="""
+I got bitten by this too.  It seems that the user is expected to fetch
+remote git-annex branches themselves, but this is not documented
+anywhere.
+
+The man page says of \"git annex merge\":
+
+    Automatically merges any changes from remotes into the git-annex
+    branch.
+
+I am not a git newbie, but even so I had incorrectly assumed that git
+annex merge would take care of pulling the git-annex branch from the
+remote prior to merging, thereby ensuring all versions of the
+git-annex branch would be merged, and that the location tracking data
+would be synced across all peer repositories.
+
+My master branches do not track any specific upstream branch, because
+I am operating in a decentralized fashion.  Therefore the error
+message caused by `git pull $remote` succeeded in encouraging me to
+instead use `git pull $remote master`, and this excludes the git-annex
+branch from the fetch.  Even worse, a git newbie might realise this
+and be tempted to do `git pull $remote git-annex`.
+
+Therefore I think it needs to be explicitly documented that
+
+    git fetch $remote
+    git merge $remote/master
+
+is required when the local branch doesn't track an upstream branch.
+Or maybe a `--fetch` option could be added to `git annex merge` to
+perform the fetch from all remotes before running the merge(s).
+"""]]
diff --git a/doc/forum/git_pull_remote_git-annex/comment_5_4f2a05ef6551806dd0ec65372f183ca4._comment b/doc/forum/git_pull_remote_git-annex/comment_5_4f2a05ef6551806dd0ec65372f183ca4._comment
new file mode 100644
index 0000000000..c01f241202
--- /dev/null
+++ b/doc/forum/git_pull_remote_git-annex/comment_5_4f2a05ef6551806dd0ec65372f183ca4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 5"
+ date="2011-12-23T16:50:26Z"
+ content="""
+My goal for `git-annex merge` is that users should not need to know about it, so it should not be doing expensive pulls.
+
+I hope that `git annex sync` will grow some useful features to support fully distributed git usage, as being discussed in [[pure_git-annex_only_workflow]]. I still use centralized git to avoid these problems myself.
+"""]]
diff --git a/doc/forum/git_pull_remote_git-annex/comment_6_3925d1aa56bce9380f712e238d63080f._comment b/doc/forum/git_pull_remote_git-annex/comment_6_3925d1aa56bce9380f712e238d63080f._comment
new file mode 100644
index 0000000000..f4b5ebec20
--- /dev/null
+++ b/doc/forum/git_pull_remote_git-annex/comment_6_3925d1aa56bce9380f712e238d63080f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="comment 6"
+ date="2011-12-23T17:14:03Z"
+ content="""
+Extending `git annex sync` would be nice, although auto-commit does not suit every use case, so it would be better not to couple one to the other.
+"""]]
diff --git a/doc/forum/git_pull_remote_git-annex/comment_7_24c45ee981b18bc78325c768242e635d._comment b/doc/forum/git_pull_remote_git-annex/comment_7_24c45ee981b18bc78325c768242e635d._comment
new file mode 100644
index 0000000000..dad2c0af21
--- /dev/null
+++ b/doc/forum/git_pull_remote_git-annex/comment_7_24c45ee981b18bc78325c768242e635d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="comment 7"
+ date="2011-12-23T17:24:58Z"
+ content="""
+P.S. I see you already [fixed the docs](http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=a0227e81f9c82afc12ac1bd1cecd63cc0894d751) - thanks! :)
+"""]]
diff --git a/doc/forum/git_pull_remote_git-annex/comment_8_7e76ee9b6520cbffaf484c9299a63ad3._comment b/doc/forum/git_pull_remote_git-annex/comment_8_7e76ee9b6520cbffaf484c9299a63ad3._comment
new file mode 100644
index 0000000000..5943d93127
--- /dev/null
+++ b/doc/forum/git_pull_remote_git-annex/comment_8_7e76ee9b6520cbffaf484c9299a63ad3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="git tweak-fetch"
+ date="2011-12-26T18:50:35Z"
+ content="""
+The git tweak-fetch hook that I have been developing, and hope will be accepted into git soon, provides some abilities that could be used to make \"git pull remote\" always merge remote/master. Normall, git can only be configured to do that merge automatically for one remote (ie, origin). But the tweak-fetch hook can flag arbitrary branches as needing merge. 
+
+So, it could always flag tracking branches of the currently checked out branch for merge. This would be enabled by some setting, probably, since it's not necessarily the case that everyone wants to auto-merge when they pull like this. (Which is why git doesn't do it by default after all.)
+
+(The tweak-fetch hook will also entirely eliminate the need to run git annex merge manually, since it can always take care of merging the git-annex branch.)
+"""]]
diff --git a/doc/forum/git_status_is_slow_twice__44___then_fast.mdwn b/doc/forum/git_status_is_slow_twice__44___then_fast.mdwn
new file mode 100644
index 0000000000..de7ef1026f
--- /dev/null
+++ b/doc/forum/git_status_is_slow_twice__44___then_fast.mdwn
@@ -0,0 +1,39 @@
+I don't know if this is a git thing, or a git annex thing, but it's weird.
+
+After I add a bunch of files to the annex (and there are many more local files not yet added), `git status` is slow. That's not really a surprise. It shows the `refresh index` calculation as usual.
+
+I run it a second time, and I get the exact same result:
+
+```
+% time git status
+Refresh index: 100% (2997/2997), done.
+<snip>
+
+git status  38.64s user 42.08s system 80% cpu 1:39.95 total
+```
+
+I run it a third time and it's _instant_.
+
+This happens reliably. Two slow runs, and then a fast run.
+
+I don't love the initial slow run, but it makes sense, so I can live with it. The second slow run doesn't make sense to me though. Is there any way to avoid it? I guess I would expect the first slow run to refresh the index and speed up subsequent runs.
+
+It seems like a similar symptom to [git keeps refreshing index](https://git-annex.branchable.com/bugs/git_keeps_refreshing_index/).
+
+I am using git and git-annex installed via homebrew on macOS 10.15.7. I have `annex.addunlocked` set to true.
+
+```
+git version 2.37.0
+
+git-annex version: 10.20220624
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-8.10.7 http-client-0.7.11 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+```
+
+- @pat
diff --git a/doc/forum/git_status_is_slow_twice__44___then_fast/comment_1_a32e4d4255a1afcfd05c374d0fffccab._comment b/doc/forum/git_status_is_slow_twice__44___then_fast/comment_1_a32e4d4255a1afcfd05c374d0fffccab._comment
new file mode 100644
index 0000000000..810e80a7e6
--- /dev/null
+++ b/doc/forum/git_status_is_slow_twice__44___then_fast/comment_1_a32e4d4255a1afcfd05c374d0fffccab._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 1"
+ date="2022-07-09T00:40:23Z"
+ content="""
+Alright I did some reading and experimenting, and it turns out it's the unlocked files. When I use locked files by defaults, git status is as fast as it usually is. I don't fully understand it, but it seems that something about smudging is slow.
+
+Anyway, I can use locked files for most of my stuff, and unlocked files for only active projects.
+"""]]
diff --git a/doc/forum/git_status_is_slow_twice__44___then_fast/comment_2_1aba5ad6deb4634fca187ecc69a6adf9._comment b/doc/forum/git_status_is_slow_twice__44___then_fast/comment_2_1aba5ad6deb4634fca187ecc69a6adf9._comment
new file mode 100644
index 0000000000..735edec5b4
--- /dev/null
+++ b/doc/forum/git_status_is_slow_twice__44___then_fast/comment_2_1aba5ad6deb4634fca187ecc69a6adf9._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-07-25T16:53:34Z"
+ content="""
+I don't know why git would re-run the slow operation twice before caching
+the result for the third time.
+
+But, yes, smudging is slow in repository v8. If you upgrade to v9 it should
+be significantly faster.
+"""]]
diff --git a/doc/forum/git_status_typechange_in_v5_direct_false.mdwn b/doc/forum/git_status_typechange_in_v5_direct_false.mdwn
new file mode 100644
index 0000000000..f326850d3c
--- /dev/null
+++ b/doc/forum/git_status_typechange_in_v5_direct_false.mdwn
@@ -0,0 +1,33 @@
+Should I see a typechange from `git status` when using direct mode = false?
+
+I'm using digiKam to manage photos in a git-annex repository. digiKam will only write XMP sidecar files for real files, not symlinks, so I need to unlock every file in order to sync metadata to XMP files.
+
+Is it possible to suppress typechange in some way?
+
+Thanks.
+
+    On branch master
+    Changes not staged for commit:
+    (use "git add <file>..." to update what will be committed)
+    (use "git checkout -- <file>..." to discard changes in working directory)
+
+        typechange: photographers/jboxman/2004/06/16/20040616-004528.jpg
+        .......
+        typechange: photographers/jboxman/2004/06/17/20040617-010127.jpg
+
+    [annex]
+    uuid = 56e0d203-7898-xxxx-xxxx-1b04cec6597c
+    version = 5
+    largefiles = largerthan=20kb and not (include=*.xmp or include=*.thor or include=bin/*)
+    direct = false
+
+    git-annex version: 6.20171124
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents TorrentParser MagicMime Feeds Quvi
+    dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.24 DAV-1.3.1 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.7.1 persistent-sqlite-2.6.3.1torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384ESHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: darwin x86_64
+
diff --git a/doc/forum/git_status_typechange_in_v5_direct_false/comment_1_eb4e2b1fd7615e2b6936b5df01d68d1f._comment b/doc/forum/git_status_typechange_in_v5_direct_false/comment_1_eb4e2b1fd7615e2b6936b5df01d68d1f._comment
new file mode 100644
index 0000000000..2e71853af1
--- /dev/null
+++ b/doc/forum/git_status_typechange_in_v5_direct_false/comment_1_eb4e2b1fd7615e2b6936b5df01d68d1f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-05-31T17:39:10Z"
+ content="""
+This all seems very OK and expected to me.
+
+When you do `git-annex unlock photographers/jboxman/2004/06/16/20040616-004528.jpg` you are changing out the symlink for the actual file, so git has recognized the thing with this name is different. If you do `git-annex add photographers/jboxman/2004/06/16/20040616-004528.jpg` git-annex will recognize that you have not modified any content and will replace the file with the symlink, the file will no longer appear in git status and the file won't have any commits associated with it.
+
+So if you unlock everything, launch digiKam and generate your sidecars, then we see both jpgs and xmps in `git status`. If you then run `git annex add .` all your jpgs will turn back into symlinks and all your xmp files will appear in `git status` per your `largefiles` rule staged for committing.
+
+I haven't tested with your exact setup so I would recommend testing the workflow on a small folder to start. 
+
+
+"""]]
diff --git a/doc/forum/git_status_typechange_in_v5_direct_false/comment_2_19df04820aa80549cfabac0141c372c0._comment b/doc/forum/git_status_typechange_in_v5_direct_false/comment_2_19df04820aa80549cfabac0141c372c0._comment
new file mode 100644
index 0000000000..7b5d7d53b7
--- /dev/null
+++ b/doc/forum/git_status_typechange_in_v5_direct_false/comment_2_19df04820aa80549cfabac0141c372c0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jasonb885"
+ avatar="http://cdn.libravatar.org/avatar/c7330f4da122c671b935fc1d58bb02b1"
+ subject="oh"
+ date="2018-07-02T01:08:37Z"
+ content="""
+To usefully use files committed to git annex with digiKam, I have to have every single file unlocked. So in this case, what git status is telling me isn't useful. I can grep-v this out, but I wasn't expecting to see it since it seems like normal usage for git annex. It seems git doesn't see it that way and thinks something special has happened. I was hoping I was doing something wrong and if I used some other approach, git would be silent about the typechange. Thanks.
+"""]]
diff --git a/doc/forum/git_status_typechange_in_v5_direct_false/comment_3_20e04806a59e05a453431cb90086ccac._comment b/doc/forum/git_status_typechange_in_v5_direct_false/comment_3_20e04806a59e05a453431cb90086ccac._comment
new file mode 100644
index 0000000000..010081671c
--- /dev/null
+++ b/doc/forum/git_status_typechange_in_v5_direct_false/comment_3_20e04806a59e05a453431cb90086ccac._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 3"
+ date="2018-07-10T18:45:37Z"
+ content="""
+I don't believe the `git` team has provided any way for `git annex` to hook into the `status` command to provide different information.
+
+You can always do `git annex status` if you want to know what `git annex` thinks about the current situation.
+"""]]
diff --git a/doc/forum/git_tag_missing_for_3.20111011.mdwn b/doc/forum/git_tag_missing_for_3.20111011.mdwn
new file mode 100644
index 0000000000..781d0c91a0
--- /dev/null
+++ b/doc/forum/git_tag_missing_for_3.20111011.mdwn
@@ -0,0 +1 @@
+Well, the subject pretty much says it all :)
diff --git a/doc/forum/git_tag_missing_for_3.20111011/comment_1_7a53bf273f3078ab3351369ef2b5f2a6._comment b/doc/forum/git_tag_missing_for_3.20111011/comment_1_7a53bf273f3078ab3351369ef2b5f2a6._comment
new file mode 100644
index 0000000000..87cda998bf
--- /dev/null
+++ b/doc/forum/git_tag_missing_for_3.20111011/comment_1_7a53bf273f3078ab3351369ef2b5f2a6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="fixed that"
+ date="2011-10-13T15:36:59Z"
+ content="""
+:)
+"""]]
diff --git a/doc/forum/git_unannex_speed.mdwn b/doc/forum/git_unannex_speed.mdwn
new file mode 100644
index 0000000000..a5e6ad5719
--- /dev/null
+++ b/doc/forum/git_unannex_speed.mdwn
@@ -0,0 +1 @@
+It was fast to git annex a bunch of files. But git unannex seems a lot slower. Is there a faster way to get files out of git annex? Or to replace the symlinks with real files and then I could just remove the .git directory? I shouldn't have put so many in as a test but they are there now.
diff --git a/doc/forum/git_unannex_speed/comment_1_10cf326248f4e89e1f75bf97d7574763._comment b/doc/forum/git_unannex_speed/comment_1_10cf326248f4e89e1f75bf97d7574763._comment
new file mode 100644
index 0000000000..39fc4793cc
--- /dev/null
+++ b/doc/forum/git_unannex_speed/comment_1_10cf326248f4e89e1f75bf97d7574763._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 1"
+ date="2012-08-02T16:58:41Z"
+ content="""
+It currently commits once per file, which is slow. `Command/Unannex.hs` explains why this is necessary. If I think of a way to avoid that, I will.
+"""]]
diff --git a/doc/forum/git_unlock_failed.mdwn b/doc/forum/git_unlock_failed.mdwn
new file mode 100644
index 0000000000..f0a546b19b
--- /dev/null
+++ b/doc/forum/git_unlock_failed.mdwn
@@ -0,0 +1,22 @@
+I am trying to 
+
+```
+$ git annex unlock myfile
+```
+
+but it gives
+
+```
+unlock myfile
+git-annex: unlock failed
+failed
+unlock: 1 failed
+```
+
+I have no idea why, and the error gives me no means to debug (nor was an internet search helpful). Note that e.g.
+
+```
+$ cat myfile
+```
+
+works fine
diff --git a/doc/forum/git_unlock_failed/comment_1_483dbd405b41b7bce343d7c08be8d92f._comment b/doc/forum/git_unlock_failed/comment_1_483dbd405b41b7bce343d7c08be8d92f._comment
new file mode 100644
index 0000000000..3c41c7f8c1
--- /dev/null
+++ b/doc/forum/git_unlock_failed/comment_1_483dbd405b41b7bce343d7c08be8d92f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-05-01T12:26:10Z"
+ content="""
+Try `git annex --debug unlock myfile`. Otherwise do an `strace git annex --debug unlock myfile` and you can try setting git debug environment variables: https://stackoverflow.com/questions/6178401/how-can-i-debug-git-git-shell-related-problems
+"""]]
diff --git a/doc/forum/git_unlock_failed/comment_2_76903b206b8cf6dced44a2da29f57201._comment b/doc/forum/git_unlock_failed/comment_2_76903b206b8cf6dced44a2da29f57201._comment
new file mode 100644
index 0000000000..c271074497
--- /dev/null
+++ b/doc/forum/git_unlock_failed/comment_2_76903b206b8cf6dced44a2da29f57201._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="tom@b87e4336a0d0785eb7d5853e390835a18797402f"
+ nickname="tom"
+ avatar="http://cdn.libravatar.org/avatar/ad14e568e362e17d4cbe9010d639f111"
+ subject="output"
+ date="2023-05-01T12:58:46Z"
+ content="""
+Thanks. It just gives a vague `-9` exit signal.
+
+```
+$ git annex --debug unlock a.h5
+[2023-05-01 14:55:49.113032] (Utility.Process) process [2384] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"ls-files\",\"--stage\",\"-z\",\"--error-unmatch\",\"--\",\"a.h5\"]
+[2023-05-01 14:55:49.117717] (Utility.Process) process [2385] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+[2023-05-01 14:55:49.119457] (Utility.Process) process [2386] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+unlock a.h5 [2023-05-01 14:55:49.137739] (Utility.Process) process [2388] call: cp [\"-a\",\".git/annex/objects/53/Mp/SHA256E-s800002048--53c9d89060bab30a448a870f0c81bc475fa79c78ebf46aa4368b54c7c481cd65.h5/SHA256E-s800002048--53c9d89060bab30a448a870f0c81bc475fa79c78ebf46aa4368b54c7c481cd65.h5\",\".git/annex/othertmp/a.h5.0/a.h5\"]
+[2023-05-01 14:55:49.138315] (Utility.Process) process [2388] done ExitFailure (-9)
+
+git-annex: unlock failed
+failed
+[2023-05-01 14:55:49.140959] (Utility.Process) process [2386] done ExitSuccess
+[2023-05-01 14:55:49.141007] (Utility.Process) process [2385] done ExitSuccess
+[2023-05-01 14:55:49.141037] (Utility.Process) process [2384] done ExitSuccess
+[2023-05-01 14:55:49.141534] (Database.Handle) commitDb start
+[2023-05-01 14:55:49.151421] (Database.Handle) commitDb done
+unlock: 1 failed
+```
+"""]]
diff --git a/doc/forum/git_unlock_failed/comment_3_3331c627e0a48f8d2698b2bda1e0748f._comment b/doc/forum/git_unlock_failed/comment_3_3331c627e0a48f8d2698b2bda1e0748f._comment
new file mode 100644
index 0000000000..3ebd2bc7fe
--- /dev/null
+++ b/doc/forum/git_unlock_failed/comment_3_3331c627e0a48f8d2698b2bda1e0748f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-05-01T15:53:41Z"
+ content="""
+Strange that cp is failing without displaying any kind of error message.
+The exit code being negative suggests it received signal 9 (SIGKILL).
+
+I'd look at `strace -o log -ff` at this point and find the log file for the
+cp process, to see what it was doing before it exited.
+"""]]
diff --git a/doc/forum/git_unlock_failed/comment_4_a24ddc8effd6983d6ed1d3a5e1c62b45._comment b/doc/forum/git_unlock_failed/comment_4_a24ddc8effd6983d6ed1d3a5e1c62b45._comment
new file mode 100644
index 0000000000..1155f99fa2
--- /dev/null
+++ b/doc/forum/git_unlock_failed/comment_4_a24ddc8effd6983d6ed1d3a5e1c62b45._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tom@b87e4336a0d0785eb7d5853e390835a18797402f"
+ nickname="tom"
+ avatar="http://cdn.libravatar.org/avatar/ad14e568e362e17d4cbe9010d639f111"
+ subject="comment 4"
+ date="2023-05-01T16:10:00Z"
+ content="""
+Do you know what to put on macOS?
+"""]]
diff --git a/doc/forum/git_unlock_failed/comment_5_e88de8c0fdd998236ba18a60d9308df8._comment b/doc/forum/git_unlock_failed/comment_5_e88de8c0fdd998236ba18a60d9308df8._comment
new file mode 100644
index 0000000000..fbf2cc6834
--- /dev/null
+++ b/doc/forum/git_unlock_failed/comment_5_e88de8c0fdd998236ba18a60d9308df8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-05-01T16:29:50Z"
+ content="""
+Sorry I don't know MacOS well enough to say... but it's good information
+that you're using that OS.
+"""]]
diff --git a/doc/forum/git_update-index_message_after_git-annex_get.mdwn b/doc/forum/git_update-index_message_after_git-annex_get.mdwn
new file mode 100644
index 0000000000..205cdeddff
--- /dev/null
+++ b/doc/forum/git_update-index_message_after_git-annex_get.mdwn
@@ -0,0 +1,17 @@
+After running `git-annex get` in an unlocked (adjusted) v8 repo with git-annex 8.20200330, I see:
+
+> git status will show some files to be modified, since content availability has changed and git-annex was unable to update
+> the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git
+> status display, you can run: git update-index -q --refresh <file>
+
+And indeed, some of the files I just got show as new, others as modified.
+
+Where can I find more information on what happened here?
+
+How can I run the update-index command safely without listing hundreds of files? Can I just run it over the directories those files were copied to?
+
+Would you consider adding an option to run the update-index automatically where needed?
+
+UPDATE: I just notice that the assistant apparently deleted some files from the git repository. When I check the file path with `git log <file>` I see the initial addition (locked, on a different machine, not adjusted) and then a deletion of the symlink on the machine where I executed `git annex get`. This is rather terrifying!
+
+The file is still in the filesystem. The last commit to the annex happened over 30m ago, the last log in daemon.log over 20m ago. The assistant will probably not add these files back? But even if it would. It is dangerous that a simple `git annex get` leads to delete commits.
diff --git a/doc/forum/git_update-index_message_after_git-annex_get/comment_1_606b627b91a6e9864653ed86252b4bd7._comment b/doc/forum/git_update-index_message_after_git-annex_get/comment_1_606b627b91a6e9864653ed86252b4bd7._comment
new file mode 100644
index 0000000000..b8b1400f03
--- /dev/null
+++ b/doc/forum/git_update-index_message_after_git-annex_get/comment_1_606b627b91a6e9864653ed86252b4bd7._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-11T17:29:12Z"
+ content="""
+git-annex does try to run git update-index, but it will fail if some other
+use of git has the index locked, resulting in that message.
+
+As for the assistant committing deletions, one way that could happen is if
+the assistant observes a brief window where the pointer file has been deleted
+and the file with the content is not yet in place. But then the assistant
+should later notice that the file has come back, and make a new commit
+adding it back. If the assistant did not make that later commit, something else
+is going on.
+"""]]
diff --git a/doc/forum/glacier_-_range_retrievals_and_daily_free_retrieval_allowance.mdwn b/doc/forum/glacier_-_range_retrievals_and_daily_free_retrieval_allowance.mdwn
new file mode 100644
index 0000000000..d9db436c61
--- /dev/null
+++ b/doc/forum/glacier_-_range_retrievals_and_daily_free_retrieval_allowance.mdwn
@@ -0,0 +1,6 @@
+I propose to add some functionality to git-annex, to automatically "throttle" the data retrieval from amazon glacier to stay within the daily free retrieval allowance. If someone would need to get his/her files faster, there should be an option to disable this throttling (or even better, specify the retrieval rate).
+
+As far as I understand glacier, this could be implemented using range retrievals. In short range retrievals enable you, to only retrieve a part of an archive in glacier. This can be used to only retrieve / request so much data, that you stay within the free retrieval allowance. ( please see [Q: Why would I retrieve only a range of an archive?](http://aws.amazon.com/glacier/faqs/#Why_would_I_retrieve_only_a_range_of_an_archive) ).
+
+
+This would be somewhat similar to the [smart retrieval feature in cloudberry](http://blog.cloudberrylab.com/2012/12/introducing-smart-restore-for-amazon.html) .
diff --git a/doc/forum/got_confused_by_fsck.mdwn b/doc/forum/got_confused_by_fsck.mdwn
new file mode 100644
index 0000000000..7f7e10f8bd
--- /dev/null
+++ b/doc/forum/got_confused_by_fsck.mdwn
@@ -0,0 +1,43 @@
+Hello,
+
+in a clean-up spree, I removed unused content from my repos and ran fsck.
+
+I found the behaviour of fsck surprising. I'm reporting it here to give feedback (and maybe get corrected).
+
+I expected fsck to basically check that git annex's "recorded state" matches the actual
+filesystem state (ie. expected files are present and they have the expected checksum).
+
+fsck does that, but it also checks that the "numcopies" rule is enforced.
+If I'm not mistaken, this check is quite different:
+* it does not correspond to an error
+* the reported issue is possibly irrelevant if the repo has an outdated view of the other remotes.
+* the reported issue might be fixed by adding copies of the content to any other repo, not specificallyb to the one being fsck-ed.
+
+Moreover, if fsck checks numcopies, I'd expect it to also check if the "required"
+rule is enforced on the current repo, which it does not (tested on git annex 6.20170101.1).
+Sice fixing a missing "required" file would need to add a copy to current repo, I'd consider this check more "local" than the numcopies one. 
+(Or alternatively, maybe fsck sould fully be "global" and report "required" rule violations about all the repos/remotes?).
+
+
+
+Because my backup/archival repos are bare, fsck defaults to --all, and will complain
+about insufficient numcopies for content that I intentionally dropped (with --unused --force).
+It scared me at first, but I not
+
+I envision several solutions to avoid those complaints:
+
+* use --numcopies=0 (by the way, https://git-annex.branchable.com/git-annex-fsck/, states
+"To verify data integrity only while disregarding required number of copies, use --numcopies=1.",
+I think it should be =0)
+
+* mark all those keys as dead (this seems time consuming)
+
+* rewrite the git history or use git annex forget (untested, seems dangerous).
+
+* maybe replace my backup/archival bare git repos with "directory" special remotes (less state involved).
+
+
+Am I missing a better way?
+
+PS. I attached a script illustrating the issue, together with its output.
+PPS Thank you for git-annex!
diff --git a/doc/forum/got_confused_by_fsck/comment_1_ab35fea4d46ee93e62ab67e5af3dfcbf._comment b/doc/forum/got_confused_by_fsck/comment_1_ab35fea4d46ee93e62ab67e5af3dfcbf._comment
new file mode 100644
index 0000000000..39b5ccc757
--- /dev/null
+++ b/doc/forum/got_confused_by_fsck/comment_1_ab35fea4d46ee93e62ab67e5af3dfcbf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-11-15T02:11:43Z"
+ content="""
+\"if the repo has an outdated view of the other remotes\" -- maybe, do git annex sync first, so that the repo has an up-to-date view of the other remotes?
+"""]]
diff --git a/doc/forum/got_confused_by_fsck/comment_2_19c730cb1337dc8794721cf5679c930b._comment b/doc/forum/got_confused_by_fsck/comment_2_19c730cb1337dc8794721cf5679c930b._comment
new file mode 100644
index 0000000000..f5d08e3045
--- /dev/null
+++ b/doc/forum/got_confused_by_fsck/comment_2_19c730cb1337dc8794721cf5679c930b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-11-15T19:12:30Z"
+ content="""
+fsck has checked required content (across all repos) since version 6.20180227.
+
+There are many ways that some copies of a file could be lost without the
+user really noticing, so it makes sense for fsck to check numcopies.
+
+The local/global distinction you are trying to draw is not one I'm really
+interested in drawing with fsck. It checks everything that it's practical
+for it to check that we've thought of checking.
+
+If you don't want to check all keys in a bare repo, you can use 
+`git annex fsck --branch=master` to only check the files in the master
+branch.
+"""]]
diff --git a/doc/forum/handling_MP3_metadata_changes.mdwn b/doc/forum/handling_MP3_metadata_changes.mdwn
new file mode 100644
index 0000000000..9b6caa27aa
--- /dev/null
+++ b/doc/forum/handling_MP3_metadata_changes.mdwn
@@ -0,0 +1,12 @@
+Hello,
+
+I'm still looking for a way to version control the metadata (title, artist, album name, ...) of my MP3s, I wonder if git annex could help for this problem ?
+The method I use now (without git annex) is to export the MP3 metadata to an textual format with one line per tag. 
+It's this textual file I handles with git. 
+The problem is to handle the mapping between the orignal file and the export file with file renaming or moving.
+I consider to use the checksum of the audio content (without metadata, this checksum never changes) to handle this problem.
+Maybe git annex has a different approach (better) to solve this problem ?
+How git annex would be use to solve the orignal problem ?
+
+Regards,
+Emmanuel Berry
diff --git a/doc/forum/handling_MP3_metadata_changes/comment_1_aa4955fd64ea5aa836f1a591e185c4a2._comment b/doc/forum/handling_MP3_metadata_changes/comment_1_aa4955fd64ea5aa836f1a591e185c4a2._comment
new file mode 100644
index 0000000000..483c1fb78d
--- /dev/null
+++ b/doc/forum/handling_MP3_metadata_changes/comment_1_aa4955fd64ea5aa836f1a591e185c4a2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.154"
+ subject="comment 1"
+ date="2014-03-18T19:29:53Z"
+ content="""
+Check out [[metadata]]
+"""]]
diff --git a/doc/forum/hashing_objects_directories.mdwn b/doc/forum/hashing_objects_directories.mdwn
new file mode 100644
index 0000000000..5b7708fb58
--- /dev/null
+++ b/doc/forum/hashing_objects_directories.mdwn
@@ -0,0 +1,27 @@
+I'm wondering how easy the addition of hashing to the directories of the objects would be.
+
+Currently a tree directory structure becomes a flat two level tree under the .git/annex/objects directory ([[internals]]).  This, through the 555 mode on the directory prevents the accidental destruction of content, which is _good_.  However file and directory numbers soon add up in there and as such any file-systems with sub directory limitations will quickly realize the limit (certainly quicker than maybe expected).
+
+Suggestion is therefore to change from 
+
+ `.git/annex/objects/SHA1:123456789abcdef0123456789abcdef012345678/SHA1:123456789abcdef0123456789abcdef012345678`
+
+to 
+
+ `.git/annex/objects/SHA1:1/2/3456789abcdef0123456789abcdef012345678/SHA1:123456789abcdef0123456789abcdef012345678`
+
+or anything in between to a paranoid
+
+ `.git/annex/objects/SHA1:123/456/789/abc/def/012/345/678/9ab/cde/f01/234/5678/SHA1:123456789abcdef0123456789abcdef012345678`
+
+Also the use of a colon specifically breaks FAT32 ([[bugs/fat_support]]), must it be a colon or could an extra directory be used? i.e. `.git/annex/objects/SHA1/*/...`
+
+`git annex init` could also create all but the last level directory on initialization. I'm thinking `SHA1/1/1, SHA1/1/2, ..., SHA256/f/f, ..., URL/f/f, ..., WORM/f/f`
+
+> This is done now with a 2-level hash. It also hashes .git-annex/ log
+> files which were the worse problem really. Scales to hundreds of millions
+> of files with each dir having 1024 or fewer contents. Example:
+>
+> `me -> .git/annex/objects/71/9t/WORM-s3-m1300247299--me/WORM-s3-m1300247299--me`
+>
+> --[[Joey]]
diff --git a/doc/forum/hashing_objects_directories/comment_1_c55c56076be4f54251b0b7f79f28a607._comment b/doc/forum/hashing_objects_directories/comment_1_c55c56076be4f54251b0b7f79f28a607._comment
new file mode 100644
index 0000000000..3a19310b63
--- /dev/null
+++ b/doc/forum/hashing_objects_directories/comment_1_c55c56076be4f54251b0b7f79f28a607._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-03-14T16:12:49Z"
+ content="""
+My experience is that modern filesystems are not going to have many issues with tens to hundreds of thousands of items in the directory. However, if a transition does happen for FAT support I will consider adding hashing. Although getting a good balanced hash in general without, say, checksumming the filename and taking part of the checksum, is difficult. 
+
+I prefer to keep all the metadata in the filename, as this eases recovery if the files end up in lost+found. So while \"SHA/\" is a nice workaround for the FAT colon problem, I'll be doing something else. (What I'm not sure yet.)
+
+There is no point in creating unused hash directories on initialization. If anything, with a bad filesystem that just guarantees worst performance from the beginning..
+"""]]
diff --git a/doc/forum/hashing_objects_directories/comment_2_504c96959c779176f991f4125ea22009._comment b/doc/forum/hashing_objects_directories/comment_2_504c96959c779176f991f4125ea22009._comment
new file mode 100644
index 0000000000..64f1e16b50
--- /dev/null
+++ b/doc/forum/hashing_objects_directories/comment_2_504c96959c779176f991f4125ea22009._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 2"
+ date="2011-03-15T13:52:16Z"
+ content="""
+Can't you just use an underscore instead of a colon?
+
+Would it be feasible to split directories dynamically? I.e. start with SHA1_123456789abcdef0123456789abcdef012345678/SHA1_123456789abcdef0123456789abcdef012345678 and, at a certain cut-off point, switch to shorter directory names? This could even be done per subdirectory and based purely on a locally-configured number. Different annexes on different file systems or with different file subsets might even have different thresholds. This would ensure scale while not forcing you to segment from the start. Also, while segmenting with longer directory names means a flatter tree, segments longer than four characters might not make too much sense. Segmenting too often could lead to some directories becoming too populated, bringing us back to the dynamic segmentation.
+
+All of the above would make merging annexes by hand a _lot_ harder, but I don't know if this is a valid use case. And if all else fails, one could merge everything with the unsegemented directory names and start again from there.
+
+-- RichiH
+"""]]
diff --git a/doc/forum/hashing_objects_directories/comment_3_9134bde0a13aac0b6a4e5ebabd7f22e8._comment b/doc/forum/hashing_objects_directories/comment_3_9134bde0a13aac0b6a4e5ebabd7f22e8._comment
new file mode 100644
index 0000000000..51deb2f959
--- /dev/null
+++ b/doc/forum/hashing_objects_directories/comment_3_9134bde0a13aac0b6a4e5ebabd7f22e8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-03-16T03:13:39Z"
+ content="""
+It is unfortunatly not possible to do system-dependant hashing, so long as git-annex stores symlinks to the content in git.
+
+It might be possible to start without hashing, and add hashing for new files after a cutoff point. It would add complexity.
+
+I'm currently looking at a 2 character hash directory segment, based on an md5sum of the key, which splits it into 1024 buckets. git uses just 256 buckets for its object directory, but then its objects tend to get packed away. I sorta hope that one level is enough, but guess I could go to 2 levels (objects/ab/cd/key), which would provide 1048576 buckets, probably plenty, as if you are storing more than a million files, you are probably using a modern enough system to have a filesystem that doesn't need hashing.
+"""]]
diff --git a/doc/forum/hashing_objects_directories/comment_4_0de9170e429cbfea66f5afa8980d45ac._comment b/doc/forum/hashing_objects_directories/comment_4_0de9170e429cbfea66f5afa8980d45ac._comment
new file mode 100644
index 0000000000..b29eea1b2b
--- /dev/null
+++ b/doc/forum/hashing_objects_directories/comment_4_0de9170e429cbfea66f5afa8980d45ac._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 4"
+ date="2011-03-16T04:06:19Z"
+ content="""
+The .git-annex/ directory is what really needs hashing.
+
+Consider that when git looks for changes in there, it has to scan every file in the directory. With hashing, it should be able to more quickly identify just the subdirectories that contained changed files, by the directory mtimes.
+
+And the real kicker is that when committing there, git has to create a tree object containing every single file, even if only 1 file changed. That will be a lot of extra work; with hashed subdirs it will instead create just 2 or 3 small tree objects leading down to the changed file. (Probably these trees both pack down to similar size pack files, not sure.)
+"""]]
diff --git a/doc/forum/hashing_objects_directories/comment_5_ef6cfd49d24c180c2d0a062e5bd3a0be._comment b/doc/forum/hashing_objects_directories/comment_5_ef6cfd49d24c180c2d0a062e5bd3a0be._comment
new file mode 100644
index 0000000000..c558ee65ee
--- /dev/null
+++ b/doc/forum/hashing_objects_directories/comment_5_ef6cfd49d24c180c2d0a062e5bd3a0be._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 5"
+ date="2011-03-16T15:47:17Z"
+ content="""
+If you can't segment the names retroactively, it's better to start with segmenting, imo.
+
+As subdirectories are cheap, going with ab/cd/rest or even ab/cd/ef/rest by default wouldn't hurt.
+
+Your point about git not needing to create as many tree objects is a kicker indeed. If I were you, I would default to segmentation.
+"""]]
diff --git a/doc/forum/help__44___a_bunch_of_files_disappeared.mdwn b/doc/forum/help__44___a_bunch_of_files_disappeared.mdwn
new file mode 100644
index 0000000000..b3479e9030
--- /dev/null
+++ b/doc/forum/help__44___a_bunch_of_files_disappeared.mdwn
@@ -0,0 +1,15 @@
+I have a large repo full of movies (dvd and blue-ray rips). I host it on my ubuntu linux 16.04 xenial system which sits next to my tv.
+
+I use git annex sync to copy stuff to my mac laptop running high sierra and I just updated to the brew version of git-annex there, 6.20171109
+
+I also have a copy on my really old laptop running mac os x lion, that one has a really really old version running.
+
+I hadn't done a git annex sync in a long time. so I updated via brew on my high sierra laptop to 6.20171109 and ran git annex sync on the laptop, and then on my server.
+
+when I ran git annex sync on my server, i saw it modify the 6 or so movies which I had copied over to the old lion laptop long ago. those six movies are now pointed to hashes which don't exist, and when I look at the history, the previous hashes don't exist either.
+
+then I ran a git annex fsck on the server, and it listed tons of movies which is says have no known copies. at some point, all of them were on the server. I suspect, but don't know how to confirm, that all the movies are still sitting in the annex on the server, but many many of the links are wrong.
+
+how can I fix the links?
+
+thanks.
diff --git a/doc/forum/help__44___a_bunch_of_files_disappeared/comment_1_56cffd43ad7056a34c23b139f95ea58e._comment b/doc/forum/help__44___a_bunch_of_files_disappeared/comment_1_56cffd43ad7056a34c23b139f95ea58e._comment
new file mode 100644
index 0000000000..53fea0012c
--- /dev/null
+++ b/doc/forum/help__44___a_bunch_of_files_disappeared/comment_1_56cffd43ad7056a34c23b139f95ea58e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="astrophoenix"
+ avatar="http://cdn.libravatar.org/avatar/cb0b7982b6877c58c3860d8ad5fb3148"
+ subject="possible cause (my error)"
+ date="2017-11-12T21:01:28Z"
+ content="""
+oh, it might have been something dumb i did:
+
+at some point I wanted to delete a few files, so trying to be cute I did this:
+
+m=OneMovie.m4v git annex drop --force $m; git rm $m; git ci -m \"rm $m\"
+
+I noted that didn't work, but didn't realize it might've taken out most/all the files in the folder
+
+"""]]
diff --git a/doc/forum/help__44___a_bunch_of_files_disappeared/comment_2_7675ff78cf1b5f58618c5c57da8591b5._comment b/doc/forum/help__44___a_bunch_of_files_disappeared/comment_2_7675ff78cf1b5f58618c5c57da8591b5._comment
new file mode 100644
index 0000000000..a99aa7bb90
--- /dev/null
+++ b/doc/forum/help__44___a_bunch_of_files_disappeared/comment_2_7675ff78cf1b5f58618c5c57da8591b5._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-11-14T17:16:54Z"
+ content="""
+There are two possible things that could have happened.
+
+1. Maybe something somehow wrong got committed to the git repository
+   for the missing files. 
+   
+   If so, you can *always* use git to check out
+   the older version before that commit, and will then be able to see
+   the files; git-annex will know where the content of them is, etc.
+   You can also use `git revert` to revert such a bad commit.
+
+2. Maybe you accidentially dropped the content of the files with --force,
+   and if so, you may have lost the content.
+
+   If you run `git annex log` on one of the files, and look at the lines
+   starting with "-", you can see when the file content was removed from
+   repositories. But there's no way to get it back unless you have another
+   copy somewhere.
+"""]]
diff --git a/doc/forum/help__44___a_bunch_of_files_disappeared/comment_3_4b700ccba2b40fdc1d172a3dcbc441e5._comment b/doc/forum/help__44___a_bunch_of_files_disappeared/comment_3_4b700ccba2b40fdc1d172a3dcbc441e5._comment
new file mode 100644
index 0000000000..c5b402ec94
--- /dev/null
+++ b/doc/forum/help__44___a_bunch_of_files_disappeared/comment_3_4b700ccba2b40fdc1d172a3dcbc441e5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="astrophoenix"
+ avatar="http://cdn.libravatar.org/avatar/cb0b7982b6877c58c3860d8ad5fb3148"
+ subject="comment 3"
+ date="2017-11-14T19:45:41Z"
+ content="""
+I'm nearly 100% certain I did a drop --force by mistake. I'm pulling the files from backups. 
+
+thank you!
+"""]]
diff --git a/doc/forum/help_running_git-annex_on_top_of_existing_repo.mdwn b/doc/forum/help_running_git-annex_on_top_of_existing_repo.mdwn
new file mode 100644
index 0000000000..365ad71db7
--- /dev/null
+++ b/doc/forum/help_running_git-annex_on_top_of_existing_repo.mdwn
@@ -0,0 +1,12 @@
+## Question
+Can git-annex run passively with an existing repo?
+
+## Scenario
+We have an existing web application with large binary assets spread throughout modules in the repo. The project is in constant development with weekly deploys to production and there are many developers working on the project.
+
+## Goal
+We need to maintain the directory structure for these assets without actually committing large binaries to the main remote (hosted on GitHub). I need a solution that has a low barrier of entry when on-boarding new developers. I was thinking maybe a script the is executed on every commit that would filter binaries files based on extensions and commit them to the git-annex remote instead. We are flexible on the type of remote storage type (SSH, S3, etc)
+
+## Notes
+I have gone through the last couple months of forum posts and done a bit of Googling but have come up empty. If anyone can point me in the right direction that would be great. 
+Thanks!
diff --git a/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_1_4cb38d71c943657c5ba0896cd70d2e64._comment b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_1_4cb38d71c943657c5ba0896cd70d2e64._comment
new file mode 100644
index 0000000000..b98ad63232
--- /dev/null
+++ b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_1_4cb38d71c943657c5ba0896cd70d2e64._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 1"
+ date="2013-06-01T09:21:54Z"
+ content="""
+Mixing files controlled by git directly and files controlled by git annex is possible, simply 'git annex add' the large files and 'git add' the rest. You will not be able to use direct mode and you should not run the git annex assisstant, as it will add all files to the annex. 
+"""]]
diff --git a/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_2_b5e94c10ebbed9125c7e2332f75709ca._comment b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_2_b5e94c10ebbed9125c7e2332f75709ca._comment
new file mode 100644
index 0000000000..ba321df6bc
--- /dev/null
+++ b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_2_b5e94c10ebbed9125c7e2332f75709ca._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9FMhhhM2sJ68Zjx_RmWd8cTdpI-mrkbE"
+ nickname="Hans"
+ subject="what about with git-svn?"
+ date="2013-06-04T08:00:15Z"
+ content="""
+I'm trying to wrap my head around a similar situation.
+I've tested this by git cloning my repo; the symlinks are copied, and end up broken because the annex directory under .git doesn't exist in the new repo.
+
+So to be specific: can I conclude that when I use git to copy my repo, as long as I don't explicitly use git-annex in the process, I end up with a 'bare' git repo and I don't have to worry about my annexed files coming along?
+
+Also: anyone know of anything that would be different about using git-svn? (i.e. git svn dcommit to push my changes to an svn repo)?
+"""]]
diff --git a/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_3_2b3b93bbc60fbc24d436231954d6822a._comment b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_3_2b3b93bbc60fbc24d436231954d6822a._comment
new file mode 100644
index 0000000000..8d2fd0dff1
--- /dev/null
+++ b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_3_2b3b93bbc60fbc24d436231954d6822a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 3"
+ date="2013-06-04T12:29:04Z"
+ content="""
+As long as you're not using Direct Mode, then a git-annex repo is just an absolutely ordinary git repo, which happens to contain some symlinks that point to .git/annex/objects/*
+
+
+"""]]
diff --git a/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_4_2dfda33ffa39b92b16c8bd9005e1cefe._comment b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_4_2dfda33ffa39b92b16c8bd9005e1cefe._comment
new file mode 100644
index 0000000000..e9f22adfd4
--- /dev/null
+++ b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_4_2dfda33ffa39b92b16c8bd9005e1cefe._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9J51AO9t75xN5k0sJgg8taUo4y0a4hpQ"
+ nickname="Daniel"
+ subject="comment 4"
+ date="2013-06-07T23:02:29Z"
+ content="""
+I'm trying to find a way to prevent developers from adding certain file types to the main repo. Is there something like a pre-add hook that could be used?
+
+I found this in another forum but I'm not sure how it was intended to be implemented.
+
+```
+git check-attr addtoannex \"$FILE\" | grep -q \": set$\"  
+if [ $? -eq 0 ]; then  
+    git annex add \"$FILE\"  
+else  
+    git add \"$FILE\"  
+fi  
+```
+
+[http://git-annex.branchable.com/forum/Let_watch_selectively_annex_files/](http://git-annex.branchable.com/forum/Let_watch_selectively_annex_files/)
+"""]]
diff --git a/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_5_96b1eb1e8e9f315c646f4686870f9b52._comment b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_5_96b1eb1e8e9f315c646f4686870f9b52._comment
new file mode 100644
index 0000000000..6435fc2528
--- /dev/null
+++ b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_5_96b1eb1e8e9f315c646f4686870f9b52._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 5"
+ date="2013-06-11T14:30:08Z"
+ content="""
+I think the most useful thing for people in this thread to know about is [[tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant]].
+
+This doesn't solve it at the command line, where you still need to choose between git add and git annex add, but you can use git annex watch to automatically commit small files to git, and large files to the git annex.
+"""]]
diff --git a/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_6_e85c3fa1d17f1d6ec625b9c4f9b698c3._comment b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_6_e85c3fa1d17f1d6ec625b9c4f9b698c3._comment
new file mode 100644
index 0000000000..6220a44166
--- /dev/null
+++ b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_6_e85c3fa1d17f1d6ec625b9c4f9b698c3._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9J51AO9t75xN5k0sJgg8taUo4y0a4hpQ"
+ nickname="Daniel"
+ subject="comment 6"
+ date="2013-06-11T22:28:52Z"
+ content="""
+This is what I ended up doing.  
+[https://gist.github.com/ifnull/5761255](https://gist.github.com/ifnull/5761255)
+
+Basically you just add the extensions of the files you want to exclude to .gitignore_large_binaries and run \"git a .\" instead of \"git add .\"
+
+    #######################
+    # Setup
+    #######################
+    mkdir annex-test
+    cd annex-test
+    git init
+    git annex init master
+
+    #######################
+    # Fab setup task
+    #######################
+    git config --local core.excludesfile ./.gitignore_large_binaries
+    git config --local alias.a '! sh ./git-add.sh'
+
+    #######################
+    # git a (git-add.sh)
+    #######################
+
+    # Generate annex include arg from .gitignore_large_binaries
+    include_str=\"--include='.lazy'\";
+
+    while read line
+    do
+        if [[ \"$line\" != *\"#\"* ]] && [[ \"$line\" != \"\" ]]; then 
+            include_str=\"$include_str --or --include=${line}\";
+        fi
+    done < \"./.gitignore_large_binaries\"
+
+    # git annex add
+    git config --local core.excludesfile ./.gitignore;
+    git annex add $1 $include_str;
+
+    # git add
+    git config --local core.excludesfile ./.gitignore_large_binaries;
+    git add $1
+"""]]
diff --git a/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_7_15d918ededb5b8375b0ca13d0b3523ff._comment b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_7_15d918ededb5b8375b0ca13d0b3523ff._comment
new file mode 100644
index 0000000000..1ca6b80ad5
--- /dev/null
+++ b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_7_15d918ededb5b8375b0ca13d0b3523ff._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlog_5wIICaMcrKTexlFNA6IO6UTp323aE"
+ nickname="Torkaly"
+ subject="comment 7"
+ date="2014-10-17T11:00:06Z"
+ content="""
+Is there a way just to sync *git-annex* branch with the *git annex sync* command? As we have an already existing git branch and want to push/pull *master* manually.
+"""]]
diff --git a/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_8_dcc3f2c6d55006776610e8d770b61d12._comment b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_8_dcc3f2c6d55006776610e8d770b61d12._comment
new file mode 100644
index 0000000000..35983e802f
--- /dev/null
+++ b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_8_dcc3f2c6d55006776610e8d770b61d12._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2014-10-20T15:25:13Z"
+ content="""
+@Torkaly just `git pull` as usual, and then run `git annex merge`
+to auto-merge the git-anne branches. Then `git push origin git-annex`
+to push the git-annex branch.
+"""]]
diff --git a/doc/forum/help_with_building_git-annex_on_conda-forge.mdwn b/doc/forum/help_with_building_git-annex_on_conda-forge.mdwn
new file mode 100644
index 0000000000..2ce28c1692
--- /dev/null
+++ b/doc/forum/help_with_building_git-annex_on_conda-forge.mdwn
@@ -0,0 +1,8 @@
+I've been maintaining the recipe for installing git-annex with the  [conda-forge](https://conda-forge.org/) package manager.  I'm having trouble making the recipe work with the current conda-forge version, and would much appreciate any help, especially from people who understand Haskell/ghc/stack/cabal .  The recipe is here: https://github.com/conda-forge/git-annex-feedstock .  I keep getting error related to not finding libgmp, even though it is installed as a dependency:
+https://circleci.com/gh/conda-forge/git-annex-feedstock/157?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
+
+The benefit of having a working conda-forge recipe is that it enables git-annex installation without root privileges, and enables building other conda-installable tools that depend on git-annex.
+
+Thanks,
+
+ilya
diff --git a/doc/forum/help_with_building_git-annex_on_conda-forge/comment_1_369460f5de3219b80a7b2da5bda9aced._comment b/doc/forum/help_with_building_git-annex_on_conda-forge/comment_1_369460f5de3219b80a7b2da5bda9aced._comment
new file mode 100644
index 0000000000..178817e8db
--- /dev/null
+++ b/doc/forum/help_with_building_git-annex_on_conda-forge/comment_1_369460f5de3219b80a7b2da5bda9aced._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-02-07T20:23:03Z"
+ content="""
+ghc links to libgmp, and uses the system library, and I can see in the log
+that is working; ghc outputs " [1 of 1] Compiling Main ..."
+
+The problem seems to be with
+`/home/conda/feedstock_root/build_artifacts/git-annex_1548210869175/_build_env/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld`
+which is not the system ld, nor is it coming from stack, so I guess it's
+conda's ld which is for whatever reason not finding the system libgmp.
+"""]]
diff --git a/doc/forum/help_with_building_git-annex_on_conda-forge/comment_2_e72eaf736e2a534fa5970183a2f671af._comment b/doc/forum/help_with_building_git-annex_on_conda-forge/comment_2_e72eaf736e2a534fa5970183a2f671af._comment
new file mode 100644
index 0000000000..826176b869
--- /dev/null
+++ b/doc/forum/help_with_building_git-annex_on_conda-forge/comment_2_e72eaf736e2a534fa5970183a2f671af._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-02-07T20:45:11Z"
+ content="""
+Question is, why isn't ghc passing the -L/path/to/libgmp option to ld (or maybe stack isn't passing it to ghc), even though the path is listed in --extra-lib-dirs when calling stack?
+"""]]
diff --git a/doc/forum/how_do_automated_upgrades_work__63__.mdwn b/doc/forum/how_do_automated_upgrades_work__63__.mdwn
new file mode 100644
index 0000000000..1f404d1449
--- /dev/null
+++ b/doc/forum/how_do_automated_upgrades_work__63__.mdwn
@@ -0,0 +1,11 @@
+When i start the assistant, it's nicely telling me:
+
+<pre>
+[2015-05-27 20:15:20 UTC] Upgrader: An upgrade of git-annex is available.  (version 5.20150522)
+</pre>
+
+That's really cool, but it's not actually upgrading. I looked around the website to understand how that worked and i found [[git-annex-upgrade]] and [[upgrades]] but those pages were not really useful, as they talk more about repository upgrades, and not the automated upgrade system. I was expecting [[upgrades]] to talk a bit about automated upgrades, or maybe the [[install]] page... 
+
+i am running `5.20150508-g883d57f`, with a standalone image installed by root in `/opt`. Should that directory be writable by the user running git-annex to solve this?
+
+Thanks! --[[anarcat]]
diff --git a/doc/forum/how_do_automated_upgrades_work__63__/comment_1_cfd00ac3a3eaa3c2a1d430f6544c32f0._comment b/doc/forum/how_do_automated_upgrades_work__63__/comment_1_cfd00ac3a3eaa3c2a1d430f6544c32f0._comment
new file mode 100644
index 0000000000..7269a2a198
--- /dev/null
+++ b/doc/forum/how_do_automated_upgrades_work__63__/comment_1_cfd00ac3a3eaa3c2a1d430f6544c32f0._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-06-02T18:57:43Z"
+ content="""
+The assistant checks for available upgrades a few times a day.
+By default, it only pops up a message in the webapp with an upgrade button.
+
+annex.autoupgrade can configure this, so the assistant can be made
+to upgrade without confirmation if you want.
+
+The upgrade process needs to move the git-annex.linux directory out of the
+way and replace it with a new one from the tarball, so it will only
+work if the user running the assistant can write to it.
+"""]]
diff --git a/doc/forum/how_do_automated_upgrades_work__63__/comment_2_5ef98e46c514e9b794ee719e4cc8fda4._comment b/doc/forum/how_do_automated_upgrades_work__63__/comment_2_5ef98e46c514e9b794ee719e4cc8fda4._comment
new file mode 100644
index 0000000000..76401a89ea
--- /dev/null
+++ b/doc/forum/how_do_automated_upgrades_work__63__/comment_2_5ef98e46c514e9b794ee719e4cc8fda4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="understood"
+ date="2015-06-03T14:25:39Z"
+ content="""
+alright, i have added this to the [[upgrades]] page, i hope that's okay.
+"""]]
diff --git a/doc/forum/how_do_i_manually_sync_my_external_drive__63__.mdwn b/doc/forum/how_do_i_manually_sync_my_external_drive__63__.mdwn
new file mode 100644
index 0000000000..a5685761d6
--- /dev/null
+++ b/doc/forum/how_do_i_manually_sync_my_external_drive__63__.mdwn
@@ -0,0 +1,9 @@
+I am working on rehauling my backup scripts here, and I was originally doing an rsync of everything to an external drive, but now I think I can be smarted and skip my annexes in that rsync, and use git-annex superpowers to do the sync instead.
+
+I have added this to my backup script:
+
+    ( cd /srv/video && git annex copy --to backup . )
+
+And it works, so yaaay. :) However, I feel it could be faster. This seems to check each file one at a time, but doesn't git-annex keep a state of the remote internally, which would allow it to copy over only the missing files, without checking if each file is present individually?
+
+I mean, it's still pretty fast considering the dataset, but I wonder if there isn't some fast/easier way. Keep in mind I am hesitant of using the assistant for this because I am [[confused_about_external_drives]], the [[bugs/webapp takes 100% of the cpu]] and the [[bugs/assistant eats all CPU]]. I would prefer to script this anyways. --[[anarcat]]
diff --git a/doc/forum/how_do_i_manually_sync_my_external_drive__63__/comment_1_4fd8722cafd55b0503c802289206645a._comment b/doc/forum/how_do_i_manually_sync_my_external_drive__63__/comment_1_4fd8722cafd55b0503c802289206645a._comment
new file mode 100644
index 0000000000..290221541f
--- /dev/null
+++ b/doc/forum/how_do_i_manually_sync_my_external_drive__63__/comment_1_4fd8722cafd55b0503c802289206645a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2014-01-01T20:43:05Z"
+ content="""
+Pulling location tracking data out of git is unlikely to be faster than statting a single file on the drive, unless the drive is dead slow.
+
+If you really want to force it to use the location tracking information, use `--not --in backup`
+"""]]
diff --git a/doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__.mdwn b/doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__.mdwn
new file mode 100644
index 0000000000..67ba99b986
--- /dev/null
+++ b/doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__.mdwn
@@ -0,0 +1,9 @@
+I have a git annex repository that contains only photos and videos. I am using an NTFS partition on Linux (because dual-boot), and recently did a `git annex upgrade` to version 6. (But the question below is general, and not about version 6). The size of my repo must be around 80G.
+
+When I run commands like status and sync, nothing happens for a really long time. I finished a `git annex fsck` today morning after the version upgrade, and so wanted to see what the repo now looks like:
+
+    git annex status --debug
+
+This is stuck at internally calling `git status -uall -z` with some other options. The process is stuck here for almost an hour, and I finally gave up and cancelled it. Like I said, this is not about the recent upgrade that I finished. I have previously seen the process succeed after one or two hours.
+
+Is it normal for `status` to take this long? Or is there something wrong with my repo? For example, maybe a large chunk of my files are checked into git without being annexed? My repo has a long history of making mistakes with git annex, so this is actually possible.
diff --git a/doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__/comment_1_26d959bb3cfdc690b1eab41c9b0b5dc4._comment b/doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__/comment_1_26d959bb3cfdc690b1eab41c9b0b5dc4._comment
new file mode 100644
index 0000000000..89cc134bde
--- /dev/null
+++ b/doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__/comment_1_26d959bb3cfdc690b1eab41c9b0b5dc4._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-01-30T17:35:27Z"
+ content="""
+Generally git-annex takes longer the more files in the repository it needs
+to deal with. If a repository gets a great many files (typically 
+hundreds of thousands to millions), various inneficiencies in git annex
+git-annex will slow things down enough that it gets annoying.
+Splitting the files into different branches 
+(or separate repositories) is a common way to deal with that.
+
+Also, running on a spinning disk tends to be a lot slower than a SSD.
+
+Just for comparison, `git annex status` in a repository with 75000 files
+takes 0.5 seconds on my laptop's SSD. `git status` takes 0.2 seconds.
+
+In your particular case, the NTFS partition and/or v6
+mode seems likely to be the reason for slowdowns. Both git and git-annex
+record the inode numbers used for files in the repository. Those numbers
+are supposed to be stable, but mounting a filesystem on windows and then
+linux will make the inode numbers change. (Even remounting a FAT
+partition on linux will change the inodes, although that doesn't seem
+to happen for NTFS in a quick test).
+
+When the inodes have changed, much slower code paths get activated, since
+git and git-annex have to then assume the contents of the files may have
+changed since the last time they saw them. In a v6 repository where this
+has happened, `git status` is quite likely running `git-annex smudge`
+once per file in the working tree, which is quite slow.
+"""]]
diff --git a/doc/forum/how_to___34__move__34___URL_between_remotes__63__.mdwn b/doc/forum/how_to___34__move__34___URL_between_remotes__63__.mdwn
new file mode 100644
index 0000000000..bdf73143da
--- /dev/null
+++ b/doc/forum/how_to___34__move__34___URL_between_remotes__63__.mdwn
@@ -0,0 +1,6 @@
+In [backups2datalad](https://github.com/dandi/backups2datalad/pull/21) we are implementing support for "embargoed" data -- files which would require authorization initially. To provide authentication support we enable/configure `git-annex-remote-datalad` to handle them.  But in the future, when data gets unembargoed we would need to remove/disable `datalad` special remote and migrate (the same) URLs to no longer be associated with it and rather be handled by `web` remote.  Generally the use case might desire moving URLs between remotes (e.g. from `datalad` to `datalad-next`), or migrating from `web` into an external remote.
+
+Is it already possible reasonably well, or would require messing with `.web` files in the git-annex branch?
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
diff --git a/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_1_d4fb3eff1b61c60224fec112df9f1136._comment b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_1_d4fb3eff1b61c60224fec112df9f1136._comment
new file mode 100644
index 0000000000..74b172240c
--- /dev/null
+++ b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_1_d4fb3eff1b61c60224fec112df9f1136._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-02-02T18:48:59Z"
+ content="""
+I see you're using CLAIMURL. What `git-annex addurl` does when a special
+remote claims an url is it records the url for the key in the git-annex
+branch, but mangled to indicate that it is not an url used by the web
+special remote.
+
+The mangling is just to prefix the url with ":".
+
+If you `git-annex registerurl --remote=web` the same url again
+but without that prefix, and  
+`git-annex setpresentkey $key 00000000-0000-0000-0000-000000000001 1`,
+the url will will able to be downloaded by the web special remote. 
+
+Then you can unregisterurl the (unmangled) url from your remote that you no
+longer want to use, and use setpresentkey with your remote's uuid and "0" to
+remove the mangled url.
+
+I don't think there's any plumbing currently that makes it easy to access
+and demangle the urls. `git-annex whereis --json` will list the demangled
+url in the "urls" field, but in amoung any other urls that other special
+remotes might have for the same content. Without --json there is a nice
+display that shows the remote that claims the url:
+
+	joey@darkstar:~/tmp/bench/rx>git-annex whereis
+	whereis foo (1 copy)
+	  	177d51e9-a115-443e-8100-49588f8a6ca2 -- foo [test]
+	
+	  test: http://example.com/foo.test
+
+Improving the whereis --json or adding some other machine-readable 
+way to list urls claimed by a remote seems like maybe worth doing?
+Let me know.
+"""]]
diff --git a/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_2_c122906fd03bd723aa027fe32fd4fab6._comment b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_2_c122906fd03bd723aa027fe32fd4fab6._comment
new file mode 100644
index 0000000000..d2a8434623
--- /dev/null
+++ b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_2_c122906fd03bd723aa027fe32fd4fab6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2024-02-03T01:17:39Z"
+ content="""
+in theory - yes. In practice, ATM I would probably just `git annex whereis | awk -e \"/^ *$remote:/{print $2;}\"` or alike in bash, and in Python it would be quite trivial to filter for a specific remote. 
+The main \"hurdle\" here would be the need to do that dance with registerurl/unregisterurl and given that we might need to do that for many thousands keys (imaging going through such repos as [dandizarrs](https://github.com/dandizarrs)), I felt like some internal dedicated function would be worthwhile.
+"""]]
diff --git a/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_3_adebe3ba65ba9fc0a4a7f4b664afc069._comment b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_3_adebe3ba65ba9fc0a4a7f4b664afc069._comment
new file mode 100644
index 0000000000..b6772525ad
--- /dev/null
+++ b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_3_adebe3ba65ba9fc0a4a7f4b664afc069._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-02-05T17:33:32Z"
+ content="""
+The commands you would need do all support --batch, so it seems very
+scriptable.
+
+I'm struggling a bit with the idea of a dedicated git-annex command for
+this, because it seems a fairly unusual situation.
+
+Maybe `git-annex registerurl could have a switch that says to move urls
+from remote foo to the web special remote? That would avoid needing to
+query for the urls.
+
+	git-annex registerurl --move-from=foo $key
+
+Since registering an url also marks it present, all you would need after
+that is to mark it as not present any longer on your special remote.
+"""]]
diff --git a/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_4_46ad0779ff71cfbadd663fe413d32ffb._comment b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_4_46ad0779ff71cfbadd663fe413d32ffb._comment
new file mode 100644
index 0000000000..82faf99196
--- /dev/null
+++ b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_4_46ad0779ff71cfbadd663fe413d32ffb._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2024-02-07T18:47:19Z"
+ content="""
+> `git-annex registerurl --move-from=foo $key`
+
+looks good
+
+> Since registering an url also marks it present, all you would need after that is to mark it as not present any longer on your special remote.
+
+it is `--move-from`, not `--copy-from`, so wouldn't it mark it not present any longer on `foo`?
+"""]]
diff --git a/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_5_712f40f27b27dfaf58c416ca7dc19045._comment b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_5_712f40f27b27dfaf58c416ca7dc19045._comment
new file mode 100644
index 0000000000..c9239dc1ae
--- /dev/null
+++ b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_5_712f40f27b27dfaf58c416ca7dc19045._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2024-03-05T17:23:34Z"
+ content="""
+Thing is that `unregisterurl` does not mark content as not present in a
+special remote. Except for the web which is a special case. Reason is
+that not having an url registered by a special remote does not prevent getting
+content from that special remote in general.
+
+So my idea for `--move-from=foo` was that it should behave the same way
+since it's the same as `registerurl + unregisterurl`.
+
+If you're going to remove/disable the special remote anyway, it won't
+matter whether git-annex thinks it contains content, I suppose? Or you
+could use setpresentkey of course.
+"""]]
diff --git a/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_6_260c238435f8f5e53511de7e574dd53f._comment b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_6_260c238435f8f5e53511de7e574dd53f._comment
new file mode 100644
index 0000000000..f1114fc3ba
--- /dev/null
+++ b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_6_260c238435f8f5e53511de7e574dd53f._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2024-03-05T18:11:32Z"
+ content="""
+Went far enough down implementing `registerurl --move-from` to be sure that
+it would complicate the code far more than just adding a new `moveurl`
+command. So despite it being a fairly unusual situation, a new command
+is better than that option.
+
+And implemented it:
+
+	joey@darkstar:~/tmp/x>git-annex registerurl WORM--bar http://example.com/bar.fooregisterurl http://example.com/bar.foo ok
+	joey@darkstar:~/tmp/x> git-annex whereis --key WORM--bar
+	whereis WORM--bar (1 copy)
+	  	dca0b5f9-659a-4928-84db-ff9fd74d8fc8 -- [foo]
+	
+	  foo: http://example.com/bar.foo
+	ok
+	joey@darkstar:~/tmp/x>git-annex reregisterurl WORM--bar --move-from=foo
+	reregisterurl WORM--bar ok
+	joey@darkstar:~/tmp/x>git-annex whereis --key WORM--bar
+	whereis WORM--bar (2 copies)
+	  	00000000-0000-0000-0000-000000000001 -- web
+	   	dca0b5f9-659a-4928-84db-ff9fd74d8fc8 -- [foo]
+	
+	  web: http://example.com/bar.foo
+	ok
+"""]]
diff --git a/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_7_742fde3d8f7aa0caa39dadc961c1b3d3._comment b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_7_742fde3d8f7aa0caa39dadc961c1b3d3._comment
new file mode 100644
index 0000000000..2754a0d81d
--- /dev/null
+++ b/doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_7_742fde3d8f7aa0caa39dadc961c1b3d3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2024-04-25T21:11:56Z"
+ content="""
+Thank you Joey!  I hope that release is coming some time soon? 
+"""]]
diff --git a/doc/forum/how_to_commit_removed_files_as_repo-droped_entries.mdwn b/doc/forum/how_to_commit_removed_files_as_repo-droped_entries.mdwn
new file mode 100644
index 0000000000..30250b12e8
--- /dev/null
+++ b/doc/forum/how_to_commit_removed_files_as_repo-droped_entries.mdwn
@@ -0,0 +1,9 @@
+I have following usecase:
+
+I want to use a central repos for xbmc/kodi where I can play and delete files from kodi somethimes also with a random file manager. But I normaly if a file gets deleted and synced with git annex sync it deletes the file "head" in every repository.
+
+I would like if its only a git annex drop of the content, if thats was the last copy ok then its ok for me that its gone. But if its not the last copy it shhould just delete it from this repo but not delete the heads of the other repositories.
+
+I know that the actual file is still in the other repositories but the entry is gone, I would love if it would be more like a git annex drop instead of a git rm.
+
+Can I do that with setting this repos readonly or is my usecase not supported/doable with git annex?
diff --git a/doc/forum/how_to_commit_removed_files_as_repo-droped_entries/comment_1_a9a4baebfb647898a76ee3d5ab6febfd._comment b/doc/forum/how_to_commit_removed_files_as_repo-droped_entries/comment_1_a9a4baebfb647898a76ee3d5ab6febfd._comment
new file mode 100644
index 0000000000..0312ac8db8
--- /dev/null
+++ b/doc/forum/how_to_commit_removed_files_as_repo-droped_entries/comment_1_a9a4baebfb647898a76ee3d5ab6febfd._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-09T17:15:19Z"
+ content="""
+One way to do this is to switch to a different branch. Then, deletion
+of a file won't propigate to other repositories, that don't have that
+same branch checked out.
+
+Or, see <http://git-annex.branchable.com/tips/file_manager_integration/>
+-- file managers can be taught to run `git annex drop` rather than deleting
+files. Perhaps xbmc/kodi could be too..
+"""]]
diff --git a/doc/forum/how_to_commit_removed_files_as_repo-droped_entries/comment_2_68392de15bae234de1332b8bc80cc2ff._comment b/doc/forum/how_to_commit_removed_files_as_repo-droped_entries/comment_2_68392de15bae234de1332b8bc80cc2ff._comment
new file mode 100644
index 0000000000..829402e583
--- /dev/null
+++ b/doc/forum/how_to_commit_removed_files_as_repo-droped_entries/comment_2_68392de15bae234de1332b8bc80cc2ff._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn4bbuawnh-nSo9pAh8irYAcV4MQCcfdHo"
+ nickname="Stefan"
+ subject="a workaround"
+ date="2015-02-10T05:00:01Z"
+ content="""
+Hacked together a small line that would convert my deletion to a annex drop, would be needed to be used in a cronjob or something like that:
+
+git st -s | grep \"^ D .*\" |  tee >(git checkout -- `grep -oE \"\S*$\"`) >(git annex drop `grep -oE \"\S*$\"`) 
+
+I guess it works only in indirect mode, maybe a git annex fsck before it would be good? (adding --force to the drop command would be good too I think)
+
+So either I rethink my usecase, maybe its ok that its a deletion or use something like that. I am not shure yet.
+I find it somethimes a bit hard to track unused files down and delete em (over several remotes).
+
+So I like the direct mode, and some programs still have problems using that files, as example du dont give you real size except you use -D of files, and even nautilus supports basicly dropping files, you cant drop on other repository with it.
+
+maybe I should also look how to easily remote git annex from some trees then I would be more willing to just play with that files around and go back to normal more painless, or I start with a smaller directory.
+
+the real fun I guess happens if you automate things like cloning of some paths to another remote as soon as its available I guess. I also dont like the interfaces to annex to much, 
+mv /mnt/share/file_x /path
+ is just simpler than 
+git annex move file_x --from=kodi --to=local-repos
+
+but thats maybe just practise :)
+"""]]
diff --git a/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__.mdwn b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__.mdwn
new file mode 100644
index 0000000000..d16131eeab
--- /dev/null
+++ b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__.mdwn
@@ -0,0 +1,14 @@
+I have an encrypted S3 remote with which I recently ran: 
+
+$> git annex move . --from cloud
+
+which moved all my files to the local repo. When I looked at my S3 bucket, I saw some files left. I then ran:
+
+$> git annex unused --from cloud
+
+to get all the unused data. I dropped each unused data from cloud so that now I think git annex believes it has nothing on the cloud remote.
+
+However there is still one file left on the bucket. Is this normal? (if not I'll create a bug report)
+More importantly, how can I decrypt this file so I can run git log -S'KEY' to figure out what it is (I want to make sure I haven't lost any data).
+
+To be clear, when I currently run 'git annex move . --from cloud' it moves nothing and when I run 'git annex unused --from cloud' it reports no unused data.
diff --git a/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_1_d4dc451892e7a6e230bf32adb7f3f9fa._comment b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_1_d4dc451892e7a6e230bf32adb7f3f9fa._comment
new file mode 100644
index 0000000000..c1eccfb0ff
--- /dev/null
+++ b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_1_d4dc451892e7a6e230bf32adb7f3f9fa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkiAsTXFXZbLE8iyy6yDtvz4MPFbzsk3c0"
+ nickname="Tony"
+ subject="comment 1"
+ date="2013-07-27T22:14:11Z"
+ content="""
+one more thing, I forgot to mention I use gpg keys for encryption on the remote and not a shared key.
+"""]]
diff --git a/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_2_79340bf3c0691073a9808c5ac2da0a3d._comment b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_2_79340bf3c0691073a9808c5ac2da0a3d._comment
new file mode 100644
index 0000000000..0cea29414e
--- /dev/null
+++ b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_2_79340bf3c0691073a9808c5ac2da0a3d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 2"
+ date="2013-07-27T22:30:50Z"
+ content="""
+I suppose this could happen if you have a tag or a branch or another repository that still refers to the file that's stored in S3. It would then not be found by `unused`.
+
+git-annex 4.20130709 has a nice new --all switch you can use: `git annex move --all --from cloud`
+
+If that doesn't move the file, nothing in the entire history of the git repository refers to it. The question then would be how did that file get there.
+
+It's by [[design|design/encryption]] not possible to get from the name of an encrypted file back to the key, unless you already know all the possible keys that the file could be. It's possible to decrypt the content if you have the gpg key and the git repository, but this space is a bit too small to explain every step in doing so, and I have some nice code that explains how in detail. ;)
+"""]]
diff --git a/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_3_6302fb6e5bb7cbddf2cfe74d98d32897._comment b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_3_6302fb6e5bb7cbddf2cfe74d98d32897._comment
new file mode 100644
index 0000000000..5c8d6356c8
--- /dev/null
+++ b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_3_6302fb6e5bb7cbddf2cfe74d98d32897._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkiAsTXFXZbLE8iyy6yDtvz4MPFbzsk3c0"
+ nickname="Tony"
+ subject="comment 3"
+ date="2013-07-27T22:47:14Z"
+ content="""
+thanks, running
+
+'git annex move --all --from cloud'
+
+grabbed the one remaining file from the bucket.
+"""]]
diff --git a/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_4_e3d95bc09c9fb21e8e9bbacc642aa60f._comment b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_4_e3d95bc09c9fb21e8e9bbacc642aa60f._comment
new file mode 100644
index 0000000000..493fa3ba17
--- /dev/null
+++ b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_4_e3d95bc09c9fb21e8e9bbacc642aa60f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 4"
+ date="2013-07-27T22:52:00Z"
+ content="""
+Great! And it should have also printed out the key it downloaded, if you're curious about looking where that file is used in your git repository.
+"""]]
diff --git a/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_5_f2f0a1c2fb0c6323707b11e2b06aa2db._comment b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_5_f2f0a1c2fb0c6323707b11e2b06aa2db._comment
new file mode 100644
index 0000000000..042704e529
--- /dev/null
+++ b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_5_f2f0a1c2fb0c6323707b11e2b06aa2db._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkiAsTXFXZbLE8iyy6yDtvz4MPFbzsk3c0"
+ nickname="Tony"
+ subject="comment 5"
+ date="2013-07-27T23:02:19Z"
+ content="""
+yeah it did print out the name of the file so I was able to verify that it was nothing I was worried about losing. thanks again :D
+"""]]
diff --git a/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_6_66fe80e634a8f13cce18fe68974ec67a._comment b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_6_66fe80e634a8f13cce18fe68974ec67a._comment
new file mode 100644
index 0000000000..8e79b4dc28
--- /dev/null
+++ b/doc/forum/how_to_decrypt_file_from_encrypted_special_remote__63__/comment_6_66fe80e634a8f13cce18fe68974ec67a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 6"
+ date="2013-07-27T23:06:38Z"
+ content="""
+I'm curious, why didn't `git annex unused --from cloud` show the file? Was it a tag/branch/etc still referring to it?
+"""]]
diff --git a/doc/forum/how_to_disaster_recovery.mdwn b/doc/forum/how_to_disaster_recovery.mdwn
new file mode 100644
index 0000000000..b4bbe123d9
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery.mdwn
@@ -0,0 +1,6 @@
+OS X: 10.11.6
+Annex: git-annex-6.20160619 (via brew)
+
+I'm [still strugling](http://git-annex.branchable.com/forum/git_annex_wants_to_repair_every_time_it__39__s_running/) with my annex repo over here. My problem is that for some reason git annex wants to repair my repo all the time when I'm starting the assistant and this (seemingly) never finishes, so I'm caught in an infinite loop in which no files get uploaded to my various remotes and nothing is downloaded either leaving me with all the data on my hard drive and nothing else. I would like to move on. How can I recover from this state? The daemon.log file doesn't show any information about what is happening during the repair and what might cause the failure. Is there another log file I could look at?
+
+Any help is appreciated at that point. Where should I look for more information? What should I do to change the behaviour? I want to solve this once and for all.
diff --git a/doc/forum/how_to_disaster_recovery/comment_10_be3cf3736166855012e10c2d251043e9._comment b/doc/forum/how_to_disaster_recovery/comment_10_be3cf3736166855012e10c2d251043e9._comment
new file mode 100644
index 0000000000..0326e2aaa1
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_10_be3cf3736166855012e10c2d251043e9._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2016-10-26T18:14:30Z"
+ content="""
+The first try at making git-annex ignore the fsck lines about duplicate
+entries didn't quite work; the second try landed 8 days ago and it's not
+been in a release yet so that's probably why you continue to see the
+problem.
+
+I don't see how deleting a special remote could lead to this. But we know
+that `git annex adjust --unlock` did, for another user.
+"""]]
diff --git a/doc/forum/how_to_disaster_recovery/comment_11_7fa36912ae21a66d3174fec35356d7ba._comment b/doc/forum/how_to_disaster_recovery/comment_11_7fa36912ae21a66d3174fec35356d7ba._comment
new file mode 100644
index 0000000000..ce3fd739a7
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_11_7fa36912ae21a66d3174fec35356d7ba._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 11"
+ date="2016-11-10T12:53:34Z"
+ content="""
+Two days ago I updated my annex through brew and the constant repairing seems to have stopped. There is one problem where the assistant shows up without any design, maybe an error with the homebrew formula? I had the too many open files error, but this seems to have disappeared. I reactivated synching for my home repo and am now letting the assistant run for a few days to see how it will work.
+"""]]
diff --git a/doc/forum/how_to_disaster_recovery/comment_12_f2e570dc60a6f16e8f696d94e253775f._comment b/doc/forum/how_to_disaster_recovery/comment_12_f2e570dc60a6f16e8f696d94e253775f._comment
new file mode 100644
index 0000000000..7c7da0ef47
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_12_f2e570dc60a6f16e8f696d94e253775f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 12"
+ date="2016-11-18T12:03:44Z"
+ content="""
+A recent update to annex via homebrew now reslolves the issue with the weird looking webapp.
+"""]]
diff --git a/doc/forum/how_to_disaster_recovery/comment_1_c8db90fd7af13b9605e152ea884b5241._comment b/doc/forum/how_to_disaster_recovery/comment_1_c8db90fd7af13b9605e152ea884b5241._comment
new file mode 100644
index 0000000000..4b14667d89
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_1_c8db90fd7af13b9605e152ea884b5241._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="jd.schroeder@0c8632a8f2bffdd4b0de05a0a3660f32acdfeeca"
+ nickname="jd.schroeder"
+ subject="comment 1"
+ date="2016-08-17T21:18:40Z"
+ content="""
+I don't use the assistant myself, so I may not be much help.
+
+Have you tried opening the terminal and running 
+
+    cd (your repository path)
+    git annex fsck
+
+it may yield more information about what's wrong.
+"""]]
diff --git a/doc/forum/how_to_disaster_recovery/comment_2_31cce673114eb9733e0f1c732c8f08e6._comment b/doc/forum/how_to_disaster_recovery/comment_2_31cce673114eb9733e0f1c732c8f08e6._comment
new file mode 100644
index 0000000000..cef32b77e9
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_2_31cce673114eb9733e0f1c732c8f08e6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="jd.schroeder@0c8632a8f2bffdd4b0de05a0a3660f32acdfeeca"
+ nickname="jd.schroeder"
+ subject="comment 2"
+ date="2016-08-17T21:23:34Z"
+ content="""
+You may want to also try
+
+    git fsck
+
+as well.
+"""]]
diff --git a/doc/forum/how_to_disaster_recovery/comment_3_52ad88121efa92d2c64bb2816884d66b._comment b/doc/forum/how_to_disaster_recovery/comment_3_52ad88121efa92d2c64bb2816884d66b._comment
new file mode 100644
index 0000000000..c069190359
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_3_52ad88121efa92d2c64bb2816884d66b._comment
@@ -0,0 +1,67 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 3"
+ date="2016-08-20T14:59:17Z"
+ content="""
+Thanks you so much for the suggestions! I tried running `git annex fsck` which yielded no errors and also ran `git fsck` which gave the following output:
+
+```
+error in tree 317eed096daa6d5efde4621ea57b698e17a44827: duplicateEntries: contains duplicate file entries
+error in tree 5d03ab540eb58fef3cba9466d0f404a2f487acbe: duplicateEntries: contains duplicate file entries
+error in tree 8001d121ff90053597e56ee6b9e4dd7d36e5ff25: duplicateEntries: contains duplicate file entries
+error in tree 9eea5dcfc9d0ab387165b91e11ecf6433d501e88: duplicateEntries: contains duplicate file entries
+error in tree c7c1bbde3d9479cbb44a5adbe763e9a90577fcbd: duplicateEntries: contains duplicate file entries
+error in tree f7544950f810acacb43647719ab77427dced34da: duplicateEntries: contains duplicate file entries
+Checking object directories: 100% (256/256), done.
+Checking connectivity: 403770, done.
+dangling blob 0a37708d72fe5cfeb0421372874557c45be3bed5
+dangling blob 7c6e000baabaa9a3b451bc4a058c8a1743598a4b
+dangling tree 8001d121ff90053597e56ee6b9e4dd7d36e5ff25
+dangling blob 7c76f1e9b6c2bc2189d11db526d4d615bfbda98a
+dangling blob f69212b0c58b43e5d935cfc39fdf6b1751cb5286
+dangling blob 3ddcb33a4a10db7a7c5f7baba730515758b47552
+dangling blob 9feae3d7a5786071826d0ec92289178c2fbbf915
+dangling blob 683f54561577372de1083e231e25eede7a978a2a
+dangling blob ffd8254bc8d78f4dfa180b7b3846bd9af7ad4e0a
+dangling blob 20e2b593b9d93cb3b9f39fd9e22dcbe3427cc369
+dangling blob 500da653dfcb37895e64be4959155e03d352fcbb
+dangling blob d61e26a6e41c547ad135ef6b58f64bd00ad0b31f
+dangling blob 38a9462b54afe85ee24e01b0c4d0fbd75eb5a240
+dangling blob 39b6962714399c604a65b350a21795e00e44b4f5
+dangling blob 71f3b6ca386913456a7de6a31b56729d6f8c36c9
+dangling blob dde4a7fea11398020fed287c4d31780909580e5d
+dangling blob 943b98bbee781a7c68befd37700ab8503a17503c
+dangling blob dc99f8b37db7bdc361c6d7973ab863674b2c59b3
+dangling blob 83b7388589b510388e4c08e2963ec10f21355e63
+dangling blob 63c1e85eedc424c297e5f36f6bc705982471fdce
+dangling blob 11d9d8a2c45f4d8b0479513e2f65352cfd0863d0
+dangling blob 9ce519f47e5a7dd8c923fcb55693a22d82e21779
+dangling blob c1ea698236b21eede67d01a8dd52c877962d1845
+dangling blob 24f6096646c9df777f2a81f40bbdef456f0e754d
+dangling blob a4fb09b357878b1cf31cd2151eb9d0fab2f0b452
+dangling blob ff0dda6cd8a6f882fdf81717519b1abb2c347a3e
+dangling blob a0500a7a450c487a3deeba9915c8f0a88f91b538
+dangling blob 31542a921878a024ec2dbe5815f58da6b6b33e2c
+dangling blob 6b6c6a8eb15fbab7f878396d0f084faa22c73382
+dangling tree 5d03ab540eb58fef3cba9466d0f404a2f487acbe
+dangling blob 87319bda4de4424f60e384fe5c3c14c2ce399d10
+dangling blob d8360b3ffc67ccb1478a797370cbb2112589e13a
+dangling blob 90e18b4beb5e5aedefdab98b57ccf636fb77e046
+dangling blob 06e24bc228ae12504a2bcbe9d3d24f263ba0a209
+dangling blob d2eb8b104d2c002ded4ec76e440dee88f5174a39
+dangling blob e7addc9b07f4938d5871eb67278f64c1d15b2cb4
+dangling blob ff02ddf430604f4a60e3bc7b70804ff1f539dedb
+dangling blob 8c04bdb8cef6265ccde6b7491a57f3869c7d6b23
+dangling blob 8d83dd50a078efda7b60de1900736fbd77a2c5a6
+dangling tree 9eea5dcfc9d0ab387165b91e11ecf6433d501e88
+dangling blob 2011ce2b12529ec512b5c6b75bb6acdf3cbc5e82
+dangling blob 8d6d6e3ea481ddc9eb697c7e4c61479b212157c6
+dangling blob 68f62e8d6902b0de28c6f28899be73c6864d58e2
+dangling blob 97f77e273d92ebc908cfcc3b81dbbc28d10ae090
+dangling blob be24efa8af600f0ac331872e0769b18aa36a17c8
+dangling blob cd257f99eef789d2ce8f7f78d2e80c99311bf8b5
+dangling blob 4e973f9d9b9900d01f2d1f1815609e80b1fcf4a5
+```
+
+I'm now running git annex repair through the command line and hoping for the best. I'm sure this will run for a while. The output so far is just `Running git fsck ...` but I can see it's doing something since the terminal application in osx shows what commands it's currently running in the header of the window itself. I'm hoping this repair will finnish until tomorrow morning because I have a flight coming up at 8. Let's see.
+"""]]
diff --git a/doc/forum/how_to_disaster_recovery/comment_4_444579d0dac2ca14e6b1cbadcca5fcf3._comment b/doc/forum/how_to_disaster_recovery/comment_4_444579d0dac2ca14e6b1cbadcca5fcf3._comment
new file mode 100644
index 0000000000..7ded573bf6
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_4_444579d0dac2ca14e6b1cbadcca5fcf3._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="jd.schroeder@0c8632a8f2bffdd4b0de05a0a3660f32acdfeeca"
+ nickname="jd.schroeder"
+ subject="comment 4"
+ date="2016-08-20T16:17:07Z"
+ content="""
+Unfortunately, I'm not familiar with the errors that git fsck is giving you, so I should defer to someone who knows more. I don't want to tell you something that makes the problem worse :)
+
+If repairing doesn't work, one other thing you could try is cloning the repository that's giving you trouble, and using git annex to move the data into the new clone. This won't modify your original (defective) repository.
+
+    git clone /path/to/repository /path/to/newClone
+    cd /path/to/newClone
+    git annex get --all
+
+If you have files in your original repository that the assistant hasn't committed yet, they won't be in the new clone. So you should look around in /path/to/newClone to see if everything is there. You can run
+
+    cd /path/to/repository
+    git status
+
+to see any files that have not yet been committed in the defective repository, and copy them over manually.
+
+Good luck! Hope you get it working.
+
+"""]]
diff --git a/doc/forum/how_to_disaster_recovery/comment_5_9b9403a80c5b0a1a441dfb94feece37d._comment b/doc/forum/how_to_disaster_recovery/comment_5_9b9403a80c5b0a1a441dfb94feece37d._comment
new file mode 100644
index 0000000000..52f1d1e454
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_5_9b9403a80c5b0a1a441dfb94feece37d._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-09-05T20:02:39Z"
+ content="""
+Very interesting git fsck output!
+
+It seems like your git repository has somehow gotten a tree object in it
+which contains two files with the same name.
+
+While git's data structures allow this, it's pretty nonsensical, and it's
+not something that would normally ever happen. It would be interesting to
+take a look and see what commits use those tree objects, and where those
+strange trees came from.
+
+git-annex in turn is seeing that tree object's sha in the fsck output and
+assumes fsck means that the data for that object is broken or missing.
+So, I suppose what I'll do is make it skip over lines containing
+`duplicateEntries`, and then it won't try to repair this repository.
+"""]]
diff --git a/doc/forum/how_to_disaster_recovery/comment_6_e8ec7b1fbbb81d61d06a7def61b06354._comment b/doc/forum/how_to_disaster_recovery/comment_6_e8ec7b1fbbb81d61d06a7def61b06354._comment
new file mode 100644
index 0000000000..425558b254
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_6_e8ec7b1fbbb81d61d06a7def61b06354._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2016-10-18T15:27:05Z"
+ content="""
+Another user reported the same problem. Their repo indeed had a tree object
+that contained two items with the same name. In this case, two trees,
+with different contents.
+
+	040000 tree cd854aba649cee8855ec72579f4c98100471f7cf    Dokument
+	040000 tree 1ae499997746c8e976cf02edc2276532978dafc5    Dokument
+
+This user had been using adjusted branches, which would be my lead suspect.
+
+Original reporter, did you use git-annex's adjusted branches feature.
+"""]]
diff --git a/doc/forum/how_to_disaster_recovery/comment_7_7e08eb18e965f47782a39d0426b75b93._comment b/doc/forum/how_to_disaster_recovery/comment_7_7e08eb18e965f47782a39d0426b75b93._comment
new file mode 100644
index 0000000000..7053bb282b
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_7_7e08eb18e965f47782a39d0426b75b93._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 7"
+ date="2016-10-18T17:37:38Z"
+ content="""
+Not that I know of. I tried a whole bunch of things, like deleting remotes, killing processes trying to switch between repo versions, modes, playing around in config files etc. etc. Not all of them were smart ideas, I admit. At some point it worked and if I remember correctly I tried to delete a branch and then the problems started. But adjusted branches seems to me like a too advanced feature to use.
+
+Btw.: Skipping over these entries doesn't help for me. It still tries to repair the repo (which takes maybe 4 hours, including having to initiate a temporary repo).
+"""]]
diff --git a/doc/forum/how_to_disaster_recovery/comment_8_78720819bea58f30146451dd953f10a5._comment b/doc/forum/how_to_disaster_recovery/comment_8_78720819bea58f30146451dd953f10a5._comment
new file mode 100644
index 0000000000..1eb3694668
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_8_78720819bea58f30146451dd953f10a5._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 8"
+ date="2016-10-18T17:38:53Z"
+ content="""
+The \"at some point\" portion of my previous message refers to a state before the problems started, not after or in between. Sorry for being unclear.
+"""]]
diff --git a/doc/forum/how_to_disaster_recovery/comment_9_b16c74c0add6d15b75163859a752d207._comment b/doc/forum/how_to_disaster_recovery/comment_9_b16c74c0add6d15b75163859a752d207._comment
new file mode 100644
index 0000000000..b6ee528a21
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_9_b16c74c0add6d15b75163859a752d207._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 9"
+ date="2016-10-25T18:02:56Z"
+ content="""
+> […] if I remember correctly I tried to delete a branch and then the problems started […]
+
+This is not correct. I tried to delete a special remote.
+"""]]
diff --git a/doc/forum/how_to_edit_the_git-annex_branch__63__.mdwn b/doc/forum/how_to_edit_the_git-annex_branch__63__.mdwn
new file mode 100644
index 0000000000..a37391001a
--- /dev/null
+++ b/doc/forum/how_to_edit_the_git-annex_branch__63__.mdwn
@@ -0,0 +1,9 @@
+as a followup to [[forum/remote-specific_meta-data/]], now i'm thinking of injecting data in the `git-annex` branch. i'm still a little hesitant because [[forum/optimising_lookupkey/]] mentions that i need to "delete or update `.git/annex/index`" when doing so. yet I also saw in the source code there is a `.git/annex/index.lock` file that is being used to avoid concurrent access to that file - is that something that should be watched out for? how do I manage that lockfile? is it mandatory to stage files into the index at first?
+
+maybe i'm just not familiar enough with how git operates internally myself. i've reviewed this section of the progit book again: http://git-scm.com/book/en/v2/Git-Internals-Git-Objects - and i feel i have again some handle on how to do those things, but it seems like a major hurdle to go through just to change a single setting in one git-annex metadata file... wouldn't `enableremote` be sufficient here? I figured to append custom fields to a remote, i could do:
+
+    git annex enableremote myremoteuuid "$(git cat-file -p git-annex:remote.log | grep myremoteuuid) extratag=true"
+
+Would that work at all? Should i operate directly on the git-annex branch myself instead?
+
+Thanks! --[[anarcat]]
diff --git a/doc/forum/how_to_edit_the_git-annex_branch__63__/comment_1_fa1936401d1abe1a28dc88968528e186._comment b/doc/forum/how_to_edit_the_git-annex_branch__63__/comment_1_fa1936401d1abe1a28dc88968528e186._comment
new file mode 100644
index 0000000000..6200e3792e
--- /dev/null
+++ b/doc/forum/how_to_edit_the_git-annex_branch__63__/comment_1_fa1936401d1abe1a28dc88968528e186._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-31T18:26:06Z"
+ content="""
+Yes, you can pass any (unused) fields you like to git-annex enableremote.
+"""]]
diff --git a/doc/forum/how_to_force_read-only_in_enableremote__63__.mdwn b/doc/forum/how_to_force_read-only_in_enableremote__63__.mdwn
new file mode 100644
index 0000000000..ff90fbbcdc
--- /dev/null
+++ b/doc/forum/how_to_force_read-only_in_enableremote__63__.mdwn
@@ -0,0 +1,3 @@
+I see that `enableremote` changes the source remote to log the presence of a new annex (the annex where `enableremote` was called). I have tested with a gcrypt remote and I see that a new commit appears in the git-annex branch of the source remote after `enableremote` was called. Since I have cloned the annex just for testing and will delete it afterwards, I would like to leave the original remote untouched.
+
+Is there a way to enable the remote read-only?
diff --git a/doc/forum/how_to_force_read-only_in_enableremote__63__/comment_1_a1206c8517f467d9a584ba89ef0e101a._comment b/doc/forum/how_to_force_read-only_in_enableremote__63__/comment_1_a1206c8517f467d9a584ba89ef0e101a._comment
new file mode 100644
index 0000000000..6dd90c28ba
--- /dev/null
+++ b/doc/forum/how_to_force_read-only_in_enableremote__63__/comment_1_a1206c8517f467d9a584ba89ef0e101a._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-10T18:13:28Z"
+ content="""
+git-annex auto-init the local repository whenever it sees it's not
+enabled and there is a git-annex branch (or origin/git-annex etc).
+This is what adds the uuid of the local repository to remote.log.
+So, it's not specific to `enableremote`; many git-annex commands
+will do the same thing. And git-annex needs to allocate a uuid for the
+local repo in order to work.
+
+One way to deal with it is to use `git annex reinit` so it uses
+some already existing uuid. Although then getting files etc will
+update the records using that uuid. Might be ok if you have one
+uuid, perhaps one you've marked dead, that you use for this purpose
+and don't care what's recorded for that uuid.
+
+Or, it might be better to let git-annex auto-init a new uuid, 
+and just configure this test repo to not push changes out to
+elsewhere. For example, `git config remote.origin.annex-readonly true`
+will make `git annex sync` avoid pushing back to the origin remote.
+"""]]
diff --git a/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__.mdwn b/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__.mdwn
new file mode 100644
index 0000000000..e7de592100
--- /dev/null
+++ b/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__.mdwn
@@ -0,0 +1,5 @@
+I fear that while using git annex I will at some point accidentally `git add` some small files and not notice it until the only way to fix the problem is to rewrite history. What would be the best way to prevent myself from ever `git add`-ing a file into my annex repository instead of `git annex add`-ing it?
+
+And secondly, how can I best search in my git annex repository whether I already did this mistake in the past or not? Currently I'm using this which returns everything that's not a symlink or a git submodule:
+
+    git ls-files -s | awk ' $1 != 120000 && $1 != 160000 { print $4 }'
diff --git a/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_1_440dcd19ea2512f968858b780c2a2913._comment b/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_1_440dcd19ea2512f968858b780c2a2913._comment
new file mode 100644
index 0000000000..166d549fd8
--- /dev/null
+++ b/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_1_440dcd19ea2512f968858b780c2a2913._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="178.79.137.64"
+ subject="comment 1"
+ date="2014-06-25T10:35:07Z"
+ content="""
+I'm not sure if you can prevent 'git add' but you can at least prevent it getting commited with the pre-commit hook. Mine is this:
+
+    #!/bin/sh
+    
+    FILES=$(find -name \".git\" -prune -o -type f -not -name \".gitignore\" -print);
+    FILE_COUNT=$(echo -n \"$FILES\" | wc -l)
+    
+    if [ $FILE_COUNT -gt 0 ]; then
+            echo \"$FILE_COUNT non-symlink files found.\"
+            echo \"$FILES\"
+            exit 1
+    fi
+    
+    # automatically configured by git-annex
+    git annex pre-commit .
+"""]]
diff --git a/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_2_e9b70386774996a3d0446faaa3219120._comment b/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_2_e9b70386774996a3d0446faaa3219120._comment
new file mode 100644
index 0000000000..bc8acf020d
--- /dev/null
+++ b/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_2_e9b70386774996a3d0446faaa3219120._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="josch"
+ ip="2001:638:709:5:2ad2:44ff:fe4b:56aa"
+ subject="comment 2"
+ date="2014-06-27T04:50:03Z"
+ content="""
+Xyem, your method does not work well because it finds all regular files in the whole annex directory and does not only check for those that are to be committed.
+"""]]
diff --git a/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_3_3dbd76accad2df2fff14b55452c828ef._comment b/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_3_3dbd76accad2df2fff14b55452c828ef._comment
new file mode 100644
index 0000000000..d8f681a1bf
--- /dev/null
+++ b/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_3_3dbd76accad2df2fff14b55452c828ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="178.79.137.64"
+ subject="comment 3"
+ date="2014-06-27T12:02:08Z"
+ content="""
+That is intentional. In my use case, there should never be any regular files in this particular annex at all. If there are, it means I have missed something! :)
+"""]]
diff --git a/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_4_bfb4758fdb2a4afafd9c4d45de5c5c6b._comment b/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_4_bfb4758fdb2a4afafd9c4d45de5c5c6b._comment
new file mode 100644
index 0000000000..de2a279a72
--- /dev/null
+++ b/doc/forum/how_to_prevent_accidentally_running___96__git_add__96____63__/comment_4_bfb4758fdb2a4afafd9c4d45de5c5c6b._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnWvnTWY6LrcPB4BzYEBn5mRTpNhg5EtEg"
+ nickname="Bence"
+ subject="comment 4"
+ date="2015-01-15T16:15:21Z"
+ content="""
+Based on the above, I'm using this script in the `pre-commit` hook.
+
+It gets the staged files and checks if they are links or not. If a file being committed is not a link (maybe it was added with `git add filename` ???), the script aborts the commit.
+
+    #!/bin/sh
+    
+    # Don't allow files to be added to the normal repo.
+    stagedfiles=$(git diff --cached --name-only);
+    echo \"$stagedfiles\" | while IFS= read -r file; do
+    	if [ ! -L \"$file\" ]; then
+    		echo \"[Error] The file \\"$file\\" should not be added to the repo.\";
+    		echo \"#Remove from the index and add with git-annex:\";
+    		echo \"\$ git rm --cached \\"$file\\" && git annex add \\"$file\\"\";
+    		exit 1;
+    	#else
+    	#	echo \"OK : $file\";
+    	fi;
+    done;
+    
+    # automatically configured by git-annex
+    git annex pre-commit .
+"""]]
diff --git a/doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents.mdwn b/doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents.mdwn
new file mode 100644
index 0000000000..4f24117f68
--- /dev/null
+++ b/doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents.mdwn
@@ -0,0 +1,7 @@
+It would be nice to have a way to drop files without leaving broken symlinks around, at least while in direct mode.
+
+Here is my user case. I have a collection of music CDs ripped in FLAC formats. At the same time I convert all these files to MP3 files to that I can use them in various other devices and to save space.
+
+The problem is that if I `git annex drop` the FLAC files once they are converted and copied, they leave broken symlinks around; this result in various annoying error messages in almost all the music playback I tried. At the same time, if I `rm` or `git rm` these symlinks, the content of these files will be removed also from the remotes as they are signalled as no longer wanted.
+
+Couldn't git-annex keep a separate index of files that have been removed but are meant to be kept?
diff --git a/doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents/comment_1_cba76311e146dabb8ffc789bf4c8b714._comment b/doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents/comment_1_cba76311e146dabb8ffc789bf4c8b714._comment
new file mode 100644
index 0000000000..c490c826a8
--- /dev/null
+++ b/doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents/comment_1_cba76311e146dabb8ffc789bf4c8b714._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ ip="2001:1418:100:262::2"
+ subject="Maybe using branches?"
+ date="2013-05-16T10:22:48Z"
+ content="""
+A suggestion from #git-annex:
+
+> &lt;mhameed&gt; i think others are already doing this, using branches, but not sure if we have a writeup/tutorial of it
+>
+> &lt;mhameed&gt; gioele:  instead of working on master branch, switch to laptop branch, git rm the files that are not wanted and commit
+>
+> &lt;gioele&gt; mhameed: I'm lazy, I'd like git-annex to do that for me :)
+"""]]
diff --git a/doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents/comment_2_8d99c50fc1347367ccc0714e8d1af385._comment b/doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents/comment_2_8d99c50fc1347367ccc0714e8d1af385._comment
new file mode 100644
index 0000000000..f0b20f1a4a
--- /dev/null
+++ b/doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents/comment_2_8d99c50fc1347367ccc0714e8d1af385._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-05-19T20:43:43Z"
+ content="""
+The original poster seems to have a misunderstanding of what git-annex does with the content of files. Deleting a file does not remove the content of the file. You can always use git to check out a previous version of a file, and the content from the annex will still be there (or you can `git annex get` it to get it from whereever git-annex stored the content).
+
+The only exception to this rule is is you, manually, chose to run `git annex unused` and then `git annex dropunused`. That can delete the contents of files, when no branch or tag refers to them. As long as some branch refers to the content of the files, even if it's not the currently checked out branch, the file content is retained.
+
+So a branch *is* the \"index of files that have been removed but are wanted to be kept\".
+
+For example, you could do:
+
+[[!format sh \"\"\"
+git checkout -b keepflacs
+
+cdrom-rip-command
+git annex add *.flac
+git commit -m \"ripped a cd\"
+flac-convert-command
+git annex add *.mp3
+git commit -m \"converted to mp3\"
+
+git checkout master
+git merge keepflacs
+git rm *.flac
+git commit -m \"removed flac files from this branch. They are still available in the keepflacs branch\"
+\"\"\"]]
+
+As long as you always switch to the keepflacs branch to add flac files, and never merge the master branch into keepflacs,
+but only merge keepflacs into master, keepflacs will have every flac file you have ripped. And so git-annex will retain those files
+even when you `git annex unused; git-annex dropunused`.
+
+Or, just make a promise to yourself that you'll never run `git-annex unused`, similarly to how you'd probably never run `rm -rf .git/objects/$rand`, and you don't need the branches; like git, git-annex will retain all data that has ever been checked into it.
+
+(The branches are still a good idea. For one thing, they let you run `git annex fsck` and other repository maintenance commands with the keepflacs branch checked out.)
+
+I am going to move this thread to the [[forum]], because it's not really a TODO item, but is something others may want to read.
+"""]]
diff --git a/doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents/comment_3_a7a9c55c2ad448179dff5d5b69976c7d._comment b/doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents/comment_3_a7a9c55c2ad448179dff5d5b69976c7d._comment
new file mode 100644
index 0000000000..39ed8306c0
--- /dev/null
+++ b/doc/forum/how_to_remove_files_and_symlinks_but_keep_historical_file_contents/comment_3_a7a9c55c2ad448179dff5d5b69976c7d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-05-20T17:46:08Z"
+ content="""
+Erm, I missed that you want to use direct mode. All this fun with git won't really work in direct mode, and indeed direct mode is not able to guarantee that old versions of modified files are retained.
+
+Direct mode is nice for some applications involving syncing and less than ideal devices, but not for this.
+"""]]
diff --git a/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit.mdwn b/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit.mdwn
new file mode 100644
index 0000000000..960f563ced
--- /dev/null
+++ b/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit.mdwn
@@ -0,0 +1,9 @@
+Been using Unison for a while to sync a folder at three different computers (can be on or off simultanously). However, I've for different reasons been looking for a different solution. Here comes git annex.e
+
+I started out with one computer, generated a new repo locally and at the server (a synology nas) with the assistant. Then i put all my files into the local directory and the files uploaded to the server. All good. I put the local computer in client mode and the server in backup mode. Then i configured a second computer with an empty repo folder, was asked to join repos, did that. Also put this computer in client mode and the server in backup. After a while all the files was located in the second computers repo directory. Yes, I was confident this was the way to go. 
+
+Howewer, doing the same with my laptop was not successful at all. After similar setup as above it only downloaded about 5% of the data. Bummer. While I tried to study the logs I thought I should check the second computers repo. That was modified and a lot of files where gone. Wow...of course I have backup, but I was hoping for a proper and consistent operation.
+
+So what causes this? Should I not put the server in backup mode? Anyone have an idea?
+
+Other thoughts?
diff --git a/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_1_a0551431a57ccab2463f2a6d43553337._comment b/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_1_a0551431a57ccab2463f2a6d43553337._comment
new file mode 100644
index 0000000000..99fa06512a
--- /dev/null
+++ b/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_1_a0551431a57ccab2463f2a6d43553337._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawncVeolylM8VoRbWhIYDlfGhIP69-aNXm4"
+ nickname="Espen"
+ subject="comment 1"
+ date="2014-10-10T07:14:36Z"
+ content="""
+Okey, came in to the office today to check the first computer I set up. It lacks all the files except the ones located on the third computer. So all sites are synced (only a lot of files are dropped). Seems something happened while the third computer was set up that caused just a few files to sync from the backup server and then git somehow thought that was it and then synced computer one, two and the server according to files present on computer three (obviously way to few files). This is slightly worrisome and I wonder what caused this. I'll inspect the log files for the transfer on computer three when I get home.
+
+Can anyone of you confirm that having this setup should not cause problems:
+
+computer 1 - client mode
+computer 2 - client mode
+computer 3 - client mode
+backup unit/nas - backup mode
+"""]]
diff --git a/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_2_e96e8cf6e08e3a21bfcefbc202e78fe2._comment b/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_2_e96e8cf6e08e3a21bfcefbc202e78fe2._comment
new file mode 100644
index 0000000000..fa0f491202
--- /dev/null
+++ b/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_2_e96e8cf6e08e3a21bfcefbc202e78fe2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlM_DRhi_5pJrTA0HbApHR25iAgy-NBXTY"
+ nickname="Tor Arne"
+ subject="comment 2"
+ date="2014-10-14T22:13:44Z"
+ content="""
+Did you figure this one out?
+"""]]
diff --git a/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_3_2ad4c1a4bfe00c22444ab878c84a8830._comment b/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_3_2ad4c1a4bfe00c22444ab878c84a8830._comment
new file mode 100644
index 0000000000..8c42c43fd5
--- /dev/null
+++ b/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_3_2ad4c1a4bfe00c22444ab878c84a8830._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawncVeolylM8VoRbWhIYDlfGhIP69-aNXm4"
+ nickname="Espen"
+ subject="comment 3"
+ date="2014-10-15T17:32:10Z"
+ content="""
+Finally had some time today to lock at the logs. However, I started from scratch. Created a local repo with the assistant, transferred some real files into the local repo dir (not .git of course). Waiting until everything was added etc. Then I created the remote server repo and it immediately started to transfer files from the local repo to the remote. Then I was slightly surprised when I got back home and saw this in the logfile:
+
+----- cut -----
+
+somefile
+
+         32,768   1%    0.00kB/s    0:00:00  To ssh://someserverrepodir
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      annex/direct/master -> synced/master
+error: Ref refs/heads/synced/git-annex is at 112bb35566a0ee9434fb74524cdced45792bf8ed but expected 0000000000000000000000000000000000000000
+error: Ref refs/heads/synced/master is at d593f3c3a5090009789154bd60c3390d9a1b90d6 but expected 0000000000000000000000000000000000000000
+remote: error: failed to lock refs/heads/synced/git-annex        
+remote: error: failed to lock refs/heads/synced/master        
+To ssh://someserverrepodir
+ ! [remote rejected] git-annex -> synced/git-annex (failed to lock)
+ ! [remote rejected] annex/direct/master -> synced/master (failed to lock)
+error: failed to push some refs to 'ssh://someserverrepodir'
+
+      1,966,080  96%    1.73MB/s    0:00:00  
+      2,034,254 100%    1.79MB/s    0:00:01 (xfr#1, to-chk=0/1)
+fatal: 'someserverrepodescription' does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+fatal: 'someserverrepodescription' does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+fatal: 'someserverrepodescription' does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+[2014-10-13 21:58:05 CEST] Transferrer: Uploaded somefile
+
+----- cut -----
+
+This was a total surprise to me. If this was the stuff that made the previous setup fail, I don not know, but I will try to track down this error first. I would be quite surprised if it indeed was a permission issue. Also visible is an upload session for one of the files...that seems to go on fine and is probably not related to the error at all. This was the only error printed once during the entire transfer/sync process. Thought the first thing I would check was the size and number of files in the local and remote directory, but I'm not really sure how to do this with all the git stuff around on the remote. Typically \"git ls-files | wc -l\" or similar gets me going on the local repo. How would I do this on the remote (in backup mode if that counts)?
+"""]]
diff --git a/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_4_44639388349a9ea5eabda9ebf79817b3._comment b/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_4_44639388349a9ea5eabda9ebf79817b3._comment
new file mode 100644
index 0000000000..c97438d8ab
--- /dev/null
+++ b/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_4_44639388349a9ea5eabda9ebf79817b3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawncVeolylM8VoRbWhIYDlfGhIP69-aNXm4"
+ nickname="Espen"
+ subject="comment 4"
+ date="2014-10-15T17:34:52Z"
+ content="""
+Sorry, forgot to format the text and the typo. Can I edit my own comments?
+"""]]
diff --git a/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_5_339123ab87b69b11d6e999ad6eaf6df5._comment b/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_5_339123ab87b69b11d6e999ad6eaf6df5._comment
new file mode 100644
index 0000000000..58bed56e57
--- /dev/null
+++ b/doc/forum/how_to_set_up_syncing_for_multiple_computer_and_a_centralized_backup_unit/comment_5_339123ab87b69b11d6e999ad6eaf6df5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawncVeolylM8VoRbWhIYDlfGhIP69-aNXm4"
+ nickname="Espen"
+ subject="comment 5"
+ date="2014-10-15T17:44:55Z"
+ content="""
+Did a quick \"du -h\" on both directories. Local is 27 and remote is 23.7 GB, so some data is obviously missing on the remote. Also, how do I increase either the permitted size of one log file, or the number of log files stored? Seems the logs where rotated over the whole allowed log batch and size before the job was done during the night, so difficult to tell if there were more errors.
+"""]]
diff --git a/doc/forum/how_to_speed_up_metadata_view_genration.mdwn b/doc/forum/how_to_speed_up_metadata_view_genration.mdwn
new file mode 100644
index 0000000000..dc2edaf596
--- /dev/null
+++ b/doc/forum/how_to_speed_up_metadata_view_genration.mdwn
@@ -0,0 +1 @@
+I personally really see the value in utilizing the [metadata driven views](https://git-annex.branchable.com/tips/metadata_driven_views/), like for organizing which of my podcasts i have and have not listened to, or for tagging images and being able to filter off those tags.  However, my annex is very large and when i try to generate these views it takes several minutes just to generate a single view, which in most cases i come to find out that I typed the name of an included directory wrong and need to regenerate a different view.  Is there anyway for one to limit what files/directories the view generator scans through?  like if i wanted to show all the tags i have associated with my podcasts, then to limit that search to just my podcasts directory
diff --git a/doc/forum/how_to_speed_up_metadata_view_genration/comment_1_56044eef4cee8940a9bd5f66d2b1cd8f._comment b/doc/forum/how_to_speed_up_metadata_view_genration/comment_1_56044eef4cee8940a9bd5f66d2b1cd8f._comment
new file mode 100644
index 0000000000..e55b1fcb41
--- /dev/null
+++ b/doc/forum/how_to_speed_up_metadata_view_genration/comment_1_56044eef4cee8940a9bd5f66d2b1cd8f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-07-12T13:19:53Z"
+ content="""
+It's possible to limit a view to a subdirectory, by
+using something like `git annex view 'foo/=*'`
+
+It might still take a while to generate that view, but
+once you're in that view, you can use `git annex vfilter`
+to further filter to tags, and it will only look at the files from the
+subdirectory, so will run faster. And `git annex vpop` will
+quickly undo a view change.
+"""]]
diff --git a/doc/forum/howto_to_link_to_existing_direct_mode_git-annexes.mdwn b/doc/forum/howto_to_link_to_existing_direct_mode_git-annexes.mdwn
new file mode 100644
index 0000000000..cab2ec0c6b
--- /dev/null
+++ b/doc/forum/howto_to_link_to_existing_direct_mode_git-annexes.mdwn
@@ -0,0 +1,5 @@
+I have created two git-annexes (one on my laptop and one on my work pc) The are using nearly the same files with some files existing only on the pc but not on the laptop as they are too large for the laptop. How do I get the two into sync. I found the manual in the tips section but that will create normal git-annexes with all files linked only. However, I would like to have my exiting file structure unchanged (the way the assistant does it by default)
+
+any ideas?
+
+Gregor
diff --git a/doc/forum/howto_to_link_to_existing_direct_mode_git-annexes/comment_1_7bd0edaf2352293678f0942aaa885d13._comment b/doc/forum/howto_to_link_to_existing_direct_mode_git-annexes/comment_1_7bd0edaf2352293678f0942aaa885d13._comment
new file mode 100644
index 0000000000..4b3b095c33
--- /dev/null
+++ b/doc/forum/howto_to_link_to_existing_direct_mode_git-annexes/comment_1_7bd0edaf2352293678f0942aaa885d13._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="71.80.94.56"
+ subject="comment 1"
+ date="2014-02-07T19:11:00Z"
+ content="""
+The webapp will help you do this, go to Add Another Repository -> Share With Your Other Devices. 
+"""]]
diff --git a/doc/forum/howto_update_feed.mdwn b/doc/forum/howto_update_feed.mdwn
new file mode 100644
index 0000000000..5323e92eb3
--- /dev/null
+++ b/doc/forum/howto_update_feed.mdwn
@@ -0,0 +1,14 @@
+I am using the importfeed [1] functionality.
+
+How am I supposed to update the feed/feeds?
+
+I understand that running
+
+    cd annex; git annex importfeed http://url/to/podcast
+
+a second time will 'do the right thing'.  But that is cumbersome as I have to know the url again.  Is there sth like git annex updatefeeds?
+
+
+
+
+[1] http://joeyh.name/blog/entry/git-annex_as_a_podcatcher/
diff --git a/doc/forum/howto_update_feed/comment_1_bec356619f370a618f19a187d09d2e35._comment b/doc/forum/howto_update_feed/comment_1_bec356619f370a618f19a187d09d2e35._comment
new file mode 100644
index 0000000000..fa87e3494d
--- /dev/null
+++ b/doc/forum/howto_update_feed/comment_1_bec356619f370a618f19a187d09d2e35._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 1"
+ date="2013-08-26T18:11:07Z"
+ content="""
+I have purposefully kept a list of feeds out of git-annex. I handle this by having a `feeds` file, which I check into git. Then a cron job runs: `xargs git-annex importfeed < feeds`
+"""]]
diff --git a/doc/forum/howto_update_feed/comment_2_84dfb80ba3db8d41164eb97022becae3._comment b/doc/forum/howto_update_feed/comment_2_84dfb80ba3db8d41164eb97022becae3._comment
new file mode 100644
index 0000000000..4f28d8f4ef
--- /dev/null
+++ b/doc/forum/howto_update_feed/comment_2_84dfb80ba3db8d41164eb97022becae3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ringprince"
+ ip="134.76.140.110"
+ subject="comment 2"
+ date="2013-08-26T19:04:21Z"
+ content="""
+Thanks for that.  I'll do the same ;-)
+"""]]
diff --git a/doc/forum/howto_update_feed/comment_3_20166db298c10074e062aecad59ffd71._comment b/doc/forum/howto_update_feed/comment_3_20166db298c10074e062aecad59ffd71._comment
new file mode 100644
index 0000000000..73f48ac9b0
--- /dev/null
+++ b/doc/forum/howto_update_feed/comment_3_20166db298c10074e062aecad59ffd71._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://a-or-b.myopenid.com/"
+ ip="203.45.2.230"
+ subject="comment 3"
+ date="2013-08-28T01:32:38Z"
+ content="""
+One thing I do slightly differently is put comments in my ```feeds``` file so I know what feed is what...
+
+    # NPR - Wait Wait... Don't Tell Me!
+    http://www.npr.org/rss/podcast.php?id=35
+    # NPR - Car Talk
+    http://www.npr.org/rss/podcast.php?id=510208
+
+
+Then I use 
+
+    grep -v '^#' feeds| xargs git-annex importfeed --relaxed
+
+I reckon that makes maintenance easier.
+"""]]
diff --git a/doc/forum/howto_update_feed/comment_4_f040e31b763fc9a7aa092442b4d6b8e8._comment b/doc/forum/howto_update_feed/comment_4_f040e31b763fc9a7aa092442b4d6b8e8._comment
new file mode 100644
index 0000000000..f7a35d1b65
--- /dev/null
+++ b/doc/forum/howto_update_feed/comment_4_f040e31b763fc9a7aa092442b4d6b8e8._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="arand"
+ ip="130.243.226.21"
+ subject="comment 4"
+ date="2013-09-01T18:06:51Z"
+ content="""
+Yet another solution, keeping it all in one script
+
+    #!/bin/sh
+    
+    while IFS= read line
+    do
+            test -n \"${line%%#*}\" && echo git annex importfeed --relaxed \"$line\"
+    done <<EOF
+    # FooCast - Alice & Bob
+    http://feeds.foo.com/foocast
+    # FrobCast
+    http://meep.moop.com/feed
+    EOF
+"""]]
diff --git a/doc/forum/huge_text_files___40__not_binary__41___-_compress.mdwn b/doc/forum/huge_text_files___40__not_binary__41___-_compress.mdwn
new file mode 100644
index 0000000000..76772121a4
--- /dev/null
+++ b/doc/forum/huge_text_files___40__not_binary__41___-_compress.mdwn
@@ -0,0 +1,4 @@
+Hi,
+we are using git in a research lab to store both code and text log generated by this code. Until now, we are using standard git and then it compresses the text files when they are committed (our text log files have +- 100MB each one). Recently, our institutional git server started to support git-annex and then we are moving from a git only solution to a git + git annex case. Git annex is working like a charm and the operations in our repository are faster after the migration to git annex. However, the files stored with git annex (.git/annex) are not compressed. I understand that git annex was designed to store binary files and then, the compression does not make sense, but I would like to know if it is possible to enable the compression when pushing the files with git-annex?
+
+Thank you for your attention!
diff --git a/doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_1_bd0925e056c275c52b59f947e23afe86._comment b/doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_1_bd0925e056c275c52b59f947e23afe86._comment
new file mode 100644
index 0000000000..81288307de
--- /dev/null
+++ b/doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_1_bd0925e056c275c52b59f947e23afe86._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-28T17:21:54Z"
+ content="""
+The difficulty with compressing annexed files is that they have to
+be available on disk in uncompressed form in order for the work tree to
+point to the content of the files. Notice that, even though git does
+compress .git/objects, the checked-out files in the working tree are not
+themselves compressed.
+
+git-annex does support compressing files that are stored on special
+remotes. Simply enabling encryption when initializing a special remote
+will also compress the data stored in it. A couple of special remotes like
+bup also compress content natively.
+
+Using a filesystem that supports compression is the only way I know of to
+transparently compress files located in the working tree.
+"""]]
diff --git a/doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_2_44eb5f14dbf3c5061afeb847958f27fe._comment b/doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_2_44eb5f14dbf3c5061afeb847958f27fe._comment
new file mode 100644
index 0000000000..a1bee43df0
--- /dev/null
+++ b/doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_2_44eb5f14dbf3c5061afeb847958f27fe._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="vgp"
+ avatar="http://cdn.libravatar.org/avatar/b332bfc1d3f49c196e1bff84b53d0f8b"
+ subject="comment 2"
+ date="2017-08-30T12:42:22Z"
+ content="""
+Thanks for your comments joey! 
+In fact, compress files in the working tree is not mandatory. The main question is compress then in the git server (quota reasons). When we were using only git, it was slow (caused by huge files) but the files were compressed. Now, using git-annex, the operations are faster but the size of the repository increases a lot (due to lack of compression) and that is the problem once we've reached the disk quota in the git server.
+"""]]
diff --git a/doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_3_4788a41425d4cc65e9f529dbcdb2bf73._comment b/doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_3_4788a41425d4cc65e9f529dbcdb2bf73._comment
new file mode 100644
index 0000000000..d070f67a33
--- /dev/null
+++ b/doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_3_4788a41425d4cc65e9f529dbcdb2bf73._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="vgp"
+ avatar="http://cdn.libravatar.org/avatar/b332bfc1d3f49c196e1bff84b53d0f8b"
+ subject="comment 3"
+ date="2017-09-01T21:40:11Z"
+ content="""
+I've tried the \"directory\" special remote with encryption=shared. It works well and I got a total size of 3.5GB while the working tree .git/annex dir has 21GB :-). The problem is: the git server of my research lab gives me a disk quota of 10GB, however, I cannot access it directly to store these files using \"directory\" special remote. Is there a way to use compression (probably through encryption) with a normal git remote?  
+"""]]
diff --git a/doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_4_4dbb0b18905d30ae6b187745859e75c2._comment b/doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_4_4dbb0b18905d30ae6b187745859e75c2._comment
new file mode 100644
index 0000000000..8ca0c6da56
--- /dev/null
+++ b/doc/forum/huge_text_files___40__not_binary__41___-_compress/comment_4_4dbb0b18905d30ae6b187745859e75c2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 4"
+ date="2021-04-20T18:30:39Z"
+ content="""
+Perhaps Git Annex could have first-class support for a local special remote inside the .git/annex dir where files that aren't checked out are stored in a more efficient manner.  
+This would mainly be useful for old versions of files you want to keep in the repo but don't need immediate access to or bare repos like in OP's case. Once special remotes support compression, it might make sense to make it the default storage method for bare repos actually.    
+Ideally these could be set to be any local special remote backend; bup would make an ideal candidate for storing old versions of documents efficiently for example.
+
+Having files in this such a \"local special remote\" would then be equivalent to having them in the regular .git/annex/objects dir for tracking purposes.
+"""]]
diff --git a/doc/forum/ignore_changes_made_by_a_remote.mdwn b/doc/forum/ignore_changes_made_by_a_remote.mdwn
new file mode 100644
index 0000000000..3659774b4c
--- /dev/null
+++ b/doc/forum/ignore_changes_made_by_a_remote.mdwn
@@ -0,0 +1,8 @@
+Hi,
+
+I have two repo one in direct (on windows) and one in indirect mode. From time to time the files in the direct repo are replaced by empty files however running git annex fsck always solves it.
+The problem is that today I did run git annex sync before running git annex fsck and git annex has then created two -variants for each of my files one empty and one with the content.
+I guess the easier for me is to just scrap that repo and make a new one however how do I prevent the changes to propagate now? I guess that if I now run git annex sync on my other repo all those small files are going to have linked created for them there as well.
+
+I hope this is clear,
+Thanks in advance.
diff --git a/doc/forum/ignore_changes_made_by_a_remote/comment_1_825676069d2e1554499b76fd8c306c30._comment b/doc/forum/ignore_changes_made_by_a_remote/comment_1_825676069d2e1554499b76fd8c306c30._comment
new file mode 100644
index 0000000000..e758aa8a7d
--- /dev/null
+++ b/doc/forum/ignore_changes_made_by_a_remote/comment_1_825676069d2e1554499b76fd8c306c30._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 1"
+ date="2014-04-02T20:02:19Z"
+ content="""
+I don't see any need to scrap the repository. Since you have an indirect mode repository, you can use `git log` in there to find commits you don't like, and run `git revert` to revert them. So if a bad commit comes down from windows, you can just undo it. That's why we use git, yes?
+
+I'm much more curious about the circumstances that cause empty files to end up in the direct mode repository. 
+"""]]
diff --git a/doc/forum/ignore_changes_made_by_a_remote/comment_2_dff49b72f7e072fddaf68584beb97f3c._comment b/doc/forum/ignore_changes_made_by_a_remote/comment_2_dff49b72f7e072fddaf68584beb97f3c._comment
new file mode 100644
index 0000000000..394a609b46
--- /dev/null
+++ b/doc/forum/ignore_changes_made_by_a_remote/comment_2_dff49b72f7e072fddaf68584beb97f3c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="bvaa"
+ ip="86.82.68.238"
+ subject="comment 2"
+ date="2014-04-03T19:20:31Z"
+ content="""
+Ok it makes indeed sense.
+Regarding the empty files I am going to try to find out where that happens and if I can reproduce.
+Thanks.
+"""]]
diff --git a/doc/forum/import_and_export_treeish_for_rsync_and_webdav.mdwn b/doc/forum/import_and_export_treeish_for_rsync_and_webdav.mdwn
new file mode 100644
index 0000000000..c4e03503fe
--- /dev/null
+++ b/doc/forum/import_and_export_treeish_for_rsync_and_webdav.mdwn
@@ -0,0 +1,3 @@
+is it possible for having import/export (pull/push) funciontality for the rsync special remote? similar to how the adb special remote handles importing and exporting treeishes?  an example use case is that i have a pinePhone which i push files (music, podcasts, pdfs) to using the rsync special remote so it can be done over my wifi network, but it would be cool to also be able to import either any picutres i take, or to import any documents that I pull from the internet and then store on the pinePhone back into my annex.
+
+some reasons that I do not just make a another full annex repo on the pinePhone really comes down computation resource limitations of the pinephone. and I have a very large git annex (150,000+ keys) which can make the git repo fairly large.
diff --git a/doc/forum/import_and_export_treeish_for_rsync_and_webdav/comment_1_6a8ee189ff2fee0697b67a405f22c5a4._comment b/doc/forum/import_and_export_treeish_for_rsync_and_webdav/comment_1_6a8ee189ff2fee0697b67a405f22c5a4._comment
new file mode 100644
index 0000000000..8d7692a132
--- /dev/null
+++ b/doc/forum/import_and_export_treeish_for_rsync_and_webdav/comment_1_6a8ee189ff2fee0697b67a405f22c5a4._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-06-14T16:45:21Z"
+ content="""
+exporttree is already supported by both. importtree is unlikely to be
+supported. It's difficult to support this without opening up a very real
+possibility of data loss. If you're importing and exporting to the same
+remote, what happens when there's a conflict? Eg, whatever else is writing
+files to the remote writes to a file, but you locally modify the same file,
+and export a tree, without importing the new version first. That
+would overwrite the modified file on the remote, losing data.
+
+All the special remotes that support exporttree+importtree are able to
+avoid losing data in this scenario. (At least as well as git is able to,
+there are similar races when git updates a working tree at the same time
+you modify a file in the working tree, but the timing of it makes it very
+unlikely, so much that noone seems to worry about it).
+See also [[todo/import_tree_from_rsync_special_remote]]
+
+I have not felt comfortable giving users a loaded gun in this case. So only
+exporttree is supported, because the user doesn't expect something
+else to be writing to files on that remote, or if they do, they don't
+have any reason to expect git-annex to deal with it well.
+
+Anyway, it seems to me it should be possible to install git-annex on
+your pinephone and connect the repos using ssh.
+"""]]
diff --git a/doc/forum/importfeed__58___comments_in_file_with_feed_urls.mdwn b/doc/forum/importfeed__58___comments_in_file_with_feed_urls.mdwn
new file mode 100644
index 0000000000..0f2ab97316
--- /dev/null
+++ b/doc/forum/importfeed__58___comments_in_file_with_feed_urls.mdwn
@@ -0,0 +1,5 @@
+Hi,
+
+how can I use comments in the file containing the feed urls.
+
+The hash symbol # causes a bad feed exception.
diff --git a/doc/forum/importfeed__58___comments_in_file_with_feed_urls/comment_1_370f5165fdda5c01a5335c864321a348._comment b/doc/forum/importfeed__58___comments_in_file_with_feed_urls/comment_1_370f5165fdda5c01a5335c864321a348._comment
new file mode 100644
index 0000000000..c4e2437662
--- /dev/null
+++ b/doc/forum/importfeed__58___comments_in_file_with_feed_urls/comment_1_370f5165fdda5c01a5335c864321a348._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-30T15:49:41Z"
+ content="""
+Well, this seems to work:
+
+	git annex importfeed --fast http://www.starshipsofa.com/feed/#award-winning-science-fiction-podcast
+
+But that limits you to url formatted comments. Instead, you could make
+the list of feeds into a shell script.
+
+	#!/bin/sh
+	# award winning science fiction podcast
+	git annex importfeed http://www.starshipsofa.com/feed/
+
+Or, you could strip out comments from the list of feeds before passing it to
+git-annex:
+
+	sed 's/#.*//' feeds | xargs git-annex importfeed
+
+How you do it is really up to you..
+"""]]
diff --git a/doc/forum/importfeed_does_not_work_with_youtube_anymore.mdwn b/doc/forum/importfeed_does_not_work_with_youtube_anymore.mdwn
new file mode 100644
index 0000000000..9d81b7eff5
--- /dev/null
+++ b/doc/forum/importfeed_does_not_work_with_youtube_anymore.mdwn
@@ -0,0 +1 @@
+Did youtube change their api? My youtube feeds doesn't work anymore. No problems with other sites.
diff --git a/doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_1_2fcbc85d7aa51dfdb2025a00c37fa8ac._comment b/doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_1_2fcbc85d7aa51dfdb2025a00c37fa8ac._comment
new file mode 100644
index 0000000000..9a76767ae0
--- /dev/null
+++ b/doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_1_2fcbc85d7aa51dfdb2025a00c37fa8ac._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-15T15:48:44Z"
+ content="""
+There's no API involved; git-annex importfeed consumes RSS feeds. Google no
+longer supports such reasonable technology.
+"""]]
diff --git a/doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_2_58733a5065493dbac5cb8d12a029dace._comment b/doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_2_58733a5065493dbac5cb8d12a029dace._comment
new file mode 100644
index 0000000000..9380c54c15
--- /dev/null
+++ b/doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_2_58733a5065493dbac5cb8d12a029dace._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="workaround with youtube-dl"
+ date="2018-11-03T20:52:49Z"
+ content="""
+i hacked my way around this problem with this crazy commandline:
+
+    URL=www.youtube.com/user/WHATEVER/videos # or playlist or whatever
+    youtube-dl --dump-json --flat-playlist $URL | jq -r '.id' | sed 's_^_https://www.youtube.com/watch?v=_' > urls.txt
+    git -c annex.security.allowed-http-addresses=all annex  addurl --batch < urls.txt
+
+It's idiotic that youtube removed support for standard stuff, but that's the name of the game these days. Maybe git-annex could delegate this to youtube-dl? --[[anarcat]]
+"""]]
diff --git a/doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_3_aef7c172d485f8f6570ada5756446480._comment b/doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_3_aef7c172d485f8f6570ada5756446480._comment
new file mode 100644
index 0000000000..42b42f9eac
--- /dev/null
+++ b/doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_3_aef7c172d485f8f6570ada5756446480._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-11-12T20:17:31Z"
+ content="""
+There is actually a way to construct a rss feed url that will work,
+but nowhere in youtube can you find the url.
+[[tips/downloading_podcasts]] discusses how the url looks like; finding the
+`channel_id` value for a given youtube page tends to involve grepping the
+html or some third-party tool.
+
+If youtube-dl had a way to extract the `channel_id`, I suppose I might make
+git-annex use it. Although leaving the user to jump through the absurd
+hoops google has set up to find an rss feed does highlight just how
+user-hostile and standard-hostile Google is being here; it sends some
+important signals to the user about the entity they're interacting with,
+their business model, and how likely the rss feed is to break in the
+future.
+"""]]
diff --git a/doc/forum/importfeed_loads_files_a_second_time_prepending_a_2__95__.mdwn b/doc/forum/importfeed_loads_files_a_second_time_prepending_a_2__95__.mdwn
new file mode 100644
index 0000000000..1a6a591960
--- /dev/null
+++ b/doc/forum/importfeed_loads_files_a_second_time_prepending_a_2__95__.mdwn
@@ -0,0 +1,8 @@
+I recognize that git annex importfeed is reloading old files for a second time while prepending the file name with "2_".
+
+So if there is a podcast file called "foo_bar_in_baz_20170101.mp3" it now imports the same file again naming it "2_foo_bar_in_baz_20170101.mp3".
+
+As I cannot imaging that the feed provider is renaming the files I guess that something else is triggerin this behaviour. Any ideas?
+
+TIA
+juh
diff --git a/doc/forum/importfeed_loads_files_a_second_time_prepending_a_2__95__/comment_1_1623344457fbe10c464506e41fbac3d8._comment b/doc/forum/importfeed_loads_files_a_second_time_prepending_a_2__95__/comment_1_1623344457fbe10c464506e41fbac3d8._comment
new file mode 100644
index 0000000000..03b935f4ae
--- /dev/null
+++ b/doc/forum/importfeed_loads_files_a_second_time_prepending_a_2__95__/comment_1_1623344457fbe10c464506e41fbac3d8._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-10-11T15:17:41Z"
+ content="""
+RSS feeds have unique IDs that are attached to a post in the feed.
+They are supposed to be allocated once and remain unchanged. It's not
+entirely uncommon for the unique IDs to change (due to broken feed
+generation software, changing feed generation software, etc), and then git-annex
+thinks this is a new file in the feed, that happens to have the same
+title as another file, so it makes up a unique name for it with the "2_".
+
+Since the alternative is to miss downloading new files from the RSS feed
+if they happen to have the same title as a previous file, I think we have
+to live with this.
+
+(git-annex was improved in version 5.20150727 to avoid some cases
+of this)
+"""]]
diff --git a/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists.mdwn b/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists.mdwn
new file mode 100644
index 0000000000..f358b9fc0f
--- /dev/null
+++ b/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists.mdwn
@@ -0,0 +1 @@
+I have decided to add importing of another playlist to the same repo (https://github.com/TrueTube/Andriy_Popyk) which already had some videos fetched for another playlist.  First I got confused since my invocation of `git annex importfeed --debug --fast 'https://www.youtube.com/feeds/videos.xml?playlist_id=PLSWNjjvqdBIsKntshAmYH7HBCv2HLlowX' --template 'Суспільство_і_політика/${itempubdate}-${itemtitle}.mkv'` just silently (no reason even in `--debug` output) did nothing. RTFM pointed me to `--force` flag which "Force downloading items it's seen before." which seemed like a remedy since it quickly added those videos from the play list.  But it is not a clean remedy since rerunning causes `git annex` to re-add those same videos with `2_` prefix, wasting "traffic" and requiring subsequent adhoc `git rm -f folder/2_`.  I wonder if there could be some way to avoid needing that?
diff --git a/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_1_ecd0764e7f15469217fd5e04a563f34c._comment b/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_1_ecd0764e7f15469217fd5e04a563f34c._comment
new file mode 100644
index 0000000000..2c776195d7
--- /dev/null
+++ b/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_1_ecd0764e7f15469217fd5e04a563f34c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2024-01-31T19:23:23Z"
+ content="""
+eg if there was a mode to just skip those which would cause to overwrite the existing files
+"""]]
diff --git a/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_2_b9885808ebe447c26283f910f4fc37c3._comment b/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_2_b9885808ebe447c26283f910f4fc37c3._comment
new file mode 100644
index 0000000000..79b1eb5a62
--- /dev/null
+++ b/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_2_b9885808ebe447c26283f910f4fc37c3._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2024-02-02T18:34:23Z"
+ content="""
+The reason it doesn't overwrite is that it's not impossible for a feed
+to have two posts with the same title (eg "happy groundhogs day") or
+whatever else is used to construct the filename (unless you use `${itemid}`
+in your --template).
+
+Maybe overwriting would have been the right choice in your situation.. do
+you think an option that overwrites would be useful?
+
+Or maybe better, an option that skips downloading when a file with the
+generated name already exists? If one groundhog's day greeting
+is enough for you..
+"""]]
diff --git a/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_3_aa1077117a83ecffccb8d2095818fa02._comment b/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_3_aa1077117a83ecffccb8d2095818fa02._comment
new file mode 100644
index 0000000000..2d3cccb343
--- /dev/null
+++ b/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_3_aa1077117a83ecffccb8d2095818fa02._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2024-02-02T19:08:38Z"
+ content="""
+I don't think overwrite here should have done anything -- should have been the same key and filename, so should be the same as skipping I think.
+
+Overall indeed might be just nice to have `--existing noclob|overwrite|skip` so it either adds index to declob, or skips or overwrites?  I would have probably used either skip or overwrite ;)
+"""]]
diff --git a/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_4_0bf6d5b03032c0b9fd35c8410aea832c._comment b/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_4_0bf6d5b03032c0b9fd35c8410aea832c._comment
new file mode 100644
index 0000000000..2b79698131
--- /dev/null
+++ b/doc/forum/importfeed_on_multiple___34__overlapping__34___playlists/comment_4_0bf6d5b03032c0b9fd35c8410aea832c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2024-02-02T19:27:41Z"
+ content="""
+Oh, but it seems that `importfeed --force` already has code to handle this.
+It checks if the file already exists and has the same url recorded as the url
+being imported. For some reason in that case, it says it failed to import
+the url, which seems a bit odd behavior to me, but in any case it doesn't
+add a "2_" file.
+
+That works for regular rss feeds, but does not work for yt-dlp urls.
+
+The reason is the url mangling done for yt-dlp urls (and other special
+remote urls). Fixed this bug.
+"""]]
diff --git a/doc/forum/include__61__subdir__47____42___in_prefererred_content_expression_not_working.mdwn b/doc/forum/include__61__subdir__47____42___in_prefererred_content_expression_not_working.mdwn
new file mode 100644
index 0000000000..275a052b4a
--- /dev/null
+++ b/doc/forum/include__61__subdir__47____42___in_prefererred_content_expression_not_working.mdwn
@@ -0,0 +1,31 @@
+Hi there,
+
+If I use a preferred content expression like the following:
+
+    include=subdir/*
+
+it does not work in commands like `git annex get --auto`.
+
+But the following works:
+
+    include=*
+
+Here is a short bash script that can be used to recreate this issue:
+
+    mkdir annexA && cd annexA
+    git init && git annex init
+    git remote add annexB ../annexB
+
+    mkdir ../annexB && cd ../annexB
+    git init && git annex init
+    git annex wanted . "include=subdir/*"
+    git remote add annexA ../annexA
+
+    cd ../annexA && mkdir subdir
+    echo "lorem ipsum" > subdir/test.txt
+    git annex add . && git annex sync
+
+    cd ../annexB && git annex sync
+    git annex get --auto
+
+I'm using **Git 2.28.0.windows.1** and **git-annex 8.20200815-g335aae266**.
diff --git a/doc/forum/incompatible_versions__63__.mdwn b/doc/forum/incompatible_versions__63__.mdwn
new file mode 100644
index 0000000000..13eb181491
--- /dev/null
+++ b/doc/forum/incompatible_versions__63__.mdwn
@@ -0,0 +1 @@
+Are versions 0.14 and 0.20110522 incompatible? I can't seem to copy files from a system running 0.14 to one running 20110522.
diff --git a/doc/forum/incompatible_versions__63__/comment_1_629f28258746d413e452cbd42a1a43f4._comment b/doc/forum/incompatible_versions__63__/comment_1_629f28258746d413e452cbd42a1a43f4._comment
new file mode 100644
index 0000000000..3702fde6ea
--- /dev/null
+++ b/doc/forum/incompatible_versions__63__/comment_1_629f28258746d413e452cbd42a1a43f4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-06-08T00:40:54Z"
+ content="""
+They are not. See [[upgrades]]
+"""]]
diff --git a/doc/forum/initremote_type__61__web.mdwn b/doc/forum/initremote_type__61__web.mdwn
new file mode 100644
index 0000000000..3bb420b7a1
--- /dev/null
+++ b/doc/forum/initremote_type__61__web.mdwn
@@ -0,0 +1,5 @@
+Is there an easy way to setup a web remote with a URL to an existing annex such as the following?
+
+    git annex initremote my_annex type=web URL=http://my_server.net/path/to/annex
+
+I've created an annex mirror using an rsync special remote on a web server. I can browse the files via HTTP, but how do I tell git annex to fetch the files from there?
diff --git a/doc/forum/initremote_type__61__web/comment_1_9ad92da9525cd89e515d1c5745a59c13._comment b/doc/forum/initremote_type__61__web/comment_1_9ad92da9525cd89e515d1c5745a59c13._comment
new file mode 100644
index 0000000000..6efe937d95
--- /dev/null
+++ b/doc/forum/initremote_type__61__web/comment_1_9ad92da9525cd89e515d1c5745a59c13._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-30T14:24:34Z"
+ content="""
+The web special remote is not the thing you want to use for this.
+That represents arbitrary files on any website, not a single git-annex
+repository on one website.
+
+Just add a git remote using the http protocol, pointing to a git
+repository.
+
+	git remote add http://my_server.net/path/to/repo/.git
+
+See [[tips/setup_a_public_repository_on_a_web_site]] for several
+configurations you will probably want to set on that repository to make it
+work well over http.
+"""]]
diff --git a/doc/forum/initremote_type__61__web/comment_2_acc1dce80c3ed3b13fdfba55ab362581._comment b/doc/forum/initremote_type__61__web/comment_2_acc1dce80c3ed3b13fdfba55ab362581._comment
new file mode 100644
index 0000000000..257b6d9480
--- /dev/null
+++ b/doc/forum/initremote_type__61__web/comment_2_acc1dce80c3ed3b13fdfba55ab362581._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://templeofcrom.duckdns.org/"
+ nickname="Karl"
+ avatar="http://cdn.libravatar.org/avatar/336975995d2c8652aa98284987d5987e90e1b4d137da415af18a8e04c29edbc3"
+ subject="comment 2"
+ date="2020-07-01T15:03:08Z"
+ content="""
+I already have a git repository but my large files are being stored on the webserver, not in git.  It's not clear at all how to tell git-annex to fetch from the web server.  My project is being hosted on SourceForge so I have little control over either the Git or HTTP servers and the URL is different for each.
+
+"""]]
diff --git a/doc/forum/initremote_type__61__web/comment_3_b222de7b3d4397fe8bcafd20c661bc64._comment b/doc/forum/initremote_type__61__web/comment_3_b222de7b3d4397fe8bcafd20c661bc64._comment
new file mode 100644
index 0000000000..b86487123a
--- /dev/null
+++ b/doc/forum/initremote_type__61__web/comment_3_b222de7b3d4397fe8bcafd20c661bc64._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-07-01T15:24:47Z"
+ content="""
+There is not currently a way to access files that were stored in a rsync
+special remote over http instead of rsync. That would need a new special
+remote, distinct from the web special remote.
+
+I suppose it's a reasonable request, since the rsync and directory special
+remotes are already [[cross_compatible|tips/multiple_remotes_accessing_the_same_data_store]].
+And it could probably also be used for anonymous access to webdav and S3
+special remotes.
+
+Anyway, the option that is available today, and works, is to mirror a git
+repository to the web server (running `git update-server-info` first) 
+and add a git remote with the http url.
+"""]]
diff --git a/doc/forum/initremote_type__61__web/comment_4_d128b2abef6cfdcac679aeff7a52d493._comment b/doc/forum/initremote_type__61__web/comment_4_d128b2abef6cfdcac679aeff7a52d493._comment
new file mode 100644
index 0000000000..5e5bba36f3
--- /dev/null
+++ b/doc/forum/initremote_type__61__web/comment_4_d128b2abef6cfdcac679aeff7a52d493._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-07-01T16:04:58Z"
+ content="""
+[[todo/generic_readonly_http_remote]]
+"""]]
diff --git a/doc/forum/initremote_type__61__web/comment_5_8de26c367ccb68b917b0b5f91eec8d1a._comment b/doc/forum/initremote_type__61__web/comment_5_8de26c367ccb68b917b0b5f91eec8d1a._comment
new file mode 100644
index 0000000000..4d109d8326
--- /dev/null
+++ b/doc/forum/initremote_type__61__web/comment_5_8de26c367ccb68b917b0b5f91eec8d1a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://templeofcrom.duckdns.org/"
+ nickname="Karl"
+ avatar="http://cdn.libravatar.org/avatar/336975995d2c8652aa98284987d5987e90e1b4d137da415af18a8e04c29edbc3"
+ subject="comment 5"
+ date="2020-07-01T21:54:49Z"
+ content="""
+The generic readonly http remote sounds like what I was expecting web special remote to be.  It would be great if that gets implemented.
+"""]]
diff --git a/doc/forum/is_it_possible_to_use_github_with_git-lfs_special_remote_within_the_assistant___40__android__41____63__.mdwn b/doc/forum/is_it_possible_to_use_github_with_git-lfs_special_remote_within_the_assistant___40__android__41____63__.mdwn
new file mode 100644
index 0000000000..7a70b2e054
--- /dev/null
+++ b/doc/forum/is_it_possible_to_use_github_with_git-lfs_special_remote_within_the_assistant___40__android__41____63__.mdwn
@@ -0,0 +1,12 @@
+Following up on [DataLad's git-objects special remote idea PR](https://github.com/datalad/datalad/pull/3727#issuecomment-540116323), I have thought to try establishing git-lfs powered (special) remote on github, within assistant (installed a few days back) ran within Termux, on an android phone.
+
+Within assistant web UI I did not find a good match for this scenario in "Add more repositories". What would it be (if any exists/defined already)?
+
+Having found none, I've decided to try the closest match -- "remote server using ssh".  But in that form, for some reason, after entering "github.com" for "Host name" results in "cannot resolve host name". 
+
+- I verified that github.com is reachable in chrome
+- I thought that may be Termux "session" doesn't have access to DNS, so I switched to termux (where I started `git annex webapp`), and ran `ping github.com`.
+  - it did resolve the IP (to 192.30.253.113)
+  - but no ping came back
+
+[[!meta author=yoh]]
diff --git a/doc/forum/is_it_possible_to_use_github_with_git-lfs_special_remote_within_the_assistant___40__android__41____63__/comment_1_d9e0c9471c14178a1b3d07d3c6d76897._comment b/doc/forum/is_it_possible_to_use_github_with_git-lfs_special_remote_within_the_assistant___40__android__41____63__/comment_1_d9e0c9471c14178a1b3d07d3c6d76897._comment
new file mode 100644
index 0000000000..a5bbb94af4
--- /dev/null
+++ b/doc/forum/is_it_possible_to_use_github_with_git-lfs_special_remote_within_the_assistant___40__android__41____63__/comment_1_d9e0c9471c14178a1b3d07d3c6d76897._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2019-10-09T18:10:05Z"
+ content="""
+FWIW -- seems to be a generic (not github.com specific) DNS issue, since fails to resolve other names as well.
+
+In the dashboard there is a Warning about `RemoteControl crashed: user error (nice [... remotedaemon... exited 1)` -- could be related?
+"""]]
diff --git a/doc/forum/is_it_possible_to_use_github_with_git-lfs_special_remote_within_the_assistant___40__android__41____63__/comment_2_a73cbde4297d1be734c768d7b8f9d597._comment b/doc/forum/is_it_possible_to_use_github_with_git-lfs_special_remote_within_the_assistant___40__android__41____63__/comment_2_a73cbde4297d1be734c768d7b8f9d597._comment
new file mode 100644
index 0000000000..28f7880b19
--- /dev/null
+++ b/doc/forum/is_it_possible_to_use_github_with_git-lfs_special_remote_within_the_assistant___40__android__41____63__/comment_2_a73cbde4297d1be734c768d7b8f9d597._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-10-20T17:51:53Z"
+ content="""
+See [[bugs/Host_resolution_error_on_Android_when_adding_RSync.net_repo]]
+"""]]
diff --git a/doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__.mdwn b/doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__.mdwn
new file mode 100644
index 0000000000..b5b38ce3c0
--- /dev/null
+++ b/doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__.mdwn
@@ -0,0 +1,37 @@
+I'm storing hundreds of gigabytes of data on a S3 remote, and often when I try to copy to my remote using this type of command:
+
+    git annex copy newdir/* --to my-s3-remote
+
+I'll get a little bit of the way uploading some large file (which is in chunks) and then something like this:
+
+    copy newdir/file1.tgz (gpg) (checking my-s3-remote...) (to my-s3-remote...) 
+
+    3%        2.2MB/s 11h14m
+
+      ErrorMisc "<socket: 16>: Data.ByteString.hGetLine: timeout (Operation timed out)"
+
+    failed                  
+
+    copy newdir/file2.tgz (checking my-s3-remote...) (to my-s3-remote...) 
+
+    15%        2.3MB/s 3h40m
+
+      ErrorMisc "<socket: 16>: Data.ByteString.hGetLine: resource vanished (Connection reset by peer)"
+
+    failed                  
+
+    copy newdir/file3.tgz (checking my-s3-remote...) (checking my-s3-remote...) (checking my-s3-remote...) (checking my-s3-remote...) (checking my-s3-remote...) (checking my-s3-remote...) (checking my-s3-remote...) ok
+    
+One common cause of this is if my Internet connection is intermittent. But even when my connection seems steady, it can happen. I'm willing to chalk that up to network problems elsewhere though.
+
+If I keep just hitting "up enter" to re-execute the command each time it fails, eventually everything gets up there.
+
+But this can actually take weeks, because often uploading these big files, I'll let it go overnight, and then wake up every morning and find out with dismay that it has failed again.
+
+My questions:
+
+- Is there a way to make it automatically retry? I am sure that upon any of these errors, an immediate automatic reply would amost assuredly work.
+
+- If not, is there at least a way to make it pick up where it left off? Even though I'm using chunks, it seems to start the file over again.
+
+Thanks.
diff --git a/doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/comment_1_82820ce711b87b092a21e31fd381ffce._comment b/doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/comment_1_82820ce711b87b092a21e31fd381ffce._comment
new file mode 100644
index 0000000000..2ab0a8ebb8
--- /dev/null
+++ b/doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/comment_1_82820ce711b87b092a21e31fd381ffce._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-01-05T20:23:40Z"
+ content="""
+The git-annex assistant will automatically retry uploads/downloads, if you
+want to use it.
+
+Or, you can use a simple loop until git-annex succeeds:
+
+	while ! git-annex annex copy newdir/* --to my-s3-remote ; do echo retry ; done
+
+As to picking up where it left off, make sure you have a recent
+release of git-annex, and then you can enable chunking for a S3
+remote. git-annex can then resume an upload or download starting
+at the next chunk that needs to be transferred.
+
+See [[chunking]].
+"""]]
diff --git a/doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/comment_2_160e80583b647eae53aa120ca734e34a._comment b/doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/comment_2_160e80583b647eae53aa120ca734e34a._comment
new file mode 100644
index 0000000000..cb2188efdd
--- /dev/null
+++ b/doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/comment_2_160e80583b647eae53aa120ca734e34a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://digiuser.livejournal.com/"
+ subject="Is there a way to make this upload all files that have not been uploaded yet?"
+ date="2015-01-08T02:37:51Z"
+ content="""
+Let's say I want my S3 repo to have all files in it that are in my current repo. Is there a variation of this while loop that will keep uploading until it's done?
+
+I recognize I could use annex assistant but let's say I just want to do it this way.
+"""]]
diff --git a/doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/comment_3_6d81a41edf052e310e1f80cc6add3c09._comment b/doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/comment_3_6d81a41edf052e310e1f80cc6add3c09._comment
new file mode 100644
index 0000000000..05e0cd3e3d
--- /dev/null
+++ b/doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/comment_3_6d81a41edf052e310e1f80cc6add3c09._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 3"
+ date="2015-01-08T18:13:47Z"
+ content="""
+That's what the while loop above does; runs the git-annex command, and retries it until it succeeds.
+"""]]
diff --git a/doc/forum/is_there_a_way_to_only_commit_some_files_in_direct-mode___63__.mdwn b/doc/forum/is_there_a_way_to_only_commit_some_files_in_direct-mode___63__.mdwn
new file mode 100644
index 0000000000..9c76e1d425
--- /dev/null
+++ b/doc/forum/is_there_a_way_to_only_commit_some_files_in_direct-mode___63__.mdwn
@@ -0,0 +1,5 @@
+I would like to be able to use git-annex to not only sync binary files for a project but also to be able to use it more like git, that is adding manually files to index and only commiting that.
+I think it is still possible in indirect-mode to manage files like I want, but as I am stuck in windows, I would like to be able to do that in direct-mode...
+Due to the safety measures taken to avoid doing bad things in direct-mode, it doesn't seem possible to commit (and push) files without syncing the whole repository.
+
+Is it currently possible to do what I would like to do, or will it be possible in the future ?
diff --git a/doc/forum/is_there_a_way_to_only_commit_some_files_in_direct-mode___63__/comment_1_804e43111ee97dff15e49e50b6c29d91._comment b/doc/forum/is_there_a_way_to_only_commit_some_files_in_direct-mode___63__/comment_1_804e43111ee97dff15e49e50b6c29d91._comment
new file mode 100644
index 0000000000..9a75526146
--- /dev/null
+++ b/doc/forum/is_there_a_way_to_only_commit_some_files_in_direct-mode___63__/comment_1_804e43111ee97dff15e49e50b6c29d91._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 1"
+ date="2013-12-12T17:01:50Z"
+ content="""
+You can `git annex add` some files and leave others not added, and `git annex sync` will commit only the added ones. 
+
+What is missing is a way to have changed some files that were added, and avoid `git annex sync` committing them. 
+
+There is no technical reason this cannot be supported in direct mode, there is just no user interface built to do it. 
+
+One way is to temporarily bypass the direct mode guard, by using the appropriate git command line option to set core.bare=false temporarily while committing files. Note that it's then up to you to avoid staging the entire content of the file into the index (so no `git commit -a` etc).
+"""]]
diff --git a/doc/forum/is_there_a_way_to_only_commit_some_files_in_direct-mode___63__/comment_2_299ad6cd0225daa166d36af3726a9ef2._comment b/doc/forum/is_there_a_way_to_only_commit_some_files_in_direct-mode___63__/comment_2_299ad6cd0225daa166d36af3726a9ef2._comment
new file mode 100644
index 0000000000..0fb4a00977
--- /dev/null
+++ b/doc/forum/is_there_a_way_to_only_commit_some_files_in_direct-mode___63__/comment_2_299ad6cd0225daa166d36af3726a9ef2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Renaud"
+ ip="182.171.224.143"
+ subject="comment 2"
+ date="2013-12-13T06:16:12Z"
+ content="""
+Thanks for the reply!
+
+I tried to commit manually but I got confused by the (recently introduced?) annex/direct/master branch and I am not sure which branch I need to commit/merge/pull/push my changes to.
+I also got blocked when pulling from origin fail due to file changes needed to be overwritten.
+I see git-annex cleverly merges those in .git/annex/merge folder so I could try doing the same but I am not too confortable doing a large part of git-annex's job...
+
+Is there a simpler way to sync with a remote repository?
+"""]]
diff --git a/doc/forum/is_windows_really_slow__63__.mdwn b/doc/forum/is_windows_really_slow__63__.mdwn
new file mode 100644
index 0000000000..18e74fb21e
--- /dev/null
+++ b/doc/forum/is_windows_really_slow__63__.mdwn
@@ -0,0 +1,16 @@
+I am trying annex for the first time.
+I am trying it on windows (installed the beta).
+My understanding from reading the docs is that it uses the repo in fully unlocked mode because windows does not support symlinks (or so git / git-annex believes).
+
+I currently have about 55K files and 220GB... mostly pictures.
+
+I have sidecar XMP files (text) next to each jpeg.
+When I git add the XMP files, it is very very slow (about 1s per file).
+When I do git status after adding them it takes minutes (refreshing index...).
+
+I have a pretty powerful machine:
+Processor	Intel(R) Core(TM) i9-7940X CPU @ 3.10GHz, 3096 Mhz, 14 Core(s), 28 Logical Processor(s)
+128GB RAM
+2TB NVMe SSD (~3GB/s symmetric transfer rate).
+
+My gut feel is that it is because all the jpgs remain in the worktree as opposed to symlinked, but wanted to hear an expert opinion?
diff --git a/doc/forum/journal.lck_became_readonly_after_really_long_fsck.mdwn b/doc/forum/journal.lck_became_readonly_after_really_long_fsck.mdwn
new file mode 100644
index 0000000000..7d7f1af6be
--- /dev/null
+++ b/doc/forum/journal.lck_became_readonly_after_really_long_fsck.mdwn
@@ -0,0 +1,16 @@
+i recently ran a git annex fsck --all command on my really large backup drive, the check ran all the way through the night, and suddenly it stopped with this error. after getting this error, i tried running a git annex sync, but got the same (read-only file system) error.  does anyone have any insight about how to fix this? Or better yet, what might have happened?
+
+
+    SHA256E-s3586436--8d7effd412a3225663569a481a5d2fc51c9bf321316119656ce287efa00d69c7.m4a (checksum...) ok
+    fsck SHA256E-s502--fa9835b9b4655c834732892eb93a3106cdee52b0b1deabc2912742d05323693b.ini
+    ** No known copies exist of SHA256E-s502--fa9835b9b4655c834732892eb93a3106cdee52b0b1deabc2912742d05323693b.ini
+    (Avoid this check by running: git annex dead --key )   
+    failed
+    fsck SHA256E-s432681--7a504d72fbbd89c2c05603beb7fedff1d89cc38b6b4a9903f5eabf94dc1f840e.JPG (checksum...) ok
+    fsck SHA256E-s3092745--e682bd862da64ad7d3a81b7dd54700e1536057f3c83972b452eba5f40037db6b.JPG (checksum...) ok
+    fsck SHA256E-s306570--d7cab655cb0bbd2de09008888101724d37ceef4060d72ea477cc3cd1d0da20b0.jpg (checksum...) ok
+    fsck SHA256E-s3814174--00bba1e6cb5d8e295a3299a24921044dc3b5a57a86420d65fe796d5505c41aee.mp4 (checksum...) ok
+    fsck SHA256E-s2345012--9530b1b32b3b1198c42aa4919a5b34698cc75adc9abf5b7b8ca02f7962c66a25.MOV (checksum...) ok
+    fsck SHA256E-s42254--cb1ae72d7b3a7bddbf5a93142cc1eed43bb5ceacf8fc3920de7876eafb2ea044.jpg (checksum...) ok
+    fsck SHA256E-s5619907--a190d2f9805d0c9deb1bacead9ce89b895fc21bf7cef38bcf97a3841693e8c8f.ogg (checksum...) ok
+    git-annex: .git/annex/journal.lck: openFd: permission denied (Read-only file system)
diff --git a/doc/forum/journal.lck_became_readonly_after_really_long_fsck/comment_1_6c094472d7f6f5f0257a445805200a82._comment b/doc/forum/journal.lck_became_readonly_after_really_long_fsck/comment_1_6c094472d7f6f5f0257a445805200a82._comment
new file mode 100644
index 0000000000..8a1314ad03
--- /dev/null
+++ b/doc/forum/journal.lck_became_readonly_after_really_long_fsck/comment_1_6c094472d7f6f5f0257a445805200a82._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-10-30T16:45:52Z"
+ content="""
+This has nothing to do with git-annex. For some reason your file system went read-only, you have to look at your kernel log (`dmesg`) for more details.
+"""]]
diff --git a/doc/forum/keys__44___URLs_and_URIs.mdwn b/doc/forum/keys__44___URLs_and_URIs.mdwn
new file mode 100644
index 0000000000..c83deae6ed
--- /dev/null
+++ b/doc/forum/keys__44___URLs_and_URIs.mdwn
@@ -0,0 +1 @@
+What, exactly, is the relationship between keys, URLs and URIs?  As I understand it, for each key, git-annex keeps a list of zero or more URLs/URIs from which the key's contents may be downloaded.  Is each entry in this list specific to one special remote, i.e. is this really a list of pairs (URL/URI, special-remote-uuid)? Is the record of which key is present in which remote completely independent of the record of which key may be downloaded from which remote through which URL/URI?  Is the only difference between URLs and URIs that, when a URL is added for a key, git-annex records the key as present in the web special remote, while when a URI is added, it doesn't?   (Sorry for too many questions.)
diff --git a/doc/forum/keys__44___URLs_and_URIs/comment_1_d285566ca97e720a7bb497c0db8cc0c2._comment b/doc/forum/keys__44___URLs_and_URIs/comment_1_d285566ca97e720a7bb497c0db8cc0c2._comment
new file mode 100644
index 0000000000..898f6adabc
--- /dev/null
+++ b/doc/forum/keys__44___URLs_and_URIs/comment_1_d285566ca97e720a7bb497c0db8cc0c2._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-16T14:46:40Z"
+ content="""
+The main difference is that git-annex will not try to
+download URIs itself, but will try to download URLs.
+
+Also, `git annex whereis` displays any URIs
+claimed by the remote, but not URLs unless
+the remote reponds to WHEREIS by listing them.
+
+URLs/URIs are not recorded with a particular remote
+owning them, but CLAIMURL can be used for a remote to
+claim ownership.
+
+My comment
+<http://git-annex.branchable.com/design/external_special_remote_protocol/#comment-f7b2275dc00920599a108a3e99cab4f2>
+sums it up pretty well, I thought.
+"""]]
diff --git a/doc/forum/known_and_local_annex_keys.mdwn b/doc/forum/known_and_local_annex_keys.mdwn
new file mode 100644
index 0000000000..7dcef8693e
--- /dev/null
+++ b/doc/forum/known_and_local_annex_keys.mdwn
@@ -0,0 +1,14 @@
+I have a direct repository with the assistant running (v4.20131002). The repo is in the backup group and should be grabbing every known annex file. Yet `git annex status` says:
+
+    local annex keys: 1386
+    local annex size: 94.53 gigabytes
+    known annex keys: 1387
+    known annex size: 94.53 gigabytes
+
+As you can seem there is one more known annex key than there are local ones. Neither `git annex get` nor `git annex sync` changes the numbers. According to `tree` the repo dir contains exactly 1387 files, which means that the missing file must exist on disk. 
+
+1) How do I find out which is the file in question? How do I get it synchronized? 
+
+Yesterday there were 1376 known annex keys. Today there are 1387. For some reason the number of keys went up by 11, and I would like to know how and why. The log suggests that a couple of files have been added from inside the repo directory, but I am positive that these files already existed in the annex directory yesterday, and that I ran `git annex sync` manually without the number of local and/or known keys going up.
+
+2) Why weren't the files synced before? Is there a way to find out whether they were or were not part of the annex yesterday - maybe list all files sorted by the date they were added? 
diff --git a/doc/forum/known_and_local_annex_keys/comment_1_3cb4828dc7116e4cf49e119f055ae9a3._comment b/doc/forum/known_and_local_annex_keys/comment_1_3cb4828dc7116e4cf49e119f055ae9a3._comment
new file mode 100644
index 0000000000..24a5ef03e4
--- /dev/null
+++ b/doc/forum/known_and_local_annex_keys/comment_1_3cb4828dc7116e4cf49e119f055ae9a3._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-10-28T16:56:20Z"
+ content="""
+I think you're stressing way too much about a number.
+
+It's quite possible for the known and local key counts to diverge while no data is missing. For example:
+
+<pre>
+joey@darkstar:~/tmp/test>touch foo
+joey@darkstar:~/tmp/test>touch bar
+joey@darkstar:~/tmp/test>git annex add foo bar
+
+local annex keys: 1
+known annex keys: 2
+</pre>
+
+"""]]
diff --git a/doc/forum/known_and_local_annex_keys/comment_2_68f20c881eafe986694bde10571cf1c0._comment b/doc/forum/known_and_local_annex_keys/comment_2_68f20c881eafe986694bde10571cf1c0._comment
new file mode 100644
index 0000000000..944ec9cafc
--- /dev/null
+++ b/doc/forum/known_and_local_annex_keys/comment_2_68f20c881eafe986694bde10571cf1c0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="77.247.181.165"
+ subject="comment 2"
+ date="2013-10-28T18:31:21Z"
+ content="""
+I don't think I'm stressing too much. Rather, I'm inquiring about why git-annex is giving me wrong (or at least unclear) output that makes me worry about losing data. I plan to trust git-annex with a lot of important files, and in order to do that I want to make sure it's trustworthy. And that's where the inaccurate key numbers get in the way.
+
+So why do the local and known numbers diverge anyway? Would you consider adjusting the status output to be more accurate, or at least less confusing? I just want to be able to check that every single file in the repo is being backed up.
+"""]]
diff --git a/doc/forum/known_and_local_annex_keys/comment_3_e195a7091a06ce0427bb28aca9a17d04._comment b/doc/forum/known_and_local_annex_keys/comment_3_e195a7091a06ce0427bb28aca9a17d04._comment
new file mode 100644
index 0000000000..fd9228b4f0
--- /dev/null
+++ b/doc/forum/known_and_local_annex_keys/comment_3_e195a7091a06ce0427bb28aca9a17d04._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 3"
+ date="2013-10-28T19:06:00Z"
+ content="""
+I have adjusted the labels to be more clear.
+"""]]
diff --git a/doc/forum/known_and_local_annex_keys/comment_4_d81f0bf7465832cb676fd89f5d53ec18._comment b/doc/forum/known_and_local_annex_keys/comment_4_d81f0bf7465832cb676fd89f5d53ec18._comment
new file mode 100644
index 0000000000..fccc576d30
--- /dev/null
+++ b/doc/forum/known_and_local_annex_keys/comment_4_d81f0bf7465832cb676fd89f5d53ec18._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="77.247.181.165"
+ subject="comment 4"
+ date="2013-10-28T19:24:12Z"
+ content="""
+Thanks, I'll check it out. And if you ever got around to introduce a means that can answer the above-mentioned integrity questions, that'd be really awesome.
+"""]]
diff --git a/doc/forum/largefiles__58___fail-on-unspecified_mode__63__.mdwn b/doc/forum/largefiles__58___fail-on-unspecified_mode__63__.mdwn
new file mode 100644
index 0000000000..ae2fe732b0
--- /dev/null
+++ b/doc/forum/largefiles__58___fail-on-unspecified_mode__63__.mdwn
@@ -0,0 +1,8 @@
+The imminent move of to v7 of my shared repositories (eg. family photo collection) offers a chance to simplify the workflow from differentiating between `git annex` commands and `git` commands for participants who have a hard time keeping them apart using `largefiles`. In practice, `largefiles` would be configured to always annex JPEG files, various raw formats and video data, but to never annex data like SVG files (typically collages), .pto files (Hugin's panorama files) or READMEs.
+
+I don't trust the above list to be comprehensive, and want to avoid errors in both directions (needlessly annexed files I'd actually want under regular version control, and worse yet, huge files in the hard-to-edit git history).
+
+Is there (or could there be added) a way I could set files to a "I don't know" state of largefiles (and make that the default for everything not explicitly configured), such that `git add` would rather err out than making the wrong decision?
+
+Thanks<br />
+[[chrysn]]
diff --git a/doc/forum/largefiles__58___fail-on-unspecified_mode__63__/comment_1_0bddf22d95cccf68a2852d7ef3a6dc19._comment b/doc/forum/largefiles__58___fail-on-unspecified_mode__63__/comment_1_0bddf22d95cccf68a2852d7ef3a6dc19._comment
new file mode 100644
index 0000000000..baa38ee303
--- /dev/null
+++ b/doc/forum/largefiles__58___fail-on-unspecified_mode__63__/comment_1_0bddf22d95cccf68a2852d7ef3a6dc19._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-01-16T19:11:35Z"
+ content="""
+This is a good idea, but unfortunately the interface that `git add` uses to
+run git-annex doesn't provide a way for git-annex to request that the file
+not be added. Even if git-annex exits with an error, git will assume the
+best thing to do is to add the file itself. As documented in the gitattributes(5)
+man page:
+
+           A missing filter driver definition in the config, or a filter driver that
+           exits with a non-zero status, is not an error but makes the filter a
+           no-op passthru.
+
+So this would I think need an extension to git..
+
+However, there is a fairly easy way to convert an annexed file to be stored in git
+if your annex.largefiles configuration didn't do the right thing:
+
+	touch thefile
+	git -c annex.largefiles=nothing add thefile
+"""]]
diff --git a/doc/forum/library__44___backup_and_music_player.mdwn b/doc/forum/library__44___backup_and_music_player.mdwn
new file mode 100644
index 0000000000..024899885a
--- /dev/null
+++ b/doc/forum/library__44___backup_and_music_player.mdwn
@@ -0,0 +1,11 @@
+Hello, I'm not sure on how to proceed with a fairly simple workflow. I keep my music library in a debian box with plenty of space. I run the plex media server on it so it should be a direct repository to avoid strange player behavior.
+I also perform a monthly (more or less) backup on an external hard drive. This should be simple too, just add a remote and sync.
+My problem now is: I have also a portable music player that I want to keep in sync with the music library. Not the whole music library but only a small subset. This needs to be a direct repository too (the best would be also without the .git/ folder but I don't believe it's possible). How to create a small subset of files to keep in sync with a direct repository? I've tried with branches but they are not simple to use in direct mode.
+
+So, to recap: a (direct) main repository, a standard backup repository and another (direct) repository with only a subset of files.
+
+Anyone with a similar workflow wants to share some tips?
+
+Thanks,
+
+F
diff --git a/doc/forum/library__44___backup_and_music_player/comment_1_a6e38a1678c433e5a5d96afae4ae4332._comment b/doc/forum/library__44___backup_and_music_player/comment_1_a6e38a1678c433e5a5d96afae4ae4332._comment
new file mode 100644
index 0000000000..edf4c4e6a7
--- /dev/null
+++ b/doc/forum/library__44___backup_and_music_player/comment_1_a6e38a1678c433e5a5d96afae4ae4332._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-05T15:52:30Z"
+ content="""
+Good question! I don't have a perfect solution for this, 
+because what you really probably want is to be able to `git annex copy`
+files to the music player and have only the present files show up in
+its repository.
+
+One approach is to use a [[directory_special_remote|special_remotes/directory]]
+on the music player. This way, only present files will show up there,
+but they'll have git-annex's internal filenames. If the music player
+doesn't care about filenames, this can work ok.
+
+Another approach is to use a v6 git-annex repository
+on the media player, and use [[git-annex-adjust]] to generate
+a version of a branch where all files that are present are unlocked
+(and thus regular files with the expected filenames). Files
+that are not present will still show up in the working tree though,
+either as symlinks or as the small text files git uses when a filesystem
+does not support symlinks. So this is much like direct mode, but it has
+the benefit that you can use all the normal git branching features
+to create a trimmed down branch for the media player with just the files
+you want.
+"""]]
diff --git a/doc/forum/linux_standalone_tarballs.mdwn b/doc/forum/linux_standalone_tarballs.mdwn
new file mode 100644
index 0000000000..1c6380a7d8
--- /dev/null
+++ b/doc/forum/linux_standalone_tarballs.mdwn
@@ -0,0 +1 @@
+Just saw that there is now a linux standalone tarball, I've a SL5 (RHEL5) based machine which I can churn out git-annex binaries if there is interest.
diff --git a/doc/forum/linux_standalone_tarballs/comment_1_5c3ceb845a45e50784f7098bfbf94df1._comment b/doc/forum/linux_standalone_tarballs/comment_1_5c3ceb845a45e50784f7098bfbf94df1._comment
new file mode 100644
index 0000000000..64a37f366f
--- /dev/null
+++ b/doc/forum/linux_standalone_tarballs/comment_1_5c3ceb845a45e50784f7098bfbf94df1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.149"
+ subject="comment 1"
+ date="2012-09-29T16:03:36Z"
+ content="""
+I'll be curious to see if the standalone tarball works on such a system.. it might need a newer libc
+than RHEL5 has.
+
+Conversely, that'd make it a good system to build the tarball on, so it's built to work with a nice old libc. :) 
+
+I have a machine where I could put chroots to do both 64 bit and 32 bit builds, but I don't know if I'll automate it there. Too lazy..
+"""]]
diff --git a/doc/forum/local_pairing_with_2_mac.mdwn b/doc/forum/local_pairing_with_2_mac.mdwn
new file mode 100644
index 0000000000..814ecc123f
--- /dev/null
+++ b/doc/forum/local_pairing_with_2_mac.mdwn
@@ -0,0 +1,27 @@
+Hey !
+I am trying to find ways to use git annex as a tool to share big binary files for our development projects (such as PSD files).
+Our team has artists that will not use command line tools so I have been testing git-annex assistant with a lot of hope.
+However all the tests I am doing are just failing. °.° '
+
+in this thread I would like to focus on what would seem to me as an easy first approach : local pairing.
+
+So my team and I are on mac. I am just trying to sync 2 computers on the same network. But the process is stuck on the "local pairing in process" step, just after I enter the secret phrase.
+
+I have enabled sshd (preferences -> remote login) on both computers, checked the firewall to authorize git-annex, so I am probably missing something here. 
+the logs on my computer does not say anything usefull ([2013-12-04 22:04:34 CET] main: Pairing in progress) but on the other computer I have this :
+
+git-annex: ssh-keygen failed
+[2013-12-04 22:04:33 CET] PairListener: utku@MacBook-Air-de-utku.local:~/Documents/git-test is sending a pair request.
+dyld: lazy symbol binding failed: Symbol not found: ___strlcpy_chk
+ Referenced from: /Applications/git-annex.app/Contents/MacOS/bundle/ssh-keygen
+ Expected in: /usr/lib/libSystem.B.dylib
+
+dyld: Symbol not found: ___strlcpy_chk
+ Referenced from: /Applications/git-annex.app/Contents/MacOS/bundle/ssh-keygen
+ Expected in: /usr/lib/libSystem.B.dylib
+
+git-annex: ssh-keygen failed
+
+Don't know if that helps. I don't know which info I need to provide.
+
+cheers
diff --git a/doc/forum/local_pairing_with_2_mac/comment_10_508585e72c81d197a9a1e193c25a702a._comment b/doc/forum/local_pairing_with_2_mac/comment_10_508585e72c81d197a9a1e193c25a702a._comment
new file mode 100644
index 0000000000..1d69f41fda
--- /dev/null
+++ b/doc/forum/local_pairing_with_2_mac/comment_10_508585e72c81d197a9a1e193c25a702a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnfC02DTOZygFDDvvg0maRciYYMhEIFgkw"
+ nickname="Utku"
+ subject="comment 10"
+ date="2013-12-15T09:51:28Z"
+ content="""
+unfortunately, it is not working on the computer where ssh was not working
+I click an got annex and nothing seems to open
+I try to go on the system logs but I see nothing really obvious. The only log that may be related would be : 
+15/12/13 10:46:23,230 Dock[166]: find_shared_window: WID 21425
+15/12/13 10:46:23,230 Dock[166]: CGSGetWindowTags: Invalid window 0x53b1
+
+if you tell me where to look at I can give you something more useful. 
+
+"""]]
diff --git a/doc/forum/local_pairing_with_2_mac/comment_1_6ca4fed183340a2902d1d4d91284b772._comment b/doc/forum/local_pairing_with_2_mac/comment_1_6ca4fed183340a2902d1d4d91284b772._comment
new file mode 100644
index 0000000000..25c97805b0
--- /dev/null
+++ b/doc/forum/local_pairing_with_2_mac/comment_1_6ca4fed183340a2902d1d4d91284b772._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 1"
+ date="2013-12-12T17:47:30Z"
+ content="""
+What version of OSX is the failing computer running? What version of git-annex? How did you install git-annex on it?
+"""]]
diff --git a/doc/forum/local_pairing_with_2_mac/comment_2_7c2b3d0a8a69c7056508f8ec73ebefcd._comment b/doc/forum/local_pairing_with_2_mac/comment_2_7c2b3d0a8a69c7056508f8ec73ebefcd._comment
new file mode 100644
index 0000000000..03b06e45ae
--- /dev/null
+++ b/doc/forum/local_pairing_with_2_mac/comment_2_7c2b3d0a8a69c7056508f8ec73ebefcd._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnfC02DTOZygFDDvvg0maRciYYMhEIFgkw"
+ nickname="Utku"
+ subject="comment 2"
+ date="2013-12-12T20:08:50Z"
+ content="""
+hello
+both computers are on mac os maverick
+latest version of git annex, and we used the git annex assistant dmg found on the install section...
+I am on a personnal home router so I don't think there is any port that might be blocked by a firewall for local connections...
+
+ 
+"""]]
diff --git a/doc/forum/local_pairing_with_2_mac/comment_3_07fa468aac1288e770487973052bccea._comment b/doc/forum/local_pairing_with_2_mac/comment_3_07fa468aac1288e770487973052bccea._comment
new file mode 100644
index 0000000000..bab5009f46
--- /dev/null
+++ b/doc/forum/local_pairing_with_2_mac/comment_3_07fa468aac1288e770487973052bccea._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 3"
+ date="2013-12-12T20:37:55Z"
+ content="""
+It's not a firewall or network problem, what you pasted earlier shows that the ssh-keygen command bundled in the git annex dmg is trying to use a symbol that is not present in your libSystem library.
+
+I am puzzled why ssh-keygen apparently works on one of your macs and not on the other, if they indeed both have the same build of git-annex installed.
+
+Please paste output of `otool -L /Applications/git-annex.app/Contents/MacOS/bundle/ssh-keygen` on the mac with the problem.
+"""]]
diff --git a/doc/forum/local_pairing_with_2_mac/comment_4_dc0494213d2b57b5b9a489b096a5b8d0._comment b/doc/forum/local_pairing_with_2_mac/comment_4_dc0494213d2b57b5b9a489b096a5b8d0._comment
new file mode 100644
index 0000000000..f3f25504aa
--- /dev/null
+++ b/doc/forum/local_pairing_with_2_mac/comment_4_dc0494213d2b57b5b9a489b096a5b8d0._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnfC02DTOZygFDDvvg0maRciYYMhEIFgkw"
+ nickname="Utku"
+ subject="comment 4"
+ date="2013-12-12T20:58:05Z"
+ content="""
+so as I don't really know which mac has a problem, here is what I get on both computers (looks they are quite the same): 
+
+/Applications/git-annex.app/Contents/MacOS/bundle/ssh-keygen:
+	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.0.0)
+	/System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 6.0.0)
+	/System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory (compatibility version 1.0.0, current version 1.0.0)
+	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55456.0.0)
+	@executable_path/O (compatibility version 1.0.0, current version 1.0.0)
+	@executable_path/P (compatibility version 3.0.0, current version 3.0.0)
+	@executable_path/B (compatibility version 1.0.0, current version 1.2.5)
+	@executable_path/L (compatibility version 1.0.0, current version 1.0.0)
+	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
+
+
+/Applications/git-annex.app/Contents/MacOS/bundle/ssh-keygen:
+       /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.0.0)
+       /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 6.0.0)
+       /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory (compatibility version 1.0.0, current version 1.0.0)
+       /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55456.0.0)
+       @executable_path/O (compatibility version 1.0.0, current version 1.0.0)
+       @executable_path/P (compatibility version 3.0.0, current version 3.0.0)
+       @executable_path/B (compatibility version 1.0.0, current version 1.2.5)
+       @executable_path/L (compatibility version 1.0.0, current version 1.0.0)
+       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
+"""]]
diff --git a/doc/forum/local_pairing_with_2_mac/comment_5_bcac18e137c00d4279774dec51963289._comment b/doc/forum/local_pairing_with_2_mac/comment_5_bcac18e137c00d4279774dec51963289._comment
new file mode 100644
index 0000000000..0639068661
--- /dev/null
+++ b/doc/forum/local_pairing_with_2_mac/comment_5_bcac18e137c00d4279774dec51963289._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 5"
+ date="2013-12-12T21:40:16Z"
+ content="""
+Well, I was wrong, we don't know only one of the 2 has the problem. The other one will probably not have run ssh-keygen yet.
+
+Can you run `/Applications/git-annex.app/Contents/MacOS/bundle/ssh-keygen --help` on both of them and see if it manages to print its help, or fails with an error?
+"""]]
diff --git a/doc/forum/local_pairing_with_2_mac/comment_6_76b62eafda1ecbf88abe288cbe778e17._comment b/doc/forum/local_pairing_with_2_mac/comment_6_76b62eafda1ecbf88abe288cbe778e17._comment
new file mode 100644
index 0000000000..e9cd8cc327
--- /dev/null
+++ b/doc/forum/local_pairing_with_2_mac/comment_6_76b62eafda1ecbf88abe288cbe778e17._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnfC02DTOZygFDDvvg0maRciYYMhEIFgkw"
+ nickname="Utku"
+ subject="comment 6"
+ date="2013-12-12T21:50:15Z"
+ content="""
+ok so it is ok on my computer, but here is what I got on the other one : 
+dyld: lazy symbol binding failed: Symbol not found: ___strlcpy_chk
+ Referenced from: /Applications/git-annex.app/Contents/MacOS/bundle/ssh-keygen
+ Expected in: /usr/lib/libSystem.B.dylib
+
+dyld: Symbol not found: ___strlcpy_chk
+ Referenced from: /Applications/git-annex.app/Contents/MacOS/bundle/ssh-keygen
+ Expected in: /usr/lib/libSystem.B.dylib
+
+Trace/BPT trap: 5
+"""]]
diff --git a/doc/forum/local_pairing_with_2_mac/comment_7_13fe788f2e9a823ad2e4844f114675a7._comment b/doc/forum/local_pairing_with_2_mac/comment_7_13fe788f2e9a823ad2e4844f114675a7._comment
new file mode 100644
index 0000000000..883cb4e143
--- /dev/null
+++ b/doc/forum/local_pairing_with_2_mac/comment_7_13fe788f2e9a823ad2e4844f114675a7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 7"
+ date="2013-12-12T21:53:56Z"
+ content="""
+So it does only fail on one machine and not the other. I wonder what is different?
+
+Can you also try running `/Volumes/git-annex/git-annex.app/Contents/MacOS/bundle/cp` on both? (I think it uses the same symbol.)
+"""]]
diff --git a/doc/forum/local_pairing_with_2_mac/comment_8_f81b454e9cfc14dcb33148798be55de3._comment b/doc/forum/local_pairing_with_2_mac/comment_8_f81b454e9cfc14dcb33148798be55de3._comment
new file mode 100644
index 0000000000..b4af1ce699
--- /dev/null
+++ b/doc/forum/local_pairing_with_2_mac/comment_8_f81b454e9cfc14dcb33148798be55de3._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnfC02DTOZygFDDvvg0maRciYYMhEIFgkw"
+ nickname="Utku"
+ subject="comment 8"
+ date="2013-12-12T22:03:54Z"
+ content="""
+you mean /Applications/git-annex.app/Contents/MacOS/bundle/cp ?
+
+on both computers it prints : 
+usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file target_file
+       cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file ... target_directory
+
+
+/Volumes/git-annex/git-annex.app/Contents/MacOS/bundle/cp doesn't work
+
+"""]]
diff --git a/doc/forum/local_pairing_with_2_mac/comment_9_f7a1ce9627ebfc854dfde2f6c924db80._comment b/doc/forum/local_pairing_with_2_mac/comment_9_f7a1ce9627ebfc854dfde2f6c924db80._comment
new file mode 100644
index 0000000000..deaf9b68c4
--- /dev/null
+++ b/doc/forum/local_pairing_with_2_mac/comment_9_f7a1ce9627ebfc854dfde2f6c924db80._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 9"
+ date="2013-12-13T18:52:40Z"
+ content="""
+As a workaround, I have removed ssh-keygen and ssh from the OSX DMG. AIUI, OSX ships ssh by default anyway.
+"""]]
diff --git a/doc/forum/local_subtree_and_broken_symlinks.mdwn b/doc/forum/local_subtree_and_broken_symlinks.mdwn
new file mode 100644
index 0000000000..de6dd6e491
--- /dev/null
+++ b/doc/forum/local_subtree_and_broken_symlinks.mdwn
@@ -0,0 +1,21 @@
+Here's a simple example on a repository with three branches, where we'll be adding images-annex as a subtree into master.
+
+    $ git branch
+        git-annex
+        images-annex
+      * master
+    $ git subtree add --squash --prefix=images/ images-annex
+      Added dir 'images'
+    $ ls
+      FILE_A        FILE_B        images/
+
+...checkout images-annex, make changes, commit...
+
+    $ git checkout master
+    $ git subtree pull --squash --prefix=images/ . images-annex
+      From .
+      * branch images-annex -> FETCH_HEAD
+      Merge made by the 'recursive' strategy.
+      ...(files created/modified/etc)
+
+I have tried a few different methods for merging the subtree in and so far have not been able to keep git-annex links up to date. Running `git-annex fix .` does what it's supposed to but then git sees everything as modified. Is this entirely the expected behavior because of the --prefix? I have not used subtrees much before but the model appears to be very helpful for what I'm trying to do.
diff --git a/doc/forum/local_subtree_and_broken_symlinks/comment_1_779cc4e49cb4da8aea7f5743e6257f21._comment b/doc/forum/local_subtree_and_broken_symlinks/comment_1_779cc4e49cb4da8aea7f5743e6257f21._comment
new file mode 100644
index 0000000000..e6ccb814f0
--- /dev/null
+++ b/doc/forum/local_subtree_and_broken_symlinks/comment_1_779cc4e49cb4da8aea7f5743e6257f21._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="comment 1"
+ date="2014-07-30T14:55:16Z"
+ content="""
+Known bug: [[bugs/Git_annexed_files_symlink_are_wrong_when_submodule_is_not_in_the_same_path]]
+
+I don't think there's much likelyhood of a fix though. Using direct mode probably works around the problem. Or you can use something like myrepos instead of git subtrees.
+"""]]
diff --git a/doc/forum/location_tracking_cleanup.mdwn b/doc/forum/location_tracking_cleanup.mdwn
new file mode 100644
index 0000000000..7e2e230af7
--- /dev/null
+++ b/doc/forum/location_tracking_cleanup.mdwn
@@ -0,0 +1,24 @@
+I recently started experimenting with git annex, adding files that I've had
+floating across several computers to repositories. During the testing I had
+a few occasions where I wrecked a repository somehow, and decided to wipe it
+and start anew (at this point there was no important files in them so I thought
+this is the easiest way). Well, as it turns out this interacts badly with location
+tracking, since now `git annex whereis` shows files residing in all those destroyed
+repositories, all having same names as some existing repositories. This makes it hard
+to follow whether a repo actually has a file, or was the file only seen in some dead
+repo with the same name.
+
+I planned on cleaning this up by looking up the UUIDs of the now stable, existing
+repos and untrusting all the dead copies (they should effectively disappear from
+git annex´s output then, right?), but I didn't find an easy way to look up the UUID
+of the current repository (maybe this could be included in `git annex status`?)
+I also noticed that untrust cannot remove the trust based on the UUID -- if I try
+it I simply get "there is no git remote named "11908472-...", so I guess untrust
+works with git remote names, which I find a bit confusing, since trust.log logs the
+trust levels based on the UUID. I could just write into trust.log manually, but I'm
+unsure how the changes would get propagated.
+
+What should I do? As a related wishlist item I would ask for some additional mechanisms
+for purging known-dead repositories from the location tracking database. And the ability
+to look up the UUID of the current repo, and to use the UUID to specify repositories when
+applicable (untrust and describe maybe).
diff --git a/doc/forum/location_tracking_cleanup/comment_1_7d6319e8c94dfe998af9cfcbf170efb2._comment b/doc/forum/location_tracking_cleanup/comment_1_7d6319e8c94dfe998af9cfcbf170efb2._comment
new file mode 100644
index 0000000000..8915ea3518
--- /dev/null
+++ b/doc/forum/location_tracking_cleanup/comment_1_7d6319e8c94dfe998af9cfcbf170efb2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-09-30T06:55:34Z"
+ content="""
+Specifying the UUID was supposed to work, I think I broke it a while ago. Fixed now in git.
+
+I'm not sure why you need to look up the UUID of the current repository. You can always refer to the current repository as \".\". Anyway, the UUID of the current repository is in `.git/config`, or use `git config annex.uuid`.
+"""]]
diff --git a/doc/forum/location_tracking_cleanup/comment_2_e7395cb6e01f42da72adf71ea3ebcde4._comment b/doc/forum/location_tracking_cleanup/comment_2_e7395cb6e01f42da72adf71ea3ebcde4._comment
new file mode 100644
index 0000000000..f612e53a4d
--- /dev/null
+++ b/doc/forum/location_tracking_cleanup/comment_2_e7395cb6e01f42da72adf71ea3ebcde4._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawncBlzaDI248OZGjKQMXrLVQIx4XrZrzFo"
+ nickname="Perttu"
+ subject="comment 2"
+ date="2011-09-30T11:55:35Z"
+ content="""
+Thanks for the quick reply :)
+
+I wanted to look up the UUID of the current repo so that I can find out which repo is alive from the collection of repos with the same name.
+I could have looked for it in .git/config though, since it's pretty obvious. I just looked into the git-annex branch and didn't find it there.
+Thanks for the tip about using \".\". By the way, could there be some kind of warning about using non-unique names for repos? That would make this
+scenario less likely. Or maybe that is a bad idea given the decentralized nature of git.
+
+By the way, do the trust settings propagate to other repos? If I mark some UUID as untrusted on one computer does it become globally untrusted?
+"""]]
diff --git a/doc/forum/location_tracking_cleanup/comment_3_c15428cec90e969284a5e690fb4b2fde._comment b/doc/forum/location_tracking_cleanup/comment_3_c15428cec90e969284a5e690fb4b2fde._comment
new file mode 100644
index 0000000000..c676b9b615
--- /dev/null
+++ b/doc/forum/location_tracking_cleanup/comment_3_c15428cec90e969284a5e690fb4b2fde._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-09-30T16:47:27Z"
+ content="""
+`git annex status` now includes a list of all known repositories.
+
+Yes, trust setting propigate on git push/pull like any other git-annex information.
+"""]]
diff --git a/doc/forum/locks_during_--batch_operations.mdwn b/doc/forum/locks_during_--batch_operations.mdwn
new file mode 100644
index 0000000000..360a4cb97c
--- /dev/null
+++ b/doc/forum/locks_during_--batch_operations.mdwn
@@ -0,0 +1,3 @@
+Are there locks that git-annex holds for the entirety of e.g. `git-annex-get --batch`?
+
+As part of [[forum/auto-fetching_annexed_files_on_open__40____41__]], I'd like to keep one or more long-running `git-annex-get --batch` processes and pipe the keys I need fetched as needed, rather than start a new git-annex process for each key.   But, this only makes sense if, while waiting to read more keys from stdin, git-annex is no holding locks that could interfere with other git-annex calls.
diff --git a/doc/forum/locks_during_--batch_operations/comment_1_190f6a52d9e49b2a092ad4c848e9d0b4._comment b/doc/forum/locks_during_--batch_operations/comment_1_190f6a52d9e49b2a092ad4c848e9d0b4._comment
new file mode 100644
index 0000000000..bfc05f4ac6
--- /dev/null
+++ b/doc/forum/locks_during_--batch_operations/comment_1_190f6a52d9e49b2a092ad4c848e9d0b4._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-20T21:33:35Z"
+ content="""
+No, there are not.
+
+I'd like to turn this question around. You, and others, seem to have low
+expectations of git-annex's locking and handling of concurrency. Is there a
+change to the documentation somewhere that would convey that git-annex
+handles multiple concurrent operations, without stepping on each other's
+toes, with extensive fine-grained locking at both the thread and file level?
+
+Because I keep anwering what seems like the same question, over and over.
+And I don't understand why people seem to expect the worst, it's kind of a
+downer and it's tedious to keep having to reassure people. Is it
+something I did? Is it a general expectation that concurrency is hard and
+so everything will get it wrong? Is it specifically git certianly having
+poor locking in several places notably around the index and assuming that
+git-annex will inherit it?
+"""]]
diff --git a/doc/forum/locks_during_--batch_operations/comment_2_b19ed6657064c11bf54673f1b2ff4860._comment b/doc/forum/locks_during_--batch_operations/comment_2_b19ed6657064c11bf54673f1b2ff4860._comment
new file mode 100644
index 0000000000..4cee1a00a6
--- /dev/null
+++ b/doc/forum/locks_during_--batch_operations/comment_2_b19ed6657064c11bf54673f1b2ff4860._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="locking granularity"
+ date="2020-02-20T22:35:33Z"
+ content="""
+Joey,
+
+I very much value all the work/thought you've put into making git-annex robust, starting with choosing Haskell.
+
+As to why the question keeps coming up...
+
+I often find myself wanting to use git-annex in what seems to me non-standard ways, so it's possible the usage pattern wasn't planned/optimized/tested for.
+E.g. with `git-annex-get --batch` the typical usage would be to feed a large batch of keys at once, and to not have other git-annex processes running at the time.
+The git-annex test suite [[does not test under concurrency|todo/add_tests_under_concurrency]].  I've run into intermittent failures with concurrent operations, that
+were fixed by disabling concurrency.  I'll try at some point to isolate reproducible examples of these failures, but they do happen quite consistently on my system.
+
+I understand that git-annex is parallelism-safe in that parallelism does not cause data loss.  But things short of data loss, like intermittent failures/deadlocks, are something I still need to work around, when using git-annex as a building block in larger automated workflows.
+
+"""]]
diff --git a/doc/forum/long_paths_on_windows_10_-_workaround.mdwn b/doc/forum/long_paths_on_windows_10_-_workaround.mdwn
new file mode 100644
index 0000000000..b51bcac5ce
--- /dev/null
+++ b/doc/forum/long_paths_on_windows_10_-_workaround.mdwn
@@ -0,0 +1,9 @@
+It seems git-annex has some serious problems with long paths on windows systems. I would like to suggest a possible solution and a simple workaround.
+
+## Possible solution:
+Although by default winapi functions work only with paths up to MAX_PATH, their unicode versions can work with much longer paths, provided that the paths are prefixed with "\\\\?\\". Functions defined in System.Win32.File module (e.g. moveFileEx) call the unicode versions. Solving the length limitation problem might not be as simple as prefixing all arguments with "\\\\?\\", as it does not work with relative paths. I also do not know the git-annex internals so I have no idea how easy would it be to implement, but maybe it could be an easier way than trying to limit the paths' lengths to fit in the archaic MAX_PATH limit. The MSDN page linked below has some more information.
+
+## Workaround:
+It turns out that Windows 10 supports long paths without the "\\\\?\\" prefix, but this setting is by default turned off. According to [this MSDN page](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85\).aspx#maxpath) one can enable it by setting HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled to 1 or by using the group policy editor (Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths). With default settings I was unable to "git annex get" some files in nested directories (it failed with a MoveFileEx error when moving a file from annex\tmp to annex\objects), but after I enabled the long paths option it worked!
+
+This is more of a workaround than a real solution because it requires modifying a global setting which can affect other applications. I also do not know if it solves all path problems with git-annex, but it worked for me so far. I hope this workaround will help others having similar problems.
diff --git a/doc/forum/lost_in_walkthrough.mdwn b/doc/forum/lost_in_walkthrough.mdwn
new file mode 100644
index 0000000000..89f4af0261
--- /dev/null
+++ b/doc/forum/lost_in_walkthrough.mdwn
@@ -0,0 +1,78 @@
+I'm trying to follow the steps of the "walkthrough" but I'm experiencing the following issue: when
+I sync one repository and do "git annex get ." I don't get the files from the other repository.
+Here is the transcript of the steps I followed - I've put them in a script (ga.sh) so I can replay
+them and show them on the shell while executing.
+Basically I have two repositories, "/tmp/a/annex" and "/tmp/b/annex", the second cloned from
+the first. All the other steps are the same as in the walkthrough.
+-----------------------------------
+> bash -x ga.sh 
++ cd /tmp
++ mkdir a
++ mkdir b
++ cd a
++ mkdir annex
++ cd annex
++ git init
+Initialized empty Git repository in /tmp/a/annex/.git/
++ git annex init a
+init a ok
+(Recording state in git...)
++ cd /tmp/b
++ git clone /tmp/a/annex
+Cloning into 'annex'...
+done.
+warning: remote HEAD refers to nonexistent ref, unable to checkout.
+
++ cd annex
++ git annex init b
+init b ok
+(Recording state in git...)
++ git remote add a /tmp/a/annex
++ cd /tmp/a/annex
++ git remote add b /tmp/b/annex
++ dd if=/dev/urandom of=first bs=1024 count=1
+1+0 records in
+1+0 records out
+1024 bytes (1.0 kB) copied, 9.9167e-05 s, 10.3 MB/s
++ dd if=/dev/urandom of=second bs=1024 count=1
+1+0 records in
+1+0 records out
+1024 bytes (1.0 kB) copied, 0.000241635 s, 4.2 MB/s
++ git annex add .
+add first (checksum...) ok
+add second (checksum...) ok
+(Recording state in git...)
++ git commit -am added
+[master (root-commit) 5078564] added
+ 2 files changed, 2 insertions(+)
+ create mode 120000 first
+ create mode 120000 second
++ git mv first e
++ mkdir x
++ git mv second x
++ git commit -m moved
+fix x/second ok
+(Recording state in git...)
+[master 422492d] moved
+ 3 files changed, 1 insertion(+), 1 deletion(-)
+ rename first => e (100%)
+ delete mode 120000 second
+ create mode 120000 x/second
++ cd /tmp/b/annex
++ git annex sync a
+(merging origin/git-annex into git-annex...)
+(Recording state in git...)
+commit  
+ok
+git-annex: no branch is checked out
++ git annex get .
+-------------------
+
+The last "git annex get ." does not retrieve the files in /tmp/a/annex ... why?
+I guess the issue starts when cloning /tmp/a/annex where no commit was done.
+
+Emanuele
+
+PS: I'm using git v1.7.9.5 (ubuntu 12.04) and the latest git-annex static binary
+downloaded a few minutes ago from the git-annex website.
+
diff --git a/doc/forum/lost_in_walkthrough/comment_1_51b703b961ca762f0359e1c169f1ee75._comment b/doc/forum/lost_in_walkthrough/comment_1_51b703b961ca762f0359e1c169f1ee75._comment
new file mode 100644
index 0000000000..a5c574b4a6
--- /dev/null
+++ b/doc/forum/lost_in_walkthrough/comment_1_51b703b961ca762f0359e1c169f1ee75._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-02T19:32:50Z"
+ content="""
+I have fixed `git annex sync` to work even when run in a repository with no master branch. 
+"""]]
diff --git a/doc/forum/lost_in_walkthrough/comment_2_a9de0401a103bdd4401ba2d5983dc54a._comment b/doc/forum/lost_in_walkthrough/comment_2_a9de0401a103bdd4401ba2d5983dc54a._comment
new file mode 100644
index 0000000000..4a8110eb4b
--- /dev/null
+++ b/doc/forum/lost_in_walkthrough/comment_2_a9de0401a103bdd4401ba2d5983dc54a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn2MI-Ci-bS9W5NITngsBJiL8LqWYcJ458"
+ nickname="Emanuele"
+ subject="comment 2"
+ date="2013-11-02T23:36:54Z"
+ content="""
+Great thanks! I'm glad my feedback helped improve git-annex!
+
+<https://github.com/joeyh/git-annex/commit/bc18cde32589cf53080c399e81b5680e4b>af6cef
+
+"""]]
diff --git a/doc/forum/lsof_resource_use_problems.mdwn b/doc/forum/lsof_resource_use_problems.mdwn
new file mode 100644
index 0000000000..f15b81fe92
--- /dev/null
+++ b/doc/forum/lsof_resource_use_problems.mdwn
@@ -0,0 +1,42 @@
+When the assistant runs lsof on my file system, the lsof process consumes a horrendous amount of memory (>11GB). This forces a large amount of swapping, and brings the system to its knees until the process exits. The same thing occurs when I run lsof manually, but this is currently making the assistant unusable for me. Is this normal when running lsof on a large number of files, or is something wrong with my particular setup?
+
+An example of resource usage from top, and some system details:
+
+---
+      PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
+    33735 username       1  23    0 28208M 11507M pfault  0   0:07  58.50% lsof
+---
+    [username@hostname /mnt/media]$ uname -a
+    FreeBSD hostname 9.2-RELEASE-p10 FreeBSD 9.2-RELEASE-p10 #0 r262572+4fb5adc: Wed Aug  6 17:07:16 PDT 2014     root@build3.ixsystems.com:/fusion/jkh/921/freenas/os-base/amd64/fusion/jkh/921/freenas/FreeBSD/src/sys/FREENAS.amd64  amd64
+---
+    [username@hostname /mnt/media]$ lsof -h
+    lsof 4.88
+---
+    [username@hostname /mnt/media]$ git annex info
+    repository mode: direct
+    trusted repositories: 0
+    semitrusted repositories: 1
+            d03b21fc-666d-457d-b953-0ca0ac7393d8 -- [hostname_media_indirect]
+    untrusted repositories: 2
+            00000000-0000-0000-0000-000000000001 -- web
+            31497a4d-290e-409a-9fd2-20c7340c245b -- hostname_mnt/media [here]
+    transfers in progress: none
+    available local disk space: 780.1 gigabytes (+10 gigabytes reserved)
+    local annex keys: 41576
+    local annex size: 943.95 gigabytes (+ 49 unknown size)
+    annexed files in working tree: 41887
+    size of annexed files in working tree: 945.14 gigabytes (+ 50 unknown size)
+    bloom filter size: 16 mebibytes (8.3% full)
+    backend usage:
+            SHA512E: 81518
+            WORM: 1846
+            URL: 99
+---
+    [username@hostname /mnt/media]$ git annex version
+    git-annex version: 5.20140817
+    build flags: Assistant Webapp Webapp-secure Pairing S3 WebDAV Kqueue XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
diff --git a/doc/forum/lsof_resource_use_problems/comment_1_a5e5d410545fa7f93f08936ec6aeee42._comment b/doc/forum/lsof_resource_use_problems/comment_1_a5e5d410545fa7f93f08936ec6aeee42._comment
new file mode 100644
index 0000000000..55312113e3
--- /dev/null
+++ b/doc/forum/lsof_resource_use_problems/comment_1_a5e5d410545fa7f93f08936ec6aeee42._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.111"
+ subject="comment 1"
+ date="2014-10-13T21:21:18Z"
+ content="""
+That seems very wrong.. On my linux system here, I can `lsof /` and it uses 4 kb total, and runs in 0.09 seconds, to report on 3500 open files.
+
+But, I don't know about freebsd. lsof may be more expensive there for some reason, like needing to look in kernel memory rather than in /proc perhaps? But expensive to the tune of gigabytes of space used, that must be lsof misbehaving.
+"""]]
diff --git a/doc/forum/lsof_resource_use_problems/comment_2_7b0d4109c04c47e65420105f0de3b7a2._comment b/doc/forum/lsof_resource_use_problems/comment_2_7b0d4109c04c47e65420105f0de3b7a2._comment
new file mode 100644
index 0000000000..a74832bba6
--- /dev/null
+++ b/doc/forum/lsof_resource_use_problems/comment_2_7b0d4109c04c47e65420105f0de3b7a2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmuT_R0AecWcfCFTN055N8rD_WwQkgo1PE"
+ nickname="Tomas"
+ subject="macosx 10.9.5"
+ date="2015-02-19T20:18:05Z"
+ content="""
+I have the same issue.
+"""]]
diff --git a/doc/forum/luks_encrypted_disk_support.mdwn b/doc/forum/luks_encrypted_disk_support.mdwn
new file mode 100644
index 0000000000..e2f9efc066
--- /dev/null
+++ b/doc/forum/luks_encrypted_disk_support.mdwn
@@ -0,0 +1,3 @@
+Is there a way to easily access, say, a FDE (Full Disk Encrypted) external drive using git-annex?
+
+My use case is that I do not wish to encrypt each file individually - and find it more reliable to use a real filesystem encryption on this external hard drive. --[[anarcat]]
diff --git a/doc/forum/luks_encrypted_disk_support/comment_1_0ea476c778888f34196d9031f72b1844._comment b/doc/forum/luks_encrypted_disk_support/comment_1_0ea476c778888f34196d9031f72b1844._comment
new file mode 100644
index 0000000000..9fda6b324f
--- /dev/null
+++ b/doc/forum/luks_encrypted_disk_support/comment_1_0ea476c778888f34196d9031f72b1844._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2013-12-29T17:53:39Z"
+ content="""
+Mount the drive and put a git repository or directory special remote on it.
+
+(This question seems to easy.. am I missing something?)
+"""]]
diff --git a/doc/forum/luks_encrypted_disk_support/comment_2_0af149bfe1868dde0a132c5d835c50df._comment b/doc/forum/luks_encrypted_disk_support/comment_2_0af149bfe1868dde0a132c5d835c50df._comment
new file mode 100644
index 0000000000..9170502f27
--- /dev/null
+++ b/doc/forum/luks_encrypted_disk_support/comment_2_0af149bfe1868dde0a132c5d835c50df._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="2001:1928:1:9::1"
+ subject="comment 2"
+ date="2013-12-30T17:44:33Z"
+ content="""
+I guess this is related to [[confused about external drives]] - I would have liked the assistant to propose using the full drive for storing stuff, as opposed to encrypting data with GPG, including prompting me for the crypto password.
+"""]]
diff --git a/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move.mdwn b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move.mdwn
new file mode 100644
index 0000000000..a8e78b7ccc
--- /dev/null
+++ b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move.mdwn
@@ -0,0 +1,3 @@
+Is there a way to make fsck only display corrupted files instead of move them to the internal /bad folder? 
+
+Especially since the -q option (to only print corrupted files) doesn't even print the filename, only that *a* file has been moved...it seems a bit aggressive to compulsorily move a file to some obfuscated name AND not indicate its original location anywhere...
diff --git a/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_1_018cb2fd618a448088d9e91e4872333d._comment b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_1_018cb2fd618a448088d9e91e4872333d._comment
new file mode 100644
index 0000000000..7220c49463
--- /dev/null
+++ b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_1_018cb2fd618a448088d9e91e4872333d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-08T18:58:19Z"
+ content="""
+I've made fsck -q include the name of the file in that warning message.
+
+Note that, given any file in `.git/annex/bad`, you can find the files
+in the git repository that linked to it, by running 
+`git log --stat -S$filename`
+"""]]
diff --git a/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_2_fdfd1d1ded3fb98a83f2593605250a87._comment b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_2_fdfd1d1ded3fb98a83f2593605250a87._comment
new file mode 100644
index 0000000000..d920d0607d
--- /dev/null
+++ b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_2_fdfd1d1ded3fb98a83f2593605250a87._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="archimedes"
+ avatar="http://cdn.libravatar.org/avatar/5b2ed40aabedcb1b8c2c0ce69f55a1e1"
+ subject="comment 2"
+ date="2017-03-08T22:34:59Z"
+ content="""
+Do you mean \"made\"==\"updated\" or made==\"already exists\"?
+
+Maybe I have an old version (installed via brew)...
+
+I get: 
+
+~/s/a/annex8 git:master ❯❯❯ git annex fsck -q
+  Bad file size (1 B smaller); moved to .git/annex/bad/<long_hash>
+git-annex: fsck: 1 failed
+
+unless there are no other copies, in which case the original filename it is printed on a new line with the \"No known copies\" warning. 
+
+My use-case is for images - a small amount of corruption to some old images might not be visually perceptible, and hence tolerable, especially if I'm short-sighted enough to only have 1 copy. 
+I mean its possible for the user to navigate to /bad, visually inspect that they're ok with a corrupted image, parse the git log --stat message and restore it. 
+But it seems beneficial to have something like a rsync-like \"--dryrun\" option for fsck.
+"""]]
diff --git a/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_3_369daddf95ab43f2c3d6b81c35810c19._comment b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_3_369daddf95ab43f2c3d6b81c35810c19._comment
new file mode 100644
index 0000000000..6ee28f5d93
--- /dev/null
+++ b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_3_369daddf95ab43f2c3d6b81c35810c19._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="archimedes"
+ avatar="http://cdn.libravatar.org/avatar/5b2ed40aabedcb1b8c2c0ce69f55a1e1"
+ subject="comment 3"
+ date="2017-03-08T22:36:14Z"
+ content="""
+Apologies for editing, forgot it was markdown.
+"""]]
diff --git a/doc/forum/make_a_snapshot_backup_into_a___34__remote__34__.mdwn b/doc/forum/make_a_snapshot_backup_into_a___34__remote__34__.mdwn
new file mode 100644
index 0000000000..76d87c1aad
--- /dev/null
+++ b/doc/forum/make_a_snapshot_backup_into_a___34__remote__34__.mdwn
@@ -0,0 +1,13 @@
+I use BTRFS, so have CoW and snapshots of the entire system which I transfer regularly to a backup box.
+Before dropping some content in the "working" instance of the repository, I thought to note availability of the keys in some backup snapshot(s) on a backup server.
+The difficulty is that those all would have the same git-annex UUID (since they are snapshots of the same "working one"), and internally git-annex would have availability marked based on that UUID so I guess that would not work as is.
+
+So I am thinking (didn't try) to do the following dance:
+
+- make a "read-write" copy of the entire backup snapshot
+- `git annex init` the backup copy inthat snapshot to cause regeneration of UUID
+- run `git annex fsck` so git-annex annotates availability of those keys with that new UUID
+- make read-only snapshot of the read-write snapshot
+- add that read-only snapshot host:/path as a remote to the "working" instance.
+
+Would that be "optimal" way or may be there is some feature of git-annex which would allow me to avoid the dance?
diff --git a/doc/forum/make_a_snapshot_backup_into_a___34__remote__34__/comment_1_4974480f1c75152a05c2305d21ed1842._comment b/doc/forum/make_a_snapshot_backup_into_a___34__remote__34__/comment_1_4974480f1c75152a05c2305d21ed1842._comment
new file mode 100644
index 0000000000..5bf23e40ac
--- /dev/null
+++ b/doc/forum/make_a_snapshot_backup_into_a___34__remote__34__/comment_1_4974480f1c75152a05c2305d21ed1842._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-05-19T18:51:06Z"
+ content="""
+Is it possible to mount the snapshot and edit it? If so, you could skip
+making the CoW copy of it, and just go into it, unset annex.uuid and
+`git-annex init`. Then proceed with the fsck etc.
+
+There's no way around needing to fsck, it needs to update its location
+tracking logs for the new uuid, and fsck is as good a tool as any.
+(Obviously --fast can be used.)
+"""]]
diff --git a/doc/forum/make_a_snapshot_backup_into_a___34__remote__34__/comment_2_e18fba58bcd5259125e6e36194234136._comment b/doc/forum/make_a_snapshot_backup_into_a___34__remote__34__/comment_2_e18fba58bcd5259125e6e36194234136._comment
new file mode 100644
index 0000000000..4e9431ea99
--- /dev/null
+++ b/doc/forum/make_a_snapshot_backup_into_a___34__remote__34__/comment_2_e18fba58bcd5259125e6e36194234136._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2023-05-19T19:06:00Z"
+ content="""
+> Is it possible to mount the snapshot and edit it?
+
+may be, but I better make (it is cheap) an snapshot of the snapshot with some explicit annotation (e.g. `-4shub-gitannex` suffix) before introducing any changes: after all snapshots are backups and better stay identical to the origin.  But gotcha overall -- thank you, will proceed per above plan
+"""]]
diff --git a/doc/forum/making_good_use_of_my_shiny_new_rsync.net_account.mdwn b/doc/forum/making_good_use_of_my_shiny_new_rsync.net_account.mdwn
new file mode 100644
index 0000000000..aef5a58a78
--- /dev/null
+++ b/doc/forum/making_good_use_of_my_shiny_new_rsync.net_account.mdwn
@@ -0,0 +1,20 @@
+So I got a shiny new rsync.net account, but it's not (yet) big enough for my bloated, kitchen-sink annex.  How do I make the best use of it?   Well, on the whole small files are more valuable to me than large.  Large files are usually replaceable, like ripped DVDs.  Small files are more likely to be family photos and such.  So I shut down the assistant, and I've been doing a series of these:
+
+    git annex copy --to=rsyncnet --smallerthan 10M --not --in=rsyncnet # I called my remote "rsyncnet"
+    
+    git annex copy --to=rsyncnet --smallerthan 20M --not --in=rsyncnet
+    
+    git annex copy --to=rsyncnet --smallerthan 40M --not --in=rsyncnet
+
+until the repo fills up.  With a few of these thrown in to check on my progress and what's ahead.
+
+
+    git annex status . --in=rsyncnet  # how much have I already done?
+    git annex status . --smallerthan 40M --not --in=rsyncnet # how much will this next command copy?
+
+
+It'd be possible to write a script to do all this automagically but at least this time it's easier to do by hand.
+
+Just sharing in case anybody's in a similar situation.
+
+(You could let the assistant do this for you if you configured a preferred content expression designating small files for the rsyncnet remote, of course.)
diff --git a/doc/forum/making_good_use_of_my_shiny_new_rsync.net_account/comment_1_0ebe509b768d46081db2100f5b712ef7._comment b/doc/forum/making_good_use_of_my_shiny_new_rsync.net_account/comment_1_0ebe509b768d46081db2100f5b712ef7._comment
new file mode 100644
index 0000000000..617c87d972
--- /dev/null
+++ b/doc/forum/making_good_use_of_my_shiny_new_rsync.net_account/comment_1_0ebe509b768d46081db2100f5b712ef7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 1"
+ date="2013-07-26T16:16:04Z"
+ content="""
+How about
+
+    git annex find . --format='${bytesize} ${file}\n' |sort -n|sed 's/[0-9]* //'|while read file; do git annex copy \"$file\" --to=your_remote; done
+"""]]
diff --git a/doc/forum/making_good_use_of_my_shiny_new_rsync.net_account/comment_2_ef63d893531d93d2eb09f48f8baff4dd._comment b/doc/forum/making_good_use_of_my_shiny_new_rsync.net_account/comment_2_ef63d893531d93d2eb09f48f8baff4dd._comment
new file mode 100644
index 0000000000..229a2dda99
--- /dev/null
+++ b/doc/forum/making_good_use_of_my_shiny_new_rsync.net_account/comment_2_ef63d893531d93d2eb09f48f8baff4dd._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 2"
+ date="2013-07-26T16:44:35Z"
+ content="""
+Note that you don't need to shut down the assistant; you can run multiple git-annex commands simulantaneously safely.
+You will probably want to set that repository to be in the manual group in the assistant though.
+
+Another way to do it is to make rsync.net a small archive, and move or copy your important files into `archive` directories.
+
+You can also set up multiple remotes using the same rsync.net account. So you could have a transfer remote that's used to ship files between clients, as well as your archive remote.
+"""]]
diff --git a/doc/forum/man_pages_in_the_prebuilt_linux_tarball.mdwn b/doc/forum/man_pages_in_the_prebuilt_linux_tarball.mdwn
new file mode 100644
index 0000000000..045dccb822
--- /dev/null
+++ b/doc/forum/man_pages_in_the_prebuilt_linux_tarball.mdwn
@@ -0,0 +1 @@
+Is there an easy way for a noob to get the man pages, after installing the prebuilt tarball?
diff --git a/doc/forum/man_pages_in_the_prebuilt_linux_tarball/comment_1_a7bc2e84e6d7c0e2de5900685207af78._comment b/doc/forum/man_pages_in_the_prebuilt_linux_tarball/comment_1_a7bc2e84e6d7c0e2de5900685207af78._comment
new file mode 100644
index 0000000000..01f0109e31
--- /dev/null
+++ b/doc/forum/man_pages_in_the_prebuilt_linux_tarball/comment_1_a7bc2e84e6d7c0e2de5900685207af78._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 1"
+ date="2012-11-27T20:27:37Z"
+ content="""
+Yes, go to http://git-annex.branchable.com/git-annex/ and http://git-annex.branchable.com/git-annex-shell/
+
+"""]]
diff --git a/doc/forum/manage_repository_connection_between_external_HDD_and_server.mdwn b/doc/forum/manage_repository_connection_between_external_HDD_and_server.mdwn
new file mode 100644
index 0000000000..d5d49e9e88
--- /dev/null
+++ b/doc/forum/manage_repository_connection_between_external_HDD_and_server.mdwn
@@ -0,0 +1,32 @@
+I have one server, two computers, and one external HDD.
+
+The git-annex repo on my server (`nhost`) has the following remotes:
+
+```
+qhost	qhost:NIdata (fetch)
+qhost	qhost:NIdata (push)
+zhost	zhost:NIdata (fetch)
+zhost	zhost:NIdata (push)
+```
+
+The repo on `zhost` has the following remotes:
+
+```
+data0	/run/media/mee/data0/NIdata/ (fetch)
+data0	/run/media/mee/data0/NIdata/ (push)
+nhost	nhost:NIdata (fetch)
+nhost	nhost:NIdata (push)
+```
+
+The repo on my HDD (`data0`) has thefollowing remotes:
+
+```
+nhost		nhost:NIdata (fetch)
+nhost		nhost:NIdata (push)
+qhost		/qhost/home/mee/NIdata/ (fetch)
+qhost		/qhost/home/mee/NIdata/ (push)
+zhost		/zhost/home/mee/NIdata/ (fetch)
+zhost		/zhost/home/mee/NIdata/ (push)
+```
+
+Any ideas how I can set up a remote from `nhost` to `data0`, without making the identity of data0 dependent on which machine I am using on each particular session?
diff --git a/doc/forum/manage_repository_connection_between_external_HDD_and_server/comment_1_ba8ed548bf228a7d1c82b68283f99a5b._comment b/doc/forum/manage_repository_connection_between_external_HDD_and_server/comment_1_ba8ed548bf228a7d1c82b68283f99a5b._comment
new file mode 100644
index 0000000000..bbb509f640
--- /dev/null
+++ b/doc/forum/manage_repository_connection_between_external_HDD_and_server/comment_1_ba8ed548bf228a7d1c82b68283f99a5b._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-21T20:06:28Z"
+ content="""
+I'm not entirely sure I understand the question, but think you're
+probably trying to make nhost be able to access data0 independant
+of whether the external HDD is plugged into nhost or zhost
+(or perhaps qhost, whatever that is?)
+
+The way to do that is simply to set up one remote for each place
+the HDD can be plugged into. If the HDD can be plugged in locally,
+make a remote pointing at the local mount point. If the HDD can be
+plugged into zhost, make a remote pointing at
+zhost:/run/media/mee/data0/NIdata/ and so on.
+
+git-annex will figure out that these different remotes are pointing
+at the same repository. When running `git annex get` or `git annex sync
+--content`, it will check if the HDD is mounted locally,
+and will use it there if so; if not it will fall back to trying
+to access it via the remotes that use zhost etc.
+
+So in summary, git-annex is designed to just work in this kind of scenario.
+Set up lots of remotes and let it figure out which ones to use.
+"""]]
diff --git a/doc/forum/managing_git-annex_with_java.mdwn b/doc/forum/managing_git-annex_with_java.mdwn
new file mode 100644
index 0000000000..3356f714ba
--- /dev/null
+++ b/doc/forum/managing_git-annex_with_java.mdwn
@@ -0,0 +1,11 @@
+Hi,
+
+Our need is to create a JAVA application under Windows that manages programmatically the synchronisation of a local directory structure from a remote directory on a Linux machine:
+- locally the user may choose the content of the remote directory to synchronise
+- then the application is able to synchronize ths content on demand or on a regular basis
+
+Can git-annex + git a soluton that answer those requirements ?
+Does git-annex expose an API callable from JAVA ?
+
+Thank you in advance,
+Regards
diff --git a/doc/forum/managing_git-annex_with_java/comment_1_fd12f0d0727b5bdddef1d7ef6236fe57._comment b/doc/forum/managing_git-annex_with_java/comment_1_fd12f0d0727b5bdddef1d7ef6236fe57._comment
new file mode 100644
index 0000000000..91d758920d
--- /dev/null
+++ b/doc/forum/managing_git-annex_with_java/comment_1_fd12f0d0727b5bdddef1d7ef6236fe57._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-05T16:28:01Z"
+ content="""
+git-annex exposes an extensive traditional command line interface,
+very much like the interface exposed by git.
+
+I presume that java can, perhaps with some difficulty, use such an
+interface.
+"""]]
diff --git a/doc/forum/managing_multiple_repositories.mdwn b/doc/forum/managing_multiple_repositories.mdwn
new file mode 100644
index 0000000000..7450b42710
--- /dev/null
+++ b/doc/forum/managing_multiple_repositories.mdwn
@@ -0,0 +1,3 @@
+I tried about 2 weeks ago using the assistant to create on my netbook and my home laptop 3 repositores, for music, pictures and documents.  Since I was also going to be away from home, I set up jabber pairing and box.com for a transfer repository, and then watched everything crash as I didn't know yet about jabber only really working for 1 repository at a time.
+
+So my new idea is this: one repository at ~/annex, and changing documents, music and pictures to be symlinks to actual documents, music and pictures folders inside ~/annex, allowing me to have just 1 annex to manage.  Is this the best way to put everything together if I want to just jabber pairing (and just 1 jabber account)?
diff --git a/doc/forum/manual_update_of_.git__47__annex__47__objects.mdwn b/doc/forum/manual_update_of_.git__47__annex__47__objects.mdwn
new file mode 100644
index 0000000000..9de5779c12
--- /dev/null
+++ b/doc/forum/manual_update_of_.git__47__annex__47__objects.mdwn
@@ -0,0 +1,8 @@
+Let's suppose that I've manually modified files in .git/annex/objects,
+for example I ran an rsync or some other file synchronization software
+to copy files. As a result, some objects have disappeared, others have
+appeared. After that `git annex whereis .' displays stale information,
+it doesn't take the manual modifications to accound. `git annex fsck'
+seems to fix this, but it runs the rehashing of all new files, so it's
+slow. Is there a fast alternative, which notices all the object file
+changes, trusts them, and just updates .git/annex/index quickly?
diff --git a/doc/forum/manual_update_of_.git__47__annex__47__objects/comment_1_ea6ec91150c8962e2711631f2422bf3a._comment b/doc/forum/manual_update_of_.git__47__annex__47__objects/comment_1_ea6ec91150c8962e2711631f2422bf3a._comment
new file mode 100644
index 0000000000..f721e21a59
--- /dev/null
+++ b/doc/forum/manual_update_of_.git__47__annex__47__objects/comment_1_ea6ec91150c8962e2711631f2422bf3a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.51"
+ subject="comment 1"
+ date="2013-09-12T17:11:41Z"
+ content="""
+I do not recommend manually messing with the contents of .git/annex/objects. It is a good way to lose data.
+
+If you look at the documentation for fsck in git-annex's man page, you will find the answer to your question.
+"""]]
diff --git a/doc/forum/manual_update_of_.git__47__annex__47__objects/comment_2_a7bbf304b26650a786e358bdc01e3069._comment b/doc/forum/manual_update_of_.git__47__annex__47__objects/comment_2_a7bbf304b26650a786e358bdc01e3069._comment
new file mode 100644
index 0000000000..5468ed3d06
--- /dev/null
+++ b/doc/forum/manual_update_of_.git__47__annex__47__objects/comment_2_a7bbf304b26650a786e358bdc01e3069._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="rasmus"
+ ip="109.201.154.177"
+ subject="But how to clean this folder?"
+ date="2014-03-20T21:55:26Z"
+ content="""
+Joey,
+
+I have sometimes experienced that there is way too much content in the `.git/annex/objects` folder.  For instance, my terminal emulator recently crashed during a sync which seemed to create a lot of folders.  
+
+In the annex repo where this happened I now got way too many folders (annex sometimes complain about no. of inodes or something like that) and I don't know how to clean it correctly.
+
+Here's a \"screenshot\":
+
+    [doc.annex] $ ls -a
+    .  ..  documents  .git  .gitignore
+    [doc.annex] $ find . -type d | wc -l
+    38568
+    [doc.annex] $ git annex fsck  > /dev/null 2>&1
+    [doc.annex] $ find . -type d | wc -l
+    38568
+    [doc.annex] $ git annex repair  > /dev/null 2>&1
+    [doc.annex] $ find . -type d | wc -l
+    38568
+    [doc.annex] $ find documents -type d | wc -l
+    1513
+    [doc.annex] $ find .git/annex/objects -type d | wc -l
+    36712
+
+This is a `direct`-mode repo.  With `.git/objectcts` I can use `git gc`.  How can I tell annex to tidy up?  I have tried `fsck`, `repair` and `forget`.
+
+Any hints on how to deal with this?  Other than manually clean up by deleting `.git/annex/objects` and rerunning `fsck`?
+"""]]
diff --git a/doc/forum/manual_update_of_.git__47__annex__47__objects/comment_3_a855096b683c4c4f84e72c797e065d59._comment b/doc/forum/manual_update_of_.git__47__annex__47__objects/comment_3_a855096b683c4c4f84e72c797e065d59._comment
new file mode 100644
index 0000000000..2271e04ffe
--- /dev/null
+++ b/doc/forum/manual_update_of_.git__47__annex__47__objects/comment_3_a855096b683c4c4f84e72c797e065d59._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.41"
+ subject="comment 3"
+ date="2014-03-26T19:09:07Z"
+ content="""
+1. This followup question seems to have nothing to do with the original question. (The aswer to the original question was `git annex fsck --fast`.)
+2. I find it hard to believe that a crashing terminal emulator will create a lot of folders.
+3. You show 36k subdirectories in .git/annex/objects. If I make a *tiny* 100 mb ext2 filesystem, it has 26k inodes. A 200 mb filesystem has 50k. So we're talking about a number of directories that is only large when using hardware from 1996.
+
+I'm not convinced yet that anything is wrong, or that there's anything you can do to improve matters. In any case, see [[todo/wishlist:_pack_metadata_in_direct_mode]].
+"""]]
diff --git a/doc/forum/many_remotes.mdwn b/doc/forum/many_remotes.mdwn
new file mode 100644
index 0000000000..4e463cb3c3
--- /dev/null
+++ b/doc/forum/many_remotes.mdwn
@@ -0,0 +1,24 @@
+Thanks Joey for the great work.
+
+I'm using git annex for my tv-shows and movies Folder.
+
+I have 3 USB HDD (ext.150Gb,ext.200Gb, ext.2Tb) and a USB Stick (ATV), which are traveling between 3 Devices
+
+2 Notebooks (Lappi,Kiste) and a Nas.
+
+First of all, I'm made a mistake and mixed the remote Locations from the tvshows folder with the movies folder and did a git annex sync, ( this happened about two weeks ago) 
+I think i can't undo this, only unannex will help.
+
+I've now watched the annex status output and noticed that there are many Remotes, some of them have a timestamp as name.
+
+see log file at http://pastebin.com/79bRVkK6
+
+Running git annex on ubuntu 12.04
+
+    christian@Lappi:~/Serien$ git annex version
+    git-annex version: 4.20130417
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3 4
+    upgrade supported from repository versions: 0 1 2
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS
diff --git a/doc/forum/mesh_configurations.mdwn b/doc/forum/mesh_configurations.mdwn
new file mode 100644
index 0000000000..c3904f4280
--- /dev/null
+++ b/doc/forum/mesh_configurations.mdwn
@@ -0,0 +1,181 @@
+I have a setup where a *source* repository `a` is connected to a *source* repository `b` (through SSH) which is then connected to  *backup* repository `c` (on amazon S3). I was expecting a file added on `a` to be moved to `c` *through* `b`, but that doesn't seem to be happening...
+
+I tried to reproduce with this basic setup:
+
+<pre>
+[1009]anarcat@angela:g-a$ git init a
+Dépôt Git vide initialisé dans /home/anarcat/test/g-a/a/.git/
+[1010]anarcat@angela:g-a$ git init b
+Dépôt Git vide initialisé dans /home/anarcat/test/g-a/b/.git/
+[1011]anarcat@angela:g-a$ git init c
+Dépôt Git vide initialisé dans /home/anarcat/test/g-a/c/.git/
+[1012]anarcat@angela:g-a$ cd a/
+[1013]anarcat@angela:a$ git annex init
+init  ok
+(Recording state in git...)
+[1014]anarcat@angela:a$ git annex group . source
+group . ok
+(Recording state in git...)
+[1015]anarcat@angela:a$ git annex wanted . groupwanted
+wanted . ok
+(Recording state in git...)
+[1036]anarcat@angela:a$ git remote add origin ../b
+[1016]anarcat@angela:a$ cd ../b
+[1025]anarcat@angela:b$ git annex init
+init  ok
+(Recording state in git...)
+[1026]anarcat@angela:b$ git annex group . source
+group . ok
+(Recording state in git...)
+[1027]anarcat@angela:b$ git annex wanted . groupwanted
+wanted . ok
+(Recording state in git...)
+[1038]anarcat@angela:b$ git remote add origin ../c
+[1019]anarcat@angela:b$ cd ../c
+[1021]anarcat@angela:c$ git annex init
+init  ok
+(Recording state in git...)
+[1022]anarcat@angela:c$ git annex group . backup
+group . ok
+(Recording state in git...)
+[1023]anarcat@angela:c$ git annex wanted . groupwanted
+wanted . ok
+(Recording state in git...)
+anarcat@angela:c$ cd ../a
+[1041]anarcat@angela:a$ git annex sync
+commit  ok
+pull origin
+warning: no common commits
+remote: Décompte des objets: 11, fait.
+remote: Compression des objets: 100% (9/9), fait.
+remote: Total 11 (delta 1), reused 0 (delta 0)
+Dépaquetage des objets: 100% (11/11), fait.
+Depuis ../b
+ * [nouvelle branche] git-annex  -> origin/git-annex
+
+merge: refs/remotes/origin/master - not something we can merge
+
+merge: refs/remotes/origin/synced/master - not something we can merge
+failed
+(merging origin/git-annex into git-annex...)
+(Recording state in git...)
+(Recording state in git...)
+git-annex: sync: 1 failed
+[1042]anarcat@angela:a1$ cd ../b
+[1043]anarcat@angela:b$ git annex sync
+commit  ok
+pull origin
+warning: no common commits
+remote: Décompte des objets: 11, fait.
+remote: Compression des objets: 100% (9/9), fait.
+remote: Total 11 (delta 1), reused 0 (delta 0)
+Dépaquetage des objets: 100% (11/11), fait.
+Depuis ../c
+ * [nouvelle branche] git-annex  -> origin/git-annex
+
+merge: refs/remotes/origin/master - not something we can merge
+
+merge: refs/remotes/origin/synced/master - not something we can merge
+failed
+(merging origin/git-annex into git-annex...)
+(Recording state in git...)
+(Recording state in git...)
+git-annex: sync: 1 failed
+[1063]anarcat@angela:b$ touch bar
+[1064]anarcat@angela:b$ ls
+bar
+[1065]anarcat@angela:b$ ls -al
+total 16K
+drwxr-xr-x 3 anarcat anarcat 4096 aoû 18 14:41 .
+drwxr-xr-x 5 anarcat anarcat 4096 aoû 18 14:33 ..
+lrwxrwxrwx 1 anarcat anarcat  178 aoû 18 14:41 bar -> .git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+drwxr-xr-x 9 anarcat anarcat 4096 aoû 18 14:41 .git
+[1066]anarcat@angela:b$ git annex sync
+commit  ok
+pull origin
+ok
+push origin
+Décompte des objets: 26, fait.
+Delta compression using up to 2 threads.
+Compression des objets: 100% (22/22), fait.
+Écriture des objets: 100% (26/26), 2.47 KiB | 0 bytes/s, fait.
+Total 26 (delta 5), reused 0 (delta 0)
+To ../c
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+ok
+[1067]anarcat@angela:b$ cd ../a
+[1068]anarcat@angela:a$ git annex sync
+commit  ok
+pull origin
+remote: Décompte des objets: 8, fait.
+remote: Compression des objets: 100% (6/6), fait.
+remote: Total 8 (delta 1), reused 0 (delta 0)
+Dépaquetage des objets: 100% (8/8), fait.
+Depuis ../b
+   5d3090f..9e345e6  git-annex  -> origin/git-annex
+ * [nouvelle branche] master     -> origin/master
+ * [nouvelle branche] synced/master -> origin/synced/master
+
+Merge made by the 'recursive' strategy.
+ bar | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 bar
+
+Already up-to-date.
+ok
+(merging origin/git-annex into git-annex...)
+(Recording state in git...)
+(Recording state in git...)
+push origin
+Décompte des objets: 41, fait.
+Delta compression using up to 2 threads.
+Compression des objets: 100% (36/36), fait.
+Écriture des objets: 100% (41/41), 3.50 KiB | 0 bytes/s, fait.
+Total 41 (delta 20), reused 0 (delta 0)
+To ../b
+   6019ab8..368ca15  master -> synced/master
+ * [new branch]      git-annex -> synced/git-annex
+ok
+[1069]anarcat@angela:a$ touch quu^C
+[1069]anarcat@angela:a130$ echo foo > quux
+[1070]anarcat@angela:a$ cd ../b
+[1071]anarcat@angela:b$ ls
+bar  foo
+[1072]anarcat@angela:b$ cd ..
+[1073]anarcat@angela:g-a$ cd a
+[1074]anarcat@angela:a$ git annex list
+here
+|origin
+||web
+|||
+XX_ bar
+XX_ foo
+X__ quux
+[1075]anarcat@angela:a$ git annex list --help
+git-annex: unrecognized option `--help'
+
+Usage: git-annex list [PATH ...] [option ...]
+    --allrepos  show all repositories, not only remotes
+
+To see additional options common to all commands, run: git annex help options
+
+
+[1076]anarcat@angela:a1$ git annex list --allrepos
+here-
+|origin
+||web
+|||anarcat@angela:~/test/g-a/c
+||||
+XX__ bar
+XX__ foo
+X___ quux
+</pre>
+
+why don't the files get copied over to the backup repo by the assistant?
+
+i somewhat understand that files don't get sent from `a` to `b`, but why doesn't the assistant copy the files from `b` to `c`?
+
+i have tried using `required` instead of `wanted` and it doesn't work much better.
+
+tested with `5.20150610+gitg608172f-1~ndall+1` (prod) and `5.20141125` (the above test). --[[anarcat]]
diff --git a/doc/forum/mesh_configurations/comment_10_dc99216ee2fc0bd3d43234915a0305ab._comment b/doc/forum/mesh_configurations/comment_10_dc99216ee2fc0bd3d43234915a0305ab._comment
new file mode 100644
index 0000000000..64e98f70cc
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_10_dc99216ee2fc0bd3d43234915a0305ab._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2015-09-21T18:44:20Z"
+ content="""
+I'm not comfortable making core.sharedrepository settings affect creds
+files. You don't normally want to give out S3 creds to other users in a
+unix group. And in the "everybody" case, it certianly seems entirely wrong
+to make the creds files world-readable. Willing to live with a little
+inconsistency here in order to not blow user's bank accounts off. It would
+be good to document it somewhere.
+
+Your paste seems to show A as being in the "sourcethis" group, not the
+"source" group. I don't know what that means.
+
+The assistant should notice config changes to the git-annex branch within
+60 seconds of them being received. Syncs happen when changes are detected,
+or every 30 minutes.
+"""]]
diff --git a/doc/forum/mesh_configurations/comment_1_0712fa3d50ca6092bd7d98c945b5cc31._comment b/doc/forum/mesh_configurations/comment_1_0712fa3d50ca6092bd7d98c945b5cc31._comment
new file mode 100644
index 0000000000..a97ade40dc
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_1_0712fa3d50ca6092bd7d98c945b5cc31._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-19T16:40:16Z"
+ content="""
+It's easy to see why a file is not copied from source repo A to source repo
+B: The preferred content expression for a source repo is "not (copies=1)",
+so a source repo will not want to get any files from any other repo.
+
+You probably want to make the central repo use transfer; that's basically
+what it's for. Note that a transfer repo hangs onto file content until it
+reaches all client repos. So you might want to change the preferred content
+expression to refer to backup repos. Something as simple as this might
+work:
+
+	not inallgroup=backup
+
+I don't see any reason why a file wouldn't move from B to backup repo C,
+but I don't see anything in your transcript that shows that not happening
+either. Your transcript doesn't actually show running any git-annex commands
+that move file contents at all; no git annex copy/move, and the sync is not
+run with --content...
+"""]]
diff --git a/doc/forum/mesh_configurations/comment_2_0d9ba4017343475a96975145c9db29c5._comment b/doc/forum/mesh_configurations/comment_2_0d9ba4017343475a96975145c9db29c5._comment
new file mode 100644
index 0000000000..9296cf7195
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_2_0d9ba4017343475a96975145c9db29c5._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="clarifications"
+ date="2015-08-19T16:57:49Z"
+ content="""
+the assistant is runnin on repos a and b. i was expecting it to move the files automatically.
+
+about repo groups, if i understand correctly, it should be:
+
+* `a`: *source*
+* `b`: *transfer* (or *not inallgroup=backup*?)
+* `c`: *backup*
+
+is that correct?
+"""]]
diff --git a/doc/forum/mesh_configurations/comment_3_d228158cf00cd04dc9ef5602acebdaac._comment b/doc/forum/mesh_configurations/comment_3_d228158cf00cd04dc9ef5602acebdaac._comment
new file mode 100644
index 0000000000..47774576b6
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_3_d228158cf00cd04dc9ef5602acebdaac._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-08-19T17:04:30Z"
+ content="""
+Your transcript doesn't show the assistant running. It's not clear that, in
+your live deployment, any files ever got to repo B for the assistant there
+to deal with.
+
+Repos such as B need a preferred content expression like the one I gave. It
+doesn't matter a whole lot what group is used for them; overriding the
+groupwanted for the transfer group to use that expression would be one way
+to do it.
+"""]]
diff --git a/doc/forum/mesh_configurations/comment_4_d5c8e99cadf976434460d6d0f410136e._comment b/doc/forum/mesh_configurations/comment_4_d5c8e99cadf976434460d6d0f410136e._comment
new file mode 100644
index 0000000000..39446c78d1
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_4_d5c8e99cadf976434460d6d0f410136e._comment
@@ -0,0 +1,282 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 4"
+ date="2015-08-19T17:17:50Z"
+ content="""
+darn, you're right... then i screwed up my copy-paste. :( the assistant *was* running on a and b, that i am sure of.
+
+here's a more complete transcript (hopefully):
+
+<pre>
+[997]anarcat@desktop008:test$ mkdir g-a
+[998]anarcat@desktop008:test$ cd g-a/
+[999]anarcat@desktop008:g-a$ git init a
+Initialized empty Git repository in /home/anarcat/test/g-a/a/.git/
+[1000]anarcat@desktop008:g-a$ git init b
+Initialized empty Git repository in /home/anarcat/test/g-a/b/.git/
+[1001]anarcat@desktop008:g-a$ git init c
+Initialized empty Git repository in /home/anarcat/test/g-a/c/.git/
+[1002]anarcat@desktop008:g-a$ cd a
+[1003]anarcat@desktop008:a$ git annex init
+init  ok
+(recording state in git...)
+[1004]anarcat@desktop008:a$ git remote add origin ../b
+[1005]anarcat@desktop008:a$ cd ../b
+[1006]anarcat@desktop008:b$ git annex init
+init  ok
+(recording state in git...)
+[1007]anarcat@desktop008:b$ git remote add origin ../c
+[1008]anarcat@desktop008:b$ cd ../c
+[1009]anarcat@desktop008:c$ git annex init
+init  ok
+(recording state in git...)
+[1010]anarcat@desktop008:c$ cd ../a/
+[1011]anarcat@desktop008:a$ git annex ^C
+[1011]anarcat@desktop008:a130$ touch test
+[1012]anarcat@desktop008:a$ git annex add tset
+git-annex: tset not found
+git-annex: add: 1 failed
+[1013]anarcat@desktop008:a1$ git annex add test
+add test ok
+(recording state in git...)
+[1014]anarcat@desktop008:a$ git annex sync
+commit  ok
+pull origin
+warning: no common commits
+remote: Counting objects: 5, done.
+remote: Compressing objects: 100% (3/3), done.
+remote: Total 5 (delta 0), reused 0 (delta 0)
+Unpacking objects: 100% (5/5), done.
+From ../b
+ * [new branch]      git-annex  -> origin/git-annex
+ok
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+push origin
+Counting objects: 16, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (12/12), done.
+Writing objects: 100% (16/16), 1.56 KiB | 0 bytes/s, done.
+Total 16 (delta 1), reused 0 (delta 0)
+To ../b
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+ok
+[1015]anarcat@desktop008:a$ git annex assistant
+[1016]anarcat@desktop008:a$ cd ../b
+[1017]anarcat@desktop008:b$ git annex assistant
+[1018]anarcat@desktop008:b$ ls
+[1019]anarcat@desktop008:b$ git anne^C
+[1019]anarcat@desktop008:b130$ ls
+[1019]anarcat@desktop008:b$ git annex sync
+commit  ok
+pull origin
+
+merge: refs/remotes/origin/master - not something we can merge
+
+merge: refs/remotes/origin/synced/master - not something we can merge
+failed
+git-annex: sync: 1 failed
+[1020]anarcat@desktop008:b1$ git remote -v^C
+[1020]anarcat@desktop008:b130$ git re^C
+[1020]anarcat@desktop008:b130$ ls
+[1021]anarcat@desktop008:b$ cd ../
+[1022]anarcat@desktop008:g-a$ git annexccd ^C
+[1022]anarcat@desktop008:g-a130$ cd c
+[1023]anarcat@desktop008:c$ git annex sync
+commit  ok
+[1024]anarcat@desktop008:c$ ls
+[1025]anarcat@desktop008:c$ cd ../b
+[1026]anarcat@desktop008:b$ git co master
+error: pathspec 'master' did not match any file(s) known to git.
+[1027]anarcat@desktop008:b1$ git branch -a
+  git-annex
+  synced/git-annex
+  synced/master
+  remotes/origin/git-annex
+[1028]anarcat@desktop008:b$ git co -b master synced/master
+Already on 'master'
+[1029]anarcat@desktop008:b$ ls
+test
+[1030]anarcat@desktop008:b$ git annex sync
+commit  ok
+pull origin
+ok
+[1031]anarcat@desktop008:b$ cd ..c
+bash: cd: ..c: No such file or directory
+[1032]anarcat@desktop008:b1$ cd ../c
+[1033]anarcat@desktop008:c$ ls
+[1034]anarcat@desktop008:c$ git annex sync
+(recording state in git...)
+commit  ok
+[1035]anarcat@desktop008:c$ ls
+[1036]anarcat@desktop008:c$ cd ../a
+[1037]anarcat@desktop008:a$ echo test > foo
+[1038]anarcat@desktop008:a$ ls -al
+total 20K
+drwxr-xr-x  3 anarcat 4294967294 4096 aoû 19 13:12 .
+drwxr-xr-x  5 anarcat 4294967294 4096 aoû 19 13:10 ..
+lrwxrwxrwx  1 anarcat 4294967294  178 aoû 19 13:12 foo -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
+drwxr-xr-x 10 anarcat 4294967294 4096 aoû 19 13:12 .git
+lrwxrwxrwx  1 anarcat 4294967294  178 aoû 19 13:11 test -> .git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+[1039]anarcat@desktop008:a$ git status
+On branch master
+nothing to commit, working directory clean
+[1040]anarcat@desktop008:a$ git annex list
+here
+|origin
+||web
+|||bittorrent
+||||
+XX__ foo
+XX__ test
+[1041]anarcat@desktop008:a$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||
+XX__ foo
+XX__ test
+[1042]anarcat@desktop008:a$ cd ../b
+[1043]anarcat@desktop008:b$ git annex wanted transfer
+git-annex: there is no available git remote named \"transfer\"
+[1044]anarcat@desktop008:b1$ git annex wanted . transfer
+wanted . git-annex: Parse error: Parse failure: near \"transfer\"
+[1045]anarcat@desktop008:b1$ git annex wanted . groupwanted
+wanted . ok
+(recording state in git...)
+[1046]anarcat@desktop008:b$ git annex group . transfer
+group . c ok
+(recording state in git...)
+[1047]anarcat@desktop008:b$ cd ../a
+[1048]anarcat@desktop008:a$ git annex group . source
+group . ok
+(recording state in git...)
+[1049]anarcat@desktop008:a$ git annex wanted . groupwanted
+wanted . ok
+(recording state in git...)
+[1050]anarcat@desktop008:a$ cd ../c
+[1051]anarcat@desktop008:c$ git annex wanted . groupwanted
+wanted . ok
+(recording state in git...)
+[1052]anarcat@desktop008:c$ git annex group . backup
+group . (merging synced/git-annex into git-annex...)
+(recording state in git...)
+ok
+(recording state in git...)
+[1053]anarcat@desktop008:c$ cd ../
+[1054]anarcat@desktop008:g-a$ cd b
+[1055]anarcat@desktop008:b$ cd ../a
+[1056]anarcat@desktop008:a$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||
+XX__ foo
+XX__ test
+[1057]anarcat@desktop008:a$ git annex^C
+[1057]anarcat@desktop008:a130$ cd ../
+[1058]anarcat@desktop008:g-a$ git ^C
+[1058]anarcat@desktop008:g-a130$ cd b
+[1059]anarcat@desktop008:b$ git remote -v
+origin  ../c (fetch)
+origin  ../c (push)
+[1060]anarcat@desktop008:b$ git annex sync
+commit  ok
+pull origin
+remote: Counting objects: 23, done.
+remote: Compressing objects: 100% (19/19), done.
+remote: Total 23 (delta 8), reused 0 (delta 0)
+Unpacking objects: 100% (23/23), done.
+From ../c
+   ac66bb1..43cfe35  git-annex  -> origin/git-annex
+ok
+(merging origin/git-annex into git-annex...)
+[1061]anarcat@desktop008:b$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/g-a/a
+|||||
+XX__X foo
+XX__X test
+[1062]anarcat@desktop008:b$ cd ../a/
+[1063]anarcat@desktop008:a$ echo bar > bar
+[1064]anarcat@desktop008:a$ git status
+On branch master
+nothing to commit, working directory clean
+[1065]anarcat@desktop008:a$ cd ^C
+[1065]anarcat@desktop008:a130$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||
+XX__ bar
+XX__ foo
+XX__ test
+[1066]anarcat@desktop008:a$ cd ../b
+[1067]anarcat@desktop008:b$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/g-a/a
+|||||
+XX__X bar
+XX__X foo
+XX__X test
+</pre>
+
+now it seems that setting repo `b` in the transfer group helped, but the files didn't get purged from `a` (or `b`, for that matter).
+
+setting the central `b` wanted expression seems to help in dropping the file from `a`, but not from `b`:
+
+<pre>
+[1070]anarcat@desktop008:b$ cd ../a
+[1071]anarcat@desktop008:a$ echo quuex > quuex
+[1072]anarcat@desktop008:a$ git status
+On branch master
+nothing to commit, working directory clean
+[1073]anarcat@desktop008:a$ cd -
+/home/anarcat/test/g-a/b
+[1074]anarcat@desktop008:b$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/g-a/a
+|||||
+XX__X bar
+XX__X foo
+X___X quuex
+XX__X test
+[1075]anarcat@desktop008:b$ cd ../c
+[1076]anarcat@desktop008:c$ git annex group
+git-annex: Specify a repository and a group.
+[1077]anarcat@desktop008:c1$ git annex group .
+(recording state in git...)
+backup
+[1078]anarcat@desktop008:c$ cd -
+/home/anarcat/test/g-a/b
+[1079]anarcat@desktop008:b$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/g-a/a
+|||||
+XX__X bar
+XX__X foo
+X___X quuex
+XX__X test
+[1080]anarcat@desktop008:b$ git annex numcopies
+global numcopies is not set
+(default is 1)
+</pre>
+
+i think i'm almost getting this now. :)
+"""]]
diff --git a/doc/forum/mesh_configurations/comment_5_a181fde7b7f6d0559331e1afa395ba0a._comment b/doc/forum/mesh_configurations/comment_5_a181fde7b7f6d0559331e1afa395ba0a._comment
new file mode 100644
index 0000000000..4cc4121055
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_5_a181fde7b7f6d0559331e1afa395ba0a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-08-19T17:54:36Z"
+ content="""
+You have B configured as a regular transfer repo, so it only wants to drop
+files once they have reached some client repos. Settings its preferred
+content to "not inallgroup=backup" should fix that.
+
+Also, the assistant can notice some configuration changes that are made
+while it's running, but maybe not all of them, and maybe it won't rescan
+files to transfer right away after such a change is made. I'd use `git
+annex sync --content` to test such changes, and save the assistant for once
+I have a working setup.
+"""]]
diff --git a/doc/forum/mesh_configurations/comment_6_7cb33d2416289f744828d8d9d24e9ef6._comment b/doc/forum/mesh_configurations/comment_6_7cb33d2416289f744828d8d9d24e9ef6._comment
new file mode 100644
index 0000000000..cd7e6777da
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_6_7cb33d2416289f744828d8d9d24e9ef6._comment
@@ -0,0 +1,117 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 6"
+ date="2015-08-19T18:13:22Z"
+ content="""
+right, i thought as well that the assistant wouldn't pickup some stuff...
+
+but `sync --content` doesn't behave as expected either:
+
+<pre>
+[1081]anarcat@desktop008:b$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/g-a/a
+|||||
+XX__X bar
+XX__X foo
+X___X quuex
+XX__X test
+[1082]anarcat@desktop008:b$ git annex sync --content
+commit  ok
+pull origin
+remote: Counting objects: 6, done.
+remote: Compressing objects: 100% (5/5), done.
+remote: Total 6 (delta 3), reused 0 (delta 0)
+Unpacking objects: 100% (6/6), done.
+From ../c
+   29d3b7b..6afbb52  git-annex  -> origin/git-annex
+ok
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+(recovering from race...)
+drop bar ok
+drop foo ok
+drop test ok
+pull origin
+ok
+(recording state in git...)
+push origin
+Counting objects: 18, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (14/14), done.
+Writing objects: 100% (18/18), 1.47 KiB | 0 bytes/s, done.
+Total 18 (delta 11), reused 0 (delta 0)
+To ../c
+   873a124..8390704  git-annex -> synced/git-annex
+ok
+[1083]anarcat@desktop008:b$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/g-a/a
+|||||
+_X__X bar
+_X__X foo
+X___X quuex
+_X__X test
+[1084]anarcat@desktop008:b$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/g-a/a
+|||||
+_X__X bar
+_X__X foo
+X___X quuex
+_X__X test
+[1084]anarcat@desktop008:b$ git annex wanted .
+not inallgroup=backup
+[1085]anarcat@desktop008:b$ cd ../a
+[1086]anarcat@desktop008:a$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||
+XX__ bar
+XX__ foo
+XX__ quuex
+XX__ test
+[1087]anarcat@desktop008:a$ git annex sync --content
+commit  ok
+pull origin
+remote: Counting objects: 114, done.
+remote: Compressing objects: 100% (94/94), done.
+remote: Total 114 (delta 54), reused 0 (delta 0)
+Receiving objects: 100% (114/114), 9.20 KiB | 0 bytes/s, done.
+Resolving deltas: 100% (54/54), completed with 6 local objects.
+From ../b
+   de5f95e..158c3cc  git-annex  -> origin/git-annex
+ok
+(merging origin/git-annex into git-annex...)
+pull origin
+ok
+[1088]anarcat@desktop008:a$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/g-a/c
+|||||
+X___X bar
+X___X foo
+XX___ quuex
+X___X test
+[1089]anarcat@desktop008:a$ git annex wanted .
+groupwanted
+[1090]anarcat@desktop008:a$ git annex group .
+source
+</pre>
+
+files are still not removed from `a` and a few of them were dropped from `b`, but not all of them. but worse, one file still isn't sent to the backup server `c` at all.
+"""]]
diff --git a/doc/forum/mesh_configurations/comment_7_6c9d499f64067ee9d3721dc763f3c425._comment b/doc/forum/mesh_configurations/comment_7_6c9d499f64067ee9d3721dc763f3c425._comment
new file mode 100644
index 0000000000..1767d5389a
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_7_6c9d499f64067ee9d3721dc763f3c425._comment
@@ -0,0 +1,123 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2015-08-19T18:51:42Z"
+ content="""
+I'm afraid I don't have time to continue to read and try to debug
+transcripts of this being set up incorrectly in various ways. 
+
+So, here's a transcript of the configuration I described, which seems to be
+working as I'd expect it to work:
+
+	joey@darkstar:~/tmp>mkdir bench
+	joey@darkstar:~/tmp>cd bench
+	joey@darkstar:~/tmp/bench>git init A
+	Initialized empty Git repository in /home/joey/tmp/bench/A/.git/
+	joey@darkstar:~/tmp/bench>cd A
+	joey@darkstar:~/tmp/bench/A>git annex init
+	init  ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/A>git annex wanted . standard
+	wanted . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/A>git annex group . source
+	group . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/A>date > somefile
+	joey@darkstar:~/tmp/bench/A>git annex add
+	add somefile ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/A>git commit -m added
+	[master (root-commit) 4a322e1] added
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 somefile
+	joey@darkstar:~/tmp/bench/A>cd ..
+	joey@darkstar:~/tmp/bench>git clone A B
+	Cloning into 'B'...
+	done.
+	joey@darkstar:~/tmp/bench>cd B
+	joey@darkstar:~/tmp/bench/B>git annex wanted . "not inallgroup=backup"
+	(merging origin/git-annex into git-annex...)
+	(recording state in git...)
+	wanted . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/B>cd ..
+	joey@darkstar:~/tmp/bench>git clone B C
+	Cloning into 'C'...
+	done.
+	joey@darkstar:~/tmp/bench>cd C
+	joey@darkstar:~/tmp/bench/C>git annex group . backup
+	(merging origin/git-annex into git-annex...)
+	(recording state in git...)
+	group . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/C>git annex wanted . standard
+	wanted . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/C>cd ..
+	joey@darkstar:~/tmp/bench>cd B
+	joey@darkstar:~/tmp/bench/B>git remote add A ../A
+	joey@darkstar:~/tmp/bench/B>git remote add C ../C
+
+Now observe sync moving the file from A thru B to C:
+
+	joey@darkstar:~/tmp/bench/B>git annex sync --content
+	commit  ok
+	pull origin 
+	ok
+	pull C 
+	remote: Counting objects: 10, done.
+	remote: Compressing objects: 100% (9/9), done.
+	remote: Total 10 (delta 3), reused 0 (delta 0)
+	Unpacking objects: 100% (10/10), done.
+	From ../C
+	 * [new branch]      git-annex  -> C/git-annex
+	 * [new branch]      master     -> C/master
+	ok
+	pull A 
+	From ../A
+	 * [new branch]      git-annex  -> A/git-annex
+	 * [new branch]      master     -> A/master
+	ok
+	(merging C/git-annex into git-annex...)
+	get somefile (from origin...) ok
+	copy somefile copy somefile (to C...) ok
+	drop somefile ok
+	drop origin somefile ok
+	pull origin 
+	ok
+	pull C 
+	ok
+	pull A 
+	ok
+	(recording state in git...)
+	push origin 
+	Counting objects: 21, done.
+	Delta compression using up to 4 threads.
+	Compressing objects: 100% (19/19), done.
+	Writing objects: 100% (21/21), 2.19 KiB | 0 bytes/s, done.
+	Total 21 (delta 7), reused 0 (delta 0)
+	To /home/joey/tmp/bench/A
+	 * [new branch]      git-annex -> synced/git-annex
+	 * [new branch]      master -> synced/master
+	ok
+	push C 
+	Counting objects: 5, done.
+	Delta compression using up to 4 threads.
+	Compressing objects: 100% (4/4), done.
+	Writing objects: 100% (5/5), 474 bytes | 0 bytes/s, done.
+	Total 5 (delta 2), reused 0 (delta 0)
+	To ../C
+	 * [new branch]      git-annex -> synced/git-annex
+	 * [new branch]      master -> synced/master
+	ok
+	push A 
+	Everything up-to-date
+	ok
+	joey@darkstar:~/tmp/bench/B>git annex whereis
+	whereis somefile (1 copy) 
+	  	65092dc3-ea1e-4267-89b7-5fcb8df2c6ae -- joey@darkstar:~/tmp/bench/C [C]
+	ok
+
+Er, the 'A' remote in 'B' was unnecessary since A is origin. But otherwise, I think that's what you asked for.. HTH.
+"""]]
diff --git a/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment b/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment
new file mode 100644
index 0000000000..b77b1b0f80
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment
@@ -0,0 +1,197 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="works with sync --content, but the assistant is slow to pickup tracking info"
+ date="2015-08-19T20:29:46Z"
+ content="""
+well, this is not exactly the topology i have here.
+
+you setup a topology like this:
+
+    A <- B <-> C
+
+`X <- Y` means `X is a remote of Y`.
+
+My topology is:
+
+    A -> B -> C
+
+So B can't directly manage objects from A. It can *receive* objects from it, but that's it.
+
+So here's a clearer transcript of the session, using the same semantics you have been using for the different repos, but with the remotes setup differently, as I describe above:
+
+<pre>
+[1113]anarcat@desktop008:bench$ git init B
+Initialized empty Git repository in /home/anarcat/test/bench/B/.git/
+[1114]anarcat@desktop008:bench$ cd B/
+[1115]anarcat@desktop008:B$ git annex init
+init  ok
+(recording state in git...)
+[1116]anarcat@desktop008:B$ date > somefile
+[1117]anarcat@desktop008:B$ git annex add
+add somefile ok
+(recording state in git...)
+[1118]anarcat@desktop008:B$ git commit -madded
+[master (root-commit) d2f6177] added
+ 1 file changed, 1 insertion(+)
+ create mode 120000 somefile
+[1119]anarcat@desktop008:B$ git annex wanted . \"not inallgroup=backup\"
+wanted . ok
+(recording state in git...)
+[1138]anarcat@desktop008:B$ git remote add C ../C # actually did that later
+[1120]anarcat@desktop008:B$ cd ../
+[1121]anarcat@desktop008:bench$ git clone -o B B A
+Cloning into 'A'...
+done.
+[1122]anarcat@desktop008:bench$ git clone B C
+Cloning into 'C'...
+done.
+[1123]anarcat@desktop008:bench$ cd A
+[1124]anarcat@desktop008:A$ git annex wanted . standard
+(merging B/git-annex into git-annex...)
+(recording state in git...)
+wanted . ok
+(recording state in git...)
+[1125]anarcat@desktop008:A$ git annex group . source
+group . ok
+(recording state in git...)
+[1126]anarcat@desktop008:A$ cd ../C
+[1127]anarcat@desktop008:C$ git annex wanted . standard
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+wanted . ok
+(recording state in git...)
+[1128]anarcat@desktop008:C$ git annex group . backup
+group . ok
+(recording state in git...)
+[1142]anarcat@desktop008:C$ git remote rm origin # because this is S3 in production, and can't do anything on its own
+</pre>
+
+And of course now, it actually works fine, with `sync --content`:
+
+<pre>
+[1144]anarcat@desktop008:A$ git annex sync --content
+commit  ok
+pull B
+remote: Counting objects: 20, done.
+remote: Compressing objects: 100% (18/18), done.
+remote: Total 20 (delta 8), reused 0 (delta 0)
+Unpacking objects: 100% (20/20), done.
+From /home/anarcat/test/bench/B
+   d2f6177..b625a42  master     -> B/master
+   0432685..2061cf9  git-annex  -> B/git-annex
+ok
+(merging B/git-annex into git-annex...)
+copy otherfile copy otherfile (to B...) ok
+drop otherfile ok
+pull B
+ok
+(recording state in git...)
+push B
+Counting objects: 8, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (6/6), done.
+Writing objects: 100% (8/8), 720 bytes | 0 bytes/s, done.
+Total 8 (delta 3), reused 0 (delta 0)
+To /home/anarcat/test/bench/B
+   0432685..e0fccbd  git-annex -> synced/git-annex
+ok
+[1145]anarcat@desktop008:A$ cd ../B
+[1146]anarcat@desktop008:B$ git annex sync --content
+commit  ok
+pull C
+remote: Counting objects: 5, done.
+remote: Compressing objects: 100% (4/4), done.
+remote: Total 5 (delta 2), reused 0 (delta 0)
+Unpacking objects: 100% (5/5), done.
+From ../C
+   2061cf9..1d0a3d5  git-annex  -> C/git-annex
+ok
+(merging C/git-annex into git-annex...)
+(recording state in git...)
+copy otherfile copy otherfile (to C...) ok
+drop otherfile ok
+pull C
+ok
+(recording state in git...)
+push C
+Counting objects: 20, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (16/16), done.
+Writing objects: 100% (20/20), 1.55 KiB | 0 bytes/s, done.
+Total 20 (delta 10), reused 0 (delta 0)
+To ../C
+   2061cf9..86a892f  git-annex -> synced/git-annex
+ok
+[1147]anarcat@desktop008:B$ git annex list
+here
+|C
+||web
+|||bittorrent
+||||
+_X__ otherfile
+_X__ somefile
+</pre>
+
+Now, that's all great for `sync --content` - but what about the assistant?
+
+<pre>
+[1150]anarcat@desktop008:B$ git annex assistant
+[1151]anarcat@desktop008:B$ cd ../A
+[1152]anarcat@desktop008:A$ git annex assistant
+[1154]anarcat@desktop008:A$ date > foo
+[1157]anarcat@desktop008:A$ git annex list --allrepos
+here
+|B
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/bench/C
+|||||
+_X___ foo
+____X otherfile
+____X somefile
+[1158]anarcat@desktop008:A$ sleep 600; git annex list --allrepos
+here
+|B
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/bench/C
+|||||
+_X___ foo
+____X otherfile
+____X somefile
+</pre>
+
+so from `A`'s perspective, it looks like the file didn't migrate properly. *but* it actually did!
+
+<pre>
+[1159]anarcat@desktop008:A$ cd ../B
+[1160]anarcat@desktop008:B$ git annex list --allrepos
+here
+|C
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/bench/A
+|||||
+_X___ foo
+_X___ otherfile
+_X___ somefile
+[1161]anarcat@desktop008:B$ cd -
+/home/anarcat/test/bench/A
+[1162]anarcat@desktop008:A$ git annex list --allrepos
+here
+|B
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/bench/C
+|||||
+_X___ foo
+____X otherfile
+____X somefile
+</pre>
+
+how long does it take for the assistant to start syncs like this? are those timers user-accessible somehow? this problem sure looks like [[bugs/sync-git-annex_branch_not_syncing_in_the_assistant]] - but maybe i'm confused there as well.
+
+anyways, it does seem like content actually does gets synced around properly by the assistant. i'll try to deploy the new preferred content expression in production and report back here.
+
+and sorry for the noisy pastes and hand-holding, but i was thoroughly confused by this one. i thought i had a good grasp on preferred content and all that, but it seems i was wrong... :(
+"""]]
diff --git a/doc/forum/mesh_configurations/comment_9_ac3e1faaefaed222f725345ab4b5f01a._comment b/doc/forum/mesh_configurations/comment_9_ac3e1faaefaed222f725345ab4b5f01a._comment
new file mode 100644
index 0000000000..33b6ab0a03
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_9_ac3e1faaefaed222f725345ab4b5f01a._comment
@@ -0,0 +1,89 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="a bit more info and solutions"
+ date="2015-08-20T14:09:54Z"
+ content="""
+so short version here: thanks for your help and i figured it, there were problems with the S3 credentials perms not respecting `sharedRepository`, multiple group support confusion, bare/non-bare, groupwanted vs standard confusion and so on... now the files are migrating properly in production. hurray! i believe documentation could be improved, and i have questions about timeouts, below.
+
+so one thing that was definitely broken in production was that, on the central server, the S3 credentials were accessible only to the user that ran the \"enable s3\" command (that is `anarcat`). it was *not* accessible to the user actually running the assistant (the `git-annex` sandbox account), which made it simply impossible for the assistant to upload files to s3. so maybe one problem here is that the `.git/annex/creds` file do not respect the `core.sharedRepository = group` setting i have there...
+
+another problem in production, of course, was the *transfer* preferred group setting. once changed to `not inallgroup=backup`, things were better... but it was still keeping too many files. the problem then was that the repo was originally set to the *source* group (PEBKAC here again, sorry) and then it was *added* to the *standard* group, with the `git annex group . standard` command. i didn't expect that: i expected the group command to *change* the group, not to add to it. the documentation ([[git-annex-group]]) is clear enough, however, so this is yet another PEBKAC.
+
+Another possible problem is that the central server (`b`) is not a bare git repository. I am not sure why it was setup that way... maybe i was worried about bare repo suport and past experiences, or concerns about being able to actually interact with the files directly on the central server. i had to do `git co -b master synced/master` to eventually see the files locally, and this helped a little in diagnosing all of this.
+
+A problem remained after that though: files are *still* not removed from `A` in my tests in production. i don't understand why: `A` is setup as a source repository:
+
+<pre>
+antoine@ip-10-88-150-10:/mnt/media$ git annex group .
+sourcethis 
+antoine@ip-10-88-150-10:/mnt/media$ git annex wanted .
+groupwanted
+</pre>
+
+yet some files have more than one copy:
+
+<pre>
+antoine@ip-10-88-150-10:/mnt/media$ git annex list test
+here
+|origin
+||s3
+|||web (untrusted)
+||||bittorrent
+|||||
+X_X__ test/motd
+__X__ test/test1
+__X__ test/test2
+__X__ test/test3
+</pre>
+
+Indeed, it doesn't sem to want to drop that local file:
+
+<pre>
+antoine@ip-10-88-150-10:/mnt/media$ git annex list --want-drop test
+here
+|origin
+||s3
+|||web (untrusted)
+||||bittorrent
+|||||
+__X__ test/test1
+__X__ test/test2
+__X__ test/test3
+</pre>
+
+It turns out that I had documentation wrong again about that as well: i was using *groupwanted* as a `wanted` expression, but the groups were standard groups, so git-annex was just failing to use the proper content expression. setting the `wanted` expression back to standard (yes, again as you showed, sorry about that) fixed the problem:
+
+<pre>
+antoine@ip-10-88-150-10:/mnt/media$ sudo -u www-data -H git annex wanted . standard
+wanted . ok
+(recording state in git...)
+antoine@ip-10-88-150-10:/mnt/media$ git annex list --want-drop test
+here
+|origin
+||s3
+|||web (untrusted)
+||||bittorrent
+|||||
+X_X__ test/motd
+__X__ test/test1
+__X__ test/test2
+__X__ test/test3
+antoine@ip-10-88-150-10:/mnt/media$ sudo -u www-data -H git annex drop --auto test
+drop test/motd ok
+(recording state in git...)
+</pre>
+
+hurray!
+
+again, i apologise for all the hand holding here... as a software developper myself, i understand how frustrating it can be to try to make users come out of their cave of ignorance and see the light of day...
+
+but i do feel there could be more work done to clarify how all of this works. i will certainly try to give a few kicks in the [[preferred content]] section and maybe this forum post will be helpful for future endeavors... or maybe just write up a new tips page about such hairy setups?
+
+the questions that remain here for me are:
+
+* how long does the assistant wait before refreshing the wanted content expressions
+* how long it waits before triggering syncs
+* are those timeouts configurable
+
+thanks so much for helping us through this, it's really appreciated!
+"""]]
diff --git a/doc/forum/messed_up_annex_by_using_git_checkout.mdwn b/doc/forum/messed_up_annex_by_using_git_checkout.mdwn
new file mode 100644
index 0000000000..f9b2eb63c4
--- /dev/null
+++ b/doc/forum/messed_up_annex_by_using_git_checkout.mdwn
@@ -0,0 +1,40 @@
+Hello. Linux experienced user here, but with no development or git experience ever. This directly leads me to my biggest trouble with git-annex because I constantly suffer from misunderstanding each and everything. That being said, my problem is the following: I had the terrible idea to have my .thunderbird directory synchronized over several machines, leading the thunderbird profile to total corruption because after a few weeks I finally managed to have multiple machines accessing it. As I started trying to recover, things got worse and this is my last seek for help before starting over by creating the repositories from scratch.
+
+What I did:
+
+1. I did some research on how to recover an old state of the repo, which should not have been a problem because there is a "full backup" repo. I came across this [1] page and the pain started with me looking for my wanted commit to roll-back in "git log" and then did some tries in the way something like, "git checkout -b old-state4 012345678".
+
+2. Of course this recovered the whole repo and not only thunderbird, so I used a file synchronizer to put everything else back into place after the action.
+
+3. Unfortunately, the "branches" seem to have been messed up and the repos are no longer in sync.
+
+This is what the machine says that I have used to create the mess:
+
+    [2016-03-08 19:15:26.915116] Pusher: Syncing with host123
+    (recording state in git...)
+    To ssh://user@10.0.0.1/mnt/foo/bar
+       d35c699..fed0636  git-annex -> synced/git-annex
+       a44bfb2..818b7b5  annex/direct/old_state4 -> synced/old_state4
+
+This is what another machine says:
+
+    [2016-03-08 21:17:48.649949] Pusher: Syncing with host123
+    (recording state in git...)
+    To ssh://user@10.0.0.1/mnt/foo/bar
+    
+       423f50f..4c8fad8  annex/direct/master -> q/annex/direct/master
+       2a67458..fed0636  git-annex  -> host123/git-annex
+       6a1076b..4c8fad8  master     -> host123/master
+       7f55414..818b7b5  old_state4 -> host123/old_state4
+
+Long story, short...
+
+I apologize for being a total git noob while at the same time performing git magic leading into a total desaster.
+However, I hope someone can give me a hint what to do to have the "old_state4" solved?
+
+Also, I really would like to get used to the git internals but since git is quite powerful, I always get overwhelmed because the tutorials out there are either developer-focused (which I'm not in the correct target group) or they simply cover each and everything (which is of no use because I don't want to administrate a GitHub repo but a private git-annex for my files and documents). 
+
+Thank you so much!
+
+
+[1] http://stackoverflow.com/questions/4114095/revert-git-repo-to-a-previous-commit
diff --git a/doc/forum/messed_up_annex_by_using_git_checkout/comment_1_04f33895f6451690372595c576be2811._comment b/doc/forum/messed_up_annex_by_using_git_checkout/comment_1_04f33895f6451690372595c576be2811._comment
new file mode 100644
index 0000000000..cd480bc153
--- /dev/null
+++ b/doc/forum/messed_up_annex_by_using_git_checkout/comment_1_04f33895f6451690372595c576be2811._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-03-14T17:27:17Z"
+ content="""
+You don't seem to really say what the problem is, but I guess it has
+something to do with this `old_state4` branch which you have made.
+
+Maybe check what `git branch` shows to see if that branch is checked out,
+and if so, `git checkout master` to get back to the master branch.
+"""]]
diff --git a/doc/forum/metadata_limits.mdwn b/doc/forum/metadata_limits.mdwn
new file mode 100644
index 0000000000..523db70d85
--- /dev/null
+++ b/doc/forum/metadata_limits.mdwn
@@ -0,0 +1,10 @@
+Hello,
+
+I was wondering what `The metadata values can contain absolutely anything you like -- but you're recommended to keep it simple and reasonably short.` listed on the [[metadata]] page really means?
+
+
+Here is my use case (which is part of a larger solution)...
+
+I've been storing my photos in git annex for a while (years perhaps), I (or actually the wife) tried to find one and couldn't, so I'm thinking I need to add metadata (Tags and captions, etc) to each picture. I was looking for ways to do so. I was actually considering using gthumb or shotwell or similar to create the tags and somehow pull that out and associate it with the file (either with a plugin or program) and then sort out how to distribute the metadata with the pics. The git annex metadata seems like a reasonable solution for keeping metadata with the pictures. The question is in this case, how long can the text in say a caption tag before git-annex has problems? I could probably do something like caption-<seq> to handle really long captions, but then captions are short by definition, so perhaps I should say description instead. And for this particular use case, I am aware this doesn't solve the problem of actually creating the data, just trying to sort out if get annex metadata to the right solution to tie the metadata to a pic, err file.
+
+
diff --git a/doc/forum/metadata_limits/comment_1_a20bbe49f2f23d23131221ec79c8b973._comment b/doc/forum/metadata_limits/comment_1_a20bbe49f2f23d23131221ec79c8b973._comment
new file mode 100644
index 0000000000..d296a1cb99
--- /dev/null
+++ b/doc/forum/metadata_limits/comment_1_a20bbe49f2f23d23131221ec79c8b973._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-12-02T18:39:34Z"
+ content="""
+There's no particular size limit for metadata. But things may not scale
+well past some size.
+
+Having a big metadata value could make git-annex be a little slow when
+dealing with metadata, since it has to parse the metadata log file.
+So if you stored say, 1 mb in metadata, that's one mb of disk IO and data
+processing every time git-annex looks at the metadata for that file.
+
+All the metadata for a file will also be buffered in memory when git-annex
+is looking at that file's metadata. So `git-annex view` would use 1 mb or
+so more memory in the above example. (But git-annex only looks at one
+file's metadata at a time, so its memory use won't grow if you have a lot
+of files with metadata.)
+
+Also of course, the metadata is stored in git, and so it will make your git
+repository bigger.
+
+I would not expect any reasonable description of a photo to be large enough
+for its size to be a problem.
+
+I'd even feel ok with putting the full text of a license in as metadata
+(GPL is 30kb, and git would deduplicate redundant license metadata).
+"""]]
diff --git a/doc/forum/metadata_limits/comment_2_4e8995ccd5fc2e5ee5d89a0780e5df9d._comment b/doc/forum/metadata_limits/comment_2_4e8995ccd5fc2e5ee5d89a0780e5df9d._comment
new file mode 100644
index 0000000000..097558f861
--- /dev/null
+++ b/doc/forum/metadata_limits/comment_2_4e8995ccd5fc2e5ee5d89a0780e5df9d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://jamestechnotes.com/"
+ nickname="James"
+ subject="comment 2"
+ date="2014-12-02T22:37:33Z"
+ content="""
+Thanks Joey.
+
+Now to sort out how to create the data ;) -- [[james]]
+"""]]
diff --git a/doc/forum/migrate_existing_git_repository_to_git-annex.mdwn b/doc/forum/migrate_existing_git_repository_to_git-annex.mdwn
new file mode 100644
index 0000000000..f673de765b
--- /dev/null
+++ b/doc/forum/migrate_existing_git_repository_to_git-annex.mdwn
@@ -0,0 +1,66 @@
+I have a large git repository with binary files scattered over different branches. I want to switch to git-annex mainly for performance reasons, but I don't want to loose my history.
+
+I tried to rewrite the (cloned) repository with git-filter-branch but failed miserably for several reasons:
+
+* --tree-filter performs its operations in a temporary directory (.git-rewrite/t/) so the symlinks point to the wrong destination (../../.git/annex/).
+* annex log files are stored in .git-annex/ instead of .git-rewrite/t/.git-annex/ so the filter operation misses them
+
+Any suggestions how to proceed?
+
+EDIT 3/2/2010
+I finally got it working for my purposes. Hardest part was preserving the branches while injecting the new `git annex setup` base commit.
+
+#### Clone repository
+    git clone original migrate
+    cd migrate
+    git checkout mybranch
+    git checkout master
+    git remote rm origin
+
+#### Inject `git annex setup` base commit and repair branches
+    git symbolic-ref HEAD refs/heads/newroot
+    git rm --cached *
+    git clean -f -d
+    git annex init master
+    echo \*.rpm annex.backend=SHA1 >> .gitattributes
+    git commit -m "store rpms in git annex" .gitattributes
+    git cherry-pick $(git rev-list --reverse master | head -1)
+    git rebase --onto newroot newroot master
+    git rebase --onto master mybranch~1 mybranch
+    git branch -d newroot
+
+#### Migrate repository
+    mkdir .temp
+    cp .git-annex/* .temp/
+    MYWORKDIR=$(pwd) git filter-branch \
+     --tag-name-filter cat \
+     --tree-filter '
+        mkdir -p .git-annex;
+        cp ${MYWORKDIR}/.temp/* .git-annex/;
+        for rpm in $(git ls-files | grep "\.rpm$"); do
+            echo;
+            git annex add $rpm;
+            annexdest=$(readlink $rpm);
+            if [ -e .git-annex/$(basename $annexdest).log ]; then
+                echo "FOUND $(basename $annexdest).log";
+            else
+                echo "COPY $(basename $annexdest).log";
+                cp ${MYWORKDIR}/.git-annex/$(basename $annexdest).log .git-annex/;
+                cp ${MYWORKDIR}/.git-annex/$(basename $annexdest).log ${MYWORKDIR}/.temp/;
+            fi;
+            ln -sf ${annexdest#../../} $rpm;
+        done;
+        git reset HEAD .git-rewrite;
+        :
+        ' -- $(git branch | cut -c 3-)
+    rm -rf .temp
+    git reset --hard
+
+
+TODO:
+
+* Find a way to repair branches automatically (detect branch points and run appropriate `git rebase` commands)
+
+I'll be happy to try any suggestions to improve this migration script.
+
+P.S. Is there a way to edit comments?
diff --git a/doc/forum/migrate_existing_git_repository_to_git-annex/comment_1_4181bf34c71e2e8845e6e5fb55d53381._comment b/doc/forum/migrate_existing_git_repository_to_git-annex/comment_1_4181bf34c71e2e8845e6e5fb55d53381._comment
new file mode 100644
index 0000000000..e88794d621
--- /dev/null
+++ b/doc/forum/migrate_existing_git_repository_to_git-annex/comment_1_4181bf34c71e2e8845e6e5fb55d53381._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-02-25T05:16:48Z"
+ content="""
+I don't know how to approach this yet, but I support the idea -- it would be great if there was a tool that could punch files out of git history and put them in the annex. (Of course with typical git history rewriting caveats.)
+
+Sounds like it might be enough to add a switch to git-annex that overrides where it considers the top of the git repository to be? 
+"""]]
diff --git a/doc/forum/migrate_existing_git_repository_to_git-annex/comment_2_5f08da5e21c0b3b5a8d1e4408c0d6405._comment b/doc/forum/migrate_existing_git_repository_to_git-annex/comment_2_5f08da5e21c0b3b5a8d1e4408c0d6405._comment
new file mode 100644
index 0000000000..71a40ad8cb
--- /dev/null
+++ b/doc/forum/migrate_existing_git_repository_to_git-annex/comment_2_5f08da5e21c0b3b5a8d1e4408c0d6405._comment
@@ -0,0 +1,60 @@
+[[!comment format=mdwn
+ username="tyger"
+ ip="80.66.20.180"
+ subject="comment 2"
+ date="2011-03-01T14:07:50Z"
+ content="""
+My current workflow looks like this (I'm still experimenting):
+
+### Create backup clone for migration
+
+    git clone original migrate
+    cd migrate
+    for branch in $(git branch -a | grep remotes/origin | grep -v HEAD); do git checkout --track $branch; done
+
+### Inject git annex initialization at repository base
+
+    git symbolic-ref HEAD refs/heads/newroot
+    git rm --cached *.rpm
+    git clean -f -d
+    git annex init master
+    git cherry-pick $(git rev-list --reverse master | head -1)
+    git rebase --onto newroot newroot master
+    git rebase master mybranch # how to automate this for all branches?
+    git branch -d newroot
+
+### Start migration with tree filter
+
+    echo \*.rpm annex.backend=SHA1 > .git/info/attributes
+    MYWORKDIR=$(pwd) git filter-branch --tree-filter ' \
+        if [ ! -d .git-annex ]; then \
+            mkdir .git-annex; \
+            cp ${MYWORKDIR}/.git-annex/uuid.log .git-annex/; \
+            cp ${MYWORKDIR}/.gitattributes .; \
+        fi
+        for rpm in $(git ls-files | grep \"\.rpm$\"); do \
+            echo; \
+            git annex add $rpm; \
+            annexdest=$(readlink $rpm); \
+            if [ -e .git-annex/$(basename $annexdest).log ]; then \
+                echo \"FOUND $(basename $annexdest).log\"; \
+            else \
+                echo \"COPY $(basename $annexdest).log\"; \
+                cp ${MYWORKDIR}/.git-annex/$(basename $annexdest).log .git-annex/; \
+            fi; \
+            ln -sf ${annexdest#../../} $rpm; \
+        done; \
+        git reset HEAD .git-rewrite; \
+        : \
+        ' -- $(git branch | cut -c 3-)
+    rm -rf .temp
+    git reset --hard
+
+
+There are still some drawbacks:
+
+* git history shows that git annex log files are modified with each checkin
+* branches have to be rebased manually before starting migration
+
+
+"""]]
diff --git a/doc/forum/migrate_existing_git_repository_to_git-annex/comment_3_f483038c006cf7dcccf1014fa771744f._comment b/doc/forum/migrate_existing_git_repository_to_git-annex/comment_3_f483038c006cf7dcccf1014fa771744f._comment
new file mode 100644
index 0000000000..90bf23b6cf
--- /dev/null
+++ b/doc/forum/migrate_existing_git_repository_to_git-annex/comment_3_f483038c006cf7dcccf1014fa771744f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="tyger"
+ ip="80.66.20.180"
+ subject="comment 3"
+ date="2011-03-02T08:15:37Z"
+ content="""
+> Sounds like it might be enough to add a switch to git-annex that overrides where it considers the top of the git repository to be?
+
+It should sufficient to honor GIT_DIR/GIT_WORK_TREE/GIT_INDEX_FILE environment variables. git filter-branch sets GIT_WORK_TREE to ., but this can be mitigated by starting the filter script with 'GIT_WORK_TREE=$(pwd $GIT_WORK_TREE)'. E.g. GIT_DIR=/home/tyger/repo/.git, GIT_WORK_TREE=/home/tyger/repo/.git-rewrite/t, then git annex should be able to compute the correct relative path or maybe use absolute pathes in symlinks.
+
+Another problem I observed is that git annex add automatically commits the symlink; this behaviour doesn't work well with filter-tree. git annex commits the wrong path (.git-rewrite/t/LINK instead of LINK). Also filter-tree doesn't expect that the filter script commmits anything; new files in the temporary work tree will be committed by filter-tree on each iteration of the filter script (missing files will be removed).
+"""]]
diff --git a/doc/forum/migrate_existing_git_repository_to_git-annex/comment_4_057f0079fbee3451ccda08026bab21d4._comment b/doc/forum/migrate_existing_git_repository_to_git-annex/comment_4_057f0079fbee3451ccda08026bab21d4._comment
new file mode 100644
index 0000000000..e8495560ae
--- /dev/null
+++ b/doc/forum/migrate_existing_git_repository_to_git-annex/comment_4_057f0079fbee3451ccda08026bab21d4._comment
@@ -0,0 +1,20 @@
+[[!comment format=sh
+ username="https://www.google.com/accounts/o8/id?id=AItOawll4Kgp7nMuOKdB0FfbcYZ3KRq7HCS0Slc"
+ nickname="Laura"
+ subject="Rebase all branches"
+ date="2014-01-16T17:47:45Z"
+ content="""
+
+For the portion: git rebase master mybranch # how to automate this for all branches?
+
+Try this:
+
+branch_to_ignore='git-annex|master|newroot'
+for branch in $(git for-each-ref --sort=-committerdate refs/heads --format='%(refname:short)' | egrep -v $branch_to_ignore )
+    do git rebase --onto master \"$branch~\" \"$branch\"
+    echo \"Rebasing branch $branch onto master....\" 
+done
+
+Feel free to add/correct as necessary
+
+"""]]
diff --git a/doc/forum/migration_to_git-annex_and_rsync.mdwn b/doc/forum/migration_to_git-annex_and_rsync.mdwn
new file mode 100644
index 0000000000..d99dab8728
--- /dev/null
+++ b/doc/forum/migration_to_git-annex_and_rsync.mdwn
@@ -0,0 +1,33 @@
+When migrating large file repositories to git-annex that are backuped in a way that uses an rsync-style mechanism (e.g. [dirvish](http://www.dirvish.org/)) and thus keeps incremental backups small by using hardlinks, space can be saved by manually reflecting the migration on the backup. So, instead of making a last pre-git-annex backup, migrating, and duplicating all backupped data with the next backup, I used the <del>attached</del> migrate.py file below, and it saved me roughly a day of backuping.
+
+A note on terminology: "migrating" here means migrating from not using git-annex at all to using it, not to the ``git annex migrate`` command, for which a similar but different solution may be created.
+
+**WARNING**: This is a quickly hacked-together script. It worked for me, but is untested apart from that. It's just a dozen lines of code, so have a look at it and make sure you understand what it does, and what migrate.sh looks like. Take special care as this tampers with your backups, and if something goes wrong, well...
+
+First, have an up-to-date backup; then, git annex init / add etc as described in the [[walkthrough]]. In the directory in which you use git-annex, run:
+
+    $ python migrate.py > migrate.sh
+
+Then copy the resulting migrate.sh to the equivalent location inside your backups and run it there. It will move all files that are now symlinked on the master to their new positions according to the symlinks (inside .git/annex/objects), but not create the symlinks (you will do a backup later anyway).
+
+After that, do a backup as usual. As rsync sees the moved files at their new locations, it will accept them and not duplicate the data.
+
+**migrate.py**:
+
+    #!/usr/bin/env python
+    
+    import os
+    from pipes import quote
+    
+    print "#!/bin/sh"
+    print "set -e"
+    print ""
+    
+    for (dirpath, dirnames, filenames) in os.walk("."):
+    	for f in filenames:
+    		fn = os.path.join(dirpath, f)
+    		if os.path.islink(fn):
+    			link = os.path.normpath(os.path.join(dirpath, os.readlink(fn)))
+    			assert link.startswith(".git/annex/objects/")
+    			print "mkdir -p %s"%quote(os.path.dirname(link))
+    			print "mv %s %s"%(quote(fn), quote(link))
diff --git a/doc/forum/misctmp_filling_up.mdwn b/doc/forum/misctmp_filling_up.mdwn
new file mode 100644
index 0000000000..a633760c97
--- /dev/null
+++ b/doc/forum/misctmp_filling_up.mdwn
@@ -0,0 +1,11 @@
+My directory .git/annex/misctmp is quite filled up with files like P39923, P33083, and also with 7 characters P310000 up to P331998. The beginning of these filenames may come from the annexed files, which all start with 'P3'.
+
+There is a total of 12198 of them (4.0TB... yes this repo is quite big ;)).
+
+Each of those has the content of individual annexed files (about 300-400MB targzipped files). Sometimes they are hard liked to each other, up to 8 copies.
+
+Since I have copied+dropped the whole repo content to other repos, there should be nothing left locally. I have verified several of those files (the annexed files which are identical to the misctmp/* files), are they indeed are located elsewhere, and not "here".
+
+So I was wondering if it is safe to remove them, and why are they not listed by git annex unused?
+
+Thanks for your help!!
diff --git a/doc/forum/misctmp_filling_up/comment_1_2739dec72fe0950dd070c8fab9fbd751._comment b/doc/forum/misctmp_filling_up/comment_1_2739dec72fe0950dd070c8fab9fbd751._comment
new file mode 100644
index 0000000000..9d1713745c
--- /dev/null
+++ b/doc/forum/misctmp_filling_up/comment_1_2739dec72fe0950dd070c8fab9fbd751._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.114"
+ subject="comment 1"
+ date="2014-04-27T00:16:49Z"
+ content="""
+You can delete them.
+
+AFAIK this should only happen if the assistant is interrupted while it's adding files. I plan to make the assistant clean up old tmp files on startup.
+"""]]
diff --git a/doc/forum/misctmp_filling_up/comment_2_440081b5e2b9b5b19e8cd5db3649a976._comment b/doc/forum/misctmp_filling_up/comment_2_440081b5e2b9b5b19e8cd5db3649a976._comment
new file mode 100644
index 0000000000..5048f601e8
--- /dev/null
+++ b/doc/forum/misctmp_filling_up/comment_2_440081b5e2b9b5b19e8cd5db3649a976._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmdbVIGiDH8KarAGAy8y2FHJD_F990JzXI"
+ nickname="François"
+ subject="comment 2"
+ date="2014-04-27T05:21:48Z"
+ content="""
+Indeed I had to interrupt the add a few times.
+
+Thanks!
+"""]]
diff --git a/doc/forum/misctmp_filling_up/comment_3_b6ab64f02f204fc7e8741b9c04c5349d._comment b/doc/forum/misctmp_filling_up/comment_3_b6ab64f02f204fc7e8741b9c04c5349d._comment
new file mode 100644
index 0000000000..21167f9c5e
--- /dev/null
+++ b/doc/forum/misctmp_filling_up/comment_3_b6ab64f02f204fc7e8741b9c04c5349d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-01-17T20:00:57Z"
+ content="""
+There were actually a few ways git-annex could be interrupted and leave
+droppings in misctmp.
+
+This is now dealt with, a subsequent run of git-annex will clean up
+leftover files from a previous interrupted run.
+"""]]
diff --git a/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer.mdwn b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer.mdwn
new file mode 100644
index 0000000000..1e2e44cfab
--- /dev/null
+++ b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer.mdwn
@@ -0,0 +1,3 @@
+A couple times working in an annex manually, I accidentally did "git add" instead of "git annex add" and ended up with files checked into my repo instead of symlinks.  So now there is some file content in git, rather than in the annex.  Is there any way to root that out, or is it there forever?  (My limited knowledge of git says: it's there forever, unless maybe you go into the branches where it lives, do an interactive rebase to the time before it was added, remove that commit, replay history, and then garbage collect, but I have no idea if that would suddenly break git annex, and it sounds painful anyway.)
+
+If say I were a neat freak and wanted to just start over with a clean annex, I imagine the thing to do would be to just start the hell over -- and if I wanted to do that, the way to go would be to get into a full repository, do a "git annex uninit" and then throw away the .git directory, then do "git init" and "git annex init" and then "git annex add ." ?
diff --git a/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_1_752db25abb647804a1cc12c5b247378a._comment b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_1_752db25abb647804a1cc12c5b247378a._comment
new file mode 100644
index 0000000000..486d434803
--- /dev/null
+++ b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_1_752db25abb647804a1cc12c5b247378a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 1"
+ date="2012-12-02T05:41:56Z"
+ content="""
+You can rebase or use git-filter-branch to rewrite history. As long as you don't touch the git-annex branch, git-annex won't care, at all. Have at it!
+
+Your uninit plan would also work.
+"""]]
diff --git a/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_2_db6f4959c35732f72e7a90bd9f4c665c._comment b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_2_db6f4959c35732f72e7a90bd9f4c665c._comment
new file mode 100644
index 0000000000..9c7f35a771
--- /dev/null
+++ b/doc/forum/mistakenly_checked___42__files__42___into_an_annex.__bummer/comment_2_db6f4959c35732f72e7a90bd9f4c665c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 2"
+ date="2012-12-03T15:46:48Z"
+ content="""
+Thanks!  I ended up going with the uninit plan.
+"""]]
diff --git a/doc/forum/monitoring_disk_usage_by_different_repos_on_same_drive.mdwn b/doc/forum/monitoring_disk_usage_by_different_repos_on_same_drive.mdwn
new file mode 100644
index 0000000000..698413ce34
--- /dev/null
+++ b/doc/forum/monitoring_disk_usage_by_different_repos_on_same_drive.mdwn
@@ -0,0 +1,7 @@
+I've setup a server using gitolite3 to host repositories for our users. All these repos share the same disk (2.5 Tb ;-). They're mainly used as backup of all contents.
+
+I'd like to monitor disk usage (possibly with statistics related to git-annex specificities) for these repos.
+
+Would anyone suggest a solution (web based maybe), for easily monitoring the growth of the repos storage ?
+
+Thanks in advance.
diff --git a/doc/forum/monitoring_disk_usage_by_different_repos_on_same_drive/comment_1_04718e5f87a7e0521a3165bc9fc951a8._comment b/doc/forum/monitoring_disk_usage_by_different_repos_on_same_drive/comment_1_04718e5f87a7e0521a3165bc9fc951a8._comment
new file mode 100644
index 0000000000..17ad194039
--- /dev/null
+++ b/doc/forum/monitoring_disk_usage_by_different_repos_on_same_drive/comment_1_04718e5f87a7e0521a3165bc9fc951a8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-29T15:34:08Z"
+ content="""
+If you go to one of the repos and run `git annex info --json --bytes`
+you'll get a json object that has keys including "local annex size".
+You can extract that value, and feed it into a graphing engine, such
+as graphite, or whatever to generate graphs of the repo sizes over time.
+
+(Of course, you could do the same thing with `du`)
+"""]]
diff --git a/doc/forum/more_intelligent_copy_.mdwn b/doc/forum/more_intelligent_copy_.mdwn
new file mode 100644
index 0000000000..1c9889a74e
--- /dev/null
+++ b/doc/forum/more_intelligent_copy_.mdwn
@@ -0,0 +1,15 @@
+Hi,
+
+I noticed, that 
+
+git annex copy --to REMOTE FILES
+
+and 
+
+git annex copy --to REMOTE --not --in REMOTE FILES
+
+behave differently. The first does not check, whether file contents are already in the remote the latter does that. I realize that this mimics "normal" (UNIX) copy behaviour but I was not entirely certain this was desired.
+Depending on the type of the remote and its configuration (encryption) the latter is considerably faster.
+
+Just my two cents.
+
diff --git a/doc/forum/more_intelligent_copy_/comment_1_526f6a007f44f389ef7c904024752541._comment b/doc/forum/more_intelligent_copy_/comment_1_526f6a007f44f389ef7c904024752541._comment
new file mode 100644
index 0000000000..9b5866c5c5
--- /dev/null
+++ b/doc/forum/more_intelligent_copy_/comment_1_526f6a007f44f389ef7c904024752541._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="annexuser"
+ avatar="http://cdn.libravatar.org/avatar/6ae692503ee113b1ab7b329b40084d5c"
+ subject="comment 1"
+ date="2016-12-13T02:00:08Z"
+ content="""
+git annex copy --to REMOTE FILES --fast
+"""]]
diff --git a/doc/forum/more_intelligent_copy_/comment_2_7b3f5d2e9de4b13de821177db2f57bcd._comment b/doc/forum/more_intelligent_copy_/comment_2_7b3f5d2e9de4b13de821177db2f57bcd._comment
new file mode 100644
index 0000000000..474a068b65
--- /dev/null
+++ b/doc/forum/more_intelligent_copy_/comment_2_7b3f5d2e9de4b13de821177db2f57bcd._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-12-13T16:51:03Z"
+ content="""
+`git annex copy --fast` has the same behavior as `--not --in REMOTE`
+
+The reason this is not the default behavior is that git-annex's location
+tracking information can sometimes be out of date, and then those
+two will not copy some files despite their content not being any longer
+in the remote. This won't lead to data loss, but could result
+in unexpected behavior, and so the slower, more understandable behavior
+is used by default. (Although I sometimes go back and forth on switching
+it.)
+"""]]
diff --git a/doc/forum/move_files_under_git-annex_and_graft_history__63__.mdwn b/doc/forum/move_files_under_git-annex_and_graft_history__63__.mdwn
new file mode 100644
index 0000000000..d2520e1429
--- /dev/null
+++ b/doc/forum/move_files_under_git-annex_and_graft_history__63__.mdwn
@@ -0,0 +1,15 @@
+I do not know yet if that it possible since I have only cursory knowledge of former grafts in git and what new came to replace them.
+
+The use case:  we have a git-annex repo (heudiconv converted MRI data) where some files with sensitive information were added directly to git not git-annex.  We do not want to rewrite the entire history since that repository already saw a good number of clones and forks.  I wondered if we could
+
+1. move those files under git-annex
+2. establish a new history from that new tree object
+3. "graft" new history commit into the old "sensitive" one as to establish correspondence between the two
+   - I would expect then something like "git pull --ff-only" to work for people seamlessly jumping between those points
+4. git push only new history to github thus not revealing old  history with sensitive data under git
+
+
+Joey, WDYT? any words of wisdom?
+
+[[!meta author=yoh]]
+[[!tag projects/repronim?]]
diff --git a/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_1_345f9a32f5fc1ea21af9fe18f902d1b0._comment b/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_1_345f9a32f5fc1ea21af9fe18f902d1b0._comment
new file mode 100644
index 0000000000..296d534232
--- /dev/null
+++ b/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_1_345f9a32f5fc1ea21af9fe18f902d1b0._comment
@@ -0,0 +1,78 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-02-09T20:01:01Z"
+ content="""
+Well `git replace` does turn out to be able to do this. With some caveats.
+
+I started with this history:
+
+	6df78e79d688de8392d952dc8705d094384ed2c0 add file (accidentially to git)
+	3235872149f1767efd282635ca12ec2f9056f9cc initial commit
+
+Then amended 6df78e, following the usual
+process to convert git to annexed, as outlined in [[tips/largefiles]],
+producing commit f36b42e.
+
+Then `git replace 6df78e f36b42e` and the log changed to:
+
+	6df78e79d688de8392d952dc8705d094384ed2c0 (replaced) add file (to annex)
+	3235872149f1767efd282635ca12ec2f9056f9cc initial commit
+
+Note that, when there are further commits made on top of
+the bad commit, they all would need to be replaced with amended commits
+as well.
+
+I'd already pushed to origin before this. And origin still showed the bad
+commit in its log. But pushing the replace refs fixed that:
+
+	git push origin 'refs/replace/*'
+
+Now looking at the origin repo showed the same amended history.
+
+In another clone, the old history is still visible, but that can be fixed, by running:
+
+	git fetch origin 'refs/replace/*:refs/replace/*'
+
+Then I deleted the git object for 6df78e from the origin repo, along with the
+blob object that contained the content of the file accidentially added to git.
+
+This is where it fell down, because cloning from that origin repo then
+fails:
+
+	joey@darkstar:~/tmp/test>git clone demo.git/ democlone
+	Cloning into 'democlone'...
+	done.
+	fatal: update_ref failed for ref 'HEAD': cannot update ref 'refs/heads/master': trying to write ref 'refs/heads/master' with nonexistent object 6df78e79d688de8392d952dc8705d094384ed2c0
+
+But, that can be worked around. Just need to make an additional commit on top of the
+replaced commit, so git clone will see a commit that has not been deleted. I did that,
+and:
+
+	joey@darkstar:~/tmp/test>git clone demo.git/ democlone
+	Cloning into 'democlone'...
+	done.
+	joey@darkstar:~/tmp/test>cd democlone
+	joey@darkstar:~/tmp/test/democlone>git log
+	error: Could not read 6df78e79d688de8392d952dc8705d094384ed2c0
+	fatal: Failed to traverse parents of commit 167b6e6842a669bc90925dd4b6df0c1a6ec4c141
+
+	joey@darkstar:~/tmp/test/democlone>git fetch origin 'refs/replace/*:refs/replace/*'
+	From /home/joey/tmp/test/demo
+	 * [new ref]         refs/replace/6df78e79d688de8392d952dc8705d094384ed2c0 -> refs/replace/6df78e79d688de8392d952dc8705d094384ed2c0
+	joey@darkstar:~/tmp/test/democlone>git log --pretty=oneline
+	167b6e6842a669bc90925dd4b6df0c1a6ec4c141 (HEAD -> master, origin/master, origin/HEAD) empty
+	6df78e79d688de8392d952dc8705d094384ed2c0 (replaced) add file (to annex)
+	3235872149f1767efd282635ca12ec2f9056f9cc initial commit
+
+So, you can do this if you're ok with clones needing to manually fetch the replace refs
+in order to access the replaced history.
+
+And of course, existing clones need to be manually updated to fetch the replace refs.
+And probably ought to have the bad objects deleted out of their .git/objects/
+to avoid accidental data leakage.
+
+I'd also caution that, if the history you rewrite with `git replace` contains a lot
+of commits, the number of refs in refs/replace/* could get large, and a large number
+of git refs can be innefficient in various ways.
+"""]]
diff --git a/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_2_aab850db06cbd3c33067cff567d2699e._comment b/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_2_aab850db06cbd3c33067cff567d2699e._comment
new file mode 100644
index 0000000000..9aa0709a5a
--- /dev/null
+++ b/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_2_aab850db06cbd3c33067cff567d2699e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2024-02-09T21:02:09Z"
+ content="""
+Oh and I doubt github lets you delete .git/object files from a repo hosted
+there, so you might need to delete the repo and re-create it.
+
+Given how github shares git object stores amoung forks, even that might not
+be enough to eliminate the objects from it.
+"""]]
diff --git a/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_3_4cff971451dd7038ffe8f7f2fa3b28c9._comment b/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_3_4cff971451dd7038ffe8f7f2fa3b28c9._comment
new file mode 100644
index 0000000000..0ab0b04460
--- /dev/null
+++ b/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_3_4cff971451dd7038ffe8f7f2fa3b28c9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2024-02-09T21:58:56Z"
+ content="""
+Thank you!  Yet to try/follow the steps. FWIW -- we have not pushed anything to github yet, so we have everything only locally and thus should potentially be able to not reveal older objects.
+"""]]
diff --git a/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_4_73e37a27ae3ff6673f34d8b1a6bed4a0._comment b/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_4_73e37a27ae3ff6673f34d8b1a6bed4a0._comment
new file mode 100644
index 0000000000..d4fb071421
--- /dev/null
+++ b/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_4_73e37a27ae3ff6673f34d8b1a6bed4a0._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2024-02-10T16:06:26Z"
+ content="""
+A simpler approach is to make a redacted history, publish that, and locally
+replace the redacted history with the unredacted history.
+
+1. make a new empty bare repo (eg on github)
+2. git branch unredacted-master master
+3. git branch -D master
+4. start a new master branch at the commit before the problem file
+   was added, that contains one or more rewritten commits, where the problem
+   file is added to the annex (eg, use `git merge --squash
+   unredacted-master` and the convert the problem file to annexed before
+   committing)
+4. push the (new) master branch to the new bare repo
+5. `git replace master unredacted-master`
+
+That last step lets you locally access all your unredacted history locally,
+but pushes of further changes to master will still push the redacted history.
+
+You can do the same git replace in each existing clone of the repository
+and keep on referring to the unredacted history in those, while publishing
+the redacted history.
+"""]]
diff --git a/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_5_d536cb5c2622d18802e6a32b03102f14._comment b/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_5_d536cb5c2622d18802e6a32b03102f14._comment
new file mode 100644
index 0000000000..f992f50f2b
--- /dev/null
+++ b/doc/forum/move_files_under_git-annex_and_graft_history__63__/comment_5_d536cb5c2622d18802e6a32b03102f14._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2024-02-10T16:49:33Z"
+ content="""
+Wrote up a tip with an even more polished version of that,
+[[tips/redacting_history_by_converting_git_files_to_annexed]]
+"""]]
diff --git a/doc/forum/moving_annex_across_filesystems.mdwn b/doc/forum/moving_annex_across_filesystems.mdwn
new file mode 100644
index 0000000000..28a6852f7d
--- /dev/null
+++ b/doc/forum/moving_annex_across_filesystems.mdwn
@@ -0,0 +1,26 @@
+git-annex has this peculiar thing that blobs stored in `.git/annex/objects` are readonly, even for the current user. Naturally, git-annex itself bypasses those restrictions in some way to create/remove/move those files from time to time, but for other tools, this can actually be a problem. For example, if a user wants to completely remove a dead repository, they will naively try to just delete it (say) in their file manager, which will fail with permission errors.
+
+Similarly, moving a repository across filesystem boundaries will create problems, as this effectively means copying the files and removing the original copy. Normally, this should be a safe thing to do, but git-annex forbids it.
+
+The workaround I have found is to do exactly that: copy the files and then remove the original. I used the "tar + pv" hack to get a progress bar:
+
+    tar cf - Photos | pv -s 406G | ( cd /srv ; tar xf - )
+
+Just for good measure, I then also run fsck on the repository copy:
+
+    git -C /srv/Photos annex fsck --quiet --incremental
+
+If that succeeds, I then remove the original repository:
+
+    sudo rm -r Photos
+
+Notice how it's simpler for me to do `sudo rm` than the alternative:
+
+    chmod -R u+w Photos
+    \rm -r Photos
+
+I believe that's because rm won't fail to remove files if they are readonly when running as root.
+
+Anyways - what's the proper way of doing this? I know I could `git clone` the repository and `git get` everything, but that would create another repository with a new UUID. That's duplication I do not want.
+
+Thanks for the advice! -- [[anarcat]]
diff --git a/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository.mdwn b/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository.mdwn
new file mode 100644
index 0000000000..b9500fa10e
--- /dev/null
+++ b/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository.mdwn
@@ -0,0 +1,19 @@
+I have a Desktop computer at home and another at work, and work from home every other day.  I'd like to use git-annex assistant to keep my git checkouts in sync across both of them.  I may be a bit unusual in that I don't always commit before going home.
+
+I also would like to have anything in the git stash synchronized between the two, the .git/config file, etc.
+
+So to be clear, I have a file structure like the following:
+
+    ./annex/.git
+    ./annex/project/README.md
+    ./annex/project/.git
+    ./annex/project2/README.md
+    ./annex/project2/.git
+
+In my testing it seems that the "project/.git" folders aren't synchronized between my two desktops, even though the rest of the files are.  A workaround is to rename "project/.git" to something else, like "project/.gitfoo", and then use --git-dir when issuing my git commands.
+
+Is this something that can be worked around?  I apologize if this is covered elsewhere, as I wasn't thinking of the right terms to search for.
+
+I've looked through the code and can't find anything obvious.  I imagine this is because git hard-codes all ".git" subdirectories as something it should ignore.
+
+Is there a better workaround?  I realize this is probably a niche use case.
diff --git a/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_1_419b27cb1c71bce021ef9f2e471aa92e._comment b/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_1_419b27cb1c71bce021ef9f2e471aa92e._comment
new file mode 100644
index 0000000000..8d698b1ba6
--- /dev/null
+++ b/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_1_419b27cb1c71bce021ef9f2e471aa92e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jewel"
+ ip="23.30.55.105"
+ subject="comment 1"
+ date="2014-10-12T05:22:03Z"
+ content="""
+Now I've found the relevant bug: `http://git-annex.branchable.com/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X`.
+
+Note the symlink workaround near the end.  A quick test shows that it's working great.  I'll try it out for a few months and report back.
+"""]]
diff --git a/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_2_dae4c7a42080dd89150159b2946839b1._comment b/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_2_dae4c7a42080dd89150159b2946839b1._comment
new file mode 100644
index 0000000000..2f574c8fe5
--- /dev/null
+++ b/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_2_dae4c7a42080dd89150159b2946839b1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 2"
+ date="2014-10-12T17:30:23Z"
+ content="""
+This is fundamentally not a good idea. All  it takes is one conflict inside the .git directories, and your git repositories will be trashed/corrupted. The page you link to has comments explaining why.
+"""]]
diff --git a/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_3_9d9fa65559ba4bb0e4676289b5a65684._comment b/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_3_9d9fa65559ba4bb0e4676289b5a65684._comment
new file mode 100644
index 0000000000..483ff007e8
--- /dev/null
+++ b/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_3_9d9fa65559ba4bb0e4676289b5a65684._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jewel"
+ ip="23.30.55.105"
+ subject="comment 3"
+ date="2014-10-12T19:04:00Z"
+ content="""
+Thanks for the warning.  I'll keep hourly incremental backups (using obnam) on each computer just in case something terrible happens.
+"""]]
diff --git a/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_4_4e89b3590cc33b2565cd173ef7c85013._comment b/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_4_4e89b3590cc33b2565cd173ef7c85013._comment
new file mode 100644
index 0000000000..b32abd3ecd
--- /dev/null
+++ b/doc/forum/multiple_git_repositories_inside_git_annex_assistant_repository/comment_4_4e89b3590cc33b2565cd173ef7c85013._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlM_DRhi_5pJrTA0HbApHR25iAgy-NBXTY"
+ nickname="Tor Arne"
+ subject="comment 4"
+ date="2014-10-14T22:09:37Z"
+ content="""
+If I use git-annex to keep my home and work computer in sync, the conflict would only happen if I somehow manage to make a change in the git repo on one machine that's not propagated to the other straight away (eg, network down), and I then modify the git repo of the other as well?
+
+Could git-annex have a different merge strategy in this case, not try to merge anything under .git and give a warning?
+
+"""]]
diff --git a/doc/forum/multiple_repositories_single_backup.mdwn b/doc/forum/multiple_repositories_single_backup.mdwn
new file mode 100644
index 0000000000..10f8c0e435
--- /dev/null
+++ b/doc/forum/multiple_repositories_single_backup.mdwn
@@ -0,0 +1,6 @@
+hi
+
+is it possible to have multiple repositories that share single backup directory ?
+
+for example.
+i have mp3, docs on my laptop as separate repositories. i would like to use single backup directory that is on my usb drive.
diff --git a/doc/forum/multiple_repositories_single_backup/comment_1_4a479fa78e0b366fcff1a27bc37081de._comment b/doc/forum/multiple_repositories_single_backup/comment_1_4a479fa78e0b366fcff1a27bc37081de._comment
new file mode 100644
index 0000000000..52da6a2724
--- /dev/null
+++ b/doc/forum/multiple_repositories_single_backup/comment_1_4a479fa78e0b366fcff1a27bc37081de._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2013-12-29T20:29:26Z"
+ content="""
+If you set up an identically configured special remote in the same location for each of your separate mp3 and docs repositories, then yes, you can store files for both of them in it. In the unlikely case where you have the same file in both mp3 and docs, only one copy will be stored in the remote. (Unless it's using encryption, which will tend to defeat that.)
+
+It should work ok, but unless you're trying to get deduplication like that, I don't see any reason to do it rather than having a separate special remote for each of the separate git repositories.
+
+(Also, I'm talking about special remotes here, not git remotes. If you add the same git remote to 2 separate repositories, then `git annex sync` will connect them all together.)
+"""]]
diff --git a/doc/forum/multiple_repositories_single_backup/comment_2_bbe19eec0969385a0d4682bf9e9de21a._comment b/doc/forum/multiple_repositories_single_backup/comment_2_bbe19eec0969385a0d4682bf9e9de21a._comment
new file mode 100644
index 0000000000..bac577ce99
--- /dev/null
+++ b/doc/forum/multiple_repositories_single_backup/comment_2_bbe19eec0969385a0d4682bf9e9de21a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkNE-H4vEcbcGndxq5daT8qUb7yIf7r1OE"
+ nickname="Łukasz"
+ subject="comment 2"
+ date="2013-12-29T21:34:19Z"
+ content="""
+thx for reply. i think i will stick with separate directories for every repositiry
+
+mp3 on laptop -> mp3-backup directory on usb drive
+docs on laptop -> docs-backup on usb drive
+"""]]
diff --git a/doc/forum/multiple_repositories_single_backup/comment_3_1b18ea058e3eb34852055cffe51de176._comment b/doc/forum/multiple_repositories_single_backup/comment_3_1b18ea058e3eb34852055cffe51de176._comment
new file mode 100644
index 0000000000..4accf7f07b
--- /dev/null
+++ b/doc/forum/multiple_repositories_single_backup/comment_3_1b18ea058e3eb34852055cffe51de176._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://cstork.org/"
+ nickname="Chris Stork"
+ subject="Using different git branches"
+ date="2014-01-14T09:12:19Z"
+ content="""
+This might not be practical (especially for a non-technical user) but wouldn't it be possible to share a (bare) git-annex repo for backup if the other non-bare repos use different branches of the same git repo? (These non-bare repos could also share their .git directory.) Hmm, I don't see this discussed much...
+"""]]
diff --git a/doc/forum/multiple_routes_to_same_repository.mdwn b/doc/forum/multiple_routes_to_same_repository.mdwn
new file mode 100644
index 0000000000..a94acac2f8
--- /dev/null
+++ b/doc/forum/multiple_routes_to_same_repository.mdwn
@@ -0,0 +1,2 @@
+I am trying to configure the local repo to be connected with remote computer. It can either find this computer on local network using local host name, or go through public IP host where I have ssh tunnel. First confusing thing is, that when setting up remote server, it successfuly establishes connection, but then asks me if the folder should be git or rsync - I believe this step should be skipped if the git repo is already there. Also choosing repository group should be detected from the repo itself.
+But the real problem is that I cannot add the public IP repo at all. Is this a known limitation?
diff --git a/doc/forum/multiple_routes_to_same_repository/comment_1_26c1734d41d5374f18fc688d862d6b8e._comment b/doc/forum/multiple_routes_to_same_repository/comment_1_26c1734d41d5374f18fc688d862d6b8e._comment
new file mode 100644
index 0000000000..94eadcd557
--- /dev/null
+++ b/doc/forum/multiple_routes_to_same_repository/comment_1_26c1734d41d5374f18fc688d862d6b8e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmZ9EwisYI1DDev8HXY6zFjPrLKt60-3QI"
+ nickname="Yo"
+ subject="comment 1"
+ date="2013-06-24T12:23:15Z"
+ content="""
+I believe I have a similar set up as you're trying to achieve. What I did was just add a repository using the public domain name only (DDNS). My home router seems to be smart enough to realize the IP the domain name resolves to is its own, so I get gigabit speeds when at home, and I can still access it when I'm not at home.
+"""]]
diff --git a/doc/forum/multiple_routes_to_same_repository/comment_2_d119ab485fb2d5512c15372efdb2327d._comment b/doc/forum/multiple_routes_to_same_repository/comment_2_d119ab485fb2d5512c15372efdb2327d._comment
new file mode 100644
index 0000000000..48cae0211b
--- /dev/null
+++ b/doc/forum/multiple_routes_to_same_repository/comment_2_d119ab485fb2d5512c15372efdb2327d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 2"
+ date="2013-06-25T20:05:46Z"
+ content="""
+I don't see anything that prevents you from adding two repositories that use different names for the same server.
+"""]]
diff --git a/doc/forum/multiple_sym_links___40__for_tagging_photos__41____63__.mdwn b/doc/forum/multiple_sym_links___40__for_tagging_photos__41____63__.mdwn
new file mode 100644
index 0000000000..c5c6f3a94b
--- /dev/null
+++ b/doc/forum/multiple_sym_links___40__for_tagging_photos__41____63__.mdwn
@@ -0,0 +1,11 @@
+I saw a cool page talking about "tagging" photos by using symlinks: http://www.trueelena.org/computers/articles/photo_management_with_git-annex_and_bash.html
+
+so say I have a photo in git annex, called DSC_3285.JPG, which of course is really a symlink to ../.git/annex/objects/Zk/kj/WORM-s5296770-m1338516288--DSC_3285.JPG/WORM-s5296770-m1338516288--DSC_3285.JPG.
+
+I want to make an additional link to that photo in a directory called tags/.
+
+should I link to the symlink (DSC_3285.JPG), or to the annexed file? (../.git/annex/objects/Zk/kj/WORM-s5296770-m1338516288--DSC_3285.JPG/WORM-s5296770-m1338516288--DSC_3285.JPG)
+
+I might occasionally rename DSC_3285.JPG or edit the photo itself. will the git annex commit hooks update both links, or should I prepare a script to update links in tags/ after I change DSC_3285 or the annexed data? 
+
+thank you.
diff --git a/doc/forum/multiple_sym_links___40__for_tagging_photos__41____63__/comment_1_96beb9ea895c80285748adb940b4f57d._comment b/doc/forum/multiple_sym_links___40__for_tagging_photos__41____63__/comment_1_96beb9ea895c80285748adb940b4f57d._comment
new file mode 100644
index 0000000000..b4d2433aa3
--- /dev/null
+++ b/doc/forum/multiple_sym_links___40__for_tagging_photos__41____63__/comment_1_96beb9ea895c80285748adb940b4f57d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.236"
+ subject="comment 1"
+ date="2012-09-05T19:56:06Z"
+ content="""
+I'd recommend linking to the annexed file. Which is what `cp -a` does BTW. Then it'll just be a peice of content that is used by more than one filename, which git-annex handles well. However, if you then edited
+one file, git-annex would not update the other link to point to the new content.
+"""]]
diff --git a/doc/forum/multiple_sym_links___40__for_tagging_photos__41____63__/comment_2_985065c1feed9300631dac7a2701f669._comment b/doc/forum/multiple_sym_links___40__for_tagging_photos__41____63__/comment_2_985065c1feed9300631dac7a2701f669._comment
new file mode 100644
index 0000000000..a53fe06b5e
--- /dev/null
+++ b/doc/forum/multiple_sym_links___40__for_tagging_photos__41____63__/comment_2_985065c1feed9300631dac7a2701f669._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnh0pv5PyOJH8dHB1Ly2rHJM4nvVd17CZ0"
+ nickname="Kevin"
+ subject="comment 2"
+ date="2012-09-05T19:57:36Z"
+ content="""
+Thank you very much! (for your answer, and for git annex)
+"""]]
diff --git a/doc/forum/multiple_urls_for_the_same_UUID.mdwn b/doc/forum/multiple_urls_for_the_same_UUID.mdwn
new file mode 100644
index 0000000000..2f8106b597
--- /dev/null
+++ b/doc/forum/multiple_urls_for_the_same_UUID.mdwn
@@ -0,0 +1,26 @@
+I've been doing a sort of experiment but I'm not sure if it's working or, really, how to even tell.
+
+I have two macbooks that are both configured as clients as well as a USB HDD, an rsync endpoint on a home NAS, and a glacier endpoint.
+
+For the purposes of this example, lets call the macbooks "chrissy" and "brodie". Chrissy's was initially configured with a remote for brodie with the url as
+
+    ssh://Brodie.88195848.members.btmm.icloud.com./Users/akraut/Desktop/annex
+
+This allows me to leverage the "Back To My Mac" free IPv6 roaming I get from Apple.  Now, occasionally, that dns resolution fails. Since I'm frequently on the same network, I can also use the mDNS address of brodie.local. which is much more reliable.
+
+So my brilliant/terrible idea was to put this in my git config:
+
+    [remote "brodie"]
+    	url = ssh://Brodie.88195848.members.btmm.icloud.com./Users/akraut/Desktop/annex
+    	fetch = +refs/heads/*:refs/remotes/brodie/*
+    	annex-uuid = BF4BCA6D-9252-4B5B-BE12-36DD755FAF4B
+    	annex-cost-command = /Users/akraut/Desktop/annex/tools/annex-cost6.sh Brodie.88195848.members.btmm.icloud.com.
+    [remote "brodie-local"]
+    	url = ssh://brodie.local./Users/akraut/Desktop/annex
+    	fetch = +refs/heads/*:refs/remotes/brodie/*
+    	annex-uuid = BF4BCA6D-9252-4B5B-BE12-36DD755FAF4B
+    	annex-cost-command = /Users/akraut/Desktop/annex/tools/annex-cost.sh brodie.local.
+
+Is there any reason why I shouldn't do this? Is annex smart enough to know that it can reach the same remote through both urls? Will the cost calculations be considered and the "local" url chosen if it's cost is less than the other?
+
+(I posted the annex-cost.sh stuff at [[forum/Calculating Annex Cost by Ping Times]].)
diff --git a/doc/forum/multiple_urls_for_the_same_UUID/comment_1_de7410d8824a864c4d106c9f1afaec3f._comment b/doc/forum/multiple_urls_for_the_same_UUID/comment_1_de7410d8824a864c4d106c9f1afaec3f._comment
new file mode 100644
index 0000000000..c06cf01c35
--- /dev/null
+++ b/doc/forum/multiple_urls_for_the_same_UUID/comment_1_de7410d8824a864c4d106c9f1afaec3f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.6"
+ subject="comment 1"
+ date="2012-12-30T04:19:48Z"
+ content="""
+Yes, this is absolutely supported. If it's trying to `get` a file and it fails to access the first remote, it'll even automatically fall back to using the second. I do similar things with my own remote, for example I have a foo that uses ssh with a foo-local that uses NFS.
+"""]]
diff --git a/doc/forum/multiple_urls_for_the_same_UUID/comment_2_309a86cf7e08448be64357a30d8b56ae._comment b/doc/forum/multiple_urls_for_the_same_UUID/comment_2_309a86cf7e08448be64357a30d8b56ae._comment
new file mode 100644
index 0000000000..9d0dc9f66b
--- /dev/null
+++ b/doc/forum/multiple_urls_for_the_same_UUID/comment_2_309a86cf7e08448be64357a30d8b56ae._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="multiple ways to access a special remote?"
+ date="2013-07-10T05:52:28Z"
+ content="""
+The use case is like this: an external USB drive could be accessed both locally (as a special directory remote) or it could be mounted remotely (then it would need to be an rsync special remote).
+Is there a way to handle this?
+
+Failing that, can one switch the same remote from being a directory to an rsync without having to --move all of the content?
+
+Finally, what's the best way to check directory remote's directory= parameter?
+"""]]
diff --git a/doc/forum/multiple_urls_for_the_same_UUID/comment_3_fa97a45fc1392935fd5e0714db999bc2._comment b/doc/forum/multiple_urls_for_the_same_UUID/comment_3_fa97a45fc1392935fd5e0714db999bc2._comment
new file mode 100644
index 0000000000..c6f5dfde91
--- /dev/null
+++ b/doc/forum/multiple_urls_for_the_same_UUID/comment_3_fa97a45fc1392935fd5e0714db999bc2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 3"
+ date="2013-07-10T16:38:04Z"
+ content="""
+@Michael, like I said above, this use case is completely supported. That's why git-annex uses UUIDs to uniquely identify repositories, no matter where or how many urls are used for them. 
+
+Just set up the remotes you need, and if they end up pointing to the same repository by different routes, git-annex will automatically notice.
+
+---
+
+The directory= parameter used when initializing a directory remote is only used to set up the remote in the .git/config file. It is not stored anywhere else, since the directory could be mounted at different locations on different computers, eg when a drive is moved between computers.
+"""]]
diff --git a/doc/forum/multiple_urls_for_the_same_UUID/comment_4_139178b1ba45b62eec0c89a660c0c81e._comment b/doc/forum/multiple_urls_for_the_same_UUID/comment_4_139178b1ba45b62eec0c89a660c0c81e._comment
new file mode 100644
index 0000000000..945aa3b6bf
--- /dev/null
+++ b/doc/forum/multiple_urls_for_the_same_UUID/comment_4_139178b1ba45b62eec0c89a660c0c81e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 4"
+ date="2013-07-10T21:26:06Z"
+ content="""
+Very cool, thanks Joey.
+"""]]
diff --git a/doc/forum/multiple_urls_for_the_same_UUID/comment_5_7237986a34228282c6b764309afc1d57._comment b/doc/forum/multiple_urls_for_the_same_UUID/comment_5_7237986a34228282c6b764309afc1d57._comment
new file mode 100644
index 0000000000..3014e6c042
--- /dev/null
+++ b/doc/forum/multiple_urls_for_the_same_UUID/comment_5_7237986a34228282c6b764309afc1d57._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkMTPqZZWoz396ABpx6nh3osxKQCFaSW6M"
+ nickname="Mark"
+ subject="annex sync when inside an itinerant repository"
+ date="2015-02-12T12:54:21Z"
+ content="""
+I'm having trouble with this where the different remotes have the same URL but different UUIDs. My situation is a repository on a USB drive that can be plugged into one of two machines and used to transport large files between them. On each machine there is a local repository in a consistent location, so I can rely on paths to things in the repos being consistent across machines. Each repo obviously has a different UUID. The USB repo has remotes for local filesystem access and remotes for over-the-network access as a convenience - something like this:
+
+    [remote \"host1\"]
+        url = /m/stuff
+        fetch = +refs/heads/*:refs/remotes/host1/*
+        annex-uuid = ce6175ba-4a0d-49e6-88b1-615dac7a37c1
+    [remote \"host1-net\"]
+        url = ssh://host1.network/m/stuff
+        fetch = +refs/heads/*:refs/remotes/host1/*
+        annex-uuid = ce6175ba-4a0d-49e6-88b1-615dac7a37c1
+    [remote \"host2\"]
+        url = /m/stuff
+        fetch = +refs/heads/*:refs/remotes/host2/*
+        annex-uuid = f7e3fbe8-f7f5-4231-a885-a72a46680d0b
+    [remote \"host2-net\"]
+        url = ssh://host2.network/m/stuff
+        fetch = +refs/heads/*:refs/remotes/host2/*
+        annex-uuid = f7e3fbe8-f7f5-4231-a885-a72a46680d0b
+
+The over-the-network path is useful for keeping everything in sync, but it doesn't have enough bandwidth to sensibly sync the content as well.
+
+If I run 'git annex sync' in this repository while it's attached to host1 I'd hope it would sync with host1 and host2-net, as those are the URLs through which the two repositories can be reached. What actually happens is that it syncs with all of the repositories and updates the annex-uuid of remote 'host2' to be the UUID of the host1 repository. It also obviously gets a bit confused because it updates the remote branches for host2 from host1.
+
+Is there some way to configure it so that sync works with all repositories based on unique uuid values, rather than all remotes?
+
+
+"""]]
diff --git a/doc/forum/multiple_urls_for_the_same_UUID/comment_6_392819ba657569a1b997b58aa921a0ad._comment b/doc/forum/multiple_urls_for_the_same_UUID/comment_6_392819ba657569a1b997b58aa921a0ad._comment
new file mode 100644
index 0000000000..783b9a41a7
--- /dev/null
+++ b/doc/forum/multiple_urls_for_the_same_UUID/comment_6_392819ba657569a1b997b58aa921a0ad._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnm19dBCRphmtjXfopm_NpvnRwz-qIJ2Tw"
+ nickname="Remi"
+ subject="comment 6"
+ date="2015-02-12T14:47:38Z"
+ content="""
+I had the same problem, and I solved it using a host specific directory with symlink:
+
+On host \"host1\", I've a directory named \"/home/me/host1/\" that contain a symlink \"mygitrepos\" to \"/home/me/mygitrepos/\".
+On host \"host2\", I've a directory named \"/home/me/host2/\" that contain a symlink \"mygitrepos\" to \"/home/me/mygitrepos/\".
+
+On the usb drive, the remote are set as:
+
+    [remote \\"host1\\"]
+        url = /home/me/host1/mygitrepos
+        fetch = +refs/heads/*:refs/remotes/host1/*
+        annex-uuid = ce6175ba-4a0d-49e6-88b1-615dac7a37c1
+    [remote \\"host2\\"]
+        url = /home/me/host2/mygitrepos
+        fetch = +refs/heads/*:refs/remotes/host2/*
+        annex-uuid = f7e3fbe8-f7f5-4231-a885-a72a46680d0b
+
+(I didn't set the net remote, but it should work). With this added indirection I protect myself against git (and git-annex) confusion.
+
+"""]]
diff --git a/doc/forum/multiple_urls_for_the_same_UUID/comment_7_276cb5d94cbd10e9fc7d1cf4ac607273._comment b/doc/forum/multiple_urls_for_the_same_UUID/comment_7_276cb5d94cbd10e9fc7d1cf4ac607273._comment
new file mode 100644
index 0000000000..a80bffe10c
--- /dev/null
+++ b/doc/forum/multiple_urls_for_the_same_UUID/comment_7_276cb5d94cbd10e9fc7d1cf4ac607273._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2015-02-12T20:25:12Z"
+ content="""
+You have two configured git remotes, host1 and host2, with the same
+"url = /m/stuff". Only one of these remotes can be accessed at a time,
+depending on where the drive is docked.
+
+So, why not just combine those two remote configs
+into a single remote. Call it "host".
+
+git-annex will automatically notice when the uuid of the repository
+pointed to by "host" changes, and it will update the .git/config
+appropriately.
+
+That BTW, happens to be just how I use git-annex with my own USB drive,
+and it works great.
+
+---
+
+git annex sync will still try to sync with "host1-net" and "host2-net", as well
+as which ever one of the two "host" points to. There's a small redundancy
+there, but since it will sync with "host" first, as it knows local file
+access is less expensive, the redundant sync will not involve much work.
+
+"""]]
diff --git a/doc/forum/multiple_urls_for_the_same_UUID/comment_8_c44144c677d54aaea6e900d0d7e000a3._comment b/doc/forum/multiple_urls_for_the_same_UUID/comment_8_c44144c677d54aaea6e900d0d7e000a3._comment
new file mode 100644
index 0000000000..f333c2bc0e
--- /dev/null
+++ b/doc/forum/multiple_urls_for_the_same_UUID/comment_8_c44144c677d54aaea6e900d0d7e000a3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkMTPqZZWoz396ABpx6nh3osxKQCFaSW6M"
+ nickname="Mark"
+ subject="comment 8"
+ date="2015-02-13T13:55:21Z"
+ content="""
+Ah, ok. So it doesn't cause any issues that the host/* remote branches will also keep getting swapped from one repository to another? The operation of `git annex sync` is sufficiently (and happily) opaque to me, so I was concerned that this might break some of its basic assumptions.
+"""]]
diff --git a/doc/forum/multiple_urls_for_the_same_UUID/comment_9_38f3007635b0a7b7d30bad0af8a2d0a9._comment b/doc/forum/multiple_urls_for_the_same_UUID/comment_9_38f3007635b0a7b7d30bad0af8a2d0a9._comment
new file mode 100644
index 0000000000..5a89f6e16b
--- /dev/null
+++ b/doc/forum/multiple_urls_for_the_same_UUID/comment_9_38f3007635b0a7b7d30bad0af8a2d0a9._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2015-02-17T21:43:16Z"
+ content="""
+It's entirely expected and normal for git-annex to update the UUID
+of a remote with `url = somepath` when it notices that the repo at 
+`somepath` has changed.
+
+This is what you want to happen. If git-annex didn't notice and react to
+the UUID change, its location tracking information (for UUID A) would be
+inconsistent with the actual status of the repo (using UUID B).
+"""]]
diff --git a/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__.mdwn b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__.mdwn
new file mode 100644
index 0000000000..46257f6461
--- /dev/null
+++ b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__.mdwn
@@ -0,0 +1,7 @@
+Just started looking at git-annex and it's very interesting to me as I manage a large tree of different types of projects, spread across two computers and some hard-drives (some backups, some offline resources and archives)
+
+But one question that's bothering me. A lot of my projects are already git repos. Is it possible to use git-annex with this tree or will the gits fight unless I explicitly make them submodules? 
+
+cheers
+
+Phil
diff --git a/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_1_ac45ad341f026289ce56183b9ff463af._comment b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_1_ac45ad341f026289ce56183b9ff463af._comment
new file mode 100644
index 0000000000..8e409bb5e0
--- /dev/null
+++ b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_1_ac45ad341f026289ce56183b9ff463af._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="git-annex is git"
+ date="2016-04-22T07:44:06Z"
+ content="""
+git-annex is first git, then some additional very neat functionality. Being git, it refuses to handle git repositories as that would create all kinds of potential confusion and inefficiency.
+
+Submodules would be a way to go, if you like how they work. Or you could just ignore the git repos, as you probably have them replicated somewhere else.
+"""]]
diff --git a/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_53e0ffe901a1a1c22361bfd7cf71affd._comment b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_53e0ffe901a1a1c22361bfd7cf71affd._comment
new file mode 100644
index 0000000000..73a2e8ce06
--- /dev/null
+++ b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_53e0ffe901a1a1c22361bfd7cf71affd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="interstar@551341a1dbca18391e90a3f719eae492868ceb7a"
+ nickname="interstar"
+ subject="comment 2"
+ date="2016-04-22T12:38:16Z"
+ content="""
+OK. Thanks.
+"""]]
diff --git a/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_f7416c26daca543ad08c11e187e1589e._comment b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_f7416c26daca543ad08c11e187e1589e._comment
new file mode 100644
index 0000000000..9ad9c73417
--- /dev/null
+++ b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_f7416c26daca543ad08c11e187e1589e._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""furthermore.."""
+ date="2016-04-22T18:52:09Z"
+ content="""
+You might also use <http://myrepos.branchable.com/> as a somewhat
+more flexible alternative to submodules.
+
+It's worth thinking about what would happen if you were able to check a git
+repository into a git (annex) repository. A git repository contains files
+like `.git/index` that are git internals, and binary files. Now what
+happens if you have two checkouts of that nested git-in-git repository, and
+git writes two different versions of the `.git/index` file? You'd get a
+merge conflict that you have no way of resolving, involving two versions of
+an internal use binary file. This is a lot worse than a merge conflict involving
+some regular binary file like a jpeg, because at least with jpegs you can
+look at the two versions of the file and pick the better one.
+
+While git prevents checking in `.git` directories, you could technically work
+around it, if you really wanted to, by eg using `GIT_DIR` to rename
+the `.git` directory to something else. But it's just setting yourself up for
+unresolvable merge conflicts and pain.
+
+It's likewise not good to check in other version control system
+directories, like `.svn`, `.bzr`, or `.hg` into git repositories or
+vice-versa.
+
+Sometimes people complain that the git-annex assistant should support
+syncing nested git repositories, because after all other directory syncing
+tools like dropbox support that. But, a little known fact about dropbox is
+that it too can end up with a conflicted merge type situation, and when
+this happens it will do *something* to auto-resolve it. That something
+almost certianly does not include leaving the git repository what was
+stored in dropbox in an ideal state. So, while people put git repos into
+dropbox and get away with it, they are just being lucky to not run into the
+edge cases where doing that blows up.
+"""]]
diff --git a/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_4_9c6386710387f7334ea44c1de7cc8729._comment b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_4_9c6386710387f7334ea44c1de7cc8729._comment
new file mode 100644
index 0000000000..a411d8de88
--- /dev/null
+++ b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_4_9c6386710387f7334ea44c1de7cc8729._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="did this today"
+ date="2016-04-25T20:40:02Z"
+ content="""
+it's interesting to find this discussion, I just finished implementing this on my system.
+
+I've been storing bare repos in annex in order to back them up with the same system.  I have really huge files in some of my git repos and I wanted to get those files into the annex system but still keep a record of their changes (the git history).
+
+Today I removed the core.bare = true setting on the repos and instead set core.worktree = projectdir, and ran git checkout in projectdir.  I have the index file in .gitignore, so there won't be that weird unresolvable conflict.  Now all my bloated git history is stored in the annex, and I can still work with it in the annexed checkout.
+
+I was thinking I'd do this again with the root of the repository when the annex grows too large, to back up the old history in a connected way.
+"""]]
diff --git a/doc/forum/name_resolution_of_dne.mdwn b/doc/forum/name_resolution_of_dne.mdwn
new file mode 100644
index 0000000000..cc3ca101ad
--- /dev/null
+++ b/doc/forum/name_resolution_of_dne.mdwn
@@ -0,0 +1,31 @@
+I get a failure in name resolution when running `annex testremote`:
+
+```
+mvanhult@detekti:~/temp/my_repo$ git annex testremote bbborig | head
+testremote bbborig (generating test keys...) Remote Tests
+  unavailable remote
+ssh: Could not resolve hostname !dne!: non-recoverable failure in name resolution
+    removeKey:                                       OK (0.01s)
+ssh: Could not resolve hostname !dne!: non-recoverable failure in name resolution
+    storeKey:                                        OK
+ssh: Could not resolve hostname !dne!: non-recoverable failure in name resolution
+    checkPresent:                                    OK
+ssh: Could not resolve hostname !dne!: non-recoverable failure in name resolution
+    retrieveKeyFile:                                 OK
+    retrieveKeyFileCheap:                            OK
+  key size Just 1048576; remote chunksize=0 encryption=none
+The following modules were not unloaded:
+  (Use "module --force purge" to unload all):
+
+  1) Stages/2024
+    removeKey when not present:                      FAIL
+      Exception: removing content from remote failed
+mvanhult@detekti:~/temp/my_repo$ git remote -v
+bbborig	juwels:/p/home/jusers/vanhulten1/juwels/temp/my_repo (fetch)
+bbborig	juwels:/p/home/jusers/vanhulten1/juwels/temp/my_repo (push)
+```
+
+Where does this `!dne!` come from?
+The relevant host of the remote is `juwels` and not `!dne!`.
+I have never before this post entered the string `!dne!`.
+Is *dne* an abbreviation?
diff --git a/doc/forum/name_resolution_of_dne/comment_1_7309e109d1f6eba8fc92659372d64b19._comment b/doc/forum/name_resolution_of_dne/comment_1_7309e109d1f6eba8fc92659372d64b19._comment
new file mode 100644
index 0000000000..21bd8d6aef
--- /dev/null
+++ b/doc/forum/name_resolution_of_dne/comment_1_7309e109d1f6eba8fc92659372d64b19._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-12-05T17:34:47Z"
+ content="""
+This is intentional behavior, it's testing that the remote behaves
+correctly when the server is unavailable. "dne" is an abbreviation for Does
+Not Exist, and "!dne!" is very unlikely to exist, so it uses that.
+"""]]
diff --git a/doc/forum/name_resolution_of_dne/comment_2_54ed13db673cff7177cd371143a295b4._comment b/doc/forum/name_resolution_of_dne/comment_2_54ed13db673cff7177cd371143a295b4._comment
new file mode 100644
index 0000000000..ff51f9180d
--- /dev/null
+++ b/doc/forum/name_resolution_of_dne/comment_2_54ed13db673cff7177cd371143a295b4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://esgf-node.llnl.gov/esgf-idp/openid/mvhulten"
+ nickname="mvhulten"
+ avatar="http://cdn.libravatar.org/avatar/8e966234bbd87d1efb0db4a4690960faa51b28cd27f4d285b9501c132a11567b"
+ subject="comment 2"
+ date="2023-12-07T12:30:24Z"
+ content="""
+Thank you for the clarification.
+"""]]
diff --git a/doc/forum/named_pipes_as_arguments.mdwn b/doc/forum/named_pipes_as_arguments.mdwn
new file mode 100644
index 0000000000..5e52c96862
--- /dev/null
+++ b/doc/forum/named_pipes_as_arguments.mdwn
@@ -0,0 +1 @@
+For which git-annex commands that take a file argument, is it safe for the file to be a named pipe (i.e. git-annex is guaranteed to only read/write the file once and without seeking)?
diff --git a/doc/forum/named_pipes_as_arguments/comment_1_0fff7a842609af3531d151425a94df0a._comment b/doc/forum/named_pipes_as_arguments/comment_1_0fff7a842609af3531d151425a94df0a._comment
new file mode 100644
index 0000000000..2992745fc4
--- /dev/null
+++ b/doc/forum/named_pipes_as_arguments/comment_1_0fff7a842609af3531d151425a94df0a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-09T15:38:21Z"
+ content="""
+I doubt it?
+
+The two way filesnames are used with git-annex commands are
+
+1. The name of a file already checked in to the git repository,
+   here git-annex needs to stat the file so I doubt a named pipe would
+   work.
+2. A file not yet checked into git which is going to be added.
+   git-annex has to adjust permissions, move the file etc, as well as
+   reading its content so again a named pipe wouldn't work.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build.mdwn b/doc/forum/new_linux_arm_tarball_build.mdwn
new file mode 100644
index 0000000000..e3b9c3de5c
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build.mdwn
@@ -0,0 +1,12 @@
+I've added an arm build to the autobuilds in [[install/Linux_standalone]].
+
+I'm curious to see how this works out. I tried to make it as self-contained
+as possible. It should work even on systems that do not use glibc, as long
+as the kernel is new enough for the glibc included in it, and supports the
+arm EABI.
+
+If it seems sufficiently useful, I might try to add the webapp to the
+build, which would be somewhat complicated, but doable (since I'm building
+using qemu, it can run a build on amd64 first to get the TH splices).
+
+--[[Joey]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_10_5f9735ec62478c99b8c814055206cff0._comment b/doc/forum/new_linux_arm_tarball_build/comment_10_5f9735ec62478c99b8c814055206cff0._comment
new file mode 100644
index 0000000000..eb3995eb15
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_10_5f9735ec62478c99b8c814055206cff0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmH9ARM62C6zcEpzh2muCs4wq-GkLRntgQ"
+ nickname="Randy"
+ subject="raspbian"
+ date="2014-04-16T10:59:10Z"
+ content="""
+This works fairly well for me on Raspian. However I am getting the same error as Justin. 
+
+    ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so' from /etc/ld.so.preload cannot be preloaded: ignored.
+
+I'm ignoring the errors for now, but it's a lot of noise that actually makes it slightly difficult to see the important output.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_11_859c44046b00fe885f6878cfe0e46360._comment b/doc/forum/new_linux_arm_tarball_build/comment_11_859c44046b00fe885f6878cfe0e46360._comment
new file mode 100644
index 0000000000..7be8a67316
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_11_859c44046b00fe885f6878cfe0e46360._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 11"
+ date="2014-04-17T19:39:41Z"
+ content="""
+I can't see any good way to prevent ld-linux.so from preloading things listed in `/etc/ld.so.preload`. I don't know why raspbian wants to preload that -- probably for optimisation purposes?
+
+I could modify the ld-linux.so shipped in the git-annex tarball, but that way lies pointless complication..
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_12_35ade68d62e95036344ad33db3279c21._comment b/doc/forum/new_linux_arm_tarball_build/comment_12_35ade68d62e95036344ad33db3279c21._comment
new file mode 100644
index 0000000000..ba6468a3f6
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_12_35ade68d62e95036344ad33db3279c21._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmH9ARM62C6zcEpzh2muCs4wq-GkLRntgQ"
+ nickname="Randy"
+ subject="comment 12"
+ date="2014-04-18T13:38:13Z"
+ content="""
+There is no need to modify anything here. The errors were mostly just confusing at first and made me wonder if it was working properly. It is indeed working perfectly! Thanks!!!
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_13_36f48c30894b9b225b812ba5e5b2f504._comment b/doc/forum/new_linux_arm_tarball_build/comment_13_36f48c30894b9b225b812ba5e5b2f504._comment
new file mode 100644
index 0000000000..312082ae1c
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_13_36f48c30894b9b225b812ba5e5b2f504._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnClfG_kAo0drU5dVZiTRXo9WnqjW4I5dA"
+ nickname="Julian"
+ subject="comment 13"
+ date="2014-12-06T17:04:04Z"
+ content="""
+Unfortunately, it isn't working for me on DS214 (MARVELL Armada XP MV78230) and DSM 5.1-5004 Update 2.
+git is installed, git-annex tar extracted and runshell worked. Within this shell git-annex seems to work (e.g. git-annex init works)
+
+However, git-annex is complaining that git-annex is not installed on remote when I try to add the NAS as a remote.
+
+I guess it is related to the fact that git-annex-shell is not working on the NAS. When I execute git-annex-shell it gives:
+/volume1/homes/julian/bin/git-annex.linux/shimmed/git-annex-shell/git-annex-shell: error while loading shared libraries: /volume1/homes/julian/bin/git-annex.linux/shimmed/git-annex-shell/git-annex-shell: file too short
+Actually /volume1/homes/julian/bin/git-annex.linux/shimmed/git-annex-shell/git-annex-shell has 0 Bytes.
+
+I can't execute git-annex-shell inside the bin folder due to permission issues. I tried to change the file permissions but it didn't help.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_14_67021b6d239690c9d18e8630aa2254ff._comment b/doc/forum/new_linux_arm_tarball_build/comment_14_67021b6d239690c9d18e8630aa2254ff._comment
new file mode 100644
index 0000000000..fd9591d9d2
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_14_67021b6d239690c9d18e8630aa2254ff._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2014-12-06T20:25:06Z"
+ content="""
+@Julian, shimmed/git-annex-shell/git-annex-shell is supposed to be a hard
+link to shimmed/git-annex/git-annex. Maybe there's a problem with hard
+links on your NAS? A symlink would also work I think.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_15_646a19555f982fb7ab302289400adc3d._comment b/doc/forum/new_linux_arm_tarball_build/comment_15_646a19555f982fb7ab302289400adc3d._comment
new file mode 100644
index 0000000000..fee8cc91d0
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_15_646a19555f982fb7ab302289400adc3d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="db"
+ subject="How do I start it?"
+ date="2016-01-23T22:42:52Z"
+ content="""
+This happens when I launch git-annex-webapp
+
+	[\u@\h \W]$ ./git-annex-webapp
+	Launching web browser on file:///tmp/webapp1804289383846930886.html
+	git-annex: xdg-open: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
+
+
+And the webapp1804289383846930886.html file seem to be deleted immediately.
+
+This is on a headless NAS and obviously I don't have a browser or anything on it. I just want to run Annex as a server/service and admin it from a browser on another machine on my LAN.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_16_442015225a14f60064aa3ba3cfbdf2ae._comment b/doc/forum/new_linux_arm_tarball_build/comment_16_442015225a14f60064aa3ba3cfbdf2ae._comment
new file mode 100644
index 0000000000..9e592df13f
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_16_442015225a14f60064aa3ba3cfbdf2ae._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2016-01-24T18:16:24Z"
+ content="""
+You can use the --listen parameter to make the webapp listen on an address
+and then connect to it from a web browser on your LAN. See
+<http://git-annex.branchable.com/git-annex-webapp/>
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_17_653448e38c3bb71a97023cb5d6b21af6._comment b/doc/forum/new_linux_arm_tarball_build/comment_17_653448e38c3bb71a97023cb5d6b21af6._comment
new file mode 100644
index 0000000000..9915cb9c8f
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_17_653448e38c3bb71a97023cb5d6b21af6._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="db"
+ subject="comment 17"
+ date="2016-01-24T19:30:41Z"
+ content="""
+Doesn't seem to work:
+
+	$ sudo ./git-annex-webapp --listen=192.168.1.3                                                                                           
+	git-annex: /tmp/webapp1804289383846930886.html16816927771714636915.tmp: hClose: resource exhausted (No space left on device)
+	WebAp$ 
+	$ touch /tmp/test
+	$
+
+I don't know why I have two different /tmp catalogs. How do I modify which temp dir git-annex uses?
+
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_18_0a76ce3895ba9598bd79625268d95ef4._comment b/doc/forum/new_linux_arm_tarball_build/comment_18_0a76ce3895ba9598bd79625268d95ef4._comment
new file mode 100644
index 0000000000..b5e5881007
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_18_0a76ce3895ba9598bd79625268d95ef4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 18"""
+ date="2016-01-29T17:27:42Z"
+ content="""
+@db, git-annex supports the standard TMPDIR environment variable.
+But, this is getting quite far afield from the topic of this thread.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_1_7211ddc626bae97d4140c723c3cf028f._comment b/doc/forum/new_linux_arm_tarball_build/comment_1_7211ddc626bae97d4140c723c3cf028f._comment
new file mode 100644
index 0000000000..2e91a7a831
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_1_7211ddc626bae97d4140c723c3cf028f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="works on raspbian"
+ date="2013-12-16T23:26:51Z"
+ content="""
+This build has been verified to work on raspbian.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_2_fcbe3f7fa9d012b21c7a771553fa9142._comment b/doc/forum/new_linux_arm_tarball_build/comment_2_fcbe3f7fa9d012b21c7a771553fa9142._comment
new file mode 100644
index 0000000000..9499141fbd
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_2_fcbe3f7fa9d012b21c7a771553fa9142._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="works on Synology NAS"
+ date="2013-12-17T02:52:22Z"
+ content="""
+Using latest build (fixed some issues).
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_3_2702cdbae4179a7a103d2a7098a8ed5e._comment b/doc/forum/new_linux_arm_tarball_build/comment_3_2702cdbae4179a7a103d2a7098a8ed5e._comment
new file mode 100644
index 0000000000..ec63cccc92
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_3_2702cdbae4179a7a103d2a7098a8ed5e._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="http://julien.lefrique.name/"
+ nickname="jlefrique"
+ subject="QNAP"
+ date="2013-12-17T07:57:37Z"
+ content="""
+Hi Joey,
+
+Thank you for taking the time to setup an ARM build. I am trying to run the last standalone build on a QNAP TS-219PII. I get the following error. Do you have any ideas?
+
+    $ uname -a
+    Linux willow 2.6.33.2 #1 Fri Mar 1 04:41:48 CST 2013 armv5tel unknown
+    $ ./runshell
+    $ cd ../annex
+    $ git annex version
+    git-annex version: 5.20131216-g07252d6
+    build flags: Assistant Pairing S3 Inotify DBus XMPP Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web glacier hook
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3 5
+    upgrade supported from repository versions: 0 1 2 4
+    $ git annex info        
+    repository mode: indirect
+    trusted repositories: fatal: cannot get RLIMIT_NOFILE: Bad address
+    fatal: cannot get RLIMIT_NOFILE: Bad address
+    fatal: cannot get RLIMIT_NOFILE: Bad address
+    fatal: cannot get RLIMIT_NOFILE: Bad address
+    fatal: cannot get RLIMIT_NOFILE: Bad address
+    fatal: cannot get RLIMIT_NOFILE: Bad address
+
+I am still using the version 3.8.3 of the QNAP distribution. I will try to update to the last version (4.0.5) to see if it helps.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_4_e1d802fbcc9d699ece5267e80990255a._comment b/doc/forum/new_linux_arm_tarball_build/comment_4_e1d802fbcc9d699ece5267e80990255a._comment
new file mode 100644
index 0000000000..e95d86b729
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_4_e1d802fbcc9d699ece5267e80990255a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="RLIMIT_NOFILE"
+ date="2013-12-17T16:05:12Z"
+ content="""
+This is clearly failing when it runs git. Looking at the git source code, it does have a `RLIMIT_NOFILE` ifdef, so I could disable this, but would have to maintain my own build of git.
+
+What kernel version is this? Upgrading is likely to fix it.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_5_257b91ecbf5a6040a8e4c9a360c775ba._comment b/doc/forum/new_linux_arm_tarball_build/comment_5_257b91ecbf5a6040a8e4c9a360c775ba._comment
new file mode 100644
index 0000000000..94ea05a495
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_5_257b91ecbf5a6040a8e4c9a360c775ba._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://julien.lefrique.name/"
+ nickname="jlefrique"
+ subject="QNAP kernel"
+ date="2013-12-17T16:27:21Z"
+ content="""
+It's kernel 2.6.33.2 (see uname in my previous message).
+A new version with kernel 3.4.x is available, I will try to update when the data on my NAS will be (more) safely backup-ed.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_6_bd8cca86a63be7e330111618c1959a74._comment b/doc/forum/new_linux_arm_tarball_build/comment_6_bd8cca86a63be7e330111618c1959a74._comment
new file mode 100644
index 0000000000..a57d48356b
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_6_bd8cca86a63be7e330111618c1959a74._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="Re: RLIMIT_NOFILE"
+ date="2013-12-19T02:10:45Z"
+ content="""
+I've passed this problem on to the git developers, and they have quickly developed a patch that will solve it, so I'll just wait for the next git release.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_7_6814bdeca94328fe6c3f407795ff923a._comment b/doc/forum/new_linux_arm_tarball_build/comment_7_6814bdeca94328fe6c3f407795ff923a._comment
new file mode 100644
index 0000000000..a4b597bdf3
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_7_6814bdeca94328fe6c3f407795ff923a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://julien.lefrique.name/"
+ nickname="jlefrique"
+ subject="Thanks"
+ date="2013-12-19T07:20:31Z"
+ content="""
+That's perfect!
+On my side, I upgraded to firmware 4.0.2 but the kernel is still the same.
+The kernel 3.4.x is available in the beta of QTS 4.1.0, I will wait the official release to upgrade.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_8_6db99d998ca990494c8f2826ff1ca273._comment b/doc/forum/new_linux_arm_tarball_build/comment_8_6db99d998ca990494c8f2826ff1ca273._comment
new file mode 100644
index 0000000000..9d58cb11ca
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_8_6db99d998ca990494c8f2826ff1ca273._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://renaud.casenave.fr/"
+ ip="126.10.66.235"
+ subject="comment 8"
+ date="2014-02-17T13:15:24Z"
+ content="""
+Hi,
+
+You might be happy to know git-annex works well on sailfishOS, even the webapp.
+It does segfault when trying to setup a xmpp account, though.
+"""]]
diff --git a/doc/forum/new_linux_arm_tarball_build/comment_9_2802b24ccb24f1615c9d61904f916d05._comment b/doc/forum/new_linux_arm_tarball_build/comment_9_2802b24ccb24f1615c9d61904f916d05._comment
new file mode 100644
index 0000000000..fbb0e2f219
--- /dev/null
+++ b/doc/forum/new_linux_arm_tarball_build/comment_9_2802b24ccb24f1615c9d61904f916d05._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c"
+ nickname="Justin"
+ subject="comment 9"
+ date="2014-03-01T19:13:16Z"
+ content="""
+This seems to work great for me on Raspbian, except I get many errors of the form
+
+    ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so' from /etc/ld.so.preload cannot be preloaded: ignored.
+
+I've tried, but I haven't been able to figure out why ld doesn't like this particular lib.  I can keep ignoring the error, but help would certainly be appreciated!
+"""]]
diff --git a/doc/forum/new_microfeatures.mdwn b/doc/forum/new_microfeatures.mdwn
new file mode 100644
index 0000000000..bfe44272a7
--- /dev/null
+++ b/doc/forum/new_microfeatures.mdwn
@@ -0,0 +1,59 @@
+I'm soliciting ideas for new small features that let git-annex do things that currently have to be done manually or whatever.
+
+Here are a few I've been considering:
+
+---
+
+* --numcopies would be a useful command line switch.
+  > Update: Added. Also allows for things like `git annex drop --numcopies=2` when in a repo that normally needs 3 copies, if you need
+  > to urgently free up space.
+* A way to make `drop` and other commands temporarily trust a given remote, or possibly all remotes. 
+
+Combined, this would allow `git annex drop --numcopies=2 --trust=repoa --trust=repob` to remove files that have been replicated out to the other 2 repositories, which could be offline. (Slightly unsafe, but in this case the files are podcasts so not really.)
+
+> Update: done --[[Joey]] 
+
+---
+
+[[wishlist:_git-annex_replicate]] suggests some way for git-annex to have the smarts to copy content around on its own to ensure numcopies is satisfied. I'd be satisfied with a `git annex copy --to foo --if-needed-by-numcopies`
+
+  > Contrary to the "basic" solution, I would love to have a git annex distribute which is smart enough to simply distribute all data according to certain rules. My ideal, personal use case during the next holidays where I will have two external disks, several SD cards with 32 GB each and a local disk with 20 GB (yes....) would be:
+
+    cd ~/photos.annex # this repository does not have any objects!
+    git annex inject --bare /path/to/SD/card  # this adds softlinks, but does **not** add anything to the index. it would calculate checksums (if enabled) and have to add a temporary location list, though
+    git annex distribute # this checks the config. it would see that my two external disks have a low cost whereas the two remotes have a higher cost.
+     # check numcopies. it's 3
+     # copy to external disk one (cost x)
+     # copy to external disk two (cost x)
+     # copy to remote one (cost x * 2)
+     # remove file from temporary tracking list
+    git annex fsck # everything ok. yay!
+
+Come to think of it, the inject --bare thing is probably not a microfeature. Should I add a new wishlist item for that? -- RichiH
+
+> I've thought about such things before; does not seem really micro and I'm unsure how well it would work, but it would be worth a [[todo]]. --[[Joey]]
+
+>> Update: Done as --auto. --[[Joey]] 
+
+---
+
+Along similar lines, it might be nice to have a mode where git-annex tries to fill up a disk up to the `annex.diskreserve` with files, preferring files that have relatively few copies. Then as storage prices continue to fall, new large drives could just be plopped in and git-annex used to fill it up in a way that improves the overall redundancy without needing to manually pick and choose.
+
+> Update: git annex get --auto basically does this; you can tune
+> --numcopies on the fly to make it get more files than needed by the
+> current numcopies setting. --[[Joey]] 
+
+---
+
+If a remote could send on received files to another remote, I could use my own local bandwith efficiently while still having my git-annex repos replicate data. -- RichiH
+
+---
+
+Really micro:
+
+    % grep annex-push .git/config
+        annex-push = !git pull && git annex add . && git annex copy . --to origin --fast --quiet && git commit -a -m "$HOST $(date +%F--%H-%M-%S-%Z)" && git push
+    %
+
+-- RichiH
+--[[Joey]]
diff --git a/doc/forum/new_microfeatures/comment_1_058bd517c6fffaf3446b1f5d5be63623._comment b/doc/forum/new_microfeatures/comment_1_058bd517c6fffaf3446b1f5d5be63623._comment
new file mode 100644
index 0000000000..84fdd325dc
--- /dev/null
+++ b/doc/forum/new_microfeatures/comment_1_058bd517c6fffaf3446b1f5d5be63623._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2011-06-01T17:36:50Z"
+ content="""
+I've been longing for an automated way of removing references to a remote assuming I know the exact uuid that I want to remove. i.e. I have lost a portable HDD due to a destructive process, I now want to delete all references to copies of data that was on that disk. Unless this feature exists, I would love to see it implemented.
+"""]]
diff --git a/doc/forum/new_microfeatures/comment_2_41ad904c68e89c85e1fc49c9e9106969._comment b/doc/forum/new_microfeatures/comment_2_41ad904c68e89c85e1fc49c9e9106969._comment
new file mode 100644
index 0000000000..4451e20baf
--- /dev/null
+++ b/doc/forum/new_microfeatures/comment_2_41ad904c68e89c85e1fc49c9e9106969._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-06-01T20:24:33Z"
+ content="""
+@jimmy [[walkthrough/what_to_do_when_you_lose_a_repository]].. I have not seen a convincing argument that removing the location tracking data entirely serves any purpose
+"""]]
diff --git a/doc/forum/new_microfeatures/comment_3_a1a9347b5bc517f2a89a8b292c3f8517._comment b/doc/forum/new_microfeatures/comment_3_a1a9347b5bc517f2a89a8b292c3f8517._comment
new file mode 100644
index 0000000000..4bb3aa684f
--- /dev/null
+++ b/doc/forum/new_microfeatures/comment_3_a1a9347b5bc517f2a89a8b292c3f8517._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"
+ nickname="Rafaël"
+ subject="git annex unlock --readonly"
+ date="2011-06-02T11:34:42Z"
+ content="""
+This was already asked [here](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606577), but I have a use case where I need to unlock with the files being hardlinked instead of copied (my fs does not support CoW), even though 'git annex lock' is now much faster ;-) . The idea is that 1) I want the external world see my repo \"as if\" it wasn't annexed (because of its own limitation to deal with soft links), and 2) I know what I do, and am sure that files won't be written to but only read.
+
+My case is: the repo contains a snapshot A1 of a certain remote directory. Later I want to rsync this dir into a new snapshot A2. Of course, I want to transfer only new or changed files, with the --copy-dest=A1 (or --compare-dest) rsync's options. Unfortunately, rsync won't recognize soft-links from git-annex, and will re-transfer everything.
+
+
+Maybe I'm overusing git-annex ;-) but still, I find it is a legitimate use case, and even though there are workarounds (I don't even remember what I had to do), it would be much more straightforward to have 'git annex unlock --readonly' (or '--readonly-unsafe'?), ... or have rsync take soft-links into account, but I did not see the author ask for microfeatures ideas :) (it was discussed, and only some convoluted workarounds were proposed). Thanks.
+
+
+"""]]
diff --git a/doc/forum/new_microfeatures/comment_4_5a6786dc52382fff5cc42fdb05770196._comment b/doc/forum/new_microfeatures/comment_4_5a6786dc52382fff5cc42fdb05770196._comment
new file mode 100644
index 0000000000..cc98109e6b
--- /dev/null
+++ b/doc/forum/new_microfeatures/comment_4_5a6786dc52382fff5cc42fdb05770196._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"
+ nickname="Rafaël"
+ subject="git annex unused"
+ date="2011-06-02T11:55:58Z"
+ content="""
+Before dropping unsused items, sometimes I want to check the content of the files manually.
+But currently, from e.g. a sha1 key, I don't know how to find the corresponding file, except with
+'find .git/annex/objects -type f -name 'SHA1-s1678--70....', wich is too slow (I'm in the case where \"git log --stat -S'KEY'\"
+won't work, either because it is too slow or it was never commited). By the way,
+is it documented somewhere how to determine the 2 (nested) sub-directories in which a given
+(by name) object is located?
+
+So I would like 'git-annex unused' be able to give me the list of *paths* to the unused items.
+Also, I would really appreciate a command like 'git annex unused --log NUMBER [NUMBER2...]' which would do for me the suggested command
+\"git log --stat -S'KEY'\", where NUMBER is from the 'git annex unused' output.
+Thanks.
+"""]]
diff --git a/doc/forum/new_microfeatures/comment_5_3c627d275586ff499d928a8f8136babf._comment b/doc/forum/new_microfeatures/comment_5_3c627d275586ff499d928a8f8136babf._comment
new file mode 100644
index 0000000000..f7361f5d1c
--- /dev/null
+++ b/doc/forum/new_microfeatures/comment_5_3c627d275586ff499d928a8f8136babf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"
+ nickname="Rafaël"
+ subject="git annex unused"
+ date="2011-06-02T19:51:49Z"
+ content="""
+ps: concerning the command 'find .git/annex/objects -type f -name 'SHA1-s1678--70....' from my previous comment, it is \"significantly\" faster to search for the containing directory which have the same name: 'find .git/annex/objects -maxdepth 2 -mindepth 2 -type d -name 'SHA1-s1678--70....'. I am just curious: what is the need to have each file object in its own directory, itself nested under two more sub-directories?
+"""]]
diff --git a/doc/forum/new_microfeatures/comment_6_31ea08c008500560c0b96c6601bc6362._comment b/doc/forum/new_microfeatures/comment_6_31ea08c008500560c0b96c6601bc6362._comment
new file mode 100644
index 0000000000..868e9677c8
--- /dev/null
+++ b/doc/forum/new_microfeatures/comment_6_31ea08c008500560c0b96c6601bc6362._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"
+ nickname="Rafaël"
+ subject="git annex fetch"
+ date="2011-07-03T14:39:41Z"
+ content="""
+I'm not sure it is worth adding a command for such a small feature, but I would certainly use it: having something like \"git annex fetch remote\" do \"git fetch remote && git annex copy --from=remote\", and \"git annex push remote\" do \"git push remote && git annex copy --to=remote\". And maybe the same for a pull operation?
+"""]]
diff --git a/doc/forum/new_microfeatures/comment_7_94045b9078b1fff877933b012d1b49e2._comment b/doc/forum/new_microfeatures/comment_7_94045b9078b1fff877933b012d1b49e2._comment
new file mode 100644
index 0000000000..e39e162322
--- /dev/null
+++ b/doc/forum/new_microfeatures/comment_7_94045b9078b1fff877933b012d1b49e2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"
+ nickname="Rafaël"
+ subject="git annex fetch"
+ date="2011-07-03T17:57:00Z"
+ content="""
+My last comment is a bit confused. The \"git fetch\" command allows to get all the information from a remote, and it is then possible to merge while being offline (without access to the remote). I would like a \"git annex fetch remote\" command to be able to get all annexed files from remote, so that if I later merge with remote, all annexed files are already here. And \"git annex fetch\" could (optionally) call \"git fetch\" before getting the files.
+
+It seems also that in my last post, I should have written \"git annex get --from=remote\" instead of \"git annex copy --from=remote\", because \"annex copy --from\" copies all files, even if the local repo already have them (is this the case? if yes, when is it useful?)
+"""]]
diff --git a/doc/forum/nntp__47__usenet_special_remote.mdwn b/doc/forum/nntp__47__usenet_special_remote.mdwn
new file mode 100644
index 0000000000..86efa48cff
--- /dev/null
+++ b/doc/forum/nntp__47__usenet_special_remote.mdwn
@@ -0,0 +1,18 @@
+Over the last few weeks i've been working on a seperate python nntp project. But decided that it would be fun to make it usable with git-annex.
+
+The code is almost complete. One major feature left(make it usable without a mysql/sqlite database, and without fetching headers). And of course a lot of bugfixes.
+
+I'm wondering if there is any interest in this special remote hook.
+
+The thought is, buy unlimited usenet account, and you can have a git-annex repository without any upper size limit. You want 100GB, well that'll be 10$ a month, want 100000GB, well that'll be 10$ a month.
+
+Of course there are plenty of caveats(retention on server, it is doubtfull the data will stay up for more than 4 years.). Because the code is in python3 i had to use a lot of external tools (uudeview, par2, ydecode/yydecode) and parse their output. Which is a horrid horrid solution. Since the code is nearing "beta" stage i might see if i can improve on that(possibly with ctypes), if there is any interest.
+
+Currently working on freebsd, ubuntu, debian, mac os x(10.7, not tested in 10.8)
+
+The last feature to be done (and this is UUUUUGLY) is to make it get nzb files from a source like this: http://nzbindex.nl/search/?q=GPGHMACSHA (yes, that is my git-annex repo) instead of from a mysql database.
+
+So, this is a call to see if anyone is interested, and if anyone proficient in *NIX want to test it out.
+
+Sincerely
+Tobias
diff --git a/doc/forum/nntp__47__usenet_special_remote/comment_1_171a0b95b1f95cfd82073e88bdefaab9._comment b/doc/forum/nntp__47__usenet_special_remote/comment_1_171a0b95b1f95cfd82073e88bdefaab9._comment
new file mode 100644
index 0000000000..ff14f6f2ec
--- /dev/null
+++ b/doc/forum/nntp__47__usenet_special_remote/comment_1_171a0b95b1f95cfd82073e88bdefaab9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-19T20:49:06Z"
+ content="""
+I think it's a neat idea. I can't see using it for my own data due to retention, but if I had a use case where I wanted to spread data around and didn't care if it vanished after X months, I can see using it.
+
+I think you should publish the details, if getting it to a state others can use is not too much work,
+"""]]
diff --git a/doc/forum/nntp__47__usenet_special_remote/comment_2_48736ed17c98ffcfb13ec00b901b2dd6._comment b/doc/forum/nntp__47__usenet_special_remote/comment_2_48736ed17c98ffcfb13ec00b901b2dd6._comment
new file mode 100644
index 0000000000..90b264f7b6
--- /dev/null
+++ b/doc/forum/nntp__47__usenet_special_remote/comment_2_48736ed17c98ffcfb13ec00b901b2dd6._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="comment 2"
+ date="2013-09-11T07:46:07Z"
+ content="""
+Only played a tiny bit with this since the initial post.
+
+I've decided that sql backend should be dropped entirely. Mostly the SQL backend was there because the code does something else entirely, and this was just a test.
+
+But since there has been no interest it will probably take ages before i actually get this finished :)
+
+"""]]
diff --git a/doc/forum/non-bare_repo_on_cloud_remote.mdwn b/doc/forum/non-bare_repo_on_cloud_remote.mdwn
new file mode 100644
index 0000000000..3949e18dac
--- /dev/null
+++ b/doc/forum/non-bare_repo_on_cloud_remote.mdwn
@@ -0,0 +1,6 @@
+Hi,
+
+I wondered if it's possible to have a non-bare repo on a cloud remote. I want to have some sort of Dropbox-like workflow were I simply put stuff into a directory on my drive and it gets synced via SSH to a central VPS so I can also always access it via HTTP, for example.
+
+Regards,
+Lukas
diff --git a/doc/forum/non-bare_repo_on_cloud_remote/comment_1_da0c023af7c78f1ef1cfe1143a900a9f._comment b/doc/forum/non-bare_repo_on_cloud_remote/comment_1_da0c023af7c78f1ef1cfe1143a900a9f._comment
new file mode 100644
index 0000000000..27e908cacd
--- /dev/null
+++ b/doc/forum/non-bare_repo_on_cloud_remote/comment_1_da0c023af7c78f1ef1cfe1143a900a9f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.1.10"
+ subject="comment 1"
+ date="2013-07-22T22:04:53Z"
+ content="""
+Sure you can.. That's how <http://downloads.kitenet.net/> works, which is where people download git-annex builds from!
+
+[[tips/making_a_remote_repo_update_when_changes_are_pushed_to_it]]
+
+[[tips/setup_a_public_repository_on_a_web_site]]
+"""]]
diff --git a/doc/forum/non-bare_repo_on_cloud_remote/comment_2_71baea93f6caaf7b81a9ac00bee91e5e._comment b/doc/forum/non-bare_repo_on_cloud_remote/comment_2_71baea93f6caaf7b81a9ac00bee91e5e._comment
new file mode 100644
index 0000000000..145c57120c
--- /dev/null
+++ b/doc/forum/non-bare_repo_on_cloud_remote/comment_2_71baea93f6caaf7b81a9ac00bee91e5e._comment
@@ -0,0 +1,67 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
+ nickname="Tobias"
+ subject="comment 2"
+ date="2013-08-08T19:05:07Z"
+ content="""
+Seems that I don't get it... Here is what I did:
+
+First, I create a new repo with the assistant on `user@laptop ~/temp/annex-test`, then:
+
+    user@laptop ~/temp/annex-test % echo test1 > test1
+    user@laptop ~/temp/annex-test % echo test2 > test2
+    
+    user@server ~/tmp % mkdir annex-test
+    user@server ~/tmp % cd annex-test
+    user@server ~/tmp/annex-test % git init
+    Initialized empty Git repository in /home/tobru/tmp/annex-test/.git/
+    user@server ~/tmp/annex-test % git annex init
+    init  ok
+    (Recording state in git...)
+    user@server ~/tmp/annex-test % mv .git/hooks/post-update.sample .git/hooks/post-update       
+    user@server ~/tmp/annex-test % cat .git/hooks/post-update
+    #!/bin/sh
+    #
+    # An example hook script to prepare a packed repository for use over
+    # dumb transports.
+    #
+    # To enable this hook, rename this file to \"post-update\".
+    
+    exec git update-server-info
+    user@server ~/tmp/annex-test % chmod +x .git/hooks/post-update
+    user@server ~/tmp/annex-test % echo '#!/bin/sh\ngit annex merge' > .git/hooks/post-receive
+    user@server ~/tmp/annex-test % chmod +x .git/hooks/post-receive
+    
+    user@laptop ~/temp/annex-test % git remote add server ssh://user@server/home/tobru/tmp/annex-test
+    user@laptop ~/temp/annex-test % git annex assistant --stop
+    user@laptop ~/temp/annex-test % git annex sync
+    commit  
+    ok
+    pull server 
+    warning: no common commits
+    remote: Counting objects: 5, done.
+    remote: Compressing objects: 100% (3/3), done.
+    remote: Total 5 (delta 1), reused 0 (delta 0)
+    Unpacking objects: 100% (5/5), done.
+    From ssh://server.tobru.local/home/tobru/tmp/annex-test
+     * [new branch]      git-annex  -> server/git-annex
+    ok
+    (merging server/git-annex into git-annex...)
+    (Recording state in git...)
+    push server 
+    Counting objects: 27, done.
+    Delta compression using up to 4 threads.
+    Compressing objects: 100% (20/20), done.
+    Writing objects: 100% (25/25), 2.36 KiB, done.
+    Total 25 (delta 2), reused 0 (delta 0)
+    remote: merge git-annex (merging synced/git-annex into git-annex...)
+    remote: ok
+    To ssh://tobru@server.tobru.local/home/tobru/tmp/annex-test
+     * [new branch]      git-annex -> synced/git-annex
+     * [new branch]      master -> synced/master
+    ok
+    user@laptop ~/temp/annex-test % git annex assistant
+
+Now I expect the files `test1` and `test2` to be at `user@server ~/tmp/annex-test`. But they are not displayed.
+What am I doing wrong? The main thing I wan't to achieve: Push the files from `laptop` to `server` without adding `laptop` as remote on the server.
+"""]]
diff --git a/doc/forum/non_fast_forward_error_with_git_annex_sync.mdwn b/doc/forum/non_fast_forward_error_with_git_annex_sync.mdwn
new file mode 100644
index 0000000000..19dad625bc
--- /dev/null
+++ b/doc/forum/non_fast_forward_error_with_git_annex_sync.mdwn
@@ -0,0 +1,34 @@
+I'm trying to sync from a direct repo to another direct repo but getting a non-fast-forward rejection:
+
+    push v-crateris 
+    Counting objects: 509, done.
+    Delta compression using up to 4 threads.
+    Compressing objects: 100% (455/455), done.
+    Writing objects: 100% (509/509), 33.21 KiB | 4.74 MiB/s, done.
+    Total 509 (delta 350), reused 0 (delta 0)
+    remote: Resolving deltas: 100% (350/350), completed with 174 local objects.
+    To v-crateris:/annex/Music
+       c60621302..803920707  git-annex -> synced/git-annex
+     ! [rejected]            annex/direct/master -> synced/master (non-fast-forward)
+    error: failed to push some refs to 'v-crateris:/annex/Music'
+    hint: Updates were rejected because a pushed branch tip is behind its remote
+    hint: counterpart. Check out this branch and integrate the remote changes
+    hint: (e.g. 'git pull ...') before pushing again.
+    hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+    To v-crateris:/annex/Music
+     ! [rejected]            master -> master (non-fast-forward)
+    error: failed to push some refs to 'v-crateris:/annex/Music'
+    hint: Updates were rejected because a pushed branch tip is behind its remote
+    hint: counterpart. Check out this branch and integrate the remote changes
+    hint: (e.g. 'git pull ...') before pushing again.
+    hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+
+      Pushing to v-crateris failed.
+
+      (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
+    failed
+
+I tried setting `receive.denyNonFastforwards` to `false` as the message said, but it made no difference.
+Both repos have `annex/direct/master` checked out.
+
+What should I do to resolve this?
diff --git a/doc/forum/non_fast_forward_error_with_git_annex_sync/comment_1_48d66e5314de5b6a26f78622a4e93ba6._comment b/doc/forum/non_fast_forward_error_with_git_annex_sync/comment_1_48d66e5314de5b6a26f78622a4e93ba6._comment
new file mode 100644
index 0000000000..acde90fd24
--- /dev/null
+++ b/doc/forum/non_fast_forward_error_with_git_annex_sync/comment_1_48d66e5314de5b6a26f78622a4e93ba6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="matyasbot@fd008517d046c382e18306c0b3db48eb58d45dee"
+ nickname="matyasbot"
+ avatar="http://cdn.libravatar.org/avatar/c1b6b47dcdf2962858e6aad44a3cec66"
+ subject="pull didn't do anything either"
+ date="2017-10-11T14:23:29Z"
+ content="""
+Also, despite the pull claiming to have succeded, there was a new directory on the remote that did not get transferred to the local repo during the sync.
+"""]]
diff --git a/doc/forum/non_fast_forward_error_with_git_annex_sync/comment_2_f7101a8e84bbbfb2fbea6c65ca62fdb9._comment b/doc/forum/non_fast_forward_error_with_git_annex_sync/comment_2_f7101a8e84bbbfb2fbea6c65ca62fdb9._comment
new file mode 100644
index 0000000000..a6ad752db3
--- /dev/null
+++ b/doc/forum/non_fast_forward_error_with_git_annex_sync/comment_2_f7101a8e84bbbfb2fbea6c65ca62fdb9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-10-11T15:14:18Z"
+ content="""
+You need to set the receive.denyNonFastforwards configuration in
+the remote git repository, not on the local git repository. It kind of
+sounds like you may have misunderstood where to set it.
+"""]]
diff --git a/doc/forum/non_fast_forward_error_with_git_annex_sync/comment_3_bbb3a5572fa2427d9bf859ae1ba68764._comment b/doc/forum/non_fast_forward_error_with_git_annex_sync/comment_3_bbb3a5572fa2427d9bf859ae1ba68764._comment
new file mode 100644
index 0000000000..53e19eef4a
--- /dev/null
+++ b/doc/forum/non_fast_forward_error_with_git_annex_sync/comment_3_bbb3a5572fa2427d9bf859ae1ba68764._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="matyasbot@fd008517d046c382e18306c0b3db48eb58d45dee"
+ nickname="matyasbot"
+ avatar="http://cdn.libravatar.org/avatar/c1b6b47dcdf2962858e6aad44a3cec66"
+ subject="comment 3"
+ date="2017-10-11T15:17:55Z"
+ content="""
+No, that is exactly where I set it.
+"""]]
diff --git a/doc/forum/noob_question._VPS_web_assistant.mdwn b/doc/forum/noob_question._VPS_web_assistant.mdwn
new file mode 100644
index 0000000000..410cb74d55
--- /dev/null
+++ b/doc/forum/noob_question._VPS_web_assistant.mdwn
@@ -0,0 +1,7 @@
+Hi
+
+So I've installed git-annex on my Debian VPS.
+
+How do I find out the URL to access the web UI / assistant?
+
+Thanks!
diff --git a/doc/forum/noob_question._VPS_web_assistant/comment_1_49f349192d64048753bedcf10ee22355._comment b/doc/forum/noob_question._VPS_web_assistant/comment_1_49f349192d64048753bedcf10ee22355._comment
new file mode 100644
index 0000000000..f08d3e8c5b
--- /dev/null
+++ b/doc/forum/noob_question._VPS_web_assistant/comment_1_49f349192d64048753bedcf10ee22355._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-16T17:26:33Z"
+ content="""
+The url inculudes a secret token, so a new url is generated each time
+the assistant is started.
+
+The file `.git/annex/url` in your git-annex repository contains the current
+url.
+"""]]
diff --git a/doc/forum/not_finding_git-annex-shell_on_remote.mdwn b/doc/forum/not_finding_git-annex-shell_on_remote.mdwn
new file mode 100644
index 0000000000..0d743bf78c
--- /dev/null
+++ b/doc/forum/not_finding_git-annex-shell_on_remote.mdwn
@@ -0,0 +1,21 @@
+I have set up an annex on a remote machine and I am connecting via ssh.  But, since it is a managed machine, I installed the git-annex binary in my own ~/bin.  Well, when I try 
+$git annex sync
+
+I get:
+  $git annex sync
+(merging origin/git-annex into git-annex...)
+(Recording state in git...)
+bash: git-annex-shell: command not found
+
+  Remote origin does not have git-annex installed; setting annex-ignore
+commit  ok
+pull origin 
+
+merge: refs/remotes/origin/master - not something we can merge
+
+merge: refs/remotes/origin/synced/master - not something we can merge
+failed
+git-annex: sync: 1 failed
+
+
+The git remote -v looks correct.  So, how do I tell git annex on my local machine where to use $HOME/bin in PATH on the remote machine when syncing  with remotes?
diff --git a/doc/forum/not_finding_git-annex-shell_on_remote/comment_1_84881cad02c251a2515cec50fc22bf16._comment b/doc/forum/not_finding_git-annex-shell_on_remote/comment_1_84881cad02c251a2515cec50fc22bf16._comment
new file mode 100644
index 0000000000..8441f412af
--- /dev/null
+++ b/doc/forum/not_finding_git-annex-shell_on_remote/comment_1_84881cad02c251a2515cec50fc22bf16._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3HGoDpnOPob5jOjvIootmkve1-nCpRiI"
+ nickname="Kalle"
+ subject="Declare path on first line of bashrc?"
+ date="2014-02-15T18:36:35Z"
+ content="""
+If i don't misremember some systems including Debian require you to set the path on the very first line of .bashrc for it to work. Can't remember why just now.
+
+in other words paste the following into the very first line of `$HOME/.bashrc`
+
+`PATH=$PATH:$HOME/bin:$HOME/bin/git-annex.linux`
+
+Modify the line above if you haven't installed to `~/bin/git-annex.linux`
+
+
+"""]]
diff --git a/doc/forum/not_finding_git-annex-shell_on_remote/comment_2_f32412f8d3b84cd5cb3c4d5d6bb60f32._comment b/doc/forum/not_finding_git-annex-shell_on_remote/comment_2_f32412f8d3b84cd5cb3c4d5d6bb60f32._comment
new file mode 100644
index 0000000000..7acee2035a
--- /dev/null
+++ b/doc/forum/not_finding_git-annex-shell_on_remote/comment_2_f32412f8d3b84cd5cb3c4d5d6bb60f32._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3rK4VDzxyhmrIc18z7F5OuXvEbUsgUac"
+ nickname="Srinath"
+ subject="Progress, but still issues"
+ date="2014-02-17T04:09:23Z"
+ content="""
+\"I now realize that the git annex system still requires the standard \"add\" and \"commit\" process. But I'm still getting:
+
+$git annex sync
+commit  ok
+pull origin 
+remote: Counting objects: 37, done.
+remote: Compressing objects: 100% (35/35), done.
+remote: Total 36 (delta 0), reused 0 (delta 0)
+Unpacking objects: 100% (36/36), done.
+From ssh://stampede.tacc.utexas.edu/work/02463/srinathv/cesm1_3_beta07/scripts
+ * [new branch]      master     -> origin/master
+
+
+merge: refs/remotes/origin/synced/master - not something we can merge
+failed
+push origin 
+Counting objects: 11, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (6/6), done.
+Writing objects: 100% (8/8), 736 bytes | 0 bytes/s, done.
+Total 8 (delta 3), reused 1 (delta 0)
+To ssh://srinathv@stampede.tacc.utexas.edu/work/02463/srinathv/cesm1_3_beta07/scripts
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+ok
+git-annex: sync: 1 failed
+
+
+So the fails appear, and the suggestion of \"export PATH\" placement did not help, though appreciated.
+"""]]
diff --git a/doc/forum/not_finding_git-annex-shell_on_remote/comment_3_dfbf7f41dd4d17f2ce8b67daa9dcd11d._comment b/doc/forum/not_finding_git-annex-shell_on_remote/comment_3_dfbf7f41dd4d17f2ce8b67daa9dcd11d._comment
new file mode 100644
index 0000000000..53419452c2
--- /dev/null
+++ b/doc/forum/not_finding_git-annex-shell_on_remote/comment_3_dfbf7f41dd4d17f2ce8b67daa9dcd11d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3rK4VDzxyhmrIc18z7F5OuXvEbUsgUac"
+ nickname="Srinath"
+ subject="no more issue"
+ date="2014-02-17T04:25:31Z"
+ content="""
+After doing 1 more sync, the error messages are now gone.  I wonder if the refs directory needed to be synched correctly.
+"""]]
diff --git a/doc/forum/not_finding_git-annex-shell_on_remote/comment_4_71ae60efcacdba5e11548923b2c85b95._comment b/doc/forum/not_finding_git-annex-shell_on_remote/comment_4_71ae60efcacdba5e11548923b2c85b95._comment
new file mode 100644
index 0000000000..12bf8fa75e
--- /dev/null
+++ b/doc/forum/not_finding_git-annex-shell_on_remote/comment_4_71ae60efcacdba5e11548923b2c85b95._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 4"
+ date="2014-02-20T19:41:05Z"
+ content="""
+@Srinath I wonder if the machine you are running git-annex sync on is a Windows machine? I have seen that \" refs/remotes/origin/synced/master - not something we can merge\" intermittently when testing on Windows, but not other times.
+
+(It's not related to the original PATH configuration problem on your server.)
+"""]]
diff --git a/doc/forum/not_getting_file_contents.mdwn b/doc/forum/not_getting_file_contents.mdwn
new file mode 100644
index 0000000000..23150216dc
--- /dev/null
+++ b/doc/forum/not_getting_file_contents.mdwn
@@ -0,0 +1 @@
+I have 2 computers successfully exchanging files, but the contexts are incomplete.  Used text files, documents, mp3s as tests. Both computers report in the webapp that they are synched and file names are there.  But file sizes are wrong by 75% less and contents are unusable.  Is there something in the config?  Both machines on LinuxMint 13. 
diff --git a/doc/forum/not_getting_file_contents/comment_1_4a0f7f4de9c9bc4d13db033cb75d20af._comment b/doc/forum/not_getting_file_contents/comment_1_4a0f7f4de9c9bc4d13db033cb75d20af._comment
new file mode 100644
index 0000000000..e03ec333a6
--- /dev/null
+++ b/doc/forum/not_getting_file_contents/comment_1_4a0f7f4de9c9bc4d13db033cb75d20af._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 1"
+ date="2013-07-11T16:06:59Z"
+ content="""
+That certainly shouldn't be happening! 
+
+Are these computers syncing via local pairing, or are you using a transfer remote, and if so, which one?
+"""]]
diff --git a/doc/forum/not_getting_file_contents/comment_2_dc7403e1b551552f9fd00da6a1453570._comment b/doc/forum/not_getting_file_contents/comment_2_dc7403e1b551552f9fd00da6a1453570._comment
new file mode 100644
index 0000000000..499176b01e
--- /dev/null
+++ b/doc/forum/not_getting_file_contents/comment_2_dc7403e1b551552f9fd00da6a1453570._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="trilobite"
+ ip="71.17.134.14"
+ subject="comment 2"
+ date="2013-07-11T23:23:41Z"
+ content="""
+I did this with local synch in home lan.  Filenames do travel both directions.  Just not contents.  They are identifed as symlinks rather than files.
+"""]]
diff --git a/doc/forum/notify-start_and_notify-finish_for_the_assistant.mdwn b/doc/forum/notify-start_and_notify-finish_for_the_assistant.mdwn
new file mode 100644
index 0000000000..e9d1dccd7d
--- /dev/null
+++ b/doc/forum/notify-start_and_notify-finish_for_the_assistant.mdwn
@@ -0,0 +1,5 @@
+Is there a way to use notify-start and notify-finish, not when using git annex
+on the command line but also when using the assistant ?
+
+I would like to get notifications when I move files to annexed folders for when
+the transfer to the server is finished and such things.
diff --git a/doc/forum/notify-start_and_notify-finish_for_the_assistant/comment_1_d3da4ce5cfea6c0a3277e83e0181102d._comment b/doc/forum/notify-start_and_notify-finish_for_the_assistant/comment_1_d3da4ce5cfea6c0a3277e83e0181102d._comment
new file mode 100644
index 0000000000..80cc5a35cf
--- /dev/null
+++ b/doc/forum/notify-start_and_notify-finish_for_the_assistant/comment_1_d3da4ce5cfea6c0a3277e83e0181102d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-26T15:22:32Z"
+ content="""
+You can pass the --notify-start and --notify-finish to the assistant
+when starting it up if you want to.
+
+It would perhaps be worth adding a config option so it could remember
+persistently to notify.
+"""]]
diff --git a/doc/forum/notify-start_and_notify-finish_for_the_assistant/comment_2_01dfd865c469a5bc465f73347a65ce44._comment b/doc/forum/notify-start_and_notify-finish_for_the_assistant/comment_2_01dfd865c469a5bc465f73347a65ce44._comment
new file mode 100644
index 0000000000..b0522755dc
--- /dev/null
+++ b/doc/forum/notify-start_and_notify-finish_for_the_assistant/comment_2_01dfd865c469a5bc465f73347a65ce44._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://renaud.casenave.fr/"
+ subject="comment 2"
+ date="2015-03-27T18:25:17Z"
+ content="""
+Well, I thought about that but it doesn't seem to work.
+with `git annex get --notify-start --notify-finish` I properly get the notifications but with `git annex assistant --notify-start --notify-finish` I get nothing when a file is uploaded or downloaded
+"""]]
diff --git a/doc/forum/offsite_repo.mdwn b/doc/forum/offsite_repo.mdwn
new file mode 100644
index 0000000000..0b950a95eb
--- /dev/null
+++ b/doc/forum/offsite_repo.mdwn
@@ -0,0 +1,8 @@
+Hi there,
+
+Let's say I have a Pictures repo in my laptop. I want to have a local copy in an external backup drive and an offsite copy in google-drive. I set numcopies to 3. Is it possible to require that files in a repository have a copy in an offsite repo e.g. a google-drive special remote? So that when I run e.g. git annex fsck, I will be reminded that some local files are not yet backed up in an offsite repo. Probably via .git/config, I can declare a remote repo as an "offsite" repo. Something like: 
+
+    remote.repo_name.offsite = true
+
+
+Eric
diff --git a/doc/forum/offsite_repo/comment_1_1f3ab9a39baa16e3e307b23fd1aabeb8._comment b/doc/forum/offsite_repo/comment_1_1f3ab9a39baa16e3e307b23fd1aabeb8._comment
new file mode 100644
index 0000000000..79f1810b3d
--- /dev/null
+++ b/doc/forum/offsite_repo/comment_1_1f3ab9a39baa16e3e307b23fd1aabeb8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-02-08T17:32:00Z"
+ content="""
+What you're looking for is probably the [[required_content]] settings.
+
+However, `git annex fsck` did not perform any checks that required content
+was present. Now it does. Enjoy!
+"""]]
diff --git a/doc/forum/offsite_repo/comment_2_d4ecd0dc29597e3e0988e06ee9c4d245._comment b/doc/forum/offsite_repo/comment_2_d4ecd0dc29597e3e0988e06ee9c4d245._comment
new file mode 100644
index 0000000000..bcbb5ae366
--- /dev/null
+++ b/doc/forum/offsite_repo/comment_2_d4ecd0dc29597e3e0988e06ee9c4d245._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ericm"
+ avatar="http://cdn.libravatar.org/avatar/67ca64c5a99fb142fc2e3916333881ca"
+ subject="comment 2"
+ date="2018-02-11T08:59:07Z"
+ content="""
+Ok I think that will do. I'll give it a try when I get some time. Thanks!
+"""]]
diff --git a/doc/forum/offsite_repo/comment_3_4b233762116c52bd2a754f49152201b7._comment b/doc/forum/offsite_repo/comment_3_4b233762116c52bd2a754f49152201b7._comment
new file mode 100644
index 0000000000..a0ae5865aa
--- /dev/null
+++ b/doc/forum/offsite_repo/comment_3_4b233762116c52bd2a754f49152201b7._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="ericm"
+ avatar="http://cdn.libravatar.org/avatar/67ca64c5a99fb142fc2e3916333881ca"
+ subject="comment 3"
+ date="2018-02-18T13:46:00Z"
+ content="""
+Hi,
+
+I first tried messing around with required content settings in a test repo in direct mode. This is what I did to initialize a test repo:
+
+    git clone existing-repo
+    git annex init
+    git annex required . \"include=*.jpg\"
+
+Then I run fsck:
+
+    git annex fsck 
+
+And I get this output:
+
+    fsck viber/0.02.01.0e411306e0b3fc90.jpg (fixing link) ok
+    fsck viber/0.02.01.20943bf9c18e42.jpg (fixing link) ok
+    fsck viber/0.02.01.5126da68987493.jpg (fixing link) ok
+    ...
+
+I expected the fsck command to complain that the required jpg files are not present in the current repo and fail. However, that is not what I'm getting.
+
+Is this the expected behavior for a direct-mode repository? If not, is there something I missed?
+"""]]
diff --git a/doc/forum/offsite_repo/comment_4_2e3dfd605df004330396040737a7c5ee._comment b/doc/forum/offsite_repo/comment_4_2e3dfd605df004330396040737a7c5ee._comment
new file mode 100644
index 0000000000..15f8a3effc
--- /dev/null
+++ b/doc/forum/offsite_repo/comment_4_2e3dfd605df004330396040737a7c5ee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-02-22T16:51:34Z"
+ content="""
+It seems likely that you have not upgraded git-annex to a version where
+fsck checks the required content yet, especially since that change has not
+yet made it into a release of git-annex. It will be in the next release, or
+you can download a daily build to get it now.
+"""]]
diff --git a/doc/forum/offsite_repo/comment_5_59a7718fde634c96dd781ed5fca1f61a._comment b/doc/forum/offsite_repo/comment_5_59a7718fde634c96dd781ed5fca1f61a._comment
new file mode 100644
index 0000000000..ee5afb9fe7
--- /dev/null
+++ b/doc/forum/offsite_repo/comment_5_59a7718fde634c96dd781ed5fca1f61a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="ericm"
+ avatar="http://cdn.libravatar.org/avatar/67ca64c5a99fb142fc2e3916333881ca"
+ subject="comment 5"
+ date="2018-02-24T03:29:21Z"
+ content="""
+Ok I'll just wait for the next version. Btw I'm using the latest version: 6.20180112.
+Thanks!
+"""]]
diff --git a/doc/forum/one-off_unlocked_annex_files_that_go_against_large.mdwn b/doc/forum/one-off_unlocked_annex_files_that_go_against_large.mdwn
new file mode 100644
index 0000000000..7220551228
--- /dev/null
+++ b/doc/forum/one-off_unlocked_annex_files_that_go_against_large.mdwn
@@ -0,0 +1,69 @@
+I've been debugging an intermittent DataLad test failure
+(<https://github.com/datalad/datalad/issues/5300>) that is related to
+an unlocked annex file whose content switches to being tracked by git.
+Basically
+
+  * `git annex add` file A to the annex.
+
+  * Configure `annex.largefiles` in a way that would have sent file A
+    to git.
+
+  * If file A's mtime matches the index's, adding file B triggers the
+    clean filter to run on file A and sends its content to git in when
+    an unrelated file is added.
+
+This sequence looks pretty close to a situation described in a comment
+of the bug report below, except that `annex.largefiles` is configured
+persistently in the repository rather than via a temporary `-c
+annex.largefiles` override.
+
+https://git-annex.branchable.com/bugs/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/#comment-215a295d83c8a08806d4f9c65ae52b10
+
+As a concrete example, here's a demo that configures .txt files to be
+added to git, but then forces the addition of an unlocked annex file
+with `--force-large`.
+
+[[!format sh """
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/ga-XXXXXXX)" || exit 1
+
+git version
+git annex version | head -1
+
+git init -q
+git annex init
+git config annex.addunlocked true
+
+printf '*.txt annex.largefiles=nothing\n' >.gitattributes
+git add .gitattributes
+git commit -m"configured annex.largefiles"
+
+echo a >foo.txt
+git annex add --force-large foo.txt
+
+git diff
+"""]]
+
+```
+git version 2.31.1.394.g7d1e84936f
+git-annex version: 8.20210330
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
+[master (root-commit) 0018dd1] configured annex.largefiles
+ 1 file changed, 1 insertion(+)
+ create mode 100644 .gitattributes
+add foo.txt
+ok
+(recording state in git...)
+diff --git a/foo.txt b/foo.txt
+index 4580ed7..7898192 100644
+--- a/foo.txt
++++ b/foo.txt
+@@ -1 +1 @@
+-/annex/objects/SHA256E-s2--87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7.txt
++a
+```
+
+Is the above showing expected behavior?  That is, if
+`annex.largefiles` is configured to send a file to git, the clean
+filter will move it there the next time it runs on it?
diff --git a/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_1_9e4604f3c7ca9be1fe6a7020fee2fd96._comment b/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_1_9e4604f3c7ca9be1fe6a7020fee2fd96._comment
new file mode 100644
index 0000000000..e9b1916899
--- /dev/null
+++ b/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_1_9e4604f3c7ca9be1fe6a7020fee2fd96._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-05-03T11:04:30Z"
+ content="""
+AFAIK, this is a long known bug and fixing it is hard/impossible. I can't find the original bug report thought.
+"""]]
diff --git a/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_2_9bd32b89d0521fd1bec94683dffb4ecd._comment b/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_2_9bd32b89d0521fd1bec94683dffb4ecd._comment
new file mode 100644
index 0000000000..2415d2a513
--- /dev/null
+++ b/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_2_9bd32b89d0521fd1bec94683dffb4ecd._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-05-03T16:26:26Z"
+ content="""
+I think this is a bug.
+
+The smudge/clean filter already handles several similar cases so ought to
+also be able to handle this one.
+
+I've made a change that seems to work, and will *probably* not break other
+cases, although this is a complex and subtle area.
+"""]]
diff --git a/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_3_3c3c4b9ee0a99f0638717922785de675._comment b/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_3_3c3c4b9ee0a99f0638717922785de675._comment
new file mode 100644
index 0000000000..0bbb28fe77
--- /dev/null
+++ b/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_3_3c3c4b9ee0a99f0638717922785de675._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-05-10T16:20:37Z"
+ content="""
+Well Lukey was right, fixing this causes other breakage. Here's
+the bug report about what my change broke:
+[[bugs/case_where_using_pathspec_with_git-commit_leaves_s]]
+
+As well as the case in that bug, [[tips/largefiles]] has a recipe to convert
+an annexed file to be stored in git, which the change broke. 
+The recipe has `git annex add --force-small` be run on a file, which in turn
+runs `git add` on the file, which runs the smudge filter. So if the smudge
+filter then sees an annexed inode and keeps it annexed, it is going against
+what the user is trying to do there.
+
+So the change has been reverted.
+
+I guess that both problems could be avoided by having git-annex add not run
+git add, but stage the file in the index itself. (IIRC there were some
+reasons to use git add there, to do with .gitignore.)
+
+But I'm doubtful now that all problems could be avoided. For one,
+consider what happens when the user follows the recipe to convert an
+annexed file to be stored in git, running `git annex add --force-small
+file`, which does store it in git. But then, if the smudge clean filter runs
+on the file later for any reason, it would still see a known annexed inode,
+and convert it back to being stored in the annex.
+"""]]
diff --git a/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_4_8d1ba01f4e25606b960023eab38ec483._comment b/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_4_8d1ba01f4e25606b960023eab38ec483._comment
new file mode 100644
index 0000000000..cd3d8215c4
--- /dev/null
+++ b/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_4_8d1ba01f4e25606b960023eab38ec483._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-05-10T16:43:00Z"
+ content="""
+Maybe the solution would be for `git annex add`, whenever it decides to
+add a file to git (due to --force-small or largefiles config), to drop the
+inode out of the keys database? I think that would make all of the cases
+described so far work.
+"""]]
diff --git a/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_5_789e8ada06063f6a1c6d6358180dc202._comment b/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_5_789e8ada06063f6a1c6d6358180dc202._comment
new file mode 100644
index 0000000000..72add2bfad
--- /dev/null
+++ b/doc/forum/one-off_unlocked_annex_files_that_go_against_large/comment_5_789e8ada06063f6a1c6d6358180dc202._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-05-10T17:21:14Z"
+ content="""
+Yes, I seem to have been able to fix it like that. Also added a test case
+to make sure the largefiles conversion recipes keep working.
+
+Of course it's always possible there are other cases I've not thought of..
+"""]]
diff --git a/doc/forum/one_annex_versus_many_annexes__63__.mdwn b/doc/forum/one_annex_versus_many_annexes__63__.mdwn
new file mode 100644
index 0000000000..cafe2aa9f8
--- /dev/null
+++ b/doc/forum/one_annex_versus_many_annexes__63__.mdwn
@@ -0,0 +1,10 @@
+I'm curious how other people are using git-annex:
+
+ * A single annex containing everything they want to keep track of (albeit with some files only available in some remotes).
+ * Several annexes for different purposes.
+
+I'm mostly asking because I don't want to get too far into using git-annex without thinking clearly about which is the most suitable choice for me.  At present I have things split into two annexes, one for things I really wouldn't want to lose (and some of which are somewhat private), and another for comparatively throwaway items.  However, given the possibility of setting different annex.numcopies on different file globs or directories, it seems like it might be kind of silly to make my life more complicated by having more than one annex.
+
+Primarily, I'm curious if there are some implications of the decision that I haven't considered.  It seems like an obvious point that one would want different annexes is if they're used in distinctly different security-level environments (e.g. I'm happy to copy my FLAC (music) files over to my work computer which lives at the office, but I wouldn't want to copy personal financial documents - or even the filenames - there.)
+
+-Mike
diff --git a/doc/forum/one_or_many_annexes__63__.mdwn b/doc/forum/one_or_many_annexes__63__.mdwn
new file mode 100644
index 0000000000..57b311c18e
--- /dev/null
+++ b/doc/forum/one_or_many_annexes__63__.mdwn
@@ -0,0 +1,7 @@
+Just a question about other peoples' annex usage.  I've got one uber-annex (in ~/annex of course) where I keep ALL THE THINGS, movies, music, pictures, whatever.
+
+It's very big, of course.  And I worry about doing anything unusual with it (like trying out direct mode) because, hey, that's all my stuff.
+
+Like, just now, I tried flipping it into direct mode, and a handful of files stayed symlinks, which weirded me out.  (Maybe because I had the assistant running while I switched it, and that caused chaos?)  Then I flipped it back to indirect, and a bunch of files were left un-tracked, as real files rather than links!  I kind of freaked out, and did a big "git annex add" to add them all back. I haven't left a bug report because it's not something I want to try again experimentally to reproduce, I just want my repo back, you know?
+
+Anyways, this kind of thing might not happen if I kept multiple small repos.  I was wondering if anybody else worked that way, and what advantages/disadvantages you've found compared to having one super-repo.
diff --git a/doc/forum/one_or_many_annexes__63__/comment_1_656d96011801d67a45b0b3bb3d70fa63._comment b/doc/forum/one_or_many_annexes__63__/comment_1_656d96011801d67a45b0b3bb3d70fa63._comment
new file mode 100644
index 0000000000..240f9868fd
--- /dev/null
+++ b/doc/forum/one_or_many_annexes__63__/comment_1_656d96011801d67a45b0b3bb3d70fa63._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn7gQ1zZDdWhXy9H51W2krZYShNmKL3qfM"
+ nickname="Karsten"
+ subject="comment 1"
+ date="2013-01-21T21:25:12Z"
+ content="""
+That's an interesting question. Personally, I have two annexes. One for my \"digital library\": movies, music, ebooks, downloads, everything I want to keep but was not created by me. I don't want to loose them because getting them back would be expensive and cumbersome. The other is my personal archive for Photos and Videos I've taken, which are valuable as they contain many memories which would be impossible to recreate if lost. With the first one, I'm experimenting quite a lot, with the second one I'm very conservative. Hope that helps.
+"""]]
diff --git a/doc/forum/only_keep_current_version_of_files_in_repo.mdwn b/doc/forum/only_keep_current_version_of_files_in_repo.mdwn
new file mode 100644
index 0000000000..8f077ec42d
--- /dev/null
+++ b/doc/forum/only_keep_current_version_of_files_in_repo.mdwn
@@ -0,0 +1,23 @@
+Hi,
+
+I have a repo on a server, my laptop, and a separate backup hard drive. In the repo I have many small files as well as several very large files that are present in several versions. I want to set up my repos such that my backup hard drive has everything on it, my server has only the most recent version of the large files (the server is shared, so I don't want to hog disk space), and my laptop doesn't keep annexed files locally. 
+
+I think I can probably achieve what I want for the hard drive with 
+
+```shell
+git annex wanted harddrive standard
+git annex group harddrive backup
+```
+
+and for the laptop with 
+
+```shell
+git annex wanted laptop standard
+git annex group laptop incrementalbackup
+```
+
+but I haven't been able to figure out how to setup the server so it keeps the current copy of large files but not their old versions. Do you have any suggestions?
+Alternatively, I might be able to do it manually, but haven't been able to figure out how to specifically drop old versions of a file, so I would be open to suggestions on that front too.
+
+Thanks!
+-Jack
diff --git a/doc/forum/only_keep_current_version_of_files_in_repo/comment_1_dd03f7cd46a8c12a34e2b1cf78e7a057._comment b/doc/forum/only_keep_current_version_of_files_in_repo/comment_1_dd03f7cd46a8c12a34e2b1cf78e7a057._comment
new file mode 100644
index 0000000000..4a5f95a4b0
--- /dev/null
+++ b/doc/forum/only_keep_current_version_of_files_in_repo/comment_1_dd03f7cd46a8c12a34e2b1cf78e7a057._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="aurtzy"
+ avatar="http://cdn.libravatar.org/avatar/7d44f9b718a534ada04551ee8c72e07f"
+ subject="comment 1"
+ date="2023-06-15T01:56:43Z"
+ content="""
+Hi! It sounds like what you want is the client [standard group](/preferred_content/standard_groups/) without the archive exclusion part? If so, this should work: `git-annex wanted server \"include=*\"`
+"""]]
diff --git a/doc/forum/only_keep_current_version_of_files_in_repo/comment_2_b45120f0a11428b75c099ca3d85d9016._comment b/doc/forum/only_keep_current_version_of_files_in_repo/comment_2_b45120f0a11428b75c099ca3d85d9016._comment
new file mode 100644
index 0000000000..e465add7ae
--- /dev/null
+++ b/doc/forum/only_keep_current_version_of_files_in_repo/comment_2_b45120f0a11428b75c099ca3d85d9016._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-06-19T17:34:59Z"
+ content="""
+The straightforward way to do this is to run periodically on the hard
+drive:
+
+	git-annex unused
+	git-annex move --unused --from server
+
+If you're using `git-annex sync --content`, you need to use `--all` in
+order for it to consider unused content. Otherwise it will only operate
+on files in the current branch, and leave other content as-is.
+And you will need to run `git-annex unused` still.
+
+If you are using the assistant, it does periodically scan for unused
+content and moves them to some repository whose preferred content matches
+them.
+
+You're right that using the "backup" standard group will make the hard
+drive want the unused content. That's because it wants "`anything`", which
+matches files whether they are unused or not.
+
+Any preferred content expression that matches on a filename,
+like "`include=*`", makes it not want unused content, which has no
+filename.
+
+Or, you can use "`not unused`" in a preferred content expression to
+explicitly exclude the unused content.
+"""]]
diff --git a/doc/forum/optimising_lookupkey.mdwn b/doc/forum/optimising_lookupkey.mdwn
new file mode 100644
index 0000000000..5a7da73839
--- /dev/null
+++ b/doc/forum/optimising_lookupkey.mdwn
@@ -0,0 +1,13 @@
+to work around [[forum/original_filename_on_s3/]], i need to get the key from a file, and i'm not within the git-annex process. i know there's `git annex lookupkey $FILE`, but that incurs significant overhead because the whole git annex runtime needs to fire up. in my tests, this takes around 25ms on average.
+
+could i optimise this by simply doing a `readlink` call on the git checkout? it sure looks like `readlink | basename` is all I really need, and that can probably be done below 10ms (4ms in my tests). how reliable are those links anyways, and is that what lookupkey does?
+
+similarly, i wonder if it's safe to bypass git-annex and talk straight with git to extract location tracking? i can jump from 90ms to below 10ms for such requests if I turn `git annex find <file>` into the convoluted:
+
+<pre>
+git annex lookupkey $file
+printf $key | md5sum
+git cat-file -p refs/heads/git-annex:$hash/${key}.log
+</pre>
+
+thanks. --[[anarcat]]
diff --git a/doc/forum/optimising_lookupkey/comment_1_e06db4754805c1e0ee298ecc676427d2._comment b/doc/forum/optimising_lookupkey/comment_1_e06db4754805c1e0ee298ecc676427d2._comment
new file mode 100644
index 0000000000..2b26d5e58b
--- /dev/null
+++ b/doc/forum/optimising_lookupkey/comment_1_e06db4754805c1e0ee298ecc676427d2._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-17T21:46:01Z"
+ content="""
+Yes, that's the same, except lookupkey only operates on files that are
+checked into git.
+
+(Also, lookupkey will work in a direct mode repo, while such a repo
+may not have a symlink to examine.)
+
+25ms doesn't seem bad for a "whole runtime" to fire up. :) I think most of
+the overhead probably involves reading the git config and running
+git-ls-files.
+
+Note that lookupkey can be passed a whole set of files, so you could avoid
+the startup overhead that way too.
+"""]]
diff --git a/doc/forum/optimising_lookupkey/comment_2_7dbfa3da6ae72a1f0669396664dd0c1a._comment b/doc/forum/optimising_lookupkey/comment_2_7dbfa3da6ae72a1f0669396664dd0c1a._comment
new file mode 100644
index 0000000000..8b3c973d48
--- /dev/null
+++ b/doc/forum/optimising_lookupkey/comment_2_7dbfa3da6ae72a1f0669396664dd0c1a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-02-17T21:50:11Z"
+ content="""
+And yes, it's fine to bypass git-annex when querying git. 
+
+Or even when manipulating the git-annex branch, so long as you either
+delete or update .git/annex/index. git-annex is not intended to be magical,
+see [[internals]].
+"""]]
diff --git a/doc/forum/optimising_lookupkey/comment_3_2c895e4494cddab70ba761c6c48e7cf8._comment b/doc/forum/optimising_lookupkey/comment_3_2c895e4494cddab70ba761c6c48e7cf8._comment
new file mode 100644
index 0000000000..5ee6599586
--- /dev/null
+++ b/doc/forum/optimising_lookupkey/comment_3_2c895e4494cddab70ba761c6c48e7cf8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="thanks"
+ date="2015-02-18T21:53:52Z"
+ content="""
+great, thanks for the feedback!
+
+i agree that 25ms is quite fast to fire up a 52MB binary. :) i am just saying that if this is going to end up as part of building a webpage, i need something faster, or cache the results somewhere.
+
+duly noted for the other points, thanks again. i see a great intimate relationship building between `git cat-file` and me. ;)
+"""]]
diff --git a/doc/forum/original_filename_on_s3.mdwn b/doc/forum/original_filename_on_s3.mdwn
new file mode 100644
index 0000000000..7ecaab4e15
--- /dev/null
+++ b/doc/forum/original_filename_on_s3.mdwn
@@ -0,0 +1,5 @@
+I understand that [[special_remotes/S3/]] is seen as a "backend" storage mechanism, but since S3 files are available directly on the web, it would be nice to have the real filenames up there.
+
+Is there a way to set that up? I know about [[tips/publishing_your_files_to_the_public/]], but it assumes you have a local git repo with all the data in the first place, something which may not be available...
+
+my use case is that we have ~1TB of files already stored in S3 under specific filenames, and those filenames are how the files are accessed on the main website. changing all those filenames would be a significant burden... i'm not even sure this can be done cheaply on S3 in the first place. --[[anarcat]]
diff --git a/doc/forum/original_filename_on_s3/comment_1_870f3f01f95b5878d483ffedd2ae2698._comment b/doc/forum/original_filename_on_s3/comment_1_870f3f01f95b5878d483ffedd2ae2698._comment
new file mode 100644
index 0000000000..165b7f8f65
--- /dev/null
+++ b/doc/forum/original_filename_on_s3/comment_1_870f3f01f95b5878d483ffedd2ae2698._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="dupe?"
+ date="2015-03-07T02:06:06Z"
+ content="""
+see also [[todo/Facilitate_public_pretty_S3_URLs]]
+"""]]
diff --git a/doc/forum/original_filename_on_s3/comment_2_2a0d5d77219ae2410090eb1811ee1fec._comment b/doc/forum/original_filename_on_s3/comment_2_2a0d5d77219ae2410090eb1811ee1fec._comment
new file mode 100644
index 0000000000..bba4a63555
--- /dev/null
+++ b/doc/forum/original_filename_on_s3/comment_2_2a0d5d77219ae2410090eb1811ee1fec._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-10-31T20:10:22Z"
+ content="""
+What real filenames? A git-annex special remote is a key/value store, where
+any key can correspond to zero or any number of filenames in the working
+tree. 
+
+What you're doing with S3 is using it to publish some files over the web.
+Fine. That's not a S3 special remote, so don't use it that way, just `git
+annex addurl` the files from S3.
+"""]]
diff --git a/doc/forum/original_filename_on_s3/comment_3_0aea0eef336dd648013a9cf7789fc445._comment b/doc/forum/original_filename_on_s3/comment_3_0aea0eef336dd648013a9cf7789fc445._comment
new file mode 100644
index 0000000000..1d75687304
--- /dev/null
+++ b/doc/forum/original_filename_on_s3/comment_3_0aea0eef336dd648013a9cf7789fc445._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-09-07T20:13:23Z"
+ content="""
+The new `git-annex export` feature allows you to export a tree
+to a special remote, with the origiginal filenames being visible there.
+
+S3 should support it soon.
+"""]]
diff --git a/doc/forum/othertmp__58___createDirectory__58___already_exists.mdwn b/doc/forum/othertmp__58___createDirectory__58___already_exists.mdwn
new file mode 100644
index 0000000000..fb227559d8
--- /dev/null
+++ b/doc/forum/othertmp__58___createDirectory__58___already_exists.mdwn
@@ -0,0 +1,38 @@
+Through no fault of Git Annex's, my drive lost power in the middle of a `git annex add`, and seems to have experienced corruption.
+
+(If it matters, here's the log of what was happening when the drive powered off:)
+
+```
+# [...snip...]
+add disk/DCIM/101_FUJI/DSCF3929.MOV
+ok
+add disk/DCIM/101_FUJI/DSCF3930.MOV
+ok
+add disk/DCIM/101_FUJI/DSCF3931.MOV
+0%    31.98 KiB        67 MiB/s 5s
+git-annex: ../.git/annex/othertmp/ingest-DSCF3931423025-19.MOV: hGetBuf: hardware fault (Input/output error)
+failed
+fatal: not a git repository: '../.git'
+fatal: unable to access '../.git/config': Input/output error
+git-annex: ../.git/annex: createDirectory: hardware fault (Input/output error)
+```
+
+
+Right after it happened, I tried to check on the data and got this error:
+
+```
+$ git annex fsck                                                    
+fatal: /media/foo/bar/.git/annex/index: index file open failed: Structure needs cleaning                                                                                                   
+git-annex: fd:13: hPutBuf: resource vanished (Broken pipe)
+```
+
+I fixed this (I hope) with an `fsck` of the drive (not a `git fsck` or `git annex fsck` - an actual `fsck` to repair the filesystem). Now I want to check that everything's okay with the data, and I run:
+
+```
+$ git annex fsck
+git-annex: .git/annex/othertmp: createDirectory: already exists (File exists)
+```
+
+How can I get past this error?
+
+Thanks!!
diff --git a/doc/forum/othertmp__58___createDirectory__58___already_exists/comment_1_6fb34a361417e4cac08edc20fd2bc3e7._comment b/doc/forum/othertmp__58___createDirectory__58___already_exists/comment_1_6fb34a361417e4cac08edc20fd2bc3e7._comment
new file mode 100644
index 0000000000..3189625f3f
--- /dev/null
+++ b/doc/forum/othertmp__58___createDirectory__58___already_exists/comment_1_6fb34a361417e4cac08edc20fd2bc3e7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="amindfv@97236fbaab6048ce6805b2737b27dd7f1cd51da4"
+ nickname="amindfv"
+ avatar="http://cdn.libravatar.org/avatar/a82f30bc12d79fee2d142021af8e9aa0"
+ subject="comment 1"
+ date="2022-11-10T21:29:33Z"
+ content="""
+If it matters for the answer, the data I was in the middle of `git annex add`-ing is replaceable. I.e. I'd be perfectly happy to bring my repo back to the state before the `add` and simply copy the data over again and then `add` it again.
+
+Also my version is 8.20210223
+
+"""]]
diff --git a/doc/forum/othertmp__58___createDirectory__58___already_exists/comment_2_0a9372f3dba83b6cee3a33933bf2b006._comment b/doc/forum/othertmp__58___createDirectory__58___already_exists/comment_2_0a9372f3dba83b6cee3a33933bf2b006._comment
new file mode 100644
index 0000000000..42705eede3
--- /dev/null
+++ b/doc/forum/othertmp__58___createDirectory__58___already_exists/comment_2_0a9372f3dba83b6cee3a33933bf2b006._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-11-14T17:14:51Z"
+ content="""
+Seems that your `.git/annex/othertmp` has somehow became a file.
+git-annex expects it to be a directory, or to not exist, but when it's
+a file, git-annex doesn't understand what is happening and so can fail this
+way.
+
+It's probably safe to delete a `.git/annex/othertmp` file,
+although since you had disk corruption, 
+you might want to take a backup of it first.
+"""]]
diff --git a/doc/forum/overmounting_repository_at_home.mdwn b/doc/forum/overmounting_repository_at_home.mdwn
new file mode 100644
index 0000000000..2bac1994f0
--- /dev/null
+++ b/doc/forum/overmounting_repository_at_home.mdwn
@@ -0,0 +1,12 @@
+Consider the following scenario:
+
+- A Server which holds the full repository
+- A Laptop with a small disk, cloned the repository
+
+Now when i am online i'd just like to mount the repository from the server on over to the client, shadowing the local repository. But when offline and the server is not
+mounted the local repository takes place.
+
+The Question is now what would be a viable concept to get this right. Especially will the assistant become confused when it runs on the server side and locally on the laptop
+while the mount is in effect. Would it be sensible not to mount the whole repository tree but only parts like `.git/annex` or `.git/annex/objects`?
+
+Not tried this yet, but I am wondering whats the most viable approach would be.
diff --git a/doc/forum/overmounting_repository_at_home/comment_1_399ac5014c489698e1e45deec4db7311._comment b/doc/forum/overmounting_repository_at_home/comment_1_399ac5014c489698e1e45deec4db7311._comment
new file mode 100644
index 0000000000..90ce2ae403
--- /dev/null
+++ b/doc/forum/overmounting_repository_at_home/comment_1_399ac5014c489698e1e45deec4db7311._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica Semrick"
+ subject="sounds like a bad idea... but..."
+ date="2014-06-24T04:18:51Z"
+ content="""
+From the few details you give, this sounds like a bad idea. git-annex tells different repos apart by using a UUID. You can see this UUID in `.git/config`.
+
+But if you are really insistent on doing this, you could always system link the folder to the spot you want it, then write a script that mounts the server in an arbitrary location and redoes the system link. I'd try this on a copy of the data or with some data that doesn't matter before going for it.
+"""]]
diff --git a/doc/forum/overmounting_repository_at_home/comment_2_d006d89ba204568cdee0731b6251ec1a._comment b/doc/forum/overmounting_repository_at_home/comment_2_d006d89ba204568cdee0731b6251ec1a._comment
new file mode 100644
index 0000000000..2413948b7a
--- /dev/null
+++ b/doc/forum/overmounting_repository_at_home/comment_2_d006d89ba204568cdee0731b6251ec1a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="cehteh"
+ ip="217.8.62.137"
+ subject="comment 2"
+ date="2014-06-24T14:03:01Z"
+ content="""
+I know that this is a bad idea right now when done in a naive approach, I am wondering if git-annex could be made aware of this case and how it could be implemented.
+A immature idea for example would be only to overmount the .git/annex/objects folder and let the git-annex check if the objects lay on a different device, if so, refuse to do operation on the object store.
+
+I started this thread to figure out if there is some interest in such functionality and if so, polishing it out to see how it could be done. 
+"""]]
diff --git a/doc/forum/overmounting_repository_at_home/comment_3_3734b50c37cbec675813cbeca7bf4ce9._comment b/doc/forum/overmounting_repository_at_home/comment_3_3734b50c37cbec675813cbeca7bf4ce9._comment
new file mode 100644
index 0000000000..029e9eba09
--- /dev/null
+++ b/doc/forum/overmounting_repository_at_home/comment_3_3734b50c37cbec675813cbeca7bf4ce9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://ypid.wordpress.com/"
+ ip="213.153.84.215"
+ subject="Already on todo list"
+ date="2014-06-24T16:58:05Z"
+ content="""
+As is appears to me, the feature you are suggesting is already on \"the todo list\" as [[union_mounting|todo/union_mounting]]. I would also really appreciate this feature …
+"""]]
diff --git a/doc/forum/overwrite_files_with_export_to_special_remote.mdwn b/doc/forum/overwrite_files_with_export_to_special_remote.mdwn
new file mode 100644
index 0000000000..146a8ff23a
--- /dev/null
+++ b/doc/forum/overwrite_files_with_export_to_special_remote.mdwn
@@ -0,0 +1,10 @@
+Hi,
+I'd like to overwrite any conflicting files during an export to the directory special remote. 
+
+I just exported ~30000 files but the export got interrupted half way. It resumed all right but 71 files seem to differ as git annex says it's "unsafe to overwrite" the files. 
+
+Alternatively I'd be fine with getting neat output of the list of affected files somehow so that I can automate removal. 
+
+I've looked through all the man pages I could find but there doesn't seem to be an obvious "overwrite" option.
+
+I'd be thankful for any help.
diff --git a/doc/forum/overwrite_files_with_export_to_special_remote/comment_1_8091fc1d63ad0a96e086c91a26e2af70._comment b/doc/forum/overwrite_files_with_export_to_special_remote/comment_1_8091fc1d63ad0a96e086c91a26e2af70._comment
new file mode 100644
index 0000000000..3641e2c583
--- /dev/null
+++ b/doc/forum/overwrite_files_with_export_to_special_remote/comment_1_8091fc1d63ad0a96e086c91a26e2af70._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-10T19:18:26Z"
+ content="""
+If the special remote is configured with importtree=yes, you can `git-annex
+import --from` it. That will let git-annex realize that the files on it are
+ones it knows (or if they are somehow not, it will start tracking their
+content), and so you should then be able to export back to it.
+"""]]
diff --git a/doc/forum/partial_annex_repository.mdwn b/doc/forum/partial_annex_repository.mdwn
new file mode 100644
index 0000000000..d83eac1a77
--- /dev/null
+++ b/doc/forum/partial_annex_repository.mdwn
@@ -0,0 +1,14 @@
+After I created a git repository, I added annex to it.
+
+Now, if I add a new file with 'git add', it goes into the annex.   However previously existing files are not in the annex.
+
+What are the implications of this?   Should I care?
+
+FWIW, most of the files are small, so I see no reason for the annex for them.
+
+How do I add a new file and not put it in the annex?
+
+How to I switch a file from one to the other?
+
+Thanks.
+
diff --git a/doc/forum/partial_annex_repository/comment_1_5e594914724a04e21087e1e4e57c2d30._comment b/doc/forum/partial_annex_repository/comment_1_5e594914724a04e21087e1e4e57c2d30._comment
new file mode 100644
index 0000000000..a92c9e6a98
--- /dev/null
+++ b/doc/forum/partial_annex_repository/comment_1_5e594914724a04e21087e1e4e57c2d30._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="git-starter"
+ subject="clarification"
+ date="2016-09-13T20:27:22Z"
+ content="""
+My previous posting looks like I'm not aware of largefiles, which would mostly answer my question.    My problem was that, after reading some doc that might not have been fully updated for v6, I got confused about the difference between an unlocked file in the annex, and a file not in the annex.    
+
+In any case, since I added some small files before using largefiles, those small files were put in the annex.   How do I change them to be in the git repository not in the annex?
+
+Thanks.
+
+
+
+"""]]
diff --git a/doc/forum/partial_annex_repository/comment_2_e6a9584bacc3ec98c4757c82a195b414._comment b/doc/forum/partial_annex_repository/comment_2_e6a9584bacc3ec98c4757c82a195b414._comment
new file mode 100644
index 0000000000..a7c0d1ec02
--- /dev/null
+++ b/doc/forum/partial_annex_repository/comment_2_e6a9584bacc3ec98c4757c82a195b414._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-09-21T16:54:24Z"
+ content="""
+Right, it's a feature of v6 mode that `git add` adds the file to the annex,
+unless annex.largefiles is configured to make it be added directly to the
+git repository.
+
+To switch your small files that are currently annexed to be added
+directly to git, the easiest way is:
+
+	git annex unannex $file
+	git -c 'annex.largefiles=exclude=*' add $file
+"""]]
diff --git a/doc/forum/partial_synchronisation._android_phone.mdwn b/doc/forum/partial_synchronisation._android_phone.mdwn
new file mode 100644
index 0000000000..7abfb24cd7
--- /dev/null
+++ b/doc/forum/partial_synchronisation._android_phone.mdwn
@@ -0,0 +1,7 @@
+hi
+
+i have a repository that is 30 gb large. i would like to sync some content onto my android phone. take mp3's for example. i would like to see whole content on android but my phone does not have that much flash space. i would like to manualy select what folders, files will be copied onto phone.
+
+this use case may not even refer strictly to android devices but even pc's. for exaple i have small ssd drive on laptop. whole contentis kept on some hudge  raid array. i will see whole directory structure but whenever i want a file i will just shedule it for download.
+
+is it possible ? or maybe i just can not find the answer on project page ?
diff --git a/doc/forum/partial_synchronisation._android_phone/comment_1_2a48569277945a9c334bdfc51f8fd01f._comment b/doc/forum/partial_synchronisation._android_phone/comment_1_2a48569277945a9c334bdfc51f8fd01f._comment
new file mode 100644
index 0000000000..b9c28a1229
--- /dev/null
+++ b/doc/forum/partial_synchronisation._android_phone/comment_1_2a48569277945a9c334bdfc51f8fd01f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2013-12-29T21:57:05Z"
+ content="""
+You can either put a repository in manual mode, which requires you run `git annex get` etc to get just the files you want, or you can find or write a [[preferred_content]] expression that matches only the files you want in a repository, and then the assistant will make it contain only those.
+"""]]
diff --git a/doc/forum/partial_synchronisation._android_phone/comment_2_550ae91c8a1fe060368c4682d37514b6._comment b/doc/forum/partial_synchronisation._android_phone/comment_2_550ae91c8a1fe060368c4682d37514b6._comment
new file mode 100644
index 0000000000..e549bf7cc9
--- /dev/null
+++ b/doc/forum/partial_synchronisation._android_phone/comment_2_550ae91c8a1fe060368c4682d37514b6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkNE-H4vEcbcGndxq5daT8qUb7yIf7r1OE"
+ nickname="Łukasz"
+ subject="comment 2"
+ date="2013-12-30T22:13:15Z"
+ content="""
+thx for reply
+"""]]
diff --git a/doc/forum/people__39__s_experience_with_parallel_git-annex_operations.mdwn b/doc/forum/people__39__s_experience_with_parallel_git-annex_operations.mdwn
new file mode 100644
index 0000000000..2e401d9053
--- /dev/null
+++ b/doc/forum/people__39__s_experience_with_parallel_git-annex_operations.mdwn
@@ -0,0 +1 @@
+Have others experienced frequent failures of parallel/concurrent git-annex operations, like ones described in [[bugs/concurrent_git-annex-copy_to_s3_special_remote_fails/]] and [[bugs/parallel_copy_fails/]]?  I'm trying to understand if there is something specific to my system that makes these failures more likely.  Thanks!
diff --git a/doc/forum/people__39__s_experience_with_parallel_git-annex_operations/comment_1_5f3b51692797f56656f313e8455c1b5f._comment b/doc/forum/people__39__s_experience_with_parallel_git-annex_operations/comment_1_5f3b51692797f56656f313e8455c1b5f._comment
new file mode 100644
index 0000000000..eddf42ec9e
--- /dev/null
+++ b/doc/forum/people__39__s_experience_with_parallel_git-annex_operations/comment_1_5f3b51692797f56656f313e8455c1b5f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 1"
+ date="2019-09-20T20:12:31Z"
+ content="""
+Yes! I've had issues with parallel operations on google remotes. I thought it might be a problem in git-annex-remote-googledrive and I didn't have time yet to investigate it further, so I didn't report it here.
+"""]]
diff --git a/doc/forum/performance_and_multiple_replication_problems.mdwn b/doc/forum/performance_and_multiple_replication_problems.mdwn
new file mode 100644
index 0000000000..7f2f90fddf
--- /dev/null
+++ b/doc/forum/performance_and_multiple_replication_problems.mdwn
@@ -0,0 +1,17 @@
+Hi,
+
+I just was setting um my git-annex repository and started to sync my whole stuff in it.
+
+Background: I have choosen git-annex to sync my whole stuff (pictures, mp3s, documents, etc) between my pc, notebook and a home-server
+
+My Problems:
+1) When I'm starting the git-annex deamon, the "Performing startup scan" message occurs for hours
+2) git-annex synchronizes folders from the server which already on my pc, and that every time I restart the deamon on client
+
+My Questions:
+For 1) is git-annex when running one repository suitable to manage > 100gb and > 50000 files?
+For 2) do I have to wait until every tasks are completed (everything is committed) to get rid of multiple downloads of the same folders/files
+3) what is the best schema to sync between >2 devices should I use a Mesh or Star Schema (where my server is in the middle)
+
+Thank You in advance!
+Regards J
diff --git a/doc/forum/performance_and_multiple_replication_problems/comment_1_a2cdf1a4840f099f6bc941fd8de966c7._comment b/doc/forum/performance_and_multiple_replication_problems/comment_1_a2cdf1a4840f099f6bc941fd8de966c7._comment
new file mode 100644
index 0000000000..aab0ec17fd
--- /dev/null
+++ b/doc/forum/performance_and_multiple_replication_problems/comment_1_a2cdf1a4840f099f6bc941fd8de966c7._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-06-11T15:06:58Z"
+ content="""
+It sounds like you are using git-annex to sync a *lot* of files. The startup scan is a basic check that there are no new, deleted, or modified files since the last time it ran. This requires a little work, like statting the files, but won't take long for reasonable numbers of files. 
+
+The size of files doesn't affect the length of the scan. I have a repository with on the order of 50k files, and the startup scan takes only a few minutes. One thing that could matter is that my repository is in indirect mode. Direct mode is less efficient. You could try to switch your repository to indirect mode: `git annex indirect` (you can always switch back: `git annex direct`)
+
+It would be possible to disable that scan, but at the expense of not being able to sync changes made while git-annex is not running. There's also a trick you can use: Start the assistant running in a subdirectory and it will only scan that subdirectory (it will only notice new files in that subdirectory too..)
+
+I don't quite understand what you mean with problem #2. If files were repeatedly being uploaded or downloaded, that have already been sent, that would be a bug. Please file a bug report with full debug logs if that is the case.
+
+Which topology is best? I think the best way is to start with the one you like, and if it doesn't work well, add more links between repositories. A star topology will certainly work ok. A mesh can work ok but can be hard to maintain.
+"""]]
diff --git a/doc/forum/performance_and_multiple_replication_problems/comment_2_e65b360706c66ede6e0e841b2ebbbfbc._comment b/doc/forum/performance_and_multiple_replication_problems/comment_2_e65b360706c66ede6e0e841b2ebbbfbc._comment
new file mode 100644
index 0000000000..3ce2447bc7
--- /dev/null
+++ b/doc/forum/performance_and_multiple_replication_problems/comment_2_e65b360706c66ede6e0e841b2ebbbfbc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7"
+ nickname="Frederik Vanrenterghem"
+ subject="comment 2"
+ date="2013-06-12T00:47:21Z"
+ content="""
+I have witnessed that second problem as well, to the point where I've stopped autostarting (and hence using) git annex for the moment. I'll try to get some debugging data.
+"""]]
diff --git a/doc/forum/performance_and_multiple_replication_problems/comment_3_ad7cb4c510e2ab26959ea7cb40a43fef._comment b/doc/forum/performance_and_multiple_replication_problems/comment_3_ad7cb4c510e2ab26959ea7cb40a43fef._comment
new file mode 100644
index 0000000000..6e4e1b1c63
--- /dev/null
+++ b/doc/forum/performance_and_multiple_replication_problems/comment_3_ad7cb4c510e2ab26959ea7cb40a43fef._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="the startup check is not a small issue"
+ date="2014-02-25T11:37:15Z"
+ content="""
+I would like to add that this startup check has probably been a blocker for my use case for a long long time. I tried to use git-annex to synchronize a huge number of files, most of them never changing. My plan was to have a few tens of GB of data which more or less never change in an archive directory and then add from time to time new data (by batches of a few hundreds of files, each of them not necessarily very large) to the annex. Once this new data has been processed or otherwise become less immediately useful, it would be shifted to the archive. It would have been very useful to have such a setup, because the amount of data is too large to be replicated everywhere, especially on a laptop. After finding this post I finally understand that the seemingly never ending \"performing startup scan\" that I observed are probably not due to the assistant somehow hanging, contrary to what I thought. It seems it is just normal operation. The problem is that this normal operation makes it unusable for the use case I was considering, since it does not make much sense to have git-annex scanning about 10^6 files or links on every boot of a laptop. On my workstation this \"startup scan\" has now been running for close to one hour now and is not finished yet, this is not thinkable on laptop boot. 
+
+Maybe an analysis of how well git-annex operation scales with number of files should be part of the documentation, since \"large files\" is not the only issue when trying to sync different computers. One finds references to \"very large number of files\" about annex.queuesize, but \"very large\" has no clear meaning. One also finds a reference to \"1 million files\" being a bit of a git limitation on comments of a bug report <https://git-annex.branchable.com/bugs/Stress_test/>. 
+
+Orders of magnitude of the number of files that git-annex is supposed to be able to handle would be very useful. 
+
+
+"""]]
diff --git a/doc/forum/performance_and_multiple_replication_problems/comment_4_23a6dc7ea569944ca55bd21851dd770d._comment b/doc/forum/performance_and_multiple_replication_problems/comment_4_23a6dc7ea569944ca55bd21851dd770d._comment
new file mode 100644
index 0000000000..77fe564fc8
--- /dev/null
+++ b/doc/forum/performance_and_multiple_replication_problems/comment_4_23a6dc7ea569944ca55bd21851dd770d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.146"
+ subject="comment 4"
+ date="2014-03-05T22:06:00Z"
+ content="""
+@maurizio, that's a good motivating example.
+
+So, I have made `git config annex.startupscan false` disable the startup scan (except for a minor tree walk that needs to be done to get inotify working).
+
+Of course, if you set that, the assistant won't notice any changes that are made when it's not running. It would work well to set it if the assistant is started at boot and left running until shutdown.
+
+My goal for git-annex is for it to scale to how ever many files git scales to. So I try to always make git be the limiting factor. I feel that git scales fairly well into the 100k file range.
+"""]]
diff --git a/doc/forum/performance_and_multiple_replication_problems/comment_5_8df6cc8b72e0e78c7380f7d471124498._comment b/doc/forum/performance_and_multiple_replication_problems/comment_5_8df6cc8b72e0e78c7380f7d471124498._comment
new file mode 100644
index 0000000000..f881942f90
--- /dev/null
+++ b/doc/forum/performance_and_multiple_replication_problems/comment_5_8df6cc8b72e0e78c7380f7d471124498._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="134.147.14.84"
+ subject="comment 5"
+ date="2014-07-08T12:26:58Z"
+ content="""
+Something to keep in mind for some point in the future: btrfs supports an efficient method by which one can inquire exactly which files have changed since a specified point in time, where the point in time is measured by a unit called «generation».
+
+A program can request the current «generation» index, and later ask btrfs which files have changed after that index, without needing to walk the file-system. This is currently implemented in the user-space program «btrfs filesystem find-new». While it’s called «find-new», this not only find newly created files, but also changed files.
+
+Currently, it seems one needs to be super-user to use «find-new», because it lists changed files for complete subvolumes, but since generations are stored per-file, in the future there will likely be a user-space method for regular users.
+"""]]
diff --git a/doc/forum/performance_for_FTP_site_mirroring.mdwn b/doc/forum/performance_for_FTP_site_mirroring.mdwn
new file mode 100644
index 0000000000..0bee18b790
--- /dev/null
+++ b/doc/forum/performance_for_FTP_site_mirroring.mdwn
@@ -0,0 +1,23 @@
+Hello --
+
+I want to use git (and git-annex) to take point-in-time snapshots of an FTP site.  Think "web.archive.org" but for an FTP site.  I'm using LFTP to mirror the site into a directory, which I then check into git.  This way I can go back in time to see what the state of the site was in the past.
+
+The site itself is currently about 10K files and about 30GB.  The files themselves are mostly zip files, as well as some xml files.  I expect files to not change much, and when they do I expect their sizes and modification times to change.  I'm using v6 mode with unlocked files.
+
+Here are my questions:
+
+1. I found that plain "git status" and "git diff" (not using git-annex) is quite slow.  i assume this is because git is computing checksums of all the files?
+
+2. On the assumption that the problem is that git is computing checksums, it seems like the appropriate way to get more performance is to tell git-annex to ignore checksum, i.e. use the WORM backend.  Is this correct?  I found that git status with the WORM backend set is fast.
+
+3. What is the proper way to set a backend globally?  'git annex init' has an option "--backend" but it doesn't seem to have any effect.  The correct way to set this globally is "git config annex.backends WORM", yes?
+
+4. Since I'm using another program to mirror the site, it appears I cannot use "locked" mode, as the mirroring program (lftp) will see that git-annex has replaced everything with symlinks and re-download the files.  Correct?  Therefore I'm using plain "git add" instead of "git annex add."
+
+5. Another reason why I appear to be forced to use "unlocked" mode is that, as part of the mirroring, the directory permissions are set to match the site, which are not writable.  git-annex appears to be unable to move the files that are inside of directories without write permissions.  Note that I am the owner of the local files/directories, and lftp happily adds and modifies files insides of these unwritable directories just fine, presumably by temporarily changing the permissions.  Is this correct?  Should I submit a feature request here?
+
+5. Although I am using WORM and unlocked mode, I found the initial "git add" and "git commit" of the 10K / 30GB of files to be pretty slow.  It takes on the order of 30 minutes for the add and an hour for the commit.  I didn't see a ton of either CPU or I/O activity.  A subsequent update of about 600 files is taking a long time to add (running 'git add -A'.)  I assume commit time will also be long.  Is this to be expected?  I would have hoped that the WORM backend prevents git from needing to actually read the files for a checksum.
+
+6. I understand that "thin = false" will lead to data duplication.  I assume this will make the initial commits slower.  Are there other performance implications of changing the thin setting?
+
+Thank you for creating a great tool.
diff --git a/doc/forum/performance_for_FTP_site_mirroring/comment_1_7648fced001ce1c34726e913e06273e9._comment b/doc/forum/performance_for_FTP_site_mirroring/comment_1_7648fced001ce1c34726e913e06273e9._comment
new file mode 100644
index 0000000000..9e886e44ec
--- /dev/null
+++ b/doc/forum/performance_for_FTP_site_mirroring/comment_1_7648fced001ce1c34726e913e06273e9._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-12T18:50:10Z"
+ content="""
+Are you using v6 mode? I'd have two entirely different sets of anwsers to
+all of these questions depending on whether you're using v6 mode or not.
+
+Since you mentioned annex.thin, I'm going to guess v6 mode...
+
+1. `git status` will be slow in v6 mode if files have been dropped or
+   git's index has otherwise gotten out of sync. This is the main reason v6
+   mode is still considered experiemental. It's being worked on.
+2. WORM backend won't help with 1. The only thing WORM is going to speed
+   up is avoiding checksumming when adding files. At the cost that two
+   versions of a file with the same size and different content can't be
+   differentiated.
+3. Yes, git config annex.backends WORM would set the WORM backend by default.
+   I don't think that WORM is a good fit for your use case though.
+4. `git add` is much slower than `git-annex add`, because the former has to run
+   git-annex once per file added. Instead, run: `git config annex.addunlocked true`
+   and then `git annex add` will add the files unlocked.
+5. We could think about making `git annex add` fiddle with directory perms
+   to allow replacing a file with the annex symlink. But, what happens
+   if it loses power before it can fix the perms back to original mode?
+   Etc. Perhaps there's a way to make lftp not remove write perms to start
+   with. But I think you're going to need to use unlocked files anyway,
+   otherwise lftp mirror is probably going to see the annexed symlink as
+   different than the remote file, and replace it.
+6. See #4.
+7. No, annex.thin does not make anything slower AFAIK.
+"""]]
diff --git a/doc/forum/performance_for_FTP_site_mirroring/comment_2_fa2b7400c85356d4de6da8459a5c3b50._comment b/doc/forum/performance_for_FTP_site_mirroring/comment_2_fa2b7400c85356d4de6da8459a5c3b50._comment
new file mode 100644
index 0000000000..e5d44d0f6d
--- /dev/null
+++ b/doc/forum/performance_for_FTP_site_mirroring/comment_2_fa2b7400c85356d4de6da8459a5c3b50._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="midfield"
+ subject="v6 mode"
+ date="2016-05-12T20:19:15Z"
+ content="""
+i am using v6 mode, edited original question to reflect this.
+"""]]
diff --git a/doc/forum/performance_for_FTP_site_mirroring/comment_3_cb4d7b283f20b43283036f20ebc648ec._comment b/doc/forum/performance_for_FTP_site_mirroring/comment_3_cb4d7b283f20b43283036f20ebc648ec._comment
new file mode 100644
index 0000000000..36b1595dd0
--- /dev/null
+++ b/doc/forum/performance_for_FTP_site_mirroring/comment_3_cb4d7b283f20b43283036f20ebc648ec._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="midfield"
+ subject="timings"
+ date="2016-05-15T19:58:37Z"
+ content="""
+for what it's worth, even with your suggestions i was unable to make git commit work quickly (it takes over an hour for the initial commit.  it only takes 4 minutes to copy the files themselves.)  thank you for the help though.
+"""]]
diff --git a/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk.mdwn b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk.mdwn
new file mode 100644
index 0000000000..f70c127025
--- /dev/null
+++ b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk.mdwn
@@ -0,0 +1,12 @@
+This works with bind-mount, I might try with softlinks as well.
+
+Going through git's data on push/pull can take ages on a spindle disk even
+if the repo is rather small in size. This is especially true if you are
+used to ssd speeds, but ssd storage is expensive. Storing the annex objects
+on a cheap spindle disk and everything else on a ssd makes things a _lot_
+faster.
+
+> Update: git-annex supports `.git/annex/` being moved to a different disk
+> than the rest of the repisitory, but does *not* support individual 
+> subdirectories, like `.git/annex/objects/` being on a different disk
+> than the main `.git/annex/` directory. --[[Joey]]
diff --git a/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_1_b3f22f9be02bc4f2d5a121db3d753ff5._comment b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_1_b3f22f9be02bc4f2d5a121db3d753ff5._comment
new file mode 100644
index 0000000000..124993bcf1
--- /dev/null
+++ b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_1_b3f22f9be02bc4f2d5a121db3d753ff5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-04-02T17:48:29Z"
+ content="""
+Either option should work fine, but git gc --aggressive will probably avoid most of git's seeking.
+"""]]
diff --git a/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_2_f94abce32ef818176b42a3cc860691ae._comment b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_2_f94abce32ef818176b42a3cc860691ae._comment
new file mode 100644
index 0000000000..eddc8c6315
--- /dev/null
+++ b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_2_f94abce32ef818176b42a3cc860691ae._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 2"
+ date="2011-04-02T21:34:24Z"
+ content="""
+I'll give it a try as soon as I get rid of this:
+
+    % git annex fsck
+fatal: index file smaller than expected
+fatal: index file smaller than expected
+    % git status
+fatal: index file smaller than expected
+    %    
+
+And no, I am not sure where that is coming from all of a sudden... (it might have to do with a hard lockup of the whole system due to a faulty hdd I tested, but I didn't do anything to it for ages before that lock-up. So meh. Also, this is prolly off topic in here)
+
+
+Richard
+"""]]
diff --git a/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_3_0c8e77fe248e00bd990d568623e5a5c9._comment b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_3_0c8e77fe248e00bd990d568623e5a5c9._comment
new file mode 100644
index 0000000000..fc29236c6d
--- /dev/null
+++ b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_3_0c8e77fe248e00bd990d568623e5a5c9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-04-03T01:48:57Z"
+ content="""
+For future reference, git can recover from a corrupted index file with `rm .git/index; git reset --mixed`.
+
+Of course, you lose any staged changes that were in the old index file, and may need to re-stage some files.
+"""]]
diff --git a/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_4_4b7e8f9521d61900d9ad418e74808ffb._comment b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_4_4b7e8f9521d61900d9ad418e74808ffb._comment
new file mode 100644
index 0000000000..ec0f88d13c
--- /dev/null
+++ b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_4_4b7e8f9521d61900d9ad418e74808ffb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 4"
+ date="2011-04-03T09:03:22Z"
+ content="""
+Thanks a lot. I tried various howtos around the net, but none of them worked; yours did. (I tried it in one of the copies of the broken repo which I keep around for obvious reasons).
+"""]]
diff --git a/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_5_7abbbe7db3988a2d239d11b0a4c597e7._comment b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_5_7abbbe7db3988a2d239d11b0a4c597e7._comment
new file mode 100644
index 0000000000..651fc81448
--- /dev/null
+++ b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_5_7abbbe7db3988a2d239d11b0a4c597e7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="stoile"
+ ip="2a01:198:242:0:219:66ff:fef2:c021"
+ subject="Error with .git/annex as a symlink"
+ date="2013-11-16T12:20:58Z"
+ content="""
+I had my git annex directory on a ssd and .git/annex on a hdd (using a symlink). I got errors when adding files because a move failed. I forgot to copy the error message. When I had .git/annex/objects on a hdd, everything worked as expected, there were no problems.
+
+So what exactly will go wrong if I only have this one subdirectory on another filesystem?
+"""]]
diff --git a/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_6_46bd45fdc25d9c583f4ebe3a9730ab9f._comment b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_6_46bd45fdc25d9c583f4ebe3a9730ab9f._comment
new file mode 100644
index 0000000000..0c0e3e4957
--- /dev/null
+++ b/doc/forum/performance_improvement__58___git_on_ssd__44___annex_on_spindle_disk/comment_6_46bd45fdc25d9c583f4ebe3a9730ab9f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="stoile"
+ ip="2a01:198:242:0:219:66ff:fef2:c021"
+ subject="Bug report answering my question"
+ date="2013-11-17T10:28:40Z"
+ content="""
+My question was answered in <http://git-annex.branchable.com/bugs/not_possible_to_have_annex_on_a_separate_filesystem/>.
+"""]]
diff --git a/doc/forum/pgp_issue_in_log_file_after_upgrade_to_5.20140517.mdwn b/doc/forum/pgp_issue_in_log_file_after_upgrade_to_5.20140517.mdwn
new file mode 100644
index 0000000000..0d226d5df8
--- /dev/null
+++ b/doc/forum/pgp_issue_in_log_file_after_upgrade_to_5.20140517.mdwn
@@ -0,0 +1,13 @@
+    [2014-05-18 22:38:21 SAST] main: starting assistant version 5.20140517-g0aed6d9
+    Already up-to-date.
+    
+    (scanning...) [2014-05-18 22:38:22 SAST] Watcher: Performing startup scan
+    gpg: WARNING: unsafe permissions on homedir `/var/folders/m6/zkd11n111m38ff37zbtgq0lr0000gp/T/git-annex-gpg.tmp.0'
+    gpg: keyring `/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg' created
+    gpg: Signature made Sun May 18 04:16:11 2014 SAST using DSA key ID XXXXXXXX
+    gpg: Can't check signature: public key not found
+    (started...) 
+
+And still facing:
+
+    git-annex-remote-skydrive is not installed in PATH (/Applications/git-annex.app/Contents/MacOS/bundle:/Applications/git-annex.app/Contents/MacOS/bundle:/usr/bin:/bin:/usr/sbin:/sbin)
diff --git a/doc/forum/pgp_issue_in_log_file_after_upgrade_to_5.20140517/comment_1_807d7da99f732f2fa5f9d3cb1ba9f1a1._comment b/doc/forum/pgp_issue_in_log_file_after_upgrade_to_5.20140517/comment_1_807d7da99f732f2fa5f9d3cb1ba9f1a1._comment
new file mode 100644
index 0000000000..0cd6a21d98
--- /dev/null
+++ b/doc/forum/pgp_issue_in_log_file_after_upgrade_to_5.20140517/comment_1_807d7da99f732f2fa5f9d3cb1ba9f1a1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="comment 1"
+ date="2014-06-21T13:07:51Z"
+ content="""
+What exactly are safe permissions?
+"""]]
diff --git a/doc/forum/pgp_issue_in_log_file_after_upgrade_to_5.20140517/comment_2_92a7509fc42ab2347d57f080081d14b5._comment b/doc/forum/pgp_issue_in_log_file_after_upgrade_to_5.20140517/comment_2_92a7509fc42ab2347d57f080081d14b5._comment
new file mode 100644
index 0000000000..4767ae75bb
--- /dev/null
+++ b/doc/forum/pgp_issue_in_log_file_after_upgrade_to_5.20140517/comment_2_92a7509fc42ab2347d57f080081d14b5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 2"
+ date="2014-07-03T19:49:03Z"
+ content="""
+That error message seems to occur when git-annex is trying to upgrade itself to a newer version, but for some reason the temporary directory it uses for gpg allows some other user to write to it. Perhaps because of a wacky umask, I don't know. AFAICS it's only a warning and the upgrade still works, but I have made git-annex force a sane umask when creating this temp directory.
+"""]]
diff --git a/doc/forum/possible_gpg_issue.mdwn b/doc/forum/possible_gpg_issue.mdwn
new file mode 100644
index 0000000000..5a3d9390b7
--- /dev/null
+++ b/doc/forum/possible_gpg_issue.mdwn
@@ -0,0 +1,28 @@
+Hi,
+
+I'm having an issue and not sure if it's to do with git-annex or something external. I'm on Ubuntu 14.04, and have been using git-annex for several months without this issue, but it suddenly started (possibly) after several packages were updated via apt-get upgrade.
+
+We have two remotes configured, one is a local (LAN) smb share, the other is on Amazon S3. We're using shared encryption on the S3 remote, and no encryption on the smb remote.
+
+The problem that started happening recently is when copying to the smb remote. There is no problem copying from the remote, and no problem reading or writing to the drive outside of git-annex. However, copying to the remote fails after it seems to copy most or all of the file and then hang on a gpg step. Again, there is no encryption on this remote. The other S3 remote with shared encryption has no issues. Other devices on the LAN, all OS X, have no issues writing to the remote.
+
+I don't have enough info to necessarily claim this is a bug in git-annex, but I'm not sure what to poke at next to try to figure it out. Any help or advice would be greatly appreciated.
+
+Below is the debug output from a failed git annex copy command.
+
+    cw@ubuntu$ git annex copy annexedfile --to smbremote --debug
+    [2014-11-07 15:35:13 PST] read: git ["--git-dir=/repobase/.git","--work-tree=/repobase","show-ref","git-annex"]
+    [2014-11-07 15:35:13 PST] read: git ["--git-dir=/repobase/.git","--work-tree=/repobase","show-ref","--hash","refs/heads/git-annex"]
+    [2014-11-07 15:35:13 PST] read: git ["--git-dir=/repobase/.git","--work-tree=/repobase","log","refs/heads/git-annex..aa8813d486939544701359dc28fa7b0916917961","--oneline","-n1"]
+    [2014-11-07 15:35:13 PST] read: git ["--git-dir=/repobase/.git","--work-tree=/repobase","log","refs/heads/git-annex..097d5b482d6856ce22814a0c2c5eee43e3e030e4","--oneline","-n1"]
+    [2014-11-07 15:35:13 PST] chat: git ["--git-dir=/repobase/.git","--work-tree=/repobase","cat-file","--batch"]
+    [2014-11-07 15:35:13 PST] read: git ["--git-dir=/repobase/.git","--work-tree=/repobase","ls-files","--cached","-z","--","annexedfile"]
+    copy annexedfile (gpg) (to smbremote...) 
+    [2014-11-07 15:35:13 PST] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","11","--symmetric","--force-mdc","--no-textmode"]
+    95%           0.0 B/s 0s/mnt/annex/tmp/GPGHMACSHA1--a097a9b653d1facbe7d37d0e8f9f580261d9adef/GPGHMACSHA1--a097a9b653d1facbe7d37d0e8f9f580261d9adef: hClose: does not exist (Host is down)
+    failed                  
+    git-annex: copy: 1 failed
+    cw@ubuntu$
+
+Thanks,
+cw
diff --git a/doc/forum/possible_gpg_issue/comment_1_c5a33ff375cddd001e6cb7be8d0ce940._comment b/doc/forum/possible_gpg_issue/comment_1_c5a33ff375cddd001e6cb7be8d0ce940._comment
new file mode 100644
index 0000000000..9c43e38a70
--- /dev/null
+++ b/doc/forum/possible_gpg_issue/comment_1_c5a33ff375cddd001e6cb7be8d0ce940._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica Semrick"
+ subject="is your samba share mounted?"
+ date="2014-11-10T05:08:39Z"
+ content="""
+You should make sure your samba share is mounted and you can read/write to it.
+"""]]
diff --git a/doc/forum/possible_gpg_issue/comment_2_e5ea7fc9be496f71516a238522193744._comment b/doc/forum/possible_gpg_issue/comment_2_e5ea7fc9be496f71516a238522193744._comment
new file mode 100644
index 0000000000..ffc69036da
--- /dev/null
+++ b/doc/forum/possible_gpg_issue/comment_2_e5ea7fc9be496f71516a238522193744._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawknHkJJRE0K7_G4sG3YgOkAaihnw0eg9Ao"
+ nickname="Chad"
+ subject="comment 2"
+ date="2014-11-10T18:06:11Z"
+ content="""
+Yes, the drive is mounted rw for all users with no username or password required to connect. There is no problem copying from the drive, and no problem reading or writing to it outside of git-annex.
+"""]]
diff --git a/doc/forum/possible_gpg_issue/comment_3_d505b6e5050d2afa7c8543e21918193d._comment b/doc/forum/possible_gpg_issue/comment_3_d505b6e5050d2afa7c8543e21918193d._comment
new file mode 100644
index 0000000000..ade7846db2
--- /dev/null
+++ b/doc/forum/possible_gpg_issue/comment_3_d505b6e5050d2afa7c8543e21918193d._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2014-12-01T21:36:40Z"
+ content="""
+The relevant error message seems to be this:
+
+	hClose: does not exist (Host is down)
+
+Which doesn't point at gpg being the problem to me. git-annex is trying to
+close a file after writing it, and that's failing with EHOSTDOWN. Not a usual
+error code, but then you're using a network filesystem, which has many unusual
+failure modes.
+
+The next step would probably be to strace git-annex to see what syscall
+is failing. Looks like it might be close(2), but then again hClose might be
+doing something else first.
+
+It's possible that this has something to do with the SMB share not supporting
+some POSIX filesystem feature that git-annex uses. Lack of support for fcntl
+locking is a problem with NFS, dunno about SMB.
+
+What would probably work better would be to set up a
+[[directory special remote|special_remotes/directory]] on the SMB share.
+That requires a lot less from the filesystem than a full-fledged git remote
+does.
+
+(Two parts of what you said don't make sense to me BTS. I see no evidence of it hanging in the transcript, so am unclear why
+you said it was hanging, as opposed to gracefully failing. And, you said the SMB remote was not configured to use encryption, but it's clearly
+encrypted in the transcript.)
+"""]]
diff --git a/doc/forum/possible_gpg_issue/comment_4_e52099d461d0df99040f664a3af23caf._comment b/doc/forum/possible_gpg_issue/comment_4_e52099d461d0df99040f664a3af23caf._comment
new file mode 100644
index 0000000000..a2e7bd6315
--- /dev/null
+++ b/doc/forum/possible_gpg_issue/comment_4_e52099d461d0df99040f664a3af23caf._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawknHkJJRE0K7_G4sG3YgOkAaihnw0eg9Ao"
+ nickname="Chad"
+ subject="comment 4"
+ date="2014-12-02T22:51:24Z"
+ content="""
+Thanks so much. I'll try digging some more into the syscalls and see what I can figure out. We do have it set up as a directory remote.
+
+To clarify, when I said it was \"hanging\" maybe that wasn't a good word choice. What I meant was that it very quickly gets to 95% or 100% progress, then freezes and does nothing for a while, before ultimately reporting the error and exiting.
+
+Also I take back what I said about it not using encryption. It is. I was confused by the fact that there are unencrypted files on the disk, but it turns out they are all from a long time ago, perhaps before we started using encryption. Everything more recent is encrypted.
+
+Thanks!
+-c
+
+
+"""]]
diff --git a/doc/forum/possible_gpg_issue/comment_5_a0c8afc2d8583d30073b62396b254a6e._comment b/doc/forum/possible_gpg_issue/comment_5_a0c8afc2d8583d30073b62396b254a6e._comment
new file mode 100644
index 0000000000..7011e7fd5c
--- /dev/null
+++ b/doc/forum/possible_gpg_issue/comment_5_a0c8afc2d8583d30073b62396b254a6e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawknHkJJRE0K7_G4sG3YgOkAaihnw0eg9Ao"
+ nickname="Chad"
+ subject="comment 5"
+ date="2014-12-03T01:05:17Z"
+ content="""
+Yeah, it's close returning the error. As far as I can tell the calls involving that file are:
+
+    open(path, O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = fh
+    fstat(fh, {st_mode=S_IFREG|0755, st_size=sz, ...}) = 0
+    ftruncate(fh, 0) = 0
+    ioctl(fh, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, ptr) = -1 ENOTTY (Inappropriate ioctl for device)
+    write(fh, data, len) x 60
+    close(fh) = -1 EHOSTDOWN (Host is down)
+
+All the calls to write appear to succeed, followed by the call to close that fails. Maybe the previously failed ioctl command has something to do with it? I guess as was mentioned previously, there may be an operation the device doesn't support, but the weird thing is this used to work fine.
+"""]]
diff --git a/doc/forum/possible_gpg_issue/comment_6_2a0120d6b586594cfd9baabbd6605373._comment b/doc/forum/possible_gpg_issue/comment_6_2a0120d6b586594cfd9baabbd6605373._comment
new file mode 100644
index 0000000000..84c9c5b4fe
--- /dev/null
+++ b/doc/forum/possible_gpg_issue/comment_6_2a0120d6b586594cfd9baabbd6605373._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2015-02-09T18:41:23Z"
+ content="""
+Sorry about the delay getting back to this.. It's great you were able
+to provide the strace.
+
+I don't think that the ioctl is at fault. That seems to be something
+that's done by the IO layer when opening a handle. It does not involve
+locking.
+
+Looks to me like the writes get buffered and it fails to flush to the SMB
+server on close.
+"""]]
diff --git a/doc/forum/possible_gpg_issue/comment_7_f095eadcd9f6947f64e6830acea8228e._comment b/doc/forum/possible_gpg_issue/comment_7_f095eadcd9f6947f64e6830acea8228e._comment
new file mode 100644
index 0000000000..c262c9b524
--- /dev/null
+++ b/doc/forum/possible_gpg_issue/comment_7_f095eadcd9f6947f64e6830acea8228e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="ka7"
+ subject="comment 7"
+ date="2015-05-05T16:58:42Z"
+ content="""
+is on the \"SMB share\" running something special ? ..like virus-scanner, quota, backup-in-progress
+
+and.. smb like SAMBA or Windows ?
+
+in theory you can do lots of funny stuff to get a smb share: sharing a samba which is a webdav mounted via nfs on a clamFS. (*scary*)
+"""]]
diff --git a/doc/forum/post-copy__47__sync_hook.mdwn b/doc/forum/post-copy__47__sync_hook.mdwn
new file mode 100644
index 0000000000..05fbc0b291
--- /dev/null
+++ b/doc/forum/post-copy__47__sync_hook.mdwn
@@ -0,0 +1,14 @@
+Hi,
+
+I have the following setup:
+- normal git repository with website code.
+- git annex repository to hold large set of binary data (pdfs, flashmovies, etc) that belongs to the site.
+
+I use git annex so I (and other developers) don't need to copy 1.4Gb+ of binary data for every working copy. (Data that is mostly left untouched.) Using git annex copy --to=origin I can simply only add new additions to this media/binary repository, without first pulling all the data. So far so good.
+
+When commits are pushed to a certain branch on the normal git repository, a post-receive hook exports (GIT_WORK_TREE=/data/site/ git checkout $branch -f) the updated repository to an apache documentroot. Thereby updating the staging server of the website.
+
+My question is, how can I do the same thing for my git annex repository? Since post-receive fires on receiving the annex hashes, and not the actual files. Those are rsynced, and I cannot find a way to trigger an action after all files are copied by git annex via rsync.
+
+Any tips?
+
diff --git a/doc/forum/post-copy__47__sync_hook/comment_1_c8322d4b9bbf5eac80b48c312a42fbcf._comment b/doc/forum/post-copy__47__sync_hook/comment_1_c8322d4b9bbf5eac80b48c312a42fbcf._comment
new file mode 100644
index 0000000000..04a6f4668e
--- /dev/null
+++ b/doc/forum/post-copy__47__sync_hook/comment_1_c8322d4b9bbf5eac80b48c312a42fbcf._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-03-14T16:23:25Z"
+ content="""
+I've made git-annex-shell run the git `hooks/annex-content` after content is received or dropped. 
+
+Note that the clients need to be running at least git-annex version 3.20120227 , which runs git-annex-shell commit, which runs the hook.
+
+"""]]
diff --git a/doc/forum/pre-commit_hook_to_use_git_annex_for_only_large_files.mdwn b/doc/forum/pre-commit_hook_to_use_git_annex_for_only_large_files.mdwn
new file mode 100644
index 0000000000..2a8135d992
--- /dev/null
+++ b/doc/forum/pre-commit_hook_to_use_git_annex_for_only_large_files.mdwn
@@ -0,0 +1,55 @@
+I've wanted to use git-annex for the longest time, but I really only wanted to use it if the files were over a certain size, otherwise, I just want to use regular git.
+
+After writing this pre-commit hook, I wanted to share and get some feedback.
+
+This would be saved as `.git/hooks/pre-commit`
+
+    #!/bin/sh
+    let MAX=1*1024*1024  # 1048576 == 1 MB
+    if [ ! -d '.git/annex/' ]; then
+      /usr/local/bin/git annex init >/dev/null 2>&1
+    fi
+    if git rev-parse --verify HEAD >/dev/null 2>&1; then
+      against=HEAD
+    else
+      # Initial commit: diff against an empty tree object
+      against=$(/usr/local/bin/git hash-object -t tree /dev/null)
+    fi
+    /usr/local/bin/git diff-index --cached $against | \
+      /usr/bin/tr '\t' ' ' | \
+      /usr/bin/cut -d ' ' -f4,6- | \
+      while read line; do
+        sha1=$(/usr/bin/cut -d ' ' -f1 <<< "$line")
+        if [ "$sha1" == "0000000000000000000000000000000000000000" ]; then
+          continue
+        fi
+        size=$(/usr/local/bin/git cat-file -s "$sha1")
+        if [ $size -ge $MAX ]; then
+          file=$(/usr/bin/cut -d ' ' -f2- <<< "$line")
+          /usr/local/bin/git update-index --force-remove "$file"
+          /usr/local/bin/git annex add "$file"
+          /usr/bin/killall -TERM Finder
+        fi
+    done
+    /usr/local/bin/git annex pre-commit .
+
+I also wrote an `Unlock Git Annex File.workflow` service for OS X:
+
+    set gitAnnex to "/Applications/git-annex.app/Contents/MacOS/git-annex"
+
+    tell application "Finder"
+            repeat with theItem in (get selection)
+                    if file type of theItem is "slnk" then
+                            set theFolder to quoted form of POSIX path of (container of theItem as alias)
+                            set filePath to do shell script "/usr/bin/basename " & quoted form of POSIX path of (theItem as text)
+                            set theCommand to "cd " & theFolder & "; " & gitAnnex & " unlock '" & filePath & "'"
+                            do shell script theCommand
+                    end if
+            end repeat
+    end tell
+
+Use Automator to create a new service that receives selected "files or folders" in "Finder.app". Then drag the "Run AppleScript" action to the workflow panel. The script above should be copied into the code area replacing all the default content.
+
+Am I all alone in wanting these types of scripts?
+
+- Peter
diff --git a/doc/forum/pre-commit_hook_to_use_git_annex_for_only_large_files/comment_1_01db183b1f1d081066d88332e2b6166a._comment b/doc/forum/pre-commit_hook_to_use_git_annex_for_only_large_files/comment_1_01db183b1f1d081066d88332e2b6166a._comment
new file mode 100644
index 0000000000..98618cd518
--- /dev/null
+++ b/doc/forum/pre-commit_hook_to_use_git_annex_for_only_large_files/comment_1_01db183b1f1d081066d88332e2b6166a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-05T18:46:42Z"
+ content="""
+The problem with this pre-commit hook is that by the time you run `git add
+largfile`, it has copied it into the git repository. Your hook will prevent
+it getting into a commit, so the repository will eventually garbage collect
+the copy away, but this can take some time or manual work to do.
+
+Recent versions of `git-annex add` will look at the annex.largefiles
+configuration and if the file does not match, add it to git directly.
+So that's an alternate workflow, where you `git annex add` files and let
+git-annex decide whether to put them in the annex or the git repository.
+"""]]
diff --git a/doc/forum/pre-commit_hook_to_use_git_annex_for_only_large_files/comment_2_2b76809869e0289f78f137afbdcf36c8._comment b/doc/forum/pre-commit_hook_to_use_git_annex_for_only_large_files/comment_2_2b76809869e0289f78f137afbdcf36c8._comment
new file mode 100644
index 0000000000..7ed0c5768e
--- /dev/null
+++ b/doc/forum/pre-commit_hook_to_use_git_annex_for_only_large_files/comment_2_2b76809869e0289f78f137afbdcf36c8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-05-05T18:56:33Z"
+ content="""
+For the Finder script, there's a page collecting such stuff,
+[[tips/file_manager_integration]]
+"""]]
diff --git a/doc/forum/preferred_content.mdwn b/doc/forum/preferred_content.mdwn
new file mode 100644
index 0000000000..b4c215328d
--- /dev/null
+++ b/doc/forum/preferred_content.mdwn
@@ -0,0 +1,11 @@
+Hello all,
+
+I'm trying to use "preferred content" with git-annex but I suspect that my version doesn't provide it.
+
+I'm using Debian "wheezy" that packs git-annex 3.20120629.
+
+I appreciate any help you can give.
+
+Thanks.
+
+Zaka.
diff --git a/doc/forum/preferred_content/comment_1_9c9e5f2ee5ae4d8459358ad16f879ef1._comment b/doc/forum/preferred_content/comment_1_9c9e5f2ee5ae4d8459358ad16f879ef1._comment
new file mode 100644
index 0000000000..24de5840b3
--- /dev/null
+++ b/doc/forum/preferred_content/comment_1_9c9e5f2ee5ae4d8459358ad16f879ef1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-07T18:38:22Z"
+ content="""
+The first version of git-annex to support preferred content settings was 3.20121009.
+
+There is a quite up-to-date backport available for Debian stable.
+"""]]
diff --git a/doc/forum/preferred_content_globs_question.mdwn b/doc/forum/preferred_content_globs_question.mdwn
new file mode 100644
index 0000000000..08304d1a59
--- /dev/null
+++ b/doc/forum/preferred_content_globs_question.mdwn
@@ -0,0 +1 @@
+The manpage for [[git-annex-preferred-content]] says "While --include=glob and --exclude=glob match files relative to the current directory, preferred content expressions match files relative to the top of the git repository".  Is the "While..." part referring to [[git-annex-matching-options]], as contrasted with [[git-annex-preferred-content]]?
diff --git a/doc/forum/preferred_content_globs_question/comment_1_de4212f2e70fde49063b45b33498ade7._comment b/doc/forum/preferred_content_globs_question/comment_1_de4212f2e70fde49063b45b33498ade7._comment
new file mode 100644
index 0000000000..125bfeae48
--- /dev/null
+++ b/doc/forum/preferred_content_globs_question/comment_1_de4212f2e70fde49063b45b33498ade7._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-07-19T17:24:35Z"
+ content="""
+Yes, --include and --exclude are the command-line options.
+"""]]
diff --git a/doc/forum/preferred_content_settings_for_multiple_symlinks.mdwn b/doc/forum/preferred_content_settings_for_multiple_symlinks.mdwn
new file mode 100644
index 0000000000..3c67a93a5f
--- /dev/null
+++ b/doc/forum/preferred_content_settings_for_multiple_symlinks.mdwn
@@ -0,0 +1,7 @@
+I have my music library in `music/` and some really old files I recently added in `reallyold/`.  There are some MP3s in the really old files and some are the same as my library, so of course git annex is only keeping one copy.  Now, I have an rsync remote, `ma`, which prefers content from `music/` but doesn't want anything from `reallyold/`.  So while right now it is trying to drop stuff, I suspect at some point that it will try to re-add them in virtue of being in `music/`, as I've got a loop.
+
+I want to eliminate this by using the present keyword to disable dropping for stuff in `reallyold/` and `music/`.  Here is my attempt, which doesn't work--I am hoping someone can spot what's wrong.
+
+    (present and include=music/*) or (present and include=reallyold/*) or (exclude=reallyold/* and exclude=video/* and exclude= ...)
+
+Note that music is included by virtue of not being excluded so it should satisfy the third disjunct.  Thanks.
diff --git a/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_1_70da012d96ab576151fe3e081ef905d1._comment b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_1_70da012d96ab576151fe3e081ef905d1._comment
new file mode 100644
index 0000000000..b5fbd345eb
--- /dev/null
+++ b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_1_70da012d96ab576151fe3e081ef905d1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.210"
+ subject="Ever figure this out?"
+ date="2013-02-24T22:00:40Z"
+ content="""
+I find it's useful, when stuck on this kind of thing, to run `git annex find` at the command line passing it parts of the expression and making sure it works, and gradually building up to the complete expression.
+
+You have to do some conversion due to differences between command line and preferred content expression format. For example `git annex find -\( --in here --and --include \"music/*\" -\)`
+"""]]
diff --git a/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_2_ccea74d8b5a4de1f3cd1f6da6694ae0e._comment b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_2_ccea74d8b5a4de1f3cd1f6da6694ae0e._comment
new file mode 100644
index 0000000000..09b9d8564f
--- /dev/null
+++ b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_2_ccea74d8b5a4de1f3cd1f6da6694ae0e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="82.36.235.9"
+ subject="comment 2"
+ date="2013-03-12T09:34:08Z"
+ content="""
+Thanks for the tip--I will definitely make another attempt at some point.
+"""]]
diff --git a/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_3_fab70c642d5aaf26de05270860281030._comment b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_3_fab70c642d5aaf26de05270860281030._comment
new file mode 100644
index 0000000000..12c49a89c7
--- /dev/null
+++ b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_3_fab70c642d5aaf26de05270860281030._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="82.36.235.9"
+ subject="Impossible?"
+ date="2013-06-24T17:48:02Z"
+ content="""
+I have now investigated this further and believe that what I am trying to do is impossible.  Suppose we have a file `song.mp3` in both `music/` and `old/` and the special remote's preferred content expression is set-up to prefer `music/` and not to prefer `old/`.  So initially, git-annex won't try to upload the content when it scans `old/song.mp3`, but it will when it scans `music/song.mp3`.  Fine.  Now consider a later scan.  On scanning the filename `music/song.mp3` git-annex will suppose the file was dropped from the remote, and then see it would be preferred again so won't drop it.  But then when it gets to scanning the filename `old/song.mp3` it will see that it wouldn't be preferred and will drop the content.  So we get the loop.
+
+In order to stop the unwanted drop here, the preferred content expression must prefer \"files in old/* that is also in music/*\" but since preferred content expressions concern filenames without reference to their contents, this is impossible to express.  The expression `include=music/* and include=old/*` will never match anything.
+"""]]
diff --git a/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_4_3cbd06de53b6a13e2741124a8e7b5b5b._comment b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_4_3cbd06de53b6a13e2741124a8e7b5b5b._comment
new file mode 100644
index 0000000000..1868e9736a
--- /dev/null
+++ b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_4_3cbd06de53b6a13e2741124a8e7b5b5b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 4"
+ date="2013-06-25T17:22:53Z"
+ content="""
+spwhitton, your analysis is correct -- except this problem was finessed in git-annex version 4.20130621. Now, when using direct mode, it knows that `old/song.mp3` is also `music/song.mp3`, and so it only drops it if the preferred content expression allows dropping both files.
+
+Still doesn't work in indirect mode, and I think not likely to in the forseeable future. See [[bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time]]
+"""]]
diff --git a/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_5_963558ab261d8a6315402d371e8348f9._comment b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_5_963558ab261d8a6315402d371e8348f9._comment
new file mode 100644
index 0000000000..f7ae3216a4
--- /dev/null
+++ b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_5_963558ab261d8a6315402d371e8348f9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="82.36.235.9"
+ subject="comment 5"
+ date="2013-06-25T19:47:19Z"
+ content="""
+I assume you mean that if I use direct mode locally, it will get things right.  I didn't think a special remote could ever be in direct mode.
+
+Thank you for the info.  I don't want to lose the safeguards of indirect mode just for this, so I'll stick with my inelegant manual preferred content strings for now.
+"""]]
diff --git a/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_6_23279af1d49d22e880d078c59f58c492._comment b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_6_23279af1d49d22e880d078c59f58c492._comment
new file mode 100644
index 0000000000..f914959961
--- /dev/null
+++ b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_6_23279af1d49d22e880d078c59f58c492._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-07-15T17:04:59Z"
+ content="""
+This did finally get fixed, in version 8.20210621.
+"""]]
diff --git a/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_7_73bf2c6dfa71cdb10b36c5cda2d2dc11._comment b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_7_73bf2c6dfa71cdb10b36c5cda2d2dc11._comment
new file mode 100644
index 0000000000..834bb5401c
--- /dev/null
+++ b/doc/forum/preferred_content_settings_for_multiple_symlinks/comment_7_73bf2c6dfa71cdb10b36c5cda2d2dc11._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 7"
+ date="2021-08-03T19:10:10Z"
+ content="""
+Very cool :)
+"""]]
diff --git a/doc/forum/problem_with_non-ascii_filenames.mdwn b/doc/forum/problem_with_non-ascii_filenames.mdwn
new file mode 100644
index 0000000000..64885c1f28
--- /dev/null
+++ b/doc/forum/problem_with_non-ascii_filenames.mdwn
@@ -0,0 +1,5 @@
+git-annex add . fails with:
+
+ git-annex: unknown response from git cat-file ("HEAD:./MYDIRECTORYNAME/Icon missing","HEAD:./MYDIRECTORYNAME/Icon\r")
+
+There's a file in the directory called Icon^M or Icon? (there's some kind of control character or unicode or other weirdness at the end)
diff --git a/doc/forum/problem_with_non-ascii_filenames/comment_1_ad7e7d7ef4b25ef59f93246dab0e3048._comment b/doc/forum/problem_with_non-ascii_filenames/comment_1_ad7e7d7ef4b25ef59f93246dab0e3048._comment
new file mode 100644
index 0000000000..6ad8fca7bd
--- /dev/null
+++ b/doc/forum/problem_with_non-ascii_filenames/comment_1_ad7e7d7ef4b25ef59f93246dab0e3048._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-09-18T16:48:06Z"
+ content="""
+It looks like you had a newline in your filename. Which is very unusual.
+
+git-annex actually got support for those in version 6.20180913.
+"""]]
diff --git a/doc/forum/public-web-frontend.mdwn b/doc/forum/public-web-frontend.mdwn
new file mode 100644
index 0000000000..d3fdb9b94a
--- /dev/null
+++ b/doc/forum/public-web-frontend.mdwn
@@ -0,0 +1,16 @@
+Hi,
+
+Use case: I would like to have a "Public" top-level directory in my annex, which gets files in there published over HTTP on a particular server.
+
+How I see doing this:
+
+1. Put my annex to an http server with exported-over-http `/Public/` directory.
+2. Configure a `post-update` hook with the following:
+
+        $ git annex fix
+
+3. Push files on `/Public/` to that annex.
+
+Does it make sense? If yes, are there any gotchas I should beware of?
+
+Thanks.
diff --git a/doc/forum/public-web-frontend/comment_1_c73bd2dfe020c25eaad1c0707dd2db01._comment b/doc/forum/public-web-frontend/comment_1_c73bd2dfe020c25eaad1c0707dd2db01._comment
new file mode 100644
index 0000000000..b9f6c98676
--- /dev/null
+++ b/doc/forum/public-web-frontend/comment_1_c73bd2dfe020c25eaad1c0707dd2db01._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="should work.."
+ date="2012-08-05T17:18:47Z"
+ content="""
+I see no need for `git annex fix` here.
+
+Web server default configurations may not allow following symlinks outside the web server document root. On apache, it can be enabled with `Options FollowSymLinks`
+"""]]
diff --git a/doc/forum/public-web-frontend/comment_2_0026d7be6b17e50d86b3b54985882f80._comment b/doc/forum/public-web-frontend/comment_2_0026d7be6b17e50d86b3b54985882f80._comment
new file mode 100644
index 0000000000..bfb60ede1e
--- /dev/null
+++ b/doc/forum/public-web-frontend/comment_2_0026d7be6b17e50d86b3b54985882f80._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmdLmVxigDvxiGhnQ34xhyAaxl0CRRe9gs"
+ nickname="Bryan"
+ subject="Alternate version - smarter integration with other remotes/web special remote?"
+ date="2013-03-03T14:19:12Z"
+ content="""
+I love the idea of pushing files to \"visible\" using annex, but I'm wondering how difficult to would be to make this even fancier.
+
+For instance, if there are files that were originally imported from the web special remote (and have http:// prefixes, since that's not guaranteed), and they're not actually in the pushed annex, generate a redirect for all of them and write a special remote-local .htaccess file.
+
+Or, similarly, allow each remote to have some metadata which specifies what, if any, the URL prefix for a directory in annex is. Then, whenever you update a web remote, the auto-generated redirects list could contain not only files not present but with web-remote locations, but also other remotes which have the file under a web-visible path prefix. Bonus for allowing URL prefixes for S3-style remotes that are not encrypted.
+
+My use case for this sort of fancy is that I have a large server with gobs of space but on a personal (slower) internet connection, and a much smaller hosted instance with much faster bandwidth. With this smarts, I could push and pull large/expected high traffic files to the higher bandwidth/smaller machine ahead of, say, announcing a new feature or sharing a link to a video via e-mail.. or even reactively if the lower-bandwidth server is getting overwhelmed. 
+"""]]
diff --git a/doc/forum/public__44___read_only_annex_without_location_tracking.mdwn b/doc/forum/public__44___read_only_annex_without_location_tracking.mdwn
new file mode 100644
index 0000000000..88f8b21c2c
--- /dev/null
+++ b/doc/forum/public__44___read_only_annex_without_location_tracking.mdwn
@@ -0,0 +1,7 @@
+I would like to use a public, read only annex to publish photos. I have a server, running gitolite, with git-annex setup, which I use successfully to sync content between my own devices.
+
+But, with a public annex, I would like the view of the repository available from the server to be that only the server has the content, and not to have, or give out any of the location tracking information about any other annexes?
+
+A more concrete example would be, how do I get a photo in to git annex locally, and then push this to the server for public access, without publishing information about my local repository?
+
+From the public annexes I have looked at, this does not appear to be done. So I am unsure if this is even possible, however it seems a desirable thing to do?
diff --git a/doc/forum/public__44___read_only_annex_without_location_tracking/comment_1_47262f048a87fd6b781090f880a9bf99._comment b/doc/forum/public__44___read_only_annex_without_location_tracking/comment_1_47262f048a87fd6b781090f880a9bf99._comment
new file mode 100644
index 0000000000..99ed6f25a7
--- /dev/null
+++ b/doc/forum/public__44___read_only_annex_without_location_tracking/comment_1_47262f048a87fd6b781090f880a9bf99._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 1"
+ date="2014-07-03T19:35:21Z"
+ content="""
+There's not a way to do it yet.
+
+The fundamental problem is that there is a variety of information stored on the git-annex branch, including location tracking information that you don't want (locations on non-public repositories), location tracking information you do want (locations on public repositories), urls, metadata, repository configurations and descriptions (some for public and some for non-public repositories). It seems fairly hard to draw a line. And once a line is drawn, there would be two diverged git-annex branches on the public and private repos, and the private repo would need to synthesize an updated version of the public branch every time it synced.
+
+Instead, the last time this came up, I added the remote.<name>.annex-readonly setting. This allows for at least having a private repository (or a whole network of repositories that all communicate together but remain private) that pulls changes from a public repo, but avoids making changes to it. Certainly not a complete solution, since changes have to be contributed to the public repo in some out-of-band way, like perhaps using git-format-patch and git-am.
+"""]]
diff --git a/doc/forum/public__44___read_only_annex_without_location_tracking/comment_2_ec3ff6487c9e5c89c7e508d72518bd50._comment b/doc/forum/public__44___read_only_annex_without_location_tracking/comment_2_ec3ff6487c9e5c89c7e508d72518bd50._comment
new file mode 100644
index 0000000000..ad74e68660
--- /dev/null
+++ b/doc/forum/public__44___read_only_annex_without_location_tracking/comment_2_ec3ff6487c9e5c89c7e508d72518bd50._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="cbaines"
+ ip="82.19.50.118"
+ subject="comment 2"
+ date="2014-07-03T20:13:20Z"
+ content="""
+Thanks for your response.
+
+The method you describe sounds like it might just do. I'll have a try, and see if it works out :)
+"""]]
diff --git a/doc/forum/pulling_from_encrypted_remote.mdwn b/doc/forum/pulling_from_encrypted_remote.mdwn
new file mode 100644
index 0000000000..e9486b597d
--- /dev/null
+++ b/doc/forum/pulling_from_encrypted_remote.mdwn
@@ -0,0 +1,12 @@
+Is there a way to pull from an encrypted remote?
+
+Use case:
+
+1. Have annex in an encrypted public rsync remote
+2. Have USB stick with PGP keys (but not the annex repository)
+3. Get to a new computer
+4. Set up a new annex using the PGP keys I have.
+
+1-3 work fine :) However, 4'th is the issue:
+
+How would I do `git pull <remote>` for an encrypted remote? Is it possible?
diff --git a/doc/forum/pulling_from_encrypted_remote/comment_1_e9d6a9a6e01d01edb41a11b0da11d74d._comment b/doc/forum/pulling_from_encrypted_remote/comment_1_e9d6a9a6e01d01edb41a11b0da11d74d._comment
new file mode 100644
index 0000000000..2da698f4a9
--- /dev/null
+++ b/doc/forum/pulling_from_encrypted_remote/comment_1_e9d6a9a6e01d01edb41a11b0da11d74d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2012-07-10T18:14:31Z"
+ content="""
+You just need to `git clone` the existing repository and make sure the `git remote`s are setup.
+
+the 'rsync remote' is not actually the annex, it's just a collection of encrypted files with obfuscated names.  You need a copy of the actual repository to restore the files.
+"""]]
diff --git a/doc/forum/pulling_from_encrypted_remote/comment_2_8d0db2ff65ce935c6e68044a3e0721a8._comment b/doc/forum/pulling_from_encrypted_remote/comment_2_8d0db2ff65ce935c6e68044a3e0721a8._comment
new file mode 100644
index 0000000000..8fd73cd92c
--- /dev/null
+++ b/doc/forum/pulling_from_encrypted_remote/comment_2_8d0db2ff65ce935c6e68044a3e0721a8._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="Thats a fair solution"
+ date="2012-07-22T13:51:25Z"
+ content="""
+Until you don't have(access to) an existing repository to clone from.
+
+I really hope you revisit this when you come to the encryption part of the assistant.
+
+Btw, I also run FreeBSD if you need a tester on that at some point.
+
+Sincerely
+Tobias Ussing
+
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow.mdwn b/doc/forum/pure_git-annex_only_workflow.mdwn
new file mode 100644
index 0000000000..36648a9058
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow.mdwn
@@ -0,0 +1,46 @@
+I’m using git annex to manage my movie collection on various devices – my laptop, a NSLU tucked away somewhere with lots of space, some external hard drives. For this use case, I do not need the full power of git as a version control system, so having to run "git commit" and coming up with commit messages is annoying. Also, this makes sense for a version control system, but not for my media collection:
+
+	$ git annex add Hot\ Fuzz\ -\ English.mkv 
+	add Hot Fuzz - English.mkv (checksum...) ok
+	(Recording state in git...)
+	$ git commit -m 'another movie added'
+	[master 851dc8a] another movie added
+	 1 files changed, 1 insertions(+), 0 deletions(-)
+	 create mode 120000 00 Noch nicht gesehen/Hot Fuzz - English.mkv
+	$ git push jeff
+	Counting objects: 38, done.
+	Delta compression using up to 2 threads.
+	Compressing objects: 100% (20/20), done.
+	Writing objects: 100% (26/26), 2.00 KiB, done.
+	Total 26 (delta 11), reused 0 (delta 0)
+	remote: error: refusing to update checked out branch: refs/heads/master
+	remote: error: By default, updating the current branch in a non-bare repository
+	remote: error: is denied, because it will make the index and work tree inconsistent
+	remote: error: with what you pushed, and will require 'git reset --hard' to match
+	remote: error: the work tree to HEAD.
+	remote: error: 
+	remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
+	remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
+	remote: error: its current branch; however, this is not recommended unless you
+	remote: error: arranged to update its work tree to match what you pushed in some
+	remote: error: other way.
+	remote: error: 
+	remote: error: To squelch this message and still keep the default behaviour, set
+	remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
+	To jeff:/mnt/media/Movies
+	 ! [rejected]        git-annex -> git-annex (non-fast-forward)
+	 ! [remote rejected] master -> master (branch is currently checked out)
+	error: failed to push some refs to 'jeff:/mnt/media/Movies'
+	To prevent you from losing history, non-fast-forward updates were rejected
+	Merge the remote changes (e.g. 'git pull') before pushing again.  See the
+	'Note about fast-forwards' section of 'git push --help' for details.
+
+It seems that to successfully make the new files known to the other side, I have to log into jeff and pull _from_ my current machine.	
+
+What I would like to have is that
+
+* git annex add does not require a commit afterwards.
+* Changes to the files are automatically picked up with the next git-annex call (similar to how etckeeper works).
+* Commands "git annex push" and "git annex pull" that will sync the metadata (i.e. the list of files) in both directions without further manual intervention, at least not until the two repositories have diverged in a way that is not possible to merge sensible.
+
+Summay: git-annex is great. git is not always. Please make it possible to use git annex without having to use git.
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_10_683768c9826b0bf0f267e8734b9eb872._comment b/doc/forum/pure_git-annex_only_workflow/comment_10_683768c9826b0bf0f267e8734b9eb872._comment
new file mode 100644
index 0000000000..dc499cbc90
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_10_683768c9826b0bf0f267e8734b9eb872._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="Finally some code"
+ date="2011-12-29T19:58:31Z"
+ content="""
+The repository at http://git.nomeata.de/?p=git-annex.git;a=summary contains changes to Commands/Sync.hs (and to the manpage) that implements this behavior. The functionality should be fine; the progress output is not very nice yet, but I’m not sure if I really understood the various Command types. It also should be more easily discoverable how to activate the behavior (by running \"git branch synced/master\") by providing a helpful message, at least unless git annex init creates the branch by default.
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_11_6b541ed834ef45606f3b98779a25a148._comment b/doc/forum/pure_git-annex_only_workflow/comment_11_6b541ed834ef45606f3b98779a25a148._comment
new file mode 100644
index 0000000000..30932e301f
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_11_6b541ed834ef45606f3b98779a25a148._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 11"
+ date="2011-12-30T21:49:06Z"
+ content="""
+OMG, my first sizable haskell patch!
+
+So trying this out..
+
+In each repo I want to sync, I first `git branch synced/master`
+
+Then in each repo, I found I had to pull from each of its remotes, to get the tracking branches that `defaultSyncRemotes` looks for to know those remotes are syncable. This was the surprising thing for me, I had expected sync to somehow work out which remotes were syncable without my explicit pull. And it was not very obvious that sync was not doing its thing before I did that, since it still does a lot of \"stuff\".
+
+Once set up properly, `git annex sync` fetches from each remote, merges, and then pushes to each remote that has a synced branch. Changes propigate around even when some links are one-directional. Cool!
+
+So it works fine, but I think more needs to be done to make setting up syncing easier. Ideally, all a user would need to do is run \"git annex sync\" and it syncs from all remotes, without needing to manually set up the synced/master branch.
+
+While this would lose the ability to control which remotes are synced, I think that being able to `git annex sync origin` and only sync from/to origin is sufficient, for the centralized use case.
+
+---
+
+Code review:
+
+Why did you make `branch` strict?
+
+There is a bit of a bug in your use of Command.Merge.start. The git-annex branch merge code only runs once per git-annex run, and often this comes before sync fetches from the remotes, leading to a push conflict. I've fixed this in my \"sync\" branch, along with a few other minor things.
+
+`mergeRemote` merges from `refs/remotes/foo/synced/master`. But that will only be up-to-date if `git annex sync` has recently been run there. Is there any reason it couldn't merge from `refs/remotes/foo/master`?
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_12_ca8ca35d6cd4a9f94568536736c12adc._comment b/doc/forum/pure_git-annex_only_workflow/comment_12_ca8ca35d6cd4a9f94568536736c12adc._comment
new file mode 100644
index 0000000000..5b0259b97a
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_12_ca8ca35d6cd4a9f94568536736c12adc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 12"
+ date="2011-12-30T23:45:57Z"
+ content="""
+I have made a new `autosync` branch, where all that the user needs to do is run `git annex sync` and it automatically sets up the synced/master branch. I find this very easy to use, what do you think?
+
+Note that `autosync` is also pretty smart about not running commands like \"git merge\" and \"git push\" when they would not do anything. So you may find `git annex sync` not showing all the steps you'd expect. The only step a sync always performs now is pulling from the remotes.
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_13_00c82d320c7b4bb51078beba17e14dc8._comment b/doc/forum/pure_git-annex_only_workflow/comment_13_00c82d320c7b4bb51078beba17e14dc8._comment
new file mode 100644
index 0000000000..84515ec6c5
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_13_00c82d320c7b4bb51078beba17e14dc8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 13"
+ date="2011-12-31T18:34:31Z"
+ content="""
+I have merged my autosync branch, the improved sync command will be in this year's last git-annex release!
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_14_b63568b327215ef8f646a39d760fdfc0._comment b/doc/forum/pure_git-annex_only_workflow/comment_14_b63568b327215ef8f646a39d760fdfc0._comment
new file mode 100644
index 0000000000..194415dfb6
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_14_b63568b327215ef8f646a39d760fdfc0._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="comment 14"
+ date="2012-01-02T14:02:04Z"
+ content="""
+Sorry for not replying earlier, but my non-mailinglist-communications-workflows are suboptimal :-)
+
+> Then in each repo, I found I had to pull from each of its remotes, to get the tracking branches that defaultSyncRemotes looks for to know those remotes are syncable.  This was the surprising thing for me, I had expected sync to somehow work out which remotes were syncable without my explicit pull. And it was not very obvious that sync was not doing its thing before I did that, since it still does a lot of \"stuff\".
+
+Right. But \"git fetch\" ought to be enough.
+
+Personally, I’d just pull and push everywhere, but you pointed out that it ought to be manageable. The existence of the synced/master branch is the flag that indicates this, so you need to propagate this once. Note that if the branch were already created by \"git annex init\", then this would not be a problem.
+
+It is not required to use \"git fetch\" once, you can also call \"git annex sync <remote>\" once with the remote explicitly mentioned; this would involve a fetch.
+
+> While this would lose the ability to control which remotes are synced, I think that being able to git annex sync origin and only sync from/to origin is sufficient, for the centralized use case.
+
+I’d leave this decision to you. But I see that you took the decision already, as your code now creates the synced/master branch when it does not exist (e290f4a8).
+
+> Why did you make branch strict?
+
+Because it did not work otherwise :-). It uses pipeRead, which is lazy, and for some reason git and/or your utility functions did not like that the output of the command was not consumed before the next git command was called. I did not investigate further. For better code, I’d suggest to add a function like pipeRead that completely reads the git output before returning, thus avoiding any issues with lazyIO.
+
+> mergeRemote merges from refs/remotes/foo/synced/master. But that will only be up-to-date if git annex sync has recently been run there. Is there any reason it couldn't merge from refs/remotes/foo/master?
+
+Hmm, good question. It is probably save to merge from both, and push only to synced/master. But which one first? synced/master can be ahead if the repo was synced to from somewhere else, master can be ahead if there are local changes. Maybe git merge should be called on all remote heads simultaniously, thus generating only one commit for the merge. I don’t know how well that works in practice.
+
+Thanks for including my code,
+Joachim
+
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_15_cb7c856d8141b2de3cc95874753f1ee5._comment b/doc/forum/pure_git-annex_only_workflow/comment_15_cb7c856d8141b2de3cc95874753f1ee5._comment
new file mode 100644
index 0000000000..a526d5db8a
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_15_cb7c856d8141b2de3cc95874753f1ee5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 15"
+ date="2012-01-02T16:01:49Z"
+ content="""
+With a lazy branch, I get \"git-annex: no branch is checked out\". Weird.. my best guess is that it's because this is running at the seek stage, which is unusual, and the value is not used until a later stage and so perhaps the git command gets reaped by some cleanup code before its output is read.
+
+(pipeRead is lazy because often it's used to read large quantities of data from git that are processed progressively.)
+
+I did make it merge both branches, separately. It would be possible to do one single merge, but it's probably harder for the user to recover if there are conflicts in an octopus merge. The order of the merges does not seem to me to matter much, barring conflicts it will work either way. Dealing with conflicts during sync is probably a weakness of all this; after the first conflict the rest of the sync will continue failing.
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_1_a32f7efd18d174845099a4ed59e6feae._comment b/doc/forum/pure_git-annex_only_workflow/comment_1_a32f7efd18d174845099a4ed59e6feae._comment
new file mode 100644
index 0000000000..def1794a3e
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_1_a32f7efd18d174845099a4ed59e6feae._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-12-09T22:56:11Z"
+ content="""
+First, you need a bare git repository that you can push to, and pull from. This simplifies most git workflow.
+
+Secondly, I use [mr](http://kitenet.net/~joey/code/mr/), with this in `.mrconfig`:
+
+<pre>
+[DEFAULT]
+lib =
+        annexupdate() {
+                git commit -a -m update || true
+                git pull \"$@\"
+                git annex merge
+                git push || true
+        }
+
+[lib/sound]
+update = annexupdate
+[lib/big]
+update = annexupdate
+</pre>
+
+Which makes \"mr update\" in repositories where I rarely care about git details take care of syncing my changes.
+
+I also make \"mr update\" do a \"git annex get\" of some files in some repositories that I want to always populate. git-annex and mr go well together. :)
+
+Perhaps my annexupdate above should be available as \"git annex sync\"?
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_2_66dc9b65523a9912411db03c039ba848._comment b/doc/forum/pure_git-annex_only_workflow/comment_2_66dc9b65523a9912411db03c039ba848._comment
new file mode 100644
index 0000000000..473a0287d0
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_2_66dc9b65523a9912411db03c039ba848._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="comment 2"
+ date="2011-12-10T16:28:29Z"
+ content="""
+Thanks for the tips so far. I guess a bare-only repo helps, but as well is something that I don’t _need_ (for my use case), any only have to do because git works like this.
+
+Also, if I have a mobile device that I want to push to, then I’d have to have two repositories on the device, as I might not be able to reach my main bare repository when traveling, but I cannot push to the „real“ repo on the mobile device from my computer. I guess I am spoiled by darcs, which will happily push to a checked out 
+remote repository, updating the checkout if possible without conflict.
+
+If I introduce a central bare repository to push to and from; I’d still have to have the other non-bare repos as remotes, so that git-annex will know about them and their files, right?
+
+I’d appreciate a \"git annex sync\" that does what you described (commit all, pull, merge, push). Especially if it comes in a \"git annex sync --all\" variant that syncs all reachable repositories.
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_3_9b7d89da52f7ebb7801f9ec8545c3aba._comment b/doc/forum/pure_git-annex_only_workflow/comment_3_9b7d89da52f7ebb7801f9ec8545c3aba._comment
new file mode 100644
index 0000000000..9b6e6d7c4d
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_3_9b7d89da52f7ebb7801f9ec8545c3aba._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-12-10T19:43:04Z"
+ content="""
+Git can actually push into a non-bare repository, so long as the branch you change there is not a checked out one. Pushing into `remotes/$foo/master` and `remotes/$foo/git-annex` would work, however determining the value that the repository expects for `$foo` is something git cannot do on its own. And of course you'd still have to `git merge remotes/$foo/master` to get the changes. 
+
+Yes, you still keep the non-bare repos as remotes when adding a bare repository, so git-annex knows how to get to them.
+
+I've made `git annex sync` run the simple script above. Perhaps it can later be improved to sync all repositories.
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_4_dc8a3f75533906ad3756fcc47f7e96bb._comment b/doc/forum/pure_git-annex_only_workflow/comment_4_dc8a3f75533906ad3756fcc47f7e96bb._comment
new file mode 100644
index 0000000000..1ac9e798a8
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_4_dc8a3f75533906ad3756fcc47f7e96bb._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="comment 4"
+ date="2011-12-13T18:16:08Z"
+ content="""
+I thought about this some more, and I think I have a pretty decent solution that avoids a central bare repository. Instead of pushing to master (which git does not like) or trying to guess the remote branch name on the other side, there is a well-known branch name, say git-annex-master. Then a sync command would do something like this (untested):
+
+    git commit -a -m 'git annex sync' # ideally with a description derived from the diff
+    git merge git-annex-master
+    git pull someremote git-annex-master # for all reachable remotes. Or better to use fetch and then merge everything in one command?
+    git branch -f git-annex-master # (or checkout git-annex-master, merge master, checkout master, but since we merged before this should have the same effect
+    git annex merge
+    git push someremote git-annex-master # for all reachable remotes
+
+The nice things are: One can push to any remote repository, and thus avoid the issue of pushing to a portable device; the merging happens on the master branch, so if it fails to merge automatically, regular git foo can resolve it, and all changes eventually reach every repository.
+
+What do you think?
+    
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_5_afe5035a6b35ed2c7e193fb69cc182e2._comment b/doc/forum/pure_git-annex_only_workflow/comment_5_afe5035a6b35ed2c7e193fb69cc182e2._comment
new file mode 100644
index 0000000000..0847daae9d
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_5_afe5035a6b35ed2c7e193fb69cc182e2._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="comment 5"
+ date="2011-12-13T18:47:18Z"
+ content="""
+After some experimentation, this seems to work better:
+
+    	git commit -a -m 'git annex sync'
+	git merge git-annex-master
+	for remote in $(git remote)
+	do
+		git fetch $remote
+		git merge $remote git-annex-master
+	done
+	git branch -f git-annex-master
+	git annex merge
+	for remote in $(git remote)
+	do
+		git push $remote git-annex git-annex-master
+	done
+
+Maybe this approach can be enhance to skip stuff gracefully if there is no git-annex-master branch and then be added to what \"git annex sync\" does, this way those who want to use the feature can do so by running \"git branch git-annex-master\" once. Or, if you like this and want to make it default, just make git-annex-init create the git-annex-master branch :-)
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_6_3660d45c5656f68924acbd23790024ee._comment b/doc/forum/pure_git-annex_only_workflow/comment_6_3660d45c5656f68924acbd23790024ee._comment
new file mode 100644
index 0000000000..fc66fbb8e1
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_6_3660d45c5656f68924acbd23790024ee._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 6"
+ date="2011-12-13T20:53:23Z"
+ content="""
+It would be clearer to call \"git-annex-master\" \"synced/master\" (or really \"synced/$current_branch\"). That does highlight that this method of syncing is not particularly specific to git-annex.
+
+I think this would be annoying to those who do use a central bare repository, because of the unnecessary pushing and pulling to other repos, which could be expensive to do, especially if you have a lot of interconnected repos. So having a way to enable/disable it seems best.
+
+Maybe you should work up a patch to Command/Sync.hs, since I know you know haskell :)
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_7_33db51096f568c65b22b4be0b5538c0d._comment b/doc/forum/pure_git-annex_only_workflow/comment_7_33db51096f568c65b22b4be0b5538c0d._comment
new file mode 100644
index 0000000000..753a2af169
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_7_33db51096f568c65b22b4be0b5538c0d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="comment 7"
+ date="2011-12-18T12:08:51Z"
+ content="""
+I agree on the naming suggestions, and that it does not suit everybody. Maybe I’ll think some more about it. The point is: I’m trying to make live easy for those who do not want to manually create some complicated setup, so if it needs configuration, it is already off that track. But turning the current behavior into something people have to configure is also not well received by the users.
+
+Given that \"git annex sync\" is a new command, maybe it is fine to have this as a default behavior, and offer an easy way out. The easy way out could be one of two flags that can be set for a repo (or a remote):
+
+* \"central\", which makes git annex sync only push and pull to and that repo (unless a different remote is given on the command line)
+* \"unsynced\", which makes git annex sync skip the repo.
+
+Maybe central is enough.
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_8_6e5b42fdb7801daadc0b3046cbc3d51e._comment b/doc/forum/pure_git-annex_only_workflow/comment_8_6e5b42fdb7801daadc0b3046cbc3d51e._comment
new file mode 100644
index 0000000000..67953860ae
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_8_6e5b42fdb7801daadc0b3046cbc3d51e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 8"
+ date="2011-12-19T18:29:01Z"
+ content="""
+I don't mind changing the behavior of git-annex sync, certainly..
+
+Looking thru git's documentation, I found some existing configuration that could be reused following your idea.
+There is a remote.name.skipDefaultUpdate and a remote.name.skipFetchAll. Though both have to do with fetches, not pushes.
+Another approach might be to use git's remote group stuff.
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_9_ace319652f9c7546883b5152ddc82591._comment b/doc/forum/pure_git-annex_only_workflow/comment_9_ace319652f9c7546883b5152ddc82591._comment
new file mode 100644
index 0000000000..de656d6629
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_9_ace319652f9c7546883b5152ddc82591._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="comment 9"
+ date="2011-12-19T22:56:26Z"
+ content="""
+Another option that would please the naive user without hindering the more advanced user: \"git annex init\", by default, creates a synced/master branch. \"git annex sync\" will pull from every <remote>/sync/master branch it finds, and also push to any <remote>/sync/master branch it finds, but will not create any. So by default (at least for new users), this provides simple one-step syncing.
+
+Advanced users can disable this per-repo by just deleting the synced/master branch. Presumably the logic will be: Every repo that should not be pushed to, because it has access to some central repo, should not have a synced/master branch. Every other repo, including the (or one of the few) central repos, will have the branch.
+
+This is not the most expressive solution, as it does not allow configuring syncing between arbitrary pairs of repos, but it feels like a good compromise between that and simplicity and transparency.
+
+I think it's about time that I provide less talk and more code. I’ll see when I find the time :-)
+"""]]
diff --git a/doc/forum/purge_files_with_no_copies.mdwn b/doc/forum/purge_files_with_no_copies.mdwn
new file mode 100644
index 0000000000..5761d9290e
--- /dev/null
+++ b/doc/forum/purge_files_with_no_copies.mdwn
@@ -0,0 +1,3 @@
+Hi guys, as a result of some improper handling I am left with a couple of files with no copies scattered all around my repos. Now, while my data loss is unfortunate, it is not tragic. What I would like to do now is to purge all of these files without having to look for them one by one. Is there any easy way to do this? 
+
+Cheers
diff --git a/doc/forum/purge_files_with_no_copies/comment_1_12b578689eb8d5d38c06261ec65e2109._comment b/doc/forum/purge_files_with_no_copies/comment_1_12b578689eb8d5d38c06261ec65e2109._comment
new file mode 100644
index 0000000000..0ea81ecfe7
--- /dev/null
+++ b/doc/forum/purge_files_with_no_copies/comment_1_12b578689eb8d5d38c06261ec65e2109._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.105"
+ subject="comment 1"
+ date="2013-09-19T20:59:32Z"
+ content="""
+This will output all files in your repository that git-annex thinks have no copies left:
+
+`git annex find --not --copies=1`
+
+Piping it to git rm is left as an excercise for the reader..
+"""]]
diff --git a/doc/forum/pushing_to_android.mdwn b/doc/forum/pushing_to_android.mdwn
new file mode 100644
index 0000000000..030ca5c793
--- /dev/null
+++ b/doc/forum/pushing_to_android.mdwn
@@ -0,0 +1 @@
+Dear git-annex community, I've just installed git-annex on my CyanogenMod phone. What I'd like to do is to synchronize my music folder from my desktop to my phone. I.e. I'm using [sshelper](http://arachnoid.com/android/SSHelper/index.html) to start OpenSSH server on the phone. The question is, how can I make git and git-annex available to SSHelper's shell so that I can git push to the phone?
diff --git a/doc/forum/pushing_to_android/comment_1_1a7f6d21a3eef88d20d6f2bbad4c39d5._comment b/doc/forum/pushing_to_android/comment_1_1a7f6d21a3eef88d20d6f2bbad4c39d5._comment
new file mode 100644
index 0000000000..aa60bbee58
--- /dev/null
+++ b/doc/forum/pushing_to_android/comment_1_1a7f6d21a3eef88d20d6f2bbad4c39d5._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-20T19:17:47Z"
+ content="""
+Gosh, I don't know. Android's permission model is not really designed to
+make it very usable as a general unix system like this. Unfortunately.
+
+You might be able to get away with just copying the files from the
+git-annex app into the sheper app.
+
+I think that a better option though, would be to run git-annex on the phone
+and let it notice when a change is made to the repository, and pull.
+The best way to set that up is to use the web app to add a repository on a
+ssh server. As long as the ssh server is running git-annex 5.20140405
+or newer, the git-annex on the phone will be able to instantly notice when
+changes are pushed into the ssh server, and will pull them down to the
+phone.
+"""]]
diff --git a/doc/forum/question_about_assistant_and___47__archive__47__.mdwn b/doc/forum/question_about_assistant_and___47__archive__47__.mdwn
new file mode 100644
index 0000000000..af8cee4c9f
--- /dev/null
+++ b/doc/forum/question_about_assistant_and___47__archive__47__.mdwn
@@ -0,0 +1,22 @@
+I have a git-annex repository located at ~/annex which has been set up using git-annex assistant.
+
+This repository is configured as "client".
+
+My other repository is a huge USB drive configured as "full archive".
+
+Now everything seems to work fine except there is one thing I don't understand:
+
+    alip@client:~/annex> git-annex whereis ./archive/kus.png
+    whereis archive/kus.png (1 copy) 
+        e79a4cf6-4c48-4833-93de-98ba6eb625d6 -- deniz
+    ok
+
+Fine, there is only one copy according to git-annex but the file is still present
+in **this** client repository:
+
+    alip@client:> du -hs ~/annex/archive
+    20G	/home/alip/annex/archive/
+
+How do I free this space? Am I supposed to call git-annex drop manually?
+
+git-annex version: 3.20130124
diff --git a/doc/forum/question_about_assistant_and___47__archive__47__/comment_1_97890e26072af9277144651e3fdcada0._comment b/doc/forum/question_about_assistant_and___47__archive__47__/comment_1_97890e26072af9277144651e3fdcada0._comment
new file mode 100644
index 0000000000..2736016c54
--- /dev/null
+++ b/doc/forum/question_about_assistant_and___47__archive__47__/comment_1_97890e26072af9277144651e3fdcada0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2013-01-30T18:44:52Z"
+ content="""
+Give this a try:
+
+http://git-annex.branchable.com/walkthrough/unused_data/
+"""]]
diff --git a/doc/forum/question_about_assistant_and___47__archive__47__/comment_2_542bf265e35a976ac76767762d67d617._comment b/doc/forum/question_about_assistant_and___47__archive__47__/comment_2_542bf265e35a976ac76767762d67d617._comment
new file mode 100644
index 0000000000..00cc063747
--- /dev/null
+++ b/doc/forum/question_about_assistant_and___47__archive__47__/comment_2_542bf265e35a976ac76767762d67d617._comment
@@ -0,0 +1,104 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkZktNHFhxC1kYA9KKdKpYJO4clq9WDsjE"
+ nickname="Jason"
+ subject="comment 2"
+ date="2013-01-30T19:14:48Z"
+ content="""
+I'm seeing the same thing and I think it's a bug.  Everything I'm reading says that when you move a file from anywhere into an archive directory, it's supposed to upload it to an archive and drop it locally.
+
+If I copy the file from outside my annex into the archive directory it will usually do exactly that and I'll end up with a symlink, but not always.  Sometimes I'll end up with a file.
+
+If I move the file from within my annex into the archive, everything gets confused.  Here is an example:
+
+    [jchu@april annex(master)]$ mkdir testdir
+    [jchu@april annex(master)]$ cd testdir/
+    [jchu@april testdir(master)]$ ls
+    [jchu@april testdir(master)]$ cat > test.txt << EOF
+    > I have a file.  It is very nice.
+    > EOF
+    [jchu@april testdir(master)]$ ls -l
+    total 4
+    -rw-r--r-- 1 jchu users 33 Jan 30 10:53 test.txt
+    [jchu@april testdir(master)]$ mkdir archive
+    [jchu@april testdir(master)]$ mv test.txt archive/
+    [jchu@april testdir(master)]$ ls -l
+    total 0
+    drwxr-xr-x 2 jchu users 21 Jan 30 10:54 archive
+    [jchu@april testdir(master)]$ ls -l archive/
+    total 4
+    -rw-r--r-- 1 jchu users 33 Jan 30 10:53 test.txt
+    [jchu@april testdir(master)]$ # Shouldn't this be a symlink?
+    [jchu@april testdir(master)]$ git show
+    commit 2fb2cba3fae98e0e0b8b7891b1af0cc655754896
+    Author: Jason Chu <jchu@xentac.net>
+    Date:   Wed Jan 30 10:54:11 2013 -0800
+
+    diff --git a/testdir/archive/test.txt b/testdir/archive/test.txt
+    new file mode 120000
+    index 0000000..5bd7982
+    --- /dev/null
+    +++ b/testdir/archive/test.txt
+    @@ -0,0 +1 @@
+    +../../.git/annex/objects/x5/Q1/SHA256E-s33--1859a57b635b0702dd3813dd7637f11842730b0464c35a4ad361dd0d37fc3dab.txt/SHA256E-s33--1859a57b635b0702dd3813dd7637f11842730b0464c35a4ad3
+    \ No newline at end of file
+    [jchu@april testdir(master)]$ git show HEAD^
+    commit 410f58f782348599d42496db2c9b21cfb2e59124
+    Author: Jason Chu <jchu@xentac.net>
+    Date:   Wed Jan 30 10:54:10 2013 -0800
+
+    diff --git a/testdir/test.txt b/testdir/test.txt
+    deleted file mode 120000
+    index 82343e3..0000000
+    --- a/testdir/test.txt
+    +++ /dev/null
+    @@ -1 +0,0 @@
+    -../.git/annex/objects/x5/Q1/SHA256E-s33--1859a57b635b0702dd3813dd7637f11842730b0464c35a4ad361dd0d37fc3dab.txt/SHA256E-s33--1859a57b635b0702dd3813dd7637f11842730b0464c35a4ad361d
+    \ No newline at end of file
+
+From what I can see here, the file was archived properly and the delete in git was issued correctly.  The daemon.log shows me that the file was uploaded correctly when it was initially created and then added to the archive directory, but I don't see a direct delete in the log file (even though the git log shows me it happened).
+
+Now on to the really weird part.  If I restart the daemon (or there are other ways to trigger it, but this seems to be the easiest for me), I see that log lines that say testdir/archive/test.txt was dropped (good) but then testdir/test.txt is re-downloaded and appears back in that directory.  I wanted the file deleted from testdir, why is it back?!?  Since it gets redownloaded and readded, my new logs look like this:
+
+    [jchu@april testdir(master)]$ git show
+    commit 850464dd2f8ae5cd407a214543afab668d4b34eb
+    Author: Jason Chu <jchu@xentac.net>
+    Date:   Wed Jan 30 11:00:03 2013 -0800
+
+    diff --git a/testdir/archive/test.txt b/testdir/archive/test.txt
+    deleted file mode 120000
+    index 5bd7982..0000000
+    --- a/testdir/archive/test.txt
+    +++ /dev/null
+    @@ -1 +0,0 @@
+    -../../.git/annex/objects/x5/Q1/SHA256E-s33--1859a57b635b0702dd3813dd7637f11842730b0464c35a4ad361dd0d37fc3dab.txt/SHA256E-s33--1859a57b635b0702dd3813dd7637f11842730b0464c35a4ad3
+    \ No newline at end of file
+    [jchu@april testdir(master)]$ git show HEAD^
+    commit 8cf9019e66e5a2cb0478e965fda352c742972591
+    Author: Jason Chu <jchu@xentac.net>
+    Date:   Wed Jan 30 11:00:00 2013 -0800
+
+    diff --git a/testdir/test.txt b/testdir/test.txt
+    new file mode 120000
+    index 0000000..82343e3
+    --- /dev/null
+    +++ b/testdir/test.txt
+    @@ -0,0 +1 @@
+    +../.git/annex/objects/x5/Q1/SHA256E-s33--1859a57b635b0702dd3813dd7637f11842730b0464c35a4ad361dd0d37fc3dab.txt/SHA256E-s33--1859a57b635b0702dd3813dd7637f11842730b0464c35a4ad361d
+    \ No newline at end of file
+
+And the filesystem looks like this:
+
+    [jchu@april testdir(master)]$ ls -lR
+    .:
+    total 4
+    drwxr-xr-x 2 jchu users 21 Jan 30 11:00 archive
+    -rw-r--r-- 1 jchu users 33 Jan 30 11:00 test.txt
+
+    ./archive:
+    total 4
+    -rw-r--r-- 1 jchu users 33 Jan 30 11:00 test.txt
+
+I have 3 remotes set up: a usb drive (client, it was created like that directly by annex when I created a Removable drive repo, it's a bare repo), s3 (archive), and nas (a remote server repo, that connects over ssh and uses rsync).  I thought maybe that the usb drive still had a record of testdir/test.txt existing, but the logs in refs/heads/synced/master match.
+
+It's as if the git annex thinks that the original content is still within a non-archive directory, so the data can't be dropped, but everywhere I look the references to that content are gone.  The only way I've found to fix this is to convert to indirect mode and delete the symlinks from there (which seems to work better).  It seems to be an interaction between direct mode, the archive, and maybe my filesystem (xfs).
+"""]]
diff --git a/doc/forum/question_about_assistant_and___47__archive__47__/comment_3_bafe99159df2adcd5fecc0d67bbf05a5._comment b/doc/forum/question_about_assistant_and___47__archive__47__/comment_3_bafe99159df2adcd5fecc0d67bbf05a5._comment
new file mode 100644
index 0000000000..b1c9e1774e
--- /dev/null
+++ b/doc/forum/question_about_assistant_and___47__archive__47__/comment_3_bafe99159df2adcd5fecc0d67bbf05a5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.125"
+ subject="comment 3"
+ date="2013-02-05T17:46:56Z"
+ content="""
+@alip I've just fixed a bug which made the assistant get location tracking info wrong for files it added in direct mode. That probably explains what you're seeing. You can run `git annex fsck` to fix the location log info, and if you restart the assistant it'll probably then realize the files are locally present and drop them. Of course, the USB drive has to be connected for that to work; git-annex needs to verify the files have been moved to it before it can drop them.
+"""]]
diff --git a/doc/forum/question_about_assistant_and___47__archive__47__/comment_4_e77fa2992d9302a49a05f514c81612ca._comment b/doc/forum/question_about_assistant_and___47__archive__47__/comment_4_e77fa2992d9302a49a05f514c81612ca._comment
new file mode 100644
index 0000000000..3f78b4813f
--- /dev/null
+++ b/doc/forum/question_about_assistant_and___47__archive__47__/comment_4_e77fa2992d9302a49a05f514c81612ca._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.125"
+ subject="comment 4"
+ date="2013-02-05T19:05:49Z"
+ content="""
+@Jason That is a bug.  Please don't report what are obviously bugs in the forum! 
+
+I've posted a bug report about it here: [[bugs/direct_mode_renames]]
+"""]]
diff --git a/doc/forum/race_condition_with_drop_-J__63__.mdwn b/doc/forum/race_condition_with_drop_-J__63__.mdwn
new file mode 100644
index 0000000000..77ece255e0
--- /dev/null
+++ b/doc/forum/race_condition_with_drop_-J__63__.mdwn
@@ -0,0 +1,7 @@
+When I run a command like: "git-annex drop . -J 20"
+
+I get: "git-annex: content is locked"
+
+Running with -J 5 works.
+
+EDIT: Even as low as -J 2 runs into problems. The issue is simply more likely to trigger with more threads.
diff --git a/doc/forum/race_condition_with_drop_-J__63__/comment_1_0607c11410d99a6933e02c28b54c1f65._comment b/doc/forum/race_condition_with_drop_-J__63__/comment_1_0607c11410d99a6933e02c28b54c1f65._comment
new file mode 100644
index 0000000000..e6d2357142
--- /dev/null
+++ b/doc/forum/race_condition_with_drop_-J__63__/comment_1_0607c11410d99a6933e02c28b54c1f65._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-04T17:13:55Z"
+ content="""
+This can happen if the working tree contains two files that both point to
+the same content. Since git-annex is dropping multiple files in parallel,
+it might try to drop both files at the same time. One of the drops will
+succeed, and the other fail as shown.
+
+It should be nothing to worry about since the content does get dropped.
+"""]]
diff --git a/doc/forum/read_directly_from_annex.mdwn b/doc/forum/read_directly_from_annex.mdwn
new file mode 100644
index 0000000000..11a134f22f
--- /dev/null
+++ b/doc/forum/read_directly_from_annex.mdwn
@@ -0,0 +1 @@
+I want to store my annex on google cloud storage (GCS) and load files from the annex on GCS directly into Big Query for processing. I'm planning on using DataLad's gitannex features. I'm thinking this kind of approach is needed to avoid the overhead of downloading to the server where the Datalad git repo is running and the need for space to store it on the regular file system.  Is anything like this possible? 
diff --git a/doc/forum/read_directly_from_annex/comment_1_d8c4a60a672e60f89d6e57e515ef86cd._comment b/doc/forum/read_directly_from_annex/comment_1_d8c4a60a672e60f89d6e57e515ef86cd._comment
new file mode 100644
index 0000000000..1f62415771
--- /dev/null
+++ b/doc/forum/read_directly_from_annex/comment_1_d8c4a60a672e60f89d6e57e515ef86cd._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-11T16:50:25Z"
+ content="""
+If the GCS remote is not configured to encrypt or chunk the files
+stored in it, they can be accessed by other things than git-annex, but
+the names of the files will be the git-annex keys (eg their hash),
+which may or may not work for what you're processing them with.
+
+If the thing you're processing them with needs to operate on
+the original filenames, you need to use a remote configured with
+exporttree=yes. Then you can use `git annex export master --to remote`
+to make the remote contain a copy of the tree of files in your master
+branch.
+
+Not all special remotes support that feature. For GCS, there is one
+option that does, using the S3 interface to GCS. (rclone and gcsannex do
+not support exporttree)
+"""]]
diff --git a/doc/forum/rebuild_location_log_from_encrypted_remote.mdwn b/doc/forum/rebuild_location_log_from_encrypted_remote.mdwn
new file mode 100644
index 0000000000..bf3f0e830c
--- /dev/null
+++ b/doc/forum/rebuild_location_log_from_encrypted_remote.mdwn
@@ -0,0 +1,35 @@
+Hi,
+
+I apologize, but I can't retrace my steps, so my problem is not replicable. The current situation is: 1 main repo and 1 directory/encrypted special remote. From the main repo, I see 0 available copy of the files I need. But when I do a fsck I do see the file. The problem is that the location log does not seem to get fixed after fsck, as I cannot use git-annex get to obtain the file, even after the fsck command. 
+
+Do you have any suggestions for next diagnostic/repair steps?
+
+Thanks a lot for your time and answer!
+
+Vincent
+
+macbook% git annex fsck foo.zip --from needle
+fsck foo.zip (gpg) 
+You need a passphrase to unlock the secret key for
+user: “me <email@email.edu>”
+2048-bit RSA key, ID ???????, created 2013-01-11 (main key ID ????????)
+
+(checking needle...) 
+GPGHMACSHA1--d7036fd17214c06c83d53479dcec9554a7dc2109
+    13815014 100%   14.16MB/s    0:00:00 (xfer#1, to-check=0/1)
+
+sent 13816832 bytes  received 42 bytes  9211249.33 bytes/sec
+total size is 13815014  speedup is 1.00
+(fixing location log) (checksum...) 
+  ** No known copies exist of foo.zip
+failed
+(Recording state in git...)
+git-annex: fsck: 1 failed
+
+
+macbook% git annex get foo.zip
+get foo.zip (not available) 
+  No other repository is known to contain the file.
+failed
+git-annex: get: 1 failed
+macbook% 
diff --git a/doc/forum/rebuild_location_log_from_encrypted_remote/comment_1_f84f955fed7b96ae6208b6ff2ec650cd._comment b/doc/forum/rebuild_location_log_from_encrypted_remote/comment_1_f84f955fed7b96ae6208b6ff2ec650cd._comment
new file mode 100644
index 0000000000..af3a411593
--- /dev/null
+++ b/doc/forum/rebuild_location_log_from_encrypted_remote/comment_1_f84f955fed7b96ae6208b6ff2ec650cd._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 1"
+ date="2013-12-01T19:59:16Z"
+ content="""
+I think you should try to run `git annex copy --from needle`, which will be able to get the files if needle has them, even if the location log is busted. 
+
+(Sometimes people complain that `git annex copy` goes and checks a remote, which can be unncessarily slow, rather than just trusting the location log  ... but this is why it does it!)
+
+From what I can tell, the fsck downloads some file from the remote, but the download is not entirely successful. One possibility is that it downloads a file, but the file fails to be decrypted, either because you don't have the right encyption key, or because the encrypted file has actually gotten corrupted on the remote. It might be that the same problem will affect `git annex copy --from needle`, but if so it should be more clear what's happening.
+"""]]
diff --git a/doc/forum/rebuild_location_log_from_encrypted_remote/comment_2_c0b2ce3bc7cd55a0c77ddc31493068c2._comment b/doc/forum/rebuild_location_log_from_encrypted_remote/comment_2_c0b2ce3bc7cd55a0c77ddc31493068c2._comment
new file mode 100644
index 0000000000..10b1c038ef
--- /dev/null
+++ b/doc/forum/rebuild_location_log_from_encrypted_remote/comment_2_c0b2ce3bc7cd55a0c77ddc31493068c2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLD-g4d-EGXD5KJh1kVKnRX0a9dTnEigg"
+ nickname="Vincent"
+ subject="comment 2"
+ date="2013-12-02T01:28:18Z"
+ content="""
+Thanks a lot for the quick response! Unfortunately, copy is just silent and does not copy the files over.
+
+I don't want to waste more of your time on this. I just wish I had kept better track of the steps I took to get myself into this mess...
+"""]]
diff --git a/doc/forum/rebuild_location_log_from_encrypted_remote/comment_3_06a73ca3dc73399ff000b642cca72de7._comment b/doc/forum/rebuild_location_log_from_encrypted_remote/comment_3_06a73ca3dc73399ff000b642cca72de7._comment
new file mode 100644
index 0000000000..9cd4424270
--- /dev/null
+++ b/doc/forum/rebuild_location_log_from_encrypted_remote/comment_3_06a73ca3dc73399ff000b642cca72de7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 3"
+ date="2013-12-02T19:53:11Z"
+ content="""
+Hmm, it seems I was wrong about copy --from not checking the location log. It does.. Probably to avoid large copies trying to copy a lot of files that are not present in a remote.
+
+I have now made `git annex copy --force --from remote` do what I said it would do, and that should work in your situation, I think.
+"""]]
diff --git a/doc/forum/receiving_indirect_renames_on_direct_repo___63__.mdwn b/doc/forum/receiving_indirect_renames_on_direct_repo___63__.mdwn
new file mode 100644
index 0000000000..51a3aa7b64
--- /dev/null
+++ b/doc/forum/receiving_indirect_renames_on_direct_repo___63__.mdwn
@@ -0,0 +1,254 @@
+I've been playing with a mixed setup, and I frequentely end up with conflicts which can be ascribed to mixing direct windows repos with indirect linux one(s), and making renames on the indirect ones.
+Possibly someone can address what I miss of the git-annex/git interaction.  
+
+#### versions involved ####
+
+linux: git-annex version: 4.20131024
+win: git-annex version: 4.20131024-gca7b71e
+
+### Steps to reproduce behaviour ###
+
+###### 1. On linux, i setup bare origin "casa" and client repo "local":
+    
+    [michele@home ~]$ git init --bare casa
+    Initialized empty Git repository in /home/sambahome/michele/casa/
+    [michele@home ~]$ cd casa
+    [michele@home casa]$ git annex init casa
+    init casa ok
+    (Recording state in git...)
+    [michele@home ~]$ cd ..; git clone casa local
+    Cloning into 'local'...
+    done.
+    warning: remote HEAD refers to nonexistent ref, unable to checkout.
+    [michele@home ~]$ cd local; git annex init local
+    init local ok
+    (Recording state in git...)
+    [michele@home local]$ echo lintest > lintest
+    [michele@home local]$ git annex add lintest
+    add lintest (checksum...) ok
+    (Recording state in git...)
+    [michele@home local]$ git annex sync
+    (merging origin/git-annex into git-annex...)
+    (Recording state in git...)
+    commit  
+    ok
+    pull origin 
+    ok
+    push origin 
+    Counting objects: 18, done.
+    Delta compression using up to 4 threads.
+    Compressing objects: 100% (12/12), done.
+    Writing objects: 100% (16/16), 1.48 KiB | 0 bytes/s, done.
+    Total 16 (delta 1), reused 0 (delta 0)
+    To /home/sambahome/michele/casa
+     * [new branch]      git-annex -> synced/git-annex
+     * [new branch]      master -> synced/master
+    ok
+    ```
+    
+###### 2. On windows I clone origin, and I sync empty
+
+    ```cmd
+    M:\>git clone ssh://michele@home/home/michele/casa win
+    Cloning into 'win'...
+    remote: Counting objects: 20, done.
+    remote: Compressing objects: 100% (15/15), done.
+    remote: Total 20 (delta 3), reused 0 (delta 0)
+    Receiving objects: 100% (20/20), done.
+    Resolving deltas: 100% (3/3), done.
+    M:\>cd win
+    M:\win>git annex status
+      Detected a crippled filesystem.
+      Enabling direct mode.
+      Detected a filesystem without fifo support.
+      Disabling ssh connection caching.
+    repository mode: direct
+    trusted repositories: (merging origin/git-annex origin/synced/git-annex into git-annex...)
+    (Recording state in git...)
+    0
+    semitrusted repositories: 4
+            00000000-0000-0000-0000-000000000001 -- web
+            598ecfac-087d-49a3-b48d-beafd0d71805 -- origin (casa)
+            b2699c17-d0bc-40a0-b447-a64ad109b2a2 -- here (ALICUDI:M:\win)
+            bd4166eb-296b-4f0f-a3be-6c25e4c7cbb0 -- local
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: unknown
+    local annex keys: 0
+    local annex size: 0 bytes
+    known annex keys: 1
+    known annex size: 8 bytes
+    bloom filter size: 16 mebibytes (0% full)
+    backend usage:
+            SHA256E: 1
+    ```
+    
+###### 3. I copy content from local to win
+
+    ```bash
+    [michele@home local]$ git annex copy --to origin lintest
+    copy lintest (to origin...) ok
+    (Recording state in git...)
+    [michele@home local]$ git annex sync
+    ...runs ok...
+    ```
+
+###### 4. and
+
+    ```cmd
+    M:\win>git annex sync
+    ...works
+    M:\win>git annex get .
+    ...works
+    M:\win>cat lintest
+    lintest
+    ```
+
+so far so good.
+###### 5. Now the renaming part (performed on linux indirect repo)
+
+    ```bash
+    [michele@home local]$ git mv lintest renamed
+    [michele@home local]$ git annex list
+    here
+    |origin
+    ||web
+    |||
+    XX_ renamed
+    [michele@home local]$ git annex sync
+    ...works
+    ```
+
+###### 6.  now, by issuing sync on windows I start getting a "push issue":
+
+    ```
+    M:\win>git annex sync
+    commit
+    ok
+    pull origin
+    remote: Counting objects: 3, done.
+    remote: Total 2 (delta 0), reused 0 (delta 0)
+    Unpacking objects: 100% (2/2), done.
+    From ssh://home/home/michele/casa
+       c3b7a63..a0854bf  master     -> origin/master
+       c3b7a63..a0854bf  synced/master -> origin/synced/master
+    ok
+    push origin
+    Counting objects: 9, done.
+    Delta compression using up to 2 threads.
+    Compressing objects: 100% (4/4), done.
+    Writing objects: 100% (5/5), 484 bytes, done.
+    Total 5 (delta 1), reused 0 (delta 0)
+    To ssh://michele@home/home/michele/casa
+       6c18669..8cc74a0  git-annex -> synced/git-annex
+     ! [rejected]        master -> synced/master (non-fast-forward)
+    error: failed to push some refs to 'ssh://michele@home/home/michele/casa'
+    hint: Updates were rejected because a pushed branch tip is behind its remote
+    hint: counterpart. Check out this branch and merge the remote changes
+    hint: (e.g. 'git pull') before pushing again.
+    hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+    failed
+    git-annex: sync: 1 failed
+    
+    M:\win>
+    ```
+
+at this stage I tried to issue a git annex merge, git annex sync, leading to same result.
+
+somewhere in the forum I read i could try issuing a git pull origin master (this could be the problem).
+and the result is as such:
+
+    ```
+    M:\win>git pull master
+    fatal: 'master' does not appear to be a git repository
+    fatal: The remote end hung up unexpectedly
+    
+    M:\win>git pull origin master
+    From ssh://home/home/michele/casa
+     * branch            master     -> FETCH_HEAD
+    Updating c3b7a63..a0854bf
+    error: Your local changes to the following files would be overwritten by merge:
+            lintest
+    Please, commit your changes or stash them before you can merge.
+    Aborting
+    
+    M:\win>git status
+    # On branch master
+    # Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
+    #
+    # Changes not staged for commit:
+    #   (use "git add <file>..." to update what will be committed)
+    #   (use "git checkout -- <file>..." to discard changes in working directory)
+    #
+    #       modified:   lintest
+    #
+    no changes added to commit (use "git add" and/or "git commit -a")
+    
+    M:\win>cat lintest
+    lintest
+    ```
+    
+well, ok it appears modified for some weirdness (crlf?), we can live with it.
+
+    ```
+    M:\win>git checkout -->> this replaces files contents with simlink (due to git pull above?)
+    ```
+
+at this stage content is lost, and annex has no knowledge about it.
+
+    ```
+    M:\win>git annex fsck
+    fsck lintest ok
+    
+    M:\win>cat lintest
+    .git/annex/objects/9Z/82/SHA256E-s8--2b721dbe9afe6031cce3004e909dd62e0b4b2f3944438b6a000dffc7ad657715/SHA256E-s8--2b721dbe9afe6031cce3004e90
+    M:\win>git annex list
+    here
+    |origin
+    ||web
+    |||
+    XX_ lintest
+    ```
+
+still I cannot sync, but now i can pull origin master:
+
+    ```cmd
+    M:\win>git pull origin master                          From ssh://home/home/michele/casa                       * branch            master     -> FETCH_HEAD          Updating c3b7a63..a0854bf                              Fast-forward                                            lintest => renamed | 0                                 1 file changed, 0 insertions(+), 0 deletions(-)        rename lintest => renamed (100%)                      
+    ```
+
+this doesnt restore content (annex thinks its already there:
+
+    ```
+    M:\win>cat renamed
+    .git/annex/objects/9Z/82/SHA256E-s8--2b721dbe9afe6031cce3004e909dd62e0b4b2f3944438b6a000dffc7ad657715/SHA256E-s8--2b721dbe9afe6031cce3004e909dd62e0b4b2f3944438b6a000dffc7ad657715
+    ```
+
+I think my mistake is the use of the ```git checkout``` in direct mode. But why is the file detected as modified in the first place ?
+
+note: as long as i didn't drop on origin, i still can recover contents by 'forcing' a content refresh:
+
+    ```
+    M:\win>git annex get renamed --from origin
+    get renamed (from origin...)
+    SHA256E-s8--2b721dbe9afe6031cce3004e909dd62e0b4b2f3944438b6a000dffc7ad657715
+               8 100%    7.81kB/s    0:00:00 (xfer#1, to-check=0/1)
+    
+    sent 30 bytes  received 153 bytes  8.13 bytes/sec
+    total size is 8  speedup is 0.04
+    ok
+    (Recording state in git...)
+    
+    M:\win>cat renamed
+    .git/annex/objects/9Z/82/SHA256E-s8--2b721dbe9afe6031cce3004e909dd62e0b4b2f3944438b6a000dffc7ad657715/SHA256E-s8--2b721dbe9afe6031cce3004e909d
+    M:\win>git annex fsck
+    fsck renamed (fixing direct mode) (checksum...) ok
+    
+    M:\win>cat renamed
+    lintest
+```
+
+
+
+
+
+
diff --git a/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_1_f4b0a14373c75cb752597c832e296bcc._comment b/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_1_f4b0a14373c75cb752597c832e296bcc._comment
new file mode 100644
index 0000000000..7b38c6af4d
--- /dev/null
+++ b/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_1_f4b0a14373c75cb752597c832e296bcc._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-10-26T19:35:46Z"
+ content="""
+You should **never, ever, ever** run `git pull`, or `git checkout` inside a direct repository. You need to read [[direct_mode]]. If you do not fully understand it, you should avoid running any git commands that are not `git annex foo` in a direct mode repository. If you forget and do run such git commands, you can generally recover by running `git annex fsck`, although it's possible that the git command you run overwrites your only copy of a file, and so you'd lose it.
+
+<pre>
+To ssh://michele@home/home/michele/casa
+   6c18669..8cc74a0  git-annex -> synced/git-annex
+ ! [rejected]        master -> synced/master (non-fast-forward)
+error: failed to push some refs to 'ssh://michele@home/home/michele/casa'
+</pre>
+
+I'll bet that if you look at the `git config` of this repository it failed to push to, you'll find that it has `receive.denyNonFastforwards` set to true. If you unset that, the push should work.
+"""]]
diff --git a/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_2_8c86dfc99f0b9040402c9d746decda53._comment b/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_2_8c86dfc99f0b9040402c9d746decda53._comment
new file mode 100644
index 0000000000..8b4ff46a40
--- /dev/null
+++ b/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_2_8c86dfc99f0b9040402c9d746decda53._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI"
+ nickname="Michele"
+ subject="still cannot push when remote has renames"
+ date="2013-10-27T23:06:03Z"
+ content="""
+now, I went again through docs, and i realized how stupid was issuing a git pull on a direct repo. thanks for your patience.
+
+but, i double checked the configuration, I assume \"receive.denyNonFastForwards\" is false by default, but anyway I set it up explicitely so that now my git config (on the linux indirect repo - with respect to my previous example, I got rid of the \"extra\" bare repo in the middle) shows:
+
+    $ git config --list
+    user.email=m@g.com
+    user.name=michele
+    core.repositoryformatversion=0
+    core.filemode=true
+    core.bare=false
+    core.logallrefupdates=true
+    annex.uuid=d084e0fd-95a7-4c98-a206-fbf2c85b779d
+    annex.version=3
+    receive.denynonfastforwards=false
+
+still I am receiving the push refusal:
+
+    M:\win>git annex sync
+    commit
+    ok
+    pull origin
+    ok
+    push origin
+    To ssh://michele@home/home/michele/casa
+       ! [rejected]        master -> synced/master (non-fast-forward)
+    error: failed to push some refs to 'ssh://michele@home/home/michele/casa'
+    hint: Updates were rejected because a pushed branch tip is behind its remote
+    hint: counterpart. Check out this branch and merge the remote changes
+    hint: (e.g. 'git pull') before pushing again.
+    hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+    failed
+    git-annex: sync: 1 failed
+
+Same happens with a bare repository in the middle. BTW: the windows \"client\" repository is behind NAT, so that the linux indirect doesn't actively sync against it: could that be source of the problem ?
+"""]]
diff --git a/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_3_0246fff6c7c75f6be45bd257ec3872a5._comment b/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_3_0246fff6c7c75f6be45bd257ec3872a5._comment
new file mode 100644
index 0000000000..0ffb2a0972
--- /dev/null
+++ b/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_3_0246fff6c7c75f6be45bd257ec3872a5._comment
@@ -0,0 +1,75 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI"
+ nickname="Michele"
+ subject="possible explanation"
+ date="2013-10-29T11:56:21Z"
+ content="""
+now, i tried to understand what happens. Instead of issuing the *git annex sync*, I relied on *git pull origin, git merge origin/master*, (I red [[http://git-annex.branchable.com/forum/Help_Windows_walkthrough/]] and I assume that pull origin / merge origin/master would work similarly to the \"download\" part of sync, *except for losing all my direct content*) just to understand what was going on, with a clarifying result:
+
+while git annex sync fails on push, git pull origin fails on pull:
+
+    M:\win>git pull origin
+    Updating 5408d6f..c566a69
+    error: Your local changes to the following files would be overwritten by merge:
+            myfile
+    Please, commit your changes or stash them before you can merge.
+    Aborting 
+
+note that the file has not been modified locally (just got it through git annex get).
+issuing a git diff, reveals:
+
+    M:\win>git diff myfile
+    diff --git a/myfile b/myfile
+    index beaf3e8..dc5b4ff 120000
+    --- a/myfile
+    +++ b/myfile
+    @@ -1 +1 @@
+    -.git/annex/objects/z5/v7/SHA256E-s8--6090923ed0931dcc6699f32fb66fa4ba32c10924088b12c66fb4ce35a91ba98c/SHA256E-s8\ No newline at end of file
+    +linux.1
+    (END)
+
+ok, i follow suggestion, and I perform a git stash. that still wouldn't suffice for git annex sync:
+
+    M:\win>git annex sync
+    commit
+    ok
+    pull origin
+    ok
+    push origin
+    To ssh://michele@home/home/michele/homebase
+     ! [rejected]        master -> synced/master (non-fast-forward)
+    error: failed to push some refs to 'ssh://michele@home/home/michele/homebase'
+    hint: Updates were rejected because a pushed branch tip is behind its remote
+    hint: counterpart. Check out this branch and merge the remote changes
+    hint: (e.g. 'git pull') before pushing again.
+    hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+    failed
+    git-annex: sync: 1 failed
+
+now, i can perform instead a *git pull origin*, since I am confident my content is stashed.
+
+    M:\win>git pull origin
+    Updating 5408d6f..c566a69
+    Fast-forward
+     myfile => myfile.renamed | 0
+     1 file changed, 0 insertions(+), 0 deletions(-)
+     rename myfile => myfile.renamed (100%)
+
+merge is not doing anything more: at this stage content has gone (file is a direct-mode symlink nad it cannot be fixed by fsck). 
+But i can recover it from stash (and I must do it unless I want to get the annex to think i still have content).
+
+    git stash apply 
+
+voilà: the content is there! and the repos seems in good order. 
+this only adds up that this is possibily a bug in the fact that git reports direct content as modified when indeed it hasn't been modified: but this affects git annex sync only when merging renaming files.
+git annex sync now works perfectly .
+
+to sum it up, I have two questions: 
+
+1) does using stash to circumvent the problem expose me to any risk ?
+2) would the behaviour on receiving renames in the abovementioned situation worth to be signaled as a bug ? 
+
+
+
+
+"""]]
diff --git a/doc/forum/recover_deleted_files___63__.mdwn b/doc/forum/recover_deleted_files___63__.mdwn
new file mode 100644
index 0000000000..7bec369685
--- /dev/null
+++ b/doc/forum/recover_deleted_files___63__.mdwn
@@ -0,0 +1,66 @@
+hi, 
+
+i think of use git-annex as the backbone of a archival systems. at first point no distributed storage, just 1 node.
+but now i run into the topic below ( deleted the "named" symlink of the "object" -- how to recover ?)
+
+maybe someone can enlighten me...
+
+thanks,
+.ka
+
+// about the version. ( debian-squeeze, bpo )
+
+$ git-annex version
+git-annex version: 3.20120629~bpo60+2
+local repository version: 3
+default repository version: 3
+supported repository versions: 3
+upgrade supported from repository versions: 0 1 2
+
+// building up a testcase.
+
+$ git init
+Initialized empty Git repository in ...test2/.git/
+
+$ git annex init
+init  ok
+(Recording state in git...)
+
+$ echo "aaa" > 1.txt
+
+$ echo "bbb" > 2.txt
+
+$ git-annex add .
+add 1.txt (checksum...) ok
+add 2.txt (checksum...) ok
+(Recording state in git...)
+
+$ git commit -a -m "added 2 files"
+fatal: No HEAD commit to compare with (yet)
+fatal: No HEAD commit to compare with (yet)
+[master (root-commit) fc2a5d7] added 2 files
+ Committer: userhere user <bla@bla>
+Your name and email address were configured automatically based
+on your username and hostname. Please check that they are accurate.
+...
+ 2 files changed, 2 insertions(+), 0 deletions(-)
+ create mode 120000 1.txt
+ create mode 120000 2.txt
+
+// ok, so far standard. i have now 2 files - lets delete one.
+
+$ rm 2.txt 
+$ ls -l
+lrwxrwxrwx 1 xp xp 176 24. Okt 22:55 1.txt -> .git/annex/objects/Z6/7q/SHA256-s4--17e682f060b5f8e47ea04c5c4855908b0a5ad612022260fe50e11ecb0cc0ab76/SHA256-s4--17e682f060b5f8e47ea04c5c4855908b0a5ad612022260fe50e11ecb0cc0ab76
+
+// eek, delete of 2.txt was a bad idea (it was just the symlink) -- try to recover...
+
+$ git-annex fix
+$ git-annex fsck
+fsck 1.txt (checksum...) ok
+$ ls
+1.txt
+
+// still not here.. how to recover the link to 2.txt ???
+// i still see the content of the file in the object folder
+// if I want to use git-annex as the backend of a archival system, this is important.
diff --git a/doc/forum/recover_deleted_files___63__/comment_1_d7abb7c45c6ec2723a04f153ed215453._comment b/doc/forum/recover_deleted_files___63__/comment_1_d7abb7c45c6ec2723a04f153ed215453._comment
new file mode 100644
index 0000000000..646e7ad540
--- /dev/null
+++ b/doc/forum/recover_deleted_files___63__/comment_1_d7abb7c45c6ec2723a04f153ed215453._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://ciffer.net/~svend/"
+ ip="2001:1938:81:1ff::2"
+ subject="git checkout"
+ date="2012-10-24T22:50:05Z"
+ content="""
+You can use `git checkout -- file` to restore the link. `git status` will display information for restoring the file.
+"""]]
diff --git a/doc/forum/recover_deleted_files___63__/comment_2_8ea2acaa30d3ee7e9f75310f4ec859b2._comment b/doc/forum/recover_deleted_files___63__/comment_2_8ea2acaa30d3ee7e9f75310f4ec859b2._comment
new file mode 100644
index 0000000000..c99461ae0b
--- /dev/null
+++ b/doc/forum/recover_deleted_files___63__/comment_2_8ea2acaa30d3ee7e9f75310f4ec859b2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.138"
+ subject="it's a git repository..."
+ date="2012-10-25T03:29:20Z"
+ content="""
+So any git stuff can be used. If you deleted a file, committed it, and want to undo that, you can `git log --stat` to find the commit, and `git revert` it. If you deleted a file, haven't committed yet, and want one more look at it, you can `git stash` to get it back, and `git stash apply` to re-stash the change. Or yeah, just `git checkout` to get back a deleted file you have not committed yet.
+"""]]
diff --git a/doc/forum/recover_deleted_files___63__/comment_3_376de81c70799bf409be189a48234815._comment b/doc/forum/recover_deleted_files___63__/comment_3_376de81c70799bf409be189a48234815._comment
new file mode 100644
index 0000000000..89edb17eb6
--- /dev/null
+++ b/doc/forum/recover_deleted_files___63__/comment_3_376de81c70799bf409be189a48234815._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="ka7"
+ ip="2001:7b8:155d:0:222:64ff:fe16:dc52"
+ subject="ok, that worked."
+ date="2012-10-25T20:15:26Z"
+ content="""
+i think of a kind of \"WORM-library\", so basically just add, not allow to remove content. (at least not for the user thru the mounted device)
+- so a script to add/commit -- but as stag-1 check for delete files and get them back. some git magic needed, but should be doable.
+- or thru \"samba\" parameters set to add but not delete/overwrite files.  (read yes, write yes, delete no) -- to be proved thats possible, but not your job :) ( annex-ing via cron every /5 or via inotify)
+so yea, will play for a while and maybe come back with new. thanks to everybody. 
+<3 git-annex <3
+"""]]
diff --git a/doc/forum/recover_deleted_files___63__/comment_4_2e73ac530d65a01768a57058b7220a29._comment b/doc/forum/recover_deleted_files___63__/comment_4_2e73ac530d65a01768a57058b7220a29._comment
new file mode 100644
index 0000000000..9e9c1b4bf2
--- /dev/null
+++ b/doc/forum/recover_deleted_files___63__/comment_4_2e73ac530d65a01768a57058b7220a29._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXlmnJKsPulm2S_hwwRm3Ky27Zyf-wKMw"
+ nickname="Chad"
+ subject="After the fact..."
+ date="2013-12-22T03:51:36Z"
+ content="""
+I've run into a situation where I've inadvertently deleted a file from my Andriod-driven annex repo rather than dropping the file. (A set of very large *.flac files, to be exact.) These are now gone from the repo on my laptop and the repo on my workstation. When looking at the `git --log stat' call, I see the addition of these files, but I do not see their deletion. When running `git annex unused', I found references to the *.flac files, their SHA key, and indeed found the commit they were associated with. I have not dropped these unused files. How to I recover them?
+"""]]
diff --git a/doc/forum/recovering_from_repo_corruption.mdwn b/doc/forum/recovering_from_repo_corruption.mdwn
new file mode 100644
index 0000000000..42df61b789
--- /dev/null
+++ b/doc/forum/recovering_from_repo_corruption.mdwn
@@ -0,0 +1,11 @@
+In my current annex config, I have 4 computers with "traditional" git annexes as well as an external drive that is a git annex, an rsync'd backup annex, and a glacier archive.  Today, one of the computers got a corrupted git repo. It was complaining that a pack file was invalid. In my attempts to fix it, a commit was logged that deleted every file in the annex. I didn't find this out until I did 'git annex sync' and watched git delete everything, then send all those commits to my other 3 systems and the external drive. *facepalm*
+
+Fortunately, I had one of those other systems in direct mode and I copied everything from the annex as a backup. Now, when I try to re-add files to the annex, I'm running into some errors. These appear to be "collisions" within the annex part of the .git folder:
+
+    %  › git annex add House.netspd 
+    add House.netspd (checksum...) 
+    git-annex: /Users/akraut/Desktop/annex/.git/annex/objects/31/Gw/SHA256E-s167433--41e68ea0adb5a4086a0b7b39d0556b9b86523ffb6b498d58f12f96460da315e9/SHA256E-s167433--41e68ea0adb5a4086a0b7b39d0556b9b86523ffb6b498d58f12f96460da315e9.map.tmp62699: openFile: permission denied (Permission denied)
+    failed
+    git-annex: add: 1 failed
+
+Any ideas on what's going on here? Perhaps how to get things added back in or recovered? It seems all the actual file contents are here, but annex doesn't seem to know they're there anymore.
diff --git a/doc/forum/recovering_from_repo_corruption/comment_1_01fc85037e24fc70e5c5329898cf6781._comment b/doc/forum/recovering_from_repo_corruption/comment_1_01fc85037e24fc70e5c5329898cf6781._comment
new file mode 100644
index 0000000000..ab65b42cbc
--- /dev/null
+++ b/doc/forum/recovering_from_repo_corruption/comment_1_01fc85037e24fc70e5c5329898cf6781._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 1"
+ date="2013-01-26T07:11:35Z"
+ content="""
+speaking strictly from the git point of view, you can create a new commit that reverses an old commit completely.
+
+    git revert <commit>
+
+creates a new commit which does the exact opposite of the commit you specify.  Theoretically it bring everything back to you quick and clean!
+
+
+
+"""]]
diff --git a/doc/forum/recovering_from_repo_corruption/comment_2_3bd1c0bf25a0e892e711a60f53cd5298._comment b/doc/forum/recovering_from_repo_corruption/comment_2_3bd1c0bf25a0e892e711a60f53cd5298._comment
new file mode 100644
index 0000000000..c8df9c0a06
--- /dev/null
+++ b/doc/forum/recovering_from_repo_corruption/comment_2_3bd1c0bf25a0e892e711a60f53cd5298._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmRFKwny4rArBaz-36xTcsJYqKIgdDaw5Q"
+ nickname="Andrew"
+ subject="comment 2"
+ date="2013-01-26T08:13:34Z"
+ content="""
+Oh! Good call. That worked, though I did have to sync and revert alternately a few times to get things resolved.  I still haven't figured out what exactly happened, though. In two separate instances, the commit message was \"git-annex automatic sync\"
+"""]]
diff --git a/doc/forum/recovering_from_repo_corruption/comment_3_679dde8ca0081fc6854d6d2e8a42abdb._comment b/doc/forum/recovering_from_repo_corruption/comment_3_679dde8ca0081fc6854d6d2e8a42abdb._comment
new file mode 100644
index 0000000000..9b724b1431
--- /dev/null
+++ b/doc/forum/recovering_from_repo_corruption/comment_3_679dde8ca0081fc6854d6d2e8a42abdb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 3"
+ date="2013-01-26T09:11:00Z"
+ content="""
+I've fixed the bug that led to the permissions denied error.
+"""]]
diff --git a/doc/forum/recovery_from_failed_merge.mdwn b/doc/forum/recovery_from_failed_merge.mdwn
new file mode 100644
index 0000000000..802c66e511
--- /dev/null
+++ b/doc/forum/recovery_from_failed_merge.mdwn
@@ -0,0 +1,7 @@
+Starting the assistant version 5.20140613 on my  repository (~60GB), it performed a merge
+with an offline-repository, deleting a large part of the files.
+Since the repo is in direct mode, I cannot do a git revert. The other repo is not available anymore
+
+Any way of getting them back?
+Also, du shows me that the .git/annex/objects folder has approximately the size of my repo before the incident.
+
diff --git a/doc/forum/recovery_from_failed_merge/comment_1_84e5b55d473d16bc9bdba5d88dc29bc3._comment b/doc/forum/recovery_from_failed_merge/comment_1_84e5b55d473d16bc9bdba5d88dc29bc3._comment
new file mode 100644
index 0000000000..3f61d8cb9e
--- /dev/null
+++ b/doc/forum/recovery_from_failed_merge/comment_1_84e5b55d473d16bc9bdba5d88dc29bc3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-06-16T17:58:22Z"
+ content="""
+All your files are still there..
+
+You can either use `git annex indirect` to switch to indirect mode and then `git revert`, or you could git clone the repo to someplace else, do the revert there, and then run `git annex sync` in first the clone and then in the direct mode repo to sync the reversion back.
+"""]]
diff --git a/doc/forum/reflog_of_pruned_commits.mdwn b/doc/forum/reflog_of_pruned_commits.mdwn
new file mode 100644
index 0000000000..ecfa8558e1
--- /dev/null
+++ b/doc/forum/reflog_of_pruned_commits.mdwn
@@ -0,0 +1,27 @@
+Hello,
+
+I ran into some issues with one repo (repo X). I didn't konw what to do, so I did several git annex sync on the other repos, and git annex repair on repo X.
+
+Now, git annex sync on repo X gives me:
+
+```
+
+pull repo W/Y/Z/etc.
+Compression automatique du dépôt en tâche de fond pour optimiser les performances.
+Voir "git help gc" pour toute information sur le nettoyage manuel.
+error: Le dernier lancement de gc a rapporté l'erreur suivante. Veuillez corriger
+la cause et supprimer .git/gc.log.
+Le nettoyage automatique n'aura pas lieu jusqu'à ce que le fichier soit supprimé.
+
+warning: reflog of 'refs/heads/git-annex' references pruned commits
+error: Could not read 7bb7bcb765b1fa81c92ac6746fe124da0f22b8b6
+fatal: Failed to traverse parents of commit 6bf9f29be6bcca7b1c0d93d0132c9e402ce433cd
+error: failed to run repack
+
+ok
+
+
+```
+
+What should I do?
+
diff --git a/doc/forum/reflog_of_pruned_commits/comment_1_edb31e8722edc58be7e2593556dc3ddf._comment b/doc/forum/reflog_of_pruned_commits/comment_1_edb31e8722edc58be7e2593556dc3ddf._comment
new file mode 100644
index 0000000000..812d06b204
--- /dev/null
+++ b/doc/forum/reflog_of_pruned_commits/comment_1_edb31e8722edc58be7e2593556dc3ddf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="hugo"
+ avatar="http://cdn.libravatar.org/avatar/950651406c30b9987cdd26060aef034b"
+ subject="Comment"
+ date="2017-08-21T06:21:33Z"
+ content="""
+(just a comment to check \"email replies to me\")
+"""]]
diff --git a/doc/forum/reflog_of_pruned_commits/comment_2_cd0f057a730389509bd12dcaf21e3150._comment b/doc/forum/reflog_of_pruned_commits/comment_2_cd0f057a730389509bd12dcaf21e3150._comment
new file mode 100644
index 0000000000..e43c880e50
--- /dev/null
+++ b/doc/forum/reflog_of_pruned_commits/comment_2_cd0f057a730389509bd12dcaf21e3150._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-08-28T17:03:19Z"
+ content="""
+This does not seem to be a problem. If the warning message is bothering
+you, you could remove the part of the reflog that references the pruned
+commits, or remove the whole reflog.
+"""]]
diff --git a/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src.mdwn b/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src.mdwn
new file mode 100644
index 0000000000..ff9d1b6c7c
--- /dev/null
+++ b/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src.mdwn
@@ -0,0 +1,12 @@
+Total newbie here, so I apologize in advice for asking dumb questions. I did my best to look through the branchable docs, Google, etc to no avail.     
+I'm trying to use git-annex to manage my music collection (on Windows). I added and pushed 669 songs to GitLab from my desktop.
+At this point, my music is on both the first folder and GitLab (worth noting that I still don't know where to find the binaries on GitLab...).      
+      
+Then just as a test, tried to clone the repo and run `git annex sync --content`.      
+      
+I get the following error:       
+`error: dst ref refs/heads/synced/git-annex receives from more than one src.`      
+`error: failed to push some refs to 'git@gitlab.com:repolocation/Songs.git'`      
+      
+I figure it's because the files are both on GitLab and the other folder, but I'm not sure how to proceed.      
+Would appreciate any help, thanks!
diff --git a/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src/comment_1_c805561fa714ff3930742bb330b340c9._comment b/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src/comment_1_c805561fa714ff3930742bb330b340c9._comment
new file mode 100644
index 0000000000..3f4be57a64
--- /dev/null
+++ b/doc/forum/refs__47__heads__47__synced__47__git-annex_receives_from_more_than_one_src/comment_1_c805561fa714ff3930742bb330b340c9._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-09T18:47:17Z"
+ content="""
+This error message is a `git push` error message.
+I've never seen this error before.. 
+
+<http://www.markhneedham.com/blog/2013/06/13/git-having-a-branchtag-with-the-same-name-error-dst-refspec-matches-more-than-one/>
+Shows one way to get into this situation, where a repository somehow has
+a tag with the same name as the branch that is being pushed.
+
+<https://lostechies.com/jasonmeridth/2010/02/27/refspec-matches-more-than-one/>>
+Similarly shows it being a conflict between a tag and a branch;
+this time the tag exists in the local repository.
+
+I guess you've run into some problem like this. If there's an easy way to
+reproduce the problem using just git-annex commands, and not manaul tag
+creation etc, please file a bug report with details.
+"""]]
diff --git a/doc/forum/reinstalled_os__44___cloned_annex__44___does_not_recognize_remote.mdwn b/doc/forum/reinstalled_os__44___cloned_annex__44___does_not_recognize_remote.mdwn
new file mode 100644
index 0000000000..2c437fe359
--- /dev/null
+++ b/doc/forum/reinstalled_os__44___cloned_annex__44___does_not_recognize_remote.mdwn
@@ -0,0 +1,8 @@
+Hi,
+
+I switched distribution and cloned my annex from the backup afterwards. getting the files from my backup worked fine, but i have a remote on an external disk and git-annex keeps saying it's unavailable despite it being there. I have the same username and hostname as on my old system so and the remote repo still has the uuid 3d661c5e-c84e-4902-b52e-decbafadfa4f. The only thing that changed is the path, it's know mounted unter /var/run/media/phaer/95... but a symlinked to the path below did not help. Any suggestions? 
+
+    3d661c5e-c84e-4902-b52e-decbafadfa4f -- phaer@kassiopeia:/media/phaer/9502bc14-b83e-471a-95a8-80ff9072a4ab/annex
+
+
+and thank you for this amazing piece of software.
diff --git a/doc/forum/reinstalled_os__44___cloned_annex__44___does_not_recognize_remote/comment_1_c1962d757dd22f49e774afa13a9862ca._comment b/doc/forum/reinstalled_os__44___cloned_annex__44___does_not_recognize_remote/comment_1_c1962d757dd22f49e774afa13a9862ca._comment
new file mode 100644
index 0000000000..1223b24145
--- /dev/null
+++ b/doc/forum/reinstalled_os__44___cloned_annex__44___does_not_recognize_remote/comment_1_c1962d757dd22f49e774afa13a9862ca._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 1"
+ date="2013-10-21T22:24:35Z"
+ content="""
+It might help if you pasted the actual error message that git-annex shows when you try to use this remote. Along with the part of .git/config that configures this remote.
+
+In general, git-annex does not are if you've reinstalled your OS, moved things around, etc. As long as the git remote's path points to a repository, git-annex will see it and be able to use it.
+"""]]
diff --git a/doc/forum/reinstalled_os__44___cloned_annex__44___does_not_recognize_remote/comment_2_1f0f4a1dc89643cee81ff7199b55e747._comment b/doc/forum/reinstalled_os__44___cloned_annex__44___does_not_recognize_remote/comment_2_1f0f4a1dc89643cee81ff7199b55e747._comment
new file mode 100644
index 0000000000..f38c0c7520
--- /dev/null
+++ b/doc/forum/reinstalled_os__44___cloned_annex__44___does_not_recognize_remote/comment_2_1f0f4a1dc89643cee81ff7199b55e747._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBhQgaA5QrFwT67-Bo0qPIx0HD9roDrso"
+ nickname="Paul"
+ subject="comment 2"
+ date="2013-11-20T11:20:13Z"
+ content="""
+The problem was just a missing git remote. Sorry & thanks
+"""]]
diff --git a/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle.mdwn b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle.mdwn
new file mode 100644
index 0000000000..6a97d38534
--- /dev/null
+++ b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle.mdwn
@@ -0,0 +1,12 @@
+I just released a new app (in beta) for macOS called [git-annex-turtle](https://github.com/andrewringler/git-annex-turtle). It provides badges in finder, context menus and very limited status updates via a menubar icon. **Requires** macOS 10.12 or later.
+
+Badges indicate whether files are present or not, how many copies they have and if they are lacking copies. Context menus (currently very limited) allow for add/get/drop/lock and unlock. A menubar icon gives (currently very limited) feedback on current operations.
+
+The is definitely a preview beta release so there are bound to be bugs. Please report any feature requests or bugs with github issues, by emailing me directly at <a href="mailto:public@andrewringler.com">public@andrewringler.com</a> or posting comments to this thread.
+
+Thanks!
+
+
+Andrew
+
+**[Download git-annex-turtle](https://github.com/andrewringler/git-annex-turtle)**
diff --git a/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_1_58f236c940ca20bfbae53324a530da0d._comment b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_1_58f236c940ca20bfbae53324a530da0d._comment
new file mode 100644
index 0000000000..e9c7f4107b
--- /dev/null
+++ b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_1_58f236c940ca20bfbae53324a530da0d._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-03-09T18:10:11Z"
+ content="""
+Thanks very much for building this. It looks great.
+
+I especially appreciated the notes in DESIGN.md about how it uses git-annex
+interfaces and what is fast/too slow. Please do file todo requests if there
+are interface improvements that git-annex can offer to query for the data
+you need.
+
+I suppose it does not make sense to integrate the code into git-annex,
+as is done for the much simpler Nautilus and Konqueror file
+manager integration. git-annex-turtle is something like 33M large with all
+the assets, and has a significant quantity of source code that I would 
+only get in the way of maintaining.
+
+And it looks like it's easy enough to install it from the zip file.
+But I do wonder if it would make sense for the git-annex.app to bundle
+git-annex-turtle, so users don't need that extra step. What do you think?
+"""]]
diff --git a/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_2_54ba7672150ee32df4d2d92390a960c1._comment b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_2_54ba7672150ee32df4d2d92390a960c1._comment
new file mode 100644
index 0000000000..8c09eb78c5
--- /dev/null
+++ b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_2_54ba7672150ee32df4d2d92390a960c1._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 2"
+ date="2018-03-10T18:33:22Z"
+ content="""
+Thanks for the positive feedback!
+
+>Please do file todo requests if there are interface improvements that git-annex can offer to query for the data you need.
+
+Will do. I think I have most of the queries I need right now. I really wanted to show nice, meaningful icons for folders; I ended up showing some measure of the number of copies of all files contained within folders. This is something I decided to cache in a database since, to my knowledge, neither git nor git-annex tracks folders directly. I don't think it would make sense to cache folder level queries in git-annex anytime soon?
+
+
+>But I do wonder if it would make sense for the git-annex.app to bundle git-annex-turtle, so users don't need that extra step.
+
+Great! Yes, that sounds like an excellent idea! Yes, as you mentioned git-annex-turtle.app is ~30mb with all the icon assets. I believe this is because the icons are uncompressed PDFs exported from Adobe Illustrator, oops. I'll see if I can compress them and get the .app size down. Currently, zipping git-annex-turtle.app brings down the size to ~8mb.
+
+Thanks,
+
+—Andrew
+"""]]
diff --git a/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_3_107d0a3c9de6880d0ee164a651d2c20e._comment b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_3_107d0a3c9de6880d0ee164a651d2c20e._comment
new file mode 100644
index 0000000000..127fb8d8db
--- /dev/null
+++ b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_3_107d0a3c9de6880d0ee164a651d2c20e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="beautiful"
+ date="2018-03-12T13:52:53Z"
+ content="""
+wow, that is absolutely gorgeous. i wish we had the same in linux! it would make git-annex so much simpler to use... but i don't know if contrib plugins can add graphic stuff like that in file manager displays in nautilus/etc?
+
+seems like we're clearly lagging behind when I look at the finder... can't believe we still don't have a proper file manager in linux yet... --[[anarcat]]
+"""]]
diff --git a/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_4_ddb6d671ddd28ba79efce74e41eab7e1._comment b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_4_ddb6d671ddd28ba79efce74e41eab7e1._comment
new file mode 100644
index 0000000000..d1c2e3dd6f
--- /dev/null
+++ b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_4_ddb6d671ddd28ba79efce74e41eab7e1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 4"
+ date="2018-03-12T19:24:56Z"
+ content="""
+Thanks [anarcat](http://git-annex.branchable.com/users/anarcat/)!
+
+[RabbitVCS](http://rabbitvcs.org/) provides Nautilus 3 icons for git, that might be a reasonable starting point for enhanced git-annex icons on Linux. Also, [nautilus-git](https://github.com/bil-elmoussaoui/nautilus-git) is minimal and quite pretty. I don't know what flavor of file manager they were using when they took their screenshots.
+"""]]
diff --git a/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_5_d496549c4f8bf3500e8ac5c2f2ae0d6e._comment b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_5_d496549c4f8bf3500e8ac5c2f2ae0d6e._comment
new file mode 100644
index 0000000000..ed82fa19bd
--- /dev/null
+++ b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_5_d496549c4f8bf3500e8ac5c2f2ae0d6e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-04-04T18:17:02Z"
+ content="""
+I guess what would be helpful is if you can take the current git-annex.app
+and copy its files to a directory and then add in the
+git-annex-turtle.app's files in a way that combines them both.
+I don't currently have an OSX desktop to play with that, but if you can
+show me the changes that need to be made to the file tree in git-annex.app
+to merge turtle into it, I can update the build scripts.
+"""]]
diff --git a/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_6_8b3555fe33da55c01b199efd492951b0._comment b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_6_8b3555fe33da55c01b199efd492951b0._comment
new file mode 100644
index 0000000000..f88587d359
--- /dev/null
+++ b/doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_6_8b3555fe33da55c01b199efd492951b0._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="integrating git-annex-turtle into git-annex"
+ date="2018-04-20T18:24:21Z"
+ content="""
+Ooops…, I missed this comment.
+
+I am not exactly sure what the best approach will be, but I have some thoughts. Yes, I can make an example of a folder structure I think could work well. I'll try to explain all the positives and negatives of various approaches below.
+
+The standard for application installation on the mac is to deliver a dmg that when double-clicked opens a small Finder window that contains the application (.app bundle), a link to /Applications and [a background image with an arrow](https://asmaloney.com/2013/07/howto/packaging-a-mac-os-x-application-using-a-dmg/) hinting that users should drag the .app file onto to the /Applications link (which causes Finder to initiate a copy).
+
+Currently, after installing git-annex from the dmg, when you double-click the git-annex.app folder git-annex-webapp is launched.
+
+1) One approach, to bundling git-annex-turtle would be to place git-annex-turtle inside the git-annex.app folder. That would mean, however, users need to ctrl-click then click `Show Package Contents` then browse the file structure until they find git-annex-turtle, then double-click it to launch it. That would be a bit confusing, and not very Mac-y. This could be slightly mitigated by adding an installer for git-annex that asks users if they want to auto-launch git-annex-turtle on login-in, but then we still have the issue of them not being able to re-launch it if they ever quit it. Also, installers are not very popular on the Mac.
+
+2) Another approach would be for the dmg file to contain a folder that contains two items git-annex.app and git-annex-turtle.app. Users would then drag the entire folder to their /Applications folder. Then git-annex-webapp would be launchable (from Finder) by double-clicking on /Applications/git-annex/git-annex.app, and git-annex-turtle would be launch-able by double-clicking on /Applications/git-annex/git-annex-turtle.app. The biggest drawback with this approach is that it would change all of the absolute paths to the binaries inside git-annex.app.
+
+For example, I currently have the following line in my bash_profile:
+
+    export PATH=/Applications/git-annex.app/Contents/MacOS:$PATH
+
+This would need to change to
+
+    export PATH=/Applications/git-annex/git-annex.app/Contents/MacOS:$PATH
+
+I think we probably don't want to make all users have to update all their paths to git-annex binaries.
+
+This approach, of having a folder with multiple apps is quite rare. Users, really expect their /Applications folder to only contain .app files with nice icons that they can double-click to launch things. I could only find a handful of examples of apps that are doing this (all cross-platform apps): Blender, Supercollider, Unity, Adobe (sometimes), Autodesk.
+
+3) Another approach would be to just include both the existing git-annex.app and git-annex-turtle.app (as they are) in the git-annex.dmg file. Then I could create a nice background image that suggests users should drag both git-annex.app and git-annex-turtle.app to their /Applications folder. Then users would have /Applications/git-annex.app and /Applications/git-annex-turtle.app installed. The main drawback here is that users need to know to drag both files to their /Applications folder, and they are slightly more likely to not always upgrade them, and there is the potential for them to just drag git-annex-turtle to /Applications and not git-annex, and wonder why one doesn't work. Or uninstall git-annex at some point, and then again, wonder why git-annex-turtle no longer works.
+
+Currently I am leaning towards this last option. But, I think 2) could work as well, although it would be unfortunate to break people's paths.
+
+
+Andrew
+"""]]
diff --git a/doc/forum/reliability__47__completeness_of_XMPP_updates.mdwn b/doc/forum/reliability__47__completeness_of_XMPP_updates.mdwn
new file mode 100644
index 0000000000..fc558aad60
--- /dev/null
+++ b/doc/forum/reliability__47__completeness_of_XMPP_updates.mdwn
@@ -0,0 +1,7 @@
+This falls into the category of "noob questions" I think.
+
+The one piece of the git-annex assistant puzzle I've never messed with is XMPP pairing.  I'm wondering how well a pair of repos can keep in sync with each other if their only connection is via XMPP.  Will things go badly if changes are made to one while the other is offline?  Do messages get queued up to deliver when they're both online?  (Or do they get queued on the server side so they can be delivered even if one of them is online, makes changes, then goes offline, and the other one comes online later?)
+
+If some xmpp messages don't go through for whatever reason, will the remotes be able to "catch up" with each other later on and make up for lost time?
+
+Just hoping for a general sense of the limitations of XMPP pairing.   TIA.
diff --git a/doc/forum/reliability__47__completeness_of_XMPP_updates/comment_1_e0f7aa48d54fc0564f41c3a569c723b7._comment b/doc/forum/reliability__47__completeness_of_XMPP_updates/comment_1_e0f7aa48d54fc0564f41c3a569c723b7._comment
new file mode 100644
index 0000000000..d72cad5b97
--- /dev/null
+++ b/doc/forum/reliability__47__completeness_of_XMPP_updates/comment_1_e0f7aa48d54fc0564f41c3a569c723b7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 1"
+ date="2013-07-16T19:27:07Z"
+ content="""
+Both clients have to be online at the same time for XMPP push to work. Once they're able to see each other, they'll sync up, even if they've diverged since the last sync.
+
+If you tend to only have one client or the other online, you should set up a git repo on a ssh server. Then clients will drop off their changes there, and the other one will check it when it comes online. (You don't really need to use XMPP at all in this case.)
+
+The most robust and fast combo is to use XMPP pairing, and also have a git repo on a ssh server. This way, when both clients are online, they'll use XMPP to instantly propagate changes, and when not the server is there to fall back to.
+"""]]
diff --git a/doc/forum/reliability__47__completeness_of_XMPP_updates/comment_2_4e74039a673c16c0163f2cfb406dc4c3._comment b/doc/forum/reliability__47__completeness_of_XMPP_updates/comment_2_4e74039a673c16c0163f2cfb406dc4c3._comment
new file mode 100644
index 0000000000..b4e329441b
--- /dev/null
+++ b/doc/forum/reliability__47__completeness_of_XMPP_updates/comment_2_4e74039a673c16c0163f2cfb406dc4c3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 2"
+ date="2013-07-16T23:36:22Z"
+ content="""
+Thanks, that was exactly the kind of explanation I needed.
+"""]]
diff --git a/doc/forum/reliability__47__completeness_of_XMPP_updates/comment_3_41ade4fe72804b2f06cd4dbf405c1746._comment b/doc/forum/reliability__47__completeness_of_XMPP_updates/comment_3_41ade4fe72804b2f06cd4dbf405c1746._comment
new file mode 100644
index 0000000000..a212dbd092
--- /dev/null
+++ b/doc/forum/reliability__47__completeness_of_XMPP_updates/comment_3_41ade4fe72804b2f06cd4dbf405c1746._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Flo"
+ ip="141.76.46.31"
+ subject="Git repositery?"
+ date="2013-07-19T08:56:04Z"
+ content="""
+I'm not sure to know what you mean with \"git repository on a SSH server\". I tried to use the assistant to add this git synchronization fall-back if XMPP is not available. However, it synchronizes all files too with this new repository. I tried to make it manual, unwanted, etc. But it stills send all my files on the transfer repository on rsync.net. I don't want that...
+"""]]
diff --git a/doc/forum/relying_on_git_for_numcopies.mdwn b/doc/forum/relying_on_git_for_numcopies.mdwn
new file mode 100644
index 0000000000..37b46cf4e7
--- /dev/null
+++ b/doc/forum/relying_on_git_for_numcopies.mdwn
@@ -0,0 +1,47 @@
+**&lt;out-of-date-warning&gt;**The main problems this is supposed to solve are addressed in a different way with [[todo/hidden files]] and the `--fast` option introduced in [[batch check on remote when using copy]], so while this is not technically obsolete, the main reasons for it are gone. --[[chrysn]]**&lt;/out-of-date-warning&gt;**
+
+This is a rough sketch of a modification of git-annex to rely more on git commit semantics. It might be flawed due to my lack of understanding of git-annex internals. --[[chrysn]]
+
+Summary
+=========
+
+Currently, [[location tracking]] is only used for informational purposes unless a repository is [[trust]]ed, in which case there is no checking at all. It is proposed to use the location tracking information as a commitment to keep track of a file until another repository takes over responsibility.
+
+git's semantics for atomic commits are proposed to be used, which makes sure that before files are actually deleted, another repository has accepted the deletion.
+
+Modified git-annex-drop behavior
+==========================
+
+The most important (if not only) git-annex command that is affected by this is `git annex drop`. Currently, for dropping a large number of files, every file is checked with another (or multiple, if so configured) host if it's safe to delete.
+
+The new behavior would be to
+
+* decrement the location tracking counter for all files to be dropped,
+* commit that change,
+* try to push it to at least as many repositories that the numcopies constraints are met,
+* revert if that fails,
+* otherwise really drop the files from the backend.
+
+Unlike explicit checking, this never looks at the remote backend if the file is really present -- otoh, git-annex already relies on the files in the backend to not be touched by anyone but git-annex itself, and git-annex would only drop them if they were derefed and committed, in which case git would not accept the push. (git by itself would accept a merged push, but even if the reverting step failed due to a power outage or similar, git-annex would, before really deleting files from the backend, check again if the numcopies restraint is still met, and revert its own delete commit as the files are still present anyway.)
+
+Implications for trust
+==============
+
+The proposed change also changes the semantics of trust. Trust can now be controlled in a finer-grained way between untrusted and semi-trusted, as best illustrated by a use case:
+
+> Alice takes her netbook with her on a trip through Spain, and will fill most of its disk up with pictures she takes. As she expects to meet some old friends during the first days, she wants to take older pictures with her, which are safely backed up at home, so they can be deleted on demand.
+>
+> She tells her netbook's repository to dereference the old images (but not other parts of the repository she has not copied anywhere yet) and pushes to the server before leaving. When she adds pictures from her camera to the repository, git-annex can now free up space as needed.
+
+Dereferencing could be implemented as `git annex drop --no-rm` (or `move --no-rm`), freeing space is similar to `dropunused`.
+
+A trusted repository with the new semantics would mean that the repository would not accept dropping anything, just as before.
+
+Advantages / Disadvantages
+=====================
+
+The advantage of this proposal is that the round trips required for dropping something could be greatly reduced.
+
+There should also be simplifications in the `git annex drop` command as it doesn't need to take care of locking any more (git should already do that between checking if HEAD is a parent of the pushed commit and replacing HEAD).
+
+Besides being a major change in git-annex (with the requirement to track hosts' git-annex versions for migration, as the new trust system is incompatible with the old one), no disadvantages of that stragegy are known to the author (hoping for discussion below).
diff --git a/doc/forum/relying_on_git_for_numcopies/comment_1_8ad3cccd7f66f6423341d71241ba89fc._comment b/doc/forum/relying_on_git_for_numcopies/comment_1_8ad3cccd7f66f6423341d71241ba89fc._comment
new file mode 100644
index 0000000000..83a908da8c
--- /dev/null
+++ b/doc/forum/relying_on_git_for_numcopies/comment_1_8ad3cccd7f66f6423341d71241ba89fc._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-02-22T18:44:28Z"
+ content="""
+I see the following problems with this scheme:
+
+- Disallows removal of files when disconnected. It's currently safe to force that, as long as
+  git-annex tells you enough other repos are belived to have the file. Just as long as you
+  only force on one machine (say your laptop). With your scheme, if you drop a file while 
+  disconnected, any other host could see that the counter is still at N, because your
+  laptop had the file last time it was online, and can decide to drop the file, and lose the last 
+version.
+
+- pushing a changed counter commit to other repos is tricky, because they're not bare, and 
+  the network topology to get the commit pulled into the other repo could vary.
+
+- Merging counter files issues.  If the counter file doesn't automerge, two repos dropping the same file will conflict. But, if it does automerge, it breaks the counter conflict detection.
+
+- Needing to revert commits is going to be annoying. An actual git revert
+  could probably not reliably be done. It's need to construct a revert
+  and commit it as a new commit. And then try to push that to remotes, and
+  what if *that* push conflicts?
+
+- I do like the pre-removal dropping somewhat as an alternative to
+  trust checking. I think that can be done with current git-annex though,
+  just remove the files from the location log, but keep them in-annex.
+  Dropping a file only looks at repos that the location log says have a
+  file; so other repos can have retained a copy of a file secretly like
+  this, and can safely remove it at any time. I'd need to look into this a bit more to be 100% sure it's safe, but have started [[todo/hidden_files]]. 
+
+- I don't see any reduced round trips. It still has to contact N other
+  repos on drop. Now, rather than checking that they have a file, it needs
+  to push a change to them.
+"""]]
diff --git a/doc/forum/relying_on_git_for_numcopies/comment_2_be6acbc26008a9cb54e7b8f498f2c2a2._comment b/doc/forum/relying_on_git_for_numcopies/comment_2_be6acbc26008a9cb54e7b8f498f2c2a2._comment
new file mode 100644
index 0000000000..d9ce8b50e0
--- /dev/null
+++ b/doc/forum/relying_on_git_for_numcopies/comment_2_be6acbc26008a9cb54e7b8f498f2c2a2._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="comment 2"
+ date="2011-02-23T16:43:59Z"
+ content="""
+i'll comment on each of the points separately, well aware that even a single little leftover issue can show that my plan is faulty:
+
+* force removal: well, yes -- but the file that is currently force-removed on the laptop could just as well be the last of its kind itself. i see the problem, but am not sure if it's fatal (after all, if we rely on out-of-band knowledge when forcing something, we could just as well ask a little more)
+* non-bare repos: pushing is tricky with non-bare repos now just as well; a post-commit hook could auto-accept counter changes. (but pushing causes problems with counters anyway, doesn't it?)
+* merging: i'd have them auto-merge. git-annex will have to check the validity of the current state anyway, and a situation in which a counter-decrementing commit is not a fast-forward one would be reverted in the next step (or upon discovery, in case the next step never took place).
+* reverting: my wording was bad as \"revert\" is already taken in git-lingo. the correct term for what i was thinking of is \"reset\". (as the commit could not be pushed, it would be rolled back completely).
+    * we might have to resort to reverting, though, if the commit has already been pused to a first server of many.
+* [[todo/hidden files]]: yes, this solves pre-removal dropping :-)
+* round trips: it's not the number of servers, it's the number of files (up to 30k in my case). it seems to me that an individual request was made for every single file i wanted to drop (that would be N*M roundtrips for N affected servers and M files, and N roundtrips with git managed numcopies)
+
+all together, it seems to be a bit more complicated than i imagined, although not completely impossible. a combination of [[todo/hidden files]] and maybe a simpler reduction of the number of requests might though achieve the important goals as well.
+"""]]
diff --git a/doc/forum/relying_on_git_for_numcopies/comment_3_43d8e1513eb9947f8a503f094c03f307._comment b/doc/forum/relying_on_git_for_numcopies/comment_3_43d8e1513eb9947f8a503f094c03f307._comment
new file mode 100644
index 0000000000..27076a877f
--- /dev/null
+++ b/doc/forum/relying_on_git_for_numcopies/comment_3_43d8e1513eb9947f8a503f094c03f307._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="relation to [[todo/branching]]"
+ date="2011-02-23T21:48:14Z"
+ content="""
+the non-bare repository issue would go away if this was combined with the \"alternate\" approach to [[todo/branching]]. (with the \"fleshed out proposal\" of branching, this would not work at all for lack of shared commits.)
+"""]]
diff --git a/doc/forum/remembering_state.mdwn b/doc/forum/remembering_state.mdwn
new file mode 100644
index 0000000000..3edc193bce
--- /dev/null
+++ b/doc/forum/remembering_state.mdwn
@@ -0,0 +1,5 @@
+so i am wondering how better to remember the state of a repository.
+
+the use case is this: i have this part of my music collection which i consider to be my "favorites". i would like to have only those on an external hard drive, but also on my portable music player. so i cloned my main music collection to the external hard drive and did `git annex get` on the files i wanted there. now i want to replicate that to the music player - how would i go around doing that? if i clone that repo again, it will all have empty symlinks and i would have to reproduce the same process all over again, which i can script, but it seems a little quirky...
+
+ideas? --[[anarcat]]
diff --git a/doc/forum/remembering_state/comment_1_4a6ac5f50dfa5a17a0f0ccd0c2e7a466._comment b/doc/forum/remembering_state/comment_1_4a6ac5f50dfa5a17a0f0ccd0c2e7a466._comment
new file mode 100644
index 0000000000..bc9a072237
--- /dev/null
+++ b/doc/forum/remembering_state/comment_1_4a6ac5f50dfa5a17a0f0ccd0c2e7a466._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlQeMMI82sfgZ9lim_9GqLkc4fsd0Z3Qt8"
+ nickname="Ronald"
+ subject="comment 1"
+ date="2014-05-14T09:08:22Z"
+ content="""
+I'm still learning git-annex myself, but I think you can make a new branch 'favorites'. Sort out your favorite music and make a checkout on your external HDD and music player. In the walkthrough you can see how that works. 
+"""]]
diff --git a/doc/forum/remembering_state/comment_2_1b02d3713a2986bc027d166589a11c3f._comment b/doc/forum/remembering_state/comment_2_1b02d3713a2986bc027d166589a11c3f._comment
new file mode 100644
index 0000000000..3c3f393a62
--- /dev/null
+++ b/doc/forum/remembering_state/comment_2_1b02d3713a2986bc027d166589a11c3f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkYmMFDdf3GJ9Oba6NCVkzGc4JyB9WavMs"
+ nickname="Xinruo"
+ subject="comment 2"
+ date="2014-05-15T02:07:06Z"
+ content="""
+I think a better solution is to use http://git-annex.branchable.com/tips/metadata_driven_views/
+You can tag the files as favorites, then use get --metadata tag=favorites to get only favorites files.
+"""]]
diff --git a/doc/forum/remembering_state/comment_3_b48775ea1e90b061b084f61a4a9baca5._comment b/doc/forum/remembering_state/comment_3_b48775ea1e90b061b084f61a4a9baca5._comment
new file mode 100644
index 0000000000..2b349527ce
--- /dev/null
+++ b/doc/forum/remembering_state/comment_3_b48775ea1e90b061b084f61a4a9baca5._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-05-15T20:01:14Z"
+ content="""
+While you can certianly use views for this, I tend to do the same with my sound files without view, but just using location tracking info. I have a set of music I'm currently listening to, and want to have more or less the same files on multiple computers as I have on my laptop. With maybe a bit more on some computers with more space. So, I do:
+
+    git annex sync
+    git annex get --in darkstar
+
+Where \"darkstar\" is the name of the repository on my laptop. 
+
+Another nice trick that also takes advantage of the location tracking logs is this to get back some files you dropped temporarily to free up space:
+
+    git annex get --in='here@{yesterday}'
+
+
+"""]]
diff --git a/doc/forum/remembering_state/comment_4_cbebcc6ed4bdae6815c0576475e96f6a._comment b/doc/forum/remembering_state/comment_4_cbebcc6ed4bdae6815c0576475e96f6a._comment
new file mode 100644
index 0000000000..c4bf94390b
--- /dev/null
+++ b/doc/forum/remembering_state/comment_4_cbebcc6ed4bdae6815c0576475e96f6a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="70.83.139.100"
+ subject="comment 4"
+ date="2014-05-21T18:02:51Z"
+ content="""
+i like @yesterday, that's a neat trick that would have basically resolved my problem here. thanks!
+"""]]
diff --git a/doc/forum/remote-specific_meta-data.mdwn b/doc/forum/remote-specific_meta-data.mdwn
new file mode 100644
index 0000000000..04b3919556
--- /dev/null
+++ b/doc/forum/remote-specific_meta-data.mdwn
@@ -0,0 +1,5 @@
+I know we can associate arbitrary [[metadata]] to files. I'd like to be able to sync *remote* specific metadata (say `ip = 10.0.0.1`) fields around. I was originally thinking of shoving this in the description but I am not sure that (a) it gets synced around and (b) it will scale well enough.
+
+Then I thought we could use the key/value storage, but then the keyname would change with metadata changes so maybe that won't work...? Another option I thought of was to just throw stuff in a separate directory in the git-annex branch.
+
+Thoughts? --[[anarcat]]
diff --git a/doc/forum/remote-specific_meta-data/comment_1_179ec4787d93ca4710c5bd448754d404._comment b/doc/forum/remote-specific_meta-data/comment_1_179ec4787d93ca4710c5bd448754d404._comment
new file mode 100644
index 0000000000..5eafa54051
--- /dev/null
+++ b/doc/forum/remote-specific_meta-data/comment_1_179ec4787d93ca4710c5bd448754d404._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-26T16:10:19Z"
+ content="""
+Well, git-annex uses remote.log for such data, and it ignores any
+extraneous fields, so..
+"""]]
diff --git a/doc/forum/remote-specific_meta-data/comment_2_51347629414ac42a6709d00d38ebef9c._comment b/doc/forum/remote-specific_meta-data/comment_2_51347629414ac42a6709d00d38ebef9c._comment
new file mode 100644
index 0000000000..e49e2c7e6e
--- /dev/null
+++ b/doc/forum/remote-specific_meta-data/comment_2_51347629414ac42a6709d00d38ebef9c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="remote.log or uuid.log?"
+ date="2015-03-31T04:29:49Z"
+ content="""
+`remote.log` is present only for \"special remotes\" - could i also use it for... well, \"non-special remotes\"? :) in other words, right now my `remote.log` is empty or even missing in most of the git-annex repos I used, because i don't use the special remotes so much. could i still store information in that file even though it's not being used by git-annex?
+
+or could i just use `uuid.log` instead, which is present for all types of remotes?
+"""]]
diff --git a/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git.mdwn b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git.mdwn
new file mode 100644
index 0000000000..2ebac6bc25
--- /dev/null
+++ b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git.mdwn
@@ -0,0 +1,19 @@
+I'm having a major problem with one of my important annexes.
+
+I'm mounting my "centralized" remote via sshfs. The remote is bare format.
+
+I have tried removing it and adding it, making sure not to have a trailing / just in case. So:
+
+git remote add mybare <pathto>/centralized-bare.git
+
+But no matter what I do, I can't get annex to stop appending "/.git" to the path. So that I see something like this:
+
+$ git annex info
+fatal: not a git repository: '../../../../mnt/sshfs/centralized-bare.git/.git'
+
+  First run: git-annex init
+trusted repositories: 0
+
+It's rendering it invisible and breaking using the centralized remote as that important fulcrum.
+
+Any ideas?
diff --git a/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_1_8333d1f8d773cd114aee8899d51b8fa1._comment b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_1_8333d1f8d773cd114aee8899d51b8fa1._comment
new file mode 100644
index 0000000000..fc8a06395b
--- /dev/null
+++ b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_1_8333d1f8d773cd114aee8899d51b8fa1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="sb-beryllium@6e2c477eac63b823bd315ef8aaf5f93173c1f15b"
+ nickname="sb-beryllium"
+ avatar="http://cdn.libravatar.org/avatar/ef62105380b73ef91d760ec327c14e22"
+ subject="comment 1"
+ date="2023-02-12T11:28:07Z"
+ content="""
+This is a desperately impactful issue. Obviously, for whatever reason, git-annex is deciding that the path to the bare remote is to a \"workarea\", and not a bare .git...
+
+Can someone shed light on the various gates that get to this point? What's being checked in what order (are permissions checked??? is a directory test being applied???)
+
+"""]]
diff --git a/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_2_174f467144d1977c6bc313f6461fc5c6._comment b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_2_174f467144d1977c6bc313f6461fc5c6._comment
new file mode 100644
index 0000000000..e8561cdfd1
--- /dev/null
+++ b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_2_174f467144d1977c6bc313f6461fc5c6._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="sb-beryllium@6e2c477eac63b823bd315ef8aaf5f93173c1f15b"
+ nickname="sb-beryllium"
+ avatar="http://cdn.libravatar.org/avatar/ef62105380b73ef91d760ec327c14e22"
+ subject="comment 2"
+ date="2023-02-13T00:46:46Z"
+ content="""
+Apologies... I just realised that perhaps I shouldn't have had such confidence in the version of git-annex I'm running.
+
+On the system I'm experiencing the issue, I'm running 8.20200226-1. I had assumed that the release of Linux I was running had a a more up-to-date version.
+
+I'm performing some upgrades, and expecting that the later version of git-annex works better. Will comment post all this.
+"""]]
diff --git a/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_3_cea5b2a55fd82e4e42ad045d1bdda0a0._comment b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_3_cea5b2a55fd82e4e42ad045d1bdda0a0._comment
new file mode 100644
index 0000000000..c7401bfb98
--- /dev/null
+++ b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_3_cea5b2a55fd82e4e42ad045d1bdda0a0._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="sb-beryllium@6e2c477eac63b823bd315ef8aaf5f93173c1f15b"
+ nickname="sb-beryllium"
+ avatar="http://cdn.libravatar.org/avatar/ef62105380b73ef91d760ec327c14e22"
+ subject="comment 3"
+ date="2023-02-13T08:33:57Z"
+ content="""
+Unfortunately, the new version is no better:
+
+git-annex version: 8.20210223
+
+I'll see how far I can go with my own debugging for the moment..
+"""]]
diff --git a/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_4_5bd942d53cf0a4978883eed1b61cfe91._comment b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_4_5bd942d53cf0a4978883eed1b61cfe91._comment
new file mode 100644
index 0000000000..cbe7fea6e1
--- /dev/null
+++ b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_4_5bd942d53cf0a4978883eed1b61cfe91._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="sb-beryllium@6e2c477eac63b823bd315ef8aaf5f93173c1f15b"
+ nickname="sb-beryllium"
+ avatar="http://cdn.libravatar.org/avatar/ef62105380b73ef91d760ec327c14e22"
+ subject="Resolved"
+ date="2023-02-13T22:46:47Z"
+ content="""
+After learning rudimentary Haskell, compiling and tracing git-annex, I stumbled on the root cause. And thankfully, it's not in git-annex.
+
+It appears that at some point git introduced the notion of validation of the \"safety\" of git directories.
+
+I first validated what I was seeing from an strace. That chdir() to the remote, and running git config --null --list was returning only the global config, and not the local config with core.bare set to true.
+
+In confusion, thankfully my thoughts turned to git remote as a command that lived exclusively in \"git config\" space, and ran git remote show. When I did, I encountered a \"googleable\" error message:
+
+    fatal: detected dubious ownership in repository at '/mnt/sshfs/centralized-bare.git'
+    To add an exception for this directory, call:
+    
+            git config --global --add safe.directory /mnt/sshfs/centralized-bare.git
+
+And I was off to the races again.
+
+It is a shame that the git config command itself doesn't throw that same error. The silent continuation in this case, was quite fatal to operations.
+
+"""]]
diff --git a/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_5_6863faa0a64ff72abcf82435bfabf7b0._comment b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_5_6863faa0a64ff72abcf82435bfabf7b0._comment
new file mode 100644
index 0000000000..2ace0d996f
--- /dev/null
+++ b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_5_6863faa0a64ff72abcf82435bfabf7b0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-02-14T16:19:33Z"
+ content="""
+Hmm, git-annex dealt with this change to git back in version 10.20220525.
+
+But, it seems it didn't deal with this specific case of a bare repo used as
+a remote. Opened a bug: [[bugs/bare_remote_safe_directory]]
+"""]]
diff --git a/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_6_df69e9d176b14c687098d52dbe3cacd3._comment b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_6_df69e9d176b14c687098d52dbe3cacd3._comment
new file mode 100644
index 0000000000..766cc77e82
--- /dev/null
+++ b/doc/forum/remote_bare_repo_is_invisible_due_to_+__47__.git/comment_6_df69e9d176b14c687098d52dbe3cacd3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="sb-beryllium@6e2c477eac63b823bd315ef8aaf5f93173c1f15b"
+ nickname="sb-beryllium"
+ avatar="http://cdn.libravatar.org/avatar/ef62105380b73ef91d760ec327c14e22"
+ subject="comment 6"
+ date="2023-02-17T01:42:58Z"
+ content="""
+Thank you.
+"""]]
diff --git a/doc/forum/remote_server_client_repositories_are_bare__33____63__.mdwn b/doc/forum/remote_server_client_repositories_are_bare__33____63__.mdwn
new file mode 100644
index 0000000000..21c7568366
--- /dev/null
+++ b/doc/forum/remote_server_client_repositories_are_bare__33____63__.mdwn
@@ -0,0 +1,17 @@
+I've gone through most of the screen casts and lots of documentation,
+but my first attempt produced an unexpected result.
+
+I wanted to use git-annex is a Dropbox-simplistic setting - syncing
+a directory between my notebook (OSX) and my desktop (OpenSUSE 12.3).
+Running the assistant on OSX and adding a "Remote server" repository,
+changing the repository group to client produced a bare repository
+on the desktop.
+
+Am I missing something obvious?
+
+I've tried a few different version of git-annex, most recently
+
+   git-annex version: 4.20130727-g9399845
+   build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+
+but it remains the same.
diff --git a/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_1_234241460f6c75a8376b303b8dd4e882._comment b/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_1_234241460f6c75a8376b303b8dd4e882._comment
new file mode 100644
index 0000000000..41e599c6d4
--- /dev/null
+++ b/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_1_234241460f6c75a8376b303b8dd4e882._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmg8DSRA425Aik2clIuge8Jj-s7VJltsBI"
+ nickname="Tommy"
+ subject="comment 1"
+ date="2013-07-28T06:05:48Z"
+ content="""
+I found a partial answer on http://git-annex.branchable.com/forum/Add_a___34__local__34___remote :
+\"The webapp does not set up remote non-bare repositories because unless the user is comfortable with the cli, nothing is going to keep them up-to-date.\"
+
+So, clearly \"Remote server\" isn't what I want, but my \"desktop\" is headless and using jabber seems a silly complication when I have a perfectly fine ssh connection.  This isn't as trivial as I had expected.
+"""]]
diff --git a/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_2_42dfc382d07af2a4f29c76016084f87c._comment b/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_2_42dfc382d07af2a4f29c76016084f87c._comment
new file mode 100644
index 0000000000..84a2f36d66
--- /dev/null
+++ b/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_2_42dfc382d07af2a4f29c76016084f87c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 2"
+ date="2013-07-30T18:56:00Z"
+ content="""
+Make a non-bare git repository on your server. Run `git annex init` in it. Run `git annex assistant` in it.
+
+Now on your notebook, you can tell the assistant to use a remote ssh server, and point it at that directory. It will see the repository already exists, and use it, rather than making a new bare repository. The assistant daemon you've run on the server will notice when changes are pushed to the directory, and update it. 
+
+You can further set up XMPP, so that the server can tell the notebook if you make any modifications to the server. You can do this by running `git annex webapp --listen=IPADDRESS` on the server, and opening the url it prints out. But this is optional, only needed if you're going to be editing files on the server.
+"""]]
diff --git a/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_3_32bf10cf837db16566dcc99d0b9aaf67._comment b/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_3_32bf10cf837db16566dcc99d0b9aaf67._comment
new file mode 100644
index 0000000000..bf302f7c89
--- /dev/null
+++ b/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_3_32bf10cf837db16566dcc99d0b9aaf67._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkftzaCvV7EDKVDfJhsQZ3E1Vn-0db516w"
+ nickname="Edward"
+ subject="One snag"
+ date="2014-07-28T19:37:04Z"
+ content="""
+I setup a non-bare repo on a server by following the above steps (git init, git annex init, then add it as a Remote Server from elsewhere and combine repos). It worked, but I hit a snag and needed to add another step.
+
+After git init, you're not sitting on any branch yet, and that seems to have prevented the assistant from doing anything to synchronize the working tree on the server. After I did \"git checkout synced/master\", it started working.
+"""]]
diff --git a/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_4_cd04cfaf97f200d5e581b83bb8d018b2._comment b/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_4_cd04cfaf97f200d5e581b83bb8d018b2._comment
new file mode 100644
index 0000000000..5213a7f950
--- /dev/null
+++ b/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_4_cd04cfaf97f200d5e581b83bb8d018b2._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkRW96vF6lsjg57muQ4nPnQqJJUAKGKGzw"
+ nickname="Catalin"
+ subject="Caveat with 'git checkout synced/master'"
+ date="2014-12-26T07:43:18Z"
+ content="""
+There's at least one caveat with the 'git checkout synced/master' workaround. When the local assistant next tries to sync with the remote, it will try to push, and the remote will refuse the push into the currently checked out branch:
+
+[2014-12-26 02:40:10 EST] main: Syncing with nyc.nanobit.org_annex 
+remote: error: refusing to update checked out branch: refs/heads/synced/master        
+remote: error: By default, updating the current branch in a non-bare repository        
+remote: error: is denied, because it will make the index and work tree inconsistent        
+remote: error: with what you pushed, and will require 'git reset --hard' to match        
+remote: error: the work tree to HEAD.        
+remote: error:         
+remote: error: You can set 'receive.denyCurrentBranch' configuration variable to        
+remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into        
+remote: error: its current branch; however, this is not recommended unless you        
+remote: error: arranged to update its work tree to match what you pushed in some        
+remote: error: other way.        
+remote: error:         
+remote: error: To squelch this message and still keep the default behaviour, set        
+remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.        
+To ssh://catalinp@git-annex-nyc.nanobit.org-catalinp_22_annex/~/annex/
+ ! [remote rejected] annex/direct/master -> synced/master (branch is currently checked out)
+"""]]
diff --git a/doc/forum/removing_information_from_special_remote_file.mdwn b/doc/forum/removing_information_from_special_remote_file.mdwn
new file mode 100644
index 0000000000..de740ee330
--- /dev/null
+++ b/doc/forum/removing_information_from_special_remote_file.mdwn
@@ -0,0 +1,8 @@
+I'm working on a project using git-annex and Tahoe as a special remote. I want to encrypt that Tahoe capability for various file(s) (the capability is present in the git-annex branch), so that it is impossible for a malicious actor to access a file. However, due to the union-merge that happens on that branch, no matter what I try, the plain text capability keeps coming back.
+
+How can I either remove an entry from a file in the git-annex branch, or maybe remove all history for a file so that it has nothing to merge against, or otherwise remove the plain-text capability?
+
+This is very similar/same as https://git-annex.branchable.com/forum/removing_remote.log_information_completely/ but hopefully I can get a updated perspective, or any further guidance. Any help at all would be greatly appreciated.
+
+If there's a simple way to modify the git-annex source code to accommodate this, I would be perfectly happy with that solution. Unfortunately I am not well versed in Haskell, but if there was a way to say, for example, ignore *.rmt files when doing the union-merge, that would probably work. I'd be happy with any solution though.
+
diff --git a/doc/forum/removing_information_from_special_remote_file/comment_1_a3c41731dbbcd53715c205e29ab99e4e._comment b/doc/forum/removing_information_from_special_remote_file/comment_1_a3c41731dbbcd53715c205e29ab99e4e._comment
new file mode 100644
index 0000000000..e117af21db
--- /dev/null
+++ b/doc/forum/removing_information_from_special_remote_file/comment_1_a3c41731dbbcd53715c205e29ab99e4e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-06T18:40:54Z"
+ content="""
+Even if you remove the information from the remote log, it would still be
+there in the git history of the file.
+
+The thing to do, then, is to not store those capabilities in git at all.
+
+If you have a use case for using tahoe without storing the capability in
+git, we could talk about implementing that. 
+
+I don't see how it would be useful to store content in tahoe if you can't
+get it back out, so seems that some form of encryption would need to be
+involved. Perhaps it could encrypt it using your gpg key or something?
+"""]]
diff --git a/doc/forum/removing_remote.log_information_completely.mdwn b/doc/forum/removing_remote.log_information_completely.mdwn
new file mode 100644
index 0000000000..0a0e91cd40
--- /dev/null
+++ b/doc/forum/removing_remote.log_information_completely.mdwn
@@ -0,0 +1,9 @@
+in [[forum/remote-specific_meta-data/]], we have learned how to insert our own remote-specific metadata, in remote.log. now, we need a way to remove that data. for some reason, injecting commits in the `git-annex` branch doesn't quite work, because other assistants will overwrite that merge thanks to the [[git-union-merge]] driver.
+
+so far, i have found that it *can* be possible to work around this problem by repeatedly doing commits on the git-annex branch and running `git-annex sync` by hand after. it stumbles and flips around for a while, but eventually does it. it does create nice sparkles in gitk: 
+
+![a tangled mess in gitk](http://i.imgur.com/PD4ne50.png)]
+
+What is the proper way of removing entries from `remote.log`? How about propagating changes to the `synced/git-annex` branch? I can generate commits on `git-annex` using the git-annex index, and on the `git-annex` branch. But how should those changes be propagated to other branches?
+
+Thanks! --[[anarcat]]
diff --git a/doc/forum/removing_remote.log_information_completely/comment_1_033f5b8f2b306c756b3f12e0a9bc6637._comment b/doc/forum/removing_remote.log_information_completely/comment_1_033f5b8f2b306c756b3f12e0a9bc6637._comment
new file mode 100644
index 0000000000..762f1ef4c8
--- /dev/null
+++ b/doc/forum/removing_remote.log_information_completely/comment_1_033f5b8f2b306c756b3f12e0a9bc6637._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-09T19:57:26Z"
+ content="""
+There's no guaranteed way to remove lines from log files on the git-annex
+branch. A union merge can always result in a removed line being added back later.
+
+The thing to do is to add a new line, that has a newer timestamp and
+omits the information you want to remove with new information.
+
+When reading the remote.log, git-annex will look for the line for a remote
+that has the newest timestamp, and use it in preference to older lines.
+"""]]
diff --git a/doc/forum/renaming_directories_not_supported__63__.mdwn b/doc/forum/renaming_directories_not_supported__63__.mdwn
new file mode 100644
index 0000000000..42df24051e
--- /dev/null
+++ b/doc/forum/renaming_directories_not_supported__63__.mdwn
@@ -0,0 +1,45 @@
+I have an annex repository with several of my CDs. They were ripped using MusicBrainz data, causing some directory names to be in Russian. This is something I wanted to change.
+
+I have cloned this repository on my laptop, where I wanted to implement the change.
+
+When I do a git mv Пётр_Ильич_Чайковский P_I_Tchaikovsky on my laptop, I can commit the change. git annex sync also doesn't object
+
+However, the original directory remains on the origin repository, and the renamed directory is not present.
+
+Am I doing something wrong?
+
+
+
+    [master e112a02] Renamed Tchaikovsky directory.
+     9 files changed, 0 insertions(+), 0 deletions(-)
+     rename "\320\237\321\221\321\202\321\200_\320\230\320\273\321\214\320\270\321\207_\320\247\320\260\320\271\320\272\320\276\320\262\321\201\320\272\320\270\320\271/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/04 Variations on a Rococo Theme, Op. 33_ Moderato quasi Andante.flac" => "P_I_Tchaikovsky/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/04 Variations on a Rococo Theme, Op. 33_ Moderato quasi Andante.flac" (100%)
+     rename "\320\237\321\221\321\202\321\200_\320\230\320\273\321\214\320\270\321\207_\320\247\320\260\320\271\320\272\320\276\320\262\321\201\320\272\320\270\320\271/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/05 Variations on a Rococo Theme, Op. 33_ Tema. Moderato semplice.flac" => "P_I_Tchaikovsky/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/05 Variations on a Rococo Theme, Op. 33_ Tema. Moderato semplice.flac" (100%)
+     rename "\320\237\321\221\321\202\321\200_\320\230\320\273\321\214\320\270\321\207_\320\247\320\260\320\271\320\272\320\276\320\262\321\201\320\272\320\270\320\271/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/06 Variations on a Rococo Theme, Op. 33_ Variazione I. Tempo del Tema.flac" => "P_I_Tchaikovsky/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/06 Variations on a Rococo Theme, Op. 33_ Variazione I. Tempo del Tema.flac" (100%)
+     rename "\320\237\321\221\321\202\321\200_\320\230\320\273\321\214\320\270\321\207_\320\247\320\260\320\271\320\272\320\276\320\262\321\201\320\272\320\270\320\271/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/07 Variations on a Rococo Theme, Op. 33_ Variazione II. Tempo del Tema.flac" => "P_I_Tchaikovsky/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/07 Variations on a Rococo Theme, Op. 33_ Variazione II. Tempo del Tema.flac" (100%)
+     rename "\320\237\321\221\321\202\321\200_\320\230\320\273\321\214\320\270\321\207_\320\247\320\260\320\271\320\272\320\276\320\262\321\201\320\272\320\270\320\271/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/08 Variations on a Rococo Theme, Op. 33_ Variazione III. Andante sostenuto.flac" => "P_I_Tchaikovsky/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/08 Variations on a Rococo Theme, Op. 33_ Variazione III. Andante sostenuto.flac" (100%)
+     rename "\320\237\321\221\321\202\321\200_\320\230\320\273\321\214\320\270\321\207_\320\247\320\260\320\271\320\272\320\276\320\262\321\201\320\272\320\270\320\271/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/09 Variations on a Rococo Theme, Op. 33_ Variazione IV. Andante grazioso.flac" => "P_I_Tchaikovsky/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/09 Variations on a Rococo Theme, Op. 33_ Variazione IV. Andante grazioso.flac" (100%)
+     rename "\320\237\321\221\321\202\321\200_\320\230\320\273\321\214\320\270\321\207_\320\247\320\260\320\271\320\272\320\276\320\262\321\201\320\272\320\270\320\271/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/10 Variations on a Rococo Theme, Op.,33_ Variazione V. Allegro moderato.flac" => "P_I_Tchaikovsky/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/10 Variations on a Rococo Theme, Op.,33_ Variazione V. Allegro moderato.flac" (100%)
+     rename "\320\237\321\221\321\202\321\200_\320\230\320\273\321\214\320\270\321\207_\320\247\320\260\320\271\320\272\320\276\320\262\321\201\320\272\320\270\320\271/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/11 Variations on a Rococo Theme, Op. 33_ Variazione VI. Andante.flac" => "P_I_Tchaikovsky/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/11 Variations on a Rococo Theme, Op. 33_ Variazione VI. Andante.flac" (100%)
+     rename "\320\237\321\221\321\202\321\200_\320\230\320\273\321\214\320\270\321\207_\320\247\320\260\320\271\320\272\320\276\320\262\321\201\320\272\320\270\320\271/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/12 Variations on a Rococo Theme, Op. 33_ Variazione VII e Coda. Allegro vivo.flac" => "P_I_Tchaikovsky/Dvo\305\231\303\241k_ Cellokonzert _ Tschaikowsky_ Rokoko-Variationen/12 Variations on a Rococo Theme, Op. 33_ Variazione VII e Coda. Allegro vivo.flac" (100%)
+    frederik@freo:~/Music$ git annex sync
+    commit  ok
+    pull A20 
+    remote: Counting objects: 83, done.
+    remote: Compressing objects: 100% (74/74), done.
+    remote: Total 83 (delta 2), reused 0 (delta 0)
+    Unpacking objects: 100% (83/83), done.
+    From ssh://A20:/mnt/usb1/Music
+       5c0bae2..72eb235  git-annex  -> A20/git-annex
+    ok
+    (merging A20/git-annex into git-annex...)
+    (Recording state in git...)
+    push A20 
+    Counting objects: 284, done.
+    Delta compression using up to 4 threads.
+    Compressing objects: 100% (257/257), done.
+    Writing objects: 100% (284/284), 21.06 KiB | 0 bytes/s, done.
+    Total 284 (delta 153), reused 0 (delta 0)
+    To ssh://A20:/mnt/usb1/Music
+       0a391ea..ad7251c  git-annex -> synced/git-annex
+       4af0061..e112a02  master -> synced/master
+    ok
diff --git a/doc/forum/renaming_directories_not_supported__63__/comment_1_94bb80e70fe619c6f1913b4a233e47ec._comment b/doc/forum/renaming_directories_not_supported__63__/comment_1_94bb80e70fe619c6f1913b4a233e47ec._comment
new file mode 100644
index 0000000000..8d51caa25c
--- /dev/null
+++ b/doc/forum/renaming_directories_not_supported__63__/comment_1_94bb80e70fe619c6f1913b4a233e47ec._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2015-06-05T07:21:44Z"
+ content="""
+Looks like you missed a step from your output (difficult to be sure because you don't show a full transcript showing a rename and it not being present in the other repo).
+
+Have you updated the remote repo where the changes aren't present? 'git annex sync' or 'git annex merge'?
+
+If you made the changes in repoA and ran sync there, it pushes the changes to repoB, but it can't update repoB's working directory remotely (restriction from git). You have to update it locally to see them.
+
+First few paragraphs of [sync](http://git-annex.branchable.com/sync/) mention this.
+
+So if you run sync or merge in the remote repository, you should see your changes.
+"""]]
diff --git a/doc/forum/renaming_directories_not_supported__63__/comment_2_4bd6386dbd5cb907a9c85fb240265ee5._comment b/doc/forum/renaming_directories_not_supported__63__/comment_2_4bd6386dbd5cb907a9c85fb240265ee5._comment
new file mode 100644
index 0000000000..4896dd0f29
--- /dev/null
+++ b/doc/forum/renaming_directories_not_supported__63__/comment_2_4bd6386dbd5cb907a9c85fb240265ee5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="frederik@ffbea6a549cb3f460d110386c0f634c1ddc6a68a"
+ nickname="frederik"
+ subject="comment 2"
+ date="2015-06-05T07:41:55Z"
+ content="""
+Thanks, I had missed that part.
+"""]]
diff --git a/doc/forum/repair_stuck_on_ls-tree_command.mdwn b/doc/forum/repair_stuck_on_ls-tree_command.mdwn
new file mode 100644
index 0000000000..3ff9f56c57
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command.mdwn
@@ -0,0 +1,54 @@
+Hi,
+
+I have run the git annex repair command on one of my repositories and it has been running for 38h hours now. I have monitored the process and its sons with htop and it seems that git annex repair is stuck.
+
+It repeatedly launches the following command: 
+
+    git --git-dir=/home/vincent/photos2/.git --work-tree=/home/vincent/photos2 ls-tree --full-tree -z -r -- 5fe5193e079631c0ceac0688ae0a6c1636491b61
+
+I have tried to execute it by hand and it produces a lot of output. I have redirected it into some file in order to count the content produced by this command.
+
+    vincent@berlioz:~/photos2/.git$ git --git-dir=/home/vincent/photos2/.git --work-tree=/home/vincent/photos2 ls-tree --full-tree -z -r -- 5fe5193e079631c0ceac0688ae0a6c1636491b61 > /tmp/ls-tree
+    vincent@berlioz:/tmp$ wc ls-tree 
+           0   232525 11611220 ls-tree
+
+Could this cause some troubles to git-annex ? Maybe my repository is just too big and it demands some time to deal with the whole thing?
+
+Before doing the git annex repair command I have tried to delete a distant annex (hosted on a raspberry pi, running an arm raspbian) from this one, using the git annex webapp website. Since it was kind of stuck I asked webapp to shutdown. I ran git annex repair for some time. It looked like stuck. I stopped it, then tried git fsck. It ran well. I tried git annex fsck, it took all my RAM and swap. The process was eating 14 Giga bytes of memory. I tried git gc and the same memory problem occured. I ran git annex repair again and it has been running for 38 hours now. I am lost. Please help.
+
+    vincent@berlioz:~$ LANG=C apt-cache policy git-annex
+    git-annex:
+      Installed: 5.20141125
+      Candidate: 5.20141125
+      Package pin: 5.20141125
+      Version table:
+     *** 5.20141125 950
+            400 http://ftp.fr.debian.org/debian/ testing/main amd64 Packages
+             50 http://ftp.fr.debian.org/debian/ unstable/main amd64 Packages
+            100 /var/lib/dpkg/status
+         3.20120629 950
+            900 http://ftp.fr.debian.org/debian/ wheezy/main amd64 Packages
+
+    vincent@berlioz:~/photos2$ du -sh .
+    152G	.
+
+Info gathered from another client annex:
+
+    vincent@tigrou:/mnt/mars/images/photos2$ git annex info
+    repository mode: indirect
+    trusted repositories: 0
+    semitrusted repositories: 11
+        8<------------skipped repositories list------------->8
+    untrusted repositories: 1
+    	a357bb9e-7a9d-4112-b74c-13707e2c7f85 -- vincent@rhett:~/photos [gateway]
+    transfers in progress: none
+    available local disk space: 945.91 gigabytes (+1 megabyte reserved)
+    bad keys size: 368 bytes (clean up with git-annex unused)
+    local annex keys: 76070
+    local annex size: 383.91 gigabytes
+    annexed files in working tree: 59117
+    size of annexed files in working tree: 319.73 gigabytes
+    bloom filter size: 16 mebibytes (15.2% full)
+    backend usage: 
+            SHA256E: 101902
+            SHA256: 33285
diff --git a/doc/forum/repair_stuck_on_ls-tree_command/comment_10_791c50f8a2284b704e34cacf15637341._comment b/doc/forum/repair_stuck_on_ls-tree_command/comment_10_791c50f8a2284b704e34cacf15637341._comment
new file mode 100644
index 0000000000..3058cbaa08
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command/comment_10_791c50f8a2284b704e34cacf15637341._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="vho"
+ subject="comment 10"
+ date="2014-12-18T10:27:07Z"
+ content="""
+This one should work:
+https://www.dropbox.com/s/t7b406wm6m3vm6c/photos2.tar.xz.gpg?dl=0
+
+    $ md5sum photos2.tar.xz.gpg
+    df2b9bde3d1ad23d9f3c4247d2f5b21a  photos2.tar.xz.gpg
+    $ sha1sum photos2.tar.xz.gpg
+    cac6f8c07a1d95fb48e3d9aa0f4699a2c77c00d598  photos2.tar.xz.gpg
+
+"""]]
diff --git a/doc/forum/repair_stuck_on_ls-tree_command/comment_11_1d951126a9633b206dffbc77bfc65f6a._comment b/doc/forum/repair_stuck_on_ls-tree_command/comment_11_1d951126a9633b206dffbc77bfc65f6a._comment
new file mode 100644
index 0000000000..a569fcbdff
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command/comment_11_1d951126a9633b206dffbc77bfc65f6a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2015-02-09T21:13:28Z"
+ content="""
+Finally got back to this. I downloaded the file.
+
+You may be able to fix your repository by running `git annex forget`
+
+I guess this is the same problem described in
+[[bugs/git-annex_branch_shows_commit_with_looong_commitlog]]
+"""]]
diff --git a/doc/forum/repair_stuck_on_ls-tree_command/comment_12_1a844376915c6a40ad03c2b9b599367b._comment b/doc/forum/repair_stuck_on_ls-tree_command/comment_12_1a844376915c6a40ad03c2b9b599367b._comment
new file mode 100644
index 0000000000..397214c6dc
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command/comment_12_1a844376915c6a40ad03c2b9b599367b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="vho"
+ subject="comment 12"
+ date="2015-11-30T15:23:22Z"
+ content="""
+Sorry I didn't see your answer before!
+
+Thanks! Fortunately I kept a copy of the defective repository. I am going to test this =)
+
+"""]]
diff --git a/doc/forum/repair_stuck_on_ls-tree_command/comment_1_9555c925516ce3be83b4dd17d587100f._comment b/doc/forum/repair_stuck_on_ls-tree_command/comment_1_9555c925516ce3be83b4dd17d587100f._comment
new file mode 100644
index 0000000000..f2c7a67d28
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command/comment_1_9555c925516ce3be83b4dd17d587100f._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="vho"
+ subject="Update"
+ date="2014-12-01T15:47:23Z"
+ content="""
+It seems I could sort things of.
+
+I have run git annex sync from another annex. It took 30 minutes but could synchronize with the slow annex. Then I launched git annex sync on the slow annex (the one which seemed to had troubles with the repair command). It took 278 minutes, used all my ram and swap, but managed to end successfully.
+
+I launched git annex sync again today, another 279 minutes:
+
+    vincent@berlioz:~/photos2$ time git annex sync
+    commit  ok
+    pull tigrou
+    Error reading response length from authentication socket.
+    Compression automatique du dépôt en tâche de fond pour optimiser les performances.
+    Voir \"git help gc\" pour toute information sur le nettoyage manuel.
+    ok
+    pull gateway
+    Compression automatique du dépôt en tâche de fond pour optimiser les performances.
+    Voir \"git help gc\" pour toute information sur le nettoyage manuel.
+    ok
+    push gateway
+    fatal: The remote end hung up unexpectedly
+     
+      Pushing to gateway failed.
+      
+      (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
+    failed
+    git-annex: sync: 1 failed
+    
+    real    279m27.760s
+    user    7m15.159s
+    sys     3m4.340s
+
+I will try to do some git gc.
+"""]]
diff --git a/doc/forum/repair_stuck_on_ls-tree_command/comment_2_17327b90d09f8dd0bf7f359c16cf69dd._comment b/doc/forum/repair_stuck_on_ls-tree_command/comment_2_17327b90d09f8dd0bf7f359c16cf69dd._comment
new file mode 100644
index 0000000000..fa046da218
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command/comment_2_17327b90d09f8dd0bf7f359c16cf69dd._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2014-12-02T17:24:30Z"
+ content="""
+According to the ls-tree output you posted, the git tree object
+5fe5193e079631c0ceac0688ae0a6c1636491b61 is somehow 11 mb
+in size, which seems quite enormous, since a git tree object
+is just a list of files in a directory in the repo.
+
+Does your repository actually contain a directory that big? 
+(This seems unlikely, since git annex info says there are only 59117 annxed
+files.)
+
+What is in the output of `git-ls-tree 5fe5193e079631c0ceac0688ae0a6c1636491b61`
+that is so enormous?
+
+I think you need to figure this out to get anywhere, because it's quite
+strange. Or, if you're willing to put the git repository someplace
+(minus .git/annex/), I could take a look at it.
+"""]]
diff --git a/doc/forum/repair_stuck_on_ls-tree_command/comment_2_2ae0c755f5a0bf5c93afe5e081fcb915._comment b/doc/forum/repair_stuck_on_ls-tree_command/comment_2_2ae0c755f5a0bf5c93afe5e081fcb915._comment
new file mode 100644
index 0000000000..da2f90797a
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command/comment_2_2ae0c755f5a0bf5c93afe5e081fcb915._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="vho"
+ subject="Still stuck"
+ date="2014-12-02T09:59:20Z"
+ content="""
+vincent@berlioz:~/photos2$ git config --global pack.packSizeLimit 100m
+vincent@berlioz:~/photos2$ git config --global pack.windowMemory 100m
+vincent@berlioz:~/photos2$ git config --global pack.threads 1
+vincent@berlioz:~/photos2$ time git gc
+error: pack-objects died of signal 9
+error: failed to run repack
+
+real    21m29.451s
+user    1m31.414s
+sys     0m9.141s
+
+:(
+
+"""]]
diff --git a/doc/forum/repair_stuck_on_ls-tree_command/comment_4_875f9e36a94264a92eb097e9f4bda444._comment b/doc/forum/repair_stuck_on_ls-tree_command/comment_4_875f9e36a94264a92eb097e9f4bda444._comment
new file mode 100644
index 0000000000..77f7a8535a
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command/comment_4_875f9e36a94264a92eb097e9f4bda444._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="vho"
+ subject="comment 4"
+ date="2014-12-02T21:11:39Z"
+ content="""
+Thanks for your time and help.
+
+http://hobeika.fr/~vincent/git/ls-tree
+
+    vincent@berlioz:~$ wc -l /tmp/ls-tree 
+    4103 /tmp/ls-tree
+
+    vincent@berlioz:~/photos2$ du -sh --exclude=.git/annex
+    863M	.
+
+I'll have to find some place to store that.
+
+Yet I don't think my repository holds such a big directory since there are no problems on other annexes.
+
+"""]]
diff --git a/doc/forum/repair_stuck_on_ls-tree_command/comment_5_d5c29dc4ea49542f7053bf2e83e0f07f._comment b/doc/forum/repair_stuck_on_ls-tree_command/comment_5_d5c29dc4ea49542f7053bf2e83e0f07f._comment
new file mode 100644
index 0000000000..5af49a7e44
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command/comment_5_d5c29dc4ea49542f7053bf2e83e0f07f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnPgn611P6ym5yyL0BS8rUzO0_ZKRldMt0"
+ nickname="Samuel"
+ subject="Not so big tree"
+ date="2014-12-03T07:36:22Z"
+ content="""
+The output of the ls-tree command suggests this tree is the git-annex branch at some point in time.
+
+I tried on my photos annex to ls-tree the git-annex branch and got.
+
+    $ git ls-tree -r --full-tree git-annex | wc
+    156405  625620 23685538
+
+My git-annex tree is about 22Mib in size, that means twice bigger than yours (no
+dumb joke intended) and I don't suffer such problem.
+
+"""]]
diff --git a/doc/forum/repair_stuck_on_ls-tree_command/comment_6_061770159851c0f06a962937dff035b9._comment b/doc/forum/repair_stuck_on_ls-tree_command/comment_6_061770159851c0f06a962937dff035b9._comment
new file mode 100644
index 0000000000..5f73e65cf0
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command/comment_6_061770159851c0f06a962937dff035b9._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="vho"
+ subject="Trying to make git gc pass with a huge swap"
+ date="2014-12-11T16:52:16Z"
+ content="""
+I have created a 100 GB swap file and ran git gc again.
+It ate my 8 GB of RAM + 38 GB of swap. It ended successfully:
+
+    vincent@berlioz:~/photos2$ time git gc --aggressive
+    Décompte des objets: 2263783, fait.
+    Compression des objets: 100% (2253014/2253014), fait.
+    Écriture des objets: 100% (2263783/2263783), fait.
+    Total 2263783 (delta 1567807), reused 284965 (delta 0)
+    Suppression des objets dupliqués: 100% (256/256), fait.
+    Vérification de la connectivité: 2263783, fait.
+    
+    real	110m18.565s
+    user	37m38.225s
+    sys	3m23.457s
+
+Yet the following git annex sync didn't do better than previous ones and took 285 minutes to complete.
+
+I am going to check my hard disk drive to see if there aren't any third party problem.
+
+    vincent@berlioz:~/photos2$ du -sh --exclude=.git/annex
+    510M	.
+
+Yet it shrank by 300 MB.
+
+"""]]
diff --git a/doc/forum/repair_stuck_on_ls-tree_command/comment_7_5d9e5fd148d5f9e918ad818e07009d69._comment b/doc/forum/repair_stuck_on_ls-tree_command/comment_7_5d9e5fd148d5f9e918ad818e07009d69._comment
new file mode 100644
index 0000000000..b27b503773
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command/comment_7_5d9e5fd148d5f9e918ad818e07009d69._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="vho"
+ subject="update"
+ date="2014-12-18T00:43:22Z"
+ content="""
+Hi,
+
+I have uploaded the repository to:
+http://dl.free.fr/bczxhyOhy
+
+You can decrypt it with your gpg key. It weights 200 Mo.
+
+Moreover when I try to run git annex whereis on files present only on the defective annex from another annex I get the following error:
+
+    $ git annex whereis IMG_4701.JPG
+    whereis IMG_4701.JPG (0 copies) failed
+    git-annex: whereis: 1 failed
+
+I guess the defective annex could not completely synchronize with the others.
+
+I also tried to look at the git tree with gitk --all.
+Well there seems to be a lot of commit with message update (recovery from race)
+I am forced to kill gitk because it starts lagging a lot.
+
+Hopefully you will be able to provide me some hints on how to resolve this issue.
+
+Best regards
+-- 
+vho
+"""]]
diff --git a/doc/forum/repair_stuck_on_ls-tree_command/comment_8_726c9a887b7df1833d7aef3bdce50517._comment b/doc/forum/repair_stuck_on_ls-tree_command/comment_8_726c9a887b7df1833d7aef3bdce50517._comment
new file mode 100644
index 0000000000..f79b16f198
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command/comment_8_726c9a887b7df1833d7aef3bdce50517._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="vho"
+ subject="(recovery from race)"
+ date="2014-12-18T00:46:09Z"
+ content="""
+git show 7dc2be23ddb9bda2edc0f01d4bbec2fdb5216763 seems quite abnormal.
+"""]]
diff --git a/doc/forum/repair_stuck_on_ls-tree_command/comment_9_163cdd18380a13aaa13d68d516af1e30._comment b/doc/forum/repair_stuck_on_ls-tree_command/comment_9_163cdd18380a13aaa13d68d516af1e30._comment
new file mode 100644
index 0000000000..f0d02075b3
--- /dev/null
+++ b/doc/forum/repair_stuck_on_ls-tree_command/comment_9_163cdd18380a13aaa13d68d516af1e30._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="vho"
+ subject="failed upload"
+ date="2014-12-18T09:18:14Z"
+ content="""
+It seems the upload failed at some point. I am going to share it somewhere else
+"""]]
diff --git a/doc/forum/replacing_a_locked_file_without_unlocking_first.mdwn b/doc/forum/replacing_a_locked_file_without_unlocking_first.mdwn
new file mode 100644
index 0000000000..377f119abb
--- /dev/null
+++ b/doc/forum/replacing_a_locked_file_without_unlocking_first.mdwn
@@ -0,0 +1 @@
+If I want to replace a locked file with new content, rather than edit the existing content, is it ok to skip the [[`git-annex-unlock`|git-annex-unlock]]/[[`git-annex-lock`|git-annex-lock]] steps?  If I just remove the symlink to the annex, create a new regular file in its place, then [[`git-annex-add`|git-annex-add]] the new file and commit, things seem to work fine.   Does this create some inconsistency that can come back to bite me later, or is this supported usage?
diff --git a/doc/forum/replacing_a_locked_file_without_unlocking_first/comment_1_637598d027bc6194dad89d63aea511d4._comment b/doc/forum/replacing_a_locked_file_without_unlocking_first/comment_1_637598d027bc6194dad89d63aea511d4._comment
new file mode 100644
index 0000000000..41227e1886
--- /dev/null
+++ b/doc/forum/replacing_a_locked_file_without_unlocking_first/comment_1_637598d027bc6194dad89d63aea511d4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-03-20T17:42:06Z"
+ content="""
+I can't think of any problems, as the end-result is the same. ´git annex unlock´ also just removes the symlink and copies the (old)file into it's place. There's no state about this kept anywhere else. So whether you unlock the file and then replace it, or directly replace the symlink with the new file, ´git annex add´ afterwards sees exactly the same state of the worktree.
+"""]]
diff --git a/doc/forum/replacing_a_locked_file_without_unlocking_first/comment_2_b3ee1b086bf0add1e5f286635c02959a._comment b/doc/forum/replacing_a_locked_file_without_unlocking_first/comment_2_b3ee1b086bf0add1e5f286635c02959a._comment
new file mode 100644
index 0000000000..81ab7f1219
--- /dev/null
+++ b/doc/forum/replacing_a_locked_file_without_unlocking_first/comment_2_b3ee1b086bf0add1e5f286635c02959a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="keeping state re: unlocked files?"
+ date="2021-03-21T18:29:13Z"
+ content="""
+\"There's no state about this kept anywhere else\" -- not sure that's accurate: e.g. git-annex keeps track of inodes of unlocked files.   Maybe @joeyh can clarify?
+
+
+"""]]
diff --git a/doc/forum/replacing_a_locked_file_without_unlocking_first/comment_3_ed4137413812467d67dd84aa5fde6263._comment b/doc/forum/replacing_a_locked_file_without_unlocking_first/comment_3_ed4137413812467d67dd84aa5fde6263._comment
new file mode 100644
index 0000000000..b61cf21404
--- /dev/null
+++ b/doc/forum/replacing_a_locked_file_without_unlocking_first/comment_3_ed4137413812467d67dd84aa5fde6263._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-03-22T17:16:14Z"
+ content="""
+It's not even necessary to delete the symlink, you can just
+rename the new version of the file over it.
+
+Unlocking the file is only necessary if you want to edit it in place.
+
+Unlocking a file does add a little bit of overhead. Mostly making
+a copy of it that is not needed when you're just going to overwrite it.
+Also the annex pointer gets added as a git object (which will get garbage
+collected eventually) and some minor things get stored to git-annex's
+internal database to keep track of it.
+"""]]
diff --git a/doc/forum/replacing_a_locked_file_without_unlocking_first/comment_4_8aa708a1bf76e452ef12c35999774791._comment b/doc/forum/replacing_a_locked_file_without_unlocking_first/comment_4_8aa708a1bf76e452ef12c35999774791._comment
new file mode 100644
index 0000000000..19bfa768fe
--- /dev/null
+++ b/doc/forum/replacing_a_locked_file_without_unlocking_first/comment_4_8aa708a1bf76e452ef12c35999774791._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="replacing a locked file with new content"
+ date="2021-03-22T19:50:25Z"
+ content="""
+Then I guess [[todo/auto-lock_files_after_one_edit]] isn't needed?
+"""]]
diff --git a/doc/forum/replacing_a_union_mount_with_git-annex.mdwn b/doc/forum/replacing_a_union_mount_with_git-annex.mdwn
new file mode 100644
index 0000000000..cb98ab5620
--- /dev/null
+++ b/doc/forum/replacing_a_union_mount_with_git-annex.mdwn
@@ -0,0 +1,18 @@
+I currently use mergerfs, it gives me a simple union mount of a bunch of drives, for example:
+/media/*/datahoard/  
+
+( * meaning several stand alone drives )
+
+I wanted to use git-annex instead, so I went to one of those drives:
+
+cd /media/strange/
+
+and created a git annex repo, then if I go to another drive
+
+cd /media/charm/ 
+
+and attempt to clone the repo, it complains because /datahoard/ already exists (and isn't empty)
+
+I want to import all of my single drives into git-annex and have the resulting directory structure be the same as the original union mount, is this possible and how would I go about doing it?
+
+Thanks
diff --git a/doc/forum/replacing_a_union_mount_with_git-annex/comment_1_b627a4028d98f1a137c4af85918f49c0._comment b/doc/forum/replacing_a_union_mount_with_git-annex/comment_1_b627a4028d98f1a137c4af85918f49c0._comment
new file mode 100644
index 0000000000..0df9b28613
--- /dev/null
+++ b/doc/forum/replacing_a_union_mount_with_git-annex/comment_1_b627a4028d98f1a137c4af85918f49c0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2020-12-05T13:07:31Z"
+ content="""
+I recommend you to first init each repo on each drive separately and add it's files with `git annex add .; git annex sync`, then add each other as a remote and run `git annex sync`, which will merge the file-trees together. <br>
+I guess you don't want each drive to contain the content of each file, so you should add all drives to a group and set a [[preferred-content|git-annex-preferred-content]] expression such as  `git annex groupwanted drives \"(not copies=drives:1) or present\"` and then set that on all drives by running `git annex group here drives; git annex wanted here groupwanted` on all drives. This way, `git annex sync --content` won't copy the content of each file to each drive. <br>
+You might also want to run `git annex config --set annex.dotfiles true` before adding any files or else dotfiles will be added to git directly. <br>
+"""]]
diff --git a/doc/forum/repo_corruption_in_usb_external_drive.mdwn b/doc/forum/repo_corruption_in_usb_external_drive.mdwn
new file mode 100644
index 0000000000..989126837e
--- /dev/null
+++ b/doc/forum/repo_corruption_in_usb_external_drive.mdwn
@@ -0,0 +1,41 @@
+I'm sorry to ask this again, but I'm not being able to find my previous message regarding this issue. I'm finding very hard to find older posts in forums. Is there a way to search for all my posted messages?
+Anyway, after some automount problems (changed mount point name), my usb repo (direct) ended in a weird state.
+See for instance the screenshot: <http://picpaste.com/git-annex-problem-eZvOl90y.jpg>
+
+In addition making a git-annex info gives the following:
+
+ * repository mode: direct
+ * trusted repositories: error: refs/heads/master does not point to a valid object!
+ * error: refs/heads/synced/git-annex does not point to a valid object!
+ * error: refs/heads/synced/master does not point to a valid object!
+ * error: refs/remotes/sapo/annex/direct/master does not point to a valid object!
+ * error: refs/remotes/sapo/git-annex does not point to a valid object!
+ * error: refs/remotes/sapo/master does not point to a valid object!
+ * error: refs/synced/1912d5a7-3929-47f0-8e25-a071d7079cc4/git-annex does not point to a valid object!
+ * error: refs/synced/1912d5a7-3929-47f0-8e25-a071d7079cc4/master does not point to a valid object!
+ * error: refs/heads/master does not point to a valid object!
+ * error: refs/heads/synced/git-annex does not point to a valid object!
+ * error: refs/heads/synced/master does not point to a valid object!
+ * error: refs/remotes/sapo/annex/direct/master does not point to a valid object!
+ * error: refs/remotes/sapo/git-annex does not point to a valid object!
+ * error: refs/remotes/sapo/master does not point to a valid object!
+ * error: refs/synced/1912d5a7-3929-47f0-8e25-a071d7079cc4/git-annex does not point to a valid object!
+ * error: refs/synced/1912d5a7-3929-47f0-8e25-a071d7079cc4/master does not point to a valid object!
+ * fatal: index file smaller than expected
+ * git-annex: failed to read sha from git write-tree
+
+
+What should I do? delete the usb repo and start again. Thank god this is just a trial.
+
+What happens if a file gets corrupted. Lets say it is corrupted in repo A, and fine in repo B. Will the good copy be overridden?
+
+git-repair takes a long time and seems to be stuck there, or maybe it just takes a long time (10Gb repo). Is this normal?
+    > git-annex repair
+    Running git fsck ...
+    Initialized empty Git repository in /tmp/tmprepo.1/.git/
+    Trying to recover missing objects from remote sapo.
+    Unpacking all pack files.
+    Unpacking objects: 100% (348848/348848), done.
+
+
+Thanks in advance.
diff --git a/doc/forum/repo_corruption_in_usb_external_drive/comment_1_d9122bb0cc3551d92877c299a25b9c9e._comment b/doc/forum/repo_corruption_in_usb_external_drive/comment_1_d9122bb0cc3551d92877c299a25b9c9e._comment
new file mode 100644
index 0000000000..ff325983d3
--- /dev/null
+++ b/doc/forum/repo_corruption_in_usb_external_drive/comment_1_d9122bb0cc3551d92877c299a25b9c9e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-15T18:50:29Z"
+ content="""
+It's normal for git-repair to take a long time.
+
+git-annex uses checksums to detect if a file gets corrupted.
+"""]]
diff --git a/doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction.mdwn b/doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction.mdwn
new file mode 100644
index 0000000000..0b66c848ee
--- /dev/null
+++ b/doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction.mdwn
@@ -0,0 +1,7 @@
+I have a repo on two hosts. One host is my laptop which is configured as "manual" repo due to limited disk space and the other host is my NAS as "full backup" repo. My laptop connects via SSH to the NAS.
+
+Strange thing is, syncing looks good. New files created on either side lead to a transfer. However, it doesn't show changes on the NAS that have been triggered on the notebook. For example, folders are missing and I can't see changes in files on the NAS which have been modified and synced from the laptop.
+
+I suspect a problem being stuck with some old branch. Unfortunately, I have little to know knowledge to git commands. :-(
+
+Any idea on how to troubleshoot the issue?
diff --git a/doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction/comment_1_412c319a1610b447fcf372584c2bb15c._comment b/doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction/comment_1_412c319a1610b447fcf372584c2bb15c._comment
new file mode 100644
index 0000000000..ebac42c49a
--- /dev/null
+++ b/doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction/comment_1_412c319a1610b447fcf372584c2bb15c._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="torpidus"
+ avatar="http://cdn.libravatar.org/avatar/997fb77747b008a26383426ae6561368"
+ subject="comment 1"
+ date="2018-09-12T19:05:40Z"
+ content="""
+possible found a first trace. the committer on the NAS side crashes. log file tells:
+
+    [2018-09-12 20:54:19.423764064] Committer: Adding ___git-an..ed_on_NAS
+    add ___git-annex_file_created_on_NAS ok
+    [2018-09-12 20:54:19.524746614] Committer: committing 1 changes
+    [2018-09-12 20:54:19.524993706] Committer: Committing changes to git
+    (recording state in git...)
+    [2018-09-12 20:54:19.590762812] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+    [2018-09-12 20:54:19.857623683] process done ExitSuccess
+    [2018-09-12 20:54:19.85896977] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2018-09-12 20:54:19.880377072] process done ExitSuccess
+    [2018-09-12 20:54:19.880645044] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/master\"]
+    [2018-09-12 20:54:20.836749623] process done ExitSuccess
+    [2018-09-12 20:54:20.837005176] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"write-tree\"]
+    [2018-09-12 20:54:21.296523156] process done ExitSuccess
+    [2018-09-12 20:54:21.304290499] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"rev-parse\",\"1469f15a8f89aae0e9b582e141e4e31f0c0ea31f:\"]
+    [2018-09-12 20:54:21.615407387] process done ExitSuccess
+    [2018-09-12 20:54:21.61567249] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"commit-tree\",\"0ec03203b806a3125bb6677c363897b346473aab\",\"--no-gpg-sign\",\"-p\",\"1469f15a8f89aae0e9b582e141e4e31f0c0ea31f\"]
+    [2018-09-12 20:54:21.952881183] process done ExitSuccess
+    [2018-09-12 20:54:21.953184061] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"update-ref\",\"refs/heads/master\",\"b15389e29d1853771a4993954a297d5dea99b21d\"]
+    [2018-09-12 20:54:22.263498786] process done ExitSuccess
+    [2018-09-12 20:54:22.26375159] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2018-09-12 20:54:22.297865786] process done ExitSuccess
+    [2018-09-12 20:54:22.306865822] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/master\"]
+    [2018-09-12 20:54:22.808817784] process done ExitSuccess
+    [2018-09-12 20:54:22.809135542] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"synced/master\",\"refs/heads/master\"]
+    [2018-09-12 20:54:23.32085476] process done ExitSuccess
+    [2018-09-12 20:54:23.321141703] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"master\",\"refs/heads/master\"]
+    fatal: Cannot force update the current branch.
+    [2018-09-12 20:54:23.339070508] process done ExitFailure 128
+    Committer crashed: failed to update refs/heads/master
+    [2018-09-12 20:54:23.343355069] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2018-09-12 20:54:23.343600554] Committer: warning Committer crashed: failed to update refs/heads/master
+    [2018-09-12 20:54:23.36031901] process done ExitSuccess
+    [2018-09-12 20:54:23.360576051] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/master\"]
+    [2018-09-12 20:54:23.68816538] process done ExitSuccess
+    [2018-09-12 20:54:23.690946926] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+    [2018-09-12 20:54:23.710158388] process done ExitSuccess
+    [2018-09-12 20:54:23.71041453] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/master\"]
+    [2018-09-12 20:54:23.993586343] process done ExitSuccess
+    [2018-09-12 20:54:23.994052834] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/master..refs/heads/synced/master\",\"--pretty=%H\",\"-n1\"]
+    [2018-09-12 20:54:24.276305404] process done ExitSuccess
+"""]]
diff --git a/doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction/comment_2_c10d614039b82c5be289e8e34bc70f86._comment b/doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction/comment_2_c10d614039b82c5be289e8e34bc70f86._comment
new file mode 100644
index 0000000000..3dc63e78db
--- /dev/null
+++ b/doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction/comment_2_c10d614039b82c5be289e8e34bc70f86._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-09-12T19:35:54Z"
+ content="""
+	[2018-09-12 20:54:23.321141703] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"master\",\"refs/heads/master\"]
+	fatal: Cannot force update the current branch.
+
+Good spotting. This problem was reported by some people 
+[back in 2013](forum/Can_Not_Sync_to_Git_Repo),
+but not since then. They were all using direct mode, and I see you are
+too.
+
+But, as far as I can see, current git-annex *never* runs "git branch -f".
+
+So, I think you may have an old version of git-annex there..
+"""]]
diff --git a/doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction/comment_3_4fec14b132bea863b58aa07e03fc31cc._comment b/doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction/comment_3_4fec14b132bea863b58aa07e03fc31cc._comment
new file mode 100644
index 0000000000..3f2d36e1e9
--- /dev/null
+++ b/doc/forum/repos_syncs_but_fails_to_show_files_in_one_direction/comment_3_4fec14b132bea863b58aa07e03fc31cc._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="torpidus"
+ avatar="http://cdn.libravatar.org/avatar/997fb77747b008a26383426ae6561368"
+ subject="comment 3"
+ date="2018-09-16T18:45:15Z"
+ content="""
+Thanks Joey,
+after your comment, I decided to migrate the repo's contents to a new one in v6 format. However, I run into several other issues. I wished there was a live support that I can pay with coffee or beer... :-) Instead, I try to figure around the issues by myself, hopefully not spamming too much here into this forum. :-(
+
+BTW, thank you so much for the effort you have put into git-annex!
+"""]]
diff --git a/doc/forum/reserving_space_with_directory_special_remotes.mdwn b/doc/forum/reserving_space_with_directory_special_remotes.mdwn
new file mode 100644
index 0000000000..fea762c397
--- /dev/null
+++ b/doc/forum/reserving_space_with_directory_special_remotes.mdwn
@@ -0,0 +1,2 @@
+Can diskreserve be done with directory special remotes?
+Where should such per directory remote setting be put?
diff --git a/doc/forum/reserving_space_with_directory_special_remotes/comment_1_cd17b624704d93b51931023f69573323._comment b/doc/forum/reserving_space_with_directory_special_remotes/comment_1_cd17b624704d93b51931023f69573323._comment
new file mode 100644
index 0000000000..83ef649ea3
--- /dev/null
+++ b/doc/forum/reserving_space_with_directory_special_remotes/comment_1_cd17b624704d93b51931023f69573323._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 1"
+ date="2013-07-10T23:50:53Z"
+ content="""
+Not currently supported. I've added a todo: [[todo/free_space_checking_for_local_special_remotes]]
+"""]]
diff --git a/doc/forum/reserving_space_with_directory_special_remotes/comment_2_877ca1be23d1484a8a30cdaeb6630053._comment b/doc/forum/reserving_space_with_directory_special_remotes/comment_2_877ca1be23d1484a8a30cdaeb6630053._comment
new file mode 100644
index 0000000000..c34052ae3c
--- /dev/null
+++ b/doc/forum/reserving_space_with_directory_special_remotes/comment_2_877ca1be23d1484a8a30cdaeb6630053._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 2"
+ date="2013-07-10T23:56:08Z"
+ content="""
+I was looking at git-annex git and saw this and thought it might be supported.
+
+commit 5cc76098ca7b702772ccf37a47f03da088148003
+Author: Joey Hess <joey@kitenet.net>
+Date:   Fri Apr 20 16:24:44 2012 -0400
+
+    Directory special remotes now check annex.diskreserve.
+
+"""]]
diff --git a/doc/forum/reserving_space_with_directory_special_remotes/comment_3_65910eeaf3c6fcfd03f22c2957293232._comment b/doc/forum/reserving_space_with_directory_special_remotes/comment_3_65910eeaf3c6fcfd03f22c2957293232._comment
new file mode 100644
index 0000000000..245849c5f8
--- /dev/null
+++ b/doc/forum/reserving_space_with_directory_special_remotes/comment_3_65910eeaf3c6fcfd03f22c2957293232._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 3"
+ date="2013-07-11T16:17:36Z"
+ content="""
+Shows what I know! It is supported. Repurposed the bug report to allow configuring a different diskreserve for the remote than the main annex.diskreserve..
+"""]]
diff --git a/doc/forum/retrieving_previous_versions.mdwn b/doc/forum/retrieving_previous_versions.mdwn
new file mode 100644
index 0000000000..7626b7935b
--- /dev/null
+++ b/doc/forum/retrieving_previous_versions.mdwn
@@ -0,0 +1,7 @@
+Hi,
+
+This might be a stupid question, but I did not find any information about it.
+Can I retrieve previous versions of a file?
+Let's say, I wanna do a "git annex get file", but considering a specific commit id. Is it possible? Are all the versions of the files kept inside .git/annex/objects?
+
+Thanks!
diff --git a/doc/forum/retrieving_previous_versions/comment_1_a4e83f688d4ec9177e7bf520f12ed26d._comment b/doc/forum/retrieving_previous_versions/comment_1_a4e83f688d4ec9177e7bf520f12ed26d._comment
new file mode 100644
index 0000000000..ab2ecee317
--- /dev/null
+++ b/doc/forum/retrieving_previous_versions/comment_1_a4e83f688d4ec9177e7bf520f12ed26d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-04-24T21:14:15Z"
+ content="""
+To get to a specific version of a file, you need to have a tag or a branch that includes that version of the file. Check out the branch and `git annex get $file`. 
+
+(Of course, even without a tag or branch, old file versions are retained, unless dropped with `unused`/`dropunused`.
+So you could even `git checkout $COMMITID`.)
+"""]]
diff --git a/doc/forum/retrieving_previous_versions/comment_2_e9251f66154e49a77be661c4b4918e18._comment b/doc/forum/retrieving_previous_versions/comment_2_e9251f66154e49a77be661c4b4918e18._comment
new file mode 100644
index 0000000000..04d7b8e6f5
--- /dev/null
+++ b/doc/forum/retrieving_previous_versions/comment_2_e9251f66154e49a77be661c4b4918e18._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlbKgUeSjtEVC2PoXZsOEcQqTDwI52fsb8"
+ nickname="John"
+ subject="what is stored?"
+ date="2014-11-25T20:57:29Z"
+ content="""
+I have an image 'logo.jpg' that is 100kb.  I am using indirect mode.
+I add the logo to the annex; my understanding is that the file contents is stored in .git/annex/....
+
+I do more work in Photoshop to improve logo.jpg.  Now, I have a new version of 'logo.jpg' that is 150kb.
+I add this new version of logo.jpg to the annex.
+
+Does the .git/annex area now contain two instances of the logo.jpg contents, one for the 100kb and one for the 150kb, with metadata pointing to each?
+
+
+"""]]
diff --git a/doc/forum/retrieving_previous_versions/comment_3_5b0ca6fbc000727bf78f5fc4ba34b91a._comment b/doc/forum/retrieving_previous_versions/comment_3_5b0ca6fbc000727bf78f5fc4ba34b91a._comment
new file mode 100644
index 0000000000..e8497dbbb4
--- /dev/null
+++ b/doc/forum/retrieving_previous_versions/comment_3_5b0ca6fbc000727bf78f5fc4ba34b91a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2014-12-01T22:30:16Z"
+ content="""
+Yes, both versions of the file are stored in `.git/annex/objects`,
+unless you move them to some other repository, or unless
+you use `git annex dropunused` to delete the old version.
+"""]]
diff --git a/doc/forum/root_assistant__63__.mdwn b/doc/forum/root_assistant__63__.mdwn
new file mode 100644
index 0000000000..54b8729440
--- /dev/null
+++ b/doc/forum/root_assistant__63__.mdwn
@@ -0,0 +1,3 @@
+How safe (or not) is it to run the assistant as root?
+
+If not safe, what would be a good way to sync directories like /usr/local ?
diff --git a/doc/forum/root_assistant__63__/comment_1_fccab2e36d393f420d0fa23958e6a9d2._comment b/doc/forum/root_assistant__63__/comment_1_fccab2e36d393f420d0fa23958e6a9d2._comment
new file mode 100644
index 0000000000..2fd418d564
--- /dev/null
+++ b/doc/forum/root_assistant__63__/comment_1_fccab2e36d393f420d0fa23958e6a9d2._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-17T21:41:27Z"
+ content="""
+I would not recommend running the assistant as root. Any security issue
+would escalate the root access; any bug could result in some root level
+damage to system.
+
+Of course, I don't know of any such security issues or bugs. If I did, I'd
+be fixing them.
+
+On my system, /usr/local is managed by group staff. It seems much safer to
+make the assistant be run by some non-root user who is in the staff group.
+"""]]
diff --git a/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__.mdwn b/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__.mdwn
new file mode 100644
index 0000000000..2a22d6ee78
--- /dev/null
+++ b/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__.mdwn
@@ -0,0 +1,13 @@
+When trying to setup an rsync.net repo I always get the following error:
+
+Permission denied, please try again.
+Permission denied, please try again.
+Received disconnect from 114.xxx.xxx.xxx: 2: Too many authentication failures for 2*****
+
+I can ssh into the account without any problems and couldn't find anything, which would have helped me any further.
+Any ideas? Is the problem sitting in front of the computer? Is it a bug?
+
+Thanks.
+David
+
+This is happening on Mavericks (10.9)
diff --git a/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_1_7754e2cfb72b034effe8642c1b3e593e._comment b/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_1_7754e2cfb72b034effe8642c1b3e593e._comment
new file mode 100644
index 0000000000..d29f6482c3
--- /dev/null
+++ b/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_1_7754e2cfb72b034effe8642c1b3e593e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn_3tllXjSmtgm__aGr9Z4gVNFgJgGyJ30"
+ nickname="David Alan"
+ subject="comment 1"
+ date="2014-04-02T15:58:57Z"
+ content="""
+This problem also exists, when connecting to other ssh remote servers.
+The error msg would be:
+
+ Failed to ssh to the server. Transcript: Permission denied, please try again. Received disconnect from 80.xxx.xxx.xxx: 2: Too many authentication failures for ssh-xxxxxx-git-annex-assist 
+"""]]
diff --git a/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_2_04e1da4352ef9f9be90253ea726e5f24._comment b/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_2_04e1da4352ef9f9be90253ea726e5f24._comment
new file mode 100644
index 0000000000..3181c4fe01
--- /dev/null
+++ b/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_2_04e1da4352ef9f9be90253ea726e5f24._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 2"
+ date="2014-04-02T19:41:29Z"
+ content="""
+What version of git-annex?
+
+Do you have ssh-askpass installed?
+
+You might try running git webapp from a terminal, in case ssh is unable to prompt for the password in a window using ssh-askpass.
+"""]]
diff --git a/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_3_84aceb9a9d3e5bd14c044861f47e3b9d._comment b/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_3_84aceb9a9d3e5bd14c044861f47e3b9d._comment
new file mode 100644
index 0000000000..ef70eea48a
--- /dev/null
+++ b/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_3_84aceb9a9d3e5bd14c044861f47e3b9d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn_3tllXjSmtgm__aGr9Z4gVNFgJgGyJ30"
+ nickname="David Alan"
+ subject="comment 3"
+ date="2014-04-03T00:31:14Z"
+ content="""
+I'm running Version: 5.20140318-gdcf93d0. Do I have to install a ssh-askpass manually? I only found one thread referring to ssh-askpass, but didn't really know what to do with that information. So, no I don't have it installed as far as I know... _I_ never did anyway...
+
+Do I need it? Did I miss something in the docs?
+"""]]
diff --git a/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_4_2cd17d01edeb230197865e6ea0884de0._comment b/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_4_2cd17d01edeb230197865e6ea0884de0._comment
new file mode 100644
index 0000000000..bfb4c2d74a
--- /dev/null
+++ b/doc/forum/rsync.net__58___Too_many_authentication_failures_for___42____42____42____42____42__/comment_4_2cd17d01edeb230197865e6ea0884de0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="216.145.95.162"
+ subject="comment 4"
+ date="2014-05-19T16:46:55Z"
+ content="""
+I suggest you upgrade to yesterday's release. It moves ssh password prompting during repository setup into a field in the webapp, so should avoid this class of problems.
+"""]]
diff --git a/doc/forum/rsync_asking_for_an_unknown_password.mdwn b/doc/forum/rsync_asking_for_an_unknown_password.mdwn
new file mode 100644
index 0000000000..1126c31eab
--- /dev/null
+++ b/doc/forum/rsync_asking_for_an_unknown_password.mdwn
@@ -0,0 +1,60 @@
+Hello,
+
+I am on OS X, using version 5.20140613.  I installed using brew.
+
+I have a really simple example where I'm trying to use local rsync to test transfer between two repos.  It keeps asking me for a password over and over.  I do not know what password it is.
+
+I'm literally doing just this:
+
+    $ cd annex-tests
+    $ mkdir target
+    $ mkdir source
+    $ cat > source/text
+    hi this is a test
+    $ cd source
+    $ git init
+    Initialized empty Git repository in /Users/me/Documents/annex-tests/source/.git/
+    $ git annex init
+    init  ok
+    (Recording state in git...)
+    $ git annex initremote rsync-login type=rsync rsyncurl=me@localhost:/Users/me/Documents/annex-tests/target encryption=none
+    initremote rsync-login ok
+    (Recording state in git...)
+    $ git annex describe rsync-login "test rsync url with a login"
+    describe rsync-login ok
+    (Recording state in git...)
+    $ git annex add text 
+    add text ok
+    (Recording state in git...)
+    $ git annex sync rsync-login --content
+    commit  ok
+    copy text copy text (checking rsync-login...) Password:
+    Password:
+    Password:
+    Password:
+    Password:
+
+I try a blank password, I try my login password, I tried 'none' (the encryption type), I try everything..  no dice
+
+So right off the bat let me explain a few things.
+
+1 -  Why not use rsa keys?  Because I was having the exact same problem and I wanted to make it even easier and use login/password
+
+2 -  Why not use the webapp since a few forum posts say you can set passwords in there?  because my annex doesn't seem to recognize the command.
+
+    $ git annex webapp
+    git-annex: unknown command webapp
+
+3 -  I verified my rsync command/url appears ok by doing the following.  The password for that command is as expected, it is my username password:
+
+    $ cat > test2
+    hi test
+    $ rsync test2 me@localhost:/Users/me/Documents/annex-tests/target
+    Password:
+    $ cat /Users/me/Documents/annex-tests/target/test2
+    hi test
+
+
+Any help will be appreciated!
+
+
diff --git a/doc/forum/rsync_asking_for_an_unknown_password/comment_1_f23d1c04a27625089eaef5b4bb7f8456._comment b/doc/forum/rsync_asking_for_an_unknown_password/comment_1_f23d1c04a27625089eaef5b4bb7f8456._comment
new file mode 100644
index 0000000000..b761838721
--- /dev/null
+++ b/doc/forum/rsync_asking_for_an_unknown_password/comment_1_f23d1c04a27625089eaef5b4bb7f8456._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-11T18:41:32Z"
+ content="""
+Re brew not being built with support for the webapp, I suggest you file a bug on brew about this. IIRC they were, or were planning to include the webapp in the build. They may have lost track of that.
+
+Now, what does rsyncurl=me@localhost:/Users/me/Documents/annex-tests/target say? It says to use rsync with the \"url\" me@localhost:/Users/me/Documents/annex-tests/target. What does rsync do with that url? It tries to ssh into localhost, as user \"me\". There's no magic here. I don't know why your login password isn't working, but you can verify by passing --debug to git-annex that it just runs rsync with the url you've given it.
+
+BTW, are you sure you want to use a rsync special remote at all, rather than a regular git remote using ssh?
+"""]]
diff --git a/doc/forum/rsync_asking_for_an_unknown_password/comment_2_ce4b399fdb2f04e30bd8a951994f1c80._comment b/doc/forum/rsync_asking_for_an_unknown_password/comment_2_ce4b399fdb2f04e30bd8a951994f1c80._comment
new file mode 100644
index 0000000000..494aaa2359
--- /dev/null
+++ b/doc/forum/rsync_asking_for_an_unknown_password/comment_2_ce4b399fdb2f04e30bd8a951994f1c80._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3JJvaarUKd7xShCMze_kpHVcuCzFrWTI"
+ nickname="Lucas"
+ subject="comment 2"
+ date="2014-07-15T16:18:01Z"
+ content="""
+Well I got the password issue straightened out (was me, don't ask).
+
+Both the rsync and git via ssh are working well, thanks!
+"""]]
diff --git a/doc/forum/rsync_into_annex_without_overwriting_links__63__.mdwn b/doc/forum/rsync_into_annex_without_overwriting_links__63__.mdwn
new file mode 100644
index 0000000000..cba8ebc9e4
--- /dev/null
+++ b/doc/forum/rsync_into_annex_without_overwriting_links__63__.mdwn
@@ -0,0 +1,13 @@
+Does anybody know if it's possible to rsync files into an annex folder without constantly overwriting already annexed files?  I know that the `-L` option will de-reference links on the source side, but I don't see any option for doing the same on the target side. 
+
+I have two machines -- alpha and beta. Alpha doesn't know anything about git annex, but knows how to rsync. I have a folder on alpha that I regularly sync over to beta with: 
+
+```
+rsync -av folder/ beta:/.../annex/folder
+``` 
+
+That way I know that I can eventually safely delete any material in the folder on alpha because it's been backed up/archived to my annex. The problem is, every time I add the files into the annex on beta, they get replaced with symlinks, which wouldn't be a problem except for the fact that now the next time I run the rsync command all of the files get retransmitted because they don't match the symlinks over on beta. This doesn't cause a problem on the git annex side, but it significantly slows down the rsync process. 
+
+Is this a case for an rsync remote? (I haven't really figured out special remotes yet.) Or is there a typical workflow on the git annex side that I could be using to fix this (like `import` rather than `add`)?
+
+Thanks! 
diff --git a/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_1_baa5351a0653838cfbf5f194f6252bcc._comment b/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_1_baa5351a0653838cfbf5f194f6252bcc._comment
new file mode 100644
index 0000000000..0b12dcf95b
--- /dev/null
+++ b/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_1_baa5351a0653838cfbf5f194f6252bcc._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="dscheffy@c203b7661ec8c1ebd53e52627c84536c5f0c9026"
+ nickname="dscheffy"
+ avatar="http://cdn.libravatar.org/avatar/62a3a0bf0e203e3746eedbe48fd13f6d"
+ subject="How do I `man` annex config options?"
+ date="2020-12-17T10:39:40Z"
+ content="""
+Right after posting this last night I came across [this](https://git-annex.branchable.com/forum/How_to_prevent_copies_on_a_single_device_and_use_only_hardlinks/) forum entry, which led me to the tip on how to create a cache annex, which eventually led me to a little more detail on the `annex.hardlink` and `annex.thin` options. 
+
+It sounds like they may kind of be what I'm looking for, but I'm not sure how to find more details (doc) on how to use them or specifically what they do. They aren't listed in supported options when I run (on v6.2):
+
+```
+git annex help config
+```
+
+I google `git annex.hardlink` and `git annex.thin`, but those just point me to bugs or forums or tips that refer to the settings. 
+
+Are these annex wide settings? (that seems to be the case). Is it possible to apply them at a folder level? Am I maybe just missing the point of lock/unlock?
+
+I'll keep looking and run some experiments on my own.
+
+Thanks again!
+"""]]
diff --git a/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_2_598cc6e65f57e941be1319255e66a55f._comment b/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_2_598cc6e65f57e941be1319255e66a55f._comment
new file mode 100644
index 0000000000..4b208be911
--- /dev/null
+++ b/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_2_598cc6e65f57e941be1319255e66a55f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 2"
+ date="2020-12-17T16:06:44Z"
+ content="""
+> How do I `man` annex config options?
+
+The options are listed in the `man git-annex` output (which is also
+available at <https://git-annex.branchable.com/git-annex/>).
+"""]]
diff --git a/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_3_d765f93511e0ba446f54f3ad30e91e6f._comment b/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_3_d765f93511e0ba446f54f3ad30e91e6f._comment
new file mode 100644
index 0000000000..5a0372ca92
--- /dev/null
+++ b/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_3_d765f93511e0ba446f54f3ad30e91e6f._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 3"
+ date="2020-12-17T17:41:35Z"
+ content="""
+> Is this a case for an rsync remote? (I haven't really figured out
+> special remotes yet.)  Or is there a typical workflow on the git annex
+> side that I could be using to fix this (like `import` rather than
+> `add`)?
+
+I think conceptually that's a good fit.  You could set
+`importtree=yes` with the special remote and ingest changes with `git
+annex import` on beta's side.  However, the rsync special remote
+doesn't support `importtree` yet.
+
+https://git-annex.branchable.com/todo/import_tree_from_rsync_special_remote/
+
+In your followup comment, you mention unlocked files.  That would get
+you around the link problem.  You could call `rsync` with `--checksum`
+to limit what is transferred, though that might be expensive depending
+on how big your files are.
+
+> Are [the annex.hardlink and annex.thin options] annex wide settings?
+> (that seems to be the case). Is it possible to apply them at a
+> folder level?
+
+You can set then at the repository level in the repo's .git/config.
+
+"""]]
diff --git a/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_4_62cf96d62228b52bf7dd52eab0b94f67._comment b/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_4_62cf96d62228b52bf7dd52eab0b94f67._comment
new file mode 100644
index 0000000000..f61165767e
--- /dev/null
+++ b/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_4_62cf96d62228b52bf7dd52eab0b94f67._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="dscheffy@c203b7661ec8c1ebd53e52627c84536c5f0c9026"
+ nickname="dscheffy"
+ avatar="http://cdn.libravatar.org/avatar/62a3a0bf0e203e3746eedbe48fd13f6d"
+ subject="comment 4"
+ date="2020-12-17T18:14:16Z"
+ content="""
+Oh boy -- or should I say, oh \"`man`\"... Now I feel like a bit of an idiot for not checking the actual high level man pages... Thanks for that tip. 
+
+I did some experimenting and noticed another thing that I hadn't noticed -- although my binary version is v6.20180227 my annexes were all using the v5 index. That came as a bit of a surprise. Once I upgraded my annex to v6 the annex.thin settings started working. 
+
+As for rsync, I had tried the `-c` (`--checksum`) option, but it wasn't dereferencing the links on the target side, so the files still registered as different (at least I think I tried this, but I may go back and check again, because I was doing a lot of different things...) Nevermind, I just checked my history and I never actually tried it -- I had been using 
+
+```
+rsync -n -v -r -c --delete ai2/ beta:/media/winston/library/lectures/coursera2/ai2/
+```
+
+to try to confirm that the contents of the two folders matched so that I'd know I could safely delete my local copy, but that didn't work because of the links. I didn't add the `-L` option until I reversed the direction and ran the command from the server side with `alpha` as the target.
+
+Thanks for all the help -- this should work well enough for my stage folder issue, but it also solves a separate problem that I'd been struggling with for making my photos available to a self hosted photo webserver tool that I was trying out (photoprism). It can't currently handle symlinks and my local drive was getting filled up with all the extra copies of my photos directory tree!
+
+"""]]
diff --git a/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_5_40e4e9fe7d301b5e75140136d0132860._comment b/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_5_40e4e9fe7d301b5e75140136d0132860._comment
new file mode 100644
index 0000000000..d797576390
--- /dev/null
+++ b/doc/forum/rsync_into_annex_without_overwriting_links__63__/comment_5_40e4e9fe7d301b5e75140136d0132860._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 5"
+ date="2020-12-17T19:05:12Z"
+ content="""
+> As for rsync, I had tried the -c (--checksum) option, but it wasn't
+> dereferencing the links on the target side
+
+Just to clarify: My comment was in the context of unlocked files (in
+v6+ repos).  In that case, symlinks aren't used: the content is kept
+in the working tree (and a pointer file is tracked by git).
+
+Also, since it sounds like you may want all files to be unlocked, you
+might want to look into `git annex adjust --unlock` to enter an
+adjusted with all files in an unlocked state.
+
+> it also solves a separate problem that I'd been struggling with for
+> making my photos available to a self hosted photo webserver tool
+> that I was trying out (photoprism). It can't currently handle
+> symlinks [...]
+
+FWIW, if you don't need importing for this use case, I think using
+`git annex export` with an rsync special remote configured with
+`exporttree=yes` would work well.
+"""]]
diff --git a/doc/forum/rsync_over_ssh__63__.mdwn b/doc/forum/rsync_over_ssh__63__.mdwn
new file mode 100644
index 0000000000..9c0c9add63
--- /dev/null
+++ b/doc/forum/rsync_over_ssh__63__.mdwn
@@ -0,0 +1,2 @@
+[Walkthrough](http://git-annex.branchable.com/walkthrough/using_ssh_remotes/) says that when using ssh remotes rsync is used for transfering files. Is rsync used via ssh or unsecure?
+-- Michael K.
diff --git a/doc/forum/rsync_over_ssh__63__/comment_1_ee21f32e90303e20339e0a568321bbbe._comment b/doc/forum/rsync_over_ssh__63__/comment_1_ee21f32e90303e20339e0a568321bbbe._comment
new file mode 100644
index 0000000000..2b9fc9552d
--- /dev/null
+++ b/doc/forum/rsync_over_ssh__63__/comment_1_ee21f32e90303e20339e0a568321bbbe._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-03-06T15:59:37Z"
+ content="""
+Everything is done over ssh unless both repos are on the same system (or unless you NFS mount a repo)
+"""]]
diff --git a/doc/forum/rsync_over_ssh__63__/comment_2_aa690da6ecfb2b30fc5080ad76dc77b1._comment b/doc/forum/rsync_over_ssh__63__/comment_2_aa690da6ecfb2b30fc5080ad76dc77b1._comment
new file mode 100644
index 0000000000..49003937b6
--- /dev/null
+++ b/doc/forum/rsync_over_ssh__63__/comment_2_aa690da6ecfb2b30fc5080ad76dc77b1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://m-f-k.myopenid.com/"
+ ip="92.194.43.135"
+ subject="comment 2"
+ date="2011-03-06T16:33:19Z"
+ content="""
+Great! This was the only thing about git-annex which could have kept me from using it. --Michael
+"""]]
diff --git a/doc/forum/rsync_protocol_mismatch_due_to_encfs_folder.mdwn b/doc/forum/rsync_protocol_mismatch_due_to_encfs_folder.mdwn
new file mode 100644
index 0000000000..c3667a2b69
--- /dev/null
+++ b/doc/forum/rsync_protocol_mismatch_due_to_encfs_folder.mdwn
@@ -0,0 +1,24 @@
+One of my repositories worked just fine for months, until I have decided to put an encfs folder within it. Encfs is encrypting folders and files, resulting in weird file and folder names. However, rsync just seems to fail.
+
+
+This has already been a topic here a few times, for example [1] and [2].
+
+Unfortunately, I have not been lucky enough to recover the situation by the hints given.
+
+
+What I did to investigate is that I have re-run one of the shell commands stuck client-side and appended --debug to gain a deeper look. This is the output:
+
+    $ /opt/git-annex/2016-01-14/exe/ssh --library-path /opt/git-annex/2016-01-14//etc/ld.so.conf.d:/opt/git-annex/2016-01-14//usr/lib/x86_64-linux-gnu/gconv:/opt/git-annex/2016-01-14//usr/lib/x86_64-linux-gnu/audit:/opt/git-annex/2016-01-14//usr/lib:/opt/git-annex/2016-01-14//usr/lib/x86_64-linux-gnu:/opt/git-annex/2016-01-14//lib64:/opt/git-annex/2016-01-14//lib/x86_64-linux-gnu: /opt/git-annex/2016-01-14/shimmed/ssh/ssh -S .git/annex/ssh/user@10.0.0.1 -o ControlMaster=auto -o ControlPersist=yes -T user@10.0.0.1 git-annex-shell 'recvkey' '/mnt/path/to/share/' 'SHA256E-s262670--e004c6e3f87ad2b5d74d206de85de5449c9f263d83e6ef1c87ffb03be8b7e725' --debug --uuid e34522e4-1dab-459c-b295-1fe41e7692e4 '--' 'remoteuuid=07820aec-e2a3-4c60-bd57-b39b7213e056' 'unlocked=1' 'direct=1' 'associatedfile=.encfs_folder/CMG23xCwkemocE-Gq9WHpO-n/1vqfTkJChNm5CgjBsZ--,9r,ZOcSBTxE-Ogz5ytA8R23st52LWf4d9MjRref56VhbEB/4ezakoEn8dqOT8s,K4X,ueSs' '--' dummy rsync --server -pe.Lsfx --log-format=X --inplace . .
+    [2016-03-16 22:52:18.922914] transfer start
+    [2016-03-16 22:52:18.949417] call: rsync ["--server","-t","--inplace","-e.Lsf",".","../../mnt/path/to/share/.git/annex/tmp/SHA256E-s262670--e004c6e3f87ad2b5d74d206de85de5449c9f263d83e6ef1c87ffb03be8b7e725"]
+    protocol version mismatch -- is your shell clean?
+    (see the rsync man page for an explanation)
+    rsync error: protocol incompatibility (code 2) at compat.c(176) [Receiver=3.1.1]
+    [2016-03-16 22:59:05.890987] process done ExitFailure 2
+    [2016-03-16 22:59:05.899506] transfer done
+
+What can I do other than to just move the encfs outside my repository, which is of course the least favorable option for me to do?
+
+[1] <http://git-annex.branchable.com/bugs/protocol_mismatch_after_interrupt/>
+
+[2] <http://git-annex.branchable.com/bugs/rsync__58___protocol_version_mismatch/>
diff --git a/doc/forum/rsync_regression_on_Windows.mdwn b/doc/forum/rsync_regression_on_Windows.mdwn
new file mode 100644
index 0000000000..d0bc0f14d1
--- /dev/null
+++ b/doc/forum/rsync_regression_on_Windows.mdwn
@@ -0,0 +1,16 @@
+I'm on Windows 7 and msysgit. The rsync that comes with the git-annex installer downloaded on January 19 2015 works fine (rsync version 3.0.9, protocol version 30; git annex version 5.20150113-gcf247cf). The rsync that comes with the current git-annex installer errors out (rsync version 3.1.1  protocol version 31; git annex v ersion 5.20150420-gb0ebb23). I don't think it's a version/protocol mismatch, as I get the error against a server with the same version and protocol.
+
+[[!format sh """
+$ rsync -rvvp anton@myhost:wtmp/ wtmp
+opening connection using: ssh -l anton myhost rsync --server --sender -vv
+pre.iLsfx . wtmp/  (10 args)
+rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
+rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.1]
+
+$ ssh -l anton myhost rsync --version
+rsync  version 3.1.1  protocol version 31
+...
+
+"""]]
+
+Bug or user error?
diff --git a/doc/forum/rsync_regression_on_Windows/comment_1_0e713f8949a3e5a949489fc89c0b9078._comment b/doc/forum/rsync_regression_on_Windows/comment_1_0e713f8949a3e5a949489fc89c0b9078._comment
new file mode 100644
index 0000000000..5642560fd1
--- /dev/null
+++ b/doc/forum/rsync_regression_on_Windows/comment_1_0e713f8949a3e5a949489fc89c0b9078._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-07T18:16:07Z"
+ content="""
+[[bugs/rsync_on_windows_broken_by_upgrade]]
+"""]]
diff --git a/doc/forum/rsync_remote_is_not_available_from_a_cloned_repo/comment_1_2e340c5a6473f165dc06cc35db38e5c0._comment b/doc/forum/rsync_remote_is_not_available_from_a_cloned_repo/comment_1_2e340c5a6473f165dc06cc35db38e5c0._comment
new file mode 100644
index 0000000000..2b6ff45df9
--- /dev/null
+++ b/doc/forum/rsync_remote_is_not_available_from_a_cloned_repo/comment_1_2e340c5a6473f165dc06cc35db38e5c0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="hannes"
+ ip="130.226.142.243"
+ subject="original repo git annex version"
+ date="2012-07-08T11:55:42Z"
+ content="""
+is 3.20120629
+"""]]
diff --git a/doc/forum/rsync_test_remote_fail.mdwn b/doc/forum/rsync_test_remote_fail.mdwn
new file mode 100644
index 0000000000..0e30d449c5
--- /dev/null
+++ b/doc/forum/rsync_test_remote_fail.mdwn
@@ -0,0 +1,84 @@
+Hi,
+
+I am running into a bizarre testremote failure (with an rsync+encryption=shared special remote). 
+
+Here are the exact steps to replicate:
+
+    $ mkdir test
+    $ cd test/
+    $ git init
+    $ git annex init
+    $ git annex initremote newremote type=rsync rsyncurl=10.0.0.100:/backup/annex-enc/test encryption=shared
+    $ git annex testremote newremote
+
+    Here is what I will get
+
+    testremote newremote (generating test keys...) Remote Tests
+      unavailable remote
+        removeKey:                                       OK
+        storeKey:                                        OK
+        checkPresent:                                    OK
+        retrieveKeyFile:                                 OK
+        retrieveKeyFileCheap:                            OK
+      key size Just 1048576; remote chunksize=0 encryption=none
+        removeKey when not present:                      OK (1.51s)
+        present False:                                   OK (0.62s)
+        storeKey:                                        OK (1.10s)
+        present True:                                    FAIL (0.62s)
+          ./Command/TestRemote.hs:290:
+          failed
+        storeKey when already present:                   OK (0.37s)
+        present True:                                    FAIL (0.63s)
+          ./Command/TestRemote.hs:290:
+          failed
+        retrieveKeyFile:                                 rsync: change_dir "/backup/annex-enc/test/242/793/'SHA256E-s1048576--26a83e410604bf3f0f9288c14b39387ce244a832a02b192c81a97a36a0e42296.this-is-a-test-key" failed: No such file or directory (2)
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1865) [Receiver=3.2.7]
+    rsync: [Receiver] write error: Broken pipe (32)
+    rsync exited 23
+    rsync: change_dir "/backup/annex-enc/test/W4/4g/'SHA256E-s1048576--26a83e410604bf3f0f9288c14b39387ce244a832a02b192c81a97a36a0e42296.this-is-a-test-key" failed: No such file or directory (2)
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1865) [Receiver=3.2.7]
+    rsync: [Receiver] write error: Broken pipe (32)
+    rsync exited 23
+    FAIL (0.61s)
+          ./Command/TestRemote.hs:290:
+          failed
+        fsck downloaded object:                          OK
+        retrieveKeyFile resume from 33%:                 FAIL
+          Exception: .git/annex/objects/W4/4g/SHA256E-s1048576--26a83e410604bf3f0f9288c14b39387ce244a832a02b192c81a97a36a0e42296.this-is-a-test-key/SHA256E-s1048576--26a83e410604bf3f0f9288c14b39387ce244a832a02b192c81a97a36a0e42296.this-is-a-test-key: openBinaryFile: does not exist (No such file or directory)
+        fsck downloaded object:                          OK
+        retrieveKeyFile resume from 0:                   rsync: change_dir "/backup/annex-enc/test/242/793/'SHA256E-s1048576--26a83e410604bf3f0f9288c14b39387ce244a832a02b192c81a97a36a0e42296.this-is-a-test-key" failed: No such file or directory (2)
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1865) [Receiver=3.2.7]
+    rsync: [Receiver] write error: Broken pipe (32)
+    rsync exited 23
+    rsync: change_dir "/backup/annex-enc/test/W4/4g/'SHA256E-s1048576--26a83e410604bf3f0f9288c14b39387ce244a832a02b192c81a97a36a0e42296.this-is-a-test-key" failed: No such file or directory (2)
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1865) [Receiver=3.2.7]
+    rsync: [Receiver] write error: Broken pipe (32)
+    rsync exited 23
+    FAIL (0.61s)
+          ./Command/TestRemote.hs:290:
+          failed
+        fsck downloaded object:                          OK
+        retrieveKeyFile resume from end:                 cp: cannot stat '.git/annex/objects/W4/4g/SHA256E-s1048576--26a83e410604bf3f0f9288c14b39387ce244a832a02b192c81a97a36a0e42296.this-is-a-test-key/SHA256E-s1048576--26a83e410604bf3f0f9288c14b39387ce244a832a02b192c81a97a36a0e42296.this-is-a-test-key': No such file or directory
+
+This will repeat again and again (with different remote chunksize?) until finally it hangs where I would have to Ctrl+C it to force it to abort.
+
+I am using Ubuntu 22.04.3 LTS (Jammy) with the following git annex version:
+
+    $ git annex version
+    git-annex version: 8.20210223
+    build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+    dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+    remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+    operating system: linux x86_64
+    supported repository versions: 8
+    upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+    local repository version: 8
+
+I can't see why git-annex rsync would be failing. I can do normal rsync via command line w/o any issues.
+
+Any help would be appreciated.
+
+
+
+
diff --git a/doc/forum/rsync_test_remote_fail/comment_1_deffffd5112a60ad7837479da045d39f._comment b/doc/forum/rsync_test_remote_fail/comment_1_deffffd5112a60ad7837479da045d39f._comment
new file mode 100644
index 0000000000..84bf746520
--- /dev/null
+++ b/doc/forum/rsync_test_remote_fail/comment_1_deffffd5112a60ad7837479da045d39f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="tchen_annex"
+ avatar="http://cdn.libravatar.org/avatar/758a07ad226fbf59a287e6cbff1c11ed"
+ subject="this also fails with encryption=none"
+ date="2024-02-25T01:08:43Z"
+ content="""
+One potentially useful info. A bit more experimentation shows that this fails with encryption=none as well. Seems to be purely a rsync issue.
+"""]]
diff --git a/doc/forum/rsync_test_remote_fail/comment_2_824e45450cc01b30144ac5f8265b930e._comment b/doc/forum/rsync_test_remote_fail/comment_2_824e45450cc01b30144ac5f8265b930e._comment
new file mode 100644
index 0000000000..4eec6a6026
--- /dev/null
+++ b/doc/forum/rsync_test_remote_fail/comment_2_824e45450cc01b30144ac5f8265b930e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="tchen_annex"
+ avatar="http://cdn.libravatar.org/avatar/758a07ad226fbf59a287e6cbff1c11ed"
+ subject="ignore, upgrading to v10.20231227 solved this issue"
+ date="2024-02-25T17:34:31Z"
+ content="""
+Okay, I tried the latest version of git-annex via git-annex-standalone package in NeuroDebian deb-src. Problem solved with latest version. Please this error report.
+"""]]
diff --git a/doc/forum/rsync_test_remote_fail/comment_3_0b910e98485832dd7f305decdc39fa7f._comment b/doc/forum/rsync_test_remote_fail/comment_3_0b910e98485832dd7f305decdc39fa7f._comment
new file mode 100644
index 0000000000..b890f99d8a
--- /dev/null
+++ b/doc/forum/rsync_test_remote_fail/comment_3_0b910e98485832dd7f305decdc39fa7f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-02-26T19:40:15Z"
+ content="""
+Thanks for following up that it's fixed in current version.
+
+Please use [[bugs]] in the future for bug reports.
+"""]]
diff --git a/doc/forum/rsyncing_.git__47__annex__47__objects.mdwn b/doc/forum/rsyncing_.git__47__annex__47__objects.mdwn
new file mode 100644
index 0000000000..876b5e04a7
--- /dev/null
+++ b/doc/forum/rsyncing_.git__47__annex__47__objects.mdwn
@@ -0,0 +1,24 @@
+In short: is it safe to rsync .git/annex/objects/ to other clones?
+
+I'm in the process of migrating a lot of my files to a new backend.  Most them
+still use the old non-file-size-tracking SHA1 backend from when WORM was the
+default.  I have multiple clones that each use about 460 GB of their 500 GB
+drives.
+
+I've noticed that git-annex creates hardlinks to migrated content in
+.git/annex/objects, so I'm able to migrate all content despite only having 40
+GB of free space.  Excellent.
+
+Now I'm planning to `rsync -a --hard-links .git/annex/objects/
+${CLONE}/.git/annex/objects/` to recreate the hardlinks and save space on the
+clones as well.  If I `fsck` afterwards, this should be fine, right?
+
+I've tried this with a test repository and it works but I'd like to be extra
+sure that I'm not missing something crucial.
+
+The alternatives that I'm aware of are:
+
+ * making space first: `git annex dropunused "1-20000"` and `git annex get .`
+ * running `git annex migrate` in each clone.
+
+I expect rsync to be safer and faster than these alternatives.
diff --git a/doc/forum/rsyncing_.git__47__annex__47__objects/comment_1_25eb9f7be5730337b9efd96dce9efd2e._comment b/doc/forum/rsyncing_.git__47__annex__47__objects/comment_1_25eb9f7be5730337b9efd96dce9efd2e._comment
new file mode 100644
index 0000000000..8d9e22a7e9
--- /dev/null
+++ b/doc/forum/rsyncing_.git__47__annex__47__objects/comment_1_25eb9f7be5730337b9efd96dce9efd2e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 1"
+ date="2013-11-16T17:36:48Z"
+ content="""
+As long as you fsck afterwards, this is fine.
+
+You might want to `git annex fsck --all` in case you have objects for old versions of files.
+"""]]
diff --git a/doc/forum/rsyncing_.git__47__annex__47__objects/comment_2_d7ceae666c8a1951021d3c6e6ac39a11._comment b/doc/forum/rsyncing_.git__47__annex__47__objects/comment_2_d7ceae666c8a1951021d3c6e6ac39a11._comment
new file mode 100644
index 0000000000..f9c449f5eb
--- /dev/null
+++ b/doc/forum/rsyncing_.git__47__annex__47__objects/comment_2_d7ceae666c8a1951021d3c6e6ac39a11._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="gernot"
+ ip="89.0.237.214"
+ subject="comment 2"
+ date="2013-11-18T15:09:59Z"
+ content="""
+Thanks for the confirmation, Joey!  I also wouldn't have thought of `--all`.
+"""]]
diff --git a/doc/forum/s3_bandwidth_limitations_and_next_release.mdwn b/doc/forum/s3_bandwidth_limitations_and_next_release.mdwn
new file mode 100644
index 0000000000..c1e67a8c0b
--- /dev/null
+++ b/doc/forum/s3_bandwidth_limitations_and_next_release.mdwn
@@ -0,0 +1,7 @@
+Is there a way to set bandwidth limits for [[special_remotes/s3]]?
+
+From what i can see in the [[todo/credentials-less_access_to_s3]] patch, the `downloadUrl` function is used, does that mean that the `annex.web-download-command` is used? If that's the case, it's great because it means we can use the `--bwlimit` parameter in `wget` to limit transfers.
+
+But what about uploads? Are there limits there as well?
+
+I'll also abuse this forum to see if/when it will be possible to have a shiny new release to ship that amazing new feature? There seems to be sufficient stuff piled up in the unreleased changelog to warrant a release, no? :) --[[anarcat]]
diff --git a/doc/forum/s3_bandwidth_limitations_and_next_release/comment_1_6fba752ada4ca86c96a026a4d09ef16b._comment b/doc/forum/s3_bandwidth_limitations_and_next_release/comment_1_6fba752ada4ca86c96a026a4d09ef16b._comment
new file mode 100644
index 0000000000..60e24bcbc7
--- /dev/null
+++ b/doc/forum/s3_bandwidth_limitations_and_next_release/comment_1_6fba752ada4ca86c96a026a4d09ef16b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-06-14T16:53:22Z"
+ content="""
+Yeah, I did use wget for the read-only S3 downloads, so you can configure
+with `annex.web-download-command`. No rate limiting available for
+authenticated S3 access yet.
+
+Release tuesday or wednesday.
+"""]]
diff --git a/doc/forum/s3_server_side_encryption.mdwn b/doc/forum/s3_server_side_encryption.mdwn
new file mode 100644
index 0000000000..f7b64921ba
--- /dev/null
+++ b/doc/forum/s3_server_side_encryption.mdwn
@@ -0,0 +1,9 @@
+AWS S3 offers a feature to enable server-side encryption of files.  
+If I understand correctly, this is enabled by sending a specific HTTP header with the request to upload the file in question.   
+So, this header needs to be set every time we want to upload a new file.  
+
+Is this feature already supported / being considered for future versions?
+
+If not, am I correct in assuming it would have to be implemented in https://github.com/joeyh/git-annex/blob/master/Remote/S3.hs ?
+
+Thank you
diff --git a/doc/forum/s3_server_side_encryption/comment_1_68345d01b016abf96c226d2bfa17c641._comment b/doc/forum/s3_server_side_encryption/comment_1_68345d01b016abf96c226d2bfa17c641._comment
new file mode 100644
index 0000000000..1dbf60047d
--- /dev/null
+++ b/doc/forum/s3_server_side_encryption/comment_1_68345d01b016abf96c226d2bfa17c641._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-01-05T20:33:13Z"
+ content="""
+I have not looked into this particular S3 feature, since I see little point
+in using it. git-annex can encrypt files client-side before sending to S3,
+which is much better.
+
+However, you can probably configure git-annex to send the header.
+See the `x-amx-meta-*` option documented in [[special_remotes/S3]].
+If the header was named encryptplz and needed to be set to
+"canhazsecurityburger", you would enable it with something like:
+
+	git annex enableremote mys3remote x-amz-meta-encryptplz=canhazsecurityburger
+"""]]
diff --git a/doc/forum/s3_server_side_encryption/comment_2_b2ccef6dc00d58e103ac0fda48ee94d3._comment b/doc/forum/s3_server_side_encryption/comment_2_b2ccef6dc00d58e103ac0fda48ee94d3._comment
new file mode 100644
index 0000000000..f3d8c94bcd
--- /dev/null
+++ b/doc/forum/s3_server_side_encryption/comment_2_b2ccef6dc00d58e103ac0fda48ee94d3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawne3YCXovu_ERUYNpH46AVo0FlgyQwt3HI"
+ nickname="Pierre"
+ subject="comment 2"
+ date="2015-01-05T20:47:31Z"
+ content="""
+Thanks for your reponse. I'll try specifying the header as you are suggesting.
+
+FYI, one reason for not handling encryption locally is to not have to manage encryption keys. If multiple people need to be able to decrypt the data, I would have to manage all their keys.
+"""]]
diff --git a/doc/forum/s3_server_side_encryption/comment_3_3eb57b98e4136b8550ea5d19393fe967._comment b/doc/forum/s3_server_side_encryption/comment_3_3eb57b98e4136b8550ea5d19393fe967._comment
new file mode 100644
index 0000000000..cee29d8770
--- /dev/null
+++ b/doc/forum/s3_server_side_encryption/comment_3_3eb57b98e4136b8550ea5d19393fe967._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-01-05T21:09:47Z"
+ content="""
+Using git-annex's encryption=shared will have the same
+key management ease as letting Amazon encrypt. 
+
+In both cases you're putting the shared encryption key into the
+configuration of a git-annex S3 remote. Anyone who can access the git
+repository can access the encryption key.
+"""]]
diff --git a/doc/forum/s3_server_side_encryption/comment_4_71d6c2356af8974cb848c3574cf3eb6d._comment b/doc/forum/s3_server_side_encryption/comment_4_71d6c2356af8974cb848c3574cf3eb6d._comment
new file mode 100644
index 0000000000..7cfa0195b7
--- /dev/null
+++ b/doc/forum/s3_server_side_encryption/comment_4_71d6c2356af8974cb848c3574cf3eb6d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawne3YCXovu_ERUYNpH46AVo0FlgyQwt3HI"
+ nickname="Pierre"
+ subject="comment 4"
+ date="2015-01-05T21:19:37Z"
+ content="""
+Ok, thank you!
+"""]]
diff --git a/doc/forum/s3_vs_ssh_Performance_Problems.mdwn b/doc/forum/s3_vs_ssh_Performance_Problems.mdwn
new file mode 100644
index 0000000000..5176e196fc
--- /dev/null
+++ b/doc/forum/s3_vs_ssh_Performance_Problems.mdwn
@@ -0,0 +1,8 @@
+I backup/sync my music using annex. I used to have one repo with 3 clones, one full copy on my vps, one full copy and one partial copy on my laptops. I decided to move all data to s3. Declared my vps repo dead, purged history (I do not care about history for this particular repo) pushed the git repo to a different computer (bare repo no data) and data to s3 (gpg encrypted). I've just finished uploading all files (around 200gb) couple files failed during the initial upload so I did a `git annex copy --quiet --to mys3 --fast` this command used to take 15 20 secs on my laptop when sending data to vps using ssh but now it took 2 hours to complete (pushing mem usage to 90%).
+
+I have one other repo (1.5gb in size 42k files using indirect mode, data gpg encrypted on s3) using the same setup except this repos content has always been on s3  i had the same behavior on this repo too. adding a file and running a copy to push content to s3 took couple hours even if I add a single 1kb file. I used to blame my hard drive, damn thing is slow but now I think this is related to s3. is there any workaround for this?
+
+Both machines are using,
+
+    git-annex version: 4.20130913-gd20a4f2
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP Feeds Quvi
diff --git a/doc/forum/s3_vs_ssh_Performance_Problems/comment_1_65f064f09d7850abecab97007b0d30f0._comment b/doc/forum/s3_vs_ssh_Performance_Problems/comment_1_65f064f09d7850abecab97007b0d30f0._comment
new file mode 100644
index 0000000000..aa3e06cc0c
--- /dev/null
+++ b/doc/forum/s3_vs_ssh_Performance_Problems/comment_1_65f064f09d7850abecab97007b0d30f0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2013-11-21T04:09:15Z"
+ content="""
+Is
+
+    git annex copy --not --in mys3 --to mys3 .
+
+any faster?
+"""]]
diff --git a/doc/forum/s3_vs_ssh_Performance_Problems/comment_2_baaf2384d9196077268e9ca9bbe3b871._comment b/doc/forum/s3_vs_ssh_Performance_Problems/comment_2_baaf2384d9196077268e9ca9bbe3b871._comment
new file mode 100644
index 0000000000..f54e49b2b5
--- /dev/null
+++ b/doc/forum/s3_vs_ssh_Performance_Problems/comment_2_baaf2384d9196077268e9ca9bbe3b871._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 2"
+ date="2013-11-21T17:47:57Z"
+ content="""
+No difference. Both take roughly the same time but I did time a couple of runs with both commands they usually take 3 to 5 minutes to complete. Maybe git did something behind the scenes like gc? But still slower than it used to be. My other repo (one with 42k files) still takes a 2 hours.
+"""]]
diff --git a/doc/forum/s3_vs_ssh_Performance_Problems/comment_3_dc44be42070c073d150c476406e9b425._comment b/doc/forum/s3_vs_ssh_Performance_Problems/comment_3_dc44be42070c073d150c476406e9b425._comment
new file mode 100644
index 0000000000..cbd460818f
--- /dev/null
+++ b/doc/forum/s3_vs_ssh_Performance_Problems/comment_3_dc44be42070c073d150c476406e9b425._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 3"
+ date="2013-11-22T20:21:11Z"
+ content="""
+Well it's not related to s3... that copy command won't even do any network traffic if there is nothing to copy.  I have a similarly configured annex with 4500 files and that command takes 10 seconds to run.
+
+I do remember there being a recent fix that reduced the algorithmic complexity of an operation, but I forget which.
+"""]]
diff --git a/doc/forum/s3_vs_ssh_Performance_Problems/comment_4_f9c3ef3b1b44bfb29125acb6ec621f38._comment b/doc/forum/s3_vs_ssh_Performance_Problems/comment_4_f9c3ef3b1b44bfb29125acb6ec621f38._comment
new file mode 100644
index 0000000000..2e4cda6342
--- /dev/null
+++ b/doc/forum/s3_vs_ssh_Performance_Problems/comment_4_f9c3ef3b1b44bfb29125acb6ec621f38._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 4"
+ date="2013-12-12T20:14:01Z"
+ content="""
+You mentioned something about high memory usage when copying. How much memory are we talking about?
+
+Have you run `git annex forget` in this repository before? It kind of sounds like you have, and it might be possible that it's repeatedly trying to forget old history for some reason.
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history.mdwn b/doc/forum/safely_dropping_git-annex_history.mdwn
new file mode 100644
index 0000000000..a6d8e66779
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history.mdwn
@@ -0,0 +1,20 @@
+the git-annex branch of a repository i've had running since 2010 has grown to unmanagable dimensions (5gb in a fresh clone of the git-annex branch, while the master branch has merely 40mb, part of which is due to checked-in files), resulting in git-annex-merges to take in the order of magnitude of 15 minutes. getting an initial clone of the git-annex branch (not the data) takes hours alone in the "remote: Counting objects" phase (admittedly, the origin server is limited in ram, so it spends its time swapping the git process back and forth).
+
+is there a recommended way for how to reset the git-annex branch in a coordinated way? of course, this would have to happen on all copies of the repo at the same time.
+
+the workflow i currently imagine is
+
+* rename all copies of the repository (the_repo → the_repo-old, the_repo.git → the_repo-old.git)
+* clone the old origin repository to a new origin with --single-branch. (this would be *the* oportunity to ``git filter-branch --prune-empty --index-filter 'git rm --cached --ignore-unmatch .git-annex -r' master`` as well, to get rid of commits of pre-whatever versions)
+* ``git annex init`` on the master repository
+* clone it to all the other copies and ``git annex init`` there
+* set all the configuration options (untrusted repos etc) again
+* either
+  * ``git annex reinject`` the files that are already present on the respective machines, or
+  * move the .git/annex/objects files over from the original locations, and use ``git annex fsck`` to make git-annex discover which files it already has, if that works. (i have numcopies=2, thus i'd dare to move instead of copy even when trying this out the first time. complete copies, even of partially checked out clones, will exceed the capacities of most clients)
+
+my questions in that endeavor are:
+
+* is there already a standard workflow for this?
+* if not, will the above do the trick?
+* can anything be done to avoid such problems in future?
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_10_a4b93a3fbc98d9b86e942f95e0039862._comment b/doc/forum/safely_dropping_git-annex_history/comment_10_a4b93a3fbc98d9b86e942f95e0039862._comment
new file mode 100644
index 0000000000..b24a058f6c
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_10_a4b93a3fbc98d9b86e942f95e0039862._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.140"
+ subject="comment 10"
+ date="2013-07-20T20:03:20Z"
+ content="""
+Since you seem to have found a way that works, I'm only answering for completeness: To resolve a conflicted merge on the git-annex branch, you can just add all lines present in either side of the merge, in any order. This won't necessarily be the most minimal resolution, but it is guaranteed to always be a valid one. There is a git-union-merge program in the git-annex source (not built by default) that can do that when merging any set of branches.
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_11_383882fafd32f25ed22b5eb2fb3691b9._comment b/doc/forum/safely_dropping_git-annex_history/comment_11_383882fafd32f25ed22b5eb2fb3691b9._comment
new file mode 100644
index 0000000000..fbfe641564
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_11_383882fafd32f25ed22b5eb2fb3691b9._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="propagating squashed history to other remotes"
+ date="2013-08-12T01:44:59Z"
+ content="""
+The easiest method seems to be to force-push git-annex and master to other remotes, e.g.
+
+    git push -f myremote git-annex:refs/heads/git-annex
+
+Before doing this, make sure location logs etc had a chance to propagate across all remotes.
+
+It's a good idea to remove synched/ branches before doing git-annex sync on the repos with rewritten history, too:
+    git branch -D synced/master
+    git branch -D synced/annex
+
+
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_12_47794a2abf29bf4ea2763ff89d872ab4._comment b/doc/forum/safely_dropping_git-annex_history/comment_12_47794a2abf29bf4ea2763ff89d872ab4._comment
new file mode 100644
index 0000000000..5c09316041
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_12_47794a2abf29bf4ea2763ff89d872ab4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4830:1600:187::2"
+ subject="comment 12"
+ date="2013-09-04T06:38:00Z"
+ content="""
+`git annex forget` automates this now, without needing to force-push or have a flag day. Needs a version of git-annex supporting it installed on *all* the computers you use the repo on. Repos notice they need to forget when git annex is run in them, and do, automatically.
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_13_b7b920862fc82eaa5d7deae34b4aebc4._comment b/doc/forum/safely_dropping_git-annex_history/comment_13_b7b920862fc82eaa5d7deae34b4aebc4._comment
new file mode 100644
index 0000000000..7a8f62260f
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_13_b7b920862fc82eaa5d7deae34b4aebc4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Rizwan"
+ avatar="http://cdn.libravatar.org/avatar/15c58acba4fc6f75abd783d5836e0254"
+ subject="Are these methods still working?"
+ date="2018-06-12T14:58:03Z"
+ content="""
+I am new to git annex. I like the concept of partial checkout, given that I have multiple storages. 
+
+My repo is small right now, 2000+ files collectively amounting to 24 MB in size. However, as soon as I add and unlock the repo, the size of the Annex folder becomes 50+ MB. Is this normal? I try to sync with google drive and the size goes to 90+ Mb post syncing. 
+
+I feel like I must be doing something wrong. Does the size of gorw upto 4 times the original data. I tried the methods listed in above comments, none worked. Seeing that last comment is 4+ years old, I wanted to know if these methods are still viable?
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_14_979bbccf31dbee1707d403957bde3493._comment b/doc/forum/safely_dropping_git-annex_history/comment_14_979bbccf31dbee1707d403957bde3493._comment
new file mode 100644
index 0000000000..8c0d512d23
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_14_979bbccf31dbee1707d403957bde3493._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2018-06-12T16:11:27Z"
+ content="""
+@Rizwan yes, the things documented here still work. But, they drop old
+history about the past locations of files, they do not drop *all* information
+about the current locations of files. git-annex is keeping track of which
+files you have stored in the local repository and on the remote, and that
+information necessisarily takes up space.
+
+You're using git-annex with small files -- around 12
+kilobytes average file size. It's designed for mostly much larger files,
+so you will see a larger percentage of overhead in using it than you would
+if your files were bigger.
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_1_4fd76d10a93fe01588fce7a621f9254d._comment b/doc/forum/safely_dropping_git-annex_history/comment_1_4fd76d10a93fe01588fce7a621f9254d._comment
new file mode 100644
index 0000000000..e46f7291a2
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_1_4fd76d10a93fe01588fce7a621f9254d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.194"
+ subject="comment 1"
+ date="2012-10-31T16:03:55Z"
+ content="""
+Yes, you can use fsck like that. I outlined a similar approach [here](http://git-annex.branchable.com/forum/Delete_unused_files__47__metadata/#comment-e2bd822214df96606a60e8aee2c8637a), and I think you don't even need to make new git repositories, just delete the old branch and git gc it -- but I've not heard of anyone doing this yet.
+
+So, since 2010, your repo must have gone through at least one and probably two repository format changes, which bloated the git branch. Hopefully we'll have no more of those. My largest repo that also went through that is under 150 mb however. 
+
+There was a recent bug fix where `git annex copy` unnecessarily updated location log even when the file was already copied. That kind of thing can bloat the repository, especially if you had that in a cron job... You might find `git annex log` useful to look through history of files and see if there have been a lot of location changes logged for whatever reason.
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_2_10ecf3220ffcbbe94ba09da225458f18._comment b/doc/forum/safely_dropping_git-annex_history/comment_2_10ecf3220ffcbbe94ba09da225458f18._comment
new file mode 100644
index 0000000000..21befd41a0
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_2_10ecf3220ffcbbe94ba09da225458f18._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="worked well"
+ date="2012-11-04T12:23:56Z"
+ content="""
+the procedure i outlined originally worked well for me; the method chosen for reinjection was moving over the .git/annex/objects directory and doing a ``git annex fsck``.
+
+special care had to be taken of the special remote (rsync+gpg) -- i guess that's why they are called special ;-) . as described in the forum post you linked, i had to copy over remote.log and the uuid.log line from the old git-annex branch -- otherwise, a ``git annex initremote`` would have generated a new hmac, effectively resetting the remote repo.
+
+the formerly 5gb git-annex branch (admittedly not ``git gc``'d recently, but that just wasn't feasible any more) shrunk down to around 25mb of current location information. i'll keep an eye on how it's growing to see if the problem is inherent or if it was just old bugs causing trouble.
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_3_e3beb8acb075faaeef6c052aecbf0a41._comment b/doc/forum/safely_dropping_git-annex_history/comment_3_e3beb8acb075faaeef6c052aecbf0a41._comment
new file mode 100644
index 0000000000..fbcbdbc4fa
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_3_e3beb8acb075faaeef6c052aecbf0a41._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="http://vjt.myopenid.com/"
+ nickname="vjt"
+ subject="drop &quot;content removed from annex&quot; history"
+ date="2013-06-18T02:12:01Z"
+ content="""
+Joey,
+
+dropping the git-annex branch and subsequent fsck worked. Moreover, as I turned my repository in containing over 700k objects due to a silly cycle of `git annex add` / `git annex unannex`, bloating *both* `git-annex` and `master` history, to clean up I successfully performed a squashed rebase of master onto itself.
+
+Here's what I did, in detail:
+
+    $ git checkout git-annex
+    $ cp *.log ..
+    $ git checkout master
+    $ git br -D git-annex
+    $ git br -D synced/git-annex
+    $ git checkout <first commit>
+    $ git checkout -b git-annex
+    $ cp ../*.log .
+    $ <remove the changes done in the first commit, my case just adding a .gitignore>
+    $ git add *.log
+    $ git commit --amend -m 'Init'
+
+With this, I got rid of the many `update` commits. Now, the fun part:
+
+    $ git checkout master
+    $ git rebase -i <first commit>
+    <In the git-rebase-todo, I squashed almost everything, except a few commits I wanted to preserve>
+    $ :wq
+
+Rebase went fine, and I was left with a clean master. I brought also `synced/master` up to date:
+
+    $ git checkout synced/master
+    $ git reset --hard master
+
+Now I re-created all the location links with fsck:
+
+    $ git annex fsck
+
+And eventually, got rid of the redundant history:
+
+    $ git reflog expire --expire=now --expire-unreachable=now --all
+    $ git gc --prune=now
+    $ git repack
+    $ git prune
+
+yay, 500k objects less ^_^'.
+
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_4_61a5fe2e7e47c60a8b237ea69404a37f._comment b/doc/forum/safely_dropping_git-annex_history/comment_4_61a5fe2e7e47c60a8b237ea69404a37f._comment
new file mode 100644
index 0000000000..d257e6f622
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_4_61a5fe2e7e47c60a8b237ea69404a37f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="would git annex fsck also recreate location tracking info for special remotes?"
+ date="2013-07-17T17:02:50Z"
+ content="""
+Suppose I want to drop history like discussed in this entry. How well does this deal with special (e.g. directory on an offline disk) remotes?
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_5_426d02e2f2a2ae4ec7eae02dfe4519b3._comment b/doc/forum/safely_dropping_git-annex_history/comment_5_426d02e2f2a2ae4ec7eae02dfe4519b3._comment
new file mode 100644
index 0000000000..aafa8fa1bc
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_5_426d02e2f2a2ae4ec7eae02dfe4519b3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 5"
+ date="2013-07-17T17:06:39Z"
+ content="""
+Also, would simply squashing git-annex branch history (without fsck etc) work?
+This seems easier.
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_6_410a7296c2cee16d3d5bb618a5a41c1d._comment b/doc/forum/safely_dropping_git-annex_history/comment_6_410a7296c2cee16d3d5bb618a5a41c1d._comment
new file mode 100644
index 0000000000..05ac273616
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_6_410a7296c2cee16d3d5bb618a5a41c1d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 6"
+ date="2013-07-17T18:57:12Z"
+ content="""
+You can use `git annex fsck --from remote` to verify that every file location tracking thinks is on the remote still is. It's innefficient though -- it has to download the whole file to check the special remote still has the right content! That transfer can be avoided by adding --fast.
+
+This is documented in the man page. :)
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_7_42cf492fc98a9eba8176387749ef12e0._comment b/doc/forum/safely_dropping_git-annex_history/comment_7_42cf492fc98a9eba8176387749ef12e0._comment
new file mode 100644
index 0000000000..5c10b988cd
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_7_42cf492fc98a9eba8176387749ef12e0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 7"
+ date="2013-07-17T18:59:03Z"
+ content="""
+I don't see any reason why squashing git-annex branch history would not work. If you squash it to the same sha in each clone, things would be very happy, but even if you squash it to different shas, the union merge should result in those  different versions of the same data automatically merging together.
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_8_c0327ada073d8b69535f71b4dc6aa57e._comment b/doc/forum/safely_dropping_git-annex_history/comment_8_c0327ada073d8b69535f71b4dc6aa57e._comment
new file mode 100644
index 0000000000..120e4daefa
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_8_c0327ada073d8b69535f71b4dc6aa57e._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="git annex merge driver?"
+ date="2013-07-19T17:04:53Z"
+ content="""
+
+I've tried rebasing git-annex branch, and I hit a bunch of conflicts (both in uuid.log and for individual content file logs) of the form:
+
+<pre><code>
+<<<<<<< HEAD
+1369615760.859476s 1 016d9095-0cbc-4734-a498-4e0421e257d7
+=======
+1369615760.845334s 1 016d9095-0cbc-4734-a498-4e0421e257d7
+>>>>>>> 52e60e8... update
+1369615359.195672s 1 38c359dc-a7d9-498d-a818-2e9beae995b8
+</code></pre>
+
+As I understand, git-annex has a special timestamp-based merge driver to deal with these. Is there a way to use that with git rebase?
+
+"""]]
diff --git a/doc/forum/safely_dropping_git-annex_history/comment_9_f83d6090aea2b7d5d54c876df940cbad._comment b/doc/forum/safely_dropping_git-annex_history/comment_9_f83d6090aea2b7d5d54c876df940cbad._comment
new file mode 100644
index 0000000000..cbfd678508
--- /dev/null
+++ b/doc/forum/safely_dropping_git-annex_history/comment_9_f83d6090aea2b7d5d54c876df940cbad._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="git checkout --orphan"
+ date="2013-07-19T17:49:37Z"
+ content="""
+Instead of rebase, --orphan seems to be the right answer for pruning history: create a new git-annex orphan branch and git add and commit the files. So:
+<pre><code>
+
+git status 
+
+# verify there are no uncommitted or untracked files
+
+# master branch
+git branch -m old-master
+git checkout --orphan master
+git add .
+git commit -m 'first commit'
+
+# git annex branch
+git branch -m git-annex old-git-annex
+git checkout git-annex
+git checkout --orphan git-annex
+git add .
+git commit -m 'first commit'
+git checkout master
+
+# at this point, you may want to double-check that everything is still OK
+
+# finally, remove branches and clean up the objects:
+git branch -D old-master old-git-annex
+git reflog expire --expire=now --all
+git prune
+git gc
+
+</code></pre>
+
+The repo remains functional and .git is smaller.
+
+"""]]
diff --git a/doc/forum/scalability_with_lots_of_files.mdwn b/doc/forum/scalability_with_lots_of_files.mdwn
new file mode 100644
index 0000000000..3bbd877cf4
--- /dev/null
+++ b/doc/forum/scalability_with_lots_of_files.mdwn
@@ -0,0 +1,43 @@
+What is git-annex's [[scalability]] with large (10k+) number of files and a few (~10) repositories?
+
+I have had difficult times maintaining a music archive of around 20k files, spread around 17 repositories.
+
+`ncdu` tells me, of the actual files in the direct repository:
+
+<pre>
+$ ncdu --exclude .git
+ Total disk usage: 109,3GiB  Apparent size: 109,3GiB  Items: 23771
+</pre>
+
+Now looking at the git-annex metadata:
+
+<pre>
+$ time git clone -b git-annex /srv/mp3
+Cloning into 'mp3'...
+done.
+Checking out files: 100% (31207/31207), done.
+0.69user 1.72system 0:04.65elapsed 51%CPU (0avgtext+0avgdata 47732maxresident)k
+40inputs+489552outputs (1major+2906minor)pagefaults 0swaps
+$ git branch
+  annex/direct/master
+* git-annex
+  master
+$ wc -l uuid.log
+7 uuid.log
+$ find -type f | wc
+  31429   62214 3013920
+$ du -sh .
+361M    .
+$ du -sch *  | tail -1
+243M    total
+</pre>
+
+So basically, it looks like the git-annex location tracking takes up around 243M, 361M if we include git's history of it (I assume). This means around 8KiB of storage per file, and 4KiB/file for history (git is doing a pretty good job here). (8KiB kind of makes sense here: one file for the tracking log (4KiB) and another directory to hold it (another 4KiB)...)
+
+Is that about right? Are there ways to compress that somehow? Could I at least drop the *history* of that from git without too much harm - that would already save 120MiB...
+
+That repository is around 18 months old.
+
+(It's interesting to notice the limitation of the "one file per record" storage format here: since git-annex has so many little files, and all of those take at least $blocksize (it seems like it's 4KB here), it takes up space pretty quickly. Another good point for git here: packing files together saves a *lot* of space! Could files be packed *before* being stored in the git-annex branch? or is that totally stupid. :)
+
+Thanks! --[[anarcat]]
diff --git a/doc/forum/scalability_with_lots_of_files/comment_1_b9bb0a71d81b8cbc2a751bb7bab84812._comment b/doc/forum/scalability_with_lots_of_files/comment_1_b9bb0a71d81b8cbc2a751bb7bab84812._comment
new file mode 100644
index 0000000000..0a58c1c71d
--- /dev/null
+++ b/doc/forum/scalability_with_lots_of_files/comment_1_b9bb0a71d81b8cbc2a751bb7bab84812._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-04T19:21:07Z"
+ content="""
+Git automatically packs loose object files after a while, which includes
+git-annex branch files. See `git-gc --help`.
+
+It also delta compresses files, and git-annex's log files will delta
+compress and compress pretty well, so your du's of a checked out git-annex
+branch don't mean much.
+
+As far as I can tell, your git repository is 118mb in size, including
+the git-annex branch and all history.
+
+You can use `git annex forget` to drop historical location tracking
+info for files.
+"""]]
diff --git a/doc/forum/schedule_repository___91__expression__93__.mdwn b/doc/forum/schedule_repository___91__expression__93__.mdwn
new file mode 100644
index 0000000000..0904dbb03a
--- /dev/null
+++ b/doc/forum/schedule_repository___91__expression__93__.mdwn
@@ -0,0 +1 @@
+what sort of options can we use in the expression field? from the [git annex bible](http://git-annex.branchable.com/git-annex/) it suggests for incremental fscks, but I'm wondering if it can run shell scripts or `git annex importurl` lines too.
diff --git a/doc/forum/schedule_repository___91__expression__93__/comment_1_b123b657a92897017973927e3e47673b._comment b/doc/forum/schedule_repository___91__expression__93__/comment_1_b123b657a92897017973927e3e47673b._comment
new file mode 100644
index 0000000000..a0c4e82221
--- /dev/null
+++ b/doc/forum/schedule_repository___91__expression__93__/comment_1_b123b657a92897017973927e3e47673b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 1"
+ date="2014-09-16T18:13:18Z"
+ content="""
+Only fscking can be scheduled. From the man page:
+
+       These  actions  are available: \"fsck self\", \"fsck UUID\" 
+
+It won't be expanded to allow arbitrary commands, because that would let anyone who you share an annex with schedule arbitrary commands to run on your computer..
+"""]]
diff --git a/doc/forum/script_to_generate___34__.hidden__34___files_for_files_not_in_local_remote.mdwn b/doc/forum/script_to_generate___34__.hidden__34___files_for_files_not_in_local_remote.mdwn
new file mode 100644
index 0000000000..efb3d1caf7
--- /dev/null
+++ b/doc/forum/script_to_generate___34__.hidden__34___files_for_files_not_in_local_remote.mdwn
@@ -0,0 +1,8 @@
+Hello,
+
+I would like to know if someone made a script to generate ".hidden" files listing all files in a git annex repository which are not available in the local remote (and also listing all directories where all files within are not available in the local remote).
+
+I'm not a prgrammer myself, but I will try to make this with a script greping in "git annex whereis" all files which are not available "[here]". But if somebody has a better idea (git annex view?) or wants to try :-)
+
+Best,  
+Hugo
diff --git a/doc/forum/script_to_generate___34__.hidden__34___files_for_files_not_in_local_remote/comment_1_76453756be78f06ef3a3d7d1bf011b9f._comment b/doc/forum/script_to_generate___34__.hidden__34___files_for_files_not_in_local_remote/comment_1_76453756be78f06ef3a3d7d1bf011b9f._comment
new file mode 100644
index 0000000000..a565d56a14
--- /dev/null
+++ b/doc/forum/script_to_generate___34__.hidden__34___files_for_files_not_in_local_remote/comment_1_76453756be78f06ef3a3d7d1bf011b9f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-28T17:15:30Z"
+ content="""
+I don't know what those .hidden files are, but you will probably
+find it easier to use `git annex find` with some options to make
+it list the files you want. Eg:
+
+	git annex find --not --in here > .hidden
+"""]]
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__.mdwn b/doc/forum/security_risk_presented_by_remote.log__63__.mdwn
new file mode 100644
index 0000000000..c320c7e30c
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__.mdwn
@@ -0,0 +1,5 @@
+I am curious if remote.log in the repository (or anything in the repository for that matter) gives someone access to the data stored in the special remotes.
+
+If I'm using an encrypted s3 special remote, and someone gets access to the entire repository, will they be able to decrypt things? Or is the gpg stuff stored completely separately and therefore completely unaccessable, even if someone got access to the entire contents of the git repository?
+
+What is the cipher and the cipherkeys stored in git show git-annex:remote.log?
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__/comment_1_9715488033f2a8939a32ed12259377ba._comment b/doc/forum/security_risk_presented_by_remote.log__63__/comment_1_9715488033f2a8939a32ed12259377ba._comment
new file mode 100644
index 0000000000..2b2805adde
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__/comment_1_9715488033f2a8939a32ed12259377ba._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 1"
+ date="2015-06-24T00:30:32Z"
+ content="""
+it depends how you configured encryption. this is pretty well described in the [[encryption]] page, but basically, unless you used \"shared\" encryption, only the holders of the GPG private key material will be able to decrypt the contents. Objects are encrypted with GPG using a symmetric key, and that key is then encrypted with OpenPGP public keys.
+
+This is all pretty well described in [[encryption]]. --[[anarcat]]
+"""]]
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__/comment_2_40383346237de0bae4760dc85fefc348._comment b/doc/forum/security_risk_presented_by_remote.log__63__/comment_2_40383346237de0bae4760dc85fefc348._comment
new file mode 100644
index 0000000000..7dc3bd825b
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__/comment_2_40383346237de0bae4760dc85fefc348._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="digiuser"
+ subject="comment 2"
+ date="2015-06-24T00:51:44Z"
+ content="""
+I read the encryption page but I just want to know if I'm understanding it correctly.
+
+Let's say I initiated my remote with this command:
+
+    git annex initremote myremote type=S3 chunk=256MiB keyid=XXXXXXXX bucket=mybucket
+
+And then, I handed out my remote.log file to people publicly. Does that expose *any* security hole at all? Or is 100% of the information in remote.log secured using gpg?
+
+I would believe that people couldn't decrypt my file contents, but could they get into my bucket or my S3 account?
+"""]]
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__/comment_3_b1ddf06b34f750e9bbd88e6d5348e765._comment b/doc/forum/security_risk_presented_by_remote.log__63__/comment_3_b1ddf06b34f750e9bbd88e6d5348e765._comment
new file mode 100644
index 0000000000..2bc041b15b
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__/comment_3_b1ddf06b34f750e9bbd88e6d5348e765._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 3"
+ date="2015-06-24T01:17:23Z"
+ content="""
+> I read the encryption page but I just want to know if I'm understanding it correctly.
+
+I think you are understanding this correctly... let's see..
+
+> Let's say I initiated my remote with this command:
+>
+>     git annex initremote myremote type=S3 chunk=256MiB keyid=XXXXXXXX bucket=mybucket
+>
+> And then, I handed out my remote.log file to people publicly. Does that expose any security hole at all?
+
+It won't expose your S3 credentials, if that's what your are asking. Those are stored in `.git/annex/creds/` and not in the git-annex branch. You can see the content of `remote.log` yourself with:
+
+    git cat-file -p git-annex:remote.log
+
+... if that helps you at all..
+
+>  Or is 100% of the information in remote.log secured using gpg?
+
+Well, it *would* expose the bucket name and the GPG key id (\"XXXXXXXX\") that you set there. The remote.log, itself, is *not* encrypted with gpg, from what I understand. Or to put it another way, the `remote.log` is not actually sent to the S3 remote there, and if you put the git repo publicly, then its content will be publicly readable. To protect against that, you would need a [[special_remotes/gcrypt]] remote.
+
+> I would believe that people couldn't decrypt my file contents, but could they get into my bucket or my S3 account?
+
+Not unless they have the S3 credentials, no. Furthermore, if the bucket is not publicly readable (see [[tips/public_Amazon_S3_remote/]] for that), they won't be able to get the file contents either. And *even* if it is public, they would get the *encrypted* content which they couldn't decrypt without the private key associated with the keyid you supplied.
+"""]]
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__/comment_4_428bbced6406a35eb093a27e35831f38._comment b/doc/forum/security_risk_presented_by_remote.log__63__/comment_4_428bbced6406a35eb093a27e35831f38._comment
new file mode 100644
index 0000000000..0b653de604
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__/comment_4_428bbced6406a35eb093a27e35831f38._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="digiuser"
+ subject="comment 4"
+ date="2015-06-24T01:30:26Z"
+ content="""
+What is `s3creds` in `remote.log` then? Something base64 encoded that is named suspiciously like creds for logging into s3?
+"""]]
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__/comment_5_df1eab397c8e08698064391438bbff1b._comment b/doc/forum/security_risk_presented_by_remote.log__63__/comment_5_df1eab397c8e08698064391438bbff1b._comment
new file mode 100644
index 0000000000..4076cd295b
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__/comment_5_df1eab397c8e08698064391438bbff1b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 5"
+ date="2015-06-24T01:34:11Z"
+ content="""
+interesting! i don't see that here, maybe that could be a problem there. my s3 remote doesn't use encryption, so maybe i don't have this problem...
+
+i don't know!
+"""]]
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__/comment_6_6a3911dc346d506d4350b5aec7619462._comment b/doc/forum/security_risk_presented_by_remote.log__63__/comment_6_6a3911dc346d506d4350b5aec7619462._comment
new file mode 100644
index 0000000000..0b331bfcc2
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__/comment_6_6a3911dc346d506d4350b5aec7619462._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2015-07-02T20:23:48Z"
+ content="""
+There are two cases there s3creds= can be in the remote.log.
+
+If you enabled gpg encryption, it stores the S3 creds there, encrypted with
+the gpg key you told it to use. So you can share the repo to users who don't
+have the gpg key, and they cannot access the S3 login credentials.
+
+If you didn't use gpg encryption, and you manually set `embedcreds=yes`
+then the s3creds= will contain the un-encrypted creds. 
+And like the docs for embedcreds says, you then need to be careful who
+you give the git repo to, since they can then access those S3 credentials.
+This is not a default configuration.
+
+(There was also the [[upgrades/insecure_embedded_creds]] bug in 2014.
+But, git-annex will detect repos with that problem and warns very verbosely
+about it.)
+"""]]
diff --git a/doc/forum/seems_to_build_fine_on_haskell_platform_2011.mdwn b/doc/forum/seems_to_build_fine_on_haskell_platform_2011.mdwn
new file mode 100644
index 0000000000..60014a7f53
--- /dev/null
+++ b/doc/forum/seems_to_build_fine_on_haskell_platform_2011.mdwn
@@ -0,0 +1 @@
+This is just a comment on git-annex building on haskell platform 2011.2.0.0 on archlinux. It just works.
diff --git a/doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine.mdwn b/doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine.mdwn
new file mode 100644
index 0000000000..faf8f4d237
--- /dev/null
+++ b/doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine.mdwn
@@ -0,0 +1,28 @@
+Hello,
+
+git-annex looks very interesting and I would like it to version large binary artifacts for testing in our source code repository.
+
+My question:
+
+I want to have/can have multiple clones of the same repository on the same machine.
+However, as the binary files can be huge, I would like to store the files only exactly ONCE per machine and not again in the .git/annex/objects folder of each similar cloned repository.
+
+To achieve that, I first created in
+
+    /tmp/repo-clone1/.git/annex/objects
+
+and then symlinked
+
+    ln -s /tmp/repo-clone1/.git/annex/objects /tmp/repo-clone2/.git/annex/objects
+
+such that
+
+    /tmp/repo-clone1
+    /tmp/repo-clone2
+
+share the same big files and the big files are only once on the machine.
+
+Is this a good idea? Is there a better way to achieve this? Looks a bit hacky. Would be nicer if you can specify a dedicated "objects" folder from the start?!
+
+Thanks and Regards,
+J
diff --git a/doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/comment_1_1606849eb13b6069394455297395dc30._comment b/doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/comment_1_1606849eb13b6069394455297395dc30._comment
new file mode 100644
index 0000000000..bd7ece79d9
--- /dev/null
+++ b/doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/comment_1_1606849eb13b6069394455297395dc30._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="use hardlinks"
+ date="2015-05-29T01:40:21Z"
+ content="""
+that is a pretty bad idea! :) git-annex will believe it has two copy of the files and could allow you to drop the last copy, and loose data.
+
+instead, you should clone the repo with `--shared`, like this:
+
+    git clone --shared /tmp/repo-clone1 /tmp/repo-clone2
+
+according to the [[git-annex]] manpage, this will set the `annex.hardlink` setting and mark the repo as \"untrusted\". files will be hardlinked between the two repositories, using only the space once.
+
+see also [[todo/wishlist:_use_hardlinks_for_local_clones/]]. --[[anarcat]]
+"""]]
diff --git a/doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/comment_2_f60c43ec9d493db03e2a5a5595501e55._comment b/doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/comment_2_f60c43ec9d493db03e2a5a5595501e55._comment
new file mode 100644
index 0000000000..2d8d6e7d92
--- /dev/null
+++ b/doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/comment_2_f60c43ec9d493db03e2a5a5595501e55._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="davicastro"
+ avatar="http://cdn.libravatar.org/avatar/4e708663cf4d5b9e8cfea74caf4307fc"
+ subject="any drawbacks in using --shared (hardlinks) clones on same Linux machine?"
+ date="2018-01-07T00:37:10Z"
+ content="""
+Hi, I'm new to git and we might be adopting it on next project solely because of git annex!
+As our files are quite big, having users cloning the repository with --shared is very very nice!
+We use Linux, so no issue with hardlinks. I did some testing and so far so good. No duplicated space is very very nice!
+But I'm wondering: is there any disadvantage on this approach?
+"""]]
diff --git a/doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/comment_3_b041da6694d9d9d21a67f7bbdda0f62e._comment b/doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/comment_3_b041da6694d9d9d21a67f7bbdda0f62e._comment
new file mode 100644
index 0000000000..0a48c1ca63
--- /dev/null
+++ b/doc/forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/comment_3_b041da6694d9d9d21a67f7bbdda0f62e._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-01-10T17:24:04Z"
+ content="""
+@davicastro using --shared makes git-annex not trust the shared clone, 
+which is necessary to avoid situations that could result in data loss.
+The downside though, is that the lack of trust can change git-annex
+behavior in some situations.
+
+For example, normally you can run `git annex get myfile` and then `git
+annex drop myfile --from someremote` will remove it from the remote, since
+you now have a local copy. But, with the shared clone being untrusted, the
+drop will fail if it would be the only remaining copy of the file. In
+this situation, you would need to first `git annex copy myfile --to origin`
+or something like that before dropping.
+
+Of course, that copy would run fast and cheap since it only has to make a
+hardlink!
+"""]]
diff --git a/doc/forum/shared_cipher_tries_to_use_gpg.mdwn b/doc/forum/shared_cipher_tries_to_use_gpg.mdwn
new file mode 100644
index 0000000000..ccaa0c59d6
--- /dev/null
+++ b/doc/forum/shared_cipher_tries_to_use_gpg.mdwn
@@ -0,0 +1,10 @@
+I tried 
+
+    git annex initremote encsharedtest type=directory encryption=shared directory=/home/lee/gitannexplay
+
+and got errors:
+
+    initremote encsharedtest gpg: error reading key: public key not found
+
+Looks like it thinks "shared" should be the name of a key rather than an instruction to use the shared cipher.
+Am I doing something wrong?
diff --git a/doc/forum/shared_cipher_tries_to_use_gpg/comment_1_760961eaaa7d5c254dd71c5792437c9e._comment b/doc/forum/shared_cipher_tries_to_use_gpg/comment_1_760961eaaa7d5c254dd71c5792437c9e._comment
new file mode 100644
index 0000000000..e97118b8a7
--- /dev/null
+++ b/doc/forum/shared_cipher_tries_to_use_gpg/comment_1_760961eaaa7d5c254dd71c5792437c9e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.23"
+ subject="comment 1"
+ date="2012-10-23T19:51:03Z"
+ content="""
+That's the right syntax, and it works when I try it, even if I move my `~/.gnupg` directory away.
+
+You sure you have a new enough git-annex for the shared cipher feature? It appeared in version 3.20120430
+
+You could try passing the `--debug` option to see what it's trying to do with gpg when it fails.
+"""]]
diff --git a/doc/forum/shared_cipher_tries_to_use_gpg/comment_2_f3260aea3a5bb9b95a9bdf1d0dfce090._comment b/doc/forum/shared_cipher_tries_to_use_gpg/comment_2_f3260aea3a5bb9b95a9bdf1d0dfce090._comment
new file mode 100644
index 0000000000..7c36e7cf4d
--- /dev/null
+++ b/doc/forum/shared_cipher_tries_to_use_gpg/comment_2_f3260aea3a5bb9b95a9bdf1d0dfce090._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlFUH5H4OUj9vMJIoXQs8bheiptgANQ6fU"
+ nickname="lee"
+ subject="A little too old"
+ date="2012-10-23T20:47:40Z"
+ content="""
+That's the problem, then. I have 3.20120406. For my purposes a gpg key with no passphrase works, though. Thanks.
+"""]]
diff --git a/doc/forum/short_exlusive_refspec_notation_for_git_annex_unused_.mdwn b/doc/forum/short_exlusive_refspec_notation_for_git_annex_unused_.mdwn
new file mode 100644
index 0000000000..a7499cc2e6
--- /dev/null
+++ b/doc/forum/short_exlusive_refspec_notation_for_git_annex_unused_.mdwn
@@ -0,0 +1,22 @@
+Hello!
+
+
+In relation to the description of `--used-refspec` in the docs https://git-annex.branchable.com/git-annex-unused/ 
+I was wondering why it is possible to add a positive refspec without the full path of the ref e.g.
+
+`git annex unused --used-refspec  +master`
+
+while for exclusions (negative refspec) it seems to be necessary to specify the full path, e.g.
+
+`git annex unused --used-refspec  '+*:-refs/heads/master'`
+
+or globbing:
+
+`git annex unused --used-refspec  '+*:-*master'`
+
+I guess the negative form of 
+
+> Each + without a glob adds the literal value to the set.  For example, "+HEAD^" adds "HEAD^".
+
+is actually (intentionally) missing. 
+If so, this might be worth noting in the docs.
diff --git a/doc/forum/short_exlusive_refspec_notation_for_git_annex_unused_/comment_1_0aeb5702e74fcf158f1e9aca16ca9e6b._comment b/doc/forum/short_exlusive_refspec_notation_for_git_annex_unused_/comment_1_0aeb5702e74fcf158f1e9aca16ca9e6b._comment
new file mode 100644
index 0000000000..4184ccff89
--- /dev/null
+++ b/doc/forum/short_exlusive_refspec_notation_for_git_annex_unused_/comment_1_0aeb5702e74fcf158f1e9aca16ca9e6b._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-04-09T15:16:12Z"
+ content="""
+       Each - is matched against the set of refs accu‐
+       mulated  so far.  Any matching refs are removed
+       from the set.
+
+It matches against the literal text of the ref that was added, so if you
+ use "+*", it adds refs/heads/master, and then to remove that, you need
+ "-refs/heads/master" not "-master". On the other hand, "+master:-master"
+results in "master" being added and then removed.
+
+Clarified to mention that it matches by name; I suppose perhaps you were
+thinking it matches based on what sha1 the ref name resolves to. The reason it
+doesn't do that is that it would be surprising for "+foo:-master" to not include
+ref foo just because it happens to currently have the same sha1 as master does.
+"""]]
diff --git a/doc/forum/slow_ikiwiki_server__63__.mdwn b/doc/forum/slow_ikiwiki_server__63__.mdwn
new file mode 100644
index 0000000000..97197061ea
--- /dev/null
+++ b/doc/forum/slow_ikiwiki_server__63__.mdwn
@@ -0,0 +1 @@
+The ikiwiki server hosting this forum seems to take much longer to finish posting a message/comment than it used to.  Not a big deal, but wondering if anyone else has noticed this?
diff --git a/doc/forum/slow_ikiwiki_server__63__/comment_1_f734812a94c0f6c7612257f82e0c4b36._comment b/doc/forum/slow_ikiwiki_server__63__/comment_1_f734812a94c0f6c7612257f82e0c4b36._comment
new file mode 100644
index 0000000000..d48a263377
--- /dev/null
+++ b/doc/forum/slow_ikiwiki_server__63__/comment_1_f734812a94c0f6c7612257f82e0c4b36._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-06-21T17:13:52Z"
+ content="""
+Ikiwiki slows down the more files there are, so removing old
+closed bug reports and comments on them periodically is mostly how this is
+dealt with. I've deleted ones from before 2020, which shrank the number of
+files by 10%.
+
+It's worth noting that 1/3 of the remaining files are in this forum,
+more than the remaining bugs+todos. Of course splitting it is an option,
+but I wonder how useful 10 year old posts in it actually are..
+"""]]
diff --git a/doc/forum/slow_ikiwiki_server__63__/comment_2_1eb8334b06b784211eb93405dbf93a77._comment b/doc/forum/slow_ikiwiki_server__63__/comment_2_1eb8334b06b784211eb93405dbf93a77._comment
new file mode 100644
index 0000000000..41fafd9181
--- /dev/null
+++ b/doc/forum/slow_ikiwiki_server__63__/comment_2_1eb8334b06b784211eb93405dbf93a77._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="old comments"
+ date="2021-06-22T14:03:23Z"
+ content="""
+Being able to search through old comments has actually been useful at times.  If what matters is the number of files and not their total size, maybe the text of the removed comments could be merged into one still-searchable file?
+"""]]
diff --git a/doc/forum/slow_ikiwiki_server__63__/comment_3_d73e4ff5f273160a3df5590ebafd440c._comment b/doc/forum/slow_ikiwiki_server__63__/comment_3_d73e4ff5f273160a3df5590ebafd440c._comment
new file mode 100644
index 0000000000..8e70ae2ca6
--- /dev/null
+++ b/doc/forum/slow_ikiwiki_server__63__/comment_3_d73e4ff5f273160a3df5590ebafd440c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-06-23T16:54:02Z"
+ content="""
+To be clear, I've only removed comments on old closed bug reports that were
+also removed. Not old comments generally.
+
+It does seem at least possible that compiling a comment thread into a
+single page might speed up ikiwiki.
+"""]]
diff --git a/doc/forum/slow_s3_transfer.mdwn b/doc/forum/slow_s3_transfer.mdwn
new file mode 100644
index 0000000000..072043f5c9
--- /dev/null
+++ b/doc/forum/slow_s3_transfer.mdwn
@@ -0,0 +1,20 @@
+Hi,
+
+I am experiencing slow transfer (UL/DL) speed with an S3-compatible remote.
+Here is the configuration:
+
+-Minio server for S3 storage in docker.
+
+-Nginx for https in docker.
+
+-git-annex (and datalad) with the S3 set as a remote, without public URL to control access.
+
+I tried to get files directly from the server to remove all the network factors.
+
+When downloading from the Minio server through nginx with wget, I have transfer rates of about 50-60MB/s.
+
+When running `git annex get` on the same file, the transfer rate is about 6-7MB/s.
+
+Any idea why git-annex would slow the transfer?
+
+Thanks
diff --git a/doc/forum/slow_s3_transfer/comment_1_a6e3f8579447d85c22f3bb99c4e6cf0d._comment b/doc/forum/slow_s3_transfer/comment_1_a6e3f8579447d85c22f3bb99c4e6cf0d._comment
new file mode 100644
index 0000000000..883f530d87
--- /dev/null
+++ b/doc/forum/slow_s3_transfer/comment_1_a6e3f8579447d85c22f3bb99c4e6cf0d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-10-08T18:48:28Z"
+ content="""
+Nothing immediately comes to mind, except perhaps wget is using a larger
+buffer or significantly less CPU or something like that.
+
+Is git-annex CPU bound when doing this? Ie, does top show it using 100% of
+a CPU?
+"""]]
diff --git a/doc/forum/slow_s3_transfer/comment_2_f66a8d597de5065049a9a9b245166540._comment b/doc/forum/slow_s3_transfer/comment_2_f66a8d597de5065049a9a9b245166540._comment
new file mode 100644
index 0000000000..af4f64fb4f
--- /dev/null
+++ b/doc/forum/slow_s3_transfer/comment_2_f66a8d597de5065049a9a9b245166540._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="basile.pinsard@f1a7fae9f3bd9d5282fca11f62ad53b45a8eb317"
+ nickname="basile.pinsard"
+ avatar="http://cdn.libravatar.org/avatar/87e1f73acf277ad0337b90fc0253c62e"
+ subject="comment 2"
+ date="2019-10-16T20:40:21Z"
+ content="""
+Sorry for the late reply.
+
+Yes git-annex is CPU bound when downloading for instance.
+
+Could this just be the fact of using https for transfer?
+
+Thanks, I wouldn't have thought this to be the limitation.
+"""]]
diff --git a/doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat.mdwn b/doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat.mdwn
new file mode 100644
index 0000000000..ed0ffb5f34
--- /dev/null
+++ b/doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat.mdwn
@@ -0,0 +1,26 @@
+Hello,
+
+I'm starting to use git annex as a replacement for unison to sync/backup my family pictures.
+It looks very promising, thank you very much for all this work!
+
+My big plan (for now) is to use git annex
+
+* on my Linux home server
+* on my mac OS laptop
+* on a (big) USB drive, that I could plug either on the server (at home) or the laptop (during holidays)
+
+Since I want the USB drive to be usable from both Linux and mac OS, I picked FAT as a file system.
+
+I first tried to set up a bare repository on the USB drive, but did hit the [[bugs/VFAT_crazy_limit_on_max_filenames_in_directory]].
+So I used a "directory" special remote, and copied files from the server. It works fine.
+
+I then created the SSH remote on the laptop and synced some content. It works quite well too.
+
+I would now like to plug the USB drive on the laptop and tell it
+"hey, this is the same remote as the one you've seen from the server, just mounted somewhere else"
+(the path is `/Volumes/usbdrive/annex` on the laptop and `/media/usbdrive/annex` on the server).
+
+The [[special_remotes/directory]] doc suggests it is possible, but I don't know how.
+Shall I copy the relevant bit from the server `.git/config`, keeping the UUID and tweaking the mount point?
+
+Thank you!
diff --git a/doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat/comment_1_a6f0ae755b9e24fd0de5868b57c6a497._comment b/doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat/comment_1_a6f0ae755b9e24fd0de5868b57c6a497._comment
new file mode 100644
index 0000000000..73c60f3b39
--- /dev/null
+++ b/doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat/comment_1_a6f0ae755b9e24fd0de5868b57c6a497._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~barthelemy"
+ nickname="barthelemy"
+ avatar="http://cdn.libravatar.org/avatar/e99cb15f6029de3225721b3ebdd0233905eb69698e9b229a8c4cc510a4135438"
+ subject="I found it out!"
+ date="2017-05-05T12:41:59Z"
+ content="""
+On the laptop, I just have to run
+
+    git annex enableremote usbdrive directory=/Volumes/usbdrive/annex
+
+But I have not found a way to disable it (for use when the drive is unplugged) yet. It may not matter.
+"""]]
diff --git a/doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat/comment_2_9fe4a596aea6bd1a898b4c235126dce2._comment b/doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat/comment_2_9fe4a596aea6bd1a898b4c235126dce2._comment
new file mode 100644
index 0000000000..1ef9386c49
--- /dev/null
+++ b/doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat/comment_2_9fe4a596aea6bd1a898b4c235126dce2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-05-09T17:48:24Z"
+ content="""
+The directory= parameter to enableremote only affects the local
+configuration of that remote, it's not stored anywhere. Which is why you
+have to pass that parameter each time you're enabling that same
+directory remote in different repositories.
+
+So, it's fine to have directory= set to different values in different
+repositories, or even to re-run enableremote with a new directory= setting
+as needed.
+"""]]
diff --git a/doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat/comment_3_02eae41ba9ad2f2fb15cbd20069bf1da._comment b/doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat/comment_3_02eae41ba9ad2f2fb15cbd20069bf1da._comment
new file mode 100644
index 0000000000..f9803584ef
--- /dev/null
+++ b/doc/forum/sneakernet_with_a___34__directory__34___special_remote_on_fat/comment_3_02eae41ba9ad2f2fb15cbd20069bf1da._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~barthelemy"
+ nickname="barthelemy"
+ avatar="http://cdn.libravatar.org/avatar/e99cb15f6029de3225721b3ebdd0233905eb69698e9b229a8c4cc510a4135438"
+ subject="comment 3"
+ date="2017-05-09T23:38:27Z"
+ content="""
+Hi Joel,
+thank you for the precision (and for git annex, and for all the rest!)
+Cheers
+"""]]
diff --git a/doc/forum/some_symlinks_left_in_direct_mode.mdwn b/doc/forum/some_symlinks_left_in_direct_mode.mdwn
new file mode 100644
index 0000000000..1f4e447ee0
--- /dev/null
+++ b/doc/forum/some_symlinks_left_in_direct_mode.mdwn
@@ -0,0 +1,5 @@
+Dear all,
+   I have a repository in direct mode which still has some symlinks pointing to .git/annex/objects. Is there a way to turn them back into regular files. I don't recall why this happen, I guess I started on indirect mode and after that I converted it to direct mode.
+Thanks in advance.
+Best regards,
+              Juan
diff --git a/doc/forum/some_symlinks_left_in_direct_mode/comment_1_fd8d8107861453f0aa6b2c390e369307._comment b/doc/forum/some_symlinks_left_in_direct_mode/comment_1_fd8d8107861453f0aa6b2c390e369307._comment
new file mode 100644
index 0000000000..29e8b7490d
--- /dev/null
+++ b/doc/forum/some_symlinks_left_in_direct_mode/comment_1_fd8d8107861453f0aa6b2c390e369307._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-12-02T18:53:32Z"
+ content="""
+Well, it's normal to have broken symlinks if the content of a file
+is not present. `git annex get` will get the file content
+and replace the symlink with it.
+
+If the symlink is not broken, you can run `git annex fsck` on the file
+and it will notice and fix this inconsistency. 
+
+Some old versions of git-annex had bugs in direct mode that could result
+in files being left as symlinks like that. I have not seen any bugs
+lately in that area. If you have a way to get a repository into that
+state, file a bug report with a test case.
+"""]]
diff --git a/doc/forum/some_symlinks_left_in_direct_mode/comment_2_63f61caf28e834d48e12467bf09b2e3d._comment b/doc/forum/some_symlinks_left_in_direct_mode/comment_2_63f61caf28e834d48e12467bf09b2e3d._comment
new file mode 100644
index 0000000000..47d8a5bec8
--- /dev/null
+++ b/doc/forum/some_symlinks_left_in_direct_mode/comment_2_63f61caf28e834d48e12467bf09b2e3d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmTNrhkVQ26GBLaLD5-zNuEiR8syTj4mI8"
+ nickname="Juan"
+ subject="going back to indirect mode fixed it"
+ date="2014-12-03T18:35:58Z"
+ content="""
+I went back to indirect mode and stayed there. Every file is now accesible. I don't know what happened.
+Thanks.
+"""]]
diff --git a/doc/forum/something_really_good_happened_with_3.20130124.mdwn b/doc/forum/something_really_good_happened_with_3.20130124.mdwn
new file mode 100644
index 0000000000..73b2838222
--- /dev/null
+++ b/doc/forum/something_really_good_happened_with_3.20130124.mdwn
@@ -0,0 +1,5 @@
+The web app used to be unresponsive without manual refreshes.  Now it's all snappy and responsive and quickly reflects what the assistant is doing.
+
+It used to be a complete crapshoot whether the assistant actually shut down when you told it to (either on the command line or through the webapp).  I used to have to manually kill leftover assistants and child processes routinely.  Now... you want it gone, and it's gone instantly, every time.
+
+Something really good happened with this last version, thank you joey!
diff --git a/doc/forum/something_really_good_happened_with_3.20130124/comment_1_1712bddd2f483a353f6313aa626445f1._comment b/doc/forum/something_really_good_happened_with_3.20130124/comment_1_1712bddd2f483a353f6313aa626445f1._comment
new file mode 100644
index 0000000000..e0a4907c68
--- /dev/null
+++ b/doc/forum/something_really_good_happened_with_3.20130124/comment_1_1712bddd2f483a353f6313aa626445f1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 1"
+ date="2013-01-25T22:35:00Z"
+ content="""
+We fixed some broken javascript that only worked in all the browsers I tried, but not yours. It's always been this cool, just glad you can also experience it now!
+"""]]
diff --git a/doc/forum/sparse_git_checkouts_with_annex.mdwn b/doc/forum/sparse_git_checkouts_with_annex.mdwn
new file mode 100644
index 0000000000..97d2f445d3
--- /dev/null
+++ b/doc/forum/sparse_git_checkouts_with_annex.mdwn
@@ -0,0 +1,31 @@
+I checked in my music collection into git annex (about 25000 files) and i'm really impressed by the performance of git annex (after i've done an git-repack). Now i'm also moving my movies into the same git-annex, but i have the following layout of my disk drives:
+
+* small raid-1 for important stuff (music, documents), which is also backupped (aka: raid)
+* big bulk data store (aka: media)
+
+In the git-annex the following layout of files is used:
+
+* documents/ <- on raid
+* music/ <- on raid
+* videos/ <- on media
+
+Now i didn't simply clone the raid-annex to media, but did an sparse-checkout (possible since version 1.7.0)
+
+* raid: .git-annex/, documents/ and music
+* media: .git-annex/, videos/
+
+As you can see i have to checkout the .git-annex directory with the file-logs twice which slows down git operations. Everything else works fine until now. git-annex doesn't have any problem, that only a part of the symlinks are present, which is really great. Is there a possibility to sparse checkout the .git-annex directory also? Perhaps splitting the log files in .git-annex/ into N subfolders, corresponding to the toplevel subfolders, like this?
+
+Before:
+
+     $ ls .git-annex
+     00 01 02....
+
+After:
+
+     $ ls .git-annex
+     documents/ music/ videos/
+     $ ls .git-annex/documents
+     00 01 02....
+
+This would make it possible to checkout only the part of the log files which i'm interested in.
diff --git a/doc/forum/sparse_git_checkouts_with_annex/comment_1_c7dc199c5740a0e7ba606dfb5e3e579a._comment b/doc/forum/sparse_git_checkouts_with_annex/comment_1_c7dc199c5740a0e7ba606dfb5e3e579a._comment
new file mode 100644
index 0000000000..7adf4fc4d6
--- /dev/null
+++ b/doc/forum/sparse_git_checkouts_with_annex/comment_1_c7dc199c5740a0e7ba606dfb5e3e579a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-04-07T16:32:04Z"
+ content="""
+That's awesome, I had not heard of git sparse checkouts before. 
+
+It does not make sense to tie the log files to the directory of the corresponding files, as then the logs would have to move when the files are moved, which would be a PITA and likely make merging log file changes very complex. Also, of course, multiple files in different locations can point at the same content, which has the same log file. And, to cap it off, git-annex can need to access the log file for a given key without having the slightest idea what file in the repository might point to it, and it would be very expensive to scan the whole repository to find out what that file is in order to lookup the filename of the log file.
+
+The most likely change in git-annex that will make this better is in [[this_todo_item|todo/branching]] -- but it's unknown how to do it yet.
+"""]]
diff --git a/doc/forum/sparse_git_checkouts_with_annex/comment_2_e357db3ccc4079f07a291843975535eb._comment b/doc/forum/sparse_git_checkouts_with_annex/comment_2_e357db3ccc4079f07a291843975535eb._comment
new file mode 100644
index 0000000000..d8088a2d82
--- /dev/null
+++ b/doc/forum/sparse_git_checkouts_with_annex/comment_2_e357db3ccc4079f07a291843975535eb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-04-07T16:33:30Z"
+ content="""
+BTW, git-annex unused *will* have a problem that not all the symlinks are present. It will suggest dropping content belonging to the excluded symlinks.
+"""]]
diff --git a/doc/forum/sparse_git_checkouts_with_annex/comment_3_fcfafca994194d57dccf5319c7c9e646._comment b/doc/forum/sparse_git_checkouts_with_annex/comment_3_fcfafca994194d57dccf5319c7c9e646._comment
new file mode 100644
index 0000000000..1b849ef891
--- /dev/null
+++ b/doc/forum/sparse_git_checkouts_with_annex/comment_3_fcfafca994194d57dccf5319c7c9e646._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkptNW1PzrVjYlJWP_9e499uH0mjnBV6GQ"
+ nickname="Christian"
+ subject="comment 3"
+ date="2011-04-08T07:31:03Z"
+ content="""
+So perhaps checking if git-status (or similar) complains about missing files is a possible solution for this?
+"""]]
diff --git a/doc/forum/sparse_git_checkouts_with_annex/comment_4_04dc14880f31eee2b6d767d4d4258c5a._comment b/doc/forum/sparse_git_checkouts_with_annex/comment_4_04dc14880f31eee2b6d767d4d4258c5a._comment
new file mode 100644
index 0000000000..9280fc51da
--- /dev/null
+++ b/doc/forum/sparse_git_checkouts_with_annex/comment_4_04dc14880f31eee2b6d767d4d4258c5a._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkptNW1PzrVjYlJWP_9e499uH0mjnBV6GQ"
+ nickname="Christian"
+ subject="comment 4"
+ date="2011-04-08T07:54:37Z"
+ content="""
+And something else i've done is, that i symlinked the video/ directory from the media annex to the normal raid annex
+
+    ln -s ~/media/annex/video ~/annex
+
+And it's working out great.
+
+    ~annex $ git annex whereis video/series/episode1.avi
+    whereis video/series/episode1.avi(1 copy)
+        	f210b45a-60d3-11e0-b593-3318d96f2520  -- Trantor - Media
+    ok
+
+I really like this, perhaps it is a good idea to store all log files in every repo, but maybe there is a possibilitiy to to pack multiple log files into one single file, where not only the time, the present bit and the annex-repository is stored, but also the file key. I don't know if this format would also be merged correctly by the union merge driver.
+
+"""]]
diff --git a/doc/forum/special_remote_for_IMAP.mdwn b/doc/forum/special_remote_for_IMAP.mdwn
new file mode 100644
index 0000000000..2aa9565515
--- /dev/null
+++ b/doc/forum/special_remote_for_IMAP.mdwn
@@ -0,0 +1,44 @@
+I have implemented a special remote that stores files as email messages on an imap server. You need   to install three utilities that the hooks invoke to deal with the email: mutt, imaputils, and         munpack. I use mutt to send the email with the file as a mime attachment; imaputils talks to the imap server to check for and retrieve the message containing the desired file; and munpack extracts and    decodes the attachment to get our file back.
+
+Several programs could be used in place of mutt, but the latter has a convenient command-line option  for attaching files; mutt is of course available in the repositories of most linux distributions.
+
+imaputils is a perl program available at http://sourceforge.net/projects/imaputils/
+It has several perl library dependencies that you might need to download using the cpan tool.
+What imaputils does for you is provide a command line tool for interacting with the mail server. You  can search for mail with a particular subject (for example), delete mail, retrieve messages, and in   general do anything that you can do with a mail client such as mutt, but from the command line rather than a curses interface. This allows you to in turn write scripts that talk to imap servers.
+
+munpack is part of the mpack package. This is included in the Ubuntu and Debian repositories, and can probably be easily obtained for most linuxes. munpack extracts and decodes mime attachments from the  command line.
+
+I define the special remote with
+
+    git annex initremote hogneygmail type=hook encryption=gitannex hooktype=hogneygmail
+
+The pgp key "gitannex" is a key established just for this purpose, that has no passphrase. This       allows me to use encryption transparently. You could also use encryption=shared if your version of    git-annex is recent enough. I also did
+
+    git annex untrust hogneygmail
+
+Here are the hooks:
+
+        hogneygmail-store-hook = mutt -n -s $ANNEX_KEY -a $ANNEX_FILE -- {email address} < /dev/null
+        hogneygmail-checkpresent-hook = "(imaputils.pl --conf {imap config file} --subject $ANNEX_KEY --count | grep -q \"1 messages\" -) && echo $ANNEX_KEY"
+        hogneygmail-retrieve-hook =  "imaputils.pl --conf {imap config file} --subject $ANNEX_KEY --display | munpack -fq && mv $ANNEX_KEY $ANNEX_FILE; rm $ANNEX_KEY.desc"
+        hogneygmail-remove-hook = "imaputils.pl --conf {imap config file} --subject $ANNEX_KEY --delete"
+
+The bits inside of the curly brackets, for example {email address}, are what you need to specialize   for your particular case (removing the brackets as well). The {imap config file} is a file that       contains some configuration for imaputils. In my case it contains
+
+    ssl
+    pass {password}
+    host {mail host}
+    user {mail username}
+    box  {name of mailbox to check}
+
+The first line tells imaputils to use ssl, and the third line is the address of the mail host. I      include my username and password so I won't need to type these in repeatedly. Of course this means    that you need to protect this file carefully.
+
+
+
+The operation of the hooks is pretty straightforward. The store-hook attaches the file to an          otherwise empty email message with a subject equal to the name of the key, and mails it off. Note     that if you use encryption then the keys generated by git-annex here will not be the same ones you    see on your local disc. The checkpresent-hook asks the imap server how many emails have the subject   equal to the key we are looking for; only if the reply contains "1 messages" are we sure the right    one is there. The retrieve-hook uses the "--display" option to imaputils to stream the message, pipes it to munpack to silently extract the attachment (which is our (encrypted) file), and moves the       result into the file contents. It then cleans up by deleting the .desc file that I can't prevent      munpack from leaving on the disk, even when the message is blank. The remove-hook passes the "--      delete" option to imaputils to supposedly delete the target message from the mail server.
+
+I've performed very limited testing of this, and my knowledge of git and, especially, git-annex is    very primitive, so I'm sure this could be vastly improved. In my testing with gmail this seems to     work fine, except that messages do not get deleted from the server - I don't know why.
+
+I've developed this as an experiment and proof of concept, and have no knowledge of whether actually  using this is in accord with the terms of service of gmail or any other mail service you might be     using, nor whether it is safe or a good idea.
+
+-- Lee
diff --git a/doc/forum/special_remote_for_IMAP/comment_1_7c7d4b57a1b6508fff1a6b0508c861f8._comment b/doc/forum/special_remote_for_IMAP/comment_1_7c7d4b57a1b6508fff1a6b0508c861f8._comment
new file mode 100644
index 0000000000..8d81dcfd03
--- /dev/null
+++ b/doc/forum/special_remote_for_IMAP/comment_1_7c7d4b57a1b6508fff1a6b0508c861f8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="Neat idea"
+ date="2012-10-26T18:35:21Z"
+ content="""
+I imagine that most mail servers have a maximum attachment size; that seems the most likely problem with using this.
+
+The directory special remote has support for splitting up keys into chunks to work around file size limits. It would be good, I suppose, to add that to the hook special remote too.
+"""]]
diff --git a/doc/forum/special_remote_for_IMAP/comment_2_9c46fe8a857aa7a5ce797288144386bd._comment b/doc/forum/special_remote_for_IMAP/comment_2_9c46fe8a857aa7a5ce797288144386bd._comment
new file mode 100644
index 0000000000..50358ea53a
--- /dev/null
+++ b/doc/forum/special_remote_for_IMAP/comment_2_9c46fe8a857aa7a5ce797288144386bd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlFUH5H4OUj9vMJIoXQs8bheiptgANQ6fU"
+ nickname="lee"
+ subject="chunking"
+ date="2012-10-26T22:05:16Z"
+ content="""
+That's a good point. But the splitting could easily be added to the hooks, and wouldn't need to be built in to git-annex.
+"""]]
diff --git a/doc/forum/special_remote_for_IMAP/comment_3_27e3b644df6942ce4c103236d0d5cb1b._comment b/doc/forum/special_remote_for_IMAP/comment_3_27e3b644df6942ce4c103236d0d5cb1b._comment
new file mode 100644
index 0000000000..b5d9137e64
--- /dev/null
+++ b/doc/forum/special_remote_for_IMAP/comment_3_27e3b644df6942ce4c103236d0d5cb1b._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA"
+ nickname="Tobias"
+ subject="comment 3"
+ date="2013-05-22T09:53:47Z"
+ content="""
+I had to change the checkpresent hook to:
+
+	hogneygmail-checkpresent-hook = (imaputils.pl --subject $ANNEX_KEY --count | grep -q \\"1 messages\\" -) && echo $ANNEX_KEY || exit 0
+
+Also, i have 5 files more than 30MB in size, that refuse to transfer.
+
+ postdrop: warning: uid=1001: File too large
+ sendmail: fatal: tou(1001): message file too big
+ Error sending message, child exited 75 (Deferred.).
+ Could not send the message.
+
+  store hook exited nonzero!
+ failed
+
+This really needs some split operations to support large files.
+
+"""]]
diff --git a/doc/forum/special_remote_for_IMAP/comment_4_0f8e01c453afb02aebf44b3fb2c9a7c1._comment b/doc/forum/special_remote_for_IMAP/comment_4_0f8e01c453afb02aebf44b3fb2c9a7c1._comment
new file mode 100644
index 0000000000..6e39fd7307
--- /dev/null
+++ b/doc/forum/special_remote_for_IMAP/comment_4_0f8e01c453afb02aebf44b3fb2c9a7c1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmH7o6q2l99M-PQolOfbR3_i5B_jtTIcAE"
+ nickname="Giovanni"
+ subject="comment 4"
+ date="2014-09-12T18:57:07Z"
+ content="""
+Does this somehow scan the IMAP server for attachments already there?
+"""]]
diff --git a/doc/forum/special_remote_for_iPods.mdwn b/doc/forum/special_remote_for_iPods.mdwn
new file mode 100644
index 0000000000..eddda5936f
--- /dev/null
+++ b/doc/forum/special_remote_for_iPods.mdwn
@@ -0,0 +1,5 @@
+I know versions of this question have been asked before, but I'm looking for a different answer.
+
+I would like a braindead special remote that can be used with devices such as portable music players. No symbolic links, no hashing, no rewriting of the filenames. The remote can be untrusted, file identity can be checked with just the filename and maybe the size. The "directory" special remote with the WORM backend seems to come closest, but does too much. 
+
+Should I just try to roll it using hooks?
diff --git a/doc/forum/special_remote_for_iPods/comment_1_37cc3dc740341cc663074fd3bfb85947._comment b/doc/forum/special_remote_for_iPods/comment_1_37cc3dc740341cc663074fd3bfb85947._comment
new file mode 100644
index 0000000000..35ac105c15
--- /dev/null
+++ b/doc/forum/special_remote_for_iPods/comment_1_37cc3dc740341cc663074fd3bfb85947._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.149"
+ subject="comment 1"
+ date="2012-10-05T00:39:43Z"
+ content="""
+I've been thinking in similar directions on this page: [[design/assistant/desymlink]]
+"""]]
diff --git a/doc/forum/special_remote_which_applies_a_lossless_operation_in__47__out.mdwn b/doc/forum/special_remote_which_applies_a_lossless_operation_in__47__out.mdwn
new file mode 100644
index 0000000000..37a60bc341
--- /dev/null
+++ b/doc/forum/special_remote_which_applies_a_lossless_operation_in__47__out.mdwn
@@ -0,0 +1,9 @@
+Hi,
+
+I'd like to modify the directory special remote, to compress/deflate files before the store/retrieve operations. Purpose is to gain size, with a lossless compression, different depending on the file type (LZMA as a default, dropbox-lepton for jpegs, etc...).
+
+Before I go on, I wonder if the file content modification will interfere with git annex internals.
+It seems it won't, from what I see in the special remote basic exemple given in https://git-annex.branchable.com/special_remotes/external/
+Can someone confirm ?
+
+Thks
diff --git a/doc/forum/special_remote_which_applies_a_lossless_operation_in__47__out/comment_1_195f52aaaa36ce20955f2eb40af3c79a._comment b/doc/forum/special_remote_which_applies_a_lossless_operation_in__47__out/comment_1_195f52aaaa36ce20955f2eb40af3c79a._comment
new file mode 100644
index 0000000000..ea497a570e
--- /dev/null
+++ b/doc/forum/special_remote_which_applies_a_lossless_operation_in__47__out/comment_1_195f52aaaa36ce20955f2eb40af3c79a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-07T20:34:38Z"
+ content="""
+Of course that will work fine, as long as the operation is reversable.
+
+Plenty of existing special remotes
+compress/encrypt/slice/dice/mangle/obfuscate/whatever the content of files
+stored in them, and undo it all when the contents are retreived.
+"""]]
diff --git a/doc/forum/speed_up_assistant_startup_on_large_repositories.mdwn b/doc/forum/speed_up_assistant_startup_on_large_repositories.mdwn
new file mode 100644
index 0000000000..e43476c7b9
--- /dev/null
+++ b/doc/forum/speed_up_assistant_startup_on_large_repositories.mdwn
@@ -0,0 +1 @@
+Starting the assistant on a repository with a huge amount of files (f.e. `annexed files in working tree: 22087`) takes a very long time. Is there a way to speed it up? F.e. just checking the file stamps and comparing them with the last assistant run time? Checking if the files are modified could be done with the regular repository check. Thoughts?
diff --git a/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_1_5ba637a0f6d01ba24fe25e6265134e0a._comment b/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_1_5ba637a0f6d01ba24fe25e6265134e0a._comment
new file mode 100644
index 0000000000..0abe4dec8a
--- /dev/null
+++ b/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_1_5ba637a0f6d01ba24fe25e6265134e0a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-05T16:43:26Z"
+ content="""
+Checking the time stamps is what it does.
+
+How long is a very long time?
+"""]]
diff --git a/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_2_d65746697977f8971a4b59f5b413f926._comment b/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_2_d65746697977f8971a4b59f5b413f926._comment
new file mode 100644
index 0000000000..e6915d2328
--- /dev/null
+++ b/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_2_d65746697977f8971a4b59f5b413f926._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawne_amN4fko4p5cRY_9EYwaYuJKNn7LRio"
+ nickname="Tobias"
+ subject="measuring how-to"
+ date="2013-11-08T16:55:58Z"
+ content="""
+How can I measure how much time the startup scan takes? I tried to find it out using the debug log, but couldn't find any usable notice when the startup scan was finished. Maybe this two lines?
+
+    [...]
+    [2013-11-08 16:00:45 CET] Watcher: Performing startup scan
+    [...]
+    [2013-11-08 16:15:30 CET] Watcher: watching 
+"""]]
diff --git a/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_3_be6c4fe5a0c745688438b716973791cc._comment b/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_3_be6c4fe5a0c745688438b716973791cc._comment
new file mode 100644
index 0000000000..d3fe6ef4c8
--- /dev/null
+++ b/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_3_be6c4fe5a0c745688438b716973791cc._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2013-11-08T17:04:23Z"
+ content="""
+That's right.
+
+15 minutes is certainly a very long time.
+
+Is this on a slow spinning disk? USB disk?
+"""]]
diff --git a/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_4_a07472338a08c068a9b88b2176fc2bee._comment b/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_4_a07472338a08c068a9b88b2176fc2bee._comment
new file mode 100644
index 0000000000..41e69ab1e4
--- /dev/null
+++ b/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_4_a07472338a08c068a9b88b2176fc2bee._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
+ nickname="Tobias"
+ subject="comment 4"
+ date="2013-11-17T17:28:06Z"
+ content="""
+The mentioned repository is stored on spinning disk.
+Maybe it would help to store the .git directory on an SSD, but I'm not sure how to do it.
+"""]]
diff --git a/doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer.mdwn b/doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer.mdwn
new file mode 100644
index 0000000000..f40b083241
--- /dev/null
+++ b/doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer.mdwn
@@ -0,0 +1,28 @@
+I setup a local git annex repo and tried to pair it with an empty repo on my notebook. All done via the webapp.
+
+But pairing failed somehow, because I get this error while transfer seems to go on forever.
+
+    ssh_exchange_identification: read: Connection reset by peer
+    ssh_exchange_identification: read: Connection reset by peer
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+
+The webapp shows the remote repo as "unfinished repository".
+
+I can access the other computer via ssh and an other git-annex repo pairing between the two computers work fine.
+
+UPDATE: In the meantime I setup another paired repo on these two computers. Everything works fine. 
+
+I added the repos from scratch again and the same errors occurs again. The repositories which do not pair are the Documents folder on my desktop and on my macbook. Is there something special with macs documents folder?
+
+    [2013-12-31 10:53:23 CET] PushRetrier: Syncing with macbook.local_Documents 
+    fatal: 'macbook.local_Documents' does not appear to be a git repository
+    fatal: Could not read from remote repository.
+
+    Please make sure you have the correct access rights
+    and the repository exists.
+
+
+juh
diff --git a/doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer/comment_1_87b9540e37abb16c0ec7605f5ab204a5._comment b/doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer/comment_1_87b9540e37abb16c0ec7605f5ab204a5._comment
new file mode 100644
index 0000000000..b44c0c3b53
--- /dev/null
+++ b/doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer/comment_1_87b9540e37abb16c0ec7605f5ab204a5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Uic1ohv6"
+ ip="62.253.227.100"
+ subject="Are you using encfs?"
+ date="2014-01-09T16:30:50Z"
+ content="""
+I've seen similar error messages when the local annex was on an encfs-mounted decrypted directory. Seemingly git-annex tries to create SSH sockets in .git, and this goes wrong at least in some such situations.
+"""]]
diff --git a/doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer/comment_2_bd3383c142bf93d9cd496cb668d7782c._comment b/doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer/comment_2_bd3383c142bf93d9cd496cb668d7782c._comment
new file mode 100644
index 0000000000..719b66eb76
--- /dev/null
+++ b/doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer/comment_2_bd3383c142bf93d9cd496cb668d7782c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.43"
+ subject="comment 2"
+ date="2014-01-14T21:16:14Z"
+ content="""
+I tried using git-annex on encfs to see if I could reproduce this problem, and I could not get exactly this error, but I certianly did see it cause problems with the ssh connection caching socket.
+
+It would be a good idea to `git config annex.sshcaching false` in repositories stored on encfs. 
+
+Actually, given other reports of problems caused by encfs, it would be a good idea to not use git-annex on encfs. There are better ways to encrypt your files.
+"""]]
diff --git a/doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer/comment_3_9b1911ae6468d09dae74ab1a60d2757b._comment b/doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer/comment_3_9b1911ae6468d09dae74ab1a60d2757b._comment
new file mode 100644
index 0000000000..59f0f9f96f
--- /dev/null
+++ b/doc/forum/ssh__95__exchange__95__identification__58___read__58___Connection_reset_by_peer/comment_3_9b1911ae6468d09dae74ab1a60d2757b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnPgn611P6ym5yyL0BS8rUzO0_ZKRldMt0"
+ nickname="Samuel"
+ subject="What are those ?"
+ date="2014-01-31T07:37:49Z"
+ content="""
+Hi,
+
+Could you please indicate what other means of file encryption systems you have in mind?
+
+The others I know are at a partition level (cryptsetup, LUKS) and are less pratical to setup than a simple encfs.
+"""]]
diff --git a/doc/forum/ssh_key_setup_woes_in_Android.mdwn b/doc/forum/ssh_key_setup_woes_in_Android.mdwn
new file mode 100644
index 0000000000..87e2dd25ff
--- /dev/null
+++ b/doc/forum/ssh_key_setup_woes_in_Android.mdwn
@@ -0,0 +1,15 @@
+I'm trying to set up a ssh remote on Android using the latest 5.20140421. For some
+reason the assistant fails to set up passwordless login on the remote server. It
+adds the required line in `.ssh/authorized_keys` on the server side, but it still
+keeps asking for the password for every connection. Nothing suspicious appears in
+the assistant's log. Also, if I set up a ssh remote on a different directory on the
+same server, a new key is generated and added to `authorized_keys`, but the passwordless
+login still doesn't work.
+
+I didn't file a bug since this would make for a very lousy bug report. How could I
+look more into what's causing this? Where should the generated keys reside on the
+Android filesystem?
+
+I think it would be useful for the assistant to check that the generated ssh keys are
+working properly, and inform the user and/or try to set them up again if there is a
+problem, instead of silently falling back to asking for the login password on the console.
diff --git a/doc/forum/ssh_key_setup_woes_in_Android/comment_1_f16fbff27a449409699f3dbcf9590622._comment b/doc/forum/ssh_key_setup_woes_in_Android/comment_1_f16fbff27a449409699f3dbcf9590622._comment
new file mode 100644
index 0000000000..1b2d9a1859
--- /dev/null
+++ b/doc/forum/ssh_key_setup_woes_in_Android/comment_1_f16fbff27a449409699f3dbcf9590622._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="216.145.95.162"
+ subject="comment 1"
+ date="2014-05-19T15:50:34Z"
+ content="""
+There have been recent improvements in the assistant's handling of ssh keys. This includes no more prompting for ssh keys in the console, ever. Instead, the ssh remote setup would presumably fail if the ssh key didn't work for some reason.
+
+To debug your problem, you need to use the shell. I would first try running \"git annex get\" or \"git annex copy\" or \"git annex drop\" on a file, and verify that it prompts for the ssh password. Then, take a look at /sdcard/git-annex.home/.ssh/config, and see if you can ssh to the special hostname set up there, from android, and if it asks for a password. If so, ssh -v might be interesting, as it should show it presenting the ssh key to the server.
+"""]]
diff --git a/doc/forum/ssh_password.mdwn b/doc/forum/ssh_password.mdwn
new file mode 100644
index 0000000000..855e5992f6
--- /dev/null
+++ b/doc/forum/ssh_password.mdwn
@@ -0,0 +1,3 @@
+Currently I have my netbook running git annex and a raspberry pi as a remote storage set up as a git repository.  I currently have it set up so that from the terminal i can just do 'ssh pi@mypi -p XXX -C' and it has the password saved.  Currently I'm having a problem that any time I add a file to my annex folder on my netbook I have to reenter my password for ssh-askpass for it to upload the file.  Once that file is uploaded, it looks to me like it closes the connection and then reopens it and asks for my password again.
+
+I'm looking in ~/.ssh/ and I'm sure that something there needs to be edited or copied, I'm not really sure what though.  Any suggestions?
diff --git a/doc/forum/ssh_password/comment_1_a3e5a41e1d4da683d577976b134b11ee._comment b/doc/forum/ssh_password/comment_1_a3e5a41e1d4da683d577976b134b11ee._comment
new file mode 100644
index 0000000000..7ef9383309
--- /dev/null
+++ b/doc/forum/ssh_password/comment_1_a3e5a41e1d4da683d577976b134b11ee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://a-or-b.myopenid.com/"
+ ip="203.45.2.230"
+ subject="comment 1"
+ date="2013-05-30T00:08:52Z"
+ content="""
+It sounds like you don't have the ssh-agent set up properly in your environment.
+
+Try starting the git annex agent from the command line and see if that helps.  If it works then it is a problem with environment variables.
+"""]]
diff --git a/doc/forum/ssh_password/comment_2_fa261676a99d49d4b237b0d43048d76d._comment b/doc/forum/ssh_password/comment_2_fa261676a99d49d4b237b0d43048d76d._comment
new file mode 100644
index 0000000000..b7a47c9fe7
--- /dev/null
+++ b/doc/forum/ssh_password/comment_2_fa261676a99d49d4b237b0d43048d76d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-05-30T15:49:27Z"
+ content="""
+If you set this repository up using the git-annex webapp, and choosing \"remote ssh server\", it will generate a new ssh key, stored in `~/.ssh/git-annex/`, and it will configure `~/.ssh/config` to use this key for a special made-up hostname which is used in the url for the git remote. On the server, it will set up `~/.ssh/authorized_keys` to allow this ssh key to connect without a password and run git-annex-shell.
+
+I don't know if you used the webapp to set this up. If not, you can try to replicate this setup on your own. If you did and it's not working, you now know where all the peices it sets up are, to figure out what went wrong.
+"""]]
diff --git a/doc/forum/ssh_remote_-_no___34__use_a_git_repository__34___option_during_setup__63__.mdwn b/doc/forum/ssh_remote_-_no___34__use_a_git_repository__34___option_during_setup__63__.mdwn
new file mode 100644
index 0000000000..06b58f9738
--- /dev/null
+++ b/doc/forum/ssh_remote_-_no___34__use_a_git_repository__34___option_during_setup__63__.mdwn
@@ -0,0 +1,3 @@
+Hi,
+
+I own a computer that I use as a home server. I'm just getting started with git-annex, and I was trying to add an ssh remote. It connected fine, but only gave me the "encrypted rsync" option. I'd like to be able to access these files on the server as well, but the "use a git repository" option didn't show up. How do I enable this?
diff --git a/doc/forum/ssh_remote_-_no___34__use_a_git_repository__34___option_during_setup__63__/comment_1_7244794579a191a677190c60758f32e7._comment b/doc/forum/ssh_remote_-_no___34__use_a_git_repository__34___option_during_setup__63__/comment_1_7244794579a191a677190c60758f32e7._comment
new file mode 100644
index 0000000000..14e51e79a1
--- /dev/null
+++ b/doc/forum/ssh_remote_-_no___34__use_a_git_repository__34___option_during_setup__63__/comment_1_7244794579a191a677190c60758f32e7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmR-xG9O2HWoybxYZPVbYVYxwitfcfDgtE"
+ nickname="Charles"
+ subject="comment 1"
+ date="2013-09-09T00:29:14Z"
+ content="""
+Oh actually, I just clicked the available option and it gave me a \"connection refused\" due to my using a port other than 22. I edited the .ssh/config, but it decided to use 22 anyway?
+"""]]
diff --git a/doc/forum/ssh_remote_-_no___34__use_a_git_repository__34___option_during_setup__63__/comment_2_277cf12907bd7c5930eb4f137b115e29._comment b/doc/forum/ssh_remote_-_no___34__use_a_git_repository__34___option_during_setup__63__/comment_2_277cf12907bd7c5930eb4f137b115e29._comment
new file mode 100644
index 0000000000..55f50b3f55
--- /dev/null
+++ b/doc/forum/ssh_remote_-_no___34__use_a_git_repository__34___option_during_setup__63__/comment_2_277cf12907bd7c5930eb4f137b115e29._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmR-xG9O2HWoybxYZPVbYVYxwitfcfDgtE"
+ nickname="Charles"
+ subject="comment 2"
+ date="2013-09-09T14:50:42Z"
+ content="""
+Never mind, I simply didn't have git-annex installed on the other computer. I'm going to make a thread in bugs about assistant always assuming port 22, you can delete this thread.
+"""]]
diff --git a/doc/forum/ssh_vs_cifs__47__webdav.mdwn b/doc/forum/ssh_vs_cifs__47__webdav.mdwn
new file mode 100644
index 0000000000..62bb9d3d9a
--- /dev/null
+++ b/doc/forum/ssh_vs_cifs__47__webdav.mdwn
@@ -0,0 +1,7 @@
+Hello,
+
+I'm new to git-annex and I would like to know which is the best method to deploy it for my case. I would like to have a central repo in my Synology NAS but with files to be able to browse files (not a bare repo). This repo will not have remotes configured. The mobile clients will use the central repo to exchange files. I thinks that this setup is totally valid x-D. Now my question is more related to how to share the repo in the Synology NAS. I am considering to use cifs/webdav for LAN/WAN access to the repo or SSH for LAN/WAN access. Which is the recommended setup? Which is the most optimum setup in terms of bandwidth or cpu usage (the CPU of my synology NAS is ARM). Thanks in advance and for this great piece of software!
+
+Best regards,
+
+Christian
diff --git a/doc/forum/ssl_errors_with_special_remote.mdwn b/doc/forum/ssl_errors_with_special_remote.mdwn
new file mode 100644
index 0000000000..4e3196f649
--- /dev/null
+++ b/doc/forum/ssl_errors_with_special_remote.mdwn
@@ -0,0 +1,7 @@
+i recently have tried setting up my own webdav server to setup as a special remote for my git annex repositories.  This webdav server has been placed behind a reverse proxy.  At one point i ran into an issue with my reverse proxy and ended up having to get new sll certificates for it.  Now  whenever i try to push something to my webdav server i get this error 
+
+(InternalException (HandshakeFailed (Error_Protocol ("certificate has expired",True,CertificateExpired))))) failed
+
+i know my certificates are good because i am able to access the site normally and push from my other machine which had only gained access to the webdav server after the SSL certificate change.  
+
+is it possible to flush the known SSL certificates from git-annex?
diff --git a/doc/forum/ssl_errors_with_special_remote/comment_1_a3d68cc1af06c54d29818644a9943cc4._comment b/doc/forum/ssl_errors_with_special_remote/comment_1_a3d68cc1af06c54d29818644a9943cc4._comment
new file mode 100644
index 0000000000..5f2a293ff2
--- /dev/null
+++ b/doc/forum/ssl_errors_with_special_remote/comment_1_a3d68cc1af06c54d29818644a9943cc4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jenkin.schibel@286264d9ceb79998aecff0d5d1a4ffe34f8b8421"
+ nickname="jenkin.schibel"
+ avatar="http://cdn.libravatar.org/avatar/692d82fb5c42fc86d97cc44ae0fb61ca"
+ subject="problem fixed itself"
+ date="2020-07-04T03:27:58Z"
+ content="""
+so for some reason the problem fixed itself.  chances are that I am just a noob at how SSL stuff works.  If anyone could provide some possible insights as to why this might have happened so that I can learn from it, that would be much appreciated.
+"""]]
diff --git a/doc/forum/ssl_errors_with_special_remote/comment_2_6ef51ec4daa0c4d3abae22dafe6f068b._comment b/doc/forum/ssl_errors_with_special_remote/comment_2_6ef51ec4daa0c4d3abae22dafe6f068b._comment
new file mode 100644
index 0000000000..fa6e9e7023
--- /dev/null
+++ b/doc/forum/ssl_errors_with_special_remote/comment_2_6ef51ec4daa0c4d3abae22dafe6f068b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jenkin.schibel@286264d9ceb79998aecff0d5d1a4ffe34f8b8421"
+ nickname="jenkin.schibel"
+ avatar="http://cdn.libravatar.org/avatar/692d82fb5c42fc86d97cc44ae0fb61ca"
+ subject="problem fixed itself"
+ date="2020-07-04T03:28:26Z"
+ content="""
+so for some reason the problem fixed itself.  chances are that I am just a noob at how SSL stuff works.  If anyone could provide some possible insights as to why this might have happened so that I can learn from it, that would be much appreciated.
+"""]]
diff --git a/doc/forum/ssl_errors_with_special_remote/comment_3_d0e4921bd6d71c7b43418722008d2c22._comment b/doc/forum/ssl_errors_with_special_remote/comment_3_d0e4921bd6d71c7b43418722008d2c22._comment
new file mode 100644
index 0000000000..3d7a86b762
--- /dev/null
+++ b/doc/forum/ssl_errors_with_special_remote/comment_3_d0e4921bd6d71c7b43418722008d2c22._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-08-10T18:13:07Z"
+ content="""
+For the record: git-annex does not cache ssl certs, and it uses the
+system's ssl cert information. If you have a problem like this it's almost
+certainly a problem with your ssl cert or web server, or some caching in
+between git-annex and it.
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions.mdwn b/doc/forum/standalone_tarballs_for_specific_versions.mdwn
new file mode 100644
index 0000000000..b1d0b5acbe
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions.mdwn
@@ -0,0 +1,2 @@
+The page at https://git-annex.branchable.com/install/Linux_standalone/ has a link to the tarball for the standalone git-annex for the most recent version.
+Is it possible to make a page with link to stand-alone builds for specific git-annex versions?  This is for creating a conda-forge recipe, which requires a pointer to a stable URL for a given version.
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_10_3c41c48d40ae44129a80f2d2bef284ae._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_10_3c41c48d40ae44129a80f2d2bef284ae._comment
new file mode 100644
index 0000000000..7124b38954
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_10_3c41c48d40ae44129a80f2d2bef284ae._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="updating the standalone distribution"
+ date="2020-07-24T19:28:18Z"
+ content="""
+@joey, when you get a chance, could you add the standalone distribution for the current released version (8.20200720.1, not the bleeding-edge git) to the archive at downloads.kitenet.net?
+
+Would it be practical to document the process for creating a standalone distro, so that it can be built on conda-forge simultaneously with the corresponding non-standalone version?
+
+Thanks!
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_11_543bb94e6a6c1313a09328402a191995._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_11_543bb94e6a6c1313a09328402a191995._comment
new file mode 100644
index 0000000000..915e89bd91
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_11_543bb94e6a6c1313a09328402a191995._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="version correspondence of standalone builds and official releases"
+ date="2020-07-29T15:36:37Z"
+ content="""
+To answer @joeyh's question from a [related bug report](https://git-annex.branchable.com/bugs/kite_net_OSX__47__current__47___distribution_is_8.20200618_but_8.20200720.1_expected/#comment-06e9d73bdaff08d38d991ddc2b946f96) (\"maybe I'm missing something about how problematic the build being slightly behind until the next release is for you\"): it's problematic for [[conda-forge|install/conda]] packaging, because I want conda to install the non-standalone release if possible and automatically fall back on the standalone release if dependencies of the standard release conflict with other packages; for this to work, I need need the standalone release that corresponds to the same version as the standard release.  I could package a standalone-only conda-forge release, marking it as an alpha to keep it from being preferred to the official release; but then there's no seamless fallback if the user wants the specific official version.
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_12_b187721c1480debba3d391c965d17800._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_12_b187721c1480debba3d391c965d17800._comment
new file mode 100644
index 0000000000..284a1abdce
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_12_b187721c1480debba3d391c965d17800._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2020-08-10T17:23:28Z"
+ content="""
+The build process is "make linuxstandalone" or "make osxapp"
+
+The builds will be updated with today's release.
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_13_121ae7a2803975e3bdcb5f9df0c4af3f._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_13_121ae7a2803975e3bdcb5f9df0c4af3f._comment
new file mode 100644
index 0000000000..b496f647ed
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_13_121ae7a2803975e3bdcb5f9df0c4af3f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="updating the standalone distribution to 8.20200908"
+ date="2020-09-12T15:20:18Z"
+ content="""
+Building the standalone distribution on conda-forge doesn't seem possible, unfortunately, since the build environment there is CentOS not Debian.
+
+@joey, when you get a chance, could you update the [https://downloads.kitenet.net/git-annex/linux/current/](https://downloads.kitenet.net/git-annex/linux/current/) and [http://archive.org/download/git-annex-builds](http://archive.org/download/git-annex-builds) version to 8.20200908 ?  [Current version there](http://archive.org/download/git-annex-builds/SHA256E-s55287727--50bd5f4673fe85859b0a2c1cc4b68c93ace4ba3fca1b4eeeedeb0f3f243b9bad.tar.gz) is 8.20200815 , which is not an official release.
+Thanks!
+
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_14_5183f3d940ef116b07f88bac25cb97a8._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_14_5183f3d940ef116b07f88bac25cb97a8._comment
new file mode 100644
index 0000000000..6a26d0f56a
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_14_5183f3d940ef116b07f88bac25cb97a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="standalone build version oddity"
+ date="2020-09-12T19:07:55Z"
+ content="""
+Oddly, the mtime of the files at [https://downloads.kitenet.net/git-annex/linux/current](https://downloads.kitenet.net/git-annex/linux/current) is 2020-09-08, which does correspond to the latest git-annex release; but when run, it prints \"git-annex version: 8.20200815-g6ea511beb\".
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_15_b822c789e2736caa2c7bce27e619c463._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_15_b822c789e2736caa2c7bce27e619c463._comment
new file mode 100644
index 0000000000..a7408e006e
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_15_b822c789e2736caa2c7bce27e619c463._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="update standalone build at archive.org"
+ date="2021-03-11T16:40:59Z"
+ content="""
+@joeyh When you get a chance, could you push the standalone version corresponding to 8.20210310 to archive.org?  Latest one there is 8.20210128 .  Thanks!
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_16_33af5c294ccdff942f078ff366470342._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_16_33af5c294ccdff942f078ff366470342._comment
new file mode 100644
index 0000000000..986e72c830
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_16_33af5c294ccdff942f078ff366470342._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2021-03-11T17:13:22Z"
+ content="""
+It's copied there as part of the release process, and git-annex says it's
+there already.
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_17_a8d92991f13993d0beb72c7dd51e23a6._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_17_a8d92991f13993d0beb72c7dd51e23a6._comment
new file mode 100644
index 0000000000..2ec428b072
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_17_a8d92991f13993d0beb72c7dd51e23a6._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="finding archive.org URL"
+ date="2021-03-11T19:32:14Z"
+ content="""
+Hmm, I'm not seeing an archive.org URL:
+
+[[!format sh \"\"\"
+git clone https://downloads.kitenet.net/.git/
+cd downloads.kitenet.net/git-annex/linux/current/
+git annex init
+git annex sync --no-push
+ls -l git-annex-standalone-amd64.tar.gz
+lrwxrwxrwx 1 ilya ilya 215 Mar 11 14:25 git-annex-standalone-amd64.tar.gz -> ../../../.git/annex/objects/pM/mF/SHA256E-s51232145--1e57d2e334\
+cffdb3c3874785cfba4f6d5fc521808d0b1deef4fb68160dd88d48.tar.gz/SHA256E-s51232145--1e57d2e334cffdb3c3874785cfba4f6d5fc521808d0b1deef4fb68160dd\
+88d48.tar.gz
+git annex whereis git-annex-standalone-amd64.tar.gz
+
+whereis git-annex-standalone-amd64.tar.gz (1 copy)
+        840760dc-08f0-11e2-8c61-576b7e66acfd -- main repo [origin]
+ok
+
+
+\"\"\"]]
+
+
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_18_28f604900388b087eed76e7c03b8945b._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_18_28f604900388b087eed76e7c03b8945b._comment
new file mode 100644
index 0000000000..5a10ba6951
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_18_28f604900388b087eed76e7c03b8945b._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="finding archive.org URL"
+ date="2021-03-11T19:32:36Z"
+ content="""
+Hmm, I'm not seeing an archive.org URL:
+
+[[!format sh \"\"\"
+git clone https://downloads.kitenet.net/.git/
+cd downloads.kitenet.net/git-annex/linux/current/
+git annex init
+git annex sync --no-push
+ls -l git-annex-standalone-amd64.tar.gz
+lrwxrwxrwx 1 ilya ilya 215 Mar 11 14:25 git-annex-standalone-amd64.tar.gz -> ../../../.git/annex/objects/pM/mF/SHA256E-s51232145--1e57d2e334\
+cffdb3c3874785cfba4f6d5fc521808d0b1deef4fb68160dd88d48.tar.gz/SHA256E-s51232145--1e57d2e334cffdb3c3874785cfba4f6d5fc521808d0b1deef4fb68160dd\
+88d48.tar.gz
+git annex whereis git-annex-standalone-amd64.tar.gz
+
+whereis git-annex-standalone-amd64.tar.gz (1 copy)
+        840760dc-08f0-11e2-8c61-576b7e66acfd -- main repo [origin]
+ok
+
+
+\"\"\"]]
+
+
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_19_00592c4cdcd7c3f63d5eacd16abdc88b._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_19_00592c4cdcd7c3f63d5eacd16abdc88b._comment
new file mode 100644
index 0000000000..c6116c8849
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_19_00592c4cdcd7c3f63d5eacd16abdc88b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="standalone builds on archive"
+ date="2021-03-12T01:38:35Z"
+ content="""
+Two other current standalone builds do exist in archive.org, but not `git-annex-standalone-amd64.tar.gz`:
+[[!format sh \"\"\"
+(master_env_v178_py36) 20:34  [current] $ git annex find --in=web
+git-annex-standalone-arm64.tar.gz
+git-annex-standalone-armel.tar.gz
+\"\"\"]]
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_1_945d08e40897ee964be5e6945ad9914a._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_1_945d08e40897ee964be5e6945ad9914a._comment
new file mode 100644
index 0000000000..38e9c4a5dd
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_1_945d08e40897ee964be5e6945ad9914a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-02-05T16:43:09Z"
+ content="""
+The git-annex repository https://downloads.kitenet.net/.git/ keeps track of
+all the old versions, which get moved to archive.org eventually to free up
+space on my server. So it would be possible to build such a page from the
+information in that repository. Or just look up the archive.org url for
+the version of the file that you want using git annex whereis.
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_20_59066dc14b5b45a3a15ee65cf6746bab._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_20_59066dc14b5b45a3a15ee65cf6746bab._comment
new file mode 100644
index 0000000000..37d5a2c8d4
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_20_59066dc14b5b45a3a15ee65cf6746bab._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 20"""
+ date="2021-03-12T16:00:20Z"
+ content="""
+That's strange, the repo's git-annex branch was somehow behind, but its
+info/refs had the branch up-to-date with the information. I don't know how
+that can happen as git update-server-info updates the latter based on the
+former, but git-annex sync in the repo does look to have fixed the problem.
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_21_c4fcf4abe2550b677ee312c597556e66._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_21_c4fcf4abe2550b677ee312c597556e66._comment
new file mode 100644
index 0000000000..c472e9f4f8
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_21_c4fcf4abe2550b677ee312c597556e66._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="standalone tarballs"
+ date="2021-03-13T19:53:44Z"
+ content="""
+Thanks! The version string printed by the latest `git-annex-standalone-amd64.tar.gz` is 8.20210224-gf951847c6 .  Would it be difficult to adjust the release process so that the standalone version corresponding to the current [hackage version](https://hackage.haskell.org/package/git-annex) gets uploaded to [archive.org](https://archive.org/download/git-annex-builds)?
+
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_22_fe5049bba125e20d766595cb30bf7ce2._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_22_fe5049bba125e20d766595cb30bf7ce2._comment
new file mode 100644
index 0000000000..9af70e0941
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_22_fe5049bba125e20d766595cb30bf7ce2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="git-annex-standalone-amd64.tar.gz not getting updated at archive.org"
+ date="2021-03-31T03:35:09Z"
+ content="""
+Seems like `git-annex-standalone-arm64.tar.gz` and `git-annex-standalone-armel.tar.gz` got (auto-)uploaded to the web, but `git-annex-standalone-amd64.tar.gz` did not.
+
+
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_23_23bf8b9ab7e7850d801dcaec60ccf22d._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_23_23bf8b9ab7e7850d801dcaec60ccf22d._comment
new file mode 100644
index 0000000000..08fa089429
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_23_23bf8b9ab7e7850d801dcaec60ccf22d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2021-04-01T16:28:13Z"
+ content="""
+I checked in a fresh clone of the repository, and it shows it was
+uploaded to archive.org. It reached it soon after it was added to the
+repository:
+
+	joey@kite:~/tmp/downloads.kitenet.net/git-annex/linux/current>git annex log git-annex-standalone-amd64.tar.gz
+	+ Wed, 10 Mar 2021 14:12:30 JEST git-annex-standalone-amd64.tar.gz | 00000000-0000-0000-0000-000000000001 -- web
+	+ Wed, 10 Mar 2021 14:12:30 JEST git-annex-standalone-amd64.tar.gz | 5dc2ccd1-e534-4dae-8e8c-f31c8015e26e -- archive.org via S3
+	+ Wed, 10 Mar 2021 14:11:16 JEST git-annex-standalone-amd64.tar.gz | 840760dc-08f0-11e2-8c61-576b7e66acfd -- main repo [origin]
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_24_3dd596dc5f09564932dacd90fbb5be2b._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_24_3dd596dc5f09564932dacd90fbb5be2b._comment
new file mode 100644
index 0000000000..e53a128d66
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_24_3dd596dc5f09564932dacd90fbb5be2b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="syncing standalone version with the standard version"
+ date="2021-07-01T18:44:03Z"
+ content="""
+The version string printed by the standalone version seems to always be behind the current [latest version on hackage](https://hackage.haskell.org/package/git-annex).  E.g. the current standalone version (`git-annex-standalone-amd64.tar.gz -> ../../../.git/annex/objects/KM/Ff/SHA256E-s51276461--a1cef631ef2cc0c977580eacaa1294d7617727df99214920ca6e8f3172bae03e.tar.gz/SHA256E-s51276461--a1cef631ef2cc0c977580eacaa1294d7617727df99214920ca6e8f3172bae03e.tar.gz`) prints `8.20210622-g0e7906e80`, while the current standard version is `8.20210630`.   If the versions could be synced up, it would simplify things for the conda package.  Thanks!
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_25_dd482d39c746dd6845382e9503731b6f._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_25_dd482d39c746dd6845382e9503731b6f._comment
new file mode 100644
index 0000000000..173963feae
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_25_dd482d39c746dd6845382e9503731b6f._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 25"""
+ date="2021-08-09T19:50:11Z"
+ content="""
+It would take a significant amount of extra work, on an ongoing basis, for
+the version output by the standalone build to match the version used for
+the release. I would need to, after making a release, go build git-annex
+against that tag, on multiple OS's. It is much easier to simply have an
+autobuilder that builds current master, and when I make a release, ship the
+most recent build.
+
+It's also some ongoing amount of work to respond to repeated
+questions about it, when people notice that the version strings don't
+perfectly match up, but I guess I've answered your questions about it now
+and you won't be contributing to that workload further. Right?
+
+(The third way I could reduce the workload, which does seem more appealing
+for some reason right now, would be to stop offering release builds.)
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_26_7fb08748b8610ad33f800c1bd173b120._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_26_7fb08748b8610ad33f800c1bd173b120._comment
new file mode 100644
index 0000000000..392d44c13d
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_26_7fb08748b8610ad33f800c1bd173b120._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="sorry"
+ date="2021-08-10T16:28:33Z"
+ content="""
+Thanks @joeyh, I get the picture now, and sorry re: too many questions.  Don't think more about it, I'll figure out a sensible way to designate the conda versions.
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_2_211e260fbc60dc83a8986fac4e9700b7._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_2_211e260fbc60dc83a8986fac4e9700b7._comment
new file mode 100644
index 0000000000..b85bf8dae7
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_2_211e260fbc60dc83a8986fac4e9700b7._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="URL for git-annex-standalone for specific version"
+ date="2020-03-04T01:33:30Z"
+ content="""
+`git-annex-whereis` does not seem to report a URL... how do I find it?
+
+[[!format sh \"\"\"
+(base) 20:26  [downloads.kitenet.net] $ git annex whereis /data/sw/ga-archive/downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz
+whereis git-annex/linux/current/git-annex-standalone-amd64.tar.gz (1 copy)
+        840760dc-08f0-11e2-8c61-576b7e66acfd -- main repo [origin]
+\"\"\"]]
+
+Reason for needing a stable per-version URL is that conda recipes require one.
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_3_9002aa86c44c19f28ab74724daad5422._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_3_9002aa86c44c19f28ab74724daad5422._comment
new file mode 100644
index 0000000000..d89d48c4ff
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_3_9002aa86c44c19f28ab74724daad5422._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-03-04T16:25:55Z"
+ content="""
+That file had not been uploaded to archive.org, so there was no archive.org
+url available for it.
+
+What I'll do is automate the upload to archive.org after each release,
+so the tarballs should usually be available from there, barring some breakage.
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_4_ea42a5cb83e9cc8e24673bb805cfd4e1._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_4_ea42a5cb83e9cc8e24673bb805cfd4e1._comment
new file mode 100644
index 0000000000..7f49a53214
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_4_ea42a5cb83e9cc8e24673bb805cfd4e1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2020-03-04T17:15:58Z"
+ content="""
+Great, thanks.   This'll permanently fix the [issue](https://github.com/conda/conda/issues/9707) of package conflicts when installing git-annex (or tools that depend on it, like DataLad) alongside other things into conda environments.
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_5_c6d2c756b51247c784786e3a02d3840a._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_5_c6d2c756b51247c784786e3a02d3840a._comment
new file mode 100644
index 0000000000..d60547a2ba
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_5_c6d2c756b51247c784786e3a02d3840a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 5"
+ date="2020-03-09T18:45:46Z"
+ content="""
+Let know when this happens, so can get the stable URL for the standalone tarball for [[news/version_7.20200309]].
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_6_f7de3190366e81fc898393c1ed168c56._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_6_f7de3190366e81fc898393c1ed168c56._comment
new file mode 100644
index 0000000000..0f7b5ca59f
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_6_f7de3190366e81fc898393c1ed168c56._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-03-09T18:55:35Z"
+ content="""
+I'm not providing builds of executables for releases in the 7.x line.
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_7_6ac3fa868ab0dfa6cc26928098abc334._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_7_6ac3fa868ab0dfa6cc26928098abc334._comment
new file mode 100644
index 0000000000..947004d64d
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_7_6ac3fa868ab0dfa6cc26928098abc334._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="stable url for standalone build"
+ date="2020-03-10T17:10:33Z"
+ content="""
+Ok -- until this gets automated, could you manually push the 8.20200309 standalone tarball to archive.org?
+(My setup now relies on the standalone conda build, and this would let me get the recent bug fixes.)
+Thanks a lot!
+
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_8_74875c799f20d051739227e2b79de18f._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_8_74875c799f20d051739227e2b79de18f._comment
new file mode 100644
index 0000000000..7af3467c3a
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_8_74875c799f20d051739227e2b79de18f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="correct standalone tarball  for git-annex-8.20200522"
+ date="2020-06-05T06:21:07Z"
+ content="""
+The current standalone tarball at [https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz) displays 8.20200502 on 'git-annex version', although the git commit message suggests it should be 8.20200522 .  Which is correct?
+"""]]
diff --git a/doc/forum/standalone_tarballs_for_specific_versions/comment_9_febd89250e37af938c723e4a204c5cef._comment b/doc/forum/standalone_tarballs_for_specific_versions/comment_9_febd89250e37af938c723e4a204c5cef._comment
new file mode 100644
index 0000000000..102ef956aa
--- /dev/null
+++ b/doc/forum/standalone_tarballs_for_specific_versions/comment_9_febd89250e37af938c723e4a204c5cef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="building the standalone distribution"
+ date="2020-06-17T14:22:34Z"
+ content="""
+Is there a way to build the standalone distribution from the tarballs posted on Hackage?
+"""]]
diff --git a/doc/forum/start_assistant_from_command_line.mdwn b/doc/forum/start_assistant_from_command_line.mdwn
new file mode 100644
index 0000000000..3f48dd6d34
--- /dev/null
+++ b/doc/forum/start_assistant_from_command_line.mdwn
@@ -0,0 +1,11 @@
+I wanted to try out this probably great piece of software you wrote, alas I do not use a Debian distro with managed software menus (i.e. I use OpenBox), so I cannot simply open the assistant through my programs-menu. In fact, to do that I'd need the command to start the assistant so I can add it manually myself. Sadly, the man page did not gave me any advices... :(
+
+Any chance to give me the terminal command to start the assistant?
+
+***
+edit: just to update the thread: everythings okay now. Thanks for this great program!
+
+the commands (as posted by Paul):
+
+    git annex assistant
+    git annex webapp
diff --git a/doc/forum/start_assistant_from_command_line/comment_1_f8dfce1fca9f1212ccaf84e431db71a9._comment b/doc/forum/start_assistant_from_command_line/comment_1_f8dfce1fca9f1212ccaf84e431db71a9._comment
new file mode 100644
index 0000000000..dc35d61bc0
--- /dev/null
+++ b/doc/forum/start_assistant_from_command_line/comment_1_f8dfce1fca9f1212ccaf84e431db71a9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBhQgaA5QrFwT67-Bo0qPIx0HD9roDrso"
+ nickname="Paul"
+ subject="comment 1"
+ date="2013-10-21T19:20:28Z"
+ content="""
+    git annex assitant
+
+starts the assitant itself, you propably want the gui which you start by
+
+   git annex webapp
+"""]]
diff --git a/doc/forum/start_assistant_from_command_line/comment_2_e769c5d09afbff85961363ddc5eb4019._comment b/doc/forum/start_assistant_from_command_line/comment_2_e769c5d09afbff85961363ddc5eb4019._comment
new file mode 100644
index 0000000000..b970990d46
--- /dev/null
+++ b/doc/forum/start_assistant_from_command_line/comment_2_e769c5d09afbff85961363ddc5eb4019._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkj7tMEJKcZpNXIFkHAAcNi5qJFSFyjn6o"
+ nickname="thissideup"
+ subject="comment 2"
+ date="2013-10-22T11:05:13Z"
+ content="""
+ah okay. That was what I was trying to do, but git-annex failed on my. Remembering that I was on Debian and checking the version (which was June 2012) - I supposed that I wasn't able to use the assistant yet. 
+
+So now I am trying to compile from source using cabal, however I sadly ran into a roadblock: http://git-annex.branchable.com/forum/cabal_install_fails_on_uuid/
+"""]]
diff --git a/doc/forum/status_of_v7.mdwn b/doc/forum/status_of_v7.mdwn
new file mode 100644
index 0000000000..ae516d7460
--- /dev/null
+++ b/doc/forum/status_of_v7.mdwn
@@ -0,0 +1,3 @@
+What is the current status of v7 repositories?  What has been people's experience in using them?
+
+`git-annex` still defaults to v5, so it sounds like v7 is still in beta?
diff --git a/doc/forum/status_of_v7/comment_1_88d3bcb329bce6dfe33707f39b843b39._comment b/doc/forum/status_of_v7/comment_1_88d3bcb329bce6dfe33707f39b843b39._comment
new file mode 100644
index 0000000000..709c05b53b
--- /dev/null
+++ b/doc/forum/status_of_v7/comment_1_88d3bcb329bce6dfe33707f39b843b39._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-07-23T16:11:18Z"
+ content="""
+The main blocker to v7 becoming the default is that its replacement for
+direct mode, adjusted unlocked branches, is still a new feature that has
+not gotten a great deal of testing and could have bugs. See 
+<http://git-annex.branchable.com/todo/v7_path_toward_default/>
+(I don't consider it to still be beta level though; on balance the many well
+known problems with direct mode are certianly worse.)
+
+When v7 is used without any unlocked files, it is nearly identical to v5
+indirect, and so is just as good. With that said, I'm not personally using
+it yet on my repos, because it also doesn't add any new features either..
+
+When v7 is used with unlocked files, it is still a relatively new feature
+and could have bugs. That said, people do appear to be using it
+increasingly widely, and the last bugs fixed in it were in December 2018.
+
+Unlocked files are also affected by 
+<http://git-annex.branchable.com/todo/git_smudge_clean_interface_suboptiomal/>
+although that has been worked around sufficiently well it still has some
+slight negative consequences.
+"""]]
diff --git a/doc/forum/store_annex_in_different_place_on_hard_drive.mdwn b/doc/forum/store_annex_in_different_place_on_hard_drive.mdwn
new file mode 100644
index 0000000000..8bc0e86536
--- /dev/null
+++ b/doc/forum/store_annex_in_different_place_on_hard_drive.mdwn
@@ -0,0 +1,2 @@
+I have the following setup on my work computer. The /home folder has limited space, but excellent backups, so I would like to keep my main repository there.
+The /scratch/ folder has no backup, but has faster read/write speed, and more storage space. Is there a way to keep the main repo in /home, but somehow store the large annexed files on /scratch. I am open to making a remote repository, but the standard "git annex get" workflow will simply copy large files into the /home directory, which is what i want to avoid altogther. Can I just make a symlink from "/home/<username>/repo/.git/annex" to "/scratch/repodata" somehow? Thanks!
diff --git a/doc/forum/store_annex_in_different_place_on_hard_drive/comment_1_a95add69028ad71f3c66b544c1a28db6._comment b/doc/forum/store_annex_in_different_place_on_hard_drive/comment_1_a95add69028ad71f3c66b544c1a28db6._comment
new file mode 100644
index 0000000000..af79351a36
--- /dev/null
+++ b/doc/forum/store_annex_in_different_place_on_hard_drive/comment_1_a95add69028ad71f3c66b544c1a28db6._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-10-06T20:17:07Z"
+ content="""
+You should avoid making two repositories that share the same .git/annex
+or .git/annex/objects directories. Doing that can get git-annex confused,
+and let it drop a file that is only located in one place .. because it sees
+it existing in 2 places due to the symlink!
+
+IIRC, git-annex supports making .git/annex a symlink to some directory
+elsewhere, that is not itself used by another git repository.
+
+Or, you can use standard `GIT_DIR` settings to make git 
+(and git-annex) look for the .git directory elsewhere.
+"""]]
diff --git a/doc/forum/support_for_git_sparse_checkout.mdwn b/doc/forum/support_for_git_sparse_checkout.mdwn
new file mode 100644
index 0000000000..dd5cfe3ccc
--- /dev/null
+++ b/doc/forum/support_for_git_sparse_checkout.mdwn
@@ -0,0 +1 @@
+Does git-annex support [git sparse checkout](https://git-scm.com/docs/git-read-tree#_sparse_checkout)?  Are there any known issues when using it in git-annex repos, especially in conjunction with [git-worktree](https://git-scm.com/docs/git-worktree)?
diff --git a/doc/forum/switching_backends.mdwn b/doc/forum/switching_backends.mdwn
new file mode 100644
index 0000000000..dedf1ffcba
--- /dev/null
+++ b/doc/forum/switching_backends.mdwn
@@ -0,0 +1,12 @@
+so git annex migrate can switch a file from using one backend to the other.
+
+I've done that with a bunch of files.
+
+The old files should become "unused" right?  But they don't seem to be.  "git annex unused" still shows me only 2 unused files, and I've just migrated dozens of files from SHA256 to SHA256E.  
+
+Is it possible they're still "used" by other repos?  I have two other repos, one reached by SSH and one on a USB drive.  Neither one of them is "bare."  So maybe those files are still used by the "master" branches there, I thought... I went over and did "git annex sync" on each.  Still my newly migrated files are not showing up as "unused."  
+
+I'm worried that my repo is going to bloat with unused files with the SHA256 backend, which mysteriously do not show up as "unused" in git annex unused, if I migrate any more.
+
+any ideas what piece of the puzzle I could be missing here?
+
diff --git a/doc/forum/switching_backends/comment_1_ecf4109c1148dafde3519243ae3c5a03._comment b/doc/forum/switching_backends/comment_1_ecf4109c1148dafde3519243ae3c5a03._comment
new file mode 100644
index 0000000000..29bc9f9c3f
--- /dev/null
+++ b/doc/forum/switching_backends/comment_1_ecf4109c1148dafde3519243ae3c5a03._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 1"
+ date="2013-01-28T03:20:38Z"
+ content="""
+Just noticed this -- http://git-annex.branchable.com/bugs/git_annex_migrate_leaves_old_backend_versions_around/
+
+so I don't need to worry about disk space bloat; they're all just hardlinks.  That's cool.  Still would be nice to know why they don't show up as \"unused.\"  But not as important.
+"""]]
diff --git a/doc/forum/switching_backends/comment_2_21f465a18f40b95dafd307fce0de659a._comment b/doc/forum/switching_backends/comment_2_21f465a18f40b95dafd307fce0de659a._comment
new file mode 100644
index 0000000000..82c9f26213
--- /dev/null
+++ b/doc/forum/switching_backends/comment_2_21f465a18f40b95dafd307fce0de659a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 2"
+ date="2013-01-28T06:28:28Z"
+ content="""
+It won't show as unused as long as there are git refs that still refer to the file. That could be branches, or more likely you have not synced everything to the local repo yet.
+"""]]
diff --git a/doc/forum/switching_backends/comment_4_4c13d22c1695195e6b101bd20ef6bb42._comment b/doc/forum/switching_backends/comment_4_4c13d22c1695195e6b101bd20ef6bb42._comment
new file mode 100644
index 0000000000..7ffa519e0c
--- /dev/null
+++ b/doc/forum/switching_backends/comment_4_4c13d22c1695195e6b101bd20ef6bb42._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 4"
+ date="2013-01-28T14:30:55Z"
+ content="""
+If by \"synced to the local repo\" you mean run a git annex sync, then yes, I have done that.
+
+Here's an example of what I'm seeing:
+
+    annex$ readlink subdir/subdir/file.txt 
+    ../../.git/annex/objects/zV/57/SHA256E-s3952--cb67d2cbadfea373ed8aa5ec434f246acccb33471a7e28a444138cc4fe8552c2.txt/SHA256E-s3952--cb67d2cbadfea373ed8aa5ec434f246acccb33471a7e28a444138cc4fe8552c2.txt
+    annex$ find .git/annex/objects/ -name SHA256-s3952--cb67d2cbadfea373ed8aa5ec434f246acccb33471a7e28a444138cc4fe8552c2
+    .git/annex/objects//1w/Q4/SHA256-s3952--cb67d2cbadfea373ed8aa5ec434f246acccb33471a7e28a444138cc4fe8552c2
+    .git/annex/objects//1w/Q4/SHA256-s3952--cb67d2cbadfea373ed8aa5ec434f246acccb33471a7e28a444138cc4fe8552c2/SHA256-s3952--cb67d2cbadfea373ed8aa5ec434f246acccb33471a7e28a444138cc4fe8552c2
+    annex$ git annex sync
+    commit  
+    # On branch master
+    nothing to commit, working directory clean
+    ok
+    pull homeworld 
+    ok
+    push homeworld 
+    Everything up-to-date
+    ok
+    annex$ git annex unused
+    unused . (checking for unused data...) (checking master...) (checking sync/master...) (checking homeworld/master...) (checking toshiba/master...) (checking toshiba/synced/master...) ok
+    annex$ find .git/annex/objects/ -name SHA256-s3952--cb67d2cbadfea373ed8aa5ec434f246acccb33471a7e28a444138cc4fe8552c2
+    .git/annex/objects//1w/Q4/SHA256-s3952--cb67d2cbadfea373ed8aa5ec434f246acccb33471a7e28a444138cc4fe8552c2
+    .git/annex/objects//1w/Q4/SHA256-s3952--cb67d2cbadfea373ed8aa5ec434f246acccb33471a7e28a444138cc4fe8552c2/SHA256-s3952--cb67d2cbadfea373ed8aa5ec434f246acccb33471a7e28a444138cc4fe8552c2
+    annex$ 
+
+
+As you can see, there are two remotes, \"toshiba\" and \"homeworld\".  Neither of them is bare, they have checked out \"master\" branches.  Could they be the reason that some of this data isn't \"unused\"?  (I ask because I notice it reports that it is checking homeworld/master and toshiba/master when it does the unused check)
+"""]]
diff --git a/doc/forum/switching_backends/comment_4_e1d4a48baac23fd3f67b20eba4eee8af._comment b/doc/forum/switching_backends/comment_4_e1d4a48baac23fd3f67b20eba4eee8af._comment
new file mode 100644
index 0000000000..d5f4e021ee
--- /dev/null
+++ b/doc/forum/switching_backends/comment_4_e1d4a48baac23fd3f67b20eba4eee8af._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.125"
+ subject="comment 4"
+ date="2013-02-05T19:16:48Z"
+ content="""
+If you have not yet run `git annex sync` on the remotes, then they are still referring to the old unmigrated keys, which is why `unused` will not remove them.
+"""]]
diff --git a/doc/forum/switching_to__47__from_direct_mode_while_assistant_is_running.mdwn b/doc/forum/switching_to__47__from_direct_mode_while_assistant_is_running.mdwn
new file mode 100644
index 0000000000..f92b5aca35
--- /dev/null
+++ b/doc/forum/switching_to__47__from_direct_mode_while_assistant_is_running.mdwn
@@ -0,0 +1,2 @@
+Is that really unsafe?  Because I did that and the switch to direct mode seemed to leave a lot of files still as links, and when I panicked and switched back to indirect mode, a whole lot of stuff seemed to have become unannexed and I reannexed it.
+
diff --git a/doc/forum/switching_to__47__from_direct_mode_while_assistant_is_running/comment_1_7832243a36613c48d0077b438dbf8b4a._comment b/doc/forum/switching_to__47__from_direct_mode_while_assistant_is_running/comment_1_7832243a36613c48d0077b438dbf8b4a._comment
new file mode 100644
index 0000000000..b27115bbb1
--- /dev/null
+++ b/doc/forum/switching_to__47__from_direct_mode_while_assistant_is_running/comment_1_7832243a36613c48d0077b438dbf8b4a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 1"
+ date="2013-01-25T03:39:16Z"
+ content="""
+This may have been an unrelated issue -- I just realized that I somehow ended up with a bunch of files in the annex under the directory \"misc\" and others under the directory \"Misc\" -- I'm not sure how they got that way, since I'm on OS X and those are supposed to be the same directory -- but they get synced over to a linux box where they're different directories.  This may be the source of some of the weirdness I saw; I'm not sure.  I tried to fix it all up on the linux box so everything was in its own directory.
+
+
+"""]]
diff --git a/doc/forum/symlinks_corrupt__58___link_in_textfile__44___100_bytes_of_size.mdwn b/doc/forum/symlinks_corrupt__58___link_in_textfile__44___100_bytes_of_size.mdwn
new file mode 100644
index 0000000000..d851075873
--- /dev/null
+++ b/doc/forum/symlinks_corrupt__58___link_in_textfile__44___100_bytes_of_size.mdwn
@@ -0,0 +1,7 @@
+I can't find out why, but under certain circumstances the symlinks don't work in my environment. On all hosts I have latest Ubuntu Linux and latest git-annex. V6 repos. Issue is, that instead of real symlinks, the filenames remain the original ones and the content is the relative link to the corresponding annex object.
+
+Strange behavior is, I can drop and get the files but it doesn't seem to affect the situation after all.
+
+Comparing the size of .git/*, it is very likely that the contents are present and so does "git annex whereis bla.jpg". Leading me to the conclusion that everything works except the symlinking. Is this a known issue? What steps can I perform to find out the root cause?
+
+Thank you.
diff --git a/doc/forum/symlinks_corrupt__58___link_in_textfile__44___100_bytes_of_size/comment_1_ee6ec862a391c54c8e1254891d4d477e._comment b/doc/forum/symlinks_corrupt__58___link_in_textfile__44___100_bytes_of_size/comment_1_ee6ec862a391c54c8e1254891d4d477e._comment
new file mode 100644
index 0000000000..c05c2ac43e
--- /dev/null
+++ b/doc/forum/symlinks_corrupt__58___link_in_textfile__44___100_bytes_of_size/comment_1_ee6ec862a391c54c8e1254891d4d477e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-11-11T23:20:25Z"
+ content="""
+git-annex does indeed store a relative link to the file content. What made you think your links are corrupt or not real? What issue are you having?
+"""]]
diff --git a/doc/forum/symlinks_corrupt__58___link_in_textfile__44___100_bytes_of_size/comment_2_0748b20c8a0d7d4704003c0ecfc27716._comment b/doc/forum/symlinks_corrupt__58___link_in_textfile__44___100_bytes_of_size/comment_2_0748b20c8a0d7d4704003c0ecfc27716._comment
new file mode 100644
index 0000000000..e67a22ed82
--- /dev/null
+++ b/doc/forum/symlinks_corrupt__58___link_in_textfile__44___100_bytes_of_size/comment_2_0748b20c8a0d7d4704003c0ecfc27716._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="sameerds"
+ avatar="http://cdn.libravatar.org/avatar/b6d36a03115d3ececaafe16e327e9e27"
+ subject="+1"
+ date="2019-02-24T17:06:30Z"
+ content="""
+I am facing the same problem. It's a v6 repo on an NTFS partition mounted on an Ubuntu system. Many (but not all) of my files look like ordinary text files with a path to the key. Double-clicking them in the GUI obviously doesn't work because although the extention is .jpg, the file contents are plain text. As far as I can see, it should have been a symlink. Commands like \"get\" and \"find\" work as if those files are present in the repo.
+"""]]
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors.mdwn b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors.mdwn
new file mode 100644
index 0000000000..0f31e49171
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors.mdwn
@@ -0,0 +1,50 @@
+I am getting errors when I try to do `sync --content`. I have a git-annex repo on my laptop and I sync all content to an S3 compatible remote (Dreamhost DreamObjects). I ran the following command in my attempt to better understand the issue:
+
+    andrew@bumblebee ~/notes$ git-annex --verbose --debug sync --content cloud &> /tmp/sync_log_2016-11-7-7pm.log
+
+For reference the repos preferred content settings are:
+
+    andrew@bumblebee ~/notes$ git-annex wanted here
+    standard
+    andrew@bumblebee ~/notes$ git-annex group here
+    manual
+    andrew@bumblebee ~/notes$ git-annex wanted cloud
+    standard
+    andrew@bumblebee ~/notes$ git-annex group cloud
+    backup
+    andrew@bumblebee ~/notes$ 
+
+Looking at the log file I see errors like this, repeated dozens of times:
+
+    fatal: '../Users/andrew/notes/cv/submissions/BCA_Submission/small_images/macropavilion_2016_IMG_0297.jpg' is outside repository
+    [2016-11-07 19:34:37.542383] process done ExitFailure 128
+    [2016-11-07 19:34:37.542473] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+    fatal: '../Users/andrew/notes/cv/submissions/BCA_Submission/small_images/macropavilion_2016_IMG_0297.jpg' is outside repository
+    [2016-11-07 19:34:37.551241] process done ExitFailure 128
+    [2016-11-07 19:34:37.551382] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+
+The relative path `../Users` is curious. `/Users/andrew` is the absolute path of my home directory (I am on OS-X 10.11.6); `/Users/andrew/notes` is the absolute path of my git-annex repo.
+
+the above logs are followed by:
+
+    git-annex: git check-attr EOF: user error
+    failed
+
+    git-annex: fd:24: hFlush: resource vanished (Broken pipe)
+    failed
+
+hFlush lines appears hundreds of times, then change to:
+
+    git-annex: fd:24: commitBuffer: resource vanished (Broken pipe)
+    failed
+
+commitBuffer lines also apear hundreds of times.
+
+Then the logs move onto successful transfers, and similar errors repeat with different file names.
+
+I have tried `git annex fsck` on the local repo, and also tried `git annex fsck --fast --from=cloud` (although I didn't let it finish) and didn't see any errors. Thoughts?
+
+
+
+Thanks,
+Andrew
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_10_d4a649874ee9c9e6a4c0252700607713._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_10_d4a649874ee9c9e6a4c0252700607713._comment
new file mode 100644
index 0000000000..7e936266bc
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_10_d4a649874ee9c9e6a4c0252700607713._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2018-07-17T19:16:23Z"
+ content="""
+Hmm, maybe.
+
+It's very difficult to say without enough of a transcript to have any idea
+at what point in the `git annex sync` it was failing. If it failed in the
+"commit" part, then yes, it could be git commit running the smudge/clean filter
+and the worktree path problem affecting it.
+"""]]
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_1_668dae37dd46047b46c9e1c23f7bcec4._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_1_668dae37dd46047b46c9e1c23f7bcec4._comment
new file mode 100644
index 0000000000..4a61d0eee6
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_1_668dae37dd46047b46c9e1c23f7bcec4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="public@881708f3cb16d1f967ca9f517a310dd211474013"
+ nickname="public"
+ avatar="http://cdn.libravatar.org/avatar/e60c5356a8001ac2a78b489d6ac3731c"
+ subject="not specific to cloud repo"
+ date="2016-11-09T21:24:59Z"
+ content="""
+I am getting the same errors when syncing to my USB drive. So it does not appear to have anything to do with syncing to the cloud.
+
+Andrew
+"""]]
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_09c62e4abf4ccc0d2e030ef5e1bcdf71._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_09c62e4abf4ccc0d2e030ef5e1bcdf71._comment
new file mode 100644
index 0000000000..fcca1b28e8
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_09c62e4abf4ccc0d2e030ef5e1bcdf71._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="how to investigate"
+ date="2016-11-16T15:37:01Z"
+ content="""
+Any thoughts? I am unsure how to investigate where this problem is. I assume these files are in my git repo or git-annex objects but I can't seem to find them using any search commands.
+
+Thanks,
+
+Andrew
+"""]]
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_8f694afa77f5a835c826d29d46d44615._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_8f694afa77f5a835c826d29d46d44615._comment
new file mode 100644
index 0000000000..8228b6eb04
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_8f694afa77f5a835c826d29d46d44615._comment
@@ -0,0 +1,30 @@
+	[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-11-16T18:52:07Z"
+ content="""
+It would be helpful if you said what version of git-annex you are using.
+
+And, is your git-annex repository using the new experimental v6 format? One
+user reported a similar error message with a v6 git-annex repository. See
+[[bugs/assistant_crashes_in_TransferScanner]]
+
+Or might your repository be using direct mode?
+
+So, please paste in `git annex version` and `git annex info` output.
+
+It kind of looks like it's having difficulty determining where the top of
+the git repository is, or constructing a relative path to the git
+repository.
+
+Are there any symlinks in the path to /Users/andrew/notes ? Eg, is /Users
+a symlink, or /Users/andrew a symlink, or //Users/andrew/notes itself
+symlinked to elsewhere?
+
+Does only `git annex sync --content` fail? What if you run, eg
+`git annex copy --auto --to cloud` and `git annex get --auto --from cloud`,
+does that fail similarly, or does it succeed?
+
+You say it's only failing for some files. Do the filenames that it's
+failing on contain any non-ascii characters?
+"""]]
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_4_a7f476aeacf88679f25badc78fad886a._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_4_a7f476aeacf88679f25badc78fad886a._comment
new file mode 100644
index 0000000000..eec45e333e
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_4_a7f476aeacf88679f25badc78fad886a._comment
@@ -0,0 +1,57 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="git annex copy --auto --to cloud works"
+ date="2016-11-17T17:49:27Z"
+ content="""
+Yes, only `git annex sync --content` seems to fail. I am using v6 with a mix of unlocked and locked files. I did not know about the --auto flags for copy/get.
+
+* `git annex copy --auto --to cloud` works fine
+* `git annex get --auto --from cloud` works fine
+
+
+*Are there any symlinks in the path to /Users/andrew/notes ? Eg, is /Users a symlink, or /Users/andrew a symlink, or //Users/andrew/notes itself symlinked to elsewhere?*
+
+**No**
+
+*You say it's only failing for some files. Do the filenames that it's failing on contain any non-ascii characters?*
+
+**They seem normal.**
+
+*So, please paste in git annex version and git annex info output.*
+
+    git-annex version: 6.20161110-gd48f4ca
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 6
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: darwin x86_64
+
+    repository mode: indirect
+    trusted repositories: 0
+    semitrusted repositories: 10
+    00000000-0000-0000-0000-000000000001 -- web
+    00000000-0000-0000-0000-000000000002 -- bittorrent
+    22de57a0-c9ca-4bfe-8349-3141b3a87c8f -- Dream Objects [cloud]
+    334791ca-c284-4a87-a233-fc29be00d31a -- [disc_May-2-2015_a]
+    4c57ac0e-b8fe-4b4b-98d3-fb0a1b6b9657 -- MacBook Air [here]
+    6a85150d-6ea2-4ba1-92ce-8f4ef575b8e0 -- prowl MacBook Mini
+    896c3d52-427a-41a1-867c-d18e6740d758 -- disc_May_4_2015_1
+    96391b13-3981-430f-ac3b-6210e3d4e759 -- [disc_May-2-2015_b]
+    b4a41e90-2398-4bba-aaf5-d8f8cd78a5bc -- 2TB USB Drive [usbdrive]
+    e42b223d-ec04-4ad8-bdf7-8429a45d844c -- disc_May-2-2015_a
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: 2.32 gigabytes (+1 megabyte reserved)
+    temporary object directory size: 29.47 megabytes (clean up with git-annex unused)
+    local annex keys: 4104
+    local annex size: 10.53 gigabytes
+    annexed files in working tree: 6417
+    size of annexed files in working tree: 80.75 gigabytes
+    bloom filter size: 32 mebibytes (0.8% full)
+    backend usage: 
+    SHA256E: 6417
+
+"""]]
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_5_e96503f38cba755b2e6bd89b1ffab6ff._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_5_e96503f38cba755b2e6bd89b1ffab6ff._comment
new file mode 100644
index 0000000000..17fa7b04b3
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_5_e96503f38cba755b2e6bd89b1ffab6ff._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="updates sync vs copy?"
+ date="2017-01-21T14:56:26Z"
+ content="""
+Any thoughts Joey? Reminder I have a v6 repo, that spits out errors `git-annex: fd:24: hFlush: resource vanished (Broken pipe)` when using sync --content.
+
+I am not sure why `git annex sync --content cloud` should spew errors, and `git annex copy --auto --to cloud` runs without issue. Anything I should do on my end to investigate this issue further?
+
+Thanks,
+
+Andrew
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+"""]]
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_6_7443fe5f7384431914c714c2b462cf5c._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_6_7443fe5f7384431914c714c2b462cf5c._comment
new file mode 100644
index 0000000000..c8b0e3356b
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_6_7443fe5f7384431914c714c2b462cf5c._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="RESOLVED / deleted all files then re-added as zip"
+ date="2017-01-23T02:28:23Z"
+ content="""
+OK. I ended up having to delete all the files from git, then re-add them zipped up.
+
+I re-read the post you mentioned, this helped me resolve my issue:
+[assistant crashes in TransferScanner](http://git-annex.branchable.com/bugs/assistant_crashes_in_TransferScanner/) (from johannes)
+
+Johannes dropped the file, then re-added, that fixed his issue. So I tried that first.
+
+I did the following:
+
+ * git-annex dropped all problem files. this didn't fix issue
+ * deleted all problem files (using OS-X Finder), committed the deletion with git (git add -A), issue then fixed
+    * re-added deleted files, issue came back
+    * re-added deleted files in different folder, issue came back
+    * re-added deleted files all with different filenames in different path, issue came back
+    * zipped up folder of problem files, then added to git-annex, no issues
+
+
+"""]]
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_7_63225cc9557886ae12b3450f68812815._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_7_63225cc9557886ae12b3450f68812815._comment
new file mode 100644
index 0000000000..fd1c563534
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_7_63225cc9557886ae12b3450f68812815._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2017-02-20T16:54:19Z"
+ content="""
+Can you give me some examples of the names of the "problem files"?
+"""]]
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_8_baefe35266021184ee78440226fe2a8d._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_8_baefe35266021184ee78440226fe2a8d._comment
new file mode 100644
index 0000000000..df94899406
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_8_baefe35266021184ee78440226fe2a8d._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="the problem files"
+ date="2017-02-20T18:11:03Z"
+ content="""
+Joey,
+
+the file names seem quite ordinary:
+
+    cv/submissions/BCA_Submission/small_images/drawblocks_2015_IMG_1719.jpg
+    cv/submissions/BCA_Submission/small_images/drawblocks_2015_IMG_3848.jpg
+    cv/submissions/BCA_Submission/small_images/macropavilion_2016_IMG_0391.jpg
+    cv/submissions/BCA_Submission/small_images/sequencing_2016_DSC5048.jpg
+    cv/submissions/BCA_Submission/small_images/sequencing_2016_IMG_8231.jpg
+
+Possibly this is related to an issue I had with v6 and `annex.largefiles` about 12-months ago. I had done `git config annex.largefiles 'largerthan=100kb and not (include=*.c or include=*.h)'`. But I believe this resulted in git-annex thinking locked files with no content present should be added to git instead of annex? After doing a `git-annex add .` I now had a bunch of files whose content was lost. Or perhaps I did a sync with a v5 repo, or perhaps I did a sync with a repo with a different large files settings, I can't remember. Anyhow, I managed to lose links to the file content and `git-annex get` or fsck couldn't retrieve them. I never filed a bug report because I was never able to reproduce the issue on a clean repo. 
+
+Anyhow, perhaps spelunking into the git log would give some answers?
+
+
+
+Andrew
+
+"""]]
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_9_a9ed50cd4a1f436822ae97bfcd1ced48._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_9_a9ed50cd4a1f436822ae97bfcd1ced48._comment
new file mode 100644
index 0000000000..1df369d84e
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_9_a9ed50cd4a1f436822ae97bfcd1ced48._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 9"
+ date="2018-07-17T18:58:58Z"
+ content="""
+Most likely related to and fixed by now fixed bug: <https://git-annex.branchable.com/bugs/add_fails_with_v6_repo_when_four_levels_deep/>
+"""]]
diff --git a/doc/forum/sync_--content_sometimes_iterates_over_all_files.mdwn b/doc/forum/sync_--content_sometimes_iterates_over_all_files.mdwn
new file mode 100644
index 0000000000..d8fc36bcc5
--- /dev/null
+++ b/doc/forum/sync_--content_sometimes_iterates_over_all_files.mdwn
@@ -0,0 +1,35 @@
+`git annex sync --content` behaves differently for directory or SSH resources.
+
+I use the directory resource on two external hard drives to sync between them. They always get mounted to the same mount point.
+
+When syncing from one USB drive to another, git-annex iterates over all files in the annex. This takes a long time even if only one file got added.
+
+When running git-annex in one of the USB drives and syncing with SSH, git-annex only does the file transfer necessary and does not iterate over all files.
+
+I'd like to have the SSH behavior also for syncs between USB drives. Is that possible?
+
+Also, how does git-annex make the decision?
+
+UPDATE: adding the output of git-annex as requested by Joey
+
+```
+% git annex sync --content usb-sg2
+commit                                                                                                                                                                           
+Auto packing the repository in background for optimum performance.
+See "git help gc" for manual housekeeping.
+[master 3bREDACTED4b] git-annex in usb-sg1
+ 2619 files changed, 2619 insertions(+)
+ create mode 120000 import/REDACTED
+ ...REDACTED...
+ create mode 120000 import/REDACTED
+ok
+pull usb-sg2
+From /media/thk/thk-sg1/annex-sg1
+   7dREDACTED45..caREDACTEDfb  git-annex  -> usb-sg2/git-annex                                                                                                                
+   84REDACTED33..3bREDACTED4b  master     -> usb-sg2/master                                                                                                                   
+Auto packing the repository in background for optimum performance.                                                                                                            
+See "git help gc" for manual housekeeping.                                                                                                                                    
+ok                                                                                                                                                                            
+copy import/REDACTING ok
+[FROM here, the above line repeats for all files in the annex]
+```
diff --git a/doc/forum/sync_--content_sometimes_iterates_over_all_files/comment_1_a276f0f6aa87a491c2fba3d58217b75a._comment b/doc/forum/sync_--content_sometimes_iterates_over_all_files/comment_1_a276f0f6aa87a491c2fba3d58217b75a._comment
new file mode 100644
index 0000000000..146fb0dbec
--- /dev/null
+++ b/doc/forum/sync_--content_sometimes_iterates_over_all_files/comment_1_a276f0f6aa87a491c2fba3d58217b75a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-27T18:27:26Z"
+ content="""
+What specifically are you seeing when it "iterates over all files in the
+annex"?
+
+sync --content necessarily has to look at each file in turn in order to
+determine if a) the file's content is present locally and b) if the file's
+content is present on the remote.
+"""]]
diff --git a/doc/forum/sync_--content_sometimes_iterates_over_all_files/comment_2_1f8ae9a0099d456e25f387798f99eec9._comment b/doc/forum/sync_--content_sometimes_iterates_over_all_files/comment_2_1f8ae9a0099d456e25f387798f99eec9._comment
new file mode 100644
index 0000000000..bf3d294894
--- /dev/null
+++ b/doc/forum/sync_--content_sometimes_iterates_over_all_files/comment_2_1f8ae9a0099d456e25f387798f99eec9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="thk"
+ avatar="http://cdn.libravatar.org/avatar/bfef10a428769701aeee1db978951461"
+ subject="comment 2"
+ date="2020-05-27T20:41:03Z"
+ content="""
+Actually I believe, the difference might just be that with an SSH remote, there is a remote process getting started on the remote that iterates over all files while with a directory remote, the iteration is done in the same process.
+Now when I actually look at it, the SSH remote sync seems to take a similar amount of time to sync, it only does not output all the files it iterates over.
+"""]]
diff --git a/doc/forum/sync_between_indirect_and_direct_mode.mdwn b/doc/forum/sync_between_indirect_and_direct_mode.mdwn
new file mode 100644
index 0000000000..66833cbe51
--- /dev/null
+++ b/doc/forum/sync_between_indirect_and_direct_mode.mdwn
@@ -0,0 +1,6 @@
+I have a music repository(direct mode) in my Nexus 5 which I want to sync with remote repository(indirect mode).
+
+When I run 'git annex sync --content', it did not sync the content but when I changed remote repository to direct mode, content got synced.
+
+Do I need to set some configuration ?
+Is it possible to sync content between direct and indirect mode repositories ?
diff --git a/doc/forum/sync_between_indirect_and_direct_mode/comment_1_7efc0d79196675582571c05fdd133b53._comment b/doc/forum/sync_between_indirect_and_direct_mode/comment_1_7efc0d79196675582571c05fdd133b53._comment
new file mode 100644
index 0000000000..7cbcd3c39b
--- /dev/null
+++ b/doc/forum/sync_between_indirect_and_direct_mode/comment_1_7efc0d79196675582571c05fdd133b53._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-03-10T17:57:51Z"
+ content="""
+There is no difference between direct and indirect mode repositories when it comes to communication between repositories, so they can be used in any combination.
+"""]]
diff --git a/doc/forum/sync_between_indirect_and_direct_mode/comment_2_8ac84dbaf7a4d503497487cbdb1749d8._comment b/doc/forum/sync_between_indirect_and_direct_mode/comment_2_8ac84dbaf7a4d503497487cbdb1749d8._comment
new file mode 100644
index 0000000000..42b5126271
--- /dev/null
+++ b/doc/forum/sync_between_indirect_and_direct_mode/comment_2_8ac84dbaf7a4d503497487cbdb1749d8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnDXvDvWTXmCqQ90ATTD4dV3Ii4YbnE8E0"
+ nickname="sys"
+ subject="git annex direct when not all content is in this repo"
+ date="2014-03-12T14:41:53Z"
+ content="""
+what does git annex direct do when all the content isn't available in the current repo (i am assuming it will leave symlinks for the missing content)
+"""]]
diff --git a/doc/forum/sync_between_indirect_and_direct_mode/comment_3_9acb237711669ec6046a8d07f9ed3b2c._comment b/doc/forum/sync_between_indirect_and_direct_mode/comment_3_9acb237711669ec6046a8d07f9ed3b2c._comment
new file mode 100644
index 0000000000..f743487b2b
--- /dev/null
+++ b/doc/forum/sync_between_indirect_and_direct_mode/comment_3_9acb237711669ec6046a8d07f9ed3b2c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.154"
+ subject="comment 3"
+ date="2014-03-12T17:03:30Z"
+ content="""
+Direct mode does not require all content be present any more than indirect mode does, and missing content is represented the same in both modes, with broken symlinks.
+"""]]
diff --git a/doc/forum/sync_content_through_repo_that_wants_nothing.mdwn b/doc/forum/sync_content_through_repo_that_wants_nothing.mdwn
new file mode 100644
index 0000000000..e9522727e6
--- /dev/null
+++ b/doc/forum/sync_content_through_repo_that_wants_nothing.mdwn
@@ -0,0 +1,7 @@
+I'm trying to figure out how to automatically sync all the remotes that I can currently reach while the local repo does not want any content.
+
+Specifically want to download content from a server (remote repo) to a USB-drive (directory special remote) through a local repo.
+If the local repo has no preferred content set or if the preferred content includes the files I want to sync to the disk it works.
+However, if I set the local preferred content to `exclude=*` neither `sync`, `satisfy` nor `assist` do what I had hoped, which is to download the files, copy them to the remote and then delete the local copy.
+
+Is there something I can do to achieve this behavior? 
diff --git a/doc/forum/sync_content_through_repo_that_wants_nothing/comment_1_6c014bc88fc8a685ef79a044c8938c7d._comment b/doc/forum/sync_content_through_repo_that_wants_nothing/comment_1_6c014bc88fc8a685ef79a044c8938c7d._comment
new file mode 100644
index 0000000000..d2e3334dcf
--- /dev/null
+++ b/doc/forum/sync_content_through_repo_that_wants_nothing/comment_1_6c014bc88fc8a685ef79a044c8938c7d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-01-18T21:17:13Z"
+ content="""
+What you want is the behavior of a transfer repository. See
+[[preferred_content/standard_groups]].
+"""]]
diff --git a/doc/forum/sync_content_through_repo_that_wants_nothing/comment_2_ef89154903395025bb0a0408e1c23bdf._comment b/doc/forum/sync_content_through_repo_that_wants_nothing/comment_2_ef89154903395025bb0a0408e1c23bdf._comment
new file mode 100644
index 0000000000..e81f301998
--- /dev/null
+++ b/doc/forum/sync_content_through_repo_that_wants_nothing/comment_2_ef89154903395025bb0a0408e1c23bdf._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="imlew"
+ avatar="http://cdn.libravatar.org/avatar/23858c3eed3c3ea9e21522f4c999f1ed"
+ subject="comment 2"
+ date="2024-01-18T23:09:21Z"
+ content="""
+Using the standard transfer group wouldn't work in this situation because the remotes cannot be clients (among other reason because the server repo is bigger than the external drives).
+
+But from your answer I surmise that the local repo must want the files unless they are on the drives and no longer want them once they are on drives, is that correct?
+
+I will try letting it run overnight with the local repo's wanted being `\"not copies=2\"`. Hopefully sync will drop the local copy as soon as it has been transferred to the drive and not keep that for last.
+
+"""]]
diff --git a/doc/forum/sync_content_through_repo_that_wants_nothing/comment_3_e05a3e3d991617bb2b323b5572cd771e._comment b/doc/forum/sync_content_through_repo_that_wants_nothing/comment_3_e05a3e3d991617bb2b323b5572cd771e._comment
new file mode 100644
index 0000000000..ddc96a55fc
--- /dev/null
+++ b/doc/forum/sync_content_through_repo_that_wants_nothing/comment_3_e05a3e3d991617bb2b323b5572cd771e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-01-25T15:50:04Z"
+ content="""
+`not copies=2` might be sufficient in your situation.
+
+If you look at the preferred content expression for a transfer repository, it
+is:
+
+`not (inallgroup=client and copies=client:2) and ($client)`
+
+Where `$client` is a copy of the preferred content expressions of the client.
+
+There's no reason you can't write a preferred content expression that
+does the same thing for some other group of repositories.
+"""]]
diff --git a/doc/forum/sync_quits_after_first_non-successfull_remote.mdwn b/doc/forum/sync_quits_after_first_non-successfull_remote.mdwn
new file mode 100644
index 0000000000..8caee35c26
--- /dev/null
+++ b/doc/forum/sync_quits_after_first_non-successfull_remote.mdwn
@@ -0,0 +1,27 @@
+Hello,
+
+I have observed what I think is a new behavior:
+
+
+    % git annex add . && git annex sync --content
+    commit
+    Auf Branch master
+    nichts zu committen, Arbeitsverzeichnis unverändert
+    ok
+    pull xgm
+    ok
+    pull horus
+    ssh: Could not resolve hostname horus.local: Name or service not known
+    fatal: Konnte nicht vom Remote-Repository lesen.
+    
+    Bitte stellen Sie sicher, dass die korrekten Zugriffsberechtigungen bestehen
+    und das Repository existiert.
+    failed
+    copy Backgrounds/Flo Wallpaper/Cirrus_front_over_Austnesfjorden,_Austvågøya,_Lofoten,_Norway,_2015_April.jpg git-annex: unable to check horus
+
+git annex sync quits with exist code 1. What I rather expect is that it tries to sync --content the other repositories. If I call `git annex sync --content S3` it sync to S3 just fine.
+
+S3 is backup/client, local repo is manual/client.
+
+Thanks,
+Florian
diff --git a/doc/forum/sync_quits_after_first_non-successfull_remote/comment_1_dbca6ea763702a82ae7563722cdc7fab._comment b/doc/forum/sync_quits_after_first_non-successfull_remote/comment_1_dbca6ea763702a82ae7563722cdc7fab._comment
new file mode 100644
index 0000000000..e890b13b14
--- /dev/null
+++ b/doc/forum/sync_quits_after_first_non-successfull_remote/comment_1_dbca6ea763702a82ae7563722cdc7fab._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-07-03T17:00:26Z"
+ content="""
+Thanks for reporting, I've reproduced and fixed the bug.
+
+Please file bugs in the bug tracker in the future,
+that will prevent me missing them or responding as slowly as I did with
+this one.
+"""]]
diff --git a/doc/forum/sync_remote_repo_on_local_sync_upstream.mdwn b/doc/forum/sync_remote_repo_on_local_sync_upstream.mdwn
new file mode 100644
index 0000000000..c2b566cc5d
--- /dev/null
+++ b/doc/forum/sync_remote_repo_on_local_sync_upstream.mdwn
@@ -0,0 +1,21 @@
+I am looking for a short cut for my workflow where I sync a (somewhat) central repo and a few client repos.
+
+So, I sync upstream 
+
+    laptop > git annex sync --content
+
+and ssh to the central repo and run another sync
+
+    server > git annex sync
+
+to bring it up to date so that I can sync/pull it again from my desktop.
+
+Is there an easy way to script/do both steps in one for different protocols? E.g., update a ssh repo and a USB-drive repo when syncing on the local one?
+
+At the moment, I would try to check for all known remotes
+
+    > git remote -v
+
+and depending on the protocol ssh/cd into each for triggering a sync.
+
+
diff --git a/doc/forum/sync_remote_repo_on_local_sync_upstream/comment_1_db650b4b5764e33219cb28eba2987ea5._comment b/doc/forum/sync_remote_repo_on_local_sync_upstream/comment_1_db650b4b5764e33219cb28eba2987ea5._comment
new file mode 100644
index 0000000000..0e2bb28e37
--- /dev/null
+++ b/doc/forum/sync_remote_repo_on_local_sync_upstream/comment_1_db650b4b5764e33219cb28eba2987ea5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-09-29T17:44:42Z"
+ content="""
+See
+<https://git-annex.branchable.com/tips/making_a_remote_repo_update_when_changes_are_pushed_to_it/>
+"""]]
diff --git a/doc/forum/sync_stages_deletions_on_remote.mdwn b/doc/forum/sync_stages_deletions_on_remote.mdwn
new file mode 100644
index 0000000000..73a51d0b0a
--- /dev/null
+++ b/doc/forum/sync_stages_deletions_on_remote.mdwn
@@ -0,0 +1,72 @@
+I'm having an issue with 2 repos: one on my laptop, the other on my NAS. Both are in indirect mode, running Arch Linux, and have the latest Git version. Laptop has git-annex 5.20140411-gda795e0, NAS has 5.20140319-g9aa31b7 (from prebuilt tarballs).
+
+The issue is quite simple. When I `git-annex add` new files on my laptop, commit them, and then `git-annex sync` them, they show up as staged for deletion on my NAS.
+
+    laptop $ git annex add some-file
+    laptop $ git commit -m "Add some-file"
+    laptop $ git annex sync
+    commit  ok
+    pull ds413j 
+    ok
+    push ds413j 
+    Counting objects: 133, done.
+    Delta compression using up to 8 threads.
+    Compressing objects: 100% (78/78), done.
+    Writing objects: 100% (80/80), 10.64 KiB | 0 bytes/s, done.
+    Total 80 (delta 12), reused 0 (delta 0)
+    To ssh://**/**
+       1dcd188..8ef4249  git-annex -> synced/git-annex
+       c0f45a6..21711d6  master -> synced/master
+    ok
+    laptop $ ssh $NAS
+    nas $ git status
+    On branch master
+    Changes to be committed:
+      (use "git reset HEAD <file>..." to unstage)
+
+            deleted:    some-file
+
+    nas $
+
+If I run `git annex sync` on the NAS, it will create a new commit that deletes that file. So I have to play with `git reset`/`git checkout` by hand to make sure that the new file won't be deleted.
+
+I'm not sure when this started, but I think it was after I did some stupid mistake (`git checkout -B master synced/master`, kill a `git annex sync` with Ctrl+C, or something else that even resulted in my non-bare repo to have "bare=true" in .git/config...). And I haven't yet been able to fix this.
+
+Any idea what can have caused this, how to fix it, and how to prevent it from happening again in the future?
+
+.git/config on NAS:
+
+    [core]
+            repositoryformatversion = 0
+            filemode = true
+            logallrefupdates = true
+    [annex]
+            uuid = d54ae60a-1f59-403c-923f-32ea3bf2d00f
+            version = 5
+            diskreserve = 1 megabyte
+            autoupgrade = ask
+            debug = false
+
+.git/config on laptop:
+
+    [core]
+            repositoryformatversion = 0
+            filemode = true
+            bare = false
+            logallrefupdates = true
+    [branch "master"]
+    [annex]
+            uuid = f20cb506-945d-4c78-af1a-0aa884bb899b
+            version = 5
+            diskreserve = 20 gigabytes
+            autoupgrade = ask
+            debug = false
+            expireunused = 7d
+            genmetadata = true
+    [push]
+            default = matching
+    [remote "ds413j"]
+            url = ssh://**/**
+            fetch = +refs/heads/*:refs/remotes/ds413j/*
+            annex-uuid = d54ae60a-1f59-403c-923f-32ea3bf2d00f
+            annex-sync = true
diff --git a/doc/forum/sync_stages_deletions_on_remote/comment_1_2b639066095e450c2d9be3b2775d24b3._comment b/doc/forum/sync_stages_deletions_on_remote/comment_1_2b639066095e450c2d9be3b2775d24b3._comment
new file mode 100644
index 0000000000..24495fd024
--- /dev/null
+++ b/doc/forum/sync_stages_deletions_on_remote/comment_1_2b639066095e450c2d9be3b2775d24b3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://schnouki.net/"
+ nickname="Schnouki"
+ subject="comment 1"
+ date="2014-04-17T12:16:41Z"
+ content="""
+Here's the output of `git annex sync --debug` (for a different commit): <http://ix.io/bJZ>
+"""]]
diff --git a/doc/forum/sync_stages_deletions_on_remote/comment_2_da5775526a2a476b6ead1cd1a735b8bd._comment b/doc/forum/sync_stages_deletions_on_remote/comment_2_da5775526a2a476b6ead1cd1a735b8bd._comment
new file mode 100644
index 0000000000..a3076faf7c
--- /dev/null
+++ b/doc/forum/sync_stages_deletions_on_remote/comment_2_da5775526a2a476b6ead1cd1a735b8bd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 2"
+ date="2014-04-17T19:28:59Z"
+ content="""
+`git annex sync` will push changes to your NAS, but this does not cause the work tree there to be updated. You must be running some command on the NAS that gets it work tree into the state you show. You need to tell us what that command is, since it seems to be where things are going wrong. Maybe you're running the git-annex assistant on the NAS, or maybe you run `git annex sync` on the NAS. 
+"""]]
diff --git a/doc/forum/sync_stages_deletions_on_remote/comment_3_9e07593228915936fadcf90373be9f4e._comment b/doc/forum/sync_stages_deletions_on_remote/comment_3_9e07593228915936fadcf90373be9f4e._comment
new file mode 100644
index 0000000000..fb9020252d
--- /dev/null
+++ b/doc/forum/sync_stages_deletions_on_remote/comment_3_9e07593228915936fadcf90373be9f4e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://schnouki.net/"
+ nickname="Schnouki"
+ subject="comment 3"
+ date="2014-04-22T14:59:47Z"
+ content="""
+Not running the assistant (freshly rebooted NAS, checked with `ps ax | grep annex`), not running any other git command. Still happened, until a few minutes ago: I found the cause for this issue... and it's quite frustrating.
+
+Every now and then, I interrupt a running `git annex sync` with Ctrl+C. And sometimes this causes my NAS repository to end up with `bare = true` in its `.git/config`. When this happens, I just remove the offending line and call it a day. Now I just added a `bare = false` line to that file, and that solved the problem. It seems that somehow, if you don't explicitely tell git that your repo is not bare, it considers it as a bare repository -- and the final push from `git annex sync` actually updates the `master` branch without updating the work tree.
+
+This is probably not a bug in git-annex, but rather a weird behaviour in git -- and for sure something I didn't expect to happend. But anyway it works now :) Leaving this here in case it helps other people.
+
+Joey, thanks again for your time and your help.
+"""]]
diff --git a/doc/forum/sync_stages_deletions_on_remote/comment_4_e5a3dc34c6229ec40bc999c3cab28041._comment b/doc/forum/sync_stages_deletions_on_remote/comment_4_e5a3dc34c6229ec40bc999c3cab28041._comment
new file mode 100644
index 0000000000..710392daa4
--- /dev/null
+++ b/doc/forum/sync_stages_deletions_on_remote/comment_4_e5a3dc34c6229ec40bc999c3cab28041._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.114"
+ subject="comment 4"
+ date="2014-04-24T18:22:16Z"
+ content="""
+git sets bare = false in newly created non-bare repositories. Perhaps this is why? It seems likely that git has an inconsistent default if there's no configuration. Sounds worth filing a bug on git for. OTOH, messing with .git/config  in nonstandard ways seems like a good way to cause yourself random pain too.
+"""]]
diff --git a/doc/forum/sync_stages_deletions_on_remote/comment_5_f3350d336c6c66c3aacc7caade2ef12c._comment b/doc/forum/sync_stages_deletions_on_remote/comment_5_f3350d336c6c66c3aacc7caade2ef12c._comment
new file mode 100644
index 0000000000..55f05331a0
--- /dev/null
+++ b/doc/forum/sync_stages_deletions_on_remote/comment_5_f3350d336c6c66c3aacc7caade2ef12c._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="edward"
+ subject="Same problem"
+ date="2015-08-27T09:24:38Z"
+ content="""
+I think I'm having the same problem. See my comments on [[bugs/git annex sync deleted a bunch of files (not expected)]]
+
+I've run `git annex sync` or `git annex webapp` on the laptop annex, then `git annex sync` on the external drive. I'm pretty sure some of the syncs have been interrupted. Does it help to see the .git/config from the external drive?
+
+    [core]
+    	repositoryformatversion = 0
+    	filemode = true
+    	bare = false
+    	logallrefupdates = true
+    [remote \"origin\"]
+    	url = /home/edward/annex
+    	fetch = +refs/heads/*:refs/remotes/origin/*
+    	annex-uuid = 38d109c9-7f5f-47cd-b15a-7b2beac22c64
+    [branch \"master\"]
+    	remote = origin
+    	merge = refs/heads/master
+    [annex]
+    	uuid = 822dec0f-a0d3-42f6-b0dc-a47b6bf91944
+    	version = 5
+    [remote \"x230\"]
+    	url = /home/edward/annex
+    	fetch = +refs/heads/*:refs/remotes/x230/*
+    	annex-uuid = 38d109c9-7f5f-47cd-b15a-7b2beac22c64
+
+Observations about my config, I have `bare = false`, which is correct. Do you think it is a problem that I have two remotes, `\"origin\"` and `\"x230\"` pointing at the same location?
+"""]]
diff --git a/doc/forum/syncing_home_directories.mdwn b/doc/forum/syncing_home_directories.mdwn
new file mode 100644
index 0000000000..fcd3917325
--- /dev/null
+++ b/doc/forum/syncing_home_directories.mdwn
@@ -0,0 +1,7 @@
+Hi,
+
+I synchronize home directories on a couple of machines using unison.  Is there a recommended way to do the equivalent using git-annex? 
+
+Thanks,
+
+John
diff --git a/doc/forum/syncing_home_directories/comment_1_220a6e0ffe0ea610921a63c0a6e3beab._comment b/doc/forum/syncing_home_directories/comment_1_220a6e0ffe0ea610921a63c0a6e3beab._comment
new file mode 100644
index 0000000000..f4699e74a1
--- /dev/null
+++ b/doc/forum/syncing_home_directories/comment_1_220a6e0ffe0ea610921a63c0a6e3beab._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-05T20:34:22Z"
+ content="""
+There are a few problems you are likely to run into if you try to store everything in git-annex:
+
+* git does not store certain things, including special file permissions, in a git repository
+* you can't check a .git directory into another git repository
+* git-annex locks files to prevent them being changed and this involves replacing them with symlinks (much less of a problem now that it has the direct mode)
+
+For these reasons, I currently encourage users to use one or more git-annex repositories to store and sync whatever large data files they need, but to confine this to subdirectories of the home directory. There are other tools like vcsh that are better suited to storing things like dotfiles in git, rather than using git-annex for that. And other tools like mr can make it easy to work with a set of repositories, so you can have your dotfiles stored in one or more repositories and your large files in others and update them all with one command. 
+
+See <http://vcs-home.branchable.com/> for more on this..
+"""]]
diff --git a/doc/forum/syncing_music_to_my_android_device.mdwn b/doc/forum/syncing_music_to_my_android_device.mdwn
new file mode 100644
index 0000000000..ba4b0f80a3
--- /dev/null
+++ b/doc/forum/syncing_music_to_my_android_device.mdwn
@@ -0,0 +1,17 @@
+Hi!
+
+So I am not sure how to deal with this issue right now. I have described in [[bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/]] how it takes a long time to replicate my `mp3` repository to another, crippled, filesystem (namely, FAT32). I am not sure what is going on there, but is seems difficult to setup an external device with only a subset of my music *and* keeping a proper directory structure in place.
+
+When I `git clone` the git-annex repository onto the device, it fails because it (apparently?) transfers all the files and runs out of space. I have also tried to `git init; git annex init; git remote add [...] ; git annex sync` with similar failure modes. All those tests take a long time and I would prefer avoiding to have to reproduce those again, but I will if necessary. :) There is over 20 000 files in the git-annex repository, and about 115GB of data in there. `.git` is about 130MB on a fresh clone on a non-crippled filesystem.
+
+Basically, my workaround so far has been to use a bare repository on the device: it works fairly well! I can transfer files to it with `git annex copy --to` and the clone is actually much faster. 
+
+This was working well on my Nokia N900 device, as the music player was fairly smart and could figure out that similar album tags belonged together. It did have trouble finding all the files (as it does a inotify on all the directories it finds, which obviously runs out of ram on that bit git-annex), but after a few restarts it worked.
+
+On this new Android 5.1 device (Cyanogenmod 12.1, to be more accurate), things don't go so well. The music player finds all the files much faster, but unfortunately, each song is put in a separate album, because they are all in different directories (because this is a bare repository).
+
+This is an issue that a [[todo/dumb__44___unsafe__44___human-readable_backend/]] would solve, but since that approach doesn't seem feasible right now, I am wondering how I can manage to deploy that repository more reliably.
+
+This is also similar to [[forum/usability__58___creating_an_archive_on_a_new_external_drive/]].
+
+Thanks for any advice! -- [[anarcat]]
diff --git a/doc/forum/syncing_music_to_my_android_device/comment_1_81653a23424ac04675651fb7632c57ae._comment b/doc/forum/syncing_music_to_my_android_device/comment_1_81653a23424ac04675651fb7632c57ae._comment
new file mode 100644
index 0000000000..ad30d0c41a
--- /dev/null
+++ b/doc/forum/syncing_music_to_my_android_device/comment_1_81653a23424ac04675651fb7632c57ae._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="special remote"
+ date="2016-06-23T13:03:48Z"
+ content="""
+I ended up writing a special remote for this, named [git-annex-remote-dumb](http://src.anarc.at/scripts.git/blob_plain/HEAD:/git-annex-remote-dumb) for lack of a better name. it mixes things up badly, is a abhorrent violation of protocol boundaries and is probably due to be taken to the back of the barn and shot, but it works for my case.
+
+this would be better implemented as [[todo/dumb, unsafe, human-readable_backend]], but I suspect this cannot be directly implemented either without significant changes of the git-annex design, something which is unlikely to happen since [[todo/hide missing files]] is likely to be implemented with [[design/adjusted branches]].
+
+more details about known problems, remaining tasks and limitations in the script header.
+"""]]
diff --git a/doc/forum/syncing_music_to_my_android_device/comment_2_e49c9e5da5c5d1db228b9b753bed53ff._comment b/doc/forum/syncing_music_to_my_android_device/comment_2_e49c9e5da5c5d1db228b9b753bed53ff._comment
new file mode 100644
index 0000000000..c14c9e9231
--- /dev/null
+++ b/doc/forum/syncing_music_to_my_android_device/comment_2_e49c9e5da5c5d1db228b9b753bed53ff._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-09-07T20:15:10Z"
+ content="""
+The new `git annex export` command can be used for this. It exports the
+current tree of files to a special remote. If your Android device can be
+mounted to the filesystem, you can initremote a directory special remote on
+it, and then export to it.
+
+It would also be possible to make a special remote that uses `adb` or some
+other method to manipulate the files on the Android device, rather than
+going via the directory special remote.
+
+The main downside is, if you modify files on the Android device, or add new
+files, there's no way to commit the changes from there back to
+your git repository.
+"""]]
diff --git a/doc/forum/syncing_non-git_trees_with_git-annex.mdwn b/doc/forum/syncing_non-git_trees_with_git-annex.mdwn
new file mode 100644
index 0000000000..9973782610
--- /dev/null
+++ b/doc/forum/syncing_non-git_trees_with_git-annex.mdwn
@@ -0,0 +1,46 @@
+I have a bunch of directory trees with large data files scattered over various computers and disk drives - they contain photos, videos, music, and so on.  In many cases I initially copied one of these trees from one machine to another just as a cheap and dirty backup, and then made small modifications to both trees in ways I no longer remember. For example, I returned from a trip with a bunch of new photos, and then might have rotated some of them 90 degrees on one machine, and edited or renamed them on another.
+
+What I want to do now is use git-annex as a way of initially synchronising the trees, and then fully managing them on an ongoing basis.  Note that the trees are *not* yet git repositories.  In order to be able to detect straight-forward file renames, I believe that [[the SHA1 backend|tips/using_the_SHA1_backend]] probably makes the most sense.
+
+I've been playing around and arrived at the following setup procedure.  For the sake of discussion, I assume that we have two trees `a` and `b` which live in the same directory referred to by `$td`, and that all large files end with the `.avi` suffix.
+
+     # Setup git in 'a'.
+     cd $td/a
+     git init
+
+     # Setup git-annex in 'a'.
+     echo '* annex.backend=SHA1' > .gitattributes
+     git add .gitattributes
+     git commit -m'use SHA1 backend'
+     git annex init
+
+     # Annex all large files.
+     find -name \*.avi | xargs git annex add
+     git add .
+     git commit -m'Initial import'
+
+     # Setup git in 'b'.
+     cd $td/b
+     git clone -n $td/a new
+     mv new/.git .
+     rmdir new
+     git reset # reset git index to b's wd - hangover from cloning from 'a'
+
+     # Setup git-annex in 'b'.
+     # This merges a's (origin's) git-annex branch into the local git-annex branch.
+     git annex init
+
+     # Annex all large files - because we're using SHA1 backend, some
+     # should hash to the same keys as in 'a'.
+     find -name \*.avi | xargs git annex add
+     git add .
+     git commit -m'Changes in b tree'
+
+     git remote add a $td/a
+
+     # Now pull changes in 'b' back to 'a'.
+     cd $td/a
+     git remote add b $td/b
+     git pull b master
+
+This seems to work, but have I missed anything?
diff --git a/doc/forum/syncing_non-git_trees_with_git-annex/comment_1_7f9593bdfd95e4a8814e6cc5c44619e6._comment b/doc/forum/syncing_non-git_trees_with_git-annex/comment_1_7f9593bdfd95e4a8814e6cc5c44619e6._comment
new file mode 100644
index 0000000000..bdec508792
--- /dev/null
+++ b/doc/forum/syncing_non-git_trees_with_git-annex/comment_1_7f9593bdfd95e4a8814e6cc5c44619e6._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-12-14T17:31:31Z"
+ content="""
+This is an entirely reasonable way to go about it.
+
+However, doing it this way causes files in B to always \"win\" -- If the same filename is in both repositories, with differing content, the version added in B will superscede the version from A. If A has a file that is not in B, a git commit -a in B will commit a deletion of that file.
+
+I might do it your way and look at the changes in B before (or even after) committing them to see if files from A were deleted or changed.
+
+Or, I might just instead keep B in a separate subdirectory in the repository, set up like so:
+
+<pre>
+mv b old_b
+git clone a b
+cd b
+mv ../old_b .
+git annex add old_b --not --exclude '*.avi'
+</pre>
+
+Or, a third way would be to commit A to a branch like branchA and B to a separate branchB, and not merge the branches at all.
+"""]]
diff --git a/doc/forum/syncing_non-git_trees_with_git-annex/comment_2_49f15478781a0ad5e46e75319070335c._comment b/doc/forum/syncing_non-git_trees_with_git-annex/comment_2_49f15478781a0ad5e46e75319070335c._comment
new file mode 100644
index 0000000000..94b5c2ec11
--- /dev/null
+++ b/doc/forum/syncing_non-git_trees_with_git-annex/comment_2_49f15478781a0ad5e46e75319070335c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmKPMUX0YHBjE93eBsEnacwZsddSDue3PY"
+ nickname="Oliver"
+ subject="comment 2"
+ date="2011-12-23T22:04:08Z"
+ content="""
+As joey points out the problem is B overwrites A, so that any files in A that aren't in B will be removed. But the suggestion to keep B in a separate subdirectory in the repository means I'll end up with duplicates of files in both A and B. What I want is to have the merged superset of all files from both A and B with only one copy of identical files. 
+
+The problem is that unique symlinks in A/master are deleted when B/master is merged in. To add back the deleted files after the merge you can do this:
+
+    git checkout master~1 deleted_file_name                                                              #checkout a single deleted file called deleted_file_name
+    git diff master~1 master --numstat --name-only --diff-filter=D                                       #get the names of all files deleted between master and master~1
+    git diff master~1 master --numstat --name-only --diff-filter=D | xargs git checkout master~1         #checkout all deleted files between master and master~1
+
+Once the first merge has been done after set up, you can continue to make changes to A and B and future merges won't require accounting for deleted files in this way.
+"""]]
diff --git a/doc/forum/syncing_non-git_trees_with_git-annex/comment_3_6d8f399f0549eddd1d1f5c9c9a10c654._comment b/doc/forum/syncing_non-git_trees_with_git-annex/comment_3_6d8f399f0549eddd1d1f5c9c9a10c654._comment
new file mode 100644
index 0000000000..1793e686fa
--- /dev/null
+++ b/doc/forum/syncing_non-git_trees_with_git-annex/comment_3_6d8f399f0549eddd1d1f5c9c9a10c654._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="re-annexing previously annexed files"
+ date="2012-03-29T21:41:54Z"
+ content="""
+Here's another handy command-line which annexes all files in repo B which have already been annexed in repo A:
+
+    git status --porcelain | sed -n '/^ T /{s///;p}' | xargs git annex add
+
+The 'T' outputted by git status for these files indicates a type change: it's a symlink to the annex in repo A, but a normal file in repo B.
+
+"""]]
diff --git a/doc/forum/syncing_to_an_encrypted_remove_won__39__t_prompt_with_pinentry-gtk2.mdwn b/doc/forum/syncing_to_an_encrypted_remove_won__39__t_prompt_with_pinentry-gtk2.mdwn
new file mode 100644
index 0000000000..8e6f2805a2
--- /dev/null
+++ b/doc/forum/syncing_to_an_encrypted_remove_won__39__t_prompt_with_pinentry-gtk2.mdwn
@@ -0,0 +1,3 @@
+I'm trying to sync my unencrypted local repo to an encrypted remote located on an external drive. I'm using Debian 8.1. When I run `git-annex sync encrypted-remote` I get prompted in my shell for the password. I'm not sure why, as other places pinentry-gtk2 pops up. This is annoying because my gpg key isn't getting cached, so I have to enter my long password several times. 
+
+How can I make git-annex/git-remote-gcrypt use pinentry-gtk2?
diff --git a/doc/forum/syncing_to_an_encrypted_remove_won__39__t_prompt_with_pinentry-gtk2/comment_1_daf41d0e59d384dfe5c86a53600ea3f7._comment b/doc/forum/syncing_to_an_encrypted_remove_won__39__t_prompt_with_pinentry-gtk2/comment_1_daf41d0e59d384dfe5c86a53600ea3f7._comment
new file mode 100644
index 0000000000..0b521a3e62
--- /dev/null
+++ b/doc/forum/syncing_to_an_encrypted_remove_won__39__t_prompt_with_pinentry-gtk2/comment_1_daf41d0e59d384dfe5c86a53600ea3f7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica"
+ subject="needed a gpg.conif"
+ date="2015-09-16T04:20:53Z"
+ content="""
+Not sure why Debian stable didn't give me a default gpg.config, but it didn't. Copying one from an old installation worked.
+"""]]
diff --git a/doc/forum/taskwarrior.mdwn b/doc/forum/taskwarrior.mdwn
new file mode 100644
index 0000000000..3e44cc610c
--- /dev/null
+++ b/doc/forum/taskwarrior.mdwn
@@ -0,0 +1,11 @@
+I try to sync my taskWarrior files .task/*.data with git-annex ... but there is two problem :
+
+- i need to chmod 755 my files because taskWarrior doesn't recognize them, or say "problem with permission" 
+
+- taskwarrior seems crazy with symbolic link used by git-annex, undo not work, task appear multiple times , etc.
+
+Is there any solution ?
+Any user experienced the same problem?
+
+Thanks
+Sr.
diff --git a/doc/forum/taskwarrior/comment_1_1c3a29e7d292cb602d9d349f8009b51e._comment b/doc/forum/taskwarrior/comment_1_1c3a29e7d292cb602d9d349f8009b51e._comment
new file mode 100644
index 0000000000..c8682b3787
--- /dev/null
+++ b/doc/forum/taskwarrior/comment_1_1c3a29e7d292cb602d9d349f8009b51e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2013-08-06T12:44:11Z"
+ content="""
+* You could try metastore (not merge friendly), git-cache-meta (pretty minimal) or metamonger (not done yet) to sync your file permissions
+* Look into direct mode to avoid symlinks
+* Alternatively, check your taskwarrior files into git, not git-annex, to avoid symlinks
+"""]]
diff --git a/doc/forum/taskwarrior/comment_2_4b3d70501763f6d36c927ae37bbd33c2._comment b/doc/forum/taskwarrior/comment_2_4b3d70501763f6d36c927ae37bbd33c2._comment
new file mode 100644
index 0000000000..ec6bcb9529
--- /dev/null
+++ b/doc/forum/taskwarrior/comment_2_4b3d70501763f6d36c927ae37bbd33c2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 2"
+ date="2014-04-14T15:27:48Z"
+ content="""
+Using direct mode would replace symlinks with actual files.
+"""]]
diff --git a/doc/forum/telehash_syncing.mdwn b/doc/forum/telehash_syncing.mdwn
new file mode 100644
index 0000000000..3a5266506e
--- /dev/null
+++ b/doc/forum/telehash_syncing.mdwn
@@ -0,0 +1,10 @@
+Hi
+
+I have read some info about telehash. It looks verry promising. I was wondering though how syncing will work. For example. I have 2 computers. Normal PC and a laptop. Mostly only one is on at a time. 
+
+* Sync messages will be sent over telehash protocoll ?
+* What if I push some changes (they will be synced to a shared repository) and laptop is not online. How will git-annex know what to sync from a shared repository ?
+* Do you plan to send files/commits directly to online clients ? If 2 friends are online at the same time.
+* What will happen with data on a shared repository if all clients have synced content ? Will it be deleted since it is not longer needed ?
+
+I was thinking of a model where you sync directly (if possible), and just drop shared content to repo for offline users. Whan everyone have pulled content it may be removed from shared repo.
diff --git a/doc/forum/tell_us_how_you__39__re_using_git-annex.mdwn b/doc/forum/tell_us_how_you__39__re_using_git-annex.mdwn
new file mode 100644
index 0000000000..d289b9f50a
--- /dev/null
+++ b/doc/forum/tell_us_how_you__39__re_using_git-annex.mdwn
@@ -0,0 +1,6 @@
+Tell your git-annex stories here. Feel free to give as little or as much detail
+as appropriate about how you're using it. How's it working out for you?
+
+See [[testimonials]] for some other stories.
+
+[[!meta author=Joey]]
diff --git a/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_1_4884803ddee7f642a3ac995a19967a6a._comment b/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_1_4884803ddee7f642a3ac995a19967a6a._comment
new file mode 100644
index 0000000000..2351378bca
--- /dev/null
+++ b/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_1_4884803ddee7f642a3ac995a19967a6a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://mildred.fr/"
+ subject="just amazing"
+ date="2012-04-12T17:12:41Z"
+ content="""
+git-annex is just amazing. I just started using it and for once, I have hope to be able to organize my files a little better than now.
+
+Currently, I have a huge homedir. From time to time, I move file away in external hard drives, then forget about them. When I want to look at them back, I just can't because I have forgotten where they are. I have also a ton of files on those drives that I can't access because they are not indexed. With git-annex I have hope to put all of these files on a git repository. I will be able to see them everywhere, and find them when I need to.
+
+I might stop loosing files for once.
+
+I might avoid having multiple copies of the same things over and over again, without knowing so. and regain some more disk space.
+
+For the moment, I'm archiving my photographs. But there is one thing that might not go very well: directory hierarchies where everything is important (file owner, specific permissions, symlinks). I won't just be able to blindly annex all of these files. But for the moment I'll stick at archiving ocuments and it should be amazing.
+
+[Mildred](http://mildred.fr)
+"""]]
diff --git a/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_2_61f5054918e7b36c191454365bc7f3b7._comment b/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_2_61f5054918e7b36c191454365bc7f3b7._comment
new file mode 100644
index 0000000000..3bd981c5db
--- /dev/null
+++ b/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_2_61f5054918e7b36c191454365bc7f3b7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://cgray.myopenid.com/"
+ nickname="cgray"
+ subject="comment 2"
+ date="2012-04-14T01:18:53Z"
+ content="""
+Git-annex has really helped me with my media files.  I have a big NAS drive where I keep all my music, tv, and movies files, each in their own git annex.  I tend to keep the media that I want to watch or listen to on my laptop and then drop it when it is done.  This way I don't have too much on my laptop at any one time, but I have a nice selection for when I'm traveling and don't have access to my NAS.
+
+Additionally, I have a mp3 player that will format itself randomly every few months or so.  I keep my podcasts on it in a git annex and in a git annex on my laptop.  When I am done with a podcast, I can delete it from the mp3 player and then sync that information with my laptop.  With this method, I have a backup of what should be on my mp3 player, so I don't need to worry about losing it all when the mp3 player decides it's had enough.
+"""]]
diff --git a/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_3_db07e8703be606c998c831e91d300d69._comment b/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_3_db07e8703be606c998c831e91d300d69._comment
new file mode 100644
index 0000000000..1a80bb4808
--- /dev/null
+++ b/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_3_db07e8703be606c998c831e91d300d69._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://bergey.dreamwidth.org/"
+ ip="66.80.90.109"
+ subject="git-annex, media, emacs"
+ date="2012-08-31T01:47:36Z"
+ content="""
+I've been using git-annex for a month or two to manage my music collection.  It's great to know I can drop files if I need space on the laptop, knowing exactly where I have other copies.  Now I'm writing an emacs mode to help me keep track: https://gitorious.org/emacs-contrib/annex-mode
+
+Locally available files are colored differently, and pressing g runs `git annex get` on the file at point.
+"""]]
diff --git a/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_4_a58595969cdd42ed20210e9615b42e42._comment b/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_4_a58595969cdd42ed20210e9615b42e42._comment
new file mode 100644
index 0000000000..d80423eac0
--- /dev/null
+++ b/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_4_a58595969cdd42ed20210e9615b42e42._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="Best thing since sliced bread"
+ date="2012-11-21T13:08:57Z"
+ content="""
+It's amazing how perfect git annex is for my use case.
+
+I record music, which results in a bunch of big files that don't change, and a bunch of small files which change often.
+
+I also need these files to be preserved for the long haul, and be verified now and then. They also need to be backed up three or four times, because they're original files! Keeping track of all that was a headache before git annex, and I was also constantly awake at night because it was impossible to verify if everything's still okay.
+
+Now I just dump everything into my archive annex and I know where everything is, and that it's safe, period. I even set myself up a raspberry pi with a usb drive adapter and put some spindown code in a cron job. Now I have a hard drive at rest that I can access from anywhere at any time. The whole thing gets backed up by Amazon Glacier, but if Amazon starts getting pesky I can just add another backend and sync it up. I can even version my small files if I want to by putting them directly into git. This entire thing would have been such a huge undertaking but now it's easy. I dump everything into the annex and to the actual backups whenever I get round to it. It just has a natural flow to it.
+
+Et voila. Professional grade backups, at home, independant from any specific vendor. I absolutely never have to worry about my files going anywhere, and if I get super paranoid, I can just \"git annex fsck\" and mathematically prove to myself everything's still there.
+
+It's totally sad how many creative people will be losing their life's work in a couple of years because they rely on regular filesystems on their USB drives. Stuff like DropBox and SpiderOak is better than nothing but trusting single vendor to not screw up or mess with your life's work is just plain creepy.
+
+I just have a huge, warm fuzzy feeling now. If this sounds like I'm relentlessly hyping git annex, it's because I am! It deserves it!
+
+
+"""]]
diff --git a/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_5_4de0a5431431e80f4a81d87e649d4598._comment b/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_5_4de0a5431431e80f4a81d87e649d4598._comment
new file mode 100644
index 0000000000..c5bdf56f4a
--- /dev/null
+++ b/doc/forum/tell_us_how_you__39__re_using_git-annex/comment_5_4de0a5431431e80f4a81d87e649d4598._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="toh_corpora"
+ avatar="http://cdn.libravatar.org/avatar/c4265d106fd775ab35231ea3f9696cb0"
+ subject="comment 5"
+ date="2018-11-27T13:59:36Z"
+ content="""
+It is not an exaggeration to say that Git Annex has improved my life. I have used it to organize massive collections of files with large efficiency. I have also been using it to organize and process almost 40 years of video content.
+"""]]
diff --git a/doc/forum/temporary_AWS_credentials.mdwn b/doc/forum/temporary_AWS_credentials.mdwn
new file mode 100644
index 0000000000..c62287ac38
--- /dev/null
+++ b/doc/forum/temporary_AWS_credentials.mdwn
@@ -0,0 +1,2 @@
+Can you add support for temporary AWS credentials?  You just have to pass AWS_SESSION_TOKEN, in addition to the usual AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, to the AWS APIs.
+This will enable working with time-limited and multifactor-authentication-protected credentials.
diff --git a/doc/forum/temporary_AWS_credentials/comment_1_655825b3aa981e97969e226c98034c4b._comment b/doc/forum/temporary_AWS_credentials/comment_1_655825b3aa981e97969e226c98034c4b._comment
new file mode 100644
index 0000000000..90788412a4
--- /dev/null
+++ b/doc/forum/temporary_AWS_credentials/comment_1_655825b3aa981e97969e226c98034c4b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-09-05T19:36:52Z"
+ content="""
+Sure, done.
+"""]]
diff --git a/doc/forum/temporary_AWS_credentials/comment_2_d4b66fd587c3a0ce74436ec09b398f10._comment b/doc/forum/temporary_AWS_credentials/comment_2_d4b66fd587c3a0ce74436ec09b398f10._comment
new file mode 100644
index 0000000000..aafead83ae
--- /dev/null
+++ b/doc/forum/temporary_AWS_credentials/comment_2_d4b66fd587c3a0ce74436ec09b398f10._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/iOGTltEpmOTQ.xZ99NFP5c7Zdcc-#6a7ba"
+ nickname="Ilya S"
+ avatar="http://cdn.libravatar.org/avatar/8a133555cc739a35b83b07d5724d28d9e2f7852c224e949eec6fd4fb7693331e"
+ subject="comment 2"
+ date="2018-09-06T04:17:35Z"
+ content="""
+Thanks a lot!
+"""]]
diff --git a/doc/forum/test_whether_a_file_is_already_annexed.mdwn b/doc/forum/test_whether_a_file_is_already_annexed.mdwn
new file mode 100644
index 0000000000..55ac739ae9
--- /dev/null
+++ b/doc/forum/test_whether_a_file_is_already_annexed.mdwn
@@ -0,0 +1 @@
+I am storing the pictures I took over the years with git-annex. Frequently I come across messy old directories with lots of pictures inside and I want to know which ones were already annexed - or which ones were not. Is there a quick way to test whether the content of a given file is already annexed? I mean computing the key (hash) of the given file and testing whether it is already present among the annex objects.
diff --git a/doc/forum/test_whether_a_file_is_already_annexed/comment_1_55bcb41abae2b70c046e3da1c4d8c761._comment b/doc/forum/test_whether_a_file_is_already_annexed/comment_1_55bcb41abae2b70c046e3da1c4d8c761._comment
new file mode 100644
index 0000000000..d175983e38
--- /dev/null
+++ b/doc/forum/test_whether_a_file_is_already_annexed/comment_1_55bcb41abae2b70c046e3da1c4d8c761._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="whereis"
+ date="2015-09-03T01:07:32Z"
+ content="""
+Thought to say that you could use 'info' but  http://git-annex.branchable.com/bugs/git_annex_info_is_reporting_file_as_not_annexed_in_direct_mode/ .
+What about 'git annex whereis FILE' ?  it should be empty output for non-annexed file
+"""]]
diff --git a/doc/forum/test_whether_a_file_is_already_annexed/comment_2_e2531c7e77bbc75f24af7ce5f789826e._comment b/doc/forum/test_whether_a_file_is_already_annexed/comment_2_e2531c7e77bbc75f24af7ce5f789826e._comment
new file mode 100644
index 0000000000..2d0962fc3d
--- /dev/null
+++ b/doc/forum/test_whether_a_file_is_already_annexed/comment_2_e2531c7e77bbc75f24af7ce5f789826e._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="emanuele.olivetti@47d88ed185b03191e25329caa6fabc2efb3118b2"
+ nickname="emanuele.olivetti"
+ subject="not whereis"
+ date="2015-09-03T07:44:49Z"
+ content="""
+First of all thank you for the answer and the bug report. Unfortunately git-annex whereis seems not to be the answer to my problem, because it works only when queried on already annexed files, while I'd like to test the yet-not-annexed ones. Here's an example using whereis:
+
+    git-annex whereis SAM_7198.m4v     # SAM_7198.m4v is an already annexed files in the current directory, so within the repository: whereis works well
+    whereis SAM_7198.m4v (2 copies)
+        5dd7f891-579a-45c6-a5bf-3ca42e3a5f9a -- laptop [here]
+        ebf56bea-2970-42b1-bace-9d72ac9ed8d1 -- emanuele@desktop:/home/emanuele/annex [origin]
+    ok
+    
+    cp -L SAM_7198.m4v zzz  # creating a copy of a that file
+    git-annex whereis zzz  # output is empty, so the file was not found, despite having the same content of SAM_7198.m4v and being in the repo dir
+    
+    cp -L SAM_7198.m4v /tmp/  # copying the annexed file outside the repo
+    git-annex whereis /tmp/SAM_7198.m4v 
+    fatal: /tmp/SAM_7198.m4v: '/tmp/SAM_7198.m4v' is outside repository
+
+"""]]
diff --git a/doc/forum/test_whether_a_file_is_already_annexed/comment_3_21f51c99b1aac8b3292f60bd83493e94._comment b/doc/forum/test_whether_a_file_is_already_annexed/comment_3_21f51c99b1aac8b3292f60bd83493e94._comment
new file mode 100644
index 0000000000..769c1c2b7d
--- /dev/null
+++ b/doc/forum/test_whether_a_file_is_already_annexed/comment_3_21f51c99b1aac8b3292f60bd83493e94._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 3"
+ date="2015-09-03T08:05:52Z"
+ content="""
+Hm.. having some kind of exposure of the key generation code on the command line would actually be pretty useful. So you can do something like:
+
+    find -type f | xargs git annex genkey --format '${key} ${file}'
+
+Probably worth a TODO, really.
+
+Regarding your situation, one way of doing it would be to recursively copy the photo directory as hardlinks, `git annex import --clean-duplicates` the hardlinked copies, then diff the directories. This would give you a list of removals and those removals are already in the repo.
+
+Or if you just want to remove them, just run '*git annex import --clean-duplicates*' on the original photos directory. **NOTE: There was recently an issue with git-annex deleting files that it didn't have any known copies of, so a recent version is highly recommended if using --clean-duplicates.**
+"""]]
diff --git a/doc/forum/test_whether_a_file_is_already_annexed/comment_4_2c61629777f47ce3e697298d5736f997._comment b/doc/forum/test_whether_a_file_is_already_annexed/comment_4_2c61629777f47ce3e697298d5736f997._comment
new file mode 100644
index 0000000000..d5d2d1dea4
--- /dev/null
+++ b/doc/forum/test_whether_a_file_is_already_annexed/comment_4_2c61629777f47ce3e697298d5736f997._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-09-09T17:43:22Z"
+ content="""
+You can use either `git-annex import --deduplicate` 
+or `git annex import --skip-duplicates` to import files from a directory
+except for ones already in the repository. The former deletes the duplicate
+files, and the latter leaves them as-is.
+
+I don't think there's currently a good stand-alone way to check if a file is a
+duplicate of content already in the annex, before adding it.
+Would need a new command to be added. 
+
+Of course, if you simply `git annex add` everything, regular hash based
+deduplication will point the duplicate file to the same object used by
+the file when you added it earlier. So, you don't need to worry about
+adding duplicates wasting much space. They may make your repo more
+cluttered than you like, is all.
+
+See also this tip: [[tips/finding_duplicate_files]].
+"""]]
diff --git a/doc/forum/the___39__here__39___remote.mdwn b/doc/forum/the___39__here__39___remote.mdwn
new file mode 100644
index 0000000000..4c3c3363bb
--- /dev/null
+++ b/doc/forum/the___39__here__39___remote.mdwn
@@ -0,0 +1 @@
+Is it correct that whenever the documentation refers to a "remote", the "here" remote can be specified to denote the local annex?
diff --git a/doc/forum/the___39__here__39___remote/comment_1_8100ed97a671afea207efe3f70230707._comment b/doc/forum/the___39__here__39___remote/comment_1_8100ed97a671afea207efe3f70230707._comment
new file mode 100644
index 0000000000..91bf8fc6c9
--- /dev/null
+++ b/doc/forum/the___39__here__39___remote/comment_1_8100ed97a671afea207efe3f70230707._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-01-17T17:18:17Z"
+ content="""
+No, "here" is not a remote. It is a way to refer to a repository that can
+be used in places where the name of a remote, or a UUID, can also be used
+to refer to a repository.
+
+For example, `git annex move --from here` doesn't work, and there's nothing
+it would make sense for it to do.
+"""]]
diff --git a/doc/forum/time_profiling_the_assistant.mdwn b/doc/forum/time_profiling_the_assistant.mdwn
new file mode 100644
index 0000000000..95a02975de
--- /dev/null
+++ b/doc/forum/time_profiling_the_assistant.mdwn
@@ -0,0 +1,19 @@
+From the repo (commit ecc548) I built git-annex with stack issuing this command:
+
+    stack install --executable-profiling --library-profiling --ghc-options="-rtsopts -auto-all"
+
+then I run the output executable with +RTS -p like
+
+    git-annex version +RTS -p
+
+and obtain the corresponding git-annex.prof with the time profile.
+
+What I am unable to do is to get a time profile of the assistant: if I kill it the git-annex.prof file is empty, same happens if I stop the assistant with
+
+    git-annex assistant --stop
+
+So... is there another way to time-profile a git-annex command? Am I missing something in this procedure?
+
+Any advice is welcome :)
+
+-- zarel
diff --git a/doc/forum/time_profiling_the_assistant/comment_1_0227d9c0db24c6abadfe091f92848ec6._comment b/doc/forum/time_profiling_the_assistant/comment_1_0227d9c0db24c6abadfe091f92848ec6._comment
new file mode 100644
index 0000000000..63971d291f
--- /dev/null
+++ b/doc/forum/time_profiling_the_assistant/comment_1_0227d9c0db24c6abadfe091f92848ec6._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-03T19:23:59Z"
+ content="""
+The assistant is stopped by sending it a TERM signal. Seems that the RTS
+does not save profiling on TERM.
+
+Try manually sending it an INT signal instead. The RTS does save profiling
+when the program is ctrl-c'd.
+
+I'd probably just run git annex assistant --foreground and then ctrl-c it.
+
+There's also a cabal flag to enable EKG, so you can watch pretty graphs in
+a web browser while it's running.
+"""]]
diff --git a/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs.mdwn b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs.mdwn
new file mode 100644
index 0000000000..8981200d88
--- /dev/null
+++ b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs.mdwn
@@ -0,0 +1,22 @@
+This is work in progress, since there is now a [[special_remotes/hook]] for users to plug in whatever they want as a remote, here's my recipe for using tahoe-lafs as a remote, this is a copy and paste the relavent section from my .git/config file
+
+        tahoe-store-hook = tahoe put $ANNEX_FILE tahoe:$ANNEX_KEY
+        tahoe-retrieve-hook = tahoe get tahoe:$ANNEX_KEY $ANNEX_FILE
+        tahoe-remove-hook = tahoe rm tahoe:$ANNEX_KEY
+        tahoe-checkpresent-hook = tahoe ls tahoe:$ANNEX_KEY 2>&1 || echo FAIL
+
+Where `tahoe:` is a tahoe-lafs alias, ideally you should create a new alias (DIR-CAP or whatever the terminolgy is) to store your files, I just used the default `tahoe:` alias for testing.
+
+The only quirk I've noticed is this...
+
+<pre>
+$ git annex whereis .
+whereis frink.jar (2 copies) 
+  	084603a8-7243-11e0-b1f5-83102bcd7953  -- here (testtest)
+   	1d1bc312-7243-11e0-a9ce-5f10c0ce9b0a
+ok
+</pre>
+
+1d1bc312-7243-11e0-a9ce-5f10c0ce9b0a is my [[!google tahoe-lafs]] remote, but there is no label/description on it. The checkpresent-hook was a little confusing when I was setting it up, I'm currently unsure if I am doing the right thing or not with my hook. My get and put commands are a little verbose for now, i might redirect it to /dev/null once I am happier with the overall performance/behaviour my setup.
+
+Other than the quirks above, I am able to put and get files from my tahoe-lafs remote. The only thing that I have not figured out is how to "remove a file" on the remote to free up space on the remote.
diff --git a/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_1_76bb33ce45ce6a91b86454147463193b._comment b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_1_76bb33ce45ce6a91b86454147463193b._comment
new file mode 100644
index 0000000000..388641f69e
--- /dev/null
+++ b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_1_76bb33ce45ce6a91b86454147463193b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="whereis labels"
+ date="2011-04-29T13:08:35Z"
+ content="""
+You should be able to fix the missing label by editing .git-annex/uuid.log and adding
+
+    1d1bc312-7243-11e0-a9ce-5f10c0ce9b0a tahoe
+"""]]
diff --git a/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_2_4d9b9d47d01d606a475678f630797bf9._comment b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_2_4d9b9d47d01d606a475678f630797bf9._comment
new file mode 100644
index 0000000000..e7c3d619dd
--- /dev/null
+++ b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_2_4d9b9d47d01d606a475678f630797bf9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-04-29T15:24:56Z"
+ content="""
+If `tahoe ls` outputs only the key, on its own line, and exits nonzero if it's not present, then I think you did the right thing.
+
+To remove a file, use `git annex move file --from tahoe` and then you can drop it locally.
+"""]]
diff --git a/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_3_8a812b11fcc2dc3b6fcf01cdbbb8459d._comment b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_3_8a812b11fcc2dc3b6fcf01cdbbb8459d._comment
new file mode 100644
index 0000000000..16ad9e9886
--- /dev/null
+++ b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_3_8a812b11fcc2dc3b6fcf01cdbbb8459d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 3"
+ date="2011-04-29T15:33:24Z"
+ content="""
+@justin, I discovered that \"git annex describe\" did what I wanted
+
+@joey, yep that is the behaviour of \"tahoe ls\", thanks for the tip on removing the file from the remote.
+
+It seems to be working okay for now, the only concern is that on the remote everything is dumped into the same directory, but I can live with that, since I want to track biggish blobs and not lots of small little files.
+"""]]
diff --git a/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_4_fc98c819bc5eb4d7c9e74d87fb4f6f3b._comment b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_4_fc98c819bc5eb4d7c9e74d87fb4f6f3b._comment
new file mode 100644
index 0000000000..5d271c6f3c
--- /dev/null
+++ b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_4_fc98c819bc5eb4d7c9e74d87fb4f6f3b._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 4"
+ date="2011-04-29T16:17:11Z"
+ content="""
+I've just tried to use the ANNEX_HASH_ variables, example of my configuration
+
+<pre>
+    git config annex.tahoe-store-hook 'tahoe mkdir $ANNEX_HASH_1 && tahoe put $ANNEX_FILE tahoe:$ANNEX_HASH_1/$ANNEX_KEY'
+    git config annex.tahoe-retrieve-hook 'tahoe get tahoe:$ANNEX_HASH_1/$ANNEX_KEY $ANNEX_FILE'
+    git config annex.tahoe-remove-hook 'tahoe rm tahoe:$ANNEX_HASH_1/$ANNEX_KEY'
+    git config annex.tahoe-checkpresent-hook 'tahoe ls tahoe:$ANNEX_HASH_1/$ANNEX_KEY 2>&1 || echo FAIL'
+    git annex initremote library type=hook hooktype=tahoe encryption=none
+    git annex describe 1d1bc312-7243-11e0-a9ce-5f10c0ce9b0a library
+</pre>
+
+It's seems to work quite well for me now, I did run across this when I tried to drop a file locally, leaving the file on my remote
+
+<pre>
+jtang@x00:/tmp/annex3 $ git annex drop .
+drop frink.sh (checking library...) (unsafe) 
+  Could only verify the existence of 0 out of 1 necessary copies
+  Try making some of these repositories available:
+  	1d1bc312-7243-11e0-a9ce-5f10c0ce9b0a  -- library
+  (Use --force to override this check, or adjust annex.numcopies.)
+failed
+drop t/frink.jar (checking library...) (unsafe) 
+  Could only verify the existence of 0 out of 1 necessary copies
+  Try making some of these repositories available:
+  	1d1bc312-7243-11e0-a9ce-5f10c0ce9b0a  -- library
+  (Use --force to override this check, or adjust annex.numcopies.)
+failed
+git-annex: 2 failed
+1|jtang@x00:/tmp/annex3 $ 
+</pre>
+
+I do know that the files exist in my library as I have just inserted them, it seemed to work when I didnt have the hashing, it appears that the checkpresent doesn't seem to pass the ANNEX_HASH_* variables (from the limited debugging I did)
+"""]]
diff --git a/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_5_c459fb479fe7b13eaea2377cfc1923a6._comment b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_5_c459fb479fe7b13eaea2377cfc1923a6._comment
new file mode 100644
index 0000000000..9127cdeeaa
--- /dev/null
+++ b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_5_c459fb479fe7b13eaea2377cfc1923a6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 5"
+ date="2011-04-29T18:01:04Z"
+ content="""
+I've corrected the missing `ANNEX_HASH_*` oversight. (It also affected removal, btw.)
+"""]]
diff --git a/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_6_2e9da5a919bbbc27b32de3b243867d4f._comment b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_6_2e9da5a919bbbc27b32de3b243867d4f._comment
new file mode 100644
index 0000000000..80874db31d
--- /dev/null
+++ b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_6_2e9da5a919bbbc27b32de3b243867d4f._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 6"
+ date="2011-04-29T20:11:08Z"
+ content="""
+Cool, that seems to make things work as expected, here's an updated recipe
+
+
+<pre>
+git config annex.tahoe-store-hook 'tahoe mkdir tahoe:$ANNEX_HASH_1/$ANNEX_HASH_2 && tahoe put $ANNEX_FILE tahoe:$ANNEX_HASH_1/$ANNEX_HASH_2/$ANNEX_KEY'
+git config annex.tahoe-retrieve-hook 'tahoe get tahoe:$ANNEX_HASH_1/$ANNEX_HASH_2/$ANNEX_KEY $ANNEX_FILE'
+git config annex.tahoe-remove-hook 'tahoe rm tahoe:$ANNEX_HASH_1/$ANNEX_HASH_2/$ANNEX_KEY'
+git config annex.tahoe-checkpresent-hook 'tahoe ls tahoe:$ANNEX_HASH_1/$ANNEX_HASH_2/$ANNEX_KEY 2>&1 || echo FAIL'
+git annex initremote library type=hook hooktype=tahoe encryption=none
+git annex describe 1d1bc312-7243-11e0-a9ce-5f10c0ce9b0a library
+</pre>
+
+
+I just needs some of the output redirected to /dev/null.
+
+(I updated this comment to fix a bug. --[[Joey]])
+"""]]
diff --git a/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_7_d636c868524b2055ee85832527437f90._comment b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_7_d636c868524b2055ee85832527437f90._comment
new file mode 100644
index 0000000000..1d75fb9631
--- /dev/null
+++ b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_7_d636c868524b2055ee85832527437f90._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="zooko"
+ ip="97.118.97.117"
+ subject="request for information, plus some ideas"
+ date="2011-05-14T05:07:17Z"
+ content="""
+Hey Jimmy: how's this working for you now? I would expect it to go slower and slower since Tahoe-LAFS has an O(N) algorithm for reading or updating directories.
+
+Of course, if it is still fast enough for your uses then that's okay. :-)
+
+(We're working on optimizations of this for future releases of Tahoe-LAFS.)
+
+I'd like to understand the desired behavior of store-hook and retrieve-hook better, in order to see if there is a more efficient way to use Tahoe-LAFS for this.
+
+Off to look for docs.
+
+Regards,
+
+Zooko
+"""]]
diff --git a/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_8_39dc449cc60a787c3bfbfaaac6f9be0c._comment b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_8_39dc449cc60a787c3bfbfaaac6f9be0c._comment
new file mode 100644
index 0000000000..dc97128bd1
--- /dev/null
+++ b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_8_39dc449cc60a787c3bfbfaaac6f9be0c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 8"
+ date="2011-05-14T10:02:26Z"
+ content="""
+@joey thanks for the update in the previous comment, I had forgotten about updating it.
+
+@zooko it's working okay for me right now, since I'm only putting fairly big blogs on stuff on to it and only things that I *really* care about. On the performance side, if it ran faster then it would be nicer :)
+"""]]
diff --git a/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_9_2592749c2f02b3e151896e31acba359b._comment b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_9_2592749c2f02b3e151896e31acba359b._comment
new file mode 100644
index 0000000000..ba58643b97
--- /dev/null
+++ b/doc/forum/tips__58___special__95__remotes__47__hook_with_tahoe-lafs/comment_9_2592749c2f02b3e151896e31acba359b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmsz4weoPXV2oEtv3zpo9dOxn_SEPz-7Iw"
+ nickname="Zooko"
+ subject="more notes about Tahoe-LAFS performance"
+ date="2014-04-21T07:18:06Z"
+ content="""
+In case anyone is reading this thread: https://github.com/zooko/tahoe-lafs/blob/3c13c138cf09e83d2f8001888e2a7de85564d406/docs/frontends/key-value-store.rst
+"""]]
diff --git a/doc/forum/transfer_bare_repo_setup_problem.mdwn b/doc/forum/transfer_bare_repo_setup_problem.mdwn
new file mode 100644
index 0000000000..239d268cf0
--- /dev/null
+++ b/doc/forum/transfer_bare_repo_setup_problem.mdwn
@@ -0,0 +1,111 @@
+Thanks to Joey's help, I managed to get the transfer repository setup working in a [previous forum question](https://git-annex.branchable.com/forum/client_repositories_setup_problem/).
+
+Now, I'm trying to do something similar, but using a bare git repository as the transfer repo instead of a regular git repository.
+
+Here's my bash script which bootstraps the setup stage:
+
+```
+#/usr/bin/env bash
+
+# Useful links:
+# https://git-annex.branchable.com/bare_repositories/
+
+# Just a way to access the script's directory
+cd "$(dirname "$0")"
+DIR="$(pwd)"
+
+# Create the 1st client repository
+mkdir $DIR/client1
+cd $DIR/client1
+git init && git annex init
+
+# Create the 2nd client repository
+mkdir $DIR/client2
+cd $DIR/client2
+git init && git annex init
+
+# Create the transfer repository
+mkdir $DIR/share
+cd $DIR/share
+git init --bare && git annex init
+
+# Setup the remotes and groups for the transfer repository
+cd $DIR/share
+git remote add client1 $DIR/client1
+git remote add client2 $DIR/client2
+git annex wanted . standard
+git annex group . transfer
+git annex group client1 client
+git annex group client2 client
+git annex mincopies 2
+git annex numcopies 2
+
+# Setup the remotes and groups for the 1st client repository.
+cd $DIR/client1
+git remote add share $DIR/share
+git annex wanted . standard
+git annex group . client
+git annex group share transfer
+git annex config --set annex.addunlocked true
+git co -b main
+
+# Setup the remotes and groups for the 2nd client repository.
+cd $DIR/client2
+git remote add share $DIR/share
+git annex wanted . standard
+git annex group . client
+git annex group share transfer
+git annex config --set annex.addunlocked true
+git co -b main
+
+# Add a single file to the 1st client.
+cd $DIR/client1
+touch file.txt
+git annex add file.txt
+git commit -m "Initial commit"
+
+# Needed step for bare repos, as documented in https://git-annex.branchable.com/bare_repositories/
+cd $DIR/client1
+git push share main
+
+###############################################################################
+# Need to do this if there are no commits in the 'client2' and 'share'
+# repositories. Or else, I'll get the following logs:
+#
+# merge: refs/remotes/share/main - not something we can merge
+# merge: refs/remotes/share/synced/main - not something we can merge
+cd $DIR/client2
+git pull share main
+###############################################################################
+
+# Run git-annex assistant for each repository
+cd $DIR/client1 && git annex assistant
+cd $DIR/client2 && git annex assistant
+
+sleep 3;
+cd $DIR/client1
+echo "My first line" >> file.txt
+```
+
+The repo `client1` correctly contains 2 commits representing changes to `file.txt`.
+Additionally, `share` and `client2` contain the same commits that were propagated.
+However, I expected `cat client2/file.txt` to show "My first line", but it shows instead "/annex/objects/SHA256E-s14--42e950c34152a022a2ec82b2201a2287689e39d4d97bfcef67f8940b49d25d4b.txt".
+
+Doing `git status` in `client2` yield:
+
+```
+  file.txt is a git-annex pointer file. Its content is not available in this repository. (Maybe file.txt was copied from another repository?)
+```
+
+but not sure how to solve this.
+
+Running `git annex whereis` yields:
+
+```
+whereis file.txt (0 copies) failed
+whereis: 1 failed
+```
+
+Any ideas what went wrong?
+
+-- [[kolam]]
diff --git a/doc/forum/transfer_bare_repo_setup_problem/comment_1_3b6c15b81c5df09587bc75c5e358b39c._comment b/doc/forum/transfer_bare_repo_setup_problem/comment_1_3b6c15b81c5df09587bc75c5e358b39c._comment
new file mode 100644
index 0000000000..4a29ea77ba
--- /dev/null
+++ b/doc/forum/transfer_bare_repo_setup_problem/comment_1_3b6c15b81c5df09587bc75c5e358b39c._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="kolam"
+ avatar="http://cdn.libravatar.org/avatar/4d2741e5e0b47928bc599b00397b5e59"
+ subject="comment 1"
+ date="2023-12-07T20:08:52Z"
+ content="""
+Seems like I needed to manually run:
+
+```
+cd $DIR/client2
+git annex sync --content
+```
+
+which solves the file not found issue. Wonder why the git-annex assistant didn't just sync again...
+
+Then, `cat file.txt` still gives `/annex/objects/SHA256E-s14--42e950c34152a022a2ec82b2201a2287689e39d4d97bfcef67f8940b49d25d4b.txt`.
+
+I managed to solve it by running `git-annex restage` on client2.
+
+However, after running `git annex whereis`, I get:
+
+```
+whereis file.txt (3 copies) 
+  	1d6bad3e-6a1c-4371-af5f-794bf387480c -- kolam@xxx:~/git-annex-scenarios/share-between-clients/share [share]
+   	87ba86d9-4922-4a4a-8c8d-57c791e0f80e -- kolam@xxx:~/git-annex-scenarios/share-between-clients/client2 [here]
+   	f5b9efb1-e5b3-4573-aa6d-354180193c74 -- kolam@xxx:~/git-annex-scenarios/share-between-clients/client1
+ok
+```
+
+but I noticed that the assistant doesn't drop the file from the \"share\" repo.
+
+Running `git annex drop --auto --from share`, I get:
+
+```
+drop file.txt (from share...) (unsafe) 
+  Could only verify the existence of 1 out of 2 necessary copies
+
+  Maybe add some of these git remotes (git remote add ...):
+  	f5b9efb1-e5b3-4573-aa6d-354180193c74 -- kolam@nelson:~/git-annex-scenarios/share-between-clients/client1
+
+  (Use --force to override this check, or adjust numcopies.)
+failed
+drop: 1 failed
+```
+
+Of course, that also means that if I modify \"$DIR/client2/file.txt\", the assistant doesn't send the updates to client1. I need to do a manual `git annex sync --content` on `client1`.
+Then again, I can't drop the file from \"share\" because of that same error as before.
+"""]]
diff --git a/doc/forum/transfer_bare_repo_setup_problem/comment_2_c011e8fcda61b6ee0067020abbddf61a._comment b/doc/forum/transfer_bare_repo_setup_problem/comment_2_c011e8fcda61b6ee0067020abbddf61a._comment
new file mode 100644
index 0000000000..d25bc6fc92
--- /dev/null
+++ b/doc/forum/transfer_bare_repo_setup_problem/comment_2_c011e8fcda61b6ee0067020abbddf61a._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="kolam"
+ avatar="http://cdn.libravatar.org/avatar/4d2741e5e0b47928bc599b00397b5e59"
+ subject="comment 2"
+ date="2023-12-07T20:16:29Z"
+ content="""
+There's a similar setup page for running your own server with a bare git repo: <https://git-annex.branchable.com/tips/centralized_git_repository_tutorial/on_your_own_server/>
+
+However: 
+
+1. the instructions are not specific for a transfer repo and showcasing the git-annex-drop statement 
+2. out of date as the instructions don't work.
+
+I also found <https://git-annex.branchable.com/forum/How_to_work_with_transfer_repos_manually63/>. 
+But the solution doesn't seem to work here either. 
+Maybe something changed since then.
+
+"""]]
diff --git a/doc/forum/treat_directory_with_multiple_files_as_a_single_item.mdwn b/doc/forum/treat_directory_with_multiple_files_as_a_single_item.mdwn
new file mode 100644
index 0000000000..4adbedb6cc
--- /dev/null
+++ b/doc/forum/treat_directory_with_multiple_files_as_a_single_item.mdwn
@@ -0,0 +1,7 @@
+In my analyses I often have multiple (>10k) generated  small files in a single directory.
+
+
+I would like to store this in git annex, in order to version them and probably even synchronize. The problem is that if a huge number of files is stored inside the repository, the repository itself becomes huge and slow. There are some ways to improve the performance ([[1|tips/Repositories_with_large_number_of_files]], [[2|forum/Handling_a_large_number_of_files]], [[3|forum/__34__git_annex_sync__34___synced_after_8_hours]]), but it doesn't solve the issue completely.
+
+
+I was wondering if it is possible to force git annex to treat a single directory with multiple files as a single item? Probably with abandoning the checksum verification.
diff --git a/doc/forum/treat_directory_with_multiple_files_as_a_single_item/comment_1_89d2819893ae954041d65a5758993be8._comment b/doc/forum/treat_directory_with_multiple_files_as_a_single_item/comment_1_89d2819893ae954041d65a5758993be8._comment
new file mode 100644
index 0000000000..5d13ae708f
--- /dev/null
+++ b/doc/forum/treat_directory_with_multiple_files_as_a_single_item/comment_1_89d2819893ae954041d65a5758993be8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="leavingchicago@c04c893e78d1c4c76cb3e32b5c227cf42bbf7682"
+ nickname="leavingchicago"
+ avatar="http://cdn.libravatar.org/avatar/4ae498d3d6ee558d6b65caa658f72572"
+ subject="comment 1"
+ date="2017-05-19T01:02:57Z"
+ content="""
+Have you thought about (compress/tar)ing the files and then only include the single object in the annex?
+
+Would give you the benefits of deduping any data too.
+"""]]
diff --git a/doc/forum/treat_directory_with_multiple_files_as_a_single_item/comment_2_6889f4695bca77c18efe0000fc491b57._comment b/doc/forum/treat_directory_with_multiple_files_as_a_single_item/comment_2_6889f4695bca77c18efe0000fc491b57._comment
new file mode 100644
index 0000000000..7ca756be6f
--- /dev/null
+++ b/doc/forum/treat_directory_with_multiple_files_as_a_single_item/comment_2_6889f4695bca77c18efe0000fc491b57._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="dav02.git@4d920fe040aa5df86fcd9f4dd57d3fcf85ee5641"
+ nickname="dav02.git"
+ avatar="http://cdn.libravatar.org/avatar/c452f62e60af3c49990973d008ca1b76"
+ subject="(compress/tar)ing the files"
+ date="2017-05-19T12:14:14Z"
+ content="""
+I considered this, but unfortunately in this form I cannot work with files.
+
+There are hacks like archivemount, but they are extremely slow for large number of files and not available on many systems.
+"""]]
diff --git a/doc/forum/treat_directory_with_multiple_files_as_a_single_item/comment_3_61924cf10643a6d2d011899d95b4ae56._comment b/doc/forum/treat_directory_with_multiple_files_as_a_single_item/comment_3_61924cf10643a6d2d011899d95b4ae56._comment
new file mode 100644
index 0000000000..0025126698
--- /dev/null
+++ b/doc/forum/treat_directory_with_multiple_files_as_a_single_item/comment_3_61924cf10643a6d2d011899d95b4ae56._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-05-24T17:08:59Z"
+ content="""
+Well, there's no way I know of to make git treat a directory as one item in
+history. So even if git-annex didn't, it would not help much.
+
+You can check a tar archive into git-annex as a single file, and have hooks
+to handle unpacking it into the directory and repacking the directory back
+to it.
+"""]]
diff --git a/doc/forum/trouble_with_multiple_remotes_syncing_to_gcrypt_based_ssh_repo_.mdwn b/doc/forum/trouble_with_multiple_remotes_syncing_to_gcrypt_based_ssh_repo_.mdwn
new file mode 100644
index 0000000000..95cfe25389
--- /dev/null
+++ b/doc/forum/trouble_with_multiple_remotes_syncing_to_gcrypt_based_ssh_repo_.mdwn
@@ -0,0 +1,7 @@
+Hi, 
+
+Is anyone having difficulties with the assistant and gpg-agent?  Particularly with multiple repos syncing to a crypt backup?
+
+It seems to work for a while and then according to the error logs I can't decrypt the manifest...I'm wondering if there is some sort of locking involved that only lets one repo sync to a gcrypt repo at a time?  I can't think why the gpg-agent would stop providing the key.
+
+I also have a rather horrible time with gpg-agent in general:  I now start each repos git annex assistant individually in the shell (from which I can confirm the gpg-agent is working) rather than launch the web-app direct. 
diff --git a/doc/forum/trouble_with_multiple_remotes_syncing_to_gcrypt_based_ssh_repo_/comment_1_4ad9a6a7cf5678ac0bc6d46a54f64cd3._comment b/doc/forum/trouble_with_multiple_remotes_syncing_to_gcrypt_based_ssh_repo_/comment_1_4ad9a6a7cf5678ac0bc6d46a54f64cd3._comment
new file mode 100644
index 0000000000..3ec0167440
--- /dev/null
+++ b/doc/forum/trouble_with_multiple_remotes_syncing_to_gcrypt_based_ssh_repo_/comment_1_4ad9a6a7cf5678ac0bc6d46a54f64cd3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
+ nickname="Matt"
+ subject="comment 1"
+ date="2014-04-29T10:16:11Z"
+ content="""
+hmmm - a command line based git annex sync always works.  So either the assistant has a separate locking mechanism or the assistant is somehow losing the gpg-agent environment.  Does the assistant restart/respawn itself and lose access to the gpg-agent env?
+
+I'm somewhat clutching at straws here.
+"""]]
diff --git a/doc/forum/trouble_with_multiple_remotes_syncing_to_gcrypt_based_ssh_repo_/comment_2_82dc18ed14879936d04133f248879fb9._comment b/doc/forum/trouble_with_multiple_remotes_syncing_to_gcrypt_based_ssh_repo_/comment_2_82dc18ed14879936d04133f248879fb9._comment
new file mode 100644
index 0000000000..30bc72f549
--- /dev/null
+++ b/doc/forum/trouble_with_multiple_remotes_syncing_to_gcrypt_based_ssh_repo_/comment_2_82dc18ed14879936d04133f248879fb9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
+ nickname="Matt"
+ subject="comment 2"
+ date="2014-04-30T12:25:55Z"
+ content="""
+I see in the comments here a possible explanation...
+
+https://git-annex.branchable.com/bugs/GPG_passphrase_repeated_prompt/
+"""]]
diff --git a/doc/forum/trusted_repositories__58___fatal__58___not_a_git_repo.mdwn b/doc/forum/trusted_repositories__58___fatal__58___not_a_git_repo.mdwn
new file mode 100644
index 0000000000..f94bd3804e
--- /dev/null
+++ b/doc/forum/trusted_repositories__58___fatal__58___not_a_git_repo.mdwn
@@ -0,0 +1,32 @@
+When issuing a `git annex info`, I get:
+
+~~~
+$ git-annex info
+repository mode: indirect
+trusted repositories: fatal: Not a git repository: '/home/micas/Music/.git' fatal: Not a git repository: '/home/micas/Music/.git' 0
+semitrusted repositories: 3
+	00000000-0000-0000-0000-000000000001 -- web
+ 	85f8a5ea-6278-11e2-9978-ebb59e8f37a2 -- here (Music annex backup)
+ 	9aff38f2-6447-11e2-8c89-ef50e6c0ea6c -- backupone (Music annex backupone)
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 174.28 gigabytes (+1 megabyte reserved)
+local annex keys: 5348
+local annex size: 25.62 gigabytes
+annexed files in working tree: 5374
+size of annexed files in working tree: 25.68 gigabytes
+bloom filter size: 16 mebibytes (1.1% full)
+backend usage: 
+	SHA256: 10692
+	SHA256E: 30
+~~~
+
+The troubling part (I think) is `trusted repositories: fatal: Not a git repository: '/home/micas/Music/.git' fatal: Not a git repository: '/home/micas/Music/.git' 0`
+
+Is there a command I can use to show all the uuid of known remotes? I thought I had marked all remotes pointing to /home/micas/Music/.git as `dead`
+
+Is there another reason for the output? How can I get trusted repos back to 0?
+
+**EDIT:**
+
+I removed the folder (was not a git repo at the time of the error) `/home/micas/Music` and the error went away.
diff --git a/doc/forum/trusted_repositories__58___fatal__58___not_a_git_repo/comment_1_0a755a4a281c3bd130722093c8ddd080._comment b/doc/forum/trusted_repositories__58___fatal__58___not_a_git_repo/comment_1_0a755a4a281c3bd130722093c8ddd080._comment
new file mode 100644
index 0000000000..133a80e14b
--- /dev/null
+++ b/doc/forum/trusted_repositories__58___fatal__58___not_a_git_repo/comment_1_0a755a4a281c3bd130722093c8ddd080._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2013-12-29T20:10:14Z"
+ content="""
+Yeah, git-annex will skip a repository if its directory doesn't exist, but if the directory exists, it expects it to be a git repository, and will run git commands that use it (to get its config specifically).
+
+The ugly message is doing just what it should; letting you know you have a problem. 
+"""]]
diff --git a/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn b/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn
new file mode 100644
index 0000000000..ca04e442ce
--- /dev/null
+++ b/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn
@@ -0,0 +1,32 @@
+I am attempting to set up automatic two-way synchronization between my laptop and a server via ssh by running assistant on both machines. I want to have both machines be non-bare and unlocked.
+
+On the rhel server:
+
+    $ mkdir ~/annex
+    $ cd ~/annex
+    $ git init
+    $ git annex init u --version=6
+    $ echo This is test file 1. >testfile1.txt
+    $ git annex add testfile1.txt
+    $ git annex sync
+    $ git remote add ml2 ssh://laptop/Users/username/annex
+    $ git annex adjust --unlock
+    $ git annex wanted . standard
+    $ git annex group . client
+
+On my mac laptop:
+
+    $ cd ~/
+    $ git clone ssh://server/home/username/annex
+    $ cd annex
+    $ git annex init ml2 --version=6
+    $ git annex sync
+    $ git annex adjust --unlock
+    $ git annex wanted . standard
+    $ git annex group . client
+
+Everything seems to work when I manually sync. But when I run
+
+    $ git annex assistant
+
+on both machines, I only get one-way automatic synchronization. Changes on the laptop are immediately propagated to the server. But changes on the server do not show up on the laptop until I manually sync. What am I doing wrong?
diff --git a/doc/forum/two-way_assistant_sync_with_ssh_special_remote/comment_1_d42def5dfc1cf814fdb07f7cf808bb12._comment b/doc/forum/two-way_assistant_sync_with_ssh_special_remote/comment_1_d42def5dfc1cf814fdb07f7cf808bb12._comment
new file mode 100644
index 0000000000..a9db035800
--- /dev/null
+++ b/doc/forum/two-way_assistant_sync_with_ssh_special_remote/comment_1_d42def5dfc1cf814fdb07f7cf808bb12._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="binx"
+ avatar="http://cdn.libravatar.org/avatar/1c2b6fe37ed500f4b72c105e42e81ba9"
+ subject="comment 1"
+ date="2016-12-16T13:57:41Z"
+ content="""
+I updated git-annex on the server. I now *sometimes* get automatic two-way syncing to happen with assistant. But it is not really consistent or reliable. One thing that seems to consistently fail is when I drag and drop a file into the annex folder on the mac. When I drag filename.txt into ~/annex, and then run git annex sync, I get the message:
+
+    $ git annex sync
+    commit  
+    On branch adjusted/master(unlocked)
+    Your branch is up-to-date with 'origin/adjusted/master(unlocked)'.
+    Untracked files:
+    	.DS_Store
+    	filename.txt
+    
+    nothing added to commit but untracked files present
+    ok
+    pull u 
+    ok
+    pull origin 
+    ok
+
+"""]]
diff --git a/doc/forum/two_lines_back_to_remote__63__.mdwn b/doc/forum/two_lines_back_to_remote__63__.mdwn
new file mode 100644
index 0000000000..3ac54134ef
--- /dev/null
+++ b/doc/forum/two_lines_back_to_remote__63__.mdwn
@@ -0,0 +1,10 @@
+`git annex map` generates a diagram roughly like this:
+
+    +------+    +-------+
+    |laptop| -> |usbdisk|
+    |      | <- |       |
+    |      | <- |       |
+    +------+    +-------+
+
+Why are there *two* lines back from the disk to the laptop?
+
diff --git a/doc/forum/two_lines_back_to_remote__63__/comment_1_064d786c5550e4470440717994e62051._comment b/doc/forum/two_lines_back_to_remote__63__/comment_1_064d786c5550e4470440717994e62051._comment
new file mode 100644
index 0000000000..bb551908b6
--- /dev/null
+++ b/doc/forum/two_lines_back_to_remote__63__/comment_1_064d786c5550e4470440717994e62051._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica"
+ subject="look at all your remotes"
+ date="2015-03-29T20:39:00Z"
+ content="""
+Have a look at all your remotes, you can reference the same repo with more than one remote name.
+"""]]
diff --git a/doc/forum/two_lines_back_to_remote__63__/comment_2_b1debe6f63e811c79ad97b9e38dd2935._comment b/doc/forum/two_lines_back_to_remote__63__/comment_2_b1debe6f63e811c79ad97b9e38dd2935._comment
new file mode 100644
index 0000000000..1bd4329393
--- /dev/null
+++ b/doc/forum/two_lines_back_to_remote__63__/comment_2_b1debe6f63e811c79ad97b9e38dd2935._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-04-06T16:59:07Z"
+ content="""
+
+"""]]
diff --git a/doc/forum/two_lines_back_to_remote__63__/comment_3_70ee40b99e06c4f64d3e2e4433c8b4ba._comment b/doc/forum/two_lines_back_to_remote__63__/comment_3_70ee40b99e06c4f64d3e2e4433c8b4ba._comment
new file mode 100644
index 0000000000..7f7389b8b8
--- /dev/null
+++ b/doc/forum/two_lines_back_to_remote__63__/comment_3_70ee40b99e06c4f64d3e2e4433c8b4ba._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-06T16:59:10Z"
+ content="""
+The map shows one line for each git remote. So if you have two git remotes
+configured that are both pointing at the laptop, that'll be the result.
+For example, you might have both "origin" and "laptop" remotes pointing to
+it, possibly via two different urls.
+
+There's nothing bad about this.
+"""]]
diff --git a/doc/forum/ui.mdwn b/doc/forum/ui.mdwn
new file mode 100644
index 0000000000..2ef8841a9e
--- /dev/null
+++ b/doc/forum/ui.mdwn
@@ -0,0 +1,11 @@
+I just briefly tried git-annex. It's an interesting concept.
+
+My main frustration so far: I find it difficult to visualise and use the annex. Shell script contortions can obviously show you anything, but I don't have the ready knowledge to compose them. It would be nice to have some more user-friendly commands or even a GUI.
+
+'annex whereis' is fine for one file, but unweildly for many (e.g. a directory whose contents are always together, never divided between repositories). Is it possible to treat a given directory and all its contents as a single object?
+
+It is not clear what files are immediately available. Sometimes you don't care about annexed files that aren't stored in the current repository. Might it be nice to temporarily remove or hide symlinks for files that are not here right now? Then you could treat the repository more like a normal file heirarchy. Or how about something like 'git annex ls' to show only currently available files?
+
+assistant and sharebox fs sound like great basic synch options, but it would be really cool to have a fuse fs somewhere between raw git-annex and assistant. Putting a file in the directory would trigger git-annex to add it and sync. rm <file> on that new file would not work by default because it's the only copy. rm --annex to get rid of the file from all repos. mv/cp <file> <remote> to transfer between repos. ls to show only the files that are here now, ls --annex to display complete information in a clear way (well-formatted, colorized). Something like that.
+
+This has just been a random brain dump from a new user, hopefully it made some sense.
diff --git a/doc/forum/ui/comment_1_f3e3446b05d6b573e29e6cad300fb635._comment b/doc/forum/ui/comment_1_f3e3446b05d6b573e29e6cad300fb635._comment
new file mode 100644
index 0000000000..84f30c5ea7
--- /dev/null
+++ b/doc/forum/ui/comment_1_f3e3446b05d6b573e29e6cad300fb635._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.140"
+ subject="comment 1"
+ date="2013-07-20T19:51:19Z"
+ content="""
+It's pretty easy to configure ls to show broken symlinks in a different color. Run dircolors, and alias ls='ls --color==auto'. Then you can see which files are not there at a glance.
+
+The Linux file manager's I've tried (nautilus and thunar) also shows which files are present; you get a X on the icon of annexed files that are not present.
+"""]]
diff --git a/doc/forum/ui/comment_2_b493ee97eb2378e72c12f3d137109580._comment b/doc/forum/ui/comment_2_b493ee97eb2378e72c12f3d137109580._comment
new file mode 100644
index 0000000000..ee79958832
--- /dev/null
+++ b/doc/forum/ui/comment_2_b493ee97eb2378e72c12f3d137109580._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://mylesenglish.myopenid.com/"
+ ip="217.39.94.195"
+ subject="comment 2"
+ date="2013-09-16T19:21:31Z"
+ content="""
+This shell function behaves more like ls and shows the files that are present:
+
+    ga-ls () {
+      CWD=`pwd`
+      cd ${1:-.} && git annex find | cut -d / -f 1 | uniq
+      cd ${CWD}
+    }
+
+"""]]
diff --git a/doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote.mdwn b/doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote.mdwn
new file mode 100644
index 0000000000..e6936e9e7b
--- /dev/null
+++ b/doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote.mdwn
@@ -0,0 +1,28 @@
+I am following the guide on [Fully encrypted git repositories with gcrypt](https://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt) to restore data to a new computer.
+
+On my old computer, I was using a removable hard drive with a bare repo as my remote. Before migrating, I moved all contents to this repository.
+
+I follow the relevant steps exactly:
+
+```
+git clone gcrypt::/media/me/path_to_repo clone
+cd clone
+git annex enableremote path_to_repo gitrepo=/media/me/path_to_repo
+```
+
+Now `git annex sync` reports success for both `origin` and `path_to_repo`. But `git annex sync --content` fails with:
+
+    Unable to access these remotes: path_to_repo
+  
+    Try making some of these repositories available: 
+  	  a3f8a46a-60fe-58e2-901b-2c093bcc22d3 -- [path_to_repo]
+
+The sync with `origin` works, but as soon as it starts trying to get the content it reports the above.
+
+`git annex get --from path_to_repo` reports no output.
+
+Why does it say this when the repo is clearly available, seeing as I can do git annex sync? (at least -- as far as I can understand it ...)
+
+I'm sorry I can't provide more detailed/to the point information. I am very befuddled by this behavior. Trying to understand how git annex works, I wonder if there is some information in my old 'checkout' repo which git annex needs to be able to recognize which repo is where? But my new clone has the correct repo uuid under the entry for `path_to_repo` in `.git/config`, so I don't understand why it doesn't know about it.
+
+thanks!
diff --git a/doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote/comment_1_cbcc4be05aa6d8f030d5ab0dc46858f4._comment b/doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote/comment_1_cbcc4be05aa6d8f030d5ab0dc46858f4._comment
new file mode 100644
index 0000000000..527fce9ac5
--- /dev/null
+++ b/doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote/comment_1_cbcc4be05aa6d8f030d5ab0dc46858f4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="fasthans@87884c78197fe1a25ac25ae7fa1d930c147e9592"
+ nickname="fasthans"
+ avatar="http://cdn.libravatar.org/avatar/6d89ddec3053d8df7e57cf2f28c8cdcd"
+ subject="how does git annex think about remote locations?"
+ date="2019-10-16T04:34:14Z"
+ content="""
+I'm really trying to understand how git annex is thinking about remote locations. If I add more remotes with the same repository URL, git annex does not pick up on them even though it seems to be syncing the branches from them. Whenever I try to get data, it complains that the original remote is unavailable. What is git-annex's logic about locating or identifying remotes? Does it have to do with the uuid?
+
+If I go into my backed up original checkout repo and try to get data, it also complains about not being able to find the original remote. They backup and the original bare repo both happen to be on the same hard drive, and they can talk to each other to sync branches. The url did change: first the drive was on 'Elements1' and now on 'Elements' but to my mind, if git can clone the repo, what is git-annex expecting differently?
+"""]]
diff --git a/doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote/comment_2_3623a37d918d08e8681276206137f5af._comment b/doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote/comment_2_3623a37d918d08e8681276206137f5af._comment
new file mode 100644
index 0000000000..b9f1b0c66c
--- /dev/null
+++ b/doc/forum/unable_to_access_remotes_when_cloning_a_gcrypt_remote/comment_2_3623a37d918d08e8681276206137f5af._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-10-21T18:36:16Z"
+ content="""
+I tried following the process given in that tip, and it works as it's
+supposed to.
+
+The easiest way to reproduce the error message you've reported is:
+
+Is "path_to_repo" a unix path, with slashes in it?
+It's hard for me to understand if you've obfuscated that,
+or if you literally used the string "path_to_repo" there.
+
+A complete un-edited transcript would clarify things a lot.
+
+A repository url tells git or git-annex *where* to access a repository.
+A repository's uuid tells git-annex *which* repository it is.
+"""]]
diff --git a/doc/forum/unable_to_clone_annex_repo_in_windows.mdwn b/doc/forum/unable_to_clone_annex_repo_in_windows.mdwn
new file mode 100644
index 0000000000..6e58c7af8a
--- /dev/null
+++ b/doc/forum/unable_to_clone_annex_repo_in_windows.mdwn
@@ -0,0 +1,29 @@
+Dear all,
+        I successfuly cloned my annex repo (hosted on gitlab.com) on my windows box (win 7, 64bits), and my data is on an exFat partition. 
+git annex version is 
+----------------
+git-annex version: 6.20160126-g2336107
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload) WebDAV ConcurrentOutput TorrentParser Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+-------------
+However, when I try to initialize annex on the newly cloned repo fails with the following error:
+
+$ git annex init "repo_win"
+init repo_win
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Enabling direct mode.
+
+git-annex: .git\annex\objects\c89\57a\SHA256E-s1339658--e7cfebb4ac9c81a6a060506c537b55aed9f13bd02d861d2b341fb8a79ad6e046.png\: openTempFile: does not exist (No such file or directory)
+failed
+git-annex: init: 1 failed
+
+any hints about this?
+Thanks in advance.
+Best regards,
+             Juan
diff --git a/doc/forum/unable_to_clone_annex_repo_in_windows/comment_1_588af0e0b655966c2d344f3f4b4d2e5f._comment b/doc/forum/unable_to_clone_annex_repo_in_windows/comment_1_588af0e0b655966c2d344f3f4b4d2e5f._comment
new file mode 100644
index 0000000000..b7ab2df61f
--- /dev/null
+++ b/doc/forum/unable_to_clone_annex_repo_in_windows/comment_1_588af0e0b655966c2d344f3f4b4d2e5f._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-03T16:55:42Z"
+ content="""
+That sounds like this bug:
+<http://git-annex.branchable.com/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/>
+
+Windows has some path length issues that come up especially when using
+git-annex in a deeply nested directory tree. Try cloning the repository to
+somewhere like c:\\ and see if that works around the problem.
+
+Although, the path it's complaining about is relative and only 113
+characters long, which should not be long enough to trigger that problem.
+So, this could be some other problem. I tried cloning a git-annex repo
+and git annex init did not fail like this, so any information you can
+provide to help me reproduce the problem would be good.
+"""]]
diff --git a/doc/forum/unable_to_clone_annex_repo_in_windows/comment_2_e4fcc8329b2deb058b7368ce1c226a3e._comment b/doc/forum/unable_to_clone_annex_repo_in_windows/comment_2_e4fcc8329b2deb058b7368ce1c226a3e._comment
new file mode 100644
index 0000000000..828906df7e
--- /dev/null
+++ b/doc/forum/unable_to_clone_annex_repo_in_windows/comment_2_e4fcc8329b2deb058b7368ce1c226a3e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="drunken_sapo"
+ subject="comment 2"
+ date="2016-05-13T18:12:24Z"
+ content="""
+Hey Joey,
+        Thanks for the answer, I'm trying to reproduce it on a test repo, but I'm having problems with my ssh-key. As soon as I fix it I'll be back with the results.
+Thanks for your time and effort.
+Best,
+         Juan
+"""]]
diff --git a/doc/forum/unable_to_clone_annex_repo_in_windows/comment_3_20aa8de2513fdb6b19a4b24f20983f0a._comment b/doc/forum/unable_to_clone_annex_repo_in_windows/comment_3_20aa8de2513fdb6b19a4b24f20983f0a._comment
new file mode 100644
index 0000000000..e9e462b561
--- /dev/null
+++ b/doc/forum/unable_to_clone_annex_repo_in_windows/comment_3_20aa8de2513fdb6b19a4b24f20983f0a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="drunken_sapo"
+ subject="The problem was path length"
+ date="2016-05-14T13:11:35Z"
+ content="""
+After fixing my ssh key problem I was able to test it appropiately.
+The path to the .git directory of my repo is 41 characters long (/d/juan/develop/git/xxxxxx_xxxxx_xxxxxxxx), if we add the offending file name: .git\annex\objects\fca\de3\SHA256E-s1312136--a79e30c5121f7843f023abbd36b211a245385b952926760d55a07baf8da1b24d.png\
+which is 114 characters long, it adds up to 155 characters.
+Moving the repo to /d/xxxxxx_xxxxx_xxxxxxxx solved the problem.
+However, I need it to be on that path, because some other projects use this on a relative path.
+Is there any way to circumvent this issue?
+"""]]
diff --git a/doc/forum/unannex_--fast_+_uninit_leaves_files_in_.git__47__annex__47__objects__63__.mdwn b/doc/forum/unannex_--fast_+_uninit_leaves_files_in_.git__47__annex__47__objects__63__.mdwn
new file mode 100644
index 0000000000..c746e3d6d9
--- /dev/null
+++ b/doc/forum/unannex_--fast_+_uninit_leaves_files_in_.git__47__annex__47__objects__63__.mdwn
@@ -0,0 +1,47 @@
+I have been trying to uninit a very large directory and ran into problems.
+
+`git annex unannex` seems to be completely infeasible because of how long it takes, also it seemed to grow the directory enormously, probably because it copies large files and then waits to delete them?
+
+I tried unannexing with the following commands instead:
+
+    `git annex get --from=backup`
+    `git annex unannex --fast`
+    `git annex uninit`
+
+This does what it is supposed to it seems, it hard links all copies of files. However, the unint step gives the following message:
+
+    git-annex: Not fully uninitialized
+    Some annexed data is still left in /science/carlo/GR_Coverage_Manuscript_Revisions_140616/.git/annex/objects/
+    This may include deleted files, or old versions of modified files.
+
+    If you don't care about preserving the data, just delete the
+    directory.
+
+    Or, you can move it to another location, in case it turns out
+    something in there is important.
+
+    Or, you can run `git annex unused` followed by `git annex dropunused`
+    to remove data that is not used by any tag or branch, which might
+    take care of all the data.
+
+    Then run `git annex uninit` again to finish.
+
+However, running `git annex unused` returns nothing.
+
+When I run `du -l -h --max-depth=1` I get the following output:
+
+    646G ./01-Collate_New_Species_Data
+    6.3G ./02-Prep_Annotations
+    1.8T ./03-Map_Riboprofiling_Data
+    111G ./04-Generate_Preprocessed_Files
+    94G  ./05-Det_Codon_Specfic_Occupancy
+    3.6T ./.git
+    6.2T .
+
+The .git/annex/objects directory remains 3.5TB in size, while the root directory, minus the contents of .git is only 2.7TB.
+
+I want to delete the .git folder to free up space, but I am very nervous now, because it looks like there is extra data in git annex that isn't present in the main directory. I don't want that to be lost, that would be a complete disaster.
+
+I tried the exact same process on a test directory, and it seemed to work completely, but losing this data would be an absolute disaster, so I don't want to risk it.
+
+Any thoughts?
diff --git a/doc/forum/unannex_--fast_+_uninit_leaves_files_in_.git__47__annex__47__objects__63__/comment_1_4aaf93801119b36a01e452c7bb0fc7e9._comment b/doc/forum/unannex_--fast_+_uninit_leaves_files_in_.git__47__annex__47__objects__63__/comment_1_4aaf93801119b36a01e452c7bb0fc7e9._comment
new file mode 100644
index 0000000000..86cd83d3a7
--- /dev/null
+++ b/doc/forum/unannex_--fast_+_uninit_leaves_files_in_.git__47__annex__47__objects__63__/comment_1_4aaf93801119b36a01e452c7bb0fc7e9._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-20T15:33:02Z"
+ content="""
+Well, are there any files in your repository (outside .git) that
+are still symlinks to content in .git? If not, you know that
+every file in the repository's working tree has been unannexed
+ok.
+
+The remaining files in .git/annex/objects are not unused, so some branch or tag
+must refer to those files.
+
+You might try running `git log --stat -S'KEY'`
+where KEY is the basename name of one of the files in .git/annex/objects.
+This will find commits to the repo that refer to that object, so you'll
+know where it was used and what filename corresponded to it.
+"""]]
diff --git a/doc/forum/unannex_alternatives.mdwn b/doc/forum/unannex_alternatives.mdwn
new file mode 100644
index 0000000000..efd05838e6
--- /dev/null
+++ b/doc/forum/unannex_alternatives.mdwn
@@ -0,0 +1,9 @@
+what is the work flow to get a file that is in git-annex out of there and into git? (current situation: `git-annex add`ed a bunch of pictures, later found make files in there which i'd rather have in git for proper source code control)
+
+the most intuitive thing to do is `git unannex`, which at first seemed to do the right thing, but when committing there came the hook and everything was back to where it was before.
+
+i could disable the hook as a workaround, but that doesn't smell like a good work flow.
+
+the [[man page|git-annex]] does warn that `unannex` is only supposed to be used against unintentional `git annex add`s (probably meaning that it should be used before something is committed), but the alternatives it suggests (`git rm` and `git annex drop`) don't to what i want to do.
+
+am i missing something or is there really no work flow for this? --[[chrysn]]
diff --git a/doc/forum/unannex_alternatives/comment_1_dcd4cd41280b41512bbdffafaf307993._comment b/doc/forum/unannex_alternatives/comment_1_dcd4cd41280b41512bbdffafaf307993._comment
new file mode 100644
index 0000000000..7f278d2bc9
--- /dev/null
+++ b/doc/forum/unannex_alternatives/comment_1_dcd4cd41280b41512bbdffafaf307993._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-02-02T00:39:10Z"
+ content="""
+Git-annex's commit hook does not prevent unannex being used. The file you unannex will not be checked into git anymore and will be a regular file again, not a git-annex symlink. 
+
+For example, here's a transcript:
+
+<pre>
+joey@gnu:~/tmp>mkdir demo
+joey@gnu:~/tmp>cd demo
+joey@gnu:~/tmp/demo>git init
+Initialized empty Git repository in /home/joey/tmp/demo/.git/
+joey@gnu:~/tmp/demo>git annex init demo
+init demo ok
+joey@gnu:~/tmp/demo>echo hi > file
+joey@gnu:~/tmp/demo>git annex add file 
+add file ok
+(Recording state in git...)
+joey@gnu:~/tmp/demo>git commit -m add
+[master 64cf267] add
+ 2 files changed, 2 insertions(+), 0 deletions(-)
+ create mode 100644 .git-annex/WORM:1296607093:3:file.log
+ create mode 120000 file
+joey@gnu:~/tmp/demo>git annex unannex file
+unannex file ok
+(Recording state in git...)
+joey@gnu:~/tmp/demo>ls -l file
+-rw-r--r-- 1 joey joey 3 Feb  1 20:38 file
+joey@gnu:~/tmp/demo>git commit
+[master 78a09cc] unannex
+ 2 files changed, 1 insertions(+), 2 deletions(-)
+ delete mode 120000 file
+joey@gnu:~/tmp/demo>ls -l file
+-rw-r--r-- 1 joey joey 3 Feb  1 20:38 file
+joey@gnu:~/tmp/demo>git status
+# On branch master
+# Untracked files:
+#   (use \"git add <file>...\" to include in what will be committed)
+#
+#	file
+nothing added to commit but untracked files present (use \"git add\" to track)
+</pre>
+"""]]
diff --git a/doc/forum/unannex_alternatives/comment_2_58a72a9fe0f58c7af0b4d7927a2dd21d._comment b/doc/forum/unannex_alternatives/comment_2_58a72a9fe0f58c7af0b4d7927a2dd21d._comment
new file mode 100644
index 0000000000..91ddadf8c6
--- /dev/null
+++ b/doc/forum/unannex_alternatives/comment_2_58a72a9fe0f58c7af0b4d7927a2dd21d._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-02-02T00:41:24Z"
+ content="""
+And following on to my transcript, you can then add the file to git in the regular git way, and it works fine:
+
+<pre>
+joey@gnu:~/tmp/demo>git add file
+joey@gnu:~/tmp/demo>git commit
+[master 225ffc0] added as regular git file, not in annex
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+ create mode 100644 file
+joey@gnu:~/tmp/demo>ls -l file
+-rw-r--r-- 1 joey joey 3 Feb  1 20:38 file
+joey@gnu:~/tmp/demo>git log file
+commit 225ffc048f5af7c0466b3b1fe549a6d5e9a9e9fe
+Author: Joey Hess <joey@kitenet.net>
+Date:   Tue Feb 1 20:43:13 2011 -0400
+
+    added as regular git file, not in annex
+
+commit 78a09cc791b875c3b859ca9401e5b6472bf19d08
+Author: Joey Hess <joey@kitenet.net>
+Date:   Tue Feb 1 20:38:30 2011 -0400
+
+    unannex
+
+commit 64cf267734adae05c020d9fd4d5a7ff7c64390db
+Author: Joey Hess <joey@kitenet.net>
+Date:   Tue Feb 1 20:38:18 2011 -0400
+
+    add
+</pre>
+"""]]
diff --git a/doc/forum/unannex_alternatives/comment_3_b1687fc8f9e7744327bbeb6f0635d1cd._comment b/doc/forum/unannex_alternatives/comment_3_b1687fc8f9e7744327bbeb6f0635d1cd._comment
new file mode 100644
index 0000000000..9f3223578b
--- /dev/null
+++ b/doc/forum/unannex_alternatives/comment_3_b1687fc8f9e7744327bbeb6f0635d1cd._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-02-02T00:46:00Z"
+ content="""
+Sorry for all the followups, but I see now that if you unannex, then add the file to git normally, and commit, the hook *does* misbehave.
+
+This seems to be a bug. git-annex's hook thinks that you have used git annex unlock (or \"git annex edit\") on the file and are now committing a changed version, and the right thing to do there is to add the new content to the annex and update the symlink accordingly. I'll track this bug over at [[bugs/unannex_vs_unlock_hook_confusion]].
+
+So, committing after unannex, and before checking the file into git in the
+usual way, is a workaround. But only if you do a "git commit" to commit
+staged changes.
+
+Anyway, this confusing point is fixed in git now!
+"""]]
diff --git a/doc/forum/unknown_response_from_git_cat-file.mdwn b/doc/forum/unknown_response_from_git_cat-file.mdwn
new file mode 100644
index 0000000000..e4c559815f
--- /dev/null
+++ b/doc/forum/unknown_response_from_git_cat-file.mdwn
@@ -0,0 +1,8 @@
+Hi,
+
+when running git annex add in my direct mode repository, since a few days ago I only get:
+
+$ git annex add
+git-annex: unknown response from git cat-file (":./Archiv/Someone missing",:./Archiv/Someone Like You Cover-fCvjvEGkTu4.flv)
+
+The :./Archiv/Someone missing part strikes me odd because it so much looks like broken shell meta-character escaping in git-annex, but I doubt that because it stopped working just suddenly.
diff --git a/doc/forum/unknown_response_from_git_cat-file/comment_1_f26ba569e715fe69b6de3093930362ee._comment b/doc/forum/unknown_response_from_git_cat-file/comment_1_f26ba569e715fe69b6de3093930362ee._comment
new file mode 100644
index 0000000000..0ddef17af4
--- /dev/null
+++ b/doc/forum/unknown_response_from_git_cat-file/comment_1_f26ba569e715fe69b6de3093930362ee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 1"
+ date="2013-08-07T16:34:18Z"
+ content="""
+This is a bug in the 1.8.4 pre-release version of git. It will be fixed in the 1.8.4 release or another pre-release. git-annex version 4.20130802 has a workaround for this problem.
+"""]]
diff --git a/doc/forum/unknown_response_from_git_cat-file/comment_2_bba450e83609225c161b4fec1e006f8a._comment b/doc/forum/unknown_response_from_git_cat-file/comment_2_bba450e83609225c161b4fec1e006f8a._comment
new file mode 100644
index 0000000000..07d1d4de30
--- /dev/null
+++ b/doc/forum/unknown_response_from_git_cat-file/comment_2_bba450e83609225c161b4fec1e006f8a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNvX8PQVP5sLzQ78sKpB6VeH3Fu8HvZ5g"
+ nickname="Jeff"
+ subject="comment 2"
+ date="2015-04-01T01:08:53Z"
+ content="""
+I'm getting a similar error on git-annex version: 5.20141203, but I'm not in direct mode. It happens when I call 'git annex unused'.
+"""]]
diff --git a/doc/forum/unknown_response_from_git_cat-file/comment_3_8e0458e86764242e9e35940b4db302b7._comment b/doc/forum/unknown_response_from_git_cat-file/comment_3_8e0458e86764242e9e35940b4db302b7._comment
new file mode 100644
index 0000000000..e03348a423
--- /dev/null
+++ b/doc/forum/unknown_response_from_git_cat-file/comment_3_8e0458e86764242e9e35940b4db302b7._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="GregGrossmeier"
+ avatar="http://cdn.libravatar.org/avatar/66db9e436738991619a59e8ab8061e64"
+ subject="Recurring?"
+ date="2017-01-02T21:13:47Z"
+ content="""
+Still getting this myself. First I've ran into it (a few weeks ago, but I hadn't used these repos recently).
+
+	greg@x230 (git)-[master] ~/Photos % git-annex add .               
+	add 2016/10/16/2016-10-16 07.47.52.jpg git-annex: unknown response from git cat-file (\"HEAD:./2016/10/16/2016-10-16 07.47.52.jpg missing\",Ref \"HEAD:./2016/10/16/2016-10-16 07.47.52.jpg\")
+	greg@x230 (git)-[master] ~/Photos % apt-cache policy git-annex git
+	zsh: correct 'git' to '.git'? [N/y/a/e] n
+	git-annex:
+	  Installed: 6.20161012-1
+	  Candidate: 6.20161012-1
+	  Version table:
+	 *** 6.20161012-1 500
+	        500 http://httpredir.debian.org/debian testing/main amd64 Packages
+	        100 /var/lib/dpkg/status
+	     5.20141125 500
+	        500 http://httpredir.debian.org/debian stable/main amd64 Packages
+	git:
+	  Installed: 1:2.11.0-1
+	  Candidate: 1:2.11.0-1
+	  Version table:
+	 *** 1:2.11.0-1 500
+	        500 http://httpredir.debian.org/debian testing/main amd64 Packages
+	        100 /var/lib/dpkg/status
+	     1:2.1.4-2.1+deb8u2 500
+	        500 http://httpredir.debian.org/debian stable/main amd64 Packages
+	
+"""]]
diff --git a/doc/forum/unknown_response_from_git_cat-file/comment_4_275fcf1e6643cb247f8ed5afc4c69e56._comment b/doc/forum/unknown_response_from_git_cat-file/comment_4_275fcf1e6643cb247f8ed5afc4c69e56._comment
new file mode 100644
index 0000000000..ad6731ab44
--- /dev/null
+++ b/doc/forum/unknown_response_from_git_cat-file/comment_4_275fcf1e6643cb247f8ed5afc4c69e56._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="fossil"
+ avatar="http://cdn.libravatar.org/avatar/951f4f4e1dca2ebe880ddb392c2d3e73"
+ subject="comment 4"
+ date="2017-01-08T15:57:42Z"
+ content="""
+This is a bug, introduced in [commit 34530e59](https://github.com/joeyh/git-annex/commit/34530e59) (release 6.20161012) and fixed in [commit b530e432](https://github.com/joeyh/git-annex/commit/b530e432) (release 6.20161031).
+
+* [git-annex chokes on filenames including spaces](https://git-annex.branchable.com/bugs/git-annex_chokes_on_filenames_including_spaces/)
+* [Single space in file name causes git annex add to fail](https://git-annex.branchable.com/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/)
+
+It happens only when the filename contains a single space, so a workaround is to first add a filename without any spaces, and then rename it:
+
+    fn=\"foo bar.txt\"; cp \"$fn\" tmp && git annex add tmp && git mv -f tmp \"$fn\"
+"""]]
diff --git a/doc/forum/unlock__47__lock_always_gets_me.mdwn b/doc/forum/unlock__47__lock_always_gets_me.mdwn
new file mode 100644
index 0000000000..0891eed0e5
--- /dev/null
+++ b/doc/forum/unlock__47__lock_always_gets_me.mdwn
@@ -0,0 +1,11 @@
+Several times now I've done something like:
+
+    $ git annex unlock movie.avi
+    $ mv /tmp/fixed.avi movie.avi
+    $ git annex lock movie.avi
+
+Oops, I just lost my fixed.avi!  That really feels like the right sequence of operations to me, so I'm always surprised when I make that mistake.  I would like to see the current `lock` renamed to something like `undo-unlock`, or have the behavior changed to be the same as `add`, or maybe warn and require a `--force` when the file has been changed.
+
+If changing current behavior is undesirable, maybe `unlock` could just print a reminder that `git annex add` is the correct next step after making changes?
+
+Failing that, I suppose I could slowly start to learn from my mistakes.
diff --git a/doc/forum/unlock__47__lock_always_gets_me/comment_1_dee73a7ea3e1a5154601adb59782831f._comment b/doc/forum/unlock__47__lock_always_gets_me/comment_1_dee73a7ea3e1a5154601adb59782831f._comment
new file mode 100644
index 0000000000..c37561665f
--- /dev/null
+++ b/doc/forum/unlock__47__lock_always_gets_me/comment_1_dee73a7ea3e1a5154601adb59782831f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-01-07T17:15:31Z"
+ content="""
+Well, lock could check for modifications and require --force to lose them. But the check could be expensive for large files.
+
+But `git annex lock` is just a convenient way to run `git checkout`. And running `git checkout` or `git reset --hard` will lose your uncommitted file the same way obviously. 
+
+Perhaps the best fix would be to get rid of `lock` entirely, and let the user use the underlying git commands same as they would to drop modifications to other files. It would then also make sense to remove `unlock`, leaving only `edit`.
+"""]]
diff --git a/doc/forum/unlock__47__lock_always_gets_me/comment_2_f89b4349dde840c355a3bc28908decdf._comment b/doc/forum/unlock__47__lock_always_gets_me/comment_2_f89b4349dde840c355a3bc28908decdf._comment
new file mode 100644
index 0000000000..f732c87da0
--- /dev/null
+++ b/doc/forum/unlock__47__lock_always_gets_me/comment_2_f89b4349dde840c355a3bc28908decdf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnRai_qFYPVvEgC6i1nlM1bh-C__jbhqS0"
+ nickname="Matthew"
+ subject="comment 2"
+ date="2013-09-07T12:26:46Z"
+ content="""
+I too was totally flummoxed by this.
+"""]]
diff --git a/doc/forum/unlock__47__lock_always_gets_me/comment_3_acbab7b75726d34dccb5c9dab7b3e728._comment b/doc/forum/unlock__47__lock_always_gets_me/comment_3_acbab7b75726d34dccb5c9dab7b3e728._comment
new file mode 100644
index 0000000000..835222f190
--- /dev/null
+++ b/doc/forum/unlock__47__lock_always_gets_me/comment_3_acbab7b75726d34dccb5c9dab7b3e728._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://olivier.berger.myopenid.com/"
+ nickname="obergix"
+ subject="It seems we've been heard"
+ date="2013-12-07T15:13:10Z"
+ content="""
+https://github.com/joeyh/git-annex/commit/cde099fe80cd2bc6345496c9266c41baf46c1976 : lock: Require --force. 
+"""]]
diff --git a/doc/forum/unrelated_repositories_sync.mdwn b/doc/forum/unrelated_repositories_sync.mdwn
new file mode 100644
index 0000000000..030fb380d7
--- /dev/null
+++ b/doc/forum/unrelated_repositories_sync.mdwn
@@ -0,0 +1,15 @@
+I have no idea how to search for this here, so I'll just go the "lazy web" approach and just ask.
+
+Say I have two "conference" repos. One is the famous [conference procedings](https://github.com/RichiH/conference_proceedings) repo, and another one is a totally unrelated repo of local conferences that are not of world-wide significance. Let's call this second repo `presentations`.
+
+I would like to have my videos of both repos in a single repo.
+
+Can I add the `conference procedings` repo as a git remote to the `presentations` repo and have it do the right thing?
+
+In fact, I'm not even sure what the right thing would be here, I guess that's the first thing I would like to clear up. But I would like to do things like what the new [[metadata]] system does. For example, I would have only the "Debian" directory from `conference procedings` in my `presentations` repo.
+
+How would that work? Would I need to do some [subtree merging](http://git-scm.com/book/ch6-7.html) magic? or `git subtree`? or submodules? or should i just use myrepos and pretend I never brought up this idea?
+
+thanks! -- [[anarcat]]
+
+related: [[tips/migrating_two_seperate_disconnected_directories_to_git_annex/]] - but that creates a merged repo...
diff --git a/doc/forum/unrelated_repositories_sync/comment_1_c899b7b05a96d14e25c2efadff3b4e52._comment b/doc/forum/unrelated_repositories_sync/comment_1_c899b7b05a96d14e25c2efadff3b4e52._comment
new file mode 100644
index 0000000000..7df8a0eb93
--- /dev/null
+++ b/doc/forum/unrelated_repositories_sync/comment_1_c899b7b05a96d14e25c2efadff3b4e52._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 1"
+ date="2014-04-02T19:51:06Z"
+ content="""
+It might help if you think about these two different repositories as branches. You have 2 branches with different files in them, and you want to produce a third branch with some mix of the two.
+
+I think git is perfectly capable of doing that. Where it gets hairy is dealing with merges when either of the 2 repositories change going forward. The same as if you've forked and modified source code, you will need to do *something* to resolve merges.
+"""]]
diff --git a/doc/forum/unsynced_folder.mdwn b/doc/forum/unsynced_folder.mdwn
new file mode 100644
index 0000000000..ceb04011e8
--- /dev/null
+++ b/doc/forum/unsynced_folder.mdwn
@@ -0,0 +1,3 @@
+If I have an archive with a lot of big files, is it possible to get one of them without using the command line, and without it popping up on other clients of that repository?
+Is it possible to have a folder that will not be synced with other clients but will still download the file when i copy it from archive?
+.gitignore probably wont work because that will not get the file from archive.
diff --git a/doc/forum/unsynced_folder/comment_1_7d7a262f067c7b02d76e82637223934c._comment b/doc/forum/unsynced_folder/comment_1_7d7a262f067c7b02d76e82637223934c._comment
new file mode 100644
index 0000000000..7f746df12c
--- /dev/null
+++ b/doc/forum/unsynced_folder/comment_1_7d7a262f067c7b02d76e82637223934c._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 1"
+ date="2013-12-12T20:09:48Z"
+ content="""
+Sorry I took so long to answer. I think that it took me a few tries to understand your question.
+
+You want to have a special folder on a single clone of a repository, and be able to move files to that folder from the archive folder, and have it get the file content from the archive repository. But you don't want that file content to spread to any of the other repositories.
+
+This is possible to do by writing a custom [[preferred_content]] expression, and configuring the repository to use it. For simplicity, let's make the folder be called `archive/local`. This way, all the clients that do not use this preferred content expression will see that the file is still under the archive folder, and not want its content.
+
+Now we can take the preferred content expression used by client repositories normally:
+
+  ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) or (not copies=semitrusted+:1)
+
+And modify it:
+
+  ((exclude=*/archive/* and exclude=archive/* and (not */archive/local/*) and (not archive/local/*)) or (not (copies=archive:1 or copies=smallarchive:1))) or (not copies=semitrusted+:1)
+
+You can use `git annex vifg` to edit the preferred content expressions, and paste that in. Should work. Untested.
+"""]]
diff --git a/doc/forum/untitled.mdwn b/doc/forum/untitled.mdwn
new file mode 100644
index 0000000000..ce75143cf1
--- /dev/null
+++ b/doc/forum/untitled.mdwn
@@ -0,0 +1,5 @@
+Hi,
+
+How git-annex-get chooses remote when it's called without the '--from' option? Is it anyhow controllable to prefer specific remotes/set priorities?
+
+What about downloading multiple files? Does it download from multiple remotes at the same time to optimize for bandwidth?
diff --git a/doc/forum/untitled/comment_1_0176d1d50bd62b113ff690346ba4161b._comment b/doc/forum/untitled/comment_1_0176d1d50bd62b113ff690346ba4161b._comment
new file mode 100644
index 0000000000..5e030b962e
--- /dev/null
+++ b/doc/forum/untitled/comment_1_0176d1d50bd62b113ff690346ba4161b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-05T16:34:35Z"
+ content="""
+Remotes have configurable costs, see `remote.<name>.annex-cost`
+documentation in [[git-annex]].
+
+`git annex get` and some other commands can be used with `-J3` to
+download multiple files at once. However, it only downloads
+each file from the cheapest remote that has a copy.
+
+It would perhaps be an interesting improvement to make it round-robin
+amoung remotes if there are multiple ones that have the same cost.
+"""]]
diff --git a/doc/forum/update_via_cabal_fails.mdwn b/doc/forum/update_via_cabal_fails.mdwn
new file mode 100644
index 0000000000..aae8461c6a
--- /dev/null
+++ b/doc/forum/update_via_cabal_fails.mdwn
@@ -0,0 +1,35 @@
+I tried to update git-annex via cabal. It fails due to lens not installing:
+
+    juh@sokrates:~$ cabal update
+    Downloading the latest package list from hackage.haskell.org
+    juh@sokrates:~$ cabal install git-annex
+    Resolving dependencies...
+    In order, the following will be installed:
+    lens-4.2 (new version)
+    DAV-0.6.2 (reinstall) changes: http-client-0.3.1.1 -> 0.3.3.1,
+    http-client-tls-0.2.1.1 added, http-types-0.8.4 -> 0.8.5, lens-4.1.2 ->     4.2,
+    network-2.4.1.2 added, optparse-applicative-0.7.0.2 added, xml-    conduit-1.2.0.1
+    -> 1.2.0.2, xml-hamlet-0.4.0.8 added
+    git-annex-5.20140707 (new package)
+    Warning: Note that reinstalls are always dangerous. Continuing anyway...
+    [1 of 1] Compiling Main             ( /tmp/lens-4.2-3107/lens-4.2/Setup.    lhs, /tmp/lens-4.2-3107/lens-4.2/dist/setup/Main.o )
+    Linking /tmp/lens-4.2-3107/lens-4.2/dist/setup/setup ...
+    Configuring lens-4.2...
+    Building lens-4.2...
+    Preprocessing library lens-4.2...
+    
+    src/Control/Lens/Internal/Zoom.hs:47:8:
+        Could not find module `Control.Monad.Trans.Except'
+        Perhaps you meant
+          Control.Monad.Trans.Cont (from transformers-0.3.0.0)
+          Control.Monad.Trans.Error (from transformers-0.3.0.0)
+          Control.Monad.Trans.List (from transformers-0.3.0.0)
+        Use -v to see a list of the files searched for.
+    Failed to install lens-4.2
+    cabal: Error: some packages failed to install:
+    DAV-0.6.2 depends on lens-4.2 which failed to install.
+    git-annex-5.20140707 depends on lens-4.2 which failed to install.
+    lens-4.2 failed during the building phase. The exception was:
+    ExitFailure 1
+
+I am not an experienced user of cabal. So any hints to solve the conflicts are appreciated.
diff --git a/doc/forum/update_via_cabal_fails/comment_1_e1235dc2acd3bac3dd51b7614dabbb88._comment b/doc/forum/update_via_cabal_fails/comment_1_e1235dc2acd3bac3dd51b7614dabbb88._comment
new file mode 100644
index 0000000000..71fd0e60f9
--- /dev/null
+++ b/doc/forum/update_via_cabal_fails/comment_1_e1235dc2acd3bac3dd51b7614dabbb88._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 1"
+ date="2014-07-09T17:58:48Z"
+ content="""
+It seems like you must have transformers-compat 0.1.1, and lens's dependency is slightly wrong, accepting that extremly old version. You'll need to upgrade it.
+"""]]
diff --git a/doc/forum/updating_the___34__number_of_copies__34__.mdwn b/doc/forum/updating_the___34__number_of_copies__34__.mdwn
new file mode 100644
index 0000000000..c28d265307
--- /dev/null
+++ b/doc/forum/updating_the___34__number_of_copies__34__.mdwn
@@ -0,0 +1,14 @@
+Is it possible to let git-annex check and update the "number of copies" or "whereis" information without recalculating the checksome?
+
+The use case is this:
+
+I have a very large "repo1": 300.000 files 1.5 TB.
+
+I copy it using low level tools for performance (clone the partition, netcat over network, or whatever...)
+
+Then i do "git annex init 'repo2'". 
+All files exist in both repos and the simlinks are valid, but git-annex does not know about it. 
+The "git-annex wehereis" only shows "repo1". How can I tell him without rehashing 1.6TB?
+
+Thx
+
diff --git a/doc/forum/updating_the___34__number_of_copies__34__/comment_1_327bdb0d9c190c60c7147b3acf07af09._comment b/doc/forum/updating_the___34__number_of_copies__34__/comment_1_327bdb0d9c190c60c7147b3acf07af09._comment
new file mode 100644
index 0000000000..2fd4ffaee0
--- /dev/null
+++ b/doc/forum/updating_the___34__number_of_copies__34__/comment_1_327bdb0d9c190c60c7147b3acf07af09._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 1"
+ date="2012-12-01T18:40:46Z"
+ content="""
+Well, first of all, after copying a repository like this, you need to edit its .git/config and delete the annex.uuid setting. Otherwise, you will have two repositories with the same UUID, which is not good.
+
+Once you've done that, run `git annex fsck` in the new repository and it will do what you want.
+"""]]
diff --git a/doc/forum/updating_the___34__number_of_copies__34__/comment_2_7e11c839637e0894332e413cde02cee9._comment b/doc/forum/updating_the___34__number_of_copies__34__/comment_2_7e11c839637e0894332e413cde02cee9._comment
new file mode 100644
index 0000000000..269fc22bc9
--- /dev/null
+++ b/doc/forum/updating_the___34__number_of_copies__34__/comment_2_7e11c839637e0894332e413cde02cee9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlgyVag95OnpvSzQofjyX0WjW__MOMKsl0"
+ nickname="Sehr"
+ subject="comment 2"
+ date="2012-12-01T19:27:59Z"
+ content="""
+Ok, that did the trick, except that it recalculates all cehcksums, which is exactly wat I do not want, as it is unnecessary and takes at 40MB/s just too long. Any other way? I think about adding the whereis info by hand, which simply feels wrong!
+"""]]
diff --git a/doc/forum/updating_the___34__number_of_copies__34__/comment_3_8b7a70fb3bb41e4eda412302834730bb._comment b/doc/forum/updating_the___34__number_of_copies__34__/comment_3_8b7a70fb3bb41e4eda412302834730bb._comment
new file mode 100644
index 0000000000..c130950906
--- /dev/null
+++ b/doc/forum/updating_the___34__number_of_copies__34__/comment_3_8b7a70fb3bb41e4eda412302834730bb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 3"
+ date="2012-12-01T19:37:26Z"
+ content="""
+git annex fsck --fast will skip the checksumming.
+"""]]
diff --git a/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive.mdwn b/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive.mdwn
new file mode 100644
index 0000000000..a6bc0b7bd6
--- /dev/null
+++ b/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive.mdwn
@@ -0,0 +1,13 @@
+story: i got a new drive from the store. plug it in. it's recognized by XFCE and mounted automatically. turns out it's NTFS, but Debian doesn't seem to mind.
+
+go in the assistant, add it as an "External drive", make it a "full backup" and let it sync.
+
+expected result: i see files
+
+actual result: i see a bare git repository.
+
+if i first `git init` the directory so it's not bare, at least i get a better handle on it: i can sync with the assistant, then `git merge synced/master` to see the files.
+
+really confusing to me, sorry if it's a dupe... 
+
+workaround: use the commandline: `git clone <repo>` and `git annex get`. --[[anarcat]]
diff --git a/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_1_27b5283c65c402f330263426e4ca6ac1._comment b/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_1_27b5283c65c402f330263426e4ca6ac1._comment
new file mode 100644
index 0000000000..1b5508f978
--- /dev/null
+++ b/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_1_27b5283c65c402f330263426e4ca6ac1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 1"
+ date="2014-09-16T18:07:54Z"
+ content="""
+I started to make this change, and then I realized this problem: If a non-bare repository is made on an external drive, then to the user this is another place they can edit their files. Which means they will expect their changes made there to be committed. Which is highly problematic, because the assistant cannot be left running on an external drive or it won't be able to be unmounted. Or, a periodic `git annex add; git annex sync` could be run on the external drive, but that is a more expensive process (especially when run on a slow drive) and would not meet the expectations of users of the assistant that their changes will promptly propagate.
+
+So, I feel that leaving bare repositories is actually the best choice.
+"""]]
diff --git a/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_2_b3a6b5ff0aaddd78903fc7bc7fbd6ee2._comment b/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_2_b3a6b5ff0aaddd78903fc7bc7fbd6ee2._comment
new file mode 100644
index 0000000000..e264c8f08c
--- /dev/null
+++ b/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_2_b3a6b5ff0aaddd78903fc7bc7fbd6ee2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="70.83.139.100"
+ subject="comment 2"
+ date="2014-09-16T20:35:23Z"
+ content="""
+i wouldn't expect those changes to be committed. it's an external drive, and unless i manually sync it, it should take into account my changes.
+
+i am more surprised by the bare repository than i would be surprised by my changes not propagating back, i think. --[[anarcat]]
+"""]]
diff --git a/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_3_aab934c0e37771d7f834d2567a9e76a1._comment b/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_3_aab934c0e37771d7f834d2567a9e76a1._comment
new file mode 100644
index 0000000000..50d97fa269
--- /dev/null
+++ b/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_3_aab934c0e37771d7f834d2567a9e76a1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 3"
+ date="2014-11-25T21:26:44Z"
+ content="""
+Of course you wouldn't expect that, I've explained the problem to you and you're technically adept and know about issues with keeping open files on removable drives.
+
+However, I have to consider the affordances of what the assistant sets up, and the natural affordance of a drive containing a directory with your files in it is to be able edit those files. And when changes in every other clone of that directory get automatically synced, the expectation would be for the same to hold true on this directory on the removable drive.
+
+I can see perhaps having the assistant run `git annex merge` in a removable repo after pushing to it (but `git annex sync` should not do that; violates least surprise for a git pull+merge+push wrapper like that to affect the work trees of other repos). As long as the assistant defaults to making removable repos bare, it won't expose normal users to the problem, and only advanced users who know how to set up non-bare repos. 
+
+If this is only for advanced users though, it (both assistant and `git annex sync`) could just as well run a configurable command on a removable repo after pushing to it. Or, the advanced user could use their skillz to make the removable drive be formatted with a reasonable filesystem that allows executable files, and then set up a git post-receive hook.
+"""]]
diff --git a/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_4_42beace277e009ddff449cb220775d44._comment b/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_4_42beace277e009ddff449cb220775d44._comment
new file mode 100644
index 0000000000..816a81da9f
--- /dev/null
+++ b/doc/forum/usability__58___creating_an_archive_on_a_new_external_drive/comment_4_42beace277e009ddff449cb220775d44._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-02-17T19:38:45Z"
+ content="""
+It's now pretty easy to set up a remote on a USB drive so that `git annex
+sync` will update the work tree. See 
+<https://git-annex.branchable.com/tips/making_a_remote_repo_update_when_changes_are_pushed_to_it/>
+
+However, the assistant does not do this by default when adding repos on USB
+drives, due to the likely confusion that setting up such a repo would
+cause, as described in my previous comment.
+"""]]
diff --git a/doc/forum/usability__58___what_are_those_arrow_things__63__.mdwn b/doc/forum/usability__58___what_are_those_arrow_things__63__.mdwn
new file mode 100644
index 0000000000..cde7d8d505
--- /dev/null
+++ b/doc/forum/usability__58___what_are_those_arrow_things__63__.mdwn
@@ -0,0 +1,29 @@
+# Introduction
+
+i want to relate a usability story that happens fairly regularly when I show git-annex to people. the story goes like this.
+
+# The story
+
+Antoine sat down at his computer saying, "i have this great movie collection I want to share with you, my friend, because the fair use provisions allow for that, and I use this great git-annex tool that allows me to sync my movie collection between different places". His friend Charlie, a Linux user only vaguely familiar with the internals of how his operating system or legal system actually works, reads this as "yay free movies" and wholeheartedly agrees to lend himself to the experiment.
+
+Antoine creates a user account for Charlie on his home computer, because he doesn't want to have to do everything himself. "That way you can choose which movies you want, because you probably don't want my complete movie collection!" Charlie emphatically responds: "right, I only have my laptop and this USB key here, so I don't think I can get it all".
+
+Charlie logs into Antoine's computer, named `marcos`. Antoine shows Charlie where the movies are located (`/srv/video`) through the file browser (Thunar, for the record). Charlie inserts his USB key into `marcos` and a new icon for the USB key shows up. Then Charlie finds a video he likes, copies and pastes it into the USB key. But instead of a familiar progress bar, Charlie is prompted with a dialog that says "Le système de fichiers ne gère pas les liens symboliques." (Antoine is french, so excuse him, this weird message says that the filesystem doesn't support symbolic links.) Puzzled, Charlie tries to copy the file to his home directory instead. This works better, but the file has a little arrow on it, which seems odd to Charlie. He then asks Antoine for advice.
+
+Antoine then has no solution but to convert the git-annex repository into direct mode, something which takes a significant amount of time and is actually [[designated as "untrusted"|direct_mode]] in the documentation. In fact, so much so that he actually did [[screw up his repository magnificently|bugs/direct_command_leaves_repository_inconsistent_if_interrupted]] because he freaked out when `git-annex direct` started and interrupted it because he tought it would take too long.
+
+# Technical analysis
+
+Now I understand it is not necessarily `git-annex`'s responsability if Thunar (or Nautilus, for that matter), doesn't know how to properly deal with symlinks (hint: just dereference the damn thing already). Maybe I should file a bug about this against thunar? I also understand that symlinks are useful to ensure the security of the data hosted in `git-annex`, and that I could have used direct mode in the first place. But I like to track changes in git to those files, and direct mode makes that really difficult.
+
+I didn't file this as a bug because I want to start the conversation, but maybe it should qualify as a usability bug. As things stand, this is one of the biggest hurdle in teaching people about git annex.
+
+(The other being "how do i actually use git annex to sync those files instead of just copying them by hand", but that's for another story!)
+
+-- [[anarcat]]
+
+# Followup
+
+Here is a bug report filed against Thunar, with a patch to fix this behavior: https://bugzilla.xfce.org/show_bug.cgi?id=11065
+
+Similar bugs would need to be filed against Nautilus, at the very least, but probably other file managers, which makes this task a little daunting, to say the least. -- [[anarcat]]
diff --git a/doc/forum/usability__58___what_are_those_arrow_things__63__/comment_1_bf34c169c725f9504e0f2114ba53be4b._comment b/doc/forum/usability__58___what_are_those_arrow_things__63__/comment_1_bf34c169c725f9504e0f2114ba53be4b._comment
new file mode 100644
index 0000000000..86099c0d53
--- /dev/null
+++ b/doc/forum/usability__58___what_are_those_arrow_things__63__/comment_1_bf34c169c725f9504e0f2114ba53be4b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 1"
+ date="2014-08-12T19:49:35Z"
+ content="""
+If I wanted to share files with someone, I'd set them up with a direct mode repository and link it to my (probably indirect mode) repository.
+
+The question then becomes, how can this person decide which files to get if they don't want to or cannot get everything. I think that [[tips/File_manager_integration]] is a pretty good answer, although it does involve adding extensions to file managers. At least it involves adding something, rather than convincing a suprisingly large number of people that their ideas about symlinks are wrong. There are other possible answers, like building a file selection UI into the webapp..
+"""]]
diff --git a/doc/forum/usability__58___what_are_those_arrow_things__63__/comment_2_364ce8b369fd0ba7ddaec3127840ff39._comment b/doc/forum/usability__58___what_are_those_arrow_things__63__/comment_2_364ce8b369fd0ba7ddaec3127840ff39._comment
new file mode 100644
index 0000000000..32ecdf0df8
--- /dev/null
+++ b/doc/forum/usability__58___what_are_those_arrow_things__63__/comment_2_364ce8b369fd0ba7ddaec3127840ff39._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="70.83.139.100"
+ subject="comment 2"
+ date="2014-08-12T19:56:58Z"
+ content="""
+the problem with this is that you end up having two copies of the same files (the direct and indirect repositories). also, the switch to direct mode exploded (because i screwed up, granted)....
+
+i have been thinking more and more than the webapp needs to have some sort of file manager as well, but that seems like a huge undertaking...
+
+a better file manager integration could certainly allow to improve this experience. for me the requirements would be:
+
+* \"clone this repo to\" - make a copy of this git annex repo to the specified target
+* \"annex-copy those files to\" - the above + a file-transfer-like dialog that would track the total file transfer (as opposed to \"begin/end\" of single files, see also [[todo/do_not_bug_me_about_intermediate_files/]])
+* probably some more stuff
+"""]]
diff --git a/doc/forum/use_case__58___unique_indentifier_of_objets___40__doi_like__41__.mdwn b/doc/forum/use_case__58___unique_indentifier_of_objets___40__doi_like__41__.mdwn
new file mode 100644
index 0000000000..76f03452dc
--- /dev/null
+++ b/doc/forum/use_case__58___unique_indentifier_of_objets___40__doi_like__41__.mdwn
@@ -0,0 +1,20 @@
+Dear all,
+           From some time now I am wondering about a way to index a set of files, lets say PDF documents. The idea is to have a unique identifier for each file and to cross-reference using this identifier. For instance, I use a project management (PM) software (web based) on a public server of my university. Then I have a set of tasks saying, review document X, or Y. And those documents are stored on an internal server of my lab.
+I see several options:
+
+1. Upload the required documents to the PM site and directly link
+2. Share online my internal server and use the URL of the docs in the PM
+3. Just use the unique identifier in the PM, and then look in git annex for that ID
+4. Use some sort of document management system (DMS)
+
+Options 1 and 2 are impractical for several reasons. Option 4 usually requires that your files are inside the DMS.
+So my questions are: 
+
+* Do you think this is doable with git-annex?
+* Is there an easy way to ask it: give me the document with this index?
+* I think the best answer for this question is: git annex find --include '*' --format='${key} ${file}' | grep <KEY>
+* And conversely, how do I find the key of a certain document?
+
+Thanks in advance.
+Best,
+       Juan
diff --git a/doc/forum/use_case__58___unique_indentifier_of_objets___40__doi_like__41__/comment_1_955f3aac12c1ddb41267c5a23ccb79e3._comment b/doc/forum/use_case__58___unique_indentifier_of_objets___40__doi_like__41__/comment_1_955f3aac12c1ddb41267c5a23ccb79e3._comment
new file mode 100644
index 0000000000..069d41c106
--- /dev/null
+++ b/doc/forum/use_case__58___unique_indentifier_of_objets___40__doi_like__41__/comment_1_955f3aac12c1ddb41267c5a23ccb79e3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 1"
+ date="2014-07-03T19:10:53Z"
+ content="""
+To make git-annex output the key of a file, run: `git annex lookupkey $file`
+
+I don't know if the git-annex key is appropriate for your use-case. If the files never get changed, then it's a nice stable identifier. If ongoing changes are made to a file, and you want to link to the most recent version, the key would not be useful.
+
+You might also look at git-annex's [[metadata]]; you could make up some metadata field and value and attach it to a file, and it would persist as the file was modified.
+"""]]
diff --git a/doc/forum/use_case__58___unique_indentifier_of_objets___40__doi_like__41__/comment_2_0aff36755f49afddd5482a602a1ccd2b._comment b/doc/forum/use_case__58___unique_indentifier_of_objets___40__doi_like__41__/comment_2_0aff36755f49afddd5482a602a1ccd2b._comment
new file mode 100644
index 0000000000..2ef754f163
--- /dev/null
+++ b/doc/forum/use_case__58___unique_indentifier_of_objets___40__doi_like__41__/comment_2_0aff36755f49afddd5482a602a1ccd2b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmTNrhkVQ26GBLaLD5-zNuEiR8syTj4mI8"
+ nickname="Juan"
+ subject="comment 2"
+ date="2014-07-09T15:32:49Z"
+ content="""
+If I get this right, the key will change every time the file is changed.
+If that's the case, seems that it won't be useful for my case.
+Thanks for the time.
+"""]]
diff --git a/doc/forum/use_case_question__58___developer_repo_with_s3.mdwn b/doc/forum/use_case_question__58___developer_repo_with_s3.mdwn
new file mode 100644
index 0000000000..b1b32e1947
--- /dev/null
+++ b/doc/forum/use_case_question__58___developer_repo_with_s3.mdwn
@@ -0,0 +1,6 @@
+Hello, the teams I work with have repositories for tracking CI pipelines and build scripts.  There are binary resources, and sensitive information, that we would like to somehow be able to store with the repo, but in a secure fashion. Would a scenario like this be feasible with git-annex?
+
+* create an annex attached to existing code repositories, with s3 as the special remote.  
+* each developer is able to read or add to and from the encrypted bucket using either their key from signed commits or from an ssh key
+
+We already reject non-signed commits, and are not public-facing in our repositories or accessible without credentials to s3. The developers with access to the repository are all of the same access level internal to the company with permission to do what they must with the keys.  I'm sorry if this is an obvious 'yes' or 'no' question.  Using git-annex privately as a file store for myself thus far has been excellent.
diff --git a/doc/forum/use_case_question__58___developer_repo_with_s3/comment_1_3e48d0a6c74e1bd67b1128d6b52f5fc4._comment b/doc/forum/use_case_question__58___developer_repo_with_s3/comment_1_3e48d0a6c74e1bd67b1128d6b52f5fc4._comment
new file mode 100644
index 0000000000..69bda1022f
--- /dev/null
+++ b/doc/forum/use_case_question__58___developer_repo_with_s3/comment_1_3e48d0a6c74e1bd67b1128d6b52f5fc4._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2019-01-16T23:44:02Z"
+ content="""
+I think you could probably achieve what you need to (depending on your specific needs).
+
+There some general notes on encryption at: <http://git-annex.branchable.com/encryption/> and <http://git-annex.branchable.com/design/encryption/> and some insights into `git-annex` internals with respect to encryption here <https://git-annex.branchable.com/tips/Decrypting_files_in_special_remotes_without_git-annex/>.
+
+I think you could setup s3 as a special remote with something like:
+
+    git annex initremote sensitive-s3 type=S3 chunk=1MiB encryption=hybrid embedcreds=no  keyid=DEV1_KEYID
+
+`DEV1_KEYID` is a name that the user's GPG keyring can recognize (sounds like you already have those). `hybrid` encryption means (I think?) that DEV1_KEYID GPG public key is used to encrypt a symmetric cipher that is stored in the repo. All the content on `sensitive-s3` will be encrypted using the symmetric cipher.  By default DEV1_KEYID will also be used to encrypt `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` which are stored encrypted in the repo, `embedcreds=no` means don't store that info in the repo.
+
+If you want to grant another developer access to `sensitive-s3`, then run something like:
+
+    git annex enableremote sensitive-s3 keyid+=DEV2_KEYID
+
+I can't find any documentation of what happens next, but I assume `git-annex` re-encrypts the symmetric cipher using multi-key encryption so both DEV1_KEYID and DEV2_KEYID can decrypt the symmetric cipher using either of their private keys. Because `git-annex` doesn't actually encrypt your files using gpg keys when using `hybrid` encryption, you don't need to re-upload or re-encrypt any files. `git-annex` is only using the GPG keys to grant access to a small encrypted file containing a symmetric cipher that is used for the actual encryption of files.
+
+The one main drawback with this design is that is difficult to revoke access. If you want, at a later date, to revoke DEV2's access to sensitive-s3, you can't do that using any built-in `git-annex` feature. You could give each dev their own AWS creds up-front, then at the very least you could revoke those on AWS. If you need to, you could also delete the old cipher regenerate a new one and re-upload all files with a new cipher that only remaining developers have access to.
+"""]]
diff --git a/doc/forum/use_case_question__58___developer_repo_with_s3/comment_2_751d3f5855729d493ee2042b19117a70._comment b/doc/forum/use_case_question__58___developer_repo_with_s3/comment_2_751d3f5855729d493ee2042b19117a70._comment
new file mode 100644
index 0000000000..8a9c6dff36
--- /dev/null
+++ b/doc/forum/use_case_question__58___developer_repo_with_s3/comment_2_751d3f5855729d493ee2042b19117a70._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 2"
+ date="2019-01-16T23:51:21Z"
+ content="""
+Another workflow is to use `encryption=pubkey`.  Again init the repo on s3. And add the keys of all your devs.
+
+    git annex initremote sensitive-s3 type=S3 chunk=1MiB encryption=pubkey embedcreds=no  keyid=DEV1_KEYID
+    git annex enableremote sensitive-s3 keyid+=DEV2_KEYID
+    git annex enableremote sensitive-s3 keyid+=DEV3_KEYID
+
+Then files on sensitive-s3 will be encrypted using (I think) multi-key encryption that any of the devs can decrypt using their private key.
+
+If you want to remove a dev later then you would have to, tell git-annex to remove their key, drop all files from sensitive-s3 (since they are readable by the revoked dev), then re-upload all files.
+
+    git annex enableremote sensitive-s3 keyid-=DEV2_KEYID
+    git annex drop --from=sensitive-s3
+    git annex copy --to=senitive-s3 /tmp/all-the-sensitive-files
+"""]]
diff --git a/doc/forum/use_case_question__58___developer_repo_with_s3/comment_3_69ec3fedc166d68c10103b97c231e3d4._comment b/doc/forum/use_case_question__58___developer_repo_with_s3/comment_3_69ec3fedc166d68c10103b97c231e3d4._comment
new file mode 100644
index 0000000000..d54f400a01
--- /dev/null
+++ b/doc/forum/use_case_question__58___developer_repo_with_s3/comment_3_69ec3fedc166d68c10103b97c231e3d4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="pthomasdelaney@9b04608ad7e837fde64ab60a285a7b7254b5bb26"
+ nickname="pthomasdelaney"
+ avatar="http://cdn.libravatar.org/avatar/2212a0d6c1fd93bc531c1fb461777a68"
+ subject="comment 3"
+ date="2019-01-18T03:31:35Z"
+ content="""
+thanks for pointing me to these resources Andrew, these really help.  I think that the pubkey method should work for us, especially since we have the capabilities to revoke access.  
+"""]]
diff --git a/doc/forum/use_case_question__58___developer_repo_with_s3/comment_4_4afea3a65b6b5c57a4dac5cdbbf89432._comment b/doc/forum/use_case_question__58___developer_repo_with_s3/comment_4_4afea3a65b6b5c57a4dac5cdbbf89432._comment
new file mode 100644
index 0000000000..9ead218908
--- /dev/null
+++ b/doc/forum/use_case_question__58___developer_repo_with_s3/comment_4_4afea3a65b6b5c57a4dac5cdbbf89432._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 4"
+ date="2019-01-20T21:14:03Z"
+ content="""
+Great, glad to hear this setup might work for you. Also, I also forgot to mention another drawback with `encryption=pubkey` is that you can't easily add add a key for a newly added developer later on, if you want to add a new developer key after you have uploaded files to s3 you will have to drop all the files, add the new key to git-annex, make sure all your devs do a `git-annex sync` to get the new set of public keys to use for encryption, then re-upload all the files to s3.
+"""]]
diff --git a/doc/forum/use_case_question__58___developer_repo_with_s3/comment_5_743d7435c4e94efb293f4d6b1e83483d._comment b/doc/forum/use_case_question__58___developer_repo_with_s3/comment_5_743d7435c4e94efb293f4d6b1e83483d._comment
new file mode 100644
index 0000000000..7a2c1d5bee
--- /dev/null
+++ b/doc/forum/use_case_question__58___developer_repo_with_s3/comment_5_743d7435c4e94efb293f4d6b1e83483d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="pthomasdelaney@9b04608ad7e837fde64ab60a285a7b7254b5bb26"
+ nickname="pthomasdelaney"
+ avatar="http://cdn.libravatar.org/avatar/2212a0d6c1fd93bc531c1fb461777a68"
+ subject="comment 5"
+ date="2019-01-23T02:26:33Z"
+ content="""
+thanks for pointing that out, I was wondering about that reading through the documentation.  We're going to give it a quick try and see how it goes.  We've got a very small team (less than five) and we require additional authentication to access the annex. I think it also works out that our company policy is a key rotation upon a departure, I'd be asked to re-create the annex. long-term we may look for other options if it seems too cumbersome but hopefully our turn over rate isn't that high.
+"""]]
diff --git a/doc/forum/use_existing_ssh_keys__63__.mdwn b/doc/forum/use_existing_ssh_keys__63__.mdwn
new file mode 100644
index 0000000000..7f73c18bc2
--- /dev/null
+++ b/doc/forum/use_existing_ssh_keys__63__.mdwn
@@ -0,0 +1,5 @@
+Hi, a new user trying out git-annex 3.20130124 here. So far looks really promising, thanks.
+
+I setup a local annex using the assistant webapp. I then created a rsync cloud repo over ssh to my shell box in a nearby data center for it. Works ok. I already have ssh key setup inclding ssh-agent for quick logins to the server. It would be great if you could configure the assistant to use these existing keys instead of creating a new set of keys. Maybe keep the defaults as is, but provide the config for this hidden behind "trust me, I know what I'm doing" check box or something.
+
+Thanks again, I keep researching.
diff --git a/doc/forum/use_existing_ssh_keys__63__/comment_1_c420c53f022bbd1b28494bc44d076feb._comment b/doc/forum/use_existing_ssh_keys__63__/comment_1_c420c53f022bbd1b28494bc44d076feb._comment
new file mode 100644
index 0000000000..93cb92c557
--- /dev/null
+++ b/doc/forum/use_existing_ssh_keys__63__/comment_1_c420c53f022bbd1b28494bc44d076feb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.125"
+ subject="comment 1"
+ date="2013-02-07T18:11:30Z"
+ content="""
+Hmm. The assistant already tries to cater to this case of having an existing key. When setting up a rsync or ssh remote, it first tries to ssh to the server without allowing a password to be prompted for. If this succeeds, it assumes you have a passwordless key and uses it. Otherwise, it sshes in once with a password prompt, and sets up its own key.
+"""]]
diff --git a/doc/forum/use_existing_ssh_keys__63__/comment_2_e4cae848e5701852073ced307832872b._comment b/doc/forum/use_existing_ssh_keys__63__/comment_2_e4cae848e5701852073ced307832872b._comment
new file mode 100644
index 0000000000..4aaaeacce8
--- /dev/null
+++ b/doc/forum/use_existing_ssh_keys__63__/comment_2_e4cae848e5701852073ced307832872b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnwz07HJdp3nzLwCAl7OGKn_3m0tTO4Mxw"
+ nickname="Teemu"
+ subject="use existing ssh keys?"
+ date="2013-03-02T12:05:30Z"
+ content="""
+I also found the key setup confusing. I have many identity files for several server / service combinations, so the webapp key setup for an ssh+rsync cloud server always failed with too many identification attempts before I had the sense to move my keys temporarily away from ~/.ssh
+
+It would be really nice if the webapp would allow one either to pick an existing identity, or to create a new one with the aid of a couple of password logins.
+
+Also, having the created key to be restricted to only running rsync in the server would improve the chances of 'Share with a friend' use case being used. I don't think many people will want to give out full shell access to their servers in order to share some files.
+"""]]
diff --git a/doc/forum/use_existing_ssh_keys__63__/comment_3_a97c20b6df74c49e5f57c7caf962f1e2._comment b/doc/forum/use_existing_ssh_keys__63__/comment_3_a97c20b6df74c49e5f57c7caf962f1e2._comment
new file mode 100644
index 0000000000..e90ed07be4
--- /dev/null
+++ b/doc/forum/use_existing_ssh_keys__63__/comment_3_a97c20b6df74c49e5f57c7caf962f1e2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-03-03T16:57:22Z"
+ content="""
+When pairing with a local computer, both systems set up locked down ssh keys that only allow the pair to run git-annex on the repository being paired with. This does *not* involve full shell access.
+
+The \"remote server\" necessarily involves you already having shell access to the remote server. However, the ssh key that the assistant generates is again locked down to only being able to run git-annex on a single repository on the remote server.
+"""]]
diff --git a/doc/forum/use_existing_ssh_keys__63__/comment_4_8977bb8ee662c30dfcecae73cede9dfa._comment b/doc/forum/use_existing_ssh_keys__63__/comment_4_8977bb8ee662c30dfcecae73cede9dfa._comment
new file mode 100644
index 0000000000..696120da9c
--- /dev/null
+++ b/doc/forum/use_existing_ssh_keys__63__/comment_4_8977bb8ee662c30dfcecae73cede9dfa._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="80d8aa@c71d4a9510ad0353dbcf7df399c2e6bde0012474"
+ nickname="80d8aa"
+ avatar="http://cdn.libravatar.org/avatar/b3f9ee295805d0758d569ca97157fb65"
+ subject="Use existing ssh keys"
+ date="2017-09-30T17:07:39Z"
+ content="""
+Is there an argument against the original request of being able to use an existing *non-default* ssh key when setting up a remote ssh repo with the webapp?
+
+As suggested above, one could reasonably have different identities, not all of which should have access to the git-annex repo. AFAIU, the way things are one has to either use their default identity with a remote ssh repo OR temporarily enable password authentication on the server so that the webapp will generate and install its own key, then turn it off. That is a tall order and might not even be possible if the server is not under the user's control. Am I missing something?
+
+"""]]
diff --git a/doc/forum/using_--quiet_with_sync.mdwn b/doc/forum/using_--quiet_with_sync.mdwn
new file mode 100644
index 0000000000..0e54f899a5
--- /dev/null
+++ b/doc/forum/using_--quiet_with_sync.mdwn
@@ -0,0 +1,9 @@
+When using `git annex sync --quiet --content --message="$(date +%F)"` I still get undesirable output in stderr even though it's not an error. Specifically, looks like:
+
+```
+>From /media/usb/backup-secrets
+   4909d792..694d8203  git-annex  -> usb/git-annex
+   6c8e7713..9d5a7e62  master     -> usb/master
+```
+
+I'd prefer not to use the approach of piping stdout/stderr to /dev/null because I still want errors to appear. Am I doing something wrong or is it not possible?
diff --git a/doc/forum/using_--quiet_with_sync/comment_1_69c2034761a8b92b001b142e49f0449e._comment b/doc/forum/using_--quiet_with_sync/comment_1_69c2034761a8b92b001b142e49f0449e._comment
new file mode 100644
index 0000000000..ba41bab280
--- /dev/null
+++ b/doc/forum/using_--quiet_with_sync/comment_1_69c2034761a8b92b001b142e49f0449e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-07-19T15:24:55Z"
+ content="""
+It's perfectly fine to file a bug report if you find something like this.
+
+Nobody seems to have wanted that before.. I've implemented it now.
+"""]]
diff --git a/doc/forum/using_git-annex_with_lightroom.mdwn b/doc/forum/using_git-annex_with_lightroom.mdwn
new file mode 100644
index 0000000000..605f2b9030
--- /dev/null
+++ b/doc/forum/using_git-annex_with_lightroom.mdwn
@@ -0,0 +1,6 @@
+I'm using git-annex to sync my photos across multiple computers, and it works beautifully. I would also like to sync Lightroom catalogues. The photo editing program creates a *.lrdata directory where it stores the edits in its own tree format. Merging two such directories obviously creates a mess. 
+
+Is there an elegant way to tell git-annex to treat the whole directory as a single file and overwrite the whole directory structure at once? I'm guessing the same problem occurs with mac os packages.
+
+Many thanks!
+Alex
diff --git a/doc/forum/using_git-annex_with_lightroom/comment_1_ec977efd277f0644767a4fc7064e4baf._comment b/doc/forum/using_git-annex_with_lightroom/comment_1_ec977efd277f0644767a4fc7064e4baf._comment
new file mode 100644
index 0000000000..e7e1fa9a60
--- /dev/null
+++ b/doc/forum/using_git-annex_with_lightroom/comment_1_ec977efd277f0644767a4fc7064e4baf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-02T15:23:18Z"
+ content="""
+There's not really a way to handle this sort of thing. I suggest that you put *.lrdata in `.gitignore`
+"""]]
diff --git a/doc/forum/using_git-annex_with_lightroom/comment_2_4dc4f1ea91c72418843a682fab1854d2._comment b/doc/forum/using_git-annex_with_lightroom/comment_2_4dc4f1ea91c72418843a682fab1854d2._comment
new file mode 100644
index 0000000000..d0626d4c72
--- /dev/null
+++ b/doc/forum/using_git-annex_with_lightroom/comment_2_4dc4f1ea91c72418843a682fab1854d2._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="Jan"
+ subject="comment 2"
+ date="2015-01-10T10:37:11Z"
+ content="""
+I had the same problem an got Lightroom to work nicely with the following configuration.
+
+Place catalog and photo data in the same directory tree, for example:
+
+
+    /Lightroom/2015/2015-01-10/IMG_4432.JPG
+    /Lightroom/2015/2015-01-10/IMG_4433.JPG
+    ...
+    /Lightroom/Catalog/Lightroom 5 Catalog.lrcat
+    /Lightroom/Catalog/Lightroom 5 Catalog Previews.lrdata
+    /Lightroom/Catalog/Backups
+
+
+Now the image data and Lightroom metadata (= catalog) can be archived at the same time. In order to prevent temporary files and previews to get annexed use the following `.gitignore`:
+
+
+    */*.lrdata
+    Temporary Folder*/
+    */Temporary Import Data*/
+    *.lock
+
+The downside is that previews will have to get regenerated on other machines which pull this data, but I don't use it to share my Lightroom config across computers but as an archival tool.
+"""]]
diff --git a/doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__.mdwn b/doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__.mdwn
new file mode 100644
index 0000000000..86e317da87
--- /dev/null
+++ b/doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__.mdwn
@@ -0,0 +1,7 @@
+I would like to use git-annex to synchronize 2 directories in the same manner as unison.
+
+I'm starting with 2 directories. There is an overlap of the same set of files in each directory, but each directory also has additional files as well.
+
+I create a git annex in each directory but when I do a git pull it merges and produces conflicts on those files that are the same.
+
+What is the correct workflow for this type of scenario?
diff --git a/doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__/comment_1_5c3ee8a8aaa6d0918c0cc9683ce177ae._comment b/doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__/comment_1_5c3ee8a8aaa6d0918c0cc9683ce177ae._comment
new file mode 100644
index 0000000000..4682ea64f7
--- /dev/null
+++ b/doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__/comment_1_5c3ee8a8aaa6d0918c0cc9683ce177ae._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="comment 1"
+ date="2011-12-18T13:57:33Z"
+ content="""
+Are the files identical or different? I today did something like that with similar, but not identical directories containing media files, and git happily merged them. but there, same files had same content.
+
+Also, make sure you use the same backend. In my case, one of the machines runs Debian stable, so I use the WORM backend, not the SHA backend.
+"""]]
diff --git a/doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__/comment_2_648946353c6d90c57351cce4010f1301._comment b/doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__/comment_2_648946353c6d90c57351cce4010f1301._comment
new file mode 100644
index 0000000000..bdd4b25e43
--- /dev/null
+++ b/doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__/comment_2_648946353c6d90c57351cce4010f1301._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-12-19T18:24:59Z"
+ content="""
+I'd recommend using the SHA backend for this, the WORM backend would produce conflicts if the files' modification times changed. 
+
+[[syncing_non-git_trees_with_git-annex]] describes one way to do it.
+"""]]
diff --git a/doc/forum/using_rsync.net_as_backup_and_glacier_as_archive.mdwn b/doc/forum/using_rsync.net_as_backup_and_glacier_as_archive.mdwn
new file mode 100644
index 0000000000..7cd68f1232
--- /dev/null
+++ b/doc/forum/using_rsync.net_as_backup_and_glacier_as_archive.mdwn
@@ -0,0 +1,13 @@
+Hi,
+
+My current setup is:
+
+  - "work" in my computer, client group
+  - "backup"  rsync.net also in client group
+  - glacier in full archive group
+
+My intention was to have rsync.net to be my live backup, from which I could pull the whole repo in case of disaster. I expected when I moved a file to "archive" in my computer this would be reflected in rsync.net and once it been archived on glacier both files (my computer and rsync) would be dropped.
+
+That did not happen, through the assistant. I watched the file uploaded to glacier but it never dropped my copy. Actually when I stopped the assistant ``git annex drop --auto`` it drops the file. But if I start the assistant again it starts downloading from rsync.net.
+
+Is there a way to accomplish what I'm trying? Maybe if rsync.net was in _trasfer_ group, but then again without being able to run ``git annex sync`` on rsync.net side (which actually supports ``git`` commands) I don't know if would work...
diff --git a/doc/forum/uuid_mismatch.mdwn b/doc/forum/uuid_mismatch.mdwn
new file mode 100644
index 0000000000..2d1626e385
--- /dev/null
+++ b/doc/forum/uuid_mismatch.mdwn
@@ -0,0 +1,17 @@
+Hi,
+
+After reinstalling my laptop with the same GPG keys, I've got this error during re-syncing a remote crypted repo :
+
+```
+Internal Server Error
+; expected Just (UUID "e7fc2bc8-b630-5eeb-a0b3-b4806d7ab064") but remote gitrepo has UUID "e2f02805-eae7-5bb8-875e-c901ba9929b1" (":id:SCPxErEQVlqp+Hl6Su0f")
+```
+
+Then, I can see the structure of the hard links in the local directory but pointing to nothing ?
+
+FYI all sub directories in .git/annex/objects contain .map files only.
+
+Could you please help me ? 
+Those data are critical, thanks for your great app and your help!
+
+Guillaume
diff --git a/doc/forum/uuid_mismatch/comment_1_ed29dcf70b916bdd094015c1c9616550._comment b/doc/forum/uuid_mismatch/comment_1_ed29dcf70b916bdd094015c1c9616550._comment
new file mode 100644
index 0000000000..a97f5baa53
--- /dev/null
+++ b/doc/forum/uuid_mismatch/comment_1_ed29dcf70b916bdd094015c1c9616550._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-10-05T19:30:48Z"
+ content="""
+It would help if you described what command you ran, or buttons you clicked
+on to get this to happen. Otherwise, I'm left making a lot of guesses..
+
+It looks like you might be running `git-annex enableremote` of a gcrypt
+special remote that you set up earlier. 
+
+It appears that the gcrypt remote has a gcrypt-id which is not the same as
+the one that was used when that special remote was originally initialized.
+
+I don't know why this would happen, and without details about what you did,
+I can barely venture a guess. All I can say is that, gcrypt is supposed to
+pick a gcrypt-id the first time a gcrypt remote is used, and not change it
+afterwards.
+
+... It might be that you did something that caused gcrypt to pick a new
+gcrypt-id.
+
+... It might be that the special remote has been pointed at a different
+gcrypt repository than the one that it was initially set up to use.
+
+It might help to look at both the local repository's `.git/config`, and the
+gcrypt git repositories git config, and see which of
+them have the wrong gcrypt-id value of ":id:SCPxErEQVlqp+Hl6Su0f".
+If only the local .git/config has that value and the gcrypt git repository
+has some other gcrypt-id, then the other one is probably the right one, and
+it might work to replace the wrong one with the right one.
+"""]]
diff --git a/doc/forum/uuid_mismatch/comment_2_de4beb1eb76ae7084387e8efc28e55d3._comment b/doc/forum/uuid_mismatch/comment_2_de4beb1eb76ae7084387e8efc28e55d3._comment
new file mode 100644
index 0000000000..9e85d931aa
--- /dev/null
+++ b/doc/forum/uuid_mismatch/comment_2_de4beb1eb76ae7084387e8efc28e55d3._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yomguy"
+ subject="comment 2"
+ date="2016-10-07T09:15:07Z"
+ content="""
+Dear Joey,
+
+Thanks you so much for your quick response.
+
+I did not use the command line for this but the web app. So I will retry the sync sequence in a shell after tweaking the gcrypt-id as you proposed and then give you some more feedback here.
+
+Cheers,
+Guillaume
+
+"""]]
diff --git a/doc/forum/uuid_mismatch/comment_3_a681a4847acbe890c4e486288b3c81d3._comment b/doc/forum/uuid_mismatch/comment_3_a681a4847acbe890c4e486288b3c81d3._comment
new file mode 100644
index 0000000000..d92f3fe17a
--- /dev/null
+++ b/doc/forum/uuid_mismatch/comment_3_a681a4847acbe890c4e486288b3c81d3._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="yomguy"
+ avatar="http://cdn.libravatar.org/avatar/03db077c04f8b753f3f504d9a2b06a29"
+ subject="comment 3"
+ date="2016-11-18T14:00:51Z"
+ content="""
+Hi joey,
+
+After modifying the gcrypt-id as you proposed, I have finally managed to clone the repo with  
+
+`git clone gcrypt::ssh://my.domain/home/admin/`
+
+But now I get only unresolved symbolic links for each files, that is .git/annex/objects directory only contains .map files.
+
+Would you have an idea about the reason/source of this behavior?
+
+Thank you so much,
+Guillaume
+"""]]
diff --git a/doc/forum/v5_to_v6_upgrade_strategy.mdwn b/doc/forum/v5_to_v6_upgrade_strategy.mdwn
new file mode 100644
index 0000000000..9a34b01e3a
--- /dev/null
+++ b/doc/forum/v5_to_v6_upgrade_strategy.mdwn
@@ -0,0 +1,21 @@
+I have recently jumped into git-annex, and have several TB stored in several remote annexes.
+I am able to sync to clients, and have some understanding of the operations needed to get files back etc.
+
+So far I have used v5 in Ubuntu and Debian 8. I have tried out assistant but will leave this until I better understand how git-annex works. CLI is best for this learning. 
+
+I am however concerned re the upgrade path from v5 to v6. I have not been able to find a comprehensive strategy. I have tried git-annex v6 and have upgraded a client repo to v6.
+
+All of my remote repos are v5, and to be honest I am very nervous about touching them.
+
+I do have a test bed where I try out all things before doing so on my 'production' repos. So, I can play, break, redo, in safety.
+
+Any direction as to formulating a game plan for upgrading my whole network of repos, clients, etc would be very much appreciated.
+
+And, if I have missed this, a pointer would be good for sure.
+
+
+Regards,
+
+Stan
+
+While it is obvious to all: this is amazing software. Genius.
diff --git a/doc/forum/v5_to_v6_upgrade_strategy/comment_1_1505166c806ab3d1a3148a245faa713a._comment b/doc/forum/v5_to_v6_upgrade_strategy/comment_1_1505166c806ab3d1a3148a245faa713a._comment
new file mode 100644
index 0000000000..68c9c52807
--- /dev/null
+++ b/doc/forum/v5_to_v6_upgrade_strategy/comment_1_1505166c806ab3d1a3148a245faa713a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="upgrades instruction"
+ date="2016-06-23T14:44:18Z"
+ content="""
+since you haven't explicitly mentionned it, i'll just mention a pointer to the [[upgrades]] page which has specific instructions regarding upgrading repositories to the v6 layout.
+
+as far as I know, you can just upgrade the git-annex *program* itself harmlessly. it will *not* upgrade your repositories without you deliberately running [[git-annex-upgrade]].
+
+then [[git-annex-upgrade]] will operate changes, but only on direct mode repositories, as far as i can tell. those repositories are switched to [[design/adjusted branches]], which have their own set of issues right name, mostly limitations with the webapp but have also seen a few bugfixes on crippled filesystems recently.
+
+i am personnally doing the \"wait and see\" game especially considering my specific use case for v6 ([[todo/hide_missing_files/]]) has not been completely implemented yet. but I am of course using 6.x binaries without problems.
+
+i am not the git-annex author, so take my comments with a grain of salt of course. :) --[[anarcat]]
+"""]]
diff --git a/doc/forum/v5_to_v6_upgrade_strategy/comment_2_ef2648a58037b867e2d745eb4b3a15a2._comment b/doc/forum/v5_to_v6_upgrade_strategy/comment_2_ef2648a58037b867e2d745eb4b3a15a2._comment
new file mode 100644
index 0000000000..e39d8f2688
--- /dev/null
+++ b/doc/forum/v5_to_v6_upgrade_strategy/comment_2_ef2648a58037b867e2d745eb4b3a15a2._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Stan"
+ subject="comment 2"
+ date="2016-06-28T23:10:07Z"
+ content="""
+Many thanks for the reply. I did not add too much detail to my post as it was my first, and I was a bit shy.
+
+I did do all of the steps indicated re v6. The binary has been fine for me also.
+
+My question is a bit more complex as I am looking to apply v6 at some point to a set of distributed repos. Essentially it has the typical duplicated system topology: 2 remotes, several clients, each of which is linked to both remotes. Thus it will survive multiple failure scenarios.
+
+I would be looking at the strategy of the order of repo upgrade. Say, a client first, and run a set of tests. And so on. Remotes last perhaps.
+
+In any case I built a test bed as above and have been experimenting with a single client at a v6 repo.
+
+So far it has been smooth, but right now I seem to be stuck where thinning is not having any effect: I still have a particular big file (1.5GB) in both the annex and the working dir. Lock remove the big file from the working dir, and leaves a link, and unlock restores the big file in the working dir. Yet, the annex still contains the big file no matter what. I was under the expectation that one of the big file copies would go away.
+"""]]
diff --git a/doc/forum/v5_to_v6_upgrade_strategy/comment_3_46fb3f5b0a7fa13b6f16ccb9832dac7e._comment b/doc/forum/v5_to_v6_upgrade_strategy/comment_3_46fb3f5b0a7fa13b6f16ccb9832dac7e._comment
new file mode 100644
index 0000000000..189b50aefc
--- /dev/null
+++ b/doc/forum/v5_to_v6_upgrade_strategy/comment_3_46fb3f5b0a7fa13b6f16ccb9832dac7e._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-07-06T18:50:34Z"
+ content="""
+I'd encourage you to not upgrade any production repositories to v6 yet.
+It's still in beta state and has known problems. Currently all known
+problems are only innefficiencies, but there could also still be bugs.
+
+When you do upgrade, you can upgrade your distibuted set of repos
+peicemeal. v5 and v6 fully interoperate, until you start unlocking files in
+the v6 clones of the repo. Once those unlocks get committed, the v5 clones
+of the repo won't be able to access the unlocked file contents, and you'll
+need to upgrade the clones then.
+
+At some point in the future, I expect v6 mode to be done and then git-annex
+will automatically upgrade for you. So the easist approach is to just wait
+for that.
+
+(Not addressing your problems with annex.thin here as you filed a separate
+forum post and bug report about that.)
+"""]]
diff --git a/doc/forum/v6_thinning_seems_to_be_not_working_for_me.mdwn b/doc/forum/v6_thinning_seems_to_be_not_working_for_me.mdwn
new file mode 100644
index 0000000000..a87421dd32
--- /dev/null
+++ b/doc/forum/v6_thinning_seems_to_be_not_working_for_me.mdwn
@@ -0,0 +1,42 @@
+git-annex version: 6.20160524+gitg2b7b2c4-1~ndall+1
+
+repo config:
+
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+[annex]
+	uuid = c5c203ec-9353-4213-8af5-6fcb8de36ca2
+	version = 6
+	thin = true
+[filter "annex"]
+	smudge = git-annex smudge %f
+	clean = git-annex smudge --clean %f
+
+
+
+copied a big file to the working directory
+
+git add
+git commit
+
+
+Locking the big file creates the symlink, with the file in the annex.
+
+Unlocking the big file creates a real file in the working dir, and the annex file stays there.
+
+The total dir is therefore twice the size of the big file.
+
+ls -li shows a unique inode for each file.
+
+
+It seems thinning is not doing what I expected:
+
+Which is: unlocking a file creates a hard link in the working directory, linked to the annex file, with
+the resulting dir size being the size of the one big file.
+
+Are my expectations correct?
+
+Is there something I am missing?
diff --git a/doc/forum/v6_thinning_seems_to_be_not_working_for_me/comment_1_751e603141513faaa43abc38f3329a3e._comment b/doc/forum/v6_thinning_seems_to_be_not_working_for_me/comment_1_751e603141513faaa43abc38f3329a3e._comment
new file mode 100644
index 0000000000..7587a0d1d4
--- /dev/null
+++ b/doc/forum/v6_thinning_seems_to_be_not_working_for_me/comment_1_751e603141513faaa43abc38f3329a3e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-06T18:48:46Z"
+ content="""
+[[bugs/v6_appears_to_not_thin]] was also filed by you about this;
+so I'll followup there instead of here.
+"""]]
diff --git a/doc/forum/vanilla_git_repo_as_special_remote__63__.mdwn b/doc/forum/vanilla_git_repo_as_special_remote__63__.mdwn
new file mode 100644
index 0000000000..94fa548653
--- /dev/null
+++ b/doc/forum/vanilla_git_repo_as_special_remote__63__.mdwn
@@ -0,0 +1,27 @@
+Right now I have separate "normal" Git repositories and separate Git annex repositories and I would love to have Git annex track and sync everything for me. The problem I have is I'd like to use "real" Git content tracking for some data (ex: text files) where I'd like to get normal Git features with (ex: diff). I'd like to combine normal Git content tracking with Git annex location tracking and syncing if possible. Ideally the cost (ex: increased git repo size and git slowdown) of content tracking would not need to be propagated across the entire git annex network, just on repos that want it (just like git annex only copies content to clients who want it and symlink the rest).
+
+The largefiles config provides a mechanism to add content to git directly in git annex, but that cost would be applied across the entire network, not opt-in per client.
+
+Ideally I'd like this situation:
+
+1. Git annex tracking everything as symlinks. No content is checked into these git repos.
+2. A subset of git annex content (ex: subfolder) synced to a normal remote non-annex git repository (ex: GitHub). This Git repo has content tracked in git itself.
+
+And I could use the git annex repos to sync everything. Somehow the git annex repo would know that the #2 remote was a "special content git remote" and push any content updates as normal git content commits.
+
+Or an adjusted branch that had the content tracked and I could sync that content branch around to only the remotes where I wanted the content history stored in git (since adjusted branches don't seem to annex sync by default). But master would just track the symlinks of those files and be synced around to all annexes.
+
+Can adjusted branches do this somehow?
+
+Some references:
+
+* [[special_remotes/external]]
+* [[design/adjusted_branches]]
+* [[todo/hide_missing_files]]
+* [[tips/largefiles]]
+* [[submodules]]
+* [[forum/git-subtree_support__63__]]
+
+Thanks!
+
+-neocryptek
diff --git a/doc/forum/vanilla_git_repo_as_special_remote__63__/comment_1_67e186265ae21f2cd8451750152f2a6d._comment b/doc/forum/vanilla_git_repo_as_special_remote__63__/comment_1_67e186265ae21f2cd8451750152f2a6d._comment
new file mode 100644
index 0000000000..65397495a2
--- /dev/null
+++ b/doc/forum/vanilla_git_repo_as_special_remote__63__/comment_1_67e186265ae21f2cd8451750152f2a6d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-16T18:30:12Z"
+ content="""
+You can use bup as a special remote, which will store the content in a git
+repository. But, not in a form that git diff can be used with.
+
+[[git-annex-diffdriver]] can be used to make `git diff` work on annexed
+files. For example:
+
+	export GIT_EXTERNAL_DIFF="git-annex diffdriver -- diff -u --"
+"""]]
diff --git a/doc/forum/vanilla_git_repo_as_special_remote__63__/comment_2_6314256da98966f4c7d02aa0d6bf94ff._comment b/doc/forum/vanilla_git_repo_as_special_remote__63__/comment_2_6314256da98966f4c7d02aa0d6bf94ff._comment
new file mode 100644
index 0000000000..f463554031
--- /dev/null
+++ b/doc/forum/vanilla_git_repo_as_special_remote__63__/comment_2_6314256da98966f4c7d02aa0d6bf94ff._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="neocryptek@659edac901ffbc8e541a974f8f18987eeafc63bd"
+ nickname="neocryptek"
+ avatar="http://cdn.libravatar.org/avatar/d9bfdefa9b503f1ac4844a686618374e"
+ subject="comment 2"
+ date="2016-11-21T22:26:52Z"
+ content="""
+Right, though bup also requires installation on the server. I'm looking for a way to store content into a vanilla git repo (as I don't have permission to install anything custom on the server).
+
+Since I want to store the content outside of git annex, it feels like a special remote. Though ideally it would have human readable files like:
+
+* <https://git-annex.branchable.com/todo/dumb__44___unsafe__44___human-readable_backend/>
+
+But since it's git and not just a normal (single version) filesystem, it could dedupe and save previous versions. Is there an easy way to hook git up safely to the external remote protocol:
+
+* [[special_remotes/external]]
+"""]]
diff --git a/doc/forum/version_3_upgrade.mdwn b/doc/forum/version_3_upgrade.mdwn
new file mode 100644
index 0000000000..7fdbcbc805
--- /dev/null
+++ b/doc/forum/version_3_upgrade.mdwn
@@ -0,0 +1,9 @@
+after upgrading to git-annex 3, i'm stuck with diverging git-annex branches -- i didn't manage to follow this line in the directions:
+
+> After this upgrade, you should make sure you include the git-annex branch when git pushing and pulling.
+
+could you explain how to do that in a littel more detail? git pull seems to only merge master, although i have these ``.git/config`` settings:
+
+    [branch "git-annex"]
+    	remote = origin
+    	merge = git-annex
diff --git a/doc/forum/version_3_upgrade/comment_1_05fc9c9cad26c520bebb98c852c71e35._comment b/doc/forum/version_3_upgrade/comment_1_05fc9c9cad26c520bebb98c852c71e35._comment
new file mode 100644
index 0000000000..18746225e9
--- /dev/null
+++ b/doc/forum/version_3_upgrade/comment_1_05fc9c9cad26c520bebb98c852c71e35._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-08-17T01:33:08Z"
+ content="""
+It's ok that `git pull` does not merge the git-annex branch. You can merge it with `git annex merge`, or it will be done
+automatically when you use other git-annex commands.
+
+If you use `git pull` and `git push` without any options, the defaults will make git pull and push the git-annex branch automatically.
+
+But if you're in the habit of doing `git push origin master`, that won't cause the git-annex branch to be pushed (use `git push origin git-annex` to manually push it then). Similarly, `git pull origin master` won't pull it. And also, the `remote.origin.fetch` setting in `.git/config` can be modified in ways that make `git pull` not automatically pull the git-annex branch. So those are the things to avoid after upgrade to v3, basically.
+"""]]
diff --git a/doc/forum/version_5_repo_with_version_6_repo.mdwn b/doc/forum/version_5_repo_with_version_6_repo.mdwn
new file mode 100644
index 0000000000..d9b4aba7a8
--- /dev/null
+++ b/doc/forum/version_5_repo_with_version_6_repo.mdwn
@@ -0,0 +1,3 @@
+I've found that when a file is unlocked in a v6 repo, syncing with a v5 repo causes the file in the v5 repo to be a symlink-replacement file (the file contents are, e.g., /annex/objects/SHA256E-s10--114811b0b8998cb9853a5379598021410feddf69bb2ee7b7145d052a7e9b5d45). I'm wondering if this is a bug, or just something that users should be aware of.
+Thanks for Git Annex---I really enjoy it!
+--Andy
diff --git a/doc/forum/version_5_repo_with_version_6_repo/comment_1_95037082d15758d7b2c23ad041d7f6f0._comment b/doc/forum/version_5_repo_with_version_6_repo/comment_1_95037082d15758d7b2c23ad041d7f6f0._comment
new file mode 100644
index 0000000000..0e7d17a20e
--- /dev/null
+++ b/doc/forum/version_5_repo_with_version_6_repo/comment_1_95037082d15758d7b2c23ad041d7f6f0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-10-31T17:04:42Z"
+ content="""
+It's something that users need to be aware of if mixing use of v6 and v5
+repositories and unlocking files. 
+
+Of course, if it becomes a problem, you can simply lock the files in the v6
+repository and then the v5 repo will be able to access them via symlinks
+again.
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives.mdwn b/doc/forum/very_slow_on_exfat_drives.mdwn
new file mode 100644
index 0000000000..718b008a5b
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives.mdwn
@@ -0,0 +1,7 @@
+I want to use git-annex to keep track of and archive of large tarballs (on the order of 10 to 100GB each).
+One of the locations are a set of external HDDs that are formatted to exFAT.
+
+Unfortunately every git command takes hours to execute.
+e.g. every time I use `git status` the index is refreshed which takes about 3 hours, committing a single takes similarly long.
+
+Is there anything I can do to speed things up?
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_10_5f67c870fc7e43ae75d8e1f8ced975c2._comment b/doc/forum/very_slow_on_exfat_drives/comment_10_5f67c870fc7e43ae75d8e1f8ced975c2._comment
new file mode 100644
index 0000000000..df1ebb3e7c
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_10_5f67c870fc7e43ae75d8e1f8ced975c2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="imlew"
+ avatar="http://cdn.libravatar.org/avatar/23858c3eed3c3ea9e21522f4c999f1ed"
+ subject="thank you"
+ date="2023-11-17T11:43:39Z"
+ content="""
+Makes sense.
+Thanks again, you've helped me a lot.
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_11_65460ed123404478ae59fed1b5cff627._comment b/doc/forum/very_slow_on_exfat_drives/comment_11_65460ed123404478ae59fed1b5cff627._comment
new file mode 100644
index 0000000000..5b4cac8ac2
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_11_65460ed123404478ae59fed1b5cff627._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2023-11-29T17:36:28Z"
+ content="""
+What might be happening on the exfat drive is, every time that filesystem
+is mounted, it generates new inode numbers for all the files. So when you
+run `git status`, git sees the new inode and needs to do work to determine
+if it's changed. When the file is an annexed file that is unlocked (which
+all annexed files necessarily are on this filesystem since it doesn't
+support symlinks), git status needs to ask git-annex about it.
+And git-annex has to either re-hash the file (for SHA) or do a
+smaller amount of work (for WORM).
+
+A bare repository does get around that. But what I tend to use in these
+situations is a [[/special_remotes/directory]] special remote configured
+with `ignoreinodes=yes`.
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_12_77cd7b20abd0cd1eadee0ebeb186b3cf._comment b/doc/forum/very_slow_on_exfat_drives/comment_12_77cd7b20abd0cd1eadee0ebeb186b3cf._comment
new file mode 100644
index 0000000000..e99a4e1093
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_12_77cd7b20abd0cd1eadee0ebeb186b3cf._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="imlew"
+ avatar="http://cdn.libravatar.org/avatar/23858c3eed3c3ea9e21522f4c999f1ed"
+ subject="comment 12"
+ date="2023-12-12T11:56:05Z"
+ content="""
+Hi joey,
+
+if it was slow because the inodes changed it should only be slow the first time `git status` etc are run.
+What I experienced was that it got slower the more files were in the repo whie the drive was continuously connected.
+
+
+Thanks for your suggestion to use a directory special remote, but it's not clear to me how that would be an improvement over a bare repo.
+The only drawback to using a bare repo is the lack of a working tree and special remotes don't seem to have that either.
+
+
+
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_13_1d6588477082dd6de6eaad02fdc53463._comment b/doc/forum/very_slow_on_exfat_drives/comment_13_1d6588477082dd6de6eaad02fdc53463._comment
new file mode 100644
index 0000000000..d99d5b0a61
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_13_1d6588477082dd6de6eaad02fdc53463._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 13"
+ date="2023-12-12T12:44:38Z"
+ content="""
+A directory special remote is just a bunch of files. A bare repo has the git history and all the metadata for the bunch of files. Git itself on slow and bad filesystems is not fun and git-annex having to comb through many git objects to extract metadata for the actual annexed files is most likely the bottleneck here. Best is to not run any git-annex commands directly on the bad filesystem, but elsewhere and operate the bad filesystem repo as a remote. Then you let git-annex gather its information on a fast filesysetm and hardware and let it do only the copying of real files to and from the bad filesystem. At least that's my experience.
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_14_6487a9a170f7caa7c9db06ac3bee8c0e._comment b/doc/forum/very_slow_on_exfat_drives/comment_14_6487a9a170f7caa7c9db06ac3bee8c0e._comment
new file mode 100644
index 0000000000..47e1d68d76
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_14_6487a9a170f7caa7c9db06ac3bee8c0e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="imlew"
+ avatar="http://cdn.libravatar.org/avatar/23858c3eed3c3ea9e21522f4c999f1ed"
+ subject="comment 14"
+ date="2023-12-12T13:36:20Z"
+ content="""
+The speeds reported by `get` and `copy` were similar to what `rsync` reports when I just copy files to and from the disks.
+It was really just the work tree (and I guess the clean/smudge filters) being slow.
+
+And bare repos have the advantage that they carry for metadata and possibly file history.
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_15_1d7c3ff1eaeffe03fe7e3e25af822e4e._comment b/doc/forum/very_slow_on_exfat_drives/comment_15_1d7c3ff1eaeffe03fe7e3e25af822e4e._comment
new file mode 100644
index 0000000000..560beff222
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_15_1d7c3ff1eaeffe03fe7e3e25af822e4e._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 15"
+ date="2023-12-12T19:25:16Z"
+ content="""
+The fact of the matter is that HDDs have gotten shittier during the past decade or so because most of them
+(except for sizes above 8TB and drives meant for the enterprise) already employ SMR (shingled magnetic recording)
+instead of conventional recording techniques. It seems SMR is poison to all sorts of workloads having
+small files and directories being rewritten (not that drives employing it have sequential speeds that are exactly
+stellar either) like what git and git-annex are doing under the hood. I bought an 6TB WD Elements desktop drive recently
+(knowingly an SMR unit because non-SMR HDDs are rather expensive here in Finland) as an git-annex archival drive and I was
+flabbergasted at how slow it turned out for merely syncing git metadata. I'm on Windows and have to use adjusted-unlocked
+branches so there's that but NTFS on Windows is not terribly slow -- maybe not as speedy as Linux filesystems but it caches
+metadata rather well, so it's ok. The problem is that while my 4TB Seagate IronWolf non-SMR drive (git-annex) syncs
+in a minute or two, my new 6TB takes a minimum of *ten* minutes or so to do that. At this point I have just resigned myself
+to the fact that all my future archival drives where I use regular git remotes will be slow as molasses. I'd love to own
+big, fast non-SMR enterprise drives but those will be outside my budget for years to come, I'm afraid. :/
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_1_0f16c72ed7bcba01398b36cb8b3cee08._comment b/doc/forum/very_slow_on_exfat_drives/comment_1_0f16c72ed7bcba01398b36cb8b3cee08._comment
new file mode 100644
index 0000000000..8d94f7094a
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_1_0f16c72ed7bcba01398b36cb8b3cee08._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="imlew"
+ avatar="http://cdn.libravatar.org/avatar/23858c3eed3c3ea9e21522f4c999f1ed"
+ subject="I guess this question is about backends"
+ date="2023-11-16T12:51:59Z"
+ content="""
+As so often happens, search the docs for hours and don't find anything and right after I asking the question I found a (seemingly) relevant page I had somehow missed before.
+
+In this case [backends](https://git-annex.branchable.com/backends/).
+
+Creating a new annex repo on a drive that already had the data but no repo and changing the backend to `WORM` (with `git config --local --add annex.backend WORM`) seems to have made things a little bit faster. Adding the first 3.5GB file in just under 2 minutes and `git status` returning after 44 seconds when first run and thereafter returning instantaneously. However adding all ~3TB in the repo is shaping up to take multiple days anyway.
+
+Is there anything else I've missed? I don't see what could be taking so long if all that is being checked is mtime, name and size.
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_2_769b971263b9124ec08079336d03869d._comment b/doc/forum/very_slow_on_exfat_drives/comment_2_769b971263b9124ec08079336d03869d._comment
new file mode 100644
index 0000000000..b2be94d837
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_2_769b971263b9124ec08079336d03869d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2023-11-16T15:54:08Z"
+ content="""
+Normally, using a bare repo helps on slow hardware/filesystems. This means making yokr repo on the HDD a bare repo, then adding your files somewhere else, where it's fast, and having git annex sync it over to the HDD. Uncool, but it seems lile exFAT or your HDD is rather on the shitty side. File size shouldn't matter much, the amount of files is often a problem.
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_3_b6ee8c6384c73b44ae9ccc0ba32c3135._comment b/doc/forum/very_slow_on_exfat_drives/comment_3_b6ee8c6384c73b44ae9ccc0ba32c3135._comment
new file mode 100644
index 0000000000..5ecf5e9309
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_3_b6ee8c6384c73b44ae9ccc0ba32c3135._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 3"
+ date="2023-11-16T15:55:49Z"
+ content="""
+Ah, and make sure you're not on an adjusted-unlocked branch. And only use locked files. If exFAT can't do symlinks properly, that might be the problem. Unlocked gigantic files are also a bottleneck.
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_4_b1dbbf57a46c79e8e32885c2ee8f45d2._comment b/doc/forum/very_slow_on_exfat_drives/comment_4_b1dbbf57a46c79e8e32885c2ee8f45d2._comment
new file mode 100644
index 0000000000..27486cb3de
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_4_b1dbbf57a46c79e8e32885c2ee8f45d2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 4"
+ date="2023-11-16T16:34:12Z"
+ content="""
+Yep, apparently, [exFAT can't do symlinks](https://superuser.com/questions/232257/does-or-will-exfat-support-symlinks).
+
+In general, it is best to use git-annex on non-shitty filesystems or one will run into problems with their limitations -- something git-annex can't really do much about.
+
+But you can work around it by using a bare git repository on the HDD as I mentioned above (see [here](https://stackoverflow.com/a/2200662) for how to do that) or to use the HDD just as a directory/rsync special remote from other git-annex repos. In both cases, symlinks are not needed and no expensive slow piping through smudge/clean filters is done. The downside is that you can't work (i.e. add, read, modify files) directly on the HDD, but you only use it as a storage drive.
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_5_ec5d339021f2a26942248962ea818a80._comment b/doc/forum/very_slow_on_exfat_drives/comment_5_ec5d339021f2a26942248962ea818a80._comment
new file mode 100644
index 0000000000..6c36556513
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_5_ec5d339021f2a26942248962ea818a80._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="imlew"
+ avatar="http://cdn.libravatar.org/avatar/23858c3eed3c3ea9e21522f4c999f1ed"
+ subject="not about backends after all"
+ date="2023-11-17T08:09:22Z"
+ content="""
+Thanks for your help. 
+I've created a bare repo on one of the drives that didn't have a repo yet and have been moving the files to my laptops internal drive to add and commit and then back with `git annex move`, this seems to be working much better. (I already have more than half the files in the repo after one night, previously I had left it running for days and couldn't get that far. (And yes, the drives are very slow.))
+
+re the filesystems, I thought so, but unfortunately these have to compatible with both mac and windoze...
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_6_a6c5e8dc86ed6b4b5ff45f66f5bad50a._comment b/doc/forum/very_slow_on_exfat_drives/comment_6_a6c5e8dc86ed6b4b5ff45f66f5bad50a._comment
new file mode 100644
index 0000000000..4bb4cb5291
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_6_a6c5e8dc86ed6b4b5ff45f66f5bad50a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="imlew"
+ avatar="http://cdn.libravatar.org/avatar/23858c3eed3c3ea9e21522f4c999f1ed"
+ subject="one more question"
+ date="2023-11-17T08:23:32Z"
+ content="""
+I'm not sure if this is caused by the disk's repo being bare, but after I have `git annex move`d a file there I still need to run `git annex sync` in the local source repo before I can find or copy the file to a third repo (in this case a second repo on my laptop).
+
+This is a little confusing because it seems the bare repo on the disk doesn't know it has the files that have been moved to it.
+
+Is this because it is bare, am I doing something wrong or why doesn't `git annex move` result in the target knowing that it has a given file?
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_7_3e66ef8493d2839cb26418788c510463._comment b/doc/forum/very_slow_on_exfat_drives/comment_7_3e66ef8493d2839cb26418788c510463._comment
new file mode 100644
index 0000000000..d8f8111ed4
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_7_3e66ef8493d2839cb26418788c510463._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 7"
+ date="2023-11-17T08:45:56Z"
+ content="""
+I'm not sure exactly what you mean. If you `git annex move`d a file from a local repo to the bare repo on the HDD, your local repo should know about this immediately. I'm not sure if an immediate `git annex move` *on the HDD* afterwards knows about this. Sounds like it should but maybe it doesn't for performance reasons. That would explain the need for a subsequent `sync`. In general, I would recommend setting up preferred content expressions for each repo, and then always just run `git annex assist` to have it sync everything. Slower than manual moving and copying though, but less worrying.
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_8_ae7380ff84e4200985c22deb647853e3._comment b/doc/forum/very_slow_on_exfat_drives/comment_8_ae7380ff84e4200985c22deb647853e3._comment
new file mode 100644
index 0000000000..5cccc65493
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_8_ae7380ff84e4200985c22deb647853e3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="imlew"
+ avatar="http://cdn.libravatar.org/avatar/23858c3eed3c3ea9e21522f4c999f1ed"
+ subject="comment 8"
+ date="2023-11-17T09:41:19Z"
+ content="""
+To try out accessing the file from another location I created a second repo on my laptop.
+So I have the \"real\" local repo (`L`), the repo on the disk (`D`) and another local repo for testing (`T`).
+In `L` I added and committed `$FILE` and then moved it to `D`.
+If I now run `git annex whereis $FILE` in all the repos
+`L` tells me it's in `D`, while both `D` and `T` tell me the file isn't know to git. 
+Only when I run `git annex sync` in `L` does `T` know and `D` still doesn't.
+
+Not a big issue, just a little suprising, but it's fine to have to remember to run `sync` in the local repo before disconnecting the disk.
+
+I have started looking into preferred content and groups and I will most likely use them. At least to begin with I want to try doing things manually and then later on move on to the more sophisticated tools.
+
+"""]]
diff --git a/doc/forum/very_slow_on_exfat_drives/comment_9_5b69d3cb7d3a51ce8a9cbdb608be676c._comment b/doc/forum/very_slow_on_exfat_drives/comment_9_5b69d3cb7d3a51ce8a9cbdb608be676c._comment
new file mode 100644
index 0000000000..f8a4c883ae
--- /dev/null
+++ b/doc/forum/very_slow_on_exfat_drives/comment_9_5b69d3cb7d3a51ce8a9cbdb608be676c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 9"
+ date="2023-11-17T09:49:02Z"
+ content="""
+Alright, that's how it's supposed to be. Copying files around and keeping track of the locations are two separate things. The location tracking, metadata, etc. are stored in the `git-annex`-branch, which is only synced with `git annex sync` or `git annex assist`. If you're on the manual route (i.e. no preferred content, no `git annex sync --content`, no `git annex assist`), then you are supposed to sync the git repos yourself, e.g. with `git annex sync`. It also makes sense from a performance standpoint. git syncing can be slow, especially on slow hardware. Maybe you don't want to sync the metadata after every copy/move/drop/etc., but you batch it up. And as long as the info where the files are is *somewhere* in a `git-annex`-branch (e.g. your local repo `L`), it's fine as it will eventually be synced around.
+"""]]
diff --git a/doc/forum/view_from_numeric_values.mdwn b/doc/forum/view_from_numeric_values.mdwn
new file mode 100644
index 0000000000..e1fc48a0f2
--- /dev/null
+++ b/doc/forum/view_from_numeric_values.mdwn
@@ -0,0 +1,9 @@
+Hi Joey,
+
+it would be nice when views could take numeric comparisons as filters.
+
+    git annex metadata -s length=273.0 john_cage_4_33.mp3
+
+    git annex view length<=300
+
+... here is the catch, < and > don't work well in shell, this needs some other Syntax. I think the underlying machinery (using numeric comparisons instead globs) should be quite trivial. Any Ideas about a Syntax?
diff --git a/doc/forum/view_from_numeric_values/comment_1_f3c440f3f0104002a0020ba96ddcf87b._comment b/doc/forum/view_from_numeric_values/comment_1_f3c440f3f0104002a0020ba96ddcf87b._comment
new file mode 100644
index 0000000000..4df3034a2d
--- /dev/null
+++ b/doc/forum/view_from_numeric_values/comment_1_f3c440f3f0104002a0020ba96ddcf87b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="cehteh"
+ ip="217.8.62.137"
+ subject="consistent syntax"
+ date="2014-03-25T15:25:43Z"
+ content="""
+Further thinking led to the idea to use the test(1) like syntax to filter matches.
+
+    git annex view length=.* -lt 300 -gt 30 -o -eq 273 bpm=.* -eq 0
+
+"""]]
diff --git a/doc/forum/view_from_numeric_values/comment_2_2414e1a8cfd154c339d8fc0e4a630ae9._comment b/doc/forum/view_from_numeric_values/comment_2_2414e1a8cfd154c339d8fc0e4a630ae9._comment
new file mode 100644
index 0000000000..ff4fcc551f
--- /dev/null
+++ b/doc/forum/view_from_numeric_values/comment_2_2414e1a8cfd154c339d8fc0e4a630ae9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.41"
+ subject="comment 2"
+ date="2014-03-26T17:53:28Z"
+ content="""
+I'm a little bit worried about the potential to reinvent SQL, badly. ;)
+
+As shown in your example, once you have ranges, it's natural to also want disjunctions, and then probably parenthesized expressions, and suddenly things are very complicated.
+
+Also, it's important that views remain reversable, so that committing a moved file in a view can unambiguously calculate the new metadata for it. I think that quickly becomes hard when adding these complications.
+"""]]
diff --git a/doc/forum/view_from_numeric_values/comment_3_7879a11cc9767cdaac14f9993182dc25._comment b/doc/forum/view_from_numeric_values/comment_3_7879a11cc9767cdaac14f9993182dc25._comment
new file mode 100644
index 0000000000..da6dded172
--- /dev/null
+++ b/doc/forum/view_from_numeric_values/comment_3_7879a11cc9767cdaac14f9993182dc25._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="cehteh"
+ ip="217.8.62.137"
+ subject="comment 3"
+ date="2014-03-26T18:55:41Z"
+ content="""
+I'm a little bit worried about the potential to reinvent SQL, badly. ;)
+
+As shown in your example, once you have ranges, it's natural to also want disjunctions, and then probably parenthesized expressions, and suddenly things are very complicated.
+
+Also, it's important that views remain reversable, so that committing a moved file in a view can unambiguously calculate the new metadata for it. I think that quickly becomes hard when adding these complications.
+
+"""]]
diff --git a/doc/forum/view_from_numeric_values/comment_4_517c7659654a6fc608eb3332053df8a4._comment b/doc/forum/view_from_numeric_values/comment_4_517c7659654a6fc608eb3332053df8a4._comment
new file mode 100644
index 0000000000..90cb1c22a9
--- /dev/null
+++ b/doc/forum/view_from_numeric_values/comment_4_517c7659654a6fc608eb3332053df8a4._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="cehteh"
+ ip="217.8.62.137"
+ subject="comment 4"
+ date="2014-03-26T20:03:51Z"
+ content="""
+I agree with you that things must stay simple. All what should be done is having the same effects like normal globs but adding arithmetic comparisons to it (could you think about a globbing extension over numeric values?). Then the generated views will have the same properties/semnatic as the normal glob'ed views without other side effects (if you want to go that far, this would even hold true for disjunct, parenthesized and otherwise complex expression).
+
+Example (how it should work, except my bug report 'set metadata on wrong files')
+
+    git annex metadata a.txt -s foo=bar -s num=1
+    git annex metadata b.txt -s foo=baz -s num=2
+    git annex metadata c.txt -s foo=barf -s num=3
+
+    git annex view foo=bar* num=* -ne 2
+
+should give
+    ./bar/1/a.txt ./barf/3/c.txt
+
+am I right now than one could
+
+    mkdir -p ./baz/2
+    mv /bar/1/a.txt ./baz/2
+
+to change the metadata of a.txt, despite the foo=baz and num=2 fields where initially filtered out when creating the view?
+If this assumption is true then having arithmetic filters, no matter how complex they are won't change the existing semantics over what globs do.
+
+"""]]
diff --git a/doc/forum/view_including_files_with_no_tags.mdwn b/doc/forum/view_including_files_with_no_tags.mdwn
new file mode 100644
index 0000000000..7ed64fc7df
--- /dev/null
+++ b/doc/forum/view_including_files_with_no_tags.mdwn
@@ -0,0 +1,5 @@
+Hi
+
+Is it possible to create a view which also includes files with no tag?
+
+I use something like `git annex view 'rating=*'` to view files sorted by rating but this view does not include files which don‘t have a rating yet. What I was looking for is a way to show tagged files and untagged files in one view.
diff --git a/doc/forum/view_including_files_with_no_tags/comment_1_b0aafc023fbec33af268576c4c199af3._comment b/doc/forum/view_including_files_with_no_tags/comment_1_b0aafc023fbec33af268576c4c199af3._comment
new file mode 100644
index 0000000000..ec58308b75
--- /dev/null
+++ b/doc/forum/view_including_files_with_no_tags/comment_1_b0aafc023fbec33af268576c4c199af3._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="87.194.19.134"
+ subject="comment 1"
+ date="2014-03-25T08:54:23Z"
+ content="""
+This is a TODO:
+
+http://git-annex.branchable.com/design/metadata/
+
+    unmatched files in filtered branches
+
+    TODO Files not matching the view should be able to be included in the filtered branch, in a special location, an \"other\" directory.
+
+In the meantime, I do this before switching to the view:
+
+    git annex metadata -s fieldIwant?=untagged
+
+This shows the files without any \"fieldIwant\" in the directory \"untagged\". Afterwards, I could (but don't need to in my workflow, it automatically gets removed), do this to remove it:
+
+    git annex metadata -s fieldIwant-=untagged
+
+What the \"?=\" does is add that metadata only if the \"fieldIwant\" hasn't been set at all.
+"""]]
diff --git a/doc/forum/view_including_files_with_no_tags/comment_2_5ae9d5308371bdb1f94342c9f9b01aff._comment b/doc/forum/view_including_files_with_no_tags/comment_2_5ae9d5308371bdb1f94342c9f9b01aff._comment
new file mode 100644
index 0000000000..3f16a163f8
--- /dev/null
+++ b/doc/forum/view_including_files_with_no_tags/comment_2_5ae9d5308371bdb1f94342c9f9b01aff._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://ypid.wordpress.com/"
+ ip="213.153.84.215"
+ subject="Perfect"
+ date="2014-03-25T20:11:26Z"
+ content="""
+This works great. Nice workaround, thanks very much.
+"""]]
diff --git a/doc/forum/views___40__branches__41___never_get_deleted.mdwn b/doc/forum/views___40__branches__41___never_get_deleted.mdwn
new file mode 100644
index 0000000000..bba7762dae
--- /dev/null
+++ b/doc/forum/views___40__branches__41___never_get_deleted.mdwn
@@ -0,0 +1,16 @@
+Hello everyone,
+I would like to know if this is normal behavior or if it's a problem with my repository:
+
+Whenever I set a view with 
+
+git annex view attr="\*"'
+
+a new branch representing the selected view gets created, as expected. The problem is that when I switch back to master ('git checkout master' or even 'git annex vpop') the view branch stays there, and all subsequent operations on the annex also consider the view branch, resulting a great slowdown if one has done many views (attr="this", attr="that", etc.). Is this normal? If so, why is it necessary for the branch to stay on? Does it speed up going back to the branch? Redoing git annex view attr="*" does not seem to take less time. 
+
+Am I doing it wrong? Should I be deleting used view branches on my own? How?
+
+thanks for your replies.
+
+**EDIT:** I just found out that even if I delete view branches with git branch -D "views/attr=_" (which I'm not sure I should be doing), the branches are still checked when doing "git annex unused". That is, "git annex unused" lists "checking..." a whole lot of past views/branches which are not even there anymore (not listed with "git branch"). I also suspect that this is preventing deleted (git-rm) files from being collected from "unused". Is this a problem with my repo? Any way to fix this?
+
+=== git-annex version: **5.20140529-gb71f9bf** ===
diff --git a/doc/forum/views___40__branches__41___never_get_deleted/comment_1_ff53fa0b5f0c4a6554a37e3309e26925._comment b/doc/forum/views___40__branches__41___never_get_deleted/comment_1_ff53fa0b5f0c4a6554a37e3309e26925._comment
new file mode 100644
index 0000000000..61fcbfeb47
--- /dev/null
+++ b/doc/forum/views___40__branches__41___never_get_deleted/comment_1_ff53fa0b5f0c4a6554a37e3309e26925._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-06-04T18:04:30Z"
+ content="""
+You can delete the view branches if you like. I have considered making moving views clean up old branches, but I have also considered reusing existing view branches when popping back to an old view.
+
+git-annex unused can't look at branches that aren't there. Perhaps you have pushed the view branches to a remote repository, and it's checking those branches of the remote? See git branch -a.
+
+I think that it makes sense for unused to ignore (local) view branches, since these are by definition supposed to be views of an existing branch, so looking at the branch should be sufficient (and if the view is out of date and has files that have since been deleted from the branch, the user's intent is not to preserve those from unused reaping). So, made that change.
+"""]]
diff --git a/doc/forum/views___40__branches__41___never_get_deleted/comment_3_1d4a3f4e83b288262e291262a6636602._comment b/doc/forum/views___40__branches__41___never_get_deleted/comment_3_1d4a3f4e83b288262e291262a6636602._comment
new file mode 100644
index 0000000000..0a5d61e548
--- /dev/null
+++ b/doc/forum/views___40__branches__41___never_get_deleted/comment_3_1d4a3f4e83b288262e291262a6636602._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmYMS6tQ8q9k1fylGyA9Q6fdFzRBotME2Q"
+ nickname="tom"
+ subject="EDIT reply comment:"
+ date="2014-06-04T19:44:18Z"
+ content="""
+> *You can delete the view branches if you like. I have considered making moving views clean up old branches, but I have also considered reusing existing view branches when popping back to an old view.*
+
+Alright, I'd very much welcome anyone of the two possibilities as I'm making heavy use of views and would benefit from any of the two solutions.
+
+> *Perhaps you have pushed the view branches to a remote repository, and it's checking those branches of the remote? See git branch -a.*
+
+That's it! Solution for future reference: The remote branches referenced in local repo did not exist anymore in any repo (I had deleted them earlier from the remote) so \"git push origin --delete \<branchname\>\" wouldn't work. This other command worked very well in cleaning up the overwhelming missing remote views all in one go: \"git fetch --prune \<remote\>\"
+
+> *I think that it makes sense for unused to ignore (local) view branches, since these are by definition supposed to be views of an existing branch, so looking at the branch should be sufficient. So, made that change.*
+
+Thanks a lot! It makes perfect sense, looking forward to it on the next release.
+
+Now, it seems that even after pruning the view branches on the remote, *unused* would still not collect deleted files. I'm wondering if this is because there are other offline repos (backups which are not practical to take out of their resting place) I have not yet synchronized. I can see their main branches with git branch -a: remotes/oldbackup/git-annex, remotes/oldbackup/master, remotes/oldbackup/synced/git-annex, remotes/oldbackup/synced/master. Does this mean that until all repos (even the offline ones I never sync and work mostly as a backup for old stuff) are synchronized, 'unused' won't collect the deleted files? If so, is there a workaround for this?
+
+"""]]
diff --git a/doc/forum/views___40__branches__41___never_get_deleted/comment_3_4e96e5325fd12e48f190fe551a6ac07e._comment b/doc/forum/views___40__branches__41___never_get_deleted/comment_3_4e96e5325fd12e48f190fe551a6ac07e._comment
new file mode 100644
index 0000000000..7ac31b1e9b
--- /dev/null
+++ b/doc/forum/views___40__branches__41___never_get_deleted/comment_3_4e96e5325fd12e48f190fe551a6ac07e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmYMS6tQ8q9k1fylGyA9Q6fdFzRBotME2Q"
+ nickname="tom"
+ subject="added comment"
+ date="2014-06-04T22:41:40Z"
+ content="""
+Specifically I'm looking for a workaround that would make this behavior possible in this use case:
+
+The user decides some file in the local repository are not needed anymore, they are not needed to be in any repository at all and wants to reclaim the space as soon as possible (or at least make the files available to 'unused' for later removal). Removing the content the from local repository (git-rm ?) the space can be immediately reclaimed in the local hard drive, without the need to connect and sync unavailable/far remotes. As the other remotes and old backups become available and sync, they delete the unused content as well (or at least make it available to 'unused').
+
+Is there a way to achieve this? 
+"""]]
diff --git a/doc/forum/views___40__branches__41___never_get_deleted/comment_4_a4764b5bfb08ebe90430ea14fcb6e8e0._comment b/doc/forum/views___40__branches__41___never_get_deleted/comment_4_a4764b5bfb08ebe90430ea14fcb6e8e0._comment
new file mode 100644
index 0000000000..762e4db533
--- /dev/null
+++ b/doc/forum/views___40__branches__41___never_get_deleted/comment_4_a4764b5bfb08ebe90430ea14fcb6e8e0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 4"
+ date="2014-06-05T17:35:31Z"
+ content="""
+`git annex drop --force $file; git rm $file`
+
+Makes sense in some situations anyway..
+"""]]
diff --git a/doc/forum/views___40__branches__41___never_get_deleted/comment_5_02e08dffb01246010b390aeef8f32234._comment b/doc/forum/views___40__branches__41___never_get_deleted/comment_5_02e08dffb01246010b390aeef8f32234._comment
new file mode 100644
index 0000000000..a9b72087e0
--- /dev/null
+++ b/doc/forum/views___40__branches__41___never_get_deleted/comment_5_02e08dffb01246010b390aeef8f32234._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmYMS6tQ8q9k1fylGyA9Q6fdFzRBotME2Q"
+ nickname="tom"
+ subject="comment 5"
+ date="2014-06-06T09:57:32Z"
+ content="""
+ah, I get it. Thanks!
+"""]]
diff --git a/doc/forum/vlc_and_git-annex.mdwn b/doc/forum/vlc_and_git-annex.mdwn
new file mode 100644
index 0000000000..cb07f8183c
--- /dev/null
+++ b/doc/forum/vlc_and_git-annex.mdwn
@@ -0,0 +1,11 @@
+I used to save movies with the srt subtitle files next to them. 
+
+Usually vlc finds it because it's on the same directory than the movie file, however with git annex the link is located on another folder.
+So after adding movies to git, the subtitles doesn't load anymore.
+
+couldn't find a quick fix. I'm thinking a bash script, but wanted to discuss it here with all annex users.
+
+I know It's out of annex scope, but I think a movie archive is a great scenario for git-annex.
+most of my HD is filled up with movies from the camcorder, screencast, etc... 
+And we usually don't modify those files
+
diff --git a/doc/forum/vlc_and_git-annex/comment_1_9c9ab8ce463cf74418aa2f385955f165._comment b/doc/forum/vlc_and_git-annex/comment_1_9c9ab8ce463cf74418aa2f385955f165._comment
new file mode 100644
index 0000000000..700b3808de
--- /dev/null
+++ b/doc/forum/vlc_and_git-annex/comment_1_9c9ab8ce463cf74418aa2f385955f165._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-12-23T16:16:19Z"
+ content="""
+From what you say, it seems that vlc is following the symlink to the movie content, and then looking for subtitles next to the file the symlink points to. It would have to explicitly realpath the symlink to have this behavior, and this sounds like a misfeature.. perhaps you could point out to the vlc people the mistake in doing so?
+
+There's a simple use-case where this behavior is obviously wrong, without involving git-annex. Suppose I have a movie, and one version of subtitles for it, in directory `foo`. I want to modify the subtitles, so I make a new directory `bar`, symlink the large movie file from `foo` to save space, and copy over and edit the subtitles from `foo`. Now I run vlc in `bar` to test my new subtitles. If it ignores the locally present subtitles and goes off looking for the ones in `bar`, I say this is broken behavior.
+"""]]
diff --git a/doc/forum/vlc_and_git-annex/comment_2_037f94c1deeac873dbdb36cd4c927e45._comment b/doc/forum/vlc_and_git-annex/comment_2_037f94c1deeac873dbdb36cd4c927e45._comment
new file mode 100644
index 0000000000..3c69f5fe46
--- /dev/null
+++ b/doc/forum/vlc_and_git-annex/comment_2_037f94c1deeac873dbdb36cd4c927e45._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-12-23T18:43:05Z"
+ content="""
+Since subtitle files are typically pretty small, a workaround is to simply check them into git directly, and only use git-annex for the movies. (Or `git annex unannex` the ones you've already annexed.)
+"""]]
diff --git a/doc/forum/walkthrough_report_setting_up_tor_p2p_remote.mdwn b/doc/forum/walkthrough_report_setting_up_tor_p2p_remote.mdwn
new file mode 100644
index 0000000000..c5d4962951
--- /dev/null
+++ b/doc/forum/walkthrough_report_setting_up_tor_p2p_remote.mdwn
@@ -0,0 +1,91 @@
+I set up synchronization between two new git-annex repositories via a webdav export remote for the files content and tor p2p for the git commits.
+
+The following notes apply to a Debian testing system with around 8.20200227. (I compile from source.)
+
+I wanted to understand what the individual setup steps are doing in detail. I hope I'll have time to contribute this into the documentation (man pages) or maybe motivate Joey to do some changes in the code.
+
+## git-annex enable-tor
+
+This is what the **enable-tor** command does:
+
+Be
+`hiddenServiceSocketFile=/var/lib/tor-annex/$(id -u)_$(git config --get annex.uuid)/s`
+
+- prepHiddenServiceSocketDir effectively does
+
+  `mkdir -p $(dirname $hiddenServiceSocketFile)`
+
+- adds two lines to /etc/tor/torrc
+
+  ```
+  HiddenServiceDir /var/lib/tor/tor-annex_$(id -u)_$(git config --get annex.uuid)
+  HiddenServicePort $newport unix:$hiddenServiceSocketFile
+  ```
+
+- restarts the tor service and waits for it to come back
+
+- parses the OnionAddress from the $HiddenServiceDir/hostname that tor should have written after restart
+
+- stores the OnionAddress and $newport into .git/annex/creds/p2paddrs
+
+### Comments to enable-tor
+
+- Why can't $newport be a fixed port? There will always only be one
+  HiddenservicePort per annex HiddenServiceDir.
+  
+  Confirmed in comment in Auth.hs:
+  
+  ```
+  -- We can omit the port and just use the onion address for the creds file,
+  -- because any given tor hidden service runs on a single port and has a
+  -- unique onion address.
+  ```
+
+- Wouldn't it be easier if git-annex-remotedaemon would just run a child tor
+  process? This way git-annex would fully control the config file and there were
+  no permission issues with the socket.
+
+- The path to the tor socket file is hard coded and git-remote-daemon can not be
+  instructed to use a different file. Thus it is not possible to explore
+  alternative setups, e.g. systemd user services.
+
+## git-annex-p2p --pair
+
+Man page: <https://git-annex.branchable.com/git-annex-p2p>
+
+I did not use the --pair option since it was unclear to me what exact Wormhole version was needed. Also it was to magic for me.
+So far I did the pairing only in one direction and still the synchronization seems to work at least in one direction. I don't remember ATM whether I also tested the other direction.
+
+### --gen-addresses
+
+- generates an auth token
+- stores the auth token in .git/annex/creds/p2pauth
+- prints some string to be passed to --link in another annex repo
+
+### --link
+
+- runs git remote add $remotename (formatP2PAddress addr)
+- storeUUIDIn (remoteAnnexConfig remotename "uuid") theiruuid
+  does effectively: git config --set remote.$remotename.annex-uuid theiruuid
+- storeP2PRemoteAuthToken addr authtoken
+  stores the auth token in .git/annex/creds/$onionaddr
+
+## git-annex remotedaemon, git-annex assistant
+
+Now I can start git-annex remotedaemon and the synchronization works.
+Also git-annex assistant works. However after killing the assistant, it seems that sometimes I needed to restart the remotedaemon, otherwise there was an error about some socket problem.
+
+## webdav export remote
+
+I needed some time to find out that I need to configure "annex-tracking-branch" for an export remote in order for the assistant to automatically sync file content.
+
+## Links
+
+- <https://git-annex.branchable.com/special_remotes/tor>
+- <https://git-annex.branchable.com/tips/peer_to_peer_network_with_tor>
+- <https://2019.www.torproject.org/docs/onion-services>
+- <https://riseup.net/en/security/network-security/tor/onionservices-best-practices>
+
+## Update 2020-03-16
+
+https://git-annex.branchable.com/bugs/p2p_auth_token_can_only_be_retrieved_at_generation_time
diff --git a/doc/forum/warning__58___remote_HEAD_refers_to_nonexistent_ref__44___unable_to_checkout.mdwn b/doc/forum/warning__58___remote_HEAD_refers_to_nonexistent_ref__44___unable_to_checkout.mdwn
new file mode 100644
index 0000000000..f57e0ee838
--- /dev/null
+++ b/doc/forum/warning__58___remote_HEAD_refers_to_nonexistent_ref__44___unable_to_checkout.mdwn
@@ -0,0 +1,69 @@
+I am struggling for so long time, everytime getting different errors :( :(
+
+I digged up my backup and started from scratch. Still not working.
+
+On the (linux) server (directory contains already files):
+
+     cd bin
+     git init
+     git annex init server
+     git annex direct
+     git annex add .
+
+Then, on the Windows client:
+
+     $ git clone ssh://me@server/srv/data/bin bin
+     Cloning into 'bin'...
+     warning: remote HEAD refers to nonexistent ref, unable to checkout.
+
+What's going on here?
+
+EDIT: Of course, I would not ask if everything would work as expected. But the client repository in windows is always empty, no matter what I do (issueing git annex init, git add remote, git annex sync, ...) does not seem to help me ...
+
+EDIT2: When I continue on the windows side (despite the warning):
+
+     cd bin
+     git annex init client
+     git annex sync
+     Permission denied (publickey,keyboard-interactive).
+     (merging origin/git-annex origin/synced/git-annex into git-annex...)
+     (Recording state in git...)
+     
+       Remote origin does not have git-annex installed; setting annex-ignore
+     commit  ok
+     pull origin Already up-to-date!
+     Merge made by the 'recursive' strategy.
+     
+     
+     ok
+     push origin To ssh://me@server/srv/data/bin
+        b79922f..4fe0505  git-annex -> synced/git-annex
+        2f6a601..02a2603  annex/direct/master -> synced/master
+     
+     ok
+
+
+But that's not true, git-annex is definitely installed on the server (it's just the Debian package and it resides in /usr/bin/git-annex). In any case, the client repository is still empty
+
+EDIT3: Struggle, struggle, ...
+
+Finally, for whatever reason, the client dir is not empty. What seems to be missing on the server was:
+
+     git annex sync
+
+but this is never written (also not in the walkthrough). Can anyone tell me if it's required and why?
+
+Furthermore, even that I "see" at least the file references now, I am not able to get them:
+
+     $ git annex get apps
+     get apps/gitignore (not available)
+       Try making some of these repositories available:
+             10d0ffd8-f499-4b55-83e6-ff58cd98edc5 -- server
+     
+       (Note that these git remotes have annex-ignore set: origin)
+     failed
+     git-annex: get: 1 failed
+
+That's an SSH remote, it *is* available! What is meant by that?
+
+
diff --git a/doc/forum/warning__58___remote_HEAD_refers_to_nonexistent_ref__44___unable_to_checkout/comment_1_c0d9758be80d1a349ffe82c80075bebd._comment b/doc/forum/warning__58___remote_HEAD_refers_to_nonexistent_ref__44___unable_to_checkout/comment_1_c0d9758be80d1a349ffe82c80075bebd._comment
new file mode 100644
index 0000000000..3601e2639c
--- /dev/null
+++ b/doc/forum/warning__58___remote_HEAD_refers_to_nonexistent_ref__44___unable_to_checkout/comment_1_c0d9758be80d1a349ffe82c80075bebd._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="171.67.174.99"
+ subject="comment 1"
+ date="2014-05-10T21:20:36Z"
+ content="""
+I think, although not sure, that all of this is related of failing/inconsistent ssh calls.
+
+I filed a bug here: https://git-annex.branchable.com/bugs/git-annex_ignores_GIT__95__SSH
+
+The problem is that failure in ssh does not result in proper error messages in git-annex, resulting in inconsistent repositories.
+"""]]
diff --git a/doc/forum/warning__58___remote_HEAD_refers_to_nonexistent_ref__44___unable_to_checkout/comment_2_c28dae2eb0ab825ee6d43735e04a18a3._comment b/doc/forum/warning__58___remote_HEAD_refers_to_nonexistent_ref__44___unable_to_checkout/comment_2_c28dae2eb0ab825ee6d43735e04a18a3._comment
new file mode 100644
index 0000000000..97671a2c52
--- /dev/null
+++ b/doc/forum/warning__58___remote_HEAD_refers_to_nonexistent_ref__44___unable_to_checkout/comment_2_c28dae2eb0ab825ee6d43735e04a18a3._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 2"
+ date="2014-05-16T16:49:09Z"
+ content="""
+After you add a file to a git repository, you have to git commit it. Using git-annex is no different. The walkthrough shows using `git commit`: <http://git-annex.branchable.com/walkthrough/adding_files/>; you can use `git-annex sync` if you prefer.
+
+<pre>
+Permission denied (publickey,keyboard-interactive).
+ (merging origin/git-annex origin/synced/git-annex into git-annex...)
+ (Recording state in git...)
+
+   Remote origin does not have git-annex installed; setting annex-ignore
+</pre>
+
+git-annex uses a heuristic to determine if git-annex-shell is not installed on a remote server: It tries to run it, and if that fails, it tries to run git fetch. If that succeeds it assumes this means it can log into the server, but git-annex-shell is not installed.
+
+Above, that heuristic seems to have failed; you seem to have given the wrong password or something so it didn't run git-annex-shell, but then it was able to log in for the git fetch. 
+
+You will need to run this command to fix it up: `git config remote.origin.annex-ignore false`
+"""]]
diff --git a/doc/forum/web-browser_for_the_repository.mdwn b/doc/forum/web-browser_for_the_repository.mdwn
new file mode 100644
index 0000000000..40a332b6e8
--- /dev/null
+++ b/doc/forum/web-browser_for_the_repository.mdwn
@@ -0,0 +1,10 @@
+Hi!
+
+I am a teacher and I would like to organize my school-files with git-annex in combination with a wiki. In the wiki I would like to outline lessons with included pictures (and links) of work-sheets etc. git-annex would help me to transfer and organize all the files. 
+
+Now I'm searching for a web-browser for a git-annex-repository, like the source-browser of trac (or gitweb). Actually I would really like to use trac (or dokuwiki) for my school-project. I tried trac with a bare-annex-repos, but it only shows the hash-links. In the web-assistent of annex I couldn't find such a feature.
+
+
+Is there any web-browser for a git-annex-repository?
+
+-- Tobias 
diff --git a/doc/forum/web-browser_for_the_repository/comment_1_1f8e7e54e9f377417cd672d66ae9bd9d._comment b/doc/forum/web-browser_for_the_repository/comment_1_1f8e7e54e9f377417cd672d66ae9bd9d._comment
new file mode 100644
index 0000000000..32296609a0
--- /dev/null
+++ b/doc/forum/web-browser_for_the_repository/comment_1_1f8e7e54e9f377417cd672d66ae9bd9d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Kalle"
+ subject="Different solution"
+ date="2016-03-21T21:02:57Z"
+ content="""
+Hi
+
+Are you able to install git-annex on the server? If so perhaps switching the server repo to **direct mode** will work. Then you should be able to use any directory listing method you like. My guess is that you need to make sure the file listing software is configured to ignore `.git` directories. I've never used TRAC so can't tell if this is possible or required.
+"""]]
diff --git a/doc/forum/web-browser_for_the_repository/comment_2_551d5bb2d24212de65720d796365177f._comment b/doc/forum/web-browser_for_the_repository/comment_2_551d5bb2d24212de65720d796365177f._comment
new file mode 100644
index 0000000000..dfee3959e5
--- /dev/null
+++ b/doc/forum/web-browser_for_the_repository/comment_2_551d5bb2d24212de65720d796365177f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Tobias"
+ subject="bare repository in direct mode"
+ date="2016-03-21T21:28:57Z"
+ content="""
+It is not possible to put a bare repository in direct mode. I tried it and it did not work. 
+
+Tobias
+"""]]
diff --git a/doc/forum/web-browser_for_the_repository/comment_3_d410df4b7160f17e3846674c3e0e9368._comment b/doc/forum/web-browser_for_the_repository/comment_3_d410df4b7160f17e3846674c3e0e9368._comment
new file mode 100644
index 0000000000..c84959a570
--- /dev/null
+++ b/doc/forum/web-browser_for_the_repository/comment_3_d410df4b7160f17e3846674c3e0e9368._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Kalle"
+ subject="comment 3"
+ date="2016-03-23T21:22:15Z"
+ content="""
+A normal direct mode repo with git annex installed on the server should give you a synced directory structure of files that you can browse with most directory listing software/modules and download files.
+
+Are you looking to enable something beyond browsing and downloading the files?
+"""]]
diff --git a/doc/forum/web-browser_for_the_repository/comment_4_d06217403bf53a713b845bbc9ca8b962._comment b/doc/forum/web-browser_for_the_repository/comment_4_d06217403bf53a713b845bbc9ca8b962._comment
new file mode 100644
index 0000000000..e0ce7359bc
--- /dev/null
+++ b/doc/forum/web-browser_for_the_repository/comment_4_d06217403bf53a713b845bbc9ca8b962._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Tobias"
+ subject="History"
+ date="2016-03-25T15:24:21Z"
+ content="""
+I'm not only interested in the current state of the files but also in a browser for the revisions. Therefore I need a \"real\" repository-browser. 
+"""]]
diff --git a/doc/forum/webapp__58___disabling_a_paired_repository.mdwn b/doc/forum/webapp__58___disabling_a_paired_repository.mdwn
new file mode 100644
index 0000000000..bc2c809c35
--- /dev/null
+++ b/doc/forum/webapp__58___disabling_a_paired_repository.mdwn
@@ -0,0 +1,12 @@
+I had two repositories, on different machines, created with the assistant, so they were both direct mode.
+
+After pairing each with the other, so that files were merrily flowing back and forth, I happened to do the following:
+ * on machine A, in the dashboard
+ * click on the 'actions' emnu for the repository on machine B
+ * select 'disable'
+
+Result: all references to the repo on machine B have disappeared from the assistant in machine A.
+
+On machine B, I still have the pairing with machine A, and selecting the 'sync now' action seems to be working.
+
+The thing I am curious about is the behaviour on machine A - why is it that I cannot find any reference to it any more in the assistant, so that I can re-enable it?
diff --git a/doc/forum/webapp__58___disabling_a_paired_repository/comment_1_9dd316fedf55afecbc77f3b99e66d837._comment b/doc/forum/webapp__58___disabling_a_paired_repository/comment_1_9dd316fedf55afecbc77f3b99e66d837._comment
new file mode 100644
index 0000000000..077832deb4
--- /dev/null
+++ b/doc/forum/webapp__58___disabling_a_paired_repository/comment_1_9dd316fedf55afecbc77f3b99e66d837._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="vincent.mcintyre@1318ebde5cb96fc17e59dfa86f399f5634b1facc"
+ nickname="vincent.mcintyre"
+ subject="addendum"
+ date="2015-08-25T10:45:56Z"
+ content="""
+Syncing seems to work only in one direction.
+
+If I  go to machine B and:
+ * change a file
+ * select 'sync now' from the 'actions' menu for machine A
+the webapp says it worked.
+
+But if I login to machine A and inspect the file I expect to have changed, it is 'not available'.
+
+If I run 'git annex get 'baz.txt' on machine A it complains and asks me to make available the reposiotry on machine B.
+
+"""]]
diff --git a/doc/forum/webapp__58___disabling_a_paired_repository/comment_2_28cf58629b9774426c084d80964151d7._comment b/doc/forum/webapp__58___disabling_a_paired_repository/comment_2_28cf58629b9774426c084d80964151d7._comment
new file mode 100644
index 0000000000..5d78439b67
--- /dev/null
+++ b/doc/forum/webapp__58___disabling_a_paired_repository/comment_2_28cf58629b9774426c084d80964151d7._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-09-21T16:55:47Z"
+ content="""
+Disabling a remote is a weak form of deleting it; the remote repository is
+left as-is, but the git remote is removed so git-annex won't sync with it,
+and the webapp won't show it.
+
+I don't know if it makes sense for the webapp to expose this possibility.
+It seems that it certianly doesn't makes sense to do it without getting
+confirmation, since to re-enable the repository, the user has to do some
+probably unknown to them process to set it back up.
+
+In your case, I think that re-doing the pairing process would get them back
+to how they were.
+
+On consideration, I am going to remove this feature from the webapp UI.
+"""]]
diff --git a/doc/forum/webapp__58___disabling_a_paired_repository/comment_3_799d66b116e8ddf42e624bb4a082337c._comment b/doc/forum/webapp__58___disabling_a_paired_repository/comment_3_799d66b116e8ddf42e624bb4a082337c._comment
new file mode 100644
index 0000000000..1e38b31851
--- /dev/null
+++ b/doc/forum/webapp__58___disabling_a_paired_repository/comment_3_799d66b116e8ddf42e624bb4a082337c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
+ nickname="Carl"
+ subject="Thanks"
+ date="2015-09-24T13:30:26Z"
+ content="""
+I think this is a very good usability improvement. I hav more than once wanted to temporarily turn off syncing (for example for a server inly available when on my lan at home) and ended up disabling the remote altogether. One possibility less to shoot myself in the foot. Thanks!
+"""]]
diff --git a/doc/forum/webapp___47___assistant_without_watch.mdwn b/doc/forum/webapp___47___assistant_without_watch.mdwn
new file mode 100644
index 0000000000..9bb1fcf1ad
--- /dev/null
+++ b/doc/forum/webapp___47___assistant_without_watch.mdwn
@@ -0,0 +1,9 @@
+I did not recieve feedback on my comment [1], so I try to post my question again but more clearly.
+
+Is it possible to run the assistent/the webapp without the functionality of 'git annex watch'?
+
+I'd like to use the assistant and to have the automatic syncing but I do not want the local repository to be watched.  Instead I prefer to manually add/drop my files.
+
+I do not see the 'pause button' mentioned in my earlier question [1].
+
+[1] http://git-annex.branchable.com/forum/webapp_and_manual_mode/
diff --git a/doc/forum/webapp___47___assistant_without_watch/comment_1_1bcd99aa81f937ded683e19a69d33dd9._comment b/doc/forum/webapp___47___assistant_without_watch/comment_1_1bcd99aa81f937ded683e19a69d33dd9._comment
new file mode 100644
index 0000000000..c76128ae39
--- /dev/null
+++ b/doc/forum/webapp___47___assistant_without_watch/comment_1_1bcd99aa81f937ded683e19a69d33dd9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 1"
+ date="2013-08-26T18:14:17Z"
+ content="""
+The assistant is currently only able to transfer files that it has added itself. So if you disable syncing, you have to manually upload any files you add.
+
+I doubt that I will change this in the assistant, because supporting this use case would complicate it unnecessarily for a use case that is not what it's designed to do. It's more likely that `git annex sync` will get an option to also transfer file contents.
+"""]]
diff --git a/doc/forum/webapp___47___assistant_without_watch/comment_2_9f5b3f5bf7fedcd5baec519d97d3aa8c._comment b/doc/forum/webapp___47___assistant_without_watch/comment_2_9f5b3f5bf7fedcd5baec519d97d3aa8c._comment
new file mode 100644
index 0000000000..a441558768
--- /dev/null
+++ b/doc/forum/webapp___47___assistant_without_watch/comment_2_9f5b3f5bf7fedcd5baec519d97d3aa8c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="ringprince"
+ ip="134.76.140.110"
+ subject="comment 2"
+ date="2013-08-26T18:54:40Z"
+ content="""
+Thanks for the clarification.
+
+Although
+
+* not what I hoped for ;-)
+* I don't see that it would get complicated
+* I do not consider my use case special
+
+Anyway, thanks for this great piece of software.
+"""]]
diff --git a/doc/forum/webapp_and_manual_mode.mdwn b/doc/forum/webapp_and_manual_mode.mdwn
new file mode 100644
index 0000000000..f7a903387b
--- /dev/null
+++ b/doc/forum/webapp_and_manual_mode.mdwn
@@ -0,0 +1,7 @@
+Somehow I seemingly have not understood the manual mode.
+
+If I have a file in my repository, that is not yet in the annex (or in git), and I start the webapp, that file is automatically added to git-annex (and git).
+
+Why is that?
+
+And how can I use the webapp without such interference?
diff --git a/doc/forum/webapp_and_manual_mode/comment_1_5b5df5ffeb6ee15779972f13fdc11729._comment b/doc/forum/webapp_and_manual_mode/comment_1_5b5df5ffeb6ee15779972f13fdc11729._comment
new file mode 100644
index 0000000000..677dd04148
--- /dev/null
+++ b/doc/forum/webapp_and_manual_mode/comment_1_5b5df5ffeb6ee15779972f13fdc11729._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.140"
+ subject="comment 1"
+ date="2013-07-21T17:17:58Z"
+ content="""
+Setting a repository to manual mode prevents the assistant from transferring new files into that repository. You have to manually run `git annex get`.
+
+To prevent the assistant from automatically adding files, you can click the pause button next to the current repository in the webapp.
+"""]]
diff --git a/doc/forum/webapp_and_manual_mode/comment_2_a1f06b50d1317c78a301b47eb05d2617._comment b/doc/forum/webapp_and_manual_mode/comment_2_a1f06b50d1317c78a301b47eb05d2617._comment
new file mode 100644
index 0000000000..99efad90a2
--- /dev/null
+++ b/doc/forum/webapp_and_manual_mode/comment_2_a1f06b50d1317c78a301b47eb05d2617._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="ringprince"
+ ip="134.76.2.1"
+ subject="comment 2"
+ date="2013-07-23T08:47:58Z"
+ content="""
+Not sure, what you mean.
+
+Disabling sync?
+But that also disables sync, right?  ;-)  So, if I add a file manually (via command line) that file is not synced automatically, correct?
+
+I do not see any other 'pause' button next to the repository.
+
+I am fine with git-annex doing the syncing automatically for me, but I want to be in control over the files git annex actually uses.
+
+If I just downloaded a big file, I might want to check it first before having git-annex move it to other repositories.
+
+
+"""]]
diff --git a/doc/forum/webapp_and_manual_mode/comment_3_f0739bf4304a91a5d4ec33ac2421c966._comment b/doc/forum/webapp_and_manual_mode/comment_3_f0739bf4304a91a5d4ec33ac2421c966._comment
new file mode 100644
index 0000000000..04369e7cd7
--- /dev/null
+++ b/doc/forum/webapp_and_manual_mode/comment_3_f0739bf4304a91a5d4ec33ac2421c966._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="Also confused by the manual mode"
+ date="2014-05-18T06:39:54Z"
+ content="""
+@Joeyh: would you mind explaining the modes maybe on their own wiki page? 
+I've got most of them but the sense and functioning of the manual method escapes me :-/
+"""]]
diff --git a/doc/forum/webapp_does_not_start.mdwn b/doc/forum/webapp_does_not_start.mdwn
new file mode 100644
index 0000000000..ad42759707
--- /dev/null
+++ b/doc/forum/webapp_does_not_start.mdwn
@@ -0,0 +1,72 @@
+Sorry, I have again an issue :(
+
+What could be the problem that the webapp is not starting (in Windows)? git annex just exists without messages, connection to localhost failes of course
+
+    me@laptop /cygdrive/c/Data
+    $ git annex --verbose --debug webapp
+    
+    me@laptop /cygdrive/c/Data
+    $
+
+If I run it within an annexed directory I get at least one message - but it still immideately exits:
+
+    me@laptop /cygdrive/c/Data/annex
+    $ git annex --verbose --debug webapp
+    [2014-07-11 19:06:58 Pacific Daylight Time] chat: git-annex ["--verbose","--debug","webapp"]
+
+    me@laptop /cygdrive/c/Data/annex
+    $
+
+    git-annex version: 5.20140707-g8116d10
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 2 3 4
+
+
+EDIT:
+1.) Interestingly, also "git annex test" fails:
+
+    [...]
+    ok
+    push origin To C:/Data/.t\repo
+       bcc4611..91f5218  git-annex -> synced/git-annex
+       6f47922..92c578a  annex/direct/master -> synced/master
+    
+    ok
+    add ../dir2/foo ok
+    (Recording state in git...)
+    FAIL
+          Exception: .t/tmprepo9/.git/annex/journal: getDirectoryContents: permission denied (Access is denied.)
+
+    2 out of 83 tests failed
+      (This could be due to a bug in git-annex, or an incompatibility
+       with utilities, such as git, installed on this system.)
+
+
+
+2.) There's really something very weird going on. At the beginning it worked. Then it stopped (as per above). Sometimes, when I start it using "Git Bash" it works. But then not any more.
+3.) Rebooting the machine does not help
+
+EDIT once again:
+4.) I am afraid there is something big broken. Suddenly I could start the daemon again. The thing I did was to delete my complete annex.
+But if I shutdown the daemon now I get:
+
+    $ git annex webapp
+    Launching web browser on file://C:\cygwin\tmp\webapp85796.html
+    
+      Detected a filesystem without fifo support.
+    
+      Disabling ssh connection caching.
+    
+      Detected a crippled filesystem.
+    
+      Enabling direct mode.
+    
+    (Recording state in git...)
+    WebApp crashed: ExitFailu
+
+... and the whole loop starts again. webapp daemon does not start as long as I delete the annex. Interestingly this is independent from %USERPROFILE%\.config. Deleting this directory does not change anything. So somehow git-annex "knows" that there is somewhere an annex and fails if it is.
+
diff --git a/doc/forum/webapp_does_not_start/comment_1_dd27d30ce305562a1552f46c87b1cd27._comment b/doc/forum/webapp_does_not_start/comment_1_dd27d30ce305562a1552f46c87b1cd27._comment
new file mode 100644
index 0000000000..cd3a7d3bc7
--- /dev/null
+++ b/doc/forum/webapp_does_not_start/comment_1_dd27d30ce305562a1552f46c87b1cd27._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-14T19:05:32Z"
+ content="""
+git-annex stores the locations of repositories in `.config/git-annex/autostart` in what passes for a home directory on Windows.
+
+Are you sure it doesn't manage to at least open a web browser tab, possibly one with an error in it? This would be easy to miss if you have a lot of tabs open. I seem to have partially reproduced this, at least that's the behavior I see. 
+
+The root of the problem seems to be that it thinks the daemon is running, but it's not. So it just opens the web browser and then stops. After I deleted .git/annex/daemon*, and .git/annex/url and .git/annex/daemon.log, `git annex webapp` worked again. 
+"""]]
diff --git a/doc/forum/webapp_does_not_start/comment_2_ef37f40288a1181ca619ae13b0f7a994._comment b/doc/forum/webapp_does_not_start/comment_2_ef37f40288a1181ca619ae13b0f7a994._comment
new file mode 100644
index 0000000000..551f518459
--- /dev/null
+++ b/doc/forum/webapp_does_not_start/comment_2_ef37f40288a1181ca619ae13b0f7a994._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 2"
+ date="2014-07-14T20:06:03Z"
+ content="""
+I think that I have fixed this problem. The Windows autobuilder should produce a fixed build within an hour.
+"""]]
diff --git a/doc/forum/webapp_does_not_start/comment_3_6e625dba9f7fa36bf9c7e9d77fbadeff._comment b/doc/forum/webapp_does_not_start/comment_3_6e625dba9f7fa36bf9c7e9d77fbadeff._comment
new file mode 100644
index 0000000000..296e066a7a
--- /dev/null
+++ b/doc/forum/webapp_does_not_start/comment_3_6e625dba9f7fa36bf9c7e9d77fbadeff._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="128.12.90.218"
+ subject="comment 3"
+ date="2014-07-15T05:43:35Z"
+ content="""
+Thank you, really really great. This part seems to work again.
+For some reason, the assistant takes the wrong (?) git.exe (as I described here: http://git-annex.branchable.com/forum/Restricting_SSH_+_supply_key/)
+"""]]
diff --git a/doc/forum/webapp_listen_port_with_autostart.mdwn b/doc/forum/webapp_listen_port_with_autostart.mdwn
new file mode 100644
index 0000000000..fc9d1241b8
--- /dev/null
+++ b/doc/forum/webapp_listen_port_with_autostart.mdwn
@@ -0,0 +1,3 @@
+To start the webapp on a X-less server it's possible to use the parameter `--listen` and then connect from a client with X to it.
+
+How can I start the webapp on all annex repos on this server like on a client with `assistant --autostart`? Would be nice to start the assistant on all configured repos which listens on a defined port, f.e. `git annex assistant --autostart --listen 0.0.0.0:8888`. It would be even nicer to have a parameter to chose a autostart configuration file, f.e. `git annex assistant --autostart --autostart-config /etc/git-annex/autostart --listen 0.0.0.0:8888`, so this could end up in a real server application, a init script would be easy to write...
diff --git a/doc/forum/webapp_listen_port_with_autostart/comment_1_65dbcf3d8f6c16568f5a326242eab9c5._comment b/doc/forum/webapp_listen_port_with_autostart/comment_1_65dbcf3d8f6c16568f5a326242eab9c5._comment
new file mode 100644
index 0000000000..0c430cf7c6
--- /dev/null
+++ b/doc/forum/webapp_listen_port_with_autostart/comment_1_65dbcf3d8f6c16568f5a326242eab9c5._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-05-13T18:49:25Z"
+ content="""
+Well, it would be possible to add a configuration setting in the repository that tells the assistant what address:port to listen on.
+
+But maybe it would be better to not use `assistant --autostart` in your situation? That command is basically the same as this shell script:
+
+[[!format sh "
+#!/bin/sh
+for dir in $(cat $HOME/.config/git-annex/autostart); do
+    cd $dir
+    git annex webapp &
+done
+"]]
+
+So you can write similar shell scripts that start the webapp with whatever options you like.
+"""]]
diff --git a/doc/forum/webapp_listen_port_with_autostart/comment_2_39664f833dedc1a4fe083eec9bc4a7cd._comment b/doc/forum/webapp_listen_port_with_autostart/comment_2_39664f833dedc1a4fe083eec9bc4a7cd._comment
new file mode 100644
index 0000000000..0d48ba8255
--- /dev/null
+++ b/doc/forum/webapp_listen_port_with_autostart/comment_2_39664f833dedc1a4fe083eec9bc4a7cd._comment
@@ -0,0 +1,75 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmiqeXJtP04fzHOjXs17kHO33v7dWR2xwA"
+ nickname="Jaco"
+ subject="Init Script"
+ date="2013-11-23T08:28:32Z"
+ content="""
+Hi Joey,
+
+Could you help out with writing an init.d script to safely start and stop the webapp on a headless server? 
+I made an attempt below based on examples from the internet, but have no idea if it will work.
+
+	#!/bin/bash
+	# git-annex
+	# chkconfig: 345 20 80
+	# description: Git Annex WebApp startup and shutdown script.
+	# processname: git-annex
+	
+	
+	DAEMON=git-annex webapp
+	
+	NAME=git-annex
+	DESC=\"Git Annex WebApp init script\"
+	PIDFILE=/var/run/$NAME.pid
+	SCRIPTNAME=/etc/init.d/$NAME
+	
+	case \"$1\" in
+	start)
+		printf \"%-50s\" \"Starting $NAME...\"
+		for dir in $(cat $HOME/.config/git-annex/autostart); do
+			cd $dir
+			PID=`$DAEMON > /dev/null 2>&1 & echo $!`
+			#echo \"Saving PID\" $PID \" to \" $PIDFILE
+		        if [ -z $PID ]; then
+	        		printf \"%s\n\" \"Fail\"
+		        else
+	        		echo $PID > $PIDFILE
+				printf \"%s\n\" \"Ok\"
+			fi
+		done
+	;;
+	status)
+	        printf \"%-50s\" \"Checking $NAME...\"
+	        if [ -f $PIDFILE ]; then
+			for PID in $(cat $PIDFILE); do
+				if [ -z \"`ps axf | grep ${PID} | grep -v grep`\" ]; then
+					printf \"%s\n\" \"Process dead but pidfile exists\"
+				else
+					echo \"Running\"
+				fi
+			done
+	        else
+	            printf \"%s\n\" \"Service not running\"
+	        fi
+	;;
+	stop)
+	        printf \"%-50s\" \"Stopping $NAME\"
+		if [ -f $PIDFILE ]; then
+			for PID in $(cat $PIDFILE); do
+				kill -HUP $PID
+				printf \"%s\n\" \"Ok\"
+			done
+			rm -f $PIDFILE
+	        else
+	            printf \"%s\n\" \"pidfile not found\"
+	        fi
+	;;
+	restart)
+	  	$0 stop
+	  	$0 start
+	;;
+	*)
+	        echo \"Usage: $0 {status|start|stop|restart}\"
+	        exit 1
+	esac
+"""]]
diff --git a/doc/forum/weird_view_file_naming.mdwn b/doc/forum/weird_view_file_naming.mdwn
new file mode 100644
index 0000000000..1520c6ad3d
--- /dev/null
+++ b/doc/forum/weird_view_file_naming.mdwn
@@ -0,0 +1,13 @@
+Very quick one, if anyone has to share experience with views (i would find them useful to get partial checkout views, as long as I can find a special setup to preserve the tree/filenames hyerarchy): 
+
+by using (filtering) views I am getting file names changed to include the (orignal) dir name,
+for instance:
+
+2008/pippo.doc
+
+after a git annex view 2008/=*, comes out as pippo_%2008%.doc
+is this avoidable ?
+
+(i've been trying to follow metadata walkthrough etc. but i always get the dirname in the filename between percents...)
+
+btw: version is 5.20141105
diff --git a/doc/forum/weird_view_file_naming/comment_1_24a44f94194231bb8efe9b20ee311d4c._comment b/doc/forum/weird_view_file_naming/comment_1_24a44f94194231bb8efe9b20ee311d4c._comment
new file mode 100644
index 0000000000..5ce5ed6ea1
--- /dev/null
+++ b/doc/forum/weird_view_file_naming/comment_1_24a44f94194231bb8efe9b20ee311d4c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI"
+ nickname="Michele"
+ subject="what I was trying to do is probabily done better with sparse checkouts"
+ date="2014-11-26T11:46:04Z"
+ content="""
+therefore instead of tagging the files _and_ placing them into subdirectories (which somehow seems confounding views reperesentation), i'll be using sparse checkout for the subdirectories I need.
+
+i'll be looking in sparse checkouts so that i have separate trees checked out from same annex ( see http://git-annex.branchable.com/forum/sparse_git_checkouts_with_annex/ )
+
+cheers
+"""]]
diff --git a/doc/forum/weird_view_file_naming/comment_2_2ff3002e45a7443f0502243b3690df9d._comment b/doc/forum/weird_view_file_naming/comment_2_2ff3002e45a7443f0502243b3690df9d._comment
new file mode 100644
index 0000000000..a78231438d
--- /dev/null
+++ b/doc/forum/weird_view_file_naming/comment_2_2ff3002e45a7443f0502243b3690df9d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2014-12-01T22:00:54Z"
+ content="""
+This naming is necessary to deal with the problem that a view could
+contain two files with the name name. So the directory is included to 
+work around it.
+
+Menomic: `%` looks sort of like a `/`
+"""]]
diff --git a/doc/forum/what_are___95__exactly__95___limitations_of_git-annex_when_using_it_like_dropbox.mdwn b/doc/forum/what_are___95__exactly__95___limitations_of_git-annex_when_using_it_like_dropbox.mdwn
new file mode 100644
index 0000000000..276ba646e9
--- /dev/null
+++ b/doc/forum/what_are___95__exactly__95___limitations_of_git-annex_when_using_it_like_dropbox.mdwn
@@ -0,0 +1,6 @@
+I'm trying to migrate from dropbox to git-annex. But I'm learning that git-annex has "limitations", as in
+"but it can be used to sync files such a way, with certain limitations". So what exactly are these limitations? I've learned already the hard way that newline can't be a character in a filename, and apparently git directories can't be synced?
+
+These are two  big issues imo (especiall the second one) - right now I don't have any filenames with newlines, and no git directories, but the brilliant thing about dropbox is that I don't have to think about such things, everything gets synced.
+
+But in any case, if I'm to use git-annex as a dropbox replacement, I really need to know what precisely are its limitations, so that it doesn't become an issue in two months out of nowhere...
diff --git a/doc/forum/what_are___95__exactly__95___limitations_of_git-annex_when_using_it_like_dropbox/comment_1_b76e6d3c4d530fd6735460aa5ab03ad5._comment b/doc/forum/what_are___95__exactly__95___limitations_of_git-annex_when_using_it_like_dropbox/comment_1_b76e6d3c4d530fd6735460aa5ab03ad5._comment
new file mode 100644
index 0000000000..66e618d3e9
--- /dev/null
+++ b/doc/forum/what_are___95__exactly__95___limitations_of_git-annex_when_using_it_like_dropbox/comment_1_b76e6d3c4d530fd6735460aa5ab03ad5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Agenta"
+ subject="not easy to access history"
+ date="2015-10-02T13:16:30Z"
+ content="""
+Another limitation is that it is not easy to access files history and to recover previous versions of a file. I have \"solved\" that by taking a snapshot of my repo every night with bup:
+https://github.com/bup/bup
+"""]]
diff --git a/doc/forum/what_happens_to_deleted_files__63__.mdwn b/doc/forum/what_happens_to_deleted_files__63__.mdwn
new file mode 100644
index 0000000000..5890a06b3d
--- /dev/null
+++ b/doc/forum/what_happens_to_deleted_files__63__.mdwn
@@ -0,0 +1,24 @@
+I have two repositories: A(direct) and B(indirect). At some point, I performed the following steps:
+
+1. Add a file in A.
+2. Sync A.
+3. Sync B, but not get all files.
+4. In B, remove a file F that was newly added in A, using `git rm` and `git commit`.
+5. Now get all files from A.
+
+This results in all "current" files being copied from A to B, but not file F.
+
+If I checkout a branch in B for an older commit which still had file F, I can see the symlink created in the branch. But now if I try to get the file in B from A, annex says that the remote is not available: 
+
+    sameerds@gajanan:/mnt/mandos/test$ git annex get
+    get IMG_0570.JPG 
+      Unable to access these remotes: A
+    
+      Try making some of these repositories available:
+      	530e4f81-474d-4b0b-9f13-4beb7361302c -- A
+    failed
+    git-annex: get: 1 failed
+
+The remote for A exists in the listing for `git remote`, and `git annex sync` does not make this error message go away. If I checkout `master` again, then everything works fine.
+
+But of course, this a different problem from my original one. It would a way to bring all files from the remote, that are ever used by any commit reachable in the local git history, irrespective of the currently checkout out commit. Perhaps an option `--deep-copy` to the standard `git annex get`.
diff --git a/doc/forum/what_happens_to_deleted_files__63__/comment_1_a476174646ad3adfbbe0cafdd7d42d08._comment b/doc/forum/what_happens_to_deleted_files__63__/comment_1_a476174646ad3adfbbe0cafdd7d42d08._comment
new file mode 100644
index 0000000000..5959db5355
--- /dev/null
+++ b/doc/forum/what_happens_to_deleted_files__63__/comment_1_a476174646ad3adfbbe0cafdd7d42d08._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://sameer.sbuddhe.net/blog/"
+ nickname="sameerds"
+ subject="never mind ..."
+ date="2013-12-31T04:06:43Z"
+ content="""
+... I discovered the [[`--all` option|http://git-annex.branchable.com/forum/Moving_older_version__39__s_file_content_without_doing_checkout/]] which does just what I was looking for!
+
+
+"""]]
diff --git a/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out.mdwn b/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out.mdwn
new file mode 100644
index 0000000000..2f12784a99
--- /dev/null
+++ b/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out.mdwn
@@ -0,0 +1,31 @@
+I have two regular git clones and 4 special remotes (cloud
+storage mostly).
+
+My `numcopies` is set to 2 which means I always need to have at
+least two copies.  One usually lives in one of my git clones
+which is a backup and so has everything.  The other is somewhere
+in the cloud.
+
+When I add a new file to my client clone and do `git annex sync
+--content` is this respecting the prefered content of each remote
+or is it only trying to satisfy the numcopy?
+
+These are my settings for archive and smallarchive
+
+    groupwanted smallarchive = ((include=*/archive/* or include=archive/*) and not (copies=archive:2 or copies=smallarchive:2 or (copies=archive:1 and copies=smallarchive:1))) or approxlackingcopies=1
+
+
+
+    groupwanted archive = (not (copies=archive:2 or copies=smallarchive:2 or (copies=archive:1 and copies=smallarchive:1)) or approxlackingcopies=1
+
+
+One of the remotes is set as archive and two as smallarchive yet `sync
+--content` only ever copies to one so as to satisfy `numcopies`.  Is
+this expected?  Shouldn't it always try to make two copies in archive
+or smallarchive? 
+
+Interestingly, it copies data to my `backup` also (which is an
+extarnal drive, so always present).  So it seems the prefered content
+is only respected for clones and not special remotes.  Is that true?
+
+Do I have to run `git annex copy --to <archive-remote> --auto` to satisfy the content preferences?
diff --git a/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_1_86428fc8286266d01cc51af8ae4aa335._comment b/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_1_86428fc8286266d01cc51af8ae4aa335._comment
new file mode 100644
index 0000000000..ce0a539924
--- /dev/null
+++ b/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_1_86428fc8286266d01cc51af8ae4aa335._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="numcopies"
+ date="2018-03-27T22:25:30Z"
+ content="""
+||| *When I add a new file to my client clone and do git annex sync --content is this respecting the … content of each remote or is it only trying to satisfy the numcopy?*
+
+Both.
+
+Running `git annex sync --content` will copy content to any remote where that content is wanted (IE look at the preferred content settings), and will drop files that are not wanted and don't violate numcopies totals (at the moment of the drop?).
+
+
+||| *One of the remotes is set as archive and two as smallarchive yet sync --content only ever copies to one so as to satisfy numcopies.*
+
+I don't believe that `git annex sync --content` is ever trying to “satisfy numcopies,” I would think of numcopies as more of a limit or restriction on when git-annex is allowed to drop content that is not wanted by a remote.
+
+
+
+
+||| *Shouldn't it always try to make two copies in archive or smallarchive?*
+
+Hmmmm. I would guess there is some issue with your archive or smallarchive expressions, or they aren't actually set (being used) or you have discovered an issue… You have overridden the standard groups, and can see your overrides with `git annex groupwanted archive` and `git annex groupwanted smallarchive`? And your remotes have `git annex group archive` and `git annex wanted groupwanted` set?
+
+So `(include=*/archive/* or include=archive/*) and` means you are only copying files in the archive directory, was that your intention?
+
+If so, the rest of your content expression seems like it should want 1 copy in an archive and 1 copy in a smallarchive, or 2 copies in 2 remotes marked archive or 2 copies in two remotes marked smallarchive.
+
+
+||| *Interestingly, it copies data to my backup*
+
+Right. If you are using a standard content group backup means “All content is wanted. Even content of old/deleted files.” This expression will want all content and never drop content.
+
+"""]]
diff --git a/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_2_50c1a19a7278e8748c2e6e789f6b418a._comment b/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_2_50c1a19a7278e8748c2e6e789f6b418a._comment
new file mode 100644
index 0000000000..efbf232b89
--- /dev/null
+++ b/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_2_50c1a19a7278e8748c2e6e789f6b418a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="MatusGoljer"
+ avatar="http://cdn.libravatar.org/avatar/8152eed1d594c570563ed46e7fd8356f"
+ subject="comment 2"
+ date="2018-03-28T23:16:51Z"
+ content="""
+Hi Andrew!
+
+Actually, you are entirely correct, I just misinterpreted the `smallarchive` formula.  What I was thinking it would do was it would upload the file in case there are not two copies in any combination of `archive` or `smallarchive` and as soon as there are two `archive` copies it would ideally drop the file if not in `*/archive/*` directory.
+
+But now I see that the formula does exactly what you say it would do, the whole long `and not` condition is additional to the first, which means a file will not get uploaded if not in those directories.
+
+I will play around with the expression, I'm sure it can be modified to do what I want.
+
+Thanks!  It was mostly me being silly, sometimes having other people re-state the obvious helps!
+"""]]
diff --git a/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_3_368403625451415c66b9e62005d9ddea._comment b/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_3_368403625451415c66b9e62005d9ddea._comment
new file mode 100644
index 0000000000..43822f3ca7
--- /dev/null
+++ b/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_3_368403625451415c66b9e62005d9ddea._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-04-04T16:14:45Z"
+ content="""
+I just wanted to say thanks to andrew for a really excellent response here.
+I've answered plenty of such questions less well.
+I hope you answer many more questions about git-annex with such care and
+attention to detail.
+
+And, thanks to MatusGoljer for following up to confirm that you were
+misunderstanding -- and I agree that you should be able to adjust the
+preferred content expression to do what you want it to do.
+"""]]
diff --git a/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_4_53ccb5c7c8f15f44fb2f113742fe77f3._comment b/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_4_53ccb5c7c8f15f44fb2f113742fe77f3._comment
new file mode 100644
index 0000000000..de464c3ac5
--- /dev/null
+++ b/doc/forum/what_rules_is_git_annex_sync_--content_using_to_send_files_out/comment_4_53ccb5c7c8f15f44fb2f113742fe77f3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 4"
+ date="2018-05-04T16:00:58Z"
+ content="""
+Thanks Joey! I am glad to hopefully take some work off your plate.
+
+—Andrew
+"""]]
diff --git a/doc/forum/when_repo_offline_list_whereis_slow.mdwn b/doc/forum/when_repo_offline_list_whereis_slow.mdwn
new file mode 100644
index 0000000000..0a8dfe66bc
--- /dev/null
+++ b/doc/forum/when_repo_offline_list_whereis_slow.mdwn
@@ -0,0 +1,2 @@
+All is well except for when a repo is offline, everything becomes slow, git annex list, whereis...
+Tried to google find in site but can't find it.
diff --git a/doc/forum/when_repo_offline_list_whereis_slow/comment_1_79052583012da5097ca7bdc52dcdfb7d._comment b/doc/forum/when_repo_offline_list_whereis_slow/comment_1_79052583012da5097ca7bdc52dcdfb7d._comment
new file mode 100644
index 0000000000..1d9a167940
--- /dev/null
+++ b/doc/forum/when_repo_offline_list_whereis_slow/comment_1_79052583012da5097ca7bdc52dcdfb7d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yonkers"
+ avatar="http://cdn.libravatar.org/avatar/c57f0d4698ad9cff11094798b530942c"
+ subject="I think I found the answer, will try laer"
+ date="2018-09-13T18:18:30Z"
+ content="""
+It is about making the repo an archive!?
+Will test later...
+"""]]
diff --git a/doc/forum/when_repo_offline_list_whereis_slow/comment_2_caa2b4ca2826444bdfb47616a549f4e6._comment b/doc/forum/when_repo_offline_list_whereis_slow/comment_2_caa2b4ca2826444bdfb47616a549f4e6._comment
new file mode 100644
index 0000000000..e380e0b9d2
--- /dev/null
+++ b/doc/forum/when_repo_offline_list_whereis_slow/comment_2_caa2b4ca2826444bdfb47616a549f4e6._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-10-04T19:26:23Z"
+ content="""
+What do you mean by "a repo is offline"?
+"""]]
diff --git a/doc/forum/where_to_submit_pull_requests_for_git-annex__63__.mdwn b/doc/forum/where_to_submit_pull_requests_for_git-annex__63__.mdwn
new file mode 100644
index 0000000000..61e41a5ba6
--- /dev/null
+++ b/doc/forum/where_to_submit_pull_requests_for_git-annex__63__.mdwn
@@ -0,0 +1,4 @@
+Is there a place to submit pull requests for git-annex?
+
+I've made a small change to the docs, adding html anchors to enable hyperlinks to docs for specific config settings, on a branch here:
+<https://github.com/notestaff/git-annex/tree/is-doc-add-html-anchors-for-config-vars>
diff --git a/doc/forum/where_to_submit_pull_requests_for_git-annex__63__/comment_1_f5e6022798ba63b55bff197b5937f9fe._comment b/doc/forum/where_to_submit_pull_requests_for_git-annex__63__/comment_1_f5e6022798ba63b55bff197b5937f9fe._comment
new file mode 100644
index 0000000000..52c71da9e1
--- /dev/null
+++ b/doc/forum/where_to_submit_pull_requests_for_git-annex__63__/comment_1_f5e6022798ba63b55bff197b5937f9fe._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-07-19T17:28:40Z"
+ content="""
+The thing to do is to go to <https://git-annex.branchable.com/todo> and 
+make a post there. Include either the url to the git repo to pull from, or
+paste in a git patch to apply.
+
+I took a look at your html anchors patch. After applying it and running
+"make mans", the man/git-annex.1 page had broken formatting around those
+html anchors. It would need some additional change to Build/mdwn2man to
+make it deal with them.
+"""]]
diff --git a/doc/forum/whereis__58___Why_not_here__63__.mdwn b/doc/forum/whereis__58___Why_not_here__63__.mdwn
new file mode 100644
index 0000000000..fb2a325d5e
--- /dev/null
+++ b/doc/forum/whereis__58___Why_not_here__63__.mdwn
@@ -0,0 +1,33 @@
+Hey,
+
+I have three repos, all are run by git-annex assistent. Files are synced just fine, but there is one oddity:
+
+```
+florian@horus ~/.synced_configuration (git)-[annex/direct/master] % git annex whereis .zshenv 
+whereis .zshenv (3 copies) 
+        69902190-d4c1-4abb-a000-f0712769f1cd -- Horus [here]
+        c7fc42ca-49f7-4688-b81d-c9cfd4a42564 -- Asaru
+        d5b0586f-32dd-4aae-a7a2-b23d9edd0c32 -- Marduk [marduk]
+ok
+florian@horus ~/.synced_configuration (git)-[annex/direct/master] % git annex whereis .emacs 
+whereis .emacs (2 copies) 
+        c7fc42ca-49f7-4688-b81d-c9cfd4a42564 -- Asaru
+        d5b0586f-32dd-4aae-a7a2-b23d9edd0c32 -- Marduk [marduk]
+ok
+```
+for `.zshenv` everything is fine, but why is `.emacs` not in Horus? Changes from and to Horus are propagated:
+
+```
+florian@horus ~/.synced_configuration (git)-[annex/direct/master] % git annex log .emacs
+- Wed, 12 Apr 2017 22:48:03 CEST .emacs | 69902190-d4c1-4abb-a000-f0712769f1cd -- Horus
++ Wed, 12 Apr 2017 22:02:55 CEST .emacs | 69902190-d4c1-4abb-a000-f0712769f1cd -- Horus
++ Wed, 12 Apr 2017 22:02:55 CEST .emacs | d5b0586f-32dd-4aae-a7a2-b23d9edd0c32 -- Marduk [marduk]
+- Wed, 12 Apr 2017 22:02:54 CEST .emacs | 69902190-d4c1-4abb-a000-f0712769f1cd -- Horus
+- Wed, 12 Apr 2017 22:02:53 CEST .emacs | d5b0586f-32dd-4aae-a7a2-b23d9edd0c32 -- Marduk [marduk]
++ Wed, 12 Apr 2017 22:00:40 CEST .emacs | d5b0586f-32dd-4aae-a7a2-b23d9edd0c32 -- Marduk [marduk]
++ Wed, 12 Apr 2017 22:00:36 CEST .emacs | 69902190-d4c1-4abb-a000-f0712769f1cd -- Horus
+```
+
+Anyone any idea what could be wrong there?
+
+Thanks!
diff --git a/doc/forum/whereis__58___Why_not_here__63__/comment_1_02a423918efcc760bb89dfb78586dc2a._comment b/doc/forum/whereis__58___Why_not_here__63__/comment_1_02a423918efcc760bb89dfb78586dc2a._comment
new file mode 100644
index 0000000000..4f032f4ce5
--- /dev/null
+++ b/doc/forum/whereis__58___Why_not_here__63__/comment_1_02a423918efcc760bb89dfb78586dc2a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Horus"
+ avatar="http://cdn.libravatar.org/avatar/8f0ee08b98ea5bba76c3fe112c08851c"
+ subject="comment 1"
+ date="2017-04-12T21:21:08Z"
+ content="""
+It's strange. I made a change to the file on Horus, it gets propagated to Marduk, but Marduk does not know about. whereis still shows the file is only at Horus. At Asaru the symlink is deleted (so the change info was propagated), but instead there is a symlink on invalid content (like in indirect mode)
+
+The connections are all over SSH: Horus -> Marduk <- Asaru
+
+Sorry, I'm utterly confused...
+"""]]
diff --git a/doc/forum/whereis__58___Why_not_here__63__/comment_2_e55ce8cbb6bbabc654ba743d755a6eee._comment b/doc/forum/whereis__58___Why_not_here__63__/comment_2_e55ce8cbb6bbabc654ba743d755a6eee._comment
new file mode 100644
index 0000000000..cffe96e28b
--- /dev/null
+++ b/doc/forum/whereis__58___Why_not_here__63__/comment_2_e55ce8cbb6bbabc654ba743d755a6eee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-05-11T17:22:01Z"
+ content="""
+Your log shows that the .emacs file reached Horus, but was then dropped
+from it some 46 minutes later.
+
+Something had to drop it. Are you using the git-annex assistant or what?
+"""]]
diff --git a/doc/forum/whereis__58___Why_not_here__63__/comment_3_7de87ad1fd8a0f53562d3083af1410d6._comment b/doc/forum/whereis__58___Why_not_here__63__/comment_3_7de87ad1fd8a0f53562d3083af1410d6._comment
new file mode 100644
index 0000000000..9b53cd06df
--- /dev/null
+++ b/doc/forum/whereis__58___Why_not_here__63__/comment_3_7de87ad1fd8a0f53562d3083af1410d6._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="Horus"
+ avatar="http://cdn.libravatar.org/avatar/8f0ee08b98ea5bba76c3fe112c08851c"
+ subject="comment 3"
+ date="2017-05-29T18:10:55Z"
+ content="""
+Sorry, just saw your comment...
+
+Yes, I'm using the assistant, as I pointed out in my original posting. Just right now, I'm having the same situation:
+
+```
+florian@horus ~/.synced_configuration (git)-[annex/direct/master] % git annex whereis .emacs
+whereis .emacs (2 copies) 
+        c7fc42ca-49f7-4688-b81d-c9cfd4a42564 -- Asaru
+        d5b0586f-32dd-4aae-a7a2-b23d9edd0c32 -- Marduk [marduk]
+ok
+```
+
+```
+florian@horus ~/.synced_configuration (git)-[annex/direct/master] % git annex log .emacs    
++ Mon, 29 May 2017 20:04:11 CEST .emacs | c7fc42ca-49f7-4688-b81d-c9cfd4a42564 -- Asaru
+- Mon, 29 May 2017 20:04:10 CEST .emacs | 69902190-d4c1-4abb-a000-f0712769f1cd -- Horus
++ Mon, 29 May 2017 20:02:37 CEST .emacs | 69902190-d4c1-4abb-a000-f0712769f1cd -- Horus
++ Mon, 29 May 2017 20:02:37 CEST .emacs | d5b0586f-32dd-4aae-a7a2-b23d9edd0c32 -- Marduk [marduk]
+- Mon, 29 May 2017 20:02:36 CEST .emacs | 69902190-d4c1-4abb-a000-f0712769f1cd -- Horus
+- Mon, 29 May 2017 20:02:35 CEST .emacs | d5b0586f-32dd-4aae-a7a2-b23d9edd0c32 -- Marduk [marduk]
++ Mon, 29 May 2017 20:02:35 CEST .emacs | d5b0586f-32dd-4aae-a7a2-b23d9edd0c32 -- Marduk [marduk]
++ Mon, 29 May 2017 20:02:33 CEST .emacs | 69902190-d4c1-4abb-a000-f0712769f1cd -- Horus
+```
+
+Thanks!
+Florian
+"""]]
diff --git a/doc/forum/whereis_command_with_file_names_instead_of_hashes.mdwn b/doc/forum/whereis_command_with_file_names_instead_of_hashes.mdwn
new file mode 100644
index 0000000000..6b4b3bf016
--- /dev/null
+++ b/doc/forum/whereis_command_with_file_names_instead_of_hashes.mdwn
@@ -0,0 +1,7 @@
+Hi
+
+I have a laptop, server and a regular PC. Laptop and PC are using same "backup" repo on server. Thay all get notified via ssh. My goal is to have synchronization and backup in one remote repo. When I wan to list all files on all repos i do:
+
+    git-annex whereis -A (some files do fail. Don't know why)
+
+But that displays hashes. Not file names. How can to list file names on all repos instead of hashes ?
diff --git a/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_1_4eaca07152916adc18032fb404e4dd92._comment b/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_1_4eaca07152916adc18032fb404e4dd92._comment
new file mode 100644
index 0000000000..3ad0becfe7
--- /dev/null
+++ b/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_1_4eaca07152916adc18032fb404e4dd92._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://ypid.wordpress.com/"
+ ip="213.153.84.215"
+ subject="-A  --all      operate on all versions of all files"
+ date="2014-07-07T07:42:03Z"
+ content="""
+Hi
+
+`-A` operates on all the files even on files which are not accessible from your current working directory. If you omit the `-A` then filenames will be printed.
+"""]]
diff --git a/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_2_94b43ac23ff8332b35723422eede8997._comment b/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_2_94b43ac23ff8332b35723422eede8997._comment
new file mode 100644
index 0000000000..2ab6b8e0bf
--- /dev/null
+++ b/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_2_94b43ac23ff8332b35723422eede8997._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkNE-H4vEcbcGndxq5daT8qUb7yIf7r1OE"
+ nickname="Łukasz"
+ subject="comment 2"
+ date="2014-07-07T08:40:57Z"
+ content="""
+Yes they will be omitted. I just want to list files that are on my laptop (for example) and on remote repo.
+"""]]
diff --git a/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_3_45ffa6dd17667ecd6685f85f34046eff._comment b/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_3_45ffa6dd17667ecd6685f85f34046eff._comment
new file mode 100644
index 0000000000..b0d48ef990
--- /dev/null
+++ b/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_3_45ffa6dd17667ecd6685f85f34046eff._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://ypid.wordpress.com/"
+ ip="213.153.84.215"
+ subject="git annex whereis --in origin"
+ date="2014-07-07T09:45:48Z"
+ content="""
+So you only want to see whereis for files which are present on certain annexes? You can use `git annex whereis --in e64553d0-779a-4c79-939a-d5b7f3e56a57` or `git annex whereis --in origin` (modify the repo names).
+
+Have a look on [QUERY COMMANDS](/git-annex/).
+"""]]
diff --git a/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_4_d459fbcf0db59b821ae67f4949e48103._comment b/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_4_d459fbcf0db59b821ae67f4949e48103._comment
new file mode 100644
index 0000000000..24643f063d
--- /dev/null
+++ b/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_4_d459fbcf0db59b821ae67f4949e48103._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkNE-H4vEcbcGndxq5daT8qUb7yIf7r1OE"
+ nickname="Łukasz"
+ subject="comment 4"
+ date="2014-07-07T10:05:06Z"
+ content="""
+git-annex whereis --not --in here
+
+Does not display anything.
+
+git-annex whereis --not --in here -A
+
+Displays files on remote only. Every file has an additional message (0 copies) failed. This displays hash names. How to display file names ? I am 100% sure that my remote repo has some files that are not present on laptop or PC.
+"""]]
diff --git a/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_5_e52a8c9cb418fbc2e2cba71f37bd44ad._comment b/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_5_e52a8c9cb418fbc2e2cba71f37bd44ad._comment
new file mode 100644
index 0000000000..eff34edb6a
--- /dev/null
+++ b/doc/forum/whereis_command_with_file_names_instead_of_hashes/comment_5_e52a8c9cb418fbc2e2cba71f37bd44ad._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkNE-H4vEcbcGndxq5daT8qUb7yIf7r1OE"
+ nickname="Łukasz"
+ subject="comment 5"
+ date="2014-07-07T10:06:03Z"
+ content="""
+One more thing. I am using indirect mode with assistant. If that matters in some way.
+"""]]
diff --git a/doc/forum/which_version_should_I_install__63__.mdwn b/doc/forum/which_version_should_I_install__63__.mdwn
new file mode 100644
index 0000000000..d75957e938
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__.mdwn
@@ -0,0 +1,8 @@
+Should I install the version in my apt repo (6), or (7) or (8)?
+
+Also, I'd like to know what the major difference is in the versions, I've googled this and found nothing.
+
+(other than bug fixes and "repo format changes"), I wanted to know if the repo format change is a good reason to try to run the latest v8.
+
+edit: I guess there is no "release notes" link for git annex? I see the content that would exist there in news: https://git-annex.branchable.com/news/
+
diff --git a/doc/forum/which_version_should_I_install__63__/comment_1_147f12392f6f546ab50dc346052ad4b7._comment b/doc/forum/which_version_should_I_install__63__/comment_1_147f12392f6f546ab50dc346052ad4b7._comment
new file mode 100644
index 0000000000..262dd17d61
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_1_147f12392f6f546ab50dc346052ad4b7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2020-03-10T14:09:33Z"
+ content="""
+There is a changelog at [Hackage](https://hackage.haskell.org/package/git-annex-8.20200309/changelog).
+
+v6 is very old.  v8 includes speed improvements; downside is it's new so less tested by users, upside is that bugfixes are more likely to happen for it than for legacy versions, and that you avoid an eventual [[git-annex-upgrade]].  I'd probably install v8.
+
+
+"""]]
diff --git a/doc/forum/which_version_should_I_install__63__/comment_3_c85c107a60b4b642ed9a8de7d233f95e._comment b/doc/forum/which_version_should_I_install__63__/comment_3_c85c107a60b4b642ed9a8de7d233f95e._comment
new file mode 100644
index 0000000000..87630445a1
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_3_c85c107a60b4b642ed9a8de7d233f95e._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="eric.w@eee65cd362d995ced72640c7cfae388ae93a4234"
+ nickname="eric.w"
+ avatar="http://cdn.libravatar.org/avatar/8d9808c12db3a3f93ff7f9e74c0870fc"
+ subject="make install failing for 8.20200309, any ideas as to why?"
+ date="2020-03-11T17:26:06Z"
+ content="""
+screen scrape below, I have no idea why it thinks that text file is locked, so weird.
+
+
+# git status
+HEAD detached at 8.20200309
+nothing to commit, working tree clean
+
+
+
+# make install PREFIX=/usr/local
+if [ \"cabal\" = ./Setup ]; then ghc --make Setup; fi
+if [ \"cabal\" != stack ]; then \
+	cabal configure  --ghc-options=\"\"; \
+else \
+	cabal setup ; \
+fi
+Warning: The configure command is a part of the legacy v1 style of cabal
+usage.
+
+Please switch to using either the new project style and the new-configure
+command or the legacy v1-configure alias as new-style projects will become the
+default in the next version of cabal-install. Please file a bug if you cannot
+replicate a working v1- use case with the new-style commands.
+
+For more information, see: https://wiki.haskell.org/Cabal/NewBuild
+
+Resolving dependencies...
+Warning: solver failed to find a solution:
+Could not resolve dependencies:
+[__0] trying: git-annex-8.20200309 (user goal)
+[__1] unknown package: filepath-bytestring (dependency of git-annex)
+[__1] fail (backjumping, conflict set: filepath-bytestring, git-annex)
+After searching the rest of the dependency tree exhaustively, these were the
+goals I've had most trouble fulfilling: git-annex, filepath-bytestring
+Trying configure anyway.
+./dist/setup/setup.version: openFile: resource busy (file is locked)
+make: *** [Makefile:37: tmp/configure-stamp] Error 1
+
+"""]]
diff --git a/doc/forum/which_version_should_I_install__63__/comment_4_f627212a612f5d746bb8bcc5e1ea48df._comment b/doc/forum/which_version_should_I_install__63__/comment_4_f627212a612f5d746bb8bcc5e1ea48df._comment
new file mode 100644
index 0000000000..06aca1b2cc
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_4_f627212a612f5d746bb8bcc5e1ea48df._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2020-03-11T17:32:35Z"
+ content="""
+Sure you need to build from source?  There are many [[install]] methods for pre-built binaries.
+"""]]
diff --git a/doc/forum/which_version_should_I_install__63__/comment_5_1c8201cf1de60fde73a2370a6e6c3ad3._comment b/doc/forum/which_version_should_I_install__63__/comment_5_1c8201cf1de60fde73a2370a6e6c3ad3._comment
new file mode 100644
index 0000000000..c7569edd42
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_5_1c8201cf1de60fde73a2370a6e6c3ad3._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="eric.w@eee65cd362d995ced72640c7cfae388ae93a4234"
+ nickname="eric.w"
+ avatar="http://cdn.libravatar.org/avatar/8d9808c12db3a3f93ff7f9e74c0870fc"
+ subject="comment 5"
+ date="2020-03-11T18:07:32Z"
+ content="""
+thank you again for being so helpful:
+
+I was using an old lts ubuntu, but the repos only had git-annex v6, and install from source wasn't working, so I upgraded to... ubuntu 19.10 / eoan, and it looks like http://neuro.debian.net/ doesn't yet support that release. 
+
+I don't exactly love polluting my apt sources, but I can be compelled to if that's my best / only option.
+
+I'll keep digging, if I can find a prebuilt .deb, I'll likely use that. (too bad there isn't a snap?)
+"""]]
diff --git a/doc/forum/which_version_should_I_install__63__/comment_6_c0f850927683d45dbe4d6d1d61788b4a._comment b/doc/forum/which_version_should_I_install__63__/comment_6_c0f850927683d45dbe4d6d1d61788b4a._comment
new file mode 100644
index 0000000000..404c99c8a8
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_6_c0f850927683d45dbe4d6d1d61788b4a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 6"
+ date="2020-03-11T18:12:09Z"
+ content="""
+[[install/conda]] installation works on any Linux, don't need to be root.
+"""]]
diff --git a/doc/forum/which_version_should_I_install__63__/comment_7_b563b2be227a1a128d8ac0679108f5b5._comment b/doc/forum/which_version_should_I_install__63__/comment_7_b563b2be227a1a128d8ac0679108f5b5._comment
new file mode 100644
index 0000000000..012b5c73c4
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_7_b563b2be227a1a128d8ac0679108f5b5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="eric.w@eee65cd362d995ced72640c7cfae388ae93a4234"
+ nickname="eric.w"
+ avatar="http://cdn.libravatar.org/avatar/8d9808c12db3a3f93ff7f9e74c0870fc"
+ subject="comment 7"
+ date="2020-03-11T18:21:59Z"
+ content="""
+I'm sorry but that conda script looks gross, its opaque, and wants to install ms / vs code... so i kinda noped out of it. 
+
+I guess I'll just stay 1 rev behind current for now. if I have to I can always use a vm.
+"""]]
diff --git a/doc/forum/which_version_should_I_install__63__/comment_8_e24a8a8edd7d0b314f26406d17775fdc._comment b/doc/forum/which_version_should_I_install__63__/comment_8_e24a8a8edd7d0b314f26406d17775fdc._comment
new file mode 100644
index 0000000000..64d6eab245
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_8_e24a8a8edd7d0b314f26406d17775fdc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="eric.w@eee65cd362d995ced72640c7cfae388ae93a4234"
+ nickname="eric.w"
+ avatar="http://cdn.libravatar.org/avatar/8d9808c12db3a3f93ff7f9e74c0870fc"
+ subject="comment 8"
+ date="2020-11-18T19:28:51Z"
+ content="""
+yeah, sorry about that comment. I really love this project and the website, I was just having a hard time figuring it out at first. 
+I very much appreciate everything. I removed my petty little comment.
+"""]]
diff --git a/doc/forum/which_version_should_I_install__63__/comment_8_ef725153df7a9b65f7ade4d7e6cecffb._comment b/doc/forum/which_version_should_I_install__63__/comment_8_ef725153df7a9b65f7ade4d7e6cecffb._comment
new file mode 100644
index 0000000000..903469f4df
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_8_ef725153df7a9b65f7ade4d7e6cecffb._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 8"
+ date="2020-03-11T21:34:14Z"
+ content="""
+\"conda script looks gross, its opaque, and wants to install ms / vs code\" -- in its defense, conda is open-source and is very widely used, so any problems with it are unlikely to go undetected.  What is \"ms / vs\"?
+
+It _would_ be good at some point to create a Docker image with git-annex, that could operate sandboxed, but Docker doesn't handle symlinks well.
+
+\"this website is a train wreck\" -- the website is an editable wiki, so you can fix things yourself, or submit [[pull requests|forum/where_to_submit_pull_requests_for_git-annex?]].  But can I suggest you phrase things less... harshly?  @joeyh has done and is doing a crazy amount of work on git-annex and other public projects, demanding a perfect website on top of that is too much.
+"""]]
diff --git a/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__.mdwn b/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__.mdwn
new file mode 100644
index 0000000000..305629ada7
--- /dev/null
+++ b/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__.mdwn
@@ -0,0 +1,32 @@
+We have the correct symlink:
+
+    $ ls -lh Sita_Sings_the_Blues_480p_2150kbps.mp4 
+    lrwxrwxrwx 1 user user 204 Apr  8 20:22 Sita_Sings_the_Blues_480p_2150kbps.mp4 -> .git/annex/objects/6q/Wz/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4
+
+The object is in place:
+
+    $ ls -lh .git/annex/objects/6q/Wz/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4
+    -r-------- 1 user user 1,4G Dec 28  2010 .git/annex/objects/6q/Wz/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4
+
+Now I move the symlink, which becomes broken:
+
+    $ mv Sita_Sings_the_Blues_480p_2150kbps.mp4 Videos/
+
+I try to fix the symlink:
+
+    $ git annex sync
+    $ git annex fix Videos/Sita_Sings_the_Blues_480p_2150kbps.mp4 
+
+But it stays broken:
+
+    $ ls -lh Videos/Sita_Sings_the_Blues_480p_2150kbps.mp4 
+    lrwxrwxrwx 1 user user 204 Apr  8 20:22 Videos/Sita_Sings_the_Blues_480p_2150kbps.mp4 -> .git/annex/objects/6q/Wz/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4
+
+Ah, when I try to `git mv Sita_Sings_the_Blues_480p_2150kbps.mp4 Videos/`, 
+I am warned that the link is not under version control. How did the symlink get 
+made in the first place, if not by git-annex? It should be known, right?
+
+After I `git annex add`, I can `git mv` and then `git annex fix`.
+
+How did I get into the state where I have a symlink pointing at an imported
+object, which is not under version control?
diff --git a/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_1_865245182d765fed7bbeb42a35dd605e._comment b/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_1_865245182d765fed7bbeb42a35dd605e._comment
new file mode 100644
index 0000000000..df24ad53e9
--- /dev/null
+++ b/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_1_865245182d765fed7bbeb42a35dd605e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2015-04-08T14:29:59Z"
+ content="""
+'git annex fix' will only fix symlinks that git is tracking (either staged, or part of the repository) because git-annex uses git-ls-files (or something like that) to get the filenames to fix.
+
+'git annex add' adds the files to the annex and replaces them with symlinks, stages the symlinks but does not commit the symlinks.
+"""]]
diff --git a/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_2_c1f5a285b7cfb92d218b9b0d31caeed6._comment b/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_2_c1f5a285b7cfb92d218b9b0d31caeed6._comment
new file mode 100644
index 0000000000..f46aeac5b4
--- /dev/null
+++ b/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_2_c1f5a285b7cfb92d218b9b0d31caeed6._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2015-04-08T14:32:56Z"
+ content="""
+It's also funny that this has cropped up [just after I asked for git-annex to fix untracked symlinks](https://git-annex.branchable.com/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/) :P
+"""]]
diff --git a/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_3_be2816c47091842b829cd626e18c5fda._comment b/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_3_be2816c47091842b829cd626e18c5fda._comment
new file mode 100644
index 0000000000..731f4d2253
--- /dev/null
+++ b/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_3_be2816c47091842b829cd626e18c5fda._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnVnsqEy82M-MuS2gLri-az83wSQ6lXSrc"
+ nickname="Jean"
+ subject="comment 3"
+ date="2015-04-09T05:37:03Z"
+ content="""
+Hi CandyAngel, thanks for the pointer, I 
+[commented](http://git-annex.branchable.com/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/#comment-5251d819e83c66dbdd9d7bcee4a87f9f) there.
+"""]]
diff --git a/doc/forum/windows_port__63__.mdwn b/doc/forum/windows_port__63__.mdwn
new file mode 100644
index 0000000000..092b8f8e1c
--- /dev/null
+++ b/doc/forum/windows_port__63__.mdwn
@@ -0,0 +1,2 @@
+Any progress on Windows port? That would be very nice to have!
+Depending on the scale of it, I might be able to help.
diff --git a/doc/forum/windows_port__63__/comment_1_23fa9aa3b00940a1c1b3876c35eef019._comment b/doc/forum/windows_port__63__/comment_1_23fa9aa3b00940a1c1b3876c35eef019._comment
new file mode 100644
index 0000000000..95323ff997
--- /dev/null
+++ b/doc/forum/windows_port__63__/comment_1_23fa9aa3b00940a1c1b3876c35eef019._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2012-03-12T06:43:02Z"
+ content="""
+[[todo/windows_support]] has everything I know about making a windows port. This badly needs someone who understand Windows to dive into it. The question of how to create a symbolic link (or the relevant Windows equivilant) from haskell on Windows
+is a good starting point..
+"""]]
diff --git a/doc/forum/wishlist__58___get__47__drop_via_webapp_file_explorer.mdwn b/doc/forum/wishlist__58___get__47__drop_via_webapp_file_explorer.mdwn
new file mode 100644
index 0000000000..3be01480ea
--- /dev/null
+++ b/doc/forum/wishlist__58___get__47__drop_via_webapp_file_explorer.mdwn
@@ -0,0 +1 @@
+Know what'd be a sweet feature?  A file explorer in the webapp that lets you get and drop files (for a Manual local repository).  Especially when the webapp becomes available on Android.  I'd love to be able to select what is and isn't present on a small device by some means other than moving files around.
diff --git a/doc/forum/wishlist__58___get__47__drop_via_webapp_file_explorer/comment_1_c818a6d44dc13a56460b1865f70eb97c._comment b/doc/forum/wishlist__58___get__47__drop_via_webapp_file_explorer/comment_1_c818a6d44dc13a56460b1865f70eb97c._comment
new file mode 100644
index 0000000000..6cc0cf38bc
--- /dev/null
+++ b/doc/forum/wishlist__58___get__47__drop_via_webapp_file_explorer/comment_1_c818a6d44dc13a56460b1865f70eb97c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-04-11T14:55:43Z"
+ content="""
+There's a page called [[design/assistant/partial_content]] that discusses this idea and related things.
+"""]]
diff --git a/doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space.mdwn b/doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space.mdwn
new file mode 100644
index 0000000000..8896fee37a
--- /dev/null
+++ b/doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space.mdwn
@@ -0,0 +1,4 @@
+I'm trying to distribute a large annex to a number of smaller archive drives.
+
+While copying to a directory special remote, the current behaviour is to continue trying copying files into a remote, even as diskspace there has been exhausted.
+It would make sense for git-annex copy to actually stop instead.
diff --git a/doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space/comment_1_467e5e3db3e836030bc4b4f15846951f._comment b/doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space/comment_1_467e5e3db3e836030bc4b4f15846951f._comment
new file mode 100644
index 0000000000..5c5f17ca9d
--- /dev/null
+++ b/doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space/comment_1_467e5e3db3e836030bc4b4f15846951f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.140"
+ subject="comment 1"
+ date="2013-07-18T19:49:43Z"
+ content="""
+Hmm, it might make sense to stop if there is no more space at all. However, just because the first file doesn't fit doesn't mean several following, smaller files can't be copied into the remaining space.
+
+Since it checks the free space before actually copying anything, it's not like there's much overhead in running through the list of files it was asked to copy and trying to copy them all, either.
+
+So, I'm unconvinced on this one.
+"""]]
diff --git a/doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space/comment_2_e3ca3db9bea11d3e085ee9c3c56b33fe._comment b/doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space/comment_2_e3ca3db9bea11d3e085ee9c3c56b33fe._comment
new file mode 100644
index 0000000000..ee535549f3
--- /dev/null
+++ b/doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space/comment_2_e3ca3db9bea11d3e085ee9c3c56b33fe._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 2"
+ date="2013-07-18T20:22:05Z"
+ content="""
+Actually with 4.20130709, I see the drive (ntfs-3g under Linux, gpg-encrypted special remote) being filled to 0 remaining space, even with reservespace of 300mb.  Guess it's another bug anyway.
+"""]]
diff --git a/doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space/comment_3_0ef8c37350fc192d9b784fbab1d9f318._comment b/doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space/comment_3_0ef8c37350fc192d9b784fbab1d9f318._comment
new file mode 100644
index 0000000000..a33cbcd27c
--- /dev/null
+++ b/doc/forum/wishlist__58___make_copy_stop_on_exhausted_disk_space/comment_3_0ef8c37350fc192d9b784fbab1d9f318._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.140"
+ subject="comment 3"
+ date="2013-07-20T20:33:37Z"
+ content="""
+Indeed, that was a bug with encrypted directory special remotes. Fixed it.
+"""]]
diff --git a/doc/forum/working_without_git-annex_commits.mdwn b/doc/forum/working_without_git-annex_commits.mdwn
new file mode 100644
index 0000000000..00a61f3f0f
--- /dev/null
+++ b/doc/forum/working_without_git-annex_commits.mdwn
@@ -0,0 +1,20 @@
+Is it possible to use git-annex without having [[location tracking]] commits in the style of "got a video I want to rewatch on the plane" or "freed up space" in the main tree?
+
+I consider these changes to be volatile, and irrelevant to the archive history. While they are unproblematic when it comes to merging, they make the commit tree rather complicated, especially with multiple users (as opposed to a single user managing his files on an external disk, a server and his laptop). Some users might even want to contribute to a shared repository without reporting on what they checked out.
+
+As a minimal solution, I configured a repository to ``.gitignore`` ``.git-annex/*:*.log``, but even when using modes that do not require that information (``git annex copy --from`` instead of ``git annex get``), that failes when git-annex tried to git-add ignored files.
+
+A more elaborate solution might be to keep location tracking information in a branch on its own (as suggested in [[todo/branching]]), keeping the main tree clean of such commits. A stealth user could then configure that branch to never be pushed. (Alternatively, if git-annex respects .gitignore and doesn't try to check in changes on ignored files, he could locally ``.gitignore`` ``.git-annex/*:*.log``.)
+
+> A stealth user can simply avoid pushing, and so keep their repository 
+> in a forked state, that can still pull changes from origin.
+> 
+> Beyond that, [[todo/branching]] is the best solution.
+> 
+> I don't think that gitignoring the log files is a good plan, because
+> if the files are left modified and uncommitted, git will not be able to 
+> merge other changes it pulls. The automerging of log files only works
+> if any local changes to them have been committed.
+> 
+> It would be possible to add a knob that
+> simply blocks all local modifications to the log files. --[[Joey]]
diff --git a/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up.mdwn b/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up.mdwn
new file mode 100644
index 0000000000..ee3185ddcc
--- /dev/null
+++ b/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up.mdwn
@@ -0,0 +1,27 @@
+I am running git-annex on Mac OS 10.9 and syncing to a Linux device that was attached to a Synology NAS.  Both were running December versions of git-annex.
+
+While working on an application in IntelliJ my workspace.xml file disappeared.  It went from being a real file to being a symlink to a location that didn't exist.
+
+The symlink looks like this: workspace.xml -> ../../../.git/annex/objects/M2/8W/SHA256E-s68106--90e9cc4f617c9034db1bf462d058b82c59ade0be58de1d3a3e2f8c02606631c2.xml/SHA256E-s68106--90e9cc4f617c9034db1bf462d058b82c59ade0be58de1d3a3e2f8c02606631c2.xml
+
+I tried git-annex fsck and I get this message: ** No known copies exist of XXXXXXX/workspace.xml
+
+"XXXXXXX" is a path I needed to obscure I can see it in the git-annex repo but it is a reference to a symlink that doesn't exist
+
+It was mentioned in another thread ( http://git-annex.branchable.com/forum/git_annex_on_osx_only_creating_symlinks__63____63__/ ) that this could happen if I did a forced drop but I do not use git-annex on the command line.  I'm using the assistant and having it manage all of my files for me.
+
+I tried looking at the log for it and it shows this:
+
+<pre>
+timmattison$ /Applications/git-annex.app/Contents/MacOS/git-annex log XXXXXXX/.idea/workspace.xml 
+- 2014-01-03 19:49:58 XXXXXXX/.idea/workspace.xml | d6747880-b355-4d41-b4e5-d1ad3afcb4a5 -- timmattison@MacBook-Pro.local:~/Desktop/annex
++ 2014-01-03 17:08:32 XXXXXXX/.idea/workspace.xml | d6747880-b355-4d41-b4e5-d1ad3afcb4a5 -- timmattison@MacBook-Pro.local:~/Desktop/annex
+(Recording state in git...)
+</pre>
+
+So I can see that the git-annex thinks the file was deleted but what really happened is that IntelliJ just modified it.  workspace.xml files are modified very often when working in IntelliJ.
+
+Is this a known bug that has been fixed in the new version (2013-12-30 or later)?
+
+Thanks,
+Tim
diff --git a/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_1_00b084f9786de6516f46065c0cb00e79._comment b/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_1_00b084f9786de6516f46065c0cb00e79._comment
new file mode 100644
index 0000000000..32e4972ca1
--- /dev/null
+++ b/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_1_00b084f9786de6516f46065c0cb00e79._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 1"
+ date="2014-01-06T18:38:51Z"
+ content="""
+If the file was modified, git-annex should notice and add the new version. So the mere act of modifying the file does not explain how you ended up with a symlink to the old version of the file. Although it does explain why git-annex log would show that the old version of the file had been deleted.
+
+What does `git log` say when run on the workspace.xml file?
+
+"""]]
diff --git a/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_2_138499b36d28c5e267b4aad8792dc87e._comment b/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_2_138499b36d28c5e267b4aad8792dc87e._comment
new file mode 100644
index 0000000000..1407a8ad36
--- /dev/null
+++ b/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_2_138499b36d28c5e267b4aad8792dc87e._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkipQLNyt8RHREHpg2k5wdYeRSCCvSNSBg"
+ nickname="Tim"
+ subject="git log for workspace.xml"
+ date="2014-01-06T19:17:13Z"
+ content="""
+git log on the file gives a ton of output, is this what you need?
+
+commit 93157022d8ee57097db29fcc669e99e218b54657
+Author: Tim Mattison <tim.mattison@email.com>
+Date:   Fri Jan 3 17:08:03 2014 -0500
+
+commit 04dab5520f33140a21882515b4036f71729a5f89
+Author: Tim Mattison <tim.mattison@email.com>
+Date:   Fri Jan 3 17:06:54 2014 -0500
+
+commit b75be90bf91c9f9314e567d5a28e4497070de9af
+Author: Tim Mattison <tim.mattison@email.com>
+Date:   Fri Jan 3 16:58:24 2014 -0500
+
+commit 4045b2d7a71b9ab692c20eeab73bf196a280940d
+Author: Tim Mattison <tim.mattison@email.com>
+Date:   Fri Jan 3 16:58:05 2014 -0500
+
+commit 25de8a1fcd5cce53b8077443dccba1591255431f
+Author: Tim Mattison <tim.mattison@email.com>
+Date:   Fri Jan 3 16:57:32 2014 -0500
+
+commit dd118ae88cdccb5a7d68a7ae14033304865cfc4e
+Author: Tim Mattison <tim.mattison@email.com>
+Date:   Fri Jan 3 16:53:37 2014 -0500
+
+commit eaa5f85b7feed8ba17e3874763b4d7aa6e05b5c1
+Author: Tim Mattison <tim.mattison@email.com>
+Date:   Fri Jan 3 16:53:23 2014 -0500
+
+commit 4d310d7d16234a1a6bcf0f14ebae232c57d904a7
+Author: Tim Mattison <tim.mattison@email.com>
+Date:   Fri Jan 3 16:52:42 2014 -0500
+
+commit 2487ae7f99c7b81c1648fdc88d0b39a1cf6e4d03
+Author: Tim Mattison <tim.mattison@email.com>
+Date:   Fri Jan 3 16:52:21 2014 -0500
+
+commit 9e0040311c43e6e1f04ff3b8fdd3ac5570c8f2d1
+Author: Tim Mattison <tim.mattison@email.com>
+Date:   Fri Jan 3 16:51:54 2014 -0500
+"""]]
diff --git a/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_3_6c59c494b563e56d061417eb2216bb19._comment b/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_3_6c59c494b563e56d061417eb2216bb19._comment
new file mode 100644
index 0000000000..f31e7cf4da
--- /dev/null
+++ b/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_3_6c59c494b563e56d061417eb2216bb19._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkipQLNyt8RHREHpg2k5wdYeRSCCvSNSBg"
+ nickname="Tim"
+ subject="Formatting!"
+ date="2014-01-06T19:22:36Z"
+ content="""
+I swear, some day I'll get the formatting correct.  Sorry!
+"""]]
diff --git a/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_4_ccbba61cdd6fce3e5de82417bcc0cbfb._comment b/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_4_ccbba61cdd6fce3e5de82417bcc0cbfb._comment
new file mode 100644
index 0000000000..3ca8a6295f
--- /dev/null
+++ b/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_4_ccbba61cdd6fce3e5de82417bcc0cbfb._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkipQLNyt8RHREHpg2k5wdYeRSCCvSNSBg"
+ nickname="Tim"
+ subject="Just happened again"
+ date="2014-01-16T16:23:00Z"
+ content="""
+This happened again and now I have this:
+
+lrwxr-xr-x  1 timmattison  staff  197 Jan 16 11:18 distribute-client-applications.sh -> ../../../.git/annex/objects/JV/91/SHA256E-s921--51fc6a6e2924ff6e2673971b5786fe0f204a5984a700a2241cc77383f04f544e.sh/SHA256E-s921--51fc6a6e2924ff6e2673971b5786fe0f204a5984a700a2241cc77383f04f544e.sh
+
+This was on the machine that had the file, not a remote machine it was syncing to.  I was editing the script, I ran it, the bash script segfaulted (expected), and then git-annex essentially deleted the file.  Can you help me understand why this happens?  It's obvious when it is a file I'm working on but I'm afraid it could be happening to other files and I don't know about it.
+"""]]
diff --git a/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_5_50526283b35997cece2f087507cdd4ee._comment b/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_5_50526283b35997cece2f087507cdd4ee._comment
new file mode 100644
index 0000000000..ebf175cf22
--- /dev/null
+++ b/doc/forum/workspace.xml_file_disappeared__44___broken_symlink_showed_up/comment_5_50526283b35997cece2f087507cdd4ee._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.146"
+ subject="comment 5"
+ date="2014-03-06T18:22:31Z"
+ content="""
+Do you edit this file in multiple places? This could be an occurance of this bug: [[bugs/direct_mode_merge_can_overwrite_local,_non-annexed_files]] which is fixed in the latest release.
+
+If the program that writes the workspace.xml file did so by first deleting it, and then writing the new version, this could result in the assistant committing the deletion, which makes the new version a local, non-annexed file, and then if a pull is received that modified the file, I think the above bug could happen. 
+
+You could tell if this was the case by looking at the git log of the directory containing the file, and see if it has been repeatedly deleted and added back to the repository. The git log snippet you pasted unfortunately does not let me tell this information.
+"""]]
diff --git a/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__.mdwn b/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__.mdwn
new file mode 100644
index 0000000000..2332f1bd52
--- /dev/null
+++ b/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__.mdwn
@@ -0,0 +1,7 @@
+Hello people :)
+
+I'm learning to use git annex and I'm doing some tests to know how it works from an user point of view... My big goal would be to use git annex to track my entire /home directory in direct mode, so I would be able to sync my main computer with my laptop in a really effective way. But of course I feel some fear because things could go wrong and of course I have lots of important files I can't lose —nothing really important since I'll backup that /home in an external hard drive, but it would make me cry if I have to spend some hours restoring my /home :S
+
+So, do you think that tracking all the /home would be a reasonable goal?
+
+Thanks a lot for your time :)
diff --git a/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_1_b011442de2f67f3ad340031a0767e990._comment b/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_1_b011442de2f67f3ad340031a0767e990._comment
new file mode 100644
index 0000000000..94d07524bc
--- /dev/null
+++ b/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_1_b011442de2f67f3ad340031a0767e990._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 1"
+ date="2013-12-09T06:07:00Z"
+ content="""
+I do track my home dir using annex, but instead of one giant annex I have multiple annex repos. It is much faster than one giant annex and when used in combination with mr you can threat all repos as one. 
+"""]]
diff --git a/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_2_c69865c08c3eb49d64310fc76e80c65d._comment b/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_2_c69865c08c3eb49d64310fc76e80c65d._comment
new file mode 100644
index 0000000000..e74d169459
--- /dev/null
+++ b/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_2_c69865c08c3eb49d64310fc76e80c65d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawleVyKk2kQsB_HgEdS7w1s0BmgRGy1aay0"
+ nickname="Milan"
+ subject="comment 2"
+ date="2013-12-09T11:16:48Z"
+ content="""
+what is 'mr'?
+"""]]
diff --git a/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_3_7651fb48fc71b2c7b4e7b6830a0f9865._comment b/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_3_7651fb48fc71b2c7b4e7b6830a0f9865._comment
new file mode 100644
index 0000000000..669046584e
--- /dev/null
+++ b/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_3_7651fb48fc71b2c7b4e7b6830a0f9865._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8"
+ nickname="Hamza"
+ subject="comment 3"
+ date="2013-12-09T14:56:13Z"
+ content="""
+It [1] allows you to run commands on a set of repositories.
+
+[1] http://myrepos.branchable.com/
+"""]]
diff --git a/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_4_7d88f1aa163185c801b7697846086c7f._comment b/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_4_7d88f1aa163185c801b7697846086c7f._comment
new file mode 100644
index 0000000000..3e4c8aeb2e
--- /dev/null
+++ b/doc/forum/would_you_call_me_crazy_if_I_use_git_annex_in_direct_mode_to_track_my___47__home__63____63__/comment_4_7d88f1aa163185c801b7697846086c7f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlqimC5gbxsILaBlnuVXYtfSMDIhiyvHfw"
+ nickname="Valentín"
+ subject="comment 4"
+ date="2013-12-10T19:34:06Z"
+ content="""
+Hi Hamza :)
+
+I like your way of achieving the same goal —and existing ``mr``, which I hadn't known until now, it looks like the best alternative.
+
+Thanks a lot for your time :)
+"""]]
diff --git a/doc/future_proofing.mdwn b/doc/future_proofing.mdwn
new file mode 100644
index 0000000000..369aa7d890
--- /dev/null
+++ b/doc/future_proofing.mdwn
@@ -0,0 +1,53 @@
+Imagine putting a git-annex drive in a time capsule. In 20, or 50, or 100
+years, you'd like its contents to be as accessible as possible to whoever
+digs it up.
+
+This is a hard problem. git-annex cannot completely solve it, but it does
+its best to not contribute to the problem. Here are some aspects of the
+problem:
+
+* How are files accessed? Git-annex carefully adds minimal complexity
+  to access files in a repository. Nothing needs to be done to extract
+  files from the repository; they are there on disk in the usual way,
+  with just some symlinks pointing at the annexed file contents.
+  Neither git-annex nor git is needed to get at the file contents.
+  
+  (Also, git-annex provides an "uninit" command that moves everything out
+  of the annex, if you should ever want to stop using it.)
+
+* What file formats are used? Will they still be readable? To deal with
+  this, it's best to stick to plain text files, and the most common
+  image, sound, etc formats. Consider storing the same content in multiple
+  formats.
+
+* What filesystem is used on the drive? Will that filesystem still be
+  available? Whatever you choose to use, git-annex can put files on it.
+  Even if you choose (ugh) FAT.
+
+* What is the hardware interface of the drive? Will hardware still exist
+  to talk to it?
+
+* What if some of the data is damaged? git-annex facilitates storing a
+  configurable number of [[copies]] of the file contents. The metadata
+  about your files is stored in git, and so every clone of the repository
+  means another copy of that is stored. Also, git-annex uses filenames
+  for the data that encode everything needed to match it back to the
+  metadata. So if a filesystem is badly corrupted and all your annexed
+  files end up in `lost+found`, they can easily be lifted back out into
+  another clone of the repository. Even if the filenames are lost,
+  it's possible to [[tips/recover_data_from_lost+found]].
+
+* What about upgrades to the git-annex repository format?
+  git-annex supports [[upgrades]] from all previous repository versions,
+  and will always support upgrading from all of them to any new versions.
+  Note that the upgrade process needs to modify the content of the
+  repository -- if modifying the original archived repository is not
+  desirable you can always make a copy of the repository and upgrade the
+  copy.
+
+* What about encrypted special remotes? A 
+  [[fairly simple shell script using standard tools|tips/Decrypting_files_in_special_remotes_without_git-annex]]
+  (gpg and openssl) can decrypt files stored on such
+  a remote, as long as you have access to the encryption keys (which
+  are stored in the git-annex branch of the repository, sometimes
+  encrypted with your gpg key).
diff --git a/doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment b/doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment
new file mode 100644
index 0000000000..dbe429fa9c
--- /dev/null
+++ b/doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~electrichead"
+ nickname="electrichead"
+ subject="Regarding accessing files in a time capsule..."
+ date="2014-08-25T15:51:00Z"
+ content="""
+Imagine a rather contrived doomsday scenario: the file paths and/or basenames are important and, for some reason, the symlinks are not present (perhaps they got deleted, or aren't supported). `git` and `git-annex` no longer exist and let's assume knowledge of `git` internals is not useful here. All the *content* is there, stored under hashed file names under `.git/annex/objects`.
+
+I may be missing something obvious but I think options for restoring file paths include:
+
+  - direct mode bypasses this issue; all the files are right there. 
+  - the WORM backend perhaps carries enough information in the object file names to work with.
+  - file content/metadata may be sufficient to easily recreate a sensible directory structure in some cases, so no worries.
+
+These first two options may represent compromises in various use-cases and the last may not be applicable or, if it is, practical. The object-path mapping could trivially be backed up in plain text in lieu of these. Like I said, I may be overlooking something here that makes this unnecessary or even a non-concern (actually, I've convinced myself it's not a serious concern in most of the use-cases I've considered, but crossing i's and dotting t's).
+"""]]
diff --git a/doc/git-annex-add.mdwn b/doc/git-annex-add.mdwn
new file mode 100644
index 0000000000..a4b6d95208
--- /dev/null
+++ b/doc/git-annex-add.mdwn
@@ -0,0 +1,137 @@
+# NAME
+
+git-annex add - adds files to the git annex
+
+# SYNOPSIS
+
+git annex add `[path ...]`
+
+# DESCRIPTION
+
+Adds the specified files to the annex. If a directory is specified,
+acts on all files inside the directory and its subdirectories.
+If no path is specified, adds files from the current directory and below.
+
+Files that are already checked into git and are unmodified, or that
+git has been configured to ignore will be silently skipped.
+
+If annex.largefiles is configured (in git config, gitattributes, or
+git-annex config), and does not match a file, `git annex add` will behave
+the same as `git add` and add the non-large file directly to the git
+repository, instead of to the annex. (By default dotfiles are assumed to
+not be large, and are added directly to git, but annex.dotfiles can be
+configured to annex those too.) See the git-annex manpage for documentation
+of these and other configuration settings.
+
+By default, large files are added to the annex in locked form, which
+prevents further modification of their content until
+unlocked by [[git-annex-unlock]](1). (This is not the case however
+when a repository is in a filesystem not supporting symlinks.)
+The annex.addunlocked git config (and git-annex config) can be used to
+change this behavior.
+
+This command can also be used to add symbolic links, both symlinks to
+annexed content, and other symlinks.
+
+# EXAMPLES
+
+	# git annex add foo bar
+	add foo ok
+	add bar ok
+	# git commit -m added
+
+# OPTIONS
+
+* `--no-check-gitignore`
+
+  Add gitignored files.
+
+* `--force-large`
+
+  Treat all files as large files, ignoring annex.largefiles and annex.dotfiles
+  configuration, and add to the annex.
+
+* `--force-small`
+
+  Treat all files as small files, ignoring annex.largefiles and annex.dotfiles
+  and annex.addsmallfiles configuration, and add to git.
+
+* `--backend`
+
+  Specifies which key-value backend to use.
+
+* file matching options
+
+  Many of the [[git-annex-matching-options]](1)
+  can be used to specify files to add.
+
+  For example: `--largerthan=1GB`
+
+* `--jobs=N` `-JN`
+
+  Adds multiple files in parallel. This may be faster.
+  For example: `-J4`  
+
+  Setting this to "cpus" will run one job per CPU core.
+
+* `--update` `-u`
+
+  Like `git add --update`, this does not add new files, but any updates
+  to tracked files will be added to the index.
+
+* `--dry-run`
+
+  Output what would be done for each file, but avoid making any changes.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-progress`
+
+  Include progress objects in JSON output.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* `--batch`
+
+  Enables batch mode, in which a file to add is read in a line from stdin,
+  the file is added, and repeat.
+
+  Note that if a file is skipped (due to not existing, being gitignored,
+  already being in git, or doesn't meet the matching options), 
+  an empty line will be output instead of the normal output produced
+  when adding a file.
+
+* `-z`
+
+  Makes the `--batch` input be delimited by nulls instead of the usual
+  newlines.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-unlock]](1)
+
+[[git-annex-lock]](1)
+
+[[git-annex-undo]](1)
+
+[[git-annex-import]](1)
+
+[[git-annex-unannex]](1)
+
+[[git-annex-reinject]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-add/comment_1_0e6b855afb4fba540ea5560df26839c5._comment b/doc/git-annex-add/comment_1_0e6b855afb4fba540ea5560df26839c5._comment
new file mode 100644
index 0000000000..d233d96d15
--- /dev/null
+++ b/doc/git-annex-add/comment_1_0e6b855afb4fba540ea5560df26839c5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="annex.largefiles"
+ date="2021-01-01T21:25:43Z"
+ content="""
+Does annex.largefiles has some documentation? It would be nice to link to that on the doc of git-annex-add.
+
+Esp, after reading this, I wonder about the default value of annex.largefiles. (I assume/hope it is disabled?)
+
+"""]]
diff --git a/doc/git-annex-add/comment_2_43cf725964c63a2d2545d9f204316a57._comment b/doc/git-annex-add/comment_2_43cf725964c63a2d2545d9f204316a57._comment
new file mode 100644
index 0000000000..2b390d980d
--- /dev/null
+++ b/doc/git-annex-add/comment_2_43cf725964c63a2d2545d9f204316a57._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="Adding external files"
+ date="2021-01-01T21:30:38Z"
+ content="""
+Let's assume I have some external files in my `~/Pictures` and I want to import them.
+
+Should I use `git annex import ~/Pictures/BestPics2020` or `cp -r ~/Pictures/BestPics2020 .; git annex add BestPics2020`? Is there a difference? Which way would be recommended or preferred?
+
+"""]]
diff --git a/doc/git-annex-add/comment_3_8517f9634d217f731efd704405d3f2ca._comment b/doc/git-annex-add/comment_3_8517f9634d217f731efd704405d3f2ca._comment
new file mode 100644
index 0000000000..1cc51ec209
--- /dev/null
+++ b/doc/git-annex-add/comment_3_8517f9634d217f731efd704405d3f2ca._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2021-01-02T15:12:49Z"
+ content="""
+The various configuration options are documented in the main [[git-annex]] manpage, at the bottom.
+
+If it is a one-shot, just use `cp/mv` and `git annex add`. If you want to frequently import from that location, use directory special-remotes with importtree=yes.
+"""]]
diff --git a/doc/git-annex-add/comment_4_3bbbe94633b6cb4ef93b7942eb36cc6c._comment b/doc/git-annex-add/comment_4_3bbbe94633b6cb4ef93b7942eb36cc6c._comment
new file mode 100644
index 0000000000..f13b663199
--- /dev/null
+++ b/doc/git-annex-add/comment_4_3bbbe94633b6cb4ef93b7942eb36cc6c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="comment 4"
+ date="2021-01-02T16:23:05Z"
+ content="""
+But is there a difference to `git annex import`? What is the difference? Why would you use `git annex add` instead of `git annex import`?
+
+"""]]
diff --git a/doc/git-annex-add/comment_5_f67bd5fdbe9deeeea1d48175a6b5c536._comment b/doc/git-annex-add/comment_5_f67bd5fdbe9deeeea1d48175a6b5c536._comment
new file mode 100644
index 0000000000..a9148f4234
--- /dev/null
+++ b/doc/git-annex-add/comment_5_f67bd5fdbe9deeeea1d48175a6b5c536._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-01-04T17:34:56Z"
+ content="""
+You use `git-annex add` when you have a file located
+inside your git-annex repository, which you want to check in.
+
+You use `git-annex import` when you have some other thing
+storing files and you want git-annex to learn about the files stored there.
+Using git-annex import to move individual files to the repository and add
+them is not significantly different than mv+add and will eventually be
+deprecated.
+"""]]
diff --git a/doc/git-annex-add/comment_6_be9e67994aacebedb478f68a8ae542a5._comment b/doc/git-annex-add/comment_6_be9e67994aacebedb478f68a8ae542a5._comment
new file mode 100644
index 0000000000..ba93f9a273
--- /dev/null
+++ b/doc/git-annex-add/comment_6_be9e67994aacebedb478f68a8ae542a5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="lh"
+ avatar="http://cdn.libravatar.org/avatar/d31bade008d7da493d9bfb37d68fd825"
+ subject="recording state in git"
+ date="2022-04-13T23:56:09Z"
+ content="""
+Why does git-annex-add record state in Git? This means if you change your mind before committing and unannex some files, those files are still left in the annex. Semantically, this makes git-annex-add feel more like a commit operation, which is confusing given the name.
+
+Furthermore, to forcibly drop these files, you have to take the output `git annex whereused --unused --historical` and compare it against the output of `git annex unused` to get a list of files that don't show up anywhere in the history. This is rather cumbersome for dropping files you never committed.
+
+Couldn't the `git-annex` branch use the index, like git itself, so unannexing wouldn't leave you with extraneous files?
+
+I get the safety perspective, but I feel like that's what `git commit` (and a hypothetical `git annex commit`) should be for. The staging area is useful to verify you're actually committing what you want. I know I'm probably a decade late here, but I'd be interested to hear your thoughts, anyway. It seems weird to deviate from git here.
+"""]]
diff --git a/doc/git-annex-add/comment_7_bb9d72f90f4d3c93d71de1a1bbc244b6._comment b/doc/git-annex-add/comment_7_bb9d72f90f4d3c93d71de1a1bbc244b6._comment
new file mode 100644
index 0000000000..166bd2e14d
--- /dev/null
+++ b/doc/git-annex-add/comment_7_bb9d72f90f4d3c93d71de1a1bbc244b6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-04-19T16:09:12Z"
+ content="""
+@lh I don't feel this man page's comment section is the place to discuss
+this in detail. But suffice to say that even if add behaved the way you
+suggest, any other git-annex command can commit the accumulated changes
+to the git-annex branch at any time. So the change would not guarantee
+the behavior you hope for.
+
+But, you can set annex.alwayscommit to false and run `git-annex merge`
+when you do want to commit changes to the git-annex branch.
+"""]]
diff --git a/doc/git-annex-addunused.mdwn b/doc/git-annex-addunused.mdwn
new file mode 100644
index 0000000000..ff6155c440
--- /dev/null
+++ b/doc/git-annex-addunused.mdwn
@@ -0,0 +1,42 @@
+# NAME
+
+git-annex addunused - add back unused files
+
+# SYNOPSIS
+
+git annex addunused `[number|range ...]`
+
+# DESCRIPTION
+
+Adds back files for the content corresponding to the numbers or ranges,
+as listed by the last `git annex unused`. 
+
+The files will have names starting with "unused."
+
+# OPTIONS
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* The [[git-annex-common-options]](1) can also be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-add]](1)
+
+[[git-annex-unused]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-addurl.mdwn b/doc/git-annex-addurl.mdwn
new file mode 100644
index 0000000000..769bed69a7
--- /dev/null
+++ b/doc/git-annex-addurl.mdwn
@@ -0,0 +1,190 @@
+# NAME
+
+git-annex addurl - add urls to annex
+
+# SYNOPSIS
+
+git annex addurl `[url ...]`
+
+# DESCRIPTION
+
+Downloads each url to its own file, which is added to the annex.
+
+When `yt-dlp` is installed, it can be used to check for a video
+embedded in  a web page at the url, and that is added to the annex instead.
+(However, this is disabled by default as it can be a security risk. 
+See the documentation of annex.security.allowed-ip-addresses
+in [[git-annex]](1) for details.)
+
+Special remotes can add other special handling of particular urls. For
+example, the bittorrent special remotes makes urls to torrent files
+(including magnet links) download the content of the torrent,
+using `aria2c`.
+
+Normally the filename is based on the full url, so will look like
+"www.example.com_dir_subdir_bigfile". In some cases, addurl is able to
+come up with a better filename based on other information. Options can also
+be used to get better filenames.
+
+# OPTIONS
+
+* `--fast`
+
+  Avoid immediately downloading the url. The url is still checked
+  (via HEAD) to verify that it exists, and to get its size if possible.
+
+* `--relaxed`
+
+  Don't immediately download the url, and avoid storing the size of the
+  url's content. This makes git-annex accept whatever content is there
+  at a future point.
+
+  This is the fastest option, but it still has to access the network
+  to check if the url contains embedded media. When adding large numbers
+  of urls, using `--relaxed --raw` is much faster.
+
+* `--verifiable` `-V`
+
+  This can be used with the `--fast` or `--relaxed` option. It improves
+  the safety of the resulting annexed file, by letting its content be
+  verified with a checksum when it is transferred between git-annex
+  repositories, as well as by things like `git-annex fsck`.
+
+  When used with --relaxed, content from the web will always be accepted,
+  even if it has changed, and the checksum recorded for later verification.
+
+  When used with --fast, the checksum is recorded the first time the
+  content is downloaded from the web. Once a checksum has been recorded,
+  subsequent downloads from the web must have the same checksum.
+
+  When addurl was used without this option before, the file it added 
+  can be converted to be verifiable by migrating it to the VURL backend.
+  For example: `git-annex migrate foo --backend=VURL`
+
+* `--raw`
+
+  Prevent special handling of urls by yt-dlp, and by bittorrent
+  and other special remotes. This will for example, make addurl
+  download the .torrent file and not the contents it points to.
+
+* `--no-raw`
+
+  Require content pointed to by the url to be downloaded using yt-dlp
+  or a special remote, rather than the raw content of the url. if that
+  cannot be done, the add will fail.
+
+* `--raw-except=remote`
+
+  Prevent special handling of urls by all special remotes except
+  for the specified one. To allow special handling only
+  by yt-dlp, use `--raw-except=web`.
+
+* `--file=name`
+
+  Use with a filename that does not yet exist to add a new file
+  with the specified name and the content downloaded from the url.
+
+  If the file already exists, addurl will record that it can be downloaded
+  from the specified url(s).
+
+* `--preserve-filename`
+
+   When the web server (or torrent, etc) provides a filename, use it as-is,
+   avoiding sanitizing unusual characters, or truncating it to length, or any
+   other modifications.
+
+   git-annex will still check the filename for safety, and if the filename
+   has a security problem such as path traversal or a control character,
+   it will refuse to add it.
+
+* `--pathdepth=N`
+
+  Rather than basing the filename on the whole url, this causes a path to
+  be constructed, starting at the specified depth within the path of the
+  url.
+
+  For example, adding the url http://www.example.com/dir/subdir/bigfile
+  with `--pathdepth=1` will use "dir/subdir/bigfile",
+  while `--pathdepth=3` will use "bigfile". 
+
+  It can also be negative; `--pathdepth=-2` will use the last
+  two parts of the url.
+
+* `--prefix=foo` `--suffix=bar`
+
+  Use to adjust the filenames that are created by addurl. For example,
+  `--suffix=.mp3` can be used to add an extension to the file.
+
+* `--no-check-gitignore`
+
+  By default, gitignores are honored and it will refuse to download an
+  url to a file that would be ignored. This makes such files be added
+  despite any ignores.
+
+* `--jobs=N` `-JN`
+
+  Enables parallel downloads when multiple urls are being added.
+  For example: `-J4`  
+
+  Setting this to "cpus" will run one job per CPU core.
+
+* `--batch`
+
+  Enables batch mode, in which lines containing urls to add are read from
+  stdin.
+
+* `-z`
+
+  Makes the `--batch` input be delimited by nulls instead of the usual
+  newlines. 
+
+* `--with-files`
+
+  When batch mode is enabled, makes it parse lines of the form: "$url $file"
+
+  That adds the specified url to the specified file, downloading its
+  content if the file does not yet exist; the same as
+  `git annex addurl $url --file $file`
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-progress`
+
+  Include progress objects in JSON output.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* `--backend`
+
+  Specifies which key-value backend to use.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# CAVEATS
+
+If annex.largefiles is configured, and does not match a file, `git annex
+addurl` will add the non-large file directly to the git repository,
+instead of to the annex. However, this is not done when --fast or --relaxed
+is used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-rmurl]](1)
+
+[[git-annex-registerurl]](1)
+
+[[git-annex-importfeed]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-addurl/comment_10_66051cf22495e661828f2ef3291f8578._comment b/doc/git-annex-addurl/comment_10_66051cf22495e661828f2ef3291f8578._comment
new file mode 100644
index 0000000000..da7bb9dc6c
--- /dev/null
+++ b/doc/git-annex-addurl/comment_10_66051cf22495e661828f2ef3291f8578._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-02-01T16:24:23Z"
+ content="""
+@m15 this page is not a bug tracking system. File bug reports over at
+[[bugs]].
+"""]]
diff --git a/doc/git-annex-addurl/comment_11_a09a85bbabc112369ab661b7ac5f277d._comment b/doc/git-annex-addurl/comment_11_a09a85bbabc112369ab661b7ac5f277d._comment
new file mode 100644
index 0000000000..5916786001
--- /dev/null
+++ b/doc/git-annex-addurl/comment_11_a09a85bbabc112369ab661b7ac5f277d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="tomdhunt"
+ avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
+ subject="Hashes for files added via addurl"
+ date="2022-07-16T20:12:20Z"
+ content="""
+If you add a file to your repo first via `addurl --fast`, it writes the filename as a symlink to a file that incorporates the URL, rather than the file hash. This is expected, since git-annex can't know the file hash until it's actually downloaded the file.
+
+If you then `git annex get` that file, it downloads the file to the path that uses the URL. Is the hash ever recorded for these files? If you were to drop and re-download the file, would git-annex accept a different file?
+"""]]
diff --git a/doc/git-annex-addurl/comment_12_f75e35ae6f739e98aeb15c3f8708be8a._comment b/doc/git-annex-addurl/comment_12_f75e35ae6f739e98aeb15c3f8708be8a._comment
new file mode 100644
index 0000000000..5b5b456347
--- /dev/null
+++ b/doc/git-annex-addurl/comment_12_f75e35ae6f739e98aeb15c3f8708be8a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="checksums and addurl --fast"
+ date="2022-07-18T16:01:41Z"
+ content="""
+>Is the hash ever recorded for these files?  If you were to drop and re-download the file, would git-annex accept a different file?
+
+Hash is not recorded, but file size is.   You can disable the size check with `--relaxed`. See [[tips/using_the_web_as_a_special_remote]].
+After [[`git-annex-get`|git-annex-get]]ting the file, you can use [[`git-annex-migrate`|git-annex-migrate]] to record it under a new checksum-based hash, then use [[`git-annex-unused`|git-annex-unused]] to find and remove the old key.
+
+Sometimes you can get the hash without downloading the file, e.g. if the hash is stored next to the file at `http://my/file.md5`, or if the file is stored in the Google Cloud. Then you can use the plumbing commands [[`git-annex-registerurl`|git-annex-registerurl]] to associate the checksum-based key with the URL, and [[`git-annex-setpresentkey`|git-annex-setpresentkey]] to record the key's presence in the (web) remote.
+
+Related discussion: [[todo/alternate_keys_for_same_content]]
+"""]]
diff --git a/doc/git-annex-addurl/comment_13_f413cc1febfa70e3ad885c6fa031a209._comment b/doc/git-annex-addurl/comment_13_f413cc1febfa70e3ad885c6fa031a209._comment
new file mode 100644
index 0000000000..270b0ed7a5
--- /dev/null
+++ b/doc/git-annex-addurl/comment_13_f413cc1febfa70e3ad885c6fa031a209._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="matthias.risze@9f2c8f7faed4cac1905d1bf1ee4524d708c13688"
+ nickname="matthias.risze"
+ avatar="http://cdn.libravatar.org/avatar/c9f7f022a1d62c39497b72c56a6a535e"
+ subject="Limitations on allowed characters in and length of URLs"
+ date="2023-01-04T11:56:35Z"
+ content="""
+Are there any limitations on which characters are allowed in an URL, and on how long an URL can be? I am working on a special remote which kind of abuses this feature by saving information about how to get the file in the URL with a specific scheme. For now it seems like I can use URLs of the form `scheme:<arbitrary json>`, but I am not sure if this might become an issue later. I could also encode the data with base64 or something similar, in which case size limitations would still be relevant; if there are any. Although, the json variant has the added benefit of being much more easily readable in whereis output.
+"""]]
diff --git a/doc/git-annex-addurl/comment_14_5719924fbda2daabe83ef2fde447d620._comment b/doc/git-annex-addurl/comment_14_5719924fbda2daabe83ef2fde447d620._comment
new file mode 100644
index 0000000000..0d78b01871
--- /dev/null
+++ b/doc/git-annex-addurl/comment_14_5719924fbda2daabe83ef2fde447d620._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2023-01-16T19:09:35Z"
+ content="""
+@matthias.risze length is not an issue. You should avoid characters that
+are not usually in urls, particularly whitespace and newline.
+
+It seems to me though that your special remote would perhaps
+be better served by using the SETSTATE and GETSTATE commands
+(see [[design/external_special_remote_protocol]])
+"""]]
diff --git a/doc/git-annex-addurl/comment_15_460d474cb8ef32d41eae71ee070de0b3._comment b/doc/git-annex-addurl/comment_15_460d474cb8ef32d41eae71ee070de0b3._comment
new file mode 100644
index 0000000000..1c8f523eb5
--- /dev/null
+++ b/doc/git-annex-addurl/comment_15_460d474cb8ef32d41eae71ee070de0b3._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="jt"
+ avatar="http://cdn.libravatar.org/avatar/920cb5f2bc783736e679d046aa7cf987"
+ subject="securehashesonly conflicts with addurl"
+ date="2023-03-25T03:22:50Z"
+ content="""
+Turning on `securehashesonly` seems to disable the `addurl` command:
+
+```console
+% git config --get annex.securehashesonly
+true
+% git annex addurl https://www.gutenberg.org/cache/epub/2591/pg2591-images.html
+addurl https://www.gutenberg.org/cache/epub/2591/pg2591-images.html
+  annex.securehashesonly blocked transfer of URL key
+failed
+addurl: 1 failed
+% git annex addurl https://www.gutenberg.org/cache/epub/2591/pg2591-images.html --relaxed
+addurl https://www.gutenberg.org/cache/epub/2591/pg2591-images.html (to www.gutenberg.org_cache_epub_2591_pg2591-images.html) ok
+(recording state in git...)
+% ls -l www.gutenberg.org_cache_epub_2591_pg2591-images.html
+www.gutenberg.org_cache_epub_2591_pg2591-images.html -> .git/annex/objects/gg/kG/URL--https&c%%www.gutenberg.org%cache%epub%2591%pg2591-images.html/URL--https&c%%www.gutenberg.org%cache%epub%2591%pg2591-images.html
+```
+
+Does this have something to do with the URL prefix that the annex object has?
+
+
+"""]]
diff --git a/doc/git-annex-addurl/comment_16_c6e1743647bb4d45b5a1b237f53d77a6._comment b/doc/git-annex-addurl/comment_16_c6e1743647bb4d45b5a1b237f53d77a6._comment
new file mode 100644
index 0000000000..78b1fb9b8d
--- /dev/null
+++ b/doc/git-annex-addurl/comment_16_c6e1743647bb4d45b5a1b237f53d77a6._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: securehashesonly conflicts with addurl"""
+ date="2023-03-27T17:59:35Z"
+ content="""
+Opened a bug report: [[bugs/securehashesonly_conflicts_with_addurl]]
+"""]]
diff --git a/doc/git-annex-addurl/comment_1_ce9c660be160a22c28aeb6de8b3b5818._comment b/doc/git-annex-addurl/comment_1_ce9c660be160a22c28aeb6de8b3b5818._comment
new file mode 100644
index 0000000000..cff3bca56c
--- /dev/null
+++ b/doc/git-annex-addurl/comment_1_ce9c660be160a22c28aeb6de8b3b5818._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joseph.rawson.works@85a210ab8c0e37a0b2d6bb235738b20e23e8878f"
+ nickname="joseph.rawson.works"
+ avatar="http://cdn.libravatar.org/avatar/6b473d5484b68803e8c47eeff9197397"
+ subject="Using youtube-dl commandline options with git-annex-addurl"
+ date="2018-05-30T15:29:16Z"
+ content="""
+I have been trying to figure out how to use addurl to get this video.
+I have this in my mscourtstuff annex as a large binary, but I would really like to 
+use the web as a remote for this.
+
+Hughes v Hosemann 2010-CA-01949-SCT-43112001.mp4
+youtube-dl --referer 'http://judicial.mc.edu/case.php?id=24206'  http://player.vimeo.com/video/43112001
+
+
+"""]]
diff --git a/doc/git-annex-addurl/comment_2_9bc984fb80d77309b62a4e915e65a31a._comment b/doc/git-annex-addurl/comment_2_9bc984fb80d77309b62a4e915e65a31a._comment
new file mode 100644
index 0000000000..a12fc56ca1
--- /dev/null
+++ b/doc/git-annex-addurl/comment_2_9bc984fb80d77309b62a4e915e65a31a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-05-30T16:30:26Z"
+ content="""
+There's not currently a way to do per-file youtube-dl options.
+The difficulty is that we don't know what youtube-dl options might be
+unsafe, and which such a feature could make eg `git annex get` use when run
+by a different user.
+
+I feel that this needs some support in youtube-dl to avoid git-annex
+needing to know about all its safe options. Especially since which options
+are available, or safe, could vary between versions of youtube-dl.
+"""]]
diff --git a/doc/git-annex-addurl/comment_3_46e1b62d37619521a60eb2339b8d094f._comment b/doc/git-annex-addurl/comment_3_46e1b62d37619521a60eb2339b8d094f._comment
new file mode 100644
index 0000000000..a5e3827b24
--- /dev/null
+++ b/doc/git-annex-addurl/comment_3_46e1b62d37619521a60eb2339b8d094f._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="pellman.john@e59e5c6d98d49cd9632d6fbe0c5026ddc71d52fd"
+ nickname="pellman.john"
+ avatar="http://cdn.libravatar.org/avatar/eaca2e5f6d5888d139129293c7293b1f"
+ subject="Inconsistent idiom"
+ date="2019-02-06T20:53:00Z"
+ content="""
+In using git-annex in the past, I've always found it counterintuitive that [rmurl](https://git-annex.branchable.com/git-annex-rmurl/) uses the following form to remove a URL from a file:
+
+```
+git annex rmurl [file] [url]
+```
+
+While, in contrast, addurl uses a flag to designate the file that a URL should be added to the list of URLs a file points to:
+
+```
+git annex addurl [url] --file=[file]
+```
+
+It would make sense (at least to me) to make the syntax for these more congruous so that both commands use either two positional arguments or one positional argument and one keyword argument / flag.
+"""]]
diff --git a/doc/git-annex-addurl/comment_4_0951800d761d18614eb6c5f08cdbb885._comment b/doc/git-annex-addurl/comment_4_0951800d761d18614eb6c5f08cdbb885._comment
new file mode 100644
index 0000000000..1290464308
--- /dev/null
+++ b/doc/git-annex-addurl/comment_4_0951800d761d18614eb6c5f08cdbb885._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-02-07T19:26:12Z"
+ content="""
+@john, the difference is that while addurl can make up a filename to use if
+you do not provide one, rmurl needs you to specifiy a filename.
+
+So, yes, "git annex rmurl --file=whatever url" would be more consistent,
+but it requires typing more my making something that is not actually
+optional into an option. And "git annex addurl file url" would make
+the command more consistent with rmurl, but harder to use.
+
+Consistency is not everything.
+
+(Also, the rmurl batch interface would then be less consistent to its
+command-line interface.)
+"""]]
diff --git a/doc/git-annex-addurl/comment_5_47dfa82fc6426fb9ad050dd00290dc03._comment b/doc/git-annex-addurl/comment_5_47dfa82fc6426fb9ad050dd00290dc03._comment
new file mode 100644
index 0000000000..db9c1150a4
--- /dev/null
+++ b/doc/git-annex-addurl/comment_5_47dfa82fc6426fb9ad050dd00290dc03._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="gan"
+ avatar="http://cdn.libravatar.org/avatar/564f55f9fc3773e521bafdbb6f23efc9"
+ subject="Provide flags to youtube-dl?"
+ date="2019-02-22T18:01:25Z"
+ content="""
+Is there already a way to specify flags to youtube-dl on a per-file basis.  I think it would be OK to do it during either during addurl (modifying the resulting reference that is stored in the annex somehow), or during git-annex get.  This is so that the preferred format can be specified.  Primarily this would enable to download audio-only formats for some files.  ) Apologies if I missed some documentation on how to achieve this)
+
+"""]]
diff --git a/doc/git-annex-addurl/comment_7_8d8ac07a0f0fe599ea5ed1e4089b13fa._comment b/doc/git-annex-addurl/comment_7_8d8ac07a0f0fe599ea5ed1e4089b13fa._comment
new file mode 100644
index 0000000000..cbc29bf551
--- /dev/null
+++ b/doc/git-annex-addurl/comment_7_8d8ac07a0f0fe599ea5ed1e4089b13fa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="gan"
+ avatar="http://cdn.libravatar.org/avatar/564f55f9fc3773e521bafdbb6f23efc9"
+ subject="Clarification"
+ date="2019-02-22T18:03:16Z"
+ content="""
+So, to clarify - I read your first answer.  But if this coulud be done during get perhaps then it's OK because it is an explicit request for the potentially unsafe operation?
+"""]]
diff --git a/doc/git-annex-addurl/comment_8_88aea3014245634d42f23a22ccf2fcc9._comment b/doc/git-annex-addurl/comment_8_88aea3014245634d42f23a22ccf2fcc9._comment
new file mode 100644
index 0000000000..d8c832b25e
--- /dev/null
+++ b/doc/git-annex-addurl/comment_8_88aea3014245634d42f23a22ccf2fcc9._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="pellman.john@e59e5c6d98d49cd9632d6fbe0c5026ddc71d52fd"
+ nickname="pellman.john"
+ avatar="http://cdn.libravatar.org/avatar/eaca2e5f6d5888d139129293c7293b1f"
+ subject="Re: Inconsistent idiom"
+ date="2019-03-28T03:59:04Z"
+ content="""
+Hi @joey,
+
+Thanks for your continued work on git-annex and for responding to my last comment.  I agree that consistency is not everything, but I do think that it's also important to balance functionality against the amount of cognitive load that an interface places on an end-user.  My perspective is no doubt influenced by my cognitive science background, but whenever I find an interface where it's easy to confuse two similar operations that use different syntaxes, I'm reminded of Don Norman's [rant about the early Unix UI](https://www.researchgate.net/publication/202165676_The_trouble_with_UNIX_The_user_interface_is_horrid).  I'm also reminded of common phenomena described in memory research such as [retroactive interference](https://en.wikipedia.org/wiki/Interference_theory#Proactive_interference), wherein a more recently learned memory interferes with something that was learned previously.  In this case, if I were to learn the syntax for addurl first, and then learned the syntax for rmurl much later, my internal representation of rmurl would to some degree \"overwrite\" my previous knowledge of addurl and compete with it.  Making the two syntaxes consistent with each other in this case would eliminate any competition between internal mental representations of how the two commands are structured.
+
+I'm also not entirely sure why a positional argument can't be optional.  If there's a good reason for this not to be so then I won't argue my point anymore, but something like the following syntax would make the most sense from my view:
+
+``git annex rmurl [url] [file]``
+
+``git annex addurl [url] [file; optional positional argument]``
+"""]]
diff --git a/doc/git-annex-addurl/comment_8_b261e7bfeeffb2c5264aaadae1d78817._comment b/doc/git-annex-addurl/comment_8_b261e7bfeeffb2c5264aaadae1d78817._comment
new file mode 100644
index 0000000000..fce6e1d997
--- /dev/null
+++ b/doc/git-annex-addurl/comment_8_b261e7bfeeffb2c5264aaadae1d78817._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: provide flags to youtube-dl"""
+ date="2019-02-22T20:01:37Z"
+ content="""
+@gan, there's not much point in providing flags that are only used in the
+initial download; the main point in adding the url to git-annex is so you
+can download the same content from it again later.
+"""]]
diff --git a/doc/git-annex-addurl/comment_9_48741c1c625dc1ecba2db4f7be2f644c._comment b/doc/git-annex-addurl/comment_9_48741c1c625dc1ecba2db4f7be2f644c._comment
new file mode 100644
index 0000000000..85f6dcefff
--- /dev/null
+++ b/doc/git-annex-addurl/comment_9_48741c1c625dc1ecba2db4f7be2f644c._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="m15"
+ avatar="http://cdn.libravatar.org/avatar/a8c5fb405daff5f9c0c15209a3df4a4d"
+ subject="bug report"
+ date="2021-01-23T08:52:14Z"
+ content="""
+```
+ENV:
+macOS 10.14.6, installed by 'brew install git-annex'
+git annex version
+git-annex version: 8.20201129
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.27 DAV-1.3.4 feed-1.3.0.1 ghc-8.10.3 http-client-0.7.3 persistent-sqlite-2.11.0.0 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+
+
+STEPS:
+File copied to git (git-annex) repo's dir  (did not 'git add' 'git annex add')
+name: 'f.mp4'
+Now run 'git annex addurl' (via Python, see below)
+
+RESULT: (same if run in bash)
+File \"/opt/anaconda3/lib/python3.7/subprocess.py\", line 512, in run
+    output=stdout, stderr=stderr)
+subprocess.CalledProcessError: Command '['git', 'annex', 'addurl', '--file=f.mp4', '--raw', '--relaxed', 'https://www.youtube.com/watch?v=U33dsEcKgeQ']' returned non-zero exit status 1.
+
+The command works after doing 'git annex add f.mp4' first
+  but it results in a backend not 'URL backend for youtube'
+  I'd like to use 'URL backend for youtube' cause I worry about youtube-video binay-change, in which case all future download will fail backend verification.
+
+
+NOTE:
+command line taken from https://git-annex.branchable.com/tips/using_the_web_as_a_special_remote/
+
+```
+
+"""]]
diff --git a/doc/git-annex-adjust.mdwn b/doc/git-annex-adjust.mdwn
new file mode 100644
index 0000000000..fd573ec904
--- /dev/null
+++ b/doc/git-annex-adjust.mdwn
@@ -0,0 +1,137 @@
+# NAME
+
+git-annex adjust - enter an adjusted branch
+
+# SYNOPSIS
+
+git annex adjust `--unlock|--lock|--fix|--hide-missing [--unlock|--lock|--fix]|--unlock-present`
+
+# DESCRIPTION
+
+Enters an adjusted form of the current branch. The annexed files will
+be treated differently. For example with --unlock all annexed files will
+be unlocked.
+
+The adjusted branch will have a name like "adjusted/master(unlocked)".
+Since it's a regular git branch, you can use `git checkout` to switch
+back to the original branch at any time.
+
+This allows changing how annexed files are handled, without making changes
+to a public branch with commands like `git-annex unlock`.
+
+While in the adjusted branch, you can use git-annex and git commands as
+usual. Any commits that you make will initially only be made to the
+adjusted branch. 
+
+To propagate commits from the adjusted branch back to the original branch,
+and to other repositories, as well as to merge in changes from other
+repositories, run `git annex sync`. This will propagate changes that you've
+made such as adding/deleting files, but will not propagate the adjustments
+made by this command.
+
+When in an adjusted branch, using `git merge otherbranch` is often not
+ideal, because merging a non-adjusted branch may lead to unnecessary
+merge conflicts, or add files in non-adjusted form. To avoid those
+problems, use `git annex merge otherbranch`.
+
+Re-running this command with the same options
+while inside the adjusted branch will update the adjusted branch
+as necessary (eg for `--hide-missing` and `--unlock-present`), 
+and will also propagate commits back to the original branch.
+
+# OPTIONS
+
+* `--unlock`
+
+  Unlock all annexed files in the adjusted branch. This allows
+  annexed files to be modified.
+
+  Normally, unlocking a file requires a copy to be made of its content,
+  so that its original content is preserved, while the copy can be modified.
+  To use less space, annex.thin can be set to true before running this
+  command; this makes a hard link to the content be made instead of a copy.
+  (When supported by the file system.) While this can save considerable
+  disk space, any modification made to a file will cause the old version of the
+  file to be lost from the local repository. So, enable annex.thin with care.
+
+  When in an adjusted unlocked branch, `git annex add` will add files
+  unlocked instead of the default behavior of adding them locked.
+
+* `--lock`
+
+  Lock all annexed files in the adjusted branch. This may be preferred
+  by those who like seeing broken symlinks when the content of an
+  annexed file is not present.
+
+  When in an adjusted locked branch, `git annex add` will add files locked,
+  as usual. However, `git add` (and `git commit -a` etc) still add files
+  unlocked. This is because it's not possible for those git commands to
+  add files locked.
+
+* `--fix`
+
+  Fix the symlinks to annexed files to point to the local git annex
+  object directory. This can be useful if a repository is checked out in an
+  unusual way that prevents the symlinks committed to git from pointing at
+  the annex objects.
+
+* `--hide-missing`
+
+  Only include annexed files in the adjusted branch when their content
+  is present.
+
+  The adjusted branch is not immediately changed when content availability
+  changes, so if you `git annex drop` files, they will become broken
+  links in the usual way. And when files that were missing are copied into the
+  repository from elsewhere, they won't immediatly become visible in the
+  branch.
+  
+  To update the adjusted branch to reflect changes to content availability, 
+  run `git annex adjust --hide-missing` again. Or, to automate updates,
+  set the `annex.adjustedbranchrefresh` config.
+
+  Despite missing files being hidden, `git annex sync --content` will
+  still operate on them, and can be used to download missing
+  files from remotes. It also updates the adjusted branch after
+  transferring content.
+
+  This option can be combined with --unlock, --lock, or --fix.
+
+* `--unlock-present`
+
+  Unlock files whose content is present, and lock files whose content is
+  missing. This provides the benefits of working with unlocked files,
+  but makes it easier to see when the content of a file is not missing,
+  since it will be a broken symlink.
+  
+  The adjusted branch is not immediately changed when content availability
+  changes, so when you `git annex get` files, they will remain locked.
+  And when you `git annex drop` files, they will remain locked and so will
+  not be broken symlinks.
+  
+  To update the adjusted branch to reflect changes to content availability, 
+  run `git annex adjust --unlock-present` again. Or, to automate updates,
+  set the `annex.adjustedbranchrefresh` config. Or use `git-annex sync
+  --content`, which updates the branch after transferring content.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-unlock]](1)
+
+[[git-annex-lock]](1)
+
+[[git-annex-upgrade]](1)
+
+[[git-annex-sync]](1)
+
+[[git-annex-view]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-adjust/comment_1_364d1d5546c0f448a4b27cfe69a59a07._comment b/doc/git-annex-adjust/comment_1_364d1d5546c0f448a4b27cfe69a59a07._comment
new file mode 100644
index 0000000000..1e2d7a602c
--- /dev/null
+++ b/doc/git-annex-adjust/comment_1_364d1d5546c0f448a4b27cfe69a59a07._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="ynikitenko"
+ avatar="http://cdn.libravatar.org/avatar/168d629704097ddc596f75ca32a687a3"
+ subject="difference with git-annex-fix?"
+ date="2017-11-02T19:57:48Z"
+ content="""
+From git-annex-fix manual:
+
+       Fixes up symlinks that have become broken to again point to annexed content.
+       This is useful to run manually when you have been moving the symlinks around, but is done automatically when committing a change with git too.
+       Also, adjusts unlocked files to be copies or hard links as configured by annex.thin.
+
+So what is the difference between that and git-annex adjust --fix?
+"""]]
diff --git a/doc/git-annex-adjust/comment_2_383af8e1e26e4119671437aace0a58f5._comment b/doc/git-annex-adjust/comment_2_383af8e1e26e4119671437aace0a58f5._comment
new file mode 100644
index 0000000000..a0a2700954
--- /dev/null
+++ b/doc/git-annex-adjust/comment_2_383af8e1e26e4119671437aace0a58f5._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-11-07T20:18:19Z"
+ content="""
+`git annex fix` fixes up the symlinks before they're committed.
+It's run by the pre-commit hook, so even when annexed files are
+manually moved around, the symlinks that get committed are always
+right.
+
+So then, if the symlinks committed are always right,
+how would `git annex adjust --fix` be useful? Well,
+there are ways to check out git repositories that make
+the .git directory not be in the usual place. For example,
+when using submodules, git puts that directory in a different place.
+And then the committed symlinks won't point to .git. So,
+`git annex adjust --fix` is useful as a way to adjust the symlinks
+locally, without committing any changes to them, in that kind of
+situation.
+"""]]
diff --git a/doc/git-annex-adjust/comment_3_c5af3a73af8925839413467a7d1e0e14._comment b/doc/git-annex-adjust/comment_3_c5af3a73af8925839413467a7d1e0e14._comment
new file mode 100644
index 0000000000..9e0cfbb342
--- /dev/null
+++ b/doc/git-annex-adjust/comment_3_c5af3a73af8925839413467a7d1e0e14._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="Thank you"
+ date="2020-01-23T19:52:47Z"
+ content="""
+This is is a great feature, especially `--hide-missing`! I really missed this in the past. (Strangely it took me until now to notice that you implemented it.) Thank you.
+"""]]
diff --git a/doc/git-annex-adjust/comment_4_597c5e0254012e3a4ecafa49cfa23cb6._comment b/doc/git-annex-adjust/comment_4_597c5e0254012e3a4ecafa49cfa23cb6._comment
new file mode 100644
index 0000000000..34e1623b97
--- /dev/null
+++ b/doc/git-annex-adjust/comment_4_597c5e0254012e3a4ecafa49cfa23cb6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="Get missing files in --hide-missing branch"
+ date="2020-06-05T19:14:26Z"
+ content="""
+When in an hide-missing adjusted branch, is there any way to \"git annex get\" a missing file without switching branches first. Respectively, is there any way to find/list missing files without switching branches?
+"""]]
diff --git a/doc/git-annex-adjust/comment_6_f00c27078cce5ad75fcf0cec1033751b._comment b/doc/git-annex-adjust/comment_6_f00c27078cce5ad75fcf0cec1033751b._comment
new file mode 100644
index 0000000000..dcb26546ae
--- /dev/null
+++ b/doc/git-annex-adjust/comment_6_f00c27078cce5ad75fcf0cec1033751b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-01-07T16:03:13Z"
+ content="""
+@lell this is a man page, it's really not a place to file bug reports
+or discuss in detail complicated scenarios. 
+
+Please use [[bugs]] and [[forum]] for such things.
+
+Comments are open on this page
+in case someone has a suggestion to improve this documentation, not for
+general discussion about the feature.
+"""]]
diff --git a/doc/git-annex-adjust/comment_7_a9c88b1d83d5e874f8f8063fcdd9e624._comment b/doc/git-annex-adjust/comment_7_a9c88b1d83d5e874f8f8063fcdd9e624._comment
new file mode 100644
index 0000000000..d2896f45fd
--- /dev/null
+++ b/doc/git-annex-adjust/comment_7_a9c88b1d83d5e874f8f8063fcdd9e624._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="lell"
+ avatar="http://cdn.libravatar.org/avatar/4c4138a71d069e290240a3a12367fabe"
+ subject="comment 7"
+ date="2022-01-10T08:33:46Z"
+ content="""
+Thanks for the help on where to put the question, joey. I have deleted and [moved](https://git-annex.branchable.com/forum/Propagate_changes_and_remove_adjusted_branch/?updated) my previous post. 
+"""]]
diff --git a/doc/git-annex-assist.mdwn b/doc/git-annex-assist.mdwn
new file mode 100644
index 0000000000..bc843be1a9
--- /dev/null
+++ b/doc/git-annex-assist.mdwn
@@ -0,0 +1,69 @@
+# NAME
+
+git-annex assist - add files and sync changes with remotes
+
+# SYNOPSIS
+
+git annex assist `[remote ...]`
+
+# DESCRIPTION
+
+This command assists you in checking files into the repository
+and syncing with remotes. It's the simplest possible way to use git-annex
+at the command line, since only this one command needs to be run on a
+regular basis.
+
+This command first adds any new files to the repository, and commits those
+as well as any modified files. Then it does the equivilant of running
+[[git-annex-pull](1) followed by [[git-annex-push]](1).
+
+This command operates on all files in the whole working tree,
+even when ran in a subdirectory. To limit it to operating on files in a
+subdirectory, use the `--content-of` option.
+
+To block some files from being added to the repository, use `.gitignore`
+files.
+
+By default, all files that are added are added to the annex, the same
+as when you run `git annex add`. If you configure annex.largefiles,
+files that it does not match will instead be added with `git add`.
+
+# OPTIONS
+
+* `--message=msg` `-m msg`
+
+  Use this option to specify a commit message.
+
+  If multiple -m options are given, their values are concatenated
+  as separate paragraphs.
+
+* `--content-of=path` `-C path`
+
+  Only add, pull, and push files in the given path.
+
+  This option can be repeated multiple times with different paths.
+
+* Also all options supported by [[git-annex-pull]](1) and
+  [[git-annex-push]](1) can be used.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-add]](1)
+
+[[git-annex-pull]](1)
+
+[[git-annex-push]](1)
+
+[[git-annex-sync]](1)
+
+[[git-annex-assistant]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-assistant.mdwn b/doc/git-annex-assistant.mdwn
new file mode 100644
index 0000000000..076c26f37f
--- /dev/null
+++ b/doc/git-annex-assistant.mdwn
@@ -0,0 +1,72 @@
+# NAME
+
+git-annex assistant - daemon to add files and automatically sync changes
+
+# SYNOPSIS
+
+git annex assistant
+
+# DESCRIPTION
+
+Watches for changes to files in the current directory and its subdirectories,
+and automatically syncs them to other remotes. This includes adding new
+files. New files published to remotes by others are also automatically
+downloaded.
+
+By default, all new files in the directory will be added to the repository.
+(Including dotfiles.) To block some files from being added, use
+`.gitignore` files.
+  
+By default, all files that are added are added to the annex, the same
+as when you run `git annex add`. If you configure annex.largefiles,
+files that it does not match will instead be added with `git add`.
+
+# OPTIONS
+
+* `--autostart`
+
+  Automatically starts the assistant running in each repository listed
+  in the file `~/.config/git-annex/autostart`
+
+  This is typically started at boot, or when you log in.
+
+* `--startdelay=N`
+
+  Wait N seconds before running the startup scan. This process can
+  be expensive and you may not want to run it immediately upon login.
+
+  When --autostart is used, defaults to --startdelay=5.
+
+* `--foreground`
+
+  Avoid forking to the background.
+
+* `--stop`
+
+  Stop a running daemon in the current repository.
+
+* `--autostop`
+
+  The complement to --autostart; stops all running daemons in the
+  repositories listed in the autostart file.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-watch]](1)
+
+[[git-annex-assist]](1)
+
+[[git-annex-schedule]](1)
+
+For more details about the git-annex assistant, see
+<https://git-annex.branchable.com/assistant/>
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-backends.mdwn b/doc/git-annex-backends.mdwn
new file mode 100644
index 0000000000..86205eaebc
--- /dev/null
+++ b/doc/git-annex-backends.mdwn
@@ -0,0 +1,24 @@
+# NAME
+
+git-annex-backends - key/value backends for git-annex
+
+# DESCRIPTION
+
+The "backend" in git-annex controls how a key is generated from a file's
+content and/or filesystem metadata. Most backends are different kinds of
+hashes. A single repository can use different backends for different files.
+
+For a list of available backends, see `git-annex version`. For more
+details, see <https://git-annex.branchable.com/backends/>
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+<http://git-annex.branchable.com/>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-benchmark.mdwn b/doc/git-annex-benchmark.mdwn
new file mode 100644
index 0000000000..3e729c00ea
--- /dev/null
+++ b/doc/git-annex-benchmark.mdwn
@@ -0,0 +1,65 @@
+# NAME
+
+git-annex benchmark - benchmark git-annex commands
+
+# SYNOPSIS
+
+git annex benchmark [criterionopts] ( -- commmand [; command] | --databases=N )
+
+# DESCRIPTION
+
+When git-annex is built with benchmarking support, this command can be used
+to benchmark any other git-annex command. For example
+"git annex benchmark -- get ."
+will benchmark "git annex get".
+
+The command being benchmarked is run in the current git-annex repository.
+It does not run just once; the benchmarking process will run it several
+times to get a statistically meaningful result.
+
+When benchmarking an action like "git annex get", the first run will
+often do much more than subseqent runs. To make the benchmark repeat an
+action like getting a file each time, additional commands can be listed,
+separated by ';'. (Note that ';' needs to be escaped from the shell.)
+The combined script will be run repeatedly by the benchmark. An example
+of using this:
+
+	git annex benchmark -- get . ';' drop .
+
+Note that git-annex benchmark does not fork new git-annex processes when
+benchmarking; it calls the command to benchmark internally, and so avoids
+git-annex's startup overhead. (So don't try to use it to optimise git-annex
+startup.) 
+
+# OPTIONS
+
+Before the "--" any of the criterion library's command-line options can be
+used.
+
+Any options that git-annex usually accepts can be included after the
+command to benchmark.
+
+The --databases=N option benchmark's git-annex's use of sqlite databases,
+instead of a command. N is the number of items to benchmark.
+
+# OUTPUT
+
+The output of the commands being benchmarked goes to standard output and
+standard error as usual. It's often a good idea to use --quiet to avoid
+unnecessary output, unless the generation of that output is part of what
+you want to benchmark.
+
+The benchmark report is output to standard output by default, although
+criterion options can be used to redirect it to a file. For example:
+
+	git annex benchmark -o bench -- find >/dev/null
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-benchmark/comment_1_fe0e8d2e2e875521e715ee2e68818570._comment b/doc/git-annex-benchmark/comment_1_fe0e8d2e2e875521e715ee2e68818570._comment
new file mode 100644
index 0000000000..57c707c33f
--- /dev/null
+++ b/doc/git-annex-benchmark/comment_1_fe0e8d2e2e875521e715ee2e68818570._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2022-12-14T19:39:38Z"
+ content="""
+I see there is a `--list` command to list benchmarks but it just \"errored out\" with 
+
+```
+❯ git annex benchmark --list
+Missing: COMMAND
+
+Usage: git-annex COMMAND
+  git-annex - benchmarking
+... here comes long list of all commands ...
+```
+
+of which that short `Usage:` help seems to be wrong (I did give the command) but I wonder what would be the invocation of `annex benchmark` if I were to run a collection of benchmarks to compare different filesystems, like I did in the past in [https://www.datalad.org/test_fs_analysis.html](https://www.datalad.org/test_fs_analysis.html)?
+
+FWIW git-annex version 10.20220724 (same with 10.20221003)
+"""]]
diff --git a/doc/git-annex-benchmark/comment_2_3d8dcde00f8df7961490ef81f5400824._comment b/doc/git-annex-benchmark/comment_2_3d8dcde00f8df7961490ef81f5400824._comment
new file mode 100644
index 0000000000..ae2cccf2e3
--- /dev/null
+++ b/doc/git-annex-benchmark/comment_2_3d8dcde00f8df7961490ef81f5400824._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-12-20T18:20:01Z"
+ content="""
+That --list turns out to come from the criterion library, and you can
+actually use it but only if you provide the mandatory "-- command"
+parameters too. For example:
+
+	git-annex benchmark --list -- version
+	version
+
+That's not useful at all, since all if can list is the same benchmark you
+provide on input. But this is a consequence of supporting other criterion
+options like --iters and --csv that can be useful.
+
+`git-annex benchmark` does not use a canned set of benchmarks; it
+benchmarks a git-annex subcommand or subcommands that you specify.
+"""]]
diff --git a/doc/git-annex-calckey.mdwn b/doc/git-annex-calckey.mdwn
new file mode 100644
index 0000000000..92ab65443e
--- /dev/null
+++ b/doc/git-annex-calckey.mdwn
@@ -0,0 +1,47 @@
+# NAME
+
+git-annex calckey - calculate key for a file
+
+# SYNOPSIS
+
+git annex calckey `[file ...]`
+
+# DESCRIPTION
+
+This plumbing-level command calculates the key that would be used
+to refer to a file. The file is not added to the annex by this command.
+The key is output to stdout.
+
+The backend used is the one from the annex.backend configuration
+setting, which can be overridden by the --backend option.
+For example, to force use of the SHA1 backend:
+
+	git annex calckey --backend=SHA1 file
+
+# OPTIONS
+
+* `--backend=name`
+
+  Specifies which key-value backend to use.
+
+* `--batch`
+
+  Enable batch mode, in which a line containing the filename is read from
+  stdin, the key is output to stdout (with a trailing newline), and repeat.
+
+* `-z`
+
+  Makes the `--batch` input be delimited by nulls instead of the usual
+  newlines.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-checkpresentkey.mdwn b/doc/git-annex-checkpresentkey.mdwn
new file mode 100644
index 0000000000..5d4d4b971c
--- /dev/null
+++ b/doc/git-annex-checkpresentkey.mdwn
@@ -0,0 +1,40 @@
+# NAME
+
+git-annex checkpresentkey - check if key is present in remote
+
+# SYNOPSIS
+
+git annex checkpresentkey `key` `[remote]`
+
+# DESCRIPTION
+
+This plumbing-level command verifies if the specified key's content
+is present in the specified remote.
+
+When no remote is specified, it verifies if the key's content is present
+in any accessible remotes.
+
+Exits 0 if the content is verified present in the remote, or 1 if it is
+verified to not be present in the remote. If there is a problem, 
+the special exit code 100 is used, and an error message is output to stderr.
+
+# OPTIONS
+
+* `--batch`
+
+  Enables batch mode. In this mode, the `key` is not specified at the
+  command line, but the `remote` may still be. Lines containing keys are
+  read from stdin, and a line is output with "1" if the key is verified to
+  be present, and "0" otherwise.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-checkpresentkey/comment_1_756f276929a0b0ff73baea141d3ef07d._comment b/doc/git-annex-checkpresentkey/comment_1_756f276929a0b0ff73baea141d3ef07d._comment
new file mode 100644
index 0000000000..3dc75ab300
--- /dev/null
+++ b/doc/git-annex-checkpresentkey/comment_1_756f276929a0b0ff73baea141d3ef07d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-09-19T17:40:16Z"
+ content="""
+If a key has a URL by which it can be downloaded from an external special remote, and the remote supports checkurl but not checkpresent, checkpresentkey says the key isn't in the remote; but git annex whereis --key says there is.  Maybe it's as intended, checkpresentkey being a plumbing command, but just wanted to note.
+"""]]
diff --git a/doc/git-annex-checkpresentkey/comment_2_e277962791b64e67b08ccff47dd22447._comment b/doc/git-annex-checkpresentkey/comment_2_e277962791b64e67b08ccff47dd22447._comment
new file mode 100644
index 0000000000..38bb1d9e5e
--- /dev/null
+++ b/doc/git-annex-checkpresentkey/comment_2_e277962791b64e67b08ccff47dd22447._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-09-24T15:28:59Z"
+ content="""
+It makes sense that checkpresentkey could report different information than
+whereis, because whereis only reports on logged location information,
+while checkpresentkey actively checks the remote.
+
+I'm not entirely clear on how an external special remote could not support
+checkpresent, I suppose you might mean it always fails or is just not
+implemented (so basically fails). That would be a problem with the remote's
+implementation. If it's something else, open a bug report.
+"""]]
diff --git a/doc/git-annex-common-options.mdwn b/doc/git-annex-common-options.mdwn
new file mode 100644
index 0000000000..44412a982c
--- /dev/null
+++ b/doc/git-annex-common-options.mdwn
@@ -0,0 +1,155 @@
+# NAME
+
+git-annex-common-options - options supported by many git-annex commands
+
+# DESCRIPTION
+
+These common options are accepted by many git-annex commands, and
+may not be explicitly listed on their individual man pages.
+Most of these options are accepted by all git-annex commands.
+(Many commands also accept the [[git-annex-matching-options]](1).)
+
+# OPTIONS
+
+* `--force`
+
+  Force unsafe actions, such as dropping a file's content when no other
+  source of it can be verified to still exist, or adding ignored files.
+  Use with care.
+
+* `--fast`
+
+  Avoid some expensive operations normally performed by a command.
+  What is avoided depends on the command, see individual command's man
+  pages for details.
+
+* `--quiet`
+
+  Avoid the default verbose display of what is done; only show errors.
+
+* `--verbose`
+
+  Enable verbose display. On by default but can be disabled by --quiet.
+
+* `--explain`
+
+  Display explanations of what git-annex takes into account when deciding
+  what to do. The explanations will be inside square brackets.
+  For example, "[foo is not present here]"
+
+  This includes explanations of why preferred content expressions and
+  other similar expressions like annex.largefiles match or fail to match.
+  In these explanations, the expression is displayed, with each term
+  followed by "[TRUE]" or "[FALSE]" to indicate the value.
+  Irrelevant terms will be ommitted from the explanation, for example 
+  `"exclude=* and copies=1"` will be displayed as `"exclude=*[FALSE]"`
+
+* `--debug`
+
+  Display debug messages to standard error.
+
+* `--no-debug`
+
+  Disable display of debug messages.
+
+* `--debugfilter=name[,name..]`
+
+  When debug message display has been enabled by `--debug`, this filters
+  the debug messages that are displayed to ones coming from modules with
+  the specified names.
+  
+  To find the names of modules, see the full debug output, which includes
+  the module name, eg "(Utility.Process)"
+
+  The full module name does not need to be
+  specified when using this, a substring of the name will do.
+
+  For example, `--debugfilter=Process,External` will display debugging
+  output when git-annex runs processes, and when it communicates with
+  external special remotes.
+
+* `--numcopies=n`
+
+  Overrides the numcopies setting.
+
+* `--mincopies=n`
+
+  Overrides the mincopies setting.
+
+* `--time-limit=time`
+
+  Limits how long a git-annex command runs. The time can be something
+  like "5h", or "30m" or even "45s" or "10d".
+
+  Note that git-annex may continue running for some time past the specified
+  time limit, in order to finish processing files it started before the
+  time limit was reached. That and a cleaner shutdown are the differences
+  between using this option and a command like `timeout(1)`.
+
+  When the time limit prevents git-annex from doing all it
+  was asked to, it will exit with a special code, 101.
+
+* `--size-limit=size`
+
+  Limits the total size of annexed files that a git-annex command
+  can process.
+
+  The size can be specified with any commonly used units, for example,
+  "50gb".
+
+  In some cases, an annexed file's size is not known. This option will
+  prevent git-annex from processing such files.
+
+  When the size limit prevents git-annex from acting on any files,
+  it will exit with a special code, 101.
+
+* `--semitrust=repository`
+* `--untrust=repository`
+
+  Overrides trust settings for a repository. May be specified more than once.
+
+  The repository should be specified using the name of a configured remote,
+  or the UUID or description of a repository.
+
+* `--trust=repository`
+
+  This used to override trust settings for a repository, but now will
+  not do so, because trusting a repository can lead to data loss,
+  and data loss is now only enabled when using the `--force` option.
+
+* `--trust-glacier`
+
+  This used to override trust settings for Glacier special remotes,
+  but now will not do so, because it could lead to data loss,
+  and data loss is now only enabled when using the `--force` option.
+
+* `--user-agent=value`
+
+  Overrides the User-Agent to use when downloading files from the web.
+
+* `--notify-finish`
+
+  Caused a desktop notification to be displayed after each successful
+  file download and upload.
+
+  (Only supported on some platforms, e.g. Linux with dbus. A no-op when
+  not supported.)
+
+* `--notify-start`
+
+  Caused a desktop notification to be displayed when a file upload
+  or download has started, or when a file is dropped.
+
+* `-c name=value`
+
+  Overrides git configuration settings. May be specified multiple times.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-config.mdwn b/doc/git-annex-config.mdwn
new file mode 100644
index 0000000000..f52f4a2a4a
--- /dev/null
+++ b/doc/git-annex-config.mdwn
@@ -0,0 +1,238 @@
+# NAME
+
+git-annex config - configuration stored in git-annex branch
+
+# SYNOPSIS
+
+git annex config --set name value
+
+git annex config --get name
+
+git annex config --unset name
+
+git annex config --show-origin name
+
+# DESCRIPTION
+
+Set or get configuration settings stored in the git-annex branch.
+
+Unlike `git config` settings, these settings can be seen
+in all clones of the repository, once they have gotten their
+git-annex branches in sync.
+
+These settings can be overridden on a per-repository basis using
+`git config`.
+
+git-annex does not check the git-annex branch for all the `git config`
+settings that affect it (which are listed on the git-annex man page
+CONFIGURATION section). Only a few make sense to be able to set such
+that all clones of a repository see the setting, and so git-annex only
+looks for these.
+
+# SUPPORTED SETTINGS
+
+* `annex.numcopies`
+
+  Tells git-annex how many copies it should preserve of files, over all
+  repositories. The default is 1.
+
+  When git-annex is asked to drop a file, it first verifies that the
+  number of copies can be satisfied among all the other
+  repositories that have a copy of the file.
+  
+  In unusual situations, involving special remotes that do not support
+  locking, and concurrent drops of the same content from multiple
+  repositories, git-annex may violate the numcopies setting. It still
+  guarantees at least 1 copy is preserved. This can be configured by
+  setting annex.mincopies.
+
+  This is the same setting that the [[git-annex-numcopies]](1) command
+  configures. It can be overridden on a per-file basis
+  by the annex.numcopies setting in `.gitattributes` files.
+
+* `annex.mincopies`
+
+  Tells git-annex how many copies it is required to preserve of files, 
+  over all repositories. The default is 1.
+
+  This supplements the annex.numcopies setting. 
+  In unusual situations, involving special remotes that do not support
+  locking, and concurrent drops of the same content from multiple
+  repositories, git-annex may violate the numcopies setting.
+  In these unusual situations, git-annex ensures that the number of copies
+  never goes below mincopies.
+  
+  It is a good idea to not only rely on only setting mincopies. Set
+  numcopies as well, to a larger number, and keep mincopies at the
+  bare minimum you're comfortable with. Setting mincopies to a large
+  number, rather than setting numcopies will in some cases prevent
+  droping content in entirely safe situations.
+
+  This is the same setting that the [[git-annex-mincopies]](1) command
+  configures. It can be overridden on a per-file basis
+  by the annex.mincopies setting in `.gitattributes` files.
+
+* `annex.largefiles`
+
+  Used to configure which files are large enough to be added to the annex.
+  It is an expression that matches the large files, eg
+  "`include=*.mp3 or largerthan(500kb)`".
+  See [[git-annex-matching-expression]](1) for details on the syntax.
+  
+  This configures the behavior of both git-annex and git when adding
+  files to the repository. By default, `git-annex add` adds all files
+  to the annex (except dotfiles), and `git add` adds files to git
+  (unless they were added to the annex previously).
+  When annex.largefiles is configured, both
+  `git annex add` and `git add` will add matching large files to the
+  annex, and the other files to git.
+
+  Other git-annex commands also honor annex.largefiles, including
+  `git annex import`, `git annex addurl`, `git annex importfeed`,
+  `git-annex assist`, and the `git-annex assistant`.
+
+  This sets a default, which can be overridden by annex.largefiles
+  attributes in `.gitattributes` files, or by `git config`.
+
+* `annex.dotfiles`
+
+  Normally, dotfiles are assumed to be files like .gitignore,
+  whose content should always be part of the git repository, so 
+  they will not be added to the annex. Setting annex.dotfiles to true
+  makes dotfiles be added to the annex the same as any other file. 
+
+  This sets a default, which can be overridden by annex.dotfiles
+  in `git config`.
+
+* `annex.addunlocked`
+
+   Commands like `git-annex add` default to adding files to the repository
+   in locked form. This can make them add the files in unlocked form,
+   the same as if [[git-annex-unlock]](1) were run on the files.
+ 
+   This can be set to "true" to add everything unlocked, or it can be a more
+   complicated expression that matches files by name, size, or content. See
+   [[git-annex-matching-expression]](1) for details.
+
+   This sets a default, which can be overridden by annex.addunlocked
+   in `git config`.
+
+* `annex.autocommit`
+
+  Set to false to prevent the `git-annex assistant`, `git-annex assist`
+  and `git-annex sync` from automatically committing changes to files
+  in the repository.
+   
+  This sets a default, which can be overridden by annex.autocommit
+  in `git config`.
+
+* `annex.resolvemerge`
+
+  Set to false to prevent merge conflicts in the checked out branch
+  being automatically resolved by the `git-annex assitant`,
+  `git-annex sync`, `git-annex pull`, ``git-annex merge`, 
+  and the `git-annex post-receive` hook.
+   
+  This sets a default, which can be overridden by annex.resolvemerge
+  in `git config`.
+
+* `annex.synccontent`
+
+  Set to true to make `git-annex sync` default to transferring
+  annexed content.
+  
+  Set to false to prevent `git-annex pull` and `git-annex` push from
+  transferring annexed content.
+  
+  This sets a default, which can be overridden by annex.synccontent
+  in `git config`.
+
+* `annex.synconlyannex`
+
+  Set to true to make `git-annex sync`, `git-annex pull` and `git-annex
+  push` default to only operate on the git-annex branch and annexed content.
+  
+  This sets a default, which can be overridden by annex.synconlyannex
+  in `git config`.
+
+* `annex.securehashesonly`
+
+  Set to true to indicate that the repository should only use
+  cryptographically secure hashes (SHA2, SHA3) and not insecure
+  hashes (MD5, SHA1) for content.
+
+  When this is set, the contents of files using cryptographically
+  insecure hashes will not be allowed to be added to the repository.
+
+  Also, `git-annex fsck` will complain about any files present in
+  the repository that use insecure hashes.
+  
+  Note that this is only read from the git-annex branch by
+  `git annex init`, and is copied to the corresponding git config setting. 
+  So, changes to the value in the git-annex branch won't affect a
+  repository once it has been initialized.
+
+# OPTIONS
+
+* `--set name value`
+
+  Set a value.
+
+* `--get name`
+
+  Get a value.
+
+* `--unset`
+
+  Unset a value.
+
+* `--show-origin name`
+
+  Explain where the value is configured, whether in the git-annex branch,
+  or in a `git config` file, or `.gitattributes` file. When a value is
+  configured in multiple places, displays the place and the value that
+  will be used.
+
+  Note that the parameter can be the name of one of the settings listed
+  above, but also any other configuration setting supported by git-annex.
+  For example, "annex.backend" cannot be set in the git-annex branch, but
+  it can be set in `.gitattributes` or `git config` and this option can
+  explain which setting will be used for it.
+
+* `--for-file file`
+
+  Can be used in combination with `--show-origin` to specify what
+  filename to check for in `.gitattributes`.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# EXAMPLE
+
+Suppose you want to prevent git annex sync from committing changes
+to files, so a manual git commit workflow is used in all clones of the
+repository. Then run:
+
+	git annex config --set annex.autocommit false
+
+If you want to override that in a partiticular clone, just use git config
+in the clone:
+
+	git config annex.autocommit true
+
+And to get back to the default behavior:
+
+	git annex config --unset annex.autocommit
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+git-config(1)
+
+[[git-annex-vicfg]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-config/comment_1_26bd743439e87e71b1eea2c620e6fc12._comment b/doc/git-annex-config/comment_1_26bd743439e87e71b1eea2c620e6fc12._comment
new file mode 100644
index 0000000000..b344fdbc09
--- /dev/null
+++ b/doc/git-annex-config/comment_1_26bd743439e87e71b1eea2c620e6fc12._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="davi.castro@13c06889d1a1aef6321227888bd7d6b73d5692ea"
+ nickname="davi.castro"
+ avatar="http://cdn.libravatar.org/avatar/615c6641965d1fa6b58b96d52f8a96b3"
+ subject="Is git annex config still supported?"
+ date="2018-03-06T03:03:45Z"
+ content="""
+I`m using version: 5.20151208 and there is no such command as git annex config. 
+It is also not listed on git annex help
+"""]]
diff --git a/doc/git-annex-config/comment_2_0cf3e61f86b217b89dcace22bdfaaa44._comment b/doc/git-annex-config/comment_2_0cf3e61f86b217b89dcace22bdfaaa44._comment
new file mode 100644
index 0000000000..a55b4990e9
--- /dev/null
+++ b/doc/git-annex-config/comment_2_0cf3e61f86b217b89dcace22bdfaaa44._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-03-06T17:39:40Z"
+ content="""
+@davi, you are using an *ancient* version of git-annex, 
+from before this command was added. Upgrade.
+"""]]
diff --git a/doc/git-annex-config/comment_3_cd443c49f9d1122f078872259e342683._comment b/doc/git-annex-config/comment_3_cd443c49f9d1122f078872259e342683._comment
new file mode 100644
index 0000000000..8d0642a473
--- /dev/null
+++ b/doc/git-annex-config/comment_3_cd443c49f9d1122f078872259e342683._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="contr-error"
+ avatar="http://cdn.libravatar.org/avatar/d79c2491dfc6947b8084796b06174cdb"
+ subject="More settings here"
+ date="2023-06-23T09:18:11Z"
+ content="""
+See also [[git-annex]], under \"CONFIGURATION OF REMOTES\" for more settings which can be set using git-annex-config.
+"""]]
diff --git a/doc/git-annex-config/comment_4_e1c484811ea276532ed1b5c965d4de1b._comment b/doc/git-annex-config/comment_4_e1c484811ea276532ed1b5c965d4de1b._comment
new file mode 100644
index 0000000000..8f5d5f39aa
--- /dev/null
+++ b/doc/git-annex-config/comment_4_e1c484811ea276532ed1b5c965d4de1b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-06-23T15:44:13Z"
+ content="""
+@contr-error nope, only the config settings listed on this man page can be
+set with `git-annex config`. Those others can only be set in `git config`.
+"""]]
diff --git a/doc/git-annex-configremote.mdwn b/doc/git-annex-configremote.mdwn
new file mode 100644
index 0000000000..d852373c7b
--- /dev/null
+++ b/doc/git-annex-configremote.mdwn
@@ -0,0 +1,41 @@
+# NAME
+
+git-annex configremote - changes special remote configuration
+
+# SYNOPSIS
+
+git annex configemote `name|uuid|desc [param=value ...]`
+
+# DESCRIPTION
+
+Changes the configuration of a special remote that was set up earlier
+by `git-annex initremote`. The special remote does not need to be enabled
+for use in the current repository, and this command will not enable it.
+
+This command can currently only be used to change the value of the
+`autoenable` parameter, eg "autoenable=false".
+
+To change other parameters, use `git-annex enableremote`
+
+# OPTIONS
+
+Most options are not prefixed by a dash, and set parameters of the remote,
+as shown above. 
+
+Also, the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-initremote]](1)
+
+[[git-annex-configremote]](1)
+
+[[git-annex-renameremote]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-contentlocation.mdwn b/doc/git-annex-contentlocation.mdwn
new file mode 100644
index 0000000000..f5030a6dd7
--- /dev/null
+++ b/doc/git-annex-contentlocation.mdwn
@@ -0,0 +1,36 @@
+# NAME
+
+git-annex contentlocation - looks up content for a key
+
+# SYNOPSIS
+
+git annex contentlocation `[key ...]`
+
+# DESCRIPTION
+
+This plumbing-level command looks up filename used to store the content 
+of a key. The filename is output to stdout. If the key's content is not
+present in the local repository, nothing is output, and it exits nonzero.
+
+# OPTIONS
+
+* `--batch`
+
+  Enable batch mode, in which a line containing the key is read from
+  stdin, the filename to its content is output to stdout (with a trailing
+  newline), and repeat.
+
+  Note that if a key's content is not present, an empty line is output to
+  stdout instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-copy.mdwn b/doc/git-annex-copy.mdwn
new file mode 100644
index 0000000000..add7a96f06
--- /dev/null
+++ b/doc/git-annex-copy.mdwn
@@ -0,0 +1,151 @@
+# NAME
+
+git-annex copy - copy content of files to/from another repository
+
+# SYNOPSIS
+
+git annex copy `[path ...] [--from=remote|--to=remote]`
+
+# DESCRIPTION
+
+Copies the content of files from or to another remote.
+
+With no parameters, operates on all annexed files in the current directory.
+Paths of files or directories to operate on can be specified.
+
+# OPTIONS
+
+* `--from=remote`
+
+  Copy the content of files from the specified
+  remote to the local repository.
+  
+  Any files that are not available on the remote will be silently skipped.
+
+* `--to=remote`
+
+  Copy the content of files from the local repository
+  to the specified remote.
+
+* `--to=here`
+
+  Copy the content of files from all reachable remotes to the local
+  repository.
+
+* `--from=remote1 --to=remote2`
+
+  Copy the content of files that are in remote1 to remote2.
+
+  This is implemented by first downloading the content from remote1 to the
+  local repository (if not already present), then sending it to remote2, and
+  then deleting the content from the local repository (if it was not present
+  to start with).
+
+* `--from-anywhere --to=remote`
+
+  Copy to the remote files from the local repository as well as from any reachable
+  remotes.
+
+* `--jobs=N` `-JN`
+
+  Enables parallel transfers with up to the specified number of jobs
+  running at once. For example: `-J10`
+
+  Setting this to "cpus" will run one job per CPU core.
+
+  Note that when using --from with --to, twice this many jobs will
+  run at once, evenly split between the two remotes.
+
+* `--auto`
+
+  Rather than copying all specified files, only copy those that don't yet have
+  the desired number of copies, or that are preferred content of the
+  destination repository. See [[git-annex-preferred-content]](1)
+
+* `--fast`
+
+  When copying content to a remote, avoid a round trip to check if the remote
+  already has content. This can be faster, but might skip copying content
+  to the remote in some cases.
+
+* `--all` `-A`
+
+  Rather than specifying a filename or path to copy, this option can be
+  used to copy all available versions of all files.
+
+  This is the default behavior when running git-annex in a bare repository.
+
+* `--branch=ref`
+
+  Operate on files in the specified branch or treeish.
+
+* `--unused`
+
+  Operate on files found by last run of git-annex unused.
+
+* `--failed`
+
+  Operate on files that have recently failed to be transferred.
+
+* `--key=keyname`
+
+  Use this option to copy a specified key.
+
+* matching options
+
+  The [[git-annex-matching-options]](1)
+  can be used to specify what to copy.
+
+* `--batch`
+
+  Enables batch mode, in which lines containing names of files to copy
+  are read from stdin.
+
+  As each specified file is processed, the usual progress output is
+  displayed. If a file's content does not need to be copied, or it does not
+  match specified matching options, or it is not an annexed file,
+  a blank line is output in response instead.
+
+  Since the usual output while copying a file is verbose and not
+  machine-parseable, you may want to use --json in combination with
+  --batch.
+
+* `--batch-keys`
+
+  This is like `--batch` but the lines read from stdin are parsed as keys.
+
+* `-z`
+
+  Makes batch input be delimited by nulls instead of the usual newlines.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-progress`
+
+  Include progress objects in JSON output.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-get]](1)
+
+[[git-annex-move]](1)
+
+[[git-annex-drop]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-copy/comment_1_9be279110a112335bc72ee8c8a347da2._comment b/doc/git-annex-copy/comment_1_9be279110a112335bc72ee8c8a347da2._comment
new file mode 100644
index 0000000000..026a2b1455
--- /dev/null
+++ b/doc/git-annex-copy/comment_1_9be279110a112335bc72ee8c8a347da2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="tomekwi"
+ subject="--all seems to do nothing"
+ date="2015-07-03T05:14:37Z"
+ content="""
+Hi,
+
+I want to back up all my files including previous versions on an external drive. I’ve tried these two commands – both of them exited instantly without producing any output:
+
+    $ git-annex copy --all --to=external-drive
+    $ git-annex copy --unused --to=external-drive
+"""]]
diff --git a/doc/git-annex-copy/comment_2_599958b0a57d2f8f4383733d28ad9c8d._comment b/doc/git-annex-copy/comment_2_599958b0a57d2f8f4383733d28ad9c8d._comment
new file mode 100644
index 0000000000..687018bb01
--- /dev/null
+++ b/doc/git-annex-copy/comment_2_599958b0a57d2f8f4383733d28ad9c8d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="tomekwi"
+ subject="comment 2"
+ date="2015-07-03T05:17:12Z"
+ content="""
+By the way I’m running 5.20140717 – the version distributed by Fedora.
+"""]]
diff --git a/doc/git-annex-copy/comment_3_a9408822e314c32bebf8230f9d40216b._comment b/doc/git-annex-copy/comment_3_a9408822e314c32bebf8230f9d40216b._comment
new file mode 100644
index 0000000000..b62a73221f
--- /dev/null
+++ b/doc/git-annex-copy/comment_3_a9408822e314c32bebf8230f9d40216b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-06T17:39:58Z"
+ content="""
+Commenting on a man page is not the right way to report a problem. File a
+bug report.
+
+FWIW, copy --all works fine in my tests. Of course, there are certianly
+situations where it copies nothing. Eg, if there are no files with ontents
+in the repository for it to copy.
+"""]]
diff --git a/doc/git-annex-copy/comment_4_44dcb42a011cc203655bccca06de2e10._comment b/doc/git-annex-copy/comment_4_44dcb42a011cc203655bccca06de2e10._comment
new file mode 100644
index 0000000000..abd34e5978
--- /dev/null
+++ b/doc/git-annex-copy/comment_4_44dcb42a011cc203655bccca06de2e10._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="b@526b37d9a821b5f9ce4e48014422239233ded155"
+ nickname="b"
+ subject="Fetch files from two (or more) remotes simultaneously?"
+ date="2016-03-21T22:47:42Z"
+ content="""
+Let's assume that user has two slow remotes. Is it possible to fetch the data from both to at least partially speed-up the process?
+"""]]
diff --git a/doc/git-annex-copy/comment_5_fe7c2c6617b3a5ca153af2225fc66498._comment b/doc/git-annex-copy/comment_5_fe7c2c6617b3a5ca153af2225fc66498._comment
new file mode 100644
index 0000000000..c243d981a7
--- /dev/null
+++ b/doc/git-annex-copy/comment_5_fe7c2c6617b3a5ca153af2225fc66498._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-04-04T20:30:33Z"
+ content="""
+If you run `git annex copy --from slowremote1` in one terminal and at the
+same time run `git annex copy --from slowremote2` in another terminal,
+the two processes will cooperatively get the files, spreading the load 
+amoung the remotes. This works because git-annex avoids downloading a file
+if the same file is already being downloaded by a different process.
+"""]]
diff --git a/doc/git-annex-dead.mdwn b/doc/git-annex-dead.mdwn
new file mode 100644
index 0000000000..a0f074daca
--- /dev/null
+++ b/doc/git-annex-dead.mdwn
@@ -0,0 +1,65 @@
+# NAME
+
+git-annex dead - hide a lost repository or key
+
+# SYNOPSIS
+
+git annex dead `[repository ...] [--key somekey ...]`
+
+# DESCRIPTION
+
+This command exists to deal with situations where data has been lost,
+and you know it has, and you want to stop being reminded of that fact.
+
+When a repository is specified, indicates that the repository has
+been irretrievably lost, so it will not be listed in eg, `git annex whereis`.
+Repositories can be specified using their remote name, their
+description, or their UUID. (To undo, use `git-annex semitrust`.)
+
+When a key is specified, indicates that the content of that key has been
+irretrievably lost. This makes the key be skipped when operating
+on all keys with eg `--all`.
+(To undo, add the key's content back to the repository, 
+by using eg, `git-annex reinject`.)
+
+# OPTIONS
+
+* `--key=somekey`
+
+  Use to specify a key that is dead.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-trust]](1)
+
+[[git-annex-semitrust]](1)
+
+[[git-annex-untrust]](1)
+
+[[git-annex-renameremote]](1)
+
+[[git-annex-expire]](1)
+
+[[git-annex-fsck]](1)
+
+[[git-annex-reinject]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-describe.mdwn b/doc/git-annex-describe.mdwn
new file mode 100644
index 0000000000..3dba674966
--- /dev/null
+++ b/doc/git-annex-describe.mdwn
@@ -0,0 +1,45 @@
+# NAME
+
+git-annex describe - change description of a repository
+
+# SYNOPSIS
+
+git annex describe repository description
+
+# DESCRIPTION
+
+Changes the description of a repository.
+
+The repository to describe can be specified by git remote name or
+by uuid. To change the description of the current repository, use
+"here".
+
+Repository descriptions are displayed by git-annex in various places.
+They are most useful when git-annex knows about a repository, but there is
+no git remote corresponding to it.
+
+# OPTIONS
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-init]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-diffdriver.mdwn b/doc/git-annex-diffdriver.mdwn
new file mode 100644
index 0000000000..4669838955
--- /dev/null
+++ b/doc/git-annex-diffdriver.mdwn
@@ -0,0 +1,64 @@
+# NAME
+
+git-annex diffdriver - git diff driver
+
+# SYNOPSIS
+
+`git annex diffdriver [--get,--text] [-- --diffopts --]`
+
+`git annex diffdriver -- cmd --cmdopts --`
+
+# DESCRIPTION
+
+Normally, `git diff` when run on annexed files displays the changes that
+are staged in git, eg annex symlinks and pointers. This command allows
+`git diff` to diff the content of annexed files instead.
+
+This command can be used either as a simple text differ,
+or as a shim that runs an external git diff driver.
+
+If some of your annexed files are textual in form, and can be usefully
+diffed with diff(1), you can configure git to use this command to diff
+them, by configuring `.gitattributes` to contain eg `*.txt diff=annextextdiff`
+and setting `git config diff.annextextdiff.command "git annex diffdriver --text"`.
+
+If your annexed files are not textual in form, you will need an external
+diff driver program that is able to diff the file format(s) you use.
+See git's documentation of `GIT_EXTERNAL_DIFF` and
+gitattributes(5)'s documentation of external diff drivers.
+
+Normally, when using `git diff` with an external diff driver, it will not
+see the contents of annexed files, since git passes to it the git-annex
+symlinks or pointer files. This command works around the problem, by
+running the real external diff driver, and passing it the paths to the
+annexed content. Configure git to use "git-annex diffdriver -- cmd params --"
+as the external diff driver, where cmd is the external diff
+driver you want it to run, and params are any extra parameters to pass
+to it. Note the trailing "--", which is required.
+
+For example, to use the j-c-diff program as the external diff driver, 
+set `GIT_EXTERNAL_DIFF="git-annex diffdriver -- j-c-diff --"`
+
+# OPTIONS
+
+To get the contents of annexed files from remotes when they are not already
+present, use the `--get` option. The file contents will remain in the
+repository for later use until dropped in the usual ways.
+
+To diff text files with diff(1), use the `--text` option.
+To pass additional options to diff(1), use eg "--text -- --color --"
+
+To use an external diff driver command, the options must start with
+"--" followed by the diff driver command, its options, and another "--"
+
+Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-diffdriver/comment_1_b45fd606668e2eee0a37bf1db3391f37._comment b/doc/git-annex-diffdriver/comment_1_b45fd606668e2eee0a37bf1db3391f37._comment
new file mode 100644
index 0000000000..a6b63ceed5
--- /dev/null
+++ b/doc/git-annex-diffdriver/comment_1_b45fd606668e2eee0a37bf1db3391f37._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="v@80d733f66c2e675c27ee39df565ebed8d0ea12de"
+ nickname="v"
+ avatar="http://cdn.libravatar.org/avatar/5d1f51d6e21cfcfb0da6dfe0aea2fc77"
+ subject="Outdated?"
+ date="2023-10-24T13:26:44Z"
+ content="""
+This article seems outdated. `--text` is not a valid option in version 8.20210223 and `GIT_EXTERNAL_DIFF=\"git annex diffdriver -- diff --\" git diff` fails with `diff: extra operand '<commit hash>'`.
+"""]]
diff --git a/doc/git-annex-diffdriver/comment_2_05c3a29d7827dd6fc5babe0ac1ff2a94._comment b/doc/git-annex-diffdriver/comment_2_05c3a29d7827dd6fc5babe0ac1ff2a94._comment
new file mode 100644
index 0000000000..5733e664e4
--- /dev/null
+++ b/doc/git-annex-diffdriver/comment_2_05c3a29d7827dd6fc5babe0ac1ff2a94._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="v@80d733f66c2e675c27ee39df565ebed8d0ea12de"
+ nickname="v"
+ avatar="http://cdn.libravatar.org/avatar/5d1f51d6e21cfcfb0da6dfe0aea2fc77"
+ subject="Minimum required version"
+ date="2023-10-24T14:27:24Z"
+ content="""
+It was me that was outdated. `--text` works as expected on `10.20230828`.
+"""]]
diff --git a/doc/git-annex-direct.mdwn b/doc/git-annex-direct.mdwn
new file mode 100644
index 0000000000..909015ae48
--- /dev/null
+++ b/doc/git-annex-direct.mdwn
@@ -0,0 +1,27 @@
+# NAME
+
+git-annex direct - switch repository to direct mode (deprecated)
+
+# SYNOPSIS
+
+git annex direct
+
+# DESCRIPTION
+
+This used to switch a repository to use direct mode.
+But direct mode is no longer used; git-annex automatically converts
+direct mode repositories to v7 adjusted unlocked branches.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-indirect]](1)
+
+[[git-annex-adjust]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-direct/comment_1_5d6f9e9393e534e027ddcd555861196b._comment b/doc/git-annex-direct/comment_1_5d6f9e9393e534e027ddcd555861196b._comment
new file mode 100644
index 0000000000..4b94b68fe6
--- /dev/null
+++ b/doc/git-annex-direct/comment_1_5d6f9e9393e534e027ddcd555861196b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tomekwi"
+ subject="direct mode within a directory?"
+ date="2015-06-13T13:03:33Z"
+ content="""
+Hi, is it possible to enable direct mode only on a single directory?
+
+I can’t use symlinks on a part of my repo because of interoperability with http://tagspaces.org . And I don’t want to have all of my repo in direct mode.
+"""]]
diff --git a/doc/git-annex-direct/comment_2_ef8ac748470549776c1ee299b062add2._comment b/doc/git-annex-direct/comment_2_ef8ac748470549776c1ee299b062add2._comment
new file mode 100644
index 0000000000..2329a5ee83
--- /dev/null
+++ b/doc/git-annex-direct/comment_2_ef8ac748470549776c1ee299b062add2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="tomekwi"
+ subject="…"
+ date="2015-06-13T13:07:49Z"
+ content="""
+Using submodules to split the repo doesn’t work cleanly for me, by the way.
+"""]]
diff --git a/doc/git-annex-drop.mdwn b/doc/git-annex-drop.mdwn
new file mode 100644
index 0000000000..aa66696958
--- /dev/null
+++ b/doc/git-annex-drop.mdwn
@@ -0,0 +1,152 @@
+# NAME
+
+git-annex drop - remove content of files from repository
+
+# SYNOPSIS
+
+git annex drop `[path ...]`
+
+# DESCRIPTION
+
+Drops the content of annexed files from this repository, when
+possible.
+
+git-annex will refuse to drop content if it cannot verify it is
+safe to do so. Usually this involves verifying that the content is stored
+in some other repository.
+
+Content that is required to be stored in the repository will not be dropped
+even if enough copies exist elsewhere. See [[git-annex-required]](1).
+
+With no parameters, tries to drop all annexed files in the current directory.
+Paths of files or directories to drop can be specified.
+
+# EXAMPLES
+
+	# git annex drop *.jpeg
+	drop photo1.jpg (checking origin...) ok
+	drop photo2.jpg (unsafe)
+	  Could only verify the existence of 0 out of 1 necessary copies
+
+	  Rather than dropping this file, try using: git annex move
+
+	  (Use --force to override this check, or adjust numcopies.)
+	failed
+	drop photo3.jpg (checking origin...) ok
+
+# OPTIONS
+
+* `--from=remote`
+
+  Rather than dropping the content of files in the local repository,
+  this option can specify a remote from which the files'
+  contents should be removed.
+
+* `--auto`
+
+  Rather than trying to drop all specified files, drop only those that
+  are not preferred content of the repository, and avoid trying to drop
+  files when there are not enough other copies for the drop to be possible.
+  See [[git-annex-preferred-content]](1)
+
+* `--force`
+
+  Use this option with care! It bypasses safety checks, and forces
+  git-annex to delete the content of the specified files, even from
+  the last repository that is storing their content. Data loss can
+  result from using this option.
+
+* `--all` `-A`
+
+  Rather than specifying a filename or path to drop, this option can be
+  used to drop all available versions of all files.
+
+  This is the default behavior when running git-annex drop in a bare
+  repository.
+
+  Note that this bypasses checking the .gitattributes annex.numcopies
+  setting and required content settings.
+
+* `--branch=ref`
+
+  Drop files in the specified branch or treeish.
+
+  Note that this bypasses checking the .gitattributes annex.numcopies
+  setting and required content settings.
+
+* `--unused`
+
+  Drop files found by last run of git-annex unused.
+
+  Note that this bypasses checking the .gitattributes annex.numcopies
+  setting and required content settings.
+
+* `--key=keyname`
+
+  Use this option to drop a specified key.
+
+  Note that this bypasses checking the .gitattributes annex.numcopies
+  setting and required content settings.
+
+* matching options
+
+  The [[git-annex-matching-options]](1)
+  can be used to specify what to drop.
+
+* `--jobs=N` `-JN`
+
+  Runs multiple drop jobs in parallel. This is particularly useful
+  when git-annex has to contact remotes to check if it can drop files.
+  For example: `-J4`  
+
+  Setting this to "cpus" will run one job per CPU core.
+
+* `--batch`
+
+  Enables batch mode, in which lines containing names of files to drop
+  are read from stdin.
+
+  As each specified file is processed, the usual output is
+  displayed. If a file's content is not present, or it does not
+  match specified matching options, or it is not an annexed file,
+  a blank line is output in response instead.
+
+* `--batch-keys`
+
+  This is like `--batch` but the lines read from stdin are parsed as keys.
+
+  Note that this bypasses checking the .gitattributes annex.numcopies
+  setting and required content settings.
+
+* `-z`
+
+  Makes the batch input be delimited by nulls
+  instead of the usual newlines.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-get]](1)
+
+[[git-annex-move]](1)
+
+[[git-annex-copy]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-drop/comment_10_9ed8d998831414436e5d0e100ed96fb7._comment b/doc/git-annex-drop/comment_10_9ed8d998831414436e5d0e100ed96fb7._comment
new file mode 100644
index 0000000000..48500cff2b
--- /dev/null
+++ b/doc/git-annex-drop/comment_10_9ed8d998831414436e5d0e100ed96fb7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="lh"
+ avatar="http://cdn.libravatar.org/avatar/d31bade008d7da493d9bfb37d68fd825"
+ subject="The man page export seems to be broken"
+ date="2022-04-15T12:26:20Z"
+ content="""
+When I rebuild the man pages on my system, this one has an error. Maybe there's a formatting issue?
+"""]]
diff --git a/doc/git-annex-drop/comment_11_95c5be6e2be84dc0903e3d7384f67313._comment b/doc/git-annex-drop/comment_11_95c5be6e2be84dc0903e3d7384f67313._comment
new file mode 100644
index 0000000000..738f432f8b
--- /dev/null
+++ b/doc/git-annex-drop/comment_11_95c5be6e2be84dc0903e3d7384f67313._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2022-04-19T15:56:05Z"
+ content="""
+@lh it builds for me and the man page looks ok.
+I suggest you file a bug report with the details about your problem.
+"""]]
diff --git a/doc/git-annex-drop/comment_1_ecb863aea64eadbaeb7759c5cb0bf5a5._comment b/doc/git-annex-drop/comment_1_ecb863aea64eadbaeb7759c5cb0bf5a5._comment
new file mode 100644
index 0000000000..1ca83ec18f
--- /dev/null
+++ b/doc/git-annex-drop/comment_1_ecb863aea64eadbaeb7759c5cb0bf5a5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="zpeters@669a56d871ec94de11e1bf63f4a21e80ea90b2fa"
+ nickname="zpeters"
+ subject="Choose which remote to lock when dropping"
+ date="2016-05-03T23:37:09Z"
+ content="""
+I might have a unique situation but i have a git annex repo that has multiple remotes for the same actual location.  I have a server at home and when i'm \"out in the world\" i use it's external IP and when i'm at home i use it's internal IP.  It appears that when i do an git annex drop on my laptop to compares and locks whichever remote is alphabetically first.  
+
+What i'm wondering is is there a way to tell git annex which remote i want to compare against?  For example when i'm remote i want to do something like \"git annex drop . --compare remoteServer\"
+
+Thank you!
+"""]]
diff --git a/doc/git-annex-drop/comment_2_c9017041b01d803b346b1b14b8d1e066._comment b/doc/git-annex-drop/comment_2_c9017041b01d803b346b1b14b8d1e066._comment
new file mode 100644
index 0000000000..63047d7447
--- /dev/null
+++ b/doc/git-annex-drop/comment_2_c9017041b01d803b346b1b14b8d1e066._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-04T17:23:41Z"
+ content="""
+@zpeters, the order that remotes are accessed are ordered by cost.
+
+You can configure the costs of remotes by setting remote.$name.annex-cost
+to eg 100 to make it be checked first or 300 to make it be checked later.
+
+There's also a remote.$name.annex-cost-command that runs a command to get
+the cost. You could perhaps use that to detect which network you're on and
+alter the costs appropriately.
+"""]]
diff --git a/doc/git-annex-drop/comment_3_16095aad685d142672911e799450634a._comment b/doc/git-annex-drop/comment_3_16095aad685d142672911e799450634a._comment
new file mode 100644
index 0000000000..13ac15c7e0
--- /dev/null
+++ b/doc/git-annex-drop/comment_3_16095aad685d142672911e799450634a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="zpeters"
+ avatar="http://cdn.libravatar.org/avatar/a8695228ff82f18c9a43c0763194c1cd"
+ subject="RE: choosing remotes and annex-cost-command"
+ date="2017-02-28T01:10:05Z"
+ content="""
+Finally got around to playing with this today figured i'd post an example for anyone looking fr this in the future.  Please forgive the TCL code if that isn't your thing.
+
+1. Adding the \"cost command\" to your remotes - Example here <https://gist.github.com/zpeters/d288531db95aa69a495944a261d17b1c>
+2. The actual script being referenced is really basic.  It's basically taking the name of the remote as an argument and depending on where i am it will give that remote a \"high\" or \"low\" cost.  Code here <https://gist.github.com/zpeters/89ba09289c89225ae5344e65c3562e6c>
+3. The cost script needs to know if I'm \"home\" or not.  Here is an example of \"whereami\" <https://gist.github.com/zpeters/cb8c2be53fd41b4d04a78fe81aaaea58>
+
+
+"""]]
diff --git a/doc/git-annex-drop/comment_4_156873ca9820b316a2099b6646562891._comment b/doc/git-annex-drop/comment_4_156873ca9820b316a2099b6646562891._comment
new file mode 100644
index 0000000000..4bf20dd61b
--- /dev/null
+++ b/doc/git-annex-drop/comment_4_156873ca9820b316a2099b6646562891._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~liori"
+ nickname="liori"
+ avatar="http://cdn.libravatar.org/avatar/e1d0fdc746b3d21bb147160d40815e37b257b9119774d21784939b2d3ba95a91"
+ subject="The meaning of &quot;safe&quot;"
+ date="2018-06-28T23:27:05Z"
+ content="""
+What does \"safe\" mean? Does `drop` just check if there are enough copies in other repositories in its local cache, does it contact remote repositories to check its own cache, or maybe even checks if the physical file in the remote repository has the right checksum?
+"""]]
diff --git a/doc/git-annex-drop/comment_5_655f0bcaafdf03eb637af715e7642e27._comment b/doc/git-annex-drop/comment_5_655f0bcaafdf03eb637af715e7642e27._comment
new file mode 100644
index 0000000000..55986f5ee6
--- /dev/null
+++ b/doc/git-annex-drop/comment_5_655f0bcaafdf03eb637af715e7642e27._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-07-02T16:08:27Z"
+ content="""
+@liori, see [[copies]] for how git-annex assures safety when dropping
+content.
+"""]]
diff --git a/doc/git-annex-drop/comment_6_ed46bc0407457fc5db0d5241ba69d9ed._comment b/doc/git-annex-drop/comment_6_ed46bc0407457fc5db0d5241ba69d9ed._comment
new file mode 100644
index 0000000000..db896522e8
--- /dev/null
+++ b/doc/git-annex-drop/comment_6_ed46bc0407457fc5db0d5241ba69d9ed._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/iOGTltEpmOTQ.xZ99NFP5c7Zdcc-#6a7ba"
+ nickname="Ilya S"
+ avatar="http://cdn.libravatar.org/avatar/8a133555cc739a35b83b07d5724d28d9e2f7852c224e949eec6fd4fb7693331e"
+ subject="comment 6"
+ date="2018-09-07T18:10:05Z"
+ content="""
+Is there a way to drop everything _except_ files under a given path in the repository?   If not, it would be good to add this option.
+It should also not drop a file if it is outside the path but is pointed to by a relative symlink under the path.
+"""]]
diff --git a/doc/git-annex-drop/comment_7_f9b255923bdb20c92b878d86998b7ae2._comment b/doc/git-annex-drop/comment_7_f9b255923bdb20c92b878d86998b7ae2._comment
new file mode 100644
index 0000000000..3050fcbc4f
--- /dev/null
+++ b/doc/git-annex-drop/comment_7_f9b255923bdb20c92b878d86998b7ae2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="re: drop everything but subdirectory"
+ date="2018-09-07T20:13:03Z"
+ content="""
+> Is there a way to drop everything except files under a given path in the repository?
+
+You can use something like `git annex drop --exclude='subdir/*'`.  See `man git-annex-matching-options`.
+
+"""]]
diff --git a/doc/git-annex-drop/comment_8_cf6fbdc5355aebe33188825d578690c1._comment b/doc/git-annex-drop/comment_8_cf6fbdc5355aebe33188825d578690c1._comment
new file mode 100644
index 0000000000..fd25a3561c
--- /dev/null
+++ b/doc/git-annex-drop/comment_8_cf6fbdc5355aebe33188825d578690c1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 8"
+ date="2022-04-04T20:01:14Z"
+ content="""
+might be also worth referencing `find` as the ultimate source for options used by `drop` but not listed here, such as `--in`, `--copies` etc.
+
+On behalf of struggling users 
+Cheers
+"""]]
diff --git a/doc/git-annex-drop/comment_9_55d96bb12b325954bb7e7817f1a8ff3f._comment b/doc/git-annex-drop/comment_9_55d96bb12b325954bb7e7817f1a8ff3f._comment
new file mode 100644
index 0000000000..1a453bfa25
--- /dev/null
+++ b/doc/git-annex-drop/comment_9_55d96bb12b325954bb7e7817f1a8ff3f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-04-05T17:43:24Z"
+ content="""
+@yarikoptic --in --copies etc are documented in 
+[[git-annex-matching-options]] which this page does link to.
+"""]]
diff --git a/doc/git-annex-dropkey.mdwn b/doc/git-annex-dropkey.mdwn
new file mode 100644
index 0000000000..1b0ba61ac2
--- /dev/null
+++ b/doc/git-annex-dropkey.mdwn
@@ -0,0 +1,49 @@
+# NAME
+
+git-annex dropkey - drops annexed content for specified keys
+
+# SYNOPSIS
+
+git annex dropkey `[key ...]`
+
+# DESCRIPTION
+
+This plumbing-level command drops the annexed data for the specified
+keys from this repository.
+
+This can be used to drop content for arbitrary keys, which do not need
+to have a file in the git repository pointing at them.
+
+Warning: This command does not check that enough other copies of the content
+exist; using it can easily result in data loss.
+
+# OPTIONS
+
+* `--batch`
+
+  Enables batch mode, in which lines containing keys to drop are read from
+  stdin.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-setkey]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-dropunused.mdwn b/doc/git-annex-dropunused.mdwn
new file mode 100644
index 0000000000..31f6abf114
--- /dev/null
+++ b/doc/git-annex-dropunused.mdwn
@@ -0,0 +1,65 @@
+# NAME
+
+git-annex dropunused - drop unused file content
+
+# SYNOPSIS
+
+git annex dropunused `[number|range ...]`
+
+# DESCRIPTION
+
+Drops the data corresponding to the numbers, as listed by the last
+`git annex unused`
+
+You can also specify ranges of numbers, such as "1-1000".
+Or, specify "all" to drop all unused data.
+
+# OPTIONS
+
+* `--from=remote`
+
+  Rather than dropping the unused files from the local repository,
+  drop them from the remote repository.
+
+* `--force`
+
+  Use this option with care! It bypasses safety checks, and forces
+  git-annex to delete the content of the specified files, even from
+  the last repository that is storing their content. Data loss can
+  result from using this option.
+
+* `--jobs=N` `-JN`
+
+  Runs multiple drop jobs in parallel. This is particularly useful
+  when git-annex has to contact remotes to check if it can drop content.
+  For example: `-J4`  
+
+  Setting this to "cpus" will run one job per CPU core.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-unused]](1)
+
+[[git-annex-drop]](1)
+
+[[git-annex-copy]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-edit.mdwn b/doc/git-annex-edit.mdwn
new file mode 100644
index 0000000000..ef8502cfa6
--- /dev/null
+++ b/doc/git-annex-edit.mdwn
@@ -0,0 +1,18 @@
+# NAME
+
+git-annex unlock - unlock files for modification
+
+# SYNOPSIS
+
+git annex edit `[path ...]`
+
+# DESCRIPTION
+
+This is an alias for the `unlock` command; see [[git-annex-unlock]](1)
+for details.
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-enable-tor.mdwn b/doc/git-annex-enable-tor.mdwn
new file mode 100644
index 0000000000..e56008ec0f
--- /dev/null
+++ b/doc/git-annex-enable-tor.mdwn
@@ -0,0 +1,40 @@
+# NAME
+
+git-annex enable-tor - enable tor hidden service
+
+# SYNOPSIS
+
+git annex enable-tor
+
+sudo git annex enable-tor $(id -u)
+
+# DESCRIPTION
+
+This command enables a tor hidden service for git-annex.
+
+It modifies `/etc/tor/torrc` to register the hidden service. If run as a
+normal user, it will try to use sudo/su/etc to get root access to modify
+that file. If you run it as root, pass it your non-root user id number,
+as output by `id -u`
+
+After this command is run, `git annex remotedaemon` can be run to serve the
+tor hidden service, and then `git-annex p2p --gen-addresses` can be run to
+give other users access to your repository via the tor hidden service.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-p2p-auth]](1)
+
+[[git-annex-remotedaemon]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-enableremote.mdwn b/doc/git-annex-enableremote.mdwn
new file mode 100644
index 0000000000..bcc6728183
--- /dev/null
+++ b/doc/git-annex-enableremote.mdwn
@@ -0,0 +1,88 @@
+# NAME
+
+git-annex enableremote - enables git-annex to use a remote
+
+# SYNOPSIS
+
+git annex enableremote `name|uuid|desc [param=value ...]`
+
+# DESCRIPTION
+
+Enables use of an existing remote in the current repository,
+that was set up earlier by `git annex initremote` run in
+another clone of the repository.
+
+When enabling a remote, specify the same name used when originally
+setting up that remote with `git annex initremote`. Run 
+`git annex enableremote` without any name to get a list of
+remote names. Or you can specify the uuid or description of the
+remote.
+  
+Some types of special remotes need parameters to be specified every time
+they are enabled. For example, the directory special remote requires a
+directory= parameter every time. The command will prompt for any required
+parameters you leave out.
+
+This command can also be used to modify the configuration of an existing
+special remote, by specifying new values for parameters that are
+usually set when using initremote. (However, some settings such as
+the as the encryption scheme cannot be changed once a special remote
+has been created.)
+
+The GPG keys that an encrypted special remote is encrypted with can be
+changed using the keyid+= and keyid-= parameters. These respectively
+add and remove keys from the list. However, note that removing a key
+does NOT necessarily prevent the key's owner from accessing data
+in the encrypted special remote
+(which is by design impossible, short of deleting the remote).
+  
+One use-case of keyid-= is to replace a revoked key with
+a new key:
+  
+	git annex enableremote mys3 keyid-=revokedkey keyid+=newkey
+  
+Also, note that for encrypted special remotes using plain public-key
+encryption (encryption=pubkey), adding or removing a key has NO effect
+on files that have already been copied to the remote. Hence using
+keyid+= and keyid-= with such remotes should be used with care, and
+make little sense except in cases like the revoked key example above.
+
+If you get tired of manually enabling a special remote in each new clone,
+you can pass "autoenable=true". Then when [[git-annex-init]](1) is run in
+a new clone, it will will attempt to enable the special remote. Of course,
+this works best when the special remote does not need anything special
+to be done to get it enabled.
+
+(This command also can be used to enable a git remote that git-annex
+has found didn't work before and gave up on using, setting 
+`remote.<name>.annex-ignore`.)
+
+# OPTIONS
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also, the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-initremote]](1)
+
+[[git-annex-configremote]](1)
+
+[[git-annex-renameremote]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-enableremote/comment_2_43876327581d6bcfb69c318c02d6389a._comment b/doc/git-annex-enableremote/comment_2_43876327581d6bcfb69c318c02d6389a._comment
new file mode 100644
index 0000000000..e3b51b6a9c
--- /dev/null
+++ b/doc/git-annex-enableremote/comment_2_43876327581d6bcfb69c318c02d6389a._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-02-14T18:16:52Z"
+ content="""
+@Sundar, good question.
+
+`git annex enableremote` will always refuse to enable the remote if there's
+a missing parameter, and prompt for the parameter. Finding the right value
+is up to you. Most of the time, no additional parameters are needed, or
+the parameters are fairly self-explanatory, eg login passwords for remote
+services.
+
+The difficulty with directory special remotes is that my /foo may not be
+the same as your /foo, so it can't reuse the directory= that was provided
+to initremote, and it's up to you to enter the right directory path.
+
+I think this needs to come down to documentation in the repository. The
+description of the remote (set by `git annex describe` 
+is a reasonable place to put that, unless you have somewhere better.
+"""]]
diff --git a/doc/git-annex-enableremote/comment_2_78223f5c6ad120d5e0b98583543425db._comment b/doc/git-annex-enableremote/comment_2_78223f5c6ad120d5e0b98583543425db._comment
new file mode 100644
index 0000000000..a42e2c6796
--- /dev/null
+++ b/doc/git-annex-enableremote/comment_2_78223f5c6ad120d5e0b98583543425db._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/80VlVB0Bx9TaNOXIj3OCQ8eimAtIOhqjUQ--#1e80e"
+ nickname="Sundar Raman"
+ avatar="http://cdn.libravatar.org/avatar/a5db56ac8777aee80bbe2b1e1d697c3961973049a22def38b4d15b7507e59c01"
+ subject="Retrieving initremote parameters for new user"
+ date="2017-02-14T00:04:50Z"
+ content="""
+Is there a way to determine the parameters that an enableremote command must use, if one does not know it? The use case is as follows:
+* Dev 1 performs an `initremote annexed-media directory=/path/to/media ...`
+* Dev 1 syncs content
+* Dev 2 comes along (or Dev 1 comes along months later with a different machine) and clones the repo, but needs to know the directory=/path... in order to 'enableremote'. Is there any way to glean this information from the source repo itself?
+
+The steps would be:
+
+```
+dev1$ git clone git@gitserver:myproject.git && cd myproject
+dev1$ mkdir images && touch images/foo1.png
+dev1$ git annex initremote annexation.dir directory=/mnt/media/myproject.annex/ encrypted=false
+dev1$ git commit && git push && git annex sync --content
+```
+
+<time passes >
+
+```
+dev2$ git clone git@gitserver:myproject.git && cd myproject
+dev2$ git annex whereis 
+# shows something like ...
+#    whereis images/foo1.png (7 copies) ...
+#        38e67e39-7dfb-45e8-90fc-8c5d01aae0b4 -- annexation.dir
+dev2$ git annex enableremote annexation.dir directory=???
+```
+
+So how does the new developer know how to define the annexation.dir? Is there any way to extract from the repo itself? Or must this information be saved into the repo's documentation to avoid losing the reference?
+
+Thanks!
+
+"""]]
diff --git a/doc/git-annex-enableremote/comment_3_4bc11d1df0ff6962b12f5b8a1bb6188e._comment b/doc/git-annex-enableremote/comment_3_4bc11d1df0ff6962b12f5b8a1bb6188e._comment
new file mode 100644
index 0000000000..e3a926d83c
--- /dev/null
+++ b/doc/git-annex-enableremote/comment_3_4bc11d1df0ff6962b12f5b8a1bb6188e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/80VlVB0Bx9TaNOXIj3OCQ8eimAtIOhqjUQ--#1e80e"
+ nickname="Sundar Raman"
+ avatar="http://cdn.libravatar.org/avatar/a5db56ac8777aee80bbe2b1e1d697c3961973049a22def38b4d15b7507e59c01"
+ subject="comment 3"
+ date="2017-02-14T20:21:41Z"
+ content="""
+Thanks much, did not think to use the 'describe' for that but that's very intuitive!
+"""]]
diff --git a/doc/git-annex-examinekey.mdwn b/doc/git-annex-examinekey.mdwn
new file mode 100644
index 0000000000..bd8e19e596
--- /dev/null
+++ b/doc/git-annex-examinekey.mdwn
@@ -0,0 +1,91 @@
+# NAME
+
+git-annex examinekey - prints information from a key
+
+# SYNOPSIS
+
+git annex examinekey `[key ...]`
+
+# DESCRIPTION
+
+This plumbing-level command is given a key, and prints information
+that can be determined purely by looking at the key.
+
+# OPTIONS
+
+* `--format=value`
+
+  Use custom output formatting.
+
+  The value is a format string, in which '${var}' is expanded to the
+  value of a variable. To right-justify a variable with whitespace,
+  use '${var;width}' ; to left-justify a variable, use '${var;-width}';
+  to escape unusual characters (including control characters)
+  in a variable, use '${escaped_var}'
+
+  To generate a path from the top of the repository to the git-annex
+  object for a key, use ${objectpath}. To generate the value of a
+  git-annex pointer file for a key, use ${objectpointer}.
+
+  These variables are also available for use in formats: ${key}, ${backend},
+  ${bytesize}, ${humansize}, ${keyname}, ${hashdirlower}, ${hashdirmixed},
+  ${mtime} (for the mtime field of a WORM key), ${file} (when a filename is
+  provided to examinekey).
+
+  Also, '\\n' is a newline, '\\000' is a NULL, etc.
+  
+  The default output format is the same as `--format='${escapedkey}\\n'`
+  except when outputting to a terminal, control characters will be escaped.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* `--migrate-to-backend=backend`
+
+  Attempt to migrate the input key to the new backend specified. If
+  successful, outputs information about the migrated key. Otherwise,
+  outputs information about the input key.
+
+  This only does fast migrations; it will not re-hash the content of a key
+  or similar expensive operation.
+
+  One way to use it is to add an extension to a key.
+
+	git-annex examinekey SHA256--xxx --migrate-to-backend=SHA256E --filename=foo.tar.gz
+
+  Or to remove the extension from a key:
+
+  	git-annex examinekey SHA256E--xxx.tar.gz --migrate-to-backend=SHA256
+
+* `--filename=name`
+
+  The name of a file associated with the key, eg a work tree file.
+  It does not need to exist. This is needed when using `--migrate-to-backend`
+  to add an extension to the key.
+
+* `--batch`
+
+  Enable batch mode, in which a line containing a key is read from stdin,
+  the information about it is output to stdout, and repeat.
+
+  In order to also provide the name of a file associated with the key, the
+  line can be in the format "$key $file"
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-expire.mdwn b/doc/git-annex-expire.mdwn
new file mode 100644
index 0000000000..e2c0d47d88
--- /dev/null
+++ b/doc/git-annex-expire.mdwn
@@ -0,0 +1,79 @@
+# NAME
+
+git-annex expire - expire inactive repositories
+
+# SYNOPSIS
+
+git annex expire `[repository:]time ...`
+
+# DESCRIPTION
+
+This command expires repositories that have not performed some activity
+within a specified time period. A repository is expired by marking it as
+dead. De-expiration is also done; if a dead repository performed some
+activity recently, it is marked as semitrusted again.
+
+This can be useful when it's not possible to keep track of the state
+of repositories manually. For example, a distributed network of
+repositories where nobody can directly access all the repositories to
+check their status.
+
+The repository can be specified using the name of a remote,
+or the description or uuid of the repository. 
+
+The time is in the form "60d" or "1y". A time of "never" will disable
+expiration.
+
+If a time is specified without a repository, it is used as the default
+value for all repositories. Note that the current repository is never
+expired.
+
+# OPTIONS
+
+* `--no-act`
+
+  Print out what would be done, but not not actually expire or unexpire
+  any repositories.
+
+* `--activity=Name`
+
+  Specify the activity that a repository must have performed to avoid being
+  expired. The default is any activity.
+
+  Currently, the only activity that can be performed to avoid expiration
+  is --activity=Fsck which corresponds to `git annex fsck`. 
+  Note that fscking a remote updates the expiration of the remote
+  repository, not the local repository.
+
+  The first version of git-annex that recorded fsck activity was
+  5.20150405.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-fsck]](1)
+
+[[git-annex-schedule]](1)
+
+[[git-annex-dead]](1)
+
+[[git-annex-semitrust]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-export.mdwn b/doc/git-annex-export.mdwn
new file mode 100644
index 0000000000..64770537c0
--- /dev/null
+++ b/doc/git-annex-export.mdwn
@@ -0,0 +1,175 @@
+# NAME
+
+git-annex export - export a tree of files to a special remote
+
+# SYNOPSIS
+
+git annex export `treeish --to remote`
+
+# DESCRIPTION
+
+Use this command to export a tree of files from a git-annex repository.
+
+Normally files are stored on a git-annex special remote named by their
+keys. That is great for reliable data storage, but your filenames are
+obscured. Exporting replicates the tree to the special remote as-is.
+
+Mixing key/value storage and exports in the same remote would be a mess and
+so is not allowed. You have to configure a special remote with
+`exporttree=yes` when initially setting it up with
+[[git-annex-initremote]](1).
+
+The treeish to export can be the name of a git branch, or a tag, or any
+other treeish accepted by git, including eg master:subdir to only export a
+subdirectory from a branch.
+
+When the remote has a preferred content expression set by
+[[git-annex-wanted]](1), the treeish is
+filtered through it, excluding annexed files it does not want from
+being exported to it. (Note that things in the expression like
+"include=" match relative to the top of the treeish being exported.)
+
+Any files in the treeish that are stored on git will also be exported to
+the special remote.
+
+Repeated exports are done efficiently, by diffing the old and new tree,
+and transferring only the changed files, and renaming files as necessary.
+
+Exports can be interrupted and resumed. However, partially uploaded files
+will be re-started from the beginning in most cases.
+
+Once content has been exported to a remote, commands like `git annex get`
+can download content from there the same as from other remotes. However,
+since an export is not a key/value store, git-annex has to do more
+verification of content downloaded from an export. Some types of keys,
+that are not based on checksums, cannot be downloaded from an export.
+And, git-annex will never trust an export to retain the content of a key.
+
+However, some special remotes, notably S3, support keeping track of old
+versions of files stored in them. If a special remote is set up to do 
+that, it can be used as a key/value store and the limitations in the above
+paragraph do not apply. Note that dropping content from such a remote is
+not supported. See individual special remotes' documentation for
+details of how to enable such versioning.
+
+Commands like `git-annex push` can also be used to export a branch to a
+special remote, updating the special remote whenever the branch is changed.
+To do this, you need to configure "remote.<name>.annex-tracking-branch" to
+tell it what branch to track. For example:
+
+	git config remote.myremote.annex-tracking-branch master
+	git annex push myremote
+
+You can combine using `git annex export` to send changes to a special 
+remote with `git annex import` to fetch changes from a special remote.
+When a file on a special remote has been modified by software other than
+git-annex, exporting to it will not overwrite the modified file, and the
+export will not succeed. You can resolve this conflict by using
+`git annex import`.
+
+(Some types of special remotes such as S3 with versioning may instead
+let an export overwrite the modified file; then `git annex import`
+will create a sequence of commits that includes the modified file,
+so the overwritten modification is not lost.)
+
+# OPTIONS
+
+* `--to=remote`
+
+  Specify the special remote to export to.
+
+* `--tracking`
+
+  This is a deprecated way to set "remote.<name>.annex-tracking-branch".
+  Instead of using this option, you should just set the git configuration
+  yourself.
+
+* `--fast`
+
+  This sets up an export of a tree, but avoids any expensive file uploads to
+  the remote. You can later run `git annex push` to upload
+  the files to the export.
+
+* `--jobs=N` `-JN`
+
+  Exports multiple files in parallel. This may be faster.
+  For example: `-J4`  
+
+  Setting this to "cpus" will run one job per CPU core.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-progress`
+
+  Include progress objects in JSON output.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# EXAMPLE
+
+	git annex initremote myremote type=directory directory=/mnt/myremote \
+		exporttree=yes encryption=none
+	git annex export master --to myremote
+
+After that, /mnt/myremote will contain the same tree of files as the master
+branch does.
+
+	git mv myfile subdir/myfile
+	git commit -m renamed
+	git annex export master --to myremote
+
+That updates /mnt/myremote to reflect the renamed file.
+
+	git annex export master:subdir --to myremote
+
+That updates /mnt/myremote, to contain only the files in the "subdir"
+directory of the master branch.
+
+# EXPORT CONFLICTS
+
+If two different git-annex repositories are both exporting different trees
+to the same special remote, it's possible for an export conflict to occur.
+This leaves the special remote with some files from one tree, and some
+files from the other. Files in the special remote may have entirely the
+wrong content as well.
+
+It's not possible for git-annex to detect when making an export will result
+in an export conflict. The best way to avoid export conflicts is to either
+only ever export to a special remote from a single repository, or to have a
+rule about the tree that you export to the special remote. For example, if
+you always export origin/master after pushing to origin, then an export
+conflict can't happen.
+
+An export conflict can only be detected after the two git repositories
+that produced it get back in sync. Then the next time you run `git annex
+export`, it will detect the export conflict, and resolve it.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-initremote]](1)
+
+[[git-annex-import]](1)
+
+[[git-annex-push]](1)
+
+[[git-annex-preferred-content]](1)
+
+# HISTORY
+
+The `export` command was introduced in git-annex version 6.20170925.
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-filter-branch.mdwn b/doc/git-annex-filter-branch.mdwn
new file mode 100644
index 0000000000..df391945b5
--- /dev/null
+++ b/doc/git-annex-filter-branch.mdwn
@@ -0,0 +1,151 @@
+# NAME
+
+git-annex filter-branch - filter information from the git-annex branch
+
+# SYNOPSIS
+
+git annex filter-branch [...]
+
+# DESCRIPTION
+
+This copies selected information from the git-annex branch into a git
+commit object, and outputs its hash. The git commit can be transported
+to another git repository, and given a branch name such as "foo/git-annex",
+and git-annex there will automatically merge that into its git-annex
+branch. This allows publishing some information from your git-annex branch,
+without publishing the whole thing.
+
+Other ways to avoid publishing information from a git-annex branch,
+or remove information from it include [[git-annex-forget]](1), the 
+`annex.private` git config, and the `--private` option to
+[[git-annex-initremote]](1). Those are much easier to use, but this
+provides full control for those who need it.
+
+With no options, no information at all will be included from the git-annex
+branch. Use options to specify what to include. All options can be specified
+multiple times.
+
+When the repository contains information about a private
+repository (due to `annex.private` being set, or `git-annex initremote
+--private` being used), that private information will be included when
+allowed by the options, even though it is not recorded on the git-annex
+branch.
+
+When a repository was created with `git annex initremote --sameas=foo`,
+its information will be included when the information for foo is,
+and excluded when foo is excluded.
+
+When a special remote is configured with importtree=yes or exporttree=yes,
+normally the git tree corresponding to the repository is included in
+the git-annex branch, to make sure it does not get garbage collected
+by `git gc`. Those trees are *not* included when filtering the git-annex
+branch. Usually this will not cause any problems, but if such a tree does
+get garbage collected, it will prevent accessing files on the special
+remote, until the next time a tree is imported or exported to it.
+
+# OPTIONS
+
+* `path`
+
+  Include information about all keys of annexed files in the path.
+
+* file matching options
+
+  The [[git-annex-matching-options]](1)
+  can be used to specify which files in a path to include.
+
+* `--branch=ref`
+
+  Include information about keys referred of annexed files in the branch
+  or treeish.
+
+* `--key=key`
+
+  Include information about a specific key.
+
+* `--all`
+
+  Include information about all keys.
+
+* `--include-key-information-for=repo`
+
+  When including information about a key, include information specific to
+  this repository. The repository can be specified with a uuid or the name
+  of a remote. This option can be used repeatedly to include several
+  repositories.
+
+* `--include-all-key-information`
+
+  Include key information for all repositories, except any excluded with
+  the `--exclude-key-information-for` option.
+
+* `--exclude-key-information-for=repo`
+
+  When including information about a key, exclude information specific to
+  this repository. The repository can be specified with a uuid or the name
+  of a remote. This option can be used repeatedly to exclude
+  several repositories.
+
+* `--include-repo-config-for=repo`
+
+  Include configuration specific to this repository. 
+  The repository can be specified with a uuid or the name of a remote.
+
+  This includes the configuration of special remotes, which may include
+  embedded credentials, or encryption parameters. It also includes trust
+  settings, preferred content, etc. It does not include information
+  about any git-annex keys. This option can be used repeatedly to include
+  several repositories.
+
+* `--include-all-repo-config`
+
+  Include the configuration of all repositories, except for any excluded
+  with the `--exclude-repo-config-for` option.
+
+* `--exclude-repo-config-for=repo`
+
+  Exclude configuration specific to this repository. 
+  The repository can be specified with a uuid or the name of a remote.
+  This option can be used repeatedly to exclude several repositories.
+
+* `--include-global-config`
+
+  Include global configuration, that is not specific to any repository.
+
+  This includes configs stored by [[git-annex-numcopies]](1),
+  [[git-annex-config]](1), etc.
+
+# EXAMPLES
+
+You have a big git-annex repository and are splitting the directory "foo"
+out, to make a smaller repository. You want the smaller repo's git-annex
+branch to contain all the information about remotes and other configuration,
+but only information about keys in that directory.
+
+	git-annex filter-branch foo --include-all-key-information \
+		--include-all-repo-config --include-global-config
+
+That only includes information about the keys that are currently
+in the directory "foo", not keys used by old versions of files.
+To also include information about the version of the subdir in
+tag "1.0", add the option `--branch=1.0:foo`
+
+Your repository has a special remote "bar", and you want to share information
+about which annexed files are stored in it, but without sharing anything
+about the configuration of the remote.
+
+	git-annex filter-branch --all --include-all-key-information \
+		--include-all-repo-config --exclude-repo-config-for=bar \
+		--include-global-config
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-forget]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-filter-process.mdwn b/doc/git-annex-filter-process.mdwn
new file mode 100644
index 0000000000..9056e37e88
--- /dev/null
+++ b/doc/git-annex-filter-process.mdwn
@@ -0,0 +1,52 @@
+# NAME
+
+git-annex filter-process - long running git filter process for git-annex
+
+# SYNOPSIS
+
+git annex filter-process
+
+# DESCRIPTION
+
+When this is not enabled, each file that git wants to filter involves
+starting up a new `git-annex smudge` process. Starting many such processes
+for many files can be slow, and can make commands like `git checkout` and
+`git add` slow when they are operating on a lot of files. (A lot of locked
+annexed files do not make `git checkout` slow, but unlocked files and
+non-annexed files do slow it down.)
+
+On the other hand when this is enabled, `git add` of a large file does an
+unnecessary extra read of the file, and pipes its contents into git-annex.
+So when this is enabled, it will be faster to use `git-annex add` to add
+large files to the annex, rather than `git add`. Other commands that
+add files, like `git commit -a`, are also impacted by this.
+
+This is used by default in git-annex repositories v9 and above, while
+v8 repositories use `git-annex smudge` for backwards compatability with
+older versions of git-annex.
+
+To enable this in a v8 repository, run:
+
+	git config filter.annex.process 'git-annex filter-process'
+
+To disable it, you can just unset the config:
+
+	git config --unset filter.annex.process
+
+There will be no visible difference in behavior between enabling this and
+not, besides changes in speed and memory use when using git.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+[[git-annex-smudge]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-find.mdwn b/doc/git-annex-find.mdwn
new file mode 100644
index 0000000000..d2acbd2d4d
--- /dev/null
+++ b/doc/git-annex-find.mdwn
@@ -0,0 +1,96 @@
+# NAME
+
+git-annex find - lists available files
+
+# SYNOPSIS
+
+git annex find `[path ...]`
+
+# DESCRIPTION
+
+Outputs a list of annexed files in the specified path. With no path,
+finds files in the current directory and its subdirectories.
+
+# OPTIONS
+
+* matching options
+    
+  The [[git-annex-matching-options]](1)
+  can be used to specify files to list.
+
+  By default, the find command only lists annexed files whose content is
+  currently present. Specifying any of the matching options will override
+  this default behavior.
+
+  To list all annexed files, present or not, specify `--anything`.
+
+  To list annexed files whose content is not present, specify `--not --in=here`
+
+* `--branch=ref`
+
+  List files in the specified branch or treeish.
+
+* `--print0`
+
+  Output filenames terminated with nulls, for use with `xargs -0`
+
+* `--format=value`
+
+  Use custom output formatting.
+
+  The value is a format string, in which '${var}' is expanded to the
+  value of a variable. To right-justify a variable with whitespace,
+  use '${var;width}' ; to left-justify a variable, use '${var;-width}';
+  to escape unusual characters (including control characters)
+  in a variable, use '${escaped_var}'
+
+  These variables are available for use in formats: file, key, backend,
+  bytesize, humansize, keyname, hashdirlower, hashdirmixed, mtime (for
+  the mtime field of a WORM key).
+
+  Also, '\\n' is a newline, '\\000' is a NULL, etc.
+
+  The default output format is the same as `--format='${file}\\n'`,
+  except when outputting to a terminal, control characters will be escaped.
+
+* `--json`
+
+  Output the list of files in JSON format.
+
+  This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* `--batch`
+
+  Enables batch mode, in which a file is read in a line from stdin,
+  its information displayed, and repeat.
+
+  Note that if the file is not an annexed file, or is not present,
+  or otherwise doesn't meet the matching options, an empty line
+  will be output instead.
+
+* `-z`
+
+  Makes the `--batch` input be delimited by nulls instead of the usual
+  newlines.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-whereis]](1)
+
+[[git-annex-findkeys]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-find/comment_6_8d931c135df8f9eba201a3dbb94af87e._comment b/doc/git-annex-find/comment_6_8d931c135df8f9eba201a3dbb94af87e._comment
new file mode 100644
index 0000000000..29a5aa9143
--- /dev/null
+++ b/doc/git-annex-find/comment_6_8d931c135df8f9eba201a3dbb94af87e._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="Find (and other operations) over multiple repos"
+ date="2019-02-25T14:33:26Z"
+ content="""
+Sometimes I want to move files from one git annex repo to another. It would be really awesome if one could so something like:
+
+    git annex find --in here --and --not --in-repo /path/to/OTHER-REPO
+
+Just to make myself clear. I do not mean \"other remote\" (foreign instance of \"same\" repo). I actually mean different repos without common location tracking, no common branches, etc. The only concession I would make (since I think it's necessary) would be that the same backend has to be used in both repos.
+
+This approach could also be relevant for other git annex commands, e.g.:
+
+    git annex move file --to-repo /path/to/OTHER-REPO
+
+Is there any way to do it? Or would this be a feature request worth to consider?
+"""]]
diff --git a/doc/git-annex-find/comment_7_b9d4cc7438ce5dbe22b62e9decc6cbee._comment b/doc/git-annex-find/comment_7_b9d4cc7438ce5dbe22b62e9decc6cbee._comment
new file mode 100644
index 0000000000..f09eecf551
--- /dev/null
+++ b/doc/git-annex-find/comment_7_b9d4cc7438ce5dbe22b62e9decc6cbee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="find wanted on remote?"
+ date="2020-04-16T21:19:44Z"
+ content="""
+Is there a way to use find to figure out what is wanted (for getting or dropping) on a given remote? I want to be able to do this to anticipate the outbound consequences of a sync (I can anticipate the inbound consequences of a sync, modulo file availability on remotes, using `git annex find --wanted-get --not --in here`). 
+
+I could manually figure out the wanted expressions for an arbitrary remote (resolving any group assignments, etc) and then use that expression, but it'd be nice to be able to do something like `git annex find --wanted-get-at remotename --not --in remotename --in here` to figure out what things will get copied *to* the remote if I run `git annex sync --content`. I presume this logic is implemented somewhere since it gets used when doing `git annex sync --content`, and perhaps there's a way that I can do it using `git annex find` or other commands and I'm just not seeing how to do it.
+"""]]
diff --git a/doc/git-annex-find/comment_8_d5846a41e2e227569d7d90dbb8edf7d8._comment b/doc/git-annex-find/comment_8_d5846a41e2e227569d7d90dbb8edf7d8._comment
new file mode 100644
index 0000000000..c603f29f2e
--- /dev/null
+++ b/doc/git-annex-find/comment_8_d5846a41e2e227569d7d90dbb8edf7d8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="&quot;dry run&quot; option"
+ date="2020-04-21T19:04:07Z"
+ content="""
+@Dan Related: [[todo/wishlist: --dry-run_option_for_all_commands/]] (but should probably move this thread to [[todo]]).
+"""]]
diff --git a/doc/git-annex-findkeys.mdwn b/doc/git-annex-findkeys.mdwn
new file mode 100644
index 0000000000..6be8a816bf
--- /dev/null
+++ b/doc/git-annex-findkeys.mdwn
@@ -0,0 +1,75 @@
+# NAME
+
+git-annex findkeys - lists available keys
+
+# SYNOPSIS
+
+git annex findkeys
+
+# DESCRIPTION
+
+Outputs a list of keys known to git-annex.
+
+# OPTIONS
+
+* matching options
+    
+  The [[git-annex-matching-options]](1)
+  can be used to specify which keys to list.
+
+  By default, the findkeys command only lists keys whose content is
+  currently present. Specifying any of the matching options will override
+  this default behavior and match on all keys that git-annex knows about.
+
+  To list all keys, present or not, specify `--anything`.
+
+  To list keys whose content is not present, specify `--not --in=here`
+
+* `--print0`
+
+  Output keys terminated with nulls, for use with `xargs -0`
+
+* `--format=value`
+
+  Use custom output formatting.
+
+  The value is a format string, in which '${var}' is expanded to the
+  value of a variable. To right-justify a variable with whitespace,
+  use '${var;width}' ; to left-justify a variable, use '${var;-width}';
+  to escape unusual characters (including control characters)
+  in a variable, use '${escaped_var}'
+
+  These variables are available for use in formats: key, backend,
+  bytesize, humansize, keyname, hashdirlower, hashdirmixed, mtime (for
+  the mtime field of a WORM key).
+
+  Also, '\\n' is a newline, '\\000' is a NULL, etc.
+
+  The default output format is the same as `--format='${escapedkey}\\n'`
+  except when outputting to a terminal, control characters will be escaped.
+
+* `--json`
+
+  Output the list of keys in JSON format.
+
+  This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-find]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-findref.mdwn b/doc/git-annex-findref.mdwn
new file mode 100644
index 0000000000..6406e404bb
--- /dev/null
+++ b/doc/git-annex-findref.mdwn
@@ -0,0 +1,27 @@
+# NAME
+
+git-annex findref - lists files in a git ref (deprecated)
+
+# SYNOPSIS
+
+git annex findref `[ref]`
+
+# DESCRIPTION
+
+This is the same as `git annex find` with the --branch option, and you're
+encouraged to use that instead unless you need to support older versions of
+git-annex.
+
+# OPTIONS
+
+Same as [[git-annex-find]](1)
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-fix.mdwn b/doc/git-annex-fix.mdwn
new file mode 100644
index 0000000000..5a670cd1a0
--- /dev/null
+++ b/doc/git-annex-fix.mdwn
@@ -0,0 +1,49 @@
+# NAME
+
+git-annex fix - fix up links to annexed content
+
+# SYNOPSIS
+
+git annex fix `[path ...]`
+
+# DESCRIPTION
+
+Fixes up symlinks that have become broken to again point to annexed
+content.
+
+This is useful to run manually when you have been moving the symlinks
+around, but is done automatically when committing a change with git too.
+
+Also, adjusts unlocked files to be copies or hard links as
+configured by annex.thin.
+
+# OPTIONS
+
+* file matching options
+  
+  The [[git-annex-matching-options]](1)
+  can be used to specify files to fix.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-fsck]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-forget.mdwn b/doc/git-annex-forget.mdwn
new file mode 100644
index 0000000000..b216c32cc1
--- /dev/null
+++ b/doc/git-annex-forget.mdwn
@@ -0,0 +1,43 @@
+# NAME
+
+git-annex forget - prune git-annex branch history
+
+# SYNOPSIS
+
+git annex forget
+
+# DESCRIPTION
+
+Causes the git-annex branch to be rewritten, throwing away historical
+data about past locations of files. The resulting branch will use less
+space, but `git annex log` will not be able to show where
+files used to be located.
+
+When this rewritten branch is merged into other clones of
+the repository, `git-annex` will automatically perform the same rewriting
+to their local `git-annex` branches. So the forgetfulness will automatically
+propagate out from its starting point until all repositories running
+git-annex have forgotten their old history. (You may need to force
+git to push the branch to any git repositories not running git-annex.)
+
+# OPTIONS
+
+* `--drop-dead`
+
+  Also prune references to repositories that have been marked as dead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-dead]](1)
+
+[[git-annex-filter-branch]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-fromkey.mdwn b/doc/git-annex-fromkey.mdwn
new file mode 100644
index 0000000000..ce7f486307
--- /dev/null
+++ b/doc/git-annex-fromkey.mdwn
@@ -0,0 +1,60 @@
+# NAME
+
+git-annex fromkey - adds a file using a specific key
+
+# SYNOPSIS
+
+git annex fromkey `[key file ...]`
+
+# DESCRIPTION
+
+This plumbing-level command can be used to manually set up a file
+in the git repository to link to a specified key.
+
+Multiple pairs of file and key can be given in a single command line.
+
+If no key and file pair are specified on the command line, batch input
+is used, the same as if the --batch option were specified.
+
+Normally the key is a git-annex formatted key. However, to make it easier
+to use this to add urls, if the key cannot be parsed as a key, and is a
+valid url, an URL key is constructed from the url. Note that this does not
+register the url as a location of the key; use [[git-annex-registerurl]](1)
+to do that.
+
+# OPTIONS
+
+* `--force`
+
+  Allow making a file link to a key whose content is not in the local
+  repository. The key may not be known to git-annex at all.
+
+* `--batch`
+
+  In batch input mode, lines are read from stdin, and each line
+  should contain a key and filename, separated by a single space.
+
+* `-z`
+
+  When in batch mode, the input is delimited by nulls instead of the usual
+  newlines.
+
+  (Note that for this to be used, you have to explicitly enable batch mode
+  with `--batch`)
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-fsck.mdwn b/doc/git-annex-fsck.mdwn
new file mode 100644
index 0000000000..4083ba4bf1
--- /dev/null
+++ b/doc/git-annex-fsck.mdwn
@@ -0,0 +1,134 @@
+# NAME
+
+git-annex fsck - find and fix problems
+
+# SYNOPSIS
+
+git annex fsck `[path ...]`
+
+# DESCRIPTION
+
+This command checks annexed files for consistency, and warns about or
+fixes any problems found. This is a good complement to `git fsck`.
+
+The default is to check all annexed files in the current directory and
+subdirectories. With parameters, only the specified files are checked.
+
+The problems fsck finds include files that have gotten corrupted,
+files whose content has somehow become lost, files that do not have the
+configured number of copies yet made, and keys that can be upgraded to a
+better format.
+
+# OPTIONS
+
+* `--from=remote`
+
+  Check a remote, rather than the local repository.
+
+  Note that by default, files will be copied from the remote to check
+  their contents. To avoid this expensive transfer, and only
+  verify that the remote still has the files that are expected to be on it,
+  add the `--fast` option.
+
+* `--fast`
+
+  Avoids expensive checksum calculations (and expensive transfers when
+  fscking a remote).
+
+* `--incremental`
+
+  Start a new incremental fsck pass. An incremental fsck can be interrupted
+  at any time, with eg ctrl-c.
+
+* `--more`
+
+  Resume the last incremental fsck pass, where it left off.
+
+  Resuming may redundantly check some files that were checked
+  before. Any files that fsck found problems with before will be re-checked
+  on resume. Also, checkpoints are made every 1000 files or every 5 minutes
+  during a fsck, and it resumes from the last checkpoint.
+
+* `--incremental-schedule=time`
+
+  This makes a new incremental fsck be started only a specified
+  time period after the last incremental fsck was started.
+
+  The time is in the form "10d" or "300h".
+
+  Maybe you'd like to run a fsck for 5 hours at night, picking up each
+  night where it left off. You'd like this to continue until all files
+  have been fscked. And once it's done, you'd like a new fsck pass to start,
+  but no more often than once a month. Then put this in a nightly cron job:
+
+	git annex fsck --incremental-schedule 30d --time-limit 5h
+
+* `--numcopies=N`
+
+  Override the normally configured number of copies. 
+
+  To verify data integrity only while disregarding required number of copies,
+  use `--numcopies=1`.
+
+* `--all` `-A`
+
+  Normally only the files in the currently checked out branch
+  are fscked. This option causes all versions of all files to be fscked.
+
+  This is the default behavior when running git-annex in a bare repository.
+
+* `--branch=ref`
+
+  Operate on files in the specified branch or treeish.
+
+* `--unused`
+
+  Operate on files found by last run of git-annex unused.
+
+* `--key=keyname`
+
+  Use this option to fsck a specified key.
+  
+* matching options
+
+  The [[git-annex-matching-options]](1)
+  can be used to control what to fsck.
+
+* `--jobs=N` `-JN`
+
+  Runs multiple fsck jobs in parallel. For example: `-J4`
+
+  Setting this to "cpus" will run one job per CPU core.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* `--quiet`
+
+  Like all git-annex commands, this option makes only error and warning
+  messages be displayed. This is particularly useful with fsck, which
+  normally displays all the files it's checking even when there is no
+  problem with them.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-repair]](1)
+
+[[git-annex-expire]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-fuzztest.mdwn b/doc/git-annex-fuzztest.mdwn
new file mode 100644
index 0000000000..d678561baa
--- /dev/null
+++ b/doc/git-annex-fuzztest.mdwn
@@ -0,0 +1,27 @@
+# NAME
+
+git-annex fuzztest - generates fuzz test files
+
+# SYNOPSIS
+
+git annex fuzztest
+
+# DESCRIPTION
+
+Generates random changes to files in the current repository,
+for use in testing the assistant. This is dangerous, so it will not
+do anything unless --forced.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-get.mdwn b/doc/git-annex-get.mdwn
new file mode 100644
index 0000000000..208188171f
--- /dev/null
+++ b/doc/git-annex-get.mdwn
@@ -0,0 +1,156 @@
+# NAME
+
+git-annex get - make content of annexed files available
+
+# SYNOPSIS
+
+git annex get `[path ...]`
+
+# DESCRIPTION
+
+Makes the content of annexed files available in this repository. This
+will involve copying them from a remote repository, or downloading them,
+or transferring them from some kind of key-value store.
+
+With no parameters, gets all annexed files in the current directory whose
+content was not already present. Paths of files or directories to get can
+be specified.
+
+# EXAMPLES
+
+	# evince foo.pdf
+	error: Unable to open document foo.pdf: No such file or directory
+	# ls foo.pdf
+	foo.pdf@
+	# git annex get foo.pdf
+	get foo.pdf (from origin..) ok
+	# evince foo.pdf
+
+# OPTIONS
+
+* `--auto`
+
+  Rather than getting all the specified files, get only those that don't yet
+  have the desired number of copies, or that are preferred content of the
+  repository. See [[git-annex-preferred-content]](1)
+
+* `--from=remote`
+
+  Normally git-annex will choose which remotes to get the content
+  from, preferring remotes with lower costs. Use this option to specify
+  which remote to use. 
+  
+  Any files that are not available on the remote will be silently skipped.
+
+* `--jobs=N` `-JN`
+
+  Enables parallel download with up to the specified number of jobs
+  running at once. For example: `-J10`
+
+  Setting this to "cpus" will run one job per CPU core.
+
+  When files can be downloaded from multiple remotes, enabling parallel
+  downloads will split the load between the remotes. For example, if
+  the files are available on remotes A and B, then one file will be
+  downloaded from A, and another file will be downloaded from B in
+  parallel. (Remotes with lower costs are still preferred over higher cost
+  remotes.)
+
+* matching options
+ 
+  The [[git-annex-matching-options]](1)
+  can be used to control what to get.
+
+* `--incomplete`
+
+  Resume any incomplete downloads of files that were started and
+  interrupted at some point previously. Useful to pick up where you left
+  off ... when you don't quite remember where that was.
+
+  These incomplete files are the same ones that are
+  listed as unused temp files by [[git-annex-unused]](1).
+
+  Note that the git-annex key will be displayed when downloading,
+  as git-annex does not know the associated file, and the associated file
+  may not even be in the current git working directory.
+
+* `--all` `-A`
+
+  Rather than specifying a filename or path to get, this option can be
+  used to get all available versions of all files.
+
+  This is the default behavior when running git-annex in a bare repository.
+
+* `--branch=ref`
+
+  Operate on files in the specified branch or treeish.
+
+* `--unused`
+
+  Operate on files found by last run of git-annex unused.
+
+* `--failed`
+
+  Operate on files that have recently failed to be transferred.
+
+  Not to be confused with `--incomplete` which resumes only downloads
+  that managed to transfer part of the content of a file.
+
+* `--key=keyname`
+
+  Use this option to get a specified key.
+
+* `--batch`
+
+  Enables batch mode, in which lines containing names of files to get
+  are read from stdin.
+
+  As each specified file is processed, the usual progress output is
+  displayed. If the specified file's content is already present, 
+  or it does not match specified matching options, or
+  it is not an annexed file, a blank line is output in response instead.
+
+  Since the usual output while getting a file is verbose and not
+  machine-parseable, you may want to use --json in combination with
+  --batch.
+
+* `--batch-keys`
+
+  This is like `--batch` but the lines read from stdin are parsed as keys.
+
+* `-z`
+
+  Makes batch input be delimited by nulls instead of the usual
+  newlines.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-progress`
+
+  Include progress objects in JSON output.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-drop]](1)
+
+[[git-annex-copy]](1)
+
+[[git-annex-move]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-get/comment_1_9914f6f6c99757927eed9b5d0217908e._comment b/doc/git-annex-get/comment_1_9914f6f6c99757927eed9b5d0217908e._comment
new file mode 100644
index 0000000000..762626b1ae
--- /dev/null
+++ b/doc/git-annex-get/comment_1_9914f6f6c99757927eed9b5d0217908e._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="matrss"
+ avatar="http://cdn.libravatar.org/avatar/59541f50d845e5f81aff06e88a38b9de"
+ subject="get file by branch and path in bare repository"
+ date="2023-09-08T15:47:16Z"
+ content="""
+Hey!
+
+Is there any way to `git annex get` a file in a specific branch when I have a bare repository?
+
+Since `git show <branch name>:<path in branch>` works I tried that notation in `get`, but that is not recognized.
+
+It is also not possible to combine `--branch` with a path as far as I can tell.
+
+My next idea was to figure out the key of the file first and then get that, but `git annex lookupkey` does not work in a bare repository either.
+
+I could parse the key from the output of `git show`, but then I would need to deal with git-annex internals like if it is a symlink or a pointer file, which feels a bit wrong.
+But since that would be possible I don't see a reason why e.g. lookupkey does not work. Is there any way to achieve this?
+"""]]
diff --git a/doc/git-annex-get/comment_2_ce5c85afa01019afe58c79df151c65ff._comment b/doc/git-annex-get/comment_2_ce5c85afa01019afe58c79df151c65ff._comment
new file mode 100644
index 0000000000..8da5e9912a
--- /dev/null
+++ b/doc/git-annex-get/comment_2_ce5c85afa01019afe58c79df151c65ff._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: get file by branch and path in bare repository"""
+ date="2023-09-12T16:46:55Z"
+ content="""
+--branch is limited to a treeish, so not a single file.
+
+You can use `git-annex lookupkey --ref` to look up the key used by a ref to
+a file, and then pass that to `git-annex get --key`
+
+(That's a new feature I added due to you asking this question.)
+"""]]
diff --git a/doc/git-annex-group.mdwn b/doc/git-annex-group.mdwn
new file mode 100644
index 0000000000..afe5aee47f
--- /dev/null
+++ b/doc/git-annex-group.mdwn
@@ -0,0 +1,39 @@
+# NAME
+
+git-annex group - add a repository to a group
+
+# SYNOPSIS
+
+git annex group `repository [groupname]`
+
+# DESCRIPTION
+
+Adds a repository to a group, such as "archival", "enduser", or "transfer".
+The groupname must be a single word.
+  
+Omit the groupname to show the current groups that a repository is in.
+
+There are some standard groups that have different default preferred content
+settings. See <https://git-annex.branchable.com/preferred_content/standard_groups/>
+
+A repository can be in multiple groups at the same time.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-ungroup]](1)
+
+[[git-annex-preferred-content]](1)
+
+[[git-annex-wanted]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-groupwanted.mdwn b/doc/git-annex-groupwanted.mdwn
new file mode 100644
index 0000000000..249f82fb11
--- /dev/null
+++ b/doc/git-annex-groupwanted.mdwn
@@ -0,0 +1,46 @@
+# NAME
+
+git-annex groupwanted - get or set groupwanted expression
+
+# SYNOPSIS
+
+git annex groupwanted `groupname [expression]`
+
+# DESCRIPTION
+
+Sets or displays the groupwanted expression. This will be used by
+repositories that are in the group, and that have their preferred
+content expression set to "groupwanted".
+  
+For example, to configure a group named redundantarchive, and
+make repositories in the group want to contain 3 copies of every file:
+  
+	git annex groupwanted redundantarchive "not (copies=redundantarchive:3)"
+	for repo in foo bar baz; do
+		git annex group $repo redundantarchive
+		git annex wanted $repo groupwanted
+	done
+
+Note that there must be exactly one groupwanted expression configured
+amoung all the groups that a repository is in; if there's more than one,
+none of them will be used.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-group]](1)
+
+[[git-annex-wanted]](1)
+
+[[git-annex-preferred-content]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-import.mdwn b/doc/git-annex-import.mdwn
new file mode 100644
index 0000000000..e78fa0ac14
--- /dev/null
+++ b/doc/git-annex-import.mdwn
@@ -0,0 +1,250 @@
+# NAME
+
+git-annex import - import files from a special remote
+
+# SYNOPSIS
+
+git annex import --from remote branch[:subdir] | `[path ...]`
+
+# DESCRIPTION
+
+This command is a way to import a tree of files from elsewhere into your
+git-annex repository. It can import files from a git-annex special remote,
+or from a directory.
+
+# IMPORTING FROM A SPECIAL REMOTE
+
+Importing from a special remote first downloads or hashes all new content
+from it, and then constructs a git commit that reflects files that have
+changed on the special remote since the last time git-annex looked at it.
+Merging that commit into your repository will update it to reflect changes
+made on the special remote.
+
+This way, something can be using the special remote for file storage,
+adding files, modifying files, and deleting files, and you can track those
+changes using git-annex.
+
+You can combine using `git annex import` to fetch changes from a special 
+remote with `git annex export` to send your local changes to the special
+remote.
+
+You can only import from special remotes that were configured with
+`importtree=yes` when set up with [[git-annex-initremote]](1). Only some
+kinds of special remotes will let you configure them this way. A perhaps
+non-exhaustive list is the directory, s3, and adb special remotes.
+
+To import from a special remote, you must specify the name of a branch.
+A corresponding remote tracking branch will be updated by `git annex import`.
+After that point, it's the same as if you had run a `git fetch`
+from a regular git remote; you can merge the changes into your
+currently checked out branch.
+
+For example:
+
+	git annex import master --from myremote
+	git annex merge --allow-unrelated-histories myremote/master
+
+You could just as well use `git merge --allow-unrelated-histories myremote/master`
+as the second step, but using `git-annex merge` avoids a couple of gotchas.
+When using adjusted branches, it adjusts the branch before merging from it.
+
+The --allow-unrelated-histories option is needed for at least the first
+merge of an imported remote tracking branch, since the branch's history is
+not connected. Think of this as the remote being a separate git repository
+with its own files. If you first `git annex export` files to a remote, and
+then `git annex import` from it, you won't need that option.
+
+You can import into a subdirectory, using the "branch:subdir" syntax. For
+example, if "camera" is a special remote that accesses a camera, and you
+want to import those into the photos directory, rather than to the root of
+your repository:
+
+	git annex import master:photos --from camera
+	git merge camera/master
+
+The `git annex sync --content` command (and the git-annex assistant)
+can also be used to import from a special remote.
+To do this, you need to configure "remote.<name>.annex-tracking-branch"
+to tell it what branch to track. For example:
+
+	git config remote.myremote.annex-tracking-branch master
+	git annex sync --content
+
+Any files that are gitignored will not be included in the import,
+but will be left on the remote.
+
+When the special remote has a preferred content expression set by
+[[git-annex-wanted]](1), that is used to pick which files to import from
+it. Files that are not preferred content of the remote will not be
+imported from it, but will be left on the remote.
+
+So for example, a preferred content expression like 
+`"include=*.jpeg or largerthan=100mb"` will make only jpegs and 
+large files be imported.
+
+Parts of a preferred content expression that relate to the key,
+such as "copies=" are ignored when importing, because the key
+is not known before importing.
+
+Things in the expression like "include=" match relative to the top of
+the tree of files on the remote, even when importing into a subdirectory.
+
+# OPTIONS FOR IMPORTING FROM A SPECIAL REMOTE
+
+* `--content`, `--no-content`
+
+  Controls whether annexed content is downloaded from the special remote.
+
+  The default is to download content into the git-annex repository.
+
+  With --no-content, git-annex keys are generated from information
+  provided by the special remote, without downloading it. Commands like
+  `git-annex get` can later be used to download files, as desired.
+  The --no-content option is not supported by all special remotes.
+
+* `--message=msg` `-m msg`
+
+  Use this option to specify a commit message for the changes that have
+  been made to the special remote since the last import from it.
+
+  If multiple -m options are given, their values are concatenated
+  as separate paragraphs.
+
+# IMPORTING FROM A DIRECTORY
+
+When run with a path, `git annex import` **moves** files from somewhere outside
+the git working copy, and adds them to the annex. In contrast to importing 
+from a special directory remote, imported files are **deleted from the given
+path**.
+
+This is a legacy interface. It is still supported, but please consider
+switching to importing from a directory special remote instead, using the
+interface documented above.
+
+Individual files to import can be specified. If a directory is specified,
+the entire directory is imported. Please note that the following instruction
+will **delete all files from the source directory**.   
+  
+        	git annex import /media/camera/DCIM/*
+
+When importing files, there's a possibility of importing a duplicate
+of a file that is already known to git-annex -- its content is either
+present in the local repository already, or git-annex knows of another
+repository that contains it, or it was present in the annex before but has
+been removed now.
+
+By default, importing a duplicate of a known file will result in
+a new filename being added to the repository, so the duplicate file
+is present in the repository twice. (With all checksumming backends,
+including the default SHA256E, only one copy of the data will be stored.)
+
+Several options can be used to adjust handling of duplicate files, see
+`--duplicate`, `--deduplicate`, `--skip-duplicates`, `--clean-duplicates`,
+and `--reinject-duplicates` documentation below.
+
+symbolic links in the directory being imported are skipped to avoid
+accidentially importing things outside the directory that import was ran
+on. The directory that import is run on can, however inself be a symbolic
+link, and that symbolic link will be followed.
+
+# OPTIONS FOR IMPORTING FROM A DIRECTORY
+
+* `--duplicate`
+
+  Do not delete files from the import location.
+
+  Running with this option repeatedly can import the same files into
+  different git repositories, or branches, or different locations in a git
+  repository.
+
+* `--deduplicate`
+
+  Only import files that are not duplicates;
+  duplicate files will be deleted from the import location.
+
+* `--skip-duplicates`
+
+  Only import files that are not duplicates. Avoids deleting any
+  files from the import location.
+
+* `--clean-duplicates`
+
+  Does not import any files, but any files found in the import location
+  that are duplicates are deleted.
+
+* `--reinject-duplicates`
+
+  Imports files that are not duplicates. Files that are duplicates have
+  their content reinjected into the annex (similar to
+  [[git-annex-reinject]](1)).
+
+* `--force`
+
+  Allow existing files to be overwritten by newly imported files.
+
+  Also, causes .gitignore to not take effect when adding files.
+
+* file matching options
+
+  Many of the [[git-annex-matching-options]](1)
+  can be used to specify files to import.
+
+		git annex import /dir --include='*.png'
+
+# COMMON OPTIONS
+
+* `--jobs=N` `-JN`
+
+  Imports multiple files in parallel. This may be faster.
+  For example: `-J4`  
+
+  Setting this to "cpus" will run one job per CPU core.
+
+* `--backend`
+
+  Specifies which key-value backend to use for the imported files.
+
+* `--no-check-gitignore`
+
+  Add gitignored files.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-progress`
+
+  Include progress objects in JSON output.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# CAVEATS
+
+Note that using `--deduplicate` or `--clean-duplicates` with the WORM
+backend does not look at file content, but filename and mtime.
+
+If annex.largefiles is configured, and does not match a file, `git annex
+import` will add the non-large file directly to the git repository,
+instead of to the annex.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-add]](1)
+
+[[git-annex-export]](1)
+
+[[git-annex-preferred-content]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-import/comment_1_8961635a772b4ddb5ba1e04a50034e6a._comment b/doc/git-annex-import/comment_1_8961635a772b4ddb5ba1e04a50034e6a._comment
new file mode 100644
index 0000000000..4dbdc45cd3
--- /dev/null
+++ b/doc/git-annex-import/comment_1_8961635a772b4ddb5ba1e04a50034e6a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="georg.schnabel@bd6be2144f897f5caa0028e0dd1e0a65634add81"
+ nickname="georg.schnabel"
+ avatar="http://cdn.libravatar.org/avatar/b58e4e0101a95b57d55da575ca21f510"
+ subject="import from special directory remote fails due to running out of memory "
+ date="2021-02-17T14:29:49Z"
+ content="""
+First of all, git annex is an awesome tool, I like it very much!
+
+When trying to `git annex import` from a special directory remote with a large number of files (~4 millions) with a cumulative size of about 1TB, git annex takes up all main memory during the final update remote/ref step on a machine with 16G of main memory and is then killed by the system. This also happens when supplying the `--no-content` option. Is there a way to make git annex less memory demanding when importing from a special directory remote with a large number of files?
+"""]]
diff --git a/doc/git-annex-import/comment_2_e62b59d5c9cee04a77c51799624a3357._comment b/doc/git-annex-import/comment_2_e62b59d5c9cee04a77c51799624a3357._comment
new file mode 100644
index 0000000000..7eade46253
--- /dev/null
+++ b/doc/git-annex-import/comment_2_e62b59d5c9cee04a77c51799624a3357._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 2"
+ date="2021-02-19T07:16:25Z"
+ content="""
+Yes, just `cp` or `mv` the files inside the repo and `git annex add` them as usual.
+"""]]
diff --git a/doc/git-annex-import/comment_3_3891ccc35010e1e5c328a9aa6b9e596b._comment b/doc/git-annex-import/comment_3_3891ccc35010e1e5c328a9aa6b9e596b._comment
new file mode 100644
index 0000000000..27d00aad5c
--- /dev/null
+++ b/doc/git-annex-import/comment_3_3891ccc35010e1e5c328a9aa6b9e596b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: import from special directory remote fails due to running out of memory"""
+ date="2021-02-22T16:13:32Z"
+ content="""
+Importing from special remotes necessarily needs to hold the list of files
+in memory, or at least it seems like it would be hard to get it to stream
+over them. So there may be some way to decrease the memory use per file
+(currently 4.2 kb per file according to your numbers), possibly by around
+50%, but it would still scale with the number of files. The whole import
+interface would need to change to use trees to avoid that.
+It would be ok to file a bug report about this.
+
+The legacy directory import interface avoids such problems.
+"""]]
diff --git a/doc/git-annex-importfeed.mdwn b/doc/git-annex-importfeed.mdwn
new file mode 100644
index 0000000000..6a763e0380
--- /dev/null
+++ b/doc/git-annex-importfeed.mdwn
@@ -0,0 +1,147 @@
+# NAME
+
+git-annex importfeed - import files from podcast feeds
+
+# SYNOPSIS
+
+git annex importfeed `[url ...]`
+
+# DESCRIPTION
+
+Imports the contents of podcasts and other rss and atom feeds. Only
+downloads files whose content has not already been added to the repository
+before, so you can delete, rename, etc the resulting files and repeated
+runs won't duplicate them.
+
+When `yt-dlp` is installed, it can be used to download links in the feed.
+This allows importing e.g., YouTube playlists.
+(However, this is disabled by default as it can be a security risk. 
+See the documentation of annex.security.allowed-ip-addresses
+in [[git-annex]](1) for details.)
+
+To make the import process add metadata to the imported files from the feed,
+`git config annex.genmetadata true`
+
+By default, the downloaded files are put in a directory with the title
+of the feed, and files are named based on the title of the item in the
+feed. This can be changed using the --template option.
+
+Existing files are not overwritten by this command. If "some feed/foo.mp3"
+already exists, it will instead write to "some feed/2\_foo.mp3"
+(or 3, 4, etc). Sometimes a feed will change an item's url,
+resulting in the new url being downloaded to such a filename.
+
+# OPTIONS
+
+* `--force`
+
+  Force downloading items it's seen before.
+
+* `--fast`, `--relaxed`, `--verifiable`, `--raw`, `--raw-except`
+
+  These options behave the same as when using [[git-annex-addurl]](1).
+
+* `--fast`
+
+  Avoid immediately downloading urls. The url is still checked
+  (via HEAD) to verify that it exists, and to get its size if possible.
+
+* `--relaxed`
+
+  Don't immediately download urls, and avoid storing the size of the
+  url's content. This makes git-annex accept whatever content is there
+  at a future point.
+
+* `--raw`
+
+  Prevent special handling of urls by yt-dlp, bittorrent, and other
+  special remotes. This will for example, make importfeed
+  download a .torrent file and not the contents it points to.
+
+* `--no-raw`
+
+  Require content pointed to by the url to be downloaded using yt-dlp
+  or a special remote, rather than the raw content of the url. if that
+  cannot be done, the import will fail, and the next import of the feed
+  will retry.
+
+* `--scrape`
+
+  Rather than downloading the url and parsing it as a rss/atom feed
+  to find files to import, uses yt-dlp to screen scrape the equivilant
+  of a feed, and imports what it found.
+
+* `--template`
+
+  Controls where the files are stored.
+
+  The default template is '${feedtitle}/${itemtitle}${extension}'
+  
+  The available variables in the template include these that
+  are information about the feed: feedtitle, feedauthor, feedurl
+
+  And these that are information about individual items in the feed:
+  itemtitle, itemauthor, itemsummary, itemdescription, itemrights,
+  itemid.
+
+  Also, title is itemtitle but falls back to feedtitle if the item has no
+  title, and author is itemauthor but falls back to feedauthor.
+
+  (All of the above are also added as metadata when annex.genmetadata is
+  set.)
+
+  The extension variable is the extension of the file in the feed,
+  or sometimes ".m" if no extension can be determined.
+
+  The template also has some variables for when an item was published.
+  
+  itempubyear (YYYY), itempubmonth (MM), itempubday (DD), itempubhour (HH),
+  itempubminute (MM), itempubsecond (SS),
+  itempubdate (YYYY-MM-DD or if the feed's date cannot be parsed, the raw
+  value from the feed).
+  
+  (These use the UTC time zone, not the local time zone.)
+
+* `--no-check-gitignore`
+
+  By default, gitignores are honored and it will refuse to download an
+  url to a file that would be ignored. This makes such files be added
+  despite any ignores.
+
+* `--jobs=N` `-JN`
+
+  Runs multiple downloads parallel. For example: `-J4`  
+
+  Setting this to "cpus" will run one job per CPU core.
+
+* `--backend`
+
+  Specifies which key-value backend to use.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-progress`
+
+  Include progress objects in JSON output.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-addurl]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-importfeed/comment_1_d0197108d07873040e46577df1faadbd._comment b/doc/git-annex-importfeed/comment_1_d0197108d07873040e46577df1faadbd._comment
new file mode 100644
index 0000000000..0d97406d98
--- /dev/null
+++ b/doc/git-annex-importfeed/comment_1_d0197108d07873040e46577df1faadbd._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joseph.rawson.works@85a210ab8c0e37a0b2d6bb235738b20e23e8878f"
+ nickname="joseph.rawson.works"
+ subject="Replacing dashes with underscores"
+ date="2015-12-28T22:39:49Z"
+ content="""
+An example rss item entry:
+
+    <item><title>00135929509939-04</title><guid isPermaLink=\"false\">http://40.media.tumblr.com/01a46c39dc0e0f3447fbed4f0807047f/tumblr_nyoj75VlaG1sgxjc6o3_1280.jpg</guid><enclosure url=\"http://40.media.tumblr.com/01a46c39dc0e0f3447fbed4f0807047f/tumblr_nyoj75VlaG1sgxjc6o3_1280.jpg\" length=\"0\" type=\"\"/></item>
+
+Using --template '${itemtitle}${extension}'
+
+The resulting filename is **00135929509939_04.jpg** (The dash was replaced with an underscore).
+
+I decided to just change all the filenames in each blog repository to use underscores, however, I thought you might want to know about this.
+"""]]
diff --git a/doc/git-annex-importfeed/comment_2_25d4ed016e98609066597a8d2b956f87._comment b/doc/git-annex-importfeed/comment_2_25d4ed016e98609066597a8d2b956f87._comment
new file mode 100644
index 0000000000..206dab711d
--- /dev/null
+++ b/doc/git-annex-importfeed/comment_2_25d4ed016e98609066597a8d2b956f87._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-01-01T20:04:02Z"
+ content="""
+All spaces and punctuation (other than '.') and other wacky stuff are replaced with
+'_' when git-annex builds a filename from some untrusted source like a
+feed.
+
+I think it makes sense to do that even for '-', at least if it's at the
+start of a filename. "--force" is not a filename you want to let a feed
+inject into your work tree. I could perhaps be convinced to let '-'
+elsewhere in the filename through unmunged, but simplicity and consistency
+suggests it's just as good to always munge it.
+"""]]
diff --git a/doc/git-annex-importfeed/comment_3_bce2b233e4d42fc87a2e17d51e2c2606._comment b/doc/git-annex-importfeed/comment_3_bce2b233e4d42fc87a2e17d51e2c2606._comment
new file mode 100644
index 0000000000..25f0ed7938
--- /dev/null
+++ b/doc/git-annex-importfeed/comment_3_bce2b233e4d42fc87a2e17d51e2c2606._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="umeboshi"
+ subject="comment 3"
+ date="2016-01-02T21:02:51Z"
+ content="""
+I just thought it was surprising behavior, especially when ```git-annex addurl --file 123-45.ext $url``` preserves the dash in the filename, yet the rss I constructed to add multiple urls, with files, didn't do this.
+
+The new ```--batch --with-files``` options to addurl will eliminate the need to create specially crafted rss files.
+
+Thanks! :)
+"""]]
diff --git a/doc/git-annex-indirect.mdwn b/doc/git-annex-indirect.mdwn
new file mode 100644
index 0000000000..4d35afa1b5
--- /dev/null
+++ b/doc/git-annex-indirect.mdwn
@@ -0,0 +1,27 @@
+# NAME
+
+git-annex indirect - switch repository to indirect mode (deprecated)
+
+# SYNOPSIS
+
+git annex indirect
+
+# DESCRIPTION
+
+This command was used to switch a repository back from direct mode
+indirect mode.
+
+Now git-annex automatically converts direct mode repositories to v7
+with adjusted unlocked branches, so this command does nothing.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-direct]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-info.mdwn b/doc/git-annex-info.mdwn
new file mode 100644
index 0000000000..9b0e9715df
--- /dev/null
+++ b/doc/git-annex-info.mdwn
@@ -0,0 +1,99 @@
+# NAME
+
+git-annex info - information about an item or the repository
+
+# SYNOPSIS
+
+git annex info `[directory|file|treeish|remote|description|uuid ...]`
+
+# DESCRIPTION
+
+Displays statistics and other information for the specified item.
+
+When no item is specified, displays overall information. This includes a
+list of all known repositories, how much annexed data is present in the
+local repository, the total size of all annexed data in the working
+tree, the combined size of annexed data in all repositories, and the annex
+sizes of each repository.
+
+When a directory is specified, displays information
+about the annexed files in that directory (and subdirectories).
+This includes how much annexed data is present in the local repository,
+the total size of all annexed data in the directory, how many files
+have the specified numcopies or more (+1, +2 etc) or less (-1, -2 etc),
+and information about how much of the annexed data is stored in known
+repositories.
+
+When a treeish is specified, displays similar information
+as when a directory is specified, but about the annexed files in that
+treeish.
+
+When a remote, or description of a repository, or uuid is specified, 
+displays information about the specified repository, including the total
+amount of annexed data stored in it, and a variety of configuration
+information.
+
+# OPTIONS
+
+* `--fast`
+
+  Only show the information that can be gathered quickly.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* `--bytes`
+
+  Show file sizes in bytes, disabling the default nicer units.
+
+* `--batch`
+
+  Enable batch mode, in which a line containing an item is read from stdin,
+  the information about it is output to stdout, and repeat.
+
+* `-z`
+
+  Makes the `--batch` input be delimited by nulls instead of the usual
+  newlines.
+
+* `--autoenable`
+
+  Display a list of special remotes that have been configured to
+  autoenable.  
+
+* `--dead-repositories`
+
+  Display a list of repositories that have been marked as dead.
+  Such repositories are not displayed in other info displays.
+
+* matching options
+
+  The [[git-annex-matching-options]](1) can be used to select what
+  to include in the statistics.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# EXAMPLES
+
+Suppose you want to run "git annex get .", but
+would first like to see how much disk space that will use.
+Then run:
+  
+	git annex info --fast . --not --in here
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-init.mdwn b/doc/git-annex-init.mdwn
new file mode 100644
index 0000000000..aa0e418639
--- /dev/null
+++ b/doc/git-annex-init.mdwn
@@ -0,0 +1,86 @@
+# NAME
+
+git-annex init - initialize git-annex
+
+# SYNOPSIS
+
+git annex init `[description]`
+
+# DESCRIPTION
+
+Until a repository (or one of its remotes) has been initialized,
+git-annex will refuse to operate on it, to avoid accidentally
+using it in a repository that was not intended to have an annex.
+
+It's useful, but not mandatory, to initialize each new clone
+of a repository with its own description. If you don't provide one,
+one will be generated using the username, hostname and the path.
+
+If any special remotes were configured with autoenable=true,
+this will also attempt to enable them. See [[git-annex-initremote]](1).
+To prevent that, re-enable a remote with "autoenable=false", or
+mark it as dead (see [[git-annex-dead]](1)).
+
+This command is entirely safe, although usually pointless, to run inside an
+already initialized git-annex repository.
+  
+A top-level `.noannex` file will prevent git-annex init from being used
+in a repository. This is useful for repositories that have a policy
+reason not to use git-annex. The content of the file will be displayed
+to the user who tries to run git-annex init.
+
+# EXAMPLES
+
+	# git annex add foo
+	git-annex: First run: git-annex init
+	# git annex init
+	init ok
+	# git annex add foo
+	add foo ok
+
+# OPTIONS
+
+* `--version=N`
+
+  Force the repository to be initialized using a different annex.version
+  than the current default.
+
+  When the version given is not supported, but can be automatically
+  upgraded to a newer version, it will use the newer version instead.
+
+* `--autoenable`
+
+  Only enable any special remotes that were configured with
+  autoenable=true, do not otherwise initialize anything.
+
+* `--no-autoenable`
+
+  Do not enable special remotes that were configured with autoenable=true.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-describe]](1)
+
+[[git-annex-reinit]](1)
+
+git-init(1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-initremote.mdwn b/doc/git-annex-initremote.mdwn
new file mode 100644
index 0000000000..eb1c1294eb
--- /dev/null
+++ b/doc/git-annex-initremote.mdwn
@@ -0,0 +1,148 @@
+# NAME
+
+git-annex initremote - creates a special (non-git) remote
+
+# SYNOPSIS
+
+git annex initremote `name type=value [param=value ...]`
+
+# DESCRIPTION
+
+Creates a new special remote, and adds it to `.git/config`.
+
+Example Amazon S3 remote:
+  
+	git annex initremote mys3 type=S3 encryption=hybrid keyid=me@example.com datacenter=EU
+
+Many different types of special remotes are supported by git-annex.
+For a list and details, see <https://git-annex.branchable.com/special_remotes/>
+ 
+The remote's configuration is specified by the parameters passed
+to this command. Different types of special remotes need different
+configuration values, so consult the documentation of a special remote for
+details. The command will prompt for any required parameters you leave out;
+you can also pass --whatelse to see additional parameters.
+
+A few parameters that are supported by all special remotes are documented in
+the next section below.
+
+Once a special remote has been initialized once with this command,
+other clones of the repository can also be set up to access it using
+`git annex enableremote`.
+
+The name you provide for the remote can't be one that's been used for any
+other special remote before, because `git-annex enableremote` uses the name
+to identify which special remote to enable. If some old special remote
+that's no longer used has taken the name you want to reuse, you might
+want to use `git annex renameremote`.
+
+# OPTIONS
+
+* `--whatelse` / `-w`
+
+  Describe additional configuration parameters that you could specify.
+
+  For example, if you know you want a S3 remote, but forget how to
+  configure it:
+
+	git annex initremote mys3 type=S3 --whatelse
+
+  For a machine-readable list of the parameters, use this with --json.
+
+* `--fast`
+
+  When initializing a remote that uses encryption, a cryptographic key is
+  created. This requires sufficient entropy. If initremote seems to hang
+  or take a long time while generating the key, you may want to Ctrl-c it
+  and re-run with `--fast`, which causes it to use a lower-quality source of
+  randomness. (Ie, /dev/urandom instead of /dev/random)
+
+* `--sameas=remote`
+
+  Use this when the new special remote uses the same underlying storage
+  as some other remote. This will result in the new special remote having
+  the same uuid as the specified remote, and either can be used to access
+  the same content.
+
+  The `remote` can be the name of a git remote, or the description
+  or uuid of any git-annex repository.
+
+  When using this option, the new remote inherits the encryption settings
+  of the existing remote, so you should not specify any encryption
+  parameters. No other configuration is inherited from the existing remote.
+
+  This will only work if both remotes use the underlying storage in
+  compatible ways. See this page for information about known
+  compatabilities.
+  <http://git-annex.branchable.com/tips/multiple_remotes_accessing_the_same_data_store/>
+
+* `--private`
+
+  Avoid recording information about the special remote in the git-annex
+  branch. The special remote will only be usable from the repository where
+  it was created.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# COMMON CONFIGURATION PARAMETERS
+
+* `encryption`
+
+  Almost all special remotes support encryption. You will need to specify
+  what encryption, if any, to use. 
+
+  If you do not want any encryption, use `encryption=none`
+
+  To encrypt to a GPG key, use `encryption=hybrid keyid=$keyid ...`
+  and fill in the GPG key id (or an email address associated with a GPG key).
+  
+  For details about this and other encrpytion settings, see
+  <https://git-annex.branchable.com/encryption/>
+  or --whatelse
+
+* `autoenable`
+
+  To avoid `git annex enableremote` needing to be run,
+  you can pass "autoenable=true". Then when git-annex is run in a new clone,
+  it will attempt to enable the special remote. Of course, this works best
+  when the special remote does not need anything special to be done to get
+  it enabled.
+
+* `cost`
+
+  Specify this to override the default cost of the special remote.
+  This configuration can be overridden by the local git config,
+  eg remote.name.annex-cost.
+
+* `uuid`
+
+  Normally, git-annex initremote generates a new UUID for the new special
+  remote. If you want to, you can specify a UUID for it to use, by passing a
+  uuid=whatever parameter. This can be useful in some unusual situations.
+  But if in doubt, don't do this.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-enableremote]](1)
+
+[[git-annex-configremote]](1)
+
+[[git-annex-renameremote]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-inprogress.mdwn b/doc/git-annex-inprogress.mdwn
new file mode 100644
index 0000000000..744cebf84d
--- /dev/null
+++ b/doc/git-annex-inprogress.mdwn
@@ -0,0 +1,72 @@
+# NAME
+
+git-annex inprogress - access files while they're being downloaded
+
+# SYNOPSIS
+
+git annex inprogress `[path ...]`
+
+# DESCRIPTION
+
+This command allows accessing the content of an annexed file while
+it is still being downloaded. It outputs to standard output the
+name of the temporary file that is being used to download the specified
+annexed file.
+
+Nothing will be output when the download is from an encrypted or chunked 
+special remote.
+
+This can sometimes be used to stream a file before it's been fully
+downloaded, for example:
+
+	git annex get video.mpeg &
+	vlc $(git annex inprogress video.mpeg)
+
+Of course if the file is downloading too slowly, the media player will
+reach the end too soon and not show the whole thing. And of course, only
+some file formats can be usefully streamed in this way.
+
+# OPTIONS
+
+* `[path ..]`
+
+  The files or directories whose partially downloaded content you want to
+  access.
+
+  Note that, when no path is specified, it defaults to all files in the
+  current working directory, and subdirectories, which can take a while to
+  traverse. It's most efficient to specify a the file you are interested
+  in, or to use `--all`
+
+* `--all` `-A`
+
+  Rather than specifying a filename or path, this option can be
+  used to access all files that are currently being downloaded.
+
+* `--key=keyname`
+
+  Access the file that is currently being downloaded for the specified key.
+
+* file matching options
+ 
+  The [[git-annex-matching-options]](1)
+  can be used to specify files to access.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# EXIT STATUS
+
+If any of the requested items are not currently being downloaded,
+the exit status will be 1.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-get]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-list.mdwn b/doc/git-annex-list.mdwn
new file mode 100644
index 0000000000..532ae3446d
--- /dev/null
+++ b/doc/git-annex-list.mdwn
@@ -0,0 +1,40 @@
+# NAME
+
+git-annex list - show which remotes contain files
+
+# SYNOPSIS
+
+git annex list `[path ...]`
+
+# DESCRIPTION
+
+Displays a table of remotes that contain the contents of the specified
+files. This is similar to `git annex whereis` but a more compact display.
+
+# OPTIONS
+
+* `--allrepos`
+
+  Only configured remotes are shown by default; this option
+  adds all known repositories to the list.
+
+* file matching options
+  
+  The [[git-annex-matching-options]](1)
+  can be used to specify files to list.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-find]](1)
+
+[[git-annex-whereis]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-lock.mdwn b/doc/git-annex-lock.mdwn
new file mode 100644
index 0000000000..3e360db41c
--- /dev/null
+++ b/doc/git-annex-lock.mdwn
@@ -0,0 +1,50 @@
+# NAME
+
+git-annex lock - lock files to prevent modification
+
+# SYNOPSIS
+
+git annex lock `[path ...]`
+
+# DESCRIPTION
+
+Lock the specified annexed files, to prevent them from being modified.
+When no files are specified, all annexed files in the current directory are
+locked.
+
+Locking a file changes how it is stored in the git repository (from a
+pointer file to a symlink), so this command will make a change that you
+can commit.
+
+# OPTIONS
+
+* file matching options
+ 
+  The [[git-annex-matching-options]](1)
+  can be used to specify files to lock.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-add]](1)
+
+[[git-annex-unlock]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-log.mdwn b/doc/git-annex-log.mdwn
new file mode 100644
index 0000000000..68f749b241
--- /dev/null
+++ b/doc/git-annex-log.mdwn
@@ -0,0 +1,147 @@
+# NAME
+
+git-annex log - shows location log information
+
+# SYNOPSIS
+
+git annex log `[path ...]`
+
+# DESCRIPTION
+
+This command displays information from the history of the git-annex branch. 
+
+Several things can prevent that information being available to display.
+When [[git-annex-forget]] is used, old historical
+data gets cleared from the branch. When annex.private or
+remote.name.annex-private is configured, git-annex does not write
+information to the branch at all. And when annex.alwayscommit is set to
+false, information may not have been committed to the branch yet.
+
+# OPTIONS
+
+* `[path ...]`
+
+  Displays the location log for the specified file or files, showing each
+  repository they were added to ("+") and removed from ("-"). Note that
+  it displays information about the file content currently at these paths,
+  not for any different content that was there in earlier commits.
+
+* matching options
+  
+  The [[git-annex-matching-options]](1)
+  can be used to control what to act on when displaying the location log
+  for specified files.
+
+* `--all` `-A`
+
+  Shows location log changes to all content, with the most recent changes first.
+  In this mode, the names of files are not available and keys are displayed
+  instead.
+
+* `--sizesof=repository`
+
+  Displays a history of the total size of the annexed files in a repository
+  over time from the creation of the repository to the present.
+
+  The repository can be "here" for the current repository, or the name of a
+  remote, or a repository description or uuid.
+
+  Note that keys that do not have a known size are not included in the
+  total.
+
+* `--sizes`
+
+  This is like --sizesof, but rather than display the size of a single
+  repository, it displays the sizes of all known repositories.
+
+  The output is a CSV formatted table.
+
+* `--totalsizes`
+
+  This is like `--sizesof`, but it displays the total size of all
+  known repositories.
+
+* `--interval=time`
+
+  When using `--sizesof`, `--sizes`, and `--totalsizes`, this 
+  controls the minimum interval between displays of the size.
+  The default is to display each new recorded size.
+
+  The time is of the form "30d" or "1y".
+
+* `--received`
+
+  Combine this option with `--sizesof` or `--sizes` to display
+  the amount of data received into repositories since the last
+  line was output.
+
+* `--gnuplot`
+
+  Combine this option with `--sizesof` or `--sizes` or `--totalsizes`
+  to use gnuplot(1) to graph the data. The gnuplot file will be left on
+  disk for you to reuse.
+
+  For example, to graph the sizes of all repositories:
+
+  git-annex log --sizes --interval=1d --gnuplot
+
+  To graph the amount of new data received into each repository every 30
+  days:
+  
+  git-annex log --sizes --interval=30d --gnuplot --recieved
+
+* `--bytes`
+
+  Show sizes in bytes, disabling the default nicer units.
+
+* `--raw-date`
+
+  Rather than the normal display of a date in the local time zone,
+  displays seconds since the unix epoch.
+
+* `--since=date`, `--after=date`, `--until=date`, `--before=date`, `--max-count=N`
+
+  These options are passed through to `git log`, and can be used to limit
+  how far back to search for location log changes.
+  
+  For example: `--since "1 month ago"`
+
+  These options do not have an affect when using `--sizesof`, `--sizes`, 
+  and `--totalsizes`.
+
+* `--gource`
+
+  Generates output suitable for the `gource` visualization program.
+  
+  This option does not have an affect when using `--sizesof`, `--sizes`, 
+  and `--totalsizes`.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+  
+  This option does not have an affect when using `--sizesof`, `--sizes`, 
+  and `--totalsizes`.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+  
+  This option does not have an affect when using `--sizesof`, `--sizes`, 
+  and `--totalsizes`.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-forget]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-lookupkey.mdwn b/doc/git-annex-lookupkey.mdwn
new file mode 100644
index 0000000000..98329ce8c5
--- /dev/null
+++ b/doc/git-annex-lookupkey.mdwn
@@ -0,0 +1,48 @@
+# NAME
+
+git-annex lookupkey - looks up key used for file
+
+# SYNOPSIS
+
+git annex lookupkey `[file ...]`
+
+# DESCRIPTION
+
+This plumbing-level command looks up the key used for a file in the
+index. The key is output to stdout. If there is no key (because
+the file is not present in the index, or is not a git-annex managed file),
+nothing is output, and it exits nonzero.
+
+# OPTIONS
+
+* `--ref`
+
+  Rather than looking for the specified files in the index, interpet them
+  as git refs. For example to find the key used for somefile in tag v1.0:
+
+    git-annex lookupkey v1.0:somefile
+
+* `--batch`
+
+  Enable batch mode, in which a line containing the filename is read from
+  stdin, the key is output to stdout (with a trailing newline), and repeat.
+
+  Note that if there is no key corresponding to the file, an empty line is
+  output to stdout instead.
+
+* `-z`
+
+  Makes the `--batch` input be delimited by nulls instead of the usual
+  newlines.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-lookupkey/comment_1_100fcc1559449ae99a2dc6eade61662c._comment b/doc/git-annex-lookupkey/comment_1_100fcc1559449ae99a2dc6eade61662c._comment
new file mode 100644
index 0000000000..78c66e025c
--- /dev/null
+++ b/doc/git-annex-lookupkey/comment_1_100fcc1559449ae99a2dc6eade61662c._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="driusan@4d47e7deeb2f5d3846792d049ed06f96a0c3ca98"
+ nickname="driusan"
+ avatar="http://cdn.libravatar.org/avatar/409b69c3ae7b431fc16129ccdadae9cd"
+ subject="Options don't match git-annex lookupkey --help"
+ date="2019-03-30T16:05:29Z"
+ content="""
+The options in this man page don't quite match what shows up with git-annex lookupkey --help. `--help` seems to include a lot of options that are non-sensicle in the context of lookup key.
+
+
+> % git-annex lookupkey --help
+> git-annex lookupkey - looks up key used for file
+>
+> Usage: git-annex lookupkey [--batch] [-z] [FILE ...]
+>
+>Available options:
+>  --batch                  enable batch mode
+>  -z                       null delimited batch input
+>  --force                  allow actions that may lose annexed data
+>  -F,--fast                avoid slow operations
+>  -q,--quiet               avoid verbose output
+>  -v,--verbose             allow verbose output (default)
+>  -d,--debug               show debug messages
+>  --no-debug               don't show debug messages
+>  -b,--backend NAME        specify key-value backend to use
+>  -N,--numcopies NUMBER    override default number of copies
+>  --trust REMOTE           override trust setting
+>  --semitrust REMOTE       override trust setting back to default
+>  --untrust REMOTE         override trust setting to untrusted
+>  -c,--config NAME=VALUE   override git configuration setting
+>  --user-agent NAME        override default User-Agent
+>  --trust-glacier          Trust Amazon Glacier inventory
+>  --notify-finish          show desktop notification after transfer finishes
+>  --notify-start           show desktop notification after transfer starts
+>  -h,--help                Show this help text
+>
+>For details, run: git-annex help lookupkey
+>% git-annex version
+>git-annex version: 7.20190322-gbc302b56a
+>build flags: S3(multipartupload)(storageclasses) TorrentParser Feeds Testsuite
+>dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 feed-1.0.1.0 ghc-8.6.3 http-client-0.6.2 persistent-sqlite-2.9.2 torrent-10000.1.1 uuid-1.3.13
+>key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+>remote types: git gcrypt p2p S3 bup directory rsync web bittorrent adb tahoe glacier ddar hook external
+>operating system: dragonfly x86_64
+>supported repository versions: 5 7
+>upgrade supported from repository versions: 0 1 2 3 4 5 6
+>local repository version: 5
+
+"""]]
diff --git a/doc/git-annex-lookupkey/comment_2_897eaca8174d5f568a19805f90d9e1c3._comment b/doc/git-annex-lookupkey/comment_2_897eaca8174d5f568a19805f90d9e1c3._comment
new file mode 100644
index 0000000000..de1034d9ff
--- /dev/null
+++ b/doc/git-annex-lookupkey/comment_2_897eaca8174d5f568a19805f90d9e1c3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-04-03T16:58:53Z"
+ content="""
+git-annex has several global options that are documented in the main
+git-annex man page.
+"""]]
diff --git a/doc/git-annex-map.mdwn b/doc/git-annex-map.mdwn
new file mode 100644
index 0000000000..debfa1c31a
--- /dev/null
+++ b/doc/git-annex-map.mdwn
@@ -0,0 +1,52 @@
+# NAME
+
+git-annex map - generate map of repositories
+
+# SYNOPSIS
+
+git annex map
+
+# DESCRIPTION
+
+Helps you keep track of your repositories, and the connections between them,
+by going out and looking at all the ones it can get to, and generating a
+Graphviz file displaying it all. If the `xdot` or `dot` command is available,
+it is used to display the file to your screen.
+  
+This command only connects to hosts that the host it's run on can
+directly connect to. It does not try to tunnel through intermediate hosts.
+So it might not show all connections between the repositories in the network
+  
+Also, if connecting to a host requires a password, you might have to enter
+it several times as the map is being built.
+  
+Note that this subcommand can be used to graph any git repository; it
+is not limited to git-annex repositories.
+
+# LEGEND
+
+Ovals are repositories. White is regular, green is trusted, red is
+untrusted, and grey is dead.
+
+Arrows between repositories are connections via git remotes.
+
+Light blue boxes are hosts that were mapped, and contain the repositories
+on that host.
+
+# OPTIONS
+
+* `--fast`
+
+  Don't display the generated Graphviz file, but save it for later use.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-matchexpression.mdwn b/doc/git-annex-matchexpression.mdwn
new file mode 100644
index 0000000000..0b11bb3fde
--- /dev/null
+++ b/doc/git-annex-matchexpression.mdwn
@@ -0,0 +1,75 @@
+# NAME
+
+git-annex matchexpression - checks if an expression matches
+
+# SYNOPSIS
+
+git annex matchexpression `expression [data]`
+
+# DESCRIPTION
+
+This plumbing-level command is given a preferred content expression,
+and some data, and checks if the expression matches the data. It exits 0 if
+it matches, and 1 if not. If not enough data was provided, it displays an
+error and exits with special code 42.
+
+For example, this will exit 0:
+
+	git annex matchexpression "include=*.png and largerthan=1mb" --file=foo.png --size=10mb
+
+# OPTIONS
+
+* `--file=`
+
+  Provide the filename to match against. Note that the file does not have
+  to actually exist on disk.
+
+* `--size=`
+
+  Tell what the size of the file is. The size can be specified with any
+  commonly used units, for example, "0.5 gb" or "100 KiloBytes".
+
+* `--key=`
+
+  Tell what key is being matched against. This is needed for
+  matching expressions like "copies=N" and "metadata=tag=foo" and
+  "present", which all need to look up the information on file for a key.
+
+  Many keys have a known size, and so --size is not needed when specifying
+  such a key.
+
+* `--largefiles`
+
+  Parse the expression as an annex.largefiles expression, rather than a
+  preferred content expression.
+
+* `--mimetype=`
+
+  Tell what the mime type of the file is. Only needed when using
+  --largefiles with a mimetype= expression.
+
+* `--mimeencoding=`
+
+  Tell what the mime encoding of the file is. Only needed when using
+  --largefiles with a mimeencoding= expression.
+
+* `--explain`
+
+  Display explanation of what parts of the preferred content expression
+  match, and which parts don't match.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-preferred-content]](1)
+
+[[git-annex-matching-expression]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-matching-expression.mdwn b/doc/git-annex-matching-expression.mdwn
new file mode 100644
index 0000000000..246196b111
--- /dev/null
+++ b/doc/git-annex-matching-expression.mdwn
@@ -0,0 +1,92 @@
+# NAME
+
+git-annex-matching-expression - specifying a set of files
+
+# DESCRIPTION
+
+The annex.largefiles and annex.addunlocked configurations both use
+expressions that match some files in the working tree.
+
+# SYNTAX
+
+The format of these expressions is similar to
+[[git-annex-preferred-content]](1) expressions.
+
+For example:
+
+	largerthan=100kb and not (include=*.c or include=*.h)
+
+This matches large files, but excludes C source files.
+
+The following terms can be used:
+
+* `include=glob` / `exclude=glob`
+
+  Specify files to include or exclude.
+
+  The glob can contain `*` and `?` to match arbitrary characters.
+
+  Note that this matches on the whole filename, relative to the top 
+  of the git directory. So, `include=foo` will include a file `foo`
+  in the top, but not `subdir/foo`. To include both, use 
+  `include=foo or include=*/foo`
+
+* `smallerthan=size` / `largerthan=size`
+
+  Matches only files smaller than, or larger than the specified size.
+
+  The size can be specified with any commonly used units, for example,
+  "0.5 gb" or "100 KiloBytes"
+
+* `mimetype=glob`
+
+  Looks up the MIME type of a file, and checks if the glob matches it.
+
+  For example, `"mimetype=text/*"` will match many varieties of text files,
+  including "text/plain", but also "text/x-shellscript", "text/x-makefile",
+  etc.
+
+  The MIME types are the same that are displayed by running `file --mime-type`
+
+  This is only available to use when git-annex was built with the
+  MagicMime build flag.
+
+* `mimeencoding=glob`
+
+  Looks up the MIME encoding of a file, and checks if the glob matches it.
+
+  For example, `"mimeencoding=binary"` will match many kinds of binary
+  files.
+
+  The MIME encodings are the same that are displayed by running `file --mime-encoding`
+
+  This is only available to use when git-annex was built with the
+  MagicMime build flag.
+
+* `anything`
+
+  Matches any file.
+
+* `nothing`
+
+  Matches no files. (Same as "not anything")
+
+* `not expression`
+
+  Inverts what the expression matches.
+
+* `and` / `or` / `( expression )`
+
+  These can be used to build up more complicated expressions.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+<http://git-annex.branchable.com/>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-matching-options.mdwn b/doc/git-annex-matching-options.mdwn
new file mode 100644
index 0000000000..ea29f98848
--- /dev/null
+++ b/doc/git-annex-matching-options.mdwn
@@ -0,0 +1,310 @@
+# NAME
+
+git-annex-matching-options - specifying what to act on
+
+# DESCRIPTION
+
+Many git-annex commands support using these options to specify which
+files they act on. Some of these options can also be used by commands to
+specify which keys they act on.
+
+Arbitrarily complicated expressions can be built using these options.
+For example:
+
+	--include='*.mp3' --and -( --in=usbdrive --or --in=archive -)
+
+The above example makes git-annex work on only mp3 files that are present
+in either of two repositories.
+
+# OPTIONS
+
+* `--exclude=glob`
+
+  Skips files matching the glob pattern. The glob is matched relative to
+  the current directory. For example:
+
+        	git annex get --exclude='*.mp3' --exclude='subdir/*'
+
+  Note that this will not match anything when using --all or --unused.
+
+* `--include=glob`
+
+  Skips files not matching the glob pattern.  (Same as `--not --exclude`.)
+  For example, to include only mp3 and ogg files:
+
+        	git annex get --include='*.mp3' --or --include='*.ogg'
+
+  Note that this will not skip anything when using --all or --unused.
+
+* `--excludesamecontent=glob`
+
+  Skips a file when there is another file with the same content,
+  whose name matches the glob. The glob is matched relative to the current
+  directory.
+
+  For example, to drop files in the archive directory, but not when the same
+  content is used by a file in the work directory:
+
+        	git annex drop archive/ --excludesamecontent='work/*'
+
+* `--includesamecontent=glob`
+
+  Skips files when there is no other file with the same content
+  whose name matches the glob. (Same as `--not --excludesamecontent`)
+
+  For example, if you have inbox and outbox directories, and want to find
+  anything in the inbox that has the same content as something in the outbox:
+
+        	git annex find inbox --includesamecontent='outbox/*'
+
+* `--in=repository`
+
+  Matches only when git-annex believes that the content is present in a
+  repository.
+
+  The repository should be specified using the name of a configured remote,
+  or the UUID or description of a repository. For the current repository,
+  use `--in=here`
+  
+  Note that this does not check remote repositories to verify that content
+  is still present on them. However, when checking the current repository,
+  it does verify that content is present in it.
+
+* `--in=repository@{date}`
+
+  Matches only when the content was present in a repository on the given
+  date.
+
+  The date is specified in the same syntax documented in
+  gitrevisions(7). Note that this uses the reflog, so dates far in the
+  past cannot be queried.
+
+  For example, you might need to run `git annex drop .` to temporarily
+  free up disk space. The next day, you can get back the files you dropped
+  using `git annex get . --in=here@{yesterday}`
+
+* `--expected-present`
+
+  Matches only when git-annex believes that the content is present 
+  in the local repository.
+
+  This is like `--in=here`, except it does not verify that the content
+  is actually present. So it can be used in situations where the location
+  tracking information is known to be out of date.
+
+  For example, if a repository is being restored from a backup
+  that did not include the git-annex objects, this could be used to get
+  back all files that were expected to be in it: 
+  `git-annex get --expected-present`
+
+* `--copies=number`
+
+  Matches only when git-annex believes there are the specified number
+  of copies, or more. Note that it does not check remotes to verify that
+  the copies still exist.
+
+* `--copies=trustlevel:number`
+
+  Matches only when git-annex believes there are the specified number of
+  copies, on remotes with the specified trust level. For example,
+  `--copies=trusted:2`
+
+  To match any trust level at or higher than a given level,
+  use 'trustlevel+'. For example, `--copies=semitrusted+:2`
+
+* `--copies=groupname:number`
+
+  Matches only when git-annex believes there are the specified number of
+  copies, on remotes in the specified group. For example,
+  `--copies=archive:2`
+
+* `--lackingcopies=number`
+
+  Matches only when git-annex believes that the specified number or 
+  more additional copies need to be made in order to satisfy numcopies
+  settings.
+
+* `--approxlackingcopies=number`
+
+  Like lackingcopies, but does not look at .gitattributes annex.numcopies
+  settings. This makes it significantly faster.
+
+* `--inbackend=name`
+
+  Matches only when content is stored using the specified key-value
+  backend.
+
+* `--securehash`
+
+  Matches only when content is hashed using a cryptographically
+  secure function. 
+
+* `--inallgroup=groupname`
+
+  Matches only when git-annex believes content is present in
+  all repositories in the specified group.
+
+* `--onlyingroup=groupname`
+
+  Matches only when git-annex believes content is present in at least one
+  repository that is in the specified group, and is not present in any
+  repositories that are not in the specified group.
+
+* `--smallerthan=size`
+* `--largerthan=size`
+
+  Matches only when the content is is smaller than, or larger than the
+  specified size.
+
+  The size can be specified with any commonly used units, for example,
+  "0.5 gb" or "100 KiloBytes"
+
+* `--metadata field=glob`
+
+  Matches only when there is a metadata field attached with a value that
+  matches the glob. The values of metadata fields are matched case
+  insensitively.
+
+* `--metadata field<value` / `--metadata field>value`
+* `--metadata field<=value` / `--metadata field>=value`
+
+  Matches only when there is a metadata field attached with a value
+  that is less then or greater than the specified value, respectively.
+
+  When both values are numbers, the comparison is done numerically.
+  When one value is not a number, the values are instead compared
+  lexicographically.
+
+  (Note that you will need to quote the second parameter to avoid
+  the shell doing redirection.)
+
+* `--want-get`
+
+  Matches only when the preferred content settings for the local repository
+  make it want to get content. Note that this will match even when
+  the content is already present, unless limited with e.g., `--not --in=here`
+
+* `--want-drop`
+
+  Matches only when the preferred content settings for the local repository
+  make it want to drop content. Note that this will match even when
+  the content is not present, unless limited with e.g., `--not --in=here`
+
+  Things that this matches will not necessarily be dropped by
+  `git-annex drop --auto`. This does not check that there are enough copies
+  to drop. Also the same content may be used by a file that is not wanted
+  to be dropped.
+
+* `--want-get-by=repository`
+
+  Matches only when the preferred content settings for the specified 
+  repository make it want to get content. Note that this will match even when
+  the content is already present in that repository, unless limited with e.g.,
+  `--not --in=repository`
+
+  The repository should be specified using the name of a configured remote,
+  or the UUID or description of a repository. `--want-get-by=here`
+  is the same as `--want-get`.
+
+* `--want-drop-by=repository`
+
+  Matches only when the preferred content settings for the specificed
+  repository make it want to drop content. Note that this will match
+  even when the content is not present, unless limited with e.g., 
+  `--not --in=repository`
+ 
+  The repository should be specified using the name of a configured remote,
+  or the UUID or description of a repository. `--want-drop-by=here`
+  is the same as `--want-drop`.
+
+* `--accessedwithin=interval`
+
+  Matches when the content was accessed recently, within the specified time
+  interval.
+  
+  The interval can be in the form "5m" or "1h" or "2d" or "1y", or a
+  combination such as "1h5m".
+
+  So for example, `--accessedwithin=1d` matches when the content was
+  accessed within the past day.
+
+  If the OS or filesystem does not support access times, this will not
+  match anything.
+
+* `--unlocked`
+
+  Matches annexed files that are unlocked.
+
+* `--locked`
+
+  Matches annexed files that are locked.
+
+* `--mimetype=glob`
+
+  Looks up the MIME type of a file, and checks if the glob matches it.
+
+  For example, `--mimetype="text/*"` will match many varieties of text files,
+  including "text/plain", but also "text/x-shellscript", "text/x-makefile",
+  etc.
+
+  The MIME types are the same that are displayed by running `file --mime-type`
+
+  If the file's annexed content is not present, the file will not match.
+
+  This is only available to use when git-annex was built with the
+  MagicMime build flag.
+
+* `--mimeencoding=glob`
+
+  Looks up the MIME encoding of a file, and checks if the glob matches it.
+
+  For example, `--mimeencoding=binary` will match many kinds of binary
+  files.
+
+  The MIME encodings are the same that are displayed by running `file --mime-encoding`
+
+  If the file's annexed content is not present, the file will not match.
+
+  This is only available to use when git-annex was built with the
+  MagicMime build flag.
+
+* `--anything`
+
+  Always matches. One way this can be useful is `git-annex find --anything`
+  will list all annexed files, whether their content is present or not.
+
+* `--nothing`
+
+  Never matches. (Same as `--not --anything`)
+
+* `--not`
+
+  Inverts the next matching option. For example, to match
+  when there are less than 3 copies, use `--not --copies=3`
+
+* `--and`
+
+  Requires that both the previous and the next matching option matches.
+  The default.
+
+* `--or`
+
+  Requires that either the previous, or the next matching option matches.
+
+* `-(`
+
+  Opens a group of matching options.
+
+* `-)`
+
+  Closes a group of matching options.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-matching-options/comment_1_09d1a7961a79dff47bef8797b3775766._comment b/doc/git-annex-matching-options/comment_1_09d1a7961a79dff47bef8797b3775766._comment
new file mode 100644
index 0000000000..83849ea16d
--- /dev/null
+++ b/doc/git-annex-matching-options/comment_1_09d1a7961a79dff47bef8797b3775766._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="mike@2d6d71f56ce2a992244350475251df87c26fe351"
+ nickname="mike"
+ avatar="http://cdn.libravatar.org/avatar/183fa439752e2f0c6f39ede658d81050"
+ subject="--includesamecontent same as  --not --includesamecontent?"
+ date="2023-12-06T22:12:47Z"
+ content="""
+The text for `--includesamecontent` states that is the \"same as `--not --includesamecontent`\", this is probably a bug in the documentation?
+"""]]
diff --git a/doc/git-annex-matching-options/comment_2_78a5e7090e5ac3e6710813bac600fde0._comment b/doc/git-annex-matching-options/comment_2_78a5e7090e5ac3e6710813bac600fde0._comment
new file mode 100644
index 0000000000..2156da9311
--- /dev/null
+++ b/doc/git-annex-matching-options/comment_2_78a5e7090e5ac3e6710813bac600fde0._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: --includesamecontent same as  --not --includesamecontent?"""
+ date="2023-12-18T17:40:04Z"
+ content="""
+Fixed that, thanks.
+"""]]
diff --git a/doc/git-annex-merge.mdwn b/doc/git-annex-merge.mdwn
new file mode 100644
index 0000000000..507e19ca9c
--- /dev/null
+++ b/doc/git-annex-merge.mdwn
@@ -0,0 +1,56 @@
+# NAME
+
+git-annex merge - merge changes from remotes
+
+# SYNOPSIS
+
+git annex merge [branch]
+
+# DESCRIPTION
+
+When run without any parameters, this performs the same merging (and merge
+conflict resolution) that is done by the `git-annex pull` and `git-annex sync`
+commands, but without uploading or downloading any data.
+
+When a branch to merge is specified, this merges it, using the same merge
+conflict resolution as the `git-annex pull` command. This is especially useful on
+an adjusted branch, because it applies the same adjustment to the
+branch before merging it.
+
+When annex.resolvemerge is set to false, merge conflict resolution
+will not be done.
+
+# OPTIONS
+
+* `--allow-unrelated-histories`, `--no-allow-unrelated-histories`
+
+  Passed on to `git merge`, to control whether or not to merge
+  histories that do not share a common ancestor.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also, the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-pull]](1)
+
+[[git-annex-sync]](1)
+
+[[git-annex-adjust]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-metadata.mdwn b/doc/git-annex-metadata.mdwn
new file mode 100644
index 0000000000..9eb6ebf3aa
--- /dev/null
+++ b/doc/git-annex-metadata.mdwn
@@ -0,0 +1,182 @@
+# NAME
+
+git-annex metadata - sets or gets metadata of a file
+
+# SYNOPSIS
+
+git annex metadata `[path ...]`
+
+# DESCRIPTION
+
+The content of an annexed file can have any number of metadata fields
+attached to it to describe it. Each metadata field can in turn
+have any number of values.
+
+This command can be used to set metadata, or show the currently set
+metadata.
+
+When run without any -s or -t parameters, displays the current metadata.
+
+Each metadata field has its own "field-lastchanged" metadata, which
+contains the date the field was last changed. Unlike other metadata,
+this cannot be directly modified by this command. It is updated
+automatically.
+
+Note that the metadata is attached to git-annex key corresponding to the 
+content of a file, not to a particular filename on a particular git branch.
+All files with the same key share the same metadata, which is
+stored in the git-annex branch. If a file is modified, the metadata
+of the previous version will be copied to the new key when git-annex adds
+the modified file.
+
+# OPTIONS
+
+* `-g field` / `--get field`
+
+  Get the value(s) of a single field.
+
+  The values will be output one per line, with no other output, so
+  this is suitable for use in a script.
+
+* `-s field=value` / `--set field=value`
+
+  Set a field's value, removing any old values.
+
+* `-s field+=value` / `--set field+=value`
+
+  Add an additional value, preserving any old values.
+
+* `-s field?=value` / `--set field?=value`
+
+  Set a value, but only if the field does not already have a value set.
+
+* `-s field-=value` / `--set field-=value`
+
+  Remove a value from a field, leaving any other values that the field has
+  set.
+
+* `-r field` / `--remove field`
+
+  Remove all current values of the field.
+
+* `-t tag` / `--tag tag`
+
+  Set a tag. Note that a tag is just a value of the "tag" field.
+
+* `-u tag` / `--unset tag`
+
+  Unset a tag.
+
+* `--remove-all`
+
+  Remove all metadata from the specified files.
+
+  When a file is modified and the new version added, git-annex will copy
+  over the metadata from the old version of the file. In situations where
+  you don't want that copied metadata, you can use this option to remove
+  it.
+
+* `--force`
+
+  By default, `git annex metadata` refuses to recursively set metadata
+  throughout the files in a directory. This option enables such recursive
+  setting.
+
+* matching options
+ 
+  The [[git-annex-matching-options]](1)
+  can be used to control what to act on.
+
+* `--all` `-A`
+
+  Specify instead of a file to get/set metadata on all known keys.
+
+* `--branch=ref`
+
+  Specify instead of a file to get/set metadata on all files in the
+  specified branch or treeish.
+
+* `--unused`
+
+  Specify instead of a file to get/set metadata on
+  files found by last run of git-annex unused.
+
+* `--key=keyname`
+
+  Specify instead of a file to get/set metadata of the specified key.
+
+* `--json`
+
+  Enable JSON output (and input). Each line is a JSON object.
+
+  The format of the JSON objects changed in git-annex version 6.20160726.
+
+  Example of the new format:
+
+	{"command":"metadata","file":"foo","key":"...","fields":{"author":["bar"],...},"note":"...","success":true}
+
+  Example of the old format, which lacks the inner fields object:
+
+	{"command":"metadata","file":"foo","key":"...","author":["bar"],...,"note":"...","success":true}
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* `--batch`
+
+  Enables batch mode, which can be used to both get, store, and unset
+  metadata for multiple files or keys.
+
+  Batch currently only supports JSON input. So, you must
+  enable `--json` along with `--batch`.
+
+  In batch mode, git-annex reads lines from stdin, which contain
+  JSON objects. It replies to each input annexed file
+  with an output JSON object. (But if the file is not an annexed file,
+  an empty line will be output.)
+
+  The format of the JSON sent to git-annex can be the same as the JSON that
+  it outputs. Or, a simplified version. Only the "file" (or "key") field
+  is actually necessary.
+
+  For example, to get the current metadata of file foo:
+
+	{"file":"foo"}
+
+  To get the current metadata of the key k:
+	
+	{"key":"k"}
+
+  Any metadata fields included in the JSON object will be stored,
+  replacing whatever values the fields had before.
+  To unset a field, include it with an empty list of values.
+
+  To change the author of file foo to bar:
+
+	{"file":"foo","fields":{"author":["bar"]}}
+
+  To remove the author of file foo:
+
+	{"file":"foo","fields":{"author":[]}}
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# EXAMPLES
+
+To set some tags on a file and also its author:
+
+	git annex metadata annexscreencast.ogv -t video -t screencast -s author+=Alice
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-view]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-metadata/comment_10_278fca1c579d0acdcce819449aec8eee._comment b/doc/git-annex-metadata/comment_10_278fca1c579d0acdcce819449aec8eee._comment
new file mode 100644
index 0000000000..c644f06b36
--- /dev/null
+++ b/doc/git-annex-metadata/comment_10_278fca1c579d0acdcce819449aec8eee._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="comment 10"
+ date="2021-01-03T22:07:02Z"
+ content="""
+From this man page, it's not totally clear how/where the metadata is stored. Is it inside the Git repo (i.e. as regular file), or inside the Annex, or somewhere else? Is this information synced when you do `git push` (as part of Git), or via `git annex sync`? 
+
+How does it resolve any conflicts?
+
+Is the metadata itself under version control? (If it is in Git itself, then clearly yes, but that's not clear to me.)
+
+"""]]
diff --git a/doc/git-annex-metadata/comment_11_deee9a4c3a812c9c8097d89f2f6c7d76._comment b/doc/git-annex-metadata/comment_11_deee9a4c3a812c9c8097d89f2f6c7d76._comment
new file mode 100644
index 0000000000..27042676c6
--- /dev/null
+++ b/doc/git-annex-metadata/comment_11_deee9a4c3a812c9c8097d89f2f6c7d76._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2021-01-04T16:06:02Z"
+ content="""
+@AlbertZeyer, this man page says it is "stored in the git-annex branch."
+
+That branch is synced whenever you push it, which git-annex sync does do,
+but git push can also be set up to do. The branch is automatically merged.
+"""]]
diff --git a/doc/git-annex-metadata/comment_1_45492400069021adbe048978be6957ef._comment b/doc/git-annex-metadata/comment_1_45492400069021adbe048978be6957ef._comment
new file mode 100644
index 0000000000..768f36be19
--- /dev/null
+++ b/doc/git-annex-metadata/comment_1_45492400069021adbe048978be6957ef._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/iOGTltEpmOTQ.xZ99NFP5c7Zdcc-#6a7ba"
+ nickname="Ilya S"
+ avatar="http://cdn.libravatar.org/avatar/8a133555cc739a35b83b07d5724d28d9e2f7852c224e949eec6fd4fb7693331e"
+ subject="adding metadata to keys that don't point to any contents is ok, correct?"
+ date="2018-09-08T22:36:06Z"
+ content="""
+I want to store a simple mapping in git-annex on the git-annex branch, from string keys to values.  I figured I can just do
+ git annex metadata --key=WORM-s0-m0--mykey -s myfield+=myvalue
+and after git annex sync these mappings will propagate to copies of the repo.  But the keys won't point to any file in any remote.
+Will that break anything in git-annex?  Will they get garbage-collected automatically in some circumstances?
+"""]]
diff --git a/doc/git-annex-metadata/comment_2_12e615b99bf9999df0678cb6dc09d398._comment b/doc/git-annex-metadata/comment_2_12e615b99bf9999df0678cb6dc09d398._comment
new file mode 100644
index 0000000000..79ceb56429
--- /dev/null
+++ b/doc/git-annex-metadata/comment_2_12e615b99bf9999df0678cb6dc09d398._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-09-11T16:33:15Z"
+ content="""
+The only risk in doing this is that if you somehow later add a file that
+actually uses that key it will have this metadata.
+
+There's no garbage collection of metadata except for keys that have been
+marked as dead with `git annex dead`.
+"""]]
diff --git a/doc/git-annex-metadata/comment_3_6537bd785997501a9708682acd91f9f6._comment b/doc/git-annex-metadata/comment_3_6537bd785997501a9708682acd91f9f6._comment
new file mode 100644
index 0000000000..b47ee3d7be
--- /dev/null
+++ b/doc/git-annex-metadata/comment_3_6537bd785997501a9708682acd91f9f6._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="question about .gitattributes"
+ date="2019-05-03T15:21:41Z"
+ content="""
+Joey, I feel like I have asked it before, but can't quickly search it up, so asking again (sorry if repeating). By
+
+> To attach metadata to a particular path, rather than a particular key, use .gitattributes .
+
+you meant attaching some other metadata, not really \"git-annex\" metadata, right? 
+Or there is a way to specify metadata `key=value` pairs to be attached to annexed files, e.g. smth like
+
+```
+*_scans.json annex.metadata=(distribution-restrictions=sensitive)
+```
+?
+"""]]
diff --git a/doc/git-annex-metadata/comment_4_49c885bd5840aba9f9e011a1618931a1._comment b/doc/git-annex-metadata/comment_4_49c885bd5840aba9f9e011a1618931a1._comment
new file mode 100644
index 0000000000..bffd1294d5
--- /dev/null
+++ b/doc/git-annex-metadata/comment_4_49c885bd5840aba9f9e011a1618931a1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-05-03T15:34:07Z"
+ content="""
+I did not write that, Ilya did. I agree that it was confusing that it was
+talking about some entirely different kind of metadata, and have reworded
+it.
+"""]]
diff --git a/doc/git-annex-metadata/comment_5_b4f928a4e8a81165e3845219483a9b25._comment b/doc/git-annex-metadata/comment_5_b4f928a4e8a81165e3845219483a9b25._comment
new file mode 100644
index 0000000000..4dd25db7fc
--- /dev/null
+++ b/doc/git-annex-metadata/comment_5_b4f928a4e8a81165e3845219483a9b25._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 5"
+ date="2019-05-03T15:50:43Z"
+ content="""
+I think I added that line to the docs, and yes, it's not for git-annex metadata.  I'll clarify the page.
+
+I'm not sure there is a well-defined way to set git-annex metadata via .gitattributes, given the different semantics of git-annex metadata (it's tied to timestamps, and is shared between all branches).  Maybe one could define some unified-metadata, which interprets git-annex metadata on an annexed file as implicitly setting .gitattributes for that file in that directory.
+"""]]
diff --git a/doc/git-annex-metadata/comment_6_11b1fa357953736925cfbbc1079590dd._comment b/doc/git-annex-metadata/comment_6_11b1fa357953736925cfbbc1079590dd._comment
new file mode 100644
index 0000000000..e199e4f059
--- /dev/null
+++ b/doc/git-annex-metadata/comment_6_11b1fa357953736925cfbbc1079590dd._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="meanwhile"
+ date="2019-09-20T18:53:03Z"
+ content="""
+I am [thinking about some abominations](https://github.com/datalad/datalad/issues/3696) to workaround inability to specify smth like
+
+```
+licenses/* annex.commit.metadata=(distribution-restrictions=sensitive)
+```
+in `.gitattributes`. IMHO by limiting to `.commit` the scope when annex should add metadata becomes clear.  Sure thing it could leak across files with the same content (0-length files are most prone) but it is unrelated IMHO since a direct call to `git annex metadata licenses/* -s ...` would have the same effect anyways.
+"""]]
diff --git a/doc/git-annex-metadata/comment_7_fe7d15a1a4cd729b6ffec26f49d8b47a._comment b/doc/git-annex-metadata/comment_7_fe7d15a1a4cd729b6ffec26f49d8b47a._comment
new file mode 100644
index 0000000000..650b327114
--- /dev/null
+++ b/doc/git-annex-metadata/comment_7_fe7d15a1a4cd729b6ffec26f49d8b47a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tobiasBora"
+ avatar="http://cdn.libravatar.org/avatar/80a7d8c2a7b475b6b71198cce0faa6b0"
+ subject="Get list of files with specific metadata"
+ date="2019-09-23T13:16:11Z"
+ content="""
+Hello,
+I would like to know, is it possible to get in one command all files with a particular tag, or a list of tags (like \"give all files that have tag foo or tag bar\"). Note that I don't want to change the current view. Also, are you aware of any music player that could use these tags to find some songs to play and add them to some playlist?
+"""]]
diff --git a/doc/git-annex-metadata/comment_8_54cff011e3e13882cfbd7a30fb43d078._comment b/doc/git-annex-metadata/comment_8_54cff011e3e13882cfbd7a30fb43d078._comment
new file mode 100644
index 0000000000..134cedad83
--- /dev/null
+++ b/doc/git-annex-metadata/comment_8_54cff011e3e13882cfbd7a30fb43d078._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2019-09-23T14:12:55Z"
+ content="""
+See [[git-annex-matching-options]] for ways to query for metadata.
+
+For example:
+
+	git annex find --metadata tag=foo --or --metadata tag=bar
+"""]]
diff --git a/doc/git-annex-metadata/comment_9_a14b21109aa12eaf13e8c215e108cc29._comment b/doc/git-annex-metadata/comment_9_a14b21109aa12eaf13e8c215e108cc29._comment
new file mode 100644
index 0000000000..0b9085a43f
--- /dev/null
+++ b/doc/git-annex-metadata/comment_9_a14b21109aa12eaf13e8c215e108cc29._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="tobiasBora"
+ avatar="http://cdn.libravatar.org/avatar/80a7d8c2a7b475b6b71198cce0faa6b0"
+ subject="comment 9"
+ date="2019-09-24T14:49:21Z"
+ content="""
+Ok thank you! If you also have names of music playes that can actually read tags from git annex, let me know!
+"""]]
diff --git a/doc/git-annex-migrate.mdwn b/doc/git-annex-migrate.mdwn
new file mode 100644
index 0000000000..89cfeb963f
--- /dev/null
+++ b/doc/git-annex-migrate.mdwn
@@ -0,0 +1,112 @@
+# NAME
+
+git-annex migrate - switch data to different backend
+
+# SYNOPSIS
+
+git annex migrate `[path ...]`
+
+git annex migrate --update
+
+# DESCRIPTION
+
+Changes the specified annexed files to use the default key-value backend
+(or the one specified with `--backend`). Only files whose content
+is currently present are migrated.
+
+Note that the content is also still stored using the old keys after
+migration. When possible, hard links are used to avoid that taking up
+extra disk space. Use `git annex unused` to find and remove the old keys.
+
+Normally, nothing will be done to specified files that are already using
+the new backend. However, if a backend changes the information it uses to
+construct a key, this can also be used to migrate files to use the new key
+format.
+
+# OPTIONS
+
+* `--update`
+
+  This updates the local repository for migrations that were performed
+  elsewhere. Only new migrations since the last time this was run will
+  be performed. 
+
+  This does not modify the working tree, but only hard links
+  (or in some cases copies) annex objects to their new keys.
+
+  `git-annex pull` and `git-annex sync --content` automatically do this,
+  unless the `annex.syncmigrations` config is set to false.
+
+  Note that older versions of git-annex did not record migrations in a
+  way that this can use. Migrations performed with those older versions
+  had to be manually run in each clone of the repository.
+
+* `--apply`
+
+  This applies all recorded migrations to the local repository. It is the
+  non-incremental form of `--update`.
+
+  One situation where this can be useful is when `git-annex migrate
+  --update` has been run, but since then un-migrated 
+  objects have entered the repository. Using this option ensures that
+  any such objects get migrated.
+
+  Note that older versions of git-annex did not record migrations in a
+  way that this can use. Migrations performed with those older versions
+  had to be manually run in each clone of the repository.
+
+* `--backend`
+
+  Specify the new key-value backend to use for migrated data.
+
+* `--force`
+
+  Force migration of keys that are already using the new backend.
+
+* file matching options
+ 
+  The [[git-annex-matching-options]](1)
+  can be used to specify files to migrate.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+* `--remove-size`
+
+  Keys often include the size of their content, which is generally a useful
+  thing. In fact, this command defaults to adding missing size information
+  to keys in most migrations. With this option, the size information is
+  removed instead.
+
+  One use of this option is to convert URL keys that were added
+  by `git-annex addurl --fast` to ones that would have been added if
+  that command was run with the `--relaxed` option. Eg:
+
+  	git-annex migrate --remove-size --backend=URL somefile
+
+  To add back the size to an URL key, use this:
+
+    git-annex migrate --backend=URL somefile
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-upgrade]](1)
+
+[[git-annex-backend]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-mincopies.mdwn b/doc/git-annex-mincopies.mdwn
new file mode 100644
index 0000000000..231b71f614
--- /dev/null
+++ b/doc/git-annex-mincopies.mdwn
@@ -0,0 +1,48 @@
+# NAME
+
+git-annex mincopies - configure minimum number of copies
+
+# SYNOPSIS
+
+git annex mincopies `N`
+
+# DESCRIPTION
+
+Tells git-annex how many copies it is required to preserve of files, over all
+repositories. The default is 1.
+
+Run without a number to get the current value.
+
+This configuration is stored in the git-annex branch, so it will be seen
+by all clones of the repository. It can be overridden on a per-file basis
+by the annex.mincopies setting in .gitattributes files, or can be
+overridden temporarily with the --mincopies option.
+
+This supplements the [[git-annex-numcopies]](1) setting. 
+In unusual situations, involving special remotes that do not support
+locking, and concurrent drops of the same content from multiple
+repositories, git-annex may violate the numcopies setting.
+In these unusual situations, git-annex ensures that the number of copies
+never goes below mincopies.
+
+It is a good idea to not only rely on only setting mincopies. Set
+numcopies as well, to a larger number, and keep mincopies at the
+bare minimum you're comfortable with. Setting mincopies to a large
+number, rather than setting numcopies will in some cases prevent
+droping content in entirely safe situations.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+[[git-annex-numcopies]](1)
+[[git-annex-config]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-mirror.mdwn b/doc/git-annex-mirror.mdwn
new file mode 100644
index 0000000000..36453744b4
--- /dev/null
+++ b/doc/git-annex-mirror.mdwn
@@ -0,0 +1,100 @@
+# NAME
+
+git-annex mirror - mirror content of files to/from another repository
+
+# SYNOPSIS
+
+git annex mirror `[path ...] [--to=remote|--from=remote]`
+
+# DESCRIPTION
+
+This causes a destination repository to mirror a source repository.
+
+Each specified file in the source repository is mirrored to the destination
+repository. If a file's content is present in the source repository, it is
+copied to the destination repository. If a file's content is not present in
+the source repository, it will be dropped from the destination repository
+when the numcopies setting allows.
+  
+Note that mirror does not sync the git repository, but only the file
+contents. Use [[git-annex-sync]](1) for that.
+
+# OPTIONS
+
+* `--to=remote`
+
+  Use the local repository as the source repository, and mirror its contents
+  to the remote.
+
+* `--from=remote`
+
+  Use the remote as the source repository, and mirror its contents to the local
+  repository.
+
+* `--jobs=N` `-JN`
+
+  Enables parallel transfers with up to the specified number of jobs
+  running at once. For example: `-J10`
+
+  Setting this to "cpus" will run one job per CPU core.
+
+* `--all` `-A`
+
+  Mirror all objects stored in the git annex, not only objects used by
+  currently existing files. 
+  
+  However, this bypasses checking the .gitattributes annex.numcopies
+  setting when dropping files.
+
+  This is the default behavior when running git-annex in a bare repository.
+
+* `--branch=ref`
+
+  Operate on files in the specified branch or treeish.
+
+  Like --all, this bypasses checking the .gitattributes annex.numcopies
+  setting when dropping files.
+
+* `--unused`
+
+  Operate on files found by last run of git-annex unused.
+
+* `--failed`
+
+  Operate on files that have recently failed to be transferred.
+
+* matching options
+
+  The [[git-annex-matching-options]](1)
+  can be used to control what to mirror.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+  Note that unlike all other commands that support `--json`, this command
+  outputs different types of json objects in different circumstances.
+
+* `--json-progress`
+
+  Include progress objects in JSON output.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-sync]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-move.mdwn b/doc/git-annex-move.mdwn
new file mode 100644
index 0000000000..c93953f985
--- /dev/null
+++ b/doc/git-annex-move.mdwn
@@ -0,0 +1,146 @@
+# NAME
+
+git-annex move - move content of files to/from another repository
+
+# SYNOPSIS
+
+git annex move `[path ...] [--from=remote|--to=remote|--to=here]`
+
+# DESCRIPTION
+
+Moves the content of files from or to another remote.
+
+With no parameters, operates on all annexed files in the current directory.
+Paths of files or directories to operate on can be specified.
+
+# OPTIONS
+
+* `--from=remote`
+
+  Move the content of files from the specified remote to the local repository.
+
+* `--to=remote`
+
+  Move the content of files from the local repository to the specified remote.
+
+* `--to=here`
+
+  Move the content of files from all reachable remotes to the local
+  repository.
+
+* `--from=remote1 --to=remote2`
+
+  Move the content of files that are in remote1 to remote2. Does not change
+  what is stored in the local repository.
+
+  This is implemented by first downloading the content from remote1 to the
+  local repository (if not already present), then sending it to remote2, and
+  then deleting the content from the local repository (if it was not present
+  to start with).
+
+* `--from-anywhere --to=remote`
+
+  Move to the remote files from the local repository and from all 
+  reachable remotes.
+
+* `--force`
+
+  Override numcopies and required content checking, and always remove
+  files from the source repository once the destination repository has a
+  copy.
+
+  Note that, even without this option, you can move the content of a file
+  from one repository to another when numcopies is not satisfied, as long
+  as the move does not result in there being fewer copies.
+
+* `--jobs=N` `-JN`
+
+  Enables parallel transfers with up to the specified number of jobs
+  running at once. For example: `-J10`
+
+  Setting this to "cpus" will run one job per CPU core.
+
+  Note that when using --from with --to, twice this many jobs will
+  run at once, evenly split between the two remotes.
+
+* `--all` `-A`
+
+  Rather than specifying a filename or path to move, this option can be
+  used to move all available versions of all files.
+
+  This is the default behavior when running git-annex in a bare repository.
+
+* `--branch=ref`
+
+  Operate on files in the specified branch or treeish.
+
+* `--unused`
+
+  Operate on files found by last run of git-annex unused.
+
+* `--failed`
+
+  Operate on files that have recently failed to be transferred.
+
+* `--key=keyname`
+
+  Use this option to move a specified key.
+
+* matching options
+
+  The [[git-annex-matching-options]](1)
+  can be used to control what to move.
+
+* `--batch`
+
+  Enables batch mode, in which lines containing names of files to move
+  are read from stdin.
+
+  As each specified file is processed, the usual progress output is
+  displayed. If a file's content does not need to be moved,
+  or it does not match specified matching options, or it
+  is not an annexed file, a blank line is output in response instead.
+
+  Since the usual output while moving a file is verbose and not
+  machine-parseable, you may want to use --json in combination with
+  --batch.
+
+* `--batch-keys`
+
+  This is like `--batch` but the lines read from stdin are parsed as keys.
+
+* `-z`
+
+  Makes batch input be delimited by nulls instead of the usual newlines.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-progress`
+
+  Include progress objects in JSON output.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-get]](1)
+
+[[git-annex-copy]](1)
+
+[[git-annex-drop]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-move/comment_1_b69fbe2f3892deddb269dd3eb1fdcd84._comment b/doc/git-annex-move/comment_1_b69fbe2f3892deddb269dd3eb1fdcd84._comment
new file mode 100644
index 0000000000..5e75b89a98
--- /dev/null
+++ b/doc/git-annex-move/comment_1_b69fbe2f3892deddb269dd3eb1fdcd84._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="Move from A to B"
+ date="2017-07-26T19:08:07Z"
+ content="""
+It would be awesome to be able to move (or copy) between remotes, 
+eg. `git annex copy --from=remote-a --to=remote-b`
+
+Use case: I have a repo of ~1TB, but only ~30GB free disk space on my laptop. Currently I have to manually `get` and `move` the files almost one by one to get them from one remote to the other.
+"""]]
diff --git a/doc/git-annex-move/comment_2_f2908113a633034aa73b8564d22abba6._comment b/doc/git-annex-move/comment_2_f2908113a633034aa73b8564d22abba6._comment
new file mode 100644
index 0000000000..90379ca6eb
--- /dev/null
+++ b/doc/git-annex-move/comment_2_f2908113a633034aa73b8564d22abba6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="3rd party &quot;mover&quot; / speed up git annex move"
+ date="2018-09-17T12:16:08Z"
+ content="""
+git annex move seems to be quite slow if many small files have to be transferred. I think the main issue is that for each file a new TCP connection is opened. In this case reusing the TCP connection could significantly speed up the transfers. Two questions about this. a) Am I just doing something wrong? (I don't want to use -J because the remote is cluster and -J connects to different servers.) b) Is there an efficient method to write my own mover for the files in question? Basically \"git annex find [...] --json\" gives me all the files in question, so I know what to move. But after copying them to the remote, how do I tell git annex that they are there? Does it make sense to use git annex reinject?
+"""]]
diff --git a/doc/git-annex-move/comment_3_82cfbc0f3600c7c4c9dffc1d35e81123._comment b/doc/git-annex-move/comment_3_82cfbc0f3600c7c4c9dffc1d35e81123._comment
new file mode 100644
index 0000000000..b3313456a7
--- /dev/null
+++ b/doc/git-annex-move/comment_3_82cfbc0f3600c7c4c9dffc1d35e81123._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-09-24T15:18:21Z"
+ content="""
+git-annex always reuses TCP connections.
+
+More likely you are using an older version of git-annex which
+had some overhead due to running rsync once per transfer. Since version
+6.20180316 git-annex has avoided that overhead.
+"""]]
diff --git a/doc/git-annex-move/comment_4_013e20add9a007d3f9a9c2a2ceb6cb06._comment b/doc/git-annex-move/comment_4_013e20add9a007d3f9a9c2a2ceb6cb06._comment
new file mode 100644
index 0000000000..8b9f2effc7
--- /dev/null
+++ b/doc/git-annex-move/comment_4_013e20add9a007d3f9a9c2a2ceb6cb06._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="rename or move files"
+ date="2021-01-01T21:33:41Z"
+ content="""
+Is this command also for renaming or moving files, like `git mv`?
+
+If not, I think this should be explained more clearly in the documentation.
+
+If not, how would I move/rename files then? As I understand, annexed files are just symlinks. So if I would move the file to another directory (e.g. via `git mv` or just `mv`), the symlink might break.
+
+"""]]
diff --git a/doc/git-annex-move/comment_5_e7608b7fac4ec80781cb4281dc2bf596._comment b/doc/git-annex-move/comment_5_e7608b7fac4ec80781cb4281dc2bf596._comment
new file mode 100644
index 0000000000..2395e2857f
--- /dev/null
+++ b/doc/git-annex-move/comment_5_e7608b7fac4ec80781cb4281dc2bf596._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 5"
+ date="2021-01-02T15:22:18Z"
+ content="""
+`git annex move` belongs so the same class of commands as `git annex get`, `git annex drop` and `git annex copy` in that it manages file content. Git annex automatically registers a pre-commit hook to fixup symlinks. `git annex fix` can also be used to fixup symlinks, but it currently is broken.
+"""]]
diff --git a/doc/git-annex-move/comment_6_eb62a9020575d89799815f6e4b98b28c._comment b/doc/git-annex-move/comment_6_eb62a9020575d89799815f6e4b98b28c._comment
new file mode 100644
index 0000000000..6eb032729f
--- /dev/null
+++ b/doc/git-annex-move/comment_6_eb62a9020575d89799815f6e4b98b28c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="comment 6"
+ date="2021-01-03T21:48:50Z"
+ content="""
+Renaming files is still somewhat unclear then. So I should just use `git mv` to rename files?
+What if the file extension changes? E.g. I have lots of pictures with uppercase `.JPG` and I might want to change them to `.jpg`. I might also have some files as `.jpeg` and to unify them, I might change them as well to `.jpg`. But as far as I understand, that would also change the default hash, as the default hash contains the extension? But doing `git mv` will take care about all of that via pre-commit hooks?
+
+"""]]
diff --git a/doc/git-annex-move/comment_7_e23e2a133db02112ca99aeda0499e841._comment b/doc/git-annex-move/comment_7_e23e2a133db02112ca99aeda0499e841._comment
new file mode 100644
index 0000000000..53295014ed
--- /dev/null
+++ b/doc/git-annex-move/comment_7_e23e2a133db02112ca99aeda0499e841._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-01-04T16:04:45Z"
+ content="""
+Use `git mv` if you want to rename an annexed file. That does not change
+the key, the old key will work fine despite the extension having changed.
+"""]]
diff --git a/doc/git-annex-multicast.mdwn b/doc/git-annex-multicast.mdwn
new file mode 100644
index 0000000000..6f6a47b204
--- /dev/null
+++ b/doc/git-annex-multicast.mdwn
@@ -0,0 +1,97 @@
+# NAME
+
+git-annex multicast - multicast file distribution
+
+# SYNOPSIS
+
+git annex multicast [options]
+
+# DESCRIPTION
+
+Multicast allows files to be broadcast to multiple receivers,
+typically on a single local network.
+
+The uftp program is used for multicast.
+<http://uftp-multicast.sourceforge.net/>
+
+# OPTIONS
+
+* `--gen-address`
+
+  Generates a multicast encryption key and stores a corresponding multicast
+  address to the git-annex branch.
+
+* `--send [file]`
+
+  Sends the specified files to any receivers whose multicast addresses
+  are stored in the git-annex branch.
+
+  When no files are specified, all annexed files in the current directory
+  and subdirectories are sent.
+
+  The [[git-annex-matching-options]](1) can be used to control which files to
+  send. For example:
+
+	git annex multicast send . --not --copies 2
+
+* `--receive`
+
+  Receives files from senders whose multicast addresses
+  are stored in the git-annex brach.
+
+  As each file is received, its filename is displayed. This is the filename
+  that the sender used; the local working tree may use a different name
+  for the file, or not contain a link to the file.
+
+  This command continues running, until it is interrupted by you pressing
+  ctrl-c.
+
+  Note that the configured annex.diskreserve is not honored by this
+  command, because `uftpd` receives the actual files, and can receive
+  any size file.
+
+* `--uftp-opt=option` `-Uoption`
+
+  Pass an option on to the uftp/uftpd command. May be specified multiple
+  times.
+
+  For example, to broadcast at 50 Mbps:
+
+	git annex multicast send -U-R -U50000
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# EXAMPLE
+
+Suppose a teacher wants to multicast files to students in a classroom.
+
+This assumes that the teacher and students have cloned a git-annex
+repository, and both can push changes to its git-annex branch,
+or otherwise push changes to each-other.
+
+First, the teacher runs `git annex multicast --gen-address; git annex sync`
+
+Next, students each run `git annex multicast --gen-address; git annex sync`
+
+Once all the students have generated addresses, the teacher runs
+`git annex sync` once more. (Now the students all have received the
+teacher's address, and the teacher has received all the student's addresses.)
+
+Next students each run `git annex multicast --receive`
+
+Finally, once the students are all listening (ahem), teacher runs
+`git annex multicast --send`
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+uftp(1)
+
+uftpd(1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-numcopies.mdwn b/doc/git-annex-numcopies.mdwn
new file mode 100644
index 0000000000..9a7c5a6c22
--- /dev/null
+++ b/doc/git-annex-numcopies.mdwn
@@ -0,0 +1,45 @@
+# NAME
+
+git-annex numcopies - configure desired number of copies
+
+# SYNOPSIS
+
+git annex numcopies `N`
+
+# DESCRIPTION
+
+Tells git-annex how many copies it should preserve of files, over all
+repositories. The default is 1. 
+
+Run without a number to get the current value.
+
+This configuration is stored in the git-annex branch, so it will be seen
+by all clones of the repository. It can be overridden on a per-file basis
+by the annex.numcopies setting in .gitattributes files, or can be
+overridden temporarily with the --numcopies option.
+
+When git-annex is asked to drop a file, it first verifies that the
+number of copies can be satisfied among all the other
+repositories that have a copy of the file.
+
+In unusual situations, involving special remotes that do not support
+locking, and concurrent drops of the same content from multiple
+repositories, git-annex may violate the numcopies setting. It still
+guarantees at least 1 copy is preserved. This can be configured by
+using [[git-annex-mincopies]](1)
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+[[git-annex-mincopies]](1)
+[[git-annex-config]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-oldkeys.mdwn b/doc/git-annex-oldkeys.mdwn
new file mode 100644
index 0000000000..2f2da7457d
--- /dev/null
+++ b/doc/git-annex-oldkeys.mdwn
@@ -0,0 +1,54 @@
+# NAME
+
+git-annex oldkeys - list keys used for old versions of files
+
+# SYNOPSIS
+
+git annex oldkeys `[path ...]`
+
+# DESCRIPTION
+
+Lists keys used for old versions of the specified files or directories.
+
+The output from this command can be piped into a command like
+`git-annex drop --batch-keys`
+
+The keys are listed in order from newest to oldest.
+
+When listing old keys for a directory, it will include keys used by deleted
+files that were in that directory in past commits.
+
+# OPTIONS
+
+* --unchecked
+
+  By default this command does not list a key that is also used by any
+  file in the currently checked out branch. This option makes it also
+  list such keys.
+
+  The default behavior avoids surprises when dropping listed keys.
+  This option can be useful when eg copying all old versions of a file to a
+  remote.
+
+* --revision-range=value
+
+  Only list old keys used in the specified range of revisions.
+  This works the same as the revision range option of `git log`.
+  See gitrevisions(7) for documentation about the format of this option.
+
+  For example, to list only keys used since the tag v1.0, use
+  `--revision-range=v1.0..HEAD`
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-unused]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-p2p.mdwn b/doc/git-annex-p2p.mdwn
new file mode 100644
index 0000000000..6b9d60c381
--- /dev/null
+++ b/doc/git-annex-p2p.mdwn
@@ -0,0 +1,82 @@
+# NAME
+
+git-annex p2p - configure peer-2-peer links between repositories
+
+# SYNOPSIS
+
+git annex p2p [options]
+
+# DESCRIPTION
+
+This command can be used to link git-annex repositories over peer-2-peer
+networks.
+
+Currently, the only P2P network supported by git-annex is Tor hidden
+services.
+
+# OPTIONS
+
+* `--pair`
+
+  Run this in two repositories to pair them together over the P2P network.
+
+  This will print out a code phrase, like "3-mango-elephant", and
+  will prompt for you to enter the code phrase from the other repository.
+
+  Once code phrases have been exchanged, the two repositories will
+  be paired. A git remote will be created for the other repository,
+  with a name like "peer1".
+
+  This uses [Magic Wormhole](https://github.com/warner/magic-wormhole)
+  to verify the code phrases and securely communicate the P2P addresses of
+  the repositories, so you will need it installed on both computers that are
+  being paired.
+
+  This feature was present in a broken form in git-annex versions
+  before version 6.20180705. Make sure that a new enough git-annex
+  is installed on both computers that are being paired.
+
+* `--gen-addresses`
+
+  Generates addresses that can be used to access this git-annex repository
+  over the available P2P networks. The address or addresses is output to
+  stdout. 
+  
+  Note that anyone who knows these addresses can access your
+  repository over the P2P networks.
+  
+  This can be run repeatedly, in order to give different addresses 
+  out to different people.
+
+* `--link`
+
+  Sets up a git remote that is accessed over a P2P network.
+  
+  This will prompt for an address to be entered; you should paste in the
+  address that was generated by --gen-addresses in the remote repository.
+
+  Defaults to making the git remote be named "peer1", "peer2",
+  etc. This can be overridden with the `--name` option.
+
+* `--name`
+
+  Specify a name to use when setting up a git remote with `--link`
+  or `--pair`.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-enable-tor]](1)
+
+[[git-annex-remotedaemon]](1)
+
+wormhole(1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-p2p/comment_1_d5a6a2eab5d32a9c2f4ed194e01d95e8._comment b/doc/git-annex-p2p/comment_1_d5a6a2eab5d32a9c2f4ed194e01d95e8._comment
new file mode 100644
index 0000000000..0455dfd985
--- /dev/null
+++ b/doc/git-annex-p2p/comment_1_d5a6a2eab5d32a9c2f4ed194e01d95e8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="bugmenot"
+ avatar="http://cdn.libravatar.org/avatar/d3f7106e378e83d54c010c230ff074b9"
+ subject="--link accepts itself"
+ date="2019-10-10T05:28:53Z"
+ content="""
+Is there a good reason why `git annex p2p --link` will accept addresses that points to itself?
+
+I'm trying to script automatic addition of .onion peers, and it's a bit annoying to have to filter the .onion pointing to the current repo instead of just adding all of the .onion urls and having it ignore/warn/fail on the one that is currently in .git/annex/creds/p2paddrs
+"""]]
diff --git a/doc/git-annex-post-receive.mdwn b/doc/git-annex-post-receive.mdwn
new file mode 100644
index 0000000000..63cb5e9802
--- /dev/null
+++ b/doc/git-annex-post-receive.mdwn
@@ -0,0 +1,36 @@
+# NAME
+
+git-annex post-receive - run by git post-receive hook
+
+# SYNOPSIS
+
+git annex post-receive
+
+# DESCRIPTION
+
+This is meant to be called from git's post-receive hook. `git annex init`
+automatically creates a post-receive hook using this.
+
+When a repository is configured with receive.denyCurrentBranch=updateInstead,
+pushes to the repository update its work tree. However, that does not work
+for repositories that have an adjusted branch checked
+out. The hook updates the work tree when run in such a repository,
+the same as running `git-annex merge` would.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-adjust]](1)
+
+[[git-annex-merge]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-pre-commit.mdwn b/doc/git-annex-pre-commit.mdwn
new file mode 100644
index 0000000000..118cb74c36
--- /dev/null
+++ b/doc/git-annex-pre-commit.mdwn
@@ -0,0 +1,32 @@
+# NAME
+
+git-annex pre-commit - run by git pre-commit hook
+
+# SYNOPSIS
+
+git annex pre-commit `[path ...]`
+
+# DESCRIPTION
+
+This is meant to be called from git's pre-commit hook. `git annex init`
+automatically creates a pre-commit hook using this.
+
+Fixes up symlinks that are staged as part of a commit, to ensure they
+point to annexed content.
+
+When in a view, updates metadata to reflect changes
+made to files in the view.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-preferred-content.mdwn b/doc/git-annex-preferred-content.mdwn
new file mode 100644
index 0000000000..890c519596
--- /dev/null
+++ b/doc/git-annex-preferred-content.mdwn
@@ -0,0 +1,317 @@
+# NAME
+
+git-annex-preferred-content - which files are wanted in a repository
+
+# DESCRIPTION
+
+Each repository has a preferred content setting, which specifies content
+that the repository wants to have present. These settings can be configured
+using `git annex vicfg` or `git annex wanted`.
+They are used by the `--auto` option, by `git annex sync --content`,
+and by the git-annex assistant.
+
+While preferred content expresses a preference, it can be overridden
+by simply using `git annex drop`. On the other hand, required content
+settings are enforced; `git annex drop` will refuse to drop a file if
+doing so would violate its required content settings. A repository's
+required content can be configured using `git annex vicfg` or
+`git annex required`.
+
+# SYNTAX
+
+Preferred content expressions use a similar syntax to 
+the [[git-annex-matching-options]](1), without the dashes.
+For example:
+
+	exclude=archive/* and (include=*.mp3 or smallerthan=1mb)
+
+The idea is that you write an expression that files are matched against. If
+a file matches, the repository wants to store its content. If it doesn't,
+the repository wants to drop its content (if there are enough copies
+elsewhere to allow removing it).
+
+# EXPRESSIONS
+
+* `include=glob` / `exclude=glob`
+
+  Match files to include, or exclude.
+
+  While the command-line options --include=glob and --exclude=glob match
+  files relative to the current directory, preferred content expressions
+  match files relative to the top of the git repository.
+
+  A glob is something like `foo.*` or `b?r`. 
+  Globs can also contain character classes, 
+  like `foo[Bb]ar`, as well as additional POSIX character classes like
+  `[[:space:]]`. Which is useful, since a glob in a preferred content
+  expression cannot contain spaces. See the `glob(7)` man page for more
+  about globs.
+
+  For example, suppose you put files into `archive` directories
+  when you're done with them. Then you could configure your laptop to prefer
+  to not retain those files, like this: `exclude=*/archive/*`
+
+  When a subdirectory is being exported or imported to a special remote (see
+  [[git-annex-export]](1)) and [[git-annex-import]](1), these match relative
+  to the top of the subdirectory.
+
+  Note that, when a command is run with the `--all` option, or in a bare
+  repository, there is no filename associated with an annexed object,
+  and so "include=" and "exclude=" will not match.
+
+* `copies=number`
+
+  Matches only files that git-annex believes to have the specified number
+  of copies, or more. Note that it does not check remotes to verify that
+  the copies still exist.
+
+  To decide if content should be dropped, git-annex evaluates the preferred
+  content expression under the assumption that the content has *already* been
+  dropped. If the content would not be wanted then, the drop can be done.
+  So, for example, `copies=2` in a preferred content expression lets
+  content be dropped only when there are currently 3 copies of it, including
+  the repo it's being dropped from. This is different than running `git annex
+  drop --copies=2`, which will drop files that currently have 2 copies.
+
+* `copies=trustlevel:number`
+
+  Matches only files that git-annex believes have the specified number
+  copies, on remotes with the specified trust level. For example,
+  `copies=trusted:2`
+
+  To match any trust level at or higher than a given level,
+  use `trustlevel+`. For example, `copies=semitrusted+:2`
+
+* `copies=groupname:number`
+
+  Matches only files that git-annex believes have the specified number of
+  copies, on remotes in the specified group. For example,
+  `copies=archive:2`
+
+  Preferred content expressions have no equivalent to the `--in`
+  option, but groups can accomplish similar things. You can add
+  repositories to groups, and match against the groups in a
+  preferred content expression. So rather than `--in=usbdrive`,
+  put all the USB drives into a "transfer" group, and use
+  `copies=transfer:1`
+
+* `lackingcopies=number`
+
+  Matches only files that git-annex believes need the specified number or
+  more additional copies to be made in order to satisfy their numcopies
+  settings.
+
+* `approxlackingcopies=number`
+
+  Like lackingcopies, but does not look at .gitattributes annex.numcopies
+  settings. This makes it significantly faster.
+
+* `inbackend=backendname`
+
+  Matches only files whose content is stored using the specified key-value
+  backend.
+
+  See [[git-annex-backends]](1) for information about available backends.
+
+* `securehash`
+
+  Matches only files whose content is hashed using a cryptographically
+  secure function.
+
+* `inallgroup=groupname`
+
+  Matches only files that git-annex believes are present in all repositories
+  in the specified group.
+
+* `onlyingroup=groupname`
+
+  Matches files that git-annex believes are present in at least one
+  repository that is in the specified group, and are not present in any
+  repositories that are not in the specified group.
+
+* `smallerthan=size` / `largerthan=size`
+
+  Matches only files whose content is smaller than, or larger than the
+  specified size.
+
+  The size can be specified with any commonly used units, for example,
+  "0.5 gb" or "100 KiloBytes"
+
+* `metadata=field=glob`
+
+  Matches only files that have a metadata field attached with a value that
+  matches the glob. The values of metadata fields are matched case
+  insensitively.
+
+  A glob is something like `foo.*` or `b?r`. 
+  Globs can also contain character classes, 
+  like `foo[Bb]ar`, as well as additional POSIX character classes like
+  `[[:space:]]`. Which is useful, since a glob in a preferred content
+  expression cannot contain spaces. See the `glob(7)` man page for more
+  about globs.
+
+  To match a tag "done", use `metadata=tag=done`
+
+  To match author metadata, use `metadata=author=*Smith`
+
+* `metadata=field<number` / `metadata=field>number` 
+* `metadata=field<=number` / `metadata=field>=number`
+
+  Matches only files that have a metadata field attached with a value that
+  is a number and is less than or greater than the specified number.
+
+  To match PDFs with between 100 and 200 pages (assuming something has set
+  that metadata), use `metadata=pagecount>=100 and metadata=pagecount<=200`
+
+* `present`
+
+  Makes content be wanted if it's present, but not otherwise.
+
+  This leaves it up to you to use git-annex manually
+  to move content around. You can use this to avoid preferred content
+  settings from affecting a subdirectory. For example:
+  `auto/* or (include=ad-hoc/* and present)`
+
+  Note that `not present` is a very bad thing to put in a preferred content 
+  expression. It'll make it want to get content that's not present, and
+  drop content that is present! Don't go there..
+
+* `inpreferreddir`
+
+  Makes content be preferred if it's in a directory (located anywhere
+  in the tree) with a particular name. 
+
+  The name of the directory can be configured using 
+  `git annex enableremote $remote preferreddir=$dirname`
+
+  (If no directory name is configured, it uses "public" by default.)
+
+  Note that, when a command is run with the `--all` option, or in a bare
+  repository, there is no filename associated with an annexed object,
+  and so "inpreferreddir" will not match.
+
+* `standard`
+
+  git-annex comes with some built-in preferred content expressions, that
+  can be used with repositories that are in some standard groups
+  such as "client" and "transfer".
+
+  When a repository is in exactly one such group, you can use the "standard"
+  keyword in its preferred content expression, to match whatever content
+  the group's expression matches.
+
+  Most often, the whole preferred content expression is simply "standard".
+  But, you can do more complicated things, for example:
+  `standard or include=otherdir/*`
+
+* `groupwanted`
+
+  The "groupwanted" keyword can be used to refer to a preferred content
+  expression that is associated with a group, as long as there is exactly
+  one such expression amoung the groups a repository is in. This is like
+  the "standard" keyword, but you can configure the preferred content
+  expressions using `git annex groupwanted`.
+
+  When writing a groupwanted preferred content expression,
+  you can use all the keywords documented here, including "standard".
+  (But not "groupwanted".)
+
+  For example, to make a variant of the standard client preferred content
+  expression that does not want files in the "out" directory, you
+  could run: `git annex groupwanted client "standard and exclude=out/*"`
+
+  Then repositories that are in the client group and have their preferred
+  content expression set to "groupwanted" will use that, while
+  other client repositories that have their preferred content expression
+  set to "standard" will use the standard expression.
+
+  Or, you could make a new group, with your own custom preferred content
+  expression tuned for your needs, and every repository you put in this
+  group and make its preferred content be "groupwanted" will use it.
+
+  For example, the archive group only wants to archive 1 copy of each file,
+  spread among every repository in the group.
+  Here's how to configure a group named redundantarchive, that instead
+  wants to contain 3 copies of each file:
+  
+	git annex groupwanted redundantarchive "not (copies=redundantarchive:3)"
+	for repo in foo bar baz; do
+		git annex group $repo redundantarchive
+		git annex wanted $repo groupwanted
+	done
+
+* `unused`
+
+  Matches only keys that `git annex unused` has determined to be unused.
+
+  This is related the the --unused option.
+  However, putting `unused` in a preferred content expression 
+  doesn't make git-annex consider those unused keys. So when git-annex is
+  only checking preferred content expressions against files in the
+  repository (which are obviously used), `unused` in a preferred
+  content expression won't match anything.
+
+  So when is `unused` useful in a preferred content expression?
+
+  Using `git annex sync --content --all` will operate on all files,
+  including unused ones, and take `unused` in preferred content expressions
+  into account.
+  
+  The git-annex assistant periodically scans for unused files, and
+  moves them to some repository whose preferred content expression
+  says it wants them. (Or, if annex.expireunused is set, it may just delete
+  them.)
+
+* `anything`
+
+  Always matches.
+
+* `nothing`
+
+  Never matches. (Same as "not anything")
+
+* `not expression`
+
+  Inverts what the expression matches. For example, `not include=archive/*`
+  is the same as `exclude=archive/*`
+
+* `and` / `or` / `( expression )`
+
+  These can be used to build up more complicated expressions.
+
+# TESTING
+
+To check at the command line which files are matched by a repository's
+preferred content settings, you can use the --want-get and --want-drop
+options.
+
+For example, git annex find --want-get --not --in . will find all the files
+that git annex get --auto will want to get, and git annex find --want-drop --in
+. will find all the files that git annex drop --auto will want to drop.
+
+The --explain option can be used to understand why a complex preferred
+content expression matches or fails to match. The expression will
+be displayed, with each term followed by "[TRUE]" or "[FALSE]" to indicate
+the value. Irrelevant terms will be ommitted from the explanation,
+for example `"exclude=* and copies=1"` will be displayed as 
+`"exclude=*[FALSE]"`
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-vicfg]](1)
+
+[[git-annex-wanted]](1)
+
+<https://git-annex.branchable.com/preferred_content/>
+
+<https://git-annex.branchable.com/preferred_content/standard_groups/>
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+<http://git-annex.branchable.com/>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-preferred-content/comment_1_4c24f4513af72214bd5feb69f1ab86bc._comment b/doc/git-annex-preferred-content/comment_1_4c24f4513af72214bd5feb69f1ab86bc._comment
new file mode 100644
index 0000000000..cf9c84ffd7
--- /dev/null
+++ b/doc/git-annex-preferred-content/comment_1_4c24f4513af72214bd5feb69f1ab86bc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ subject="comment 1"
+ date="2016-01-21T08:35:52Z"
+ content="""
+The `present` expression is mentioned in [standard_groups](https://git-annex.branchable.com/preferred_content/standard_groups/) but doesn't seem to be explicitly documented anywhere. Is it basically the preferred-content equivalent of `--in .`?
+"""]]
diff --git a/doc/git-annex-preferred-content/comment_2_e4e0f34466db1fecd21db0e929530ad0._comment b/doc/git-annex-preferred-content/comment_2_e4e0f34466db1fecd21db0e929530ad0._comment
new file mode 100644
index 0000000000..5a873189a1
--- /dev/null
+++ b/doc/git-annex-preferred-content/comment_2_e4e0f34466db1fecd21db0e929530ad0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-01-22T15:59:31Z"
+ content="""
+Well, it was documented over on [[preferred_content]]. But I've moved the
+documentation to here so it'll be available in man page form.
+"""]]
diff --git a/doc/git-annex-preferred-content/comment_3_73c14351e041ac5ba86f6ab21487fd12._comment b/doc/git-annex-preferred-content/comment_3_73c14351e041ac5ba86f6ab21487fd12._comment
new file mode 100644
index 0000000000..c35dacb745
--- /dev/null
+++ b/doc/git-annex-preferred-content/comment_3_73c14351e041ac5ba86f6ab21487fd12._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Don"
+ subject="want everything, but not old versions"
+ date="2016-03-31T18:50:55Z"
+ content="""
+I'm trying to make a custom `full` group that wants everything, but doesn't keep old versions like the `backup` group that wants `anything`.  I'm using `groupwanted full = (copies=1)`--will that work?  I guess the `anything` expression seems a bit magical to me, so I'm not sure how to avoid matching what it matches to collect old versions.  
+"""]]
diff --git a/doc/git-annex-preferred-content/comment_4_4f30e99af93a2eb571f5b084cfa72d0d._comment b/doc/git-annex-preferred-content/comment_4_4f30e99af93a2eb571f5b084cfa72d0d._comment
new file mode 100644
index 0000000000..39c859c97c
--- /dev/null
+++ b/doc/git-annex-preferred-content/comment_4_4f30e99af93a2eb571f5b084cfa72d0d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-04-04T20:01:42Z"
+ content="""
+@Don, when a preferred content expression matches
+based on the name of a file, it will only match objects used by
+files currently in the tree, and not objects used by old versions.
+
+So, what you want is probably as simple as "include=*"
+"""]]
diff --git a/doc/git-annex-preferred-content/comment_5_b05949f87e0073e93a7e09658bd21f05._comment b/doc/git-annex-preferred-content/comment_5_b05949f87e0073e93a7e09658bd21f05._comment
new file mode 100644
index 0000000000..dcd5eb610a
--- /dev/null
+++ b/doc/git-annex-preferred-content/comment_5_b05949f87e0073e93a7e09658bd21f05._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="rinomizu5@5ead4c82685c65d7717dbd5591b80425036ae9e3"
+ nickname="rinomizu5"
+ avatar="http://cdn.libravatar.org/avatar/62478823018c68821064febcda7e5d4f"
+ subject="&quot;not inbackend=URL&quot; is failed with parse error"
+ date="2022-09-21T07:04:35Z"
+ content="""
+I tried the `git annex wanted gin \"not inbackend=URL\"` because I don't want to sync to gin remote if the backend key is a URL. But it failed with a Parse error.  
+The syntax says `inbackend=name`, but is `URL` not included in this `name`?  
+Please advise me what to do.  
+
+
+"""]]
diff --git a/doc/git-annex-preferred-content/comment_6_f10a0c185fa2f2b4b8ec9fceaed6e8e1._comment b/doc/git-annex-preferred-content/comment_6_f10a0c185fa2f2b4b8ec9fceaed6e8e1._comment
new file mode 100644
index 0000000000..11d9c25844
--- /dev/null
+++ b/doc/git-annex-preferred-content/comment_6_f10a0c185fa2f2b4b8ec9fceaed6e8e1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-09-26T19:53:52Z"
+ content="""
+@rinomizu5 congrats, you found a bug!
+
+I've fixed this, so you'll want to upgrade to version 10.20220927 when
+it's released tomorrow.
+"""]]
diff --git a/doc/git-annex-proxy.mdwn b/doc/git-annex-proxy.mdwn
new file mode 100644
index 0000000000..374bd27c6f
--- /dev/null
+++ b/doc/git-annex-proxy.mdwn
@@ -0,0 +1,25 @@
+# NAME
+
+git-annex proxy - safely bypass direct mode guard (deprecated)
+
+# SYNOPSIS
+
+git annex proxy `-- git cmd [options]`
+
+# DESCRIPTION
+
+This command was for use in a direct mode repository, and such 
+repositories are automatically updated to use an adjusted unlocked branch.
+So, there's no reason to use this command any longer.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-direct]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-pull.mdwn b/doc/git-annex-pull.mdwn
new file mode 100644
index 0000000000..eabc599995
--- /dev/null
+++ b/doc/git-annex-pull.mdwn
@@ -0,0 +1,153 @@
+# NAME
+
+git-annex pull - pull content from remotes
+
+# SYNOPSIS
+
+git annex pull `[remote ...]`
+
+# DESCRIPTION
+
+This command pulls content from remotes. It downloads
+both git repository content, and the content of annexed files.
+Like `git pull`, it merges changes into the current branch.
+
+You can use `git pull` and `git-annex get` by hand to do the same thing as
+this command, but this command handles several details, including making
+sure that the git-annex branch is fetched from the remote.
+
+Some special remotes contain a tree of files that can be imported,
+and this command can be used to pull from those remotes as
+well as regular git remotes. See [[git-annex-import]](1) for details
+about how those special remotes work. In order for this command to import
+from a special remote, `remote.<name>.annex-tracking-branch` also must
+be configured, and have the same value as the currently checked out branch.
+
+When [[git-annex-adjust]](1) has been used to check out an adjusted branch,
+this command will also pull changes from the parent branch.
+
+When [[git-annex-view]](1) has been used to check out a view branch,
+this command will update the view branch to reflect any changes 
+to the parent branch or metadata.
+
+When [[git-annex-migrate]](1) has been used in other repositories,
+this updates the content in the local repository for those migrations as well.
+
+Normally this tries to download the content of each annexed file,
+from any remote that it's pulling from that has a copy. 
+To control which files it downloads, configure the preferred
+content of the local repository. It will also drop files from a
+remote that are not preferred content of the remote.
+See [[git-annex-preferred-content]](1).
+
+# OPTIONS
+
+* `[remote]`
+
+  By default this command pulls from all available remotes, except for remotes
+  that have `remote.<name>.annex-pull` (or `remote.<name>.annex-sync`) 
+  set to false. 
+
+  By specifying the names of remotes (or remote groups), you can control
+  which ones to pull from.
+
+* `--fast`
+
+  Only pull with the remotes with the lowest annex-cost value configured.
+
+  When a list of remotes (or remote groups) is provided, it picks from
+  amoung those, otherwise it picks from amoung all remotes.
+
+* `--only-annex` `-a`, `--not-only-annex`
+
+  Only pull the git-annex branch and annexed content from remotes,
+  not other git branches.
+
+  The `annex.synconlyannex` configuration can be set to true to make
+  this be the default behavior. To override such a setting, use
+  `--not-only-annex`.
+
+  When this is combined with --no-content, only the git-annex branch
+  will be pulled.
+
+* `--no-content, `-g`, `--content`
+
+  Use `--no-content` or `-g` to avoid downloading (and dropping)
+  the content of annexed files, and also prevent doing any migrations of
+  content.
+
+  If you often use `--no-content`, you can set the `annex.synccontent`
+  configuration to false to prevent downloading content by default.
+  The `--content` option overrides that configuration.
+
+  To only prevent only migrations of content, you can set the
+  `annex.syncmigrations` configuration to false.
+  The `--content` option overrides that configuration as well.
+
+* `--content-of=path` `-C path`
+
+  Only download (and drop) annexed files in the given path.
+
+  This option can be repeated multiple times with different paths.
+
+* `--all` `-A`
+
+  Usually this command operates on annexed files in the current branch.
+  This option makes it operate on all available versions of all annexed files
+  (when preferred content settings allow).
+
+  Note that preferred content settings that use `include=` or `exclude=`
+  will only match the version of files currently in the work tree, but not
+  past versions of files.
+
+* `--jobs=N` `-JN`
+
+  Enables parallel pulling with up to the specified number of jobs
+  running at once. For example: `-J10`
+
+  Setting this to "cpus" will run one job per CPU core.
+
+  (Note that git pulls are not done in parallel because that tends to be
+  less efficient.)
+
+* `--allow-unrelated-histories`, `--no-allow-unrelated-histories`
+
+  Passed on to `git merge`, to control whether or not to merge
+  histories that do not share a common ancestor.
+
+* `--resolvemerge`, `--no-resolvemerge`
+
+  By default, merge conflicts are automatically handled by this command. 
+  When two conflicting versions of a file have been committed, both will
+  be added  to the tree, under different filenames. For example, file "foo"
+  would be replaced with "foo.variant-A" and "foo.variant-B". (See
+  [[git-annex-resolvemerge]](1) for details.)
+
+  Use `--no-resolvemerge` to disable this automatic merge conflict
+  resolution. It can also be disabled by setting `annex.resolvemerge`
+  to false.
+
+* `--backend`
+
+  Specifies which key-value backend to use when importing from a
+  special remote. 
+
+* Also the [[git-annex-common-options]](1) can be used.
+  
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-push]](1)
+
+[[git-annex-sync]](1)
+
+[[git-annex-preferred-content]](1)
+
+[[git-annex-satisfy]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-push.mdwn b/doc/git-annex-push.mdwn
new file mode 100644
index 0000000000..30b7123a30
--- /dev/null
+++ b/doc/git-annex-push.mdwn
@@ -0,0 +1,147 @@
+# NAME
+
+git-annex push - push content to remotes
+
+# SYNOPSIS
+
+git annex push `[remote ...]`
+
+# DESCRIPTION
+
+This command pushes content to remotes. It uploads 
+both git repository content, and the content of annexed files.
+
+You can use `git push` and `git-annex copy` by hand to do the same thing as
+this command, but this command handles several details, including making
+sure that the git-annex branch is pushed to the remote.
+
+When using git-annex, often remotes are not bare repositories, because
+it's helpful to add remotes for nearby machines that you want
+to access the same annexed content. Pushing to a non-bare remote will
+not normally update the remote's current branch with changes from the local
+repository. (Unless the remote is configured with
+receive.denyCurrentBranch=updateInstead.)
+
+To make working with such non-bare remotes easier, this command pushes not
+only local `master` to remote `master`, but also to remote `synced/master`
+(and similar with other branches). When `git-annex pull` (or `git-annex
+sync`) is later run on the remote, it will merge the `synced/` branches
+that were pushed to it.
+
+Some special remotes allow exporting a tree of files to them
+(`exporttree=yes`),
+and this command can be used to push to those remotes as well
+as regular git remotes. See [[git-annex-export]](1) for details
+about how those special remotes work. In order for this command to export
+to a special remote, `remote.<name>.annex-tracking-branch` also must
+be configured, and have the same value as the currently checked out branch.
+
+When [[git-annex-adjust]](1) has been used to check out an adjusted branch,
+this command will propagate changes that have been made back to the 
+parent branch, without propagating the adjustments. 
+
+Normally this tries to upload the content of each annexed file that is
+in the working tree, to any remote that it's pushing to that does not have
+a copy. To control which files are uploaded to a remote, configure the preferred
+content of the remote. When a file is not the preferred content of a remote,
+or of the local repository, this command will try to drop the file's content.
+See [[git-annex-preferred-content]](1).
+
+# OPTIONS
+
+* `[remote]`
+
+  By default, this command pushes to all available remotes, except for remotes 
+  that have `remote.<name>.annex-push` (or `remote.<name>.annex-sync`) 
+  set to false or `remote.<name>.annex-readonly` set to true.
+
+  By specifying the names of remotes (or remote groups), you can control which
+  ones to push to.
+
+* `--fast`
+
+  Only push to the remotes with the lowest annex-cost value configured.
+
+  When a list of remotes (or remote groups) is provided, it picks from
+  amoung those, otherwise it picks from amoung all remotes.
+
+* `--only-annex` `-a`, `--not-only-annex`
+
+  Only push the git-annex branch and annexed content to remotes,
+  not other git branches.
+
+  The `annex.synconlyannex` configuration can be set to true to make
+  this be the default behavior. To override such a setting, use
+  `--not-only-annex`.
+
+  When this is combined with --no-content, only the git-annex branch
+  will be pushed.
+
+* `--no-content`, `-g`, `--content`
+
+  Use `--no-content` or `-g` to avoid uploading (and dropping) the content
+  of annexed files.
+
+  If you often use `--no-content`, you can set the `annex.synccontent`
+  configuration to false to prevent uploading content by default.
+  The `--content` option overrides that configuration.
+
+* `--content-of=path` `-C path`
+
+  Only upload (or drop) annexed files in the given path.
+
+  This option can be repeated multiple times with different paths.
+
+  Note that this option is ignored when syncing with "exporttree=yes"
+  remotes.
+
+* `--all` `-A`
+
+  Usually this command operates on annexed files in the current branch.
+  This option makes it operate on all available versions of all annexed files
+  (when preferred content settings allow).
+
+  Note that preferred content settings that use `include=` or `exclude=`
+  will only match the version of files currently in the work tree, but not
+  past versions of files.
+
+* `--jobs=N` `-JN`
+
+  Enables parallel pushing with up to the specified number of jobs
+  running at once. For example: `-J10`
+
+  Setting this to "cpus" will run one job per CPU core.
+
+* `--cleanup`
+
+  Removes the local and remote `synced/` branches, which were created
+  and pushed by `git-annex push` or `git-annex sync`. This option
+  prevents all other activities.
+
+  This can come in handy when you've pushed a change to remotes and now
+  want to reset your master branch back before that change. So you
+  run `git reset` and force-push the master branch to remotes, only
+  to find that the next `git annex merge` or `git annex pull` brings the
+  changes back. Why? Because the `synced/master` branch is hanging
+  around and still has the change in it. Cleaning up the `synced/` branches
+  prevents that problem.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-pull]](1)
+
+[[git-annex-sync]](1)
+
+[[git-annex-preferred-content]](1)
+
+[[git-annex-satisfy]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-readpresentkey.mdwn b/doc/git-annex-readpresentkey.mdwn
new file mode 100644
index 0000000000..1dd7d56edc
--- /dev/null
+++ b/doc/git-annex-readpresentkey.mdwn
@@ -0,0 +1,32 @@
+# NAME
+
+git-annex readpresentkey - read records of where key is present
+
+# SYNOPSIS
+
+git annex readpresentkey `key uuid`
+
+# DESCRIPTION
+
+This plumbing-level command reads git-annex's records about whether
+the specified key's content is present in the remote with the specified
+uuid.
+  
+It exits 0 if the key is recorded to be present and 1 if not.
+
+Note that this does not do an active check to verify if the key
+is present. To do such a check, use [[git-annex-checkpresentkey]](1)
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-registerurl.mdwn b/doc/git-annex-registerurl.mdwn
new file mode 100644
index 0000000000..bf5133b8db
--- /dev/null
+++ b/doc/git-annex-registerurl.mdwn
@@ -0,0 +1,77 @@
+# NAME
+
+git-annex registerurl - registers an url for a key
+
+# SYNOPSIS
+
+git annex registerurl `[key url]`
+
+# DESCRIPTION
+
+This plumbing-level command can be used to register urls where a
+key can be downloaded from.
+
+No verification is performed of the url's contents.
+
+Normally the key is a git-annex formatted key. However, to make it easier
+to use this to add urls, if the key cannot be parsed as a key, and is a
+valid url, an URL key is constructed from the url.
+
+Registering an url also makes git-annex treat the key as present in the
+special remote that claims it. (Usually the web special remote.)
+
+# OPTIONS
+
+* `--remote=name|uuid`
+
+  Indicate that the url is expected to be claimed by the specified remote.
+  If some other remote claims the url instead, registering it will fail.
+
+  Note that `--remote=web` will prevent any other remote from claiming
+  the url.
+
+* `--batch`
+
+  In batch input mode, lines are read from stdin, and each line
+  should contain a key and url, separated by a single space.
+
+  For backwards compatability with old git-annex before this option
+  was added, when no key and url pair are specified on the command line,
+  batch input is used, the same as if the --batch option were
+  specified. It is however recommended to use --batch.
+
+* `-z`
+
+   When in batch mode, the input is delimited by nulls instead of the usual
+   newlines.
+
+   (Note that for this to be used, you have to explicitly enable batch mode
+   with `--batch`)
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-addurl]](1)
+
+[[git-annex-unregisterurl]](1)
+
+[[git-annex-reregisterurl]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-reinit.mdwn b/doc/git-annex-reinit.mdwn
new file mode 100644
index 0000000000..f7c528a0a7
--- /dev/null
+++ b/doc/git-annex-reinit.mdwn
@@ -0,0 +1,52 @@
+# NAME
+
+git-annex reinit - initialize repository, reusing old UUID
+
+# SYNOPSIS
+
+git annex reinit `uuid|description`
+
+# DESCRIPTION
+
+Normally, initializing a repository generates a new, unique identifier
+(UUID) for that repository. Occasionally it may be useful to reuse a
+UUID -- for example, if a repository got deleted, and you're
+setting it back up.
+
+Use this with caution; it can be confusing to have two existing
+repositories with the same UUID. 
+
+Make sure you run `git annex fsck` after changing the UUID of a
+repository to make sure location tracking information is recorded
+correctly.
+
+Like `git annex init`, this attempts to enable any special remotes
+that are configured with autoenable=true.
+
+# OPTIONS
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-init]](1)
+
+[[git-annex-fsck]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-reinject.mdwn b/doc/git-annex-reinject.mdwn
new file mode 100644
index 0000000000..1202d0d339
--- /dev/null
+++ b/doc/git-annex-reinject.mdwn
@@ -0,0 +1,97 @@
+# NAME
+
+git-annex reinject - inject content of file back into annex
+
+# SYNOPSIS
+
+git annex reinject `[src dest]`
+
+git annex reinject --known `[src]`
+
+# DESCRIPTION
+
+Moves the content of the src file or files into the annex.
+Only known file contents will be reinjected. Any unknown src files will
+be left unchanged.
+
+This can be useful if you have obtained the content of a file from
+elsewhere and want to put it in the local annex. For example, if a file's
+content has been lost and you have a backup, you can restore the backup and
+reinject it into your local repository.
+
+There are two ways to use this command. Specifying a src file and the name
+of a dest file (located inside the repository's working tree)
+injects the src file as the content of the dest file.
+
+	git annex reinject /tmp/foo.iso foo.iso
+
+Or the `--known` option can be used to reinject all known src files, without
+needing to specify the dest file.
+
+	git annex reinject --known /tmp/*.iso
+
+# OPTIONS
+
+* `--known`
+
+  With this option, each specified src file is hashed using the default
+  key-value backend (or the one specified with `--backend`), and if git-annex
+  has a record of the resulting key having been in the annex before, the
+  content is reinjected.
+
+  Note that, when using a key-value backend that includes the filename
+  extension in the key, this will only work if the src files have the same
+  extensions as the files with the same content that was originally added
+  to git-annex.
+
+  Note that this will reinject old versions of files that have been
+  modified or deleted from the current git branch.
+  Use [[git-annex-unused]](1) to detect when such old and potentially
+  unused files have been reinjected.
+
+* `--backend`
+
+  Specify the key-value backend to use when checking if a file is known
+  with the `--known` option.
+
+* `--guesskeys`
+
+  With this option, each specified source file is checked to see if it
+  has the name of a git-annex key, and if so it is imported as the content
+  of that key.
+
+  This can be used to pluck git-annex objects out of `lost+found`,
+  as long as the original filename has not been lost,
+  and is particularly useful when using key-value backends that don't hash
+  to the content of a file.
+
+  When the key-value backend does support hashing, the content of the file
+  is verified before importing it.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-add]](1)
+
+[[git-annex-unused]](1)
+
+[[git-annex-fsck]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-reinject/comment_1_070a87e0cb1bbc49088989293334e1fb._comment b/doc/git-annex-reinject/comment_1_070a87e0cb1bbc49088989293334e1fb._comment
new file mode 100644
index 0000000000..07f5ec381e
--- /dev/null
+++ b/doc/git-annex-reinject/comment_1_070a87e0cb1bbc49088989293334e1fb._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Like it's written: annex only"
+ date="2016-10-28T20:40:54Z"
+ content="""
+# Summary
+
+Just to make it explicit: `--known` mode operates on the *annex only*.  If trying to reinject a file that is stored in the regular git part of the repository, and therefore practically known, `git-annex-reinject` will consider it *not known*.
+
+# Context
+
+I'm currently using `git-annex reinject --known` to tidy a pre-git-annex storage.  It gets progressively near-emptied of big files, letting unknown files stand out in the deserted directory hierarchy.
+
+Yet only actually annexed files will get removed.
+
+In my case big files are pictures (NEF, JPG), and regular git files are `xmp` metadata files used by http://darktable.org/ to store processing parameters.  So, all xmp files linger there, whether they were committed in git or not, needing separate handling.
+
+# How to detect if a file is known to regular git repository (not annex).
+
+There must be a number of ways.  I just hacked one:
+
+```
+HASH=$( git hash-object \"$FILEPATH\" )
+if $( git cat-file -e \"$HASH\" )
+then
+        echo \"Known $FILEPATH\"
+else
+        echo \"Unknown $FILEPATH\"
+fi
+```
+
+This can be wrapped into a helper function and used in a `find | ...` one-liner to remove any file already known to git.
+
+## Caveats
+
+`git cat-file` will probably consider known any file actually stored within git objects, even if on an deleted branch or whatever situations where it is not reachable.  As a result, removing files based on this test may well lose information, not immediately, but on some subsequent `git gc`.
+
+Such caveat is not surprising, as regular git content and annexed content have differing \"scopes\"/lifetime.
+
+# Question
+
+Joey, is there an alternative to `git-annex-reinject --known` that considers regular git content, too?  Perhaps it's a pure git issue and therefore not something inside git-annex job?
+
+A quick test of `git-annex-import --clean-duplicates` shows similar behavior.
+
+"""]]
diff --git a/doc/git-annex-reinject/comment_2_d1a04e31fea877ae5fe873fbd01fdcaa._comment b/doc/git-annex-reinject/comment_2_d1a04e31fea877ae5fe873fbd01fdcaa._comment
new file mode 100644
index 0000000000..1a65fc6e01
--- /dev/null
+++ b/doc/git-annex-reinject/comment_2_d1a04e31fea877ae5fe873fbd01fdcaa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="AlbertZeyer"
+ avatar="http://cdn.libravatar.org/avatar/b37d71961a6a5abf9b7184ed77b5a941"
+ subject="Difference to import/add?"
+ date="2021-01-01T21:49:29Z"
+ content="""
+Considering `git annex reinject /tmp/foo.iso foo.iso`, what is the difference to `git import `/tmp/foo.iso` or `cp /tmp/foo.iso; git annex add foo.iso`?
+"""]]
diff --git a/doc/git-annex-reinject/comment_3_2dcdd82efbd6dcac0f3b729d55a09386._comment b/doc/git-annex-reinject/comment_3_2dcdd82efbd6dcac0f3b729d55a09386._comment
new file mode 100644
index 0000000000..aa9f7b4aaf
--- /dev/null
+++ b/doc/git-annex-reinject/comment_3_2dcdd82efbd6dcac0f3b729d55a09386._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2021-01-02T15:16:04Z"
+ content="""
+The difference of `git annex reinject` to (`git annex import` or `cp/mv; git annex add`) is that only known file contents will be reinjected.
+"""]]
diff --git a/doc/git-annex-rekey.mdwn b/doc/git-annex-rekey.mdwn
new file mode 100644
index 0000000000..aefa820dfb
--- /dev/null
+++ b/doc/git-annex-rekey.mdwn
@@ -0,0 +1,59 @@
+# NAME
+
+git-annex rekey - change keys used for files
+
+# SYNOPSIS
+
+git annex rekey `[file key ...]`
+
+# DESCRIPTION
+
+This plumbing-level command is similar to migrate, but you specify
+both the file, and the new key to use for it.
+
+Multiple pairs of file and key can be given in a single command line.
+
+Note that, unlike `git-annex migrate`, this does not copy over metadata,
+urls, and other such information from the old to the new key
+
+# OPTIONS
+
+* `--force`
+
+  Allow rekeying of even files whose content is not currently available.
+  Use with caution.
+
+* `--batch`
+
+  Enables batch mode, in which lines are read from stdin.
+  Each line should contain the file, and the new key to use for that file,
+  separated by a single space.
+
+* `-z`
+
+  Makes the `--batch` input be delimited by nulls instead of the usual
+  newlines.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-migrate]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-remotedaemon.mdwn b/doc/git-annex-remotedaemon.mdwn
new file mode 100644
index 0000000000..8fecee287c
--- /dev/null
+++ b/doc/git-annex-remotedaemon.mdwn
@@ -0,0 +1,58 @@
+# NAME
+
+git-annex remotedaemon - persistent communication with remotes
+
+# SYNOPSIS
+
+git annex remotedaemon
+
+# DESCRIPTION
+
+The remotedaemon provides persistent communication with remotes.
+
+Several types of remotes are supported:
+
+For ssh remotes, the remotedaemon tries to maintain a connection to the
+remote git repository, and uses git-annex-shell notifychanges to detect
+when the remote git repository has changed, and fetches changes from it.
+For this to work, the git remote must have [[git-annex-shell]](1)
+installed, with notifychanges support. The first version of git-annex-shell
+that supports it is 5.20140405.
+
+For tor-annex remotes, the remotedaemon runs a tor hidden service,
+accepting connections from other nodes and serving up the contents of the
+repository. This is only done if you first run `git annex enable-tor`.
+Use `git annex p2p` to configure access to tor-annex remotes.
+
+Note that when `remote.<name>.annex-pull` is set to false, the remotedaemon
+will avoid fetching changes from that remote.
+
+# OPTIONS
+
+* `--foreground`
+
+  Don't fork to the background, and communicate on stdin/stdout using a
+  simple textual protocol. The assistant runs the remotedaemon this way.
+
+  Commands in the protocol include LOSTNET, which tells the remotedaemon
+  that the network connection has been lost, and causes it to stop any TCP
+  connctions. That can be followed by RESUME when the network connection
+  comes back up.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-assistant]](1)
+
+[[git-annex-enable-tor]](1)
+
+[[git-annex-p2p]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-renameremote.mdwn b/doc/git-annex-renameremote.mdwn
new file mode 100644
index 0000000000..7db88ce8c8
--- /dev/null
+++ b/doc/git-annex-renameremote.mdwn
@@ -0,0 +1,47 @@
+# NAME
+
+git-annex renameremote - changes name of a special remote
+
+# SYNOPSIS
+
+git annex renameremote `name|uuid|desc newname`
+
+# DESCRIPTION
+
+Changes the name that is used to enable a special remote.
+
+Normally the current name is used to identify the special remote to rename, 
+but its uuid or description can also be used.
+
+This is especially useful when an old special remote used a name, and now you
+want to use that name for a new special remote. `git annex initremote`
+won't let you create a remote with a conflicting name, so rename the old
+remote first.
+
+	git annex renameremote phone lost-phone
+	git annex initremote phone ...
+
+This only updates the name that git-annex has stored for use 
+by `git annex enableremote`. It does not update the git config stanza
+for the special remote to use the new name, but of course you can edit
+the git config if you want to rename it there.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-initremote]](1)
+
+[[git-annex-enableremote]](1)
+
+[[git-annex-configremote]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-repair.mdwn b/doc/git-annex-repair.mdwn
new file mode 100644
index 0000000000..88359a2d4b
--- /dev/null
+++ b/doc/git-annex-repair.mdwn
@@ -0,0 +1,59 @@
+# NAME
+
+git-annex repair - recover broken git repository
+
+# SYNOPSIS
+
+git annex repair
+
+# DESCRIPTION
+
+This can repair many of the problems with git repositories that `git fsck`
+detects, but does not itself fix. It's useful if a repository has become
+badly damaged. One way this can happen is if a repository used by git-annex
+is on a removable drive that gets unplugged at the wrong time.
+  
+This command can actually be used inside git repositories that do not
+use git-annex at all; when used in a repository using git-annex, it
+does additional repairs of the git-annex branch.
+  
+It works by deleting any corrupt objects from the git repository, and
+retrieving all missing objects it can from the remotes of the repository.
+  
+If that is not sufficient to fully recover the repository, it can also
+reset branches back to commits before the corruption happened, delete
+branches that are no longer available due to the lost data, and remove any
+missing files from the index. It will only do this if run with the
+`--force` option, since that rewrites history and throws out missing data.
+Note that the `--force` option never touches tags, even if they are no
+longer usable due to missing data.
+  
+After running this command, you will probably want to run `git fsck` to
+verify it fixed the repository. Note that fsck may still complain about
+objects referenced by the reflog, or the stash, if they were unable to be
+recovered. This command does not try to clean up either the reflog or the
+stash.
+  
+It is also a good idea to run `git annex fsck --fast` after this command,
+to make sure that the git-annex branch reflects reality.
+
+# OPTIONS
+
+* `--force`
+
+  Enable repair actions that involve deleting data that has been
+  lost due to git repository corruption.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-fsck]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-repair/comment_1_088ce57c74a653478e03968e1d6bba23._comment b/doc/git-annex-repair/comment_1_088ce57c74a653478e03968e1d6bba23._comment
new file mode 100644
index 0000000000..339fe0262b
--- /dev/null
+++ b/doc/git-annex-repair/comment_1_088ce57c74a653478e03968e1d6bba23._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="When a weird 'no space left on device' error appears"
+ date="2022-12-21T16:46:44Z"
+ content="""
+When you run into weird `no space left on device` errors although there clearly **is** enough room on your disk while running `git annex repair`, it probably means that your `/tmp` is too small (You can verify with `watch -n0 df -h` or just `df -h`). You can instruct `git annex repair` to use a different directory for intermediate storage via the `TMPDIR` environment variable:
+
+```bash
+mkdir /path/to/dir/with/enough/space
+TMPDIR=/path/to/dir/with/enough/space git annex repair
+# Now that new dir is used and the 'no space left on device' error should disappear
+```
+
+Might be worth adding a note for `TMPDIR` to the `git annex repair` manpage, @joey?
+"""]]
diff --git a/doc/git-annex-required.mdwn b/doc/git-annex-required.mdwn
new file mode 100644
index 0000000000..bf9535cc43
--- /dev/null
+++ b/doc/git-annex-required.mdwn
@@ -0,0 +1,49 @@
+# NAME
+
+git-annex required - get or set required content expression
+
+# SYNOPSIS
+
+git annex required `repository [expression]`
+
+# DESCRIPTION
+
+When run with an expression, configures the content that is required
+to be held in the archive.
+
+For example:
+
+	git annex required . "include=*.mp3 or include=*.ogg"
+
+Without an expression, displays the current required content setting
+of the repository.
+
+While [[git-annex-wanted]](1) is just a preference, this designates content
+that should really not be removed. For example a file that is `wanted` can
+be removed with `git annex drop`, but if that file is `required`, it would
+need to be removed with `git annex drop --force`. 
+
+Also, `git-annex fsck` will warn about required contents that are not
+present.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# NOTES
+
+The `required` command was added in git-annex 5.20150420.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-wanted]](1)
+
+[[git-annex-preferred-content]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-reregisterurl.mdwn b/doc/git-annex-reregisterurl.mdwn
new file mode 100644
index 0000000000..c22a0c6e98
--- /dev/null
+++ b/doc/git-annex-reregisterurl.mdwn
@@ -0,0 +1,64 @@
+# NAME
+
+git-annex reregisterurl - updates url registration information
+
+# SYNOPSIS
+
+git annex reregisterurl `[key]`
+
+# DESCRIPTION
+
+This plumbing-level command updates information about the urls that are
+registered for a key.
+
+# OPTIONS
+
+* `--move-from=name|uuid`
+
+  For each key, update any urls that are currently claimed by the
+  specified remote to be instead used by the web special remote.
+
+  This could be used eg, when a special remote was needed to provide
+  authorization to get an url, but the url has now become publically
+  available and so the web special remote can be used.
+
+  Note that, like `git-annex unregisterurl`, using this option unregisters
+  an url from a special remote, but it does not mark the content as not
+  present in that special remote. However, like `git-annex registerurl`,
+  this option does mark content as being present in the web special remote.
+
+* `--batch`
+
+  In batch input mode, lines are read from stdin, and each line
+  should contain a key.
+
+* `-z`
+
+   When in batch mode, the input is delimited by nulls instead of the usual
+   newlines.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-registerurl]](1)
+
+[[git-annex-unregisterurl]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-resolvemerge.mdwn b/doc/git-annex-resolvemerge.mdwn
new file mode 100644
index 0000000000..ca057d6de4
--- /dev/null
+++ b/doc/git-annex-resolvemerge.mdwn
@@ -0,0 +1,70 @@
+# NAME
+
+git-annex resolvemerge - resolve merge conflicts
+
+# SYNOPSIS
+
+git annex resolvemerge
+
+# DESCRIPTION
+
+Automatically resolves a conflicted merge. This is done
+automatically when using `git annex sync` or `git annex merge`.
+
+When two trees being merged contain conflicting versions of an annexed
+file, the merge conflict will be resolved by adding both versions to the
+tree, using variants of the filename.
+
+When one tree modified the file, and the other tree deleted the file,
+the merge conflict will be resolved by adding the modified file using a
+variant of the filename, leaving the original filename deleted.
+
+When the merge conflict involves a file that is annexed in one
+tree, but is not annexed in the other tree, it is
+resolved by keeping the non-annexed file as-is, and adding the annexed
+version using a variant of the filename.
+
+Note that only merge conflicts that involve one or more annexed files
+are resolved. Merge conflicts between two files that are not annexed
+will not be automatically resolved.
+
+# EXAMPLES
+
+Suppose Alice commits a change to annexed file `foo`, and Bob commits
+a different change to the same file `foo`. 
+
+Merging between them will then fail, and git will present the
+merge conflict as a file `foo` pointing to one version of the
+git-annex symlink, with `git status` indicating that `foo` has an
+unresolved conflict.
+
+Running `git annex resolvemerge` in this situation will resolve the merge
+conflict, by replacing the file `foo` with files named like
+`foo.variant-c696` and `foo.variant-f16a`. One of the files has the content
+that Alice committed, and the other has the content that Bob committed.
+
+The user can then examine the two variants of the file, and either merge
+the two changes into a single file, or rename one of them back to `foo`
+and delete the other.
+
+Now suppose Alice commits a change to annexed file `bar`, while Bob commits
+a deletion of the same file `bar`. Merging will fail. Running 
+`git annex resolvemerge` in this situation will resolve the merge conflict
+by making a file with a name like `bar.variant-421f` containing Alice's
+version. The `bar` file remains deleted. The user can later examine the
+variant of the file and either rename it back to `bar`, or decide to delete
+it too.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-restage.mdwn b/doc/git-annex-restage.mdwn
new file mode 100644
index 0000000000..11d69142c3
--- /dev/null
+++ b/doc/git-annex-restage.mdwn
@@ -0,0 +1,34 @@
+# NAME
+
+git-annex restage - restages unlocked files in the git index
+
+# SYNOPSIS
+
+git annex restage
+
+# DESCRIPTION
+
+Since getting or dropping an unlocked file modifies the file in the work
+tree, git needs to be told that the modification does not change the
+content that it has recorded (the annex pointer). Restaging the file
+accomplishes that.
+
+You do not normally need to run this command, because usually git-annex
+is able to restage unlocked files itself. There are some situations
+where git-annex needs to restage a file, but the git index is locked,
+and so it cannot. It will then display a warning suggesting you run this
+command.
+
+It's safe to run this command even after you have made a modification to an
+unlocked file.
+
+# SEE ALSO
+
+[[git-annex]](1)
+[[git-annex-smudge]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-rmurl.mdwn b/doc/git-annex-rmurl.mdwn
new file mode 100644
index 0000000000..8203b8ad97
--- /dev/null
+++ b/doc/git-annex-rmurl.mdwn
@@ -0,0 +1,53 @@
+# NAME
+
+git-annex rmurl - record file is not available at url
+
+# SYNOPSIS
+
+git annex rmurl `[file url ..]`
+
+# DESCRIPTION
+
+Record that the file is no longer available at the url.
+
+Removing the last web url will make git-annex no longer treat content as being
+present in the web special remote. If some other special remote
+claims the url, unregistering the url will not update presence information
+for it, because the content may still be present on the remote.
+
+# OPTIONS
+
+* `--batch`
+
+  Enables batch mode, in which lines are read from stdin.
+  Each line should contain the file, and the url to remove from that file,
+  separated by a single space.
+
+* `-z`
+
+  Makes the `--batch` input be delimited by nulls instead of the usual
+  newlines.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-addurl]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-rmurl/comment_1_fc99b7e905c81183f78320af266ae1a5._comment b/doc/git-annex-rmurl/comment_1_fc99b7e905c81183f78320af266ae1a5._comment
new file mode 100644
index 0000000000..2299fd0c35
--- /dev/null
+++ b/doc/git-annex-rmurl/comment_1_fc99b7e905c81183f78320af266ae1a5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-09-19T03:40:05Z"
+ content="""
+After doing rmurl to remove the last URL at which a file is available, 'git annex whereis filename' still shows 'web' as having one of the copies.  Bug?
+"""]]
diff --git a/doc/git-annex-rmurl/comment_2_181581caac6ee439ba1003ebca79ed09._comment b/doc/git-annex-rmurl/comment_2_181581caac6ee439ba1003ebca79ed09._comment
new file mode 100644
index 0000000000..7c7e9b5413
--- /dev/null
+++ b/doc/git-annex-rmurl/comment_2_181581caac6ee439ba1003ebca79ed09._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-10-04T18:47:14Z"
+ content="""
+rmurl should mark the content as not being present in the web special
+remote once the last url is removed, and it does when I tested it just now.
+
+There was a recent bug, now fixed, that prevented it doing that in some unusual
+circumstances.
+"""]]
diff --git a/doc/git-annex-satisfy.mdwn b/doc/git-annex-satisfy.mdwn
new file mode 100644
index 0000000000..1ed4ec543d
--- /dev/null
+++ b/doc/git-annex-satisfy.mdwn
@@ -0,0 +1,74 @@
+# NAME
+
+git-annex satisfy - transfer and drop content as configured
+
+# SYNOPSIS
+
+git annex satisfy `[remote ...]`
+
+# DESCRIPTION
+
+This transfers and drops content of annexed files to work toward satisfying
+the preferred content settings of the local repository and remotes.
+
+It does the same thing as `git-annex sync --content` without the pulling
+and pushing of git repositories, and without changing the trees that are
+imported to or exported from special remotes.
+
+Note that it (like [[git-annex-sync]] or [[git-annex-assist]]) does not work
+specifically towards satisfying the [[git-annex-numcopies]] setting,
+unless the preferred content setting of the local repository is written to
+do so by using eg `approxlackingcopies=1`.
+
+# OPTIONS
+
+* `[remote]`
+
+  By default this command operates on all remotes, except for remotes
+  that have `remote.<name>.annex-sync` set to false.
+
+  By specifying the names of remotes (or remote groups), you can control
+  which ones to operate on.
+
+* `--content-of=path` `-C path`
+
+  Operate on only files in the specified path. The default is to operate on
+  all files in the working tree.
+
+  This option can be repeated multiple times with different paths.
+
+  Note that this option is ignored when syncing with "exporttree=yes"
+  remotes.
+
+* `--jobs=N` `-JN`
+
+  Enables parallel processing with up to the specified number of jobs
+  running at once. For example: `-J10`
+
+  Setting this to "cpus" will run one job per CPU core.
+
+* `--all` `-A`
+
+  Usually this command operates on annexed files in the current branch.
+  This option makes it operate on all available versions of all annexed files
+  (when preferred content settings allow).
+
+  Note that preferred content settings that use `include=` or `exclude=`
+  will only match the version of files currently in the work tree, but not
+  past versions of files.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-sync]](1)
+
+[[git-annex-preferred-content]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-schedule.mdwn b/doc/git-annex-schedule.mdwn
new file mode 100644
index 0000000000..c55bb9f61f
--- /dev/null
+++ b/doc/git-annex-schedule.mdwn
@@ -0,0 +1,55 @@
+# NAME
+
+git-annex schedule - get or set scheduled jobs
+
+# SYNOPSIS
+
+git annex schedule `repository [expression]`
+
+# DESCRIPTION
+
+The [[git-annex-assistant]](1) daemon can be configured to run scheduled jobs.
+This is similar to cron and anacron (and you can use them if you prefer),
+but has the advantage of being integrated into git-annex, and so being able
+to e.g., fsck a repository on a removable drive when the drive gets
+connected.
+
+When run with an expression, configures scheduled jobs to run at a
+particular time. This can be used to make the assistant periodically run
+incremental fscks.
+
+When run without an expression, outputs the current scheduled jobs for
+the repository.
+
+# EXPRESSIONS
+
+These actions are available: "fsck self", "fsck UUID" (where UUID
+is the UUID of a remote to fsck). After the action comes the duration
+to allow the action to run, and finally the schedule of when to run it.
+  
+To schedule multiple jobs, separate them with "; ".
+  
+  Some examples:
+  
+	fsck self 30m every day at any time
+	fsck self 1h every month at 3 AM
+	fsck self 1h on day 1 of every month at any time
+	fsck self 1h every week divisible by 2 at any time
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-assistant]](1)
+
+[[git-annex-expire]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-semitrust.mdwn b/doc/git-annex-semitrust.mdwn
new file mode 100644
index 0000000000..5efce9cb11
--- /dev/null
+++ b/doc/git-annex-semitrust.mdwn
@@ -0,0 +1,46 @@
+# NAME
+
+git-annex semitrust - return repository to default trust level
+
+# SYNOPSIS
+
+git annex semitrust `[repository ...]`
+
+# DESCRIPTION
+
+Returns a repository to the default semi trusted state.
+
+Repositories can be specified using their remote name, their
+description, or their UUID. For the current repository, use "here".
+
+# OPTIONS
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-trust]](1)
+
+[[git-annex-untrust]](1)
+
+[[git-annex-dead]](1)
+
+[[git-annex-expire]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-setkey.mdwn b/doc/git-annex-setkey.mdwn
new file mode 100644
index 0000000000..f2562eb33d
--- /dev/null
+++ b/doc/git-annex-setkey.mdwn
@@ -0,0 +1,33 @@
+# NAME
+
+git-annex setkey - sets annexed content for a key
+
+# SYNOPSIS
+
+git annex setkey key file
+
+# DESCRIPTION
+
+This plumbing-level command makes the content of the specified key
+be set to the specified file. The file is moved into the annex.
+
+It's generally a better idea to use [[git-annex-reinject]](1) instead of
+this command.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-reinject]](1)
+
+[[git-annex-dropkey]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-setpresentkey.mdwn b/doc/git-annex-setpresentkey.mdwn
new file mode 100644
index 0000000000..b12d7f36b7
--- /dev/null
+++ b/doc/git-annex-setpresentkey.mdwn
@@ -0,0 +1,44 @@
+# NAME
+
+git-annex setpresentkey - change records of where key is present
+
+# SYNOPSIS
+
+git annex setpresentkey `key uuid [1|0]`
+
+# DESCRIPTION
+
+This plumbing-level command changes git-annex's records about whether
+the specified key's content is present in a remote with the specified uuid.
+
+Use 1 to indicate the key is present, or 0 to indicate the key is
+not present.
+
+# OPTIONS
+
+* `--batch`
+
+  Enables batch mode, in which lines are read from stdin.
+  The line format is "key uuid [1|0]"
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-setpresentkey/comment_1_58c98aafb5f6c20c6b71126cd17d3a40._comment b/doc/git-annex-setpresentkey/comment_1_58c98aafb5f6c20c6b71126cd17d3a40._comment
new file mode 100644
index 0000000000..c615df5a88
--- /dev/null
+++ b/doc/git-annex-setpresentkey/comment_1_58c98aafb5f6c20c6b71126cd17d3a40._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-10-04T21:16:29Z"
+ content="""
+Is there a way to say the key exists in an export remote at a given path?
+"""]]
diff --git a/doc/git-annex-setpresentkey/comment_2_57b0ae8a49df6c8809aa3050610191b2._comment b/doc/git-annex-setpresentkey/comment_2_57b0ae8a49df6c8809aa3050610191b2._comment
new file mode 100644
index 0000000000..e524ff352d
--- /dev/null
+++ b/doc/git-annex-setpresentkey/comment_2_57b0ae8a49df6c8809aa3050610191b2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-10-04T21:38:41Z"
+ content="""
+That's not the same information that this command deals with. There is the
+per-remote metadata log, which some export remotes (currently S3) can 
+use to keep track of whatever information is needed to access a given
+file that was exported to them.
+"""]]
diff --git a/doc/git-annex-setpresentkey/comment_3_30a5d3fbd8e02726989ab80ed98b4a54._comment b/doc/git-annex-setpresentkey/comment_3_30a5d3fbd8e02726989ab80ed98b4a54._comment
new file mode 100644
index 0000000000..c84e4f8545
--- /dev/null
+++ b/doc/git-annex-setpresentkey/comment_3_30a5d3fbd8e02726989ab80ed98b4a54._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-10-08T16:24:59Z"
+ content="""
+@Ilya_Shlyakhter the way export tree remotes work is git-annex keeps track
+of the tree object that corresponds to the state of the remote, as well
+as the usual presense tracking information. It uses the presense tracking
+to know which files in the tree have reached the remote, and the tree to
+work out the path to a file on the remote.
+
+So the only way to manipulate its tracking for those is to update the tree
+that it has recorded as exported there, as well as the presence information
+this command is about. [[internals]] has the details for the export.log.
+"""]]
diff --git a/doc/git-annex-setpresentkey/comment_4_df3018b9b3491963311063e8ff202df4._comment b/doc/git-annex-setpresentkey/comment_4_df3018b9b3491963311063e8ff202df4._comment
new file mode 100644
index 0000000000..a7f423a48a
--- /dev/null
+++ b/doc/git-annex-setpresentkey/comment_4_df3018b9b3491963311063e8ff202df4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2018-10-08T21:43:17Z"
+ content="""
+@joey thanks.  But, besides export.log, the S3 remote also keeps some (undocumented?) internal state, and there's not way to update that state to record the fact that git-annex can GET a given key by downloading s3://mybucket/myobject ?  Also, I feel uneasy directly manipulating git-annex internal files.  Can you think of any plumbing commands, that could be added to support this use case?
+The use case is, I submit a batch job that takes as input some s3:// objects, writes outputs to other s3:// objects, and returns pointers to these new s3:// objects.  I want to register these new objects in git-annex, initially without downloading them, but be able to git-annex-get these objects, drop them from the S3 remote, but later be able to put them back under their original s3:// URIs.  The latter ability is needed because (1) many workflows expect filenames to be in a particular form, e.g. mysamplename.pN.bam to represent mysample processed with parameter p=N; and (2) some workflow engines can reuse past results if a step is re-run with the same inputs, but they need the results to be at the same s3:// URI as when the step was first run.
+"""]]
diff --git a/doc/git-annex-shell.mdwn b/doc/git-annex-shell.mdwn
new file mode 100644
index 0000000000..4224c40f6f
--- /dev/null
+++ b/doc/git-annex-shell.mdwn
@@ -0,0 +1,194 @@
+# NAME
+
+git-annex-shell - Restricted login shell for git-annex only SSH access
+
+# SYNOPSIS
+
+git-annex-shell [-c] command [params ...]
+
+# DESCRIPTION
+
+git-annex-shell is a restricted shell, similar to git-shell, which
+can be used as a login shell for SSH accounts.
+
+Since its syntax is identical to git-shell's, it can be used as a drop-in
+replacement anywhere git-shell is used. For example it can be used as a 
+user's restricted login shell.
+
+# COMMANDS
+
+Any command not listed below is passed through to git-shell.
+
+Note that the directory parameter should be an absolute path, otherwise
+it is assumed to be relative to the user's home directory. Also the
+first "/~/" or "/~user/" is expanded to the specified home directory.
+
+* configlist directory
+
+  This outputs a subset of the git configuration, in the same form as
+  `git config --list`. This is used to get the annex.uuid of the remote
+  repository.
+
+  When run in a repository that does not yet have an annex.uuid, one
+  will be created, as long as a git-annex branch has already been pushed to
+  the repository, or if the autoinit=1 flag is used to indicate
+  initialization is desired.
+
+* p2pstdio directory uuid
+
+  This causes git-annex-shell to communicate using the git-annex p2p
+  protocol over stdio.
+
+  The uuid is the one belonging to the repository that will be
+  communicating with git-annex-shell.
+
+* notifychanges directory
+
+  This is used by `git-annex remotedaemon` to be notified when
+  refs in the remote repository are changed.
+
+* gcryptsetup directory gcryptid
+
+  Sets up a repository as a gcrypt repository.
+
+* inannex directory [key ...]
+
+  This checks if all specified keys are present in the annex, 
+  and exits zero if so.
+
+  Exits 1 if the key is certainly not present in the annex.
+  Exits 100 if it's unable to tell (perhaps the key is in the process of
+  being removed from the annex).
+  
+  Used only by the gcrypt special remote.
+
+* recvkey directory key
+
+  This runs rsync in server mode to receive the content of a key,
+  and stores the content in the annex.
+  
+  Used only by the gcrypt special remote.
+
+* sendkey directory key
+
+  This runs rsync in server mode to transfer out the content of a key.
+  
+  Used only by the gcrypt special remote.
+
+* dropkey directory [key ...]
+
+  This drops the annexed data for the specified keys.
+  
+  Used only by the gcrypt special remote.
+
+# OPTIONS
+
+* --uuid=UUID
+
+  git-annex uses this to specify the UUID of the repository it was expecting
+  git-annex-shell to access, as a sanity check.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+* -- fields=val fields=val.. --
+
+  Additional fields may be specified this way, to retain compatibility with
+  past versions of git-annex-shell (that ignore these, but would choke
+  on new dashed options).
+
+  Currently used fields are autoinit= and remoteuuid=
+
+# HOOK
+
+After content is received or dropped from the repository by git-annex-shell,
+it runs a hook, `.git/hooks/annex-content` (or `hooks/annex-content` on a bare
+repository). The hook is not currently passed any information about what
+changed.
+
+# ENVIRONMENT
+
+* GIT_ANNEX_SHELL_READONLY
+
+  If set, disallows any action that could modify the git-annex 
+  repository.
+
+  Note that this does not prevent passing commands on to git-shell.
+  For that, you also need ...
+
+* GIT_ANNEX_SHELL_LIMITED
+
+  If set, disallows running git-shell to handle unknown commands.
+
+* GIT_ANNEX_SHELL_APPENDONLY
+
+  If set, allows data to be written to the git-annex repository,
+  but does not allow data to be removed from it.
+
+  Note that this does not prevent passing commands on to git-shell,
+  so you will have to separately configure git to reject pushes that
+  overwrite branches or are otherwise not appends. The git pre-receive
+  hook may be useful for accomplishing this.
+
+  It's a good idea to enable annex.securehashesonly in a repository
+  that's set up this way.
+
+* GIT_ANNEX_SHELL_DIRECTORY
+
+  If set, git-annex-shell will refuse to run commands that do not operate
+  on the specified directory.
+
+# EXAMPLES
+
+To make a `~/.ssh/authorized_keys` file that only allows git-annex-shell
+to be run, and not other commands, pass the original command to the -c
+option:
+    
+	command="git-annex-shell -c \"$SSH_ORIGINAL_COMMAND\"",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB3NzaC1y[...] user@example.com
+
+To further restrict git-annex-shell to a particular repository, 
+and fully lock it down to read-only mode:
+
+	command="GIT_ANNEX_SHELL_DIRECTORY=/srv/annex GIT_ANNEX_SHELL_LIMITED=true GIT_ANNEX_SHELL_READONLY=true git-annex-shell -c \"$SSH_ORIGINAL_COMMAND\"",restrict ssh-rsa AAAAB3NzaC1y[...] user@example.com
+
+Obviously, `ssh-rsa AAAAB3NzaC1y[...] user@example.com` needs to
+replaced with your SSH key. The above also assumes `git-annex-shell`
+is available in your `$PATH`, use an absolute path if it is not the
+case. Also note how the above uses the `restrict` option instead of an
+explicit list of functionality to disallow. This only works in certain
+OpenSSH releases, starting from 7.1p2.
+
+To only allow adding new objects to the repository, the
+`GIT_ANNEX_SHELL_APPENDONLY` variable can be used as well:
+
+    command="GIT_ANNEX_SHELL_DIRECTORY=/srv/annex GIT_ANNEX_SHELL_APPENDONLY=true git-annex-shell -c \"$SSH_ORIGINAL_COMMAND\"",restrict ssh-rsa AAAAB3NzaC1y[...] user@example.com
+
+This will not keep an attacker from destroying the git history, as
+explained above. For this you might want to disallow certain
+operations, like branch deletion and force-push, with options from
+git-config(1). For example:
+
+    git config receive.denyDeletes true
+    git config receive.denyNonFastForwards true
+
+With this configuration, git commits can still remove files, 
+but they will still be available in the git history and git-annex will
+retain their contents. Changes to `git-annex` branch, however, can
+negatively impact git-annex's location tracking information and might
+cause data loss. To work around this problem, more complex hooks
+are required, see for example the `update-paranoid` hook in the git
+source distribution.
+
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+git-shell(1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+<http://git-annex.branchable.com/>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care
diff --git a/doc/git-annex-smudge.mdwn b/doc/git-annex-smudge.mdwn
new file mode 100644
index 0000000000..6f6eba8140
--- /dev/null
+++ b/doc/git-annex-smudge.mdwn
@@ -0,0 +1,66 @@
+# NAME
+
+git-annex smudge - git filter driver for git-annex
+
+# SYNOPSIS
+
+git annex smudge [--clean] file
+
+git annex smudge --update
+
+# DESCRIPTION
+
+This command lets git-annex be used as a git filter driver which lets
+annexed files in the git repository to be unlocked, instead
+of being symlinks, and lets `git add` store files in the annex.
+
+When adding a file with `git add`, the annex.largefiles config is
+consulted to decide if a given file should be added to git as-is,
+or if its content are large enough to need to use git-annex.
+The annex.gitaddtoannex setting overrides that; setting it to false
+prevents `git add` from adding files to the annex.
+
+However, if git-annex can tell that a file was annexed before,
+it will still be added to the annex even when those configs would normally
+prevent it. Two examples of this are adding a modified version of an
+annexed file, and moving an annexed file to a new filename and adding that.
+
+The git configuration to use this command as a filter driver is as follows.
+This is normally set up for you by git-annex init, so you should
+not need to configure it manually.
+
+	[filter "annex"]
+	        smudge = git-annex smudge %f
+	        clean = git-annex smudge --clean %f
+
+To make git use that filter driver, it needs to be configured in
+the `.gitattributes` file or in `.git/info/attributes`. The latter
+is normally configured when a repository is initialized, with the following
+contents:
+
+	* filter=annex
+
+The smudge filter does not provide git with the content of annexed files,
+because that would be slow and triggers memory leaks in git. Instead,
+it records which worktree files need to be updated, and 
+`git annex smudge --update` later updates the work tree to contain
+the content. That is run by several git hooks, including post-checkout
+and post-merge. However, a few git commands, notably `git stash` and
+`git cherry-pick`, do not run any hooks, so after using those commands
+you can manually run `git annex smudge --update` to update the working
+tree.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+[[git-annex-filter-process]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-status.mdwn b/doc/git-annex-status.mdwn
new file mode 100644
index 0000000000..962fda51d4
--- /dev/null
+++ b/doc/git-annex-status.mdwn
@@ -0,0 +1,46 @@
+# NAME
+
+git-annex status - show the working tree status (deprecated)
+
+# SYNOPSIS
+
+git annex status `[path ...]`
+
+# DESCRIPTION
+
+Similar to `git status --short`, this command displays the status of the files
+in the working tree. 
+
+Show files that are not checked into git (?), deleted (D),
+modified (M), added but not committed (A), and type changed/unlocked (T).
+
+# OPTIONS
+
+* `--ignore-submodules=when`
+
+  This option is passed on to git status, see its man page for
+  details.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+git-status(1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-sync.mdwn b/doc/git-annex-sync.mdwn
new file mode 100644
index 0000000000..6c7235ddf7
--- /dev/null
+++ b/doc/git-annex-sync.mdwn
@@ -0,0 +1,92 @@
+# NAME
+
+git-annex sync - synchronize local repository with remotes
+
+# SYNOPSIS
+
+git annex sync `[remote ...]`
+
+# DESCRIPTION
+
+This command synchronizes the local repository with its remotes.
+
+This command first commits any local changes to files that have
+previously been added to the repository. Then it does the equivilant of
+[[git-annex-pull]](1) followed by [[git-annex-push]](1).
+
+However, unlike those commands, this command does not transfer annexed
+content by default. That will change in a future version of git-annex,
+when syncing with repositories that have preferred content configured.
+
+# OPTIONS
+
+* `--content`, `--no-content`, `-g`
+
+  The --content option causes the content of annexed files
+  to also be pulled and pushed.
+
+  The --no-content and -g options cause the content of annexed files to
+  not be pulled and pushed.
+
+  The `annex.synccontent` configuration can be set to true to make
+  `--content` be enabled by default.
+
+* `--content-of=path` `-C path`
+
+  This option causes the content of annexed files in the given
+  path to also be pulled and pushed.
+
+  This option can be repeated multiple times with different paths.
+
+  Note that this option does not prevent exporting other files to an 
+  "exporttree=yes" remote.
+
+* `--commit`, `--no-commit`
+
+  A commit is done by default (unless `annex.autocommit` is set to false).
+  
+  Use --no-commit to avoid committing local changes.
+
+* `--message=msg` `-m msg`
+
+  Use this option to specify a commit message.
+
+  If multiple -m options are given, their values are concatenated
+  as separate paragraphs.
+
+* `--pull`, `--no-pull`
+
+  Use this option to disable pulling.
+
+  When `remote.<name>.annex-sync` is set to false, pulling is disabled
+  for that remote, and using `--pull` will not enable it.
+
+* `--push`, `--no-push` 
+
+  Use this option to disable pushing.
+  
+  When `remote.<name>.annex-sync` is set to false, pushing is disabled for
+  that remote, and using `--push` will not enable it.
+
+* Also all options supported by [[git-annex-pull]](1) and
+  [[git-annex-push]](1) can be used.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-pull]](1)
+
+[[git-annex-push]](1)
+
+[[git-annex-assist]](1)
+
+[[git-annex-satisfy]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-sync/comment_1_2e12ed1c1a594dfbd06a3f25f5e25e57._comment b/doc/git-annex-sync/comment_1_2e12ed1c1a594dfbd06a3f25f5e25e57._comment
new file mode 100644
index 0000000000..bf881064d2
--- /dev/null
+++ b/doc/git-annex-sync/comment_1_2e12ed1c1a594dfbd06a3f25f5e25e57._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="when push fails due to non-fast-forward merge, pull and retry?"
+ date="2018-09-12T17:56:40Z"
+ content="""
+When a push would result in a non-fast-forward merge, git-annex-sync currently fails.  Maybe instead, pull and retry pushing?  This happens in the context of several processes trying to push to the same git-annex repo.
+
+Also, the docs mention synced/master, but it's synced/current-branch.
+"""]]
diff --git a/doc/git-annex-sync/comment_2_cc11f83a06352e5049dcbc588d216f27._comment b/doc/git-annex-sync/comment_2_cc11f83a06352e5049dcbc588d216f27._comment
new file mode 100644
index 0000000000..cc9eac7301
--- /dev/null
+++ b/doc/git-annex-sync/comment_2_cc11f83a06352e5049dcbc588d216f27._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-10-04T19:07:09Z"
+ content="""
+git-annex sync pulls before pushing. If another push occurs at the same
+time, the push might fail, but retrying the pull will not avoid that same
+situation occurring again. I don't think it makes sense for git-annex sync
+to retry an arbitrary number of times.
+"""]]
diff --git a/doc/git-annex-sync/comment_3_cf05eba2bcc10f48092334f9ce889863._comment b/doc/git-annex-sync/comment_3_cf05eba2bcc10f48092334f9ce889863._comment
new file mode 100644
index 0000000000..5a075b3ca8
--- /dev/null
+++ b/doc/git-annex-sync/comment_3_cf05eba2bcc10f48092334f9ce889863._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2018-10-04T19:30:07Z"
+ content="""
+Maybe, have a config option for the number of retries or the maximum time to keep trying?  An important property of git-annex-sync is that, even though it does merging, it does not normally fail.  It'd be good to keep that guarantee even in the face of concurrent access to the repo.  Alternately, you could push to a new branch synced/uuid/branchname, and then when git-annex-sync is later done at the target repo locally, merge from each of the synced/*/branchname .
+"""]]
diff --git a/doc/git-annex-sync/comment_4_bd5e45a7e668063df9159033a0857075._comment b/doc/git-annex-sync/comment_4_bd5e45a7e668063df9159033a0857075._comment
new file mode 100644
index 0000000000..099a403423
--- /dev/null
+++ b/doc/git-annex-sync/comment_4_bd5e45a7e668063df9159033a0857075._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2018-10-09T18:41:33Z"
+ content="""
+When concurrent git-annex commands on the same repo update that repo's git-annex branch, how is that handled?
+"""]]
diff --git a/doc/git-annex-sync/comment_5_5bf6c2b9750dbe5cff87d630f59f511a._comment b/doc/git-annex-sync/comment_5_5bf6c2b9750dbe5cff87d630f59f511a._comment
new file mode 100644
index 0000000000..1f94bd6566
--- /dev/null
+++ b/doc/git-annex-sync/comment_5_5bf6c2b9750dbe5cff87d630f59f511a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: comment 4"""
+ date="2020-02-20T19:30:38Z"
+ content="""
+With approptiate locking to prevent concurrency problems. As is the case
+extensively throughout git-annex, although users seem to keep expecting
+that to not be the case no matter how many times I assure them it is.
+"""]]
diff --git a/doc/git-annex-sync/comment_6_2c989d6d9f2ad2821db970cb3aed83c7._comment b/doc/git-annex-sync/comment_6_2c989d6d9f2ad2821db970cb3aed83c7._comment
new file mode 100644
index 0000000000..0b0386868d
--- /dev/null
+++ b/doc/git-annex-sync/comment_6_2c989d6d9f2ad2821db970cb3aed83c7._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="dud225@35a1ee469f82f3a7eb1f2dce4ad453f5e47bdfd3"
+ nickname="dud225"
+ avatar="http://cdn.libravatar.org/avatar/5147563e50c475918474594d93be95c2"
+ subject="Sync to remote master?"
+ date="2023-04-19T08:40:41Z"
+ content="""
+I'm a bit confused by what is mentioned in this page:
+> To make working with such non-bare remotes easier, sync pushes not only local master to remote master, but also to remote synced/master
+
+but just above it's explained that by default Git does not allow to push to remote master:
+> Syncing with a non-bare remote will not normally update the remote's current branch with changes from the local repository.
+
+In addition the page https://git-annex.branchable.com/sync/ doesn't mention that the remote master branch is directly synchronized:
+> When you run git annex sync [...] Finally, it updates synced/master to reflect the new state of master, and pushes it out to each of the remotes.
+
+So I was wondering about the correctness of the first cited sentence.
+"""]]
diff --git a/doc/git-annex-sync/comment_7_8f9a5457020bed293e9a93ccc9461a65._comment b/doc/git-annex-sync/comment_7_8f9a5457020bed293e9a93ccc9461a65._comment
new file mode 100644
index 0000000000..3917322fa5
--- /dev/null
+++ b/doc/git-annex-sync/comment_7_8f9a5457020bed293e9a93ccc9461a65._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Sync to remote master?"""
+ date="2023-04-19T16:17:11Z"
+ content="""
+The push to remote master will typically fail in a non-bare repository
+(it is possible to configure one to allow it). The push to synced/master
+will then succeed. Then when sync is later run in that repository, it will
+merge synced/master into master.
+"""]]
diff --git a/doc/git-annex-test.mdwn b/doc/git-annex-test.mdwn
new file mode 100644
index 0000000000..83bdc5bd3e
--- /dev/null
+++ b/doc/git-annex-test.mdwn
@@ -0,0 +1,71 @@
+# NAME
+
+git-annex test - run built-in test suite
+
+# SYNOPSIS
+
+git annex test
+
+# DESCRIPTION
+
+This runs git-annex's built-in test suite.
+
+The test suite runs in the `.t` subdirectory of the current directory.
+
+It can be useful to run the test suite on different filesystems,
+or to verify your local installation of git-annex.
+
+# OPTIONS
+      
+There are several options, provided by Haskell's tasty test
+framework. Pass --help for details about those.
+
+* `--jobs=N` `-JN`
+
+  How many tests to run in parallel. The default is "cpus", which will
+  runs one job per CPU core.
+
+* `--keep-failures`
+
+  When there are test failures, leave the `.t` directory populated with
+  repositories that demonstate the failures, for later analysis.
+
+* `--test-git-config name=value`
+
+  The test suite prevents git from reading any git configuration files.
+  Usually it is a good idea to run the test suite with a standard 
+  git configuration. However, this option can be useful to see what
+  effect a git configuration setting has on the test suite. 
+
+  Some configuration settings will break the test suite, in ways that are
+  due to a bug in git-annex. But it is possible that changing a
+  configuration can find a legitimate bug in git-annex.
+
+  One valid use of this is to change a git configuration to a value that
+  is planned to be the new default in a future version of git.
+
+  Also, some things can only be tested with a git configuration. For
+  example, annex.shared-sop-command has to be set for the test suite to
+  test using that command.
+
+* `--test-debug`
+
+  Normally output of commands run by the test suite is hidden, so even
+  when annex.debug or --debug is enabled, it will not be displayed.
+  This option makes the full output of commands run by the test suite be
+  displayed. It also makes the test suite run git-annex with --debug.
+
+  It's a good idea to use `-J1` in combinaton with this, otherwise
+  the output of concurrent tests will be mixed together.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-testremote]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-test/comment_1_5fbd7f75fef7a9f504baab1fae05d72c._comment b/doc/git-annex-test/comment_1_5fbd7f75fef7a9f504baab1fae05d72c._comment
new file mode 100644
index 0000000000..7657d84780
--- /dev/null
+++ b/doc/git-annex-test/comment_1_5fbd7f75fef7a9f504baab1fae05d72c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-09-25T16:11:40Z"
+ content="""
+Do the tests test multi-threaded operations (-JN)?  Is here a way to specify the number of processors to use for testing?
+"""]]
diff --git a/doc/git-annex-test/comment_2_752ca0ba483203cc4f5ccf36752e656d._comment b/doc/git-annex-test/comment_2_752ca0ba483203cc4f5ccf36752e656d._comment
new file mode 100644
index 0000000000..06e86a0a74
--- /dev/null
+++ b/doc/git-annex-test/comment_2_752ca0ba483203cc4f5ccf36752e656d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-09-25T16:57:13Z"
+ content="""
+Multithreaded operation is not tested, and since most threading related
+bugs are timing dependant, it's doubtful that the test suite would be able
+to usefully test them.
+"""]]
diff --git a/doc/git-annex-test/comment_3_cac436ddf4dec95006d1ebb4171a3289._comment b/doc/git-annex-test/comment_3_cac436ddf4dec95006d1ebb4171a3289._comment
new file mode 100644
index 0000000000..be98eb8276
--- /dev/null
+++ b/doc/git-annex-test/comment_3_cac436ddf4dec95006d1ebb4171a3289._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2018-09-25T18:22:16Z"
+ content="""
+\"since most threading related bugs are timing dependant, it's doubtful that the test suite would be able to usefully test them\" -- if you repeat a test enough times it'll tell you _whether_ that test might fail under multithreading.  Then git bisect can narrow down the breaking change.  But it'd be reassuring to be able to run the tests with multithreading on my particular environment (the way I use git-annex) and know they pass.
+"""]]
diff --git a/doc/git-annex-testremote.mdwn b/doc/git-annex-testremote.mdwn
new file mode 100644
index 0000000000..77f7aebaed
--- /dev/null
+++ b/doc/git-annex-testremote.mdwn
@@ -0,0 +1,60 @@
+# NAME
+
+git-annex testremote - test transfers to/from a remote
+
+# SYNOPSIS
+
+git annex testremote `remote`
+
+# DESCRIPTION
+
+This tests a remote by sending objects to it, downloading objects from it,
+etc.
+
+It's safe to run in an existing repository (the repository contents are
+not altered), although it may perform expensive data transfers.
+
+It's best to make a new remote for testing purposes. While the test
+tries to clean up after itself, if the remote being tested had a bug,
+the cleanup might fail, leaving test data in the remote. Also,
+some special remotes don't support removal of data that has been stored 
+in them, so test data won't be able to be cleaned up when testing those.
+
+Testing will use the remote's configuration, automatically varying
+the chunk sizes, and with simple shared encryption disabled and enabled,
+and exporttree disabled and enabled. If the remote is readonly, testing
+is limited to checking various properties of downloading from it.
+
+# OPTIONS
+
+* `--fast`
+
+  Perform a smaller set of tests.
+
+* `--test-readonly=file`
+
+  Normally, random objects are generated for the test and are sent to the
+  remote. When a readonly remote is being tested, that cannot be done,
+  and so you need to specify some annexed files to use in the testing,
+  using this option. Their content needs to be present in the readonly remote
+  being tested, and in the local repository.
+
+  This option can be repeated.
+
+* `--size=NUnits`
+
+  Tune the base size of generated objects. The default is 1MiB.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-test]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-transferkey.mdwn b/doc/git-annex-transferkey.mdwn
new file mode 100644
index 0000000000..6176397fad
--- /dev/null
+++ b/doc/git-annex-transferkey.mdwn
@@ -0,0 +1,39 @@
+# NAME
+
+git-annex transferkey - transfers a key from or to a remote
+
+# SYNOPSIS
+
+git annex transferkey `key [--from=remote|--to=remote]`
+
+# DESCRIPTION
+
+This plumbing-level command is used to request a single key be
+transferred.
+
+# OPTIONS
+
+* `--from=remote`
+
+  Download the content of the key from the remote.
+
+* `--to=remote`
+
+  Upload the content of the key to the remote.
+
+* `--file=name`
+
+  Provides a hint about the name of the file associated with the key.
+  (This name is only used in progress displays.)
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-transferkeys.mdwn b/doc/git-annex-transferkeys.mdwn
new file mode 100644
index 0000000000..d28004e381
--- /dev/null
+++ b/doc/git-annex-transferkeys.mdwn
@@ -0,0 +1,31 @@
+# NAME
+
+git-annex transferkeys - transfers keys (deprecated)
+
+# SYNOPSIS
+
+git annex transferkeys
+
+# DESCRIPTION
+
+This plumbing-level command is used to transfer data, by the assistant
+in git-annex version 8.20201127 and older. It is still included only
+to prevent breakage during upgrades.
+
+It is a long-running process, which is fed instructions about the keys
+to transfer using an internal stdio protocol, which is
+intentionally not documented (as it may change at any time).
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-transferrer.mdwn b/doc/git-annex-transferrer.mdwn
new file mode 100644
index 0000000000..97c28476fd
--- /dev/null
+++ b/doc/git-annex-transferrer.mdwn
@@ -0,0 +1,28 @@
+# NAME
+
+git-annex transferrer - transfers content
+
+# SYNOPSIS
+
+git annex transferrer
+
+# DESCRIPTION
+
+This plumbing-level command is used to transfer data.
+It is a long-running process, which is fed instructions about
+what to transfer using an internal stdio protocol, which is
+intentionally not documented (as it may change at any time).
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-trust.mdwn b/doc/git-annex-trust.mdwn
new file mode 100644
index 0000000000..d712c22d76
--- /dev/null
+++ b/doc/git-annex-trust.mdwn
@@ -0,0 +1,52 @@
+# NAME
+
+git-annex trust - trust a repository
+
+# SYNOPSIS
+
+git annex trust `[repository ...]`
+
+# DESCRIPTION
+
+Records that a repository is trusted to not unexpectedly lose
+content. Use with care.
+
+Repositories can be specified using their remote name, their
+description, or their UUID. To trust the current repository, use "here".
+
+Before trusting a repository, consider this scenario. Repository A
+is trusted and B is not; both contain the same content. `git-annex drop`
+is run on repository A, which checks that B still contains the content,
+and so the drop proceeds. Then `git-annex drop` is run on repository B,
+which trusts A to still contain the content, so the drop succeeds. Now
+the content has been lost.
+
+# OPTIONS
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-semitrust]](1)
+
+[[git-annex-untrust]](1)
+
+[[git-annex-dead]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-unannex.mdwn b/doc/git-annex-unannex.mdwn
new file mode 100644
index 0000000000..157318de2c
--- /dev/null
+++ b/doc/git-annex-unannex.mdwn
@@ -0,0 +1,56 @@
+# NAME
+
+git-annex unannex - undo accidental add command
+
+# SYNOPSIS
+
+git annex unannex `[path ...]`
+
+# DESCRIPTION
+
+Use this to undo an accidental `git annex add` command. It puts the
+file back how it was before the add.
+
+Note that for safety, the content of the file remains in the annex,
+until you use `git annex unused` and `git annex dropunused`.
+
+This is not the command you should use if you intentionally added a
+file some time ago, and don't want its contents any more. In that
+case you should use `git annex drop` instead, and you can also
+`git rm` the file.
+
+# OPTIONS
+
+* `--fast`
+
+  Normally this does a slow copy of the file. In `--fast` mode, it
+  instead makes a hard link from the file to the content in the annex.
+  But use --fast mode with caution, because editing the file will
+  change the content in the annex.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* file matching options
+
+  The [[git-annex-matching-options]](1)
+  can be used to specify files to unannex.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-unannex/comment_1_281aea2f018ea0fc98452c0d180c3bcb._comment b/doc/git-annex-unannex/comment_1_281aea2f018ea0fc98452c0d180c3bcb._comment
new file mode 100644
index 0000000000..3d03f267f8
--- /dev/null
+++ b/doc/git-annex-unannex/comment_1_281aea2f018ea0fc98452c0d180c3bcb._comment
@@ -0,0 +1,62 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="This needs to commit first. Any alternative?"
+ date="2016-10-25T07:25:47Z"
+ content="""
+Hello and thank you for git-annex.
+
+## Context
+
+Every newbie needs to understand what steps are possible and what to do when a wrong step was made.
+
+
+The wording \"undo accidental add command\" suggested (to me at least) that it was intended to be issued just *right after* the accidental add command, *before any commit*.  
+
+## Steps to reproduce
+
+Right after `git annex add path`, do `git annex unannex path`.
+
+## Expected behavior
+
+`git annex unannex path` would undo the add.
+
+More precisely, it would walk the path given, find any symlink pointing to annexed data and not committed yet, and replace it with a plain file with the linked content, honoring `--fast` option if given.
+
+## Observed behavior
+
+    git-annex: Cannot proceed with uncommitted changes staged in the index. Recommend you: git commit
+
+If user follows this path, there will be two unnecessary commits: an add commit and an unannex commit.
+
+There may be reasons to prefer not to introduce those commits.  Granted, git allows to adjust history after the fact.  Is there a simpler solution?
+
+## Question, summarized
+
+Is there a command to just revert a \"add\", without introducing any commit?
+
+
+## Details
+
+Full test log below:
+
+```
+{
+cd /tmp/ ; mkdir testga ; cd testga ; 
+git init ; git annex init ; 
+echo \"test\" > test ; 
+git annex add test ; git annex unannex test
+}
+
+Initialized empty Git repository in /tmp/testga/.git/
+init  ok
+(recording state in git...)
+add test ok
+(recording state in git...)
+git-annex: Cannot proceed with uncommitted changes staged in the index. Recommend you: git commit
+```
+
+Thank you for any hint.
+
+"""]]
diff --git a/doc/git-annex-unannex/comment_2_d325e4201ec2964c5633e00c473df755._comment b/doc/git-annex-unannex/comment_2_d325e4201ec2964c5633e00c473df755._comment
new file mode 100644
index 0000000000..9cec18a0bd
--- /dev/null
+++ b/doc/git-annex-unannex/comment_2_d325e4201ec2964c5633e00c473df755._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-10-26T17:53:23Z"
+ content="""
+The behavior your comment describes is only the case with v5
+repoitories in indirect mode. With v5 direct mode repositories and
+with the newer v6 repository format, `git annex unannex`
+is able to safely handle files that have been added and not committed yet.
+"""]]
diff --git a/doc/git-annex-unannex/comment_3_034db8e67e4bf5321e022918902f38e8._comment b/doc/git-annex-unannex/comment_3_034db8e67e4bf5321e022918902f38e8._comment
new file mode 100644
index 0000000000..2b1225e68c
--- /dev/null
+++ b/doc/git-annex-unannex/comment_3_034db8e67e4bf5321e022918902f38e8._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Ok, v6 not mature yet (as of 2016-10)."
+ date="2016-10-29T10:02:05Z"
+ content="""
+> with the newer v6 repository format, git annex unannex is able to safely handle files that have been added and not committed yet.
+
+I was puzzled, believing that recent versions used v6 repository format.
+
+Indeed, all my repositories have been created with 6.20161011-g3135d35 with default options (indirect mode).
+
+```
+git-annex version: 6.20161011-g3135d35
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux x86_64
+```
+
+I understand now that v6 is still experimental and not enabled by default ( ref http://git-annex.branchable.com/devblog/day_421__lost_in_the_trees/ ). 
+
+"""]]
diff --git a/doc/git-annex-unannex/comment_4_2a5334f59a4bdf242d53d2d5c120283c._comment b/doc/git-annex-unannex/comment_4_2a5334f59a4bdf242d53d2d5c120283c._comment
new file mode 100644
index 0000000000..980b1c8601
--- /dev/null
+++ b/doc/git-annex-unannex/comment_4_2a5334f59a4bdf242d53d2d5c120283c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="datamanager"
+ avatar="http://cdn.libravatar.org/avatar/7d4ca7c5e571d4740ef072b83a746c12"
+ subject="is there some way to remove a file I've commited? "
+ date="2021-05-25T13:10:35Z"
+ content="""
+Essentially, I want to tell git-annex to forget about my file; remove it from the annex, and put the original file back where it was in my local filesystem. 
+
+I made the mistake of adding a list of files accidentally, and then panicked. I even ran git-annex-sync, so there's now a commit on the git-annex branch with my accidentally added files. I thought that maybe I could just revert that commit and all would be well, but I thought I'd seek some assistance before doing that. 
+
+I haven't copied the files to any other remotes as yet, but git-annex-whereis returns nothing when I give it one of the paths I added by mistake, so those files seem to be in some kind of limbo, where they're in the annex, but it doesn't know about them. I am not sure what I broke along the way. 
+"""]]
diff --git a/doc/git-annex-unannex/comment_5_d549796a3b1bdd3e980cb2c05f30fe2e._comment b/doc/git-annex-unannex/comment_5_d549796a3b1bdd3e980cb2c05f30fe2e._comment
new file mode 100644
index 0000000000..306233a424
--- /dev/null
+++ b/doc/git-annex-unannex/comment_5_d549796a3b1bdd3e980cb2c05f30fe2e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-05-27T16:20:11Z"
+ content="""
+@datamanager the `git-annex unannex` command can't rewrite git history,
+it just stops further tracking of an annexed file by git. Any way you would
+usually scrub an unwanted commit out of git's history can be used with
+git-annex; scrubbing mentioned of hashes out of the git-annex branch's
+history gets more involved.
+
+Once you have run `git-annex unannex` on a file, it's not annexed, so
+commands like `git-annex whereis` will not have anything to say about it.
+"""]]
diff --git a/doc/git-annex-unannex/comment_6_d5a8450349b0383ec29d150420189937._comment b/doc/git-annex-unannex/comment_6_d5a8450349b0383ec29d150420189937._comment
new file mode 100644
index 0000000000..0ada2033bb
--- /dev/null
+++ b/doc/git-annex-unannex/comment_6_d5a8450349b0383ec29d150420189937._comment
@@ -0,0 +1,97 @@
+[[!comment format=mdwn
+ username="arnaud.legrand@e79f5d4cff79116f56388885021e8507bef18e12"
+ nickname="arnaud.legrand"
+ avatar="http://cdn.libravatar.org/avatar/143239914c3e3c1a374a7c244b56d73e"
+ subject="Weird behavior of git archive in combination with largefiles configuration"
+ date="2023-02-17T09:46:34Z"
+ content="""
+Hi,
+
+I'm preparing a lecture on how git annex can help research data
+management and I stumbled, when playing with `git-annex unannex`, on a
+strange behavior that I fail to understand nor to properly work around.
+When preparing for a public archive it may make sense to include
+**some** annexed files in the archive while it may be desirable to keep
+the symlinks for others (e.g., because they are already available from
+somewhere else). This is why I do not want to rely on the `git-annex
+export` mechanism that would replace the symlinks of all annexed files
+by their content.
+
+Instead, I `unannex` some of my files but surprisingly, depending on git
+annex configuration, their content may not be in the archive produced by
+`git archive`. Here is a minimal working example.
+
+``` shell
+DIR=/tmp/test
+chmod -Rf u+w $DIR; rm -rf $DIR ; mkdir -p $DIR; cd $DIR
+git init
+git annex init
+git config --local annex.largefiles 'largerthan=100kb and include=data/*'
+
+echo \"Hello\" > README
+git add README
+
+mkdir data/
+dd if=/dev/zero of=data/foo.dat bs=1M count=1 2>/dev/null
+git annex add data/foo.dat
+git commit -m \"Initial commit\"
+
+## git config --local annex.largefiles ''
+git annex unannex data/foo.dat && git add data/foo.dat && git commit -m \"Unannexing\" 
+git archive --format=tar.gz --prefix nobel_project/ -o ../archive.tgz HEAD
+
+tar zxf ../archive.tgz
+tree -s nobel_project/
+```
+
+``` example
+
+ Initialized empty Git repository in /tmp/test/.git/
+init  ok
+(recording state in git...)
+       add data/foo.dat
+31.98 KiB        14 MiB/s 0s100%  1 MiB           137 MiB/s 0s                                  ok
+(recording state in git...)
+[master (root-commit) 8fbb907] Initial commit
+ 2 files changed, 2 insertions(+)
+ create mode 100644 README
+ create mode 120000 data/foo.dat
+  unannex data/foo.dat ok
+(recording state in git...)
+[master da73fb0] Unannexing
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+)
+100644
+mnobel_project/
+├── [       4096]  data
+│   └── [        102]  foo.dat
+└── [          6]  README
+
+1 directory, 2 files
+```
+
+As you may see from the output, `foo.dat` is only 102 bytes whereas it
+should be 1MB. Instead the content of `foo.dat` is:
+
+``` shell
+cat nobel_project/data/foo.dat
+```
+
+``` example
+/annex/objects/SHA256E-s1048576--30e14955ebf1352266dc2ff8067e68104607e750abb9d3b36582b8af909fcb58.dat
+```
+
+But if I remove the `annex.largefiles` configuration (either upfront or
+right before calling `unannex`), everything works as expected, i.e., my
+archive comprises the content of the annexed file.
+
+Is this an expected behavior ? This is the kind of operation I typically
+do in a branch that I erase afterward but it (temporarily) messes my
+local git configuration, which I don't like, so I'm looking for a better
+workaround.
+
+Thanks for you amazing work,
+
+Arnaud
+
+"""]]
diff --git a/doc/git-annex-unannex/comment_7_a6b64c4d90f4d228b8facce5e2399eca._comment b/doc/git-annex-unannex/comment_7_a6b64c4d90f4d228b8facce5e2399eca._comment
new file mode 100644
index 0000000000..88bd1d056a
--- /dev/null
+++ b/doc/git-annex-unannex/comment_7_a6b64c4d90f4d228b8facce5e2399eca._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Weird behavior of git archive in combination with largefiles configuration"""
+ date="2023-02-20T18:52:43Z"
+ content="""
+That behavior does not really have anything to do with the use of
+`git-annex unannex`.
+
+You have configured annex.largefiles to something that matches a file. The
+file is not checked into git (perhaps because you ran `git-annex unannex`
+after adding it earlier, but it could just as well be a new file). You run
+`git add` on the file. What happens? Well, `git add` asks git-annex if the
+file should be annexed. Your annex.largefiles configuration tells it it
+should. So the file is added to the annex, and a pointer file is checked
+into git. (Not a symlink because the file is added unlocked; 
+see [[git-annex-unlock]].)
+
+`git archive` does not archive the contents of the annex, so it only
+archives the pointer file content.
+
+What you can do is use `git-annex add --force-small` when adding the file
+to override the annex.largefiles config. See [[tips/largefiles]] at the
+bottom for a recipe for using that to convert an annexed file to be stored
+in git.
+"""]]
diff --git a/doc/git-annex-unannex/comment_8_54a6008e1db73d16d72587830912d772._comment b/doc/git-annex-unannex/comment_8_54a6008e1db73d16d72587830912d772._comment
new file mode 100644
index 0000000000..99ef161e0c
--- /dev/null
+++ b/doc/git-annex-unannex/comment_8_54a6008e1db73d16d72587830912d772._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="arnaud.legrand@e79f5d4cff79116f56388885021e8507bef18e12"
+ nickname="arnaud.legrand"
+ avatar="http://cdn.libravatar.org/avatar/143239914c3e3c1a374a7c244b56d73e"
+ subject="Re: Weird behavior of git archive in combination with largefiles configuration "
+ date="2023-02-26T18:45:31Z"
+ content="""
+Thanks a lot Joey for your very clear explanation and clean workaround.
+"""]]
diff --git a/doc/git-annex-undo.mdwn b/doc/git-annex-undo.mdwn
new file mode 100644
index 0000000000..000ece2f1c
--- /dev/null
+++ b/doc/git-annex-undo.mdwn
@@ -0,0 +1,49 @@
+# NAME
+
+git-annex undo - undo last change to a file or directory
+
+# SYNOPSIS
+
+git annex  `[filename|directory] ...`
+
+# DESCRIPTION
+
+When passed a filename, undoes the last change that was made to that
+file.
+  
+When passed a directory, undoes the last change that was made to the
+contents of that directory.
+  
+Running undo a second time will undo the undo, returning the working
+tree to the same state it had before. To support undoing an undo of
+staged changes, any staged changes are first committed by the
+undo command.
+
+Note that this does not undo get/drop of a file's content; it only
+operates on the file tree committed to git.
+
+# OPTIONS
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* The [[git-annex-common-options]](1) can also be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-add]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-undo/comment_1_3466520304aa164ec44ed4e9d67590e7._comment b/doc/git-annex-undo/comment_1_3466520304aa164ec44ed4e9d67590e7._comment
new file mode 100644
index 0000000000..8155ec0e7b
--- /dev/null
+++ b/doc/git-annex-undo/comment_1_3466520304aa164ec44ed4e9d67590e7._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="git-annex-undo removes files, possibly destroying information? Please explain."
+ date="2016-10-14T07:02:42Z"
+ content="""
+Hello,
+
+## Context
+
+Thank you for git-annex. I'm progressing in learning how to use it. Seems to work as intended with only annexed files.
+
+I actually need mixed content repository and like the idea of `annex.largefiles` deciding which files go into the annex.
+
+While experimenting with mixed content repository, I had `git-annex-undo` destroy information twice.  Or perhaps I did something wrong?
+
+## What happened
+
+Here's my .gitattributes
+
+```
+*.NEF annex.largefiles=anything
+*.JPG annex.largefiles=anything
+*.jpg annex.largefiles=anything
+
+```
+
+I had a directory (say, `newdir`) with some jpg and some other files, not known by git or git-annex so far.
+
+Based on [https://git-annex.branchable.com/tips/largefiles/](https://git-annex.branchable.com/tips/largefiles/) I expected both `git add` and `git annex add` to add NEF JPG jpg to the annex, and other files as regular git files.  
+
+In case of problem, I expected `git annex undo` to revert state to the one just before the last command (which is: full of my regular files, not symlinks or empty).
+
+* `git add newdir` added them *all* as *regular* files, not partly in the annex as expected.  Surprised, I wanted to undo and try another command.
+* `git annex undo` emptied `newdir` completely. Wow! Fortunately these were copies, else they would have been gone forever! To be fair I have not checked at that point if files had been copied in annex, which as only copy would still be a mess because file names would have been lost anyway. 
+
+I used `git reset <hash>` to revert state git-style, checked with `git status` that state was indeed back to pre-add (newdir empty, not known to git), then copied the files again from their source.
+
+* `git annex add newdir` added them all as *annexed* files, replacing with links, not partly as regular files as expected.
+* `git annex undo` emptied `newdir` completely. I expected my regular files back in place. 
+
+I had the intended result by using `git add` on regular files and `git annex add` to add files to be annexed.  As if `.gitattributes` were absent.
+
+git-annex compiled on Debian unstable as of 2016-10-13 from git source, commit 3135d35094aa5453ef7a5f12762e00e0139a6dbb.
+
+## Questions
+
+* Have I explained situation clearly?
+* Did `git annex add` behave as intended by you? Wasn't it supposed to automatically decide which files go to the annex?
+* Did `git annex undo` behave as intended by you? Wasn't it supposed to revert working directory to the state just before the wrong \"add\"?
+* Have I used `.gitattributes`, `add` commands correctly?
+
+Thank you.
+"""]]
diff --git a/doc/git-annex-undo/comment_2_3dba1a993cbd357bdaa453366c0185cd._comment b/doc/git-annex-undo/comment_2_3dba1a993cbd357bdaa453366c0185cd._comment
new file mode 100644
index 0000000000..8d36310537
--- /dev/null
+++ b/doc/git-annex-undo/comment_2_3dba1a993cbd357bdaa453366c0185cd._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="comment 2"
+ date="2016-10-14T07:23:51Z"
+ content="""
+Adding this to `.gitattributes`:
+
+```
+*.xmp annex.largefiles=nothing
+```
+
+Causes `git-annex add` to behave as expected.  Questions about `git annex undo` behavior remain.
+
+"""]]
diff --git a/doc/git-annex-undo/comment_3_ac1369c0417c1dc5f1b41b5cc88fe2fd._comment b/doc/git-annex-undo/comment_3_ac1369c0417c1dc5f1b41b5cc88fe2fd._comment
new file mode 100644
index 0000000000..acf1a0f856
--- /dev/null
+++ b/doc/git-annex-undo/comment_3_ac1369c0417c1dc5f1b41b5cc88fe2fd._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-10-17T19:24:35Z"
+ content="""
+`git annex undo` undoes the last change that was committed to the file.
+If the file has staged changes, `git annex undo` first commits those
+changes (to avoid losing data) and then undoes that commit.
+
+The reason that `git annex undo` deleted the files from your working tree
+is that the previous commit did not have those files in it, and it undid
+to the state at that commit.
+
+So, you will never lose the content of a file by running `git annex undo`.
+If `git annex undo` deletes a file, you can always get it back by
+checking out a previous version of the branch. Or even by running `git
+annex undo` a second time, to undo the undo.
+"""]]
diff --git a/doc/git-annex-undo/comment_4_18ed23e07ffed1cbf63e71fb115b0654._comment b/doc/git-annex-undo/comment_4_18ed23e07ffed1cbf63e71fb115b0654._comment
new file mode 100644
index 0000000000..89f01b5f75
--- /dev/null
+++ b/doc/git-annex-undo/comment_4_18ed23e07ffed1cbf63e71fb115b0654._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="git-annex-undo: 3 issues and fix suggestions"
+ date="2016-10-21T09:21:16Z"
+ content="""
+Hello Joey.
+
+Thank you for your answer.  It makes things clearer. I believe the documentation should reflect it.  
+
+## Where the bug (1) is: not defining the level of operation
+
+> git annex undo undoes the last change that was committed to the file.
+
+Ah, *committed*. That's an important information.  It's not at all what I expected from reading the page.
+
+I was expecting tree-level undo, not commit-level undo. I've found the bug: *The documentation for git-annex undo does not define \"undo\" or the level at which it operates.*
+
+### Suggestion (1): define the level of operation
+
+What if the documentation included something like this?
+
+> Here, \"undo\" means: \"undo a commit\", that is \"add a commit in the history that undoes the previous commit\".  
+
+## Case (2) of staged changes
+
+> If the file has staged changes, git annex undo first commits those changes (to avoid losing data) and then undoes that commit.
+
+This sounds strange. 
+
+So, if I call git-annex-undo to undo a commit A, but there are staged changes, git-annex-undo will add a commit B then add another commit C to undo B? 
+
+This will not undo A.
+
+What use case where you thinking of?
+
+### Case of staged changes: suggestion (2)
+
+Perhaps in case when file has staged changes, it would be better to display a warning message, perhaps with a `--commit-staged` option to bypass it.
+
+## Internal rationale: got it
+
+> The reason that git annex undo deleted the files from your working tree is that the previous commit did not have those files in it, and it undid to the state at that commit.
+
+> So, you will never lose the content of a file by running git annex undo. If git annex undo deletes a file, you can always get it back by checking out a previous version of the branch. Or even by running git annex undo a second time, to undo the undo.
+
+Ok I understand the data was not lost.  But this kind of reasoning is only reachable when one knows what git-annex-undo really does.  So, this command is still dangerous to the unsavvy.  Perhaps document that?
+
+## Issue (3): What was actually needed (all this time)
+
+It seems that what I really needed was [[git-annex-unannex]].
+
+### Suggested changes to documentation (3)
+
+Perhaps in case when file has staged changes, it would be better to display a warning message *and* suggest using [[git-annex-unannex]] instead?
+
+> If you are looking for a way to undo changes in the directory tree, consider [[git-annex-unannex]].
+
+## Conclusion
+
+What do you think about the 3 issues and fix suggestions?
+
+Thanks again. `git-annex` has started to become useful here.
+
+"""]]
diff --git a/doc/git-annex-ungroup.mdwn b/doc/git-annex-ungroup.mdwn
new file mode 100644
index 0000000000..7e678bacfc
--- /dev/null
+++ b/doc/git-annex-ungroup.mdwn
@@ -0,0 +1,27 @@
+# NAME
+
+git-annex ungroup - remove a repository from a group
+
+# SYNOPSIS
+
+git annex ungroup `repository groupname`
+
+# DESCRIPTION
+
+Removes a repository from a group.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-group]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-uninit.mdwn b/doc/git-annex-uninit.mdwn
new file mode 100644
index 0000000000..2f8c218ae7
--- /dev/null
+++ b/doc/git-annex-uninit.mdwn
@@ -0,0 +1,41 @@
+# NAME
+
+git-annex uninit - de-initialize git-annex and clean out repository
+
+# SYNOPSIS
+
+git annex uninit
+
+# DESCRIPTION
+
+Use this to stop using git annex. It will unannex every file in the
+repository, and remove all of git-annex's other data, leaving you with a
+git repository plus the previously annexed files.
+
+# OPTIONS
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-unannex]](1)
+
+[[git-annex-init]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-uninit/comment_1_075670e8e153e1d9f420b7d53c6ec06d._comment b/doc/git-annex-uninit/comment_1_075670e8e153e1d9f420b7d53c6ec06d._comment
new file mode 100644
index 0000000000..70fad31696
--- /dev/null
+++ b/doc/git-annex-uninit/comment_1_075670e8e153e1d9f420b7d53c6ec06d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="chocolate.camera@ec2ecab153906be21ac5f36652c33786ad0e0b60"
+ nickname="chocolate.camera"
+ avatar="http://cdn.libravatar.org/avatar/4f00dfc3ad590ef7492788b854ceba78"
+ subject="Why so slow"
+ date="2018-12-31T04:06:08Z"
+ content="""
+Why is uninit so slow? Shouldn’t it simply consist of moving the files out of the annex and then delete the .git folder?
+"""]]
diff --git a/doc/git-annex-uninit/comment_2_c695775bdb2c7491314a33dd6bcb447d._comment b/doc/git-annex-uninit/comment_2_c695775bdb2c7491314a33dd6bcb447d._comment
new file mode 100644
index 0000000000..e403979f66
--- /dev/null
+++ b/doc/git-annex-uninit/comment_2_c695775bdb2c7491314a33dd6bcb447d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-01-01T16:26:57Z"
+ content="""
+Obvious reason is that it's not something often used or that has had much
+demand for being sped up. And in particular it's written as a call to
+unannex each annexed file, and that runs `git rm --cached` once per file,
+which can be slow.
+
+But there are also non-obvious things that it may need to do that can be
+slow. For example, if two files in the git repo point to the same git-annex
+object, it has to make a copy of the object to one of the worktree files.
+"""]]
diff --git a/doc/git-annex-uninit/comment_4_3386d8419830354b4422d38448467e95._comment b/doc/git-annex-uninit/comment_4_3386d8419830354b4422d38448467e95._comment
new file mode 100644
index 0000000000..a99f5f4701
--- /dev/null
+++ b/doc/git-annex-uninit/comment_4_3386d8419830354b4422d38448467e95._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-11-21T19:56:32Z"
+ content="""
+Moved some comments about a bug to 
+[[bugs/uninit_fails_when_I_symlink_your_symlink]]. 
+Please do not use this man page's comment section to file bug reports.
+"""]]
diff --git a/doc/git-annex-uninit/comment_5_53358bdd6093e2fb787df8de7190c5fd._comment b/doc/git-annex-uninit/comment_5_53358bdd6093e2fb787df8de7190c5fd._comment
new file mode 100644
index 0000000000..b9ca1f8f63
--- /dev/null
+++ b/doc/git-annex-uninit/comment_5_53358bdd6093e2fb787df8de7190c5fd._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="eric.w@eee65cd362d995ced72640c7cfae388ae93a4234"
+ nickname="eric.w"
+ avatar="http://cdn.libravatar.org/avatar/8d9808c12db3a3f93ff7f9e74c0870fc"
+ subject="comment 5"
+ date="2021-01-14T22:15:12Z"
+ content="""
+A faster way of doing uninit is the following:
+
+```cp --no-clobber --dereference --recursive --preserve=all --reflink=auto --verbose ./git_annex_repo/your_symlinks/ ./target_dir/```
+
+This will simply copy (thin COW copy) symlinks (dereferenced) as normal files preserving the mtime, etc. the resulting ./target_dir/ will have your files if they existed in this annex or broken symlinks if the files were not here.
+
+
+
+
+"""]]
diff --git a/doc/git-annex-unlock.mdwn b/doc/git-annex-unlock.mdwn
new file mode 100644
index 0000000000..1a2bd32596
--- /dev/null
+++ b/doc/git-annex-unlock.mdwn
@@ -0,0 +1,79 @@
+# NAME
+
+git-annex unlock - unlock files for modification
+
+# SYNOPSIS
+
+git annex unlock `[path ...]`
+
+# DESCRIPTION
+
+Normally, the content of annexed files is protected from being changed.
+Unlocking an annexed file allows it to be modified. When no files are
+specified, all annexed files in the current directory are unlocked.
+
+Unlocking a file changes how it is stored in the git repository (from a
+symlink to a pointer file), so this command will make a change that you
+can commit.
+
+The content of an unlocked file is still stored in git-annex, not git, 
+and when you commit modifications to the file, the modifications will also
+be stored in git-annex, with only the pointer file stored in git.
+
+If you use `git add` to add a file to the annex, it will be added in unlocked form from
+the beginning. This allows workflows where a file starts out unlocked, is
+modified as necessary, and is locked once it reaches its final version.
+
+Normally, unlocking a file requires a copy to be made of its content, so
+that its original content is preserved, while the copy can be modified. To
+use less space, annex.thin can be set to true; this makes a hard link to
+the content be made instead of a copy. (Only when supported by the file
+system.) While this can save considerable disk space, any modification made
+to a file will cause the old version of the file to be lost from the local
+repository. So, enable annex.thin with care.
+
+# EXAMPLES
+
+	# git annex unlock disk-image
+	# git commit -m "unlocked to allow VM to make changes as it runs"
+
+	# git annex unlock photo.jpg
+	# gimp photo.jpg
+	# git annex add photo.jpg
+	# git annex lock photo.jpg
+	# git commit -m "redeye removal"
+
+# OPTIONS
+
+* file matching options
+ 
+  The [[git-annex-matching-options]](1)
+  can be used to specify files to unlock.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-edit]](1)
+
+[[git-annex-add]](1)
+
+[[git-annex-lock]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-unlock/comment_10_1f5ca7ccd35e9b102bf24b3f14deeee1._comment b/doc/git-annex-unlock/comment_10_1f5ca7ccd35e9b102bf24b3f14deeee1._comment
new file mode 100644
index 0000000000..8ef849a9f4
--- /dev/null
+++ b/doc/git-annex-unlock/comment_10_1f5ca7ccd35e9b102bf24b3f14deeee1._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="re: Are my unlocked, annexed files still safe?"
+ date="2021-04-21T16:32:42Z"
+ content="""
+@pat:
+> Basically, unlock gives me an editable copy of the file - but I always
+> have the original version, and can revert or check it out if I need
+> to. Is that correct?
+
+Yes, it's a copy as long as you don't set `annex.thin=true` (as you
+mention).  Just as with locked files, though, you may not be able to
+get the content back from an earlier version if you've dropped unused
+content.
+
+"""]]
diff --git a/doc/git-annex-unlock/comment_11_26ad80a6ad142e7dac6c8af955a4413f._comment b/doc/git-annex-unlock/comment_11_26ad80a6ad142e7dac6c8af955a4413f._comment
new file mode 100644
index 0000000000..e194fffa86
--- /dev/null
+++ b/doc/git-annex-unlock/comment_11_26ad80a6ad142e7dac6c8af955a4413f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="re: clarifying unlocked files"
+ date="2021-04-21T16:34:50Z"
+ content="""
+@Ilya_Shlyakhter:
+> Does the locked/unlocked state apply to one particular path within the
+> repo, or to a particular key?
+
+A particular path.
+
+> Can the same key be used by both a locked and an unlocked file?
+
+Yes.
+
+"""]]
diff --git a/doc/git-annex-unlock/comment_1_d7f38f681be51db1244988847840d735._comment b/doc/git-annex-unlock/comment_1_d7f38f681be51db1244988847840d735._comment
new file mode 100644
index 0000000000..ee9d313622
--- /dev/null
+++ b/doc/git-annex-unlock/comment_1_d7f38f681be51db1244988847840d735._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="chocolate.camera@ec2ecab153906be21ac5f36652c33786ad0e0b60"
+ nickname="chocolate.camera"
+ avatar="http://cdn.libravatar.org/avatar/4f00dfc3ad590ef7492788b854ceba78"
+ subject="comment 1"
+ date="2018-12-31T16:41:08Z"
+ content="""
+> Normally, unlocking a file requires a copy to be made of its content, so that its original content is preserved
+
+Does that imply than, on v7 in a file system that does not support hard links such as FAT32, `git annex adjust --unlock` would effectively be creating a duplicate of all files via cp (which is incredibly costly time-wise specially for big repos and huge files) and would effectively double the size it occupies?
+"""]]
diff --git a/doc/git-annex-unlock/comment_2_51158d4484ecb39633ec828beb8d9ce3._comment b/doc/git-annex-unlock/comment_2_51158d4484ecb39633ec828beb8d9ce3._comment
new file mode 100644
index 0000000000..4d732cd99b
--- /dev/null
+++ b/doc/git-annex-unlock/comment_2_51158d4484ecb39633ec828beb8d9ce3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-01-01T16:21:04Z"
+ content="""
+Yes, if you don't want the copy set annex.thin as documented on the man
+page.
+"""]]
diff --git a/doc/git-annex-unlock/comment_3_516a1522db3d1c14cc5131a24d672a8f._comment b/doc/git-annex-unlock/comment_3_516a1522db3d1c14cc5131a24d672a8f._comment
new file mode 100644
index 0000000000..9918be6c26
--- /dev/null
+++ b/doc/git-annex-unlock/comment_3_516a1522db3d1c14cc5131a24d672a8f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="chocolate.camera@ec2ecab153906be21ac5f36652c33786ad0e0b60"
+ nickname="chocolate.camera"
+ avatar="http://cdn.libravatar.org/avatar/4f00dfc3ad590ef7492788b854ceba78"
+ subject="comment 3"
+ date="2019-01-01T18:17:21Z"
+ content="""
+The page about [unlocked files](https://git-annex.branchable.com/tips/unlocked_files/) says:
+
+> setting annex.thin only has any effect on systems that support hard links. It is supported on Windows, but not on FAT filesystems.
+"""]]
diff --git a/doc/git-annex-unlock/comment_4_d04a1d4159306939b91a34fd17ab0325._comment b/doc/git-annex-unlock/comment_4_d04a1d4159306939b91a34fd17ab0325._comment
new file mode 100644
index 0000000000..64a8c2b83d
--- /dev/null
+++ b/doc/git-annex-unlock/comment_4_d04a1d4159306939b91a34fd17ab0325._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tobiasBora"
+ avatar="http://cdn.libravatar.org/avatar/80a7d8c2a7b475b6b71198cce0faa6b0"
+ subject="Move file from git annex to just git in one commit"
+ date="2019-09-26T22:52:35Z"
+ content="""
+Hello. I'd like to know, how could I move back a file managed by git annex to a normal file (for example, say I added by mistake a text file in it). For now, I do `git unlock MYFILE`, then I remove the file from git: `git rm --cached MYFILE`, and `git commit -am 'Remove file'`, and finally I add back the file, `git add MYFILE && git commit -am 'File added back in git'`. However, this creates two commits, which is a bit annoying and leave the feeling that the file has been removed while it was just a kind of modification. How could I do that in less commands, and with a single commit?
+Thanks! 
+"""]]
diff --git a/doc/git-annex-unlock/comment_5_40abc819288a97753747562f16b8febe._comment b/doc/git-annex-unlock/comment_5_40abc819288a97753747562f16b8febe._comment
new file mode 100644
index 0000000000..cc425484f4
--- /dev/null
+++ b/doc/git-annex-unlock/comment_5_40abc819288a97753747562f16b8febe._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Move file from git annex to just git in one commit"""
+ date="2019-09-30T17:29:39Z"
+ content="""
+See [[tips/largefiles]], it has recipes for conversion from annex to git and
+from git to annex.
+"""]]
diff --git a/doc/git-annex-unlock/comment_6_047355b1ba5e90b71fc85b42f52d1aeb._comment b/doc/git-annex-unlock/comment_6_047355b1ba5e90b71fc85b42f52d1aeb._comment
new file mode 100644
index 0000000000..182b05f5c3
--- /dev/null
+++ b/doc/git-annex-unlock/comment_6_047355b1ba5e90b71fc85b42f52d1aeb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="issue with example"
+ date="2021-02-28T23:18:26Z"
+ content="""
+In the example, wouldn't `git-annex-unlock` erase any edits made in gimp? Was this meant to use `git-annex-add` instead?
+
+# EXAMPLES
+
+	# git annex unlock photo.jpg
+	# gimp photo.jpg
+	# git annex lock photo.jpg
+	# git commit -m \"redeye removal\"
+
+"""]]
diff --git a/doc/git-annex-unlock/comment_6_7ab5b674d0fc18da262e6c0264953e21._comment b/doc/git-annex-unlock/comment_6_7ab5b674d0fc18da262e6c0264953e21._comment
new file mode 100644
index 0000000000..ec3e10f15c
--- /dev/null
+++ b/doc/git-annex-unlock/comment_6_7ab5b674d0fc18da262e6c0264953e21._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: issue with example"""
+ date="2021-03-01T17:07:06Z"
+ content="""
+`git-annex lock` wouldn't erase any modifications, but it would fail
+due to the file being modified. Fixed the example to use `git-annex add`
+before locking.
+"""]]
diff --git a/doc/git-annex-unlock/comment_8_d10c8b6e2dd8800cbfc11a7fa8536065._comment b/doc/git-annex-unlock/comment_8_d10c8b6e2dd8800cbfc11a7fa8536065._comment
new file mode 100644
index 0000000000..b8ec3bb67a
--- /dev/null
+++ b/doc/git-annex-unlock/comment_8_d10c8b6e2dd8800cbfc11a7fa8536065._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="Are my unlocked, annexed files still safe?"
+ date="2021-04-21T15:47:48Z"
+ content="""
+I want to double-check something: if I've annexed and committed files, I believe they are safely stored in git-annex even if I unlock them (as long as I don't use `--thin`). If I annex copies of the the same file, annex will only store it once, and use a symlink for the two original files. But if I unlock them, I can edit them independently.
+
+Basically, unlock gives me an editable copy of the file - but I always have the original version, and can revert or check it out if I need to. Is that correct?
+"""]]
diff --git a/doc/git-annex-unlock/comment_9_31c72f60ddf029f09c1850223d5a8a55._comment b/doc/git-annex-unlock/comment_9_31c72f60ddf029f09c1850223d5a8a55._comment
new file mode 100644
index 0000000000..0a61a8954a
--- /dev/null
+++ b/doc/git-annex-unlock/comment_9_31c72f60ddf029f09c1850223d5a8a55._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="clarifying unlocked files"
+ date="2021-04-21T16:08:05Z"
+ content="""
+Does the locked/unlocked state apply to one particular path within the repo, or to a particular key?  Can the same key be used by both a locked and an unlocked file?
+"""]]
diff --git a/doc/git-annex-unregisterurl.mdwn b/doc/git-annex-unregisterurl.mdwn
new file mode 100644
index 0000000000..e8192f4084
--- /dev/null
+++ b/doc/git-annex-unregisterurl.mdwn
@@ -0,0 +1,68 @@
+# NAME
+
+git-annex unregisterurl - unregisters an url for a key
+
+# SYNOPSIS
+
+git annex unregisterurl `[key url]`
+
+# DESCRIPTION
+
+This plumbing-level command can be used to unregister urls when keys can
+no longer be downloaded from them.
+
+Normally the key is a git-annex formatted key. However, if the key cannot be
+parsed as a key, and is a valid url, an URL key is constructed from the url.
+
+Unregistering a key's last web url will make git-annex no longer treat content
+as being present in the web special remote. If some other special remote
+claims the url, unregistering the url will not update presence information
+for it, because the content may still be present on the remote.
+
+# OPTIONS
+
+* `--remote=name|uuid`
+
+  Indicate that the url is expected to be claimed by the specified remote.
+  If some other remote claims the url instead, unregistering it will fail.
+
+  Note that `--remote=web` will prevent any other remote from claiming
+  the url.
+
+* `--batch`
+
+  In batch input mode, lines are read from stdin, and each line
+  should contain a key and url, separated by a single space.
+
+* `-z`
+
+   When in batch mode, the input is delimited by nulls instead of the usual
+   newlines.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-registerurl]](1)
+
+[[git-annex-reregisterurl]](1)
+
+[[git-annex-rmurl]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-untrust.mdwn b/doc/git-annex-untrust.mdwn
new file mode 100644
index 0000000000..11a1ea77fa
--- /dev/null
+++ b/doc/git-annex-untrust.mdwn
@@ -0,0 +1,45 @@
+# NAME
+
+git-annex untrust - do not trust a repository
+
+# SYNOPSIS
+
+git annex untrust `[repository ...]`
+
+# DESCRIPTION
+
+Records that a repository is not trusted and could lose content
+at any time.
+
+Repositories can be specified using their remote name, their
+description, or their UUID. To untrust the current repository, use "here".
+
+# OPTIONS
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-trust]](1)
+
+[[git-annex-semitrust]](1)
+
+[[git-annex-dead]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-unused.mdwn b/doc/git-annex-unused.mdwn
new file mode 100644
index 0000000000..9165ace10a
--- /dev/null
+++ b/doc/git-annex-unused.mdwn
@@ -0,0 +1,110 @@
+# NAME
+
+git-annex unused - look for unused file content
+
+# SYNOPSIS
+
+git annex unused
+
+# DESCRIPTION
+
+Checks the annex for data that does not correspond to any files present
+in any tag or branch, or in the git index, and prints a numbered list
+of the data.
+
+After running this command, you can use the `--unused` option with many 
+other git-annex commands to operate on all the unused data that was found.
+
+For example, to move all unused data to origin:
+  
+	git annex unused; git annex move --unused --to origin
+
+# OPTIONS
+
+* `--fast`
+
+  Only show unused temp and bad files.
+
+* `--from=repository`
+
+  Check for unused data that is located in a repository.
+
+  The repository should be specified using the name of a configured remote,
+  or the UUID or description of a repository.
+
+* `--used-refspec=+ref:-ref`
+
+  By default, any data that the git index uses, or that any refs in the git
+  repository point to is considered to be used. If you only want to use
+  some refs, you can use this option to specify the ones to use. Data that
+  is not in the specified refs (and not used by the index) will then be
+  considered unused.
+
+  See REFSPEC FORMAT below for details of the format of this setting.
+
+  The git configuration annex.used-refspec can be used to configure
+  this in a more permanent fashion.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# REFSPEC FORMAT
+
+The refspec format for --used-refspec and annex.used-refspec is
+a colon-separated list of additions and removals of refs.
+A somewhat contrived example:
+
+	+refs/heads/*:+HEAD^:+refs/tags/*:-refs/tags/old-tag:reflog
+
+This adds all refs/heads/ refs, as well as the previous version
+of HEAD. It also adds all tags, except for old-tag. And it adds
+all refs from the reflog.
+
+The default behavior is equivilant to `--used-refspec=+refs/*:+HEAD`
+
+The refspec is processed by starting with an empty set of refs,
+and walking the list in order from left to right.
+
+Each + using a glob is matched against all relevant refs
+(a subset of `git show-ref`) and all matching refs are added
+to the set.
+For example, "+refs/remotes/*" adds all remote refs.
+
+Each + without a glob adds the literal value to the set.
+For example, "+HEAD^" adds "HEAD^".
+
+Each - is matched against the set of refs accumulated so far.
+Any refs with names that match are removed from the set.
+
+"reflog" adds all the refs from the reflog. This will make past versions
+of files not be considered to be unused until the ref expires from the
+reflog (by default for 90 days). Note that this may make git-annex unused
+take some time to complete, it if needs to check every ref from the
+reflog.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-dropunused]](1)
+
+[[git-annex-addunused]](1)
+
+[[git-annex-whereused]](1)
+
+[[git-annex-oldkeys]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-unused/comment_11_5c1ea2e8ac475d8c0ddca2c38f968b95._comment b/doc/git-annex-unused/comment_11_5c1ea2e8ac475d8c0ddca2c38f968b95._comment
new file mode 100644
index 0000000000..9c0c594fc5
--- /dev/null
+++ b/doc/git-annex-unused/comment_11_5c1ea2e8ac475d8c0ddca2c38f968b95._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2020-01-01T18:54:04Z"
+ content="""
+Generally if git-annex unused does not identify some object as unused, that
+you expected would be unused, it's because it found a branch that still
+uses that object. It might be some old branch (or tag) that you made and
+forgot about, it might be a remote tracking branch, either for a remote
+that you forgot to sync the changes to, or for an old remote that
+got removed but in a way that left the tracking branch around.
+annex.used-refspec can also pull in other, non-branch refs.
+"""]]
diff --git a/doc/git-annex-unused/comment_12_573e68def90ffd899271c6a9f80eae3c._comment b/doc/git-annex-unused/comment_12_573e68def90ffd899271c6a9f80eae3c._comment
new file mode 100644
index 0000000000..cf535d7c1b
--- /dev/null
+++ b/doc/git-annex-unused/comment_12_573e68def90ffd899271c6a9f80eae3c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="meribold"
+ avatar="http://cdn.libravatar.org/avatar/8cfdfc37c8459a7320aa6bb9f2689112"
+ subject="comment 12"
+ date="2021-03-11T02:52:32Z"
+ content="""
+Is it possible to only list files that are not present in any branch/tag/ref and are *also* not present in any ancestor commit of any branch/tag/ref?
+"""]]
diff --git a/doc/git-annex-unused/comment_13_4a935c0c8862b24202c877031c35e238._comment b/doc/git-annex-unused/comment_13_4a935c0c8862b24202c877031c35e238._comment
new file mode 100644
index 0000000000..339abb4431
--- /dev/null
+++ b/doc/git-annex-unused/comment_13_4a935c0c8862b24202c877031c35e238._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2021-03-11T15:59:50Z"
+ content="""
+@meribold there is not, but I've opened a todo,
+[[todo/git-annex-unused_--history]]
+"""]]
diff --git a/doc/git-annex-unused/comment_1_029c4bee59e48806c9f3d83579fdbb90._comment b/doc/git-annex-unused/comment_1_029c4bee59e48806c9f3d83579fdbb90._comment
new file mode 100644
index 0000000000..80239253dc
--- /dev/null
+++ b/doc/git-annex-unused/comment_1_029c4bee59e48806c9f3d83579fdbb90._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mark@6b90344cdab3158eacb94a3944460d138afc9bef"
+ nickname="mark"
+ subject="Special remotes"
+ date="2016-01-08T21:12:45Z"
+ content="""
+Does this work for special remotes? Or only remotes that are full repositories?
+"""]]
diff --git a/doc/git-annex-unused/comment_2_c4d994706f69024788e6653d02a09517._comment b/doc/git-annex-unused/comment_2_c4d994706f69024788e6653d02a09517._comment
new file mode 100644
index 0000000000..4c06422d26
--- /dev/null
+++ b/doc/git-annex-unused/comment_2_c4d994706f69024788e6653d02a09517._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-11T16:30:18Z"
+ content="""
+@mark The `--from` option can be used with any remote, whether it's a normal git
+remote or a special remote.
+"""]]
diff --git a/doc/git-annex-unused/comment_2_ca010846ef8eed4a302b6755f1f521f4._comment b/doc/git-annex-unused/comment_2_ca010846ef8eed4a302b6755f1f521f4._comment
new file mode 100644
index 0000000000..a83e286e86
--- /dev/null
+++ b/doc/git-annex-unused/comment_2_ca010846ef8eed4a302b6755f1f521f4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2018-09-24T17:27:34Z"
+ content="""
+If I understand correctly, git-annex-unused will by default cause old versions of files to be lost?
+"""]]
diff --git a/doc/git-annex-unused/comment_3_5eb913bb96a04a174c04fe5d119977f4._comment b/doc/git-annex-unused/comment_3_5eb913bb96a04a174c04fe5d119977f4._comment
new file mode 100644
index 0000000000..802b3b9e25
--- /dev/null
+++ b/doc/git-annex-unused/comment_3_5eb913bb96a04a174c04fe5d119977f4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-09-25T18:09:29Z"
+ content="""
+Well, this only finds old versions of files, it does not delete them.
+
+Even if you choose to then run [[git-annex-dropunused]], it won't lose
+data unless you force it to.
+"""]]
diff --git a/doc/git-annex-unused/comment_4_5b208cb45335f0d383a456865068e659._comment b/doc/git-annex-unused/comment_4_5b208cb45335f0d383a456865068e659._comment
new file mode 100644
index 0000000000..a10db0d1a5
--- /dev/null
+++ b/doc/git-annex-unused/comment_4_5b208cb45335f0d383a456865068e659._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="atrent"
+ avatar="http://cdn.libravatar.org/avatar/6069dfebff03997460874771defa0fa4"
+ subject="can't find unused objects"
+ date="2019-12-02T07:26:41Z"
+ content="""
+I recently migrated an annex to SHA256 (without \"E\") and I'm now trying to clean the repo from unused data.
+I have a strange situation: there are 62G of unused objects:
+
+    $ du -ks .git/annex/objects/
+    64334024	.git/annex/objects/
+
+but 'git annex unused' gives me only:
+
+    $ git annex unused
+    unused ...
+    Some annexed data is no longer used by any files:
+    NUMBER  KEY
+    1       SHA256E-s27--32efec98dc9e05442fc2385bb85d855a8c7824c68abd4ab5bf55a4dfe412b334.pdf
+    (To see where data was previously used, try: git log --stat --no-textconv -S'KEY')
+    To remove unwanted data: git-annex dropunused NUMBER
+    ok
+
+I've checked (through a small shell script) that none of the object is in fact referenced by any symlink...
+
+May I delete them? Shall I do some other checking/fscking/repairing?
+
+Thank you
+"""]]
diff --git a/doc/git-annex-unused/comment_5_65ab9f687f2817199eda7455d9b82677._comment b/doc/git-annex-unused/comment_5_65ab9f687f2817199eda7455d9b82677._comment
new file mode 100644
index 0000000000..f688589402
--- /dev/null
+++ b/doc/git-annex-unused/comment_5_65ab9f687f2817199eda7455d9b82677._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="atrent"
+ avatar="http://cdn.libravatar.org/avatar/6069dfebff03997460874771defa0fa4"
+ subject="P.S. they are all SHA256E"
+ date="2019-12-02T07:29:06Z"
+ content="""
+the \"lost\" objects are all SHA256E (*with* the \"E\")
+"""]]
diff --git a/doc/git-annex-unused/comment_6_962097729f8b4a657bb7b9863fdffb68._comment b/doc/git-annex-unused/comment_6_962097729f8b4a657bb7b9863fdffb68._comment
new file mode 100644
index 0000000000..564bbab667
--- /dev/null
+++ b/doc/git-annex-unused/comment_6_962097729f8b4a657bb7b9863fdffb68._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="atrent"
+ avatar="http://cdn.libravatar.org/avatar/6069dfebff03997460874771defa0fa4"
+ subject="P.P.S. i dropped all local copies"
+ date="2019-12-02T08:03:01Z"
+ content="""
+I forgot to tell that after migrating I synced to all remotes and dropped everything in 'here', that's why I was expecting no more objects locally.
+"""]]
diff --git a/doc/git-annex-unused/comment_7_e21b036767651c5cfdd34bbd24a31fb5._comment b/doc/git-annex-unused/comment_7_e21b036767651c5cfdd34bbd24a31fb5._comment
new file mode 100644
index 0000000000..bcc17e1d5b
--- /dev/null
+++ b/doc/git-annex-unused/comment_7_e21b036767651c5cfdd34bbd24a31fb5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 7"
+ date="2019-12-02T16:02:47Z"
+ content="""
+Did you commit after git-migrate?   Does the worktree have any uncommitted changes?
+"""]]
diff --git a/doc/git-annex-unused/comment_8_10ee2770ffe1cde367f3d310b2670539._comment b/doc/git-annex-unused/comment_8_10ee2770ffe1cde367f3d310b2670539._comment
new file mode 100644
index 0000000000..b7377c955c
--- /dev/null
+++ b/doc/git-annex-unused/comment_8_10ee2770ffe1cde367f3d310b2670539._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="dropping contents of old keys after migration"
+ date="2019-12-02T16:48:47Z"
+ content="""
+\"May I delete them\" -- `git-annex-drop --force` may be safer, as it also updates [[location_tracking]].  You might also want to [[git-annex-dead]] the dropped keys to prevent [[git-annex-fsck]] from complaining about lost contents.
+
+Re: why [[git-annex-unused]] isn't finding the unused contents, try running it with `--used-refspec=+HEAD`, and make sure `annex.used-refspec` git config is not set.  Note that this will mark as unused any annexed contents not referenced from the latest tree of the HEAD branch, e.g. annexed files that were removed in some older commit.
+"""]]
diff --git a/doc/git-annex-unused/comment_9_cfcc0bab810d58b7db66c2fa4e92f769._comment b/doc/git-annex-unused/comment_9_cfcc0bab810d58b7db66c2fa4e92f769._comment
new file mode 100644
index 0000000000..41477d216b
--- /dev/null
+++ b/doc/git-annex-unused/comment_9_cfcc0bab810d58b7db66c2fa4e92f769._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 9"
+ date="2019-12-02T16:58:25Z"
+ content="""
+\"I synced to all remotes and dropped everything in 'here'\" -- [[git-annex-unused]] \"Checks the *annex*\" for the unused contents (unless `--from=repository` is used), so if you dropped everything in `here`, there's nothing to find.  But it seems from `du` results that contents wasn't actually dropped?  [[git-annex-whereis]] tells where git-annex thinks contents is.
+"""]]
diff --git a/doc/git-annex-upgrade.mdwn b/doc/git-annex-upgrade.mdwn
new file mode 100644
index 0000000000..0b22067816
--- /dev/null
+++ b/doc/git-annex-upgrade.mdwn
@@ -0,0 +1,60 @@
+# NAME
+
+git-annex upgrade - upgrade repository
+
+# SYNOPSIS
+
+git annex upgrade
+
+# DESCRIPTION
+
+Upgrades the repository to the latest version.
+
+Each git-annex repository has an annex.version in its git configuration,
+that indicates the repository version. When an old repository version
+becomes deprecated, git-annex will automatically upgrade it
+(unless annex.autoupgraderepository is set to false). To manually upgrade,
+you can use this command.
+
+Sometimes there's a newer repository version that is not the default yet,
+and then you can use this command to upgrade to it.
+
+Currently, git-annex supports upgrades all the way back to version 0, which
+was only used by its author. It's expected that git-annex will always
+support upgrading from all past repository versions -- this is necessary to
+allow archives to be taken offline for years and later used.
+
+# OPTIONS
+
+* --autoonly
+
+  Only do whatever automatic upgrade can be done, don't necessarily
+  upgrade to the latest version. This is used internally by git-annex.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-migrate]](1)
+
+Upgrades procedures and history: <http://git-annex.branchable.com/upgrades>
+
+News and release notes: <http://git-annex.branchable.com/news/>
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-vadd.mdwn b/doc/git-annex-vadd.mdwn
new file mode 100644
index 0000000000..98b545c7a5
--- /dev/null
+++ b/doc/git-annex-vadd.mdwn
@@ -0,0 +1,42 @@
+# NAME
+
+git-annex vadd - add subdirs to current view
+
+# SYNOPSIS
+
+git annex vadd `[field=glob ...] [field=value ...] [tag ...] [?tag ...] [field?=glob]`
+
+# DESCRIPTION
+
+Changes the current view, adding an additional level of directories
+to categorize the files.
+
+For example, when the view is by author/tag, `vadd year=*` will
+change it to year/author/tag.
+
+So will `vadd year=2014 year=2013`, but limiting the years in view
+to only those two.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-metadata]](1)
+
+[[git-annex-view]](1)
+
+[[git-annex-vpop]](1)
+
+[[git-annex-vfilter]](1)
+
+[[git-annex-vcycle]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-vcycle.mdwn b/doc/git-annex-vcycle.mdwn
new file mode 100644
index 0000000000..0971cd578c
--- /dev/null
+++ b/doc/git-annex-vcycle.mdwn
@@ -0,0 +1,38 @@
+# NAME
+
+git-annex vcycle - switch view to next layout
+
+# SYNOPSIS
+
+git annex vcycle
+
+# DESCRIPTION
+
+When a view involves nested subdirectories, this cycles the order.
+ 
+For example, when the view is by year/author/tag, `vcycle` will switch
+it to author/tag/year.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-metadata]](1)
+
+[[git-annex-view]](1)
+
+[[git-annex-vpop]](1)
+
+[[git-annex-vadd]](1)
+
+[[git-annex-vfilter]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-version.mdwn b/doc/git-annex-version.mdwn
new file mode 100644
index 0000000000..4630182790
--- /dev/null
+++ b/doc/git-annex-version.mdwn
@@ -0,0 +1,38 @@
+# NAME
+
+git-annex version - show version info
+
+# SYNOPSIS
+
+git annex version
+
+# DESCRIPTION
+
+Shows the version of git-annex, as well as repository version information.
+
+git-annex's version is in the form MAJOR.DATE, where MAJOR is a number
+like 5, which corresponds to the current repository version, and DATE
+is the date of the last release, like 20150320.
+
+Daily builds of git-annex will append a "-gREF" to the version, which
+corresponds to the git ref from git-annex's source repository that was
+built. Therefore, "5.20150320-gdd35cf3" is a daily build, and
+"5.20150401" is an April 1st release made a bit later.
+
+# OPTIONS
+
+* `--raw`
+
+  Causes only git-annex's version to be output, and nothing else.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-vfilter.mdwn b/doc/git-annex-vfilter.mdwn
new file mode 100644
index 0000000000..c9ed797083
--- /dev/null
+++ b/doc/git-annex-vfilter.mdwn
@@ -0,0 +1,36 @@
+# NAME
+
+git-annex vfilter - filter current view
+
+# SYNOPSIS
+
+git annex vfilter `[tag ...] [field=value ...] [?tag ...] [field?=glob] [!tag ...] [field!=value ...]`
+
+# DESCRIPTION
+
+Filters the current view to only the files that have the
+specified field values and tags.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-metadata]](1)
+
+[[git-annex-view]](1)
+
+[[git-annex-vpop]](1)
+
+[[git-annex-vadd]](1)
+
+[[git-annex-vcycle]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-vicfg.mdwn b/doc/git-annex-vicfg.mdwn
new file mode 100644
index 0000000000..273dda7251
--- /dev/null
+++ b/doc/git-annex-vicfg.mdwn
@@ -0,0 +1,32 @@
+# NAME
+
+git-annex vicfg - edit configuration in git-annex branch
+
+# SYNOPSIS
+
+git annex vicfg
+
+# DESCRIPTION
+
+Opens EDITOR on a temp file containing all of git-annex's 
+configuration settings that are stored in the git-annex branch, 
+and when it exits, stores any changes made back to the git-annex branch.
+
+Unlike git config settings, these configuration settings can be seen
+by all clones of the repository.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+git-config(1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-view.mdwn b/doc/git-annex-view.mdwn
new file mode 100644
index 0000000000..f2677019a7
--- /dev/null
+++ b/doc/git-annex-view.mdwn
@@ -0,0 +1,77 @@
+# NAME
+
+git-annex view - enter a view branch
+
+# SYNOPSIS
+
+git annex view `[tag ...] [field=value ...] [field=glob ...] [?tag ...] [field?=glob] [!tag ...] [field!=value ...]`
+
+# DESCRIPTION
+
+Uses metadata to build a view branch of the files in the current branch,
+and checks out the view branch. Only files in the current branch whose
+metadata matches all the specified field values and tags will be
+shown in the view.
+
+Multiple values for a metadata field can be specified, either by using
+a glob (`field="*"`) or by listing each wanted value. The resulting view
+will put files in subdirectories according to the value of their fields.
+  
+Once within such a view, you can make additional directories, and
+copy or move files into them. When you commit, the metadata will
+be updated to correspond to your changes. Deleting files and committing
+also updates the metadata.
+
+As well as the usual metadata, there are fields available corresponding
+to the path to the file. So a file "foo/bar/baz/file" has fields "/=foo",
+"foo/=bar", and "foo/bar/=baz". These location fields can be used the
+same as other metadata to construct the view.
+
+For example, `/=foo` will only include files from the foo
+directory in the view, while `foo/=*` will preserve the
+subdirectories of the foo directory in the view.
+
+To enter a view containing only files that lack a given metadata
+value or tag, specify field!=value or !tag. (Globs cannot be used here.)
+
+`field?=*` is like `field=*` but adds an additional directory named `_` (by
+default) that contains files that do not have the field set to any value.
+Similarly, `?tag` adds an additional directory named `_` that contains
+files that do not have any tags set. Moving files from the `_` directory to
+another directory and committing will set the metadata. And moving files
+into the `_` directory and committing will unset the metadata. 
+
+The name of the `_` directory can be changed using the annex.viewunsetdirectory
+git config.
+
+Filenames in the view branch include their path within the original branch, to
+ensure that they are unique. The path comes after the main filename, and
+before any extensions. For example, "foo/bar.baz" will have a name
+like "bar_%foo%.baz". annex.maxextensionlength can be used to configure
+what is treated as an extension.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-metadata]](1)
+
+[[git-annex-vpop]](1)
+
+[[git-annex-vfilter]](1)
+
+[[git-annex-vadd]](1)
+
+[[git-annex-vcycle]](1)
+
+[[git-annex-adjust]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-vpop.mdwn b/doc/git-annex-vpop.mdwn
new file mode 100644
index 0000000000..f226fae2a0
--- /dev/null
+++ b/doc/git-annex-vpop.mdwn
@@ -0,0 +1,38 @@
+# NAME
+
+git-annex vpop - switch back to previous view
+
+# SYNOPSIS
+
+git annex vpop `[N]`
+
+# DESCRIPTION
+
+Switches from the currently active view back to the previous view.
+Or, from the first view back to original branch.
+  
+The optional number tells how many views to pop.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-metadata]](1)
+
+[[git-annex-view]](1)
+
+[[git-annex-vfilter]](1)
+
+[[git-annex-vadd]](1)
+
+[[git-annex-vcycle]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-wanted.mdwn b/doc/git-annex-wanted.mdwn
new file mode 100644
index 0000000000..e8200e025e
--- /dev/null
+++ b/doc/git-annex-wanted.mdwn
@@ -0,0 +1,39 @@
+# NAME
+
+git-annex wanted - get or set preferred content expression
+
+# SYNOPSIS
+
+git annex wanted `repository [expression]`
+
+# DESCRIPTION
+
+When run with an expression, configures the content that is preferred
+to be held in the archive. See [[git-annex-preferred-content]](1)
+
+For example:
+
+	git annex wanted . "include=*.mp3 or include=*.ogg"
+
+Without an expression, displays the current preferred content setting
+of the repository.
+
+# OPTIONS
+
+* The [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-required]](1)
+
+[[git-annex-preferred-content]](1)
+
+[[git-annex-groupwanted]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-watch.mdwn b/doc/git-annex-watch.mdwn
new file mode 100644
index 0000000000..7f82cbb62f
--- /dev/null
+++ b/doc/git-annex-watch.mdwn
@@ -0,0 +1,47 @@
+# NAME
+
+git-annex watch - daemon to watch for changes
+
+# SYNOPSIS
+
+git annex watch
+
+# DESCRIPTION
+
+Watches for changes to files in the current directory and its subdirectories,
+and takes care of automatically adding new files, as well as dealing with
+deleted, copied, and moved files. With this running as a daemon in the
+background, you no longer need to manually run git commands when
+manipulating your files.
+  
+By default, all new files in the directory will be added to the repository.
+(Including dotfiles.) To block some files from being added, use
+`.gitignore` files.
+  
+By default, all files that are added are added to the annex, the same
+as when you run `git annex add`. If you configure annex.largefiles,
+files that it does not match will instead be added with `git add`.
+
+# OPTIONS
+
+* `--foreground`
+
+  Avoid forking to the background.
+
+* `--stop`
+
+  Stop a running daemon in the current repository.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-assistant]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-webapp.mdwn b/doc/git-annex-webapp.mdwn
new file mode 100644
index 0000000000..d53e76f8cb
--- /dev/null
+++ b/doc/git-annex-webapp.mdwn
@@ -0,0 +1,60 @@
+# NAME
+
+git-annex webapp - launch webapp
+
+# SYNOPSIS
+
+git annex webapp
+
+# DESCRIPTION
+
+Opens a web app, that allows easy setup of a git-annex repository,
+and control of the git-annex assistant. If the assistant is not
+already running, it will be started. This will cause new files to 
+be added and syncing operations to be performed.
+
+By default, the webapp can only be accessed from localhost, and running
+it opens a browser window.
+
+# OPTIONS
+
+* `--listen=address`
+
+  Useful for using the webapp on a remote computer. This makes the webapp
+  listen on the specified IP address. (Or on the address that a specified
+  hostname resolves to.)
+
+  This disables running a local web browser, and outputs the url you
+  can use to open the webapp.
+
+  Set annex.listen in the git config to make the webapp always
+  listen on an IP address.
+
+* `--port=number`
+
+  Use this option to specify a port for the webapp.
+  By default, the webapp picks an unused port.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# USING HTTPS
+
+When using the webapp on a remote computer, you'll almost certainly
+want to enable HTTPS. The webapp will use HTTPS if it finds
+a .git/annex/privkey.pem and .git/annex/certificate.pem. Here's
+one way to generate those files, using a self-signed certificate:
+  
+	openssl genrsa -out .git/annex/privkey.pem 4096
+	openssl req -new -x509 -key .git/annex/privkey.pem > .git/annex/certificate.pem
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-assistant]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-webapp/comment_1_443c5595412a19ef9c6948c4224297a3._comment b/doc/git-annex-webapp/comment_1_443c5595412a19ef9c6948c4224297a3._comment
new file mode 100644
index 0000000000..aeba3edaad
--- /dev/null
+++ b/doc/git-annex-webapp/comment_1_443c5595412a19ef9c6948c4224297a3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="NewUser"
+ nickname="dont.post.me"
+ avatar="http://cdn.libravatar.org/avatar/90f59ddc341eaf9b2657422206c06901"
+ subject="launching `git annex webapp` starts adding to the annex which is surprising"
+ date="2023-11-18T20:03:06Z"
+ content="""
+I have gotten as far as running `git init` and `git annex init` on my server. There&rsquo;s a bunch of stuff there and I figure I&rsquo;ll just add the things that I care about as I go.
+
+I read the page on the [webapp](https://git-annex.branchable.com/git-annex-webapp/) and it just says that it &ldquo;allows easy setup of a git-annex repository, and control of the git-annex assistant&rdquo;. I started the webapp on my server and I was alarmed to see a message in the webapp that it was adding things to git annex. Over on the page for the [git annex assistant](https://git-annex.branchable.com/git-annex-assistant/) it says &ldquo;By default, all new files in the directory will be added to the repository&rdquo; which is definitely not what I expected. I&rsquo;m a new user trying to learn how to use git annex and this was an unpleasant surprise. Can we amend the docs for the webapp to warn about this behavior?
+
+"""]]
diff --git a/doc/git-annex-webapp/comment_2_7b1c4c4356e801006081588b32075fb4._comment b/doc/git-annex-webapp/comment_2_7b1c4c4356e801006081588b32075fb4._comment
new file mode 100644
index 0000000000..ad79367d0f
--- /dev/null
+++ b/doc/git-annex-webapp/comment_2_7b1c4c4356e801006081588b32075fb4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="NewUser"
+ nickname="dont.post.me"
+ avatar="http://cdn.libravatar.org/avatar/90f59ddc341eaf9b2657422206c06901"
+ subject="launching `git annex webapp` starts adding to the annex which is surprising"
+ date="2023-11-18T20:08:17Z"
+ content="""
+Since I panicked upon seeing a message about adding files to the annex, I promptly killed the webapp. I might just be misunderstanding what's going on. Thanks!
+"""]]
diff --git a/doc/git-annex-webapp/comment_3_aee70625f7cff6e7312f9bc2cbbb02d0._comment b/doc/git-annex-webapp/comment_3_aee70625f7cff6e7312f9bc2cbbb02d0._comment
new file mode 100644
index 0000000000..c96c374c1a
--- /dev/null
+++ b/doc/git-annex-webapp/comment_3_aee70625f7cff6e7312f9bc2cbbb02d0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 3"
+ date="2023-11-19T16:16:15Z"
+ content="""
+Welcome on board. `git annex webapp` launches the assistant. It might even do `git annex assistant --autostart` and launch the assistant in all configured repos. That is indeed an important info to know. Everyone can edit these pages (the Edit button above) btw. 
+"""]]
diff --git a/doc/git-annex-webapp/comment_4_c1754cdb4087ad278867ed8fddd99409._comment b/doc/git-annex-webapp/comment_4_c1754cdb4087ad278867ed8fddd99409._comment
new file mode 100644
index 0000000000..71371439bb
--- /dev/null
+++ b/doc/git-annex-webapp/comment_4_c1754cdb4087ad278867ed8fddd99409._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 4"
+ date="2023-11-19T16:27:34Z"
+ content="""
+I added a note to make it more clear that the webapp will sync stuff via the assistant.
+"""]]
diff --git a/doc/git-annex-webapp/comment_5_31301895752f0dd81db72c463f0dc732._comment b/doc/git-annex-webapp/comment_5_31301895752f0dd81db72c463f0dc732._comment
new file mode 100644
index 0000000000..0041f9127e
--- /dev/null
+++ b/doc/git-annex-webapp/comment_5_31301895752f0dd81db72c463f0dc732._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="NewUser"
+ nickname="dont.post.me"
+ avatar="http://cdn.libravatar.org/avatar/90f59ddc341eaf9b2657422206c06901"
+ subject="Thanks Yann!"
+ date="2023-11-19T18:20:03Z"
+ content="""
+Thank you [nobodyinperson](https://git-annex.branchable.com/users/nobodyinperson/)! Your note looks perfect. Oh, wow; I didn&rsquo;t know that I could edit this page. Thanks again!
+"""]]
diff --git a/doc/git-annex-whereis.mdwn b/doc/git-annex-whereis.mdwn
new file mode 100644
index 0000000000..84678709f0
--- /dev/null
+++ b/doc/git-annex-whereis.mdwn
@@ -0,0 +1,122 @@
+# NAME
+
+git-annex whereis - lists repositories that have file content
+
+# SYNOPSIS
+
+git annex whereis `[path ...]`
+
+# DESCRIPTION
+
+Displays information about where the contents of files are located.
+
+For example:
+
+	# git annex whereis
+	whereis my_cool_big_file (1 copy)
+		0c443de8-e644-11df-acbf-f7cd7ca6210d  -- laptop
+	whereis other_file (3 copies)
+		0c443de8-e644-11df-acbf-f7cd7ca6210d  -- laptop
+		62b39bbe-4149-11e0-af01-bb89245a1e61  -- usb drive [here]
+		7570b02e-15e9-11e0-adf0-9f3f94cb2eaa  -- backup drive
+
+Note that this command does not contact remotes to verify if they still
+have the content of files. It only reports on the last information that was
+received from remotes.
+
+# OPTIONS
+
+* matching options
+  
+  The [[git-annex-matching-options]](1)
+  can be used to control what to act on.
+
+* `--key=keyname`
+
+  Show where a particular git-annex key is located.
+
+* `--all` `-A`
+
+  Show whereis information for all known keys.
+  
+  (Except for keys that have been marked as dead,
+  see [[git-annex-dead]](1).)
+
+* `--branch=ref`
+
+  Show whereis information for files in the specified branch or treeish.
+
+* `--unused`
+
+  Show whereis information for files found by last run of git-annex unused.
+
+* `--batch`
+
+  Enables batch mode, in which a file is read in a line from stdin,
+  its information displayed, and repeat.
+
+  Note that if the file is not an annexed file, or does not match
+  specified matching options, an empty line will be
+  output instead.
+
+* `--batch-keys`
+
+  This is like `--batch` but the lines read from stdin are parsed as keys.
+
+* `-z`
+
+  Makes batch input be delimited by nulls instead of the usual
+  newlines.
+
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
+* `--json-error-messages`
+
+  Messages that would normally be output to standard error are included in
+  the JSON instead.
+
+* `--format=value`
+
+  Use custom output formatting.
+
+  The value is a format string, in which '${var}' is expanded to the
+  value of a variable. To right-justify a variable with whitespace,
+  use '${var;width}' ; to left-justify a variable, use '${var;-width}';
+  to escape unusual characters (including control characters)
+  in a variable, use '${escaped_var}'
+
+  These variables are available for use in formats: file, key, uuid,
+  url, backend, bytesize, humansize, keyname, hashdirlower, hashdirmixed,
+  mtime (for the mtime field of a WORM key).
+
+  Also, '\\n' is a newline, '\\000' is a NULL, etc.
+
+  When the format contains the uuid variable, it will be expanded in turn
+  for each repository that contains the file content. For example,
+  with --format="${file} ${uuid}\\n", output will look like:
+  
+	foo 00000000-0000-0000-0000-000000000001
+	foo a7f7ddd0-9a08-11ea-ab66-8358e4209d30
+	bar a7f7ddd0-9a08-11ea-ab66-8358e4209d30
+
+  The same applies when the url variable is used and a file has multiple
+  recorded urls.
+
+* Also the [[git-annex-common-options]](1) can be used.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-find]](1)
+
+[[git-annex-list]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-whereis/comment_1_6a1f97de22983127bfc351d14838fb0e._comment b/doc/git-annex-whereis/comment_1_6a1f97de22983127bfc351d14838fb0e._comment
new file mode 100644
index 0000000000..429cbe8d53
--- /dev/null
+++ b/doc/git-annex-whereis/comment_1_6a1f97de22983127bfc351d14838fb0e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-09-19T18:57:13Z"
+ content="""
+Maybe, mention in the docs that whereis does not actually contact remotes to check they still have the files (unlike drop).  Maybe, print the timestamp of the last check?
+"""]]
diff --git a/doc/git-annex-whereis/comment_2_69a861de80c7d2b939aae7103b1b7359._comment b/doc/git-annex-whereis/comment_2_69a861de80c7d2b939aae7103b1b7359._comment
new file mode 100644
index 0000000000..cf8b1ca01a
--- /dev/null
+++ b/doc/git-annex-whereis/comment_2_69a861de80c7d2b939aae7103b1b7359._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-09-24T15:33:02Z"
+ content="""
+I've added a para above.  Note that this is a wiki, and you can edit it
+too!
+
+Showing the timestamp of when the file was added to the remote could be
+done; git-annex does not track the last time it verified content was on a
+remote and tracking that would bloat the git-annex branch. I don't think
+displaying a very old timestamp for data at rest would give the right
+impression though.
+"""]]
diff --git a/doc/git-annex-whereis/comment_3_d06a33bfaeb2a9274d12639fdedcfa8a._comment b/doc/git-annex-whereis/comment_3_d06a33bfaeb2a9274d12639fdedcfa8a._comment
new file mode 100644
index 0000000000..94bf904d4f
--- /dev/null
+++ b/doc/git-annex-whereis/comment_3_d06a33bfaeb2a9274d12639fdedcfa8a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="rshalaev"
+ avatar="http://cdn.libravatar.org/avatar/d7f181d338cbcef7418faa01f0441e86"
+ subject="How to find last available version of a file?"
+ date="2024-04-29T14:07:40Z"
+ content="""
+Repo that contains the latest/current version of a file is not accessible. Can git annex whereis find the last available version of a file in other repos (or a specific repo)?
+
+I can looping through commit log and running whereis for each commit until an earlier version of a file is found, but perhaps there is a better way to do it with a single command?
+"""]]
diff --git a/doc/git-annex-whereis/comment_4_3f06096e582178b4c69d63e84735d911._comment b/doc/git-annex-whereis/comment_4_3f06096e582178b4c69d63e84735d911._comment
new file mode 100644
index 0000000000..5ea5d0a457
--- /dev/null
+++ b/doc/git-annex-whereis/comment_4_3f06096e582178b4c69d63e84735d911._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: How to find last available version of a file?"""
+ date="2024-04-30T18:52:12Z"
+ content="""
+There's not currently a way to do that without some scripting to get
+the keys, and then `git-annex whereis --key`.
+
+I think this idea is worth doing something about, so I made this todo:
+[[todo/wherewas]].
+"""]]
diff --git a/doc/git-annex-whereused.mdwn b/doc/git-annex-whereused.mdwn
new file mode 100644
index 0000000000..e40457a2aa
--- /dev/null
+++ b/doc/git-annex-whereused.mdwn
@@ -0,0 +1,53 @@
+# NAME
+
+git-annex whereused - find what files use or used a key
+
+# SYNOPSIS
+
+git annex whereused `--key=keyname|--unused`
+
+# DESCRIPTION
+
+Finds what files use or used a key.
+
+For each file in the working tree that uses a key, this outputs one line,
+starting with the key, then a space, and then the name of the file.
+When multiple files use the same key, they will all be listed. When
+nothing is found that uses the key, there will be no output.
+
+The default is to find only files in the current working tree that use a
+key. The `--historical` option makes it also find past versions of files.
+
+# OPTIONS
+
+* `--key=keyname`
+
+  Operate on this key.
+
+* `--unused`
+
+  Operate on keys found by last run of git-annex unused.
+
+  Usually these keys won't be used by any files in the current working
+  tree, or any tags or branches. Combining this option with `--historical`
+  will find past uses of the keys.
+
+* `--historical`
+
+  When no files in the current working tree use a key, this causes more
+  work to be done, looking at past versions of the current branch, other
+  branches, tags, and the reflog, to find somewhere that the key was used.
+  It stops after finding one use of the key, and outputs a git rev that
+  refers to where it was used, eg "HEAD@{40}:somefile"
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-unused]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-whereused/comment_1_bebd4ad86c6a64cc48e6f0dd5861f3de._comment b/doc/git-annex-whereused/comment_1_bebd4ad86c6a64cc48e6f0dd5861f3de._comment
new file mode 100644
index 0000000000..53e2cf6434
--- /dev/null
+++ b/doc/git-annex-whereused/comment_1_bebd4ad86c6a64cc48e6f0dd5861f3de._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="jt"
+ avatar="http://cdn.libravatar.org/avatar/920cb5f2bc783736e679d046aa7cf987"
+ subject="Invalid argument `whereused'"
+ date="2023-05-05T14:04:06Z"
+ content="""
+```console
+% git annex whereused --help
+Invalid argument `whereused'
+
+Usage: git-annex COMMAND
+  git-annex - manage files with git, without checking their contents in
+
+...
+
+% git annex version
+git-annex version: 8.20210223
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+
+% uname -a
+Linux muaddib 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux
+```
+"""]]
diff --git a/doc/git-annex-whereused/comment_2_f926fbe7c558a242a2af949daed415f7._comment b/doc/git-annex-whereused/comment_2_f926fbe7c558a242a2af949daed415f7._comment
new file mode 100644
index 0000000000..9b7301ecc5
--- /dev/null
+++ b/doc/git-annex-whereused/comment_2_f926fbe7c558a242a2af949daed415f7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="out of date git-annex"
+ date="2023-05-05T14:19:41Z"
+ content="""
+Your git annex is very out of date, try updating. Also, the right place for reporting bugs is https://git-annex.branchable.com/bugs/
+"""]]
diff --git a/doc/git-annex-whereused/comment_3_bc04457bf320e81437c2eb858793c5ca._comment b/doc/git-annex-whereused/comment_3_bc04457bf320e81437c2eb858793c5ca._comment
new file mode 100644
index 0000000000..9634e1eb7b
--- /dev/null
+++ b/doc/git-annex-whereused/comment_3_bc04457bf320e81437c2eb858793c5ca._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-05-05T17:36:25Z"
+ content="""
+This command was first added in version 8.20210803.
+"""]]
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
new file mode 100644
index 0000000000..59dacb0229
--- /dev/null
+++ b/doc/git-annex.mdwn
@@ -0,0 +1,2203 @@
+# NAME
+
+git-annex - manage files with git, without checking their contents in
+
+# SYNOPSIS
+
+git annex command [params ...]
+
+# DESCRIPTION
+
+git-annex allows managing files with git, without checking the file
+contents into git. While that may seem paradoxical, it is useful when
+dealing with files larger than git can currently easily handle, whether due
+to limitations in memory, checksumming time, or disk space.
+
+Even without file content tracking, being able to manage files with git,
+move files around and delete files with versioned directory trees, and use
+branches and distributed clones, are all very handy reasons to use git. And
+annexed files can co-exist in the same git repository with regularly
+versioned files, which is convenient for maintaining documents, Makefiles,
+etc that are associated with annexed files but that benefit from full
+revision control.
+
+When a file is annexed, its content is moved into a key-value store, and
+a symlink is made that points to the content. These symlinks are checked into
+git and versioned like regular files. You can move them around, delete
+them, and so on. Pushing to another git repository will make git-annex
+there aware of the annexed file, and it can be used to retrieve its
+content from the key-value store.
+
+# EXAMPLES
+
+	# git annex get video/hackity_hack_and_kaxxt.mov
+	get video/hackity_hack_and_kaxxt.mov (not available)
+	  I was unable to access these remotes: server
+	  Try making some of these repositories available:
+	  	5863d8c0-d9a9-11df-adb2-af51e6559a49  -- my home file server
+	   	58d84e8a-d9ae-11df-a1aa-ab9aa8c00826  -- portable USB drive
+	   	ca20064c-dbb5-11df-b2fe-002170d25c55  -- backup SATA drive
+	failed
+	# sudo mount /media/usb
+	# git remote add usbdrive /media/usb
+	# git annex get video/hackity_hack_and_kaxxt.mov
+	get video/hackity_hack_and_kaxxt.mov (from usbdrive...) ok
+	
+	# git annex add iso
+	add iso/Debian_5.0.iso ok
+	
+	# git annex drop iso/Debian_4.0.iso
+	drop iso/Debian_4.0.iso ok
+	
+	# git annex move iso --to=usbdrive
+	move iso/Debian_5.0.iso (moving to usbdrive...) ok
+
+# COMMONLY USED COMMANDS
+
+* `help`
+
+  Display built-in help.
+
+  For help on a specific command, use `git annex help command`
+
+* `add [path ...]`
+
+  Adds files to the annex.
+  
+  See [[git-annex-add]](1) for details.
+
+* `get [path ...]`
+
+  Makes the content of annexed files available in this repository.
+  
+  See [[git-annex-get]](1) for details.
+
+* `drop [path ...]`
+
+  Drops the content of annexed files from this repository.
+  
+  See [[git-annex-drop]](1) for details.
+
+* `move [path ...] [--from=remote|--to=remote]`
+
+  Moves the content of files from or to another remote.
+
+  See [[git-annex-move]](1) for details.
+
+* `copy [path ...] [--from=remote|--to=remote]`
+
+  Copies the content of files from or to another remote.
+
+  See [[git-annex-copy]](1) for details.
+
+* `status [path ...]`
+
+  Show the working tree status. (deprecated)
+
+  See [[git-annex-status]](1) for details.
+
+* `unlock [path ...]`
+
+  Unlock annexed files for modification.
+  
+  See [[git-annex-unlock]](1) for details.
+
+* `edit [path ...]`
+
+  This is an alias for the unlock command. May be easier to remember,
+  if you think of this as allowing you to edit an annexed file.
+
+* `lock [path ...]`
+
+  Use this to undo an unlock command if you don't want to modify
+  the files, or have made modifications you want to discard.
+  
+  See [[git-annex-lock]](1) for details.
+
+* `pull [remote ...]`
+
+  Pull content from remotes.
+  
+  See [[git-annex-pull]](1) for details.
+
+* `push [remote ...]`
+
+  Push content to remotes.
+  
+  See [[git-annex-push]](1) for details.
+
+* `sync [remote ...]`
+
+  Synchronize local repository with remotes.
+  
+  See [[git-annex-sync]](1) for details.
+
+* `assist [remote ...]`
+
+  Add files and sync changes with remotes.
+  
+  See [[git-annex-assist]](1) for details.
+
+* `satisfy [remote ...]`
+
+  Satisfy preferred content settings by transferring and dropping content.
+  
+  See [[git-annex-satisfy]](1) for details.
+
+* `mirror [path ...] [--to=remote|--from=remote]`
+
+  Mirror content of files to/from another repository.
+  
+  See [[git-annex-mirror]](1) for details.
+
+* `addurl [url ...]`
+
+  Downloads each url to its own file, which is added to the annex.
+  
+  See [[git-annex-addurl]](1) for details.
+
+* `rmurl file url`
+
+  Record that the file is no longer available at the url.
+  
+  See [[git-annex-rmurl]](1) for details.
+
+* `import --from remote branch[:subdir] | [path ...]`
+
+  Add a tree of files to the repository.
+  
+  See [[git-annex-import]](1) for details.
+
+* `importfeed [url ...]`
+
+  Imports the contents of podcast feeds into the annex.
+  
+  See [[git-annex-importfeed]](1) for details.
+
+* `export treeish --to remote`
+
+  Export content to a remote.
+
+  See [[git-annex-export]](1) for details.
+
+* `undo [filename|directory] ...`
+
+  Undo last change to a file or directory.
+  
+  See [[git-annex-undo]](1) for details.
+
+* `multicast`
+
+  Multicast file distribution.
+
+  See [[git-annex-multicast]](1) for details.
+
+* `watch`
+
+  Daemon to watch for changes and autocommit.
+  
+  See [[git-annex-watch]](1) for details.
+
+* `assistant`
+
+  Daemon to automatically sync changes.
+
+  See [[git-annex-assistant]](1) for details.
+
+* `webapp`
+
+  Opens a web app, that allows easy setup of a git-annex repository,
+  and control of the git-annex assistant. If the assistant is not
+  already running, it will be started.
+
+  See [[git-annex-webapp]](1) for details.
+
+* `remotedaemon`
+
+  Persistant communication with remotes.
+
+  See [[git-annex-remotedaemon]](1) for details.
+
+# REPOSITORY SETUP COMMANDS
+
+* `init [description]`
+
+  Until a repository (or one of its remotes) has been initialized,
+  git-annex will refuse to operate on it, to avoid accidentally
+  using it in a repository that was not intended to have an annex.
+  
+  See [[git-annex-init]](1) for details.
+
+* `describe repository description`
+
+  Changes the description of a repository.
+  
+  See [[git-annex-describe]](1) for details.
+
+* `initremote name type=value [param=value ...]`
+
+  Creates a new special remote, and adds it to `.git/config`.
+
+  See [[git-annex-initremote]](1) for details.
+  
+* `enableremote name [param=value ...]`
+
+  Enables use of an existing special remote in the current repository.
+  
+  See [[git-annex-enableremote]](1) for details.
+
+* `configremote name [param=value ...]`
+
+  Changes configuration of an existing special remote.
+  
+  See [[git-annex-configremote]](1) for details.
+
+
+* `renameremote`
+
+  Renames a special remote.
+
+  See [[git-annex-renameremote]](1) for details.
+
+* `enable-tor`
+
+  Sets up tor hidden service.
+  
+  See [[git-annex-enable-tor]](1) for details.
+
+* `numcopies [N]`
+
+  Configure desired number of copies.
+  
+  See [[git-annex-numcopies]](1) for details.
+
+* `mincopies [N]`
+
+  Configure minimum number of copies.
+  
+  See [[git-annex-mincopies]](1) for details.
+
+* `trust [repository ...]`
+
+  Records that a repository is trusted to not unexpectedly lose
+  content. Use with care.
+  
+  See [[git-annex-trust]](1) for details.
+
+* `untrust [repository ...]`
+
+  Records that a repository is not trusted and could lose content
+  at any time.
+  
+  See [[git-annex-untrust]](1) for details.
+
+* `semitrust [repository ...]`
+
+  Returns a repository to the default semi trusted state.
+  
+  See [[git-annex-semitrust]](1) for details.
+
+* `group repository groupname`
+
+  Add a repository to a group.
+  
+  See [[git-annex-group]](1) for details.
+
+* `ungroup repository groupname`
+
+  Removes a repository from a group.
+  
+  See [[git-annex-ungroup]](1) for details.
+
+* `wanted repository [expression]`
+  
+  Get or set preferred content expression.
+
+  See [[git-annex-wanted]](1) for details.
+
+* `groupwanted groupname [expression]`
+
+  Get or set groupwanted expression.
+
+  See [[git-annex-groupwanted]](1) for details.
+
+* `required repository [expression]`
+  
+  Get or set required content expression.
+  
+  See [[git-annex-required]](1) for details.
+
+* `schedule repository [expression]`
+
+  Get or set scheduled jobs.
+
+  See [[git-annex-schedule]](1) for details.
+
+* `config`
+
+  Get and set other configuration stored in git-annex branch.
+  
+  See [[git-annex-config]](1) for details.
+
+* `vicfg`
+
+  Opens EDITOR on a temp file containing most of the above configuration
+  settings, as well as a few others, and when it exits, stores any changes
+  made back to the git-annex branch.
+  
+  See [[git-annex-vicfg]](1) for details.
+
+* `adjust`
+
+  Switches a repository to use an adjusted branch, which can automatically
+  unlock all files, etc.
+  
+  See [[git-annex-adjust]](1) for details.
+
+* `direct`
+
+  Switches a repository to use direct mode. (deprecated)
+  
+  See [[git-annex-direct]](1) for details.
+
+* `indirect`
+
+  Switches a repository to use indirect mode. (deprecated)
+  
+  See [[git-annex-indirect]](1) for details.
+
+# REPOSITORY MAINTENANCE COMMANDS
+
+* `fsck [path ...]`
+
+  Checks the annex consistency, and warns about or fixes any problems found. 
+  This is a good complement to `git fsck`.
+
+  See [[git-annex-fsck]](1) for details.
+
+* `expire [repository:]time ...`
+
+  Expires repositories that have not recently performed an activity
+  (such as a fsck).
+
+  See [[git-annex-expire]](1) for details.
+
+* `unused`
+
+  Checks the annex for data that does not correspond to any files present
+  in any tag or branch, and prints a numbered list of the data.
+  
+  See [[git-annex-unused]](1) for details.
+
+* `dropunused [number|range ...]`
+
+  Drops the data corresponding to the numbers, as listed by the last
+  `git annex unused`
+  
+  See [[git-annex-dropunused]](1) for details.
+
+* `addunused [number|range ...]`
+
+  Adds back files for the content corresponding to the numbers or ranges,
+  as listed by the last `git annex unused`.
+  
+  See [[git-annex-addunused]](1) for details.
+
+* `fix [path ...]`
+
+  Fixes up symlinks that have become broken to again point to annexed content.
+
+  See [[git-annex-fix]](1) for details.
+
+* `merge`
+
+  Automatically merge changes from remotes.
+
+  See [[git-annex-merge]](1) for details.
+
+* `upgrade`
+
+  Upgrades the repository.
+  
+  See [[git-annex-upgrade]](1) for details.
+
+* `dead [repository ...] [--key key]`
+
+  Indicates that a repository or a single key has been irretrievably lost.
+  
+  See [[git-annex-dead]](1) for details.
+
+* `forget`
+
+  Causes the git-annex branch to be rewritten, throwing away historical
+  data about past locations of files.
+  
+  See [[git-annex-forget]](1) for details.
+
+* `filter-branch`
+
+  Produces a filtered version of the git-annex branch.
+  
+  See [[git-annex-filter-branch]](1) for details.
+
+* `repair`
+
+  This can repair many of the problems with git repositories that `git fsck`
+  detects, but does not itself fix. It's useful if a repository has become
+  badly damaged. One way this can happen is if a repository used by git-annex
+  is on a removable drive that gets unplugged at the wrong time.
+  
+  See [[git-annex-repair]](1) for details.
+
+* `p2p`
+
+  Configure peer-2-Peer links between repositories.
+
+  See [[git-annex-p2p]](1) for details.
+
+# QUERY COMMANDS
+
+* `find [path ...]`
+
+  Outputs a list of annexed files in the specified path. With no path,
+  finds files in the current directory and its subdirectories.
+
+  See [[git-annex-find]](1) for details.
+
+* `whereis [path ...]`
+
+  Displays information about where the contents of files are located.
+  
+  See [[git-annex-whereis]](1) for details.
+
+* `list [path ...]`
+
+  Displays a table of remotes that contain the contents of the specified
+  files. This is similar to whereis but a more compact display.
+  
+  See [[git-annex-list]](1) for details.
+
+* `whereused`
+
+  Finds what files use or used a key.
+
+* `log [path ...]`
+
+  Displays the location log for the specified file or files,
+  showing each repository they were added to ("+") and removed from ("-").
+
+  See [[git-annex-log]](1) for details.
+
+* `oldkeys [path ...]`
+
+  List keys used for old versions of files.
+  
+  See [[git-annex-oldkeys]](1) for details.
+
+* `info [directory|file|remote|uuid ...]`
+
+  Displays statistics and other information for the specified item,
+  which can be a directory, or a file, or a remote, or the uuid of a
+  repository. 
+
+  When no item is specified, displays statistics and information
+  for the repository as a whole.
+  
+  See [[git-annex-info]](1) for details.
+
+* `version`
+
+  Shows the version of git-annex, as well as repository version information.
+  
+  See [[git-annex-version]](1) for details.
+
+* `map`
+
+  Generate map of repositories.
+
+  See [[git-annex-map]](1) for details.
+
+* `inprogress`
+
+  Access files while they're being downloaded.
+
+  See [[git-annex-inprogress]](1) for details.
+
+* `findkeys`
+
+  Similar to `git-annex find`, but operating on keys.
+
+  See [[git-annex-findkeys]](1) for details.
+
+# METADATA COMMANDS
+
+* `metadata [path ...]`
+
+  The content of an annexed file can have any number of metadata fields
+  attached to it to describe it. Each metadata field can in turn
+  have any number of values.
+
+  This command can be used to set metadata, or show the currently set
+  metadata.
+
+  See [[git-annex-metadata]](1) for details.
+
+* `view [tag ...] [field=value ...] [field=glob ...] [?tag ...] [field?=glob] [!tag ...] [field!=value ...]`
+
+  Uses metadata to build a view branch of the files in the current branch,
+  and checks out the view branch. Only files in the current branch whose
+  metadata matches all the specified field values and tags will be
+  shown in the view.
+
+  See [[git-annex-view]](1) for details.
+
+* `vpop [N]`
+
+  Switches from the currently active view back to the previous view.
+  Or, from the first view back to original branch.
+ 
+  See [[git-annex-vpop]](1) for details.
+
+* `vfilter [tag ...] [field=value ...] [!tag ...] [field!=value ...]`
+
+  Filters the current view to only the files that have the
+  specified field values and tags.
+  
+  See [[git-annex-vfilter]](1) for details.
+
+* `vadd [field=glob ...] [field=value ...] [tag ...]`
+
+  Changes the current view, adding an additional level of directories
+  to categorize the files.
+  
+  See [[git-annex-vfilter]](1) for details.
+
+* `vcycle`
+
+  When a view involves nested subdirectories, this cycles the order.
+  
+  See [[git-annex-vcycle]](1) for details.
+
+# UTILITY COMMANDS
+
+* `migrate [path ...]`
+
+  Changes the specified annexed files to use a different key-value backend.
+  
+  See [[git-annex-migrate]](1) for details.
+
+* `reinject src dest`
+
+  Moves the src file into the annex as the content of the dest file.
+  This can be useful if you have obtained the content of a file from
+  elsewhere and want to put it in the local annex.
+
+  See [[git-annex-reinject]](1) for details.
+
+* `unannex [path ...]`
+
+  Use this to undo an accidental `git annex add` command. It puts the
+  file back how it was before the add.
+  
+  See [[git-annex-unannex]](1) for details.
+
+* `uninit`
+
+  De-initialize git-annex and clean out repository.
+  
+  See [[git-annex-uninit]](1) for details.
+
+* `reinit uuid|description`
+
+  Initialize repository, reusing old UUID.
+  
+  See [[git-annex-reinit]](1) for details.
+
+# PLUMBING COMMANDS
+
+* `pre-commit [path ...]`
+
+  This is meant to be called from git's pre-commit hook. `git annex init`
+  automatically creates a pre-commit hook using this.
+  
+  See [[git-annex-pre-commit]](1) for details.
+
+* `post-receive`
+
+  This is meant to be called from git's post-receive hook. `git annex init`
+  automatically creates a post-receive hook using this.
+  
+  See [[git-annex-post-receive]](1) for details.
+
+* `lookupkey [file ...]`
+
+  Looks up key used for file.
+
+  See [[git-annex-lookupkey]](1) for details.
+
+* `calckey [file ...]`
+
+  Calculates the key that would be used to refer to a file.
+  
+  See [[git-annex-calckey]](1) for details.
+
+* `contentlocation [key ..]`
+
+  Looks up location of annexed content for a key.
+
+  See [[git-annex-contentlocation]](1) for details.
+
+* `examinekey [key ...]`
+
+  Print information that can be determined purely by looking at the key.
+  
+  See [[git-annex-examinekey]](1) for details.
+
+* `matchexpression`
+
+  Checks if a preferred content expression matches provided data.
+  
+  See [[git-annex-matchexpression]](1) for details.
+
+* `fromkey [key file]`
+
+  Manually set up a file in the git repository to link to a specified key.
+  
+  See [[git-annex-fromkey]](1) for details.
+
+* `registerurl [key url]`
+
+  Registers an url for a key.
+  
+  See [[git-annex-registerurl]](1) for details.
+  
+* `unregisterurl [key url]`
+
+  Unregisters an url for a key.
+  
+  See [[git-annex-unregisterurl]](1) for details.
+
+* `reregisterurl [key url]`
+
+  Updates url registration information.
+  
+  See [[git-annex-reregisterurl]](1) for details.
+
+* `setkey key file`
+
+  Moves a file into the annex as the content of a key.
+  
+  See [[git-annex-setkey]](1) for details.
+
+* `dropkey [key ...]`
+
+  Drops annexed content for specified keys.
+  
+  See [[git-annex-dropkey]](1) for details.
+
+* `transferkey key [--from=remote|--to=remote]`
+
+  Transfers a key from or to a remote.
+  
+  See [[git-annex-transferkey]](1) for details.
+
+* `transferrer`
+  
+  Used internally by git-annex to transfer content.
+
+  See [[git-annex-transferrer]](1) for details.
+
+* `transferkeys`
+  
+  Used internally by old versions of the assistant.
+
+  See [[git-annex-transferkey]](1) for details.
+
+* `setpresentkey key uuid [1|0]`
+
+  This plumbing-level command changes git-annex's records about whether
+  the specified key's content is present in a remote with the specified uuid.
+
+  See [[git-annex-setpresentkey]](1) for details.
+
+* `readpresentkey key uuid`
+
+  Read records of where key is present.
+
+  See [[git-annex-readpresentkey]](1) for details.
+
+* `checkpresentkey key remote`
+
+  Check if key is present in remote.
+  
+  See [[git-annex-checkpresentkey]](1) for details.
+
+* `rekey [file key ...]`
+
+  Change keys used for files.
+  
+  See [[git-annex-rekey]](1) for details.
+
+* `resolvemerge`
+
+  Resolves a conflicted merge, by adding both conflicting versions of the
+  file to the tree, using variants of their filename. This is done
+  automatically when using `git annex sync` or `git-annex pull`
+  or `git annex merge`.
+
+  See [[git-annex-resolvemerge]](1) for details.
+
+* `diffdriver`
+
+  This can be used to make `git diff` diff the content of annexed files.
+
+  See [[git-annex-diffdriver]](1) for details.
+
+* `smudge`
+
+  This command lets git-annex be used as a git filter driver, allowing
+  annexed files in the git repository to be unlocked regular files instead
+  of symlinks.
+
+  See [[git-annex-smudge]](1) for details.
+
+* `filter-process`
+
+  An alternative implementation of a git filter driver, that is faster
+  in some situations and slower in others than `git-annex smudge`.
+
+  See [[git-annex-filter-process]](1) for details.
+
+* `restage`
+  
+  Restages unlocked files in the git index.
+
+  See [[git-annex-restage]](1) for details.
+
+* `findref [ref]`
+
+  Lists files in a git ref. (deprecated)
+  
+  See [[git-annex-findref]](1) for details.
+
+* `proxy -- git cmd [options]`
+
+  Bypass direct mode guard. (deprecated)
+  
+  See [[git-annex-proxy]](1) for details.
+
+# TESTING COMMANDS
+
+* `test`
+
+  This runs git-annex's built-in test suite.
+  
+  See [[git-annex-test]](1) for details.
+
+* `testremote remote`
+
+  This tests a remote by generating some random objects and sending them to
+  the remote, then redownloading them, removing them from the remote, etc.
+
+  It's safe to run in an existing repository (the repository contents are
+  not altered), although it may perform expensive data transfers.
+  
+  See [[git-annex-testremote]](1) for details.
+
+* `fuzztest`
+
+  Generates random changes to files in the current repository,
+  for use in testing the assistant.
+  
+  See [[git-annex-fuzztest]](1) for details.
+
+* `benchmark`
+
+  This runs git-annex's built-in benchmarks, if it was built with
+  benchmarking support.
+  
+  See [[git-annex-benchmark]](1) for details.
+
+# ADDON COMMANDS
+
+In addition to all the commands listed above, more commands can be added to
+git-annex by dropping commands named like "git-annex-foo" into a directory
+in the PATH.
+
+# CONFIGURATION
+
+Like other git commands, git-annex is configured via `.git/config`.
+These settings, as well as relevant git config settings, are
+the ones git-annex uses.
+
+(Some of these settings can also be set, across all clones of the
+repository, using [[git-annex-config]]. See its man page for a list.)
+
+* `annex.uuid`
+
+  A unique UUID for this repository (automatically set).
+
+* `annex.backend`
+
+  Name of the default key-value backend to use when adding new files
+  to the repository. See [[git-annex-backends]](1) for information about
+  available backends.
+
+  This is overridden by annex annex.backend configuration in the
+  .gitattributes files, and by the --backend option.
+
+  (This used to be named `annex.backends`, and that will still be used
+  if set.)
+
+* `annex.securehashesonly`
+
+  Set to true to indicate that the repository should only use
+  cryptographically secure hashes (SHA2, SHA3) and not insecure
+  hashes (MD5, SHA1) for content.
+
+  When this is set, the contents of files using cryptographically
+  insecure hashes will not be allowed to be added to the repository.
+
+  Also, `git-annex fsck` will complain about any files present in
+  the repository that use insecure hashes. And, 
+  `git-annex import --no-content` will refuse to import files
+  from special remotes using insecure hashes.
+
+  To configure the behavior in new clones of the repository,
+  this can be set using [[git-annex-config]].
+
+* `annex.maxextensionlength`
+
+  Maximum length, in bytes, of what is considered a filename extension.
+  This is used when adding a file to a backend that preserves filename extensions,
+  and also when generating a view branch.
+
+  The default length is 4, which allows extensions like "jpeg". The dot before
+  the extension is not counted part of its length.
+
+* `annex.maxextensions`
+
+  Maximum number of filename extensions to preserve when using a backend
+  that preserves filename extensions, and also when generating a view
+  branch.
+
+  The default is 2, which allows for compound extensions like ".tar.gz".
+  When set to 1, it will only preserve the last extension, eg ".gz".
+
+* `annex.diskreserve`
+
+  Amount of disk space to reserve. Disk space is checked when transferring
+  annexed content to avoid running out, and additional free space can be
+  reserved via this option, to make space for other data (such as git 
+  commit logs). Can be specified with any commonly used units, for 
+  example, "0.5 gb", "500M", or "100 KiloBytes"
+
+  The default reserve is 100 megabytes.
+
+* `annex.skipunknown`
+
+  Set to true to make commands like "git-annex get" silently skip over
+  items that are listed in the command line, but are not checked into git.
+
+  Set to false to make it an error for commands like "git-annex get"
+  to be asked to operate on files that are not checked into git.
+  (This is the default in recent versions of git-annex.)
+
+  Note that, when annex.skipunknown is false, a command like "git-annex get
+  ." will fail if no files in the current directory are checked into git.
+  Commands like "git-annex get foo/" will fail if no files in the directory
+  are checked into git, but if at least one file is, it will ignore other
+  files that are not. This is all the same as the behavior of "git-ls files
+  --error-unmatch".
+  
+  Also note that git-annex skips files that are checked into git, but are
+  not annexed files; this setting does not affect that.
+
+* `annex.largefiles`
+
+  Used to configure which files are large enough to be added to the annex.
+  It is an expression that matches the large files, eg
+  "`include=*.mp3 or largerthan=500kb`"
+  See [[git-annex-matching-expression]](1) for details on the syntax.
+
+  Overrides any annex.largefiles attributes in `.gitattributes` files.
+  
+  To configure a default annex.largefiles for all clones of the repository,
+  this can be set in [[git-annex-config]](1).
+
+  This configures the behavior of both git-annex and git when adding
+  files to the repository. By default, `git-annex add` adds all files
+  to the annex (except dotfiles), and `git add` adds files to git
+  (unless they were added to the annex previously).
+  When annex.largefiles is configured, both
+  `git annex add` and `git add` will add matching large files to the
+  annex, and the other files to git.
+
+  Other git-annex commands also honor annex.largefiles, including
+  `git annex import`, `git annex addurl`, `git annex importfeed`,
+  `git-annex assist`, and the `git-annex assistant`.
+
+* `annex.dotfiles`
+
+  Normally, dotfiles are assumed to be files like .gitignore,
+  whose content should always be part of the git repository, so 
+  they will not be added to the annex. Setting annex.dotfiles to true
+  makes dotfiles be added to the annex the same as any other file. 
+
+  To annex only some dotfiles, set this and configure annex.largefiles
+  to match the ones you want. For example, to match only dotfiles ending 
+  in ".big"
+
+	git config annex.largefiles "(include=.*.big or include=*/.*.big) or (exclude=.* and exclude=*/.*)"
+  	git config annex.dotfiles true
+  
+  To configure a default annex.dotfiles for all clones of the repository,
+  this can be set in [[git-annex-config]](1).
+
+* `annex.gitaddtoannex`
+
+  Setting this to false will prevent `git add` from adding
+  files to the annex, despite the annex.largefiles configuration.
+
+* `annex.addsmallfiles`
+
+  Controls whether small files (not matching annex.largefiles)
+  should be checked into git by `git annex add`. Defaults to true;
+  set to false to instead make small files be skipped.
+
+* `annex.addunlocked`
+
+  Commands like `git-annex add` default to adding files to the repository
+  in locked form. This can make them add the files in unlocked form,
+  the same as if [[git-annex-unlock]](1) were run on the files.
+
+  This can be set to "true" to add everything unlocked, or it can be a more
+  complicated expression that matches files by name, size, or content. See
+  [[git-annex-matching-expression]](1) for details.
+  
+  To configure a default annex.addunlocked for all clones of the repository,
+  this can be set in [[git-annex-config]](1).
+  
+  (Using `git add` always adds files in unlocked form and it is not
+  affected by this setting.)
+  
+  When a repository has core.symlinks set to false, or has an adjusted 
+  unlocked branch checked out, this setting is ignored, and files are 
+  always added to the repository in unlocked form.
+
+* `annex.numcopies`
+
+  This is a deprecated setting. You should instead use the
+  `git annex numcopies` command to configure how many copies of files
+  are kept across all repositories, or the annex.numcopies .gitattributes
+  setting.
+
+  This config setting is only looked at when `git annex numcopies` has
+  never been configured, and when there's no annex.numcopies setting in the
+  .gitattributes file.
+
+* `annex.genmetadata`
+
+  Set this to `true` to make git-annex automatically generate some metadata
+  when adding files to the repository.
+
+  In particular, it stores year, month, and day metadata, from the file's
+  modification date.
+
+  When importfeed is used, it stores additional metadata from the feed,
+  such as the author, title, etc.
+
+* `annex.used-refspec`
+
+  This controls which refs `git-annex unused` considers to be used.
+  See REFSPEC FORMAT in [[git-annex-unused]](1) for details.
+
+* `annex.jobs`
+
+  Configure the number of concurrent jobs to run. Default is 1.
+
+  Only git-annex commands that support the --jobs option will
+  use this.
+
+  Setting this to "cpus" will run one job per CPU core.
+
+  When the `--batch` option is used, this configuration is ignored.
+
+* `annex.adjustedbranchrefresh`
+
+  When [[git-annex-adjust]](1) is used to set up an adjusted branch
+  that needs to be refreshed after getting or dropping files, this config
+  controls how frequently the branch is refreshed. 
+
+  Refreshing the branch takes some time, so doing it after every file
+  can be too slow. (It also can generate a lot of dangling git objects.)
+  The default value is 0 (or false), which does not
+  refresh the branch. Setting 1 (or true) will refresh only once, 
+  after git-annex has made other changes. Setting 2 refreshes after every
+  file, 3 after every other file, and so on; setting 100 refreshes after
+  every 99 files.
+
+  (If git-annex gets faster in the future, refresh rates will increase
+  proportional to the speed improvements.)
+
+* `annex.queuesize`
+
+  git-annex builds a queue of git commands, in order to combine similar
+  commands for speed. By default the size of the queue is limited to
+  10240 commands; this can be used to change the size. If you have plenty
+  of memory and are working with very large numbers of files, increasing
+  the queue size can speed it up.
+
+* `annex.bloomcapacity`
+
+  The `git annex unused` and `git annex sync --content` commands use
+  a bloom filter to determine what files are present in eg, the work tree.
+  The default bloom filter is sized to handle
+  up to 500000 files. If your repository is larger than that,
+  you should increase this value. Larger values will
+  make `git-annex unused` and `git annex sync --content` consume more memory;
+  run `git annex info` for memory usage numbers.
+
+* `annex.bloomaccuracy`
+
+  Adjusts the accuracy of the bloom filter used by
+  `git annex unused` and `git annex sync --content`. 
+  The default accuracy is 10000000 -- 1 unused file out of 10000000
+  will be missed by `git annex unused`. Increasing the accuracy will make
+  `git annex unused` consume more memory; run `git annex info`
+  for memory usage numbers.
+
+* `annex.sshcaching`
+
+  By default, git-annex caches ssh connections using ssh's
+  ControlMaster and ControlPersist settings
+  (if built using a new enough ssh). To disable this, set to `false`.
+
+* `annex.adviceNoSshCaching`
+
+  When git-annex is unable to use ssh connection caching, or has been
+  configured not to, and concurrency is enabled, it will warn that
+  this might result in multiple ssh processes prompting for passwords
+  at the same time. To disable that warning, eg if you have configured ssh
+  connection caching yourself, or have ssh agent caching passwords, 
+  set this to `false`.
+
+* `annex.alwayscommit`
+
+  By default, git-annex automatically commits data to the git-annex branch
+  after each command is run. If you have a series
+  of commands that you want to make a single commit, you can
+  run the commands with `-c annex.alwayscommit=false`. You can later
+  commit the data by running `git annex merge` (or by automatic merges)
+  or `git annex sync`.
+
+* `annex.commitmessage`
+
+  When git-annex updates the git-annex branch, it usually makes up
+  its own commit message (eg "update"), since users rarely look at or
+  care about changes to that branch. If you do care, you can
+  specify this setting by running commands with
+  `-c annex.commitmessage=whatever`
+
+  This works well in combination with annex.alwayscommit=false,
+  to gather up a set of changes and commit them with a message you specify.
+
+* `annex.commitmessage-command`
+
+  This command is run and its output is used as the commit message to the
+  git-annex branch.
+
+* `annex.alwayscompact`
+
+  By default, git-annex compacts data it records in the git-annex branch.
+  Setting this to false avoids doing that compaction in some cases, which
+  can speed up operations that populate the git-annex branch with a lot
+  of data. However, when used with operations that overwrite old values in
+  the git-annex branch, that may cause the git-annex branch to use more disk
+  space, and so slow down reading data from it.
+
+  An example of a command that can be sped up by using 
+  `-c annex.alwayscompact=false` is `git-annex registerurl --batch`,
+  when adding a large number of urls to the same key.
+
+  This option was first supported by git-annex version 10.20220724.
+  It is not entirely safe to set this option in a repository that may also
+  be used by an older version of git-annex at the same time as a version
+  that supports this option.
+
+* `annex.allowsign`
+
+  By default git-annex avoids gpg signing commits that it makes when
+  they're not the purpose of a command, but only a side effect.
+  That default avoids lots of gpg password prompts when
+  commit.gpgSign is set. A command like `git annex sync` or `git annex merge`
+  will gpg sign its commit, but a command like `git annex get`,
+  that updates the git-annex branch, will not. The assistant also avoids
+  signing commits.
+
+  Setting annex.allowsign to true lets all commits be signed, as
+  controlled by commit.gpgSign and other git configuration.
+
+* `annex.merge-annex-branches`
+
+  By default, git-annex branches that have been pulled from remotes
+  are automatically merged into the local git-annex branch, so that
+  git-annex has the most up-to-date possible knowledge.
+
+  To avoid that merging, set this to "false". 
+
+  This can be useful particularly when you don't have write permission
+  to the repository. While git-annex is mostly able to work in a read-only
+  repository with unmerged git-annex branches, some things do not work,
+  and when it does work it will be slower due to needing to look at each of
+  the unmerged branches.
+
+* `annex.private`
+
+  When this is set to true, no information about the repository will be
+  recorded in the git-annex branch.
+
+  For example, to make a repository without any mention of it ever
+  appearing in the git-annex branch:
+
+	git init myprivate
+	cd myprivaterepo
+	git config annex.private true
+	git annex init
+
+* `annex.hardlink`
+
+  Set this to `true` to make file contents be hard linked between the
+  repository and its remotes when possible, instead of a more expensive copy.
+
+  Use with caution -- This can invalidate numcopies counting, since
+  with hard links, fewer copies of a file can exist. So, it is a good
+  idea to mark a repository using this setting as untrusted.
+
+  When a repository is set up using `git clone --shared`, git-annex init
+  will automatically set annex.hardlink and mark the repository as
+  untrusted.
+
+  When `annex.thin` is also set, setting `annex.hardlink` has no effect.
+
+* `annex.thin`
+
+  Set this to `true` to make unlocked files be a hard link to their content
+  in the annex, rather than a second copy. This can save considerable
+  disk space, but when a modification is made to a file, you will lose the
+  local (and possibly only) copy of the old version. Any other, locked
+  files in the repository that pointed to that content will get broken
+  as well (`git-annex fsck` will detect and clean up after that). 
+  So, enable this with care.
+
+  After setting (or unsetting) this, you should run `git annex fix` to
+  fix up the annexed files in the work tree to be hard links (or copies).
+ 
+  Note that this has no effect when the filesystem does not support hard links.
+  And when multiple files in the work tree have the same content, only
+  one of them gets hard linked to the annex.
+
+* `annex.supportunlocked`
+
+  By default git-annex supports unlocked files as well as locked files,
+  so this defaults to true. If set to false, git-annex will only support
+  locked files. That will avoid doing the work needed to support unlocked
+  files.
+
+  Note that setting this to false does not prevent a repository from
+  having unlocked files added to it, and in that case the content of the
+  files will not be accessible until they are locked.
+
+  After changing this config, you need to re-run `git-annex init` for it
+  to take effect.
+
+* `annex.resolvemerge`
+
+  Set to false to prevent merge conflicts in the checked out branch
+  being automatically resolved by the `git-annex assitant`,
+  `git-annex assist`, `git-annex sync`, `git-annex pull`, `git-annex merge`,
+  and the git-annex post-receive hook.
+
+  To configure the behavior in all clones of the repository,
+  this can be set in [[git-annex-config]](1).
+
+* `annex.synccontent`
+
+  Set to true to make `git-annex sync` default to transferring
+  annexed content.
+
+  Set to false to prevent `git-annex assist`, `git-annex pull` and
+  `git-annex push` from transferring annexed content.
+
+  To configure the behavior in all clones of the repository,
+  this can be set in [[git-annex-config]](1).
+
+* `annex.synconlyannex`
+
+  Set to true to make `git-annex assist`, `git-annex sync`, 
+  `git-annex pull`, and `git-annex push` default to only operating
+  on the git-annex branch and annexed content.
+
+  To configure the behavior in all clones of the repository,
+  this can be set in [[git-annex-config]](1).
+
+* `annex.syncmigrations`
+
+  Set to false to prevent `git-annex sync` and `git-annex pull`
+  from scanning for migrations and updating the local 
+  repository for those migrations.
+
+* `annex.viewunsetdirectory`
+
+  This configures the name of a directory that is used in a view to contain
+  files that do not have metadata set. The default name for the directory 
+  is `"_"`. See [[git-annex-view]](1) for details.
+
+* `annex.debug`
+
+  Set to true to enable debug logging by default.
+
+* `annex.debugfilter`
+
+  Set to configure which debug messages to display (when debug message
+  display has been enabled by annex.debug or --debug). The value is one
+  or more module names, separated by commas.
+
+* `annex.version`
+
+  The current version of the git-annex repository. This is
+  maintained by git-annex and should never be manually changed.
+
+* `annex.autoupgraderepository`
+
+  When an old git-annex repository version is no longer supported,
+  git-annex will normally automatically upgrade the repository to
+  the new version. It may also sometimes upgrade from an old repository
+  version that is still supported but that is not as good as a later
+  version.
+
+  If this is set to false, git-annex won't automatically upgrade the
+  repository. If the repository version is not supported, git-annex
+  will instead exit with an error message. If it is still supported,
+  git-annex will continue to work.
+
+  You can run `git annex upgrade` yourself when you are ready to upgrade the
+  repository.
+
+* `annex.crippledfilesystem`
+
+  Set to true if the repository is on a crippled filesystem, such as FAT,
+  which does not support symbolic links, or hard links, or unix permissions.
+  This is automatically probed by "git annex init".
+
+* `annex.pidlock`
+
+  Normally, git-annex uses fine-grained lock files to allow multiple
+  processes to run concurrently without getting in each others' way.
+  That works great, unless you are using git-annex on a filesystem that
+  does not support POSIX fcntl locks. This is sometimes the case when
+  using NFS or Lustre filesystems. 
+  
+  To support such situations, you can set annex.pidlock to true, and it
+  will fall back to a single top-level pid file lock.
+
+  Although, often, you'd really be better off fixing your networked
+  filesystem configuration to support POSIX locks.. And, some networked
+  filesystems are so inconsistent that one node can't reliably tell when
+  the other node is holding a pid lock. Caveat emptor.
+
+* `annex.pidlocktimeout`
+  
+  git-annex will wait up to this many seconds for the pid lock
+  file to go away, and will then abort if it cannot continue. Default: 300
+
+  When using pid lock files, it's possible for a stale lock file to get
+  left behind by previous run of git-annex that crashed or was interrupted.
+  This is mostly avoided, but can occur especially when using a network
+  file system. This timeout prevents git-annex waiting forever in such a
+  situation.
+
+* `annex.dbdir`
+
+  The directory where git-annex should store its sqlite databases.
+  The default location is inside `.git/annex/`. 
+
+  Certian filesystems, such as cifs, may not support locking operations
+  that sqlite needs, and setting this to a directory on another filesystem
+  can work around such a problem.
+
+  This can safely be set to the same directory in the configuration of
+  multiple repositories; each repository will use a subdirectory for its
+  sqlite database.
+
+* `annex.cachecreds`
+
+  When "true" (the default), git-annex will cache credentials used to
+  access special remotes in files in .git/annex/creds/
+  that only you can read. To disable that caching, set to "false",
+  and credentials will only be read from the environment, or if
+  they have been embedded in encrypted form in the git repository, will
+  be extracted and decrypted each time git-annex needs to access the
+  remote.
+
+* `annex.secure-erase-command`
+
+  This can be set to a command that should be run whenever git-annex
+  removes the content of a file from the repository.
+
+  In the command line, %file is replaced with the file that should be
+  erased.
+
+  For example, to use the wipe command, set it to `wipe -f %file`.
+
+* `annex.freezecontent-command`, `annex.thawcontent-command`
+
+  Usually the write permission bits are unset to protect annexed objects
+  from being modified or deleted. The freezecontent-command is run after
+  git-annex has removed (or attempted to remove) the write bit, and can
+  be used to prevent writing in some other way.
+  The thawcontent-command should undo its effect, and is run before
+  git-annex restores the write bit.
+
+  In the command line, %path is replaced with the file or directory to
+  operate on.
+
+  (When annex.crippledfilesystem is set, git-annex will not try to
+  remove/restore the write bit, but it will still run these hooks.)
+
+* `annex.tune.objecthash1`, `annex.tune.objecthashlower`, `annex.tune.branchhash1`
+
+  These can be passed to `git annex init` to tune the repository.
+  They cannot be safely changed in a running repository and should never be
+  set in global git configuration.
+  For details, see <https://git-annex.branchable.com/tuning/>.
+
+# CONFIGURATION OF REMOTES
+
+Remotes are configured using these settings in `.git/config`.
+
+* `remote.<name>.annex-cost`
+
+  When determining which repository to
+  transfer annexed files from or to, ones with lower costs are preferred.
+  The default cost is 100 for local repositories, and 200 for remote
+  repositories.
+
+* `remote.<name>.annex-cost-command`
+
+  If set, the command is run, and the number it outputs is used as the cost.
+  This allows varying the cost based on e.g., the current network.
+
+* `remote.<name>.annex-start-command`
+
+  A command to run when git-annex begins to use the remote. This can
+  be used to, for example, mount the directory containing the remote.
+
+  The command may be run repeatedly when multiple git-annex processes
+  are running concurrently.
+
+* `remote.<name>.annex-stop-command`
+
+  A command to run when git-annex is done using the remote.
+
+  The command will only be run once *all* running git-annex processes
+  are finished using the remote.
+
+* `remote.<name>.annex-shell`
+
+  Specify an alternative git-annex-shell executable on the remote
+  instead of looking for "git-annex-shell" on the PATH.
+
+  This is useful if the git-annex-shell program is outside the PATH
+  or has a non-standard name.
+
+* `remote.<name>.annex-ignore`
+
+  If set to `true`, prevents git-annex from storing or retrieving annexed
+  file contents on this remote by default. 
+  (You can still request it be used with the `--from` and `--to` options.)
+
+  This is, for example, useful if the remote is located somewhere
+  without git-annex-shell. (For example, if it's on GitHub).
+  Or, it could be used if the network connection between two
+  repositories is too slow to be used normally.
+
+  This does not prevent `git-annex sync`, `git-annex pull`, `git-annex push`,
+  `git-annex assist` or the `git-annex assistant` from operating on the
+  git repository. It only affects annexed content.
+
+* `remote.<name>.annex-ignore-command`
+
+  If set, the command is run, and if it exits nonzero, that's the same
+  as setting annex-ignore to true. This allows controlling behavior based
+  on e.g., the current network.
+
+* `remote.<name>.annex-sync`
+
+  If set to `false`, prevents `git-annex sync` (and `git-annex pull`, 
+  `git-annex push`, `git-annex assist`, and the `git-annex assistant`)
+  from operating on this remote by default.
+
+* `remote.<name>.annex-sync-command`
+
+  If set, the command is run, and if it exits nonzero, that's the same
+  as setting annex-sync to false. This allows controlling behavior based
+  on e.g., the current network.
+
+* `remote.<name>.annex-pull`
+
+  If set to `false`, prevents `git-annex pull`, `git-annex sync`,
+  `git-annex assist` and the `git-annex assistant` from ever pulling
+  (or fetching) from the remote.
+
+* `remote.<name>.annex-push`
+
+  If set to `false`, prevents `git-annex push`, `git-annex sync`,
+  `git-annex assist` and the `git-annex assistant` from ever pushing
+  to the remote.
+
+* `remote.<name>.annex-readonly`
+
+  If set to `true`, prevents git-annex from making changes to a remote.
+  This prevents `git-annex sync` and `git-annex assist` from pushing
+  changes to a git repository. And it prevents storing or removing
+  files from read-only remote.
+
+* `remote.<name>.annex-verify`, `annex.verify`
+
+  By default, git-annex will verify the checksums of objects downloaded
+  from remotes. If you trust a remote and don't want the overhead
+  of these checksums, you can set this to `false`.
+
+  Note that even when this is set to `false`, git-annex does verification
+  in some edge cases, where it's likely the case than an
+  object was downloaded incorrectly, or when needed for security.
+
+* `remote.<name>.annex-tracking-branch`
+
+  This is for use with special remotes that support exports and imports.
+
+  When set to eg, "master", this tells git-annex that you want the
+  special remote to track that branch.
+
+  When set to eg, "master:subdir", the special remote tracks only
+  the subdirectory of that branch.
+
+  Setting this enables some other commands to work with these special
+  remotes: `git-annex pull` will import changes from the remote and merge them into
+  the annex-tracking-branch. And `git-annex push` will export changes to
+  the remote. Higher-level commands `git-annex sync --content`
+  and `git-annex assist` both import and export.
+
+* `remote.<name>.annex-export-tracking`
+
+  Deprecated name for `remote.<name>.annex-tracking-branch`. Will still be used
+  if it's configured and `remote.<name>.annex-tracking-branch` is not.
+
+* `remote.<name>.annexUrl`
+
+  Can be used to specify a different url than the regular `remote.<name>.url`
+  for git-annex to use when talking with the remote. Similar to the `pushUrl`
+  used by git-push.
+
+* `remote.<name>.annex-uuid`
+
+  git-annex caches UUIDs of remote repositories here.
+
+* `remote.<name>.annex-config-uuid`
+
+  Used for some special remotes, points to a different special remote
+  configuration to use.
+
+* `remote.<name>.annex-retry`, `annex.retry`
+
+  Number of times a transfer that fails can be retried. (default 0)
+
+* `remote.<name>.annex-forward-retry`, `annex.forward-retry`
+
+  If a transfer made some forward progress before failing,
+  this allows it to be retried even when `annex.retry` does not.
+  The value is the maximum number of times to do that. (default 5)
+
+  When both `annex.retry` and this are set, the maximum number of
+  retries is the larger of the two.
+
+* `remote.<name>.annex-retry-delay`, `annex.retry-delay`
+
+  Number of seconds to delay before the first retry of a transfer.
+  When making multiple retries of the same transfer, the delay 
+  doubles after each retry. (default 1)
+
+* `remote.<name>.annex-bwlimit`, `annex.bwlimit`
+
+  This can be used to limit how much bandwidth is used for a transfer
+  from or to a remote.
+ 
+  For example, to limit transfers to 1 mebibyte per second:
+  `git config annex.bwlimit "1MiB"`
+  
+  This will work with many remotes, including git remotes, but not
+  for remotes where the transfer is run by a separate program than
+  git-annex. 
+
+* `remote.<name>.annex-bwlimit-download`, `annex.bwlimit-download`
+
+  Limit bandwith for downloads from a remote.
+  
+  Overrides `remote.<name>.annex-bwlimit` and `annex.bwlimit`
+
+* `remote.<name>.annex-bwlimit-upload`, `annex.bwlimit-upload`
+  
+  Limit bandwith for uploads to a remote. 
+
+  Overrides `remote.<name>.annex-bwlimit` and `annex.bwlimit`
+
+* `remote.<name>.annex-stalldetection`, `annex.stalldetection`
+
+  Configuring this lets stalled or too-slow transfers be detected, and
+  dealt with, so rather than getting stuck, git-annex will cancel the
+  stalled operation. The transfer will be considered to have failed, so
+  settings like annex.retry will control what it does next.
+
+  The default is to automatically detect when transfers that have probably
+  stalled, and suggest configuring this, but not cancel the stalled
+  operations. For this to work, a remote needs to update its progress
+  consistently. Remotes that do not will not have automatic stall detection
+  done. And it may take a while for git-annex to decide a remote is really
+  stalled when using automatic stall detection, since it needs to be
+  conservative about what looks like a stall.
+
+  Set to "false" to avoid all attempts at stall detection.
+
+  To detect and cancel stalled transfers, set this to a value in the form
+  "$amount/$timeperiod" which specifies how much data git-annex should
+  expect to see flowing, minimum, over a given period of time.
+
+  For example, to detect outright stalls where no data has been transferred
+  after 30 seconds: `git config annex.stalldetection "1KB/30s"`
+
+  Or, if you have a remote on a USB drive that is normally capable of
+  several megabytes per second, but has bad sectors where it gets
+  stuck for a long time, you could use:
+  `git config remote.usbdrive.annex-stalldetection "1MB/1m"`
+
+  Some remotes don't report transfer progress, and stalls cannot be
+  detected when using those.
+
+  Some remotes only report transfer progress occasionally, eg
+  after each chunk. To avoid false timeouts in such a situation, if the
+  first progress update takes longer to arrive than the configured time
+  period, the stall detection will be automically adjusted to use a longer
+  time period. For example, if the first progress update comes after 10
+  minutes, but annex.stalldetection is "1MB/1m", it will be treated as eg
+  "30MB/30m".
+
+  Configuring stall detection can make git-annex use more resources. To be
+  able to cancel stalls, git-annex has to run transfers in separate
+  processes (one per concurrent job). So it may need to open more
+  connections to a remote than usual, or the communication with those
+  processes may make it a bit slower.
+
+* `remote.<name>.annex-stalldetection-download`, `annex.stalldetection-download`
+
+  Stall detection for downloads from a remote.
+ 
+  For example, if a remote is often fast, but sometimes is very slow,
+  and there is another remote that is consistently medium speed
+  and that contains the same data, this could be set to treat the fast
+  remote as stalled when it's slow. Then a command like `git-annex get`
+  will fall back to downloading from the medium speed remote.
+
+  Overrides `remote.<name>.annex-stalldetection`, `annex.stalldetection`
+
+* `remote.<name>.annex-stalldetection-upload`, `annex.stalldetection-upload`
+
+  Stall detection for uploads to a remote.
+
+  Overrides `remote.<name>.annex-stalldetection`, `annex.stalldetection`
+
+* `remote.<name>.annex-checkuuid`
+
+  This only affects remotes that have their url pointing to a directory on
+  the same system. git-annex normally checks the uuid of such
+  remotes each time it's run, which lets it transparently deal with
+  different drives being mounted to the location at different times.
+
+  Setting annex-checkuuid to false will prevent it from checking the uuid 
+  at startup (although the uuid is still verified before making any
+  changes to the remote repository). This may be useful to set to prevent
+  unnecessary spin-up or automounting of a drive.
+
+* `remote.<name>.annex-trustlevel`
+
+  Configures a local trust level for the remote. This overrides the value
+  configured by the trust and untrust commands. The value can be any of
+  "trusted", "semitrusted" or "untrusted".
+
+* `remote.<name>.annex-availability`
+
+  This configuration setting is no longer used.
+
+* `remote.<name>.annex-speculate-present`
+
+  Set to "true" to make git-annex speculate that this remote may contain the
+  content of any file, even though its normal location tracking does not
+  indicate that it does. This will cause git-annex to try to get all file
+  contents from the remote. Can be useful in setting up a caching remote.
+
+* `remote.<name>.annex-private`
+
+  When this is set to true, no information about the remote will be
+  recorded in the git-annex branch. This is mostly useful for special
+  remotes, and is set when using [[git-annex-initremote]](1) with the
+  `--private` option.
+
+* `remote.<name>.annex-bare`
+
+  Can be used to tell git-annex if a remote is a bare repository
+  or not. Normally, git-annex determines this automatically.
+
+* `remote.<name>.annex-ssh-options`
+
+  Options to use when using ssh to talk to this remote.
+
+* `remote.<name>.annex-rsync-options`
+
+  Options to use when using rsync
+  to or from this remote. For example, to force IPv6, and limit
+  the bandwidth to 100Kbyte/s, set it to `-6 --bwlimit 100`
+
+  Note that git-annex-shell has a whitelist of allowed rsync options,
+  and others will not be be passed to the remote rsync. So using some
+  options may break the communication between the local and remote rsyncs.
+
+* `remote.<name>.annex-rsync-upload-options`
+
+  Options to use when using rsync to upload a file to a remote.
+
+  These options are passed after other applicable rsync options,
+  so can be used to override them. For example, to limit upload bandwidth
+  to 10Kbyte/s, set `--bwlimit 10`.
+
+* `remote.<name>.annex-rsync-download-options`
+
+  Options to use when using rsync to download a file from a remote.
+
+  These options are passed after other applicable rsync options,
+  so can be used to override them.
+
+* `remote.<name>.annex-rsync-transport`
+
+  The remote shell to use to connect to the rsync remote. Possible
+  values are `ssh` (the default) and `rsh`, together with their
+  arguments, for instance `ssh -p 2222 -c blowfish`; Note that the
+  remote hostname should not appear there, see rsync(1) for details.
+  When the transport used is `ssh`, connections are automatically cached
+  unless `annex.sshcaching` is unset.
+
+* `remote.<name>.annex-bup-split-options`
+
+  Options to pass to bup split when storing content in this remote.
+  For example, to limit the bandwidth to 100Kbyte/s, set it to `--bwlimit 100k`
+  (There is no corresponding option for bup join.)
+
+* `remote.<name>.annex-gnupg-options`
+
+  Options to pass to GnuPG when it's encrypting data. For instance, to
+  use the AES cipher with a 256 bits key and disable compression, set it
+  to `--cipher-algo AES256 --compress-algo none`. (These options take
+  precedence over the default GnuPG configuration, which is otherwise
+  used.)
+
+* `remote.<name>.annex-gnupg-decrypt-options`
+
+  Options to pass to GnuPG when it's decrypting data. (These options take
+  precedence over the default GnuPG configuration, which is otherwise
+  used.)
+
+* `remote.<name>.annex-shared-sop-command`
+
+  Use this command, which is an implementation of the Stateless OpenPGP
+  command line interface, rather than GnuPG for encrypting and decrypting
+  data. This is only used when a special remote is configured with
+  encryption=shared.
+
+  For example, to use Sequoia PGP's sqop command, set this to "sqop".
+
+* `remote.<name>.annex-shared-sop-profile`
+
+  When encrypting with a Stateless OpenPGP command, this can be used
+  to specify the profile to use, such as "rfc4880".
+
+  For a list of available profiles, run eg "sqop list-profiles encrypt"
+
+  sqop list-profiles encrypt
+
+* `annex.ssh-options`, `annex.rsync-options`,
+  `annex.rsync-upload-options`, `annex.rsync-download-options`,
+  `annex.bup-split-options`, `annex.gnupg-options`,
+  `annex.gnupg-decrypt-options`,
+  `annex.shared-sop-command`, `annex.shared-sop-profile`
+
+  Default options to use if a remote does not have more specific options
+  as described above.
+
+* `remote.<name>.annex-rsyncurl`
+
+  Used by rsync special remotes, this configures
+  the location of the rsync repository to use. Normally this is automatically
+  set up by `git annex initremote`, but you can change it if needed.
+
+* `remote.<name>.annex-buprepo`
+
+  Used by bup special remotes, this configures
+  the location of the bup repository to use. Normally this is automatically
+  set up by `git annex initremote`, but you can change it if needed.
+
+* `remote.<name>.annex-borgrepo`
+
+  Used by borg special remotes, this configures
+  the location of the borg repository to use. Normally this is automatically
+  set up by `git annex initremote`, but you can change it if needed.
+
+* `remote.<name>.annex-ddarrepo`
+
+  Used by ddar special remotes, this configures
+  the location of the ddar repository to use. Normally this is automatically
+  set up by `git annex initremote`, but you can change it if needed.
+
+* `remote.<name>.annex-directory`
+
+  Used by directory special remotes, this configures
+  the location of the directory where annexed files are stored for this
+  remote. Normally this is automatically set up by `git annex initremote`,
+  but you can change it if needed.
+
+* `remote.<name>.annex-adb`
+
+  Used to identify remotes on Android devices accessed via adb.
+  Normally this is automatically set up by `git annex initremote`.
+
+* `remote.<name>.annex-androiddirectory`
+
+  Used by adb special remotes, this is the directory on the Android
+  device where files are stored for this remote. Normally this is
+  automatically set up by `git annex initremote`, but you can change
+  it if needed.
+
+* `remote.<name>.annex-androidserial`
+
+  Used by adb special remotes, this is the serial number of the Android
+  device used by the remote. Normally this is automatically set up by
+  `git annex initremote`, but you can change it if needed, eg when
+  upgrading to a new Android device.
+
+* `remote.<name>.annex-s3`
+
+  Used to identify Amazon S3 special remotes.
+  Normally this is automatically set up by `git annex initremote`.
+
+* `remote.<name>.annex-glacier`
+
+  Used to identify Amazon Glacier special remotes.
+  Normally this is automatically set up by `git annex initremote`.
+
+* `remote.<name>.annex-rclone`
+
+  Used to identify rclone special remotes.
+  Normally this is automatically set up by `git annex initremote`.
+
+* `remote.<name>.annex-web`
+
+  Used to identify web special remotes.
+  Normally this is automatically set up by `git annex initremote`.
+
+* `remote.<name>.annex-webdav`
+
+  Used to identify webdav special remotes.
+  Normally this is automatically set up by `git annex initremote`.
+
+* `remote.<name>.annex-tahoe`
+
+  Used to identify tahoe special remotes.
+  Points to the configuration directory for tahoe.
+
+* `remote.<name>.annex-gcrypt`
+
+  Used to identify gcrypt special remotes.
+  Normally this is automatically set up by `git annex initremote`.
+
+  It is set to "true" if this is a gcrypt remote.
+  If the gcrypt remote is accessible over ssh and has git-annex-shell
+  available to manage it, it's set to "shell".
+
+* `remote.<name>.annex-git-lfs`
+
+  Used to identify git-lfs special remotes.
+  Normally this is automatically set up by `git annex initremote`.
+
+  It is set to "true" if this is a git-lfs remote.
+
+* `remote.<name>.annex-httpalso`
+
+  Used to identify httpalso special remotes.
+  Normally this is automatically set up by `git annex initremote`.
+
+* `remote.<name>.annex-externaltype`
+
+  Used by external special remotes to record the type of the remote.
+
+  Eg, if this is set to "foo", git-annex will run a "git-annex-remote-foo"
+  program to communicate with the external special remote.
+
+  If this is set to "readonly", then git-annex will not run any external
+  special remote program, but will try to access things stored in the
+  remote using http. That only works for some external special remotes,
+  so consult the documentation of the one you are using.
+
+* `remote.<name>.annex-hooktype`
+
+  Used by hook special remotes to record the type of the remote.
+
+* `annex.web-options`
+
+  Options to pass to curl when git-annex uses it to download urls
+  (rather than the default built-in url downloader).
+
+  For example, to force IPv4 only, set it to "-4".
+
+  Setting this option makes git-annex use curl, but only
+  when annex.security.allowed-ip-addresses is configured in a
+  specific way. See its documentation.
+
+  Setting this option prevents git-annex from using git-credential
+  for prompting for http passwords. Instead, you can include "--netrc"
+  to make curl use your ~/.netrc file and record the passwords there.
+
+* `annex.youtube-dl-options`
+
+  Options to pass to yt-dlp (or deprecated youtube-dl) when using it to
+  find the url to download for a video.
+
+  Some options may break git-annex's integration with yt-dlp. For
+  example, the --output option could cause it to store files somewhere
+  git-annex won't find them. Avoid setting here or in the yt-dlp config
+  file any options that cause it to download more than one file,
+  or to store the file anywhere other than the current working directory.
+
+* `annex.youtube-dl-command`
+
+  Default is to use "yt-dlp" or if that is not available in the PATH, 
+  to use "youtube-dl".
+
+* `annex.aria-torrent-options`
+
+  Options to pass to aria2c when using it to download a torrent.
+
+* `annex.http-headers`
+
+  HTTP headers to send when downloading from the web. Multiple lines of
+  this option can be set, one per header.
+
+* `annex.http-headers-command`
+
+  If set, the command is run and each line of its output is used as a HTTP
+  header. This overrides annex.http-headers.
+
+* `annex.security.allowed-url-schemes`
+
+  List of URL schemes that git-annex is allowed to download content from.
+  The default is "http https ftp".
+
+  Think very carefully before changing this; there are security
+  implications. For example, if it's changed to allow "file" URLs, then
+  anyone who can get a commit into your git-annex repository could
+  `git-annex addurl` a pointer to a private file located outside that
+  repository, possibly causing it to be copied into your repository
+  and transferred on to other remotes, exposing its content.
+
+  Any url schemes supported by curl can be listed here, but you will
+  also need to configure annex.security.allowed-ip-addresses to allow
+  using curl.
+
+  Some special remotes support their own domain-specific URL
+  schemes; those are not affected by this configuration setting.
+
+* `annex.security.allowed-ip-addresses`
+
+  By default, git-annex only makes connections to public IP addresses;
+  it will refuse to use HTTP and other servers on localhost or on a
+  private network.
+
+  This setting can override that behavior, allowing access to particular
+  IP addresses that would normally be blocked. For example "127.0.0.1 ::1"
+  allows access to localhost (both IPV4 and IPV6).
+  To allow access to all IP addresses, use "all"
+  
+  Think very carefully before changing this; there are security
+  implications. Anyone who can get a commit into your git-annex repository
+  could `git annex addurl` an url on a private server, possibly
+  causing it to be downloaded into your repository and transferred to
+  other remotes, exposing its content.
+
+  Note that, since the interfaces of curl and yt-dlp do not allow
+  these IP address restrictions to be enforced, curl and yt-dlp will
+  never be used unless annex.security.allowed-ip-addresses=all.
+  
+  To allow accessing local or private IP addresses on only specific ports,
+  use the syntax "[addr]:port". For example,
+  "[127.0.0.1]:80 [127.0.0.1]:443 [::1]:80 [::1]:443" allows
+  localhost on the http ports only.
+
+* `annex.security.allowed-http-addresses`
+
+  Old name for annex.security.allowed-ip-addresses.
+  If set, this is treated the same as having
+  annex.security.allowed-ip-addresses set.
+
+* `annex.security.allow-unverified-downloads`
+
+  For security reasons, git-annex refuses to download content from
+  most special remotes when it cannot check a hash to verify 
+  that the correct content was downloaded. This particularly impacts
+  downloading the content of URL or WORM keys, which lack hashes.
+
+  The best way to avoid problems due to this is to migrate files
+  away from such keys, before their content reaches a special remote.
+  See [[git-annex-migrate]](1).
+
+  When the content is only available from a special remote, you can
+  use this configuration to force git-annex to download it.
+  But you do so at your own risk, and it's very important you read and
+  understand the information below first!
+
+  Downloading unverified content from encrypted special remotes is
+  prevented, because the special remote could send some other encrypted
+  content than what you expect, causing git-annex to decrypt data that you
+  never checked into git-annex, and risking exposing the decrypted
+  data to any non-encrypted remotes you send content to.
+
+  Downloading unverified content from (non-encrypted)
+  external special remotes is prevented, because they could follow
+  http redirects to web servers on localhost or on a private network,
+  or in some cases to a file:/// url.
+
+  If you decide to bypass this security check, the best thing to do is
+  to only set it temporarily while running the command that gets the file.
+  The value to set the config to is "ACKTHPPT".
+  For example:
+
+	git -c annex.security.allow-unverified-downloads=ACKTHPPT annex get myfile
+
+  It would be a good idea to check that it downloaded the file you expected,
+  too.
+
+* `remote.<name>.annex-security-allow-unverified-downloads`
+
+  Per-remote configuration of annex.security.allow-unverified-downloads.
+
+# CONFIGURATION OF ASSISTANT
+
+* `annex.delayadd`
+
+  Makes the watch and assistant commands delay for the specified number of
+  seconds before adding a newly created file to the annex. Normally this
+  is not needed, because they already wait for all writers of the file
+  to close it.
+
+  Note that this only delays adding files created while the daemon is
+  running. Changes made when it is not running will be added immediately
+  the next time it is started up.
+
+* `annex.expireunused`
+
+  Controls what the assistant does about unused file contents
+  that are stored in the repository.
+
+  The default is `false`, which causes
+  all old and unused file contents to be retained, unless the assistant
+  is able to move them to some other repository (such as a backup repository).
+
+  Can be set to a time specification, like "7d" or "1m", and then
+  file contents that have been known to be unused for a week or a
+  month will be deleted.
+
+* `annex.fscknudge`
+
+  When set to false, prevents the webapp from reminding you when using
+  repositories that lack consistency checks.
+
+* `annex.autoupgrade`
+
+  When set to ask (the default), the webapp will check for new versions
+  and prompt if they should be upgraded to. When set to true, automatically
+  upgrades without prompting (on some supported platforms). When set to
+  false, disables any upgrade checking.
+
+  Note that upgrade checking is only done when git-annex is installed
+  from one of the prebuilt images from its website. This does not
+  bypass e.g., a Linux distribution's own upgrade handling code.
+
+  This setting also controls whether to restart the git-annex assistant
+  when the git-annex binary is detected to have changed. That is useful
+  no matter how you installed git-annex.
+
+* `annex.autocommit`
+
+  Set to false to prevent the `git-annex assistant`, `git-annex assist`, 
+  and `git-annex sync` from automatically committing changes to files in
+  the repository.
+
+  To configure the behavior in all clones of the repository,
+  this can be set in [[git-annex-config]](1).
+
+* `annex.startupscan`
+
+  Set to false to prevent the git-annex assistant from scanning the
+  repository for new and changed files on startup. This will prevent it
+  from noticing changes that were made while it was not running, but can be
+  a useful performance tweak for a large repository.
+
+* `annex.listen`
+
+  Configures which IP address the webapp listens on. 
+  The default is localhost. Can be either an IP address, 
+  or a hostname that resolves to the desired address.
+
+* `annex.port`
+
+  Configures which port address the webapp listens on. 
+  The default is to pick an unused port.
+
+# CONFIGURATION VIA .gitattributes
+
+The key-value backend used when adding a new file to the annex can be
+configured on a per-file-type basis via `.gitattributes` files. In the file,
+the `annex.backend` attribute can be set to the name of the backend to
+use. (See [[git-annex-backends]](1) for information about
+available backends.)
+For example, this here's how to use the WORM backend by default,
+but the SHA256E backend for ogg files:
+
+	* annex.backend=WORM
+	*.ogg annex.backend=SHA256E
+
+There is a annex.largefiles attribute, which is used to configure which
+files are large enough to be added to the annex. Since attributes cannot
+contain spaces, it is difficult to use for more complex annex.largefiles
+settings. Setting annex.largefiles in [[git-annex-config]](1) is an easier
+way to configure it across all clones of the repository.
+See [[git-annex-matching-expression]](1) for details on the syntax.
+
+The numcopies and mincopies settings can also be configured on a 
+per-file-type basis via the `annex.numcopies` and `annex.mincopies` 
+attributes in `.gitattributes` files. This overrides other settings.
+For example, this makes two copies be needed for wav files and 3 copies
+for flac files:
+
+	*.wav annex.numcopies=2
+	*.flac annex.numcopies=3
+
+These settings are honored by git-annex whenever it's operating on a
+matching file. However, when using --all, --unused, or --key to specify
+keys to operate on, git-annex is operating on keys and not files, so will
+not honor the settings from .gitattributes. For this reason, the `git annex
+numcopies` and `git annex mincopies` commands are useful to configure a
+global default.
+
+Also note that when using views, only the toplevel .gitattributes file is
+preserved in the view, so other settings in other files won't have any
+effect.
+
+# EXIT STATUS
+
+git-annex itself will exit 0 on success and 1 on failure, unless 
+the `--size-limit` or `--time-limit` option is hit, in 
+which case it exits 101. 
+
+A few git-annex subcommands have other exit statuses used to indicate
+specific problems, which are documented on their individual man pages.
+
+# ENVIRONMENT
+
+These environment variables are used by git-annex when set:
+
+* `GIT_WORK_TREE`, `GIT_DIR`
+
+  Handled the same as they are by git, see git(1)
+
+* `GIT_SSH`, `GIT_SSH_COMMAND`
+
+  Handled similarly to the same as described in git(1).
+  The one difference is that git-annex will sometimes pass an additional
+  "-n" parameter to these, as the first parameter, to prevent ssh from
+  reading from stdin. Since that can break existing uses of these
+  environment variables that don't expect the extra parameter, you will
+  need to set `GIT_ANNEX_USE_GIT_SSH=1` to make git-annex support
+  these.
+
+  Note that setting either of these environment variables prevents
+  git-annex from automatically enabling ssh connection caching
+  (see `annex.sshcaching`), so it will slow down some operations with
+  remotes over ssh. It's up to you to enable ssh connection caching
+  if you need it; see ssh's documentation.
+
+  Also, `annex.ssh-options` and `remote.<name>.annex-ssh-options`
+  won't have any effect when these envionment variables are set.
+
+  Usually it's better to configure any desired options through your
+  ~/.ssh/config file, or by setting `annex.ssh-options`.
+
+* `GIT_ANNEX_VECTOR_CLOCK`
+
+  Normally git-annex timestamps lines in the log files committed to the
+  git-annex branch. Setting this environment variable to a number
+  will make git-annex use that (or a larger number) 
+  rather than the current number of seconds since the UNIX epoch.
+  Note that decimal seconds are supported.
+  
+  This is only provided for advanced users who either have a better way to
+  tell which commit is current than the local clock, or who need to avoid
+  embedding timestamps for policy reasons.
+
+* Some special remotes use additional environment variables
+  for authentication etc. For example, `AWS_ACCESS_KEY_ID`
+  and `GIT_ANNEX_P2P_AUTHTOKEN`. See special remote documentation.
+
+# FILES
+
+These files are used by git-annex:
+
+`.git/annex/objects/` in your git repository contains the annexed file
+contents that are currently available. Annexed files in your git
+repository symlink to that content.
+
+`.git/annex/` in your git repository contains other run-time information
+used by git-annex.
+
+`~/.config/git-annex/autostart` is a list of git repositories
+to start the git-annex assistant in.
+
+`.git/hooks/pre-commit-annex` in your git repository will be run whenever
+a commit is made to the HEAD branch, either by git commit, git-annex
+sync, or the git-annex assistant.
+
+`.git/hooks/post-update-annex` in your git repository will be run
+whenever the git-annex branch is updated. You can make this hook run
+`git update-server-info` when publishing a git-annex repository by http.
+
+# SEE ALSO
+
+More git-annex documentation is available on its web site,
+<https://git-annex.branchable.com/>
+
+If git-annex is installed from a package, a copy of its documentation
+should be included, in, for example, `/usr/share/doc/git-annex/`.
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+<https://git-annex.branchable.com/>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-remote-tor-annex.mdwn b/doc/git-remote-tor-annex.mdwn
new file mode 100644
index 0000000000..4e41de877b
--- /dev/null
+++ b/doc/git-remote-tor-annex.mdwn
@@ -0,0 +1,36 @@
+# NAME
+
+git-remote-tor-annex - remote helper program to talk to git-annex over tor
+
+# SYNOPSIS
+
+git fetch tor-annex::address.onion:port
+
+git remote add tor tor-annex::address.onion:port
+
+# DESCRIPTION
+
+This is a git remote helper program that allows git to pull and push
+over tor(1), communicating with a tor hidden service.
+
+The tor hidden service probably requires an authtoken to use it.
+The authtoken can be provided in the environment variable
+`GIT_ANNEX_P2P_AUTHTOKEN`. Or, if there is a file in 
+`.git/annex/creds/` matching the onion address of the hidden
+service, its first line is used as the authtoken.
+
+# SEE ALSO
+
+git-remote-helpers(1)
+
+[[git-annex]](1)
+
+[[git-annex-enable-tor]](1)
+
+[[git-annex-remotedaemon]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-union-merge.mdwn b/doc/git-union-merge.mdwn
new file mode 100644
index 0000000000..ca06d2f933
--- /dev/null
+++ b/doc/git-union-merge.mdwn
@@ -0,0 +1,38 @@
+# NAME
+
+git-union-merge - Join branches together using a union merge
+
+# SYNOPSIS
+
+git union-merge ref ref newref
+
+# DESCRIPTION
+
+Does a union merge between two refs, storing the result in the
+specified newref.
+
+The union merge will always succeed, but assumes that files can be merged
+simply by concatenating together lines from all the oldrefs, in any order.
+So, this is useful only for branches containing log-type data.
+
+Note that this does not touch the checked out working copy. It operates
+entirely on git refs and branches.
+
+# EXAMPLE
+
+	git union-merge git-annex origin/git-annex refs/heads/git-annex 
+
+Merges the current git-annex branch, and a version from origin,
+storing the result in the git-annex branch.
+
+# BUGS
+
+File modes are not currently merged.
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+<http://git-annex.branchable.com/>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care
diff --git a/doc/how_it_works.mdwn b/doc/how_it_works.mdwn
new file mode 100644
index 0000000000..56e6591546
--- /dev/null
+++ b/doc/how_it_works.mdwn
@@ -0,0 +1,44 @@
+This page gives a high-level view of how git-annex works. For a detailed
+low-level view, see [[the_man_page|git-annex]] and [[internals]].
+
+You do not need to read this page to get started with using git-annex. The
+[[walkthrough]] provides step-by-step examples, and [[workflow]] discusses
+different ways you can use git-annex.
+
+----
+
+Still reading? Ok. Git's man page calls it "a stupid content
+tracker". With git-annex, git is instead "a stupid filename and metadata
+tracker". The contents of annexed files are not stored in git, only the
+names of the files and some other metadata remain there.
+
+The contents of the files are kept by git-annex in a distributed key/value
+store consisting of every clone of a given git repository. That's a fancy
+way to say that git-annex stores the actual file content somewhere under
+`.git/annex/`. (See [[internals]] for details.)
+
+That was the values; what about the keys? Well, a key is calculated for a
+given file when it's first added into git-annex. Normally this uses a hash
+of its contents, but various [[backends]] can produce different sorts of
+keys. The file that gets checked into git is just a symlink to the key
+under `.git/annex/`. If the content of a file is modified, that produces
+a different key (and the symlink is changed).
+
+A file's content can be [[transferred|transferring_data]] from one
+repository to another by git-annex. Which repositories contain a given
+value is tracked by git-annex (see [[location_tracking]]). It stores this
+tracking information in a separate branch, named "git-annex". All you ever
+do with the "git-annex" branch is push/pull it around between repositories,
+to [[sync]] up git-annex's view of the world.
+
+That's really all there is to it. Oh, there are [[special_remotes]] that
+let values be stored other places than git repositories (anything from
+Amazon S3 to a USB key), and there's a pile of commands listed in
+[[the_man_page|git-annex]] to handle moving the values around and managing
+them. But if you grok the description above, you can see through all that.
+It's really just symlinks, keys, values, and a git-annex branch to store
+additional metadata.
+
+---
+
+Next: [[install]] or [[walkthrough]]
diff --git a/doc/how_it_works/comment_1_b3bdd6a06d5764db521ae54878131f5f._comment b/doc/how_it_works/comment_1_b3bdd6a06d5764db521ae54878131f5f._comment
new file mode 100644
index 0000000000..60aeab7324
--- /dev/null
+++ b/doc/how_it_works/comment_1_b3bdd6a06d5764db521ae54878131f5f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="minor suggestion"
+ date="2013-08-10T14:31:31Z"
+ content="""
+The contents of large files are not stored in git, only the names of the files and some other metadata remain there.
+
+Would this read better to the newbie as:
+
+The contents of 'annexed' files are not stored in git, only the names of the files and some other metadata remain there.
+
+First time for me, the note about large files made me think that maybe annex operated on files above a certain size.
+"""]]
diff --git a/doc/how_it_works/comment_2_2a8ce5859040d815e6234fc18f5f1961._comment b/doc/how_it_works/comment_2_2a8ce5859040d815e6234fc18f5f1961._comment
new file mode 100644
index 0000000000..cc16f465d0
--- /dev/null
+++ b/doc/how_it_works/comment_2_2a8ce5859040d815e6234fc18f5f1961._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm4cjowB3PaZP00vEr255d1GdUBikE9Qdg"
+ nickname="Matthew"
+ subject="clarification about what is moved / stored and where"
+ date="2014-02-10T12:53:44Z"
+ content="""
+Just to support Nigel's comment; it's good to be precise and clear about what happens to the files from the start.
+I've sent a similar suggestion to the mailing list.
+
+"""]]
diff --git a/doc/how_it_works/comment_3_806c0fe325942a425e43afb9b78327ec._comment b/doc/how_it_works/comment_3_806c0fe325942a425e43afb9b78327ec._comment
new file mode 100644
index 0000000000..ef4fbbebf1
--- /dev/null
+++ b/doc/how_it_works/comment_3_806c0fe325942a425e43afb9b78327ec._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="G.nius.ck@d885edcfde63422ee84e5ee501b7aa545e91298d"
+ nickname="G.nius.ck"
+ subject="What do you mean by &quot;git-annex&quot; branch?"
+ date="2016-01-09T16:04:29Z"
+ content="""
+Branches usually mean different versions of your repo, not entirely different content! Why are branches being used for this?
+"""]]
diff --git a/doc/how_it_works/comment_4_0ef6b8c9dbd5a7f9b9f274dc6f9988f0._comment b/doc/how_it_works/comment_4_0ef6b8c9dbd5a7f9b9f274dc6f9988f0._comment
new file mode 100644
index 0000000000..fc57799ee5
--- /dev/null
+++ b/doc/how_it_works/comment_4_0ef6b8c9dbd5a7f9b9f274dc6f9988f0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-01-11T16:21:00Z"
+ content="""
+A git branch can be used to name any tree ref. In this case we're using
+"git-annex" as the name of a branch that is not connected to the rest of
+the content in the repository.
+"""]]
diff --git a/doc/how_it_works/comment_5_11e5141c9ffb37db4fa0c1bfb32c51a9._comment b/doc/how_it_works/comment_5_11e5141c9ffb37db4fa0c1bfb32c51a9._comment
new file mode 100644
index 0000000000..5fbc0d7346
--- /dev/null
+++ b/doc/how_it_works/comment_5_11e5141c9ffb37db4fa0c1bfb32c51a9._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="git-annex.branchable.com@78dd096e15e9d37643bf695293cae77fec735698"
+ nickname="git-annex.branchable.com"
+ avatar="http://cdn.libravatar.org/avatar/f9a3a021d4457e45fb899b38ba0aed41"
+ subject="So where are the file stored?"
+ date="2021-08-18T20:19:25Z"
+ content="""
+This is like a 1000ft overview, but doesn't actually say where the files are actually stored or how they're synchronized.
+
+Does one need to setup a samba, sftp, or AWS bucket to contain the large files? Does a clone of the repo full down all of the large files, or just the files in the working directory that's checked out? Are files transferred via direct connection to other repos (ex the same SSH tunnel that git uses, http, etc) or is there a UDP p2p layer like syncthing or bittorrent that might struggle with certain NAT situations?
+
+The sentence \"A file's content can be transferred from one repository to another by git-annex. Which repositories contain a given value is tracked by git-annex (see location tracking).\" makes it sound like the old versions of the large files only exist on computers that checked out those copies. Does this mean old versions of a file might be lost forever if a single clone is deleted and temporarily unavailable if clones that contain those revisions of the file are offline?
+
+Is there a way to ensure that a clone has all copies of all of the files (for example, when using git with a central trusted server)? 
+"""]]
diff --git a/doc/how_it_works/comment_6_2ad3441a02f1bcc2cca0c10ecf7b216f._comment b/doc/how_it_works/comment_6_2ad3441a02f1bcc2cca0c10ecf7b216f._comment
new file mode 100644
index 0000000000..6652e190ec
--- /dev/null
+++ b/doc/how_it_works/comment_6_2ad3441a02f1bcc2cca0c10ecf7b216f._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 6"
+ date="2021-08-18T21:07:11Z"
+ content="""
+    This is like a 1000ft overview, but doesn't actually say where the files are actually stored or how they're synchronized.
+
+It does:
+\"[...] That's a fancy way to say that git-annex stores the actual file content somewhere under .git/annex/. (See [[internals]] for details.)\". <br>
+When using SHA256E hashing (the default), a file will end up for example under `.git/annex/f87/4d5/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`.
+
+    Does one need to setup a samba, sftp, or AWS bucket to contain the large files?
+
+No.
+
+    Does a clone of the repo pull down all of the large files, or just the files in the working directory that's checked out?
+
+No and no. You decide yourself (via [[git-annex-get]]/[[git-annex-drop]]/[[git-annex-copy]]/[[git-annex-move]]) or automated (via `git annex sync --content`/[[git-annex-wanted]]/[[git-annex-preferred-content]]) what large files are stored where. If a file is not present you will just see a broken symlink.
+
+    Are files transferred via direct connection to other repos (ex the same SSH tunnel that git uses, http, etc) or is there a UDP p2p layer like syncthing or bittorrent that might struggle with certain NAT situations?
+
+Yes and no. git-annex is very flexible, it can also communicate via tor.
+
+    The sentence \"A file's content can be transferred from one repository to another by git-annex. Which repositories contain a given value is tracked by git-annex (see location tracking).\" makes it sound like the old versions of the large files only exist on computers that checked out those copies. Does this mean old versions of a file might be lost forever if a single clone is deleted and temporarily unavailable if clones that contain those revisions of the file are offline?
+
+Yes and yes. If you don't copy the file elsewhere (with the commands mentioned above) before deleting the repo, that version is lost.
+
+    Is there a way to ensure that a clone has all copies of all of the files (for example, when using git with a central trusted server)?
+
+`git annex get --all`/`git annex wanted server anything` 
+
+I strongly suggest you to create a throwaway repository and try things out.
+
+"""]]
diff --git a/doc/index.mdwn b/doc/index.mdwn
new file mode 100644
index 0000000000..77b61da9dd
--- /dev/null
+++ b/doc/index.mdwn
@@ -0,0 +1,40 @@
+[[!inline raw=yes pages="summary"]]
+
+[[!sidebar content="""
+[[!inline feeds=no template=bare pages=sidebar]]
+"""]]
+
+<table>
+<tr>
+<td width="33%" valign="top">[[!inline feeds=no template=bare pages=links/key_concepts]]</td>
+<td width="33%" valign="top">[[!inline feeds=no template=bare pages=links/the_details]]</td>
+<td width="33%" valign="top">[[!inline feeds=no template=bare pages=links/other_stuff]]</td>
+</tr>
+</table>
+
+<table>
+<tr>
+<td width="50%" valign="top">[[!inline feeds=no template=bare pages=use_case/bob]]</td>
+<td width="50%" valign="top">[[!inline feeds=no template=bare pages=use_case/alice]]</td>
+</tr>
+</table>
+
+If that describes you, or if you're some from column A and some from column
+B, then git-annex may be the tool you've been looking for to expand from
+keeping all your small important files in git, to managing your large
+files with git.
+
+<table>
+<tr>
+<td width="50%" valign="top">[[!inline feeds=no template=bare pages=footer/column_a]]</td>
+<td width="50%" valign="top">[[!inline feeds=no template=bare pages=footer/column_b]]</td>
+</tr>
+</table>
+
+----
+
+git-annex is [[Free Software|license]], written in [Haskell](http://www.haskell.org/).
+You can [[contribute]]!
+
+git-annex's wiki is powered by [Ikiwiki](http://ikiwiki.info/) and
+hosted by [Branchable](http://branchable.com/).
diff --git a/doc/install.mdwn b/doc/install.mdwn
new file mode 100644
index 0000000000..3b6a5058f9
--- /dev/null
+++ b/doc/install.mdwn
@@ -0,0 +1,41 @@
+## Pick your OS
+
+[[!table format=dsv header=yes data="""
+detailed instructions             | quick install
+[[Linux|linux_standalone]]        | 
+&nbsp;&nbsp;[[Debian]]            | `apt-get install git-annex`
+&nbsp;&nbsp;[[Ubuntu]]            | `apt-get install git-annex`
+&nbsp;&nbsp;[[Fedora]]            | `yum install git-annex`
+&nbsp;&nbsp;[[ArchLinux]]         | `pacman -S git-annex`
+&nbsp;&nbsp;[[AlpineLinux]]       | `apk add git-annex`
+&nbsp;&nbsp;[[NixOS]]             | `nix-env -i git-annex`
+&nbsp;&nbsp;[[Gentoo]]            | `emerge git-annex`
+&nbsp;&nbsp;[[Guix]]              | `guix package -i git-annex`
+&nbsp;&nbsp;[[Void]]              | `xbps-install git-annex`
+&nbsp;&nbsp;[[ScientificLinux]]   |
+&nbsp;&nbsp;[[RHEL]]              |
+&nbsp;&nbsp;[[openSUSE]]          | `zypper in git-annex`
+&nbsp;&nbsp;[[Docker]]            | 
+&nbsp;&nbsp;[[conda]]             | `conda install -c conda-forge git-annex`
+[[OSX]]                           |
+&nbsp;&nbsp;[[OSX/Homebrew]]      | `brew install git-annex`
+[[FreeBSD]]                       | `pkg install hs-git-annex`
+[[OpenBSD]]                       | `pkg_add git-annex`
+[[Android]]                       | **beta**
+[[Windows]]                       | **beta**
+"""]]
+
+## Historical builds
+
+Many of historical builds available from the [https://downloads.kitenet.net/.git/](https://downloads.kitenet.net/.git/) git-annex repository.  Visit [downloads.kitenet.net](https://downloads.kitenet.net/) for more information.
+
+## Building it yourself
+
+git-annex is [[Free Software|license]], written in [Haskell](http://www.haskell.org/).
+Experienced users should not find it too hard to build and install
+it [[from source|fromsource]].
+
+## See also
+
+ * [[autobuild overview|builds]]
+ * [[upgrades]]
diff --git a/doc/install/AlpineLinux.mdwn b/doc/install/AlpineLinux.mdwn
new file mode 100644
index 0000000000..26d0284c31
--- /dev/null
+++ b/doc/install/AlpineLinux.mdwn
@@ -0,0 +1,3 @@
+There is now a [git-annex package for AlpineLinux](https://pkgs.alpinelinux.org/package/edge/community/x86_64/git-annex), so to install it:
+
+	apk add git-annex
diff --git a/doc/install/Android.mdwn b/doc/install/Android.mdwn
new file mode 100644
index 0000000000..af9f70fc9a
--- /dev/null
+++ b/doc/install/Android.mdwn
@@ -0,0 +1,7 @@
+Now git-annex can be used on Android!
+
+[[Installation instructions here|/Android]].
+
+The way it works now is the [[Linux_standalone]] builds of git-annex are run
+inside the Termux app. The old git-annex Android app,
+is no longer being updated, details about it are at [[oldapp]].
diff --git a/doc/install/Android/git-annex-install b/doc/install/Android/git-annex-install
new file mode 100755
index 0000000000..12fdcbd27c
--- /dev/null
+++ b/doc/install/Android/git-annex-install
@@ -0,0 +1,58 @@
+#!/bin/sh
+# 
+# Installs git-annex in termux on android.
+# 
+# This is only a convenience script to avoid the user needing to type much
+# in termux. The standalone tarball automatically adapts itself to the termux
+# environment, so this script should stay as minimal as possible.
+#
+# This script needs to be sourced into the current termux shell, rather
+# than run with a new shell, so it can set the PATH to include git-annex.
+
+set -e
+
+case $(uname -m) in
+	aarch64)
+		arch=arm64-ancient
+		;;
+	arm)
+		arch=armel
+		;;
+	armv7l)
+		arch=armel
+		;;
+	x86_64)
+		arch=amd64
+		;;
+	x86_32)
+		arch=i386-ancient
+		;;
+	*) 
+		echo "unknown architecture $(uname -m), cannot install" >&2
+		exit 1
+		;;
+esac
+
+url=https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-"$arch".tar.gz
+# uncomment to use latest autobuild
+#url=https://downloads.kitenet.net/git-annex/autobuild/"$arch"/git-annex-standalone-"$arch".tar.gz
+
+echo "Installing dependencies with termux pkg manager..."
+pkg install git wget tar coreutils proot
+
+echo "Downloading git-annex..."
+cd
+wget -O- "$url" | tar zx
+
+# This lets runshell finish the installation.
+git-annex.linux/git-annex version
+echo "git-annex is successfully installed."
+
+echo "Now running termux-setup-storage, to let git-annex access system storage."
+termux-setup-storage
+
+# Add to PATH of shell that sourced this, so the user can immediately
+# start using git-annex.
+PATH="$PATH:`pwd`/git-annex.linux"
+
+echo "Installation complete."
diff --git a/doc/install/Android/oldapp.mdwn b/doc/install/Android/oldapp.mdwn
new file mode 100644
index 0000000000..7013a600a2
--- /dev/null
+++ b/doc/install/Android/oldapp.mdwn
@@ -0,0 +1,11 @@
+## Old Android app
+
+This app is being deprecated in favor of Termux. It doesn't work with newer
+versions of Android.
+
+**These builds are not being updated.** They are provided just in case
+someone needs them, but use at your own risk.
+
+* [Android 5.0 git-annex.apk](http://downloads.kitenet.net/git-annex/android/current/5.0/git-annex.apk)
+* [Android 4.4 and 4.3 git-annex.apk](http://downloads.kitenet.net/git-annex/android/current/4.3/git-annex.apk)
+* [Android 4.0 to 4.2 git-annex.apk](http://downloads.kitenet.net/git-annex/android/current/4.0/git-annex.apk)
diff --git a/doc/install/Android/oldapp/comment_10_225f2c6fe255be93702cfbd4dc172f3b._comment b/doc/install/Android/oldapp/comment_10_225f2c6fe255be93702cfbd4dc172f3b._comment
new file mode 100644
index 0000000000..f6a71981e6
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_10_225f2c6fe255be93702cfbd4dc172f3b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="+1 F-Droid"
+ date="2013-09-24T18:36:48Z"
+ content="""
+Availability in F-Droid would be really neat. I imagine the unusual build requirements would require some work though.
+"""]]
diff --git a/doc/install/Android/oldapp/comment_10_4b565e73f02f0e84bdf7e686b0d7bf5f._comment b/doc/install/Android/oldapp/comment_10_4b565e73f02f0e84bdf7e686b0d7bf5f._comment
new file mode 100644
index 0000000000..6ab3dbd4a1
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_10_4b565e73f02f0e84bdf7e686b0d7bf5f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://lj.rossia.org/users/imz/"
+ ip="79.165.57.121"
+ subject="re F-Droid"
+ date="2014-05-03T14:58:02Z"
+ content="""
+See also <http://git-annex.branchable.com/todo/custom_f-droid_repo/>.
+"""]]
diff --git a/doc/install/Android/oldapp/comment_11_3e7980603749665fafbdeb1b7ab068a5._comment b/doc/install/Android/oldapp/comment_11_3e7980603749665fafbdeb1b7ab068a5._comment
new file mode 100644
index 0000000000..dc620bfcb9
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_11_3e7980603749665fafbdeb1b7ab068a5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnG-DZQa3d3Jn7K2q36TlbmZ8v2YuV-23M"
+ nickname="Fer"
+ subject="Android x86?"
+ date="2015-03-23T06:55:35Z"
+ content="""
+Hello, looks like the binaries compiled for ARM, anyone succeeded building for Android x86?
+"""]]
diff --git a/doc/install/Android/oldapp/comment_11_4e970633d9073fcf4bc33f3fff2525b2._comment b/doc/install/Android/oldapp/comment_11_4e970633d9073fcf4bc33f3fff2525b2._comment
new file mode 100644
index 0000000000..f57fb8d79e
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_11_4e970633d9073fcf4bc33f3fff2525b2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="What am I missing?"
+ date="2013-10-15T21:54:07Z"
+ content="""
+I've setup repositories on both my linux PC & android mini pc and added jabber account on both. They are both at my home network. They detected each other fine. But when it comes to syncing files, there's a message which says \"Unable to download files from your other devices\" with a button for \"add a cloud repository\". I don't need to add a cloud repository since both computers are at the same network? Or am I missing something in the architecture of git-annex that even to sync two local computers in the same LAN, annex would still need an external repo? (and if so, why would that be?)
+I'm not really willing to add an external repository as I intend to add large files and I don't want that they are first uploaded using a slow connection & then re-downloaded.
+What am I missing?
+"""]]
diff --git a/doc/install/Android/oldapp/comment_12_57867e2b13b83cc9815df56b027d388a._comment b/doc/install/Android/oldapp/comment_12_57867e2b13b83cc9815df56b027d388a._comment
new file mode 100644
index 0000000000..fc5b3ad1dc
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_12_57867e2b13b83cc9815df56b027d388a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="Android 6/7?"
+ date="2016-11-09T21:44:26Z"
+ content="""
+Is there yet a version for Android 6 resp. 7? Or can I just use the Android 5 version?
+"""]]
diff --git a/doc/install/Android/oldapp/comment_12_87da4f379a0276b662583e7e22061218._comment b/doc/install/Android/oldapp/comment_12_87da4f379a0276b662583e7e22061218._comment
new file mode 100644
index 0000000000..772fa1d6aa
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_12_87da4f379a0276b662583e7e22061218._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 12"
+ date="2013-10-16T16:05:45Z"
+ content="""
+To make computers on your network directly communicate, they must be connected together using the user interface. This is normally using the local pairing interface. But local pairing does not yet work on Android. The best you can do to instead on your Android device, add the Linux PC as a ssh server. This will let the Android device send/receive files directly with it over the local network.
+"""]]
diff --git a/doc/install/Android/oldapp/comment_13_169025cf0b415d5a45dd89856e53cca9._comment b/doc/install/Android/oldapp/comment_13_169025cf0b415d5a45dd89856e53cca9._comment
new file mode 100644
index 0000000000..0564f974c5
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_13_169025cf0b415d5a45dd89856e53cca9._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="hobbes@b2cacef69071743c3a831e60511062f7e014e52f"
+ nickname="hobbes"
+ avatar="http://cdn.libravatar.org/avatar/44b70169c4d862b3619812c360aa8f1e"
+ subject="Modern Android?"
+ date="2018-04-16T19:28:09Z"
+ content="""
+Hey there!
+
+It's been a while since the android app has worked. Are there any plans to get it working on modern Android versions? I assume it's pretty low demand, but it would make git-annex just so much more useful for me.
+
+To clarify, I am experiencing this issue, as will everybody using Android >=6:
+
+https://git-annex.branchable.com/bugs/android__58___cannot_link_executable/
+https://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-runtime
+
+I'm not certain, but I think it might just be a matter of compiling git-annex with this flag and releasing a new APK?
+
+https://ghc.haskell.org/trac/ghc/ticket/13702
+
+I'd be delighted to test if given an APK! Thanks again for the lovely git magic :).
+
+
+
+
+"""]]
diff --git a/doc/install/Android/oldapp/comment_14_19909ddf4e7e6da0e814e165c5c9b44a._comment b/doc/install/Android/oldapp/comment_14_19909ddf4e7e6da0e814e165c5c9b44a._comment
new file mode 100644
index 0000000000..b499cdddf6
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_14_19909ddf4e7e6da0e814e165c5c9b44a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 14"
+ date="2018-04-17T08:38:32Z"
+ content="""
+There is now an [adb special remote](https://git-annex.branchable.com/todo/adb_special_remote).
+"""]]
diff --git a/doc/install/Android/oldapp/comment_1_f9ced494a530e6ae3e76cfbaddb89f5d._comment b/doc/install/Android/oldapp/comment_1_f9ced494a530e6ae3e76cfbaddb89f5d._comment
new file mode 100644
index 0000000000..13f9c659ff
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_1_f9ced494a530e6ae3e76cfbaddb89f5d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://josh.easyid.net/"
+ ip="208.100.171.144"
+ subject="Minimum version of Android?"
+ date="2013-06-18T22:05:02Z"
+ content="""
+Does this require 4.x?
+"""]]
diff --git a/doc/install/Android/oldapp/comment_2_74cccae04ea23a8600069c7e658143aa._comment b/doc/install/Android/oldapp/comment_2_74cccae04ea23a8600069c7e658143aa._comment
new file mode 100644
index 0000000000..bf5978674c
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_2_74cccae04ea23a8600069c7e658143aa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 2"
+ date="2013-06-25T17:58:57Z"
+ content="""
+I have not heard of anyone using older than 4.x with success. In particular, several people reported 2.3 doesn't work.
+"""]]
diff --git a/doc/install/Android/oldapp/comment_3_82c7cb31d19d4e18ca5548da5ca19a79._comment b/doc/install/Android/oldapp/comment_3_82c7cb31d19d4e18ca5548da5ca19a79._comment
new file mode 100644
index 0000000000..c049bfcab0
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_3_82c7cb31d19d4e18ca5548da5ca19a79._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmhfodZquCI_EEl-f3h7HkROTszlsQL6yA"
+ nickname="Joe"
+ subject="comment 3"
+ date="2013-07-04T15:06:36Z"
+ content="""
+Is it safe to upgrade by installing a daily build over an existing version? Will that overwrite any settings? 
+"""]]
diff --git a/doc/install/Android/oldapp/comment_4_cebaa8ee5bbed27d9b2d032ca7bdec6e._comment b/doc/install/Android/oldapp/comment_4_cebaa8ee5bbed27d9b2d032ca7bdec6e._comment
new file mode 100644
index 0000000000..2745044a4c
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_4_cebaa8ee5bbed27d9b2d032ca7bdec6e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 4"
+ date="2013-07-05T00:53:00Z"
+ content="""
+It is safe to re-install, all your data and settings are stored in /sdcard and will not be touched, even if you delete the app!
+"""]]
diff --git a/doc/install/Android/oldapp/comment_8_34f7c42050fa48769a6bfae60d72e477._comment b/doc/install/Android/oldapp/comment_8_34f7c42050fa48769a6bfae60d72e477._comment
new file mode 100644
index 0000000000..efba6aeeb3
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_8_34f7c42050fa48769a6bfae60d72e477._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmrb8I1K5jjNr7ZrLSvgmkeQGjYauPeGJU"
+ nickname="Martin"
+ subject="comment 8"
+ date="2013-08-18T16:44:02Z"
+ content="""
+Any chance that older versions of Android will be supported in the future?
+"""]]
diff --git a/doc/install/Android/oldapp/comment_9_f3d289b78d6bdb3cc65689495a8439a5._comment b/doc/install/Android/oldapp/comment_9_f3d289b78d6bdb3cc65689495a8439a5._comment
new file mode 100644
index 0000000000..9893042422
--- /dev/null
+++ b/doc/install/Android/oldapp/comment_9_f3d289b78d6bdb3cc65689495a8439a5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://openlifechallenge.wordpress.com/"
+ nickname="O"
+ subject="Add to F-Droid"
+ date="2013-09-08T09:56:38Z"
+ content="""
+Hi,
+Really enjoy this app for Android! Super simple to use but it would be great if you could fix a folder navigator option when choosing location for device repo, right now it does not work. 
+
+Could you also add it to the F-Droid repository?
+"""]]
diff --git a/doc/install/ArchLinux.mdwn b/doc/install/ArchLinux.mdwn
new file mode 100644
index 0000000000..6919c4cbec
--- /dev/null
+++ b/doc/install/ArchLinux.mdwn
@@ -0,0 +1,21 @@
+There is now an [official git-annex package for Arch](https://www.archlinux.org/packages/community/x86_64/git-annex/), so to install it:
+
+	pacman -S git-annex
+
+There are at least three non non-official packages for git-annex in the Arch Linux User Repository. Any of these may be installed manually per [AUR guidelines](https://wiki.archlinux.org/index.php/AUR_User_Guidelines#Installing_packages) or using a wrapper such as [`yaourt`](https://wiki.archlinux.org/index.php/yaourt) shown below.
+
+1. A git-annex package is available in the haskell-core AUR <https://wiki.archlinux.org/index.php/ArchHaskell>
+
+2. A development package is available at [git-annex-git](https://aur.archlinux.org/packages/git-annex-git/) that functions similarly to the source package but builds directly from the HEAD of the git repository rather that the last official release.
+
+       $ yaourt -Sy git-annex-git
+
+3. A Cabal sandbox build is also available
+
+       $ yaourt -Sy git-annex-cabal
+
+Finally you may choose to forgo the Arch Linux package system entirely and install git-annex directly through cabal.
+
+    $ pacman -S git rsync curl wget gnupg openssh cabal-install
+    $ cabal update
+    $ cabal install git-annex --bindir=$HOME/bin
diff --git a/doc/install/ArchLinux/comment_10_b68c42b3804481808dfe83ae557edec3._comment b/doc/install/ArchLinux/comment_10_b68c42b3804481808dfe83ae557edec3._comment
new file mode 100644
index 0000000000..5dbd95adb5
--- /dev/null
+++ b/doc/install/ArchLinux/comment_10_b68c42b3804481808dfe83ae557edec3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 10"
+ date="2016-11-03T10:17:49Z"
+ content="""
+@caleb I didn't mean to slight the maintainer, if that's how it came across, just letting people know what I had to do to get a more recent version, in case they need the same (e.g. finding an issue like I had).
+
+I'll go and flag it any time a new release is done from now on, so it doesn't get missed :)
+"""]]
diff --git a/doc/install/ArchLinux/comment_11_0d51aaebe5929b03cba38156a97bf3cc._comment b/doc/install/ArchLinux/comment_11_0d51aaebe5929b03cba38156a97bf3cc._comment
new file mode 100644
index 0000000000..2469ba0382
--- /dev/null
+++ b/doc/install/ArchLinux/comment_11_0d51aaebe5929b03cba38156a97bf3cc._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="douglass.doug@f332d3f2822cae5f75accdf82fdab4a8f565e1f9"
+ nickname="douglass.doug"
+ avatar="http://cdn.libravatar.org/avatar/51567f932ee16ed200c339f44986d173"
+ subject="git-annex-bin package?"
+ date="2018-03-09T20:59:02Z"
+ content="""
+Seems the git-annex-bin package is no longer in AUR.
+
+@caleb any interesting in resurrecting the old git-annex-bin package?
+
+It would be a welcome option for users that have no other haskell-based packages installed vs. the community/git-annex package that now depends on ghc and *many* separate haskell packages. Reply or ping me, I can assist.
+"""]]
diff --git a/doc/install/ArchLinux/comment_2_e5f923e6d81cfb3fba7a72f60baaf4ab._comment b/doc/install/ArchLinux/comment_2_e5f923e6d81cfb3fba7a72f60baaf4ab._comment
new file mode 100644
index 0000000000..9b1f29623a
--- /dev/null
+++ b/doc/install/ArchLinux/comment_2_e5f923e6d81cfb3fba7a72f60baaf4ab._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://olivier.mehani.name/"
+ nickname="olivier-mehani"
+ subject="Stalling when creating repository in assistant"
+ date="2013-09-13T05:09:49Z"
+ content="""
+I am experiencing a weird issue with any install I've had on this one (and only) ArchLinux machine: all of aur/git-annex 4.20130516-1, aur/git-annex-bin-4.20130909-1, aur/git-annex-standalone-4.20130909-1 and a Cabal install just stall when trying to create the initial Git annex repo in the webapp.
+
+When started, it offers me to create the annex in ~/annex/ or ~/Desktop/annex/, where ~ gets turned into /home/USER when I press “Make repository”, but nothing else happens. This is regardless of if that repo exists when I try to create it or start the webapp.
+
+If I start the webapp from an existing annex (now in ~/annex), it seems to work a bit better, but any other remote (SSH) server that I try to add fails. I just get a fleeting Bootstrap message box when I click “Check this server”, and nothing in the logs of eithr git annex webapp or the ssh logs of the server.
+
+Any idea? Where should I look for more debug information?
+.
+
+"""]]
diff --git a/doc/install/ArchLinux/comment_3_8e607cd883ec174571e9dfe3b25bfd05._comment b/doc/install/ArchLinux/comment_3_8e607cd883ec174571e9dfe3b25bfd05._comment
new file mode 100644
index 0000000000..48a2888a21
--- /dev/null
+++ b/doc/install/ArchLinux/comment_3_8e607cd883ec174571e9dfe3b25bfd05._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.2.134"
+ subject="comment 3"
+ date="2013-09-13T15:35:59Z"
+ content="""
+Please post a [[bug report|bugs]] and start the webapp with the --debug option.
+"""]]
diff --git a/doc/install/ArchLinux/comment_4_a378391dd218859f381c479259dd8fe3._comment b/doc/install/ArchLinux/comment_4_a378391dd218859f381c479259dd8fe3._comment
new file mode 100644
index 0000000000..9146da9c83
--- /dev/null
+++ b/doc/install/ArchLinux/comment_4_a378391dd218859f381c479259dd8fe3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://olivier.mehani.name/"
+ nickname="olivier-mehani"
+ subject="comment 4"
+ date="2013-09-16T01:23:58Z"
+ content="""
+Done [0]. Not much debug output, unfortunately...
+
+[0] http://git-annex.branchable.com/bugs/Assistant_stalls_when_adding__47__creating_repo_on_ArchLinux/?updated
+"""]]
diff --git a/doc/install/ArchLinux/comment_6_1d597d6a95f9c2df7dae6e98813e4865._comment b/doc/install/ArchLinux/comment_6_1d597d6a95f9c2df7dae6e98813e4865._comment
new file mode 100644
index 0000000000..9f158347bc
--- /dev/null
+++ b/doc/install/ArchLinux/comment_6_1d597d6a95f9c2df7dae6e98813e4865._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqWbWVRH2k9spSMqKfIXBP1G3ekkj9Igg"
+ nickname="Rado"
+ subject="problem installing using cabal: language-javascript missing"
+ date="2014-03-28T22:38:04Z"
+ content="""
+Configuring gnuidn-0.2.1...
+cabal: The program c2hs is required but it could not be found.
+Failed to install gnuidn-0.2.1
+Configuring language-javascript-0.5.9...
+cabal: The program happy version >=1.18.5 is required but it could not be
+found.
+Failed to install language-javascript-0.5.9
+cabal: Error: some packages failed to install:
+git-annex-5.20140320 depends on language-javascript-0.5.9 which failed to
+install.
+gnuidn-0.2.1 failed during the configure step. The exception was:
+ExitFailure 1
+hjsmin-0.1.4.6 depends on language-javascript-0.5.9 which failed to install.
+language-javascript-0.5.9 failed during the configure step. The exception was:
+ExitFailure 1
+network-protocol-xmpp-0.4.6 depends on gnuidn-0.2.1 which failed to install.
+yesod-static-1.2.2.4 depends on language-javascript-0.5.9 which failed to
+install.
+[r-c@rc-laptop ~]$ cabal install language-javascript
+Resolving dependencies...
+Configuring language-javascript-0.5.9...
+cabal: The program happy version >=1.18.5 is required but it could not be
+found.
+Failed to install language-javascript-0.5.9
+cabal: Error: some packages failed to install:
+language-javascript-0.5.9 failed during the configure step. The exception was:
+ExitFailure 1
+
+Can you help how to solve?
+"""]]
diff --git a/doc/install/ArchLinux/comment_7_2d708977e2fad6b68803494576382df5._comment b/doc/install/ArchLinux/comment_7_2d708977e2fad6b68803494576382df5._comment
new file mode 100644
index 0000000000..3d7826bc10
--- /dev/null
+++ b/doc/install/ArchLinux/comment_7_2d708977e2fad6b68803494576382df5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://alerque.com/"
+ nickname="Caleb"
+ subject="dep problems"
+ date="2014-03-28T22:50:37Z"
+ content="""
+@rado The Haskel dependencies can be a nightmare to sort out for the un-initiated. You can side-step the whole issue by uninstalling the pre-built version that that has all the dependencies built in out of the box.
+
+Just grab the git-annex-bin package from the AUR and be done with it. (The -bin and -standalone packages recently merged so there is just -bin now).
+"""]]
diff --git a/doc/install/ArchLinux/comment_7_97d611f1ae6d4fbe91f84f9fe739f368._comment b/doc/install/ArchLinux/comment_7_97d611f1ae6d4fbe91f84f9fe739f368._comment
new file mode 100644
index 0000000000..31f153b026
--- /dev/null
+++ b/doc/install/ArchLinux/comment_7_97d611f1ae6d4fbe91f84f9fe739f368._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="dropped"
+ subject="Correct way to install git-annex directly through cabal."
+ date="2015-07-27T12:01:34Z"
+ content="""
+The effective way to install git-annex and resolve dependencies:
+
+    $ sudo pacman -S gsasl git rsync curl wget gnupg openssh cabal-install
+    $ cabal update
+    $ cabal install c2hs
+    $ cabal install git-annex --bindir=$HOME/bin
+    $ sudo cp ~/bin/git-annex /usr/lib/git-core
+"""]]
diff --git a/doc/install/ArchLinux/comment_8_5b5f5e0b64e5bfb1ea12e8b251c6fb5f._comment b/doc/install/ArchLinux/comment_8_5b5f5e0b64e5bfb1ea12e8b251c6fb5f._comment
new file mode 100644
index 0000000000..3e6d6b3a82
--- /dev/null
+++ b/doc/install/ArchLinux/comment_8_5b5f5e0b64e5bfb1ea12e8b251c6fb5f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmqWbWVRH2k9spSMqKfIXBP1G3ekkj9Igg"
+ nickname="Rado"
+ subject="I solved it installing dependencies....but dont know hot to start it..."
+ date="2014-03-29T07:45:19Z"
+ content="""
+cabal install gsasl
+cabal install happy
+cabal install language-javascript
+cabal install alex
+cabal install c2hs
+
+after installing writing in terminal: git-annex, git-annex webapp does nothing...
+can you help how to start git-annex?
+"""]]
diff --git a/doc/install/ArchLinux/comment_8_ddc13b45286933e7dd06f5bd6ea8fac9._comment b/doc/install/ArchLinux/comment_8_ddc13b45286933e7dd06f5bd6ea8fac9._comment
new file mode 100644
index 0000000000..9d1a601a67
--- /dev/null
+++ b/doc/install/ArchLinux/comment_8_ddc13b45286933e7dd06f5bd6ea8fac9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 8"
+ date="2016-11-03T09:44:23Z"
+ content="""
+Right now, the git-annex package in community is quite outdated (2016-06).
+
+If you wish to install a newer version, you can use git-annex-git from AUR instead. You will need to disable S3 support in the PKGBUILD (and perhaps add haskell-core in pacman.conf), because haskell-hs3 doesn't seem to be available (Not that I looked too hard, as I don't use it..).
+"""]]
diff --git a/doc/install/ArchLinux/comment_9_b5f1bd5d92cf35002e2ea75e07040bea._comment b/doc/install/ArchLinux/comment_9_b5f1bd5d92cf35002e2ea75e07040bea._comment
new file mode 100644
index 0000000000..5f440dc7aa
--- /dev/null
+++ b/doc/install/ArchLinux/comment_9_b5f1bd5d92cf35002e2ea75e07040bea._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="caleb@2b0d6f0eabf955cc8fd04c634b09f0ca4aad9233"
+ nickname="caleb"
+ avatar="http://cdn.libravatar.org/avatar/1d84382865c6c3378c04a35348fdfa07"
+ subject="Arch packages"
+ date="2016-11-03T09:54:34Z"
+ content="""
+@CandyAngel the Arch package in community has only been flagged as out of date since last week. It usually takes about a week once packages get flagged for the updates to drop. If it doesn't drop by the end of this week we can file a bug and get somebody on it. Using the -git package from AUR should not be necessary to get the latest released version of software on arch. If it is something is broken and should be fixed.
+"""]]
diff --git a/doc/install/Debian.mdwn b/doc/install/Debian.mdwn
new file mode 100644
index 0000000000..4b44894d59
--- /dev/null
+++ b/doc/install/Debian.mdwn
@@ -0,0 +1,14 @@
+## Debian testing or unstable
+
+Debian unstable and testing are usually fairly up to date,
+so this should be enough:
+
+	sudo apt install git-annex
+
+## Standalone backports for all releases
+
+If the version shipped with Debian is too old, 
+the [NeuroDebian team](http://neuro.debian.net/) provides a
+[standalone build package](http://neuro.debian.net/pkgs/git-annex-standalone.html)
+that is regularly updated and that should work across all releases of
+Debian.
diff --git a/doc/install/Debian/comment_11_b44ed53973ac26eedd3838df28f74a7e._comment b/doc/install/Debian/comment_11_b44ed53973ac26eedd3838df28f74a7e._comment
new file mode 100644
index 0000000000..45925cdd99
--- /dev/null
+++ b/doc/install/Debian/comment_11_b44ed53973ac26eedd3838df28f74a7e._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="chris"
+ subject="Easy"
+ date="2014-12-23T08:18:31Z"
+ content="""
+Easy to install.
+"""]]
diff --git a/doc/install/Debian/comment_12_a0105d7f045511b9c80ea9bb0eac3708._comment b/doc/install/Debian/comment_12_a0105d7f045511b9c80ea9bb0eac3708._comment
new file mode 100644
index 0000000000..7305f23f74
--- /dev/null
+++ b/doc/install/Debian/comment_12_a0105d7f045511b9c80ea9bb0eac3708._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Alan"
+ avatar="http://cdn.libravatar.org/avatar/9cbc26346f1c693d7df198e662a5fdae"
+ subject="No package for armhf on stretch"
+ date="2017-08-28T09:00:15Z"
+ content="""
+I cannot find a package in stretch for armhf (It's not listed here: https://packages.debian.org/stretch/git-annex). Is my only option to install from source?
+"""]]
diff --git a/doc/install/Debian/comment_13_435fb1359ea7f481ae23a973216085d8._comment b/doc/install/Debian/comment_13_435fb1359ea7f481ae23a973216085d8._comment
new file mode 100644
index 0000000000..e17db396a5
--- /dev/null
+++ b/doc/install/Debian/comment_13_435fb1359ea7f481ae23a973216085d8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Alan"
+ avatar="http://cdn.libravatar.org/avatar/9cbc26346f1c693d7df198e662a5fdae"
+ subject="For stretch on armhf, install from unstable"
+ date="2017-08-28T09:25:22Z"
+ content="""
+I found that there is a git-annex package available on unstable, so I installed this one. Everything seems to work.
+"""]]
diff --git a/doc/install/Debian/comment_14_a34e23d9aa3027012ab1236aa4f7d5cb._comment b/doc/install/Debian/comment_14_a34e23d9aa3027012ab1236aa4f7d5cb._comment
new file mode 100644
index 0000000000..86f1d60502
--- /dev/null
+++ b/doc/install/Debian/comment_14_a34e23d9aa3027012ab1236aa4f7d5cb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Miles"
+ ip="88.175.62.104"
+ subject="installed git-annex on debian but cannot find it"
+ date="2013-08-19T23:29:24Z"
+ content="""
+I am an absolute beginner when it comes to linux in debian in particular. I installed git-annex via the root terminal, but now I do not know where to find it. I searched for in the file system but could not locate it. Any help is appreciated.
+"""]]
diff --git a/doc/install/Debian/comment_15_20d8271ba3f6cfe3c8849c3d41607630._comment b/doc/install/Debian/comment_15_20d8271ba3f6cfe3c8849c3d41607630._comment
new file mode 100644
index 0000000000..6f32c2b0b8
--- /dev/null
+++ b/doc/install/Debian/comment_15_20d8271ba3f6cfe3c8849c3d41607630._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk_GWOEjK4Sn4hUB6ofFlE3CNeC7tO56J8"
+ nickname="John"
+ subject="Re:  installed git-annex on debian but cannot find it "
+ date="2013-08-20T00:50:28Z"
+ content="""
+@Miles - The command is git annex webapp to bring up the web interface.
+"""]]
diff --git a/doc/install/Debian/comment_16_89f67da4a4a6a626a7db9c6674b244b6._comment b/doc/install/Debian/comment_16_89f67da4a4a6a626a7db9c6674b244b6._comment
new file mode 100644
index 0000000000..563be1c6c1
--- /dev/null
+++ b/doc/install/Debian/comment_16_89f67da4a4a6a626a7db9c6674b244b6._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm9ocq1Kb0WL-cz-LPpvd2Xm-q8tIQvqXA"
+ nickname="Dominik"
+ subject="debian squeeze"
+ date="2014-05-16T22:58:52Z"
+ content="""
+I'm tring to set up a bare repo on a debian squeeze server and sync it to windows client. Unfortunately the direct mode does not seem to be available for the git-annex version (3.20120629~bpo60+2
+) in the squeeze-backports 
+
+Would you be able to update the version in that repository? Thank you for your hard work! Git-annex is awesome
+"""]]
diff --git a/doc/install/Debian/comment_17_ef7f3e88d61833e51f0302e938343818._comment b/doc/install/Debian/comment_17_ef7f3e88d61833e51f0302e938343818._comment
new file mode 100644
index 0000000000..cd42becc27
--- /dev/null
+++ b/doc/install/Debian/comment_17_ef7f3e88d61833e51f0302e938343818._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="216.145.95.162"
+ subject="comment 17"
+ date="2014-05-17T17:03:31Z"
+ content="""
+Debian squeeze has an extremely ancient ghc compiler, and it would be a mammoth undertaking to build current git-annex using that. 
+
+Use the linux standalone build instead.
+"""]]
diff --git a/doc/install/Debian/comment_1_029486088d098c2d4f1099f2f0e701a9._comment b/doc/install/Debian/comment_1_029486088d098c2d4f1099f2f0e701a9._comment
new file mode 100644
index 0000000000..9a4ed7c31d
--- /dev/null
+++ b/doc/install/Debian/comment_1_029486088d098c2d4f1099f2f0e701a9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawla7u6eLKNYZ09Z7xwBffqLaXquMQC07fU"
+ nickname="Matthias"
+ subject="squeeze-backports update?"
+ date="2011-08-17T12:34:46Z"
+ content="""
+Is there going to be an update of git-annex in debian squeeze-backports to a version that supports repository version 3?
+Thx
+"""]]
diff --git a/doc/install/Debian/comment_2_648e3467e260cdf233acdb0b53313ce0._comment b/doc/install/Debian/comment_2_648e3467e260cdf233acdb0b53313ce0._comment
new file mode 100644
index 0000000000..b8b3d68f33
--- /dev/null
+++ b/doc/install/Debian/comment_2_648e3467e260cdf233acdb0b53313ce0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="Re: squeeze-backports update?"
+ date="2011-08-17T15:34:29Z"
+ content="""
+Yes, I uploaded it last night.
+"""]]
diff --git a/doc/install/Debian/comment_3_4d922e11249627634ecc35bba4044d9e._comment b/doc/install/Debian/comment_3_4d922e11249627634ecc35bba4044d9e._comment
new file mode 100644
index 0000000000..98d65740bc
--- /dev/null
+++ b/doc/install/Debian/comment_3_4d922e11249627634ecc35bba4044d9e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkstq9oH1vHXY_VP0nYO9Gg3eKnKerDGRI"
+ nickname="Hadi"
+ subject="ARM"
+ date="2012-07-31T15:13:06Z"
+ content="""
+is there any package for Debian armhf? I'd love to install git-annex on my raspberry pi
+"""]]
diff --git a/doc/install/Debian/comment_4_2a93ab18b05ccb90e7acc5885866fca2._comment b/doc/install/Debian/comment_4_2a93ab18b05ccb90e7acc5885866fca2._comment
new file mode 100644
index 0000000000..8436f0354a
--- /dev/null
+++ b/doc/install/Debian/comment_4_2a93ab18b05ccb90e7acc5885866fca2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 4"
+ date="2012-07-31T15:41:43Z"
+ content="""
+Yes, git-annex is available for every Debian architecture which supports Haskell, including all arm ports:
+
+<pre>git-annex | 3.20120629         | wheezy            | source, amd64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc</pre>
+"""]]
diff --git a/doc/install/Debian/comment_7_1bccc7bf7a4ef61a9b30024b9b22ba7d._comment b/doc/install/Debian/comment_7_1bccc7bf7a4ef61a9b30024b9b22ba7d._comment
new file mode 100644
index 0000000000..6d8cae2f0a
--- /dev/null
+++ b/doc/install/Debian/comment_7_1bccc7bf7a4ef61a9b30024b9b22ba7d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://mey.vn/"
+ ip="46.65.14.106"
+ subject="libc6 dep version on amd64"
+ date="2013-05-28T15:28:47Z"
+ content="""
+hi Joey,
+
+i see from the release notes of the 4.20130521 release that the Debian package should now be built with libc6 2.13, which appears to be the case except for the amd64 arch (hence the amd64 package won't install as is on Wheezy on amd64) - is this a build glitch or is 2.14 needed on amd64 (i imagine as a dependency of one of git-annex's deps on that arch)?
+
+thanks!
+"""]]
diff --git a/doc/install/Debian/comment_8_5b5a3b0e8abe8831a6a15a4e258d14fd._comment b/doc/install/Debian/comment_8_5b5a3b0e8abe8831a6a15a4e258d14fd._comment
new file mode 100644
index 0000000000..253df3d078
--- /dev/null
+++ b/doc/install/Debian/comment_8_5b5a3b0e8abe8831a6a15a4e258d14fd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 8"
+ date="2013-05-29T16:23:10Z"
+ content="""
+@mey.vn, Debian packages of git-annex, as uploaded to the Debian repositories, are built with whatever libc version the Debian autobuilder is running. You cannot, in general, install packages from Debian unstable into stable without upgrading your libc6.
+
+The release notes were not talking about the Debian packages, but about the [[Linux_standalone]] tarballs. Those are built with libc 2.13.
+"""]]
diff --git a/doc/install/Docker.mdwn b/doc/install/Docker.mdwn
new file mode 100644
index 0000000000..9f3f3bd33f
--- /dev/null
+++ b/doc/install/Docker.mdwn
@@ -0,0 +1,6 @@
+There is not yet a pre-built Docker image for git-annex. However, it's
+easy to add it to an image.
+
+For example:
+
+	docker run -i -t debian apt-get install git-annex
diff --git a/doc/install/Docker/comment_1_909e3b2da0050ce1102c289cc5aac522._comment b/doc/install/Docker/comment_1_909e3b2da0050ce1102c289cc5aac522._comment
new file mode 100644
index 0000000000..ea43a4d9a3
--- /dev/null
+++ b/doc/install/Docker/comment_1_909e3b2da0050ce1102c289cc5aac522._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="matei.david@d6acba23dba331f26fc4756d01c7ab65cf3aee4d"
+ nickname="matei.david"
+ subject="A more detailed walkthrough"
+ date="2016-06-03T18:48:11Z"
+ content="""
+I want to use a recent `git-annex` version, and I prefer a Docker solution to a binary. There wasn't much documentation on how to do that, so here are the steps I took, just in case anybody finds this information useful. This is not a complete guide, just more than I was able to find so far.
+
+- Install Docker so that you can access it (eg, `docker info`) without `sudo`. (Beyond the scope in here.)
+
+- Create a git-annex image as follows:
+
+Dockerfile:
+
+    FROM debian:unstable
+    RUN apt-get update && apt-get install -y ssh git man git-annex=6.20160511-1
+    # maybe install gpg2, other remotes, etc
+    #RUN apt-get install -y gnupg2 && ln -s /usr/bin/gpg2 /usr/local/bin/gpg
+    #RUN apt-get install -y golang-go && GOPATH=/usr/local go get github.com/encryptio/git-annex-remote-b2
+    VOLUME /data
+    WORKDIR /data
+
+Build image and run basic test:
+
+    docker build -t git-annex-6.20160511-1 .
+    docker run -it --rm git-annex-6.20160511-1 git-annex version
+
+- You still need to:
+
+  - On host: Replace `git-annex` by a script that invokes the Dockerized version.
+  - In container:
+    - Use non-root uids, otherwise you end up creating files with uid 0.
+    - Access `ssh` and `gpg` credentials on host.
+    - Access `~/.gitconfig` on host.
+    - Mount `git` repository root as a volume, not just the current dir.
+    - Access AWS/B2 credentials, if applicable.
+
+Here is a sample script that achieves these. Name it `git-annex`, and place it in your `PATH` before the host `git-annex` (or just uninstall the latter).
+
+    #!/bin/bash
+    CONT_NAME=${CONT_NAME:-git-annex-6.20160511-1}
+    # if in git repo, mount root as /data, and cd into relative subdir
+    # if not, mount cwd as /data
+    abs_dir=$(readlink -e .)
+    root_dir=$(git rev-parse --show-toplevel 2>/dev/null || true)
+    root_dir=${root_dir:-$abs_dir}
+    rel_dir=${abs_dir#$root_dir}
+    # if run by git, assume command is git-annex
+    # otherwise, don't assume, to allow other uses
+    cmd=
+    ! [ \"$(basename \"$(readlink -e /proc/$PPID/exe)\")\" = \"git\" ] || cmd=git-annex
+    exec docker run -it --rm \
+        -u $(id -u):$(id -g) \
+        -v /etc/passwd:/etc/passwd:ro \
+        -v $HOME/.ssh:$HOME/.ssh \
+        -v $HOME/.gnupg:$HOME/.gnupg \
+        -v $HOME/.gitconfig:$HOME/.gitconfig \
+        -v \"$root_dir\":/data \
+        ${AWS_ACCESS_KEY_ID:+-e AWS_ACCESS_KEY_ID=\"$AWS_ACCESS_KEY_ID\"} \
+        ${AWS_SECRET_ACCESS_KEY:+-e AWS_SECRET_ACCESS_KEY=\"$AWS_SECRET_ACCESS_KEY\"} \
+        ${B2_ACCOUNT_ID:+-e B2_ACCOUNT_ID=\"$B2_ACCOUNT_ID\"} \
+        ${B2_APP_KEY:+-e B2_APP_KEY=\"$B2_APP_KEY\"} \
+        -w /data\"$rel_dir\" \
+        $CONT_NAME $cmd \"$@\"
+
+"""]]
diff --git a/doc/install/Fedora.mdwn b/doc/install/Fedora.mdwn
new file mode 100644
index 0000000000..9c31165f83
--- /dev/null
+++ b/doc/install/Fedora.mdwn
@@ -0,0 +1,40 @@
+git-annex is available in recent versions of Fedora.
+[status](http://koji.fedoraproject.org/koji/packageinfo?packageID=14145)
+
+Should be as simple as: `yum install git-annex`
+
+Note: Fedora's build does not currently include the git-annex webapp.
+
+----
+
+To install the latest version of git-annex on Fedora 18 and later, you can use `cabal`:
+
+<pre>
+# Install dependencies
+sudo yum install libxml2-devel gnutls-devel libgsasl-devel ghc cabal-install happy alex libidn-devel
+# Update the cabal list
+cabal update
+# Install c2hs, required by dependencies of git-annex, but not automatically installed
+cabal install --bindir=$HOME/bin c2hs
+# Install git-annex
+cabal install --bindir=$HOME/bin git-annex
+</pre>
+
+----
+
+Older version? Here's an installation recipe for Fedora 14 through 15.
+
+<pre>
+sudo yum install ghc cabal-install
+git clone git://git-annex.branchable.com/ git-annex
+cd git-annex
+git checkout ghc7.0
+cabal update
+cabal install --only-dependencies
+cabal configure
+cabal build
+cabal install --bindir=$HOME/bin
+</pre>
+
+Note: You can't just use `cabal install git-annex`, because Fedora does
+not yet ship ghc 7.4.
diff --git a/doc/install/Fedora/comment_1_c4db84e672ad4b45b522db735706b00f._comment b/doc/install/Fedora/comment_1_c4db84e672ad4b45b522db735706b00f._comment
new file mode 100644
index 0000000000..bdc8c9e06c
--- /dev/null
+++ b/doc/install/Fedora/comment_1_c4db84e672ad4b45b522db735706b00f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://mebus.myopenid.com/"
+ ip="2a01:198:3eb:0:4a5b:39ff:fea4:55b3"
+ subject="RPM of version 4.2"
+ date="2013-07-30T01:09:54Z"
+ content="""
+Hi!
+
+Isn't there an rpm package of version 4.2 available for Fedora 17 or 18?
+
+Thanks!
+
+Mebus
+
+
+"""]]
diff --git a/doc/install/Fedora/comment_2_f98c488c09bef86e2b0414589ce9e141._comment b/doc/install/Fedora/comment_2_f98c488c09bef86e2b0414589ce9e141._comment
new file mode 100644
index 0000000000..0a1de29b53
--- /dev/null
+++ b/doc/install/Fedora/comment_2_f98c488c09bef86e2b0414589ce9e141._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="http://mebus.pip.verisignlabs.com/"
+ nickname="Bussard"
+ subject="comment 2"
+ date="2013-07-30T20:41:07Z"
+ content="""
+When I try to build in from source on Fedora 17, I get this error:
+
+[ 77 of 163] Compiling Utility.DiskFree ( Utility/DiskFree.hs, dist/build/git-annex/git-annex-tmp/Utility/DiskFree.o )
+[ 78 of 163] Compiling Utility.Url      ( Utility/Url.hs, dist/build/git-annex/git-annex-tmp/Utility/Url.o )
+
+Utility/Url.hs:111:88:
+    Couldn't match expected type `Maybe URI' with actual type `URI'
+    In the second argument of `fromMaybe', namely
+      `(newURI `relativeTo` u)'
+    In the expression: fromMaybe newURI (newURI `relativeTo` u)
+    In an equation for `newURI_abs':
+        newURI_abs = fromMaybe newURI (newURI `relativeTo` u)
+
+Any help?
+
+Mebus
+
+
+"""]]
diff --git a/doc/install/Fedora/comment_3_d872acf8865fe7c99a9b712db5b38ea4._comment b/doc/install/Fedora/comment_3_d872acf8865fe7c99a9b712db5b38ea4._comment
new file mode 100644
index 0000000000..4a86249616
--- /dev/null
+++ b/doc/install/Fedora/comment_3_d872acf8865fe7c99a9b712db5b38ea4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 3"
+ date="2013-07-30T21:25:32Z"
+ content="""
+Edit Utility/Url.hs and play around with the version in the `MIN_VERSION_network` define.  It seems to me that your system needs to build with the #else branch of the #ifdef, despite having a version of the haskell network package older than 2.4.0. It's possible that the haskell network package has been modified by Fedora.
+"""]]
diff --git a/doc/install/Fedora/comment_4_93b3402e4c51e1a5c96f907bb528164b._comment b/doc/install/Fedora/comment_4_93b3402e4c51e1a5c96f907bb528164b._comment
new file mode 100644
index 0000000000..afdbf1dc16
--- /dev/null
+++ b/doc/install/Fedora/comment_4_93b3402e4c51e1a5c96f907bb528164b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI"
+ nickname="Michele"
+ subject="installing on fc19"
+ date="2013-10-18T21:05:56Z"
+ content="""
+i share my experience in installing from source on fc19, I must admit these are useful only for haskell novices:
+should cabal complain about missing libffi.so.5 (as it happened to me), do 
+
+     yum install compat-libffi
+
+and you'll get the missing library (the shipping version with fc19 is libffi.so.6)
+also: in order for the git annex to be picked up globally or better to end up in the default path i had to:
+
+     cabal install --global 
+"""]]
diff --git a/doc/install/Fedora/comment_5_0427e0503764b29e57abf9e97155136b._comment b/doc/install/Fedora/comment_5_0427e0503764b29e57abf9e97155136b._comment
new file mode 100644
index 0000000000..df518ea11d
--- /dev/null
+++ b/doc/install/Fedora/comment_5_0427e0503764b29e57abf9e97155136b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://mebus.myopenid.com/"
+ ip="2a01:198:3eb:0:4a5b:39ff:fea4:55b3"
+ subject="Error on Fedora 19"
+ date="2013-10-19T14:57:12Z"
+ content="""
+On Fedora 19, I am getting this error:
+
+http://pastebin.com/raw.php?i=c9SNjbXV
+
+Mebus
+
+
+
+"""]]
diff --git a/doc/install/Fedora/comment_6_1b1b38a79251fe2e8c1e4debbe3bc3c5._comment b/doc/install/Fedora/comment_6_1b1b38a79251fe2e8c1e4debbe3bc3c5._comment
new file mode 100644
index 0000000000..ffb6f06059
--- /dev/null
+++ b/doc/install/Fedora/comment_6_1b1b38a79251fe2e8c1e4debbe3bc3c5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://mebus.myopenid.com/"
+ ip="2a01:198:3eb:0:4a5b:39ff:fea4:55b3"
+ subject="comment 6"
+ date="2013-10-19T15:09:34Z"
+ content="""
+Worked! I forgot to install c2hs.
+
+Mebus
+
+
+"""]]
diff --git a/doc/install/Fedora/comment_7_4832d271dcc63a6cd1c40fe38ad5e367._comment b/doc/install/Fedora/comment_7_4832d271dcc63a6cd1c40fe38ad5e367._comment
new file mode 100644
index 0000000000..ec9308b70e
--- /dev/null
+++ b/doc/install/Fedora/comment_7_4832d271dcc63a6cd1c40fe38ad5e367._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI"
+ nickname="Michele"
+ subject="building fails on fedora 19"
+ date="2014-05-26T15:31:10Z"
+ content="""
+latest version (git-annex-5.20140517) during cabal install git-annex I encounter this:
+
+[[!format sh \"\"\"
+[266 of 457] Compiling Remote.WebDAV    ( Remote/WebDAV.hs, dist/build/git-annex/git-annex-tmp/Remote/WebDAV.o )
+
+Remote/WebDAV.hs:380:32:
+    Constructor `StatusCodeException' should have 3 arguments, but has been given 2
+    In the pattern: StatusCodeException s _
+    In an equation for `matchStatusCodeException':
+        matchStatusCodeException want (StatusCodeException s _)
+          | s == want = Just ()
+          | otherwise = Nothing
+Failed to install git-annex-5.20140517
+cabal: Error: some packages failed to install:
+git-annex-5.20140517 failed during the building phase. The exception was:
+ExitFailure 1
+\"\"\"]]
+"""]]
diff --git a/doc/install/Fedora/comment_8_80e167cde1a6511683a8f6e8029c0da6._comment b/doc/install/Fedora/comment_8_80e167cde1a6511683a8f6e8029c0da6._comment
new file mode 100644
index 0000000000..e649ff759c
--- /dev/null
+++ b/doc/install/Fedora/comment_8_80e167cde1a6511683a8f6e8029c0da6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.176"
+ subject="comment 8"
+ date="2014-05-27T16:08:14Z"
+ content="""
+@Michele, you seem to have an old version of the haskell DAV library installed. The simple solutions is probably `cabal install DAV` to upgrade to the new one.
+
+(The complex solution is to edit the file and copy the line 2 lines above the error, or fix the ifdefs somehow to work with whatever combination of versions of DAV and http-client or http-conduit you have installed.)
+"""]]
diff --git a/doc/install/FreeBSD.mdwn b/doc/install/FreeBSD.mdwn
new file mode 100644
index 0000000000..358c02d5a1
--- /dev/null
+++ b/doc/install/FreeBSD.mdwn
@@ -0,0 +1,2 @@
+git-annex is in FreeBSD ports in
+[devel/hs-git-annex](http://www.freshports.org/devel/hs-git-annex/)
diff --git a/doc/install/Gentoo.mdwn b/doc/install/Gentoo.mdwn
new file mode 100644
index 0000000000..feeaad739b
--- /dev/null
+++ b/doc/install/Gentoo.mdwn
@@ -0,0 +1,3 @@
+Gentoo users can: `emerge git-annex`
+
+A possibly more up-to-date version is in the haskell portage overlay.
diff --git a/doc/install/Guix.mdwn b/doc/install/Guix.mdwn
new file mode 100644
index 0000000000..8816ca5031
--- /dev/null
+++ b/doc/install/Guix.mdwn
@@ -0,0 +1,7 @@
+git-annex can be installed with the [GNU Guix](https://www.gnu.org/software/guix) package manager.
+
+    guix package -i git-annex
+
+Currently (as of March 2021), some features are not enabled in the package.
+
+    -Android -Webapp
diff --git a/doc/install/Linux_standalone.mdwn b/doc/install/Linux_standalone.mdwn
new file mode 100644
index 0000000000..7c7b6f2a3d
--- /dev/null
+++ b/doc/install/Linux_standalone.mdwn
@@ -0,0 +1,68 @@
+If your Linux distribution does not have git-annex packaged up for you,
+you can either build it [[fromsource]], or you can use a handy
+prebuilt tarball of the most recent release.
+
+This tarball should work on most Linux systems. It has basically no
+dependencies and is self-contained.
+
+* x86-64: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz)
+* x86-32: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386.tar.gz)
+* x86-32, for ancient kernels: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386-ancient.tar.gz)
+* arm: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-armel.tar.gz)
+* arm64: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-arm64.tar.gz)
+* arm64, for ancient kernels: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-arm64-ancient.tar.gz)
+
+To use, just unpack the tarball, `cd git-annex.linux` and run `./runshell`
+-- this sets up an environment where you can use `git annex`, as well
+as everything else included in the bundle.
+
+Alternatively, you can unpack the tarball, and add the directory to your
+`PATH`, or symlink the programs in the directory to a directory in your
+PATH. This lets you use `git annex`, without overriding your system's
+own versions of git, etc.
+
+The arm version can be installed on NAS devices and other embedded ARM
+linux systems.
+
+* [[tips/Synology_NAS_and_git_annex]]
+* [[forum_thread|forum/new_linux_arm_tarball_build]]
+
+The x86-32 build for ancient kernels is for use with Linux kernel
+versions such as 2.6.32. It will work on both 32 and 64 bit systems.
+The arm64 build for ancient kernels is for kernels such as 4.19,
+which is still in use on Android phones.
+
+## autobuilds
+
+An hourly autobuild is also available, hosted by [[Joey]]:
+
+* x86-64: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/amd64/git-annex-standalone-amd64.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/amd64/))
+* x86-32: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/i386/git-annex-standalone-i386.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/i386/))
+* x86-32, for ancient kernels: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/i386-ancient/git-annex-standalone-i386-ancient.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/i386-ancient/))
+* arm64: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/arm64/git-annex-standalone-arm64.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/arm64/))
+* arm64, for ancient kernels: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/arm64-ancient/git-annex-standalone-arm64-ancient.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/arm64-ancient/))
+
+The arm autobuilder runs daily (sun permitting), and is hosted by [[Joey]].
+
+* arm: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/armel/git-annex-standalone-armel.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/armel/))
+
+## download security
+
+All the download links above use https for security. For added security, see
+[[verifying_downloads]].
+
+## building it yourself
+
+This entails building git-annex from source, so you will first
+need to get that working, see [[fromsource]] for some of the details.
+
+In git-annex's source tree, run `make linuxstandalone`. This will build
+git-annex from source, and then build the tarball bundle, into eg
+`tmp/git-annex-standalone-amd64.tar.gz`
+
+This build process is done on a Debian system, and it needs to use
+`dpkg` to examine the host system.
+
+## technical details
+
+The way those tarballs work is described in [joeyh's blog](http://joeyh.name/blog/entry/completely_linux_distribution-independent_packaging/).
diff --git a/doc/install/Linux_standalone/comment_1_1adc00aecc51f1e74701bd67cd74155d._comment b/doc/install/Linux_standalone/comment_1_1adc00aecc51f1e74701bd67cd74155d._comment
new file mode 100644
index 0000000000..8218aa40d9
--- /dev/null
+++ b/doc/install/Linux_standalone/comment_1_1adc00aecc51f1e74701bd67cd74155d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c"
+ nickname="Justin"
+ subject="Are the ARM binaries ARMv6 or ARMv7?"
+ date="2014-02-26T21:04:44Z"
+ content="""
+I'm trying to run git-annex on my Raspberry PI, which is an ARMv6 device.  But I can't tell if the prebuilt binaries are ARMv6 or ARMv7.  The binaries seem to work, but it's not clear to me how early I should expect things to fail if they're compiled for ARMv7.
+"""]]
diff --git a/doc/install/Linux_standalone/comment_2_7983285b56fd10359a7cc3615fd1e2fe._comment b/doc/install/Linux_standalone/comment_2_7983285b56fd10359a7cc3615fd1e2fe._comment
new file mode 100644
index 0000000000..996263b181
--- /dev/null
+++ b/doc/install/Linux_standalone/comment_2_7983285b56fd10359a7cc3615fd1e2fe._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.146"
+ subject="comment 2"
+ date="2014-02-26T21:07:20Z"
+ content="""
+The arm binaries are ARMv6; they're built on a Debian armel system.
+
+Obviously there is a lot of variation in ARM instructions sets. Like Debian, we're shooting for lowest common denominator here.
+
+(Note: I'm going to be moving your comment and this one to the place you should have posted it...)
+"""]]
diff --git a/doc/install/Linux_standalone/comment_3_eaa9b0532d4629b61f3a684886b1d4f9._comment b/doc/install/Linux_standalone/comment_3_eaa9b0532d4629b61f3a684886b1d4f9._comment
new file mode 100644
index 0000000000..62ab93ca88
--- /dev/null
+++ b/doc/install/Linux_standalone/comment_3_eaa9b0532d4629b61f3a684886b1d4f9._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="nasava"
+ subject="Ancient variant for Armel"
+ date="2016-03-08T22:02:29Z"
+ content="""
+I have a NAS running Linux Kernel 2.6.36 unfortunately not possible updating it. The newest standalone build complains about \"kernel too old\". Is there a variant somewhere for ancient armel also like for x86_32? Or how can I build one?
+"""]]
diff --git a/doc/install/Linux_standalone/comment_4_070689ea45739d06260da07d1369dff9._comment b/doc/install/Linux_standalone/comment_4_070689ea45739d06260da07d1369dff9._comment
new file mode 100644
index 0000000000..61ed0ff34d
--- /dev/null
+++ b/doc/install/Linux_standalone/comment_4_070689ea45739d06260da07d1369dff9._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-03-09T17:16:54Z"
+ content="""
+I've opened a todo, [[todo/add_ancient_armel_build]]
+"""]]
diff --git a/doc/install/Linux_standalone/comment_5_9046b80114fc03179c971bfb3e4d666d._comment b/doc/install/Linux_standalone/comment_5_9046b80114fc03179c971bfb3e4d666d._comment
new file mode 100644
index 0000000000..4241cb23c0
--- /dev/null
+++ b/doc/install/Linux_standalone/comment_5_9046b80114fc03179c971bfb3e4d666d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="building the standalone distribution on CentOS"
+ date="2020-10-16T14:58:42Z"
+ content="""
+\"This build process is done on a Debian system, and it needs to use dpkg to examine the host system\" -- would it be hard to make this work on CentOS?  (For building the standalone tarball as part of building the [conda-forge package](https://github.com/conda-forge/git-annex-feedstock/), where the build process uses [this docker image](https://github.com/conda-forge/docker-images/blob/master/linux-anvil-comp7/Dockerfile).)
+"""]]
diff --git a/doc/install/NixOS.mdwn b/doc/install/NixOS.mdwn
new file mode 100644
index 0000000000..0ef55b6e33
--- /dev/null
+++ b/doc/install/NixOS.mdwn
@@ -0,0 +1,10 @@
+Users of the [Nix package manager](http://nixos.org/) can install it by running:
+
+    nix-env -i git-annex
+
+When including it in a NixOS configuration.nix file, the name of the reference to the package is
+
+    haskellPackages.git-annex
+
+The build status of the package within Nix can be seen on the [Hydra Build
+Farm](http://hydra.nixos.org/job/nixpkgs/trunk/gitAndTools.gitAnnex).
diff --git a/doc/install/NixOS/comment_1_4e487ddd2654a8a992c1538b9c3bf003._comment b/doc/install/NixOS/comment_1_4e487ddd2654a8a992c1538b9c3bf003._comment
new file mode 100644
index 0000000000..8424b632dd
--- /dev/null
+++ b/doc/install/NixOS/comment_1_4e487ddd2654a8a992c1538b9c3bf003._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
+ nickname="Matthias"
+ subject="build failure"
+ date="2014-06-09T15:13:18Z"
+ content="""
+Building git-annex with Nix 1.7 fails for me. Error:
+
+    trying https://git.samba.org/?p=rsync.git;a=commitdiff_plain;h=0dedfbce2c1b851684ba658861fe9d620636c56a
+      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
+                                     Dload  Upload   Total   Spent    Left  Speed
+    100  2277    0  2277    0     0   2805      0 --:--:-- --:--:-- --:--:--  5735
+    output path `/nix/store/w6l1c3cdr52arymv3zgwly7razwnsdll-CVE-2014-2855.patch' should have sha256 hash `1jpwwdf07naqxc8fv1lspc95jgk50j5j3wvf037bjay2qzpwjmvf', instead has `0j1pqmwsqc5mh815x28izi4baki2y2r5q8k7ma1sgs4xsgjc4rk8'
+    building path(s) `/nix/store/85v7c8b3ygpfj8m8bk98kcygf29qcbq7-cacert-20131205.pem.bz2'
+    cannot build derivation `/nix/store/im9p1y2xbh08yrwp5yggj1ii884wv3ql-rsync-3.1.0.drv': 1 dependencies couldn't be built
+    killing process 2599
+    cannot build derivation `/nix/store/sl48cnm06m7mcqxjfj2b0yv8am3blqr3-git-annex-5.20140517.drv': 1 dependencies couldn't be built
+    error: build of `/nix/store/sl48cnm06m7mcqxjfj2b0yv8am3blqr3-git-annex-5.20140517.drv' failed
+
+Someone has an idea what Nix expects me to do in this situation?
+"""]]
diff --git a/doc/install/OSX.mdwn b/doc/install/OSX.mdwn
new file mode 100644
index 0000000000..eba4050544
--- /dev/null
+++ b/doc/install/OSX.mdwn
@@ -0,0 +1,42 @@
+## git-annex.app
+
+[[!img /assistant/osx-app.png align=right link=/assistant]]
+For easy installation, use the prebuilt app bundle.
+
+* 10.15 Catalina: [git-annex.dmg](https://downloads.kitenet.net/git-annex/OSX/current/10.15_Catalina/git-annex.dmg)
+
+To run the [[git-annex_assistant|/assistant]], just
+install the app, look for the icon, and start it up. 
+
+To use git-annex at the command line, you can add
+`git-annex.app/Contents/MacOS` to your `PATH`
+
+Alternatively, from the command line you can run
+`git-annex.app/Contents/MacOS/runshell`, which makes your shell use all the
+programs bundled inside the app, including not just git-annex, but git, and
+several more. Handy if you don't otherwise have git installed.
+
+## autobuilds
+
+An autobuild is also available, thanks to the Datalad project.
+
+* [git-annex.dmg](https://downloads.kitenet.net/git-annex/autobuild/x86_64-apple-catalina/git-annex.dmg)
+  ([build logs](https://github.com/datalad/git-annex/actions/workflows/build-macos.yaml?query=Build+git-annex+on+macOS))
+
+## download security
+
+All the download links above use https for security. For added security, see
+[[verifying_downloads]].
+
+## using Homebrew
+
+git-annex is [[available in Homebrew|Homebrew]].
+
+## using MacPorts
+
+git-annex is not available in MacPorts, but can be built from source using
+MacPorts tools. See [[MacPorts]].
+
+## building it yourself
+
+See [[porting]].
diff --git a/doc/install/OSX/Homebrew.mdwn b/doc/install/OSX/Homebrew.mdwn
new file mode 100644
index 0000000000..7a2e9634ad
--- /dev/null
+++ b/doc/install/OSX/Homebrew.mdwn
@@ -0,0 +1,25 @@
+[Homebrew](http://brew.sh/) has [a formula](https://formulae.brew.sh/formula/git-annex) for git-annex.
+
+Warning: Homebew enables telemetry by default, which is not a good practice.
+If you are surprised by it doing this, see [here](https://docs.brew.sh/Analytics)
+and you may want to run `brew analytics off`.
+
+Homebrew users can simply run `brew install git-annex` to install git-annex.
+
+## buiding git-annex from sources
+
+This is the old recipe for building git-annex from source, using
+packages from homebrew. Useful if you want a newer version than the version
+in homebrew.
+
+<pre>
+brew install haskell-platform git ossp-uuid md5sha1sum coreutils gnutls libidn gsasl pkg-config libxml2
+brew link libxml2 --force
+cabal update
+mkdir $HOME/bin
+PATH=$HOME/bin:$PATH
+PATH=$HOME/.cabal/bin:$PATH
+cabal install c2hs --bindir=$HOME/bin
+cabal install gnuidn
+cabal install git-annex --bindir=$HOME/bin
+</pre>
diff --git a/doc/install/OSX/Homebrew/comment_1_61cad5a309c3c4e3f278dec1890c9f40._comment b/doc/install/OSX/Homebrew/comment_1_61cad5a309c3c4e3f278dec1890c9f40._comment
new file mode 100644
index 0000000000..75217e851c
--- /dev/null
+++ b/doc/install/OSX/Homebrew/comment_1_61cad5a309c3c4e3f278dec1890c9f40._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="IgorGanapolsky"
+ avatar="http://cdn.libravatar.org/avatar/6bc0985e3dedceb150f08ad6456c84b2"
+ subject="Cannot install c2hs"
+ date="2016-10-24T18:05:51Z"
+ content="""
+When I run the following command: **cabal install c2hs --bindir=$HOME/bin**
+
+I get the following error:
+
+Error: some packages failed to install: c2hs-0.28.1 depends on language-c-0.5.0 which failed to install. language-c-0.5.0 failed during the configure step. The exception was: ExitFailure 1
+"""]]
diff --git a/doc/install/OSX/Homebrew/comment_2_2f89cfbc42590885fb7e92a89d0f7895._comment b/doc/install/OSX/Homebrew/comment_2_2f89cfbc42590885fb7e92a89d0f7895._comment
new file mode 100644
index 0000000000..4b3845f64a
--- /dev/null
+++ b/doc/install/OSX/Homebrew/comment_2_2f89cfbc42590885fb7e92a89d0f7895._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="Man pages not included when installing via homebrew"
+ date="2022-07-11T17:30:42Z"
+ content="""
+It seems that for me at least, OSX installations performed with `brew install git-annex` do not include man pages, e.g., if I subsequently run `man git-annex` I get the error `No manual entry for git-annex`. This isn't an enormous bother as I can instead browse documentation as needed on the website, but it's a headache when I'm working offline and even when not it can be irksome to have to leave the terminal.
+
+Below I've pasted the [relevant lines](https://github.com/Homebrew/homebrew-core/blob/0362892918d8e1c8d0b38c962e26a872e8612e71/Formula/git-annex.rb#L22-L27) that govern how homebrew performs the installation (or in practice, how the \"bottle\" is built as part of a CI process, and which bottle is typically \"poured\" by end users rather than compiling locally). 
+
+```
+  def install
+    system \"cabal\", \"v2-update\"
+    system \"cabal\", \"v2-install\", *std_cabal_v2_args,
+                    \"--flags=+S3\"
+    bin.install_symlink \"git-annex\" => \"git-annex-shell\"
+  end
+```
+
+Notably, it uses `cabal` to do the installation, but it doesn't quite follow any of the cabal-related patterns currently outlined on the [\"installing from source\" documentation](https://git-annex.branchable.com/install/fromsource/). I inspected the bottle that homebrew downloads, and indeed it contains just a handful of files that do not include the man pages, i.e.:
+
+```
+.
+├── CHANGELOG
+├── COPYRIGHT
+├── NEWS
+├── README
+├── bin
+│   ├── git-annex
+│   └── git-annex-shell -> git-annex
+├── homebrew.git-annex.service
+└── homebrew.mxcl.git-annex.plist
+
+1 directory, 8 files
+```
+
+Is there an easy tweak to the cabal-based installation that homebrew currently uses to do its bottling that would include man pages, or would it be a potentially significant undertaking that would require an appreciably different build approach?
+"""]]
diff --git a/doc/install/OSX/MacPorts.mdwn b/doc/install/OSX/MacPorts.mdwn
new file mode 100644
index 0000000000..dd6db8b0eb
--- /dev/null
+++ b/doc/install/OSX/MacPorts.mdwn
@@ -0,0 +1,27 @@
+This is not a recommended way to install git-annex. Use [[HomeBrew]] or the
+prebuilt app bundle instead.
+
+But if you really want to use MacPorts:
+
+Install the Haskell Platform from [[http://hackage.haskell.org/platform/mac.html]].
+The version provided by Macports is too old to work with current versions of git-annex.
+Then execute
+
+<pre>
+sudo port install git ossp-uuid md5sha1sum coreutils gnutls libxml2 libgsasl pkgconfig
+sudo cabal update
+PATH=$HOME/bin:$PATH
+cabal install c2hs git-annex --bindir=$HOME/bin
+</pre>
+
+## PATH setup
+
+Do not forget to add to your PATH variable your ~/bin folder. In your .bashrc, for example:
+<pre>
+PATH=$HOME/bin:$PATH
+</pre>
+
+See also:
+
+* [[forum/OSX__39__s_haskell-platform_statically_links_things]]
+* [[forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set]]
diff --git a/doc/install/OSX/MacPorts/comment_21_987f1302f56107c926b6daf83e124654._comment b/doc/install/OSX/MacPorts/comment_21_987f1302f56107c926b6daf83e124654._comment
new file mode 100644
index 0000000000..e7d42b5344
--- /dev/null
+++ b/doc/install/OSX/MacPorts/comment_21_987f1302f56107c926b6daf83e124654._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmJdzisfT6DhorwRz0kKJ_9-zQbccCopu4"
+ nickname="Alejandro"
+ subject="Macports _iconv"
+ date="2013-07-18T14:23:02Z"
+ content="""
+If you get an error like `undefined symbol _iconv for x86_64`, you're most likely using libiconv installed by macports. You can fix this by running
+
+    cabal install c2hs git-annex --bindir=$HOME/bin --extra-lib-dirs=/usr/lib
+
+"""]]
diff --git a/doc/install/OSX/MacPorts/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment b/doc/install/OSX/MacPorts/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment
new file mode 100644
index 0000000000..69f3f0feed
--- /dev/null
+++ b/doc/install/OSX/MacPorts/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlDDW-g2WLLsLpcnCm4LykAquFY_nwbIrU"
+ nickname="Daniel"
+ subject="comment 3"
+ date="2013-01-15T15:22:43Z"
+ content="""
+Installing via the MacPorts method. I ran into this error.
+
+    \"_locale_charset\", referenced from: _localeEncoding in libHSbase-4.5.1.0.a(PrelIOUtils.o) 
+    ld: symbol(s) not found for architecture x86_64
+
+I was able to solve and get git-annex to build buy providing the --extra-lib-dirs parameter
+
+    cabal install c2hs git-annex --bindir=$HOME/bin --extra-lib-dirs=/usr/lib
+
+Cheers, [Daniel Wozniak](http://woz.io)
+"""]]
diff --git a/doc/install/OSX/comment_10_e5172de344908f85ce6cf976e3c3806b._comment b/doc/install/OSX/comment_10_e5172de344908f85ce6cf976e3c3806b._comment
new file mode 100644
index 0000000000..99669d22ed
--- /dev/null
+++ b/doc/install/OSX/comment_10_e5172de344908f85ce6cf976e3c3806b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk7iPiqWr3BVPLWEDvJhSSvcOqheLEbLNo"
+ nickname="Dirk"
+ subject="Is the Mavericks build still beeing updated?"
+ date="2015-02-26T12:22:51Z"
+ content="""
+I am still using Mac OS 10.9. Recently downloading a new git-annex version showed that the Mavericks build is still based on 5.20141104, while the Yosemite is 5.20150219. I am wondering if this is a misstake or if it is time for me to move on to Yosemite? ;-)
+
+
+"""]]
diff --git a/doc/install/OSX/comment_11_8d53c477b441ab0984257b21003c7cc7._comment b/doc/install/OSX/comment_11_8d53c477b441ab0984257b21003c7cc7._comment
new file mode 100644
index 0000000000..1045a44b61
--- /dev/null
+++ b/doc/install/OSX/comment_11_8d53c477b441ab0984257b21003c7cc7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Is the Mavericks build still beeing updated?"""
+ date="2015-02-27T18:57:51Z"
+ content="""
+The Yosemite build linked above has been reported to work on Mavericks too,
+and is being updated. There is no separate Mavericks build anymore.
+
+There were some old mavericks builds floating around the downloads site; 
+I've removed those and symlinked the mavericks directory to the yosimite
+directory.
+"""]]
diff --git a/doc/install/OSX/comment_12_17b84f51de6bed88e373350b194c8a8d._comment b/doc/install/OSX/comment_12_17b84f51de6bed88e373350b194c8a8d._comment
new file mode 100644
index 0000000000..8f937d1b8f
--- /dev/null
+++ b/doc/install/OSX/comment_12_17b84f51de6bed88e373350b194c8a8d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew.grangaard@bf525d11f8ebfbfb0976f7df2301aa0f36668f59"
+ nickname="andrew.grangaard"
+ subject="10.10 build works on El Capitan (10.11)"
+ date="2016-02-02T01:30:45Z"
+ content="""
+The OSX 10.10 build works fine on my 10.11 El Capitan machine.   Updated this page to reflect that.
+
+git-annex is also in 'brew cask', automating installation from the OSX binaries.   I've sent  [PR 18105](https://github.com/caskroom/homebrew-cask/pull/18105) to the brew cask team to get the cask to work for 10.11.
+"""]]
diff --git a/doc/install/OSX/comment_13_f4b39e2009274539d60b29711a4a2c8d._comment b/doc/install/OSX/comment_13_f4b39e2009274539d60b29711a4a2c8d._comment
new file mode 100644
index 0000000000..960591bc4a
--- /dev/null
+++ b/doc/install/OSX/comment_13_f4b39e2009274539d60b29711a4a2c8d._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="lhunath@3b4ff15f4600f3276d1776a490b734fca0f5c245"
+ nickname="lhunath"
+ subject="The application cannot be opened because its executable is missing."
+ date="2016-05-05T04:33:06Z"
+ content="""
+Just downloaded the DMG, copied the .app into /Applications and ran it; does nothing, from terminal:
+
+$ open -W /Applications/git-annex.app
+The application cannot be opened because its executable is missing.
+
+$ /Applications/git-annex.app/Contents/MacOS/git-annex-webapp
+$
+unable to start webapp in repository /Users/lhunath/annex: Not in a git repository.
+Launching web browser on file:///var/folders/np/v9byg9092bbf31jw5cydzszm0000gn/T/webapp1622650073984943658.html
+
+$ /Applications/git-annex.app/Contents/MacOS/git-annex version
+git-annex version: 6.20160427-gd0036b9
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+"""]]
diff --git a/doc/install/OSX/comment_14_5581b7d1c09e6a78419d626bb25261b6._comment b/doc/install/OSX/comment_14_5581b7d1c09e6a78419d626bb25261b6._comment
new file mode 100644
index 0000000000..f42d308f1b
--- /dev/null
+++ b/doc/install/OSX/comment_14_5581b7d1c09e6a78419d626bb25261b6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2016-05-10T17:22:03Z"
+ content="""
+I don't know what needs to be put where in the app to make `open`
+run git-annex-webapp. There is already a Info.plist file that I thought was
+supposed to handle that. If someone wants to help make `open` work please
+be my guest.
+"""]]
diff --git a/doc/install/OSX/comment_15_dda16b58686b0e5d061521f8e1831f89._comment b/doc/install/OSX/comment_15_dda16b58686b0e5d061521f8e1831f89._comment
new file mode 100644
index 0000000000..55ce7543e2
--- /dev/null
+++ b/doc/install/OSX/comment_15_dda16b58686b0e5d061521f8e1831f89._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="drunken_sapo"
+ avatar="http://cdn.libravatar.org/avatar/95a4912e969b86df221626188ecc8f94"
+ subject="It is better to provide osx dmgs"
+ date="2018-03-05T11:48:11Z"
+ content="""
+I've just installed git-annex in OSX High Sierra, and it pulls a LOT of dependencies, many of them already installed. For instance, yet another python distro. It is kind of overkill just to install annex.
+
+"""]]
diff --git a/doc/install/OSX/comment_16_277249620801bd4305776a3d598bd074._comment b/doc/install/OSX/comment_16_277249620801bd4305776a3d598bd074._comment
new file mode 100644
index 0000000000..daeda7175f
--- /dev/null
+++ b/doc/install/OSX/comment_16_277249620801bd4305776a3d598bd074._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="achilleas.k@14be77d42a1252fab5ec9dbf4e5ea03c5833e8c8"
+ nickname="achilleas.k"
+ avatar="http://cdn.libravatar.org/avatar/ed6c67c4d8e6c6850930e16eaf85a771"
+ subject="dmg (possibly) requires rebuild"
+ date="2018-03-29T15:31:23Z"
+ content="""
+On macOS High Sierra (10.13.3) trying to use git-annex from the latest .dmg shows the following error:
+
+    > git annex version
+    dyld: Symbol not found: _inflateValidate
+      Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
+      Expected in: /Applications/git-annex.app/Contents/MacOS/bundle/B
+     in /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
+    error: git-annex died of signal 6
+
+I ran it by opening the .app directory (Show Package Contents) and running the `runshell` script to set up the environment:
+
+    > which git
+    /Applications/git-annex.app/Contents/MacOS/bundle/git
+    > which git-annex
+    /Applications/git-annex.app/Contents/MacOS/bundle/git-annex
+
+"""]]
diff --git a/doc/install/OSX/comment_17_06e8fc7a4670a42c249f90a3602c3523._comment b/doc/install/OSX/comment_17_06e8fc7a4670a42c249f90a3602c3523._comment
new file mode 100644
index 0000000000..e4f3b15942
--- /dev/null
+++ b/doc/install/OSX/comment_17_06e8fc7a4670a42c249f90a3602c3523._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: dmg (possibly) requires rebuild"""
+ date="2018-04-04T15:56:38Z"
+ content="""
+@achilleas.k, that was [this bug](https://git-annex.branchable.com/Error_running_git-annex.app_on_OS_X_10.13.1___40__17B1003__41__/) which should be fixed
+now.
+
+Please file bug reports for issues with the OSX build, don't report them
+here.
+"""]]
diff --git a/doc/install/OSX/comment_18_5eca3153048d2b3b4fa707d6b8a5ebeb._comment b/doc/install/OSX/comment_18_5eca3153048d2b3b4fa707d6b8a5ebeb._comment
new file mode 100644
index 0000000000..31d4757780
--- /dev/null
+++ b/doc/install/OSX/comment_18_5eca3153048d2b3b4fa707d6b8a5ebeb._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="achilleas.k@14be77d42a1252fab5ec9dbf4e5ea03c5833e8c8"
+ nickname="achilleas.k"
+ avatar="http://cdn.libravatar.org/avatar/ed6c67c4d8e6c6850930e16eaf85a771"
+ subject="comment 18"
+ date="2018-04-04T16:27:54Z"
+ content="""
+Right. Should have searched the bug reports. Thanks and sorry for the noise.
+"""]]
diff --git a/doc/install/OSX/comment_19_040d388c94ee0e537990f0cd782d8554._comment b/doc/install/OSX/comment_19_040d388c94ee0e537990f0cd782d8554._comment
new file mode 100644
index 0000000000..3525b1ff90
--- /dev/null
+++ b/doc/install/OSX/comment_19_040d388c94ee0e537990f0cd782d8554._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="git-annex not a cask anymore"
+ date="2018-04-20T13:21:27Z"
+ content="""
+@andrew.grangaard, I just wanted to note that git-annex is [no longer available as a cask](https://github.com/caskroom/homebrew-cask/pull/22706). It is just available as a [formula](http://formulae.brew.sh/formula/git-annex), ie `brew install git-annex` see [Homebrew](http://git-annex.branchable.com/install/OSX/Homebrew/).
+"""]]
diff --git a/doc/install/OSX/comment_20_3e6a3c00444badf2cf7a9ee3d54af11e._comment b/doc/install/OSX/comment_20_3e6a3c00444badf2cf7a9ee3d54af11e._comment
new file mode 100644
index 0000000000..ef273bf7be
--- /dev/null
+++ b/doc/install/OSX/comment_20_3e6a3c00444badf2cf7a9ee3d54af11e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnEgT3Gxm4AAK4zu3ft5-PsUmY6dr1F-gE"
+ nickname="David"
+ subject="OSX app bundle"
+ date="2013-06-05T17:35:49Z"
+ content="""
+I'm using the annex assistant from the annex bundle for the convenience, but sometimes I use git-annex directly from the command line. I have /Applications/git-annex.app/Contents/MacOS/ in my path, but is there any way you could build the app bundle with the manpage in there so I could add it to my MANPATH?  
+"""]]
diff --git a/doc/install/OSX/comment_21_951e6bb1f70d8f02374e9e3fb91dc182._comment b/doc/install/OSX/comment_21_951e6bb1f70d8f02374e9e3fb91dc182._comment
new file mode 100644
index 0000000000..879a8d0605
--- /dev/null
+++ b/doc/install/OSX/comment_21_951e6bb1f70d8f02374e9e3fb91dc182._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lhunath@3b4ff15f4600f3276d1776a490b734fca0f5c245"
+ nickname="lhunath"
+ avatar="http://cdn.libravatar.org/avatar/6388e539b56b3875cc9aceb9f404b3ad"
+ subject="comment 21"
+ date="2018-04-29T18:37:16Z"
+ content="""
+I don't get this, but I should note uname on macOS doesn't have -o, this should probably be changed to -s
+"""]]
diff --git a/doc/install/OSX/comment_22_6ae394921280d3cd4907f210b9845a2f._comment b/doc/install/OSX/comment_22_6ae394921280d3cd4907f210b9845a2f._comment
new file mode 100644
index 0000000000..ffe16b5921
--- /dev/null
+++ b/doc/install/OSX/comment_22_6ae394921280d3cd4907f210b9845a2f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="allforabit"
+ avatar="http://cdn.libravatar.org/avatar/32e0c529af793688f16aa23cb462d9da"
+ subject="Apologies"
+ date="2018-05-19T23:48:05Z"
+ content="""
+My apologies. I will do that in future. I've removed my comments.Hopefully that doesn't cause more confusion. It's working great now. Thanks for the amazing software!
+"""]]
diff --git a/doc/install/OSX/comment_23_895d4e837d05a318512730d66f14db22._comment b/doc/install/OSX/comment_23_895d4e837d05a318512730d66f14db22._comment
new file mode 100644
index 0000000000..d32a50bde3
--- /dev/null
+++ b/doc/install/OSX/comment_23_895d4e837d05a318512730d66f14db22._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2018-05-08T18:03:05Z"
+ content="""
+Guys talking about uname -o and stuff, this is not the place to do that.
+File a [[bug]] report if you have a bug like that. You're making it harder
+for every person who opens this page to install git-annex and ends up
+wwading through discussion of fixed bugs like that one. Also, I respond
+*much* faster to bug reports than to random misplaced comments about bugs.
+"""]]
diff --git a/doc/install/OSX/comment_23_af10ed56c037499d002fcf0114b9426a._comment b/doc/install/OSX/comment_23_af10ed56c037499d002fcf0114b9426a._comment
new file mode 100644
index 0000000000..3c6d1ac3c7
--- /dev/null
+++ b/doc/install/OSX/comment_23_af10ed56c037499d002fcf0114b9426a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2022-07-12T19:12:24Z"
+ content="""
+@Dan I would not be surprised if cabal v2-install 
+does not support installing man pages like the old
+v1-install does. When I tried it, it seemed not to.
+
+The Makefile has an `install-mans` target
+that could be used instead. There are several other things
+that `make install` does that cabal cannot, including installing
+completions files, so system integrators (like homebrew) 
+should probably use it when they can.
+"""]]
diff --git a/doc/install/OSX/comment_25_db90984062a07576a4777b2d743161f1._comment b/doc/install/OSX/comment_25_db90984062a07576a4777b2d743161f1._comment
new file mode 100644
index 0000000000..2a924e8f90
--- /dev/null
+++ b/doc/install/OSX/comment_25_db90984062a07576a4777b2d743161f1._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnyMzZZLS1xGW1raqc_9Md6Ksdkvx5rUJU"
+ nickname="Michael"
+ subject="confusion with bundled programs"
+ date="2013-10-02T21:39:11Z"
+ content="""
+I have fiddled with the fresh (as of Oct 2nd) build of assistant on OS X 10.8.5, and there has been a lot of problems with bundled software
+
+bundled git is an old 1.7.x version which keeps saying in the daemon logs it is too old to honor .gitignores etc
+at the same time I have git 1.8.4 installed through homebrew which works very nicely throughout my system
+
+I also have homebrew-installed gpg2:
+
+$ gpg2 --version
+gpg (GnuPG) 2.0.21
+libgcrypt 1.5.3
+
+(and have briefly experimented with using GPGSuite from gpgtools.org, which kept bailing with invalid autolocate directive in gpg.conf)
+
+however there is some unidentifiable gpg binary bundled with the assistant, which cannot connect to gpg-agent from gpg2, and doesn't work with GPGSuite (see above)
+
+is there a way to completely forgo usage of bundled software and have the webapp use whatever is already available on the system?
+
+"""]]
diff --git a/doc/install/OSX/comment_2_25552ff2942048fafe97d653757f1ad6._comment b/doc/install/OSX/comment_2_25552ff2942048fafe97d653757f1ad6._comment
new file mode 100644
index 0000000000..8d7010a1b9
--- /dev/null
+++ b/doc/install/OSX/comment_2_25552ff2942048fafe97d653757f1ad6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 2"
+ date="2012-07-24T15:09:29Z"
+ content="""
+I've moved some outdated comments about installing on OSX to [[old_comments]].
+And also moved away some comments that helped build the instructions above.
+"""]]
diff --git a/doc/install/OSX/comment_4_25cac8bcd84a5210fc0a5243260b8cc7._comment b/doc/install/OSX/comment_4_25cac8bcd84a5210fc0a5243260b8cc7._comment
new file mode 100644
index 0000000000..703f502f72
--- /dev/null
+++ b/doc/install/OSX/comment_4_25cac8bcd84a5210fc0a5243260b8cc7._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaYy6kTuKAHmsa4BtGls2oqa42Jo2w2v0"
+ nickname="Pere"
+ subject="Snow Leopard"
+ date="2013-01-18T15:51:48Z"
+ content="""
+Hi,
+
+Are there plans to provide a git-annex.app that works on Snow Leopard? 
+
+Currently there are only installers for the Lions.
+
+http://downloads.kitenet.net/git-annex/OSX/current/
+
+Thanks :-)
+
+
+"""]]
diff --git a/doc/install/OSX/comment_5_39b4b748b4586bf32b37edfefef84bba._comment b/doc/install/OSX/comment_5_39b4b748b4586bf32b37edfefef84bba._comment
new file mode 100644
index 0000000000..c188d81250
--- /dev/null
+++ b/doc/install/OSX/comment_5_39b4b748b4586bf32b37edfefef84bba._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.194"
+ subject="comment 5"
+ date="2013-01-18T17:25:36Z"
+ content="""
+What we need to provide a Snow Leopard or other version build, is access to a box running that version of OSX, or someone with a box that doesn't mind compiling stuff and setting up the autobuilder (not very hard).
+"""]]
diff --git a/doc/install/OSX/comment_6_1a9c91ef43edc4148947f202ff604114._comment b/doc/install/OSX/comment_6_1a9c91ef43edc4148947f202ff604114._comment
new file mode 100644
index 0000000000..a16e4cad00
--- /dev/null
+++ b/doc/install/OSX/comment_6_1a9c91ef43edc4148947f202ff604114._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaYy6kTuKAHmsa4BtGls2oqa42Jo2w2v0"
+ nickname="Pere"
+ subject="Snow Leopard"
+ date="2013-01-18T17:57:40Z"
+ content="""
+If the process is very automatic I might contribute. I mean, if you tell me, install this and that package and run this script once a week, I might be able to help. I have a MacBook from 2007 with Snow Leopard. I also have macports installed, but I'm not a programmer.
+"""]]
diff --git a/doc/install/OSX/comment_7_892f7e65f95f43697164267c4b71c0d5._comment b/doc/install/OSX/comment_7_892f7e65f95f43697164267c4b71c0d5._comment
new file mode 100644
index 0000000000..3c7e2b8b6c
--- /dev/null
+++ b/doc/install/OSX/comment_7_892f7e65f95f43697164267c4b71c0d5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.194"
+ subject="comment 7"
+ date="2013-01-18T20:16:52Z"
+ content="""
+If you can get it to build using the instructions for Brew (or MacPorts) on this page, it's easy to get from there to a distributable app.
+"""]]
diff --git a/doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment b/doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment
new file mode 100644
index 0000000000..902d87dd7c
--- /dev/null
+++ b/doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 8"
+ date="2014-08-15T19:26:07Z"
+ content="""
+@David, the bundle contains the man page since a while.
+
+@Michael, the best way to get a git-annex that does not use those bundled programs is probably to instead install it using homebrew.
+"""]]
diff --git a/doc/install/OSX/comment_9_f11f726d1fee3c4c91f3c984e792037d._comment b/doc/install/OSX/comment_9_f11f726d1fee3c4c91f3c984e792037d._comment
new file mode 100644
index 0000000000..afc7268e1c
--- /dev/null
+++ b/doc/install/OSX/comment_9_f11f726d1fee3c4c91f3c984e792037d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
+ nickname="Matthias"
+ subject="Why different versions?"
+ date="2014-09-23T10:59:32Z"
+ content="""
+Why are there different versions for 10.7, 10.8, 10.9 anyway? Is it not possible to produce an executable compatible with all these? I mean, it's the same architecture and executable format, not? I guess there has to be a reason, explanations are welcome :-)
+"""]]
diff --git a/doc/install/OSX/old_comments.mdwn b/doc/install/OSX/old_comments.mdwn
new file mode 100644
index 0000000000..ccb6785fd7
--- /dev/null
+++ b/doc/install/OSX/old_comments.mdwn
@@ -0,0 +1 @@
+Moved a bunch of outdated comments here, AFAIK all these issues are fixed.
diff --git a/doc/install/OSX/old_comments/comment_10_4d15bfc4fc26e7249953bebfbb09e0aa._comment b/doc/install/OSX/old_comments/comment_10_4d15bfc4fc26e7249953bebfbb09e0aa._comment
new file mode 100644
index 0000000000..d655da7256
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_10_4d15bfc4fc26e7249953bebfbb09e0aa._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkp-1EQboBDqZ05MxOHNkwNQDM4luWYioA"
+ nickname="Charles"
+ subject="comment 10"
+ date="2012-11-15T13:26:57Z"
+ content="""
+Installing it with brew, I had to do the following steps before the final `cabal` command:
+
+* `cabal install c2hs`
+* add `$HOME/.cabal/bin` to my `$PATH` (so that c2hs program can be found)
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_10_798000aab19af2944b6e44dbc550c6fe._comment b/doc/install/OSX/old_comments/comment_10_798000aab19af2944b6e44dbc550c6fe._comment
new file mode 100644
index 0000000000..675a90eee8
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_10_798000aab19af2944b6e44dbc550c6fe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.25"
+ subject="comment 10"
+ date="2012-06-25T15:38:44Z"
+ content="""
+@Agustin you should be able to work around that with: cabal install git-annex --flags=-Inotify
+
+I've fixed it properly for the next release, it should only be using that library on Linux.
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_11_707a1a27a15b2de8dfc8d1a30420ab4c._comment b/doc/install/OSX/old_comments/comment_11_707a1a27a15b2de8dfc8d1a30420ab4c._comment
new file mode 100644
index 0000000000..69a4f9128d
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_11_707a1a27a15b2de8dfc8d1a30420ab4c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkwR9uOA38yi5kEUvcEWNtRiZwpxXskayE"
+ nickname="Agustin"
+ subject="comment 11"
+ date="2012-06-27T08:54:52Z"
+ content="""
+Hi @joey! Perfect!... I'll do that then!
+
+Thanks for your time man!
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_12_60d13f2c8e008af1041bea565a392c83._comment b/doc/install/OSX/old_comments/comment_12_60d13f2c8e008af1041bea565a392c83._comment
new file mode 100644
index 0000000000..e2e85aaa94
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_12_60d13f2c8e008af1041bea565a392c83._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnHrjHxJAm39x8DR4bnbazQO6H0nMNuY9c"
+ nickname="Damien"
+ subject="sha256 alternative"
+ date="2012-06-30T14:34:11Z"
+ content="""
+in reply to comment 6: On my Mac (10.7.4) there's `/usr/bin/shasum -a 256 <file>` command that will produce the same output as `sha256sum <file>`.
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_13_a6f48c87c2d6eabe379d6e10a6cac453._comment b/doc/install/OSX/old_comments/comment_13_a6f48c87c2d6eabe379d6e10a6cac453._comment
new file mode 100644
index 0000000000..e5ce62b138
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_13_a6f48c87c2d6eabe379d6e10a6cac453._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnHrjHxJAm39x8DR4bnbazQO6H0nMNuY9c"
+ nickname="Damien"
+ subject="gnu commands"
+ date="2012-07-01T17:03:57Z"
+ content="""
+…and another approach to the same problem: apparently git-annex also relies on the GNU coreutils (for instance, when doing `git annex get .`, `cp` complains about `illegal option -- -`). I do have the GNU coreutils installed with Homebrew, but they are all prefixed with `g`. So maybe you should try `gsha256sum` and `gcp` before `sha256sum` and `cp`, that seems like a more general solution.
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_14_6ef2ddb7b11ce6ad54578ae118ed346e._comment b/doc/install/OSX/old_comments/comment_14_6ef2ddb7b11ce6ad54578ae118ed346e._comment
new file mode 100644
index 0000000000..35e0bb6ed5
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_14_6ef2ddb7b11ce6ad54578ae118ed346e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 14"
+ date="2012-07-04T12:43:54Z"
+ content="""
+@Damien, hmm, it should not be using any cp options, unless when it was built there was a cp in the path that supported some option like -p. Can you check with --debug what cp parameters it's trying to use?
+
+
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_15_6fd1fad5b6d9f36620e5a0e99edd2f89._comment b/doc/install/OSX/old_comments/comment_15_6fd1fad5b6d9f36620e5a0e99edd2f89._comment
new file mode 100644
index 0000000000..0005328c48
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_15_6fd1fad5b6d9f36620e5a0e99edd2f89._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 15"
+ date="2012-07-04T13:14:00Z"
+ content="""
+git-annex will now fall back to slower pure Haskell hashing code if `sha256sum`, etc programs are not in PATH. I'd still recommend installing the coreutils, as they're probably faster.
+
+(The `shasum` command seems to come from a perl library, so I have not tried to make git-annex use that one.)
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_16_af6fe3540032cdf4400478de87771058._comment b/doc/install/OSX/old_comments/comment_16_af6fe3540032cdf4400478de87771058._comment
new file mode 100644
index 0000000000..5da4b22c63
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_16_af6fe3540032cdf4400478de87771058._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://a-or-b.myopenid.com/"
+ ip="203.45.2.230"
+ subject="Compiling git-annex on OSX (with 32 bit Haskell)"
+ date="2012-07-24T03:26:45Z"
+ content="""
+I came across an issue when following the instructions here:
+     <http://git-annex.branchable.com/install/OSX/>
+
+I'm compiling the 'assistant' branch (522f568450a005ae81b24f63bb37e75320b51219).
+
+
+The pre-compiled version of Haskell for OSX recommends the 32 bit installer, however git-annex compiles
+
+>  Utility/libdiskfree.o Utility/libkqueue.o Utility/libmounts.o
+
+as 64 bit. The 'make' command fails on linking 32- and 64-bit code.
+
+So... I made a small change to the Makefile
+
+>  CFLAGS=-Wall
+
+becomes
+
+>  CFLAGS=-Wall -m32
+
+I don't know if there is an easy way to programmatically check for this, or even if you'd want to spend time doing it, but it might help someone else out.
+
+<https://gist.github.com/3167798>
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_17_8d3a0596db67108041728b20f2790f31._comment b/doc/install/OSX/old_comments/comment_17_8d3a0596db67108041728b20f2790f31._comment
new file mode 100644
index 0000000000..782f2fd759
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_17_8d3a0596db67108041728b20f2790f31._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 17"
+ date="2012-07-24T15:03:49Z"
+ content="""
+The instructions say to use cabal for a reason -- it's more likely to work. But I have made the Makefile detect the mismatched GHC and C compiler and force the C compiler to 32 bit.
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_1_0a1760bf0db1f1ba89bdb4c62032f631._comment b/doc/install/OSX/old_comments/comment_1_0a1760bf0db1f1ba89bdb4c62032f631._comment
new file mode 100644
index 0000000000..1148a87cab
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_1_0a1760bf0db1f1ba89bdb4c62032f631._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://www.schleptet.net/~cfm/"
+ ip="64.30.148.100"
+ subject="comment 1"
+ date="2011-08-30T14:31:36Z"
+ content="""
+You can also use Homebrew instead of MacPorts.  Homebrew's `haskell-platform` is up-to-date, too:
+
+    brew install haskell-platform git ossp-uuid md5sha1sum coreutils pcre
+    ln -s /usr/local/include/pcre.h /usr/include/pcre.h
+
+As of this writing, however, Homebrew's `md5sha1sum` has a broken mirror.  I wound up getting that from MacPorts anyway.
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_2_0327c64b15249596add635d26f4ce67f._comment b/doc/install/OSX/old_comments/comment_2_0327c64b15249596add635d26f4ce67f._comment
new file mode 100644
index 0000000000..5768d8b932
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_2_0327c64b15249596add635d26f4ce67f._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkEUhIcw37X2Kh-dznSMIb9Vgcq0frfdWs"
+ nickname="Ethan"
+ subject="GHC 7"
+ date="2012-03-28T19:06:51Z"
+ content="""
+The Haskell Platform installer for OSX uses GHC 7.0.4, which doesn't seem able to support the current version of git-annex.
+
+Cabal throws a very cryptic error about not being able to use the proper base package.
+
+I was able to install it by 
+
+1.  cloning the repo
+2.  merging the ghc7.0 branch
+3.  resolving merge conflicts in git-annex.cabal
+4.  cabal install git-annex.cabal
+
+(Note I also tried this with homebrew and had similar results)
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_2_7683740a98182de06cb329792e0c0a25._comment b/doc/install/OSX/old_comments/comment_2_7683740a98182de06cb329792e0c0a25._comment
new file mode 100644
index 0000000000..113ef687a0
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_2_7683740a98182de06cb329792e0c0a25._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmYiJgOvC4IDYkr2KIjMlfVD9r_1Sij_jY"
+ nickname="Douglas"
+ subject="setup: standalone/macos/git-annex.app/Contents/Info.plist: does not exist"
+ date="2012-10-06T14:46:55Z"
+ content="""
+I tried installing with cabal and homebrew on Mountain Lion. After cabal install git-annex I get:
+
+    Linking dist/build/git-annex/git-annex ...
+    Installing executable(s) in /Users/dfc/.cabal/bin
+    setup: standalone/macos/git-annex.app/Contents/Info.plist: does not exist
+    cabal: Error: some packages failed to install:
+    git-annex-3.20121001 failed during the final install step. The exception was:
+    ExitFailure 1
+
+
+There is no directory named macos inside of standalone:
+
+    jumbo:git-annex-3.20121001 dfc$ ls -l standalone/
+    total 112
+    -rw-r--r--+ 1 dfc  staff  55614 Oct  6 10:40 licences.gz
+    drwxr-xr-x+ 6 dfc  staff    204 Oct  6 10:40 linux
+    drwxr-xr-x+ 3 dfc  staff    102 Oct  6 10:40 osx
+
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_34_c9362141d15a2f68a75df9f8bfe29da0._comment b/doc/install/OSX/old_comments/comment_34_c9362141d15a2f68a75df9f8bfe29da0._comment
new file mode 100644
index 0000000000..65a7e0ea77
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_34_c9362141d15a2f68a75df9f8bfe29da0._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl-xMSPoRHcT5d2nAc1K8pWVi-AexKkYik"
+ nickname="Ralf"
+ subject="Mac OS X Maverick - symbol not found"
+ date="2013-10-27T21:02:45Z"
+ content="""
+Just to mention that the beta dated 24 Oct 2013 and Joey's autobuild of 27 Oct both don't start with the following error message for git-annex, git-annex-webapp under Mac OS X 10.9 Maverick with latest XCode installed: 
+
+    dyld: Symbol not found: _objc_debug_taggedpointer_mask
+      Referenced from: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
+      Expected in: /Applications/git-annex.app/Contents/MacOS/bundle/I
+     in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
+
+    Trace/BPT trap: 5
+
+Many thanks. Can I help?
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_35_8106196c3fef70652cb2106e2d5857db._comment b/doc/install/OSX/old_comments/comment_35_8106196c3fef70652cb2106e2d5857db._comment
new file mode 100644
index 0000000000..697dafa0b9
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_35_8106196c3fef70652cb2106e2d5857db._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 35"
+ date="2013-10-27T21:06:57Z"
+ content="""
+We do not yet have an autobuild for 10.9. You can build from source: <http://git-annex.branchable.com/bugs/git_annex_doesn__39__t_work_in_Max_OS_X_10.9/#comment-8e8ee5e50506a6fde029d236f4809df8>
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_3_47c682a779812dda77601c24a619923c._comment b/doc/install/OSX/old_comments/comment_3_47c682a779812dda77601c24a619923c._comment
new file mode 100644
index 0000000000..251375cbec
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_3_47c682a779812dda77601c24a619923c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="ghc 7.0"
+ date="2012-03-28T19:18:58Z"
+ content="""
+You did the right thing, although just checking out the ghc-7.0 branch will avoid merge conflicts. I am trying to keep it fairly close to up-to-date.
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_3_733147cebe501c60f2141b711f1d7f24._comment b/doc/install/OSX/old_comments/comment_3_733147cebe501c60f2141b711f1d7f24._comment
new file mode 100644
index 0000000000..51e667ab66
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_3_733147cebe501c60f2141b711f1d7f24._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnnIQkoUQo4RYzjUNyiB3v6yJ5aR41WG8k"
+ nickname="Markus"
+ subject="Updated install instructions with homebrew"
+ date="2012-08-07T06:46:47Z"
+ content="""
+To install git annex with homebrew simply do:
+
+    brew update
+    brew install haskell-platform git ossp-uuid md5sha1sum coreutils pcre
+    cabal install git-annex
+
+Then link the binary to your `PATH` e.g. with
+
+    ln -s ~/.cabal/bin/git-annex* /usr/local/bin/
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_3_b090f40fe5a32e00b472a5ab2b850b4a._comment b/doc/install/OSX/old_comments/comment_3_b090f40fe5a32e00b472a5ab2b850b4a._comment
new file mode 100644
index 0000000000..a437704a38
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_3_b090f40fe5a32e00b472a5ab2b850b4a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.149"
+ subject="comment 3"
+ date="2012-10-06T21:05:45Z"
+ content="""
+@Douglas, I've fixed that in git. FWIW, the program is installed before that point. Actually, I am leaning toward not having cabal install that plist file at all.
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_3_fc092412e99cf4c5f095b0ef710bc4de._comment b/doc/install/OSX/old_comments/comment_3_fc092412e99cf4c5f095b0ef710bc4de._comment
new file mode 100644
index 0000000000..47ad9feafc
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_3_fc092412e99cf4c5f095b0ef710bc4de._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 17"
+ date="2012-07-24T06:33:13Z"
+ content="""
+@a-or-b that issue is logged here [[bugs/subtle build issue on OSX 10.7 and Haskell Platform (if you have the 32bit version installed)]], you can use cabal to build and install git-annex and it will detect if its 32 or 64bit automatically.
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_4_d513e21512a9b207983d38abf348d00f._comment b/doc/install/OSX/old_comments/comment_4_d513e21512a9b207983d38abf348d00f._comment
new file mode 100644
index 0000000000..049f7e9624
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_4_d513e21512a9b207983d38abf348d00f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm_-2XlXNyd6cCLI4n_jaBNqVUOWwJquko"
+ nickname="David"
+ subject="installing via homebrew"
+ date="2012-09-05T11:11:55Z"
+ content="""
+I had to:
+
+    cabal update
+
+before:
+
+    cabal install git-annex
+
+
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_4_d68c36432c7be3f4a76f4f0d7300bac9._comment b/doc/install/OSX/old_comments/comment_4_d68c36432c7be3f4a76f4f0d7300bac9._comment
new file mode 100644
index 0000000000..b274707fb3
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_4_d68c36432c7be3f4a76f4f0d7300bac9._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmY_4MvT5yEeztrS7UIJseStUe4mtgp6YE"
+ nickname="Сергей"
+ subject="Have error"
+ date="2012-10-10T11:47:09Z"
+ content="""
+[ 98 of 248] Compiling Utility.DiskFree ( Utility/DiskFree.hs, dist/build/git-annex/git-annex-tmp/Utility/DiskFree.o )
+[ 99 of 248] Compiling Utility.Url      ( Utility/Url.hs, dist/build/git-annex/git-annex-tmp/Utility/Url.o )
+
+Utility/Url.hs:111:88:
+    Couldn't match expected type `Maybe URI' with actual type `URI'
+    In the second argument of `fromMaybe', namely
+      `(newURI `relativeTo` u)'
+    In the expression: fromMaybe newURI (newURI `relativeTo` u)
+    In an equation for `newURI_abs':
+        newURI_abs = fromMaybe newURI (newURI `relativeTo` u)
+cabal: Error: some packages failed to install:
+git-annex-3.20121009 failed during the building phase. The exception was:
+ExitFailure 1
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_4_e6109a964064a2a799768a370e57801d._comment b/doc/install/OSX/old_comments/comment_4_e6109a964064a2a799768a370e57801d._comment
new file mode 100644
index 0000000000..be3ba2be44
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_4_e6109a964064a2a799768a370e57801d._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkO9tsPZkAxEulq2pGCdwz4md-LqB0RcMw"
+ nickname="Reimund"
+ subject="Problems with Base & Crypto"
+ date="2012-04-25T22:56:18Z"
+ content="""
+I got the following error message trying to install git-annex:
+
+    cabal: cannot configure git-annex-3.20120418. It requires base >=4.5 && <5
+    For the dependency on base >=4.5 && <5 there are these packages: base-4.5.0.0.
+    However none of them are available.
+    base-4.5.0.0 was excluded because of the top level dependency base -any
+
+These are the steps I performed to make it work
+
+1. Download [Ghc 7.4](http://www.haskell.org/ghc/download).
+2. Run `sudo cabal install git-annex --bindir=$HOME/bin`.
+3. Compilation of the Crypto-4.2.4 dependency failed since it's not updated to work with Ghc 7.4. You need to patch SHA2.hs (steps below).
+4. Run `sudo cabal install git-annex --bindir=$HOME/bin` a second time.
+
+The steps I did to patch the SHA2.hs file in Crypto-4.2.4:
+
+1. `cabal unpack crypto-4.2.4`
+2. `cd Crypto-4.2.4`
+3. `patch -p1 < crypto-4.2.4-ghc-7.4.patch`
+4. `sudo cabal install`.
+
+PS: I used [this patchfile](http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-haskell/crypto/files/crypto-4.2.4-ghc-7.4.patch?revision=1.1).
+Then I did the last step a third time.
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_5_50777853f808d57b957f8ce9a0f84b3d._comment b/doc/install/OSX/old_comments/comment_5_50777853f808d57b957f8ce9a0f84b3d._comment
new file mode 100644
index 0000000000..eca1761786
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_5_50777853f808d57b957f8ce9a0f84b3d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnHrjHxJAm39x8DR4bnbazQO6H0nMNuY9c"
+ nickname="Damien"
+ subject="sha256"
+ date="2012-06-01T16:13:05Z"
+ content="""
+If you're missing the `sha256sum` command with Homebrew, it's provided by `coreutils`. You have to change your `$PATH` before running `cabal install git-annex.cabal`:
+
+    PATH=\"$(brew --prefix coreutils)/libexec/gnubin:$PATH\"
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_5_626a4b4bf302d4ae750174f860402f70._comment b/doc/install/OSX/old_comments/comment_5_626a4b4bf302d4ae750174f860402f70._comment
new file mode 100644
index 0000000000..1b79a11e65
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_5_626a4b4bf302d4ae750174f860402f70._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.248.164"
+ subject="comment 5"
+ date="2012-10-10T15:34:23Z"
+ content="""
+@Сергей, I've fixeed that in git.
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_6_18a8df794aa0ddd294dbf17d3d4c7fe2._comment b/doc/install/OSX/old_comments/comment_6_18a8df794aa0ddd294dbf17d3d4c7fe2._comment
new file mode 100644
index 0000000000..5cb813776b
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_6_18a8df794aa0ddd294dbf17d3d4c7fe2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 6"
+ date="2012-06-01T17:24:29Z"
+ content="""
+Last night I made it look in /opt/local/libexec/gnubin .. if there's another directory it could look in, let me know. I am reluctant to make it run the brew command directly.
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_7_2ce7acab15403d3f993cec94ec7f3bc6._comment b/doc/install/OSX/old_comments/comment_7_2ce7acab15403d3f993cec94ec7f3bc6._comment
new file mode 100644
index 0000000000..32093ee51f
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_7_2ce7acab15403d3f993cec94ec7f3bc6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://www.davidhaslem.com/"
+ nickname="David"
+ subject="comment 7"
+ date="2012-06-19T04:41:27Z"
+ content="""
+$(brew --prefix) should, in most cases, be /usr/local.  That's the recommended install location for homebrew.
+
+I already had git installed and homebrew as my package manager - my install steps were as follows:
+
+1. brew install haskell-platform ossp-uuid md5sha1sum coreutils pcre
+2. PATH=\"$(brew --prefix coreutils)/libexec/gnubin:$PATH\" cabal install git-annex
+
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_8_a93ad4b67c5df4243268bcf32562f6be._comment b/doc/install/OSX/old_comments/comment_8_a93ad4b67c5df4243268bcf32562f6be._comment
new file mode 100644
index 0000000000..cd128a6f13
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_8_a93ad4b67c5df4243268bcf32562f6be._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkwR9uOA38yi5kEUvcEWNtRiZwpxXskayE"
+ nickname="Agustin"
+ subject="Installation not working on OS X 10.6.8"
+ date="2012-06-25T02:21:40Z"
+ content="""
+I try installing with brew because I already had brew setup in my machine, but all run ok but when I try to run cabal install git-annex I got an error with the hinotify-0.3.2 library complaining about a header file.
+
+Full trace:
+
+~~~
+sudo cabal install git-annex
+Resolving dependencies...
+Configuring hinotify-0.3.2...
+Building hinotify-0.3.2...
+Preprocessing library hinotify-0.3.2...
+INotify.hsc:35:25: error: sys/inotify.h: No such file or directory
+INotify.hsc: In function ‘main’:
+INotify.hsc:259: error: invalid use of undefined type ‘struct inotify_event’
+INotify.hsc:260: error: invalid use of undefined type ‘struct inotify_event’
+INotify.hsc:261: error: invalid use of undefined type ‘struct inotify_event’
+INotify.hsc:262: error: invalid use of undefined type ‘struct inotify_event’
+INotify.hsc:265: error: invalid use of undefined type ‘struct inotify_event’
+INotify.hsc:266: error: invalid application of ‘sizeof’ to incomplete type ‘struct inotify_event’ 
+compiling dist/build/System/INotify_hsc_make.c failed (exit code 1)
+command was: /usr/bin/gcc -c dist/build/System/INotify_hsc_make.c -o dist/build/System/INotify_hsc_make.o -m64 -fno-stack-protector -m64 -D__GLASGOW_HASKELL__=704 -Ddarwin_BUILD_OS -Ddarwin_HOST_OS -Dx86_64_BUILD_ARCH -Dx86_64_HOST_ARCH -I/usr/local/Cellar/ghc/7.4.1/lib/ghc-7.4.1/directory-1.1.0.2/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/usr/local/Cellar/ghc/7.4.1/lib/ghc-7.4.1/unix-2.5.1.0/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/usr/local/Cellar/ghc/7.4.1/lib/ghc-7.4.1/old-time-1.1.0.0/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/usr/local/Cellar/ghc/7.4.1/lib/ghc-7.4.1/bytestring-0.9.2.1/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/usr/local/Cellar/ghc/7.4.1/lib/ghc-7.4.1/base-4.5.0.0/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/usr/local/Cellar/ghc/7.4.1/lib/ghc-7.4.1/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/usr/local/Cellar/ghc/7.4.1/lib/ghc-7.4.1/include/
+cabal: Error: some packages failed to install:
+git-annex-3.20120624 depends on hinotify-0.3.2 which failed to install.
+hinotify-0.3.2 failed during the building phase. The exception was:
+ExitFailure 1
+~~~
+
+Anyone has an idea how can I solve this.
+
+Thanks for the time!
+
+Agustin
+
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_9_ae3ed5345bc84f57e44251d2e6c39342._comment b/doc/install/OSX/old_comments/comment_9_ae3ed5345bc84f57e44251d2e6c39342._comment
new file mode 100644
index 0000000000..70fbc6c3c6
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_9_ae3ed5345bc84f57e44251d2e6c39342._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkwR9uOA38yi5kEUvcEWNtRiZwpxXskayE"
+ nickname="Agustin"
+ subject="For the moment"
+ date="2012-06-25T02:51:10Z"
+ content="""
+Hi Joey! I just comment that I could not install it but the issue is with the last version (the one you just release today, so no problem!! man on sunday??  you're awesome!!!) so I installed the previous one and no problem at all
+
+Thanks for all the efford and if you need me to try os whatever, feel free to ask!
+
+Thanks again
+
+Agustin
+"""]]
diff --git a/doc/install/OSX/old_comments/comment_9_c6b1b31d16f2144ad08abd8c767b6ab9._comment b/doc/install/OSX/old_comments/comment_9_c6b1b31d16f2144ad08abd8c767b6ab9._comment
new file mode 100644
index 0000000000..faa7b1b43a
--- /dev/null
+++ b/doc/install/OSX/old_comments/comment_9_c6b1b31d16f2144ad08abd8c767b6ab9._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnBEsNDl_6O4rHb2en3I0-fg-6fUxglaRQ"
+ nickname="chee"
+ subject="Recent install for OS X"
+ date="2012-11-13T04:40:05Z"
+ content="""
+if you are having trouble installing with `cabal install git-annex` at the moment, trouble of the XML kind, you'll need to do a couple things:
+
+`brew update`
+`brew install libxml2`
+`cabal update`
+`cabal install libxml --extra-include-dirs=/usr/local/Cellar/libxml2/2.8.0/include/libxml2 --extra-lib-dirs=/usr/local/Cellar/libxml2/2.8.0/lib`
+
+well, then i hit a brick wall.
+
+well.
+
+I got it to work by manually symlinking from `../Cellar/libxml2/2.8.0/lib/`* into `/usr/local` and from `../../Cellar/libxml2/2.8.0/lib/` to `/usr/local/pkgconfig`, but i can't recommend it or claim to be too proud about it all.
+
+OS X already has an old libxml knocking around so this might ruin everything for me.
+
+let's find out !
+"""]]
diff --git a/doc/install/OSX/porting.mdwn b/doc/install/OSX/porting.mdwn
new file mode 100644
index 0000000000..7aeb1c12c6
--- /dev/null
+++ b/doc/install/OSX/porting.mdwn
@@ -0,0 +1,7 @@
+If you cannot get a OSX build of git-annex suitable for your computer,
+from eg [[HomeBrew]] or the regular [[OSX]] prebuilt app, you
+can try building git-annex from source on OSX, using haskell's cabal package
+manager.
+
+For general instructions on building git-annex from source see
+[[install/fromsource]]
diff --git a/doc/install/OSX/porting/comment_10_cd2120552ef894a37933b328136fa4cc._comment b/doc/install/OSX/porting/comment_10_cd2120552ef894a37933b328136fa4cc._comment
new file mode 100644
index 0000000000..c2b43b2dd3
--- /dev/null
+++ b/doc/install/OSX/porting/comment_10_cd2120552ef894a37933b328136fa4cc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaYy6kTuKAHmsa4BtGls2oqa42Jo2w2v0"
+ nickname="Pere"
+ subject="Segmentation Fault"
+ date="2013-01-19T16:10:08Z"
+ content="""
+I guess my adventure ends here. :'(
+"""]]
diff --git a/doc/install/OSX/porting/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment b/doc/install/OSX/porting/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment
new file mode 100644
index 0000000000..d0c74d6095
--- /dev/null
+++ b/doc/install/OSX/porting/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmyFvkaewo432ELwtCoecUGou4v3jCP0Pc"
+ nickname="Eric"
+ subject="Updating to latest build"
+ date="2013-01-25T06:05:35Z"
+ content="""
+What is the appropriate way to update to the latest build of git-annex using cabal?
+"""]]
diff --git a/doc/install/OSX/porting/comment_12_a84028080578a8b60115b6c4ef823627._comment b/doc/install/OSX/porting/comment_12_a84028080578a8b60115b6c4ef823627._comment
new file mode 100644
index 0000000000..cc57cbdfb6
--- /dev/null
+++ b/doc/install/OSX/porting/comment_12_a84028080578a8b60115b6c4ef823627._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaYy6kTuKAHmsa4BtGls2oqa42Jo2w2v0"
+ nickname="Pere"
+ subject="git annex on Snow Leopard"
+ date="2013-01-25T14:36:52Z"
+ content="""
+Is there any way I can try to solve or by-pass the Segmentation Fault I commeted before? 
+"""]]
diff --git a/doc/install/OSX/porting/comment_13_d6f1db401858ffea23c123db49f5b296._comment b/doc/install/OSX/porting/comment_13_d6f1db401858ffea23c123db49f5b296._comment
new file mode 100644
index 0000000000..875db34f1d
--- /dev/null
+++ b/doc/install/OSX/porting/comment_13_d6f1db401858ffea23c123db49f5b296._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.125"
+ subject="comment 13"
+ date="2013-02-05T19:46:29Z"
+ content="""
+@eric `cabal update && cabal upgrade git-annex`
+"""]]
diff --git a/doc/install/OSX/porting/comment_14_035f856923276b0edad879e196e94097._comment b/doc/install/OSX/porting/comment_14_035f856923276b0edad879e196e94097._comment
new file mode 100644
index 0000000000..1072dbc39f
--- /dev/null
+++ b/doc/install/OSX/porting/comment_14_035f856923276b0edad879e196e94097._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmCmNS-oUgYfNg85-LPuxzTZJUp0sIgprM"
+ nickname="Jonas"
+ subject="more homebrew"
+ date="2013-02-16T19:46:47Z"
+ content="""
+i had macports installed. then i installed brew, instaled haskell via brew. i needed to set 
+    PATH=$HOME/bin:/usr/local/bin:$PATH
+"""]]
diff --git a/doc/install/OSX/porting/comment_15_336e0acb00e84943715e69917643a69e._comment b/doc/install/OSX/porting/comment_15_336e0acb00e84943715e69917643a69e._comment
new file mode 100644
index 0000000000..05f5654bc8
--- /dev/null
+++ b/doc/install/OSX/porting/comment_15_336e0acb00e84943715e69917643a69e._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~wincus"
+ nickname="Juan Moyano"
+ subject="git annex on Snow Leopard"
+ date="2013-03-26T16:02:54Z"
+ content="""
+I'm having the same issue as @Pere, with a newer version of DAV :(
+
+cabal: Error: some packages failed to install:
+DAV-0.3.1 failed during the building phase. The exception was:
+ExitFailure 11
+git-annex-4.20130323 depends on shakespeare-css-1.0.3 which failed to install.
+persistent-1.1.5.1 failed during the building phase. The exception was:
+ExitFailure 11
+persistent-template-1.1.3.1 depends on persistent-1.1.5.1 which failed to
+install.
+shakespeare-css-1.0.3 failed during the building phase. The exception was:
+ExitFailure 11
+yesod-1.1.9.2 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-auth-1.1.5.3 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-core-1.1.8.2 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-default-1.1.3.2 depends on shakespeare-css-1.0.3 which failed to
+install.
+yesod-form-1.2.1.3 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-json-1.1.2.2 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-persistent-1.1.0.1 depends on shakespeare-css-1.0.3 which failed to
+install.
+yesod-static-1.1.2.2 depends on shakespeare-css-1.0.3 which failed to install.
+
+
+
+*Any ideas?*
+
+
+"""]]
diff --git a/doc/install/OSX/porting/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment b/doc/install/OSX/porting/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment
new file mode 100644
index 0000000000..0098e745da
--- /dev/null
+++ b/doc/install/OSX/porting/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkurjhi0CRJvgm7QNaZDWS9hitBtavqIpc"
+ nickname="Bret"
+ subject="Snow Leopard Issues"
+ date="2013-04-14T20:17:17Z"
+ content="""
+I was able to build snow leopard completely for the first time over last night (it took a very long time to build all the tools and dependancies).  Woohoo!
+
+The way I was able to fully build on a 32-bit 10.6 machine was this
+
+1. Delete ~/.ghc and ~/.cabal.  They were full of random things and were causing problems.
+2. `brew uninstall ghc and haskell-platform`
+3. `brew update`
+4. `brew install git ossp-uuid md5sha1sum coreutils libgsasl gnutls libidn libgsasl pkg-config libxml2`
+5. `brew upgrade git ossp-uuid md5sha1sum coreutils libgsasl gnutls libidn libgsasl pkg-config libxml2` (Some of these were already installed/up to date.
+6. `brew link libxml2`
+7. `brew install haskell-platform`  (This takes a long, long time).
+8. `cabal update` (assuming you have added `~/.cabal/bin` to your path
+9. `cabal install cablal-install`
+10. `cabal install c2hs`
+11. `cabal install git-annex`
+
+
+It also appears to be running fairly smoothly than it had in the past on a 32-bit SL system.  Thats also neat.  
+
+The problem is that it seems to not really work as git annex though, probably due to the error relating you get when you start up the webapp:
+Running
+`git annex webapp` 
+The browser starts up, and I get 3 of these errors:
+`Watcher crashed: Need at least OSX 10.7.0 for file-level FSEvents`
+
+Pairing with a local computer appears to work to systems running 10.7, but when you complete the process, they never show up in the repository list.
+
+
+Also on a side note, when running `git annex webapp` it triggers the opening of an html file in whatever the default html file handler is.  I edit a lot of html, so for me that is usually a text editor.  I had to change the file handler to open html files with my web browser for the `git annex webapp` to actually work.  Is there a way to change that so that `git annex webapp` uses the default web browser for the system rather than the default html file handler?
+"""]]
diff --git a/doc/install/OSX/porting/comment_17_19c08b2c6c2c5cd88bf96d2bcbbd9055._comment b/doc/install/OSX/porting/comment_17_19c08b2c6c2c5cd88bf96d2bcbbd9055._comment
new file mode 100644
index 0000000000..8955ab20b2
--- /dev/null
+++ b/doc/install/OSX/porting/comment_17_19c08b2c6c2c5cd88bf96d2bcbbd9055._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 17"
+ date="2013-04-16T20:31:10Z"
+ content="""
+@Bret, the assistant relies on FSEvents pretty heavily. It seems to me your best bet is to upgrade OSX to a version that supports FSEvents.
+
+You can certainly use the rest of git-annex on Snow Leopard without FSEvents.
+"""]]
diff --git a/doc/install/OSX/porting/comment_18_537fad5d8854e765499d47602d1ab398._comment b/doc/install/OSX/porting/comment_18_537fad5d8854e765499d47602d1ab398._comment
new file mode 100644
index 0000000000..9d8d8f755f
--- /dev/null
+++ b/doc/install/OSX/porting/comment_18_537fad5d8854e765499d47602d1ab398._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkurjhi0CRJvgm7QNaZDWS9hitBtavqIpc"
+ nickname="Bret"
+ subject="Can't update"
+ date="2013-04-18T00:58:19Z"
+ content="""
+The laptop is one of the first macbook pro's with a 32 bit chip, which apple dropped support for in 10.7, so the furthest it can update to is 10.6.x. :(
+"""]]
diff --git a/doc/install/OSX/porting/comment_19_18d4377f4ded5604d395d73783ba82c9._comment b/doc/install/OSX/porting/comment_19_18d4377f4ded5604d395d73783ba82c9._comment
new file mode 100644
index 0000000000..f244951e8d
--- /dev/null
+++ b/doc/install/OSX/porting/comment_19_18d4377f4ded5604d395d73783ba82c9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 19"
+ date="2013-04-18T02:05:34Z"
+ content="""
+sounds like a prime candidate for a nice lightweight linux distro ;)
+"""]]
diff --git a/doc/install/OSX/porting/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment b/doc/install/OSX/porting/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment
new file mode 100644
index 0000000000..7dfa481328
--- /dev/null
+++ b/doc/install/OSX/porting/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmRFKwny4rArBaz-36xTcsJYqKIgdDaw5Q"
+ nickname="Andrew"
+ subject="comment 22"
+ date="2013-07-25T02:19:53Z"
+ content="""
+Rather than specifying --bindir on the command line for cabal, I edited my ~/.cabal/config to add this line:
+
+    symlink-bindir: /usr/local/bin
+
+This installs the binaries to ~/.cabal/bin but symlinks them into /usr/local/bin alongside the links that homebrew installs. Additionally, I symlinked /usr/local/bin/git-annex-shell to /usr/local/bin/git-annex which made things work great from remote hosts via ssh.
+"""]]
diff --git a/doc/install/OSX/porting/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment b/doc/install/OSX/porting/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment
new file mode 100644
index 0000000000..08792aa21c
--- /dev/null
+++ b/doc/install/OSX/porting/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmL8pteP2jbYJUn1M3CbeLDvz2SWAA1wtg"
+ nickname="Kristian"
+ subject="Build failure using Haskel Platform"
+ date="2013-09-15T18:49:01Z"
+ content="""
+I get this error when I try to build git-annex using \"cabal install git-annex\"
+
+    [ 34 of 347] Compiling Utility.Misc     ( Utility/Misc.hs, dist/build/git-annex/git-annex-tmp/Utility/Misc.o )
+    [ 35 of 347] Compiling Utility.Process  ( Utility/Process.hs, dist/build/git-annex/git-annex-tmp/Utility/Process.o )
+    [ 36 of 347] Compiling Utility.Network  ( Utility/Network.hs, dist/build/git-annex/git-annex-tmp/Utility/Network.o )
+    [ 37 of 347] Compiling Utility.SRV      ( Utility/SRV.hs, dist/build/git-annex/git-annex-tmp/Utility/SRV.o )
+    
+    Utility/SRV.hs:70:54:
+        Couldn't match expected type `Maybe
+                                        [(Int, Int, Integer, B8.ByteString)]'
+                    with actual type `Either
+                                        dns-1.0.0:Network.DNS.Internal.DNSError
+                                        [(Int, Int, Int, dns-1.0.0:Network.DNS.Internal.Domain)]'
+        In the third argument of `maybe', namely `r'
+        In the second argument of `($)', namely
+          `maybe [] (orderHosts . map tohosts) r'
+        In a stmt of a 'do' block:
+          return $ maybe [] (orderHosts . map tohosts) r
+    Failed to install git-annex-4.20130909
+    cabal: Error: some packages failed to install:
+    git-annex-4.20130909 failed during the building phase. The exception was:
+    ExitFailure 1
+
+"""]]
diff --git a/doc/install/OSX/porting/comment_24_b9d3563a2cc3d769f27876e028dc344d._comment b/doc/install/OSX/porting/comment_24_b9d3563a2cc3d769f27876e028dc344d._comment
new file mode 100644
index 0000000000..4b4bf3eb72
--- /dev/null
+++ b/doc/install/OSX/porting/comment_24_b9d3563a2cc3d769f27876e028dc344d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.128"
+ subject="comment 24"
+ date="2013-09-17T15:56:17Z"
+ content="""
+@Kristian, a new version of the DNS library has caused this. A workaround is to pass `-f-DNS` to the cabal command.
+
+I am in the process of adding support for the new DNS library version in git now.
+
+By the way, please [[file_a_bug|bugs]] if you have a big ugly looking build failure like that, so as to not clutter up this page.
+"""]]
diff --git a/doc/install/OSX/porting/comment_27_2a60108a440231ba83f5a54b6bcc5488._comment b/doc/install/OSX/porting/comment_27_2a60108a440231ba83f5a54b6bcc5488._comment
new file mode 100644
index 0000000000..9a5b9c9c1e
--- /dev/null
+++ b/doc/install/OSX/porting/comment_27_2a60108a440231ba83f5a54b6bcc5488._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="comment 27"
+ date="2013-10-16T09:40:23Z"
+ content="""
+The [FSevents framework itself has been around since leopard](http://arstechnica.com/apple/2007/10/mac-os-x-10-5/7/).
+
+[This fsevents wrapper project](https://github.com/rastersize/CDEvents) supports snow leopard and even leopard, maybe it will provide some clues on how it was done.
+
+I'm guessing it would be worth it, [snow leopard is still the most popular OSX as of April](http://www.patentlyapple.com/patently-apple/2013/04/snow-leopard-remains-the-most-popular-version-of-os-x.html). From my own experience, snow leopard is a huge life extender for 2+ year old hardware. Lion just makes them sluggishly painful to use.
+
+Maybe someone could volunteer an SL machine for remote development? Sorry, mine are tied down :(
+"""]]
diff --git a/doc/install/OSX/porting/comment_27_d453510b9bb62072a4c663206c12c8a4._comment b/doc/install/OSX/porting/comment_27_d453510b9bb62072a4c663206c12c8a4._comment
new file mode 100644
index 0000000000..cc9b44c1a4
--- /dev/null
+++ b/doc/install/OSX/porting/comment_27_d453510b9bb62072a4c663206c12c8a4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 27"
+ date="2013-10-16T15:14:53Z"
+ content="""
+The git-annex assistant uses **file level** FSevents to detect which files have been changed. Would it be possible to make it work with older versions that don't provide file-level events? Probably. The code for BSD kqueue deals with similar limitations in needing to scan the directory to find the files that actually changed. If someone cares about old versions of OSX and wants to do that work I'll happily support you.
+"""]]
diff --git a/doc/install/OSX/porting/comment_28_0970bfd63137ea48701dff6aea1b4bcb._comment b/doc/install/OSX/porting/comment_28_0970bfd63137ea48701dff6aea1b4bcb._comment
new file mode 100644
index 0000000000..a672a70c43
--- /dev/null
+++ b/doc/install/OSX/porting/comment_28_0970bfd63137ea48701dff6aea1b4bcb._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://alan.petitepomme.net/"
+ nickname="Alan Schmitt"
+ subject="dbus support?"
+ date="2013-10-18T08:24:11Z"
+ content="""
+Hello,
+
+I just compiled git-annex using cabal on OS X, and I see there is no dbus support:
+
+    Assistant/Threads/NetWatcher.hs:26:0:
+         warning: #warning Building without dbus support; will poll for network connection changes
+    
+    Assistant/Threads/MountWatcher.hs:33:0:
+         warning: #warning Building without dbus support; will use mtab polling
+
+Is this problematic? I see I can install dbus using homebrew. If I do so, will I have dbus support (after recompiling git-annex)?
+"""]]
diff --git a/doc/install/OSX/porting/comment_29_8622ed56c6a8034c20fb311418d94003._comment b/doc/install/OSX/porting/comment_29_8622ed56c6a8034c20fb311418d94003._comment
new file mode 100644
index 0000000000..c0552d9d99
--- /dev/null
+++ b/doc/install/OSX/porting/comment_29_8622ed56c6a8034c20fb311418d94003._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="comment 29"
+ date="2013-10-18T15:58:59Z"
+ content="""
+I think I dragged you out of dev mode for commenting unnecessarily, sorry about that. Apparently, [Lion](http://www.redmondpie.com/os-x-lion-vs-os-x-snow-leopard-head-to-head-performance-showdown/) and [Mountain Lion are fine on older hardware](http://apple.stackexchange.com/questions/58453/will-mountain-lion-make-an-older-computer-run-faster-or-slower). For a while [a daemon cause Lion slowdowns for a day after upgrade](https://discussions.apple.com/message/15719036) for a while, which was enough to cause a reputation.
+"""]]
diff --git a/doc/install/OSX/porting/comment_30_ce58633ef5b2f8f4caa7e626358f33be._comment b/doc/install/OSX/porting/comment_30_ce58633ef5b2f8f4caa7e626358f33be._comment
new file mode 100644
index 0000000000..9fcf7aa039
--- /dev/null
+++ b/doc/install/OSX/porting/comment_30_ce58633ef5b2f8f4caa7e626358f33be._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 30"
+ date="2013-10-19T15:31:45Z"
+ content="""
+@Alan you don't need to install dbus on OSX. The polling code will work. On the other hand if you'd like to experiment with installing dbus and report back, perhaps it's worth a try. It's nice when the git-annex assistant can instantly detect when drives are plugged in, and then the network connection changes and react to it. On Linux, dbus gives it that capability.
+"""]]
diff --git a/doc/install/OSX/porting/comment_31_09084a7b3cf06bfa3add0f4991476ffe._comment b/doc/install/OSX/porting/comment_31_09084a7b3cf06bfa3add0f4991476ffe._comment
new file mode 100644
index 0000000000..df9134194e
--- /dev/null
+++ b/doc/install/OSX/porting/comment_31_09084a7b3cf06bfa3add0f4991476ffe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://alan.petitepomme.net/"
+ nickname="Alan Schmitt"
+ subject="dbus and homebrew"
+ date="2013-10-20T17:25:04Z"
+ content="""
+I'm trying to build git-annex with dbus support, and even though I installed dbus (through homebrew), at the end of compilation I get the warning about \"building without dbus\". Is there something special I need to do for git-annex to see I have installed dbus?
+
+(Also, it tells me at the beginning that I don't have gcrypt, but libgcrypt is installed.)
+"""]]
diff --git a/doc/install/OSX/porting/comment_32_a46d8e3e7795b9afb1e1c2be943d12af._comment b/doc/install/OSX/porting/comment_32_a46d8e3e7795b9afb1e1c2be943d12af._comment
new file mode 100644
index 0000000000..290da58f85
--- /dev/null
+++ b/doc/install/OSX/porting/comment_32_a46d8e3e7795b9afb1e1c2be943d12af._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 32"
+ date="2013-10-21T22:47:14Z"
+ content="""
+You probably need to install libdbus dev stuff, and then the haskell dbus library. But it's certainly going to need code changes to make git-annex use dbus in any way on OSX, assuming there are even useful dbus events generated for network connections and drives being mounted on OSX.
+
+It was saying \"gcrypt\" when it meant \"git-remote-gcrypt\".
+"""]]
diff --git a/doc/install/OSX/porting/comment_33_203a36322b3c453c05c8906c64e62e06._comment b/doc/install/OSX/porting/comment_33_203a36322b3c453c05c8906c64e62e06._comment
new file mode 100644
index 0000000000..7e2853a4e0
--- /dev/null
+++ b/doc/install/OSX/porting/comment_33_203a36322b3c453c05c8906c64e62e06._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://alan.petitepomme.net/"
+ nickname="Alan Schmitt"
+ subject="comment 33"
+ date="2013-10-23T11:39:51Z"
+ content="""
+I installed the haskell DBus library, but it's still not picking it up. Is there some additional option to pass to cabal, or is it supposed to find it automatically?
+"""]]
diff --git a/doc/install/OSX/porting/comment_34_874ff01f27911baf6ef0f559d5d5f5a0._comment b/doc/install/OSX/porting/comment_34_874ff01f27911baf6ef0f559d5d5f5a0._comment
new file mode 100644
index 0000000000..45b62b770d
--- /dev/null
+++ b/doc/install/OSX/porting/comment_34_874ff01f27911baf6ef0f559d5d5f5a0._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3rK4VDzxyhmrIc18z7F5OuXvEbUsgUac"
+ nickname="Srinath"
+ subject="build issue with brew technique on Darwin Kernel Version 13.0.0"
+ date="2014-02-15T02:17:16Z"
+ content="""
+Following the Mac OS X brew instructions from the top of the board, I got the following error:
+
+[5 of 5] Compiling Yesod            ( Yesod.hs, dist/build/Yesod.o )
+In-place registering yesod-1.2.5...
+Installing library in /Users/srinathv/.cabal/lib/yesod-1.2.5/ghc-7.6.3
+Registering yesod-1.2.5...
+Installed yesod-1.2.5
+cabal: Error: some packages failed to install:
+git-annex-5.20140210 depends on libxml-sax-0.7.4 which failed to install.
+libxml-sax-0.7.4 failed during the configure step. The exception was:
+ExitFailure 1
+network-protocol-xmpp-0.4.5 depends on libxml-sax-0.7.4 which failed to
+install.
+
+
+Then I perused the comments and did:
+$brew link libmxl2 --force
+$cabal install git-annex --bindir=$HOME/bin
+
+with success.  
+"""]]
diff --git a/doc/install/OSX/porting/comment_8_38d9c2eea1090674de2361274eab5b0e._comment b/doc/install/OSX/porting/comment_8_38d9c2eea1090674de2361274eab5b0e._comment
new file mode 100644
index 0000000000..bdc1698b78
--- /dev/null
+++ b/doc/install/OSX/porting/comment_8_38d9c2eea1090674de2361274eab5b0e._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaYy6kTuKAHmsa4BtGls2oqa42Jo2w2v0"
+ nickname="Pere"
+ subject="I couldn't install it on Snow Leopard"
+ date="2013-01-19T15:04:27Z"
+ content="""
+Bad news, it looks like I'm not able to install git-annex to my machine: When I run
+
+    sudo cabal install c2hs git-annex --bindir=$HOME/bin
+
+I get the following error:
+
+    cabal: Error: some packages failed to install:
+    DAV-0.3 failed during the building phase. The exception was:
+    ExitFailure 11
+    git-annex-3.20130114 depends on yesod-core-1.1.7.1 which failed to install.
+    yesod-1.1.7.2 depends on yesod-core-1.1.7.1 which failed to install.
+    yesod-auth-1.1.3 depends on yesod-core-1.1.7.1 which failed to install.
+    yesod-core-1.1.7.1 failed during the building phase. The exception was:
+    ExitFailure 11
+    yesod-default-1.1.3 depends on yesod-core-1.1.7.1 which failed to install.
+    yesod-form-1.2.0.2 depends on yesod-core-1.1.7.1 which failed to install.
+    yesod-json-1.1.2 depends on yesod-core-1.1.7.1 which failed to install.
+    yesod-persistent-1.1.0.1 depends on yesod-core-1.1.7.1 which failed to
+    install.
+    yesod-static-1.1.1.2 depends on yesod-core-1.1.7.1 which failed to install.
+
+What does *ExitFailure 11* mean?
+"""]]
diff --git a/doc/install/OSX/porting/comment_9_35bf3812db6f3ef25da9b3bc84f147c5._comment b/doc/install/OSX/porting/comment_9_35bf3812db6f3ef25da9b3bc84f147c5._comment
new file mode 100644
index 0000000000..afb7334436
--- /dev/null
+++ b/doc/install/OSX/porting/comment_9_35bf3812db6f3ef25da9b3bc84f147c5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.194"
+ subject="comment 9"
+ date="2013-01-19T16:02:35Z"
+ content="""
+sig11 is a Segmentation Fault, probably from a C library used by DAV for HTTP in this case.
+"""]]
diff --git a/doc/install/OpenBSD.mdwn b/doc/install/OpenBSD.mdwn
new file mode 100644
index 0000000000..105345102a
--- /dev/null
+++ b/doc/install/OpenBSD.mdwn
@@ -0,0 +1 @@
+git-annex is [in OpenBSD ports](https://openports.pl/path/devel/git-annex), and can be installed with `pkg_add git-annex`
diff --git a/doc/install/RHEL.mdwn b/doc/install/RHEL.mdwn
new file mode 100644
index 0000000000..a1081ab4ff
--- /dev/null
+++ b/doc/install/RHEL.mdwn
@@ -0,0 +1,4 @@
+git-annex is available in the [EPEL](https://fedoraproject.org/wiki/EPEL) repo.
+
+If that package is too old, you can also use the 
+[[git-annex-standalone rpm|rpm_standalone]].
diff --git a/doc/install/ScientificLinux.mdwn b/doc/install/ScientificLinux.mdwn
new file mode 100644
index 0000000000..a51fccc935
--- /dev/null
+++ b/doc/install/ScientificLinux.mdwn
@@ -0,0 +1,6 @@
+There is a version of git-annex in the 
+[EPEL](https://fedoraproject.org/wiki/EPEL) repo. However, it is probably
+quite old.
+
+To install a newer version of git-annex, use the
+[[git-annex-standalone rpm|rpm_standalone]].
diff --git a/doc/install/Ubuntu.mdwn b/doc/install/Ubuntu.mdwn
new file mode 100644
index 0000000000..6c9d8603d3
--- /dev/null
+++ b/doc/install/Ubuntu.mdwn
@@ -0,0 +1,11 @@
+Ubuntu has a git-annex package, so to install simply run:
+	
+	sudo apt-get install git-annex
+
+## backport
+
+If the version shipped with Ubuntu is too old, 
+the [NeuroDebian team](http://neuro.debian.net/) provides a
+[standalone build package](http://neuro.debian.net/pkgs/git-annex-standalone.html)
+that is regularly updated and that should work across all releases of
+Ubuntu.
diff --git a/doc/install/Ubuntu/Phone.mdwn b/doc/install/Ubuntu/Phone.mdwn
new file mode 100644
index 0000000000..8fccef4905
--- /dev/null
+++ b/doc/install/Ubuntu/Phone.mdwn
@@ -0,0 +1,20 @@
+Ubuntu is available on multiple phones, and as they are running Ubuntu, git-annex can be installed.
+
+## Installation
+
+Use phablet-config writable-image to make the image writable.
+
+Then install git-annex using apt (apt install git-annex).
+
+## Issues
+
+The Debian package does not include the webapp:
+git-annex version: 5.20141125
+build flags: Assistant Pairing Testsuite S3 Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web tahoe glacier ddar hook external
+
+### Application Compatibility
+
+I have had difficulties getting the Music app to play music in a git-annex repository.
+
diff --git a/doc/install/Ubuntu/comment_10_490e065314693423ab6969d8ae6978fe._comment b/doc/install/Ubuntu/comment_10_490e065314693423ab6969d8ae6978fe._comment
new file mode 100644
index 0000000000..d598adfba9
--- /dev/null
+++ b/doc/install/Ubuntu/comment_10_490e065314693423ab6969d8ae6978fe._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkdiXn5s1wX2Zncy1S7_h-yPTv2gt0bmmY"
+ nickname="Jacob"
+ subject="comment 10"
+ date="2013-10-16T11:43:36Z"
+ content="""
+would be great to get the PPA updated with the latest git-annex; i'm finding synchronisation bugs (ie. updates made to word documents aren't replicated), and discovered its rather old now.
+"""]]
diff --git a/doc/install/Ubuntu/comment_11_4ebac3fb43de854ed1a3b1d2ea94011a._comment b/doc/install/Ubuntu/comment_11_4ebac3fb43de854ed1a3b1d2ea94011a._comment
new file mode 100644
index 0000000000..68a889176e
--- /dev/null
+++ b/doc/install/Ubuntu/comment_11_4ebac3fb43de854ed1a3b1d2ea94011a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="fmarier"
+ ip="207.134.53.206"
+ subject="Re: comment 10"
+ date="2013-10-16T13:43:37Z"
+ content="""
+Jacob: make sure you have the right URL for the PPA: https://launchpad.net/~fmarier/+archive/git-annex
+
+It used to be in my main PPA, now it's in a separate PPA by itself. The package was removed from the original PPA (hence it won't update) but is fully up to date in the new one.
+"""]]
diff --git a/doc/install/Ubuntu/comment_12_38f69dffe2db0d15e4c4e5cb47f40ef8._comment b/doc/install/Ubuntu/comment_12_38f69dffe2db0d15e4c4e5cb47f40ef8._comment
new file mode 100644
index 0000000000..7cbf8c0ae9
--- /dev/null
+++ b/doc/install/Ubuntu/comment_12_38f69dffe2db0d15e4c4e5cb47f40ef8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="Raring?"
+ date="2013-11-01T20:28:04Z"
+ content="""
+I'm also on Raring and the latest version available is 3.20121112ubuntu4, nearly a year old.  The PPA is only for Precise.  The tarball is a daily snapshot, and I would much rather run a released version right now.  What can I do?  Can't the PPA be built automatically for Raring and Saucy?
+"""]]
diff --git a/doc/install/Ubuntu/comment_13_7964374bb2332940677eea570bdb0b69._comment b/doc/install/Ubuntu/comment_13_7964374bb2332940677eea570bdb0b69._comment
new file mode 100644
index 0000000000..25ac3e381f
--- /dev/null
+++ b/doc/install/Ubuntu/comment_13_7964374bb2332940677eea570bdb0b69._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawntodrSgODU27WUCyN2PV7TC14YMkyaoxQ"
+ nickname="Dennis"
+ subject="Ubuntu Trusty 14.04"
+ date="2015-01-24T03:20:48Z"
+ content="""
+I am searching for current packages for Ubuntu Trusty 14.04. The version shipped is 5.20140412ubuntu1, but I would like to try a more recent version to see if an issue I experience still persists. Is there any up-to-date PPA available for Trusty?
+"""]]
diff --git a/doc/install/Ubuntu/comment_14_b511063001af2e2170bef657cf016ff2._comment b/doc/install/Ubuntu/comment_14_b511063001af2e2170bef657cf016ff2._comment
new file mode 100644
index 0000000000..472ff6730d
--- /dev/null
+++ b/doc/install/Ubuntu/comment_14_b511063001af2e2170bef657cf016ff2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawltxdgYMUK4CMJh3jC8AlegwyoiHA9Ka7o"
+ nickname="Justin"
+ subject="Trusty PPA"
+ date="2015-01-27T18:24:50Z"
+ content="""
+@Dennis, I just got a backport of the latest release (5.20150113) running under trusty.  This was my first attempt at backporting software and it ended up being a fairly big project.  I had to pull in a lot of haskell dependencies from vivid in order to get this to build.
+
+I'll attempt to keep this PPA up-to-date as long as I don't have to do too much more build dep wrangling.
+
+<https://launchpad.net/~jtgeibel/+archive/ubuntu/ppa?field.series_filter=trusty>
+"""]]
diff --git a/doc/install/Ubuntu/comment_15_4ea052431b49a0505b4a58a760054bed._comment b/doc/install/Ubuntu/comment_15_4ea052431b49a0505b4a58a760054bed._comment
new file mode 100644
index 0000000000..716cee9d04
--- /dev/null
+++ b/doc/install/Ubuntu/comment_15_4ea052431b49a0505b4a58a760054bed._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mhauru"
+ avatar="http://cdn.libravatar.org/avatar/2532433a0207ba772e6ca964e61899c0"
+ subject="NeuroDebian seems to have stopped updating"
+ date="2020-09-27T12:40:54Z"
+ content="""
+The comment about NeuroDebian providing more up to date builds is out of date, their version is now more than a year old. An alternative would be welcome, something between the official Ubuntu package and compiling from source.
+"""]]
diff --git a/doc/install/Ubuntu/comment_16_b5dd1d73309e427d6e817a3a69beea74._comment b/doc/install/Ubuntu/comment_16_b5dd1d73309e427d6e817a3a69beea74._comment
new file mode 100644
index 0000000000..8e79819905
--- /dev/null
+++ b/doc/install/Ubuntu/comment_16_b5dd1d73309e427d6e817a3a69beea74._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 16"
+ date="2020-09-27T13:42:15Z"
+ content="""
+Eh, true. Our version is year old as the one which doesn't cause regressions in datalad. We are still fighting with some remaining regressions. See eg one of the last attempts https://github.com/datalad/datalad/pull/4915 .
+
+We do have unannounced on the NeuroDebian debian-devel/ (complement to regular debian/ line in your apt listing) from the main NeuroDebian website (not mirrors). That is where we upload those versions to test.
+
+Also there is now a daily built git annex .deb (and .dmg for osx) package as artifact of GitHub workflow, eg https://github.com/datalad/datalad-extensions/actions/runs/274613689 . I guess we better automatically upload them somewhere for easier fetching/deployment.
+"""]]
diff --git a/doc/install/Ubuntu/comment_1_d1c511153fe94bf33e19a1281f1c92f2._comment b/doc/install/Ubuntu/comment_1_d1c511153fe94bf33e19a1281f1c92f2._comment
new file mode 100644
index 0000000000..3b48bb4066
--- /dev/null
+++ b/doc/install/Ubuntu/comment_1_d1c511153fe94bf33e19a1281f1c92f2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkx5V3MTbzCXS3J7Mn9FEq8M9bPPYMkAHY"
+ nickname="Pedro"
+ subject="comment 1"
+ date="2013-05-20T15:53:25Z"
+ content="""
+Note that the fmarier ppa includes more than just git-annex. I've asked the author if he could segregate git-annex into a separate ppa.
+"""]]
diff --git a/doc/install/Ubuntu/comment_2_ad13886c1c1f76d1cd995ea7b7d8471c._comment b/doc/install/Ubuntu/comment_2_ad13886c1c1f76d1cd995ea7b7d8471c._comment
new file mode 100644
index 0000000000..2d8221be13
--- /dev/null
+++ b/doc/install/Ubuntu/comment_2_ad13886c1c1f76d1cd995ea7b7d8471c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlQ7ZdQxAps4v0cl5J3wKGWD8243Gy8-m0"
+ nickname="Phil"
+ subject="PPA Package Pinning"
+ date="2013-05-23T21:18:14Z"
+ content="""
+@Pedro, see <http://askubuntu.com/a/170265> for blocking all packages except git-annex from François's repo.
+"""]]
diff --git a/doc/install/Ubuntu/comment_3_a08817322739b03cf0fec97283b16f1a._comment b/doc/install/Ubuntu/comment_3_a08817322739b03cf0fec97283b16f1a._comment
new file mode 100644
index 0000000000..6d47d49bed
--- /dev/null
+++ b/doc/install/Ubuntu/comment_3_a08817322739b03cf0fec97283b16f1a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.fmarier.org/"
+ nickname="fmarier"
+ subject="New PPA only contains git-annex"
+ date="2013-06-15T07:45:13Z"
+ content="""
+As Pedro suggested, I've moved my git-annex backport to a separate PPA with only git-annex and the 220 Haskell packages it depends on.
+"""]]
diff --git a/doc/install/Ubuntu/comment_4_fe0997e56136bd30749f0995cbf19b56._comment b/doc/install/Ubuntu/comment_4_fe0997e56136bd30749f0995cbf19b56._comment
new file mode 100644
index 0000000000..04992f31e4
--- /dev/null
+++ b/doc/install/Ubuntu/comment_4_fe0997e56136bd30749f0995cbf19b56._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmhGq_ii5HaDkp9nx2m9qIMe-xxI4HV5wo"
+ nickname="Jeff"
+ subject="Packages way out of date"
+ date="2013-07-27T19:02:38Z"
+ content="""
+I'm setting up git-annex for myself (wanting to use the assistant to build myself a replacement for dropbox/box/ownCloud, etc.) and I installed the ubuntu package. Unfortunately, it is way out of date (3.20120406: amd64 i386). I didn't think to check the version. It's deceiving as the UI's are all the same, but it doesn't seem to work at all (syncing fails to remote servers, odd things happen with symlinking files to git object files, changing file permissions). 
+
+It gives a bad first intro into git-annex on ubuntu (*nix?) machines. It might be best just to point people at the cabal install for now so we get the lastest and greatest.
+
+Anyway, thanks for the great tool, I'm looking forward to using it.
+"""]]
diff --git a/doc/install/Ubuntu/comment_5_fbb5306a162db1a1ee9efa3523aac952._comment b/doc/install/Ubuntu/comment_5_fbb5306a162db1a1ee9efa3523aac952._comment
new file mode 100644
index 0000000000..fc525af962
--- /dev/null
+++ b/doc/install/Ubuntu/comment_5_fbb5306a162db1a1ee9efa3523aac952._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 5"
+ date="2013-07-27T20:12:33Z"
+ content="""
+Jeff, AFAIK the 3.20120406 in precise does not include the assistant at all. The Precise PPA is well up-to-date. 
+I don't think git-annex has anyone in Ubuntu updating the package, so it's whatever version is synced periodically from Debian.
+
+(AFAICS, all the problems Jeff had were due to manually creating an indirect mode repository when he expected direct mode.)
+"""]]
diff --git a/doc/install/Ubuntu/comment_6_a97e7f0e62ac685c3ded423bddeaa67f._comment b/doc/install/Ubuntu/comment_6_a97e7f0e62ac685c3ded423bddeaa67f._comment
new file mode 100644
index 0000000000..3f9a2fd194
--- /dev/null
+++ b/doc/install/Ubuntu/comment_6_a97e7f0e62ac685c3ded423bddeaa67f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmhGq_ii5HaDkp9nx2m9qIMe-xxI4HV5wo"
+ nickname="Jeff"
+ subject="comment 6"
+ date="2013-07-27T21:51:11Z"
+ content="""
+Ah, does it only have the webapp? I was able to boot the webapp and see messages, and it looked mostly the same, I assumed it was broken since no syncing was happening, but that would be due to the assistant not being there.
+
+I guess it's hard as a new user that goes straight for the easy/out-of-the box solution, via the assistant, after watching your video on it. I just assumed things were broken since I was seeing slightly different things. I didn't understand that the assistant was separate from the webapp (and was missing).
+
+Maybe mentioning the minimum required version on the assistant page to at least prompt users to check the version they're getting? I assumed following the link to the install guide, and installing the package for Ubuntu, would give me what I needed.
+
+
+"""]]
diff --git a/doc/install/Ubuntu/comment_7_921a223fd7e679b9ced3d8ba5ce688e0._comment b/doc/install/Ubuntu/comment_7_921a223fd7e679b9ced3d8ba5ce688e0._comment
new file mode 100644
index 0000000000..2cc1f66529
--- /dev/null
+++ b/doc/install/Ubuntu/comment_7_921a223fd7e679b9ced3d8ba5ce688e0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmhGq_ii5HaDkp9nx2m9qIMe-xxI4HV5wo"
+ nickname="Jeff"
+ subject="comment 7"
+ date="2013-07-27T21:53:45Z"
+ content="""
+I see how I missed this page too. I just saw the `apt-get install git-annex` and didn't even register Ubuntu as a link with more information.
+"""]]
diff --git a/doc/install/Ubuntu/comment_8_1f943cb084fa8e21bc6ee5fc3118f02f._comment b/doc/install/Ubuntu/comment_8_1f943cb084fa8e21bc6ee5fc3118f02f._comment
new file mode 100644
index 0000000000..d51ac5345b
--- /dev/null
+++ b/doc/install/Ubuntu/comment_8_1f943cb084fa8e21bc6ee5fc3118f02f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 8"
+ date="2013-07-27T21:53:57Z"
+ content="""
+The webapp is part of the assistant. I was told Precise didn't have it, but IIRC they were working on fixing that build, and perhaps that has happened now.
+"""]]
diff --git a/doc/install/Ubuntu/comment_9_c2f8b35ada873acb1ce593b04e2899fe._comment b/doc/install/Ubuntu/comment_9_c2f8b35ada873acb1ce593b04e2899fe._comment
new file mode 100644
index 0000000000..828b80e396
--- /dev/null
+++ b/doc/install/Ubuntu/comment_9_c2f8b35ada873acb1ce593b04e2899fe._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/2eeca722-8d1c-41fe-8fda-13af7eaff6ae"
+ nickname="Diggory"
+ subject="Outdated in 13.04"
+ date="2013-10-08T16:36:10Z"
+ content="""
+13.04 Raring also has fairly outdated packages: 3.20121112ubuntu4
+Is there a PPA or some such for this? I suppose since Saucy will be out soon this is less critical, but would still be useful.
+
+These don't have direct mode, which (I think; I haven't tested it yet) is the feature I've been waiting for.
+"""]]
diff --git a/doc/install/Void.mdwn b/doc/install/Void.mdwn
new file mode 100644
index 0000000000..772c9d9b93
--- /dev/null
+++ b/doc/install/Void.mdwn
@@ -0,0 +1 @@
+git-annex can be installed in Void Linux by running: `xbps-install git-annex`.
diff --git a/doc/install/Windows.mdwn b/doc/install/Windows.mdwn
new file mode 100644
index 0000000000..6ea4b5f756
--- /dev/null
+++ b/doc/install/Windows.mdwn
@@ -0,0 +1,37 @@
+git-annex now does Windows!
+
+* First, [install Git for Windows](http://git-scm.com/downloads)
+
+* Then, install git-annex:
+
+  - Windows 10 [download](https://downloads.kitenet.net/git-annex/windows/current/)
+
+This port is now in reasonably good shape for command-line use of
+git-annex. The assistant and webapp are also usable. There are some known
+problems and parts that don't work. See [[todo/windows_support]] for
+current status.
+
+## autobuilds
+
+An autobuild is also available, thanks to the Datalad project.
+
+* Windows 10 [download](https://downloads.kitenet.net/git-annex/autobuild/windows/git-annex-installer.exe)
+  ([build logs](https://github.com/datalad/git-annex/actions?query=workflow%3A%22Build+git-annex+on+Windows%22))
+
+## download security
+
+All the download links above use https for security. For added security, see
+[[verifying_downloads]].
+
+## building it yourself
+
+To build git-annex from source on Windows, you need to install
+[Git for Windows](http://git-scm.com/downloads), and
+[Stack](http://haskellstack.org/).
+
+Then open Git Bash, [[clone git-annex|download]], and in git-annex's source
+tree, run "stack build" to download and
+build all dependencies and git-annex. "stack install" will install git-annex.
+
+(To build the git-annex installer, you also need to install the NullSoft
+installer system, see Build/NullSoftInstaller.hs for details.)
diff --git a/doc/install/Windows/comment_10_39edee046193c7d36daaf245fa87007c._comment b/doc/install/Windows/comment_10_39edee046193c7d36daaf245fa87007c._comment
new file mode 100644
index 0000000000..8b8b09db3d
--- /dev/null
+++ b/doc/install/Windows/comment_10_39edee046193c7d36daaf245fa87007c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nix.zahlen@1211ac6c964ba2d68b70655f747bef1383032e77"
+ nickname="nix.zahlen"
+ avatar="http://cdn.libravatar.org/avatar/66cc45a05749fe8d4ca36d8c6071da51"
+ subject="windows installer has not been updated"
+ date="2020-06-28T20:01:35Z"
+ content="""
+the windows installer is \"8.20200331-gb11931a4a\"
+"""]]
diff --git a/doc/install/Windows/comment_11_6310a850074cf65b1c0b5b49e2e5b582._comment b/doc/install/Windows/comment_11_6310a850074cf65b1c0b5b49e2e5b582._comment
new file mode 100644
index 0000000000..133b3a1e65
--- /dev/null
+++ b/doc/install/Windows/comment_11_6310a850074cf65b1c0b5b49e2e5b582._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mreiden"
+ avatar="http://cdn.libravatar.org/avatar/00e411c947bed82f673935f36f6be689"
+ subject="Autobuild permissions"
+ date="2020-07-22T16:07:20Z"
+ content="""
+It looks like the windows autobuild is updating based on the timestamps and the build-version contents (8.20200720.2-gd9ae6ab0b), but permission is denied on the exe file (https://downloads.kitenet.net/git-annex/autobuild/windows/git-annex-installer.exe).
+"""]]
diff --git a/doc/install/Windows/comment_12_3a7080a31d30ccb32fede56a98bb635a._comment b/doc/install/Windows/comment_12_3a7080a31d30ccb32fede56a98bb635a._comment
new file mode 100644
index 0000000000..09b70f9ca5
--- /dev/null
+++ b/doc/install/Windows/comment_12_3a7080a31d30ccb32fede56a98bb635a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nix.zahlen@1211ac6c964ba2d68b70655f747bef1383032e77"
+ nickname="nix.zahlen"
+ avatar="http://cdn.libravatar.org/avatar/66cc45a05749fe8d4ca36d8c6071da51"
+ subject="It is really a pitty that the Windows port / version is unmaintained"
+ date="2020-07-24T17:48:07Z"
+ content="""
+Is there maybe a how-to somewhere which describes how we could compile the source on Windows to have more recent versions?!
+"""]]
diff --git a/doc/install/Windows/comment_13_6a998c400070059477de18a81a3ba0b5._comment b/doc/install/Windows/comment_13_6a998c400070059477de18a81a3ba0b5._comment
new file mode 100644
index 0000000000..dd486c45b9
--- /dev/null
+++ b/doc/install/Windows/comment_13_6a998c400070059477de18a81a3ba0b5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""permissions fixed"""
+ date="2020-08-10T17:07:29Z"
+ content="""
+If you had filed a bug report about this permissions problem, I would have
+fixed it immediately. Instead I had to read all comments on the web site 
+before I noticed it weeks later.
+
+This build is being maintained, but you have to file bug reports when there
+are problems with it.
+"""]]
diff --git a/doc/install/Windows/comment_14_7b5f0c6b31d9c409ea0989123788bacf._comment b/doc/install/Windows/comment_14_7b5f0c6b31d9c409ea0989123788bacf._comment
new file mode 100644
index 0000000000..fefd166ae9
--- /dev/null
+++ b/doc/install/Windows/comment_14_7b5f0c6b31d9c409ea0989123788bacf._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="nix.zahlen@1211ac6c964ba2d68b70655f747bef1383032e77"
+ nickname="nix.zahlen"
+ avatar="http://cdn.libravatar.org/avatar/66cc45a05749fe8d4ca36d8c6071da51"
+ subject="where and how to submit Windows autobuild related issues?"
+ date="2020-10-31T17:44:18Z"
+ content="""
+see <br>
+- http://git-annex.branchable.com/news/version_8.20201007/#comment-cc425c38dbd1e3e6ee308bf2d9de1fd1 <br>
+- http://git-annex.branchable.com/bugs/windows_dosn__39__t_build_again__63____33__/#comment-90263bc0689187fb5df4d44ce668c08c (bug moved to \"done\"?!? but there is still no updated Windows installer available...) <br>
+
+
+"""]]
diff --git a/doc/install/Windows/comment_15_19226be8cae0c29b0e9a54cebcf1f17b._comment b/doc/install/Windows/comment_15_19226be8cae0c29b0e9a54cebcf1f17b._comment
new file mode 100644
index 0000000000..f55154a278
--- /dev/null
+++ b/doc/install/Windows/comment_15_19226be8cae0c29b0e9a54cebcf1f17b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="nix.zahlen@1211ac6c964ba2d68b70655f747bef1383032e77"
+ nickname="nix.zahlen"
+ avatar="http://cdn.libravatar.org/avatar/66cc45a05749fe8d4ca36d8c6071da51"
+ subject="build a CI/CD chain for git-annex"
+ date="2020-10-31T17:47:15Z"
+ content="""
+would this be: <br>
+* possible? <br>
+* desired? <br>
+* appreciated? <br>
+
+If yes, how and where? Ideas?
+
+"""]]
diff --git a/doc/install/Windows/comment_16_b4b60bed666355ace286775afe87860d._comment b/doc/install/Windows/comment_16_b4b60bed666355ace286775afe87860d._comment
new file mode 100644
index 0000000000..0b33a6ce6d
--- /dev/null
+++ b/doc/install/Windows/comment_16_b4b60bed666355ace286775afe87860d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 16"
+ date="2020-11-02T21:04:35Z"
+ content="""
+FWIW -- there is now CI for git-annex on linux (debian-based), osx, and Windows on https://github.com/datalad/datalad-extensions/ which builds git-annex installer, tests git-annex, and then tests datalad against it in a few scenarios.
+ATM it runs on cron, so not for each git-annex commit.  We will see if we need/want more frequent builds. Artifacts (re)distribution will eventually be established on http://datasets.datalad.org/datalad/packages/ but we aren't there yet.
+"""]]
diff --git a/doc/install/Windows/comment_17_165ac8b0e1cd4f250e681eb88c0624d3._comment b/doc/install/Windows/comment_17_165ac8b0e1cd4f250e681eb88c0624d3._comment
new file mode 100644
index 0000000000..5036ee9ef1
--- /dev/null
+++ b/doc/install/Windows/comment_17_165ac8b0e1cd4f250e681eb88c0624d3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="arelius@a7e47ae13cb3452464261e3a99bfe6d2c25895fd"
+ nickname="arelius"
+ avatar="http://cdn.libravatar.org/avatar/f89b3d8d61a90fed8f52ac7ea9dd4456"
+ subject="comment 17"
+ date="2021-02-24T04:49:33Z"
+ content="""
+I'm using the git-annex from the CI build... Even though it appears to be an x64 build, it appears to put the docs in /mingw32 instead of /mingw64 preventing the docs from being located.
+"""]]
diff --git a/doc/install/Windows/comment_18_e0adfbf74754f847dc4705685cf00640._comment b/doc/install/Windows/comment_18_e0adfbf74754f847dc4705685cf00640._comment
new file mode 100644
index 0000000000..845d50be1f
--- /dev/null
+++ b/doc/install/Windows/comment_18_e0adfbf74754f847dc4705685cf00640._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: comment 17"""
+ date="2021-02-24T17:18:01Z"
+ content="""
+I've corrected that path.
+
+(Please don't use this page to report issues with the windows build.
+Open bug reports.)
+"""]]
diff --git a/doc/install/Windows/comment_1_e5e5c7b75859493a7d94cbf7df746fb9._comment b/doc/install/Windows/comment_1_e5e5c7b75859493a7d94cbf7df746fb9._comment
new file mode 100644
index 0000000000..0421d93576
--- /dev/null
+++ b/doc/install/Windows/comment_1_e5e5c7b75859493a7d94cbf7df746fb9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jpfeifer@4c6cf56b857caa324cbbc9f133705fb2fb3f9bef"
+ nickname="jpfeifer"
+ subject="Compatibility with recent version of Git for Windows"
+ date="2015-09-02T17:58:41Z"
+ content="""
+Git for Windows now has a 64 bit version. Thus, the installation path must be adjusted accordingly. This page should note that git annex must be installed in the same folder as git itself.
+"""]]
diff --git a/doc/install/Windows/comment_2_ef329ea100b36a1180e232a1f97369d6._comment b/doc/install/Windows/comment_2_ef329ea100b36a1180e232a1f97369d6._comment
new file mode 100644
index 0000000000..e51d4b14e6
--- /dev/null
+++ b/doc/install/Windows/comment_2_ef329ea100b36a1180e232a1f97369d6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="eren.m.dursun@73116dce47e54243c7ee1637f1289afb02f07f4b"
+ nickname="eren.m.dursun"
+ subject="Re: Compatibility with recent version of Git for Windows"
+ date="2015-11-29T19:24:03Z"
+ content="""
+To install git-annex next to 64bit git on Windows:
+
+Start cmd.exe with administrator privileges and run
+mklink /J \"C:\Program Files (x86)\Git\" \"C:\Program Files\Git\"
+to add a sym-link. Install git-annex.
+"""]]
diff --git a/doc/install/Windows/comment_3_10fb90bc434b4da189ed7235818ef30f._comment b/doc/install/Windows/comment_3_10fb90bc434b4da189ed7235818ef30f._comment
new file mode 100644
index 0000000000..b57136526c
--- /dev/null
+++ b/doc/install/Windows/comment_3_10fb90bc434b4da189ed7235818ef30f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-11-30T19:05:36Z"
+ content="""
+@eren, some of the programs included with git-annex need to use libraries
+from Git for Windows. In particular, I think you'll find that rsync doesn't
+work if you use the 64 bit Git for Windows.
+"""]]
diff --git a/doc/install/Windows/comment_4_c81a36e387ca11050cf8cb977fff98ff._comment b/doc/install/Windows/comment_4_c81a36e387ca11050cf8cb977fff98ff._comment
new file mode 100644
index 0000000000..d2d866fd11
--- /dev/null
+++ b/doc/install/Windows/comment_4_c81a36e387ca11050cf8cb977fff98ff._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ avatar="http://cdn.libravatar.org/avatar/7003e967f47003bae82966aa373de8ef"
+ subject="comment 4"
+ date="2018-04-21T09:52:31Z"
+ content="""
+Is 64-bit still a problem now that git-annex has switched over from rsync to its own transport?
+"""]]
diff --git a/doc/install/Windows/comment_5_88ad2f657bf92e8c6144608612b9be49._comment b/doc/install/Windows/comment_5_88ad2f657bf92e8c6144608612b9be49._comment
new file mode 100644
index 0000000000..90e8f589d4
--- /dev/null
+++ b/doc/install/Windows/comment_5_88ad2f657bf92e8c6144608612b9be49._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-07-03T16:32:22Z"
+ content="""
+rsync is still used for some things, the rsync special remote and 
+communication with servers using older versions of git-annex.
+"""]]
diff --git a/doc/install/Windows/comment_6_90ef5d5a4f66ac3e440aadf302a625a9._comment b/doc/install/Windows/comment_6_90ef5d5a4f66ac3e440aadf302a625a9._comment
new file mode 100644
index 0000000000..86ba67b377
--- /dev/null
+++ b/doc/install/Windows/comment_6_90ef5d5a4f66ac3e440aadf302a625a9._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="error when building on windows"
+ date="2019-07-22T18:04:29Z"
+ content="""
+Building on Windows gives this error:
+
+[[!format sh \"\"\"
+Extracting  ghc-8.6.5.tar
+
+Everything is Ok
+
+Size:       1773445120
+Compressed: 280280296
+Extracting ghc-8.6.5.tar...
+Extracted total of 9780 files from ghc-8.6.5.tar
+C:\Users\ilya\AppData\Local\Programs\stack\x86_64-windows\ghc-8.6.5-tmp6568\ghc-8.6.5\: renamePath:MoveFileEx \"C:\\Users\\ilya\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.6.5-tmp6568\\ghc-8.6.5\\\" \"C:\\Users\\ilya\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.6.5\\\": permission denied (Access is denied.)
+
+\"\"\"]]
+
+Running Git Bash with Administrator privileges does not seem to help.  Anyone else run into this / know how to fix it?  Thanks!
+"""]]
diff --git a/doc/install/Windows/comment_7_0589dd8c33572dd1d0ef5cb7b29ebba7._comment b/doc/install/Windows/comment_7_0589dd8c33572dd1d0ef5cb7b29ebba7._comment
new file mode 100644
index 0000000000..cb738b3270
--- /dev/null
+++ b/doc/install/Windows/comment_7_0589dd8c33572dd1d0ef5cb7b29ebba7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="hourly windows autobuild seems to have stopped running"
+ date="2019-08-19T19:47:06Z"
+ content="""
+The hourly windows autobuild seems to be several days old?
+"""]]
diff --git a/doc/install/Windows/comment_8_35c66016c971a623ec86318adf7923b4._comment b/doc/install/Windows/comment_8_35c66016c971a623ec86318adf7923b4._comment
new file mode 100644
index 0000000000..32d2d2730c
--- /dev/null
+++ b/doc/install/Windows/comment_8_35c66016c971a623ec86318adf7923b4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="michael.fsp@85f5ea833fb457cf7b0b0181c314888d5f32649c"
+ nickname="michael.fsp"
+ avatar="http://cdn.libravatar.org/avatar/f398e1ea7eed60be1d45caa3126fc691"
+ subject="windows installer has not been updated to version 7.20191218"
+ date="2019-12-21T18:17:19Z"
+ content="""
+Just to let you know that the windows installer is still at version 7.20191115
+
+Thanks for the awesome work!
+"""]]
diff --git a/doc/install/Windows/comment_9_2687128ff7aa4b6f29e8b880b5d4d13d._comment b/doc/install/Windows/comment_9_2687128ff7aa4b6f29e8b880b5d4d13d._comment
new file mode 100644
index 0000000000..00fad5d1c2
--- /dev/null
+++ b/doc/install/Windows/comment_9_2687128ff7aa4b6f29e8b880b5d4d13d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2020-01-01T19:04:08Z"
+ content="""
+@michael.fsp autobuilder was down. There's a build now for the most recent
+release.
+"""]]
diff --git a/doc/install/comment_1_0aa16754fb08d8f2a54c8c3f78b6c187._comment b/doc/install/comment_1_0aa16754fb08d8f2a54c8c3f78b6c187._comment
new file mode 100644
index 0000000000..1bf53f02a9
--- /dev/null
+++ b/doc/install/comment_1_0aa16754fb08d8f2a54c8c3f78b6c187._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7eqCMh_B7mxE0tnchbr0JoYu11FUAFRY"
+ nickname="Stéphane"
+ subject="Old versions from distributions (e.g. Debian stable) fail with online instructions."
+ date="2014-06-28T15:36:12Z"
+ content="""
+Hello everyone.
+
+Be aware that your distribution's package may be very old.
+For example, at the time I write this, latest Debian stable is Debian 7.5 which is 2 months old.
+But git-annex package there is two *years* old (tomorrow, it will be exactly two yezrs old).
+
+So, beware.  If following [online walkthrough](https://git-annex.branchable.com/walkthrough/), either install a more recent git-annex (e.g. from [Debain backports](http://backports.debian.org/Instructions/)) or follow instructions from your local `/usr/share/doc/git-annex/html/walkthrough.html` instead.
+"""]]
diff --git a/doc/install/comment_2_ba3985a5cbd9f5682807d2bdbb9874e2._comment b/doc/install/comment_2_ba3985a5cbd9f5682807d2bdbb9874e2._comment
new file mode 100644
index 0000000000..4db93ac341
--- /dev/null
+++ b/doc/install/comment_2_ba3985a5cbd9f5682807d2bdbb9874e2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="For Debian/Ubuntu users -- get git-annex-standalone from NeuroDebian"
+ date="2017-07-12T17:57:21Z"
+ content="""
+We provide quite an up-to-date standalone backport build of git-annex (package name [git-annex-standalone](http://neuro.debian.net/pkgs/git-annex-standalone.html)) through NeuroDebian for all Debian/Ubuntus, so you might want to enable NeuroDebian repository (`apt-get install neurodebian`  on a recent debian/ubuntu or follow [NeuroDebian website](http://neuro.debian.net) for instructions). 
+"""]]
diff --git a/doc/install/comment_3_9a2118d6f967585cb21f9d9b372f4017._comment b/doc/install/comment_3_9a2118d6f967585cb21f9d9b372f4017._comment
new file mode 100644
index 0000000000..499b2c3999
--- /dev/null
+++ b/doc/install/comment_3_9a2118d6f967585cb21f9d9b372f4017._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Alan"
+ avatar="http://cdn.libravatar.org/avatar/9cbc26346f1c693d7df198e662a5fdae"
+ subject="No package for debian stretch, armh?"
+ date="2017-08-25T11:58:38Z"
+ content="""
+I cannot find a package for Debian Stretch for the armh architecture. I don't see git-annex in the official packages, and armh is not available in neurodebian. Is building from source the only option?
+"""]]
diff --git a/doc/install/comment_5_a2532a0fea59d15a2efa11748ff0d70a._comment b/doc/install/comment_5_a2532a0fea59d15a2efa11748ff0d70a._comment
new file mode 100644
index 0000000000..809c683172
--- /dev/null
+++ b/doc/install/comment_5_a2532a0fea59d15a2efa11748ff0d70a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="dittigas"
+ avatar="http://cdn.libravatar.org/avatar/58cabd2b30471004288fac2b535faaa8"
+ subject="git-annex-webapp missing from Fedora 27"
+ date="2018-03-27T07:43:53Z"
+ content="""
+My installation does not seem to include the webapp feature. I.e git-annex webapp, git annex webapp or git-annex-webapp are not abailble.
+"""]]
diff --git a/doc/install/comment_6_4ae37152bc9765cea921b436fb2785d8._comment b/doc/install/comment_6_4ae37152bc9765cea921b436fb2785d8._comment
new file mode 100644
index 0000000000..c06c13ee23
--- /dev/null
+++ b/doc/install/comment_6_4ae37152bc9765cea921b436fb2785d8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: git-annex-webapp missing from Fedora 27"""
+ date="2018-04-04T15:59:51Z"
+ content="""
+@dittigas git-annex can be built without the webapp,
+if the libraries it uses are not made available at build time.
+I suggest you get in touch with the Fedora maintainers and ask them to
+enable the webapp in their builds.
+"""]]
diff --git a/doc/install/comment_7_bc273d60cb74241231183186aefbc147._comment b/doc/install/comment_7_bc273d60cb74241231183186aefbc147._comment
new file mode 100644
index 0000000000..94e3ace489
--- /dev/null
+++ b/doc/install/comment_7_bc273d60cb74241231183186aefbc147._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="seregynp@3214c4138198e0fe5615d11af832f69f8f5b6873"
+ nickname="seregynp"
+ avatar="http://cdn.libravatar.org/avatar/9070bf4684f1f7ed88564c6d75f29d59"
+ subject="Cannot upgrade to v6"
+ date="2018-09-15T10:20:58Z"
+ content="""
+I'm running Ubuntu:
+
+    Distributor ID: Ubuntu                                                                  │                                                                                       
+    Description:    Ubuntu 16.04.5 LTS                                                      │                                                                                       
+    Release:        16.04                                                                   │                                                                                       
+    Codename:       xenial
+
+Installed git annex with: \"apt-get install git-annex\".
+
+And here is the my \"git-annex version\":
+
+    git-annex version: 5.20151208-1build1                                                   │                                                                                       
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus Des│                                                                                       
+    ktopNotify XMPP DNS Feeds Quvi TDFA TorrentParser Database                              │                                                                                       
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256│                                                                                       
+    E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 S│                                                                                       
+    KEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL                                          │                                                                                       
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar│                                                                                       
+     hook external
+
+When i'm trying to \"git annex init --version=6\" it says: \"Usage: git-annex init [DESC]\".  
+Meaning v5 git annex does not support \"--version\" option for \"init\" command.
+
+If i'm running \"git annex upgrade\", it says: \"upgrade . ok\".  
+But then \"git annex version\" shows v5 again.
+
+Is it possible to upgrade from v5 to v6 currently ?  
+Am i doing anything wrong ?
+"""]]
diff --git a/doc/install/comment_8_1330a5413b720eca0103a0880d24eb2d._comment b/doc/install/comment_8_1330a5413b720eca0103a0880d24eb2d._comment
new file mode 100644
index 0000000000..29b8c07a31
--- /dev/null
+++ b/doc/install/comment_8_1330a5413b720eca0103a0880d24eb2d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2018-10-04T18:24:07Z"
+ content="""
+@seregynp, you need git-annex version 7 to use that.
+"""]]
diff --git a/doc/install/comment_8_768498659909c37044f2b4dd08bacda3._comment b/doc/install/comment_8_768498659909c37044f2b4dd08bacda3._comment
new file mode 100644
index 0000000000..73e75dee54
--- /dev/null
+++ b/doc/install/comment_8_768498659909c37044f2b4dd08bacda3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="Git for Windows installation -- support for symlinks"
+ date="2019-08-08T15:04:07Z"
+ content="""
+The Git for Windows installer has a setting to turn on support for symlinks, which is not the default.  It says something about symlinks requiring special permissions.  What setting should be used with git-annex?
+"""]]
diff --git a/doc/install/conda.mdwn b/doc/install/conda.mdwn
new file mode 100644
index 0000000000..beaddfb193
--- /dev/null
+++ b/doc/install/conda.mdwn
@@ -0,0 +1,15 @@
+On Linux, an up-to-date binary distribution of git-annex can now be
+installed with the [conda package manager](https://conda.io/docs/) 
+from the [conda-forge channel](https://conda-forge.org/).
+
+After [installing conda](https://docs.conda.io/en/latest/miniconda.html), run:
+
+	conda install -c conda-forge git-annex
+
+Note that this installation method does not need root permissions.
+
+If there are [package conflicts](https://docs.conda.io/projects/conda/en/latest/user-guide/troubleshooting.html#unsatisfiablespecifications-error) between git-annex's dependencies and packages already installed in the environment, conda may fall back on installing the [[standalone|install/Linux_standalone]] git-annex distribution.  This distribution may work slower or have other [[issues|todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__]].  To require installation of the standard package, use
+
+	conda install -c conda-forge git-annex=*=alldep*
+
+This, however, could result in installing an older git-annex version to avoid package conflicts.
diff --git a/doc/install/conda/comment_1_d9fbae3aca8853a13919350d405d686b._comment b/doc/install/conda/comment_1_d9fbae3aca8853a13919350d405d686b._comment
new file mode 100644
index 0000000000..d6beb247c8
--- /dev/null
+++ b/doc/install/conda/comment_1_d9fbae3aca8853a13919350d405d686b._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="cardoso-neto"
+ avatar="http://cdn.libravatar.org/avatar/d90a656df072f3a29da54302c190c696"
+ subject="Ugly message when installing git-annex through conda"
+ date="2020-08-14T00:08:25Z"
+ content="""
+Whenever I install git-annex through conda, this message haunts me:
+
+```
+Downloading and Extracting Packages
+certifi-2020.6.20    | 151 KB    | ############################################################################################################################################################## | 100% 
+conda-4.8.4          | 3.1 MB    | ############################################################################################################################################################## | 100% 
+python_abi-3.7       | 4 KB      | ############################################################################################################################################################## | 100% 
+Preparing transaction: done
+Verifying transaction: done
+Executing transaction: \ b'\n##############################################################################\n#                                                                            #\n# Standalone distribution of git-annex was installed, instead of the         #\n# standard distribution, likely due to package conflicts in the target       #\n# environment.  The standalone distribution may have issues (e.g. be slower, #\n# or not pass the expected environment to some external programs);           #\n# the standard distribution should be used when possible.                    #\n# You can force installation of the standard version by adding =alldep* to   #\n# the build string, e.g.                                                     #\n# conda install git-annex=*=alldep*                                          #\n#                                                                            #\n# For more info on the standalone git-annex distribution see                 #\n# https://git-annex.branchable.com/install/Linux_standalone/                 #\n#                                                                            #\n##############################################################################\n'
+done
+```
+
+I couldn't help, but notice this sounds like what @Ilya_Shlyakhter said earlier.
+
+I'm not a packaging expert, but I don't think this message is really supposed to be here. 
+"""]]
diff --git a/doc/install/conda/comment_2_8968f1e04a08fb95644910089438b02d._comment b/doc/install/conda/comment_2_8968f1e04a08fb95644910089438b02d._comment
new file mode 100644
index 0000000000..cded74f08e
--- /dev/null
+++ b/doc/install/conda/comment_2_8968f1e04a08fb95644910089438b02d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2020-08-14T02:59:08Z"
+ content="""
+\"this sounds like what @Ilya_Shlyakhter said earlier\" because I maintain the conda package :)  I need to figure out why the `nodep*` version gets chosen even though the `alldep*` version has a higher build number -- will ask conda people and get back.  If you prefer not to be haunted just install with `git-annex=*=alldep*` to force the standard version.
+
+"""]]
diff --git a/doc/install/fromsource.mdwn b/doc/install/fromsource.mdwn
new file mode 100644
index 0000000000..4ebdbf7c1c
--- /dev/null
+++ b/doc/install/fromsource.mdwn
@@ -0,0 +1,121 @@
+So you want to build git-annex from source. This is encouraged for
+users with experience building code from source. But the build may
+require some care and feeding. This page will start with the easy
+methods and work up to the harder ones.
+
+This page also covers installing git-annex from source, but in many
+cases it's better to install it using your OS's package manager.
+
+## downloading the source code
+
+The easiest way is using git; see [[download]] or just run:
+
+	git clone git://git-annex.branchable.com/ git-annex
+
+## building from source on Debian
+
+This is the method used by git-annex's author, and so it's the one most
+likely to work without problems.
+
+First, install everything git-annex needs to build:
+
+	sudo apt-get build-dep git-annex
+
+Now you can build git-annex by running `make` inside the source tree.
+
+Then, to install the program and associated files system-wide in `/usr/local`,
+run:
+
+	sudo make install PREFIX=/usr/local
+
+Or, to install the program into $HOME/.local/bin, and associated files
+into other parts of your HOME directory, run:
+
+	make install-home
+
+## building from source with stack
+
+Using stack automates nearly everything, will work on many systems,
+and avoids build failures due to fast-changing haskell libraries.
+
+First, [install stack](https://docs.haskellstack.org/en/stable/install_and_upgrade/)  
+On Debian:
+
+	sudo apt-get install haskell-stack zlib1g-dev
+
+Get the git-annex source code, and inside the source tree run:
+
+	stack setup
+	stack build
+
+To install the program and all associated files system-wide
+in `/usr/local`, run:
+
+	sudo make install BUILDER=stack PREFIX=/usr/local
+
+Or, to install the program into $HOME/.local/bin, and associated files
+into other parts of your HOME directory, run:
+
+	make install-home BUILDER=stack
+
+(Why not run `stack install git-annex`? Because that causes stack to 
+[ignore git-annex's stack.yaml file](https://github.com/commercialhaskell/stack/issues/2371),
+yielding a less reliable build. Stack also only installs the binary,
+and not other files.)
+
+Note that this build produces a git-annex without the build flags
+DBUS and MagicMime.
+These optional features require installing additional C libraries.
+To try to build with these features 
+enabled, pass extra parameters when running `stack build`: 
+`--flag git-annex:DBUS --flag git-annex:MagicMime`
+
+## minimal build from source with cabal
+
+This can be done anywhere, and builds git-annex without some optional
+features that require harder-to-install C libraries. This is plenty to let
+you get started with git-annex, but it does not include the assistant or
+webapp.
+
+Be warned that this involves building a lot of Haskell libraries from
+source, and so it has a lot of moving parts, and it's not uncommon for it
+to be broken from time to time.
+
+Get the git-annex source code, and inside the source tree, run:
+
+	cabal install -j -f"-assistant -webapp -pairing -dbus -magicmime" --only-dependencies
+	cabal configure -f"-assistant -webapp -pairing -dbus -magicmime"
+	cabal build -j
+
+To install the program and all associated files system-wide
+in `/usr/local`, run:
+
+	sudo make install BUILDER=cabal PREFIX=/usr/local
+
+Or, to install the program into $HOME/.local/bin, and associated files
+into other parts of your HOME directory, run:
+
+	make install-home BUILDER=cabal
+
+## full build from source with cabal
+
+To build with all features enabled, including the assistant and webapp,
+you will need to install several C libraries and their headers,
+including libmagic, and zlib. How to do that for your OS is beyond
+the scope of this page. 
+
+Once the C libraries are installed, run inside the source tree:
+
+	cabal install -j --only-dependencies
+	cabal configure
+	cabal build -j
+
+To install the program and all associated files system-wide
+in `/usr/local`, run:
+
+	sudo make install BUILDER=cabal PREFIX=/usr/local
+
+Or, to install the program into $HOME/.local/bin, and associated files
+into other parts of your HOME directory, run:
+
+	make install-home BUILDER=cabal
diff --git a/doc/install/fromsource/comment_10_7ebe353b05d4df29897dc9a4f45c8a91._comment b/doc/install/fromsource/comment_10_7ebe353b05d4df29897dc9a4f45c8a91._comment
new file mode 100644
index 0000000000..5b813baba2
--- /dev/null
+++ b/doc/install/fromsource/comment_10_7ebe353b05d4df29897dc9a4f45c8a91._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 10"
+ date="2013-07-27T17:49:07Z"
+ content="""
+@Henning; see the [[OSX]] page for full installation instructions for OSX. Which include all the neccesary brew incantations.
+"""]]
diff --git a/doc/install/fromsource/comment_11_0d06702e6e0ae3cd331cf748a9f6f273._comment b/doc/install/fromsource/comment_11_0d06702e6e0ae3cd331cf748a9f6f273._comment
new file mode 100644
index 0000000000..94919710fb
--- /dev/null
+++ b/doc/install/fromsource/comment_11_0d06702e6e0ae3cd331cf748a9f6f273._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlXEIT2PEAuHuInLP4UYVzWE0lceMYd2lA"
+ nickname="Gregor"
+ subject="Installation on tonidoplug"
+ date="2013-08-03T07:19:54Z"
+ content="""
+I tried various ways to install git-annex on my [TonidoPlug](http://www.tonidoplug.com/).
+
+System Info:
+
+	root@TonidoPlug2:~# uname -a
+	Linux TonidoPlug2 2.6.31.8-topkick1281p2-001-004-20101214 #1 Thu Jun 16 10:06:20 CST 2011 armv5tel GNU/Linux
+
+`apt-get` didn't work.
+
+	root@TonidoPlug2:~# apt-get install git-annex
+	Reading package lists... Done
+	Building dependency tree       
+	Reading state information... Done
+	E: Unable to locate package git-annex
+
+The Linux standalone installation results in an error message like this, when calling `git-annex` (or `git annex`)
+
+	~$ git-annex.linux/git-annex
+	/home/gitolite/git-annex.linux/bin/git-annex: 1: Syntax error: \")\" unexpected
+
+(git-annex.linux/bin/git-annex is a binary file and works fine on other distros)
+
+When installing with cabal, I get the error message (tried as root and gitolite user)
+
+	~$ cabal install git-annex --bindir=$HOME/bin -f\"-assistant -webapp -webdav -pairing -xmpp -dns\"
+	Resolving dependencies...
+	cabal: cannot configure git-annex-4.20130802. It requires base >=4.5 && <4.8
+	For the dependency on base >=4.5 && <4.8 there are these packages:
+	base-4.5.0.0, base-4.5.1.0, base-4.6.0.0 and base-4.6.0.1. However none of
+	them are available.
+	base-4.5.0.0 was excluded because of the top level dependency base -any
+	base-4.5.1.0 was excluded because of the top level dependency base -any
+	base-4.6.0.0 was excluded because of the top level dependency base -any
+	base-4.6.0.1 was excluded because of the top level dependency base -any
+
+Any help is appreciated.
+Thanks for providing git-annex. I started cleaning up my backups with it yesterday and really like it.
+"""]]
diff --git a/doc/install/fromsource/comment_12_b93ca271dffca3f948645d3e1326c1d9._comment b/doc/install/fromsource/comment_12_b93ca271dffca3f948645d3e1326c1d9._comment
new file mode 100644
index 0000000000..8d9c97898f
--- /dev/null
+++ b/doc/install/fromsource/comment_12_b93ca271dffca3f948645d3e1326c1d9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 12"
+ date="2013-08-07T16:31:30Z"
+ content="""
+The Linux standalone builds for i386 and amd64 will not work on Arm systems.
+
+There are builds of git-annex for arm in eg, Debian. You should be able to use one of those if this system is running Debian. You may need to upgrade to eg, Debian stable, which includes git-annex.
+
+It looks like you have an old and/or broken GHC compiler too. You could upgrade that to a newer version (eg from Debian stable) and build it that way, but it seems like the long way around if you have a Debian system there.
+"""]]
diff --git a/doc/install/fromsource/comment_13_3dac019cda71bf99878c0a1d9382323b._comment b/doc/install/fromsource/comment_13_3dac019cda71bf99878c0a1d9382323b._comment
new file mode 100644
index 0000000000..80e3a6ad14
--- /dev/null
+++ b/doc/install/fromsource/comment_13_3dac019cda71bf99878c0a1d9382323b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlXEIT2PEAuHuInLP4UYVzWE0lceMYd2lA"
+ nickname="Gregor"
+ subject="TonidoPlug"
+ date="2013-08-09T17:46:28Z"
+ content="""
+@Joey Thanks for the answer. I didn't want to mess around too much with the TonidoPlug. I am currently setting up a raspberry pi, which works fine. 
+"""]]
diff --git a/doc/install/fromsource/comment_14_14b46470593f84f8c3768a91cb77bdab._comment b/doc/install/fromsource/comment_14_14b46470593f84f8c3768a91cb77bdab._comment
new file mode 100644
index 0000000000..93fca16531
--- /dev/null
+++ b/doc/install/fromsource/comment_14_14b46470593f84f8c3768a91cb77bdab._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlfIVXjkzrYE9qJAO2A0H7K6tKGMaSgc3U"
+ nickname="Daniel"
+ subject="Problems with cryptocipher"
+ date="2013-08-22T01:36:50Z"
+ content="""
+I had problems following these directions on recent releases of Fedora/Ubuntu. The install attempts failed on cryptocipher-0.3.1, which I think came as a dependency of Yesod.
+I was able to work around this by installing yesod-platform with cabal first, then installing git-annex.
+"""]]
diff --git a/doc/install/fromsource/comment_15_c3a5b0aad28a90e0bb8da31a430578eb._comment b/doc/install/fromsource/comment_15_c3a5b0aad28a90e0bb8da31a430578eb._comment
new file mode 100644
index 0000000000..fc64af2341
--- /dev/null
+++ b/doc/install/fromsource/comment_15_c3a5b0aad28a90e0bb8da31a430578eb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="77.247.181.162"
+ subject="git-annex assistant on Arm"
+ date="2013-08-23T03:07:11Z"
+ content="""
+I'd like to use the assistant's power on a Raspberry Pi to build an always-on file/sync server. Is there a way to get the assistant running on Arm? I know there's a Debian package, but it's Version 3.20120629 and comes without the assistant. Has anyone ever successfully built a recent git-annex version on Arm? What would I need in order to do it myself? 
+"""]]
diff --git a/doc/install/fromsource/comment_16_4faf214f97f9516898d7c17d743ef825._comment b/doc/install/fromsource/comment_16_4faf214f97f9516898d7c17d743ef825._comment
new file mode 100644
index 0000000000..be14b39081
--- /dev/null
+++ b/doc/install/fromsource/comment_16_4faf214f97f9516898d7c17d743ef825._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 16"
+ date="2013-08-23T17:37:52Z"
+ content="""
+The git-annex assistant can easily be built on arm. But not the webapp. It's entirely possible to use the assistant without the webapp though; you just have to make the git repository and configure the remotes by hand, and then the assistant will sync them the same way the webapp does.
+
+It is possible but very involved to build the webapp for arm. I do not anticipate doing it in the Debian package until ghc gets proper template haskell support for arm. See [[forum/Webapp_on_ARM]]
+"""]]
diff --git a/doc/install/fromsource/comment_17_2a9d6807a3a13815c824985521757167._comment b/doc/install/fromsource/comment_17_2a9d6807a3a13815c824985521757167._comment
new file mode 100644
index 0000000000..c0b570dfb6
--- /dev/null
+++ b/doc/install/fromsource/comment_17_2a9d6807a3a13815c824985521757167._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="77.247.181.162"
+ subject="comment 17"
+ date="2013-08-23T18:51:51Z"
+ content="""
+Thanks for the quick answer. I will try to build git-annex with just the assistant, as you suggest, and once it works set up the server by hand as you suggest. 
+
+BTW: Awesome job you're doing with git-annex. I appreciate your enthusiasm.
+"""]]
diff --git a/doc/install/fromsource/comment_18_1efa0c7a963ec452fc6336fbe4964f6e._comment b/doc/install/fromsource/comment_18_1efa0c7a963ec452fc6336fbe4964f6e._comment
new file mode 100644
index 0000000000..e3a523e228
--- /dev/null
+++ b/doc/install/fromsource/comment_18_1efa0c7a963ec452fc6336fbe4964f6e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="96.47.226.20"
+ subject="git-annex assistant for the Raspberry Pi"
+ date="2013-09-04T03:58:37Z"
+ content="""
+It took a while and a few tries, but I finally built the git-annex binary including the assistant on a Raspberry Pi. The build comes without the flags webapp, webdav, and dbus as these rely on a Template Haskell compiler that hasn't been ported to Arm architecture yet. 
+
+I put the binary up on Github in case anyone's interested: <https://github.com/tradloff/git-annex-RPi>
+"""]]
diff --git a/doc/install/fromsource/comment_19_6f42f9234f9ff6a2ca6bbb4d2643843e._comment b/doc/install/fromsource/comment_19_6f42f9234f9ff6a2ca6bbb4d2643843e._comment
new file mode 100644
index 0000000000..27a3e8c620
--- /dev/null
+++ b/doc/install/fromsource/comment_19_6f42f9234f9ff6a2ca6bbb4d2643843e._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlu7K3h7Ry1uDAU_ERYGuqt0LoGNJqGuRo"
+ nickname="Nathan"
+ subject="Cabal installing git-annex on Ubuntu 12.04 Precise with GHC 7.6.3"
+ date="2013-09-25T22:39:04Z"
+ content="""
+I now realize [there is a Ubuntu 12.04 Precise PPA with a current
+version of
+git-annex](http://git-annex.branchable.com/install/Ubuntu/), so that's
+probably a better choice, but here's how I cabal isntalled git-annex.
+
+1. Apt install non-cabal dependencies:
+
+       sudo aptitude install c2hs libgsasl7-dev libxml2-dev
+
+2. Manually cabal install yesod-platform to avoid the [cryptocipher problem 
+   mentioned above](
+   http://git-annex.branchable.com/install/cabal/#comment-1807da37dc144b572b76aaf4b574bb54):
+
+       cabal install yesod-platform
+
+3. Cabal install git-annex with DNS flag disabled:
+
+       cabal install git-annex -f\"-dns\"
+
+I was getting this error building git-annex before disabling the DNS flag:
+
+    Utility/SRV.hs:70:54:
+        Couldn't match expected type `Maybe
+                                        [(Int, Int, Integer, B8.ByteString)]'
+                    with actual type `Either
+                                        dns-1.0.0:Network.DNS.Internal.DNSError
+                                        [(Int, Int, Int, dns-1.0.0:Network.DNS.Internal.Domain)]'
+        In the third argument of `maybe', namely `r'
+        In the second argument of `($)', namely
+          `maybe [] (orderHosts . map tohosts) r'
+        In a stmt of a 'do' block:
+          return $ maybe [] (orderHosts . map tohosts) r
+
+Looking at Utiltity/SRV.hs, it appears that disabling the DNS flag
+just makes git annex use a different DNS library (ADNS), not
+actually disable DNS lookups.
+
+"""]]
diff --git a/doc/install/fromsource/comment_1_9d085e460553fa045999ab7cb945cdec._comment b/doc/install/fromsource/comment_1_9d085e460553fa045999ab7cb945cdec._comment
new file mode 100644
index 0000000000..1b68d0f8cb
--- /dev/null
+++ b/doc/install/fromsource/comment_1_9d085e460553fa045999ab7cb945cdec._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="azul"
+ ip="91.36.153.149"
+ subject="cabal fails to resolve dependencies"
+ date="2014-06-19T08:49:05Z"
+ content="""
+I tried this on ubuntu 14.04 without any previous haskell installs and cabal failed to resolve the dependencies:
+
+rejecting: optparse-applicative-0.9.0 (conflict: hjsmin =>
+optparse-applicative>=0.7 && <0.9)
+
+[full log](paste.debian.net/105771/)
+"""]]
diff --git a/doc/install/fromsource/comment_1_f04df6bcd50d1d01eb34868bb00ac35c._comment b/doc/install/fromsource/comment_1_f04df6bcd50d1d01eb34868bb00ac35c._comment
new file mode 100644
index 0000000000..b280d3d3de
--- /dev/null
+++ b/doc/install/fromsource/comment_1_f04df6bcd50d1d01eb34868bb00ac35c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlJemqsekZTC5dvc-MAByUWaBvsYE-mFUo"
+ nickname="Gábor"
+ subject="Cabal dependencies"
+ date="2013-05-12T12:52:20Z"
+ content="""
+After finishing the installation the cabal way, here are the packages I installed. It is possible that there are other packages I installed previously as dependency for other packages.
+
+    $ lsb_release -a
+    No LSB modules are available.
+    Distributor ID:	Ubuntu
+    Description:	Ubuntu 12.04.2 LTS
+    Release:	12.04
+    Codename:	precise
+    
+    $ apt-get install cabal-install libgnutls28-dev libgsasl7-dev c2hs libghc-libxml-sax-dev zlib1g-dev libghc-zlib-dev
+    $ cabal install git-annex --bindir=$HOME/bin
+"""]]
diff --git a/doc/install/fromsource/comment_20_0f553be2a4c666e3bed58b2bce549406._comment b/doc/install/fromsource/comment_20_0f553be2a4c666e3bed58b2bce549406._comment
new file mode 100644
index 0000000000..288c0e0176
--- /dev/null
+++ b/doc/install/fromsource/comment_20_0f553be2a4c666e3bed58b2bce549406._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlkA6XinbeOdnEDxEGQUWyjqPGh0kdMXr4"
+ nickname="Blake"
+ subject="Updating git-annex via cabal"
+ date="2013-10-09T21:21:22Z"
+ content="""
+What is the best way to update git-annex and the dependencies via cabal? Just the `$ cabal install *` commands again?
+"""]]
diff --git a/doc/install/fromsource/comment_21_f91a6ec21e96eced73ea9579fd8cbd15._comment b/doc/install/fromsource/comment_21_f91a6ec21e96eced73ea9579fd8cbd15._comment
new file mode 100644
index 0000000000..ef8a3d2a3e
--- /dev/null
+++ b/doc/install/fromsource/comment_21_f91a6ec21e96eced73ea9579fd8cbd15._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.22"
+ subject="comment 21"
+ date="2013-10-11T17:09:33Z"
+ content="""
+If you run the \"cabal update\" command followed by the \"cabal install\" command it'll upgrade git-annex.
+"""]]
diff --git a/doc/install/fromsource/comment_22_2f27b78215f97ade1986ca806c634cb3._comment b/doc/install/fromsource/comment_22_2f27b78215f97ade1986ca806c634cb3._comment
new file mode 100644
index 0000000000..d7ff056177
--- /dev/null
+++ b/doc/install/fromsource/comment_22_2f27b78215f97ade1986ca806c634cb3._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="96.44.189.100"
+ subject="&quot;Could not find module Crypto.Hash&quot; error when building git-annex "
+ date="2013-10-21T19:55:12Z"
+ content="""
+Lately I get this error message when trying to build git-annex-v4.20131002:
+
+    Utility/Hash.hs:7:8:
+        Could not find module `Crypto.Hash'
+        Perhaps you meant
+    	  Crypto.HMAC (needs flag -package crypto-api-0.10.2)
+        Use -v to see a list of the files searched for.
+
+crypto-api-0.10.2 is installed as a debian dev package. All the dependencies are met. I have no idea what's going on.  
+"""]]
diff --git a/doc/install/fromsource/comment_23_c34d2b1d95830a3e58671a5b566a1758._comment b/doc/install/fromsource/comment_23_c34d2b1d95830a3e58671a5b566a1758._comment
new file mode 100644
index 0000000000..03a5b87ce4
--- /dev/null
+++ b/doc/install/fromsource/comment_23_c34d2b1d95830a3e58671a5b566a1758._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="64.134.31.139"
+ subject="comment 23"
+ date="2013-10-21T22:09:05Z"
+ content="""
+git-annex needs cryptohash version 0.10.0 or greater. You appear to have an old version. You can cabal `configure -f-CryptoHash` if it's for some reason failing to disable the cryptohash support despite the declared dependency not being met.
+"""]]
diff --git a/doc/install/fromsource/comment_24_40cbde8ec067b3a860e6df1a9bea5f76._comment b/doc/install/fromsource/comment_24_40cbde8ec067b3a860e6df1a9bea5f76._comment
new file mode 100644
index 0000000000..3bb1605466
--- /dev/null
+++ b/doc/install/fromsource/comment_24_40cbde8ec067b3a860e6df1a9bea5f76._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="37.130.227.133"
+ subject="comment 24"
+ date="2013-10-22T17:55:32Z"
+ content="""
+I fixed the error by installing a newer version of cryptohash. Thanks for pointing out the culprit. 
+"""]]
diff --git a/doc/install/fromsource/comment_25_8a7664e6f9271718dc607a0782366c5b._comment b/doc/install/fromsource/comment_25_8a7664e6f9271718dc607a0782366c5b._comment
new file mode 100644
index 0000000000..929956ede7
--- /dev/null
+++ b/doc/install/fromsource/comment_25_8a7664e6f9271718dc607a0782366c5b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="141.138.141.208"
+ subject="Bad version on Hackage"
+ date="2013-10-30T18:56:25Z"
+ content="""
+Quick note: The latest version in the Hackage repository (git-annex-4.20131024) fails to build, due to a faulty version of Assistant/Threads/Cronner.hs. 
+"""]]
diff --git a/doc/install/fromsource/comment_26_bd455c732639728bce2bfc39e32871d2._comment b/doc/install/fromsource/comment_26_bd455c732639728bce2bfc39e32871d2._comment
new file mode 100644
index 0000000000..5b1f06023b
--- /dev/null
+++ b/doc/install/fromsource/comment_26_bd455c732639728bce2bfc39e32871d2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 26"
+ date="2013-11-01T16:33:25Z"
+ content="""
+@RaspberryPie that only affected builds without the webapp, in any case it's fixed now.
+"""]]
diff --git a/doc/install/fromsource/comment_27_c080e9239b6eec88d329c28da7bb4141._comment b/doc/install/fromsource/comment_27_c080e9239b6eec88d329c28da7bb4141._comment
new file mode 100644
index 0000000000..4c007c9ad9
--- /dev/null
+++ b/doc/install/fromsource/comment_27_c080e9239b6eec88d329c28da7bb4141._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="37.221.160.203"
+ subject="comment 27"
+ date="2013-11-02T12:52:18Z"
+ content="""
+Okay, the error doesn't show up anymore. I didn't even get to Cronner though, because this time I got a different error:
+
+    Assistant/Alert.hs:195:20:
+        Couldn't match expected type `Assistant ()' with actual type `()'
+        Expected type: Maybe Remote -> Assistant ()
+          Actual type: Maybe Remote -> ()
+        In the expression: noop
+        In an equation for `notFsckedNudge': notFsckedNudge _ = noop
+
+This is from trying to compile 4.20131101 with `-f\"-webapp -webdav\"`
+"""]]
diff --git a/doc/install/fromsource/comment_28_15951dd070a675300420eea137a28ef9._comment b/doc/install/fromsource/comment_28_15951dd070a675300420eea137a28ef9._comment
new file mode 100644
index 0000000000..19a570caec
--- /dev/null
+++ b/doc/install/fromsource/comment_28_15951dd070a675300420eea137a28ef9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 28"
+ date="2013-11-02T17:40:18Z"
+ content="""
+Unfortunate about that. I've fixed it in git.
+
+(It would be best to file bug reports about build failures to avoid cluttering up this page.)
+"""]]
diff --git a/doc/install/fromsource/comment_29_ac082dca67f4a29b06070c0283130f52._comment b/doc/install/fromsource/comment_29_ac082dca67f4a29b06070c0283130f52._comment
new file mode 100644
index 0000000000..524a0db0cf
--- /dev/null
+++ b/doc/install/fromsource/comment_29_ac082dca67f4a29b06070c0283130f52._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="robohack"
+ ip="24.67.98.78"
+ subject="cabal install failing due to problems building pcre-light-0.4"
+ date="2013-11-21T20:17:10Z"
+ content="""
+After a fresh install of Haskell, and following the instructions above, I end up with the following rather bizarre and unexpected problem:
+
+	$ cabal install git-annex --bindir=$HOME/bin -f\"-assistant -webapp -webdav -pairing -xmpp -dns\"
+	Resolving dependencies...
+	Configuring pcre-light-0.4...
+	Building pcre-light-0.4...
+	Preprocessing library pcre-light-0.4...
+	Base.hsc:103:18: error: pcre.h: No such file or directory
+	Base.hsc: In function ‘main’:
+	Base.hsc:402: error: ‘PCRE_ANCHORED’ undeclared (first use in this function)
+	Base.hsc:402: error: (Each undeclared identifier is reported only once
+	Base.hsc:402: error: for each function it appears in.)
+	Base.hsc:405: error: ‘PCRE_AUTO_CALLOUT’ undeclared (first use in this function)
+
+(followed by an error for every other macro that was expected to be defined in the header...)
+
+	compiling dist/build/Text/Regex/PCRE/Light/Base_hsc_make.c failed (exit code 1)
+	command was: /usr/bin/gcc -c dist/build/Text/Regex/PCRE/Light/Base_hsc_make.c -o dist/build/Text/Regex/PCRE/Light/Base_hsc_make.o -m64 -fno-stack-protector -m64 -fno-stack-protector -m64 -D__GLASGOW_HASKELL__=700 -Ddarwin_BUILD_OS -Ddarwin_HOST_OS -Dx86_64_BUILD_ARCH -Dx86_64_HOST_ARCH -I/sw/lib/ghc-7.0.4/bytestring-0.9.1.10/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/sw/lib/ghc-7.0.4/base-4.3.1.0/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/sw/lib/ghc-7.0.4/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/sw/lib/ghc-7.0.4/include -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/sw/lib/ghc-7.0.4/include/
+	Failed to install pcre-light-0.4
+	cabal: Error: some packages failed to install:
+	git-annex-3.20120230 depends on pcre-light-0.4 which failed to install.
+	pcre-light-0.4 failed during the building phase. The exception was:
+	ExitFailure 1
+
+This is a somewhat older Mac OS X 10.6.8 system.
+
+I do have PCRE already installed via Fink, and pcre.h is in /sw/include.  I see other -I/sw/... things in the compile command above, but obviously /sw/include is not one of them.
+
+Any clues for me?
+
+(Why the heck does git-annex need pcre in particular anyway???  I saw another regex library get installed earlier somewhere in this (massive) process.)
+
+"""]]
diff --git a/doc/install/fromsource/comment_2_a69d17c55e56a707ec6606d5cdddee25._comment b/doc/install/fromsource/comment_2_a69d17c55e56a707ec6606d5cdddee25._comment
new file mode 100644
index 0000000000..5a7beea37a
--- /dev/null
+++ b/doc/install/fromsource/comment_2_a69d17c55e56a707ec6606d5cdddee25._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="E: Unable to locate package libghc-libxml-sax-dev"
+ date="2013-05-30T15:05:47Z"
+ content="""
+I get an error from the command as above:
+$ sudo apt-get install cabal-install libgnutls28-dev libgsasl7-dev c2hs libghc libxml-sax-dev zlib1g-dev libghc-zlib-dev
+
+$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 12.04.2 LTS
+Release:	12.04
+Codename:	precise
+
+"""]]
diff --git a/doc/install/fromsource/comment_2_b7954521d9ab40622b665f278dd72e17._comment b/doc/install/fromsource/comment_2_b7954521d9ab40622b665f278dd72e17._comment
new file mode 100644
index 0000000000..949ee0abf5
--- /dev/null
+++ b/doc/install/fromsource/comment_2_b7954521d9ab40622b665f278dd72e17._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="azul"
+ ip="91.36.173.120"
+ subject="conflict solved"
+ date="2014-06-20T06:13:09Z"
+ content="""
+`apt-get install happy alex libghc-hjsmin-dev`
+solved the problem for me. The hjsmin lib was probably crucial. It seems a bunch of dependencies can also be installed as debs rather than through cabal.
+`standalone/android/buildchroot-inchroot` gave me a clue.
+"""]]
diff --git a/doc/install/fromsource/comment_30_ad639c07cb79e89406e95c1dafce3a01._comment b/doc/install/fromsource/comment_30_ad639c07cb79e89406e95c1dafce3a01._comment
new file mode 100644
index 0000000000..f068944b09
--- /dev/null
+++ b/doc/install/fromsource/comment_30_ad639c07cb79e89406e95c1dafce3a01._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="robohack"
+ ip="24.67.98.78"
+ subject="hmmm... ok, the PCRE problem was odd, but now this:"
+ date="2013-11-21T20:30:54Z"
+ content="""
+The PCRE problem is solved trivially in my case with a couple more cabal install options, though the need for these seems oddly dissatisfying given the reams of other stuff that was successfully built and installed without these options.
+
+Now however I seem to have encountered a deeper problem:
+
+	$ cabal install git-annex --bindir=$HOME/bin --extra-include-dirs=/sw/include --extra-lib-dirs=/sw/lib               
+	Resolving dependencies...
+	[1 of 1] Compiling Main             ( /var/folders/7h/7hWHR5m8HPKOnUEvQU7HU++++TI/-Tmp-/git-annex-3.20120230-84797/git-annex-3.20120230/Setup.hs, /var/folders/7h/7hWHR5m8HPKOnUEvQU7HU++++TI/-Tmp-/git-annex-3.20120230-84797/git-annex-3.20120230/dist/setup/Main.o )
+	Linking /var/folders/7h/7hWHR5m8HPKOnUEvQU7HU++++TI/-Tmp-/git-annex-3.20120230-84797/git-annex-3.20120230/dist/setup/setup ...
+	hsc2hs Utility/StatFS.hsc
+	perl -i -pe 's/^{-# INCLUDE.*//' Utility/StatFS.hs
+	ghc -O2 -Wall -ignore-package monads-fd --make configure
+	
+	Utility/StatFS.hsc:54:8:
+	    Could not find module `GHC.Foreign':
+	      Use -v to see a list of the files searched for.
+	make: *** [Build/SysConfig.hs] Error 1
+	Configuring git-annex-3.20120230...
+	Building git-annex-3.20120230...
+	Preprocessing executable 'git-annex' for git-annex-3.20120230...
+	
+	Git/Version.hs:11:18:
+	    Could not find module `Build.SysConfig':
+	      Use -v to see a list of the files searched for.
+	Failed to install git-annex-3.20120230
+	cabal: Error: some packages failed to install:
+	git-annex-3.20120230 failed during the building phase. The exception was:
+	ExitFailure 1
+
+"""]]
diff --git a/doc/install/fromsource/comment_31_4763b24a29627d55f465b9ea260ea7ec._comment b/doc/install/fromsource/comment_31_4763b24a29627d55f465b9ea260ea7ec._comment
new file mode 100644
index 0000000000..224c1dc19f
--- /dev/null
+++ b/doc/install/fromsource/comment_31_4763b24a29627d55f465b9ea260ea7ec._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="robohack"
+ ip="24.67.98.78"
+ subject="a different error trying to build from the git repo...."
+ date="2013-11-21T21:14:54Z"
+ content="""
+I'm using the ghc7.0 branch because Fink's GHC is still at 7.0.4....
+
+	$ cabal build                                
+	Building git-annex-3.20120523...
+	Preprocessing executable 'git-annex' for git-annex-3.20120523...
+	[ 78 of 163] Compiling Utility.Url      ( Utility/Url.hs, dist/build/git-annex/git-annex-tmp/Utility/Url.o )
+	
+	Utility/Url.hs:111:88:
+	    Couldn't match expected type `Maybe URI' with actual type `URI'
+	    In the second argument of `fromMaybe', namely
+	      `(newURI `relativeTo` u)'
+	    In the expression: fromMaybe newURI (newURI `relativeTo` u)
+	    In an equation for `newURI_abs':
+	        newURI_abs = fromMaybe newURI (newURI `relativeTo` u)
+
+"""]]
diff --git a/doc/install/fromsource/comment_32_1d34c294486c85b1149675fa5861ae35._comment b/doc/install/fromsource/comment_32_1d34c294486c85b1149675fa5861ae35._comment
new file mode 100644
index 0000000000..8b2ae67f92
--- /dev/null
+++ b/doc/install/fromsource/comment_32_1d34c294486c85b1149675fa5861ae35._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 32"
+ date="2013-11-22T16:27:36Z"
+ content="""
+@robohack, the ghc7.0 branch is not being maintained, and is so old I don't recommend it. To build it against current cabal you will probably need to version its dependency on network to an older version than 2.4.0. 
+
+Also, git-annex has not depended on pcre for a long time. But you're building thoroughly old version so get to trip over every bug that's been reported for the past 2 years..
+"""]]
diff --git a/doc/install/fromsource/comment_33_8d4dfc33cada6091c30d3a43ce404b8b._comment b/doc/install/fromsource/comment_33_8d4dfc33cada6091c30d3a43ce404b8b._comment
new file mode 100644
index 0000000000..8fab5a45f7
--- /dev/null
+++ b/doc/install/fromsource/comment_33_8d4dfc33cada6091c30d3a43ce404b8b._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
+ nickname="Matthias"
+ subject="Build failure"
+ date="2014-03-20T09:10:44Z"
+ content="""
+I followed the instructions and the invocation of
+
+    cabal install git-annex --bindir=$HOME/bin -f\"-assistant -webapp -webdav -pairing -xmpp -dns\"
+
+resulted in the following error:
+
+    Test.hs:107:41: Not in scope: `errMessage'
+    Failed to install git-annex-5.20140306
+    cabal: Error: some packages failed to install:
+    git-annex-5.20140306 failed during the building phase. The exception was:
+    ExitFailure 1
+
+I used the Haskell Platform for Mac OS X (10.8)
+
+"""]]
diff --git a/doc/install/fromsource/comment_34_38451e751add6daf479b559c4b6a7c61._comment b/doc/install/fromsource/comment_34_38451e751add6daf479b559c4b6a7c61._comment
new file mode 100644
index 0000000000..619e790129
--- /dev/null
+++ b/doc/install/fromsource/comment_34_38451e751add6daf479b559c4b6a7c61._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/a05bb829-932b-49f2-85a9-00dcda8b5e20"
+ nickname="Christian Pietsch"
+ subject="Re: Build failure"
+ date="2014-03-20T13:56:16Z"
+ content="""
+I get exactly the same error message as Matthias when attempting the minimal Cabal install on openSUSE 12.2 (x86_64) Linux.
+"""]]
diff --git a/doc/install/fromsource/comment_35_4d44e4531e6686bd340f26836ad40026._comment b/doc/install/fromsource/comment_35_4d44e4531e6686bd340f26836ad40026._comment
new file mode 100644
index 0000000000..899e4fc01c
--- /dev/null
+++ b/doc/install/fromsource/comment_35_4d44e4531e6686bd340f26836ad40026._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.102"
+ subject="comment 35"
+ date="2014-03-20T16:06:22Z"
+ content="""
+The `errMessage` build failure is due to a new version of optparse-applicative. I've added support for it in git master.
+"""]]
diff --git a/doc/install/fromsource/comment_36_2a095a5af53a356bd29abd22a9cb1bea._comment b/doc/install/fromsource/comment_36_2a095a5af53a356bd29abd22a9cb1bea._comment
new file mode 100644
index 0000000000..f6e0d85034
--- /dev/null
+++ b/doc/install/fromsource/comment_36_2a095a5af53a356bd29abd22a9cb1bea._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkNcHu5T1Pxzl-r2co9vf6SxXYWubv2P04"
+ nickname="Matthew"
+ subject="I did indeed get problems on Ubuntu 13.04"
+ date="2014-06-25T01:01:43Z"
+ content="""
+The issues I had were version mismatches when resolving dependencies of git-annex.
+
+It seems that when you install haskell-platform package with apt-get, it installs a bunch of haskell dependencies as apt packages, yet those aren't needed for any other system packages.  So some people here who complain about version mismatches might not have intended to install any Haskell libraries with apt, they just come along for the ride by default.
+
+I can't remember the exact ones, but I ended up uninstalling some of the stuff that gets auto-installed along with haskell-platform, and using cabal to build those.  Then all the git-annex dependencies worked.
+
+Why 13.04 in this day and age?  Using Zentyal as a home server/gateway, and it currently runs on 13.04.
+
+This method might not work if you installed other apt packages that _do_ need those apt-based Haskell libraries.   But if git-annex is all you need that uses the Haskell platform, might work.
+"""]]
diff --git a/doc/install/fromsource/comment_37_f33e1a4575dccc20b0d3d7c00e6db709._comment b/doc/install/fromsource/comment_37_f33e1a4575dccc20b0d3d7c00e6db709._comment
new file mode 100644
index 0000000000..daf7d0b5a8
--- /dev/null
+++ b/doc/install/fromsource/comment_37_f33e1a4575dccc20b0d3d7c00e6db709._comment
@@ -0,0 +1,69 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmveNWaFIL1zEehHr_0416bKBzsul5tGlE"
+ nickname="Daniel"
+ subject="Install fails horribly"
+ date="2014-07-10T23:11:51Z"
+ content="""
+```
+lyriondesktop:/home/zilti/tmp # cabal install c2hs
+Resolving dependencies...
+Configuring c2hs-0.17.2...
+Building c2hs-0.17.2...
+Preprocessing executable 'c2hs' for c2hs-0.17.2...
+[ 1 of 26] Compiling Data.DLists      ( src/Data/DLists.hs, dist/build/c2hs/c2hs-tmp/Data/DLists.o )
+[ 2 of 26] Compiling Control.StateTrans ( src/Control/StateTrans.hs, dist/build/c2hs/c2hs-tmp/Control/StateTrans.o )
+
+src/Control/StateTrans.hs:77:1: Warning:
+    Module `Prelude' does not export `catch'
+[ 3 of 26] Compiling Data.Errors      ( src/Data/Errors.hs, dist/build/c2hs/c2hs-tmp/Data/Errors.o )
+[ 4 of 26] Compiling Data.Attributes  ( src/Data/Attributes.hs, dist/build/c2hs/c2hs-tmp/Data/Attributes.o )
+[ 5 of 26] Compiling Text.Lexers      ( src/Text/Lexers.hs, dist/build/c2hs/c2hs-tmp/Text/Lexers.o )
+[ 6 of 26] Compiling Control.StateBase ( src/Control/StateBase.hs, dist/build/c2hs/c2hs-tmp/Control/StateBase.o )
+[ 7 of 26] Compiling Data.NameSpaces  ( src/Data/NameSpaces.hs, dist/build/c2hs/c2hs-tmp/Data/NameSpaces.o )
+[ 8 of 26] Compiling C2HS.C.Attrs     ( src/C2HS/C/Attrs.hs, dist/build/c2hs/c2hs-tmp/C2HS/C/Attrs.o )
+[ 9 of 26] Compiling C2HS.C.Builtin   ( src/C2HS/C/Builtin.hs, dist/build/c2hs/c2hs-tmp/C2HS/C/Builtin.o )
+[10 of 26] Compiling Paths_c2hs       ( dist/build/autogen/Paths_c2hs.hs, dist/build/c2hs/c2hs-tmp/Paths_c2hs.o )
+[11 of 26] Compiling C2HS.Config      ( src/C2HS/Config.hs, dist/build/c2hs/c2hs-tmp/C2HS/Config.o )
+[12 of 26] Compiling C2HS.Switches    ( src/C2HS/Switches.hs, dist/build/c2hs/c2hs-tmp/C2HS/Switches.o )
+[13 of 26] Compiling C2HS.Version     ( src/C2HS/Version.hs, dist/build/c2hs/c2hs-tmp/C2HS/Version.o )
+[14 of 26] Compiling System.CIO       ( src/System/CIO.hs, dist/build/c2hs/c2hs-tmp/System/CIO.o )
+[15 of 26] Compiling Control.State    ( src/Control/State.hs, dist/build/c2hs/c2hs-tmp/Control/State.o )
+[16 of 26] Compiling C2HS.State       ( src/C2HS/State.hs, dist/build/c2hs/c2hs-tmp/C2HS/State.o )
+[17 of 26] Compiling C2HS.CHS.Lexer   ( src/C2HS/CHS/Lexer.hs, dist/build/c2hs/c2hs-tmp/C2HS/CHS/Lexer.o )
+
+src/C2HS/CHS/Lexer.hs:612:16: Warning:
+    Defined but not used: `lexeme'
+[18 of 26] Compiling C2HS.CHS         ( src/C2HS/CHS.hs, dist/build/c2hs/c2hs-tmp/C2HS/CHS.o )
+[19 of 26] Compiling C2HS.Gen.Header  ( src/C2HS/Gen/Header.hs, dist/build/c2hs/c2hs-tmp/C2HS/Gen/Header.o )
+[20 of 26] Compiling C2HS.C.Trav      ( src/C2HS/C/Trav.hs, dist/build/c2hs/c2hs-tmp/C2HS/C/Trav.o )
+[21 of 26] Compiling C2HS.C.Names     ( src/C2HS/C/Names.hs, dist/build/c2hs/c2hs-tmp/C2HS/C/Names.o )
+[22 of 26] Compiling C2HS.C           ( src/C2HS/C.hs, dist/build/c2hs/c2hs-tmp/C2HS/C.o )
+[23 of 26] Compiling C2HS.Gen.Monad   ( src/C2HS/Gen/Monad.hs, dist/build/c2hs/c2hs-tmp/C2HS/Gen/Monad.o )
+
+src/C2HS/Gen/Monad.hs:227:10: Warning:
+    Orphan instance: instance Read Ident
+[24 of 26] Compiling C2HS.C.Info      ( src/C2HS/C/Info.hs, dist/build/c2hs/c2hs-tmp/C2HS/C/Info.o )
+[25 of 26] Compiling C2HS.Gen.Bind    ( src/C2HS/Gen/Bind.hs, dist/build/c2hs/c2hs-tmp/C2HS/Gen/Bind.o )
+
+src/C2HS/Gen/Bind.hs:971:43: Warning:
+    In the use of `posColumn' (imported from Language.C.Data.Position):
+    Deprecated: \"column number information is inaccurate in presence of macros - do not rely on it.\"
+
+src/C2HS/Gen/Bind.hs:789:10: Warning:
+    Orphan instance: instance Num CInteger
+[26 of 26] Compiling Main             ( src/Main.hs, dist/build/c2hs/c2hs-tmp/Main.o )
+Linking dist/build/c2hs/c2hs ...
+Installing executable(s) in /root/.cabal/bin
+Installed c2hs-0.17.2
+lyriondesktop:/home/zilti/tmp # cabal install git-annex
+Resolving dependencies...
+Configuring gnuidn-0.2.1...
+cabal: The program c2hs is required but it could not be found.
+Failed to install gnuidn-0.2.1
+cabal: Error: some packages failed to install:
+git-annex-5.20140709 depends on gnuidn-0.2.1 which failed to install.
+gnuidn-0.2.1 failed during the configure step. The exception was:
+ExitFailure 1
+network-protocol-xmpp-0.4.6 depends on gnuidn-0.2.1 which failed to install.
+```
+"""]]
diff --git a/doc/install/fromsource/comment_38_5c1e96221154a4ae4ebd636232044ced._comment b/doc/install/fromsource/comment_38_5c1e96221154a4ae4ebd636232044ced._comment
new file mode 100644
index 0000000000..7c44518d92
--- /dev/null
+++ b/doc/install/fromsource/comment_38_5c1e96221154a4ae4ebd636232044ced._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 38"
+ date="2014-07-11T18:30:55Z"
+ content="""
+@Daniel, I suggest you either follow the instuctions above, or if you don't want to follow the instructions, follow the error messages. :P In this case, the instructions say to do:
+
+> PATH=$HOME/bin:$PATH
+> cabal install c2hs --bindir=$HOME/bin
+
+Which is exactly to work around the problem that we can see in your transcript: `Installing executable(s) in /root/.cabal/bin` 
+
+Also, to reiterate the top of the page: If you are not comfortable tracking down and dealing with library build problems, installing git-annex with cabal is probably not the right choice for you!
+
+"""]]
diff --git a/doc/install/fromsource/comment_39_a86057d7e6d47113330f79e1812c3a5d._comment b/doc/install/fromsource/comment_39_a86057d7e6d47113330f79e1812c3a5d._comment
new file mode 100644
index 0000000000..7573b47849
--- /dev/null
+++ b/doc/install/fromsource/comment_39_a86057d7e6d47113330f79e1812c3a5d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkftzaCvV7EDKVDfJhsQZ3E1Vn-0db516w"
+ nickname="Edward"
+ subject="GHC 7.8 Issue"
+ date="2014-08-20T20:06:01Z"
+ content="""
+Just an FYI: I tried to \"cabal install --only-dependencies\" with GHC 7.8 and it fails because DAV-1.0.1 is pulling in lens-3.10.3 which is not compatible with GHC 7.8 due to changes in Typeable. 
+
+I don't have enough experience with cabal to figure out why it's not trying to use a newer version of lens.
+"""]]
diff --git a/doc/install/fromsource/comment_3_55bed050bdb768543dbe1b86edec057d._comment b/doc/install/fromsource/comment_3_55bed050bdb768543dbe1b86edec057d._comment
new file mode 100644
index 0000000000..7a53b2b647
--- /dev/null
+++ b/doc/install/fromsource/comment_3_55bed050bdb768543dbe1b86edec057d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 3"
+ date="2013-05-30T15:25:29Z"
+ content="""
+If you're installing git-annex with cabal, there is no need to install any haskell library packages with apt-get. That includes libghc-libxml-sax-dev and libghc-zlib-dev. Without those, the apt-get line may work to install the C libraries needed for cabal to install the haskell libraries. 
+
+However, see the the [[Ubuntu]] page for much easier ways to get git-annex installed.
+"""]]
diff --git a/doc/install/fromsource/comment_3_a3bf3ce57ea73515a059267f25b816eb._comment b/doc/install/fromsource/comment_3_a3bf3ce57ea73515a059267f25b816eb._comment
new file mode 100644
index 0000000000..1fade16c32
--- /dev/null
+++ b/doc/install/fromsource/comment_3_a3bf3ce57ea73515a059267f25b816eb._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="azul"
+ ip="91.36.173.120"
+ subject="c2hs required for cabal to install dependencies"
+ date="2014-06-20T06:35:35Z"
+ content="""
+Next thing i ran into was missing c2hs.
+So
+`apt-get install c2hs` before running the cabal install otherwise...
+
+<pre>
+$ cabal install git-annex --only-dependencies
+Resolving dependencies...
+Configuring gnuidn-0.2.1...
+cabal: The program c2hs is required but it could not be found.
+Failed to install gnuidn-0.2.1
+cabal: Error: some packages failed to install:
+gnuidn-0.2.1 failed during the configure step. The exception was:
+ExitFailure 1
+network-protocol-xmpp-0.4.6 depends on gnuidn-0.2.1 which failed to install.
+</pre>
+
+"""]]
diff --git a/doc/install/fromsource/comment_45_d9cccbb9620cc8218e72b5380fd89a05._comment b/doc/install/fromsource/comment_45_d9cccbb9620cc8218e72b5380fd89a05._comment
new file mode 100644
index 0000000000..e8666b04e5
--- /dev/null
+++ b/doc/install/fromsource/comment_45_d9cccbb9620cc8218e72b5380fd89a05._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="no need for c2hs"
+ date="2014-09-16T19:28:09Z"
+ content="""
+The c2hs mentioned in some of the above comments is not needed any longer; ghc 7.6.3 and newer come with a hsc2hs command that is used.
+"""]]
diff --git a/doc/install/fromsource/comment_46_954de34275d33bc4590927f911761563._comment b/doc/install/fromsource/comment_46_954de34275d33bc4590927f911761563._comment
new file mode 100644
index 0000000000..c0f283f4ba
--- /dev/null
+++ b/doc/install/fromsource/comment_46_954de34275d33bc4590927f911761563._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 46"
+ date="2014-09-16T19:33:11Z"
+ content="""
+Britt's comment is spot on, but git-annex tries pretty hard to work with lots of older versions of haskell libraries, as well as the latest and greatest. So it should be ok to install haskell libraries with apt-get and use them to build git-annex, as the (revised) instructions above show.
+
+What tends not to work so well is use apt-get to install older versions of haskell libraries and then cabal install on top to add newer stuff. Gets complicated and I'd recommend not going there. The instructions above show using either apt-get or cabal to install the haskell libraries, but not both.
+"""]]
diff --git a/doc/install/fromsource/comment_47_6de25c1e450e1e3b1d18d2c76235ccb8._comment b/doc/install/fromsource/comment_47_6de25c1e450e1e3b1d18d2c76235ccb8._comment
new file mode 100644
index 0000000000..2edb95e215
--- /dev/null
+++ b/doc/install/fromsource/comment_47_6de25c1e450e1e3b1d18d2c76235ccb8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="thnetos"
+ subject="Where to start reading the source code?"
+ date="2014-12-15T22:04:06Z"
+ content="""
+Do you have any recommendations for the overall haskell architecture of the project? Where to start looking if I want to read through the source code?
+"""]]
diff --git a/doc/install/fromsource/comment_48_9c08300c5d172ba9223042a00c8acb2b._comment b/doc/install/fromsource/comment_48_9c08300c5d172ba9223042a00c8acb2b._comment
new file mode 100644
index 0000000000..4e58da1bb4
--- /dev/null
+++ b/doc/install/fromsource/comment_48_9c08300c5d172ba9223042a00c8acb2b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""where to start reading the source code"""
+ date="2015-01-05T20:58:50Z"
+ content="""
+@thnetos, great question!
+
+Annex.hs is a key starting place, as it defines git-annex's main monad.
+If you like learning code bases bottom-up, Types/* has files for
+the main data types used in git-annex, such as Key and UUID and Remote and
+GitConfig.
+
+Command/* gets you the implementation of any particular git-annex command
+you are interested in. Or Remote/* for any particular special remote.
+
+I recommend running "make tags" and then your editor should be able to use
+the tags file to bounce around in the source code.
+"""]]
diff --git a/doc/install/fromsource/comment_49_c8370525547b435d963a2c1192a21124._comment b/doc/install/fromsource/comment_49_c8370525547b435d963a2c1192a21124._comment
new file mode 100644
index 0000000000..c0561861ed
--- /dev/null
+++ b/doc/install/fromsource/comment_49_c8370525547b435d963a2c1192a21124._comment
@@ -0,0 +1,93 @@
+[[!comment format=mdwn
+ username="dave@2ab82f485adf7e2ce787066e35f5f9789bff430b"
+ nickname="dave"
+ subject="apt-get build-dep fails"
+ date="2015-07-09T00:07:32Z"
+ content="""
+    hobbes@namagiri:~/src$ sudo apt-get build-dep git-annex
+    Reading package lists... Done
+    Building dependency tree       
+    Reading state information... Done
+    E: Build-Depends dependency for git-annex cannot be satisfied because the package libghc-hamlet-dev cannot be found
+
+Hmm, deprecated in favor of libghc-shakespear-dev, according to http://hackage.haskell.org/package/hamlet ...
+
+    hobbes@namagiri:~/src/apt-get-source-git-annex$ grep -iR build-depends.*hamlet|tr , \\n
+    git-annex_5.20141125.dsc:Build-Depends: debhelper (>= 9)
+     ghc (>= 7.4)
+     cabal-install
+     libghc-mtl-dev (>= 2.1.1)
+     libghc-missingh-dev
+     libghc-data-default-dev
+     libghc-hslogger-dev
+     libghc-pcre-light-dev
+     libghc-sha-dev
+     libghc-cryptohash-dev
+     libghc-dataenc-dev
+     libghc-utf8-string-dev
+     libghc-hs3-dev (>= 0.5.6)
+     libghc-dav-dev (>= 1.0) [amd64 i386 kfreebsd-amd64 kfreebsd-i386 powerpc]
+     libghc-quickcheck2-dev
+     libghc-monad-control-dev (>= 0.3)
+     libghc-exceptions-dev (>= 0.6)
+     libghc-transformers-dev
+     libghc-unix-compat-dev
+     libghc-dlist-dev
+     libghc-uuid-dev
+     libghc-json-dev
+     libghc-aeson-dev
+     libghc-ifelse-dev
+     libghc-bloomfilter-dev
+     libghc-edit-distance-dev
+     libghc-hinotify-dev [linux-any]
+     libghc-stm-dev (>= 2.3)
+     libghc-dbus-dev (>= 0.10.3) [linux-any]
+     libghc-fdo-notify-dev (>= 0.3) [linux-any]
+     libghc-yesod-dev [i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc]
+     libghc-yesod-static-dev [i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc]
+     libghc-yesod-default-dev [i386 amd64 kfreebsd-amd64 powerpc]
+     libghc-hamlet-dev [i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc]
+     libghc-shakespeare-dev [i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc]
+     libghc-clientsession-dev [i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc]
+     libghc-warp-dev [i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc]
+     libghc-warp-tls-dev [i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc]
+     libghc-wai-dev [i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc]
+     libghc-wai-extra-dev [i386 amd64 kfreebsd-i386 kfreebsd-amd64 powerpc]
+     libghc-securemem-dev
+     libghc-byteable-dev
+     libghc-dns-dev
+     libghc-case-insensitive-dev
+     libghc-http-types-dev
+     libghc-http-conduit-dev
+     libghc-blaze-builder-dev
+     libghc-crypto-api-dev
+     libghc-network-multicast-dev
+     libghc-network-info-dev [linux-any kfreebsd-any]
+     libghc-safesemaphore-dev
+     libghc-network-protocol-xmpp-dev (>= 0.4.3-1+b1)
+     libghc-gnutls-dev (>= 0.1.4)
+     libghc-xml-types-dev
+     libghc-async-dev
+     libghc-feed-dev (>= 0.3.9.2)
+     libghc-regex-tdfa-dev [!mipsel !s390]
+     libghc-regex-compat-dev [mipsel s390]
+     libghc-tasty-dev (>= 0.7) [!sparc]
+     libghc-tasty-hunit-dev [!sparc]
+     libghc-tasty-quickcheck-dev [!sparc]
+     libghc-tasty-rerun-dev [!sparc]
+     libghc-optparse-applicative-dev [!sparc]
+     lsof [!kfreebsd-i386 !kfreebsd-amd64 !hurd-any]
+     ikiwiki
+     perlmagick
+     git (>= 1:2.0)
+     rsync
+     wget
+     curl
+     openssh-client
+     git-remote-gcrypt (>= 0.20130908-6)
+     llvm-3.4 [armel armhf]
+    
+I think that's the bug, right there: *git-annex_5.20141125.dsc*.
+
+I hope this helps.
+"""]]
diff --git a/doc/install/fromsource/comment_4_2ff7f8a3b03bea7e860248829d595bd1._comment b/doc/install/fromsource/comment_4_2ff7f8a3b03bea7e860248829d595bd1._comment
new file mode 100644
index 0000000000..4a04303ced
--- /dev/null
+++ b/doc/install/fromsource/comment_4_2ff7f8a3b03bea7e860248829d595bd1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="Re: Comment 3"
+ date="2013-05-30T15:48:44Z"
+ content="""
+@Joey Many thanks.
+I am new to Haskell (vaguely looked at it with DARCS) and git-annex.
+After installing with apt-get on Ubuntu 12.04 LTS I found webapp was missing, hence have come here.
+I am going through the correct steps now, it should be awesome when done.
+
+This seems to be a long build process (still going on my old laptop, much longer than apt-get).
+Ubuntu git-annex packages from 13.10 Saucy I think are updated to include webapp.
+"""]]
diff --git a/doc/install/fromsource/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment b/doc/install/fromsource/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment
new file mode 100644
index 0000000000..66615dac78
--- /dev/null
+++ b/doc/install/fromsource/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 4"
+ date="2014-08-24T11:53:11Z"
+ content="""
+@azul, thanks for hints, but it still fails. No wonders though - this is Haskell, kids.
+
+~~~~
+$ cabal install git-annex --only-dependencies
+Resolving dependencies...
+cabal: Could not resolve dependencies:
+trying: git-annex-5.20140817
+trying: git-annex-5.20140817:+webapp
+trying: git-annex-5.20140817:+s3
+trying: git-annex-5.20140817:+dns
+trying: dns-1.4.3
+trying: yesod-1.2.6.1
+trying: yesod-auth-1.3.4.2
+trying: http-client-0.3.7.1
+trying: http-client-0.3.7.1:+network-uri
+trying: hS3-0.5.8
+trying: hxt-9.3.1.6
+trying: hxt-9.3.1.6:-network-uri
+rejecting: network-2.6.0.1, 2.6.0.0 (conflict: hxt-9.3.1.6:network-uri =>
+network>=2.4 && <2.6)
+rejecting: network-2.5.0.0, 2.4.2.3, 2.4.2.2, 2.4.2.1, 2.4.2.0, 2.4.1.2,
+2.4.1.1, 2.4.1.0, 2.4.0.1, 2.4.0.0, 2.3.2.0, 2.3.1.1, 2.3.1.0, 2.3.0.14,
+2.3.0.13, 2.3.0.12, 2.3.0.11, 2.3.0.10, 2.3.0.9, 2.3.0.8, 2.3.0.7, 2.3.0.6,
+2.3.0.5, 2.3.0.4, 2.3.0.3, 2.3.0.2, 2.3.0.1, 2.3 (conflict:
+http-client-0.3.7.1:network-uri => network>=2.6)
+rejecting: network-2.2.3.1, 2.2.3, 2.2.1.10, 2.2.1.9, 2.2.1.8, 2.2.1.7,
+2.2.1.6, 2.2.1.5, 2.2.1.4, 2.2.1.3, 2.2.1.2, 2.2.1.1, 2.2.1, 2.2.0.1, 2.2.0.0,
+2.1.0.0, 2.0 (conflict: dns => network>=2.3)
+~~~~
+
+"""]]
diff --git a/doc/install/fromsource/comment_50_c1ce6084ba1e96afa30e18f0f6433aa4._comment b/doc/install/fromsource/comment_50_c1ce6084ba1e96afa30e18f0f6433aa4._comment
new file mode 100644
index 0000000000..2e51353766
--- /dev/null
+++ b/doc/install/fromsource/comment_50_c1ce6084ba1e96afa30e18f0f6433aa4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 50"""
+ date="2015-07-15T15:54:15Z"
+ content="""
+Yes, Debian has a by now very outdated version of git-annex.
+
+You can clone git-annex's git repo and build a debian package from there;
+it's been updated for these changes.
+"""]]
diff --git a/doc/install/fromsource/comment_51_514bac1020c4227a23380d1675184fc7._comment b/doc/install/fromsource/comment_51_514bac1020c4227a23380d1675184fc7._comment
new file mode 100644
index 0000000000..21cf6e739f
--- /dev/null
+++ b/doc/install/fromsource/comment_51_514bac1020c4227a23380d1675184fc7._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="reyman64@f52a9d695f5dc1d5b0788fbb9877e9401fae7421"
+ nickname="reyman64"
+ subject="Error with Url.hs"
+ date="2015-11-06T13:37:41Z"
+ content="""
+Hi,
+With minimal compilation for git-annex-5.20151102.1
+and
+Cabal version is : 1.22.4.0
+Ghc version is : 7.10.2 
+
+I have an error on url.hs:45
+binary operator not found before lexical element \" ( \"
+
+any idea ?
+
+"""]]
diff --git a/doc/install/fromsource/comment_52_df7d36e4d169fbc4199026d7af1aa581._comment b/doc/install/fromsource/comment_52_df7d36e4d169fbc4199026d7af1aa581._comment
new file mode 100644
index 0000000000..42a519cf96
--- /dev/null
+++ b/doc/install/fromsource/comment_52_df7d36e4d169fbc4199026d7af1aa581._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 52"""
+ date="2015-11-06T16:48:16Z"
+ content="""
+@reyman64 missing dependency on http-client in that configuration.
+I've fixed this in git.
+"""]]
diff --git a/doc/install/fromsource/comment_53_e4bb31024aa4a317be2f45667b6d6f9f._comment b/doc/install/fromsource/comment_53_e4bb31024aa4a317be2f45667b6d6f9f._comment
new file mode 100644
index 0000000000..0a65aac6bf
--- /dev/null
+++ b/doc/install/fromsource/comment_53_e4bb31024aa4a317be2f45667b6d6f9f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="reyman64@f52a9d695f5dc1d5b0788fbb9877e9401fae7421"
+ nickname="reyman64"
+ subject="comment 53"
+ date="2015-11-06T17:07:21Z"
+ content="""
+Great that works now, thanks :)
+"""]]
diff --git a/doc/install/fromsource/comment_54_d7fabada8101596954ed7e401a8c460b._comment b/doc/install/fromsource/comment_54_d7fabada8101596954ed7e401a8c460b._comment
new file mode 100644
index 0000000000..24a03d070d
--- /dev/null
+++ b/doc/install/fromsource/comment_54_d7fabada8101596954ed7e401a8c460b._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="reyman64@f52a9d695f5dc1d5b0788fbb9877e9401fae7421"
+ nickname="reyman64"
+ subject="Error on compile"
+ date="2016-01-20T22:50:01Z"
+ content="""
+Hi, i have an error with last pulled version on my system : 
+
+[17 of 23] Compiling Text.Feed.Constructor ( src/Text/Feed/Constructor.hs, dist/build/Text/Feed/Constructor.o )
+
+src/Text/Feed/Constructor.hs:131:5: Warning:
+    Pattern match(es) are non-exhaustive
+    In a case alternative: Patterns not matched: XMLFeed _
+[18 of 23] Compiling Text.Feed.Export ( src/Text/Feed/Export.hs, dist/build/Text/Feed/Export.o )
+[19 of 23] Compiling Text.Feed.Import ( src/Text/Feed/Import.hs, dist/build/Text/Feed/Import.o )
+[20 of 23] Compiling Text.Feed.Util   ( src/Text/Feed/Util.hs, dist/build/Text/Feed/Util.o )
+[21 of 23] Compiling Text.Feed.Query  ( src/Text/Feed/Query.hs, dist/build/Text/Feed/Query.o )
+
+src/Text/Feed/Query.hs:66:53:
+    Module ‘Data.Time.Locale.Compat’ does not export ‘rfc822DateFormat’
+
+src/Text/Feed/Query.hs:66:71:
+    Module
+    ‘Data.Time.Locale.Compat’
+    does not export
+    ‘iso8601DateFormat’
+cabal: Error: some packages failed to install:
+feed-0.3.11.1 failed during the building phase. The exception was:
+ExitFailure 1
+
+"""]]
diff --git a/doc/install/fromsource/comment_55_0592c3d36ab569cd777009a491e25ba2._comment b/doc/install/fromsource/comment_55_0592c3d36ab569cd777009a491e25ba2._comment
new file mode 100644
index 0000000000..e0f375d6d6
--- /dev/null
+++ b/doc/install/fromsource/comment_55_0592c3d36ab569cd777009a491e25ba2._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 55"""
+ date="2016-01-22T15:56:01Z"
+ content="""
+@reyman64, that's a failure to build the feed package, not git-annex.
+See <http://hackage.haskell.org/package/feed> for a pointer to its bug
+tracker.
+
+The best way to avoid running into such problems is to use stack rather
+than cabal to build git-annex, since that avoids using bleeding-edge and
+thus frequently broken versions of the dependencies.
+"""]]
diff --git a/doc/install/fromsource/comment_57_13a198daa871e001b02b9df2e8d7c446._comment b/doc/install/fromsource/comment_57_13a198daa871e001b02b9df2e8d7c446._comment
new file mode 100644
index 0000000000..221b765aa0
--- /dev/null
+++ b/doc/install/fromsource/comment_57_13a198daa871e001b02b9df2e8d7c446._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 57"""
+ date="2016-01-26T18:50:30Z"
+ content="""
+Check out the tag for the release of git-annex that you want to build to
+avoid building from master, which may not be ready. In this case, I was
+adjusting some build flags this morning and hadn't tried a stack build yet.
+
+git-annex-shell is just a symlink to git-annex. I guess that stack install 
+bypasses the code that makes cabal install set up that symlink. You can make
+the symlink yourself I suppose.
+"""]]
diff --git a/doc/install/fromsource/comment_57_efac370d382fc79e1f207e8090e0f06b._comment b/doc/install/fromsource/comment_57_efac370d382fc79e1f207e8090e0f06b._comment
new file mode 100644
index 0000000000..286d609329
--- /dev/null
+++ b/doc/install/fromsource/comment_57_efac370d382fc79e1f207e8090e0f06b._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="reyman64@740e43250854ada1b8484b3bc44b53be03367d70"
+ nickname="reyman64"
+ subject="problem with latest pull and stack"
+ date="2016-01-26T16:49:05Z"
+ content="""
+
+Is there a tag in github to download the latest dev build  (if i want to compile a build with v6 repository for example) ? 
+
+Because after a recent `git pull` (commit `65f44423d1b9407a9c0e4a2b2e7e24b701f6dc32`
+ ) on master, i have this error on `stack install` :
+
+Also, `git-annex-shell` is not created by stack install, is it normal ? 
+
+```
+[reyman64@web504 git-annex]$ stack install git-annex --local-bin-path /home/reyman64/bin
+Invalid flag specification:
+- Package 'git-annex' does not define the following flags (specified in stack.yaml):
+  feed
+  quvi
+  tahoe
+  webapp-secure
+- Flags defined by package 'git-annex':
+  git-annex:android
+  git-annex:androidsplice
+  git-annex:assistant
+  git-annex:benchmark
+  git-annex:concurrentoutput
+  git-annex:cryptonite
+  git-annex:dns
+  git-annex:ekg
+  git-annex:network-uri
+  git-annex:pairing
+  git-annex:production
+  git-annex:s3
+  git-annex:tdfa
+  git-annex:testsuite
+  git-annex:torrentparser
+  git-annex:webapp
+  git-annex:webdav
+```
+
+Best,
+SR.
+"""]]
diff --git a/doc/install/fromsource/comment_58_64b44da5ec93fe4f50ad8b856823558d._comment b/doc/install/fromsource/comment_58_64b44da5ec93fe4f50ad8b856823558d._comment
new file mode 100644
index 0000000000..be94ec1a1a
--- /dev/null
+++ b/doc/install/fromsource/comment_58_64b44da5ec93fe4f50ad8b856823558d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="reyman64@740e43250854ada1b8484b3bc44b53be03367d70"
+ nickname="reyman64"
+ subject="comment 58"
+ date="2016-01-26T19:09:05Z"
+ content="""
+Ok thanks for your answer :) 
+
+"""]]
diff --git a/doc/install/fromsource/comment_59_4ef618a5de9b86ffa54ae849cbb329bb._comment b/doc/install/fromsource/comment_59_4ef618a5de9b86ffa54ae849cbb329bb._comment
new file mode 100644
index 0000000000..7eee42ef31
--- /dev/null
+++ b/doc/install/fromsource/comment_59_4ef618a5de9b86ffa54ae849cbb329bb._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="dave@2ab82f485adf7e2ce787066e35f5f9789bff430b"
+ nickname="dave"
+ subject="Build failure"
+ date="2016-09-07T18:25:19Z"
+ content="""
+I cloned the `git-annex` repo from github.com and checked out the `6.20160907` tag.
+
+Then I invoked `stack install` and that ended with the following.  Note, this is on Windows.
+
+    Configuring concurrent-output-1.7.6...
+    Building concurrent-output-1.7.6...
+    Preprocessing library concurrent-output-1.7.6...
+    [1 of 7] Compiling Utility.Data     ( Utility\Data.hs, .stack-work\dist\2672c1f3\build\Utility\Data.o )
+    [2 of 7] Compiling Utility.Exception ( Utility\Exception.hs, .stack-work\dist\2672c1f3\build\Utility\Exception.o )
+    [3 of 7] Compiling Utility.Monad    ( Utility\Monad.hs, .stack-work\dist\2672c1f3\build\Utility\Monad.o )
+    [4 of 7] Compiling System.Console.Concurrent.Internal ( System\Console\Concurrent\Internal.hs, .stack-work\dist\2672c1f3\build\System\Console\Concurrent\Internal.o )
+    [5 of 7] Compiling System.Console.Concurrent ( System\Console\Concurrent.hs, .stack-work\dist\2672c1f3\build\System\Console\Concurrent.o )
+    [6 of 7] Compiling System.Console.Regions ( System\Console\Regions.hs, .stack-work\dist\2672c1f3\build\System\Console\Regions.o )
+    
+    System\Console\Regions.hs:559:46: Warning:
+        Defined but not used: `oldt'
+    
+    System\Console\Regions.hs:719:1: Warning:
+        Defined but not used: `calcLineUpdate'
+    
+    System\Console\Regions.hs:746:1: Warning:
+        Defined but not used: `advanceLine'
+    
+    System\Console\Regions.hs:773:1: Warning:
+        Defined but not used: `isSGR'
+    
+    System\Console\Regions.hs:777:1: Warning:
+        Defined but not used: `genLineUpdate'
+    
+    System\Console\Regions.hs:791:1: Warning:
+        Defined but not used: `optimiseLineUpdate'
+    
+    System\Console\Regions.hs:807:1: Warning:
+        Defined but not used: `combineSGR'
+    
+    System\Console\Regions.hs:817:1: Warning:
+        Defined but not used: `combineSGRCodes'
+    [7 of 7] Compiling System.Process.Concurrent ( System\Process\Concurrent.hs, .stack-work\dist\2672c1f3\build\System\Process\Concurrent.o )
+    
+    System\Process\Concurrent.hs:24:49:
+        Not in scope: `createProcessConcurrent'
+    
+"""]]
diff --git a/doc/install/fromsource/comment_5_4aea55dc5b24d84e0953382ccfea1a01._comment b/doc/install/fromsource/comment_5_4aea55dc5b24d84e0953382ccfea1a01._comment
new file mode 100644
index 0000000000..c14b75bc08
--- /dev/null
+++ b/doc/install/fromsource/comment_5_4aea55dc5b24d84e0953382ccfea1a01._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmfEGTjv4GsWkSG2lpuBitRDxVkml7yEQg"
+ nickname="Britt"
+ subject="Installing debs"
+ date="2014-09-16T02:16:28Z"
+ content="""
+@azul - the problem with installing dependencies from apt-get is that the Ubuntu haskell packages are rather old. It shouldn't be this way (and it has gotten a LOT better - I suggest installing the newest version of the Haskell Platform that you can), but often cabal will complain about a package it is unable to install because it failed on the install of that package's dependencies. You should try to cabal install $FAILED_DEPENDENCY (not an actual env variable), and you will often get more informative error messages - some packages require non-haskell dependencies (take gtk3, for instance) which cabal doesn't know how to handle at this point, because that would require some cross platform foo (cabal install runs on Windows and OSX, which don't have native package managers at all). 
+
+@Paul - It looks like you ran into a bug, because http-client no longer depends on network>=2.6, it now can take network 2.4 - 2.6 or 2.6 or greater. If you try again it should work. 
+
+Please don't be put off by haskell because of things like this - git annex is a very large and complicated project, and developing on large projects such as this pretty much require you to have pretty recent versions of all haskell packages. I really suggest you take a look at this book http://learnyouahaskell.com/introduction. Haskell is a beautiful language and it doesn't have to be esoteric, academic, or difficult at all. It's obvious since you are attempting to build this from source that you are either interested in haskell or you are only interested in the development of git-annex. Either way, it would behoove you to read that book. It is short, full of great examples, and it even has pleasant illustrations. It may look like a children's book, but by the end of it you will know how to use all of the major monads (you may not know what a monad is, but that isn't really that important anyway - you just need to know how they are used).
+"""]]
diff --git a/doc/install/fromsource/comment_5_8789fc27466714faa5a3a7a6b8ec6e5d._comment b/doc/install/fromsource/comment_5_8789fc27466714faa5a3a7a6b8ec6e5d._comment
new file mode 100644
index 0000000000..59bdbdd13c
--- /dev/null
+++ b/doc/install/fromsource/comment_5_8789fc27466714faa5a3a7a6b8ec6e5d._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="Re: Comment 3"
+ date="2013-05-30T16:29:12Z"
+ content="""
+At the end of the build I got these errors:
+Registering yesod-static-1.1.2.3...
+Installing library in /home/nrb/.cabal/lib/yesod-static-1.1.2.3/ghc-7.4.1
+Registering yesod-static-1.1.2.3...
+cabal: Error: some packages failed to install:
+c2hs-0.16.4 depends on language-c-0.3.2.1 which failed to install.
+dbus-0.10.4 depends on libxml-sax-0.7.4 which failed to install.
+git-annex-4.20130521.2 depends on libxml-sax-0.7.4 which failed to install.
+language-c-0.3.2.1 failed during the configure step. The exception was:
+ExitFailure 1
+libxml-sax-0.7.4 failed during the configure step. The exception was:
+ExitFailure 1
+network-protocol-xmpp-0.4.5 depends on libxml-sax-0.7.4 which failed to
+install.
+
+One way I could fix this myself is to put together a VM with 13.10 or Debian in it and work inside that.
+Or if I can get help to fix my issues here that would be great ;)
+"""]]
diff --git a/doc/install/fromsource/comment_60_55ec2dcb5e1b5e272fdd53aa063bc162._comment b/doc/install/fromsource/comment_60_55ec2dcb5e1b5e272fdd53aa063bc162._comment
new file mode 100644
index 0000000000..4cf3a9beb3
--- /dev/null
+++ b/doc/install/fromsource/comment_60_55ec2dcb5e1b5e272fdd53aa063bc162._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="dave@2ab82f485adf7e2ce787066e35f5f9789bff430b"
+ nickname="dave"
+ subject="This seems relevant to the comment directly previous this one."
+ date="2016-09-07T20:27:48Z"
+ content="""
+https://git.joeyh.name/?p=concurrent-output.git;a=blobdiff;f=System/Console/Concurrent.hs;h=d8cea13a3816eba44f8d70a855db21e2dd58a27d;hp=124476379264a94e44b51eb1407fd7d80d0348e7;hb=HEAD;hpb=021358c5a033335e05ec9cff72107ab401217c30
+"""]]
diff --git a/doc/install/fromsource/comment_61_7fb2a70b6d39ad95ee701a99b9e19961._comment b/doc/install/fromsource/comment_61_7fb2a70b6d39ad95ee701a99b9e19961._comment
new file mode 100644
index 0000000000..d0c06f6d42
--- /dev/null
+++ b/doc/install/fromsource/comment_61_7fb2a70b6d39ad95ee701a99b9e19961._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="dave@2ab82f485adf7e2ce787066e35f5f9789bff430b"
+ nickname="dave"
+ subject="concurrent-output-1.7.7"
+ date="2016-09-08T17:41:28Z"
+ content="""
+Hi.  `concurrent-output-1.7.7` is not present in resolver `lts-5.18`.
+"""]]
diff --git a/doc/install/fromsource/comment_62_4cf71016c3b42ec972760a938031cbf9._comment b/doc/install/fromsource/comment_62_4cf71016c3b42ec972760a938031cbf9._comment
new file mode 100644
index 0000000000..05d15326dd
--- /dev/null
+++ b/doc/install/fromsource/comment_62_4cf71016c3b42ec972760a938031cbf9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 62"""
+ date="2016-09-21T17:21:58Z"
+ content="""
+In the meantime, the stack.yaml has been updated to use lts-7.0, which
+includes concurrent-output-1.7.7, so that should solve that.
+"""]]
diff --git a/doc/install/fromsource/comment_63_dddfc7e7d2fa09008f538abde3213b45._comment b/doc/install/fromsource/comment_63_dddfc7e7d2fa09008f538abde3213b45._comment
new file mode 100644
index 0000000000..f7858d6ac9
--- /dev/null
+++ b/doc/install/fromsource/comment_63_dddfc7e7d2fa09008f538abde3213b45._comment
@@ -0,0 +1,63 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ subject="Build on Debian 7.11 AMD64"
+ date="2016-10-10T06:43:49Z"
+ content="""
+Hello,
+
+Following https://git-annex.branchable.com/install/fromsource/ \"building from source on Debian\" succeeds on Xubuntu 16.04 but fails on Debian 7.11.
+First observed on recent commit `ade6ab4` (the one that was used on Xubuntu 16.04) then failed the same way with most recent commit `f244d94` and for tag `debian/6.20160719-1`.
+
+Haskell context was installed on the machine specifically to build git-annex, so there should not be any extraneous package.
+
+Surprisingly, \"make\" and \"cabal\" output rather different messages.
+
+```
+make
+
+if [ \"cabal\" = ./Setup ]; then ghc --make Setup; fi
+if [ \"cabal\" = stack ]; then \
+		cabal build ; \
+	else \
+		cabal configure --ghc-options=\"\"; \
+	fi
+Warning: git-annex.cabal: Ignoring unknown section type: custom-setup
+Resolving dependencies...
+Warning: git-annex.cabal: Ignoring unknown section type: custom-setup
+
+Utility/Exception.hs:29:18:
+    Could not find module `Control.Monad.Catch'
+    Perhaps you meant
+      Control.Monad.CatchIO (from MonadCatchIO-mtl-0.3.0.4)
+      Control.Monad.Base (from transformers-base-0.4.1)
+      Control.Monad.Cont (from mtl-2.1.1)
+    Use -v to see a list of the files searched for.
+make: *** [Build/SysConfig.hs] Erreur 1
+```
+
+```
+cabal install
+
+Warning: git-annex.cabal: Ignoring unknown section type: custom-setup
+Resolving dependencies...
+cabal: Could not resolve dependencies:
+next goal: git-annex (user goal)
+rejecting: git-annex-6.20160923, 6.20160907, 6.20160808 (global constraint
+requires ==6.20160619)
+trying: git-annex-6.20160619
+trying: base-4.5.0.0/installed-40b... (dependency of git-annex-6.20160619)
+trying: git-annex-6.20160619:+concurrentoutput
+next goal: concurrent-output (dependency of
+git-annex-6.20160619:+concurrentoutput)
+rejecting: concurrent-output-1.7.7, 1.7.6, 1.7.5, 1.7.4, 1.7.3, 1.7.2, 1.7.1,
+1.7.0, 1.6.1, 1.6.0 (conflict: base==4.5.0.0/installed-40b...,
+concurrent-output => base(>=4.6))
+rejecting: concurrent-output-1.5.0, 1.4.0, 1.3.0, 1.2.0, 1.1.0, 1.0.1, 1.0.0
+(conflict: git-annex-6.20160619:concurrentoutput => concurrent-output(>=1.6))
+```
+
+Any hint? When succeeding the pair of machines will be my first remote ssh-based repo. I need a recent enough build for [mixed content repository](https://git-annex.branchable.com/tips/largefiles/) that would automatically put some types of files in regular git and some other types in annex.
+Thanks.
+
+"""]]
diff --git a/doc/install/fromsource/comment_64_c3195cbc42058593ea6ca9d2eaaf9722._comment b/doc/install/fromsource/comment_64_c3195cbc42058593ea6ca9d2eaaf9722._comment
new file mode 100644
index 0000000000..569a51d0b6
--- /dev/null
+++ b/doc/install/fromsource/comment_64_c3195cbc42058593ea6ca9d2eaaf9722._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 64"""
+ date="2016-10-17T19:33:29Z"
+ content="""
+@stephane-gourichon, Control.Monad.Catch is in the haskell exceptions
+package, which is a dependency of git-annex. I don't know why it
+is failing to find it on your system.
+
+You appear to be in some variety of cabal hell; you probably need to delete
+your ~/.cabal and ~/.ghc and start over.
+
+Also, Debian 7.11 is quite old; to follow the "building from source on
+Debian" you need Debian unstable, testing, or sometimes stable
+(doesn't work currently); not oldstable.
+"""]]
diff --git a/doc/install/fromsource/comment_65_663426a5014e5a38d477fb6fed411c17._comment b/doc/install/fromsource/comment_65_663426a5014e5a38d477fb6fed411c17._comment
new file mode 100644
index 0000000000..57760fc0c1
--- /dev/null
+++ b/doc/install/fromsource/comment_65_663426a5014e5a38d477fb6fed411c17._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="florian-git-annex@90936f45daa5a57ed4b867f7ebc35e23acad1a08"
+ nickname="florian-git-annex"
+ avatar="http://cdn.libravatar.org/avatar/87a7fe93a5233ee03438752229aa14f6"
+ subject="apt-get build-dep git-annex problem on Raspbian"
+ date="2017-06-01T07:09:58Z"
+ content="""
+I tried to build git-annex on a current raspbian system. Executing \"apt-get build-dep git-annex\" I get the following error:
+
+    Reading package lists... Done
+    Building dependency tree       
+    Reading state information... Done
+    E: Build-Depends dependency for git-annex cannot be satisfied because the package libghc-yesod-dev cannot be found
+
+
+"""]]
diff --git a/doc/install/fromsource/comment_66_849c4c2cfc34991c13d55495e391cce3._comment b/doc/install/fromsource/comment_66_849c4c2cfc34991c13d55495e391cce3._comment
new file mode 100644
index 0000000000..3f7dcacad7
--- /dev/null
+++ b/doc/install/fromsource/comment_66_849c4c2cfc34991c13d55495e391cce3._comment
@@ -0,0 +1,78 @@
+[[!comment format=mdwn
+ username="erics"
+ avatar="http://cdn.libravatar.org/avatar/6e5f74c742128e5d98fd672ed6ea4865"
+ subject="Adventures with stack"
+ date="2017-11-01T19:19:51Z"
+ content="""
+I've played with git-annex before, but never used it seriously.  Building it from source for the first time, to get the latest and greatest, I ran into a few stumbling blocks.  I've got them sorted out now; this is to (a) document them, and (b) ask which if any of these should be considered bugs -- in which case I'll file bug reports about them.
+
+I'm a complete Haskell newbie, and don't want to dive into that right now, so I'm using *stack*, since I like the sound of
+> Using stack automates nearly everything, will work on many systems, and avoids build failures due to fast-changing haskell libraries.
+
+I'm working with Ubuntu 16.04 LTS, stack 1.5.1, ghc 8.0.2 (courtesy of stack), and git-annex 6.20171026.
+
+So, here's how things went.
+
+*Almost* following the *stack* section of [[install/fromsource]], after `stack setup` I did `stack build` instead of`stack install`, so that I could (a) run the tests before installing, and (b) install into /usr/local as root.
+
+Issue #1: **`stack test` doesn't run the tests**.  It took me a while to find `git annex test`.  This isn't a bug, just something for people to be aware of.
+
+Issue #2: **`stack build` doesn't create the *git-annex* and *git-annex-shell* symlinks**.  Which means that the *ssh remote* tests fail.
+
+Issue #3: **Unless they don't**.  If *./git-annex-shell* doesn't exist, the tests use whatever copy they find on $PATH.  Which lets them run -- but it's not testing the code you think it's testing.  This could lead to either false negatives or false positives under different circumstances.
+
+I'd noticed the Makefile, but dismissed it after a failed attempt to set `BUILDER=stack`, especially since it's undocumented.  Turns out it does important stuff -- like creating those symlinks.  So I dug more deeply.  The magic incantation is:
+
+	make BUILDER=stack GHC=\"stack ghc --\" [target]
+
+The \"--\" is the unobvious bit.
+
+There's even a `make test`.
+
+Issue #4: The Makefile does good and useful things, but **I can find no mention of it in [[install/fromsource]]**.
+
+OK, so at this point I've got the thing built, and the tests passing (legitimately, using the correct version of *git-annex-shell*).  Time to install it.
+
+Issue #5: **`sudo make install` doesn't work**.  *stack* refuses to run, complaining:
+
+> You are not the owner of '/home/erics/.stack/'. Aborting to protect file permissions.
+> Retry with '--allow-different-user' to disable this precaution.
+
+See <https://github.com/commercialhaskell/stack/issues/471> for what this is about.
+
+Three ways to add that option:
+
+1. Hack the Makefile -- add another `if [ $BUILDER = stack ]` section
+
+2. Add this line to git-annex's *stack.yaml* (or to *~/.stack/config.yaml* if you want it as a global setting):
+
+       allow-different-user: true
+
+   (It's a standalone entry, so should have *no* leading whitespace)
+
+3. For installing, use a variant of the above magic incantation:
+
+	  sudo make BUILDER=\"stack --allow-different-user\" GHC=\"stack ghc --\" install
+
+I did #2, but #3 is probably safest, since it means you're only allow(ing)-different-user when you actually need to.
+
+However you do it, be aware that if *stack* decides, at make-install time, to create any files under the source tree, of course it will create them as root, so subsequent builds as non-root will find them unwritable.  I presume that's what stack's error message, \"... to protect file permissions\", is talking about.
+
+Issue #6: **`make install` does indeed cause stack to create more files**.  Specifically, it builds *Build/InstallDesktopFile*.  It would make sense to build that at `make all` time, so that it gets done as the non-root user. This wouldn't guarantee not to pollute the source tree with root-owned files -- but as it is now, that's pretty much guaranteed *to* happen.
+
+After all those gripes, one very very good thing: I didn't have to apt-get any Haskell things at all!  Stack downloaded everything it needed, including the compiler.  Nice!
+
+Questions for @Joey:
+
+A. Is the Makefile undocumented because you don't really intend anyone else to use it, or is that just an oversight?
+
+B. Are any of the above issues legitimate bugs?  (Prime candidates, to my mind: #3 and #6)
+
+C. Given all the dependency grief in the comments from Cabal users, and that for all my troubles I experienced *none* of that ... maybe *stack* should be the recommended approach, even if you don't use it yourself?
+
+D. What's the preferred way to submit patches?  I have a couple of cosmetic ones for Makefile, besides the (trivial) fix for #6
+
+I'll edit the *stack* section of [[install/fromsource]] (the only part I'm competent to talk about), once I know which direction to go (i.e. the answer to (A)).
+
+
+"""]]
diff --git a/doc/install/fromsource/comment_67_5655a80d206bd1f7cf1f326c645df7ed._comment b/doc/install/fromsource/comment_67_5655a80d206bd1f7cf1f326c645df7ed._comment
new file mode 100644
index 0000000000..beecf6922c
--- /dev/null
+++ b/doc/install/fromsource/comment_67_5655a80d206bd1f7cf1f326c645df7ed._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="erics"
+ avatar="http://cdn.libravatar.org/avatar/6e5f74c742128e5d98fd672ed6ea4865"
+ subject="Woops, just found the &quot;contributing&quot; page..."
+ date="2017-11-01T19:33:08Z"
+ content="""
+... so I have the answer to my question about how to submit patches.
+"""]]
diff --git a/doc/install/fromsource/comment_68_059f1cd929228e131bf88d80aca0b573._comment b/doc/install/fromsource/comment_68_059f1cd929228e131bf88d80aca0b573._comment
new file mode 100644
index 0000000000..e1f96f95e5
--- /dev/null
+++ b/doc/install/fromsource/comment_68_059f1cd929228e131bf88d80aca0b573._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 68"""
+ date="2017-11-07T20:42:14Z"
+ content="""
+@erics, thanks for the useful feedback about stack. I've applied your
+patch to avoid the Build/InstallDesktopFile problem. And, I made it
+automatically set GHC when BUILDER=stack.
+
+Using the Makefile is documented, up in the "building from source on
+Debian" section. But there's a set of users who want to use stack,
+and don't want to mess around with Makefiles (including users on Windows
+without a "make"), and that's who the stack instructions are kind of
+targeted at. It's an unfortunate problem with stack that it doesn't provide
+any way to make the git-annex-shell symlink.
+
+I am doubtful that --allow-different-user is a good idea. I sometimes
+use stack to build git-annex for testing purposes, but I have never
+built it with stack and installed that with `sudo make install`.
+And it may well be that there's not a reasonable way to make that work;
+and the install target is mostly intended for use by distributions that
+are creating a package of git-annex, who probably set PREFIX and don't run
+it as root.
+"""]]
diff --git a/doc/install/fromsource/comment_69_444e529f8838ef127ff115eb6c2ef8ca._comment b/doc/install/fromsource/comment_69_444e529f8838ef127ff115eb6c2ef8ca._comment
new file mode 100644
index 0000000000..9d6fbc2f18
--- /dev/null
+++ b/doc/install/fromsource/comment_69_444e529f8838ef127ff115eb6c2ef8ca._comment
@@ -0,0 +1,140 @@
+[[!comment format=mdwn
+ username="Mowgli"
+ avatar="http://cdn.libravatar.org/avatar/17ab194dddf7b7da59ec039cbb3ac252"
+ subject="Gentoo-Build (Haskell nightmare)"
+ date="2018-10-05T19:36:01Z"
+ content="""
+I try to build git-annex on Gentoo linux (the most current version to be able to interact with the same version on debian). Unfortunatelly the version in Gentoo itself is to old (6.20170818).
+
+So I found the haskell overlay that includes newer libraries for haskell as well as git-annex version 6.20180626.
+
+So for 3 days now I try to get the haskell stack compiled what failed many times with circular dependencies, conflicting versions or simply not working haskell versions. It was a real nightmare and only a hint from the mailinglist to simply allow any haskell library, even all broken ones, gave me the solution to fulfile all dependencies for git-annex.
+
+But now, git-annex itself fails to compile. I have no idea how to solve that.
+
+Here the relevant logs:
+./setup configure --ghc --prefix=/usr --with-compiler=/usr/bin/ghc --with-hc-pkg=/usr/bin/ghc-pkg --prefix=/usr --libdir=/usr/lib64 --libsubdir=git-annex-6.20180626/ghc-8.4.3 --datadir=/usr/share/ --datasubdir=git-annex-6.20180626/ghc-8.4.3 --ghc-options=-j2 +RTS -A256M -qb0 -RTS --with-ar=x86_64-pc-linux-gnu-ar --ghc-option=-optc-march=native --ghc-option=-optc-O2 --ghc-option=-optc-pipe --ghc-option=-optl-Wl,-O1 --ghc-option=-optl-Wl,--as-needed --disable-executable-stripping --docdir=/usr/share/doc/git-annex-6.20180626 --verbose --enable-shared --enable-executable-dynamic --sysconfdir=/etc --disable-library-stripping --flag=-android --flag=-androidsplice --flags=-assistant --flags=-benchmark --flags=concurrentoutput --flags=-dbus --flags=magicmime --flags=network-uri --flags=pairing --flag=-production --flags=-s3 --flag=-testsuite --flags=torrentparser --flags=-webapp --flags=webdav
+…
+Assistant/Threads/MountWatcher.hs:36:2: error:
+     warning: #warning Building without dbus support; will use mtab polling [-Wcpp]
+     #warning Building without dbus support; will use mtab polling
+      ^~~~~~~
+   |
+36 | #warning Building without dbus support; will use mtab polling
+   |  ^
+
+Assistant/Threads/NetWatcher.hs:27:2: error:
+     warning: #warning Building without dbus support; will poll for network connection changes [-Wcpp]
+     #warning Building without dbus support; will poll for network connection changes
+      ^~~~~~~
+   |
+27 | #warning Building without dbus support; will poll for network connection changes
+   |  ^
+
+BuildFlags.hs:22:2: error:
+     warning: #warning Building without the assistant. [-Wcpp]
+     #warning Building without the assistant.
+      ^~~~~~~
+   |
+22 | #warning Building without the assistant.
+   |  ^
+
+BuildFlags.hs:27:2: error:
+     warning: #warning Building without the webapp. You probably need to install Yesod.. [-Wcpp]
+     #warning Building without the webapp. You probably need to install Yesod..
+      ^~~~~~~
+   |
+27 | #warning Building without the webapp. You probably need to install Yesod..
+   |  ^
+
+BuildFlags.hs:43:2: error:
+     warning: #warning Building without S3. [-Wcpp]
+     #warning Building without S3.
+      ^~~~~~~
+   |
+43 | #warning Building without S3.
+   |  ^
+
+Utility/DirWatcher.hs:42:2: error:
+     warning: #warning \"Building without inotify support\" [-Wcpp]
+     #warning \"Building without inotify support\"
+      ^~~~~~~
+   |
+42 | #warning \"Building without inotify support\"
+   |  ^
+…
+Utility/IPAddress.hs:20:48: error:
+    Variable not in scope:
+      hostAddressToTuple :: HostAddress -> (Integer, b0, c0, d0)
+   |
+20 | isLoopbackAddress (SockAddrInet _ ipv4) = case hostAddressToTuple ipv4 of
+   |                                                ^^^^^^^^^^^^^^^^^^
+
+Utility/IPAddress.hs:26:53: error:
+    Variable not in scope:
+      hostAddress6ToTuple
+        :: HostAddress6
+           -> (Word16, Word16, Word16, Word16, Word16, Word16, Word16, Word16)
+   |
+26 | isLoopbackAddress (SockAddrInet6 _ _ ipv6 _) = case hostAddress6ToTuple ipv6 of
+   |                                                     ^^^^^^^^^^^^^^^^^^^
+
+Utility/IPAddress.hs:39:47: error:
+    Variable not in scope:
+      hostAddressToTuple
+        :: HostAddress -> (Integer, Integer, Integer, Integer)
+   |
+39 | isPrivateAddress (SockAddrInet _ ipv4) = case hostAddressToTuple ipv4 of
+   |                                               ^^^^^^^^^^^^^^^^^^
+
+Utility/IPAddress.hs:49:52: error:
+    Variable not in scope:
+      hostAddress6ToTuple
+        :: HostAddress6
+           -> (Word16, Word16, Word16, Word16, Word16, Word16, Word16, Word16)
+   |
+49 | isPrivateAddress (SockAddrInet6 _ _ ipv6 _) = case hostAddress6ToTuple ipv6 of
+   |                                                    ^^^^^^^^^^^^^^^^^^^
+
+Utility/IPAddress.hs:70:22: error:
+    Variable not in scope: htonl :: Integer -> t
+   |
+70 |         toipv4 a b = htonl $ fromIntegral a * (2^halfipv4bits) + fromIntegral b
+   |                      ^^^^^
+…
+Utility/Mounts.hs:13:1: error:
+    Could not find module `System.MountPoints'
+    Use -v to see a list of the files searched for.
+   |
+13 | import qualified System.MountPoints
+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Utility/Mounts.hs:14:1: error:
+    Could not find module `System.MountPoints'
+    Use -v to see a list of the files searched for.
+   |
+14 | import System.MountPoints (Mntent(..))
+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+…
+Utility/SRV.hs:18:1: error:
+    Could not find module `Network.DNS.Lookup'
+    Use -v to see a list of the files searched for.
+   |
+18 | import qualified Network.DNS.Lookup as DNS
+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Utility/SRV.hs:19:1: error:
+    Could not find module `Network.DNS.Resolver'
+    Use -v to see a list of the files searched for.
+   |
+19 | import Network.DNS.Resolver
+   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Full logs via e-mail.
+
+As you can see, I try to compile without assistant and without webapp as I never use that two subsystems. From the ebuild file, that should exclude them via cabal flags and does not install the dns library (beside others).
+
+Bt git-annex seems to ignore the cabal flags and try to install all the excluded stuff nevertheless (like s3, assistan or webapp).
+
+Help! How to get out of the Haskell nightmare!?
+"""]]
diff --git a/doc/install/fromsource/comment_6_5afb2d081e8b603bc338cd460ad9317d._comment b/doc/install/fromsource/comment_6_5afb2d081e8b603bc338cd460ad9317d._comment
new file mode 100644
index 0000000000..1ff7b4f760
--- /dev/null
+++ b/doc/install/fromsource/comment_6_5afb2d081e8b603bc338cd460ad9317d._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="Some errors after the build"
+ date="2013-05-30T16:38:37Z"
+ content="""
+    Registering yesod-static-1.1.2.3...
+    Installing library in /home/nrb/.cabal/lib/yesod-static-1.1.2.3/ghc-7.4.1
+    Registering yesod-static-1.1.2.3...
+    cabal: Error: some packages failed to install:
+    c2hs-0.16.4 depends on language-c-0.3.2.1 which failed to install.
+    dbus-0.10.4 depends on libxml-sax-0.7.4 which failed to install.
+    git-annex-4.20130521.2 depends on libxml-sax-0.7.4 which failed to install.
+    language-c-0.3.2.1 failed during the configure step. The exception was:
+    ExitFailure 1
+    libxml-sax-0.7.4 failed during the configure step. The exception was:
+    ExitFailure 1
+    network-protocol-xmpp-0.4.5 depends on libxml-sax-0.7.4 which failed to
+    install.
+
+"""]]
diff --git a/doc/install/fromsource/comment_70_ab27934713fa6032ec9992f7e04fa9c5._comment b/doc/install/fromsource/comment_70_ab27934713fa6032ec9992f7e04fa9c5._comment
new file mode 100644
index 0000000000..b04e520b59
--- /dev/null
+++ b/doc/install/fromsource/comment_70_ab27934713fa6032ec9992f7e04fa9c5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Mowgli"
+ avatar="http://cdn.libravatar.org/avatar/17ab194dddf7b7da59ec039cbb3ac252"
+ subject="Logs"
+ date="2018-10-05T19:38:06Z"
+ content="""
+Sorry, your comment system ate up all the linebreaks and make all that beautiful error logs unreadable. :-(
+"""]]
diff --git a/doc/install/fromsource/comment_71_3075af9a88b717c8ff1a489177e689f4._comment b/doc/install/fromsource/comment_71_3075af9a88b717c8ff1a489177e689f4._comment
new file mode 100644
index 0000000000..bed7d68564
--- /dev/null
+++ b/doc/install/fromsource/comment_71_3075af9a88b717c8ff1a489177e689f4._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 71"""
+ date="2018-10-08T16:30:41Z"
+ content="""
+@Mowgl, I see from the errors that whatever version of git-annex you're
+trying to build is at least somewhat out of date, since Utility.SRV was
+removed last month. The Utility.Mounts problem has also been fixed in newer
+versions.
+
+hostAddressToTuple has been provided by all versions of the network package
+that git-annex.cabal allows it to build with, so you must have forced it to
+build with an older, unsupported version.
+
+Anyway, there is nothing that prevents using git-annex 6.20170818 from
+working with any newer version of git-annex, unless you are using a
+couple of features added in newer versions.
+"""]]
diff --git a/doc/install/fromsource/comment_72_fb9581f4949efe1e8c90851fce9d61bf._comment b/doc/install/fromsource/comment_72_fb9581f4949efe1e8c90851fce9d61bf._comment
new file mode 100644
index 0000000000..9647ff4679
--- /dev/null
+++ b/doc/install/fromsource/comment_72_fb9581f4949efe1e8c90851fce9d61bf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Mowgli"
+ avatar="http://cdn.libravatar.org/avatar/17ab194dddf7b7da59ec039cbb3ac252"
+ subject="comment 72"
+ date="2018-10-13T12:37:56Z"
+ content="""
+@joey, What I have is just the builds I get from gentoo respective the haskell overlay. The most current version in that overlay is 6.20180626 but it also does not compile.
+
+I need a version more recent than 6.20170818 as that version does still use rsync for remote copy.
+"""]]
diff --git a/doc/install/fromsource/comment_73_bc163a82180b00a8b757edf269cebc06._comment b/doc/install/fromsource/comment_73_bc163a82180b00a8b757edf269cebc06._comment
new file mode 100644
index 0000000000..aa0c94fd0f
--- /dev/null
+++ b/doc/install/fromsource/comment_73_bc163a82180b00a8b757edf269cebc06._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="prabindh"
+ avatar="http://cdn.libravatar.org/avatar/d5c12329a2a524ebf6105721dafcc0c2"
+ subject="Windows build with stack"
+ date="2019-02-07T14:59:51Z"
+ content="""
+1. git checkout failed,
+
+fatal: cannot create directory at 
+
+'doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed.': Filename too long
+
+fixed by updating longpaths in gitconfig, 
+
+2. stack setup ok
+
+3. stack install failed, 
+
+regex-tdfa-1.2.3.1: copy/register
+Progress 58/168
+removeDirectoryRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:RemoveDirectory 
+
+Will have to try the Make approach on Windows ?
+"""]]
diff --git a/doc/install/fromsource/comment_74_473d320a05f08ce3cbe24789dcb01200._comment b/doc/install/fromsource/comment_74_473d320a05f08ce3cbe24789dcb01200._comment
new file mode 100644
index 0000000000..e02b0c53c4
--- /dev/null
+++ b/doc/install/fromsource/comment_74_473d320a05f08ce3cbe24789dcb01200._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="driusan@4d47e7deeb2f5d3846792d049ed06f96a0c3ca98"
+ nickname="driusan"
+ avatar="http://cdn.libravatar.org/avatar/409b69c3ae7b431fc16129ccdadae9cd"
+ subject="Warning building with cabal"
+ date="2019-03-30T00:19:10Z"
+ content="""
+I had to build with cabal on DragonFlyBSD because stack isn't available (which is presumably the reason it's not in dports even though it builds cleanly.)
+
+Everything worked after, except all the cabal commands gave warnings of the type:
+
+> Warning: The install command is a part of the legacy v1 style of cabal usage.
+> 
+> Please switch to using either the new project style and the new-install
+command or the legacy v1-install alias as new-style projects will become the
+default in the next version of cabal-install. Please file a bug if you cannot
+replicate a working v1- use case with the new-style commands.
+>
+> For more information, see: https://wiki.haskell.org/Cabal/NewBuild
+
+I don't know much about \"new style\" and \"legacy\" commands in cabal, but instructions should probably be cleaned up to get around these warnings at some point.
+"""]]
diff --git a/doc/install/fromsource/comment_75_58dfd18135aa187d8b3977521ecff2d2._comment b/doc/install/fromsource/comment_75_58dfd18135aa187d8b3977521ecff2d2._comment
new file mode 100644
index 0000000000..9d07aef2ec
--- /dev/null
+++ b/doc/install/fromsource/comment_75_58dfd18135aa187d8b3977521ecff2d2._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="TTTTAAAx"
+ avatar="http://cdn.libravatar.org/avatar/9edd4b69b9f9fc9b8c1cb8ecd03902d5"
+ subject="comment 75"
+ date="2024-01-11T14:15:58Z"
+ content="""
+Can I make armv7 version for alpine Linux? Or WASM?
+`git-annex` can't run on iOS without jailbreak.
+The only way is to build it on iSH or A-shell.
+
+git-annex(aarch64) is already provided on alpine repo. But iSH supports only armv7. So I can't install git-annex. I tried to build ghc for armv7. But the Haskell foundation has dropped supporting the armv7 since ghc-9. 
+
+A-shell needs WASI binary. I tried ghc-wasm-meta to compile git-annex to WASI binary, But I couldn't handle package version conflicts inside git-annex.
+
+
+"""]]
diff --git a/doc/install/fromsource/comment_7_129c4f2e404c874e5adfa52902a81104._comment b/doc/install/fromsource/comment_7_129c4f2e404c874e5adfa52902a81104._comment
new file mode 100644
index 0000000000..40b202d4e0
--- /dev/null
+++ b/doc/install/fromsource/comment_7_129c4f2e404c874e5adfa52902a81104._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="krig"
+ ip="46.194.28.123"
+ subject="Could not resolve dependencies for yesod"
+ date="2013-06-25T06:14:18Z"
+ content="""
+I'm having problems installing from cabal, and it seems related to yesod. I found an older discussion on something similar, where a constraint to require a newer version of yesod had been added, but I haven't figured out what was done to solve it.
+
+The problem seems to be that git-annex requires yesod < 1.2, but cabal is unable to install an older version.
+
+    $ cabal install git-annex --bindir=$HOME/bin
+    Resolving dependencies...
+    cabal: Could not resolve dependencies:
+    trying: git-annex-4.20130601
+    trying: git-annex-4.20130601:+webapp
+    rejecting: yesod-1.2.1.1, 1.2.1, 1.2.0.1, 1.2.0 (conflict:
+    git-annex-4.20130601:webapp => yesod(<1.2))
+    trying: yesod-1.1.9.3
+    $
+
+From what I can tell, the problem is fixed in github master since yesod >= 1.2 is supported again.
+"""]]
diff --git a/doc/install/fromsource/comment_8_738c108f131e3aab0d720bc4fd6a81fd._comment b/doc/install/fromsource/comment_8_738c108f131e3aab0d720bc4fd6a81fd._comment
new file mode 100644
index 0000000000..536f30da09
--- /dev/null
+++ b/doc/install/fromsource/comment_8_738c108f131e3aab0d720bc4fd6a81fd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 8"
+ date="2013-06-25T17:16:46Z"
+ content="""
+git-annex 4.20130621 once again builds with the current version of yesod.
+"""]]
diff --git a/doc/install/fromsource/comment_9_5ddbba419d96a7411f7edddaa4d7b739._comment b/doc/install/fromsource/comment_9_5ddbba419d96a7411f7edddaa4d7b739._comment
new file mode 100644
index 0000000000..3284c8caa2
--- /dev/null
+++ b/doc/install/fromsource/comment_9_5ddbba419d96a7411f7edddaa4d7b739._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl7dGdYtCHb7xleEOp6n8yaUQ4UtaiAEEs"
+ nickname="Henning"
+ subject="libxml-sax Error on OS X fresh install"
+ date="2013-07-27T13:11:23Z"
+ content="""
+I had - maybe the same problem as Nigel - with ExitFailure 1 libxml-sax-0.7.4 .
+
+I could fix this by forcing the link of libxml2 package with \"brew link libxml2 --force\". Maybe you should update your guide. I had this problem on 2 different machines running both the current versions of OS X.
+
+After this the build finished successfull. Maybe this helps.
+"""]]
diff --git a/doc/install/openSUSE.mdwn b/doc/install/openSUSE.mdwn
new file mode 100644
index 0000000000..cd5a8eef85
--- /dev/null
+++ b/doc/install/openSUSE.mdwn
@@ -0,0 +1,7 @@
+There are [packages of git-annex](https://build.opensuse.org/project/show/devel:languages:haskell)
+available for openSUSE.
+
+From openSUSE:Leap:42.2 git-annex will be part of the distribution.
+
+git-annex is included in the openSUSE:Tumbleweed distribution
+and can be installed by running `zypper in git-annex`
diff --git a/doc/install/openSUSE/comment_1_a5aea1ef644d0402d3caf593fef2456f._comment b/doc/install/openSUSE/comment_1_a5aea1ef644d0402d3caf593fef2456f._comment
new file mode 100644
index 0000000000..ee0bf31099
--- /dev/null
+++ b/doc/install/openSUSE/comment_1_a5aea1ef644d0402d3caf593fef2456f._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="nangal.vivek@08b8bc308cb03037792b7930fd839b9deec118df"
+ nickname="nangal.vivek"
+ avatar="http://cdn.libravatar.org/avatar/f8e7f170b837feb1008df116c7f9d0de"
+ subject="not able to find git-annex on openSUSE using zypper"
+ date="2019-12-01T17:04:53Z"
+ content="""
+Getting the following error on runnning `zypper in git-annex`
+
+    Loading repository data...
+    Reading installed packages...
+    Package 'git-annex' not found.
+
+I am running openSUSE for WSL with the following info
+
+    NAME=\"openSUSE Leap\"
+    VERSION=\"15.1 \"
+    ID=\"opensuse-leap\"
+    ID_LIKE=\"suse opensuse\"
+    VERSION_ID=\"15.1\"
+    PRETTY_NAME=\"openSUSE Leap 15.1\"
+    ANSI_COLOR=\"0;32\"
+    CPE_NAME=\"cpe:/o:opensuse:leap:15.1\"
+    BUG_REPORT_URL=\"https://bugs.opensuse.org\"
+    HOME_URL=\"https://www.opensuse.org/\"
+"""]]
diff --git a/doc/install/openSUSE/comment_2_095d48e7dffe57421b2d3384a83d7183._comment b/doc/install/openSUSE/comment_2_095d48e7dffe57421b2d3384a83d7183._comment
new file mode 100644
index 0000000000..6e0bc217ed
--- /dev/null
+++ b/doc/install/openSUSE/comment_2_095d48e7dffe57421b2d3384a83d7183._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="daniel"
+ avatar="http://cdn.libravatar.org/avatar/2494072cb19027868a5111e94ad71986"
+ subject="openSUSE Leap 15.2"
+ date="2021-04-29T14:47:00Z"
+ content="""
+Confirm getting the following error on runnning zypper in git-annex:
+
+    Loading repository data...
+    Reading installed packages...
+    Package 'git-annex' not found.
+
+Looking at [software.opensuse](https://software.opensuse.org/package/git-annex) I found at least an experimental package, which seems to work for me:
+
+    zypper addrepo https://download.opensuse.org/repositories/devel:languages:haskell/openSUSE_Leap_15.2/devel:languages:haskell.repo
+    zypper refresh
+    zypper install git-annex
+
+"""]]
diff --git a/doc/install/rpm_standalone.mdwn b/doc/install/rpm_standalone.mdwn
new file mode 100644
index 0000000000..919324e988
--- /dev/null
+++ b/doc/install/rpm_standalone.mdwn
@@ -0,0 +1,12 @@
+If the version of git-annex shipped in your rpm-based distribution is too
+old, there's a git-annex-standalone rpm that you can install instead. It's
+kept up-to-date with the latest git-annex release, and it works on a wide
+range of distribution versions.
+
+To install it, you first have to download a yum configuration file for the git-annex rpm repository:
+
+	curl https://downloads.kitenet.net/git-annex/linux/current/rpms/git-annex.repo > /etc/yum.repos.d/git-annex.repo
+
+Then:
+
+	yum install git-annex-standalone
diff --git a/doc/install/rpm_standalone/comment_1_7d234e64f3b6e97cd6d91c339ebb0025._comment b/doc/install/rpm_standalone/comment_1_7d234e64f3b6e97cd6d91c339ebb0025._comment
new file mode 100644
index 0000000000..19722c779f
--- /dev/null
+++ b/doc/install/rpm_standalone/comment_1_7d234e64f3b6e97cd6d91c339ebb0025._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="mike@4e7a118bd37129091199ae0fb28184999c5f4725"
+ nickname="mike"
+ avatar="http://cdn.libravatar.org/avatar/9751260f8a13fc27ad837eaf66fac5d7"
+ subject="repodata is outdated"
+ date="2019-12-18T10:06:08Z"
+ content="""
+The repodata under https://downloads.kitenet.net/git-annex/linux/current/rpms/repodata/ is outdated (from September), latest RPM in https://downloads.kitenet.net/git-annex/linux/current/rpms/ is from November. I (think) I had an issue using git-annex-shell using the 201909 version, so this is somewhat relevant.
+"""]]
diff --git a/doc/install/rpm_standalone/comment_2_11f0fdc5be4fd6620732867070c53477._comment b/doc/install/rpm_standalone/comment_2_11f0fdc5be4fd6620732867070c53477._comment
new file mode 100644
index 0000000000..9d19de483a
--- /dev/null
+++ b/doc/install/rpm_standalone/comment_2_11f0fdc5be4fd6620732867070c53477._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-12-18T18:28:51Z"
+ content="""
+I've fixed it, should include the latest release now.
+
+Please do file a bug report if you find problems with the rpms.
+"""]]
diff --git a/doc/install/rpm_standalone/comment_3_3a38ab16ca034025476b4df0a566b4a9._comment b/doc/install/rpm_standalone/comment_3_3a38ab16ca034025476b4df0a566b4a9._comment
new file mode 100644
index 0000000000..0e08bcb0c9
--- /dev/null
+++ b/doc/install/rpm_standalone/comment_3_3a38ab16ca034025476b4df0a566b4a9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="ipfs"
+ date="2022-10-31T13:36:51Z"
+ content="""
+It would be nice if the rpm or repository included auxiliarity scripts such as git-annex-remote-ipfs so that these would get installed/uninstalled/upgraded alongside the main project.
+"""]]
diff --git a/doc/install/verifying_downloads.mdwn b/doc/install/verifying_downloads.mdwn
new file mode 100644
index 0000000000..3677848c7b
--- /dev/null
+++ b/doc/install/verifying_downloads.mdwn
@@ -0,0 +1,33 @@
+When you download a git-annex package from downloads.kitenet.net, as listed
+in a page under [[install]], you should use a https connection. That
+provides some security, but here's some more.
+
+The downloaded package's integrity can be verified by checking that
+it was signed using the right GPG key, specifically the git-annex
+distribution signing key. To do this, you need to download the .sig
+file accompanying your package. Just append .sig to the url. 
+
+For example, on Linux:
+
+	$ wget https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz
+	$ wget https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz.sig
+
+You can then download the public key, and check that the package is signed
+with it.
+
+	$ wget https://downloads.kitenet.net/git-annex/gpg-pubkey.asc
+	$ gpg --import gpg-pubkey.asc
+	$ gpg --verify git-annex-standalone-*.tar.gz.sig
+
+(The git-annex assistant can automatically upgrade git-annex, and when it
+does, it always checks the signature like that.)
+
+But, how do you know that the gpg-pubkey.asc you downloaded
+is the right key? The answer is the GPG web of trust. 
+
+* Joey Hess generates these git-annex packages,
+  and has a GPG key, C910D9222512E3C7 Joey Hess &lt;id@joeyh.name&gt;, which has
+  been verified and signed by many people.
+* Joey's GPG key has signed the git-annex distribution signing key.
+
+Don't take this page's word about this, check it yourself!
diff --git a/doc/internals.mdwn b/doc/internals.mdwn
new file mode 100644
index 0000000000..09225312fc
--- /dev/null
+++ b/doc/internals.mdwn
@@ -0,0 +1,366 @@
+In the world of git, we're not scared about internal implementation
+details, and sometimes we like to dive in and tweak things by hand. Here's
+some documentation to that end.
+
+## The .git/ directory
+
+### `.git/annex/objects/aa/bb/*/*`
+
+This is where locally available file contents are actually stored.
+Files added to the annex get a symlink or [[pointer_file]] checked into git,
+that points to the file content.
+
+First there are two levels of directories used for hashing, to prevent
+too many things ending up in any one directory.
+See [[hashing]] for details.
+
+Each subdirectory has the [[name_of_a_key|key_format]] in one of the
+[[key-value_backends|backends]]. The file inside also has the name of the key.
+This two-level structure is used because it allows the write bit to be removed
+from the subdirectories as well as from the files. That prevents accidentally
+deleting or changing the file contents. See [[lockdown]] for details.
+
+### `.git/annex/tmp/`
+
+This directory contains partially transferred objects.
+
+### `.git/annex/othertmp/`
+
+This is a temp directory for miscellaneous other temp files.
+
+### `.git/annex/bad/`
+
+git-annex fsck puts any bad objects it finds in here.
+
+### `.git/annex/transfers/`
+
+Contains information files for uploads and downloads that are in progress,
+as well as any that have failed. Used especially by the assistant.
+It is safe to delete these files.
+
+### `.git/annex/ssh/`
+
+ssh connection caching files are written in here. It is safe to delete
+these files.
+
+### `.git/annex/index`
+
+This is a git index file which git-annex uses to stage files
+when preparing commits to the git-annex branch.
+
+It's pretty safe to delete this file if git-annex is not currently running.
+It will be re-created as necessary.
+
+### `.git/annex/journal/`
+
+git-annex uses this to journal changes to the git-annex branch,
+before committing a set of changes.
+
+<a name="The_git-annex_branch"></a>
+## The git-annex branch
+
+This branch is managed by git-annex, with the contents listed below.
+
+This branch is not connected to your master, etc branches. It it used for
+internal tracking of information about git-annex repositories and annexed
+objects.
+
+The files stored in this branch are all designed to be auto-merged
+using git's [[union merge driver|git-union-merge]]. So each line
+has a timestamp, to allow the most recent information to be identified.
+
+### `uuid.log`
+
+Records the UUIDs of known repositories, and associates them with a
+description of the repository. This allows git-annex to display something
+more useful than a UUID when it refers to a repository that does not have
+a configured git remote pointing at it.
+
+The file format is simply one line per repository, with the uuid followed by a
+space and then the description, followed by a timestamp. Example:
+
+	e605dca6-446a-11e0-8b2a-002170d25c55 laptop timestamp=1317929189.157237s
+	26339d22-446b-11e0-9101-002170d25c55 usb disk timestamp=1317929330.769997s
+
+## `numcopies.log`
+
+Records the global numcopies setting.
+
+The file format is simply a timestamp followed by a number.
+
+## `mincopies.log`
+
+Records the global mincopies setting.
+
+The file format is simply a timestamp followed by a number.
+
+## `config.log`
+
+Records global configuration settings, which can be overridden by values
+in `.git/config`.
+
+The file format is a timestamp, followed by the name of the configuration,
+followed by the value. For example:
+
+	1317929189.157237s annex.autocommit false
+
+## `remote.log`
+
+Holds persistent configuration settings for [[special_remotes]] such as
+Amazon S3.
+
+The file format is one line per remote, starting with the uuid of the
+remote, followed by a space, and then a series of var=value pairs,
+each separated by whitespace, and finally a timestamp.
+
+Special remotes that are autoenabled have autoenable=true here.
+
+Encrypted special remotes store their encryption key here,
+in the "cipher" value. It is base64 encoded, and unless shared [[encryption]]
+is used, is encrypted to one or more gpg keys. The first 256 bytes of
+the cipher is used as the HMAC SHA1 encryption key, to encrypt filenames
+stored on the special remote. The remainder of the cipher is used as a gpg
+symmetric encryption key, to encrypt the content of files stored on the special
+remote.
+
+## `trust.log`
+
+Records the [[trust]] information for repositories. Does not exist unless
+[[trust]] values are configured.
+
+The file format is one line per repository, with the uuid followed by a
+space, and then either `1` (trusted), `0` (untrusted), `?` (semi-trusted),
+`X` (dead) and finally a timestamp.
+
+Example:
+
+	e605dca6-446a-11e0-8b2a-002170d25c55 1 timestamp=1317929189.157237s
+	26339d22-446b-11e0-9101-002170d25c55 ? timestamp=1317929330.769997s
+
+Repositories not listed are semi-trusted.
+
+## `group.log`
+
+Used to group repositories together.
+
+The file format is one line per repository, with the uuid followed by a space,
+and then a space-separated list of groups this repository is part of,
+and finally a timestamp.
+
+## `preferred-content.log`
+
+Used to indicate which repositories prefer to contain which file contents.
+
+The file format is one line per repository, with the uuid followed by a space,
+then a boolean expression, and finally a timestamp.
+
+Files matching the expression are preferred to be retained in the
+repository, while files not matching it are preferred to be stored
+somewhere else.
+
+## `required-content.log`
+
+Used to indicate which repositories are required to contain which file
+contents.
+
+File format is identical to preferred-content.log.
+
+## `group-preferred-content.log`
+
+Contains standard preferred content settings for groups. (Overriding or
+supplementing the ones built into git-annex.)
+
+The file format is one line per group, starting with a timestamp, then a
+space, then the group name followed by a space and then the preferred
+content expression.
+
+## `export.log`
+
+Tracks what trees have been exported to special remotes by
+[[git-annex-export]](1).
+
+Each line starts with a timestamp, then the uuid of the repository
+that exported to the special remote, followed by a colon (`:`) and
+the uuid of the special remote. Then, separated by a spaces,
+the SHA of the tree that was exported, and optionally any number of
+subsequent SHAs, of trees that have started to be exported but whose
+export is not yet complete. 
+
+In order to record the beginning of the first export, where nothing
+has been exported yet, the SHA of the exported tree can be
+the empty tree (eg 4b825dc642cb6eb9a060e54bf8d69288fbee4904).
+
+For example:
+
+	1317929100.012345s e605dca6-446a-11e0-8b2a-002170d25c55:26339d22-446b-11e0-9101-002170d25c55 4b825dc642cb6eb9a060e54bf8d69288fbee4904 bb08b1abd207aeecccbc7060e523b011d80cb35b
+	1317929100.012345s e605dca6-446a-11e0-8b2a-002170d25c55:26339d22-446b-11e0-9101-002170d25c55 bb08b1abd207aeecccbc7060e523b011d80cb35b 
+	1317929189.157237s e605dca6-446a-11e0-8b2a-002170d25c55:26339d22-446b-11e0-9101-002170d25c55 bb08b1abd207aeecccbc7060e523b011d80cb35b 7c7af825782b7c8706039b855c72709993542be4
+	1317923000.251111s e605dca6-446a-11e0-8b2a-002170d25c55:26339d22-446b-11e0-9101-002170d25c55 7c7af825782b7c8706039b855c72709993542be4 
+
+(The trees are also grafted into the git-annex branch, at
+`export.tree`, to prevent git from garbage collecting it. However, the head
+of the git-annex branch should never contain such a grafted in tree;
+the grafted tree is removed in the same commit that updates `export.log`.)
+
+## `aaa/bbb/*.log`
+
+These log files record [[location_tracking]] information
+for file contents. These are placed in two levels of subdirectories
+for hashing. See [[hashing]] for details.
+
+The name of the key is the filename, and the content
+consists of a timestamp, either 1 (present) or 0 (not present) or X (dead),
+and the UUID of the repository that has or lacks the file content.
+
+Example:
+
+	1287290776.765152s 1 e605dca6-446a-11e0-8b2a-002170d25c55
+	1287290767.478634s 0 26339d22-446b-11e0-9101-002170d25c55
+
+## `aaa/bbb/*.log.web`
+
+These log files record urls used by the
+[[web_special_remote|special_remotes/web]] and sometimes by other remotes.
+Their format is similar to the location tracking files, but with urls
+rather than UUIDs.
+
+## `aaa/bbb/*.log.ek`
+
+These log files record other keys that are equivilant to the key
+used in the filename. This is currently used for the `VURL` backend.
+Their format is similar to the location tracking files, but with keys
+rather than UUIDs.
+
+## `aaa/bbb/*.log.rmt`
+
+These log files are used by remotes that need to record their own state
+about keys. Each remote can store one line of data about a key, in
+its own format.
+
+Note that only the most recently set state about a key is seen
+by remotes using this. The `log.rmet` documented below does not have this
+limitation.
+
+Example:
+
+	1287290776.765152s e605dca6-446a-11e0-8b2a-002170d25c55 blah blah
+	1287290767.478634s 26339d22-446b-11e0-9101-002170d25c55 foo=bar
+
+## `aaa/bbb/*.log.met`
+
+These log files are used to store arbitrary [[design/metadata]] about keys.
+Each key can have any number of metadata fields. Each field has a set of
+values.
+
+Lines are timestamped, and record when values are added (`field +value`),
+but also when values are removed (`field -value`). Removed values
+are retained in the log so that when merging an old line that sets a value
+that was later unset, the value is not accidentally added back.
+
+For example:
+
+	1287290776.765152s tag +foo +bar author +joey
+	1291237510.141453s tag -bar +baz
+
+The value can be completely arbitrary data, although it's typically
+reasonably short. If the value contains any whitespace
+(including \r or \n), it will be base64 encoded. Base64 encoded values
+are indicated by prefixing them with "!".
+
+## `aaa/bbb/*.log.rmet`
+
+These log files store per-remote metadata about keys. This metadata
+is only used by the remote.
+
+Format is the same as the metadata log files above, but each metadata key
+is prefixed with "uuid:" to indicate the remote it belongs to.
+
+For example:
+
+	1287290776.765152s e605dca6-446a-11e0-8b2a-002170d25c55:foo +bar
+	1287290776.765152s 26339d22-446b-11e0-9101-002170d25c55:x +1
+	1291237510.141453s 26339d22-446b-11e0-9101-002170d25c55:x -1 26339d22-446b-11e0-9101-002170d25c55:x +2
+
+## `aaa/bbb/*.log.cid`
+
+These log files store per-remote content identifiers for keys.
+A given key may have any number of content identifiers.
+
+The format is a timestamp, followed by the uuid of the remote,
+followed by the content identifiers which are separated by colons.
+If a content identifier contains a colon or \r or \n, it will be base64
+encoded. Base64 encoded values are indicated by prefixing them with "!".
+
+	1287290776.765152s e605dca6-446a-11e0-8b2a-002170d25c55 5248916:5250378
+
+## `aaa/bbb/*.log.cnk`
+
+These log files are used when objects are stored in chunked form on
+remotes. They record the size(s) of the chunks, and the number of chunks.
+
+For example, this logs that a remote has an object stored using both
+9 chunks of 1 mb size, and 1 chunk of 10 mb size.
+
+	1287290776.765152s e605dca6-446a-11e0-8b2a-002170d25c55:10240 9
+	1287290776.765153s e605dca6-446a-11e0-8b2a-002170d25c55:102400 1
+
+(When those chunks are removed from the remote, the 9 is changed to 0.)
+
+## `schedule.log`
+
+Used to record scheduled events, such as periodic fscks.
+
+The file format is simply one line per repository, with the uuid followed by a
+space and then its schedule, followed by a timestamp.
+
+There can be multiple events in the schedule, separated by "; ".
+
+The format of the scheduled events is the same described in
+[[git-annex-schedule]].
+
+Example:
+
+	42bf2035-0636-461d-a367-49e9dfd361dd fsck self 30m every day at any time; fsck 4b3ebc86-0faf-4892-83c5-ce00cbe30f0a 1h every year at any time timestamp=1385646997.053162s
+
+## `activity.log`
+
+Used to record the times of activities, such as fscks.
+
+Example:
+
+	42bf2035-0636-461d-a367-49e9dfd361dd Fsck timestamp=1422387398.30395s
+
+## `transitions.log`
+
+Used to record transitions, eg by `git annex forget`
+
+Each line of the file is a transition, followed by a timestamp.
+
+Example:
+
+	ForgetGitHistory 1387325539.685136s
+	ForgetDeadRemotes 1387325539.685136s
+
+## `difference.log`
+
+Used when a repository has fundamental differences from other repositories,
+that should prevent merging.
+
+Example:
+
+	e605dca6-446a-11e0-8b2a-002170d25c55 [ObjectHashLower] timestamp=1422387398.30395s
+
+## `multicast.log`
+
+Records uftp public key fingerprints, for use by [[git-annex-multicast]].
+
+## `migrate.tree/old` and `migrate.tree/new`
+
+These are used to record migrations done by `git-annex migrate`. By diffing
+between the two, the old and new keys can be determined. This lets
+migrations be recorded while using a minimum of space in the git
+repository. The filenames in these trees have no connection to the names
+of actual annexed files.
+
+These trees are recorded in history of the git-annex branch, but the
+head of the git-annex branch will never contain them.
diff --git a/doc/internals/comment_10_c4298babd96b2596bd4f6ad828212c92._comment b/doc/internals/comment_10_c4298babd96b2596bd4f6ad828212c92._comment
new file mode 100644
index 0000000000..794735a02f
--- /dev/null
+++ b/doc/internals/comment_10_c4298babd96b2596bd4f6ad828212c92._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="atrent"
+ avatar="http://cdn.libravatar.org/avatar/6069dfebff03997460874771defa0fa4"
+ subject="duplicate objects?"
+ date="2019-11-30T14:04:17Z"
+ content="""
+Do I understand correctly that in .git/annex/objects dir there should be no duplicates?
+Here follows a run of 'rdfind' done in the objects dir:
+
+    $ rdfind .
+    Now scanning \".\", found 12874 files.
+    Now have 12874 files in total.
+    Removed 0 files due to nonunique device and inode.
+    Total size is 75579281486 bytes or 70 GiB
+    Removed 8376 files due to unique sizes from list.4498 files left.
+    Now eliminating candidates based on first bytes:removed 68 files from list.4430 files left.
+    Now eliminating candidates based on last bytes:removed 66 files from list.4364 files left.
+    Now eliminating candidates based on sha1 checksum:removed 0 files from list.4364 files left.
+    It seems like you have 4364 files that are not unique
+    Totally, 10 GiB can be reduced.
+    Now making results file results.txt
+
+And here is an example pair of dupes (excerpt from the abovementioned 'results.txt'):
+
+    DUPTYPE_FIRST_OCCURRENCE 2073 3 86558 26 21057567 1 ./53/zv/SHA256E-s86558--e79a0891bb94fc9212ce2f28178fe84591c5fb24c07b5239d367099118e12ede.jpg/SHA256E-s86558--e79a0891bb94fc9212ce2f28178fe84591c5fb24c07b5239d367099118e12ede.jpg
+    DUPTYPE_WITHIN_SAME_TREE -2073 3 86558 26 1080608 1 ./7w/w2/SHA256E-s86558--e79a0891bb94fc9212ce2f28178fe84591c5fb24c07b5239d367099118e12ede.56.jpeg/SHA256E-s86558--e79a0891bb94fc9212ce2f28178fe84591c5fb24c07b5239d367099118e12ede.56.jpeg
+
+Any clues?
+
+Thank you
+"""]]
diff --git a/doc/internals/comment_11_9758bb3a17f63b4dcf51742ea482dbe9._comment b/doc/internals/comment_11_9758bb3a17f63b4dcf51742ea482dbe9._comment
new file mode 100644
index 0000000000..3eb9d34423
--- /dev/null
+++ b/doc/internals/comment_11_9758bb3a17f63b4dcf51742ea482dbe9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="same contents with different keys"
+ date="2019-11-30T16:51:58Z"
+ content="""
+@atrent -- some [[backends]] (like SHA256E) base the key not just on object contents, but also on part of its filename (the extension).   So the same content can exist with two different keys.  In your example, the same contents exists in one file ending with .jpg and in another ending with .56.jpeg .  (This is done to give the annexed contents the same extension as the original file had before annexing, to avoid confusing some programs).  There are also backends like WORM and URL, not based on checksums, that could lead to different keys with same contents.  There could also be same contents added under different backends (see also [[`git-annex-migrate`|git-annex-migrate]]).  Finally, there is the theoretical possibility of hash collisions.
+"""]]
diff --git a/doc/internals/comment_12_f0325cefa5cd53a5a897046606137cef._comment b/doc/internals/comment_12_f0325cefa5cd53a5a897046606137cef._comment
new file mode 100644
index 0000000000..fe35b66fa2
--- /dev/null
+++ b/doc/internals/comment_12_f0325cefa5cd53a5a897046606137cef._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="atrent"
+ avatar="http://cdn.libravatar.org/avatar/6069dfebff03997460874771defa0fa4"
+ subject="no collisions"
+ date="2019-11-30T20:37:00Z"
+ content="""
+I can confirm that these are not collisions: these identical files are the same photos with different names, shame on Dropbox syncing from my smartphone. I was actually hoping to dedupe through git-annex ;-)
+
+Some more questions/suggestions/conversation-starters:
+
+* I suppose I can dedup them with rdfind (i.e., hardlinking identical files), do you foresee any side effects?
+
+* may I change the hash function of git-annex to something not depending on filenames? (I suppose so, I'll have a look at the docs)
+
+* if I can change the hash function can I regenerate the whole annex without re-creating it? (again I'll have a look at docs)
+
+Thanks
+"""]]
diff --git a/doc/internals/comment_13_e45b6fa035a30703618448a0f764f935._comment b/doc/internals/comment_13_e45b6fa035a30703618448a0f764f935._comment
new file mode 100644
index 0000000000..69452682e1
--- /dev/null
+++ b/doc/internals/comment_13_e45b6fa035a30703618448a0f764f935._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 13"
+ date="2019-11-30T21:11:53Z"
+ content="""
+[[git-annex-migrate]] to a backend not ending in E (e.g. SHA256 not SHA256E), then [[git-annex-unused]] to drop the old keys.
+
+"""]]
diff --git a/doc/internals/comment_14_3f62751c2dd041f4ead1c6580ea5eec1._comment b/doc/internals/comment_14_3f62751c2dd041f4ead1c6580ea5eec1._comment
new file mode 100644
index 0000000000..a950c8f739
--- /dev/null
+++ b/doc/internals/comment_14_3f62751c2dd041f4ead1c6580ea5eec1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="hardlinking identical files in annex may break invariants"
+ date="2019-11-30T21:36:38Z"
+ content="""
+P.S. Re: hardlinking identical files -- git-annex [[keeps track of inodes|todo/inode_based_clean_filter_for_less_surprising_git_add]] where contents is stored, so deleting a file might make that info stale.  Also, dropping one key will drop another key's contents without updating [[location_tracking]] info.  And dropping then getting files would lead to two separate copies again.   So I wouldn't recommend that.
+
+See also [[tips/local_caching_of_annexed_files]].
+"""]]
diff --git a/doc/internals/comment_15_c3d12d14e4d044f39829c5d92f523655._comment b/doc/internals/comment_15_c3d12d14e4d044f39829c5d92f523655._comment
new file mode 100644
index 0000000000..aa630ff5b9
--- /dev/null
+++ b/doc/internals/comment_15_c3d12d14e4d044f39829c5d92f523655._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="atrent"
+ avatar="http://cdn.libravatar.org/avatar/6069dfebff03997460874771defa0fa4"
+ subject="migrating..."
+ date="2019-11-30T22:30:06Z"
+ content="""
+I'm git-annex-migrating (to SHA256) now, thank you for all suggestions!
+"""]]
diff --git a/doc/internals/comment_16_2455c898d6c77a5437a2c1532144bb8a._comment b/doc/internals/comment_16_2455c898d6c77a5437a2c1532144bb8a._comment
new file mode 100644
index 0000000000..b71adef496
--- /dev/null
+++ b/doc/internals/comment_16_2455c898d6c77a5437a2c1532144bb8a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: representing unlocked state of files"""
+ date="2020-02-20T20:23:41Z"
+ content="""
+Starting with "/annex/objects" is not enough, the remainder of
+the first line of the file has to parse as a git-annex key
+for it to be a pointer file.
+"""]]
diff --git a/doc/internals/comment_17_df13b7e66963a6d2673e49f52afb978a._comment b/doc/internals/comment_17_df13b7e66963a6d2673e49f52afb978a._comment
new file mode 100644
index 0000000000..c750a92392
--- /dev/null
+++ b/doc/internals/comment_17_df13b7e66963a6d2673e49f52afb978a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="why othertmp to be on the same file system?"
+ date="2022-12-13T14:15:28Z"
+ content="""
+Joey, you said
+
+> .git/annex/othertmp has to be on the same filesystem as the work tree and git repository.
+
+is that for atomic/quick renames important for adjusted branch unlocked mode?  asking because in datalad we have that \"wreckless\" mode where we symlink an entire `.git/annex` from original clone to e.g. have quick throw away clone to access the data and possibly even without modifying state of any annexed key.
+
+Or how else are we stepping on the shovel here?
+"""]]
diff --git a/doc/internals/comment_18_1adce7945940b9c384c2383261388dd9._comment b/doc/internals/comment_18_1adce7945940b9c384c2383261388dd9._comment
new file mode 100644
index 0000000000..533b703735
--- /dev/null
+++ b/doc/internals/comment_18_1adce7945940b9c384c2383261388dd9._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: why othertmp to be on the same file system?"""
+ date="2022-12-20T18:39:35Z"
+ content="""
+I've audited the code and the only place I could find where it did not work
+to have othertmp on a different filesystem is in the bittorrent special
+remote when it downloads a torrent file. But that also failed when
+`.git/annex/tmp` was on a different filesystem! (Since it was moving between
+the two directories.) I've fixed that.
+
+It's still best to keep things on the same filesystem because
+cross-filesystem moves can be expensive and it sometimes falls back to less
+ideal behavior in other ways too when operating across filesystems. Also
+of course, you avoid being the one who gets to find and report breakage
+like the above..
+"""]]
diff --git a/doc/internals/comment_1_4b8ed353dca4f484b3b6eb463fa02fd8._comment b/doc/internals/comment_1_4b8ed353dca4f484b3b6eb463fa02fd8._comment
new file mode 100644
index 0000000000..b42cd2fd81
--- /dev/null
+++ b/doc/internals/comment_1_4b8ed353dca4f484b3b6eb463fa02fd8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="stoile"
+ ip="2a01:198:242:0:219:66ff:fef2:c021"
+ subject="tmp missing"
+ date="2013-11-16T12:16:48Z"
+ content="""
+There's no information about .git/annex/tmp here.
+"""]]
diff --git a/doc/internals/comment_2_c19232d5cc4976c2e5b014aef6e8d9ec._comment b/doc/internals/comment_2_c19232d5cc4976c2e5b014aef6e8d9ec._comment
new file mode 100644
index 0000000000..3c5f87bd5b
--- /dev/null
+++ b/doc/internals/comment_2_c19232d5cc4976c2e5b014aef6e8d9ec._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 2"
+ date="2013-11-16T17:23:02Z"
+ content="""
+.git/annex/tmp is not very interesting. It's a temporary file directory. When transferring a key's content, git-annex uses a stable filename, which allows resuming interrupted downloads, or cleaning up aborted downloads with `git annex unused`.
+"""]]
diff --git a/doc/internals/comment_3_5a26ee5aab274f321a4ea6f8527f53bd._comment b/doc/internals/comment_3_5a26ee5aab274f321a4ea6f8527f53bd._comment
new file mode 100644
index 0000000000..099f4c8ca0
--- /dev/null
+++ b/doc/internals/comment_3_5a26ee5aab274f321a4ea6f8527f53bd._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="134.147.14.84"
+ subject="comment 3"
+ date="2014-09-15T10:34:36Z"
+ content="""
+Some documentation that would be nice having added in the appropriate places:
+
+* Exactly how is the index file being used? Is this just a copy of the git index file that we would get when checking out the git-annex branch? Why is the file kept around? Which sort of operations are done on the index, e.g. when doing git annex add?
+
+* For all time-stamped data-structures: Exactly which significance does the time-stamp have? E.g., for uuid.log, is this the date the name was changed?
+"""]]
diff --git a/doc/internals/comment_4_81293b180fb09105ec158fdfef73d249._comment b/doc/internals/comment_4_81293b180fb09105ec158fdfef73d249._comment
new file mode 100644
index 0000000000..6a23316d44
--- /dev/null
+++ b/doc/internals/comment_4_81293b180fb09105ec158fdfef73d249._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject=".git/annex/tmp third-party use?"
+ date="2015-06-09T20:21:39Z"
+ content="""
+can `.git/annex/tmp` be used by third party software to import stuff in git-annex? the idea here would be to accept uploads from a web form in `.git/annex/tmp` then move it into place in the proper location once the upload is complete (then do a git-annex-add or let the assistant import it). --[[anarcat]]
+"""]]
diff --git a/doc/internals/comment_5_354012b6a9ac11160eb926234d38051f._comment b/doc/internals/comment_5_354012b6a9ac11160eb926234d38051f._comment
new file mode 100644
index 0000000000..f74e004f38
--- /dev/null
+++ b/doc/internals/comment_5_354012b6a9ac11160eb926234d38051f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-06-09T20:25:03Z"
+ content="""
+It's ok to put files in .git/annex/tmp if they're formatted as git-annex
+key filenames. Of course, you should avoid overwriting the content of files
+already there.
+
+Files not formatted as keys should be kept out of .git/annex/tmp; it's ok
+to put them in .git/annex/misctmp.
+"""]]
diff --git a/doc/internals/comment_7_7e40f744f9ac7f0403df9d1a2162a516._comment b/doc/internals/comment_7_7e40f744f9ac7f0403df9d1a2162a516._comment
new file mode 100644
index 0000000000..3f70188fc0
--- /dev/null
+++ b/doc/internals/comment_7_7e40f744f9ac7f0403df9d1a2162a516._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="arseny-n@6aba76e573dcdf2fd9e033fb3132944c8466125a"
+ nickname="arseny-n"
+ avatar="http://cdn.libravatar.org/avatar/0c138544ac6dfffb07d6a60dbe430587"
+ subject=".git/annex/misctmp very large"
+ date="2018-01-17T13:04:52Z"
+ content="""
+Why is .git/annex/misctmp so large ? Currently I use git annex to manage pytorch models, 
+basically I have a large amount (1500 folder) of 4 Kilobytes files, some files are are bigger,
+misctmp occupies 6.2 GB, is  it ok ?
+ 
+PS. Sorry, if I write this here but failed to post to the forum.
+
+"""]]
diff --git a/doc/internals/comment_7_9c82a2878f3feb1b2a95662ed25b234b._comment b/doc/internals/comment_7_9c82a2878f3feb1b2a95662ed25b234b._comment
new file mode 100644
index 0000000000..d8034bb5fa
--- /dev/null
+++ b/doc/internals/comment_7_9c82a2878f3feb1b2a95662ed25b234b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2018-02-22T16:56:13Z"
+ content="""
+@arseny-n the misctemp directory does not normally contain anything, or
+only temp files in use by the currently running git-annex process for a
+short amount of time. The only way I know of that it can get files piled up
+in it is when you kill the git-annex process while it's using such a file.
+
+It's always safe to delete the files in misctemp as long as git-annex is
+not running. Also, the names of the files should give a pretty good clue
+about what git-annex was using the file for. For example "jlog" files are
+used for staging the journal.
+"""]]
diff --git a/doc/internals/comment_8_9dccdd3a9556ceef54e318cd5c8a50ad._comment b/doc/internals/comment_8_9dccdd3a9556ceef54e318cd5c8a50ad._comment
new file mode 100644
index 0000000000..6cd3e4f154
--- /dev/null
+++ b/doc/internals/comment_8_9dccdd3a9556ceef54e318cd5c8a50ad._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 8"
+ date="2018-09-19T16:07:44Z"
+ content="""
+\"Each subdirectory has the name of a key in one of the key-value backends. The file inside also has the name of the key.\" -- is it necessary for the file inside to also have the name of the key?  Repeating the already long key name leads to very long symlink targets.   Could the file inside just be 'f.txt' (or whatever the extension is)?
+
+Also, the terms \"key\" and \"name of the key\" are used in various places; are these the same thing?
+"""]]
diff --git a/doc/internals/comment_9_40442b012886ad698f448c262f0d7f4c._comment b/doc/internals/comment_9_40442b012886ad698f448c262f0d7f4c._comment
new file mode 100644
index 0000000000..84fcb7273f
--- /dev/null
+++ b/doc/internals/comment_9_40442b012886ad698f448c262f0d7f4c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="representing unlocked state of files"
+ date="2019-09-19T18:02:31Z"
+ content="""
+Is the locked/unlocked state of a file represented somewhere?  Or does git-annex just assume that any file whose contents starts with /annex/objects/ is a pointer file?
+"""]]
diff --git a/doc/internals/hashing.mdwn b/doc/internals/hashing.mdwn
new file mode 100644
index 0000000000..9895cad0e9
--- /dev/null
+++ b/doc/internals/hashing.mdwn
@@ -0,0 +1,44 @@
+In both the .git/annex directory and the git-annex branch, two levels of
+hash directories are used, to avoid issues with too many files in one
+directory.
+
+Two separate hash methods are used. 
+
+* hashdirmixed is only used for non-bare git repositories.
+  (We'd like to stop using this, but it'd be too annoying to change
+  all the git-annex symlinks!)
+
+* hashdirlower is used for bare git repositories, the 
+  git-annex branch, and on special remotes as well.
+
+Note that `git annex find` and `git annex examinekey` can be used with
+the `--format` option to find the hash directories. The explanation
+below is only for completeness.
+
+## new hash format
+
+This uses two directories, each with a three-letter name, such as "f87/4d5"
+
+The directory names come from the first 6 characters of the md5sum of the [[key|key_format]]
+when serialized as a hex string.
+
+For example:
+
+	echo -n	"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" | md5sum
+
+## old hash format
+
+This uses two directories, each with a two-letter name, such as "pX/1J"
+
+It takes the md5sum of the key, but rather than a string, represents it as 4
+32bit words. Only the first word is used. It is converted into a string by the
+same mechanism that would be used to encode a normal md5sum value into a
+string, but where that would normally encode the bits using the 16 characters
+0-9a-f, this instead uses the 32 characters "0123456789zqjxkmvwgpfZQJXKMVWGPF".
+The first 2 letters of the resulting string are the first directory, and the
+second 2 are the second directory.
+
+## chunk keys
+
+The same hash directory is used for a chunk key as would be used for the
+key that it's a chunk of.
diff --git a/doc/internals/hashing/comment_1_9153e4f4f9335e524cf1b96a51bef41f._comment b/doc/internals/hashing/comment_1_9153e4f4f9335e524cf1b96a51bef41f._comment
new file mode 100644
index 0000000000..075bedfcec
--- /dev/null
+++ b/doc/internals/hashing/comment_1_9153e4f4f9335e524cf1b96a51bef41f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnlotDRSLW2JVXY3SLSwhrcHteqUHhTtoY"
+ nickname="Péter"
+ subject="comment 1"
+ date="2014-01-31T00:45:47Z"
+ content="""
+The correct old hash value for the empty file SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 is pX/ZJ .
+
+The text describes the old hash value computation incorrectly, because it doesn't mention that 1 bit is skipped between each group of 5 bits. See the sample implementation in display_32bits_as_dir in https://github.com/joeyh/git-annex/blob/master/Locations.hs
+"""]]
diff --git a/doc/internals/hashing/comment_2_086ea37acf15e2a8694b8386222b73f6._comment b/doc/internals/hashing/comment_2_086ea37acf15e2a8694b8386222b73f6._comment
new file mode 100644
index 0000000000..04a35232d1
--- /dev/null
+++ b/doc/internals/hashing/comment_2_086ea37acf15e2a8694b8386222b73f6._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="comment 2"
+ date="2014-12-04T20:26:47Z"
+ content="""
+1c to support  Péter's statement:
+
+    $> git annex examinekey --format='${hashdirmixed}' \"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\"
+    pX/ZJ/%  
+"""]]
diff --git a/doc/internals/hashing/comment_3_19b7d20ca392078f14f9f10992f288ec._comment b/doc/internals/hashing/comment_3_19b7d20ca392078f14f9f10992f288ec._comment
new file mode 100644
index 0000000000..6ba3e097fa
--- /dev/null
+++ b/doc/internals/hashing/comment_3_19b7d20ca392078f14f9f10992f288ec._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="josch"
+ subject="any particular reason for the chosen characters for base32 encoding"
+ date="2015-01-31T17:13:57Z"
+ content="""
+are the characters \"0123456789zqjxkmvwgpfZQJXKMVWGPF\" chosen randomly for the base32 encoding or was there a reason to choose exactly these?
+"""]]
diff --git a/doc/internals/hashing/comment_4_7642d6ce5fd4d37d464b05d0b4f869c6._comment b/doc/internals/hashing/comment_4_7642d6ce5fd4d37d464b05d0b4f869c6._comment
new file mode 100644
index 0000000000..ee20eada75
--- /dev/null
+++ b/doc/internals/hashing/comment_4_7642d6ce5fd4d37d464b05d0b4f869c6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-02-04T17:14:24Z"
+ content="""
+The only reason for the letter choice is that it avoids making random
+words with possibly unintentional meanings..
+"""]]
diff --git a/doc/internals/hashing/comment_5_b0cb207a85cda5a0ff2ea71caca22c0d._comment b/doc/internals/hashing/comment_5_b0cb207a85cda5a0ff2ea71caca22c0d._comment
new file mode 100644
index 0000000000..80db7abccd
--- /dev/null
+++ b/doc/internals/hashing/comment_5_b0cb207a85cda5a0ff2ea71caca22c0d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="why md5sum?"
+ date="2015-02-13T15:59:46Z"
+ content="""
+why the extra processing to generate the hashing directories?
+
+we already have a hash here, for example, `SHA256E-s8242375--5f82490990812ad3feabb02355750710a9d94283ab256d1c691c3bf8d7d9fbe3.ogg` has a loon `5f82490990812ad3feabb02355750710a9d94283ab256d1c691c3bf8d7d9fbe3` hash. Why not use the first characters of that? This is will not change for a give file, and has a higher chance of generating collisions (which is a good thing here, because we can reuse directories).
+
+In other words, why aren't the hashes of `SHA256E-s8242375--5f82490990812ad3feabb02355750710a9d94283ab256d1c691c3bf8d7d9fbe3.ogg` simply `5f8/249`? --[[anarcat]]
+"""]]
diff --git a/doc/internals/hashing/comment_6_edb5c3388b5ac3481403c7accf9bb3f2._comment b/doc/internals/hashing/comment_6_edb5c3388b5ac3481403c7accf9bb3f2._comment
new file mode 100644
index 0000000000..302b394dff
--- /dev/null
+++ b/doc/internals/hashing/comment_6_edb5c3388b5ac3481403c7accf9bb3f2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: why md5sum?"""
+ date="2015-02-17T21:51:59Z"
+ content="""
+Not all types of keys contain hashes.
+"""]]
diff --git a/doc/internals/hashing/comment_7_843592cf125be06fb316be43b85b0524._comment b/doc/internals/hashing/comment_7_843592cf125be06fb316be43b85b0524._comment
new file mode 100644
index 0000000000..7c426e8e6e
--- /dev/null
+++ b/doc/internals/hashing/comment_7_843592cf125be06fb316be43b85b0524._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="giomasce"
+ subject="Python implementation"
+ date="2015-03-22T22:38:54Z"
+ content="""
+I wrote a Python implementation of the two hashing functions for a project of mine. [Here it is](https://gist.github.com/giomasce/a7802bda1417521c5b30), hoping it can be helpful for somone.
+
+"""]]
diff --git a/doc/internals/key_format.mdwn b/doc/internals/key_format.mdwn
new file mode 100644
index 0000000000..5d183fa040
--- /dev/null
+++ b/doc/internals/key_format.mdwn
@@ -0,0 +1,31 @@
+A git-annex key has this format:
+
+	BACKEND[-sNNNN][-mNNNN][-SNNNN-CNNNN]--NAME
+
+For example:
+
+	SHA256E-s31390--f50d7ac4c6b9031379986bc362fcefb65f1e52621ce1708d537e740fefc59cc0.mp3
+
+* The backend is one of the [[key-value_backends|backends]], which
+  are always upper-cased.
+* The name field at the end has a format dependent on the backend. It is
+  always the last field, and is prefixed with "--". Unlike other fields,
+  it may contain "-" in its content. It should not contain newline
+  characters or "/"; otherwise nearly anything goes. The "E" variants of
+  hash keys include a filename extension after the hash.
+* The "-s" field is optional, and is the size of the content in bytes.
+* The "-m" field is optional, and is the mtime of the file when it was
+  added to git-annex, expressed as seconds from the epoch.
+  This is currently only used by the WORM backend.
+* The "-S" and "-C" fields are only used for keys that are chunks
+  of some other key. "-S" is the size of the chunk, and "-C" is the chunk
+  number (starting at 1).
+* Other fields could be added in the future, if needed.
+
+git-annex always puts the fields in the order shown above when serializing
+a key. Older versions of git-annex would parse keys with the fields in other
+orders (although the name field must always come last), but the current
+version requires the fields come in the order shown above.
+
+The [[`git annex examinekey`|git-annex-examinekey]] command can be used to extract information from
+a key.
diff --git a/doc/internals/key_format/comment_1_4ec126bffafc81fae04e183874ffce39._comment b/doc/internals/key_format/comment_1_4ec126bffafc81fae04e183874ffce39._comment
new file mode 100644
index 0000000000..8a3e8f7bf1
--- /dev/null
+++ b/doc/internals/key_format/comment_1_4ec126bffafc81fae04e183874ffce39._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Key character set"
+ date="2019-12-10T10:27:58Z"
+ content="""
+Are there limitations on the character set git-annex guarantees?
+
+It appears from experiments that git-annex only uses ASCII characters in there, given both a file 'test.extü' (in UTF-8 encoding) 'test.ext\xff' produced extension-free key names in the SHA256E hash – but it'd be good to have that confirmed.
+"""]]
diff --git a/doc/internals/key_format/comment_2_1e46521ab48805c36233dbb69b11e389._comment b/doc/internals/key_format/comment_2_1e46521ab48805c36233dbb69b11e389._comment
new file mode 100644
index 0000000000..269e30e9cc
--- /dev/null
+++ b/doc/internals/key_format/comment_2_1e46521ab48805c36233dbb69b11e389._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-02-20T20:12:24Z"
+ content="""
+Like git, git-annex tries to be character set agnostic when it comes to
+filenames, including key filenames.
+
+It's certianly possible for a key to contain non-ascii bytes in its name,
+and an extension containing unicode or some other non-ascii value is one
+way that can in fact happen.
+
+(Looks like, in a C locale, ".extü" is 5 chars long, so is considered too
+long to be an extension, while in a unicode locale, it's 4 chars long, so
+is treated as an extension.)
+"""]]
diff --git a/doc/internals/lockdown.mdwn b/doc/internals/lockdown.mdwn
new file mode 100644
index 0000000000..86b5260a12
--- /dev/null
+++ b/doc/internals/lockdown.mdwn
@@ -0,0 +1,48 @@
+Object files stored in `.git/annex/objects` are each put in their own directory.
+This allows the write bit to be removed from both the file, and its directory,
+which prevents accidentally deleting or changing the file contents.
+
+The reasoning for doing this follows:
+
+Normally with git, once you have committed a file, editing the file in the
+working tree cannot cause you to lose the committed version. This is an
+important property of git. Of course you can `rm -rf .git` and delete
+commits if you like (before you've pushed them). But you can't lose a
+committed version of the file because of something you do with the working
+tree version.
+
+It's easy for git to do this, because committing a file makes a copy of it.
+But git-annex does not make a local copy of a file added to it, because
+the file could be very large.
+
+So, it's important for git-annex to find another way to preserve the expected
+property that once committed, you cannot accidentally lose a file.
+The most important protection it makes is just to remove the write bit of
+the file. Thus preventing programs from modifying it.
+
+But, that does not prevent any program that might follow the symlink and
+delete the symlinked file. This might seem an unlikely thing for a program to
+do at first, but consider a command like:
+`tar cf foo.tar foo --remove-files --dereference`
+
+When I tested this, I didn't know if it would remove the file foo symlinked
+to or not! It turned out that my tar doesn't remove it. But it could
+have easily went the other way.
+
+Rather than needing to worry about every possible program that might
+decide to do something like this, git-annex removes the write bit from the
+directory containing the annexed object, as well as removing the write
+bit from the file. (The only bad consequence of this is that `rm -rf .git`
+doesn't work unless you first run `chmod -R +w .git`)
+
+----
+
+It's known that this lockdown mechanism is incomplete. The worst hole in
+it is that if you explicitly run `chmod +w` on an annexed file in the working
+tree, this follows the symlink and allows writing to the file. It would be
+better to make the files fully immutable. But most systems either don't
+support immutable attributes, or only let root make files immutable.
+
+The git configs `annex.freezecontent-command` and `annex.thawcontent-command`
+can be used to run additional commands to further lock down and later thaw
+the annex object and directory.
diff --git a/doc/internals/lockdown/comment_1_caa8b378e8c35177083e6cc2f6937180._comment b/doc/internals/lockdown/comment_1_caa8b378e8c35177083e6cc2f6937180._comment
new file mode 100644
index 0000000000..2260e2f80a
--- /dev/null
+++ b/doc/internals/lockdown/comment_1_caa8b378e8c35177083e6cc2f6937180._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnLM6CIUo2loSFNTLPDdBgAEoz9ehP2hz8"
+ nickname="Duncan"
+ subject="Having the write bit not set can cause problems with automated usage (e.g. build systems)"
+ date="2014-12-02T23:16:57Z"
+ content="""
+I'm using a git-annex to store build artefacts on a remote bare repo. Some of these artefacts are used in subsequent builds, which clone the artefacts repo, and use 'git annex get' to retrieve the artefacts of interest. 
+
+Unfortunately, I've had to add a little kludge along the following lines to my build script fragment:
+
+    git annex get ${file}
+    find .git/annex/objects -type d -exec chmod +w {} \;
+
+This is necessary because I need to ensure that the cloned git repo is able to be deleted at all times (I'm using yocto/openembedded and it may want to delete the clone for a variety of reasons).
+"""]]
diff --git a/doc/internals/lockdown/comment_2_7bf74adb5556b7fc74a94e751c5fd3d6._comment b/doc/internals/lockdown/comment_2_7bf74adb5556b7fc74a94e751c5fd3d6._comment
new file mode 100644
index 0000000000..72d24a283a
--- /dev/null
+++ b/doc/internals/lockdown/comment_2_7bf74adb5556b7fc74a94e751c5fd3d6._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm_YXzEdPHzbSGVwtmTR7g1BqDtTnIBB5s"
+ nickname="Matthias"
+ subject="File immutability"
+ date="2015-01-07T12:06:15Z"
+ content="""
+# setcap cap_linux_immutable+ep /usr/bin/git-annex
+
+After doing that, git-annex is able to make files immutable, so the additional directory is not needed any more.
+Even on file systems / in environments where that is not possible, in some situations file lookup speed is way more important than not being able to delete the target of a symlink.
+
+I have no idea how to code in Haskell, so if somebody else could add an appropriate always/never/only-when-necessary config option I'd be very happy, and my media server would not have any more hiccups when switching songs …
+"""]]
diff --git a/doc/internals/lockdown/comment_3_caf6d5318703d188a2135737093d8323._comment b/doc/internals/lockdown/comment_3_caf6d5318703d188a2135737093d8323._comment
new file mode 100644
index 0000000000..7ddbca9a40
--- /dev/null
+++ b/doc/internals/lockdown/comment_3_caf6d5318703d188a2135737093d8323._comment
@@ -0,0 +1,421 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="How to disable lockdown in bare repos?"
+ date="2022-05-15T21:30:50Z"
+ content="""
+I've set up a project server for my team with annexes in most repos. I'm using [gitolite](https://gitolite.com) with its [git-annex-shell](https://github.com/sitaramc/gitolite/blob/master/src/commands/git-annex-shell) plugin. It's been going well for a year, and my team finds git-annex very useful for managing our large projects, so we have a large debt to you for that :)
+
+## Problem
+
+But when my users delete repos, the repos aren't fully deleted because any `annex/objects/*/*/SHA256-*/SHA256-*` file is locked down.
+
+
+### Gitolite
+
+For example:
+
+<details><summary><code>test-git-annex-write</code></summary>
+
+```
+
+test-gitea-annex-write() {
+REPO=$1; shift
+
+
+(set -e; cd $(mktemp -d)
+  git init
+  echo '# testing' > README.md && git add README.md && git commit -m \"Initial commit\"
+  git annex init
+  dd if=/dev/urandom of=large.bin bs=1M count=16 && git annex add large.bin && git commit -m \"Annex a file\"
+
+  git remote add origin \"$REPO\"
+  git config annex.jobs 1
+  git annex sync --content origin
+  git annex sync --content origin  # it only uploads the branch, but doesn't upload content, if I only do this once
+)
+}
+```
+
+</details>
+
+<details><summary>Create+Upload: <code>test-gitea-annex-write git@data:datasets/test-jank.git</code></summary>
+
+```
+$ test-gitea-annex-write git@data:datasets/test-jank.git
+Initialized empty Git repository in /tmp/tmp.ak87a0yp1e/.git/
+[master (root-commit) 0a7be36] Initial commit
+ 1 file changed, 1 insertion(+)
+ create mode 100644 README.md
+init  ok
+(recording state in git...)
+16+0 records in
+16+0 records out
+16777216 bytes (17 MB, 16 MiB) copied, 0.0608327 s, 276 MB/s
+add large.bin 
+ok                                
+(recording state in git...)
+[master 4a55ea5] Annex a file
+ 1 file changed, 1 insertion(+)
+ create mode 120000 large.bin
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+
+  Unable to parse git config from origin
+FATAL: autocreate denied
+
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+  annex.sshcaching is not set to true
+
+  Unable to parse git config from origin
+FATAL: autocreate denied
+
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+On branch master
+nothing to commit, working tree clean
+commit ok
+pull origin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+FATAL: autocreate denied
+
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+ok
+push origin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+hint: Using 'master' as the name for the initial branch. This default branch name
+hint: is subject to change. To configure the initial branch name to use in all
+hint: of your new repositories, which will suppress this warning, call:
+hint: 
+hint:   git config --global init.defaultBranch <name>
+hint: 
+hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
+hint: 'development'. The just-created branch can be renamed via this command:
+hint: 
+hint:   git branch -m <name>
+Initialized empty Git repository in /srv/git/repositories/datasets/test-jank.git/
+ok
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+On branch master
+nothing to commit, working tree clean
+commit ok
+pull origin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+ok
+copy large.bin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+(to origin...) ok
+pull origin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+ok
+(recording state in git...)
+push origin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+ok
+```
+
+</details>
+
+<details><summary>Delete the repo</summary>
+
+```
+$ ssh git@data D unlock datasets/test-jank
+'datasets/test-jank' is now unlocked
+$ ssh git@data D rm datasets/test-jank
+rm: cannot remove 'datasets/test-jank.git/annex/objects/968/4c0/SHA256E-s16777216--9d8ccb3ebe399a8f6801cde009e03a867151ea4e4bc609848abbd29dd335688f.bin/SHA256E-s16777216--9d8ccb3ebe399a8f6801cde009e03a867151ea4e4bc609848abbd29dd335688f.bin': Permission denied
+'datasets/test-jank' is now gone!
+```
+
+</details>
+
+Notice the \"Permission denied\" error -- but gitolite *thinks* its work is done:
+
+```
+$ ssh git@data info | grep test-jank
+$
+```
+
+but if I try to recreate the same repo, it fails:
+
+<details><summary><code>test-gitea-annex-write git@data:datasets/test-jank.git</code></summary>
+
+```
+$ test-gitea-annex-write git@data:datasets/test-jank.git
+Initialized empty Git repository in /tmp/tmp.IBSNFKRgRg/.git/
+[master (root-commit) e11344b] Initial commit
+ 1 file changed, 1 insertion(+)
+ create mode 100644 README.md
+init  ok
+(recording state in git...)
+16+0 records in
+16+0 records out
+16777216 bytes (17 MB, 16 MiB) copied, 0.0631523 s, 266 MB/s
+add large.bin 
+ok                                
+(recording state in git...)
+[master 0cedc5c] Annex a file
+ 1 file changed, 1 insertion(+)
+ create mode 120000 large.bin
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+
+  Unable to parse git config from origin
+FATAL: R any datasets/test-jank nguenther DENIED by fallthru
+(or you mis-spelled the reponame)
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+
+  Unable to parse git config from origin
+FATAL: R any datasets/test-jank nguenther DENIED by fallthru
+(or you mis-spelled the reponame)
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+On branch master
+nothing to commit, working tree clean
+commit ok
+pull origin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+FATAL: R any datasets/test-jank nguenther DENIED by fallthru
+(or you mis-spelled the reponame)
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+ok
+push origin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+FATAL: W any datasets/test-jank nguenther DENIED by fallthru
+(or you mis-spelled the reponame)
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+FATAL: W any datasets/test-jank nguenther DENIED by fallthru
+(or you mis-spelled the reponame)
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+
+  Pushing to origin failed.
+failed
+sync: 1 failed
+```
+
+</details>
+
+Because of course if I log in on the server I can see:
+
+```
+git@data:~/repositories/datasets$ tree test-jank.git/
+test-jank.git/
+└── annex
+    └── objects
+        └── 968
+            └── 4c0
+                └── SHA256E-s16777216--9d8ccb3ebe399a8f6801cde009e03a867151ea4e4bc609848abbd29dd335688f.bin
+                    └── SHA256E-s16777216--9d8ccb3ebe399a8f6801cde009e03a867151ea4e4bc609848abbd29dd335688f.bin
+
+5 directories, 1 file
+```
+
+
+### Gitea
+
+I've been [porting `git-annex-shell`](https://github.com/neuropoly/gitea/pull/1/) into [Gitea](https://gitea.io/) as well to get a more familiar UI for my team, and I have discovered the exact same problem there: if `test-git-annex-write` to my test instance, then delete that repo, Gitea dutifully reports
+
+> The repository has been deleted.
+
+but if I then try to recreate it balks with
+
+> Files already exist for this repository. Either adopt them or delete them.
+
+## Solutions
+
+There doesn't seem to be much benefit to lockdown in a bare repo: there's no checkout that might corrupt the content. Plus in my case there's gitolite/gitea in the way which is an extra layer of protection against direct modification.  So could **lockdown be turned off**?
+
+I'd like it best if you detected when you're run in a bare repo and skipped the freezing and thawing steps. But I'd also just be able to work with a config setting (`git config --global annex.lockdown false`?).
+
+#### Workaround #1
+
+In the meantime, so far I have found one workaround: I can misuse [`annex.freezecontent-command`](https://git-annex.branchable.com/todo/lockdown_hooks/):
+
+```
+ssh root@data
+su -l git
+git config --global annex.freezecontent-command \"chmod -R +w %path\"
+```
+
+<details><summary>Example</summary>
+
+```
+$ test-gitea-annex-write git@data:datasets/test-jank3
+Initialized empty Git repository in /tmp/tmp.I9wno7oZXg/.git/
+[master (root-commit) 4f47840] Initial commit
+ 1 file changed, 1 insertion(+)
+ create mode 100644 README.md
+init  ok
+(recording state in git...)
+16+0 records in
+16+0 records out
+16388608 bytes (16.2 MB, 16.0 MiB) copied, 0.0313028 s, 268 MB/s
+add large.bin 
+ok                                
+(recording state in git...)
+[master 27e4c8c] Annex a file
+ 1 file changed, 1 insertion(+)
+ create mode 120000 large.bin
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+
+  Unable to parse git config from origin
+FATAL: autocreate denied
+
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+  annex.sshcaching is not set to true
+
+  Unable to parse git config from origin
+FATAL: autocreate denied
+
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+On branch master
+nothing to commit, working tree clean
+commit ok
+pull origin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+FATAL: autocreate denied
+
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+ok
+push origin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+hint: Using 'master' as the name for the initial branch. This default branch name
+hint: is subject to change. To configure the initial branch name to use in all
+hint: of your new repositories, which will suppress this warning, call:
+hint: 
+hint:   git config --global init.defaultBranch <name>
+hint: 
+hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
+hint: 'development'. The just-created branch can be renamed via this command:
+hint: 
+hint:   git branch -m <name>
+Initialized empty Git repository in /srv/git/repositories/datasets/test-jank3.git/
+ok
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+On branch master
+nothing to commit, working tree clean
+commit ok
+pull origin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+ok
+copy large.bin 
+
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+  annex.sshcaching is not set to true
+(to origin...) ok
+pull origin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+ok
+(recording state in git...)
+push origin 
+  You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
+
+  annex.sshcaching is not set to true
+ok
+$ ssh git@data D unlock datasets/test-jank3
+'datasets/test-jank3' is now unlocked
+$ ssh git@data D rm datasets/test-jank3
+'datasets/test-jank3' is now gone!
+```
+
+(notice it doesn't give any error this time)
+
+</details>
+
+But this only works with a relatively new git-annex; I haven't looked up when this went in, but I know 8.20210223, from barely a year ago, doesn't have this feature, while 10.20220322 does. And also it's very much a workaround: it immediately undoes the work git-annex does, which will cause unnecessary disk I/O.
+
+Here's an upgrade to this workaround, that limits the effect to bare repos (though the only repos ever created by the remote `git` user should be bare):
+
+```
+git config --global annex.freezecontent-command 'sh -c '\"'\"'[ \"$(git config core.bare)\" = \"true\" ] && chmod -R +w %path'\"'\"
+```
+
+
+#### Workaround #2
+
+The advice above says to
+
+>  (The only bad consequence of this is that `rm -rf .git` doesn't work unless you first run `chmod -R +w .git`)
+
+so another solution would be to patch gitolite/gitea's `rm` subroutines to be git-annex aware, i.e. to run `chmod -R +w` before doing anything else.
+
+That looks more feasible for me to do in gitea, where git-annex support is turning out to need a whole bunch of patches scattered across the codebase, but it's a lot less appealing to do in gitolite where git-annex support is currently contained in one very elegant file.
+"""]]
diff --git a/doc/internals/lockdown/comment_4_0253bf642148ea853f6d1c8580e09db2._comment b/doc/internals/lockdown/comment_4_0253bf642148ea853f6d1c8580e09db2._comment
new file mode 100644
index 0000000000..ffa3d6f0f5
--- /dev/null
+++ b/doc/internals/lockdown/comment_4_0253bf642148ea853f6d1c8580e09db2._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: How to disable lockdown in bare repos?"""
+ date="2022-05-20T17:08:29Z"
+ content="""
+I think that the annex.freezecontent-command approach is fine. The hook
+runs after git-annex changes permissions, and it can add them back if you
+want. It is supported since 8.20210630
+
+I agree it would be better if gitolite could be modified to only set the
+write bits before deleting the repository. It seems to me that gitolite
+demonstratably has a bug, because you show it fail to delete everything but
+apparently behave as if it succeeded. Perhaps setting the write bits 
+could be justified to the gitolite developers as a way to make it more robust
+when removing a repository, in case some permission problem prevents deleting
+the content of a directory.
+"""]]
diff --git a/doc/internals/lockdown/comment_5_3d7ab5c8e813b21812b5132c708aad68._comment b/doc/internals/lockdown/comment_5_3d7ab5c8e813b21812b5132c708aad68._comment
new file mode 100644
index 0000000000..e48f9ae20a
--- /dev/null
+++ b/doc/internals/lockdown/comment_5_3d7ab5c8e813b21812b5132c708aad68._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="comment 5"
+ date="2022-05-20T18:09:45Z"
+ content="""
+Thanks for your time and your advice, joey. We'll stick with the hook for now then.
+
+I realized I didn't include versions: on my gitolite server I have git-annex 10.20220504. However, that's only because I hacked the environment up so I could use the [conda-forge](https://anaconda.org/conda-forge/git-annex) build as the system git-annex. Because the version in Ubuntu 22.04 is 8.20210223.
+
+That's not really a stable way to run a system, so I am leaning towards reverting and just living with the bug for a while.
+"""]]
diff --git a/doc/internals/pointer_file.mdwn b/doc/internals/pointer_file.mdwn
new file mode 100644
index 0000000000..f109dfd804
--- /dev/null
+++ b/doc/internals/pointer_file.mdwn
@@ -0,0 +1,25 @@
+A pointer file is one of two ways that an annex object can be checked into
+git. The other is a symbolic link pointing to a file in the
+.git/annex/objects/ directory.
+
+A pointer file starts with "/annex/objects/", which is followed
+by the key (see [[key_format]]). (In some situations a pointer file
+might instead contain the content of a symlink target.)
+
+Pointer files usually have a newline after the key. This is not required.
+A carriage return followed by a newline is also accepted, as is end of file.
+
+After that, there is usually nothing more in a pointer file, but git-annex
+does support pointer files with additional text on subsequent lines.
+
+Every such subsequent line has to contain "/annex/" somewhere in it,
+and end in a newline. Otherwise it not considered to be a valid pointer file.
+
+The maximum size of a pointer file is 32 kb. If it is any longer, it is not
+considered to be a valid pointer file.
+
+The possibility exists that a pointer file is in a working tree,
+representing an annex object that is not present, and something appends
+data onto it accidentally. The limitation that each line of a valid
+pointer file contains "/annex/" and that it cannot be larger than 32kb
+let such a situation be detected.
diff --git a/doc/license.mdwn b/doc/license.mdwn
new file mode 100644
index 0000000000..0de299db2c
--- /dev/null
+++ b/doc/license.mdwn
@@ -0,0 +1,6 @@
+git-annex is Free Software, licensed as a whole under the [[AGPL]], version 3 or
+higher.
+
+Parts of git-annex are licensed under the GPL, BSD, and other licenses.
+For details, see
+[this file](http://source.git-annex.branchable.com/?p=source.git;a=blob_plain;f=COPYRIGHT;hb=HEAD).
diff --git a/doc/license/AGPL b/doc/license/AGPL
new file mode 100644
index 0000000000..dba13ed2dd
--- /dev/null
+++ b/doc/license/AGPL
@@ -0,0 +1,661 @@
+                    GNU AFFERO GENERAL PUBLIC LICENSE
+                       Version 3, 19 November 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                            Preamble
+
+  The GNU Affero General Public License is a free, copyleft license for
+software and other kinds of works, specifically designed to ensure
+cooperation with the community in the case of network server software.
+
+  The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+our General Public Licenses are intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+  Developers that use our General Public Licenses protect your rights
+with two steps: (1) assert copyright on the software, and (2) offer
+you this License which gives you legal permission to copy, distribute
+and/or modify the software.
+
+  A secondary benefit of defending all users' freedom is that
+improvements made in alternate versions of the program, if they
+receive widespread use, become available for other developers to
+incorporate.  Many developers of free software are heartened and
+encouraged by the resulting cooperation.  However, in the case of
+software used on network servers, this result may fail to come about.
+The GNU General Public License permits making a modified version and
+letting the public access it on a server without ever releasing its
+source code to the public.
+
+  The GNU Affero General Public License is designed specifically to
+ensure that, in such cases, the modified source code becomes available
+to the community.  It requires the operator of a network server to
+provide the source code of the modified version running there to the
+users of that server.  Therefore, public use of a modified version, on
+a publicly accessible server, gives the public access to the source
+code of the modified version.
+
+  An older license, called the Affero General Public License and
+published by Affero, was designed to accomplish similar goals.  This is
+a different license, not a version of the Affero GPL, but Affero has
+released a new version of the Affero GPL which permits relicensing under
+this license.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+                       TERMS AND CONDITIONS
+
+  0. Definitions.
+
+  "This License" refers to version 3 of the GNU Affero General Public License.
+
+  "Copyright" also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+  "The Program" refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as "you".  "Licensees" and
+"recipients" may be individuals or organizations.
+
+  To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a "modified version" of the
+earlier work or a work "based on" the earlier work.
+
+  A "covered work" means either the unmodified Program or a work based
+on the Program.
+
+  To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+  To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+  An interactive user interface displays "Appropriate Legal Notices"
+to the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+  1. Source Code.
+
+  The "source code" for a work means the preferred form of the work
+for making modifications to it.  "Object code" means any non-source
+form of a work.
+
+  A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+  The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+  The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+  The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+  The Corresponding Source for a work in source code form is that
+same work.
+
+  2. Basic Permissions.
+
+  All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+  You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+  Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+  No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+  When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+  4. Conveying Verbatim Copies.
+
+  You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+  You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+  You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+    a) The work must carry prominent notices stating that you modified
+    it, and giving a relevant date.
+
+    b) The work must carry prominent notices stating that it is
+    released under this License and any conditions added under section
+    7.  This requirement modifies the requirement in section 4 to
+    "keep intact all notices".
+
+    c) You must license the entire work, as a whole, under this
+    License to anyone who comes into possession of a copy.  This
+    License will therefore apply, along with any applicable section 7
+    additional terms, to the whole of the work, and all its parts,
+    regardless of how they are packaged.  This License gives no
+    permission to license the work in any other way, but it does not
+    invalidate such permission if you have separately received it.
+
+    d) If the work has interactive user interfaces, each must display
+    Appropriate Legal Notices; however, if the Program has interactive
+    interfaces that do not display Appropriate Legal Notices, your
+    work need not make them do so.
+
+  A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+  You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+    a) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by the
+    Corresponding Source fixed on a durable physical medium
+    customarily used for software interchange.
+
+    b) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by a
+    written offer, valid for at least three years and valid for as
+    long as you offer spare parts or customer support for that product
+    model, to give anyone who possesses the object code either (1) a
+    copy of the Corresponding Source for all the software in the
+    product that is covered by this License, on a durable physical
+    medium customarily used for software interchange, for a price no
+    more than your reasonable cost of physically performing this
+    conveying of source, or (2) access to copy the
+    Corresponding Source from a network server at no charge.
+
+    c) Convey individual copies of the object code with a copy of the
+    written offer to provide the Corresponding Source.  This
+    alternative is allowed only occasionally and noncommercially, and
+    only if you received the object code with such an offer, in accord
+    with subsection 6b.
+
+    d) Convey the object code by offering access from a designated
+    place (gratis or for a charge), and offer equivalent access to the
+    Corresponding Source in the same way through the same place at no
+    further charge.  You need not require recipients to copy the
+    Corresponding Source along with the object code.  If the place to
+    copy the object code is a network server, the Corresponding Source
+    may be on a different server (operated by you or a third party)
+    that supports equivalent copying facilities, provided you maintain
+    clear directions next to the object code saying where to find the
+    Corresponding Source.  Regardless of what server hosts the
+    Corresponding Source, you remain obligated to ensure that it is
+    available for as long as needed to satisfy these requirements.
+
+    e) Convey the object code using peer-to-peer transmission, provided
+    you inform other peers where the object code and Corresponding
+    Source of the work are being offered to the general public at no
+    charge under subsection 6d.
+
+  A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+  A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, "normally used" refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+  "Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+  If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+  The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+  Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+  7. Additional Terms.
+
+  "Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+  When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+  Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+    a) Disclaiming warranty or limiting liability differently from the
+    terms of sections 15 and 16 of this License; or
+
+    b) Requiring preservation of specified reasonable legal notices or
+    author attributions in that material or in the Appropriate Legal
+    Notices displayed by works containing it; or
+
+    c) Prohibiting misrepresentation of the origin of that material, or
+    requiring that modified versions of such material be marked in
+    reasonable ways as different from the original version; or
+
+    d) Limiting the use for publicity purposes of names of licensors or
+    authors of the material; or
+
+    e) Declining to grant rights under trademark law for use of some
+    trade names, trademarks, or service marks; or
+
+    f) Requiring indemnification of licensors and authors of that
+    material by anyone who conveys the material (or modified versions of
+    it) with contractual assumptions of liability to the recipient, for
+    any liability that these contractual assumptions directly impose on
+    those licensors and authors.
+
+  All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+  If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+  Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+  8. Termination.
+
+  You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+  However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated (a)
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and (b) permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+  Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+  Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+  You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+  Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+  An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+  You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+  11. Patents.
+
+  A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's "contributor version".
+
+  A contributor's "essential patent claims" are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+  Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+  In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+  If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  "Knowingly relying" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+  If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+  A patent license is "discriminatory" if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license (a) in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or (b) primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+  Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+  If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+  13. Remote Network Interaction; Use with the GNU General Public License.
+
+  Notwithstanding any other provision of this License, if you modify the
+Program, your modified version must prominently offer all users
+interacting with it remotely through a computer network (if your version
+supports such interaction) an opportunity to receive the Corresponding
+Source of your version by providing access to the Corresponding Source
+from a network server at no charge, through some standard or customary
+means of facilitating copying of software.  This Corresponding Source
+shall include the Corresponding Source for any work covered by version 3
+of the GNU General Public License that is incorporated pursuant to the
+following paragraph.
+
+  Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the work with which it is combined will remain governed by version
+3 of the GNU General Public License.
+
+  14. Revised Versions of this License.
+
+  The Free Software Foundation may publish revised and/or new versions of
+the GNU Affero General Public License from time to time.  Such new versions
+will be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+  Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU Affero General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU Affero General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+  If the Program specifies that a proxy can decide which future
+versions of the GNU Affero General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+  Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+  15. Disclaimer of Warranty.
+
+  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+  If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+
+                     END OF TERMS AND CONDITIONS
+
+            How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software: you can redistribute it and/or modify
+    it under the terms of the GNU Affero General Public License as published by
+    the Free Software Foundation, either version 3 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU Affero General Public License for more details.
+
+    You should have received a copy of the GNU Affero General Public License
+    along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+Also add information on how to contact you by electronic and paper mail.
+
+  If your software can interact with users remotely through a computer
+network, you should also make sure that it provides a way for users to
+get its source.  For example, if your program is a web application, its
+interface could display a "Source" link that leads users to an archive
+of the code.  There are many ways you could offer source, and different
+solutions will be better for different programs; see section 13 for the
+specific requirements.
+
+  You should also get your employer (if you work as a programmer) or school,
+if any, to sign a "copyright disclaimer" for the program, if necessary.
+For more information on this, and how to apply and follow the GNU AGPL, see
+<http://www.gnu.org/licenses/>.
diff --git a/doc/license/GPL b/doc/license/GPL
new file mode 100644
index 0000000000..94a9ed024d
--- /dev/null
+++ b/doc/license/GPL
@@ -0,0 +1,674 @@
+                    GNU GENERAL PUBLIC LICENSE
+                       Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                            Preamble
+
+  The GNU General Public License is a free, copyleft license for
+software and other kinds of works.
+
+  The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.  We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors.  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+  To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received.  You must make sure that they, too, receive
+or can get the source code.  And you must show them these terms so they
+know their rights.
+
+  Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+
+  For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+  Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so.  This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software.  The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable.  Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products.  If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+
+  Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary.  To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+                       TERMS AND CONDITIONS
+
+  0. Definitions.
+
+  "This License" refers to version 3 of the GNU General Public License.
+
+  "Copyright" also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+  "The Program" refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as "you".  "Licensees" and
+"recipients" may be individuals or organizations.
+
+  To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a "modified version" of the
+earlier work or a work "based on" the earlier work.
+
+  A "covered work" means either the unmodified Program or a work based
+on the Program.
+
+  To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+  To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+  An interactive user interface displays "Appropriate Legal Notices"
+to the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+  1. Source Code.
+
+  The "source code" for a work means the preferred form of the work
+for making modifications to it.  "Object code" means any non-source
+form of a work.
+
+  A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+  The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+  The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+  The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+  The Corresponding Source for a work in source code form is that
+same work.
+
+  2. Basic Permissions.
+
+  All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+  You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+  Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+  No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+  When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+  4. Conveying Verbatim Copies.
+
+  You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+  You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+  You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+    a) The work must carry prominent notices stating that you modified
+    it, and giving a relevant date.
+
+    b) The work must carry prominent notices stating that it is
+    released under this License and any conditions added under section
+    7.  This requirement modifies the requirement in section 4 to
+    "keep intact all notices".
+
+    c) You must license the entire work, as a whole, under this
+    License to anyone who comes into possession of a copy.  This
+    License will therefore apply, along with any applicable section 7
+    additional terms, to the whole of the work, and all its parts,
+    regardless of how they are packaged.  This License gives no
+    permission to license the work in any other way, but it does not
+    invalidate such permission if you have separately received it.
+
+    d) If the work has interactive user interfaces, each must display
+    Appropriate Legal Notices; however, if the Program has interactive
+    interfaces that do not display Appropriate Legal Notices, your
+    work need not make them do so.
+
+  A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+  You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+    a) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by the
+    Corresponding Source fixed on a durable physical medium
+    customarily used for software interchange.
+
+    b) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by a
+    written offer, valid for at least three years and valid for as
+    long as you offer spare parts or customer support for that product
+    model, to give anyone who possesses the object code either (1) a
+    copy of the Corresponding Source for all the software in the
+    product that is covered by this License, on a durable physical
+    medium customarily used for software interchange, for a price no
+    more than your reasonable cost of physically performing this
+    conveying of source, or (2) access to copy the
+    Corresponding Source from a network server at no charge.
+
+    c) Convey individual copies of the object code with a copy of the
+    written offer to provide the Corresponding Source.  This
+    alternative is allowed only occasionally and noncommercially, and
+    only if you received the object code with such an offer, in accord
+    with subsection 6b.
+
+    d) Convey the object code by offering access from a designated
+    place (gratis or for a charge), and offer equivalent access to the
+    Corresponding Source in the same way through the same place at no
+    further charge.  You need not require recipients to copy the
+    Corresponding Source along with the object code.  If the place to
+    copy the object code is a network server, the Corresponding Source
+    may be on a different server (operated by you or a third party)
+    that supports equivalent copying facilities, provided you maintain
+    clear directions next to the object code saying where to find the
+    Corresponding Source.  Regardless of what server hosts the
+    Corresponding Source, you remain obligated to ensure that it is
+    available for as long as needed to satisfy these requirements.
+
+    e) Convey the object code using peer-to-peer transmission, provided
+    you inform other peers where the object code and Corresponding
+    Source of the work are being offered to the general public at no
+    charge under subsection 6d.
+
+  A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+  A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, "normally used" refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+  "Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+  If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+  The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+  Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+  7. Additional Terms.
+
+  "Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+  When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+  Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+    a) Disclaiming warranty or limiting liability differently from the
+    terms of sections 15 and 16 of this License; or
+
+    b) Requiring preservation of specified reasonable legal notices or
+    author attributions in that material or in the Appropriate Legal
+    Notices displayed by works containing it; or
+
+    c) Prohibiting misrepresentation of the origin of that material, or
+    requiring that modified versions of such material be marked in
+    reasonable ways as different from the original version; or
+
+    d) Limiting the use for publicity purposes of names of licensors or
+    authors of the material; or
+
+    e) Declining to grant rights under trademark law for use of some
+    trade names, trademarks, or service marks; or
+
+    f) Requiring indemnification of licensors and authors of that
+    material by anyone who conveys the material (or modified versions of
+    it) with contractual assumptions of liability to the recipient, for
+    any liability that these contractual assumptions directly impose on
+    those licensors and authors.
+
+  All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+  If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+  Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+  8. Termination.
+
+  You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+  However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated (a)
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and (b) permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+  Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+  Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+  You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+  Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+  An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+  You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+  11. Patents.
+
+  A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's "contributor version".
+
+  A contributor's "essential patent claims" are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+  Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+  In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+  If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  "Knowingly relying" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+  If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+  A patent license is "discriminatory" if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license (a) in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or (b) primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+  Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+  If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+  13. Use with the GNU Affero General Public License.
+
+  Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU Affero General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the special requirements of the GNU Affero General Public License,
+section 13, concerning interaction through a network will apply to the
+combination as such.
+
+  14. Revised Versions of this License.
+
+  The Free Software Foundation may publish revised and/or new versions of
+the GNU General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+  Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+  If the Program specifies that a proxy can decide which future
+versions of the GNU General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+  Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+  15. Disclaimer of Warranty.
+
+  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+  If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+
+                     END OF TERMS AND CONDITIONS
+
+            How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software: you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation, either version 3 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+Also add information on how to contact you by electronic and paper mail.
+
+  If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+
+    <program>  Copyright (C) <year>  <name of author>
+    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, your program's commands
+might be different; for a GUI interface, you would use an "about box".
+
+  You should also get your employer (if you work as a programmer) or school,
+if any, to sign a "copyright disclaimer" for the program, if necessary.
+For more information on this, and how to apply and follow the GNU GPL, see
+<http://www.gnu.org/licenses/>.
+
+  The GNU General Public License does not permit incorporating your program
+into proprietary programs.  If your program is a subroutine library, you
+may consider it more useful to permit linking proprietary applications with
+the library.  If this is what you want to do, use the GNU Lesser General
+Public License instead of this License.  But first, please read
+<http://www.gnu.org/philosophy/why-not-lgpl.html>.
diff --git a/doc/links/key_concepts.mdwn b/doc/links/key_concepts.mdwn
new file mode 100644
index 0000000000..b1b037789c
--- /dev/null
+++ b/doc/links/key_concepts.mdwn
@@ -0,0 +1,7 @@
+### key concepts
+
+* [[git-annex man page|git-annex]]
+* [[how_it_works]]
+* [[special_remotes]]
+* [[workflows|workflow]]
+* [[sync]]
diff --git a/doc/links/other_stuff.mdwn b/doc/links/other_stuff.mdwn
new file mode 100644
index 0000000000..b1645d8cbe
--- /dev/null
+++ b/doc/links/other_stuff.mdwn
@@ -0,0 +1,9 @@
+### other stuff
+
+* [[testimonials]]
+* [[privacy]]
+* [[what git annex is not|not]]
+* [[related_software]]
+* [[public git-annex repos|publicrepos]]
+* [[thanks]]
+* [[sitemap]]
diff --git a/doc/links/the_details.mdwn b/doc/links/the_details.mdwn
new file mode 100644
index 0000000000..cb18d5b2b7
--- /dev/null
+++ b/doc/links/the_details.mdwn
@@ -0,0 +1,9 @@
+### the details
+
+* [[encryption]]
+* [[key-value backends|backends]]
+* [[bare_repositories]]
+* [[submodules]]
+* [[internals]]
+* [[scalability]]
+* [[design]]
diff --git a/doc/location_tracking.mdwn b/doc/location_tracking.mdwn
new file mode 100644
index 0000000000..d40a7206fd
--- /dev/null
+++ b/doc/location_tracking.mdwn
@@ -0,0 +1,30 @@
+git-annex keeps track of in which repositories it last saw a file's content.
+This location tracking information is stored in the git-annex branch.
+Repositories record their UUID and the date when they get or drop 
+a file's content.
+
+This location tracking information is useful if you have multiple
+repositories, and not all are always accessible. For example, perhaps one
+is on a home file server, and you are away from home. Then git-annex can
+tell you what git remote it needs access to in order to get a file:
+
+	# git annex get myfile 
+	get myfile (not available)
+	  I was unable to access these remotes: home
+
+Another way the location tracking comes in handy is if you put repositories
+on removable USB drives, that might be archived away offline in a safe
+place. In this sort of case, you probably don't have a git remotes
+configured for every USB drive. So git-annex may have to resort to talking
+about repository UUIDs. If you have previously used "git annex init"
+to attach descriptions to those repositories, it will include their
+descriptions to help you with finding them:
+
+	# git annex get myfile
+	get myfile (not available)
+	  Try making some of these repositories available:
+	  	c0a28e06-d7ef-11df-885c-775af44f8882  -- USB archive drive 1
+	  	e1938fee-d95b-11df-96cc-002170d25c55
+
+In certain cases you may want to configure git-annex to [[trust]]
+that location tracking information is always correct for a repository.
diff --git a/doc/logo-old-bw.svg b/doc/logo-old-bw.svg
new file mode 100644
index 0000000000..11d362e5f1
--- /dev/null
+++ b/doc/logo-old-bw.svg
@@ -0,0 +1,60 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="640px"
+   height="480px"
+   id="svg3134"
+   version="1.1"
+   inkscape:version="0.48.3.1 r9886"
+   sodipodi:docname="New document 11">
+  <defs
+     id="defs3136" />
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.77472527"
+     inkscape:cx="317.41844"
+     inkscape:cy="245.16312"
+     inkscape:current-layer="layer1"
+     inkscape:document-units="px"
+     showgrid="false"
+     inkscape:window-width="800"
+     inkscape:window-height="564"
+     inkscape:window-x="0"
+     inkscape:window-y="12"
+     inkscape:window-maximized="0" />
+  <metadata
+     id="metadata3139">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title></dc:title>
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     id="layer1"
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer">
+    <path
+       style="fill:#000000"
+       d="m 302.43431,440.4468 c -14.88228,-4.33874 -18.89443,-6.47398 -28.38217,-15.10481 -13.08558,-11.90371 -17.72561,-23.29726 -17.72561,-43.52501 0,-18.30772 4.14768,-29.96528 14.34194,-40.30981 7.27131,-7.37848 18.36439,-13.25052 25.03206,-13.25052 4.73347,0 4.8315,0.27458 4.8315,13.5325 l 0,13.5325 -6.57204,3.04787 c -9.16684,4.25125 -13.05127,12.36242 -12.09267,25.25093 1.53891,20.69072 13.75689,28.81207 43.34566,28.81207 14.25099,0 19.3577,-0.72886 23.91428,-3.41316 12.51899,-7.37499 18.80704,-23.65294 14.28477,-36.97908 -2.56222,-7.55028 -13.65238,-17.88336 -19.19364,-17.88336 -3.36269,0 -3.73837,1.31029 -3.73837,13.03841 l 0,13.0384 -11.88928,-0.55077 -11.88929,-0.55079 0,-25.90026 0,-25.90027 35.19228,0 35.19228,0 0.57499,9.7126 c 0.49269,8.32267 0.0845,9.71665 -2.85343,9.74093 -8.20311,0.0677 -8.706,2.84359 -2.15276,11.88256 6.12053,8.44215 6.33349,9.33743 6.33349,26.62529 0,15.38301 -0.65924,19.1446 -4.70538,26.84845 -9.93611,18.91837 -28.93477,29.1492 -56.00199,30.15722 -10.88743,0.40545 -20.4551,-0.28006 -25.84662,-1.85189 z m -45.65485,-139.01542 0,-13.87514 65.62885,0 65.62884,0 0,13.87514 0,13.87514 -65.62884,0 -65.62885,0 0,-13.87514 z m 49.45942,-38.8504 0,-15.72516 -24.72971,0 -24.72971,0 0,-12.95013 0,-12.95014 24.72971,0 24.72971,0 0,-16.65017 0,-16.65017 15.21829,0 15.21828,0 0,16.65017 0,16.65017 25.68085,0 25.68085,0 0,12.89643 0,12.89645 -25.20528,0.51619 -25.20528,0.51621 -0.5525,15.26265 -0.5525,15.26266 -15.14135,0 -15.14136,0 0,-15.72516 z m 90.58314,-28.97078 c -1.413,-6.87082 -1.79669,-6.34506 5.78198,-7.92291 5.58749,-1.16331 6.09939,-0.83956 7.33692,4.64003 1.45579,6.44604 -0.79787,9.0505 -7.87441,9.1001 -3.02463,0.0211 -4.34501,-1.44337 -5.24449,-5.81722 z m -160.69546,0.49827 c -1.79783,-1.10787 -2.17745,-3.37832 -1.25087,-7.48118 1.23754,-5.47959 1.74944,-5.80335 7.33693,-4.64004 7.57866,1.57785 7.19497,1.05209 5.78198,7.92291 -1.24077,6.03343 -6.10031,7.75249 -11.86804,4.19831 z m 190.42463,-6.76941 c -1.85277,-5.87101 -1.66966,-6.25919 3.83255,-8.12458 3.17805,-1.07743 5.9948,-1.95896 6.25947,-1.95896 0.91633,0 4.67209,11.70301 3.97372,12.38219 -0.38574,0.37517 -3.27056,1.39869 -6.41068,2.27453 -5.34046,1.48954 -5.83503,1.19409 -7.65506,-4.57318 z m -216.85329,0.64986 c -3.40034,-0.87401 -6.18243,-1.85733 -6.18243,-2.18515 0,-0.32782 0.94953,-3.24505 2.11007,-6.48271 1.73496,-4.84015 2.83405,-5.67166 6.18243,-4.67733 7.88037,2.34017 8.42794,3.15845 6.18018,9.23554 -1.96709,5.31825 -2.52062,5.59264 -8.29025,4.10965 z m 245.52541,-10.67191 c -2.12815,-5.48318 -2.11652,-5.49574 11.85359,-12.82409 22.7641,-11.94143 40.5838,-25.97488 57.05249,-44.93026 l 7.53031,-8.66734 5.41145,4.25151 5.41145,4.25151 -17.60152,17.90565 c -16.73035,17.01941 -37.6183,32.42395 -56.39658,41.59159 -10.27596,5.01677 -10.722,4.96367 -13.26119,-1.57857 z m -286.33038,-6.27889 c -21.55151,-11.9442 -31.63729,-19.70355 -49.98909,-38.45829 l -16.54083,-16.90401 5.39695,-4.24028 5.39696,-4.24026 7.53031,8.66734 c 16.46869,18.95538 34.28839,32.98883 57.05248,44.93026 13.97012,7.32835 13.98175,7.34091 11.8536,12.82409 -1.17162,3.01872 -3.03333,5.48856 -4.13709,5.48856 -1.10378,0 -8.55726,-3.63034 -16.56329,-8.06741 z m 375.66016,-70.84688 c -3.97648,-2.69927 -4.05764,-3.18834 -1.36824,-8.24615 2.7937,-5.254 2.98784,-5.31188 8.50732,-2.53606 6.47782,3.25777 6.35114,2.92151 3.44074,9.13364 -2.52039,5.37967 -4.60478,5.70447 -10.57982,1.64857 z M 89.683687,134.84263 c -2.910382,-6.21213 -3.037055,-5.87587 3.440759,-9.13364 5.520337,-2.77624 5.713305,-2.71854 8.512274,2.54533 2.72546,5.12566 2.63957,5.52893 -1.77689,8.3432 -6.255304,3.98601 -7.594703,3.75504 -10.176143,-1.75489 z M 558.86885,114.49806 c -4.66412,-2.46246 -4.94939,-3.21135 -3.14292,-8.25101 1.09275,-3.04849 2.20334,-5.54273 2.46799,-5.54273 1.15984,0 12.46263,4.10838 12.46263,4.52996 0,2.20567 -4.45138,12.10382 -5.41738,12.04614 -0.68234,-0.0407 -3.54898,-1.29279 -6.37032,-2.78236 z M 76.248436,107.82834 c -1.1486,-3.20438 -2.088367,-6.03672 -2.088367,-6.2941 0,-0.42158 11.30279,-4.529954 12.462632,-4.529954 0.264646,0 1.376722,2.498376 2.471297,5.551964 1.832586,5.11256 1.553673,5.77145 -3.524022,8.32508 -7.178882,3.61035 -6.90035,3.70158 -9.32154,-3.05299 z M 568.27869,86.478917 c -4.16144,-1.0576 -4.15124,-1.435966 0.47558,-17.673656 4.71707,-16.554414 4.76128,-15.866207 -0.95115,-14.804204 -3.51666,0.653779 -4.75571,0.08973 -4.75571,-2.164633 0,-1.67682 1.09334,-3.456779 2.42964,-3.95547 1.33629,-0.498709 4.53447,-4.218875 7.10707,-8.267031 3.85384,-6.064326 5.73436,-7.360301 10.68013,-7.360301 4.78765,0 6.24005,0.919681 7.17525,4.543462 0.64491,2.498894 2.13408,6.869564 3.30925,9.712599 4.714,11.40422 2.47433,18.328434 -4.06643,12.571786 -3.92535,-3.4548 -3.4906,-4.351652 -9.63904,19.885132 -2.24473,8.848659 -3.45803,9.62341 -11.76459,7.512316 z M 62.514449,66.506779 57.950276,48.599557 52.639,52.662624 c -2.921206,2.234675 -5.630041,3.75306 -6.019648,3.374157 -0.389608,-0.378884 0.859281,-4.428205 2.775301,-8.998492 1.916001,-4.570287 3.965028,-9.76649 4.553405,-11.547134 0.734891,-2.224093 3.046111,-3.237533 7.383397,-3.237533 5.021102,0 8.14882,1.812001 15.277977,8.851138 4.930401,4.868122 8.964349,10.279427 8.964349,12.025124 0,4.517598 -2.081195,3.939726 -6.8916,-1.913568 -2.299596,-2.798153 -4.818203,-4.473179 -5.596904,-3.722293 -0.778719,0.750904 0.522064,8.499468 2.890599,17.219014 2.368555,8.719565 3.936551,16.213492 3.484473,16.653149 -0.452097,0.439676 -3.422934,1.3053 -6.601862,1.923613 l -5.779866,1.12422 -4.564172,-17.90724 z"
+       id="path3050"
+       inkscape:connector-curvature="0" />
+  </g>
+</svg>
diff --git a/doc/logo-old.png b/doc/logo-old.png
new file mode 100644
index 0000000000000000000000000000000000000000..38d335a4514173cc21b1049c3de4b75055a502bf
GIT binary patch
literal 9092
zcmZX41yqz@(EfsSDBZO*64D^uDF`bFD4o(Eury1vbcb{b2$IrW(k|U05=wX1_wqac
z|2f||-?G5o_r3SdotbBznR(BKYp5&YVo_j$Kp<RYB{>KPgv17X-oQWu{`RI#=mY<d
zTp)@vpo(8q+rR+LR8>(9^!W6X+g6+iT)}iw(sKcUunC`jkwEF0WWYsqS7kMM^abqa
z&*+%=8?)SjOXRNdx~{U0_VyMIt{~aZ7ACG1=5+4XuAk@>mDMzK0-lqCKy)BwIcY7A
zh5cnu53T7niKELEJ>Ee^MzFVx%=?+(V6`}T{i>4a8^U`DqG}TTDmZbGjloV}-}jdh
zs`k?QPO`Sdk#!|*7OEJk12V`+GD>vjU(9Q)>b+sGF=b3}twqAfn-#?A8QT^YpUdGF
z_g}9sS6oo^QY<q2-=Q0I!faqNj;8#YS57w>bo4u;p(mF|etj%$Tse||Z0@++N=JR+
zZJbra8XyhZlK#>dn`~5ik;+MGfdSh&E0-+%hid4h%SzmkBgc=HJo$QK%>zj5y9Y1=
z4gcIOI=K}t%c*ErQQH7st&6*9+;It89cUq@<tc%eD9RU?H1!^MiMlrZ3QPJm<}c%0
z{m${<azyM=XF$J)B^(2EbeE^ITwh58u2W476I2xiNrB<d4_PanC9^p_!>z*Lb*z~?
zuB{ylh7M;+d9a*^x3e9bH5*eIx6NDLXvE`q?yCWcS-)^UCjDjp-L*9#(I&l%Eg^hi
zn9Z3F-k2PEb)?>>Sk?Jw<{nz6+~zlReVff3`bH{=xkgdr_2-Z{xKGbQkK^xGibA=g
zOIs5ck)ItJXdxo9&xRIXdX;nY(yeU$;**`Iw!T3diERF{xJt|FlPN9FkFp^|VtQIy
zNhb^Sq%9VCd+C)brK7YzvDrocSeXvB-_yQY`@`8tf5V$0x;pETTjnVw;A%R%s+NHH
z(YAe^obklDlG@-f<-YafvF0H-c~uu4O`OsEkXEkNUHRwlGtfjJ#O~lq&Rcu7<1zEv
zyum{8L+mjQ!FA(|OS%V^bih<6WASC;#IT^1%(qfJw@@z-pcFxeY8&<VgC@vdGk^^b
zHE))BS4~aWb7q~VgS@F~cQrtT6G0ar+X6nI2>vFESBTR)wU&6)9V`i!!vB5d2YHr=
zxOHa&nWI|KNp8G(9RCw9M9<D&U>icGjYoj|$GLSsc$C>F6E^Z?KhZ(%y%O5VdB_0P
z;BP>k^SFo(5}{tB#kLT)sv+oi<qUX%eSgd2@tqm9)IWQo;97CmKVl#4d;7}a%7`Ya
z%h>h|t4O$0O#y|_=7mH}04v6v*!r`jj7O)~+#A4le;p6z6D91*M>lWJSG<WGZ!h*a
zwB;Pk+tOw-g8e;EN&}C!rgY-T6IRYIYajPrmF8{hwcRrn?5(nNXvXwvEvvQgn>4M5
zO)`f2aVeM25BnG#<t&v%cmZ#EY()PxFxno7{CTCw03kHtg9D0O$)6R8$;!!QwxvwZ
zbJmuR;j~iSM2((P`vuM!+S_!r`&)&5f|u==%ewV%OIU;tg9UiZWpXAG;XX#~Syb>T
zIl7;c%`llE!<%W>na{!|`QX(lb|+iTq0+dB89Dl!O!RO>@?ur0Rrn{RFfEgu59YpD
zY@jr%bPJbj2hpGk!uUgxY0c>LUkhDj%1E6*s@Mcm|Nc7}v)<mAr>6+qt1G0kjy``~
z$Q<&<A5!HzD??-ZPEIzVEhVWfCGDe(O4$^>_}s<v-^E=Qk9v4$nz|~>XID>OoA4&4
zLXffL75}33LSyCIAS3+v%j(%c2$ss5&v}znPDe4PwWC-ac$Ku<5+hX#d0ju&5_#Bt
zM81Zpg@6LAqCa5(vsGTuV1JL46?#n#8BbR#L}f0R(TF8qo8*3)7;Guc`OWhyJd}={
z7b<kH`wn}ABrMeCwT`_Nb@zQY9Tq(T4?k~uDU`~9rhfJ>U4w~ZY}p;H+UoC#Wbstl
z2zZH*!XR8c`g+bVCn)Q@34Vs%-^^x<Ue7Eqw}GLYqTx6Oh7fke(bKQ?sx#43c!8%)
zwtHtLSI--@1K<OCD((m6C8a2j-ySF=r}w48iU^TWMrfS{0MZkikmDBy7xD4`&PYG3
zK0k9`X2wGOwIq3bxZ~)oI-v&Km)JUIaHMDA#&n^#>^92VZkXM6>AxoIL;NXjrfw_F
z&F!6uln9a0I4UQ&hVT5M;23J6<~6@!=T9T#A?%3yVs$xhsB_lzc4z2clVECw1s`+=
zdJ4>qgXzE)&!Z~pUfj6f(snvRU-c-mNQC?v`~4a$;C96rd>b;a|971*=NOob5oy<@
z$nxO4V!^UdR&_Af;&DD8g1}_c#M__w8j+!@IpY;&l{$dFH?<$CCwN&JB9IG41<hCM
z%<Z{QltwGIG-W;Ap0gznxeYPdIZ}4;7H?Pz#M>r~`LZ^7<g)zB0fxXD><qlx<>s`*
z3UdUXAX$9x*I3fGX&~AB)rGzU&6&DuEIW2tR)+_|BfG7PrSIIx`0R)fFXLZW3pJP(
z3ephUC;v65z#|%nY3u%8xjkcbDIs#q#ubycdA0$Q+YmP&7?|Gg>QBzOOv5?Lhm-3H
z0BHi3jh^CzO2&)z^&!Nu%e}f%O>k;$wlolmfaAqf-TJNXbQ`F#2_2kn+sPqv8{=p`
zB_u)Sy{l#IQU#ibg12%|HuRkk^MR|IvrCWLEA*26@}9w%ca1Fe<OmQxuAj>*od$H6
z=*4q@vma7p0tpTck4SrO`j0s9JWCV`XdX-NF=u-XF*~Hw@xK|#?iinf%Ox)yVuzF7
zlPZpMudhFLCP;1M8FG0)Gs?WficiPjP}UFj98Z0I6+M4X0!iRln{9zbzN4NNob`75
zlXGj~flj}Z0gSIk4@6tUi&G1!!$lKFTf{7y*>AqD>l4W>B{U8kcvVvCA*|=a#l~*T
zD80p$^jF>opkwQ-t=xq<S6#=shY^AFDcta%n7+cLqzEVH{e2=+;6M<OK=SYY=KVG<
z#4PEb(gafQV1j#C5(r5(k#tet%2k7+Muu1SC0r~Rha8aL=-&2`fE0ItW9!}zyE|!&
z<IRhV2r2`^hK^gdJ15(TN*+nB3|VYK&$zc`58<+$7J{?N*eYE`nxvjE7le)Hj=e_s
zw~EJXK_A|gFE^xjt8iO#4LKTScE)D~K@&h?=l4AJH`t`C>Ni~xtH*y7xyL<FF^CwZ
ze`TsncVbL3ABa%*3&-6&>@wzY{U|7I_cD9X!>)5>*gqsmnz#EC51kTmFM-qsle+uN
zpUobav_p>}$X`Wk?R#mZNieMZFoX!-v+~de_S05zW-WERqtkv+=*2%<Z*!&OIvUw3
zUJSq?DbML&jGNj7d{`6u9orAjcEtnWu(v_NvFc9yKDCvb?$Q`9-Yif{I_TssyFXZ~
zwiGp%L_9=ic&3Z-i^iNQ-XYB+oGGY;b{ab4dFSdvgAYMf>udByEYE4?EbbptvJ0L!
zc0|CJWD}Umxjd1EFPFm*>JG<q{gY^QZ&ebQT48?(?ZnzKN#;MVxXEaBUF~iNz$fHt
zfE+WvxJhel*7p^#A-M$ZizveY6B;P0pN1`@e<5ZOhZQuIkzQrDdg#4WCM{PnJih6M
z%?bj<MlN11MF)O04NcOvG3HHSoTp{W8!zckWJ1(3WDVfjh}a(MZ!es3l?hClSv)Yz
z=~fS#wL1o_u(+9Z<342#_cnkkb=~)<Q@HabxOH)K>klshSzZSH^dGB^ub8Q9MSsO1
z|B6aFI+{zyIHh!OUyfy$>}N^NsV&5Bl1g9_(>rOEP0Zy`{t!IXX&#z1?c~P#KH3{k
zW&9x*$C1hxTNKfRr6hOpUGySGb~S4-Pp`3>b_;R36Nl`7++|ixfBrmd#<%d3+ib0z
zocSuS@wyrM2e64>&oLnJnM6#JPB0P3yx(x`2&d#Nkz{1|*B}mGIp|(FqK{H>wWcK-
zqGdYWh|Z%=y`y<(boS$!*GB-a3_j`0=OUb09#u}n0Q2c#g?q&>R*}XMeTRNpCN6b1
zZbes*_~Q&_!lI|4^p;dWEm|;WSYC>eBoYhojYij{2>+!CxEv6;JJt;FiWGE@nCAMm
z+*_Y_epr&_>M#_ZhjHkvJzvAxTE1kSlu<84`OK(qwCG77AQw8Dg)f2Iz;wT0CK>s!
z)RCk66&2#G2Lbq-amy|R2U__63`5kdMNh<fU~$$11Y`9;-rs_@?8acJ^qH9*(#ByD
z>u(+htx(%@_76Ra&7Gh6qw(%|<%b2$M|-9nN7Ng7F^#KW+1U8LD@8N=89w+C_T@js
z1~G$6N*z_-(~9Y(t+5-S*gIkpmgRq%shZ(8i|We`VvsAAuo+xU)b%=L1j8@MpX-vT
zvpBT+3qE9*#A2a>=s`Bns}K*@rTb;eQt*kkQT9Sa>d=bQKhGAEZ*=8@K3Hr4%7(}D
ztu|4of4&mj<vAtyNE5HqM(fmM%QqU4sq$PilJl;xJy!L@(b_PzY^s@0*;@D_`3i65
z&RRNt^YDL3r>>Zh5PU#-gY%`6Kuw~L@yk(h5W?)^Jy+Pw?8`b2lkP+yWhCkNs#j)m
zZpnEQKWH2Y1A#B{qn#Dr$h6J8l;-s8wse4Hiqf@F^if*NJrgRNn?3BY#Naq{HW-Ht
z%Bn_sL0taX#%Jre=clpT4K05Db4xb&dOh&4@Uq_eNs$e?e@=-4{3TgnCv8OgT;;3I
z#6DR4>!qRjK<%ERyI_{KZ{dFlf!w&C@?6aDjQ@gvOY|WCZ0z=vmWN>vIR(m+L9*VF
z9b>%7omww6OfnLl7EW6GUKY&iA!UH&MNXT2MdX;=ad_nK3KTkGLMFrn$O<0&e=lwZ
zrAHIUZHFHsUX^t~ZCZ@v3<6swQs|Y)2PO`UmDFw>xB|7gLX*t9MvkmKUao7hie3Gb
zep@6YxE3p4mgV(cfRmdX@y3J7WM|Fre!i{!2dg}jpX3eKQnFXeyN<EdsXPCVCkNfJ
zb&J=ybg}jC8YoZQ9~Mge(+Sc;QduN+&yi3;Dn_s4XJZ@DtOEvh-Hs5SxCKRisI^Il
zX`|=#ymb?;;<w-dik>@#xc*N(4S(ut+^)WEp%>Q=$9xGRw(fBIgr_`Hh&C4-=USdq
zL-GZ@t!{s5whZN%_hnhByh5=Y9C1X)ZKkztSWjtf$;4s}$?Y^KZCJl7I6V2{f6@f7
z36A`o>6Q)0n?|I3LY;V=1boV&)t*1CqVp()((jh_g0%Y(CevMifr{<5_Q9-q#m{qw
zisL4;{Ifp7?|4MI>35WGo{#qOF};$uvUBoSOr)L$^muJ2asCQOx*M+FqXvjA2cy)I
zbJp%7Vol<r)a^6K6Jq**ivM<IuxXB*HCnD+tPrX*-jDBCYe~=1U-0`dN5rAtif<M;
z5qg#i*SWlDu)egsR><5dfmV<+V(8+*#2wU{2a6qdHEz6+Fd(RFv1W%onMdTh?=DFH
zMXRaX=ael5=`YjhlL-<(l0H6OdEhpUBKhL4NIW1tZ{#*MOY;(@q42Jhb$QQQ*xI`X
zCr`smh?$LT4R_3H{eTQ=arK-l8kYT_f#smqib)!*w#6X0kuZ_M+v;*ByRmc8_~YI}
z)1?YvOQ2~9?L9uZ-defdvmfan4qKJd?q^HA<mr|qaW7sDDD7dXZtCC4mc7`;KDrzl
z1-5muzQuFne*bkjd>)@KbjtbN^S*B0*ZkOyZ+)pBg_}?*V`0Hi)v(Fik{w~x?~q{|
zq<Kc!pAO50cES%5Lmy(ATXTjBxVlcJ7WE(Ejg>st(Mgj5lTdFdjCKJJ0*=qOAEiF$
zLtZ<~eTt$KOkb7R(KhUnXoXxfNX*V1lGoWOor&`ldf|Vii9uIbjlOoC*M-?JKt+Z5
zPJn9Bp6iwE>xh$jEWmbd183A4?jMR~HvO?QuGY7DLmDLxY;u};62a5xr2&H;4&8*T
zb|UbGVaZNE-+)o$3__mCtp~xJ8`Ab~4<ss@;o)FHZqYlL5uBW@+RGY^!@B*T(J-nN
z1tOG@$n40Ei4G^>e-FqY_jC*%R5Rw{A;|yv2n_UY;xkQx2QM=^902UtyR|ewWX)E+
z@Wj2X+B(`LBTNd#1aCJAY%`b03%qDdwc)8VPUU)`ybv$gZ=Fu-Ue^P5>pB{26u-7C
zL}NY$@fGf601i&A$^O~3B|GQ(hjuP+IDm2Zh;X`*`9dXQ@xXd1mc(V(Gc~zBX-(<l
zYrl+|-m;i5QRW|bs9j~1dje#X)ddoyi#zTn9ql0CNM)v6{r3fj2W}a!@%fH_jyC{!
z=jJg-PGRJfQ8*IzJ0^ovXwT=ofsqx9d^^4#gmuw>+%q(}Zii-!Zcc_Sw)gL7DGJ2=
zNHM#s;=wrGZ5wio=e(-lQX~>e7CFz%XJ^z4?2wr(_7_?3qOyJ7v2u8s8XgGu)J$!*
z;BYK3?*%-qnfpq{T2(K0b8!c{w(>*N`@0^yJX1w<3l_k3t7dvYH=n||0>|_@ivVvv
zuYTas&GyQW4e?U+jTv>b3{|Uby8GLlb+uUS4$36|>@K4u0zpoU11jHOe|)8JW*Me$
zbb~<ix7XKE))6wdiip7e_wH1SNG|iByi4-igQq3O+5^W_K7m<~0??0Y<zwY!EluqH
zBjen9zX#ZJ+vJ`1a=$>e&Yz%&x5jZ%c&JExJzv*#FlSG9xMgjeHvV1AwH?|(K7AeC
zw7N7QV>HvrNtv!Ck2U)+m&C`Sp&`ThP24MeuQo`9^9&}L3DJ-tlG8Ph9JN|-4Migo
zN~IUz#;k68lfWj`3G}yse`YO5=ie)#mW8f;OEZ!JvpN|pz4G?uG*!ZdAKJp|n|y*{
z9Qpk5g0pNkT-8lt(v*m2`x=DWp)$fQ4R_=9>%!xPApr8J>^T(!+DmMI1OP3-(|H%m
zuNSaNsn1_?t0-g$jJ8Z3{Khm<@(lG>;Or?Jdt+C&81CbXKT<Pa`eAA?#)hBbyp2l-
z150iZ^YxB{(K?ctZsSm1dKtUGDpVEyv#Yn$IG(qD2zavyC_A6<r%&k3^kLL~V0_cW
z+xIz;-U>#SEH8hp1wnsSt4}c>by>2^mw7IfH7Qur1H>}375!y(_F*K>RLL_(s))p;
zfa~W{Nu)_UC#%CtX%*vythk!{vTU->ui3Tv0`VFcSi0uJo~c3<=fd-v(ZZCz@`*Bh
z-oZ%_4SIG)>RJX%?p!j+%3CliRr8eHtHL?jO)(^7f;vp$g%1w3XtwNy%wd*mImHjS
z-yxA~d3tHY64aADU+LpseBmn$O=r)4C7TJudEP+PRT?uHhiEc998DB^{<YWNLlo?W
zk*a85%23E#Ex1b_^@3)2P>mcSyXfXT-^j&92^w>7kaQ9Fwl5r0N3AITktv}rTuh0p
zO6OUfPSEtry4LLku>4;v4K!n)Bi*OfLF2P=B5!fE{QY$wKSg1wY%;Lnu;q6pm#aNJ
zx>B%Nj|V<Q2;u`ofT4kQ^qad7E>^&N4w;!0!!v}tVB_Nh4Jv%J4Xo7pMUw!T2<cuz
z3mf#~%Obe(N~DHE7W^_7|Nf>!16yT<`M2t(539QMCcC-b&(dF$>Tf-Euz-%<-rMi*
z3C?SvNy6+}KVD4wcynJ(BaMgmmo^9_57MHCh3O^ccio0uAExp+fI=U*RV~xJJ<EHm
zrBDNt0?35yM*OF4$`8M^(%u#hRL42@D7n>ST&%MSUXwxOXpANqLy7)7B`}i1VWX!9
zhCGFE`2QQ4D&hY(1k20uV+dm*zb@~YK&mVGZ2hs;JV28d`S*a-22~7;{PTEoOrxBK
z=PyZRRT3=Zu0j~t8M9tI5CH1?px*-f0UK<*gl2m4=p~Hl>4Vk>U;5vR8K6k}!xWgc
zc$~$^aM&ocNU$jc+hV`M{LrM$iyGMrwO;m?dp+;!FjwL!{B*RqYa`GLf??42pFS9s
zzL(KB@wj?J{ufO5bmk{R|6dh)f#*H{ONEX1KAm&JgEc6+j7~n&kN9%<VstocCvdMS
zcy8pYFcGfob!9hEF08Afm_N=($+Xll&g$(Shm&4!2fe!6I>L)XJRtJ{*!|B^6ccmK
z>f&jmmcV<U1_uUvG`xkD!yIjF0_W{6;Fny(yn#VMd63dMmcBT8N9X}*<M;2lVJ~PE
zEG(F8Y;DKK#z1;0Jg^6!!lI%qciKR@+}vEy?rf!^nOT7%N?@O9SF7h~mD8F`$+S)O
zC)&<3Z&|V2q2b}<K2oFKz2Su1WH{Uu(FRB;p!J{8Jz4H6^Sh*e*C(6YU*6DYn~i_s
zZ@gUbj!#P)NE}Tk@?=OH4BpwX@wr+H6L$TFr}dJ!_fb8ZDO*4wg=095ad4|WO2Mqb
zUM!^TQVp=l*upz)ZDK*km8drFOBo`0;0zawc(M^_LYd{G4c|XDm=33K0+KXJwQyKW
zmEx_YvZE9jX1;$61LoIk0Z=+A_qTCy_<3`_s|kU0ml*)QKwy<zTtLeW+bE)=qiN=w
z)OzD6@&ODCns=uQ*pg{HO(~N{>hwNr3yX-rLL>4NPcf#o+uC2K!xn|^ktI-XBrtZF
zR{LMF)-ub}P-vW=pU+j9JR`#Di^E_mf?$ToAW2F}Vg&kcY?w1LGScz#CWHin<+J7R
zP?Qpa-F9cBiTc3!8XvxsV3Tl2>FSc1nwjC_;W@4RW){30klona%&V#SJa8skS67!;
zUXD{*T55pg2IY%I0$ljQW``UH&2F`Qd0+PHnc`{;YsA<me$cNo@cE`d`}G#(-TfiV
zik2wDdt+Oz?c2APM8w3>MUZn(SOTM4G#fDy(Z)r(p1C<A3Fn94M3%RvtL?t5Y-~s%
zRwAt8%gw{XSk902QVEP4x>f#lETKf6rkpBxC_d-YIu6^BykFjs3EGiu{mP0Y=d+Y5
z7;hw^sRtGUS{hH4Xr{e(VSdTZUTr<eoRpm0g+L&-@2&YM?#?FP!ee9mqsaMmS;-(9
z)^)5wUH;20?w9|Bq4mne<DZ;PM}^F`M!qZ~S4jp=-=x1x#$sb*^Vo=2Jlae(`ZN5h
zBbZTHy{&={gF9pN>QCe=ZofMZ6m;}j<14%i<!gUhzpK2rh)v~$;BZ2gKc&UlJD2_<
zMxDAwuS7*D8<wGzDAG>NvC4QTQ&UsMr(2`TfvIE={sA>{(7@oJbCa?q?-!>oR8r&l
z8Vd|8tR2B0!&0*tNXA1+Y`RUKnW7X5CZ!ABmmQxXB-j6q7wlyKP%Gv?Kl2j*@bP2T
z17xTMC$cXvI2eV)pxJe-d)w#G_UzxdZo5y@q|O6?ESbE{uWA{(!hr5<fPGB3$@CWl
zxw-M&mz={CgD2;u8HRb8)zX96-hFNS;cH+({q5Vg|7K&_*x2YlFC7_qBd4h7t^XKZ
zr@-%ipwF88%V=@?-@neao-jRNSN=J3y->qScQ$h%pa3&Ilg1OPc~nTTDE#`Bo`+|A
zTbY<qSw>k|d3HpoH!fe=v|2ZJcGm#QKQ0cBk%h&3&#D&fZ?cZzwyT;ZUa*8fP&ioL
z!Bj8<Acx-*P(3|8gMiIJUS3{2GO~YXw_<KPL>wg8*qA^ZwkU7xMaRxiqzM$Zu0h&r
z)g){Q>wo-63JC_w2Q4qzT3b7Ni7F@H(b68)=k7UTVq&Uas)pyo)6*$P2ttW)nUxd9
z#>dwnRiF4N8c^Qo>ZZLLeW{m{_r5HvSyn<sWMMmw0Hv!4#DeItx@^@qO1C}uv?G3h
zHtBJ*T|7QBW9bg7;pjmiUa;#_1k2<(U5!)fD45{M<0mI4a{#PLF$7o!Fn>X;#Lh(h
z{W9%OMYFjj23ibq$C5thpOgT;o!=p*zs4C>UZ$rjC@Y6A_WuBw92b<V5(0-~6x+(>
zv;LW@HZy!TSyoYDIT;O>Us=$v)#Xr!1rTGQUK}j%rZ5}9W{E8HevTI?8hqpV{Duu!
z&s+B)IxUT?xFbrXhyWE8l}3Cs@tkjeuDYklB;G<#K~4_kKLeg`gwy}{@Lg2^t#&?Y
zX-Pk}LLSM=GRWD25d|<C1;vm|cU*qg1HGbxLh~6@y)FlE7IYC25wUu`AMS^SQ`6H;
zOH+~2(H3A6rE%lPs3=!YpVRz&`lO_!M*goJFrjlCv}b--Yv`#o1oaY=X#f!;KkY~Y
zcm$$^8Th2<`R;5%P0fT^;LyU`l*GizV)S5HS=qd48$GEfY#~2;hEGDW1?j{H1OYIw
zvz^UvZ(m{fDMX5bL`+QVaoBdLpRK5oV$s{zcW#YF4Fm_}Xc|w?=JqtIw3LerpP}!$
z_SDP_^fv#6g4Fc%^cs*l_D<!Bfe`0X<5$69+d;3jLWHtLaG^)KF%FX&dgSdslm>j$
z&JtHu1Nh(2Yn#ax3cc7qpSBT5NJ#K_#wr^j7QitK_&HVoGv*uS#Nk`bQmwJwbC2Ec
z4M#V-mF|>Y4U)FnGj!JnEr&;YwFuzI?TA|(3=AnRFA?mpSUmHUlwHD|-QD9c*%#-Y
zrl`BgJVlW3vWjM`TFcSE_htLzuAeUy#$0AoEy$^<smHcmJ#P0KobRrjOSHa8(4qsD
z80Koh!6xN8`<I~|4i?z3d1qNm4!hqqa{k?k)F2kcKFs@unGhKnIW8q-M!-e&%^RHV
z?r!}RM>8`9^-SRa2E~}%!a@`a3kx89`5pv`h#DJtZW5!Qpi~)OVZ^X(Vt4RAwq^Z3
z8Gfaxr}yQfrE>Mbq&aV1V<TB#U*FN`=`Mvf9|s4HrlzKnlG4BCbm#%o<HQ66NRm_%
zK4km*`z7V&!F{FyUB>^?9fkllwy&cu7>Doe**(c10g}mEe#;TED5}>4MMXsp<UxZs
zObrhmgXV#Q<}$Xn?5-lz&#6VG1j;KphQ)6x$`89fsEXW**HIkZfI!HTPu~S-5|t`<
zPqVVJ;>-2H5&h*`GKdaRP2~#7$;p{C3lya^%x9I!(~v5H04YfN`+Fc#D;FQjhl#M{
zJ6`CsU?6XeW}rta^!Ps!s^GP`o`Qx3-urT0q=Io_^U#;ozo25?7j`5lK$yyE6crZ!
zUa+mCCIDNs5j6Q+pGYjTD*z$hnM)v#KR-WDCJMF7ImkK*^`8K$j>GobIlW&%$z%Hf
z7^Gac8rke;)OK^imTi&>lSBKpB|v;nRn&%k9oz2_?Yi5;4%+qp*vnGOxO1*sRBRIC
zovBhBRzR|gE@q&=#c+xV!08T6upz>94<J9Orf_rtI3Dq*z}if6&%E`Ue2a&Y_J-MR
zz6LeN_ktYod+SLg=kRA8mZm!Bz>|itA=CBti$~kVIr(jEZ3x6Q?uIwIe^nLtk_$o{
z9uZ+G#Zx$t3NV++?#%bO4%nmr(x-V+l1NlQoXgfo*WL9gK#b%XKvlE3K;-nba_AF(
zepMA7t<MosdU|@U2CLXkq$BlTF-}h0h7~XN{QUgpgP^BfKf!^_h7AZ0O-Uh18{Lw&
zMf;HR_^wn70~c2w3KisPJ?eHC)izZc$1Bs*>$n22Gk`!S`uRyjL`IG;EMOHu<_`rp
zb~#1>h<9~$4GauOSz0pJ)YJ$oyyht^VF6%OUoQxh8YVzF0URCHfF7}ouRCL$z=)a8
zYPvU9-MCjX9G9Ms1yraNo+x_W0Ljjm8|V>}ko-AX>tSVQ4^l7QrNBc_@OOS8k4JE+
z1k$;NL<{^T!a@Zc_TvL5kbmMbGoyf4h4c-X3XsPn&{O(MrM<mHpX%6|nHe|sAj8VT
zi>qjrqHbVMurdL#?1{aosG{QH;%IaT$<={ne%Rl;mR>xy7iiQu%MAa&ZugmZM7M!D
WD9US+Ndn)80V&I?%T>r22mTMqt$z~$

literal 0
HcmV?d00001

diff --git a/doc/logo-old.svg b/doc/logo-old.svg
new file mode 100644
index 0000000000..5741ffeb5b
--- /dev/null
+++ b/doc/logo-old.svg
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="640px"
+   height="480px"
+   id="svg3134"
+   version="1.1"
+   inkscape:version="0.48.3.1 r9886"
+   sodipodi:docname="git-annex.svg">
+  <defs
+     id="defs3136" />
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.77472527"
+     inkscape:cx="398.6665"
+     inkscape:cy="232.05718"
+     inkscape:current-layer="layer1"
+     inkscape:document-units="px"
+     showgrid="false"
+     inkscape:window-width="1024"
+     inkscape:window-height="566"
+     inkscape:window-x="0"
+     inkscape:window-y="12"
+     inkscape:window-maximized="0" />
+  <metadata
+     id="metadata3139">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title></dc:title>
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     id="layer1"
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer">
+    <g
+       id="g4187"
+       transform="matrix(2.0184211,0,0,1.9796558,-320.30102,-235.1316)">
+      <path
+         sodipodi:nodetypes="cccccccccccccccccccccccccssscssssssssscssssssssssscccssssscccssssssssssssssssssscssssssssssscsssssssccscsssssssssscc"
+         inkscape:connector-curvature="0"
+         id="path3050"
+         d="m 306.53525,253.83733 0,-8.5 -13,0 -13,0 0,-7 0,-7 13,0 13,0 0,-9 0,-9 8,0 8,0 0,9 0,9 13.5,0 13.5,0 0,6.97097 0,6.97098 -13.25,0.27902 -13.25,0.27903 -0.29044,8.25 -0.29044,8.25 -7.95956,0 -7.95956,0 z m 47.61806,-15.65972 c -0.74279,-3.71392 -0.94449,-3.42973 3.03949,-4.28261 2.93725,-0.62881 3.20635,-0.45381 3.8569,2.5081 0.76528,3.48431 -0.41943,4.89211 -4.13945,4.91892 -1.59,0.0114 -2.2841,-0.78019 -2.75694,-3.14441 z m -84.47495,0.26933 c -0.94509,-0.59884 -1.14465,-1.8261 -0.65756,-4.04384 0.65055,-2.96191 0.91965,-3.13691 3.8569,-2.5081 3.98398,0.85288 3.78228,0.56869 3.03949,4.28261 -0.65225,3.26128 -3.20683,4.19049 -6.23883,2.26933 z m 100.10308,-3.6591 c -0.97397,-3.17349 -0.87771,-3.38331 2.01471,-4.39162 1.67065,-0.58239 3.15137,-1.05889 3.2905,-1.05889 0.4817,0 2.45604,6.32589 2.08892,6.69301 -0.20278,0.20279 -1.71928,0.75604 -3.36999,1.22946 -2.80739,0.80515 -3.06738,0.64545 -4.02414,-2.47196 z m -113.99619,0.35127 c -1.7875,-0.47243 -3.25,-1.00395 -3.25,-1.18115 0,-0.1772 0.49915,-1.75406 1.10923,-3.50413 0.91204,-2.61627 1.48981,-3.06573 3.25,-2.52826 4.14258,1.26494 4.43043,1.70725 3.24882,4.99213 -1.03407,2.8747 -1.32505,3.02302 -4.35805,2.22141 z m 129.06865,-5.76854 c -1.11873,-2.96385 -1.11262,-2.97064 6.23124,-6.93187 11.96671,-6.45476 21.33423,-14.04033 29.99155,-24.28638 l 3.95856,-4.685 2.84471,2.29809 2.84471,2.29809 -9.25283,9.67863 c -8.79487,9.19959 -19.77532,17.52628 -29.64675,22.48171 -5.4019,2.71174 -5.63638,2.68304 -6.97119,-0.85327 z m -150.51915,-3.39396 c -11.32927,-6.45626 -16.6312,-10.65046 -26.27844,-20.78805 l -8.69524,-9.13721 2.83709,-2.29202 2.83709,-2.29201 3.95856,4.685 c 8.65732,10.24605 18.02484,17.83162 29.99155,24.28638 7.34386,3.96123 7.34997,3.96802 6.23124,6.93187 -0.6159,1.63172 -1.59457,2.96676 -2.1748,2.96676 -0.58024,0 -4.49841,-1.96233 -8.70705,-4.36072 z m 197.47834,-38.29522 c -2.09037,-1.45905 -2.13303,-1.72341 -0.71926,-4.45733 1.4686,-2.83997 1.57066,-2.87126 4.47216,-1.37083 3.40528,1.76094 3.33869,1.57918 1.80874,4.93705 -1.32493,2.9079 -2.42066,3.08347 -5.56164,0.89111 z m -239.11733,-2.89111 c -1.52994,-3.35787 -1.59653,-3.17611 1.80875,-4.93705 2.90195,-1.50066 3.00339,-1.46947 4.47476,1.37584 1.43273,2.7706 1.38758,2.98858 -0.93408,4.50979 -3.28831,2.15458 -3.99241,2.02973 -5.34943,-0.94858 z m 246.64289,-10.99695 c -2.45185,-1.33105 -2.60181,-1.73585 -1.65218,-4.45996 0.57444,-1.64782 1.15826,-2.99604 1.29738,-2.99604 0.60971,0 6.5514,2.22072 6.5514,2.4486 0,1.19224 -2.34002,6.54254 -2.84783,6.51136 -0.35869,-0.022 -1.86564,-0.6988 -3.34877,-1.50396 z m -253.70558,-3.60522 c -0.6038,-1.73208 -1.09782,-3.26306 -1.09782,-3.40218 0,-0.22788 5.94169,-2.4486 6.5514,-2.4486 0.13912,0 0.72372,1.35046 1.29912,3.00103 0.96336,2.76352 0.81674,3.11967 -1.85252,4.5 -3.77382,1.95152 -3.6274,2.00083 -4.90018,-1.65025 z M 444.28525,158.648 c -2.1876,-0.57167 -2.18224,-0.77619 0.25,-9.55323 2.47969,-8.94824 2.50293,-8.57624 -0.5,-8.00219 -1.84865,0.35339 -2.5,0.0485 -2.5,-1.17006 0,-0.90638 0.57475,-1.86851 1.27722,-2.13807 0.70247,-0.26957 2.3837,-2.28045 3.73607,-4.46862 2.0259,-3.27798 3.01446,-3.9785 5.61437,-3.9785 2.51679,0 3.28029,0.49712 3.77191,2.4559 0.33902,1.35074 1.12185,3.71324 1.73962,5.25 2.47807,6.16438 1.30071,9.90716 -2.13766,6.79549 -2.06349,-1.86744 -1.83495,-2.35222 -5.06708,10.74861 -1.18002,4.78301 -1.81783,5.20179 -6.18445,4.06067 z m -265.87191,-10.79564 -2.39931,-9.67948 -2.79205,2.19623 c -1.53563,1.20792 -2.95962,2.02866 -3.16443,1.82385 -0.20481,-0.2048 0.45171,-2.3936 1.45893,-4.864 1.00721,-2.4704 2.08435,-5.27913 2.39365,-6.24163 0.38632,-1.2022 1.60129,-1.75 3.88133,-1.75 2.63951,0 4.2837,0.97945 8.03138,4.78435 2.59183,2.63139 4.71241,5.55639 4.71241,6.5 0,2.44192 -1.09405,2.12956 -3.6228,-1.03435 -1.20886,-1.5125 -2.53285,-2.41791 -2.9422,-2.01203 -0.40936,0.40589 0.27444,4.59426 1.51954,9.30748 1.24511,4.71323 2.06938,8.76396 1.83173,9.00161 -0.23766,0.23766 -1.79938,0.70556 -3.47049,1.03978 l -3.03838,0.60768 z"
+         style="fill:#40bf4c;fill-opacity:1" />
+      <path
+         sodipodi:nodetypes="ccccccccc"
+         style="fill:#d8372c;fill-opacity:1"
+         d="m 280.84173,275.15053 0,-7.5 34.5,0 34.5,0 0,7.5 0,7.5 -34.5,0 -34.5,0 z"
+         id="path4113"
+         inkscape:connector-curvature="0" />
+      <path
+         sodipodi:nodetypes="sssssscssssssscccccccsssssss"
+         style="fill:#666666;fill-opacity:1;fill-rule:nonzero"
+         d="m 305.37638,349.62884 c -7.82337,-2.34524 -9.93249,-3.49941 -14.92004,-8.16468 -6.87887,-6.43437 -9.31806,-12.59298 -9.31806,-23.52679 0,-9.89596 2.18037,-16.19728 7.53932,-21.78886 3.82241,-3.98833 9.65386,-7.16237 13.15894,-7.16237 2.48831,0 2.53984,0.14842 2.53984,7.31479 l 0,7.31479 -3.45481,1.64748 c -4.81886,2.29795 -6.86084,6.68232 -6.35692,13.64901 0.80898,11.18406 7.23177,15.57393 22.7861,15.57393 7.49151,0 10.17602,-0.39397 12.57134,-1.84493 6.58103,-3.98644 9.88655,-12.78524 7.50927,-19.98849 -1.34692,-4.08119 -7.17683,-9.66658 -10.08978,-9.66658 -1.76771,0 -1.9652,0.70826 -1.9652,7.04772 l 0,7.04771 -6.25,-0.29771 -6.25,-0.29772 0,-14 0,-14 18.5,0 18.5,0 0.30226,5.25 c 0.259,4.49869 0.0444,5.25219 -1.5,5.26531 -4.31224,0.0366 -4.5766,1.53706 -1.13167,6.42294 3.21746,4.56328 3.32941,5.04721 3.32941,14.3919 0,8.31506 -0.34655,10.34833 -2.47354,14.51253 -5.22325,10.22604 -15.21053,15.75616 -29.43932,16.30103 -5.72334,0.21916 -10.75291,-0.15138 -13.58714,-1.00101 z"
+         id="path4115"
+         inkscape:connector-curvature="0" />
+    </g>
+  </g>
+</svg>
diff --git a/doc/logo-old_small.png b/doc/logo-old_small.png
new file mode 100644
index 0000000000000000000000000000000000000000..867fecf86c48e439b1eff1d8a2bd758010bdda64
GIT binary patch
literal 4713
zcmV-v5|-_WP)<h;3K|Lk000e1NJLTq005Q%0046c1^@s6dWiee00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2igk`
z10Xdi4~-K5000?uMObu0Z*6U5Zgc=ca%Ew3Wn>_CX>@2HM@dakSAh-}000rhNkl<Z
zc-rlqd2|$2zQ@0}s(MS(*&v;SkN^@RK_Utc$|4XIaREhy!5O!QPh~s|pootV8D?+*
zkLVN8H;lM|!w5beAP$QHZUhia3<v}fWD7#}t($a`uIlQ#?+@srD@kWxI$igBP7ZX}
ze($G#Tiv=%D5Vrvbnl+Ys8L)107@yw#@&vWQfGsS$yXaM{u^(fS_z);0D#{_55m$L
z7HZbvybzspo=1h-p)MeVU|YdXEIYY^wItJ3QDFHm@2XG%z~PFVI;(NM5Se)sd<+<j
zoDrMzx8cPj3s{3P0RUb+x<CUJ0NC9QRJtqcf&~Dd=4}O~6oimEJIgH3#)4x@SgYz>
z2g-iHccqzi7zq_ZkWsQ<W0W`m*mz+JD5Ve;5k}6aF7!|jexEcMRv`@E7VpL8i`!W1
z>QqZlEXRKxSpXAntatgM<F7+f+*iR;sDdvFzl4V>*fewvZtFhuYMccE(IaC0(A97$
zF04HJ5o=+cYJ0(#;0Ol`Z`N2Qugts|+Y5GH1?z0pd7P;_hdI~HK#!1k42rrz-H;<3
zPE`JaFd-B#_nU*nkObDkI@J@sAI5+5{ypxrjRwV4umr+Gp%iZFMsnCSSB(;_h2I(H
zIXsp*4JO`n*?;mO*mm3ct4V>MIIN{AE-r@6W@A0qMf6PeESz$lRatm7Z2>;YU5DeB
zPGa_T)A3-!IBoFmRo}2a@IX;NmrHioC2bj^EoHOW>NTxQfvLQjLiPWWA|cLf!<z#a
z<B?v!#XWIj>Sl$$8rtnQ>i-R#fY0)`w`=FOHLOhSBfDgW-EH?t?iBP1>y1!DDE`oQ
zD$G~BoL{hRw~f@qS^G<~Sm*0plu~?}w+#Xj)bECMAL4iYdcjJI=nqMe)X%w9=UL0@
zT!avOSDFcqa4KkHV$+)kR-e#b;C!m9H69lZmLJw+15EnUh3bo%`0D!be$4|503J-Z
z50p~Kii~Ju6uvLd1_5)2x^#n}$S(g8H6GVha0riHp^1LC5&Zend*jETQm(@E<fjm0
z>c(1E&u$O|d&>?W${2|X$qt_Ic&O+2hPR;&q<a*USt%xsid-dl=k$AcEa|sMu_pUX
z>KX*gpEY9{qTXF28Z|duV-R^&B9`HuQ|~dTbXaDn>lz!E&{&Fjpfn2$etH!yj|f5t
zV$Cs_+;aj0Oh;vg6{kPM!$}hnZH#KN*Ww!6@!6_exD_`9jt5UTY`nOIL8T*Wwf@&n
zvHrrRnDE^rxGQ5KvdRuNss9^wg=1pVAu6K!Ilra=MXnOo>N>Gj8!rAE9O1wd9+D#A
zY*lWPw&fbzvCSNV!BIB?0AkHC_~h0P5o?ZNt*!$Vx{6WcDpunxQ4w)R?5HL^H*Pd5
zq?DpWEJcJNTpdcoq#vEH`V}u6nU6B50@sK4!~YC=y=m5twqV!-D>>*-F4=`jj}zUE
z-I~<*EdmRm__aD85rP%r1}lRsh=cc*_N~y|dPb#OiN~{^g<WzW-W-chhJMI;Ajn{<
zlq=zstI@*}+v5E+87x8wPF9}A)7dk@6CQ*R<hcrP&UqfaLz9@*3ZhK#>Fil3a+M(3
z7=<;ryo*piL|xWYam_jCb=G9Wnr%KCbC`K}E`utFtkpT^c@(;eK?p&G+m3tpPR7})
z+-CPN*W3dyzwuSbiVR9AV$9vKb;SR&G3!BOt^WAqi<*H4v1S|khV^OwzFHEzFFO7@
z?uow(gCcKewuxj4d`;Z{7|O*8c&G;(hJA!Mb8N?e#mWuA?G6Fphl(GutMD7l??0zy
z){nN*k9i?m`|JPV<fYSCIA9(d!NtlAP0tD&qI=T*$5ASl0|1UYen$WBe$1kE6?j0g
z;Mfujh)Bhh#EBZ1TGNNEvREGK!N_m#gMkPjgn&{Cj&S&9^cLnWyNE?Pe(40JAA0dh
zpdN$uLsz#+-?iEm7P^WsdH+-h9Iu|Ni8o>A$W5&0x`3OzefRxPsG=GMnR<|szOBw2
zSj`pJs*?jnoH-WrQlE$S%`ieP&rmaN?-bU10bW`dyXPSlDgaQRVAHUFwi>EdgGF$e
z@_XXPV3cjR=A@l+6{Z|`QWJ|Y1y0sCZtoO`S4IVUHLu@n#F}kw^8P5-7UWY(@z?%y
z)uF52?~7c;cqH=~bseU_aDP({JPD^<rGaWx%m~~af9K_O+90oQb&TaJS&=a&<3Y`6
zdrB#yjFH$p{9_i-2LM!$W=_M!>O4(9L>r^9Y3Q2Eulu!8|FkJsz~xu3@64D`$4^^@
zFl-s|34^N>p_=&JV<?v@wCzuUFGp>LzzJ=7Os=gj!pIr%<;czOP(|~7rR>DmjEQi{
zPS(?%0M-5beuoOTT?3Uu73>_fsm-Bk7q9@p#GCNdsLx>Hv_qLC>c;qezr)u29RVHG
zH#K<e3Q=RF?8MkT6H!^~hW1beyGCx-OlI7sSto7B-lddc>JQVATlK5vPVrC=5-mNk
z_SW|TwnOgNeLuPxqx~+wK0FnF88A1Xt<={19eCs9JL=R!-enfvj4dNRfq^r$+c|LU
zd4Yrwd^BVQ9!wYq#m6=Bgh#%s0Qc;fgsifI0cpJoT_q@y%KZM>-IoIPrXYmivCL_B
z{p8zqpz0HvgwJo=(5_ImJ6PU}nU(Sf{P(~`n#tS%z@><I;mCaa=MOUi(jj&wN9esV
zGs_O*o;{Oru_j-WKq*wggoOLBddP|nNuIclxO)KL=IER7+3<BRaz>4H5;y^8s?H&O
z_jtT^;w=_!w<0clI(sHwIPx-FS6(po&D38X_zIp&dA7sOhwI3T?{197&XJq&WS>Vh
z){B6E5Q5JOzQkP_6Y=(`cbgqZ>sd=ryp7v;-;Yzya~c;%DTRqMVe_!H7!p0WL(i#0
z!SY(K$9q4F^|!7@q#;5RdvSz=o4T>-;#Q>Z9*@5qdljNbWaRkCSl>DI9`4GRi0uVC
zL5Q|qE-4bG_I?CAMsDnsiSvZcYM=y5JT?#i7<)_h<E5O15Qsqq&l_+aD9eJGH~Y<c
z^eC4{#L^SXvAbj+6smwDoF+h5sDfx?6yCn+HT9Q7I-{+)&T1g<#oiV(413bQ!1Uy&
z;PQxS{6#6nywn#oF#S+|2(y0t6ZVuIs1vjXrFE+3+AO>od#_x7?TpW@xUq1+OV~X8
zWAwE2=+txP0-*sp!eMga1nf!Qj_Juy!L7LAl${vX{T8)x2_e{U;WHeuAH)2dzhU&Z
z<FLJ8mkMZoozNQS8jJ0Cj&FCE_LY8*=MT@rp^C$r@Beh&bDA4a^oV#i`AO_a{~V)Z
zMs%8$3J6zNpA4J<lM^Rka^eL1eCZb$Yt>o~RU82!1OgEtdPJmz^;PFdC4}Jbr`|_}
z+ku;-Z$er`e<WDq@k`}t%sKq$I{Rug(P$(tIbuJCN#8x*tbIz<jeiY!7vYBRIvwwI
z?}QL+$^Qaxp8Pvx>VZIbSa>rAU77KRQi_qbVW`Y;B80c#kI7GCV$bpIUYF|9VEHOF
zJVo<)XW`eVl&cUTSgu$(9@kp?YS!6Wumdhd#LmL6QRS(|x1+a0Ry-(`%9=e>4%dh=
zm#K_0cSZBS@<@=V3_=L<YYK79aU6##jv&eyiD`YOs+KY(tS=<Rt^PJ(R{0@K2w@~f
ztQqnTTpy7dux>nH!K$sXad#lW5|3|-_hD=P4&2=BCe3oY<UoaFM~DytffEo;tcWm#
z<01-L6$7?IS_ix2z_@)=5Xy&u=Xh8+vkDdgLBH@6a6ZScbXVf5q72*_J4*d7kfG{Q
zU;&q(&kcy^j~UlK1DDTa_5g6meneAg?itb}V6P+67y+wbRpBX<D&TNmLWCh)U1v!2
zU>v*jGwzGK3+c8IxFK>tmr6Xk6j;7iq;?r%aMX=hlC}W9RG!B1%9EN-3PdGX;!xl!
zx||3Q9*6BY7!`AMc=zJ8Kf`k68oOfVD<DV|VF<^lnBf?08_^}s_nOe&=x*wUe%2K9
z3%?dOMyAy%E3~^?W?*%4T+|L)ls3OkMi@*ADzN-T%QE$VSLEh33=tZfDPN(A=5bV0
zBvTLS8x;|ZPZ8R6pkE+JRy?SZtD0^3hJQ1*!CF>Ycz-NPo8P?nhX5hGCE#jK%wo0V
z0y!QL#^wj|jaeg}@CY|pn{PjL@){fmCKd-Wu$UNFObje0CI%K0%L==)YCNtw&m(;$
zDQ?zC4J9d*O#@S}escVLxk&0q7Cr<?Aqij;uIdmhHUSB9h3#|K5CW+nALZ-*2_gi*
zrOGm5o}CFUB$R>G)#WKGMaA0H;7sODKNm$3(QWE8x&Vu1g&pdfS-F9UiGjt$z+z%x
zF)^{Mu)&C#DhjBgbpDx8g@F|`7Z{&_xR?G4!t<REmPgS=sR3Y*bUMj$1^*KPfpxOB
zlYJ*4@%`MUce4&2GYJeTf|{BdWMyUH@ZrO7xm=h#cdojeQi^HQrs2}1ORa_}B_#!~
zyz&aOSiugI!{NZ<#fwo<Q2~zQ)Y)EqXMT}o863wUGBUE&$IZ{rhbW3LnM^_7#)4j<
zTD58w_V3>hp66Alm>5_shKf>(dGqF>yu2Lzl}wRA#lUJYP+ov$&z_Cy>go=UbM%&c
z>!R}RjhEJ~TZgKust&bMzEFES9^F8u8&`Px^l5zk_16$Oc)%ae^O!kvCQ?#Tz;T>z
zT(54P6|P#fszIn)Vnw_eq|(6SB1KW~)mL9>;yFE7te^*rQi|N%T;%8HHwYA^6jrMh
zOO`BY^1i!w?~au#SK{TDUxp+}^#V#M#nGcjv0=jo)lxBw6(psFUAuPqtsQwg`K`C!
z!W(bAf#~SyCU?9SqTaoGWA*CQFq`Ynz()uH$8p%QWeW-m3)!R~!4k9sz`=tD{eqz=
z3RbRMiO|r{7Q006Hp`bUhs9#4cb$-s5WM;3n`}~$V6j+bWn~aW(eLuR@4j2DZ?)7-
zdE+KZDdx<XquHPDv5Jd}VYk~^j1>$P%i(bNg@q7;haP%JEl0FPNh2{a5f+Q3&i)7?
z5Cj2d&YWQ}RxrrvbgF57ZCS0>Ha{Mv6lrN`^=67Z&*Q|26U-F`J6J}eu}N;p?RKl~
zt@dB-@&O?Pg9i`xTY|{T%hLr|x*w0#m|GGA0n3&xs~5nCh=_V04K-9RD=I2tU<JDx
zvsPYcA|fIhTwYrjE?m(4gYBSqg`uILe%+GO>1>rXtM3=QD5d!R`|tg_UslHo5_Rj=
z4YDlP+rgqJ;=+XsZR%DDAt)&+@e5^qd^`gy7+hUsWMsWDj~9X!D^|4Gu_&e3uwer{
z9*<wkl$x5#zzT-IJS;3st*Y0zytK3wAAImZt6Y_L8&MRoYu7HnBT{8qMp9A|11nfG
zY0@PB4Zv~8%*@35@4w%wV@Q&O=bwKb9LM>EQ&AKKRxr84TW-0f!MAKUjzd;f7G}+w
zg`-E0HpzPVF59?qBWBE)p$_Ep7hfeMCAG;*8C}9#=;ejgwQJWRBO{~HOiz*|goTBn
zM~@z`*=)Gxnrjdn8;f4OdI5ks1SdB)7bPVn$ji%vD2nQMD}NBy)YM?{;>AczOl(rd
z$-wF&R!fp3Or1Kl!N)khbt!MNcmr{7$%5lJ^{+XAq^73gx#ymPUZfj~MJdIZGiR`9
z(IOa)#tyX@4u=D4)~tcSU|_>$f-yr(PEN)XPdoup6g#X?SzTR?Wy_Z73MyTJ<pn7{
zJspoe`Y38@YB~g}g$oxVK0aP|k9c%9+l)7k`st^iuypBCn9b%keaFz-oNl)puf6sf
zY&IM8C|yru<c)o@v$J6`nOY4Or4&x56XVB^$CN2k+GGGB1FH*KEw9d=J&PSXcHqE)
z127m2Fc_Nm)4FcA8?r28`0(L);DHAa7Z<1dU&YY1#j4%;9*+k(IXTGA&PGm74yvoG
z)uN|wxxxFd$z;O7fdesk@L&uYG)Oa3jo!s(^lJn*hr<E4+l}h#Y5<pq;Ru2NtJSJP
r<~x#<LB+soGF)x7E(42+sg?SFMfwq8DWpGt00000NkvXXu0mjfl%(8l

literal 0
HcmV?d00001

diff --git a/doc/logo-with-cli.png b/doc/logo-with-cli.png
new file mode 100644
index 0000000000000000000000000000000000000000..40e47fdb5daac654eefcdfe88930a70edf28e55b
GIT binary patch
literal 39440
zcmeFZXH-;K^Dlf56_unT%8+p+DM<kdO;iMIqJV;Alq?dv1<5!DOr$1fP=ZKOqD?dd
zlA1<9vLZQ37Mk$ZY3B+5weJ1$e!2I<Wvy9*^f`Oiu3W#W-48G7YA_yPKY$<zBlg01
z0|eR4gCMl#`}V?LSPkh$;D7twFPPvEMC>^FAI+^SWiR+68(!@S-q6h+?|s$N4)ON(
z7ISiS#@SqTw-a;obV!<0U`G&M1bhDMrCZ4}13vNQb}4H+ZEKgjrT;j}e`9Xq`N4~K
zU%%wD$dRYVR|*F+ueW5kK7S^Oc_gVM+1$J&d+gbd^k;WuU4x$opK9B!)-iDRAfeFk
zDsKPrliwu%s5dd+_w<hof|G?yTU(Lo4~|XFVJ@%b8qRm$91YKWF-O6TR#sMR7>@T_
z;k;>pTm+HQV!=><L4>3~(@}pTU5aL={*s<61gC}{6+?X`>Mz0BPyMOCAUbO6zkf-5
zwD`|TM@DI>e{wwe{}!S$;{S3UsWh$J$W?G_pQY8f+e(9|2u^YoB(q~^gIhti=~=^k
zbB_$_3Z35-GNkN5f_2-?3YNcU1sW5jZ~0D$Aeh6Ww82M{s!Yj~1WPW#80CGOdy(LG
zW_Ze*Lrx>z@y_>&h0}G!9TF)4!E=K~h#nS<DdF2%Dcb(1Og6Jve`<XjK_-x_N~NoX
z4)c`hC9jr~0ep_U2-m|!8WpV%jXoh-+a}m7!Of*(u9G+OT(6uten|{L9*O9lbd#>Q
zthXs6QzM|eH%R=F0Fpv|Cq6t#n~YmsA~`X0$$5D^{(&GDZ+R3i?jZzO?}Ybi_?2Hu
z?e0B~VAz26?8i}`d0zL-D|G(I#p@3_W>v%_Ac#=$J#X=uSn@P~%fOE0=1U=+qR^<<
zd0B4}ya*gZrwqUJX2CVE=XR=1wovG1B7ag_kZ+zR4RX<T$%}K1nP3_C&7miO+`rR7
zP(d)<=td8tUOPXv?M`r($hod;^VE6xQFh2KB>kIjUJSSQP6<|NYiBi-DY^ZN3c`!-
zF(U02nrW=Fx;_>d=yvnliq4bWh)Tvs>}Z43;&h9^mQtN?=**62Wx%%w*?Vb83t**E
zYDDRm4gKPYQ`7x3@1G3qMyxBzdWqAoPt;DB3><DB)p<yZP%bJV4d%(o-mi%kc~(4m
zawgOV*@ta^hVz@rrF2(r?)v1m%TWL&;?#o2Y*7A~ZAy8-_SeLGGO!Y_Xtr0^y@QU!
zeC#m%8YCR0g8bwIXCZO9ka0UBbI29X<-NuKLxu*CeZ8GTaZt~-a43{x6gwlMd2?X!
zbP5t73QH$Ua?A$R5}9O;aK(St?ML2>%p@E77G=iSmG(D{&&tLwBq0(S>j>{*k3YP#
z^e0OQV|K4+B&V_#geA?Hk>GPDx{bsxzwovtW>*a!5xg@h(!Cpjb=eXqt~yuq$5@hC
z1!H8SuUa5TuW9n7FsZe?oKr?PgVh3WMxf0WRh9Rj%WkU?wx9aQ{|Xt-TpS)NU`A9Z
z9!q(A%H`N5<vh@OM{+NMISBH*PgTWL6CF2T2iNczm1${%*GEOiUP$>Q?OZOrY}qlQ
zh~W1D5sZny?h;c6W-OX-PTkQ6t*PpvAV`F_mUNomHTHGo@@wL_oj*}3ZZFcjDFvA_
z61MANUE-&L){N*Vrsd#p<vN0JJI%hisUNSjG+x^j2-XI<#mCmRZ;xvQIti~y8IEM<
zu>s>IF4>e+iACZyA6EpdXM}UE6&{`6pKcB6pxrb0D$%0*MBl5#sFf$aPMc9Qt9uaM
z=e6yhB^t#UUU{F~QHEoXP>MTF%_|b>B&>sRO=WMD54=`J5Ye(<<=g8{nQa$}4^rki
z>U?H<Dw4NK4^n6ygFxKbnQr)x*BW=cCpZbH04Medln99i6hE{%BRHK<<=|z-ElV3L
z4PL~WJUmkUemZNy^o)1@SZ2I46RI33>B$VG*MON@MT1k{oK-^*QXoq7S?5pJbz_OT
z0TT_c)~GJ2M5M=m?jgZc0#v1cxt%}BxcU^H37NeI%**_M9SyxcdZh)cndSYd@eP3_
zhae5TwXYJpwGz27O;ODSaZf;%vhTvfXFoQ6X1%bjmw}sU8(c{8x(Rwgb!#G_En+o#
zWG&V4ugYe!ZuPH%I52yHSI@2^--3@0*1YT!Wjq7A(|j{IS|ac;a`Dfa&fBAeL2gX_
z?bp+8phdDMJ*Y5gxHcMI1-TU(-);49FP8u(#gwuO304=aEeNVj3Q)g|9xmZ8T-ALb
zO5hH>VK`M_<lDbIo`KU&4SMd-^e9R-2LZ#?w$JjNJc+Hp+bV%=>sKtHJR%)KMtDFK
zw@m+WuR?S-XL78KqSd?Wu?oWYg9wuSET?=}kDu{=>uI&3FmP>mnP_;2fUPsexrOGT
zoymVkW%{71TbeR>-R?HAMjRhDxe$IT@bH`4pkKcj;b1ZeeJ@CI*=;-36_~F)m^}y*
z)d{+&EmNnv&H?Ts<cn7O3e^$Aj_c=vN8KNQudjRPRL317h?9m|(nSgwlo|n>?)<`_
zORn|Tb$gwdxyzhyP8>uQ!SddSD}ssklT0Ms@iozby|zT96P!r!;M5yWnVk-joJ8b?
z)k>(5uWCIKp$xhf=rkB+GuX!ssx_PJDe>l)4x-{()&!OzVHm9*cn0)I0lYbarF^<x
zS=J8PP!$dQ4OZxtF<LUbo`xDgvqg!$IU8nouz!X>lCD<4%=vw+JMqY(-!4=ei7du+
zLjq2`_%QoZYfGpNFr?6`1hOo!G9rdw6c1U5O`2rjq}s8rxE&?@J_O<JHY*TuU(z}^
z?kIrU!nxfXeSB^liC~UqRtb3=^;X$yeGfdJMBL7=z`Xnm)B_pjON~(vtmy?C00$Cl
zSr4c9W0aQE?pw}~{4LuHb;YsjpU|^0HE#tIE&sr%Jx-=NUXc7<@P+v2|M908C8dvu
zVc-}L-b`5&kMhilyRGe-a~oRVyVLy<%$HWVtTjzvlL=0m<io~vJA6R2%D74G!sfHg
ziH?&Ez`I_Vz@^`z3nKYD;0op<vD`D)pyoI}>|+1s9gyQpbdv=QB4;hpCu#Ha0czQ7
zD`eRpGPjx3ft+~RTu!GsV^%zzsO3c*dAjYj^W}Etja|sdc{vl0jFFVUp9?-720p4F
z_jeN`R!YH4F@Xk)HmW%dxA#bT&-=Q;2f@SB1x80Nd}`yw60G3(>5`CVa%Gxx{5srd
zbiXx{C-4|5p_VUa(fuQ&G>aTI1xP+ZJi$!uC3fF-H!2;(XtZ8o@5vdqRm&L+qDLGh
zDpZxeqK|(x&v8wwo1O>JkW4`|bYDRsHgws6)ngdVlc&L$BZ!^_o?*n(SDlpmx5Rz(
z?gV7u5J#@hbm_D+iAT2XWE!3uZxC0mN@l=+X}*c5;6#URZR?K>dcg8c+L1|x_CSps
zQ1iDiM5LP~VO)7~dw8r-!O-jdndgI_5Rn5>r{4kl+OzuWiq1lAlPwq=67ev#_nZ8m
zd2&wU5CK9nR1rrd*fm|--Zk(D7`E-(<^h|XgP7e&dceoVH`uY(D=jA$nBm!v8HR|X
z82aqz#y4iom-nYUW2{lsJxL2|Aia9YA4)POe6c0x9GoOWUa#K-dw&$VNF$UEX^Nsg
zS^0izd$zVG=n0a2buNpL#)(mrm*~!gY-u$W+@}=tDDA~lTQX~H`EgU-TEjDcPbP`0
zrCo&+Sr>mU`z%Ko<iu#mYyI2bO3|S&*pz6^M=g^{atEw^^jtos-Djdf8tTAVbGKY+
z`83N_=VV+D$qUH@u?+`eBG4#=bz@F>Ce%F3<Ck}bMGgthv6V=g&}7R?IE3R8lmj)}
z1(n8uYYQ%0OC1-|4y9GvI@z<s-)RuN+~oXUINVA|tNy9+RU^7V7O?Capg4Q1C4@V*
zo^;;Wg_HN_DzuoVPoV`T;vwNqu;nCt-R)!>2QFObC~yx!xrh2n{Y$RfIitP2J9S8~
z)wO(kT!M4hNVg<B#srVG%yQ(dZ^OA-n{OUL_pbA72>COw2QS{I6f`~*0v?tFRExtV
z-(Cw<C|>MT0n@71r-a?2SLgd>KC!4IJ@ZF;zoG{D_*G&-sX`%Btte`avQ4fQKFLXi
zN9hzQ9wkt6;%-<rN*zjXfn&J50JqU^zWG=GHP`Jxkd=x<@fqi*3v<iYu^RVV$ydWt
zCp48mc7~|<p^KA-`!>d_dK^CFh#f<93v)@&XIh?L6g1;-LS9`mL$w^ZppNb%7$i6s
z_!BgpokA!tv#xST%+t|LEccMvDLOhM>D*QLs^Z}tC7N`bWvB|oJ!=LF)|LI%bbT+%
zb9q(|=*TD5JR}ZQ&UD47a>Nx<u9mFricrL@k=T%tD@5sEH*qz5_^?Lzj`B>0U+Z8;
z2<ZVh^>x?Pb&{MwQ;TKNGJ^#NhA!CuM>#!0XInUsA*ubgp9Hm|V{%z%TZxcM-r50V
z7x*IggSCSAzfU;k$v7j(jFn#uGx*BjJ8)Qc71u6lH=*V;ew~bYn$%79Rp2cr7!1D~
zxh28ts4H_<aq;TAr-)f=S3MVkAnAw3^v$+JoO75@B6n3GWLbONV>)%D$|1IQs^c#N
z2{i0As<4Qja#=aMCs+mICFk9pzwm$Op3>|4=X1Z5b?d>ECG@0d48HTAcZyMsoy{0Z
z;@-rh-YJI!vzh{>=g7gm=%+u+PxA0_9Y%|4#_M@$b~Ysr%A8PCZBpqUTP-26W&ahr
zJOj%ij(5!{n<BW5RCzrs`J=!b>O%)-Z;q-)_kt0l$-s@4#0z9e)$w={Tv=xb%kLwe
zVn)y4lsSI46+zzMMW<?}9dRxDQf!L*H*+#15l09{2-9=RM}aJu_m|=;+Ol3Ch=NJ3
z(z60hJdSd8f&uBJ1!`%hxQ)$favgIhwlv7CVlUzLf!^tWUBT`sA4p?;dIMrke}Pyf
zx+S3;JOK6-Jn2~R$3TDY)B!B=9sHUsuT>2uW;qIkoFUdjOOW=`!E^nAVL*_MAIgMf
zewnhyUz$1o$f*<ln0?j~fkKmP8LBf&5hFt$CG+tV?}3>r*X`M7K@#J)%UJUV4r4eG
zB=mV~NKq6%g%2Fw1)N{xrJzW&<#UZzLX#g|eFH6-vPK|nje_*@Te|itk64foy*H=#
z(vC#8w9EicR$y9Ed8gLlH5Zf8+cMx;!Y+z3D`wUh=FHt%v_Z|T|CaaGc^p@odifi3
z!OF>7I7K}|*-0DrNlHO4J=Lh(FNy`FW3_g)7byczDa{=&uDwUI+P5^6q^A3v#jlvT
zky8<*v?f%md+Xvx%X@B$+guva*{GYIETq_OUSFkFpOiz-=l3wv$7FmWaiTYNB@uaq
zCO>D1PD$&fR<(UCJP#Bq+p=8zwC+!AFSt@RW*rLqBCl#A2xf2t*EJuDAF5TZvqx)l
zyv}+0=8nSyPk-oOl*;gL2hHR!B~Dqo`q~-}g(|o3N(VEkpsdim>Bk$&)TQ(_oUg8}
zr96SMMHuS7++D5{AQLb&+EFA1IF5j;yz__y!F6bDJPyrnDG$<kmhvAG!s2e+PD*i{
ztJf-5S+q&Ju82D`{rLj22Tk$P$<Iq&hDuw~u)X%hE@E{<E%T2JT#_hPmJ2d&XQbS=
zfh5=It8Z_Y2exl@t7rK`{m}s>_w#G7!}N}Gxw+D7dp&Im_wLv~HXKWjMA^5}5fG+#
zUHK1V>!u3d%ZLn-1Z?VnG|7U>tCyW9n+raji>!g%82aE<I2QFM@#F!n-@mbN{Qtw4
zI>GxPwl3?RmcrTRxs}cAX~kv>V?!(tV-6z-r39_%5A(ZtJ(ku~l5lVc_<@RmDTN*>
zwx8q1&>~X#6{aTNVwo<mN6#=|%jYu&EDl$N)!u9@sN44^RHR!cyZ7$&n$HJp&b#(H
z73$-7yp}SquV?dwG}9p_;FCzPkOJ~^dB!F&CQkcf+x%aQSN1qZrDiyrq3>fKM!ogp
ztHB3_6NS%obn}JAQ+_%sczQc`(5QHUDVBzQtXOHAPZUZiS@SxeY(}nbtRcI;hz;4B
z$j*cWpO`8r^p7;#m_1QFLUHxV8#%6_C`*Y&?Wv>G9f>#%=0aTk(08JL7GE;S8SVT7
z5->UY_lu0o4&0E1IX#Mc+er{h9c$u=x^!mkyO3x>-<OIx!5)6v;2DTW4KcD0t1^9x
zJeTPCQk)AN99|U?>#j<1uU|UqOoK$+^K|*9gp)sgCu@o@7b#`%BCgAIiZZ;#mcJiK
zfGB>jpU^U{9Prdx&n>#wn%yaj$kgJ?EaRf>dq2*h2Gp_xlDUtK`s@ME*qp1Jl2%g=
zzp@z&cQ(`O!wfzNK&(#!3wBeV8EX$F?j2b9JUO6yn*VT?@3OX-)*fW!tlQ0>HLe@e
z_VYioLt1W@WPUGvXu%P`y_=T>jxPFY>i*@d*(L83F(;Kp9DmL8PPYC{x2V)e?+RZl
z1W9#-XkvdOO?fqq5aznjb+fUK&q+2^>XMnlV!_dQ=JY$j1INS?H#v$^mHo{XwOqzZ
z6Sc+n=f*rbn0Znt&&EC1Pe3m2S+K~Cs}sO8xwauBO%xWPf<=e<IijU_O~OYY;weTZ
z6>0jayY2%|N+JUAz~5-ahN+L*{9^meljlUIcfpTU2E+tH1t~&sKvzE!e{MpXPCqX;
zqzO&%For{pqhF*Jt5nBjA6N~hUbWm9cC4P0&!DCGU6|W7jxD8GiiZZBC-)GTm{S~1
zl7#}WE(<zCP}3kJpJCf?9fYm36P$+Mv)$tR>R*gzG^sk!kZKbHDiwnN?)9f=1qtNl
zOAB-JozR>ufJlO1^q^FZo~eKcbP`wdp(PECQ>#z|SeyE<Onotb57n#QC6ilg@61!w
zXb>SKnUv#BMiZPJS6!|4rO;6Q=_wbdFP3iS`<K%*&m6Xx+@-s`7b!I*OX6MF)p8Q2
zO|geFmbBm2bS{!AP%vOnb_uW%(Q3b|Yt>x!+vmxLGD<k(6?xZ{=Tqe<kA4SBMg-B4
zVdhjGv|~-24(DrON*Pz_-<&6;Ms}iEyc_VJ-Jp=s(xGsOG3Cbz|3;npB7XYr^{Gy$
ziBk{^dk8JU;kwV3&&g~(^z;ie*eC{r^*fgX+k?7EK@q|!)qQb-v#xdCy=0AF@x6<$
zz#b&M<3r;MBKa!^UyUKT<lMN=-)_cD?|pclF{U#@G<0mJH4}#z*YFa1qd!ypbH`ff
zr{g|pX-vqQK<aq_rJ=~XZfIfY&y7be7hd=IrHE$#D5}D4RLJQ6rGM}bM~cS4a_*c5
z<y(Q){cXvM&~uQmlMogZ-r%dcNLESzbMW#SYk#jyu_$R9IRNN}%KHs<y4DNFtDb%A
zbB$Yml~7f$Tzz%@eu!DM41hTuW?Zs5#q<NqRRqm~zMlE#u^O${2Lh2tPvBJn0RO58
zfq8q(0<6e(OWb9`A$#w8m0JS}<eA}Cy0gAwFgZKs8<lC&GT7EKL|A^}Uk#Af1Ouwy
z`h|?uP5s-256${*3bh8fYidmk%R6r1)3bc@XoI5ESMQVL*sm4_fu~Yt$IwL>qxe9j
zrRL6g^1bVWcb}k?rZslnLyF00dV1}`vxj=IQ<8)HKHlZR^C{-~(`;-W?XkP)ejHV7
z=?{mB;jG48CS;^1yY{AXB!0ofJAc!9?be1bHt5(So5|ewYz`rA#P$S)3zgG1OiI6N
z7*r}fF6)ocWPfN-Q*6pDCp^i<oqY=d;9?+ftdgs9@u%HVMVr!~c~R7IL4H>ldE!xi
z*DeHw2=6!Fw7a7<Bi&tQ;pBU+OhMr_(fgNh!fsk5{Y{tUORqLZ1%Dj_vs;9ulZ3hJ
z?u~Aje`Ls)H0(vf(F`{s*VSjeWi+)wIbu0Ew}u?}eatwg{TIJqQ96V&!_hqB9KwBm
zMyQKK8pR2v=Lk9;xlP33gDPFGVQ+iXv~=S1z8~4S>dM;swS>ZkZTor8M~E9NI1@m#
zBOZSkwn7!hr@J@yL*uuPzd@PU>pl~!*L`lC3MI#ZSv7tVTqkQ}73L+eGpT5RCyvPV
zZB#xs`HEJtUT5f3_q10tWr1GfM+Wmy@k}hOQr!_WCy>|OD@M4Hm$ZE$(OZ8)8wp-*
z2Mj2~)hi~mvu`|nfCCU$QUYIY`LArZuut!cVy4<+OVx|5I49P}Rwu8o(<{5_D<E8`
zUS?C%jWMs5ZJrhR{!6(lPm(3rnXO7zN(-X4Sh90Jm%Z%(z<1S|VDXnzHXm_)X!VAP
zhvzp(Bv|^iwETu3PSJ13DoBg$NHijD=F1zk(kD!NbS~;BL+}<)Rg_-1ft`2nU|w62
zihFXp0!jQEHa+~+jv`>BphO(TxvoB{)+u}tbs6WE7sD*vIZHUIuy7jJaw=S@<mcQy
zws59B2#XHUNKT`;TX{0ArGMy)VrrnIu2C`<-`Bu=WrwZfsD}92HwWHMs#7bbOa1w?
z0d=@<-_Zz3L1;<f2<;Bghzw{q?@sLb8?5>7OoxfQ44h*7pv>PkYnAJL&8s^#B=els
zfaR}ir5Fw<=tZa?!uAQpm5i{q$frquQJ;I!@a|?;PD@-`F0;Y5HPlD-I*IqoAA4Ur
zGZuHhbx->1=A{K1KBV+K>WuNZBX!CN<5j|EmPR`l8?ps7XeAB_#xP&lZUuWoy-NHr
zGtmKD#+_;Yw3!&jzJZx{K$uk`I|JhRK$r)?KLPmKo4+oo_~RYE*_xAoRSM{(8POn%
z89CCw!cMR-6QqXvi^8KmUucWPrFE8CBN3`#@CV#_3WUP}<Kh_D#9%vw4sCulsKMKC
ztLLDvR#Yx(H;N|=<^|mI+3JI`yZr@+QB1MUUMf_W{!-f>g&1cOA_KL^K8#}CU4V~o
z*&HPz$gIm`_UDogp_+E{4zaA3GaAKO+zQukG(p~w8gB;)$Z_EHJr+S>tBbmOWvY5c
z$1qZl&$O(pdb<1!FTO&LkWyP;J9o}JEL>h1!<>A)(tK0BCVCJWPFk<uF{wmC{1%Fa
z90rW%uM;)Ki?Y)zEwj%?d*3|G?}qdtt?@=zVTv)f{8V2|joISk@;08Ts*1|tn4UsL
zWF4~5^i#vOA5XaA>O^|@3HH(stn<<pWgg_6=COQcq#@5!;#OqRmhRyS*%O!X4xp+E
zx<)N7!%7Ir6PVUJ$mU&;2pux5OvgN;uFKol`qwdCDIVP~dPKj{BN4O#&tmKdG6B2u
z0UQpBl3ER|@!O?x8jU8-qrIQAB)!821lQFFre4=x6LnL{oX0Ph+cOSn(4Y;ZJK{RW
zcZ|z^jz7s9&x&+=5OrHGEug7K&-r^TLSm_Q+6$Q{An;9PpGU_gMG2{_f87B}t8YyU
z>ewG!r9-5wlJos<CrMwxD7;w}=;4`3?Fk5iY^scAl`gm$r9pnQ_glJ@$NXTE!I5Rw
zAepVJa%`J95m3Fhyjt^5+bAG}?dKeIl(B#lMy866D+#+FMdATuL0pdO8gU*Lyptx`
z9g*p9w{=N)I}8L?go50*4k)sdMOJT2<&gb+_}3#LojNwbJFK34Ji%V?WkeBB-{}IT
z+Ah&bJ#wDvcn=S*roudL6F^NQ_><^B>GDe<QI`lvk3{MknWL67Jll*bpds)vqXT(k
zi{`9lXul*b>bBVczKrM@@GX`Y^s)l;a|7)XbQrVcHYZFZp6P!&iDi5#$-iTo%wSm!
zX`<x09Gc)ekg-Q-LGuaf&m!`3d{JgC$w#2Ee`XQ28dW+PMB5@cKe5WDP@PZoK#Co~
z9&1_yU9vcey0DzM7J|pX>4^|_{d4gR7KEKUtF^DL3tG5t_kib43t`%Y#8+oMwP=K*
z=JzZ>QY`nFwAbSij|q_ucTM*7I6$GBV%^LGFF>mD5{1D%e>|x&Y6**a`*>g`k08pB
zl0!3=&HM>FN+6v@5W0$q)!WBERXMmwb+cuZNToNKyA3JgKFJK*T4P~}pSI`{8Ri^U
zq;P9ryZH)YtL5>jH-4$rbbhXvjpRfY^Pr=Hs}z`F!qxnRj}?iZzSSuGsqtHkhv(q;
zj3wmFk6Wq?yw7VK<QXiTT+d*|52Oe>yKW0YeCzi3^G{?%FF9Y9KUCBEM4X{0`!&L#
zQ0M$SM}Y`E*ItAVm~s1ZQ|Eq}7VwIiYAbyZMHoLq8kKPeK~_(q(COpr1Rf5I*3vKk
ziVbnd!KeY4Dc-y0GI<BUZQG_S3-47FmV(~G1fJTdpy+@Tz{lEqmaK(;k_kXTt_Von
zMpVi+@1<$2)&m5emd2U2-RbF)&ZTES7hKLN=wa+uws=*hs#<oOel{&>$gTFr03?fV
zexNTxh?lxn=nS2V+c{e085O2JS`)ko343(NYxNbmUtcE3Y(k{P;fMZ<Zlk77i;Sp$
z-urZ`0+5M1cuyMF;=U9PkYwRF=RU--R+dd9Zfamhz)62Xq~QBJSE$Au+7e2A08z@d
z->a*kjju-CKoK8n<X$oq`Kgu+eT99{Yk$-L<uRH;9e0Y#v^h8K#8{{5yQ~P%@0%!U
zId<JgHgXgCU8WPeWro<nY!dSu4lAQQd)tqvK_<stSJw!d8B3)NZCP_eMX`B@fz`j?
z&8Qdi>PX2jEG3Cxd8Tq1Z(Q-3{`})y2u-jTv^A<tAI-(!b%ERwd$-)!x}Q8Kd$z$3
zG^AW7Vy+IZ_z`Y?x#5Wu?UOvdWlEHGKMM^6QdsN_rJYF+17cT;vf$(-Y#eJ9v&^ui
zHNk@Xyo55>0Hm^Ws+)t)2iCSNeAevZLNr?UPtKo+phVH6dw?S5O=m4o_;$8PCZ=t*
zayD(h?x6=pds7Vs?YAbD#x_(YIFH3s)?M2JKm)pQM|UF%VC8QeAORX*wU~9sPbkoA
zDuix!R)|!Mz5>JehT?f6y^+i<+s-mB3@OKV;}lz33Qr2sTFr8B`KwJRAQ6J}^Oj$^
zfQMaLl~$;$+5e$si?QtE`yFn~K7^A2P%?8fzqh>`%>x5Pk;_9FCA;ya?31msY?}=b
zpS-^+HX}ciK9|L4p_$AyLCLmI6&9%<l4lR^{}Xy>+9)j8UuD-5%B<;iJ97XQxI|d)
zf~KrrP3POXCsDVICR7m8bqJUS$(LNE^<*?L$MC5yZ>Sphtq<MTrJ+Jy>7tjKRILb`
zp;Iquh1Pz!%hc#4Qf8s#OuQ_UKNa1xf?%$ou^Rf}#+qK?BMu?0QM5x-iGNaD0H9;!
z+KmW22DR&h<X=g6-A{GA;o*2Z<qVkOmLJR*=tLhx9yy};$fKyw{Q9Olg_$zf=Pz5Q
z%;gwdA_CCCbta5mg@P8QMubJ3d5Ipz4BSY=68J>A@ZR-M;6@Du*mHEdg4I7Z`n1g!
z7%5ddeEP-AS9jr$ibSku2e*uJk*Vcc4RislUw~LjkHk?56G|)vd*W0b8V}>-^~nxd
zK09a-5J%lRjEz{oh`nLCP5`HQhWw$fYQ69L<WJk6#N{XbN1-*M4ZVlpa@_c&bG_zG
zvlBhE86_j(Ji<;Zx7KF#?&<DA4BJbx7OQ<v)YR(~MSi$!UN<=m*z{-Us99H{1Z3$1
zOb3!L>&0O=!14OnT8=ZG3@$e?Q&<kbK7-RmSy_rQ7wrd&Wrucfy2}7sa)pxZ2!Kv$
zrM{l5!p<JyP#p(Y-Lu0kLvkd%D5)->)eOR0usVtuIG25t2{0u45WMcS5_q<ceJY}H
z)F?}hJcJ$EpK@H|kI7d<mY`U^sFx8!<7JU4w{G*+8lTSHRsyYZ647rn5hWI5KIgjK
zPLf-EqhpnzXk=v~YJ8%bhGkdCIwEwp{np4QV159$JNM4`o22O|s_v_IJ&5{jg;f&B
zD$87b<mP^4Pw<_GQA<qTNmp#=9zT=Xh-;})-H{$B6R6Zoo8(^e)*5_e=-0pOHfGV(
zohG??0jxUW2+(v-UzB;r*{y8YHLwO#68yYdYjr{W=oP5;=X@}8MSNTWYA4rj1W4)b
zt>c?yYII8j4p4!oC>?WT_BtBmpOr43#K{{j^3VAuU?XicpW!Pqo#L1)(ul4aFiR9e
z+*Wws;PRoi=S+Lq4S+P09d@T*1o^Ohc2p>p);+nzS7$)D*V=K->Z`ZuW+`;pJse(d
z_2z`)_(gjt^`#JaZNT+(_tzcksTr&6uAZJw+Hl=;Qf;IeA)^^+dE3y6nd>9~Oer&C
zf?8gl*sLG?2_pnPzjxkdGV&Va9T!_G8Oj5q)pI6c!ocQsLRD2<fAN#~T;x#**vxmZ
zJmVPWJCOzf@A9Ks%U?0*K3p56^LclSP)F7&iZ*v8NEOQFZZ@>kIc*EA3DWK%nHA(~
z9<OT{n?8>%Y1VPAo!3_;X=Po?q2~S|p@p}Tb5@{eTe57N<U!hd@*e}nYBM8uWRM0)
zl<U#U3|4G{wDOq~?2Q2SINh$w8_nqBu=t?kptlrLpXls${G%$=E%oM#9RZ5m<BwGZ
z8{QPl<~B2OJ>6>Y)hnxBZJ(?r>ny<(3f|H=+p+D5ViRA07p7=u6yq94^vQ{4w#ti}
zYN`-1ty6@c>WC(6_b!WuZ`MJIb{ba@BPEPa6{sq0--E^!1N`S@<Dc_qigyNw--=(i
zWn}sES0n2^ruI4enS@`0*beA<1f{<kcs6?drT?FyA>hnjUM{{DYS&m()Y`8YxO#t-
zgPRGQP-5;KF^#>XhlJGcS7qkAONW9hXesTRvn6hhw~mCz=4Rj|@-u+vsb4rYeOF6d
zS`rxs9n{r$s!TZM!#1F}$L~T3jaz<lY3;~CW%`sXwtjNB!|B_9h2mc>aWlnczSYyD
z8BsH+T@T_5J@fKI<ic=KZGJmvNxi_f8d;CsLNL64Mt!oq#7!AD5C+aD{Rrq9{%)qj
zNV(LaB>xsKKK9A%T%wRg`@~-qr3`a&1G_7rT`YH-EXd`1<D6cSqPx;c0xL50q$+ip
z0y1Nhy=dr`cTJ#kP#ATWg@y_kRO%SWRt{1M+AK-h=sL5RYpu6F*U^0Q(jAl6v%7?%
zKh<V;2wi{eACbxCSE($JD^!<Rm3am#%|0mmrSN|uj{I;)F1x0ujLH&e1IH)FNG8SB
zt~<#snv+sF<_cHuIYOZ;6#e|Is_oX3EXW?a93Ry@6P&f;un?4znT=ddgi>@E4#&G2
zUC3d6f~X<vy5T+{66)SD;i#~=BGM({HnZp`Gh6M_E~?!67k#k5yB0@H%nRpgKO?uJ
zCgcXOrfVs|fhX5{fUcX6KBx$x2Q(-%Pr2ZGUtDTUMoXF-(}q8v>#%5Fy)(A0nl*8R
zQEaIuVC?~|&;tX->%TZzacv`Ak9&u2TH#7WP4YW^S6ift;{+9tcapFOFPax}xkzyn
z--*uRI__kYXt%G0`#ZMkn21P8SCwin&V4ev+AMHUDl&)7-@+{Dhx5#lEGG`jEo+$;
z?j+f~@>>%WNWxScQMxS2lAdO{mddK+8d&J99onU7yLJpG>g*p{+HSZ&GtzvBxo!Pz
zE$#sOLVl_!t)Ok>ctgloe$<zvbswsPV@d^1Ff$jT6+fiAD%_BD1ZTF?O!Gu=2M{y$
z?zc+pm#-A?3J}QqNPfQHaVwNtn~paKV4!l>!C$wAg<6LFng<mKK~j&)5@&KA-AFg(
zu8r?&N4^<@c3G!gCsyW}a&I5U)wJr!tB(6z_v$Rra@|rpDlCc)IF0#wy?>Z|I!WcM
z-OsX=mIfVcqGGJ&WHzT2_M6#S>inro4<2eF5vW$&BDCN7#lEzxZMT>$Z#D<sbojVQ
zL7e)^eT^HM1UpYR+2HEaZNmzz^Kw55FPCswX_yAJZfG>$)H&*G2f0r?IOv4rdFXn;
zR0%@S7ahX4&Ai%h8mpAX$66hBvYi+GtEXWsmVP#HLyviVo}r5-Lee$$<62TriPx-o
z@>>icQ;Hn2mXaI6%8c~_zAukKqrqkQ2?HX8PDtK5Fx_Ud(*R0lie-I0`JLp$*JvJR
zU)F_I!7hbrY$7XL`Al`YBV=MP_ayWbu%fA!YxassL3g^2{tH8Zq{Z(;iR6RQM+f02
zsI>t9D3i}U+AnJHf@t1H`<b50vC$v1Nd2BPEXD#>Lu?jyE4#UUXU4=DcTVPtn%4qO
z7qrWPCb%4JAVpm?+x)nrd7YlZN1?~s9FvHrWSOKUyUrzSN_-RebYs_^GeMMm7Xo{2
zabv%(d1Ws7=lAk(t<N$pMlTl{YCHRn8Z{lCU+T<T!c*vw5q4-mX%mVpQ;eEac_v;^
zu!PHI)mvT_^@VM>TC|yxqT}&2ES<HI3=(o3cGdDp?+ghLzBk;Brgg|-SZ5S*V|%th
z3J@LSKzd<16wz)k2sqwHSaeS#)|rsQjAkascpzi1DmE3@ZS^b6WVI_Xg*F_EnSj-g
zv7SNS(+&<>>@te+qltPSb-XoKi&0ZA$Z_Fv`<RMclmcTo#VEE0X#tefdaD9F{$tsS
zPErdGZx|OitZJ!rpI0oI<UkgM^74{yV3R*s^yKpwfZDq@DkXIKQXJ~smnymm_a1{7
z++@7Pe@}%wz8M=#3XE80C~`McGcdHT(#YMuiF&8cUYFY@V(B~6R(~GbiEKATJR3yw
z9<m0;OU+;I$uH}EqPVIrbH=%P^nsLz0a<dfEqNB&yO2c&Gw><Ce_!R$YRT&qx;n_3
zoFG*k)aqGNlcr#r{L$2Pg9bNy`(4w|t`{?{0TG$hPAhr5*xZop&1YpQ%FJxkG%YDN
zzY9S{oIr)mz)yX2%8YyMB$RY{D-6ZqfCA&_Rymt_!H7^vZ&xC6pjEV`*uP=wMV{5k
z&X~rpIx>nPlU(Fyf|r|)Cly~gjQkV^{zbg%9sVAq=X>9{a`H({Nc5R^O3^wmta9Tt
z69N_;Tdzi`v~#Uqn54lbJXyb4VHoG8u=8A`%eQ}Q@O#mPO6LvXudkCVBGp$|p)(K%
zh3~`WcQi;KK*~rW-y~aYUY8{F0gF64%AG_OXeZmn?YTwX>v0bl6vDuZtE07Jj;(U*
zHBm`5Kl>-*E!PSJ6Iwf&U5h!M;)fwhO|+ODEf`AmIf=Xxha^+wFtHyRSscwg7QE|e
z*u-UyTQUJs(|X@xfhwUa41d)Tz|PW-+n!nYixQdSr?}yR-8plQwSUIGh*Olgptrv&
zb>0Rc?SgZYc6EB*G%izE%;>RM8Be4n@ymZ(J|HujT;{y_A|E%CD)*{iq-lQ3WRRYT
zx2U;99#7VB=u144P)j#p_NBL8;1z{y%m|QKN{Nyl9pY|{u6Yi;L7g9X`D>q22kPt!
zANMbR+fHT8@>)Stf>z(4C2hULHJ@<x4r0n~mA=Ng&ve)&Kh}Yi??<lqwe;7F0|EYz
zLSzy&96(48p`TRC^4InvoSa}fyWN|L&A2&2Lxz;WD0;?xQ!?F@zhCw42q_utfD*bt
zdbFl%r)1629Z?&%PZ&(RC~hb3X-JS38T$E>Xhr!oGyt7}$eCq;%qIcX4a;AHvH~^A
z-KA@q557ASdf)AFeQ}|(Nk_)GNp(nR;&ION{-qehmYC5KOZ|e3_$N1*<6K&a%mklF
z18i0EO_$7x53txvQ|=7|$<<wmwvO=x!2ONJMY{ZqTI_S^Jp9;<foW=csREV&&1{mK
zy}#b)#Z5E$XJ`!VPAl1tWMJ(?F=iOU;z?Pl1h~rsC>qgT8kBMfOppxG*~RtLbo*T!
z|CUtMks7}nUdC=-(_05V!ZR?EkKluAj19l$6<eI?pq)TQQtdX+q-_zQ$-D^-fMBMV
z&PJu@7w1H}MLLhWRv{S8u6xhYQf7T&ViGk=rU-TYv9wd_lYatjCK6&iGsK$C81c_u
zFq&wI>Komuw#~({*$Oe@3M*UDe%|_G?h2xJOLQI&lCBC-Q|0Z-4K~@cWSoR$>=Jh{
zli>>oc~=}yYXGbbRTRSYMyLD2#{7&?^Y-D3$a>eA)5n|09`AI#p_*kY+>bQ8Dnw_3
zS}sHLRTNtkm5I*$x<75&_$z$)%ceGtOQz;>0-gq+Xcjy0%Nhoc9uS#QJ~avQ)z!C@
zpU(}SOVIE2q$Esx*>eAZM3|u}cvgC4VA%pY6tnDso#L=qNcPRet4B}aE0*yxeh-QE
zoc{ddU?Y+NdgR=wTZ4Lh0pM8GatGwrP6ym{w7%sKRYHS!LbD9Pd`0~r?<5^zTa7@S
zpCD<3DYm!hMLsp;Q&uBm31OQn#_HxUAer7UOB1L3%0E70Ik>SlGBHS}*pKYkrf7E5
z<(K~RCrGeAhy&RqcXgD9X>DxODjO?r&%>1X&a%{ty00x(H|E6I=XL82i|_@zo9|3T
z)*j8;PVvPK`OZY}1i1~ZLHm;la3sY2B3kU^X3DQ_(U3CKe`K_Uz(|mz9vnQ_Jf7&+
zMwzy-fRW_(IRVWLj>bV4n6#O>W3jSq0~k=%`@r^<4s;Uf7HUtttW?X$3;`_5+rwa;
zIFex_^`W1qy3Ebi41iaJS6&}gXGBlp5IWz~a1>rb8rVQ_5bD@DqEeWt|9N>gf*iOH
zv>_u5=#UgOC?ULVkO?6|e?p3YL`VXQ5S4b&7bLhE(AIyw-kJ$?BP;;ApzDHuBI%Ck
zYbu5D9M7boyZq1VH^Eo_`yKZ_7*tk+(Jp9NqT2>PMOQ@R(7*hz_Hh5k_pj#{sn7pS
zeV%yDlASpPsI~>51f`u0Fob_-H*T&!@xP`%`Qd*ZOL&Y*J|mU<1ejVwkUhWY`sfd6
z#lQb$w_4cq18uHT=N3Uw31_4qLtExw=M$FcuM0*`@(*R-3%`H|0jL2%dQi1N)(<_*
z<A%r4>mmSQQFn!_3c$3(=wA+?nt_b$r)~+!12E>j`R@(Uc@D7k@Bf>}K2T5dd)ec<
zC<AGJzd#jIFjW?*sMs#5pqujQ{nzt?KQe#<>cq(ZeuqWq3nIbja3@IU+J6y#2!_Ov
z^#8Gg#qagvDP>M0R;||xgv#ps{q>GI>lo!)`o4^zz(QT8ys0vS)mZ+lfEyq1^MCA;
z8kOFkujj?gZ`t;ijmrUcs`m3okKT?i(KH1e`9NW9B;xpBnFC2X4W{XY{&wgJ@`%oy
zg(neS571*?js6i-F%Vuq;7u?mI=b@@yGGPUoZxmAd{&I6#tn?D)bp|&0x9z<Kk0)(
z8srfw_y`V8+5I3PZFGhH2L?Zy>3EM%wmy)6)CR^?Aricdwu*(PscP~+p5FZVfV$2<
zpP*Ly&pMmmV3Y~&-k^dTQUCB<=imRhFM0hiNDc+xk@c&eVwhFb$z&UUMevz$$>D!e
zv-#}}_TMk6e@FloLhhjo+Q6KR3XcV~8D5!WT0zj?15|Etq-OVf!M~^q7u;{%3&yT;
z8dXZqXOH{Df}1n5{;<-6gTm-LGP2hJK0sK|K*%ejP=Ff)e*IQq&pW7rQOEF*2p&}N
z{@FS7IbiYs-eB_^mE*t9dB1NrYC`{7fL8GK%onXg|Jm(+&Y|D?p|-~>Q>pE5K>u$_
zzrhp$%rsCLcE5Z2zxL?=y~pp503H6%fs%k>|FDu6*(C^bFbxgWg@4#_!|Eu1iEmw4
zf$)!1mNAB-fBKiq|4UZ=6NTM!OXx~eb0WTtK~MY7OVs0Cn?fh*g6q|C6){(9PvFD0
z;vG`fC2?WelByw&a@``>64iRgOO<!@;VQ-EDepirSPfnn`woYCv(q-1QV*kr>pVe0
ztt|$QhYVDlNHiXM^mluIJgdgVYOWz!*jY{-@0Yr=d(Gt>ry5tv$rx!l84LCP_p-y=
z?rQeu59zyq;5w+W?{yh39*dh_-`u|NGlZd3rcrLq&u!6Hi8}ysS(KZPmR=iN+e)2B
z4=u!ka_ay5FPAjX82D|+w8nSkyM=|tT3hjqkfc1hnd#<Q79sXEB{S2aDOQxjvMz9I
zuDWQTyW1Eu5}`VnvSuz7p0FjR(-DfAySqFpiCtzDt`=)^164dO_IhDYC-mn6uQ@o3
zN6v{!M)46TR?6F}X?;Z8I33@prPA{9@_E8wG`dcel>llTBnean_VHo~N9<QQy@P5q
z1=aNN!OIo=@3+tEf0&H|9S}v`HHmM!t6(}cIoZE3p&)u$+grTF0ZnufM^@AnSVY2p
zgk12=N+^iLf4yNOGoux2w{%h*&Y1{Tt-t{-udKwxid${}g>^esqQT<9h!Rf{Lw9e`
zx3aS8UL0+*B6oBw8F>d?jO-ppb^o7_-+ue{t=P0cn$*#O%dRSN{B$NKJNp(Vyzg>b
zP!vI$-~asSULPtm__}u>grBRu+1VS9zam)#51cYaiEGy9tk*kJ!mNo=`mi$YXA1LB
zDkbQlPHDwxj(W^((@6UHH*lhlrdv=Co4&ohJ(^|UbOG+B{_VEvX#W;<sZs!%!K~(=
z+}vTV)eE1t4RV*cu}!MuM6UlZV&?suH*X%A#D-q*)t(UXwzpqFvm<H)0C{6^fsonJ
z-0Ha&6#0b>(`J#|d7Zi`mBa3Wqn_)p^jTay)_$CG=!t7>Z56=-sln=0Qf)e4T-L(K
z%eR4$R|uxtd=G2<){0ScFWrOkl8=#rfwN~|U`x(B=se(bQ&UsdsASQ@7Qt$6W73b?
zG%?Vd?Xmt%Eob{4<jNNUpHCo*8f$LLBRcHV+?@S?y^?2;n;(t8oynh3()=-1(eDcC
z%zJmi6W02Ve*9wa-tjJ55PhH(D{}R}-pYZuB!Jh&B$F{4P|SQZP`kkWHss~=ODAJk
ziIn)>>RS<+w9E<-s9X81UPnV^!>qo|rA1#lkiySw5=+e)sPM}bmSNez7YPC9T&nBe
zr|9VFcA;bKh$HG)t>5NdIw=_6bMJbGq3B#IfnQ7EKO8$+iVAUVn+>Z4{h_`>i>m)R
zz}u<mY2g^ntZ?YrO^B#{CE^7AKp}o3K387)`uYwE!k{^h<pG*Cs+gg%LF58xOBTVB
z6{8U;_WIi{qyN0%zCoeP&(GPw3(W&5j1YWO%&wfO52b+{9q-@2*VoXfH}bY}=g=P9
zUtwMv!bR}HCRQg|4cXXN%}=rR2NY$dcrW>!!Bz~m6hV7PAt?e(3hvz?FVnTPwUduc
zK7?*G&8RBJsS@G-fKxghR(D$gy10PGge#|pWlKM^3_!@IelI{^dZzci)^@&`HPYVx
ztrLX83xp9aAfkGb7P(T28XWyQFc=oKc6%%xTnFLH_jlyc;;X@3yEYsGDtI;HJ%Svh
ziuvs8@Ao+@f6P7p?)A9u)ndk$g2<z%T0dmP&=CZc5>!aNmO()~o|2Stl3Zf*Il4E=
zoYwZ8d|0JKzQ$`NS>PW)OzB&|X>UzaZj44$3_Md^eU9wiG`d)WPC}%!p(MG8VhMCw
zk5tF^1;aKe2i4lW_wL;r#tevm@KfqOiB&sEnJ}KT>)UDntFkAXig(1~n!?e(Wbj`L
zANC-ma;lyv3gg36uB^Xw=lnyh-8hO*P7b|I_~;zyuA`Z~m+k}ujhg+Z>?rzrMZN%{
zL9T)X^>Y*jazwqsC2aVCl;fEtZAwX<%=ArX=eA=!iT*dB#fFTa0wKlrZ?$Ad-d*iT
z+m5bZxHtY%=us_!ukmWe9W;?nEd`e7a@I4);jd3{W{6r;q7O|9Vbf-&r)})$L1n*T
z>5+7<8XfY}q4{*nqNQQ{ci-!JdTmwcWfNX;)LP38axZaP+l%i@d3J=;9WI7uNTy$O
z1DoT4=~jf7S;2`0+MnK5c_00nM_jSS*o}t?TX@RqY?UhAbpc7goJ@}Xnx=ty7kdpX
z#&xXzoWHJ(eYwkQZ<+Cp-qOil(p3bB55M<Ig%P=uzOk`U3Hok%2&AKPVdL+rAdjA6
zyCHLkK2J|_&NU3wrDjih&uuPY37qkEJvJ>fJ@%{q*!tZMjHB;Nt@w5}r;fppJ6zbn
zp<n6X$k7xh9#mK*e%}x=Cs#Dz=y-HQSV>t*>JmNI^O!8BN-c7Q)Ry1shGv$hW{qWd
zOTHexO-ys{sHaa%W&z4Ys?!cG|32q@&cX3-`hl(4&g&~V8FxybC3MmZ#V*fkW=V|9
z%||RBC|lo~Wxsm+?c2BFZvC$pvY}yt#M6T}R5AOLle0QJGv{8be)@bRh2ur%6wKY2
z2&rpm1c^G?an?VxFUOMiXGpfFwte~XC4|357S)5XzdIlccF8cxt1+dw*}s)CD^Vh|
zwz{emIh^q)P*GJ=QxhI7C31p3#i6iyMh#0)K<7r_J#b~gUJC>g&4HhxzBPk&K1*Xm
z_nC@GEi*|TUYzxDNj-vmTr8Ll&KfiF4^)cQ<)}My^Z}itNmSDH$Z*H*ko)>5%q+|;
zmkW&QgeLbVDye01DT;;t=s;D&x*RnW(Y67rgBaB?*E1!oSxy^ms;a6ke)KBxS{=)R
z`YeiP$!_Ny66hu69d6x<A9n{;dPmEOq>mCQI8}#+#!y1)DGX*KE#r=e*YV@WyAyhp
zFKif2h~R#bINYiuL&0&mpz)eS2J4%1vJa<EIZoFdtC<zmA+?2_;Ek8Yv43(Rc!jh|
z(7EkHGr%6yGnPtu2Zi<SEKIQybO%eFI?6Kcd~*Zp0=$(K@nJolYZ~DB?_K;%gB*S6
z6(m82T=~|&Ws)J;+_6H~KBm*bp-T7GBF`w#j6XmMA13!F1G+NW0!K_^6B07(m{V-H
zw{O_*L}X9y+-LebV0vao!H~=Y6XlHFK^{c&T4NMkpoV8s@yVFas(f5WG4-4}Sl{i5
ziHWvzbZ@s)ya#=Pyw+skcC(g6mO(Bj3;-aZRO0hRnsoQ4T;*=n?pT)3P)+x+v9aMf
zUE+4H^)$!a_7wG=6&h{Q?GjAP20g#ejpsO3p2jmZhw1qh@G+;@9i5Xob;|u3+($)b
z-~uF)&YzG#^plTeu9GOaO*(c;Mp7dqP!1T;P@FH02B=l&3L_-K=g~!4KCVNUdJ#K)
zmIB=lyfJWC-a9C0f}v!27)7zZ@}SC`hdF@{1}-v(K6zsP2ZnAe$F#swWYRAK*Zgh^
z7CBB;4=bvAoOtv!<X-D3t?r~A`EwyEO3gO{U^V@dF{vDA=|`bDLaa$_%0bNg8}U76
zuLrJu|5_VBap1Rrxc01AME(qwLaG)Jn)6dWhX@<xUs-raIu?<(u&_{>2@+CI=&|X_
zH^ISlJA(AXeOE-KNp5SogE<CoJHZ+1xhBKJ$Y_^=<F!gjNwGoIr9C|i@)<$&V&|Iy
z6bdL!&dtsB>Ye|t0cORKp~@RH4kAk950HT6J*Ht$K87m)_B*O{j?oDLy!gE=Q#Kj2
zQlFbsS<sVsQ+fC(jEO7#Y@OMwYajQ3=w!h@S+y#U;luWF)wvE-&cXNt@*2hDgJW&%
zH9}fR`y?q}Nu-OScqSGHM@J#tnjT7AA>>j@Qs~|6xdW&GM{P~K@DmK7rzCY>U)lXs
z=z3BBPyf~-w6JzZ8*+$fj*gMi<}F*>kr$+67ptXof`lfs(OGqS>RxDh<#<BaxX}FM
zWGZ}RKzLQqG5lVskgBRoFS+)SOjNf2kVS@+%{xO<>fHd$#L=|a*jq8DWE`5?ww5eG
zCk<bt?R*uj(<QN1E4)sN>35hmEGG^+rb6y{1`7d|Hnz~R##as1y?*o>dwN#9iQWVQ
z<FD@<E7RT~Ot;5+UVHq|Ar!)O&O=!SlQh&bIG|J-;jT;|lpk}-0Dzp`JcSQdKd+D9
zLDl{Drg<jZm^V-bEKifz4xR@j)Fk#5s<)mf0}8UaT&vRkuiPybaelm*p%eCE4<aH#
zJ^VHMko&DKl}%!|<lxL!-rj5Bst%3^IRFhaWulV!nsPQnaz-!r(zTLCwTbGbR!T``
z9YBl-Rg<Xdkq9U*`%7UwvKwbHfiO}Hm6K`=lMGzeLD$Pn74dt2e|AM$R`#_BRd~;j
z;~_VkYiO?QSHwRFI2oe}xu1}Mn_H2dwzfG3ramR1CzZtZg?seQ^|Ia?z5%$4f*=(r
z{#eT5?Y7=0RxDyh8hsBMqC?(-`}z8Ppnm6B)Yjl83KA@jmL)2APVn4QAyd*Q?P@NU
zbn=bIp=LD5V|w&xou&TkyboEu9!DpXsjWxYv7wlODAkw@`fHA2-fzFA)SPor`O_qJ
zfE}ZH{Hf4WURv0jDrBcfojq$I&lp&9g&ql@ETb|D&HhbW21zul^#gvY@apW#V=ula
z$-$N=B$%F6`u;PW<TL*()xB5s{>TmR+=U$7PhHPr&Fe~6p!Ni^?^&o3i+eH#9;U9Q
zBOlGIk#@7ogzhdVh-AqeiH-gH994K!|8T;-ToQkO@A)dPSzl|=HYG`U1^j*W_}>cl
zo1nCFbdDr2PL-vycKc^0Xi3|TB1!34uPJFj{M{;LC|`Da6oDMC+Luw)3Z24M(Q=Ag
zJWKv@j!xyEFsyO6$`Cyu)$BS;n_O7Kxw*N=YBxUSh^}r>#m-KB>*3Sq7Dh@UHIR`)
zTDYr45?pR(CQQmXk}mz%=J6&~`Th|JDR5&pv3@{rUrL6)KFcf<ReC6rQW`DN<Qj1a
zy$R9=0jwp;&ZIAzc`nclZnXaE0GUo0e)QJrUd7S;l2!~aexFoGf+7YuKy^tdI-7oE
zOBx@%m&?7+r9$xpejiH_{P0aigA1T0L1(B2wwy$wvHwoYpiRF;$K(I=8Q%&h`E!HZ
z52>g_qOw}8`yLZXNOBr2<KgR2gp63!^ypKrN*9a#0EkRQi)sv<-gRR5`zBXv9okYI
z?lIlI27zcx*=vnjAI_nW9qCcwelBb2r$WAV6AVJSSq47ARm##3av=UunMl>JrpcL^
zO?aT>`&=70C#M2@w*<@ars5cg#IXrF_W<{Q!$mz}>!(l-Hv%3v!C6AOoY$!f3|}vC
z5{EckzB<!W0;UI6M%|atzhw-s8}MTZw5lO0kP7>}$fTfAcCe?XM|YG9u|7m4fKReY
z0?vTBM9zb_GzZ@U@P@NLG5Z9HLH?HhWf+|amb=yQ;&NUr=%qg&cJWW|Ak7I*+|PQd
z!~E?EB}%+Rc*3B(WoH1Y+}GgCD^6+D?MG7vd8#329uYR$yhMgtVeDH$o>2h?zQ3Zm
z4a)LoEi*)jnfDT?XQa9!env*dPCko2AX^ZbpF`E)V0=|=ZLLA99S6S&Bu3xoy6>ZW
zNuj>eqn1J2e6Om`%i8+e2a?<=8AV0KSDA3B{<QJjcGG`cr?7L=;#mWYSUa;QKJZt&
zOHggq!@`wN8zs#w@{#{I;n+^d`Bbrekjp#^(ekwcYfDZrffxBfS0tGGG}P4#>AB#B
z?C-PXCj{`+vS8{JHgTNw;UJdKhd+L;5K_6|Pp_uXq=FiqTAG!3Fz*%c2|W%3K9fV3
zeXCGk)nD+1JW1}CF4bJn;XD<sq{PIH7nzN~s_*--JUraobNje<d%M8#E?`+NOu=k=
zZGVl$8kPnTai{u+a=WHjvzD1A;A2OWpn!mMqKO&z!0QNptml<jJF6&s8p*`-rE?>J
zKaLvgEvO1yEz+dKjZtM9mJMs$&$Vl3DDjLl6Jgm7TMv_sbl!Eg@9#6tR%`A<UItV7
zJP0{?9N)kn7!9VuWWN1^)}_Ia<lAv^aiv8qKPQ<iUb9c5M{T+a?T$G5^p(5xJ)87f
zWc_>1=wwVq2-B;0er)kmqdW_d$wnCKY$y?-ss=h=qGI;osiWZpgWPHFoj5*h`OE!w
zOCLQp4`PR+@CNXO8&x-M+?d&*CJx{xA%i|8A>ny16L6k}_Nj*tAJXroql>%8RD1<R
zGZK5e`M8c?v}lfg{>+QK+4Z{uvX=(m-kNHa*C`hM<JWh{wr#P5WS05`H585rx!Y<O
zoC_R5hfx2?$T*^+qIlx)h9Domhy)Av`UN)5j|oL*oV%6<umsJ@W;E;3yIm_KExk%X
zY5U4b{ptk7@d|+tN+D481B++8gLKMFw=Pfc&WZq_2SfBHV)54BWbfhD#=(lAu?N{#
z?aTHfNP5AS>6K7O2SN!)hb{N($&};~_}BoBavLhPYbwZ~EsKJxS6ouQqqz$U4lq@K
zIM;AIeADxHj*A907XW(v8wT2-Mz!wN@|`DVX;l<j)dhM_oGO6bqxe$9{=fFV^R1~g
z`ZgA1Migd71PjFy1nClbS40g+XFxi(&{U*GIyP`Xia|=Kf)PZ7fT0MXDJlq|1tn4f
zItUnnL}^h&;O@iR-^cq0-22>o&^+Yi<eazcvew%BuqFu&8{2(qDRgx{xRL*fj_0-s
z3rpFQy|3s$aK=`Jl|s-2cpymY@^JOR;4FuJ27~b)a6o;Fap&*v`ocEW|4omgt2fCY
z`PqMga|VR?JSKk$X{u9BSRJ4lHk^B%kQf&i_pI;wu`H*_Z(Fe{X~E>yfE$2B-Aztz
z-j5_{hzJ*w{4z(fVIzgIum>x6yXUXgC4%98mQh4RL`-F0;vKl_ak&KdV%CU!^7gzE
z(@{+gjS$*kxy#xv5Oe?UgrOXb9XrHwD-7DaEQ|HHw|F}_IhlM3642Vd>r-Xm2!g-8
z5H!+HD4Nb1@?l34(8>GxF4H8RU$w~0c_T3NgUfk{`<)%FUl1p(DhFqXRk_d~5tKu@
z{#F(iQ8BQfBaX!n7kv8k>C3MfvXNmzQHvHuwt;6Sqa>17cAIHSW~2-?hAk}j9sQqE
zmcuFrB<9Q)2_@eYQkM+BgGs(q^kpl4%_+Osu5crfxWwg3yUC|ZO|hZkWf#^eHTcxy
z({pc_<JRR4Mt>lo5M_Og{BXDciM32pnu(Xsjx<8_ewHu3#hI>w3k_*<Uvq<q&LV8I
z_AIV8eCg{>1i>z6%$&>_>L(<JaseMGB(RT+`zfAl8LK+q{(WL%A_4(=JT(#1blD$l
z%MZn_XmlwiI77fQr8tGV(nQM9aC4Y#XfyK1$C6|)YtgAx6)nnScC*_JmqT0sW%ojI
zSReufSnN7|srVa~&}c<Rw9^Uaa2^tpl2MjODnc_|??oB*0m6Ab88=B?LF?3(`(}@7
zklN?}U<H9sD+|5jJ~)+h(MuT92gd$m5FT^Z6Q~O0`h?zq$DAbe{GPX|BaIqEt*g`8
zj{NRV#EB`&L4LteqnN`F2L=XZTqH~F+0%IpxjDlRSN}p)enevfjj)cVbmfA@JPk+r
zk080RL%@1f4+IBQ)b`1CKga^*J8Gdi>0f~NtdU?!jHGU1hZT?O*+A>xX`ZPp362eD
z?e&kII+xel(*K5UP^z2k<(s_uzm@>y0bp?*DH8Alrl8I&ycsA!3Tpck;*h!K<>BDV
z>v$Cc@K-)~<P)AmT*5xN-Lp~sW6i^d4?Vzb!08b~E7sWG-|uf0?)F8ZwK;1@kgm?$
zg)9Tp^}F5blYJ$%8UT)uS0Zt*6L$J<MZQ?HeqBkDdZF9Q8sy-^<Wc?%lgU((M#jPm
z5Iscb8EbkzGBT1(8bC+M28$UJXtQ)k0L8C-s649{ECz_&h4sb=&<`<mZa6=@Df%91
z$1$%LMavIi?(!QhkJRR@ql1VzGuG5+>FfJ=d}wI23q7Ea;`#juMS9S;ro?}&k$Bz{
z0^yBF6e0Gg+@)^yNJ3GGIcO2Z6m>IC+AOLk2%=igy#%}8TI8Ud$=Pe#A7icym!P<H
z{ONmNl@IIo4p67Q)9W+j3(0@W+h?=?5TbYL3W+uL&N8Xo|4#A>PJ%+GcTGl^+JNhl
zz1?#|fHe-t(%xKIceuy|1kOISXYXEK6yUvw3C&_~g8SLTa=>PmMBz4G-$jlXJqmP(
zBLIFs39E;L#j2Z(yqpHLz^<1gTlu%7^<!TA`0-;5UYW!pK(+b?D-_esQjof1&pn9o
zeZDt9qTno!lL<6}&~Q9432^ZW#0lmj5SaH)7&O$ZNxf_IIZ@LILNe3@DfyRBMeNJo
zry$Zu<1&PXLoJ^LPuKELPWLF?w2<=P5&wa`yul4vma$Y2EJMZl-Me>J3hU~)EcR+M
zTt(nl_#fsyx6x;y*dtDO6P#$BsKFK5mNvd*o<u7N<q5oSlPNW_7~rg9#AWBf*r6y0
z=u{<_Amxk8Jy&_nqMpZVpi-r=-+_oZkHBE965B*XPVU&Tqr^Nsg|x|J`sje`{fk2%
zKYaMmyS@zakVU5|0`PP*t`-nSQC*>}AvcLl8Wsa7x>orB`)MFz4^OE#Z{9=)eZF@x
zU!Jvu01r1u=hP{9_E;0|C@lSHJAF8f7BbWO5V~c|Ml|mrYbQZ5Sc=wlpLChfV>z(+
z27yPt@yHl{23o7#{MQ2{`WK@)yU}H7vmOYBD2d>mLITLm38-QcCw@RL$iM0R*C#yJ
z)UXAI)6F;^00&bsi3ihAh=f27i~&BCV}%gh6@0=zYX4|iJ>UZznY0uv7Yn4HfZ}@7
zT=f?S*%jU-Mdc9*Y)M^_;3U!lj8z?MoKGqUGGEz;Y}~%%SVD02kU5jzO#nybb#F+4
z6@**vpBt%*35$$ul+p!nnYey^8<3&Z8ok;Ey*GStkP&%Z=QUGfp4rPs1p<B{vVPKC
z$VvY=^T<}GhuKANNQl}$ANYv0_LMPGFbZDg{rW*4)_?f`0vHSHd`|Vs8ZwtLaHL-^
z#MIowV#n_-{tRzgt?$m!TGI>$y!_kR`tdg$DqQP>At3ApX9PfDEve1K%lC)|n8}7y
zbS;@ES&IR;vj_htm@`h?i|}g=tm2amyfh{sOR&tSR=oNY*NJumtU{9_oi+4`9j$W_
zhJFsw2gGV(^z}yr_)83FFI<W`<)j&`=bP`Fd8Y4Vm<L!mtQNLmkXDf%Y>{!%NQ+Wn
zs}945v}iz`+2=rZkGck%b(4CN<M9%rQV`b`a{a8IsrkehsoaZB7jRwZ5Hnq4I)S=-
zBuL9BhAN3!%OwPl&{{Zw+_%J-mWxx2D@Q0fUaPze#jaJt#UUj-JG;8vnAM+pUQ4&Z
zT-L7ZcOX07y7M*!A;?Qi6R{-lvPP<Q{{Nf*M+f0?GGwg}ehZK=>ZGl@(<fw@C+UIM
z_*27dwjOO(i_omVDgxl}FI9P10+k<$R77}JuZmH~>{7u{7+Bq^{@x(2IhyYWL49NZ
z3yz9?4brmK8>zrI;cB~?Ryi}k!lnR{IuEx0N)Ki)awcS(dPn#TK4r~)`SQab+x}UV
z-H8C4#El!_^9~U};=KKC-n`kRtE=1mBodh4@N15a4Dq=5_@N!hg6sg{S8T0A+50g?
z){orweElOw?tRwZ0iT?yh5{7h5i`PPRqUDqD|X|XwNfgTH?~*vQkJ5pCi3%-E1~>G
zFQPW#uoRkA`S$HwyRF$EHbg1PgGC)48W@QLQ-i9M1B>qM!j87r>qUN2454i<chQ7Z
z0)da_$_K6=bOt%dtLDbE)lPlbu&6Vl+U-)tBY|9_tf2tY9u?ovGA!Y95J8xB-of9W
zgNcueOHhu31N%<E2Cr7aKzHf1t&Ok9Lb*)ed^AfcY+H6#R;B(F9OC&25!k>_Hq(0$
ztxN1{r1`^0He|#NBuRm!mMcK0W$si*#`FwQgIZm#<Wf88i{r?jt0gvtfR%NBbqP69
z6&U!w!G?wgO|xI_`Izq6M4#+v`CcM?)_M*+>4Wmi5cb&8gJk$>DPipBA>g9j|7GX5
zgEK;*U{u6n)h*WE0TAqseIIr=0Q=q`Vp)F@2~>%8V6CA4CtyKBuj01vT|ICZ68;^y
zT1)x@I(^TNcUY`=)=)jTwoLIof5DMwNN}Z!au9c(!-^L~|6;{kT38qiGNmE#X`(33
z9HBhIg_cn{SGnWaLysVA%j^+F#4)I?07rQq)#WrUtSYk1F-FMWHX}e4@_Jy6c*FnW
z8~py{380eKk7zyi!bcqcg4Sa}xNw_TJ`UVMJG^EJF)+q3F%@S3v$4F&O#v~=ihS|}
z#-ZG~295X&cn$wK*|sWq9w!a(PJ=R*Kmh_*`+q+BebQutEd!d2wL{oIHu%Xup=}ZJ
ztv+EnX&gt2F!<iLrp(Li4)2yQB-RjHC_IeJqCU!2-d_Q$WM!SlHAX%_RUfdVX0=#i
z$#;vsOacSfwG_^0LgWXS#qFuxfQ%KnlM57CFWAvBST2ULX|(C&fWWvrw(dEv8@GHC
zYXkx4bKay+_Sj!)dML#cd_KR+{1H6>7n)0YC{y0?Y&IVkYK3KHN8fybGaQux8u6`S
zS8dLa1>ws5;G0B#q_6MS5|`Rb#NWP$C~n5#-~=K{5aJOQt??~ns`Oc0e0St2v=5oc
zlxJBHDgwBEO#VDzFK)Hb{9nu$FYAcJw9)*JNFs;Aax;RhELx=Qpf3`x+^c{778Gv(
zX#uM3FfF|{qHcea87jMxz_jwC5(yI2cOa#yrb_$a+Ref%Nt1*OtnTrFaXsO_Mb4zh
zXjBOif~FiMzmB~sgyEHvJibZ%k$A5@;>$KASuBBkD*TPB(Ku7(pQ0~ONIubVM9ldV
z0WFISe?;;!3-6O?e@<O9rk@1!VptEMqGVF^IiSR0tg%6j?D1WalI2rJykh><c9%4@
z84=BAud*B>&RLh*yOUV5I`u)^AeqUKC%w)Xq0r+285iBl9omn%Ntb&8f8GAhx5f@4
z*4Ip{{>8)!{kc>SW{YDR9z&GcSy))8IPLej!d2O*79!b8%|Xu;c|l-2Pd}9Q$3gVJ
z=1y1Wo>jNtlxc`ZbkFkGhK3p%ODrU92uKdv`ZweUe*;sN+5WVmqQVL`?I)F_=oMN4
z-!W?_5p57GmAU$e>fw!(wgR?wA#1<^xB4`HABzaY>i|=_oOMG@q(y^5uIFXqIb-~#
zg<hi=FUz1H$5Q+JL#*boo?xzYiO(;-zE_U}3|H^{zWM;J5y>a~Y(7T(ug-X?>iGO8
z;R<z%$d&PCKIF|4FY@mklm_jFB!tE)nTuPnB5%W1NYt1H$OJ<mc#GplT_vE&ghh^y
zD`P<Ya_5{QmM}|Sq;9zUf+nR6QTI%r4qFaOC^)5S7@VwWZ8cDRIYC+U{MD=93~QX{
z9^nS3*(u)hljO`r79dhOkcPA!@}QoDJ;7(M{*pMs*R~jl=WuR<Z+N)(%JWaax8o+)
znl72q1#Co{ybuB`*Q?hYz(_5MdEg%Wnz{vfXj~Aoq?3?%*VXeD?yp@Q%%t*kPD+J+
zo*pi|kduhUN_}Pf0T@dN&$;>*ELhIaNm*Ihwetw-k$ts0P6m))Z00HXN$q7W?9As7
zQu_A>;MxFrOL_d>*C_2>+QJucYr|24<w&`~HYWcd;IJ)sCw|=hyUby7sp3F3AW-5!
z`K;IusQg$^mO__~&>V11%UyunbQbJHW#wGIe*L5@cD~fPJhYs|6_Ar6vC?;v6N|pg
zqp`{m&r8S0$BQooRiLq!;4z-RqZt;TGka%=Rq1**+a4ehbFM1itQJXKwUf0@+5{7+
zEyl0)88IXxfBMy{SLp!vxwfwCLq<(I*~*;oc`sqLohI*V`F)=Sx%gTGHKw|(Yz8zC
zYNO-h9vx=w^;u4Z-&S+m#}pEZV!Fd{ZNN{(-;eqJ?MOm=l*>DjTNc4a7@jq_X@3G*
zCxY1!!u?J1w<ISD&ca`!UEFL>X7K49%JueiDz%|O8Dvo+-Y=KHpvz@;wZ92id8F9Y
ztimdIr^|CTfN11AXnnjuyr37Hg~K4}%MzhkmStn{{K5sCN;!;hj+4xDZvZm_o7`LI
zw86(Zz2BwfS^uK3ngH~A?x=9g0{O;QxKk_ItPsI+yTr6Ler?*eG}uj|ooq!QVXjJH
zZ2>15B1C6TpT@YjmD;Zw_7aosO#C2bN9T47951zZ&Rn1g#LpMjC#R~b>*$185YS%h
z9xG1x7Bv(7_AS7@j#*C1T%R7g36n1ffs|Hj&4ve;a}nqaF7Aq`>DqZ*@76poX$UnE
zVa*C{+O+9pyzsy_fc>3ql{1a5AUX2;&t2S8zqs1TC!Hr>yW9ixa1VC;{vzI@IT-C@
zOvi(GE5&!dW*UlxHJY%5NIJ7+|6xYNTF})#+IXJAzuJZ}!CBk)YMzD_B#*6;XwRmW
zfEu#PPdW)&SOiYmVn*y+zg*Mg)hRjL7db0&$j2MZdjlHVBMB-Lt1resTrixBNV@^5
zaeQDU(d|sBy@LP^ctHigNkiGAKTWVR?{pO;m)|n2V0oQPH<LMD#Z*V`f&Tvek`5-q
zr$Yi`KHbs~INAAVe~{>5ECIueqGWq~8}0uGP+UQ{ZP_g}RZz6aup#EFCuQF1c_uA#
zgpvq1TZ=&F`)|@_&o1QWwi{jx44m)Q>1}iol)CnDDBEyS&T0ezTH79sIJz^wG6U=E
z2-vJ8I84~561snoh~hk#oy$j8LZ{g8VKEDV<jNUKK&uQa{=TCf3R?vY*sDX@$>V;w
z+BFe>6-4g_GcSuafW{=dtqecLZfbtVuG=!2PSi4ARSHht9q;9|yaem#*q41gkWO8P
zAs=PhVdnxBs_S`Wel^1v3q4e3KU7V)5u$S!KGdmC%z*ak6MJ<yw|&);PSojjt(22?
zHpwhbxxB)n1=3*3tIvStjtS%*sTmwk62|a?fdab#C|KWCkcB0ZQVzEq<Q!AQMA+54
zO3lp7bOj0i{CMclp|K;Bp|c7)rgSecIwu6I7~#H|@1u<~u$sf`U3-?!ylI4mmPPVE
z1?|ukgMy!u%t3Im!$e@0wDkB4n>@JqJ0^^kq3(QP_Xy~8)hJKq-DIZO?pJCa4!Jlf
zG_~Fk?N)4GiI!*|FSVBk?!)^C(Z{6j@c8*#^MMbjYY~72DLj3HiuDBItc;lVa4`IZ
zh8M23xTM5u<e1Y28|6&t{Vb68k0yCRz|^P`d`JJObB*sm#Hi!tPOXwsrv0}I{r`MU
z0eco<)^G-RRWD-6q>X5lM)E{S+*SZ~$-!Lwr2g`KG}d8Se}N2AuPx~d#dWyadgt<J
zjb5UV<fKWW8b$UwZ#oVA)8>(_Q+;aoFNbO{Zc-TDUD75HqsGT0KQ03t`)@$>9j8-G
zrsY}{CbX}-7oXh@2BgUQczM&>n;BSbiO1rz$lyLH?}qCn44%4^0dWeT*7z}&FE|Y*
z<e2rm-+)`LPd%BJJrsfF%k>i3t7MFfO$Bb5(M47KIS0(oOkjTfM;pV@ngz7mpSrK^
z?)cBZui3%AQI3<$F?r0Gk+u#>rstCD7P;JUBe*W_TC+#<+E{7fyobhZbIrel#7o6C
zD0v`P96zp2S!q`4&dpeU)29O@y2seom}21NXwPPi)T7kD91DCv>V=S8vtxmwZczdp
zYC7qyM7uJ`vTy42q@gVUkUv8|s*@ayaiJjeS5R&}WG|z))h$}?7qhU0d~ck`wmh#l
zpd|hi>)0L;`R3TD`r-RT-qi5q@qgIK$-<g78!8{erK;e$R#@i_fyR2CH|Qqk`;Ja^
z(t5V$6&~f@uQm+6Q~%_>FP|U`H}NOC*$0e#p;pKWFu5{U<BB94$P6Q@@B1e*`;`rW
zl1itFOzSUS1fbr;y$uFls9TZo7maoT;HehkG!3$uv(m7ydjQW48s#6yN~Z(sjirwh
zhvLzEO^B^WeqzlOvYZb5I$P7<)W%+w$F9T(R(gZm4np$*5w^H`{N%}#Wx1}1U76gB
zkGTYN@V5j9qx4Vg=MfURZHkNRA&M+#Kwyt1C1%*~m|F{0Y7h+8s<pV$e8<6Y4m)#F
zXMm<T`TfL9L&yyK6MOG`NAS9yOlwj<sQ*Evw{eYglbXdqIvBC*1kF>!lDcW6HuQEN
zgvKGrzXH-O{1@Xn2w=od`PRuwo6Dqwb}kmTYu7Gq8{3#K65ao@$z}x7Tt+;VmuTXZ
zB@@KO#|a-1lr1&5vV*UH(NlPpa}nWyUop$%SGO1EbkEvi3o`6AC_&7qcg(s|zY<6u
zkAG;X3YyHVse(u`M~8pTD*1fMJ$3c*{Xoi1pVAFn4Oo>A;=bRjb)`|MotS8*;Q!mZ
zKm=wlCt*M*H<ovC$Qe6>UfP^obDG{Dmmm)Y4T;bq28u0Ow&j*8Wf5z>Z}BK^d@G9j
zjGGcTcP~eoA;TYLk`s!)c(GScVn$f(I-(Pr<%u_XMH9{pCQu8|tkjJQS)@8_IQBY2
z?j^-UFze>@{jSOL?SODf>2@eqPjD7q*oevy#s+AKp&=mvWZt>)CdPwa0t~a`i4!NH
zC)v$p5qAo%`zQ?W1x!RCDaN*$Cvs|FT<ZixCRP%A_B@%?k7z+KQ>pgvdNjq}ox8j;
zx+YUnl9Kqnu7>pxNoyt)U6)wspc&>CvtEbwxL%Tzp7KO+LqZR7>K2%)_qgRPlOs>M
zO*2W3gELE+j`Ha$VB&jxYku8qB|1BUDUQszD69F&R+;5Ui2lOXA`TUF&st@>hXsG2
zrR>CX{Vm@1>>SD)k_ZupqbjwuSr>xgWt@1Aensyg1~z+4;mf4_l*Ju!vKw`|9OEBe
zeKX?m_jWSOCXXFmLo$N%Q4~iGvOF==l41`<LtFaIzgP4IA+I6~`?UX(RsRuS$Bw>D
zbi0Ua$y_V}35W(|lRCd~BA*@INHjQR`-vxz<<vrK!pEr47oLIX6D-a8y9feP7i2r(
zc~+pC^=T<kryTj@h>ijq$e{9e<CYIu`0pWRP5=+yNjMRhJ5-tD-~96?1fwdci$8Kt
zgr2ammz0u<UI9IkW{%Zqh>H@6?0;6wuhmdnG}^-w|C(&mr$rvrsUws9FZ`UJR0-hL
zdH;H$M(SW%VJHLtYB!@3invM1$<h0-7H0q=-g!eMAdh50Fw6rfq~`qZuramqG4-V5
z^g;pLrr3;Wh^rMj;t$3lj<A4)cFlmX!6$q56g>s}OByk6f=#w*whDZx*yUclk`kxT
z8O2?giO^_5M~x&)>aF?#XVYTd$Af?fmgYs=@*b?h{BL27wAu8is3`y4;PhPHX$01`
z>>xM$;SRD_Z~NAScdf>47Zz47d+*z;L1BnCdbJ;c&=Si0HCb>Kd7a#l9uf%ymMx@N
zz%0AC?o_x}z3ZwsFcaCzBlBwa(Qi)z@0314i@TeW!kEx@zld{`Yq6a?0!fdbM$}(t
z+i0_j_?R=6yU~Zi)4cEKI5iOCA->1Yc0;|~I=DS{ZGs}xRP$QX?bkhG9u>&ol<ry`
z*T=xyG7KQHOiOUmjmV+4@PWe~)n+{MN5HSIOTSX71*PXQ_eNwFTMY4FQWxx3ESIbX
zRtq+3z53tjlRj<|KG=_K5=e@vDR#7;JWC;Yj{A)o03%tiTyuP(dvp(1Z?X<i`Zj@5
z@>;}L%55NLK%l@_+#1`sqHi%U5tz%30kr^^%9}}Sj3Y)3(t7sn-d%r1xgciH$xE`*
zk5Qr3+xWt+<NT?NizUfPNl|5Yh6tb+nCPA*6ixO1NGCCXKCY=31}*>3Y{Q<~$5F3(
z%m=E!bxR9^OupyYtnVaug*7ObkgubrM&PZrh0F|waDcjk2a{AwwC96_`;EkOw;3dh
z>G!7th%u16KfibH-rhYwKZ0+TvLiEMiXt7;S6s4-Z%30|73HM2LTL6DmN+2x&eQ1I
zWwcqy2;YK(JQn|ZscmWQSN6D^=b{S09t-os_=jLBWD<&m>_=H*77EhYfCveJKst=(
z`+C0c6qYbrwBoKEqO{C8lGOrn<v|u*;$(%zKy~G02P_t+fvzXig={A>L%I@_(`5_U
zcrSrW5j$MyuP<M`HB!z(fNKS)3WXrtdwxukI3x($ay*qgI-*e+`NJOElunApw{<ih
zik}1smT&hn^4!vjS*s3LXf6cwn*3q%T0sPp&jN_3lDES9PxIca%;E&?2@9!lj`E~j
z38<$4-R=#k(Sb?s5?DMv$e&-HFa%!-J-5T%85xU-2s!y2$Vq*zcdpf9w8UhGAl{KY
zTqyiwF}^aXEWu$*-&>pknM=pSZ#kip?67FN24*isQBS6KyAhb~=1F#m*>FDNG|GEN
zy+J?-SIJaNgaBcLDPb&kng&V&*(n|JKfbu-l(3!9MHL+VKSTp8U3wuqjCvz~hq`$U
zKpm4|bImO<#YW0*4T}&#E$L4&-|``k5mJ%{dd4h!EKx?B9gVvO-C2`TQaDLPUtSZU
z3kEuPTrO8o=jSm3&LN{bqZ&hoFW(@h>+oQ)b*1}%x6WMjO^9EyHWa-S9K6`>lU)H(
z((-v-mrw464{5U|gbK)IXJN&}8CD&<RWhZ|u>$bJ@6shjvS4z{6NfU#2A+^cRIegR
zaVsu^5!F`*@T11X`b&@z+$rYr-rlAPMr=4@MOHf3QVQI20aTl1&l}LK2vYQ9|BmN8
z1|9-`P0q-jL9#~+)t$WdkR&~=<46E3Nh+O7({pZ){F!!tVD2CG>ReS-Rq>@UZ8f!d
zL5v=T90q{I0kTujy<(OIRJkpD5FtBJrmk51&f;)9uHa^Znx}XmV~>VJN24?T5Q2wU
zWEXp#wy=;?@;Ouf-E#R8Ar7p<I=tB0YW!t~UiLYN!I*@3LzAdESB}@^SEpyjlBe%&
zYR!GlYg@=Vk8`QJJQ5ltMOpR&1yfol*L_-F>$G168RRy6|23nNAhOTIcJi`j3B<hA
z1zHi)RzBT9<5}3W>!qP*lMa{&VxV&PXj7lvn`ep<4wer`Y3>Y~i#Wt>_elx>r#NrO
zS?V#Xab~IqJ+XFYGyD4k>UwX(!W>gz<?Fa}p0L?$N>Hw#jiEXdQK@7VvxXpTK3UK6
zli@1|AHsH_%fSc_LoQmNlkfck&~07IpI4ki0<w$6KWlT8mzI~Ct>{HV(B82q(|mva
z#UXJ3w&XB8v*d~7w*d~A3pS!VS8tTVqI1Qzbc9`UNf&{VixXNObIOqU^9g@{C4VbF
zN|WN6F`6^Pz**M#WD{Goq&s|E0jW6JWsb*VTn@4Z!3enn0@up`ludeu?HAZ+snqq%
zu~)RS<IhQxeMoRs?p&TvJ>Q<p%NZ&|^A&>+S#W~aI)PK9Kx}{8>=9wQ-$)7cimolY
zbA}=oa`AYO{P^MqmD?*ewB`be$Ce^wOsRHK6#c#m-61CV#^ek<pM>a7{$G1|?x+s}
zRu!qJEnNGNukY2svkB`__@InmyP8(96m21mA!a@d%3abz=t_HAciC5$x_o+`D#8Y%
z5SAm3`yL$Se-EP(Q^0D@K%_J>rpx}y0j`2$*G%>s#~{d=#Pr!MlO~>s;ss1nFK2Ep
z>M=<?%PC(kqWAC5?2>xkMF66sIQCa@8Pj^$9pEpr7OEU58ag^U6@$+&3Zk|KeJP9|
z0}We7FSmWHDIyaj4)v^Y43qB|*8O#MmKL--pb)27b0q=l=e}*6Ts(03giX7-*r%83
z77HuG9Ea@U7{cO^#7VKxL=M!$CEFR2FE2v@hsva?*C4W|Tx^wl6`1@gxD~RxMf-ht
zS_Bri{4}tBg+VR{v;IUvOD<z^0%-nkIFF;cP_9)??7pFVKlrSW<bV&5&DZ$Ho<}I}
z{j;0apv_6jU%rT-b_Dd#XQT&vf8Sty57$g)!-Hg`R_`+&*p}XJ-<pd124+p4!x<}C
znqhDNS@0vc=MHq#4skn~Ekm>!;?OjcFQb#>(trSJ7CD+bzjO7-{Kn=?25W!NS=@La
zH*Bq5lhWvLot8-Def;PdQ|`d~hjeox%Sk?cOpbLMvoN03PTLIz{yhx-rFr*191N=;
zjHIyMEk*@Mr>pPOrXNci*>P7cVO0T)!nY(8Jn>Ooxo&=c*R#;W($VgHLY+}>=YBhm
zp`LW7Bn-kf!(zzO?D3wUF_?wKUro`cEQ6GLeR^`UoZRaY3{*>W7HR_~-i+7toWi<6
zUk94DF;K+m8`B2@b9rnCi!Qn^e2cL$tgZx(k5J6&{I%xC8Jn1uFXN@eFbsnN$rp@M
z(Y6AwdF2_yzCLBO#}q#JzPMJnB~Zt!fcTH`!NI{=;q&F9^(S#tvj&*og++f_G`%yc
zdO$z-qSm+EzCYoBgT+gO4S)R=s64|xDQtEmllXbatC#k((SzK$@9k%vVvhoi=EMuj
zfA1|pHV|LkoRc~7DPKzd@zAAOe%5JG)7+z*Vtt^Z&(rHOGs^w()4NgiOreH|$8S-A
z+@FQd)RtSJPO$R4LE1g^TQTg56aR>By?xr<4<i(Kwt>j}^T4#{9Ox?at{3HN=AGy$
z_Gx&*^#4ti0k*G`Jyv#=`l?0hm-6lv{cI6TD`cUFT}@tgrDOK7UPLNnf4>pcuOODl
zz15lh6js|PldZ7<_47`V93vpi?y4hITv2pu&Zalr_ov#Ja}sMm&@bF)<Px5Rm*2d^
za%{~r7d#K@6&q|}Ek8co;)a~)){6qVwq7_Htk>-h!s0biQ?EnVmsb|<_D5zNh2R%T
zoEPwbwY|#fk)CuL*ruUnZ(V5Z%_Dw>suszu5eq=H#lND})<krltJ*cM)}MOtIpsdX
zO%C&^MmR9Hjakwbg(>vSa_EkSD8YgqZTaB2*Qu>)+dG(o!$(R5)unMH<V>LO+Rv)T
zg%(p|WH{NlENhoD_|MvFng58RVp*g){||=0`cn*_2vfxsQVv=9F^QEk%i_mw9k;pP
z<+mbAdG>Q37EUq8E_h2#2292=L&+u7W-KIlD~uv&J!^bxbRn37fP_eN+h01@j>0{#
zj^W_9bn5IHC{z$ZweA>J`}O^;bGwMtWp0CxA8$qx%U(StHDhU$nkQl-Iyt|`$mua7
zqQRZytSF|CE!EzEheZqo)Ka4mOZ4t=t_*DEVp0$UmV=kUNxi~R!WxMD3ev<v#dhMy
zG&DTm3aU@GVS8cB6LY$!B(MuK#l_u=`^3k)Rg-cDyC+s}j)IBsSnF0SDLYh*?wCw~
zN`lTA&b*bW&AV-j;c&mVplIWoRlTdbA5OZLB8*?_0=sH09(nFBZ$p||`Op^+U%s`6
z$M_Mz|CiXS;TYZ~i?%sO6zbL>gMklz*#AQbA9I_O>D#-j`H_ui_dPT|bLez^*Pkd{
zCQuLnX$NCVChcElA`aTg(hskgEkgMKMdm{BlA#}<CO{Gh(L`pH^OdHJsC~!{bwT)G
zLdOmdK-Jt~*4MA$G4-xvhQyT1l78A*OaW7D;_?DdvMNX?p=b<8`I$pVzO+D3spoZq
zCU_KIAG`;CfCfJ>t?1tP125Cm1iW~X?_6-!2A4_DCp`mIx?-+TOf;6B4GPm-ya5W=
zXc%f*)Bf$-w<yS>8O*hcZu7OU>|%Uvn8lr`wx>|F<-W_*2C1OYlL?u20}9s3x$X*c
z1<_z(Vpdl|eAnzSC}R|`y*mOVJY-pOm!0R$K|$y?UR?7{6qckah60dndN4rc<h0{C
zVkp%aP>Jed+rH8gB{z6F92QIT1Hjc!Ml$cat=^ubH(v)O!#Xx}$M2R)o+u(VL0G@`
z50&y-6xH`9I7S`+o?M-q1cymCA=JLR3gpK57iN!a1Gp`{*GkvZRHF%vN@<%h0nd2|
zL&bmv3PLj{+0p~~In)iPtR(;+^9{Uuaz~C&Y(U}i03g_nWn4)2$7z-L=-&U^@KAi7
z2*wz+aW>sJiX)xcJ^QV321FEjNP#N-lBPeQ8qINrCN^?niPN9}tTW5rtE-n#<UYM+
zbrd%GoA8K;6hHMn)2HOI*#$7fsA?A=B<=^Nkq*vR2%u8)fbWS@^VUCQ`>_9v3@gg%
z!ufga&?DPnP&&1f+xI5D$s_cLC4ov@5NXd~i(T8d2O8p)L6{^Z%OYc3|80cvq^U}$
z884j8_O__dmPwv)LGw#Uc&z+q*Fi^MX><Kh(7s7KSv)u-gt^bhX{-i1u23R>&L4Z&
z|J<2gv@P==bW(*&U2=Sb&c7c_d-B!m|7{|;6YvIv&+Iw~h|dCLc?tQJ?w|m{eJn1-
zm41^T^?O#>EmGUYsST}9-!qv_mUO@2%6AKO{^P6ru^gW^=MO^JB08*@85dCbIphrK
z;@4g`&fI&aPT337>X8CczKF5ca86(&e<jH!4B|v%sHB+t!HFa?5Mjn&1OP)cWk<Vz
zaYbcaMu1#&RHYmE=6Ybebg=}Nk(xu%aZ@HaK-YimI9K(dgoUXuI>c%K^YEghqXR#$
zjEk$1VB}{`45LzaV<<qkm%fySr@}IgAiYVt9<+gW02kUs<<O|fe`I%08H6z^jUcac
zV@IbC^P(=JeN14gAi=HDtPtvt^v;nz<S3f>nx$5ME}m2ch;pK!pkPcc{>Wtqq5BKf
z#yWyGyBH{%86?|Z*|MAO2IJQ{K+HKd4zF!lLY`uPID7{I;Z)<ym(4&Ru41q)gf@D+
zUvGbNP~aKr!~V#QGqBWDG;+F)G8Tm`QW!jdZ$m;t+*Gx-wacl6yN7qmm3&|@>b$RB
zy&CbL5$j{H({;2*W5a`_vAwEgS8y>|=-=_XHngfky|%kDOC?b8>}7y9>;dHXe8!}m
zDC{5S^$6CBI)z)$D-C1N1IeT(q%QDA+MIKNVo$)<GYP}Pk!PC1L+a)WZf!)pKo;6G
zd;iJ8^2zxNs4RErnPFH0mgGEP>hqZs7jS!FU%8L51^>yrJ7r=F!`BZE!ZLs>a!U6F
za{(k1(I43}AQ*ZE!AYvW>dV82P^jIPvB!_vH+U)H$IpsQHN>5G81R%-E9C+hK>8d!
z5PSGhzjtn-F_-n6*FK<baSR^i_tL5H+INp91_O76KR<^E{7-CCm^l5gx8deWKv!-r
zOm(}Q$IYNE;@|Eh1XGD_zxqr>_;asb9Y4r9S4>nYyy0y1rCC(oUyY{t+3qMR%hGb|
zeG0X#OrdwK5f$46ogkoXL&20=dm7*(ow8-`zltv?lXmn)YHzkWU6ExJv+8V-CWK=0
zYvmG@PZK_e7aVd?Dc*|_3j3$ee={u`tU1^Z$bh>u7oQjh?0_<8qu=fec;c>|-k=;(
zpye-h(gpJj=(4b&DcaAhmyLp#<!SclAZ`^@_VX^zFvu}zW2xnXi@VB_t>x2`lO}#7
zoU8g_g5`I%eE$f`l-P90VqgbcmzR(JEW>IeF7G*V;~N&1%SuY7<t7Kdp<++ZfqXxG
zYw#+ARv~h4ljn&r_2Z|S+^20hcWFe-^i6`hs2n>SL)Eb!q=a(Dq5>W$&I;;D7e8=S
zZh1)?G__H8JLLEd?dFAxv4e{5Jp2*NZ6e>Qb&OUd0McVO`kBYA`~Yb3(UdEQQtS6t
zPZkN5P64*r?#_do%B=>p*T+!B2RiKhFf+pUZmyNVX^TUS8{F>#r+f?(5p_ou?_mcd
zC=s^b{`pG$Y-H9gSdCBZ<qJTiU>=@1@2{_~%=&ub;rAk7hx)E%Wy4gD?_U_@TS1eD
zINE3qNRY4K*Cw7aHpJ%Y%Ubue!9crgx+wWnK!+?6EP)q!w(x=}B69C$!9Nq%t`jfY
zKliy@2j-*~Wa-qS^t|h8-Lw-xpekBRE#H`GGu*aq+i}1wEx@Lj(pzdz;HLQKi9fM3
zGLkvyw+WC?a;9B-?;=$$2eBg?PZ%<oy+T=aj!7pb{=!Bc-K?rW9HJZBa0NPbL?bJ<
z4AW@GqWrmcjdgwyh0q2n_E|(Xc`Sr778t6ceFf<}`Zlf2t}pUKA{e7LQ{6cr+KfqE
zR0v}n^r28&>fFgj7%U-(fc{;xyl}@)DGy<y4-T4DOupZbDFEp&My8x5FO4d`Zq1$k
zZ0Imd%g@1YHx~Tm{vem7x-oF@3yT$2PO8~(u%+(8TY_J~4^X+9pOA@C@LUCNV)c7g
zylmmmN^wvO5%Tl!k_2`rH%MIB^~b2Xg$f9Ng`VYYBM_quuYPvLuLYOdhdX_A1s2mN
z_0`kx3rZhM<)E}8$OP)Bvz#7JwcWcOC~PLtE;P!Q2^&NOAHWDLZBeJhWAlmuJhq_>
zjXsFw=rE%mw6wIWzUp;Ziw=Ffl2Kh(mq|5J17{Wf%O9f`#G*gy1vz?xxk^*8*O)-J
zCR?fjtPmp2%>W8l;sA~I)K$4)nq83kDo5vn(&vG5&7S8wv%7JRIoM>0UAsEwczZDs
z<v((_SLadVeGMBMfvI$Q@H83NDV2=iORXI-djZ;9E^Wy|zcn)d6|;fiH0-Tj@mp5B
zShmQ(9qKp^*HTc-QUKljk2GrdZweLzdT74Ymi|PUDBa|Ve_*Eiyhgw%ltG7(a$M-W
z`Ie8Od7rARkJdORl{9PbDqIx~g<2t2CM?6dm>}1^U(Ucd;pJ$`hJKnkUYk2u-ry3@
zr4p*o*zBg}lzSoFxCMRe$fgQz#UT6q=2tn{EA>SFdCE}ZK8pbrbK4r{ZfbGzNA?76
z`P1Eh$9-`nFbTa{Io(#-L*0N}){sS{cI~<YgwG=EDiED_Gh>t<HpE8#u2ys!3LENV
zqLl5WbWc=n$s*<*V3iflA1VX5<R^PIe$HJyRvoI74U#7~X5mL;pTh)Z%3y7UQZ;^>
zDx~iKH^|!mtVnK8uipW8zjLo1zjPmrG0iR>|G@B129J$So)9_Jp#JU#+uaR9=yFH*
zu*sW+YI>60@hj@xvxp^M1>YMp<#t+DUM!ITRb4H%&#R2AcGmOW;zFOHA+D(;MW7Aj
zSVu7!ywNfGfQ%A`B0#84iBnEJjNw&L;~Or_Jk?G%N=0KUwbHWqwAuXF01gmrKdkle
ze`FJ12SncfF}AfMi5fFTJEkt39Kt1#3Q<mJgO@bNFXI%BT`;w|AJ?I?3l~~XmENH`
z&(71sFH3*9Sqt^|tKZs0jM|tcbJ2PYP>gq&C3$^bSE^lkm=l0?%o!4bMUdmI|Je)V
zNbOrA3}=mn(-tGK<a>+7gFglx&2`=F3VyeW-&n|(^Bnw>&?Ax+FYJlK3*L<wgUxKd
zVL|vYEY=COY+aBA%1HJ@g&u}?RieFRmpsQ9NH7ddv7_lMK~rS=cK$x=!TZ3T*)jP~
zQ;F;`jG<xkgt4^Nkt1MM_f(Niv`&r#JY^-6#pw4otnPhC7-Y;WO+fLaO}T?f(x#XD
zuX07qeZgVb6NfCq7_mdInI`_-uHv8t(%wPIqQ<YD__+dE1g(`A@pq}cWoB@I-r&Yc
zf84SFR%CO6-f6llfX-q9og-xMXqk)E#sOMeI*A0R@RPWLE5y6H0$NR4i*ObRWyCAC
z(&9k;kv@ZdG<0LiWSO0&UKzn<dw?U%1<<oQO#D`XkDGp&+gQlyekMCQYRuF#G=NLq
zoUC~23GjC<UFS9{;R?X6YuskO53v_D)vE51@+yWfWt6Xb5r0dh6%DHpL-{B6o-8Qp
zdT|D!M*y&wX)>_Sr>?m@ep(6!!3=8-7TCJ%{h-B?2!usZ#%J-tQt#n4cu<?NbNVkz
zP#x8y%Dcblz726;ER0~;pD)ZkeYGBUYNFD%bX!Bjh+%J*Q{`SZlTUW$248qXTYUtY
z1N|<ILw*1n)#34YPHMI4g$iQc6<kSsz={dTa)Mh(r+YtX?MX^Rn74w-J-_(_5?!dB
z%z2kT;ZxZ7j_LozUOq-Ny#4HddBVb0fyg%0$36(-_G4yj9&`zJ&(?s$FoG4307+$x
z$i1JpKo=(Iq$ma&x}Ml7Ze3_>_22cbhTXIqV@aMk&QRsqHohG{2xy^^uF1dxVw9$*
zQVGzQb%14rN)6?QcpKj0f>XH$2A-iNAA~zaxL^+DH7&&L@W2c7sEp4$W<>Wf_kFqB
z@gC(wJ<jT7CzX$E4eUVCPt_wws`Qd4_R3rgv0J0K7^ykRiB@DBUpTu(jiS;J(J=+e
zoWI$t&;V=g+^3hf-<w43>l+yvVS1~F%QT&|Ew(b*aM}%$!dC$+VOUv#y9Q7T=rW<*
zT-@&+`NewgD3C`6h+GwJZ=7tvMc-C`$383x9OOyj(AAG0R6xJ7^ulrjG&lJLAm8s8
zAvJ^JP_^9&i&X{SX>MHSth&1N#sKa}kz9i+mN3KBh!GoLfLXZ;cX*RzEzZC2BBvV{
z2JmT>cJlORw{19S3{U<1#(O2O!rsaygk$cw?_<#+D~;TjJQ09pz|LQ40d-BN)szTK
zYwqB0pY5E*Uv?X{N)MrZh6>ZSee@&_{bWl4+A*i&9D*yfzUC;=u0`dQfO@T2TVFqN
z`g${03j@M~_MD*^bkk9KY3I}@T90%2;BvfAH!kRmZHL~UQfc-&@3{6b*}0G(XvvMT
zr%F!R*rzXM7>7y5Pqpp$)sXxJqLw1G<R!fD&p<p><0@i3(iTT^yM`3-<49$1&`gQC
z^dGs@7_$gvpMQOn1HXgK8mBXvQ7NQ{80T|UB#KNP=%kyduF5e76N>z)JWcEf?NTPS
z*DuPoj`R?nw~y6PI;$DP9qGP1wJ9|XvRZ$LZ_I{frxMZpWFp`4VZSvDB^Yz6i~*Xp
z9}{tkFd9`w?8bAwGP@?H&9XC(Dy_v+JpxtRMTJcz+Bx<=7zkiR71p=_)yPol9aCI+
z&~AKGw-ayCN=rU+uqVmN1lHpiEn4QkFcre*-{K+skMEvM8eVwi+wjx5>Wn`3pMtF2
z-GZAzO?RGfVxeMFp5M81MTM2)Xm)Sz;Jv#Pbe;k$62G>0Zubso6%S9Z$QS<CC!fgt
ztI`rB2yKx5M%SE=SQ$V!xzcCQc~fi|yb3nl&+q9k^LKG?Zjvm(DgDaPe7ay4Afa+^
zvA?xyO^Nl)`Yb>Y7Nh)H>oCY@r7tto9}UG#wY{6o2nOD}(z(1DWS7xOoEv{QK&G2d
zZE>duXPeFQ<q|AGdp)}PO69p;x8Q|IHSCDU4;$kX(Cp)H`swD!^`F>xO|}FM4sWmq
za7;4*PX@x6<2_weUX>j$co*8)d`-nWfXqfq==L#F+l~lTF+eQ)@UFp|vqjPt9+Q>;
zO!@$kE=X=6_}Q-q`t2cab*RW}nXfRVGjAXJ^ck={Uj9m=x^!wf)P_TAxiH4{p7-Hx
zR|CdEBoy&2Rc92(((sZf5*oWYMyu$A>-gcFU3^)x%^lQ9wV|Q6stpt4sUU(ISED@e
za2(~ogNVkVgJuaa*cv-i-C9mGKOOy62gvyWmXEfYI*^Pl1WR>FOLy584AqHV2Bb!G
zW#;(9pRqLk)gKe$=D!@qLLLMm$;L6P5#0IB;EQ7ds2{uWoV3OFjWZp6nNvM^JlQ$d
zN-~+V3ojC?UNjl62Q9n0T8TzAo-b~+(DO?JUSthjlxWEUm?{EaN98KHKL6$fGF9lz
zRjt9f(H9LgtV6lOS_c!P+bJW@gWH%YZqF{feG7lDOi3w(tAP^d07oD^QmYj>&V9r;
z?d|yIygk_NMnB?Ke2bFBK<}iRU~B<U97wu8?)XtFf8doQjA}QMZ#B9JWfOsZJ#sr|
z-+pW$cT6!Q$u*qyNU!^;?A6(S<q}R@lGpkRuMO9C4~_NDE;fnR6_TKsWEZdXfvD&J
zKBi@PHtsFm2&yj=)GfvbKsY<j5Ug6*-~<(8s~J@CyKNB*@k0lppOlOn0WWD+Nwt=1
z)Z-jLtu%rJG6D)T++|tQp=mvycnFlzhWV-L$rB%FV}EEb4~ME>fn;x5=61gAcPjKE
z3;9TMN}SrH`a9wi2GpB8r+f0+Yil`CPW1iVQqhDw_Ud;)0Y|Wel`#PDF4R)RH<fRn
zwaYGM)bkn|XN;$v8-iK9?x*F`St1$4D9>xxuIY~M-0Z0WBIcOUOPU@#!sm}#u0HJd
zUcpgQZe^N1I?v=6wN{Couvu)sj^UO%l$EC~dVc(14xN@3p0*Mxe{~CbZbb$i`jdcY
zf(#Mr^r^4uphA+i*k8P#<-#^(vlZYvBZ9MwIT8?shdtZSjZ0g@_lp6f+&{dbN)P5O
z3~1sR_NwNb&ksv4N66LgH724eV-QzxWu$g)38zWGD+zYdDx9BR{WJqkSlV~G0e}V@
zQPaILN?VCD>}i9gb4!YdJU$u|;s5bN$<D2}ZIV4C&N#xd#DG4dgGq>UF#<~YhFn5&
z5EpJtoOa1(rXWQ#r~5Ll)`Gr?unL6)?ekA1vtTO8;Lwe(a{bVfX?TM#Al=rlg<Lyr
zs<&V*0PEjL%`XY$rsNFy;zerq3LD2Ej>TLa{E7!bnNY1dO*k}TgPnm;(pxIg9})v5
zZrNo&RN+jiTNq^&`*eKR1m#LkY)h+O(%ko|F5^2V15L}h0w46UMU3~A$Gxn3bst4L
z1{kV2G;E3-8m$jf3F2a8`k5z35c_fl7-ttK!30T<ltoHjjxwtVM1Xv!m>47cLlovT
z0o?`~yoW?LHrxL#H6If8UVyFeBErJ83mX>;<TJZ^F%%KOWG1K^CiM5zK~mDxln#+Q
zl~ljsp%D<mtEEe^e?=UTY`(S$g^NuBDip*e3NqkViW_H+dJ(g-K#DyN?cMmbB<U&F
z9x+UWIdpw^_#H)ah4uH?xqP*d+G0cJ&R0yAj`9_7p|;t@{yk;iD*<%8L3ESxIr{O7
z2yk%GMpvgu(D5XS!8Fmb7b6bEUBA9z>^x_a$~M(a0ma+GV4!BeCP<j}o7Z?noc)rR
z6C1S$HkUY7<%-3=;lZg%JhtI9T?oNNh8s0w?}93&9*EcGKAL4(uzAnqbCSw)UJlUL
z?+0(ijRxcKEhp(^o7%@Jd{n!=#~Q=L&3;*SoW?}V0c!Q@7_R4#1QmrVwx*=-y&l+i
z-8s!EJX6JEl?_?L3WLc<<73i^dHYKBIKNaQYLe^SDskP}Bx|{+8KUOlmT~6Lqw@)r
zj+;{bGX?vkKrXZ$TR>PW&Ck#G@YT#|B1C)8Z7$1y5+oSf$cbuhgB!22@MAlIFRmg+
zsb0MV?tC67E~TsN`{f=jtKV%)MFCw&+$bd*!WBZcUA;a&^t7Y8bS#m@x*k|7*g2$t
znMt$n2uvc<XzUJZ+#k;4l~JWjCWLAbW*$s@{qGT6=v`9SR)(tHgJXrQ;ymI0hB<x_
zsB@9J{KdUcZ~PSmAdm|FD0t3GBCJM3AgooRT$*zqpqD$u*Bg9OiBWpTd&boFBw2}V
zy}i$+oAPu4HB&K=-+LsUG<1pmn{|(SJ<rWXRNyD?BfGw_hfr~ZLKf)!b@o9nt@_PW
z21pYBg-W$XIy0u1Hui;0zOOFZr<U@ZS5CO1B)WA?UGn782^)A~6=hTVmEADAW*=!c
zH9<u|hKlHF*s<G)z>U}tenfvhe7B2uohX|;p+ra){-XwT=U!VnHpKdzhf<uAkT`f~
zQjn2GdeRcv(bc53nv(s$)UkTiUbkis64>{G$<!FFgdz^y2ze@`c~9%2hN@~`2&ai_
zSmI7@IYkGJ&`)+WiKwJTxy>FcH+U%L7Gc=_PR8I1n@b$RVU5%%9I(}TP&;yu>e3zY
z;Cx>s3YVpwT=4K}-aCJ=UjG_H#XHm!I=X8APE*A#$HfNRU9WRY)yWoV-8RAY+I*L)
z;0Y}Upd@}Ln9wayK!?W4#&rg9eFAdS;Lou`Nnq(so<a|%W>U&68WbwkriLM3sMLbF
z-`z^P1f_uI3GPy=p)-K+H1AejuZCMr@DXoShu(jGTpnxusV0z5nPnH88dxmfzh3L+
z>EAG~3=LO++wp<{u))fD{Sk9{3sM${`WEDEh#Ihln#BN!Nt&SjUof|Rw_;TY>=CUC
zsZgAcLK($RZMupA-Cg_hh$D&6hX8*PeCcm^q_fCDCZB=kXOP6Ri5IJIUEiSDn{=-#
zQX+|pPC&i}XB8skXPSl<TBo9k#Nlgeoyov`gi*zyZW@JxX6ce|Xv*t}PZ$HKqI(bo
zBdgnmmyTKaE;O%<REipV6~coklH*7kV3J1D@%xc)>I!uWJ_yQ%h_XCPeEo|HS3jZq
zHjG9oTG%NQk;1!Fp-@8<Wjq8hz_QP7$X{Z6Ocyp}F;4(96@DTnCdPns3^`Y@a<UtW
zV%J7ng@>7>Jf}{(K~+5*{H90Hb9v|-P8KQ=gnZVkB(sEJz$o$N4Gm`$o2wywJi<AL
zoZ{o}hy{sPc^(myUF^|Ag|c^e7==7cJ?(D{Wd`(f5YdgyD{n#mzI+?znevXwH!70*
zb)V=4h2xPPV*<!sv|fkXFRp{OGJA2$+wp5!0NX<4(}MC=<cq~OkTGQ&9$>MYCUb@?
zF(WdpBiIoc<_y~?qZ$N)g3p}St0;$GXTAEbr2E-=i+lKP>S4gDk=H&u_4Nrt85hI7
zAg|cd{m>c!c@c|#{`W==25SA?1(?S5Hyxtg|DEywpXmRBG5Wf;iF{7)d%4Dd95Q=Y
MQ_JHO$2@QRF9rjRdH?_b

literal 0
HcmV?d00001

diff --git a/doc/logo-with-cli.svg b/doc/logo-with-cli.svg
new file mode 100644
index 0000000000..9d30581484
--- /dev/null
+++ b/doc/logo-with-cli.svg
@@ -0,0 +1,107 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   id="svg2"
+   sodipodi:version="0.32"
+   inkscape:version="1.3.2 (091e20ef0f, 2023-11-25, custom)"
+   width="337.62668"
+   height="275.14575"
+   version="1.0"
+   sodipodi:docname="logo-with-cli.svg"
+   xml:space="preserve"
+   inkscape:export-filename="logo-with-cli.png"
+   inkscape:export-xdpi="300"
+   inkscape:export-ydpi="300"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:dc="http://purl.org/dc/elements/1.1/"><metadata
+     id="metadata7"><rdf:RDF><cc:Work
+         rdf:about="Git Logo"><dc:format>image/svg+xml</dc:format><dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" /></cc:Work></rdf:RDF></metadata><defs
+     id="defs5"><inkscape:perspective
+       sodipodi:type="inkscape:persp3d"
+       inkscape:vp_x="0 : 101.13537 : 1"
+       inkscape:vp_y="0 : 1000 : 0"
+       inkscape:vp_z="97 : 101.13537 : 1"
+       inkscape:persp3d-origin="48.5 : 69.802067 : 1"
+       id="perspective11" /><inkscape:perspective
+       id="perspective3682"
+       inkscape:persp3d-origin="0.5 : 7.4687698 : 1"
+       inkscape:vp_z="1 : 7.6353698 : 1"
+       inkscape:vp_y="0 : 1000 : 0"
+       inkscape:vp_x="0 : 7.6353698 : 1"
+       sodipodi:type="inkscape:persp3d" /><inkscape:perspective
+       sodipodi:type="inkscape:persp3d"
+       inkscape:vp_x="0 : -140.76773 : 1"
+       inkscape:vp_y="0 : 1000 : 0"
+       inkscape:vp_z="97 : -140.76773 : 1"
+       inkscape:persp3d-origin="48.5 : -172.10103 : 1"
+       id="perspective11-7" /><inkscape:perspective
+       id="perspective3682-8"
+       inkscape:persp3d-origin="0.5 : -234.43433 : 1"
+       inkscape:vp_z="1 : -234.26773 : 1"
+       inkscape:vp_y="0 : 1000 : 0"
+       inkscape:vp_x="0 : -234.26773 : 1"
+       sodipodi:type="inkscape:persp3d" /></defs><sodipodi:namedview
+     inkscape:window-height="1517"
+     inkscape:window-width="2560"
+     inkscape:pageshadow="2"
+     inkscape:pageopacity="0.0"
+     guidetolerance="10.0"
+     gridtolerance="10.0"
+     objecttolerance="10.0"
+     borderopacity="1.0"
+     bordercolor="#666666"
+     pagecolor="#ffffff"
+     id="base"
+     inkscape:zoom="1.6910175"
+     inkscape:cx="20.401918"
+     inkscape:cy="180.36478"
+     inkscape:window-x="0"
+     inkscape:window-y="0"
+     inkscape:current-layer="svg2"
+     showguides="false"
+     showgrid="false"
+     inkscape:window-maximized="1"
+     inkscape:showpageshadow="2"
+     inkscape:pagecheckerboard="0"
+     inkscape:deskcolor="#d1d1d1"
+     showborder="true" /><text
+     xml:space="preserve"
+     style="font-size:48.1739px;line-height:1.25;font-family:Frutiger;-inkscape-font-specification:'Frutiger, Normal';font-variation-settings:normal;word-spacing:0px;vector-effect:none;fill:#666666;fill-opacity:1;stroke-width:0.735607;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;-inkscape-stroke:none;stop-color:#000000"
+     x="18.510771"
+     y="248.40559"
+     id="text1-7"><tspan
+       sodipodi:role="line"
+       id="tspan1-0"
+       x="18.510771"
+       y="248.40559"
+       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:48.1739px;font-family:'JetBrains Mono';-inkscape-font-specification:'JetBrains Mono, Bold';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;font-variation-settings:normal;vector-effect:none;fill:#666666;fill-opacity:1;stroke-width:0.735607;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;-inkscape-stroke:none;stop-color:#000000;stop-opacity:1"
+       dx="0 0 0"><tspan
+   style="font-variation-settings:normal;letter-spacing:0px;vector-effect:none;fill:#666666;fill-opacity:1;stroke-width:0.735607;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;-inkscape-stroke:none;stop-color:#000000;stop-opacity:1"
+   id="tspan3-4"><tspan
+   style="font-variation-settings:normal;vector-effect:none;fill:#666666;fill-opacity:1;stroke-width:0.735607;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;-inkscape-stroke:none;stop-color:#000000;stop-opacity:1"
+   id="tspan4-0">&gt;</tspan> </tspan>git annex</tspan></text><path
+     sodipodi:nodetypes="ccccccccccccccccccc"
+     id="path1927-4-1"
+     d="m 160.79525,192.35577 c -11.60008,-1.49439 -23.53847,-12.46256 -25.20639,-25.33023 -1.59972,-10.75758 0.70817,-23.31443 9.6007,-30.41399 3.90042,-2.65848 9.20606,-5.63712 13.88482,-5.28265 0.14013,4.76254 -0.14013,10.55125 0,15.31379 -5.57282,0.62044 -10.96717,6.95467 -10.85492,12.75434 0.1366,7.54733 3.47685,14.48175 10.73818,16.7406 8.03172,2.70257 17.22586,1.93392 24.66094,-2.55921 6.14217,-4.7856 6.71028,-13.6958 3.49781,-20.4765 -1.44495,-3.73134 -4.56003,-6.47068 -8.78786,-6.45923 v 13.28344 H 166.40691 V 131.3289 h 36.10126 v 10.28372 l -9.88833,0.0915 c 9.22745,5.26008 10.1733,16.6128 9.70037,24.48894 0.3325,13.5299 -13.03437,24.56116 -26.292,26.03608 -4.79652,0.35961 -8.85473,0.37853 -15.23296,0.12667 z"
+     style="fill:#666666;fill-opacity:1;stroke-width:0.735607" /><path
+     sodipodi:nodetypes="ccccc"
+     id="path1925-1-7"
+     d="m 135.00354,125.64811 -0.0758,-15.00768 h 67.67588 l -0.008,15.07995 -67.59231,-0.0723 z"
+     style="fill:#d8382d;fill-opacity:1;stroke-width:0.735607" /><path
+     sodipodi:nodetypes="ccccccccccccc"
+     id="path1917-90-1"
+     d="M 160.79658,105.36859 V 89.307826 H 134.5599 v -13.97654 h 26.23668 v -18.02238 h 15.69293 v 18.02238 h 26.11406 v 13.97654 h -26.11406 l -0.25871,16.027244 -15.43422,0.0335 z"
+     style="fill:#40bf4c;fill-opacity:1;stroke-width:0.735607" /><path
+     style="fill:#40bf4c;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:0.735607"
+     d="M 91.825744,18.068854 76.171139,39.953171 h 8.68936 c 0.01763,2.418934 0.222525,4.801478 0.574654,7.126197 l 13.81566,-2.091884 c -0.247091,-1.644053 -0.396048,-3.325842 -0.413778,-5.034313 h 8.643395 z M 100.3312,49.906858 86.975373,53.92971 c 0.679483,2.253194 1.505492,4.445378 2.482673,6.551503 l 12.666194,-5.861871 c -0.70324,-1.517249 -1.30665,-3.088285 -1.79304,-4.712484 z m 4.18377,9.011189 -11.746687,7.562963 c 5.285482,8.195887 12.907037,14.747249 21.930287,18.689025 l 5.58598,-12.804167 c -6.49673,-2.835317 -11.97061,-7.5448 -15.76958,-13.447821 z m 20.41311,15.07995 -3.77,13.470807 c 2.13297,0.596378 4.31508,1.045614 6.55155,1.356282 L 129.6406,74.98647 c -1.60694,-0.22606 -3.17878,-0.559429 -4.71252,-0.988473 z"
+     id="path2836-9-1" /><path
+     style="fill:#40bf4c;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:0.735607"
+     d="m 245.29182,18.068854 -15.65468,21.884317 h 8.68936 c -0.0176,1.708471 -0.16669,3.39026 -0.41378,5.034313 l 13.81566,2.091884 c 0.35214,-2.324719 0.55679,-4.707263 0.57466,-7.126197 h 8.64339 z m -8.45948,31.838004 c -0.48638,1.624199 -1.08981,3.195235 -1.79305,4.712484 l 12.66621,5.861871 c 0.9771,-2.106125 1.80319,-4.298309 2.48267,-6.551503 z m -4.18377,9.011189 c -3.79897,5.903021 -9.27284,10.612504 -15.76958,13.447821 l 5.58598,12.804167 c 9.02325,-3.941776 16.64481,-10.493138 21.93029,-18.689025 z m -20.4131,15.07995 c -1.53374,0.429044 -3.10559,0.762413 -4.71252,0.988473 l 1.93097,13.838616 c 2.23647,-0.310668 4.41864,-0.759904 6.55153,-1.356282 z"
+     id="path3649-8-1" /></svg>
diff --git a/doc/logo.mdwn b/doc/logo.mdwn
new file mode 100644
index 0000000000..401e7fae7f
--- /dev/null
+++ b/doc/logo.mdwn
@@ -0,0 +1,30 @@
+Variants of the git-annex logo.
+
+👕 Since March 2024 you can buy shirts, hoodies and backpacks with the git annex logo over at [hellotux.com](https://www.hellotux.com/git-annex).
+
+[[logo_small.png]]
+
+[[logo.svg]]
+
+[[logo-with-cli.svg]]
+
+[[logo-with-cli.png]]
+
+(The font of the `> git annex` text is [JetBrains Mono](https://www.jetbrains.com/lp/mono/))
+
+[[logo-old.png]]
+
+[[logo-old_small.png]]
+
+[[logo-old.svg]]
+
+[[logo-old-bw.svg]]
+
+----
+
+	Copyright: 2007 Henrik Nyh <http://henrik.nyh.se/>
+	           2010 Joey Hess <id@joeyh.name>
+	           2013 John Lawrence
+	           2024 Yann Büchau <nobodyinperson at posteo de>
+	License: other
+	  Free to modify and redistribute with due credit, and obviously free to use.
diff --git a/doc/logo.svg b/doc/logo.svg
new file mode 100644
index 0000000000..bd87eefefb
--- /dev/null
+++ b/doc/logo.svg
@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   id="svg2"
+   sodipodi:version="0.32"
+   inkscape:version="0.47 r22583"
+   width="251.1875"
+   height="240.34375"
+   version="1.0"
+   sodipodi:docname="gitlogo.svg">
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="Git Logo">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title></dc:title>
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <defs
+     id="defs5">
+    <inkscape:perspective
+       sodipodi:type="inkscape:persp3d"
+       inkscape:vp_x="0 : 94 : 1"
+       inkscape:vp_y="0 : 1000 : 0"
+       inkscape:vp_z="97 : 94 : 1"
+       inkscape:persp3d-origin="48.5 : 62.666667 : 1"
+       id="perspective11" />
+    <inkscape:perspective
+       id="perspective3682"
+       inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
+       inkscape:vp_z="1 : 0.5 : 1"
+       inkscape:vp_y="0 : 1000 : 0"
+       inkscape:vp_x="0 : 0.5 : 1"
+       sodipodi:type="inkscape:persp3d" />
+  </defs>
+  <sodipodi:namedview
+     inkscape:window-height="825"
+     inkscape:window-width="1440"
+     inkscape:pageshadow="2"
+     inkscape:pageopacity="0.0"
+     guidetolerance="10.0"
+     gridtolerance="10.0"
+     objecttolerance="10.0"
+     borderopacity="1.0"
+     bordercolor="#666666"
+     pagecolor="#ffffff"
+     id="base"
+     inkscape:zoom="1.7347111"
+     inkscape:cx="79.460121"
+     inkscape:cy="96.862066"
+     inkscape:window-x="0"
+     inkscape:window-y="25"
+     inkscape:current-layer="svg2"
+     showguides="false"
+     showgrid="false"
+     inkscape:window-maximized="1" />
+  <path
+     sodipodi:nodetypes="ccccccccccccccccccc"
+     id="path1927"
+     d="m 115.03986,236.92929 c -15.769481,-2.03151 -31.998702,-16.94187 -34.26618,-34.43444 -2.174671,-14.62409 0.962744,-31.69413 13.051455,-41.34542 5.302266,-3.61399 12.514875,-7.66322 18.875285,-7.18134 0.1905,6.47429 -0.19049,14.34359 0,20.81788 -7.57578,0.84345 -14.909032,9.45432 -14.756408,17.33851 0.185705,10.26001 4.726478,19.68681 14.597668,22.75753 10.91859,3.67394 23.41726,2.62901 33.52469,-3.47905 8.34971,-6.50563 9.12218,-18.61836 4.75506,-27.83618 -1.96442,-5.07246 -6.19899,-8.79638 -11.94647,-8.78081 l 0,18.05778 -16.20641,0 0,-38.87566 49.07678,0 0,13.97989 -13.44239,0.12434 c 12.54392,7.15066 13.82967,22.58379 13.18688,33.29078 0.45188,18.39283 -17.71936,33.38895 -35.74198,35.39399 -6.52041,0.48886 -12.03738,0.51459 -20.70798,0.1722 z"
+     style="fill:#666666;fill-opacity:1" />
+  <path
+     sodipodi:nodetypes="ccccc"
+     id="path1925"
+     d="m 79.977992,146.2455 -0.103031,-20.40175 91.999999,0 -0.0106,20.5 -91.886388,-0.0983 z"
+     style="fill:#d8382d;fill-opacity:1" />
+  <path
+     sodipodi:nodetypes="ccccccccccccc"
+     id="path1917"
+     d="m 115.04163,118.67709 0,-21.83334 -35.666669,0 0,-19 35.666669,0 0,-24.5 21.33333,0 0,24.5 35.5,0 0,19 -35.5,0 -0.35168,21.78777 -20.98165,0.0456 z"
+     style="fill:#40bf4c;fill-opacity:1" />
+  <path
+     style="fill:#40bf4c;fill-opacity:1;fill-rule:evenodd;stroke:none"
+     d="M 21.28125,0 0,29.75 l 11.8125,0 c 0.02423,3.288346 0.302477,6.52723 0.78125,9.6875 L 31.375,36.59375 C 31.03908,34.358787 30.836567,32.072528 30.8125,29.75 l 11.75,0 L 21.28125,0 z M 32.84375,43.28125 14.6875,48.75 c 0.923692,3.063035 2.046663,6.043138 3.375,8.90625 L 35.28125,49.6875 c -0.956041,-2.062577 -1.776322,-4.198284 -2.4375,-6.40625 z m 5.6875,12.25 L 22.5625,65.8125 C 29.747774,76.954156 40.108616,85.860221 52.375,91.21875 L 59.96875,73.8125 C 51.136943,69.958114 43.695592,63.555939 38.53125,55.53125 z m 27.75,20.5 -5.125,18.3125 c 2.899536,0.810722 5.86596,1.421431 8.90625,1.84375 l 2.625,-18.8125 c -2.184482,-0.307312 -4.321319,-0.760497 -6.40625,-1.34375 z"
+     id="path2836" />
+  <path
+     style="fill:#40bf4c;fill-opacity:1;fill-rule:evenodd;stroke:none"
+     d="m 229.90625,0 -21.28125,29.75 11.8125,0 c -0.024,2.322528 -0.22658,4.608787 -0.5625,6.84375 l 18.78125,2.84375 c 0.47877,-3.16027 0.75698,-6.399154 0.78125,-9.6875 l 11.75,0 L 229.90625,0 z m -11.5,43.28125 c -0.66118,2.207966 -1.48146,4.343673 -2.4375,6.40625 l 17.21875,7.96875 c 1.32834,-2.863112 2.45131,-5.843215 3.375,-8.90625 l -18.15625,-5.46875 z m -5.6875,12.25 c -5.16434,8.024689 -12.60569,14.426864 -21.4375,18.28125 L 198.875,91.21875 C 211.14138,85.860221 221.50223,76.954156 228.6875,65.8125 L 212.71875,55.53125 z m -27.75,20.5 c -2.08493,0.583253 -4.22177,1.036438 -6.40625,1.34375 l 2.625,18.8125 c 3.04029,-0.422319 6.00671,-1.033028 8.90625,-1.84375 l -5.125,-18.3125 z"
+     id="path3649" />
+</svg>
diff --git a/doc/logo_16x16.png b/doc/logo_16x16.png
new file mode 100644
index 0000000000000000000000000000000000000000..c98663d57de86f1db8b549da460cfa1968013ca6
GIT binary patch
literal 233
zcmeAS@N?(olHy`uVBq!ia0vp^0wB!73?$#)eFPFv4DbnYJ#+f>w5e0io;kDN#*+UV
z*8NwJn>k~K?FKhvL&Gy?&iw!Xzc$v%9;lcx$=lt9p@UV{1IXbl@Q5sCVBi)8VMc~o
zb0mO*>?NMQuI%@i1%%DT|Ghnw1r+l0ba4#fxSkxbHS6jpEro*{vZijV+-Nu>kdGyS
zEr#nL1G9p%2*&{)aRrB|QP-AUWK26V;nfKyW23OrQYXpPw-yAgR!}-^wIC~OqbdU@
Z!%IakEs06KXMiR%c)I$ztaD0e0suI|O<({3

literal 0
HcmV?d00001

diff --git a/doc/logo_32x32.png b/doc/logo_32x32.png
new file mode 100644
index 0000000000000000000000000000000000000000..9075cc2b61aa2a3422f2e501b4280bd2a1e7d7da
GIT binary patch
literal 473
zcmV;~0Ve*5P)<h;3K|Lk000e1NJLTq001BW001Be0{{R3M5Kzw0001@P)t-stgNhS
zYip*arhI&S#Kgq@{{HUn?r3OeXJ==ZmzU1Y&Xbdqf`Wqh`1q%%r@Xwpetv$OoSd?<
zvbeao@bK{a{`{n*q<DCEb#-<2_xF^cqT%7;d3Sfp%F2t2i>axpZEbDe-{1KC_{+=7
z{Qms<`uhI-{K3J&x3{<Q_4RIUZu0W-tE;QU#l@YSou8kdh=_=BadF=@DLb)7W@cvp
z|Nrj1w9Ehi00Cl4M??UK1szBL000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2i^k^
z6azHk?^bF6006y7L_t(I%eB(i5`r)g1<)YU?Y;NjHFy92*Q5;?69=7<`;^%n*iC?u
z7|yv^VE+Q`Rn{98*)6!3JV4&}@I8={f`^zqz*{!I4@vt0U=ZTSpg#g^ib1I>gKP9$
z1nP2&mS65I13<0?oFz~MW+sJzs=z@4C!jzvC~Jx#JHRe!TvGrBI0?8bz!tE~bRHQT
z{h~e$mtz~y*3vz&;QW(m<Dv(PrsAq^NaLx#h2bRol@Gt1>xJ8e`Ah8yXr9Ww`WOS7
P00000NkvXXu0mjfogwCU

literal 0
HcmV?d00001

diff --git a/doc/logo_small.png b/doc/logo_small.png
new file mode 100644
index 0000000000000000000000000000000000000000..252b761d096848611c090155f67780c87257cafd
GIT binary patch
literal 4749
zcmV;85_0W{P)<h;3K|Lk000e1NJLTq005Q%0052%1^@s6(}eL900004b3#c}2nYxW
zd<bNS00009a7bBm000O?000O?0oO&#000008FWQhbW?9;ba!ELWdL_~cP?peYja~^
zaAhuUa%Y?FJQ@H15(-H~K~#90?VWja9L1f-zrP;I2S}L1Cg2xha~Q)0Viv^ZgXtLs
z8%vtu@Uu7)UdSd;Sy&)1j|9A6cuMkKfMiKHOeogbK)`H}g8@mtu&wTq!LR{yENp@|
zoC_Nk%O-%qvL#Lb_KzOn(P(DW-P3dQs6OxMX{P#DRlk|}zN+e~UsV$`!wq_(Wf_z9
zi^N$SZ@bE<2qfX2_>sicb!NEhDmVEwH^xyTehD#MNz4zou51mtb5RjAT35D)i1}e+
zx-x3SFL9ICv9KcM`O}$jF8~l@cJGwFo7_682o}9l`feh|Yye=wy%F>L=}z-H5|-UM
z4Ll6+q_pIvdLnkFJ69D!A@$oX-Iv0XfC0xnl_O#8n7rpkfaYW*hlsJFX>HR1PMuW*
zgQm4j2M}WgfD94Q99s*cGpexkMC?o^zB$L`Blk=Q-Q%PpMQ}*{rblMG#>6)}>8bJx
zE4OmfE5fCEB7X5`6)A#&o`_$}giG_7IO?hL3M-#-(;>#M8@rpQjb^8)Y#O_prxD}V
z4opYwsd5U-fpXK}NtUKPq^2N(OY6$kkfmu4W!#|UWVD_ttFT-sH=TLCQ~H*;%%i9f
zQor3iH+k~)R3n6CE0<O{Rc;2iM2+UtJ>*lAk<@Q?i~F2B$<k;=ww`K)uyRZ-IHiUu
zv?5}*)_KgYC@~SUwT>yY0zi$o60%Q03=>wwjGw{8OEZn!!AAqT?=GwiMd{dmxBZ)W
zhl!U)%=j7UX*9G5J@=V&>uUzBmx*yyA(f<6)@p{kR{BwvqB!V@mc_)>?nhZncx$jm
zJL%~;PwoQJTC8#X)-u0D1pve(!#(F6;a7PIe+l=TcLXs>zse)VQRDipWkc^Z!0pt6
zV-C`+<nP+r+FV6YD2h*8Tbrg?$=?Au$j@@qrywZ0scD*}g<kP^7w7<5V(1;W7N=~5
z7b0f-27rH7oYLtN%}UN9-DtTRx#urVK%V8C4BiK@GfR5ErG*wH&U)fKFK#OQCERn~
z5t@~J48XW7mk$Qubojym{xiq5&6F>KR8Pd-CB|2r)IyBwyCa>qJ9J7>f#`{rtBL6@
zhvvP8-g#)Qi=&Nyb~ts4iE>t=2nNJ-hzs*<z0()u6&5jioz}v{Q=Hl=DwfI4P1(D!
z0CFrWVyJ+>z(a0UO!D?-qfO%v%gh7|z&ik5*DT(~q-_IuTQW4Tt!Li44_r8<s6Y(8
z<FW-$UGSs5<NId<bR03w1b8NZnXtpBzR(L3<!!O@3X7OG0Ne}UbwJxTv2XB=H4E45
z_2WY*DwFl|S8WHd9l+-F^oFeswfld5*fE-=%>=BOnx(ywubjMhg$jjNe4Q1Km=TXF
z<cf0R_itBlVd0+G49(&=Krx_hGVDoJMc}C0tS4d?F?EKLTF1u5C;n7OX|B7%)|IWH
z?T7B3tyvUfLLBzMF1^Sz4ZY*JLYz{RmWbJM0zj{(r!nCzV(QQ=bXwZ39z!<<-IVF5
z#j-<clILg^#dr#ui0KffT-MfQ0F<x-1QUImGTIkA(uKcoY4|=+_i@CGtz)7N;?P<{
zfBfUo${cl!b<X;84z3-rwi8o(Dgt7Z*;#5LP)^w?Di31BMlm@Mz(vIT2r$^|Bphl~
zVXa%R?jwLVk7ftpLt?%WsQDU0-D(DjiG9fiVq6c9gSklB>Lj4RQCCQ;J;20g=eYVN
zz`p=Kd!RdF>~T_FCDX9Ap|*b45&OHzGqG=PUy$eb)+}7}DS+FX);8VQH?ihYCjKEY
zj?HFEZ2g;)G967f?3pm(aVC74k-U|dF4PmJ9Bb&E_ZfQdMFjx$yQVe+gMV}L*Edo7
z$8!7a2Wu9t*=y(>%OhsP@x;7{34hEm=?f+IKI)__M=jQtGu!*3M(j~0Tn=C(z_%HC
z*G2$9WTbstTbpL+&tDZv(tm7<c4j)Kr~o2n^GU>7bn=dgceXEXPo`hH<(6A40ILA3
zikLASpz8rX2f(TgU*GVFlky$UV=>VknuYr|MLS;1XBX~iIi7S{PE4~cjo+E~bj!(`
z=XU+gX+4VKGxwQu>uaI4Ghs&Wl)j6?J<Z=qoVEJZY_^8pX#y~#Mr;-nC$rgP!?Cao
zz2o(K*BiDr)Yg4=*bM}_iFhbFk*3!S@^1m0=d>P0@u?Y1E(d5v>g}nT71|m#;<rxT
zG2y4}i`)CN<>`)ezT&11UzT+AMEunHT~oIb(~tLwY6v=4PsD!cM?H$dNkxga4o~G;
zCSKY*rSE0G4$~`0Sn;m-etIJIFU0&Tz$fOiBgSnJGv?}WRE7UU%=mYS>CQYR#{+me
zYQ*m<bT_+aVMUEt<EQofDlvY5(KlQWfP3^r%hg`%QxrzjXt@I5`(ghUIU$C|#8(4-
zuSLw}bG+8)Nmz~D@%c>H=yroEG2NxQ#nPiETCQfI`!I^AGMENvYxP8Iv|0JAcoJ53
zv~vSMtG(nU#_bU^_J@dh{()ZdE1Wa;nRDy)L~KQB=Z%+Twv7?9!PD>TNmvZ#P_pJ*
z0KD!MTm%fhoOzIh!apKr^GUS>)>dM;I-h+X^g$@8eKR$u<r>dptc{JUc4`)11i)1|
zMH<rp-W)MwzdCDkliK0q6Z4*KIVfVrZw0jH0L&OQLw1r();BgbKKY?nKMJ}l+!XEF
zLJUX8Gv}ZNz_p=d=q)|b(x#5~_D;lXt&5nkn`#ENw*kH$z<94^5z~*&aF<btKLyWY
z8Ii7^1N@r;i>V`~o7K_Y-XZS01HeywID=zFxaX9g7V1yIp~(zp(&_SWB9<iPD+(!#
z*jk?cK4LaEXjbUp{&CjxYFWtU?2TtnN`@vh5Od$AXxEmZbYd(|t>t=#7!QSe8ZPrX
zt{PsJPoYx;qHv=59%8!EV-YVIdgsaM33?*_7%^V}fSK?YfWMdCMC*x`dBpV9Lj2Cc
zECAnglYu}h8Qkrs6HL4<{j)}mbLTKw%VCFt6BD}4aA#wBo`@OS0>I<UIX$Q+PWcBv
zL<RWJVhzDyMi^H`jd;?YU~^r<uo>Zq8L1)E4}Eb&jAJ!x_#!AVz5zgZ_1P~Nycob@
zKg%T69t2?Qdv6Ue;kY!DxeK0Ju>bn`>pxFRyAz&-#SiF-hVS?#D!}LMUjWb@>9{8K
zh!n>w;Y`>*vCsPb@YMP<MvfP>H+^t1kPz3tIs84w^^Y5$5w!H#V*viwMX}6;+x5h$
zzKRMcg0KL<40ruRv#cl_e@MP>WCSKJ$S~^bj&}Xk5C4M5#>Q1U0c31q82%j@x-rOv
zWpDr!wiEM0Gu(N--=YGFBrE{f6kXjDO4iOAZHAr+{luK*VFi@APW6_GrAKCqJz_1d
zX0Y~t0Dbw3;SI#rtnNtHdjDJ-PEpSX-PpKlr=fSWFwqYHWDQ*=rglSL{eS6c5i>rS
ziBBGG$$8HT7$anU2gjVfsb$!DZK`Ekkt6?JfR>p0>IIqKx!;uJ;8`==@k<~%BQ@WZ
zG4@K12;(5eeB$B0G0~VEUk#D%J4k9;mI#F5H$wI)LG++zSu+j2<JMBN{3Scl*wEL!
zZ|Gg$1?U7OS_J@1*kb6bU&yqzv=QSgs1^&z_8nyVt_;2FH70Ze024Yii@s*)9hYs2
zu70-^UIIQ&H#j8~;=HJ_J9b(!#3Pm+2t+!!%+E{@CCBa^;Xe3{%pe6~L>sm?)V^@a
z3j-O(H)$4A`Xp*8Dck8Vxpwd9X45PHhh?T~Y>oLAYg~Wm&4JnxH*j_JyAGcNz)Vjx
z!=2BT%CBrx;NkwE2>`kPqzx`<;GmE8D_JvMscbmA;{zt_PD|<quvW9E;(o`9JI^Y0
zQcVm1B4*Q<nL?)$TSsN?eH)7~m?PYBBeC{gD2eAce7)m;%I#Aw)QNr>M9lbk06*>~
z4-;QwhP%`g&(f&4CN!XU4R)+rl(2k(l&~^T!tw!P%DmMd^C)5Yf~8ul43x0^K?y4Z
zB`jZ1W2{V+uzWy`u|}eV<qK+zm5CCTKPX{kpoHZE#G2{~Gf=|vg`{e+GEl<u1$9@L
zNySAsl%HK)HG?$=)(+G%0DO8tE!Pf=X8;)2{|N)Y`2O*{<B$pV>%G0)9W?`c#(S|)
z(G7~Cpt?duQBcBC6oo*Kv9_IlVgoeox^nwbBoZ^9eI?6A-e3@DVL{WT0(@b)-6#fR
zZ}1JQumar`GNA4}DwIGAD`Z)|A7-KOhd>L9Df5A|ib^5S!UCzTuu=)Muq@J4S6HD0
zT3E1>s>P~M0xc|cS6I0OT39t|@LsV5T3D7vYK&E(1X@@iHO8t`0==Y@)bL&?{a8fS
zhMh`AU>f!|g+;?pFC)%wXOmXua66EeRwnOzol$SzGC=A1_Pu7}rx9ROJeHy;1iLF#
zR4htZilU%|r6>x49=sQV5TXV^6!y~{rUEz=K%0~@k;Qg7fQHg~h!s-GpO?5!-xzbk
z5<*M`uoOTmfP*tG-<2cVF|Z#uS4zwh*XJu^Mp#0K2>`AGa07t-%j{0oGbV&3gt!pE
zZ2+c~+n2FIRSQc9aRh)z0L(47FJq0W6_ya<7yz39e5KsJj76$)x<Lr>RREizL{&Db
zPFO;SdH_!%%ky{?rK1|V!g~Q6U2Z2FumeCR04vAei21Z2QB}ecLM#UG&2szUkjVh{
z18{|u^3!rV<2TjT6)q{a11`A`z)PtcjjEz*ge8QS3*hg|?S}`B0<ca9F{Rv&_(|0W
z3&1r6=HG!~&q#F5000BP2Ojbs4WLU1F|L66D~hTRmJs600M7T2bpXJ_0Ga?CE~R{~
z05^6^DWg)#sQ_jGXm^?aGyvBYP=7^HEra(f;r_FH3}BIzvfFQGq?B&}xKIeu4&YG$
zA%|I)3LzenQWny3Rs?}>u~OZ~<u0?m4PbULM3s(|@-YD4c9EqX_Ck5!3B0fX90&W>
z-6<cz7S*4N<j*jqln(*uaFOLwAw+Gl{3#XHA}lv7DMMGY1oot-6AlH?Ttr_=!dMg5
z9|8Ppu^h>Tl=4ro*DjrMR<V3371bcD<6YQZC#5Xcem6G{Fh8+qUX+Mx5SG&xYcGI8
zrV|R~2^Y3XSmi_rK>&_*X#Sd%vTP4il2X14;3bFVUkdt6e4vE|J2YlLhqf;k(-DWb
z*)|{ORx9Weq<dW0eqKO5_XAkxgD-BLxpOptqRz7wlb{Q0mkZnJUMrDOKH@cR21ysT
zPG{>Yl0bKbQp!O9yB(TOFQO|>88eTc3$(COI1Q4UUQ8z(GG-2ns|I0x;?V9uA;jTD
z^<;EPy-mMtRD-bGg!O)_XkLth5MmO5Mi*J!jK?aDY7o|6UDygCM7ch541k+JzU{?w
zq!d(xu%2~cJ014vGUea`m-b#FQ7eXO5Y{s;?SEA2Rx1^c-{LZxo0hoZs0LxZ0HEK6
zeHg$UMe=0?LWt=ARsnDmW3?BB#ow2mzza)Cxd*^{m)WirLR?u4f6@^`)WHt&bGz=h
zCN)PFSOPDs6uAye%bQ0Caf$Dqq(~j`)(&rLe*f;XJ0+)Tj^h?W{1<?~^N{s9*iogX
zPkx*LJ8u1AxVsA+Vi$lfNh$mM@TXi<ld!G;APXqsDFD9$@T`>bW0!Rw0Q(HCt5Nt}
z=Q1hfKNVO;*{LRBg<yvspIl&34B*eOr!lsqUMI2dunq<=0rsxz(^7vk;m@#Q2Y{JU
z%8z^~tE^OwumC^^aWZUi1vN6@aw+BVay#J%)iQVo07xlc1n|pp`{9x20Q{!hPWVMt
z2`j}?xSupFH}AsUm0dO6M^$x&LkJ-bhAl3)dk)LNP5^VIl&_cD5kINM77MAt??P1m
z?DgjWV$~)pph|@W08+|#U@zbNrOdA6;%xwPq?B$J(E~%(3JU<Fl>ZIj3{>9ZLpA_t
zkW#)<ZbynmRSOIFqFbB~U>VB))cf54ZU(Th8s@6<QI&)DTnHg%1Go>R-?PWC4|w}$
zDdqbmuDdLZDPaL$JWlRf*z0-4J_~*T_L18^lTyA=<hm+~F(<4cQfE*thJAMF={^_#
z3V`3je&*l~pUVyeV^&z{2qBJ!y@)&qw#e#WuL~yA{wK4f4gLQR_7?t^0K6!r>@D#}
bs5t%~<9Qvx67brY00000NkvXXu0mjfM+)HE

literal 0
HcmV?d00001

diff --git a/doc/meta.mdwn b/doc/meta.mdwn
new file mode 100644
index 0000000000..5ee36f8c0b
--- /dev/null
+++ b/doc/meta.mdwn
@@ -0,0 +1,5 @@
+This wiki contains [[!pagecount pages="*"]] pages.
+
+Broken links:
+
+[[!brokenlinks ]]
diff --git a/doc/metadata.mdwn b/doc/metadata.mdwn
new file mode 100644
index 0000000000..3b61a47d52
--- /dev/null
+++ b/doc/metadata.mdwn
@@ -0,0 +1,49 @@
+git-annex allows you to store arbitrary metadata about the content of files
+stored in the git-annex repository. The metadata is stored in the
+`git-annex` branch, and so is automatically kept in sync with the rest of
+git-annex's state, such as [[location_tracking]] information.
+
+Some of the things you can do with metadata include:
+
+* Using `git annex metadata file` to show all 
+  the metadata associated with a file.
+* [[tips/metadata_driven_views]]
+* Limiting the files git-annex commands act on to those with
+  or without particular metadata.
+  For example `git annex find --metadata tag=foo --or --metadata tag=bar`
+* Using it in [[preferred_content]] expressions. 
+  For example "metadata=tag=important or not metadata=author=me"
+* Editing and viewing it with git-annex-metadata-gui,
+  [[tips/a_gui_for_metadata_operations]].
+
+Each file (actually the underlying key) can have any number of metadata
+fields, which each can have any number of values. For example, to tag
+files, the `tag` field is typically used, with values set to each tag that
+applies to the file.
+
+The field names are limited to alphanumerics (and `[_-.]`), and are case
+insensitive. The metadata values can contain absolutely anything you
+like -- but you're recommended to keep it simple and [[reasonably short|forum/metadata_limits]]
+
+Here are some metadata fields that git-annex has special support for:
+
+* `tag` - With each tag being a different value.
+* `year`, `month` - When this particular version of the file came into
+  being.
+* `$field-lastchanged` - This is automatically maintained for each
+  field that's set, and gives the date and time of the most recent
+  change to the field. It cannot be modified directly.
+* `lastchanged` - This is automatically maintained, giving the data and time
+  of the last change to any of the metadata of a file.
+
+To make git-annex automatically set the year and month when adding files,
+run `git config annex.genmetadata true`. Also, see
+[[tips/automatically_adding_metadata]].
+
+git-annex's metadata can be updated in a distributed fashion. For example,
+two users, each with their own clone of a repository, can set and unset
+metadata at the same time, even for the same field of the same file. 
+When they push their changes, `git annex merge` will combine their
+metadata changes in a consistent and (probably) intuitive way.
+
+See [[the metadata design page|design/metadata]] for more details.
diff --git a/doc/metadata/comment_1_d367fdaf0425b59d694bf16059d47192._comment b/doc/metadata/comment_1_d367fdaf0425b59d694bf16059d47192._comment
new file mode 100644
index 0000000000..8fb93442c7
--- /dev/null
+++ b/doc/metadata/comment_1_d367fdaf0425b59d694bf16059d47192._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="bremner"
+ ip="198.164.160.48"
+ subject="access metadata by key?"
+ date="2014-03-17T01:26:44Z"
+ content="""
+I'm hacking around with using metadata from an external special remote. Those work with keys, not files, so one option would be to add a GETMETADATA to the protocol. It also seems like it would not be too hard to add
+an option  to \"git annex metadata\" to take a key rather than a file.
+"""]]
diff --git a/doc/metadata/comment_2_e15d2b5a405db4ccdb91d6aad4a22983._comment b/doc/metadata/comment_2_e15d2b5a405db4ccdb91d6aad4a22983._comment
new file mode 100644
index 0000000000..1fd5a9fe1f
--- /dev/null
+++ b/doc/metadata/comment_2_e15d2b5a405db4ccdb91d6aad4a22983._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.154"
+ subject="comment 2"
+ date="2014-03-17T19:32:39Z"
+ content="""
+I've made `git annex metadata --key` work.
+
+I'll wait and see what you come up with your special remote and add something to the protocol later if it makes sense.
+"""]]
diff --git a/doc/metadata/comment_3_50b17af1cf75ce88c4aef59dcd971b82._comment b/doc/metadata/comment_3_50b17af1cf75ce88c4aef59dcd971b82._comment
new file mode 100644
index 0000000000..771b6a970a
--- /dev/null
+++ b/doc/metadata/comment_3_50b17af1cf75ce88c4aef59dcd971b82._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="madduck"
+ subject="Overwriting metadata from json"
+ date="2015-04-30T18:42:45Z"
+ content="""
+I see that --json allows me to export metadata in a well-parseable format. I'd really like to be able to pipe this into a file, edit the file and then pipe it back to git-annex, causing the metadata for each file to be rewritten from the JSON input. This would make it trivial to write an external metadata editor (like vidir, vorbistagedit, git annex vicfg even… etc.)
+"""]]
diff --git a/doc/metadata/comment_4_237721c5e8f66f303a1828810573a23d._comment b/doc/metadata/comment_4_237721c5e8f66f303a1828810573a23d._comment
new file mode 100644
index 0000000000..d2c13888e1
--- /dev/null
+++ b/doc/metadata/comment_4_237721c5e8f66f303a1828810573a23d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-05-01T19:38:36Z"
+ content="""
+@madduck, you could file a todo if you want about that.
+
+However, I have my doubts; if the json supposed to include the full set of
+metadata for the file? If so, that seems a potentially expensive interface.
+If not, it would be hard to tell when metadata should be deleted, or when
+multiple values are being set, vs a value being changed. 
+
+The current interface to set metadata deals with these possibilities in a
+compact and sensible way.
+"""]]
diff --git a/doc/metadata/comment_5_fd30444aecfc4792eb4dbfdebc230786._comment b/doc/metadata/comment_5_fd30444aecfc4792eb4dbfdebc230786._comment
new file mode 100644
index 0000000000..195eea278e
--- /dev/null
+++ b/doc/metadata/comment_5_fd30444aecfc4792eb4dbfdebc230786._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="madduck"
+ subject="TODO written"
+ date="2015-05-06T14:24:56Z"
+ content="""
+@joeyh, yes, it would overwrite all metadata. The idea would be to export with --json, manipulate, import…
+
+http://git-annex.branchable.com/todo/ability_to_set_metadata_from_json/?updated
+"""]]
diff --git a/doc/news.mdwn b/doc/news.mdwn
new file mode 100644
index 0000000000..0cb92355d8
--- /dev/null
+++ b/doc/news.mdwn
@@ -0,0 +1,11 @@
+[[!if test="news/*" then="""
+This is where announcements of new releases, features, and other news is
+posted. git-annex users are recommended to subscribe to this page's RSS
+feed. Also, see [[security]] for security announcements.
+
+[[!inline pages="./news/* and !./news/*/* and !*/Discussion" rootpage="news" show="30"]]
+
+"""
+else="""
+(Please see the changelog.)
+"""]]
diff --git a/doc/news/2013_git-annex_user_survey.mdwn b/doc/news/2013_git-annex_user_survey.mdwn
new file mode 100644
index 0000000000..269496e64f
--- /dev/null
+++ b/doc/news/2013_git-annex_user_survey.mdwn
@@ -0,0 +1,5 @@
+Similar to the yearly git user survey, I am doing a
+[2013 git-annex user survey](http://git-annex-survey.branchable.com/polls/2013/).
+
+If you use git-annex,
+please take a few minutes to answer my questions!
diff --git a/doc/news/2015_git-annex_user_survey.mdwn b/doc/news/2015_git-annex_user_survey.mdwn
new file mode 100644
index 0000000000..b1fa713b10
--- /dev/null
+++ b/doc/news/2015_git-annex_user_survey.mdwn
@@ -0,0 +1,5 @@
+Similar to the yearly git user survey, there is a
+[2015 git-annex user survey](http://git-annex-survey.branchable.com/polls/2015/).
+
+If you use git-annex,
+please take a few minutes to answer the questions!
diff --git a/doc/news/2018_git-annex_user_survey.mdwn b/doc/news/2018_git-annex_user_survey.mdwn
new file mode 100644
index 0000000000..732e50ee64
--- /dev/null
+++ b/doc/news/2018_git-annex_user_survey.mdwn
@@ -0,0 +1,7 @@
+Similar to the yearly git user survey, there is a
+[2018 git-annex user survey](http://git-annex-survey.branchable.com/polls/2018/).
+
+If you use git-annex, please take a few minutes to answer the questions!
+
+Since git-annex is seeing increasing use to manage scientific data, the
+survey also includes some extra questions about that at the end.
diff --git a/doc/news/Distribits_meeting.mdwn b/doc/news/Distribits_meeting.mdwn
new file mode 100644
index 0000000000..4aadbf641a
--- /dev/null
+++ b/doc/news/Distribits_meeting.mdwn
@@ -0,0 +1,12 @@
+We are happy to announce that the call for participation for the first ever
+Distribits meeting is now online at <https://distribits.live/>
+
+This meeting is organized by the folks behind git-annex and DataLad. We aim
+to bring together enthusiasts of tools and workflows in the domain of
+distributed data.
+
+We are looking forward to April 2024 and to meeting people from everywhere,
+online and in Düsseldorf.
+
+Registration is open now and until October 15. Please consider submitting a
+talk if you are doing something interesting or unusual with git-annex.
diff --git a/doc/news/Distribits_meeting/comment_1_774494da38afecc425aceca21d047b5e._comment b/doc/news/Distribits_meeting/comment_1_774494da38afecc425aceca21d047b5e._comment
new file mode 100644
index 0000000000..c4d5d9fb19
--- /dev/null
+++ b/doc/news/Distribits_meeting/comment_1_774494da38afecc425aceca21d047b5e._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-09-14T16:37:12Z"
+ content="""
+I plan to attend, and hope to give a talk or two. ;-)
+"""]]
diff --git a/doc/news/Distribits_meeting/comment_2_bbdde32c4bd9c7a1a62450d59a1e879b._comment b/doc/news/Distribits_meeting/comment_2_bbdde32c4bd9c7a1a62450d59a1e879b._comment
new file mode 100644
index 0000000000..de9bc07404
--- /dev/null
+++ b/doc/news/Distribits_meeting/comment_2_bbdde32c4bd9c7a1a62450d59a1e879b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2023-09-14T19:46:14Z"
+ content="""
+The world definitely needs more git-annex related talks/videos! I also plan to attend and will try to give a talk or two myself.
+"""]]
diff --git a/doc/news/LWN_article.mdwn b/doc/news/LWN_article.mdwn
new file mode 100644
index 0000000000..c1c0c40472
--- /dev/null
+++ b/doc/news/LWN_article.mdwn
@@ -0,0 +1,2 @@
+[Linux Weekly News](http://lwn.net/) has a nice
+[article on git-annex](http://lwn.net/Articles/418337/) in it this week.
diff --git a/doc/news/Presentation_at_FOSDEM.mdwn b/doc/news/Presentation_at_FOSDEM.mdwn
new file mode 100644
index 0000000000..48daf2678d
--- /dev/null
+++ b/doc/news/Presentation_at_FOSDEM.mdwn
@@ -0,0 +1,4 @@
+git-annex will be briefly presented at FOSDEM, on Sunday February 4th at 15:40.
+[Details](http://fosdem.org/2012/schedule/event/gitannex).
+
+Thanks to Richard Hartmann for making this presentation.
diff --git a/doc/news/git-annex_shirts_now_available_at_hellotux.com.mdwn b/doc/news/git-annex_shirts_now_available_at_hellotux.com.mdwn
new file mode 100644
index 0000000000..6a514935f6
--- /dev/null
+++ b/doc/news/git-annex_shirts_now_available_at_hellotux.com.mdwn
@@ -0,0 +1,3 @@
+Since 24.03.2024, [hellotux.com](https://www.hellotux.com/git-annex) now offers git-annex-branded shirts, hoodies and backpacks. Just in time, right before the [distribits](https://distribits.live/) meeting.
+
+This cooperation was initiated by [Yann Büchau (nobodyinperson)](https://git-annex.branchable.com/users/nobodyinperson/).
diff --git a/doc/news/git_annex_fall_of_code.mdwn b/doc/news/git_annex_fall_of_code.mdwn
new file mode 100644
index 0000000000..79e0ff6900
--- /dev/null
+++ b/doc/news/git_annex_fall_of_code.mdwn
@@ -0,0 +1,27 @@
+Thanks to my recent successful git-annex
+[crowdfunding campaign](http://campaign.joeyh.name/), $1000 has been set
+aside to award others for their contributions to git-annex by
+the end of 2013. This is not a lot of money, but I hope that the
+reward and recognition will encourage some more people to work on git-annex.
+
+You don't need to know Haskell! You could contribute some interesting and
+useful special remote hooks, or write better documentation.
+
+On the other hand, if you have learned Haskell, this might be your first
+chance to make some money with it! Some ideas for things to work on that
+would be particularly award-worthy:
+
+* Port git-annex to IOS, using [ghc-ios](https://github.com/ghc-ios).
+  I don't plan to ever do this myself, but you could make it happen.
+* Get the git-annex assistant working in Windows, building on the existing
+  port to Windows. Otherwise, this is on my roadmap for February.
+* Solve existing [[bugs]] or [[todo]] items. There are more than I can
+  keep up with.
+
+The amount of the awards will vary depending on the size of the
+contribution. Since this is getting started later than is ideal,
+I reserve the right to extend it past the end of the year if I don't get
+enough participants.
+
+If you'd like to participate in this program, just email me at
+<id@joeyh.name>. --[[Joey]]
diff --git a/doc/news/security_fix_release.mdwn b/doc/news/security_fix_release.mdwn
new file mode 100644
index 0000000000..63ce148539
--- /dev/null
+++ b/doc/news/security_fix_release.mdwn
@@ -0,0 +1,32 @@
+git-annex 6.20180626 is an important security fix release.
+
+See [[the advisory|security/CVE-2018-10857_and_CVE-2018-10859]]
+for details about the security holes fixed in this release.
+
+After upgrading git-annex, you should restart any git-annex assistant
+processes.
+
+Several changes to git-annex's behavior had to be made as part of the
+security fixes:
+
+* A security fix has changed git-annex to refuse to download content from
+  some special remotes when the content cannot be verified with a hash check.
+  In particular URL and WORM keys stored on such remotes won't be downloaded.
+  See the documentation of the annex.security.allow-unverified-downloads
+  configuration for how to deal with this if it affects your files.
+
+* A security fix has changed git-annex to only support http, https, and ftp
+  URL schemes by default. You can enable other URL schemes, at your own risk,
+  using annex.security.allowed-url-schemes.
+
+* A related security fix prevents git-annex from connecting to http
+  servers (and proxies) on localhost or private networks. This can
+  be overridden, at your own risk, using annex.security.allowed-ip-addresses.
+
+* Setting annex.web-options no longer is enough to make curl be used,
+  and youtube-dl is also no longer used by default. See the
+  documentation of annex.security.allowed-http-addresses for
+  details and how to enable them.
+
+* The annex.web-download-command configuration has been removed,
+  use annex.web-options instead.
diff --git a/doc/news/sharebox_a_FUSE_filesystem_for_git-annex.mdwn b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex.mdwn
new file mode 100644
index 0000000000..8eab9a34ac
--- /dev/null
+++ b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex.mdwn
@@ -0,0 +1,19 @@
+[[!meta title="sharebox: a FUSE filesystem for git-annex"]]
+
+Christophe-Marie Duquesne has just announced 
+[Sharebox](https://github.com/chmduquesne/sharebox-fs), a FUSE filesystem
+relying on git-annex:
+
+<blockquote>
+<pre>
+What are your goals?  
+Seamless synchronization "à la dropbox".  
+Ability to use with big binary files such as mp3/movies.  
+Entirely decentralized.  
+Don't use unnecessary space  
+Keep it simple: avoid special VCS commands and keep a filesystem  
+interface as much as possible.
+</pre>
+</blockquote>
+
+While still alpha, this is promising. --[[Joey]]
diff --git a/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_1_e238d1734238e37bb55ff952b32e06b8._comment b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_1_e238d1734238e37bb55ff952b32e06b8._comment
new file mode 100644
index 0000000000..8754a7f9a6
--- /dev/null
+++ b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_1_e238d1734238e37bb55ff952b32e06b8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlatTbI0K-qydpeYHl37iseqPNvERcdIMk"
+ nickname="Tiago"
+ subject="comment 1"
+ date="2012-09-27T00:08:19Z"
+ content="""
+This is what the assistant should aim to be...\"Like Dropbox\", but even better.
+I would guess many people who pledged were thinking of this.
+"""]]
diff --git a/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_2_341b567722797eb02bd96ffada431b0c._comment b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_2_341b567722797eb02bd96ffada431b0c._comment
new file mode 100644
index 0000000000..e155225e1e
--- /dev/null
+++ b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_2_341b567722797eb02bd96ffada431b0c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="I wondered if there is any even simple fuse wrapper for git-annex?"
+ date="2014-12-16T16:34:06Z"
+ content="""
+sharebox seems aiming to achieve what assistant is aiming for (synchronization).  In my usecase I wondered if there is a simple(r) FUSE wrapper for git-annex which would just 'annex get' any file which is requested (for reading).
+"""]]
diff --git a/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_3_d6f6e7181f30094339a49ab420bee380._comment b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_3_d6f6e7181f30094339a49ab420bee380._comment
new file mode 100644
index 0000000000..f32de2fbae
--- /dev/null
+++ b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_3_d6f6e7181f30094339a49ab420bee380._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 3"
+ date="2014-12-16T16:56:05Z"
+ content="""
+@Yaroslav: I made one of these while I was messing with FUSE but found I didn't use it much.
+
+If I can find it, I'll post it somewhere or if you really want it, I can just write a (much) better one!
+"""]]
diff --git a/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_4_ab0d45c5058595a71656035c962c1143._comment b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_4_ab0d45c5058595a71656035c962c1143._comment
new file mode 100644
index 0000000000..a527f9b02a
--- /dev/null
+++ b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_4_ab0d45c5058595a71656035c962c1143._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="comment 4"
+ date="2014-12-16T20:42:28Z"
+ content="""
+what could I say to a \"much better one\" offer, besides \"GO AHEAD\" and \"Thank you in advance\"! :)
+
+I wonder though what joey thinks about possible utility of a basic fuse wrapper for annex, and possibly shipping it along?
+
+My primary use-case would be primarily oriented for testing, e.g. if I would like to run a (sub)collection of tests (e.g. on travis) which rely on having some data from annex available, now I would need either provide some project/language specific wrapping which would check if file is available or not and then fetch it.  With FUSE I thought I could just do that transparently without requiring any per-project coding/setup.  Similar use-case would be analysis of some large datasets, once again, without requiring pre-fetching them in entirety and/or piece-by-piece fetching.
+Another possible additional usecase/mode could also be -- expose only available files under FUSE.  If easy to \"trigger\" it would help to provide that \"lean\" view I was blurbing about (https://github.com/datalad/datalad/issues/25) although it would be quite a suboptimal workaround (since if directory is heavily loaded with broken links, it would take a while for FUSE handler to first traverse the tree anyways)
+"""]]
diff --git a/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_5_b92045c91d92da7db794aed2c67dde0d._comment b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_5_b92045c91d92da7db794aed2c67dde0d._comment
new file mode 100644
index 0000000000..de3a2a8b10
--- /dev/null
+++ b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_5_b92045c91d92da7db794aed2c67dde0d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 5"
+ date="2014-12-18T09:26:17Z"
+ content="""
+Having the lean view would be easy to implement either as an option you pass when mounting or something you can toggle by touching a file ($MNT/.config/lean/{on,off}).
+
+Regarding fetching of files, how would you like it to behave? My previous one would return EBUSY while downloading a file and ENODATA if it wasn't available and couldn't be fetched. I could, for example, make unavailable files appear as normal files (containing text regarding the download state) until they are available, then they become symlinks. What would work best for you?
+"""]]
diff --git a/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_6_6f3b5d5a5781b3a570f46481dc2ebca2._comment b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_6_6f3b5d5a5781b3a570f46481dc2ebca2._comment
new file mode 100644
index 0000000000..f505b347db
--- /dev/null
+++ b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_6_6f3b5d5a5781b3a570f46481dc2ebca2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="unavailable files"
+ date="2014-12-18T16:37:13Z"
+ content="""
+for my use cases the best would be if FUSE simply didn't return until file becomes available. Making an option to return immediately with EBUSY/ENODATA could also be generally useful but not in my case :-/
+I wonder if any timeout would kick in in some use-cases if it takes too long?
+"""]]
diff --git a/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_7_6202ae898f24b3e02bc343d0fd2ac35a._comment b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_7_6202ae898f24b3e02bc343d0fd2ac35a._comment
new file mode 100644
index 0000000000..127fe773c6
--- /dev/null
+++ b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_7_6202ae898f24b3e02bc343d0fd2ac35a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 7"
+ date="2014-12-19T08:40:06Z"
+ content="""
+Okie dokie, I'll see what I can do.
+
+Can you give me an idea of the annex file properties (file size, count, files per directory, directory count) etc. please?
+"""]]
diff --git a/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_8_884a0b9571544a95fad55cb5fc5963d8._comment b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_8_884a0b9571544a95fad55cb5fc5963d8._comment
new file mode 100644
index 0000000000..3032f162d4
--- /dev/null
+++ b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_8_884a0b9571544a95fad55cb5fc5963d8._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="typical repos"
+ date="2014-12-19T14:05:22Z"
+ content="""
+Thanks for doing it and asking for detail!!!
+Repositories will vary quite a bit.  I am currently testing how big we could actually make them (see https://github.com/datalad/datalad/issues/17) ;)
+
+Meanwhile here are sample few available for git clone/testing:
+
+https://github.com/datalad/nih--videocast   a good collection of heavyish video files
+http://psydata.ovgu.de/forrest_gump/.git/   a good single dataset with probably a somewhat typical amount of data
+http://data.pymvpa.org/datasets/haxby2001/.git/  relatively small dataset with typical data sizes
+"""]]
diff --git a/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_9_32b5d0fb9c328fbcd8105dfa31f032d3._comment b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_9_32b5d0fb9c328fbcd8105dfa31f032d3._comment
new file mode 100644
index 0000000000..a0239f3428
--- /dev/null
+++ b/doc/news/sharebox_a_FUSE_filesystem_for_git-annex/comment_9_32b5d0fb9c328fbcd8105dfa31f032d3._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2015-01-05T20:38:40Z"
+ content="""
+My concern about using FUSE has always been that I don't much like it
+when open() hangs indefinitely, with no progress indication, and 
+is either downloading some large file from the network or .. just hung.
+
+That doesn't strike me as a nice user interface in general,
+which is why I avoided using FUSE for the assistant.
+
+It might make sense in the batch use cases Yaroslav gave. If something
+nice is developed, I would not be against including it in git-annex.
+(Bonus if it's implemented in haskell.)
+"""]]
diff --git a/doc/news/version_10.20230926.mdwn b/doc/news/version_10.20230926.mdwn
new file mode 100644
index 0000000000..44a24c356d
--- /dev/null
+++ b/doc/news/version_10.20230926.mdwn
@@ -0,0 +1,17 @@
+git-annex 10.20230926 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Fix more breakage caused by git's fix for CVE-2022-24765, this time
+    involving a remote (either local or ssh) that is a repository not owned
+    by the current user.
+  * Fix using git remotes that are bare when git is configured with
+    safe.bareRepository = explicit.
+  * Fix linker optimisation in linux standalone tarballs.
+  * adb: Avoid some problems with unusual characters in exporttree
+    filenames that confuse adb shell commands.
+  * push: When on an adjusted branch, propagate changes to parent branch
+    before updating export remotes.
+  * lookupkey: Added --ref option.
+  * enableremote: Avoid overwriting existing git remote when passed the uuid
+    of a specialremote that was earlier initialized with the same name.
+  * Support being built with crypton rather than the no-longer maintained
+    cryptonite.
+  * Removed the vendored git-lfs and the GitLfs build flag."""]]
\ No newline at end of file
diff --git a/doc/news/version_10.20230926/comment_1_6edf64272975935ac4874d7e8dd44390._comment b/doc/news/version_10.20230926/comment_1_6edf64272975935ac4874d7e8dd44390._comment
new file mode 100644
index 0000000000..1017b4ea4c
--- /dev/null
+++ b/doc/news/version_10.20230926/comment_1_6edf64272975935ac4874d7e8dd44390._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="Linux 64bit failing?"
+ date="2023-10-04T14:39:48Z"
+ content="""
+FYI Joey: seems like the x86_64 build failed? In any case the \"current\" Linux x86_64 standalone tarball points to the last release from the end of August.
+"""]]
diff --git a/doc/news/version_10.20230926/comment_2_b1bb446c48a4abc4df73354980f9f7cf._comment b/doc/news/version_10.20230926/comment_2_b1bb446c48a4abc4df73354980f9f7cf._comment
new file mode 100644
index 0000000000..aa0b3ce0b8
--- /dev/null
+++ b/doc/news/version_10.20230926/comment_2_b1bb446c48a4abc4df73354980f9f7cf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-10-09T18:27:34Z"
+ content="""
+Publishing the new version had not happened due to a problem. I've fixed
+that now.
+"""]]
diff --git a/doc/news/version_10.20231129.mdwn b/doc/news/version_10.20231129.mdwn
new file mode 100644
index 0000000000..103697888d
--- /dev/null
+++ b/doc/news/version_10.20231129.mdwn
@@ -0,0 +1,22 @@
+git-annex 10.20231129 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Fix bug in git-annex copy --from --to that skipped files that were
+    locally present.
+  * Make git-annex copy --from --to --fast actually fast.
+  * Fix crash of enableremote when the special remote has embedcreds=yes.
+  * Ignore directories and other unusual files in .git/annex/journal/
+  * info: Added calculation of combined annex size of all repositories.
+  * log: Added options --sizesof, --sizes and --totalsizes that
+    display how the size of repositories changed over time.
+  * log: Added options --interval, --bytes, --received, and --gnuplot
+    to tune the output of the above added options.
+  * findkeys: Support --largerthan and --smallerthan.
+  * importfeed: Use caching database to avoid needing to list urls
+    on every run, and avoid using too much memory.
+  * Improve memory use of --all when using annex.private.
+  * lookupkey: Sped up --batch.
+  * Windows: Consistently avoid ending standard output lines with CR.
+    This matches the behavior of git on Windows.
+  * Windows: Fix CRLF handling in some log files.
+  * Windows: When git-annex init is installing hook scripts, it will
+    avoid ending lines with CR for portability. Existing hook scripts
+    that do have CR line endings will not be changed."""]]
\ No newline at end of file
diff --git a/doc/news/version_10.20231227.mdwn b/doc/news/version_10.20231227.mdwn
new file mode 100644
index 0000000000..580da5cbfb
--- /dev/null
+++ b/doc/news/version_10.20231227.mdwn
@@ -0,0 +1,28 @@
+git-annex 10.20231227 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * migrate: Support distributed migrations by recording each migration,
+    and adding a --update option that updates the local repository
+    incrementally, hard linking annex objects to their new keys.
+  * pull, sync: When operating on content, automatically handle
+    distributed migrations.
+  * Added annex.syncmigrations config that can be set to false to prevent
+    pull and sync from migrating object content.
+  * migrate: Added --apply option that (re)applies all recorded
+    distributed migrations to the objects in repository.
+  * migrate: Support adding size to URL keys that were added with
+    --relaxed, by running eg: git-annex migrate --backend=URL foo
+  * When importing from a special remote, support preferred content
+    expressions that use terms that match on keys (eg "present", "copies=1").
+    Such terms are ignored when importing, since the key is not known yet.
+    Before, such expressions caused the import to fail.
+  * Support git-annex copy/move --from-anywhere --to remote.
+  * Make git-annex get/copy/move --from foo override configuration of
+    remote.foo.annex-ignore, as documented.
+  * Lower precision of timestamps in git-annex branch, which can reduce the
+    size of the branch by up to 8%.
+  * sync: Fix locking problems during merge when annex.pidlock is set.
+  * Avoid a problem with temp file names ending in "." on certian
+    filesystems that have problems with such filenames.
+  * sync, push: Avoid trying to send individual files to special remotes
+    configured with importtree=yes exporttree=no, which would always fail.
+  * Fix a crash opening sqlite databases when run in a non-unicode locale.
+    (Needs persistent-sqlite 2.13.3.)"""]]
\ No newline at end of file
diff --git a/doc/news/version_10.20240129.mdwn b/doc/news/version_10.20240129.mdwn
new file mode 100644
index 0000000000..87f8fd0985
--- /dev/null
+++ b/doc/news/version_10.20240129.mdwn
@@ -0,0 +1,24 @@
+git-annex 10.20240129 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * info: Added "annex sizes of repositories" table to the overall display.
+  * import: Sped up import from special remotes.
+  * import: Added --message/-m option.
+  * Support using commands that implement the Stateless OpenPGP command line
+    interface, as an alternative to gpg.
+    Currently only supported for encryption=shared special remotes,
+    when annex.shared-sop-command is configured.
+  * test: Test a specified Stateless OpenPGP command when
+    run with eg --test-git-config annex.shared-sop-command=sqop
+  * Improve disk free space checking when transferring unsized keys to
+    local git remotes.
+  * Added configs annex.stalldetection-download, annex.stalldetection-upload,
+    annex.bwlimit-download, annex.bwlimit-upload,
+    and similar per-remote configs.
+  * Improve annex.stalldetection to handle remotes that update progress
+    less frequently than the configured time period.
+  * external: Monitor file size when getting content from external
+    special remotes and use that to update the progress meter,
+    in case the external special remote program does not report progress.
+  * Added --expected-present file matching option.
+  * webapp: Added --port option, and annex.port config.
+  * assistant: When generating a gpg secret key, avoid hardcoding the
+    key algorithm and size."""]]
\ No newline at end of file
diff --git a/doc/news/version_10.20240227.mdwn b/doc/news/version_10.20240227.mdwn
new file mode 100644
index 0000000000..dfb95d996d
--- /dev/null
+++ b/doc/news/version_10.20240227.mdwn
@@ -0,0 +1,16 @@
+git-annex 10.20240227 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * importfeed: Added --scrape option, which uses yt-dlp to screen scrape
+    the equivilant of an RSS feed.
+  * importfeed --force: Don't treat it as a failure when an already
+    downloaded file exists. (Fixes a behavior change introduced in
+    10.20230626.)
+  * importfeed --force: Avoid creating duplicates of existing
+    already downloaded files when yt-dlp or a special remote was used.
+  * addurl, importfeed: Added --raw-except option.
+  * stack.yaml: Update to lts-22.9 and use crypton.
+  * assistant, undo: When committing, let the usual git commit
+    hooks run.
+  * Added annex.commitmessage-command config.
+  * pre-commit: Avoid committing the git-annex branch
+    (except when a commit is made in a view, which changes metadata).
+  * Pass --no-warnings to yt-dlp."""]]
\ No newline at end of file
diff --git a/doc/not.mdwn b/doc/not.mdwn
new file mode 100644
index 0000000000..c2053e4bed
--- /dev/null
+++ b/doc/not.mdwn
@@ -0,0 +1,70 @@
+[[!meta title="what git-annex is not"]]
+
+* git-annex is not a backup system. It may be a useful component of an
+  [[archival|use_case/bob]] system, or a way to deliver files to a backup
+  system. For a backup system that uses git and that git-annex supports
+  storing data in, see [[special_remotes/bup]].
+
+* git-annex is not a filesystem or Dropbox clone. However, the git-annex
+  [[assistant]] is addressing some of the same needs in its own unique ways.
+  (There is also a FUSE filesystem built on top of git-annex, called 
+  [ShareBox](https://github.com/chmduquesne/sharebox-fs).)
+
+* git-annex is not unison, but if you're finding unison's checksumming
+  too slow, or its strict mirroring of everything to both places too
+  limiting, then git-annex could be a useful alternative.
+
+* git-annex is also not a folder mirroring system like [syncthing](https://syncthing.net/) 
+  (although [[syncthing could be supported as a special remote|todo/syncthing_special_remote/]])
+  or [gut](https://github.com/tillberg/gut), but it can be used to sync
+  files such a way, with certain limitations (for example, it doesn't
+  like syncing `.git` directories so much).
+
+* git-annex is also not a distributed file system like Bittorrent or [ipfs](http://ipfs.io)
+  but both are supported as special remotes with more work in making 
+  [[git-annex more distributed underway|todo/Bittorrent-like_features/]].
+  
+* git-annex is more than just a workaround for git scalability 
+  limitations that might eventually be fixed by efforts like
+  [git-bigfiles](http://caca.zoy.org/wiki/git-bigfiles). In particular,
+  git-annex's [[location_tracking]] allows having many repositories
+  with a partial set of files, that are copied around as desired.
+
+* git-annex is not some flaky script that was quickly thrown together.
+  I wrote it in Haskell because I wanted it to be solid and to compile
+  down to a binary. And it has a fairly extensive test suite. (Don't be
+  fooled by "make test" only showing a few dozen test cases; each test
+  involves checking dozens to hundreds of assertions.)
+
+* git-annex is not [git-media](https://github.com/schacon/git-media),
+  although they both approach the same problem from a similar direction.
+  I only learned of git-media after writing git-annex, but I probably
+  would have still written git-annex instead of using it. 
+  git-media uses git smudge filters (recently supported in git-annex as
+  well; see [[tips/unlocked_files]]) and may be a tighter fit for certain
+  situations. It lacks git-annex's support for widely distributed storage,
+  using only a single backend data store. It also does not support
+  partial checkouts of file contents, like git-annex does.
+
+* git-annex is similarly not [git-fat](https://github.com/jedbrown/git-fat),
+  which also uses git smudge filters, and also lacks git-annex's widely
+  distributed storage and partial checkouts.
+
+* Similarly, git-annex is not [git-lfs](https://github.com/github/git-lfs),
+  which also uses git smudge filters, and appears to lack git-annex's
+  widely distributed storage and partial checkouts.
+
+* git-annex is also not [boar](https://bitbucket.org/mats_ekberg/boar),
+  although it shares many of its goals and characteristics. Boar implements
+  its own version control system, rather than simply embracing and
+  extending git. And while boar supports distributed clones of a repository,
+  it does not support keeping different files in different clones of the
+  same repository, which git-annex does, and is an important feature for
+  large-scale archiving.
+
+* git-annex is not the [Mercurial largefiles extension](http://mercurial.selenic.com/wiki/LargefilesExtension).
+  Although mercurial and git have some of the same problems around large
+  files, and both try to solve them in similar ways (standin files using
+  mostly hashes of the real content).
+
+See also the [[related_software]] page for software that git-annex *is* similar to.
diff --git a/doc/not/comment_10_d8fb9add7e98dadea2a39f8827f75447._comment b/doc/not/comment_10_d8fb9add7e98dadea2a39f8827f75447._comment
new file mode 100644
index 0000000000..ad7b699f9f
--- /dev/null
+++ b/doc/not/comment_10_d8fb9add7e98dadea2a39f8827f75447._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 10"
+ date="2013-12-11T15:40:35Z"
+ content="""
+@Zellyn, what you describe does not sound unreasonable. But it's hard to say if it's a backup. For example, if you delete a file from the archive folder, and that happened to be the only copy of the file, it's gone.
+
+It's definitely possible to use git-annex in backup-like ways, but what I want to discourage is users thinking that just putting files into git-annex means that they have a backup. Proper backups need to be designed, and tested. It helps to use software that is explicitly designed as a backup solution. git-annex is more about file distribution, and some archiving, than backups.
+"""]]
diff --git a/doc/not/comment_11_6c23aba5a9c341f2d5e2007e4b43f2ea._comment b/doc/not/comment_11_6c23aba5a9c341f2d5e2007e4b43f2ea._comment
new file mode 100644
index 0000000000..50c7e0da1c
--- /dev/null
+++ b/doc/not/comment_11_6c23aba5a9c341f2d5e2007e4b43f2ea._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQafKy7hNSEolLs6TvbgUnkklTctUY9LI"
+ nickname="Zellyn"
+ subject="Backup"
+ date="2013-12-11T17:38:39Z"
+ content="""
+@joeyh - ok, good to know. So as long as I realize I need to sync with my hard drives before deleting, it should work fine as a backup solution. Sweet!
+"""]]
diff --git a/doc/not/comment_12_a0ef1a045257659f0f8722e4987e0ccc._comment b/doc/not/comment_12_a0ef1a045257659f0f8722e4987e0ccc._comment
new file mode 100644
index 0000000000..3f9aa2087e
--- /dev/null
+++ b/doc/not/comment_12_a0ef1a045257659f0f8722e4987e0ccc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkRtPz8CAz_1sBR0Rf-b8OlQQ49v9JxOIE"
+ nickname="John"
+ subject="re: Not an backup"
+ date="2014-02-05T10:45:45Z"
+ content="""
+@joeyh.name But if I set numcopies=2 it won't let me drop the file right? I don't think we are mean to directly modify the archive; but if we do would git-annex detect the corruption and discourage us from dropping the other file?
+"""]]
diff --git a/doc/not/comment_13_c5c20576388f18daba3af913b44fb001._comment b/doc/not/comment_13_c5c20576388f18daba3af913b44fb001._comment
new file mode 100644
index 0000000000..38c96f7073
--- /dev/null
+++ b/doc/not/comment_13_c5c20576388f18daba3af913b44fb001._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="206.74.132.139"
+ subject="comment 13"
+ date="2014-02-06T17:00:59Z"
+ content="""
+Yes, git-annex ensures your configured [[numcopies|copies]] is met before dropping a file.
+"""]]
diff --git a/doc/not/comment_14_837e3699014b73e8f2bd2a668eea9eef._comment b/doc/not/comment_14_837e3699014b73e8f2bd2a668eea9eef._comment
new file mode 100644
index 0000000000..01eb17b865
--- /dev/null
+++ b/doc/not/comment_14_837e3699014b73e8f2bd2a668eea9eef._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmhufs6QGCQXnUEc6qrCcQIZTomUDKNeAQ"
+ nickname="Jeff"
+ subject="Git annex in a strange direct with .git/annex/objects mode"
+ date="2014-04-21T21:03:24Z"
+ content="""
+I'm doing something perhaps unreasonable and weird, and I'm wondering if there's a better way.
+
+I'm running a wget -mbc of a particular web site.  It replicates down to a tree.
+Then I'm ingesting the content into git annex via the normal 'git annex add' sequence.
+
+Later, when I'm going to update my replica of the website, I am running a 'git annex unlock' on the whole tree (90 gig in this case), and then running the 'wget -mbc ; git annex add' command sequence again.
+
+Is there any mechanism to convince git-annex to scan the file, and ingest (copy) it into objects if it is new content, while leaving the original files unlocked?   This would give me the ability to avoid the 'git annex unlock' copy operation, which is lengthy.
+
+I'm aware this is inherently space inefficient.
+
+I'm sure there's some other problem with this idea that I'm missing.
+
+Thanks.
+
+
+"""]]
diff --git a/doc/not/comment_15_ac7396ca125abb80a42f9aaaf61a6ab4._comment b/doc/not/comment_15_ac7396ca125abb80a42f9aaaf61a6ab4._comment
new file mode 100644
index 0000000000..369acad22c
--- /dev/null
+++ b/doc/not/comment_15_ac7396ca125abb80a42f9aaaf61a6ab4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 15"
+ date="2014-05-16T18:59:47Z"
+ content="""
+@Jeff, why did you post that comment here? Please use the [[forum]] for questions.
+
+(You may find it useful to use direct mode, or `git annex import --skip-duplicates` or something.)
+"""]]
diff --git a/doc/not/comment_16_d2ae9613ad81508dbda6ed425d441ccb._comment b/doc/not/comment_16_d2ae9613ad81508dbda6ed425d441ccb._comment
new file mode 100644
index 0000000000..1955a945b1
--- /dev/null
+++ b/doc/not/comment_16_d2ae9613ad81508dbda6ed425d441ccb._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="shodanshok@8c8405b6944c211be7dec8ae8fccde70adc19027"
+ nickname="shodanshok"
+ avatar="http://cdn.libravatar.org/avatar/8b4dd6a9f2396b788ca18f3690609ad3"
+ subject="Can git-annex be used to quasi-realtime replication?"
+ date="2017-01-16T17:41:07Z"
+ content="""
+Suppose I have two Samba fileservers in two different locations. Can I use git-annex in thin mode + git-annex assistant to automatically synchronize these two fileserver? Specifically, I am trying to understand if:
+
+1) git-annex preserve owner/group ID and POSIX ACLs;
+2) it can efficiently manage very large number of file/directory (500K+ files)
+3) it can be used alongside inotify to efficiently transfer only changed files
+
+One last thing: I which sense git-annex is not like Unison? It seems it can be configured to have very similar functionality. I am missing something?
+
+Thank you all.
+"""]]
diff --git a/doc/not/comment_1_ab41bec1ccc884e71780cb9458439170._comment b/doc/not/comment_1_ab41bec1ccc884e71780cb9458439170._comment
new file mode 100644
index 0000000000..6a7eed33b0
--- /dev/null
+++ b/doc/not/comment_1_ab41bec1ccc884e71780cb9458439170._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://bergey.dreamwidth.org/"
+ ip="66.80.90.109"
+ subject="git-media"
+ date="2012-07-14T15:42:05Z"
+ content="""
+I haven't used git-media, but from the README it looks as though they now support several backends.  Might want to update the (very helpful!) comparison.
+"""]]
diff --git a/doc/not/comment_2_0e19ff7deb5ed65f2bc685d4c516d816._comment b/doc/not/comment_2_0e19ff7deb5ed65f2bc685d4c516d816._comment
new file mode 100644
index 0000000000..926df6bc19
--- /dev/null
+++ b/doc/not/comment_2_0e19ff7deb5ed65f2bc685d4c516d816._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkurjhi0CRJvgm7QNaZDWS9hitBtavqIpc"
+ nickname="Bret"
+ subject="Sparkleshare"
+ date="2012-09-06T08:09:17Z"
+ content="""
+How does [sparkleshare](http://sparkleshare.org/) and git-annex (and git-annex assistant) compare? 
+"""]]
diff --git a/doc/not/comment_3_bab9584c41a25dda934ad230e3eb732d._comment b/doc/not/comment_3_bab9584c41a25dda934ad230e3eb732d._comment
new file mode 100644
index 0000000000..eb66e0b3d4
--- /dev/null
+++ b/doc/not/comment_3_bab9584c41a25dda934ad230e3eb732d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.236"
+ subject="comment 3"
+ date="2012-09-06T14:50:43Z"
+ content="""
+My understanding of sparkleshare (I've not used it) is that it uses a regular git repository, so has git's problems with large files and will not support partial checkouts. However, you might want to try it out and see if it works for you.
+"""]]
diff --git a/doc/not/comment_4_b2a0d5a45ab8ddd66c29dde9412d7a12._comment b/doc/not/comment_4_b2a0d5a45ab8ddd66c29dde9412d7a12._comment
new file mode 100644
index 0000000000..10baf5f45d
--- /dev/null
+++ b/doc/not/comment_4_b2a0d5a45ab8ddd66c29dde9412d7a12._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn4bbuawnh-nSo9pAh8irYAcV4MQCcfdHo"
+ nickname="Stefan"
+ subject="Sparkleshare"
+ date="2012-09-15T01:28:05Z"
+ content="""
+Hi,
+
+I used sparkleshare lately in a project involving 3 computers and 2 people. and for ascii texts and even a few smaller binary things it works ok.
+
+But it does \"to much\" for media. at least at the moment, it just uses git for saving the data. That has a possitive and a negative aspect.
+
+possitive:
+
+1. you have a full history, if you delete a file its not gone for ever, so if you change it, the older version is still recoverable.
+2. if you would as example use it from a laptop in a train without internet and you use a git server in the internet for the central server, and would change some files, then you or somebody else would write on the same txt file as example (html or something... latex...) you would be able to merge this files.
+3. its not totaly bad for backup, because you can restore old files even if you delete it localy, because it will hold all history
+
+
+negative:
+
+1. for bigger data its cracy. if you use it for movies as example, you would in git annex delete some stuff you want not to see anytime again, so you would delete it everywhere. and its really away, not beeing still there in the history
+2. git as it is has issues with saving/transfairing very big files, and its slow on even mid-sized files lets say 100 5mb big files it would be slow. because at the moment sparkleshare uses git all this disatvantages are there.
+3. as many clients you use lets say a projekt with 10 people, each of them have all files and all the history of this projekt/directory on their pc.
+4. you need a central data-store git folder you can use a seperate pc for that or save it on a client, if you use a client for that you have to save the data double on this pc.
+
+(so you see for big files even if git would handle them faster you would waste massivly hard disk space) but again for pdfs a few pictures text files even some office files and stuff <100mb its great and easy to do.
+
+
+I try it in a few words, sparkleshare is like dropbox but with file history ( I think dropbox dont have that???) but because git is not designed (yet) for big files it works somewhat ok for < 100mb stuff if you go very much higher > 1GB it will not be optimal.
+
+git annex dont saves the data itself in git but only the locations and the checksums. so its more like a adress book of your data. its a abstraction layer to your data, you can see on as many devises as you want even without no netzwerk internet connection active and only a very small hd see all your 5 Terrabyte of Data you might have, and move around directories sort around them... delete stuff you dont want if you can deside that by the name... and then  when you come back to the connection you sync your actions and it does it to the files.
+
+And one big feature like joey said is that you cannot partialy load files from the repos to your device if it has as example only enough space for 1/10 of it.
+
+There is another thing, but because it is \"only\" a abstraction layer, it is theoreticaly easy to implement extentions to save your data on anything not only git repositories...
+
+Sparkleshare will switch to something else than git, maybe but then it will switch to this single protocol and stick to that. because it does not abstract stuff so hard.
+
+btw there is a alternative out there it forces you not to use git as vcs but you have to use a vcs (like git) and you dont have to use the client written in mono but only a smaller python script:
+
+http://www.mayrhofer.eu.org/dvcs-autosync
+
+but the idea behind it is the same except this 2 points ;)
+
+
+but many free software developers dont like mono, so the change that it gets more love from more people is not totaly unlikely.
+
+
+So way to long post but hope that helps somebody ;)
+"""]]
diff --git a/doc/not/comment_5_f2829ecbe80a61aa9a8411d2403de69e._comment b/doc/not/comment_5_f2829ecbe80a61aa9a8411d2403de69e._comment
new file mode 100644
index 0000000000..02597ceb8a
--- /dev/null
+++ b/doc/not/comment_5_f2829ecbe80a61aa9a8411d2403de69e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn4bbuawnh-nSo9pAh8irYAcV4MQCcfdHo"
+ nickname="Stefan"
+ subject="comment 5"
+ date="2012-09-15T01:35:06Z"
+ content="""
+or to make it more simple ;)
+
+sparkleshare is for proejects and maybe backup your documents folder
+
+annex is for managing big binary files that not get modified most of the time and only added/synced or deleted.
+
+hope thats on the point, try to start using it also now, but am a bit blowen away what it all can do and what not... and how to get a good use case, and mixing media-management with backup of home and thinking on solving that all with annex without having it used ever ;)
+"""]]
diff --git a/doc/not/comment_6_547fc59b19ad66d7280c53a7f923ea08._comment b/doc/not/comment_6_547fc59b19ad66d7280c53a7f923ea08._comment
new file mode 100644
index 0000000000..9980f0e4c4
--- /dev/null
+++ b/doc/not/comment_6_547fc59b19ad66d7280c53a7f923ea08._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlatTbI0K-qydpeYHl37iseqPNvERcdIMk"
+ nickname="Tiago"
+ subject="comment 6"
+ date="2012-09-27T10:17:18Z"
+ content="""
+Stefan: \"annex is for managing big binary files that not get modified most of the time and only added/synced or deleted.\"
+
+While this is true,  the kickstarter title for assistant was \"Like dropbox\", and dropbox makes it transparent to edit files and they work with the filesystem.
+So with assistant, lock/unlock should be automated and transparent to the user. Otherwise it's confusing and not simple at all to use, and at least OSX keeps giving errors because of the way it handles aliases.
+So something like sharebox is essential to be included in assistant in my opinion.
+
+"""]]
diff --git a/doc/not/comment_7_581e23cca0219711f8a4500a8d5d20fc._comment b/doc/not/comment_7_581e23cca0219711f8a4500a8d5d20fc._comment
new file mode 100644
index 0000000000..f1bb833538
--- /dev/null
+++ b/doc/not/comment_7_581e23cca0219711f8a4500a8d5d20fc._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="l3iggs"
+ ip="24.130.145.126"
+ subject="comment 7"
+ date="2013-02-03T03:57:05Z"
+ content="""
+hi joey,
+
+i'm excited by your project here but also confused by its direction. the kickstarter page has the header: \"git-annex assistant: Like DropBox, but with your own cloud.\" this page says \"git-annex is not a ... DropBox clone.\" these seem to be in direct opposition.
+
+i'm looking for what is described by the header on your kickstarter page. i assume your backers are looking for the the same thing (a self hosted DropBox). for my use, dropbox is perfect, except for the fact that i have to pay a monthly fee to store my data on someone else's server when i would like to buy my own storage medium and run some open source dropbox clone on my own server.
+
+can you explain more clearly what dropbox features your project lacks (/will lack)? and why where is a difference between your fundraising page and this one?
+
+maybe i'm just confused by the difference between git-annex and git-annex assistant. does git-annex assistant truely aim to be a dropbox clone?
+"""]]
diff --git a/doc/not/comment_8_5c61457f117de38ef487e5cc2780d554._comment b/doc/not/comment_8_5c61457f117de38ef487e5cc2780d554._comment
new file mode 100644
index 0000000000..1a955c8626
--- /dev/null
+++ b/doc/not/comment_8_5c61457f117de38ef487e5cc2780d554._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 8"
+ date="2013-02-04T03:17:06Z"
+ content="""
+It's pretty much exactly what he said:
+
+> git-annex is not a filesystem or DropBox clone. However, the git-annex assistant is addressing some of the same needs in its own unique ways. 
+
+The git-annex assistant is not exactly like DropBox; it's not a drop-in replacement that works exactly the way dropbox works.  But as it stands, right now, it can (like Dropbox) run in the background and make sure that all of your files in a special directory are mirrored to another place (a USB drive, or a server to which you have SSH access, or another computer on your home network, or another computer somewhere else which has access to the same USB drive from time to time, or has accesss to the same SSH server or S3 repository or....
+
+It works as is but is still under heavy development and features are being added rapidly.  For example, up until a month or two ago, the files in your annex were replaced with softlinks whose content resided in a hidden directory. This caused some problems esp. on OS X where native programs don't handle softlinked files very gracefully. So Joey added an entirely new way of operating called \"direct mode\" which uses ordinary files, much like Dropbox does.
+
+So -- what you should expect from git-annex assistant is a program which solves many of the same problems Dropbox does (keeping a set of files magically in sync across computers) but does it in its own way, which won't be *exactly* like Dropbox; it will be more flexible but might require a little learning to figure out exactly how to use it the way you want.  It's possible to get a very Dropbox-like system out of the box, especially now that you don't need to use softlinks, if you've got a place on the network you can use as a central remote repository for your files, or if you only want to synchronize two or more computers on the same local network.
+
+\"git-annex\" itself is the plumbing used by git-annex assistant, or to put it another way, the engine that the assistant has under the hood.  Git-annex itself is extremely simple and stable but should only be used by people already familiar with the command line, perhaps even people already familiar with git.
+
+That's my point of view as an enthusiastic user.  Joey may have his own perspective to share. :)
+
+
+
+
+"""]]
diff --git a/doc/not/comment_9_69aa47398a3c13ce64f146de985b727d._comment b/doc/not/comment_9_69aa47398a3c13ce64f146de985b727d._comment
new file mode 100644
index 0000000000..137cfc2df8
--- /dev/null
+++ b/doc/not/comment_9_69aa47398a3c13ce64f146de985b727d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQafKy7hNSEolLs6TvbgUnkklTctUY9LI"
+ nickname="Zellyn"
+ subject="Not a backup system..."
+ date="2013-12-10T20:55:05Z"
+ content="""
+I'd like to understand the \"not a backup system\" point better. My current plan was to use git annex assistant to save my annex folder onto two hard drives, one at home and one at work. Step two is to move most big stuff into .../archive/... folders, and step three is to add an annex folder on my wife's laptop, so we can use the hard drives to back up everything.
+
+Does that sound unreasonable?
+"""]]
diff --git a/doc/polls.mdwn b/doc/polls.mdwn
new file mode 100644
index 0000000000..a4996a4d0d
--- /dev/null
+++ b/doc/polls.mdwn
@@ -0,0 +1,3 @@
+* [[2015 git-annex user survey|2015]]
+* [[2013 git-annex user survey|2013]]
+* [[old polls|design/assistant/polls]]
diff --git a/doc/polls/2013.mdwn b/doc/polls/2013.mdwn
new file mode 100644
index 0000000000..bda584d64a
--- /dev/null
+++ b/doc/polls/2013.mdwn
@@ -0,0 +1,5 @@
+This has moved to a separate site due to load issues.
+
+<http://git-annex-survey.branchable.com/polls/2013/>
+
+Any votes you made here were carried over, so no need to vote twice!
diff --git a/doc/preferred_content.mdwn b/doc/preferred_content.mdwn
new file mode 100644
index 0000000000..19670723cc
--- /dev/null
+++ b/doc/preferred_content.mdwn
@@ -0,0 +1,71 @@
+git-annex tries to ensure that the configured number of [[copies]] of your
+data always exist, and leaves it up to you to use commands like `git annex
+get` and `git annex drop` to move the content to the repositories you want
+to contain it. But often, it can be good to have more fine-grained
+control over which content is wanted by which repositories. Configuring
+this allows the git-annex assistant as well as 
+`git annex get --auto`, `git annex drop --auto`, `git annex sync --content`,
+etc to do smarter things.
+
+Preferred content settings can be edited using `git
+annex vicfg`, or viewed and set at the command line with `git annex wanted`.
+Each repository can have its own settings, and other repositories will
+try to honor those settings when interacting with it.
+(So there's no local `.git/config` for preferred content settings.)
+
+The idea is that you write an expression that files are matched against.
+If a file matches, the repository wants to store its content.
+If it doesn't, the repository wants to drop its content
+(if there are enough copies elsewhere to allow removing it).
+
+## writing expressions
+
+[[!template id=note text="""
+### [[quickstart|standard_groups]]
+
+Rather than writing your own preferred content expression, you can use
+several standard ones included in git-annex that are tuned to cover different
+common use cases.
+
+You do this by putting a repository in a group,
+and simply setting its preferred content to "standard" to match whatever
+is standard for that group. See [[standard_groups]] for a list.
+"""]]
+
+See the man page [[git-annex-preferred-content]] for details on the syntax
+of preferred content expressions.
+
+An example:
+
+	include=*.mp3 and (not largerthan=100mb) and exclude=old/*
+
+This makes all .mp3 files, and all other files that are less than 100 mb in
+size be preferred content. It excludes all files under the "old" directory.
+
+## upgrades
+
+It's important that all clones of a repository can understand one-another's
+preferred content expressions, especially when using the git-annex
+assistant. So using newly added keywords can cause a problem if
+an older version of git-annex is in use elsewhere.
+
+Before git-annex version 5.20140320, when git-annex saw a keyword it
+did not understand, it defaulted to assuming *all* files were
+preferred content. From version 5.20140320, git-annex has a nicer fallback
+behavior: When it is unable to parse a preferred content expression,
+it assumes all files that are currently present are preferred content.
+
+Here are recent changes to preferred content expressions, and the version
+they were added in.
+
+* "securehash" 6.20170228
+* "nothing" 6.201600202
+* "anything" 5.20150616
+* "standard" 5.20140314  
+  (only when used in a more complicated expression; "standard" by
+  itself has been supported for a long time)
+* "groupwanted=" 5.20140314
+* "metadata=" 5.20140221
+* "lackingcopies=", "approxlackingcopies=", "unused=" 5.20140127
+* "inpreferreddir=" 4.20130501
+* "metadata=field&lt;number" etc 6.20160227
diff --git a/doc/preferred_content/comment_10_d9eb7d8efe731cbcdb456fc56935d886._comment b/doc/preferred_content/comment_10_d9eb7d8efe731cbcdb456fc56935d886._comment
new file mode 100644
index 0000000000..c7a898c683
--- /dev/null
+++ b/doc/preferred_content/comment_10_d9eb7d8efe731cbcdb456fc56935d886._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ subject="default settings?"
+ date="2016-01-28T09:32:45Z"
+ content="""
+Could you clarify how the _default_ (empty) preferred content setting works? Is it equivalent to `anything`, or more magical than that?
+
+(Asking because I noticed that `annex find --in . --want-drop` in such a repo matches basically all files, even the ones that `annex sync --content` just retrieved. Likewise, it retrieves files while `annex find --not --in . --want-get` lists nothing. I'm fine with the sync behavior here, but somewhat worried that a _future_ `annex sync --content` would actually decide to drop everything... I'm running 6.20160126 with numcopies=1.)
+
+Also, what happens if I use `standard` for a repo that's not in any group?
+"""]]
diff --git a/doc/preferred_content/comment_10_f0bce3c67f293eaba97b92f0942876b6._comment b/doc/preferred_content/comment_10_f0bce3c67f293eaba97b92f0942876b6._comment
new file mode 100644
index 0000000000..cd7c36fe48
--- /dev/null
+++ b/doc/preferred_content/comment_10_f0bce3c67f293eaba97b92f0942876b6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.22"
+ subject="comment 10"
+ date="2013-10-11T17:12:00Z"
+ content="""
+Georg, `drop --auto` will only drop files that are not preferred content. I'd need to know what preferred content expression you're using to say more.
+"""]]
diff --git a/doc/preferred_content/comment_11_fa7249ebbd7d5b499b486311c0a8f96d._comment b/doc/preferred_content/comment_11_fa7249ebbd7d5b499b486311c0a8f96d._comment
new file mode 100644
index 0000000000..3c9de44de2
--- /dev/null
+++ b/doc/preferred_content/comment_11_fa7249ebbd7d5b499b486311c0a8f96d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2016-01-29T17:30:52Z"
+ content="""
+@grawity, the empty (or unset) preferred content setting causes a default behavior to
+be used. What the default is varies depending on what you're doing. For
+example, if you're running `git annex drop --auto`, it defaults to dropping
+everything when there's no preferred content setting. On the other hand,
+`git annex sync --content` defaults to getting everything. So, this is
+diffent than using "anything".
+
+If you use "standard" and the repo is not in exactly one of the standard
+groups, it behaves the same as if you'd given it an unparseable preferred
+content setting. It will want all files it has and none it doesn't have.
+"""]]
diff --git a/doc/preferred_content/comment_1_7d45e21dfb016e9ffa4715346dd0c1a6._comment b/doc/preferred_content/comment_1_7d45e21dfb016e9ffa4715346dd0c1a6._comment
new file mode 100644
index 0000000000..728e23dc24
--- /dev/null
+++ b/doc/preferred_content/comment_1_7d45e21dfb016e9ffa4715346dd0c1a6._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlgyVag95OnpvSzQofjyX0WjW__MOMKsl0"
+ nickname="Sehr"
+ subject="Interplay with numcopies"
+ date="2012-12-05T20:41:26Z"
+ content="""
+How does the preferred content settings interfere with the numcopies setting?
+
+I could not get behind it. E.g. a case I do not unterstand:
+
+I have a preferred setting evaluating to true and still 
+
+    git annex get --auto
+
+does nothing, if the number of copies produced would surpass the numcopies setting.
+
+
+Thx
+"""]]
diff --git a/doc/preferred_content/comment_2_1ccd90b009245667ad59f4d29d2a3a37._comment b/doc/preferred_content/comment_2_1ccd90b009245667ad59f4d29d2a3a37._comment
new file mode 100644
index 0000000000..51e5f27015
--- /dev/null
+++ b/doc/preferred_content/comment_2_1ccd90b009245667ad59f4d29d2a3a37._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.253.113"
+ subject="comment 2"
+ date="2012-12-06T17:24:29Z"
+ content="""
+Yeah, that didn't make sense. I've fixed it, so it gets files if needed for either numcopies or preferred content.
+"""]]
diff --git a/doc/preferred_content/comment_4_384025b5fa23a3f175985a081438149f._comment b/doc/preferred_content/comment_4_384025b5fa23a3f175985a081438149f._comment
new file mode 100644
index 0000000000..e6d13ca049
--- /dev/null
+++ b/doc/preferred_content/comment_4_384025b5fa23a3f175985a081438149f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.117"
+ subject="comment 4"
+ date="2012-12-10T19:46:01Z"
+ content="""
+It was a bug in the backup group's preferred content pagespec, introduced by the changes I made to fix the previous problem. Now fixed.
+"""]]
diff --git a/doc/preferred_content/comment_4_6a9bc657bc7415f0e118357d8c6664c6._comment b/doc/preferred_content/comment_4_6a9bc657bc7415f0e118357d8c6664c6._comment
new file mode 100644
index 0000000000..0ac5dec521
--- /dev/null
+++ b/doc/preferred_content/comment_4_6a9bc657bc7415f0e118357d8c6664c6._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 4"
+ date="2012-12-07T20:24:18Z"
+ content="""
+Built a new copy of git-annex yesterday.  I have a \"client\" on my macbook, and two \"backup\"s, one on an external HD, one on an ssh git remote.
+
+git annex get --auto works beautifully!
+
+It doesn't seem to work for copying content *to* a place where it's needed, though.
+
+If I drop a file from my \"backup\" USB drive, and then go back to my macbook and do a \"git annex sync\" and \"git annex copy --to=usbdrive --auto\" it does not send the file out to the USB drive, even though by preferred content settings, the USB drive should \"want\" the file because it's a backup drive and it wants all content.
+
+Similarly, if I add a new file on my macbook and then do a \"git annex copy --to=usbdrive auto\" it does not get copied to the USB drive.
+
+Is this missing functionality, or should the preferred content setting for remotes only affect the assistant?
+"""]]
diff --git a/doc/preferred_content/comment_5_f0a957e67297c4bb5a8778c11b3c9fd4._comment b/doc/preferred_content/comment_5_f0a957e67297c4bb5a8778c11b3c9fd4._comment
new file mode 100644
index 0000000000..7074541eb3
--- /dev/null
+++ b/doc/preferred_content/comment_5_f0a957e67297c4bb5a8778c11b3c9fd4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 5"
+ date="2012-12-11T16:03:04Z"
+ content="""
+thanks!
+
+"""]]
diff --git a/doc/preferred_content/comment_6_b434c0e2aaa132020fd4a01551285376._comment b/doc/preferred_content/comment_6_b434c0e2aaa132020fd4a01551285376._comment
new file mode 100644
index 0000000000..12deccb35d
--- /dev/null
+++ b/doc/preferred_content/comment_6_b434c0e2aaa132020fd4a01551285376._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmRFKwny4rArBaz-36xTcsJYqKIgdDaw5Q"
+ nickname="Andrew"
+ subject="comment 6"
+ date="2013-01-10T03:00:52Z"
+ content="""
+Is there a way to change these definitions for a given annex?
+
+ie: in this repo make \"client\" mean
+
+    present and exclude=*/archive/* and exclude=archive/*
+"""]]
diff --git a/doc/preferred_content/comment_7_c4acaa237bf1a8512c5e8ea4cdbd11b9._comment b/doc/preferred_content/comment_7_c4acaa237bf1a8512c5e8ea4cdbd11b9._comment
new file mode 100644
index 0000000000..4facaf69b2
--- /dev/null
+++ b/doc/preferred_content/comment_7_c4acaa237bf1a8512c5e8ea4cdbd11b9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 7"
+ date="2013-01-10T03:51:38Z"
+ content="""
+The expressions used for \"standard\" are built in.
+
+But, you can use \"groupwanted\" instead, see documentation above.
+"""]]
diff --git a/doc/preferred_content/comment_9_f82538be42428691d7cab60a7add2e74._comment b/doc/preferred_content/comment_9_f82538be42428691d7cab60a7add2e74._comment
new file mode 100644
index 0000000000..e1c2d41641
--- /dev/null
+++ b/doc/preferred_content/comment_9_f82538be42428691d7cab60a7add2e74._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkC0W3ZQERUaTkHoks6k68Tsp1tz510nGo"
+ nickname="Georg"
+ subject="drop only files located in archive"
+ date="2013-10-08T17:53:08Z"
+ content="""
+Is there a way to drop only the files that are located in an \"archive\" directory?
+I want to drop all files when calling
+
+    git annex drop --auto
+
+if I move them to the archive. But I want to keep the files that are outside of the archive, even if they are already present in other repos. As far as I have seen and tested, as soon as I have the files in an other repo all files get dropped, also the ones outside the archive directory. Or do I have to increase \"numcopies\" in order to circumvent the \"(not copies=semitrusted+:1)\" case?
+"""]]
diff --git a/doc/preferred_content/standard_groups.mdwn b/doc/preferred_content/standard_groups.mdwn
new file mode 100644
index 0000000000..24f34257d5
--- /dev/null
+++ b/doc/preferred_content/standard_groups.mdwn
@@ -0,0 +1,133 @@
+git-annex comes with some built-in [[preferred_content]] settings, that can
+be used with repositories that are in special groups. To make a
+repository use one of these, just set its preferred content expression
+to "standard", and put it in one of these groups. For example, to put the current
+repository in the manual group and use this group to control the preferred
+content, run
+
+    git annex wanted . standard
+    git annex group . manual
+
+In the webapp, just edit the repository and select the group.
+
+(Note that most of these standard expressions also make the repository
+want to get any content that is only currently available on untrusted and
+dead repositories. So if an untrusted repository gets connected,
+any repository that can will back it up.)
+
+The following standard groups are available:
+
+### client
+
+All content in the current working tree is wanted, unless it's for a
+file in a "archive" directory, which has reached an archive repository.
+
+`(include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1`
+
+### transfer
+
+Use for repositories that are used to transfer data between other
+repositories, but do not need to retain data themselves. For
+example, a repository on a server, or in the cloud, or a small
+USB drive used in a sneakernet.
+
+The preferred content expression for these causes them to get and retain
+data until all clients have a copy.
+
+`not (inallgroup=client and copies=client:2) and ($client)`
+
+(Where $client is a copy of the preferred content expression used for
+clients.)
+
+The "copies=client:2" part of the above handles the case where
+there is only one client repository. It makes a transfer repository
+speculatively  prefer content in this case, even though it as of yet
+has nowhere to transfer it to. Presumably, another client repository
+will be added later.
+
+### backup
+
+All content is wanted. Even content of old/deleted files.
+
+`anything`
+
+(Note that most git-annex commands operate on files present in the
+working tree by default, and using this does not change that. The assistant
+does operate on deleted files, and other commands can be made to do so with
+the --all option.)
+
+### incrementalbackup
+
+Only wants content that's not already backed up to another backup
+or incremental backup repository.
+
+`((not copies=backup:1) and (not copies=incrementalbackup:1)) or approxlackingcopies=1`
+
+### smallarchive
+
+Only wants content that's located in an "archive" directory, and
+only if it's not already been archived somewhere else.
+
+`((include=*/archive/* or include=archive/*) and not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1`
+
+### archive
+
+All content is wanted, unless it's already been archived somewhere else.
+
+`(not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1`
+
+Note that if you want to archive multiple copies (not a bad idea!),
+you can set `git-annex groupwanted archive` to a version of 
+the above preferred content expression with a larger number of copies
+than 1. Then make the archive repositories have a preferred
+content expression of "groupwanted" in order to use your modified
+version.
+
+### source
+
+Use for repositories where files are often added, but that do not need to
+retain files for local use. For example, a repository on a camera, where
+it's desirable to remove photos as soon as they're transferred elsewhere.
+
+The preferred content expression for these causes them to only retain
+data until a copy has been sent to some other repository.
+
+`not (copies=1)`
+
+### manual
+
+This gives you nearly full manual control over what content is stored in the
+repository. This allows using the [[assistant]] without it trying to keep a
+local copy of every file. Instead, you can manually run `git annex get`,
+`git annex drop`, etc to manage content. Only content that is already
+present is wanted.
+
+The exception to this manual control is that content that a client
+repository would not want is not wanted. So, files in archive
+directories are not wanted once their content has 
+reached an archive repository.
+
+`present and ($client)`
+
+(Where $client is a copy of the preferred content expression used for
+clients.)
+
+### public
+
+This is used for publishing information to a repository that can be
+publically accessed. Only files in a directory with a particular name
+will be published. (The directory can be located anywhere in the
+repository.)
+
+`inpreferreddir`
+
+The name of the directory can be configured using
+`git annex enableremote $remote preferreddir=$dirname`
+
+### unwanted
+
+Use for repositories that you don't want to exist. This will result
+in any content on them being moved away to other repositories. (Works
+best when the unwanted repository is also marked as untrusted or dead.)
+
+`not anything`
diff --git a/doc/preferred_content/standard_groups/comment_1_026e47e425d06c4b2580238b3187a379._comment b/doc/preferred_content/standard_groups/comment_1_026e47e425d06c4b2580238b3187a379._comment
new file mode 100644
index 0000000000..9a06d3791e
--- /dev/null
+++ b/doc/preferred_content/standard_groups/comment_1_026e47e425d06c4b2580238b3187a379._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://mildred.fr/"
+ ip="2a01:e35:2f7b:8350:290:f5ff:feea:5546"
+ subject="difference between source and unwanted"
+ date="2014-04-02T22:25:26Z"
+ content="""
+What's the difference between `source` and `unwanted` ?
+
+- `source` (`not copies=1`) will keep files that have less than 1 copies, meaning zero copies, meaning no files.
+- `unwanted` will exclude all files.
+
+Both gets to the same results, all files are moved elsewhere. Right?
+"""]]
diff --git a/doc/preferred_content/standard_groups/comment_2_460bae34ba7c05357318a202b2932d25._comment b/doc/preferred_content/standard_groups/comment_2_460bae34ba7c05357318a202b2932d25._comment
new file mode 100644
index 0000000000..c877a92222
--- /dev/null
+++ b/doc/preferred_content/standard_groups/comment_2_460bae34ba7c05357318a202b2932d25._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 2"
+ date="2014-04-02T22:44:14Z"
+ content="""
+@Mildred, I think both preferred content expressions will do the same thing. There is, however a difference between the groups: The webapp notices when all files have gone from an unwanted repository, and will help the user finish deleting the repository.
+"""]]
diff --git a/doc/preferred_content/standard_groups/comment_4_f5cd38886b58917fa3c417861fd10a10._comment b/doc/preferred_content/standard_groups/comment_4_f5cd38886b58917fa3c417861fd10a10._comment
new file mode 100644
index 0000000000..495afaeee9
--- /dev/null
+++ b/doc/preferred_content/standard_groups/comment_4_f5cd38886b58917fa3c417861fd10a10._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnbBRfl5F8gKRr1ko8Ai6FbEZStXXNF1S4"
+ nickname="Áron"
+ subject="&quot;new files&quot; group"
+ date="2015-02-19T11:06:34Z"
+ content="""
+In my mobile devices I would like to automatically have the newest files, because those have the biggest chance that I want to watch/read them on mobile. But I have found any preferred content expression that is about the age of a file. Is it possible to do something like this with the existing git-annex capabilities?
+thanks
+"""]]
diff --git a/doc/preferred_content/standard_groups/comment_5_22434bd01b2b9ce62ddc9fb64b18f8b8._comment b/doc/preferred_content/standard_groups/comment_5_22434bd01b2b9ce62ddc9fb64b18f8b8._comment
new file mode 100644
index 0000000000..3925841fa8
--- /dev/null
+++ b/doc/preferred_content/standard_groups/comment_5_22434bd01b2b9ce62ddc9fb64b18f8b8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="dittigas"
+ avatar="http://cdn.libravatar.org/avatar/58cabd2b30471004288fac2b535faaa8"
+ subject="How do I mark a specialremote (box.com) as being in the transfer group (cli)"
+ date="2018-03-27T07:39:28Z"
+ content="""
+I've got thing set up (2 client, with box.com as a special remote)... client one uploads it's content, but client 2 does not download anything. I'd like to have box.com set up as as a trandfer repo, which will loos it's content when client 2 got the files.
+"""]]
diff --git a/doc/preferred_content/standard_groups/comment_5_9288dfe6b89885fe287db27cf941be64._comment b/doc/preferred_content/standard_groups/comment_5_9288dfe6b89885fe287db27cf941be64._comment
new file mode 100644
index 0000000000..50a7cb11bf
--- /dev/null
+++ b/doc/preferred_content/standard_groups/comment_5_9288dfe6b89885fe287db27cf941be64._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-02-25T19:17:10Z"
+ content="""
+@Áron, there is not a way to do that, unless you move the "old"
+files to a different directory, or something like that.
+"""]]
diff --git a/doc/preferred_content/standard_groups/comment_6_31fa43557e7585dec5dd105531b0fc10._comment b/doc/preferred_content/standard_groups/comment_6_31fa43557e7585dec5dd105531b0fc10._comment
new file mode 100644
index 0000000000..6ca9aa8feb
--- /dev/null
+++ b/doc/preferred_content/standard_groups/comment_6_31fa43557e7585dec5dd105531b0fc10._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: How do I mark a specialremote (box.com) as being in the transfer group (cli)"""
+ date="2018-04-04T16:21:54Z"
+ content="""
+Up at the top of this page there's an example to change the group
+of the local repository and to make it use the standard preferred content settings for the
+group:
+
+    git annex wanted . standard
+    git annex group . manual
+
+The same commands can be used to configure a remote. Just put the name of the remote
+instead of the "." that is used the refer to the current directory's repository.
+
+    git annex wanted myremote standard
+    git annex group myremote transfer
+"""]]
diff --git a/doc/preferred_content/standard_groups/comment_7_258ce07e607fa8eba80d142651393a95._comment b/doc/preferred_content/standard_groups/comment_7_258ce07e607fa8eba80d142651393a95._comment
new file mode 100644
index 0000000000..f80be9d85a
--- /dev/null
+++ b/doc/preferred_content/standard_groups/comment_7_258ce07e607fa8eba80d142651393a95._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="j2.00ghz@62c10efa0e9db19385458f656e45c32d1642bca4"
+ nickname="j2.00ghz"
+ avatar="http://cdn.libravatar.org/avatar/23a619a7d1f5937934334509a832618d"
+ subject="Repo with multiple groups with wanted/required set to standard"
+ date="2018-12-22T17:06:26Z"
+ content="""
+What should happen if I `git annex require here standard` and then `git annex group here client; git annex group here transfer`? Does it take the expressions from both groups and connects them with or?
+"""]]
diff --git a/doc/preferred_content/standard_groups/comment_8_2d4737488451f1376500098919652808._comment b/doc/preferred_content/standard_groups/comment_8_2d4737488451f1376500098919652808._comment
new file mode 100644
index 0000000000..1cac6f7736
--- /dev/null
+++ b/doc/preferred_content/standard_groups/comment_8_2d4737488451f1376500098919652808._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Repo with multiple groups with wanted/required set to standard"""
+ date="2018-12-26T17:02:54Z"
+ content="""
+standard only works if the repository is in exactly one group.
+
+Combining standard preferred content expressions for several groups with
+OR/AND does not always make sense, and which way does make sense probably
+varies.
+"""]]
diff --git a/doc/privacy.mdwn b/doc/privacy.mdwn
new file mode 100644
index 0000000000..5be735d1ad
--- /dev/null
+++ b/doc/privacy.mdwn
@@ -0,0 +1,47 @@
+git-annex users entrust it with data that is often intensively private.
+Here's some things to know about how to maintain your privacy while using
+git-annex.
+
+## browsing this web site
+
+This website supports https. [Use it.](https://git-annex.branchable.com/privacy/)
+
+## repository contents
+
+In general, anyone who can clone a git repository gets the ability to see
+all current and past filenames in the repository, and their contents.
+It's best to assume this also holds true for git-annex, as a general rule.
+
+There are some obvious exceptions: If you `git annex dropunused` old
+content from all your repositories, then it's *gone*. If you `git annex
+move` files to a offline drive then only those with physical access can see
+their content. (The names of the files are still visible to anyone with a
+clone of the repository.)
+
+git-annex can encrypt data stored in special remotes. This allows you to
+store files in the cloud without exposing their file names, or their
+contents. See [[design/encryption]] for details.
+
+When using the shared encryption method, the encryption key gets stored
+in git, and so anyone who has a clone of your repository can decrypt files
+from the encrypted special remote.
+
+When using encryption with a GPG key or keys, only those with access to the
+GPG key can decrypt the content of files stored in an encrypted special
+remote.
+
+## bug reporting
+
+When you file a [[bug|bugs]] report on git-annex, you may need to provide
+debugging output or details about your repository. In general, git-annex
+does not sanitize `--debug` output at all, so it may include the names of
+files or other repository details. You should review any debug or other
+output you post, and feel free to remove identifying information.
+
+Note that the git-annex assistant *does* sanitize XMPP protocol information
+logged when debugging is enabled.
+
+If you prefer not to post information publically, you can send a GPG
+encrypted mail to Joey Hess <id@joeyh.name> (gpg key ID 2512E3C7).
+Or you can post a public bug report, and send a followup email with private
+details.
diff --git a/doc/profiling.mdwn b/doc/profiling.mdwn
new file mode 100644
index 0000000000..99429aa05f
--- /dev/null
+++ b/doc/profiling.mdwn
@@ -0,0 +1,3 @@
+This page exsists to collect profiling data about git-annex, so it can
+be referred to later. If you have a specific instance where git-annex seems
+unncessarily slow, please file a bug report about it.
diff --git a/doc/profiling/comment_1_c1f99493f5e5c362d5c39f048280b11b._comment b/doc/profiling/comment_1_c1f99493f5e5c362d5c39f048280b11b._comment
new file mode 100644
index 0000000000..e0f4987a02
--- /dev/null
+++ b/doc/profiling/comment_1_c1f99493f5e5c362d5c39f048280b11b._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""profiling"""
+ date="2016-09-26T19:20:36Z"
+ content="""
+Built git-annex with profiling, using `stack build --profile`
+
+(For reproduciblity, running git-annex in a clone of the git-annex repo
+https://github.com/RichiH/conference_proceedings with rev
+2797a49023fc24aff6fcaec55421572e1eddcfa2 checked out. It has 9496 annexed
+objects.)
+
+Profiling `git-annex find +RTS -p`:
+
+	        total time  =        3.53 secs   (3530 ticks @ 1000 us, 1 processor)
+	        total alloc = 3,772,700,720 bytes  (excludes profiling overheads)
+	
+	COST CENTRE            MODULE                  %time %alloc
+	
+	spanList               Data.List.Utils          32.6   37.7
+	startswith             Data.List.Utils          14.3    8.1
+	md5                    Data.Hash.MD5            12.4   18.2
+	join                   Data.List.Utils           6.9   13.7
+	catchIO                Utility.Exception         5.9    6.0
+	catches                Control.Monad.Catch       5.0    2.8
+	inAnnex'.checkindirect Annex.Content             4.6    1.8
+	readish                Utility.PartialPrelude    3.0    1.4
+	isAnnexLink            Annex.Link                2.6    4.0
+	split                  Data.List.Utils           1.5    0.8
+	keyPath                Annex.Locations           1.2    1.7
+
+
+This is interesting!
+
+Fully 40% of CPU time and allocations are in list (really String) processing,
+and the details of the profiling report show that `spanList` and `startsWith`
+and `join` are all coming from calls to `replace` in `keyFile` and `fileKey`.
+Both functions nest several calls to replace, so perhaps that could be unwound
+into a single pass and/or a ByteString used to do it more efficiently.
+
+12% of run time is spent calculating the md5 hashes for the hash
+directories for .git/annex/objects. Data.Hash.MD5 is from missingh, and
+it is probably a quite unoptimised version. Switching to the version
+if cryptonite would probably speed it up a lot.
+"""]]
diff --git a/doc/profiling/comment_2_f4d802a28b79905da0cb24af6cb65b0a._comment b/doc/profiling/comment_2_f4d802a28b79905da0cb24af6cb65b0a._comment
new file mode 100644
index 0000000000..9692ad2d73
--- /dev/null
+++ b/doc/profiling/comment_2_f4d802a28b79905da0cb24af6cb65b0a._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""more profiling"""
+ date="2016-09-26T19:59:43Z"
+ content="""
+Instead of profiling `git annex copy --to remote`, I profiled `git annex
+find --not --in web`, which needs to do the same kind of location log lookup.
+
+	        total time  =       12.41 secs   (12413 ticks @ 1000 us, 1 processor)
+	        total alloc = 8,645,057,104 bytes  (excludes profiling overheads)
+	
+	COST CENTRE               MODULE                      %time %alloc
+	
+	adjustGitEnv              Git.Env                      21.4   37.0
+	catchIO                   Utility.Exception            13.2    2.8
+	spanList                  Data.List.Utils              12.6   17.9
+	parsePOSIXTime            Logs.TimeStamp                6.1    5.0
+	catObjectDetails.receive  Git.CatFile                   5.9    2.1
+	startswith                Data.List.Utils               5.7    3.8
+	md5                       Data.Hash.MD5                 5.1    7.9
+	join                      Data.List.Utils               2.4    6.0
+	readFileStrictAnyEncoding Utility.Misc                  2.2    0.5
+
+The adjustGitEnv overhead is a surprise! It seems it is getting called once
+per file, and allocating a new copy of the environment each time. Call stack:
+withIndex calls withIndexFile calls addGitEnv calls adjustGitEnv.
+Looks like simply making gitEnv be cached at startup would avoid most of
+the adjustGitEnv slowdown.
+
+(The catchIO overhead is a false reading; the detailed profile shows
+that all its time and allocations are inherited. getAnnexLinkTarget
+is running catchIO in the expensive case, so readSymbolicLink is
+the actual expensive bit.)
+
+The parsePOSIXTime comes from reading location logs. It's implemented
+using a generic Data.Time.Format.parseTime, which uses a format string
+"%s%Qs". A custom parser that splits into seconds and picoseconds
+and simply reads both numbers might be more efficient.
+
+catObjectDetails.receive is implemented using mostly String and could
+probably be sped up by being converted to use ByteString.
+"""]]
diff --git a/doc/profiling/comment_3_1af4ac0d37c876912678522895c1656b._comment b/doc/profiling/comment_3_1af4ac0d37c876912678522895c1656b._comment
new file mode 100644
index 0000000000..868b103646
--- /dev/null
+++ b/doc/profiling/comment_3_1af4ac0d37c876912678522895c1656b._comment
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2016-09-29T18:33:33Z"
+ content="""
+* Optimised key2file and file2key. 18% scanning time speedup.
+* Optimised adjustGitEnv. 50% git-annex branch query speedup
+* Optimised parsePOSIXTime. 10% git-annex branch query speedup
+* Tried making catObjectDetails.receive use ByteString for parsing, 
+  but that did not seem to speed it up significantly.
+  So it parsing is already fairly optimal, it's just that a
+  lot of data passes through it when querying the git-annex
+  branch.
+
+After all that, profiling `git-annex find`:
+
+	        Thu Sep 29 16:51 2016 Time and Allocation Profiling Report  (Final)
+	
+	           git-annex.1 +RTS -p -RTS find
+	
+	        total time  =        1.73 secs   (1730 ticks @ 1000 us, 1 processor)
+	        total alloc = 1,812,406,632 bytes  (excludes profiling overheads)
+	
+	COST CENTRE            MODULE                  %time %alloc
+	
+	md5                    Data.Hash.MD5            28.0   37.9
+	catchIO                Utility.Exception        10.2   12.5
+	inAnnex'.checkindirect Annex.Content             9.9    3.7
+	catches                Control.Monad.Catch       8.7    5.7
+	readish                Utility.PartialPrelude    5.7    3.0
+	isAnnexLink            Annex.Link                5.0    8.4
+	keyFile                Annex.Locations           4.2    5.8
+	spanList               Data.List.Utils           4.0    6.3
+	startswith             Data.List.Utils           2.0    1.3
+
+And `git-annex find --not --in web`:
+
+	        Thu Sep 29 16:35 2016 Time and Allocation Profiling Report  (Final)
+	
+	           git-annex +RTS -p -RTS find --not --in web
+	
+	        total time  =        5.24 secs   (5238 ticks @ 1000 us, 1 processor)
+	        total alloc = 3,293,314,472 bytes  (excludes profiling overheads)
+	
+	COST CENTRE               MODULE                      %time %alloc
+	
+	catObjectDetails.receive  Git.CatFile                  12.9    5.5
+	md5                       Data.Hash.MD5                10.6   20.8
+	readish                   Utility.PartialPrelude        7.3    8.2
+	catchIO                   Utility.Exception             6.7    7.3
+	spanList                  Data.List.Utils               4.1    7.4
+	readFileStrictAnyEncoding Utility.Misc                  3.5    1.3
+	catches                   Control.Monad.Catch           3.3    3.2
+
+So, quite a large speedup overall!
+
+This leaves md5 still unoptimised at 10-28% of CPU use. I looked at switching
+it to cryptohash's implementation, but it would require quite a lot of
+bit-banging math to pull the used values out of the ByteString containing
+the md5sum.
+"""]]
diff --git a/doc/profiling/comment_4_1ca8d9765e6e3a18ae09df74bc390a00._comment b/doc/profiling/comment_4_1ca8d9765e6e3a18ae09df74bc390a00._comment
new file mode 100644
index 0000000000..619351d4ca
--- /dev/null
+++ b/doc/profiling/comment_4_1ca8d9765e6e3a18ae09df74bc390a00._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2017-05-15T21:56:52Z"
+ content="""
+Switched from MissingH to cryptonite for md5. It did move md5 out of the top CPU spot but
+the overall runtime didn't change much. Memory allocations did go down by a
+good amount.
+
+Updated profiles:
+
+	           git-annex +RTS -p -RTS find
+	
+	        total time  =        1.63 secs   (1629 ticks @ 1000 us, 1 processor)
+	        total alloc = 1,496,336,496 bytes  (excludes profiling overheads)
+	
+	COST CENTRE              MODULE                     SRC                                             %time %alloc
+	
+	catchIO                  Utility.Exception          Utility/Exception.hs:79:1-17                     14.1   15.1
+	inAnnex'.checkindirect   Annex.Content              Annex/Content.hs:(108,9)-(119,39)                10.6    4.8
+	catches                  Control.Monad.Catch        src/Control/Monad/Catch.hs:(432,1)-(436,76)       8.6    6.9
+	spanList                 Data.List.Utils            src/Data/List/Utils.hs:(150,1)-(155,36)           6.7   11.1
+	isAnnexLink              Annex.Link                 Annex/Link.hs:35:1-85                             5.0   10.2
+	keyFile                  Annex.Locations            Annex/Locations.hs:(456,1)-(462,19)               5.0    7.0
+	readish                  Utility.PartialPrelude     Utility/PartialPrelude.hs:(48,1)-(50,20)          3.8    2.0
+	startswith               Data.List.Utils            src/Data/List/Utils.hs:103:1-23                   3.6    2.3
+	splitc                   Utility.Misc               Utility/Misc.hs:(52,1)-(54,25)                    3.4    6.5
+	s2w8                     Data.Bits.Utils            src/Data/Bits/Utils.hs:65:1-15                    2.6    6.4
+	keyPath                  Annex.Locations            Annex/Locations.hs:(492,1)-(494,23)               2.5    4.4
+	fileKey.unesc            Annex.Locations            Annex/Locations.hs:(469,9)-(474,39)               2.0    3.5
+	copyAndFreeze            Data.ByteArray.Methods     Data/ByteArray/Methods.hs:(224,1)-(227,21)        1.8    0.5
+
+	           git-annex +RTS -p -RTS find --not --in web
+	
+	        total time  =        5.33 secs   (5327 ticks @ 1000 us, 1 processor)
+	        total alloc = 2,908,489,000 bytes  (excludes profiling overheads)
+	
+	COST CENTRE          MODULE                     SRC                                             %time %alloc
+	
+	catObjectDetails.\   Git.CatFile                Git/CatFile.hs:(80,72)-(88,97)                    7.8    2.8
+	catchIO              Utility.Exception          Utility/Exception.hs:79:1-17                      7.6    8.3
+	spanList             Data.List.Utils            src/Data/List/Utils.hs:(150,1)-(155,36)           5.8    9.1
+	readish              Utility.PartialPrelude     Utility/PartialPrelude.hs:(48,1)-(50,20)          4.5    4.0
+	parseResp            Git.CatFile                Git/CatFile.hs:(113,1)-(124,28)                   4.4    2.9
+	readFileStrict       Utility.Misc               Utility/Misc.hs:33:1-59                           3.7    1.6
+	catches              Control.Monad.Catch        src/Control/Monad/Catch.hs:(432,1)-(436,76)       3.1    3.6
+	encodeW8             Utility.FileSystemEncoding Utility/FileSystemEncoding.hs:(131,1)-(133,70)    3.1    2.3
+	
+"""]]
diff --git a/doc/profiling/comment_5_1ca8d9765e6e3a18ae09df74bc390a00._comment b/doc/profiling/comment_5_1ca8d9765e6e3a18ae09df74bc390a00._comment
new file mode 100644
index 0000000000..135011a9c7
--- /dev/null
+++ b/doc/profiling/comment_5_1ca8d9765e6e3a18ae09df74bc390a00._comment
@@ -0,0 +1,80 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-01-14T21:18:17Z"
+ content="""
+After switching many internal types to ByteString.
+
+(Note that stack build --profile built this with -O, not -O2, so it's not
+as fast as it ought to be, but the cost centers are probably fairly
+accurate still.)
+
+	        Mon Jan 14 17:17 2019 Time and Allocation Profiling Report  (Final)
+	
+	           git-annex +RTS -p -RTS find
+	
+	        total time  =        3.07 secs   (3074 ticks @ 1000 us, 1 processor)
+	        total alloc = 1,880,855,184 bytes  (excludes profiling overheads)
+	
+	COST CENTRE                      MODULE                         SRC                                                 %time %alloc
+	
+	inAnnex'.checkindirect           Annex.Content                  Annex/Content.hs:(106,9)-(121,39)                    31.6   41.0
+	splitc                           Utility.Split                  Utility/Split.hs:(24,1)-(26,25)                       4.8    5.2
+	keyFile'                         Annex.Locations                Annex/Locations.hs:(518,1)-(524,30)                   4.5    5.2
+	encodeW8                         Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:(189,1)-(191,70)        3.1    3.6
+	>>=.\                            Data.Attoparsec.Internal.Types Data/Attoparsec/Internal/Types.hs:(146,9)-(147,44)    2.5    0.7
+	_encodeFilePath                  Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:(111,1)-(114,49)        2.5    2.7
+	>>=.\.succ'                      Data.Attoparsec.Internal.Types Data/Attoparsec/Internal/Types.hs:146:13-76           2.2    0.2
+	fileKey'                         Annex.Locations                Annex/Locations.hs:(532,1)-(541,41)                   2.2    1.5
+	getState                         Annex                          Annex.hs:(254,1)-(257,27)                             2.1    0.4
+	getAnnexLinkTarget'.probesymlink Annex.Link                     Annex/Link.hs:77:9-62                                 1.9    2.5
+	w82s                             Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:217:1-15                1.8    5.2
+	keyPath                          Annex.Locations                Annex/Locations.hs:(551,1)-(553,23)                   1.7    3.5
+	keyFile'.esc                     Annex.Locations                Annex/Locations.hs:(520,9)-(524,30)                   1.6    4.7
+	fileKey'.go                      Annex.Locations                Annex/Locations.hs:535:9-63                           1.6    1.6
+	s2w8                             Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:214:1-15                1.3    3.5
+	withPtr                          Basement.Block.Base            Basement/Block/Base.hs:(395,1)-(404,31)               1.3    0.5
+	parseLinkTarget                  Annex.Link                     Annex/Link.hs:(247,1)-(255,25)                        1.2    3.8
+	parseKeyVariety                  Types.Key                      Types/Key.hs:(135,1)-(184,41)                         1.2    0.0
+	assertLocal                      Git                            Git.hs:(123,1)-(129,28)                               0.8    1.6
+	decodeBS'                        Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:151:1-31                0.6    2.4
+
+Notice that the percent of time inAnnex' went up from 14.1% to 31.6%. 
+That and getAnnexLinkTarget are the meat of the IO, so it's good for them
+to get a higher percent of the CPU, to the extent they're IO bound.
+It seems like getAnnexLinkTarget also lost a lot of non-IO overhead.
+
+There are still some overheads from conversion to and from ByteString,
+but the above does seem like a good improvement.
+
+	        Mon Jan 14 17:56 2019 Time and Allocation Profiling Report  (Final)
+	
+	           git-annex +RTS -p -RTS find --not --in web
+	
+	        total time  =        7.62 secs   (7622 ticks @ 1000 us, 1 processor)
+	        total alloc = 1,908,064,368 bytes  (excludes profiling overheads)
+	
+	COST CENTRE                      MODULE                         SRC                                                 %time %alloc
+	
+	catObjectDetails.\               Git.CatFile                    Git/CatFile.hs:(83,88)-(91,97)                        6.5    3.8
+	catchDefaultIO                   Utility.Exception              Utility/Exception.hs:57:1-53                          6.4    2.5
+	parseResp                        Git.CatFile                    Git/CatFile.hs:(141,1)-(152,28)                       4.9    5.0
+	MAIN                             MAIN                           <built-in>                                            4.6    0.4
+	>>=.\                            Data.Attoparsec.Internal.Types Data/Attoparsec/Internal/Types.hs:(146,9)-(147,44)    4.6    1.7
+	>>=.\.succ'                      Data.Attoparsec.Internal.Types Data/Attoparsec/Internal/Types.hs:146:13-76           4.1    0.7
+	getState                         Annex                          Annex.hs:(254,1)-(257,27)                             2.7    1.1
+	simplifyPath                     Utility.Path                   Utility/Path.hs:(38,1)-(50,48)                        2.6    6.8
+	splitc                           Utility.Split                  Utility/Split.hs:(24,1)-(26,25)                       2.5    5.1
+	keyFile'                         Annex.Locations                Annex/Locations.hs:(518,1)-(524,30)                   1.7    5.2
+	getAnnexLinkTarget'.probesymlink Annex.Link                     Annex/Link.hs:77:9-62                                 1.7    2.6
+	journalFile                      Annex.Journal                  Annex/Journal.hs:(107,1)-(112,33)                     1.7    5.7
+	catches                          Control.Monad.Catch            src/Control/Monad/Catch.hs:(795,1)-(799,76)           1.7    2.7
+	query.send                       Git.CatFile                    Git/CatFile.hs:137:9-32                               1.6    0.5
+	delEntry                         Utility.Env                    Utility/Env.hs:(57,1)-(60,48)                         1.6    0.8
+	encodeW8                         Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:(189,1)-(191,70)        1.4    3.5
+	query                            Git.CatFile                    Git/CatFile.hs:(130,1)-(138,26)                       1.3    0.0
+
+Notice that allocations dropped by 1/3rd!
+
+Otherwise, not a large change here..
+"""]]
diff --git a/doc/profiling/comment_6_ca4ac016a0fb0132fc5c746dfb6fefb3._comment b/doc/profiling/comment_6_ca4ac016a0fb0132fc5c746dfb6fefb3._comment
new file mode 100644
index 0000000000..7f8d3a2571
--- /dev/null
+++ b/doc/profiling/comment_6_ca4ac016a0fb0132fc5c746dfb6fefb3._comment
@@ -0,0 +1,70 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2019-11-22T22:18:02Z"
+ content="""
+After caching serialized Keys.
+
+		Fri Nov 22 19:06 2019 Time and Allocation Profiling Report  (Final)
+	
+		   git-annex +RTS -p -RTS find
+	
+		total time  =        3.00 secs   (2997 ticks @ 1000 us, 1 processor)
+		total alloc = 1,890,060,432 bytes  (excludes profiling overheads)
+	
+	COST CENTRE                      MODULE                         SRC                                                 %time %alloc
+	
+	inAnnex'.\                       Annex.Content                  Annex/Content.hs:(103,61)-(118,31)                   28.2   40.6
+	keyFile'                         Annex.Locations                Annex/Locations.hs:(564,1)-(574,30)                   3.8    5.3
+	splitc                           Utility.Split                  Utility/Split.hs:(24,1)-(26,25)                       3.7    5.1
+	_encodeFilePath                  Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:(111,1)-(114,49)        3.1    2.7
+	encodeW8                         Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:(189,1)-(191,70)        3.0    3.6
+	w82s                             Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:217:1-15                2.8    5.1
+	>>=.\.succ'                      Data.Attoparsec.Internal.Types Data/Attoparsec/Internal/Types.hs:146:13-76           2.8    0.2
+	>>=.\                            Data.Attoparsec.Internal.Types Data/Attoparsec/Internal/Types.hs:(146,9)-(147,44)    2.5    0.7
+	getAnnexLinkTarget'.probesymlink Annex.Link                     Annex/Link.hs:78:9-62                                 2.4    2.5
+	fileKey'                         Annex.Locations                Annex/Locations.hs:(583,1)-(593,41)                   2.1    1.5
+	parseLinkTarget                  Annex.Link                     Annex/Link.hs:(254,1)-(262,25)                        2.0    3.8
+	keyFile'.esc                     Annex.Locations                Annex/Locations.hs:(570,9)-(574,30)                   1.9    4.7
+	s2w8                             Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:214:1-15                1.7    3.5
+	keyPath                          Annex.Locations                Annex/Locations.hs:(603,1)-(605,23)                   1.6    3.5
+	getState                         Annex                          Annex.hs:(251,1)-(254,27)                             1.6    0.3
+	parseKeyVariety                  Types.Key                      Types/Key.hs:(322,1)-(370,42)                         1.4    0.0
+	withMutablePtrHint               Basement.Block.Base            Basement/Block/Base.hs:(468,1)-(482,50)               1.3    0.4
+	hashUpdates.\.\.\                Crypto.Hash                    Crypto/Hash.hs:85:48-99                               1.2    0.0
+	parseLinkTargetOrPointer         Annex.Link                     Annex/Link.hs:(239,1)-(243,25)                        1.1    0.1
+	primitive                        Basement.Monad                 Basement/Monad.hs:72:5-18                             1.1    0.0
+	withPtr.makeTrampoline           Basement.Block.Base            Basement/Block/Base.hs:(401,5)-(404,31)               1.0    0.6
+	assertLocal                      Git                            Git.hs:(123,1)-(129,28)                               0.8    1.6
+	decodeBS'                        Utility.FileSystemEncoding     Utility/FileSystemEncoding.hs:151:1-31                0.4    2.4
+
+Runtime improved by 5% or so, and getAnnexLinkTarget moved up, otherwise
+not a lot of change. keyFile is looking like an optimization target,
+although its percent of the runtime actually reduced. 
+However that's specific to this repo which has a lot of URL keys that
+contain '/' and so need to be escaped.
+
+		Fri Nov 22 19:09 2019 Time and Allocation Profiling Report  (Final)
+	
+		   git-annex +RTS -p -RTS find --not --in web
+	
+		total time  =        8.42 secs   (8421 ticks @ 1000 us, 1 processor)
+		total alloc = 1,887,547,744 bytes  (excludes profiling overheads)
+	
+	COST CENTRE                      MODULE                           SRC                                                 %time %alloc
+	
+	catObjectDetails.\               Git.CatFile                      Git/CatFile.hs:(83,88)-(91,97)                        8.1    4.1
+	catchMaybeIO                     Utility.Exception                Utility/Exception.hs:53:1-63                          7.6    2.2
+	parseResp                        Git.CatFile                      Git/CatFile.hs:(145,1)-(156,28)                       5.2    5.6
+	>>=.\                            Data.Attoparsec.Internal.Types   Data/Attoparsec/Internal/Types.hs:(146,9)-(147,44)    5.0    2.0
+	>>=.\.succ'                      Data.Attoparsec.Internal.Types   Data/Attoparsec/Internal/Types.hs:146:13-76           4.7    1.0
+	MAIN                             MAIN                             <built-in>                                            4.2    0.4
+	getState                         Annex                            Annex.hs:(251,1)-(254,27)                             2.0    1.1
+	getAnnexLinkTarget'.probesymlink Annex.Link                       Annex/Link.hs:78:9-62                                 1.9    2.6
+	splitc                           Utility.Split                    Utility/Split.hs:(24,1)-(26,25)                       1.9    5.2
+	_encodeFilePath                  Utility.FileSystemEncoding       Utility/FileSystemEncoding.hs:(111,1)-(114,49)        1.8    2.8
+	query.send                       Git.CatFile                      Git/CatFile.hs:141:9-32                               1.7    0.5
+	keyFile'                         Annex.Locations                  Annex/Locations.hs:(564,1)-(574,30)                   1.6    5.4
+
+Ditto.
+"""]]
diff --git a/doc/profiling/comment_7_95f5afb616c7eba60473cdeb85a070b0._comment b/doc/profiling/comment_7_95f5afb616c7eba60473cdeb85a070b0._comment
new file mode 100644
index 0000000000..05db73f4fb
--- /dev/null
+++ b/doc/profiling/comment_7_95f5afb616c7eba60473cdeb85a070b0._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2019-12-18T19:18:04Z"
+ content="""
+Updated profiling. git-annex find is now ByteString end-to-end!
+Note the massive reduction in alloc, and improved runtime.
+
+	        Wed Dec 11 14:41 2019 Time and Allocation Profiling Report  (Final)
+	
+	           git-annex +RTS -p -RTS find
+	
+	        total time  =        1.51 secs   (1515 ticks @ 1000 us, 1 processor)
+	        total alloc = 608,475,328 bytes  (excludes profiling overheads)
+	
+	COST CENTRE                      MODULE                           SRC                                                    %time %alloc
+	
+	keyFile'                         Annex.Locations                  Annex/Locations.hs:(590,1)-(600,30)                      8.2   16.6
+	>>=.\.succ'                      Data.Attoparsec.Internal.Types   Data/Attoparsec/Internal/Types.hs:146:13-76              4.7    0.7
+	getAnnexLinkTarget'.probesymlink Annex.Link                       Annex/Link.hs:79:9-46                                    4.2    7.6
+	>>=.\                            Data.Attoparsec.Internal.Types   Data/Attoparsec/Internal/Types.hs:(146,9)-(147,44)       3.9    2.3
+	parseLinkTarget                  Annex.Link                       Annex/Link.hs:(255,1)-(263,25)                           3.9   11.8
+	doesPathExist                    Utility.RawFilePath              Utility/RawFilePath.hs:30:1-25                           3.4    0.6
+	keyFile'.esc                     Annex.Locations                  Annex/Locations.hs:(596,9)-(600,30)                      3.2   14.7
+	fileKey'                         Annex.Locations                  Annex/Locations.hs:(609,1)-(619,41)                      3.0    4.7
+	parseLinkTargetOrPointer         Annex.Link                       Annex/Link.hs:(240,1)-(244,25)                           2.8    0.2
+	hashUpdates.\.\.\                Crypto.Hash                      Crypto/Hash.hs:85:48-99                                  2.5    0.1
+	combineAlways                    System.FilePath.Posix.ByteString System/FilePath/Posix/../Internal.hs:(698,1)-(704,67)    2.0    3.3
+	getState                         Annex                            Annex.hs:(251,1)-(254,27)                                2.0    1.1
+	withPtr.makeTrampoline           Basement.Block.Base              Basement/Block/Base.hs:(401,5)-(404,31)                  1.9    1.7
+	withMutablePtrHint               Basement.Block.Base              Basement/Block/Base.hs:(468,1)-(482,50)                  1.8    1.2
+	parseKeyVariety                  Types.Key                        Types/Key.hs:(323,1)-(371,42)                            1.8    0.0
+	fileKey'.go                      Annex.Locations                  Annex/Locations.hs:611:9-55                              1.7    2.2
+	isLinkToAnnex                    Annex.Link                       Annex/Link.hs:(299,1)-(305,47)                           1.7    1.0
+	hashDirMixed                     Annex.DirHashes                  Annex/DirHashes.hs:(82,1)-(90,27)                        1.7    1.3
+	primitive                        Basement.Monad                   Basement/Monad.hs:72:5-18                                1.6    0.1
+	withPtr                          Basement.Block.Base              Basement/Block/Base.hs:(395,1)-(404,31)                  1.5    1.6
+	mkKeySerialization               Types.Key                        Types/Key.hs:(115,1)-(117,22)                            1.1    2.8
+	decimal.step                     Data.Attoparsec.ByteString.Char8 Data/Attoparsec/ByteString/Char8.hs:448:9-49             0.8    1.2
+"""]]
diff --git a/doc/profiling/comment_8_951c1c047ef414268295626218474677._comment b/doc/profiling/comment_8_951c1c047ef414268295626218474677._comment
new file mode 100644
index 0000000000..39e0e446d8
--- /dev/null
+++ b/doc/profiling/comment_8_951c1c047ef414268295626218474677._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2020-10-19T18:27:56Z"
+ content="""
+Update after some recent optimisations involving seekFilteredKeys.
+
+	        Mon Oct 19 14:36 2020 Time and Allocation Profiling Report  (Final)
+	
+	           git-annex +RTS -p -RTS find
+	
+	        total time  =        1.32 secs   (1316 ticks @ 1000 us, 1 processor)
+	        total alloc = 583,359,800 bytes  (excludes profiling overheads)
+	
+	COST CENTRE           MODULE                              SRC                                                   %time %alloc
+	
+	keyFile               Annex.Locations                     Annex/Locations.hs:(602,1)-(612,30)                    13.2   32.7
+	readObjectContent     Git.CatFile                         Git/CatFile.hs:(122,1)-(131,42)                        10.9    2.3
+	copyAndFreeze         Data.ByteArray.Methods              Data/ByteArray/Methods.hs:(237,1)-(240,21)              5.2    0.8
+	withPtr               Basement.Block.Base                 Basement/Block/Base.hs:(402,1)-(411,31)                 5.2    4.1
+	parseLinkTarget       Annex.Link                          Annex/Link.hs:(263,1)-(271,25)                          4.5   12.3
+	fileKey               Annex.Locations                     Annex/Locations.hs:(618,1)-(628,41)                     4.5    8.1
+	decimal               Data.Attoparsec.ByteString.Char8    Data/Attoparsec/ByteString/Char8.hs:(447,1)-(448,49)    4.3    4.5
+	doesPathExist         Utility.RawFilePath                 Utility/RawFilePath.hs:32:1-25                          3.9    0.6
+	ifM                   Utility.Monad                       Utility/Monad.hs:(54,1)-(56,44)                         3.0    3.2
+	catObjectStream       Git.CatFile                         Git/CatFile.hs:(322,1)-(330,45)                         2.6    2.5
+	</>                   System.FilePath.Posix.ByteString    System/FilePath/Posix/../Internal.hs:841:1-15           2.4    3.4
+	respParser            Git.CatFile                         Git/CatFile.hs:(175,1)-(182,39)                         2.4    1.3
+"""]]
diff --git a/doc/projects.mdwn b/doc/projects.mdwn
new file mode 100644
index 0000000000..bbf2b2d2b9
--- /dev/null
+++ b/doc/projects.mdwn
@@ -0,0 +1,5 @@
+Projects that rely on git-annex can put pages here to do things like track
+bugs that affect them, etc. (See also: [[related_software]])
+
+[[!inline pages="projects/* and !projects/*/* and !*/Discussion" 
+feeds=no archive=yes sort=title rootpage="projects" postformtext="Add your project:"]]
diff --git a/doc/projects/annextimelog.mdwn b/doc/projects/annextimelog.mdwn
new file mode 100644
index 0000000000..031032b84b
--- /dev/null
+++ b/doc/projects/annextimelog.mdwn
@@ -0,0 +1,10 @@
+[annextimelog](https://gitlab.com/nobodyinperson/annextimelog) (`atl`) is a cli time tracker and logbook made by [[users/nobodyinperson]]. It uses git-annex to store and sync data. `atl` has a loosely similar usage to [timewarrior](https://timewarrior.net/) but improves on many of its pain points:
+
+- tracking of simultaneous events
+- conflict-free syncing
+- more powerful tagging system
+- more powerful search
+- more output formats (JSON, hledger timeclock, ...)
+- a more sophisticated event specification language
+
+annextimelog is also an experiment how useable git-annex is as a backend for syncable application data storage. While first sounding silly, it works very well.
diff --git a/doc/projects/dandi.mdwn b/doc/projects/dandi.mdwn
new file mode 100644
index 0000000000..380200ac16
--- /dev/null
+++ b/doc/projects/dandi.mdwn
@@ -0,0 +1,26 @@
+DANDI [https://dandiarchive.org](https://dandiarchive.org)
+==========================================================
+
+DANDI: Distributed Archives for Neurophysiology Data Integration is a platform for publishing, sharing, and processing neurophysiology data funded by the BRAIN Initiative. The platform is under construction with an initial release slated for end of September 2019.
+
+## TODOs
+
+[[!inline pages="todo/* and !todo/done and !link(todo/done) and tagged(projects/dandi)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+<details>
+<summary>Done</summary>
+
+[[!inline pages="todo/* and !todo/done and link(todo/done) and tagged(projects/dandi)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+</details>
+
+## BUGs
+
+[[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and tagged(projects/dandi)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+<details>
+<summary>Done</summary>
+
+[[!inline pages="((bugs/* and !bugs/done and link(bugs/done)) or projects/dandi/bugs-done/*) and tagged(projects/dandi)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+</details>
diff --git a/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_.mdwn b/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_.mdwn
new file mode 100644
index 0000000000..b6098127a7
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_.mdwn
@@ -0,0 +1,49 @@
+### Please describe the problem.
+
+Original complaints could be found mentioned in the comments of the [importfeed page](https://git-annex.branchable.com/git-annex-importfeed/): when using `addurl`, and even when the server provides Content-Disposition field with the filename, git-annex seems (BTW -- no Content-Disposition was mentioned in the --debug output) to take that filename value and obfuscates it (replaces '-' with '_' etc) to what supposed to be the original filename.
+
+
+[[!format sh """
+$> mkdir /tmp/testrepo; cd /tmp/testrepo; git init; git annex init; 
+mkdir: cannot create directory ‘/tmp/testrepo’: File exists
+E: could not determine git repository root
+Initialized empty Git repository in /tmp/testrepo/.git/
+init  ok
+(recording state in git...)
+
+$> git annex addurl --fast  https://girder.dandiarchive.org/api/v1/item/5e9f9588b5c9745bad9f58ff/download      
+addurl https://girder.dandiarchive.org/api/v1/item/5e9f9588b5c9745bad9f58ff/download (to sub_mouse_AAYYT_ses_20180420_sample_2_slice_20180420_slice_2_cell_20180420_sample_2.nwb) ok
+(recording state in git...)
+
+$> ls -l
+total 4
+lrwxrwxrwx 1 yoh yoh 184 May  7 17:02 sub_mouse_AAYYT_ses_20180420_sample_2_slice_20180420_slice_2_cell_20180420_sample_2.nwb -> .git/annex/objects/Gj/9z/URL-s9335000--https&c%%girder.dandiarchive.org-48163bc503cb7181516be86ef215f923/URL-s9335000--https&c%%girder.dandiarchive.org-48163bc503cb7181516be86ef215f923
+"""]]]
+
+whenever original content-disposition was having "-" in the filename, which are perfectly safe the filename AFAIK:
+
+[[!format sh """
+$> wget -S https://girder.dandiarchive.org/api/v1/item/5e9f9588b5c9745bad9f58ff/download                
+... bunch of forwards to the final one with the content disposition field
+Resolving dandiarchive.s3.amazonaws.com (dandiarchive.s3.amazonaws.com)... 52.219.101.51
+Connecting to dandiarchive.s3.amazonaws.com (dandiarchive.s3.amazonaws.com)|52.219.101.51|:443... connected.
+HTTP request sent, awaiting response... 
+  HTTP/1.1 200 OK
+  x-amz-id-2: VgJE1jV5XUkBQXZDWgR5WEDfmHJp4Fj6fGo6z2tYkLfyTsxDWC+m92B2qOSVppCuiRFu2QpNV5M=
+  x-amz-request-id: 1221CAC30E3931CF
+  Date: Thu, 07 May 2020 21:02:52 GMT
+  Last-Modified: Wed, 22 Apr 2020 00:54:32 GMT
+  ETag: "acf3b4f5951435245a0efcd4a518e77d"
+  Content-Disposition: attachment; filename="sub-mouse-AAYYT_ses-20180420-sample-2_slice-20180420-slice-2_cell-20180420-sample-2.nwb"
+...
+
+$> git annex version
+git-annex version: 7.20190708+git9-gfa3524b95-1~ndall+1
+
+"""]]
+
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_1_6450f220a0d4252ceafdd82f0cc24486._comment b/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_1_6450f220a0d4252ceafdd82f0cc24486._comment
new file mode 100644
index 0000000000..29b8b82654
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_1_6450f220a0d4252ceafdd82f0cc24486._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-05-08T16:50:14Z"
+ content="""
+This is due to the filename being passed through sanitizeFilePath.
+
+There are security concerns here. If the filename contains "../"
+it absolutely has to be modified, or the command would have to fail and
+refuse the import it.
+
+If the filename contains an ANSI escape sequence, it could potentially
+lead to a security hole. Or if the filename starts with "-" it could be
+somewhere between a possible security hole and just very annoying to work
+with. As could a filename that contains a newline, which will
+break large quantities of shell pipelines. While generally git repos can
+have these problems with files in them too, the exposure seems larger when
+talking to some random web server than when pulling from a repo.
+
+Also, cross filesystem compatibility is a concern. It used to allow "|" in
+the filename, but a bug pointed out that cannot be used on fat filesystems.
+And "\\" means different things on linux and windows, so probably best to avoid
+filenames containing it on linux too.
+
+Finally, it's somewhat opinionated, since it replaces spaces with
+underscores. That's certainly the least defensible thing.
+
+(git-annex may also truncate the filename if it's longer than what the
+filesystem supports.)
+
+So, it's clearly wrong that it should be taken as-is without obfuscation,
+IMHO. Maybe there's a way to improve it to meet some use case though.
+
+I could see having a config that avoids sanitizing the filename, but
+makes addurl fail if the filename looks like a security problem. 
+
+Though that has the downside that git-annex would then need to
+comprehensively track, going forward, all the ways that people find to make
+filenames be a security problem; the current method, by being strict in
+what it lets through, probably limits expoits to ones involving a) unicode
+or b) the user's wetware.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_2_f787daed9b02af18b81f033cc2f84d0b._comment b/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_2_f787daed9b02af18b81f033cc2f84d0b._comment
new file mode 100644
index 0000000000..0e7b2f2d18
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_2_f787daed9b02af18b81f033cc2f84d0b._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-05-08T18:19:20Z"
+ content="""
+`git-annex import` does not do any sanitization, and that could be
+considered inconsistent, particularly when importing from a remote like S3.
+
+A difference with that is, it creates a remote tracking branch for the
+imported files. (That happens to avoid "../" path traversal because git
+generally avoids it.) Maybe the real difference is, import from a special
+remote is completely analagous to fetching from a git remote. So it feels
+different to me than adding an url does. 
+
+If I sync with a S3 bucket and it turns out it imported a escape sequence
+file, well I could have looked at the bucket first, or imported and
+reviewed the branch before merging it. And if I was syncing with a git
+remote the same thing could happen. So it feels like I should have no
+expectation git-annex would protect me. Whereis, if I add an url and the
+web server uses an obscure-ish http header to surprise me with a similar
+malicious filename, I had no way before hand to know that would happen, and
+so it does feel like git-annex should protect me.
+
+(Although if git did prevent that, git-annex should too, and I'd be
+fine with git preventing that.)
+"""]]
diff --git a/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_3_a1aeed36b8317144bc5df6fe7bcfd488._comment b/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_3_a1aeed36b8317144bc5df6fe7bcfd488._comment
new file mode 100644
index 0000000000..b09f93c9a4
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_3_a1aeed36b8317144bc5df6fe7bcfd488._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-05-08T19:56:27Z"
+ content="""
+Implemented git-annex addurl --preserve-filename, which will do what you
+want.
+
+Leaving this bug open because I only implemented it for web urls, not yet
+for torrents and other special remotes that have their own url scheme.
+The sanitization for those is currently done at a lower level than addurl,
+and so that will take a bit more work to implement.
+
+(importfeed does not, I think, need to implement this option, because
+the filenames are based on information from the rss feed, and it's
+perfectly fine to sanitize eg a podcast episode title to get a reasonable
+filename.)
+"""]]
diff --git a/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_4_a32f922bb12d6cfd96c5116b20cff828._comment b/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_4_a32f922bb12d6cfd96c5116b20cff828._comment
new file mode 100644
index 0000000000..e10003390c
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_4_a32f922bb12d6cfd96c5116b20cff828._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2020-05-09T22:10:43Z"
+ content="""
+> If the filename contains an ANSI escape sequence, it could potentially lead to a security hole.
+> ... As could a filename that contains a newline, which will break large quantities of shell pipelines. 
+
+IMHO those indeed are ok to target for sanitization
+
+> Or if the filename starts with \"-\" it could be somewhere between a possible security hole and just very annoying to work with.
+
+So why not to sanitize it only at the beginning of the filename?  
+`-` is a very common and a safe character to use within filename. For that matter we VERY frequently use `-` in filenames. It even became part of our BIDS standard in neuroimaging: https://bids-specification.readthedocs.io where we separate `_key` from `value`, e.g.in ` .  I really do not see why git-annex should so aggressively sanitize filenames as replacing \"-\" within filenames -- it makes nothing more secure or convenient.
+
+> While generally git repos can have these problems with files in them too, the exposure seems larger when talking to some random web server than when pulling from a repo.
+
+Well, not sure about ansi characters and new line symbols, but typically files are saved by the browsers with the name suggested by the server.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_5_fad1fe49c2c545aeeb388176d2f5a893._comment b/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_5_fad1fe49c2c545aeeb388176d2f5a893._comment
new file mode 100644
index 0000000000..99ebacee68
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/addurl__58___content-disposition_field_should_be_taken_as_is_without_obfuscation_/comment_5_fad1fe49c2c545aeeb388176d2f5a893._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-05-11T17:20:07Z"
+ content="""
+I agree that it may as well allow non-leading '-'. But, if you are relying
+on getting the unsanitized filename generally, you should use
+--preserve-filename
+
+Web browsers do do some santization, particulary of '/'.
+Chrome removes leading "." as well. Often files are downloaded
+without the user confirming it. I suspect there is enough insecurity
+in that area that someone could make a living injecting bitcoin miners into
+dotfiles.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages.mdwn b/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages.mdwn
new file mode 100644
index 0000000000..3ade4c1737
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages.mdwn
@@ -0,0 +1,6 @@
+While running `git-annex addurl --batch --with-files --jobs 10 --json --json-error-messages --json-progress --raw`, I occasionally run into files that fail to download for no discernable reason, and the `"error-messages"` key in the output from the command is an empty list.  This makes it hard to figure out exactly why the download is failing.
+
+[[!meta author=jwodder]]
+[[!tag projects/dandi]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_1_86b9cb50635c8ef8cf5918ab9a76d013._comment b/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_1_86b9cb50635c8ef8cf5918ab9a76d013._comment
new file mode 100644
index 0000000000..486a8cc69e
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_1_86b9cb50635c8ef8cf5918ab9a76d013._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-10-27T16:23:52Z"
+ content="""
+Is it reproducible with a particular url? Does it only happen with -J?
+
+Version would also be good to know. There were recent relevant 
+changes eg [[!commit 4f42292b13dc5a6664eeb19b5c9d48991eaef292]].
+
+I've spent a while hunting for a code path where it fails without
+displaying a warning, and have not found one. Since the code in addurl
+is structured as return Nothing and hopefully display a warning
+beforehand, rather than as throw an error, it's certianly possible that
+happens.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_2_2a151ccc0d9ef464df1452adc6ca449a._comment b/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_2_2a151ccc0d9ef464df1452adc6ca449a._comment
new file mode 100644
index 0000000000..5cda4b37a8
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_2_2a151ccc0d9ef464df1452adc6ca449a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jwodder"
+ avatar="http://cdn.libravatar.org/avatar/b06e01332c949b895c681cc92934f36a"
+ subject="comment 2"
+ date="2021-10-27T18:16:43Z"
+ content="""
+It appears that the problem occurs whenever one tries to download the same URL to two different paths at the same time.  When this occurs, one of the downloads fails, and though its \"error-messages\" is empty, its \"notes\" field reads, \"transfer already in progress, or unable to take transfer lock\".
+"""]]
diff --git a/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_3_1732be4c1d48acefcf3174cf8a7c8434._comment b/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_3_1732be4c1d48acefcf3174cf8a7c8434._comment
new file mode 100644
index 0000000000..01b9fb6538
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_3_1732be4c1d48acefcf3174cf8a7c8434._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jwodder"
+ avatar="http://cdn.libravatar.org/avatar/b06e01332c949b895c681cc92934f36a"
+ subject="comment 3"
+ date="2021-10-27T18:19:23Z"
+ content="""
+As to your questions, I am using git-annex 8.20211011 on macOS 11.6.  The problem does not occur when the `--jobs` option is omitted, but that's not viable for the current project we're using git-annex for.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_4_74e37e96d01bfb8b9521000d5faa7e53._comment b/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_4_74e37e96d01bfb8b9521000d5faa7e53._comment
new file mode 100644
index 0000000000..7411b045d1
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_4_74e37e96d01bfb8b9521000d5faa7e53._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-10-27T18:40:48Z"
+ content="""
+Aha, that makes sense! addurl constructs a url-based Key to use while
+downloading, and the key transfer machinery prevents redundant downloads
+of the same Key at the same time.
+
+Arguably, the problem is not where the message gets put, but that
+it fails when adding an url to two different paths at the same time.
+
+I have, though, moved that message so it will appear in error-messages.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_5_1b87390e69204b42878930cc1614437e._comment b/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_5_1b87390e69204b42878930cc1614437e._comment
new file mode 100644
index 0000000000..009320608e
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/addurl_failure_has_empty_error-messages/comment_5_1b87390e69204b42878930cc1614437e._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-10-27T18:56:23Z"
+ content="""
+The best solution I can find is for it to notice when another thread is
+downloading the same url, and wait until it finishes. Then proceed
+with downloading the url for a second time.
+
+It's not very satisfying to re-download. But once the url Key is downloaded,
+it does not keep that url Key populated, but hashes the content and moves
+the content to the final Key. It would be a real complication to
+communicate, across threads, what Key the content ended up at, and have the
+waiting thread use that. And addurl is already complicated well beyond a
+point I am comfortable with.
+
+Also, the content of an url can of course change over time. If I feed
+"$url foo" into git-annex addurl --batch -J10 and then some time
+later, I feed "$url bar", I might expect that file bar gets whatever
+content the url has now, not the content that the url had back when I added
+the same url to file foo. And if I cared about avoiding re-downloading,
+I could add the url to the first file, and then copy the annex link to the
+second file myself.
+
+Implemented this approach.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404.mdwn b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404.mdwn
new file mode 100644
index 0000000000..bb204ea9e7
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404.mdwn
@@ -0,0 +1,21 @@
+### Please describe the problem.
+
+This is a continuation to the [prior report/discussion](https://git-annex.branchable.com/bugs/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/#comment-424548e59fc41618ffeeb65f418694b3) to facilitate access to private repositories on public hosting portals.
+
+If we place more odd/custom behavior of gitlab etc installations which forward to login screen (thus no 401 or 404 response) upon attempt to access something which might be within private rep, aside, the situation with github and gogs (github clone) which powers gin (which I had [mentioned](https://git-annex.branchable.com/bugs/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/#comment-ec2193d97bb19945ad74cee13f747b35) in that prior discussion)) is different: they return 404 response.  And I think (didn't check git code, but just based on its behavior) `git` is then asking for credentials as the "next way to try".  I think git-annex should do the same -- if 404 received, ask `git credential` to fill for that domain (as it would do now in case of 401).
+
+### What steps will reproduce the problem?
+
+Try to clone and get data from a private repository on [https://gin.g-node.org/](https://gin.g-node.org/) (repo could be created, or let me know and I would create one, but you would still need to register there).  I am not yet 100% certain that upon authentication you would be able to fetch that `/config` (haven't tried).  Satellite issue/discussion I just initiated on gin is [here](https://github.com/G-Node/gogs/issues/111)
+
+### What version of git-annex are you using? On what operating system?
+
+8.20201127+git54-ga1b227171-1~ndall+1
+
+
+edit 1: although probably a deeper look into how/why git decides to ask for credentials for private repos might be due.  May be similar check should be done by git-annex first, since otherwise there might be no way to tell apart from a "proper" 404 for inability to get `/config` from github
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_1_aa0be7b60156b1b8a036081b36d120e0._comment b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_1_aa0be7b60156b1b8a036081b36d120e0._comment
new file mode 100644
index 0000000000..9de6dee891
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_1_aa0be7b60156b1b8a036081b36d120e0._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-01-21T16:57:06Z"
+ content="""
+The git source code does not appear to behave
+like that, see http.c `normalize_curl_result`, which reauths on 401, but 
+not on 404. If you think git behaves like this, you need to show an example
+where it clearly accesses an url that is 404 and goes on to authenticate.
+
+Seems to me that these hosting sites may simply not be exposing foo.git/config
+to http. Git does not request that file over http. Such a hosting site would
+probably also not expose foo.git/annex/ over http, so git-annex would not be
+able to use it anyway. To support git-annex, it would need to
+expose both, and then git-annex's handling of 401 should work fine for
+authentication.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_2_0bbf38af3012493cee0ada5248f32525._comment b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_2_0bbf38af3012493cee0ada5248f32525._comment
new file mode 100644
index 0000000000..733a5335b0
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_2_0bbf38af3012493cee0ada5248f32525._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2021-01-21T18:36:50Z"
+ content="""
+a quick one: https://gin.g-node.org/ does expose `foo.git/annex/` -- that is what gin has extended original borg with.  Example repo to try on https://gin.g-node.org/ljchang/Sherlock  . The problem/difficulty is only in access to \"private\" repositories -- access to config and annexed files is working fine through http 
+"""]]
diff --git a/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_3_d36533f093ced2a0fa5aa74de492b69f._comment b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_3_d36533f093ced2a0fa5aa74de492b69f._comment
new file mode 100644
index 0000000000..841702bafd
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_3_d36533f093ced2a0fa5aa74de492b69f._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-01-21T19:20:00Z"
+ content="""
+It still seems easy to demonstrate that git does not ask for creds on 404:
+
+	joey@darkstar:~> git clone http://google.com/this-url-does-not-exist
+	Cloning into 'this-url-does-not-exist'...
+	fatal: repository 'http://google.com/this-url-does-not-exist/' not found
+
+So I need you to show me what makes you think that git does such a strange
+thing, before I can take seriously a request to replicate that behavior in
+git-annex. Because the only possible reason I would implement such an
+insane thing is if git has lost its collective mind and so I needed to
+follow into the abyss.
+
+If the actual issue is that gogs has implemented support for git-annex,
+but that it sends 404 when git-annex requests config from a
+private repo, rather than 401, it seems to me the place to fix that is in
+gogs.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_4_7f8537172df5da79bdedd66bdc5cd231._comment b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_4_7f8537172df5da79bdedd66bdc5cd231._comment
new file mode 100644
index 0000000000..16aeabc5f0
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_4_7f8537172df5da79bdedd66bdc5cd231._comment
@@ -0,0 +1,112 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2021-01-22T01:47:46Z"
+ content="""
+yeap, it is not about 404 ... 
+
+<details>
+<summary>with gogs/gin situation is obscure but \"easyish\" - 401 is returned upon access to `/info/refs` but not above:</summary> 
+
+```shell
+$> wget -S \"https://gin.g-node.org/SakshamSharda/ophys_testing1.git/info/refs\"
+--2021-01-21 20:37:22--  https://gin.g-node.org/SakshamSharda/ophys_testing1.git/info/refs
+Resolving gin.g-node.org (gin.g-node.org)... 141.84.41.219
+Connecting to gin.g-node.org (gin.g-node.org)|141.84.41.219|:443... connected.
+HTTP request sent, awaiting response... 
+  HTTP/1.1 401 Unauthorized
+  Date: Fri, 22 Jan 2021 01:37:23 GMT
+  Server: Apache/2.4.38 (Debian)
+  content-type: text/plain
+  www-authenticate: Basic realm=\".\"
+  content-length: 0
+  set-cookie: lang=en-US; Path=/; Max-Age=2147483647
+  set-cookie: gnode_gin=823b677f19feb8ef; Path=/; HttpOnly
+  set-cookie: _csrf=GrekbiqDJleLLNcVyax5z77buGY6MTYxMTI3OTQ0MzYwMTMyMzE4NQ; Path=/; Expires=Sat, 23 Jan 2021 01:37:23 GMT
+  Keep-Alive: timeout=5, max=100
+  Connection: Keep-Alive
+
+Username/Password Authentication Failed.
+1 51975 ->6 [2].....................................:Thu 21 Jan 2021 08:37:23 PM EST:.
+(git)lena:~/proj/misc/git[master]git
+$> wget -S \"https://gin.g-node.org/SakshamSharda/ophys_testing1.git/info\"     
+--2021-01-21 20:37:52--  https://gin.g-node.org/SakshamSharda/ophys_testing1.git/info
+Resolving gin.g-node.org (gin.g-node.org)... 141.84.41.219
+Connecting to gin.g-node.org (gin.g-node.org)|141.84.41.219|:443... connected.
+HTTP request sent, awaiting response... 
+  HTTP/1.1 404 Not Found
+  Date: Fri, 22 Jan 2021 01:37:53 GMT
+  Server: Apache/2.4.38 (Debian)
+  content-type: text/html; charset=UTF-8
+  set-cookie: lang=en-US; Path=/; Max-Age=2147483647
+  set-cookie: gnode_gin=26d42c5108c8715d; Path=/; HttpOnly
+  set-cookie: _csrf=SAKUL4rdspufTb_lxEWIijnzYBU6MTYxMTI3OTQ3Mjk5MDczODgzMA; Path=/; Expires=Sat, 23 Jan 2021 01:37:52 GMT
+  Keep-Alive: timeout=5, max=100
+  Connection: Keep-Alive
+  Transfer-Encoding: chunked
+2021-01-21 20:37:53 ERROR 404: Not Found.
+
+
+```
+</details>
+
+
+github is ... trickier, or to say -- my C/gdb/whatever foo is not good enough, since
+
+<details>
+<summary>it is still 404 with simple wget but git remote-https seems to get 401:</summary> 
+
+```shell
+(gdb) p results
+$15 = {curl_result = CURLE_HTTP_RETURNED_ERROR, http_code = 401, auth_avail = 1, http_connectcode = 0}
+(gdb) p rl
+No symbol \"rl\" in current context.
+(gdb) p url
+$16 = 0x5555557a4450 \"https://github.com/yarikoptic/abcd-testds2/info/refs?service=git-upload-pack\"
+(gdb) bt
+#0  http_request (url=0x5555557a4450 \"https://github.com/yarikoptic/abcd-testds2/info/refs?service=git-upload-pack\", 
+    result=<optimized out>, target=<optimized out>, options=0x7fffffffd920) at http.c:1981
+#1  0x00005555555665bf in http_request_reauth (
+    url=0x5555557a4450 \"https://github.com/yarikoptic/abcd-testds2/info/refs?service=git-upload-pack\", result=0x7fffffffd880, 
+    target=0, options=0x7fffffffd920) at http.c:2040
+#2  0x000055555555f7f3 in discover_refs (service=<optimized out>, service@entry=0x5555556b622c \"git-upload-pack\", 
+    for_push=for_push@entry=0) at remote-curl.c:493
+#3  0x000055555556137e in get_refs (for_push=<optimized out>) at remote-curl.c:548
+#4  cmd_main (argc=argc@entry=3, argv=argv@entry=0x7fffffffdcd8) at remote-curl.c:1523
+#5  0x000055555555ee94 in main (argc=3, argv=0x7fffffffdcd8) at common-main.c:52
+
+```
+
+```
+$> wget --header \"Git-Protocol: version=2\" --header \"Pragma: no-cache\" -S 'https://github.com/yarikoptic/abcd-testds2/info/refs?service=git-upload-pack' 
+--2021-01-21 20:41:21--  https://github.com/yarikoptic/abcd-testds2/info/refs?service=git-upload-pack
+Resolving github.com (github.com)... 140.82.114.3
+Connecting to github.com (github.com)|140.82.114.3|:443... connected.
+HTTP request sent, awaiting response... 
+  HTTP/1.1 404 Not Found
+  Server: GitHub.com
+  Date: Fri, 22 Jan 2021 01:41:21 GMT
+  Content-Type: text/plain; charset=utf-8
+  Status: 404 Not Found
+  Vary: X-PJAX, Accept-Encoding, Accept, X-Requested-With
+  Cache-Control: no-cache
+  Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
+  X-Frame-Options: deny
+  X-Content-Type-Options: nosniff
+  X-XSS-Protection: 1; mode=block
+  Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
+  Expect-CT: max-age=2592000, report-uri=\"https://api.github.com/_private/browser/errors\"
+  Content-Security-Policy: default-src 'none'; base-uri 'self'; connect-src 'self'; form-action 'self'; img-src 'self' data:; script-src 'self'; style-src 'unsafe-inline'
+  Set-Cookie: _gh_sess=UoF3mYOvfYf5mFbK1tr7aWOuYpQbNoJVhajA5nr2ANUvg%2FekQjtgh0h3xLva0EcwHnLNNsl7VMEdVLXNGi9Yn4AbjrBxX0sdo51DL1XQYR%2Bm3ZeS71I7keexEnrZspp%2FQxaT7cJpceXr7ZrKg2HwJu8dMo%2Bcz13Vr%2F9p7MtZ6cIjUMMF3ql8GX%2BYO949RdgS31KNBb1Ln917v7GlLaZhbejgGAYJOFI2YMuWhs3WkZxOZCMy1JnW%2Bbp3OcdyffBt0ToaKaLcUx1mt6kzzOb4Ow%3D%3D--FD5dTEIs8HUBjIdH--P%2B86pTRJ%2FwWUndICVXAaNA%3D%3D; Path=/; HttpOnly; Secure; SameSite=Lax
+  Set-Cookie: _octo=GH1.1.1513753117.1611279681; Path=/; Domain=github.com; Expires=Sat, 22 Jan 2022 01:41:21 GMT; Secure; SameSite=Lax
+  Set-Cookie: logged_in=no; Path=/; Domain=github.com; Expires=Sat, 22 Jan 2022 01:41:21 GMT; HttpOnly; Secure; SameSite=Lax
+  Content-Length: 9
+  X-GitHub-Request-Id: 8F40:2881:CD3AD3:1222997:600A2D41
+2021-01-21 20:41:21 ERROR 404: Not Found.
+```
+
+</details>
+
+but overall the point is that git does seems to get 401 with auth availability (although I failed to dig out how exactly it gets it).  So I will leave it to the experts to figure out how
+"""]]
diff --git a/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_5_1993718701b7ad180ec683f80c87003f._comment b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_5_1993718701b7ad180ec683f80c87003f._comment
new file mode 100644
index 0000000000..97dc876b8c
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_5_1993718701b7ad180ec683f80c87003f._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-01-22T18:36:50Z"
+ content="""
+These possibilities seem about equally likely to me:
+
+1. gogs has not implemented authed access to the files git-annex needs
+   for private repositories
+2. gogs has a bug where it returns 404 rather than 401 when not authed,
+   but serves the files up when authed.
+
+So why try to work around it in git-annex when it's a coin flip whether
+git-annex can at all, when in either case there's clearly a bug in gogs,
+and is specifically in code in gogs that is intended to support git-annex?
+
+github has a bad habit of using user-agent to make urls do different
+things when git accesses them than when other http clients do. That is the
+case in your example; use wget -U git/1 and it will 401. But I don't
+see how that's relevant, since git-annex does not talk to github except for
+a) via git and b) via its git-lfs implementation (which supports http basic
+auth although I can't remember if I tested it against github's server or only
+other servers like gitlab). 
+
+If github's lfs endpoint did do user-agent sniffing, IMHO that would
+violate their spec, but also yeah, I'd probably put in some appropiately
+snarky fake user-agent in git-annex there. But not in general, and none of
+this says git-annex should be treating 404 like 401.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_6_a84145c6537ac1a81db59cdc03bc625d._comment b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_6_a84145c6537ac1a81db59cdc03bc625d._comment
new file mode 100644
index 0000000000..1d1fd5c8f3
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_6_a84145c6537ac1a81db59cdc03bc625d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2021-01-25T15:18:39Z"
+ content="""
+THANK YOU Joey.  That is indeed quite odd (\"security through obscurity\") behavior from github (note: github returns 401 even if that repo does not exist, so it is at least consistent in not revealing presence/absence of private repos at a url). Feel welcome to close this issue since I guess nothing should indeed be done on git-annex side, and ideally `gin` portal just returns 401 in such cases
+"""]]
diff --git a/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_7_3fd3445beec2a6cc6e8c71bd8e90cc83._comment b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_7_3fd3445beec2a6cc6e8c71bd8e90cc83._comment
new file mode 100644
index 0000000000..cfce6da314
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/be_like_git_and_ask_for_credentials_if_404/comment_7_3fd3445beec2a6cc6e8c71bd8e90cc83._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-01-28T16:37:59Z"
+ content="""
+github's rationalle for the sniffing, such as it is, is that an url to a
+git repository lets you view it in the web ui, and the same url can be
+cloned by git.
+
+Agreed, I'll close this in git-annex, and they can fix it in gin.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy.mdwn b/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy.mdwn
new file mode 100644
index 0000000000..053f4319f2
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy.mdwn
@@ -0,0 +1,88 @@
+### Please describe the problem.
+
+decided to test annex on a new to me file system -- beegfs
+
+```
+$> mount | grep beegfs
+beegfs_nodev on /mnt/beegfs type beegfs (rw,relatime,cfgFile=/etc/beegfs/beegfs-client.conf,_netdev)
+
+```
+
+```
+$> modinfo beegfs
+filename:       /lib/modules/5.4.0-77-generic/updates/fs/beegfs_autobuild/beegfs.ko
+version:        7.2.2
+alias:          fs-beegfs
+author:         Fraunhofer ITWM, CC-HPC
+description:    BeeGFS parallel file system client (http://www.beegfs.com)
+license:        GPL v2
+srcversion:     533BB7E5866E52F63B9ACCB
+depends:        ib_core,rdma_cm
+retpoline:      Y
+name:           beegfs
+vermagic:       5.4.0-77-generic SMP mod_unload modversions
+
+```
+
+### What steps will reproduce the problem?
+
+1. get beegfs
+
+2.
+```
+leviathan:/mnt/beegfs/yoh/tmp
+$> TMPDIR=$PWD/annex-tmp git annex test
+```
+
+
+### What version of git-annex are you using? On what operating system?
+
+```
+leviathan:/mnt/beegfs/yoh/tmp
+$> git annex version
+git-annex version: 8.20210621-g91f9aac
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+```
+
+### Please provide any additional information below.
+
+looking in detail -- it seems it is not init, but addurl (but subject is set in stone now, can't edit) -- got mislead I guess by the interleaving stdout/err:
+
+[[!format sh """
+    addurl:                                               FAIL (2.79s)
+Init Tests
+  init:       ./Test/Framework.hs:57:
+      addurl on file:///mnt/beegfs/yoh/tmp/.t/tmprepo96/myurl failed (transcript follows)
+(to _mnt_beegfs_yoh_tmp_.t_tmprepo96_myurl) git-annex: .git/annex/tmp/URL-s3--file&c%%%mnt%beegfs%yoh%tmp%.t%tmprepo96%myurl: renameFile:renamePath:rename: resource busy (Device or resource busy)failedaddurl: 1 failed
+
+...
+    addurl:                                               FAIL (1.86s)
+      ./Test/Framework.hs:57:
+      addurl on file:///mnt/beegfs/yoh/tmp/.t/tmprepo193/myurl failed (transcript follows)
+(to _mnt_beegfs_yoh_tmp_.t_tmprepo193_myurl) git-annex: .git/annex/tmp/URL-s3--file&c%%%mnt%beegfs%yoh%tmp%.t%tmprepo193%myurl: renameFile:renamePath:rename: resource busy (Device or resource busy)failedaddurl: 1 failed
+Init Tests
+...
+    addurl:                                               FAIL (2.29s)
+      ./Test/Framework.hs:57:
+      addurl on file:///mnt/beegfs/yoh/tmp/.t/tmprepo293/myurl failed (transcript follows)
+(to _mnt_beegfs_yoh_tmp_.t_tmprepo293_myurl) git-annex: .git/annex/tmp/URL-s3--file&c%%%mnt%beegfs%yoh%tmp%.t%tmprepo293%myurl: renameFile:renamePath:rename: resource busy (Device or resource busy)failedaddurl: 1 failed
+
+3 out of 984 tests failed (1776.96s)
+
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+on days ending with `y` it seems to work quite nicely.
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[fixed|done]], I think, though have not installed beegfs to test.
+> --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_1_0c17cba36b1feddc956e0075f73536ed._comment b/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_1_0c17cba36b1feddc956e0075f73536ed._comment
new file mode 100644
index 0000000000..92dc5835b7
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_1_0c17cba36b1feddc956e0075f73536ed._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-07-02T14:26:34Z"
+ content="""
+       EBUSY  The rename fails because oldpath or new‐
+              path  is  a  directory that is in use by
+              some process (perhaps as current working
+              directory,  or as root directory, or be‐
+              cause it was open for reading) or is  in
+              use  by the system (for example as mount
+              point), while the system considers  this
+              an  error.   (Note  that there is no re‐
+              quirement to return EBUSY in such cases—
+              there  is  nothing  wrong with doing the
+              rename anyway—but it is allowed  to  re‐
+              turn  EBUSY  if the system cannot other‐
+              wise handle such situations.)
+
+".git/annex/tmp/URL-s3--file&c%%%mnt%beegfs%yoh%tmp%.t%tmprepo193%myurl"
+is not a directory, it is a file. So, rename seems to have no business failing
+in this way. Probably the FS is buggy.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_2_33143a5f2467c58201496c8f59532b53._comment b/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_2_33143a5f2467c58201496c8f59532b53._comment
new file mode 100644
index 0000000000..8c38c9e370
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_2_33143a5f2467c58201496c8f59532b53._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2021-07-04T03:27:20Z"
+ content="""
+Thank you Joey!  indeed most likely a \"too fancy\" of a file system.
+
+On [https://www.beegfs.io/release/beegfs_6/Changelog.txt](https://www.beegfs.io/release/beegfs_6/Changelog.txt) I found 
+
+
+```
+== Changes in 6.11 (release date: 2017-05-26) ==
+
+General Changes:
+
+* client: Add option sysRenameEbusyAsXdev to return EXDEV instead of EBUSY if
+  rename() is called on open files. (Tools like \"mv\" can handle EXDEV as return
+  value.)
+```
+
+do you think EXDEV would be worked out Ok if that is the culprit? (meanwhile I will let the beegfs users know as well - may be they could try)
+
+"""]]
diff --git a/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_3_1241df23fa4861554cf9a5d65235c8a1._comment b/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_3_1241df23fa4861554cf9a5d65235c8a1._comment
new file mode 100644
index 0000000000..17084e83a4
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_3_1241df23fa4861554cf9a5d65235c8a1._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-07-05T16:18:39Z"
+ content="""
+I've checked with strace, to see if the file was open while it was being
+renamed. Not that there is anything generally wrong with renaming an open
+file on a POSIX file system, but it would possibly be a problem on windows,
+where some forms of opening a file locks it in place. And apparently
+this filesystem is not trying to be very POSIX either.
+
+	413026 openat(AT_FDCWD, ".git/annex/tmp/URL-s3--file&c%%%tmp%foo", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 17
+	413026 write(17, "hi\n", 3)             = 3
+	413026 close(17)                        = 0
+	...
+	413026 openat(AT_FDCWD, ".git/annex/tmp/URL-s3--file&c%%%tmp%foo", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11
+	413026 read(11, "hi\n", 8192)           = 3
+	...
+	413026 openat(AT_FDCWD, ".git/annex/tmp/URL-s3--file&c%%%tmp%foo", O_RDONLY|O_NOCTTY|O_NONBLOCK <unfinished ...>
+	413028 <... futex resumed>)             = 0
+	413026 <... openat resumed>)            = 16
+	...
+	413026 read(16, "hi\n", 32752)          = 3
+	...
+	413026 close(16)                        = 0
+	...
+	413026 rename(".git/annex/tmp/URL-s3--file&c%%%tmp%foo", "_tmp_foo") = 0
+	...
+	413028 close(11)                        = 0
+
+So the file is left open across the rename, which ought to be able to be
+changed and would presumably fix the problem.
+
+It's also a bit odd that the file gets read twice after being copied,
+once for checksum makes sense, but what's the other one?
+(Copying while checksumming should be able to avoid one of the reads,
+but there is an open todo tracking progress on that.)
+
+Aah, the other read is when it's probing if the file is html in case it ought
+to be passed off to youtube-dl. That is the read that lingers for a while,
+because it's done with a lazy readFile and probing if the file is html doesn't
+read to the end and close it, so the file handle lingers until the GC gets
+around to closing it. Of course youtube-dl won't be able to do anything with a
+file url, but git-annex doesn't know that. And anyway the failure on this
+filesystem would also happen when adding a http url.
+
+Ok, fixed it to close the handle promptly. That should fix the test suite.
+It does not seem unlikely that something else will break due to this 
+filesystem's unusual behavior though.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_4_8c64d10dbfcd8189465affbf5329c63e._comment b/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_4_8c64d10dbfcd8189465affbf5329c63e._comment
new file mode 100644
index 0000000000..1dd7f05a47
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/beegfs__58___init_tests_FAIL_resource_busy/comment_4_8c64d10dbfcd8189465affbf5329c63e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-07-05T17:17:59Z"
+ content="""
+Also looked over other uses of readFile. While there are a couple that
+don't read the whole file and so may have a lag closing, none of them are
+files that are used in ways that seem likely to trigger this kind of
+problem.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks.mdwn b/doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks.mdwn
new file mode 100644
index 0000000000..4bb67de230
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+
+Probably it is more of a todo than a bug.
+
+### What steps will reproduce the problem?
+
+This is a use-case where I am trying to establish a special remote to be shared by multiple unrelated repositories.
+
+So I had original repo1 in which I
+
+- created an external special remote with chunking, it got UUID1
+- uploaded some data (all got chunked)
+
+created repo2 in which I
+
+- initialized special remote with identical settings and provided `uuid=UUID1`
+- decided to test if annex would be able to get a key from the shared special remote
+
+but `annex fsck --key KEY --from remote --fast`, since it doesn't have an exact chunking list, just provides special remote backend with original full key only, which is obviously not found, and it reports failure.   But I wondered -- couldn't `git-annex` just use chunking size and "mint" possible chunked-keys to test on the special remote since it has all the information?  After all chunk keys AFAIK are deterministically minted and pretty much are just "augmented" original key with `-S<chunksize>-C<chunkindex>` added to the key.
+
+### What version of git-annex are you using? On what operating system?
+
+8.20200908+git175-g95d02d6e2-1~ndall+1
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks/comment_1_5d11bb90105b4d0cf14f85e6d8795023._comment b/doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks/comment_1_5d11bb90105b4d0cf14f85e6d8795023._comment
new file mode 100644
index 0000000000..5fc15354d9
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks/comment_1_5d11bb90105b4d0cf14f85e6d8795023._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-10-22T16:09:17Z"
+ content="""
+Note that what you are trying to do will only work if the special remote
+is not encrypted.
+
+As well as your use case, which seems very unusual, I think one other use
+case would be if a clone uploaded to the special remote, but never synced
+out its git-annex branch before being lost, and fsck --from
+remote is being run in another clone to reconstruct it. Currently it
+won't try chunks as none are recorded.
+
+Speculatively trying the current remote's chunk config would handle the
+majority of cases, though wouldn't help if the other clone had adjusted the
+special remote's chunk size too.
+
+There's some overhead, but it can check it last, and not check it if
+it's in the list of known chunks, so the overhead would only usually 
+be paid if the content git-annex expected to be present had gone missing,
+which I think is rare enough to not care about.
+
+(Also, this can only be done when the size of the key is known, so not
+eg addurl --relaxed keys.)
+"""]]
diff --git a/doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks/comment_2_f48e4d3571a8fc2b45fbaad7a9f8fb60._comment b/doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks/comment_2_f48e4d3571a8fc2b45fbaad7a9f8fb60._comment
new file mode 100644
index 0000000000..5924108ca3
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks/comment_2_f48e4d3571a8fc2b45fbaad7a9f8fb60._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-10-22T17:00:25Z"
+ content="""
+Implemented that. But..
+
+As implemented, there's nothing to make the chunk size get stored in the
+chunk log for a key, after it accesses its content using the configured
+chunk size.
+
+So, changing the chunk= of the remote can prevent accessing content that
+was accessible before. Of course, avoiding that is why chunk sizes are
+logged in the first place.
+
+Seems like maybe fsck --from should fix the chunk log? I think
+fsck would always need to be used, to fix up the location log, before any
+other commands rely on the data being in the special remote, so it seems
+fine to only fix the chunk log there.
+
+But, also a bit unclear how fsck would find out when it needs to do this.
+It only needs to when the remote's configured chunk size is not
+listed in the chunk log. But that's also common after changing the chunk
+size of a remote. So it would have to mess around with checking the
+presence of chunk keys itself, which would be extra work and also ugly
+to implement.
+
+I'm leaving this todo^Wbug open for now due to this.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks/comment_3_ff3bcc2cce6e0cbbeef10a187541f5d3._comment b/doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks/comment_3_ff3bcc2cce6e0cbbeef10a187541f5d3._comment
new file mode 100644
index 0000000000..dff49bbd6c
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/fsck_--key_without___34__chunking__34___information_in_git-annex_does_not_try_chunks/comment_3_ff3bcc2cce6e0cbbeef10a187541f5d3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-10-22T17:36:12Z"
+ content="""
+Ok, made update the chunk log as needed while checking if chunks are
+present. So this is done.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/git-lfs_remote_URL_is_not_recorded__63__.mdwn b/doc/projects/dandi/bugs-done/git-lfs_remote_URL_is_not_recorded__63__.mdwn
new file mode 100644
index 0000000000..04784716bb
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/git-lfs_remote_URL_is_not_recorded__63__.mdwn
@@ -0,0 +1,119 @@
+### Please describe the problem.
+
+I was trying to follow https://git-annex.branchable.com/special_remotes/git-lfs/ (only without any encryption), to store at least some data on github via LFS (e.g., for https://github.com/dandi-datasets/nwb_test_data). 
+
+Even though I do provide URL to the `annex initremote` call, it is not stored within `remote.log`:
+
+
+[[!format sh """
+$> sudo rm -rf /tmp/testds2 && ( mkdir /tmp/testds2 && cd /tmp/testds2 && git init && git annex init && git annex initremote gh-lfs autoenable=true type=git-lfs url=git@github.com:yarikoptic/testds2.git encryption=none && git show git-annex:remote.log; )                                                                                  
+Initialized empty Git repository in /tmp/testds2/.git/
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
+initremote gh-lfs ok
+(recording state in git...)
+c9132e68-e9d8-40b5-ba34-5d60a8b9c844 autoenable=true encryption=none name=gh-lfs type=git-lfs timestamp=1570642576.06742667s
+
+"""]]
+
+git annex 7.20190912-1~ndall+1
+
+
+If I just proceed, populate and copy some data via lfs (example uses datalad's `create-sibling-github` to create a new repo): 
+
+[[!format sh """
+$> ( cd /tmp/testds2 && touch 123 && git annex add 123 && git commit -m 'add 123' && datalad create-sibling-github -s origin testds2 && git push -u origin master && git annex copy --to=gh-lfs 123; git push origin git-annex; )                                                                                       
+add 123                                                                                      
+ok
+(recording state in git...)
+[master (root-commit) d2b2f52] add 123
+ 1 file changed, 1 insertion(+)
+ create mode 120000 123
+[WARNING] Authentication failed using a token. 
+.: origin(-) [https://github.com/yarikoptic/testds2.git (git)]
+'https://github.com/yarikoptic/testds2.git' configured as sibling 'origin' for <Dataset path=/tmp/testds2>
+Enumerating objects: 3, done.
+Counting objects: 100% (3/3), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (2/2), done.
+Writing objects: 100% (3/3), 307 bytes | 307.00 KiB/s, done.
+Total 3 (delta 0), reused 0 (delta 0)
+To github.com:yarikoptic/testds2.git
+ * [new branch]      master -> master
+Branch 'master' set up to track remote branch 'master' from 'origin'.
+copy 123 (to gh-lfs...) 
+ok
+(recording state in git...)
+Enumerating objects: 19, done.
+Counting objects: 100% (19/19), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (15/15), done.
+Writing objects: 100% (19/19), 1.66 KiB | 567.00 KiB/s, done.
+Total 19 (delta 4), reused 0 (delta 0)
+remote: Resolving deltas: 100% (4/4), done.
+remote: 
+remote: Create a pull request for 'git-annex' on GitHub by visiting:
+remote:      https://github.com/yarikoptic/testds2/pull/new/git-annex
+remote: 
+To github.com:yarikoptic/testds2.git
+ * [new branch]      git-annex -> git-annex
+
+"""]]
+
+on a new clone I get a complaint that `url=` is missing, and no data is fetched
+
+[[!format sh """
+$> sudo rm -rf testds2-clone && git clone git@github.com:yarikoptic/testds2.git testds2-clone && ( cd testds2-clone && git annex init && git annex get 123; )    
+Cloning into 'testds2-clone'...
+remote: Enumerating objects: 22, done.
+remote: Counting objects: 100% (22/22), done.
+remote: Compressing objects: 100% (13/13), done.
+remote: Total 22 (delta 5), reused 21 (delta 4), pack-reused 0
+Receiving objects: 100% (22/22), done.
+Resolving deltas: 100% (5/5), done.
+123@
+init  (merging origin/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+Invalid command: 'git-annex-shell 'configlist' '/~/yarikoptic/testds2.git''
+  You appear to be using ssh to clone a git:// URL.
+  Make sure your core.gitProxy config option and the
+  GIT_PROXY_COMMAND environment variable are NOT set.
+
+  Remote origin does not have git-annex installed; setting annex-ignore
+
+  This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote origin
+(Auto enabling special remote gh-lfs...)
+
+  Specify url=
+ok
+(recording state in git...)
+get 123 (not available) 
+  Try making some of these repositories available:
+  	92ce3cfc-8c58-42db-8aa3-ea4d4b3a6011 -- yoh@hopa:/tmp/testds2
+   	c9132e68-e9d8-40b5-ba34-5d60a8b9c844 -- gh-lfs
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+git-annex: get: 1 failed
+"""]]
+
+so I had to enableremote it while providing URL I become able to `get` the file:
+
+[[!format sh """
+$> git annex enableremote gh-lfs autoenable=true type=git-lfs url=git@github.com:yarikoptic/testds2.git encryption=none && git annex get 123                                         
+enableremote gh-lfs ok      
+(recording state in git...)
+get 123 (from gh-lfs...) 
+(checksum...) ok
+(recording state in git...)
+"""]]
+
+
+Shouldn't that URL be recorded in remote.log? (similarly to `type=git` remotes)
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[done]]; see my comment --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/git-lfs_remote_URL_is_not_recorded__63__/comment_1_e2bcd52490fc04850738b72255692e32._comment b/doc/projects/dandi/bugs-done/git-lfs_remote_URL_is_not_recorded__63__/comment_1_e2bcd52490fc04850738b72255692e32._comment
new file mode 100644
index 0000000000..320b95edae
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/git-lfs_remote_URL_is_not_recorded__63__/comment_1_e2bcd52490fc04850738b72255692e32._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-10-21T19:07:42Z"
+ content="""
+That is intentional, because a git-lfs remote can have multiple urls that
+can access it, and different users of the remote might want to use
+different urls.
+
+It's also documented to work that way, the same as the directory
+special remote documents that you have to provide directory= each time it's
+enabled.
+
+But, now that git-annex supports sameas remotes, it would be possible to
+have one special remote for each different url to a given git-lfs remote,
+and have git-annex know they're the same repository. The user can then
+enableremote whichever one they want.
+
+See [[todo/git-lfs_special_remote_simpler_setup]] for where I hope this
+will lead.
+
+Closing this bug report as redundant with that todo item, and not actually a
+bug since it is documented to behave the way it currently behaves.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place.mdwn b/doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place.mdwn
new file mode 100644
index 0000000000..869594e70f
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place.mdwn
@@ -0,0 +1,49 @@
+### Please describe the problem.
+
+I am trying to import (and then reimport) a directory which I sync to from box.com shared with me folder.
+I have used `--duplicate` option to not delete original files upon `import`.  But then upon-rerunning `import` command git-annex would error out if file already exists.  `--reinject-duplicates` seems to be the option to use, but all those modes are "exclusive" so I cannot use `--duplicate --reinject-duplicates`, and using `--reinject-duplicates` alone would result in removing original files (as without `--duplicates`)
+
+### What version of git-annex are you using? On what operating system?
+
+7.20190819+git2-g908476a9b-1~ndall+1
+
+### Please provide any additional information below.
+
+my little demo snippet for import with using --duplicate and then both options at the same time:
+
+[[!format sh """
+$> mkdir /tmp/d-in /tmp/d-repo && touch /tmp/d-in/file && ( cd /tmp/d-repo && git init && git annex init && for r in 1 2; do echo "Run $r";  ls -l ../d-in && git annex import --duplicate ../d-in/.; done )  
+Initialized empty Git repository in /tmp/d-repo/.git/
+init  ok
+(recording state in git...)
+Run 1
+total 0
+-rw------- 1 yoh yoh 0 Oct 14 10:51 file
+import ./file ok
+(recording state in git...)
+Run 2
+total 0
+-rw------- 1 yoh yoh 0 Oct 14 10:51 file
+import ./file 
+  not overwriting existing ./file (is a symlink)
+failed
+git-annex: import: 1 failed
+
+
+$> cd d-repo 
+$> git annex import ../d-in/. --reinject-duplicates --duplicate 2>&1 | head -n 3                                                                                                                           
+Invalid option `--duplicate'                                                    
+
+Usage: git-annex COMMAND
+
+"""]]
+
+
+Or may be there is a better way to establish re-runnable import from a directory workflow?
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+[[!tag moreinfo]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place/comment_1_d385d0fffdd6ac18f38828f805e4daff._comment b/doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place/comment_1_d385d0fffdd6ac18f38828f805e4daff._comment
new file mode 100644
index 0000000000..a34534e6f5
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place/comment_1_d385d0fffdd6ac18f38828f805e4daff._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-11-19T17:12:41Z"
+ content="""
+I think that you can accomplish what you want by making the directory
+you're importing from be a directory special remote with exporttree=yes
+importtree=yes and use the new `git annex import master --from remote`
+
+If that does not do what you want, I'd prefer to look at making it be able
+to do so. I hope to eventually remove the legacy git-annex import from
+directory, since we have this new more general interface.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place/comment_2_0c6006b53f97515c1ed31d8d4ab464cc._comment b/doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place/comment_2_0c6006b53f97515c1ed31d8d4ab464cc._comment
new file mode 100644
index 0000000000..e133b8b30e
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place/comment_2_0c6006b53f97515c1ed31d8d4ab464cc._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-03-30T15:50:17Z"
+ content="""
+Tagged moreinfo since I'm waiting on a reply to my suggestion.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place/comment_3_300f74178ef17e2e549fd7a04a262428._comment b/doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place/comment_3_300f74178ef17e2e549fd7a04a262428._comment
new file mode 100644
index 0000000000..76afcc3b47
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place/comment_3_300f74178ef17e2e549fd7a04a262428._comment
@@ -0,0 +1,59 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2020-10-06T01:26:59Z"
+ content="""
+I think it worked wonderfully
+
+<details>
+<summary>here is my script I have tried</summary> 
+
+```shell
+#!/bin/bash
+
+export PS4='> '
+set -x
+set -eu
+cd \"$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)\"
+
+mkdir d-in d-repo 
+echo content >| d-in/file 
+
+function dance() {
+    git annex import master --from d-in
+    # but we need to merge it
+    git merge d-in/master
+    ls -l
+    grep -e . *
+}
+
+( 
+cd d-repo 
+git init
+git annex init 
+git annex initremote d-in type=directory directory=../d-in exporttree=yes importtree=yes encryption=none
+
+ls -l ../d-in
+
+for r in 1 2; do 
+   echo \"Run $r\";  
+   dance
+done 
+
+echo \"more\" >> ../d-in/file
+echo \"new\" > ../d-in/newfile
+dance
+
+rm ../d-in/file
+dance
+
+)
+
+```
+</details>
+
+and it seemed to do the right job!  I have not tried to add some `.gitattributes` into that branch it imports into to tell some files to go to git, but I hope it would just work, and if not -- I will come back!  feel welcome to close this issue.
+
+Cheers
+"""]]
diff --git a/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason.mdwn b/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason.mdwn
new file mode 100644
index 0000000000..fad43f305c
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason.mdwn
@@ -0,0 +1,70 @@
+### Please describe the problem.
+
+
+[original question raised by John](https://github.com/dandi/dandisets/issues/139#issuecomment-1149948239) which lead me to the goose chase.
+
+Following reproducer
+
+```
+#!/bin/bash
+
+cd "$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)"
+set -eux
+
+git init --bare remote
+( cd remote; git annex init; cat config )
+rpath=$PWD/remote
+
+git init repo
+cd repo
+git annex init
+echo 'This is test text.' > file.txt
+git add file.txt
+git commit -m Init file.txt
+
+git remote add --fetch remote-git $rpath
+
+# without this -- there is no annex-uuid for  remote -- git-annex branch is not getting merged
+git annex info
+
+cat .git/config
+
+# but this still fails
+git annex initremote testremote type=git location=$rpath autoenable=true
+
+```
+
+ends with
+
+```
+[remote "remote-git"]
+	url = /home/yoh/.tmp/dl-VjO0aSF/remote
+	fetch = +refs/heads/*:refs/remotes/remote-git/*
+	annex-uuid = afdc6d54-cd6d-4a20-b639-a639f9c7ef09
++ git annex initremote testremote type=git location=/home/yoh/.tmp/dl-VjO0aSF/remote autoenable=true
+initremote testremote 
+git-annex: could not find existing git remote with specified location
+failed
+initremote: 1 failed
+
+```
+
+so
+
+- error "could not find existing git remote with specified location" seems not descriptive of the underlying problem since location matches the url. Underlying issue is still not clear why we can't initremote
+- as you could see in the script - need `annex info` to have annex-uuid populated and looking at [code ](https://git.kitenet.net/index.cgi/git-annex.git/tree/Remote/Git.hs?id=af0d854460c28230dc682faa7c6daf3d96698cb6#n110) comment -- it requires UUID to be known. If not known -- ideally should be a dedicated error message ("remote blah found but lacks uuid, check if remote is annex")
+- IMHO should not need manual `annex info` to merge git-annex branch
+
+
+### What steps will reproduce the problem?
+
+above
+
+### What version of git-annex are you using? On what operating system?
+
+10.20220504
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_1_182b9cc42f7287c8b022422404fc74b7._comment b/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_1_182b9cc42f7287c8b022422404fc74b7._comment
new file mode 100644
index 0000000000..3421df727b
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_1_182b9cc42f7287c8b022422404fc74b7._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-06-08T16:55:50Z"
+ content="""
+Hmm, I think this only works for ssh:// urls currently.
+
+Even the ssh url form host:/path does not work, because it gets
+normalized to a ssh:// url.
+
+The implementation does not support non-url's at all; the provided location
+is treated as an url (`Git.Url location`). And even if it were treated as a
+path, the path gets normalized to a relative path and an absolute path (or
+differently relavatized path) would not work.
+
+Using paths with this is rather problematic too, because if the repo is
+cloned to another machine, it would not find the repo at the recorded path.
+Similarly, relative paths are also problimatic. But it may as well support
+them to the extent it can.
+
+I think this needs changes to the core Git data structure, to store the
+original, unmodified git.remote.path. Or a different interface than the
+current, one that accepts any repo location and probes it to find the uuid.
+The latter idea seems better because it simplifies the UI rather than
+complicating the internal representation.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_2_0baadee49b21451a99a38306a98e3e56._comment b/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_2_0baadee49b21451a99a38306a98e3e56._comment
new file mode 100644
index 0000000000..c77c55a34f
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_2_0baadee49b21451a99a38306a98e3e56._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-06-09T17:04:23Z"
+ content="""
+Implemented probing of the uuid of the repo location. Which may change
+how you use this feature. Although the old roundabout method of having an
+existing git remote and running initremote with the same location will
+work too, it's not neccessary to do that anymore.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_2_d51bb87dc5ed0f4ede808c5a9594240d._comment b/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_2_d51bb87dc5ed0f4ede808c5a9594240d._comment
new file mode 100644
index 0000000000..085d00ea50
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_2_d51bb87dc5ed0f4ede808c5a9594240d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 2"
+ date="2022-06-09T02:32:18Z"
+ content="""
+Wouldn't it be possible to support (absolute) file:// urls, eg. something similar to
+`file:///home/jkniiv/test-VEfBrTZ/remote2`? In my mind they feel like a reasonable approximation
+of ssh:// urls and could be useful for getting a feel for git special remotes before setting
+up a bare git-repo/annex on an ssh-server. I know they are not the same thing implementation wise
+but I feel that being able to try this feature out on a least-effort basis would be useful
+from a pedagogical standpoint.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_4_ea413a9dec0243688cbfcaf8a5998ac5._comment b/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_4_ea413a9dec0243688cbfcaf8a5998ac5._comment
new file mode 100644
index 0000000000..d764a5c68f
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/initremote_type__61__git_is_not_working_for_unkn_reason/comment_4_ea413a9dec0243688cbfcaf8a5998ac5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-06-09T17:28:19Z"
+ content="""
+Re file:// urls, it does now work to use them in location=. I don't know if
+I'd consider using them any better than absolute paths though. YMMV.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file.mdwn b/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file.mdwn
new file mode 100644
index 0000000000..9457d4b8bf
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file.mdwn
@@ -0,0 +1,150 @@
+[[!meta title="http remotes that require authentication are not yet supported"]]
+
+It is not a ground shaking issue, but probably would be best to handle it more gracefully.
+
+Initially mentioned while doing install using datalad. Account/permission is required to access this particular repo, ask Canadians for access if you don't have it yet Joey.  credentials I guess got asked for and cached by git upon initial invocation, so upon subsequent calls didn't ask for any:
+
+[[!format sh """
+$> datalad install https://git.bic.mni.mcgill.ca/bic/Coffey-mri-bids
+[INFO   ] Cloning https://git.bic.mni.mcgill.ca/bic/Coffey-mri-bids [1 other candidates] into '/tmp/Coffey-mri-bids'
+[INFO   ] fatal: bad config line 1 in file /home/yoh/.tmp/git-annex96493-5.tmp
+[INFO   ]   Remote origin not usable by git-annex; setting annex-ignore
+install(ok): /tmp/Coffey-mri-bids (dataset)
+"""]]
+
+which boiled down to that message being spited out during `git annex init` which samples the remote, but fails to download the config and gets instead a redirected html page:
+
+[[!format sh """
+$> git clone https://git.bic.mni.mcgill.ca/bic/Coffey-mri-bids
+Cloning into 'Coffey-mri-bids'...
+warning: redirecting to https://git.bic.mni.mcgill.ca/bic/Coffey-mri-bids.git/
+remote: Enumerating objects: 398, done.
+remote: Counting objects: 100% (398/398), done.
+remote: Compressing objects: 100% (282/282), done.
+remote: Total 398 (delta 53), reused 393 (delta 48)
+Receiving objects: 100% (398/398), 34.97 KiB | 795.00 KiB/s, done.
+Resolving deltas: 100% (53/53), done.
+
+
+$> git -C Coffey-mri-bids annex init --debug
+...
+[2019-11-27 19:27:01.341315979] Request {
+  host                 = "git.bic.mni.mcgill.ca"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding","identity"),("User-Agent","git-annex/7.20190819+git2-g908476a9b-1~ndall+1")]
+  path                 = "/bic/Coffey-mri-bids/config"
+  queryString          = ""
+  method               = "GET"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+}
+
+[2019-11-27 19:27:01.90016181] read: git ["config","--null","--list","--file","/home/yoh/.tmp/git-annex228094-5.tmp"]
+fatal: bad config line 1 in file /home/yoh/.tmp/git-annex228094-5.tmp
+[2019-11-27 19:27:01.913302324] process done ExitFailure 128
+
+  Remote origin not usable by git-annex; setting annex-ignore
+
+$> wget -S https://git.bic.mni.mcgill.ca/bic/Coffey-mri-bids/config
+--2019-11-27 19:29:25--  https://git.bic.mni.mcgill.ca/bic/Coffey-mri-bids/config
+Resolving git.bic.mni.mcgill.ca (git.bic.mni.mcgill.ca)... 132.216.133.92
+Connecting to git.bic.mni.mcgill.ca (git.bic.mni.mcgill.ca)|132.216.133.92|:443... connected.
+HTTP request sent, awaiting response... 
+  HTTP/1.1 302 Found
+  Server: nginx
+  Date: Thu, 28 Nov 2019 00:29:26 GMT
+  Content-Type: text/html; charset=utf-8
+  Content-Length: 109
+  Connection: keep-alive
+  Cache-Control: no-cache
+  Location: https://git.bic.mni.mcgill.ca/users/sign_in
+  Set-Cookie: _gitlab_session=8a4f8d5569636004aaebfb73588a2d53; path=/; secure; HttpOnly
+  X-Request-Id: xTcSyu4H36
+  X-Runtime: 0.071681
+  Strict-Transport-Security: max-age=31536000
+  Referrer-Policy: strict-origin-when-cross-origin
+Location: https://git.bic.mni.mcgill.ca/users/sign_in [following]
+--2019-11-27 19:29:26--  https://git.bic.mni.mcgill.ca/users/sign_in
+Reusing existing connection to git.bic.mni.mcgill.ca:443.
+HTTP request sent, awaiting response... 
+  HTTP/1.1 200 OK
+  Server: nginx
+  Date: Thu, 28 Nov 2019 00:29:26 GMT
+  Content-Type: text/html; charset=utf-8
+  Transfer-Encoding: chunked
+  Connection: keep-alive
+  Vary: Accept-Encoding
+  Cache-Control: max-age=0, private, must-revalidate
+  Etag: W/"305857ff0ba591a1e4ee7fec83b5687c"
+  Referrer-Policy: strict-origin-when-cross-origin
+  Set-Cookie: _gitlab_session=8a4f8d5569636004aaebfb73588a2d53; path=/; expires=Thu, 28 Nov 2019 02:29:26 -0000; secure; HttpOnly
+  X-Content-Type-Options: nosniff
+  X-Download-Options: noopen
+  X-Frame-Options: DENY
+  X-Permitted-Cross-Domain-Policies: none
+  X-Request-Id: MHFi7Yjxe82
+  X-Runtime: 0.063359
+  X-Ua-Compatible: IE=edge
+  X-Xss-Protection: 1; mode=block
+  Strict-Transport-Security: max-age=31536000
+  Referrer-Policy: strict-origin-when-cross-origin
+Length: unspecified [text/html]
+Saving to: ‘config’
+
+config                                                       [ <=>                                                                                                                              ]  13.19K  --.-KB/s    in 0s      
+
+2019-11-27 19:29:26 (89.1 MB/s) - ‘config’ saved [13505]
+
+$> cat config 
+<!DOCTYPE html>
+<html class="devise-layout-html">
+<head prefix="og: http://ogp.me/ns#">
+<meta charset="utf-8">
+<meta content="IE=edge" http-equiv="X-UA-Compatible">
+<meta content="object" property="og:type">
+<meta content="GitLab" property="og:site_name">
+<meta content="Sign in" property="og:title">
+...
+"""]]
+
+I guess the problem is multi-faceted:
+
+1. in case of authenticated http remote, `git` caches credentials, but then `git annex` tries to download file directly (instead of somehow via git), it could not "sense" that remote to be a valid annex and/or get files from it.
+
+You can try with this simple one -- user "demo", password "demo":
+
+[[!format sh """
+$> git clone http://www.onerussian.com/tmp/secret-repo/.git
+Cloning into 'secret-repo'...
+Username for 'http://www.onerussian.com': demo
+Password for 'http://demo@www.onerussian.com': 
+
+$> git -C secret-repo annex init
+init  (merging origin/git-annex into git-annex...)
+(recording state in git...)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+ok
+(recording state in git...)
+
+"""]]
+
+although remote is a proper annex, indeed `git annex` cannot use it since does not authenticate as git does.
+So even though the error message is not incorrect, I would say the situation is suboptimal
+ 
+2. if remote server instead of just returning 404 or 403 error code (as eg github seems to do in similar cases of non-authenticated access) instead redirects to some login page, annex feeds that page as a config to git, ignores the error message and just marks that remote as ignored for annex, while leaking that obscure "fatal" error message from git. 
+
+IMHO, ideally 1. should be addressed properly (authentication), and for 2. annex should spit out some more sensible message ("git failed to parse a config file fetched from the remote X.  Please inspect it at this /path/config"), so keep that file around for debugging.  As it is now I had to dig quite deep to figure out WTF is going on.
+
+git annex 7.20190819+git2-g908476a9b-1~ndall+1 and the same with bleeding edge 7.20191114+git43-ge29663773-1~ndall+1 (probably that commit is the one with my patch for stricter git versioning, so use the count of 42 ;))
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[done]]; the error message is improved and also git remotes that need
+> http basic auth to access will get password from `git credential`.
+> --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_1_08af564539efb1b0d85905c0aa862c43._comment b/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_1_08af564539efb1b0d85905c0aa862c43._comment
new file mode 100644
index 0000000000..53716fecb2
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_1_08af564539efb1b0d85905c0aa862c43._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="related: shouldn't git annex try external remotes to download config?"
+ date="2019-11-28T01:22:53Z"
+ content="""
+I haven't tested, but I can see the situation where a specific repository URL could be handled by external special remote (such as datalad, downloaders of which do handle obscure setups such as this one without 403/404 but rather forwarding to login page) which would provide authenticated access to the URL.  Would annex even try that config URL via external special remotes?
+"""]]
diff --git a/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_2_9a63b2918f5621efbfe8cdb33b23ff21._comment b/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_2_9a63b2918f5621efbfe8cdb33b23ff21._comment
new file mode 100644
index 0000000000..bf9004d767
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_2_9a63b2918f5621efbfe8cdb33b23ff21._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2019-11-29T18:09:45Z"
+ content="""
+one of the use-cases (will be) https://gin.g-node.org/ -- an archive of (primarily) electrophys data.  The platform is based on gogs, but uses git-annex underneath.  It \"will be\" because currently access to git-annex is provided only via ssh, but as of today it is already possible to `git clone` (tried on public, didn't try private) datasets via https, and developers are looking into exposing git-annex also via http.  To access private datasets authentication will need to be handled
+"""]]
diff --git a/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_3_3df07b6c8ef25ad96ff4f198931347ad._comment b/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_3_3df07b6c8ef25ad96ff4f198931347ad._comment
new file mode 100644
index 0000000000..7be8cac1f4
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_3_3df07b6c8ef25ad96ff4f198931347ad._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-01-22T16:04:37Z"
+ content="""
+git-annex could use `git credential` if the config download fails with
+401 unauthorized and then retry with the credentials. (The git-lfs special
+remote already does this.) And it would also need to do the same thing
+when getting a key from the remote.
+
+But that would not help with the https://git.bic.mni.mcgill.ca example,
+apparently, because there's no 401, but a 302 redirect to a 200,
+that is indistingishable from a successful download. 
+
+Yeah, when git-annex expects a git config, if it doesn't parse as one,
+it could retry, asking for credentials.
+But that seems asking for trouble: what if it fails to parse for
+another reason, maybe the web server served up something other than the
+expected config, maybe a captive portal got in the way. There would be a
+username/password prompt that doesn't make sense to the user at all.
+
+And if this happens in a key download, git-annex certianly has no way to
+tell that what it downloaded is not intended as the content of a key,
+short of verifying the content, and failure to verify certainly doesn't
+justify prompting for a username/password.
+
+So, I am not comfortable with falling back to ask for credentials unless
+I've seen a http status code that indicates they are necessary.
+And IMHO gitlab's use of a 302 redirect to a login page is a bug in
+gitlab, and will need to be fixed there, or a better http server used.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_4_051d22f0bd0eb601476cd3b74a9b98b8._comment b/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_4_051d22f0bd0eb601476cd3b74a9b98b8._comment
new file mode 100644
index 0000000000..956baeb592
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_4_051d22f0bd0eb601476cd3b74a9b98b8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: related: shouldn't git annex try external remotes to download config?"""
+ date="2020-01-22T16:31:16Z"
+ content="""
+No, the external special remote protocol is not aimed at downloading git
+config files. Anyway, this code path is never involved with using 
+special remotes; the uuid of a special remote is known and so there is no
+need to ever download a git config file to discover it.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/many___40__2x_jobs__63____41___sleeping__hash-object__processes__63__.mdwn b/doc/projects/dandi/bugs-done/many___40__2x_jobs__63____41___sleeping__hash-object__processes__63__.mdwn
new file mode 100644
index 0000000000..2b2fe673ca
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/many___40__2x_jobs__63____41___sleeping__hash-object__processes__63__.mdwn
@@ -0,0 +1,48 @@
+### Please describe the problem.
+
+May be not a problem per se, but decided to check if expected. Following [this advise](http://git-annex.branchable.com/todo/git_smudge_clean_interface_suboptiomal/#comment-65f848510d8684bf65c6698f68b700dd) I have `git config filter.annex.process "git-annex filter-process"` in that git-annex repo and now observe following tree (in htop) of processes:
+
+```
+3799768 dandi      20   0 1025G  191M 40616 S  6.6  0.3  0:31.87 │                 │     ├─ git-annex addurl --batch --with-files --jobs 5 --json --json-error-messages --json-progress --raw
+3799796 dandi      20   0  191M  5088  4680 S  0.0  0.0  0:00.01 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+3805272 dandi      20   0  6892  3420  2992 S  0.0  0.0  0:00.27 │                 │     │  ├─ /bin/bash /usr/bin/git-annex-remote-rclone
+3805640 dandi      20   0 20432 13032  4024 S  0.0  0.0  0:02.82 │                 │     │  ├─ git --git-dir=.git --work-tree=. check-ignore -z --stdin --verbose --non-matching
+3805646 dandi      20   0 20432 13044  4036 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs check-attr -z --stdin annex.backend annex.largefiles annex.numcopies annex.mincopies --
+3805650 dandi      20   0 31900  4064  3816 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3805685 dandi      20   0 30144  4000  3752 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3805704 dandi      20   0 30144 16076 15792 S  0.0  0.0  0:00.01 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3805705 dandi      20   0 30144  3976  3728 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3805717 dandi      20   0 30144 15968 15680 S  0.0  0.0  0:00.01 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3805781 dandi      20   0 30144  3980  3724 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3805786 dandi      20   0 30144  4068  3820 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3805807 dandi      20   0 30144 16028 15744 S  0.0  0.0  0:00.02 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3805808 dandi      20   0 30144  3884  3636 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3805828 dandi      20   0 30144  4008  3764 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3805848 dandi      20   0 20432 13104  4092 S  0.0  0.0  0:00.04 │                 │     │  ├─ git --git-dir=.git --work-tree=. check-ignore -z --stdin --verbose --non-matching
+3805852 dandi      20   0 20432 12948  3940 S  0.0  0.0  0:00.02 │                 │     │  ├─ git --git-dir=.git --work-tree=. check-ignore -z --stdin --verbose --non-matching
+3805865 dandi      20   0 20432 13032  4024 S  0.0  0.0  0:00.02 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs check-attr -z --stdin annex.backend annex.largefiles annex.numcopies annex.mincopies --
+3806054 dandi      20   0 30144  4004  3752 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3806066 dandi      20   0 45216  5108  4700 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+3806067 dandi      20   0 30144  3888  3640 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3806068 dandi      20   0 30144 16032 15748 S  0.0  0.0  0:00.01 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3806095 dandi      20   0 30144  4060  3816 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3806104 dandi      20   0 20432 12928  3916 S  0.0  0.0  0:00.06 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs check-attr -z --stdin annex.backend annex.largefiles annex.numcopies annex.mincopies --
+3806110 dandi      20   0 30144 15944 15660 S  0.0  0.0  0:00.02 │                 │     │  └─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3804258 dandi      20   0 1024G 44336 37772 S  0.0  0.1  0:00.04 │                 │     ├─ git-annex addurl --batch --with-files --jobs 5 --json --json-error-messages --json-progress --raw
+3804277 dandi      20   0 40844  5124  4740 S  0.0  0.0  0:00.00 │                 │     │  └─ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+3805399 dandi      20   0 1024G 23508 20844 S  0.0  0.0  0:00.61 │                 │     ├─ git-annex examinekey --batch --migrate-to-backend=SHA256E
+3805493 dandi      20   0 1024G 36516 26184 S  0.0  0.1  0:01.51 │                 │     ├─ git-annex fromkey --force --batch --json --json-error-messages
+3805503 dandi      20   0 25788  5120  4712 S  0.0  0.0  0:00.00 │                 │     │  ├─ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+3805510 dandi      20   0 12472  3984  3732 S  0.0  0.0  0:00.05 │                 │     │  └─ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+```
+
+which might be ok but still wonder why they are just sleeping there in more than one per `--jobs` number quantities. git annex 10.20220624-g769be12
+
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+
+> [[done]]; this is now handled like other git helper processes
+> and will be capped to the maximum of the number of jobs or cpu cores,
+> and in practice usually fewer than that will be started. --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/many___40__2x_jobs__63____41___sleeping__hash-object__processes__63__/comment_1_c01d8d2e4aa2cb0d064ab223e615a75c._comment b/doc/projects/dandi/bugs-done/many___40__2x_jobs__63____41___sleeping__hash-object__processes__63__/comment_1_c01d8d2e4aa2cb0d064ab223e615a75c._comment
new file mode 100644
index 0000000000..bd3256f989
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/many___40__2x_jobs__63____41___sleeping__hash-object__processes__63__/comment_1_c01d8d2e4aa2cb0d064ab223e615a75c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-07-25T20:37:55Z"
+ content="""
+I was able to reproduce this by feeding 10 urls into git-annex addurl
+-J5 and got 7 hash-object processes running.
+
+filter.annex.process has nothing to do with this. I reproduced the behavior
+without it set.
+
+Seems like a simple concurrency issue, where each thread potentially starts
+its own hash-object handle, and there can be around 2x as many threads
+started as the -J number due to job stages. Annex.Concurrent sets up pools of
+handles for other similar git processes, but not hash-object.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/metadata_cmd._vs._--json-error-messages.mdwn b/doc/projects/dandi/bugs-done/metadata_cmd._vs._--json-error-messages.mdwn
new file mode 100644
index 0000000000..7e38c2f026
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/metadata_cmd._vs._--json-error-messages.mdwn
@@ -0,0 +1,8 @@
+(Sorry about the title; I was trying to work within the character limit.)
+
+When invoking `git-annex metadata --batch --json --json-error-messages`, if an error occurs in response to some input — say, because the name of a nonexistent file was supplied (or, in my case, because the name of a file downloaded milliseconds ago in a parallel addurl process was supplied) — then `git-annex metadata` will output "git-annex: not an annexed file: {filepath}" to standard error and immediately exit.  Not only is this in contrast to what it seems `--json-error-messages` should do, but the "exiting immediately" bit is in contrast to my understanding of how batch mode is supposed to work.  Surely this should be fixed?
+
+[[!meta author=jwodder]]
+[[!tag projects/dandi]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/metadata_cmd._vs._--json-error-messages/comment_1_198df45c72d0c9b4997d1342ffb666ca._comment b/doc/projects/dandi/bugs-done/metadata_cmd._vs._--json-error-messages/comment_1_198df45c72d0c9b4997d1342ffb666ca._comment
new file mode 100644
index 0000000000..faa240af2c
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/metadata_cmd._vs._--json-error-messages/comment_1_198df45c72d0c9b4997d1342ffb666ca._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-11-01T16:27:48Z"
+ content="""
+For consistency with other --batch, I've made it reply with a blank line
+when the input is not an annexed file.
+
+Do note that --json-error-messages cannot cram every possible kind of error
+message into a json object. In particular, errors that occur at startup,
+and not when acting on a particular file or key, do not fit into the json
+schema.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/move.log__58___openFile__58___resource_busy___40__file_is_locked__41__.mdwn b/doc/projects/dandi/bugs-done/move.log__58___openFile__58___resource_busy___40__file_is_locked__41__.mdwn
new file mode 100644
index 0000000000..894aa8012e
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/move.log__58___openFile__58___resource_busy___40__file_is_locked__41__.mdwn
@@ -0,0 +1,44 @@
+### Please describe the problem.
+
+From [https://github.com/DanielDent/git-annex-remote-rclone/pull/57](https://github.com/DanielDent/git-annex-remote-rclone/pull/57), where we use that rclone special remote for backup of DANDI data to dropbox
+
+Seems like a test sometimes fails on Mac OS with:
+
+```
++ git-annex copy -J5 --quiet . --to GA-rclone-CI
+git-annex: .git/annex/move.log: openFile: resource busy (file is locked)
+copy: 1 failed
+Error: Process completed with exit code 1.
+```
+
+indeed so far seemed to happen only on Mac
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex-remote-rclone[master]2022
+$> datalad foreach-dataset git grep 'file is locked'
+foreach-dataset(error): /mnt/datasets/datalad/ci/git-annex-remote-rclone (dataset) [CommandError: 'git grep 'file is locked'' failed with exitcode 1 under /mnt/datasets/datalad/ci/git-annex-remote-rclone]
+03/cron/20221003T064418/da57e9a/github-Tests-144-failed/9_test (macos-latest, v1.53.3).txt:2022-10-03T06:47:44.4978580Z git-annex: .git/annex/move.log: openFile: resource busy (file is locked)
+03/cron/20221003T064418/da57e9a/github-Tests-144-failed/test (macos-latest, v1.53.3)/9_tests.txt:2022-10-03T06:47:44.4978530Z git-annex: .git/annex/move.log: openFile: resource busy (file is locked)
+03/push/master/1d0d3ce/github-Tests-146-failed/10_test (macos-latest, v1.33).txt:2022-10-03T23:35:41.8464390Z git-annex: .git/annex/move.log: openFile: resource busy (file is locked)
+03/push/master/1d0d3ce/github-Tests-146-failed/9_test (macos-latest, v1.53.3).txt:2022-10-03T23:37:44.0652500Z git-annex: .git/annex/move.log: openFile: resource busy (file is locked)
+03/push/master/1d0d3ce/github-Tests-146-failed/test (macos-latest, v1.33)/9_tests.txt:2022-10-03T23:35:41.8463970Z git-annex: .git/annex/move.log: openFile: resource busy (file is locked)
+03/push/master/1d0d3ce/github-Tests-146-failed/test (macos-latest, v1.53.3)/9_tests.txt:2022-10-03T23:37:44.0652360Z git-annex: .git/annex/move.log: openFile: resource busy (file is locked)
+foreach-dataset(ok): /mnt/datasets/datalad/ci/git-annex-remote-rclone/2022/10 (dataset)
+foreach-dataset(error): /mnt/datasets/datalad/ci/git-annex-remote-rclone/2022/06 (dataset) [CommandError: 'git grep 'file is locked'' failed with exitcode 1 under /mnt/datasets/datalad/ci/git-annex-remote-rclone/2022/06]
+foreach-dataset(error): /mnt/datasets/datalad/ci/git-annex-remote-rclone/2022/07 (dataset) [CommandError: 'git grep 'file is locked'' failed with exitcode 1 under /mnt/datasets/datalad/ci/git-annex-remote-rclone/2022/07]
+foreach-dataset(error): /mnt/datasets/datalad/ci/git-annex-remote-rclone/2022/09 (dataset) [CommandError: 'git grep 'file is locked'' failed with exitcode 1 under /mnt/datasets/datalad/ci/git-annex-remote-rclone/2022/09]
+foreach-dataset(error): /mnt/datasets/datalad/ci/git-annex-remote-rclone/2022/08 (dataset) [CommandError: 'git grep 'file is locked'' failed with exitcode 1 under /mnt/datasets/datalad/ci/git-annex-remote-rclone/2022/08]
+```
+
+### What steps will reproduce the problem?
+
+no minimal reproducer yet but happens as part of [this test "script"](https://github.com/DanielDent/git-annex-remote-rclone/blob/master/tests/all-in-one.sh)
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20220927
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> Presumed [[fixed|done]]; please followup if I'm wrong. --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/move.log__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_1_14d5ba72397406620ac0a9fb05f2862d._comment b/doc/projects/dandi/bugs-done/move.log__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_1_14d5ba72397406620ac0a9fb05f2862d._comment
new file mode 100644
index 0000000000..b052d32263
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/move.log__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_1_14d5ba72397406620ac0a9fb05f2862d._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-10-07T16:44:04Z"
+ content="""
+I doubt this is really OSX specific. This must be two threads running logMove
+at the same time, that end up trying to both write or one write and one
+read at the same time. That causes the haskell RTS to fail this way.
+
+Since it does use a lock file when writing and appending to the log file,
+I think it must be the call to checkLogFile that is failing. That avoids
+taking the lock, for performance reasons. The performace gain is pretty
+minimal though, taking the lock is not much. Only when modifyLogFile
+is called at the same time might it need to block on the file being
+rewritten, but the file only ever has 100 items, so that never takes long
+either.
+
+So, I have added locking to checkLogFile (and to calcLogFile though it's
+not used here, just because it has the same problem). That should fix it,
+though we'll need to wait on the test to know for sure. I'm going to close
+this, as I'm pretty sure though..
+"""]]
diff --git a/doc/projects/dandi/bugs-done/move.log__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_2_6216c1eb6991cec787333284463fcc9d._comment b/doc/projects/dandi/bugs-done/move.log__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_2_6216c1eb6991cec787333284463fcc9d._comment
new file mode 100644
index 0000000000..b16d04b181
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/move.log__58___openFile__58___resource_busy___40__file_is_locked__41__/comment_2_6216c1eb6991cec787333284463fcc9d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-11-04T12:41:47Z"
+ content="""
+ok, did the archaeologic expedition to figure when fixed -- was  fixed in [10.20221003-19-g4a42c6909 AKA 10.20221103~28](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=4a42c69092a03cce7b31b79b862e59c9842ced77) , brew still (well -- we are just 1 day post release! ;)) has 10.20221003 so in testing git-annex-remote-rclone we keep getting hit but hopefully it would go away soon with update of git-annex in brew.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not.mdwn b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not.mdwn
new file mode 100644
index 0000000000..8a3d282848
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not.mdwn
@@ -0,0 +1,96 @@
+### Please describe the problem.
+
+git status reports having staged changes and no changes from index
+
+```shell
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git restore <file>..." to discard changes in working directory)
+        modified:   .dandi/assets.json
+
+no changes added to commit (use "git add" and/or "git commit -a")
+
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git annex status
+M ./.dandi/assets.json
+```
+
+although git shows no diff and sha256 checksum corresponds to the key:
+
+```shell
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git diff --cached
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git show -- .dandi/assets.json
+commit b859efed7ddb2ff31cc26168f40676c572d2798f (HEAD -> draft, github/draft, github/HEAD)
+Author: DANDI User <info@dandiarchive.org>
+Date:   Fri Sep 16 22:22:29 2022 +0000
+
+    [backups2datalad] 66 files added
+
+diff --git a/.dandi/assets.json b/.dandi/assets.json
+index d3ef95e1ee..62fe372810 100644
+--- a/.dandi/assets.json
++++ b/.dandi/assets.json
+@@ -1 +1 @@
+-/annex/objects/SHA256E-s69400783--8b576786d3926ab0e84809b4131cdc5a8f631674d378afa343e7dcd84f011c90.json
++/annex/objects/SHA256E-s69507227--6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14.json
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ sha256sum .dandi/assets.json
+6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14  .dandi/assets.json
+```
+
+I think may be the tricky part is that I have it of 
+
+```
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git config annex.version
+10
+```
+
+although I thought that we kept it at 8 but I have user wider config setting
+
+```
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git config filter.annex.process
+git-annex filter-process
+```
+
+I was recommended to speed up operations while avoiding upgrade to  10, but I guess running most recent version once lead to the upgrade since all the other repos are still at 8 as I thought it would be
+
+```
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ grep -h '\<version =' ../*/.git/config | sort | uniq -c
+      1         version = 10
+    186         version = 8
+```
+
+having it reported modified causes our script which does sanity check to operate only on clean repo to fail.
+
+`git reset --hard` seems mitigated that
+
+```
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git reset --hard
+HEAD is now at b859efed7d [backups2datalad] 66 files added
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+nothing to commit, working tree clean
+```
+
+all.  I will now rerun our script and see in what state I would end up (although, once again, I ended up in version 10 of the repo already, so may be behavior would be different). 
+
+### What steps will reproduce the problem?
+
+I think I get it after I `annex move` and then `annex get` that file back. Just for my own reference -- git-annex repo is result of the https://github.com/dandi/dandisets/blob/draft/tools/backups2datalad-update-cron 
+
+
+### What version of git-annex are you using? On what operating system?
+
+10.20220822-g84f1875 (conda build), originally observed on earlier 10.20220724-ge30d846
+
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+[[!meta title="annex.stalldetection prevents git-annex get from restaging unlocked files"]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_10_43f1eec4aa317ff3b1a4fc18def96c6f._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_10_43f1eec4aa317ff3b1a4fc18def96c6f._comment
new file mode 100644
index 0000000000..4941e433c2
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_10_43f1eec4aa317ff3b1a4fc18def96c6f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 10"
+ date="2022-09-22T17:34:35Z"
+ content="""
+damn, I should have shared my config!  I also do have `annex.stalldetection` set!
+
+```
+[annex]
+	stalldetection = 1KB/120s
+```
+
+never thought it might be related.  We should look into having some matrix test run with such config set.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_11_f8a54670d8eaf00624e9b8f85e803864._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_11_f8a54670d8eaf00624e9b8f85e803864._comment
new file mode 100644
index 0000000000..ea0faa1353
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_11_f8a54670d8eaf00624e9b8f85e803864._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2022-09-22T17:38:45Z"
+ content="""
+Yeah, a whole git-annex test run with stalldetection set would have found
+this bug. Which seems a bit heavy-weight for the test suite to try as a
+separate pass by default. But then again, stalldetection does significantly
+change how git-annex operates since it has to fork off child processes that
+it can kill when they stall.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_12_5cdddca4ca03216b68d443eeb49af581._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_12_5cdddca4ca03216b68d443eeb49af581._comment
new file mode 100644
index 0000000000..6d8bfbcc4e
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_12_5cdddca4ca03216b68d443eeb49af581._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 12"
+ date="2022-09-22T18:14:15Z"
+ content="""
+Adding a matrix run where I initiated a custom config settings to our [datalad/git-annex](https://github.com/datalad/git-annex/pull/133) CI run.  Let's see how that goes.  May be some other interesting config settings to add there? e.g. retries etc?  or global `~/.gitconfig` is not used/mocked away during tests? (e.g. we do that in datalad, so I had to trick that in [PR against datalad](https://github.com/datalad/datalad/pull/7056) to test against this setting being set)
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_12_68a79183b04b99d4b00b363e3cbe3f3c._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_12_68a79183b04b99d4b00b363e3cbe3f3c._comment
new file mode 100644
index 0000000000..f8955e7b05
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_12_68a79183b04b99d4b00b363e3cbe3f3c._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2022-09-22T17:40:57Z"
+ content="""
+So, `git-annex transferrer`, after downloading the content, does handle
+populating pointer files. So it calls restagePointerFile to register a cleanup
+action.
+
+Whatever is making that process exit 1 must be preventing the cleanup
+action from being run. And I think what that is, is that its stdout handle
+gets closed at the same time its stdin handle is closed. I tried running
+`git-annex transferrer` manually and feeding it a transfer request on
+stdin. After its stdin was closed, it proceeded to send 
+`"om (recording state in git...)\n"` to stdout, and that would fail
+with stdout already closed.
+
+Worse, I suspect there's another problem.. When a stall actually
+is detected, git-annex kills the `git-annex transferrer` process that has
+stalled. But suppose that process has already successfully downloaded some
+content and populated pointer files. Killing it would prevent it from
+running restagePointerFile on those. It seems that to solve this,
+it would need to communicate back to the parent what pointer files need to
+be restaged. (Which would also solve the exit 1 problem, although not
+necessarily in the best way.)
+
+Also, I think that multiple processes running the restagePointerFile
+cleanup action at the same time can be a problem, because one will
+lock the index and the rest will fail to restage. Not what's happening
+here, but with -J, there would be multiple `git-annex transferrer`
+processes doing that at the same time at the end.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_13_5c03731700b2a025755fb06c9a96f331._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_13_5c03731700b2a025755fb06c9a96f331._comment
new file mode 100644
index 0000000000..7574901278
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_13_5c03731700b2a025755fb06c9a96f331._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2022-09-22T18:16:22Z"
+ content="""
+Avoided the early stdout handle close, and that did fix this bug as
+reported.
+
+The related problems I identified in comment #12 are still unfixed, so
+leaving this open for now.
+
+I think what ought to be done to wrap this up is make restagePointerFile
+record the files that need to be restaged in a log file. Then at shutdown,
+git-annex can read the log file, and restage everything listed in it.
+This will solve multiple problems:
+
+* When a previous git-annex process was interrupted after a get/drop of an
+  unlocked file, the file will be in the log, so git-annex can notice
+  that and handle the restaging.
+* When a stalled `git-annex transferrer` is killed, the parent git-annex
+  will read the log and handle the restaging that it was not able to do.
+* When multiple processes are trying to restage files at the same time,
+  an exclusive lock can be used to make only one of them run, and it can
+  handle restaging the files that the others have recorded in the log too.
+* As a bonus, in the situations where git-annex is legitimately unable to
+  restage files, it can still record them to be restaged later. And the
+  "only a cosmetic problem" message can tell the user to run a single
+  simple git-annex command, rather than a complicated 
+  `git update-index` command per file.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_15_df08c2530b890544d5eb2df792c8fd4b._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_15_df08c2530b890544d5eb2df792c8fd4b._comment
new file mode 100644
index 0000000000..5f5c21ab67
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_15_df08c2530b890544d5eb2df792c8fd4b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2022-09-22T18:42:06Z"
+ content="""
+@yarikoptic oh, `git-annex test` does prevent global gitconfig from
+influeencing the tests. So your matrix test won't work if you're
+running `git-annex test` in it. If you're running other git-annex commands
+in datalad's test suite, it would work though.
+
+I've opened [[todo/specify_gitconfig_for_test_suite]].
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_16_4b8a360c38dfa4c8d22e3a96fbace0e5._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_16_4b8a360c38dfa4c8d22e3a96fbace0e5._comment
new file mode 100644
index 0000000000..018139bf8e
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_16_4b8a360c38dfa4c8d22e3a96fbace0e5._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""status update"""
+ date="2022-09-23T19:57:38Z"
+ content="""
+I've implemented the log file. The stalled transferrer case is now handled.
+This bug is fixed.
+
+As to a few other cases I considered in comments upthread:
+
+When a get/drop was interrupted before it could restage, 
+the next get/drop will cause the necessary restaging for the 
+interrupted process to happen. However, this doesn't help if there's
+nothing left to get/drop. Should git-annex always run restagePointerFiles
+on shutdown? That would make any git-annex command handle the restaging.
+But it doesn't seem right for query commands to do potentially a lot of
+work to handle this case. Anyway, I don't think this needs to be dealt
+with in this bug report.
+
+When multiple processes try to restage at the same time, one will
+restage everything that all of them logged. The others will still display a
+warning to the user that they couldn't restage. It would be hard to avoid
+displaying that warning, since it does need to warn when it was
+unable to restage because git has the index locked at the time. Anyway,
+I think it's ok to display the message despite the files having been
+restaged, because it's the same as a later git-annex process handling the
+restaging. (It does seem like two transferrers belonging to the same parent
+could collide in this way, and one display the warning, which isn't great..)
+
+I also implemented a "git-annex restage" command that
+is an easier way to restage in the cases where git-annex is not able
+to do it itself.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_1_5dead4bf9fe9a9c7627843c91613caf5._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_1_5dead4bf9fe9a9c7627843c91613caf5._comment
new file mode 100644
index 0000000000..c13beab231
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_1_5dead4bf9fe9a9c7627843c91613caf5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-21T17:05:51Z"
+ content="""
+Is .dandi/assets.json an unlocked file?
+
+`git diff --cached` seems like the wrong thing to run, because
+that would show changes that you have staged for commit.
+This change is one that has not been staged for commit.
+So `git diff` should show it.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_2_49e075aaa89e60fe1d35513dd4d4d755._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_2_49e075aaa89e60fe1d35513dd4d4d755._comment
new file mode 100644
index 0000000000..d27645608b
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_2_49e075aaa89e60fe1d35513dd4d4d755._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-09-21T18:46:50Z"
+ content="""
+d'oh forgot to show that I have tried that one too. Here is everything at once again with `git diff` and again doing checksums (that should have been different in my prev examples as well if different only in tree but not in index):
+
+```shell
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+Changes not staged for commit:
+  (use \"git add <file>...\" to update what will be committed)
+  (use \"git restore <file>...\" to discard changes in working directory)
+        modified:   .dandi/assets.json
+
+
+It took 3.19 seconds to enumerate untracked files. 'status -uno'
+may speed it up, but you have to be careful not to forget to add
+new files yourself (see 'git help status').
+no changes added to commit (use \"git add\" and/or \"git commit -a\")
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git diff
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git diff --cached
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ sha256sum .dandi/assets.json
+6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14  .dandi/assets.json
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git show -- .dandi/assets.json
+commit b859efed7ddb2ff31cc26168f40676c572d2798f (HEAD -> draft, github/draft, github/HEAD)
+Author: DANDI User <info@dandiarchive.org>
+Date:   Fri Sep 16 22:22:29 2022 +0000
+
+    [backups2datalad] 66 files added
+
+diff --git a/.dandi/assets.json b/.dandi/assets.json
+index d3ef95e1ee..62fe372810 100644
+--- a/.dandi/assets.json
++++ b/.dandi/assets.json
+@@ -1 +1 @@
+-/annex/objects/SHA256E-s69400783--8b576786d3926ab0e84809b4131cdc5a8f631674d378afa343e7dcd84f011c90.json
++/annex/objects/SHA256E-s69507227--6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14.json
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git annex status
+M ./.dandi/assets.json
+
+```
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_3_2a08321045a8ede5c3b5a690232020b3._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_3_2a08321045a8ede5c3b5a690232020b3._comment
new file mode 100644
index 0000000000..a5bb342722
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_3_2a08321045a8ede5c3b5a690232020b3._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2022-09-21T18:49:06Z"
+ content="""
+the workaround you suggest elsewhere for \"cosmetic\" problem works here too
+
+```
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+Changes not staged for commit:
+  (use \"git add <file>...\" to update what will be committed)
+  (use \"git restore <file>...\" to discard changes in working directory)
+        modified:   .dandi/assets.json
+
+no changes added to commit (use \"git add\" and/or \"git commit -a\")
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git update-index -q --refresh .dandi/assets.json
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+nothing to commit, working tree clean
+
+```
+
+but since we are relying on output from `status`, it is not just a \"cosmetic\" issue. IMHO if such `update-index` is needed, it should have been done by git-annex automagically somehow/sometime.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_4_ac9c166c2b0c3aad8391abb56654ecf2._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_4_ac9c166c2b0c3aad8391abb56654ecf2._comment
new file mode 100644
index 0000000000..30e9d721ac
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_4_ac9c166c2b0c3aad8391abb56654ecf2._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-09-21T19:19:08Z"
+ content="""
+So you can reproduce this? I am pretty sure it's not as simple as a drop
+followed by a get, so more information about reproducing it seems crucial.
+
+I assume you are *not* seeing the "This is only a cosmetic problem affecting git status"
+message?
+
+I expect that running `git update-index --refresh .dandi/assets.json`  
+will fix git status. Can you confirm?
+
+The only way I know of that this can happen without the message is if a
+drop or a get is still running, or gets interrupted. One of the last things
+git-annex before exiting is restage all the unlocked files that it has
+updated.
+
+Short of that, it seems like it would have to be a bug that prevents
+restagePointerFile from working. Which might not be a bug in git-annex,
+if the problem involves git's handling of timestamps in the index, for
+example. (Which is known to have some odd behaviors.)
+
+(git-annex could be improved to do the
+restaging later when interrupted and possibly after such a bug.
+But there's no way to make it recover in `git status`, because
+git doesn't run it in this situation.)
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_5_7d339e9a04a7c303949523b235a046ec._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_5_7d339e9a04a7c303949523b235a046ec._comment
new file mode 100644
index 0000000000..d0fc8a0a57
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_5_7d339e9a04a7c303949523b235a046ec._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-09-21T22:06:49Z"
+ content="""
+Seems likely that the --time-limit option, when combined with -J,
+could result in git-annex exiting before a worker thread gets a chance to
+call stagePointerFile. I have not verified this, and it would be unlikely
+to result in the same file being affected reproducibly.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_6_48819ddcb8713087c78db8941e4c1151._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_6_48819ddcb8713087c78db8941e4c1151._comment
new file mode 100644
index 0000000000..a3f60308dc
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_6_48819ddcb8713087c78db8941e4c1151._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2022-09-22T01:03:18Z"
+ content="""
+may be it one of those options, in my case - it is just a straight `get` on that single unlocked file:
+
+```
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+nothing to commit, working tree clean
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ cat .dandi/assets.json
+/annex/objects/SHA256E-s69507227--6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14.json
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git annex get .dandi/assets.json
+get .dandi/assets.json (from dandi-dandisets-dropbox...)
+(checksum...) ok
+(recording state in git...)
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+Changes not staged for commit:
+  (use \"git add <file>...\" to update what will be committed)
+  (use \"git restore <file>...\" to discard changes in working directory)
+        modified:   .dandi/assets.json
+
+no changes added to commit (use \"git add\" and/or \"git commit -a\")
+
+```
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_7_3186ec45f20c4d768c7682e1d42fa24c._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_7_3186ec45f20c4d768c7682e1d42fa24c._comment
new file mode 100644
index 0000000000..419f0415bc
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_7_3186ec45f20c4d768c7682e1d42fa24c._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2022-09-22T01:33:24Z"
+ content="""
+sorry I have not mentioned your [earlier comment 4](http://git-annex.branchable.com/bugs/reports_file___34__modified__34___whenever_it_is_not/#comment-ca0281ff580c91c40e429fbbb71a3791) but my clarification above I think gives the answers to your questions ;)
+
+<details>
+<summary>FWIW here is the get --debug output </summary> 
+
+```shell
+[2022-09-21 21:29:59.904218] (Utility.Process) process [3968193] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"ls-files\",\"--stage\",\"-z\",\"--error-unmatch\",\"--\",\".dandi/assets.json\"]
+[2022-09-21 21:29:59.904725] (Utility.Process) process [3968194] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+[2022-09-21 21:29:59.905645] (Utility.Process) process [3968195] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+[2022-09-21 21:29:59.906012] (Utility.Process) process [3968196] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"show-ref\",\"git-annex\"]
+[2022-09-21 21:29:59.907578] (Utility.Process) process [3968196] done ExitSuccess
+[2022-09-21 21:29:59.907891] (Utility.Process) process [3968197] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2022-09-21 21:29:59.913611] (Utility.Process) process [3968197] done ExitSuccess
+[2022-09-21 21:29:59.914676] (Utility.Process) process [3968198] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"log\",\"refs/heads/git-annex..5f5efa8544ff02c9261dd1590425dcea37a55526\",\"--pretty=%H\",\"-n1\"]
+[2022-09-21 21:29:59.916707] (Utility.Process) process [3968198] done ExitSuccess
+[2022-09-21 21:29:59.916968] (Utility.Process) process [3968199] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"log\",\"refs/heads/git-annex..18497e6e9cab7754a85256416c361fee36ba65b2\",\"--pretty=%H\",\"-n1\"]
+[2022-09-21 21:29:59.918722] (Utility.Process) process [3968199] done ExitSuccess
+[2022-09-21 21:29:59.919069] (Utility.Process) process [3968200] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+get .dandi/assets.json [2022-09-21 21:29:59.921463] (Utility.Process) process [3968202] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch\"]
+(from dandi-dandisets-dropbox...) [2022-09-21 21:29:59.931525] (Utility.Process) process [3968203] chat: /home/dandi/miniconda3/envs/dandisets/bin/git-annex [\"transferrer\",\"-c\",\"annex.debug=true\"]
+[2022-09-21 21:29:59.93162] (Annex.TransferrerPool) > d rdandi-dandisets-dropbox SHA256E-s69507227--6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14.json .dandi/assets.json
+[2022-09-21 21:29:59.942599] (Annex.TransferrerPool) < opb
+
+[2022-09-21 21:29:59.942718] (Annex.TransferrerPool) < ops 69507227
+[2022-09-21 21:30:03.103409] (Annex.TransferrerPool) < ope
+[2022-09-21 21:30:03.103539] (Annex.TransferrerPool) < om (checksum...) 
+(checksum...) [2022-09-21 21:30:03.768599] (Annex.TransferrerPool) < t
+[2022-09-21 21:30:03.768843] (Annex.Branch) read 6e0/a70/SHA256E-s69507227--6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14.json.log
+[2022-09-21 21:30:03.770259] (Annex.Branch) set 6e0/a70/SHA256E-s69507227--6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14.json.log
+ok
+[2022-09-21 21:30:03.770361] (Utility.Process) process [3968200] done ExitSuccess
+[2022-09-21 21:30:03.770425] (Utility.Process) process [3968195] done ExitSuccess
+[2022-09-21 21:30:03.770484] (Utility.Process) process [3968194] done ExitSuccess
+[2022-09-21 21:30:03.770531] (Utility.Process) process [3968193] done ExitSuccess
+[2022-09-21 21:30:03.771187] (Utility.Process) process [3968452] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2022-09-21 21:30:03.77319] (Utility.Process) process [3968453] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"update-index\",\"-z\",\"--index-info\"]
+[2022-09-21 21:30:04.063182] (Utility.Process) process [3968453] done ExitSuccess
+[2022-09-21 21:30:04.063779] (Utility.Process) process [3968463] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2022-09-21 21:30:04.065352] (Utility.Process) process [3968463] done ExitSuccess
+(recording state in git...)
+[2022-09-21 21:30:04.06587] (Utility.Process) process [3968464] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"write-tree\"]
+[2022-09-21 21:30:04.407935] (Utility.Process) process [3968464] done ExitSuccess
+[2022-09-21 21:30:04.408528] (Utility.Process) process [3968468] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"commit-tree\",\"56c62dcc21145201f9454a2dd6e75cc37f072ee4\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"]
+[2022-09-21 21:30:04.410591] (Utility.Process) process [3968468] done ExitSuccess
+[2022-09-21 21:30:04.413623] (Utility.Process) process [3968469] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"update-ref\",\"refs/heads/git-annex\",\"c3a1f9208649b47621b1424b055bd9871aa2fc79\"]
+[2022-09-21 21:30:04.415318] (Utility.Process) process [3968469] done ExitSuccess
+[2022-09-21 21:30:04.416301] (Utility.Process) process [3968202] done ExitSuccess
+[2022-09-21 21:30:04.416574] (Utility.Process) process [3968452] done ExitSuccess
+[2022-09-21 21:30:06.373343] (Utility.Process) process [3968203] done ExitFailure 1
+```
+</details>
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_8_927028d040b0e24d772b667324b1a5e1._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_8_927028d040b0e24d772b667324b1a5e1._comment
new file mode 100644
index 0000000000..422fc09ad2
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_8_927028d040b0e24d772b667324b1a5e1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-09-22T17:02:04Z"
+ content="""
+I've fixed the issue I found with --timestamp combined with -J. Which I do
+think could have resulted in the same kind of problem. But you've shown
+that is not the cause in your case..
+"""]]
diff --git a/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_9_64ba2901154b629a9697b427f3ad92e2._comment b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_9_64ba2901154b629a9697b427f3ad92e2._comment
new file mode 100644
index 0000000000..c7378771ce
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/reports_file___34__modified__34___whenever_it_is_not/comment_9_64ba2901154b629a9697b427f3ad92e2._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-09-22T17:04:35Z"
+ content="""
+Thanks for the --debug. It shows that git-annex is not running 
+`git update-index --refresh` at all.
+
+And it shows that the transfer happens in a `git-annex transferrer` process.
+So, I think you have annex.stalldetection set.
+
+	[2022-09-21 21:29:59.931525] (Utility.Process) process [3968203] chat: /home/dandi/miniconda3/envs/dandisets/bin/git-annex [\"transferrer\",\"-c\",\"annex.debug=true\"]
+
+And interestingly, that transferrer process fails at the end:
+
+	[2022-09-21 21:30:06.373343] (Utility.Process) process [3968203] done ExitFailure 1
+
+Aha! I can reproduce it by setting annex.stalldetection.
+"""]]
diff --git a/doc/projects/dandi/bugs-done/standalone_needs_more_depends_-_libgcc-s1__63__.mdwn b/doc/projects/dandi/bugs-done/standalone_needs_more_depends_-_libgcc-s1__63__.mdwn
new file mode 100644
index 0000000000..b3863dd72b
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/standalone_needs_more_depends_-_libgcc-s1__63__.mdwn
@@ -0,0 +1,72 @@
+### Please describe the problem.
+
+NB can't change the title since it is not about depends since libgcc-s1 is essential... so most likely some  LD_LIBRARY_PATH manipulation is in place or smth like that.
+
+[Testing of git-annex-remote-rclone on ubuntu-20.04 crashed](https://github.com/DanielDent/git-annex-remote-rclone/actions/runs/3750292044/jobs/6370225718) with
+
+```
++ git-annex copy -J5 --quiet . --to GA-rclone-CI
+libgcc_s.so.1 must be installed for pthread_cancel to work
+/home/runner/work/git-annex-remote-rclone/git-annex-remote-rclone/tests/all-in-one.sh: line 124:  3066 Aborted                 (core dumped) git-annex copy -J5 --quiet . --to GA-rclone-CI
+Error: Process completed with exit code 134.
+```
+
+installation of git annex
+
+```
+Run datalad-installer --sudo ok git-annex -m datalad/git-annex:release
+2022-12-21T15:10:30+0000 [INFO    ] datalad_installer Writing environment modifications to /tmp/dl-env-j8s29if7.sh
+2022-12-21T15:10:30+0000 [INFO    ] datalad_installer Installing git-annex via datalad/git-annex:release
+2022-12-21T15:10:30+0000 [INFO    ] datalad_installer Version: None
+2022-12-21T15:10:30+0000 [INFO    ] datalad_installer Downloading https://github.com/datalad/git-annex/releases/download/10.20221212/git-annex-standalone_10.20221212-1.ndall%2B1_amd64.deb
+2022-12-21T15:10:33+0000 [INFO    ] datalad_installer Running: sudo dpkg -i /tmp/tmpah14ch03/git-annex-standalone_10.20221212-1.ndall+1_amd64.deb
+Selecting previously unselected package git-annex-standalone.
+(Reading database ... 236921 files and directories currently installed.)
+Preparing to unpack .../git-annex-standalone_10.20221212-1.ndall+1_amd64.deb ...
+Unpacking git-annex-standalone (10.20221212-1~ndall+1) ...
+Setting up git-annex-standalone (10.20221212-1~ndall+1) ...
+Processing triggers for mailcap (3.70+nmu1ubuntu1) ...
+Processing triggers for hicolor-icon-theme (0.17-2) ...
+Processing triggers for man-db (2.10.2-1) ...
+2022-12-21T15:10:35+0000 [INFO    ] datalad_installer git-annex is now installed at /usr/bin/git-annex
+```
+
+or may be that is an issue with `rclone`? in this case it was
+
+```
+Run datalad-installer --sudo ok rclone=v1.59.2 -m downloads.rclone.org
+2022-12-21T15:10:35+0000 [INFO    ] datalad_installer Writing environment modifications to /tmp/dl-env-aon5z6_f.sh
+2022-12-21T15:10:35+0000 [INFO    ] datalad_installer Installing rclone from downloads.rclone.org
+2022-12-21T15:10:35+0000 [INFO    ] datalad_installer Version: v1.59.2
+2022-12-21T15:10:35+0000 [INFO    ] datalad_installer Bin dir: /usr/local/bin
+2022-12-21T15:10:35+0000 [INFO    ] datalad_installer Man dir: None
+2022-12-21T15:10:35+0000 [INFO    ] datalad_installer Downloading https://downloads.rclone.org/v1.59.2/rclone-v1.59.2-linux-amd64.zip
+2022-12-21T15:10:38+0000 [INFO    ] datalad_installer Moving /tmp/tmp75sde__c/rclone-v1.59.2-linux-amd64/rclone to /usr/local/bin/rclone
+2022-12-21T15:10:38+0000 [INFO    ] datalad_installer rclone is now installed at /usr/local/bin/rclone
+```
+
+I have tried to reproduce locally with exactly those installations of rclone and git-annex but not getting the same problem :-/
+
+I have also ran with `--debug` and got 
+```
+[2022-12-21 17:20:10.056928113] (Utility.Process) process [11603] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","commit-tree","c95a5c849daca7183eefc28c360942104d01e900","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2022-12-21 17:20:10.060448661] (Utility.Process) process [11603] done ExitSuccess
+[2022-12-21 17:20:10.060806165] (Utility.Process) process [11604] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-ref","refs/heads/git-annex","248cef615747c4aba64fbb475b0a03c8d2a78b27"]
+[2022-12-21 17:20:10.063957208] (Utility.Process) process [11604] done ExitSuccess
+[2022-12-21 17:20:10.066005436] (Utility.Process) process [11127] done ExitSuccess
+[2022-12-21 17:20:10.066266539] (Utility.Process) process [11114] done ExitSuccess
+[2022-12-21 17:20:10.066702845] (Utility.Process) process [11126] done ExitSuccess
+[2022-12-21 17:20:10.067107151] (Utility.Process) process [11125] done ExitSuccess
+[2022-12-21 17:20:10.067357854] (Utility.Process) process [11599] done ExitSuccess
+libgcc_s.so.1 must be installed for pthread_cancel to work
+/home/runner/work/git-annex-remote-rclone/git-annex-remote-rclone/tests/all-in-one.sh: line 125: 11083 Aborted                 (core dumped) git-annex drop -J5 --debug .
+Error: Process completed with exit code 134.
+```
+in https://github.com/DanielDent/git-annex-remote-rclone/actions/runs/3751417971/jobs/6372374929 .
+
+Any ideas Joey? 
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/dandi/bugs-done/standalone_needs_more_depends_-_libgcc-s1__63__/comment_1_93f4c8f86c58da7988bf1550867f8945._comment b/doc/projects/dandi/bugs-done/standalone_needs_more_depends_-_libgcc-s1__63__/comment_1_93f4c8f86c58da7988bf1550867f8945._comment
new file mode 100644
index 0000000000..3b49b31ae1
--- /dev/null
+++ b/doc/projects/dandi/bugs-done/standalone_needs_more_depends_-_libgcc-s1__63__/comment_1_93f4c8f86c58da7988bf1550867f8945._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-12-22T18:38:32Z"
+ content="""
+I'm a bit surprised git-annex is using `pthread_cancel`, since `strings`
+does not show it contains that symbol. Perhaps one of the other pthread
+symbols it uses ends up calling that.
+
+It does seem though from the message that it's git-annex and not a program
+it runs that is core dumping on this. Also I checked, and the rclone you 
+installed is a statically linked binary so I would not expect it to use
+`libgcc_s.so`. And  And git-annex-remote-rclone is a bash script, and bash
+doesn't use pthreads.
+
+(I do think that, in general, using the git-annex standalone tarball and
+then trying to run additional programs besides git-annex inside it is not
+going to always work well. Standalone interposes its own versions of libraries,
+which may not work with the other programs. There is already a todo about that, 
+[[todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__]].)
+
+I've added `libgcc_s.so.1` to the standalone build.
+"""]]
diff --git a/doc/projects/dandi/done.mdwn b/doc/projects/dandi/done.mdwn
new file mode 100644
index 0000000000..c298dba684
--- /dev/null
+++ b/doc/projects/dandi/done.mdwn
@@ -0,0 +1 @@
+This bug was closed, and has been archived.
diff --git a/doc/projects/dandi/potential.mdwn b/doc/projects/dandi/potential.mdwn
new file mode 100644
index 0000000000..89fe4d579d
--- /dev/null
+++ b/doc/projects/dandi/potential.mdwn
@@ -0,0 +1,5 @@
+These are TODOs that have been tagged as potentially being useful for
+[[/projects/Dandi]] or a related project to fund work on.
+
+[[!inline pages="todo/* and !todo/done and !link(todo/done) and tagged(projects/dandi/potential)"
+sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]]
diff --git a/doc/projects/datalad.mdwn b/doc/projects/datalad.mdwn
new file mode 100644
index 0000000000..8e8205f435
--- /dev/null
+++ b/doc/projects/datalad.mdwn
@@ -0,0 +1,30 @@
+TODOs for DataLad
+=================
+
+[[!inline pages="todo/* and !todo/done and !link(todo/done) and
+(author(mih) or author(ben) or author(kyle) or tagged(projects/datalad))" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]]
+
+
+<details>
+<summary>Done</summary>
+
+[[!inline pages="todo/* and !todo/done and link(todo/done) and
+(author(mih) or author(ben) or author(kyle) or tagged(projects/datalad))" feeds=no actions=yes archive=yes show=0 template=buglist]]
+
+</details>
+
+My bugs
+=======
+
+[[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and
+(author(mih) or author(ben) or author(kyle) or tagged(projects/datalad))" sort=mtime feeds=no actions=yes archive=yes show=0  template=buglist template=buglist]]
+
+
+
+<details>
+<summary>Fixed</summary>
+
+[[!inline pages="((bugs/* and !bugs/done and link(bugs/done)) or projects/datalad/bugs-done/*) and
+(author(mih) or author(ben) or author(kyle) or tagged(projects/datalad))" feeds=no actions=yes archive=yes show=0  template=buglist]]
+
+</details>
diff --git a/doc/projects/datalad/bugs-done/--debug_is_not_in_effect_if_precedes_-c.mdwn b/doc/projects/datalad/bugs-done/--debug_is_not_in_effect_if_precedes_-c.mdwn
new file mode 100644
index 0000000000..681f37707c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/--debug_is_not_in_effect_if_precedes_-c.mdwn
@@ -0,0 +1,69 @@
+### Please describe the problem.
+
+Identified while troubleshooting another [issue](https://git-annex.branchable.com/bugs/enableremote_stuck_with_a_recentish_git-annex/#comment-2116c5e109aaf39ffd62f3bdeeb14602)
+
+[[!format sh """
+$> 'git-annex' 'enableremote' --debug -cremote.target1.blah=1 'target1'      
+enableremote target1 ok
+
+$> 'git-annex' 'enableremote'  -cremote.target1.blah=1 --debug 'target1'     
+[2020-02-26 14:46:47.789794028] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","remote.target1.blah=1","show-ref","git-annex"]
+[2020-02-26 14:46:47.797917978] process done ExitSuccess
+[2020-02-26 14:46:47.798350533] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","remote.target1.blah=1","show-ref","--hash","refs/heads/git-annex"]
+[2020-02-26 14:46:47.802576899] process done ExitSuccess
+[2020-02-26 14:46:47.802884873] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","remote.target1.blah=1","log","refs/heads/git-annex..b1ab0b11fbbc94ffd3d52adb7a0e93c3d45d8b52","--pretty=%H","-n1"]
+[2020-02-26 14:46:47.813289406] process done ExitSuccess
+[2020-02-26 14:46:47.815873454] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","remote.target1.blah=1","cat-file","--batch"]
+[2020-02-26 14:46:47.818598891] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","remote.target1.blah=1","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2020-02-26 14:46:47.824657055] read: git ["config","--null","--list"]
+[2020-02-26 14:46:47.835897478] process done ExitSuccess
+enableremote target1 [2020-02-26 14:46:47.83652184] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","remote.target1.blah=1","config","remote.target1.annex-ignore","false"]
+[2020-02-26 14:46:47.842277017] process done ExitSuccess
+[2020-02-26 14:46:47.842703576] read: git ["config","--null","--list"]
+[2020-02-26 14:46:47.853478328] process done ExitSuccess
+ok
+[2020-02-26 14:46:47.855317715] process done ExitSuccess
+[2020-02-26 14:46:47.856835556] process done ExitSuccess
+
+"""]]
+
+I consider it a bug since options shouldn't be order dependent, and even if they were -- `--debug` is listed before `-c` in `git annex enableremote --help`:
+
+[[!format sh """
+$> git annex enableremote --help
+git-annex enableremote - enables git-annex to use a remote
+
+Usage: git-annex enableremote [NAME K=V ...]
+
+Available options:
+  --force                  allow actions that may lose annexed data
+  -F,--fast                avoid slow operations
+  -q,--quiet               avoid verbose output
+  -v,--verbose             allow verbose output (default)
+  -d,--debug               show debug messages
+  --no-debug               don't show debug messages
+  -b,--backend NAME        specify key-value backend to use
+  -N,--numcopies NUMBER    override default number of copies
+  --trust REMOTE           override trust setting
+  --semitrust REMOTE       override trust setting back to default
+  --untrust REMOTE         override trust setting to untrusted
+  -c,--config NAME=VALUE   override git configuration setting
+  --user-agent NAME        override default User-Agent
+  --trust-glacier          Trust Amazon Glacier inventory
+  --notify-finish          show desktop notification after transfer finishes
+  --notify-start           show desktop notification after transfer starts
+  -h,--help                Show this help text
+
+For details, run: git-annex help enableremote
+
+$> git annex version             
+git-annex version: 7.20190819+git2-g908476a9b-1~ndall+1
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
+
+> fixed in [8.20200226-3-gc089f395b](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=c089f395b0c7d6416a3d4f2bf3211404acfd5b0e) --[[yarikoptic]]
diff --git a/doc/projects/datalad/bugs-done/--debug_is_not_in_effect_if_precedes_-c/comment_1_0f66414e629e31c2de868f8b7eeb7af5._comment b/doc/projects/datalad/bugs-done/--debug_is_not_in_effect_if_precedes_-c/comment_1_0f66414e629e31c2de868f8b7eeb7af5._comment
new file mode 100644
index 0000000000..badeb87ff9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/--debug_is_not_in_effect_if_precedes_-c/comment_1_0f66414e629e31c2de868f8b7eeb7af5._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-27T04:20:58Z"
+ content="""
+-c uses adjustGitRepo which calls changeGitRepo, which
+re-extracts the GitConfig. --debug uses changeGitConfig which 
+sets annexDebug in the GitConfig, which does not survive the changeGitRepo.
+
+There might be a broader problem here, as changeGitRepo is also
+called by setConfig in many parts of the code. I think it narrowly
+escapes being a problem, because by the time a command is started,
+it's already enabled debug output, and so the GitConfig being reloaded
+doesn't disable debugging.
+
+Other calls to changeGitConfig could also be a problem, if followed by
+an adjustGitRepo which loses those changes. There are only a few others,
+look probably ok, but this would be an easy gotcha to hit later.
+
+So changeGitConfig needs to make a config change that persists across
+changeGitRepo.
+
+Done.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips.mdwn b/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips.mdwn
new file mode 100644
index 0000000000..4e804b39fa
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+
+
+### What steps will reproduce the problem?
+
+
+I am  plowing through on making git-annex available within conda-forge "natively" for Windows.  For now I just took the recently built installer, the one now available from [datasets.datalad.org](http://datasets.datalad.org/datalad/packages/windows/) and built on datalad-extensions github setup.  I just extracted git-annex component from the installer and placed them within conda hierarchy (installed `posix` package with all the needed basic tools.  Overall -- looks great, but:
+
+[[!format sh """
+    prop_view_roundtrips:                                 FAIL (0.30s)
+      *** Failed! Falsified (after 524 tests and 1 shrink):
+      "a"
+      MetaData (fromList [(MetaField "8",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet True) "\nD\EM",MetaValue (CurrentlySet True) "GO`!)",MetaValue (CurrentlySet False) "k\FS\CAN"]),(MetaField "dU",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet False) "\NUL44Vfm[\t",MetaValue (CurrentlySet True) "\nLMEgYc",MetaValue (CurrentlySet True) "\SO[",MetaValue (CurrentlySet True) "\FS\DC4\DLE\"3",MetaValue (CurrentlySet True) ";\f0&Wc\GS{^",MetaValue (CurrentlySet True) "D",MetaValue (CurrentlySet True) "c:"]),(MetaField "sV",fromList [MetaValue (CurrentlySet True) "",MetaValue (CurrentlySet False) "\STX8#w",MetaValue (CurrentlySet False) "\ny",MetaValue (CurrentlySet False) "\DC4qOq",MetaValue (CurrentlySet True) "\FSbqjq",MetaValue (CurrentlySet True) "T_bx%[lN",MetaValue (CurrentlySet True) "W0`",MetaValue (CurrentlySet True) "~ ueY"]),(MetaField "V",fromList [MetaValue (CurrentlySet False) "",MetaValue (CurrentlySet False) "\t\DC1~`\SOHv\DC1",MetaValue (CurrentlySet True) "\DLE3",MetaValue (CurrentlySet True) "/MZh$",MetaValue (CurrentlySet False) "0",MetaValue (CurrentlySet False) "MEulc",MetaValue (CurrentlySet True) "P5D",MetaValue (CurrentlySet True) "i|S,",MetaValue (CurrentlySet True) "x|C"])])
+      True
+      Use --quickcheck-replay=742853 to reproduce.
+"""]]
+
+unfortunately I cannot tell from that output what could be the problem.  Please let me know if hard to figure it out and I should provide access to such environment (ATM needs effort, so I do not want to spend time on that unless "no other way")
+
+And it seems it might be a flaky test -- I started another run, it is still running but I this test did not fail 
+
+```
+$ grep prop_view_roundtrips git-annex-test-miniconda*.log
+git-annex-test-miniconda-2.log:    prop_view_roundtrips:                                 OK (2.51s)
+git-annex-test-miniconda.log:    prop_view_roundtrips:                                 FAIL (0.30s)
+```
+
+Cheers,
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_1_3a2be0a1cd74c7dba3b07e1300ce2a30._comment b/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_1_3a2be0a1cd74c7dba3b07e1300ce2a30._comment
new file mode 100644
index 0000000000..a2dfd1a589
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_1_3a2be0a1cd74c7dba3b07e1300ce2a30._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-10-26T16:03:40Z"
+ content="""
+I can reproduce it in a windows VM running
+`git-annex test --quickcheck-replay=742853`
+
+These quickcheck tests test random input so not flaky exactly.
+
+Does not happen with that seed on linux, so it probably involves something
+encoding specific. An area where the windows port is known to have
+extensive problems.
+
+([[!commit 1b8026b2cbc8df0274082c5f08a8b4f8ca47c5c9]] was similar, 
+although that was MetaField and this appears to be MetaValue.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_2_1945040bcdf209b9a0faecd4a77e0f35._comment b/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_2_1945040bcdf209b9a0faecd4a77e0f35._comment
new file mode 100644
index 0000000000..6c1ae21b1b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_2_1945040bcdf209b9a0faecd4a77e0f35._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-10-26T17:57:12Z"
+ content="""
+you say \"windows port\", I say \"windows as a whole\", e.g. today revelation (or just a come back if I ran into it before but forgot) to me [was inability to have a file/directory named `con`...](https://github.com/datalad/datalad/issues/5097) - no bloody sense on how such design decision has happened and how it dragged all the way into the flagman of the 2020 product.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_3_06dd9606225cf881f7681fc27fb4833d._comment b/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_3_06dd9606225cf881f7681fc27fb4833d._comment
new file mode 100644
index 0000000000..029540d2ba
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_3_06dd9606225cf881f7681fc27fb4833d._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-10-26T18:41:27Z"
+ content="""
+Hmm, this uses viewedFiles, which generates filenames
+based on the MetaValue. Note use of pathProduct, which uses
+System.FilePath.combine.
+
+So, generating random ascii (including escape sequences)
+bytestrings, and passing them through decodeBS to generate FilePaths, 
+and then operating on those filepaths. What could possibly go wrong.
+
+And aha! I made pathProduct use System.FilePath.Windows.combine
+and was able to reproduce the test suite failure on Linux.
+
+And aha again: 
+
+	MetaValue (CurrentlySet True) "c:"
+
+Which of course breaks it on windows because it wanted to generate
+something like "bar/c:/baz/a" but instead it gets "c:/bar/baz/a"
+
+git-annex does replace '/' and '\' when generating these filenames.
+Not as a security measure (when the view branch is checked out, git's
+security checks apply same as any branch so it piggybacks on those),
+but to let the user build a view and successfully check it out
+when their metadata happens to include such stuff.
+
+However, windows does have enough special filenames and gotchas
+that it simply does not seem to make sense for git-annex to try to work
+around them all in the view code. If a MetaValue happens to end with a
+period, or is "nul", and so the generated filename is illegal on Windows,
+it'll blow up at checkout time, and I am ok with that.
+
+So I think it would make sense to also escape ':', but that's about as far
+as this should go. *Especially* because the filenames it generates need to
+roundtrip back to metadata cleanly, which is what this test case is
+testing. While I can finesse individual characters, it would be quite hard
+to make a filename w/o a trailing dot roundtrip back to one with it, for
+example.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_4_0c6b8a3b0a6fbd700b3c8934bfec199f._comment b/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_4_0c6b8a3b0a6fbd700b3c8934bfec199f._comment
new file mode 100644
index 0000000000..ffb30751c8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_4_0c6b8a3b0a6fbd700b3c8934bfec199f._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2021-01-22T16:44:58Z"
+ content="""
+did it come back,  I see 
+
+```
+2021-01-22T04:32:25.5012547Z     prop_view_roundtrips:                                 FAIL (0.09s)
+2021-01-22T04:32:25.5015902Z       *** Failed! Falsified (after 218 tests):
+2021-01-22T04:32:25.5016251Z       AssociatedFile (Just \"rdmBBP\")
+2021-01-22T04:32:25.5018130Z       MetaData (fromList [(MetaField \"CkL\",fromList [MetaValue (CurrentlySet False) \"\",MetaValue (CurrentlySet True) \"\SOH5:R9\EM\DC4\",MetaValue (CurrentlySet True) \"\STX\US\fL2\ACK|\\\r[$\",MetaValue (CurrentlySet False) \"\ETBRi\",MetaValue (CurrentlySet False) \"/\FS}\",MetaValue (CurrentlySet True) \"W\",MetaValue (CurrentlySet False) \"X=sQh\NAK^\",MetaValue (CurrentlySet False) \"l\SUB\a\"]),(MetaField \"jM\",fromList [MetaValue (CurrentlySet False) \"\",MetaValue (CurrentlySet False) \"\FSSivk\",MetaValue (CurrentlySet True) \"J'<\SYN\STXGJP\"]),(MetaField \"V\",fromList [MetaValue (CurrentlySet False) \"\",MetaValue (CurrentlySet True) \"\n\NUL\",MetaValue (CurrentlySet True) \"\r\",MetaValue (CurrentlySet False) \"+X\",MetaValue (CurrentlySet True) \"@aN\t~c\SIy\",MetaValue (CurrentlySet False) \"K>xq\",MetaValue (CurrentlySet True) \"a:\"]),(MetaField \"W\",fromList [MetaValue (CurrentlySet True) \"0\DC4qL\",MetaValue (CurrentlySet False) \"K\",MetaValue (CurrentlySet False) \"LD\DC3<M\",MetaValue (CurrentlySet False) \"a\v\",MetaValue (CurrentlySet True) \"dO\",MetaValue (CurrentlySet True) \"w\EOT\"])])
+2021-01-22T04:32:25.5020545Z       True
+2021-01-22T04:32:25.5020894Z       Use --quickcheck-replay=455629 to reproduce.
+```
+
+on https://github.com/datalad/git-annex/runs/1746587663?check_suite_focus=true with `8.20201129+git169-gaa07e68ed_x64`
+"""]]
diff --git a/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_4_c2f248745388b508337c5097baaa1979._comment b/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_4_c2f248745388b508337c5097baaa1979._comment
new file mode 100644
index 0000000000..1cf72d1acb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/1_test_failure_under_conda_on_Windows_10__58___prop__95__view__95__roundtrips/comment_4_c2f248745388b508337c5097baaa1979._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-01-22T16:59:55Z"
+ content="""
+Not sure if this is really the same bug, though certainly related. These
+quickcheck tests are fuzz tests, they can find numerous bugs, that's kind of
+the point of them. In any case, posting to a closed bug report risks your
+followup being lost and deprioritises it.
+
+The problem this new failure shows is that toViewPath is failing to escape the
+final character in the path in some cases. Which is not a windows-specific
+bug at all really, it could also happen with a metadata value such as "foo/"
+being set on linux. Fixed that bug.
+
+Which shows the point of these quickcheck fuzz tests: To be able to catch
+lots of different bugs with a single test case.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write.mdwn b/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write.mdwn
new file mode 100644
index 0000000000..b4f2645591
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write.mdwn
@@ -0,0 +1,42 @@
+### Please describe the problem.
+
+Since cron build of 20210828
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2021/08[master]git
+$> git grep -l 'Unable to remove all write permissions'
+cron-20210828/build-macos.yaml-403-69466103-failed/2_test-annex (crippled-tmp).txt
+cron-20210828/build-macos.yaml-403-69466103-failed/test-annex (crippled-tmp)/8_Run tests.txt
+cron-20210829/build-macos.yaml-404-69466103-failed/2_test-annex (crippled-tmp).txt
+cron-20210829/build-macos.yaml-404-69466103-failed/test-annex (crippled-tmp)/8_Run tests.txt
+cron-20210830/build-macos.yaml-405-69466103-failed/2_test-annex (crippled-tmp).txt
+cron-20210830/build-macos.yaml-405-69466103-failed/test-annex (crippled-tmp)/8_Run tests.txt
+cron-20210831/build-macos.yaml-406-69466103-failed/2_test-annex (crippled-tmp).txt
+cron-20210831/build-macos.yaml-406-69466103-failed/test-annex (crippled-tmp)/8_Run tests.txt
+```
+
+we got two test fails on a crippled FS on Mac (does not happen on linux afaik)
+
+[example CI log](https://github.com/datalad/git-annex/runs/3468283573?check_suite_focus=true)
+
+Both look like
+
+```
+2021-08-31T02:15:42.0758760Z     magic:                                                OK (2.41s)
+2021-08-31T02:15:42.6972710Z     import:                                               FAIL (0.62s)
+2021-08-31T02:15:42.6973680Z       ./Test/Framework.hs:57:
+2021-08-31T02:15:42.6974230Z       import failed (transcript follows)
+2021-08-31T02:15:42.6974760Z       import import1/f
+2021-08-31T02:15:42.6976570Z         Unable to remove all write permissions from /Volumes/crippledfs/importtestvjfjz3/import1/f -- perhaps it has an xattr or ACL set.
+2021-08-31T02:15:42.6977430Z       failed
+2021-08-31T02:15:42.6977830Z       import: 1 failed
+2021-08-31T02:15:44.1985050Z     reinject:                                             OK (1.50s)
+```
+
+[here is the script](https://github.com/datalad/git-annex/blob/master/.github/workflows/tools/setup_crippledfs#L24) to setup such a crippled (FAT32) FS on OSX.
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] (provisionally, waiting on test run) --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_1_22a1f4b025a6046e4d11f90590a6e4bd._comment b/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_1_22a1f4b025a6046e4d11f90590a6e4bd._comment
new file mode 100644
index 0000000000..038f8ed29b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_1_22a1f4b025a6046e4d11f90590a6e4bd._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-09-01T13:48:57Z"
+ content="""
+Seems that mounting that way on OSX results in a FS where files are always mode
+777 and the permissions cannot be changed.
+
+When I tried using git-annex on such a FS, I saw:
+
+	datalads-imac:x joey$ git annex init
+	init
+	  Detected a filesystem without fifo support.
+	
+	  Disabling ssh connection caching.
+	
+	  Filesystem allows writing to files whose write bit is not set.
+	
+	  Detected a crippled filesystem.
+
+And it skips the new permissions check when on a crippled filesystem.
+
+But in that that test run, it seems it is failing to detect a crippled
+filesystem. Both because of the failure and also the test suite does
+not even run the "v8 unlocked" tests when it detects a crippled filesystem.
+
+Is the test suite running as root? Looks like probably yes. Running as
+root prevents detecting the issue that made it use a crippled FS above. And it
+seems that, when a FAT fs is mounted on OSX that way, symlinks actually work
+(!!!) so the other crippled FS tests also don't notice a problem.
+
+So, the fix should be for init to also test if it can remove the write
+bits from a file, and it should try that test even when root.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_2_71e985981c14780cc172a07beb0e9854._comment b/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_2_71e985981c14780cc172a07beb0e9854._comment
new file mode 100644
index 0000000000..b43efea8b6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_2_71e985981c14780cc172a07beb0e9854._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2021-09-01T16:22:22Z"
+ content="""
+> Is the test suite running as root? Looks like probably yes. 
+
+FWIW, it is a `runner` user  [ref](https://github.com/datalad/git-annex/pull/76/checks?check_run_id=3486443350#step:8:1) (did in a temp [PR](https://github.com/datalad/git-annex/pull/76)) who is not `root` but is part of the `admin` group thus with super privileges indeed (that is why I guess we can also use `hdiutil` directly to mount that crippled FS).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_3_ac3fe75560c020015ecca615cf0e7abe._comment b/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_3_ac3fe75560c020015ecca615cf0e7abe._comment
new file mode 100644
index 0000000000..65cf9084d4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_3_ac3fe75560c020015ecca615cf0e7abe._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-09-02T16:22:56Z"
+ content="""
+OSX test is still failing after that fix, reopened.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_4_3bdf724f5e9203424b7cb5630fb49a46._comment b/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_4_3bdf724f5e9203424b7cb5630fb49a46._comment
new file mode 100644
index 0000000000..0b400facce
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_4_3bdf724f5e9203424b7cb5630fb49a46._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-09-02T16:26:14Z"
+ content="""
+My prior analysis seems right, as far as it running as root would go, but it is
+not running as root. So I missed something.
+
+The test failures are both of `git-annex import`.
+Otherwise locking down files does succeed. The difference with import
+must be that the file located in a directory outside the repository.
+
+Aha... The test suite is being run with TEMPDIR set to the crippled FS,
+but `.t` is in another, non-crippled FS. A very smart idea to test that,
+although I think this import test is the only one that actually uses
+TEMPDIR. (Reading the workflow file, I think it was maybe expected that
+all the tests would run in TEMPDIR, but they don't; `git-annex test`
+writes to `./.t`, other than this one test.
+
+When the import directory is on a crippled FS, and the repo
+is not, it will think the FS is not crippled. Then it fails
+to remove write perms from the file while it is in the import
+directory, and the perm check then fails.
+
+So, I think it should skip the perm check when doing the initial lockdown
+of the file it's going to import.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_5_46acb87752c0f0574d8f3b91fdfb1697._comment b/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_5_46acb87752c0f0574d8f3b91fdfb1697._comment
new file mode 100644
index 0000000000..09332c3e0d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/2_mac_crippled_FS__58___Unable_to_remove_all_write/comment_5_46acb87752c0f0574d8f3b91fdfb1697._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-09-02T17:39:20Z"
+ content="""
+Ok, fixed some more, hopefully all the way this time..
+"""]]
diff --git a/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password.mdwn b/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password.mdwn
new file mode 100644
index 0000000000..633c8a3b62
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password.mdwn
@@ -0,0 +1,66 @@
+### Please describe the problem.
+
+There was some recent work to ["centralize" such prompts](https://git-annex.branchable.com/devblog/day_457__improved_ssh_password_prompting/) but it seems some are still "leaking through" multiple times.  May be it is because there are 2 available repos on that remote host, so annex generates one per each of those? (although it knows only about origin)
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170810+gitgff6f9e203-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+$> git annex get -J5 .
+get R042/R042-2013-08-16/R042-2013-08-16-CSC01a.ncs get R042/R042-2013-08-16/R042-2013-08-16-CSC02a.ncs get R042/R042-2013-08-16/R042-2013-08-16-CSC03a.ncs get R042/R042-2013-08-16/R042-2013-08-16-CSC05a.ncs get R042/R042-2013-08-16/R042-2013-08-16-CSC04a.ncs (from datalad-archives...) 
+(from datalad-archives...) (from datalad-archives...) 
+
+(from datalad-archives...) 
+(from datalad-archives...) 
+[ERROR] Failed to run ['git-annex', 'get', '--key', 'MD5E-s237624713--dbdc4079b005b8b7f1549e00647b36d6.zip'] under '/mnt/btrfs/datasets/datalad/crawl/workshops/mind-2017/MotivationalT'. Exit code=1. out=get MD5E-s237624713--dbdc4079b005b8b7f1549e00647b36d6.zip (transfer already in progress, or unable to take transfer lock) 
+|   Unable to access these remotes: origin
+| 
+|   Try making some of these repositories available:
+|       aaa0bc14-51fc-45c8-81c2-76dff067755b -- mvdm@atlantis.hpcc.dartmouth.edu:~/data/mind-2017/MotivationalT_
+|       f7f97046-ea49-4af1-9f5a-8475a5ea1e0a -- yhalchen@atlantis.hpcc.dartmouth.edu:~/mind-2017/MotivationalT [origin]
+| failed
+|  err=git-annex: get: 1 failed
+|  
+[ERROR] Failed to run ['git-annex', 'get', '--key', 'MD5E-s237624713--dbdc4079b005b8b7f1549e00647b36d6.zip'] under '/mnt/btrfs/datasets/datalad/crawl/workshops/mind-2017/MotivationalT'. Exit code=1. out=get MD5E-s237624713--dbdc4079b005b8b7f1549e00647b36d6.zip (transfer already in progress, or unable to take transfer lock) 
+|   Unable to access these remotes: origin
+| 
+|   Try making some of these repositories available:
+|       aaa0bc14-51fc-45c8-81c2-76dff067755b -- mvdm@atlantis.hpcc.dartmouth.edu:~/data/mind-2017/MotivationalT_
+|       f7f97046-ea49-4af1-9f5a-8475a5ea1e0a -- yhalchen@atlantis.hpcc.dartmouth.edu:~/mind-2017/MotivationalT [origin]
+| failed
+|  err=git-annex: get: 1 failed
+|  
+[ERROR] Failed to fetch any archive containing SHA256E-s17136940--0501aab6b4d1ce0565921728bc92ef74f81edf0d7bcd5a77946ca58f977f2537.ncs. Tried: ['MD5E-s237624713--dbdc4079b005b8b7f1549e00647b36d6.zip'] 
+[ERROR] Failed to fetch any archive containing SHA256E-s17136940--8b3b08310db20ca7e3e784a21f935a78f8669efdf1396168596411f1e355e43b.ncs. Tried: ['MD5E-s237624713--dbdc4079b005b8b7f1549e00647b36d6.zip'] 
+(from origin...) (from origin...) [ERROR] Failed to run ['git-annex', 'get', '--key', 'MD5E-s237624713--dbdc4079b005b8b7f1549e00647b36d6.zip'] under '/mnt/btrfs/datasets/datalad/crawl/workshops/mind-2017/MotivationalT'. Exit code=1. out=get MD5E-s237624713--dbdc4079b005b8b7f1549e00647b36d6.zip (transfer already in progress, or unable to take transfer lock) 
+|   Unable to access these remotes: origin
+| 
+|   Try making some of these repositories available:
+|       aaa0bc14-51fc-45c8-81c2-76dff067755b -- mvdm@atlantis.hpcc.dartmouth.edu:~/data/mind-2017/MotivationalT_
+|       f7f97046-ea49-4af1-9f5a-8475a5ea1e0a -- yhalchen@atlantis.hpcc.dartmouth.edu:~/mind-2017/MotivationalT [origin]
+| failed
+|  err=git-annex: get: 1 failed
+|  
+[ERROR] Failed to fetch any archive containing SHA256E-s17136940--08ce5a67c7fc09f02b994a3987812a75727eaf51f3e70fa7e1030dae934f9fbc.ncs. Tried: ['MD5E-s237624713--dbdc4079b005b8b7f1549e00647b36d6.zip'] 
+(from origin...) [ERROR] Failed to run ['git-annex', 'get', '--key', 'MD5E-s237624713--dbdc4079b005b8b7f1549e00647b36d6.zip'] under '/mnt/btrfs/datasets/datalad/crawl/workshops/mind-2017/MotivationalT'. Exit code=1. out=get MD5E-s237624713--dbdc4079b005b8b7f1549e00647b36d6.zip (transfer already in progress, or unable to take transfer lock) 
+|   Unable to access these remotes: origin
+| 
+|   Try making some of these repositories available:
+|       aaa0bc14-51fc-45c8-81c2-76dff067755b -- mvdm@atlantis.hpcc.dartmouth.edu:~/data/mind-2017/MotivationalT_
+|       f7f97046-ea49-4af1-9f5a-8475a5ea1e0a -- yhalchen@atlantis.hpcc.dartmouth.edu:~/mind-2017/MotivationalT [origin]
+| failed
+|  err=git-annex: get: 1 failed
+|  
+[ERROR] Failed to fetch any archive containing SHA256E-s17136940--bc145f07c79584181cad3763a763a2ea047282bd41153d20a63d85a44fb27a7f.ncs. Tried: ['MD5E-s237624713--dbdc4079b005b8b7f1549e00647b36d6.zip'] 
+(from origin...) yhalchen@discovery.dartmouth.edu's password: yhalchen@discovery.dartmouth.edu's password: 
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> warning added; [[done]] --[[Joey]] 
diff --git a/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_1_f78784304b46b77d334f74c827d0889b._comment b/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_1_f78784304b46b77d334f74c827d0889b._comment
new file mode 100644
index 0000000000..8602847694
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_1_f78784304b46b77d334f74c827d0889b._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2017-08-12T04:08:04Z"
+ content="""
+ha -- if I do specify `--from=origin` -- only 1 prompt
+
+[[!format sh \"\"\"
+$> git annex get -J5 --from=origin .
+get R042/R042-2013-08-16/R042-2013-08-16-CSC01a.ncs (from origin...) get R042/R042-2013-08-16/R042-2013-08-16-CSC03a.ncs (from origin...) get R042/R042-2013-08-16/R042-2013-08-16-CSC02a.ncs (from origin...) get R042/R042-2013-08-16/R042-2013-08-16-CSC04a.ncs (from origin...) get R042/R042-2013-08-16/R042-2013-08-16-CSC05a.ncs (from origin...) yhalchen@discovery.dartmouth.edu's password:
+git-annex-shell: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
+  
+  Unable to run git-annex-shell on remote .
+
+git-annex-shell: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
+  
+  Unable to run git-annex-shell on remote .
+
+git-annex-shell: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
+  
+  Unable to run git-annex-shell on remote .
+
+git-annex-shell: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
+  
+  Unable to run git-annex-shell on remote .
+
+SHA256E-s17136940--08ce5a67c7fc09f02b994a3987812a75727eaf51f3e70fa7e1030dae934f9fbc.ncs
+              0   0%    0.00kB/s    0:00:00  SHA256E-s17136940--bc145f07c79584181cad3763a763a2ea047282bd41153d20a63d85a44fb27a7f.ncs
+              0   0%    0.00kB/s    0:00:00  SHA256E-s17136940--c3a8af948c77a2df422eae50807a6e7e6e5db7a3451a562bca529d3f1a1a234f.ncs
+              0   0%    0.00kB/s    0:00:00  git-annex-shell: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
+
+\"\"\"]]
+"""]]
diff --git a/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_2_62a5cc7cd6b8b06850fb32b76121ad82._comment b/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_2_62a5cc7cd6b8b06850fb32b76121ad82._comment
new file mode 100644
index 0000000000..f7f3f5da58
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_2_62a5cc7cd6b8b06850fb32b76121ad82._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-08-15T16:43:07Z"
+ content="""
+The improvements around ssh password prompting require ssh connection
+caching to work. If a ssh connection fails because the wrong password is
+entered or because there's no usable tty or whatever, there's no cached
+ssh connection to reuse, so the next attempt to access that host will
+result in another password prompt.
+
+Also, datalad does not seem to be running git-annex with -J. So it *can't*
+be trying to make two ssh connection at the same time. My recent work on
+ssh password prompting was mostly to fix cases where git-annex is run with
+-J.
+
+It's also possible that some ssh configuration that I don't know of could
+make ssh password prompt even when git-annex is running it with
+`BatchMode=true` to avoid password prompts (in order to test if the ssh
+connection is already up). That would then result in two ssh password
+prompts, one after the other, which seems to match your transcript.
+
+If you have only one remote, specifying `--from=origin` won't change
+anything. Entering the right password would change something there though..
+"""]]
diff --git a/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_3_f621e615a745910b4e28f91b27132c0e._comment b/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_3_f621e615a745910b4e28f91b27132c0e._comment
new file mode 100644
index 0000000000..4745d9990a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_3_f621e615a745910b4e28f91b27132c0e._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="the issue persists"
+ date="2019-11-01T18:12:27Z"
+ content="""
+Ran into the same problem again, and it is not clear to me either connection caching is enabled or not (and why?):
+
+[[!format sh \"\"\"
+[d31548v@discovery7 bids]$ git -c annex.sshcaching=true annex --debug get -J2 --from=origin sub-sid000005
+[2019-11-01 14:10:56.178577] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2019-11-01 14:10:56.475956] process done ExitSuccess
+[2019-11-01 14:10:56.47622] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2019-11-01 14:10:56.836271] process done ExitSuccess
+[2019-11-01 14:10:56.865928] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..8a694d5c54eb81b1e5c5446fa63bdcd13daa34b3\",\"--pretty=%H\",\"-n1\"]
+[2019-11-01 14:10:57.229787] process done ExitSuccess
+[2019-11-01 14:10:57.234655] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2019-11-01 14:10:57.23592] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2019-11-01 14:10:57.546203] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2019-11-01 14:10:57.780246] process done ExitSuccess
+[2019-11-01 14:10:57.780454] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2019-11-01 14:10:58.097345] process done ExitSuccess
+[2019-11-01 14:10:58.09754] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"sub-sid000005\"]
+[2019-11-01 14:10:58.298181] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2019-11-01 14:10:58.29998] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2019-11-01 14:10:58.305022] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2019-11-01 14:10:58.306024] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2019-11-01 14:10:58.62005] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2019-11-01 14:10:58.621714] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2019-11-01 14:10:58.632596] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2019-11-01 14:10:58.6338] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+get sub-sid000005/ses-actions1/fmap/sub-sid000005_ses-actions1_acq-25mm_magnitude2.nii.gz get sub-sid000005/ses-actions1/fmap/sub-sid000005_ses-actions1_acq-25mm_magnitude1.nii.gz (from origin...) (from origin...) 
+[2019-11-01 14:10:59.489719] chat: ssh [\"yohtest@rolando.cns.dartmouth.edu\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/Haxby/Sam/1021_actions' '--debug' 'fd3f7af9-cf7d-4d7e-8efd-30e6bedf838d' --uuid d839134c-3afe-4456-920a-e280ce0fdf2a\"]
+
+[2019-11-01 14:10:59.553029] chat: ssh [\"yohtest@rolando.cns.dartmouth.edu\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/Haxby/Sam/1021_actions' '--debug' 'fd3f7af9-cf7d-4d7e-8efd-30e6bedf838d' --uuid d839134c-3afe-4456-920a-e280ce0fdf2a\"]
+yohtest@rolando.cns.dartmouth.edu's password: yohtest@rolando.cns.dartmouth.edu's password: 
+
+
+[d31548v@discovery7 bids]$ git annex version
+git-annex version: 7.20191024-g6dc2272
+\"\"\"]]
+Could you hint me on what/where to dig?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_4_43e5a90d6215b414f4e3357ea91af663._comment b/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_4_43e5a90d6215b414f4e3357ea91af663._comment
new file mode 100644
index 0000000000..7ae63772c4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_4_43e5a90d6215b414f4e3357ea91af663._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-01-23T15:51:46Z"
+ content="""
+I notice that debug output has no BatchMode=true in any ssh call. But
+the version of git-annex you show always runs ssh with that when
+-J is used, unless sshcaching is disabled.
+
+More evidence that sshcaching is disabled in your transcript is that when
+it does run ssh, it does not pass -S.
+
+I think the repository must be on a crippled filesystem, on which
+git-annex can't do ssh connection caching, because the filesystem
+does not support unix sockets. (Or it potentially could be crippled in some
+other way.) So it ignores the annex.sshcaching setting.
+You could work around this by setting the (undocumented)
+GIT_ANNEX_TMP_DIR to some temporary directory on a non-crippled filesystem.
+
+I'm going to add a warning message in this situation.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_5_27b5669cecba4863ce296049804e82af._comment b/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_5_27b5669cecba4863ce296049804e82af._comment
new file mode 100644
index 0000000000..10f405fd1f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/2_ssh_connection_prompts_for_password/comment_5_27b5669cecba4863ce296049804e82af._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2020-01-23T17:51:58Z"
+ content="""
+Thank you Joey!  I can only confirm that the file system was likely a crippled/NFS one... So we would likely need to do some sensing on DataLad side and instruct git-annex. Will continue on our end at https://github.com/datalad/datalad/issues/4075
+"""]]
diff --git a/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file.mdwn b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file.mdwn
new file mode 100644
index 0000000000..eb5b79a5f4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file.mdwn
@@ -0,0 +1,79 @@
+In datalad test builds with git-annex 7.20191114+git43-ge29663773, one
+of the new test failures is due to an unexpectedly dirty repository
+([related datalad issue][0]).  The dirty status comes from a file that
+was tracked in Git switching over to an annex pointer file.  Here's a
+script that distills enough of the test to trigger the failure on my
+end.
+
+[[!format sh """
+#!/bin/sh
+
+set -eu
+
+assert_clean () {
+    if test -n "$(git status --porcelain)"
+    then
+        printf "\n\nUnexpectedly dirty:\n" >&2
+        git status >&2
+        git diff >&2
+        exit 1
+    fi
+}
+
+cd "$(mktemp -d --tmpdir gx-pointer-dirty-XXXXXXX)"
+git init && git annex init
+
+printf content-git >file-git
+git -c annex.largefiles=nothing annex add -- file-git
+git commit -m'file-git added'
+assert_clean
+
+printf content-annex >file-annex
+git -c annex.largefiles=anything annex add -- file-annex
+git commit -m'file-annex annexed'
+assert_clean
+"""]]
+
+On Travis as well as my local machine, the failure is intermittent,
+but seems to happen much more often than not.  In the failing case,
+the last assert_clean call shows:
+
+```
+Unexpectedly dirty:
+On branch master
+Changes not staged for commit:
+        modified:   file-git
+
+no changes added to commit
+diff --git a/file-git b/file-git
+index d1c416a..b41ca32 100644
+--- a/file-git
++++ b/file-git
+@@ -1 +1 @@
+-content-git
+\ No newline at end of file
++/annex/objects/SHA256E-s11--726732d25826965592478fcc7c145d5a10fa1aa70c49fe3a4f847174b6d8889c
+```
+
+I see the failure with git-annex built from the latest master
+b962471c2 (2019-12-12).  Bisecting against the git-annex repo (with a
+commit being marked "bad" if there was a failure within ten runs of the
+above script), points to ec08b66bd (shouldAnnex: check isInodeKnown,
+2019-10-23) as the first bad commit.  Just looking at the topic of 
+the commit, that result seems plausible to me.
+
+### Other details
+
+My git version 2.24.1 and locally I'm building git-annex through guix.
+On the failing Travis run, git-annex 7.20191114+git43-ge29663773 came
+from neurodebian, and the git version was 2.24.0.
+
+Hopefully the script above is sufficient to trigger the issue on your end.
+Thanks for having a look.
+
+[0]: https://github.com/datalad/datalad/issues/3890
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_1_ea82bf47752807531870651653160f1c._comment b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_1_ea82bf47752807531870651653160f1c._comment
new file mode 100644
index 0000000000..6f93c91ffa
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_1_ea82bf47752807531870651653160f1c._comment
@@ -0,0 +1,97 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-12-26T16:56:38Z"
+ content="""
+The title makes it sound like a work tree file gets replaced with a
+dangling pointer file, which is not the case. A worktree file that was
+not annexed is is being added to the annex, if you choose to commit that
+state.
+
+For whatever reason, git becomes confused about whether this file is
+modified. I seem to recall that git distrusts information it recorded in
+its own index if the mtime of the index file is too close to the
+mtime recorded inside it, or something like that. (Likely as a
+workaround for mtime granularity issues with various filesystems.) Whatever
+the reason, git-annex is not involved in it; it will happen sometimes even
+when git-annex has not initialized the repo and is not being used.
+
+It's not normally a problem that git gets confused or distrusts its
+index or whatever, since all it does is stat the file, or
+feed it through the clean filter again, and if the file is not
+modified, nothing changes.
+
+Why does the clean filter decide to add the file to annex in this case?
+
+Well, because this is all happening inside this:
+	
+	git -c annex.largefiles=anything annex add -- file-annex
+
+And there you've told it to add all files to the annex with
+annex.largefiles=anything. So it does.
+
+To complete the description of what happens:
+`git-annex add` runs `git add` on the `file-annex` symlink it's adding. 
+`git add file-annex`, for whatever reason, decides to run the clean filter on
+file-git.
+The annex.largefiles=anything gets inherited through this chain of calls.
+
+While the resulting "change" does not get staged by `git add`
+(it was never asked to operate on that file), the clean filter
+duly ingests the content into the annex, and remembers its inode.
+So when the clean filter later gets run by `git status`, it sees an inode
+it knows it saw before, and assumes it should remain annexed.
+(This is why the commit that checks for known inodes was fingered by the
+bisection.)
+
+---
+
+Note that, you can accomplish the same thing without setting
+annex.largefiles, assuming a current version of git-annex:
+
+	git add file-git
+	git annex add file-annex
+
+I think the only reason for setting annex.largefiles in either of the two
+places you did is if there's a default value that you want to
+temporarily override?
+
+----
+
+Also, just touching file-git before the annex.largefiles=anything
+operation causes the same problem, again git-annex add runs git add
+file-annex, which runs the clean filter on file-git, which this time
+is legitimately modified.
+
+---
+
+Possible ways to improve this short of improving git's behavior:
+
+`git annex` could set annex.gitaddtoannex=false when it runs `git add`.
+Since git-annex never relies on `git add` adding files to the annex,
+that seems entirely safe to always do (perhaps even when running all git
+commands aside from git-annex commands of course). But, that would
+not help with a variant where rather than `git-annex add`,
+this is run:
+
+	git -c annex.largefiles=anything add file-annex
+
+The clean filter could delay long enough that git stops distrusting
+its index based on timestamps. A 1 second sleep if the file's mtime
+is too close to the current time works; I prototyped a patch doing that.
+But, that does not deal with the case
+mentioned above where file-git gets touched or legitimately modified.
+
+The clean filter could check if the file is already
+in the index but is not annexed, and avoid converting it to annexed.
+But that would prevent legitimate conversions from git to annexed
+as well, which rely on the same kind of use of annex.largefiles.
+
+Temporary overrides of annex.largefiles could be ignored by the clean
+filter. Same problem as previous.
+
+So, I think that fixing this will involve adding a new interface for
+converting between git and annexed files that does not involve
+-c annex.largefiles. That plus having the clean filter check for
+non-annexed files seems like the best approach.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_2_27faf0663265bd3855e98f7f1f382bdd._comment b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_2_27faf0663265bd3855e98f7f1f382bdd._comment
new file mode 100644
index 0000000000..a27979480b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_2_27faf0663265bd3855e98f7f1f382bdd._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-12-27T06:22:23Z"
+ content="""
+On second thought, making the clean filter check for non-annexed files
+would prevent use cases like annex.largefiles=largerthan(100kb)
+from working as the user intended and letting a small file start out
+non-annexed and get annexed once it gets too large. Users certianly rely on
+that and this bug that only affects an edge case does not justify breaking
+that.
+
+What would work to make the clean filter detect when a file's content
+has not changed, though its mtime (or inode) has changed. In that case,
+it's reasonable for the clean filter to ignore annex.largefiles and keep
+the content represented in git however it already was (non-annexed or
+annexed).
+
+To detect that, in the case where the file in the index is not annexed:
+First check if the file size is the same as the
+size in the index. If it is, run git hash-object on the file, and see if
+the sha1 is the same as in the index. This avoids hashing any unusually
+large files, so the clean filter only gets a bit slower.
+
+And when the file in the index is annexed, check if the file size is the
+same as the size of the annexed key. If it is, verify if the file content
+matches the key. (typically be hashing). Cases where keys lack size or
+don't use a checksum could lead to false positives or negatives though.
+Although, I've not managed to find a version of this bug that makes an
+annexed file get converted to git unintentionally, so maybe this part does
+not need to be done?
+
+----
+
+Or.. Since the root of the problem is temporarily overriding annex.largefiles,
+it could just be documented that it's not a good idea to use 
+-c annex.largefiles=anything/nothing, because such broad overrides
+can affect other files than the ones you intended.
+(And since the documented methods of converting files from annexed to git and
+git to annexed use such overrides, that documentation would need to be
+changed.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_3_37fb6d6361068f57c2068270ceb72ac0._comment b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_3_37fb6d6361068f57c2068270ceb72ac0._comment
new file mode 100644
index 0000000000..f4bebf7c93
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_3_37fb6d6361068f57c2068270ceb72ac0._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-12-27T17:11:42Z"
+ content="""
+A variant of this where an annexed unlocked file is added first,
+then the file is touched, and then some other file is added
+with -c annex.largefiles=nothing does result in the clean filter sending
+the whole annexed file content back to git, rather than keeping it annexed.
+For whatever reason, git does not store that content in .git/objects or
+update the index for that file though, so it doesn't show up as a change.
+
+So *apparently* that variant is only potentially an expensive cat of a
+large annexed file, and does not need to be dealt with. Unless git
+sometimes behaves otherwise.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_4_4c3b233aa1c6b0b6c0b0d7519b5877a1._comment b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_4_4c3b233aa1c6b0b6c0b0d7519b5877a1._comment
new file mode 100644
index 0000000000..22b7852084
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_4_4c3b233aa1c6b0b6c0b0d7519b5877a1._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-12-27T18:41:12Z"
+ content="""
+It's almost possible to get the same unwanted conversion without any git
+races:
+
+	echo content-git > file-git
+	sleep 2
+	git add file-git
+	git commit -m add
+
+	echo foo > file-git
+	echo content-annex > file-annex
+	git -c annex.largefiles=anything annex add file-annex
+
+In this case, git currently does not run the modified file-git through the
+clean filter in the last line, so the annex.largefiles=anything doesn't
+affect it.
+
+But, as far as I can see, there's nothing preventing a future version
+of git from deciding it does want to run file-git through the clean filter
+in this case.
+
+I am not going to try to prevent against such a thing happening.
+As far as I can see, anything that the clean filter can possibly do to
+avoid such a situation will cripple existing uses cases of
+annex.largefiles, like largerthan() as mentioned above.
+The user has told git-annex to annex "anything", and if git
+decides to run the clean filter while that is in effect, caveat emptor.
+
+Which is not to say I'm not going to fix the specific case this bug was
+filed about. I actually have a fix developed now. But just to say that
+setting annex.largefiles=anything/nothing temporarily is a blunt instrument,
+and you risk accidental conversion when using it, and so it would be a good
+idea to not do that.
+
+One idea: Make `git-annex add --annex` and `git-annex add --git`
+add a specific file to annex or git, bypassing annex.largefiles and all
+other configuration and state. This could also be used to easily switch
+a file from one storage to the other. I'd hope the existence of that
+would prevent one-off setting of annex.largefiles=anything/nothing.
+[[todo/git_annex_add_option_to_control_to_where]]
+"""]]
diff --git a/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_5_d1d23d3884fcbef3c8715ebdf8791f01._comment b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_5_d1d23d3884fcbef3c8715ebdf8791f01._comment
new file mode 100644
index 0000000000..e9da0fd0d5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_5_d1d23d3884fcbef3c8715ebdf8791f01._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 5"
+ date="2019-12-28T21:06:46Z"
+ content="""
+Thanks for the explanation and the fix.
+
+> For whatever reason, git becomes confused about whether this file is
+> modified. I seem to recall that git distrusts information it recorded in
+> its own index if the mtime of the index file is too close to the
+> mtime recorded inside it, or something like that.
+
+I see.  I think the problem and associated workaround you're referring
+to is described in git's Documentation/technical/racy-git.txt.
+
+> Note that, you can accomplish the same thing without setting
+> annex.largefiles, assuming a current version of git-annex:
+>
+> 	git add file-git
+> 	git annex add file-annex
+>
+> I think the only reason for setting annex.largefiles in either of the two
+> places you did is if there's a default value that you want to
+> temporarily override?
+
+Right.  DataLad's methods that are responsible for calling out to `git
+annex add` have a `git={None,False,True}` parameter.  By default
+(`None`), DataLad just calls `git annex add ...` and let's any
+configuration in the repo control whether the file goes to git or is
+annexed.  But with `git=True` or `git=False`, the `annex add` call
+includes a `-c annex.largefiles=` argument with a value of `nothing`
+or `anything`, respectively.
+
+> But just to say that setting annex.largefiles=anything/nothing
+> temporarily is a blunt instrument, and you risk accidental
+> conversion when using it, and so it would be a good idea to not do
+> that.
+
+Noted.  As mentioned above, DataLad's default behavior is to honor the
+repo's `annex.largefiles` configuration.  And the documentation for
+`datalad save`, DataLad's main user-facing entry point for `annex
+add`, recommends that the user configure .gitattributes rather than
+using the option that leads calling `annex add` with `-c
+annex.largefiles=nothing`.
+
+> One idea: Make `git-annex add --annex` and `git-annex add --git`
+> add a specific file to annex or git, bypassing annex.largefiles and all
+> other configuration and state. This could also be used to easily switch
+> a file from one storage to the other. I'd hope the existence of that
+> would prevent one-off setting of annex.largefiles=anything/nothing.
+
+As far as I can see, those flags would completely cover DataLad's
+one-off setting of `annex.largefiles=anything/nothing`.  They map
+directly to DataLad's `git=False/True` option described above.  So,
+from DataLad's perspective, they'd be very useful and welcome.
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_6_b713bf610c4f4d9c2463b61721bce406._comment b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_6_b713bf610c4f4d9c2463b61721bce406._comment
new file mode 100644
index 0000000000..9dba03060f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/A_case_where_file_tracked_by_git_unexpectedly_becomes_annex_pointer_file/comment_6_b713bf610c4f4d9c2463b61721bce406._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-01-01T17:41:13Z"
+ content="""
+I've added git-annex add --force-large and --force-small, which would be
+good to use to avoid this kind of too-broad overriding problem in the future.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e.mdwn b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e.mdwn
new file mode 100644
index 0000000000..3b84e4f973
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e.mdwn
@@ -0,0 +1,66 @@
+In the datalad test suite, a test involving one of our special remotes
+hangs after 7245a9ed5 (Improve shutdown process for external special
+remotes and external backends, 2020-11-02).  The hang depends on the
+remote program creating an SSH socket but not cleaning it up on
+failure.  That's being addressed on our end
+(<https://github.com/datalad/datalad/pull/5151>).
+
+While that's clearly bad handling on the part of datalad's special
+remote, I'm opening this bug report in case the above stall indicates
+that 7245a9ed5 brings an increased susceptibility to hanging that's
+worth worrying about.  Based on 7245a9ed5's commit message, it sounds
+like that resolved some hanging on Windows (and generally sounds like
+a good change), so it probably makes sense keep that at the expense of
+hanging that is restricted to buggy special remotes.  But I don't have
+a good enough understanding of the issue to know if it's limited to
+misbehaving special remotes, or if perhaps there's a way to avoid both
+hangs.
+
+In case it's helpful, here's a demo that tweaks the example special
+remote to trigger a hang:
+
+[[!format sh """
+set -eu
+
+ga_srcdir="$(realpath "${1?requires git-annex source directory as first argument}")"
+host="${2?requires ssh host as second argument}"
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/gx-testremote-XXXXXXX)"
+top="$PWD"
+
+mkdir bin
+git -C "$ga_srcdir" cat-file -p cfae74ae25a791a8dbf8b476fe17d5c6feacd8b0 \
+    >bin/git-annex-remote-foo
+
+# Open a socket in setupcreds().
+cmd="ssh -fN -o ControlMaster=auto -o ControlPersist=15m -o ControlPath=$top/socket $host"
+sed -i "s|setupcreds () {|&\\n\\t$cmd|" bin/git-annex-remote-foo
+
+chmod +x bin/git-annex-remote-foo
+export PATH="$top/bin:$PATH"
+
+git annex version
+git init a
+(
+    cd a
+    git annex init main
+    # This will trigger an INITREMOTE-FAILURE failure because
+    # MYPASSWORD and MYLOGIN are not set.  This hangs after 7245a9ed5.
+    git annex initremote d --debug \
+        type=external externaltype=foo directory="$top/d" encryption=none
+)
+"""]]
+
+```
+$ sh /tmp/gx-failed-dir-hang.sh ~/src/haskell/git-annex smaug
+git-annex version: 8.20201103
+build flags: Assistant Pairing Inotify MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.4 feed-1.2.0.1 ghc-8.6.5 http-client-0.6.4 persistent-sqlite-2.10.5.2 uuid-1.3.13
+[... 40 lines ...]
+[2020-11-12 11:40:01.886013862] /tmp/gx-testremote-3MudMuQ/bin/git-annex-remote-foo[1] --> SETCONFIG directory /tmp/gx-testremote-3MudMuQ/d
+[2020-11-12 11:40:02.451619481] /tmp/gx-testremote-3MudMuQ/bin/git-annex-remote-foo[1] --> INITREMOTE-FAILURE You need to set MYPASSWORD and MYLOGIN environment variables when running initremote.
+```
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]]
diff --git a/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_1_c0a98d1391d4426182d3d43651ad67e5._comment b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_1_c0a98d1391d4426182d3d43651ad67e5._comment
new file mode 100644
index 0000000000..04d9199302
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_1_c0a98d1391d4426182d3d43651ad67e5._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 1"
+ date="2020-11-16T18:22:05Z"
+ content="""
+> In the datalad test suite, a test involving one of our special remotes
+> hangs after 7245a9ed5 [...] The hang depends on the remote program
+> creating an SSH socket but not cleaning it up on failure. That's being
+> addressed on our end (https://github.com/datalad/datalad/pull/5151).
+
+That statement was based on me being able to trigger a stall locally
+in the same test on my Buster system.  The changes from datalad's pr
+5151 resolved the hang on my end, as well as the hang from the
+stripped down demo I added here.
+
+However, with the changes from pr 5151 merged, it turns out the the
+stall on the Ubuntu 18.04 CI is still there [1].  So, it's unclear
+what's going on.  Perhaps 7245a9ed5 isn't even what triggered the hang
+on the CI, though the stall seems to have first appeared 14 days ago
+on a build using 7e24b2587 [2], so the timing is at least consistent
+with 7245a9ed5 being the culprit.
+
+[1] https://github.com/datalad/git-annex/runs/1404305092?check_suite_focus=true
+[2] https://github.com/datalad/datalad-extensions/runs/1345445794?check_suite_focus=true
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_2_952d0856b79cdf1637a84c74f396d9e8._comment b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_2_952d0856b79cdf1637a84c74f396d9e8._comment
new file mode 100644
index 0000000000..fd32a52002
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_2_952d0856b79cdf1637a84c74f396d9e8._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-11-17T16:06:53Z"
+ content="""
+The ssh process you run this way has the following file descriptor:
+
+	l-wx------ 1 joey joey 64 Nov 17 12:07 2 -> pipe:[6320144]
+
+That pipe is connected to git-annex. git-annex is waiting to read any errors
+that the special remote might output to stderr, in order to relay them to the
+user. Yes, this was changed by the referenced commit.
+
+Since git-annex has already waited on the process, the process is dead
+by the point it waits on the stderr relayer thread. The only purpose
+of waiting rather than closing the handle is to see anything the process
+might have output in its dying breath.
+
+Also, this is very similar to the problem fixed
+in [[!commit aa492bc65904a19f22ffdfc20d7a5e7052e2f54d]] and in
+[[!commit cb74cefde782e542ad609b194792deabe55b1f5a]], also involving ssh.
+Those were solved using a rather ugly up to 2 second wait for any late
+stderr to arrive, though it only delays when the handle is kept open like this.
+
+There are surely a ton of places where this could potentially happen.
+Not only stderr.. it's entirely possible that process that git-annex
+expects to read stdout from might spawn a daemon that keeps inherited
+stdout open, and exit, leaving git-annex waiting forever to read
+from the pipe.
+
+I'm doubtful this is a bug everywhere that git-annex reads all the stdout from
+a pipe. Because it seems to me a great many programs would have the same
+problem if a program they were piping stdout from behaved in that way. 
+I've never seen anything concern itself with this potential problem. This is
+why proper daemons close their handles, certianly their stdout handle. stderr
+is a slightly special case maybe.
+
+processTranscript is one example of another place in git-annex that
+waits to consume all stderr from a process and would be hung by such a daemon.
+There are a dozen in all,
+`git grep 'std_err =' | egrep 'CreatePipe|UseHandle | grep -v nullh`
+I suppose they could all be audited and maybe something abstracted out to
+deal with them all.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_3_ed02f45c96f7eedf2c15add673ca84f2._comment b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_3_ed02f45c96f7eedf2c15add673ca84f2._comment
new file mode 100644
index 0000000000..14ff49337a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_3_ed02f45c96f7eedf2c15add673ca84f2._comment
@@ -0,0 +1,57 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-11-17T19:04:26Z"
+ content="""
+One approach would be:
+
+		cancelOnExit :: ProcessHandle -> IO a -> IO (Maybe a)
+
+The versions of this currently being used to work around the past
+occurances of the problem wait for the process to exit, and then wait 2
+seconds before canceling the action, to give it time to read anything that
+was buffered in the pipe.
+
+That's annoyingly racey, what if the system somehow massively slows
+down for 2 seconds just after the process exits, and so buffered output is
+lost? Doing this in a lot of places, not just a few targeted places where
+maybe we didn't care too much about stderr anyway, does not feel safe.
+
+There's GHC.IO.Handle.hWaitForInput that does not consume input from a
+Handle, but checks if there is any available to read. Digging into what
+that really means -- as well as checking its internal buffers, it calls a
+[fdReady C function](https://gitlab.haskell.org/ghc/ghc/-/blob/ba4dcc7cb77a37486368911fec854d112a1db93c/libraries/base/cbits/inputReady.c)
+which boils down to a `poll()`. So that seems like it could be used to
+avoid the race. I think it would be safest to use it with 0, which avoids a
+case where, it interrupted too long, it can return false when there's still
+input.
+
+It should be possible to use that to implement this:
+
+	readUntilExit :: ProcessHandle -> (Handle -> IO a) -> Handle -> IO a
+
+Wait for the process to exit, and then check hWaitForInput, and as long as
+there's input left, sleep breifly and loop. Once all buffered input as been
+consumed by the action, hClose the handle to get the action to finish
+reading from it.
+
+One problem with this is that eg, this would throw an exception if it
+closed the handle out from under hGetLine before it read anything:
+
+	unlessM (hIsEOF h) $
+		readUntilExit ph hGetLine h
+
+So it's not entirely safe to drop this in just anywhere. Maybe it should
+catch the EOF exception?
+	
+	readUntilExitOrEOF :: ProcessHandle -> (Handle -> IO a) -> Handle -> IO (Maybe a)
+
+That should be fine for things like hGetLine, but would still be unsafe
+for hGetContents, which does *not* like having the handle it's reading
+closed out from under it ("hGetContents: illegal operation (delayed read on closed handle)").
+So maybe best to specialize it:
+
+	hGetLineUntilExitOrEOF :: ProcessHandle -> Handle -> IO (Maybe String)
+
+I have a partial implementation on the ssh-hates-me branch.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_4_639337906e441523a610c7080f215aa8._comment b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_4_639337906e441523a610c7080f215aa8._comment
new file mode 100644
index 0000000000..795b09a4a4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_4_639337906e441523a610c7080f215aa8._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-11-18T15:57:10Z"
+ content="""
+hWaitForInput does not seem to behave as documented. It does not time out,
+so blocks forever in this situation. This is with a 0 timeout and with
+larger timeouts. Unsure why, it looked like it should work. Looking at the
+ghc bug tracker, it seems to have some open bugs.
+([[!commit 9af0000e0ff28c8eaae0ee1ce6838063d0a5ebef]] has my bench test
+demonstrating this problem.)
+
+hGetLineUntilExitOrEOF could still be implemented, but rather than using
+hGetLine, it would need to use hGetBufNonBlocking to do one byte at a time
+reads, with a small sleep when there is nothing to read,
+until it gets an empty read at a point after the process has exited.
+
+I can't see a way to implement it without the sleep, and that is
+problimatic, too long sleep will slow down reading, and too short a sleep
+will waste cpu. It might be possible to use hGetBufSome and cancel it
+once the process exits, and only then switch to hGetBufNonBlocking to
+read the rest of the buffer. But it's not clear what would happen hGetBufSome
+got as far as reading from the handle, but didn't quite manage to finish
+before being timed out. Seems likely any data it did read would then be lost.
+
+Think I'll have to abandon the hGetLineUntilExitOrEOF idea.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_4_746ffcf575f91bc3d156b279bcdf8ae2._comment b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_4_746ffcf575f91bc3d156b279bcdf8ae2._comment
new file mode 100644
index 0000000000..f4fc122825
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_4_746ffcf575f91bc3d156b279bcdf8ae2._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-11-18T17:23:21Z"
+ content="""
+Seems the problem with hWaitForInput happens when running it concurrently
+with hGetLine on the same handle. When I run it sequentially, it does seem
+to work. Ok.. I was able to implement hGetLineUntilExitOrEOF that seems to
+work.
+
+I've converted it to use that, and the test case for this bug is fixed.
+Also, the sleep based workaround
+in [[!commit aa492bc65904a19f22ffdfc20d7a5e7052e2f54d]] is removed,
+and it uses hGetLineUntilExitOrEOF instead.
+
+However, I still want to do the audit of other things that pipe stderr.
+Some of them don't do line based input, so will need a different function
+than hGetLineUntilExitOrEOF. Leaving this bug open until that audit is
+done.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_4_e4f249bc78e870c91b3fcbf34596a9ed._comment b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_4_e4f249bc78e870c91b3fcbf34596a9ed._comment
new file mode 100644
index 0000000000..500d86939e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_4_e4f249bc78e870c91b3fcbf34596a9ed._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 4"
+ date="2020-11-18T15:30:06Z"
+ content="""
+Thanks for the analysis.  (I wish I had some sort of intelligent input
+to give rather than just being the reporter of several of these ssh
+issues :/)
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_7_a9b594ecd43c0d2f35029c934ba7e143._comment b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_7_a9b594ecd43c0d2f35029c934ba7e143._comment
new file mode 100644
index 0000000000..64ad00acb9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_7_a9b594ecd43c0d2f35029c934ba7e143._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 7"
+ date="2020-11-19T15:34:59Z"
+ content="""
+Thanks.  The hanging datalad CI builds are now resolved.
+
+https://github.com/datalad/git-annex/actions/runs/371469598
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_8_9fdcef0d78d04ce05765693fe296bb3d._comment b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_8_9fdcef0d78d04ce05765693fe296bb3d._comment
new file mode 100644
index 0000000000..458ec3ec48
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Buggy_external_special_remote_stalls_after_7245a9e/comment_8_9fdcef0d78d04ce05765693fe296bb3d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2020-11-19T20:37:57Z"
+ content="""
+Finished auditing and fixing anywhere in git-annex this could possibly
+happen.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path.mdwn b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path.mdwn
new file mode 100644
index 0000000000..60d406b833
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path.mdwn
@@ -0,0 +1,15 @@
+As of December 3, the GitHub Actions version of one of the programs (not sure which one) that git-annex bundles in its DMG installer for macOS uses `@loader_path` in the path for one of its dynamic libraries.  (The value of the `@loader_path` variable is the directory containing the binary file in which the path appears.)  `Build/OSXMkLibs.hs` does not resolve the `@loader_path` syntax, and so this leads to `./Build/Standalone` failing with:
+
+```
+cp: ./@loader_path/libbrotlicommon.1.dylib: No such file or directory
+Standalone: library install failed
+CallStack (from HasCallStack):
+  error, called at ./Build/OSXMkLibs.hs:72:41 in main:Build.OSXMkLibs
+```
+
+I attempted to patch `Build/OSXMkLibs.hs` to handle this myself, but the file containing this syntax is another dynamic lib, and the code doesn't seem to record the original paths that dynamic libraries are copied from, and so the patch would be nontrivial.
+
+[[!meta author=jwodder]]
+[[!tag projects/datalad]]
+
+> [[done]] per commeents --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_1_138124e29ad5a27751fcd133e9dbf6df._comment b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_1_138124e29ad5a27751fcd133e9dbf6df._comment
new file mode 100644
index 0000000000..dde98aec96
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_1_138124e29ad5a27751fcd133e9dbf6df._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2020-12-14T14:07:47Z"
+ content="""
+For your convenience Joey here is a sample fresh (since still keeps failing) log: [http://www.onerussian.com/tmp/git-annex-osx-20201214-1.txt](http://www.onerussian.com/tmp/git-annex-osx-20201214-1.txt) .  Link to workflow all results: [https://github.com/datalad/git-annex/actions?query=workflow%3A%22Build+git-annex+on+macOS%22](https://github.com/datalad/git-annex/actions?query=workflow%3A%22Build+git-annex+on+macOS%22)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_2_4f68ed79045c93831cb8b41888057f29._comment b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_2_4f68ed79045c93831cb8b41888057f29._comment
new file mode 100644
index 0000000000..9b5cbf5398
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_2_4f68ed79045c93831cb8b41888057f29._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-12-14T19:08:40Z"
+ content="""
+install_name_tool: warning: changes being made to the file will invalidate the code signature in: tmp/build-dmg/git-annex.app/Contents/MacOS/bundle/R
+
+This makes me doubtful that, even if the `@loader_path` problem gets resolved
+and it builds, it will actually work. It seems likely that if a library is
+signed, modifying it to have an invalid signature would make the OS refuse to
+use it.
+
+The OSX build used for releases is still using an older OSX and does not have
+either problem. I do notice there is a similar workaround in Build/OSXMkLibs.h
+for `@executable_path`; it skips such libraries. So skipping `@loader_path`
+in the same place would probably build, but would it work?
+
+Since git-annex can be installed from homebrew, I don't know if it's worth
+trying to keep the standalone app working in the face of such problems.
+Is there a use case for the .dmg file that this failing build is producing?
+
+One approach would be to stop bundling system libraries, so the .dmg
+perhaps is tied to a specific version of OSX. I've added a way to build
+the dmg that way, make osxapp USE_SYSTEM_LIBS=1
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_3_72d271ac0612e13b3ceaf736e9e50fd9._comment b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_3_72d271ac0612e13b3ceaf736e9e50fd9._comment
new file mode 100644
index 0000000000..e2c6caba6d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_3_72d271ac0612e13b3ceaf736e9e50fd9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2020-12-14T20:59:06Z"
+ content="""
+> Is there a use case for the .dmg file that this failing build is producing?
+
+In our case we build .dmg to have it possibly (re)distributed later on as a build of git-annex to use.  But primary use case is just to have it installed and run git-annex and then datalad tests to ensure correct operation.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_4_69ae4b847873d039d790cd2b1cfa97c0._comment b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_4_69ae4b847873d039d790cd2b1cfa97c0._comment
new file mode 100644
index 0000000000..075c2c6e44
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_4_69ae4b847873d039d790cd2b1cfa97c0._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-12-14T21:43:29Z"
+ content="""
+In that case, seems fine to build with USE_SYSTEM_LIBS=1
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_5_ca662cade7153349ce644cd93c379815._comment b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_5_ca662cade7153349ce644cd93c379815._comment
new file mode 100644
index 0000000000..52cc5b54a4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_5_ca662cade7153349ce644cd93c379815._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2020-12-15T16:18:39Z"
+ content="""
+FTR: unfortunately not a complete workaround for us since the 'test' step is done in a clean environment (not build one), where we just install .dmg.  That results in git-annex not being able to find those dynamic libraries it had in build environment
+
+```
+Run git annex version
+dyld: Library not loaded: /usr/local/opt/libmagic/lib/libmagic.1.dylib
+  Referenced from: /Applications/git-annex.app/Contents/MacOS/bundle/git-annex
+  Reason: image not found
+error: git-annex died of signal 6
+Error: Process completed with exit code 134.
+```
+
+ref: [https://github.com/datalad/git-annex/pull/31](https://github.com/datalad/git-annex/pull/31)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_6_c75c9bcbcc8e68c60323dfde9c0248a7._comment b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_6_c75c9bcbcc8e68c60323dfde9c0248a7._comment
new file mode 100644
index 0000000000..3b309045d4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build__47__OSXMkLibs.hs_does_not_resolve___64__loader__95__path/comment_6_c75c9bcbcc8e68c60323dfde9c0248a7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-12-29T16:49:52Z"
+ content="""
+I later removed `USE_SYSTEM_LIBS` and made it skip
+`@loader_path` as it was already skipping `@executable_path`.
+
+Looks like the OSX build is succeeding with building and using the
+app. I suppose this can probably be closed, although we don't know how
+portable that app might be to systems where the libraries this causes it to
+skip are at other versions than it needs.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Build_failing_because_MonadFail_is_not_in_scope.mdwn b/doc/projects/datalad/bugs-done/Build_failing_because_MonadFail_is_not_in_scope.mdwn
new file mode 100644
index 0000000000..e6a2d9809e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build_failing_because_MonadFail_is_not_in_scope.mdwn
@@ -0,0 +1,31 @@
+As of commit b9c1aa925, trying to build git-annex on either Ubuntu or macOS fails with:
+
+```
+Annex/TransferrerPool.hs:56:24: error:
+    Not in scope: type constructor or class `MonadFail'
+   |
+   |         :: (MonadIO m, MonadFail m, MonadMask m)
+   |                        ^^^^^^^^^
+```
+
+This can be fixed with the following patch:
+
+```
+diff --git a/Annex/TransferrerPool.hs b/Annex/TransferrerPool.hs
+index 973f75629..0de145461 100644
+--- a/Annex/TransferrerPool.hs
++++ b/Annex/TransferrerPool.hs
+@@ -28,6 +28,7 @@ import Utility.ThreadScheduler
+ import Control.Concurrent
+ import Control.Concurrent.Async
+ import Control.Concurrent.STM hiding (check)
++import Control.Monad.Fail (MonadFail)
+ import Control.Monad.IO.Class (MonadIO)
+ import Text.Read (readMaybe)
+ import Data.Time.Clock.POSIX
+```
+
+[[!meta author=jwodder]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Build_failing_because_MonadFail_is_not_in_scope/comment_1_3ebe2e53fd8e8ce673267ac2715d964c._comment b/doc/projects/datalad/bugs-done/Build_failing_because_MonadFail_is_not_in_scope/comment_1_3ebe2e53fd8e8ce673267ac2715d964c._comment
new file mode 100644
index 0000000000..39aaf12325
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build_failing_because_MonadFail_is_not_in_scope/comment_1_3ebe2e53fd8e8ce673267ac2715d964c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-12-09T16:40:24Z"
+ content="""
+Indeed, and thank you for the patch.
+
+However, MonadFail often suggests a code smell, here it's the `Just ... <-`
+pattern match which could potentially fail. In fact, it's not possible for
+it to, so I have instead made that clear in a way that the type checker
+can understand.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Build_failing_on_Windows_since_ef3ab0769.mdwn b/doc/projects/datalad/bugs-done/Build_failing_on_Windows_since_ef3ab0769.mdwn
new file mode 100644
index 0000000000..2f27b9533d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build_failing_on_Windows_since_ef3ab0769.mdwn
@@ -0,0 +1,76 @@
+Due to the type change of `tryMakeLockHandle` in commit ef3ab0769, compilation of git-annex is currently failing on Windows with the below error.  I am unsure of the best way to fix it.
+
+[[!format txt """
+Utility\LockPool\Windows.hs:25:19: error:
+    * Couldn't match type `(LockHandle, t1)' with `LockHandle'
+      Expected type: IO (Maybe LockHandle)
+        Actual type: IO (Maybe (LockHandle, t1))
+    * In the expression:
+        tryMakeLockHandle
+          P.lockPool file (\ p f -> P.tryTakeLock p f LockShared)
+          (\ f _ -> fmap mk <$> F.lockShared f)
+      In an equation for `lockShared':
+          lockShared file
+            = tryMakeLockHandle
+                P.lockPool file (\ p f -> P.tryTakeLock p f LockShared)
+                (\ f _ -> fmap mk <$> F.lockShared f)
+   |
+25 | lockShared file = tryMakeLockHandle P.lockPool file
+
+   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
+
+Utility\LockPool\Windows.hs:27:18: error:
+    * Couldn't match type `FileLockOps' with `(FileLockOps, t1)'
+      Expected type: IO (Maybe (FileLockOps, t1))
+        Actual type: IO (Maybe FileLockOps)
+    * In the expression: fmap mk <$> F.lockShared f
+      In the fourth argument of `tryMakeLockHandle', namely
+        `(\ f _ -> fmap mk <$> F.lockShared f)'
+      In the expression:
+        tryMakeLockHandle
+          P.lockPool file (\ p f -> P.tryTakeLock p f LockShared)
+          (\ f _ -> fmap mk <$> F.lockShared f)
+   |
+27 |         (\f _ -> fmap mk <$> F.lockShared f)
+
+   |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Utility\LockPool\Windows.hs:36:22: error:
+    * Couldn't match type `(LockHandle, t0)' with `LockHandle'
+      Expected type: IO (Maybe LockHandle)
+        Actual type: IO (Maybe (LockHandle, t0))
+    * In the expression:
+        tryMakeLockHandle
+          P.lockPool file (\ p f -> P.tryTakeLock p f LockExclusive)
+          (\ f _ -> fmap mk <$> F.lockExclusive f)
+      In an equation for `lockExclusive':
+          lockExclusive file
+            = tryMakeLockHandle
+                P.lockPool file (\ p f -> P.tryTakeLock p f LockExclusive)
+                (\ f _ -> fmap mk <$> F.lockExclusive f)
+   |
+36 | lockExclusive file = tryMakeLockHandle P.lockPool file
+
+   |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
+
+Utility\LockPool\Windows.hs:38:18: error:
+    * Couldn't match type `FileLockOps' with `(FileLockOps, t0)'
+      Expected type: IO (Maybe (FileLockOps, t0))
+        Actual type: IO (Maybe FileLockOps)
+    * In the expression: fmap mk <$> F.lockExclusive f
+      In the fourth argument of `tryMakeLockHandle', namely
+        `(\ f _ -> fmap mk <$> F.lockExclusive f)'
+      In the expression:
+        tryMakeLockHandle
+          P.lockPool file (\ p f -> P.tryTakeLock p f LockExclusive)
+          (\ f _ -> fmap mk <$> F.lockExclusive f)
+   |
+38 |         (\f _ -> fmap mk <$> F.lockExclusive f)
+
+   |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+"""]]
+
+[[!meta author=jwodder]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_0a9a9c44e.mdwn b/doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_0a9a9c44e.mdwn
new file mode 100644
index 0000000000..8858b884f5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_0a9a9c44e.mdwn
@@ -0,0 +1,6 @@
+As of commit 0a9a9c44e, trying to build git-annex on Windows fails because due to a type error.  [This patch](https://raw.githubusercontent.com/datalad/git-annex/master/patches/20210630-0a9a9c44e-fix-windows.patch) fixes it.
+
+[[!meta author=jwodder]]
+[[!tag projects/datalad]]
+
+> [[done]] thankyou! --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_4b1b9d7a8.mdwn b/doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_4b1b9d7a8.mdwn
new file mode 100644
index 0000000000..47e7b952c4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_4b1b9d7a8.mdwn
@@ -0,0 +1,6 @@
+As of commit 4b1b9d7a8, trying to build git-annex on Windows fails because of a missing function argument and a missing import, both in `Annex/Init.hs`.  [This patch](https://raw.githubusercontent.com/datalad/git-annex/master/patches/20210622-4b1b9d7a8-fix-windows.patch) fixes both problems.
+
+[[!meta author=jwodder]]
+[[!tag projects/datalad]]
+
+> [[done]], thank you jwodder! --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_a706708d1.mdwn b/doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_a706708d1.mdwn
new file mode 100644
index 0000000000..afd21ee701
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_a706708d1.mdwn
@@ -0,0 +1,6 @@
+As of commit a706708d1, trying to build git-annex on Windows fails because the import of `oneSecond` from `Utility.ThreadScheduler` is not available.  [This patch](https://raw.githubusercontent.com/datalad/git-annex/master/patches/20210607-a706708d1-fix-oneSecond.patch) fixes that.
+
+[[!meta author=jwodder]]
+[[!tag projects/datalad]]
+
+> Thank you for reporting and for the patch. [[applied|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_ddd7d1d11.mdwn b/doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_ddd7d1d11.mdwn
new file mode 100644
index 0000000000..a933b0a274
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Build_fails_on_Windows_as_of_commit_ddd7d1d11.mdwn
@@ -0,0 +1,6 @@
+As of commit ddd7d1d11, trying to build git-annex on Windows fails due to a function being defined with too many arguments.  [This patch](https://raw.githubusercontent.com/datalad/git-annex/master/patches/20210902-ddd7d1d11-fix-windows.patch) fixes it.
+
+[[!meta author=jwodder]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Change_to_annex.largefiles_leaves_repo_modified.mdwn b/doc/projects/datalad/bugs-done/Change_to_annex.largefiles_leaves_repo_modified.mdwn
new file mode 100644
index 0000000000..becfbb3f28
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Change_to_annex.largefiles_leaves_repo_modified.mdwn
@@ -0,0 +1,179 @@
+### Please describe the problem.
+
+When unlocking an annexed file and also adding a matching `annex.largefiles=nothing` entry to `.gitattributes`, leaves the file modified after committing both.
+This seems to happen only recently. Observed on macOS VM with recent annex in DataLad's CI builds. Same situation comes out clean on other machines (with not as recent git-annex). Moreover it appears to be a race condition, since with the reproducer below it happens almost always, but sometimes it does end up with a clean repository.
+
+Note, that the issue is less about what exactly should happen to that file. git-annex-add reports it's adding it to the git repository and that's fine. If git-annex was to say: "Hey, that's stupid" - that too would probably be fine. What seems wrong either way is a modified file right after committing this file, plus the fact that we didn't observe this with earlier annex versions.
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+mkdir testrepo
+cd testrepo
+git init
+git annex init
+echo "**/.git* annex.largfiles=nothing" > .gitattributes
+git annex add .gitattributes
+echo "something" > somefile
+git annex add -c annex.dotfiles=true -- .gitattributes somefile
+git commit -m "to annex"
+ls -la
+git status
+#----------Setup done-----------------
+git annex unlock somefile
+echo "* annex.largefiles=nothing" >> .gitattributes
+git annex add -c annex.dotfiles=true -- .gitattributes somefile
+git commit -m "adding to git" .gitattributes somefile
+git status  # <- this will (most of the time) show a modified `somefile`
+"""]]
+
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+[[!format sh """
+> git annex version
+git-annex version: 10.20220222
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.11 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+> git --version
+git version 2.35.1
+"""]]
+
+
+### Please provide any additional information below.
+
+On the said system the reproducer script above gives:
+
+[[!format sh """
+++ mkdir testrepo
+++ cd testrepo
+++ git init
+Initialized empty Git repository in /Users/appveyor/projects/testrepo/.git/
+++ git annex init
+init  ok
+(recording state in git...)
+++ echo '**/.git* annex.largfiles=nothing'
+++ git annex add .gitattributes
+add .gitattributes (non-large file; adding content to git repository) ok
+(recording state in git...)
+++ echo something
+++ git annex add -c annex.dotfiles=true -- .gitattributes somefile
+add somefile
+ok
+(recording state in git...)
+++ git commit -m 'to annex'
+[master (root-commit) fd4307e] to annex
+ 2 files changed, 2 insertions(+)
+ create mode 100644 .gitattributes
+ create mode 120000 somefile
+++ ls -la
+total 8
+drwxr-xr-x   5 appveyor  staff  160 Mar 16 04:36 .
+drwxr-xr-x   5 appveyor  staff  160 Mar 16 04:36 ..
+drwxr-xr-x  13 appveyor  staff  416 Mar 16 04:36 .git
+-rw-r--r--   1 appveyor  staff   33 Mar 16 04:36 .gitattributes
+lrwxr-xr-x   1 appveyor  staff  180 Mar 16 04:36 somefile -> .git/annex/objects/gG/2m/SHA256E-s10--4bc453b53cb3d914b45f4b250294236adba2c0e09ff6f03793949e7e39fd4cc1/SHA256E-s10--4bc453b53cb3d914b45f4b250294236adba2c0e09ff6f03793949e7e39fd4cc1
+++ git status
+On branch master
+nothing to commit, working tree clean
+++ git annex unlock somefile
+unlock somefile ok
+(recording state in git...)
+++ echo '* annex.largefiles=nothing'
+++ git annex add -c annex.dotfiles=true -- .gitattributes somefile
+add .gitattributes (non-large file; adding content to git repository) ok
+add somefile (non-large file; adding content to git repository) ok
+(recording state in git...)
+++ git commit -m 'adding to git' .gitattributes somefile
+[master 9a6e407] adding to git
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+ rewrite somefile (100%)
+ mode change 120000 => 100644
+++ git status
+On branch master
+Changes to be committed:
+  (use "git restore --staged <file>..." to unstage)
+        modified:   somefile
+"""]]
+
+Whereas on a different machine it looks like this:
+
+
+[[!format sh """
++ mkdir testrepo
++ cd testrepo
++ git init
+Initialized empty Git repository in /tmp/testrepo/.git/
++ git annex init
+init  ok
+(recording state in git...)
++ echo **/.git* annex.largfiles=nothing
++ git annex add .gitattributes
+add .gitattributes (non-large file; adding content to git repository) ok
+(recording state in git...)
++ echo something
++ git annex add -c annex.dotfiles=true -- .gitattributes somefile
+add somefile 
+ok                                
+(recording state in git...)
++ git commit -m to annex
+[master (root-commit) 408fed5] to annex
+ 2 files changed, 2 insertions(+)
+ create mode 100644 .gitattributes
+ create mode 120000 somefile
++ ls -la
+total 36
+drwxr-xr-x  3 ben  ben   4096 Mar 16 10:39 .
+drwxrwxrwt 29 root root 20480 Mar 16 10:39 ..
+drwxr-xr-x  9 ben  ben   4096 Mar 16 10:39 .git
+-rw-r--r--  1 ben  ben     33 Mar 16 10:39 .gitattributes
+lrwxrwxrwx  1 ben  ben    180 Mar 16 10:39 somefile -> .git/annex/objects/gG/2m/SHA256E-s10--4bc453b53cb3d914b45f4b250294236adba2c0e09ff6f03793949e7e39fd4cc1/SHA256E-s10--4bc453b53cb3d914b45f4b250294236adba2c0e09ff6f03793949e7e39fd4cc1
++ git status
+On branch master
+nothing to commit, working tree clean
++ git annex unlock somefile
+unlock somefile ok
+(recording state in git...)
++ echo * annex.largefiles=nothing
++ git annex add -c annex.dotfiles=true -- .gitattributes somefile
+add .gitattributes (non-large file; adding content to git repository) ok
+add somefile (non-large file; adding content to git repository) ok
+(recording state in git...)
++ git commit -m adding to git .gitattributes somefile
+[master 865efeb] adding to git
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+ rewrite somefile (100%)
+ mode change 120000 => 100644
++ git status
+On branch master
+nothing to commit, working tree clean
++ git annex version
+git-annex version: 8.20211123
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
++ git --version
+git version 2.34.1
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Lots! I love git-annex!
+
+[[!meta author=bpoldrack]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Change_to_annex.largefiles_leaves_repo_modified/comment_1_7cd205f8f5560420d117d5a2bde48532._comment b/doc/projects/datalad/bugs-done/Change_to_annex.largefiles_leaves_repo_modified/comment_1_7cd205f8f5560420d117d5a2bde48532._comment
new file mode 100644
index 0000000000..94d55a33d8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Change_to_annex.largefiles_leaves_repo_modified/comment_1_7cd205f8f5560420d117d5a2bde48532._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="FWIW a detail"
+ date="2022-03-16T14:38:45Z"
+ content="""
+I believe our corresponding test in datalad started to fail on this date:
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2022/02[master]git
+$> git grep 'test_partial_unlocked.*FAIL' | head -n 1
+cron-20220219/build-macos.yaml-595-85dd9355-failed/1_test-datalad (master).txt:2022-02-19T02:37:34.9834050Z datalad.core.local.tests.test_save.test_partial_unlocked ... FAIL
+```
+which had git-annex-macos-dmg_10.20220127+git57-gb481ec273_x64 -- so that or some commit shortly before likely introduced that regression
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Change_to_annex.largefiles_leaves_repo_modified/comment_2_725d46358366ea79e375fd47beac6acd._comment b/doc/projects/datalad/bugs-done/Change_to_annex.largefiles_leaves_repo_modified/comment_2_725d46358366ea79e375fd47beac6acd._comment
new file mode 100644
index 0000000000..d98635f4cd
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Change_to_annex.largefiles_leaves_repo_modified/comment_2_725d46358366ea79e375fd47beac6acd._comment
@@ -0,0 +1,77 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-03-21T17:33:28Z"
+ content="""
+Isolated to [[!commit c68f52c6a25ebd8a12f4572da53fbba827d682aa]]
+
+Since that commit is only a speed improvement, it can be reverted, which
+does avoid the problem.
+
+But I don't really see a bug in that commit either. It only causes
+git to smudge the file when it's unlocked, rather than at some later
+point. The result should be the same either way. Except, of course,
+that you're varying the annex.largefiles config, so when git smudges
+the file later, it sees a different result than when it smudges the file
+while unlock is running.
+
+I think that the actually surprising thing here is that 
+`git-annex add somefile` re-adds the file (adding it to git per the new
+annex.largefiles configuration). The file is in typechange state at that
+point but is not modified, so it does not need to be re-added at all.
+But add seeks `withUnmodifiedUnlockedPointers` which finds files in
+typechange state.
+
+So git-annex add decides to add the file to git even though it was
+previously added to the annex. At that point, I'd expect `git add` would
+update the index and replace the smudged content with the unsmudged
+content. However, it actually does not!
+Looking at `git ls-files  --stage` before and after git-annex add,
+the annex pointer content remains staged:
+
+	100644 bf1114c25db2833499838552f3fa69635fcc1292 0	somefile
+	add .gitattributes (non-large file; adding content to git repository) ok
+	add somefile (non-large file; adding content to git repository) ok
+	(recording state in git...)
+	100644 bf1114c25db2833499838552f3fa69635fcc1292 0	somefile
+
+The only reason that git commit goes on to commit the non-annexed
+content is because you pass somefile to it, so it re-adds somefile
+at that point, which runs the smudge filter, which passes the content
+through.
+
+And that's why git status then sees the file as modified -- 
+the index has the annex pointer still staged in it, which is different
+from what got committed.
+
+So, probably this same thing could happen in another situation, even if
+the change to git-annex unlock were reverted. Eg, if something else
+caused git smudge to run just after unlock, before the annex.largefiles
+config got changed.
+
+Why is `git add` not updating the index? Presumably because the inode
+and mtime have not changed, so it does not think it needs to. Even though
+it's being run with the smudge filter disabled, and so sees a different
+hash than the one in the index. I think a case could be made for this
+being a bug in `git add`. Although maybe the `--renormalize` option
+is intended to handle this kind of situation.
+
+The documented way for a user to change a file from being stored in git-annex
+to git is to first `git rm --cached` and then `git annex add --force-small`.
+Which avoids that `git add` behavior.
+
+I tracked git-annex add's behavior here back to 
+[[!commit 2743224658cee33657ad30653ff97de2363366c6]].
+Which addressed an old bug, filed by Kyle, which can be seen at
+[[!commit 5567496518]]. So it was intentional that unlocking a file
+and then `git annex add` should lock it, for consistency with v5
+and for consistency with unlocking a file
+and then modifying it, and then `git annex add`. I am actually a bit
+surprised at this behavior, but it was intended to handle locking files,
+not adding files to git.
+
+So, I think it would be fine for `git-annex add` to skip over a typechanged
+file when it would be added to git rather than to the annex. 
+
+I've implemented that, and it does fix this bug.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Deleted_files_not_considered_with_wanted__61____34__anything__34__.mdwn b/doc/projects/datalad/bugs-done/Deleted_files_not_considered_with_wanted__61____34__anything__34__.mdwn
new file mode 100644
index 0000000000..18ffa4fbe6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Deleted_files_not_considered_with_wanted__61____34__anything__34__.mdwn
@@ -0,0 +1,80 @@
+My understanding is that a preferred content value of "anything" (or
+equivalently the standard group "backup") should consider deleted
+files from a remote as wanted.  I'm not a heavy user of preferred
+content myself, so this understanding is based primarily off of the
+[preferred_content/standard_groups][0] documentation saying
+
+```
+### backup
+
+All content is wanted. Even content of old/deleted files.
+
+`anything`
+```
+
+At least with the scenarios I've constructed, I haven't been able to
+find a case where old files are considered.  As an example:
+
+[[!format sh """
+cd "$(mktemp -d ${TMPDIR:-/tmp}/gx-XXXXXXX)"
+
+git init a
+(
+    cd a
+    git annex init a
+    >foo && git annex add foo && git commit -m"add foo"
+    git rm foo && git commit -m"delete foo"
+)
+
+git clone a b
+(
+    cd b
+    git annex init b
+    git annex wanted . anything
+    git annex sync
+
+    set -x
+
+    git show git-annex:uuid.log
+    git show git-annex:preferred-content.log
+
+    git annex find --want-get
+    git annex get --auto
+    git annex unused
+)
+"""]]
+
+```
+[...]
++ git show git-annex:uuid.log
+17fae615-a90b-405a-85c2-9d0f28246bdf a timestamp=1586190820.385256186s
+1f0ad7d6-31ba-4d7e-a2e6-ab6acb3338c9 b timestamp=1586190820.750487084s
++ git show git-annex:preferred-content.log
+1f0ad7d6-31ba-4d7e-a2e6-ab6acb3338c9 anything timestamp=1586190820.867633471s
++ git annex find --want-get
++ git annex get --auto
++ git annex unused
+unused . (checking for unused data...) ok
+```
+
+The output above is with 8.20200330, but I saw the same result when I
+tried with 7.20190819.
+
+I haven't been able to think of another way to interpret "Even content
+of old/deleted files", so I think at least this is a documentation
+bug.
+
+[Related DataLad issue](https://github.com/datalad/datalad/issues/4369#issuecomment-608603732)
+
+[0]: https://git-annex.branchable.com/preferred_content/standard_groups/
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes.  Thank you!  :>
+
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Deleted_files_not_considered_with_wanted__61____34__anything__34__/comment_1_03eebb6527c364552b8f81c12616e926._comment b/doc/projects/datalad/bugs-done/Deleted_files_not_considered_with_wanted__61____34__anything__34__/comment_1_03eebb6527c364552b8f81c12616e926._comment
new file mode 100644
index 0000000000..f189f113bb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Deleted_files_not_considered_with_wanted__61____34__anything__34__/comment_1_03eebb6527c364552b8f81c12616e926._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-04-13T16:03:16Z"
+ content="""
+All of the commands you ran looked only at files in the current tree,
+so of course did not operate on deleted files. Eg, "git annex get" and "git
+annex get ." are identical, and obviously the current directory does not
+contain any deleted files.
+
+But there are commands that do operate on deleted files, including eg `git
+annex sync --content --all` and `git annex get --all`. Those commands will
+honor preferred content settings including "anything" when operating on
+deleted files. (The assistant also periodically does.)
+
+I've added a note to that effect to the preferred content
+documentation. Also several command's man pages didn't make entirely
+explicit that they operated on files in the current tree
+(although the main git-annex man page does document that),
+so improved that documentation too.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Deleted_files_not_considered_with_wanted__61____34__anything__34__/comment_2_fded8e94841cb23a9d2715b00f63ae98._comment b/doc/projects/datalad/bugs-done/Deleted_files_not_considered_with_wanted__61____34__anything__34__/comment_2_fded8e94841cb23a9d2715b00f63ae98._comment
new file mode 100644
index 0000000000..833eda94e2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Deleted_files_not_considered_with_wanted__61____34__anything__34__/comment_2_fded8e94841cb23a9d2715b00f63ae98._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 2"
+ date="2020-04-13T18:58:50Z"
+ content="""
+> All of the commands you ran looked only at files in the current
+> tree, so of course did not operate on deleted files.
+
+Okay.  I incorrectly thought `--auto` would bypass that.
+
+Thank you for the doc updates.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV.mdwn b/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV.mdwn
new file mode 100644
index 0000000000..0f928a36db
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV.mdwn
@@ -0,0 +1,37 @@
+I am using `git annex export` to export to a WEBDAV special remote configured with `exporttree=yes`. Works beautifully!
+
+However, now I have a repository with a submodule, and I want to export them both, such that they look like a single worktree on the WEBDAV service. I can, in-principle, achieve this by using an appropriately adjusted WEBDAV URL. But git-annex exports an empty file with the name of the submodule in the location where I would need a directory to place the submodule export -- which the WEBDAV services rightfully acknowledges with a 409 (conflict) response, when I attempt running `initremote` on the submodule nevertheless.
+
+I found no way to use an `wanted` expression to automatically exclude all submodules.
+
+The options I am left with are:
+
+1. Remove the empty submodule placeholders after an export.
+
+2. Maintain a dedicated wanted expression with a continuously updated exclusion list covering all submodule mounts.
+
+(2) Might allow me to not have to fiddle with WEBDAV requests myself, but it doesn't seem "right", given that the submodule layout and number can change with any state of the repository.
+
+I wonder, though, what benefit the export of these placeholder files provides? Maybe they should not be exported at all. Or, alternatively, it might make sense to actually export them as directories right away. I might be biased, but that might be a more appropriate representation than an empty file.
+
+
+I have used a Nextcloud instance for me attempts, and a repository with a single submodule (both created with datalad in my case, but that should not be relevant here). Followed by
+
+```
+git annex initremote wd type=webdav url=https://.../files/user/datalad/dummy encryption=none exporttree=yes
+git annex initremote wd type=webdav url=https://.../files/user/datalad/dummy/submod encryption=none exporttree=yes
+```
+
+in both repositories respectively.
+
+I have been using `git-annex version: 8.20201127`
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+It is the rock that I stand on.
+
+[[!tag projects/datalad]]
+
+
+> [[fixed|done]] --[[Joey]] 
diff --git a/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_1_43cde828704e54cad344c066ba1e2821._comment b/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_1_43cde828704e54cad344c066ba1e2821._comment
new file mode 100644
index 0000000000..cf4a340fc6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_1_43cde828704e54cad344c066ba1e2821._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-12T15:46:04Z"
+ content="""
+I think it's simply a bug that it exports submodules at all. Very easy to
+forget about the special case of those wacky submodule directories in git.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_2_f1d89a826b5a2847328f6eec36b9f452._comment b/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_2_f1d89a826b5a2847328f6eec36b9f452._comment
new file mode 100644
index 0000000000..18f0cad771
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_2_f1d89a826b5a2847328f6eec36b9f452._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-03-12T16:16:44Z"
+ content="""
+Easy enough to exclude them from export, that's done.
+
+But the other side of the coin is, importing back from there will generate
+a remote-tracking branch without the submodule, and merging it will result
+in a tree that does not include the submodule, as if it were deleted.
+
+So, importing needs to somehow add back submodules, 
+unless the submodule location has been overwritten with a file on the remote.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_3_38d687454c618c3321ad6d9b3c4e7a38._comment b/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_3_38d687454c618c3321ad6d9b3c4e7a38._comment
new file mode 100644
index 0000000000..cc1f2483ed
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_3_38d687454c618c3321ad6d9b3c4e7a38._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-03-12T17:28:10Z"
+ content="""
+All right, both export and import are fixed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_4_8f31a065f5f97285adeb3f9614c1f3c9._comment b/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_4_8f31a065f5f97285adeb3f9614c1f3c9._comment
new file mode 100644
index 0000000000..b567464ab6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Exclude_submodules_from_export_to_WEBDAV/comment_4_8f31a065f5f97285adeb3f9614c1f3c9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Confirm fix"
+ date="2021-03-13T16:23:34Z"
+ content="""
+This is working now. `git-annex version: 8.20210311-gecee702b3`
+
+Thx!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/FTBFS__58___Couldn__39__t_match_type___96__Annex.AnnexState__39___..._.mdwn b/doc/projects/datalad/bugs-done/FTBFS__58___Couldn__39__t_match_type___96__Annex.AnnexState__39___..._.mdwn
new file mode 100644
index 0000000000..0fc811aead
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/FTBFS__58___Couldn__39__t_match_type___96__Annex.AnnexState__39___..._.mdwn
@@ -0,0 +1,59 @@
+### Please describe the problem.
+
+FTBFS for two days (this error matches only on linux, didn't check others why they are red in https://github.com/datalad/git-annex):
+
+```
+2022-06-29T03:25:00.4893455Z E: build failed
+2022-06-29T03:25:00.4894450Z I: the tail of the log
+2022-06-29T03:25:00.4903612Z [310 of 677] Compiling Creds            ( Creds.hs, dist/build/git-annex/git-annex-tmp/Creds.o )
+2022-06-29T03:25:00.4908788Z [311 of 677] Compiling Remote.Helper.AWS ( Remote/Helper/AWS.hs, dist/build/git-annex/git-annex-tmp/Remote/Helper/AWS.o )
+2022-06-29T03:25:00.4910166Z [312 of 677] Compiling P2P.Address      ( P2P/Address.hs, dist/build/git-annex/git-annex-tmp/P2P/Address.o )
+2022-06-29T03:25:00.4911450Z [313 of 677] Compiling P2P.Auth         ( P2P/Auth.hs, dist/build/git-annex/git-annex-tmp/P2P/Auth.o )
+2022-06-29T03:25:00.4912850Z [314 of 677] Compiling Annex.Notification ( Annex/Notification.hs, dist/build/git-annex/git-annex-tmp/Annex/Notification.o )
+2022-06-29T03:25:00.4913599Z 
+2022-06-29T03:25:00.4913895Z Annex/Notification.hs:37:42: error:
+2022-06-29T03:25:00.4914739Z     * Couldn't match type `Annex.AnnexState' with `Annex.AnnexRead'
+2022-06-29T03:25:00.4915686Z       Expected type: Annex.AnnexState -> DesktopNotify
+2022-06-29T03:25:00.4916569Z         Actual type: Annex.AnnexRead -> DesktopNotify
+2022-06-29T03:25:00.4917418Z     * In the first argument of `Annex.getState', namely
+2022-06-29T03:25:00.4918159Z         `Annex.desktopnotify'
+2022-06-29T03:25:00.4918842Z       In a stmt of a 'do' block:
+2022-06-29T03:25:00.4919609Z         wanted <- Annex.getState Annex.desktopnotify
+2022-06-29T03:25:00.4920362Z       In the expression:
+2022-06-29T03:25:00.4921081Z         do wanted <- Annex.getState Annex.desktopnotify
+2022-06-29T03:25:00.4921878Z            if (notifyStart wanted || notifyFinish wanted) then
+2022-06-29T03:25:00.4922815Z                do client <- liftIO DBus.Client.connectSession
+2022-06-29T03:25:00.4923576Z                   ....
+2022-06-29T03:25:00.4924147Z            else
+2022-06-29T03:25:00.4924729Z                a NotifyWitness
+2022-06-29T03:25:00.4925310Z    |
+2022-06-29T03:25:00.4926060Z 37 |                 wanted <- Annex.getState Annex.desktopnotify
+2022-06-29T03:25:00.4926916Z    |                                          ^^^^^^^^^^^^^^^^^^^
+2022-06-29T03:25:00.4927396Z 
+2022-06-29T03:25:00.4927702Z Annex/Notification.hs:60:34: error:
+2022-06-29T03:25:00.4928555Z     * Couldn't match type `Annex.AnnexState' with `Annex.AnnexRead'
+2022-06-29T03:25:00.4929502Z       Expected type: Annex.AnnexState -> DesktopNotify
+2022-06-29T03:25:00.4930367Z         Actual type: Annex.AnnexRead -> DesktopNotify
+2022-06-29T03:25:00.4931212Z     * In the first argument of `Annex.getState', namely
+2022-06-29T03:25:00.4931962Z         `Annex.desktopnotify'
+2022-06-29T03:25:00.4935814Z       In a stmt of a 'do' block:
+2022-06-29T03:25:00.4936937Z         wanted <- Annex.getState Annex.desktopnotify
+2022-06-29T03:25:00.4937934Z       In the expression:
+2022-06-29T03:25:00.4938808Z         do wanted <- Annex.getState Annex.desktopnotify
+2022-06-29T03:25:00.4939703Z            when (notifyFinish wanted)
+2022-06-29T03:25:00.4940467Z              $ liftIO
+2022-06-29T03:25:00.4941336Z                  $ do client <- DBus.Client.connectSession
+2022-06-29T03:25:00.4942492Z                       void $ Notify.notify client (droppedNote ok (fromRawFilePath f))
+2022-06-29T03:25:00.4943446Z    |
+2022-06-29T03:25:00.4944547Z 60 |         wanted <- Annex.getState Annex.desktopnotify
+2022-06-29T03:25:00.4945576Z    |                                  ^^^^^^^^^^^^^^^^^^^
+2022-06-29T03:25:00.4946531Z make[3]: *** [Makefile:58: git-annex] Error 1
+
+```
+
+full log at https://github.com/datalad/git-annex/runs/7124197096?check_suite_focus=true or on smaug on `/mnt/datasets/datalad/ci/git-annex/builds/2022/06/cron-20220629/build-ubuntu.yaml-744-90215d4e-failed/1_build-package (1).txt`
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] earlier today --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working.mdwn b/doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working.mdwn
new file mode 100644
index 0000000000..fdb2ada535
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working.mdwn
@@ -0,0 +1,119 @@
+### Please describe the problem.
+I tried using GitLab as a `--type git-lfs` special remote. I followed the steps in https://git-annex.branchable.com/tips/storing_data_in_git-lfs/ for both GitHub and GitLab.
+While it worked as described for GitHub I get an error message when trying to push data to GitLab.
+
+### What steps will reproduce the problem?
+[[!format sh """
+# basic repository setup
+mkdir annex
+cd annex
+git init
+git annex init
+
+# create a random binary file
+head -c 100 /dev/urandom >random.bin
+git annex add .
+git commit -a -m added
+
+# set GitHub as a remote (repo exists and is public: https://github.com/iimog/annex)
+git remote add github git@github.com:iimog/annex
+git push --all github
+git annex initremote lfs type=git-lfs encryption=none url=git@github.com:iimog/annex
+git annex copy * --to lfs
+#copy random.bin (to lfs...) 
+#ok                                
+#(recording state in git...)
+
+# set GitLab as a remote (repo exists and is public: https://gitlab.com/iimog/annex)
+git remote add gitlab git@gitlab.com:iimog/annex
+git push --all gitlab
+git annex initremote lfs-gitlab type=git-lfs encryption=none url=git@gitlab.com:iimog/annex
+#
+#  Unable to parse git config from gitlab
+#
+#  Remote gitlab does not have git-annex installed; setting annex-ignore
+#
+#  This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote gitlab
+#initremote lfs-gitlab ok
+#(recording state in git...)
+git annex copy * --to lfs-gitlab                                                           
+#copy random.bin (to lfs-gitlab...)
+#<long error message>
+#--> The error in short is a "Bad Request" (details see below)
+
+# Try again after explicitly calling enableremote
+git annex enableremote gitlab                                                              
+#enableremote gitlab ok
+git annex copy * --to lfs-gitlab                                                           
+#copy random.bin (to lfs-gitlab...)
+#<long error message>
+#--> This still results in the same "Bad Request" error
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 8.20210903-ga4d179c
+Ubuntu 20.04.3 LTS
+
+### Please provide any additional information below.
+
+I initially discovered this issue while using DataLad and reported the issue [here](https://github.com/datalad/datalad/issues/6126).
+As suspected by @yarikoptic the issue also exists when using git-annex directly, not through DataLad.
+
+On a self-hosted GitLab instance the following error was found in the server log:
+[[!format sh """
+2021/10/28 21:07:13 [error] 7412#0: *1869253 client sent invalid chunked body while sending request to upstream, client: <...>, server: <...>, request: "PUT /iimog/my-cool-ds2.git/gitlab-lfs/objects/92f711c1799c5aa936c2be297171d08afc19ba97899b57a1f67f2e70486395aa/80547 HTTP/1.1", upstream: "http://unix/var/opt/gitlab/gitlab-workhorse/sockets/socket:/iimog/my-cool-ds2.git/gitlab-lfs/objects/92f711c1799c5aa936c2be297171d08afc19ba97899b57a1f67f2e70486395aa/80547", host: "<...>"
+"""]]
+
+This is the full error message I got when calling `git annex copy * --to lfs-gitlab`:
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+$ git annex copy * --to lfs-gitlab
+
+copy random.bin (to lfs-gitlab...) 
+                                  
+  HttpExceptionRequest Request {
+    host                 = "gitlab.com"
+    port                 = 443
+    secure               = True
+    requestHeaders       = [("Authorization","<REDACTED>"),("Content-Type","application/octet-stream"),("Transfer-Encoding","chunked"),("User-Agent","git-annex/8.20210903-ga4d179c")]
+    path                 = "/iimog/annex.git/gitlab-lfs/objects/04b38782b7f5990e090577047fb54b52e9771ba57c1c36e21f4702049adfcfe3/100"
+    queryString          = ""
+    method               = "PUT"
+    proxy                = Nothing
+    rawBody              = False
+    redirectCount        = 10
+    responseTimeout      = ResponseTimeoutDefault
+    requestVersion       = HTTP/1.1
+  }
+   (StatusCodeException (Response {responseStatus = Status {statusCode = 400, statusMessage = "Bad Request"}, responseVersion = HTTP/1.1, responseHeaders = [("Server","cloudflare"),("Date","Tue, 09 Nov 2021 15:03:11 GMT"),("Content-Type","text/html"),("Content-Length","155"),("Connection","close"),("CF-RAY","6ab7ed2afb9fdfcf-FRA")], responseBody = (), responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose}) "<html>\r\n<head><title>400 Bad Request</title></head>\r\n<body>\r\n<center><h1>400 Bad Request</h1></center>\r\n<hr><center>cloudflare</center>\r\n</body>\r\n</html>\r\n")
+                                  
+                                  
+  HttpExceptionRequest Request {
+    host                 = "gitlab.com"
+    port                 = 443
+    secure               = True
+    requestHeaders       = [("Authorization","<REDACTED>"),("Content-Type","application/octet-stream"),("Transfer-Encoding","chunked"),("User-Agent","git-annex/8.20210903-ga4d179c")]
+    path                 = "/iimog/annex.git/gitlab-lfs/objects/04b38782b7f5990e090577047fb54b52e9771ba57c1c36e21f4702049adfcfe3/100"
+    queryString          = ""
+    method               = "PUT"
+    proxy                = Nothing
+    rawBody              = False
+    redirectCount        = 10
+    responseTimeout      = ResponseTimeoutDefault
+    requestVersion       = HTTP/1.1
+  }
+   (StatusCodeException (Response {responseStatus = Status {statusCode = 400, statusMessage = "Bad Request"}, responseVersion = HTTP/1.1, responseHeaders = [("Server","cloudflare"),("Date","Tue, 09 Nov 2021 15:03:12 GMT"),("Content-Type","text/html"),("Content-Length","155"),("Connection","close"),("CF-RAY","6ab7ed2c9a4ad6b5-FRA")], responseBody = (), responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose}) "<html>\r\n<head><title>400 Bad Request</title></head>\r\n<body>\r\n<center><h1>400 Bad Request</h1></center>\r\n<hr><center>cloudflare</center>\r\n</body>\r\n</html>\r\n")
+failed                            
+copy: 1 failed
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Yes, I'm using DataLad for some of my projects and I'm really impressed how it makes use of git-annex to solve many of the tasks that I struggled with pure git before.
+
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working/comment_1_e821d8666ace3a760a2a335220844b29._comment b/doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working/comment_1_e821d8666ace3a760a2a335220844b29._comment
new file mode 100644
index 0000000000..a61d560585
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working/comment_1_e821d8666ace3a760a2a335220844b29._comment
@@ -0,0 +1,56 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-11-09T20:09:01Z"
+ content="""
+Let's see.. git-lfs endpoint discovery over ssh works. 
+
+The request to start a transfer works:
+
+	  host                 = "gitlab.com"
+	  path                 = "/joeyh/test.git/info/lfs/objects/batch"
+	...
+	[2021-11-10 12:06:35.409182815] (Remote.GitLFS) Status {statusCode = 200, statusMessage = "OK"}
+
+So it's the actual PUT that fails:
+
+	requestHeaders       = [("Authorization","<REDACTED>"),("Content-Type","application/octet-stream"),("Transfer-Encoding","chunked"),("User-Agent","git-annex/8.20211029-ga5a7d8433")]
+	path                 = "/joeyh/test.git/gitlab-lfs/objects/922d58c647a679e17ee7c30f7de0111b56b90e84129fa3663568b81822a2628a/30"
+
+Seems that the Transfer-Encoding chunked header is the problem.
+That header is provided by the git-lfs endpoint as one to include in
+the PUT (along with the Authorization header), and git-annex dutifully does
+include it. But it seems that does not make the PUT use that
+transfer encoding. And then in the server error, we see 
+"invalid chunked body".
+
+I tried filtering out the Transfer-Encoding header, and that does 
+fix the problem. But I dunno if that's the best fix. Should git-annex support
+Transfer-Encoding chunked?
+
+git-lfs has itself supported Transfer-Encoding chunked since 2015,
+see <https://github.com/git-lfs/git-lfs/issues/385>. That says
+"client may send data via chunked Transfer-Encoding when the server
+explicitly advertises that it's supported". Which is an interesting
+wording -- "may", "supported" -- implying it's not required to use it.
+
+The API docs <https://github.com/git-lfs/git-lfs/blob/main/docs/api/batch.md>
+says the http headers are "Optional hash of String HTTP header key/value
+pairs to apply to the request". I think it means optional as in the
+server may optionally not send any, not necessarily 
+that applying them to the request is optional, but that's not really clear.
+(Surely a header like Authorization is not optional to include.)
+
+If the headers are not optional to include then the API would let the server
+specify any http headers at all, and the client has to send a PUT that includes
+those headers and that complies with them. So Transfer-Encoding deflate would
+need to use that compression method, etc.
+
+But looking at the git-lfs implementation, it only actually handles
+Transfer-Encoding chunked and not other values. I think it may also
+not include other headers than Authorization in the PUT?
+
+It seems possible there are other headers that might cause problems if they are
+blindly copied into the PUT. Content-Encoding is the only other obvious one,
+but who knows what may lurk in some odd corner of a HTTP spec.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working/comment_2_3cdbe5b9b7150f9ad9fd5d7af01b247b._comment b/doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working/comment_2_3cdbe5b9b7150f9ad9fd5d7af01b247b._comment
new file mode 100644
index 0000000000..cda7fe4f5f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working/comment_2_3cdbe5b9b7150f9ad9fd5d7af01b247b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-11-10T17:21:01Z"
+ content="""
+Fixed by not passing through those 2 problem headers. And also made it
+actually used chunked encoding when the server indicates it's supported.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working/comment_3_1dcf8d6a37bec46a7e7c2d9a65becf28._comment b/doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working/comment_3_1dcf8d6a37bec46a7e7c2d9a65becf28._comment
new file mode 100644
index 0000000000..ef52795d03
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Git_LFS_as_a_special_remote_on_GitLab_not_working/comment_3_1dcf8d6a37bec46a7e7c2d9a65becf28._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="iimog@2c22a44141070c04b943932b697818a686859677"
+ nickname="iimog"
+ avatar="http://cdn.libravatar.org/avatar/e6b150bcd25f22fa74abde05e5d6d4eb"
+ subject="It works"
+ date="2021-11-12T08:14:32Z"
+ content="""
+Thank you so much for this. I can confirm that using the latest version, I can push to GitLab LFS with git-annex and it also works when used through DataLad. This opens a whole range of options for me, so thanks a million!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__.mdwn b/doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__.mdwn
new file mode 100644
index 0000000000..997911284b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__.mdwn
@@ -0,0 +1,68 @@
+I've been thinking a bit more about `annex.dotfiles` in the context of
+[this forum post][0].  It seems to me that annexed dotfiles can jump
+to git in a way that's surprising and worth raising as a possible bug.
+
+Say that I have repo with `annex.dotfiles=true` in the .git/config,
+and I add some dotfiles to the annex.  Then, someone clones that repo
+and goes into an adjusted state (either by running `git annex adjust
+--unlock` or by being on a crippled file system).  In that clone,
+calling `annex get` on any of the annexed dotfiles will lead to those
+files being added to the index as regular files.  (Demo included
+below.)
+
+The above issue could be resolved by the user storing
+`annex.dotfiles=true` in `git-annex:config.log`, but perhaps it'd be
+feasible for git-annex to guard against already annexed dotfiles
+migrating to git?
+
+Thanks in advance.
+
+[[!format sh """
+git annex version | head -1
+
+cd "$(mktemp -d --tmpdir gx-XXXXXXX)"
+git init a
+(
+    cd a
+    git annex init a
+    git config annex.dotfiles true
+    mkdir .reallybig
+    echo "a" >.reallybig/foo
+    git annex add .reallybig/foo
+    git commit -m"add foo"
+)
+
+git clone a b
+(
+    cd b
+    git annex init b
+    git annex adjust --unlock
+    git annex get .reallybig
+    git status
+    git diff --cached
+)
+"""]]
+
+```
+git-annex version: 8.20200226
+[...]
+On branch adjusted/master(unlocked)
+Changes to be committed:
+        modified:   .reallybig/foo
+
+diff --git a/.reallybig/foo b/.reallybig/foo
+index 3de500c..7898192 100644
+--- a/.reallybig/foo
++++ b/.reallybig/foo
+@@ -1 +1 @@
+-/annex/objects/SHA256E-s2--87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7
++a
+```
+
+[0]: https://git-annex.branchable.com/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/
+
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__/comment_1_e9f5fdf1078c87718fb6ca2559323b1e._comment b/doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__/comment_1_e9f5fdf1078c87718fb6ca2559323b1e._comment
new file mode 100644
index 0000000000..ec0e3b6391
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__/comment_1_e9f5fdf1078c87718fb6ca2559323b1e._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-09T17:00:38Z"
+ content="""
+This looks like a serious regression in 8.x. It is not an intentional part
+of the annex.dotfiles change. I have confirmed the last 7.x release did not
+have the behavior.
+
+(Notice that annex.dotfiles is not used in the repo where the problem
+occurs. The regression was probably introduced by the annex.dotfiles
+changes, but the dotfile could just as well have been added by git-annex v5
+with git-annex add --include-dotfiles and the result committed to git would
+be the same.)
+
+A simpler test case is to unlock the dotfile in the first repo, then
+all that needs to be run in its clone is `git annex get`.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__/comment_2_5d0e1468f7ab2e8cd42452812d9ce49b._comment b/doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__/comment_2_5d0e1468f7ab2e8cd42452812d9ce49b._comment
new file mode 100644
index 0000000000..fe8e9befa0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__/comment_2_5d0e1468f7ab2e8cd42452812d9ce49b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-03-09T18:07:12Z"
+ content="""
+Analysis: Command.Smudge.shouldAnnex was changed
+in [[!commit 3cd375723658398a4b15ff8ec19e562ec4622488]] to check, for dotfiles,
+if annex.dotfiles is set. If not, it always returns False, so the file
+always gets added to git when it's smudged.
+
+After getting a file, git-annex tells git to update its index, which
+smudges the file. Of course, there are also plenty of other things that can
+cause a file to be smudged.
+
+Bad. Fix is very easy, luckily. It just needs to, rather than returning
+False, checking if the file was annexed, same as is done for non-dotfiles.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__/comment_3_a9837edeacdf55c74d8fed2b8d7bf1f9._comment b/doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__/comment_3_a9837edeacdf55c74d8fed2b8d7bf1f9._comment
new file mode 100644
index 0000000000..c94c5fa9ec
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Guard_against_previously_annexed_dotfiles_being_converted_to_git_files__63__/comment_3_a9837edeacdf55c74d8fed2b8d7bf1f9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="thanks"
+ date="2020-03-09T18:29:26Z"
+ content="""
+Thank you for the analysis and the fix!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/JSON_results_for___96__export__96___have_file__58__null_property.mdwn b/doc/projects/datalad/bugs-done/JSON_results_for___96__export__96___have_file__58__null_property.mdwn
new file mode 100644
index 0000000000..a80653d04b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/JSON_results_for___96__export__96___have_file__58__null_property.mdwn
@@ -0,0 +1,26 @@
+Neither successful nor failing exports via a WEBDAV special remote have appropriate `file` properties in the produced JSON records.
+
+```
+% git annex export master --to 4shared --json --json-error-messages
+{"command":"export 4shared","success":true,"input":[],"error-messages":[],"file":null}
+{"command":"export 4shared","success":true,"input":[],"error-messages":[],"file":null}
+{"command":"export 4shared","success":true,"input":[],"error-messages":[],"file":null}
+{"command":"export 4shared","success":true,"input":[],"error-messages":[],"file":null}
+{"command":"export 4shared","success":false,"input":[],"error-messages":["  DAV failure: Status {statusCode = 500, statusMessage = \"Internal Server Error\"} \"<html><body><h1>Server Error</h1></body></html>\" HTTP request: \"MOVE\" \"/dummy/git-annex-webdav-tmp-MD5E-s143466--368857ff4d0e4b14c745d94db7f7d3ff.pdf\"","  DAV failure: Status {statusCode = 500, statusMessage = \"Internal Server Error\"} \"<html><body><h1>Server Error</h1></body></html>\" HTTP request: \"MOVE\" \"/dummy/git-annex-webdav-tmp-MD5E-s143466--368857ff4d0e4b14c745d94db7f7d3ff.pdf\""],"file":null}
+{"command":"export 4shared","success":true,"input":[],"error-messages":[],"file":null}
+{"command":"export 4shared","success":true,"input":[],"error-messages":[],"file":null}
+git-annex: export: 1 failed
+```
+
+```
+git-annex version: 8.20210223
+```
+
+This behavior was observed using the 4shared service, but I believe git-annex knows which file a success or failure belongs to and could report it regardless of service oddities.
+
+
+Thx!
+
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/JSON_results_for___96__export__96___have_file__58__null_property/comment_1_bf743f047b8063b8ecbd8c87d12fa475._comment b/doc/projects/datalad/bugs-done/JSON_results_for___96__export__96___have_file__58__null_property/comment_1_bf743f047b8063b8ecbd8c87d12fa475._comment
new file mode 100644
index 0000000000..29681baafe
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/JSON_results_for___96__export__96___have_file__58__null_property/comment_1_bf743f047b8063b8ecbd8c87d12fa475._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-12T18:09:48Z"
+ content="""
+I've fixed this.
+
+However, there is still a case where the file field is null, which is when
+an already exported file is renamed. Since nothing is transferred in that
+case, and 2 files are involved which doesn't fit the one file in the json,
+I left it as-is.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/JSON_results_for___96__export__96___have_file__58__null_property/comment_2_d6e28d84238cb79c1df927da491f50db._comment b/doc/projects/datalad/bugs-done/JSON_results_for___96__export__96___have_file__58__null_property/comment_2_d6e28d84238cb79c1df927da491f50db._comment
new file mode 100644
index 0000000000..23abfcf7e2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/JSON_results_for___96__export__96___have_file__58__null_property/comment_2_d6e28d84238cb79c1df927da491f50db._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Thx!"
+ date="2021-03-13T16:05:51Z"
+ content="""
+Confirmed working with git-annex version 8.20210311-gecee702b3
+"""]]
diff --git a/doc/projects/datalad/bugs-done/OSX__58___addurl_--batch_--json_spits_out_shortened_output_string__dies_off_with_4.mdwn b/doc/projects/datalad/bugs-done/OSX__58___addurl_--batch_--json_spits_out_shortened_output_string__dies_off_with_4.mdwn
new file mode 100644
index 0000000000..a5fe6aedb3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/OSX__58___addurl_--batch_--json_spits_out_shortened_output_string__dies_off_with_4.mdwn
@@ -0,0 +1,42 @@
+### Please describe the problem.
+
+See transcript.  Didn't bisect fully but 6.20160128-g599a3ba seems to work ok, 6.20160211-g479a094 already dies off
+
+[[!format sh """
+
+datalads-imac:~ yoh$ git annex version
+git-annex version: 6.20160221-g3d1895e
+...
+datalads-imac:~ yoh$ mkdir -p /tmp/123; cd /tmp/123; git init; git annex init;  
+Initialized empty Git repository in /private/tmp/123/.git/
+init  ok
+(recording state in git...)
+
+datalads-imac:123 yoh$  rm -f /tmp/pipe; mkfifo /tmp/pipe; cat /tmp/pipe | git -c receive.autogc=false annex addurl -c annex.largefiles=exclude=*.txt --with-files --json --batch 
+{"command":"addurl","file":"1.png","note":"downloading http://www.onerussian.com/tmp/banner.png ..."error: git-annex died of signal 4
+
+# now with --debug
+datalads-imac:123 yoh$  rm -f /tmp/pipe; mkfifo /tmp/pipe; cat /tmp/pipe | git -c receive.autogc=false annex addurl -c annex.largefiles=exclude=*.txt --with-files --json --batch --debug
+[2016-02-23 08:32:49.160686] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.largefiles=exclude=*.txt","show-ref","git-annex"]
+[2016-02-23 08:32:49.167372] process done ExitSuccess
+[2016-02-23 08:32:49.167479] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.largefiles=exclude=*.txt","show-ref","--hash","refs/heads/git-annex"]
+[2016-02-23 08:32:49.172795] process done ExitSuccess
+[2016-02-23 08:32:49.173039] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.largefiles=exclude=*.txt","log","refs/heads/git-annex..b2892e67682c5240dadb5d439da810edbdb882df","-n1","--pretty=%H"]
+[2016-02-23 08:32:49.178586] process done ExitSuccess
+[2016-02-23 08:32:49.179085] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.largefiles=exclude=*.txt","cat-file","--batch"]
+[2016-02-23 08:32:49.183985] read: quvi ["--version"]
+{"command":"addurl","file":"1.png","note":"downloading http://www.onerussian.com/tmp/banner.png ..."[2016-02-23 08:32:49.255949] call: curl ["-s","-f","-L","-C","-","-#","-o","/private/tmp/123/.git/annex/tmp/URL-s25319--http&c%%www.onerussian.com%tmp%banner.png","http://www.onerussian.com/tmp/banner.png","--user-agent","git-annex/6.20160221-g3d1895e"]
+[2016-02-23 08:32:49.302577] process done ExitSuccess
+[2016-02-23 08:32:49.303332] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.largefiles=exclude=*.txt","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+[2016-02-23 08:32:49.305653] read: git ["--version"]
+[2016-02-23 08:32:49.310314] process done ExitSuccess
+error: git-annex died of signal 4
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]]; this was indeed due to libmagic, and I've fixed it using brew
+> --build-bottle to make a portable one. Then had to disable the build
+> flag. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Patch_for_compilation_errors_on_Windows.mdwn b/doc/projects/datalad/bugs-done/Patch_for_compilation_errors_on_Windows.mdwn
new file mode 100644
index 0000000000..99ab2b9c61
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Patch_for_compilation_errors_on_Windows.mdwn
@@ -0,0 +1,38 @@
+Compilation of the latest git-annex code (commit 04dca96) on Windows is currently failing due to some modules not being imported.  The issues are fixed by the following patch:
+
+```
+diff --git a/Annex/Content/Presence.hs b/Annex/Content/Presence.hs
+index 861288c0b..f5d4b593f 100644
+--- a/Annex/Content/Presence.hs
++++ b/Annex/Content/Presence.hs
+@@ -25,6 +25,9 @@ module Annex.Content.Presence (
+ ) where
+
+ import Annex.Common
++#ifdef mingw32_HOST_OS
++import Annex.Perms
++#endif
+ import qualified Annex
+ import Annex.LockPool
+ import Annex.WorkerPool
+diff --git a/Git/Hook.hs b/Git/Hook.hs
+index 45662f236..788552305 100644
+--- a/Git/Hook.hs
++++ b/Git/Hook.hs
+@@ -13,9 +13,7 @@ import Common
+ import Git
+ import Utility.Tmp
+ import Utility.Shell
+-#ifndef mingw32_HOST_OS
+ import Utility.FileMode
+-#endif
+
+ data Hook = Hook
+        { hookName :: FilePath
+
+```
+
+[[!meta author=jwodder]]
+[[!tag projects/datalad]]
+
+> build is succeeding now [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Patch_for_compilation_errors_on_Windows/comment_1_eb8d464da14af1fead372b4b61b20f17._comment b/doc/projects/datalad/bugs-done/Patch_for_compilation_errors_on_Windows/comment_1_eb8d464da14af1fead372b4b61b20f17._comment
new file mode 100644
index 0000000000..d340c41376
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Patch_for_compilation_errors_on_Windows/comment_1_eb8d464da14af1fead372b4b61b20f17._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jwodder"
+ avatar="http://cdn.libravatar.org/avatar/b06e01332c949b895c681cc92934f36a"
+ subject="comment 1"
+ date="2020-11-23T15:02:28Z"
+ content="""
+I see you patched `Git/Hook.hs`, but you did not patch `Annex/Content/Presence.hs`.  The Windows builds are still failing.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/R__47__O_permissions_are_stalking_me_somehow.mdwn b/doc/projects/datalad/bugs-done/R__47__O_permissions_are_stalking_me_somehow.mdwn
new file mode 100644
index 0000000000..b8a3a67ada
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/R__47__O_permissions_are_stalking_me_somehow.mdwn
@@ -0,0 +1,58 @@
+### Please describe the problem.
+
+I have got data which I was trying to add to an existing annex.  Unfortunately I have missed first that some files were not having write permissions so initial 'annex add' failed with similar to below messages, so I have pruned misctmp, adjusted permissions and have tried to add again -- but the same error keeps coming back
+
+[[!format sh """
+% chmod +w -R S1/DDA-Freeviewing/surf2anat
+
+% ls -l S1/DDA-Freeviewing/surf2anat/S1_run1_lh*
+-rw-r----- 2 yoh retino 241147956 Feb 28 21:46 S1/DDA-Freeviewing/surf2anat/S1_run1_lh_process_surf.nii.gz
+
+% rm -rf .git/annex/misctmp/*
+zsh: sure you want to delete all the files in /mnt/datasets/mikemp/data-annex/.git/annex/misctmp [yn]? y
+
+% git annex add S1/DDA-Freeviewing/surf2anat/S1_run1_lh_process_surf.nii.gz
+add S1/DDA-Freeviewing/surf2anat/S1_run1_lh_process_surf.nii.gz
+git-annex: .git/annex/misctmp/S1_run1_lh1804289383846930886: rename: permission denied (Permission denied)
+failed
+git-annex: add: 1 failed
+
+% ls -l S1/DDA-Freeviewing/surf2anat/S1_run1_lh*
+-r--r----- 2 yoh retino 241147956 Feb 28 21:46 S1/DDA-Freeviewing/surf2anat/S1_run1_lh_process_surf.nii.gz
+
+% git annex version
+git-annex version: 6.20160307+gitgb095561-1~ndall+1
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 5 6
+upgrade supported from repository versions: 0 1 2 4 5
+
+
+% rm -rf .git/annex/misctmp/*
+zsh: sure you want to delete all the files in /mnt/datasets/mikemp/data-annex/.git/annex/misctmp [yn]? y
+
+% chmod +w -R S1/DDA-Freeviewing/surf2anat
+
+% git annex add --debug S1/DDA-Freeviewing/surf2anat/S1_run1_lh_process_surf.nii.gz
+[2016-03-10 10:15:22.578786] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--others","--exclude-standard","-z","--","S1/DDA-Freeviewing/surf2anat/S1_run1_lh_process_surf.nii.gz"]
+[2016-03-10 10:15:22.583854] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+[2016-03-10 10:15:22.584443] read: git ["--version"]
+[2016-03-10 10:15:22.588703] process done ExitSuccess
+add S1/DDA-Freeviewing/surf2anat/S1_run1_lh_process_surf.nii.gz [2016-03-10 10:15:23.186056] read: sha256sum [".git/annex/misctmp/S1_run1_lh1804289383846930886"]
+[2016-03-10 10:15:24.611133] process done ExitSuccess
+
+git-annex: .git/annex/misctmp/S1_run1_lh1804289383846930886: rename: permission denied (Permission denied)
+failed
+[2016-03-10 10:15:24.648808] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--name-only","--diff-filter=T","-z","--","S1/DDA-Freeviewing/surf2anat/S1_run1_lh_process_surf.nii.gz"]
+git-annex: add: 1 failed
+% ls -l .git/annex/misctmp/S1_run1_lh1804289383846930886
+-r--r----- 2 yoh retino 241147956 Feb 28 21:46 .git/annex/misctmp/S1_run1_lh1804289383846930886
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[unreproducible|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/R__47__O_permissions_are_stalking_me_somehow/comment_1_9e4ba1e03a89c219c5e62280757311ba._comment b/doc/projects/datalad/bugs-done/R__47__O_permissions_are_stalking_me_somehow/comment_1_9e4ba1e03a89c219c5e62280757311ba._comment
new file mode 100644
index 0000000000..6e77495297
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/R__47__O_permissions_are_stalking_me_somehow/comment_1_9e4ba1e03a89c219c5e62280757311ba._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-03-14T17:53:32Z"
+ content="""
+A file's permissions cannot prevent it being renamed; so I diagnose some
+kind of directory permission problem.
+
+(Also AFAICS git-annex add deals with files whose permissions don't allow
+being read by turning on the read bit. And it should never need the write
+bit. I can `chmod 000 foo; git annex add foo` and it succeeds..)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__.mdwn b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__.mdwn
new file mode 100644
index 0000000000..aad4c5ae35
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__.mdwn
@@ -0,0 +1,167 @@
+I'm looking into another SSH-based hang in the DataLad tests.  I can't
+trigger the hang on my local system (Debian Buster), but in a Ubuntu
+Xenial VM I can.  The hang bisects to 1f2e2d15e (async exception
+safety, 2020-06-03).  It disappears on the parent of 1f2e2d15e or if I
+revert that commit on top of master (currently 3b6754e2a).
+
+I was able to reduce the hang down to a `git annex get` from an rsync
+remote.  Here is a script that triggers the hang via a Xenial Docker
+container.  Sorry for the length; given the system interaction, it's
+the simplest reproducer I've managed to come up with.
+
+[[!format sh """
+cd "$(mktemp -d ${TMPDIR:-/tmp}/ga-XXXXXXX)"
+
+cat >demo.sh <<'EOF'
+git annex version
+
+cd "$(mktemp -d /tmp/ga-XXXXXXX)"
+remdir="$PWD/store"
+mkdir "$remdir"
+git init repo
+(
+    cd repo
+    git annex init
+    git annex initremote r type=rsync rsyncurl="localhost:$remdir" encryption=none
+    echo 0 >f0
+    git annex add f0
+    git commit -m'f0'
+    git annex copy --to=r f0
+    git annex drop f0
+)
+
+git clone repo clone
+(
+    cd clone
+    git annex init clone
+    git annex enableremote r
+    git annex get --debug f0
+)
+EOF
+
+cat >Dockerfile <<'EOF'
+FROM ubuntu:xenial
+
+ENV DEBIAN_FRONTEND=noninteractive
+RUN apt-get update
+RUN apt-get install -y --no-install-recommends \
+  curl rsync openssh-client openssh-server ca-certificates
+RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
+
+RUN cd /root && curl -fSsL \
+  https://downloads.kitenet.net/git-annex/autobuild/amd64/git-annex-standalone-amd64.tar.gz \
+  | tar xz
+ENV PATH="/root/git-annex.linux:$PATH"
+
+RUN git config --system user.name "u"
+RUN git config --system user.email "u@e"
+
+RUN mkdir -p /root/.ssh
+RUN mkdir -p /var/run/sshd
+RUN ssh-keygen -f /root/.ssh/id_rsa -N ""
+RUN cat /root/.ssh/id_rsa.pub >>/root/.ssh/authorized_keys
+RUN echo "Host localhost\nStrictHostKeyChecking no\n" >>/root/.ssh/config
+
+COPY demo.sh /root/demo.sh
+CMD /usr/sbin/sshd && sh /root/demo.sh
+EOF
+
+docker build -t ga-rsync-hang:latest .
+docker run -it --rm ga-rsync-hang:latest
+"""]]
+
+Output, where the last line stalled:
+
+```
+[... 50 lines ...]
+git-annex version: 8.20200618-g3b6754e2a
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+[... 32 lines ...]
+[2020-07-07 14:28:55.252423613] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2020-07-07 14:28:55.256082009] process done ExitSuccess
+[2020-07-07 14:28:55.256316845] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2020-07-07 14:28:55.26056207] process done ExitSuccess
+[2020-07-07 14:28:55.260917245] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","-z","--cached","--","f0"]
+get f0 [2020-07-07 14:28:55.26481346] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2020-07-07 14:28:55.268786541] process done ExitSuccess
+[2020-07-07 14:28:55.268997933] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2020-07-07 14:28:55.272176401] process done ExitSuccess
+[2020-07-07 14:28:55.272550418] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..ea06186dfc3dab39316da534144d5d6ef3d6090c","--pretty=%H","-n1"]
+[2020-07-07 14:28:55.275989985] process done ExitSuccess
+[2020-07-07 14:28:55.27634403] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2020-07-07 14:28:55.276782737] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2020-07-07 14:28:55.279315206] read: git ["config","--null","--list"]
+[2020-07-07 14:28:55.281990769] process done ExitSuccess
+(from r...) 
+[2020-07-07 14:28:55.288194172] read: rsync ["-e","'ssh' '-S' '.git/annex/ssh/localhost' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T'","--progress","--inplace","localhost:/tmp/ga-075MZKs/store/0c5/66e/'SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa/SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa'",".git/annex/tmp/SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa"]
+SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa
+
+              0   0%    0.00kB/s    0:00:00  
+              2 100%    1.95kB/s    0:00:00 (xfr#1, to-chk=0/1)
+^C
+```
+
+Replacing "FROM ubuntu:xenial" with "FROM ubuntu:bionic" (a later
+release) resolves the hang, so perhaps there is some interaction with
+an older rsync or openssh version.  Here are the versions that are
+present in Xenial:
+
+```
+OpenSSH_7.2p2 Ubuntu-4ubuntu2.10, OpenSSL 1.0.2g  1 Mar 2016
+
+rsync  version 3.1.1  protocol version 31
+Copyright (C) 1996-2014 by Andrew Tridgell, Wayne Davison, and others.
+Web site: http://rsync.samba.org/
+Capabilities:
+    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
+    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
+    append, ACLs, xattrs, iconv, symtimes, prealloc
+```
+
+Thinking it's an older version of openssh or rsync, I tried with an older version of Debian.  Using "FROM debian:stretch-slim" doesn't hang.  Here are the versions there:
+
+```
+OpenSSH_7.4p1 Debian-10+deb9u7, OpenSSL 1.0.2u  20 Dec 2019
+
+rsync  version 3.1.2  protocol version 31
+Copyright (C) 1996-2015 by Andrew Tridgell, Wayne Davison, and others.
+Web site: http://rsync.samba.org/
+Capabilities:
+    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
+    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
+    append, ACLs, xattrs, iconv, symtimes, prealloc
+```
+
+However, going back farther, "FROM debian:jessie-slim" does hang.  The
+versions there:
+
+```
+OpenSSH_6.7p1 Debian-5+deb8u8, OpenSSL 1.0.1t  3 May 2016
+
+rsync  version 3.1.1  protocol version 31
+Copyright (C) 1996-2014 by Andrew Tridgell, Wayne Davison, and others.
+Web site: http://rsync.samba.org/
+Capabilities:
+    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
+    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
+    append, ACLs, xattrs, iconv, symtimes, prealloc
+```
+
+So perhaps there's some interaction with openssh before 7.4p1 or rsync
+before 3.1.2.  Those are pretty old versions, and, in the case of
+Jessie, the release is now EOL.  But I figured it was at least worth
+writing up given that the hang isn't triggered until a recent commit
+in git-annex.
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] made it cancel the threads 2 seconds after the process
+> exited if still running. So there will be a bit of a slow down when using
+> that broken ssh version, but it will work. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_10_d9dc3550012a618ba674119dd1163642._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_10_d9dc3550012a618ba674119dd1163642._comment
new file mode 100644
index 0000000000..c42b0037ec
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_10_d9dc3550012a618ba674119dd1163642._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 10"
+ date="2020-08-10T18:56:02Z"
+ content="""
+Hmm.  Well, I doubt it provides any useful information, but just in case, here's the output produced by the `git annex get --debug f0` call:
+
+```
+[2020-08-10 14:49:51.227779797] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2020-08-10 14:49:51.229945707] process done ExitSuccess
+[2020-08-10 14:49:51.230127447] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2020-08-10 14:49:51.232132388] process done ExitSuccess
+[2020-08-10 14:49:51.232349474] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"-z\",\"--cached\",\"--\",\"f0\"]
+get f0 [2020-08-10 14:49:51.234243652] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2020-08-10 14:49:51.236402808] process done ExitSuccess
+[2020-08-10 14:49:51.236609182] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2020-08-10 14:49:51.238119863] process done ExitSuccess
+[2020-08-10 14:49:51.238409384] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..d8b33719c8ce515e7b5b99f8d0c51ab7d2de46e1\",\"--pretty=%H\",\"-n1\"]
+[2020-08-10 14:49:51.240088806] process done ExitSuccess
+[2020-08-10 14:49:51.240391883] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2020-08-10 14:49:51.240716412] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2020-08-10 14:49:51.247306917] read: git [\"config\",\"--null\",\"--list\"]
+[2020-08-10 14:49:51.24859076] process done ExitSuccess
+(from r...) 
+[2020-08-10 14:49:51.250558418] read: rsync [\"-e\",\"'ssh' '-S' '.git/annex/ssh/localhost' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T'\",\"--progress\",\"--inplace\",\"localhost:/tmp/ga-urvfy8Q/store/0c5/66e/'SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa/SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa'\",\".git/annex/tmp/SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa\"]
+SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa
+
+              0   0%    0.00kB/s    0:00:00  
+              2 100%    1.95kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2020-08-10 14:49:51.557365853] process done ExitSuccess
+git-annex: AsyncCancelled
+```
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_11_5dc1d7c54fc4768849d39affac51fcae._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_11_5dc1d7c54fc4768849d39affac51fcae._comment
new file mode 100644
index 0000000000..cc09e047fe
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_11_5dc1d7c54fc4768849d39affac51fcae._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 11"
+ date="2020-08-10T19:01:35Z"
+ content="""
+And I should have checked the result the command rather than just
+noting that it didn't hang.  f0 is not transferred.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_12_7cb4c4e1bc100e8f3241ece74ce463e3._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_12_7cb4c4e1bc100e8f3241ece74ce463e3._comment
new file mode 100644
index 0000000000..fd2b57b86f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_12_7cb4c4e1bc100e8f3241ece74ce463e3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2020-08-10T19:36:30Z"
+ content="""
+Wait, are you saying the command exited nonzero, or that the transfer
+didn't happen, or both?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_13_a1bce716987b0d8d00a4a9aa07e9ac65._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_13_a1bce716987b0d8d00a4a9aa07e9ac65._comment
new file mode 100644
index 0000000000..69548cba1e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_13_a1bce716987b0d8d00a4a9aa07e9ac65._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2020-08-10T19:54:26Z"
+ content="""
+Well, I ran the reproducer script, substituting a git-annex tarball with
+the fix (and adding an output of the exit code and dropping the --debug),
+and the end was:
+
+	get f0 (from r...) 
+	SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa2 
+	100%    1.95kB/s    0:00:00 (xfr#1, to-chk=0/1)
+	(checksum...) ok
+	(recording state in git...)
+	0
+
+So, I guess this patch is ok, at least with the git-annex I've built.
+(Using haskell from debian unstable.) It seems possible that some older
+ghc, async, etc might have handled that AsyncCancelled differently and
+resulted in the behavior you're seeing.
+
+Also tried with https://downloads.kitenet.net/git-annex/autobuild/i386-ancient/git-annex-standalone-i386-ancient.tar.gz
+and it's ok too.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_13_dd51471ec6a8f380663c62d6f9edb176._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_13_dd51471ec6a8f380663c62d6f9edb176._comment
new file mode 100644
index 0000000000..e859f5fa68
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_13_dd51471ec6a8f380663c62d6f9edb176._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 13"
+ date="2020-08-10T19:47:59Z"
+ content="""
+The file isn't transferred, and the exit is non-zero (1).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_15_93e2dd2b30cdeddd5e273eae78a422e0._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_15_93e2dd2b30cdeddd5e273eae78a422e0._comment
new file mode 100644
index 0000000000..5155449d73
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_15_93e2dd2b30cdeddd5e273eae78a422e0._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2020-08-10T20:06:28Z"
+ content="""
+Hmm, come to think of it, `wait errt` is racing 
+`cancel errt`, so what if cancel kills the errt thread,
+and before `race` noticed cancel is done, the wait thread 
+sees errt,  died of an an AsyncCancelled exception and rethrows that?
+Result could be the exception leaking out, perhaps.
+
+It might be that async now avoids that, and some other version didn't, or
+you could be getting unlucky with the race.
+
+So, I've added something to catch that exception in case it leaks.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_16_b2d1550e20e8c4cc07dbd0ebba64c603._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_16_b2d1550e20e8c4cc07dbd0ebba64c603._comment
new file mode 100644
index 0000000000..30813e6b3b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_16_b2d1550e20e8c4cc07dbd0ebba64c603._comment
@@ -0,0 +1,78 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 16"
+ date="2020-08-10T21:34:43Z"
+ content="""
+I applied the change from c59a51a0651b and 4466c1001d88.  Now I don't
+see \"git-annex: AsyncCancelled\", f0 is transferred, and the exit
+status is 0, so it looks to be working as intended.  Thank you.
+
+As described in comment 8, this is all in the Xenial VM on top of
+1df9e72a7829, because the hang goes away with the next commit
+(4c9ad1de46dd).  For posterity, here is a diff of the changes on top
+1df9e72a7829, applied from aa492bc65904, c59a51a0651b, and
+4466c1001d88.
+
+<details>
+<summary>diff</summary>
+
+[[!format diff \"\"\"
+diff --git a/Utility/Metered.hs b/Utility/Metered.hs
+index 1c35a9a05..c4063c90b 100644
+--- a/Utility/Metered.hs
++++ b/Utility/Metered.hs
+@@ -1,6 +1,6 @@
+ {- Metered IO and actions
+  -
+- - Copyright 2012-2018 Joey Hess <id@joeyh.name>
++ - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+  -
+  - License: BSD-2-clause
+  -}
+@@ -46,6 +46,7 @@ import Common
+ import Utility.Percentage
+ import Utility.DataUnits
+ import Utility.HumanTime
++import Utility.ThreadScheduler
+ 
+ import qualified Data.ByteString.Lazy as L
+ import qualified Data.ByteString as S
+@@ -314,10 +315,26 @@ outputFilter cmd params environ outfilter errfilter =
+ 	catchMaybeIO $ withCreateProcess p go
+   where
+ 	go _ (Just outh) (Just errh) pid = do
+-		void $ concurrently 
+-			(tryIO (outfilter outh) >> hClose outh)
+-			(tryIO (errfilter errh) >> hClose errh)
+-		waitForProcess pid
++		outt <- async $ tryIO (outfilter outh) >> hClose outh
++		errt <- async $ tryIO (errfilter errh) >> hClose errh
++		ret <- waitForProcess pid
++
++		-- Normally, now that the process has exited, the threads
++		-- will finish processing its output and terminate.
++		-- But, just in case the process did something evil like
++		-- forking to the background while inheriting stderr,
++		-- it's possible that the threads will not finish, which
++		-- would result in a deadlock. So, wait a few seconds
++		-- maximum for them to finish and then cancel them.
++		-- (One program that has behaved this way in the past is
++		-- openssh.)
++		void $ tryNonAsync $ race_
++			(wait outt >> wait errt)
++			(threadDelaySeconds (Seconds 2))
++		cancel outt
++		cancel errt
++
++		return ret
+ 	go _ _ _ _ = error \"internal\"
+ 	
+ 	p = (proc cmd (toCommand params))
+\"\"\"]]
+
+</details>
+
+
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_1_5274e7f715ef060383046e8f5da08164._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_1_5274e7f715ef060383046e8f5da08164._comment
new file mode 100644
index 0000000000..40807725de
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_1_5274e7f715ef060383046e8f5da08164._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-07-13T15:53:56Z"
+ content="""
+Hmm, my guess is that the significant and unmentioned change in that commit
+is, it waits for one of the stdout or stderr to be fully processed before
+waiting on the process to terminate. So if it somehow fails to detect EOF
+(maybe because old rsync and ssh somehow end up with the handle not being
+closed when rsync exits eg if a background ssh process inherited them?) it
+would block forever.
+
+If so, this patch would avoid the hang (and if this doesn't fix it, the
+problem must be somehow due to using with CreateProcess).
+
+	diff --git a/Utility/Metered.hs b/Utility/Metered.hs
+	index 1c35a9a05..8e363681d 100644
+	--- a/Utility/Metered.hs
+	+++ b/Utility/Metered.hs
+	@@ -314,9 +314,8 @@ outputFilter cmd params environ outfilter errfilter =
+	 	catchMaybeIO $ withCreateProcess p go
+	   where
+	 	go _ (Just outh) (Just errh) pid = do
+	-		void $ concurrently 
+	-			(tryIO (outfilter outh) >> hClose outh)
+	-			(tryIO (errfilter errh) >> hClose errh)
+	+		void $ async $ tryIO (outfilter outh) >> hClose outh
+	+		void $ async $ tryIO (errfilter errh) >> hClose errh
+	 		waitForProcess pid
+	 	go _ _ _ _ = error "internal"
+ 
+If that patch does avoid the hang, this one would be worth a try
+as it tries to accomplish the goal of the patch in a better way:
+
+	diff --git a/Utility/Metered.hs b/Utility/Metered.hs
+	index 1c35a9a05..bd265ae09 100644
+	--- a/Utility/Metered.hs
+	+++ b/Utility/Metered.hs
+	@@ -313,11 +313,10 @@ outputFilter
+	 outputFilter cmd params environ outfilter errfilter = 
+	 	catchMaybeIO $ withCreateProcess p go
+	   where
+	-	go _ (Just outh) (Just errh) pid = do
+	-		void $ concurrently 
+	-			(tryIO (outfilter outh) >> hClose outh)
+	-			(tryIO (errfilter errh) >> hClose errh)
+	-		waitForProcess pid
+	+	go _ (Just outh) (Just errh) pid =
+	+		withAsync (tryIO (outfilter outh) >> hClose outh) $ const $
+	+			withAsync (tryIO (errfilter errh) >> hClose errh) $ const $
+	+				waitForProcess pid
+	 	go _ _ _ _ = error "internal"
+	 	
+	 	p = (proc cmd (toCommand params))
+
+I can try these if necessary but don't have docker handy,
+so maybe you're in a better position to?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_2_8976d014def1910f5140b1e5cdd37fb0._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_2_8976d014def1910f5140b1e5cdd37fb0._comment
new file mode 100644
index 0000000000..7a50318714
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_2_8976d014def1910f5140b1e5cdd37fb0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 2"
+ date="2020-07-13T16:46:54Z"
+ content="""
+Thanks for taking a look.  I'll test out those changes and report back.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_3_efccd6c930ea37f782cbd3b029f4fa71._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_3_efccd6c930ea37f782cbd3b029f4fa71._comment
new file mode 100644
index 0000000000..d3f6bb5b2b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_3_efccd6c930ea37f782cbd3b029f4fa71._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 3"
+ date="2020-07-13T19:04:45Z"
+ content="""
+Okay, short summary:
+
+  * The demo script above no longer hangs as of 4c9ad1de4
+    (optimisation: stream keys through git cat-file --buffer,
+    2020-07-10).
+
+  * Going to the parent of 4c9ad1de4 (1df9e72), the hang is still
+    there.
+
+  * The first patch advances the output by one line but still hangs,
+    with the line at the time of the hang being \"process done
+    ExitSuccess\".
+
+  * The second patch removes the hang (again, this is from the parent
+    of 4c9ad1de4).
+
+---
+
+The above is all based on working in a Xenial VM, building from source
+with stack.  The Docker-based approach above provides a reproducer,
+but it depends on the autobuild downloads.  It'd need quite a bit more
+work to have the full stack setup there.  However, running the above
+script without Docker caching, I've confirmed the most recent
+autobuild, which has 4c9ad1de4, no longer hangs.
+
+It seems at least plausible that 4c9ad1de4 affected the stall because
+it looks to deal with git-annex-get.  However, perhaps that's just
+resolving the issue for this particular case, and it still makes sense
+to apply the second the patch?
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_4_282d1a5a2942820785b9cdacc1126545._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_4_282d1a5a2942820785b9cdacc1126545._comment
new file mode 100644
index 0000000000..8082ddf944
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_4_282d1a5a2942820785b9cdacc1126545._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-07-13T21:15:46Z"
+ content="""
+If rsync is truely what's hanging, then commit 4c9ad1de4 can't have changed
+anything to do with that. Seems more likely that the hang did not actually
+involve rsync (but the debug output makes it seem like it is), 
+or that the hang is not fully deterministic.
+
+Whatever it's hanging on in the first patch is apparently not involving
+rsync, because rsync has exited. And it doesn't make sense that the first
+patch would hang while the second one doesn't, they're doing identical
+things except for extra background thread cleanup in the second patch.
+
+As this stands, I don't feel confident enough that the second patch really
+fixes this to close this. Also I'm a little bit doubtful it's really
+correct, it seems possible it might cancel one of the threads before all
+output is processed by them. The first patch actually seems better.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_5_34d7c2fb1b46f61e348a92f86a3d732c._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_5_34d7c2fb1b46f61e348a92f86a3d732c._comment
new file mode 100644
index 0000000000..edd7f2d835
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_5_34d7c2fb1b46f61e348a92f86a3d732c._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 5"
+ date="2020-07-14T19:18:10Z"
+ content="""
+Fair enough.
+
+> or that the hang is not fully deterministic.
+
+Perhaps.  I haven't hit any divergent results yet, but that of course
+doesn't mean that much.
+
+In my view, it'd be okay to close this issue, as well as [the other
+Xenial/old system stall][0].  These are related to SSH-based stalls
+that DataLad is hitting on Travis, and it would of course be nice to
+resolve them, but it probably isn't worth investing much more time in.
+And on DataLad's end, we should probably upgrade our CI's distribution
+from Xenial to Bionic anyway.
+
+That being said, if you think of specific debugging information that
+might be useful for me to provide or if you want access to the Xenial
+qcow2 image (a bloated 25G :/), please let me know.
+
+Thanks for your feedback on this issue and the other one.
+
+[0]: https://git-annex.branchable.com/bugs/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_6_279dfc4d611e2dbcb2523b9756f13a9d._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_6_279dfc4d611e2dbcb2523b9756f13a9d._comment
new file mode 100644
index 0000000000..893e669a6c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_6_279dfc4d611e2dbcb2523b9756f13a9d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-07-15T20:11:03Z"
+ content="""
+I think this is worth following up still, I plan to reproduce it eventually
+and debug.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_7_815bf1b8985a49a0fafbcddc7c96f9d6._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_7_815bf1b8985a49a0fafbcddc7c96f9d6._comment
new file mode 100644
index 0000000000..2f79028cbe
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_7_815bf1b8985a49a0fafbcddc7c96f9d6._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2020-07-21T19:59:40Z"
+ content="""
+Reproducer script did not work for me.
+
+But in the meantime, 4c9ad1de4 has gotten into the built that script uses,
+so whatever about that commit fixes or masks the problem, it seems.
+
+But, the other stall's reproducer script did still work. And I was able to
+confirm that git-annex was blocked while ssh was a
+zombie process.. and killing sshd got git-annex unstuck. So apparently sshd
+is inheriting a handle keeping it open... at least sometimes.
+
+It's really weird my first patch didn't work. The only difference between
+reverting commit 1f2e2d15e and my first patch is the use of
+withCreateProcess. So um.. withCreateProcess is somehow blocking on ssh to
+close stderr? Looking at its code, it calls cleanupProcess, which has
+this comment:
+
+	-- Note, it's important that other threads that might be reading/writing
+	-- these handles also get killed off, since otherwise they might be holding
+	-- the handle lock and prevent us from closing, leading to deadlock.
+
+Ok, that begins to make sense.. The threads are not killed off, so
+are accessing the handle, so closing the handle blocks. And this explains
+why it got to ExitSuccess and then hung.
+
+My second patch, by using withAsync, avoided that. But like I said, that
+patch could kill the threads before they have read and processed all the 
+output. For example, if the process output an error and exited,
+that could cause the error message to not get displayed to the user.
+
+So hmm, this is not reproducible, but we don't know why a recent change
+hid it, and the only patch I know of that fixes it is to revert commit 1f2e2d15e,
+which is part of the work being done for [[todo/more_extensive_retries_to_mask_transient_failures]].
+And while that todo is currently stalled and I may not use this work
+to resolve it at all, it seems a pity to revert that commit.
+
+Also, before 1f2e2d15e, it would have started a thread to read from stderr,
+and that thread could keep running after outputFilter returned.
+And nothing would ever stop that thread, which would block forever due to
+ssh's behavior. So, before that commit, I think there was also a bug,
+a FD leak (and small memory leak).
+
+This is getting kind of long, but the only way forward I see out of all
+this, aside from somehow determining how 4c9ad1de4 masks the problem,
+would be to make the stderr waiter thread only be allowed to run
+for a "little while" after the process exits. Similar to how cb74cefde78
+fixed the other hang.
+
+(Or well, git-annex could detect the ssh versions that have this
+behavior and refuse to use them..)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_8_6f5e18dec962aba505ed15bed328f11f._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_8_6f5e18dec962aba505ed15bed328f11f._comment
new file mode 100644
index 0000000000..d8b1d7dfcf
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_8_6f5e18dec962aba505ed15bed328f11f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 8"
+ date="2020-07-22T16:12:23Z"
+ content="""
+> fixed made it cancel the threads 2 seconds after the process exited
+> if still running. So there will be a bit of a slow down when using
+> that broken ssh version, but it will work
+
+Just to see this in action, in the Xenial VM, I checked out the parent
+of 4c9ad1de4 (1df9e72a7) to get to a state that hangs with the demo
+script.  I then applied the fix (aa492bc65) on top.  The hang is
+avoided, and I see \"git-annex: AsyncCancelled\".
+
+Thanks.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_9_bcc64259541b35eed34a63f4955884e5._comment b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_9_bcc64259541b35eed34a63f4955884e5._comment
new file mode 100644
index 0000000000..6e8cc82c93
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/comment_9_bcc64259541b35eed34a63f4955884e5._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2020-08-10T17:26:13Z"
+ content="""
+I'm a bit surprised that the AsyncCancelled exception gets displayed.
+
+Something in git-annex must be catching that, and displaying it. The
+"git-annex:" says it's displayed with topLevelWarning, and the only thing
+that calls that to display an exception is accountCommandAction, but that uses
+tryNonAsync so it's supposed to not catch async exceptions like this one.
+
+(Also why would canceling a worker thread throw an exception all the way
+out to accountCommandAction? And if it did, the overall command would then
+fail.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Repo_contains_invalid_Windows_paths_again.mdwn b/doc/projects/datalad/bugs-done/Repo_contains_invalid_Windows_paths_again.mdwn
new file mode 100644
index 0000000000..309021acb3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Repo_contains_invalid_Windows_paths_again.mdwn
@@ -0,0 +1,15 @@
+As of commit f3ff2b83ca7357e16c6f0cb06962434b8afe1e89, the git-annex repository once again contains files with names that are invalid on Windows, thus creating problems when trying to clone the repo on Windows:
+
+```
+error: invalid path 'doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term./comment_1_9984f65d6e89f0f88b33cbd499e859eb._comment'
+error: invalid path 'doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term./comment_2_d7bdfeb33bac7f139b0bdc1c6fb53237._comment'
+error: invalid path 'doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term./comment_3_7dc224cb0b88bf07879e03717efffa17._comment'
+error: invalid path 'doc/forum/Is_Annex_for_me__63___Questions_about_the_long_term./comment_4_a538f8a4272b5ce134607dc7201e3f04._comment'
+```
+
+Previous bug report on the same basic issue: <https://git-annex.branchable.com/bugs/Error_cloning_repository_on_Windows/>
+
+[[!meta author=jwodder]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__.mdwn b/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__.mdwn
new file mode 100644
index 0000000000..c06ebc20fb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__.mdwn
@@ -0,0 +1,115 @@
+First, this feels like it is probably the same underlying cause as the
+[report I recently opened][0].  However, it bisects to an earlier
+commit and doesn't involve rsync, so I'm erring on the side of a
+separate issue.  And this probably comes down to a bad interaction
+with an old openssh version, so like the other bug, it might not
+really be worth looking into or fixing.  On DataLad's end, we're
+running into it because our Travis tests run on Xenial, which is LTS
+until April 2021.
+
+[0]: https://git-annex.branchable.com/bugs/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/
+
+Here's a script that triggers the hang.  It creates a Xenial-based
+Docker image, pulling in the latest git-annex autobuild.
+
+[[!format sh """
+cd "$(mktemp -d ${TMPDIR:-/tmp}/ga-XXXXXXX)"
+
+cat >demo.sh <<'EOF'
+git annex version
+cd "$(mktemp -d /tmp/ga-XXXXXXX)"
+git init repo
+(
+    cd repo
+    git annex init
+    git commit -m'c0' --allow-empty
+)
+git clone localhost:"$(pwd)"/repo clone
+git -C clone annex init --debug
+EOF
+
+cat >Dockerfile <<'EOF'
+FROM ubuntu:xenial
+
+ENV DEBIAN_FRONTEND=noninteractive
+RUN apt-get update && \
+    apt-get install -y --no-install-recommends \
+      curl openssh-client openssh-server ca-certificates && \
+    apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
+
+RUN cd /root && curl -fSsL \
+  https://downloads.kitenet.net/git-annex/autobuild/amd64/git-annex-standalone-amd64.tar.gz \
+  | tar xz
+ENV PATH="/root/git-annex.linux:$PATH"
+# Make SSH see standalone's executables.
+RUN chsh -s /bin/bash
+RUN echo 'export PATH="/root/git-annex.linux:$PATH"' >/root/.bashrc.tmp && \
+    cat /root/.bashrc >>/root/.bashrc.tmp && \
+    mv /root/.bashrc.tmp /root/.bashrc
+
+RUN PATH="/root/git-annex.linux:$PATH" && \
+    git config --system user.name "u" && \
+    git config --system user.email "u@e"
+
+RUN mkdir -p /root/.ssh && \
+    mkdir -p /var/run/sshd && \
+    ssh-keygen -f /root/.ssh/id_rsa -N "" && \
+    cat /root/.ssh/id_rsa.pub >>/root/.ssh/authorized_keys && \
+    echo "Host localhost\nStrictHostKeyChecking no\n" >>/root/.ssh/config
+
+COPY demo.sh /root/demo.sh
+CMD /usr/sbin/sshd && sh /root/demo.sh
+EOF
+
+docker build -t ga-init-hang:latest .
+docker run -it --rm ga-init-hang:latest
+"""]]
+
+Here's the output.  The last line stalled.
+
+```
+[... 35 lines ...]
+git-annex version: 8.20200618-g59c90643c
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+[... 66 lines ...]
+(scanning for unlocked files...)
+[2020-07-10 20:38:16.279437348] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--head"]
+[2020-07-10 20:38:16.281916637] process done ExitSuccess
+[2020-07-10 20:38:16.282041242] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-tree","--full-tree","-z","-r","--","HEAD"]
+[2020-07-10 20:38:16.284631723] process done ExitSuccess
+[2020-07-10 20:38:16.285152392] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2020-07-10 20:38:16.287400177] process done ExitSuccess
+[2020-07-10 20:38:16.287504149] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2020-07-10 20:38:16.28987225] process done ExitSuccess
+[2020-07-10 20:38:16.289980932] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2020-07-10 20:38:16.292040629] process done ExitSuccess
+[2020-07-10 20:38:16.292160147] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2020-07-10 20:38:16.294629952] process done ExitSuccess
+[2020-07-10 20:38:16.294755223] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","checkout","-q","-B","master"]
+[2020-07-10 20:38:16.313153728] process done ExitSuccess
+[2020-07-10 20:38:16.315278334] read: uname ["-n"]
+[2020-07-10 20:38:16.316832707] process done ExitSuccess
+[2020-07-10 20:38:16.318892738] read: ssh ["localhost","-S",".git/annex/ssh/localhost","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","git-annex-shell 'configlist' '/tmp/ga-MwIuVzn/repo' '--debug'"]
+^C
+```
+
+The openssh version in that container is OpenSSH_7.2p2.  As with the
+other bug report, replacing "FROM ubuntu:xenial" with "FROM
+ubuntu:bionic" eliminates the stall.  debian:jessie-slim also shows
+the stall, but debian:stretch-slim doesn't, which places the
+problematic openssh version before OpenSSH_7.4p1.
+
+With the same demo.sh script in a Xenial VM, that bisects to 75059c9f3
+(better error message when git config fails to parse remote config,
+2020-01-22).
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_1_ce71734986fe4c86a43a5805628dd3de._comment b/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_1_ce71734986fe4c86a43a5805628dd3de._comment
new file mode 100644
index 0000000000..8a21243e78
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_1_ce71734986fe4c86a43a5805628dd3de._comment
@@ -0,0 +1,59 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-07-13T16:48:04Z"
+ content="""
+Hmm, I do see similarities with this and the rsync hang. This one
+also has it waiting on threads that read from stdout and stderr.
+
+Since it was already reading stdout, it must not be the stdout handle
+that's not getting closed. If my guess about an unclosed handle
+for the rsync bug is right, it must be the stderr handle.
+
+And that kind of makes sense, ssh might start a daemon-like process
+(for connection caching), but that old version might have let it inherit
+stderr rather than fully daemonizing.
+
+If that's the case, this patch would solve it:
+
+	diff --git a/Git/Config.hs b/Git/Config.hs
+	index 9e2ac2bd8..45cf4aa8f 100644
+	--- a/Git/Config.hs
+	+++ b/Git/Config.hs
+	@@ -22,6 +22,7 @@ import Git.Types
+	 import qualified Git.Command
+	 import qualified Git.Construct
+	 import Utility.UserInfo
+	+import Utility.ThreadScheduler
+	 
+	 {- Returns a single git config setting, or a fallback value if not set. -}
+	 get :: ConfigKey -> ConfigValue -> Repo -> ConfigValue
+	@@ -214,13 +215,20 @@ fromPipe r cmd params st = tryNonAsync $ withCreateProcess p go
+	 		{ std_out = CreatePipe
+	 		, std_err = CreatePipe
+	 		}
+	-	go _ (Just hout) (Just herr) pid = do
+	-		(val, err) <- concurrently 
+	-			(S.hGetContents hout)
+	-			(S.hGetContents herr)
+	-		forceSuccessProcess p pid
+	-		r' <- store val st r
+	-		return (r', val, err)
+	+	go _ (Just hout) (Just herr) pid =
+	+		withAsync (S.hGetContents herr) $ \errreader -> do
+	+			val <- S.hGetContents hout
+	+			-- In case the process exits while something else,
+	+			-- like a background process, keeps the stderr handle
+	+			-- open, don't block forever waiting for stderr.
+	+			-- A few seconds after finishing reading stdout
+	+			-- should get any error message.
+	+			err <- either id id <$> 
+	+				wait errreader
+	+					`race` (threadDelaySeconds (Seconds 2) >> return mempty)
+	+			forceSuccessProcess p pid
+	+			r' <- store val st r
+	+			return (r', val, err)
+	 	go _ _ _ _ = error "internal"
+	 
+	 {- Reads git config from a specified file and returns the repo populated
+"""]]
diff --git a/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_2_8e7487f2f093e79dcce0be34274d7fa2._comment b/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_2_8e7487f2f093e79dcce0be34274d7fa2._comment
new file mode 100644
index 0000000000..d1c1453cae
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_2_8e7487f2f093e79dcce0be34274d7fa2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 2"
+ date="2020-07-13T19:27:17Z"
+ content="""
+In a Xenial VM, I tested that patch on top of today's 4dd5cfa46, which
+still shows the hang.  The patch indeed resolves the hang.  Thanks!
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_3_4ddca3bdc573ed3c7f6d846c4309ac2e._comment b/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_3_4ddca3bdc573ed3c7f6d846c4309ac2e._comment
new file mode 100644
index 0000000000..7272622072
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_3_4ddca3bdc573ed3c7f6d846c4309ac2e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-07-13T21:20:19Z"
+ content="""
+Ok, but the results for similar patches in
+<https://git-annex.branchable.com/bugs/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/>
+make me somewhat doubt I understand the problem, or that these hangs
+are fully deterministic.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_4_c480f7fad76759742bbdc4837d8c0c36._comment b/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_4_c480f7fad76759742bbdc4837d8c0c36._comment
new file mode 100644
index 0000000000..4eacab9ee2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_4_c480f7fad76759742bbdc4837d8c0c36._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-07-21T20:02:22Z"
+ content="""
+Reproduced this with the script.
+
+	1798550 pts/0    S+     0:00              |   \_ /root/git-annex.linux/exe/git --library-path /root/git-annex.linux//lib:/root/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/root/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/root/git-annex.linux//etc/ld.so.conf.d:/root/git-annex.linux//lib64:/root/git-annex.linux//lib/x86_64-linux-gnu:/root/git-annex.linux//usr/lib/x86_64-linux-gnu: /root/git-annex.linux/shimmed/git/git -C clone annex init --debug
+	1798579 pts/0    Sl+    0:00              |       \_ /root/git-annex.linux/exe/git-annex --library-path /root/git-annex.linux//lib:/root/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/root/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/root/git-annex.linux//etc/ld.so.conf.d:/root/git-annex.linux//lib64:/root/git-annex.linux//lib/x86_64-linux-gnu:/root/git-annex.linux//usr/lib/x86_64-linux-gnu: /root/git-annex.linux/shimmed/git-annex/git-annex init --debug
+	1798596 pts/0    S+     0:00              |           \_ /root/git-annex.linux/exe/git --library-path /root/git-annex.linux//lib:/root/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/root/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/root/git-annex.linux//etc/ld.so.conf.d:/root/git-annex.linux//lib64:/root/git-annex.linux//lib/x86_64-linux-gnu:/root/git-annex.linux//usr/lib/x86_64-linux-gnu: /root/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+	1798597 pts/0    S+     0:00              |           \_ /root/git-annex.linux/exe/git --library-path /root/git-annex.linux//lib:/root/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/root/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/root/git-annex.linux//etc/ld.so.conf.d:/root/git-annex.linux//lib64:/root/git-annex.linux//lib/x86_64-linux-gnu:/root/git-annex.linux//usr/lib/x86_64-linux-gnu: /root/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+	1798598 pts/0    S+     0:00              |           \_ /root/git-annex.linux/exe/git --library-path /root/git-annex.linux//lib:/root/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/root/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/root/git-annex.linux//etc/ld.so.conf.d:/root/git-annex.linux//lib64:/root/git-annex.linux//lib/x86_64-linux-gnu:/root/git-annex.linux//usr/lib/x86_64-linux-gnu: /root/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+	1798628 pts/0    Z+     0:00              |           \_ [ssh] <defunct>
+	1798267 ?        Ss     0:00              \_ /usr/sbin/sshd
+	1798629 ?        Ss     0:00              |   \_ sshd: root@notty
+
+I killed 1798629 and git-annex stopped hanging. That seems to confirm my
+theory that sshd has inherited the stderr handle that git-annex is waiting
+for input on. That process had these FDs:
+
+	lrwx------ 1 root root 64 Jul 21 16:04 0 -> /dev/null
+	lrwx------ 1 root root 64 Jul 21 16:04 1 -> /dev/null
+	lrwx------ 1 root root 64 Jul 21 16:04 2 -> /dev/null
+	lrwx------ 1 root root 64 Jul 21 16:04 3 -> socket:[15959002]
+	lr-x------ 1 root root 64 Jul 21 16:04 4 -> pipe:[15956866]
+	l-wx------ 1 root root 64 Jul 21 16:04 5 -> pipe:[15956866]
+
+So probably 4 or 5 was connected to git-annex on the other end.
+
+I've applied my patch, to fix this one.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_5_8a5b1e1cb4482fb787bde97a6066de59._comment b/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_5_8a5b1e1cb4482fb787bde97a6066de59._comment
new file mode 100644
index 0000000000..6206f0e014
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/SSH-based_git-annex-init_hang_on_older_systems___40__Xenial__44___Jessie__41__/comment_5_8a5b1e1cb4482fb787bde97a6066de59._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 5"
+ date="2020-07-22T16:01:03Z"
+ content="""
+Great, thanks for the analysis and for applying the patch.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Some_calls_to_git_repeat_--config_values.mdwn b/doc/projects/datalad/bugs-done/Some_calls_to_git_repeat_--config_values.mdwn
new file mode 100644
index 0000000000..370031ef6e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Some_calls_to_git_repeat_--config_values.mdwn
@@ -0,0 +1,69 @@
+Some of git-annex's calls to git duplicate the `--config` values that
+are passed by the caller.  Here's an example:
+
+[[!format sh """
+cd "$(mktemp -d --tmpdir gx-XXXXXXX)"
+git init
+git annex init -c foo.bar=true --debug
+"""]]
+
+```
+[...]
+[2020-03-11 10:59:12.932497354] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","foo.bar=true","config","annex.uuid","ffad618f-a272-4d1b-8a5b-73778661ac1b"]
+[2020-03-11 10:59:12.934971688] process done ExitSuccess
+[2020-03-11 10:59:12.93926062] read: git ["config","--null","--list"]
+[2020-03-11 10:59:12.941719766] process done ExitSuccess
+[2020-03-11 10:59:12.942450637] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","foo.bar=true","-c","foo.bar=true","show-ref","git-annex"]
+[...]
+[2020-03-11 10:59:12.955818683] read: git ["config","--null","--list"]
+[2020-03-11 10:59:12.958211547] process done ExitSuccess
+[2020-03-11 10:59:12.958313557] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","foo.bar=true","-c","foo.bar=true","-c","foo.bar=true","status","--porcelain"]
+[2020-03-11 10:59:12.960857733] process done ExitSuccess
+[2020-03-11 10:59:12.960928142] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","foo.bar=true","-c","foo.bar=true","-c","foo.bar=true","config","filter.annex.smudge","git-annex smudge -- %f"]
+[2020-03-11 10:59:12.963408762] process done ExitSuccess
+[...]
+```
+
+Based on looking at the full output, it seems like a repeated
+`--config` value gets tacked on each time after the configuration is
+re-read.
+
+The above is with a git-annex built from 8.20200226-161-g1978a2420.  I
+see the same duplicates with a git-annex built from
+7.20190819-2-g908476a9b.
+
+Those extra values shouldn't cause any problems, but this issue seems
+worth filing in case there's a simple fix.
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> Fix was attempted in [[!commit c8fec6ab0]] but that
+> caused [[annex-ssh-options_dropped_since_8.20200330]]
+> so it was reverted.
+> 
+> The cause of the problem is that the action passed to adjustGitRepo
+> gets run more than once in some cases where the Repo has changed
+> and the adjustment needs to be re-done, so if it appends a value,
+> the value may get appended to a Repo that already had it appended.
+> 
+> So that commit made it check if the value was present and not add it.
+> I don't currently understand why, but that prevented the value getting
+> added.
+> --[[Joey]]
+
+> > Huh, with that commit's patch, the option is passed to all calls to
+> > git.. But not to the call to ssh.
+> >
+> > Ah.. remoteAnnexSshOptions is populated by parsing the git config,
+> > and is what gets passed to ssh. The patch though made it not call
+> > Git.Config.Store, so when the git config has been reloaded, it loses
+> > the -c config.
+> >
+> > Also, I notice that c8fec6ab0 had a second bug: 
+> > If -c foo=1 -c foo=2 -c foo=1 were passed, it would 
+> > add the first and second, but not add the third.
+> > 
+> > I was really not at even 10% back in March. For obvious reasons.
+> > 
+> > Ok, all fixed, the right way this time. [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Submodule_deletion_not_synced_from_adjusted_branch.mdwn b/doc/projects/datalad/bugs-done/Submodule_deletion_not_synced_from_adjusted_branch.mdwn
new file mode 100644
index 0000000000..4c47a35a4c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Submodule_deletion_not_synced_from_adjusted_branch.mdwn
@@ -0,0 +1,124 @@
+This is conceptually a continuation of a previous issue:
+https://git-annex.branchable.com/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/
+
+That was about `git annex sync` propagating submodule modifications
+back to the main branch.  When looking into debugging a DataLad test
+failure involving adjusted branches, I realized that there is still an
+issue with submodule *deletions* not being propagated back.
+
+Here's a demo:
+
+[[!format sh """
+set -eu
+
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/ga-sync-sub-del-XXXX)"
+
+git init
+git commit -mc0 --allow-empty
+git init sub
+git -C sub commit -m'c0 sub' --allow-empty
+git submodule add --name sub ./sub
+git commit -m'add sub'
+
+git annex init
+git annex adjust --unlock
+
+git rm sub
+git commit -m'remove sub'
+git annex sync
+
+git log --format="* %s %d" -p -2
+"""]]
+
+With a git-annex built from 8.20201129-72-gf35469764, the submodule
+deletion remains on the adjusted branch:
+
+```
+[...]
+* git-annex adjusted branch  (HEAD -> adjusted/master(unlocked))
+
+diff --git a/sub b/sub
+deleted file mode 160000
+index 95031de..0000000
+--- a/sub
++++ /dev/null
+@@ -1 +0,0 @@
+-Subproject commit 95031de9306714e09dc535246ef77b9e155999be
+* remove sub  (synced/master, master, refs/basis/adjusted/master(unlocked))
+
+diff --git a/.gitmodules b/.gitmodules
+index c489803..e69de29 100644
+--- a/.gitmodules
++++ b/.gitmodules
+@@ -1,3 +0,0 @@
+-[submodule "sub"]
+-	path = sub
+-	url = ./sub
+```
+
+I tried my hand at fixing this with the attached patch.  I'm not
+confident that it's the right fix, but with it the output of the above
+demo looks as I'd expect (and the git-annex tests still pass):
+
+```
+[...]
+* git-annex adjusted branch  (HEAD -> adjusted/master(unlocked))
+* remove sub  (synced/master, master, refs/basis/adjusted/master(unlocked))
+
+diff --git a/.gitmodules b/.gitmodules
+index c489803..e69de29 100644
+--- a/.gitmodules
++++ b/.gitmodules
+@@ -1,3 +0,0 @@
+-[submodule "sub"]
+-	path = sub
+-	url = ./sub
+diff --git a/sub b/sub
+deleted file mode 160000
+index 102197a..0000000
+--- a/sub
++++ /dev/null
+@@ -1 +0,0 @@
+-Subproject commit 102197a8b5692dc07dde7c1f6dd2f51c7ec6834e
+```
+
+Thanks for taking a look.
+
+[[!format patch """
+From e7abf01499fbd5593044889da529834e1b2999bc Mon Sep 17 00:00:00 2001
+From: Kyle Meyer <kyle@kyleam.com>
+Date: Wed, 6 Jan 2021 19:16:30 -0500
+Subject: [PATCH] adjustTree: Consider submodule deletions
+
+In addition to regular file deletions, the removefiles argument passed
+to adjustTree may contain removed submodules.  When making the new
+tree, filter these out in the same way that is done for regular files
+so that the deletion is propagated.
+---
+ Git/Tree.hs | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/Git/Tree.hs b/Git/Tree.hs
+index 491314fff..d5ac59ea7 100644
+--- a/Git/Tree.hs
++++ b/Git/Tree.hs
+@@ -259,6 +259,7 @@ adjustTree adjusttreeitem addtreeitems resolveaddconflict removefiles r repo =
+ 
+ 	removeset = S.fromList $ map (normalise . gitPath) removefiles
+ 	removed (TreeBlob f _ _) = S.member (normalise (gitPath f)) removeset
++	removed (TreeCommit f _ _) = S.member (normalise (gitPath f)) removeset
+ 	removed _ = False
+ 
+ 	addoldnew [] new = new
+
+base-commit: f3546976483aa4c29e1050081af6d5a03290e25b
+-- 
+2.30.0.284.gd98b1dd5ea
+
+"""]]
+
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[done]] thanks! --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Submodule_deletion_not_synced_from_adjusted_branch/comment_1_6473d7eceae5141e36c87156044b9d06._comment b/doc/projects/datalad/bugs-done/Submodule_deletion_not_synced_from_adjusted_branch/comment_1_6473d7eceae5141e36c87156044b9d06._comment
new file mode 100644
index 0000000000..9519541945
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Submodule_deletion_not_synced_from_adjusted_branch/comment_1_6473d7eceae5141e36c87156044b9d06._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-01-07T17:41:49Z"
+ content="""
+Clearly correct. The `_` pattern match hid this when
+[[!commit a13c0ce66c]] added TreeCommit.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit.mdwn b/doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit.mdwn
new file mode 100644
index 0000000000..625d4c64da
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit.mdwn
@@ -0,0 +1,94 @@
+When on an adjusted branch, `git annex sync` will sync the submodule
+commit for the initial addition of a submodule, but it doesn't seem to
+sync changes in the recorded commit.  Here's a demo of the issue based
+off of Michael's script at [DataLad's issue 4292][0].
+
+[[!format sh """
+cd "$(mktemp -d --tmpdir gx-sync-demo-XXXXXXX)"
+
+git init
+git annex init
+git commit --allow-empty -mc0
+git annex adjust --unlock
+
+git init sub
+git -C sub commit --allow-empty -mc0
+git submodule add ./sub
+git commit -m'add sub'
+# A new submodule is sync'd.
+git annex sync --no-commit --no-push --no-pull --no-content
+
+git -C sub commit --allow-empty -mc1
+git add sub
+git commit -m'sub update'
+
+# A change in the submodule ID is not.
+git annex sync --no-commit --no-push --no-pull --no-content
+git diff master..
+"""]]
+
+With a git-annex built from 8.20200309-62-gc8fec6ab0, the submodule
+remains modified between `master` and `adjusted/master(unlocked))`.
+
+```
+diff --git a/sub b/sub
+index ed67764..a27fd83 160000
+--- a/sub
++++ b/sub
+@@ -1 +1 @@
+-Subproject commit ed6776462d0842bf0a317d2e3ee1983572a217ff
++Subproject commit a27fd837958466ba4fb751a3de139c03548be1ad
+```
+
+I was able to resolve the issue (i.e. the above demo outputs an empty
+diff) with the patch below, though that might of course be the
+completely wrong way to fix this.
+
+Thanks in advance for looking into this issue.
+
+[[!format patch """
+From fa3a4be5497300b9b39e121008b474e9dd405fd3 Mon Sep 17 00:00:00 2001
+From: Kyle Meyer <kyle@kyleam.com>
+Date: Tue, 17 Mar 2020 22:16:06 -0400
+Subject: [PATCH] adjust: Propagate submodule changes back to original branch
+
+When the recorded submodule commit changes on an adjusted branch, the
+change is carried in the function that reverseAdjustedCommit passes
+for adjustTree's adjusttreeitem parameter.  Update the CommitObject
+handling in adjustTree to consider adjusttreeitem so that a submodule
+change is synced back.
+---
+ Git/Tree.hs | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/Git/Tree.hs b/Git/Tree.hs
+index da05a3fa5..9627ae969 100644
+--- a/Git/Tree.hs
++++ b/Git/Tree.hs
+@@ -237,8 +237,12 @@ adjustTree adjusttreeitem addtreeitems resolveaddconflict removefiles r repo =
+ 				let !modified' = modified || slmodified || wasmodified
+ 				go h modified' (subtree : c) depth intree is'
+ 			Just CommitObject -> do
+-				let ti = TreeCommit (LsTree.file i) (LsTree.mode i) (LsTree.sha i)
+-				go h wasmodified (ti:c) depth intree is
++				let ti = TreeItem (LsTree.file i) (LsTree.mode i) (LsTree.sha i)
++				v <- adjusttreeitem ti
++				let commit = tc $ fromMaybe ti v
++				go h wasmodified (commit:c) depth intree is
++				where
++					tc (TreeItem f m s) = TreeCommit f m s
+ 			_ -> error ("unexpected object type \"" ++ decodeBS (LsTree.typeobj i) ++ "\"")
+ 		| otherwise = return (c, wasmodified, i:is)
+ 
+-- 
+2.25.1
+
+"""]]
+
+
+[0]: https://github.com/datalad/datalad/issues/4292
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[applied|done]], thanks! --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_1_5b56b989145a8ef6a6203e4df38e2288._comment b/doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_1_5b56b989145a8ef6a6203e4df38e2288._comment
new file mode 100644
index 0000000000..eddad00420
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_1_5b56b989145a8ef6a6203e4df38e2288._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-26T18:15:57Z"
+ content="""
+Little bit of a scary change, because calls to adjustTree could be not
+handling the case of a submodule correctly in their adjusttreeitem
+function.
+
+So I checked them all..
+
+Command.Export uses adjustTree with an adjusttreeitem
+function that runs catKey on the sha from the TreeItem.
+I think that would be ok, because catKey will see it's not 
+a key, and in that case it passes back the TreeItem unchanged.
+
+Each different adjusted branch has its
+own function. Most of those check if the TreeItem
+is a symlink, with a submodule is not, and they'll return
+it unchanged.
+
+The PresenceAdjustment instead
+uses catKey, and again looks ok, because it falls back to returning the
+TreeItem unchanged.
+
+The LockAdjustment, when the TreeItem is not a symlink, also uses catKey,
+which will see it's not a key, and also falls back to returning the
+TreeItem unchanged.
+
+
+Think that's everything, so this seems a safe change to make.
+
+----
+
+But.. I don't actually understand how your change fixes the problem!
+
+(Of course, I tried your patch, and it does work...)
+
+I've been staring at it for 30 minutes and it seems to me that
+the TreeItem you have it construct gets passed to adjusttreeitem,
+which always returns it unchanged (per analysis above). Then you
+deconstruct the TreeItem, extracting the file mode and sha, and
+construct a TreeCommit from those. As far as I can see, that TreeCommit
+must be identical to the one it constructed before this patch.
+
+Hmm, so I added a debug print and it's not the same, the sha
+is different.
+
+What am I missing?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_2_e37aaf6d440b6c2a7567b3df1c344ff7._comment b/doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_2_e37aaf6d440b6c2a7567b3df1c344ff7._comment
new file mode 100644
index 0000000000..f17dd818ff
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_2_e37aaf6d440b6c2a7567b3df1c344ff7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-03-26T18:53:05Z"
+ content="""
+Ok, figured it out.. reverseAdjustedTree uses a `propchanges`
+function that looks at the diff from adjusted branch to basis,
+and substitutes the new sha for the old one. So that's
+how the sha get changed.
+
+My analysis was otherwise correct, I think. And your patch is fine, now
+that I understand that. Applying it as-is.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_3_9e1cc48bb2125cc8fd375e3ff2f3310f._comment b/doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_3_9e1cc48bb2125cc8fd375e3ff2f3310f._comment
new file mode 100644
index 0000000000..53d3ceeacd
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_3_9e1cc48bb2125cc8fd375e3ff2f3310f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 3"
+ date="2020-03-26T23:32:56Z"
+ content="""
+Thanks for taking the time to review this patch and the `add --force-small` ones.  Very much appreciated!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Syntax_error_in_comit_f29d49d47.mdwn b/doc/projects/datalad/bugs-done/Syntax_error_in_comit_f29d49d47.mdwn
new file mode 100644
index 0000000000..2cac185c68
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Syntax_error_in_comit_f29d49d47.mdwn
@@ -0,0 +1,31 @@
+There is a syntax error in commit f29d49d47 that is preventing git-annex from building:
+
+```
+Command/Move.hs:214:36: error: parse error on input `->'
+    |
+214 |                         Right True -> return True
+    |                                    ^^
+```
+
+The following patch fixes it:
+
+```
+diff --git a/Command/Move.hs b/Command/Move.hs
+index 584565648..d8c4bc4c9 100644
+--- a/Command/Move.hs
++++ b/Command/Move.hs
+@@ -210,7 +210,7 @@ fromOk :: Remote -> Key -> Annex Bool
+ fromOk src key
+ 	-- check if the remote contains the key, when it can be done cheaply
+ 	| Remote.hasKeyCheap src = 
+-		Remote.hasKey src key >>= 
++		Remote.hasKey src key >>= \x -> case x of
+ 			Right True -> return True
+ 			-- Don't skip getting the key just because the
+ 			-- remote no longer contains it if the log
+```
+
+[[!meta author=jwodder]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] before this was filed, but only pushed later. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Tests_failing_on_Windows.mdwn b/doc/projects/datalad/bugs-done/Tests_failing_on_Windows.mdwn
new file mode 100644
index 0000000000..f1eeb09311
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Tests_failing_on_Windows.mdwn
@@ -0,0 +1,149 @@
+As of commit 02b9764ff, after building git-annex on Windows with [this patch](https://git-annex.branchable.com/bugs/Patch_for_compilation_errors_on_Windows/) fully applied, running `git annex test` fails with the following output:
+
+[[!format sh """
+Tests
+  QuickCheck
+    prop_encode_decode_roundtrip:                         OK (0.05s)
+      +++ OK, passed 1000 tests.
+    prop_encode_c_decode_c_roundtrip:                     OK (0.02s)
+      +++ OK, passed 1000 tests.
+    prop_isomorphic_key_encode:                           OK (0.03s)
+      +++ OK, passed 1000 tests.
+    prop_isomorphic_shellEscape:                          OK (0.02s)
+      +++ OK, passed 1000 tests.
+    prop_isomorphic_shellEscape_multiword:                OK (0.68s)
+      +++ OK, passed 1000 tests.
+    prop_isomorphic_configEscape:                         OK (0.02s)
+      +++ OK, passed 1000 tests.
+    prop_parse_show_Config:                               OK (0.04s)
+      +++ OK, passed 1000 tests.
+    prop_upFrom_basics:                                   OK (0.02s)
+      +++ OK, passed 1000 tests.
+    prop_relPathDirToFileAbs_basics:                      OK (0.04s)
+      +++ OK, passed 1000 tests.
+    prop_relPathDirToFileAbs_regressionTest:              OK
+      +++ OK, passed 1 test.
+    prop_cost_sane:                                       OK
+      +++ OK, passed 1 test.
+    prop_matcher_sane:                                    OK
+      +++ OK, passed 1 test.
+    prop_HmacSha1WithCipher_sane:                         OK
+      +++ OK, passed 1 test.
+    prop_VectorClock_sane:                                OK
+      +++ OK, passed 1 test.
+    prop_addMapLog_sane:                                  OK
+      +++ OK, passed 1 test.
+    prop_verifiable_sane:                                 OK (0.07s)
+      +++ OK, passed 1000 tests.
+    prop_segment_regressionTest:                          OK
+      +++ OK, passed 1 test.
+    prop_read_write_transferinfo:                         OK (0.04s)
+      +++ OK, passed 1000 tests.
+    prop_read_show_inodecache:                            OK (0.03s)
+      +++ OK, passed 1000 tests.
+    prop_parse_build_presence_log:                        OK (1.39s)
+      +++ OK, passed 1000 tests.
+    prop_parse_build_contentidentifier_log:               OK (1.32s)
+      +++ OK, passed 1000 tests.
+    prop_read_show_TrustLevel:                            OK
+      +++ OK, passed 1 test.
+    prop_parse_build_TrustLevelLog:                       OK
+      +++ OK, passed 1 test.
+    prop_schedule_roundtrips:                             OK (0.01s)
+      +++ OK, passed 1000 tests.
+    prop_past_sane:                                       OK
+      +++ OK, passed 1 test.
+    prop_duration_roundtrips:                             OK
+      +++ OK, passed 1000 tests.
+    prop_metadata_sane:                                   OK (0.82s)
+      +++ OK, passed 1000 tests.
+    prop_metadata_serialize:                              OK (0.89s)
+      +++ OK, passed 1000 tests.
+    prop_branchView_legal:                                OK (0.69s)
+      +++ OK, passed 1000 tests.
+    prop_viewPath_roundtrips:                             OK (0.05s)
+      +++ OK, passed 1000 tests.
+    prop_view_roundtrips:                                 OK (0.41s)
+      +++ OK, passed 1000 tests.
+    prop_viewedFile_rountrips:                            OK (0.03s)
+      +++ OK, passed 1000 tests.
+    prop_b64_roundtrips:                                  OK (0.03s)
+      +++ OK, passed 1000 tests.
+    prop_standardGroups_parse:                            OK
+      +++ OK, passed 1 test.
+    sha1 stable:                                          OK
+      +++ OK, passed 1 test.
+    sha2_224 stable:                                      OK
+      +++ OK, passed 1 test.
+    sha2_256 stable:                                      OK
+      +++ OK, passed 1 test.
+    sha2_384 stable:                                      OK
+      +++ OK, passed 1 test.
+    sha2_512 stable:                                      OK
+      +++ OK, passed 1 test.
+    skein256 stable:                                      OK
+      +++ OK, passed 1 test.
+    skein512 stable:                                      OK
+      +++ OK, passed 1 test.
+    sha3_224 stable:                                      OK
+      +++ OK, passed 1 test.
+    sha3_256 stable:                                      OK
+      +++ OK, passed 1 test.
+    sha3_384 stable:                                      OK
+      +++ OK, passed 1 test.
+    sha3_512 stable:                                      OK
+      +++ OK, passed 1 test.
+    blake2s_160 stable:                                   OK
+      +++ OK, passed 1 test.
+    blake2s_224 stable:                                   OK
+      +++ OK, passed 1 test.
+    blake2s_256 stable:                                   OK
+      +++ OK, passed 1 test.
+    blake2sp_224 stable:                                  OK
+      +++ OK, passed 1 test.
+    blake2sp_256 stable:                                  OK
+      +++ OK, passed 1 test.
+    blake2b_160 stable:                                   OK
+      +++ OK, passed 1 test.
+    blake2b_224 stable:                                   OK
+      +++ OK, passed 1 test.
+    blake2b_256 stable:                                   OK
+      +++ OK, passed 1 test.
+    blake2b_384 stable:                                   OK
+      +++ OK, passed 1 test.
+    blake2b_512 stable:                                   OK
+      +++ OK, passed 1 test.
+    blake2bp_512 stable:                                  OK
+      +++ OK, passed 1 test.
+    md5 stable:                                           OK
+      +++ OK, passed 1 test.
+    HmacSha1 stable:                                      OK
+      +++ OK, passed 1 test.
+    HmacSha224 stable:                                    OK
+      +++ OK, passed 1 test.
+    HmacSha256 stable:                                    OK
+      +++ OK, passed 1 test.
+    HmacSha384 stable:                                    OK
+      +++ OK, passed 1 test.
+    HmacSha512 stable:                                    OK
+      +++ OK, passed 1 test.
+  Remote Tests
+    remote type directory
+  Detected a filesystem without fifo support.
+  Disabling ssh connection caching.
+  Detected a crippled filesystem.
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+Switched to branch 'adjusted/master(unlocked)'
+git-annex.exe: System.PosixCompat.Files.removeLink: not supported: illegal operation
+      init:                                               FAIL (1.48s)
+        Test.hs:250:
+        init failed
+      unavailable remote
+        removeKey:                                        
+##[error]Process completed with exit code 124.
+"""]]
+
+[[!meta author=jwodder]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Tests_failing_on_Windows/comment_1_69e29a9c9b6690684ce1f4f8df3f3a2a._comment b/doc/projects/datalad/bugs-done/Tests_failing_on_Windows/comment_1_69e29a9c9b6690684ce1f4f8df3f3a2a._comment
new file mode 100644
index 0000000000..91a5206227
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Tests_failing_on_Windows/comment_1_69e29a9c9b6690684ce1f4f8df3f3a2a._comment
@@ -0,0 +1,170 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="I concur, in fact `git annex init` doesn't work at all"
+ date="2020-11-24T16:28:24Z"
+ content="""
+You don't need to apply that patch anymore as it's already integrated in said commit.
+In any case a regular `git annex init` fails at the end of it -- no need to even run the tests.
+The following is a full `--debug` trace of the problem (run in *Git Bash*):
+
+[[!format sh \"\"\"
+jkniiv@AINESIS MINGW64 /c/annx/jkniiv
+$ git init test-annex-doesnt-init7
+Initialized empty Git repository in C:/annx/jkniiv/test-annex-doesnt-init7/.git/
+
+jkniiv@AINESIS MINGW64 /c/annx/jkniiv
+$ cd test-annex-doesnt-init7/
+
+jkniiv@AINESIS MINGW64 /c/annx/jkniiv/test-annex-doesnt-init7 (master)
+$ ../../git-annex.exe init --debug \"this a a test annex\"
+init this a a test annex [2020-11-24 18:15:09.0966726] process [14724] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2020-11-24 18:15:09.1256729] process [14724] done ExitFailure 1
+[2020-11-24 18:15:09.132673] process [25092] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--verify\",\"-q\",\"origin/git-annex\"]
+[2020-11-24 18:15:09.167677] process [25092] done ExitFailure 1
+[2020-11-24 18:15:09.1966739] process [19304] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2020-11-24 18:15:09.2326676] process [19304] done ExitSuccess
+[2020-11-24 18:15:09.2396739] process [21104] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\",\"--no-gpg-sign\"]
+[2020-11-24 18:15:09.2867321] process [21104] done ExitSuccess
+[2020-11-24 18:15:09.2946728] process [18512] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"52d153a914036befb21509dffd71b1c61f963128\"]
+[2020-11-24 18:15:09.3826786] process [18512] done ExitSuccess
+[2020-11-24 18:15:09.4066808] process [9000] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"annex.uuid\",\"be53d345-4055-410a-bd96-3406cf2ea624\"]
+[2020-11-24 18:15:09.4456722] process [9000] done ExitSuccess
+[2020-11-24 18:15:09.4566773] process [19308] read: git [\"config\",\"--null\",\"--list\"]
+[2020-11-24 18:15:09.4996747] process [19308] done ExitSuccess
+
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+[2020-11-24 18:15:09.5086746] process [12268] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"annex.sshcaching\",\"false\"]
+[2020-11-24 18:15:09.5546777] process [12268] done ExitSuccess
+[2020-11-24 18:15:09.5626825] process [3884] read: git [\"config\",\"--null\",\"--list\"]
+[2020-11-24 18:15:09.6017154] process [3884] done ExitSuccess
+
+  Detected a crippled filesystem.
+[2020-11-24 18:15:09.6106759] process [10728] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"annex.crippledfilesystem\",\"true\"]
+[2020-11-24 18:15:09.6466714] process [10728] done ExitSuccess
+[2020-11-24 18:15:09.6536743] process [24072] read: git [\"config\",\"--null\",\"--list\"]
+[2020-11-24 18:15:09.6836731] process [24072] done ExitSuccess
+[2020-11-24 18:15:09.6996718] process [2080] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2020-11-24 18:15:09.7376661] process [2080] done ExitSuccess
+[2020-11-24 18:15:09.7436799] process [26508] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2020-11-24 18:15:09.7766675] process [26508] done ExitSuccess
+[2020-11-24 18:15:09.7857266] process [11880] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..52d153a914036befb21509dffd71b1c61f963128\",\"--pretty=%H\",\"-n1\"]
+[2020-11-24 18:15:09.823668] process [11880] done ExitSuccess
+[2020-11-24 18:15:09.8326743] process [13328] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2020-11-24 18:15:09.8406709] process [276] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2020-11-24 18:15:09.848678] process [12984] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2020-11-24 18:15:09.858682] process [14224] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+[2020-11-24 18:15:09.8726713] process [21748] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"refs/heads/git-annex\",\"--\"]
+[2020-11-24 18:15:09.9246702] process [21748] done ExitSuccess
+[2020-11-24 18:15:09.9316687] process [14224] done ExitSuccess
+[2020-11-24 18:15:09.9476714] process [21624] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"annex.version\",\"8\"]
+[2020-11-24 18:15:09.978666] process [21624] done ExitSuccess
+[2020-11-24 18:15:09.9866767] process [25956] read: git [\"config\",\"--null\",\"--list\"]
+[2020-11-24 18:15:10.0146718] process [25956] done ExitSuccess
+[2020-11-24 18:15:10.0216809] process [5596] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"status\",\"--porcelain\"]
+[2020-11-24 18:15:10.0697039] process [5596] done ExitSuccess
+[2020-11-24 18:15:10.0746735] process [9184] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"filter.annex.smudge\",\"git-annex smudge -- %f\"]
+[2020-11-24 18:15:10.1026708] process [9184] done ExitSuccess
+[2020-11-24 18:15:10.1086806] process [6224] read: git [\"config\",\"--null\",\"--list\"]
+[2020-11-24 18:15:10.1396676] process [6224] done ExitSuccess
+[2020-11-24 18:15:10.1436682] process [8364] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"filter.annex.clean\",\"git-annex smudge --clean -- %f\"]
+[2020-11-24 18:15:10.1726771] process [8364] done ExitSuccess
+[2020-11-24 18:15:10.1796716] process [11776] read: git [\"config\",\"--null\",\"--list\"]
+[2020-11-24 18:15:10.2096719] process [11776] done ExitSuccess
+(scanning for unlocked files...)
+[2020-11-24 18:15:10.2166803] process [8628] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--head\"]
+[2020-11-24 18:15:10.2486682] process [8628] done ExitSuccess
+[2020-11-24 18:15:10.2736792] process [1164] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2020-11-24 18:15:10.3076677] process [1164] done ExitSuccess
+[2020-11-24 18:15:10.312673] process [16932] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2020-11-24 18:15:10.3456662] process [16932] done ExitFailure 1
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+[2020-11-24 18:15:10.3526723] process [23920] read: git [\"--version\"]
+[2020-11-24 18:15:10.3786705] process [23920] done ExitSuccess
+[2020-11-24 18:15:10.3856741] process [24572] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2020-11-24 18:15:10.4296714] process [24572] done ExitSuccess
+[2020-11-24 18:15:10.4376789] process [24056] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2020-11-24 18:15:10.4866748] process [24056] done ExitFailure 1
+[2020-11-24 18:15:10.4946748] process [1728] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit\",\"--no-gpg-sign\",\"--quiet\",\"--allow-empty\",\"-m\",\"commit before entering adjusted unlocked branch\"]
+[2020-11-24 18:15:11.0776691] process [1728] done ExitSuccess
+[2020-11-24 18:15:11.0826695] process [3640] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2020-11-24 18:15:11.108669] process [3640] done ExitSuccess
+[2020-11-24 18:15:11.1136702] process [15176] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2020-11-24 18:15:11.1466682] process [15176] done ExitSuccess
+[2020-11-24 18:15:11.1536783] process [24472] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--verify\",\"-q\",\"refs/heads/adjusted/master(unlocked)\"]
+[2020-11-24 18:15:11.186678] process [24472] done ExitFailure 1
+[2020-11-24 18:15:11.1916747] process [25668] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2020-11-24 18:15:11.2236679] process [25668] done ExitSuccess
+[2020-11-24 18:15:11.2286695] process [16952] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2020-11-24 18:15:11.2596741] process [16952] done ExitSuccess
+[2020-11-24 18:15:11.2656783] process [16796] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--verify\",\"-q\",\"refs/heads/adjusted/master(unlocked)\"]
+[2020-11-24 18:15:11.2966705] process [16796] done ExitFailure 1
+[2020-11-24 18:15:11.3046729] process [18584] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/basis/adjusted/master(unlocked)\",\"refs/heads/master\"]
+[2020-11-24 18:15:11.3506912] process [18584] done ExitSuccess
+[2020-11-24 18:15:11.3556766] process [13908] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"mktree\",\"--batch\",\"-z\"]
+[2020-11-24 18:15:11.3626729] process [20108] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-tree\",\"--full-tree\",\"-z\",\"-r\",\"-t\",\"--\",\"refs/basis/adjusted/master(unlocked)\"]
+[2020-11-24 18:15:11.4036732] process [20108] done ExitSuccess
+[2020-11-24 18:15:11.406668] process [13908] done ExitSuccess
+[2020-11-24 18:15:11.411672] process [9932] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2020-11-24 18:15:11.4176708] process [10324] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2020-11-24 18:15:11.4726702] process [20936] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\",\"--no-gpg-sign\",\"-p\",\"refs/basis/adjusted/master(unlocked)\"]
+[2020-11-24 18:15:11.5406728] process [20936] done ExitSuccess
+[2020-11-24 18:15:11.5476778] process [18764] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"-m\",\"entering adjusted branch\",\"refs/heads/adjusted/master(unlocked)\",\"e2fe9e06e323660a2161f243f1d691a46297f7b9\"]
+[2020-11-24 18:15:11.6186724] process [18764] done ExitSuccess
+
+[2020-11-24 18:15:11.6266754] process [22820] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"checkout\",\"adjusted/master(unlocked)\",\"--progress\"]
+Switched to branch 'adjusted/master(unlocked)'
+[2020-11-24 18:15:11.9456734] process [22820] done ExitSuccess
+ok
+[2020-11-24 18:15:11.981671] process [16872] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+[2020-11-24 18:15:12.0146692] process [16872] done ExitSuccess
+[2020-11-24 18:15:12.0216752] process [17292] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2020-11-24 18:15:12.0616647] process [17292] done ExitSuccess
+(recording state in git...)
+[2020-11-24 18:15:12.0686717] process [20456] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+[2020-11-24 18:15:12.0756702] process [264] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"refs/heads/git-annex\",\"--\"]
+[2020-11-24 18:15:12.1226698] process [264] done ExitSuccess
+[2020-11-24 18:15:12.1286677] process [20456] done ExitSuccess
+[2020-11-24 18:15:12.1426731] process [3904] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2020-11-24 18:15:12.1896708] process [3904] done ExitSuccess
+[2020-11-24 18:15:12.1956708] process [19908] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"b8eead277bae945458edc01f8f15f06c9b0d41b0\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"]
+[2020-11-24 18:15:12.2446677] process [19908] done ExitSuccess
+[2020-11-24 18:15:12.2516714] process [15256] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"f596f889462d76e46876497a6505e9d33f5b5012\"]
+[2020-11-24 18:15:12.2986749] process [15256] done ExitSuccess
+git-annex.exe: System.PosixCompat.Files.removeLink: not supported: illegal operation
+
+jkniiv@AINESIS MINGW64 /c/annx/jkniiv/test-annex-doesnt-init7 (adjusted/master(unlocked))
+$ ../../git-annex.exe version
+git-annex version: 8.20201117-g02b9764ff
+build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso hook external
+operating system: mingw32 x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 2 3 4 5 6 7
+local repository version: 8
+
+jkniiv@AINESIS MINGW64 /c/annx/jkniiv/test-annex-doesnt-init7 (adjusted/master(unlocked))
+$ cat .git/config
+[core]
+        repositoryformatversion = 0
+        filemode = false
+        bare = false
+        logallrefupdates = true
+        symlinks = false
+        ignorecase = true
+[annex]
+        uuid = be53d345-4055-410a-bd96-3406cf2ea624
+        sshcaching = false
+        crippledfilesystem = true
+        version = 8
+[filter \"annex\"]
+        smudge = git-annex smudge -- %f
+        clean = git-annex smudge --clean -- %f
+\"\"\"]]
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Tests_failing_on_Windows/comment_2_e95cf7f151ba51fd4324dc212afd5467._comment b/doc/projects/datalad/bugs-done/Tests_failing_on_Windows/comment_2_e95cf7f151ba51fd4324dc212afd5467._comment
new file mode 100644
index 0000000000..4bce0ce237
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Tests_failing_on_Windows/comment_2_e95cf7f151ba51fd4324dc212afd5467._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-11-24T18:32:13Z"
+ content="""
+Fixed earlier today.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes.mdwn b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes.mdwn
new file mode 100644
index 0000000000..84a4b36cbc
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes.mdwn
@@ -0,0 +1,111 @@
+### Please describe the problem.
+
+Even if  -c annex.largefiles=nothing  is used with git add, then git commit  commits file into annex.
+
+This script demonstrates initial finding: http://www.onerussian.com/tmp/ga.sh
+
+Even if we use -c annex.largefiles=nothing  with both add and commit, subsequent   git status   migrates that file into annex (which is even more weird)
+
+Adjusted script demonstrates it: http://www.onerussian.com/tmp/ga-2.sh
+
+### What steps will reproduce the problem?
+
+see above
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170101+gitg93d69b1-1~ndall+1
+
+
+### Please provide any additional information below.
+
+For completeness here is the output of the 2nd script run:
+
+[[!format sh """
+$> /tmp/ga-2.sh
+++ mktemp -d
++ d=/home/yoh/.tmp/tmp.WXTv2cULD0
++ echo 'directory: /home/yoh/.tmp/tmp.WXTv2cULD0'
+directory: /home/yoh/.tmp/tmp.WXTv2cULD0
++ cd /home/yoh/.tmp/tmp.WXTv2cULD0
++ git init
+Initialized empty Git repository in /tmp/tmp.WXTv2cULD0/.git/
++ git annex init --version=6
+init  ok
+(recording state in git...)
++ sed -i -e 's,pre-commit ,pre-commit --debug ,g' .git/hooks/pre-commit
++ echo 'I: creating a file'
+I: creating a file
++ echo whatever
++ git -c annex.largefiles=nothing add file5
++ git annex lookupkey file5
++ echo 'not in annex as it should'
+not in annex as it should
++ git annex find
++ ls -lR .git/annex/objects
+ls: cannot access '.git/annex/objects': No such file or directory
++ :
++ git -c annex.largefiles=nothing commit -m sdf
+[2017-01-27 09:43:27.569648245] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--cached","--name-only","-z","--diff-filter=ACMRT","--","."]
+[2017-01-27 09:43:27.576498829] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2017-01-27 09:43:27.581039152] process done ExitSuccess
+[2017-01-27 09:43:27.581134039] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2017-01-27 09:43:27.585093046] process done ExitFailure 1
+[master (root-commit) 9ec3fe6] sdf
+ 1 file changed, 1 insertion(+)
+ create mode 100644 file5
++ ls -lR .git/annex/objects
+ls: cannot access '.git/annex/objects': No such file or directory
++ :
++ echo 'I: before git status'
+I: before git status
++ ls -lR .git/annex/objects
+ls: cannot access '.git/annex/objects': No such file or directory
++ :
++ git status
+On branch master
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	modified:   file5
+
+no changes added to commit (use "git add" and/or "git commit -a")
++ echo 'I: after git status'
+I: after git status
++ ls -lR .git/annex/objects
+.git/annex/objects:
+total 0
+drwx------ 3 yoh yoh 60 Jan 27 09:43 XF
+
+.git/annex/objects/XF:
+total 0
+drwx------ 3 yoh yoh 60 Jan 27 09:43 pp
+
+.git/annex/objects/XF/pp:
+total 0
+dr-x------ 2 yoh yoh 60 Jan 27 09:43 SHA256E-s9--cd293be6cea034bd45a0352775a219ef5dc7825ce55d1f7dae9762d80ce64411
+
+.git/annex/objects/XF/pp/SHA256E-s9--cd293be6cea034bd45a0352775a219ef5dc7825ce55d1f7dae9762d80ce64411:
+total 4
+-rw------- 1 yoh yoh 9 Jan 27 09:43 SHA256E-s9--cd293be6cea034bd45a0352775a219ef5dc7825ce55d1f7dae9762d80ce64411
++ git diff
+diff --git a/file5 b/file5
+index 982793c..8fdffc0 100644
+--- a/file5
++++ b/file5
+@@ -1 +1 @@
+-whatever
++/annex/objects/SHA256E-s9--cd293be6cea034bd45a0352775a219ef5dc7825ce55d1f7dae9762d80ce64411
+
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+yeap
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]]; clean filter defaults to preserving git/annex state of file.
+> --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_10_5eb0622b326a8094b06f5f0de627e288._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_10_5eb0622b326a8094b06f5f0de627e288._comment
new file mode 100644
index 0000000000..dcba5d1420
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_10_5eb0622b326a8094b06f5f0de627e288._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2018-08-09T19:52:50Z"
+ content="""
+Ben, I can reproduce that, but the file appearing modified in git status 
+is a known  problem documented in [[todo/smudge]]. It's one
+of the primary reasons that v6 mode remains experiemental.
+
+While `git commit -a` in that clone does cause the file to be converted
+from git to annex, touching the file and committing has the same effect. If
+you want to juggle annexed and non-annexed files in a v6 repository without
+letting annex.largefiles tell git-annex what to do, you have to manually
+tell it what to do every time the file is staged. When you `git commit -a`,
+you stage the file and so you need to include `-c annex.largefiles=nothing`
+to keep it from transitioning to the annex.
+
+It think it might make sense to get v6 working to the point that it's
+non-experimental before worrying about such a marginal edge case as this.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_11_a3b5e2047185bbd3972ada07ddb79172._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_11_a3b5e2047185bbd3972ada07ddb79172._comment
new file mode 100644
index 0000000000..45ddfa1014
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_11_a3b5e2047185bbd3972ada07ddb79172._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2018-08-27T17:20:19Z"
+ content="""
+Actually the "some" in-git file showing as modified in status is not the
+same as the git-annex get/drop showing modified in status problem. I've
+fixed the latter and the former still happens.
+
+What's happening is, git runs the clean filter, I think because this
+is a fresh clone and it's not cleaned it yet. That looks at
+annex.largefiles (lack of) configuration and concludes this file belongs in
+the annex, so it ingests it. Rest follows the same as what I described in 
+comment #2.
+
+So yeah, that's a real problem, you clone a repo and there are suddenly
+changes that mess up the painstakingly set up in-annex/in-git division.
+(Note that it does not need to involve an upgrade.)
+
+Only fix I can imagine is my old idea:
+
+> I suppose one way this could be improved is for git annex smudge --clean to
+> check if a file was checked into git as a non-annexed file before, and then
+> avoid cleaning it at all. But then if someone had a non-annexed file and it got
+> big and they wanted to add it annexed, such a change would cause a problem..
+
+I suppose we could get around that problem with a new git-annex command
+that converts a non-annexed file to an annexed file. Without a command,
+this would also work: mv the file to a temp name, followed by git-annex add,
+and then git mv back.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_12_db64ae67b8aa974bd6d00aad005058ac._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_12_db64ae67b8aa974bd6d00aad005058ac._comment
new file mode 100644
index 0000000000..1b373f801e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_12_db64ae67b8aa974bd6d00aad005058ac._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2018-08-27T18:08:24Z"
+ content="""
+Hmm, I think if annex.largefiles is configured, it should be honored. So,
+the ways to convert documented on
+<https://git-annex.branchable.com/tips/largefiles/> will work
+with only a minor modification.
+
+If annex.largefiles is not configured, it can check if the file was annexed
+or not before, and maintain the status quo.
+
+At least to start with I am only going to do it in the clean filter, so
+`git annex add` behavior won't change, it default to annexing. It may make
+sense to make `git annex add` consistent with `git add`, but that would
+also need to affect v5 repositories, probably, and I don't want to entangle
+a v6 bug fix with a v5 behavior change. Also, the risk of a
+`git annex add` with the wrong annex.largefiles temp setting
+is much smaller than the risk of forgetting to temp set annex.largefiles
+when running `git commit -a`. Also, I seem to remember another todo item
+discussing making this change to `git annex add` and would need to revisit
+the thinking in that.
+
+Note that a .gitattributes file might only configure largefiles for eg,
+"*.c" and not for other files, thus implicitly accepting the default
+largefiles for the rest. Should then `Makefile` be treated as having
+largefiles configured or not? I lean toward treating it as not configured,
+because then when the user temporarily overrides largefiles to add `Makefile`
+to git, a modification won't accidentially go to the annex.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_13_5f11262639d60ef63a44de09b191e0b6._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_13_5f11262639d60ef63a44de09b191e0b6._comment
new file mode 100644
index 0000000000..3b68a560cf
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_13_5f11262639d60ef63a44de09b191e0b6._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2018-08-28T14:02:37Z"
+ content="""
+However, that leaves the case where .gitattributes configures
+annex.largefiles, but that's been overridden for a file to add it to git,
+and then the repo is cloned and initted with --version=6 (or upgraded).
+
+Turns out that calling git status before enabling the smudge filter
+prevents git from getting confused about the file being modified in this
+case.
+
+In the fresh clone, git has not populated the index with stat info
+yet, and so it later runs the clean filter on the file, and that
+respects the largefiles configuration, so the way the file is
+stored in git is not taken into account.
+
+Worked around this by adding a `git status` call to the v6
+initialization/upgrade.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_14_cfab68df294195498fe71daa376e9f68._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_14_cfab68df294195498fe71daa376e9f68._comment
new file mode 100644
index 0000000000..1cb3327c50
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_14_cfab68df294195498fe71daa376e9f68._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="michael.hanke@c60e12358aa3fc6060531bdead1f530ac4d582ec"
+ nickname="michael.hanke"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="git annex init --version=6 leaves repo dirty"
+ date="2018-11-18T17:00:21Z"
+ content="""
+With this command in an empty directory, I can more or less reliably cause the issue to happen (again)
+
+`sudo rm -rf .git .datalad .gitattributes * ; git clone https://github.com/datalad/testrepo--minimalds.git . && git annex init --version=6; git status`
+
+using 6.20181011+git124-g94aa0e2f6-1~ndall+1 or 6.20180913-1
+
+Full story is here: [#datalad/2998](https://github.com/datalad/datalad/issues/2998)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_15_e42f03c3e880dcd71d57bc2f6292d95d._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_15_e42f03c3e880dcd71d57bc2f6292d95d._comment
new file mode 100644
index 0000000000..7e19bf85d5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_15_e42f03c3e880dcd71d57bc2f6292d95d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2018-11-19T17:17:07Z"
+ content="""
+6.20180913-1 is from before the problem was fixed.
+
+I don't reproduce the problem with your script, using the current version of git-annex.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_1_045f90b5693de55958c6ad1b825cbc9e._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_1_045f90b5693de55958c6ad1b825cbc9e._comment
new file mode 100644
index 0000000000..b1f3d49b43
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_1_045f90b5693de55958c6ad1b825cbc9e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-01-30T16:07:31Z"
+ content="""
+> Even if  -c annex.largefiles=nothing  is used with git add, then git commit commits file into annex.
+
+I don't reproduce that problem; as long as the file is staged with that -c,
+git commit commits what's staged.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_2_ead7e348547da0598a82be8d064c0c08._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_2_ead7e348547da0598a82be8d064c0c08._comment
new file mode 100644
index 0000000000..f3f287c009
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_2_ead7e348547da0598a82be8d064c0c08._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-01-30T16:11:04Z"
+ content="""
+What's really going on with `git status`:
+
+* It runs `git annex smudge --clean`
+* That ingests the file into the annex, but does not change what's staged at all.
+* When you run `git diff`, it again cleans the file and displays
+  the difference between what is staged (the unannexed file) and the
+  cleaned version (the annexed file).
+* Notice that if you run `git annex add file12 -c annex.largefiles=nothing`
+  after this, the file gets staged in non-annexed file, as you'd expect.
+
+So the only problem I see here is `git annex smudge --clean`
+is ingesting a file into the annex when `git status` is not going to
+update the working tree to use the pointer to that file. But the clean
+hook interface doesn't provide it any way to know why git is asking for a
+file to be cleaned, so it has to always do that.
+
+If this is a small file suitable for being checked into git, the overhead of
+having a copy of it in the annex shouldn't matter much, and annex.thin
+will even make that copy be a hard link.
+
+I suppose one way this could be improved is for `git annex smudge --clean`
+to check if a file was checked into git as a non-annexed file before,
+and then avoid cleaning it at all. But then if someone had a non-annexed
+file and it got big and they wanted to add it annexed, such a change
+would cause a problem..
+
+Or git's smudge/clean interface could be improved so that the clean
+filter can know why it's being called, and so avoid ingesting files
+unnecessarily. IIRC my patch to improve the git interface did do that, but
+unfortunately it's stalled getting accepted into git.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_3_ff0746f08600fb9729b8e1773317a52d._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_3_ff0746f08600fb9729b8e1773317a52d._comment
new file mode 100644
index 0000000000..3f823cab4f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_3_ff0746f08600fb9729b8e1773317a52d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2017-02-06T20:46:29Z"
+ content="""
+thought about it...
+I guess it would then be a limitation, sorry -- a feature, of v6 mode indeed that all instructions on what files should go into annex vs git should always reside within .gitattributes, to be in effect.  Although very powerful, might be limiting in case of a naive user.  Any chance you would pick up on pushing your suggested changes forward (i.e. keep nagging like I do I guess) within git? ;)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_4_598622df322c56da71320d1b15e0348f._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_4_598622df322c56da71320d1b15e0348f._comment
new file mode 100644
index 0000000000..182d19e2e8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_4_598622df322c56da71320d1b15e0348f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="benjamin.poldrack@d09ccff6d42dd20277610b59867cf7462927b8e3"
+ nickname="benjamin.poldrack"
+ avatar="http://cdn.libravatar.org/avatar/5c1a901caa7c2cfeeb7e17e786c5230d"
+ subject="comment 4"
+ date="2017-02-09T09:05:34Z"
+ content="""
+I want to point out an issue, that seems to be unnoticed:
+While we (datalad) might be able to deal with this effect regarding git status in terms of space, it has another consequence. As the scripts are showing it also leads to the file marked as modified, if it is rewritten (very same content) and therefore leaves the repository dirty. To me this a pretty weird effect and I don't understand yet what this is caused by.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_5_9707d9dda7ebb2c94c71f1ea2f99064d._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_5_9707d9dda7ebb2c94c71f1ea2f99064d._comment
new file mode 100644
index 0000000000..cf1822b592
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_5_9707d9dda7ebb2c94c71f1ea2f99064d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="db48x"
+ avatar="http://cdn.libravatar.org/avatar/ad2688127feb555a92154b16d8eeb5d3"
+ subject="comment 5"
+ date="2017-02-14T21:10:13Z"
+ content="""
+I've got a repository that has a small file that gets updated regularly. I've given up trying to keep it unannexed and just started unlocking it every time I run the automated script that updates it.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_6_56c8ddb604b54b8a5cfd077225971582._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_6_56c8ddb604b54b8a5cfd077225971582._comment
new file mode 100644
index 0000000000..8999250aa1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_6_56c8ddb604b54b8a5cfd077225971582._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2017-03-02T17:58:22Z"
+ content="""
+The several comments after my analysis above seem to still be under the
+impression that it's somehow hard to keep files stored in git, not annexed
+in v6 mode. But as my analysis shows, that is not what is happening at all
+in the test case given.
+
+If you have a situation there that problem occurs, please share it.
+Otherwise, I will close this bug report.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_7_6b2a763f3d07f0cdc035008638e08194._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_7_6b2a763f3d07f0cdc035008638e08194._comment
new file mode 100644
index 0000000000..7c7d1b5afe
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_7_6b2a763f3d07f0cdc035008638e08194._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="benjamin.poldrack@d09ccff6d42dd20277610b59867cf7462927b8e3"
+ nickname="benjamin.poldrack"
+ avatar="http://cdn.libravatar.org/avatar/5c1a901caa7c2cfeeb7e17e786c5230d"
+ subject="comment 7"
+ date="2017-03-27T09:03:10Z"
+ content="""
+You are right, if we stage that file again with annex.largefiles option, it stays in git.
+But still keeping a file in git is troublesome. For example: Take a repository with an annexed file and a file in git, clone it and the call git annex init --version=6 on the clone.
+This will lead to a dirty repository, where git status as well as git annex status are stating, that the file in git has unstaged modifications.
+I'm not sure, whether this is actually related but I guess it is. Causing fresh clones to be dirty is at least a strange consequence for having files directly in git.
+
+[[ben]]
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_8_5aa63bf0d8e4145974702a86b36bd435._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_8_5aa63bf0d8e4145974702a86b36bd435._comment
new file mode 100644
index 0000000000..24067287d0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_8_5aa63bf0d8e4145974702a86b36bd435._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""@ben: what?"""
+ date="2017-04-07T16:37:31Z"
+ content="""
+I don't know what you mean with `git annex init` in a v6 repo somehow
+doing something to a non-annexed file. That would be extemely surprising
+if it happened, and it does not happen when I try to follow your
+instructions.
+
+	joey@darkstar:~/tmp/v62>git annex init --version=6
+	init  (merging origin/git-annex into git-annex...)
+	(recording state in git...)
+	ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/v62>ls
+	x  y@
+	joey@darkstar:~/tmp/v62>git annex get y
+	get y (from origin...) (checksum...) ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/v62>git status
+	On branch master
+	Your branch is up-to-date with 'origin/master'.
+	nothing to commit, working tree clean
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_9_5a22839b8dc11965a879dd2654bd5d60._comment b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_9_5a22839b8dc11965a879dd2654bd5d60._comment
new file mode 100644
index 0000000000..c2a1a3dc1b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_9_5a22839b8dc11965a879dd2654bd5d60._comment
@@ -0,0 +1,76 @@
+[[!comment format=mdwn
+ username="benjamin.poldrack@d09ccff6d42dd20277610b59867cf7462927b8e3"
+ nickname="benjamin.poldrack"
+ avatar="http://cdn.libravatar.org/avatar/5c1a901caa7c2cfeeb7e17e786c5230d"
+ subject="@joey: Sorry ..."
+ date="2017-09-14T12:00:09Z"
+ content="""
+... I somehow managed to miss your response. Now, since a somewhat related topic is emerging again with datalad, I looked into this one again.
+I reproduced, what I described before, but I noticed that it involves kind of an implicit upgrade from a V5 to V6 repository.
+
+First, let's have v5 repo with a file in git and a file in annex:
+
+
+    ben@tree /tmp % mkdir origin
+    ben@tree /tmp % cd origin
+    ben@tree /tmp/origin % git init
+    Initialized empty Git repository in /tmp/origin/.git/
+    ben@tree /tmp/origin % git annex init
+    init  ok
+    (recording state in git...)
+    ben@tree /tmp/origin % echo some > some
+    ben@tree /tmp/origin % git add some
+    ben@tree /tmp/origin % echo something different > annex
+    ben@tree /tmp/origin % git annex add annex
+    add annex ok
+    (recording state in git...)
+    ben@tree /tmp/origin % git commit -m \"initial\"
+    [master (root-commit) 8b96354] initial
+     2 files changed, 2 insertions(+)
+     create mode 120000 annex
+     create mode 100644 some
+    ben@tree /tmp/origin % ll
+    total 376
+    drwxr-xr-x  3 ben  ben    4096 Sep 14 13:34 .
+    drwxrwxrwt 24 root root 364544 Sep 14 13:33 ..
+    lrwxrwxrwx  1 ben  ben     180 Sep 14 13:34 annex -> .git/annex/objects/g7/4P/SHA256E-s20--b6105173f468fc7afa866aa469220cd56e5200db590be89922239a38631379c9/SHA256E-s20--b6105173f468fc7afa866aa469220cd56e5200db590be89922239a38631379c9
+    drwxr-xr-x  9 ben  ben    4096 Sep 14 13:34 .git
+    -rw-r--r--  1 ben  ben       5 Sep 14 13:34 some
+    ben@tree /tmp/origin % git ls-files
+    annex
+    some
+    ben@tree /tmp/origin % git annex find
+    annex
+
+Now, clone this repository:
+
+    ben@tree /tmp/origin % cd ..
+    ben@tree /tmp % git clone origin cloned
+    Cloning into 'cloned'...
+    done.
+    ben@tree /tmp % cd cloned
+
+And annex-init as a v6 repository:
+
+    ben@tree /tmp/cloned % git annex init --version=6
+    init  (merging origin/git-annex into git-annex...)
+    (recording state in git...)
+    (scanning for unlocked files...)
+    ok
+    (recording state in git...)
+    ben@tree /tmp/cloned % git status
+    On branch master
+    Your branch is up-to-date with 'origin/master'.
+
+    Changes not staged for commit:
+      (use \"git add <file>...\" to update what will be committed)
+      (use \"git checkout -- <file>...\" to discard changes in working directory)
+
+    	    modified:   some
+
+    no changes added to commit (use \"git add\" and/or \"git commit -a\")
+
+
+This kind of \"implicit\" upgrade might not be a common use case, but the result seems to be a bit weird nonetheless.
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content.mdwn b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content.mdwn
new file mode 100644
index 0000000000..766107e940
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content.mdwn
@@ -0,0 +1,58 @@
+I am using a free 4shared account to test the webdav special remote export.
+
+My repository looks like this:
+
+```
+% tree
+.
+├── ingit.txt
+└── subdir
+    └── inannex.txt -> ../.git/annex/objects/Kp/FZ/MD5E-s7--3b158c5b0a18c247ebad28c09fc3e180.txt/MD5E-s7--3b158c5b0a18c247ebad28c09fc3e180.txt
+
+1 directory, 2 files
+```
+
+My webdav setup:
+
+```
+% git cat-file -p git-annex:remote.log                                                                                 
+93522a6c-8e9f-47a1-a578-b6a18f82d429 encryption=none exporttree=yes name=4shared type=webdav url=https://webdav.4shared.com/datalad-tester/6350cc6b-2af7-41db-89cf-96c3d41f29cc timestamp=1615568357.193179854s
+```
+
+I can export without error, but the resulting layout on the server does not match the local worktree.
+
+```
+.
+├── ingit.txt
+├── inannex.txt
+└── subdir
+```
+
+The annexed file is in the root, and the subdirectory exists, but is empty.
+
+Git annex itself isn't happy with the result either:
+
+```
+% git annex fsck -f 4shared
+fsck subdir/inannex.txt (fixing location log) 
+  ** Based on the location log, subdir/inannex.txt
+  ** was expected to be present, but its content is missing.
+failed
+(recording state in git...)
+git-annex: fsck: 1 failed
+```
+
+On repeated upload attempts to situation remains identical: the annexed files is misplaced into the root.
+
+```
+% git annex export HEAD --to 4shared --json --json-error-messages
+{"command":"export 4shared","success":true,"input":[],"error-messages":[],"file":null}
+```
+
+I have no attempted a replication with another webdav service yet.
+
+Thx!
+
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_10_0598b1ccc9d7002d6b7fa08f29f8edc9._comment b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_10_0598b1ccc9d7002d6b7fa08f29f8edc9._comment
new file mode 100644
index 0000000000..8257ee159f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_10_0598b1ccc9d7002d6b7fa08f29f8edc9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="comment 10"
+ date="2021-03-17T17:03:34Z"
+ content="""
+Sorry, forgot about that.
+
+I `git mv`'ed a file from the root into a subdirectory, and re-exported. It fails:
+
+DAV failure: Status {statusCode = 500, statusMessage = \"Internal Server Error\"} \"<html><body><h1>Server Error</h1></body></html>\" HTTP request: \"MOVE\" \"/dltest20/some%20space/git-annex-webdav-tmp-MD5E-s4--ba1f2511fc30423bdbb183fe33f3dd0f\"
+
+On the server-side the file is removed from the root, but the target directory only has the tmp files.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_11_03ea7014854be4fa9f40a8815616b81d._comment b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_11_03ea7014854be4fa9f40a8815616b81d._comment
new file mode 100644
index 0000000000..e758873603
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_11_03ea7014854be4fa9f40a8815616b81d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2021-03-22T16:27:10Z"
+ content="""
+Ok, failed kind of like I expected, although I have to say the filenames
+don't entirely make sense to me.
+("git-annex-webdav-tmp" is not used in filenames when renaming an exported
+file, only when storing it in the first place)
+
+So what seems to make sense for git-annex to do when renaming an exported
+file is: Try to rename, and if it fails, delete the source and the
+destination -- since it has no idea what may have been left in either place
+-- and then fall back to uploading the file again instead. I have
+implemented that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_1_e4b3597a6be74b10f03af3cdbc9ab4b2._comment b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_1_e4b3597a6be74b10f03af3cdbc9ab4b2._comment
new file mode 100644
index 0000000000..a2ffeb1199
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_1_e4b3597a6be74b10f03af3cdbc9ab4b2._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-12T18:14:59Z"
+ content="""
+Unless this only happens on the one webdav server, my guess is
+it involves the kind of weird way DAV handles collections.
+
+In particular, the content is being written to a temp file,
+which is in the webdav root, and then it runs:
+
+	inLocation src $ moveContentM (B8.fromString newurl)
+
+where src = the webdav root. It may be that ignores the path in newurl and
+just puts it into the same collection.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_2_aa11bebaa9ca341434fbc1382bbbbee4._comment b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_2_aa11bebaa9ca341434fbc1382bbbbee4._comment
new file mode 100644
index 0000000000..016d97291a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_2_aa11bebaa9ca341434fbc1382bbbbee4._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-03-12T18:27:26Z"
+ content="""
+Well, I tried with the box.com webdav server, and did not reproduce the
+problem there; exported files went into the proper subdirectories.
+
+I think there's some chance that the webdav server you're trying to use is
+just broken in its handling of moving from one collection to another. 
+Or perhaps the webdav spec can be interpreted multiple ways and this is
+falling into an edge case.
+
+Here's --debug of it working:
+
+	export box.com sub/t
+	[2021-03-12 14:29:33.044254918] getProps sub/t
+	[2021-03-12 14:29:35.56315446] putContent git-annex-webdav-tmp-SHA256E-s3--98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4
+	[2021-03-12 14:29:37.751164566] delContent sub/t
+	[2021-03-12 14:29:38.695664147] getProps sub
+	[2021-03-12 14:29:40.638445948] moveContent git-annex-webdav-tmp-SHA256E-s3--98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4 https://dav.box.com/dav/git-annex/sub/t
+
+Does it look significantly different in your case?
+
+We unfortunately haven't an easy way to get a HTTP trace, but this shows
+effectively the api calls for the DAV libary, and the moveContent looks
+like it would generate a http request like this:
+
+	MOVE /git-annex-webdav-tmp-SHA256E-s3...
+	Destination: https://dav.box.com/dav/git-annex/sub/t
+
+Which seems fine, there are similar examples in the webdav spec
+of moving from one directory to another.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_3_22290ea94d5e547a199411d696657708._comment b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_3_22290ea94d5e547a199411d696657708._comment
new file mode 100644
index 0000000000..cf70bdf459
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_3_22290ea94d5e547a199411d696657708._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-03-12T18:48:38Z"
+ content="""
+If the problem does involve moving between collections, it could
+avoid the problem by storing the temp file into the subdirectory in the first
+place, and only renaming it to its final name once transferred. 
+
+I've implemented that and committed it along with this comment,
+and it works tested against box.com again, can you try it with
+the 4shared server?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_4_b6c36a9f466cbd0a09ae83ada7bc728c._comment b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_4_b6c36a9f466cbd0a09ae83ada7bc728c._comment
new file mode 100644
index 0000000000..efcf797ad7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_4_b6c36a9f466cbd0a09ae83ada7bc728c._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Progress report"
+ date="2021-03-13T16:19:17Z"
+ content="""
+Thx for the fixes! This seems to be working nicely, but only for subdirectories. All files that are not in the root of a repository are placed in their respective subdirectories, whether or not they are annexed.
+
+However, the export errors for all files in the root. Using `git-annex version: 8.20210311-gecee702b3` I see:
+
+```
+% git annex export HEAD --to 4shared --json --json-error-messages
+{\"command\":\"export 4shared\",\"success\":true,\"input\":[],\"error-messages\":[],\"file\":\".datalad/.gitattributes\"}
+{\"command\":\"export 4shared\",\"success\":true,\"input\":[],\"error-messages\":[],\"file\":\".datalad/config\"}
+{\"command\":\"export 4shared\",\"success\":false,\"input\":[],\"error-messages\":[\"  DAV failure: Status {statusCode = 409, statusMessage = \\"Conflict\\"} \\"<html><body><h1>Conflict</h1></body></html>\\" HTTP request: \\"PUT\\" \\"/dummy/./git-annex-webdav-tmp-GIT--c3aaefef9a2470b31ba9213350046ff7cde75737\\"\"],\"file\":\".gitattributes\"}
+{\"command\":\"export 4shared\",\"success\":false,\"input\":[],\"error-messages\":[\"  DAV failure: Status {statusCode = 409, statusMessage = \\"Conflict\\"} \\"<html><body><h1>Conflict</h1></body></html>\\" HTTP request: \\"PUT\\" \\"/dummy/./git-annex-webdav-tmp-MD5E-s4--971658bc2f5bdee5660844a83b5bf0a2.txt\\"\",\"  DAV failure: Status {statusCode = 409, statusMessage = \\"Conflict\\"} \\"<html><body><h1>Conflict</h1></body></html>\\" HTTP request: \\"PUT\\" \\"/dummy/./git-annex-webdav-tmp-MD5E-s4--971658bc2f5bdee5660844a83b5bf0a2.txt\\"\"],\"file\":\"inannexroot.txt\"}
+{\"command\":\"export 4shared\",\"success\":false,\"input\":[],\"error-messages\":[\"  DAV failure: Status {statusCode = 409, statusMessage = \\"Conflict\\"} \\"<html><body><h1>Conflict</h1></body></html>\\" HTTP request: \\"PUT\\" \\"/dummy/./git-annex-webdav-tmp-GIT--ec28779b36c1a65a3fb8ca1b1cad32c8b1f0fd45\\"\"],\"file\":\"ingit.txt\"}
+git-annex: export: 3 failed
+```
+
+and with `--debug` on a subsequent attempt:
+
+```
+...
+[2021-03-13 17:10:40.082377685] getProps .datalad/.gitattributes
+{\"command\":\"export 4shared\",\"success\":true,\"input\":[],\"error-messages\":[],\"file\":\".datalad/.gitattributes\"}
+[2021-03-13 17:10:41.109311219] getProps .datalad/config
+{\"command\":\"export 4shared\",\"success\":true,\"input\":[],\"error-messages\":[],\"file\":\".datalad/config\"}
+[2021-03-13 17:10:41.274971242] getProps .gitattributes
+[2021-03-13 17:10:41.477825807] putContent ./git-annex-webdav-tmp-GIT--c3aaefef9a2470b31ba9213350046ff7cde75737
+{\"command\":\"export 4shared\",\"success\":false,\"input\":[],\"error-messages\":[\"  DAV failure: Status {statusCode = 409, statusMessage = \\"Conflict\\"} \\"<html><body><h1>Conflict</h1></body></html>\\" HTTP request: \\"PUT\\" \\"/dummy/./git-annex-webdav-tmp-GIT--c3aaefef9a2470b31ba9213350046ff7cde75737\\"\"],\"file\":\".gitattributes\"}
+[2021-03-13 17:10:41.684686094] getProps inannexroot.txt
+[2021-03-13 17:10:42.125435547] putContent ./git-annex-webdav-tmp-MD5E-s4--971658bc2f5bdee5660844a83b5bf0a2.txt
+[2021-03-13 17:10:42.299969611] putContent ./git-annex-webdav-tmp-MD5E-s4--971658bc2f5bdee5660844a83b5bf0a2.txt
+{\"command\":\"export 4shared\",\"success\":false,\"input\":[],\"error-messages\":[\"  DAV failure: Status {statusCode = 409, statusMessage = \\"Conflict\\"} \\"<html><body><h1>Conflict</h1></body></html>\\" HTTP request: \\"PUT\\" \\"/dummy/./git-annex-webdav-tmp-MD5E-s4--971658bc2f5bdee5660844a83b5bf0a2.txt\\"\",\"  DAV failure: Status {statusCode = 409, statusMessage = \\"Conflict\\"} \\"<html><body><h1>Conflict</h1></body></html>\\" HTTP request: \\"PUT\\" \\"/dummy/./git-annex-webdav-tmp-MD5E-s4--971658bc2f5bdee5660844a83b5bf0a2.txt\\"\"],\"file\":\"inannexroot.txt\"}
+[2021-03-13 17:10:42.64284096] getProps ingit.txt
+[2021-03-13 17:10:42.808582229] putContent ./git-annex-webdav-tmp-GIT--ec28779b36c1a65a3fb8ca1b1cad32c8b1f0fd45
+{\"command\":\"export 4shared\",\"success\":false,\"input\":[],\"error-messages\":[\"  DAV failure: Status {statusCode = 409, statusMessage = \\"Conflict\\"} \\"<html><body><h1>Conflict</h1></body></html>\\" HTTP request: \\"PUT\\" \\"/dummy/./git-annex-webdav-tmp-GIT--ec28779b36c1a65a3fb8ca1b1cad32c8b1f0fd45\\"\"],\"file\":\"ingit.txt\"}
+...
+```
+"""]]
diff --git a/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_5_201fb2f59e3143145f9f0b07a5f3ac30._comment b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_5_201fb2f59e3143145f9f0b07a5f3ac30._comment
new file mode 100644
index 0000000000..e5567a075f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_5_201fb2f59e3143145f9f0b07a5f3ac30._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="4shared-specific issue"
+ date="2021-03-13T16:26:12Z"
+ content="""
+I was just able to export one and the same repository with the identical remote parameterization to a Nextcloud instance's WEBDAV. The reported behavior is indeed specific to 4shared, or at least not a general issue.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_6_e1051429a09bf5d7e5887d0eb378d72f._comment b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_6_e1051429a09bf5d7e5887d0eb378d72f._comment
new file mode 100644
index 0000000000..93550ca079
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_6_e1051429a09bf5d7e5887d0eb378d72f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-03-16T18:13:45Z"
+ content="""
+I think I see how my change broke exporting to the top directory of the
+repo. I've committed a fix for that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_7_e50ed095c335c616b8e27fe20dae00d9._comment b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_7_e50ed095c335c616b8e27fe20dae00d9._comment
new file mode 100644
index 0000000000..298a00bd7c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_7_e50ed095c335c616b8e27fe20dae00d9._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-03-16T18:19:17Z"
+ content="""
+I think I see another way that the same webdav server misbehavior could
+happen, since there is also a rename. When a file is in the top of the
+repo, is exported to webdav, then is moved into a subdirectory, and the
+export run again, it will rename it to avoid re-uploading.
+
+mid, can you check if the 4shared server breaks in that situation?
+
+(I notice there's a special case in that code path already for the box.com
+webdav server (see [[!commit bf48ba4ef7aeb69d5efca7c04068ff7752f57f3f]])
+which apparently also had problems with renames. Although as I noted
+upthread, I didn't see the problem reported in this bug report when I
+tested it against box.com.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_8_c1f5a71c217b965ece29fe8d9a01e6b2._comment b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_8_c1f5a71c217b965ece29fe8d9a01e6b2._comment
new file mode 100644
index 0000000000..0b2d80f6e8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_8_c1f5a71c217b965ece29fe8d9a01e6b2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Works!"
+ date="2021-03-17T08:20:08Z"
+ content="""
+I tested export to 4shared with 8.20210311-g02e74c010 and it is working nicely now!
+
+Thx!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_9_b25f2c71675f4d8f6a6e22bb5cd98b23._comment b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_9_b25f2c71675f4d8f6a6e22bb5cd98b23._comment
new file mode 100644
index 0000000000..0f77bcd4a5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/WEBDAV_export_has_wrong_subdirectory_content/comment_9_b25f2c71675f4d8f6a6e22bb5cd98b23._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-03-17T13:44:02Z"
+ content="""
+Can you test the rename case mentioned in comment #7?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/W__58__prop__95__relPathDirToFileAbs__95__basics_started_to_fail.mdwn b/doc/projects/datalad/bugs-done/W__58__prop__95__relPathDirToFileAbs__95__basics_started_to_fail.mdwn
new file mode 100644
index 0000000000..8f400439df
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/W__58__prop__95__relPathDirToFileAbs__95__basics_started_to_fail.mdwn
@@ -0,0 +1,19 @@
+### Please describe the problem.
+
+Recently, with 8.20201129+git100-g2d84bf992 version of git-annex and whatever states of datalad, we have celebrated a Windows Green Day -- our CI was totally green for Windows.
+
+But then Windows started to fail again.  Currently (8.20201129+git125-g7f72314bf) due to
+
+```
+2021-01-18T14:42:32.7075079Z     prop_relPathDirToFileAbs_basics:                      FAIL
+2021-01-18T14:42:32.7078493Z       *** Failed! Falsified (after 54 tests):
+2021-01-18T14:42:32.7082732Z       TestableFilePath {fromTestableFilePath = "/*LFy?\ETBoj(96"}
+2021-01-18T14:42:32.7084569Z       Use --quickcheck-replay=725893 to reproduce.
+```
+
+full list of recent runs with logs etc: [datalad/git-annex github actions](https://github.com/datalad/git-annex/actions?query=workflow%3A%22Build+git-annex+on+Windows%22).  Note that `git annex version` reported is "off": [just filed an issue](https://github.com/datalad/git-annex/issues/44)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__.mdwn b/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__.mdwn
new file mode 100644
index 0000000000..3b1416d031
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__.mdwn
@@ -0,0 +1,99 @@
+### Please describe the problem.
+
+Happens as a part of our test [for datalad-archives external special remote](https://github.com/datalad/datalad/blob/master/datalad/customremotes/tests/test_archives.py#L171) we drop/get the file we just added to git-annex from a tarball.
+
+It works fine on Linux, and from todays fix [8.20201007-144-g7245a9ed5](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=7245a9ed533c87abb70b2b9d06a5d3d5ea2f23b4) we no longer stall, and proceed to that `drop`.  But drop fails claiming that the content is locked.  I have checked processes - there is no some other git annex hanging around and .lck even doesn't exist before we call `drop`.
+
+        (datalad-3) C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_ythgiyjt\a\d>dir ..\..\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc\                                                     
+         Volume in drive C has no label.                                                                                                                                                                                                                           
+         Volume Serial Number is AC6C-BABE                                                                                                                                                                                                                         
+                                                                                                                                                                                                                                                                   
+         Directory of C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_ythgiyjt\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc                                                                  
+                                                                                                                                                                                                                                                                   
+        11/02/2020  05:17 PM    <DIR>          .                                                                                                                                                                                                                   
+        11/02/2020  05:17 PM    <DIR>          ..                                                                                                                                                                                                                  
+        11/02/2020  05:17 PM                 3 SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc               1 File(s)              3 bytes                                                                                      
+                                   2 Dir(s)  23,168,851,968 bytes free                                                                                                                                                                                             
+                                                                                                                                                                                                                                                                   
+
+but then it is created by `drop`:
+                                                                                                                                                                                                                                                                   
+        (datalad-3) C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_ythgiyjt\a\d>git annex drop --debug -- a.datc                                                                                                                                            
+        [2020-11-02 17:21:26.8245443] process [5128] read: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","symbolic-ref","-q","HEAD"]                                                                                                    
+        [2020-11-02 17:21:26.8393936] process [5128] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:26.8393936] process [1452] read: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","show-ref","refs/heads/adjusted/dl-test-branch(unlocked)"]                                                                     
+        [2020-11-02 17:21:26.8860693] process [1452] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:26.8860693] process [2004] read: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","ls-files","--stage","-z","--","a.datc"]                                                                                       
+        [2020-11-02 17:21:26.9331701] process [3452] chat: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]                                               
+        [2020-11-02 17:21:26.9501808] process [4632] chat: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]                                                     
+        [2020-11-02 17:21:26.9501808] process [2920] read: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","show-ref","git-annex"]                                                                                                        
+        [2020-11-02 17:21:27.0113712] process [2920] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:27.0113712] process [976] read: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]                                                                                     
+        [2020-11-02 17:21:27.0580403] process [976] done ExitSuccess                                                                                                                                                                                               
+        [2020-11-02 17:21:27.0580403] process [8] read: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","log","refs/heads/git-annex..6217b1e92de175374dcb552d2bddee0b785073ce","--pretty=%H","-n1"]                                       
+        [2020-11-02 17:21:27.1363275] process [8] done ExitSuccess                                                                                                                                                                                                 
+        [2020-11-02 17:21:27.1363275] process [6948] chat: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]                                                                             
+        [2020-11-02 17:21:27.1675675] process [1728] chat: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","cat-file","--batch"]                                                                                                          
+        [2020-11-02 17:21:27.1675675] process [4840] chat: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]                                                          
+        [2020-11-02 17:21:27.1834634] process [7832] feed: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","update-index","-z","--index-info"]                                                                                            
+        [2020-11-02 17:21:27.2146236] process [6244] read: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","diff-index","--raw","-z","-r","--no-renames","-l0","--cached","refs/heads/git-annex","--"]                                    
+        [2020-11-02 17:21:27.2769931] process [6244] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:27.3111859] process [7832] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:27.3238724] process [5528] chat: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]                                                     
+        [2020-11-02 17:21:27.3864742] process [8556] chat: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]                                         
+        [2020-11-02 17:21:27.4331328] process [1100] chat: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","cat-file","--batch"]                                                                                                          
+        [2020-11-02 17:21:27.4331328] process [3516] chat: git ["--git-dir=..\\..\\.git","--work-tree=..\\..","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]                                                          
+        drop a.datc                                                                                                                                                                                                                                                
+        git-annex: content is locked                                                                                                                                                                                                                               
+        failed                                                                                                                                                                                                                                                     
+        [2020-11-02 17:21:27.5114868] process [1100] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:27.5114868] process [3516] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:27.5114868] process [8556] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:27.5275735] process [6948] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:27.5422938] process [5528] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:27.5422938] process done ExitSuccess                                                                                                                                                                                                     
+        [2020-11-02 17:21:27.5422938] process done ExitSuccess                                                                                                                                                                                                     
+        [2020-11-02 17:21:27.5422938] process [4632] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:27.5422938] process [3452] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:27.5422938] process [2004] done ExitSuccess                                                                                                                                                                                              
+        [2020-11-02 17:21:27.5422938] process done ExitSuccess                                                                                                                                                                                                     
+        git-annex: drop: 1 failed                                                                                                                                                                                                                                  
+                                                           
+
+        (datalad-3) C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_ythgiyjt\a\d>dir ..\..\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc\                                                     
+         Volume in drive C has no label.                                                                                                                                                                                                                           
+         Volume Serial Number is AC6C-BABE                                                                                                                                                                                                                         
+                                                                                                                                                                                                                                                                   
+         Directory of C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_ythgiyjt\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc                                                                  
+                                                                                                                                                                                                                                                                   
+        11/02/2020  05:21 PM    <DIR>          .                                                                                                                                                                                                                   
+        11/02/2020  05:21 PM    <DIR>          ..                                                                                                                                                                                                                  
+        11/02/2020  05:17 PM                 3 SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc                                                                                                                                   
+        11/02/2020  05:21 PM                 0 SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc.lck                                                                                                                               
+                                   2 File(s)              3 bytes                                                                                                                                                                                                  
+                                   2 Dir(s)  23,168,679,936 bytes free         
+
+
+so it seems that `drop` somehow steps on its own feet and gets freaked out.
+
+Here is also some dump from procmon captured during `drop`, and filtered on this lck file name
+
+```
+5:07:49.2392479 PM	git-annex.exe	2144	CreateFile	C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_j7pvlyz2\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc.lck	SUCCESS	Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Opened	File System	8228	8664
+5:07:49.2393198 PM	git-annex.exe	2144	QueryInformationVolume	C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_j7pvlyz2\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc.lck	SUCCESS	VolumeCreationTime: 10/22/2020 2:55:22 PM, VolumeSerialNumber: AC6C-BABE, SupportsObjects: True, VolumeLabel: 	File System	8228	8664
+5:07:49.2393295 PM	git-annex.exe	2144	QueryAllInformationFile	C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_j7pvlyz2\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc.lck	BUFFER OVERFLOW	CreationTime: 11/2/2020 5:02:41 PM, LastAccessTime: 11/2/2020 5:04:56 PM, LastWriteTime: 11/2/2020 5:04:56 PM, ChangeTime: 11/2/2020 5:04:56 PM, FileAttributes: A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x2e000000015258, EaSize: 0, Access: Generic Read/Write, Position: 0, Mode: Synchronous IO Non-Alert, AlignmentRequirement: Word	File System	8228	8664
+5:07:49.2393613 PM	git-annex.exe	2144	QueryInformationVolume	C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_j7pvlyz2\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc.lck	SUCCESS	VolumeCreationTime: 10/22/2020 2:55:22 PM, VolumeSerialNumber: AC6C-BABE, SupportsObjects: True, VolumeLabel: 	File System	8228	8664
+5:07:49.2393740 PM	git-annex.exe	2144	QueryAllInformationFile	C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_j7pvlyz2\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc.lck	BUFFER OVERFLOW	CreationTime: 11/2/2020 5:02:41 PM, LastAccessTime: 11/2/2020 5:04:56 PM, LastWriteTime: 11/2/2020 5:04:56 PM, ChangeTime: 11/2/2020 5:04:56 PM, FileAttributes: A, AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x2e000000015258, EaSize: 0, Access: Generic Read/Write, Position: 0, Mode: Synchronous IO Non-Alert, AlignmentRequirement: Word	File System	8228	8664
+5:07:49.2394246 PM	git-annex.exe	2144	QueryStandardInformationFile	C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_j7pvlyz2\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc.lck	SUCCESS	AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: False, Directory: False	File System	8228	8664
+5:07:49.2394500 PM	git-annex.exe	2144	SetEndOfFileInformationFile	C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_j7pvlyz2\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc.lck	SUCCESS	EndOfFile: 0	File System	8228	8664
+5:07:49.2395339 PM	git-annex.exe	2144	SetAllocationInformationFile	C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_j7pvlyz2\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc.lck	SUCCESS	AllocationSize: 0	File System	8228	8664
+5:07:49.2395801 PM	git-annex.exe	2144	CloseFile	C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_j7pvlyz2\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc.lck	SUCCESS		File System	8228	8664
+```
+
+so it seems to happily create that file.
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] apparently, reopen if neccessary --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_1_ddf822288da76a16eaaade2da51c5b43._comment b/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_1_ddf822288da76a16eaaade2da51c5b43._comment
new file mode 100644
index 0000000000..a739060457
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_1_ddf822288da76a16eaaade2da51c5b43._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2020-11-03T02:12:16Z"
+ content="""
+hehehey -- I think I got the reason at least!  
+
+```
+In [4]: len(r'C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_j7pvlyz2\.git\annex\objects\662\c6f\SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc\SHA256E-s3--a665a45920422f9d417e4867efdc4
+   ...: fb8a04a1f3fff1fa07e998e86f7f7a27ae3.datc.lck')
+Out[4]: 257
+
+```
+so we exceeded the volume of magical dust windows could swallow without it sticking out somewhere...  If I change backend to MD5E we do not observe that issue.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_2_00fa93b8a064bd1e6ca6c35b1a10d5aa._comment b/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_2_00fa93b8a064bd1e6ca6c35b1a10d5aa._comment
new file mode 100644
index 0000000000..bad4075d59
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_2_00fa93b8a064bd1e6ca6c35b1a10d5aa._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-01-13T17:25:08Z"
+ content="""
+It seems that Utility.LockFile.Windows.openLock
+must be returning Nothing for this message
+to be displayed.
+
+Which it does when CreateFile returns `INVALID_HANDLE_VALUE`. Which
+it makes sense it would do for a filename that's too long. Except
+that's taken to mean the locking failed due to it being locked.
+
+(So it seems createfile with the too-long filename is creating the file but
+then failing that way. Which is weird.)
+
+It might be possible to use windows's `GetLastError` to find out that it
+failed due to length, but the API docs don't seem
+to say what the error value is in that case.
+
+Normally ghc modifies filenames on windows to not use the
+compatability layer that has this filename length limit. But since
+this is using the low-level CreateFile, that does not happen here.
+
+The code that does that is not exposed (`create_device_name` in base's
+cbits/fs.c)
+It's basically a matter of prepending `\\?\` to the path, but it also
+has to be made absolute and cannot contain '/'. 
+
+I've implemented something similar in git-annex, which I hope will solve
+this. I have not tried it on windows yet so leaving the bug open for
+confirmation.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_3_26e80ddbcb3f0c149e6565552558f6c7._comment b/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_3_26e80ddbcb3f0c149e6565552558f6c7._comment
new file mode 100644
index 0000000000..34a125dae9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_3_26e80ddbcb3f0c149e6565552558f6c7._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-06-28T16:54:21Z"
+ content="""
+I never heard back -- did the problem get fixed by my changes?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_4_5f9a1e4468a4531a7676d1b749ba0b9e._comment b/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_4_5f9a1e4468a4531a7676d1b749ba0b9e._comment
new file mode 100644
index 0000000000..975dc7ab40
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_4_5f9a1e4468a4531a7676d1b749ba0b9e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2021-06-29T17:27:35Z"
+ content="""
+I don't remember running into it recently so let's coaster resolved, it I could try later in windows vm
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__.mdwn b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__.mdwn
new file mode 100644
index 0000000000..1d422b2316
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+
+Performance on Windows 10.0.19041 even on small text files is 10+ times slower than Git alone, and seems to have dropped over the past months of (windows, git, or git-annex developments).
+
+
+### What steps will reproduce the problem?
+
+Compare performance of `git add` and `git commit` in a Git repo with vs without `git annex init`.
+
+The observations below have been taken from [this DataLad issue](https://github.com/datalad/datalad/issues/5994). The hardware of the test system is described over there, but only the relative performance is relevant here.
+
+- `git init`: 0.1s
+- `git annex init`: 5.7s
+
+First timing info is the command executed in an annex-repo (after `git annex init`), the second timing is the same command executed in a plain Git repo.
+
+after creating a 3-byte text file:
+
+- `git add file`: 1.9s (0.1s)
+- `git commit file -m msg`: 3.2s (0.1s)
+
+after creating two new 3-byte test files:
+
+- `git add .`: 4.5s (0.1s)
+- `git commit -m msg`: 2.4s (0.1s)
+
+after creating eight more 3-byte text files:
+
+- `git add .`: 13.1s (0.1s)
+- `git commit -m msg`: 1.6 (0.1s)
+
+now adding a 225 MB binary file
+
+- `git add binfiile`: 16s (13s)
+- `git commit -m msg`: 2s (0.2s)
+
+no changes
+
+- `git commit --amend -m msg`: 2s (0.1s)
+
+So it looks as if there is a substantial per-file cost of `add` in an annex repo that is not explained by the underlying Git repo performance.
+
+
+
+### What version of git-annex are you using? On what operating system?
+
+- Windows 10.0.19041
+- Git 2.33.0.windows.2
+- git-annex 8.20210804-g1d3f59a9d
+
+### Please provide any additional information below.
+
+The linked datalad issue has more information on the configuration of the Git installation, but that only seems to affect performance broadly, and not git-annex specifically.
+
+I am reporting this behavior now, because it has worsened since [I last looked into performance on windows](https://github.com/datalad/datalad/issues/5317). It is unclear to me, which developments have led to this (also the windows version has progressed since then). However, even back then, it looked like there is a windows-specific performance issues that cannot be explained by the general handling of crippled filesystems or adjusted branches (comparing performance on an NTFS drive mounted on Debian vs a native windows box).
+
+
+Thanks for git-annex!
+
+[[!tag projects/datalad]]
+
+> [[fixed|done]] (enable filter.annex.process) --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_10_4e3cec5a4ce33dadfd0ce7a8d17bfaa0._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_10_4e3cec5a4ce33dadfd0ce7a8d17bfaa0._comment
new file mode 100644
index 0000000000..f6535207db
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_10_4e3cec5a4ce33dadfd0ce7a8d17bfaa0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-09-28T17:57:50Z"
+ content="""
+Since my profiling above shows windows is as fast as linux (though
+probably on faster hardware), one thing I am wondering is if antivirus
+could be slowing it down. I know AV on windows can slow down things like
+writing to files, because it blocks closing the file until it finishes
+scanning. Maybe the github windows CI does not run AV, but your windows
+does, mih?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_12_f1a92680ab7874aa0c102cbf4b8a445a._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_12_f1a92680ab7874aa0c102cbf4b8a445a._comment
new file mode 100644
index 0000000000..cb45f4b039
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_12_f1a92680ab7874aa0c102cbf4b8a445a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2021-09-28T18:01:17Z"
+ content="""
+@adina.wagner wonderful, thanks for the second windows profile..
+
+You need to run `git-annex init` first, unsure if you did. And 
+you need to create the file `x`, containing eg "foo", and pipe
+that file to `git-annex smudge --clean x`
+
+I think your profile reflects it being stuck waiting
+for stdin for some time, with the `GHC.IO.Handle.FD` at the top.
+Otherwise, it would probably look more
+like the one I did on window, since createProcess is near the
+top. It would be good to verify that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_13_e38a372b6d9f498160369a9c3071939a._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_13_e38a372b6d9f498160369a9c3071939a._comment
new file mode 100644
index 0000000000..9e98bffe5f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_13_e38a372b6d9f498160369a9c3071939a._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2021-09-28T18:13:08Z"
+ content="""
+For future reference, I modified the datalad/git-annex workflow to build on windows
+to do the profiling, here's how the end of that workflow looks:
+
+      - name: Build git-annex
+        run: stack install --profile --no-haddock --extra-include-dirs=$PWD --extra-lib-dirs=$PWD --local-bin-path .
+
+      - name: profile
+        run: |
+          git init profile
+          cd profile
+          PATH=..:$PATH ../git-annex.exe init
+          echo foo > x
+          ../git-annex.exe +RTS -p -RTS smudge --clean x
+          cat git-annex.prof
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_14_26472db382e75e03cf10c6e5770ef42b._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_14_26472db382e75e03cf10c6e5770ef42b._comment
new file mode 100644
index 0000000000..0916c49763
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_14_26472db382e75e03cf10c6e5770ef42b._comment
@@ -0,0 +1,53 @@
+[[!comment format=mdwn
+ username="adina.wagner@2a4cac6443aada2bd2a329b8a33f4a7b87cc8eff"
+ nickname="adina.wagner"
+ avatar="http://cdn.libravatar.org/avatar/80b124ad61d6008fa0f6f0b4b0f7c2ef"
+ subject="comment 14"
+ date="2021-09-28T19:19:20Z"
+ content="""
+> And you need to create the file x, containing eg \"foo\", and pipe that file to git-annex smudge --clean x
+
+Thanks much for clarifying! I did run ``git annex init``, but did not create and pipe the file into the command. Here is the profile after running it correctly:
+
+
+```
+	Tue Sep 28 21:00 2021 Time and Allocation Profiling Report  (Final)
+
+	   git-annex.exe +RTS -p -RTS smudge x --clean
+
+	total time  =        0.01 secs   (13 ticks @ 1000 us, 1 processor)
+	total alloc =   5,906,000 bytes  (excludes profiling overheads)
+
+COST CENTRE           MODULE                             SRC                                                %time %alloc
+
+cmdname               Types.Command                      Types\Command.hs:80:11-17                           15.4    0.0
+MAIN                  MAIN                               <built-in>                                           7.7    0.1
+catchMaybeIO          Utility.Exception                  Utility\Exception.hs:53:1-63                         7.7    0.2
+readish               Utility.PartialPrelude             Utility\PartialPrelude.hs:(57,1)-(59,20)             7.7    0.4
+createProcess         Utility.Process                    Utility\Process.hs:(177,1)-(180,16)                  7.7    6.9
+readInodeCache        Utility.InodeCache                 Utility\InodeCache.hs:(175,1)-(186,20)               7.7    0.6
+read                  Git.Config                         Git\Config.hs:(41,1)-(43,33)                         7.7    0.0
+CAF:cmd3              Command.Find                       <no location info>                                   7.7    0.0
+normalise.dropDots    System.FilePath.Windows.ByteString System\FilePath\Windows\..\Internal.hs:1018:9-34     7.7    0.0
+execParserPure.pinfo' Options.Applicative.Extra          src\Options\Applicative\Extra.hs:(136,5)-(138,51)    7.7    0.0
+uncons                Data.ByteString.UTF8               Data\ByteString\UTF8.hs:(166,1)-(167,38)             7.7    1.0
+catch                 Control.Monad.Catch                src\Control\Monad\Catch.hs:333:3-32                  7.7    0.3
+doesPathExist         Utility.RawFilePath                Utility\RawFilePath.hs:80:1-49                       0.0    4.0
+getFileSize           Utility.FileSize                   Utility\FileSize.hs:37:1-80                          0.0    3.9
+toInodeCache'         Utility.InodeCache                 Utility\InodeCache.hs:(196,1)-(206,34)               0.0    9.7
+assertLocal           Git                                Git.hs:(131,1)-(137,28)                              0.0    1.1
+clean                 Command.Smudge                     Command\Smudge.hs:(90,1)-(173,60)                    0.0    1.1
+escape                Database.Persist.Sqlite            Database\Persist\Sqlite.hs:(605,1)-(610,24)          0.0    1.2
+getFileType           System.PosixCompat.Files           src\System\PosixCompat\Files.hsc:(350,1)-(355,62)    0.0    9.4
+getFileStatus         System.PosixCompat.Files           src\System\PosixCompat\Files.hsc:(312,1)-(337,24)    0.0   19.4
+getFileSize           System.PosixCompat.Files           src\System\PosixCompat\Files.hsc:(358,1)-(359,76)    0.0    3.9
+unconsB               Codec.Binary.UTF8.Generic          Codec\Binary\UTF8\Generic.hs:297:1-18                0.0    3.7
+foldr                 Data.ByteString.UTF8               Data\ByteString\UTF8.hs:(171,1)-(173,40)             0.0    2.8
+decode.choose         Data.ByteString.UTF8               Data\ByteString\UTF8.hs:(72,3)-(78,39)               0.0    1.8
+decode                Data.ByteString.UTF8               Data\ByteString\UTF8.hs:(68,1)-(124,32)              0.0    1.3
+```
+
+>  one thing I am wondering is if antivirus could be slowing it down. I know AV on windows can slow down things like writing to files, because it blocks closing the file until it finishes scanning.
+
+The one I am using doesn't run AV, and I believe @mih's doesn't either. 
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_15_94d2048dcd33712e08f2206a5182b23f._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_15_94d2048dcd33712e08f2206a5182b23f._comment
new file mode 100644
index 0000000000..0368810127
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_15_94d2048dcd33712e08f2206a5182b23f._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2021-09-28T20:33:00Z"
+ content="""
+	cmdname               Types.Command                      Types\Command.hs:80:11-17                           15.4    0.0
+
+I don't trust this latest profile, because cmdname is a 
+a field of a data structure. There's no code there to take 15% of
+runtime, it's basically following a pointer.
+I think probably the profiler got confused there.
+
+Anyway, `git-annex smudge --clean x < x` is running as fast in that profile
+as it does on linux, and is certainly nowhere near the 1.9s runtime of `git add`
+that this bug report is about. I wonder if it also runs that fast for @mih?
+
+Possibly something else is making git add slow.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_16_0a170534b266ca55afbfcfe191ff18fc._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_16_0a170534b266ca55afbfcfe191ff18fc._comment
new file mode 100644
index 0000000000..0607f45806
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_16_0a170534b266ca55afbfcfe191ff18fc._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2021-09-28T21:53:49Z"
+ content="""
+`git add x` takes less than 0.1 seconds run on the github windows CI in a
+git-annex repo.
+
+      - name: profile
+        run: |
+          git init profile
+          cd profile
+          PATH=..:$PATH ../git-annex.exe init
+          echo foo > x
+          date
+          PATH=..:$PATH git add x
+          date
+
+Output:
+
+	ok
+	(recording state in git...)
+	Tue Sep 28 21:51:46 CUT 2021
+	warning: LF will be replaced by CRLF in x.
+	The file will have its original line endings in your working directory
+	Tue Sep 28 21:51:46 CUT 2021
+
+So, whatever made it slow for @mih is not a problem here, and I guess
+not where @adina ran it either.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_17_7db34973cb362bee271545c3c58690b4._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_17_7db34973cb362bee271545c3c58690b4._comment
new file mode 100644
index 0000000000..62774e4b12
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_17_7db34973cb362bee271545c3c58690b4._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 17"""
+ date="2021-11-16T16:28:11Z"
+ content="""
+The new `git-annex filter-process` should improve this speed a lot.
+It avoids a new process being started for each file that is added.
+
+git config filter.annex.process 'git-annex filter-process'
+
+That may become the default in v9, or possibly in new v8 repositories.
+
+There is a tradeoff, since `git add` of a large file to the annex gets
+slower when it's enabled. Only about 5% in my benchmarks on linux, but
+maybe more on windows, I don't know.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_18_2e8e840cabbc547ef758568bb2779f9a._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_18_2e8e840cabbc547ef758568bb2779f9a._comment
new file mode 100644
index 0000000000..22fbac94a1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_18_2e8e840cabbc547ef758568bb2779f9a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Translates to Windows!"
+ date="2021-11-25T07:34:48Z"
+ content="""
+Sorry for being silent for so long. I just got a contemporary machine with windows, such that hardware age should no longer be a concern for any performance comparison.
+
+I did not yet find the time to re-assess this issue in full, but I tried the new filter-process setting with a simple `datalad create` (this only adds a few tiny files, but nevertheless took long, and was the original motivation for this issue). Enabling the new setting reduces the runtime by 25% (from 4.5s to 3.5s on average).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_19_c89853eca5c16e9dfa4a4acc982ab526._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_19_c89853eca5c16e9dfa4a4acc982ab526._comment
new file mode 100644
index 0000000000..ffbf19ebf9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_19_c89853eca5c16e9dfa4a4acc982ab526._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="More statistics"
+ date="2021-11-25T13:09:11Z"
+ content="""
+I looked into the global affect of this switch on a large and versatile set of use cases in the form of the DataLad test suite: https://github.com/datalad/datalad/pull/6245
+
+It is worth keeping in mind that there are only small-size files involved!
+
+The benefit is somewhere between noticeable and remarkable. An overall runtime reduction of 16% with benefits ranging from 5% to 32% depending on the tested functionality.
+
+This will need a bit of further investigation to drill down on the reason for this large variability, but given that the sign is always in the right direction this is really great! Thx much!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_1_8623b98bf21427ae5734d74e2576af5b._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_1_8623b98bf21427ae5734d74e2576af5b._comment
new file mode 100644
index 0000000000..90bb281f8d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_1_8623b98bf21427ae5734d74e2576af5b._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-09-21T14:29:12Z"
+ content="""
+Each `git add` has to run a new `git annex smudge`
+process. `git commit` will often run it as well.
+This is discussed in detail in
+[[todo/git_smudge_clean_interface_suboptiomal]].
+
+According to
+<https://github.com/datalad/datalad/issues/5994#issuecomment-923744895>
+git-annex 8.20201127 had the same performance that you are seeing
+with the current version. So it cannot be any changes in the past year
+that impacted git-annex performance.
+
+But <https://github.com/datalad/datalad/issues/5317> seems like it would
+have been using around the same version of git-annex, and the timing there
+was much faster. Unfortunatly the issue does not say what version
+of git-annex was used, but it seems likely it would have been around
+8.20201127 since that was released 2 months prior.
+
+So are the timings in those issues comparable, or is it an apples/oranges
+comparison with different hardware or OS version?
+
+And if the timings between those issues are not comparable, what exactly
+is this new issue comparing with when it says the peformance has worsened?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_20_281ded4caa0dd407431b205ce6746c05._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_20_281ded4caa0dd407431b205ce6746c05._comment
new file mode 100644
index 0000000000..39230325a6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_20_281ded4caa0dd407431b205ce6746c05._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Even more impact on real systems"
+ date="2021-11-26T14:23:34Z"
+ content="""
+It seems the impact on real systems is even more sever: https://github.com/datalad/datalad/pull/6245#issuecomment-979992551 -- factor 2-3 faster on that particular machine. Maybe consumer systems do some kind of expensive process startup inspection (antivirus?) that bring a swarm of child processes to a crawl.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_21_cc08c222cc36e3a0462f370df12eb129._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_21_cc08c222cc36e3a0462f370df12eb129._comment
new file mode 100644
index 0000000000..3c08a42faa
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_21_cc08c222cc36e3a0462f370df12eb129._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 21"""
+ date="2021-11-29T17:17:29Z"
+ content="""
+@mih I've been pondering enabling filter.annex.process by default in new
+repositories in Windows or generally. (Enabling it in existing repositories
+kind of needs a new major version so an upgrade can set it, although introducing
+repository minor versions is also a possibility.)
+
+Enabling it earlier in datalad is fine by me, more experience with it being
+used would be good.
+
+It would also be useful to get some benchmarks of `git add` when 
+large files are added to the annex (eg `git -c annex.largefiles=anything
+add`). As I said, that suffers around 5% on performance on Linux, at least
+when the files are small enough to still mostly fit in disk cache (1 gb on
+a 4 gb system with some web browsers etc running). It may be
+that Windows will pay a higher price. I don't have real Windows machines
+to run such a benchmark on myself. Please post any such benchmarks
+to [[todo/incremental_hashing_for_add]].
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_22_1c001d885bd4d7f60b3260d494406e5c._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_22_1c001d885bd4d7f60b3260d494406e5c._comment
new file mode 100644
index 0000000000..fc6853dd50
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_22_1c001d885bd4d7f60b3260d494406e5c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 22"""
+ date="2022-01-11T17:24:49Z"
+ content="""
+Enabling filter.annex.process in new repositories would unfortunately
+break using that repository with an older version of git-annex before that
+was added to it. So it seems that `git-annex init` cannot do it for
+annex.version 8 and will need to wait for v9.
+
+Of course, if you are sure users of a repository will not be using an old
+version of git-annex, it's fine to enable it.
+
+I'm going to close this bug now, since [[todo/v9_changes]] is open to get it
+enabled by default in v9.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_23_cedee281d3f6f97499e70dacd0560f70._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_23_cedee281d3f6f97499e70dacd0560f70._comment
new file mode 100644
index 0000000000..285a3ed8cb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_23_cedee281d3f6f97499e70dacd0560f70._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2022-01-21T17:04:11Z"
+ content="""
+v9 is implemented, and enables filter-process. Not yet the default, but
+will be eventually.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_2_80c5ec6993e8a720fbd1841fdd21e311._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_2_80c5ec6993e8a720fbd1841fdd21e311._comment
new file mode 100644
index 0000000000..7a339930a0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_2_80c5ec6993e8a720fbd1841fdd21e311._comment
@@ -0,0 +1,68 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Performance stats on crippled Debian NTFS-mount"
+ date="2021-09-22T18:37:10Z"
+ content="""
+I am responding to your comments in an altered order:
+
+> So are the timings in those issues comparable, or is it an apples/oranges comparison with different hardware or OS version? And if the timings between those issues are not comparable, what exactly is this new issue comparing with when it says the performance has worsened?
+
+The timing are comparable insofar as they come from the same hardware and \"same\" OS, but that OS has seen various updates over time, hence cannot be considered constant.
+
+> Each git add has to run a new git annex smudge process. git commit will often run it as well. This is discussed in detail in git smudge clean interface suboptiomal.
+
+Yes, I understand that this is a limitation that is outside the control of git-annex. However, the difference between windows (with implied crippling) and a crippled FS mounted on a proper OS are substantial. Here are a bunch of stats, matching those above.
+
+From https://github.com/datalad/datalad/issues/5317#issuecomment-760767158 a description on how the real windows test system used above relates to my laptop used for the stats below:
+
+> The machine is a little older (1 year older than the machine I used for the stats posted before), but not a cripple (Core i5, two physical cores at 2.6GHz, 8GB RAM, mSATA SSD, uptodate bios from 2019, and an uptodate win10).
+
+Here I am using a Core i7-6500U CPU @ 2.50GHz, 8GB RAM, mSATA SSD (via USB3). git 2.33.0, git annex version 8.20210903:
+
+For convenience, I am putting the values from my original post with the stats computed on windows in *brackets*.
+
+- git init: 0.01s *[0.1s]*
+- git annex init: 0.1s *[5.7s]*
+
+First timing info is the command executed in an annex-repo (after git annex init), the second timing is the same command executed in a plain Git repo.
+
+after creating a 3-byte text file:
+
+- git add file: 0.05s (0.01s) *[1.9s (0.1s)]*
+- git commit file -m msg: 0.08s (0.02s) *[3.2s (0.1s)]*
+
+after creating two new 3-byte test files:
+
+- git add .: 0.08s (0.01s) *[4.5s (0.1s)]*
+- git commit -m msg: 0.04s (0.02s) *[2.4s (0.1s)]*
+
+after creating eight more 3-byte text files:
+
+- git add .: 0.36s (0.01s) *[13.1s (0.1s)]*
+- git commit -m msg: 0.04s (0.01s) *[1.6 (0.1s)]*
+
+now adding a 225 MB binary file
+
+- git add binfiile: 10.8s (10.9s) *[16s (13s)]*
+- git commit -m msg: 1.2s (0.03s) *[2s (0.2s)]*
+
+no changes
+
+- git commit --amend -m msg: 1.3s (0.01s) *[2s (0.1s)]*
+
+
+So taken together, we can clearly see the price that needs to be paid for the smudge filter approach. However, it is nowhere near the penalty paid on the real windows system, both in absolute terms, as well as relative to plain git operations. Critically (for me) the total difference for a `datalad create` amounts to:
+
+- 25s on a crippled NTFS drive on windows
+- 0.9s on a crippled NTFS drive on Debian
+
+(on otherwise fairly comparable hardware).
+
+I think this indicates that something is slower on windows that *cannot* be explained by
+
+- Git generally being slower on Windows
+- git-annex generally being slower when juggling smudge filters and adjusted branches
+- an overall performance difference between my two test machines
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_3_85f07d906b836ac968ab877258180c0c._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_3_85f07d906b836ac968ab877258180c0c._comment
new file mode 100644
index 0000000000..0eb1184d91
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_3_85f07d906b836ac968ab877258180c0c._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-09-22T19:33:58Z"
+ content="""
+Look at the 3 git add results, dividing windows runtime by linux:
+
+	1.9/0.05 = 38.00
+	4.5/0.08 = 56.25
+	13.1/0.36 = 36.39
+
+The middle is slightly an outlier, and it would be better to have more data
+points, but what this says to me is it's probably around 38x more expensive
+on windows than on linux for git-annex smudge --clean to run.
+
+git-annex smudge --clean makes on the order of 4000 syscalls, including
+opening 200 files, execing git 8 times, and statting 500 files. That's
+around 10x as many syscalls as git add makes. And it's run once per file. So
+relatively small differences in syscall performance between windows and
+linux can add up.
+
+I've looked at just this kind of comparisons before, and it has always
+seemed explainable by differences in syscall overhead. I don't
+really see anything in your numbers that says otherwise.
+
+I'm still curious if there's an older version of git-annex that was faster
+(after it stopped using direct mode in v7).
+If I've understood correctly, you don't seem to be saying that there is.
+
+If it's always been this slow, then about all I can think to do to improve
+it is profile git-annex smudge --clean on windows and see if anything other
+than those syscalls is somehow being slow.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_4_0d2ab75208877136534040b726c7f97b._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_4_0d2ab75208877136534040b726c7f97b._comment
new file mode 100644
index 0000000000..ab347d10a5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_4_0d2ab75208877136534040b726c7f97b._comment
@@ -0,0 +1,62 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="v7 v v8 comparison"
+ date="2021-09-23T06:29:30Z"
+ content="""
+> I'm still curious if there's an older version of git-annex that was faster (after it stopped using direct mode in v7). If I've understood correctly, you don't seem to be saying that there is.
+
+Here is some data that seems to support this view.
+
+I dug up another windows box on the higher performance end
+
+- windows 11 (not 10!) build 10.0.22000
+- intel 6-core xeon E-2136 @ 3.3ghz
+- NVMe drive
+
+All stats done with
+
+- git 2.32.0.windows.2
+
+I am reporting two values each, the first for git annex 8.20210715-g7334893d4 and the second for 7.20191107-g8ea269ef7 (the oldest windows build that I could find). Consequently, the first measurement is for a v8 repo, the second for a v7 repo (but no direct mode).
+
+init
+
+- git init: 0.1s / 0.1s
+- git annex init: 3.2s / 3.2s
+
+after creating a 3-byte text file:
+
+- git add file: 1.0s / 0.9s
+- git commit file -m msg: 1.8s / 1.8s
+
+after creating two new 3-byte test files:
+
+- git add .: 1.9s / 1.7s
+- git commit -m msg: 0.9s / 0.9s
+
+(NB: the `add` increase is caused by unique keys, adding a bunch of identical files is the same as adding one file)
+
+after creating eight more 3-byte text files:
+
+- git add .: 6.5s / 6.8s
+- git commit -m msg: 0.9s / 0.9s
+
+now adding a 280 MB binary file
+
+- git add binfiile: 9.8s / 9.9s
+- git commit -m msg: 1.2s / 1.2s
+
+no changes
+
+- git commit --amend -m msg: 1.2s / 1.2s
+
+
+
+
+So there is pretty much no change, and in particular no change attributable to the last ~2 years of git-annex evolution.
+
+However, what remains is that a substantially more capable windows workstation (internal NVMe, faster CPU) comes nowhere near the performance of my 6 year old Debian laptop with an external USB3 drive -- despite having to go through the same smudge filter complications.
+
+I would be grateful, if you could have a look at the windows implementation of `smudge --clean`. Please let me know what kind of contribution could help to push such an effort. Thanks!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_5_891b532bd662b1198351803b82ed634e._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_5_891b532bd662b1198351803b82ed634e._comment
new file mode 100644
index 0000000000..cbed74725c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_5_891b532bd662b1198351803b82ed634e._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-09-23T17:22:19Z"
+ content="""
+Thank you for verifying this is not a recent speed reversion.
+
+You could use `git -c filter.annex.clean= add smallfile`
+to avoid the overhead of the smudge filter.
+Using `git annex add --force-small` or `git annex add` with an
+annex.largefiles config will also avoid it.
+
+ghc 8.12 has a new IO manager for windows, which
+I think is likely to be faster. (It avoids the win32 API.) I would
+want to look at that before other windows-specific optimisations.
+The windows build is still using lts-16.27 (ghc 8.8.3), there is not
+yet an lts release with ghc 8.12.
+
+I don't know if there are really any windows-specific optimisations to
+be had in the smudge code other than such low-level stuff.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_6_3947b44c88820da49d8a2d1afd3595ff._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_6_3947b44c88820da49d8a2d1afd3595ff._comment
new file mode 100644
index 0000000000..8f4802eaa6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_6_3947b44c88820da49d8a2d1afd3595ff._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-09-23T17:48:19Z"
+ content="""
+I noticed in the strace that smudge --clean ran git cat-file 2
+more times than necessary. Also was able to avoid updating the git-annex
+branch, which eliminates several calls to git (depending on the number of
+remotes). On Linux, this made it 25% faster. Might be more on Windows.
+
+Rest of the strace looks clean, nothing else stands out as unnecessary.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_7_1c867ba26de03f921dd347c14b8ec402._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_7_1c867ba26de03f921dd347c14b8ec402._comment
new file mode 100644
index 0000000000..44bb65d144
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_7_1c867ba26de03f921dd347c14b8ec402._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-09-24T22:21:45Z"
+ content="""
+Here is a time profile, git-annex built with `stack build --profile`
+on linux.
+
+	        Fri Sep 24 18:18 2021 Time and Allocation Profiling Report  (Final)
+	
+	           git-annex +RTS -p -RTS smudge --clean x
+	
+	        total time  =        0.01 secs   (13 ticks @ 1000 us, 1 processor)
+	        total alloc =   1,732,704 bytes  (excludes profiling overheads)
+	
+	COST CENTRE                    MODULE                           SRC                                                    %time %alloc
+	
+	createProcess                  Utility.Process                  Utility/Process.hs:(177,1)-(180,16)                     23.1   16.3
+	MAIN                           MAIN                             <built-in>                                               7.7    1.5
+	>>=.\                          Data.Attoparsec.Internal.Types   Data/Attoparsec/Internal/Types.hs:(148,9)-(149,44)       7.7    0.2
+	searchParser                   Options.Applicative.Common       src/Options/Applicative/Common.hs:(136,1)-(151,40)       7.7    0.9
+	splitPath.f                    System.FilePath.Posix.ByteString System/FilePath/Posix/../Internal.hs:(857,9)-(862,49)    7.7    1.6
+	withCatFileMetaDataHandle      Annex.CatFile                    Annex/CatFile.hs:(86,1)-(89,46)                          7.7    0.0
+	withAltRepo                    Annex.GitOverlay                 Annex/GitOverlay.hs:(107,1)-(124,31)                     7.7    0.1
+	cmdname                        Types.Command                    Types/Command.hs:80:11-17                                7.7    0.1
+	stop                           Utility.CoProcess                Utility/CoProcess.hs:(58,1)-(63,46)                      7.7    0.2
+	relPathCwdToFile               Utility.Path.AbsRel              Utility/Path/AbsRel.hs:(76,1)-(86,36)                    7.7    0.5
+	getEnv                         Utility.Env                      Utility/Env.hs:32:1-18                                   7.7    0.4
+
+Note that the profiler saw a 0.01 second runtime, but actual runtime is more
+like 0.04 seconds (actually 0.08 with this profiling build, but non-profiling
+builds are faster). The rest of the runtime must be linking and RTS startup?
+
+It would be good to get a similar profile on windows for comparison.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_8_4ee757b45706816c3296dd4b29f05fbf._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_8_4ee757b45706816c3296dd4b29f05fbf._comment
new file mode 100644
index 0000000000..9fed65e9ae
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_8_4ee757b45706816c3296dd4b29f05fbf._comment
@@ -0,0 +1,69 @@
+[[!comment format=mdwn
+ username="adina.wagner@2a4cac6443aada2bd2a329b8a33f4a7b87cc8eff"
+ nickname="adina.wagner"
+ avatar="http://cdn.libravatar.org/avatar/80b124ad61d6008fa0f6f0b4b0f7c2ef"
+ subject="comment 8"
+ date="2021-09-28T12:53:13Z"
+ content="""
+> It would be good to get a similar profile on windows for comparison.
+
+I tried to create a profile*. Here is what I am seeing on a Windows 10 system, version 2004, OS build 19041.1237:
+
+```
+		Tue Sep 28 14:48 2021 Time and Allocation Profiling Report  (Final)
+
+	   git-annex.exe +RTS -p -RTS smudge --clean x
+
+	total time  =        0.00 secs   (1 ticks @ 1000 us, 1 processor)
+	total alloc =     956,208 bytes  (excludes profiling overheads)
+
+COST CENTRE               MODULE                               SRC                                                         %time %alloc
+
+CAF                       GHC.IO.Handle.FD                     <entire-module>                                             100.0    5.5
+MAIN                      MAIN                                 <built-in>                                                    0.0    1.1
+createProcess             Utility.Process                      Utility\Process.hs:(177,1)-(180,16)                           0.0    8.5
+relPathCwdToFile          Utility.Path.AbsRel                  Utility\Path\AbsRel.hs:(76,1)-(86,36)                         0.0    2.0
+absPath                   Utility.Path.AbsRel                  Utility\Path\AbsRel.hs:(55,1)-(66,45)                         0.0    2.0
+checkForRepo.gitSignature Git.Construct                        Git\Construct.hs:234:9-56                                     0.0    2.1
+parse.sep                 Git.Config                           Git\Config.hs:(163,9)-(165,38)                                0.0    2.8
+needsGitLinkFixup         Annex.Fixup                          Annex\Fixup.hs:(149,1)-(155,34)                               0.0    3.0
+clean                     Command.Smudge                       Command\Smudge.hs:(90,1)-(173,60)                             0.0    3.6
+parseCmd.subcmds          CmdLine                              CmdLine.hs:109:9-64                                           0.0    3.0
+parseCmd.mkcommand        CmdLine                              CmdLine.hs:(110,9)-(113,31)                                   0.0    1.1
+cmds                      CmdLine.GitAnnex                     CmdLine\GitAnnex.hs:(132,1)-(244,9)                           0.0    1.3
+addGitAnnexGlobalOptions  CmdLine.GitAnnex                     CmdLine\GitAnnex.hs:247:1-97                                  0.0    1.6
+splitPath.f.(...)         System.FilePath.Windows.ByteString   System\FilePath\Windows\..\Internal.hs:862:17-49              0.0    1.4
+splitPath.f.(...)         System.FilePath.Windows.ByteString   System\FilePath\Windows\..\Internal.hs:861:17-49              0.0    1.8
+splitPath.f               System.FilePath.Windows.ByteString   System\FilePath\Windows\..\Internal.hs:(857,9)-(862,49)       0.0    1.7
+<>                        Options.Applicative.Builder.Internal src\Options\Applicative\Builder\Internal.hs:(96,3)-(97,47)    0.0    1.7
+stepParser                Options.Applicative.Common           src\Options\Applicative\Common.hs:(187,1)-(194,35)            0.0    3.1
+searchParser              Options.Applicative.Common           src\Options\Applicative\Common.hs:(136,1)-(151,40)            0.0    1.7
+pure                      Options.Applicative.Internal         src\Options\Applicative\Internal.hs:55:3-21                   0.0    1.1
+mplus                     Options.Applicative.Internal         src\Options\Applicative\Internal.hs:(215,3)-(219,52)          0.0    1.0
+>>=                       Options.Applicative.Internal         src\Options\Applicative\Internal.hs:64:3-50                   0.0    1.3
+>>=                       Options.Applicative.Internal         src\Options\Applicative\Internal.hs:(200,3)-(204,54)          0.0    1.2
+encodeChar.go             Codec.Binary.UTF8.String             Codec\Binary\UTF8\String.hs:(52,3)-(67,25)                    0.0    1.0
+encodeChar                Codec.Binary.UTF8.String             Codec\Binary\UTF8\String.hs:(50,1)-(67,25)                    0.0    2.7
+encode                    Codec.Binary.UTF8.String             Codec\Binary\UTF8\String.hs:72:1-29                           0.0    2.3
+unconsB                   Codec.Binary.UTF8.Generic            Codec\Binary\UTF8\Generic.hs:297:1-18                         0.0    1.5
+foldr                     Data.ByteString.UTF8                 Data\ByteString\UTF8.hs:(171,1)-(173,40)                      0.0    1.1
+catch                     Control.Monad.Catch                  src\Control\Monad\Catch.hs:333:3-32                           0.0    1.5
+
+
+                                                                                                                                               
+
+[...]
+```
+
+
+
+
+
+*I'm not familiar with Haskell, and don't 100% understand what you ran, so I'll detail how I created it in case I did something obvious wrong.
+I build git-annex at state b9aa2ce8d1 from source using stack Version 2.7.3, Git revision 7927a3aec32e2b2e5e4fb5be76d0d50eddcc197f x86_64 hpack-0.34.4. It used ghc 8.8.4.
+I ran ``stack build --profile`` to build the executable.
+
+I created an empty git/git annex repository - no files committed to Git or git-annex at all. In this repository, I ran ``git-annex.exe +RTS -p -RTS smudge --clean x`` (as shown in your profile -- as this command didn't return, I just killed it after a few seconds). The profile above is the first section of the resulting ``.prof`` file. 
+
+Hope this helps and was the correct procedure. Let me know if I should repeat any step any differently. Thanks! :)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_8_b46545c78628379dd50d306c87550b9d._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_8_b46545c78628379dd50d306c87550b9d._comment
new file mode 100644
index 0000000000..d69bb45762
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_8_b46545c78628379dd50d306c87550b9d._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2021-09-28T16:22:36Z"
+ content="""
+Corresponding time profile on Windows. This was run on a github CI
+instance, so I don't know if the CPU was busy with other tasks.
+
+		Mon Sep 27 22:45 2021 Time and Allocation Profiling Report  (Final)
+	
+		   git-annex.exe +RTS -p -RTS smudge --clean x
+	
+		total time  =        0.02 secs   (22 ticks @ 1000 us, 1 processor)
+		total alloc =   6,753,624 bytes  (excludes profiling overheads)
+	
+	COST CENTRE                    MODULE                     SRC                                                 %time %alloc
+	
+	createProcess                  Utility.Process            Utility\Process.hs:(177,1)-(180,16)                  50.0   18.7
+	openLock.\                     Utility.LockFile.Windows   Utility\LockFile\Windows.hs:(64,17)-(65,76)           4.5    0.0
+	toInodeCache'                  Utility.InodeCache         Utility\InodeCache.hs:(196,1)-(206,34)                4.5    3.0
+	checkSentinalFile.loadoldcache Utility.InodeCache         Utility\InodeCache.hs:(260,9)-(261,83)                4.5    0.3
+	adjustGitEnv                   Git.Env                    Git\Env.hs:(18,1)-(22,7)                              4.5   41.2
+	pipeReadStrict'.go             Git.Command                Git\Command.hs:(80,9)-(85,37)                         4.5    0.1
+	mergeGitConfig                 Types.GitConfig            Types\GitConfig.hs:(284,1)-(299,54)                   4.5    0.0
+	fixupRepo                      Annex.Fixup                Annex\Fixup.hs:(37,1)-(42,31)                         4.5    0.0
+	noCommit                       Command                    Command.hs:56:1-37                                    4.5    0.0
+	getFileSize                    System.PosixCompat.Files   src\System\PosixCompat\Files.hsc:(358,1)-(359,76)     4.5    1.5
+	searchParser                   Options.Applicative.Common src\Options\Applicative\Common.hs:(136,1)-(151,40)    4.5    0.2
+	catch                          Control.Monad.Catch        src\Control\Monad\Catch.hs:333:3-32                   4.5    0.2
+	getFileSize                    Utility.FileSize           Utility\FileSize.hs:37:1-80                           0.0    1.5
+	getFileType                    System.PosixCompat.Files   src\System\PosixCompat\Files.hsc:(350,1)-(355,62)     0.0    2.9
+	getFileStatus                  System.PosixCompat.Files   src\System\PosixCompat\Files.hsc:(312,1)-(337,24)     0.0    6.0
+	unconsB                        Codec.Binary.UTF8.Generic  Codec\Binary\UTF8\Generic.hs:297:1-18                 0.0    1.2
+
+(Whole profile at <https://tmp.joeyh.name/windows-profile>)
+
+What stands out is that createProcess is twice as expensive as linux, and
+fully half the runtime is apparently spent just forking a few processes.
+
+Here are the git processes started and percent of time to start them,
+from the more detailed profiling:
+
+	git config	9%
+	git cat-file	9%
+	git check-attr	4.5%
+	git diff (reconcileStaged)	9%
+	git show-ref (reconcileStaged)	9%
+	git write-tree (reconcileStaged)	9%
+
+(The reconcileStaged stuff only happened because `git init`
+didn't do it -- I forgot to put git-annex in the path the way I ran it
+on the CI builder, and so init didn't do everything it usually would.
+A second run with that fixed had a createProcess percent reduced to 30%,
+though still at around2 0.2s total runtime.)
+
+This is not super slow on the Windows CI, it's competative with Linux,
+though my Linux laptop probably has a slower CPU (1.5ghz).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_9_409a95cb01a4b26d46d7aaff042026a0._comment b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_9_409a95cb01a4b26d46d7aaff042026a0._comment
new file mode 100644
index 0000000000..51d56994ce
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows__58___substantial_per-file_cost_for___96__add__96__/comment_9_409a95cb01a4b26d46d7aaff042026a0._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-09-28T17:09:21Z"
+ content="""
+So most of the time is spent in createProcess. Forking is not slow
+(on linux anyway) so why are 4 createProcess 23% of runtime on linux?
+
+Here is a strace --relative-timestamps on linux, showing a single createProcess
+call, for reading `git config`.
+
+     0.000196 pipe([11, 12])            = 0
+     0.000134 pipe([13, 14])            = 0
+     0.000067 rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
+     0.000074 vfork()                   = 1412528
+     0.000552 close(12)                 = 0
+     0.000058 fcntl(11, F_SETFD, FD_CLOEXEC) = 0
+     0.000095 close(14)                 = 0
+     0.000050 fcntl(13, F_SETFD, FD_CLOEXEC) = 0
+     0.000047 read(13, "", 4)           = 0
+     0.000050 close(13)                 = 0
+     0.000061 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
+     0.000062 futex(0x98336c8, FUTEX_WAKE_PRIVATE, 1) = 1
+     0.000061 futex(0x9833660, FUTEX_WAKE_PRIVATE, 1) = 1
+     0.000066 fcntl(11, F_GETFL)        = 0 (flags O_RDONLY)
+     0.000047 fcntl(11, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
+     0.000073 ioctl(11, TCGETS, 0x7ffc091b0d80) = -1 ENOTTY (Inappropriate ioctl for device)
+
+Total runtime of createProcess above is 1.69 ms. 
+And from the profile on windows, it's taking around 1.7 ms per createProcess.
+
+I'd say that at least 1.32 ms of that is necessary, leaving out the `futex`
+and `rt_sigprocmask` that are probably GHC runtime stuff, and the `ioctl`
+and `read` and `fcntl F_GETFL` which seem unnecessary.
+If those were optimised out, the total `git-annex smudge --clean`
+runtime would speed up by only 10% or so.
+
+Feels like I've reached the end of profiling. Most of the time is being spent
+starting git processes, and it can't be sped up significantly without
+starting fewer git processes.
+
+(I do wish that `git check-attr` could be removed, but it's needed for the
+annex.largefiles .gitattributes support.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/Windows_build_failing_as_of_commit_cb7bb3e.mdwn b/doc/projects/datalad/bugs-done/Windows_build_failing_as_of_commit_cb7bb3e.mdwn
new file mode 100644
index 0000000000..3352bb8654
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/Windows_build_failing_as_of_commit_cb7bb3e.mdwn
@@ -0,0 +1,6 @@
+As of commit cb7bb3e, trying to build git-annex on Windows fails with a syntax error, which (once fixed) is replaced by a type error and an undefined name error.  All of these can be fixed with [this patch](https://raw.githubusercontent.com/datalad/git-annex/32c2244753ae217a081109e1694bc83fe7a2da21/patches/20210211-cb7bb3e4b-windows-fix.patch).
+
+[[!meta author=jwodder]]
+[[!tag projects/datalad]]
+
+> applied, thanks [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount.mdwn b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount.mdwn
new file mode 100644
index 0000000000..c5c982a2a8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount.mdwn
@@ -0,0 +1,138 @@
+### Please describe the problem.
+
+edit: I said "lustre" but it is isilon which is under.  My wrong/outdated/mixed up knowledge of the system
+
+Finally we got what should be a normal "POSIX" NFS mount (no ACL) on a local HPC.  I immediately ventured to test git-annex (and datalad) on that file system. git annex 8.20210803-g99bb214 and git 2.30.2 both coming from conda.
+
+with basic operations -- it felt like it works ok.
+but then when I ran tests while pointing TMPDIR to this location, e.g. `TMPDIR=$PWD git annex test 2>&1 | tee git-annex-noretry+pidlock1-1.log` - `git-annex` is far from a happy camper.
+
+Note: `tmp` path below is actually a `/dartfs/rc/lab/D/DBIC/DBIC/archive/tmp`
+
+<details>
+<summary>Not sure if related or not but git-annex upon init seems to not detect the need for pidlock </summary> 
+
+```shell
+[d31548v@discovery7 tmp]$ ( PS4='[$(date)] > '; set -x; mkdir test; cd test; git init; git annex --debug init; cat .git/config; )
+[Wed Aug 11 16:14:03 EDT 2021] > mkdir test
+[Wed Aug 11 16:14:03 EDT 2021] > cd test
+[Wed Aug 11 16:14:04 EDT 2021] > git init
+Initialized empty Git repository in /dartfs/rc/lab/D/DBIC/DBIC/archive/tmp/test/.git/
+[Wed Aug 11 16:14:04 EDT 2021] > git annex --debug init
+init  [2021-08-11 16:14:04.936362] (Utility.Process) process [10184] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-08-11 16:14:04.982236] (Utility.Process) process [10184] done ExitFailure 1
+[2021-08-11 16:14:04.984294] (Utility.Process) process [10185] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--verify","-q","refs/remotes/origin/git-annex"]
+[2021-08-11 16:14:05.019706] (Utility.Process) process [10185] done ExitFailure 1
+[2021-08-11 16:14:05.029391] (Utility.Process) process [10187] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","write-tree"]
+[2021-08-11 16:14:05.118706] (Utility.Process) process [10187] done ExitSuccess
+[2021-08-11 16:14:05.121008] (Utility.Process) process [10189] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","commit-tree","4b825dc642cb6eb9a060e54bf8d69288fbee4904","--no-gpg-sign"]
+[2021-08-11 16:14:05.197601] (Utility.Process) process [10189] done ExitSuccess
+[2021-08-11 16:14:05.218776] (Utility.Process) process [10190] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-ref","refs/heads/git-annex","4570bef1d852f540b8bb1bcf7aa778cf48d8743a"]
+[2021-08-11 16:14:05.342053] (Utility.Process) process [10190] done ExitSuccess
+[2021-08-11 16:14:05.380591] (Utility.Process) process [10191] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","config","annex.uuid","4f1069df-9aa9-4e72-92dc-b1f5ac6946d5"]
+[2021-08-11 16:14:05.428772] (Utility.Process) process [10191] done ExitSuccess
+[2021-08-11 16:14:05.432081] (Utility.Process) process [10193] read: git ["config","--null","--list"]
+[2021-08-11 16:14:05.502382] (Utility.Process) process [10193] done ExitSuccess
+[2021-08-11 16:14:05.635239] (Utility.Process) process [10202] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2021-08-11 16:14:05.698023] (Utility.Process) process [10202] done ExitSuccess
+[2021-08-11 16:14:05.699988] (Utility.Process) process [10203] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-08-11 16:14:05.734066] (Utility.Process) process [10203] done ExitSuccess
+[2021-08-11 16:14:05.741208] (Utility.Process) process [10204] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..4570bef1d852f540b8bb1bcf7aa778cf48d8743a","--pretty=%H","-n1"]
+[2021-08-11 16:14:05.794383] (Utility.Process) process [10204] done ExitSuccess
+[2021-08-11 16:14:05.827348] (Utility.Process) process [10207] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-08-11 16:14:05.832331] (Utility.Process) process [10208] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-08-11 16:14:05.912843] (Utility.Process) process [10212] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","config","annex.version","8"]
+[2021-08-11 16:14:06.014334] (Utility.Process) process [10212] done ExitSuccess
+[2021-08-11 16:14:06.017332] (Utility.Process) process [10213] read: git ["config","--null","--list"]
+[2021-08-11 16:14:06.09542] (Utility.Process) process [10213] done ExitSuccess
+[2021-08-11 16:14:06.097328] (Utility.Process) process [10215] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","status","--porcelain"]
+[2021-08-11 16:14:06.199386] (Utility.Process) process [10215] done ExitSuccess
+[2021-08-11 16:14:06.201524] (Utility.Process) process [10217] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","config","filter.annex.smudge","git-annex smudge -- %f"]
+[2021-08-11 16:14:06.259174] (Utility.Process) process [10217] done ExitSuccess
+[2021-08-11 16:14:06.262019] (Utility.Process) process [10218] read: git ["config","--null","--list"]
+[2021-08-11 16:14:06.332769] (Utility.Process) process [10218] done ExitSuccess
+[2021-08-11 16:14:06.334786] (Utility.Process) process [10221] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","config","filter.annex.clean","git-annex smudge --clean -- %f"]
+[2021-08-11 16:14:06.396427] (Utility.Process) process [10221] done ExitSuccess
+[2021-08-11 16:14:06.39987] (Utility.Process) process [10224] read: git ["config","--null","--list"]
+[2021-08-11 16:14:06.454542] (Utility.Process) process [10224] done ExitSuccess
+[2021-08-11 16:14:06.871684] (Utility.Process) process [10228] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2021-08-11 16:14:06.923312] (Utility.Process) process [10228] done ExitSuccess
+[2021-08-11 16:14:06.975588] (Utility.Process) process [10231] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","refs/heads/master"]
+[2021-08-11 16:14:07.015031] (Utility.Process) process [10231] done ExitFailure 1
+[2021-08-11 16:14:07.017599] (Utility.Process) process [10233] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2021-08-11 16:14:07.056731] (Utility.Process) process [10233] done ExitSuccess
+[2021-08-11 16:14:07.059379] (Utility.Process) process [10234] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/master"]
+[2021-08-11 16:14:07.100443] (Utility.Process) process [10234] done ExitFailure 1
+[2021-08-11 16:14:07.102482] (Utility.Process) process [10236] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","checkout","-q","-B","master"]
+[2021-08-11 16:14:07.157509] (Utility.Process) process [10236] done ExitSuccess
+[2021-08-11 16:14:07.208637] (Utility.Process) process [10238] read: uname ["-n"]
+[2021-08-11 16:14:07.209729] (Utility.Process) process [10238] done ExitSuccess
+[2021-08-11 16:14:07.292876] (Annex.Branch) read uuid.log
+[2021-08-11 16:14:07.392149] (Annex.Branch) set uuid.log
+[2021-08-11 16:14:07.393272] (Annex.Branch) read remote.log
+ok
+[2021-08-11 16:14:07.536729] (Utility.Process) process [10244] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","hash-object","-w","--stdin-paths","--no-filters"]
+[2021-08-11 16:14:07.54018] (Utility.Process) process [10245] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index-info"]
+[2021-08-11 16:14:07.760348] (Utility.Process) process [10245] done ExitSuccess
+[2021-08-11 16:14:07.76284] (Utility.Process) process [10246] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-08-11 16:14:07.800127] (Utility.Process) process [10246] done ExitSuccess
+(recording state in git...)
+[2021-08-11 16:14:07.805187] (Utility.Process) process [10247] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","write-tree"]
+[2021-08-11 16:14:07.948696] (Utility.Process) process [10247] done ExitSuccess
+[2021-08-11 16:14:07.950889] (Utility.Process) process [10248] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","commit-tree","2ebb8bbc83b47982a995f66975d4265986f005b8","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2021-08-11 16:14:08.022394] (Utility.Process) process [10248] done ExitSuccess
+[2021-08-11 16:14:08.024889] (Utility.Process) process [10252] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-ref","refs/heads/git-annex","83fb8ae08e2e0ea030f3ce75aa840d27838859b6"]
+[2021-08-11 16:14:08.172372] (Utility.Process) process [10252] done ExitSuccess
+[2021-08-11 16:14:08.349523] (Utility.Process) process [10207] done ExitSuccess
+[2021-08-11 16:14:08.35006] (Utility.Process) process [10208] done ExitSuccess
+[2021-08-11 16:14:08.352912] (Utility.Process) process [10244] done ExitSuccess
+[Wed Aug 11 16:14:08 EDT 2021] > cat .git/config
+[core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = false
+        logallrefupdates = true
+[annex]
+        uuid = 4f1069df-9aa9-4e72-92dc-b1f5ac6946d5
+        version = 8
+[filter "annex"]
+        smudge = git-annex smudge -- %f
+        clean = git-annex smudge --clean -- %f
+
+```
+</details>
+
+
+so I did set it to `1` globally (in `~/.gitconfig`).  Only later discovered that it should be `true` not `1` but it nohow seems affected git-annex operation in the tests.
+
+Full log from tests run is available at [http://www.onerussian.com/tmp/git-annex-noretry+pidlock1-1.log](http://www.onerussian.com/tmp/git-annex-noretry+pidlock1-1.log)
+
+and a common pattern something like
+
+```
+        fsck downloaded object:                          OK (0.02s)
+        retrieveKeyFile resume from 0:                   FAIL
+          Exception: .git/annex/tmp/SHA256E-s1048577--2c30628691d7a7e5b16237fd74efb4bf365db003e19e6fbe78d96c15396819e5.this-is-a-test-key: openFile: permission denied (Permission denied)
+        fsck downloaded object:                          OK (0.02s)
+        retrieveKeyFile resume from 33%:                 FAIL
+          Exception: .git/annex/objects/1X/90/SHA256E-s1048577--2c30628691d7a7e5b16237fd74efb4bf365db003e19e6fbe78d96c15396819e5.this-is-a-test-key/SHA256E-s1048577--2c30628691d7a7e5b16237fd74efb4bf365db003e19e6fbe78d96c15396819e5.this-is-a-test-key: openBinaryFile: does not exist (No such file or directory)
+        fsck downloaded object:                          OK (0.03s)
+        retrieveKeyFile resume from end:                 cp: cannot stat '.git/annex/objects/1X/90/SHA256E-s1048577--2c30628691d7a7e5b16237fd74efb4bf365db003e19e6fbe78d96c15396819e5.this-is-a-test-key/SHA256E-s1048577--2c30628691d7a7e5b16237fd74efb4bf365db003e19e6fbe78d96c15396819e5.this-is-a-test-key': No such file or directory
+FAIL (0.28s)
+          ./Command/TestRemote.hs:292:
+          failed
+```
+
+I thought that may be it is due to running into the path limit, but I could touch a much (twice) longer path no problem and longest filename of 257 characters can be created.
+
+details of the mount with minimal sensoring with XXXs:
+
+```
+/ifs/rc/dartfs/rc on /dartfs/rc type nfs4 (rw,nosuid,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5,clientaddr=XXX.XXX.XXX.XXX,local_lock=none,addr=10.1.16.105)
+```
+
+any ideas Joey?  or how to troubleshoot on this beast further?
+
+[[!meta title="357 out of 984 tests fail on NFS isilon mount"]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_10_61c1fe6f14a30082a325c0efea9632f6._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_10_61c1fe6f14a30082a325c0efea9632f6._comment
new file mode 100644
index 0000000000..7664f850aa
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_10_61c1fe6f14a30082a325c0efea9632f6._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 10"
+ date="2021-08-27T01:38:54Z"
+ content="""
+ha -- I have mentioned that there is `--no-preserve` so I have tried it with -a to exclude xattr and it seems to do the trick as well
+
+```
+(datalad) [d31548v@discovery7 _test_]$ rm -f bar baz
+(datalad) [d31548v@discovery7 _test_]$ echo bar > bar
+(datalad) [d31548v@discovery7 _test_]$ chmod 444 bar
+(datalad) [d31548v@discovery7 _test_]$ cp --reflink=auto -a --no-preserve=xattr bar baz
+(datalad) [d31548v@discovery7 _test_]$ chmod 644 baz
+(datalad) [d31548v@discovery7 _test_]$ ls -l baz
+-rw-r--r-- 1 d31548v rc-DBIC-bids 4 Aug 26 21:36 baz
+```
+
+so may be just worth explicitly excluding xattr instead of explicitly including some of the others? ;)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_11_541e257ea04d6a7647a337998d79232c._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_11_541e257ea04d6a7647a337998d79232c._comment
new file mode 100644
index 0000000000..92e2d5d715
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_11_541e257ea04d6a7647a337998d79232c._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2021-08-27T16:41:45Z"
+ content="""
+I've made the change to use that option. I think this should clear the test
+suite.
+
+I see that Isilon is a NAS, so some proprietary and broken NFS server
+apparently. Kind of explains why cp -a would do this, because I found
+threads about cp -a preserving NFS xattrs, and people wanted it to,
+presumably for other reasons on less broken NFS servers.
+
+This does raise the question of what might happen if someone copies
+a file themselves with cp -a on this NFS and then git-annex adds the copy.
+Probably git-annex would then be unable to remove the write bit
+from the annex object file. 
+
+I also worried about ACLS, but it seems like ACLs do not have this
+problem, because chmod a-w causes the write ACL that was set to be
+effectively unset:
+
+	joey@darkstar:~>chmod -w foo
+	joey@darkstar:~>setfacl -m g:nogroup:rw foo
+	joey@darkstar:~>ls -l foo
+	-r--rw-r--+ 1 joey joey 0 Aug 27 12:53 foo
+	nobody@darkstar:/home/joey$ echo test >> foo
+	joey@darkstar:~>chmod a-w foo
+	joey@darkstar:~>ls -l foo
+	-r--rw-r--+ 1 joey joey 0 Aug 27 12:53 foo
+	nobody@darkstar:/home/joey$ echo test >> foo
+	bash: foo: Permission denied
+	joey@darkstar:~>getfacl foo
+	# file: foo
+	# owner: joey
+	# group: joey
+	user::r--
+	group::r--
+	group:nogroup:rw-		#effective:r--
+	mask::r--
+	other::r--
+
+I've verified that git-annex add also clears the write ACL.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_12_80b15bc4e0c8c9ed4680da9408c1d559._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_12_80b15bc4e0c8c9ed4680da9408c1d559._comment
new file mode 100644
index 0000000000..0136b0a862
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_12_80b15bc4e0c8c9ed4680da9408c1d559._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2021-08-27T17:13:54Z"
+ content="""
+I've also made git-annex add check, after removing write bits,
+if the file still has write bits set. It will refuse to add a file
+when it can't lock it down.
+
+That should avoid the NFS xattr problem in a situation where
+cp -a was used to make a copy that then gets added to the annex.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_13_8f305fa196210899d2215324849a8fab._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_13_8f305fa196210899d2215324849a8fab._comment
new file mode 100644
index 0000000000..722d3d6f8f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_13_8f305fa196210899d2215324849a8fab._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 13"
+ date="2021-08-27T18:46:39Z"
+ content="""
+Great, thank you, I will test after the next daily build. What would be the easiest way to establish such an xattr enabled NFS setup, so we could tune up [our test on NFS scenarios](https://github.com/datalad/git-annex/blob/master/.github/workflows/build-ubuntu.yaml#L221) to catch any possible future regression?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_14_66d72d1d214124eaa57681df21b9b121._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_14_66d72d1d214124eaa57681df21b9b121._comment
new file mode 100644
index 0000000000..4113a8574d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_14_66d72d1d214124eaa57681df21b9b121._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2021-08-30T15:59:29Z"
+ content="""
+It seems likely to me that this NFS server is just broken. Why would a
+well-designed NFS server behave this way, rather than letting a chmod
+override the xattr that was set earlier?
+
+I considered filing a bug report on coreutils or something about cp
+preserving the NFS xattr leading to this problem, but since it seems likely
+to be the NFS server on the NAS that is at fault, didn't think that would
+be productive. 
+
+If you did manage to reproduce that behavior with a regular
+linux NFS server, it seems like it would be a grounds for a bug on some
+part of linux..
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_15_6354d1e144830bea5a0d7872f698ccc0._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_15_6354d1e144830bea5a0d7872f698ccc0._comment
new file mode 100644
index 0000000000..e7e235c582
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_15_6354d1e144830bea5a0d7872f698ccc0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="just an update on my testing"
+ date="2021-08-30T22:17:53Z"
+ content="""
+FWIW, I've tested a debianstadalone build of `8.20210803+git153-g63c2cfd47-1~ndall+1` on that system, and besides 3 fails due to no `--kill` in elderly system wide gpgconf (apparently debian bundle does not come with one) -- it is all clean! (although took nearly a full work day to complete on that filesystem: `3 out of 984 tests failed (18157.38s)`)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_1_945d45b37b0548deacddab19568dd5b3._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_1_945d45b37b0548deacddab19568dd5b3._comment
new file mode 100644
index 0000000000..978f89790c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_1_945d45b37b0548deacddab19568dd5b3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="note on `sec=` on the mount"
+ date="2021-08-16T21:38:13Z"
+ content="""
+Just now, while comparing with operation on another mount point (on NFS v3, not 4 though), noted that this mount point is `sec=krb5` (and NFS 3 one is `sec=sys`)... so might be what is contributing here
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_2_4e89c558748c370e8bbb1ef50f4cdcf7._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_2_4e89c558748c370e8bbb1ef50f4cdcf7._comment
new file mode 100644
index 0000000000..6e432ab5f6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_2_4e89c558748c370e8bbb1ef50f4cdcf7._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-08-24T16:01:30Z"
+ content="""
+
+The "retrieveKeyFile resume from 0%" test
+starts by writing an empty file with default permissions.
+It then does the download storing to that file.
+
+The permission denied is happening when trying to open that file
+later, to write to it. So this seems like a umask or some other
+kind of permissions problem. Maybe filesystem related in some way,
+if the filesystem is somehow not honoring permissions, but that would
+not be my first or second guess.
+
+The other 2 failures shown do chain on from that
+initial failure, since that test does some things that the
+later tests depend on. Looking through the log, there are several other
+test failures that also seem due to permissions, that all look like this,
+or probably chain from this:
+
+	  add:  FAIL (4.08s)
+	    ./Test/Framework.hs:324:
+	    unable to modify sha1foo
+
+And that error message happens when it's checking that the file
+permissions include the write bit.
+
+So, your next step should be something like:
+
+	umask
+	touch foo
+	ls -l foo
+	echo foo >> foo
+
+I tried with `umask 0222` (new files lack any write bit) but it failed a lot
+earlier, while setting up the test suite. Which seems ok itself given how
+restricted and weird that umask is. If the test suite overrode the umask, it
+would not notice if some actual reasonable umask caused problems. But I'm
+getting ahead of confirmation that it is a umask problem.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_3_1c0abfb39eafb73527c99dd56b41c0bd._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_3_1c0abfb39eafb73527c99dd56b41c0bd._comment
new file mode 100644
index 0000000000..7b867138a7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_3_1c0abfb39eafb73527c99dd56b41c0bd._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2021-08-24T18:06:10Z"
+ content="""
+```
+[d31548v@discovery7 _test_]$ umask 
+0022
+[d31548v@discovery7 _test_]$ touch foo
+[d31548v@discovery7 _test_]$ ls -l foo
+-rw-r--r-- 1 d31548v rc-DBIC-bids 0 Aug 24 13:53 foo
+[d31548v@discovery7 _test_]$ echo foo >> foo
+
+```
+
+I blindly think it is somehow due to that `sec=krb5` nfs mount option. didn't try to reproduce the setup \"locally\" (would need all the krb config I guess) to see if I am right on that.
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_4_ff06b532b0ec6edc17ae26a7a80233af._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_4_ff06b532b0ec6edc17ae26a7a80233af._comment
new file mode 100644
index 0000000000..4a0ea981a7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_4_ff06b532b0ec6edc17ae26a7a80233af._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-08-24T18:51:41Z"
+ content="""
+Somehow the write bit is not being set. Since the umask is ok, the next
+most likely thing seems to be NFS either not setting it, or temporarily
+forgetting it's set, or the file somehow being created owned by a different
+user.
+
+Could run: `git-annex test --keep-failures` and then when it gets
+to one of the "unable to modify foo" failures, it will print out the path
+to the repository that it failed in, and you can "ls -l" the path,
+which should include the "foo" file.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_5_86eed28bf04fd293851afcbea5312271._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_5_86eed28bf04fd293851afcbea5312271._comment
new file mode 100644
index 0000000000..b9c2de2c6d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_5_86eed28bf04fd293851afcbea5312271._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2021-08-25T22:05:06Z"
+ content="""
+```
+[d31548v@discovery7 _test_]$ grep -A1 -m1 'unable to modify foo' git-annex-8.20210803-g99bb214-20210925-1.log
+      unable to modify foo
+    export_import_subdir:                                 ** Preserving repo for failure analysis in .t/tmprepo5
+
+[d31548v@discovery7 _test_]$ ls -la .t/tmprepo5
+total 239
+drwxr-xr-x   4 d31548v rc-DBIC-bids  112 Aug 25 10:59 .
+drwxr-xr-x 205 d31548v rc-DBIC-bids 5525 Aug 25 11:31 ..
+-rw-r--r--   1 d31548v rc-DBIC-bids   19 Aug 25 10:58 bar.c
+drwxr-xr-x   2 d31548v rc-DBIC-bids    0 Aug 25 10:59 dir
+-r--r--r--   1 d31548v rc-DBIC-bids   20 Aug 25 10:58 foo
+drwxr-xr-x   8 d31548v rc-DBIC-bids  296 Aug 25 10:59 .git
+-r--r--r--   1 d31548v rc-DBIC-bids   25 Aug 25 10:58 sha1foo
+```
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_6_71f5f1704b97cf4e809a55a71e9da3eb._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_6_71f5f1704b97cf4e809a55a71e9da3eb._comment
new file mode 100644
index 0000000000..41caca1b08
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_6_71f5f1704b97cf4e809a55a71e9da3eb._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-08-26T15:06:26Z"
+ content="""
+So confirmed to be actual missing write bits.
+
+I think that the next step is going to be to dig through a `strace -f -s 1024`, 
+of the "resume from 0" file that has the permission denied problem, 
+and of the ".t/tmprepo5/foo" file that is somehow not writable.
+
+Then I can compare with a strace where it does not fail, to see
+if it's doing something different.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_7_78258166fed7a555e59ed2b78143fad1._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_7_78258166fed7a555e59ed2b78143fad1._comment
new file mode 100644
index 0000000000..0616099da9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_7_78258166fed7a555e59ed2b78143fad1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2021-08-26T16:49:56Z"
+ content="""
+details on what I have ran and logs went via email in response to your last email response ;)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_8_1219295230f196c00744058ed3441a98._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_8_1219295230f196c00744058ed3441a98._comment
new file mode 100644
index 0000000000..2b49ea9651
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_8_1219295230f196c00744058ed3441a98._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2021-08-26T20:18:05Z"
+ content="""
+From the strace of `git-annex test -p export_import_subdir`,
+I have found what I think is the smoking gun:
+
+	21179 stat(".git/annex/othertmp/foo.0/foo", {st_mode=S_IFREG|0444, st_size=20, ...}) = 0
+	21179 chmod(".git/annex/othertmp/foo.0/foo", 0100644) = 0
+	21179 stat(".git/annex/othertmp/foo.0/foo", {st_mode=S_IFREG|0444, st_size=20, ...}) = 0
+	21179 rename(".git/annex/othertmp/foo.0/foo", "./foo") = 0
+
+This seems like proof that NFS is losing the file permissions. chmod 644
+followed immediately by stat showing the mode is still 444, with nothing
+happening in between according to strace.
+
+The full set of operations on that temp file is:
+
+	21179 unlink(".git/annex/othertmp/foo.0/foo") = -1 ENOENT (No such file or directory)
+	21179 vfork( <unfinished ...>
+	21217 execve("/dartfs-hpc/admin/opt/oldopt/git-annex/8.20200522/bin/cp", ["cp", "--reflink=auto", "-a", ".git/annex/objects/Kj/0x/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", ".git/annex/othertmp/foo.0/foo"], 0x7fff09e296f8 /* 77 vars */ <unfinished ...>
+	21179 <... vfork resumed>)              = 21217
+	21217 stat(".git/annex/othertmp/foo.0/foo", 0x7ffc13f0d430) = -1 ENOENT (No such file or directory)
+	21217 newfstatat(AT_FDCWD, ".git/annex/othertmp/foo.0/foo", 0x7ffc13f0d1b0, 0) = -1 ENOENT (No such file or directory)
+	21217 openat(AT_FDCWD, ".git/annex/othertmp/foo.0/foo", O_WRONLY|O_CREAT|O_EXCL, 0400) = 4
+	21217 fstat(4, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
+	21217 ioctl(4, BTRFS_IOC_CLONE or FICLONE, 3) = -1 EOPNOTSUPP (Operation not supported)
+	21217 write(4, "annexed file content", 20) = 20
+	21217 utimensat(4, NULL, [{tv_sec=1629996169, tv_nsec=810295000} /* 2021-08-26T12:42:49.810295000-0400 */, {tv_sec=1629996169, tv_nsec=810295000} /* 2021-08-26T12:42:49.810295000-0400 */], 0 <unfinished ...>
+	21217 <... utimensat resumed>)          = 0
+	21217 fchmod(4, 0600)                   = 0
+	21217 fsetxattr(4, "system.nfs4_acl", "\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\211\0\0\0\6OWNER@\0\0\0\0\0\0\0\0\0\0\0\22\0\211\0\0\0\6GROUP@\0\0\0\0\0\0\0\0\0\0\0\22\0\211\0\0\0\tEVERYONE@\0\0", 80, 0) = 0
+	21217 fchmod(4, 0400)                   = 0
+	21217 fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\4\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EOPNOTSUPP (Operation not supported)
+	21217 fchmod(4, 0100444)                = 0
+	21217 close(4)                          = 0
+	21179 stat(".git/annex/othertmp/foo.0/foo",  <unfinished ...>
+	21179 <... stat resumed>{st_mode=S_IFREG|0444, st_size=20, ...}) = 0
+	21179 stat(".git/annex/othertmp/foo.0/foo", {st_mode=S_IFREG|0444, st_size=20, ...}) = 0
+	21179 chmod(".git/annex/othertmp/foo.0/foo", 0100644) = 0
+	21179 stat(".git/annex/othertmp/foo.0/foo", {st_mode=S_IFREG|0444, st_size=20, ...}) = 0
+	21179 rename(".git/annex/othertmp/foo.0/foo", "./foo") = 0
+
+So, cp -a copies the object file to the temp file, leaving it 444 at the end,
+as it should be since the object file had that mode. And the following
+chmod 644 has no effect.
+
+That `nfs4_acl` seems like it contains effectively the permissions of the file,
+which were 444 at that point. Could that xattr override the later chmod?
+
+It would be worth trying this:
+
+	# use runshell to get the same cp that git-annex uses
+	/dartfs-hpc/admin/opt/oldopt/git-annex/8.20200522/runshell
+	echo bar > bar
+	chmod 444 bar
+	cp --reflink=auto -a bar baz
+	chmod 644 baz
+	ls -l baz
+
+If preserving the `nfs4_acl` is indeed the problem, then a fix in git-annex
+might be possible. (Even though this feels like a NFS bug) 
+Replace `cp -a` with `cp -dR --preserve=mode,ownership,timestamps`
+so omitting the xattr preservation.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_9_640a2685ca0efb7367da6bc502354735._comment b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_9_640a2685ca0efb7367da6bc502354735._comment
new file mode 100644
index 0000000000..11691a7f39
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/comment_9_640a2685ca0efb7367da6bc502354735._comment
@@ -0,0 +1,67 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 9"
+ date="2021-08-27T01:34:18Z"
+ content="""
+not sure if related, but I noticed you said to use `/dartfs-hpc/admin/opt/oldopt/git-annex/8.20200522/runshell` which corresponds to the git-annex I have available upon login, but the tests were ran using git annex installed in a conda env `8.20200502-g55acb2e52` `~/.conda/envs/datalad/bin/git-annex`, which is a \"proper\" (not standalone) build and lacks `runshell`, and I believe would just use system wide `cp`.
+
+# in that /dartfs-hpc/admin/opt/oldopt/git-annex/8.20200522/runshell
+
+```
+(datalad) [d31548v@discovery7 _test_]$ /dartfs-hpc/admin/opt/oldopt/git-annex/8.20200522/runshell
+$ pwd
+/dartfs/rc/lab/D/DBIC/DBIC/inbox/BIDS/_test_
+$ echo bar > bar
+chmod 444 bar
+cp --reflink=auto -a bar baz
+chmod 644 baz
+ls -l baz$ $ $ $ 
+-r--r--r-- 1 d31548v rc-DBIC-bids 4 Aug 26 21:27 baz
+
+```
+
+now outside using default cp -- the same
+
+```shell
+(datalad) [d31548v@discovery7 _test_]$ echo bar > bar
+(datalad) [d31548v@discovery7 _test_]$ chmod 444 bar
+(datalad) [d31548v@discovery7 _test_]$ cp --reflink=auto -a bar baz
+(datalad) [d31548v@discovery7 _test_]$ chmod 644 baz
+(datalad) [d31548v@discovery7 _test_]$ ls -l baz
+-r--r--r-- 1 d31548v rc-DBIC-bids 4 Aug 26 21:29 baz
+```
+
+and indeed we do get a different result, with `w`, if running under a regular `/tmp`:
+
+```
+(datalad) [d31548v@discovery7 tmp]$ pwd
+/tmp
+(datalad) [d31548v@discovery7 tmp]$ echo bar > bar
+(datalad) [d31548v@discovery7 tmp]$ chmod 444 bar
+(datalad) [d31548v@discovery7 tmp]$ cp --reflink=auto -a bar baz
+(datalad) [d31548v@discovery7 tmp]$ chmod 644 baz
+(datalad) [d31548v@discovery7 tmp]$ ls -l baz
+-rw-r--r-- 1 d31548v rc-users 4 Aug 26 21:29 baz
+```
+
+Now, using the alternative to `-a` setting -- retains the `w` in both `runshell` and outside:
+
+```
+(datalad) [d31548v@discovery7 _test_]$ /dartfs-hpc/admin/opt/oldopt/git-annex/8.20200522/runshell
+$ echo bar > bar
+chmod 444 bar
+cp --reflink=auto -dR --preserve=mode,ownership,timestamps bar baz
+chmod 644 baz
+ls -l baz$ $ $ $ 
+-rw-r--r-- 1 d31548v rc-DBIC-bids 4 Aug 26 21:32 baz
+$ 
+(datalad) [d31548v@discovery7 _test_]$ rm -f bar baz
+(datalad) [d31548v@discovery7 _test_]$ echo bar > bar
+(datalad) [d31548v@discovery7 _test_]$ chmod 444 bar
+(datalad) [d31548v@discovery7 _test_]$ cp --reflink=auto -dR --preserve=mode,ownership,timestamps bar baz
+(datalad) [d31548v@discovery7 _test_]$ chmod 644 baz
+(datalad) [d31548v@discovery7 _test_]$ ls -l baz
+-rw-r--r-- 1 d31548v rc-DBIC-bids 4 Aug 26 21:32 baz
+```
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__.mdwn b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__.mdwn
new file mode 100644
index 0000000000..b7b00303b4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__.mdwn
@@ -0,0 +1,222 @@
+### Please describe the problem.
+
+I am unable to copy files from one git-annex repo to another, either using `copy --from=...' from the destination repo or `--to=...' from the source repo.
+
+Even with the added output from `--debug` I have no idea what is going wrong. The example below focusses on one file, but I think no files work.
+
+`git annex unused` shows `partially transferred data` after the failures. As far as I can tell, the rsync commands that copy the files to `.git/annex/objects/tmp` are working, so I guess the failure happens after that.
+
+From the source repo, located at `/home/james/w/annex-neu`:
+
+	james copter annex-neu $ git remote show -n nature
+	* remote nature
+	  Fetch URL: /d/nature-ext2/falsifian/w/annex-neu
+	  Push  URL: /d/nature-ext2/falsifian/w/annex-neu
+	  HEAD branch: (not queried)
+	  Remote branches: (status not queried)
+	    git-annex
+	    master
+	    synced/git-annex
+	    synced/master
+	  Local ref configured for 'git push' (status not queried):
+	    (matching) pushes to (matching)
+
+	james copter annex-neu $ git annex copy --to=nature datasets/reddit/files.pushshift.io/reddit/daily/RS_2019_10_01.gz
+	copy datasets/reddit/files.pushshift.io/reddit/daily/RS_2019_10_01.gz (to nature...)
+
+
+	  failed to send content to remote
+
+
+
+	  failed to send content to remote
+	failed
+	git-annex: copy: 1 failed
+
+And with `--debug`:
+
+	james copter annex-neu $ git annex copy --debug --to=nature datasets/reddit/files.pushshift.io/reddit/daily/RS_2019_10_01.gz                                    [2021-06-05 20:24:58.016674809] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+	[2021-06-05 20:24:58.021106113] process done ExitSuccess                        
+	[2021-06-05 20:24:58.021381484] read: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+	[2021-06-05 20:24:58.025170816] process done ExitSuccess                        [2021-06-05 20:24:58.025705324] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..803d71e5e3f15ee4a2a30e63c5e0e9faccf0defe","--pretty=%H","-n1"]                                                   [2021-06-05 20:24:58.029655191] process done ExitSuccess                        [2021-06-05 20:24:58.030257913] read: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","log","refs/heads/git-annex..4a7de0d2b9a7f4a2b9cf88c57636a8388
+	6f6b340","--pretty=%H","-n1"]
+	[2021-06-05 20:24:58.034210664] process done ExitSuccess
+	[2021-06-05 20:24:58.034470983] read: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","log","refs/heads/git-annex..bbfde8eb1c05e46c1a4e25719c8eb0418
+	9fa7cf2","--pretty=%H","-n1"]                                                   
+	[2021-06-05 20:24:58.038954155] process done ExitSuccess
+	[2021-06-05 20:24:58.039404429] chat: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","cat-file","--batch"]
+	[2021-06-05 20:24:58.039881197] chat: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(object
+	size)"]
+	[2021-06-05 20:24:58.050584672] read: git ["config","--null","--list"]
+	[2021-06-05 20:24:58.053085725] process done ExitSuccess
+	[2021-06-05 20:24:58.053918467] read: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","symbolic-ref","-q","HEAD"]
+	[2021-06-05 20:24:58.056598571] process done ExitSuccess
+	[2021-06-05 20:24:58.056750274] read: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","show-ref","refs/heads/master"]
+	[2021-06-05 20:24:58.059953296] process done ExitSuccess
+	[2021-06-05 20:24:58.060270357] read: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","ls-files","--stage","-z","--","datasets/reddit/files.pushshif
+	t.io/reddit/daily/RS_2019_10_01.gz"]
+	[2021-06-05 20:24:58.060602372] chat: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(object
+	size)","--buffer"]
+	[2021-06-05 20:24:58.061149131] chat: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)"
+	,"--buffer"]
+	[2021-06-05 20:24:58.061754169] chat: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)"
+	,"--buffer"]
+	copy datasets/reddit/files.pushshift.io/reddit/daily/RS_2019_10_01.gz (to nature
+	...) 
+	[2021-06-05 20:24:58.124257351] read: cp ["--reflink=always","--preserve=timesta
+	mps",".git/annex/objects/vv/Km/SHA256E-s302380112--fb63e37bf5af350af35be3400a47b
+	c1bf3a46253646b710579b9162560cea087.gz/SHA256E-s302380112--fb63e37bf5af350af35be
+	3400a47bc1bf3a46253646b710579b9162560cea087.gz","../../../../nature-ext2/falsifi
+	an/w/annex-neu/.git/annex/tmp/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc
+	1bf3a46253646b710579b9162560cea087.gz"]
+	[2021-06-05 20:24:58.125931854] process done ExitFailure 1
+	[2021-06-05 20:24:58.12621772] read: rsync ["--progress","--inplace","--perms","
+	.git/annex/objects/vv/Km/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a
+	46253646b710579b9162560cea087.gz/SHA256E-s302380112--fb63e37bf5af350af35be3400a4
+	7bc1bf3a46253646b710579b9162560cea087.gz","../../../../nature-ext2/falsifian/w/a
+	nnex-neu/.git/annex/tmp/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a4
+	6253646b710579b9162560cea087.gz"]
+	100%  288.37 MiB      330 MiB/s 0s  [2021-06-05 20:24:59.003840882] process done
+	 ExitSuccess
+
+	[2021-06-05 20:24:59.004436111] read: rsync ["--progress","--inplace","--perms",
+	".git/annex/objects/vv/Km/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3
+	a46253646b710579b9162560cea087.gz/SHA256E-s302380112--fb63e37bf5af350af35be3400a
+	47bc1bf3a46253646b710579b9162560cea087.gz","../../../../nature-ext2/falsifian/w/
+	annex-neu/.git/annex/tmp/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a
+	46253646b710579b9162560cea087.gz"]
+	100%  288.37 MiB      463 MiB/s 0s [2021-06-05 20:24:59.629830876] process done
+	ExitSuccess
+
+	  failed to send content to remote
+
+	[2021-06-05 20:24:59.631304163] read: rsync ["--progress","--inplace","--perms",
+	".git/annex/objects/vv/Km/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3
+	a46253646b710579b9162560cea087.gz/SHA256E-s302380112--fb63e37bf5af350af35be3400a
+	47bc1bf3a46253646b710579b9162560cea087.gz","../../../../nature-ext2/falsifian/w/
+	annex-neu/.git/annex/tmp/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a
+	46253646b710579b9162560cea087.gz"]
+	100%  288.37 MiB      462 MiB/s 0s [2021-06-05 20:25:00.257185993] process done
+	ExitSuccess
+
+	[2021-06-05 20:25:00.257891486] read: rsync ["--progress","--inplace","--perms",
+	".git/annex/objects/vv/Km/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3
+	a46253646b710579b9162560cea087.gz/SHA256E-s302380112--fb63e37bf5af350af35be3400a
+	47bc1bf3a46253646b710579b9162560cea087.gz","../../../../nature-ext2/falsifian/w/
+	annex-neu/.git/annex/tmp/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a
+	46253646b710579b9162560cea087.gz"]
+	100%  288.37 MiB      437 MiB/s 0s [2021-06-05 20:25:00.92075523] process done E
+	xitSuccess
+
+	  failed to send content to remote
+	failed
+	[2021-06-05 20:25:00.921692771] process done ExitSuccess
+	[2021-06-05 20:25:00.921771903] process done ExitSuccess
+	[2021-06-05 20:25:00.921837622] process done ExitSuccess
+	git-annex: copy: 1 failed
+
+
+Trying in the other direction (note /home/falsifian is a symlink to james):
+
+	james copter annex-neu $ git remote show -n local                               * remote local
+	  Fetch URL: /home/falsifian/w/annex-neu
+	  Push  URL: /home/falsifian/w/annex-neu
+	  HEAD branch: (not queried)
+	  Remote branches: (status not queried)
+	    git-annex
+	    master                                                                          synced/git-annex                                                                synced/master                                                                 Local ref configured for 'git push' (status not queried):                         (matching) pushes to (matching)                                             james copter annex-neu $ git annex get --debug --from=local datasets/reddit/file
+	s.pushshift.io/reddit/daily/RS_2019_10_01.gz
+	[2021-06-05 20:26:43.459693059] read: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","show-ref","git-annex"]
+	[2021-06-05 20:26:43.4637773] process done ExitSuccess
+	[2021-06-05 20:26:43.464083545] read: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+	[2021-06-05 20:26:43.467747946] process done ExitSuccess
+	[2021-06-05 20:26:43.468371444] read: git ["--git-dir=.git","--work-tree=.","--l
+	iteral-pathspecs","log","refs/heads/git-annex..2585bc984868658a30bac238f343e14ee
+	0ab4a40","--pretty=%H","-n1"]
+	[2021-06-05 20:26:43.472230994] process done ExitSuccess
+	[2021-06-05 20:26:43.472821833] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..4026e21e431b23f3ed8bab4a59d076a07eb38aba","--pretty=%H","-n1"]
+	[2021-06-05 20:26:43.476524704] process done ExitSuccess
+	[2021-06-05 20:26:43.476704328] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..4a7de0d2b9a7f4a2b9cf88c57636a83886f6b340","--pretty=%H","-n1"]
+	[2021-06-05 20:26:43.480419871] process done ExitSuccess
+	[2021-06-05 20:26:43.480903262] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+	[2021-06-05 20:26:43.481438522] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+	[2021-06-05 20:26:43.484464329] read: git ["config","--null","--list"]
+	[2021-06-05 20:26:43.484899963] read: git ["config","--null","--list"]
+	[2021-06-05 20:26:43.494876192] process done ExitSuccess
+	[2021-06-05 20:26:43.495606623] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+	[2021-06-05 20:26:43.498087081] process done ExitSuccess
+	[2021-06-05 20:26:43.498254949] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+	[2021-06-05 20:26:43.50112263] process done ExitSuccess
+	[2021-06-05 20:26:43.501446299] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--","datasets/reddit/files.pushshift.io/reddit/daily/RS_2019_10_01.gz"]
+	[2021-06-05 20:26:43.501858278] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+	[2021-06-05 20:26:43.503867361] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+	[2021-06-05 20:26:43.504653623] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+	[2021-06-05 20:26:43.50750836] chat: git ["--git-dir=.git","--work-tree=.","--li
+	teral-pathspecs","cat-file","--batch"]
+	[2021-06-05 20:26:43.50796496] chat: git ["--git-dir=.git","--work-tree=.","--li
+	teral-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+	get datasets/reddit/files.pushshift.io/reddit/daily/RS_2019_10_01.gz (from local...)
+	[2021-06-05 20:26:43.568982372] read: cp ["--reflink=always","--preserve=timesta
+	mps","../../../../../home/falsifian/w/annex-neu/.git/annex/objects/vv/Km/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a46253646b710579b9162560cea087.gz/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a46253646b710579b9162560cea087.gz",".git/annex/tmp/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a46253646b710579b9162560cea087.gz"]
+	[2021-06-05 20:26:43.571638865] process done ExitFailure 1
+	[2021-06-05 20:26:43.572002434] read: rsync ["--progress","--inplace","--perms","../../../../../home/falsifian/w/annex-neu/.git/annex/objects/vv/Km/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a46253646b710579b9162560cea087.gz/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a46253646b710579b9162560cea087.gz",".git/annex/tmp/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a46253646b710579b9162560cea087.gz"]
+	100%  288.37 MiB      351 MiB/s 0s   [2021-06-05 20:26:44.396269512] process don
+	e ExitSuccess
+
+	  failed to retrieve content from remote
+
+	[2021-06-05 20:26:44.397675637] read: rsync ["--progress","--inplace","--perms","../../../../../home/falsifian/w/annex-neu/.git/annex/objects/vv/Km/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a46253646b710579b9162560cea087.gz/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a46253646b710579b9162560cea087.gz",".git/annex/tmp/SHA256E-s302380112--fb63e37bf5af350af35be3400a47bc1bf3a46253646b710579b9162560cea087.gz"]
+	0%    32 KiB           23 MiB/s 12s[2021-06-05 20:26:45.0364163] process done Ex
+	itSuccess
+
+	  failed to retrieve content from remote
+	failed
+	[2021-06-05 20:26:45.037805309] process done ExitSuccess
+	[2021-06-05 20:26:45.03799324] process done ExitSuccess
+	[2021-06-05 20:26:45.038069266] process done ExitSuccess
+	[2021-06-05 20:26:45.038244936] process done ExitSuccess
+	[2021-06-05 20:26:45.03831897] process done ExitSuccess
+	git-annex: get: 1 failed
+
+
+### What steps will reproduce the problem?
+
+I don't know how to reproduce this on a different repo. This is the first time I've seen this. I haven't had trouble in the past.
+
+
+### What version of git-annex are you using? On what operating system?
+
+	james copter annex-neu $ git annex version
+	git-annex version: 8.20200810
+	build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+	dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.27 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+	key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+	remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+	operating system: linux x86_64
+	supported repository versions: 8
+	upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+	local repository version: 8
+	james copter annex-neu $ uname -a
+	Linux copter 4.9.0-15-amd64 #1 SMP Debian 4.9.258-1 (2021-03-08) x86_64 GNU/Linux
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git-annex is awesome! I am using it a lot.
+
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_10_755703a901687283f1a9b3bfcdf1ea68._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_10_755703a901687283f1a9b3bfcdf1ea68._comment
new file mode 100644
index 0000000000..ac86628de1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_10_755703a901687283f1a9b3bfcdf1ea68._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Carification"
+ date="2021-07-22T14:59:23Z"
+ content="""
+I posted this in response to [your reference](https://git-annex.branchable.com/forum/get_fails/#comment-a075dbdcd47640fb27d546c77679ab8c) (which points here). What is being reproducible is [this report](https://git-annex.branchable.com/forum/get_fails/#comment-fed0a60f23a32498459af4d9bb9dec2b)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_11_539c272450ceb56badde88702afb4e4d._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_11_539c272450ceb56badde88702afb4e4d._comment
new file mode 100644
index 0000000000..9cac6e08f7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_11_539c272450ceb56badde88702afb4e4d._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2021-07-22T17:08:56Z"
+ content="""
+@mih so the new version's output confirms my suspicion that git-annex
+sees a change in the stat information of the file (mtime, size, inode)
+from before it started the transfer to when it finished.
+
+I could imagine eg, that somehow the filesystem is not preserving stable
+inode numbers, and so the inode might appear different, without anything
+having actually changed.
+
+It also seems possible that git-annex might somehow fail to stat the file
+either before or afterwards. In either case that would result in the same
+message. Maybe there's some way that the file gets deleted at the same time
+it's being transferred. Maybe the stat call fails for some other reason.
+
+A strace of git-annex seems like the next step, if you can reproduce this
+somewhat reliably. I suggest a `strace -v`, which will display the full
+results of the stat() calls. The stats of the object file done before
+and after are the only part of the strace that we should need.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_12_67567cf57d9b7d57fb5e10ff7a54a99f._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_12_67567cf57d9b7d57fb5e10ff7a54a99f._comment
new file mode 100644
index 0000000000..fee8fb69b9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_12_67567cf57d9b7d57fb5e10ff7a54a99f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2021-07-22T17:26:02Z"
+ content="""
+I don't think it's a case of the file being deleted file it's being
+transferred. It is possible to do that, just `git annex drop` while
+a transfer is in progress. But that transfer fails in a different way:
+
+	  .git/annex/objects/Pg/8g/SHA256E-s1048576000--81a66cc6944beade4f98430ad1993bfe98a773fd0db76dd7818b2486b7c33399/SHA256E-s1048576000--81a66cc6944beade4f98430ad1993bfe98a773fd0db76dd7818b2486b7c33399: getFileStatus: does not exist (No such file or directory)
+	
+	  .git/annex/objects/Pg/8g/SHA256E-s1048576000--81a66cc6944beade4f98430ad1993bfe98a773fd0db76dd7818b2486b7c33399/SHA256E-s1048576000--81a66cc6944beade4f98430ad1993bfe98a773fd0db76dd7818b2486b7c33399: openBinaryFile: does not exist (No such file or directory)
+	
+	  failed to send content to remote
+	
+	  content not available
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_13_a4643d9f91947714b6105ca81164cb26._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_13_a4643d9f91947714b6105ca81164cb26._comment
new file mode 100644
index 0000000000..9aeca0ef9e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_13_a4643d9f91947714b6105ca81164cb26._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2021-07-22T17:59:12Z"
+ content="""
+(This stat check is not strictly necessary, at least when annex.verify is
+enabled, so removing it is a possibility. Or perhaps not making a failure
+to stat be treated as a problem. But I need to understand what's happening
+first.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_14_41f1271bdc7a4d62b30f6254a0f6ffd6._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_14_41f1271bdc7a4d62b30f6254a0f6ffd6._comment
new file mode 100644
index 0000000000..373de132ac
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_14_41f1271bdc7a4d62b30f6254a0f6ffd6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2021-07-22T18:07:37Z"
+ content="""
+Also seems possible that the keys db contains an inode cache for the object
+that is somehow out of date. It would then only stat the object once,
+which would succeed, but would differ from the previous value.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_15_0d6bfbc5539ef2083e0bc2e32762a9c0._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_15_0d6bfbc5539ef2083e0bc2e32762a9c0._comment
new file mode 100644
index 0000000000..56328764e2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_15_0d6bfbc5539ef2083e0bc2e32762a9c0._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="strace logs"
+ date="2021-07-26T07:10:22Z"
+ content="""
+I ran `PATH=/tmp/dl-build-eyhm_8vt/git-annex.linux:$PATH strace -v -f -e trace=%%stat git annex get sub-001/meg/sub-001_task-memento_proc-sss_meg-1.fif &> annex_strace_stat.txt` to produce a log using `git-annex version: 8.20210715-g39d747936`. `-f` was needed as the real action is taking place in a fork. And here is the `stat` evolution of the transfer file from that log (leaving the \"changed\" messages in to give a sense, when those happen):
+
+```
+% grep '\(stat.*/tmp/.*9aed9592cd3a6c1917b7c4c031aad4fa.fif\)\|\(content changed\)' < annex_strace_stat.txt 
+(from origin...) [pid 1294882] stat(\".git/annex/tmp/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif\", {st_dev=makedev(0x9, 0x2), st_ino=12191752, st_mode=S_IFREG|0644, st_nlink=1, st_uid=40214, st_gid=3104, st_blksize=4096, st_blocks=4191048, st_size=2145810855, st_atime=1627282213 /* 2021-07-26T08:50:13.284852080+0200 */, st_atime_nsec=284852080, st_mtime=1617777225 /* 2021-04-07T08:33:45.757412790+0200 */, st_mtime_nsec=757412790, st_ctime=1627282213 /* 2021-07-26T08:50:13.280852098+0200 */, st_ctime_nsec=280852098}) = 0
+[pid 1294882] stat(\".git/annex/tmp/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif\", {st_dev=makedev(0x9, 0x2), st_ino=12191752, st_mode=S_IFREG|0644, st_nlink=1, st_uid=40214, st_gid=3104, st_blksize=4096, st_blocks=4191048, st_size=2145810855, st_atime=1627282213 /* 2021-07-26T08:50:13.284852080+0200 */, st_atime_nsec=284852080, st_mtime=1617777225 /* 2021-04-07T08:33:45.757412790+0200 */, st_mtime_nsec=757412790, st_ctime=1627282213 /* 2021-07-26T08:50:13.280852098+0200 */, st_ctime_nsec=280852098}) = 0
+[pid 1294882] stat(\".git/annex/tmp/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif\", {st_dev=makedev(0x9, 0x2), st_ino=12191752, st_mode=S_IFREG|0644, st_nlink=1, st_uid=40214, st_gid=3104, st_blksize=4096, st_blocks=4191048, st_size=2145810855, st_atime=1627282213 /* 2021-07-26T08:50:13.284852080+0200 */, st_atime_nsec=284852080, st_mtime=1617777225 /* 2021-04-07T08:33:45.757412790+0200 */, st_mtime_nsec=757412790, st_ctime=1627282213 /* 2021-07-26T08:50:13.280852098+0200 */, st_ctime_nsec=280852098}) = 0
+[pid 1294887] stat(\".git/annex/tmp/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif\", 0x42000a91b0) = -1 ENOENT (No such file or directory)
+[pid 1294901] stat(\".git/annex/tmp/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif\", 0x7ffd582998a0) = -1 ENOENT (No such file or directory)
+[pid 1294901] newfstatat(AT_FDCWD, \".git/annex/tmp/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif\", 0x7ffd58299630, 0) = -1 ENOENT (No such file or directory)
+[pid 1294882] stat(\".git/annex/tmp/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif\", 0x42000b9970) = -1 ENOENT (No such file or directory)
+  content changed while it was being sent
+[pid 1294882] stat(\".git/annex/tmp/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif\", {st_dev=makedev(0x9, 0x2), st_ino=12191752, st_mode=S_IFREG|0444, st_nlink=1, st_uid=40214, st_gid=3104, st_blksize=4096, st_blocks=4191048, st_size=2145810855, st_atime=1617777225 /* 2021-04-07T08:33:45.757412790+0200 */, st_atime_nsec=757412790, st_mtime=1617777225 /* 2021-04-07T08:33:45.757412790+0200 */, st_mtime_nsec=757412790, st_ctime=1627282242 /* 2021-07-26T08:50:42.444725931+0200 */, st_ctime_nsec=444725931}) = 0
+  content changed while it was being sent
+[pid 1294882] stat(\".git/annex/tmp/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif\", {st_dev=makedev(0x9, 0x2), st_ino=12191752, st_mode=S_IFREG|0444, st_nlink=1, st_uid=40214, st_gid=3104, st_blksize=4096, st_blocks=4191048, st_size=2145810855, st_atime=1617777225 /* 2021-04-07T08:33:45.757412790+0200 */, st_atime_nsec=757412790, st_mtime=1617777225 /* 2021-04-07T08:33:45.757412790+0200 */, st_mtime_nsec=757412790, st_ctime=1627282252 /* 2021-07-26T08:50:52.464682583+0200 */, st_ctime_nsec=464682583}) = 0
+  content changed while it was being sent
+[pid 1294882] stat(\".git/annex/tmp/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif\", {st_dev=makedev(0x9, 0x2), st_ino=12191752, st_mode=S_IFREG|0444, st_nlink=1, st_uid=40214, st_gid=3104, st_blksize=4096, st_blocks=4191048, st_size=2145810855, st_atime=1617777225 /* 2021-04-07T08:33:45.757412790+0200 */, st_atime_nsec=757412790, st_mtime=1617777225 /* 2021-04-07T08:33:45.757412790+0200 */, st_mtime_nsec=757412790, st_ctime=1627282262 /* 2021-07-26T08:51:02.804637850+0200 */, st_ctime_nsec=804637850}) = 0
+  content changed while it was being sent
+
+```
+
+So without having a clear understanding of what is happening inside the key properties `mtime`, `size`, and `inode` ae stable (except that the file vanishes in some intermediate `stat` attempts). What changes is `atime` (no surprise, I guess), but also `ctime`, and the permissions.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_16_6ef33d110d709e46768549c59b02841a._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_16_6ef33d110d709e46768549c59b02841a._comment
new file mode 100644
index 0000000000..49d74826e8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_16_6ef33d110d709e46768549c59b02841a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2021-07-26T14:21:17Z"
+ content="""
+You grepped for stats of a file in `tmp` directory but those stats are not
+relevant to this problem. Since you ran git-annex get, it should be statting
+the annex object file in the remote repository, which I assume is another git
+repo on the same computer. (Otherwise it would not be able to fail this way
+AFAICS.) It's the stat of that file that's relevant.
+
+I've added some debugging now, so --debug with a fresh git-annex build
+should explain what's going on with the stats. 
+Use -c annex.debugfilter=Annex.InodeSentinal,Annex.Content 
+to limit debug output to the relevant ones.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_17_7c7b953b2366fbfc1b95cc6048473ddb._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_17_7c7b953b2366fbfc1b95cc6048473ddb._comment
new file mode 100644
index 0000000000..bb730f9ce2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_17_7c7b953b2366fbfc1b95cc6048473ddb._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 17"""
+ date="2021-07-26T17:12:28Z"
+ content="""
+I can certianly reproduce this if I manually get the keys database
+into a state where it has the wrong inode recorded for the object file.
+
+I have not found a way to make that happen using git-annex, but I'm
+guessing it might involve annex.thin being set, and almost certianly
+involves unlocked files. Some sequence of events is happening in
+the git repo that later prevents getting content from it, even though
+the content is still there.
+
+It kind of looks like Command.Lock might neglect to update the keys
+database when it repopulates the annex object from an unmodified associated
+file in the case where it was hard linked to another, unlocked file and so
+got modified. I have not quite managed to make that reproduce it though.
+
+But that's just guessing and the real situation could be something
+different. Someone needs to figure out how to reproduce this,
+until then I'm probably stuck.
+
+(Enough other things could break due to this kind of database inconsistency
+that simply removing the check when transferring the file would only paper
+over the problem.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_18_eb8b597167a6708a27ac03ef4fbf3632._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_18_eb8b597167a6708a27ac03ef4fbf3632._comment
new file mode 100644
index 0000000000..e69ba7fb15
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_18_eb8b597167a6708a27ac03ef4fbf3632._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 18"""
+ date="2021-07-26T20:29:13Z"
+ content="""
+One way to reproduce this is to replace the git repository with a copy
+produced with eg `cp -r` (not `-a`), with the file unlocked before that
+point. Eg:
+
+	#!/bin/sh
+	set -e
+	cd tmp
+	sudo rm -rf xx yy xx.old
+	git init xx
+	cd xx
+	git annex init
+	echo hi > foo
+	git annex add foo
+	git annex unlock foo
+	git commit -m add
+	cd ..
+	git clone xx yy
+	mv xx xx.old
+	sleep 10
+	cp -r xx.old xx
+	cd yy
+	git annex init
+	git annex get foo
+
+I doubt this is what people have been doing to see the behavior though.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_19_9a1c92462a5393155298d70ef90d3019._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_19_9a1c92462a5393155298d70ef90d3019._comment
new file mode 100644
index 0000000000..8d43dc8c61
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_19_9a1c92462a5393155298d70ef90d3019._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2021-07-26T21:20:15Z"
+ content="""
+I've made it fall back to checking the file's content when the inode cache
+is somehow stale. I expect this will solve the problem. But, I would still
+like to know how to reproduce the problem, because if something is making
+the inode cache go stale, this fallback check will need to hash the file,
+which could make git-annex significantly more expensive.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_1_c36b1968c69e9794c723ff29d1738759._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_1_c36b1968c69e9794c723ff29d1738759._comment
new file mode 100644
index 0000000000..6782785529
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_1_c36b1968c69e9794c723ff29d1738759._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-06-14T17:06:19Z"
+ content="""
+From the --deubg you provided, the important part is that rsync is
+succeeding to copy the file, but then git-annex for some reason thinks it
+failed, or has some other problem. Eg, if the annexed object was corrupt,
+it could copy it with rsync and then fail to verify the copy.
+
+Your git-annex version is a year out of date, so you should upgrade. The
+code that is failing has definitely been changed a lot in the meantime,
+though not that I can remember to fix a bug like this.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_20_e6ed93310ad694f6c52b52530c63f8f5._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_20_e6ed93310ad694f6c52b52530c63f8f5._comment
new file mode 100644
index 0000000000..40b48c5faf
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_20_e6ed93310ad694f6c52b52530c63f8f5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Fixed in 8.20210715-g3b5a3e168"
+ date="2021-07-27T12:00:35Z"
+ content="""
+I tried with the update from yesterday and it checksumed the file first, and only then started the download -- which matches the code change, I think.
+
+After the update in the source dataset, I can now also `get` the file with git annex 8.20210310.
+
+I am afraid that I have no idea how to replicate the original state. It was a rather organic process that involved computation across a cluster. Each compute node operated on its own branch of a clone, the branches were pushed back and merged. A final `git annex fsck` seemingly confirmed that all is kosher.
+
+I tried this with two affected files, but I have a few more left. If you let me know what exactly would be meaningful input for you to get a sense of what is going on, I'd be happy to provide that. Would a full `strace` log (analog to the above) be suitable?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_21_79ccde86a33f486b77857720d97185f3._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_21_79ccde86a33f486b77857720d97185f3._comment
new file mode 100644
index 0000000000..fbcbdd6983
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_21_79ccde86a33f486b77857720d97185f3._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 21"""
+ date="2021-07-27T17:16:50Z"
+ content="""
+I don't think a strace will tell me anything now.
+
+Is this the same repository that this issue was regarding?
+<https://github.com/datalad/datalad/issues/5613>
+If not, that does seem like the same problem so perhaps we could learn
+something from that repository.
+
+Was this repository upgraded from git-annex repository format 7 to 8?
+If so, I see one way this could have happened. That upgrade regenerates
+the keys db, but does not add inode caches for annex objects.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_22_4b6cf4221ff9d4f106d595f2897ea85f._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_22_4b6cf4221ff9d4f106d595f2897ea85f._comment
new file mode 100644
index 0000000000..61ee5e955d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_22_4b6cf4221ff9d4f106d595f2897ea85f._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Cause cannot (only) be a v7->v8 upgrade"
+ date="2021-07-29T05:40:36Z"
+ content="""
+I posted an update to https://github.com/datalad/datalad/issues/5613#issuecomment-888813877 Below is an edited version:
+
+The repository this issue is referring to is indeed old (started in 2015). So an upgrade from 7 (or earlier) is a potential cause. It is currently a version 8 repo.
+
+Moreover, I can still replicate the exact same issue with `git-annex version: 8.20210310`. I have not attempted to use the newest git-annex to preserve the state of this repo.
+
+I can confirm, however, that this issue is unrelated to the special datalad special remote implementation. I created a plain new remote on the local filesystem, and I can see the same behavior when attempting to copy the key to it:
+
+```
+% git remote -v
+...
+tmp     /tmp/mytest (fetch)
+tmp     /tmp/mytest (push)
+
+% git annex copy --to tmp --key MD5E-s190--e6e1f4d3923cfd861e23f0f4cb20fa03.mat 
+copy MD5E-s190--e6e1f4d3923cfd861e23f0f4cb20fa03.mat (to tmp...) 
+  failed to send content to remote
+  failed to send content to remote
+failed
+git-annex: copy: 1 failed
+```
+
+That being said, the cause cannot (only) be a v7 to v8 upgrade. The repository concerning https://github.com/datalad/datalad/issues/5750 was created in April 2021 (v8 from the very start), and there are more recent examples too.
+
+In both cases a `git annex fsck` was attempted in the repository from which a key was to be transferred from. In both cases that did not fix the issue. As far as I understand the fix made in 8.20210715-g3b5a3e168 forces a file checksuming before transfer. This is an expensive change, and the `fsck` should have already performed the same checksuming. Should `fsck` not also be able to update the respective key property caches?
+
+
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_23_503d0507c55412ca8c625b32feb7f80e._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_23_503d0507c55412ca8c625b32feb7f80e._comment
new file mode 100644
index 0000000000..c612752e1b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_23_503d0507c55412ca8c625b32feb7f80e._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2021-07-29T16:30:46Z"
+ content="""
+There are probably multiple causes. v8 upgrade does seem likely to be the
+main one, but I see that adswa seems to have found a way to reproduce it from
+scratch:
+<https://github.com/datalad/datalad/issues/5750#issuecomment-888819347>
+It's looking like perhaps inode instability in their case, due to use
+of a networked filesystem in a cluster.
+
+I have done some detailed auditing, and I'm pretty sure git-annex doesn't
+just forget to record the inode in some case. Well, except for potentially
+one case involving git-annex lock and annex.thin, which I fixed but was not
+able to actually quite get to reproduce the problem. 
+
+(I did find a some potential races, that would cause other problems but not
+this one, so the auditing was good for something..)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_24_4345e2d7f30318dc7565e90ac8578086._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_24_4345e2d7f30318dc7565e90ac8578086._comment
new file mode 100644
index 0000000000..3457a8d729
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_24_4345e2d7f30318dc7565e90ac8578086._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 24"""
+ date="2021-07-29T17:00:57Z"
+ content="""
+I agree, fsck should notice and correct this problem. The current fix
+papers over the problem it in a way that will prevent users noticing it.
+Fsck being noisy about it will help avoid sweeping it under the rug and
+forgetting about it. Implemented that.
+
+The performance impact here is relatively small. Aside from
+whenever this problem occurs, the extra checksumming will only happen when
+files are unlocked and the object file is modified. So annex.thin
+would need to be set and a file modified in a way that affects the object
+file. Several other parts of git-annex also checksum in that situation;
+that's a perf price you pay for using annex.thin. When this problem does
+occur, it will only checksum the object file once, and then will get its
+inode information cached.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_2_5b1148d1d771b71f6af654f974dbf427._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_2_5b1148d1d771b71f6af654f974dbf427._comment
new file mode 100644
index 0000000000..2aa8f0c3ac
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_2_5b1148d1d771b71f6af654f974dbf427._comment
@@ -0,0 +1,144 @@
+[[!comment format=mdwn
+ username="falsifian"
+ avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae"
+ subject="comment 2"
+ date="2021-06-19T23:41:24Z"
+ content="""
+I tried again with 8.20210428 and saw a similar error. `git annex fsck` thinks the file is okay. It doesn't exist on the remote (`elbow`) in this case (confirmed that the symlink is broken).
+
+copy&paste showing `version`, `copy --debug` and `fsck`:
+
+    james copter annex-neu $ git annex version                             [61/5067]
+    git-annex version: 8.20210428
+    build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser M
+    agicMime Feeds Testsuite S3 WebDAV
+    dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.28 DAV-1.3.4 feed
+    -1.3.2.0 ghc-8.10.4 http-client-0.6.4.1 persistent-sqlite-2.11.1.0 torrent-10000
+    .1.1 uuid-1.3.15 yesod-1.6.1.1
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEI
+    N256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512
+    E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM UR
+    L X*                                                                            remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb ta
+    hoe glacier ddar git-lfs httpalso borg hook external
+    operating system: linux x86_64
+    supported repository versions: 8
+    upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+    local repository version: 8
+    james copter annex-neu $ git remote show -n elbow
+    * remote elbow
+      Fetch URL: /d/elbow-ext2/falsifian/w/annex-neu
+      Push  URL: /d/elbow-ext2/falsifian/w/annex-neu
+      HEAD branch: (not queried)
+      Remote branches: (status not queried)
+        git-annex
+        master
+        synced/git-annex
+        synced/master
+      Local ref configured for 'git push' (status not queried):
+        (matching) pushes to (matching)
+    james copter annex-neu $ git annex fsck software_releases/openbsd/68/amd64/insta
+    ll68.img
+    fsck software_releases/openbsd/68/amd64/install68.img (checksum...) ok
+    (recording state in git...)
+    james copter annex-neu $ git annex copy --debug --to=elbow software_releases/ope
+    nbsd/68/amd64/install68.img
+    [2021-06-19 23:37:59.820462299] (Utility.Process) process [28235] read: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"sho
+    w-ref\",\"git-annex\"]
+    [2021-06-19 23:37:59.824734704] (Utility.Process) process [28235] done ExitSucce
+    ss
+    [2021-06-19 23:37:59.825397492] (Utility.Process) process [28236] read: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"sho
+    w-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2021-06-19 23:37:59.829279502] (Utility.Process) process [28236] done ExitSucce
+    ss
+    [2021-06-19 23:37:59.830626358] (Utility.Process) process [28237] read: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"log
+    \",\"refs/heads/git-annex..ddbef20f72b72bf2c36bc07574cf211c954bbc41\",\"--pretty=%H\"
+    ,\"-n1\"]
+    [2021-06-19 23:37:59.834246281] (Utility.Process) process [28237] done ExitSucce
+    ss
+    [2021-06-19 23:37:59.834758464] (Utility.Process) process [28238] read: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"log
+    \",\"refs/heads/git-annex..061e90a61d21283803bd3a16628337e3d098452d\",\"--pretty=%H\"
+    ,\"-n1\"]
+    [2021-06-19 23:37:59.838545279] (Utility.Process) process [28238] done ExitSucce
+    ss
+    [2021-06-19 23:37:59.838996643] (Utility.Process) process [28239] read: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"log
+    \",\"refs/heads/git-annex..5c367f9a01548348bffa89e8d441c64b18e0dd51\",\"--pretty=%H\"
+    ,\"-n1\"]
+    [2021-06-19 23:37:59.842728492] (Utility.Process) process [28239] done ExitSucce
+    ss
+    [2021-06-19 23:37:59.84317283] (Utility.Process) process [28240] read: git [\"--g
+    it-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"log\"
+    ,\"refs/heads/git-annex..194c38c1020fe2f5fb62a1358c08589feb845e06\",\"--pretty=%H\",
+    \"-n1\"]
+    [2021-06-19 23:37:59.847513494] (Utility.Process) process [28240] done ExitSucce
+    ss
+    [2021-06-19 23:37:59.847961228] (Utility.Process) process [28241] read: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"log
+    \",\"refs/heads/git-annex..9dbdfd430c2d74c58de025c9f30d8a218cf137ca\",\"--pretty=%H\"
+    ,\"-n1\"]
+    [2021-06-19 23:37:59.851669136] (Utility.Process) process [28241] done ExitSucce
+    ss
+    [2021-06-19 23:37:59.859466727] (Utility.Process) process [28242] chat: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat
+    -file\",\"--batch\"]
+    [2021-06-19 23:37:59.860034811] (Utility.Process) process [28243] chat: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat
+    -file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+    [2021-06-19 23:37:59.863651703] (Utility.Process) process [28244] read: git [\"co
+    nfig\",\"--null\",\"--list\"]
+    [2021-06-19 23:37:59.86580683] (Utility.Process) process [28244] done ExitSucces
+    s
+    [2021-06-19 23:37:59.867051153] (Utility.Process) process [28246] read: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"sym
+    bolic-ref\",\"-q\",\"HEAD\"]
+    [2021-06-19 23:37:59.86930561] (Utility.Process) process [28246] done ExitSucces
+    s
+    [2021-06-19 23:37:59.870034557] (Utility.Process) process [28247] read: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"sho
+    w-ref\",\"refs/heads/master\"]
+    [2021-06-19 23:37:59.873057419] (Utility.Process) process [28247] done ExitSucce
+    ss
+    [2021-06-19 23:37:59.873564996] (Utility.Process) process [28248] read: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"ls-
+    files\",\"--stage\",\"-z\",\"--\",\"software_releases/openbsd/68/amd64/install68.img\"]
+    [2021-06-19 23:37:59.874034406] (Utility.Process) process [28249] chat: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat
+    -file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+    [2021-06-19 23:37:59.874572424] (Utility.Process) process [28250] chat: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat
+    -file\",\"--batch=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+    [2021-06-19 23:37:59.875594055] (Utility.Process) process [28251] chat: git [\"--
+    git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat
+    -file\",\"--batch=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+    copy software_releases/openbsd/68/amd64/install68.img (to elbow...)
+    [2021-06-19 23:37:59.994828229] (Utility.Process) process [28253] read: cp [\"--r
+    eflink=always\",\"--preserve=timestamps\",\".git/annex/objects/MF/F8/SHA256-s6967459
+    84--14ea602583030b33e91ee8fde8dd76113984e9fac6598f9f609f408137c4cff2/SHA256-s696
+    745984--14ea602583030b33e91ee8fde8dd76113984e9fac6598f9f609f408137c4cff2\",\"/d/el
+    bow-ext2/falsifian/w/annex-neu/.git/annex/tmp/SHA256-s696745984--14ea602583030b3
+    3e91ee8fde8dd76113984e9fac6598f9f609f408137c4cff2\"]
+    [2021-06-19 23:37:59.996355598] (Utility.Process) process [28253] done ExitFailu
+    re 1
+    
+    
+      failed to send content to remote
+    
+    
+    
+      failed to send content to remote
+    failed
+    [2021-06-19 23:38:16.192591254] (Utility.Process) process [28251] done ExitSucce
+    ss
+    [2021-06-19 23:38:16.192851278] (Utility.Process) process [28250] done ExitSucce
+    ss
+    [2021-06-19 23:38:16.193064177] (Utility.Process) process [28249] done ExitSucce
+    ss
+    [2021-06-19 23:38:16.193167533] (Utility.Process) process [28248] done ExitSucce
+    ss
+    git-annex: copy: 1 failed
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_3_ac650ab647f5fda2623a958b30b40c18._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_3_ac650ab647f5fda2623a958b30b40c18._comment
new file mode 100644
index 0000000000..76f4f3bf0b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_3_ac650ab647f5fda2623a958b30b40c18._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="falsifian"
+ avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae"
+ subject="comment 3"
+ date="2021-06-19T23:48:20Z"
+ content="""
+If it helps: I see a progress indicator go from 0% to 100% four times when I run the copy command. The \"failed to send content to remote\" messages appear after the second and fourth times.
+
+Also, I was able to copy that reddit dataset file (from my original comment) to this remote (`elbow`) today. So I guess it is not a property of the particular file on the source repository?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_4_af8d80956d3ccedfe9aeb0fe22b2592a._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_4_af8d80956d3ccedfe9aeb0fe22b2592a._comment
new file mode 100644
index 0000000000..3af04e4347
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_4_af8d80956d3ccedfe9aeb0fe22b2592a._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-06-25T16:15:40Z"
+ content="""
+I've taken a close look at the error handling in the relevant code path.
+Normally when there's an exception it gets displayed. It is possible
+for the transfer to fail without displaying anything and without throwing an
+exception. When I synthesize such a failure, I see the same
+output you described.
+
+One way that could happen is if git-annex thinks the file got
+modified while it was being sent. If the file was unlocked, and was touched
+by something else while the copy was running, it would be enough to make
+git-annex think that, even though the content is still good. I've made
+it display a reason for the failure in that case.
+
+The only other way I found was if the hash fails to verify, which seems
+already ruled out in your case, but it did result in the same hard to understand
+output, so I've fixed that too.
+
+It would be good to know if one of these changes has fixed it for you.
+The autobuild for linux should be updated within an hour.
+While the scenario with the file having been touched seems unlikely to
+happen repeatedly with different files, it does otherwise match your
+circumstances and seems like the most likely fit.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_5_93cb28a06189d349a59d8d79c44d3b51._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_5_93cb28a06189d349a59d8d79c44d3b51._comment
new file mode 100644
index 0000000000..34279b323d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_5_93cb28a06189d349a59d8d79c44d3b51._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="falsifian"
+ avatar="http://cdn.libravatar.org/avatar/59c3c23c500d20d83ecb9d1f149be9ae"
+ subject="comment 5"
+ date="2021-06-30T00:09:23Z"
+ content="""
+Hm, the mtime of the target of `software_releases/openbsd/68/amd64/install68.img` is later than the time of my last comment:
+
+    james copter annex-neu $ ls -l .git/annex/objects/MF/F8/SHA256-s696745984--14ea602583030b33e91ee8fde8dd76113984e9fac6598f9f609f408137c4cff2/SHA256-s696745984--14ea602583030b33e91ee8fde8dd76113984e9fac6598f9f609f408137c4cff2
+    -r--r--r-- 1 james james 696745984 Jun 23 20:17 .git/annex/objects/MF/F8/SHA256-s696745984--14ea602583030b33e91ee8fde8dd76113984e9fac6598f9f609f408137c4cff2/SHA256-696745984--14ea602583030b33e91ee8fde8dd76113984e9fac6598f9f609f408137c4cff2
+
+I can't imagine what would have touched it in the meantime, but there it is. So, I suspect your theory about the mtime changing is right. (I double-checked that git annex fsck is still happy with the file today.)
+
+Next time I see this behaviour, I'll try running your updated code to confirm the cause, and also try to figure out what's touching the file.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_6_d76a32758b58695dcef7d4ec83abb1ea._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_6_d76a32758b58695dcef7d4ec83abb1ea._comment
new file mode 100644
index 0000000000..91fadb7f88
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_6_d76a32758b58695dcef7d4ec83abb1ea._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-07-01T16:35:51Z"
+ content="""
+See also similar report here
+<https://git-annex.branchable.com/forum/get_fails/>
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_7_40094333a89de09f7e64ca715ba20f16._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_7_40094333a89de09f7e64ca715ba20f16._comment
new file mode 100644
index 0000000000..2f96b1ab8e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_7_40094333a89de09f7e64ca715ba20f16._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-07-19T14:27:50Z"
+ content="""
+Whether the timestamp is right or not doesn't matter, but if something is
+causing it to *change*, it could result in this error.
+
+All I can suggest is you upgrade git-annex to a current release, to get a
+hopefully better error message.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_7_4da389b802a114dc18e0264a4df36dee._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_7_4da389b802a114dc18e0264a4df36dee._comment
new file mode 100644
index 0000000000..5b63548be3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_7_4da389b802a114dc18e0264a4df36dee._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="same problem on debian bullseye"
+ date="2021-07-18T02:02:42Z"
+ content="""
+I'm having the same problem with the latest git-annex from Debian bullseye (`8.20210223-2`). I have a flaky hardware clock on this computer, which NTP regularly adjusts by a few seconds (!):
+
+    jui 17 21:56:27 curie ntpd[1042]: adjusting local clock by -2.525655s
+    jui 17 21:57:30 curie ntpd[1042]: adjusting local clock by -2.546923s
+    jui 17 22:01:51 curie ntpd[1042]: adjusting local clock by -2.537140s
+
+so maybe that's what's going on? i understand that having a working clock is kind of ... expected of computers nowadays (!) but maybe that could be the source of this problem...
+
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_9_c43d7b153cc8b68f31ea007922326ee8._comment b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_9_c43d7b153cc8b68f31ea007922326ee8._comment
new file mode 100644
index 0000000000..c59bcfc370
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__34__failed_to_send_content_to_remote__34__/comment_9_c43d7b153cc8b68f31ea007922326ee8._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Reproducible with 8.20210715-g39d747936"
+ date="2021-07-22T14:54:40Z"
+ content="""
+```
+...
+[2021-07-22 16:48:57.422143438] (Utility.Process) process [4094853] read: cp [\"--reflink=always\",\"--preserve=timestamps\",\"/data/project/brainpeach/memento-sss/.git/annex/objects/3M/zW/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif\",\".git/annex/tmp/MD5E-s2145810855--9aed9592cd3a6c1917b7c4c031aad4fa.fif\"]
+[2021-07-22 16:48:57.432008244] (Utility.Process) process [4094853] done ExitFailure 1
+  content changed while it was being sent
+  content changed while it was being sent
+  failed to retrieve content from remote
+[2021-07-22 16:49:08.991227722] (Utility.Process) process [4094849] done ExitSuccess
+[2021-07-22 16:49:08.991545471] (Utility.Process) process [4094850] done ExitSuccess
+  content changed while it was being sent
+  content changed while it was being sent
+  failed to retrieve content from remote
+```
+
+I have a repository with a file where this happens reliably for `get` requests by different users to different locations on that system (but not for `get` requests issued from  different systems).
+
+If it helps, we could arrange for access Joey.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo.mdwn b/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo.mdwn
new file mode 100644
index 0000000000..f639a543dd
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo.mdwn
@@ -0,0 +1,81 @@
+2a8fdfc7d (Display a warning message when asked to operate on a file
+inside a directory that's a symbolic link to elsewhere, 2020-05-11)
+made `git annex add` error like `git add` does rather than silently
+doing nothing in a scenario like below.
+
+[[!format sh """
+# <repo>
+# |-- a
+# |   `-- f0
+# `-- alink -> a
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/gx-link-XXXXXXX)"
+git init && git annex init
+mkdir a
+ln -sT a alink
+echo 0 >alink/f0
+git annex add alink/f0
+"""]]
+
+Unlike git, however, git-annex's warning also applies when the
+symbolic link is upstream of the repository and git-annex is passed an
+absolute path.
+
+[[!format sh """
+# .
+# |-- a
+# |   `-- repo
+# |       `-- f0
+# `-- alink -> a
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/gx-link-XXXXXXX)"
+mkdir a
+ln -sT a alink
+git init alink/repo
+(
+    cd alink/repo
+    git annex init
+    echo 0 >f0
+    git annex add "$(pwd)"/f0
+)
+"""]]
+
+```
+[...]
+git-annex: /tmp/gx-link-Wxqnzo8/alink/repo/f0 is beyond a symbolic link
+add f0
+ok
+(recording state in git...)
+```
+
+The file does appear to be annexed and added to the index despite the
+warning:
+
+```
+$ git diff --cached
+diff --git a/f0 b/f0
+new file mode 120000
+index 0000000..7a725b9
+--- /dev/null
++++ b/f0
+@@ -0,0 +1 @@
++.git/annex/objects/Xj/V5/SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa/SHA256E-s2--9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa
+\ No newline at end of file
+```
+
+Looking at `Seek.workTreeItems'`, my first thought was that the above
+scenario should not error: `relPathCwdToFile` should turn the absolute
+path into `f0` when it compares it against the current working
+directory, `/tmp/gx-link-Wxqnzo8/alink/repo/`.  However, it looks like
+`System.Directory.getCurrentDirectory` returns a resolved path for the
+current working directory, so `relPathCwdToFile` turns the absolute
+path into `../../alink/repo/f0`, which gets flagged by the
+`viasymlink` check.
+
+This error message is of course easy enough to work around on the
+caller's side, but since it looks like an unintended consequence of
+2a8fdfc7d, the change in behavior seems worth mentioning.
+
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_1_a2d1112b0a9338b7c093546a985a5f90._comment b/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_1_a2d1112b0a9338b7c093546a985a5f90._comment
new file mode 100644
index 0000000000..be4951bfb8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_1_a2d1112b0a9338b7c093546a985a5f90._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-08-06T16:01:46Z"
+ content="""
+Really, the shell is the only thing that knows cd has been used with a symlink,
+the real cwd is what getCurrentDirectory returns, same as getcwd(3).
+
+(I think this is a bad design decision on the part of shells, it often
+leads to various confusion and odd behavior. A good example of this is
+that, if you cd bar/dir, which is a symlink to foo/dir, and both
+bar/file and foo/file exist, what does rm ../file delete? Not what the
+shell prompt's `bar>` suggests!)
+
+What this code needs to do is stop traversing the path and checking for
+symlinks when it reaches the top of the working tree. But I'm not currently
+seeing a good way to do that. It would need to examine the path for
+symlinks and resolve them. Like canonicalizePath, but don't want to
+canonicalize the part of the path inside the working tree, eg a symlink
+"./foo" should not be canonicalized to "./bar". But how does it know where
+inside working tree part begins when there are symlinks involved? Probably
+I'm missing something simple which git does to deal with this.
+
+(Also, canonicalizePath or anything like it does add a certian amount of
+overhead for every file passed to git-annex on the command line, just for
+this edge case. The current code does 2 stats, but this would be stats
+all the way up the path.)
+
+It also looks like the nearby code `hidden currbranch relf`
+will not work in this same case, because relf is "../../alink/repo/f0".
+In that case it will display "not found" and really fail to process
+the file.
+
+In a way the really surprising thing is not that it rejects this file with
+"is beyond a symbolic link" but that the file then goes on to be processed
+anyway. Because this code only displays a warning, and is written with the
+naive hope that it will manage to replicate git's porcelain behavior.
+But then git ls-files goes on to list the file anyway, so it's processed
+anyway.
+
+I think it should certianly, if it warns about a file, not pass it into git
+ls-files. So the warning really becomes an error and that surprise is
+avoided.
+
+That might be enough to consider this dealt with, without using
+canonicalizePath. There would then be an inconsistency that `git add` etc
+can be used with that path, while `git annex add` etc reject it as beyond
+a symbolic link. But git-annex is not obliged to copy git's behavior in what
+path situations it will accept and rejecting this particular one does not seem
+like a hardship to the user. 
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_2_c6e30af134a73bc8b3faee83c7c3b378._comment b/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_2_c6e30af134a73bc8b3faee83c7c3b378._comment
new file mode 100644
index 0000000000..985a751088
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_2_c6e30af134a73bc8b3faee83c7c3b378._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-08-06T17:46:11Z"
+ content="""
+I've made it skip processing the file in this case.
+
+Remain unsure if I want to close it now that the behavior is at least not
+weird, or try to more closely replicate git's behavior of what symlinks
+it's ok to be behind and which not.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_3_9ac6e3436ab4866993ebf4e469b13636._comment b/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_3_9ac6e3436ab4866993ebf4e469b13636._comment
new file mode 100644
index 0000000000..64ff44e454
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_3_9ac6e3436ab4866993ebf4e469b13636._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-08-06T22:29:49Z"
+ content="""
+AFAICS, git does something like cache the stat of the directory at the top
+of the working tree, and uses that to know which part to check for symlinks. 
+There's a lstat cache in the relevant code anyway.
+
+Ok, implemented it that way in git-annex, which I was able to do w/o doing
+any more work per file than comparing a dev and an inode.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_3_efe4490c33e874bd78fd567c70874088._comment b/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_3_efe4490c33e874bd78fd567c70874088._comment
new file mode 100644
index 0000000000..cf6eb234f3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_3_efe4490c33e874bd78fd567c70874088._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 3"
+ date="2020-08-06T20:58:17Z"
+ content="""
+> Really, the shell is the only thing that knows cd has been used with a symlink,
+> the real cwd is what getCurrentDirectory returns, same as getcwd(3).
+
+Doh, indeed.  Thanks.
+
+> But how does it know where inside working tree part begins when
+> there are symlinks involved? Probably I'm missing something simple
+> which git does to deal with this.
+
+It looks like git handles this in `setup.c:abspath_part_inside_repo`.
+That function takes the absolute, unresolved path that was given as an
+argument (`/tmp/gx-link-Wxqnzo8/alink/repo/f0`, to continue with the
+original example).  Then it compares that to the working tree path
+(`/tmp/gx-link-Wxqnzo8/a/repo`).
+
+If the path doesn't already have the working tree as a prefix, the
+core logic seems to be:
+
+  * Take the realpath of the leftmost directory in the received path
+    (`/tmp`).
+
+  * If that fully matches the path for the working tree, chop those
+    leading components off of the received path, returning what
+    remains.
+
+  * If not, tack on the next directory component
+    (`/tmp/gx-link-Wxqnzo8/`) and repeat.
+
+For this specific case, that'd go until
+`/tmp/gx-link-Wxqnzo8/alink/repo/`, whose realpath would match the
+working tree, and then return `f0`.
+
+That of course may not be worth the overhead.
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__39__git_annex_test__39___failures_introduced_by_75aab72d2.mdwn b/doc/projects/datalad/bugs-done/__39__git_annex_test__39___failures_introduced_by_75aab72d2.mdwn
new file mode 100644
index 0000000000..b20cc24ad5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__39__git_annex_test__39___failures_introduced_by_75aab72d2.mdwn
@@ -0,0 +1,142 @@
+Running `git annex test` with the current master (9a3b050) shows nine
+failures (on my end and on the CI runs at
+<https://github.com/datalad/datalad-extensions>).  These failures
+bisect to 75aab72d2 (mostly done with location log precaching,
+2020-07-13).
+
+I've tried to extract the failing tests below, adding horizontal
+separators for readability.
+
+```
+    unannex (no copy):                                    [adjusted/master(unlocked) 0acf147] empty
+adjust ok
+unannex foo cp: cannot stat '.git/annex/objects/Kj/0x/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77': No such file or directory
+
+git-annex: foo: getFileStatus: does not exist (No such file or directory)
+failed
+git-annex: unannex: 1 failed
+FAIL (0.48s)
+      Test.hs:504:
+      unannex failed with no copy
+
+----------------------------------------------------
+
+    unannex (with copy):                                  [adjusted/master(unlocked) 0acf147] empty
+adjust ok
+get foo (from origin...) 
+
+100%  20 B              7 KiB/s 0s
+                                  
+(checksum...) ok
+(recording state in git...)
+unannex foo ok
+unannex sha1foo cp: cannot stat '.git/annex/objects/3j/xV/SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa/SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa': No such file or directory
+
+git-annex: sha1foo: getFileStatus: does not exist (No such file or directory)
+failed
+git-annex: unannex: 1 failed
+FAIL (0.63s)
+      Test.hs:511:
+      unannex failed
+
+----------------------------------------------------
+
+    fsck (basics):                                        [adjusted/master(unlocked) 8d7e450] empty
+adjust ok
+(recording state in git...)
+numcopies 2 ok
+(recording state in git...)
+FAIL (0.40s)
+      Test.hs:862:
+      fsck failed to fail with numcopies unsatisfied
+
+----------------------------------------------------
+
+    unannex (no copy):                                    unannex foo cp: cannot stat '.git/annex/objects/Kj/0x/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77': No such file or directory
+
+git-annex: foo: getFileStatus: does not exist (No such file or directory)
+failed
+git-annex: unannex: 1 failed
+FAIL (0.32s)
+      Test.hs:504:
+      unannex failed with no copy
+
+----------------------------------------------------
+
+    unannex (with copy):                                  get foo (from origin...) 
+
+100%  20 B              7 KiB/s 0s
+                                  
+(checksum...) ok
+(recording state in git...)
+unannex foo ok
+unannex sha1foo cp: cannot stat '.git/annex/objects/3j/xV/SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa/SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa': No such file or directory
+
+git-annex: sha1foo: getFileStatus: does not exist (No such file or directory)
+failed
+git-annex: unannex: 1 failed
+FAIL (0.54s)
+      Test.hs:511:
+      unannex failed
+
+----------------------------------------------------
+
+    fsck (basics):                                        (recording state in git...)
+numcopies 2 ok
+(recording state in git...)
+FAIL (0.38s)
+      Test.hs:862:
+      fsck failed to fail with numcopies unsatisfied
+
+----------------------------------------------------
+
+    unannex (no copy):                                    unannex foo cp: cannot stat '.git/annex/objects/Kj/0x/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77': No such file or directory
+
+git-annex: foo: getFileStatus: does not exist (No such file or directory)
+failed
+git-annex: unannex: 1 failed
+FAIL (0.20s)
+      Test.hs:504:
+      unannex failed with no copy
+
+----------------------------------------------------
+
+    unannex (with copy):                                  get foo (from origin...) 
+
+100%  20 B              4 KiB/s 0s
+                                  
+(checksum...) ok
+(recording state in git...)
+unannex foo ok
+unannex sha1foo cp: cannot stat '.git/annex/objects/3j/xV/SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa/SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa': No such file or directory
+
+git-annex: sha1foo: getFileStatus: does not exist (No such file or directory)
+failed
+git-annex: unannex: 1 failed
+FAIL (0.28s)
+      Test.hs:511:
+      unannex failed
+
+----------------------------------------------------
+
+    fsck (basics):                                        (recording state in git...)
+numcopies 2 ok
+(recording state in git...)
+FAIL (0.22s)
+      Test.hs:862:
+      fsck failed to fail with numcopies unsatisfied
+
+----------------------------------------------------
+
+9 out of 837 tests failed (244.85s)
+  (Failures above could be due to a bug in git-annex, or an incompatibility
+   with utilities, such as git, installed on this system.)
+
+```
+
+Edit: Same as
+<https://git-annex.branchable.com/bugs/failing_tests_in_master/>, so
+[[done]]
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
diff --git a/doc/projects/datalad/bugs-done/__39__init_--version__61__N__39___can_land_on_unsupported_N+1.mdwn b/doc/projects/datalad/bugs-done/__39__init_--version__61__N__39___can_land_on_unsupported_N+1.mdwn
new file mode 100644
index 0000000000..12e48c4ebb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__39__init_--version__61__N__39___can_land_on_unsupported_N+1.mdwn
@@ -0,0 +1,53 @@
+I expected `git annex init --version=N`, where N is a version in
+`autoUpgradeableVersions`, to auto-upgrade in a way that lands on a
+supported version.  For example, with a git-annex built from a recent
+master (835a214de), `supportedVersions` contains only 8, and I
+expected
+
+    git init && git annex init --version=6
+
+to result in a v8 repo.  Instead it lands on v7:
+
+    git config annex.version # => 7
+
+Shouldn't the auto-upgrade mapping by `init` be carried all the way
+through until a supported version is reached?
+
+I was able to get the behavior I expected with the change below.
+
+[[!format diff """
+diff --git a/Command/Init.hs b/Command/Init.hs
+index db6cb14fb..ad7ed8962 100644
+--- a/Command/Init.hs
++++ b/Command/Init.hs
+@@ -36,11 +36,15 @@ optParser desc = InitOptions
+ parseRepoVersion :: Monad m => String -> m RepoVersion
+ parseRepoVersion s = case RepoVersion <$> readish s of
+ 	Nothing -> fail $ "version parse error"
+-	Just v
+-		| v `elem` supportedVersions -> return v
+-		| otherwise -> case M.lookup v autoUpgradeableVersions of
+-			Just v' -> return v'
+-			Nothing -> fail $ s ++ " is not a currently supported repository version"
++	Just v -> case check v of
++		Nothing -> fail $ s ++ " is not a currently supported repository version"
++		Just supported -> return supported
++  where
++	check v'
++		| v' `elem` supportedVersions = Just v'
++		| otherwise = case M.lookup v' autoUpgradeableVersions of
++			Just v'' -> check v''
++			Nothing -> Nothing
+ 
+ seek :: InitOptions -> CommandSeek
+ seek = commandAction . start
+"""]]
+
+I'm quite confident that my attempt above is not pretty, but if I got
+lucky and it's passable Haskell, I'd be happy to send a patch.
+
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/__39__init_--version__61__N__39___can_land_on_unsupported_N+1/comment_1_c67521dc54f12efbbf7e13c828775e30._comment b/doc/projects/datalad/bugs-done/__39__init_--version__61__N__39___can_land_on_unsupported_N+1/comment_1_c67521dc54f12efbbf7e13c828775e30._comment
new file mode 100644
index 0000000000..70e8078282
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__39__init_--version__61__N__39___can_land_on_unsupported_N+1/comment_1_c67521dc54f12efbbf7e13c828775e30._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-24T17:13:45Z"
+ content="""
+Your patch is perfectly fine haskell code.
+
+But, looking at it, the problem is deeper than init --version.
+Running git-annex in a v3 repo produces a v5 repo,
+then running git-annex again produces a v6 repo,
+then v7, then v8.
+
+So the problem is really that autoUpgradeableVersions
+should map everything to latestVersion. At least currently,
+since all versions should be upgraded to v8.
+
+(Really it could just be a list of versions that all
+are assumed to upgrade to latestVersion, but I left it a map
+in case at some point there are two concurrent version
+tracks without an autoupgrade between them.)
+
+Anyway, attach a git format-patch next time so I can git am it. :)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/__39__init_--version__61__N__39___can_land_on_unsupported_N+1/comment_2_d65fc129524c92fa1c783d8dbc516f5f._comment b/doc/projects/datalad/bugs-done/__39__init_--version__61__N__39___can_land_on_unsupported_N+1/comment_2_d65fc129524c92fa1c783d8dbc516f5f._comment
new file mode 100644
index 0000000000..67f2552aba
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/__39__init_--version__61__N__39___can_land_on_unsupported_N+1/comment_2_d65fc129524c92fa1c783d8dbc516f5f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="thanks"
+ date="2020-02-25T01:20:33Z"
+ content="""
+Great, thank you for the fix!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__.mdwn b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__.mdwn
new file mode 100644
index 0000000000..c22436a01d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+
+Our datalad tests started to fail on 04 Aug 2022  build of git-annex.  `git bisect` brought me to the [10.20220724-56-g3a513cfe7](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=3a513cfe73ed873aeeabbc17d2c458b62dd4198c) change which added `--dry-run` to `annex add`.  The "regression" manifests in that we end up with a file not added/committed.  Unfortunately I do not have yet more details or git-annex minimal reproducer.
+
+Meanwhile - the full log from running `DATALAD_LOG_OUTPUTS=1 DATALAD_LOG_LEVEL=DEBUG python -m pytest -s -v datalad/local/tests/test_add_archive_content.py::test_add_archive_content `
+
+[http://www.onerussian.com/tmp/test_add_archive_content-fail.log](http://www.onerussian.com/tmp/test_add_archive_content-fail.log)
+
+and it has
+
+
+```shell
+$> grep '2/1_f.txt\>' /tmp/test_add_archive_content-fail.log                                                                                                                                       
+[DEBUG] Adding /home/yoh/.tmp/datalad_temp_test_add_archive_contentxyf002ii/2/1_f.txt to annex pointing to dl+archive:MD5E-s151--eb922c8b7151d0c53f56e03c10bb0e70.tar.gz#path=1/1+f.txt&size=8 and with options ['-c', 'annex.largefiles=exclude=*.txt'] 
+[DEBUG] File /home/yoh/.tmp/datalad_temp_test_add_archive_contentxyf002ii/2/1_f.txt was added to git, not adding url 
+first = '2/1_f.txt'
+E           AssertionError: assert '2/1_f.txt' in ['.datalad/.gitattributes', '.datalad/config', '.gitattributes', '1/1 f-1.1.txt', '1/1 f-1.2.txt', '1/1 f-1.txt', ...]
+DEBUG    datalad.local.add_archive_content:add_archive_content.py:609 Adding /home/yoh/.tmp/datalad_temp_test_add_archive_contentxyf002ii/2/1_f.txt to annex pointing to dl+archive:MD5E-s151--eb922c8b7151d0c53f56e03c10bb0e70.tar.gz#path=1/1+f.txt&size=8 and with options ['-c', 'annex.largefiles=exclude=*.txt']
+DEBUG    datalad.local.add_archive_content:add_archive_content.py:627 File /home/yoh/.tmp/datalad_temp_test_add_archive_contentxyf002ii/2/1_f.txt was added to git, not adding url
+```
+
+so git-annex seems reported that it was added to `git` but if we stop in (another run) at that point and look at the repo we see that it was not added:
+
+```
+$> DATALAD_TESTS_TEMP_KEEP=1 DATALAD_LOG_OUTPUTS=1 DATALAD_LOG_LEVEL=DEBUG python -m pytest -s -v --pdb datalad/local/tests/test_add_archive_content.py::test_add_archive_content
+...
+DEBUG    datalad.runner.runner:runner.py:171 Run ['git', '-c', 'diff.ignoreSubmodules=none', 'annex', 'addurl', '-c', 'annex.largefiles=exclude=*.txt', '--with-files', '--json', '--json-error-messages', '--batch'] (protocol_class=BatchedCommandProtocol) (cwd=/home/yoh/.tmp/datalad_temp_test_add_archive_content0r8qsr6l)
+DEBUG    datalad.local.add_archive_content:add_archive_content.py:627 File /home/yoh/.tmp/datalad_temp_test_add_archive_content0r8qsr6l/2/1_f.txt was added to git, not adding url
+INFO     datalad.local.add_archive_content:log.py:431 Files to extract 0 
+DEBUG    datalad.local.add_archive_content:add_archive_content.py:506 Skipping 1/d/1d since contains d pattern
+DEBUG    datalad.local.add_archive_content:add_archive_content.py:641 Removing the original archive 1.tar.gz
+...
+
+```
+
+and if we go to that folder -- we see that `2/` was not added to git:
+
+```
+(git-annex)lena:~/.tmp/datalad_temp_test_add_archive_content0r8qsr6l[dl-test-branch]
+$> git status
+On branch dl-test-branch
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+	2/
+
+nothing added to commit but untracked files present (use "git add" to track)
+
+$> ls 2/
+1_f.txt
+
+$> ls .git/annex/journal/
+# came out empty, FWIW
+```
+
+Versions: annexremote=1.6.0 boto=2.49.0 cmd:7z=16.02 cmd:annex=10.20220724+git77-ga24ae0814-1~ndall+1 cmd:bundled-git=2.30.2 cmd:git=2.30.2 cmd:ssh=9.0p1 cmd:system-git=2.35.1 cmd:system-ssh=9.0p1 datalad=0.17.2+75.g3bc853bb2 exifread=3.0.0 humanize=4.2.3 iso8601=1.0.2 keyring=23.6.0 keyrings.alt=UNKNOWN msgpack=1.0.4 mutagen=1.45.1 platformdirs=2.5.2 requests=2.28.1 tqdm=4.64.0
+
+I will try to dig deeper some time later, unless you Joey immediately see what could be a culprit or recommend something specific to try
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_1_0bc5a3d36900d9bd8c978a08383d409d._comment b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_1_0bc5a3d36900d9bd8c978a08383d409d._comment
new file mode 100644
index 0000000000..59f1771bae
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_1_0bc5a3d36900d9bd8c978a08383d409d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-09T16:41:59Z"
+ content="""
+Unable to reproduce such a problem using git-annex so far. (I don't know how
+to set up an enviroment to run that case of the datalad test suite.)
+
+Also I don't see any obvious logic error in the code of that commit.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_2_ecc658185b485a5ccaf592ab8a255241._comment b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_2_ecc658185b485a5ccaf592ab8a255241._comment
new file mode 100644
index 0000000000..9756e69a13
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_2_ecc658185b485a5ccaf592ab8a255241._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-08-09T17:19:56Z"
+ content="""
+For future reference, I was able to run the test suite by cloning datalad,
+and settup up the virtualenv like in the README, except then running "pip
+install ." in the datalad directory.
+
+I reproduced the datalad test failure. Then I wrapped git-annex with a
+script that logs the paramters it was run with. It seems the test is 
+running git-annex addurl, not git-annex add at all. So maybe that commit
+broke addurl?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_3_38baec012d7ebc95f92df59c85c6d525._comment b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_3_38baec012d7ebc95f92df59c85c6d525._comment
new file mode 100644
index 0000000000..57f2c8d5b0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_3_38baec012d7ebc95f92df59c85c6d525._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-08-09T17:22:52Z"
+ content="""
+In particular, the test runs:
+
+	git-annex addurl -c annex.largefiles=exclude=*.txt --with-files --json --json-error-messages --batch
+
+It never runs git-annex add.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_4_ee9f695290b1bcaf2c9320d8042047cc._comment b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_4_ee9f695290b1bcaf2c9320d8042047cc._comment
new file mode 100644
index 0000000000..8ef220c9f4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_4_ee9f695290b1bcaf2c9320d8042047cc._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-08-09T17:35:46Z"
+ content="""
+Found the bug.. it is in the change to Command.AddUrl. Since addSmall
+changed to a CommandPerform, `void $ Command.Add.addSmall ...` only
+now runs the first part of it, but not the action that returns that
+actually adds the file to git! The `void` causes that to get thrown
+away. Easily fixed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_5_3fb410419608d725ea15a4849266396e._comment b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_5_3fb410419608d725ea15a4849266396e._comment
new file mode 100644
index 0000000000..c447f64031
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_5_3fb410419608d725ea15a4849266396e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2022-08-09T18:02:08Z"
+ content="""
+Thank you Joey! FTR, fixed in [10.20220724-96-g21cfd0ea9](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=21cfd0ea980feaec8875380707c1a1ddb91de5dc)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_6_2455f440750a285768746e764fbfb9cd._comment b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_6_2455f440750a285768746e764fbfb9cd._comment
new file mode 100644
index 0000000000..6277a04f30
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_6_2455f440750a285768746e764fbfb9cd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2022-08-09T18:02:32Z"
+ content="""
+Thank you Joey! FTR, fixed in [10.20220724-96-g21cfd0ea9](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=21cfd0ea980feaec8875380707c1a1ddb91de5dc)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_7_c8f6ee2cb993b22b2531d1a4b7c3da8e._comment b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_7_c8f6ee2cb993b22b2531d1a4b7c3da8e._comment
new file mode 100644
index 0000000000..c73080b432
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/add_--dry-run_seems_have_introduced_a___34__regression__34__/comment_7_c8f6ee2cb993b22b2531d1a4b7c3da8e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2022-08-09T19:12:40Z"
+ content="""
+BTW -- well done on:
+
+> For future reference, I was able to run the test suite by cloning datalad, and settup up the virtualenv like in the README, except then running \"pip install .\" in the datalad directory.
+
+FTR: There is also [CONTRIBUTING.md](https://github.com/datalad/datalad/blob/HEAD/CONTRIBUTING.md#development-environment) with more \"development oriented\" instructions for installation etc.  Might come handy.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/add_--force-small_fails_on_modified_submodules.mdwn b/doc/projects/datalad/bugs-done/add_--force-small_fails_on_modified_submodules.mdwn
new file mode 100644
index 0000000000..57d13efefe
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/add_--force-small_fails_on_modified_submodules.mdwn
@@ -0,0 +1,128 @@
+Passing a modified submodule to `git annex --force-small` triggers a
+failure:
+
+[[!format sh """
+cd "$(mktemp -d --tmpdir gx-XXXXXXX)"
+git init
+git annex init
+git init sub
+git -C sub commit --allow-empty -m"c0"
+git submodule add ./sub
+
+git -C sub commit --allow-empty -m"c1"
+git commit -m'sub change'
+git annex add --force-small sub
+"""]]
+
+```
+[...]
+add sub (adding content to git repository) fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+
+git-annex: fd:18: hGetLine: end of file
+failed
+git-annex: user error (git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"] exited 128)
+```
+
+The demo above passes a submodule to `annex add`, but the more
+realistic scenario would be passing a directory (most likely ".") that
+happens to include a modified submodule.
+
+The failure is happening when `addSmallOverridden` calls `hash-object`
+with the submodule path.  As far as I can see, `addSmallOverridden`
+will only receive a directory if the path in question is a submodule
+(based on ls-files not traversing into submodules).  So, perhaps an
+appropriate fix is to go through `addFile` rather
+`hash-object/update-index` when the file is a directory.  I've
+included a patch to do that below.  The first patch is for an issue in
+`addSmallOverridden` that I noticed when making the change.
+
+[[!format patch """
+From 58b5a1acf7dfe305b9284cf3423a58853c13451a Mon Sep 17 00:00:00 2001
+From: Kyle Meyer <kyle@kyleam.com>
+Date: Mon, 23 Mar 2020 15:45:15 -0400
+Subject: [PATCH 1/2] add --force-small: Don't dereference link when checking
+ file status
+
+addSmallOverridden calls getFileStatus and then checks the result with
+isSymbolicLink.  getFileStatus dereferences symbolic links, so
+isSymbolicLink will always return false (assuming the getFileStatus
+call doesn't fail on a broken link).  Use getSymbolicLinkStatus
+instead.
+---
+ Command/Add.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Command/Add.hs b/Command/Add.hs
+index e142aac0b..56e6fb236 100644
+--- a/Command/Add.hs
++++ b/Command/Add.hs
+@@ -107,7 +107,7 @@ addSmallOverridden :: RawFilePath -> Annex Bool
+ addSmallOverridden file = do
+ 	showNote "adding content to git repository"
+ 	let file' = fromRawFilePath file
+-	s <- liftIO $ getFileStatus file'
++	s <- liftIO $ getSymbolicLinkStatus file'
+ 	if isSymbolicLink s
+ 		then addFile file 
+ 		else do
+-- 
+2.25.1
+
+"""]]
+
+[[!format patch """
+From c823d69a7b477f770fe539a74b788b61df173a76 Mon Sep 17 00:00:00 2001
+From: Kyle Meyer <kyle@kyleam.com>
+Date: Mon, 23 Mar 2020 15:45:15 -0400
+Subject: [PATCH 2/2] add --force-small: Send all non-regular files through
+ addFile
+
+Running `git annex add --force-small` on a modified submodule fails
+when the submodule path is fed to hash-object.  This failure is
+unlikely to be triggered by a caller passing a submodule explicitly to
+`git annex add` because there's nothing useful that annex-add can do
+with a submodule.  A more likely scenario for hitting this failure is
+that the caller passes "." or a subdirectory to `annex-add` while a
+submodule underneath the specified path happens to be modified.
+
+addSmallOverridden already routes symbolic links through addFile
+rather than using the custom hash-object/update-index call.  The
+latter is valid only for regular files, so extend this condition so
+that everything that isn't a regular file goes through addFile.  Doing
+so avoids the above error because submodules come in as directories.
+---
+ Command/Add.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Command/Add.hs b/Command/Add.hs
+index 56e6fb236..72aae5f3c 100644
+--- a/Command/Add.hs
++++ b/Command/Add.hs
+@@ -108,7 +108,7 @@ addSmallOverridden file = do
+ 	showNote "adding content to git repository"
+ 	let file' = fromRawFilePath file
+ 	s <- liftIO $ getSymbolicLinkStatus file'
+-	if isSymbolicLink s
++	if not (isRegularFile s)
+ 		then addFile file 
+ 		else do
+ 			-- Can't use addFile because the clean filter will
+-- 
+2.25.1
+
+"""]]
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[applied|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/add_--force-small_fails_on_modified_submodules/comment_1_95e4a43684338e28a74b6df8d2e5281a._comment b/doc/projects/datalad/bugs-done/add_--force-small_fails_on_modified_submodules/comment_1_95e4a43684338e28a74b6df8d2e5281a._comment
new file mode 100644
index 0000000000..eb7d186562
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/add_--force-small_fails_on_modified_submodules/comment_1_95e4a43684338e28a74b6df8d2e5281a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-26T17:15:02Z"
+ content="""
+Really well done, thank you. Applied both.
+
+About the only thing I have to add is, I wonder if it would be better for 
+--force-small to just temporarily disable the clean filter and always
+use git add. Seems that might be less likely to run into this kind of
+breakage. OTOH, it looks like you've found all the possible bugs in it
+already... So I suppose I'll wait until the next bug is found in it to
+think about doing that. ;-)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn b/doc/projects/datalad/bugs-done/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn
new file mode 100644
index 0000000000..8336cb9934
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn
@@ -0,0 +1,42 @@
+### Please describe the problem.
+
+When addurl'ing a big file with .gitattributes configured to add only some files directly into git (and 'git annex add' operating correctly), addurl adds large files straight into git.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 6.20161018+gitgf3c366a-1~ndall+1
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> cat .gitattributes 
+* annex.backend=MD5E
+* annex.largefiles=(largerthan=100kb)
+*.json annex.largefiles=nothing
+*.txt annex.largefiles=nothing
+*.tsv annex.largefiles=nothing
+*.nii.gz annex.largefiles=(largerthan=0kb)
+*.tgz annex.largefiles=(largerthan=0kb)
+*.tar.gz annex.largefiles=(largerthan=0kb)
+*.gz annex.largefiles=(largerthan=0kb)
+
+$> git annex addurl http://fcp-indi.s3.amazonaws.com/data/Projects/HBNSSI/RawDataTars/sub-0031121_baseline.tar.gz\?versionId\=7FvexHgyazWF.dUo238FA7XRiK0FWQDw.
+addurl fcp_indi.s3.amazonaws.com_data_Projects_HBNSSI_RawDataTars_sub_0031121_baseline.tar.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. (downloading http://fcp-indi.s3.amazonaws.com/data/Projects/HBNSSI/RawDataTars/sub-0031121_baseline.tar.gz?versionId=7FvexHgyazWF.dUo238FA7XRiK0FWQDw. ...) 
+/mnt/btrfs/datasets/datalad/crawl-misc/indi/ 100%[==============================================================================================>] 195.44M  21.2MB/s    in 12s     
+(non-large file; adding content to git repository) ok
+(recording state in git...)
+cached/staged changes:                                                                                                                                                              
+ \u2026r.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. | Bin 0 -> 204937338 bytes
+
+$> ls -l fcp_indi.s3.amazonaws.com_data_Projects_HBNSSI_RawDataTars_sub_0031121_baseline.tar.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. 
+-rw------- 1 yoh datalad 204937338 Oct 25 17:30 fcp_indi.s3.amazonaws.com_data_Projects_HBNSSI_RawDataTars_sub_0031121_baseline.tar.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw.
+cached/staged changes:                                                                                                                                                              
+ \u2026r.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. | Bin 0 -> 204937338 bytes
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed.mdwn b/doc/projects/datalad/bugs-done/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed.mdwn
new file mode 100644
index 0000000000..d3ceb2f22a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed.mdwn
@@ -0,0 +1,99 @@
+### Please describe the problem.
+
+only happens if file doesn't exist yet and gets downloaded (interestingly, as I reported in another report, if file exists it gets re-downloaded but this bug doesn't repeat)
+
+[[!format sh """
+
+$> chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init;                                                 
+Initialized empty Git repository in /tmp/123/.git/
+init  ok
+(recording state in git...)
+
+$> mkfifo /tmp/pipe
+
+$> cat /tmp/pipe | git annex --debug addurl --batch --with-files                
+^Z                                                               
+[2]  + 1084 suspended  cat /tmp/pipe | 
+       1085 suspended  git annex --debug addurl --batch --with-files
+
+$> bg
+[2]  - 1084 continued  cat /tmp/pipe | 
+       1085 continued  git annex --debug addurl --batch --with-files
+
+$> exec 3>/tmp/pipe
+
+$> echo "http://www.onerussian.com/tmp/banner.png banner.png" >&3                                                
+[2016-01-11 22:25:34.423037] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]                                                                                    
+[2016-01-11 22:25:34.427649] process done ExitSuccess
+[2016-01-11 22:25:34.428067] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2016-01-11 22:25:34.432199] process done ExitSuccess
+
+$> [2016-01-11 22:25:34.432834] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..87efc349dceb06df635c8485ef536ae11f48736c","-n1","--pretty=%H"]
+[2016-01-11 22:25:34.438533] process done ExitSuccess
+[2016-01-11 22:25:34.439666] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2016-01-11 22:25:34.444875] read: quvi ["--version"]
+[2016-01-11 22:25:34.452158] process done ExitSuccess
+[2016-01-11 22:25:34.452563] call: quvi ["--verbosity","mute","--support","http://www.onerussian.com/tmp/banner.png"]
+[2016-01-11 22:25:34.468071] process done ExitFailure 65
+addurl banner.png (downloading http://www.onerussian.com/tmp/banner.png ...) 
+[2016-01-11 22:25:34.500939] call: wget ["-q","--show-progress","--clobber","-c","-O","/tmp/123/.git/annex/tmp/URL-s25319--http&c%%www.onerussian.com%tmp%banner.png","http://www.onerussian.com/tmp/banner.png","--user-agent","git-annex/6.20160104+gitg0cf96be-1~ndall+1"]
+/tmp/123/.git/annex/tmp/URL-s25319--http&c%%www.on 100%[==============================================================================================================>]  24.73K  --.-KB/s    in 0s      
+[2016-01-11 22:25:34.518335] process done ExitSuccess
+[2016-01-11 22:25:34.519195] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","--"]
+[2016-01-11 22:25:34.5241] read: git ["--version"]
+[2016-01-11 22:25:34.527001] process done ExitSuccess
+ok
+
+$> git status  # note that file is untracked, although it is a symlink into .git/annex/objects
+On branch master
+
+Initial commit
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+
+	banner.png
+
+nothing added to commit but untracked files present (use "git add" to track)
+
+$> # closing the pipe now
+$> exec 3>&-
+(recording state in git...)                                                                                                                                                                               
+[2016-01-11 22:26:02.947133] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"]
+$> [2016-01-11 22:26:02.95701] process done ExitSuccess
+[2016-01-11 22:26:02.961588] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]
+[2016-01-11 22:26:02.964507] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+[2016-01-11 22:26:02.971853] process done ExitSuccess
+[2016-01-11 22:26:02.972524] process done ExitSuccess
+[2016-01-11 22:26:02.973043] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2016-01-11 22:26:02.975871] process done ExitSuccess
+[2016-01-11 22:26:02.977613] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2016-01-11 22:26:02.982308] process done ExitSuccess
+[2016-01-11 22:26:02.982744] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","0b4d294f555bc86c17de89bca35193433408bbef","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2016-01-11 22:26:02.990485] process done ExitSuccess
+[2016-01-11 22:26:02.990941] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","1359dc4d9296bc4f5941e7299376319899ea222c"]
+[2016-01-11 22:26:02.995434] process done ExitSuccess
+
+[2]  - 1084 done       cat /tmp/pipe | 
+       1085 done       git annex --debug addurl --batch --with-files
+
+$> git status
+On branch master
+
+Initial commit
+
+Changes to be committed:
+  (use "git rm --cached <file>..." to unstage)
+
+	new file:   banner.png
+
+$> git annex version
+git-annex version: 6.20160104+gitg0cf96be-1~ndall+1
+...
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> closing as not a bug [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists.mdwn b/doc/projects/datalad/bugs-done/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists.mdwn
new file mode 100644
index 0000000000..509ba95de1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists.mdwn
@@ -0,0 +1,22 @@
+### Please describe the problem.
+
+Complained elsewhere (http://git-annex.branchable.com/bugs/inconsistent_output_upon_addurl_--batch_complicates_if_not_forbids_reliable_parsing_of_output/) haven't mentioned it was marked fixed, so reiterating as independent bugreport
+
+With today's version
+[[!format sh """
+
+$> echo "http://www.onerussian.com/tmp/banner.png 123" | git annex addurl --batch --with-files
+addurl 123 git-annex: 123 already exists and is not annexed; not overwriting                  
+
+$> echo "http://www.onerussian.com/tmp/banner.png 123" | git annex addurl --batch --with-files 2>/dev/null
+addurl 123 %       
+
+$> echo "http://www.onerussian.com/tmp/banner.png 123" | git annex addurl --batch --with-files --json 2>/dev/null 
+{"command":"addurl","file":"123"% 
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn b/doc/projects/datalad/bugs-done/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
new file mode 100644
index 0000000000..6987f932fc
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
@@ -0,0 +1,22 @@
+### What version of git-annex are you using? On what operating system?
+
+6.20160425+gitgffe2ea2-1~ndall+1
+(reconfirmed with 6.20160523+gitg33c00ab-1~ndall+1)
+
+### Please provide any additional information below.
+Here is a debug output from datalad which shows the interaction
+
+[[!format sh """
+2016-05-23 16:41:59,955 [DEBUG  ] Initiating a new process for BatchedAnnex(annex_cmd='addurl', annex_options=<<['-c', 'annex.largefil...>>, git_options=[], output_proc=<function>, path=<<'/mnt/btrfs/datasets/d...>>) (annexrepo.py:1177)
+2016-05-23 16:41:59,956 [Level 5] Command: ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'addurl', '-c', 'annex.largefiles=exclude=Makefile and exclude=LICENSE* and exclude=ISSUES* and exclude=CHANGES* and exclude=README* and exclude=*.[mc] and exclude=dataset*.json and (exclude=*.txt or include=*/*.txt) and (exclude=*.json or include=*/*.json) and (exclude=*.tsv or include=*/*.tsv)', '--with-files', '--json', '--batch'] (annexrepo.py:1180)
+2016-05-23 16:41:59,967 [Level 5] Sending u'http://openfmri.s3.amazonaws.com/tarballs/ds052_R2.0.0_metadata_derivatives.tgz?versionId=nrIMjS3lH6TMoSkA.27U.Md_k2BSva3i ds052_R2.0.0_metadata_derivatives.tgz\n' to batched annex BatchedAnnex(annex_cmd='addurl', annex_options=<<['-c', 'annex.largefil...>>, git_options=[], output_proc=<function>, path=<<'/mnt/btrfs/datasets/d...>>) (annexrepo.py:1234)
+2016-05-23 16:41:59,968 [Level 5] Done sending. (annexrepo.py:1242)
+yoh@datasets.datalad.org's password: 
+"""]]
+
+That repository indeed has a remote (ssh) setup pointing to datasets.datalad.org (which carries no load for annex, besides git-annex repository, ATM), but that remote should not be consulted IMHO for addurl operation (not to mention in the --batch mode shouldn't request any user interaction)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/addurl_--file__causes_file_redownload_even_if_it_already_present.mdwn b/doc/projects/datalad/bugs-done/addurl_--file__causes_file_redownload_even_if_it_already_present.mdwn
new file mode 100644
index 0000000000..167ca68698
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/addurl_--file__causes_file_redownload_even_if_it_already_present.mdwn
@@ -0,0 +1,33 @@
+### Please describe the problem.
+
+IMHO annex shouldn't redownload the file (not yet under annex/git control) entirely if pointed by --file=FILE FILE exists.  
+
+[[!format sh """
+
+$> chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init;                                            
+Initialized empty Git repository in /tmp/123/.git/                                               
+init  ok
+
+$> wget -q http://www.onerussian.com/tmp/banner.png                                  
+
+$> ls -l 
+total 28
+-rw------- 1 yoh yoh 25319 Sep 17 13:49 banner.png
+
+$> git annex addurl --file=banner.png http://www.onerussian.com/tmp/banner.png
+addurl banner.png (downloading http://www.onerussian.com/tmp/banner.png ...) 
+/tmp/123/.git/annex/tmp/URL-s25319--http&c%%w 100%[=================================================================================================>]  24.73K  --.-KB/s    in 0.003s  
+ok
+
+$> git annex version
+git-annex version: 6.20160104+gitg0cf96be-1~ndall+1
+
+"""]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> I don't think that the re-download is the bug. The actual problem
+> is that the file is present and not an annexed file, so git-annex addurl
+> should avoid overwriting it, whatever its content. [[fixed|done]]
+> --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/annex-ssh-options_dropped_since_8.20200330.mdwn b/doc/projects/datalad/bugs-done/annex-ssh-options_dropped_since_8.20200330.mdwn
new file mode 100644
index 0000000000..084eacd001
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex-ssh-options_dropped_since_8.20200330.mdwn
@@ -0,0 +1,50 @@
+When debugging some ssh-related datalad tests that hang with newer
+git-annex versions, I noticed that there was a regression in the
+treatment of annex-ssh-options in c8fec6ab0 (Fix a minor bug that
+caused options provided with -c to be passed multiple times to git,
+2020-03-16).
+
+Here's a demo script.  Pointing `SSHURL` to any ssh-accessible annex
+repo should do.  In the case below, the target is an annex repo with
+one commit and no files in the working tree.
+
+[[!format sh """
+SSHURL="smaug:/home/kyle/scratch/repo"
+
+cd "$(mktemp -d ${TMPDIR:-/tmp}/gx-ssh-opts-XXXXXXX)"
+git clone "$SSHURL" ./ >/dev/null 2>&1
+git annex init \
+    -c annex.sshcaching=false \
+    -c remote.origin.annex-ssh-options="-o ControlMaster=auto -S CACHE" \
+    --debug 2>&1 | grep 'read: ssh'
+"""]]
+
+With the parent of the above commit checked out (b166223d4), the
+script outputs
+
+```
+[2020-06-30 11:09:43.853918422] read: ssh ["smaug","-o","ControlMaster=auto","-S","CACHE","-n","-T","git-annex-shell 'configlist' '/home/kyle/scratch/repo' '--debug'"]
+```
+
+With c8fec6ab0 checked out, it outputs
+
+```
+[2020-06-30 11:11:03.833678263] read: ssh ["smaug","-S",".git/annex/ssh/smaug","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","git-annex-shell 'configlist' '/home/kyle/scratch/repo' '--debug'"]
+[2020-06-30 11:11:04.448046366] read: ssh ["-O","stop","-S","smaug","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
+```
+
+It looks like the options specified via
+`remote.origin.annex-ssh-options` are dropped, and git-annex switches
+to using its built-in ssh caching.
+
+A recent commit on master (95b8b4a5a) shows the same behavior.
+
+I've tried to work through the config-related handling and understand
+why the condition from c8fec6ab0 results in the ssh options being
+dropped, but I haven't made any progress yet.
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] (also re-fixed the original bug in a better way)
+> --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/annex-ssh-options_dropped_since_8.20200330/comment_1_2ba303f406a0be7c3bb4a8466ce4b9c3._comment b/doc/projects/datalad/bugs-done/annex-ssh-options_dropped_since_8.20200330/comment_1_2ba303f406a0be7c3bb4a8466ce4b9c3._comment
new file mode 100644
index 0000000000..e5b230d7e9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex-ssh-options_dropped_since_8.20200330/comment_1_2ba303f406a0be7c3bb4a8466ce4b9c3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-07-02T16:30:03Z"
+ content="""
+Yeah, this adjustGitRepo that re-runs the code repeatedly sometimes is very
+hard to understand and I guess needs to be redone entirely somehow.
+
+I've reverted the commit, reopened the old bug which I prefer to this one.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex-ssh-options_dropped_since_8.20200330/comment_2_d3fdcfe9e75f2fa6a7c4d12e318455db._comment b/doc/projects/datalad/bugs-done/annex-ssh-options_dropped_since_8.20200330/comment_2_d3fdcfe9e75f2fa6a7c4d12e318455db._comment
new file mode 100644
index 0000000000..d69f6737ac
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex-ssh-options_dropped_since_8.20200330/comment_2_d3fdcfe9e75f2fa6a7c4d12e318455db._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 2"
+ date="2020-07-02T20:07:10Z"
+ content="""
+Thank you!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_.mdwn b/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_.mdwn
new file mode 100644
index 0000000000..7330e8f427
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_.mdwn
@@ -0,0 +1,113 @@
+### Please describe the problem.
+
+the goal was to have files unlocked (no symlinks) and gain "efficient" clone which would not consume more space through hardlinks.
+But if mode is thin in the clone - we get a copy within the clone
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+
+#!/bin/bash
+
+export PS4='> '
+set -x
+set -eu
+cd "$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)"
+
+git annex version | head -n 1
+(
+mkdir src
+cd src
+git init
+git annex init
+git commit --allow-empty -m empty
+
+git annex adjust --unlock
+git config annex.thin true
+
+touch 123 
+git annex add 123
+git commit -m 123 123
+)
+
+git clone --shared src dest
+
+(
+cd dest
+# without it it would stall in "get" call 
+# https://git-annex.branchable.com/bugs/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/
+git annex init
+git config annex.thin true
+git annex get 123
+)
+
+: are inodes the same?
+ls -lLi {dest,src}/{123,.git/annex/objects/*/*/*/*}
+"""]]
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> bash check-annex-thin-hardlink.sh
+> set -eu
+>> mktemp -d /home/yoh/.tmp/dl-XXXXXXX
+> cd /home/yoh/.tmp/dl-je8JzWt
+> git annex version
+> head -n 1
+git-annex version: 8.20200810+git47-g27329f0bb-1~ndall+1
+> mkdir src
+> cd src
+> git init
+Initialized empty Git repository in /home/yoh/.tmp/dl-je8JzWt/src/.git/
+> git annex init
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
+> git commit --allow-empty -m empty
+[master (root-commit) be447d9] empty
+> git annex adjust --unlock
+adjust 
+Switched to branch 'adjusted/master(unlocked)'
+ok
+> git config annex.thin true
+> touch 123
+> git annex add 123
+add 123 
+ok
+(recording state in git...)
+> git commit -m 123 123
+[adjusted/master(unlocked) c5db915] 123
+ 1 file changed, 1 insertion(+)
+ create mode 100644 123
+> git clone --shared src dest
+Cloning into 'dest'...
+done.
+> cd dest
+> git annex init
+init  (merging origin/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+
+  Repository was cloned with --shared; setting annex.hardlink=true and making repository untrusted.
+ok
+(recording state in git...)
+> git config annex.thin true
+> git annex get 123
+get 123 (from origin...) 
+(checksum...) ok
+(recording state in git...)
+> : are inodes the 'same?'
+> ls -lLi dest/123 dest/.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 src/123 src/.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+49711952 -rw------- 2 yoh yoh 0 Aug 25 11:04 dest/123
+49711952 -rw------- 2 yoh yoh 0 Aug 25 11:04 dest/.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+49711742 -rw------- 2 yoh yoh 0 Aug 25 11:04 src/123
+49711742 -rw------- 2 yoh yoh 0 Aug 25 11:04 src/.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]], it seems that my documentation improvement is the only thing
+> that needed to be done for this. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_1_cc1417bb8173e3b2636d465967a704d9._comment b/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_1_cc1417bb8173e3b2636d465967a704d9._comment
new file mode 100644
index 0000000000..a59d60f83a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_1_cc1417bb8173e3b2636d465967a704d9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 1"
+ date="2020-08-25T15:20:45Z"
+ content="""
+I believe this is by design.  See ecd0684bf (avoid hard linking object
+from other repository when annex.thin is set, 2016-01-13).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_2_60ab40449991dbb3f64d08f01c5458c4._comment b/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_2_60ab40449991dbb3f64d08f01c5458c4._comment
new file mode 100644
index 0000000000..80fe2b7cce
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_2_60ab40449991dbb3f64d08f01c5458c4._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-08-25T17:01:55Z"
+ content="""
+That is the relevant commit indeed.
+
+We have two different things that want to hard link a file for different
+purposes. The purposes are not compatible. So one of them has to win out.
+
+If both annex.hardlink and annex.thin were both allowed to hard link the
+same file, then a file could get a link count of more than 2. That would
+prevent using the method that annex.thin relies on to avoid two unlocked
+files with the same content ending up hard linked together. With the very
+undesirable result that an edit to one file would also edit the other file.
+
+Now, I could imagine using some other thing than link count to avoid that
+situation, eg keep track of when two files have the same content. But
+there's a second similar problem: If a file were unlocked in one repo and
+that repos's annex/objects also hard linked to its remote's annex/objects,
+then editing the file in the first repo would corrupt the object content in
+the other repo.
+
+So I think the only other possible way for it to work would be for which
+ever of the two caused a hard link to be made first to win, rather than
+annex.thin always winning as it does now. So, after a `git annex get` in
+the clone hard linked the file (annex.hardlink wins), `git annex unlock`
+would copy the file (annex.thin loses). While a `git add` would hard link
+the file to annex/objects (annex.thin wins), resulting in `git annex copy
+--to origin` having to copy the file (annex.hardlink loses).
+
+But that would not change the behavior in your test case,
+since it needs to get the file (annex.hardlink wins) before unlocking
+it (annex.thin loses).
+
+So the benefit of making that change seems small to nonexistent as far as
+this bug report goes. Behavior becomes less consistent, it has to work
+harder to enforce the link count invariant, and it doesn't actually change
+the test case. The only real benefit would be when some files are not
+unlocked, but annex.thin is set, since then the locked files could be
+hardlinked.
+
+----
+
+I added a note to the annex.hardlink docs about annex.thin winning and am
+inclined to only do that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_3_86e8f44191a004da20db8e97577744a9._comment b/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_3_86e8f44191a004da20db8e97577744a9._comment
new file mode 100644
index 0000000000..046bc611ac
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_3_86e8f44191a004da20db8e97577744a9._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="dreaming of everyone using CoW FSs"
+ date="2020-08-26T01:26:28Z"
+ content="""
+Thank you Joey for looking into it!  I only wish that all file systems were CoW so we could quickly \"clone/get\" any amount of data without jeopardizing data as is the case with hardlinks and also that software did not follow symlinks all the way into the .git/annex/objects (which remains the issue even with browsers etc).  
+But unfortunately it is not the case and that is why we breed all the workarounds to fulfill the use-cases.
+For a \"consumer\" who is not intending to modify any of the original hardlinked files -- do you see any other way to get a \"quick\" clone of a heavy in GBs (or TBs) repository without somehow \"marrying\" shared+thin?
+May be for data protection there could be some \"read-only-thin\" mode which would make all annexed files read-only (thus in the original and clone) repositories thus making it \"safe\" (somewhat) to have inodes with more than 2 hardlinks? 
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_4_d6039a6d2df740600e98b50fe90fbdfb._comment b/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_4_d6039a6d2df740600e98b50fe90fbdfb._comment
new file mode 100644
index 0000000000..d6ef40bc98
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex.hardlink_is_not___34__in_effect__34___in_thin_mode_/comment_4_d6039a6d2df740600e98b50fe90fbdfb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-08-26T17:07:49Z"
+ content="""
+`git annex adjust --lock` seems like it would accomplish that.
+
+Unless symlinks don't work for some reason on this filesystem, but I don't
+think there are any where hard links work and symlinks don't.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_add_ignores_.-prefixed_directories.mdwn b/doc/projects/datalad/bugs-done/annex_add_ignores_.-prefixed_directories.mdwn
new file mode 100644
index 0000000000..52e4068385
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_add_ignores_.-prefixed_directories.mdwn
@@ -0,0 +1,79 @@
+### Please describe the problem.
+
+annex add  seems to ignore content under directories having . prefix.
+
+We thought to unify (across direct/indirect/v6) adding files to annex repository by using 'git annex add' with corresponding setting for largefiles for any addition, but it seems to ignore content under .-prefixed directories, unlike git
+
+### What version of git-annex are you using? On what operating system?
+
+6.20161122+gitg9f179ae-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+hopa:/tmp/datalad_temp_test_annex_add_no_dotfilesqMXck8
+$> git status                      
+On branch master
+ 
+Initial commit
+
+nothing to commit (create/copy files and use "git add" to track)
+
+$> mkdir .dir dir; echo 123 > .dir/123; echo 124 > dir/124
+
+$> git status
+On branch master
+
+Initial commit
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+
+	.dir/
+	dir/
+
+nothing added to commit but untracked files present (use "git add" to track)
+
+$> git annex add -c 'annex.largefiles=nothing' .
+add dir/124 (non-large file; adding content to git repository) ok
+(recording state in git...)
+
+$> git status
+On branch master
+
+Initial commit
+
+Changes to be committed:
+  (use "git rm --cached <file>..." to unstage)
+
+	new file:   dir/124
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+
+	.dir/
+
+
+# and with regular git
+$> git  -c 'annex.largefiles=nothing' add . 
+
+$> git status
+On branch master
+
+Initial commit
+
+Changes to be committed:
+  (use "git rm --cached <file>..." to unstage)
+
+	new file:   .dir/123
+	new file:   dir/124
+
+
+"""]]
+
+Ref: https://github.com/datalad/datalad/issues/1027
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[[done]]; oh -- it is RTFM: --include-dotfiles  --[[yoh]]
diff --git a/doc/projects/datalad/bugs-done/annex_doesn__39__t_fixup_symlinks_when___34__git_commit_path__95__to__95__repo__34___is_used.mdwn b/doc/projects/datalad/bugs-done/annex_doesn__39__t_fixup_symlinks_when___34__git_commit_path__95__to__95__repo__34___is_used.mdwn
new file mode 100644
index 0000000000..e7cdc074c9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_doesn__39__t_fixup_symlinks_when___34__git_commit_path__95__to__95__repo__34___is_used.mdwn
@@ -0,0 +1,84 @@
+### Please describe the problem.
+
+whenever we 'git mv' some files from one dir to another, "git commit path_to_that_repo" seems to cause git annex to not fix up the symlinks
+
+### What steps will reproduce the problem?
+
+see below complete examples
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170307+gitg24ade8a25-1~ndall+1
+
+### Please provide any additional information below.
+
+correct operation:
+
+[[!format sh """
+
+hopa:/tmp/testl
+$> builtin cd /tmp/; chmod +w -R /tmp/testl; rm -rf /tmp/testl; mkdir /tmp/testl && cd /tmp/testl && git init && git annex init && mkdir d && echo 123 > d/123 && git annex add d/123 && git commit -m added && git mv d/123 123 && git annex add . && echo -e '#!/bin/sh\ngit annex pre-commit --debug . >/tmp/precommit.log 2>&1\n' >| .git/hooks/pre-commit && git commit -m msg && ls -l 123 && git status && cat /tmp/precommit.log                                             
+Initialized empty Git repository in /tmp/testl/.git/
+init  ok
+(recording state in git...)
+add d/123 ok
+(recording state in git...)
+[master (root-commit) a04d6e9] added
+ 1 file changed, 1 insertion(+)
+ create mode 120000 d/123
+[master 1be2c88] msg
+ 2 files changed, 1 insertion(+), 1 deletion(-)
+ create mode 120000 123
+ delete mode 120000 d/123
+lrwxrwxrwx 1 yoh yoh 178 Mar 22 14:52 123 -> .git/annex/objects/G6/qW/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+On branch master
+nothing to commit, working tree clean
+[2017-03-22 14:52:45.459507064] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--cached","--name-only","-z","--diff-filter=ACMRT","--","."]
+fix 123 ok
+[2017-03-22 14:52:45.46373033] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--name-only","--diff-filter=T","-z","--cached","--","."]
+[2017-03-22 14:52:45.46776695] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2017-03-22 14:52:45.471690183] process done ExitSuccess
+[2017-03-22 14:52:45.471781853] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2017-03-22 14:52:45.475456411] process done ExitSuccess
+(recording state in git...)
+[2017-03-22 14:52:45.475535994] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--force","--"]
+[2017-03-22 14:52:45.482800008] process done ExitSuccess
+"""]]
+
+and this time commit with the path: (git commit -m msg /tmp/testl)
+
+[[!format sh """
+$> builtin cd /tmp/; chmod +w -R /tmp/testl; rm -rf /tmp/testl; mkdir /tmp/testl && cd /tmp/testl && git init && git annex init && mkdir d && echo 123 > d/123 && git annex add d/123 && git commit -m added && git mv d/123 123 && git annex add . && echo -e '#!/bin/sh\ngit annex pre-commit --debug . >/tmp/precommit.log 2>&1\n' >| .git/hooks/pre-commit && git commit -m msg /tmp/testl && ls -l 123 && git status && cat /tmp/precommit.log                                                                                                                                                      
+Initialized empty Git repository in /tmp/testl/.git/
+init  ok
+(recording state in git...)
+add d/123 ok
+(recording state in git...)
+[master (root-commit) 1438090] added
+ 1 file changed, 1 insertion(+)
+ create mode 120000 d/123
+[master 8912aa3] msg
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ rename d/123 => 123 (100%)
+lrwxrwxrwx 1 yoh yoh 181 Mar 22 14:52 123 -> ../.git/annex/objects/G6/qW/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+On branch master
+nothing to commit, working tree clean
+[2017-03-22 14:52:55.857221368] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--name-only","--diff-filter=T","-z","--cached","--","."]
+[2017-03-22 14:52:55.861708907] process done ExitSuccess
+[2017-03-22 14:52:55.861809182] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2017-03-22 14:52:55.865393029] process done ExitSuccess
+[2017-03-22 14:52:55.865471585] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2017-03-22 14:52:55.869145816] process done ExitSuccess
+
+
+"""]]
+
+
+note that there is no "(recording state in git...) ..." portion in the output!
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> This was fixed by v7 mode, which no longer needs to deal with old-style
+> unlocked files and so is not impacted by git false indexes any longer.
+> I've verified the test case no longer reproduces. [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/annex_doesn__39__t_fixup_symlinks_when___34__git_commit_path__95__to__95__repo__34___is_used/comment_1_b90f22ce0ab931658856e949ac227985._comment b/doc/projects/datalad/bugs-done/annex_doesn__39__t_fixup_symlinks_when___34__git_commit_path__95__to__95__repo__34___is_used/comment_1_b90f22ce0ab931658856e949ac227985._comment
new file mode 100644
index 0000000000..e5a1ac2784
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_doesn__39__t_fixup_symlinks_when___34__git_commit_path__95__to__95__repo__34___is_used/comment_1_b90f22ce0ab931658856e949ac227985._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-07T20:16:45Z"
+ content="""
+There's nothing special about using the absolute path; "git commit ." 
+or "git commit thefile" will behave the same.
+
+This is the git false index problem. Since git commit in these situations
+runs the pre-commit hook with a false index file, changes made to that
+index file won't be visible after the commit.
+
+So, if `git annex pre-commit` fixes symlinks in this situation,
+the right thing will be committed, but then the old index will have the old
+symlinks staged, which will result in `git status` after the commit showing
+modification to the files you just staged and committed!
+
+Short of having a post-commit hook come along and fix up the index to match
+what was committed, I don't see anything git-annex can do better. Well, it
+could prevent such commits even being made, I suppose, or warn.
+
+It's a pity git uses this false index file in this situation.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_drop_fails_to_determine_availability_on_a_http_url_redirecting_to_ftp.mdwn b/doc/projects/datalad/bugs-done/annex_drop_fails_to_determine_availability_on_a_http_url_redirecting_to_ftp.mdwn
new file mode 100644
index 0000000000..0d59a518eb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_drop_fails_to_determine_availability_on_a_http_url_redirecting_to_ftp.mdwn
@@ -0,0 +1,132 @@
+### Please describe the problem.
+
+Need to annex some files from a http link which forwards to ftp.  addurl works out fine (besides not carrying about redirected filename), but drop fails to verify presence of the file
+
+
+### What version of git-annex are you using? On what operating system?
+
+6.20160706+gitgc4229be-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+smaug:/tmp
+$> mkdir /tmp/123; cd /tmp/123; git init; git annex init;
+Initialized empty Git repository in /tmp/123/.git/
+init  ok
+(recording state in git...)
+1 10080.....................................:Tue 12 Jul 2016 02:18:46 PM EDT:.
+(git)smaug:/tmp/123[master]
+$> git annex addurl --debug --pathdepth=-1 http://www.nitrc.org/frs/downloadlink.php/1637
+[2016-07-12 14:18:54.8195] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2016-07-12 14:18:54.83021] process done ExitSuccess
+[2016-07-12 14:18:54.830357] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2016-07-12 14:18:54.841375] process done ExitSuccess
+[2016-07-12 14:18:54.841694] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..787586641a9027e772b91989eb649cb9303cd975","--pretty=%H","-n1"]
+[2016-07-12 14:18:54.851263] process done ExitSuccess
+[2016-07-12 14:18:54.852043] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2016-07-12 14:18:54.862122] read: quvi ["--version"]
+[2016-07-12 14:18:54.869939] process done ExitSuccess
+[2016-07-12 14:18:54.870062] call: quvi ["--verbosity","mute","--support","http://www.nitrc.org/frs/downloadlink.php/1637"]
+[2016-07-12 14:18:54.891339] process done ExitFailure 65
+addurl 1637 (downloading http://www.nitrc.org/frs/downloadlink.php/1637 ...) 
+[2016-07-12 14:18:55.830611] call: wget ["-q","--show-progress","--clobber","-c","-O","/tmp/123/.git/annex/tmp/URL--http&c%%www.nitrc.org%frs%downloadlink.php%1637","http://www.nitrc.org/frs/downloadlink.php/1637","--user-agent","git-annex/6.20160706+gitgc4229be-1~ndall+1"]
+1637                                         100%[===========================================================================================>] 268.32M  12.9MB/s    in 27s     
+[2016-07-12 14:19:31.32811] process done ExitSuccess
+[2016-07-12 14:19:31.328909] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+[2016-07-12 14:19:31.329444] read: git ["--version"]
+[2016-07-12 14:19:31.338195] process done ExitSuccess
+[2016-07-12 14:19:31.338947] read: sha256sum [".git/annex/tmp/URL--http&c%%www.nitrc.org%frs%downloadlink.php%1637"]
+[2016-07-12 14:19:32.860187] process done ExitSuccess
+ok
+(recording state in git...)
+[2016-07-12 14:19:32.872749] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"]
+[2016-07-12 14:19:32.890096] process done ExitSuccess
+[2016-07-12 14:19:32.890573] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]
+[2016-07-12 14:19:32.891376] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+[2016-07-12 14:19:32.901206] process done ExitSuccess
+[2016-07-12 14:19:32.901288] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2016-07-12 14:19:32.909396] process done ExitSuccess
+[2016-07-12 14:19:32.909691] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2016-07-12 14:19:32.91827] process done ExitSuccess
+[2016-07-12 14:19:32.918324] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","6c1ce1871151c12f6930733e7693eac2fd862677","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2016-07-12 14:19:32.927217] process done ExitSuccess
+[2016-07-12 14:19:32.927281] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","2453a1c23977e4f17ac5fd9668cdc7bdb93e34e8"]
+[2016-07-12 14:19:32.936074] process done ExitSuccess
+cached/staged changes:                                                                                                                                                           
+ 1637 | 1 +
+1 10081.....................................:Tue 12 Jul 2016 02:19:32 PM EDT:.
+(git)smaug:/tmp/123[master]
+$> git commit -m 'added'                                                          
+[master (root-commit) b212851] added
+ 1 file changed, 1 insertion(+)
+ create mode 120000 1637
+1 10082.....................................:Tue 12 Jul 2016 02:19:38 PM EDT:.
+(git)smaug:/tmp/123[master]git
+$> git annex drop 1637                                                            
+drop 1637 (checking http://www.nitrc.org/frs/downloadlink.php/1637...) (unsafe) 
+  Could only verify the existence of 0 out of 1 necessary copies
+
+  Rather than dropping this file, try using: git annex move
+
+  (Use --force to override this check, or adjust numcopies.)
+failed
+git-annex: drop: 1 failed
+1 10083 ->1.....................................:Tue 12 Jul 2016 02:19:48 PM EDT:.
+(git)smaug:/tmp/123[master]git
+$> wget -S http://www.nitrc.org/frs/downloadlink.php/1637
+--2016-07-12 14:19:54--  http://www.nitrc.org/frs/downloadlink.php/1637
+Resolving www.nitrc.org (www.nitrc.org)... 132.239.16.23
+Connecting to www.nitrc.org (www.nitrc.org)|132.239.16.23|:80... connected.
+HTTP request sent, awaiting response... 
+  HTTP/1.1 302 Found
+  Date: Tue, 12 Jul 2016 18:19:54 GMT
+  Server: Apache/2.2.15 (CentOS)
+  X-Powered-By: PHP/5.3.3
+  Set-Cookie: PHPSESSID=vhcpo1fmi205cfv0h4jgbnn9a0; path=/
+  Expires: Thu, 19 Nov 1981 08:52:00 GMT
+  Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
+  Pragma: no-cache
+  Location: ftp://www.nitrc.org/fcon_1000/htdocs/Ontario.tar
+  Content-Length: 0
+  Keep-Alive: timeout=2, max=100
+  Connection: Keep-Alive
+  Content-Type: text/html; charset=UTF-8
+Location: ftp://www.nitrc.org/fcon_1000/htdocs/Ontario.tar [following]
+--2016-07-12 14:19:55--  ftp://www.nitrc.org/fcon_1000/htdocs/Ontario.tar
+           => ‘Ontario.tar’
+Connecting to www.nitrc.org (www.nitrc.org)|132.239.16.23|:21... connected.
+Logging in as anonymous ... 
+220 (vsFTPd 2.2.2)
+--> USER anonymous
+
+331 Please specify the password.
+--> PASS Turtle Power!
+
+230 Login successful.
+--> SYST
+
+215 UNIX Type: L8
+--> PWD
+
+257 "/"
+--> TYPE I
+
+200 Switching to Binary mode.
+--> CWD /fcon_1000/htdocs
+
+250 Directory successfully changed.
+--> SIZE Ontario.tar
+
+213 281354240
+--> PASV
+
+227 Entering Passive Mode (132,239,16,23,106,251).
+--> RETR Ontario.tar
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed.mdwn b/doc/projects/datalad/bugs-done/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed.mdwn
new file mode 100644
index 0000000000..7234f2187a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed.mdwn
@@ -0,0 +1,67 @@
+### Please describe the problem.
+
+Usecase (you might suggest a better way) is to 'annex' the content of files (via addurl) without actually committing symlinks to git (git-annex branch obviously should progress forward).  So the sequence is akin 'annex addurl', 'annex drop' both ran with annex.alwayscommit=false .  The issue is that it seems that if addurl is --batched, then symlink is not 'git add'ed until batched process finishes, and thus subsequent to 'addurl' 'drop' does nothing, leaving key behind not dropped.
+
+Related recent TODO wishlist is [[http://git-annex.branchable.com/todo/drop_--batch/]]
+
+### What steps will reproduce the problem?
+
+FWIW below is a somewhat noisy output from datalad's unittest (which addurl into the archive's content, so custom special remote is involved).  At the end of the run content is not dropped, symlink is not dangling.
+
+### What version of git-annex are you using? On what operating system?
+
+originally was a version from March but tried also with fresh  6.20160425+gitgffe2ea2-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+2016-04-26 14:13:05,545 [DEBUG  ] Initiating a new process for BatchedAnnex(annex_cmd='addurl', annex_options=['--with-files', '--json'], git_options=[], output_proc=<function>, path=<<'/home/yoh/.tmp/datala...>>) (annexrepo.py:1145)
+2016-04-26 14:13:05,545 [Level 5] Command: ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'addurl', '--with-files', '--json', '--batch'] (annexrepo.py:1148)
+2016-04-26 14:13:05,548 [Level 5] Sending 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4 .dataladMCsP4y/file.txt\n' to batched annex BatchedAnnex(annex_cmd='addurl', annex_options=['--with-files', '--json'], git_options=[], output_proc=<function>, path=<<'/home/yoh/.tmp/datala...>>) (annexrepo.py:1202)
+2016-04-26 14:13:05,548 [Level 5] Done sending. (annexrepo.py:1210)
+2016-04-26 14:13:05,869 [DEBUG] Importing the rest of datalad.__init__ (__init__.py:15)
+2016-04-26 14:13:05,870 [DEBUG] Reading files: ['/etc/datalad/datalad.cfg', '/etc/xdg/datalad/config', '/home/yoh/.config/datalad/datalad.cfg', '.datalad/config'] (configparserinc.py:144)
+2016-04-26 14:13:05,959 [DEBUG] UI set to ConsoleLog(out=<file>) (__init__.py:48)
+2016-04-26 14:13:05,960 [DEBUG] UI set to UnderAnnexUI(out=<file>) (__init__.py:48)
+2016-04-26 14:13:05,962 [DEBUG] Not initiating existing cache for the archives under /tmp/datalad_temp_tree_setupmRy8cc/.git/datalad/tmp/archives (archives.py:262)
+2016-04-26 14:13:05,962 [Level 4] Sending 'VERSION 1' (base.py:312)
+2016-04-26 14:13:05,962 [Level 4] Received ['PREPARE'] (base.py:312)
+2016-04-26 14:13:05,962 [Level 4] Sending 'PREPARE-SUCCESS' (base.py:312)
+2016-04-26 14:13:05,962 [Level 4] Received ['CLAIMURL', 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'] (base.py:312)
+2016-04-26 14:13:05,963 [DEBUG] Claiming url 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4' (base.py:316)
+2016-04-26 14:13:05,963 [Level 4] Sending "DEBUG Claiming url 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'" (base.py:312)
+2016-04-26 14:13:05,963 [Level 4] Sending 'CLAIMURL-SUCCESS' (base.py:312)
+2016-04-26 14:13:05,963 [Level 4] Received ['CHECKURL', 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'] (base.py:312)
+2016-04-26 14:13:05,964 [DEBUG] Current directory: /tmp/datalad_temp_tree_setupmRy8cc, url: dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4 (archives.py:163)
+2016-04-26 14:13:05,964 [DEBUG] Initiating a new process for BatchedAnnex(annex_cmd='contentlocation', annex_options=[], git_options=[], output_proc=<function>, path=<<'/tmp/datalad_temp_tre...>>) (annexrepo.py:1145)
+2016-04-26 14:13:05,964 [Level 5] Command: ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'contentlocation', '--batch'] (annexrepo.py:1148)
+2016-04-26 14:13:05,967 [Level 5] Sending 'SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar\n' to batched annex BatchedAnnex(annex_cmd='contentlocation', annex_options=[], git_options=[], output_proc=<function>, path=<<'/tmp/datalad_temp_tre...>>) (annexrepo.py:1202)
+2016-04-26 14:13:05,967 [Level 5] Done sending. (annexrepo.py:1210)
+2016-04-26 14:13:06,007 [Level 5] Received output: '.git/annex/objects/7p/mj/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar' (annexrepo.py:1220)
+2016-04-26 14:13:06,008 [Level 4] Sending 'CHECKURL-CONTENTS 4' (base.py:312)
+2016-04-26 14:13:06,009 [Level 4] Received ['TRANSFER', 'RETRIEVE', 'URL-s4--dl,43archive:SHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61', '.git/annex/tmp/URL-s4--dl,43archive&cSHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61'] (base.py:312)
+2016-04-26 14:13:06,009 [INFO] RETRIEVE key URL-s4--dl,43archive:SHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61 into/from .git/annex/tmp/URL-s4--dl,43archive&cSHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61 (base.py:429)
+2016-04-26 14:13:06,009 [Level 4] Sending 'GETURLS URL-s4--dl,43archive:SHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61 dl+archive:' (base.py:312)
+2016-04-26 14:13:06,011 [Level 4] Received ['VALUE', 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'] (base.py:312)
+2016-04-26 14:13:06,011 [Level 4] Received ['VALUE'] (base.py:312)
+2016-04-26 14:13:06,011 [Level 4] Received URLS: ['dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'] (base.py:312)
+2016-04-26 14:13:06,011 [DEBUG] Getting file 1/file.txt from /tmp/datalad_temp_tree_setupmRy8cc/.git/annex/objects/7p/mj/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar while PWD=/tmp/datalad_temp_tree_setupmRy8cc (archives.py:299)
+2016-04-26 14:13:06,011 [DEBUG] Requested file 1/file.txt from archive /tmp/datalad_temp_tree_setupmRy8cc/.git/annex/objects/7p/mj/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar (archives.py:454)
+2016-04-26 14:13:06,012 [Level 2] Verifying that /tmp/datalad_temp_tree_setupmRy8cc/.git/datalad/tmp/archives/60e44d2ccc/1/file.txt exists (archives.py:462)
+2016-04-26 14:13:06,012 [DEBUG] Hardlinking /tmp/datalad_temp_tree_setupmRy8cc/.git/datalad/tmp/archives/60e44d2ccc/1/file.txt under .git/annex/tmp/URL-s4--dl,43archive&cSHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61 (cmd.py:372)
+2016-04-26 14:13:06,012 [Level 2] Hardlinking finished (cmd.py:382)
+2016-04-26 14:13:06,012 [Level 4] Sending 'TRANSFER-SUCCESS RETRIEVE URL-s4--dl,43archive:SHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61' (base.py:312)
+2016-04-26 14:13:06,022 [Level 5] Received output: {u'note': u'from datalad-archives', u'success': True, u'command': u'addurl', u'key': u'SHA256E-s4--0cf67fc72b3c86c7a454f6d86b43ed245a8e491d0e5288d4da8c7ff43a7bcdb0.txt', u'file': u'.dataladMCsP4y/file.txt'} (annexrepo.py:1220)
+2016-04-26 14:13:06,023 [DEBUG  ] Running: ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', '-c', 'annex.alwayscommit=false', 'annex', 'drop', '--debug', '.dataladMCsP4y/file.txt'] (cmd.py:351)
+2016-04-26 14:13:06,075 [ERROR  ] stderr| [2016-04-26 14:13:06.069266] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--",".dataladMCsP4y/file.txt"] (cmd.py:351)
+2016-04-26 14:13:06,075 [Level 8] Finished running ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', '-c', 'annex.alwayscommit=false', 'annex', 'drop', '--debug', '.dataladMCsP4y/file.txt'] with status 0 (cmd.py:351)
+t sh
+
+"""]]
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] per comments --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_.mdwn b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_.mdwn
new file mode 100644
index 0000000000..e3146fc8db
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_.mdwn
@@ -0,0 +1,99 @@
+
+[[!format sh """
+(git)smaug:/mnt/btrfs/datasets/datalad/crawl/dbic/QA[master]git
+$> git annex get -J 16 --debug --json-progress .
+[2018-09-25 09:40:26.76476951] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","."]
+[2018-09-25 09:40:26.769184442] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-09-25 09:40:26.771844846] process done ExitSuccess
+[2018-09-25 09:40:26.771993108] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-09-25 09:40:26.775598151] process done ExitSuccess
+[2018-09-25 09:40:26.776318887] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..db88e4b0bf3d633885a4e202e0c113942856c47f","--pretty=%H","-n1"]
+[2018-09-25 09:40:26.780382394] process done ExitSuccess
+[2018-09-25 09:40:26.780553211] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..4f0e8cd9a43b003228c3898133b1e200f9bdfc22","--pretty=%H","-n1"]
+[2018-09-25 09:40:26.785109549] process done ExitSuccess
+[2018-09-25 09:40:26.785992031] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-09-25 09:40:26.787017719] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-09-25 09:40:26.838015294] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-09-25 09:40:26.838108997] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-09-25 09:40:26.838146759] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-09-25 09:40:26.838125814] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-09-25 09:40:26.840522185] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-09-25 09:40:26.840544359] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-09-25 09:40:26.840612031] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-09-25 09:40:26.843542095] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-09-25 09:40:26.843885927] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-09-25 09:40:26.844793008] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-09-25 09:40:26.84691911] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-09-25 09:40:26.848525571] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-09-25 09:40:26.876936065] read: ssh ["-O","stop","-S","bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
+[2018-09-25 09:40:26.89165743] process done ExitSuccess
+{"command":"get","wanted":[{"here":false,"uuid":"6384a551-a41d-4290-b186-9258befede97","description":"bids@rolando:/inbox/BIDS/dbic/QA [origin]"}],"note":"transfer already in progress, or unable to take transfer lock\nUnable to access these remotes: origin\nTry making some of these repositories available:\n\t6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA [origin]\n","skipped":[],"success":false,"key":"SHA256E-s1633--1bc7a100b82cd31d084aae5b25b8d90af128324d10d92cfc9e2196d28829d375.tsv","file":".heudiconv/qa/ses-20171106/info/dicominfo_ses-20171106.tsv"}
+[2018-09-25 09:40:26.89294943] read: ssh ["-o","BatchMode=true","-S",".git/annex/ssh/bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","bids@rolando.cns","true"]
+[2018-09-25 09:40:26.892976736] read: ssh ["-o","BatchMode=true","-S",".git/annex/ssh/bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","bids@rolando.cns","true"]
+[2018-09-25 09:40:26.892951965] read: ssh ["-o","BatchMode=true","-S",".git/annex/ssh/bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","bids@rolando.cns","true"]
+[2018-09-25 09:40:26.901388917] read: ssh ["-o","BatchMode=true","-S",".git/annex/ssh/bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","bids@rolando.cns","true"]
+[2018-09-25 09:40:26.901683012] read: ssh ["-o","BatchMode=true","-S",".git/annex/ssh/bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","bids@rolando.cns","true"]
+[2018-09-25 09:40:28.479898885] process done ExitSuccess
+[2018-09-25 09:40:28.480093679] chat: ssh ["bids@rolando.cns","-S",".git/annex/ssh/bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba8f2cea-f229-422c-82be-6580e5e07ed5' --uuid 6384a551-a41d-4290-b186-9258befede97"]
+[2018-09-25 09:40:28.505377708] process done ExitSuccess
+[2018-09-25 09:40:28.505676376] chat: ssh ["bids@rolando.cns","-S",".git/annex/ssh/bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba8f2cea-f229-422c-82be-6580e5e07ed5' --uuid 6384a551-a41d-4290-b186-9258befede97"]
+[2018-09-25 09:40:28.508740142] process done ExitSuccess
+[2018-09-25 09:40:28.508761163] process done ExitSuccess
+[2018-09-25 09:40:28.508782029] process done ExitSuccess
+[2018-09-25 09:40:28.50891246] chat: ssh ["bids@rolando.cns","-S",".git/annex/ssh/bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba8f2cea-f229-422c-82be-6580e5e07ed5' --uuid 6384a551-a41d-4290-b186-9258befede97"]
+[2018-09-25 09:40:28.508944895] chat: ssh ["bids@rolando.cns","-S",".git/annex/ssh/bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba8f2cea-f229-422c-82be-6580e5e07ed5' --uuid 6384a551-a41d-4290-b186-9258befede97"]
+[2018-09-25 09:40:28.509074882] chat: ssh ["bids@rolando.cns","-S",".git/annex/ssh/bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba8f2cea-f229-422c-82be-6580e5e07ed5' --uuid 6384a551-a41d-4290-b186-9258befede97"]
+[2018-09-25 09:40:29.936552742] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 09:40:29.93677054] P2P > VERSION 1
+[2018-09-25 09:40:29.937971781] P2P < VERSION 1
+[2018-09-25 09:40:29.938155534] P2P > GET 0 .heudiconv/qa/ses-20171127/info/filegroup_ses-20171127.json SHA256E-s429026--12edfd6e2c58f05803cb5bff0ff3665f46229b5593354324fbecdd5b131506fc.json
+[2018-09-25 09:40:29.940554579] P2P < GET 0 .heudiconv/qa/ses-20171127/info/filegroup_ses-20171127.json SHA256E-s429026--12edfd6e2c58f05803cb5bff0ff3665f46229b5593354324fbecdd5b131506fc.json[2018-09-25 09:40:29.967840409] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 09:40:29.967989255] P2P > VERSION 1
+[2018-09-25 09:40:29.969234907] P2P < VERSION 1
+[2018-09-25 09:40:29.96933411] P2P > GET 0 .heudiconv/qa/ses-20171204/info/dicominfo_ses-20171204.tsv SHA256E-s1633--7aee5bc34c95def9972b1f99f1a9ad976a3acb9da9f18e8bfa8888f579c111f6.tsv
+[2018-09-25 09:40:29.971575677] P2P < GET 0 .heudiconv/qa/ses-20171204/info/dicominfo_ses-20171204.tsv SHA256E-s1633--7aee5bc34c95def9972b1f99f1a9ad976a3acb9da9f18e8bfa8888f579c111f6.tsv[2018-09-25 09:40:29.972619373] P2P > DATA 429026[2018-09-25 09:40:29.971577514] P2P < DATA 429026
+[2018-09-25 09:40:29.981195211] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 09:40:29.981346807] P2P > VERSION 1
+[2018-09-25 09:40:29.982599704] P2P < VERSION 1
+[2018-09-25 09:40:29.982851645] P2P > GET 0 .heudiconv/qa/ses-20171113/info/filegroup_ses-20171113.json SHA256E-s429026--2f0daf77e8ff5d902c00f88343b3cad51a2c7abc1e4702d450e5aea8dafc4ca6.json
+[2018-09-25 09:40:29.98372615] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 09:40:29.983855252] P2P > VERSION 1
+[2018-09-25 09:40:29.985098551] P2P < GET 0 .heudiconv/qa/ses-20171113/info/filegroup_ses-20171113.json SHA256E-s429026--2f0daf77e8ff5d902c00f88343b3cad51a2c7abc1e4702d450e5aea8dafc4ca6.json[2018-09-25 09:40:29.985099291] P2P < VERSION 1
+[2018-09-25 09:40:29.985268868] P2P > GET 0 .heudiconv/qa/ses-20171113/info/dicominfo_ses-20171113.tsv SHA256E-s1633--76397f694088587dfbe2cbea5d35341c7588dbcb262a0ff91f94a07892c83409.tsv
+[2018-09-25 09:40:29.986356073] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 09:40:29.9876026] P2P < GET 0 .heudiconv/qa/ses-20171113/info/dicominfo_ses-20171113.tsv SHA256E-s1633--76397f694088587dfbe2cbea5d35341c7588dbcb262a0ff91f94a07892c83409.tsv[2018-09-25 09:40:29.986449339] P2P > VERSION 1
+[2018-09-25 09:40:29.987893014] P2P < VERSION 1
+[2018-09-25 09:40:29.988057111] P2P > GET 0 .heudiconv/qa/ses-20171106/info/filegroup_ses-20171106.json SHA256E-s429026--cd00d181cf477405db3b5243fbd5d7969efffccf16b49599a1cd1fde32879a66.json
+[2018-09-25 09:40:29.990480076] P2P < GET 0 .heudiconv/qa/ses-20171106/info/filegroup_ses-20171106.json SHA256E-s429026--cd00d181cf477405db3b5243fbd5d7969efffccf16b49599a1cd1fde32879a66.json{"byte-progress":32752,"action":{"command":"get","note":"from origin...","key":"SHA256E-s429026--12edfd6e2c58f05803cb5bff0ff3665f46229b5593354324fbecdd5b131506fc.json","file":".heudiconv/qa/ses-20171127/info/filegroup_ses-20171127.json"},"total-size":429026,"percent-progress":"7.63%"}
+[2018-09-25 09:40:30.109171443] P2P > VALID{"byte-progress":429026,"action":{"command":"get","note":"from origin...","key":"SHA256E-s429026--12edfd6e2c58f05803cb5bff0ff3665f46229b5593354324fbecdd5b131506fc.json","file":".heudiconv/qa/ses-20171127/info/filegroup_ses-20171127.json"},"total-size":429026,"percent-progress":"100%"}
+[2018-09-25 09:40:30.109206914] P2P < VALID
+[2018-09-25 09:40:30.109391344] P2P > SUCCESS
+[2018-09-25 09:40:30.111586675] P2P < SUCCESS{"command":"get","note":"from origin...\nchecksum...","success":true,"key":"SHA256E-s429026--12edfd6e2c58f05803cb5bff0ff3665f46229b5593354324fbecdd5b131506fc.json","file":".heudiconv/qa/ses-20171127/info/filegroup_ses-20171127.json"}
+
+"""]]
+
+on the remote I see 5 sleeping annex-shells:
+[[!format sh """
+[bids@rolando ~] > ps auxw | grep git-anne[x] | nl
+     1	bids     17254  0.0  0.0 1074095936 12788 ?    Ssl  09:40   0:00 /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2/exe/git-annex-shell --library-path /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu/gconv:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu/audit:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//etc/ld.so.conf.d:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//lib64:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//lib/x86_64-linux-gnu:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu: /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2/shimmed/git-annex-shell/git-annex-shell p2pstdio /inbox/BIDS/dbic/QA --debug ba8f2cea-f229-422c-82be-6580e5e07ed5 --uuid 6384a551-a41d-4290-b186-9258befede97
+     2	bids     17259  0.0  0.0 1074095936 12004 ?    Ssl  09:40   0:00 /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2/exe/git-annex-shell --library-path /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu/gconv:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu/audit:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//etc/ld.so.conf.d:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//lib64:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//lib/x86_64-linux-gnu:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu: /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2/shimmed/git-annex-shell/git-annex-shell p2pstdio /inbox/BIDS/dbic/QA --debug ba8f2cea-f229-422c-82be-6580e5e07ed5 --uuid 6384a551-a41d-4290-b186-9258befede97
+     3	bids     17260  0.0  0.0 1074095936 12012 ?    Ssl  09:40   0:00 /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2/exe/git-annex-shell --library-path /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu/gconv:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu/audit:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//etc/ld.so.conf.d:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//lib64:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//lib/x86_64-linux-gnu:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu: /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2/shimmed/git-annex-shell/git-annex-shell p2pstdio /inbox/BIDS/dbic/QA --debug ba8f2cea-f229-422c-82be-6580e5e07ed5 --uuid 6384a551-a41d-4290-b186-9258befede97
+     4	bids     17261  0.0  0.0 1074095936 12012 ?    Ssl  09:40   0:00 /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2/exe/git-annex-shell --library-path /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu/gconv:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu/audit:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//etc/ld.so.conf.d:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//lib64:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//lib/x86_64-linux-gnu:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu: /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2/shimmed/git-annex-shell/git-annex-shell p2pstdio /inbox/BIDS/dbic/QA --debug ba8f2cea-f229-422c-82be-6580e5e07ed5 --uuid 6384a551-a41d-4290-b186-9258befede97
+     5	bids     17262  0.0  0.0 1074095936 12008 ?    Ssl  09:40   0:00 /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2/exe/git-annex-shell --library-path /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu/gconv:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu/audit:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//etc/ld.so.conf.d:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//lib64:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//lib/x86_64-linux-gnu:/afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2//usr/lib/x86_64-linux-gnu: /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex_v2/shimmed/git-annex-shell/git-annex-shell p2pstdio /inbox/BIDS/dbic/QA --debug ba8f2cea-f229-422c-82be-6580e5e07ed5 --uuid 6384a551-a41d-4290-b186-9258befede97
+"""]]
+
+local version is 6.20180913+git33-g2cd5a723f-1~ndall+1 and remote 6.20180808-ga1327779a (it is like Sep 13, current standalone build).
+There was/is no other transfer in progress when calling it, but some previously failed runs. That file gets just fine later on if run get on it alone
+[[!format sh """
+$> git annex get .heudiconv/qa/ses-20171113/info/filegroup_ses-20171113.json  
+get .heudiconv/qa/ses-20171113/info/filegroup_ses-20171113.json (from origin...) 
+(checksum...) ok                   
+(recording state in git...)
+"""]]
+
+so to me smells like some race condition due to high -J value.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_10_4b053c393627e2efb746a2b81838e518._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_10_4b053c393627e2efb746a2b81838e518._comment
new file mode 100644
index 0000000000..d8fff8861b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_10_4b053c393627e2efb746a2b81838e518._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2018-10-22T16:24:44Z"
+ content="""
+First, you have not disabled sshcaching, because the value to disable it is
+not "no" but "false". So please try again with sshcaching disabled..
+
+	Oct  4 16:25:28 localhost sshd[11700]: Received disconnect from 129.XXX.XXX.XXX port 40080:11: disconnected by user
+
+Looks like something on the client side or in the middle is closing the TCP
+connection, and I think not in a clean shutdown way, but hard.
+
+I'm fairly sure the git-annex is not stopping the ssh process it used to open
+that connection though. The "hGetChar: illegal operation" is because it's still
+trying to read from ssh after it exited. So it seems we need to find out why
+the ssh process on the client side is exiting (assuning the same thing happens
+with sshcaching disabled). strace?
+
+You mentioned NFS.. Which repo is on NFS, the client or the server?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_11_e8ff5342533744617248104b04aa227f._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_11_e8ff5342533744617248104b04aa227f._comment
new file mode 100644
index 0000000000..8c96047c14
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_11_e8ff5342533744617248104b04aa227f._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="stalling - also with =false"
+ date="2018-10-22T17:34:28Z"
+ content="""
+`=false` instead of `=no` seems to make no difference:
+
+[[!format sh \"\"\"
+1 13835.....................................:Mon 22 Oct 2018 01:24:10 PM EDT:.
+(git)smaug:/tmp/QA-stalling[master]git
+$> git  -c annex.sshcaching=false  annex get -J2 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz
+get sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz (from origin...) (checksum...) ok
+get sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz (from origin...) (checksum...) ok
+get sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz (from origin...) 
+^C
+1 13836 ->130.....................................:Mon 22 Oct 2018 01:25:44 PM EDT:.
+\"\"\"]]
+
+in a blind attempt I have also set them within `~/.gitconfig` on the server side -- also to no effect
+
+> `... strace?`
+
+I've provided a URL to strace log in an email from 3 Oct 2018 (msg id 20181003182901.GM3684@hopa.kiewit.dartmouth.edu).  Now will collect one more with the `=false` and follow up to that email with url to this fresh trace (do not want to share them publicly happen some sensitive information is recorded/leaks)
+
+> `You mentioned NFS.. Which repo is on NFS, the client or the server?  `
+
+Server.  I've emailed mount options in a private communication on Fri, 5 Oct 2018 (message id 20181005201504.GH3978@hopa.kiewit.dartmouth.edu)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_12_7b5857e8415f386813b1b174e39e899f._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_12_7b5857e8415f386813b1b174e39e899f._comment
new file mode 100644
index 0000000000..95b8b46756
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_12_7b5857e8415f386813b1b174e39e899f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2018-10-22T18:37:54Z"
+ content="""
+Interestingly, the P2P debug in
+<http://git-annex.branchable.com/bugs/annex_get_-J_16_via_ssh_stalls_/#comment-34b66436c1a2f2d9479f948655375bb5>
+shows two ssh processes started, but then git-annex sends "VERSION 1" three
+times. And the remote only replies to two of those.
+
+Could that indicate two threads are somehow talking to the same ssh?
+I've instrumented --debug with more information to find out, so 
+please try again with [[!commit fcca7adaffe86673dade3790f80e22ee426b51e7]].
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_13_552c0283748b64d84e84f5117f697d3b._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_13_552c0283748b64d84e84f5117f697d3b._comment
new file mode 100644
index 0000000000..3019a55105
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_13_552c0283748b64d84e84f5117f697d3b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2018-10-22T19:55:18Z"
+ content="""
+Hmm, more likely that's debug info from the remote side coming over ssh
+stderr channel. Still the added instrumentation may provide a clue..
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_14_7e3f849312d824cfbd10cce1f024c80b._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_14_7e3f849312d824cfbd10cce1f024c80b._comment
new file mode 100644
index 0000000000..d1b1d9cc6b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_14_7e3f849312d824cfbd10cce1f024c80b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 14"
+ date="2018-10-22T20:07:38Z"
+ content="""
+it would be easier for me just to build from master but [fresh test failures](http://git-annex.branchable.com/bugs/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d/) seems to preclude that.  Any clue on those?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_15_666dcda30f5a34588c4357c3fa43e8d8._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_15_666dcda30f5a34588c4357c3fa43e8d8._comment
new file mode 100644
index 0000000000..70dacd3642
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_15_666dcda30f5a34588c4357c3fa43e8d8._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 15"
+ date="2018-10-23T03:04:48Z"
+ content="""
+So what should I/we look for? 
+
+[[!format sh \"\"\"
+(git)smaug:/tmp/QA-stalling[master]git
+$> git -c annex.sshcaching=false annex get --debug --json --json-progress -J2 -- sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz
+[2018-10-22 23:03:07.420460462] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2018-10-22 23:03:07.42483927] process done ExitSuccess
+[2018-10-22 23:03:07.424913817] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2018-10-22 23:03:07.427996778] process done ExitSuccess
+[2018-10-22 23:03:07.428098073] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\",\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz\",\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"]
+[2018-10-22 23:03:07.432957028] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2018-10-22 23:03:07.436709692] process done ExitSuccess
+[2018-10-22 23:03:07.436887432] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-10-22 23:03:07.439267296] process done ExitSuccess
+[2018-10-22 23:03:07.439767312] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..fa5c45ed1a2765c1c59878ab3ba179cf89cb58c5\",\"--pretty=%H\",\"-n1\"]
+[2018-10-22 23:03:07.445013811] process done ExitSuccess
+[2018-10-22 23:03:07.445522717] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-10-22 23:03:07.446204069] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-10-22 23:03:07.452085512] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-10-22 23:03:07.452510897] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-10-22 23:03:07.452757895] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-10-22 23:03:07.453502591] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-10-22 23:03:07.573292091] chat: ssh [\"bids@rolando.cns\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ed495e60-f4c1-4a9b-86fd-0b3cec9689a6' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-10-22 23:03:07.574732043] chat: ssh [\"bids@rolando.cns\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ed495e60-f4c1-4a9b-86fd-0b3cec9689a6' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-10-22 23:03:09.30462026] [ssh connection 1] [ThreadId 12] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-10-22 23:03:09.30461788] [ssh connection 2] [ThreadId 11] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-10-22 23:03:09.304852574] [ssh connection 1] [ThreadId 12] P2P > VERSION 1
+[2018-10-22 23:03:09.304949382] [ssh connection 2] [ThreadId 11] P2P > VERSION 1
+[2018-10-22 23:03:09.306234971] [ssh connection 1] [ThreadId 12] P2P < VERSION 1
+[2018-10-22 23:03:09.306349793] [ssh connection 2] [ThreadId 11] P2P < VERSION 1
+[2018-10-22 23:03:09.306444891] [ssh connection 1] [ThreadId 12] P2P > GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz
+[2018-10-22 23:03:09.306552423] [ssh connection 2] [ThreadId 11] P2P > GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz
+[2018-10-22 23:03:09.307458334] P2P < GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz[2018-10-22 23:03:09.307525458] P2P < GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz[2018-10-22 23:03:09.325250636] P2P > DATA 26287753[2018-10-22 23:03:09.325749037] [ssh connection 1] [ThreadId 12] P2P < DATA 26287753
+{\"byte-progress\":32752,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz\"},\"total-size\":26287753,\"percent-progress\":\"0.12%\"}
+{\"byte-progress\":5535088,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz\"},\"total-size\":26287753,\"percent-progress\":\"21.06%\"}
+{\"byte-progress\":12052736,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz\"},\"total-size\":26287753,\"percent-progress\":\"45.85%\"}
+{\"byte-progress\":19389184,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz\"},\"total-size\":26287753,\"percent-progress\":\"73.76%\"}
+{\"byte-progress\":23024656,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz\"},\"total-size\":26287753,\"percent-progress\":\"87.59%\"}
+[2018-10-22 23:03:09.830143593] P2P > VALID{\"byte-progress\":26287753,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz\"},\"total-size\":26287753,\"percent-progress\":\"100%\"}
+[2018-10-22 23:03:09.831871793] [ssh connection 1] [ThreadId 12] P2P < VALID
+[2018-10-22 23:03:09.832050086] [ssh connection 1] [ThreadId 12] P2P > SUCCESS
+[2018-10-22 23:03:09.832697551] P2P < SUCCESS{\"command\":\"get\",\"note\":\"from origin...\nchecksum...\",\"success\":true,\"key\":\"SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz\"}
+[2018-10-22 23:03:09.978345188] [ssh connection 1] [ThreadId 48] P2P > GET 0 sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz
+[2018-10-22 23:03:09.979193267] P2P < GET 0 sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz[2018-10-22 23:03:09.993552354] P2P > DATA 33352666[2018-10-22 23:03:09.994121174] [ssh connection 1] [ThreadId 48] P2P < DATA 33352666
+{\"byte-progress\":32752,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"0.1%\"}
+{\"byte-progress\":7434704,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"22.29%\"}
+{\"byte-progress\":10644400,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"31.91%\"}
+{\"byte-progress\":10677152,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"32.01%\"}
+{\"byte-progress\":20207984,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"60.59%\"}
+{\"byte-progress\":23810704,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"71.39%\"}
+[2018-10-22 23:03:10.946446534] P2P > VALID{\"byte-progress\":33352666,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"100%\"}
+[2018-10-22 23:03:10.947694471] [ssh connection 1] [ThreadId 48] P2P < VALID
+[2018-10-22 23:03:10.947885865] [ssh connection 1] [ThreadId 48] P2P > SUCCESS
+[2018-10-22 23:03:10.9484066] P2P < SUCCESS{\"command\":\"get\",\"note\":\"from origin...\nchecksum...\",\"success\":true,\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"}
+^C
+
+$> git annex version
+git-annex version: 6.20181011+git124-g94aa0e2f6-1~ndall+1
+\"\"\"]]
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_16_39227b7dc49d141556680980aa558318._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_16_39227b7dc49d141556680980aa558318._comment
new file mode 100644
index 0000000000..c76bc85df2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_16_39227b7dc49d141556680980aa558318._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2018-11-02T16:33:52Z"
+ content="""
+Trimming that to only P2P protocol and reordering by connection:
+
+[[!format sh \"\"\"
+[2018-10-22 23:03:09.30462026] [ssh connection 1] [ThreadId 12] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-10-22 23:03:09.304852574] [ssh connection 1] [ThreadId 12] P2P > VERSION 1
+[2018-10-22 23:03:09.306234971] [ssh connection 1] [ThreadId 12] P2P < VERSION 1
+[2018-10-22 23:03:09.306444891] [ssh connection 1] [ThreadId 12] P2P > GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz
+[2018-10-22 23:03:09.307458334] P2P < GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz
+[2018-10-22 23:03:09.325250636] P2P > DATA 26287753
+[2018-10-22 23:03:09.325749037] [ssh connection 1] [ThreadId 12] P2P < DATA 26287753
+[2018-10-22 23:03:09.830143593] P2P > VALID
+[2018-10-22 23:03:09.831871793] [ssh connection 1] [ThreadId 12] P2P < VALID
+[2018-10-22 23:03:09.832050086] [ssh connection 1] [ThreadId 12] P2P > SUCCESS
+[2018-10-22 23:03:09.832697551] P2P < SUCCESS
+[2018-10-22 23:03:09.978345188] [ssh connection 1] [ThreadId 48] P2P > GET 0 sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz
+[2018-10-22 23:03:09.979193267] P2P < GET 0 sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz
+[2018-10-22 23:03:09.993552354] P2P > DATA 33352666
+[2018-10-22 23:03:09.994121174] [ssh connection 1] [ThreadId 48] P2P < DATA 33352666
+[2018-10-22 23:03:10.946446534] P2P > VALID
+[2018-10-22 23:03:10.947694471] [ssh connection 1] [ThreadId 48] P2P < VALID
+[2018-10-22 23:03:10.947885865] [ssh connection 1] [ThreadId 48] P2P > SUCCESS
+[2018-10-22 23:03:10.9484066] P2P < SUCCESS
+
+[2018-10-22 23:03:09.30461788] [ssh connection 2] [ThreadId 11] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-10-22 23:03:09.304949382] [ssh connection 2] [ThreadId 11] P2P > VERSION 1
+[2018-10-22 23:03:09.306349793] [ssh connection 2] [ThreadId 11] P2P < VERSION 1
+[2018-10-22 23:03:09.306552423] [ssh connection 2] [ThreadId 11] P2P > GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz
+[2018-10-22 23:03:09.307525458] P2P < GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz
+\"\"\"]]
+
+So the second connection received the GET request, but did not respond to
+it, or its response was not received.
+
+Maybe try replaying the same protocol on the server manually. Eg:
+
+	ssh bids@rolando.cns -T git-annex-shell p2pstdio /inbox/BIDS/dbic/QA --debug ed495e60-f4c1-4a9b-86fd-0b3cec9689a6 --uuid 6384a551-a41d-4290-b186-9258befede9
+	VERSION 1
+	GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz
+
+If it doesn't reply with DATA, then it's something to do with that
+one particular key. If it does, the problem must involve concurrency or
+the ssh connection somehow.
+
+---
+
+I have found one possible way this protocol trace could happen, although it seems
+unlikely to be the actual cause here.. But possibly. Dealt with it
+in [[!commit 0b053b96119c1a2d6c2d03ba7f98f032e89b8b66]] which would need
+to be deployed to the server side to test.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_17_c39c3b0978777987dcd8c86906aa6532._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_17_c39c3b0978777987dcd8c86906aa6532._comment
new file mode 100644
index 0000000000..360a9ab395
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_17_c39c3b0978777987dcd8c86906aa6532._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 17"
+ date="2018-11-02T19:58:06Z"
+ content="""
+> If it doesn't reply with DATA, then it's something to do with that one particular key. If it does, the problem must involve concurrency or the ssh connection somehow.
+
+isn't the fact that it works without -j parallelization hints that it is about concurrency and not just the key?
+But for the sake of completeness, I did that \"manual\" `GET 0 sub-qa/s...` snippet and indeed was bombarded with the data.
+
+> Dealt with it in 0b053b96119c1a2d6c2d03ba7f98f032e89b8b66 which would need to be deployed to the server side to test.
+
+ok, will build/test, thanks!
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_18_bffd59a35ae162f4141b6de7efcc7422._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_18_bffd59a35ae162f4141b6de7efcc7422._comment
new file mode 100644
index 0000000000..b02786d1b8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_18_bffd59a35ae162f4141b6de7efcc7422._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="tests fail - can't build to test the change"
+ date="2018-11-02T21:51:16Z"
+ content="""
+the 7.20181031-13-g4d24b712b (7.20181031+git7-g39bff661b did fine) is failing some tests, get/see build logs at 
+<http://neuro.debian.net/_files/_buildlogs/git-annex/7.20181031+git13-g4d24b712b/>
+
+isn't there some CI running tests for git-annex or my failures are standalone build specific?  
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_19_b3fc7c5f6acfa23b6bfd0f709d2f6b96._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_19_b3fc7c5f6acfa23b6bfd0f709d2f6b96._comment
new file mode 100644
index 0000000000..2aa574f9c3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_19_b3fc7c5f6acfa23b6bfd0f709d2f6b96._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2018-11-05T15:42:45Z"
+ content="""
+I've seen the test fail that way, where apparently all gets from the remote
+repo are failing, on the autobuilders once or twice, but not reproducably,
+so have not been able to track it down yet.
+
+(I was running the test suite hundreds of times overnight
+in a loop to reproduce and fix other intermittent test failures
+just before the v7 release, and never reproduced that failure pattern.)
+
+If you can reproduce that test failure we can work on debugging 
+it on a different bug report.
+
+Anyway, since it replied to DATA for that key, the fix in
+[[!commit 0b053b96119c1a2d6c2d03ba7f98f032e89b8b66]] almost certianly can't
+be for the same problem as this bug.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_1_4916bb94a700e72d42302d2938693daa._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_1_4916bb94a700e72d42302d2938693daa._comment
new file mode 100644
index 0000000000..4d20d7a00c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_1_4916bb94a700e72d42302d2938693daa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="same as another one?"
+ date="2018-09-25T15:35:15Z"
+ content="""
+might relate to my other recent report [about needing to retry while transfering over ssh/rsync](http://git-annex.branchable.com/bugs/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_20_3070880ace124795e07c4f8d1f47e81b._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_20_3070880ace124795e07c4f8d1f47e81b._comment
new file mode 100644
index 0000000000..081461be5f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_20_3070880ace124795e07c4f8d1f47e81b._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 20"""
+ date="2018-11-05T16:25:21Z"
+ content="""
+I'm fairly sure that the problem with no DATA response is not due to an
+implementation bug in the P2P protocol code, since I've read over it all
+and only found the one way it could fail to send DATA, which should be
+reproducible w/o concurrency.
+
+(It would be good to prove that it always sends DATA now, and it should
+be possible to prove things like that about the P2P protocol code, by
+running it in a different free monad interpreter that tests every possible
+input. But I don't have a framework to do that yet.)
+
+Anyway, it would be good to check this at the server end, by stracing
+git-annex-shell. Can you wrap it with a shell script that straces it?
+Eg:
+
+	#!/bin/sh
+	set -e
+	strace -o $HOME/git-annex-shell-strace.$$ -f git-annex-shell "$@"
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_20_797c40af56ddb435db3d4affa86d49a2._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_20_797c40af56ddb435db3d4affa86d49a2._comment
new file mode 100644
index 0000000000..3bced76fec
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_20_797c40af56ddb435db3d4affa86d49a2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 20"
+ date="2018-11-05T15:57:16Z"
+ content="""
+ah, ok -- just now I have mentioned that it did build find for i386... rerunning amd64 build a few times to see how reproducible it is for a lucky me
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_22_35fbdb89eb658439e4125c22a04173a7._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_22_35fbdb89eb658439e4125c22a04173a7._comment
new file mode 100644
index 0000000000..6ef48f4b3b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_22_35fbdb89eb658439e4125c22a04173a7._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 22"
+ date="2018-11-05T17:31:45Z"
+ content="""
+Had to call that script explicitly since my PATH is tuned to point to the directory with this \"wrapper\" so it would call recursively and bail with operation not permitted (to strace already straced thing)
+
+[[!format sh \"\"\"
+#!/bin/sh                                                                                               
+set -e                                                                                                  
+strace -o $HOME/git-annex-shell-strace.$$ -f /afs/dbic.dartmouth.edu/usr/pkg/git-annex/git-annex-shell \"$@\" 
+\"\"\"]]
+
+anyways, sending straces via email
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_23_301141057296da0e01fcc622b4f14dcc._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_23_301141057296da0e01fcc622b4f14dcc._comment
new file mode 100644
index 0000000000..1b998f359a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_23_301141057296da0e01fcc622b4f14dcc._comment
@@ -0,0 +1,69 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2018-11-05T19:14:44Z"
+ content="""
+Straces confirm the hanging git-annex-shell never gets to the point of
+sending "DATA". It does receive the "GET". 
+
+annex.pidlock is set. That's unusual. It seems likely it's got
+something to do with the problem, because pidlocks and concurrency don't
+really mix; at best one git-annex process can hold the pid lock, so
+other processes will need to wait, and could also time out and fail
+to take the pid lock. 
+
+Yeah: Setting annex.pidlock, I can reproduce the hang!
+
+The strace of the non-hanging process shows it took the pid lock and dropped it,
+twice. So the other process should have been able to take the pid lock too.
+
+The hanging process does something around taking the pid lock just before
+it hangs.
+
+It checks the side lock, which is locked (this is `trySideLock`):
+
+	6219  openat(AT_FDCWD, "/dev/shm/08d71513c120bda153ed3b773c1e59ff_BIDS_dbic_QA_.git_annex_pidlock.lck", O_RDWR|O_CREAT, 0666 <unfinished ...>
+	6286  futex(0x555f91523d2c, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
+	6219  <... openat resumed> )            = 11
+	6219  fcntl(11, F_GETFD)                = 0
+	6219  fcntl(11, F_SETFD, FD_CLOEXEC)    = 0
+	6219  fcntl(11, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = -1 EAGAIN (Resource temporarily unavailable)
+	6219  close(11)                         = 0
+
+Then it checks the pid lock (this is `tryLock` when
+`linkToLock` fails due to the side lock not being held):
+
+	6219  openat(AT_FDCWD, "XXX/.git/annex/locktmp6219-0", O_RDWR|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK, 0600) = 11
+	6219  openat(AT_FDCWD, "XXX/.git/annex/pidlock", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11
+	6219  fstat(11, {st_mode=S_IFREG|0444, st_size=52, ...}) = 0
+	6219  ioctl(11, TCGETS, 0x7ffd3c59ba90) = -1 ENOTTY (Inappropriate ioctl for device)
+	6219  uname({sysname="Linux", nodename="XXX", ...}) = 0
+	6219  stat("XXX/.git/annex/locktmp6219-0", {st_mode=S_IFREG|0444, st_size=52, ...}) = 0
+	6219  read(11, "PidLock {lockingPid = 6221, lock"..., 8192) = 52
+
+And gives up without overwriting it:
+
+	6219  unlink("XXX/.git/annex/locktmp6219-0") = 0
+	6219  unlink("XXX/.git/annex/locktmp6219-0") = -1 ENOENT (No such file or directory)
+
+And then hangs waiting on stdin, it looks lile:
+
+	6219  poll([{fd=0, events=POLLIN}], 1, 0) = 0 (Timeout)
+	6219  epoll_ctl(3, EPOLL_CTL_MOD, 0, {EPOLLIN|EPOLLONESHOT, {u32=0, u64=0}}) = 0
+	6219  futex(0x555f91523c0c, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
+	6285  <... read resumed> "\1\0\0\0\0\0\0\0", 8) = 8
+	6285  read(4, "\1\0\0\0\0\0\0\0", 8)    = 8
+	6285  read(4, "\1\0\0\0\0\0\0\0", 8)    = 8
+	6285  read(4, "\1\0\0\0\0\0\0\0", 8)    = 8
+	6285  read(4, "\1\0\0\0\0\0\0\0", 8)    = 8
+
+Seems it was not in `waitLock`, because that should loop and `tryLock` again once
+per second.
+
+So, maybe some part of git-annex is calling `tryLock`, and when it fails, it
+somehow ends up blocked waiting for more protocol commands?
+
+My next step now that I can reproduce it is to manually take the pid lock,
+and run git-annex-shell p2pstdio, and see if it's indeed reading more commands from
+stdin despite not responding to GET, or is sending an error or what.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_24_1c96a68c27ba09cd1f8c035dd026582b._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_24_1c96a68c27ba09cd1f8c035dd026582b._comment
new file mode 100644
index 0000000000..66406692bc
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_24_1c96a68c27ba09cd1f8c035dd026582b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 24"
+ date="2018-11-05T20:53:48Z"
+ content="""
+Great to hear that bottom issue is revealed!
+
+FWIW regarding
+
+> If you wait 300 seconds, it should give up waiting for the pid lock, and complain about it to stderr, which may or may not be visible across the ssh connection.
+
+waited for ~50 minutes, `git annex get` process is still hanging without any additional output provided
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_25_d107200df348bc2b97e2fefc4342e49a._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_25_d107200df348bc2b97e2fefc4342e49a._comment
new file mode 100644
index 0000000000..08dcaed633
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_25_d107200df348bc2b97e2fefc4342e49a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 25"
+ date="2018-11-05T21:01:35Z"
+ content="""
+Re
+
+> I've seen the test fail that way, where apparently all gets from the remote repo are failing, on the autobuilders once or twice, but not reproducably...
+
+Unfortunately this time I was not as fortunate to reliably reproduce it (yet) :-(  for me I believe it happened for the first time ever although I could be wrong.
+How do you know which test(s) fail and how to restart only a failing test (e.g. by name?) -- I find it difficult to parse logged output to figure out test names/boundaries since intermixed with git output etc which also includes error messages on conflicts etc.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_26_a3d803f25795365c9651d2ec023d9145._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_26_a3d803f25795365c9651d2ec023d9145._comment
new file mode 100644
index 0000000000..d8e5aa97ee
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_26_a3d803f25795365c9651d2ec023d9145._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 26"""
+ date="2018-11-05T21:32:20Z"
+ content="""
+tryLockExclusive is returning Nothing before the hang, when runTransfer 
+tries to lock the transfer log file. So runTransfer returns without 
+running the transfer action.
+
+Aha! ReadContent tries to run a transfer, and it calls
+sinkfile with sender in the transfer action.
+Never run, and so DATA never gets sent and indeed git-annex-shell is
+waiting for the next command.
+
+Using alwaysRunTransfer would solve this; that's what Command.SendKey does.
+And it would let concurrent downloads from a annex.pidlock remote work.
+However, I'm not entirely happy with that, because as this shows any bug in
+there that prevents the transfer action being run will lead to a protocol
+stall. Seems it ought to detect when the transfer action didn't run, and
+error out, somehow.
+
+Note that StoreContent also runs a transfer, but that does not involve
+running a callback. So, might be ok. But, it may not consume the DATA
+from the sender, so I need to look at it too.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_27_0f2e6c7dbfbb3007d4e3f7faa63d16b4._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_27_0f2e6c7dbfbb3007d4e3f7faa63d16b4._comment
new file mode 100644
index 0000000000..77857611f8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_27_0f2e6c7dbfbb3007d4e3f7faa63d16b4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 27"""
+ date="2018-11-06T16:55:17Z"
+ content="""
+Preliminary fix in place, but have not yet done anything more to guarantee that
+other failures don't prevent it from sending DATA.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_28_0812ef7942034a4ece952dd8069813a3._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_28_0812ef7942034a4ece952dd8069813a3._comment
new file mode 100644
index 0000000000..3506ed780e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_28_0812ef7942034a4ece952dd8069813a3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 28"""
+ date="2018-11-06T18:48:29Z"
+ content="""
+I now have a comprehensive fix in place, including fixing similar bad
+behavior when uploading different objects concurrently to a remote with
+annex.pidlock=yes or the same object concurrently to a remote not using
+pidlock.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_29_c18ec0797bd55780a0851c3b0c71b184._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_29_c18ec0797bd55780a0851c3b0c71b184._comment
new file mode 100644
index 0000000000..7ffe2913e1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_29_c18ec0797bd55780a0851c3b0c71b184._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 29"
+ date="2018-11-06T20:01:08Z"
+ content="""
+whoohoo!  thanks!  am I reading changelog correctly that fix should be \"applied\" on remote side (`git-annex-shell`) and not on local (`git annex get`)?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_2_8d391bacf291492846d9253057653082._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_2_8d391bacf291492846d9253057653082._comment
new file mode 100644
index 0000000000..1116dca82a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_2_8d391bacf291492846d9253057653082._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-09-25T17:01:00Z"
+ content="""
+All this debug output means nothing to me, what operation is it stalling
+on?
+
+	{"command":"get","wanted":[{"here":false,"uuid":"6384a551-a41d-4290-b186-9258befede97","description":"bids@rolando:/inbox/BIDS/dbic/QA [origin]"}],"note":"transfer already in progress, or unable to take transfer lock\nUnable to access these remotes: origin\nTry making some of these repositories available:\n\t6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA [origin]\n","skipped":[],"success":false,"key":"SHA256E-s1633--1bc7a100b82cd31d084aae5b25b8d90af128324d10d92cfc9e2196d28829d375.tsv","file":".heudiconv/qa/ses-20171106/info/dicominfo_ses-20171106.tsv"}
+
+Are two files in the set of files you operated on both pointing at this key?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_30_2bee4762be30b9864083ed1d32fe942e._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_30_2bee4762be30b9864083ed1d32fe942e._comment
new file mode 100644
index 0000000000..2d6d5f40cf
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_30_2bee4762be30b9864083ed1d32fe942e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 30"""
+ date="2018-11-12T16:09:59Z"
+ content="""
+Yes, git-annex-shell needs to be upgraded for the problem you reported.
+The other related problems I found also need git-annex to be upgraded
+to be fixed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_3_6f228fa6770aad308d0f99647ac21347._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_3_6f228fa6770aad308d0f99647ac21347._comment
new file mode 100644
index 0000000000..92daaeba35
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_3_6f228fa6770aad308d0f99647ac21347._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2018-09-25T22:28:49Z"
+ content="""
+> All this debug output means nothing to me, what operation is it stalling on?
+
+Do you mean that command I have pasted in the beginning `git annex get -J 16 --debug --json-progress .`? if something else, I cannot add beyond that command and `--debug` output.
+
+> Are two files in the set of files you operated on both pointing at this key?
+
+Ha, good question... seems to be not?:
+
+[[!format sh \"\"\"
+$> git clone http://datasets.datalad.org/dbic/QA/.git
+Cloning into 'QA'...
+
+$> cd QA
+
+$> find -lname */SHA256E-s1633--1bc7a100b82cd31d084aae5b25b8d90af128324d10d92cfc9e2196d28829d375.tsv 
+./.heudiconv/qa/ses-20171106/info/dicominfo_ses-20171106.tsv
+
+\"\"\"]]
+the only thing is that I have interrupted some previous stalled `get` invocations so may be it is somehow related?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_4_3eaebe28f2925cac21a49f30aed3fa3c._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_4_3eaebe28f2925cac21a49f30aed3fa3c._comment
new file mode 100644
index 0000000000..328c047313
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_4_3eaebe28f2925cac21a49f30aed3fa3c._comment
@@ -0,0 +1,239 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="reproducible, no locking message, many &quot;duplicate&quot; files"
+ date="2018-09-26T00:06:29Z"
+ content="""
+tried to replicate from other hosts, but without success, so might be something specific about that one (original repo is on NFS (mount options rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.232.11.5,mountvers=3,mountport=1009,mountproto=udp,local_lock=none,addr=10.232.11.5), CentOS Linux release 7.4.1708 (Core), git annex 6.20180808-ga1327779a, OpenSSH_7.4p1, OpenSSL 1.0.2k-fips).  This time it is also without any message about being unable to lock:
+
+[[!format sh \"\"\"
+$> git clone bids@rolando.cns:/inbox/BIDS/dbic/QA
+Cloning into 'QA'...
+
+
+    Dartmouth College, Department of Psychological and Brain Sciences
+                      Authorized access only
+
+
+
+
+remote: Counting objects: 26086, done.
+remote: Compressing objects: 100% (9257/9257), done.
+remote: Total 26086 (delta 11366), reused 25687 (delta 10968)
+Receiving objects: 100% (26086/26086), 30.63 MiB | 53.17 MiB/s, done.
+Resolving deltas: 100% (11366/11366), done.
+1 13074.....................................:Tue 25 Sep 2018 07:39:11 PM EDT:.
+smaug:/tmp
+$> cd QA
+CHANGES    dataset_description.json  sub-emmet/                                        task-rest_acq-3mm_bold.json                 task-rest_acq-p2Xs4X35mm_bold.json
+README     participants.tsv          sub-qa/                                           task-rest_acq-noXgrappa_bold.json           task-rest_acq-p2_bold.json
+README.md  sourcedata/               sub-sid000143/                                    task-rest_acq-p22_bold.json                 task-rest_acq-p2noprescannormalize_bold.json
+code/      sub-amit/                 task-rest_acq-24mm64sl1000tr32te600dyn_bold.json  task-rest_acq-p2XB0shimXadvanced_bold.json
+1 13075.....................................:Tue 25 Sep 2018 07:39:12 PM EDT:.
+(git)smaug:/tmp/QA[master]
+$> git annex get -J16 --debug --json --json-progress .                            
+[2018-09-25 19:39:24.076576505] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2018-09-25 19:39:24.08073842] process done ExitSuccess
+[2018-09-25 19:39:24.080921239] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-09-25 19:39:24.083832166] process done ExitFailure 1
+[2018-09-25 19:39:24.084026056] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--verify\",\"-q\",\"origin/git-annex\"]
+[2018-09-25 19:39:24.086534115] process done ExitFailure 1
+[2018-09-25 19:39:24.087406723] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2018-09-25 19:39:24.090577834] process done ExitSuccess
+[2018-09-25 19:39:24.090805078] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\",\"--no-gpg-sign\"]
+[2018-09-25 19:39:24.094384723] process done ExitSuccess
+[2018-09-25 19:39:24.094571341] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"0fd8155db835617a672760453bf6fd0786d16ea7\"]
+[2018-09-25 19:39:24.099179252] process done ExitSuccess
+[2018-09-25 19:39:24.163625058] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"annex.uuid\",\"e57c285c-4145-4c57-9e9c-73c29a6dc115\"]
+[2018-09-25 19:39:24.167183166] process done ExitSuccess
+[2018-09-25 19:39:24.167313312] read: git [\"config\",\"--null\",\"--list\"]
+[2018-09-25 19:39:24.171253975] process done ExitSuccess
+[2018-09-25 19:39:24.182032449] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2018-09-25 19:39:24.183696686] process done ExitSuccess
+[2018-09-25 19:39:24.183777495] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-09-25 19:39:24.185400318] process done ExitSuccess
+[2018-09-25 19:39:24.185531597] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..0fd8155db835617a672760453bf6fd0786d16ea7\",\"--pretty=%H\",\"-n1\"]
+[2018-09-25 19:39:24.18734038] process done ExitSuccess
+[2018-09-25 19:39:24.187415347] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..70f0788641a4b3b77353b14ee6db0986a1c1e682\",\"--pretty=%H\",\"-n1\"]
+[2018-09-25 19:39:24.191055467] process done ExitSuccess
+[2018-09-25 19:39:24.191255165] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:24.191633582] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:24.193406759] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2018-09-25 19:39:24.193797713] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+[2018-09-25 19:39:24.19424715] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"70f0788641a4b3b77353b14ee6db0986a1c1e682\",\"--\"]
+[2018-09-25 19:39:24.402505793] process done ExitSuccess
+[2018-09-25 19:39:24.411127976] process done ExitSuccess
+[2018-09-25 19:39:24.411819307] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"70f0788641a4b3b77353b14ee6db0986a1c1e682..refs/heads/git-annex\",\"--pretty=%H\",\"-n1\"]
+[2018-09-25 19:39:24.414936679] process done ExitSuccess
+[2018-09-25 19:39:24.415127364] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2018-09-25 19:39:24.426606063] process done ExitSuccess
+[2018-09-25 19:39:24.426728558] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"961159c1de057d7120f7cea5c0f151954ab400c1\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\",\"-p\",\"70f0788641a4b3b77353b14ee6db0986a1c1e682\"]
+[2018-09-25 19:39:24.42982717] process done ExitSuccess
+[2018-09-25 19:39:24.429968237] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"691a2081d0839b84e286f50330ffbb0fa4dfc22f\"]
+[2018-09-25 19:39:24.433255645] process done ExitSuccess
+[2018-09-25 19:39:24.434830328] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"annex.version\",\"5\"]
+[2018-09-25 19:39:24.436846163] process done ExitSuccess
+[2018-09-25 19:39:24.436926679] read: git [\"config\",\"--null\",\"--list\"]
+[2018-09-25 19:39:24.449483362] process done ExitSuccess
+[2018-09-25 19:39:24.449648554] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2018-09-25 19:39:24.452355348] process done ExitSuccess
+[2018-09-25 19:39:24.452485849] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2018-09-25 19:39:24.455464092] process done ExitSuccess
+[2018-09-25 19:39:24.455563403] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2018-09-25 19:39:24.458025223] process done ExitSuccess
+[2018-09-25 19:39:24.458139592] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/master\"]
+[2018-09-25 19:39:24.461541709] process done ExitSuccess
+[2018-09-25 19:39:24.461682534] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"checkout\",\"-q\",\"-B\",\"master\"]
+[2018-09-25 19:39:24.523918634] process done ExitSuccess
+[2018-09-25 19:39:24.525217891] read: uname [\"-n\"]
+[2018-09-25 19:39:24.527130923] process done ExitSuccess
+[2018-09-25 19:39:24.528961091] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\".\"]
+[2018-09-25 19:39:24.53401854] read: ssh [\"-o\",\"BatchMode=true\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"bids@rolando.cns\",\"true\"]
+[2018-09-25 19:39:26.071148456] process done ExitSuccess
+[2018-09-25 19:39:26.071456884] read: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"git-annex-shell 'configlist' '/inbox/BIDS/dbic/QA' '--debug'\"]
+[2018-09-25 19:39:27.533523078] process done ExitSuccess
+[2018-09-25 19:39:27.533732629] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"remote.origin.annex-uuid\",\"6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:27.541031187] process done ExitSuccess
+[2018-09-25 19:39:27.541185336] read: git [\"config\",\"--null\",\"--list\"]
+[2018-09-25 19:39:27.546614539] process done ExitSuccess
+[2018-09-25 19:39:27.548934829] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:27.54893425] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:27.5490026] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:27.54908919] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:27.549123562] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:27.549156199] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:27.549209727] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:27.549329392] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:27.549398039] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:27.549438971] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:27.549469661] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:27.549491832] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 19:39:27.549500665] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:27.549677068] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:27.549933199] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:27.550251508] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:27.550728146] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:27.552286946] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:27.552666906] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:27.552969316] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:27.553792735] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:27.55697274] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:27.557179172] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:27.557586095] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-25 19:39:27.559528852] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'e57c285c-4145-4c57-9e9c-73c29a6dc115' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:27.560166953] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'e57c285c-4145-4c57-9e9c-73c29a6dc115' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:27.560470671] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'e57c285c-4145-4c57-9e9c-73c29a6dc115' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:27.609120855] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'e57c285c-4145-4c57-9e9c-73c29a6dc115' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:27.628746035] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'e57c285c-4145-4c57-9e9c-73c29a6dc115' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:27.629098606] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'e57c285c-4145-4c57-9e9c-73c29a6dc115' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:27.642438219] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'e57c285c-4145-4c57-9e9c-73c29a6dc115' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:27.642444075] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'e57c285c-4145-4c57-9e9c-73c29a6dc115' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:27.642633512] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'e57c285c-4145-4c57-9e9c-73c29a6dc115' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:27.642685766] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'e57c285c-4145-4c57-9e9c-73c29a6dc115' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:27.64756999] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'e57c285c-4145-4c57-9e9c-73c29a6dc115' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:27.64783317] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'e57c285c-4145-4c57-9e9c-73c29a6dc115' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-25 19:39:29.140327887] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 19:39:29.140500055] P2P > VERSION 1
+[2018-09-25 19:39:29.141624424] P2P < VERSION 1
+[2018-09-25 19:39:29.141769124] P2P > GET 0 .heudiconv/amit/ses-20180508/info/dicominfo_ses-20180508.tsv SHA256E-s2072--84342b6857db244be0bfa97d4289ee6206ba8e34bb11dc23262f609b6478e783.tsv
+[2018-09-25 19:39:29.1419719] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 19:39:29.142163513] P2P > VERSION 1
+[2018-09-25 19:39:29.143097033] P2P < GET 0 .heudiconv/amit/ses-20180508/info/dicominfo_ses-20180508.tsv SHA256E-s2072--84342b6857db244be0bfa97d4289ee6206ba8e34bb11dc23262f609b6478e783.tsv[2018-09-25 19:39:29.143589471] P2P < VERSION 1
+[2018-09-25 19:39:29.14370964] P2P > GET 0 .heudiconv/amit/ses-20180508/info/amit_ses-20180508.edit.txt SHA256E-s551--bc05c5596a6cf03ad7d302aab294dac7b45ecfcb96f7469085520660bf1c3e29.edit.txt
+[2018-09-25 19:39:29.145075908] P2P < GET 0 .heudiconv/amit/ses-20180508/info/amit_ses-20180508.edit.txt SHA256E-s551--bc05c5596a6cf03ad7d302aab294dac7b45ecfcb96f7469085520660bf1c3e29.edit.txt[2018-09-25 19:39:29.172581646] P2P > DATA 2072[2018-09-25 19:39:29.172391553] P2P < DATA 2072
+[2018-09-25 19:39:29.17275537] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 19:39:29.172869445] P2P > VERSION 1
+[2018-09-25 19:39:29.1739641] P2P < VERSION 1
+[2018-09-25 19:39:29.174135119] P2P > GET 0 .heudiconv/emmet/ses-20180508/info/dicominfo_ses-20180508.tsv SHA256E-s2086--b3e49ddbe4c33b7872c031722b771e66ecfc67468c9d13e9abbaa5fdde2a2851.tsv
+[2018-09-25 19:39:29.17581668] P2P > VALID[2018-09-25 19:39:29.175562895] P2P < GET 0 .heudiconv/emmet/ses-20180508/info/dicominfo_ses-20180508.tsv SHA256E-s2086--b3e49ddbe4c33b7872c031722b771e66ecfc67468c9d13e9abbaa5fdde2a2851.tsv{\"byte-progress\":2072,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s2072--84342b6857db244be0bfa97d4289ee6206ba8e34bb11dc23262f609b6478e783.tsv\",\"file\":\".heudiconv/amit/ses-20180508/info/dicominfo_ses-20180508.tsv\"},\"total-size\":2072,\"percent-progress\":\"100%\"}
+[2018-09-25 19:39:29.179265924] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 19:39:29.179393396] P2P > VERSION 1
+[2018-09-25 19:39:29.180519354] P2P < VERSION 1
+[2018-09-25 19:39:29.180693554] P2P > GET 0 .heudiconv/emmet/ses-20180521/info/emmet_ses-20180521.auto.txt SHA256E-s2658--42b972cbc99464913e8819e4944071a949914ec2cc7e786cb48fc26b41f665f1.auto.txt
+[2018-09-25 19:39:29.181047474] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 19:39:29.18117293] P2P > VERSION 1
+[2018-09-25 19:39:29.182208685] P2P < VERSION 1
+[2018-09-25 19:39:29.18233901] P2P > GET 0 .heudiconv/amit/ses-20180508/info/amit_ses-20180508.auto.txt SHA256E-s551--bc05c5596a6cf03ad7d302aab294dac7b45ecfcb96f7469085520660bf1c3e29.auto.txt
+[2018-09-25 19:39:29.183648585] P2P < GET 0 .heudiconv/amit/ses-20180508/info/amit_ses-20180508.auto.txt SHA256E-s551--bc05c5596a6cf03ad7d302aab294dac7b45ecfcb96f7469085520660bf1c3e29.auto.txt[2018-09-25 19:39:29.18996796] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 19:39:29.190121603] P2P > VERSION 1
+[2018-09-25 19:39:29.19043361] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 19:39:29.190512631] P2P > VERSION 1
+[2018-09-25 19:39:29.191211455] P2P < VERSION 1
+[2018-09-25 19:39:29.191380774] P2P > GET 0 .heudiconv/emmet/ses-20180508/info/filegroup_ses-20180508.json SHA256E-s222552--1d8be851f4aa959df6cf8b39313f9f8245d4f5c7897f3028eaf671c3140e07db.json
+[2018-09-25 19:39:29.191418345] P2P < VERSION 1
+[2018-09-25 19:39:29.191614568] P2P > GET 0 .heudiconv/emmet/ses-20180521/info/emmet_ses-20180521.edit.txt SHA256E-s2658--42b972cbc99464913e8819e4944071a949914ec2cc7e786cb48fc26b41f665f1.edit.txt
+[2018-09-25 19:39:29.192744192] P2P < GET 0 .heudiconv/emmet/ses-20180508/info/filegroup_ses-20180508.json SHA256E-s222552--1d8be851f4aa959df6cf8b39313f9f8245d4f5c7897f3028eaf671c3140e07db.json[2018-09-25 19:39:29.194287137] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 19:39:29.194417333] P2P > VERSION 1
+[2018-09-25 19:39:29.195415113] P2P < VERSION 1
+[2018-09-25 19:39:29.1956202] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 19:39:29.195628464] P2P > GET 0 .heudiconv/emmet/ses-20180508/info/reproin.py SHA256E-s39141--59c2abfbe8184c851079d1cc0d8b87ddb38239a20d08002610ed81866aff7680.py
+[2018-09-25 19:39:29.195755609] P2P > VERSION 1
+[2018-09-25 19:39:29.196329099] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 19:39:29.196428881] P2P > VERSION 1
+[2018-09-25 19:39:29.197074793] P2P < GET 0 .heudiconv/emmet/ses-20180508/info/reproin.py SHA256E-s39141--59c2abfbe8184c851079d1cc0d8b87ddb38239a20d08002610ed81866aff7680.py[2018-09-25 19:39:29.196872107] P2P < VERSION 1
+[2018-09-25 19:39:29.197063591] P2P > GET 0 .heudiconv/emmet/ses-20180521/info/filegroup_ses-20180521.json SHA256E-s505696--ebc027b49ed92d8020c9f566239782519c9eb2b44945476fd534d3290feab14f.json
+[2018-09-25 19:39:29.197414808] P2P < VERSION 1
+[2018-09-25 19:39:29.19757817] P2P > GET 0 .heudiconv/amit/ses-20180508/info/filegroup_ses-20180508.json SHA256E-s219789--d98a66036a9e3eb96308430cb3b4ac4e741a3cf13373e396ba353dbc46ddb3ec.json
+[2018-09-25 19:39:29.19848677] P2P < GET 0 .heudiconv/emmet/ses-20180521/info/filegroup_ses-20180521.json SHA256E-s505696--ebc027b49ed92d8020c9f566239782519c9eb2b44945476fd534d3290feab14f.json[2018-09-25 19:39:29.198940575] P2P < GET 0 .heudiconv/amit/ses-20180508/info/filegroup_ses-20180508.json SHA256E-s219789--d98a66036a9e3eb96308430cb3b4ac4e741a3cf13373e396ba353dbc46ddb3ec.json[2018-09-25 19:39:29.285402553] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-25 19:39:29.285533748] P2P > VERSION 1
+[2018-09-25 19:39:29.286629667] P2P < VERSION 1
+[2018-09-25 19:39:29.286785793] P2P > GET 0 .heudiconv/emmet/ses-20180531/info/dicominfo_ses-20180531.tsv SHA256E-s2569--52f497d72d0ccd90f9405ec9ba26ff01d37257e618d9d836ebc56d60aa90413f.tsv
+[2018-09-25 19:39:29.288268229] P2P < GET 0 .heudiconv/emmet/ses-20180531/info/dicominfo_ses-20180531.tsv SHA256E-s2569--52f497d72d0ccd90f9405ec9ba26ff01d37257e618d9d836ebc56d60aa90413f.tsv[2018-09-25 19:39:29.179261499] P2P > AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97[2018-09-25 19:39:29.190593096] P2P > AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97[2018-09-25 19:39:29.180612292] P2P < VERSION 1[2018-09-25 19:39:29.191640719] P2P < VERSION 1[2018-09-25 19:39:29.180837225] P2P > VERSION 1[2018-09-25 19:39:29.191763909] P2P > VERSION 1[2018-09-25 19:39:29.182014203] P2P < GET 0 .heudiconv/emmet/ses-20180521/info/emmet_ses-20180521.auto.txt SHA256E-s2658--42b972cbc99464913e8819e4944071a949914ec2cc7e786cb48fc26b41f665f1.auto.txt[2018-09-25 19:39:29.192947297] P2P < GET 0 .heudiconv/emmet/ses-20180521/info/emmet_ses-20180521.edit.txt SHA256E-s2658--42b972cbc99464913e8819e4944071a949914ec2cc7e786cb48fc26b41f665f1.edit.txt[2018-09-25 19:39:29.319628794] P2P < VALID
+[2018-09-25 19:39:29.31975345] P2P > SUCCESS
+[2018-09-25 19:39:29.321050683] P2P < SUCCESS{\"command\":\"get\",\"note\":\"from origin...\nchecksum...\",\"success\":true,\"key\":\"SHA256E-s2072--84342b6857db244be0bfa97d4289ee6206ba8e34bb11dc23262f609b6478e783.tsv\",\"file\":\".heudiconv/amit/ses-20180508/info/dicominfo_ses-20180508.tsv\"}
+[2018-09-25 19:39:29.326554415] P2P > GET 0 .heudiconv/emmet/ses-20180531/info/emmet_ses-20180531.auto.txt SHA256E-s1317--7eca0e85c908fbf855e085d4514d025ab401c3673fe63f4af04e24ac5cf049fa.auto.txt
+
+
+\"\"\"]]
+and nothing more...
+
+indeed though there is a good number of files pointing to the same annex keys
+
+[[!format sh \"\"\"
+(git)smaug:/tmp/QA[master]git
+$> find -type l | while read f; do readlink $f | xargs basename || echo ERROR; done | sort | uniq -c | sort -n | nl | tail -n 20
+  1168          1 SHA256E-s9234655--441a4f30bdda1378ab9a55c682e075af8f6660ddf3c20b6bdd0ade5e788183c0.nii.gz
+  1169        1 SHA256E-s9236756--b761702178efdb66a7165ac21433ea65cee844231d85ce2b3699dbf6f9f10439.nii.gz
+  1170        1 SHA256E-s9251135--903bfe4fa818f8773a3617090c6545d9bbc45f7287cbb4727fa784365bb17ccc.nii.gz
+  1171        1 SHA256E-s9266850--97c97de7fcb552893dfd48e78d98d8300bfa26a51d56ef112675b91df55f1aca.nii.gz
+  1172        1 SHA256E-s93--ddf04c5c23b143330b4e4ea83dfbbdf07b48acb64f3cfd309147a5cc2c6487f8
+  1173        1 SHA256E-s9678246--6048a63eac04b294cd4ef06c217da1ec19b9733ece68991da0ab4200363dad1c.tgz
+  1174        2 SHA256E-s11626616--d9b4f8bc420f09c2b43a0967f12421295fb500c0311b40d1cd2de0f7881d2f48.nii.gz
+  1175        2 SHA256E-s43413657--dc9a866b5100af7129acac14d3fb31e3404767349dda2d7cbde42bcb2cd5fa45.nii.gz
+  1176        2 SHA256E-s551--bc05c5596a6cf03ad7d302aab294dac7b45ecfcb96f7469085520660bf1c3e29.auto.txt
+  1177        2 SHA256E-s551--bc05c5596a6cf03ad7d302aab294dac7b45ecfcb96f7469085520660bf1c3e29.edit.txt
+  1178        4 SHA256E-s39141--59c2abfbe8184c851079d1cc0d8b87ddb38239a20d08002610ed81866aff7680.py
+  1179        7 SHA256E-s736--bb53d9a3cf00df009e6a53d1960ec76796e46dc32dd92e5349a48c8c00d50df9.auto.txt
+  1180        7 SHA256E-s736--bb53d9a3cf00df009e6a53d1960ec76796e46dc32dd92e5349a48c8c00d50df9.edit.txt
+  1181        9 SHA256E-s685--fc402d82b86dcfb0b1736d176948e7b9d368af063f92fcdb730f068b5e30e04f.auto.txt
+  1182        9 SHA256E-s685--fc402d82b86dcfb0b1736d176948e7b9d368af063f92fcdb730f068b5e30e04f.edit.txt
+  1183       31 SHA256E-s598--492217a4a3191ce3d7848e60138c31315152fdf85d902fdbc98b6f642cd4b859.auto.txt
+  1184       31 SHA256E-s598--492217a4a3191ce3d7848e60138c31315152fdf85d902fdbc98b6f642cd4b859.edit.txt
+  1185       34 SHA256E-s857--15709030cff9f43cd0b8f7e91a184dfde283215a017704da01380202d2f55425.auto.txt
+  1186       34 SHA256E-s857--15709030cff9f43cd0b8f7e91a184dfde283215a017704da01380202d2f55425.edit.txt
+  1187       92 SHA256E-s39894--637a4b00403a5c88835c6d1ffb3f611d68b6377d95c5f7751e33539b598b18a3.py
+1 13093.....................................:Tue 25 Sep 2018 08:04:56 PM EDT:.
+(git)smaug:/tmp/QA[master]git
+$> git annex info                                                                                                               
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 6
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA [origin]
+        7d9ed214-3e5f-4cc8-ac88-f397145b2d4c -- yoh@falkor:/srv/datasets.datalad.org/www/dbic/QA
+        ba8f2cea-f229-422c-82be-6580e5e07ed5 -- yoh@smaug:/mnt/datasets/datalad/crawl/dbic/QA
+        e57c285c-4145-4c57-9e9c-73c29a6dc115 -- yoh@smaug:/tmp/QA [here]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 3.35 gigabytes (+1 megabyte reserved)
+local annex keys: 4
+local annex size: 246.75 kilobytes
+annexed files in working tree: 1439
+size of annexed files in working tree: 39.52 gigabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+        SHA256E: 1439
+\"\"\"]]
+so only 1187 unique keys for 1439 files.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_5_c31884e8d52324c0e04cdbbee42d4d35._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_5_c31884e8d52324c0e04cdbbee42d4d35._comment
new file mode 100644
index 0000000000..379e51b555
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_5_c31884e8d52324c0e04cdbbee42d4d35._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2018-09-26T13:47:35Z"
+ content="""
+FWIW, some anecdotal evidences/observations:
+
+After upgrade to 6.20180913+git149-g23bd27773-1~ndall+1 (resolving that `get` issue over ssh with elderly annexes) I thought that I started to see that `get` does not stall in a fresh git clone of the repository
+while `get` was still stalling in the git clone where I have tried to get (and stalled) with 6.20180913+git52-gdb1644808-1~ndall+1.  Removing files under `.git/annex/tmp` seemed to make `get` on the next run behave better...  But then I still started to observe stalling from time to time, although it felt that it started to happen **much** more rarely.
+
+Despite -J flag, and starting a large number of  `git-annex-shell 'p2pstdio'`, transmission seems to happen one file at a time, nothing is really parallelized.  I see a single file being downloaded reported by `datalad` (which processes --json --json-progress output) or just observing output of `git annex get -J16 .` (or even just -J2) having only a single % line running at the bottom.
+
+On one run I got a new beasty error reported: `hGetChar: illegal operation`:
+
+[[!format sh \"\"\"
+$> git annex get -J16 .
+get sourcedata/sub-qa/ses-20170807/func/sub-qa_ses-20170807_task-rest_acq-p2Xs4X35mm_bold.dicom.tgz (from origin...) (checksum...) ok
+get sourcedata/sub-qa/ses-20170828/func/sub-qa_ses-20170828_task-rest_acq-p2Xs4X35mm_bold.dicom.tgz (from origin...) (checksum...) ok
+get sourcedata/sub-qa/ses-20170905/func/sub-qa_ses-20170905_task-rest_acq-p2Xs4X35mm_bold.dicom.tgz (from origin...) 
+  Lost connection (fd:167: hGetChar: illegal operation (handle is closed))
+
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+  	6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA [origin]
+   	7d9ed214-3e5f-4cc8-ac88-f397145b2d4c -- yoh@falkor:/srv/datasets.datalad.org/www/dbic/QA
+   	ba8f2cea-f229-422c-82be-6580e5e07ed5 -- yoh@smaug:/mnt/datasets/datalad/crawl/dbic/QA
+failed
+get sourcedata/sub-qa/ses-20170905/dwi/sub-qa_ses-20170905_acq-DTIX30Xp2_dwi.dicom.tgz (from origin...) (checksum...) ok
+get sourcedata/sub-qa/ses-20170911/dwi/sub-qa_ses-20170911_acq-DTIX30Xp2Xs4_dwi.dicom.tgz (from origin...) (checksum...) ok
+....
+42%   34.86 MiB        52 MiB/s 0s
+\"\"\"]]
+may be it is somehow related.
+
+Raising -J to some obscene value (32) causes a collection of the `Unable to access these remotes: origin`, some include that `Lost connection (fd:323: hGetChar: illegal operation (handle is closed))`, some not. Someone could argue that it would be expected...
+
+Overall:
+- I think that stalling situation did improve, although not entirely resolved.
+- Not sure if annex is actually doing any parallel transfer over ssh
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_6_0707380cc043d9bbb84f0232eb1c1322._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_6_0707380cc043d9bbb84f0232eb1c1322._comment
new file mode 100644
index 0000000000..32945294fe
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_6_0707380cc043d9bbb84f0232eb1c1322._comment
@@ -0,0 +1,105 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="&quot;minimal&quot; reproducible case"
+ date="2018-09-26T16:03:13Z"
+ content="""
+Finally I've boiled down to a small reproducible case for the stall with the bleeding edge 6.20180913+git149-g23bd27773-1~ndall+1 build:
+
+[[!format sh \"\"\"
+(git)smaug:/mnt/btrfs/scrap/tmp/QA[master]git
+$> git annex drop --fast sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz
+drop sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz (locking origin...) ok
+drop sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz (locking origin...) ok
+drop sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz (locking origin...) ok
+(recording state in git...)
+
+$> git annex get --debug -c remote.origin.annex-ssh-options='-o ControlMaster=auto -S /home/yoh/.cache/datalad/sockets/478606ac' --json --json-progress -J2 -- sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz
+{\"byte-progress\":32752,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"0.13%\"}
+{\"byte-progress\":4159504,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"16.77%\"}
+{\"byte-progress\":8253504,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"33.28%\"}
+{\"byte-progress\":12347504,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"49.79%\"}
+{\"byte-progress\":16539760,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"66.7%\"}
+{\"byte-progress\":20699264,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"83.47%\"}
+{\"byte-progress\":24797353,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"100%\"}
+{\"command\":\"get\",\"note\":\"from origin...\nchecksum...\",\"success\":true,\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"}
+{\"byte-progress\":32752,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"0.1%\"}
+{\"byte-progress\":4683536,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"14.04%\"}
+{\"byte-progress\":9694592,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"29.07%\"}
+{\"byte-progress\":11790720,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"35.35%\"}
+{\"byte-progress\":18373872,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"55.09%\"}
+{\"byte-progress\":23417680,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"70.21%\"}
+{\"byte-progress\":28461488,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"85.33%\"}
+{\"byte-progress\":33352666,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"100%\"}
+{\"command\":\"get\",\"note\":\"from origin...\nchecksum...\",\"success\":true,\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"}
+
+
+\"\"\"]]
+
+So it gets stuck after having 2 out of 3 files transmitted.  With -J8 (in above it is -J2) it stalls after the first one.  Similarly stalls (there is more --debug output) if I do not reuse the ssh socket:
+[[!format sh \"\"\"
+$> git annex get --debug --json --json-progress -J2 -- sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz              
+[2018-09-26 11:59:52.123811672] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\",\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz\",\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"]
+[2018-09-26 11:59:52.127664351] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2018-09-26 11:59:52.132089355] process done ExitSuccess
+[2018-09-26 11:59:52.132238783] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-09-26 11:59:52.135559006] process done ExitSuccess
+[2018-09-26 11:59:52.135835934] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..eb4d1df5604157f25b3f2f272413e4a3fb59dc2d\",\"--pretty=%H\",\"-n1\"]
+[2018-09-26 11:59:52.139675103] process done ExitSuccess
+[2018-09-26 11:59:52.140319876] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-26 11:59:52.140817819] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-26 11:59:52.146834989] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-26 11:59:52.146890494] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-26 11:59:52.147529819] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-26 11:59:52.147813727] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-09-26 11:59:52.154567936] read: ssh [\"-o\",\"BatchMode=true\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"bids@rolando.cns\",\"true\"]
+[2018-09-26 11:59:52.155552005] read: ssh [\"-o\",\"BatchMode=true\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"bids@rolando.cns\",\"true\"]
+[2018-09-26 11:59:53.680319247] process done ExitSuccess
+[2018-09-26 11:59:53.680436536] process done ExitSuccess
+[2018-09-26 11:59:53.680671127] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'c807100d-3e57-4198-9a25-a9d434f493a9' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-26 11:59:53.680730098] chat: ssh [\"bids@rolando.cns\",\"-S\",\".git/annex/ssh/bids@rolando.cns\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'c807100d-3e57-4198-9a25-a9d434f493a9' --uuid 6384a551-a41d-4290-b186-9258befede97\"]
+[2018-09-26 11:59:55.15893547] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-26 11:59:55.15895813] P2P < AUTH-SUCCESS 6384a551-a41d-4290-b186-9258befede97
+[2018-09-26 11:59:55.159205411] P2P > VERSION 1
+[2018-09-26 11:59:55.159313796] P2P > VERSION 1
+[2018-09-26 11:59:55.160624999] P2P < VERSION 1
+[2018-09-26 11:59:55.160742428] P2P < VERSION 1
+[2018-09-26 11:59:55.162001851] P2P > VERSION 1[2018-09-26 11:59:55.160845243] P2P > GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz
+[2018-09-26 11:59:55.160943268] P2P > GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz
+[2018-09-26 11:59:55.163615313] P2P < GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz[2018-09-26 11:59:55.163667046] P2P < GET 0 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz[2018-09-26 11:59:55.196799694] P2P > DATA 24797353[2018-09-26 11:59:55.19553292] P2P < DATA 24797353
+{\"byte-progress\":32752,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"0.13%\"}
+{\"byte-progress\":3930240,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"15.85%\"}
+{\"byte-progress\":8351760,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"33.68%\"}
+{\"byte-progress\":12675024,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"51.11%\"}
+{\"byte-progress\":17293056,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"69.74%\"}
+{\"byte-progress\":22009344,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"88.76%\"}
+[2018-09-26 11:59:55.759916936] P2P > VALID{\"byte-progress\":24797353,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"},\"total-size\":24797353,\"percent-progress\":\"100%\"}
+[2018-09-26 11:59:55.759776216] P2P < VALID
+[2018-09-26 11:59:55.759965583] P2P > SUCCESS
+[2018-09-26 11:59:55.762270429] P2P < SUCCESS{\"command\":\"get\",\"note\":\"from origin...\nchecksum...\",\"success\":true,\"key\":\"SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz\",\"file\":\"sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz\"}
+[2018-09-26 11:59:55.902055144] P2P > GET 0 sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz
+[2018-09-26 11:59:55.904705166] P2P < GET 0 sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz[2018-09-26 11:59:55.93085693] P2P > DATA 33352666[2018-09-26 11:59:55.929729548] P2P < DATA 33352666
+{\"byte-progress\":32752,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"0.1%\"}
+{\"byte-progress\":5207568,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"15.61%\"}
+{\"byte-progress\":10382384,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"31.13%\"}
+{\"byte-progress\":15720960,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"47.14%\"}
+{\"byte-progress\":21157792,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"63.44%\"}
+{\"byte-progress\":26463616,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"79.34%\"}
+{\"byte-progress\":27511680,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"82.49%\"}
+[2018-09-26 11:59:56.729414189] P2P > VALID{\"byte-progress\":33352666,\"action\":{\"command\":\"get\",\"note\":\"from origin...\",\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"},\"total-size\":33352666,\"percent-progress\":\"100%\"}
+[2018-09-26 11:59:56.729435631] P2P < VALID
+[2018-09-26 11:59:56.729716652] P2P > SUCCESS
+[2018-09-26 11:59:56.732037464] P2P < SUCCESS{\"command\":\"get\",\"note\":\"from origin...\nchecksum...\",\"success\":true,\"key\":\"SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz\",\"file\":\"sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz\"}
+\"\"\"]]
+
+all of those 3 files point to different keys
+[[!format sh \"\"\"
+$> ls -l sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz   
+lrwxrwxrwx 1 yoh yoh 215 Sep 26 09:25 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2Xs4_dwi.nii.gz -> ../../../.git/annex/objects/8p/qK/SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz/SHA256E-s24797353--d1bb6541067f4ba3cdb6a698e2e6e7dbd483d8179007ebd2f2774d11972daf04.nii.gz
+lrwxrwxrwx 1 yoh yoh 215 Sep 26 09:25 sub-qa/ses-20161205/dwi/sub-qa_ses-20161205_acq-DTIX30Xp2_dwi.nii.gz -> ../../../.git/annex/objects/gq/WX/SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz/SHA256E-s26287753--02448aa9a07ef300dcd7b445d178c558bef8048dced539e0cf97a51250c937c8.nii.gz
+lrwxrwxrwx 1 yoh yoh 215 Sep 26 09:25 sub-qa/ses-20161205/func/sub-qa_ses-20161205_task-rest_acq-p2Xs4X35mm_bold.nii.gz -> ../../../.git/annex/objects/8K/85/SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz/SHA256E-s33352666--36efd3512b1dd33192ec0d4e1a615c2a6eb36277fbe817827eb0be0a2c6934ea.nii.gz
+\"\"\"]]
+
+`.git/tmp/annex` is clean (I thought it could have mattered, seems not)
+What other information could I provide?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_7_f7fd86a45b6d5440cdd0588ebb8753c8._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_7_f7fd86a45b6d5440cdd0588ebb8753c8._comment
new file mode 100644
index 0000000000..146d02454b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_7_f7fd86a45b6d5440cdd0588ebb8753c8._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2018-10-03T19:17:35Z"
+ content="""
+It seems to be stalled waiting for data to come in from the pipe from ssh.
+Both the protocol debug and the emailed strace look like that.
+
+I think it's quite likely that this is something in ssh being unhappy with
+a large number of connections. ssh also seems to be closing some of the
+connections while git-annex is still using them.
+
+It would be worth disabling annex.sshcaching to at least eliminate that
+part of ssh.
+
+It would probably make sense to look at the ssh server's logs and see if
+it's throttling connections.
+
+FWIW, I tried a git-annex get -J64 from localhost using ssh and it worked
+without any problems.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_8_7eee5a23aa67cb156aa31fe9fd92dd50._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_8_7eee5a23aa67cb156aa31fe9fd92dd50._comment
new file mode 100644
index 0000000000..1be72299d6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_8_7eee5a23aa67cb156aa31fe9fd92dd50._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 8"
+ date="2018-10-03T20:58:08Z"
+ content="""
+Ok, I will check those should settings/logs. Note that the reproducible example is using -J 2, so there is no larger number of connections
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_9_ee7333607930d8e3fbd4cca2b974c55b._comment b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_9_ee7333607930d8e3fbd4cca2b974c55b._comment
new file mode 100644
index 0000000000..667787a39a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_-J_16_via_ssh_stalls_/comment_9_ee7333607930d8e3fbd4cca2b974c55b._comment
@@ -0,0 +1,68 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="reporting back"
+ date="2018-10-04T20:37:53Z"
+ content="""
+NB that server we are accessing via ssh was even rebooted today, no change
+
+doing `git -c annex.sshcaching=no annex get` didn't make any difference
+
+Here is some logs from the server with comments from myself (on `#`-prefixed lines):
+
+[[!format sh \"\"\"
+Oct  4 16:24:50 localhost sshd[11428]: Accepted publickey for bids from 129.XXX.XXX.XXX port 40052 ssh2: RSA SHA256:XXX
+Oct  4 16:24:50 localhost sshd: pam_unix(sshd:session): session opened for user bids by (uid=0)
+Oct  4 16:24:53 localhost sshd[11428]: Received disconnect from 129.XXX.XXX.XXX port 40052:11: disconnected by user
+Oct  4 16:24:53 localhost sshd[11428]: Disconnected from 129.XXX.XXX.XXX port 40052
+Oct  4 16:24:53 localhost sshd[11428]: pam_unix(sshd:session): session closed for user bids
+# that was a good non -J session
+
+Oct  4 16:25:06 localhost sshd[11560]: Accepted publickey for bids from 129.XXX.XXX.XXX port 40070 ssh2: RSA SHA256:XXX
+Oct  4 16:25:06 localhost sshd: pam_unix(sshd:session): session opened for user bids by (uid=0)
+Oct  4 16:25:07 localhost sshd[11560]: Received disconnect from 129.XXX.XXX.XXX port 40070:11: disconnected by user
+Oct  4 16:25:07 localhost sshd[11560]: Disconnected from 129.XXX.XXX.XXX port 40070
+Oct  4 16:25:07 localhost sshd[11560]: pam_unix(sshd:session): session closed for user bids
+# that was a drop
+
+Oct  4 16:25:26 localhost sshd[11701]: Accepted publickey for bids from 129.XXX.XXX.XXX port 40082 ssh2: RSA SHA256:XXX
+Oct  4 16:25:26 localhost sshd[11700]: Accepted publickey for bids from 129.XXX.XXX.XXX port 40080 ssh2: RSA SHA256:XXX
+Oct  4 16:25:26 localhost sshd: pam_unix(sshd:session): session opened for user bids by (uid=0)
+Oct  4 16:25:26 localhost sshd: pam_unix(sshd:session): session opened for user bids by (uid=0)
+Oct  4 16:25:28 localhost sshd[11700]: Received disconnect from 129.XXX.XXX.XXX port 40080:11: disconnected by user
+Oct  4 16:25:28 localhost sshd[11700]: Disconnected from 129.XXX.XXX.XXX port 40080
+Oct  4 16:25:28 localhost sshd[11700]: pam_unix(sshd:session): session closed for user bids
+# here it is stalled
+# interrupted on client, ssh: .git/annex/ssh/bids@rolando.cns [mux] process is still there
+# killing the process
+Oct  4 16:26:11 localhost sshd[11701]: Received disconnect from 129.XXX.XXX.XXX port 40082:11: disconnected by user
+Oct  4 16:26:11 localhost sshd[11701]: Disconnected from 129.XXX.XXX.XXX port 40082
+Oct  4 16:26:11 localhost sshd[11701]: pam_unix(sshd:session): session closed for user bids
+
+
+Oct  4 16:26:43 localhost sshd[12176]: Accepted publickey for bids from 129.XXX.XXX.XXX port 40092 ssh2: RSA SHA256:XXX
+Oct  4 16:26:43 localhost sshd: pam_unix(sshd:session): session opened for user bids by (uid=0)
+Oct  4 16:26:44 localhost sshd[12176]: Received disconnect from 129.XXX.XXX.XXX port 40092:11: disconnected by user
+Oct  4 16:26:44 localhost sshd[12176]: Disconnected from 129.XXX.XXX.XXX port 40092
+Oct  4 16:26:44 localhost sshd[12176]: pam_unix(sshd:session): session closed for user bids
+# that was drop
+
+Oct  4 16:26:53 localhost sshd[12309]: Accepted publickey for bids from 129.XXX.XXX.XXX port 40096 ssh2: RSA SHA256:XXX
+Oct  4 16:26:53 localhost sshd[12308]: Accepted publickey for bids from 129.XXX.XXX.XXX port 40094 ssh2: RSA SHA256:XXX
+Oct  4 16:26:53 localhost sshd[12310]: Accepted publickey for bids from 129.XXX.XXX.XXX port 40098 ssh2: RSA SHA256:XXX
+Oct  4 16:26:53 localhost sshd: pam_unix(sshd:session): session opened for user bids by (uid=0)
+Oct  4 16:26:53 localhost sshd: pam_unix(sshd:session): session opened for user bids by (uid=0)
+Oct  4 16:26:53 localhost sshd: pam_unix(sshd:session): session opened for user bids by (uid=0)
+Oct  4 16:26:54 localhost sshd[12308]: Received disconnect from 129.XXX.XXX.XXX port 40094:11: disconnected by user
+Oct  4 16:26:54 localhost sshd[12308]: Disconnected from 129.XXX.XXX.XXX port 40094
+Oct  4 16:26:54 localhost sshd[12310]: Received disconnect from 129.XXX.XXX.XXX port 40098:11: disconnected by user
+Oct  4 16:26:54 localhost sshd[12310]: Disconnected from 129.XXX.XXX.XXX port 40098
+Oct  4 16:26:54 localhost sshd[12308]: pam_unix(sshd:session): session closed for user bids
+Oct  4 16:26:54 localhost sshd[12310]: pam_unix(sshd:session): session closed for user bids
+# This was with -J3, which stalled after the first one was done   
+# it stalled with a single ssh: .git/annex/ssh/bids@rolando.cns [mux]  still running
+# interruptedOct  4 16:28:34 localhost sshd[12309]: Received disconnect from 129.XXX.XXX.XXX port 40096:11: disconnected by user
+Oct  4 16:28:34 localhost sshd[12309]: Disconnected from 129.XXX.XXX.XXX port 40096
+Oct  4 16:28:34 localhost sshd[12309]: pam_unix(sshd:session): session closed for user bids
+\"\"\"]]
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3.mdwn b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3.mdwn
new file mode 100644
index 0000000000..6aad55c1ed
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+
+IMHO `git -c annex.retry=5 annex get -J...` should do its really best (up to 5 times per file) to obtain content.
+It is really not pragmatic to demand looping on top of such a call to ensure that eventually we do get all content.
+
+Possibly relevant older issues/todos I ran into:
+- [https://git-annex.branchable.com/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/](https://git-annex.branchable.com/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__/)
+- [https://git-annex.branchable.com/todo/more_extensive_retries_to_mask_transient_failures/](https://git-annex.branchable.com/todo/more_extensive_retries_to_mask_transient_failures/)
+
+
+### What steps will reproduce the problem?
+
+I have cloned `http://datasets.datalad.org/labs/hasson/narratives/derivatives/freesurfer/.git` and did `git annex get -J5 . 2>&1 | tee /tmp/annex-get-freesurfer-patched-annex-1.log` whenever 
+
+```
+[d31548v@discovery7 freesurfer]$ git config annex.retry
+3
+```
+
+that log file is available from http://www.onerussian.com/tmp/annex-get-freesurfer-patched-annex-1.log . That call ended with `get: 2948 failed`.
+
+I have dumped the output of `annex list` into [a file](http://www.onerussian.com/tmp/annex-get-freesurfer-patched-annex-1-listafter.out) and now ran
+
+```
+grep '^_' /tmp/annex-get-freesurfer-patched-annex-1-listafter.out | awk '{print $2;}' | xargs git -c annex.retry=10 annex --debug get -J5 2>&1 | tee /tmp/annex-get-freesurfer-patched-annex-1-getabsent.log
+```
+
+log for which is at [http://www.onerussian.com/tmp/annex-get-freesurfer-patched-annex-1-getabsent.log](http://www.onerussian.com/tmp/annex-get-freesurfer-patched-annex-1-getabsent.log)
+
+and which finished with `get: 130 failed` -- so clearly those original failures were not real inability to fetch content.
+
+### What version of git-annex are you using? On what operating system?
+
+
+```
+[d31548v@discovery7 git-annexes]$ git annex version
+git-annex version: 8.20211123+git21-ga6699be79-1~ndall+1
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+```
+
+and this is on that "fancy" NFS mounted isilon on a local HPC (a "POSIX" mount this time).
+
+```
+[d31548v@discovery7 freesurfer]$ git config annex.pidlock
+true
+```
+
+per my setting in `~/.gitconfig` (which also has `annex.retry = 3`)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+
+[[!meta title="annex.pidlock can cause git-annex get -J to fail to take transfer lock"]]
+
+> [[done]] --[[Joey]] 
diff --git a/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_10_1cbef11391d23210230872a75f8e5414._comment b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_10_1cbef11391d23210230872a75f8e5414._comment
new file mode 100644
index 0000000000..1011eaccd3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_10_1cbef11391d23210230872a75f8e5414._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-12-06T19:11:20Z"
+ content="""
+Update: All problems noted above are fixed, fine-grained locking is merged, 
+and it seems to work well!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_1_4de90238d57de0d49b75418411135dbc._comment b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_1_4de90238d57de0d49b75418411135dbc._comment
new file mode 100644
index 0000000000..4262fafb50
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_1_4de90238d57de0d49b75418411135dbc._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-12-01T16:39:05Z"
+ content="""
+It seems that every failure in that log is preceeded by "transfer already
+in progress, or unable to take transfer lock".
+
+It does not make sense to retry in such a case because the transfer will
+probably still be in progress so the retry would fail.
+
+So I don't think this really involves retrying (which certianly supports
+S3). The question is why are several transfers failing this way.
+My suspicion would be something to do with pid locking.
+
+And indeed, I can reproduce the same behavior in a local repo getting from
+another local repo, once I set annex.pidlock.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_2_5da78a05b781029fa7f0f9d8ead7e093._comment b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_2_5da78a05b781029fa7f0f9d8ead7e093._comment
new file mode 100644
index 0000000000..6d5e6883b4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_2_5da78a05b781029fa7f0f9d8ead7e093._comment
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-12-01T17:05:14Z"
+ content="""
+What's happening is Utility.LockFile.PidLock.tryLock
+calls trySideLock and in these failure cases,
+that returns Nothing, because another thread also happens to
+have taken the sidelock. 
+
+Due to the concurrency, the pid lock file always already exists, so
+linkToLock fails. When it is able to take the side lock, it treats this as
+a stale pid lock file situation, and takes over the pid lock.
+
+(This could also affect other locks than transfer locks, potentially.)
+
+One way to solve it would be to use a LockPool instead to take the side
+lock. Then multiple concurrent threads could all lock the side lock.
+
+Or, it could special case when the pid in the pid lock file is the same as
+the current pid, and handle it in the lock file take over code.
+
+----
+
+Now, annex.pidlock is supposed to be a big top-level lock, which is used
+instead of the fine-grained locking. What if 2 threads are each wanting
+to take a lock before operating on the same resource? If either of the
+solutions above is implemented, then both threads will "succeed" at locking
+even though it's a shared pidlock. Which could result in any undefined
+behavior.
+
+And, in all the cases where it does *not* fail to take the transfer lock,
+but instead takes over the pid lock, we're perilously close to such a thing
+happening! The only reason it's not a problem, in the case of transfers
+is that OnlyActionOn is used and prevents two threads transferring the same
+key. (Also used for dropping etc.)
+
+But this makes me worry that using annex.pidlock with concurrency enabled
+is flirting with disaster, and perhaps it should refuse to use concurrency
+to avoid such potential problems. Unless there's a way to avoid them
+entirely.
+
+Hmm.. Normally all locking in git-annex uses LockPool, which
+handles inter-process locking. If LockPool is used, one of those 2 threads
+will win at the lock and the other one will wait for it. But,
+Annex.LockPool.PosixOrPid.tryPidLock/pidLock do not use LockPool
+for fine-grained locking when pid locking is enabled.
+
+So, I think it's potentially buggy in the unsafe direction of letting
+2 threads "lock" the same resource, as well as in the safe direction of
+sometimes unncessarily failing. Both need to be fixed.
+
+I am leaning toward a process only taking the pid lock once and holding it
+until exit, with LockPool used to make that thread safe. And add fine grained
+locking using LockPool when doing pid locking.
+
+Utility.LockPool.PidLock does use a LockPool for the pid lock
+already, but with LockShared, which seems rather pointless since it will never make
+any thread block and multiple threads can still try to make the pid lock
+file at the same time.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_3_b279da2a2db1ba5a24a76a9112e691aa._comment b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_3_b279da2a2db1ba5a24a76a9112e691aa._comment
new file mode 100644
index 0000000000..436feed599
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_3_b279da2a2db1ba5a24a76a9112e691aa._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-12-01T20:25:18Z"
+ content="""
+I've fixed the transfer locking problem. Also drop -J did sometimes fail
+due to a similar locking problem and should be fixed.
+
+Still want to add the fine-grained STM locking when doing pid locking,
+as discussed above.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_4_089f1d2d7de435a98dc1098ebf1cf3df._comment b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_4_089f1d2d7de435a98dc1098ebf1cf3df._comment
new file mode 100644
index 0000000000..cd1b70d472
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_4_089f1d2d7de435a98dc1098ebf1cf3df._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2021-12-02T13:05:55Z"
+ content="""
+Just a note that I believe locking changes broke windows build, can see log [here](https://github.com/datalad/git-annex/runs/4390439197?check_suite_focus=true#step:18:205)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_5_3b840d50a1ecc9cb6e161e3c039fe332._comment b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_5_3b840d50a1ecc9cb6e161e3c039fe332._comment
new file mode 100644
index 0000000000..264dfcfa3c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_5_3b840d50a1ecc9cb6e161e3c039fe332._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-12-03T18:07:56Z"
+ content="""
+Indeed, fixed that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_6_2c83482ead69a902c99fca3ae63dfc34._comment b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_6_2c83482ead69a902c99fca3ae63dfc34._comment
new file mode 100644
index 0000000000..9138ef0207
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_6_2c83482ead69a902c99fca3ae63dfc34._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-12-03T20:37:18Z"
+ content="""
+I noticed that there is a FD leak when pidlock is enabled.
+About 1 file in 10 that is processed,
+there is a handle to ".git/annex/pidlock.lck" that is left open.
+This is not a regression caused by my fix above, bug is in older git-annex
+too.
+
+Also, I have the fine-grained locking implemented in the pidlockfinegrained
+branch now, but am waiting to merge it for testing and to resolve the above
+problem first.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_7_51f6745c4abce7b3cdfcf1c5998f8329._comment b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_7_51f6745c4abce7b3cdfcf1c5998f8329._comment
new file mode 100644
index 0000000000..fbdadc2375
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_7_51f6745c4abce7b3cdfcf1c5998f8329._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2021-12-03T21:41:53Z"
+ content="""
+Great - thank you! FWIW I gave `8.20211123+git32-g9c0f3d1de-1~ndall+1_amd64` build a test run on that system, and it performed nicely (did get all files in my limited `get -J5` attempt on that dataset).  Will be waiting for the ultimate solution to try.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_7_d8ccfe3fe0d5123c1065ace73b623b44._comment b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_7_d8ccfe3fe0d5123c1065ace73b623b44._comment
new file mode 100644
index 0000000000..36bc79daa6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_7_d8ccfe3fe0d5123c1065ace73b623b44._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-12-03T22:35:16Z"
+ content="""
+Unfortunately the more I dig into pid locking, the more deep problems I'm
+finding..
+
+When the pid lock's LockHandle is dropped, it drops the pid lock, and that
+happens even if there is another LockHandle for the pid lock, which is
+possble since it's a shared lock. So the pid lock may go away despite
+a thread is still operating as if it is present. I think probably the pid
+lock needs to stop using the LockPool and use a single LockHandle, which is
+ref counted.
+
+`getLockStatus` and `checkSaneLock` look at the status of the pid lock,
+but not yet at the fine-grained STM lock status. And as implemented,
+I think they never worked at all, since they check for posix locks on the
+pid lock file.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_9_df98c47016e79f15218880a009e671ea._comment b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_9_df98c47016e79f15218880a009e671ea._comment
new file mode 100644
index 0000000000..cba3c4624c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_get_should_retry_failed_downloads_from_S3/comment_9_df98c47016e79f15218880a009e671ea._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-12-06T16:36:45Z"
+ content="""
+Unfortunately, [[!commit 66b2536ea0aa5c88f5b744eeace3322a8a4a10b6]]
+broke shared locking when pid locks are not used, causing a FD leak,
+and had to be reverted. Which further breaks concurrent pid locking. 
+
+At this point, when -J is used with pidlock, it may drop the lock but
+still think it has it held internally. Comment #7 found another way that
+could happen, and the conclusion is that the pid lock must migrate away
+from using the lock pool.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch.mdwn b/doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch.mdwn
new file mode 100644
index 0000000000..9f1c014ce5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch.mdwn
@@ -0,0 +1,46 @@
+### Please describe the problem.
+
+From our inspection,  `annex metadata` call relies on `ls-files` to determine if the file is known to annex.  But if there is an `addurl --batch` running which is adding those files, `git` is not immediately aware of them, thus `git annex metadata` returns "peacefully" without actually performing any operation on metadata.
+
+### What steps will reproduce the problem?
+
+this is an extract from what we are doing in datalad, so might be insufficient (let us know if so)
+
+1. run `git annex addurl --batch` and add a file
+2. run `git annex metadata` to assign some metadata to the just addurl'ed file
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+6.20180316+gitg308f3ecf6-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> git -c receive.autogc=0 -c gc.auto=0 annex --debug metadata --json -s verbal_iq+=116 -s performance_iq+=89 -s age+=16.77 -s handedness+=ambidextrous -s site_id+=pitt -s session_count+=1 -s dsm_iv_tr+=autism -s sex+=Male -s project+=abide_initiative -s full_iq+=103 -s MRI+=yes -s diagnosis+=autism -s participant_id+=50002 -s session_id+=1 -s species+=homo-sapiens -- sub-50002/ses-1/T1_rep-0.mgz                                                                             [2018-03-27 11:25:15.953624157] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","sub-50002/ses-1/T1_rep-0.mgz"]
+[2018-03-27 11:25:15.957761277] process done ExitSuccess
+
+# no error exit code
+$> px | grep addurl.*batch
+yoh      26767  0.0  0.0  17892  2184 pts/16   T    11:05   0:00  |       \_ /usr/lib/git-annex.linux/exe/git --library-path /usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/usr/lib/git-annex.linux//etc/ld.so.conf.d:/usr/lib/git-annex.linux//lib64:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu:/usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git -c receive.autogc=0 -c gc.auto=0 annex addurl --with-files --json --batch
+yoh      26790  0.0  0.3 1074180296 63604 pts/16 Tl 11:05   0:00  |           \_ /usr/lib/git-annex.linux/exe/git-annex --library-path /usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/usr/lib/git-annex.linux//etc/ld.so.conf.d:/usr/lib/git-annex.linux//lib64:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu:/usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git-annex/git-annex addurl --with-files --json --batch
+
+"""]]
+
+
+P.S.  It might be a related observation that git-annex metadata does exit with non-0 exit code whenever it is ran on a non-existing file, but it exits with 0 exit code (but without performing any action) when ran on the existing but not known to git file.  I wondered if there could be if not a change in behavior but a flag to make `annex metadata PATHs` exit with non-0 code if it didn't handle some path(s) from the provided.  Then we could use it within our "set metadata" to guarantee that we do not omit any file for which we thought we would get metadata operation performed.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[[!meta title="silently skipping files that are not in git or not annexed is sometimes surprising to some"]]
+
+> annex.skipunknown false will make git-annex error out in this situation.
+> That will become the default in a couple of years, but can be set already
+> by those who don't like the behavior of skipping. 
+> 
+> In the case of addurl --batch though, do see my first comment for a way to
+> avoid any errors.
+> 
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch/comment_1_4169fceac6ef95400ddc79652558dc13._comment b/doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch/comment_1_4169fceac6ef95400ddc79652558dc13._comment
new file mode 100644
index 0000000000..f02fd8669e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch/comment_1_4169fceac6ef95400ddc79652558dc13._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-04-04T16:01:21Z"
+ content="""
+I guess you expected annex.queuesize to be set to 1.
+However, that would mean every single file that addurl adds
+needs the whole git index file to be rewritten so other commands can
+immediately know about it. Which could be very slow, which is why that is
+not the default.
+
+What you can do is use `git annex addurl --batch --json` and observe the
+key that it reports it's added. Then pass that key into `git annex metadata --batch --json`
+to add metadata to the key, which will work before the file ever gets
+added to the git index, and much more efficiently than relying on the
+index.
+
+(Pretty sure this has came up before and that I suggested the same thing
+then.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch/comment_2_c479f19eb55dce35364eea30d0b727b7._comment b/doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch/comment_2_c479f19eb55dce35364eea30d0b727b7._comment
new file mode 100644
index 0000000000..c85c646c50
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch/comment_2_c479f19eb55dce35364eea30d0b727b7._comment
@@ -0,0 +1,81 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-05-28T16:24:35Z"
+ content="""
+I think if there's a bug here, it's entirely about git-annex's behavior
+when passed a non-annexed file, or a file that is not checked into git,
+of silently skipping the file. 
+
+Users are fairly frequently surprised by that.
+
+(See also [bugs/unlock_should_warn_if_file_isn__39__t_in_repo]] and
+probably others that have been closed or handled in the forum.)
+
+What git commit does is, if a file/directory exists but is not in git:
+
+	error: pathspec 'foo' did not match any file(s) known to git
+
+On the other hand "git commit $dir" just ignores such files as it recurses
+the directory tree (as long as something in the directory tree is known to
+git).
+
+That would be fairly reasonable behavior for git-annex to have too.
+But it would be a behavior change. If someone is used to
+"git annex get foo*" getting all annexed files, but skipping the "foo~"
+temp file that is not in git, then they would have to change scripts
+and workflows.
+
+Implementing it may be as simple as passing --error-unmatch to git
+ls-files. (And disable git-annex's code that checks for parameters that are
+not existing files.)
+
+It could be an option, but I don't really consider an option as fixing the
+surprising behavior. And once you know git-annex behaves this way, I think
+it's rarely surprising and so the benefit of having an option may not
+justify having an option. I'd rather remove surprising behavior, if
+possible, than add an option to paper over it.
+
+I think this would need a transition plan. Eg:
+
+* Add a git config option, defaulting to false, that can be set to true
+  to error out.
+* Document in NEWS that the config option will start defaulting to true in
+  some release (in say, 2022), so proactive users either set it to false
+  explicitly if they want to keep the current behavior, or can change their
+  workflows.
+* Ideally, display a warning in cases where the behavior is going to
+  change. But that would need some way to emulate --error-unmatch and
+  warn when it would error. And I think that would be hard to do and/or
+  slow it down.
+* After the 2022 release the option would need to remain, or there
+  could be a later transition to remove it, by first having git-annex
+  warn about it being deprecated when it's set to true.
+
+---
+
+Also, it would need to be decided what to do about files that are checked
+into git but are not annexed files. It seems to make sense for git-annex
+get and drop of "foo*" to ignore "foo.txt" that is not annexed. But what about
+git-annex metadata on the same file? Could be argued that is throwing away
+the provided metadata, so should error, the same as if the file was not
+checked into git at all. I don't like the behavior varying between
+subcommands, so if metadata should error, so should get and drop.
+
+There's code that currently skips those files and could error. It would
+need to remember the input list of files, and check if the non-annexed
+file was explicitly listed.
+
+Oh, but what about the case where the non-annexed file is in a directory
+and the directory is explicitly listed and contains no other annexed files?
+Seems it ought to error for consistency there, but not if the directory
+does contain another file that is annexed, in addition to the one that is
+not. Implementing an error there seems to need a hash containing all the
+passed filenames, and then files can be deleted from it as it finds annexed
+files they expanded to, and at the end it can error out about any others.
+Kind of ugly and the hash lookups for each file would slow things down
+some.
+
+I think that users are less frequently bitten by git-annex ignoring
+non-annexed files though.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch/comment_3_f694e35efa09aa60daf17d63270968af._comment b/doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch/comment_3_f694e35efa09aa60daf17d63270968af._comment
new file mode 100644
index 0000000000..b2cc47571a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_metadata___40__not_--batch__39__ed__41___is_not_aware_of_files_added_via_addurls_--batch/comment_3_f694e35efa09aa60daf17d63270968af._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-05-28T19:49:58Z"
+ content="""
+Implemented annex.skipunknown git config, that will make it error out when
+given a file that git doesn't know about.
+
+Not default yet, will be in a couple of years.
+[[todo/complete_annex.skipunknown_transition_in_2022]]
+
+As to git-annex skipping non-annexed files, I'm leaning toward keeping it
+the way it is, and it's not really the subject of this bug report, except
+maybe that it's not entirely consistent with the annex.skipunknown
+behavior for non-git files. If users complain about it, I'll consider it
+again.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_sync___40__in_direct_mode_only__41___does_not_actually_update_local_branch__47__tree.mdwn b/doc/projects/datalad/bugs-done/annex_sync___40__in_direct_mode_only__41___does_not_actually_update_local_branch__47__tree.mdwn
new file mode 100644
index 0000000000..a4b6733ad7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_sync___40__in_direct_mode_only__41___does_not_actually_update_local_branch__47__tree.mdwn
@@ -0,0 +1,117 @@
+### Please describe the problem.
+
+ref: [datalad#1713](https://github.com/datalad/datalad/issues/1713#issuecomment-368091458) so it seems to work when origin remote on http, but fails (as demoed below) for local paths (and ssh)
+
+### What steps will reproduce the problem?
+
+It works correctly in indirect mode (commands below are the same besides switching to direct mode in the clone, sorry for "sudo rm" but that was the fast non-datalad method to remove them ;) )
+
+[[!format sh """
+*yoh@hopa:/tmp/test-clone> cd /tmp/; sudo rm -r /tmp/test-{clone,origin}; mkdir /tmp/test-origin; cd /tmp/test-origin; git init; git annex init; echo "1" > 1; git add 1; git commit -m 'added 1'; git clone /tmp/test-origin /tmp/test-clone; echo 2 > 2; git add 2; git commit -m 'added 2'; cd /tmp/test-clone; git annex sync  --no-content --no-push --pull origin; git show
+Initialized empty Git repository in /tmp/test-origin/.git/
+init  ok
+(recording state in git...)
+[master (root-commit) 2fc9be3] added 1
+ 1 file changed, 1 insertion(+)
+ create mode 100644 1
+Cloning into '/tmp/test-clone'...
+done.
+[master 1caaa64] added 2
+ 1 file changed, 1 insertion(+)
+ create mode 100644 2
+(merging origin/git-annex into git-annex...)
+commit (recording state in git...)
+
+On branch master
+Your branch is up-to-date with 'origin/master'.
+nothing to commit, working tree clean
+ok
+pull origin 
+remote: Counting objects: 3, done.
+remote: Compressing objects: 100% (2/2), done.
+remote: Total 3 (delta 0), reused 0 (delta 0)
+Unpacking objects: 100% (3/3), done.
+From /tmp/test-origin
+   2fc9be3..1caaa64  master     -> origin/master
+
+Updating 2fc9be3..1caaa64
+Fast-forward
+ 2 | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 2
+ok
+commit 1caaa64da380d82641356be46a5f6bc4b012a54d (HEAD -> master, origin/master, origin/HEAD, synced/master)
+Author: Yaroslav Halchenko <debian@onerussian.com>
+Date:   Fri Feb 23 14:16:43 2018 -0500
+
+    added 2
+
+diff --git a/2 b/2
+new file mode 100644
+index 0000000..0cfbf08
+--- /dev/null
++++ b/2
+@@ -0,0 +1 @@
++2
+
+"""]]
+
+but in direct you will see that you are still on 1:
+
+[[!format sh """
+*yoh@hopa:/tmp/test-clone> cd /tmp/; sudo rm -r /tmp/test-{clone,origin}; mkdir /tmp/test-origin; cd /tmp/test-origin; git init; git annex init; echo "1" > 1; git add 1; git commit -m 'added 1'; git clone /tmp/test-origin /tmp/test-clone; echo 2 > 2; git add 2; git commit -m 'added 2'; cd /tmp/test-clone; git annex direct; git annex sync  --no-content --no-push --pull origin; git show
+Initialized empty Git repository in /tmp/test-origin/.git/
+init  ok
+(recording state in git...)
+[master (root-commit) 06b75e1] added 1
+ 1 file changed, 1 insertion(+)
+ create mode 100644 1
+Cloning into '/tmp/test-clone'...
+done.
+[master e147893] added 2
+ 1 file changed, 1 insertion(+)
+ create mode 100644 2
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+commit 
+(recording state in git...)
+On branch master
+Your branch is up-to-date with 'origin/master'.
+nothing to commit, working tree clean
+ok
+direct ok
+commit (recording state in git...)
+ok
+pull origin 
+remote: Counting objects: 3, done.
+remote: Compressing objects: 100% (2/2), done.
+remote: Total 3 (delta 0), reused 0 (delta 0)
+Unpacking objects: 100% (3/3), done.
+From /tmp/test-origin
+   06b75e1..e147893  master     -> origin/master
+ok
+commit 06b75e18594f89d5af0bc2b083a90b02dd5e3f21 (HEAD -> annex/direct/master, synced/master, master)
+Author: Yaroslav Halchenko <debian@onerussian.com>
+Date:   Fri Feb 23 14:18:27 2018 -0500
+
+    added 1
+
+diff --git a/1 b/1
+new file mode 100644
+index 0000000..d00491f
+--- /dev/null
++++ b/1
+@@ -0,0 +1 @@
++1
+
+"""]]
+
+
+### What version of git-annex are you using? On what operating system?
+
+6.20180206+gitg638032f3a-1~ndall+1
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/annex_sync___40__in_direct_mode_only__41___does_not_actually_update_local_branch__47__tree/comment_1_6fb5a4fec435eccc0528744c55b7468c._comment b/doc/projects/datalad/bugs-done/annex_sync___40__in_direct_mode_only__41___does_not_actually_update_local_branch__47__tree/comment_1_6fb5a4fec435eccc0528744c55b7468c._comment
new file mode 100644
index 0000000000..04b6d62027
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_sync___40__in_direct_mode_only__41___does_not_actually_update_local_branch__47__tree/comment_1_6fb5a4fec435eccc0528744c55b7468c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-02-26T17:38:05Z"
+ content="""
+Seems that it's only merging from remotes/origin/synced/master, not
+remotes/origin/master. When `git annex sync` is used in the first
+repository, that works, but not when `git commit` is used.
+
+And it's due to being in direct mode because the annex/direct/master
+branch is checked out, so it tries to merge from
+remotes/origin/direct/master, which doesn't exist.
+
+This does not seem to be a reversion, but a long-ago oversight.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database.mdwn b/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database.mdwn
new file mode 100644
index 0000000000..7624accf5b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+
+[[!format sh """
+(git-annex)hopa:/tmp/1038_hyperface[master]git-annex
+$> git annex view 'needed-by=*'
+view (searching...) fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+
+git-annex: fd:14: hGetLine: end of file
+failed
+git-annex: user error (git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"] exited 128)
+
+
+$> git annex version           
+git-annex version: 6.20180416+gitg86b18966f-1~ndall+1
+
+"""]]
+
+copy of the repository will be provided via email
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_1_9c91eef41c51737f85d4df3c737fc6c7._comment b/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_1_9c91eef41c51737f85d4df3c737fc6c7._comment
new file mode 100644
index 0000000000..6436841e82
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_1_9c91eef41c51737f85d4df3c737fc6c7._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-05-08T17:56:54Z"
+ content="""
+I have not received the database by email yet.
+
+Note that this is a sqlite error message.
+
+I wonder if this is a symptom of the same bug as 
+<http://git-annex.branchable.com/bugs/regression_-_fails_to_drop_._Exit_code_11_wo_--debug__44___and_1_with_--debug/>
+since it popped up at the same time, and that also involved a NULL
+dereference.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_2_f6759af83ddd62293593a276e089188d._comment b/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_2_f6759af83ddd62293593a276e089188d._comment
new file mode 100644
index 0000000000..98ac9d8901
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_2_f6759af83ddd62293593a276e089188d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="details"
+ date="2018-05-09T01:12:30Z"
+ content="""
+not sure what happened with the email (was sent on 3rd of may to id@joeyh.name, I have resent it again, both times encrypted).  Also now uploaded to http://www.onerussian.com/tmp/1038_hyperface.tgz.gpg encrypted with your key. Let me know when you get it - I will remove it
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_3_798629780fa04dc1a8bf1c21ca813d40._comment b/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_3_798629780fa04dc1a8bf1c21ca813d40._comment
new file mode 100644
index 0000000000..cab739d835
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_3_798629780fa04dc1a8bf1c21ca813d40._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-05-14T17:14:17Z"
+ content="""
+I have the file. I've reproduced the crash using that repo and the most
+recent git-annex.
+
+I don't think sqlite is involved after all; seems that git hash-object
+is what's crashing on a null pointer.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_4_b7c2abf63c9f350402b3176e028bda03._comment b/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_4_b7c2abf63c9f350402b3176e028bda03._comment
new file mode 100644
index 0000000000..c991bd3b6a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/annex_view_barfs__fatal__58___Unable_to_add___40__null__41___to_database/comment_4_b7c2abf63c9f350402b3176e028bda03._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-05-14T17:30:25Z"
+ content="""
+It's caused by git submodules with names starting with dots. Not at all
+related to the recent null pointer dereference bug in git-annex.
+
+The .heudiconv/ directory is a submodule and git ls-files lists it; the view
+generation code assumes it's a dotfile and asks git to hash it.
+
+	joey@darkstar:~/tmp/1038_hyperface.x>git hash-object -w --stdin-paths --no-filters
+	.heudiconv
+	fatal: Unable to add (null) to database
+
+Views only include dotfiles to make .gitattributes etc work, and they don't
+include submodules normally, but they do include dot-dirs too; indeed I see
+this repository uses that with a .datalad/ that gets included in the view.
+Perhaps .heudiconv/ is a similar dot-dir. Seems that such submodule
+dot-dirs ought to be included in the view.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/autoenable__61__true_seems_to_not_work_any_longer.mdwn b/doc/projects/datalad/bugs-done/autoenable__61__true_seems_to_not_work_any_longer.mdwn
new file mode 100644
index 0000000000..021f9bf6d5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/autoenable__61__true_seems_to_not_work_any_longer.mdwn
@@ -0,0 +1,82 @@
+### Please describe the problem.
+
+autoenable for special remotes seems has stopped working (didn't check with prev versions though, so it might be just something changed in how repository is setup or smth else)
+
+### What version of git-annex are you using? On what operating system?
+
+6.20160902+gitgbc49d8a-1~ndall+1
+
+### Please provide any additional information below.
+
+as you can see below  autoenable=true  is set for that remote, and it enables manually just fine
+
+[[!format sh """
+(venv-tests) % rm -rf fbirn_phaseIII; git clone http://datasets.datalad.org/nidm/fbirn_phaseIII/.git
+Cloning into 'fbirn_phaseIII'...
+Checking connectivity... done.
+
+(venv-tests) % cd fbirn_phaseIII
+
+(venv-tests) % git annex info
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 6
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	225f46f1-c353-48ce-89da-ccc94dc59d01 -- yoh@falkor:/srv/datasets.datalad.org/www/nidm/fbirn_phaseIII [origin]
+ 	72ce8ab3-19bd-4cef-95b0-5b150c53edc1 -- datalad-archives
+ 	d3ceb488-0266-4464-985d-4d4a265e4144 -- yoh@smaug:/mnt/datasets/datalad/crawl/nidm/fbirn_phaseIII
+ 	f779a37c-96a5-43b5-822b-0010651dc7b1 -- yoh@hopa:/tmp/autoenable/fbirn_phaseIII [here]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 1.2 gigabytes (+1 megabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 7521
+size of annexed files in working tree: 2.76 gigabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+	MD5E: 7521
+
+(venv-tests) % echo 'git-annex:remote.log' | git cat-file --batch
+951989a46d53a17d9a2621f6af82def73c2dc96e blob 328
+72ce8ab3-19bd-4cef-95b0-5b150c53edc1 autoenable=true encryption=none externaltype=datalad-archives name=datalad-archives type=external timestamp=1473266618.950662s
+72ce8ab3-19bd-4cef-95b0-5b150c53edc1 autoenable=true encryption=none externaltype=datalad-archives name=datalad-archives type=external timestamp=1473444735.988475s
+
+(venv-tests) % git annex enableremote datalad-archives
+enableremote datalad-archives ok
+(recording state in git...)
+(venv-tests) % git annex info                                    
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 6
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	225f46f1-c353-48ce-89da-ccc94dc59d01 -- yoh@falkor:/srv/datasets.datalad.org/www/nidm/fbirn_phaseIII [origin]
+ 	72ce8ab3-19bd-4cef-95b0-5b150c53edc1 -- [datalad-archives]
+ 	d3ceb488-0266-4464-985d-4d4a265e4144 -- yoh@smaug:/mnt/datasets/datalad/crawl/nidm/fbirn_phaseIII
+ 	f779a37c-96a5-43b5-822b-0010651dc7b1 -- yoh@hopa:/tmp/autoenable/fbirn_phaseIII [here]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 1.2 gigabytes (+1 megabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 7521
+size of annexed files in working tree: 2.76 gigabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+	MD5E: 7521
+
+"""]]
+
+I am a little confused though since we do test for this scenario in datalad and test still passes, i.e. remote gets enabled... 
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[[!meta title="autoenable not done for implicit init"]]
+
+> [[done]], autoinit will now autoenable --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/autoenable__61__true_seems_to_not_work_any_longer/comment_1_457027471d09aa4ae8718c1508cfae1d._comment b/doc/projects/datalad/bugs-done/autoenable__61__true_seems_to_not_work_any_longer/comment_1_457027471d09aa4ae8718c1508cfae1d._comment
new file mode 100644
index 0000000000..0c8585d602
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/autoenable__61__true_seems_to_not_work_any_longer/comment_1_457027471d09aa4ae8718c1508cfae1d._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-21T17:37:39Z"
+ content="""
+`git annex init` does handle autoenable. When you bypass explicit init,
+it does not do autoenabling.
+
+This is not a change AFAICS. The changelog entry for autoenable
+says that it's done by `git annex init`. Presumably your test suite
+does run `git annex init`.
+
+My original notes on why not to have automaitic init handle autoenable were:
+
+> There was also the question of what to do when git-annex auto-inits
+> in a clone of a repository. It wouldn't do for a command like
+> `git annex find`'s output to include any messages that might be shown
+> while auto-enabling special remotes as a result of an auto-init.
+> Since I can't guarantee enabling special remotes will be quiet, I've not
+> tried to auto-enable special remotes in this case.
+> 
+> I think I'd have to
+> exec a git-annex init process with stdout sent to stderr to implement
+> this in a safe way, and due to calls to ensureInitialized in Remote.Git,
+> which can auto-init a local remote, that gets particularly tricky. Best,
+> I feel, to wait and see if anyone needs that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected.mdwn b/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected.mdwn
new file mode 100644
index 0000000000..a7701aea72
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected.mdwn
@@ -0,0 +1,13 @@
+### Please describe the problem.
+
+Due to the very unstable kernel on my laptop atm I need to reboot quite frequently... and this issue with annex assistant immediately starting synchronizing (although I did disable all synchronizations in webapp, so it would be another issue I guess), I wanted just to disable autostart of git-annex altogether.  I have removed $HOME/.config/autostart/git-annex.desktop but to my surprise upon gnome crashing/relogin I had the same ssh key passphrase dialog and that file reappeared.
+
+### What version of git-annex are you using? On what operating system?
+
+5.20151116+gitg5416a1a-1~ndall+1
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[closing|done]] as it's not been shown how to reproduce this and it
+> seems impossible as described. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_1_020c0c7a51638cf28efc518da4ccdb9d._comment b/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_1_020c0c7a51638cf28efc518da4ccdb9d._comment
new file mode 100644
index 0000000000..69de952217
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_1_020c0c7a51638cf28efc518da4ccdb9d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-11-30T19:51:45Z"
+ content="""
+Well, if your system is crashing, the deletion of the file might not be
+reflected on the disk or something.
+
+It is true that, when git-annex is installed via the standalone tarball, it
+will try to install the autostart file whenever the assistant is started.
+But something has to cause the assistant to start, and if you deleted the
+autostart file, it wasn't that .. so what was it?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_2_0378843b9c7281d587304ac9c42d46f5._comment b/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_2_0378843b9c7281d587304ac9c42d46f5._comment
new file mode 100644
index 0000000000..01e468f3f6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_2_0378843b9c7281d587304ac9c42d46f5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991"
+ nickname="timothyhobbs"
+ subject="comment 2"
+ date="2016-04-04T06:07:20Z"
+ content="""
+It would be better to prompt the user \"Would you like to automatically start git annex when you log in? Yes No [ ] Do not display again.\" That way user's won't be surprised that there is disk churn when they startup their computer...
+"""]]
diff --git a/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_3_935f2fe1f7ff1a46b1038cd4458317a4._comment b/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_3_935f2fe1f7ff1a46b1038cd4458317a4._comment
new file mode 100644
index 0000000000..a0a94fceb0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_3_935f2fe1f7ff1a46b1038cd4458317a4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 3"
+ date="2016-05-01T21:47:17Z"
+ content="""
+FWIW, I think for me it was the /etc/xdg/autostart/git-annex.desktop which kept it coming from dead (and laptop behaves a bit better lately so I don't reboot as often ;) )
+"""]]
diff --git a/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_4_5bb365e15cd27002b0104d9eb9b5f28d._comment b/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_4_5bb365e15cd27002b0104d9eb9b5f28d._comment
new file mode 100644
index 0000000000..403783d9d6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/autostart__47__git-annex.desktop_gets_resurrected/comment_4_5bb365e15cd27002b0104d9eb9b5f28d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-05-28T15:29:45Z"
+ content="""
+/etc/xdg/autostart/git-annex.desktop is part of the git-annex Debian
+package, but it's a conffile, so if dpkg reinstalls it after it was deleted
+that would be a dpkg bug. Anyway, it's not a file written by git-annex
+except during make install with no PREFIX.
+
+I'm going to close this as it's very old and my earlier comment seems
+valid.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/awkward_error_from_annex_whenever_operating_on_a_clone_with_submodules.mdwn b/doc/projects/datalad/bugs-done/awkward_error_from_annex_whenever_operating_on_a_clone_with_submodules.mdwn
new file mode 100644
index 0000000000..8f2600fd2c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/awkward_error_from_annex_whenever_operating_on_a_clone_with_submodules.mdwn
@@ -0,0 +1,64 @@
+### Please describe the problem.
+
+git annex init  fails on a clone of a sub sub module from a git repo
+
+### What steps will reproduce the problem?
+
+This is the archive with sample repo which is used in example below
+[http://www.onerussian.com/tmp/repl_submodule.tgz]
+
+
+### What version of git-annex are you using? On what operating system?
+
+6.20160307+gitgb095561-1~ndall+1
+
+[[!format sh """
+> tar -xzf repl_submodule.tgz        
+
+> ls -ld datalad_temp_testrepo_Lb8lMD
+drwx------ 5 yoh yoh 180 Mar 29 09:06 datalad_temp_testrepo_Lb8lMD/
+
+> git clone datalad_temp_testrepo_Lb8lMD/sub1/sub1
+Cloning into 'sub1'...
+done.
+
+> cd sub1
+INFO.txt  sub1/  sub2/  test-annex.dat@  test.dat
+
+> git annex init
+init  fatal: Could not switch to '/sub1/': No such file or directory
+ok
+(recording state in git...)
+
+> cat .git/config 
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+[remote "origin"]
+	url = /tmp/datalad_temp_testrepo_Lb8lMD/sub1/sub1
+	fetch = +refs/heads/*:refs/remotes/origin/*
+[branch "master"]
+	remote = origin
+	merge = refs/heads/master
+[annex]
+	uuid = 7293cd84-98c5-4f8c-b1ff-1c4fadd90ba3
+	version = 5
+
+> git annex --debug init 2>&1 | grep -3 "Could not"
+[2016-03-29 09:22:21.786669] read: git ["config","--null","--list"]
+[2016-03-29 09:22:21.792047] process done ExitSuccess
+[2016-03-29 09:22:21.792158] read: git ["--git-dir=../datalad_temp_testrepo_Lb8lMD/sub1/sub1/.git","--work-tree=/sub1/sub1","--literal-pathspecs","show-ref","git-annex"]
+fatal: Could not switch to '/sub1/': No such file or directory
+[2016-03-29 09:22:21.797597] process done ExitFailure 128
+ok
+[2016-03-29 09:22:21.800514] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]], I'm going to assume it was fixed since there was no followup
+> --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/awkward_error_from_annex_whenever_operating_on_a_clone_with_submodules/comment_1_86b409dc4b7824f601deeed0a14cc8e4._comment b/doc/projects/datalad/bugs-done/awkward_error_from_annex_whenever_operating_on_a_clone_with_submodules/comment_1_86b409dc4b7824f601deeed0a14cc8e4._comment
new file mode 100644
index 0000000000..fb81b5b1e6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/awkward_error_from_annex_whenever_operating_on_a_clone_with_submodules/comment_1_86b409dc4b7824f601deeed0a14cc8e4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-13T18:31:00Z"
+ content="""
+I'm pretty sure this is a duplicate of 
+[[git-annex_confuses_Git_with_nested_submodules]],
+which was filed by Michael Hanke.
+
+Error message is not identical but very close.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/awkward_error_from_annex_whenever_operating_on_a_clone_with_submodules/comment_2_f5bf66e8494b4ee2c6da7f3a6de8da18._comment b/doc/projects/datalad/bugs-done/awkward_error_from_annex_whenever_operating_on_a_clone_with_submodules/comment_2_f5bf66e8494b4ee2c6da7f3a6de8da18._comment
new file mode 100644
index 0000000000..d39502ab24
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/awkward_error_from_annex_whenever_operating_on_a_clone_with_submodules/comment_2_f5bf66e8494b4ee2c6da7f3a6de8da18._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-01-23T19:20:47Z"
+ content="""
+The bug I earlier hypothesized might be the same as this one has since been
+fixed. So it would be good to know if this bug is fixed. I do not think
+enough information was provided for me to be able to reproduce it.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__.mdwn b/doc/projects/datalad/bugs-done/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__.mdwn
new file mode 100644
index 0000000000..92449ef6e7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+[Original report](https://git-annex.branchable.com/bugs/manages_to_incorrectly_add_to_annex_instead_of_git_based_on___34__mimetype__34___-_we_cannot_figure_it_out_why/)  was about the change in behavior of git-annex (as a whole installed bundle) that .json files started to be added to git-annex instead of git, whenever .json files remained text files and .gitattributes was configured to add all files with mimetype of text to go into git.
+It happened due to the fact that libmagic added handling for detecting .json files and reporting that they are `application/json` instead of `text/plain` as before.
+
+Note that [initial demand/idea behind adding treatment of mime types](https://git-annex.branchable.com/devblog/day_360__annex.largefiles_mimetype/) was actually to provide automation for the most reasonable decision making on what goes into git and what annex, based on either a file a text file or binary.
+
+The bug report referenced above was just marked "done" with a comment that "the magic database changing behavior is not a bug in git-annex" without actually addressing the underlying issue.  I even somehow got a wrong impression that "we had it fixed" and was surprised to stumble into it again.  I think that the issue should be properly addressed, ideally without requiring users to adjust their `.gitattribute` files (and introducing newer git annex version dependency), so that the desired behavior of having text files going into git, not git-annex, was maintained *even across changes in libmagic DB*.
+
+One, IMHO the easiest way, now that `-k` (keep going) [issue was fixed in libmagic](https://bugs.astron.com/view.php?id=77), would be for git-annex to treat "mimetype" specification as "if any mimetype matches" and ask libmagic about all mimetypes of a file, e.g.:
+
+[[!format sh """
+$> file --mime-type -Lk 1.json
+1.json: application/json\012- text/plain
+"""]]
+
+so that if any structured text file would soon acquire additional, more specific mimetype (e.g., `.md` could be reported as `application/markdown`, just not yet), previous specifications in .gitattributes would still work -- after all those files remain `text/plain` files!
+
+If strict matching (not sure yet about a use case where it would really be needed) by the most specialized mime type is needed, additional "mimetypefirstguess" or alike could be added.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> Looks like we're agreed this is not necessary, so [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__/comment_1_a18cfae149effed2375b3b0be021ac3a._comment b/doc/projects/datalad/bugs-done/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__/comment_1_a18cfae149effed2375b3b0be021ac3a._comment
new file mode 100644
index 0000000000..bc2e78a99b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__/comment_1_a18cfae149effed2375b3b0be021ac3a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="oh hoh, there is mimeencoding now"
+ date="2019-12-20T19:54:04Z"
+ content="""
+OH!! \"Much ado about nothing\". As [Joey reported in datalad issues](https://github.com/datalad/datalad/issues/3361#issuecomment-488018126) there is now handling of `mimeencoding=binary` as the ultimate decision maker.  So we are probably doomed (unless Joey sees reason in the reasoning above and implements that as well) to do go through all datasets and autoadjust them to use `mimeencoding` instead of `mimetype`.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__/comment_2_08448687578634b6281ea285f18d87e7._comment b/doc/projects/datalad/bugs-done/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__/comment_2_08448687578634b6281ea285f18d87e7._comment
new file mode 100644
index 0000000000..0cde6c7a1b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__/comment_2_08448687578634b6281ea285f18d87e7._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-12-20T20:00:14Z"
+ content="""
+Yes, mimeencoding=binary is intended for those cases where you just want a
+robust (presumably) text/binary division.
+
+The "any mimetype matches" approach seems like it could break things too.
+Consider:
+
+	(not mimetype=text/plain and (mimetype=text/* or mimetype=application/json)) or mimetype=AI/buggy
+
+Currently a shell script is found to be only text/x-shellscript,
+so it would match the above. If git-annex were changed to consider
+all reported mime types, the shell script, being also text/plain
+would not match.
+
+And then, once the mime database solves the halting problem and helpfully
+starts flagging shell scripts as AI/buggy (all shell scripts are presumably
+buggy so maybe that AI has an easy job), the behavior on the above example
+would change for a third time, back to matching.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test.mdwn b/doc/projects/datalad/bugs-done/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test.mdwn
new file mode 100644
index 0000000000..9ff3429c8f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test.mdwn
@@ -0,0 +1,22 @@
+### Please describe the problem.
+
+Full build logs are at http://neuro.debian.net/_files/_buildlogs/git-annex/7.20191230+git152-gefb981388
+
+
+
+[[!format sh """
+...
+    prop_read_write_transferinfo:                         FAIL
+      *** Failed! Exception: 'recoverEncode: invalid argument (invalid character)' (after 1 test):
+      Exception thrown while showing test case: 'recoverEncode: invalid argument (invalid character)'
+      Use --quickcheck-replay=507010 to reproduce.
+
+
+"""]]
+
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test/comment_1_e9db58f71eedc99ccfd7a7a446843316._comment b/doc/projects/datalad/bugs-done/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test/comment_1_e9db58f71eedc99ccfd7a7a446843316._comment
new file mode 100644
index 0000000000..86f92e591b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test/comment_1_e9db58f71eedc99ccfd7a7a446843316._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-02T19:41:34Z"
+ content="""
+Minimal reproducer:
+
+	bash$ LANG=C ghci Utility/FileSystemEncoding.hs
+	ghci> useFileSystemEncoding
+	ghci> toRawFilePath "\611584"
+	"*** Exception: recoverEncode: invalid argument (invalid character)
+
+No such problem in a unicode locale.
+
+The problem does not, though, affect actually using git-annex in LANG=C
+with a filename with that in its name.
+
+Odd because the filesystem encoding is supposed to round-tip well,
+anything, but here encoding a string with it is failing internally.
+Maybe the thing is, it's not really round-tripping? QuickCheck arbitrary
+magics up a FilePath that contains that, so it's starting in the middle and
+trying to convert it out.
+
+[[!commit 70395659db9f662e61009d984fc9b0b2f24fdece]] introduced this while
+fixing another intermittent encoding test case failure.
+
+	ghci> Data.Char.generalCategory  '\611584'
+	NotAssigned
+
+I think it would make sense to filter out NotAssigned and PrivateUse.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw.mdwn b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw.mdwn
new file mode 100644
index 0000000000..008294071a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw.mdwn
@@ -0,0 +1,179 @@
+### Please describe the problem.
+
+Finally got to try [https://git-annex.branchable.com/todo/lockdown_hooks/](https://git-annex.branchable.com/todo/lockdown_hooks/) solution to avoid adjusted branches on local HPC which uses ACLs on some (but not all) partitions/etc.
+
+For the use-case at hands I figured how to "freeze" and "thaw" to be done via `nfs4_{s,g}etfacl`.  Here are my two scripts which also dump debug output to stderr
+
+<details>
+<summary>freeze-content -- adds "D::EVERYONE@:wadTN" at index 1</summary> 
+
+```shell
+#!/bin/bash
+
+set -eu
+
+{
+echo "D: freezing [$@] while under `pwd`"
+ls -ld "$@"
+# Cumbersome and buggy -- I found no other way to just say "remove write bits"
+#nfs4_getfacl "$@" | sed -e 's,:r[^:]*$,:rxtncy,g' | nfs4_setfacl -S- "$@"
+
+# This should be first and thus preventing any changes to that path
+# 'thaw'ing would just remove that rule
+nfs4_setfacl -a D::EVERYONE@:wadTN 1 "$@"
+echo "D: finished freezing ok. Current ACL:"
+nfs4_getfacl "$@"
+} >&2
+```
+</details>
+
+
+<details>
+<summary>thaw-content -- removes that ACL</summary> 
+
+```shell
+#!/bin/bash
+
+set -eu
+
+echo "unlocking [$@] while under `pwd`" >&2
+#nfs4_getfacl "$@" | sed -e 's,:r[^:]*$,:rxtncy,g' | nfs4_setfacl -S- "$@"
+nfs4_setfacl -x D::EVERYONE@:wadTN "$@"
+echo "finished locking ok. ACL:" >&2
+nfs4_getfacl "$@" >&1
+```
+</details>
+
+
+and I verified that it does work as expected/desired:
+
+<details>
+<summary>on a directory</summary> 
+
+```shell
+(git-annex) [d31548v@discovery7 tmp]$ mkdir testdir && ~/bin-annex/freeze-content testdir
+D: freezing [testdir] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp
+drwxrwx--- 2 d31548v rc-CANlab-admin 0 Feb 23 15:48 testdir
+D: finished freezing ok. Current ACL:
+
+# file: testdir
+D::EVERYONE@:wadTN
+A::OWNER@:rwadxtTnNcy
+A:fdi:OWNER@:rwadxtTnNcy
+A:fd:GROUP@:rwaDdxtTnNcCoy
+A:fdg:rc-CANlab@KIEWIT.DARTMOUTH.EDU:rxtncy
+(git-annex) [d31548v@discovery7 tmp]$ touch testdir/123
+touch: cannot touch 'testdir/123': Permission denied
+(git-annex) [d31548v@discovery7 tmp]$ rm -rf testdir
+rm: cannot remove 'testdir': Permission denied
+(git-annex) [d31548v@discovery7 tmp]$ ~/bin-annex/thaw-content testdir && rm -rf testdir
+unlocking [testdir] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp
+finished locking ok. ACL:
+
+# file: testdir
+A::OWNER@:rwadxtTnNcy
+A:fdi:OWNER@:rwadxtTnNcy
+A:fd:GROUP@:rwaDdxtTnNcCoy
+A:fdg:rc-CANlab@KIEWIT.DARTMOUTH.EDU:rxtncy
+(git-annex) [d31548v@discovery7 tmp]$ ls -ld testdir
+ls: cannot access testdir: No such file or directory
+
+```
+</details>
+
+
+<details>
+<summary>and a file</summary> 
+
+```shell
+(git-annex) [d31548v@discovery7 tmp]$ touch testfile && ~/bin-annex/freeze-content testfile
+D: freezing [testfile] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp
+-rwxrwx--- 1 d31548v rc-CANlab-admin 0 Feb 23 15:49 testfile
+D: finished freezing ok. Current ACL:
+
+# file: testfile
+D::EVERYONE@:wadTN
+A::OWNER@:rwadxtTnNcy
+A::GROUP@:rwadxtTnNcCoy
+A:g:rc-CANlab@KIEWIT.DARTMOUTH.EDU:rxtncy
+(git-annex) [d31548v@discovery7 tmp]$ echo 123 >> testfile
+bash: testfile: Permission denied
+(git-annex) [d31548v@discovery7 tmp]$ rm testfile
+rm: remove write-protected regular empty file 'testfile'? y
+rm: cannot remove 'testfile': Permission denied
+(git-annex) [d31548v@discovery7 tmp]$ ~/bin-annex/thaw-content testfile && rm -rf testfile
+unlocking [testfile] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp
+finished locking ok. ACL:
+
+# file: testfile
+A::OWNER@:rwadxtTnNcy
+A::GROUP@:rwadxtTnNcCoy
+A:g:rc-CANlab@KIEWIT.DARTMOUTH.EDU:rxtncy
+(git-annex) [d31548v@discovery7 tmp]$ ls -ld testfile
+ls: cannot access testfile: No such file or directory
+
+```
+</details>
+
+
+But that still dissatisfies `git-annex` (10.20220127-gf616630):
+
+```shell
+(git-annex) [d31548v@discovery7 tmp]$ d=repo; chmod +r -R "$d" ; rm -rf "$d"; mkdir -p "$d" && cd $d && git init && git -c annex.freezecontent-command="$HOME/bin-annex/freeze-content %path" -c annex.thawcontent-command="$HOME/bin-annex/thaw-content %path" annex init   
+chmod: cannot access 'repo': No such file or directory
+Initialized empty Git repository in /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/repo/.git/
+init  D: freezing [.git/annex/misctmp/gaprobe] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/repo
+-rwxrwx--- 1 d31548v rc-CANlab-admin 0 Feb 23 15:51 .git/annex/misctmp/gaprobe
+D: finished freezing ok. Current ACL:
+
+# file: .git/annex/misctmp/gaprobe
+D::EVERYONE@:wadTN
+A::OWNER@:rwadxtTnNcy
+A::GROUP@:rwadxtTnNcCoy
+A:g:rc-CANlab@KIEWIT.DARTMOUTH.EDU:rxtncy
+unlocking [.git/annex/misctmp/gaprobe] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/repo
+finished locking ok. ACL:
+
+# file: .git/annex/misctmp/gaprobe
+A::OWNER@:rwadxtTnNcy
+A::GROUP@:rwadxtTnNcCoy
+A:g:rc-CANlab@KIEWIT.DARTMOUTH.EDU:rxtncy
+
+  Filesystem does not allow removing write bit from files.
+
+  Detected a crippled filesystem.
+
+  Disabling core.symlinks.
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Switched to branch 'adjusted/master(unlocked)'
+ok
+(recording state in git...)
+```
+
+may be it is because at POSIX level write bits are still there? e.g. here is with the file
+
+```shell
+(git-annex) [d31548v@discovery7 repo]$ touch testfile && ~/bin-annex/freeze-content testfile && ls -l testfile                                         
+D: freezing [testfile] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/repo
+-rwxrwx--- 1 d31548v rc-CANlab-admin 0 Feb 23 15:51 testfile
+D: finished freezing ok. Current ACL:
+
+# file: testfile
+D::EVERYONE@:wadTN
+A::OWNER@:rwadxtTnNcy
+A::GROUP@:rwadxtTnNcCoy
+A:g:rc-CANlab@KIEWIT.DARTMOUTH.EDU:rxtncy
+-rwxrwx--- 1 d31548v rc-CANlab-admin 0 Feb 23 15:51 testfile
+```
+
+filing as a bug since I think I satisfied all desires of git-annex for ensuring that target path is frozen, but it is still not satisfied
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+
+edit 1:  I thought that may be "Locking down a directory only needs to do the equivilant of removing its write bit, does not need to lockdown the files within it." from [lockdown_hooks](https://git-annex.branchable.com/todo/lockdown_hooks/) does not really "work", so I added `-R` to above nfs4_facl calls, but seems the effect is the same -- annex doesn' like me :-/
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_1_07ee2e1b3e0bf8959001c22273a71afe._comment b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_1_07ee2e1b3e0bf8959001c22273a71afe._comment
new file mode 100644
index 0000000000..a9826be5e5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_1_07ee2e1b3e0bf8959001c22273a71afe._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="approach which somewhat works"
+ date="2022-02-24T02:20:15Z"
+ content="""
+ok, if instead I do use more fragile version where I do adjust `A:` ACLs instead of just adding the `D:`
+
+<details>
+<summary>here are the two commands to freeze/thaw</summary> 
+
+```shell
+
+nfs4_getfacl \"$@\" | sed -e 's,:rwadxtTnN,:rxtn,g' | nfs4_setfacl -S- \"$@\"
+
+
+nfs4_getfacl \"$@\" | sed -e 's,:rxtn,:rwadxtTnN,g' | nfs4_setfacl -S- \"$@\"
+
+
+```
+</details>
+
+then  I do get `ls -l` reporting that write bit is not set, and `git annex` seems to be happy then... heh.  So I guess some recipe like this could be used , but I still would prefer to avoid needing in-place changes of such \"detailed\" permissions listings in those ACLs.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_2_ad34ddcf5bd0466b66eb1b93f65297fe._comment b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_2_ad34ddcf5bd0466b66eb1b93f65297fe._comment
new file mode 100644
index 0000000000..5a5e50ad45
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_2_ad34ddcf5bd0466b66eb1b93f65297fe._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="for some reason `drop` freezes thawn key file before thawing key dir"
+ date="2022-02-24T03:21:54Z"
+ content="""
+which results in permission denied on removal of the key (annex  10.20220127-gf616630) -- why should it freeze the key if it is about to be dropped?
+
+```
+(git-annex) [d31548v@discovery7 ds000001]$ git annex get sub-02/anat
+get sub-02/anat/sub-02_T1w.nii.gz (from s3-PUBLIC...) 
+
+thawing [.git/annex/objects/K0/1M/MD5E-s5736750--4ba3ad9eaa54aab87d97fa0d60b576ad.nii.gz] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/ds000001
+D: freezing [.git/annex/objects/K0/1M/MD5E-s5736750--4ba3ad9eaa54aab87d97fa0d60b576ad.nii.gz/MD5E-s5736750--4ba3ad9eaa54aab87d97fa0d60b576ad.nii.gz] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/ds000001
+D: freezing [.git/annex/objects/K0/1M/MD5E-s5736750--4ba3ad9eaa54aab87d97fa0d60b576ad.nii.gz] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/ds000001
+ok
+get sub-02/anat/sub-02_inplaneT2.nii.gz (from s3-PUBLIC...) 
+
+thawing [.git/annex/objects/49/7G/MD5E-s718835--da6846d3f0a6c0fe29bb1bf22c796354.nii.gz] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/ds000001
+D: freezing [.git/annex/objects/49/7G/MD5E-s718835--da6846d3f0a6c0fe29bb1bf22c796354.nii.gz/MD5E-s718835--da6846d3f0a6c0fe29bb1bf22c796354.nii.gz] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/ds000001
+D: freezing [.git/annex/objects/49/7G/MD5E-s718835--da6846d3f0a6c0fe29bb1bf22c796354.nii.gz] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/ds000001
+ok
+(recording state in git...)
+(git-annex) [d31548v@discovery7 ds000001]$ git annex drop sub-02/anat
+drop sub-02/anat/sub-02_T1w.nii.gz thawing [.git/annex/objects/K0/1M/MD5E-s5736750--4ba3ad9eaa54aab87d97fa0d60b576ad.nii.gz/MD5E-s5736750--4ba3ad9eaa54aab87d97fa0d60b576ad.nii.gz] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/ds000001
+D: freezing [.git/annex/objects/K0/1M/MD5E-s5736750--4ba3ad9eaa54aab87d97fa0d60b576ad.nii.gz/MD5E-s5736750--4ba3ad9eaa54aab87d97fa0d60b576ad.nii.gz] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/ds000001
+thawing [.git/annex/objects/K0/1M/MD5E-s5736750--4ba3ad9eaa54aab87d97fa0d60b576ad.nii.gz] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/ds000001
+
+git-annex: .git/annex/objects/K0/1M/MD5E-s5736750--4ba3ad9eaa54aab87d97fa0d60b576ad.nii.gz/MD5E-s5736750--4ba3ad9eaa54aab87d97fa0d60b576ad.nii.gz: removeLink: permission denied (Permission denied)
+failed
+drop sub-02/anat/sub-02_inplaneT2.nii.gz thawing [.git/annex/objects/49/7G/MD5E-s718835--da6846d3f0a6c0fe29bb1bf22c796354.nii.gz/MD5E-s718835--da6846d3f0a6c0fe29bb1bf22c796354.nii.gz] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/ds000001
+D: freezing [.git/annex/objects/49/7G/MD5E-s718835--da6846d3f0a6c0fe29bb1bf22c796354.nii.gz/MD5E-s718835--da6846d3f0a6c0fe29bb1bf22c796354.nii.gz] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/ds000001
+thawing [.git/annex/objects/49/7G/MD5E-s718835--da6846d3f0a6c0fe29bb1bf22c796354.nii.gz] while under /dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp/ds000001
+
+git-annex: .git/annex/objects/49/7G/MD5E-s718835--da6846d3f0a6c0fe29bb1bf22c796354.nii.gz/MD5E-s718835--da6846d3f0a6c0fe29bb1bf22c796354.nii.gz: removeLink: permission denied (Permission denied)
+failed
+drop: 2 failed
+```
+
+as a workaround I added `-R` to my thawing script so thawing of keydir re-thaws the key as well, but that doesn't feel right.
+
+edit: interestingly, `drop` also thaws the file in index (e.g. `./sub-02/anat/sub-02_inplaneT2.nii.gz` in my case) -- why does it in \"indirect\" mode? hm...
+"""]]
diff --git a/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_3_223df2a9cebd99a312537137863b1781._comment b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_3_223df2a9cebd99a312537137863b1781._comment
new file mode 100644
index 0000000000..e7d69b6dc7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_3_223df2a9cebd99a312537137863b1781._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-02-24T16:34:51Z"
+ content="""
+Looks like, while init does run the freeze hook in its test,
+as well as trying to remove the write bits (which it always does, freeze
+hook or no freeze hook), it still checks if the file's write permissions
+got removed.
+
+I think that, in order to support filesystems where chmod -w has no effect,
+init should skip looking at write perms when there is a freeze hook. It can
+still check that freezing prevents writing to a file.
+
+Hmm, init uses checkContentWritePerm to see if the write permission is
+removed. That is also used by fsck, and when ingesting a file. So even if
+it were fixed in init, those would still be problems. This really needs to
+be fixed in checkContentWritePerm.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_4_c78b91393ca917f9d231c39702c70e14._comment b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_4_c78b91393ca917f9d231c39702c70e14._comment
new file mode 100644
index 0000000000..0e97320c48
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_4_c78b91393ca917f9d231c39702c70e14._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-02-24T17:07:19Z"
+ content="""
+I think that this issue with drop freezing the content needs to be treated
+as a separate bug. There also may be a good reason for it to do it, I have
+not looked into that yet.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_5_1bf2ff8d5ddbc8121ea69a5f4042f190._comment b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_5_1bf2ff8d5ddbc8121ea69a5f4042f190._comment
new file mode 100644
index 0000000000..9b51f7cd5a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_5_1bf2ff8d5ddbc8121ea69a5f4042f190._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-02-24T17:24:55Z"
+ content="""
+Fixed it to ignore remaining write perms when annex.freezecontent-command
+is set.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_6_e12bd42ef9690d3bb74236d55da66bff._comment b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_6_e12bd42ef9690d3bb74236d55da66bff._comment
new file mode 100644
index 0000000000..3cc2484d9f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_6_e12bd42ef9690d3bb74236d55da66bff._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-02-24T17:30:07Z"
+ content="""
+I've added --debug output for both freezing and thawing. 
+
+The behavior will vary between v8 and v10 because of changes to locking; in v8
+it has to thaw the content file before it can lock it, and then it will freeze
+it back after locking and before removing it.
+
+In v8 drop looks like:
+
+	[2022-02-24 13:51:01.946411104] (Annex.Perms) thawing content .git/annex/objects/p9/5Q/SHA256E-s30--afdc07f1ee36cca8648193709de3a8bbd7abf1ce9ff23538284d01dee4d9cf63/SHA256E-s30--afdc07f1ee36cca8648193709de3a8bbd7abf1ce9ff23538284d01dee4d9cf63
+	[2022-02-24 13:51:01.947501102] (Annex.Perms) freezing content .git/annex/objects/p9/5Q/SHA256E-s30--afdc07f1ee36cca8648193709de3a8bbd7abf1ce9ff23538284d01dee4d9cf63/SHA256E-s30--afdc07f1ee36cca8648193709de3a8bbd7abf1ce9ff23538284d01dee4d9cf63
+	[2022-02-24 13:51:01.966185222] (Annex.Perms) thawing content directory .git/annex/objects/p9/5Q/SHA256E-s30--afdc07f1ee36cca8648193709de3a8bbd7abf1ce9ff23538284d01dee4d9cf63
+	[2022-02-24 13:51:01.967659691] (Annex.Perms) thawing content ./foo
+
+In v10 drop looks like:
+
+	[2022-02-24 13:50:11.863585194] (Annex.Perms) freezing content directory .git/annex/objects/p9/5Q/SHA256E-s30--afdc07f1ee36cca8648193709de3a8bbd7abf1ce9ff23538284d01dee4d9cf63
+	[2022-02-24 13:50:11.883859034] (Annex.Perms) thawing content directory .git/annex/objects/p9/5Q/SHA256E-s30--afdc07f1ee36cca8648193709de3a8bbd7abf1ce9ff23538284d01dee4d9cf63
+	[2022-02-24 13:50:11.885644532] (Annex.Perms) thawing content ./foo
+	[2022-02-24 13:50:11.887090539] (Annex.Perms) thawing content directory .git/annex/objects/p9/5Q/SHA256E-s30--afdc07f1ee36cca8648193709de3a8bbd7abf1ce9ff23538284d01dee4d9cf63
+
+So that's more or less as I expected (aside from the thawing of the worktree symlink foo
+which is kind of weird). 
+
+You said "drop freezes thawn key file before thawing key dir" and yes, that's the v8 behavior
+shown above. 
+
+The reason is safety: If it left the content file thawed after taking the posix
+lock of it, but then turned out to be unable to remove it (could not lock
+enough other copies of the object in other repos), it would then need to
+re-freeze it since it failed to drop it. But waiting until that point to
+re-freeze it would leave a perhaps long stretch of time where it was thawed and
+vulnerable to being written to. And also if it were interrupted before it could
+re-freeze it would leave it thawed until fsck finally noticed and fixed the
+problem. So I don't feel what it's doing is wrong with respect to thawing
+and then freezing in v8.
+
+Notice that, in v10, it thaws the content directory, but never directly thaws
+the content file. So if the content file remaining frozen prevents removing it,
+that would also affect v10.
+
+This does complicate freeze hooks that do things that prevent removal
+of the file, rather than just preventing write to the file. Of course
+those are two different permissions in classical unix permissions, but
+not necessarily with your ACLs or with immutability bits etc.
+
+So, I think that what git-annex ought to do is, when there's a thaw
+hook, thaw the content file just before unlinking it.
+
+Implemented that. Should solve your second problem.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_7_f0a3a944479e52a7789ff9a346001a6d._comment b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_7_f0a3a944479e52a7789ff9a346001a6d._comment
new file mode 100644
index 0000000000..5825a1cf13
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_7_f0a3a944479e52a7789ff9a346001a6d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-02-24T18:13:20Z"
+ content="""
+	[2022-02-24 13:50:11.885644532] (Annex.Perms) thawing content ./foo
+
+This turns out to be due to removeAnnex's resetpointer.
+It was not intended to run on symlinks. I've fixed this too.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/cannot___34__install__34___standalone_git_annex_within_afs_mount.mdwn b/doc/projects/datalad/bugs-done/cannot___34__install__34___standalone_git_annex_within_afs_mount.mdwn
new file mode 100644
index 0000000000..bd24582a40
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/cannot___34__install__34___standalone_git_annex_within_afs_mount.mdwn
@@ -0,0 +1,25 @@
+### Please describe the problem.
+
+Cannot even extract the standalone linux tarball for deployment on our processing server:
+
+[[!format sh """
+[mvdoc@rolando bin] > tar -xzf git-annex-standalone-amd64.tar.gz 
+tar: git-annex.linux/shimmed/git-fsck/git-fsck: Cannot hard link to `git-annex.linux/shimmed/git-help/git-help': Invalid cross-device link
+tar: git-annex.linux/shimmed/git-cat-file/git-cat-file: Cannot hard link to `git-annex.linux/shimmed/git-help/git-help': Invalid cross-device link
+tar: git-annex.linux/shimmed/git-init/git-init: Cannot hard link to `git-annex.linux/shimmed/git-help/git-help': Invalid cross-device link
+...
+tar: Exiting with failure status due to previous errors
+
+[mvdoc@rolando bin] > ls -l git-annex.linux/shimmed/git-pack-redundant/git-pack-redundant git-annex.linux/shimmed/git-help/git-help
+ls: cannot access git-annex.linux/shimmed/git-pack-redundant/git-pack-redundant: No such file or directory
+-rwxr-xr-x 1 mvdoc users 2023056 Oct 29 22:44 git-annex.linux/shimmed/git-help/git-help
+[mvdoc@rolando bin] > 
+
+
+# End of transcript or log.
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now.mdwn b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now.mdwn
new file mode 100644
index 0000000000..b01c70774b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now.mdwn
@@ -0,0 +1,73 @@
+### Please describe the problem.
+
+Leads to a failure of 'git commit' upon attempt to commit a file which went from "largefile" to small, according to .gitattributes settings, if we `git annex add file` before committing the change.
+
+### What version of git-annex are you using? On what operating system?
+
+6.20180720+gitg03978571f-1~ndall+1
+
+### Please provide any additional information below.
+
+Here is a full script to reproduce it:
+[[!format sh """
+#!/bin/bash
+
+set -ex
+
+builtin cd /tmp; 
+
+if [ -e /tmp/repo ]; then
+    chmod -R +w /tmp/repo; 
+    rm -rf /tmp/repo; 
+fi
+mkdir /tmp/repo; 
+cd /tmp/repo; 
+git init; 
+git annex init; 
+echo '* annex.largefiles=(largerthan=5b)' >.gitattributes; 
+git add .gitattributes; 
+git commit -m 'added .gitattri'; 
+echo 123456 > file; 
+git annex add file; 
+git commit -m add1; 
+ls -l; 
+
+git annex unlock file; 
+echo 123 >| file
+git annex add file
+
+# this would work but commit to git-annex, not git despite .gitattributes settings
+# git commit -m edit -a 
+# This one would fail to commit at all, complaining about "partial commit"
+git commit -m edit file
+ls -l file; 
+
+git status
+
+
+"""]]
+
+which leads to 
+[[!format sh """
+...
++ git annex add file
+add file (non-large file; adding content to git repository) ok
+add file (non-large file; adding content to git repository) ok
+(recording state in git...)
++ git commit -m edit file
+git-annex: Cannot make a partial commit with unlocked annexed files. You should `git annex add` the files you want to commit, and then run git commit.
+"""]]
+
+additional observations:
+
+- works fine if remains large file (e.g. we just append to it)
+- does not fail if we do `git commit -a` not `git commit file`, but it commits it to annex not to git, despite previous `git annex add` message rightfully says that "non-large file; adding content to git repository" 
+
+Expected behavior:
+- have consistent behavior between `commit -a` and `commit file`
+- commit without a failure, committing to git (since .gitattributes instructs so and even `git annex add` reports that)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_1_ad19d064dd9c175debe647a6928e4f35._comment b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_1_ad19d064dd9c175debe647a6928e4f35._comment
new file mode 100644
index 0000000000..d6167d7893
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_1_ad19d064dd9c175debe647a6928e4f35._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-08-09T15:57:57Z"
+ content="""
+I take this as not being a bug about the partial commit
+blocking (as explained in
+[[!commit adc5ca70a8095a389273e7c286cb32de6873a5a3]]), which is working
+around a git behavior and so can't be fixed other than by going to v6.
+
+Instead, I think this is a bug about git annex add of an unlocked file
+not converting it to a in-git file when annex.largefiles says it ought
+to. If it did that it would not run into the partial commit blocking
+at all. And, the observersion about git commit -a committing to the annex
+not to git points at the same problem.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_2_19de1d89dd0a266ce43e0f25cd2b74cd._comment b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_2_19de1d89dd0a266ce43e0f25cd2b74cd._comment
new file mode 100644
index 0000000000..50c512e369
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_2_19de1d89dd0a266ce43e0f25cd2b74cd._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-08-09T16:05:27Z"
+ content="""
+The double output from `git-annex add file` is also some kind of minor bug.
+
+The double output seems to have the same root cause too: The file is left
+typechanged form by the first pass of the add, and so the second pass
+sees it again. When annex.largefiles lets the file be annexed, the doubled
+output does not occur.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_3_92b71940fe9d00bf58ee08b327f4a991._comment b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_3_92b71940fe9d00bf58ee08b327f4a991._comment
new file mode 100644
index 0000000000..25f6c61a23
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_3_92b71940fe9d00bf58ee08b327f4a991._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-08-09T16:17:33Z"
+ content="""
+So the root problem is that when we have a typechanged file and want to
+convert that to be not typechanged, we have to git commit it.
+As long as the previous commit is a symlink and the file in the index is
+not, the file will be typechanged by definition.
+
+When git-annex add runs `git add file`, it's doing the only thing it can
+do, but it leaves the file typechanged, and so git-annex later has no way
+to tell that this file is not supposed to be treated as an unlocked file.
+I don't think we want `git annex add` to commit the file. That would be
+very surprising behavior!
+
+What git-annex could do is have the pre-commit hook notice that the file
+doesn't match annex.largefiles and not re-annex it, allowing the typechange to
+get committed to git. Then the user would only need to unlock the file,
+modify it to make it non-large, and commit it to get it checked into git.
+
+In a way, this is *too* easy, because if the user sees that working, they may
+expect to be able to turn a small file back into an annexed file by
+making the content large and running git commit on it w/o git-annex add.
+Which would be bad because that would commit a large file to git.
+I suppose the pre-commit could handle that too, but imagine that replacing
+eg a `configure` script that's expected to be shipped in the git repository
+with an annex symlink, which would be surprising.
+
+So it may be better to keep the conversion from annexed to in-git file
+and back explicit. This could be done by `git annex add` detecting
+this situation and erroring out with a message that suggests running
+`git commit -n` if the user wants to change the annexed file to a in-git
+file. That bypasses the pre-commit hook, so the typechange gets committed
+to git as they desire.
+
+Which is better, the implicit conversion of the explicit? I am not
+sure, but lean toward the explicit since it doesn't have this potential
+to confuse users. Also, the implicit conversion would only work when
+annex.largefiles is being used, but the explicit conversion can be done
+irregardless.
+
+The explicit paths would be:
+
+	# annex to git                 # git to annex
+	git annex unlock file		
+	smallen file                   largen file
+	git add file                   git annex add file
+	git commit -n                  git commit
+
+Seems worth documenting somewhere. Or making a command that handles these
+conversions, but the largen and smallen steps being manual, and the
+possibility to combine multiple of these into a single commit argues
+against a conversion command.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_4_010b0b10ce6f9cd2b9a3f9847ff2a91a._comment b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_4_010b0b10ce6f9cd2b9a3f9847ff2a91a._comment
new file mode 100644
index 0000000000..e1ec8152d4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_4_010b0b10ce6f9cd2b9a3f9847ff2a91a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="may be one more gitattribute to instruct on either conversion is desired for the file?"
+ date="2018-08-09T18:59:56Z"
+ content="""
+I will place implementation and possible tech difficulties aside for now.
+I am afraid that here and [there](http://git-annex.branchable.com/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/) we (well, me?) indeed wanted to see two conflicting behaviors somehow happen.  On one hand (in [there](http://git-annex.branchable.com/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/)) we would like to keep the file initially committed to git under git, regardless what .gitattributes instructs.
+On the other, here I expected file to automagically jump between git and annex depending on `.gitattributes`.  So, rather than explicit \"to git\" or \"to annex\" you outlined, to me the question sounds more like \"retain the same storage (git or annex) as before\" or \"possibly perform conversion according to .gitattributes\".  And I see usecases where for some files (directories, e.g. `.datalad/metadata`) we would like to see one strategy (auto-conversion) and for the others (default?) the other (maintain git/annex).   Given that in v6 there would only be `git add` (so no explicit `git` vs `git annex` add), and that `-n` for `git add` is a flag I was not even aware about, may be it is better to think about being able to explicitly set some additional gitattribute to allow (or disallow?) the conversion for given files, and then have consistent user-level `git annex add` (and in v6 `git add`) which would perform necessary actions across provided files according to `largefiles` and that additional attribute value to decide on the destiny of the file?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_4_8ab0f0852a1dc6c51a502f07faba61eb._comment b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_4_8ab0f0852a1dc6c51a502f07faba61eb._comment
new file mode 100644
index 0000000000..7a3436b636
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_4_8ab0f0852a1dc6c51a502f07faba61eb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-08-09T19:04:28Z"
+ content="""
+Documented both conversions in
+<https://git-annex.branchable.com/tips/largefiles>
+"""]]
diff --git a/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_6_7081b1386ca8807dff79e8613088b619._comment b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_6_7081b1386ca8807dff79e8613088b619._comment
new file mode 100644
index 0000000000..36ae0a0a5a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_6_7081b1386ca8807dff79e8613088b619._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2018-08-09T19:16:10Z"
+ content="""
+In v6, `git add` rather than `git annex add` will also add it to the annex,
+given annex.largefiles setting. Of course, `git annex add` can also be used
+in v6 mode too. And `-n` is a flag to `git commit`, not `git add`.
+
+Let's please not entangle this bug with that other bug. Unless your goal is
+that I merge them. Bear in mind that I consider the other bug a snake pit,
+and probably should have closed it as utterly useless some time ago.a
+
+(Maybe that was uncharitable, but the other bug seems pretty well blocked
+on a complete reimplementation of v6 mode leading to a v6 mode that is not
+experimental, and entangling this bug into that does not seem wise.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_7_d987bcd1f589cd9f19a4df92461f9e1a._comment b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_7_d987bcd1f589cd9f19a4df92461f9e1a._comment
new file mode 100644
index 0000000000..23a34f0e4f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_7_d987bcd1f589cd9f19a4df92461f9e1a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="my 1c"
+ date="2018-08-10T19:17:16Z"
+ content="""
+> Let's please not entangle this bug with that other bug.
+
+Sure!  I just (probably erroneously) felt that they stem from the same point of absent clear \"semantic\" on either conversion should happen or not.  I am  yet to fully digest what you are suggesting, and either and how we should address for this at datalad level, but meanwhile FWIW:
+
+- adding `-n` to the `commit` (and not to `add`) is as uncommon to me in my daily use of git/git-annex, and I hope that I would never have to use it while performing regular \"annex unlock file(s); annex add file(s); commit file(s)\" sequence in order to maintain a file(s) under annex.
+
+- either a file `smallen` according to git-annex/largefiles setting is unknown to the user (or some higher level tool using git-annex as datalad) without explicitly checking (not even sure yet how) or doing `git annex add`-ing it/them and seeing either it would now be added to git whenever it was added to annex before.  So hopefully we do not need to do that either.
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_8_a9100e161d004729db9e3157fcb78343._comment b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_8_a9100e161d004729db9e3157fcb78343._comment
new file mode 100644
index 0000000000..47d80128d1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_8_a9100e161d004729db9e3157fcb78343._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2018-08-29T16:14:09Z"
+ content="""
+That other bug is closed now, and 
+let to [[!commit 10138056dc240ad4265a4c473a32d4c715bbb629]].
+
+So in v6, when annex.largefiles is not configured for a file,
+git add of a modification to the file will store it however the file was
+stored before. But when annex.largefiles is configured, it overrides that
+default.
+
+That didn't change the behavior of git-annex add, but we could consider
+doing so. Although I don't know if it's technically possible to support
+that behavior in v5 mode, due to the difficulties discussed in comment #3
+above.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_9_220be99862a8a24263bd5f5f27988a1c._comment b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_9_220be99862a8a24263bd5f5f27988a1c._comment
new file mode 100644
index 0000000000..ec92d5d4b4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_9_220be99862a8a24263bd5f5f27988a1c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2019-09-30T19:43:43Z"
+ content="""
+IIRC this involved v5 repositories and the pre-commit
+hook's hacks to make v5 unlocked files work. Stuff that was one of the
+motivations for v7.
+
+I tried the script in a v7 repository, and the git commit 
+of the file succeeded, no "partial commit" complaint. So I think the
+original bug is fixed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/case_where_using_pathspec_with_git-commit_leaves_s.mdwn b/doc/projects/datalad/bugs-done/case_where_using_pathspec_with_git-commit_leaves_s.mdwn
new file mode 100644
index 0000000000..a9d33dff6e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/case_where_using_pathspec_with_git-commit_leaves_s.mdwn
@@ -0,0 +1,119 @@
+424bef6b6 (smudge: check for known annexed inodes before checking
+annex.largefiles, 2021-05-03) fixed a case where an unlocked annexed
+file that annex.largefiles does not match could get its unchanged
+content checked into git.  This was in response to
+<https://git-annex.branchable.com/forum/one-off_unlocked_annex_files_that_go_against_large/>.
+
+In a comment there, Joey said:
+
+> I've made a change that seems to work, and will probably not break
+> other cases, although this is a complex and subtle area.
+
+I'm following up with a change in behavior flagged by a DataLad test.
+As with most things in this area, I have a hard time reasoning about
+what the expected behavior should be and whether it should be
+considered a bug.  Here's the reproducer:
+
+[[!format sh """
+set -eu
+
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/ga-XXXXXXX)"
+
+git version
+git annex version | head -1
+
+git init -q
+git annex init
+
+echo a >foo
+git annex add foo
+git commit --quiet -m 'add foo'
+
+git annex unlock foo
+printf '* annex.largefiles=nothing\n' >.gitattributes
+
+sleep 1
+
+git annex add foo
+git commit -q -m 'commit unlocked' -- foo
+
+set -x
+export PS4='> '
+git diff HEAD^- -- foo
+git diff --cached
+"""]]
+
+Here's the output with 8.20210428:
+
+```
+git version 2.31.1.659.g12c5fe8677
+git-annex version: 8.20210428
+[...]
+> git diff HEAD^- -- foo
+diff --git a/foo b/foo
+deleted file mode 120000
+index 8a2a0c9..0000000
+--- a/foo
++++ /dev/null
+@@ -1 +0,0 @@
+-.git/annex/objects/3z/F8/SHA256E-s2--87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7/SHA256E-s2--87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7
+\ No newline at end of file
+diff --git a/foo b/foo
+new file mode 100644
+index 0000000..7898192
+--- /dev/null
++++ b/foo
+@@ -0,0 +1 @@
++a
+> git diff --cached
+```
+
+And here's the output with a recent commit on master following
+424bef6b6:
+
+```
+git version 2.31.1.659.g12c5fe8677
+git-annex version: 8.20210429-ge811a50e2
+[...]
+> git diff HEAD^- -- foo
+diff --git a/foo b/foo
+deleted file mode 120000
+index 8a2a0c9..0000000
+--- a/foo
++++ /dev/null
+@@ -1 +0,0 @@
+-.git/annex/objects/3z/F8/SHA256E-s2--87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7/SHA256E-s2--87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7
+\ No newline at end of file
+diff --git a/foo b/foo
+new file mode 100644
+index 0000000..3de500c
+--- /dev/null
++++ b/foo
+@@ -0,0 +1 @@
++/annex/objects/SHA256E-s2--87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7
+> git diff --cached
+diff --git a/foo b/foo
+index 3de500c..7898192 100644
+--- a/foo
++++ b/foo
+@@ -1 +1 @@
+-/annex/objects/SHA256E-s2--87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7
++a
+```
+
+Before 424bef6b6, `git annex add foo + git commit ... foo` results in
+a commit that has foo's content tracked in git.  After 424bef6b6, the
+unlocked file is still recorded, and the switch to being tracked by
+git ends up staged in the index.
+
+The new behavior isn't seen if the pathspec is dropped from `git
+commit`.  Also, without the sleep, it isn't triggered reliably
+(presumably because the index and foo have the same mtime, bypassing
+the clean filter).
+
+Thanks for taking a look.
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> commit reverted; [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/case_where_using_pathspec_with_git-commit_leaves_s/comment_1_a71ce38ec25075ac7037550094da2bf7._comment b/doc/projects/datalad/bugs-done/case_where_using_pathspec_with_git-commit_leaves_s/comment_1_a71ce38ec25075ac7037550094da2bf7._comment
new file mode 100644
index 0000000000..d4776c2799
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/case_where_using_pathspec_with_git-commit_leaves_s/comment_1_a71ce38ec25075ac7037550094da2bf7._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-05-10T16:04:07Z"
+ content="""
+On the second `git annex add foo`, I see:
+
+	add foo (non-large file; adding content to git repository) ok
+
+Which seems right as far as the largefiles config goes.
+
+That in turn runs `git add`, which runs the smudge filter. Due to my change
+in [[!commit 424bef6b6]], the smudge filter then sees an inode it already
+knows (because the file was unlocked), and so it avoids adding the file to
+git, and leaves it annexed.
+
+I don't quite understand how the different ways of running git commit play
+into this, or how the file ends up, after the commit, to having a
+non-annexed file recorded in the index. I guess the smudge filter must
+end up being run again, and perhaps the [[!commit 424bef6b6]] change
+doesn't work then, but anyway the behavior before that point is already a
+problem.
+
+Another instance of I think the same problem is following the
+[[tips/largefiles]] recipe to convert an annexed file to git:
+
+	git init repo; cd repo; git annex init
+	echo foo > file
+	git annex add file
+	git commit -m add
+	git annex unlock file
+	git rm --cached file
+	git annex add --force-small file
+	git commit -m convert file
+
+This results in a commit that unlocked the file but leaves
+it annexed, and after the commit, git diff --cached shows that the index
+has staged a conversion from unlocked to stored in git. So very similar,
+and clearly [[!commit 424bef6b6]] cannot be allowed to cause that breakage,
+which does not even involve largefiles!
+
+So I've reverted the commit for now, and we can discuss next steps in the
+forum thread.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621.mdwn b/doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621.mdwn
new file mode 100644
index 0000000000..72c4777c27
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621.mdwn
@@ -0,0 +1,7 @@
+not sure if regression and what specific annex command caused it yet. 
+initially detected with 8.20210621 released and bisected to [8.20210621-12-g4b1b9d7a8 AKA 8.20210630~39](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=4b1b9d7a83f0da71665658e6234e699e182cbddc): datalad tests started to fail to `git push` because freshly created remote was already carrying some `master`. Some more details on [original datalad issue #5759](https://github.com/datalad/datalad/issues/5759#issuecomment-875973598)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[dup|done]] see my comment --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621/comment_1_ba8a5b590d2f690bcabeb63c0ef6f46c._comment b/doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621/comment_1_ba8a5b590d2f690bcabeb63c0ef6f46c._comment
new file mode 100644
index 0000000000..73dd429b1e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621/comment_1_ba8a5b590d2f690bcabeb63c0ef6f46c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-07-12T13:43:41Z"
+ content="""
+In the linked issue, it is apparently bisected to 
+[[!commit 4b1b9d7a83f0da71665658e6234e699e182cbddc]] which added
+annex.freezecontent-command.
+
+But unless you're setting that config, I don't see it changing behavior,
+and if you are setting that config, it kind of follows that the behavior
+change is due to whatever you set it to?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621/comment_2_28ea6b8a7addc23f2eaf5626705fc789._comment b/doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621/comment_2_28ea6b8a7addc23f2eaf5626705fc789._comment
new file mode 100644
index 0000000000..4b3e83a313
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621/comment_2_28ea6b8a7addc23f2eaf5626705fc789._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2021-07-12T14:17:52Z"
+ content="""
+I don't know yet how, but I was just stating the fact that behavior has changed and we do not have yet added any handling for  `annex.freezecontent-command`. May be bisection was not entirely correct and it is some prior commit where it failed to build or smth like that - I didn't double check manually the status of prior commit etc.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621/comment_3_bd3faa20f746fcf4fd99a011b7453b38._comment b/doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621/comment_3_bd3faa20f746fcf4fd99a011b7453b38._comment
new file mode 100644
index 0000000000..fbf7e6e4f8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/change_in_behavior_after_8.20210621/comment_3_bd3faa20f746fcf4fd99a011b7453b38._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-07-12T14:26:14Z"
+ content="""
+<https://git-annex.branchable.com/bugs/regression__58___index.lck_in_shared-group_is_not_g+w/>
+fixed a problem where git-annex init entered an adjusted branch
+unexpectedly.
+
+Entering an adjusted branch involves creating a master branch at init time,
+because it has to have a branch existing in order to adjust it.
+
+So, these bugs appear to have the same cause. I'll close this dup.
+
+But, note that the same thing could happen if git-annex init were run on a
+crippled filesystem, so it may be your test needs to deal with
+such a new-born master branch.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/clash_of_-j__in_copy_for_--json_--json-progress.mdwn b/doc/projects/datalad/bugs-done/clash_of_-j__in_copy_for_--json_--json-progress.mdwn
new file mode 100644
index 0000000000..9464cee56d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/clash_of_-j__in_copy_for_--json_--json-progress.mdwn
@@ -0,0 +1,19 @@
+### What version of git-annex are you using? On what operating system?
+
+6.20170101+gitg93d69b1-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> git annex copy --help
+...
+  -j,--json                enable JSON output
+  -j,--json-progress       include progress in JSON output
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> Removed the short -j for --json-progress, I don't think that
+> needs a short option. [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change.mdwn b/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change.mdwn
new file mode 100644
index 0000000000..faa0b8bdd5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change.mdwn
@@ -0,0 +1,95 @@
+A [couple of failing tests][0] on DataLad's end pointed to a recent
+change in git-annex creating commits on the git-annex branch despite
+`-c annex.alwayscommit=false` being specified.  One of those tests
+checks that, when we're doing a bulk operation adding metadata to
+files, we don't generate many separate commits on the git-annex branch
+for each `git annex metadata` call.  Based of off that, here's a
+script that shows that `-c annex.alwayscommit=false` isn't honored on
+the second call to `git annex metadata`.
+
+[[!format sh """
+set -x
+
+cd "$(mktemp -d ${TMPDIR:-/tmp}/gx-XXXXXXX)"
+
+git init && git annex init
+>one && git annex add one && git commit -m'add one'
+
+ga_head=$(git rev-parse git-annex)
+git annex metadata -c annex.alwayscommit=false --set a=1 one
+git annex metadata -c annex.alwayscommit=false --set b=2 one
+git log --oneline --stat $ga_head..git-annex
+
+git annex merge
+git log --oneline --stat $ga_head..git-annex
+"""]]
+
+```
+[...]
++ git annex metadata -c annex.alwayscommit=false --set b=2 one
+metadata one (recording state in git...)
+
+  a=1
+  a-lastchanged=2020-04-14@21-16-48
+  b=2
+  b-lastchanged=2020-04-14@21-16-48
+  lastchanged=2020-04-14@21-16-48
+ok
++ git log --oneline --stat 8e7323181b1481aa6d8ed1059a46f8da29de0629..git-annex
+84b987f update
+ ...0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.log.met | 1 +
+ 1 file changed, 1 insertion(+)
++ git annex merge
+merge git-annex (recording state in git...)
+ok
++ git log --oneline --stat 8e7323181b1481aa6d8ed1059a46f8da29de0629..git-annex
+2cb57d6 update
+ ...0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.log.met | 1 +
+ 1 file changed, 1 insertion(+)
+84b987f update
+ ...0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.log.met | 1 +
+ 1 file changed, 1 insertion(+)
+```
+
+Before eedd73b84 (fix reversion caused by earlier optimisation to
+git-annex branch reads, 2020-04-10), the output of the first `git log`
+call would instead be empty, and the second log call (after `git annex
+merge`) would show a single commit for the metadata changes.
+
+I wasn't able to make much progress understanding eedd73b84 or the
+commit it references, aeca7c220 (Sped up query commands that read the
+git-annex branch by around 5%, 2020-04-09).  The main change in
+eedd73b84 is the addition of the `else` branch, so not too
+surprisingly I can restore the change in behavior by guarding the
+`else` branch with a condition that checks `annexAlwaysCommit` (diff
+below).  But I don't have a clear enough understanding to write a
+commit message that justifies that change or to be confident that this
+change is good overall (though `git annex test` did not report any
+failures).
+
+[[!format diff """
+diff --git a/Annex/Branch.hs b/Annex/Branch.hs
+index 712c5c10f..f248b3eb4 100644
+--- a/Annex/Branch.hs
++++ b/Annex/Branch.hs
+@@ -179,8 +179,9 @@ updateTo' pairs = do
+ 				 - a commit needs to be done. -}
+ 				when dirty $
+ 					go branchref dirty [] jl
+-			, when dirty $
+-				lockJournal $ go branchref dirty []
++			, whenM (annexAlwaysCommit <$> Annex.getGitConfig) $
++				when dirty $
++					lockJournal $ go branchref dirty []
+ 			)
+ 		else lockJournal $ go branchref dirty tomerge
+ 	return $ not $ null tomerge
+"""]]
+
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+[0]: https://github.com/datalad/datalad-extensions/pull/9
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_1_793ab4d52a3a4a3a30b0e72b72ac18eb._comment b/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_1_793ab4d52a3a4a3a30b0e72b72ac18eb._comment
new file mode 100644
index 0000000000..2189ebbf0a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_1_793ab4d52a3a4a3a30b0e72b72ac18eb._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-04-15T16:09:02Z"
+ content="""
+That change would lead to buggy behavior, because git-annex would then not
+stage the journal files, and the optimisation prevents it reading the
+journal files, so it would operate with out of date information.
+
+The right fix, I think is to avoid making a commit, and instead only stage
+the journal files into the annex index. 
+
+But probably only when annex.alwayscommit=false and still commit when it's
+true, because leaving staged changes in the annex index without
+committing them risks git gc deleting the objects used, which is a
+documented gotcha with annex.alwayscommit=false but not something users
+should otherwise need to worry about.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_2_1c0e6f07f1da2872455401ac97c4ccc8._comment b/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_2_1c0e6f07f1da2872455401ac97c4ccc8._comment
new file mode 100644
index 0000000000..d392fde7a4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_2_1c0e6f07f1da2872455401ac97c4ccc8._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-04-15T16:30:43Z"
+ content="""
+Tried to implement that approach, but it has a problem: Once the journal
+gets staged into the index, the journal is no longer dirty. So, when
+git-annex is later run with annex.alwayscommit=true, it won't know it needs
+to commit the index to the branch. It would only do so after some other
+subsequent change is made. So `git annex merge` would not commit the staged
+changes as it does now.
+
+Solving that would need some other indication that the index has staged
+changes in it, eg a flag file or some comparison of index file timestamp
+with the git-annex branch ref timestamp. But whatever it is would need to
+be checked for when annex.alwayscommit=true. So git-annex would become
+slower in the common case to support annex.alwayscommit=false.
+
+The slowdown would be much less than the win of the optimisation that
+caused this, but still I am not much of a fan of slowing things back down
+for an uncommon case.
+
+(The only way around that, maybe, would be to leave a file in the journal
+after staging it, so git-annex treats the journal as dirty without needing
+to check anything else, and so knows it needs to commit the annex index
+later. But then the journal would be treated as dirty every time git-annex
+starts up, and so would be staged into the index. Which would make running
+with annex.alwayscommit=false slower. Maybe the file could have a special
+name that git-annex knows it does not need to stage? This feels like a lot
+of complexity being added.)
+
+So, I'm now leaning more toward disabling the optimisation when
+annex.alwayscommit=false. The journal won't be staged to the index
+then, and git-annex will have to check for journalled changes as long
+as it's running with that configuration. No worse than it was before.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_3_d064cceaaded97ce52169ca176959187._comment b/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_3_d064cceaaded97ce52169ca176959187._comment
new file mode 100644
index 0000000000..75b3df0bcc
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_3_d064cceaaded97ce52169ca176959187._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-04-15T16:47:44Z"
+ content="""
+Found another problem with that optimisation: When
+annex.merge-annex-branches=false, the journal does
+not get staged or committed, but the optimisation
+assumes it always does. So, git-annex won't see any
+journalled changes then.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_4_8209bed5e7c10f74b3ac17c368c92023._comment b/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_4_8209bed5e7c10f74b3ac17c368c92023._comment
new file mode 100644
index 0000000000..4fd9392565
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/commits_created_despite_alwayscommit__61__false_as_of_recent_change/comment_4_8209bed5e7c10f74b3ac17c368c92023._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 4"
+ date="2020-04-15T18:02:29Z"
+ content="""
+Thanks for the fixes, as well for providing a nice description of your
+analysis for others to follow along.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output.mdwn b/doc/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output.mdwn
new file mode 100644
index 0000000000..8c4b2aed50
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+
+see below.  expected: entries on failed copies with "success"=false, and not just error messages 
+
+
+[[!format sh """
+
+$> git annex copy --to=neurosmaug svgtune_0.2.0.orig.tar.gz nonexisting                         
+git-annex: nonexisting not found                                       
+copy svgtune_0.2.0.orig.tar.gz (checking neurosmaug...) ok
+git-annex: copy: 1 failed
+
+$> git annex copy --to=neurosmaug svgtune_0.2.0.orig.tar.gz nonexisting --json
+git-annex: nonexisting not found
+{"command":"copy","note":"checking neurosmaug...","success":true,"key":"SHA256E-s5121--6d8f7d10206a120a42bec2cd29bc2365d09889fdf070ac8c67d1cff0b1539f63.tar.gz","file":"svgtune_0.2.0.orig.tar.gz"}
+git-annex: copy: 1 failed
+
+$> git annex version
+git-annex version: 6.20170220+gitg75a15e1ad-1~ndall+1
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[[!meta title="--json-error-messages could apply to file not found error"]]
+
+> [[wontfix|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output/comment_1_4ed0e29f0b599135b1b1c9197d58873b._comment b/doc/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output/comment_1_4ed0e29f0b599135b1b1c9197d58873b._comment
new file mode 100644
index 0000000000..d41ce9ebd4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output/comment_1_4ed0e29f0b599135b1b1c9197d58873b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-02T17:08:21Z"
+ content="""
+I get what you're saying, but there's a layering problem that prevents
+the JSON display of a higher layer being used by a lower layer that is
+finding files to operate on.
+
+Trying to copy a file that does not exist is a fundamentally
+different class of error that an error that occurs when copying a file
+that does exist. A memory read error resulting in a SIGBUS is a different
+class of error, as is a git failure due to a corrupted repository.
+git-annex fails in four entirely different ways in these four cases.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output/comment_2_cae2883d41b495a6722a7039f0ec2726._comment b/doc/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output/comment_2_cae2883d41b495a6722a7039f0ec2726._comment
new file mode 100644
index 0000000000..f2a4b04179
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output/comment_2_cae2883d41b495a6722a7039f0ec2726._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-05-28T15:39:53Z"
+ content="""
+Revisiting this old bug as it's still open. In the mean time,
+--json-error-messages was added. So at first I wondered if this file not
+found should be jsonified by that.
+
+Currently, the option adds a error-messages field to the json objects that
+are output for each file it acts on, so only messages specifically having
+to do with a specific thing it acts on get json error messages. As I
+mentioned before, it's not for capturing every possible error message, 
+and really cannot.
+
+In this case, there's at least a filename that coul be said to be
+being acted on, though of course it's not really acting on it since it DNE.
+What it could do is output a whole json object just for this file, eg:
+
+	{"command":"copy", "success":false, "file":"foo", "error-messages":"foo not found"}
+
+It would be rather hard to make that include the "command" field, because
+currently that is provided to showStart, and this error is happening
+in the seek stage instead. So the command name would have to be threaded
+through the seek actions to this error message.
+
+Even if that was done, the json object there is missing the "key" field
+too.
+
+So that would mean a special case that anything consuming the json could
+be broken by, if it expects to find a key field and does something with the
+key.
+
+I suppose maybe it could contain a key that somehow never exists and cannot
+exist? But this still seems likely to lead to some kind of breakage in some
+consumer of this. Just for example, maybe someone is consuming the json
+and building up a list of keys that failed to get copied. Later their
+program passes the keys to git-annex copy --key or something like that.
+If a key that will never exist gets emitted, it will gum up that program
+with something it will never succeed in copying, and it's easy to imagine
+that leading to undesirable behavior.
+
+So, the benefits seem outweighed by the drawbacks to me, unless there's a
+very good use case for really wanting the missing file in json output?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/could_standalone_copy_of_git_ship__47__deploy_hooks_samples_as_well_as_stock_git__63__.mdwn b/doc/projects/datalad/bugs-done/could_standalone_copy_of_git_ship__47__deploy_hooks_samples_as_well_as_stock_git__63__.mdwn
new file mode 100644
index 0000000000..a2bb3daff1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/could_standalone_copy_of_git_ship__47__deploy_hooks_samples_as_well_as_stock_git__63__.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+
+ATM, if bundled git is used instead of system-wide available (e.g. standalone git-annex's PATH is preceding system's /usr/bin), then user running 'git init' uses bundled version of git.  In comparison to "full regular" installation of git, bundled version doesn't carry hooks, so any "git init"ed with it repository would lack those samples in .git/hooks
+
+### What steps will reproduce the problem?
+
+just use bundled git and run "git init" in some new dir
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170209+gitg16be7b5cc-1~ndall+1
+
+
+### Please provide any additional information below.
+
+actually there is few more differences (/tmp/123 generated with bundled version) -- description, branches:
+
+[[!format sh """
+(git)hopa:/tmp/123[master]
+$> find .git
+.git
+.git/objects
+.git/objects/info
+.git/objects/pack
+.git/config
+.git/HEAD
+.git/refs
+.git/refs/tags
+.git/refs/heads
+
+(git)hopa:/tmp/123_system[master]
+$> find .git            
+.git
+.git/objects
+.git/objects/info
+.git/objects/pack
+.git/config
+.git/HEAD
+.git/refs
+.git/refs/tags
+.git/refs/heads
+.git/info
+.git/info/exclude
+.git/hooks
+.git/hooks/prepare-commit-msg.sample
+.git/hooks/pre-applypatch.sample
+.git/hooks/pre-rebase.sample
+.git/hooks/pre-receive.sample
+.git/hooks/pre-commit.sample
+.git/hooks/pre-push.sample
+.git/hooks/commit-msg.sample
+.git/hooks/post-update.sample
+.git/hooks/applypatch-msg.sample
+.git/hooks/update.sample
+.git/description
+.git/branches
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy.mdwn b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy.mdwn
new file mode 100644
index 0000000000..1a036f8a5d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy.mdwn
@@ -0,0 +1,90 @@
+### Please describe the problem.
+After initializing an empty new v7 repo in a remote NTFS drive from linux mounted via CIFS, adding new file fails with a SQLite3 error.
+Using a v5 repo in direct mode works (with git annex init --version=5).
+
+### What steps will reproduce the problem?
+[[!format sh """
+$ git init .
+$ git annex init test
+$ git annex add file1
+add file1
+git-annex: SQLite3 returned ErrorBusy while attempting to perform close: unable to close due to unfinalized statements or unfinished backups.
+failed
+git-annex: add: 1 failed
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+Ubuntu 19.04
+
+git-annex version: 7.20190129
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+$ mount
+//192.168.0.1/myserver/myfolder on /media/mydisk type cifs (rw,nosuid,nodev,noexec,relatime,vers=1.0,cache=none,username=myname,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.0.1,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=61440,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1)
+$ mkdir /media/mydisk/tmp
+$ cd /media/mydisk/tmp
+$ date > file1
+
+$ echo "The following fails..."
+$ git init .
+Dépôt Git vide initialisé dans /media/wdtv/tmp/.git/
+$ git annex init test
+init test 
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Basculement sur la branche 'adjusted/master(unlocked)'
+ok
+(recording state in git...)
+$ git annex add .
+add file1 
+git-annex: SQLite3 returned ErrorBusy while attempting to perform close: unable to close due to unfinalized statements or unfinished backups
+failed
+git-annex: add: 1 failed
+
+$ echo "The following works..."
+$ rm -rf .git/
+$ git init .
+Dépôt Git vide initialisé dans /media/wdtv/tmp/.git/
+$ git annex init --version=5 test
+init test 
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Enabling direct mode.
+ok
+(recording state in git...)
+$ git annex add .
+add file1 ok
+(recording state in git...)
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+When initializing the repo with v5 git-annex (git annex init --version=5 test), then the legacy direct mode is used and file addition works well.
+
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_10_b96755e44bedf262cbb32403f8edaf0b._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_10_b96755e44bedf262cbb32403f8edaf0b._comment
new file mode 100644
index 0000000000..22dddc60bb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_10_b96755e44bedf262cbb32403f8edaf0b._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2022-08-05T18:42:34Z"
+ content="""
+Another way this could be dealt with is to move the sqlite databases to
+a local filesystem.
+
+Since git-annex only ever uses them for caching information from git, it
+can rebuild them, so even a tempfs would work. And it would also be ok if
+two git-annex processes accessing the same repo used different sqlite
+databases, since they would both build up the same information.
+(Even if they were on different computers using a network filesystem.)
+
+This could be done with a git config. And perhaps get `git-annex init`
+to somehow probe for this problem and set the git config. Although, what
+path would it set it to?
+
+(Note that gitAnnexKeysDbIndexCache would also need to be moved since it
+contains information about the content of a sqlite database.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_11_9356da08c06aeae254fc84e44b0b3d14._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_11_9356da08c06aeae254fc84e44b0b3d14._comment
new file mode 100644
index 0000000000..46951f8c5a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_11_9356da08c06aeae254fc84e44b0b3d14._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2022-08-11T21:15:29Z"
+ content="""
+I have mostly implemented an annex.dbdir to relocate the sqlite databases.
+It's in the `dbdir` branch until I get it fully working.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_12_918ed48f23dfdc1fc95e3df9526b489c._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_12_918ed48f23dfdc1fc95e3df9526b489c._comment
new file mode 100644
index 0000000000..1837965358
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_12_918ed48f23dfdc1fc95e3df9526b489c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2022-08-12T17:07:51Z"
+ content="""
+annex.dbdir is now implemented. Note that it can safely be set to the same
+path in several repositories. If all your repositories were on cifs,
+you could even set it globally.
+
+This issue remains open because `git-annex init` ought to probe to
+determine when sqlite cannot be used on the repository's filesystem.
+I don't think it could itself set annex.dbdir to work around the
+problem, because what would it set it to? Maybe
+`~/.cache/git-annex/something`? Seems better for it to explain the
+problem to the user and suggest that they set it.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_13_baafac7f80ff4b7cc4cf078e4ab969c3._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_13_baafac7f80ff4b7cc4cf078e4ab969c3._comment
new file mode 100644
index 0000000000..c3f92feb5b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_13_baafac7f80ff4b7cc4cf078e4ab969c3._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2022-08-17T17:05:25Z"
+ content="""
+I've implemented probing by `git-annex init`, and it will display
+this message to help the user get it configured:
+
+	init  
+	  Detected a filesystem where Sqlite does not work.
+	
+	  (sqlite worker thread crashed: user error (SQLite3 returned ErrorBusy while attempting to perform close(synthetic)(after successful open)))
+	
+	  To work around this problem, you can set annex.dbdir to a directory on another filesystem.
+	
+	  For example: git config annex.dbdir $HOME/cache/git-annex
+	
+	git-annex: Not initialized.
+
+Going to close the bug since I think this is the best that it can be handled.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_1_ac112e35d792bdaeff268aae7ef0dc6a._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_1_ac112e35d792bdaeff268aae7ef0dc6a._comment
new file mode 100644
index 0000000000..da431f94e2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_1_ac112e35d792bdaeff268aae7ef0dc6a._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-09-13T16:31:27Z"
+ content="""
+I guess the CIFS must be the cause of the problem, 
+NTFS on linux works in my tests.
+
+Are you able to reliably reproduce this problem every time, or does
+it only fail that way some of the time?
+
+It would be good to know if this also happens with using sqlite3 at the
+command line on the CIFS mount point. Can you do this:
+
+	apt-get install sqlite3
+	sqlite3 /media/mydisk/tmp/db
+	create table foo (name varchar);
+	insert into foo "joey";
+	.exit
+
+And see if that also crashes.
+
+---
+
+According to <https://www.sqlite.org/c3ref/close.html>, a close can indeed
+fail with BUSY, and I guess the only thing to do then would be to keep
+retrying until sqlite hopefully gets around to finishing whatever it's
+doing.
+
+Or, it looks like using `sqlite3_close_v2` might be an option since
+that leaves the db running in the background until it's able to close.
+Although if git-annex is exiting at the time, that might be problimatic.
+`sqlite3_close_v2` is not currently available in the haskell bindings.
+
+Oddly, the docs say this should only happen when there are "unfinalized
+prepared statements or unfinished sqlite3_backup objects".
+I don't believe git-annex uses either. It seems likely something else
+in sqlite is failing that results in BUSY, and if that can be reproduced
+outside of git-annex it would be good to file a bug on sqlite about it.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e1c7bd12aba40c6d9e9c039fa0de8631._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e1c7bd12aba40c6d9e9c039fa0de8631._comment
new file mode 100644
index 0000000000..4388760c19
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e1c7bd12aba40c6d9e9c039fa0de8631._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-26T16:21:53Z"
+ content="""
+I've made git-annex catch the ErrorBusy at database close, and retry for up
+to 16 seconds. That's in [[!commit 9628ae2e6758d1ec6e10df7f3540cd78ce333f1f]]
+
+I don't know if that solves the problem. It would be good to try and find
+out.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e524de262247edc4c541ce3af92c48e0._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e524de262247edc4c541ce3af92c48e0._comment
new file mode 100644
index 0000000000..f38adabb5a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_2_e524de262247edc4c541ce3af92c48e0._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 2"
+ date="2019-09-25T07:41:51Z"
+ content="""
+Sorry for the long answer delay.
+
+I tried the given commands, after fixing the \"insert\" one a little (syntax).
+
+    $ sqlite3 /media/mydisk/tmp/db
+    SQLite version 3.27.2 2019-02-25 16:06:06
+    Enter \".help\" for usage hints.
+    sqlite> create table foo (name varchar);
+    Error: database is locked
+    sqlite> .exit
+
+    $ sqlite3 /tmp/db
+    SQLite version 3.27.2 2019-02-25 16:06:06
+    Enter \".help\" for usage hints.
+    sqlite> create table foo (name varchar);
+    sqlite> insert into foo \"joey\";
+    Error: near \"\"joey\"\": syntax error
+    sqlite> insert into foo (name) values (\"joey\")
+    sqlite> .exit
+
+    $ ls -l /media/mydisk/tmp/db
+    -rw-rw---- 1 olivier users 0 sept. 25  2019 db
+
+    $ ls -l /tmp/db
+    -rw-r--r-- 1 olivier olivier 12288 sept. 25 09:29 /tmp/db
+
+    $ echo \"test\" > /media/mydisk/tmp/test
+    $ ls -l /media/mydisk/tmp/test
+    -rw-rw---- 1 olivier users 5 sept. 25 09:34 /media/wdtv/tmp/test
+
+    $ id olivier
+    uid=1000(olivier) gid=1000(olivier)
+    groupes=1000(olivier),4(adm),8(mail),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),101(input),108(netdev),999(spi),998(i2c),997(gpio),114(lpadmin),1001(download)
+
+The diff between /tmp and /media/mydisk/tmp is the filesystem, /tmp being in RAM. It seems that sqlite does not like the user rights and owner of files mounted by CIFS, here \"olivier:users\", even though user \"olivier\" can read/write files there and belongs to group \"users\".
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_4_1e0f10f694f7d07c0ab75136daec669c._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_4_1e0f10f694f7d07c0ab75136daec669c._comment
new file mode 100644
index 0000000000..4145d7bbc2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_4_1e0f10f694f7d07c0ab75136daec669c._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-09-26T16:30:25Z"
+ content="""
+It looks more like a locking problem than a permission problem.
+
+Anyway, you've certainly shown that sqlite is not able to work well on that
+filesystem. 
+
+I forgot was that git-annex uses WAL mode for the database,
+and that will change how sqlite does locking. Can you please try this
+on a new database file:
+
+	sqlite3 /media/mydisk/tmp/db.new
+	PRAGMA journal_mode=WAL;
+	create table foo (name varchar);
+	insert into foo (name) values ("joey")
+	.exit
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_5_bc9b8c1b80a3308c997fdccbf8465f08._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_5_bc9b8c1b80a3308c997fdccbf8465f08._comment
new file mode 100644
index 0000000000..5c292a8a98
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_5_bc9b8c1b80a3308c997fdccbf8465f08._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-09-26T16:47:02Z"
+ content="""
+I've found several discussions about Sqlite on CIFS.
+
+https://stackoverflow.com/questions/42722855/sqlite-3-on-windows-share-cifs-access-from-ubuntu-nobrl-risk
+
+That also had all write actions fail with "locked".
+It suggests mounting the CIFS filesystem with the "nobrl" mount option.
+Another thread suggested instead the "nolock" mount option.
+
+Those may be worth trying, although I'd make sure that
+
+1. annex.pidlock is set to true in the repository's git config.
+As long as it is, disabling locking at the database level is not unsafe,
+since only one git-annex process will be able to use the database.
+
+2. You only ever use git-annex on one computer at a time in a given
+repository on this CIFS drive.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_6_21e8b47c5f100196f3d2062001a484d8._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_6_21e8b47c5f100196f3d2062001a484d8._comment
new file mode 100644
index 0000000000..97f617d22b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_6_21e8b47c5f100196f3d2062001a484d8._comment
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 6"
+ date="2019-09-26T20:39:41Z"
+ content="""
+The lock issue seems confirmed here. And the \"nobrl\" mount option solves the issue.
+
+Maybe you should inform the user about \"nobrl\" & \"annex.pidlock\" during the \"git annex init\" filesystem check, refuse to go on and propose legacy direct mode instead if user cannot accept to have no filesystem locking ?
+
+Without changing my mount options:
+
+    SQLite version 3.27.2 2019-02-25 16:06:06
+    Enter \".help\" for usage hints.
+    sqlite> PRAGMA journal_mode=WAL;
+    Error: database is locked
+    sqlite> create table foo (name varchar);
+    Error: database is locked
+    sqlite> insert into foo (name) values (\"joey\");
+    Error: no such table: foo
+    sqlite> .exit
+
+After adding \"nobrl\" in the mount options:
+
+    SQLite version 3.27.2 2019-02-25 16:06:06
+    Enter \".help\" for usage hints.
+    sqlite> PRAGMA journal_mode=WAL;
+    wal
+    sqlite> create table foo (name varchar);
+    sqlite> insert into foo (name) values (\"joey\");
+    sqlite> .exit
+
+It seems \"nolock\" is an alias for \"nobrl\", results are the same; when I put \"nolock\" in the mount options, I end up with \"nobrl\" in the \"mount\" command output.
+
+Finally, with the \"nobrl\" mount option:
+
+    $ cd /media/mydisk/tmp/
+    $ date > file1
+    $ git init .
+    Dépôt Git vide initialisé dans /media/mydisk/tmp/.git/
+    $ git annex init test
+    init test 
+      Detected a filesystem without fifo support.
+
+      Disabling ssh connection caching.
+
+      Detected a crippled filesystem.
+
+      Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+    Basculement sur la branche 'adjusted/master(unlocked)'
+    ok
+    (recording state in git...)
+    $ git annex add file1 
+    add file1 ok
+    (recording state in git...)
+
+Hurray ! 
+
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_7_36f796f2ed8cd91716ee5a083e5a5ace._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_7_36f796f2ed8cd91716ee5a083e5a5ace._comment
new file mode 100644
index 0000000000..699d1366c8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_7_36f796f2ed8cd91716ee5a083e5a5ace._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2019-09-27T16:48:49Z"
+ content="""
+I notice that `git annex init` is not able to detect that posix locks are not
+working (I assume they are not), so it doesn't enable pid locking. You
+should run: `git config annex.pidlock true`
+
+That could be improved: The current probe only tries to set an
+exclusive lock, but does not verify that the exclusive lock has any effect.
+But I'm a bit wary about all the ways verifying the lock could go wrong
+given that the posix locks are violating posix. Trying to take the lock
+nonblocking might block forever or any other undefined behavior.
+
+It does seem that init ought to test if sqlite can be used, and
+fail early otherwise. Better to learn about the problem before you start
+using the repository.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_8_0d34bfeab48421e35c6880bca639cbb2._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_8_0d34bfeab48421e35c6880bca639cbb2._comment
new file mode 100644
index 0000000000..8e059a15ea
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_8_0d34bfeab48421e35c6880bca639cbb2._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 8"
+ date="2022-08-05T16:17:09Z"
+ content="""
+We have got user of cifs filesystem mount [reprorting](https://github.com/datalad/datalad/issues/6917#issuecomment-1206358866) that setting pidlock didn't help while using git-annex 10.20220504-g35cafb7 and cifs mount with options 
+
+```
+type cifs (rw,relatime,vers=default,sec=krb5,cache=strict,multiuser,uid=164445,noforceuid,gid=100513,noforcegid,addr=172.19
+```
+
+Please advise to how to troubleshoot such situation.
+
+NB I might later try similarish cifs mount of our local HPC which I believe might expose it similarly.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_9_d0d441c94af2fe63ed1b20fb031181a3._comment b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_9_d0d441c94af2fe63ed1b20fb031181a3._comment
new file mode 100644
index 0000000000..d27ad40762
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_9_d0d441c94af2fe63ed1b20fb031181a3._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-08-05T18:05:45Z"
+ content="""
+@yoh Mounting the cifs filesystem with nobrl should avoid the problem.
+To make that safe, you *also* need to set annex.pidlock.
+
+Setting annex.pidlock on its own will not help.
+
+I don't think that git-annex can be changed in any way that makes sqlite
+work on this filesystem in its default state. What I discussed in comment
+#7 seems like the only feasible improvement to git-annex and would only
+help the user learn about the mount option.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/crippledfs__58___annex-init_crash_when_remote_name_is.mdwn b/doc/projects/datalad/bugs-done/crippledfs__58___annex-init_crash_when_remote_name_is.mdwn
new file mode 100644
index 0000000000..42e433d0b0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/crippledfs__58___annex-init_crash_when_remote_name_is.mdwn
@@ -0,0 +1,55 @@
+git-clone makes it easy to specify a name other than "origin" via the
+`--origin` option, and, as of Git 2.30.0, via the
+`clone.defaultRemoteName` configuration option.  Running `git annex
+init` in a clone on a system where git-annex sets
+`annex.crippledfilesystem` leads to a crash due to a hard-coded
+"refs/remotes/origin".
+
+[[!format sh """
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/ga-XXXXXXX)"  || exit 1
+
+export GIT_CONFIG_PARAMETERS="'annex.crippledfilesystem=true'"
+
+git version
+git annex version | head -1
+
+git init -q a
+git -C a commit -q --allow-empty -m c0
+git -C a annex init
+
+git clone --origin=not-origin a b
+git -C b annex init
+"""]]
+
+```
+git version 2.31.1.424.g95a8dafae5
+git-annex version: 8.20210331-g17646b0b3
+init  (scanning for unlocked files...)
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Switched to branch 'adjusted/master(unlocked)'
+ok
+(recording state in git...)
+Cloning into 'b'...
+done.
+init  (merging not-origin/git-annex into git-annex...)
+(scanning for unlocked files...)
+fatal: refs/remotes/origin/master: not a valid SHA1
+
+git-annex: git [Param "update-ref",Param "refs/heads/master",Param "refs/remotes/origin/master"] failed
+CallStack (from HasCallStack):
+  error, called at ./Git/Command.hs:42:17 in main:Git.Command
+failed
+git-annex: init: 1 failed
+```
+
+Thanks in advance for taking a look.
+
+Update: Before posting, I should have tried to trigger this without
+overriding `annex.crippledfilesystem`.  Entering an adjusted branch in
+`a` is sufficient to trigger this.
+
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/diffdriver_does_not_workout_on_unlocked_file__63__.mdwn b/doc/projects/datalad/bugs-done/diffdriver_does_not_workout_on_unlocked_file__63__.mdwn
new file mode 100644
index 0000000000..f0a221c448
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/diffdriver_does_not_workout_on_unlocked_file__63__.mdwn
@@ -0,0 +1,121 @@
+### Please describe the problem.
+
+[[!format sh """
+(git-annex)lena:/tmp/testds3[master]git-annex
+$> git diff HEAD^                            
+--- file.dat      2021-04-08 13:38:57.578593717 -0400
++++ /home/yoh/.tmp/hT81L0_file.dat        2021-04-08 13:39:04.794565306 -0400
+@@ -1 +1 @@
+-4
++/annex/objects/MD5E-s2--6d7fce9fee471194aa8b5b6e47267f03.dat
+"""]]
+
+NB edit: order of the diff is reverted from what it should be, I guess need to swap `$1` and `$2` in the driver
+
+<details>
+<summary>my current git config and (dirty) git-annex diffdriver</summary> 
+
+```shell
+
+$> git config  diff.external                                                          
+git-annex diffdriver -- git-annex-diff-wrapper --
+
+$> cat ~/bin/git-annex-diff-wrapper 
+#!/usr/bin/env bash                                                             
+#set -eu
+echo "Called with $@ under $PWD" >> /tmp/calls
+LANG=C colordiff --color=auto -u "$1" "$2"                                                   
+exit 0
+#LANG=C diff --color=always -u "$2" "$5"                                                   
+#LANG=C diff --color=always --ignore-matching-lines="\(AFNI version=\|time.*Elapsed\)" -u "$2" "$5"                                                   
+#label="$1:${2##*/}->${5##*/}" 
+label="$1"
+regex="XXXXXX" #\(AFNI version=\|time.*Elapsed\)"
+LANG=C diff --label "$1" --color=auto --ignore-matching-lines="$regex" -u "$2" "$5"                                                   
+exit 0
+
+```
+</details>
+
+<details>
+<summary>a more complete dump from the terminal</summary> 
+
+```shell
+(git-annex)lena:/tmp/testds3[master]git-annex
+$> rm  file.dat 
+(dev3) 1 70670 [3].....................................:Thu 08 Apr 2021 01:38:54 PM EDT:.
+(git-annex)lena:/tmp/testds3[master]git-annex
+$> echo 4 >| file.dat
+(dev3) 1 70671 [3].....................................:Thu 08 Apr 2021 01:38:57 PM EDT:.
+(git-annex)lena:/tmp/testds3[master]git-annex
+$> git commit -m 'commit unlocked 4' file.dat
+[master 5f57c78] commit unlocked 4
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+(dev3) 1 70672 [3].....................................:Thu 08 Apr 2021 01:39:02 PM EDT:.
+(git-annex)lena:/tmp/testds3[master]git-annex
+$> git diff HEAD^                            
+--- file.dat      2021-04-08 13:38:57.578593717 -0400
++++ /home/yoh/.tmp/hT81L0_file.dat        2021-04-08 13:39:04.794565306 -0400
+@@ -1 +1 @@
+-4
++/annex/objects/MD5E-s2--6d7fce9fee471194aa8b5b6e47267f03.dat
+(dev3) 1 70673 [3].....................................:Thu 08 Apr 2021 01:39:04 PM EDT:.
+(git-annex)lena:/tmp/testds3[master]git-annex
+$> cat file.dat 
+4
+(dev3) 1 70674 [3].....................................:Thu 08 Apr 2021 01:39:17 PM EDT:.
+(git-annex)lena:/tmp/testds3[master]git-annex
+$> git --version
+git version 2.29.2
+(dev3) 1 70675 [3].....................................:Thu 08 Apr 2021 01:39:24 PM EDT:.
+(git-annex)lena:/tmp/testds3[master]git-annex
+$> git annex version | head -n 1
+git-annex version: 8.20210223
+
+```
+</details>
+
+### What steps will reproduce the problem?
+
+<details>
+<summary>a complete but dirty (uses datalad) shell history</summary> 
+
+```shell
+datalad create /tmp/testds3
+cd /tmp/testds3
+echo 1 > file.dat
+datalad save -m 1
+rm file.dat
+echo 2 > file.dat
+datalad save -m 2
+git diff HEAD^^
+git diff HEAD^
+git annex unlock file.dat
+git add file.dat
+echo 3 >| file.dat
+git commit -m 'commit unlocked 3'
+git commit --amend
+git commit -m 'commit unlocked 3' file.dat
+git diff HEAD^
+git diff HEAD^^
+rm file.dat
+echo 4 >| file.dat
+git commit -m 'commit unlocked 4' file.dat
+git diff HEAD^
+cat file.dat
+git --version
+git annex version | head -n 1
+git status
+
+```
+</details>
+
+### What version of git-annex are you using? On what operating system?
+
+
+8.20210223
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/diffdriver_does_not_workout_on_unlocked_file__63__/comment_1_f5f0bb494672fb6b959c2a72a042467d._comment b/doc/projects/datalad/bugs-done/diffdriver_does_not_workout_on_unlocked_file__63__/comment_1_f5f0bb494672fb6b959c2a72a042467d._comment
new file mode 100644
index 0000000000..3fec3b29ea
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/diffdriver_does_not_workout_on_unlocked_file__63__/comment_1_f5f0bb494672fb6b959c2a72a042467d._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-08T18:09:25Z"
+ content="""
+Let's see, I have a file foo that was added, locked, and committed.
+I then unlock foo, and modify it. Then I run
+
+	GIT_EXTERNAL_DIFF='git-annex diffdriver -- my-diff --' git diff HEAD
+
+And my-diff is a shell script that prints "$@". So I see:
+
+	foo .git/annex/objects/W8/Zw/SHA256E-s30--9e179ece66f95419f996974c1e478294d6d6e8ea3eee2e6694d1d2fba5d82704/SHA256E-s30--9e179ece66f95419f996974c1e478294d6d6e8ea3eee2e6694d1d2fba5d82704 ebf7004afbf3838eaad7db6af8b77eb21eb1f810 120000 foo 0000000000000000000000000000000000000000 100644
+
+$2 is the old content of the file, which git-annex diffdriver has correctly
+fixed up to be the annex object file. $5 is the new version of the file
+which git-annex has not touched, but it's "foo" in the working tree, which is right.
+
+So that's ok, what about the other way around. Start with foo being unlocked,
+commit that, then modify it, and add it locked. Now I see:
+
+	foo /home/joey/tmp/5klQtl_foo 1a822e679e46982e0119f0ea725aaaffc6954f4b 100644 .git/annex/objects/wm/ZV/SHA256E-s8--ca7eb6f8a60a1abaddc1df52662184d6e7b33feca3cb5165343321dc35aeda17/SHA256E-s8--ca7eb6f8a60a1abaddc1df52662184d6e7b33feca3cb5165343321dc35aeda17 3ba78f367ca1a5b5bf6a4054a117d5d9a013073a 120000
+
+Here git-annex diffdriver has correctly fixed up $5, but $2 is left as-is,
+and if I have it cat that tmp file, it's "/annex/objects/SHA..."; the git-annex
+link used for the locked file.
+
+Ok, now I understand. :)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/does_not_complain__47__fail_if_by_mistake_option_value_passed_within_arg_for__-c.mdwn b/doc/projects/datalad/bugs-done/does_not_complain__47__fail_if_by_mistake_option_value_passed_within_arg_for__-c.mdwn
new file mode 100644
index 0000000000..e82cae2e15
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/does_not_complain__47__fail_if_by_mistake_option_value_passed_within_arg_for__-c.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+
+spotted that in my script I have "incorrectly" passed both -c and its value within the same single argument ('-c annex....').  But surprisingly annex neither treated it correctly, nor complained that something was incorrectly passed in.  Shouldn't it fail if option is not '-c' but '-c smthelse' or correctly treat the value in such as case?
+
+### What version of git-annex are you using? On what operating system?
+
+5.20151104+gitge9cdce6-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> ls -ld svgtune-0.2.0/README.rst
+-rw------- 1 yoh yoh 9 Nov 12 12:03 svgtune-0.2.0/README.rst
+
+$> git-annex add --debug '-c annex.largefiles=exclude=*.rst' svgtune-0.2.0/README.rst 
+add svgtune-0.2.0/README.rst ok
+(recording state in git...)
+
+$> ls -ld svgtune-0.2.0/README.rst                                                   
+lrwxrwxrwx 1 yoh yoh 189 Nov 12 12:03 svgtune-0.2.0/README.rst -> ../.git/annex/objects/32/vx/SHA256E-s9--246c960678ee9a80aa6d2eff2f1df1debd590cb73aa5fed6cb4b13b8018599f5.rst/SHA256E-s9--246c960678ee9a80aa6d2eff2f1df1debd590cb73aa5fed6cb4b13b8018599f5.rst
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> I guess it could be considered [[done]] --[[yoh]]
+
diff --git a/doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_.mdwn b/doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_.mdwn
new file mode 100644
index 0000000000..2886f455f7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_.mdwn
@@ -0,0 +1,198 @@
+### Please describe the problem.
+
+Originally [reported and troubleshooted against datalad](https://github.com/datalad/datalad/issues/3929).  With older git-annex, behavior was even worse -- the `.nfs*` file was left behind, forbidding datalad remove that repository directory entirely.  With later git-annex (eg. current `7.20200219+git135-g34d726cba-1~ndall+1`) situation improved:  No `.nfs*` file, but the KEY directory itself is still there:
+
+<details>
+<summary>Full protocol with details on NFS etc (click to expand)</summary> 
+
+[[!format sh """
+/tmp > mkdir -p /tmp/nfsmount{,_}                              
+
+/tmp > cat /etc/exports                                        
+/tmp/nfsmount_ localhost(rw)
+
+/tmp > sudo exportfs -a
+exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' specified for export "localhost:/tmp/nfsmount_".
+  Assuming default behaviour ('no_subtree_check').
+  NOTE: this default has changed since nfs-utils version 1.0.x
+
+
+/tmp > sudo mount -t nfs localhost:/tmp/nfsmount_ /tmp/nfsmount
+
+/tmp > mount | grep /tmp/nfsmount
+localhost:/tmp/nfsmount_ on /tmp/nfsmount type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr=::1)
+
+/tmp > cat /home/yoh/proj/datalad/trash/nfsdrop
+#!/bin/bash
+
+set -xeu
+
+git annex version 2>&1 | head -n 1
+
+if [ -e nfsdrop ]; then
+    chmod +w -R nfsdrop
+    rm -rf nfsdrop
+fi
+
+mkdir nfsdrop
+cd nfsdrop
+git init
+# git config --add annex.pidlock true
+git annex init
+echo 123 > file1
+git annex add file1
+git commit -m dummy
+tree -a .git/annex/objects 
+git annex drop --force file1
+tree -a .git/annex/objects 
+
+/tmp > git annex version
+git-annex version: 7.20200219+git135-g34d726cba-1~ndall+1
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+
+/tmp > cd nfsmount
+
+/tmp/nfsmount > /home/yoh/proj/datalad/trash/nfsdrop
++git annex version
++head -n 1
+git-annex version: 7.20200219+git135-g34d726cba-1~ndall+1
++'[' -e nfsdrop ']'
++mkdir nfsdrop
++cd nfsdrop
++git init
+Initialized empty Git repository in /tmp/nfsmount/nfsdrop/.git/
++git annex init
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
++echo 123
++git annex add file1
+add file1 
+ok                                
+(recording state in git...)
++git commit -m dummy
+[master (root-commit) f9539b4] dummy
+ 1 file changed, 1 insertion(+)
+ create mode 120000 file1
++tree -a .git/annex/objects
+.git/annex/objects
+└── G6
+    └── qW
+        └── SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+            └── SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+
+3 directories, 1 file
++git annex drop --force file1
+drop file1 ok
+(recording state in git...)
++tree -a .git/annex/objects
+.git/annex/objects
+└── G6
+    └── qW
+        └── SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+
+3 directories, 0 files
+
+/tmp/nfsmount > cat nfsdrop/.git/config 
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+[annex]
+	uuid = 7c5d4d5f-c2da-4616-8a91-25f9d932d7aa
+	version = 8
+[filter "annex"]
+	smudge = git-annex smudge -- %f
+	clean = git-annex smudge --clean -- %f
+
+
+"""]]
+
+</details>
+
+What was noticed is that git-annex did not decide to have pidlock enabled.
+<details>
+<summary>  If we enable it via config -- no KEY directory is left behind:
+</summary> 
+[[!format sh """
+/tmp/nfsmount > cat /home/yoh/proj/datalad/trash/nfsdrop
+#!/bin/bash
+
+set -xeu
+
+git annex version 2>&1 | head -n 1
+
+if [ -e nfsdrop ]; then
+    chmod +w -R nfsdrop
+    rm -rf nfsdrop
+fi
+
+mkdir nfsdrop
+cd nfsdrop
+git init
+git config --add annex.pidlock true
+git annex init
+echo 123 > file1
+git annex add file1
+git commit -m dummy
+tree -a .git/annex/objects 
+git annex drop --force file1
+tree -a .git/annex/objects 
+
+/tmp/nfsmount > /home/yoh/proj/datalad/trash/nfsdrop
++git annex version
++head -n 1
+git-annex version: 7.20200219+git135-g34d726cba-1~ndall+1
++'[' -e nfsdrop ']'
++chmod +w -R nfsdrop
++rm -rf nfsdrop
++mkdir nfsdrop
++cd nfsdrop
++git init
+Initialized empty Git repository in /tmp/nfsmount/nfsdrop/.git/
++git config --add annex.pidlock true
++git annex init
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
++echo 123
++git annex add file1
+add file1 
+ok                                
+(recording state in git...)
++git commit -m dummy
+[master (root-commit) ff91d78] dummy
+ 1 file changed, 1 insertion(+)
+ create mode 120000 file1
++tree -a .git/annex/objects
+.git/annex/objects
+└── G6
+    └── qW
+        └── SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+            └── SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+
+3 directories, 1 file
++git annex drop --force file1
+drop file1 ok
+(recording state in git...)
++tree -a .git/annex/objects
+.git/annex/objects
+
+0 directories, 0 files
+
+"""]]
+</details>
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> merged with
+> <https://git-annex.branchable.com/bugs/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/>
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_1_ef17dd348b2404000c29e7b41f1e5253._comment b/doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_1_ef17dd348b2404000c29e7b41f1e5253._comment
new file mode 100644
index 0000000000..23422d1a81
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_1_ef17dd348b2404000c29e7b41f1e5253._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-28T17:39:43Z"
+ content="""
+You should always enable pidlock on NFS.
+
+AFAIK, there has been no particular change to git-annex that prevents .nfs
+files from causing problems when git-annex uses posix file locking.
+There might have been some change in the behavior of a nfs server, eg
+it might delete the .nfs file *eventually*, but only after git-annex
+has tried, and failed, to delete the non-empty key directory. Seems like
+the kind of thing that network latency etc could make nondeterministic.
+
+There are already at least two other open bug reports wishing that
+git-annex somehow discover when a repo is on NFS and enable pidlock.
+<https://git-annex.branchable.com/bugs/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/>
+<https://git-annex.branchable.com/bugs/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/>
+
+(The second of those is really about something else, but it's been waiting
+on a fix being confirmed for 3 years, so the only useful part of it is I
+guess the last message in the thread, which discusses the difficulty of
+detecting NFS.)
+
+So I'm inclined to merge this bug report with the first of those.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_2_51a060d64f2dead1aa030596b0b34bc8._comment b/doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_2_51a060d64f2dead1aa030596b0b34bc8._comment
new file mode 100644
index 0000000000..bbd69601be
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_2_51a060d64f2dead1aa030596b0b34bc8._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-02-28T18:47:26Z"
+ content="""
+> AFAIK, there has been no particular change to git-annex that prevents .nfs files from causing problems when git-annex uses posix file locking. There might have been some change in the behavior of a nfs server, eg it might delete the .nfs file eventually, but only after git-annex has tried, and failed, to delete the non-empty key directory. Seems like the kind of thing that network latency etc could make nondeterministic.
+
+Just if that could shine any light, in aforementioned datalad issue, [this specific comment](https://github.com/datalad/datalad/issues/3929#issuecomment-589712933), I state (although show only for the recent annex) that without any change to NFS server/mount, and on a local nfs mount (so network is largely out of question) we ended with .nfs* files with older gitannex and without them in newer.  It might be some change in how git-annex deleted files/directories, but no change to NFS. 
+
+As for the git-annex version differences, inbetween I believe there was this fix [7.20190819-98-g94c75d2bd AKA 7.20190912~21](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=94c75d2bd9a50c6348f716b8b945b056cb56e447) for [regression: fails to detect need for pidlock on an NSF mount](https://git-annex.branchable.com/bugs/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/) which might or not be related -- didn't check
+
+
+> So I'm inclined to merge this bug report with the first of those.
+
+FWIW, that is ok with me.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_3_6c79c41676318bd976eff9988463d167._comment b/doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_3_6c79c41676318bd976eff9988463d167._comment
new file mode 100644
index 0000000000..f4ada35c68
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/drop_on_NFS___40__no_pidlock_need_detected__41___leaves_annex__47__objects__47__XX__47__YY__47__KEY_dir_behind_/comment_3_6c79c41676318bd976eff9988463d167._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-03-02T19:56:49Z"
+ content="""
+Sure, some minor change in git-annex could tickle non-deterministic
+behavior, eg something to do with timing of when it deletes the file 
+vs the later closing of the file that drops the lock.
+
+That regression made git-annex init fail when NFS doesn't have posix lock
+support enabled. It can detect that, and enables pidlock, but it can't
+detect NFS when it is pretending to support posix locks.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/dropkey_--batch_--json_--force_is_always_succesfull.mdwn b/doc/projects/datalad/bugs-done/dropkey_--batch_--json_--force_is_always_succesfull.mdwn
new file mode 100644
index 0000000000..51d2274df7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/dropkey_--batch_--json_--force_is_always_succesfull.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+just want to check if that is "by design"... --force was demanded seem operation is dangerous, but I expected that it would still report success false if key was not actually dropped, at least if a key is a completely wrong key
+
+so is that "by design" and I shouldn't care to check success field...?
+
+### What version of git-annex are you using? On what operating system?
+6.20160425+gitgffe2ea2-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+$> echo MD5E-s11--74d80f7d99b835e5189948c8d4297efd | git annex dropkey --batch --json --force
+{"command":"dropkey","key":"MD5E-s11--74d80f7d99b835e5189948c8d4297efd","success":true}
+
+$> ls -l
+total 0
+0 lrwxrwxrwx 1 yoh yoh 110 Apr 29 09:21 124 -> .git/annex/objects/MV/Jw/MD5E-s11--74d80f7d99b835e5189948c8d4297efd/MD5E-s11--74d80f7d99b835e5189948c8d4297efd
+
+$> echo MD5E-s11--74d80f7d99b835e5189948c8d4297efd | git annex dropkey --batch --json --force
+{"command":"dropkey","key":"MD5E-s11--74d80f7d99b835e5189948c8d4297efd","success":true}
+
+$> echo MD5E-s11--74d80f7dsd99b835e5189948c8d4297efd | git annex dropkey --batch --json --force 
+{"command":"dropkey","key":"MD5E-s11--74d80f7dsd99b835e5189948c8d4297efd","success":true}
+
+$> echo MD5E-s11--74d80f7dsd99b835e5189948c8d4297efdsdfsdf | git annex dropkey --batch --json --force 
+{"command":"dropkey","key":"MD5E-s11--74d80f7dsd99b835e5189948c8d4297efdsdfsdf","success":true}
+
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/duplicate_progress_reports_in_parallel___39__get__39__.mdwn b/doc/projects/datalad/bugs-done/duplicate_progress_reports_in_parallel___39__get__39__.mdwn
new file mode 100644
index 0000000000..adc7881d49
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/duplicate_progress_reports_in_parallel___39__get__39__.mdwn
@@ -0,0 +1,25 @@
+[[!format sh """
+$> git annex version                    
+git-annex version: 6.20160213+gitg9597a21-1~ndall+1
+...
+$> git annex get -J 5 .
+get docs/freesurfer.groupanalysis.ppt (from origin...) (checksum...) ok
+get docs/freesurfer.future_directions.2007.ppt (from origin...) (checksum...) ok
+get docs/freesurfer.groupanalysis.short.ppt (from origin...) (checksum...) ok
+get distribution/trctrain/trctraindata.tar.gz (from origin...) 
+47%          80.2MB/s 3s
+47%          80.2MB/s 3s
+get docs/freesurfer.inferring_architectonics.ppt (from origin...) 
+33%           8.1MB/s 4s
+33%           8.1MB/s 4s
+get docs/freesurfer.intro.2011.ppt (from origin...) 
+64%           7.3MB/s 1s
+64%           7.3MB/s 1s
+get docs/freesurfer.intro.mmclass.ppt (from origin...)
+# End of transcript or log.
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex.mdwn b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex.mdwn
new file mode 100644
index 0000000000..ae8e92873f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+
+Originally detected while testing newer (7.20200204+git1-gb2c529b88-1~ndall+1) [git-annex-standalone build against DataLad](https://github.com/datalad/datalad/pull/4116): one of our tests started to hang. Even using a different way of invoking external commands which was recently added to DataLad, it looks like `git annex enableremote` simply does not return:
+
+[[!format sh """
+[DEBUG  ] Async run ['git-annex', 'enableremote', '--debug', '-c', 'remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/3d284eaf', 'target2'] 
+[DEBUG  ] Launching process ['git-annex', 'enableremote', '--debug', '-c', 'remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/3d284eaf', 'target2'] 
+[DEBUG  ] Process 16621 started 
+[DEBUG  ] Waiting for process 16621 to complete 
+[Level 5] Read 46 bytes from 16621[stdout]: 
+[Level 9] stdout| (merging target2/git-annex into git-annex...)
+|   
+[Level 5] Read 28 bytes from 16621[stdout]: 
+[Level 9] stdout| (recording state in git...)
+|   
+No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
+"""]]
+
+[Full log link](https://travis-ci.org/datalad/datalad/jobs/655416864#L8664).
+
+Unfortunately ATM I do not have any further information, besides that we all failed to reproduce it locally and the issue is not happening with older build of git-annex-standalone (e.g. 7.20190819+git2-g908476a9b-1~ndall+1).
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> assuming [[fixed|done]], see my comment --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_10_1a3d3ade491f97e68a7bfcd853062875._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_10_1a3d3ade491f97e68a7bfcd853062875._comment
new file mode 100644
index 0000000000..8811fedd4d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_10_1a3d3ade491f97e68a7bfcd853062875._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 10"
+ date="2020-03-02T20:54:12Z"
+ content="""
+I am sorry! I rushed pasting I guess and didn't spot that pasted the wrong one.  Instead of `8.20200226+git16-ge156a2b74-1~ndall+1` I meant `7.20190819+git2-g908476a9b-1~ndall+1` which [we have in neurodebian ATM](http://neuro.debian.net/pkgs/git-annex-standalone.html?highlight=standalone). `8.20200226+git16-ge156a2b74-1~ndall+1`  is a bad one!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_11_d53e63d817a71ae88580c5b08ce28956._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_11_d53e63d817a71ae88580c5b08ce28956._comment
new file mode 100644
index 0000000000..5d9fcaac76
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_11_d53e63d817a71ae88580c5b08ce28956._comment
@@ -0,0 +1,71 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 11"
+ date="2020-03-03T17:48:16Z"
+ content="""
+> It would be worth checking on the server if ssh has run the process.
+
+Added a bunch of `ps auxw -H` calls in the code and monitoring of the process for when it calls enableremote on target2.  
+
+<details>
+<summary>
+Here is the diff for `ps auxw -H` right before running `enableremote` and then right after the outside process notes that it was ran (and probably hanged):
+</summary>
+
+
+```
+@@ -91,22 +91,28 @@
+ root      1745  0.0  0.2  82604 22000 ?        Ss   16:00   0:00   /usr/bin/python3 /usr/bin/google_accounts_daemon
+ root      1764  0.0  0.0  65512  6312 ?        Ss   16:00   0:00   /usr/sbin/sshd -D
+ root      1998  0.0  0.0  96936  7004 ?        Ss   16:00   0:00     sshd: travis [priv]
+-travis    2014  0.0  0.0  96936  3488 ?        S    16:00   0:00       sshd: travis@pts/0
++travis    2014  0.1  0.0  96936  3488 ?        S    16:00   0:00       sshd: travis@pts/0
+ travis    2015  0.1  0.1  31864 12732 pts/0    Ss+  16:00   0:00         bash /home/travis/build.sh
+ travis    2637  0.0  0.1 429472 16088 pts/0    Sl+  16:00   0:00           ruby /home/travis/.travis/agent
+ travis    9632  0.0  0.0  22448  2996 pts/0    S+   16:05   0:00           /bin/bash ../tools/ci/stalling-enable-remote.sh
+-travis    9634 20.7  0.5 165156 47104 pts/0    S+   16:05   0:03             python -m nose -s -v ../datalad/distribution/tests/test_publish.py:test_publish_depends
+-travis   17483  0.0  0.0   4508   788 pts/0    S+   16:05   0:00               sh -c echo '==== right before enableremote target2'; date; ps auxw -H
+-travis   17485  0.0  0.0  47388  3472 pts/0    R+   16:05   0:00                 ps auxw -H
+-travis   17344  0.0  0.0  17168   644 pts/0    S+   16:05   0:00             sleep 1
++travis    9634 20.8  0.5 165156 47108 pts/0    S+   16:05   0:03             python -m nose -s -v ../datalad/distribution/tests/test
++travis   17486  0.0  0.5 1074090736 42496 pts/0 Sl+ 16:05   0:00               /usr/lib/git-annex.linux/exe/git-annex --library-path
++travis   17510  0.0  0.0  21156  4264 pts/0    S+   16:05   0:00                 /usr/lib/git-annex.linux/exe/git --library-path /us
++travis   17511  0.0  0.0  21156  2228 pts/0    S+   16:05   0:00                 /usr/lib/git-annex.linux/exe/git --library-path /us
++travis   17512  0.0  0.0  21204  4160 pts/0    S+   16:05   0:00                 /usr/lib/git-annex.linux/exe/git --library-path /us
++travis   17520  0.0  0.0      0     0 pts/0    Z+   16:05   0:00                 [ssh] <defunct>
++travis   17552  0.0  0.0  47388  3440 pts/0    R+   16:05   0:00             ps auxw -H
+ root     16839  0.5  0.0  96936  6872 ?        Ss   16:05   0:00     sshd: travis [priv]
+ travis   16845  0.5  0.0  96936  4168 ?        S    16:05   0:00       sshd: travis@notty
+ root     17310  0.0  0.0  96936  6964 ?        Ss   16:05   0:00     sshd: travis [priv]
+ travis   17316  0.0  0.0  96936  4104 ?        S    16:05   0:00       sshd: travis@notty
++root     17521  0.0  0.0  96936  6924 ?        Ss   16:05   0:00     sshd: travis [priv]
++travis   17528  0.0  0.0  96936  3668 ?        S    16:05   0:00       sshd: travis@notty
+ travis    2008  0.0  0.0  45276  4664 ?        Ss   16:00   0:00   /lib/systemd/systemd --user
+ travis    2009  0.0  0.0  63256  1908 ?        S    16:00   0:00     (sd-pam)
+ root      3439  0.1  0.8 335396 68348 ?        Ssl  16:01   0:00   /usr/bin/dockerd -H fd://
+-root      3462  0.2  0.4 268004 34968 ?        Ssl  16:01   0:00     docker-containerd --config /var/run/docker/containerd/containerd.toml
++root      3462  0.2  0.4 268004 34968 ?        Ssl  16:01   0:00     docker-containerd --config /var/run/docker/containerd/container
+ travis    5658  0.0  0.0  11148   316 ?        Ss   16:03   0:00   ssh-agent
+-travis   16841  0.0  0.0  44924   704 ?        Ss   16:05   0:00   ssh -fN -o ControlMaster=auto -o ControlPersist=15m -o ControlPath=/home/travis/.cache/datalad/sockets/a1cd7d63 localhost
+-travis   17312  0.0  0.0  44924   708 ?        Ss   16:05   0:00   ssh -fN -o ControlMaster=auto -o ControlPersist=15m -o ControlPath=/home/travis/.cache/datalad/sockets/31d0eb5a datalad-test
++travis   16841  0.0  0.0  44924   704 ?        Ss   16:05   0:00   ssh -fN -o ControlMaster=auto -o ControlPersist=15m -o ControlPat
++travis   17312  0.0  0.0  44924   708 ?        Ss   16:05   0:00   ssh -fN -o ControlMaster=auto -o ControlPersist=15m -o ControlPat
++travis   17525  0.0  0.0  44928   712 ?        Ss   16:05   0:00   ssh: .git/annex/ssh/datalad-test [mux]
+```
+
+</details>
+
+[full travis log](https://api.travis-ci.org/v3/job/657811641/log.txt)  . Unfortunately the \"after\" call has truncated command lines :-/   But you can see new processes:
+
+```
++travis   17486  0.0  0.5 1074090736 42496 pts/0 Sl+ 16:05   0:00               /usr/lib/git-annex.linux/exe/git-annex --library-path
++travis   17510  0.0  0.0  21156  4264 pts/0    S+   16:05   0:00                 /usr/lib/git-annex.linux/exe/git --library-path /us
++travis   17511  0.0  0.0  21156  2228 pts/0    S+   16:05   0:00                 /usr/lib/git-annex.linux/exe/git --library-path /us
++travis   17512  0.0  0.0  21204  4160 pts/0    S+   16:05   0:00                 /usr/lib/git-annex.linux/exe/git --library-path /us
++travis   17520  0.0  0.0      0     0 pts/0    Z+   16:05   0:00                 [ssh] <defunct>
+...
++travis   17525  0.0  0.0  44928   712 ?        Ss   16:05   0:00   ssh: .git/annex/ssh/datalad-test [mux]
+```
+and no `configlist`.  so it does seems to be ssh stalling for some reason
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_12_435c4cad7d3837aa09292642b983f041._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_12_435c4cad7d3837aa09292642b983f041._comment
new file mode 100644
index 0000000000..9b88697575
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_12_435c4cad7d3837aa09292642b983f041._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2020-03-16T16:48:38Z"
+ content="""
+It seems to me that the process tree you pasted there comes from 
+the host where git-annex is running, and not the host that it sshes
+to in order to run git-annex-shell.
+
+What I was suggesting is, if ssh $host git-annex-shell seems to be hanging,
+it then makes sense to go look at $host and see if git-annex-shell is
+running there, or has already run there (eg looking at
+the ssh log). That bisects the problem space to one side or the other.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_13_afc2af08abebba808886464fbcd0b9d7._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_13_afc2af08abebba808886464fbcd0b9d7._comment
new file mode 100644
index 0000000000..d479374fba
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_13_afc2af08abebba808886464fbcd0b9d7._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 13"
+ date="2020-03-16T17:57:27Z"
+ content="""
+It should be the same host:
+
+```
+$> grep test /etc/hosts
+127.0.0.1  	datalad-test
+
+```
+
+FWIW more of details of my struggle is available on [datalad/pull/4265#issuecomment-597416284](https://github.com/datalad/datalad/pull/4265#issuecomment-597416284). The last suspicion was that may be while on travis that process simply doesn't return fully if it opens a new socket, path to which we provide but do not have ssh yet \"serving\" it.  Another side topic (might formalize later on) which might or not be related is that git-annex uses `ControlPersist=yes` thus without any time out. FWIW, when datalad starts one, we use `ControlPersist=15m` (we might want to reduce it but at least it is not forever).  Setting it to `ControlPersist=1m` (not `yes`) by git-annex, and hoping that ssh would close that eventually, might unstuck us... didn't try
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_14_a532adc63a5ad97ab37a0a775cda0d0e._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_14_a532adc63a5ad97ab37a0a775cda0d0e._comment
new file mode 100644
index 0000000000..6b9e30f342
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_14_a532adc63a5ad97ab37a0a775cda0d0e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2020-03-16T18:18:52Z"
+ content="""
+I'm having a hard time seeing what I can do about this. It's not clear that
+git-annex is at fault at all, I don't know how to reproduce it, etc.
+
+You should be able to bisect the what changed the behavior, I suppose.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_15_ba2420e2d8f41dbdafc839246b8362aa._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_15_ba2420e2d8f41dbdafc839246b8362aa._comment
new file mode 100644
index 0000000000..fbf7436a2c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_15_ba2420e2d8f41dbdafc839246b8362aa._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2020-03-16T18:27:34Z"
+ content="""
+Re ControlPersist=yes, git-annex runs ssh -O stop on a socket file on exit,
+unless some other git-annex process is also using that socket. So they don't
+hangaround stale. By passing options to make ssh use other sockets, 
+you bypass that.
+
+I do see in https://github.com/datalad/datalad/pull/4265
+that you seem to have reproduced the hang without running git-annex at all?
+Is that right? Seems to say not a git-annex bug. Perhaps some innocuous
+change in behavior by git-annex, that tickles whatever the real problem is.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_16_8768afda308d5afeee2002f53f5cbf2c._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_16_8768afda308d5afeee2002f53f5cbf2c._comment
new file mode 100644
index 0000000000..80f64e1bd7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_16_8768afda308d5afeee2002f53f5cbf2c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 16"
+ date="2020-03-16T19:54:42Z"
+ content="""
+overall - yes. It still might be just our \"Runner\" issue.  I am not 100% sure in that since a reimplementation (WitlessRunner, used now in many places of the master version) which shouldn't have similar drawbacks, and should not stall -- it did stall as well and we didn't dig yet deeper.  Another \"anecdotal\" observation was that I saw the \"python -m nose\" which runs our tests to not exit cleanly, waiting for some process to be done, or until I Ctrl-C it... didn't analyze that situation either.
+I will try to find some time to dig into this deeper and/or bisect (isn't easy/fun since didn't manage to reproduce locally yet).  Thank you for the details and comments about sockets -- I am yet to fully analyze that situation as well.  I just know that I do have some hanging around and they might have been initiated by a git-annex process which we start pointing to some not-yet initiated socket.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_17_06103ccf5423718b35d35d6b2e4f04d2._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_17_06103ccf5423718b35d35d6b2e4f04d2._comment
new file mode 100644
index 0000000000..02709b50c6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_17_06103ccf5423718b35d35d6b2e4f04d2._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 17"""
+ date="2020-08-28T17:48:47Z"
+ content="""
+Seems likely this was the same hang as 
+<https://git-annex.branchable.com/bugs/Recent_hang_with_rsync_remote_with_older_systems___40__Xenial__44___Jessie__41__/>
+
+* Xeniel
+* hang involving ssh
+* started close to 7.20200202
+
+If you can still reproduce this let me know,  but I'm closing it on that
+basis.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_1_e47d2cae9fa224bef2433eba4d21ec7e._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_1_e47d2cae9fa224bef2433eba4d21ec7e._comment
new file mode 100644
index 0000000000..ef44441219
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_1_e47d2cae9fa224bef2433eba4d21ec7e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-26T18:09:16Z"
+ content="""
+These strange options forcing use of unusual ssh sockets stick out.
+
+You don't indicate what kind of remote is being enabled. --debug output
+is often useful.
+
+The travis log is kind of enormous to take in, when all I want to know is
+the type of the remote, and maybe a --debug output. Grepping it seemed
+to suggest that target2 might be a regular git remote that has been fed
+into initremote, but I'm not sure?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_2_de71be6bdc853567ad52a05c591b3bb5._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_2_de71be6bdc853567ad52a05c591b3bb5._comment
new file mode 100644
index 0000000000..0e5d4fbdf5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_2_de71be6bdc853567ad52a05c591b3bb5._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-02-26T20:14:47Z"
+ content="""
+thank you for the quick follow up joey.  I got confused about
+
+> --debug output is often useful. ... and maybe a --debug output
+
+since all `--debug` output from running `enableremote` is present in the log extract I have shown AFAIK... started digging, if `--debug` preceds `-c` -- it is not in effect, filed a [dedicated issue](https://git-annex.branchable.com/bugs/--debug_is_not_in_effect_if_precedes_-c/?updated).
+
+
+I  repositioned `--debug` after `-c`. Results will appear later on [travis log](https://travis-ci.org/datalad/datalad/jobs/655516059?utm_medium=notification&utm_source=github_status) and I will update here.
+
+Re type of remote:  it is actually a regular git remote. Before running `enableremote` on my laptop it looks like:
+
+```
+[remote \"target2\"]
+	url = ssh://datalad-test/home/yoh/.tmp/datalad_temp_test_publish_dependsfgrfi8tn
+	fetch = +refs/heads/*:refs/remotes/target2/*
+	datalad-publish-depends = target1
+```
+
+and then after `enableremote`:
+
+```
+[remote \"target2\"]
+	url = ssh://datalad-test/home/yoh/.tmp/datalad_temp_test_publish_dependsfgrfi8tn
+	fetch = +refs/heads/*:refs/remotes/target2/*
+	datalad-publish-depends = target1
+	annex-uuid = 31b92c58-edd1-4675-8b06-7d40f3bcc40d
+	annex-ignore = false
+```
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_3_36b91cb600c0a14dedd58e91e97132d5._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_3_36b91cb600c0a14dedd58e91e97132d5._comment
new file mode 100644
index 0000000000..5e74e198d1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_3_36b91cb600c0a14dedd58e91e97132d5._comment
@@ -0,0 +1,100 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="--debug output"
+ date="2020-02-26T20:36:28Z"
+ content="""
+<details>
+<summary>here is the --debug output (well, logged by datalad, so there is some decoration) for the stuck `enableremote`</summary> 
+
+```shell
+[DEBUG  ] Async run ['git-annex', 'enableremote', '-c', 'remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35', 'target2', '--debug'] 
+[DEBUG  ] Launching process ['git-annex', 'enableremote', '-c', 'remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35', 'target2', '--debug'] 
+[DEBUG  ] Process 16886 started 
+[DEBUG  ] Waiting for process 16886 to complete 
+[Level 5] Read 232 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.411270506] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"show-ref\",\"git-annex\"]
+|   
+[Level 5] Read 309 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.414030967] process done ExitSuccess
+| [2020-02-26 20:21:00.414120854] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+|   
+[Level 5] Read 57 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.416528464] process done ExitSuccess
+|   
+[Level 5] Read 300 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.416774225] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"log\",\"refs/heads/git-annex..4205e0fe09bdb15c518d8475778452b26a0b931a\",\"--pretty=%H\",\"-n1\"]
+|   
+[Level 5] Read 57 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.420055075] process done ExitSuccess
+|   
+[Level 5] Read 300 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.420146676] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"log\",\"refs/heads/git-annex..e7c5d7333e2ba07d8eb6a4ddadd9affae13c40eb\",\"--pretty=%H\",\"-n1\"]
+|   
+[Level 5] Read 56 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.42378637] process done ExitSuccess
+|   
+[Level 5] Read 230 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.430135272] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"cat-file\",\"--batch\"]
+|   
+[Level 5] Read 278 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.432035636] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+|   
+[Level 5] Read 46 bytes from 16886[stdout]: 
+[Level 9] stdout| (merging target2/git-annex into git-annex...)
+|   
+[Level 5] Read 259 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.435904786] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+|   
+[Level 5] Read 244 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.438156653] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"update-index\",\"-z\",\"--index-info\"]
+|   
+[Level 5] Read 320 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.440579446] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"e7c5d7333e2ba07d8eb6a4ddadd9affae13c40eb\",\"--\"]
+|   
+[Level 5] Read 57 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.444964246] process done ExitSuccess
+|   
+[Level 5] Read 56 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.44534127] process done ExitSuccess
+|   
+[Level 5] Read 300 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.447359547] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"log\",\"e7c5d7333e2ba07d8eb6a4ddadd9affae13c40eb..refs/heads/git-annex\",\"--pretty=%H\",\"-n1\"]
+|   
+[Level 5] Read 57 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.450117916] process done ExitSuccess
+|   
+[Level 5] Read 28 bytes from 16886[stdout]: 
+[Level 9] stdout| (recording state in git...)
+|   
+[Level 5] Read 221 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.45026688] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"write-tree\"]
+|   
+[Level 5] Read 415 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.453577825] process done ExitSuccess
+| [2020-02-26 20:21:00.453656296] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"commit-tree\",\"bc6e2bf931ad9e846895d60189f9af41d9705724\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\",\"-p\",\"e7c5d7333e2ba07d8eb6a4ddadd9affae13c40eb\"]
+|   
+[Level 5] Read 57 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.456300928] process done ExitSuccess
+|   
+[Level 5] Read 287 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.45636449] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"remote.target1.annex-ssh-options=-o ControlMaster=auto -S /home/travis/.cache/datalad/sockets/44786c35\",\"update-ref\",\"refs/heads/git-annex\",\"c06d34b848f1a4095d0e2d59bf36b96469e168ea\"]
+|   
+[Level 5] Read 57 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.459600142] process done ExitSuccess
+|   
+[Level 5] Read 71 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.460816011] read: git [\"config\",\"--null\",\"--list\"]
+|   
+[Level 5] Read 57 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.462948244] process done ExitSuccess
+|   
+[Level 5] Read 246 bytes from 16886[stderr]: 
+[Level 9] stderr| [2020-02-26 20:21:00.464013355] read: ssh [\"datalad-test\",\"-S\",\".git/annex/ssh/datalad-test\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"git-annex-shell 'configlist' '/tmp/datalad_temp_test_publish_depends_q8i1lpv' '--debug'\"]
+|   
+No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
+Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received
+```
+</details>
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_4_2a15295f0a6f907d684ca5a7134619ac._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_4_2a15295f0a6f907d684ca5a7134619ac._comment
new file mode 100644
index 0000000000..e1cd7090d7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_4_2a15295f0a6f907d684ca5a7134619ac._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-02-28T18:44:07Z"
+ content="""
+Since this is a regular git remote, all enableremote
+does is the usual uuid probing. And that's where it hangs,
+sshing to the remote to run git-annex-shell configlist.
+
+One thing I notice is that you went to some trouble to pass 
+with -c annex-ssh-options for target1. I assume for some important reason,
+probably having to do with making ssh work in this environment.
+But this remote is target2, so it doesn't use those options when it sshes
+to it.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_5_e7a571699a2e564bb8364e353d9a1245._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_5_e7a571699a2e564bb8364e353d9a1245._comment
new file mode 100644
index 0000000000..42858484dc
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_5_e7a571699a2e564bb8364e353d9a1245._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2020-02-28T19:15:21Z"
+ content="""
+yes, we establish control paths (so all of us - git, git-annex, and datalad could use them and thus not re-prompting password by each tool).
+and I also spotted that we are missing control path for target2 -- [filed an issue](https://github.com/datalad/datalad/issues/4195).  But the curious point is that it doesn't stall with older git-annex.  I will rerun on travis with the same level of logging, but older git-annex, to see may be that interaction is somehow different.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_6_362351708d543f1d219dfcf8d71b5a14._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_6_362351708d543f1d219dfcf8d71b5a14._comment
new file mode 100644
index 0000000000..5b91e57281
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_6_362351708d543f1d219dfcf8d71b5a14._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2020-02-29T06:10:19Z"
+ content="""
+FWIW -- two excerpts:
+[good session](http://www.onerussian.com/tmp/travis-656403954.log), [bad session](http://www.onerussian.com/tmp/travis-655516047.log)
+command to obtain
+
+[[!format sh \"\"\"
+> for j in 655516047 656403954; do wget -q -O- https://api.travis-ci.org/v3/job/$j/log.txt | sed -n -e'/Launching.*nableremote.*target2/,100000p' | sed -ne '1,/^I: done/p' | sed -e 's/2020-..-.. ..:..:..\........../TIMESTAMP/g' >| /tmp/travis-$j.log; done
+\"\"\"]]
+
+still too much details and too many differences unfortunately. But at least shows that the same invocation of ssh proceeds normally in the good case (first one is the only one in bad, in good ones, more come):
+[[!format sh \"\"\"
+$> grep 'read: ssh .\"datalad-test\",' travis-6*.log      
+travis-655516047.log:[Level 9] stderr| [TIMESTAMP] read: ssh [\"datalad-test\",\"-S\",\".git/annex/ssh/datalad-test\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"git-annex-shell 'configlist' '/tmp/datalad_temp_test_publish_dependsymsjz245' '--debug'\"]
+travis-656403954.log:[Level 9] stderr| [TIMESTAMP read: ssh [\"datalad-test\",\"-S\",\".git/annex/ssh/datalad-test\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"git-annex-shell 'configlist' '/tmp/datalad_temp_test_publish_depends60annfb5' '--debug'\"]
+travis-656403954.log:[Level 9] stderr| [TIMESTAMP] read: ssh [\"datalad-test\",\"-S\",\".git/annex/ssh/datalad-test\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-o\",\"ControlMaster=auto\",\"-S\",\"/home/travis/.cache/datalad/sockets/04825add\",\"-n\",\"-T\",\"git-annex-shell 'configlist' '/tmp/datalad_temp_test_publish_dependsgxlws0yt' '--debug'\"]
+travis-656403954.log:[Level 11] stderr| [TIMESTAMP] read: ssh [\"datalad-test\",\"-S\",\".git/annex/ssh/datalad-test\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-o\",\"ControlMaster=auto\",\"-S\",\"/home/travis/.cache/datalad/sockets/04825add\",\"-n\",\"-T\",\"git-annex-shell 'commit' '/tmp/datalad_temp_test_publish_dependsgxlws0yt' '--debug' --uuid 7d69e4d6-f4d0-43c0-bf5a-0e6e8c363613\"] 
+travis-656403954.log:[Level 11] stderr| [TIMESTAMP] read: ssh [\"datalad-test\",\"
+\"\"\"]]
+
+and there is close to no chance for `\"git-annex-shell 'configlist' '/tmp/datalad_temp_test_publish_depends_q8i1lpv' '--debug'\"` to actually be the one which got stuck? (`ssh` is more likely of cause, but I am really not sure why...).  Note, that if download full log (urls are above), in that \"bad\" session
+```
+$> grep configlist log.txt 
+[Level 9] stderr| [2020-02-26 20:21:35.087032521] read: ssh [\"localhost\",\"-S\",\".git/annex/ssh/localhost\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-o\",\"ControlMaster=auto\",\"-S\",\"/home/travis/.cache/datalad/sockets/2e18ea6b\",\"-n\",\"-T\",\"git-annex-shell 'configlist' '/tmp/datalad_temp_test_publish_depends7k9yct_j' '--debug'\"]
+[Level 9] stderr| [2020-02-26 20:21:36.785462409] read: ssh [\"datalad-test\",\"-S\",\".git/annex/ssh/datalad-test\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"git-annex-shell 'configlist' '/tmp/datalad_temp_test_publish_dependsymsjz245' '--debug'\"]
+```
+so -- there is a prior session (probably to another remote) with configlist and that one works out just fine...  just that it goes to localhost, not datalad-test (set to 127.0.0.1 in /etc/hosts).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_7_1fbf8751d378f4e838e7f5ba6b43a6ca._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_7_1fbf8751d378f4e838e7f5ba6b43a6ca._comment
new file mode 100644
index 0000000000..998616974e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_7_1fbf8751d378f4e838e7f5ba6b43a6ca._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2020-03-02T17:10:12Z"
+ content="""
+It seems very unlikely that git-annex-shell configlist would get stuck,
+all it does is run git config --list.
+
+Not impossible of course. It would be worth checking on the server if
+ssh has run the process.
+
+What git-annex version is it that does not exhibit the problem?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_8_03d750b6461b965b33e1e4bed1242658._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_8_03d750b6461b965b33e1e4bed1242658._comment
new file mode 100644
index 0000000000..117cee9f6a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_8_03d750b6461b965b33e1e4bed1242658._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2020-03-02T19:34:40Z"
+ content="""
+Wait, the intial bug report said 7.20200204 had the
+problem, but you say the newer 8.20200226 does not?
+Either 8.20200226 was a typo of the wrong version,
+or it seems this bug has been fixed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_8_3f8ca763326523a79184192332107879._comment b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_8_3f8ca763326523a79184192332107879._comment
new file mode 100644
index 0000000000..2592d75833
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/enableremote_stuck_with_a_recentish_git-annex/comment_8_3f8ca763326523a79184192332107879._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 8"
+ date="2020-03-02T19:23:55Z"
+ content="""
+> What git-annex version is it that does not exhibit the problem?
+
+I know for sure that `8.20200226+git16-ge156a2b74-1~ndall+1` doesn't -- that is the one we are still distributing in neurodebian. In the past we tested other intermediate versions (like  7.20191114+git43-ge29663773) which also didn't exhibit it AT THAT TIME (different datalad, and possibly different git which gets bundled).
+
+> It would be worth checking on the server if ssh has run the process.
+
+I will try to do that later.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__.mdwn b/doc/projects/datalad/bugs-done/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__.mdwn
new file mode 100644
index 0000000000..3b527e6cc5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__.mdwn
@@ -0,0 +1,98 @@
+### Please describe the problem.
+
+In the past archived issue ([[https://webcache.googleusercontent.com/search?q=cache:t2N25kWAWEsJ:https://git-annex.branchable.com/bugs/encfs_accused_of_being_crippled/+&cd=1&hl=en&ct=clnk&gl=us]]) you have left a comment 
+
+    So, it seems worthwhile to break out lack of hard links support from the other limitations currently lumped into "cripped file system". I've done so.
+
+did it mean that encfs should be supported without assuming it crippled any longer?
+
+I have just tried with annex 6.20160425+gitgffe2ea2-1~ndall+1  and it still considers it crippled (FWIW and for the record encfs is 1.8.1-3+b2) 
+
+
+[[!format sh """
+$> git annex init --debug
+init  [2016-04-27 11:55:41.20934] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2016-04-27 11:55:41.214794] process done ExitFailure 1
+[2016-04-27 11:55:41.21487] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","origin/git-annex"]
+[2016-04-27 11:55:41.218775] process done ExitFailure 1
+[2016-04-27 11:55:41.219362] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2016-04-27 11:55:41.225289] process done ExitSuccess
+[2016-04-27 11:55:41.225379] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","4b825dc642cb6eb9a060e54bf8d69288fbee4904","--no-gpg-sign"]
+[2016-04-27 11:55:41.232881] process done ExitSuccess
+[2016-04-27 11:55:41.233028] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","243e083b39dbf3ae84014dfd9be82d93ab57feb1"]
+[2016-04-27 11:55:41.240395] process done ExitSuccess
+[2016-04-27 11:55:41.252322] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.uuid","75f66b80-d877-4f33-8b32-53dff9ac7da8"]
+[2016-04-27 11:55:41.25768] process done ExitSuccess
+[2016-04-27 11:55:41.257822] read: git ["config","--null","--list"]
+[2016-04-27 11:55:41.263729] process done ExitSuccess
+
+  Detected a crippled filesystem.
+[2016-04-27 11:55:41.283605] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.crippledfilesystem","true"]
+[2016-04-27 11:55:41.288741] process done ExitSuccess
+[2016-04-27 11:55:41.289113] read: git ["config","--null","--list"]
+[2016-04-27 11:55:41.294897] process done ExitSuccess
+
+  Disabling core.symlinks.
+[2016-04-27 11:55:41.295002] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","core.symlinks","false"]
+[2016-04-27 11:55:41.29995] process done ExitSuccess
+[2016-04-27 11:55:41.300036] read: git ["config","--null","--list"]
+[2016-04-27 11:55:41.305809] process done ExitSuccess
+[2016-04-27 11:55:41.30591] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2016-04-27 11:55:41.310985] process done ExitSuccess
+[2016-04-27 11:55:41.311082] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2016-04-27 11:55:41.316091] process done ExitSuccess
+[2016-04-27 11:55:41.316284] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..243e083b39dbf3ae84014dfd9be82d93ab57feb1","--pretty=%H","-n1"]
+[2016-04-27 11:55:41.322238] process done ExitSuccess
+[2016-04-27 11:55:41.323989] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2016-04-27 11:55:41.330709] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.version","5"]
+[2016-04-27 11:55:41.335578] process done ExitSuccess
+[2016-04-27 11:55:41.335656] read: git ["config","--null","--list"]
+[2016-04-27 11:55:41.340418] process done ExitSuccess
+
+  Enabling direct mode.
+[2016-04-27 11:55:41.340519] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","."]
+[2016-04-27 11:55:41.34474] process done ExitSuccess
+[2016-04-27 11:55:41.344828] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2016-04-27 11:55:41.349993] process done ExitSuccess
+[2016-04-27 11:55:41.352705] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2016-04-27 11:55:41.357245] process done ExitFailure 1
+[2016-04-27 11:55:41.357309] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","checkout","-q","-B","annex/direct/master"]
+[2016-04-27 11:55:41.362052] process done ExitSuccess
+[2016-04-27 11:55:41.362117] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","core.bare","true"]
+[2016-04-27 11:55:41.368411] process done ExitSuccess
+[2016-04-27 11:55:41.368536] read: git ["config","--null","--list"]
+[2016-04-27 11:55:41.373468] process done ExitSuccess
+[2016-04-27 11:55:41.373556] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.direct","true"]
+[2016-04-27 11:55:41.378578] process done ExitSuccess
+[2016-04-27 11:55:41.379147] read: git ["config","--null","--list"]
+[2016-04-27 11:55:41.38818] process done ExitSuccess
+[2016-04-27 11:55:41.388271] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2016-04-27 11:55:41.39251] process done ExitSuccess
+[2016-04-27 11:55:41.392591] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/annex/direct/master"]
+[2016-04-27 11:55:41.397179] process done ExitFailure 1
+[2016-04-27 11:55:41.416782] read: uname ["-n"]
+[2016-04-27 11:55:41.419832] process done ExitSuccess
+ok
+[2016-04-27 11:55:41.434629] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]
+[2016-04-27 11:55:41.435418] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+[2016-04-27 11:55:41.443936] process done ExitSuccess
+[2016-04-27 11:55:41.444038] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2016-04-27 11:55:41.449543] process done ExitSuccess
+(recording state in git...)
+[2016-04-27 11:55:41.450041] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2016-04-27 11:55:41.460223] process done ExitSuccess
+[2016-04-27 11:55:41.46035] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","a8504dac0ddbd154fff36b704b6d49c6eb573d6c","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2016-04-27 11:55:41.467958] process done ExitSuccess
+[2016-04-27 11:55:41.468059] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","c163e24c747d665d51bfa3f13026193956ef1313"]
+[2016-04-27 11:55:41.475227] process done ExitSuccess
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> Since this was opened, git-annex init has started warning
+> in this situation, "Filesystem allows writing to files whose
+> write bit is not set."
+> 
+> Anyway, not seeing anything to do here, so [[done]]. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__/comment_1_a3111068628efcfe8c5dbbe653805481._comment b/doc/projects/datalad/bugs-done/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__/comment_1_a3111068628efcfe8c5dbbe653805481._comment
new file mode 100644
index 0000000000..98455e1aed
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__/comment_1_a3111068628efcfe8c5dbbe653805481._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-27T16:59:51Z"
+ content="""
+git-annex does not these days treat lack of of hard link support as a crippled
+filesystem. It just falls back to copying files where it would make hard
+links.
+
+encfs is coming up crippled because it ignores lack of write bits on files;
+writing to a mode 444 file on an encfs filesystem by the owner of the file
+is allowed. 
+
+That breaks an important safeguard that git-annex relies on;
+for example this would work in a non-direct mode repository on an encfs
+filesystem, even though file permissions don't allow writing to annexed
+file contents:
+
+	joey@darkstar:/tmp/encfs/d> echo corrupt > bar
+
+So, you're really better off using direct mode on encfs.
+
+encfs has tons of other problems that make it not work well with
+git-annex, and generally insecure. I heartily recommend you reconsider
+using it.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata.mdwn b/doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata.mdwn
new file mode 100644
index 0000000000..0020caf269
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata.mdwn
@@ -0,0 +1,28 @@
+
+[[!format sh """
+(datalad-0.13) nastase@head2:/backup/tmp/sam-study-1021/containers/licenses$ git annex metadata freesurfer -s distribution-restrictions=sensitive
+metadata freesurfer 
+  distribution-restrictions=sensitive
+  distribution-restrictions-lastchanged=2020-06-26@14-15-10
+  lastchanged=2020-06-26@14-15-10
+ok
+(recording state in git...)
+error: invalid object 100644 13a548163abc38cac81810399bcf5a8792c56763 for 'group.log'
+fatal: git-write-tree: error building trees
+git-annex: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
+
+(datalad-0.13) nastase@head2:/backup/tmp/sam-study-1021/containers/licenses$ git annex version | head -n 1
+git-annex version: 8.20200617-g02765b8
+
+"""]]
+
+
+I think nothing odd was done besides trying to make this file saved unlocked for a while with datalad
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata/comment_1_d027727bb0063e82ef9f92c8558e191d._comment b/doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata/comment_1_d027727bb0063e82ef9f92c8558e191d._comment
new file mode 100644
index 0000000000..aa9063569b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata/comment_1_d027727bb0063e82ef9f92c8558e191d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2020-06-26T14:22:24Z"
+ content="""
+It is likely the side-effect from datalad's `install --reckless=ephemeral` where we symlink `.git/annex`
+"""]]
diff --git a/doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata/comment_2_e7d11326148bf27a0233d36e26e08e6a._comment b/doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata/comment_2_e7d11326148bf27a0233d36e26e08e6a._comment
new file mode 100644
index 0000000000..0c9549ccf3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata/comment_2_e7d11326148bf27a0233d36e26e08e6a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-06-26T16:13:43Z"
+ content="""
+Apparently .git/annex/index refers to a blob that is not in the git
+repository.
+
+I don't see a git-annex bug here.
+
+Making a shared clone rather than symlinking .git/annex would avoid this situation.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata/comment_3_3ef1310132adf09cd426e49c93503a88._comment b/doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata/comment_3_3ef1310132adf09cd426e49c93503a88._comment
new file mode 100644
index 0000000000..01de440d80
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/error__58___invalid_object__while_setting_metadata/comment_3_3ef1310132adf09cd426e49c93503a88._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-05-31T16:40:25Z"
+ content="""
+This certianly looks like a file handle leak in git-annex filter-process..
+
+A workaround for you would be to run:
+
+	git config --unset filter.annex.process
+
+I have tried to reproduce this. I made a repository with 10000 files,
+all annexed and unlocked. I upgraded it to repository version 9. I checked
+out a commit where all the files were not present yet, and then checked out
+a commit that had all the files present. It did not fail, and also I never
+saw it having more than a few files open.
+
+So there must be something else about your repository that is needed to
+reproduce this..
+
+(Weirdly, signal 15 is SIGTERM, so I don't know what would have caused it to
+receive that signal unless it was ctrl-c'd.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/error_message_in_addurl_is_not_channeled_into_json_record_with_--json-error-messages.mdwn b/doc/projects/datalad/bugs-done/error_message_in_addurl_is_not_channeled_into_json_record_with_--json-error-messages.mdwn
new file mode 100644
index 0000000000..68d052d656
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/error_message_in_addurl_is_not_channeled_into_json_record_with_--json-error-messages.mdwn
@@ -0,0 +1,29 @@
+### Please describe the problem.
+
+Original report: https://github.com/datalad/datalad/issues/3825
+
+
+[[!format sh """
+$> git annex addurl --json --json-error-messages s3://hcp-openaccess/HCP_1200/100206/.xdlm/100206_3T_Diffusion_unproc.json                                       
+Configuration does not allow accessing s3://hcp-openaccess/HCP_1200/100206/.xdlm/100206_3T_Diffusion_unproc.json
+download failed: Configuration does not allow accessing s3://hcp-openaccess/HCP_1200/100206/.xdlm/100206_3T_Diffusion_unproc.json
+{"command":"addurl","success":false,"error-messages":[],"file":null}
+git-annex: addurl: 1 failed
+
+$> git annex version | head
+git-annex version: 7.20191009-1~ndall+1
+...
+"""]]
+
+the reason for the failure overall is that `datalad` external special remote is not enabled.  So the error message might also be considered misleading -- it is not about "allowing" but rather being "not supported" since AFAIK git-annex doesn't support s3:// urls (see [an existing issue](https://git-annex.branchable.com/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/))
+
+If user convenience was something to strive for here, it should technically be possible for git annex to "sense" all available external special remotes and inquire them (without enabling) either they would support a given url, and then report to the user a more informative error message ("URL ... is not supported by git-annex.  You can initialize one of the available external special remotes which support that url: datalad, somebodies-s3, ...".  It could even check if the special remote is configured but not enabled and then replace "initialize" with "enable" in the message above).
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]], and I also converted a number of other places
+> where an error could leak through to stderr, although there are still
+> some places where direct writes to stderr happen -- I'll probably never
+> be able to guarantee --json-error-messages catches every possible stderr
+> output. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/export_-J_6__to_S3__58___transfer_already_in_progress.mdwn b/doc/projects/datalad/bugs-done/export_-J_6__to_S3__58___transfer_already_in_progress.mdwn
new file mode 100644
index 0000000000..f5dabbf854
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/export_-J_6__to_S3__58___transfer_already_in_progress.mdwn
@@ -0,0 +1,98 @@
+<details>
+<summary>git annex version</summary> 
+
+```shell
+git-annex version: 8.20201127-ga19b48c
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+```
+</details>
+
+<details>
+<summary>git annex info  on the repo</summary> 
+
+```shell
+trusted repositories: 0
+semitrusted repositories: 5
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        4d79a724-9e8c-4cce-b030-f712eed3e131 -- snastase@scotty.pni.Princeton.EDU:/mnt/bucket/labs/hasson/snastase/smaug/narratives/derivatives/fmriprep
+        5f96664f-23ba-4c25-8e75-9ca24fcd46f5 -- nastase@smaug:/mnt/datasets/incoming/nastase/narratives/derivatives/fmriprep [here]
+        bf6f56f3-f6b7-4df8-9898-a4226dc71400 -- [fcp-indi]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 34.8 terabytes (+1 megabyte reserved)
+local annex keys: 40135
+local annex size: 1.83 terabytes
+annexed files in working tree: 50622
+size of annexed files in working tree: 1.81 terabytes
+bloom filter size: 32 mebibytes (8% full)
+backend usage: 
+        MD5E: 50622
+```
+</details>
+
+```
+$ git show git-annex:remote.log | grep indi
+bf6f56f3-f6b7-4df8-9898-a4226dc71400 autoenable=true bucket=fcp-indi datacenter=US encryption=none exporttree=yes fileprefix=data/Projects/narratives/derivatives/fmriprep/ host=s3.amazonaws.com name=fcp-indi partsize=1GiB port=80 public=yes publicurl=https://s3.amazonaws.com/fcp-indi storageclass=STANDARD type=S3 versioning=yes timestamp=1607616182.971041s
+```
+
+the invocation `git annex export --to "$srname" --jobs 6 master` within our [script](https://github.com/datalad/datalad/issues/5227) ended with `git-annex: export: 360 failed`.  Scrolling back through the terminal (in screen) session  I saw
+
+```
+export fcp-indi sub-345/func/sub-345_task-notthefallintact_space-MNI152NLin2009cAsym_res-native_desc-aseg_dseg.nii.gz ok
+export fcp-indi sub-345/func/sub-345_task-notthefallintact_space-MNI152NLin2009cAsym_res-native_desc-preproc_bold.json (transfer already in progress, or unable to take transfer lock) failed
+export fcp-indi sub-345/anat/sub-345_hemi-L_pial.surf.gii ok
+```
+
+and alike for a few other files (until ran out of history, output was not `tee`-ed into a file).
+
+looking at that specific file
+
+```
+/mnt/datasets/incoming/nastase/narratives/derivatives/fmriprep$ ls -l sub-345/func/sub-345_task-notthefallintact_space-MNI152NLin2009cAsym_res-native_desc-preproc_bold.json
+lrwxrwxrwx 1 nastase nastase 126 Jul 16 16:33 sub-345/func/sub-345_task-notthefallintact_space-MNI152NLin2009cAsym_res-native_desc-preproc_bold.json -> ../../.git/annex/objects/45/xZ/MD5E-s87--c4e21e8310450e816749d8bd7541292f.json/MD5E-s87--c4e21e8310450e816749d8bd7541292f.json
+
+```
+
+and the content (key) is not unique: there is a good number of files for that key:
+
+
+```
+$ find -lname *MD5E-s87--c4e21e8310450e816749d8bd7541292f.json | nl | tail
+   215  ./sub-343/func/sub-343_task-notthefallintact_space-MNI152NLin6Asym_res-native_desc-preproc_bold.json
+   216  ./sub-343/func/sub-343_task-notthefallintact_space-T1w_desc-preproc_bold.json
+   217  ./sub-344/func/sub-344_task-notthefallintact_desc-preproc_bold.json
+   218  ./sub-344/func/sub-344_task-notthefallintact_space-MNI152NLin2009cAsym_res-native_desc-preproc_bold.json
+   219  ./sub-344/func/sub-344_task-notthefallintact_space-MNI152NLin6Asym_res-native_desc-preproc_bold.json
+   220  ./sub-344/func/sub-344_task-notthefallintact_space-T1w_desc-preproc_bold.json
+   221  ./sub-345/func/sub-345_task-notthefallintact_desc-preproc_bold.json
+   222  ./sub-345/func/sub-345_task-notthefallintact_space-MNI152NLin2009cAsym_res-native_desc-preproc_bold.json
+   223  ./sub-345/func/sub-345_task-notthefallintact_space-MNI152NLin6Asym_res-native_desc-preproc_bold.json
+   224  ./sub-345/func/sub-345_task-notthefallintact_space-T1w_desc-preproc_bold.json
+```
+
+so I guess it is the reason for the "issue".
+
+Note: some of those "duplicate"s were successfully exported, but not the one for which error was reported:
+
+```
+nastase@smaug:/mnt/datasets/incoming/nastase/narratives/derivatives/fmriprep$ s3cmd ls s3://fcp-indi/data/Projects/narratives/derivatives/fmriprep/sub-343/func/sub-343_task-notthefallintact_space-MNI152NLin6Asym_res-native_desc-preproc_bold.json
+2020-12-10 18:24        87   s3://fcp-indi/data/Projects/narratives/derivatives/fmriprep/sub-343/func/sub-343_task-notthefallintact_space-MNI152NLin6Asym_res-native_desc-preproc_bold.json
+
+nastase@smaug:/mnt/datasets/incoming/nastase/narratives/derivatives/fmriprep$ s3cmd ls s3://fcp-indi/data/Projects/narratives/derivatives/fmriprep/sub-345/func/sub-345_task-notthefallintact_space-MNI152NLin2009cAsym_res-native_desc-preproc_bold.json
+<no output was produced>
+```
+
+Besides reporting the issue, I also have a question:  could I just rerun `export` and it should be "safe/efficient" (not reupload what was already uploaded, thus producing DeleteMarkers, new versionIds etc)?  or I would need to manually fixup somehow to avoid heavy/lengthy re-upload?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] bypassed this unnecessary locking for exports. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/export_-J_6__to_S3__58___transfer_already_in_progress/comment_1_f81e00b5293f2df894dc3cd1678530c1._comment b/doc/projects/datalad/bugs-done/export_-J_6__to_S3__58___transfer_already_in_progress/comment_1_f81e00b5293f2df894dc3cd1678530c1._comment
new file mode 100644
index 0000000000..2aca9910e6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/export_-J_6__to_S3__58___transfer_already_in_progress/comment_1_f81e00b5293f2df894dc3cd1678530c1._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-12-10T21:49:03Z"
+ content="""
+Answer first: Re-running export will skip over things that it knows
+it already exported before, so should be efficient.
+
+Yes, it seems this is the same as the old issue where 2 files with the same
+key being sent to a remote concurrently failed like this. Fixed back then by
+skipping the second, redundant transfer. But in this case, since there are
+2 files on the remote, the data needs to be sent twice. So it probably just
+shouldn't guard against redundant transfers when exporting. Or if it does,
+it should use the ExportLocation, not the Key as what coulds as redundant..
+I will have to look at this later though.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/export_-J_6__to_S3__58___transfer_already_in_progress/comment_2_0efd2da2e467c0607d1903ada98a3f20._comment b/doc/projects/datalad/bugs-done/export_-J_6__to_S3__58___transfer_already_in_progress/comment_2_0efd2da2e467c0607d1903ada98a3f20._comment
new file mode 100644
index 0000000000..ec62286df3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/export_-J_6__to_S3__58___transfer_already_in_progress/comment_2_0efd2da2e467c0607d1903ada98a3f20._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-12-10T21:55:20Z"
+ content="""
+THANK YOU for the quick reply.  I will redo export then without -J to upload all those which initially failed. Thank you!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu.mdwn b/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu.mdwn
new file mode 100644
index 0000000000..ea1b42dac2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+
+actually it fails whenever HOME is crippled (not /tmp)
+
+```
+2021-01-22T03:59:51.9212395Z   Unit Tests v8 adjusted unlocked branch
+2021-01-22T03:59:51.9218586Z     add dup:                                              Init Tests
+2021-01-22T03:59:52.1497485Z   init: OK (0.23s)
+2021-01-22T03:59:53.3199842Z   add:  OK (1.17s)
+2021-01-22T03:59:53.3200475Z 
+2021-01-22T03:59:53.3200888Z All 2 tests passed (1.40s)
+2021-01-22T03:59:53.9335540Z OK (0.61s)
+2021-01-22T03:59:54.2385075Z     add extras:                                           OK (0.30s)
+2021-01-22T03:59:54.8735634Z     ignore deleted files:                                 OK (0.63s)
+2021-01-22T03:59:55.7703551Z     metadata:                                             OK (0.90s)
+2021-01-22T03:59:58.5056762Z     export_import:                                        FAIL (2.74s)
+2021-01-22T03:59:58.5061241Z       Test.hs:1884:
+2021-01-22T03:59:58.5061997Z       did not find expected content of dir/import
+2021-01-22T04:00:00.8296862Z     export_import_subdir:                                 OK (2.32s)
+2021-01-22T04:00:01.1359269Z     shared clone:                                         OK (0.31s)
+2021-01-22T04:00:01.4846753Z     log:                                                  OK (0.35s)
+```
+
+from  https://github.com/datalad/git-annex/runs/1746481387?check_suite_focus=true
+on 8.20201129+git169-gaa07e68ed-1~ndall+1 (presumably... identified 3 regressions today, may be we have a problem with our CI setup and building some old annex?)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_1_fcf8372714c74e5001b5a18c7100c7a1._comment b/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_1_fcf8372714c74e5001b5a18c7100c7a1._comment
new file mode 100644
index 0000000000..6a473788a5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_1_fcf8372714c74e5001b5a18c7100c7a1._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-01-25T15:34:39Z"
+ content="""
+Reproduced on fat with the current version. (You didn't say what your
+filesystem was however.)
+
+Seems quite possibly related to the recent change in
+[[!commit 73df633a6215faa093e4a7524c6d328aa988aed1]]. Since that 
+made the inode not be considered when importing, and since FAT has very
+low resolution timestamps (1s), repeated modifications of a file that don't
+change its size could not be noticed when repeatedly importing.
+
+But hmm, the test suite already guards against such a thing by making sure,
+when writing a new value to a file, that the modification time is different
+than before.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_2_1fb916ff03e0b8c96c554caf1558ecab._comment b/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_2_1fb916ff03e0b8c96c554caf1558ecab._comment
new file mode 100644
index 0000000000..76752cee51
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_2_1fb916ff03e0b8c96c554caf1558ecab._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-01-25T16:28:17Z"
+ content="""
+Confirmed that a sleep at the right place in the test suite avoids the
+failure. Unsure yet why the test suite's existing mtime managing didn't manage
+to. 
+
+I do think this should be fixed in the test suite; it's acceptable
+that, if using a FS like FAT that doesn't support high-rest mtimes,
+git-annex not deal with high-frequency modifications. The same behavior
+could already have happened on FAT when it was including the inode,
+if the modifications were done w/o overwriting changing the inode.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_3_18d4577c331bceceaffed7518902975a._comment b/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_3_18d4577c331bceceaffed7518902975a._comment
new file mode 100644
index 0000000000..8a276b1708
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_3_18d4577c331bceceaffed7518902975a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2021-01-25T16:49:36Z"
+ content="""
+FWIW, we actually only recently did the opposite -- [added inode](https://github.com/datalad/datalad/pull/5276) into consideration on our (datalad end) while monitoring for changes to `.git/config` files: `git` seems to rewrite those files (so inode changes)  which provided us a nice consistent indication and avoided crippled systems workarounds. Otherwise we were hitting all kinds of weird/hard to debug corner cases.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_3_d949841feb6a035e20a3d0f31634d388._comment b/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_3_d949841feb6a035e20a3d0f31634d388._comment
new file mode 100644
index 0000000000..25e9d0a879
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/export__95__import_fails_on_crippled_FS_on_ubuntu/comment_3_d949841feb6a035e20a3d0f31634d388._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-01-25T16:54:58Z"
+ content="""
+Oh this is interesting:
+
+	unexport foo import
+	  unsafe to remove modified file
+	failed
+	export foo import ok
+
+So despite seeing the file is modified when it is asked to remove it, it
+somehow does not notice that when writing to it, so overwrites it
+with the content anyway. That's how it ends up with
+unexpected content, despite the overall `git-annex export`
+failing as expected.
+
+And the root cause is, the test suite writes to the file on the remote,
+and then Remote.Directory writes to a temp file, and then gets its content
+identifier (mtime), and for some reason accepts that content identifier as
+one it can overwrite. Due to the timestamp resolution, that's the same
+content identifier as the newly written file on the remote. So it
+overwrites it.
+
+I can't find any good reason for it to accept the temp file's content
+identifier as a known content identifier, which it's always done. Other remotes
+don't do that. So I think this is a real bug in Remote.Directory and will
+fix it there.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten.mdwn b/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten.mdwn
new file mode 100644
index 0000000000..83e2616476
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten.mdwn
@@ -0,0 +1,95 @@
+### Please describe the problem.
+
+original report: https://github.com/datalad/datalad/issues/3583
+
+### What steps will reproduce the problem?
+
+initial get -J8 largely fails (ok for 1 file in one thread I guess) but subsequent succeeds:
+
+[[!format sh """
+hopa:/tmp
+$> git clone https://github.com/OpenNeuroDatasets/ds000248 && cd ds000248 && git annex init && git annex get -J 8 sub-01 
+Cloning into 'ds000248'...                                                                                     
+remote: Enumerating objects: 161, done.
+remote: Total 161 (delta 0), reused 0 (delta 0), pack-reused 161
+Receiving objects: 100% (161/161), 18.55 KiB | 863.00 KiB/s, done.
+Resolving deltas: 100% (20/20), done.
+CHANGES  acq-epi_T1w.json  acq-flipangle05_run-01_MEFLASH.json  acq-flipangle30_run-01_MEFLASH.json  dataset_description.json  derivatives/  sub-01/  sub-emptyroom/
+init  (merging origin/git-annex into git-annex...)
+(recording state in git...)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+(Auto enabling special remote s3-PUBLIC...)
+ok
+(recording state in git...)
+get sub-01/meg/sub-01_task-audiovisual_run-01_meg.fif (from s3-PUBLIC...) 
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+
+  unknown export location
+
+  Unable to access these remotes: s3-PUBLIC
+
+  Try making some of these repositories available:
+  	82a4b182-753f-4d93-a59e-20cfdd4d4237 -- [s3-PUBLIC]
+   	e3612a8a-0c48-4374-9bfb-888f4010be54 -- root@1f69c4ed80cf:/datalad/ds000248
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+get sub-01/anat/sub-01_acq-flipangle30_run-01_MEFLASH.nii.gz (from s3-PUBLIC...) 
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+
+  unknown export location
+
+  Unable to access these remotes: s3-PUBLIC
+
+  Try making some of these repositories available:
+  	82a4b182-753f-4d93-a59e-20cfdd4d4237 -- [s3-PUBLIC]
+   	e3612a8a-0c48-4374-9bfb-888f4010be54 -- root@1f69c4ed80cf:/datalad/ds000248
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+get sub-01/anat/sub-01_T1w.nii.gz (from s3-PUBLIC...) 
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+
+  unknown export location
+
+  Unable to access these remotes: s3-PUBLIC
+
+  Try making some of these repositories available:
+  	82a4b182-753f-4d93-a59e-20cfdd4d4237 -- [s3-PUBLIC]
+   	e3612a8a-0c48-4374-9bfb-888f4010be54 -- root@1f69c4ed80cf:/datalad/ds000248
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+get sub-01/anat/sub-01_acq-flipangle05_run-01_MEFLASH.nii.gz (from s3-PUBLIC...) 
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+(recording state in git...)
+git-annex: get: 3 failed
+
+$> git annex get -J 8 sub-01
+get sub-01/anat/sub-01_T1w.nii.gz (from s3-PUBLIC...) 
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+get sub-01/anat/sub-01_acq-flipangle30_run-01_MEFLASH.nii.gz (from s3-PUBLIC...) 
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+get sub-01/meg/sub-01_task-audiovisual_run-01_meg.fif (from s3-PUBLIC...) 
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+(recording state in git...)
+
+"""]]
+
+
+### What version of git-annex are you using? On what operating system?
+
+7.20190708+git36-g32d526164-1~ndall+1
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
+
+> fixed in [7.20200219-129-ge52034150 AKA 8.20200226~12](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=7.20200219-129-ge52034150) --[[yarikoptic]]
diff --git a/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_1_917b46d9ca69c4e8181d041d5414d373._comment b/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_1_917b46d9ca69c4e8181d041d5414d373._comment
new file mode 100644
index 0000000000..0c2e7c1dea
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_1_917b46d9ca69c4e8181d041d5414d373._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-23T19:26:20Z"
+ content="""
+Looking in the git-annex branch of this repository, for information about
+a key such as  MD5E-s10555001--f8bc87e8841634b3d2f9ac0ba85d0a83.nii.gz.log
+which is one of the files that fails to download, all there is is this:
+
+	joey@darkstar:/tmp/ds000248#git-annex>cat ./f0b/978/MD5E-s10555001--f8bc87e8841634b3d2f9ac0ba85d0a83.nii.gz.log 
+	1531766688.020213886s 1 82a4b182-753f-4d93-a59e-20cfdd4d4237
+	1531766681.703832952s 1 e3612a8a-0c48-4374-9bfb-888f4010be54
+
+So location log says it's in s3-PUBLIC, but in fact no S3 version id has been recorded.
+
+And there were old bugs that prevented the recording of the S3 version id. 
+Notably, it used to be possible to set versioning=yes on an existing S3
+remote, and the files already stored in it necessarily lacked version ids
+then. That has been fixed.
+
+So, is it still possible to reproduce creating a repository with this problem?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_2_363c4a87018de7be3286d88d0d5f8ebf._comment b/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_2_363c4a87018de7be3286d88d0d5f8ebf._comment
new file mode 100644
index 0000000000..113d9ed522
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_2_363c4a87018de7be3286d88d0d5f8ebf._comment
@@ -0,0 +1,231 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="requires -c annex.retry=2 to workaround"
+ date="2020-02-26T17:34:55Z"
+ content="""
+no, it would not be easily possible to reproduce such a dataset, but there is an ample number of them now available from openneuro.
+Another example on ds000115, where no versioning information seems to be available as well.
+
+<details>
+<summary>But it seems to be getting files just fine on a fast box with fast network (smaug) and annex 7.20190819+git2-g908476a9b-1~ndall+1</summary> 
+
+```shell
+$> ( sudo rm -rf tmpds && git clone https://github.com/OpenNeuroDatasets/ds000115.git tmpds && builtin cd tmpds && git annex enableremote s3-PUBLIC && git annex get -J 8 --json sub-01 && echo \"success\" || { echo \"try again\"; gi
+t annex get -J 8 sub-01; } )
+Cloning into 'tmpds'...
+remote: Enumerating objects: 4222, done.
+remote: Counting objects: 100% (4222/4222), done.
+remote: Compressing objects: 100% (2921/2921), done.
+remote: Total 4222 (delta 259), reused 4222 (delta 259), pack-reused 0
+Receiving objects: 100% (4222/4222), 389.19 KiB | 4.93 MiB/s, done.
+Resolving deltas: 100% (259/259), done.
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+enableremote s3-PUBLIC ok
+(recording state in git...)
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  unknown export location
+  unknown export location
+  unknown export location
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+{\"command\":\"get\",\"note\":\"from s3-PUBLIC...\nfrom s3-PUBLIC...\nchecksum...\",\"success\":true,\"key\":\"MD5E-s19916325--b0bc24ff278e3ef7031e6c801fc6c694.nii.gz\",\"file\":\"sub-01/func/sub-01_task-letter2backtask_bold.nii.gz\"}
+{\"command\":\"get\",\"note\":\"from s3-PUBLIC...\nchecksum...\",\"success\":true,\"key\":\"MD5E-s19915954--e9f91cc343144c541ca35831c62e9503.nii.gz\",\"file\":\"sub-01/func/sub-01_task-letter1backtask_bold.nii.gz\"}
+{\"command\":\"get\",\"note\":\"from s3-PUBLIC...\nfrom s3-PUBLIC...\nchecksum...\",\"success\":true,\"key\":\"MD5E-s35278866--09ae0c4f8a8eb6d379104e9ab9ca577a.nii.gz\",\"file\":\"sub-01/anat/sub-01_T1w.nii.gz\"}
+{\"command\":\"get\",\"note\":\"from s3-PUBLIC...\nfrom s3-PUBLIC...\nchecksum...\",\"success\":true,\"key\":\"MD5E-s19875519--1a412c009b3d247b95f774b9099d55a8.nii.gz\",\"file\":\"sub-01/func/sub-01_task-letter0backtask_bold.nii.gz\"}
+success
+2 16341.....................................:Wed 26 Feb 2020 12:19:20 PM EST:.
+smaug:/mnt/btrfs/scrap/tmp
+$> git annex version
+git-annex version: 7.20190819+git2-g908476a9b-1~ndall+1
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512
+E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 S
+HA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+
+```
+</details>
+
+<details>
+<summary>while it fails to get all files upon initial attempt on my laptop with annex 7.20200204+git62-gcc4521068-1~ndall+1 </summary> 
+
+```shell
+lena:/tmp
+$> ( sudo rm -rf tmpds && git clone https://github.com/OpenNeuroDatasets/ds000115.git tmpds && builtin cd tmpds && git annex enableremote s3-PUBLIC && git annex get -J 8 --json sub-01 && echo \"success\" || { echo \"try again\"; git annex get -J 8 sub-01; } )
+Cloning into 'tmpds'...
+remote: Enumerating objects: 4222, done.
+remote: Counting objects: 100% (4222/4222), done.
+remote: Compressing objects: 100% (2921/2921), done.
+remote: Total 4222 (delta 259), reused 4222 (delta 259), pack-reused 0
+Receiving objects: 100% (4222/4222), 389.19 KiB | 753.00 KiB/s, done.
+Resolving deltas: 100% (259/259), done.
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+enableremote s3-PUBLIC ok
+(recording state in git...)
+  8.76s user 3.42s system 99% cpu 12.267 total
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  unknown export location
+  unknown export location
+  unknown export location
+{\"command\":\"get\",\"wanted\":[{\"here\":false,\"uuid\":\"3970e64d-b24a-48e7-83b4-1ec6fdaa229d\",\"description\":\"[s3-PUBLIC]\"},{\"here\":false,\"uuid\":\"4a13d847-362b-4211-9124-861b9a8f4c13\",\"description\":\"root@6dedfdc60b41:/datalad/ds000115\"}],\"note\":\"from s3-PUBLIC...\nUnable to access these remotes: s3-PUBLIC\nTry making some of these repositories available:\n\t3970e64d-b24a-48e7-83b4-1ec6fdaa229d -- [s3-PUBLIC]\n \t4a13d847-362b-4211-9124-861b9a8f4c13 -- root@6dedfdc60b41:/datalad/ds000115\n\n(Note that these git remotes have annex-ignore set: origin)\",\"skipped\":[],\"success\":false,\"key\":\"MD5E-s35278866--09ae0c4f8a8eb6d379104e9ab9ca577a.nii.gz\",\"file\":\"sub-01/anat/sub-01_T1w.nii.gz\"}
+{\"command\":\"get\",\"wanted\":[{\"here\":false,\"uuid\":\"3970e64d-b24a-48e7-83b4-1ec6fdaa229d\",\"description\":\"[s3-PUBLIC]\"},{\"here\":false,\"uuid\":\"4a13d847-362b-4211-9124-861b9a8f4c13\",\"description\":\"root@6dedfdc60b41:/datalad/ds000115\"}],\"note\":\"from s3-PUBLIC...\nUnable to access these remotes: s3-PUBLIC\nTry making some of these repositories available:\n\t3970e64d-b24a-48e7-83b4-1ec6fdaa229d -- [s3-PUBLIC]\n \t4a13d847-362b-4211-9124-861b9a8f4c13 -- root@6dedfdc60b41:/datalad/ds000115\n\n(Note that these git remotes have annex-ignore set: origin)\",\"skipped\":[],\"success\":false,\"key\":\"MD5E-s19915954--e9f91cc343144c541ca35831c62e9503.nii.gz\",\"file\":\"sub-01/func/sub-01_task-letter1backtask_bold.nii.gz\"}
+{\"command\":\"get\",\"wanted\":[{\"here\":false,\"uuid\":\"3970e64d-b24a-48e7-83b4-1ec6fdaa229d\",\"description\":\"[s3-PUBLIC]\"},{\"here\":false,\"uuid\":\"4a13d847-362b-4211-9124-861b9a8f4c13\",\"description\":\"root@6dedfdc60b41:/datalad/ds000115\"}],\"note\":\"from s3-PUBLIC...\nUnable to access these remotes: s3-PUBLIC\nTry making some of these repositories available:\n\t3970e64d-b24a-48e7-83b4-1ec6fdaa229d -- [s3-PUBLIC]\n \t4a13d847-362b-4211-9124-861b9a8f4c13 -- root@6dedfdc60b41:/datalad/ds000115\n\n(Note that these git remotes have annex-ignore set: origin)\",\"skipped\":[],\"success\":false,\"key\":\"MD5E-s19916325--b0bc24ff278e3ef7031e6c801fc6c694.nii.gz\",\"file\":\"sub-01/func/sub-01_task-letter2backtask_bold.nii.gz\"}
+{\"command\":\"get\",\"note\":\"from s3-PUBLIC...\nchecksum...\",\"success\":true,\"key\":\"MD5E-s19875519--1a412c009b3d247b95f774b9099d55a8.nii.gz\",\"file\":\"sub-01/func/sub-01_task-letter0backtask_bold.nii.gz\"}
+git-annex: get: 3 failed
+try again
+get sub-01/func/sub-01_task-letter1backtask_bold.nii.gz (from s3-PUBLIC...) 
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+get sub-01/func/sub-01_task-letter2backtask_bold.nii.gz (from s3-PUBLIC...) 
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+get sub-01/anat/sub-01_T1w.nii.gz (from s3-PUBLIC...) 
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+(checksum...) ok
+(recording state in git...)
+( sudo rm -rf tmpds && git clone  tmpds && builtin cd tmpds && git annex   &&}  12.89s user 6.48s system 17% cpu 1:48.24 total
+(dev3) 1 30089.....................................:Wed 26 Feb 2020 12:23:12 PM EST:.
+lena:/tmp
+$> git annex version
+git-annex version: 7.20200204+git62-gcc4521068-1~ndall+1
+
+```
+</details>
+
+or 7.20190819+git2-g908476a9b-1~ndall+1 as well.  So it seems to boil down to slow(er) networking causing annex too quickly give up.
+
+<details>
+<summary>Running get with --debug shows only a single Request being sent</summary> 
+
+```shell
+lena:/tmp
+$> ( sudo rm -rf tmpds && git clone https://github.com/OpenNeuroDatasets/ds000115.git tmpds && builtin cd tmpds && git annex enableremote s3-PUBLIC && git annex get --debug -J 8 --json sub-01 ; ) 
+Cloning into 'tmpds'...
+remote: Enumerating objects: 4222, done.
+remote: Counting objects: 100% (4222/4222), done.
+remote: Compressing objects: 100% (2921/2921), done.
+remote: Total 4222 (delta 259), reused 4222 (delta 259), pack-reused 0
+Receiving objects: 100% (4222/4222), 389.19 KiB | 935.00 KiB/s, done.
+Resolving deltas: 100% (259/259), done.
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+enableremote s3-PUBLIC ok
+(recording state in git...)
+[2020-02-26 12:26:19.646897501] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2020-02-26 12:26:19.655216807] process done ExitSuccess
+[2020-02-26 12:26:19.655320586] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2020-02-26 12:26:19.658449065] process done ExitSuccess
+[2020-02-26 12:26:19.658605031] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..9088cb243b450cddf9d0efc28f7f4ae057ffad23\",\"--pretty=%H\",\"-n1\"]
+[2020-02-26 12:26:19.662572852] process done ExitSuccess
+[2020-02-26 12:26:19.664852493] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2020-02-26 12:26:19.668114175] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2020-02-26 12:26:19.67758125] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2020-02-26 12:26:19.684929526] process done ExitSuccess
+[2020-02-26 12:26:19.685314107] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2020-02-26 12:26:19.69392093] process done ExitSuccess
+[2020-02-26 12:26:19.69430796] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"sub-01\"]
+[2020-02-26 12:26:19.700836327] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2020-02-26 12:26:19.700836297] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2020-02-26 12:26:19.701069494] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2020-02-26 12:26:19.701090289] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2020-02-26 12:26:19.702350099] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2020-02-26 12:26:19.702739318] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2020-02-26 12:26:19.703280813] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2020-02-26 12:26:19.703705127] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  Remote is configured to use versioning, but no S3 version ID is recorded for this key
+  unknown export location
+  unknown export location
+  unknown export location
+[2020-02-26 12:26:19.758474799] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"diff-tree\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"-r\",\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\",\"9b2dd0df25c9725a5a999d86746cf34d58942a0d\",\"--\"]
+{\"command\":\"get\",\"wanted\":[{\"here\":false,\"uuid\":\"3970e64d-b24a-48e7-83b4-1ec6fdaa229d\",\"description\":\"[s3-PUBLIC]\"},{\"here\":false,\"uuid\":\"4a13d847-362b-4211-9124-861b9a8f4c13\",\"description\":\"root@6dedfdc60b41:/datalad/ds000115\"}],\"note\":\"from s3-PUBLIC...\nUnable to access these remotes: s3-PUBLIC\nTry making some of these repositories available:\n\t3970e64d-b24a-48e7-83b4-1ec6fdaa229d -- [s3-PUBLIC]\n \t4a13d847-362b-4211-9124-861b9a8f4c13 -- root@6dedfdc60b41:/datalad/ds000115\n\n(Note that these git remotes have annex-ignore set: origin)\",\"skipped\":[],\"success\":false,\"key\":\"MD5E-s19916325--b0bc24ff278e3ef7031e6c801fc6c694.nii.gz\",\"file\":\"sub-01/func/sub-01_task-letter2backtask_bold.nii.gz\"}
+{\"command\":\"get\",\"wanted\":[{\"here\":false,\"uuid\":\"3970e64d-b24a-48e7-83b4-1ec6fdaa229d\",\"description\":\"[s3-PUBLIC]\"},{\"here\":false,\"uuid\":\"4a13d847-362b-4211-9124-861b9a8f4c13\",\"description\":\"root@6dedfdc60b41:/datalad/ds000115\"}],\"note\":\"from s3-PUBLIC...\nUnable to access these remotes: s3-PUBLIC\nTry making some of these repositories available:\n\t3970e64d-b24a-48e7-83b4-1ec6fdaa229d -- [s3-PUBLIC]\n \t4a13d847-362b-4211-9124-861b9a8f4c13 -- root@6dedfdc60b41:/datalad/ds000115\n\n(Note that these git remotes have annex-ignore set: origin)\",\"skipped\":[],\"success\":false,\"key\":\"MD5E-s19915954--e9f91cc343144c541ca35831c62e9503.nii.gz\",\"file\":\"sub-01/func/sub-01_task-letter1backtask_bold.nii.gz\"}
+{\"command\":\"get\",\"wanted\":[{\"here\":false,\"uuid\":\"3970e64d-b24a-48e7-83b4-1ec6fdaa229d\",\"description\":\"[s3-PUBLIC]\"},{\"here\":false,\"uuid\":\"4a13d847-362b-4211-9124-861b9a8f4c13\",\"description\":\"root@6dedfdc60b41:/datalad/ds000115\"}],\"note\":\"from s3-PUBLIC...\nUnable to access these remotes: s3-PUBLIC\nTry making some of these repositories available:\n\t3970e64d-b24a-48e7-83b4-1ec6fdaa229d -- [s3-PUBLIC]\n \t4a13d847-362b-4211-9124-861b9a8f4c13 -- root@6dedfdc60b41:/datalad/ds000115\n\n(Note that these git remotes have annex-ignore set: origin)\",\"skipped\":[],\"success\":false,\"key\":\"MD5E-s35278866--09ae0c4f8a8eb6d379104e9ab9ca577a.nii.gz\",\"file\":\"sub-01/anat/sub-01_T1w.nii.gz\"}
+[2020-02-26 12:26:19.766878604] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2020-02-26 12:26:19.767158129] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2020-02-26 12:26:19.851709223] process done ExitSuccess
+[2020-02-26 12:26:19.947314114] Request {
+  host                 = \"openneuro.org.s3.amazonaws.com\"
+  port                 = 80
+  secure               = False
+  requestHeaders       = [(\"Accept-Encoding\",\"identity\"),(\"User-Agent\",\"git-annex/7.20190819+git2-g908476a9b-1~ndall+1\")]
+  path                 = \"/ds000115/sub-01/func/sub-01_task-letter0backtask_bold.nii.gz\"
+  queryString          = \"\"
+  method               = \"GET\"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+}
+
+
+
+Comment from Yarik:  WAITING here  FOR SECONDS for any output
+
+
+{\"command\":\"get\",\"note\":\"from s3-PUBLIC...\nchecksum...\",\"success\":true,\"key\":\"MD5E-s19875519--1a412c009b3d247b95f774b9099d55a8.nii.gz\",\"file\":\"sub-01/func/sub-01_task-letter0backtask_bold.nii.gz\"}
+[2020-02-26 12:26:37.921920147] process done ExitSuccess
+[2020-02-26 12:26:37.922115361] process done ExitSuccess
+[2020-02-26 12:26:37.922365844] process done ExitSuccess
+[2020-02-26 12:26:37.922600701] process done ExitSuccess
+[2020-02-26 12:26:37.922863082] process done ExitSuccess
+[2020-02-26 12:26:37.923112144] process done ExitSuccess
+[2020-02-26 12:26:37.923365928] process done ExitSuccess
+[2020-02-26 12:26:37.923571279] process done ExitSuccess
+[2020-02-26 12:26:37.923756395] process done ExitSuccess
+[2020-02-26 12:26:37.923937489] process done ExitSuccess
+[2020-02-26 12:26:37.92408496] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2020-02-26 12:26:37.924519626] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+[2020-02-26 12:26:37.928315529] process done ExitSuccess
+[2020-02-26 12:26:37.92837579] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2020-02-26 12:26:37.931065243] process done ExitSuccess
+[2020-02-26 12:26:37.931117591] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2020-02-26 12:26:37.935370176] process done ExitSuccess
+[2020-02-26 12:26:37.935408603] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"e7455c411db4691a4ba0571fa0f6c804ad7dfc2c\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"]
+[2020-02-26 12:26:37.938230054] process done ExitSuccess
+[2020-02-26 12:26:37.938266402] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"4c1269e4de04001766e6dcf0373b726409f4f4df\"]
+[2020-02-26 12:26:37.940995248] process done ExitSuccess
+[2020-02-26 12:26:37.941574513] process done ExitSuccess
+[2020-02-26 12:26:37.941834172] process done ExitSuccess
+[2020-02-26 12:26:37.942081282] process done ExitSuccess
+git-annex: get: 3 failed
+
+$> git annex version
+git-annex version: 7.20190819+git2-g908476a9b-1~ndall+1
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+
+```
+</details>
+
+and adding ` -c annex.retry=2` seems to be sufficient to workaround the issue and then `get` works for me even on the laptop. 
+"""]]
diff --git a/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_3_1fd43cf6dd14f50ef8087f0b22ad640f._comment b/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_3_1fd43cf6dd14f50ef8087f0b22ad640f._comment
new file mode 100644
index 0000000000..d6b29ca041
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_3_1fd43cf6dd14f50ef8087f0b22ad640f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2020-02-26T17:42:51Z"
+ content="""
+correction:  I found that on that fast(er) server I did have `annex.retry 3` set at the user level `~/.gitconfig`, that is why I didn't experience it (disadvantage of all the workaround customizations, heh heh).  Removing that setting, reproduces it on the fast box as well, so doesn't have much to do with network speed etc
+"""]]
diff --git a/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_4_4a4d5b62af4a42ab9072ccaa6d8bed7d._comment b/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_4_4a4d5b62af4a42ab9072ccaa6d8bed7d._comment
new file mode 100644
index 0000000000..a1e27d03d6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_4_4a4d5b62af4a42ab9072ccaa6d8bed7d._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-02-26T18:22:46Z"
+ content="""
+How do I produce such a repo, I thought that git-annex has fixed the 
+problem that made it not include the S3 versioning information?
+I don't want to see a lot of repos being created with that information
+missing.
+
+----
+
+Anyway, the S3 version is is a red herring, the failure is actually
+caused by the export db not getting populated from the git-annex branch
+before some threads try to use it. Remote.Helper.ExportImport has a
+updateexportdb that lets one thread update the db, but other threads
+don't block waiting for it. Easily fixed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_5_6c1e74df4c7e566c4c1ba43fbbbd3beb._comment b/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_5_6c1e74df4c7e566c4c1ba43fbbbd3beb._comment
new file mode 100644
index 0000000000..11704aa75f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fails_to___96__get__96___in_parallel_for_a_freshly_clone_from_public_s3_bucket_where_versioning_info_was_forgotten/comment_5_6c1e74df4c7e566c4c1ba43fbbbd3beb._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2020-02-26T20:58:16Z"
+ content="""
+> How do I produce such a repo, I thought that git-annex has fixed the problem that made it not include the S3 versioning information? I don't want to see a lot of repos being created with that information missing.
+
+Sorry if I was not clear.  Those repositories were produced in 2018 when available/used version of git annex was not yet \"fixed\".  Newer datasets, have .rmet files, e.g. just checked https://github.com/OpenNeuroDatasets/ds002596 (full of .rmet files in git-annex branch ;))
+
+>  Easily fixed.
+
+Thanks. FTR in 7.20200219-129-ge52034150
+"""]]
diff --git a/doc/projects/datalad/bugs-done/fails_to_verify_presence_via_http_while_wget_fetches_it_just_fine.mdwn b/doc/projects/datalad/bugs-done/fails_to_verify_presence_via_http_while_wget_fetches_it_just_fine.mdwn
new file mode 100644
index 0000000000..6b89bc842b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fails_to_verify_presence_via_http_while_wget_fetches_it_just_fine.mdwn
@@ -0,0 +1,52 @@
+### Please describe the problem.
+
+Fails to addurl --fast (there is additional problem there anyways since size is not provided by the server -- generated on the fly), but more important that refuses to drop even when addurl/wget fetch it just fine (although different one each time ATM -- probably time stamp within zip etc)
+
+### What steps will reproduce the problem?
+
+just try that url in the pasted output below
+
+### What version of git-annex are you using? On what operating system?
+6.20170525+gitge1cf095ae-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+$> git annex whereis mriqcresults.zip 
+whereis mriqcresults.zip (2 copies)  
+  	00000000-0000-0000-0000-000000000001 -- web
+   	8da1dc60-6c81-4bdc-91f6-90f15368797c -- yoh@hopa:/tmp/test [here]
+
+  web: https://openneuro.org/crn/jobs/594d42a090c6d1000180660b/results/fileName?ticket=ticket
+ok
+2 31497.....................................:Wed 26 Jul 2017 03:08:00 PM EDT:.
+hopa:/tmp/test
+$> git annex drop --debug mriqcresults.zip
+[2017-07-26 15:08:11.696997009] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","mriqcresults.zip"]
+[2017-07-26 15:08:11.700695374] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+[2017-07-26 15:08:11.700910913] read: git ["--version"]
+[2017-07-26 15:08:11.705537628] process done ExitSuccess
+[2017-07-26 15:08:11.705930374] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2017-07-26 15:08:11.709905527] process done ExitSuccess
+[2017-07-26 15:08:11.709986403] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2017-07-26 15:08:11.713535966] process done ExitSuccess
+[2017-07-26 15:08:11.714440039] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2017-07-26 15:08:11.714790464] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+drop mriqcresults.zip (checking https://openneuro.org/crn/jobs/594d42a090c6d1000180660b/results/fileName?ticket=ticket...) (unsafe) 
+  Could only verify the existence of 0 out of 1 necessary copies
+
+  Rather than dropping this file, try using: git annex move
+
+  (Use --force to override this check, or adjust numcopies.)
+failed
+git-annex: drop: 1 failed
+
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/fails_to_verify_presence_via_http_while_wget_fetches_it_just_fine/comment_1_fa6649208f1882a6bb412ba40cf57fec._comment b/doc/projects/datalad/bugs-done/fails_to_verify_presence_via_http_while_wget_fetches_it_just_fine/comment_1_fa6649208f1882a6bb412ba40cf57fec._comment
new file mode 100644
index 0000000000..ed23e8902b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fails_to_verify_presence_via_http_while_wget_fetches_it_just_fine/comment_1_fa6649208f1882a6bb412ba40cf57fec._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-15T17:28:20Z"
+ content="""
+The normal reason for this to happen is if the size of the file
+on the website has changed. git-annex checks the reported size and if it
+differs from the versioned file, it knows that the website no longer
+contains the same file.
+
+In this case, it seems to be a cgi program generating a zip file, and the
+program actually generated two different zip files when I hit it twice with
+wget. (So if git-annex actually did drop the only copy of the version you
+downloaded, you'd not be able to download it again. Not that git-annex can know
+that; this kind of thing is why trusting the web is not a good idea..) They did
+have the same size, but it looks like the web server is not sending a size
+header anyway.
+
+The actual problem is the web server takes a long time to answer a HEAD request
+for this URL. It takes 35 seconds before curl is able to HEAD it. I suspect
+it's generating the 300 mb zip file before it gets around to finishing
+the HEAD request. Not the greatest server behavior, all around.
+
+That breaks http-client due to its default 30 second timeout. So, will remove that timeout then.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/find_--batch_reports_files_that_have_no_content.mdwn b/doc/projects/datalad/bugs-done/find_--batch_reports_files_that_have_no_content.mdwn
new file mode 100644
index 0000000000..8a56afc0d0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/find_--batch_reports_files_that_have_no_content.mdwn
@@ -0,0 +1,68 @@
+As of 75aab72d2 (mostly done with location log precaching,
+2020-07-13), feeding `git annex find --batch` (no matching options)
+the name of a file whose content is not present locally outputs its
+name rather than an empty string.
+
+[[!format sh """
+cd "$(mktemp -d ${TMPDIR:-/tmp}/-XXXXXXX)"
+git init
+git annex init
+echo . >f1
+echo .. >f2
+git annex add f1 f2
+git commit -mfiles
+git annex drop --force f1
+echo "--- find, no batch"
+git annex find f1 f2
+echo "--- find, batch"
+echo "f1\nf2" | git annex find --batch
+git annex version
+"""]]
+
+Here's the output on the current tip of master (77299ae6e):
+
+```
+[...]
+--- find, no batch
+f2
+--- find, batch
+f1
+f2
+git-annex version: 8.20200618-g77299ae6e
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify TorrentParser Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.4 feed-1.2.0.1 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+```
+
+And here's the expected output on the parent of 75aab72d2:
+
+```
+[...]
+--- find, no batch
+f2
+--- find, batch
+
+f2
+git-annex version: 8.20200618-gdf5860980
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify TorrentParser Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.4 feed-1.2.0.1 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+```
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]], and audited for any other similar reversions.
+> 
+> Unfortunately did not see this bug before the release,
+> so I should make a point release for it. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked.mdwn b/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked.mdwn
new file mode 100644
index 0000000000..0d4e1cadbd
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked.mdwn
@@ -0,0 +1,84 @@
+If I'm not mistaken, the `--locked` and `--unlocked` limiting options
+are intended to work with `find --branch`, but that leads to empty
+output in all the cases I've tried.
+
+[[!format sh """
+set -eu
+
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/gx-XXXXXXX)"
+git init
+git annex init
+
+git commit --allow-empty -mc0
+echo a >on-master-locked
+echo b >on-master-unlocked
+git annex add on-master-locked on-master-unlocked
+git annex unlock on-master-unlocked
+git commit -mc1
+
+git checkout -b other HEAD~
+echo c >on-other-locked
+echo d >on-other-unlocked
+git annex add on-other-locked on-other-unlocked
+git annex unlock on-other-unlocked
+git commit -mc2
+
+export PS4='$ '
+set -x
+
+git symbolic-ref --short HEAD
+git annex find
+git annex find --locked
+git annex find --unlocked
+
+git checkout -
+
+git annex find
+git annex find --locked
+git annex find --unlocked
+
+git annex find --branch=other
+git annex find --branch=other --locked
+git annex find --branch=other --unlocked
+"""]]
+
+```
+[...]
+29	$ git symbolic-ref --short HEAD
+30	other
+31	$ git annex find
+32	on-other-locked
+33	on-other-unlocked
+34	$ git annex find --locked
+35	on-other-locked
+36	$ git annex find --unlocked
+37	on-other-unlocked
+38	$ git checkout -
+39	Switched to branch 'master'
+40	$ git annex find
+41	on-master-locked
+42	on-master-unlocked
+43	$ git annex find --locked
+44	on-master-locked
+45	$ git annex find --unlocked
+46	on-master-unlocked
+47	$ git annex find --branch=other
+48	on-other-locked
+49	on-other-unlocked
+50	$ git annex find --branch=other --locked
+51	$ git annex find --branch=other --unlocked
+```
+
+Lines 29-49 show the output I expected.  On the other hand, I thought
+the last two lines, which combine --branch with --locked and
+--unlocked, would show the same output as lines 35 and 37.
+
+I dug a bit hoping I could figure out what was going on, but I haven't
+had any luck so far.
+
+Thanks in advance.
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_1_d0dcd56a0af59bb53092c518a4e3eefd._comment b/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_1_d0dcd56a0af59bb53092c518a4e3eefd._comment
new file mode 100644
index 0000000000..13fc0e3374
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_1_d0dcd56a0af59bb53092c518a4e3eefd._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-01T17:10:45Z"
+ content="""
+The problem is that withKeyOptions' runbranchkeys finds keys,
+and matchLockStatus with a MatchingKey is always False. The former would
+need to check if the file in the branch is unlocked or not and add that to
+the data for use by the latter.
+
+Looks like it can be done without adding any additional overhead,
+but currently catKey reads the git ref and uses parseLinkTargetOrPointer
+which handles both indiscriminitely, so that would also need to be changed.
+
+This goes beyond find, the same basic problem is that
+`git-annex whereis --unlocked --all` does not display anything,
+while without the --unlocked it does. Probably it should not be allowed
+to combine --unlocked and --locked with --all or --key, because that does
+not actually make any sense. Also --all with
+--include/--exclude/--want-get/--want-drop/--mimetype/--mimeencoding.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_2_3f1980c96f795c30886b3decba69819d._comment b/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_2_3f1980c96f795c30886b3decba69819d._comment
new file mode 100644
index 0000000000..5a10b2d539
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_2_3f1980c96f795c30886b3decba69819d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-03-01T19:50:36Z"
+ content="""
+I've guarded against all the other bad combos mentioned. 
+
+find --branch --unlocked/--locked will be rejected now due to that change,
+but can be implemented later the way I discussed above.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_3_5299bafc9ae75788d2e7e9aa7f48d00e._comment b/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_3_5299bafc9ae75788d2e7e9aa7f48d00e._comment
new file mode 100644
index 0000000000..2b2e7b804e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_3_5299bafc9ae75788d2e7e9aa7f48d00e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="thanks"
+ date="2021-03-02T20:51:52Z"
+ content="""
+Great, thank you!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_3_b68abf3a46bf0137c02e439c58ce0014._comment b/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_3_b68abf3a46bf0137c02e439c58ce0014._comment
new file mode 100644
index 0000000000..0d19fde168
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/find_--branch__58___no_results_with_--__123__un__44____125__locked/comment_3_b68abf3a46bf0137c02e439c58ce0014._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-03-02T17:40:57Z"
+ content="""
+Ah yes, it's using git ls-tree so it can just check if the mode is that of
+a symlink or a file to tell if it's unlocked, so no need to mess with
+catKey.
+
+Ok, got --branch combined --unlocked/--locked working! Also in whereis and
+whatever other commands support --branch.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/fresh_test_fails_for___34__trust__58____34___-_trust_failed_.mdwn b/doc/projects/datalad/bugs-done/fresh_test_fails_for___34__trust__58____34___-_trust_failed_.mdwn
new file mode 100644
index 0000000000..add6c98dff
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fresh_test_fails_for___34__trust__58____34___-_trust_failed_.mdwn
@@ -0,0 +1,17 @@
+### Please describe the problem.
+
+Started to happen with today's build of annex for  8.20201129+git80-g1e65d1b9a-1~ndall+1 and was ok for  8.20201129+git73-g0e10402ef-1~ndall+1
+
+```
+    trust:                                                FAIL (0.28s)
+      ./Test/Framework.hs:57:
+      trust failed (transcript follows)
+      trust origin git-annex: Trusting a repository can lead to data loss.If you're sure you know what you're doing, use --force tomake this take effect.If you choose to do so, bear in mind that any time you dropcontent from origin, you will risk losing data.failedgit-annex: trust: 1 failed
+```
+
+with 6 of similar fails. See e.g. [https://github.com/datalad/git-annex/runs/1666536034?check_suite_focus=true](https://github.com/datalad/git-annex/runs/1666536034?check_suite_focus=true) for more detail
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] earlier today --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/fromkey__58___create_directories_for_pointer_files__63__.mdwn b/doc/projects/datalad/bugs-done/fromkey__58___create_directories_for_pointer_files__63__.mdwn
new file mode 100644
index 0000000000..dc3a70c7fb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fromkey__58___create_directories_for_pointer_files__63__.mdwn
@@ -0,0 +1,96 @@
+Thanks for extending `fromkey` to support for unlocked files.  When
+updating some DataLad code to make use of this, a test flagged a
+difference between how links and pointer files are handled: the
+necessary leading directories will be created for links but not
+pointer files.
+
+[[!format sh """
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/ga-XXXXXXX)" || exit 1
+
+git version
+git annex version | head -1
+
+git init -q
+git annex init
+
+set -x
+
+git annex fromkey --force \
+    SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c \
+    foo/a
+git cat-file -p :foo/a
+
+git config annex.addunlocked true
+git annex fromkey --force \
+    SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730 \
+    bar/a
+"""]]
+
+```
+git version 2.31.1.705.g1ce651569c
+git-annex version: 8.20210429-gdab203070
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
++ git annex fromkey --force SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c foo/a
+fromkey foo/a ok
+(recording state in git...)
++ git cat-file -p :foo/a
+../.git/annex/objects/91/9x/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c+ git config annex.addunlocked true
++ git annex fromkey --force SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730 bar/a
+fromkey bar/a
+git-annex: bar/a: openBinaryFile: does not exist (No such file or directory)
+failed
+(recording state in git...)
+git-annex: fromkey: 1 failed
+```
+
+The caller can of course make sure that leading directories exist, but
+I think it makes sense for the locked and unlocked variants to behave
+the same here.  What do you think about the patch below?
+
+[[!format patch """
+From f6c97b8d01c7e9b8069638e9827062aa2462d429 Mon Sep 17 00:00:00 2001
+From: Kyle Meyer <kyle@kyleam.com>
+Date: Thu, 6 May 2021 11:11:14 -0400
+Subject: [PATCH] fromkey: create directory for pointer files too
+
+fromkey creates leading directories for symbolic links.  Do the same
+for pointer files.
+---
+ Command/FromKey.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Command/FromKey.hs b/Command/FromKey.hs
+index eadb89fd1..16ff1693f 100644
+--- a/Command/FromKey.hs
++++ b/Command/FromKey.hs
+@@ -106,6 +106,7 @@ perform matcher key file = lookupKeyNotHidden file >>= \case
+ 					, matchKey = Just key
+ 					}
+ 				else keyMatchInfoWithoutContent key file
++			createWorkTreeDirectory (parentDir file)
+ 			ifM (addUnlocked matcher mi contentpresent)
+ 				( do
+ 					stagePointerFile file Nothing =<< hashPointerFile key
+@@ -115,7 +116,6 @@ perform matcher key file = lookupKeyNotHidden file >>= \case
+ 						else writepointer
+ 				, do
+ 					link <- calcRepo $ gitAnnexLink file key
+-					createWorkTreeDirectory (parentDir file)
+ 					addAnnexLink link file
+ 				)
+ 			next $ return True
+
+base-commit: dab2030702200bc9abea4bff9ce83ba63aeca41c
+-- 
+2.31.1.705.g1ce651569c
+
+"""]]
+
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> Thanks for the patch, applied
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly.mdwn b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly.mdwn
new file mode 100644
index 0000000000..9f260d1711
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly.mdwn
@@ -0,0 +1,46 @@
+### Please describe the problem.
+
+ATM I am chasing a problem that somehow one key "mutated" although I do not remember doing anything malicious, file seems to be also not  writable (itself).
+So I decided to fsck, and only spotted a problem when some warnings started to appear that I am not the owner of the (key)file.  So I looked inside and found
+that all key dirs are writeable BUT annex complains only about the ones where it can't change permissions since they don't belong to me
+
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170815+gitg22da64d0f-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> for f in sub00{1,3}/anatomy/highres001.nii.gz; do ls -ld $(realpath $f | xargs dirname ); git annex fsck $f; done 
+drwxrws--- 2 yoh famface 3 May 12 15:15 /data/famface/openfmri/data/.git/annex/objects/08/V3/SHA256E-s6498717--b850ac82ec9db2d399962609e9381d9c2bdf1f426012500b7005b173ea4d9102.nii.gz/
+fsck sub001/anatomy/highres001.nii.gz (checksum...) ok
+(recording state in git...)
+drwxrwsr-x 2 contematto famface 3 Jul 13  2015 /data/famface/openfmri/data/.git/annex/objects/x2/xX/SHA256E-s6592524--dccba651dc4cd104826a05a2efb6a257b39ca2d8b44d215027250221729f9434.nii.gz/
+fsck sub003/anatomy/highres001.nii.gz 
+  ** Unable to set correct write mode for .git/annex/objects/x2/xX/SHA256E-s6592524--dccba651dc4cd104826a05a2efb6a257b39ca2d8b44d215027250221729f9434.nii.gz/SHA256E-s6592524--dccba651dc4cd104826a05a2efb6a257b39ca2d8b44d215027250221729f9434.nii.gz ; perhaps you don't own that file
+(checksum...) ok
+(recording state in git...)
+
+# thought to see may be annex would complain then!?
+$> chmod a+rwx /data/famface/openfmri/data/.git/annex/objects/08/V3/SHA256E-s6498717--b850ac82ec9db2d399962609e9381d9c2bdf1f426012500b7005b173ea4d9102.nii.gz/
+
+$> for f in sub00{1,3}/anatomy/highres001.nii.gz; do ls -ld $(realpath $f | xargs dirname ); git annex fsck $f; done                                          
+drwxrwsrwx 2 yoh famface 3 May 12 15:15 /data/famface/openfmri/data/.git/annex/objects/08/V3/SHA256E-s6498717--b850ac82ec9db2d399962609e9381d9c2bdf1f426012500b7005b173ea4d9102.nii.gz/
+fsck sub001/anatomy/highres001.nii.gz (checksum...) ok
+(recording state in git...)
+drwxrwsr-x 2 contematto famface 3 Jul 13  2015 /data/famface/openfmri/data/.git/annex/objects/x2/xX/SHA256E-s6592524--dccba651dc4cd104826a05a2efb6a257b39ca2d8b44d215027250221729f9434.nii.gz/
+fsck sub003/anatomy/highres001.nii.gz 
+  ** Unable to set correct write mode for .git/annex/objects/x2/xX/SHA256E-s6592524--dccba651dc4cd104826a05a2efb6a257b39ca2d8b44d215027250221729f9434.nii.gz/SHA256E-s6592524--dccba651dc4cd104826a05a2efb6a257b39ca2d8b44d215027250221729f9434.nii.gz ; perhaps you don't own that file
+(checksum...) ok
+(recording state in git...)
+
+"""]]
+
+~~btw -- the same wrong permissions on the upper hash directories, and they do not get fixed/complained about at all (that is ok)~~
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[closing|done]], see my comments --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_1_1d627cb46d9ecdf0b526a9c8e9764011._comment b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_1_1d627cb46d9ecdf0b526a9c8e9764011._comment
new file mode 100644
index 0000000000..92fbb3ba59
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_1_1d627cb46d9ecdf0b526a9c8e9764011._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2017-09-13T14:32:57Z"
+ content="""
+also note, that even though I am not the owner, I should have sufficient privileges to modify (member of the group(s))!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_2_eb7c6445b1ca53d5552506d8ae93b5d4._comment b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_2_eb7c6445b1ca53d5552506d8ae93b5d4._comment
new file mode 100644
index 0000000000..5d708f871d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_2_eb7c6445b1ca53d5552506d8ae93b5d4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-09-13T16:12:22Z"
+ content="""
+I think you must have core.sharedRepository set to group or all or
+something like that, otherwise fsck never complains about modes.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_3_c7d43b06f88d2000fcf574ebab971ae1._comment b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_3_c7d43b06f88d2000fcf574ebab971ae1._comment
new file mode 100644
index 0000000000..162052573b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_3_c7d43b06f88d2000fcf574ebab971ae1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2017-09-13T17:58:54Z"
+ content="""
+yeap -- sharedrepository=1 I have.  should be legit right?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_4_9d7c83cfb6154bdfc51caae00da4c4b7._comment b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_4_9d7c83cfb6154bdfc51caae00da4c4b7._comment
new file mode 100644
index 0000000000..af7840112e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_4_9d7c83cfb6154bdfc51caae00da4c4b7._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-10-02T20:07:23Z"
+ content="""
+In general, it's out of scope for fsck to make file permission sane,
+because "sane" has a fairly broad set of definitions when it comes
+to file permissions!
+
+See [[!commit bd516af734bf5e1f7a3d43c7e4dd0f6fb9fd5919]] for the
+backstory about why fsck wants to fix this one particular permission.
+In short, old versions of git-annex didn't set the write bit of content files
+in a shared repo, which prevented git-annex from locking the content
+files, which prevents dropping them or locking them to prevent removal
+while dropping them from another repo. So fsck is fixing up from that
+situation.
+
+With core.sharedrepository=1, isContentWritePermOk 
+wants owner and group write bits to be set on the content file.
+
+I can reproduce what seems to be the same problem as follows:
+
+	drwxrwxr-x 2 root netdev 4096 Oct  2 16:20 .git/annex/objects/2K/7F/SHA256E-s30--0d18b66aa72aeecad450963ec8f8951f4f5d27fc965d56bdfd3ff75e6d42ea3e/
+	-rw-r--r-- 1 root netdev 30 Oct  2 16:20 .git/annex/objects/2K/7F/SHA256E-s30--0d18b66aa72aeecad450963ec8f8951f4f5d27fc965d56bdfd3ff75e6d42ea3e/SHA256E-s30--0d18b66aa72aeecad450963ec8f8951f4f5d27fc965d56bdfd3ff75e6d42ea3e
+
+When I fsck as user joey, who is in group netdev, it complains it can't
+fix the permissions.
+
+While joey has write access to the directory containing
+the content file, this does not allow changing the permissions of the file.
+
+The directory perms do allow deleting the file and replacing it with a copy
+that has the permissions I want. But, that is an expensive operation, needing
+to copy a perhaps enormous file. So I don't think it's a reasonable thing for
+fsck to do.
+
+So, it seems to me that fsck complaining is ok.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_5_09bb754f4e7e19cd52d68f91368f57fc._comment b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_5_09bb754f4e7e19cd52d68f91368f57fc._comment
new file mode 100644
index 0000000000..8356dc2745
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_5_09bb754f4e7e19cd52d68f91368f57fc._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2017-12-05T18:26:43Z"
+ content="""
+FWIW regarding
+
+> But, that is an expensive operation, needing to copy a perhaps enormous file. So I don't think it's a reasonable thing for fsck to do.
+
+I prefer machines to do the job instead of me, even though they need to sweat may be more than I for some of those ;)  not sure if needs to be an option or default behavior. But altogether, I am trying to get away from shared mode (ref: http://git-annex.branchable.com/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/) with write permissions set on fiels since it is simply too dangerous if that repository is the single source of correct data/files.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_6_3cba6bde1e5c1e978519672bf4c2d33f._comment b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_6_3cba6bde1e5c1e978519672bf4c2d33f._comment
new file mode 100644
index 0000000000..f735cd3f8d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/fsck_does_not_detect__47__fix_some_key_directories_correctly/comment_6_3cba6bde1e5c1e978519672bf4c2d33f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-05-28T16:03:01Z"
+ content="""
+Making fsck use additional disk space by making a copy of an annexed file
+in an obscure corner case is the kind of thing that results in complaints.
+It violates least surprise.
+
+The error message seems good.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_--json_fails_whenever_plain_get_works___40__with_https_urls__41__.mdwn b/doc/projects/datalad/bugs-done/get_--json_fails_whenever_plain_get_works___40__with_https_urls__41__.mdwn
new file mode 100644
index 0000000000..e86b7c1352
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_--json_fails_whenever_plain_get_works___40__with_https_urls__41__.mdwn
@@ -0,0 +1,55 @@
+### Please describe the problem.
+
+subject
+
+### What steps will reproduce the problem?
+
+repo from http://datasets.datalad.org/workshops/nih-2017/ds000114/derivatives/freesurfer/
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170525+gitge1cf095ae-1~ndall+1
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+[student3@helix freesurfer]$ 'git' '-c' 'receive.autogc=0' '-c' 'gc.auto=0' 'annex' 'get' '--debug' '--json' '--json-progress' 'sub-01/label/lh.aparc.a2009s.annot'
+[2017-07-30 09:33:42.479678681] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","sub-01/label/lh.aparc.a2009s.annot"]
+[2017-07-30 09:33:42.501443872] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2017-07-30 09:33:42.523673251] process done ExitSuccess
+[2017-07-30 09:33:42.523765181] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2017-07-30 09:33:42.544559473] process done ExitSuccess
+[2017-07-30 09:33:42.553475534] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2017-07-30 09:33:42.554641292] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2017-07-30 09:33:42.591306199] call: curl ["-sS","-f","-L","-C","-","-#","-o","/scratch/nih-2017/ds000114/derivatives/freesurfer/.git/annex/tmp/MD5E-s831572--7437ad482af573329af54386a15007fe","https://dl.dropbox.com/s/85yms1fl56pq7io/lh.aparc.a2009s.annot?dl=0","--user-agent","git-annex/6.20170525+gitge1cf095ae-1~ndall+1"]
+curl: (77) error setting certificate verify locations:
+  CAfile: /etc/ssl/certs/ca-certificates.crt
+  CApath: /etc/ssl/certs
+[2017-07-30 09:33:42.693467186] process done ExitFailure 77
+{"command":"get","wanted":[{"here":false,"uuid":"00000000-0000-0000-0000-000000000001","description":"web"},{"here":false,"uuid":"5e47b3f3-f09c-4969-8885-920a49ff8a45","description":"yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/workshops/nih-workshop-2017/ds000114/derivatives/freesurfer"}],"note":"Try making some of these repositories available:\n\t00000000-0000-0000-0000-000000000001 -- web\n \t5e47b3f3-f09c-4969-8885-920a49ff8a45 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/workshops/nih-workshop-2017/ds000114/derivatives/freesurfer\n","skipped":[],"success":false,"key":"MD5E-s831572--7437ad482af573329af54386a15007fe","file":"sub-01/label/lh.aparc.a2009s.annot"}
+git-annex: get: 1 failed
+[student3@helix freesurfer]$ 'git' '-c' 'receive.autogc=0' '-c' 'gc.auto=0' 'annex' 'get' '--json' '--json-progress' 'sub-01/label/lh.aparc.a2009s.annot'
+curl: (77) error setting certificate verify locations:
+  CAfile: /etc/ssl/certs/ca-certificates.crt
+  CApath: /etc/ssl/certs
+{"command":"get","wanted":[{"here":false,"uuid":"00000000-0000-0000-0000-000000000001","description":"web"},{"here":false,"uuid":"5e47b3f3-f09c-4969-8885-920a49ff8a45","description":"yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/workshops/nih-workshop-2017/ds000114/derivatives/freesurfer"}],"note":"Try making some of these repositories available:\n\t00000000-0000-0000-0000-000000000001 -- web\n \t5e47b3f3-f09c-4969-8885-920a49ff8a45 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/workshops/nih-workshop-2017/ds000114/derivatives/freesurfer\n","skipped":[],"success":false,"key":"MD5E-s831572--7437ad482af573329af54386a15007fe","file":"sub-01/label/lh.aparc.a2009s.annot"}
+git-annex: get: 1 failed
+                        
+while works fine without:
+                 
+[student3@helix freesurfer]$ 'git' '-c' 'receive.autogc=0' '-c' 'gc.auto=0' 'annex' 'get'  'sub-01/label/lh.aparc.a2009s.annot'
+get sub-01/label/lh.aparc.a2009s.annot (from web...)
+/scratch/nih-2017/ds000114/ 100%[===========================================>] 812.08K  --.-KB/s    in 0.08s
+2017-07-30 09:34:02 URL:https://dl.dropboxusercontent.com/s/85yms1fl56pq7io/lh.aparc.a2009s.annot?dl=0 [831572/831572] -> "/scratch/nih-2017/ds000114/derivatives/freesurfer/.git/annex/tmp/MD5E-s831572--7437ad482af573329af54386a15007fe" [1]  
+(checksum...) 
+(recording state in git...)
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> git-annex no longer uses either curl or wget by default, and always uses
+> curl when configured to do so, so this kind of surprising behavior will
+> no longer occur [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/get_--json_fails_whenever_plain_get_works___40__with_https_urls__41__/comment_1_a9aee679a5069dc8ee8960e975bf020b._comment b/doc/projects/datalad/bugs-done/get_--json_fails_whenever_plain_get_works___40__with_https_urls__41__/comment_1_a9aee679a5069dc8ee8960e975bf020b._comment
new file mode 100644
index 0000000000..22f1ad8c17
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_--json_fails_whenever_plain_get_works___40__with_https_urls__41__/comment_1_a9aee679a5069dc8ee8960e975bf020b._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-07-31T18:46:00Z"
+ content="""
+Using --json will have the same effect as --quiet in that commands have
+to be made to not output to stdout in that mode. In the case of
+downloading an url, git-annex usually uses wget, however when curl is
+available in path, it uses it in quiet mode, because curl displays error
+messages to stdout, whereas wget never displays error messages at all
+when run in quiet mode.
+
+So, by using --json, you're changing the command that git-annex uses to
+download files from wget to curl.
+
+But, the git-annex standalone build bundles both wget and curl, so
+I'd expect that any certificates problem would affect both equally.
+But I suppose wget may be better able to deal with the certs on this
+system than curl, for whatever reason.
+
+Bundling certs with git-annex seems wrong on multiple counts; it's
+moving a large security boundary inside git-annex; it's lots of work;
+there may be local policies on allowed certs that this would disallow.
+
+Suggestion: Remove curl from the standalone build you're using, so
+it will use the system-wide curl.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_--json_fails_whenever_plain_get_works___40__with_https_urls__41__/comment_2_f1e97aa8b9927c01e3365b940061d3c2._comment b/doc/projects/datalad/bugs-done/get_--json_fails_whenever_plain_get_works___40__with_https_urls__41__/comment_2_f1e97aa8b9927c01e3365b940061d3c2._comment
new file mode 100644
index 0000000000..e27a5fa6fc
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_--json_fails_whenever_plain_get_works___40__with_https_urls__41__/comment_2_f1e97aa8b9927c01e3365b940061d3c2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2017-07-31T19:05:04Z"
+ content="""
+There is no guarantee that system would have curl installed,  e.g. I believe neither of debian docker images would have curl.  For neurodebian package I sure thing could just depend on curl.  But I am afraid those who might be using standalone git-annex in minimalistic environments would get surprised
+
+FWIW -- removing curl from the bundled git-annex indeed helped
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist.mdwn b/doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist.mdwn
new file mode 100644
index 0000000000..758406251a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist.mdwn
@@ -0,0 +1,22 @@
+### Please describe the problem.
+
+happens while running `git annex get -J5 .` on http://datasets.datalad.org/labs/hasson/narratives/derivatives/fmriprep/.git
+
+filesystem is that NFS mounted lustre where I thought we resolved all the issues (spotted by `annex test`, yet to redo)
+
+the entire run has failed with `get: 128 failed`
+
+It is consistent. Tried in another dataset  http://datasets.datalad.org/labs/hasson/narratives/derivatives/freesurfer/.git/ and after one crashed run (kerberos key timeout, leading to other errors), started a new `annex get -J5` for which log in full is http://www.onerussian.com/tmp/annex-get-freesurfer-5.log and which ends with `get: 89 failed` 
+
+
+### What version of git-annex are you using? On what operating system?
+
+conda linux nodep (standalone) build 8.20211012-geb95ed486 and then with another standalone build (debian, extracted on that CentOS) 8.20211117+git14-ge1f38b9dd  
+
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] provisionally, followup if further testing shows otherwise
+> --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist/comment_1_83448258af56b5872a9530cf60c72eb0._comment b/doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist/comment_1_83448258af56b5872a9530cf60c72eb0._comment
new file mode 100644
index 0000000000..d86821d32b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist/comment_1_83448258af56b5872a9530cf60c72eb0._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-11-29T18:11:30Z"
+ content="""
+I think that this error comes from Utility.LockFile.PidLock.tryLock,
+which has the only getFileStatus involving the pidlock whose exceptions
+are not caught. The file is assumed to exist since it was just created,
+and normally nothing deletes it.
+
+While looking at where this might come from, I refreshed my memory of
+how Lustre can to do insane stuff like having 2 different files with the
+same name in a directory. Which checkInsaneLustre tries to deal with
+by deleting one of them, but since this is all behavior undefined by POSIX,
+maybe that sometimes deletes both of them. Or the file doesn't appear
+after being created for some other POSIX-defying reason.
+
+I've changed it to catch exceptions from that getFileStatus, which will
+test this theory.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist/comment_2_92dec3e0c31ffbef1a70ea3038ba6ca1._comment b/doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist/comment_2_92dec3e0c31ffbef1a70ea3038ba6ca1._comment
new file mode 100644
index 0000000000..ec448e5cc1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist/comment_2_92dec3e0c31ffbef1a70ea3038ba6ca1._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-01-11T16:16:51Z"
+ content="""
+Ping, can you try to reproduce this with a recent build?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist/comment_3_ab590b41983d84c8fe7d5dc7276689b8._comment b/doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist/comment_3_ab590b41983d84c8fe7d5dc7276689b8._comment
new file mode 100644
index 0000000000..2023ad7858
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J5___58___pidlock__58___getFileStatus__58___does_not_exist/comment_3_ab590b41983d84c8fe7d5dc7276689b8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2022-01-12T19:33:15Z"
+ content="""
+Still checking but so far looks good with `8.20211231+git69-ga55fc567c-1~ndall+1` -- thank you!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted.mdwn b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted.mdwn
new file mode 100644
index 0000000000..ad1a21c87e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted.mdwn
@@ -0,0 +1,54 @@
+### Please describe the problem.
+
+running `git annex get -J8` on OSX (git annex 8.20200226 installed via brew)
+
+  - distribution:  10.14.6/x86_64
+  - encoding:
+    - default: utf-8
+    - filesystem: utf-8
+    - locale.prefered: UTF-8
+  - max_path_length: 272
+  - name: Darwin
+  - release: 18.7.0
+  - type: posix
+  - version: Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64
+
+
+results in git annex failing to get some files with errors about too many open files:
+
+[[!format sh """
+get .datalad/metadata/objects/0b/cn-65a581e2e22f95210db4d750cbcd1c.xz (from origin...) (checksum...) ok
+get .datalad/metadata/objects/16/cn-020f8a40eed616291d855f13793e6e.xz (from origin...) (checksum...) ok
+get .datalad/metadata/objects/0e/ds-2e262d6ab40f1f0fa399e80866f732 (from origin...) (checksum...) ok
+get .datalad/metadata/objects/0f/cn-550a7aca2cc94645e63cda96476d40.xz
+git-annex: git: createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files)
+failed
+get .datalad/metadata/objects/0f/cn-3c0d085acbb8ea3af430f826828b69.xz (from origin...) (checksum...) ok
+get .datalad/metadata/objects/1d/ds-8e8fbd9d2834f108c7bd5ddb4294eb (from origin...) (checksum...) ok
+get .datalad/metadata/objects/0b/ds-cd8a472d84af1980703baca7ad4910 (from origin...) (checksum...) ok
+get .datalad/metadata/objects/1b/ds-9f695168fd28140c49a45523b9ce5f (from origin...) (checksum...) ok
+get .datalad/metadata/objects/21/ds-92598325890e1d079e1a0a8e4fd9df
+git-annex: git: createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files)
+failed
+get .datalad/metadata/objects/0f/ds-550a7aca2cc94645e63cda96476d40 (from origin...) (checksum...) ok
+get .datalad/metadata/objects/06/cn-2c3eade47bd2d9052658c6a9d10a57.xz (from origin...) (checksum...) ok
+get .datalad/metadata/objects/21/cn-92598325890e1d079e1a0a8e4fd9df.xz (from origin...) (checksum...) ok
+get .datalad/metadata/objects/1b/cn-f55a26461f99a8ac1dde6b618e3425.xz (from origin...) (checksum...)
+git-annex: .git/annex/othertmp.lck: openFd: resource exhausted (Too many open files)
+failed
+get .datalad/metadata/objects/26/ds-0ad917bee8d05db1dd27d0ad50c1bb
+git-annex: git: createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files)
+"""]]
+
+Full bundle of logs with a bit older (20191230) and this newer version, and full output of `datalad wtf` is available from [http://www.onerussian.com/tmp/git-annex-J8-logs.tar.gz](http://www.onerussian.com/tmp/git-annex-J8-logs.tar.gz).
+
+possibly related, but not yet marked done [issue I found is from 6 years ago](https://git-annex.branchable.com/bugs/Resource_exhausted/).
+
+I have tried to replicate this on some other OSX boxes a few weeks back but I have not reproduced it, so might be specific about this one.  FWIW `ulimit` reported "unlimited"
+
+I will try to get a chance to troubleshoot it more to provide possibly more details whenever I get access to it again.  Meanwhile just informing, and would welcome additional instructions on what to look at (besides adding `--debug` and running lsof in a loop in parallel) to troubleshoot it.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_10_61622483d4f1962f191fb6a791c6817d._comment b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_10_61622483d4f1962f191fb6a791c6817d._comment
new file mode 100644
index 0000000000..3a12fad787
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_10_61622483d4f1962f191fb6a791c6817d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2020-04-20T17:24:53Z"
+ content="""
+Implemented the cat-file pool. Capped at 2 cat-files of each distinct type,
+so it will start a max of 8 no matter the -J level.
+
+(Although cat-file can also be run in those repositories so there will be
+more then.)
+
+While testing, I noticed git-anenx drop -Jn starts n git check-attr
+processes, so the same thing ought to be done with them. Leaving this bug open
+for that, but I do think that the problem you reported should be fixed now.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_11_ccc6f5f1ac5743b0857f68cf21eaa6ea._comment b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_11_ccc6f5f1ac5743b0857f68cf21eaa6ea._comment
new file mode 100644
index 0000000000..f20f97afb3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_11_ccc6f5f1ac5743b0857f68cf21eaa6ea._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2020-04-21T15:23:57Z"
+ content="""
+check-attr and check-ignore also converted to resource pools
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_1_5f9e9600d65c1270b479cc8910d507d0._comment b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_1_5f9e9600d65c1270b479cc8910d507d0._comment
new file mode 100644
index 0000000000..7bdde7d8e0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_1_5f9e9600d65c1270b479cc8910d507d0._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-16T16:13:00Z"
+ content="""
+The obvious question to ask, which I can't really imagine making any
+progress without an answer to: What files did git-annex have open?
+
+I did notice that of the two git-annex logs, one got 19 files before
+failing, while the other got 27. It seems unlikely that, if git-annex, or
+an external remote, or git, or whatever is somehow leaking file handles,
+it would leak different numbers at different times. Which leads to the
+second question: What else on the system has files open and how many?
+
+OSX has a global limit of 12k open files, and a per process limit of 10k.
+
+`git-annex get` on linux needs to open around 16 files per file it
+downloads. So if git-annex were somehow leaking every single open FD,
+it would successfully download over 600 files before hitting the
+per-process limit. If every subprocess git-annex forks also leaked every
+open FD, it would of course vary by remote, but with a regular git clone
+on the local filesystem, the number of files opened per get is still only
+62, so still over an order of magnitude less.
+
+Seems much more likely that the system is unhappy for some other reason.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_2_54cf519a09cfaa0c85d60734daf58d72._comment b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_2_54cf519a09cfaa0c85d60734daf58d72._comment
new file mode 100644
index 0000000000..91f7a32c6b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_2_54cf519a09cfaa0c85d60734daf58d72._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="it is many more &quot;open files&quot; in reality"
+ date="2020-04-16T03:41:07Z"
+ content="""
+Michael has reported [a similar issue on Linux](https://github.com/datalad/datalad/issues/4404).  I was initially also \"skeptical\".  But the reason really is that each git-annex process takes HUNDREDS of open files (dynamic libraries etc), and parallel execution of `get` adds a good number of pipes on top (counted ~3000 for `get -J 8` process).  I thought to investigate more before reporting and then randomly ran into this not so old report from myself ;)
+
+A quick demo:
+[[!format sh \"\"\"
+$> echo BEFORE; lsof | grep annex | nl | tail -n 2; git clone http://datasets.datalad.org/allen-brain-observatory/visual-coding-neuropixels/ecephys-cache/.git && cd ecephys-cache && git annex get -J5 * >/dev/null & p=$! && sleep 3 && echo DURING && lsof | grep annex | nl | tail -n 2; kill %1 
+BEFORE
+Cloning into 'ecephys-cache'...
+remote: Counting objects: 5875, done.
+remote: Compressing objects: 100% (3046/3046), done.
+remote: Total 5875 (delta 2335), reused 4599 (delta 1424)
+Receiving objects: 100% (5875/5875), 73.55 MiB | 30.39 MiB/s, done.
+Resolving deltas: 100% (2335/2335), done.
+Checking out files: 100% (573/573), done.
+[1] 17335
+DURING
+  2242	git       17424               yoh   67w      REG                9,1 40018173     131020 /tmp/ecephys-cache/.git/annex/tmp/SHA512E-s665395296--8327d0715923b88a2b6b179d02a40acb1630e420a73a16a3422b6b245e9c0e57e21529919136492ab2c746256f99831200c36b7e071ea24f25abb37efc28de13.h5
+  2243	git       17424               yoh   68w      REG                9,1 67095741     131021 /tmp/ecephys-cache/.git/annex/tmp/SHA512E-s166348896--3bb739a0df1acd478eb84545a7c22c31933458fcd44ce211d4dd555bc979170bef11126064fed730e3b289d41999cc1c6fb0b6c35870bb996a4faa2e34a75403.h5
+\"\"\"]]
+so with `-J5` 3 seconds after initial call with `-J5` I get over 2k open files used by annex (according to grep, may be some managed to escape matching).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_3_132ea480f90af577e3cad67f2f01c73d._comment b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_3_132ea480f90af577e3cad67f2f01c73d._comment
new file mode 100644
index 0000000000..5684368249
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_3_132ea480f90af577e3cad67f2f01c73d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2020-04-16T03:43:13Z"
+ content="""
+Sorry, forgot to mention, I do not think I had spotted any file descriptor leaking.  The number of used up file descriptors (according to `lsof`) was fluctuating as process kept going but was not really steadily growing
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_4_06e99c29eaa770ab96ea5fd832ee04b8._comment b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_4_06e99c29eaa770ab96ea5fd832ee04b8._comment
new file mode 100644
index 0000000000..cce55a5fd6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_4_06e99c29eaa770ab96ea5fd832ee04b8._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-04-17T16:37:07Z"
+ content="""
+I'm seeing a lot of git cat-file processes, not a lot of any other process.
+
+Each -J increment adds 3 threads for the different command stages
+(start, perform, cleanup). Each thread might need a git cat-file
+run with either of two different parameters, and on either of two different
+index files. (Both are needed for unlocked files, only one for locked
+files.)
+
+So, 5x3x2x2=60 copies of git cat-file max for -J5.
+And experimentally, that's exactly how many I see in the worst case
+repo where all files are unlocked. (Plus 4 which I think are owned by
+the controlling thread or something). Using your test case, I am seeing 44.
+So I don't think there's a subprocess leak here.
+
+IIUC, what you show is lsof of things open by git-annex and any git processes
+that happen to open a file with "annex" in its name, being around 3000.
+
+Now, lsof is for one thing showing a file that two different threads have
+open, as being opened twice. 
+
+	git-annex 1459862 1459863 ghc_ticke       joey  mem       REG                8,1    169720    9175285 /lib/x86_64-linux-gnu/ld-2.30.so
+	git-annex 1459862 1459873 git-annex       joey  mem       REG                8,1    169720    9175285 /lib/x86_64-linux-gnu/ld-2.30.so
+
+That is different threads of the same process, that has certianly not
+opened ld.so repeatedly.
+
+So, you should be using `lsof -Ki` or something. With that, I see around
+1019 files open, between git-annex and git. git-annex by itself has only
+246.
+
+(Interestingly, the majority of those seem to be sqlite. I'm unsure
+why sqlite is opening the same database 30 times. A single thread often
+has the same database opened repeatedly. Might be that the sqlite database
+layer has a too large connection pool. There are also a lot of FIFO's,
+which I think also belong to sqlite, unless they're something internal to
+the ghc runtime.)
+
+Looking at Michael's bug report, looks like they were running with -J8.
+I don't see that exceeding the default ulimit of 1024. If they were really
+running at -J32, it would. It's not clear to me either how datalad's --jobs
+interacts with git-annex's -J, does it pass through or do you run multiple
+git-annex processes? People in that bug report are referring to multiple
+git-annex processes, which git-annex -J does not result in.
+
+All these -J5 etc values seem a bit high. I doubt that more than -J2
+makes a lot of sense given the command stages optimisation, that makes
+it use 6 threads and balance the work better than it used to. Only
+time it really would if if you're getting from several different
+remotes that each bottleneck on a different resource.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_5_0e7b492da14e067c34693b7be02e6864._comment b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_5_0e7b492da14e067c34693b7be02e6864._comment
new file mode 100644
index 0000000000..c759ea9b36
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_5_0e7b492da14e067c34693b7be02e6864._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="quick follow up"
+ date="2020-04-17T20:34:55Z"
+ content="""
+>  It's not clear to me either how datalad's --jobs interacts with git-annex's -J, does it pass through or do you run multiple git-annex processes? 
+
+ATM we just run a single `annex get` with `-J` option ATM (FWIW -- in `--batch` mode IIRC).  Things might change in the future to balance across different submodules.
+
+> All these -J5 etc values seem a bit high. I doubt that more than -J2 makes a lot of sense given the command stages optimisation, that makes it use 6 threads and balance the work better than it used to.
+
+I could do some timing later on, but I did see benefits as I could not go over 40-60MBps in a single download process (e.g. from S3) but parallel ones (even as high as 8 or 10) could easily carry that throughput in parallel, thus scaling up quite nicely.  If interested -- you could experiment on smaug to which you have access to possibly observe similar effects.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_5_db1ae584fc803c0dbb48c7e31a540c4e._comment b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_5_db1ae584fc803c0dbb48c7e31a540c4e._comment
new file mode 100644
index 0000000000..6481650a95
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_5_db1ae584fc803c0dbb48c7e31a540c4e._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-04-17T21:09:41Z"
+ content="""
+The sqlite open files is a red herring: That happened only when
+using a remote in a local directory. Anyway, I've fixed that.
+
+The open files I'm seeing now in my artifical
+test case (two local repos with 1000 unlocked files, git-annex get between them, lsof
+-Ki run after that's moved 500 files, while the git-annex process is suspended):
+
+	no -J	48
+	-J2	104
+	-J5	185
+	-J32	964
+
+Which seems fine, 28 file handles per -J increment.
+
+If you have something worse than that, show me the lsof.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_7_f584dc15789b371569e1925c4ee5ae36._comment b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_7_f584dc15789b371569e1925c4ee5ae36._comment
new file mode 100644
index 0000000000..edabfb4748
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_7_f584dc15789b371569e1925c4ee5ae36._comment
@@ -0,0 +1,127 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2020-04-18T02:05:52Z"
+ content="""
+>  5x3x2x2=60 copies of git cat-file max for -J5.
+
+So there is now up to 60 `git` processes, where each one has about 20 open files, totaling up to 1200 open files... so we are getting into thousands 
+<details>
+<summary>
+In my current attempt on the laptop, here is a `pstree` with counts per each process and total at the bottom - 883 open files for -J5 invocation, with each `git cat-file` taking between 14 and 29:
+</summary> 
+
+```shell
+$> total=0; pstree -l -a --compact-not -T -p `pgrep datalad` | sed -e 's,--library-path /[^ ]*,,g' -e 's,/usr/lib/git-annex.linux/shimmed/git/,,g' -e 's,--git-dir=.git --work-tree=. --literal-pathspecs -c annex.dotfiles=true,,g' | nl | while read l; do pid=$(echo \"$l\" | sed -e 's/.*,\([0-9][0-9]*\).*/\1/g'); of=$(lsof -Ki -p $pid 2>/dev/null|grep -v COMMAND | wc -l); echo \"$l\" | sed -e \"s/,$pid/,$pid = $of/g\"; total=$(($total + $of)) ; done; echo \"Total: $total open files across all processes\"
+1	datalad,2807826 = 54 /home/yoh/proj/datalad/datalad-maint/venvs/dev3/bin/datalad -l debug install -J 5 -g ///labs/haxby/raiders
+2	  `-git-annex,2808614 = 149  /usr/lib/git-annex.linux/shimmed/git-annex/git-annex get -c annex.dotfiles=true --json --json-error-messages --json-progress -J5 -- .
+3	      |-git,2808649 = 16  git  cat-file --batch
+4	      |-git,2808650 = 14  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+5	      |-(git,2808653 = 0)
+6	      |-git,2808654 = 16  git  cat-file --batch
+7	      |-git,2808655 = 16  git  cat-file --batch
+8	      |-git,2808656 = 16  git  cat-file --batch
+9	      |-git,2808657 = 16  git  cat-file --batch
+10	      |-git,2808658 = 16  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+11	      |-git,2808659 = 16  git  cat-file --batch
+12	      |-git,2808660 = 16  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+13	      |-git,2808661 = 16  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+14	      |-git,2808662 = 16  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+15	      |-git,2808663 = 16  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+16	      |-git,2808669 = 16  git  cat-file --batch
+17	      |-git,2808670 = 16  git  cat-file --batch
+18	      |-git,2808671 = 16  git  cat-file --batch
+19	      |-git,2808672 = 16  git  cat-file --batch
+20	      |-git,2808673 = 16  git  cat-file --batch
+21	      |-git,2808674 = 14  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+22	      |-git,2808675 = 14  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+23	      |-git,2808676 = 14  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+24	      |-git,2808677 = 14  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+25	      |-git,2808678 = 14  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+26	      |-git,2808679 = 17  git  cat-file --batch
+27	      |-git,2808680 = 14  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+28	      |-git,2808682 = 25  git  cat-file --batch
+29	      |-git,2808683 = 23  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+30	      |-git,2808685 = 26  git  cat-file --batch
+31	      |-git,2808686 = 24  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+32	      |-git,2808688 = 27  git  cat-file --batch
+33	      |-git,2808689 = 24  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+34	      |-git,2808690 = 28  git  cat-file --batch
+35	      |-git,2808691 = 26  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+36	      |-git,2808693 = 29  git  cat-file --batch
+37	      |-git,2808694 = 27  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+38	      |-git,2809036 = 26  git  cat-file --batch
+39	      `-git,2809037 = 24  git  cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+Total: 883 open files across all processes
+```
+
+</details>
+
+<details>
+<summary>
+looking at the one with 29 open files:
+</summary> 
+
+```shell
+$> lsof -Ki -p 2808691
+COMMAND     PID USER   FD   TYPE   DEVICE SIZE/OFF     NODE NAME
+git     2808691  yoh  cwd    DIR    259,5     4096 16654129 /tmp/raiders
+git     2808691  yoh  rtd    DIR    259,5     4096        2 /
+git     2808691  yoh  txt    REG    259,5   165632  8395234 /usr/lib/git-annex.linux/lib64/ld-linux-x86-64.so.2
+git     2808691  yoh  mem    REG    259,5   337024 11806232 /usr/lib/locale/aa_DJ.utf8/LC_CTYPE
+git     2808691  yoh  mem    REG    259,5     3284 11807992 /usr/lib/locale/en_US.utf8/LC_TIME
+git     2808691  yoh  mem    REG    259,5  1824496  8394627 /usr/lib/git-annex.linux/lib/x86_64-linux-gnu/libc.so.6
+git     2808691  yoh  mem    REG    259,5    35808  8395214 /usr/lib/git-annex.linux/lib/x86_64-linux-gnu/librt.so.1
+git     2808691  yoh  mem    REG    259,5   114128  8395210 /usr/lib/git-annex.linux/lib/x86_64-linux-gnu/libpthread.so.0
+git     2808691  yoh  mem    REG    259,5   121280  8395232 /usr/lib/git-annex.linux/lib/x86_64-linux-gnu/libz.so.1
+git     2808691  yoh  mem    REG    259,5   539304  8395937 /usr/lib/git-annex.linux/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
+git     2808691  yoh  mem    REG    259,5  3008120  8395330 /usr/lib/git-annex.linux/shimmed/git/git
+git     2808691  yoh    0r  FIFO     0,13      0t0 99400741 pipe
+git     2808691  yoh    1w  FIFO     0,13      0t0 99400742 pipe
+git     2808691  yoh    2w   REG     0,48        0 35023711 /home/yoh/.tmp/datalad_temp__runneroutput__mq55kiau
+git     2808691  yoh   77u  IPv4 99400731      0t0      TCP lena:38384->falkor.dartmouth.edu:http (CLOSE_WAIT)
+git     2808691  yoh   82u  IPv4 99392984      0t0      TCP lena:38386->falkor.dartmouth.edu:http (CLOSE_WAIT)
+git     2808691  yoh   83u  IPv4 99392024      0t0      TCP lena:38380->falkor.dartmouth.edu:http (ESTABLISHED)
+git     2808691  yoh   84u  IPv4 99400730      0t0      TCP lena:38382->falkor.dartmouth.edu:http (ESTABLISHED)
+git     2808691  yoh   85u  IPv4 99377953      0t0      TCP lena:38388->falkor.dartmouth.edu:http (CLOSE_WAIT)
+git     2808691  yoh   86w   REG    259,5 68071663 16654712 /tmp/raiders/.git/annex/tmp/MD5E-s6658782008--8def61aac5f6742194027447390405ff.hdf5.gz
+git     2808691  yoh   87w   REG    259,5 53047218 16654713 /tmp/raiders/.git/annex/tmp/MD5E-s121517414--f83afa4a5dff04b5a1467afd30e74632.nii.gz
+git     2808691  yoh   89w   REG    259,5 23378713 16654715 /tmp/raiders/.git/annex/tmp/MD5E-s23378713--7a238410b5c496a29e7967da21332c03.nii.gz
+git     2808691  yoh   94u  IPv4 99398310      0t0      TCP lena:38390->falkor.dartmouth.edu:http (CLOSE_WAIT)
+git     2808691  yoh  102u  IPv4 99394953      0t0      TCP lena:38400->falkor.dartmouth.edu:http (CLOSE_WAIT)
+git     2808691  yoh  106u  IPv4 99399711      0t0      TCP lena:38402->falkor.dartmouth.edu:http (CLOSE_WAIT)
+git     2808691  yoh  107w   REG    259,5   545747 16654726 /tmp/raiders/.git/annex/objects/2X/Kz/MD5E-s545747--e2c2cd58ad55da46bf778d223e01389e.nii.gz/MD5E-s545747--e2c2cd58ad55da46bf778d223e01389e.nii.gz
+```
+
+</details>
+
+<details>
+<summary>and only 16</summary> 
+
+```shell
+$> lsof -Ki -p 2808669
+
+COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
+git     2808669  yoh  cwd    DIR  259,5     4096 16654129 /tmp/raiders
+git     2808669  yoh  rtd    DIR  259,5     4096        2 /
+git     2808669  yoh  txt    REG  259,5   165632  8395234 /usr/lib/git-annex.linux/lib64/ld-linux-x86-64.so.2
+git     2808669  yoh  mem    REG  259,5  1322694 16654180 /tmp/raiders/.git/objects/pack/pack-3ed86065dacf772445fec4258d6e60ebe21baf77.pack
+git     2808669  yoh  mem    REG  259,5   505212 16654181 /tmp/raiders/.git/objects/pack/pack-3ed86065dacf772445fec4258d6e60ebe21baf77.idx
+git     2808669  yoh  mem    REG  259,5   337024 11806232 /usr/lib/locale/aa_DJ.utf8/LC_CTYPE
+git     2808669  yoh  mem    REG  259,5     3284 11807992 /usr/lib/locale/en_US.utf8/LC_TIME
+git     2808669  yoh  mem    REG  259,5  1824496  8394627 /usr/lib/git-annex.linux/lib/x86_64-linux-gnu/libc.so.6
+git     2808669  yoh  mem    REG  259,5    35808  8395214 /usr/lib/git-annex.linux/lib/x86_64-linux-gnu/librt.so.1
+git     2808669  yoh  mem    REG  259,5   114128  8395210 /usr/lib/git-annex.linux/lib/x86_64-linux-gnu/libpthread.so.0
+git     2808669  yoh  mem    REG  259,5   121280  8395232 /usr/lib/git-annex.linux/lib/x86_64-linux-gnu/libz.so.1
+git     2808669  yoh  mem    REG  259,5   539304  8395937 /usr/lib/git-annex.linux/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
+git     2808669  yoh  mem    REG  259,5  3008120  8395330 /usr/lib/git-annex.linux/shimmed/git/git
+git     2808669  yoh    0r  FIFO   0,13      0t0 99388817 pipe
+git     2808669  yoh    1w  FIFO   0,13      0t0 99388818 pipe
+git     2808669  yoh    2w   REG   0,48        0 35023711 /home/yoh/.tmp/datalad_temp__runneroutput__mq55kiau
+```
+</details>
+ we can see why it is fluctuating, although I have no clue why those are opened by `git cat-file`: connections to the remote (although -- why??), looking at .git/annex/tmp?
+
+But overall problem seems to me is this heavy growth of external processes due to multiple external `git` invocations per each `annex get` thread, and then each process consuming very small, but still tens of, open files.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_8_83eccac19016c971f1b799d935a4c0bb._comment b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_8_83eccac19016c971f1b799d935a4c0bb._comment
new file mode 100644
index 0000000000..6a1a7b6c17
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_8_83eccac19016c971f1b799d935a4c0bb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 8"
+ date="2020-04-18T02:14:32Z"
+ content="""
+FWIW, kept running it a bit more, the number `git cat-file` processes grew up a bit (to 42) with total open files 1034 but seems to be stable, i.e. one other support that there is no leaking processes or file descriptors -- just sheer growth of sub processes leading to large number of open files. 
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_9_5db907d77c5f5490c1bdc8e51387a9e9._comment b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_9_5db907d77c5f5490c1bdc8e51387a9e9._comment
new file mode 100644
index 0000000000..d476681451
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J8_resource_exhausted/comment_9_5db907d77c5f5490c1bdc8e51387a9e9._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2020-04-20T15:54:15Z"
+ content="""
+Thinking about this over the weekend, I had two ideas:
+
+* The worker pool has an AnnexState for each thread. If those could be
+  partitioned so eg perfom stage is always run by the same threads,
+  then when only one stage needs cat-file, the overall number of cat-file
+  processes would be reduced by 1/3rd.
+
+  This might be the least resource intensive approach. But, as threads
+  transition between stages, their AnnexState necessarily does too,
+  and the cleanup stage might need some state change made in the perform
+  stage, so swapping out the perform AnnexState for a cleanup one
+  seems hard to accomplish.
+
+* Could have a pool of cat-files, and just have worker threads block until
+  one is available. This would let it be pinned to the -J number, or
+  event to a smaller number.
+
+  Seems likely that only 2 or 3 in the cat-file pool will
+  maximise concurrency, because it's not a major bottleneck most of the
+  time, and when it is the actual bottleneck is probably disk IO and so
+  won't be helped by more (and likely more only increase unnecessary seeks).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files.mdwn b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files.mdwn
new file mode 100644
index 0000000000..7150eb1b45
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files.mdwn
@@ -0,0 +1,33 @@
+### Please describe the problem.
+
+Unclear reason why some files/keys fail to get in parallel.
+
+### What steps will reproduce the problem?
+
+In my case it is getting files from the datalad-archives special remote which fetches the tarball key, extracts, and copies for annex.
+I've implemented locking in datalad-archives on getting the tarball key and extracting the archive, so now we can run `get -JX` and it generally works. But when there is lots of files in the tarball, for some of them (seems to be up to the X in -JX) transfer fails.
+
+git annex simply reports
+[[!format sh """
+$> grep already git-annex-getJ5-5.log                               
+{"command":"get","wanted":[{"here":false,"uuid":"79080a38-0e94-4a0a-bd89-9022eada547b","description":"yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/crcns/aa-1"},{"here":false,"uuid":"895b9a07-6613-4c8a-95ae-280d8119475c","description":"[datalad-archives]"}],"note":"transfer already in progress, or unable to take transfer lock\nUnable to access these remotes: datalad-archives\nTry making some of these repositories available:\n\t79080a38-0e94-4a0a-bd89-9022eada547b -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/crcns/aa-1\n \t895b9a07-6613-4c8a-95ae-280d8119475c -- [datalad-archives]\n","skipped":[],"success":false,"key":"MD5E-s1001--2cd1bc42ddd745e7d5c00edb07d8c9d4","file":"MLd_cells/gg0304_6_A/conspecific/spike20"}
+.... 4 more
+
+$> find -lname */MD5E-s1001--2cd1bc42ddd745e7d5c00edb07d8c9d4 
+./MLd_cells/gg0304_6_A/conspecific/spike20
+"""]]
+
+so it is not that the key is used for multiple files (I remember we had that before, so checked for that first).
+According to the logs ([git-annex](http://www.onerussian.com/tmp/git-annex-getJ5-5.log) and [datalad](http://www.onerussian.com/tmp/datalad-getJ5-5.log)) that key is not even passed from annex to our special remote so somehow it freaks out and skips it.
+
+If needed, I could probably provide you a singularity image with the environment with datalad pre-installed with that branch so you could troubleshoot.
+
+
+### What version of git-annex are you using? On what operating system?
+
+Tried with bleeding edge 6.20180308+gitg3962ca71b-1~ndall+1 although originally detected with 6.20180220+gitg811d0d313-1~ndall+1
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_1_57844bc289adacc6a53162cd224e6df3._comment b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_1_57844bc289adacc6a53162cd224e6df3._comment
new file mode 100644
index 0000000000..502fa12d3e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_1_57844bc289adacc6a53162cd224e6df3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2018-03-09T18:55:51Z"
+ content="""
+May be would be of help: here datalad-archives spits out TRANSFER-SUCCESSes really fast since it takes it little time to just copy a little file... so it feels to me that issue is in some race condition within git-annex.  If I add 100ms delay before returning TRANSFER-SUCCESS from the special remote - number of failures goes down to 0-2 instead of 5ish. With 200ms delay seems to get no failures whatsoever.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_2_ea5d3efc56b70de03a5b0b5e908bf11f._comment b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_2_ea5d3efc56b70de03a5b0b5e908bf11f._comment
new file mode 100644
index 0000000000..b2348ff01a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_2_ea5d3efc56b70de03a5b0b5e908bf11f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-03-09T19:00:27Z"
+ content="""
+FWIW: I was wrong with the statement that # of failures goes upto the X in -JX -- just got 13 (when no delay) with -J5.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_3_ed5fa01a2263ebb4a24bfe0e46ee820f._comment b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_3_ed5fa01a2263ebb4a24bfe0e46ee820f._comment
new file mode 100644
index 0000000000..579960fda9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_3_ed5fa01a2263ebb4a24bfe0e46ee820f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-03-14T19:43:38Z"
+ content="""
+I was able to reproduce this with two normal git-annex repos
+and `git annex get -J10`. 6.20180227.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_4_5964e40963325975e5de37506a2852ca._comment b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_4_5964e40963325975e5de37506a2852ca._comment
new file mode 100644
index 0000000000..e3c8243e43
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_4_5964e40963325975e5de37506a2852ca._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-03-14T20:17:31Z"
+ content="""
+tryLockExclusive is returning Nothing when this happens.
+
+Which seems very similar to the problem fixed in
+[[parallel_get_can_fail_some_downloads_and_require_re-getting_]].
+Which really seemed to be fixed back then..
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_5_64705f2eddbb6fcb55edc797bbd3b22c._comment b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_5_64705f2eddbb6fcb55edc797bbd3b22c._comment
new file mode 100644
index 0000000000..4fb6884467
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_5_64705f2eddbb6fcb55edc797bbd3b22c._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-03-14T20:38:48Z"
+ content="""
+This is not the same as the previous bug; the STM code seems ok.
+It is finding an open exclusive lock handle in the STM lock pool
+for the transfer lock file, and so tryLockExclusive fails.
+
+Instrumented tryLockExclusive, and it's somehow being called twice or more
+on the same transfer lock file despite there being no duplicate keys.
+
+Aha.. sizeOfDownloadsInProgress calls getTransfers,
+which locks the transfer info files in order to check
+which transfers are running. So one of the other worker threads
+is calling that at just the wrong time, and so contending with
+the thread that is starting up the transfer.
+
+Bug was introduced by [[!commit 3cd47f997873ff9d50b35c0f4440763364766d93]].
+
+It's interesting that the transfer info file is being created before
+the transfer lock file. If the lock file were always created first,
+then getTransfers would not see the transfer before its lock file is
+locked, and this bug would be avoided. On the other hand,
+this exact ordering of file creation is why
+3cd47f997873ff9d50b35c0f4440763364766d93 is necessary.
+
+There are a couple of ways the files could be created in the wrong
+order. 3cd47f997873ff9d50b35c0f4440763364766d93 commit message describes
+one, which does not apply to the test case for this bug.
+
+Hmm, mkProgressUpdater was very recently changed to write the transfer
+info file, in 24df95f0f6ab474119aff3bbd942251373754ab2, and that comes
+before the transfer lock is created. That is probably the recent change
+that exposed this mess.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_6_e51841ae57dd9d2f48cd21fbdb90ac29._comment b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_6_e51841ae57dd9d2f48cd21fbdb90ac29._comment
new file mode 100644
index 0000000000..c4ab254675
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_6_e51841ae57dd9d2f48cd21fbdb90ac29._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2018-03-14T22:54:24Z"
+ content="""
+Ok, fixed the reversion in a fairly decent way,
+verified with 1000 files and -J10.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_7_2f7f87db7ca4d379d439ab88bdeee5b5._comment b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_7_2f7f87db7ca4d379d439ab88bdeee5b5._comment
new file mode 100644
index 0000000000..1fbd5ef75d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_7_2f7f87db7ca4d379d439ab88bdeee5b5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2018-03-14T23:09:20Z"
+ content="""
+cool, thanks, will test it out
+would this one somehow reveal itself also in non-J mode? (just doublechecking)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_8_36bcdc23439c4f19c5aaedff85213db0._comment b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_8_36bcdc23439c4f19c5aaedff85213db0._comment
new file mode 100644
index 0000000000..4972081c38
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_8_36bcdc23439c4f19c5aaedff85213db0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2018-03-14T23:14:46Z"
+ content="""
+This same bug can happen without -J if two git-annex processes are running
+at the same time and both downloading (different) files.
+
+So, the way datalad special remote runs git-annex, for example...
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_9_7ce83c16509bd42b2460ce59470f70c0._comment b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_9_7ce83c16509bd42b2460ce59470f70c0._comment
new file mode 100644
index 0000000000..a92e576f36
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_9_7ce83c16509bd42b2460ce59470f70c0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 9"
+ date="2018-03-15T12:47:01Z"
+ content="""
+FWIW, confirming that the fix seems to work nicely for us (with a bit of git-annex on sid, although typically do on stable).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key.mdwn b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key.mdwn
new file mode 100644
index 0000000000..8c3f4afc38
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key.mdwn
@@ -0,0 +1,53 @@
+### What steps will reproduce the problem?
+
+ask annex get in parallel files which point to the same key
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170815+gitg22da64d0f-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+# works in serial mode
+
+$> git annex get rh.white{,_avg}
+get rh.white (from web...) 
+/mnt/btrfs/scrap/tmp/ds0001 100%[===========================================>] 360.31K  --.-KB/s    in 0.1s    
+2017-08-30 10:08:02 URL:https://dl.dropboxusercontent.com/s/0lww4tomnwfanwd/rh.white_avg?dl=0 [368962/368962] -> "/mnt/btrfs/scrap/tmp/ds000114/derivatives/freesurfer/.git/annex/tmp/MD5E-s368962--99a4db61cedffee686aef99b2d197794" [1]
+(checksum...) ok
+(recording state in git...)
+(dev)2 10016.....................................:Wed 30 Aug 2017 10:08:02 AM EDT:.
+(git)smaug:…/btrfs/scrap/tmp/ds000114/derivatives/freesurfer[master]fsaverage5/surf
+$> git annex drop --fast rh.white{,_avg}         
+drop rh.white (checking https://dl.dropbox.com/s/0lww4tomnwfanwd/rh.white_avg?dl=0...) ok
+(recording state in git...)
+
+# "fails" in parallel
+$> git annex get -J2 rh.white{,_avg}   
+get rh.white get rh.white_avg (transfer already in progress, or unable to take transfer lock) 
+  Unable to access these remotes: web
+(from web...) 
+
+  Try making some of these repositories available:
+        00000000-0000-0000-0000-000000000001 -- web
+        5e47b3f3-f09c-4969-8885-920a49ff8a45 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/workshops/nih-workshop-2017/ds000114/derivatives/freesurfer
+failed
+/mnt/btrfs/scrap/tmp/ds0001 100%[===========================================>] 360.31K  1.63MB/s    in 0.2s    
+2017-08-30 10:08:21 URL:https://dl.dropboxusercontent.com/s/0lww4tomnwfanwd/rh.white_avg?dl=0 [368962/368962] -> "/mnt/btrfs/scrap/tmp/ds000114/derivatives/freesurfer/.git/annex/tmp/MD5E-s368962--99a4db61cedffee686aef99b2d197794" [1]
+(checksum...) ok
+(recording state in git...)
+git-annex: get: 1 failed
+(dev)2 10018 ->1.....................................:Wed 30 Aug 2017 10:08:21 AM EDT:.
+
+"""]]
+
+so at the end we get a run of git-annex which exits with error 1... and in json mode also the error(s) reported etc.
+I wondered if annex should first analyze passed paths to get actual keys to be fetched?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]]; also fixed for several other commands, but the final 
+> fix needed each command that could have the problem to be modified, so 
+> there could possibly be some I missed.. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_1_5b3879d1bb992ddf2aafa3fcb41b968f._comment b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_1_5b3879d1bb992ddf2aafa3fcb41b968f._comment
new file mode 100644
index 0000000000..11786bb777
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_1_5b3879d1bb992ddf2aafa3fcb41b968f._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-09-29T16:47:18Z"
+ content="""
+The only way I can see to improve this would be to keep track of which
+keys already have a thread working on them, and avoid a second thread
+working on the same key.
+
+I've started this in the avoid-dup-threads branch.
+
+Getting key information to commandAction would be quite the plumbing job;
+there are something like 50 call sites.
+
+More difficult, the key is not known yet when commandAction is called in a
+lot of cases, and looking up the key redundantly will slow down all
+git-annex scanning. Seems that nontrivial changes would be needed to every
+command.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_2_af7078b291d99569070f6a76579787aa._comment b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_2_af7078b291d99569070f6a76579787aa._comment
new file mode 100644
index 0000000000..3412f1cb17
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_2_af7078b291d99569070f6a76579787aa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="also the same for add"
+ date="2017-10-05T17:00:51Z"
+ content="""
+Hi Joey
+
+I did remember that we had something similar but forgot that it was for \"get\" -- now I was getting similar problem for \"add --jobs\".  Will this fix also work for it as well?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_3_86e1be495262a7f57428e92eb27a559f._comment b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_3_86e1be495262a7f57428e92eb27a559f._comment
new file mode 100644
index 0000000000..066f8db4e0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_3_86e1be495262a7f57428e92eb27a559f._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2017-10-05T20:36:50Z"
+ content="""
+here, caught one for you for add (git annex version is tiny bit dated: 6.20170815+gitg22da64d0f-1~ndall+1 )
+[[!format sh \"\"\"
+(Pdb) print e.msg
+Failed to run ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'add', '--json', '-J6', '082-sn/000001.dcm', '078-sn/000001.dcm', '080-sn/000002.dcm', '076-sn/000002.dcm', '080-sn/000004.dcm', '080-sn/000001.dcm', '079-sn/000003.dcm', '082-sn/000003.dcm', '073-sn/000002.dcm', '079-sn/000002.dcm', '079-sn/000001.dcm', '077-sn/000002.dcm', '074-sn/000001.dcm', '080-sn/000003.dcm', '077-sn/000001.dcm', '076-sn/000001.dcm', '081-sn/000002.dcm', '078-sn/000002.dcm', '081-sn/000001.dcm', '081-sn/000003.dcm', '073-sn/000001.dcm', '075-sn/000001.dcm', '079-sn/000004.dcm', '082-sn/000002.dcm', '075-sn/000002.dcm', '074-sn/000002.dcm'] under '/mnt/DICOM/test2/inbox/2016/12/12/unknown'. Exit code=1. out={\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s193740--3da2e91e0888c05e01daf8ef9ae79570.dcm\",\"file\":\"076-sn/000002.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s205064--851ce819ea44cabd66923d902e55cd2c.dcm\",\"file\":\"082-sn/000001.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s226874--8acaba7ff0f57a3e69a5c1afb8bc0ba3.dcm\",\"file\":\"080-sn/000001.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s193746--faf49ea7b403c8f6191fa5b7521ebbd5.dcm\",\"file\":\"078-sn/000001.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s205066--c5af824ecd895a342cba7ffefe019fde.dcm\",\"file\":\"082-sn/000003.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s226872--abdaf5312c4c11da68cc9aaead6bc93a.dcm\",\"file\":\"080-sn/000004.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s226768--352d7bf9be4b45316cb75c2fc5bfbdd2.dcm\",\"file\":\"079-sn/000002.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s226872--755e5e693b07fd7cab07fa55e0f17fd2.dcm\",\"file\":\"080-sn/000002.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s193636--47816f992ddf6167549b0d20bf430036.dcm\",\"file\":\"073-sn/000002.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s193750--465de1ebab376633842ac9e36f6fcc35.dcm\",\"file\":\"074-sn/000001.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s226766--04006df494da6adbe7b3eea90e4dba1b.dcm\",\"file\":\"079-sn/000003.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s226768--3624982179994bbaa781ee8c72c5d6b9.dcm\",\"file\":\"079-sn/000001.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s193636--98a6efe8bea17485297e5d600c4c01e6.dcm\",\"file\":\"077-sn/000002.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s193642--15770ed37bedb6bd90a7a4b39761a1fa.dcm\",\"file\":\"077-sn/000001.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s226870--621a7d3a2be10b99d45a39ef2526ab1c.dcm\",\"file\":\"080-sn/000003.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s204960--e28aac5eb5e52fe47c2671e8b87edc8c.dcm\",\"file\":\"081-sn/000002.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s193750--25cadf2f0fc7a4ca324687a742a2d55e.dcm\",\"file\":\"076-sn/000001.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s193740--0424fce22306f7590f6d94561eb74e93.dcm\",\"file\":\"078-sn/000002.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s204956--039309e288379d98480390043ea84ecb.dcm\",\"file\":\"081-sn/000001.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s204960--7b32e2620301909a74adea3d29c00ed5.dcm\",\"file\":\"081-sn/000003.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s193646--ff7337b5330f852063652f1e75099b27.dcm\",\"file\":\"073-sn/000001.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s226768--40821b65d32878f5859ed1b19c5633d0.dcm\",\"file\":\"079-sn/000004.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s193646--02704fbd9d37349c4ee96c1509f1a20d.dcm\",\"file\":\"075-sn/000001.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s193636--7c727d28c56da2476b744e8aca421b5c.dcm\",\"file\":\"075-sn/000002.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s193740--c0b3731d6a46df9000df32eeb78ae894.dcm\",\"file\":\"074-sn/000002.dcm\"}
+{\"command\":\"add\",\"success\":true,\"key\":\"MD5E-s205066--11b6f6e4cb2f5879a530f83d288bb7fa.dcm\",\"file\":\"082-sn/000002.dcm\"}
+ err=git-annex: 075-sn/000001.dcm not found
+git-annex: add: 1 failed
+
+(Pdb)
+[1]+  Stopped                 ../test/addall.sh
+(dev) [yoh@rolando test2]$ ls -l '/mnt/DICOM/test2/inbox/2016/12/12/unknown/075-sn/000001.dcm'
+lrwxrwxrwx 1 yoh users 129 Dec 12  2016 /mnt/DICOM/test2/inbox/2016/12/12/unknown/075-sn/000001.dcm -> ../.git/annex/objects/ZQ/3G/MD5E-s193646--02704fbd9d37349c4ee96c1509f1a20d.dcm/MD5E-s193646--02704fbd9d37349c4ee96c1509f1a20d.dcm
+
+\"\"\"]]
+
+so it does report success in json, but complains in stderr that file is not found... I guess some race condition between workers so it manages to catch the moment when file is moved into a key or smth like that?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_4_3428942e9b52091b2297cd9823f17219._comment b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_4_3428942e9b52091b2297cd9823f17219._comment
new file mode 100644
index 0000000000..e023db5e1c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_4_3428942e9b52091b2297cd9823f17219._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2017-10-06T00:38:25Z"
+ content="""
+verified that it is still the case with annex 6.20171001+gitg542d0649f-1~ndall+1
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_5_525ac8695b6253fc435112f336238c41._comment b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_5_525ac8695b6253fc435112f336238c41._comment
new file mode 100644
index 0000000000..ace650c101
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_5_525ac8695b6253fc435112f336238c41._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-10-16T16:06:50Z"
+ content="""
+The add problem is clearly an entirely unrelated problem. Opened this
+bug report for it: <add_-J_fails_with_not_found>
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_6_5f2ed95bcad2e3d1c4260d1fb0440052._comment b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_6_5f2ed95bcad2e3d1c4260d1fb0440052._comment
new file mode 100644
index 0000000000..32f2d4decc
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J___34__fails__34___to_get_files_with_the_same_key/comment_6_5f2ed95bcad2e3d1c4260d1fb0440052._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2017-10-17T17:21:27Z"
+ content="""
+Another way to approach the problem would be, when the transfer of
+the same key is already in progress by another thread of the same process, 
+wait for that thread to complete before running the requested transfer
+action.
+
+The assistant has a TransferMap of all transfers the process is running.
+That would need to be moved from the DaemonStatus to Annex state.
+
+To wait on the thread that's doing the transfer, would need to store
+a MVar or something in the TransferInfo; the ThreadId can't be waited on
+by itself.
+
+This seems much less intrusive, and just as fast as my initial approach.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication.mdwn b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication.mdwn
new file mode 100644
index 0000000000..e20e9ffc7d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication.mdwn
@@ -0,0 +1,44 @@
+### Please describe the problem.
+
+can't fetch in parallel from a host over ssh if authentication is password-based
+
+### What steps will reproduce the problem?
+
+try to  get -J4  from a host which has ssh authentication password-only (no key)
+
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170101+gitg93d69b1-1~ndall+1
+with newer version (6.20170220+gitg75a15e1ad-1~ndall+1) looks slightly different but to the same "effect"
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> git annex get -J4
+get sourcedata/sub-sid000004/ses-siemens0/anat/sub-sid000004_ses-siemens0_acq-MPRAGE_run-01_T1w.dicom.tgz get sourcedata/sub-sid000004/ses-siemens0/fmap/sub-sid000004_ses-siemens0_acq-3mm_run-01_phasediff.dicom.tgz get sourcedata/sub-sid000005/ses-siemens1/func/sub-sid000005_ses-siemens1_task-life_acq-2mm692_run-04_bold.dicom.tgz get sourcedata/sub-sid000005/ses-siemens1/func/sub-sid000005_ses-siemens1_task-life_acq-2mm748_run-03_bold.dicom.tgz (transfer already in progress, or unable to take transfer lock) 
+  Unable to access these remotes: origin
+(from origin...) (from origin...) 
+  Try making some of these repositories available:
+
+
+  	2e44be07-8f1a-4c11-a7cb-464802b87b26 -- mvdoc@smaug:/mnt/btrfs/dbic/inbox/dbic-ds-3mm/dbic/pulse_sequences
+   	b2ff2964-c31b-4784-b094-2bebb336da91 -- mvdoc@smaug:/mnt/btrfs/dbic/inbox/dbic-ds/dbic/pulse_sequences
+   	d486ea11-98dc-42d3-9640-e5713acfb675 -- yoh@rolando:/inbox/BIDS/dbic/1000-dbic-dataset [origin]
+failed
+get sourcedata/sub-sid000005/ses-siemens1/func/sub-sid000005_ses-siemens1_task-life_acq-2mm754_run-05_bold.dicom.tgz (from origin...) 
+(from origin...) 
+...
+yohtest@rolando.cns's password: yohtest@rolando.cns's password: yohtest@rolando.cns's password: yohtest@rolando.cns's password
+
+"""]]
+
+I have entered password just once -- didn't try to enter it multiple times into the void ;)  but I guess it would be neat if annex could handle this situation gracefully (e.g. initiate central ssh controller first before spawning parallel getters) and demand password once
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]]; this was fixed for ssh, except for in the case of `GIT_SSH`.
+> I don't think it can be supported for `GIT_SSH`, and don't think it's
+> worth leaving this open for something that can't be fixed. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_1_236d2b897a550e7db4b266814d4e778d._comment b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_1_236d2b897a550e7db4b266814d4e778d._comment
new file mode 100644
index 0000000000..40e7ee2ca0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_1_236d2b897a550e7db4b266814d4e778d._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-07T19:58:41Z"
+ content="""
+Well let's see.. To fix this would need some way for ssh to outsource its
+password prompting to another program, which could then serialize
+concurrent password requests, and perhaps reuse the same password when
+reconnecting to the same host.
+
+Sounds an aweful lot like ssh-agent, doesn't it?
+
+Now, it does happen to be the case that without -J, the password is only
+prompted for once to download multiple files from the same host. That works
+because of ssh connection caching. But in the -J case, the
+connection caching does not help, because multiple sshed are started before
+there's a connection to reuse, so each tries to make a new connection and
+prompts.
+
+Even if connection caching worked with -J, the general problem would remain
+when it did concurrent downloads from different hosts.
+
+So I tend to feel that this is just not fixable; if the user wants to use
+-J, they ought to use ssh-agent so it doesn't prompt for passwords.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_2_c877de08f959dee4ace34e66f42c8615._comment b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_2_c877de08f959dee4ace34e66f42c8615._comment
new file mode 100644
index 0000000000..c60ba6d4ad
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_2_c877de08f959dee4ace34e66f42c8615._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="may be?"
+ date="2017-04-07T21:01:56Z"
+ content="""
+well, it kinda depends at either at which level parallelization is happening or how parallel jobs handling is done, or may be ...
+
+level of parallelization:
+I guess ATM annex just parallelizes at the level of \"get --key KEY\" jobs.
+But if central process decided to try to \"get --from=remote --key KEY\" -- call which it submits to parallel work pull -- then it could first check if remote is an ssh remote and connection caching is established, and if not -- establish it and then submit this and/or any subsequent get call.
+This would though over-complicate the design I guess considerably, so probably shouldn't be approached.
+
+jobs handling:
+if parallel jobs could 'yield' back to the original process (e.g. if there was some protocoled exchange between them and master process... somewhat similar to git annex special remotes in a way) demanding some action (e.g. - authenticate me to the host) and then proceed back with its dues, could work out I guess.
+But I guess that is also not current implementation
+
+
+may be...:
+since I guess (didn't check) GIT_SSH_COMMAND is used (or not yet but could be?) for ssh transfers, such activity as establishing shared ssh connection could be deferred to it (with some proper locking/waiting for parallel invocations)... or am I wrong?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_3_daac1d424bc9e5b56772fa49707bc5a5._comment b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_3_daac1d424bc9e5b56772fa49707bc5a5._comment
new file mode 100644
index 0000000000..26f1aedc62
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_3_daac1d424bc9e5b56772fa49707bc5a5._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-04-07T21:06:51Z"
+ content="""
+How do you check if ssh has established a cached ssh connection?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_4_05bf20db275b911e2d89311182f289f6._comment b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_4_05bf20db275b911e2d89311182f289f6._comment
new file mode 100644
index 0000000000..27d39a7d88
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_4_05bf20db275b911e2d89311182f289f6._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-04-07T21:07:44Z"
+ content="""
+`GIT_SSH_COMMAND` is used for *every* call to ssh in git-annex.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_5_b094509fe0194313666b5b1db0a68156._comment b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_5_b094509fe0194313666b5b1db0a68156._comment
new file mode 100644
index 0000000000..4d904ca499
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_5_b094509fe0194313666b5b1db0a68156._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2017-04-08T03:16:48Z"
+ content="""
+> How do you check if ssh has established a cached ssh connection?
+
+ssh -O check  -- somewhat of an additional overhead, but possible
+
+> GIT_SSH_COMMAND is used for every call to ssh in git-annex.
+
+so then theoretically we could implement \"may be ...\" strategy on our end in our sshrun.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_6_f5fe8d4cecfceec5cb4a03dd054d2e0a._comment b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_6_f5fe8d4cecfceec5cb4a03dd054d2e0a._comment
new file mode 100644
index 0000000000..2daef87279
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_6_f5fe8d4cecfceec5cb4a03dd054d2e0a._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2017-05-11T18:09:04Z"
+ content="""
+All cases could be dealt with by having a single process-level prompt lock
+(not a lock file, but an MVar), that's taken when doing something
+that might prompt for input.
+
+Then `Annex.Ssh.prepSocket` could block to take the prompt lock, and once
+it has the prompt lock, start the ssh connection multiplexer and wait for
+the the ssh connection to be established.
+
+Thus, even if `git annex get -J` is connecting to multiple hosts that each
+need passwords, password prompting would be serialized.
+
+All message output could also be blocked while the prompt lock is held,
+and then concurrent output would not scramble with the ssh password prompt.
+
+`ssh -S path -O check` does indeed exit nonzero when ssh has not yet
+connected and is at a password prompt. Also, I noticed that the socket file
+is only created after the password prompt, so a less expensive check
+(though perhaps not as accurate) is to see if the socket file exists.
+(But, it seems we don't need to check, see below.)
+
+The real problem is starting the ssh connection multiplexer without
+blocking for eg a whole rsync transfer to run. There's
+not a `-O` command that starts the multiplexer. The only way to do it seems
+to be something like `ssh -S path -o ControlMaster=auto -o 
+ControlPersist=yes host true`. So, run a no-op command on the remote host just
+to get the connection up. Then prepSocket will know the cached connection
+is up, and can drop the prompt lock and return.
+
+It would only need to do this when concurrency is enabled, so
+non-concurrent uses the current, faster path.
+
+prepSocket takes a shared 
+file level lock of the socket's lock file, which is used to tell when
+another git-annex process is using the connection multiplexer.
+So, an optimisation would be for prepSocket to check if it's already
+taken that shared lock, and then it does not need to start the multiplexer.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_7_0118a107147f6b94a7da907e599e58db._comment b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_7_0118a107147f6b94a7da907e599e58db._comment
new file mode 100644
index 0000000000..24f34bcc01
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_7_0118a107147f6b94a7da907e599e58db._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2017-05-11T19:23:02Z"
+ content="""
+What about when `GIT_SSH` is used? `prepSocket` is not used then,
+and git-annex can only use the `GIT_SSH` interface to ssh to the host.
+So, the approach above won't work.
+
+git-annex could then try to use `GIT_SSH` to ssh to the host and run eg `true`,
+in hopes that `GIT_SSH` is enabling ssh connection caching and that will
+get the ssh connection set up. If `GIT_SSH` is not enabling connection
+caching, that might add an additional password prompt, and not avoid
+other password prompts from overlapping.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_8_5da63cf5fa93120c85b98077fba51488._comment b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_8_5da63cf5fa93120c85b98077fba51488._comment
new file mode 100644
index 0000000000..8860bc536e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J_cannot_be_used_with_password-based_authentication/comment_8_5da63cf5fa93120c85b98077fba51488._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""status"""
+ date="2017-05-11T21:57:24Z"
+ content="""
+Current status: It's implemented, but not for `GIT_SSH` yet.
+
+The display is a bit ugly, because the ssh password prompt line
+confuses the concurrent-output region manager. Opened
+[[minor_display_glitch_with_ssh_password_prompting_and_-J]] bug for that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J_from_ssh_remote_tries_to_lock_in_home_directory__63__.mdwn b/doc/projects/datalad/bugs-done/get_-J_from_ssh_remote_tries_to_lock_in_home_directory__63__.mdwn
new file mode 100644
index 0000000000..61cf5637c8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J_from_ssh_remote_tries_to_lock_in_home_directory__63__.mdwn
@@ -0,0 +1,50 @@
+### Please describe the problem.
+
+had `datalad get -J4` lockup ... interrupted it, ran git annex directly to observe some errors reported and what looks like to be an attempt to determine if the home directory on remote end is a git repo... see below for details of such a run.  
+
+may be unrelated but also experiencing some lock ups [while "interacting" with this remote  from datalad](https://github.com/datalad/datalad/issues/2128)
+
+### What version of git-annex are you using? On what operating system?
+6.20180206+gitg638032f3a-1~ndall+1 on the local
+6.20180115-g56b56033a on remote
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> 'git' '-c' 'receive.autogc=0' '-c' 'gc.auto=0' 'annex' 'get' '--debug' '-c' 'remote.rolando.annex-ssh-options=-o ControlMaster=auto -S /home/yoh/.cache/datalad/sockets/810d3ac4' '--json' '--json-progress' -J4  --from rolando --key SHA256E-s4295588--8db39d197775c7372bb1afff197ea724f158f3217ad064eef7ff8427a1502f15.tgz    
+fatal: Not a git repository: '../../../home/bids/.git'
+git-annex-shell: Not a git-annex or gcrypt repository.
+  Unable to run git-annex-shell on remote .
+{"byte-progress":4295588,"action":{"command":"get","note":"from rolando...","key":"SHA256E-s4295588--8db39d197775c7372bb1afff197ea724f158f3217ad064eef7ff8427a1502f15.tgz","file":null},"total-size":4295588,"percent-progress":"100%"}
+{"byte-progress":4295588,"action":{"command":"get","note":"from rolando...","key":"SHA256E-s4295588--8db39d197775c7372bb1afff197ea724f158f3217ad064eef7ff8427a1502f15.tgz","file":null},"total-size":4295588,"percent-progress":"100%"}
+{"command":"get","note":"checksum...","success":true,"key":"SHA256E-s4295588--8db39d197775c7372bb1afff197ea724f1  Unable to run git-annex-shell on remote .
+
+$> git annex drop 'sourcedata/sub-qa/ses-20180102'
+drop sourcedata/sub-qa/ses-20180102/anat/sub-qa_ses-20180102_scout.dicom.tgz (locking rolando...) ok
+(recording state in git...)
+
+$> 'git' '-c' 'receive.autogc=0' '-c' 'gc.auto=0' 'annex' 'get' '--debug' '-c' 'remote.rolando.annex-ssh-options=-o ControlMaster=auto -S /home/yoh/.cache/datalad/sockets/810d3ac4' '--json' '--json-progress' --from rolando --key SHA256E-s4295588--8db39d197775c7372bb1afff197ea724f158f3217ad064eef7ff8427a1502f15.tgz     
+{"byte-progress":4295588,"action":{"command":"get","note":"from rolando...","key":"SHA256E-s4295588--8db39d197775c7372bb1afff197ea724f158f3217ad064eef7ff8427a1502f15.tgz","file":null},"total-size":4295588,"percent-progress":"100%"}
+{"byte-progress":4295588,"action":{"command":"get","note":"from rolando...","key":"SHA256E-s4295588--8db39d197775c7372bb1afff197ea724f158f3217ad064eef7ff8427a1502f15.tgz","file":null},"total-size":4295588,"percent-progress":"100%"}
+{"command":"get","note":"checksum...","success":true,"key":"SHA256E-s4295588--8db39d197775c7372bb1afff197ea724f158f3217ad064eef7ff8427a1502f15.tgz","file":null}
+
+$> cat .git/config
+ ...
+[remote "rolando"]
+	url = bids@rolando.cns.dartmouth.edu:/inbox/BIDS/dbic/QA
+	fetch = +refs/heads/*:refs/remotes/rolando/*
+	annex-uuid = 6384a551-a41d-4290-b186-9258befede97
+	annex-ignore = false
+
+"""]]
+
+To get to that host I have `ProxyCommand ssh -q -A smaug.dartmouth.edu 'nc -w1 %h %p'` in my ~/.ssh/config for it (if relevant)
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Most of the days of the week. Friday is a tricky one
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]]; see my comment --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/get_-J_from_ssh_remote_tries_to_lock_in_home_directory__63__/comment_1_362a858ce78fa0b8d7949fb39fb247d9._comment b/doc/projects/datalad/bugs-done/get_-J_from_ssh_remote_tries_to_lock_in_home_directory__63__/comment_1_362a858ce78fa0b8d7949fb39fb247d9._comment
new file mode 100644
index 0000000000..27f8f3fef5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J_from_ssh_remote_tries_to_lock_in_home_directory__63__/comment_1_362a858ce78fa0b8d7949fb39fb247d9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2018-02-10T02:48:14Z"
+ content="""
+BTW remote location is an NFS mount ... git annex didn't show any issue working with it on that host any time recently
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_-J_from_ssh_remote_tries_to_lock_in_home_directory__63__/comment_2_3f985fc652c9a15b5989cc82cb5da1ad._comment b/doc/projects/datalad/bugs-done/get_-J_from_ssh_remote_tries_to_lock_in_home_directory__63__/comment_2_3f985fc652c9a15b5989cc82cb5da1ad._comment
new file mode 100644
index 0000000000..7aedcb64da
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_-J_from_ssh_remote_tries_to_lock_in_home_directory__63__/comment_2_3f985fc652c9a15b5989cc82cb5da1ad._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-18T17:26:37Z"
+ content="""
+So, this bug is mistitled, it's not about locking, but about looking.
+
+Or more clearly, something about file paths that end up pointing to a home directory.
+
+	fatal: Not a git repository: '../../../home/bids/.git' git-annex-shell: Not a git-annex or gcrypt repository.
+
+	Unable to run git-annex-shell on remote .
+
+The second message used to be output by the code path warming up the ssh
+connection to handle concurrency. That code path has since changed, and no
+longer tries to run git-annex-shell there.
+
+And, notice the "remote ." -- that means that 
+`Git.repoDescribe (gitConfigRepo (remoteGitConfig gc))` produced "."
+
+And the git-annex shell command was similarly passed a directory
+of `Git.repoPath $ gitConfigRepo $ remoteGitConfig gc`
+
+So, it was running "git-annex-shell ." which got converted to an absolute path by git-annex-shell
+when CWD was $HOME, and then re-relevatized.
+
+Clearly that code was pretty broken, apparently more than I knew at the time
+I fixed it. I do think it's fixed though, by [[!commit 3dd43df9c2748df355314cd07b2bb8ebd30be69e]].
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_fails___40__only_in_--debug__41___with_rsync_error.mdwn b/doc/projects/datalad/bugs-done/get_fails___40__only_in_--debug__41___with_rsync_error.mdwn
new file mode 100644
index 0000000000..2503714e05
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_fails___40__only_in_--debug__41___with_rsync_error.mdwn
@@ -0,0 +1,83 @@
+### Please describe the problem.
+
+I have been trying to get to the bottom of it but failed
+
+Seems to relate to the version and/or build of git-annex on remote end, but happens whenever on remote it is a conda-forge build 8.20210621-g91f9aac 
+
+Whenever I can get/drop without `--debug`, with `--debug` it fails:
+
+```
+(git-annex)lena:/tmp/testds-mit[master]git-annex
+$> git annex get 123                                
+get 123 (from origin...) 
+ok
+(recording state in git...)
+1 11897.....................................:Fri 06 Aug 2021 06:09:05 PM EDT:.
+(git-annex)lena:/tmp/testds-mit[master]git-annex
+$> git annex drop 123
+drop 123 (locking origin...) ok
+(recording state in git...)
+1 11898.....................................:Fri 06 Aug 2021 06:09:11 PM EDT:.
+(git-annex)lena:/tmp/testds-mit[master]git-annex
+$> git annex get 123 --debug
+[2021-08-06 18:09:22.424837137] (Utility.Process) process [1488170] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2021-08-06 18:09:22.437700889] (Utility.Process) process [1488170] done ExitSuccess
+[2021-08-06 18:09:22.438748331] (Utility.Process) process [1488171] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","refs/heads/master"]
+[2021-08-06 18:09:22.449949392] (Utility.Process) process [1488171] done ExitSuccess
+[2021-08-06 18:09:22.451491273] (Utility.Process) process [1488172] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","ls-files","--stage","-z","--","123"]
+[2021-08-06 18:09:22.45371749] (Utility.Process) process [1488173] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-06 18:09:22.455744285] (Utility.Process) process [1488174] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2021-08-06 18:09:22.458678421] (Utility.Process) process [1488175] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+get 123 [2021-08-06 18:09:22.471519462] (Utility.Process) process [1488176] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2021-08-06 18:09:22.479244675] (Utility.Process) process [1488176] done ExitSuccess
+[2021-08-06 18:09:22.480965615] (Utility.Process) process [1488177] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-08-06 18:09:22.494689644] (Utility.Process) process [1488177] done ExitSuccess
+[2021-08-06 18:09:22.496859969] (Utility.Process) process [1488178] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..b1854b845d5ab7dbae4f50607ae02b76ae526716","--pretty=%H","-n1"]
+[2021-08-06 18:09:22.505499833] (Utility.Process) process [1488178] done ExitSuccess
+[2021-08-06 18:09:22.507468513] (Utility.Process) process [1488179] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..83d0262dcb3d3abf7f64ce7079e5d6e4a27c2293","--pretty=%H","-n1"]
+[2021-08-06 18:09:22.517489766] (Utility.Process) process [1488179] done ExitSuccess
+[2021-08-06 18:09:22.519480403] (Utility.Process) process [1488180] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-08-06 18:09:22.519793644] (Utility.Process) process [1488181] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+(from origin...) 
+[2021-08-06 18:09:22.524141345] (Utility.Process) process [1488182] read: ssh ["-o","BatchMode=true","-S",".git/annex/ssh/openmind7.mit.edu","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","openmind7.mit.edu","true"]
+[2021-08-06 18:09:24.650559322] (Utility.Process) process [1488182] done ExitSuccess
+[2021-08-06 18:09:24.651134161] (Utility.Process) process [1488187] chat: ssh ["openmind7.mit.edu","-S",".git/annex/ssh/openmind7.mit.edu","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","git-annex-shell 'p2pstdio' '/~/tmp/testds' '--debug' '339c2fc7-df7a-44fd-97eb-5a2c41ac8a0a' --uuid f30e2969-4ddf-4edb-ba45-37c455816c9a"]
+[2021-08-06 18:09:24.80528113] (P2P.IO) [ssh connection Just 1488187] [ThreadId 4] P2P > ERROR auth failed
+[2021-08-06 18:09:24.84393255] (Utility.Process) process [1488187] done ExitSuccess
+[2021-08-06 18:09:24.846367147] (Utility.Process) process [1488189] read: rsync ["--progress","--inplace","--perms","-e","'ssh' 'openmind7.mit.edu' '-S' '.git/annex/ssh/openmind7.mit.edu' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'git-annex-shell ''sendkey'' ''/~/tmp/testds'' ''--debug'' ''MD5E-s0--d41d8cd98f00b204e9800998ecf8427e'' --uuid f30e2969-4ddf-4edb-ba45-37c455816c9a ''--'' ''remoteuuid=339c2fc7-df7a-44fd-97eb-5a2c41ac8a0a'' ''unlocked='' ''direct='' ''associatedfile=123'' ''--'''","--","dummy:",".git/annex/tmp/MD5E-s0--d41d8cd98f00b204e9800998ecf8427e"]
+protocol version mismatch -- is your shell clean?
+(see the rsync man page for an explanation)
+rsync error: protocol incompatibility (code 2) at compat.c(178) [Receiver=3.1.3]
+[2021-08-06 18:09:24.970785079] (Utility.Process) process [1488189] done ExitFailure 2
+rsync exited 2
+
+  rsync failed -- run git annex again to resume file transfer
+
+  Transfer failed
+[2021-08-06 18:09:25.014462898] (Utility.Process) process [1488180] done ExitSuccess
+[2021-08-06 18:09:25.016852848] (Utility.Process) process [1488181] done ExitSuccess
+
+  Unable to access these remotes: origin
+[2021-08-06 18:09:25.021878961] (Utility.Process) process [1488191] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-08-06 18:09:25.025537927] (Utility.Process) process [1488192] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+
+  No other repository is known to contain the file.
+failed
+[2021-08-06 18:09:25.038970056] (Utility.Process) process [1488191] done ExitSuccess
+[2021-08-06 18:09:25.040408598] (Utility.Process) process [1488192] done ExitSuccess
+[2021-08-06 18:09:25.040589952] (Utility.Process) process [1488175] done ExitSuccess
+[2021-08-06 18:09:25.040701306] (Utility.Process) process [1488174] done ExitSuccess
+[2021-08-06 18:09:25.040787814] (Utility.Process) process [1488173] done ExitSuccess
+[2021-08-06 18:09:25.040861945] (Utility.Process) process [1488172] done ExitSuccess
+[2021-08-06 18:09:25.041785909] (Utility.Process) process [1488193] read: ssh ["-O","stop","-S","openmind7.mit.edu","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
+[2021-08-06 18:09:25.061503656] (Utility.Process) process [1488193] done ExitSuccess
+get: 1 failed
+
+```
+
+I just merged freshier update of conda-forge to 8.20210803 -- will try that one later 
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/get_fails___40__only_in_--debug__41___with_rsync_error/comment_1_d30e7f8eecfb73f2f97ec87285966f21._comment b/doc/projects/datalad/bugs-done/get_fails___40__only_in_--debug__41___with_rsync_error/comment_1_d30e7f8eecfb73f2f97ec87285966f21._comment
new file mode 100644
index 0000000000..bd8c648b34
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_fails___40__only_in_--debug__41___with_rsync_error/comment_1_d30e7f8eecfb73f2f97ec87285966f21._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-08-09T16:33:15Z"
+ content="""
+git-annex 8.20210714 fixed a bug where --debug went to stdout, not stderr.
+(See [[wanted_started_to_dump_debug_output_to_stdout_]])
+
+You seem to be using a version that still has the bug. Upgrade.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_fails___40__only_in_--debug__41___with_rsync_error/comment_2_6ec6e02bfb94b27b8da1ed68e4f9f121._comment b/doc/projects/datalad/bugs-done/get_fails___40__only_in_--debug__41___with_rsync_error/comment_2_6ec6e02bfb94b27b8da1ed68e4f9f121._comment
new file mode 100644
index 0000000000..3c6c672051
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_fails___40__only_in_--debug__41___with_rsync_error/comment_2_6ec6e02bfb94b27b8da1ed68e4f9f121._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2021-08-09T17:58:55Z"
+ content="""
+damn, sorry for the noise and thanks for the link -- something was nagging in the back of my head, but I didn't listen ;)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_from_the_web_remote_fails___40__redirect__63____41___-_lack_of_further_debug_info.mdwn b/doc/projects/datalad/bugs-done/get_from_the_web_remote_fails___40__redirect__63____41___-_lack_of_further_debug_info.mdwn
new file mode 100644
index 0000000000..5d7e3fcd81
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_from_the_web_remote_fails___40__redirect__63____41___-_lack_of_further_debug_info.mdwn
@@ -0,0 +1,94 @@
+### Please describe the problem.
+
+Originally reported on [https://github.com/datalad/datalad/issues/2472](datalad issue 2472)
+
+First I present full initial dump, then minimal set of commands and a few observations (e.g. seems to be related to running it within that docker environment, but cannot figure out why)
+
+[[!format sh """
+$> docker run -it --rm miykael/datalad_test
+neuro@d0008523faf7:~$ cd ds000114/derivatives/fmriprep/
+neuro@d0008523faf7:~/ds000114/derivatives/fmriprep$ git annex get --debug sub-01.html
+[2018-05-06 15:30:05.79497316] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","sub-01.html"]
+get sub-01.html [2018-05-06 15:30:05.801191505] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-05-06 15:30:05.828819907] process done ExitSuccess
+[2018-05-06 15:30:05.82896273] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-05-06 15:30:05.832716117] process done ExitSuccess
+[2018-05-06 15:30:05.833138385] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..7d2ed09660cc91efbeb52b5792fb372622463813","--pretty=%H","-n1"]
+[2018-05-06 15:30:05.837375012] process done ExitSuccess
+[2018-05-06 15:30:05.837896891] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-05-06 15:30:05.838257537] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+(from web...) 
+
+(from web...) 
+
+
+  Unable to access these remotes: web
+
+  Try making some of these repositories available:
+  	00000000-0000-0000-0000-000000000001 -- web
+   	b8b7bab3-c978-4f50-8ed4-e77900198eb9 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/workshops/nih-workshop-2017/ds000114/derivatives/fmriprep
+failed
+[2018-05-06 15:30:05.877509068] process done ExitSuccess
+[2018-05-06 15:30:05.877986803] process done ExitSuccess
+git-annex: get: 1 failed
+
+neuro@d0008523faf7:~/ds000114/derivatives/fmriprep$ git annex whereis sub-01.html
+whereis sub-01.html (2 copies) 
+  	00000000-0000-0000-0000-000000000001 -- web
+   	b8b7bab3-c978-4f50-8ed4-e77900198eb9 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/workshops/nih-workshop-2017/ds000114/derivatives/fmriprep
+
+  web: https://dl.dropbox.com/s/f03sxu7omhsibyc/sub-01.html?dl=0
+ok
+
+neuro@d0008523faf7:~/ds000114/derivatives/fmriprep$ curl https://dl.dropbox.com/s/f03sxu7omhsibyc/sub-01.html?dl=0
+<html>
+  <head><title>Found</title></head>
+  <body>
+    <h1>Found</h1>
+    <p>The resource was found at <a href="https://dl.dropboxusercontent.com/s/f03sxu7omhsibyc/sub-01.html?dl=0">https://dl.dropboxusercontent.com/s/f03sxu7omhsibyc/sub-01.html?dl=0</a>;
+you should be redirected automatically.
+
+<!--  --></p>
+    <hr noshade>
+    <div align="right">WSGI Server</div>
+  </body>
+</html>
+
+neuro@d0008523faf7:~/ds000114/derivatives/fmriprep$ git annex version
+git-annex version: 6.20180416+gitg86b18966f-1~ndall+1
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux x86_64
+
+"""]]
+
+Minimal set of commands to replicate
+
+[[!format sh """
+git clone http://datasets.datalad.org/workshops/nih-2017/ds000114/derivatives/fmriprep/.git
+cd fmriprep
+git annex get --debug --from=web sub-01.html
+"""]]
+
+- I think the issue is somehow specific to running it within that docker -- if those commands ran on laptop, it works just fine!
+- Issue persists with the `6.20180501-g0d2527e67` manually installed in the container
+- Since then I also provided that file from the webserver, so if you do `git fetch`, it would start fetching that file from the web server (thus obfuscating the issue), so you would need ' --from=web ' to force an attempt to download from the web
+- if before, with invoking wget/curl commands it was possible to see what is going on, ATM `--debug` of git-annex does not give any information about what is attempted to be fetched from web remote and what problem it is experiencing.  I think it would be very valuable to get more troubleshooting information output in `--debug`
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> This does not involve redirects. It's hitting the url a
+> couple of times on failure, thus the multiple "from web".
+> That was due to a bug in the forward retry code; `Just 0 > Nothing`.
+> Fixed.
+> 
+> I added a display of the error message from the web server.
+> 
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed.mdwn b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed.mdwn
new file mode 100644
index 0000000000..10934c5bea
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed.mdwn
@@ -0,0 +1,78 @@
+### Please describe the problem.
+
+A very basic operation is stuck (isn't there a unit-test?)
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+#!/bin/bash
+
+export PS4='> '
+set -x
+set -eu
+cd "$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)"
+
+(
+mkdir src
+cd src
+git init
+git annex init
+
+
+touch 123
+git add 123
+git commit -m 123 123
+)
+
+#git clone --shared src dest
+git clone src dest
+
+(
+cd dest
+#git annex init
+# would stall unless we git annex init above with 8.20200810+git5-gb41f77445-1~ndall+1
+git annex get 123
+)
+
+ls -lLi {dest,src}/123
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+8.20200810+git47-g27329f0bb-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> bash check-annex-hardlink.sh 
+> set -eu
+>> mktemp -d /home/yoh/.tmp/dl-XXXXXXX
+> cd /home/yoh/.tmp/dl-sgm3azv
+> mkdir src
+> cd src
+> git init
+Initialized empty Git repository in /home/yoh/.tmp/dl-sgm3azv/src/.git/
+> git annex init
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
+> touch 123
+> git add 123
+> git commit -m 123 123
+[master (root-commit) 8e97f2f] 123
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ create mode 100644 123
+> git clone src dest
+Cloning into 'dest'...
+done.
+> cd dest
+> git annex get 123
+(merging origin/git-annex into git-annex...)
+(scanning for unlocked files...)
+^C
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_1_dee4b1e8c5cc15a5d362df3b97a886a8._comment b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_1_dee4b1e8c5cc15a5d362df3b97a886a8._comment
new file mode 100644
index 0000000000..28e4ece372
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_1_dee4b1e8c5cc15a5d362df3b97a886a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2020-08-25T15:01:16Z"
+ content="""
+FWIW:ha ha -- just now spotted that I have used `git add` instead of `git annex add` (not that `get` should have stuck)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_2_16bf63e639626f5dfedd6f3809216747._comment b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_2_16bf63e639626f5dfedd6f3809216747._comment
new file mode 100644
index 0000000000..c3f295bce3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_2_16bf63e639626f5dfedd6f3809216747._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment: works on my end"
+ date="2020-08-25T15:02:43Z"
+ content="""
+Your script doesn't stall on my end.  I tried with the last git-annex
+release 8.20200810 and the commit you report (27329f0bb).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_3_3b3dc5b946e405955b68b0c4c3d7df3d._comment b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_3_3b3dc5b946e405955b68b0c4c3d7df3d._comment
new file mode 100644
index 0000000000..8d3239fb23
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_3_3b3dc5b946e405955b68b0c4c3d7df3d._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="pidlock to blame!"
+ date="2020-08-25T16:27:08Z"
+ content="""
+Thank you Kyle!  your comment reminded me that yesterday while I was trying to reproduce [stalling issue on NFS (not yet reported here)]() I have set globally pidlock=true!  
+
+<details>
+<summary>Here is an adjusted script which sets it in the clone and causes the stall (also changed to use git annex add instead of git add)</summary> 
+
+```shell
+#!/bin/bash
+
+export PS4='> '
+set -x
+set -eu
+cd \"$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)\"
+
+(
+mkdir src
+cd src
+git init
+git annex init
+
+
+touch 123
+git annex add 123
+git commit -m 123 123
+)
+
+#git clone --shared src dest
+git clone src dest
+
+(
+cd dest
+#git annex init
+# would stall unless we git annex init above with 8.20200810+git5-gb41f77445-1~ndall+1
+git config annex.pidlock true
+git annex get 123
+)
+
+ls -lLi {dest,src}/123
+
+```
+</details>
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_4_91cdb022987aa3a8852a82ace092a929._comment b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_4_91cdb022987aa3a8852a82ace092a929._comment
new file mode 100644
index 0000000000..1c7332418b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_4_91cdb022987aa3a8852a82ace092a929._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 4"
+ date="2020-08-25T17:51:41Z"
+ content="""
+I can trigger it with annex.pidlock=true.  It looks like the hang
+starts with 96f6aa39d (add runsGitAnnexChildProcess calls,
+2020-06-17).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_4_b2c7517a7482071111514a68c70ce8dc._comment b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_4_b2c7517a7482071111514a68c70ce8dc._comment
new file mode 100644
index 0000000000..aef78e732d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_4_b2c7517a7482071111514a68c70ce8dc._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-08-25T17:44:43Z"
+ content="""
+This is the same class of bug as
+[[!commit 82448bdf39bbe2b4fb6e0bac0735b845d52e189a]] fixed.
+
+Subsequent to that fix, I audited for other bugs in this class
+and tried to fix them too 
+in [[!commit 96f6aa39dda335bf9aa25ed8a67756e31bd307c2]].
+What that commit missed was that runsGitAnnexChildProcess only
+affects running git commands, while actually in all 3 places touched by
+that commit, git-annex runs other, non-git commands that result in git-annex
+being run. So all 3 of those can still deadlock like this, and actually
+that commit made it worse by making them always deadlock, rather than only
+theoretically deadlock in some case where some other part of git-annex
+happened to have taken the pid lock at the same time.
+
+(Not really deadlock, I think, but wait for the annex.pidlocktimeout 
+and then fail after 5 minutes.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_6_76433ca072233f8cd24600d3e45f97c5._comment b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_6_76433ca072233f8cd24600d3e45f97c5._comment
new file mode 100644
index 0000000000..14010e4a65
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_6_76433ca072233f8cd24600d3e45f97c5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-08-25T21:35:15Z"
+ content="""
+While fixed, this shows that annex.pidlock blocking for a long time should
+display a message. Perhaps it could first try to take the lock, and only
+display the message if it needs to wait on it.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_7_21dbdbf7e4e889dc7c2475a0b9d4c5d7._comment b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_7_21dbdbf7e4e889dc7c2475a0b9d4c5d7._comment
new file mode 100644
index 0000000000..940137d96d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_is_stuck_unless_a_clone_was_previously_explicitly___34__annex_init__34__ed/comment_7_21dbdbf7e4e889dc7c2475a0b9d4c5d7._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2020-08-26T17:02:26Z"
+ content="""
+Added that message after the first second waiting on a pid lock.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished.mdwn b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished.mdwn
new file mode 100644
index 0000000000..3d0f2af59e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished.mdwn
@@ -0,0 +1,69 @@
+### Please describe the problem.
+
+I think I never saw that before.  The only thing which differs now I think is the version of git-annex on this box:
+
+[[!format sh """
+$> git annex get --from origin --debug 'sub-qa/ses-20180312/func/sub-qa_ses-20180312_task-rest_acq-p2Xs4X35mm_bold.nii.gz'                              
+[2018-09-21 23:26:38.299280879] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-09-21 23:26:38.303220623] process done ExitSuccess
+[2018-09-21 23:26:38.311081622] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-09-21 23:26:38.314302424] process done ExitSuccess
+[2018-09-21 23:26:38.314584504] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..4f0e8cd9a43b003228c3898133b1e200f9bdfc22","--pretty=%H","-n1"]
+[2018-09-21 23:26:38.321260451] process done ExitSuccess
+[2018-09-21 23:26:38.321567411] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-09-21 23:26:38.322235784] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-09-21 23:26:38.327995657] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","sub-qa/ses-20180312/func/sub-qa_ses-20180312_task-rest_acq-p2Xs4X35mm_bold.nii.gz"]
+get sub-qa/ses-20180312/func/sub-qa_ses-20180312_task-rest_acq-p2Xs4X35mm_bold.nii.gz (from origin...) 
+[2018-09-21 23:26:38.336441538] chat: ssh ["bids@rolando.cns","-S",".git/annex/ssh/bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba8f2cea-f229-422c-82be-6580e5e07ed5' --uuid 6384a551-a41d-4290-b186-9258befede97"]
+[2018-09-21 23:26:39.94999901] P2P > ERROR auth failed
+
+  fd:19: hClose: resource vanished (Broken pipe)
+failed
+[2018-09-21 23:26:39.951838683] read: ssh ["-O","stop","-S","bids@rolando.cns","-o","ControlMaster=auto","-o","ControlPersist=yes","localhost"]
+[2018-09-21 23:26:39.960970417] process done ExitSuccess
+[2018-09-21 23:26:39.961786471] process done ExitSuccess
+[2018-09-21 23:26:39.962311637] process done ExitSuccess
+
+$> git annex version
+git-annex version: 6.20180913+git33-g2cd5a723f-1~ndall+1
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.12 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+local repository version: 5
+
+$> ssh -S .git/annex/ssh/bids@rolando.cns bids@rolando.cns ls /inbox/BIDS/dbic/QA
+                                                                                 
+
+    Dartmouth College, Department of Psychological and Brain Sciences
+                      Authorized access only
+
+
+
+
+CHANGES
+code
+...
+
+$> ssh -S .git/annex/ssh/bids@rolando.cns bids@rolando.cns git annex version     
+
+
+    Dartmouth College, Department of Psychological and Brain Sciences
+                      Authorized access only
+
+
+git-annex version: 6.20180115-g56b56033a
+
+"""]]
+
+so ssh connection seems to be ok
+
+what could it be?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_10_dd7883772bb37fa85aa1332633184071._comment b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_10_dd7883772bb37fa85aa1332633184071._comment
new file mode 100644
index 0000000000..b4f18dade4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_10_dd7883772bb37fa85aa1332633184071._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-09-25T17:18:14Z"
+ content="""
+Ok, reproduced by downgrading git-annex, so it is a reversion in the
+fallback from p2pstdio.
+
+It is indeed caused by [[!commit b18fb1e343e9654207fbebacf686659c75d0fb4c]],
+because that adds a new ProtocolEOF value, and postAuth has a fallthrough
+case that tries to then send a ERROR message back over the connection, but
+by that time the pipe has closed.
+
+So that was an easy fix. I do still wonder how a system that displays
+/etc/issue or whatever to noninteractive logins could have ever worked with
+rsync or git-annex. But if that system doesn't work after this fix, it's an
+unrelated problem.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_11_375e6d23c43a2cc0ef8bb81b06c3bcc9._comment b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_11_375e6d23c43a2cc0ef8bb81b06c3bcc9._comment
new file mode 100644
index 0000000000..7887e73ef2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_11_375e6d23c43a2cc0ef8bb81b06c3bcc9._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 11"
+ date="2018-09-26T00:10:40Z"
+ content="""
+FWIW confirming that the issue is resolved for my attempts while interacting with that very old git-annex on a server side
+
+[[!format sh \"\"\"
+(git-annex)hopa:/tmp/repo[master]
+$> git annex get 1                              
+get 1 (from origin...) 
+ 
+  fd:19: hClose: resource vanished (Broken pipe)
+
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+  	f6bedfe8-0e58-4182-bca3-764c5c3ed17b -- yoh@washoe:/tmp/repo [origin]
+failed
+git-annex: get: 1 failed
+1 5943 ->1.....................................:Tue 25 Sep 2018 08:07:34 PM EDT:.
+(git-annex)hopa:/tmp/repo[master]
+$> sudo dpkg -i ../git-annex-standalone_6.20180913+git149-g23bd27773-1\~ndall+1_amd64.deb 
+[sudo] password for yoh: 
+(Reading database ... 825207 files and directories currently installed.)
+Preparing to unpack .../git-annex-standalone_6.20180913+git149-g23bd27773-1~ndall+1_amd64.deb ...
+Unpacking git-annex-standalone (6.20180913+git149-g23bd27773-1~ndall+1) over (6.20180913+git52-gdb1644808-1~ndall+1) ...
+Setting up git-annex-standalone (6.20180913+git149-g23bd27773-1~ndall+1) ...
+Processing triggers for gnome-menus (3.13.3-11) ...
+Processing triggers for desktop-file-utils (0.23-2) ...
+Processing triggers for mime-support (3.60) ...
+Processing triggers for doc-base (0.10.8) ...
+Processing 1 changed doc-base file...
+Registering documents with scrollkeeper...
+Processing triggers for hicolor-icon-theme (0.17-2) ...
+Processing triggers for man-db (2.8.2-1) ...
+sudo dpkg -i   4.98s user 1.95s system 65% cpu 10.632 total
+1 5944.....................................:Tue 25 Sep 2018 08:07:52 PM EDT:.
+(git-annex)hopa:/tmp/repo[master]
+$> git annex get 1                                                                       
+get 1 (from origin...) 
+(checksum...) ok                  
+(recording state in git...)
+
+\"\"\"]]
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_1_032dfcb0dc7e5c54a0cbc6634ad77268._comment b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_1_032dfcb0dc7e5c54a0cbc6634ad77268._comment
new file mode 100644
index 0000000000..6bf1259cb0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_1_032dfcb0dc7e5c54a0cbc6634ad77268._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="bremner"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="Similar failure with one host running 6.20180913-1"
+ date="2018-09-22T18:38:23Z"
+ content="""
+I have two up to date debian testing machines on my desk, same kernel, both running 6.20180913-1 from Debian. One of them sees these \"auth failed\" but not the other.  The server they are trying to fetch from is running 6.20170101-1+deb9u2. The one that is failing  has a restrictive firewall on it; could that be the problem? In principle it is supposed to allow all outbound traffic. Certainly ssh to the server works.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_2_1c079d165831b790676dc6bec0549773._comment b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_2_1c079d165831b790676dc6bec0549773._comment
new file mode 100644
index 0000000000..8eb24f15bd
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_2_1c079d165831b790676dc6bec0549773._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="bremner"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="Dropped the firewall, no change. Maybe it's IPv6?"
+ date="2018-09-22T18:56:12Z"
+ content="""
+<pre>
+convex# iptables -L      
+Chain INPUT (policy ACCEPT)
+target     prot opt source               destination         
+
+Chain FORWARD (policy DROP)
+target     prot opt source               destination         
+
+Chain OUTPUT (policy ACCEPT)
+target     prot opt source               destination         
+convex# 
+</pre>
+
+The other difference is that the non-working machine is using IPv6 and IPv4, while the working machine is just IPv4
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_3_d83330ad40f4f2c2c55f29acf6680620._comment b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_3_d83330ad40f4f2c2c55f29acf6680620._comment
new file mode 100644
index 0000000000..7526fc8e6e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_3_d83330ad40f4f2c2c55f29acf6680620._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="comment 3"
+ date="2018-09-24T09:03:13Z"
+ content="""
+I'm seeing this bug, too. It happens between my laptop, which is also running 6.20180913-1, and two servers which both run 6.20170101-1+deb9u2. One of the servers is remote, while the other one is on my local network.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_4_129a1946d7c76b89ae2f45b8a804959f._comment b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_4_129a1946d7c76b89ae2f45b8a804959f._comment
new file mode 100644
index 0000000000..158800bcee
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_4_129a1946d7c76b89ae2f45b8a804959f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="downgrading helped! "
+ date="2018-09-24T17:56:42Z"
+ content="""
+Downgrading (testing on local laptop) local git-annex all the way down (didn't try intermediates yet) to 6.20170101-1+deb9u2  helped - I can fetch data from that server.
+
+My wild guess is that it all relates to the fact that remote git-annex-shell, being outdated, has no clue about `p2pstdio` command, and local new git-annex doesn't fall back anyhow to use some other way to transfer.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_4_1713d56b81db533db4532f2a79250c87._comment b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_4_1713d56b81db533db4532f2a79250c87._comment
new file mode 100644
index 0000000000..35eadd4a57
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_4_1713d56b81db533db4532f2a79250c87._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-09-24T18:37:08Z"
+ content="""
+The only new change in 6.20180913 that might somehow affect this is 
+[[!commit b18fb1e343e9654207fbebacf686659c75d0fb4c]]. But I don't see how
+it could really.
+
+Since ssh seems to be displaying a motd when running a noninteractive
+command, I think that git-annex must be seeing that motd where it
+expects to see the P2P protocol.
+
+Although it may be that ssh -T avoids the motd display. (But unfortunately
+your transcript using -T trims out exactly that part!) I didn't think ssh
+normally displays motd when not running a login shell. Perhaps it's
+something to do with your shell and not ssh.
+
+git-annex will fall back to not using p2pstdio, but only if the command
+exits nonzero without ssh sending anything to stdout.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_5_a14f999b63905c1f29999bd68ded42f2._comment b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_5_a14f999b63905c1f29999bd68ded42f2._comment
new file mode 100644
index 0000000000..239e4e32fd
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_5_a14f999b63905c1f29999bd68ded42f2._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2018-09-24T18:05:15Z"
+ content="""
+FWIW, here is what I see if I just try to invoke directly
+[[!format sh \"\"\"
+$> ssh bids@rolando.cns -T git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba8f2cea-f229-422c-82be-6580e5e07ed5' --uuid 6384a551-a41d-4290-b186-9258befede97 
+...
+fatal: Run with no arguments or with -c cmd
+git-annex-shell: git-shell failed
+1 5358 ->1
+\"\"\"]]
+so - exit code is `1` (happen annex decides on exit code about availability of p2pstdio)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_7_31ecf1c31511e6454a274e3c9a9bef75._comment b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_7_31ecf1c31511e6454a274e3c9a9bef75._comment
new file mode 100644
index 0000000000..e7aa3c6b99
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_7_31ecf1c31511e6454a274e3c9a9bef75._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2018-09-25T16:15:54Z"
+ content="""
+indeed I do have /etc/issue (not motd) displayed even when with -T:
+
+[[!format sh \"\"\"
+
+        $> ssh bids@rolando.cns -T git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba8f2cea-f229-422c-82be-6580e5e07ed5' --uuid 6384a551-a41d-4290-b186-9258befede97
+
+
+                Dartmouth College, Department of Psychological and Brain Sciences
+                                                  Authorized access only
+
+
+
+
+        fatal: Run with no arguments or with -c cmd
+        git-annex-shell: git-shell failed
+        1 5383 ->1
+
+\"\"\"]]
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_8_3aecc3467427b4ebecbd53012e111004._comment b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_8_3aecc3467427b4ebecbd53012e111004._comment
new file mode 100644
index 0000000000..8df2246133
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_8_3aecc3467427b4ebecbd53012e111004._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 8"
+ date="2018-09-25T16:18:58Z"
+ content="""
+replicated on another host with a VERY outdated annex (5.20141125), but where there is no issue or motd:
+[[!format sh \"\"\"
+$> git annex get --debug 1
+[2018-09-25 12:17:02.454369526] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"1\"]
+get 1 [2018-09-25 12:17:02.463349835] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2018-09-25 12:17:02.467436881] process done ExitSuccess
+[2018-09-25 12:17:02.467538938] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-09-25 12:17:02.471371867] process done ExitSuccess
+[2018-09-25 12:17:02.471566695] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..70d4b5032ee0c3d4de499d650c71bdb0d55d2dee\",\"--pretty=%H\",\"-n1\"]
+[2018-09-25 12:17:02.476070612] process done ExitSuccess
+[2018-09-25 12:17:02.476399866] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-09-25 12:17:02.477000311] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+(from origin...) 
+[2018-09-25 12:17:02.484004025] chat: ssh [\"washoe\",\"-S\",\".git/annex/ssh/washoe\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/tmp/repo' '--debug' '84085bc4-d338-41eb-be4d-9b0d96536860' --uuid f6bedfe8-0e58-4182-bca3-764c5c3ed17b\"]
+[2018-09-25 12:17:02.695407743] P2P > ERROR auth failed
+
+  fd:19: hClose: resource vanished (Broken pipe)
+
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+  	f6bedfe8-0e58-4182-bca3-764c5c3ed17b -- yoh@washoe:/tmp/repo [origin]
+failed
+[2018-09-25 12:17:02.699113109] read: ssh [\"-O\",\"stop\",\"-S\",\"washoe\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"localhost\"]
+[2018-09-25 12:17:02.709050558] process done ExitSuccess
+[2018-09-25 12:17:02.709515542] process done ExitSuccess
+[2018-09-25 12:17:02.710090983] process done ExitSuccess
+git-annex: get: 1 failed
+
+$> ssh washoe -T git-annex-shell 'p2pstdio' '/inbox/BIDS/dbic/QA' '--debug' 'ba8f2cea-f229-422c-82be-6580e5e07ed5' --uuid 6384a551-a41d-4290-b186-9258befede97       
+fatal: Run with no arguments or with -c cmd
+git-annex-shell: git-shell failed
+
+\"\"\"]]
+so I think it is incorrectly handles this failure and doesn't fall back to ssh/rsync.  nothing to do with motd/issue
+"""]]
diff --git a/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_9_dfb1b7ee4e674cf18d6f41e4f4b6c879._comment b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_9_dfb1b7ee4e674cf18d6f41e4f4b6c879._comment
new file mode 100644
index 0000000000..024d71f740
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_9_dfb1b7ee4e674cf18d6f41e4f4b6c879._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2018-09-25T16:37:53Z"
+ content="""
+I tried configuring sshd with PrintMotd yes, that actually resulted in
+double motd on interactive login, but still none on noninteractive login,
+and doesn't cause this problem.
+
+I tried making ~/.bashrc echo some stuff. That also didn't reproduce the
+problem, though debug does have this:
+
+	[2018-09-25 12:40:18.092800592] P2P > ERROR auth failed
+
+It does not give up, but goes on to use rsync. Although rsync unsurprisingly 
+also fails "protocol version mismatch -- is your shell clean?".
+
+Still, this seems to indicate that the motd display shown in your transcripts is
+at the root of the problem, although I've not fully replicated the circumstances
+and will need more information to get further on this.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock.mdwn b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock.mdwn
new file mode 100644
index 0000000000..101c0ae84b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock.mdwn
@@ -0,0 +1,43 @@
+### Please describe the problem.
+
+Ideally annex should detect all "paranormal" cases such as running on NFS mounted partition, but according to [https://git-annex.branchable.com/bugs/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/](https://git-annex.branchable.com/bugs/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/).  Happily ignorant we were running annex (5.20151116-g76139a9) on NFS mounted partition until we filled up 2TB of allocated to us space with .nfs* files.  Well -- apparently according to above we should have tried pidlock... trying now but doesn't work :-/
+
+[[!format sh """
+*$> git clone smaug:/tmp/123 123-clone && cd 123-clone && git config annex.pidlock true && echo 124 > 124.dat && git annex add 124.dat && git commit -m 'added 124' && git annex move --to=origin 124.dat
+Initialized empty Git repository in /home/yhalchen/123-clone/.git/
+remote: Counting objects: 22, done.
+remote: Compressing objects: 100% (16/16), done.
+remote: Total 22 (delta 3), reused 0 (delta 0)
+Receiving objects: 100% (22/22), done.
+Resolving deltas: 100% (3/3), done.
+total 1
+1 123.dat@  1 README.txt
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+add 124.dat ok
+(recording state in git...)
+[master 0f1092a] added 124
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+ create mode 120000 124.dat
+move 124.dat (checking origin...) git-annex: content is locked
+
+$> echo $?
+1
+
+"""]]
+
+BTW running move in our old now somewhat screwed up annex, results in a differently expressed error: [http://www.onerussian.com/tmp/2016-02-29.png](http://www.onerussian.com/tmp/2016-02-29.png)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> Looks to me like I fixed the reported problem 3 years ago, in
+> [[!commit 1a8ba7eab4677be18fef5d6e1c2e59607594c446]].
+> 
+> That fix was never confirmed to work, but I see no reason why it
+> wouldn't, so if it didn't please reopen. [[done]]
+>
+> (As far as detecting nfs and enabling pidlock, 
+> there is
+> <https://git-annex.branchable.com/bugs/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/>)
+> --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_10_d44de6a250694b25ce9c3169d62db8d1._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_10_d44de6a250694b25ce9c3169d62db8d1._comment
new file mode 100644
index 0000000000..f2ba4335c7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_10_d44de6a250694b25ce9c3169d62db8d1._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2016-03-01T20:52:38Z"
+ content="""
+	2456732 openat(AT_FDCWD, ".git/annex/ssh/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	2456732 mkdir(".git/annex/ssh", 0777)   = 0
+	2456732 open(".git/annex/ssh/smaug.lock", O_RDONLY|O_CREAT, 0666) = 11
+	2456732 fcntl(11, F_GETFD)              = 0
+	2456732 fcntl(11, F_SETFD, FD_CLOEXEC)  = 0
+	2456732 close(11)                       = 0
+
+Backs up what I thought git-annex should be doing; it's not fcntl locking that file.
+
+Ah, I'll bet it's not git-annex at all this time.
+It runs ssh with -S .git/annex/ssh/smaug, and ssh probably
+does its own locking around setting up that control socket.
+
+If so, disabling annex.sshcaching will avoid the problem.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_11_56ae0f15bbdea2331df3b261b74d0b0b._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_11_56ae0f15bbdea2331df3b261b74d0b0b._comment
new file mode 100644
index 0000000000..2ee2e6aa86
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_11_56ae0f15bbdea2331df3b261b74d0b0b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 11"
+ date="2016-03-01T22:40:44Z"
+ content="""
+would then may be annex not to use sshcaching if operating under pidlock, unless some nfs specific flag is used to tease it apart
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_12_d499a2f44e8ee2f39ee959f4d6373570._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_12_d499a2f44e8ee2f39ee959f4d6373570._comment
new file mode 100644
index 0000000000..5ab7c9e118
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_12_d499a2f44e8ee2f39ee959f4d6373570._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 12"
+ date="2016-03-10T04:36:12Z"
+ content="""
+so -- shouldn't annex at least upon init sense if repo is under nfs?  if to be done platform independent way then it could do smth like
+
+[[!format sh \"\"\"
+python -c 'from glob import glob; import os; f=open(\".tmp-test\", \"w\"); os.unlink(\".tmp-test\"); assert(not glob(\".nfs*\"))'
+\"\"\"]]
+
+somewhere under .git/annex/tmp .. so if .nfs* file gets generated -- under nfs.  Seems to work for me in limited set of tests -- assertion fails all the time under NFS ;)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_13_05687dca2462eb79872879bd7695d665._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_13_05687dca2462eb79872879bd7695d665._comment
new file mode 100644
index 0000000000..64df7bc578
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_13_05687dca2462eb79872879bd7695d665._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2016-10-26T16:34:38Z"
+ content="""
+Looking at the strace finally...
+
+Here's git-annex creating the dummy posix lock file, soon after
+the ssh socket is removed. (I think that's ssh removing the socket before,
+but the jumble of strace output is hard to follow here.)
+
+	2456732 unlink(".git/annex/ssh/smaug" <unfinished ...>
+	...
+	2456732 open(".git/annex/ssh/.nfs00000000099d85d000000002.lock", O_RDONLY|O_CREAT, 0666 <unfinished ...>
+
+And later ssh is told to stop using a related socket:
+
+	2456815 execve("/mnt/btrfs/scrap/datalad/test_nfs/git-annex.linux/bin/ssh", ["ssh", "-O", "stop", "-S", ".nfs00000000099d85d000000002", "-o", "ControlMaster=auto", "-o", "ControlPersist=yes", "localhost"], [/* 98 vars */] <unfinished ...>
+
+Which it seems does not exist by then:
+
+	2456815 connect(3, {sa_family=AF_LOCAL, sun_path=".nfs00000000099d85d000000002"}, 31) = -1 ENOENT (No such file or directory)
+	2456732 unlink(".git/annex/ssh/.nfs00000000099d85d000000002") = -1 ENOENT (No such file or directory)
+
+Seems like this would have to be `sshCleanup` running, and `enumSocketFiles`
+seeing ".nfs00000000099d85d000000002" existing at that point due
+probably to the ssh/smaug socket being in the process of being
+removed. 
+
+So, it assumes it's a socket file and tries to clean it up, creating
+the dummy posix lock file. And posix lock files don't get deleted
+(it's impossible to do so in a race-free way), so this results in more
+and more `.nfs*.lock` files.
+
+Need to find a way to prevent `enumSocketFiles` from listing these
+files. Seems that ".nfs00000000099d85d000000002" is probably the deleted
+form of the "smaug" socket, so it really is a socket file, so checking
+if a file is a socket won't help. Of course it could
+ explicitly filter out ".nfs" prefixed files. That could be a case of
+kicking the can down the road, since NFS could always choose to use
+another name for these files.
+
+Hmm.. Before a ssh socket file gets created, git-annex always locks the
+associated lock file. And as noted, the posix lock file is never
+removed. (On Windows the lock file is also created and never deleted.) 
+So, if $file does not have an associated $file.lock 
+then $file must not be a ssh socket, and `enumSocketFiles` can skip it.
+
+I've added that check. Unable to test it because the NFS mount has
+been lost in the intervening time. @yoh can you test this fixed it?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_14_cb1df663b03f3ce9cb27e311e5a70198._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_14_cb1df663b03f3ce9cb27e311e5a70198._comment
new file mode 100644
index 0000000000..42dad95c4b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_14_cb1df663b03f3ce9cb27e311e5a70198._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2016-10-26T17:19:39Z"
+ content="""
+Re detecting NFS, I'm not sure that ".nfs" files are always used for
+deleted files by all NFS configurations. And, there are probably NFS
+configurations that do properly support Posix locks, and others that
+don't. So connecting a check for ".nfs" files with turning on
+annex.pidlock seems problimatic.
+
+If we had a good way to detect systems that don't support Posix locks,
+annex.pidlock could be auto-enabled. But for some reason embedding a large
+portion of a Posix test suite into git-annex does not fill me with joy.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_1_a98a54c04fa4e81f35fe958e746d61cb._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_1_a98a54c04fa4e81f35fe958e746d61cb._comment
new file mode 100644
index 0000000000..21304e2e8b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_1_a98a54c04fa4e81f35fe958e746d61cb._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-03-01T14:36:25Z"
+ content="""
+FYI, I think you could remove the .nfs files to free up space.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_2_18169e7bbd2caba5ee4bb0286961ac95._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_2_18169e7bbd2caba5ee4bb0286961ac95._comment
new file mode 100644
index 0000000000..42b3265bd8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_2_18169e7bbd2caba5ee4bb0286961ac95._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-03-01T15:35:48Z"
+ content="""
+Oddly, I cannot reproduce this, although I can reproduce the behavior in
+<http://git-annex.branchable.com/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone/>a
+
+(smaug:/tmp/123 has permissions that do not let me access it.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_3_e3b623ff6714a9fe5fa0d332c72fe32f._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_3_e3b623ff6714a9fe5fa0d332c72fe32f._comment
new file mode 100644
index 0000000000..51f71c7ac8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_3_e3b623ff6714a9fe5fa0d332c72fe32f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-03-01T16:52:16Z"
+ content="""
+I've fixed the STM transaction bug. Need either more info to reproduce this
+bug, or you could test and see if it still occurs when git-annex is
+upgraded to ad888a6b760e8f9d31f8d99c51912bcdaa7fb0c1
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_4_58eebd8cfd664b32ef6fd0ddc34c5e86._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_4_58eebd8cfd664b32ef6fd0ddc34c5e86._comment
new file mode 100644
index 0000000000..7a562f7efc
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_4_58eebd8cfd664b32ef6fd0ddc34c5e86._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="more info"
+ date="2016-03-01T17:31:29Z"
+ content="""
+If we could remove those .nfs* files, it would indeed be not that bad  but we can't
+
+smaug:/tmp/123 -- sorry about permissions but it is a regular annex nothing special, so the bug should show itself with other repos as well I think.  I gave you access to it now and also there is /tmp/123.tar.gz archive of it just in case.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_5_e5e24428ac02b78d38cd4f197ae3807b._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_5_e5e24428ac02b78d38cd4f197ae3807b._comment
new file mode 100644
index 0000000000..75a45bdad1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_5_e5e24428ac02b78d38cd4f197ae3807b._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="recent snapshot seems has fixed it"
+ date="2016-03-01T18:52:27Z"
+ content="""
+[[!format sh \"\"\"
+$> git clone smaug:/tmp/123 123-clone && cd 123-clone && git config annex.pidlock true && echo 124 > 124.dat && git annex add 124.dat && git commit -m 'added 124' && git annex move --to=origin 124.dat
+Cloning into '123-clone'...
+remote: Counting objects: 22, done.
+remote: Compressing objects: 100% (16/16), done.
+remote: Total 22 (delta 3), reused 0 (delta 0)
+Receiving objects: 100% (22/22), done.
+Resolving deltas: 100% (3/3), done.
+Checking connectivity... done.
+total 1
+1 123.dat@  1 README.txt
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+add 124.dat ok
+(recording state in git...)
+[master 6eca577] added 124
+ 1 file changed, 1 insertion(+)
+ create mode 120000 124.dat
+move 124.dat (checking origin...) ok
+(recording state in git...)
+
+$> git annex version
+git-annex version: 6.20160301+gitg647fffd-1~ndall+1
+
+\"\"\"]]
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_6_01dc7a1ff67783ce672d72cefe7b4bb5._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_6_01dc7a1ff67783ce672d72cefe7b4bb5._comment
new file mode 100644
index 0000000000..20eca2f62f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_6_01dc7a1ff67783ce672d72cefe7b4bb5._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 6"
+ date="2016-03-01T18:54:15Z"
+ content="""
+but then I found   ./.git/annex/ssh/.nfs000000000000f41600003608.lock left behind (removable, luckily to me ;) )
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_7_458518805b8d6613930b38b9ccc3c1bc._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_7_458518805b8d6613930b38b9ccc3c1bc._comment
new file mode 100644
index 0000000000..756b642500
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_7_458518805b8d6613930b38b9ccc3c1bc._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 7"
+ date="2016-03-01T18:58:20Z"
+ content="""
+and those are breeding with next subsequent --move
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_8_853bc273b19bd6d84ca8f5da6c3dfb56._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_8_853bc273b19bd6d84ca8f5da6c3dfb56._comment
new file mode 100644
index 0000000000..d24d78d513
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_8_853bc273b19bd6d84ca8f5da6c3dfb56._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2016-03-01T20:17:35Z"
+ content="""
+That ssh lock file is created by this code:
+
+	-- The posix lock file is created even when using pid locks, in order to
+	-- avoid complicating any code that might expect to be able to see that
+	-- lock file. But, it's not locked.
+	dummyPosixLock :: Maybe FileMode -> LockFile -> IO ()
+	dummyPosixLock m f = closeFd =<< openLockFile ReadLock m f
+
+But, that does not ever actually take a lock on the file, so
+NFS should not make its .nfs thing in this case. Unless NFS does it when a
+FD is simply opened with close-on-exec set. 
+
+Can you get a strace of the creation of files under .git/annex/ssh/
+that result in these .nfs things?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_9_86656a409ab25c7fa24de8ac3e68b254._comment b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_9_86656a409ab25c7fa24de8ac3e68b254._comment
new file mode 100644
index 0000000000..b862174b15
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex__58___content_is_locked__while_trying_to_move_under_NFS_and_pidlock/comment_9_86656a409ab25c7fa24de8ac3e68b254._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 9"
+ date="2016-03-01T20:43:17Z"
+ content="""
+ok -- see on smaug /mnt/nfs/scrap/datalad/test_nfs/123-clone-move.strace  .  Now you can experiment there as well -- the entire /mnt/btrfs/scrap is mounted also via nfs (under /mnt/nfs/scrap)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist.mdwn b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist.mdwn
new file mode 100644
index 0000000000..4235bf3998
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist.mdwn
@@ -0,0 +1,35 @@
+### Please describe the problem.
+
+A `git-annex get` fails with `createDirectory: does not exist (No such file or directory)` on MacOSX.
+
+### What steps will reproduce the problem?
+
+I can trigger the condition as part of a CI run of the DataLad test suite. Here is an example
+run that shows the failure: https://ci.appveyor.com/project/mih/datalad/build/job/k5u263619e6erk8t
+However, the exact conditions required to trigger the issue are not yet known (c.f. https://github.com/datalad/datalad/issues/5291).
+
+A protocol of an exploration of this issue with debug output is here: https://github.com/datalad/datalad/issues/5301#issuecomment-757467813
+
+In this end I can trigger the error with a `mkdir` performed manually in the shell using the path reported by git-annex (e.g. `../../../../../../../var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex/`). But a `mkdir` is successful using a "normalized variant of the path
+pointing to the same physical directory (e.g. `/var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex`).
+
+I do not understand enough of this platform to understand what is happening, but it seems that some of these folders actually live in `/private/var`, despite being accessible via `/var`, but I do not see how `mkdir` would error on a relative path and succeed on an absolute one.
+
+
+### What version of git-annex are you using? On what operating system?
+
+8.20201129 on darwin/19.6.0 10.15.7/x86_64
+
+More system details are here https://ci.appveyor.com/project/mih/datalad/build/job/k5u263619e6erk8t#L422
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git-annex is critical infrastructure for me. There is no day without it. Thx much!
+
+
+[[!tag projects/datalad]]
+
+> So there's an OSX bug here, and git-annex has been made to use
+> an absolute path to a remote when it has one, which can be used to work
+> around the OSX bug. [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_1_88439da4b9df6e07aa0300700b66d910._comment b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_1_88439da4b9df6e07aa0300700b66d910._comment
new file mode 100644
index 0000000000..324a2fbe73
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_1_88439da4b9df6e07aa0300700b66d910._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="michael.hanke@c60e12358aa3fc6060531bdead1f530ac4d582ec"
+ nickname="michael.hanke"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Specific to repository location in /private"
+ date="2021-01-10T16:10:42Z"
+ content="""
+The issue goes away, when I place the directory in which repositories are created into the user's HOME directory (instead of `/tmp`, which maps to some place under `/private`).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_2_020d7c6292c2a8238a5ec891fba9eddd._comment b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_2_020d7c6292c2a8238a5ec891fba9eddd._comment
new file mode 100644
index 0000000000..83eacb503e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_2_020d7c6292c2a8238a5ec891fba9eddd._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-01-13T16:32:06Z"
+ content="""
+Is the relative path actually valid? There may be some case involving
+symlinks in the parent directories where the relative path could be wrong.
+This part seems to suggest there are symlinks involved:
+
+> some of these folders actually live in /private/var, despite being accessible via /var
+
+Of course, it's a bit surprising that a relative path is used when the path
+is into an entirely different top-level directory. But without
+understanding the problem I don't know if switching to using an absolute
+path in that case would only happen to fix this case of the problem and not
+the general case, whatever that is.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_3_f533ffdb2b37f98094fc7633cd686e5c._comment b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_3_f533ffdb2b37f98094fc7633cd686e5c._comment
new file mode 100644
index 0000000000..f3eaee6d9a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_3_f533ffdb2b37f98094fc7633cd686e5c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-01-13T16:57:10Z"
+ content="""
+Also it seems common for directories under /var/folders/xx/yyyyy/ to be
+mode 700, so it could somehow involve permissions.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_4_301ac4a37a0f2da6b9c394509a369484._comment b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_4_301ac4a37a0f2da6b9c394509a369484._comment
new file mode 100644
index 0000000000..501afa9f54
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_4_301ac4a37a0f2da6b9c394509a369484._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="comment 4"
+ date="2021-01-15T08:32:58Z"
+ content="""
+> Is the relative path actually valid?
+
+As far as I can tell, it is.
+
+```
+(venv3.8.6) worker-629-003:datalad_temp_test_basic_scenariocm66i4fm appveyor$ ls -id ../../../../../../../var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex /var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex
+12889649026 ../../../../../../../var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex
+12889649026 /var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex
+```
+
+I cannot come up with an explanation, for the consistent behavior of `ls`, but not `mkdir` for a relative path vs. an absolute path.
+
+```
+(venv3.8.6) worker-629-003:datalad_temp_test_basic_scenariocm66i4fm appveyor$ mkdir ../../../../../../../var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex/testdummy
+mkdir: ../../../../../../../var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex: No such file or directory
+
+(venv3.8.6) worker-629-003:datalad_temp_test_basic_scenariocm66i4fm appveyor$ mkdir /var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex/testdummy
+-> exit 0
+```
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_5_f2a25cca5d72ce1dcecf36c2780abec2._comment b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_5_f2a25cca5d72ce1dcecf36c2780abec2._comment
new file mode 100644
index 0000000000..c2cf84be00
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_5_f2a25cca5d72ce1dcecf36c2780abec2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-01-18T17:29:12Z"
+ content="""
+I can't see how git-annex can work around this, unless someone finds an
+explanation for the OS's behavior.
+
+I think you've clearly shown it's not a git-annex bug, since other mkdir()
+calls behave the same way. And that seems to point squarely at an OS bug.
+
+(Unless .git/annex was itself a dangling symlink, then ls would be able to
+list it, but mkdir would fail like that.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_6_b8f96a403990a125bf181f0ce8bea44e._comment b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_6_b8f96a403990a125bf181f0ce8bea44e._comment
new file mode 100644
index 0000000000..94431144a4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_6_b8f96a403990a125bf181f0ce8bea44e._comment
@@ -0,0 +1,72 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="why relative path?"
+ date="2021-02-08T14:47:42Z"
+ content="""
+I feel it is OS (OSX bug), does not reproduce on newer 11.1 (appveyor has 10.15.7), [asked on SO](https://stackoverflow.com/questions/66103552/osx-mkdir-tmp-dir-no-such-file-or-directory-under-private-while-ls-can-l) anyways with minimalistic example.  I believe it is the `tmp -> private/tmp` somehow throws it off.
+
+<details>
+<summary>But I also wonder why git-annex uses relative path for get whenever remote is specified via an absolute one?</summary>
+
+```shell
+bash-3.2$ cd /private/var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_test_get_recurse_dirs7eiohcer
+bash-3.2$ cat .git/config
+[core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = false
+        logallrefupdates = true
+        ignorecase = true
+        precomposeunicode = true
+[remote \\"origin\\"]
+        url = /var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_get_recurse_dirsfciy781u
+        fetch = +refs/heads/*:refs/remotes/origin/*
+        annex-uuid = 52043a4d-fab3-4661-a8aa-904cd780c804
+[branch \\"dl-test-branch\\"]
+        remote = origin
+        merge = refs/heads/dl-test-branch
+[annex \\"security\\"]
+        allowed-url-schemes = http https file
+        allowed-http-addresses = all
+[annex]
+        uuid = f40f35d9-cd79-4258-9f25-bdeb56303f94
+        version = 8
+[filter \\"annex\\"]
+        smudge = git-annex smudge -- %f
+        clean = git-annex smudge --clean -- %f
+bash-3.2$ git annex get --debug --from origin subdir/file2.txt
+[2021-02-08 08:37:39.159007] process [10170] read: git [\\"--git-dir=.git\\",\\"--work-tree=.\\",\\"--literal-pathspecs\\",\\"show-ref\\",\\"git-annex\\"]
+[2021-02-08 08:37:39.164531] process [10170] done ExitSuccess
+[2021-02-08 08:37:39.165453] process [10171] read: git [\\"--git-dir=.git\\",\\"--work-tree=.\\",\\"--literal-pathspecs\\",\\"show-ref\\",\\"--hash\\",\\"refs/heads/git-annex\\"]
+[2021-02-08 08:37:39.169315] process [10171] done ExitSuccess
+[2021-02-08 08:37:39.170596] process [10172] read: git [\\"--git-dir=.git\\",\\"--work-tree=.\\",\\"--literal-pathspecs\\",\\"log\\",\\"refs/heads/git-annex..250f87f912fab3d2081ef0ccd02ffc35fd7a97a7\\",\\"--pretty=%H\\",\\"-n1\\"]
+[2021-02-08 08:37:39.177178] process [10172] done ExitSuccess
+[2021-02-08 08:37:39.178303] process [10173] chat: git [\\"--git-dir=.git\\",\\"--work-tree=.\\",\\"--literal-pathspecs\\",\\"cat-file\\",\\"--batch\\"]
+[2021-02-08 08:37:39.179112] process [10174] chat: git [\\"--git-dir=.git\\",\\"--work-tree=.\\",\\"--literal-pathspecs\\",\\"cat-file\\",\\"--batch-check=%(objectname) %(objecttype) %(objectsize)\\"]
+[2021-02-08 08:37:39.183428] process [10175] read: git [\\"config\\",\\"--null\\",\\"--list\\"]
+[2021-02-08 08:37:39.188091] process [10175] done ExitSuccess
+[2021-02-08 08:37:39.195372] process [10176] read: git [\\"--git-dir=.git\\",\\"--work-tree=.\\",\\"--literal-pathspecs\\",\\"symbolic-ref\\",\\"-q\\",\\"HEAD\\"]
+[2021-02-08 08:37:39.198517] process [10176] done ExitSuccess
+[2021-02-08 08:37:39.199328] process [10177] read: git [\\"--git-dir=.git\\",\\"--work-tree=.\\",\\"--literal-pathspecs\\",\\"show-ref\\",\\"refs/heads/dl-test-branch\\"]
+[2021-02-08 08:37:39.202993] process [10177] done ExitSuccess
+[2021-02-08 08:37:39.20432] process [10178] read: git [\\"--git-dir=.git\\",\\"--work-tree=.\\",\\"--literal-pathspecs\\",\\"ls-files\\",\\"--stage\\",\\"-z\\",\\"--\\",\\"subdir/file2.txt\\"]
+[2021-02-08 08:37:39.205302] process [10179] chat: git [\\"--git-dir=.git\\",\\"--work-tree=.\\",\\"--literal-pathspecs\\",\\"cat-file\\",\\"--batch-check=%(objectname) %(objecttype) %(objectsize)\\",\\"--buffer\\"]
+[2021-02-08 08:37:39.208369] process [10180] chat: git [\\"--git-dir=.git\\",\\"--work-tree=.\\",\\"--literal-pathspecs\\",\\"cat-file\\",\\"--batch=%(objectname) %(objecttype) %(objectsize)\\",\\"--buffer\\"]
+[2021-02-08 08:37:39.209513] process [10181] chat: git [\\"--git-dir=.git\\",\\"--work-tree=.\\",\\"--literal-pathspecs\\",\\"cat-file\\",\\"--batch=%(objectname) %(objecttype) %(objectsize)\\",\\"--buffer\\"]
+get subdir/file2.txt (from origin...)
+  ../../../../../../../var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_get_recurse_dirsfciy781u/.git/annex: createDirectory: does not exist (No such file or directory)
+failed
+[2021-02-08 08:37:39.218675] process [10181] done ExitSuccess
+[2021-02-08 08:37:39.218748] process [10180] done ExitSuccess
+[2021-02-08 08:37:39.218781] process [10179] done ExitSuccess
+[2021-02-08 08:37:39.218806] process [10178] done ExitSuccess
+git-annex: get: 1 failed
+
+```
+</details>
+
+IIRC it might have been done to minimize the path length so we have a better chance to not hit limits.  But in this case, if anything - it makes it only longer.
+
+PS initially posted with another \"wisdom\" that relative path was off but only then spotted that it was `/var` vs `/private/var` ;)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_7_2899ef72aa2a5488eb945d14f7a2d76e._comment b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_7_2899ef72aa2a5488eb945d14f7a2d76e._comment
new file mode 100644
index 0000000000..fc367bb9c9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex_get__58___createDirectory__58___does_not_exist/comment_7_2899ef72aa2a5488eb945d14f7a2d76e._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-02-08T15:54:58Z"
+ content="""
+Agreed, what you show in the stackoverflow post can only be an OSX bug.
+
+Using a relative path for the current repository does avoid using long
+absolute paths, and also has a minor benefit of letting the repository be
+moved while git-annex is running and it still accessing the right files.
+
+Neither benefit applies to the paths to remotes. I think the only
+reason relative paths are being used for them is that the same code
+is used to operate on them as on the local repository.
+
+I've made some changes that will make it use absolute paths when the
+remote has an absolute path.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex_looses_itself_on_Windows__63__.mdwn b/doc/projects/datalad/bugs-done/git-annex_looses_itself_on_Windows__63__.mdwn
new file mode 100644
index 0000000000..5d874fe142
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex_looses_itself_on_Windows__63__.mdwn
@@ -0,0 +1,43 @@
+Well, I know that my setup is "experimental" - I am trying to establish consistent `conda` environment, ATM everything (`git` and all the `posix` tools) come from conda (conda-forge channel at large) and then git-annex is installed on top - pretty much simply extracted into conda environment from our git-annex-installer.exe built with magic.
+
+Running (in a windows shell, so not in bash)
+
+```
+(datalad-2) C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_hufbz7i1>git add --verbose "fi le2.dat"
+git-annex smudge --clean -- 'fi le2.dat': git-annex: command not found
+error: external filter 'git-annex smudge --clean -- %f' failed 127
+error: external filter 'git-annex smudge --clean -- %f' failed
+add 'fi le2.dat'
+
+```
+
+suggests that `git` does see `git-annex`, but then `git-annex smudge` doesn't see `git-annex` in the PATH?
+
+```
+(datalad-2) C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_hufbz7i1>echo %PATH%
+C:\Users\DataLad\miniconda3\envs\datalad-2;C:\Users\DataLad\miniconda3\envs\datalad-2\Library\mingw-w64\bin;C:\Users\DataLad\miniconda3\envs\datalad-2\Library\usr\bin;C:\Users\DataLad\miniconda3\envs\datalad-2\Library\bin;C:\Users\DataLad\miniconda3\envs\datalad-2\Scripts;C:\Users\DataLad\miniconda3\envs\datalad-2\bin;C:\Users\DataLad\miniconda3\condabin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program Files\Git\cmd;C:\Users\DataLad\AppData\Local\Microsoft\WindowsApps;.
+```
+
+and there is `C:\Users\DataLad\miniconda3\envs\datalad-2\Library\bin\git-annex.exe` .
+
+<details>
+<summary>git annex version</summary> 
+
+```shell
+(datalad-2) C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_hufbz7i1>git annex version
+git-annex version: 8.20201008-g3be4731
+build flags: Assistant Webapp Pairing TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso hook external
+operating system: mingw32 x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 2 3 4 5 6 7
+local repository version: 8
+```
+</details>
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/git-annex_looses_itself_on_Windows__63__/comment_1_e809445ff0109d8aa98093b024b3b35c._comment b/doc/projects/datalad/bugs-done/git-annex_looses_itself_on_Windows__63__/comment_1_e809445ff0109d8aa98093b024b3b35c._comment
new file mode 100644
index 0000000000..c2e0e652ed
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex_looses_itself_on_Windows__63__/comment_1_e809445ff0109d8aa98093b024b3b35c._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2020-10-27T19:44:36Z"
+ content="""
+probably nevermind and feel free to close -- something is finicky with the `bash` which I have
+
+```
+(datalad-2) C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_hufbz7i1>bash -c \"git-annex version\"
+bash: git-annex: command not found
+```
+
+need to figure that out
+
+```
+(datalad-2) C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_hufbz7i1>echo %PATH%
+C:\Users\DataLad\miniconda3\envs\datalad-2;C:\Users\DataLad\miniconda3\envs\datalad-2\Library\mingw-w64\bin;C:\Users\DataLad\miniconda3\envs\datalad-2\Library\usr\bin;C:\Users\DataLad\miniconda3\envs\datalad-2\Library\bin;C:\Users\DataLad\miniconda3\envs\datalad-2\Scripts;C:\Users\DataLad\miniconda3\envs\datalad-2\bin;C:\Users\DataLad\miniconda3\condabin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program Files\Git\cmd;C:\Users\DataLad\AppData\Local\Microsoft\WindowsApps;.
+
+(datalad-2) C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_hufbz7i1>bash -c \"echo $PATH\"
+/c/Users/DataLad/miniconda3/envs/datalad-2:/mingw-w64/bin:/usr/bin:/bin:/c/Users/DataLad/miniconda3/envs/datalad-2/Scripts:/c/Users/DataLad/miniconda3/envs/datalad-2/bin:/c/Users/DataLad/miniconda3/condabin:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:/c/Windows/System32/OpenSSH:/c/Program Files/Git/cmd:/c/Users/DataLad/AppData/Local/Microsoft/WindowsApps:.
+```
+so it seems to discard `C:\Users\DataLad\miniconda3\envs\datalad-2\Library\bin`, may be I should not \"install\" there ;) (but it also looses `conda` itself in that `bash` \"shell\")
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git-annex_no_longer_provides_remote_name_with_GETCONFIG_name.mdwn b/doc/projects/datalad/bugs-done/git-annex_no_longer_provides_remote_name_with_GETCONFIG_name.mdwn
new file mode 100644
index 0000000000..ef50c87a94
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex_no_longer_provides_remote_name_with_GETCONFIG_name.mdwn
@@ -0,0 +1,21 @@
+### Please describe the problem.
+
+A special remote implementation that needs to look up further config based on the remote name no longer works, because a recent change prevents `GETCONFIG name` to return the remote name while `git annex initremote` is driving the special remote implementation.
+
+
+### What version of git-annex are you using? On what operating system?
+
+It used to work with 7.20191230 and no longer does with 8.20200226, test on Debian and Ubuntu.
+
+### Please provide any additional information below.
+
+Originally reported at https://github.com/datalad/datalad/issues/4259
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+There is no day that ends without me being grateful for git-annex ;-)
+
+[[!meta author=mih]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/git-annex_no_longer_provides_remote_name_with_GETCONFIG_name/comment_1_005fd5bb4e8a025f1b15c7bf5f22d2c5._comment b/doc/projects/datalad/bugs-done/git-annex_no_longer_provides_remote_name_with_GETCONFIG_name/comment_1_005fd5bb4e8a025f1b15c7bf5f22d2c5._comment
new file mode 100644
index 0000000000..043107e3b4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git-annex_no_longer_provides_remote_name_with_GETCONFIG_name/comment_1_005fd5bb4e8a025f1b15c7bf5f22d2c5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-09T16:16:23Z"
+ content="""
+Hmm, I wonder if I was aware that any externals used GETCONFIG with things
+like name. Seems I might have heard about it at one point and forgotten?
+Reading the external protocol, it does say it's anything passed to
+initremote.
+
+I've fixed this. Release should happen by tomorrow.
+
+(I've also backported the fix to the 7.x branch.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend.mdwn b/doc/projects/datalad/bugs-done/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend.mdwn
new file mode 100644
index 0000000000..d78016339f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend.mdwn
@@ -0,0 +1,61 @@
+### Please describe the problem.
+
+Interestingly, on my first attempt I had two files which migrated from MD5 to MD5E backend, but may be I have done some steps differently which provoked also  also utils/test/test_data.tar.gz to get to the same destiny (actually later replicated on a fresh clone).
+I am also a bit confused why git diff reports change in the symlink if file is already a real file (I guess all the smudging magic)
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+(git)smaug:~exppsy/freesurfer-upstream2[master]git
+$> git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+nothing to commit, working directory clean
+
+$> git annex adjust --unlock
+adjust
+Checking out files: 100% (468/468), done.
+Switched to branch 'adjusted/master(unlocked)'
+ok
+git annex adjust --unlock  23.70s user 35.25s system 32% cpu 2:59.41 total
+changes on filesystem:
+ vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh | 2 +-
+
+$> git status
+On branch adjusted/master(unlocked)
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git checkout -- <file>..." to discard changes in working directory)
+
+        modified:   vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh
+
+no changes added to commit (use "git add" and/or "git commit -a")
+changes on filesystem:
+ vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh | 2 +-
+
+$> git diff
+diff --git a/vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh b/vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh
+index 9ea90d3..7bc0177 100644
+--- a/vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh
++++ b/vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh
+@@ -1 +1 @@
+-/annex/objects/SHA256-s655672--85f9b50e8fb8a72a8783152c7ad098c0600222256a7244ccd595cbe67b9ea949
++/annex/objects/SHA256E-s655672--85f9b50e8fb8a72a8783152c7ad098c0600222256a7244ccd595cbe67b9ea949.mgh
+changes on filesystem:
+ vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh | 2 +-
+
+$> ls -ld vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh
+-rw------- 1 yoh yoh 655672 Jun  1 23:28 vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh
+
+$> git annex version
+git-annex version: 6.20160523+gitg33c00ab-1~ndall+1
+
+"""]]
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__.mdwn b/doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__.mdwn
new file mode 100644
index 0000000000..53dd96d114
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__.mdwn
@@ -0,0 +1,49 @@
+### Please describe the problem.
+
+git annex info  crashes in some directories of the NFS mounted partition but not in the others
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+yoh@rolando:/inbox/BIDS/Meng/Meng/1005-faceperception$ git annex info
+
+git-annex: waitToSetLock: resource exhausted (No locks available)
+failed
+git-annex: info: 1 failed
+yoh@rolando:/inbox/BIDS/Meng/Meng/1005-faceperception$ cd -
+/inbox/BIDS/Gobbini/Matteo/1002-faceangles
+
+yoh@rolando:/inbox/BIDS/Gobbini/Matteo/1002-faceangles$ git annex info
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 5
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	8ffcc6d4-1288-45cb-8e5b-0fa13a22c8c5 -- mvdoc@falkor:/srv/dbic.datalad.org/www/Gobbini/Matteo/1002-faceangles
+ 	b7872847-80ac-47d6-a712-fa695b24e85e -- yoh@rolando:/inbox/BIDS/Gobbini/Matteo/1002-faceangles [here]
+ 	db79e407-569d-43b4-8c39-c50f0eeb1fdd -- mvdoc@smaug:/mnt/btrfs/dbic/inbox/face-angles/Gobbini/Matteo
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 30.19 terabytes (+1 megabyte reserved)
+local annex keys: 40
+local annex size: 5.21 gigabytes
+annexed files in working tree: 40
+size of annexed files in working tree: 5.21 gigabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+	SHA256E: 40
+
+yoh@rolando:/inbox/BIDS/Gobbini/Matteo/1002-faceangles$ git annex version
+git-annex version: 6.20170101+gitg93d69b1-1~ndall+1
+
+"""]]
+
+
+so this one was a run from within singularity neurodebian environment on a centos box. but the same behaviour is if ran using 6.20161231-gc8eeb17da  standalone build ran under CentOS natively.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> It seems this was probably not a bug in git-annex, as explained in my 
+> comments, so [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__/comment_1_6c595bec40f6bf470e9170c8ae4bb573._comment b/doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__/comment_1_6c595bec40f6bf470e9170c8ae4bb573._comment
new file mode 100644
index 0000000000..3835086719
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__/comment_1_6c595bec40f6bf470e9170c8ae4bb573._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-07T17:48:05Z"
+ content="""
+These seem to be two separate git repositories and it's only crashing in
+one of them. 
+
+Perhaps annex.pidlock is set in the repository where it works, and not in
+the other repository?
+
+git-annex init probes to see if it can set a lock, and if not, enables
+annex.pidlock. Since 5.20151116.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__/comment_2_4c2e143b8b3283734963e0a6e68755ac._comment b/doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__/comment_2_4c2e143b8b3283734963e0a6e68755ac._comment
new file mode 100644
index 0000000000..9fd9af6500
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__/comment_2_4c2e143b8b3283734963e0a6e68755ac._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2017-02-10T01:38:33Z"
+ content="""
+indeed that was the case.... not clear though how that one ended up without pidlock not being set since all creation was uniform as far as I remember
+
+I wonder if annex could potentially detect for such a case and reissue check/assignment of the pidlock?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__/comment_3_dac1401bd3661397a9388a5b6ce673a5._comment b/doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__/comment_3_dac1401bd3661397a9388a5b6ce673a5._comment
new file mode 100644
index 0000000000..95f02857c6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/git_annex_info_fails_on_NFS__58___waitToSetLock__58___resource_exhausted___40__No_locks_available__41__/comment_3_dac1401bd3661397a9388a5b6ce673a5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-02-10T17:56:32Z"
+ content="""
+Seems unlikely that the init-time check would not have worked in this
+repository. Probably the repository was either initialized by an old
+version of git-annex, or perhaps init was run on the NFS server,
+or perhaps the repository was initted elsewhere and moved into place.
+
+I don't want to complicate locking with fallbacks involving changing
+configuration. ENOLCK can be raised for other reasons, so it's not
+necessarily an indication of a NFS system anyway.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/graft__47__graft_cleanup_commits_--_really_needed__63__.mdwn b/doc/projects/datalad/bugs-done/graft__47__graft_cleanup_commits_--_really_needed__63__.mdwn
new file mode 100644
index 0000000000..95a2c42045
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/graft__47__graft_cleanup_commits_--_really_needed__63__.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+
+Playing with the new fancy "export" feature.  Thanks again!
+
+Somehow I see now commits in the git-annex branch in the quick succession establishing and then killing a "graft".
+Are they really needed/used by annex or could have been squashed/avoided?
+
+some details of the recent history of commands and how git-annex branch looks like are listed below
+
+
+### What version of git-annex are you using? On what operating system?
+
+6.20171018+gitgbb20b1ed3-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+14883  tree /tmp/test-directory-export -a
+14887  git annex info
+14888  git annex export --to=directory-export
+14889  git annex export
+14890  git annex export --tracking master --to public-s3
+14891  git annex export --tracking master --to directory-export
+14892  git annex export
+14893  git annex export --to directory-export
+14894  git annex export
+14896  git annex sync --content
+14898  git log --stat git-annex
+
+
+$> git lg --stat git-annex | head -n 30
+* 4a03be8 - (git-annex) update (4 minutes ago) [Yaroslav Halchenko]| 
+|  export.log | 2 +-
+|  1 file changed, 1 insertion(+), 1 deletion(-)
+
+* b23ae9d - graft cleanup (4 minutes ago) [Yaroslav Halchenko]| 
+|  export.tree/.datalad/.gitattributes | 3 ---
+|  export.tree/.datalad/config         | 2 --
+|  export.tree/.gitattributes          | 1 -
+|  export.tree/123                     | 1 -
+|  export.tree/sub/dir/11              | 1 -
+|  5 files changed, 8 deletions(-)
+
+* 6a0bc5f - graft (4 minutes ago) [Yaroslav Halchenko]| 
+|  export.tree/.datalad/.gitattributes | 3 +++
+|  export.tree/.datalad/config         | 2 ++
+|  export.tree/.gitattributes          | 1 +
+|  export.tree/123                     | 1 +
+|  export.tree/sub/dir/11              | 1 +
+|  5 files changed, 8 insertions(+)
+
+* 919e345 - update (5 minutes ago) [Yaroslav Halchenko]| 
+|  export.log | 2 +-
+|  1 file changed, 1 insertion(+), 1 deletion(-)
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> Seems we're ok, so [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/graft__47__graft_cleanup_commits_--_really_needed__63__/comment_1_7bc271ddeafc92d36d2b90fcb1481891._comment b/doc/projects/datalad/bugs-done/graft__47__graft_cleanup_commits_--_really_needed__63__/comment_1_7bc271ddeafc92d36d2b90fcb1481891._comment
new file mode 100644
index 0000000000..8de4c19158
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/graft__47__graft_cleanup_commits_--_really_needed__63__/comment_1_7bc271ddeafc92d36d2b90fcb1481891._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-10-25T18:56:49Z"
+ content="""
+They're really needed. Squashing them together would make the tree ref
+that's being grafted in not be reachable, so it would be subject to GC,
+which would lose data that the export feature needs to make sure is
+retained for later.
+
+It would be possible to squash the graft cleanup with the export.log update
+commit. However, I was unable to stage the graft
+into the git-annex branch index file using git update-index, due to
+possibly a bug in git, so I was not able to find a way to do that.
+See [[!commit 5483ea90eca33f61c799fb6a3c2675657caa9c75]]
+
+The diff makes it look somehow big and expensive, but the actual overhead
+on disk is two commit objects. The tree object being grafted in is the
+exported tree, so retaining it does not really add any overhead. So
+something in the area of 2 kb overhead, per export of a tree.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/graft__47__graft_cleanup_commits_--_really_needed__63__/comment_2_d0a7283aac4f3c231e20ab284a1f2253._comment b/doc/projects/datalad/bugs-done/graft__47__graft_cleanup_commits_--_really_needed__63__/comment_2_d0a7283aac4f3c231e20ab284a1f2253._comment
new file mode 100644
index 0000000000..91eb4bcd93
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/graft__47__graft_cleanup_commits_--_really_needed__63__/comment_2_d0a7283aac4f3c231e20ab284a1f2253._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="got it"
+ date="2017-10-30T18:33:20Z"
+ content="""
+Thank you Joey!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__.mdwn b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__.mdwn
new file mode 100644
index 0000000000..28a8cc8c34
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__.mdwn
@@ -0,0 +1,41 @@
+### Please describe the problem.
+
+Sorry if it doesn't really fit into the "bug" category, although may be I could have titled it "does not consider another instance of the same special remote in case one fails to initialize in parallel (-J) mode" may be?
+
+### What steps will reproduce the problem?
+
+In datalad-archives we probably should restrict to having just a single instance of that special remote running to avoid messing with tracking of which instance is taking care about which archive and stage (download, extraction, etc).  So I thought I would just implement that by assuring that there is a single instance of the special remote running per repository and all others just reporting 'PREPARE-FAILURE' and then git-annex would try another instance it has in the pool.
+
+But it seems to be not the case:
+
+
+[[!format sh """
+[2018-03-05 14:23:06.725630284] chat: /home/yoh/proj/datalad/datalad/venvs/dev/bin/git-annex-remote-datalad-archives []
+[2018-03-05 14:23:07.019016095] git-annex-remote-datalad-archives[2] --> VERSION 1
+[2018-03-05 14:23:07.019267772] git-annex-remote-datalad-archives[2] <-- EXTENSIONS INFO
+[2018-03-05 14:23:07.019461422] git-annex-remote-datalad-archives[2] --> UNSUPPORTED-REQUEST
+[2018-03-05 14:23:07.019596061] git-annex-remote-datalad-archives[2] <-- PREPARE
+[2018-03-05 14:23:07.019643377] git-annex-remote-datalad-archives[1] --> VERSION 1
+[2018-03-05 14:23:07.01973844] git-annex-remote-datalad-archives[1] <-- EXTENSIONS INFO
+[2018-03-05 14:23:07.019888855] git-annex-remote-datalad-archives[1] --> UNSUPPORTED-REQUEST
+[2018-03-05 14:23:07.019917528] git-annex-remote-datalad-archives[2] --> PREPARE-SUCCESS
+[2018-03-05 14:23:07.019972279] git-annex-remote-datalad-archives[1] <-- PREPARE
+[2018-03-05 14:23:07.02001778] git-annex-remote-datalad-archives[2] <-- TRANSFER RETRIEVE MD5E-s5238--ead47341c9363e7f49c1a50c895d170b.txt .git/annex/tmp/MD5E-s5238--ead47341c9363e7f49c1a50c895d170b.txt
+[2018-03-05 14:23:0detailed-methods.txt (from datalad-archives...) ] --> PREPARE-FAILURE Failed to prepare <datalad.customremotes.archives.ArchiveAnnexCustomRemote object at 0x7f7c1ce84390> due to Cannot lock repo /home/yoh/datalad__/crcn
+get docs/crcns-aa1-conditions.txt (from datalad-archives...) failed
+get docs/crcns-aa1-detailed-methods.txt (from datalad-archives...) 
+"""]]
+
+if one instance fails -- annex immediately reports that the url failed to download and doesn't try another instance it had to be ran in parallel.
+
+I wondered if there is an easy way to restrict a single instance for some special remotes (may be with recently added "FEATURES" to describe special remotes) or adjust parallel download logic to loop through available (not failed) instances thus reusing only one instance if all others fail?
+
+### What version of git-annex are you using? On what operating system?
+6.20180220+gitg811d0d313-1~ndall+1
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[[!meta title="extend external special remote protocol so a process can refuse to PREPARE, making -J not use it concurrently"]]
+
+> [[rejected|done]] --[[Joey]] 
diff --git a/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_1_447c9cf5e9e137238fb2c662a54ee2d7._comment b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_1_447c9cf5e9e137238fb2c662a54ee2d7._comment
new file mode 100644
index 0000000000..1d5af193c9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_1_447c9cf5e9e137238fb2c662a54ee2d7._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-03-06T16:08:23Z"
+ content="""
+When I try this with ssh remotes, which should act the same as external
+special remotes as far as git-annex get behavior is concerned,
+git-annex get moves on to the next remote that has the file when the first
+one fails.
+
+I think the difference might come down to the handling of the failed
+PREPARE. That throws an exception, so terminates the get action for that
+file.
+
+Indeed, there are quite a few `giveup` in Remote/External.hs, and while
+some of them are reasonable exceptions to throw, it needs an audit for ones
+that throw an exception when there's a better way to indicate failure like
+return False.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_2_8432a49e6af69efbfcb4d615e147f873._comment b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_2_8432a49e6af69efbfcb4d615e147f873._comment
new file mode 100644
index 0000000000..51c0c38be3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_2_8432a49e6af69efbfcb4d615e147f873._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-03-06T16:33:41Z"
+ content="""
+Ok, audited all exceptions thrown in there, 
+and the only other one that stood out is 
+that TRANSFER-FAILURE throws an exception -- but that one
+is ok because it's in a Retriever, all of which exceptions are caught.
+
+But hmm, PREPARE-FAILURE throwing an exception when git-annex is preparing
+before retrieving a key is in the same Retriever, so that exception also
+should not be a problem. There might be other cases where PREPARE-FAILURE
+throwing an exception is not desirable, but this is not one.
+
+---
+
+Oh, I see, the bug report is really about some -J specific issue!
+
+I'm having difficulty reproducing it. I have two external special remotes
+that both send PREPARE-FAILURE, and when a file is present in both,
+`git annex get -J2` does try both of them:
+
+	[2018-03-06 12:45:21.123121045] chat: /home/joey/bin/git-annex-remote-directory []
+	[2018-03-06 12:45:21.125524418] git-annex-remote-directory[1] --> VERSION 1
+	[2018-03-06 12:45:21.125702152] git-annex-remote-directory[1] <-- EXTENSIONS INFO
+	[2018-03-06 12:45:21.126005492] git-annex-remote-directory[1] --> UNSUPPORTED-REQUEST
+	[2018-03-06 12:45:21.126186941] git-annex-remote-directory[1] <-- PREPARE
+	[2018-03-06 12:45:21.126518978] git-annex-remote-directory[1] --> PREPARE_FAILURE OOK
+	[2018-03-06 12:45:21.129247706] chat: /home/joey/bin/git-annex-remote-directory []
+	[2018-03-06 12:45:21.131475605] git-annex-remote-directory[1] --> VERSION 1
+	[2018-03-06 12:45:21.131636898] git-annex-remote-directory[1] <-- EXTENSIONS INFO
+	[2018-03-06 12:45:21.131848068] git-annex-remote-directory[1] --> UNSUPPORTED-REQUEST
+	[2018-03-06 12:45:21.131953342] git-annex-remote-directory[1] <-- PREPARE
+	[2018-03-06 12:45:21.132127177] git-annex-remote-directory[1] --> PREPARE_FAILURE OOK
+	get foo (from d1...) (from d2...)
+	  Unable to access these remotes: d1, d2
+"""]]
diff --git a/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_3_f66844b716e48c5befbe99346e940962._comment b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_3_f66844b716e48c5befbe99346e940962._comment
new file mode 100644
index 0000000000..23d34f6331
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_3_f66844b716e48c5befbe99346e940962._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2018-03-06T19:07:37Z"
+ content="""
+re reproduce:  may be it is relevant that in my case it is THE SAME (the same uuid, hardcoded similarly to web \"remote\" uuid) remote.
+
+re locking: have some ugly (almost) working fix -- but yet to troubleshoot why some files still manage to get \"failed\" status (may be it is somehow related to above)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_4_e90ba33f7506745582d18841ae9a9531._comment b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_4_e90ba33f7506745582d18841ae9a9531._comment
new file mode 100644
index 0000000000..5dcc4d0361
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_4_e90ba33f7506745582d18841ae9a9531._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-04-02T17:13:33Z"
+ content="""
+Ok so I misunderstood this, it's entirely about -J mode and external
+special remote processes. One is started per parallelism level, because
+otherwise nothing much would actually be done in parallel. 
+
+You wanted to start only one because reasons, which IIRC from talking
+with you were in the meantime fixed in your special remore program using
+locking.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_5_098b2e2c51f70d495fe1587220173f55._comment b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_5_098b2e2c51f70d495fe1587220173f55._comment
new file mode 100644
index 0000000000..49afab2c0a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_5_098b2e2c51f70d495fe1587220173f55._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-04-03T19:17:32Z"
+ content="""
+PREPARE-FAILURE is documented as "the special remote cannot be used"
+and so I don't think it makes sense for git-annex to use the previously
+started instance of the program if a later one fails like that.
+
+It would need a new response to PREPARE. And some possibly not
+insignificant changes in Remote/External.hs to support it. In particular,
+Remote/External.hs currently delays sending PREPARE until the first time
+it uses a special remote, but this seems to need PREPARE to be sent
+earlier, when it starts up the special remote, so it can detect the new
+response and remember that it should not try to start up any more
+concurrent instances and instead use any already started instance.
+
+The best argument for doing it, I think, is if several different external
+special remote programs really only support a single instance running at a
+time, and if supporting that inside git-annex would be enough of a win,
+rather than making those programs do their own locking.
+
+Hmm, an external  special remote program can't just block its response to
+PREPARE when another instance is running, because it would never be able to
+un-block. So it seems they would have to use finer-grained locking when
+responding to eg TRANSFER. I don't know if anything other than datalad
+needs such locking (and IIUC datalad already got the necessary locking), 
+but it does seem like it would be worth adding an extra PREPARE response
+to avoid needing to so complicate external special remote programs.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_6_306afca0827aabc092fd99e56a5b658c._comment b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_6_306afca0827aabc092fd99e56a5b658c._comment
new file mode 100644
index 0000000000..a0f56c4aaa
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_6_306afca0827aabc092fd99e56a5b658c._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-05-28T16:15:34Z"
+ content="""
+So the idea here is to add a PREPARE-NONCONCURRENT or whatever for the
+external to use to signal that it's not able to do anything because another
+one is already running concurrently.
+
+If the first instance that git-annex starts up responds that way, I suppose
+it would just be treated the same as PREPARE-FAILURE.
+
+So, if an external is being used for one git-annex command, another
+git-annex command that also needs to use it would just fail to start it,
+and so fail entirely.
+
+Just for example, git annex whereis needs to start up the external program
+to check WHEREIS, and would need to fail if it responded PREPARE-NONCONCURRENT.
+So a long-running git-annex copy (or even the assistant) would then prevent
+other git-annex commands from working.
+
+So, seem this is blocked on
+[[todo/external_remote_querying_transition]].
+
+I'm also not really sure it's worth implementing this, is it really going
+to be useful compared with external remote programs doing their own locking
+around whatever operations cannot be run concurrently?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_7_987b2c1de4638e01c4f4feb028d47b88._comment b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_7_987b2c1de4638e01c4f4feb028d47b88._comment
new file mode 100644
index 0000000000..37d2103e0d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_7_987b2c1de4638e01c4f4feb028d47b88._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2020-05-28T23:53:58Z"
+ content="""
+The workaround I had mentioned above originally seems to work fine for us, so indeed no need for this feature from DataLad side ATM.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_8_d0d8a729badb551bb8d0f77e7104c159._comment b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_8_d0d8a729badb551bb8d0f77e7104c159._comment
new file mode 100644
index 0000000000..ca6e1c8a68
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_8_d0d8a729badb551bb8d0f77e7104c159._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2020-09-28T14:00:00Z"
+ content="""
+The async extension to the protocol guarantees only a single process will
+be run. The remote might be asked to start several operations
+concurrently, but if it wants to queue them sequentially, that should be
+fine.
+
+While it might be a bit of a round about way to get this functionality,
+since the extension complicates the protocol a bit, I'm inclined to feel
+it's enough, and not add this other extension, 
+at least without some more compelling use case.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_9_7159b17d64ee147822969d79d5a1c48c._comment b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_9_7159b17d64ee147822969d79d5a1c48c._comment
new file mode 100644
index 0000000000..f8f9e7e6e5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_9_7159b17d64ee147822969d79d5a1c48c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 9"
+ date="2020-09-28T19:44:05Z"
+ content="""
+Sorry for being anal with my questions and not just trying it out... but by `The async extension to the protocol guarantees only a single process will be run.` which of the following scenarios do you mean
+
+- a. there will be no parallel workers if `--jobs N` is specified (thus a single process for an external remote)
+- b. there are parallel workers, and a single instance of an external special remote will be ran and either 
+   - b.1. only one worker would be able to talk to it
+   - b.2. parallel workers will talk to the same async external special remote
+
+or may be some other c. or b.3  ?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created.mdwn b/doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created.mdwn
new file mode 100644
index 0000000000..21c33ba786
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created.mdwn
@@ -0,0 +1,41 @@
+### Please describe the problem.
+
+I have 2 indirect mode repos, both on network filesystems, that I have only used for adding
+data on one end, then syncing via `git annex sync` and `git annex get`.  The problem
+is that`.nfs` copies are being made for each git annex object data file, e.g:
+
+`./.git/annex/objects/34/2x/SHA256E-s4112535690--c5f0e5a8af7bf17dd4a8ca192c8ddfb01fe6ec10908c80cffa5ac64c00e28443.vtk.gz/.nfs0000000006d0018600002147`
+
+Reading up on .nfs files, they are generated when "an open file is removed but is still being accessed".
+
+### What steps will reproduce the problem?
+Clone a git annex repo on a network file system,  run 
+`git annex sync` ,
+`git annex drop` ,
+`git annex get` 
+
+### What version of git-annex are you using? On what operating system?
+* git-annex version: 5.20140818-g10bf03a
+* 2.6.34.9-69.fc13.x86_64 fedora 13
+* 2.6.32-279.22.1.el6.x86_64 centOS
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+[[!meta title="git-annex and NFS don't mix; could git annex init detect NFS and refuse to use it?"]]
+
+[[!tag projects/datalad]]
+
+> [[closing|done]] because annex.pidlock exists, and git-annex init 
+> checks if FCNTL locking works, and if not, enables it. So if the NFS
+> server does not support FCNTL locking at all, it will use pidlock
+> automatically. And if the NFS server does support locking, there does not
+> seem to be a good way to probe that it's NFS and enable annex.pidlock.
+> --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/comment_1_833cf2db9881a401a3d5db6d4f3c450a._comment b/doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/comment_1_833cf2db9881a401a3d5db6d4f3c450a._comment
new file mode 100644
index 0000000000..430e26f5f0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/comment_1_833cf2db9881a401a3d5db6d4f3c450a._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-04T19:31:32Z"
+ content="""
+git-annex uses posix file locking to avoid scenarios that could
+otherwise result in data loss when dropping a file. 
+
+This indeed involves keeping a file open and locked while removing it.
+
+Since NFS's posix file locking support ranges from poor to completely
+broken, it's not wise to use git-annex over NFS at all. It's much nicer
+to use it locally, with a git remote accessing the file server over
+eg, ssh.
+
+I can't see any changes to git-annex that could improve its handing
+of NFS, unless there's a good way to detect a NFS filesystem and make
+`git annex init` refuse to set up a repository there.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/comment_2_ae3d42be1a15dda2cfe97c99248ceacb._comment b/doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/comment_2_ae3d42be1a15dda2cfe97c99248ceacb._comment
new file mode 100644
index 0000000000..c9c5e758ae
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/comment_2_ae3d42be1a15dda2cfe97c99248ceacb._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 2"
+ date="2015-06-10T18:30:21Z"
+ content="""
+i am not sure I understand how this is such a problem... those lockfiles are transient - they will eventually go away. do they take up too much space? or what is the problem exactly?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/comment_3_bea29c2596ddcc7f8cd7f02ff7bfd9ef._comment b/doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/comment_3_bea29c2596ddcc7f8cd7f02ff7bfd9ef._comment
new file mode 100644
index 0000000000..9822058c5a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/comment_3_bea29c2596ddcc7f8cd7f02ff7bfd9ef._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-11-13T19:56:12Z"
+ content="""
+I've just added annex.pidlock to git-annex. Configure that to true, and it
+will use one top-level pid lock file, rather than these posix locks. Might
+work better on NFS.
+
+annex.pidlock is enabled automatically if probing detects that posix locks
+cannot be made at all. However, if the NFS lets posix locks be made, just
+with the poor behavior described here, the probing can't detect that and so
+you'd need to enable it manually.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times.mdwn b/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times.mdwn
new file mode 100644
index 0000000000..743e6fd0b2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times.mdwn
@@ -0,0 +1,14 @@
+As reported before in private communication, remains the case.  Yesterday happened on both chromium and firefox.  Cookies are enabled and even present (see screenshot, couldn't attach), clearing cookie doesn't help.  Now managed to successfully login in firefox.
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[screenshot.png](http://www.onerussian.com/tmp/gkrellShoot_09-25-18_092905.png)
+[[!taglink  confirmed]]
+
+> I've made http redirect to https, which will avoid this problem.
+> 
+> [ikiwiki bug report](http://ikiwiki.info/bugs/http_login_after_https_login_leads_to_extremely_confusing_error/)
+> 
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_1_a5824d9099dc4035e09086166b13f133._comment b/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_1_a5824d9099dc4035e09086166b13f133._comment
new file mode 100644
index 0000000000..76f729959b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_1_a5824d9099dc4035e09086166b13f133._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-09-25T15:24:55Z"
+ content="""
+Same here.  Had to clear all my cookies, and even that doesn't always help.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_2_fceb64e98fb7566f7cb999e9b37914f5._comment b/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_2_fceb64e98fb7566f7cb999e9b37914f5._comment
new file mode 100644
index 0000000000..1019bfce92
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_2_fceb64e98fb7566f7cb999e9b37914f5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-09-25T15:27:13Z"
+ content="""
+happened to me again on firefox, where I first went to http://git-annex.branchable.com/bugs/ to file a new report, was directed to login, entered credentials, got error message.  I have then removed cookies, went in a new tab to the bugs, this bug, and then was able to login.
+So it is cookies related, but IMHO not a user fault 
+"""]]
diff --git a/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_3_49b8cf8de638190b3b29ffdca3fe0bdd._comment b/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_3_49b8cf8de638190b3b29ffdca3fe0bdd._comment
new file mode 100644
index 0000000000..487bb37c87
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_3_49b8cf8de638190b3b29ffdca3fe0bdd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 3"
+ date="2018-11-12T16:37:44Z"
+ content="""
+This happens to me every few months. Just happened to me again today 2018-11-12. I cleared my cookies for this site and now I am logged in. Marked this bug as confirmed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_4_dc940fed174b32dfdb4b4ff8c10529f0._comment b/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_4_dc940fed174b32dfdb4b4ff8c10529f0._comment
new file mode 100644
index 0000000000..8f5d0a113d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_4_dc940fed174b32dfdb4b4ff8c10529f0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 4"
+ date="2018-11-17T19:07:07Z"
+ content="""
+and again. 2018-11-17 2:05pm EST, if the time helps for spelunking the logs.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_5_c76fddc3aab4d3580c79f105c97d6998._comment b/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_5_c76fddc3aab4d3580c79f105c97d6998._comment
new file mode 100644
index 0000000000..233a26e5d3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/impossible_to_login_to_the_website_at_times/comment_5_c76fddc3aab4d3580c79f105c97d6998._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 5"
+ date="2019-01-01T18:47:58Z"
+ content="""
+OK. I think I have figured out the issue (at least in my case). I guess that I had logged into https://git-annex.branchable.com, then tried to visit the non-secure URL http://git-annex.branchable.com this is when I got the error.
+
+Taking a look at the cookie I send when visiting https://git-annex.branchable.com I see that it has the secure flag set. Which I think means that my browser will refuse to send this cookie when I visit the http://git-annex.branchable.com and will refuse to receive another cookie (since its the same domain).
+
+If I clear my cookies and login via http://git-annex.branchable.com, the cookie does not have the secure flag set.
+
+This means that ikiwiki is serving cookies with different flags for http vs https. Probably related to this feature? <https://ikiwiki.info/todo/use_secure_cookies_for_ssl_logins/>. Anyhow it seems this isn't quite working as desired. I think it is possible to serve two different cookies (one for http and one for https) but ikiwiki does not appear to be doing that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions.mdwn b/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions.mdwn
new file mode 100644
index 0000000000..d06d3e413f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions.mdwn
@@ -0,0 +1,23 @@
+
+### What version of git-annex are you using? On what operating system?
+
+6.20171001+gitg542d0649f-1~ndall+1
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+$> git annex info     
+
+git-annex: .git/annex/misctmp/mergedrefs.0: createDirectory: permission denied (Permission denied)
+failed
+git-annex: info: 1 failed
+
+"""]]
+
+unless there is really a need to have this operations performed within the same repository/the same filesystem, I do not understand why generic $TMPDIR could not be used for such operations so no write access has to be demanded
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]]; I implemented annex.merge-annex-branches=false to avoid
+> the unwanted behavior, and have not heard any complaints, so.. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_1_8b60c52d8fe41718377d6d15a25cae97._comment b/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_1_8b60c52d8fe41718377d6d15a25cae97._comment
new file mode 100644
index 0000000000..efef1a0e39
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_1_8b60c52d8fe41718377d6d15a25cae97._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-02-22T16:17:35Z"
+ content="""
+The mergedrefs directory is used while building the commit to merge
+git-annex branches. So even if it was written someplace else, that commit
+would fail.
+
+I think this may be happening even when there are no
+git-annex refs to merge in, due to the transition code
+in Annex.Branch.updateTo that temporarily calls addMergedRefs
+in the "null tomerge" case. That was added in 2016, and is flagged as able
+to be safely removed. I've removed it.
+
+However, when there actually is a git-annex branch to merge, if a
+hypothetical readonly mode avoided doing so, it would necessarily see a
+different state of the git-annex branch than would be seen in non-readonly
+mode. That behavior difference could be fairly confusing potentially..
+"""]]
diff --git a/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_2_066d2f95ffab1b36b69aa84643d67765._comment b/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_2_066d2f95ffab1b36b69aa84643d67765._comment
new file mode 100644
index 0000000000..0863efa278
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_2_066d2f95ffab1b36b69aa84643d67765._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="--read-only flag?"
+ date="2018-02-22T17:18:18Z"
+ content="""
+I hear you... so far though I was confused by the fact that what I thought would be a read-only operation was actually changing the state of the things (doing the annex merge).  Although I would have preferred just a warning like \"Cannot merge git-annex branch because of lacking permissions to do so, some information might be not up-to-date\", I wondered if then may be a generic resolution could be to add `--read-only` flag to such commands as `info` and `whereis`.  Then we (datalad) would be the one to explicitly check if there is write-permissions and if not -- issue the command in `--read-only` mode.  We might even make it a default mode of operation for some of our usecases where it would be confusing if things were changing in the background (e.g. with `ls` command)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_3_05f7eec04634e5b4e200cf3dca1bb1b1._comment b/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_3_05f7eec04634e5b4e200cf3dca1bb1b1._comment
new file mode 100644
index 0000000000..3edb6654b5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_3_05f7eec04634e5b4e200cf3dca1bb1b1._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-02-22T17:27:06Z"
+ content="""
+There are situations where a git command that appears to be read-only,
+such as `git status` actually writes to the repository behind the scenes.
+It looks like git ignores write errors in at least some such cases. So
+there is precident for implicit read-only support, but I think not in cases
+where it would involve significant behavior changes, like it would for the
+git-annex branch auto-merging. In git's case the behavior change probably
+only involves repeated `git status` runs being slower than otherwise,
+or something like that.
+
+As well as populating the .git/annex/index file with information merged in from
+recently fetched git-annex branches, git-annex may need to write to other files
+in order to prepare caches needed to perform what appears to be "read-only"
+query operation, or to lock files in order to prevent someone who does have
+write access from dropping them in a situation where that will lose data.
+An example of the latter is running `git annex drop` in a repository you do have
+write access to, and it needing to exclusively lock files in origin,
+which requires write access to origin as well. Without write access,
+the drop may fail.
+
+The --read-only flag seems to be setting up a situation where git-annex handles
+some things being read-only, but then someone expects the flag to 
+make some other thing work read-only, which git-annex can't manage to support
+for whatever reason. 
+
+So I prefer a more specific name, like annex.merge-annex-branches=false.
+
+Implemented that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_4_705616c61fe7a0779df3794fa8a1d6dc._comment b/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_4_705616c61fe7a0779df3794fa8a1d6dc._comment
new file mode 100644
index 0000000000..1db847262d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_4_705616c61fe7a0779df3794fa8a1d6dc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2021-12-02T20:42:37Z"
+ content="""
+backref: follow up is now filed separately [here](https://git-annex.branchable.com/bugs/merge-annex-branches__61__false_-_automate_and_extend/)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/inconsistent_output_upon_addurl_--batch_complicates_if_not_forbids_reliable_parsing_of_output.mdwn b/doc/projects/datalad/bugs-done/inconsistent_output_upon_addurl_--batch_complicates_if_not_forbids_reliable_parsing_of_output.mdwn
new file mode 100644
index 0000000000..c5330b28bb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/inconsistent_output_upon_addurl_--batch_complicates_if_not_forbids_reliable_parsing_of_output.mdwn
@@ -0,0 +1,25 @@
+### Please describe the problem.
+
+if using addurl in --batch mode, there is no --json formatting and text output is somewhat inconsistent.  It might include "downloading ..." with 'ok' on a separate line, possibly with a msg on recording state in git, or within the same line report 'ok', or 'failed' in upcoming lines.  This complicates parsing of such output to verify correct operation for a given addurl pair
+
+[[!format sh """
+
+$> echo 'http://127.0.0.1:33369/about.txt about.txt' | git -c receive.autogc=false annex addurl --with-files --batch --debug 2>/dev/null
+addurl about.txt (downloading http://127.0.0.1:33369/about.txt ...)                                                                     
+ok
+(recording state in git...)
+
+$> echo 'http://127.0.0.1:33369/about.txt about.txt' | git -c receive.autogc=false annex addurl --with-files --batch --debug 2>/dev/null
+addurl about.txt ok
+
+$> echo 'http://127.0.0.1:33369/about.stxt about.txt' | git -c receive.autogc=false annex addurl --with-files --batch --debug 2>/dev/null 
+addurl about.txt 
+failed
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> I've made --json work for addurl; I feel that's the way to go for parsing
+> its output. [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/info_--json_lists_backend_usage_stats_as_a_list_of_lists.mdwn b/doc/projects/datalad/bugs-done/info_--json_lists_backend_usage_stats_as_a_list_of_lists.mdwn
new file mode 100644
index 0000000000..ad3da66185
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/info_--json_lists_backend_usage_stats_as_a_list_of_lists.mdwn
@@ -0,0 +1,35 @@
+### What version of git-annex are you using? On what operating system?
+
+5.20151116+gitg5416a1a-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+    "backend usage": [
+        [
+            "MD5E",
+            2
+        ],
+        [
+            "SHA256E",
+            2
+        ]
+    ],
+"""]]
+
+instead of more logical
+
+[[!format sh """
+
+    "backend usage": {
+         "MD5E": 2,
+         "SHA256E": 2
+    }
+"""]]
+
+also it seems it just doubles them since I have only 2 files, 1 for each backend (as reported also by info "local annex keys": 2). 
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/init__58___syntax_warnings_in_diff_driver_on_Windows.mdwn b/doc/projects/datalad/bugs-done/init__58___syntax_warnings_in_diff_driver_on_Windows.mdwn
new file mode 100644
index 0000000000..3faa80170f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/init__58___syntax_warnings_in_diff_driver_on_Windows.mdwn
@@ -0,0 +1,125 @@
+### Please describe the problem.
+Git-for-Windows comes with custom diff drivers (see [https://github.com/git-for-windows/build-extra/blob/main/git-extra/gitattributes](https://github.com/git-for-windows/build-extra/blob/main/git-extra/gitattributes); [https://github.com/git-for-windows/build-extra/blob/main/git-extra/astextplain](https://github.com/git-for-windows/build-extra/blob/main/git-extra/astextplain)) that are meant to improve the diff display for a variety of file types.
+When cloning a repository where such file types are annexed, a subsequent ``git annex init`` will cause the diff drivers to run and fail, emitting the warnings and errors of the tools used within the diff driver.
+For example, the ``astextplain`` diff driver for PDFs uses ``pdftotext -layout -enc UTF-8 "$1" - | sed "s/(\^M$)|(^\^L)//"`` and emits the following during a ``git annex init`` in a repository with annexed PDFs:
+
+```
+Updating files: 100% (10/10), done.
+Switched to branch 'adjusted/master(unlocked)'
+Syntax Warning: May not be a PDF file (continuing anyway)
+Syntax Error: Couldn't read xref table
+Syntax Warning: PDF file is damaged - attempting to reconstruct xref table...
+Syntax Error: Couldn't find trailer dictionary
+Syntax Error: Couldn't read xref table
+[...] one for each PDF
+```
+
+I have filed a feature request with Git for Windows to maybe parametrize the tools with a ``--quiet`` or equivalent flag, such that these warnings do not bubble up: [https://github.com/git-for-windows/git/issues/3673](https://github.com/git-for-windows/git/issues/3673).
+However, the question came up whether git annex internal calls could instead be parametrized differently, and I wanted to file this companion issue to hopefully figure out which place - if any - would be the right one for a fix.
+
+> [Quote from a response to the linked issue] "On a different note though, why is git annex init running a git diff here with external diff drivers on files it knows aren't the types of files git would expect to be there? Would it show an actual diff to the user here with other types of annexed files/on a different filesystem? Or is it trying to generate some diff for scripted use? If it's trying to do the latter, it should probably at least use --no-textconv there."
+
+### What steps will reproduce the problem?
+
+On a Windows system using Git for Windows, run:
+
+```sh
+git clone git@github.com:datalad-datasets/machinelearning-books.git
+cd machinelearning-books
+git annex init
+```
+
+The output looks like this:
+
+```sh
+datalads@bnbdatalad MINGW64 ~/machinelearning-books (master)
+$ git annex init
+init
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Disabling core.symlinks.
+starting fsmonitor-daemon in 'C:/Users/datalads/machinelearning-books'
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Updating files: 100% (10/10), done.
+Switched to branch 'adjusted/master(unlocked)'
+Syntax Warning: May not be a PDF file (continuing anyway)
+Syntax Error: Couldn't read xref table
+Syntax Warning: PDF file is damaged - attempting to reconstruct xref table...
+Syntax Error: Couldn't find trailer dictionary
+Syntax Error: Couldn't read xref table
+Syntax Warning: May not be a PDF file (continuing anyway)
+Syntax Error: Couldn't read xref table
+Syntax Warning: PDF file is damaged - attempting to reconstruct xref table...
+Syntax Error: Couldn't find trailer dictionary
+Syntax Error: Couldn't read xref table
+Syntax Warning: May not be a PDF file (continuing anyway)
+Syntax Error: Couldn't read xref table
+Syntax Warning: PDF file is damaged - attempting to reconstruct xref table...
+Syntax Error: Couldn't find trailer dictionary
+Syntax Error: Couldn't read xref table
+Syntax Warning: May not be a PDF file (continuing anyway)
+Syntax Error: Couldn't read xref table
+Syntax Warning: PDF file is damaged - attempting to reconstruct xref table...
+Syntax Error: Couldn't find trailer dictionary
+Syntax Error: Couldn't read xref table
+Syntax Warning: May not be a PDF file (continuing anyway)
+Syntax Error: Couldn't read xref table
+Syntax Warning: PDF file is damaged - attempting to reconstruct xref table...
+Syntax Error: Couldn't find trailer dictionary
+Syntax Error: Couldn't read xref table
+Syntax Warning: May not be a PDF file (continuing anyway)
+Syntax Error: Couldn't read xref table
+Syntax Warning: PDF file is damaged - attempting to reconstruct xref table...
+Syntax Error: Couldn't find trailer dictionary
+Syntax Error: Couldn't read xref table
+Syntax Warning: May not be a PDF file (continuing anyway)
+Syntax Error: Couldn't read xref table
+Syntax Warning: PDF file is damaged - attempting to reconstruct xref table...
+Syntax Error: Couldn't find trailer dictionary
+Syntax Error: Couldn't read xref table
+Syntax Warning: May not be a PDF file (continuing anyway)
+Syntax Error: Couldn't read xref table
+Syntax Warning: PDF file is damaged - attempting to reconstruct xref table...
+Syntax Error: Couldn't find trailer dictionary
+Syntax Error: Couldn't read xref table
+Syntax Warning: May not be a PDF file (continuing anyway)
+Syntax Error: Couldn't read xref table
+Syntax Warning: PDF file is damaged - attempting to reconstruct xref table...
+Syntax Error: Couldn't find trailer dictionary
+Syntax Error: Couldn't read xref table
+Syntax Warning: May not be a PDF file (continuing anyway)
+Syntax Error: Couldn't read xref table
+Syntax Warning: PDF file is damaged - attempting to reconstruct xref table...
+Syntax Error: Couldn't find trailer dictionary
+Syntax Error: Couldn't read xref table
+
+  Unable to parse git config from origin
+
+  Remote origin does not have git-annex installed; setting annex-ignore
+
+  This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote origin
+ok
+(recording state in git...)
+```
+
+### What version of git-annex are you using? On what operating system?
+
+In this particular report, git-annex version: 8.20211029-g438e5b56a on Windows 11 Professional [Version 10.0.22000.434].
+
+### Please provide any additional information below.
+
+There is a companion issue in datalad at [https://github.com/datalad/datalad/issues/6301](https://github.com/datalad/datalad/issues/6301) where I originally recorded this observation, and some other people's additional thoughts about the matter.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Git-annex is amazing. I use it daily. A lot of science is made possible by this tool.
+
+> [[fixed|done]] --[[Joey]]
+
+[[!tag projects/datalad]]
diff --git a/doc/projects/datalad/bugs-done/init__58___syntax_warnings_in_diff_driver_on_Windows/comment_1_65fda26959f82d1f3d110e72d7aaec9a._comment b/doc/projects/datalad/bugs-done/init__58___syntax_warnings_in_diff_driver_on_Windows/comment_1_65fda26959f82d1f3d110e72d7aaec9a._comment
new file mode 100644
index 0000000000..83c5dfde84
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/init__58___syntax_warnings_in_diff_driver_on_Windows/comment_1_65fda26959f82d1f3d110e72d7aaec9a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-01T17:30:46Z"
+ content="""
+Hmm, it seems to me that when git-annex runs git diff, it passes
+--no-ext-diff, which ought to disable any external diff drivers.
+
+Ah, so this is really about the .gitattributes textconv,
+which enables the same thing in a different way that 
+the other option doesn't disable. 
+Ok, I'll add --no-textconv as well.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__.mdwn b/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__.mdwn
new file mode 100644
index 0000000000..8ff01ad7d7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__.mdwn
@@ -0,0 +1,22 @@
+Our test started to fail on 20220610 daily tests, with smth like
+
+```
+2022-06-10T05:51:16.5860150Z >               **results,
+2022-06-10T05:51:16.5860330Z             )
+2022-06-10T05:51:16.5861310Z E           datalad.runner.exception.CommandError: CommandError: 'git -c diff.ignoreSubmodules=none annex initremote fresh-sr type=git location=http://127.0.0.1:50821/ autoenable=true -c annex.dotfiles=true' failed with exitcode 1 under /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/datalad_temp_test_as_common_datasourceerpclil1 [out: 'initremote fresh-sr 
+2022-06-10T05:51:16.5861910Z E           
+2022-06-10T05:51:16.5862300Z E           failed'] [err: 'http://127.0.0.1:50821//config download failed: File not found
+2022-06-10T05:51:16.5862730Z E           git-annex: git repository does not have an annex uuid
+2022-06-10T05:51:16.5863040Z E           initremote: 1 failed']
+2022-06-10T05:51:16.5863180Z 
+2022-06-10T05:51:16.5863540Z ../../../../hostedtoolcache/Python/3.7.13/x64/lib/python3.7/site-packages/datalad/runner/runner.py:205: CommandError
+
+```
+most likely due to  [10.20220525-64-g14584e7a3](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=14584e7a384be87e2fd613ef93a8393d91c0842f) "initremote type=git probe uuid" .
+
+yet to unravel details/change in behavior, but since changelog entry says only about "Improve handling of type=git special remotes" I would not expect negative change in the behavior. Joey -- anything immediate comes to mind?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_1_54456b2ce0964933db23257149b5a651._comment b/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_1_54456b2ce0964933db23257149b5a651._comment
new file mode 100644
index 0000000000..80799bb01c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_1_54456b2ce0964933db23257149b5a651._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2022-06-13T23:52:48Z"
+ content="""
+the \"heart\" of the issue is that in initremote we provide URL which is without `/.git` suffix.   That used to work just fine and [our test](https://github.com/datalad/datalad/blob/HEAD/datalad/distribution/tests/test_siblings.py#L560) testing `git annex get` on the clone accomplished the mission.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_2_23398e5403c3a9f40d3b544139ee9915._comment b/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_2_23398e5403c3a9f40d3b544139ee9915._comment
new file mode 100644
index 0000000000..f0c481cfdc
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_2_23398e5403c3a9f40d3b544139ee9915._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-06-14T15:51:57Z"
+ content="""
+The change that broke your test uses the exact same url uuid detection code
+that git-annex usually uses. So if you were using an url without .git
+before, it seems like it would have failed to detect a uuid after enabling
+the special remote.
+
+If that reasoning does not hold, I'm going to need a test case to
+understand why. Unfortunately, your test case is hard for me to
+understand what it's doing. 
+
+I can't even get git to clone a non-bare git repo served over plain http
+without using .git in the url, so don't understand how your test case is
+doing that.
+
+When I manually make a git remote with a http url without .git
+(which git cannot pull from),
+I see the git-annex uuid detection code failing, as I would expect:
+
+	git remote add test http://localhost/~joey/tmp/foo/
+	git config annex.security.allowed-ip-addresses all
+	git-annex info
+	
+	  Remote test not usable by git-annex; setting annex-ignore
+	
+	  http://localhost/~joey/tmp/foo//config download failed: Not Found
+
+And the initremote behavior is consistent with that:
+
+	git-annex initremote bar type=git location=http://localhost/~joey/tmp/foo/
+	initremote bar
+	  http://localhost/~joey/tmp/foo//config download failed: Not Found
+	
+	git-annex: git repository does not have an annex uuid
+	failed
+
+(It's worth noting that the change was made to handle another datalad use
+case, [[[initremote_type__61__git_is_not_working_for_unkn_reason]].
+I'd consider that use case unusual, and marginally worth supporting.
+I could of course revert the change, but then I'd have to close that
+bug as wontfix.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_3_7fd5d3decc2d6b40d6d2f2d7e6dcabdd._comment b/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_3_7fd5d3decc2d6b40d6d2f2d7e6dcabdd._comment
new file mode 100644
index 0000000000..73d8c4030e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_3_7fd5d3decc2d6b40d6d2f2d7e6dcabdd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="hold it... ;)"
+ date="2022-06-14T18:47:24Z"
+ content="""
+Thank you Joey!  I will try to gain better insight into our dance in that test of ours. I am also curious how it worked before that it doesn't work now.  FWIW with `datalad clone` we do try URL as is, and then also with `/.git` to make users' life easier and so they could just e.g. `datalad clone https://datasets.datalad.org`.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_4_307e7328ca24ff386e0dd734b9ff103e._comment b/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_4_307e7328ca24ff386e0dd734b9ff103e._comment
new file mode 100644
index 0000000000..fdcc7b3ea4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_4_307e7328ca24ff386e0dd734b9ff103e._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="mystery resolved"
+ date="2022-07-01T19:19:30Z"
+ content="""
+Ok, resolved mystery for myself:
+
+> So if you were using an url without .git before, it seems like it would have failed to detect a uuid after enabling the special remote.
+
+yes -- if `initremote` failed to detect uuid it
+
+- didn't exit with non-0 (i.e. initremote call succeeded, our code passed through)
+- produced a \"funky\" looking remotes.log entry without UUID:
+
+```shell
+(git-annex)lena:~/.tmp/datalad_temp_test_as_common_datasourcek5ozqwqd[dl-test-branch]git-annex
+$> git show git-annex:remote.log
+ autoenable=true location=http://127.0.0.1:41311/ name=fresh-sr type=git timestamp=1656702874.867345813s
+0392395d-c1a2-4791-ba6a-e932f1392c34 autoenable=true location=http://127.0.0.1:41311/.git name=mike2 type=git timestamp=165670282
+```
+
+and our test was working before because apparently we had that type=git remote already added with the correct (with `.git`) url (as you can see above) so as long as initremote didn't crash, we were \"happy\" ;)  a little more info could be found in [our datalad issue](https://github.com/datalad/datalad/issues/6779)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_5_e9800d53c4f88d1555aad2e0e945b40b._comment b/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_5_e9800d53c4f88d1555aad2e0e945b40b._comment
new file mode 100644
index 0000000000..3b81e9e276
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/initremote_type__61__git_fresh___34__regression__34__/comment_5_e9800d53c4f88d1555aad2e0e945b40b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-07-07T16:10:12Z"
+ content="""
+Aha! That funky remote.log was caused by a historical bad type in 
+git-annex: UUID has a NoUUID value, and when it probed for the UUID, it
+did not check if it got NoUUID, which serializes to "". Really fixing that
+is hard, I've tried a couple of times. 
+
+Anyway, the new behavior is not buggy, so closing.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout.mdwn b/doc/projects/datalad/bugs-done/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout.mdwn
new file mode 100644
index 0000000000..a09b905dc4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout.mdwn
@@ -0,0 +1,42 @@
+### Please describe the problem.
+
+with previous snapshot (6.20160119+gitgb2a2f5d-1~ndall+1) you just get a clean output
+
+[[!format sh """
+hopa:~/.tmp
+$> git clone /home/yoh/.tmp/datalad_temp_clone_url_RmXPyt 123
+Cloning into '123'...                    
+done.
+
+$> cd 123 
+INFO.txt  test-annex.dat@  test.dat
+
+$> git annex lookupkey test-annex.dat                                        
+SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
+
+"""]]
+
+with new one (6.20160126+gitg65f4442-1~ndall+1) you get it polluted in such a freshly cloned repo with
+
+[[!format sh """
+$> git annex lookupkey test-annex.dat                        
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
+"""]]
+
+and since I am a "dude" who likes "devnulling" things for some reason (I hope reason is clear here ;)):
+
+[[!format sh """
+$> git annex lookupkey test-annex.dat 2>/dev/null            
+(merging origin/git-annex into git-annex...)     
+(recording state in git...)
+SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
+"""]]
+
+I guess I will just skip all lines starting with ( for now but thought to let you know about such changed behavior which might complicate pipelining etc
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout/comment_1_fc8fa8020a9e542d90dd459799d6ec6e._comment b/doc/projects/datalad/bugs-done/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout/comment_1_fc8fa8020a9e542d90dd459799d6ec6e._comment
new file mode 100644
index 0000000000..c5ebf1c059
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout/comment_1_fc8fa8020a9e542d90dd459799d6ec6e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="sh@243262e07058e7517194e54030ce421ae984ea08"
+ nickname="sh"
+ avatar="http://cdn.libravatar.org/avatar/7655b4b31b41fda08031dadd660f1328"
+ subject="comment 1"
+ date="2022-02-04T07:58:20Z"
+ content="""
+181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b is the sha 256 hash for \"123\" is this intentional? 
+"""]]
diff --git a/doc/projects/datalad/bugs-done/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout/comment_2_dac0fc9914eff0e187d4cfe3c21348bc._comment b/doc/projects/datalad/bugs-done/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout/comment_2_dac0fc9914eff0e187d4cfe3c21348bc._comment
new file mode 100644
index 0000000000..9d0c488d70
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout/comment_2_dac0fc9914eff0e187d4cfe3c21348bc._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-02-07T16:16:37Z"
+ content="""
+This is a closed bug report and your comment is offtopic. But yes, the sha1
+of "123\n" is what you said it is. I suggest you ask about basics of
+hashing elsewhere though.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/man_page_for_command_misses_actual_command_in_the_synopsis_for_git-annex-checkpresentkey.mdwn b/doc/projects/datalad/bugs-done/man_page_for_command_misses_actual_command_in_the_synopsis_for_git-annex-checkpresentkey.mdwn
new file mode 100644
index 0000000000..60ae2ff36c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/man_page_for_command_misses_actual_command_in_the_synopsis_for_git-annex-checkpresentkey.mdwn
@@ -0,0 +1,19 @@
+[[!format sh """
+$> git annex version
+git-annex version: 6.20160126+gitg65f4442-1~ndall+1
+...
+$> man git-annex-checkpresentkey | head
+git-annex-checkpresentkey(1)               General Commands Manual               git-annex-checkpresentkey(1)
+
+NAME
+       git-annex-checkpresentkey - check if key is present in remote
+
+SYNOPSIS
+       git annex  key remote
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend.mdwn b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend.mdwn
new file mode 100644
index 0000000000..79f424e494
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+
+previously reported and partially addressed in [here](https://git-annex.branchable.com/bugs/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/)
+
+
+### What steps will reproduce the problem?
+
+try any presumably read-only annex operation (whereis, wanted, etc) on a repository where you have no write permissions.
+
+` -c annex.merge-annex-branches=false ` configuration switch was introduced to allow for running `whereis` in "read-only" mode.  But it requires user knowhow and good memory.
+It is also inconsistent with how `git` behaves in that it doesn't require any extra option and just handles it automagically/gracefully.
+
+If git-annex could automagically switch to such mode when encountering read-only repository, may be announcing that on stderr, that would make life so much easier.
+
+Also it seems that some commands are not even fully support it:
+
+```
+[d31548v@discovery7 1076_spacetop]$ git annex wanted here
+git-annex: /dartfs/rc/lab/D/DBIC/DBIC/archive/BIDS/Wager/Wager/1076_spacetop/.git/annex: openTempFile template locktmp: permission denied (Permission denied)
+git-annex: /dartfs/rc/lab/D/DBIC/DBIC/archive/BIDS/Wager/Wager/1076_spacetop/.git/annex: openTempFile template locktmp: permission denied (Permission denied)
+[d31548v@discovery7 1076_spacetop]$ git  -c annex.merge-annex-branches=false annex wanted here
+
+git-annex: /dartfs/rc/lab/D/DBIC/DBIC/archive/BIDS/Wager/Wager/1076_spacetop/.git/annex: openTempFile template locktmp: permission denied (Permission denied)
+[d31548v@discovery7 1076_spacetop]$ git annex version | head -n 1
+git-annex version: 8.20211117+git14-ge1f38b9dd-1~ndall+1
+```
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_10_d2242b526c7cce1084bbb63ef2bfe06a._comment b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_10_d2242b526c7cce1084bbb63ef2bfe06a._comment
new file mode 100644
index 0000000000..2ff530eb74
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_10_d2242b526c7cce1084bbb63ef2bfe06a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-12-30T16:43:10Z"
+ content="""
+@yoh I'm also planning to extend git-annex's test suite with checks that
+some of the basic queries work in readonly repos.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_1_c3fbb6eb15a510ae9b1af13cd7df028a._comment b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_1_c3fbb6eb15a510ae9b1af13cd7df028a._comment
new file mode 100644
index 0000000000..7cfba7c9f0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_1_c3fbb6eb15a510ae9b1af13cd7df028a._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-12-08T17:21:42Z"
+ content="""
+Firstly, you're overstating the problem. This does not affect queries in
+all read-only repositories. If the read-only repository does not have any
+remote git-annex branches that have not been merged into the local
+branch, the query will succeed. Only when there is such an unmerged branch
+will there be a permission error when it merges the annex branch.
+
+So, if you eg use `git anenx sync`, you would never end up in a situation
+where annex.merge-annex-branches is needed, because the remote git-annex
+branches are always merged by it.
+
+Setting annex.merge-annex-branches false manually is one thing,
+you know you are changing its behavior. Setting it implicitly due to
+permissions is another thing, what would result in git-annex query commands
+changing their behavior based on permissions. The previously linked thread
+discussed and rejected that idea, and rightly so.
+
+What I would be willing to do would be to have git-annex detect when it
+cannot merge remote annex branches, and skip the merging, and instead when
+querying the value of a file from the git-annex branch, also query the
+values from the unmerged remote branches, and combine them in memory the
+same as if a merge had been done. This would make git-annex query
+operations slower in this unusual situation, but they would always
+have the same result as if it was able to perform the merge.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_2_c33bf0bdf6bf85e4ee9e1286208c0b73._comment b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_2_c33bf0bdf6bf85e4ee9e1286208c0b73._comment
new file mode 100644
index 0000000000..69046ec7aa
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_2_c33bf0bdf6bf85e4ee9e1286208c0b73._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-12-08T17:38:54Z"
+ content="""
+I have not been able to reproduce the 
+`git -c annex.merge-annex-branches=false annex wanted here`
+problem. You apparently have annex.pidlock set since
+"locktmp" is used when doing pid locks, but despite setting that and having
+an unmerged remote git-annex branch, this is as close as I can get:
+
+	nobody@darkstar:/tmp/yyy$ git-annex wanted here
+	git-annex: /tmp/yyy/.git/annex: openTempFile template locktmp: permission denied (Permission denied)
+	wanted: 1 failed
+	nobody@darkstar:/tmp/yyy$ git -c annex.merge-annex-branches=false annex wanted here
+
+	nobody@darkstar:/tmp/yyy$
+
+Anyway, this is an entirely different problem and should be in its own bug
+report, once you determine how to reproduce it..
+"""]]
diff --git a/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_3_4c957c33a1c8dc179e0e6cd67a5a29d9._comment b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_3_4c957c33a1c8dc179e0e6cd67a5a29d9._comment
new file mode 100644
index 0000000000..b0837ff5eb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_3_4c957c33a1c8dc179e0e6cd67a5a29d9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2021-12-08T18:56:51Z"
+ content="""
++1 on the idea of \"combine them in memory the same as if a merge had been done.\" -- sounds great to me, even though indeed might cost some performance.  I would assume that with `annex.merge-annex-branches=false` such operation would be skipped, and then read-only operations would operate on current, possibly lacking some merges git-annex branch
+
+re \"wanted\": tried on the same repository, but it was updated so its git-annex branch is now up to date with the remote one... For now just managed to unravel a more of a UX issue: [https://git-annex.branchable.com/bugs/wanted_on_read-only_repo_crashes_/?updated](https://git-annex.branchable.com/bugs/wanted_on_read-only_repo_crashes_/?updated)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_4_497bbe4e351a66731c920ca5a2048c92._comment b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_4_497bbe4e351a66731c920ca5a2048c92._comment
new file mode 100644
index 0000000000..dc1c7a86e5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_4_497bbe4e351a66731c920ca5a2048c92._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-12-09T18:38:54Z"
+ content="""
+Yes, it seems like annex.merge-annex-branches=false should prevent it
+looking at unmerged sibling branches. Since it would be effectively
+doing an in-memory merge.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_5_53c317adf0ef48d9ba4af0571f9ded3f._comment b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_5_53c317adf0ef48d9ba4af0571f9ded3f._comment
new file mode 100644
index 0000000000..c917fc01ef
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_5_53c317adf0ef48d9ba4af0571f9ded3f._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-12-26T18:06:26Z"
+ content="""
+I have this mostly implemented, in the `readonly-annex-merge` branch.
+It seems to work well. Eg:
+
+	joey@darkstar:/tmp/a2>/usr/bin/git-annex whereis xxx
+	git-annex: .git/annex/journal.lck: openFd: permission denied (Permission denied)
+	- exit 1
+	joey@darkstar:/tmp/a2>~/bin/git-annex whereis xxx
+	whereis xxx (1 copy)
+	  	2a4e4ab8-6bc0-484b-aa4c-e54053cf1d87 -- joey@darkstar:/tmp/a1 [origin]
+	ok
+
+One sticking point is transitions. When a remote git-annex branch has a
+transition in it, and the transition has not yet been applied to the local
+branch and/or other remote git-annex branches, then as this is currently
+implemented, the transition will not be applied when doing the in-memory
+merge.
+
+Since the only transitions so far forget old history and dead remotes,
+it's not a major effect. It would only mean that some additional information
+about a dead remote would be displayed, or that `git-annex log` would
+display more history.
+
+Also, there are several couple of other things that look at the git-annex
+branch, beyond simply reading a single log file, and so do not look at
+unmerged branches. `git-annex log` does, --all does, etc. There are
+several more.
+
+These things break the invariant I am shooting for, that git-annex
+commands will behave the same whether they are in this readonly mode or
+not. They will need to be addressed before this is merged..
+"""]]
diff --git a/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_6_7fac2098e6d7cce997a540592e20c97a._comment b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_6_7fac2098e6d7cce997a540592e20c97a._comment
new file mode 100644
index 0000000000..81d360318d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_6_7fac2098e6d7cce997a540592e20c97a._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-12-27T17:38:49Z"
+ content="""
+Update: Completed and merged!
+
+Current list of items that need to be fixed before this is mergeable:
+
+- (fixed) When there is a transition in one of the remote git-annex branches
+  that has not yet been applied to the local or other git-annex branches.
+  Transitions are not handled.
+- (fixed) `git-annex log` runs git log on the git-annex branch, and so
+  it will not be able to show information coming from the other, not yet
+  merged branches. Fixed by making it error out in that situation.
+- (fixed) Annex.Branch.files only looks at files in the git-annex branch and not
+  unmerged branches. This affects git-annex info output when displaying
+  info for a remote or a uuid. Fixed by making info display "not available"
+  in that situation. Not ideal, it is a small difference in output compared
+  to when the repository is not read-only.
+- (fixed) Annex.Branch.hs.overBranchFileContents ditto. Affects --all and
+  also importfeed (but importfeed cannot work in a read-only repo
+  anyway). Fixed by making --all throw an error when there are unmerged
+  branches.
+- (fixed) CmdLine.Seek.seekFilteredKeys when precaching location logs.
+  Note use of Annex.Branch.fullname. Fixed by avoiding precaching
+  when there are unmerged git-annex branches. This fix will make some
+  things slower in a read-only repo.
+- (skip) Database.ContentIdentifier.needsUpdateFromLog and updateFromLog access
+  the branch manually and would not see unmerged branches. But updateFromLog
+  writes to the db so won't run in a readonly repo anyway, and so it seems
+  this can be skipped.
+- (skip) `--in=repository@{date}` uses loggedLocationsHistorical which uses
+  Annex.Branch.getHistorical, which does not look at unmerged branches.
+  But perhaps this is ok.. This uses the reflog, so when used to query
+  eg files that were present in the past, it means ones that the local
+  git-annex branch thought were present; other git-annex branches
+  may have had a different opinion but it will not show those.
+  And another way to look at it, the result for this will be the same
+  before and after merging those branches.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_7_05e4e6936d7b87cb21e312a7aa1731eb._comment b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_7_05e4e6936d7b87cb21e312a7aa1731eb._comment
new file mode 100644
index 0000000000..7d4ecd0ea9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_7_05e4e6936d7b87cb21e312a7aa1731eb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="thank you!"
+ date="2021-12-29T02:00:48Z"
+ content="""
+woohoo ! Great to see such productive holidays! ;)  I will give it a try as soon as I can and I guess we should then add some unittests within datalad for typical readonly operations within CI (we already \"abuse\" `sudo` in a few spots for similar needs).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_8_ccb6c9756a2fcf75be8049d89731a5bf._comment b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_8_ccb6c9756a2fcf75be8049d89731a5bf._comment
new file mode 100644
index 0000000000..5e4ac396f6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_8_ccb6c9756a2fcf75be8049d89731a5bf._comment
@@ -0,0 +1,52 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="very much appreciated"
+ date="2021-12-29T17:20:29Z"
+ content="""
+Bravo! Readonly annex merge support seems to mostly work on Windows, too, which frankly surprised me a bit. I was under
+the impression that Windows was kind of a lost cause at times and no readonly-type support would be forthcoming on this
+platform. :D So colour me surprised when `wanted`, `whereis` and `log` worked just like that. Only `info` gave me
+trouble when I targeted a directory or file with it:
+
+[[!format sh \"\"\"
+B:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex info C4A845FD48C3E1A9-00-00.mrimg
+file: C4A845FD48C3E1A9-00-00.mrimg
+size: 184.64 gigabytes
+key: BLAKE2B160E-s184642714873--e802cd1a09bf66dc07959b4935116fe1fb5d39a7.mrimg
+present: sqlite worker thread crashed: user error (SQLite3 returned ErrorCan'tOpen while attempting to perform prepare \"SELECT null from content limit 1\": unable to open database file(while opening database connection))
+git-annex: sqlite query crashed: thread blocked indefinitely in an MVar operation
+CallStack (from HasCallStack):
+  error, called at .\Database\Handle.hs:79:40 in main:Database.Handle
+\"\"\"]]
+
+An argumentless `info` works just fine:
+
+[[!format sh \"\"\"
+B:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex info
+trusted repositories: 0
+semitrusted repositories: 8
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        3362df51-1789-4471-96a0-d2267ada6aa4 -- Reflect-varmistukset [origin]
+        46a41e47-45c8-4a86-b348-db0c4cfb18f3 -- Reflect-varmistukset [reflect-varm-k-levy]
+        489cdd9b-d71f-4a62-a48a-0279ec6f2245 -- Reflect-varm-ylivuoto1 [here]
+        dc778e0b-c470-4c69-960f-29cbfebd5bb9 -- jkniiv@AINESIS:K:\Reflect-varmistukset
+        ed923fc2-f2d9-46a6-813d-a0799d735d5c -- Reflect-varmistukset
+        fd6945cc-15db-406c-8653-31f1351e5051 -- Reflect-varmistukset
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 305.55 gigabytes (+1 megabyte reserved)
+local annex keys: 1
+local annex size: 184.64 gigabytes
+annexed files in working tree: 73
+size of annexed files in working tree: 3.02 terabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage:
+        BLAKE2B160E: 64
+        MD5E: 9
+\"\"\"]]
+
+Should I file a bug, Joey? Or do you still think this is hardly worth pursuing? :)
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_9_49cda6f52fa4fb527b392f6ee6bae078._comment b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_9_49cda6f52fa4fb527b392f6ee6bae078._comment
new file mode 100644
index 0000000000..9b6c23c4ab
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/merge-annex-branches__61__false_-_automate_and_extend/comment_9_49cda6f52fa4fb527b392f6ee6bae078._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-12-30T16:34:03Z"
+ content="""
+@jkniiv that may somehow be windows-specific, if opening a sqlite database
+on windows in order to only query it needs write access.
+
+I did try this on linux with an unlocked file and it did not crash, but the
+file was already present in the database. I also tried with the keysdb
+deleted, and it still worked. I'm sure that there are situations though
+where the database is not updated where it will try to populate it before
+querying it, which will fail when it cannot write.
+
+It would be worth filing new bug reports for such issues. Although
+when write access is unavoidable, I might just have to close them.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb.mdwn b/doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb.mdwn
new file mode 100644
index 0000000000..c07ca6920d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb.mdwn
@@ -0,0 +1,54 @@
+With 88a7fb5cb (convert all applicable commands to new 2x faster
+annexed file seeking, 2020-07-10), the following script hangs on the
+last command.
+
+[[!format sh """
+cd "$(mktemp -d ${TMPDIR:-/tmp}/ga-metadata-XXXXXXX)"
+git init
+git annex init
+echo 0 >f0
+echo 1 >f1
+git annex add f0 f1
+git commit -mc0
+git annex metadata --debug --remove a .
+"""]]
+
+Here's the output, where the git-ls-files call is the spot of the
+hang:
+
+```
+[... 13 lines ...]
+[2020-07-10 21:04:33.030754298] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2020-07-10 21:04:33.032022677] process done ExitSuccess
+[2020-07-10 21:04:33.032205649] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2020-07-10 21:04:33.033970479] process done ExitSuccess
+[2020-07-10 21:04:33.034308573] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2020-07-10 21:04:33.035040652] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2020-07-10 21:04:33.037070231] process done ExitSuccess
+[2020-07-10 21:04:33.037281793] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2020-07-10 21:04:33.038995286] process done ExitSuccess
+[2020-07-10 21:04:33.03938464] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..d39f6bdff82a20be7edf466ba572877de0db0daf","--pretty=%H","-n1"]
+[2020-07-10 21:04:33.041697801] process done ExitSuccess
+[2020-07-10 21:04:33.042060234] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2020-07-10 21:04:33.047868787] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2020-07-10 21:04:33.049298291] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--","."]
+[2020-07-10 21:04:42.432722123] process done ExitFailure (-2)
+```
+
+On the parent of the commit, this completes fine, with the expected
+"use --force" failure.
+
+```
+[... 13 lines ...]
+[2020-07-10 21:02:36.753459763] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2020-07-10 21:02:36.756144724] process done ExitSuccess
+[2020-07-10 21:02:36.756300697] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2020-07-10 21:02:36.758083727] process done ExitSuccess
+[2020-07-10 21:02:36.758319366] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","-z","--cached","--","."]
+git-annex: Not recursively setting metadata. Use --force to do that.
+```
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb/comment_1_5a7d8371910b27a82e479bdf3bb63d8f._comment b/doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb/comment_1_5a7d8371910b27a82e479bdf3bb63d8f._comment
new file mode 100644
index 0000000000..270438387f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb/comment_1_5a7d8371910b27a82e479bdf3bb63d8f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-07-13T16:24:55Z"
+ content="""
+Aha, seekFilteredKeys is not prepared for the file list action that's
+passed to it to throw an exception, but in this one case at least, it can.
+
+Thanks for reporting, I've fixed it.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb/comment_2_bdc4f86afd827beb20b3d888d96aefe9._comment b/doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb/comment_2_bdc4f86afd827beb20b3d888d96aefe9._comment
new file mode 100644
index 0000000000..ef50111eac
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb/comment_2_bdc4f86afd827beb20b3d888d96aefe9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-07-13T16:43:35Z"
+ content="""
+Also the test case was not testing the metadata command at all, added some
+tests.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb/comment_2_d3c6aa8c91630d4bb40b3267bfdebfbf._comment b/doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb/comment_2_d3c6aa8c91630d4bb40b3267bfdebfbf._comment
new file mode 100644
index 0000000000..c6c4a24327
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/metadata_--remove_stalls_as_of_88a7fb5cb/comment_2_d3c6aa8c91630d4bb40b3267bfdebfbf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 2"
+ date="2020-07-13T16:50:36Z"
+ content="""
+Wonderful.  Thanks for the quick fix.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/mysterious_dependency_of_git_annex_status_output_of_the_added_file.mdwn b/doc/projects/datalad/bugs-done/mysterious_dependency_of_git_annex_status_output_of_the_added_file.mdwn
new file mode 100644
index 0000000000..1666dcd2bb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/mysterious_dependency_of_git_annex_status_output_of_the_added_file.mdwn
@@ -0,0 +1,84 @@
+### Please describe the problem.
+
+in v6 mode -- Result depends on having a good sleep before running 'git annex add'.
+
+Without sleep, git annex manages first to stage file to be committed into git, but then also modifies it to be added into annex  (this is not shown above -- just inspect that repository obtained without having any sleep)
+
+I guess relates to http://git-annex.branchable.com/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/
+
+### What steps will reproduce the problem?
+
+Run http://www.onerussian.com/tmp/ga-3.sh  twice:  once giving 0 secs to sleep, and then 1 (or about 0.3 might work as well)
+
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170209+gitg16be7b5cc-1~ndall+1
+
+### Please provide any additional information below.
+
+if we just proceed with the script (init, add, status) without any delays -- git annex status would report it 
+[[!format sh """
+$> ./ga-3.sh 0
++ s=0
+++ mktemp -d
++ d=/home/yoh/.tmp/tmp.d6g0E7scxt
++ echo 'directory: /home/yoh/.tmp/tmp.d6g0E7scxt'
+directory: /home/yoh/.tmp/tmp.d6g0E7scxt
++ cd /home/yoh/.tmp/tmp.d6g0E7scxt
++ git init
+Initialized empty Git repository in /tmp/tmp.d6g0E7scxt/.git/
++ git annex init --version=6
+init  ok
+(recording state in git...)
++ sed -i -e 's,pre-commit ,pre-commit --debug ,g' .git/hooks/pre-commit
++ echo 'I: creating a file'
+I: creating a file
++ echo whatever
++ sleep 0
++ git -c annex.largefiles=nothing annex --debug add file5
+[2017-02-17 10:19:48.91932971] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--others","--exclude-standard","-z","--","file5"]
+add file5 (non-large file; adding content to git repository) ok
+[2017-02-17 10:19:48.923428344] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--modified","-z","--","file5"]
+(recording state in git...)
+[2017-02-17 10:19:48.927922289] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"]
+[2017-02-17 10:19:48.956812867] process done ExitSuccess
++ git annex status
+M file5
+"""]]
+
+And if we wait just a bit before running add -- we would get it reported added
+[[!format sh """
+hopa:~/.tmp
+$> ./ga-3.sh 1
++ s=1
+++ mktemp -d
++ d=/home/yoh/.tmp/tmp.4I7ym6dSx2
++ echo 'directory: /home/yoh/.tmp/tmp.4I7ym6dSx2'
+directory: /home/yoh/.tmp/tmp.4I7ym6dSx2
++ cd /home/yoh/.tmp/tmp.4I7ym6dSx2
++ git init
+Initialized empty Git repository in /tmp/tmp.4I7ym6dSx2/.git/
++ git annex init --version=6
+init  ok
+(recording state in git...)
++ sed -i -e 's,pre-commit ,pre-commit --debug ,g' .git/hooks/pre-commit
++ echo 'I: creating a file'
+I: creating a file
++ echo whatever
++ sleep 1
++ git -c annex.largefiles=nothing annex --debug add file5
+[2017-02-17 10:19:52.529445464] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--others","--exclude-standard","-z","--","file5"]
+add file5 (non-large file; adding content to git repository) ok
+[2017-02-17 10:19:52.533532166] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--modified","-z","--","file5"]
+(recording state in git...)
+[2017-02-17 10:19:52.537789158] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"]
+[2017-02-17 10:19:52.567222419] process done ExitSuccess
++ git annex status
+A file5
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[[done]]
diff --git a/doc/projects/datalad/bugs-done/mysterious_dependency_of_git_annex_status_output_of_the_added_file/comment_1_4d7eb95c73eceb079a176db1957df25e._comment b/doc/projects/datalad/bugs-done/mysterious_dependency_of_git_annex_status_output_of_the_added_file/comment_1_4d7eb95c73eceb079a176db1957df25e._comment
new file mode 100644
index 0000000000..80a863de50
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/mysterious_dependency_of_git_annex_status_output_of_the_added_file/comment_1_4d7eb95c73eceb079a176db1957df25e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="benjamin.poldrack@d09ccff6d42dd20277610b59867cf7462927b8e3"
+ nickname="benjamin.poldrack"
+ avatar="http://cdn.libravatar.org/avatar/5c1a901caa7c2cfeeb7e17e786c5230d"
+ subject="comment 1"
+ date="2017-02-24T13:00:08Z"
+ content="""
+I just want to point out, that this is most likely related to this one: <http://git-annex.branchable.com/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/>
+
+Generally, we get into trouble with files in git in v6 repos everytime. Pretty much the same thing happens, if we clone an annex repo with a file directly in git and then `git annex init --version=6` that clone. In that case, I can't avoid it with such a delay. However, all of this doesn't happen if I do it manually via single commands in the shell, but does, if it's done in a script. In some way, that smudge filter seems run out of sync with the command call triggering it.
+
+[[ben]]
+"""]]
diff --git a/doc/projects/datalad/bugs-done/mysterious_dependency_of_git_annex_status_output_of_the_added_file/comment_2_ef55541955a6a8840a63309aa403ecae._comment b/doc/projects/datalad/bugs-done/mysterious_dependency_of_git_annex_status_output_of_the_added_file/comment_2_ef55541955a6a8840a63309aa403ecae._comment
new file mode 100644
index 0000000000..287e79a584
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/mysterious_dependency_of_git_annex_status_output_of_the_added_file/comment_2_ef55541955a6a8840a63309aa403ecae._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="fixed"
+ date="2018-09-10T18:27:49Z"
+ content="""
+As far as I can tell, this was fixed by 10138056d (v6: avoid accidental conversion when annex.largefiles is not configured, 2018-08-27).
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/new_whereis_--json_lost_information_about_web_urls_if_other_special_remotes_provide_them.mdwn b/doc/projects/datalad/bugs-done/new_whereis_--json_lost_information_about_web_urls_if_other_special_remotes_provide_them.mdwn
new file mode 100644
index 0000000000..8baa22fd57
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/new_whereis_--json_lost_information_about_web_urls_if_other_special_remotes_provide_them.mdwn
@@ -0,0 +1,94 @@
+### Please describe the problem.
+
+With upgrade to 6.20160114+gitg6be9ee0-1~ndall+1 our (datalad) tests started to fail since apparently format of whereis --json has changed.  It changed probably for the best since now no need to parse out urls from the generic 'note' field.  BUT it seems that it has lost 1. ability to associate urls with remotes 2. doesn't list web remote urls if another remote provides urls as well
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> git annex whereis  sub001/BOLD/task001_run001/bold.nii.gz                          
+whereis sub001/BOLD/task001_run001/bold.nii.gz (3 copies) 
+  	00000000-0000-0000-0000-000000000001 -- web
+   	70d0c2f3-0d57-485c-8802-f6e829503516 -- [datalad-archives]
+   	bb907499-dbea-4713-977f-0ccd209de415 -- yoh@hopa:~/datalad/crawl/openfmri/ds000005 [here]
+
+  web: http://www.onerussian.com/tmp/banner.png
+  web: http://www.onerussian.com/tmp/bold.nii.gz
+
+  datalad-archives: dl+archive:SHA256E-s110760--5c9a3b565944b84c7df381481b597d716061881cbfc85493317452e85ea9b391.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz
+  datalad-archives: dl+archive:SHA256E-s111649--63c9168b53e033c29d188b97d4950e267fa93a4d991fc92f42a3bb9488013863.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz
+  datalad-archives: dl+archive:SHA256E-s112069--f1afedb105994006cbf37c03e2a05b538397283701c5a9bee483287ca912d690.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz
+  datalad-archives: dl+archive:SHA256E-s154612--8adda02a8bc1a88f864f2cff31766f5ad4fcefbb42afd7230f95edfb5e0dfcb1.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz
+ok
+
+$> git annex whereis --json sub001/BOLD/task001_run001/bold.nii.gz | python -m json.tool                      
+{            
+    "command": "whereis",
+    "file": "sub001/BOLD/task001_run001/bold.nii.gz",
+    "note": "\t00000000-0000-0000-0000-000000000001 -- web\n \t70d0c2f3-0d57-485c-8802-f6e829503516 -- [datalad-archives]\n \tbb907499-dbea-4713-977f-0ccd209de415 -- yoh@hopa:~/datalad/crawl/openfmri/ds000005 [here]\n",
+    "success": true,
+    "untrusted": [],
+    "urls": [
+        "dl+archive:SHA256E-s110760--5c9a3b565944b84c7df381481b597d716061881cbfc85493317452e85ea9b391.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz",
+        "dl+archive:SHA256E-s111649--63c9168b53e033c29d188b97d4950e267fa93a4d991fc92f42a3bb9488013863.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz",
+        "dl+archive:SHA256E-s112069--f1afedb105994006cbf37c03e2a05b538397283701c5a9bee483287ca912d690.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz",
+        "dl+archive:SHA256E-s154612--8adda02a8bc1a88f864f2cff31766f5ad4fcefbb42afd7230f95edfb5e0dfcb1.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz"
+    ],
+    "whereis": [
+        {
+            "description": "web",
+            "here": false,
+            "uuid": "00000000-0000-0000-0000-000000000001"
+        },
+        {
+            "description": "[datalad-archives]",
+            "here": false,
+            "uuid": "70d0c2f3-0d57-485c-8802-f6e829503516"
+        },
+        {
+            "description": "yoh@hopa:~/datalad/crawl/openfmri/ds000005",
+            "here": true,
+            "uuid": "bb907499-dbea-4713-977f-0ccd209de415"
+        }
+    ]
+}
+
+"""]]
+
+as you can see -- only --json format is missing on web remote URLs.  I guess, ideally, "urls" should also be an associative array with keys corresponding to remote names and listing them under.  OR why not to list them within the remote record under 'whereis'?  Sounds like the most logical place for them to be at, e.g.
+
+[[!format sh """
+
+    "whereis": [
+        {
+            "description": "web",
+            "here": false,
+            "uuid": "00000000-0000-0000-0000-000000000001",
+            "urls": [ "http://www.onerussian.com/tmp/bold.nii.gz"]
+        },
+        {
+            "description": "[datalad-archives]",
+            "here": false,
+            "uuid": "70d0c2f3-0d57-485c-8802-f6e829503516"
+            "urls": [
+        "dl+archive:SHA256E-s110760--5c9a3b565944b84c7df381481b597d716061881cbfc85493317452e85ea9b391.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz",
+        "dl+archive:SHA256E-s111649--63c9168b53e033c29d188b97d4950e267fa93a4d991fc92f42a3bb9488013863.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz",
+        "dl+archive:SHA256E-s112069--f1afedb105994006cbf37c03e2a05b538397283701c5a9bee483287ca912d690.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz",
+        "dl+archive:SHA256E-s154612--8adda02a8bc1a88f864f2cff31766f5ad4fcefbb42afd7230f95edfb5e0dfcb1.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz"
+    ],
+
+
+        },
+        {
+            "description": "yoh@hopa:~/datalad/crawl/openfmri/ds000005",
+            "here": true,
+            "uuid": "bb907499-dbea-4713-977f-0ccd209de415"
+        }
+    ]
+"""]]
+
+what is the purpose of note in current output anyways since it just duplicates information in 'whereis' field?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__.mdwn b/doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__.mdwn
new file mode 100644
index 0000000000..2ecb0c10c5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+Recent git-annex release [triggered a number of datalad test fails](https://github.com/datalad/datalad/issues/6492).
+
+One of them is attempted to workaround in [datalad/pull/6510](https://github.com/datalad/datalad/pull/6510) is due to the fact that `annex find` did not only change its output (which seems to ignore having `--json --json-error-messages` and not providing json records with errors) but also not even exiting no longer with non-0 exit code:
+
+```
+(git-annex)lena:/tmp/testds[master]
+$> git annex find --copies 0 --json --json-error-messages qwdqwd csdc
+error: pathspec 'qwdqwd' did not match any file(s) known to git
+error: pathspec 'csdc' did not match any file(s) known to git
+Did you forget to 'git add'?
+
+$> echo $?
+0
+
+$> git annex version
+git-annex version: 10.20220222+git23-g51c528980-1~ndall+1
+```
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__/comment_1_ac192db19137f8b65a13a2c3f7f454a9._comment b/doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__/comment_1_ac192db19137f8b65a13a2c3f7f454a9._comment
new file mode 100644
index 0000000000..5b551d654b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__/comment_1_ac192db19137f8b65a13a2c3f7f454a9._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-28T16:07:31Z"
+ content="""
+This is the annex.skipunknown transition so you can set that to true to get
+back the previous behavior. (See NEWS)
+
+However, I do not think that was intended to result in this behavior when
+the specified files do not exist at all, it was only supposed to make it
+skip files that exist but are not checked into git. So this does seem like
+a bug.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__/comment_2_88d08c4b269c075e0724fa1bce70f671._comment b/doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__/comment_2_88d08c4b269c075e0724fa1bce70f671._comment
new file mode 100644
index 0000000000..4d2df38d4f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__/comment_2_88d08c4b269c075e0724fa1bce70f671._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-02-28T16:11:46Z"
+ content="""
+Also, the docs for annex.skipunknown say that a command should exit nonzero
+if all files in a directory are not checked into git, but it does not
+behave that way either. It seems that it needs to propagate a nonzero exit
+status of git-ls-files at least for that, if not for also the handling of
+files that do not exist.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__/comment_3_28060f4bb31730e3334cf3db56fc032b._comment b/doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__/comment_3_28060f4bb31730e3334cf3db56fc032b._comment
new file mode 100644
index 0000000000..c824282c37
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/no_longer_non-0_exit_for___34__find_..._nonexisting__34__/comment_3_28060f4bb31730e3334cf3db56fc032b._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-02-28T16:32:08Z"
+ content="""
+I've fixed it to propagate the non-zero exit status from git ls-files.
+
+The git ls-files message still goes to stderr, not to
+--json-error-messages, the same as any stderr output by a git command
+that git-annex runs. And this is actually not a behavior change;
+the old git-annex output of "not found" did not get included in
+--json-error-messages either:
+
+	joey@darkstar:/tmp/mmm>/usr/bin/git-annex drop dne foo --json --json-error-messages
+	git-annex: dne not found
+	{"command":"drop","wanted":[],"note":"unsafe\nCould only verify the existence of 0 out of 1 necessary copy\n(Use --force to override this check, or adjust numcopies.)","success":false,"input":["foo"],"key":"SHA256E-s3--98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4","error-messages":[],"file":"foo/bar"}
+	drop: 2 failed
+
+Bear in mind that --json-error-messages
+is about errors encountered while processing a particular file that it
+outputs a json record for. This error comes before it starts processing any
+particular file. Also, of course, error messages output by git commands
+are never included in --json-error-messages.
+
+I think it might be a good idea to add an actual API for detecting when
+there is this kind of problem, so datalad does not have to parse
+error messages (which could easily change). But that would need to be a
+separate discussion. I've opened
+[[todo/api_for_telling_when_nonexistant_or_non_git_files_passed]] for that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink.mdwn b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink.mdwn
new file mode 100644
index 0000000000..bf2593f8c8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+
+Ref: Original issue and finding [report against datalad](https://github.com/datalad/datalad/issues/5015#issuecomment-709436065).
+
+
+### What version of git-annex are you using? On what operating system?
+
+Windows 8.20200815-g335aae266  (I see now that I might benefit from update, but I found no related issue so likely it is something new)
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+{920}[Level 5] CommandError: '"git" "annex" "add" "-c" "annex.dotfiles=true" "-c" "annex.retry=3" "--json" "--json-error-messages" "--debug" "--" "file.dat"' failed with exitcode 1 under C:\Users\DataLad\AppData\Local\Temp\datalad_temp_tree_q4wxn05d [out: '{"command":"add","success":false,"error-messages":["  file.dat failed to link to annex"],"file":"file.dat"}'] [err: '[2020-10-15 11:57:07.4657537] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.dotfiles=true","-c","annex.retry=3","show-ref","git-annex"]
+| [2020-10-15 11:57:07.4813787] process done ExitSuccess
+| [2020-10-15 11:57:07.4813787] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.dotfiles=true","-c","annex.retry=3","show-ref","--hash","refs/heads/git-annex"]
+...
+| [2020-10-15 11:57:07.6376287] call: cp ["--reflink=auto","-a","file.dat",".git\\annex\\objects\\6f0\\fbd\\SHA256E-s7--ed7002b439e9ac845f22357d822bac1444730fbdb6016d3ec9432297b9ec9f73.dat\\SHA256E-s7--ed7002b439e9ac845f22357d822bac1444730fbdb6016d3ec9432297b9ec9f73.dat"]
+| "cp": unrecognized option `--reflink=auto'
+| Try `"cp" --help' for more information.
+| [2020-10-15 11:57:07.6532537] process done ExitFailure 1
+
+C:\tmp>cp --help | grep ref
+  -d                           same as --no-dereference --preserve=link
+  -L, --dereference            always follow symbolic links
+  -P, --no-dereference         never follow symbolic links
+
+C:\tmp>cp --version
+cp (GNU coreutils) 5.97
+Copyright (C) 2006 Free Software Foundation, Inc.
+This is free software.  You may redistribute copies of it under the terms of
+the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
+There is NO WARRANTY, to the extent permitted by law.
+
+Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.
+"""]]
+
+if I parsed NEWS.gz correctly, that option was added in `* Noteworthy changes in release 8.0 (2009-10-06) [beta]` . So I wonder if `git-annex` could sense for version of `cp` or presence of `--reflink` option and not use it if `cp` is too old?
+
+Meanwhile I will see if there is some sensible way to get more uptodate coreutils (or `cp`) at least within conda env
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]](ish) --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_10_53714ec51d6ae4769f6c4dd9ee46ebae._comment b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_10_53714ec51d6ae4769f6c4dd9ee46ebae._comment
new file mode 100644
index 0000000000..1d3818d985
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_10_53714ec51d6ae4769f6c4dd9ee46ebae._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-06-28T16:34:31Z"
+ content="""
+Since this bug was opened, some uses of cp have been converted to git-annex
+doing the copy itself without cp, first probing for CoW support.
+
+I do not think that the places mentioned in this bug report where cp fails
+are ones that have been converted yet.
+The most likely way to fix this bug would be to convert them. But the need
+to remember what directory combinations it's probed for CoW support in and
+so avoid probing for CoW support every time complicates that conversion.
+See related: [[todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__]]
+
+But I don't think git-annex will ever stop relying on programs bundled with
+it (when not packaged with a package manager that supports deps). It's much
+easier to reimplement cp than gpg or ssh. So these version skews are always
+a potential problem, when people are doing things that put other programs
+ahead of the ones bundled with git-annex in PATH. So the benefit of
+avoiding external cp entirely just doesn't seem compelling.
+
+I've disabled using --reflink=auto on windows. Going to close this with
+that. 
+"""]]
diff --git a/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_1_44965e93c65148f06bf4fe4cad95993c._comment b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_1_44965e93c65148f06bf4fe4cad95993c._comment
new file mode 100644
index 0000000000..00090cafda
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_1_44965e93c65148f06bf4fe4cad95993c._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2020-10-16T01:29:22Z"
+ content="""
+a mental note... building git-annex in a windows vm ATM, and saw
+
+```
+> stack ghc --no-haddock --package nsis Build/NullSoftInstaller.hs
+...
+[36 of 36] Compiling StackSetupShim   ( C:\\sr\setup-exe-src\setup-shim-Z6RU0evB.hs, C:\\tmp\git-annex\.stack-work\dist\
+29cc6475\setup\StackSetupShim.o )
+Linking C:\\tmp\\git-annex\\.stack-work\\dist\\29cc6475\\setup\\setup.exe ...
+  checking UPGRADE_LOCATION... http://downloads.kitenet.net/git-annex/windows/current/git-annex-installer.exe
+  checking git... yes
+  checking git version... 2.23.0.windows.1
+  checking cp -a... yes
+  checking cp -p... yes
+  checking cp --preserve=timestamps... yes
+  checking cp --reflink=auto... yes
+...
+  checking ssh connection caching... no
+Configuring git-annex-8.20201007...
+```
+
+so either the check is wrong or there are multiple `cp` around (may be some came with `stack`?) ... I found total over 10 different cp.exe on drive (didn't check yet how many in PATH). But I just wonder, if check is done at build time, but `cp` is not distributed along, the check should be done at run time instead.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_2_4a704f47a709a9de35358d6d2fb9fe20._comment b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_2_4a704f47a709a9de35358d6d2fb9fe20._comment
new file mode 100644
index 0000000000..cddb1f8f38
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_2_4a704f47a709a9de35358d6d2fb9fe20._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-10-16T01:50:39Z"
+ content="""
+in datalad we took an approach that \"if bundled git-annex is used, use by default git which comes with it\".  If assumption here for Windows is that \"cp which comes with git should be used\", then git-annex needs to use a specific PATH to use that one, and not some other which might be found in the PATH.  The situation is a bit messy though since `git.exe` is at `/c/Program Files (x86)/Git/cmd/git.exe` (pasting from mingw'ed bash) while `cp` is under `/c/Program Files (x86)/Git/usr/bin/cp.exe` so not exactly the same directory, but I guess consistent for all Windows'es.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_3_fea65a7f0218ccf27446ee7ce6fc017e._comment b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_3_fea65a7f0218ccf27446ee7ce6fc017e._comment
new file mode 100644
index 0000000000..ad1f270bc0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_3_fea65a7f0218ccf27446ee7ce6fc017e._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-10-19T16:19:49Z"
+ content="""
+I'm not going to make git-annex probe everything at run time. The
+user can find more ways to break their environment than I can probe for,
+and sheer code complexity, and runtime complexity, and debug complexity, 
+and run time would all be affected.
+
+The way git-annex is installed into git for windows's path is supposed to both
+make "git annex" work and also put it in the same directory that git for
+windows installs curl and cp. IIRC on windows a program automatically
+looks in its directory along with the path, so that makes them available
+to git-annex. There are probably configurations that make some other path
+be used in preference, or perhaps something changed in git for windows's
+locations of these things, although the path you show sounds like the same
+one I'd expect git-annex.exe to be in. I do know that used to work.
+
+--reflink seems unlikely to do anything useful on windows
+even if the option is supported, so it could just be defaulted to not
+supported on windows. -a/-p/--preserve-timestamps are more important and
+also probed at build time.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_4_c2d4485b2a49ada5ab5266e30df91b0b._comment b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_4_c2d4485b2a49ada5ab5266e30df91b0b._comment
new file mode 100644
index 0000000000..da50534ae3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_4_c2d4485b2a49ada5ab5266e30df91b0b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-10-19T16:39:28Z"
+ content="""
+I installed git for windows in a fresh windows 10
+VM. Then I installed git-annex from the git-annex for windows installer. 
+Then I ran git-annex add, which ran cp --reflink successfully.
+
+But you didn't say how you installed git-annex on windows, did you?
+I guess, since you're building it yourself, you put it into path somewhere
+else. So it seems to me, it's the up to you to make its path include the
+same cp you built it against. 
+
+Or just build the windows installer too, and install your git-annex build
+using that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_5_94d4cc9baf46fbc09c21abd08b441b0c._comment b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_5_94d4cc9baf46fbc09c21abd08b441b0c._comment
new file mode 100644
index 0000000000..37bfbc60ba
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_5_94d4cc9baf46fbc09c21abd08b441b0c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2020-10-20T12:29:19Z"
+ content="""
+It isn't exactly \"how git-annex installed\" but rather, what else is installed besides git-annex.  Recommended way to install datalad on OSX and Windows is via [anaconda](https://www.anaconda.com/) or [miniconda](https://docs.conda.io/en/latest/miniconda.html) from conda-forge channel.  See  So it places itself into `PATH` ahead of the rest, and it is the one which comes ATM with outdated `cp`.
+[It seems](https://github.com/conda-forge/coreutils-feedstock/issues/8) that `cp` might come also with `git` package there, and I have initiated (but didn't progress) [effort](https://github.com/conda-forge/coreutils-feedstock/issues/8) to build newer coreutils for Windows for conda-forge. (there is also some other m2sys channel with somewhat newer coreutils build, but mixing channels that much is begging for more of other issues).  So, eventually, I hope that there would be updated `cp` available by default with `datalad` installation, but the point is that unless git-annex uses the specific `cp` it knows about, it could be some other `cp` in its way.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_6_db5de257e8cfb468bf31d46065b7d251._comment b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_6_db5de257e8cfb468bf31d46065b7d251._comment
new file mode 100644
index 0000000000..3ef5e305ed
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_6_db5de257e8cfb468bf31d46065b7d251._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2020-10-20T12:33:29Z"
+ content="""
+> --reflink seems unlikely to do anything useful on windows even if the option is supported, so it could just be defaulted to not supported on windows. 
+
+yeap, sounds good to me ATM.
+
+> -a/-p/--preserve-timestamps are more important and also probed at build time.
+
+If I read NEWS correctly, it was added in 4.1.10, so old enough (was I even born then?) ;) 
+"""]]
diff --git a/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_7_644826ed86849eb4babf37bea3937a7c._comment b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_7_644826ed86849eb4babf37bea3937a7c._comment
new file mode 100644
index 0000000000..b15f51beb5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_7_644826ed86849eb4babf37bea3937a7c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2020-10-20T16:39:15Z"
+ content="""
+oh, just now realized that `git-annex.exe` is in **exactly** the same `C:\Program Files (x86)\Git\usr\bin` as `cp` etc -- so specifying specific path of where `git-annex.exe` installed (I bet the process would know which dir it is coming from) to `cp` and all those tools for a windows build could potentially make those installations more robust overall.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_8_dd50ae03bc9a71e04528ac793e79a8b2._comment b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_8_dd50ae03bc9a71e04528ac793e79a8b2._comment
new file mode 100644
index 0000000000..53218d2137
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_8_dd50ae03bc9a71e04528ac793e79a8b2._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2020-10-22T17:41:49Z"
+ content="""
+If whatever is putting itself at the front of PATH, I think it would
+also risk breaking any part of git that expects to run another part of it
+by path. Including any git commands that use the bundled cp or other
+unix commands.
+
+Perhaps the problem is that you're mixing two different package systems?
+If there's going to be a datalad package, there should also be a git-annex
+package, and then it can be built to use the right cp options for its
+distibution.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_9_552e36f88bc39bc68b65ccba06002082._comment b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_9_552e36f88bc39bc68b65ccba06002082._comment
new file mode 100644
index 0000000000..70fa26315b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/old__40__er__41___cp_from_coreutils_lacks_--reflink/comment_9_552e36f88bc39bc68b65ccba06002082._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 9"
+ date="2020-10-27T19:30:24Z"
+ content="""
+Working in the same environment as in [the other issue](https://git-annex.branchable.com/bugs/git-annex_looses_itself_on_Windows__63__/?updated).  It does come with more recent `cp` (coreutils) 8.25 BUT that one blows with (sorry -- this is debug output of datalad, not direct output from git/annex invocation):
+
+<details>
+<summary></summary> 
+
+```shell
+datalad.cmd: DEBUG: Async run ['git', '-c', 'annex.largefiles=nothing', 'add', '--dry-run', '-N', '--ignore-missing', '--verbose', '--', 'fi le.dat']
+datalad.cmd: DEBUG: Launching process ['git', '-c', 'annex.largefiles=nothing', 'add', '--dry-run', '-N', '--ignore-missing', '--verbose', '--', 'fi le.dat']
+datalad.cmd: DEBUG: Process 2932 started
+datalad.cmd: DEBUG: Waiting for process 2932 to complete
+datalad.cmd: DEBUG: Process 2932 exited with return code 0
+datalad.cmd: DEBUG: Process file list chunk 0 (length 1)
+datalad.annex: DEBUG: Running add resulted in stderr output: cp: preserving permissions for ‘.git\\annex\\objects\\6f0\\fbd\\SHA256E-s7--ed7002b439e9ac845f22357d822bac1444730fbdb6016d3ec9432297b9ec9f73.dat\\SHA256E-s7--ed7002b439e9ac845f22357d822bac1444730fbdb6016d3ec9432297b9ec9f73.dat’: Not supported
+git-annex: add: 1 failed
+
+```
+</details>
+
+so it echoes your \"-a/-p/--preserve-timestamps are more important and also probed at build time.\" and is yet another gotcha of using different build and run environments. I only wonder how is that our github windows workflow environment supports `cp` with preserving permissions while conda's doesn't
+"""]]
diff --git a/doc/projects/datalad/bugs-done/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages.mdwn b/doc/projects/datalad/bugs-done/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages.mdwn
new file mode 100644
index 0000000000..57bb645ee0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages.mdwn
@@ -0,0 +1,60 @@
+### Please describe the problem.
+
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+lena:/tmp
+$> git clone http://kumo.ovgu.de/~mih/myHP/bd2/4e4aa-7aea-11e6-9d5d-002590f97d84/
+Cloning into '4e4aa-7aea-11e6-9d5d-002590f97d84'...
+
+$> cd 4e4aa-7aea-11e6-9d5d-002590f97d84 
+
+$> git annex init                                                                
+init  (merging origin/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+
+  Failed to get annex.uuid configuration of repository origin
+
+  Instead, got: "core.repositoryformatversion\n0\NULcore.filemode\ntrue\NULcore.bare\ntrue\NUL"
+
+  This is unexpected; please check the network transport!
+(Auto enabling special remote datalad-archives...)
+(Auto enabling special remote inm7-storage...)
+
+  Cannot run git-annex-remote-ria -- It is not installed in PATH (/usr/lib/git-annex.linux/bin:/usr/lib/git-core:/home/yoh/picts/mris/heudiconv-master/venvs/dev3/bin:/home/yoh/gocode/bin:/home/yoh/gocode/bin:/home/yoh/bin:/home/yoh/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/usr/local/sbin:/usr/lib/git-annex.linux/extra)
+ok
+(recording state in git...)
+
+"""]]
+
+so two issues in above:
+- not clear why it dumps git config if fetched instead of just announcing that remote has no git-annex and set to ignore
+- empty lines between all the messages go to stdout:
+
+[[!format sh """
+$> git annex init 2>/dev/null
+init  (scanning for unlocked files...)
+
+
+
+(Auto enabling special remote inm7-storage...)
+
+ok
+"""]]
+
+PS ignore "ignores --json-error-messages" part of the subject -- was detected in 7.20190819+git2-g908476a9b-1~ndall+1 during `get` but upgrade to 7.20191114+git43-ge29663773-1~ndall+1 resolved it
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] what I consider to be the core issue in this bug report. 
+> --[[Joey]]
+
diff --git a/doc/projects/datalad/bugs-done/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_1_a7ad806ceb76f13ff8fdcce62bc0ed8a._comment b/doc/projects/datalad/bugs-done/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_1_a7ad806ceb76f13ff8fdcce62bc0ed8a._comment
new file mode 100644
index 0000000000..666d6a54e8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_1_a7ad806ceb76f13ff8fdcce62bc0ed8a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-22T15:11:05Z"
+ content="""
+This error message is not specific to a particular file in the repository, so if
+git-annex get outputs it, it doesn't help for the error message to be
+wrapped up in json. The actual purpose of --json-error messages is being
+able to correlate a failure to eg, get a particular file with an error
+message related to that action. Not in avoiding all possible stderr.
+
+The actual bug here is that it dumps git config to stderr at all.
+
+----
+
+The extra newlines are output to stdout, so not a problem WRT stderr.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_2_495820d777c889f88466d725c11895f9._comment b/doc/projects/datalad/bugs-done/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_2_495820d777c889f88466d725c11895f9._comment
new file mode 100644
index 0000000000..b68dcc0b2c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_2_495820d777c889f88466d725c11895f9._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-01-22T17:04:09Z"
+ content="""
+Error message has been improved.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_.mdwn b/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_.mdwn
new file mode 100644
index 0000000000..7128c814a0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+Well, I remember whining before on this issue.  It does cause some notable inconvenience when trying to automate use of annex -- I am left without a choice but try to reget files multiple times without knowing what was actual cause for it to fail to start with.  Originally I observed it while content had to be wget'ed, to which I thought "oh well -- might be some connection overload etc".  But now I have tried on a repository which is local to that drive -- there must be no problem accessing multiple files at once whatsoever.  But on a trial X with -J5 I have error: 613, ok: 255, on next call  error: 415,  ok: 198 and so on -- kinda converging but imho it must not be so difficult.  I do suspect some race condition in annex itself preventing correct operation.
+
+### What steps will reproduce the problem?
+
+git annex get -J10   on some well sized annex.  Possibly with original annex to fetch content from just right on the same drive
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170408+gitg804f06baa-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> git annex get -J5 --json | grep -v '"success":true' 2>&1 | head
+{"command":"get","wanted":[{"here":false,"uuid":"3db23446-8c40-441e-97ec-55ffc86b4fc0","description":"yoh@smaug:~/proj/datalad/datalad/.git/travis-ci/origin-annex [origin]"}],"note":"Try making some of these repositories available:\n\t3db23446-8c40-441e-97ec-55ffc86b4fc0 -- yoh@smaug:~/proj/datalad/datalad/.git/travis-ci/origin-annex [origin]\n","skipped":[],"success":false,"key":"SHA256E-s328--c2eb8088cdc71a0d4cbd660312bef5421a47ce7da3655efdb17712e7188be4a1.txt.gz","file":"3728/3728.9-None.txt.gz"}
+{"command":"get","wanted":[{"here":false,"uuid":"3db23446-8c40-441e-97ec-55ffc86b4fc0","description":"yoh@smaug:~/proj/datalad/datalad/.git/travis-ci/origin-annex [origin]"}],"note":"Try making some of these repositories available:\n\t3db23446-8c40-441e-97ec-55ffc86b4fc0 -- yoh@smaug:~/proj/datalad/datalad/.git/travis-ci/origin-annex [origin]\n","skipped":[],"success":false,"key":"SHA256E-s62840--c20189a229fac622bb781650af394cf40367b5563a833885480f
+825fdbf29b47.txt.gz","file":"3729/3729.1-0.txt.gz"}
+
+...
+$> git annex get --key SHA256E-s328--c2eb8088cdc71a0d4cbd660312bef5421a47ce7da3655efdb17712e7188be4a1.txt.gz
+get SHA256E-s328--c2eb8088cdc71a0d4cbd660312bef5421a47ce7da3655efdb17712e7188be4a1.txt.gz (from origin...)
+SHA256E-s328--c2eb8088cdc71a0d4cbd660312bef5421a47ce7da3655efdb17712e7188be4a1.txt.gz
+            328 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+(checksum...) ok
+(recording state in git...)
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_1_1173126bd91dcb7fd13c57f06fd16c2b._comment b/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_1_1173126bd91dcb7fd13c57f06fd16c2b._comment
new file mode 100644
index 0000000000..469518202b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_1_1173126bd91dcb7fd13c57f06fd16c2b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-05-25T17:29:08Z"
+ content="""
+Let's not diagnose a concurrency problem prematurely.
+
+I've run many concurrent gets and never seen masses of failures, or indeed any
+failures without either an error message explaining why it failed, or something
+obviously wrong (like the drive not being mounted).
+
+The json output is making it harder than necessary to understand what's going on.
+It seems you should be easily able to replicate the same problem without --json.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_2_2ba8101ed0e91df7079744d1b37779fd._comment b/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_2_2ba8101ed0e91df7079744d1b37779fd._comment
new file mode 100644
index 0000000000..c9a6f133ac
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_2_2ba8101ed0e91df7079744d1b37779fd._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2017-05-25T18:39:03Z"
+ content="""
+didn't need to go far ;)
+
+[[!format sh \"\"\"
+$> git annex get -J5 
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+get 10/10.1-None.txt.gz get 1000/1000.2-0.txt.gz get 1000/1000.1-0.txt.gz get 1000/1000.3-0.txt.gz get 1000/1000.4-1.txt.gz error: could not lock config file .git/config: File exists
+(from origin...) (from origin...) (from origin...) 
+
+(transfer already in progress, or unable to take transfer lock) 
+  Unable to access these remotes: origin
+(from origin...) 
+
+  Try making some of these repositories available:
+  	3db23446-8c40-441e-97ec-55ffc86b4fc0 -- yoh@smaug:~/proj/datalad/datalad/.git/travis-ci/origin-annex [origin]
+failed
+SHA256E-s55194--48621840b3a869ac27dfdb2a201c202ee1382aa0114337563da2c38262a0c9e8.txt.gz
+         55,194 100%   21.39MB/s    0:00:00 (xfr#1, to-chk=0/1)
+SHA256E-s56291--48af9865017aca9c8931c3b91c4f0ff9954273d21007ff25de1a2c73ca0df95cSHA256E-s7813--7861750b475c620012f1a76635749d89b86b7777130352b6adb844753d3822c2.txt.gz
+.txt.gz
+         32,768  58%    0.00kB/s    0:00:00  (checksum...)    0:00:00 (xfr#1, to-chk=0/1)
+         56,291 100%   22.43MB/s    0:00:00 (xfr#1, to-chk=0/1)
+(checksum...) (checksum...) ok
+ok
+ok
+git-annex: git [Param \"config\",Param \"remote.origin.annex-uuid\",Param \"3db23446-8c40-441e-97ec-55ffc86b4fc0\"] failed
+CallStack (from HasCallStack):
+  error, called at ./Git/Command.hs:39:17 in main:Git.Command
+
+$> git annex get 2>&1 | head
+get 1000/1000.2-0.txt.gz (from origin...) 
+SHA256E-s56206--1fa38270b23b4c700c4a998712549c65782613d4567b8650b1ebaa3fcfc884f4.txt.gz
+         56,206 100%   22.35MB/s    0:00:00 (xfr#1, to-chk=0/1)
+(checksum...) ok
+get 1000/1000.3-0.txt.gz (from origin...) 
+SHA256E-s55880--dea4463f7e42c51463e236d29c4c40486b56754cbd8340c260e481bdd506115b.txt.gz
+         55,880 100%   22.04MB/s    0:00:00 (xfr#1, to-chk=0/1)
+(checksum...) ok
+get 1000/1000.5-1.txt.gz (from origin...) 
+SHA256E-s55028--f6f8d5f25bed2bb51d9ba17275a956a97276cdcc74c6538c7e590919426e97df.txt.gz
+
+\"\"\"]]
+
+FWIW, the repository in question is this one: http://datasets.datalad.org/devel/travis-buildlogs/.git/
+"""]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_3_6674e4dbc7437ce941bcef6272c3433b._comment b/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_3_6674e4dbc7437ce941bcef6272c3433b._comment
new file mode 100644
index 0000000000..a004b75b90
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_3_6674e4dbc7437ce941bcef6272c3433b._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-05-25T19:08:59Z"
+ content="""
+That looks like concurrent `git config` setting remote.origin.annex-uuid
+are failing.
+
+I have not reproduced the `.git/config` error, but with a local
+clone of a repository, I have been able to reproduce some intermittent
+"transfer already in progress, or unable to take transfer lock" failures
+with `git annex get -J5`, happening after remote.origin.annex-uuid has been
+cached.
+
+So, two distinct bugs I think..
+
+---
+
+Debugging, the lock it fails to take always seems to be the lock on
+the remote side, which points to the local clone being involved somehow.
+
+Debugging further, Utility.LockPool.STM.tryTakeLock is what's failing.
+That's supposed to only fail when another thread holds a conflicting lock,
+but as it's implemented with `orElse`, if the main STM
+transaction retries due to other STM activity on the same TVar,
+it will give up when it shouldn't.
+
+That's probably why this is happening under heavier concurrency loads;
+it makes that failure case much more likely. And with a local clone,
+twice as much locking is done.
+
+I've fixed this part of it! 
+
+---
+
+The concurrent `git config` part remains.
+Since git-annex can potentially have multiple threads doing different `git
+config` for their own reasons concurrently, it seems it will need to add
+its own locking around that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_4_480df575c68bfb37b8bb4fb43737726f._comment b/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_4_480df575c68bfb37b8bb4fb43737726f._comment
new file mode 100644
index 0000000000..3827077c2f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_4_480df575c68bfb37b8bb4fb43737726f._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-05-25T21:52:37Z"
+ content="""
+The .git/config concurrent access happens because the remote
+list is only generated on demand, and nothing demands it when running with
+-J until all the threads are spun up and each thread has its own state
+then, so each generates the remote list.
+
+There don't look to be any other git-config settings that
+would cause problems for concurrency other than ones run while
+generating the remote list.
+
+So, generating the remote list before starting concurrent threads
+would avoid that problem, and also leads to a slightly faster startup
+since the remote git config only has to be read once, etc.
+
+The only risk in doing that would be if generating a Remote
+opens some kind of handle, which can't be used concurrently, or
+is less efficient if only opened once and then used by multiple threads.
+
+I've audited all the Remote.*.gen methods, and they all
+seem ok. For example, Remote.External.gen sets up a worker pool
+of external special remote processes, and new ones are allocated as needed.
+And Remote.P2P.chainGen sets up a connection pool.
+
+Ok, gone ahead with this fix.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_5_03e474b00b1cb2a5b8244d9161857b9b._comment b/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_5_03e474b00b1cb2a5b8244d9161857b9b._comment
new file mode 100644
index 0000000000..abc1d700b8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_can_fail_some_downloads_and_require_re-getting_/comment_5_03e474b00b1cb2a5b8244d9161857b9b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="woohoo"
+ date="2017-05-26T02:03:57Z"
+ content="""
+Thank you Joey!  It seems to work very nice now!  Not a single one lost out of 1550!
+
+[[!format sh \"\"\"
+$> datalad get -J5 38*
+[INFO   ] Getting 100 items of dataset <Dataset path=/tmp/travis-buildlogs> ... 
+[INFO   ] Actually getting 1550 files 
+Tried to get 1550 files. Got 1550. 
+\"\"\"]]
+"""]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction.mdwn b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction.mdwn
new file mode 100644
index 0000000000..1aa191ed88
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction.mdwn
@@ -0,0 +1,73 @@
+Originally was trying to reproduce [datalad/issues/3653](https://github.com/datalad/datalad/issues/3653) assuming that multiple files pointed to the same key.
+It was not the case, and my attempt revealed another bug - annex inability to "obtain" files in parallel when multiple of them point to the same key:
+
+<details>
+<summary>setup of original repo(click to expand)</summary>
+
+[[!format sh """
+/tmp > mkdir src; (cd src; git init; git annex init; dd if=/dev/zero of=1 count=1024 bs=1024; for f in {2..10}; do cp 1 $f; done ; git annex add *; git commit -m added; )
+Initialized empty Git repository in /tmp/src/.git/
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
+1024+0 records in
+1024+0 records out
+1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00106651 s, 983 MB/s
+add 1 
+ok                                
+add 10 
+ok                                
+add 2 
+ok                                
+add 3 
+ok                                
+add 4 
+ok                                
+add 5 
+ok                                
+add 6 
+ok                                
+add 7 
+ok                                
+add 8 
+ok                                
+add 9 
+ok                                
+(recording state in git...)
+[master (root-commit) 63b1163] added
+ 10 files changed, 10 insertions(+)
+ create mode 120000 1
+ create mode 120000 10
+ create mode 120000 2
+ create mode 120000 3
+ create mode 120000 4
+ create mode 120000 5
+ create mode 120000 6
+ create mode 120000 7
+ create mode 120000 8
+ create mode 120000 9
+"""]]
+</details>
+
+And that is what happens then when we try to get the same key in parallel:
+[[!format sh """
+
+/tmp > git clone src dst; (cd dst; git annex get -J 5 *; )
+Cloning into 'dst'...
+done.
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+get 2 (from origin...) (checksum...) 
+git-annex: thread blocked indefinitely in an STM transaction
+failed
+git-annex: thread blocked indefinitely in an MVar operation
+
+"""]]
+
+I felt like it is an old issue but failed to find a trace of it upon a quick lookup
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_1_46420a92dbd8655af9b16349da24d0fc._comment b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_1_46420a92dbd8655af9b16349da24d0fc._comment
new file mode 100644
index 0000000000..77b039cc67
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_1_46420a92dbd8655af9b16349da24d0fc._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-11-13T16:34:34Z"
+ content="""
+Reproduced.
+
+After building git-annex with the DebugLocks flag, I got this:
+
+	debugLocks, called at ./Annex/Transfer.hs:248:18 in main:Annex.Transfer
+	debugLocks, called at ./CmdLine/Action.hs:263:26 in main:CmdLine.Action
+
+Which points to pickRemote and ensureOnlyActionOn. But pickRemote
+does no STM actions when there's only 1 remote, so it must really be
+the latter.
+
+Also, I notice that when 5 files to get are provided, it crashes, but with
+less than 5, it succeeds. 
+Even this trivial case crashes: `git annex get -J1 1 2`
+"""]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_2_b1f4dc12ad00a4aa73e5bdc7c0a8f489._comment b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_2_b1f4dc12ad00a4aa73e5bdc7c0a8f489._comment
new file mode 100644
index 0000000000..0721cf378a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_2_b1f4dc12ad00a4aa73e5bdc7c0a8f489._comment
@@ -0,0 +1,83 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-11-13T17:07:29Z"
+ content="""
+Ok, I see the bug. ensureOnlyActionOn does a STM 
+retry if it finds in the activekeys map some other thread
+is operating on the same key.
+But, there is no running STM transaction what will update
+the map. So, STM detects that the retry would deadlock.
+
+It's not really a deadlock, because once the other thread finishes,
+it will update the map to remove itself. But STM can't know that.
+The solution will be to not use STM for waiting on the other thread.
+
+Hmm, I tried the obvious approach, using a MVar semaphore to wait for the
+thread, but that just resulted in more STM and MVar deadlocks. 
+
+I don't understand why after puzzling over it for two hours. I did
+instrument all calls to atomically, and it looks, unfortunately, like
+the one in finishCommandActions is deadlocking. If the problem extends
+beyond ensureOnlyActionOn it may be much more complicated.
+
+Patch that does not work and I don't know why.
+
+	diff --git a/CmdLine/Action.hs b/CmdLine/Action.hs
+	index 87298a95f..bf4bdd589 100644
+	--- a/CmdLine/Action.hs
+	+++ b/CmdLine/Action.hs
+	@@ -268,16 +268,30 @@ ensureOnlyActionOn k a = debugLocks $
+	 	go ConcurrentPerCpu = goconcurrent
+	 	goconcurrent = do
+	 		tv <- Annex.getState Annex.activekeys
+	-		bracket (setup tv) id (const a)
+	-	setup tv = liftIO $ do
+	+		bracketIO (setup tv) id (const a)
+	+	setup tv = do
+	+		mysem <- newEmptyMVar
+	 		mytid <- myThreadId
+	-		atomically $ do
+	+		finishsetup <- atomically $ do
+	 			m <- readTVar tv
+	 			case M.lookup k m of
+	-				Just tid
+	-					| tid /= mytid -> retry
+	-					| otherwise -> return $ return ()
+	+				Just (tid, theirsem)
+	+					| tid /= mytid -> return $ do
+	+						-- wait for the other
+	+						-- thread to finish, and
+	+						-- retry (STM retry would
+	+						-- deadlock)
+	+						readMVar theirsem
+	+						setup tv
+	+					| otherwise -> return $
+	+						-- same thread, so no
+	+						-- blocking
+	+						return $ return ()
+	 				Nothing -> do
+	-					writeTVar tv $! M.insert k mytid m
+	-					return $ liftIO $ atomically $
+	-						modifyTVar tv $ M.delete k
+	+					writeTVar tv $! M.insert k (mytid, mysem) m
+	+					return $ return $ do
+	+						atomically $ modifyTVar tv $
+	+							M.delete k
+	+						-- indicate finished
+	+						putMVar mysem ()
+	+		finishsetup
+	diff --git a/Annex.hs b/Annex.hs
+	index 9eb4c5f39..936399ae7 100644
+	--- a/Annex.hs
+	+++ b/Annex.hs
+	@@ -143,7 +143,7 @@ data AnnexState = AnnexState
+	 	, existinghooks :: M.Map Git.Hook.Hook Bool
+	 	, desktopnotify :: DesktopNotify
+	 	, workers :: Maybe (TMVar (WorkerPool AnnexState))
+	-	, activekeys :: TVar (M.Map Key ThreadId)
+	+	, activekeys :: TVar (M.Map Key (ThreadId, MVar ()))
+	 	, activeremotes :: MVar (M.Map (Types.Remote.RemoteA Annex) Integer)
+	 	, keysdbhandle :: Maybe Keys.DbHandle
+	 	, cachedcurrentbranch :: (Maybe (Maybe Git.Branch, Maybe Adjustment))
+"""]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_3_d8ba7cc5a860e9ccaab32c637cc2a7cd._comment b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_3_d8ba7cc5a860e9ccaab32c637cc2a7cd._comment
new file mode 100644
index 0000000000..2880a4632a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_3_d8ba7cc5a860e9ccaab32c637cc2a7cd._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-11-13T19:07:49Z"
+ content="""
+Tried going back to c04b2af3e1a8316e7cf640046ad0aa68826650ed,
+which is before the separation of perform and cleanup stages.
+The same code was in onlyActionOn back then. And the test case does not
+crash.
+
+So, that gives a good commit to start a bisection. Which will probably
+find the bug was introduced in the separation of perform and cleanup stages,
+because that added a lot of STM complexity.
+
+(Have to cherry-pick 018b5b81736a321f3eb9762a2afb7124e19dbdf9
+onto those old commits to make them build with current libraries.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_4_eecaa7f7b0279c56902c90ed58d1444f._comment b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_4_eecaa7f7b0279c56902c90ed58d1444f._comment
new file mode 100644
index 0000000000..4c1ad5521e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_4_eecaa7f7b0279c56902c90ed58d1444f._comment
@@ -0,0 +1,83 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-11-13T21:22:07Z"
+ content="""
+Simplified version of patch above, that converts ensureOnlyActionOn to not use
+STM at all, and is significantly simpler.
+
+With this patch, the test case still STM deadlocks. So this seems to be
+proof that the actual problem is not in ensureOnlyActionOn.
+
+	diff --git a/Annex.hs b/Annex.hs
+	index 9eb4c5f39..9baf7755a 100644
+	--- a/Annex.hs
+	+++ b/Annex.hs
+	@@ -143,7 +143,7 @@ data AnnexState = AnnexState
+	 	, existinghooks :: M.Map Git.Hook.Hook Bool
+	 	, desktopnotify :: DesktopNotify
+	 	, workers :: Maybe (TMVar (WorkerPool AnnexState))
+	-	, activekeys :: TVar (M.Map Key ThreadId)
+	+	, activekeys :: MVar (M.Map Key (ThreadId, MVar ()))
+	 	, activeremotes :: MVar (M.Map (Types.Remote.RemoteA Annex) Integer)
+	 	, keysdbhandle :: Maybe Keys.DbHandle
+	 	, cachedcurrentbranch :: (Maybe (Maybe Git.Branch, Maybe Adjustment))
+	@@ -154,7 +154,7 @@ data AnnexState = AnnexState
+	 newState :: GitConfig -> Git.Repo -> IO AnnexState
+	 newState c r = do
+	 	emptyactiveremotes <- newMVar M.empty
+	-	emptyactivekeys <- newTVarIO M.empty
+	+	emptyactivekeys <- newMVar M.empty
+	 	o <- newMessageState
+	 	sc <- newTMVarIO False
+	 	return $ AnnexState
+	diff --git a/CmdLine/Action.hs b/CmdLine/Action.hs
+	index 87298a95f..a8c2bd205 100644
+	--- a/CmdLine/Action.hs
+	+++ b/CmdLine/Action.hs
+	@@ -22,7 +22,7 @@ import Remote.List
+	 import Control.Concurrent
+	 import Control.Concurrent.Async
+	 import Control.Concurrent.STM
+	-import GHC.Conc
+	+import GHC.Conc (getNumProcessors)
+	 import qualified Data.Map.Strict as M
+	 import qualified System.Console.Regions as Regions
+	 
+	@@ -267,17 +267,22 @@ ensureOnlyActionOn k a = debugLocks $
+	 	go (Concurrent _) = goconcurrent
+	 	go ConcurrentPerCpu = goconcurrent
+	 	goconcurrent = do
+	-		tv <- Annex.getState Annex.activekeys
+	-		bracket (setup tv) id (const a)
+	-	setup tv = liftIO $ do
+	+		mv <- Annex.getState Annex.activekeys
+	+		bracketIO (setup mv) id (const a)
+	+	setup mv =  do
+	 		mytid <- myThreadId
+	-		atomically $ do
+	-			m <- readTVar tv
+	-			case M.lookup k m of
+	-				Just tid
+	-					| tid /= mytid -> retry
+	-					| otherwise -> return $ return ()
+	-				Nothing -> do
+	-					writeTVar tv $! M.insert k mytid m
+	-					return $ liftIO $ atomically $
+	-						modifyTVar tv $ M.delete k
+	+		m <- takeMVar mv
+	+		let ready sem = do
+	+			putMVar mv $! M.insert k (mytid, sem) m
+	+			return $ do
+	+				modifyMVar_ mv $ pure . M.delete k
+	+				putMVar sem ()
+	+		case M.lookup k m of
+	+			Nothing -> ready =<< newEmptyMVar
+	+			Just (tid, sem)
+	+				| tid /= mytid -> do
+	+					takeMVar sem
+	+					ready sem
+	+				| otherwise -> do
+	+					putMVar mv m
+	+					return noop
+"""]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_5_052acf169f9c2b8b0233adddabb02559._comment b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_5_052acf169f9c2b8b0233adddabb02559._comment
new file mode 100644
index 0000000000..4d3cc32da8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_5_052acf169f9c2b8b0233adddabb02559._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-11-13T21:42:58Z"
+ content="""
+finishCommandActions is reaching the retry case, and STM deadlocks there.
+The WorkerPool is getting into a state where allIdle is False, and is not
+leaving it, perhaps due to an earlier STM deadlock. (There seem to be two
+different ones.)
+
+Also, I notice with --json-error-messages:
+
+	{"command":"get","note":"from origin...\nchecksum...","success":false,"key":"SHA256E-s524288--07854d2fef297a06ba81685e660c332de36d5d18d546927d30daad6d7fda1541","error-messages":["git-annex: thread blocked indefinitely in an STM transaction"],"file":"1"}
+
+So the thread that actually gets to run on the key is somehow reaching a
+STM deadlock.
+
+Which made me wonder if that thread deadlocks on enteringStage.
+And it seems so. If Command.Get is changed to use commandStages
+rather than transferStages, the test case succeeds.
+
+Like finishCommandActions, enteringStage has a STM retry if it needs to
+wait for something to happen to the WorkerPool. So again it looks like
+the WorkerPool is getting screwed up.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_6_880c962d5ca77c494c984e7f74725265._comment b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_6_880c962d5ca77c494c984e7f74725265._comment
new file mode 100644
index 0000000000..f8d18b1cf6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_6_880c962d5ca77c494c984e7f74725265._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="catch-all deadlock breaker"
+ date="2019-11-13T22:33:59Z"
+ content="""
+Not sure if feasible, but maybe a [[catch-all deadlock breaker|todo/more_extensive_retries_to_mask_transient_failures]] could be implemented to mask this and other deadlocks?
+
+The moon landings software [[had something|https://www.ibiblio.org/apollo/hrst/archive/1033.pdf]] [[like this|https://history.nasa.gov/computers/Ch2-6.html]], and it worked [[pretty well|https://www.wsj.com/articles/apollo-11-had-a-hidden-hero-software-11563153001]]...
+"""]]
diff --git a/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_6_e33df0ec76069deb069b94c944d62c76._comment b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_6_e33df0ec76069deb069b94c944d62c76._comment
new file mode 100644
index 0000000000..7f348fc9f5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/parallel_get_to_the_files_for_the_same_key_would_fail_with__thread_blocked_indefinitely_in_an_STM_transaction/comment_6_e33df0ec76069deb069b94c944d62c76._comment
@@ -0,0 +1,69 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2019-11-14T15:20:13Z"
+ content="""
+Added tracing of changes to the WorkerPool.
+
+	joey@darkstar:/tmp/dst>git annex get -J1 1 2 --json
+	("initial pool",WorkerPool UsedStages {initialStage = TransferStage, stageSet = fromList [TransferStage,VerifyStage]} [IdleWorker TransferStage,IdleWorker VerifyStage] 2)
+	("starting worker",WorkerPool UsedStages {initialStage = TransferStage, stageSet = fromList [TransferStage,VerifyStage]} [ActiveWorker TransferStage,IdleWorker VerifyStage] 1)
+
+Transfer starts for file 1
+
+	(("change stage from",TransferStage,"to",VerifyStage),WorkerPool UsedStages {initialStage = TransferStage, stageSet = fromList [TransferStage,VerifyStage]} [IdleWorker TransferStage,ActiveWorker VerifyStage] 1)
+
+Transfer complete, verifying starts.
+
+	("starting worker",WorkerPool UsedStages {initialStage = TransferStage, stageSet = fromList [TransferStage,VerifyStage]} [ActiveWorker TransferStage,ActiveWorker VerifyStage] 0)
+
+This second thread is being started to process file 2.
+It starts in TransferStage, but it will be blocked from doing anything
+by ensureOnlyActionOn.
+
+	("finishCommandActions starts with",WorkerPool UsedStages {initialStage = TransferStage, stageSet = fromList [TransferStage,VerifyStage]} [ActiveWorker TransferStage,ActiveWorker VerifyStage] 0)
+	("finishCommandActions observes",WorkerPool UsedStages {initialStage = TransferStage, stageSet = fromList [TransferStage,VerifyStage]} [ActiveWorker TransferStage,ActiveWorker VerifyStage] 0)
+
+All files have threads to process them started, so finishCommandActions starts up.
+It will retry since the threads are still running.
+
+	(("change stage from",VerifyStage,"to",TransferStage),WorkerPool UsedStages {initialStage = TransferStage, stageSet = fromList [TransferStage,VerifyStage]} [IdleWorker VerifyStage,ActiveWorker TransferStage] 0)
+
+The first thread is done with verification, and 
+the stage is being restored to transfer.
+
+The 0 means that there are 0 spareVals. Normally, the number of spareVals
+should be the same as the number of IdleWorkers, so it should be 1.
+It's 0 because the thread is in the process of changing between stages.
+
+The thread should at this point be waiting for an idle TransferStage
+slot to become available. The second thread still has that active.
+It seems that wait never completes, because a trace I had after that wait
+never got printed.
+
+	("finishCommandActions observes",WorkerPool UsedStages {initialStage = TransferStage, stageSet = fromList [TransferStage,VerifyStage]} [IdleWorker VerifyStage,ActiveWorker TransferStage] 0)
+
+It retries again, because of the active worker and also because spareVals
+is not the same as IdleWorkers.
+
+	git-annex: thread blocked indefinitely in an STM transaction
+
+Deadlock.
+
+Looks like that second thread that got into transfer stage
+never leaves it, and then the first thread, which wants to
+restore back to transfer stage, is left waiting forever for it. And so is
+finishCommandActions.
+
+Aha! The second thread is in fact still in ensureOnlyActionOn.
+So it's waiting on the first thread to finish. But the first thread can't
+transition back to TransferStage because the second thread has stolen it.
+
+Now it makes sense.
+
+So.. One way to fix this would be to add a new stage, which is used for
+threads that are just starting. Then the second thread would be in
+StartStage, and the first thread would not be prevented from transitioning
+back to TransferStage. Would need to make sure that, once a thread leaves
+StartStage, it does not ever transition back to it.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/prematurely___40__can__39__t_check_offline__41___marks_remote_as_annex-ignore.mdwn b/doc/projects/datalad/bugs-done/prematurely___40__can__39__t_check_offline__41___marks_remote_as_annex-ignore.mdwn
new file mode 100644
index 0000000000..b05a6a30e2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prematurely___40__can__39__t_check_offline__41___marks_remote_as_annex-ignore.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+
+I have cloned via http and then went offline... decided to get a file, annex immediately tried to fetch it from origin which it couldn't have access to atm and marked it as annex-ignore.  IMHO it is a bit premature action, and annex should mark a remote as ignore only if it managed to reach the remote location and discovered that it has no annex there, not on a mere connectivity fluke
+
+
+### What version of git-annex are you using? On what operating system?
+
+6.20160425+gitgffe2ea2-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> git annex get cond001.txt
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+get cond001.txt 
+  Remote origin not usable by git-annex; setting annex-ignore
+(not available) 
+  Try making some of these repositories available:
+  	899f0347-0888-48ef-91b6-bac213ca8cef -- datalad-archives
+   	c8bd3d05-33d4-4b59-9d53-ca7efbdcdd13 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/openfmri/ds000001
+failed
+(recording state in git...)
+git-annex: get: 1 failed
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls.mdwn b/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls.mdwn
new file mode 100644
index 0000000000..abb8d922fe
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls.mdwn
@@ -0,0 +1,87 @@
+### Please describe the problem.
+
+
+### What steps will reproduce the problem?
+
+```
+git clone http://datasets.datalad.org/labs/hasson/narratives/derivatives/fmriprep/.git
+cd fmriprep
+AWS_ACCESS_KEY_ID=X AWS_SECRET_ACCESS_KEY=Y git annex get  sub-001/anat/sub-001_space-MNI152NLin2009cAsym_desc-brain_mask.nii.gz
+```
+
+results in
+
+```
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+get sub-001/anat/sub-001_space-MNI152NLin2009cAsym_desc-brain_mask.nii.gz (from fcp-indi...) 
+
+
+  HttpExceptionRequest Request {
+    host                 = "fcp-indi.s3.amazonaws.com"
+    port                 = 80
+    secure               = False
+    requestHeaders       = [("Date","Tue, 16 Mar 2021 17:32:39 GMT"),("Authorization","<REDACTED>")]
+    path                 = "/data/Projects/narratives/derivatives/fmriprep/sub-001/anat/sub-001_space-MNI152NLin2009cAsym_desc-brain_mask.nii.gz"
+    queryString          = ""
+    method               = "GET"
+    proxy                = Nothing
+    rawBody              = False
+    redirectCount        = 10
+    responseTimeout      = ResponseTimeoutDefault
+    requestVersion       = HTTP/1.1
+  }
+   (StatusCodeException (Response {responseStatus = Status {statusCode = 403, statusMessage = "Forbidden"}, responseVersion = HTTP/1.1, responseHeaders = [("x-amz-request-id","2RHPCARD2XCMWS10"),("x-amz-id-2","pUFqyuk39EhsOj3wkeN+9PB7SfNxRCkR2iYbROSf4PwiJ9EezRzpEfoA4FcHRpthqmaBF2pAhDQ="),("Content-Type","application/xml"),("Transfer-Encoding","chunked"),("Date","Tue, 16 Mar 2021 17:32:38 GMT"),("Server","AmazonS3")], responseBody = (), responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose}) "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Error><Code>InvalidAccessKeyId</Code><Message>The AWS Access Key Id you provided does not exist in our records.</Message><AWSAccessKeyId>X</AWSAccessKeyId><RequestId>2RHPCARD2XCMWS10</RequestId><HostId>pUFqyuk39EhsOj3wkeN+9PB7SfNxRCkR2iYbROSf4PwiJ9EezRzpEfoA4FcHRpthqmaBF2pAhDQ=</HostId></Error>")
+
+  Unable to access these remotes: fcp-indi
+
+  Maybe add some of these git remotes (git remote add ...):
+  	4d79a724-9e8c-4cce-b030-f712eed3e131 -- snastase@scotty.pni.Princeton.EDU:/mnt/bucket/labs/hasson/snastase/smaug/narratives/derivatives/fmriprep
+   	5f96664f-23ba-4c25-8e75-9ca24fcd46f5 -- nastase@smaug:/mnt/datasets/incoming/nastase/narratives/derivatives/fmriprep
+failed
+git-annex: get: 1 failed
+```
+
+although direct S3 access was not even required (and would not trigger if no AWS_ variables are specified) due to
+
+```shell
+$> git show git-annex:remote.log                                                                                                  
+bf6f56f3-f6b7-4df8-9898-a4226dc71400 autoenable=true bucket=fcp-indi datacenter=US encryption=none exporttree=yes fileprefix=data/Projects/narratives/derivatives/fmriprep/ host=s3.amazonaws.com name=fcp-indi partsize=1GiB port=80 public=yes publicurl=https://s3.amazonaws.com/fcp-indi storageclass=STANDARD type=S3 versioning=yes timestamp=1607616182.971041s
+```
+
+Doing above attempt sets some flag somewhere (are those credentials get recorded somewhere locally? didn't investigate) making subsequent `git annex get` without AWS vars fail too...  In a fresh clone it works though just fine
+
+```shell
+
+$> git annex get sub-001/anat/sub-001_space-MNI152NLin2009cAsym_desc-brain_mask.nii.gz   
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+get sub-001/anat/sub-001_space-MNI152NLin2009cAsym_desc-brain_mask.nii.gz (from fcp-indi...) 
+
+(checksum...) ok                  
+(recording state in git...)
+```
+
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 8.20210310+git49-g4d6f74477-1~ndall+1
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_1_9222f76d21e8260327b4f127cc90782d._comment b/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_1_9222f76d21e8260327b4f127cc90782d._comment
new file mode 100644
index 0000000000..2e632930a1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_1_9222f76d21e8260327b4f127cc90782d._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-16T18:57:55Z"
+ content="""
+git-annex initremote caches the AWS creds locally in a file
+(.git/annex/creds/uuid) and that caching must be what's happening.
+I suppose with an autoinit of this particular repo.
+
+It may be that autoinit should avoid sucking in such information, since the
+user may not expect it. And also what if two S3 repos were auto-initted,
+probably the creds would only work for one. There is support in the API
+that remotes could use to avoid such behavior during auto-init, but not
+in the external special remote protocol.
+
+The S3 remote currently always uses S3 protocol when there are creds,
+even for read operations; when there are no creds it goes on to check if
+it can determinte a public url, and uses that instead. If it instead 
+preferred public urls, your use case would work even with the creds. 
+Could break other use cases though, eg if there was a public url
+recorded but it didn't work and the API did, also versioned repos maybe.
+
+So not sure I like that second approach, it seems better to use the creds, 
+so long as the user knowingly provided them.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_2_9e694fdee4a40581a86d21b962f99f25._comment b/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_2_9e694fdee4a40581a86d21b962f99f25._comment
new file mode 100644
index 0000000000..2a46ccc07e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_2_9e694fdee4a40581a86d21b962f99f25._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-03-17T13:37:01Z"
+ content="""
+Ok, I've made autoenable not take creds from the environment, which will
+avoid the problem.
+
+If there are any external special remotes that might behave similarly,
+it would need an extension to the external special remote protocol to
+support them. Currently `INITREMOTE` is sent during auto-enable, and so
+the protocol would need to have `ENABLEREMOTE` and `AUTOENBLEREMOTE` added
+to it. Since that would need an extension and I don't know if any externals
+actually look at env vars etc at (auto)enable time, I've skipped doing it
+for now.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_3_79626c62d4ce8be2524f9ef3a1351363._comment b/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_3_79626c62d4ce8be2524f9ef3a1351363._comment
new file mode 100644
index 0000000000..55154b17a6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_3_79626c62d4ce8be2524f9ef3a1351363._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2021-03-17T14:56:19Z"
+ content="""
+> Ok, I've made autoenable not take creds from the environment, which will avoid the problem.
+
+indeed it would avoid the problem for public ones, but wouldn't it introduce problem/regression for handling private ones?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_4_40d710dd89b305a64ff8df5d238778e8._comment b/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_4_40d710dd89b305a64ff8df5d238778e8._comment
new file mode 100644
index 0000000000..5f3ccefa9a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/presence_of_AWS_creds_ruins_access_to_public_urls/comment_4_40d710dd89b305a64ff8df5d238778e8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-03-17T15:28:05Z"
+ content="""
+Yes, it's a behavior change. But the old behavior meant users had to set
+env vars when doing something that has nothing to do with enabling remotes,
+which is not a reasonable thing to expect users to do.
+
+If you relied on autoenabling of remotes that need creds to enable, you
+will need to change to explicitly enabling them.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files.mdwn b/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files.mdwn
new file mode 100644
index 0000000000..ea3e135cef
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files.mdwn
@@ -0,0 +1,76 @@
+If an unlocked (as known to annex) file is dropped locally, it is still present on the file system as a regular file. So git-annex unaware tool could happily append to it without realizing that it is changing a file which contains no data, but rather a git link of git-annex.  Then `git commit` would silently (!!!) commit such a change.
+
+<details>
+<summary>here is a reproducer</summary> 
+
+```shell
+#!/bin/bash
+
+cd "$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)"
+set -eu
+
+git init
+git annex init
+
+set -x
+git annex addurl --file 123 http://onerussian.com/tmp/123
+git annex unlock 123 
+git commit -m 'commit 123 unlocked' 123
+
+git annex drop 123
+cat 123
+
+# git annex knows that the content is gone!
+git annex list
+
+echo "more crap" >> 123
+git commit -m 'Added crap' 123
+
+# how probable it is that the user DOES want gitlink on top of that file?
+cat 123
+git show
+
+```
+</details>
+
+which with git-annex `10.20220127+git47-g9f9b1488e-1~ndall+1` produces
+
+```
+...
++ git annex list
+here
+|web
+||bittorrent
+|||
+_X_ 123
++ echo 'more crap'
++ git commit -m 'Added crap' 123
+[master fdcea88] Added crap
+ 1 file changed, 1 insertion(+)
++ cat 123
+/annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+more crap
++ git show
+commit fdcea88dcfcaf823eebfe78734f30b81531240a8 (HEAD -> master)
+Author: Yaroslav Halchenko <debian@onerussian.com>
+Date:   Fri Feb 18 14:43:32 2022 -0500
+
+    Added crap
+
+diff --git a/123 b/123
+index 1c0106d..ef5ca34 100644
+--- a/123
++++ b/123
+@@ -1 +1,2 @@
+ /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
++more crap
+```
+
+although could be considered a user error, I feel that also git annex could add a guard that while smudging if file was not locally present, beginning of the content is the previous git link, something went awry and at least issuing some warning (if possible) could be due and help prevent some data loss where expected to grow file would be trimmed and previous content possibly dropped.
+
+may be situation is even more "dire" because git-annex still considers this file "annexed" (according to `git annex list`) although not present locally.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] (at least as far as it can be fixed) --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_1_9b101babc7cb9e697a6195366d4a0a67._comment b/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_1_9b101babc7cb9e697a6195366d4a0a67._comment
new file mode 100644
index 0000000000..213a809412
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_1_9b101babc7cb9e697a6195366d4a0a67._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-21T19:01:29Z"
+ content="""
+Actually, the format of pointer files allows
+additional content to be present after the key and a newline.
+
+That is to allow for future expansion. Note that git-lfs does the same and
+IIRC puts something additional in there, perhaps including a comment like
+"This file's content is not present; this is only a pointer."
+
+So, appending to the link file keeps it a working link,
+ just a link with more crap at the end:
+
+	joey@darkstar:/tmp/aaaa>echo "more crap" >> g
+	joey@darkstar:/tmp/aaaa>cat g
+	/annex/objects/SHA256E-s14135--d1e433edea357dde79276fcfd63bacb93f2c2b4bf869ab976ee83a66e5506e16
+	more crap
+	joey@darkstar:/tmp/aaaa>git-annex whereis g
+	whereis g (1 copy)
+	  	00000000-0000-0000-0000-000000000001 -- web
+	
+	  web: http://google.com/
+	ok
+
+So how is this data loss? The annexed content is still available;
+git-annex get will still work. The content you appended to 
+the link file didn't go where you intended it to, but it is checked
+into git too.
+
+If git-annex warned about this when smudging a file, it would still 
+get added to git; it can't prevent that. And the warning would mess
+with any intentional use of this.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_2_9bfcb8386d5589623423f4d3f040df3c._comment b/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_2_9bfcb8386d5589623423f4d3f040df3c._comment
new file mode 100644
index 0000000000..40e97693ef
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_2_9bfcb8386d5589623423f4d3f040df3c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-02-21T21:46:14Z"
+ content="""
+> So how is this data loss? The annexed content is still available; git-annex get will still work. The content you appended to the link file didn't go where you intended it to, but it is checked into git too.
+
+;-) hm, well, indeed - data will not be lost per se. But data will \"spread out\" (some under git-annex, some as some ignored content in the git link file), and indeed the history of modifications would still be there in git history thus keeping it possible to reconstruct the ultimate intended file content (would be especially fun exercise for a user if there were modifications to both git-annex'ed version of the file and `git` committed git linked text portion of the file). I could come up with some obscure scenario (force dropped annexed content of some prior state of annexed file because I have a newer one) where recovering ultimate original order of such \"spread outs\" would make it impossible though.
+
+> And the warning would mess with any intentional use of this.
+
+Is there really any intentional use of this? if not, then IMHO UX would be better if such use would be prevented (error out) rather than allowed since could lead to the confusion and requiring quite an archaeological expedition to recover data in originally intended \"all annexed in one file\". If there is an intended use, then I guess indeed there is no way for users to shoot themselves in the foot?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_3_704ecfd2888a8153eaa5e4a8e6e3d011._comment b/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_3_704ecfd2888a8153eaa5e4a8e6e3d011._comment
new file mode 100644
index 0000000000..8cc0df84e0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_3_704ecfd2888a8153eaa5e4a8e6e3d011._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-02-22T15:48:20Z"
+ content="""
+If it errored, git would ignore the failure and still add the file
+content to git.
+
+One thing that could be done is to come up with some kind of format for the
+lines after the annex link in the pointer file, to be used in whatever
+future expansion might happen. Then it could warn if there is data there
+not matching that format. And then add the file to the annex, to at least
+keep that data out of the git repository.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_4_3291fcd5100fda8d41fb8714cec15b30._comment b/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_4_3291fcd5100fda8d41fb8714cec15b30._comment
new file mode 100644
index 0000000000..dbed89efe5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_4_3291fcd5100fda8d41fb8714cec15b30._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-02-23T16:45:24Z"
+ content="""
+I've now specified a format in [[internals/pointer_file]], which is
+designed to allow detecting accidental appends. 
+
+And git-annex will now treat a pointer file that has been appeneded to as
+not a pointer file any longer.
+
+So, for example:
+
+	joey@darkstar:/tmp/r>echo oops >> foo
+	joey@darkstar:/tmp/r>cat foo
+	/annex/objects/SHA256E-s14169--bdcf6188db530bc3af79c898208ce2a56df6197f59b3872b03613a248ac8faf4
+	oops
+	joey@darkstar:/tmp/r>git add foo
+	joey@darkstar:/tmp/r>git diff --cached foo | tail -n 2
+	-/annex/objects/SHA256E-s14169--bdcf6188db530bc3af79c898208ce2a56df6197f59b3872b03613a248ac8faf4
+	+/annex/objects/SHA256E-s101--b7da3d6b0ad2f6a2a263e783e59efb60f2520f03bb36cea35a556a684b0d5c9d
+
+Since the file is not a valid pointer file after being appended to, 
+git add does what it would do with any file, in this case adding the
+content to the annex.
+
+So at least it keeps the possibly large appeneded content out of git now.
+I think that's the most important thing. Detecting and warning about
+pointer files that are not valid due to appends should be easy from here.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_5_adb69305a31cf55ff62497b6de8e2f6a._comment b/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_5_adb69305a31cf55ff62497b6de8e2f6a._comment
new file mode 100644
index 0000000000..362dd8a378
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prevent_silent_data_loss_on_unlocked_files/comment_5_adb69305a31cf55ff62497b6de8e2f6a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-02-23T19:13:25Z"
+ content="""
+	joey@darkstar:/tmp/r>git add xx
+	git-annex: The file "xx" looks like git-annex pointer file that has had other content appended to it
+
+I think this is as far as git-annex can do toward preventing foot shooting here.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/prop__95__isomorphic__95__key__95__encode_fails_with_external_backend_changes.mdwn b/doc/projects/datalad/bugs-done/prop__95__isomorphic__95__key__95__encode_fails_with_external_backend_changes.mdwn
new file mode 100644
index 0000000000..d3b596667f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prop__95__isomorphic__95__key__95__encode_fails_with_external_backend_changes.mdwn
@@ -0,0 +1,37 @@
+Just a heads up that `prop_isomorphic_key_encode` is failing on master
+(for me locally and at <https://github.com/datalad/datalad-extensions>):
+
+```
+$ git show --no-patch --format=reference
+85e57d826 (Added a comment: streaming data and external backends, 2020-07-30)
+
+$ stack exec -- git annex test -p prop_isomorphic_key_encode
+Tests                     
+  QuickCheck
+    prop_isomorphic_key_encode: FAIL (0.03s)
+      *** Failed! (after 601 tests):
+      Exception:
+        Data.ByteString.last: empty ByteString
+        CallStack (from HasCallStack):
+          error, called at libraries/bytestring/Data/ByteString.hs:1877:23 in bytestring-0.10.8.2:Data.ByteString
+      Exception thrown while showing test case:
+        Data.ByteString.last: empty ByteString
+        CallStack (from HasCallStack):
+          error, called at libraries/bytestring/Data/ByteString.hs:1877:23 in bytestring-0.10.8.2:Data.ByteString
+      
+      Use --quickcheck-replay=896100 to reproduce.
+
+1 out of 1 tests failed (0.03s)
+  (Failures above could be due to a bug in git-annex, or an incompatibility
+   with utilities, such as git, installed on this system.)
+```
+
+I do not see this failure before f75be3216 (external backends wip,
+2020-07-29).
+
+Thanks in advance.
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] and rest of test suite passing --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/prop__95__isomorphic__95__key__95__encode_fails_with_external_backend_changes/comment_1_7f23940cfa4451e4cd7137e2d7a46d86._comment b/doc/projects/datalad/bugs-done/prop__95__isomorphic__95__key__95__encode_fails_with_external_backend_changes/comment_1_7f23940cfa4451e4cd7137e2d7a46d86._comment
new file mode 100644
index 0000000000..9e646fccb3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prop__95__isomorphic__95__key__95__encode_fails_with_external_backend_changes/comment_1_7f23940cfa4451e4cd7137e2d7a46d86._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 1"
+ date="2020-07-31T21:20:08Z"
+ content="""
+> -		in if S.last b' == fromIntegral (ord 'E')
+> +		in if not (S.null b') && S.last b' == fromIntegral (ord 'E')
+
+I had a feeling this could be a one-liner, but I wasn't able to come
+up with a patch.  Shoot!
+
+Thanks for the fix.
+
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__.mdwn b/doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__.mdwn
new file mode 100644
index 0000000000..0282ec96da
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+
+Fresh build of 8.20201129+git100-g2d84bf992-1~ndall+1 when having HOME (base system is Ubuntu) on a crippled FS leads to
+
+```
+2021-01-13T03:46:45.0619292Z     prop_relPathDirToFileAbs_basics:                      FAIL (0.01s)
+2021-01-13T03:46:45.0620328Z       *** Failed! Falsifiable (after 702 tests):
+2021-01-13T03:46:45.0621015Z       TestableFilePath {fromTestableFilePath = "A"}
+2021-01-13T03:46:45.0621819Z       TestableFilePath {fromTestableFilePath = "A/"}
+2021-01-13T03:46:45.0623170Z       Use --quickcheck-replay=895840 to reproduce.
+```
+
+[https://github.com/datalad/git-annex/runs/1692622842?check_suite_focus=true](https://github.com/datalad/git-annex/runs/1692622842?check_suite_focus=true)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__/comment_1_23bf4756af808d1b2cf89f7da119031f._comment b/doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__/comment_1_23bf4756af808d1b2cf89f7da119031f._comment
new file mode 100644
index 0000000000..b388e7415f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__/comment_1_23bf4756af808d1b2cf89f7da119031f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-01-13T17:01:07Z"
+ content="""
+This is a pure test, and the filesystem does not affect it in any way.
+
+The test is slightly broken, in that when two paths
+are the same except slightly differently normalized (eg, "A" vs "A/"),
+it fails. Really not a great test overall, rewriting.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__/comment_2_63d3ff9c10ef530d318653bfadccab22._comment b/doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__/comment_2_63d3ff9c10ef530d318653bfadccab22._comment
new file mode 100644
index 0000000000..0f3132b578
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__/comment_2_63d3ff9c10ef530d318653bfadccab22._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2021-01-22T16:42:32Z"
+ content="""
+announced fixed in [8.20201129-109-g99ba47120](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=99ba4712098f2f4339bd22927a79d1b3e6ab8eaa) but I still see failures on Windows as of 8.20201129+git169-gaa07e68ed_x64
+
+```
+2021-01-22T04:32:19.9129496Z     prop_relPathDirToFileAbs_basics:                      FAIL
+2021-01-22T04:32:19.9130236Z       *** Failed! Falsified (after 44 tests):
+2021-01-22T04:32:19.9130819Z       TestableFilePath {fromTestableFilePath = \"/LF2U\DC4b\EMiFT\SYNQn\ENQnY)\ACK\\"\DC4\"}
+2021-01-22T04:32:19.9132039Z       Use --quickcheck-replay=62958 to reproduce.
+```
+on [https://github.com/datalad/git-annex/runs/1746587663?check_suite_focus=true](https://github.com/datalad/git-annex/runs/1746587663?check_suite_focus=true)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__/comment_3_e8432845460fd0598f8fea5d00c70993._comment b/doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__/comment_3_e8432845460fd0598f8fea5d00c70993._comment
new file mode 100644
index 0000000000..7f8b0c9019
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/prop__95__relPathDirToFileAbs__95__basics_fail_on_crippled___126__/comment_3_e8432845460fd0598f8fea5d00c70993._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-01-22T18:06:21Z"
+ content="""
+Please do not followup to closed bug reports with new problems.
+
+I've fixed this problem.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression_-_fails_to_drop_._Exit_code_11_wo_--debug__44___and_1_with_--debug.mdwn b/doc/projects/datalad/bugs-done/regression_-_fails_to_drop_._Exit_code_11_wo_--debug__44___and_1_with_--debug.mdwn
new file mode 100644
index 0000000000..739d35ea2c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression_-_fails_to_drop_._Exit_code_11_wo_--debug__44___and_1_with_--debug.mdwn
@@ -0,0 +1,106 @@
+### Please describe the problem.
+
+DataLad unittest (datalad/crawler/pipelines/tests/test_simple_s3.py:test_drop) checking communication of git-annex with our special remote started to hang (should have crashed I guess, yet to check) and the attempt in independent execution showed that git-annex simply crashes.  Downgrade from 6.20180506+gitg6316072f0-1~ndall+1 to 6.20180416+gitg86b18966f-1~ndall+1 resolved the issue. Seems to boil down to change on interactions with the remote with new version crashing with `git-annex: readDirStream: invalid argument (Bad file descriptor)`?
+
+May be manages to stop/kill the custom special remote before stopping communicating with it?
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> git annex whereis --all --debug
+[2018-05-07 21:49:18.991105877] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-05-07 21:49:18.997322576] process done ExitSuccess
+[2018-05-07 21:49:18.997426863] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-05-07 21:49:19.003137341] process done ExitSuccess
+[2018-05-07 21:49:19.003344009] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..f9909eda54827d61b254605b5631482b3dc65468","--pretty=%H","-n1"]
+[2018-05-07 21:49:19.007972053] process done ExitSuccess
+[2018-05-07 21:49:19.008717245] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-05-07 21:49:19.009717171] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+whereis MD5E-s8--966634ebf2fc135707d6753692bf4b1e.txt [2018-05-07 21:49:19.016115806] chat: /home/yoh/proj/datalad/datalad-master/venvs/dev/bin/git-annex-remote-datalad []
+[2018-05-07 21:49:19.832279118] git-annex-remote-datalad[1] --> VERSION 1
+[2018-05-07 21:49:19.832466638] git-annex-remote-datalad[1] <-- EXTENSIONS INFO
+[2018-05-07 21:49:19.832654467] git-annex-remote-datalad[1] --> UNSUPPORTED-REQUEST
+[2018-05-07 21:49:19.832898699] git-annex-remote-datalad[1] <-- PREPARE
+[2018-05-07 21:49:19.83308154] git-annex-remote-datalad[1] --> PREPARE-SUCCESS
+[2018-05-07 21:49:19.833153568] git-annex-remote-datalad[1] <-- WHEREIS MD5E-s8--966634ebf2fc135707d6753692bf4b1e.txt
+[2018-05-07 21:49:19.833276243] git-annex-remote-datalad[1] --> WHEREIS-FAILURE
+[2018-05-07 21:49:19.833536457] git-annex-remote-datalad[1] <-- CLAIMURL s3://datalad-test0-nonversioned/1version-nonversioned1.txt?versionId=null
+[2018-05-07 21:49:19.833847975] git-annex-remote-datalad[1] --> DEBUG Claiming url 's3://datalad-test0-nonversioned/1version-nonversioned1.txt?versionId=null'
+[2018-05-07 21:49:19.833975294] Claiming url 's3://datalad-test0-nonversioned/1version-nonversioned1.txt?versionId=null'
+[2018-05-07 21:49:19.834045759] git-annex-remote-datalad[1] --> CLAIMURL-SUCCESS
+(1 copy) 
+  	cf13d535-b47c-5df6-8590-0793cb08a90a -- [datalad]
+
+  datalad: s3://datalad-test0-nonversioned/1version-nonversioned1.txt?versionId=null
+ok
+git-annex: readDirStream: invalid argument (Bad file descriptor)
+
+(dev) 1 19899 ->1.....................................:Mon 07 May 2018 09:49:19 PM EDT:.
+
+# so -- it exited with exit code 1.  Downgrading now!
+
+$> sudo apt-get install git-annex-standalone=6.20180416+gitg86b18966f-1~ndall+1        
+...
+
+$> git annex whereis --all --debug                                                     
+[2018-05-07 21:50:33.064546504] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-05-07 21:50:33.075890599] process done ExitSuccess
+[2018-05-07 21:50:33.076053279] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-05-07 21:50:33.082610193] process done ExitSuccess
+[2018-05-07 21:50:33.082774661] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..f9909eda54827d61b254605b5631482b3dc65468","--pretty=%H","-n1"]
+[2018-05-07 21:50:33.088684568] process done ExitSuccess
+[2018-05-07 21:50:33.089343824] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-05-07 21:50:33.090037985] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-05-07 21:50:33.09515616] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-tree","--full-tree","-z","-r","--name-only","--","refs/heads/git-annex"]
+whereis MD5E-s8--966634ebf2fc135707d6753692bf4b1e.txt [2018-05-07 21:50:33.101385386] chat: /home/yoh/proj/datalad/datalad-master/venvs/dev/bin/git-annex-remote-datalad []
+[2018-05-07 21:50:33.935964594] git-annex-remote-datalad[1] --> VERSION 1
+[2018-05-07 21:50:33.936100411] git-annex-remote-datalad[1] <-- EXTENSIONS INFO
+[2018-05-07 21:50:33.936325748] git-annex-remote-datalad[1] --> UNSUPPORTED-REQUEST
+[2018-05-07 21:50:33.936398107] git-annex-remote-datalad[1] <-- PREPARE
+[2018-05-07 21:50:33.936521005] git-annex-remote-datalad[1] --> PREPARE-SUCCESS
+[2018-05-07 21:50:33.936577067] git-annex-remote-datalad[1] <-- WHEREIS MD5E-s8--966634ebf2fc135707d6753692bf4b1e.txt
+[2018-05-07 21:50:33.936676987] git-annex-remote-datalad[1] --> WHEREIS-FAILURE
+[2018-05-07 21:50:33.937304604] git-annex-remote-datalad[1] <-- CLAIMURL s3://datalad-test0-nonversioned/1version-nonversioned1.txt?versionId=null
+[2018-05-07 21:50:33.937515713] git-annex-remote-datalad[1] --> DEBUG Claiming url 's3://datalad-test0-nonversioned/1version-nonversioned1.txt?versionId=null'
+[2018-05-07 21:50:33.937580054] Claiming url 's3://datalad-test0-nonversioned/1version-nonversioned1.txt?versionId=null'
+[2018-05-07 21:50:33.937645676] git-annex-remote-datalad[1] --> CLAIMURL-SUCCESS
+(1 copy) 
+  	cf13d535-b47c-5df6-8590-0793cb08a90a -- [datalad]
+
+  datalad: s3://datalad-test0-nonversioned/1version-nonversioned1.txt?versionId=null
+ok
+[2018-05-07 21:50:33.973870482] process done ExitSuccess
+[2018-05-07 21:50:33.974304561] process done ExitSuccess
+[2018-05-07 21:50:33.97461093] process done ExitSuccess
+
+"""]]
+
+all kosher.
+
+Original manifestation was (note that exit code was 1 for with --debug and 139 (128+11) without --debug):
+
+
+[[!format sh """
+(git-annex)hopa:~/.tmp/datalad_temp_test_drop2bWvne[master]git
+$> git annex drop --debug --json --all --force --
+[2018-05-07 21:43:12.673253137] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-05-07 21:43:12.677379888] process done ExitSuccess
+[2018-05-07 21:43:12.677452681] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-05-07 21:43:12.681153081] process done ExitSuccess
+[2018-05-07 21:43:12.681279588] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..f9909eda54827d61b254605b5631482b3dc65468","--pretty=%H","-n1"]
+[2018-05-07 21:43:12.686123605] process done ExitSuccess
+[2018-05-07 21:43:12.686850715] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-05-07 21:43:12.687525693] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+git-annex: readDirStream: invalid argument (Bad file descriptor)
+(dev) 1 19888 ->1.....................................:Mon 07 May 2018 09:43:12 PM EDT:.
+(git-annex)hopa:~/.tmp/datalad_temp_test_drop2bWvne[master]git
+$> git annex drop  --json --all --force --     
+error: git-annex died of signal 11
+(dev) 1 19889 ->139.....................................:Mon 07 May 2018 09:43:16 PM EDT:.
+"""]]
+which also resolves with downgrade of git-annex.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/regression_-_fails_to_drop_._Exit_code_11_wo_--debug__44___and_1_with_--debug/comment_1_3c2578d17ce519f80aa278a546df29cf._comment b/doc/projects/datalad/bugs-done/regression_-_fails_to_drop_._Exit_code_11_wo_--debug__44___and_1_with_--debug/comment_1_3c2578d17ce519f80aa278a546df29cf._comment
new file mode 100644
index 0000000000..305eee8b38
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression_-_fails_to_drop_._Exit_code_11_wo_--debug__44___and_1_with_--debug/comment_1_3c2578d17ce519f80aa278a546df29cf._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-05-08T17:09:35Z"
+ content="""
+Neither git rev 6316072f0 nor 86b18966f is present in my git-annex git repo,
+which makes it kind of hard to look at the diff between whatever versions
+of git-annex you're running. Are you building out of a patched git
+repository?
+
+My guess is [[!commit bea0ad220a68138dc0a43d0c86bb2353ecf92d2c]]
+since it involves both directory reading and unsafeInterleaveIO.
+
+Indeed, it looks like that could defer a readDirStream due to
+unsafeInterleaveIO to outside the open/close bracket. And I suppose reading
+from a closed file handle might conceivably segfault.
+
+Looks like that would affect bare repositories, or using --all.
+I don't think it would affect those commands in a non-bare repository.
+Ah, I see youre whereis is indeed in a bare repository, and your drop
+used --all, so my analysis seems right.
+
+Fixed by backing out the problematic part of the commit.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls.mdwn b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls.mdwn
new file mode 100644
index 0000000000..51a5920869
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls.mdwn
@@ -0,0 +1,32 @@
+### Please describe the problem.
+
+some tests started to fail in datalad when tried current master version of annex
+
+### What version of git-annex are you using? On what operating system?
+
+6.20171205+gitgcf05ebbeb-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+(git-annex)hopa:/tmp/datalad_temp_test_AnnexRepo_web_remoteRusdWA[master]git
+$> git annex whereis --json 127.0.0.1_about.txt
+{"command":"whereis","note":"web: http://example.com/someurl\nweb: yt:http://127.0.0.1:33587/about.txt\n","success":true,"untrusted":[],"key":"SHA256E-s14--198775960d0d9827f134da4e219e5793949d24b62bfcb92aa9e2dc16d411b776.txt","whereis":[{"here":false,"uuid":"00000000-0000-0000-0000-000000000001","urls":["http://example.com/someurl","yt:http://127.0.0.1:33587/about.txt"],"description":"web"}],"file":"127.0.0.1_about.txt"}
+
+$> git annex whereis 127.0.0.1_about.txt      
+whereis 127.0.0.1_about.txt (1 copy) 
+  	00000000-0000-0000-0000-000000000001 -- web
+
+  web: http://example.com/someurl
+  web: yt:http://127.0.0.1:33587/about.txt
+
+"""]]
+
+This is a new behavior, this test was passing before, and I do not think we suggested that those test files are anyhow related to youtube before.
+
+Some tests also failed related to our datalad archives git annex special remote but I didn't look into them yet -- I guess though that it is related ;-)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_1_56cd6e167c86f4419ac0971922f2e5d1._comment b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_1_56cd6e167c86f4419ac0971922f2e5d1._comment
new file mode 100644
index 0000000000..ad2e84dc3c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_1_56cd6e167c86f4419ac0971922f2e5d1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-12-06T15:51:03Z"
+ content="""
+Reporoduced by putting "Lots of abouts" in a http://localhost/about.txt file,
+and running git annex addurl --file with an existing file and that url.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_2_1cebe1385d2b8a244afc259a78f72ada._comment b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_2_1cebe1385d2b8a244afc259a78f72ada._comment
new file mode 100644
index 0000000000..624d094fd9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_2_1cebe1385d2b8a244afc259a78f72ada._comment
@@ -0,0 +1,6 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-12-06T16:02:55Z"
+ content="""
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_2_ca0bf1079acc89a4a79e55f8f58403c0._comment b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_2_ca0bf1079acc89a4a79e55f8f58403c0._comment
new file mode 100644
index 0000000000..60e3d3bd3e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_2_ca0bf1079acc89a4a79e55f8f58403c0._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2017-12-08T02:32:15Z"
+ content="""
+Thanks for the fix... seems to be a bit incomplete though -- in the --fast mode, url still has yt: prefix, reflected in the key as well:
+
+[[!format sh \"\"\"
+
+$> ls -l
+total 4
+lrwxrwxrwx 1 yoh yoh 110 Dec  7 21:27 1-copy.dat -> .git/annex/objects/gw/pw/URL--yt&chttp&c%%127.0.0.1&c34337%d1%1.dat/URL--yt&chttp&c%%127.0.0.1&c34337%d1%1.dat
+
+$> git annex whereis 1-copy.dat
+whereis 1-copy.dat (1 copy) 
+  	00000000-0000-0000-0000-000000000001 -- web
+
+  web: yt:http://127.0.0.1:34337/d1/1.dat
+ok
+
+$> git annex version
+git-annex version: 6.20171206+gitgc6e4bc0a2-1~ndall+1
+
+\"\"\"]]
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_4_f05e1047c5d22dddba21a9faa3397f0d._comment b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_4_f05e1047c5d22dddba21a9faa3397f0d._comment
new file mode 100644
index 0000000000..b2aec7da15
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_4_f05e1047c5d22dddba21a9faa3397f0d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-12-08T18:48:46Z"
+ content="""
+That one happened with `git annex addurl --fast $url` so a different code
+path. Had to add a html page check to youtubeDlFileName to fix it.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_5_811ba6ec07f6f30c701201178cdb00ac._comment b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_5_811ba6ec07f6f30c701201178cdb00ac._comment
new file mode 100644
index 0000000000..aaf8143bd0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_5_811ba6ec07f6f30c701201178cdb00ac._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2017-12-11T05:27:15Z"
+ content="""
+ok, tested with 6.20171208+gitg01f78e877-1~ndall+1 -- --fast mode issue is indeed resolved.  Thanks!
+Failing tests now only relate to our special remote (datalad-archives) which interfaces urls, so I thought it might relate... I will try to distill more info tomorrow unless you beat me to it figuring out where that regression could be (upon quick look didn't spot any yt: anywhere, so probably another issue) 
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_6_2cd156baab77dc3b3c248a2368b59040._comment b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_6_2cd156baab77dc3b3c248a2368b59040._comment
new file mode 100644
index 0000000000..4dddd9af6b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_6_2cd156baab77dc3b3c248a2368b59040._comment
@@ -0,0 +1,105 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2017-12-11T14:40:26Z"
+ content="""
+ok, first initial bit of information:  there is a difference in interactions with the special remote now. Here is the diff between old and new runs (sorry - content was also changing so there is difference in keys as well):
+
+[[!format sh \"\"\"
+$> diff -Nar -u6 /tmp/datalad_temp_tree_check_basic_scenarioVEOIhb/.git/bin/git-annex-remote-datalad-archive /tmp/datalad_temp_tree_check_basic_scenarioIfsLo7/.git/bin/git-annex-remote-datalad-archive
+--- /tmp/datalad_temp_tree_check_basic_scenarioVEOIhb/.git/bin/git-annex-remote-datalad-archive	2017-12-11 08:56:38.381298365 -0500
++++ /tmp/datalad_temp_tree_check_basic_scenarioIfsLo7/.git/bin/git-annex-remote-datalad-archive	2017-12-11 08:56:14.885677071 -0500
+@@ -48,66 +48,72 @@
+ ### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'add', '--debug', '--json', 'simple.txt']
+ 
+ ### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'commit', '-m', 'Added the load file']
+ 
+ ### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'lookupkey', '--debug', 'a.tar.gz']
+ 
+-### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'addurl', '--debug', '--relaxed', '--file=simple.txt', 'dl+archive:SHA256E-s172--70cf6dd95738e5d3672a7139a2785b0a979f0f7955d0f6da0d94cc03c84a63b7.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+']
++### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'addurl', '--debug', '--relaxed', '--file=simple.txt', 'dl+archive:SHA256E-s173--db0a9680f8d15578de8e4a5b5c1e87f36d9372d6118fb24c1c60f390e71ad3c1.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+']
+ #send VERSION 1
+ #recv PREPARE
+ #send PREPARE-SUCCESS
+ #recv GETCOST
+ #send COST 500
+ #recv GETAVAILABILITY
+ #send AVAILABILITY LOCAL
+-#recv CLAIMURL dl+archive:SHA256E-s172--70cf6dd95738e5d3672a7139a2785b0a979f0f7955d0f6da0d94cc03c84a63b7.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+
+-#send DEBUG Claiming url 'dl+archive:SHA256E-s172--70cf6dd95738e5d3672a7139a2785b0a979f0f7955d0f6da0d94cc03c84a63b7.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+'
++#recv CLAIMURL dl+archive:SHA256E-s173--db0a9680f8d15578de8e4a5b5c1e87f36d9372d6118fb24c1c60f390e71ad3c1.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+
++#send DEBUG Claiming url 'dl+archive:SHA256E-s173--db0a9680f8d15578de8e4a5b5c1e87f36d9372d6118fb24c1c60f390e71ad3c1.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+'
+ #send CLAIMURL-SUCCESS
+-#recv CHECKURL dl+archive:SHA256E-s172--70cf6dd95738e5d3672a7139a2785b0a979f0f7955d0f6da0d94cc03c84a63b7.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+
++#recv CHECKURL dl+archive:SHA256E-s173--db0a9680f8d15578de8e4a5b5c1e87f36d9372d6118fb24c1c60f390e71ad3c1.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+
+ #send CHECKURL-CONTENTS UNKNOWN
+ #recv 
+ 
+ ### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'drop', '--debug', '--json', 'simple.txt']
+ #send VERSION 1
+ #recv PREPARE
+ #send PREPARE-SUCCESS
+ #recv CHECKPRESENT SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.txt
+ #send GETURLS SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.txt dl+archive:
+-#recv VALUE dl+archive:SHA256E-s172--70cf6dd95738e5d3672a7139a2785b0a979f0f7955d0f6da0d94cc03c84a63b7.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+
++#recv VALUE dl+archive:SHA256E-s173--db0a9680f8d15578de8e4a5b5c1e87f36d9372d6118fb24c1c60f390e71ad3c1.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+
+ #recv VALUE 
+ #send CHECKPRESENT-SUCCESS SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.txt
+ #recv 
+ 
+ ### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'whereis', '--debug', '--json', 'simple.txt']
+ #send VERSION 1
+ #recv PREPARE
+ #send PREPARE-SUCCESS
+ #recv WHEREIS SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.txt
+ #send WHEREIS-FAILURE
+-#recv CLAIMURL dl+archive:SHA256E-s172--70cf6dd95738e5d3672a7139a2785b0a979f0f7955d0f6da0d94cc03c84a63b7.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+
+-#send DEBUG Claiming url 'dl+archive:SHA256E-s172--70cf6dd95738e5d3672a7139a2785b0a979f0f7955d0f6da0d94cc03c84a63b7.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+'
+-#send CLAIMURL-SUCCESS
+ #recv 
+ 
+ ### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'find', '--debug', '--json', '--not', '--in', 'here', 'simple.txt']
+ 
+ ### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'get', '--debug', '--json', '--json-progress', 'simple.txt']
+ #send VERSION 1
+ #recv PREPARE
+ #send PREPARE-SUCCESS
+ #recv TRANSFER RETRIEVE SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.txt .git/annex/tmp/SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.txt
+ #send GETURLS SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.txt dl+archive:
+-#recv VALUE dl+archive:SHA256E-s172--70cf6dd95738e5d3672a7139a2785b0a979f0f7955d0f6da0d94cc03c84a63b7.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+
++#recv VALUE dl+archive:SHA256E-s173--db0a9680f8d15578de8e4a5b5c1e87f36d9372d6118fb24c1c60f390e71ad3c1.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+
+ #recv VALUE 
+ #send TRANSFER-SUCCESS RETRIEVE SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.txt
+ #recv 
+ 
+-### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'rmurl', '--debug', 'simple.txt', 'dl+archive:SHA256E-s172--70cf6dd95738e5d3672a7139a2785b0a979f0f7955d0f6da0d94cc03c84a63b7.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+']
++### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'rmurl', '--debug', 'simple.txt', 'dl+archive:SHA256E-s173--db0a9680f8d15578de8e4a5b5c1e87f36d9372d6118fb24c1c60f390e71ad3c1.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+']
++#send VERSION 1
++#recv PREPARE
++#send PREPARE-SUCCESS
++#recv CLAIMURL dl+archive:SHA256E-s173--db0a9680f8d15578de8e4a5b5c1e87f36d9372d6118fb24c1c60f390e71ad3c1.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+
++#send DEBUG Claiming url 'dl+archive:SHA256E-s173--db0a9680f8d15578de8e4a5b5c1e87f36d9372d6118fb24c1c60f390e71ad3c1.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+'
++#send CLAIMURL-SUCCESS
++#recv 
++
++### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'drop', '--debug', '--json', 'simple.txt']
+ send VERSION 1
+ recv PREPARE
+ send PREPARE-SUCCESS
+-recv CLAIMURL dl+archive:SHA256E-s172--70cf6dd95738e5d3672a7139a2785b0a979f0f7955d0f6da0d94cc03c84a63b7.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+
+-send DEBUG Claiming url 'dl+archive:SHA256E-s172--70cf6dd95738e5d3672a7139a2785b0a979f0f7955d0f6da0d94cc03c84a63b7.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+'
+-send CLAIMURL-SUCCESS
++recv CHECKPRESENT SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.txt
++send GETURLS SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.txt dl+archive:
++recv VALUE dl+archive:SHA256E-s173--db0a9680f8d15578de8e4a5b5c1e87f36d9372d6118fb24c1c60f390e71ad3c1.tar.gz#path=a/d/+%22%27%3Ba%26b%26cd+%60%7C+
++recv VALUE 
++send CHECKPRESENT-SUCCESS SHA256E-s3--a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3.txt
+ recv 
+-
+-### ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'drop', '--debug', '--json', 'simple.txt']
+
+
+\"\"\"]]
+[our test](https://github.com/datalad/datalad/blob/master/datalad/customremotes/tests/test_archives.py#L86) verifies that annex refuses  to drop the content if we remove the dl+archive link for  the key, and now it fails
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_7_9f3f7c04524063960f1451c90948a41f._comment b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_7_9f3f7c04524063960f1451c90948a41f._comment
new file mode 100644
index 0000000000..f3cd71433b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_7_9f3f7c04524063960f1451c90948a41f._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2017-12-11T17:12:41Z"
+ content="""
+The diff shows `git annex whereis` used to send CLAIMURL to the external,
+and no longer does.
+
+Reproduction recipe using git-annex-remote-ipfs:
+
+	git annex initremote ipfs type=external externaltype=ipfs encryption=none
+	date > somefile
+	git annex add somefile
+	git annex addurl --debug --relaxed ipfs:dummy --file somefile
+
+Which results in `git annex whereis somefile` saying it's present in ipfs,
+but not listing the ipfs url for it. And again, whereis does not sent
+CLAIMURL.
+
+And, in log.web, I see why:
+
+	+1513013502.312530881s 1 ipfs:dummy
+
+That is not an OtherDownloader url, it's lacking the ":" prefix.
+
+This seems to be particular to the addurl --relaxed --file code path;
+letting addurl add a new file does result in an OtherDownloader url
+being recorded.
+
+I guess the reason the test suite then fails is, the url it removes is not
+the one git-annex recorded, and so git-annex still thinks it's at the wrongly
+recorded url, and so dropping succeeds.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_8_55b111079ecb9732a42d3486160e77b5._comment b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_8_55b111079ecb9732a42d3486160e77b5._comment
new file mode 100644
index 0000000000..7e91d6208f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression_-_yt__58___prefix_for___34__regular__34___urls/comment_8_55b111079ecb9732a42d3486160e77b5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2017-12-11T17:43:30Z"
+ content="""
+Above problem fixed in [[!commit bd7f8be121a5cd310ffbc32c6020326ef437a151]
+
+Good thing you have such a good test suite.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___annex_add_of_moved_file_errors_out.mdwn b/doc/projects/datalad/bugs-done/regression__58___annex_add_of_moved_file_errors_out.mdwn
new file mode 100644
index 0000000000..10a7e25c36
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___annex_add_of_moved_file_errors_out.mdwn
@@ -0,0 +1,48 @@
+### Please describe the problem.
+
+originally filed/investigated in [DataLad #6778](https://github.com/datalad/datalad/issues/6778).
+
+<details>
+<summary>Following reproducer which simply git annex adds  a moved to subdirectory annexed file</summary> 
+
+```bash
+#!/bin/bash
+
+cd "$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)"
+set -eu
+
+git init
+git annex init
+
+echo 123 > 123
+git annex add 123
+git commit -m 'commit 123'
+
+mkdir sub
+mv 123 sub
+git annex add sub/123
+git commit -m 'committing moved'
+
+```
+</details>
+
+crashes with
+
+```
+[master (root-commit) 30d904b] commit 123
+ 1 file changed, 1 insertion(+)
+ create mode 120000 123
+add sub/123 
+git-annex: sub/123: rename: does not exist (No such file or directory)
+failed
+add: 1 failed
+```
+
+with recent (after 10.20220525+git96-gf259be7f3, full range for when bug introduced AFAIK is 10.20220525+git81-g8916c818b..10.20220525+git96-gf259be7f3) git-annex
+
+As this is such a basic operation, I am still wondering how come it is not caught by git-annex tests and only 1 of our datalad tests managed to pick this up!
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]], with a test case added for this edge case. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___fails_to___39__add_.__39___if_file_was_renamed.mdwn b/doc/projects/datalad/bugs-done/regression__58___fails_to___39__add_.__39___if_file_was_renamed.mdwn
new file mode 100644
index 0000000000..985e4a958e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___fails_to___39__add_.__39___if_file_was_renamed.mdwn
@@ -0,0 +1,51 @@
+### Please describe the problem.
+
+It was introduced somewhere between `10.20220322-1~ndall+1` to `10.20220724-1~ndall+1` ( I will try to bisect now) and started to cause datalad-crawler tests to fail with that upgrade, see [crawler issue](https://github.com/datalad/datalad-crawler/issues/124). Here is the situation in the nutshell:
+
+```
+(git-annex)lena:~/.tmp/datalad_temp_test_balsa_extract_meta6ro1j8gw[incoming-processed]git
+$> git status
+On branch incoming-processed
+All conflicts fixed but you are still merging.
+  (use "git commit" to conclude merge)
+
+Changes to be committed:
+	new file:   .datalad/crawl/statuses/incoming.json
+	new file:   .datalad/meta/balsa.json
+	new file:   _files/dir1/file2.nii
+	new file:   _files/file1.nii
+	new file:   dir1/file2.nii
+	new file:   file1.nii
+
+Changes not staged for commit:
+  (use "git add/rm <file>..." to update what will be committed)
+  (use "git restore <file>..." to discard changes in working directory)
+	deleted:    _files/dir1/file2.nii
+	deleted:    _files/file1.nii
+
+$> /usr/lib/git-annex.linux/git annex add .                                  
+git-annex: _files/dir1/file2.nii: getSymbolicLinkStatus: does not exist (No such file or directory)
+
+```
+
+here is a minimal reproducer
+
+```shell
+$> ( export PATH=/usr/lib/git-annex.linux/:$PATH; chmod +w -R /tmp/repo || : ; rm -rf /tmp/repo; mkdir /tmp/repo; cd /tmp/repo; git init; git annex init; touch file; git annex add file; rm file; git annex add .; echo $?)
+Initialized empty Git repository in /tmp/repo/.git/
+init  ok
+(recording state in git...)
+add file 
+ok
+(recording state in git...)
+git-annex: file: getSymbolicLinkStatus: does not exist (No such file or directory)
+1
+```
+
+I am a little surprised that it is only datalad-crawler, not datalad or git-annex, unittests pick up on this :-/
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___fails_to___39__add_.__39___if_file_was_renamed/comment_1_bd132d7cfa21b2ea3236b76dffaff156._comment b/doc/projects/datalad/bugs-done/regression__58___fails_to___39__add_.__39___if_file_was_renamed/comment_1_bd132d7cfa21b2ea3236b76dffaff156._comment
new file mode 100644
index 0000000000..02e5faee10
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___fails_to___39__add_.__39___if_file_was_renamed/comment_1_bd132d7cfa21b2ea3236b76dffaff156._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2022-08-17T19:55:45Z"
+ content="""
+bisected to [10.20220525-96-gf259be7f3 AKA 10.20220624~22](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=f259be7f39d6c1746b6b809f15b9a227624a0cd8)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___fails_to___39__add_.__39___if_file_was_renamed/comment_2_bceb84ed261a160c4041c146372fc551._comment b/doc/projects/datalad/bugs-done/regression__58___fails_to___39__add_.__39___if_file_was_renamed/comment_2_bceb84ed261a160c4041c146372fc551._comment
new file mode 100644
index 0000000000..e2ca79d78b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___fails_to___39__add_.__39___if_file_was_renamed/comment_2_bceb84ed261a160c4041c146372fc551._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-08-19T16:39:11Z"
+ content="""
+Fixed this.
+
+The test suite does test add of renamed files, but just barely missed it
+since it ran git-annex add of the destination file only.
+Added a test case for this.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w.mdwn b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w.mdwn
new file mode 100644
index 0000000000..56c7771f10
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w.mdwn
@@ -0,0 +1,68 @@
+Upon datalad's `clone`
+
+<details>
+<summary>with git-annex 8.20210630-1~ndall+1 and bundled git 2.24.0</summary> 
+
+```shell
+(git-annex)lena:~/.tmp/datalad_temp_check_recklesssutnjo68[adjusted/master(unlocked)]git-annex
+$> cat .git/config
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+	sharedrepository = 1
+	symlinks = false
+[remote "origin"]
+	url = /home/yoh/.tmp/datalad_temp_check_recklesswnpsqpys
+	fetch = +refs/heads/*:refs/remotes/origin/*
+	annex-uuid = a69ecda5-b653-4147-b190-37b7911e3ebc
+[branch "master"]
+	remote = origin
+	merge = refs/heads/master
+[annex "security"]
+	allowed-url-schemes = http https file
+	allowed-http-addresses = all
+[receive]
+	denyNonFastforwards = true
+[annex]
+	uuid = 06e1e8e1-32ca-484e-9dd6-daf332da0b36
+	crippledfilesystem = true
+	version = 8
+[filter "annex"]
+	smudge = git-annex smudge -- %f
+	clean = git-annex smudge --clean -- %f
+[datalad "clone"]
+	reckless = shared-group
+
+$> ls -ld .git/annex/index*   
+-rw-rw---- 1 yoh yoh 209 Jul  7 18:24 .git/annex/index
+-rw------- 1 yoh yoh  41 Jul  7 18:24 .git/annex/index.lck
+
+```
+</details>
+
+we end up with group non-writeable index.lck, whenever before
+
+<details>
+<summary>it was writeable with annex 8.20210330-1~ndall+1 and git 2.24.0 </summary> 
+
+```shell
+$> ls -ld .git/annex/index*                             
+-rw-rw---- 1 yoh yoh 209 Jul  7 18:29 .git/annex/index
+-rw-rw---- 1 yoh yoh  41 Jul  7 18:29 .git/annex/index.lck
+
+$> git annex version | head -n 1
+git-annex version: 8.20210330-1~ndall+1
+
+```
+</details>
+
+is that somehow intended (didn't spot anything in CHANGELOG.md) or a regression?
+
+reference: https://github.com/datalad/datalad/issues/5759
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_1_7f25fd487c60f8b6fcaddd1444d898af._comment b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_1_7f25fd487c60f8b6fcaddd1444d898af._comment
new file mode 100644
index 0000000000..9fa3ebdc01
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_1_7f25fd487c60f8b6fcaddd1444d898af._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-07-12T13:42:12Z"
+ content="""
+Is datalad doing something with the new annex.freezecontent-command?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_2_92c7a561537e0c6628f30be233b9d7f6._comment b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_2_92c7a561537e0c6628f30be233b9d7f6._comment
new file mode 100644
index 0000000000..d6b29b13e7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_2_92c7a561537e0c6628f30be233b9d7f6._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-07-12T13:46:18Z"
+ content="""
+I don't think annex.freezecontent-command will affect writing this file
+though.
+
+This seems to be how to reproduce it:
+
+	git config sharedRepository group
+	git annex init
+
+	-rw-rw-r-- 1 joey joey 137 Jul 12 09:53 .git/annex/index
+	-rw-r--r-- 1 joey joey  41 Jul 12 09:53 .git/annex/index.lck
+
+Not identical modes here, but with an older git-annex the index.lck is 664
+not 644.
+
+Also, for some reason git-annex init with that config set complains that
+"Filesystem allows writing to files whose write bit is not set."
+And enters an adjusted brach. The older git-annex didn't do that either.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_3_621beade26a1dbbdea000ca43d93a325._comment b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_3_621beade26a1dbbdea000ca43d93a325._comment
new file mode 100644
index 0000000000..e5ab4703aa
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_3_621beade26a1dbbdea000ca43d93a325._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-07-12T14:09:19Z"
+ content="""
+Fixed the problem with git-annex init's probing. 
+
+Oh, that's odd, fixing that also fixed the index.lck permissions.
+
+So, the actual cause of the permissions problem is init deciding to enter
+an adjusted unlocked branch. Entering the branch after init does not result
+in the problem though. So still need to track down what's happening there,
+since it can enter the adjusted branch for other reasons.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_4_3b19a1d3e0e13e407af476b54b725bd1._comment b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_4_3b19a1d3e0e13e407af476b54b725bd1._comment
new file mode 100644
index 0000000000..ef5655e4c5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_4_3b19a1d3e0e13e407af476b54b725bd1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-07-12T14:41:50Z"
+ content="""
+The bug was making init set annex.crippledfilesystem,
+and once that's set, git-annex avoids setting file
+perms, so then it writes index.lck it leaves it at the default permissions.
+
+That might or might not be a problem in some case (eg if some filesystem
+was detected as crippled but still supported file permissions to a point
+that write bits need to be added to support core.sharedRepository = group), but 
+the reversion was fixed by fixing init's behavior. So, closing this.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_5_0655ad5ece1ccd1892ea217aac493594._comment b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_5_0655ad5ece1ccd1892ea217aac493594._comment
new file mode 100644
index 0000000000..5ebe0236be
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_5_0655ad5ece1ccd1892ea217aac493594._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2021-07-12T17:44:58Z"
+ content="""
+FWIW FTR: the fix (will check on datalad side with the next cron build) is likely the [8.20210630-52-g6a581f8b8](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=6a581f8b8b54719f2c34fdeb071e546d9a8f64c9) (I still don't know how to navigate from the `[fixed]` tag to actual fix/version)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_6_9dce3bf28e416dbcc08b314dbc08c8a4._comment b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_6_9dce3bf28e416dbcc08b314dbc08c8a4._comment
new file mode 100644
index 0000000000..13908ebeac
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___index.lck_in_shared-group_is_not_g+w/comment_6_9dce3bf28e416dbcc08b314dbc08c8a4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-07-12T20:00:32Z"
+ content="""
+Yes that's the commit. Normally I'd have closed it in the commit but I
+didn't realize at that point that the commit actually fixed it.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___standalone_build_is_deficient_on_linux_after_7.20190819+git2-g908476a9b-1__126__ndall+1_some_time.mdwn b/doc/projects/datalad/bugs-done/regression__58___standalone_build_is_deficient_on_linux_after_7.20190819+git2-g908476a9b-1__126__ndall+1_some_time.mdwn
new file mode 100644
index 0000000000..9ec6964e7b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___standalone_build_is_deficient_on_linux_after_7.20190819+git2-g908476a9b-1__126__ndall+1_some_time.mdwn
@@ -0,0 +1,79 @@
+### Please describe the problem.
+
+There were a few changes introduced since then to Makefile (I will not guess which one broke it) which resulted in git within git-annex-standalone of neurodebian to be unable to clone from https://:
+
+
+[[!format sh """
+$> /usr/lib/git-annex.linux/git clone https://github.com/afni/afni_ci_test_data.git                            
+Cloning into 'afni_ci_test_data'...
+fatal: unable to find remote helper for 'https'
+
+"""]]
+
+<details>
+<summary>diff between list of files in 7.20190819+git60-gcdb679818 and 7.20191017+git2-g7b13db551 package builds shows many git-* missing</summary>
+[[!format sh """
+lena:/tmp
+$> ls 7.2019*/usr/lib/git-annex.linux/exe/                                         
+7.20190819/usr/lib/git-annex.linux/exe/:
+cp@                            git-diff-index@          git-mktag@                git-sh-i18n--envsubst@
+curl@                          git-diff-tree@           git-mktree@               git-shell@
+git@                           git-difftool@            git-multi-pack-index@     git-shortlog@
+git-add@                       git-fast-export@         git-mv@                   git-show@
+git-am@                        git-fast-import@         git-name-rev@             git-show-branch@
+git-annex@                     git-fetch@               git-notes@                git-show-index@
+git-annex-shell@               git-fetch-pack@          git-pack-objects@         git-show-ref@
+git-annotate@                  git-fmt-merge-msg@       git-pack-redundant@       git-stage@
+git-apply@                     git-for-each-ref@        git-pack-refs@            git-status@
+git-archive@                   git-format-patch@        git-patch-id@             git-stripspace@
+git-bisect--helper@            git-fsck@                git-prune@                git-submodule--helper@
+git-blame@                     git-fsck-objects@        git-prune-packed@         git-symbolic-ref@
+git-branch@                    git-gc@                  git-pull@                 git-tag@
+git-bundle@                    git-get-tar-commit-id@   git-push@                 git-unpack-file@
+git-cat-file@                  git-grep@                git-range-diff@           git-unpack-objects@
+git-check-attr@                git-hash-object@         git-read-tree@            git-update-index@
+git-check-ignore@              git-help@                git-rebase@               git-update-ref@
+git-check-mailmap@             git-http-backend@        git-rebase--interactive@  git-update-server-info@
+git-check-ref-format@          git-http-fetch@          git-receive-pack@         git-upload-archive@
+git-checkout@                  git-http-push@           git-reflog@               git-upload-pack@
+git-checkout-index@            git-imap-send@           git-remote@               git-var@
+git-cherry@                    git-index-pack@          git-remote-ext@           git-verify-commit@
+git-cherry-pick@               git-init@                git-remote-fd@            git-verify-pack@
+git-clean@                     git-init-db@             git-remote-ftp@           git-verify-tag@
+git-clone@                     git-interpret-trailers@  git-remote-ftps@          git-whatchanged@
+git-column@                    git-log@                 git-remote-http@          git-worktree@
+git-commit@                    git-ls-files@            git-remote-https@         git-write-tree@
+git-commit-graph@              git-ls-remote@           git-remote-testsvn@       localedef@
+git-commit-tree@               git-ls-tree@             git-remote-tor-annex@     lsof@
+git-config@                    git-mailinfo@            git-repack@               rsync@
+git-count-objects@             git-mailsplit@           git-replace@              sh@
+git-credential@                git-merge@               git-rerere@               ssh@
+git-credential-cache@          git-merge-base@          git-reset@                ssh-keygen@
+git-credential-cache--daemon@  git-merge-file@          git-rev-list@             tar@
+git-credential-store@          git-merge-index@         git-rev-parse@            uname@
+git-daemon@                    git-merge-ours@          git-revert@               xargs@
+git-describe@                  git-merge-recursive@     git-rm@
+git-diff@                      git-merge-subtree@       git-send-pack@
+git-diff-files@                git-merge-tree@          git-serve@
+
+7.20191017/usr/lib/git-annex.linux/exe/:
+cp@                    git-credential-cache--daemon@  git-http-push@         git-sh-i18n--envsubst@  sh@
+curl@                  git-credential-store@          git-imap-send@         git-shell@              ssh@
+git@                   git-daemon@                    git-receive-pack@      git-upload-pack@        ssh-keygen@
+git-annex@             git-fast-import@               git-remote-http@       localedef@              tar@
+git-annex-shell@       git-http-backend@              git-remote-testsvn@    lsof@                   uname@
+git-credential-cache@  git-http-fetch@                git-remote-tor-annex@  rsync@                  xargs@
+
+
+"""]]
+
+</details>
+
+so may be that is related.
+
+Unfortunately in datalad we had no test testing cloning over https, so I added such integration test in https://github.com/datalad/datalad/pull/3867 to at least detect such regressions in the future before hitting the userland
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/regression__58___standalone_build_is_deficient_on_linux_after_7.20190819+git2-g908476a9b-1__126__ndall+1_some_time/comment_1_1735409e62ce82f7ba7258b0167fda06._comment b/doc/projects/datalad/bugs-done/regression__58___standalone_build_is_deficient_on_linux_after_7.20190819+git2-g908476a9b-1__126__ndall+1_some_time/comment_1_1735409e62ce82f7ba7258b0167fda06._comment
new file mode 100644
index 0000000000..1c80ed5ecb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/regression__58___standalone_build_is_deficient_on_linux_after_7.20190819+git2-g908476a9b-1__126__ndall+1_some_time/comment_1_1735409e62ce82f7ba7258b0167fda06._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-11-14T18:14:35Z"
+ content="""
+It will either be caused by 5463f97ca216cd261f7a1da08aa8a62cef415a71 or by
+a new version of git reorging files (or both).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi.mdwn b/doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi.mdwn
new file mode 100644
index 0000000000..adf1b4198c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi.mdwn
@@ -0,0 +1,43 @@
+When using `reinject <src> <dest>` and `dest` is an absolute path to a
+pointer file, the operation silently fails to reinject the content.
+
+[[!format sh """
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/ga-XXXXXXX)" || exit 1
+
+git version
+git annex version | head -1
+
+git init -q
+git annex init
+git config annex.addunlocked true
+
+git annex fromkey --force \
+    SHA256E-s3--2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae \
+    foo
+
+printf foo >.git/tmp-to-copy
+git annex reinject .git/tmp-to-copy "$PWD"/foo
+echo $?
+cat foo
+"""]]
+
+```
+git version 2.31.1.705.g1ce651569c
+git-annex version: 8.20210429-g06e996efa
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
+fromkey foo ok
+(recording state in git...)
+0
+/annex/objects/SHA256E-s3--2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
+```
+
+If a link destination is used (i.e. drop the `addunlocked`
+configuration in the script above) or a relative path is used
+(i.e. drop the `"$PWD"/`), the content is injected.
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi/comment_1_10590563da0f80fa8326a90977966509._comment b/doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi/comment_1_10590563da0f80fa8326a90977966509._comment
new file mode 100644
index 0000000000..ac33c842fa
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi/comment_1_10590563da0f80fa8326a90977966509._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-05-07T15:57:03Z"
+ content="""
+It thinks the file is not annexed, due to asking git cat-file about it, and
+git cat-file not supporting paths that extend outside the repo.
+
+Most commands pass through ls-files which makes absolute relative.
+A similar bug has been fixed earlier for --batch with absolute
+filenames, [[!commit 957a87b437d6f056aa159e484a5f0a5af54e45db]].
+
+Also, `git-annex reinject /path/to/foo bar` fails to notice when the first
+parameter is an annexed file, for the same reason.
+
+And, grepping for ifAnnexed, whenAnnexed, and lookupKey, I found some
+other commands that also have the same problem, including rekey
+(also silently skips it), addurl --file (refuses to overwrite file, rather
+than adding url to key), rmurl (silently skips). Seems likely there are
+other commands with the bug too, that call those functions indirectly.
+
+Also, `git annex reinject content ../thisrepo/foo` fails in a really ugly
+way with a lot of "is outside repository" from git (despite it being
+inside the repository).
+
+So I think that it probably makes sense for catKeyFile to fix up the path
+to avoid these problems. There could be other problems caused by absolute
+paths, but at least that would eliminate this particular set of bugs.
+
+---
+
+This also raises the question of why reinject silently ignores non-annexed
+files. I don't think there's really a good reason, other than git-annex
+generally ignoring non-annexed files. But in this case, the user is
+explicitly providing the content of the file, so has a high
+expectation it's annexed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi/comment_2_1b9b2ebc78949c7b39a255c291d11891._comment b/doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi/comment_2_1b9b2ebc78949c7b39a255c291d11891._comment
new file mode 100644
index 0000000000..0db337caf4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi/comment_2_1b9b2ebc78949c7b39a255c291d11891._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-05-07T17:28:43Z"
+ content="""
+Fixed them all, and made reinject not skip over non-annexed files.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi/comment_3_0ec752dbe8ef55a9884c1c5e83887505._comment b/doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi/comment_3_0ec752dbe8ef55a9884c1c5e83887505._comment
new file mode 100644
index 0000000000..60c0c2084e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/reinject__58___silent_failure_with_absolute_path_to_poi/comment_3_0ec752dbe8ef55a9884c1c5e83887505._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="thanks"
+ date="2021-05-07T18:07:24Z"
+ content="""
+Sounds great, thank you!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn b/doc/projects/datalad/bugs-done/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn
new file mode 100644
index 0000000000..251cf0424e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn
@@ -0,0 +1,48 @@
+### Please describe the problem.
+
+Originally spotted/reported: https://github.com/datalad/datalad/issues/1020
+
+If that is mandatory, then I guess there should be some error message.
+
+### What steps will reproduce the problem?
+
+create a remote repo without specifying version, i.e. of version 5 and copy data into it
+
+### What version of git-annex are you using? On what operating system?
+
+6.20160923+gitgd1dabb3-1~ndall+1
+
+### Please provide any additional information below.
+
+Output from running http://www.onerussian.com/tmp/v6-push.sh  with argument which specifies annex version within remote 
+
+[[!format sh """
+
+$> ./v6-push.sh 5 2>&1 | grep '>>>' 
+>>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
+>>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
+
+$> ./v6-push.sh 6 2>&1 | grep '>>>' 
+>>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
+>>> 123
+
+"""]]
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> The data loss bugs are fixed in [[!commit ee309d694161d0f416420db6c4efb834c813351e]].
+> 
+> I am not sure yet why the keys database lacked an entry for the file;
+> perhaps something to do with it being a v6 unlocked file in a v5
+> repository.
+> 
+> Ok.. Seems that cloning to a v5 repository, and then copying/getting
+> objects into it, and then upgrading to v6 reproduces the problem with the
+> keys database. The inode cache does not get populated for unlocked files
+> on upgrade. Also, unlocked files stay as pointer files even when their
+> content is present in annex/objects. Fixed the upgrade process to handle
+> this case.
+> 
+> [[fixed|done]]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/reports_success_when_addurl_--batch__a_file_which_is_.gitignore__39__d.mdwn b/doc/projects/datalad/bugs-done/reports_success_when_addurl_--batch__a_file_which_is_.gitignore__39__d.mdwn
new file mode 100644
index 0000000000..fa55d3ee6c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/reports_success_when_addurl_--batch__a_file_which_is_.gitignore__39__d.mdwn
@@ -0,0 +1,37 @@
+### Please describe the problem.
+
+Reports success although file is not added to git, since ignored due to .gitignore
+
+Although not sure yet if that is annex could actually take care about since probably annex stages those for 'add' command to git so wouldn't know right when addurl is called for a specific file?
+
+### What steps will reproduce the problem?
+
+see below
+
+### What version of git-annex are you using? On what operating system?
+
+6.20160728+gitg9a2fe62-1~ndall+1
+
+
+[[!format sh """
+
+$> rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; echo "*exclude*" >| .git/info/exclude; git annex init; { echo "http://www.onerussian.com/tmp/1exclude.txt 1exclude.txt"; echo "2nd one" >&2; echo "http://www.onerussian.com/tmp/2.txt 2.txt"\; } | git annex addurl -c annex.largefiles=exclude=*.txt --batch --json --with-files                                                                       
+Initialized empty Git repository in /tmp/123/.git/
+init  ok
+(recording state in git...)
+2nd one
+{"command":"addurl","key":null,"file":"1exclude.txt","note":"downloading http://www.onerussian.com/tmp/1exclude.txt ...","note":"non-large file; adding content to git repository","success":true}
+{"command":"addurl","key":null,"file":"2.txt;","note":"downloading http://www.onerussian.com/tmp/2.txt ...","key":"SHA256E-s2--53c234e5e8472b6ac51c1ae1cab3fe06fad053beb8ebfd8977b010655bfdd3c3.txt","success":true}
+The following paths are ignored by one of your .gitignore files:
+1exclude.txt
+Use -f if you really want to add them.
+git-annex: user error (xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.largefiles=exclude=*.txt","add","--"] exited 123)
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> And it leaves the unstaged symlink behind too.
+> 
+> [[fixed|done]] to check ignore status before creating the file.
+> --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/return_--backend_for_addurl___63___.mdwn b/doc/projects/datalad/bugs-done/return_--backend_for_addurl___63___.mdwn
new file mode 100644
index 0000000000..c7b5351f94
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/return_--backend_for_addurl___63___.mdwn
@@ -0,0 +1,29 @@
+### Please describe the problem.
+
+Our 
+due to [10.20220624-27-gb223988e2](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=b223988e22931cf2243ae14289d22ef4e70e51f2) :
+
+```
+    remove --backend from global options
+    
+    --backend is no longer a global option, and is only accepted by commands
+    that actually need it.
+
+```
+
+well, our tests on OSX started to fail in 
+
+
+```shell
+2022-06-30T05:53:21.6356200Z E           datalad.runner.exception.CommandError: CommandError: 'git -c diff.ignoreSubmodules=none annex addurl --backend SHA1 --file=remotefile2 http://127.0.0.1:52474/remotefile --json --json-error-messages --json-progress -c annex.dotfiles=true' failed with exitcode 1 under /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/datalad_temp_tree_test_AnnexRepo_backend_optionhe08bgd0 [info keys: stdout_json] [err: 'Invalid option `--backend'
+
+```
+
+so we are not using it as a global option.  This functionality was already released in DataLad and I would appreciate if support for it was returned in git-annex so  we could avoid coming up with an alternative way to do the same thing.
+
+Sample logs could be found at https://github.com/datalad/git-annex/runs/7123868190?check_suite_focus=true or `/mnt/datasets/datalad/ci/git-annex/builds/2022/06/cron-20220630/build-macos.yaml-740-90215d4e-failed/1_test-datalad (master).txt` on smaug
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/running_tests_on_NFS_HOME_does_not_exit_cleanly__58___gpgtmp.mdwn b/doc/projects/datalad/bugs-done/running_tests_on_NFS_HOME_does_not_exit_cleanly__58___gpgtmp.mdwn
new file mode 100644
index 0000000000..2e509da524
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/running_tests_on_NFS_HOME_does_not_exit_cleanly__58___gpgtmp.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+
+I am establishing running daily tests on annex on NFS mounted partition (one run with NFS as TMPDIR -- passes, another with NFS for HOME).
+
+### What version of git-annex are you using? On what operating system?
+
+as of now  git-annex-standalone_8.20200810+git47-g27329f0bb-1~ndall+1_amd64.deb 
+
+### Please provide any additional information below.
+
+[full build/log](https://github.com/datalad/datalad-extensions/pull/29/checks?check_run_id=1024502537)
+
+[[!format sh """
+...
+All 840 tests passed (707.87s)
+.t/gpgtmp/7: removePathForcibly:removePathForcibly:removePathForcibly:removeDirectory: unsatisfied constraints (Directory not empty)
+sleeping 10 seconds and will retry directory cleanup
+git-annex: .t/gpgtmp/7/.nfs0000000000669ff400000a6b: removePathForcibly:removePathForcibly:removePathForcibly:removePathForcibly:removeLink: resource busy (Device or resource busy)
+##[error]Process completed with exit code 1.
+"""]]
+
+so it seems to relate to gpg, and not unlikely to be out of git-annex control, but I wondered if it could potentially be some non-clean termination of underlying gpg process or alike which could/should actually be addressed on git-annex side?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/running_tests_on_NFS_HOME_does_not_exit_cleanly__58___gpgtmp/comment_1_84a2d253843903f9811652b78d0fa7ba._comment b/doc/projects/datalad/bugs-done/running_tests_on_NFS_HOME_does_not_exit_cleanly__58___gpgtmp/comment_1_84a2d253843903f9811652b78d0fa7ba._comment
new file mode 100644
index 0000000000..6e9db4c855
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/running_tests_on_NFS_HOME_does_not_exit_cleanly__58___gpgtmp/comment_1_84a2d253843903f9811652b78d0fa7ba._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-08-28T17:17:07Z"
+ content="""
+This may depend on the version of gpg in use. With latest version, I see:
+
+	 374404 ?        Ss     0:00 gpg-agent --homedir /home/joey/src/git-annex/.t/tmprepo85/../gpgtmp/1 --use-standard-socket --daemon
+	 374411 ?        Ss     0:01 gpg-agent --homedir /home/joey/src/git-annex/.t/tmprepo85/../gpgtmp/2 --use-standard-socket --daemon
+
+12 of these build up by the end of the test suite. But here when the test suite
+exits, they all terminate.
+
+Presumably they have a deleted file they're holding open, which causes NFS to
+break in the ususal NFS way. Here they have an inotify handle, and some kind of
+socket. Based on the .nfs filename, which I think usually includes the name of
+the deleted file but here does not, I suspect it might be for the directory
+itself, and so due to the inotify handle.
+
+Ah, I think I see.. When I delete the directory, gpg-agent notices
+and exits.
+
+`gpgconf --kill all` can be used to stop them, so I've made the test
+suide do that after using gpg.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file.mdwn b/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file.mdwn
new file mode 100644
index 0000000000..6ddc034a71
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file.mdwn
@@ -0,0 +1,50 @@
+### Please describe the problem.
+
+spent quite some time trying to figure out WTF I got some files not published due to tag being set...  managed to reproduce in minimal setup -- if I set metadata to a file, rename a file (mv, git add;  or even git mv), and add another file with different content but the same name -- it would obtain metadata of original key/file (unless I commit right after rename)
+
+### What steps will reproduce the problem?
+
+see below
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170924+gitgd35053009-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> sudo rm -rf /tmp/repo; mkdir /tmp/repo; cd /tmp/repo; git init; git annex init; echo 1 >| 1; git annex add 1; git commit -m 'added 1'; git annex metadata -s tag=value 1; git mv 1 2; git annex add 2; echo 2>1; git annex add 1; for f in 1 2; do echo "file $f"; ls -l $f; git annex metadata -g tag $f; done                                                                                                                          
+Initialized empty Git repository in /tmp/repo/.git/
+init  ok
+(recording state in git...)
+add 1 ok
+(recording state in git...)
+[master (root-commit) 750d619] added 1
+ 1 file changed, 1 insertion(+)
+ create mode 120000 1
+metadata 1 
+  lastchanged=2017-09-26@17-59-22
+  tag=value
+  tag-lastchanged=2017-09-26@17-59-22
+ok
+(recording state in git...)
+
+add 1 ok
+(recording state in git...)
+file 1
+lrwxrwxrwx 1 yoh yoh 178 Sep 26 13:59 1 -> .git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+value
+file 2
+lrwxrwxrwx 1 yoh yoh 178 Sep 26 13:59 2 -> .git/annex/objects/2W/V5/SHA256E-s2--4355a46b19d348dc2f57c046f8ef63d4538ebb936000f3c9ee954a27460dd865/SHA256E-s2--4355a46b19d348dc2f57c046f8ef63d4538ebb936000f3c9ee954a27460dd865
+value
+
+"""]]
+
+you can see in above taht 1 and 2 have different content/keys, but they both acquire the same tag=value.  If I commit 2 after it being renamed from 1, it is ok.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[closing|done]] because I added a warning about the metadata copying, 
+> and that seems sufficient for users to understand why this happens.
+> --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_1_cd7043b66977b2a668bbd52f4d8e31ff._comment b/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_1_cd7043b66977b2a668bbd52f4d8e31ff._comment
new file mode 100644
index 0000000000..b4eef0dab8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_1_cd7043b66977b2a668bbd52f4d8e31ff._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-09-26T18:17:58Z"
+ content="""
+This is caused by an intentional feature. When `git annex add` is run
+on a modified file, the old metadata for the file (as committed to HEAD)
+is copied over. This prevents metadata being lost when modifying a file.
+
+The same would happen if the file were deleted and then new content added
+with the same filename. It seems like different things should be done in
+these cases, but the same thing can end up staged in several different
+cases, so the cases can't be distinguished.
+
+Committing the rename or deletion before adding a file back with the same
+name allows distinguishing from a modification of the file, and so that
+avoids the problem.
+
+I agree this led to confusing behavior here, but I'll bet it's also
+prevented confusing loss of metadata for people when editing a file..
+"""]]
diff --git a/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_2_e5b43f5733181fba9f79ae0035b354ef._comment b/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_2_e5b43f5733181fba9f79ae0035b354ef._comment
new file mode 100644
index 0000000000..7916814206
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_2_e5b43f5733181fba9f79ae0035b354ef._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-09-26T18:36:48Z"
+ content="""
+Other than the always-popular "make it configurable",
+I wonder if it would suffice to simply output a note when copying metadata
+from the (presumed) old version of the file? Then there would be no
+confusion about why the metadata got set.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_3_10d6135ad4b0c9706ff7b932323118d3._comment b/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_3_10d6135ad4b0c9706ff7b932323118d3._comment
new file mode 100644
index 0000000000..26d2ff01f3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_3_10d6135ad4b0c9706ff7b932323118d3._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-09-26T19:16:29Z"
+ content="""
+Hmm, if the file was not already in the index, that could be taken to
+indicate it was deleted/moved and replaced, rather than being modified,
+and so don't copy the metadata.
+
+But that would make these two sequences have different behavior:
+
+	git rm file; echo foo > file; git annex add file
+
+	echo foo > file; git annex add file
+
+As well as these two sequences:
+
+	git mv file other; echo foo > file; git annex add file
+
+	cp file other; echo foo > file; git annex add file other
+"""]]
diff --git a/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_4_fda77062452ac619a23298007bc0148a._comment b/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_4_fda77062452ac619a23298007bc0148a._comment
new file mode 100644
index 0000000000..7e79c4ca16
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_4_fda77062452ac619a23298007bc0148a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2017-09-27T05:30:52Z"
+ content="""
+Thanks for the analysis/explaining.  My POV, I somewhat got used to the notion \"git annex cares about content/keys, and files are mere pointers\".  That is easy to explain, in particular why two files pointing to the same key would have the same meta-data. So I assumed that no meta-data would be copied over to the new content/key.  But I now do see how retaining the meta-data could be useful, e.g. if I unlock/modify/add a file where meta-data should be carried over (e.g. for music could be all the author/album/etc)... But if file was not unlocked, then may be such \"copying\" shouldn't happen?  not sure  what to suggest otherwise :-/.
+
+In my specific case in one case (newly assigned meta-data) I could simply workaround by first renaming and then assigning meta-data to the renamed file, but in the other (if meta-data is already assigned for the key), I would need to explicitly reset it then but it seems can't do it without committing since that \"copy metadata for the filename\" happens upon committing... so not sure on how to workaround without explicitly removing it from those files after committing... heh
+"""]]
diff --git a/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_5_fa6d5d0afdc00824da0e04d9bf23d6f4._comment b/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_5_fa6d5d0afdc00824da0e04d9bf23d6f4._comment
new file mode 100644
index 0000000000..2f7c8479ef
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_5_fa6d5d0afdc00824da0e04d9bf23d6f4._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-09-28T16:03:28Z"
+ content="""
+Files are not unlocked before modifying in direct mode, and may be
+unlocked all the time in v6 mode. Also, in indirect mode it's of course
+fine to overwrite the symlink with a new version of a file. So detecting 
+if it's been unlocked doesn't seem to help with this.
+
+It may be that there are different sorts of metadata, some of which should
+be inherited by new versions of a file, and others not. If there was a way
+to tell git-annex which metadata was which, it could do the right thing.
+But it feels like stacking complications. Particularly since there might be
+some tags that should be inherited and others not, and tags are values..
+
+In the meantime, I've added the warning when it copies metadata. 
+I also added `git annex metadata --remove-all`, which the warning
+suggests running if you don't want the copied metadata.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__.mdwn b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__.mdwn
new file mode 100644
index 0000000000..b0146468f3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__.mdwn
@@ -0,0 +1,32 @@
+### Please describe the problem.
+
+Not sure how I have missed this issue for a while, since now I have tried with almost year old 6.20170101-1+b1 -- the same story as with 6.20171003-g14ffdd779
+
+I expect those files to be readable according to the 'shared' setting but definitely not writeable!
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> sudo rm -rf tttt; mkdir tttt; ( cd tttt; git init --shared .; git annex init ; echo 123 >123; git annex add 123; git commit -m 'added 123'; ls -lL 123; ) 
+Initialized empty shared Git repository in /tmp/tttt/.git/
+init  ok
+(recording state in git...)
+add 123 ok
+(recording state in git...)
+[master (root-commit) b137ea6] added 123
+ 1 file changed, 1 insertion(+)
+ create mode 120000 123
+-rw-rw---- 1 yoh yoh 4 Oct 10 12:59 123
+
+$> echo 11 >> tttt/123
+# no error code
+"""]]
+
+FWIW my umask is 077 but originally discovered on a system with umask 0002
+
+I guess I need to annex fsck tons of repositories now :-/
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] in git-annex v10. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_10_2e61ccc41839b8da70ad26d31e40ad74._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_10_2e61ccc41839b8da70ad26d31e40ad74._comment
new file mode 100644
index 0000000000..95809e9d9b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_10_2e61ccc41839b8da70ad26d31e40ad74._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2022-01-12T19:14:10Z"
+ content="""
+This would almost work:
+
+Continue taking a shared lock of the content
+file when locking to prevent dropping. That does not need write access,
+only an exclusive lock does, so the content file can have its write bit
+removed. Also lock the new lock file, with a shared lock to prevent
+dropping, or an exclusive when dropping.
+
+The old git-annex version, when dropping, will fail to exclusively lock the
+content file, either because it's not writable, or because of a shared
+lock intended to prevent dropping. So a git-annex drop that was in progress
+may start to fail, but it will not lose any data.
+
+Problem: The old git-annex version, when locking to prevent dropping
+(eg git-annex move --from remote),
+will take the shared lock of the content file. If the new git-annex version
+is locking to drop, it will also take the shared lock of the content file,
+followed by the exlusive lock of the new lock file. So the old git-annex will
+not be able to prevent the new git-annex from dropping.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_11_e9af4784ffb84b49b6faaa21aa7c8efc._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_11_e9af4784ffb84b49b6faaa21aa7c8efc._comment
new file mode 100644
index 0000000000..6e11790e16
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_11_e9af4784ffb84b49b6faaa21aa7c8efc._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2022-01-12T19:40:35Z"
+ content="""
+This is going to need two repository version bumps:
+
+v9:  Add the upgrade lock file, and all git-annex processes take a shared
+lock to avoid the repository being upgraded out from under them.
+
+v10: Skipped until the upgrade lock file is of a certain age. Take upgrade
+lock before upgrading.
+
+In v10, stop locking content files and lock separate lock files.
+
+The age could be eg 1 month, which assumes that no pre-v9 git-annex
+process like `git-annex move --to remote` is still running after that long.
+Of course, that is still an assumption, but it can be pushed out as long as
+it takes to feel comfortable with it. Maybe 1 year? The only disadvantage
+really is that any v11 upgrade would also get deferred.
+
+Since the assistant can possibly run for longer than a year without
+restarting, the v10 upgrade would need to be skipped when the assistant is
+running.
+
+`git-annex upgrade --version=10` could be available to speed up that
+upgrade. The user would be responsible for making sure there are no such
+old git-annex processes running, so that might need --force.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_12_fc10e403f35f47a6c4464f3f68d01eca._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_12_fc10e403f35f47a6c4464f3f68d01eca._comment
new file mode 100644
index 0000000000..b70278a8db
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_12_fc10e403f35f47a6c4464f3f68d01eca._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2022-01-19T19:55:10Z"
+ content="""
+What kind of locking is needed for the v10 upgrade? Everything else is in
+place now, but the actual locking is TBD.
+
+My plan above calls for a way to detect if another git-annex process
+(v9 or above) is running in the repo. That will be hard to implement
+though.. 
+
+It might cause problems with annex.pidlock, if every git-annex
+process starts taking a shared lock, because pidlock does not support
+shared locks, so only 1 git-annex process will be able to run, perhaps in
+situations where multiples can run now even with pidlocking because no
+locking is needed.
+
+Also, the existing locking machinery runs in the Annex monad, but such a
+lock needs to be implemented in Annex.hs itself, so that would be a
+recursive dep. And, it would add overhead to every git-annex process.
+(A small amount.)
+
+Alternatively, there could be a top-level lock file that is held shared
+whenever locking content files. And the v10 upgrade takes an exclusive
+lock. But this seems to fail when a v9 process is running -- if it blocks
+on the shared lock for the v10 upgrade, it would still go on the lock in v9
+mode in the now v10 repository.
+
+Update: That problem can be avoided by re-reading the git config
+to check if v10 was enabled, once it has taken the shared lock.
+That will mean that v9 repos do a little bit more work when locking content
+and dropping. For efficiency, use an InodeCache and only re-read when it's changed.
+This will need the v10 upgrade to set annex.version while it is still
+holding the exclusive lock.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_13_43a09de767ed9060dd91d6eca5e0b3a3._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_13_43a09de767ed9060dd91d6eca5e0b3a3._comment
new file mode 100644
index 0000000000..5c5d08ccf7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_13_43a09de767ed9060dd91d6eca5e0b3a3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2022-01-21T16:59:49Z"
+ content="""
+v10 is implemented, so upgrade your affected repositories to it to get the
+fix.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_1_df04a6bd62a60789d8a59cce4b62728e._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_1_df04a6bd62a60789d8a59cce4b62728e._comment
new file mode 100644
index 0000000000..b6fd7150fd
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_1_df04a6bd62a60789d8a59cce4b62728e._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="annex fsck reverts them back to incorrect!"
+ date="2017-10-10T17:17:12Z"
+ content="""
+even if I fix them, and then rerun 'annex fsck' to verify that I am 'ok' -- it would revert to the bad state:
+
+[[!format sh \"\"\"
+$ find -ipath '*.git/annex/objects' | while read d; do chmod a-w -R $d/*/*/*; done
+ls -ld ./.git/annex/objects/Kj/ZJ/MD5E-s3500--157855c754113321d3f6621abe0fe71d.tsv
+dr-xr-sr-x 2 bids bids 3 Oct  3 08:36 ./.git/annex/objects/Kj/ZJ/MD5E-s3500--157855c754113321d3f6621abe0fe71d.tsv
+
+$ git annex fsck >/dev/null
+
+$ ls -ld ./.git/annex/objects/Kj/ZJ/MD5E-s3500--157855c754113321d3f6621abe0fe71d.tsv
+drwxrwsr-x 2 bids bids 3 Oct  3 08:36 ./.git/annex/objects/Kj/ZJ/MD5E-s3500--157855c754113321d3f6621abe0fe71d.tsv
+
+$ ls -ld ./.git/annex/objects/Kj/ZJ/MD5E-s3500--157855c754113321d3f6621abe0fe71d.tsv/*
+-rw-rw-rw- 1 bids bids 3500 Oct  3 07:57 ./.git/annex/objects/Kj/ZJ/MD5E-s3500--157855c754113321d3f6621abe0fe71d.tsv/MD5E-s3500--157855c754113321d3f6621abe0fe71d.tsv
+\"\"\"]]
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_2_0619eec44cddf3d3b1aae27c7bd1389a._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_2_0619eec44cddf3d3b1aae27c7bd1389a._comment
new file mode 100644
index 0000000000..5ee888e6a8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_2_0619eec44cddf3d3b1aae27c7bd1389a._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-10-10T17:23:14Z"
+ content="""
+The write bit is necessary so that the files can be opened in write mode to
+lock them. Normally the write bit is temporarily enabled and then disabled
+for locking, but in a shared repository, some other user may own the file,
+which prevents the user from changing its permissions.
+
+Similarly, the parent directory is not made unwritable in a shared
+repository, because other users won't be able to temporarily flip the write
+bit on when making changes.
+
+[[!commit 0d432dd1a4f718225c4192d0834a4e0a34b3e4bd]] used the latter as a
+rationalle to allow the former.
+
+I suppose it could use separate lock files from the content file, 
+as is already done in direct mode. However interaction between different
+versions of git-annex with different ideas about locking could result in
+`git annex drop` losing data.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_3_aae8dd8b3b0ce4647ec2d30e1d682339._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_3_aae8dd8b3b0ce4647ec2d30e1d682339._comment
new file mode 100644
index 0000000000..9450cbc496
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_3_aae8dd8b3b0ce4647ec2d30e1d682339._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2017-10-10T17:40:08Z"
+ content="""
+Found a following comment in the code
+[[!format haskell \"\"\"
+{- Normally, blocks writing to an annexed file, and modifies file
+ - permissions to allow reading it.
+ -
+ - When core.sharedRepository is set, the write bits are not removed from
+ - the file, but instead the appropriate group write bits are set. This is
+ - necessary to let other users in the group lock the file. But, in a
+ - shared repository, the current user may not be able to change a file
+ - owned by another user, so failure to set this mode is ignored.
+ -}
+\"\"\"]]
+So may be it is a \"Feature\" although killing the whole premise of data safety while using git-annex.
+
+In my case, shared permissions are primarily to make files/repositories readable by others, so may be I should have not used 'shared' mode anyways, since reading does not need the shared setting
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_4_c72e6646e39cc487ea52cd17925a548f._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_4_c72e6646e39cc487ea52cd17925a548f._comment
new file mode 100644
index 0000000000..8e7b2ec6a9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_4_c72e6646e39cc487ea52cd17925a548f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2017-10-10T17:56:47Z"
+ content="""
+our comments crossed in the hyperspace... ;)  yeah -- I would have expected a separate lock file to be used for such cases.  Now data loss is really a possibility (almost made it happen since opened the file and wrote it without unlocking, good that I caught it and was able to modify back exactly the way it was).  Interactions among multiple versions of annex on the same repo is imho a lesser possibility (would require two different versions of annex being available)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_5_d8c8b725ee91a899a131bf505bd9a2e3._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_5_d8c8b725ee91a899a131bf505bd9a2e3._comment
new file mode 100644
index 0000000000..05ef7377a8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_5_d8c8b725ee91a899a131bf505bd9a2e3._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-10-11T15:59:16Z"
+ content="""
+It's easy to have multiple versions of git-annex installed. Especially
+when a repository is shared amoung users, who may install different
+versions for their own reasons.
+
+I am not happy either about this weakening of safety guarantees that indirect
+mode repositories otherwise have. It seems at least worth a big fat
+warning.
+
+I don't feel comfortable changing locking without a major repository
+version change, which would be a Big Deal.
+
+Anyhow the file mode and directory mode are both needed to protect annexed
+files. Making the file read-only will not prevent a lot of things
+renaming over top of it. (Including vim!)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_6_d0d8065b78c22e62ef780c27e4d5952c._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_6_d0d8065b78c22e62ef780c27e4d5952c._comment
new file mode 100644
index 0000000000..b2958d0c0f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_6_d0d8065b78c22e62ef780c27e4d5952c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2017-12-05T18:20:41Z"
+ content="""
+> Making the file read-only will not prevent a lot of things renaming over top of it. (Including vim!)
+
+not exactly... removing write permission from the key file at least makes vim report that the file read-only and disallowing (without force) to overwrite it.  That is my use case where I keep burning myself constantly (e.g. this morning again).  Need to not forget to switch all \"shared\" repos back to the single user mode.  One of the promises of git-annex is that data is safe, and this mode just violates it wildly. 
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_7_a82064795fdbdb0187763aeee4a308ff._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_7_a82064795fdbdb0187763aeee4a308ff._comment
new file mode 100644
index 0000000000..add0385dd2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_7_a82064795fdbdb0187763aeee4a308ff._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-10-12T17:40:51Z"
+ content="""
+I've opened [[todo/v9_changes]] and this can be taken care of if/when a v9
+happens. It's unfortunate I didn't think of this bug when doing v8, so
+hopefully that new todo will remind me about it for v9.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_8_c3d447a8f4e63f6a28a02ccb4eed1ad4._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_8_c3d447a8f4e63f6a28a02ccb4eed1ad4._comment
new file mode 100644
index 0000000000..de67df2e7c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_8_c3d447a8f4e63f6a28a02ccb4eed1ad4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-01-11T18:48:15Z"
+ content="""
+This is being implemented in the `v9-locking` branch,
+which will only get merged when v9 happens, whenever that is.
+See [[todo/v9_changes]].
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_9_f74642e1dfc4e533b9582e5a13a16898._comment b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_9_f74642e1dfc4e533b9582e5a13a16898._comment
new file mode 100644
index 0000000000..f72e43dfe8
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_9_f74642e1dfc4e533b9582e5a13a16898._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-01-12T16:29:40Z"
+ content="""
+While this is mostly implemented in the branch, the upgrade to it has a
+serious danger point.
+
+If a long-running git-annex process, eg a large drop, is running during the
+upgrade, then it will keep on using the current locking method. Meanwhile,
+other processes run after the upgrade will use the new locking method. So
+this could cause data loss: Old git-annex locks a file to drop it, and at
+the same time new git-annex-shell is used to lock the same file, to prevent
+it from being dropped.
+
+Avoiding that seems to require a way to make sure there are no running
+git-annex processes when performing a repository upgrade. (Which would be
+nice in general but has somehow not been necessary until now.)
+
+One way to do it would be to have a shared lock file that all git-annex
+processes hold while they are running. And upgrade takes an exclusive lock.
+That locking would need to be implemented first and somehow be known
+that any git-annex process that is running is using it, before performing
+the repository upgrade. Ideally without taking years in between to wait
+for all git-annex binaries to be upgraded.
+
+I suppose that git-annex v9 could ship with that added lock file, and not
+upgrade the repository to v9 immediately. Instead, stat the lock file, and
+only when its ctime is sufficiently old that it seems safe to assume any
+running git-annex process would be using it, do the repository upgrade. Eg
+after 3 months or so or perhaps when the ctime is older than the last
+reboot. But this would not avoid problems if an older git-annex
+version was also used in the same repository as the new version.
+
+Or git-annex upgrade could hunt for other running git-annex processes that
+are using the repository and refuse to perform the v9 upgrade. But that is
+hard because a processes's cwd is not necessarily inside the repository
+it's using (eg a remote). It would have to look for git child processes
+of git-annex processes that are using the repository, such as git cat-file.
+Also network filesystems would be a problem.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/should_not_assume_entire_name_to_be_an_extension__63__.mdwn b/doc/projects/datalad/bugs-done/should_not_assume_entire_name_to_be_an_extension__63__.mdwn
new file mode 100644
index 0000000000..0dd0355d8f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/should_not_assume_entire_name_to_be_an_extension__63__.mdwn
@@ -0,0 +1,63 @@
+### Please describe the problem.
+
+I guess it might be argued against, but I just spotted getting 
+```
+lrwxrwxrwx 1 yoh yoh   186 Aug  2 12:44 .dot -> .git/annex/objects/k4/g9/SHA256E-s4--5ddbce254c08372e429a250112c6f4593868687ab01e9a126193e5a83560362b.dot/SHA256E-s4--5ddbce254c08372e429a250112c6f4593868687ab01e9a126193e5a83560362b.dot
+```
+
+so the entire filename of `.dot` upon `add --force-large` was considered to be an extension.  I think it might be worthwhile to not consider leading `.` as belonging to extension?
+
+checking on how we treat that case in datalad [in split_ext](https://github.com/datalad/datalad/blob/master/datalad/support/path.py#L84) -- apparently we are consistent with git-annex here:
+
+```
+$> python -c 'from datalad.support.path import split_ext; print(split_ext(".dot"))'
+('', '.dot')
+```
+
+and we do not test for this case in tests, so not clear if omission was "conscious"
+ 
+### What steps will reproduce the problem?
+
+<details>
+<summary>spotted on following "toy script" while exploring `drop --excludesamecontent=glob` functionality</summary> 
+
+```bash
+#!/bin/bash
+
+export PS4='> '
+set -eu
+cd "$(mktemp -d ${TMPDIR:-/tmp}/ann-XXXXXXX)"
+
+set -x
+
+git init 
+git annex init
+
+mkdir -p d{1,2,3}
+echo dot > .dot
+echo 123 > d1/f1
+cp .dot d1/same-as-dot
+echo 124 > d1/unique
+cp d1/f1 d2/same-as-in-d1
+echo 125 > d2/unique
+
+git annex add --force-large * .dot 
+git commit -m 'all initial' -a
+
+git status
+git annex list
+git annex drop --force '--excludesamecontent=*' '--excludesamecontent=.*' d1
+git annex list
+
+```
+</details>
+
+### What version of git-annex are you using? On what operating system?
+
+8.20210714+git68-g645b045e0-1~ndall+1
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/shouldn__39__t_keep_permissions_of_the_ssh_remote__63__.mdwn b/doc/projects/datalad/bugs-done/shouldn__39__t_keep_permissions_of_the_ssh_remote__63__.mdwn
new file mode 100644
index 0000000000..de41ac05e0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shouldn__39__t_keep_permissions_of_the_ssh_remote__63__.mdwn
@@ -0,0 +1,15 @@
+### Please describe the problem.
+
+Initially generated an annex while having a restrictive umask 077.  Then cloned that repository to another host for public consumption so directory had proper/good permissions set allowing group to access.  And everything is accessible but not the load which I 'annex get'ed.  Key directories were readable but not the content.  I guess there is somewhere 'preserve permissions' setting for rsync/scp which imho shouldn't be there and content should inherit local/environment settings
+
+### What version of git-annex are you using? On what operating system?
+
+6.20160208+gitg1ac9034-1~ndall+1
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> I'm going to close this. Mostly because rsync is no longer used for ssh
+> transfers and so file perms are not preserved, unless git-annex is
+> talking to a very old git-annex-shell. Also because not enough
+> information is known about the repo setup back then. [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/shouldn__39__t_keep_permissions_of_the_ssh_remote__63__/comment_1_35eeb15c0031c18ba6d0922bb7ae8ed3._comment b/doc/projects/datalad/bugs-done/shouldn__39__t_keep_permissions_of_the_ssh_remote__63__/comment_1_35eeb15c0031c18ba6d0922bb7ae8ed3._comment
new file mode 100644
index 0000000000..33047adf9f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shouldn__39__t_keep_permissions_of_the_ssh_remote__63__/comment_1_35eeb15c0031c18ba6d0922bb7ae8ed3._comment
@@ -0,0 +1,89 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-14T20:43:05Z"
+ content="""
+umask 077 means a file will be mode 400. The 400 mode is indeed retained
+when that object is transferred to another repository.
+
+git-annex does make sure that the file can be read by the current user.
+Which mode 400 does allow.
+
+Did your problem involve some other user needing to read the file? 
+If you configure core.sharedrepository group or world, then git-annex
+will adjust the mode of the received object to let the group or everyone
+read it.
+
+----
+
+The simplest way to make it use the umask would be this patch. But,
+with this patch, if I have a file that's mode 664 and my umask is 077, git
+annex add will change the file mode to 600.
+So, I don't like this patch; its impact is too broad.
+
+    diff --git a/Annex/Perms.hs b/Annex/Perms.hs
+    index 6444025..9b35bb8 100644
+    --- a/Annex/Perms.hs
+    +++ b/Annex/Perms.hs
+    @@ -5,6 +5,8 @@
+      - Licensed under the GNU GPL version 3 or higher.
+      -}
+     
+    +{-# LANGUAGE CPP #-}
+    +
+     module Annex.Perms (
+     	setAnnexFilePerm,
+     	setAnnexDirPerm,
+    @@ -28,6 +30,10 @@ import Git.SharedRepository
+     import qualified Annex
+     import Config
+     
+    +#ifndef mingw32_HOST_OS
+    +import Data.Bits
+    +#endif
+    +
+     withShared :: (SharedRepository -> Annex a) -> Annex a
+     withShared a = a =<< coreSharedRepository <$> Annex.getGitConfig
+     
+    @@ -82,7 +88,7 @@ createAnnexDirectory dir = walk dir [] =<< top
+     			setAnnexDirPerm p
+     
+     {- Normally, blocks writing to an annexed file, and modifies file
+    - - permissions to allow reading it.
+    + - permissions to not allow writing it and otherwise reflect the umask.
+      -
+      - When core.sharedRepository is set, the write bits are not removed from
+      - the file, but instead the appropriate group write bits are set. This is
+    @@ -98,9 +104,18 @@ freezeContent file = unlessM crippledFileSystem $
+     		addModes [ownerReadMode, groupReadMode, ownerWriteMode, groupWriteMode]
+     	go AllShared = liftIO $ void $ tryIO $ modifyFileMode file $
+     		addModes (readModes ++ writeModes)
+    -	go _ = liftIO $ modifyFileMode file $
+    -		removeModes writeModes .
+    -		addModes [ownerReadMode]
+    +#ifndef mingw32_HOST_OS
+    +	go _ = liftIO $ bracket
+    +		(liftIO $ setFileCreationMask 0o22) -- set umask to get it
+    +		(liftIO . setFileCreationMask) 
+    +		$ \umask -> modifyFileMode file $
+    +			removeModes writeModes .
+    +			(\mode -> mode .&. complement umask)
+    +#else
+    +	go _ = liftIO $ modifyFileMode file $ 
+    +			removeModes writeModes .
+    +			addModes [ ownerReadMode ]
+    +#endif
+     
+     isContentWritePermOk :: FilePath -> Annex Bool
+     isContentWritePermOk file = ifM crippledFileSystem
+
+The umask-based mode setting could be put into every remote
+that uses a transfer method that preserves permissions. (Including the
+external special remote I suppose, since it *might* do so.) Or put in
+`gitViaTmp` but there are a few places `getViaTmp` is used that do not
+involve transfers from remotes.
+
+Also this would add the overhead of umask()+stat()+chmod()+umask()
+to every file downloaded by git-annex, on top of the chmodding it already
+does.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/shouldn__39__t_keep_permissions_of_the_ssh_remote__63__/comment_2_65232a9c2bbba075d325ce00b7c5e13f._comment b/doc/projects/datalad/bugs-done/shouldn__39__t_keep_permissions_of_the_ssh_remote__63__/comment_2_65232a9c2bbba075d325ce00b7c5e13f._comment
new file mode 100644
index 0000000000..7de7adc48c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/shouldn__39__t_keep_permissions_of_the_ssh_remote__63__/comment_2_65232a9c2bbba075d325ce00b7c5e13f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 2"
+ date="2016-04-18T14:16:31Z"
+ content="""
+heh -- it has been awhile and damn me didn't reveal originally the location of such a repository so I could not check if I set group settings for the repo \"correctly\"... don't know now -- would need to replicate at some point and follow up
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal.mdwn b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal.mdwn
new file mode 100644
index 0000000000..a0ea3823ae
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal.mdwn
@@ -0,0 +1,19 @@
+### Please describe the problem.
+
+With recent RFing of scanning for unlocked/annexed files (I guess), a sweep of datalad tests on OSX started to take about 3h 30min instead of prior 1h 46min. So pretty much twice. Besides possibly affecting user experience, I am afraid that would cause too much ripples though our CI setup which might not run out of time
+
+Logs etc are at https://github.com/datalad/git-annex/actions/workflows/build-macos.yaml 
+
+The first red is ok, just a fluke but then they all fail due to change in output log string (for which there is a fix but somehow behavior on osx seems different, yet to check).
+ 
+
+
+
+### What version of git-annex are you using? On what operating system?
+
+Currently 8.20210428+git282-gd39dfed2a and first got slow with 
+8.20210428+git228-g13a6bfff4 and was ok with 8.20210428+git202-g9a5981a15
+
+[[!meta title="performance edge case when adding large numbers of identical files"]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_10_37d5186dfa2da31526c4eafbbbfdbc33._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_10_37d5186dfa2da31526c4eafbbbfdbc33._comment
new file mode 100644
index 0000000000..dddce7ad18
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_10_37d5186dfa2da31526c4eafbbbfdbc33._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="slow down is OSX specific"
+ date="2021-06-08T14:28:18Z"
+ content="""
+Thank you Joey for all the OPTs. 
+Looking at it again: the significant impact seems to be OSX builds specific: Linux and Windows builds did get just a bit slower (if at all).  So may be situation is not that dire ;-)  Two possibilities:
+
+- Even though coincidences like this are unlikely, it is possible that OSX VMs on Github actions got slower? 
+- may be the RFing is somehow effecting OSX specifically?
+
+I will try to do some timings locally.  Also I should finally get those logs (and built packages) into some more convenient form using [tinuous](https://github.com/con/tinuous/) John has been developing -- would allow for easy greps instead of all these jumping through CIs etc.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_11_51a3a86a290b0e3994507f3f64e7c72a._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_11_51a3a86a290b0e3994507f3f64e7c72a._comment
new file mode 100644
index 0000000000..b9d18337d6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_11_51a3a86a290b0e3994507f3f64e7c72a._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2021-06-08T15:41:23Z"
+ content="""
+I can't think of anything OSX specific in the recent changes.
+
+I have added debugging of when reconcileStaged wakes up and possibly
+wastes some time, eg:
+
+	joey@darkstar:~/tmp/big> git config annex.debug true
+	joey@darkstar:~/tmp/big> git config annex.debugfilter Database.Keys
+	joey@darkstar:~/tmp/big> git-annex init
+	init  
+	[2021-06-08 11:52:11.854202926] (Database.Keys) reconcileStaged start
+	(scanning for annexed files...)
+	[2021-06-08 11:52:44.092620256] (Database.Keys) reconcileStaged end
+	ok
+
+All the new work happens in between those two debugs[1], so you could check if
+the time sink is there or elsewhere.
+
+(Note that the last release takes 2 seconds longer for that init than
+it does now..)
+
+[1] With the exception of a single call to `git write-tree`, but that
+should be very fast.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_12_c841c9db2000c65c56ce8e26e58a3f62._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_12_c841c9db2000c65c56ce8e26e58a3f62._comment
new file mode 100644
index 0000000000..4d84790533
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_12_c841c9db2000c65c56ce8e26e58a3f62._comment
@@ -0,0 +1,153 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="all recent builds/logs are fetched to smaug"
+ date="2021-06-08T16:50:11Z"
+ content="""
+Finished fetching all the builds (logs + artifacts, i.e. built installers and packages) to smaug.  FWIW `joey` user on smaug should be able to access them at /mnt/datasets/datalad/ci/git-annex as well (it is all git/git-annex with submodules happen you want to get a \"clone\" ;))
+
+<details>
+<summary>grep confirms timing for datalad testson OSX</summary> 
+
+```shell
+(tinuous-dev) datalad@smaug:/mnt/datasets/datalad/ci/git-annex$ grep -h -i 'Ran .*tests in' builds/2021/0[56]/*/cron-*/*/*macOS*/*_test-datalad\ \(master\).txt
+2021-05-01T05:47:43.6623300Z Ran 1269 tests in 10381.041s
+2021-05-02T04:27:47.4468150Z Ran 1269 tests in 5835.199s
+2021-05-03T04:25:06.4741780Z Ran 1269 tests in 5817.953s
+2021-05-04T04:26:25.2725400Z Ran 1269 tests in 5925.938s
+2021-05-05T04:15:45.7241110Z Ran 1270 tests in 6003.093s
+2021-05-06T04:14:18.9203140Z Ran 1270 tests in 5821.084s
+2021-05-07T04:19:12.5257430Z Ran 1270 tests in 5887.912s
+2021-05-08T04:17:21.4790320Z Ran 1270 tests in 5775.691s
+2021-05-09T04:20:53.2085730Z Ran 1270 tests in 5961.437s
+2021-05-10T04:21:52.2492300Z Ran 1270 tests in 5698.905s
+2021-05-11T04:28:39.1451570Z Ran 1270 tests in 5899.918s
+2021-05-12T04:28:26.6181110Z Ran 1270 tests in 5964.851s
+2021-05-13T04:30:47.2978230Z Ran 1277 tests in 5938.297s
+2021-05-14T04:37:51.3172970Z Ran 1277 tests in 5921.571s
+2021-05-15T04:31:29.6466840Z Ran 1277 tests in 6060.762s
+2021-05-16T04:33:26.5552670Z Ran 1277 tests in 5789.405s
+2021-05-17T04:36:52.4460760Z Ran 1277 tests in 5855.382s
+2021-05-18T04:37:24.5613580Z Ran 1278 tests in 6007.685s
+2021-05-19T04:34:37.3253830Z Ran 1279 tests in 5940.204s
+2021-05-20T04:36:10.3184010Z Ran 1280 tests in 5941.388s
+2021-05-21T04:41:10.2664330Z Ran 1280 tests in 6218.775s
+2021-05-22T04:40:39.2754540Z Ran 1289 tests in 5884.267s
+2021-05-23T04:37:51.5005200Z Ran 1289 tests in 5750.672s
+2021-05-24T04:38:24.5894000Z Ran 1289 tests in 5911.655s
+2021-05-25T04:51:35.2189100Z Ran 1289 tests in 6266.836s
+2021-05-26T06:56:33.6660300Z Ran 1293 tests in 12584.992s
+2021-05-27T07:08:27.4015580Z Ran 1293 tests in 11901.552s
+2021-05-28T07:39:17.3481450Z Ran 1292 tests in 12094.343s
+2021-05-29T08:05:14.3586440Z Ran 1294 tests in 12205.434s
+2021-05-30T08:09:33.0780990Z Ran 1294 tests in 12028.089s
+2021-05-31T08:16:36.3910830Z Ran 1294 tests in 12329.455s
+2021-06-01T08:42:24.3167200Z Ran 1294 tests in 12115.378s
+2021-06-02T08:42:23.1985610Z Ran 1294 tests in 12432.309s
+2021-06-03T08:00:08.2576030Z Ran 1294 tests in 11556.974s
+2021-06-04T07:25:39.1674160Z Ran 1294 tests in 11946.195s
+2021-06-05T07:14:00.5262620Z Ran 1294 tests in 12456.432s
+2021-06-06T06:53:14.7001370Z Ran 1294 tests in 11677.647s
+2021-06-07T07:12:57.5076610Z Ran 1294 tests in 12042.332s
+2021-06-08T06:48:01.3977250Z Ran 1294 tests in 12126.463
+```
+
+Interestingly the top one is in 10k,  but prior ones were ok
+
+```shell
+(tinuous-dev) datalad@smaug:/mnt/datasets/datalad/ci/git-annex$ grep -h -i 'Ran .*tests in' builds/2021/04/*/cron-*/*/*macOS*/*_test-datalad\ \(master\).txt
+2021-04-27T03:58:30.4829510Z Ran 1265 tests in 6312.819s
+2021-04-28T03:44:23.1655040Z Ran 1265 tests in 5622.562s
+2021-04-29T03:50:14.0670840Z Ran 1269 tests in 6196.774s
+2021-04-30T04:21:45.1727310Z Ran 1269 tests in 5879.034s
+```
+</details>
+
+<details>
+<summary>and absence of the drastic effect confirmed for linux and windows</summary> 
+
+```shell
+(tinuous-dev) datalad@smaug:/mnt/datasets/datalad/ci/git-annex$ grep -h -i 'Ran .*tests in' builds/2021/0[56]/*/cron-*/*/*buntu*/*_test-datalad\ \(master\).txt
+2021-05-01T04:16:34.1539917Z Ran 1269 tests in 3999.905s
+2021-05-02T04:17:04.5604428Z Ran 1269 tests in 3745.951s
+2021-05-03T04:22:46.1508135Z Ran 1269 tests in 4133.703s
+2021-05-04T04:22:19.3612212Z Ran 1269 tests in 4341.995s
+2021-05-05T04:23:04.3327570Z Ran 1270 tests in 4383.268s
+2021-05-06T04:07:33.2967674Z Ran 1270 tests in 3457.688s
+2021-05-07T04:18:26.7140893Z Ran 1270 tests in 3778.162s
+2021-05-08T04:13:13.9041377Z Ran 1270 tests in 3728.503s
+2021-05-09T04:16:59.6844666Z Ran 1270 tests in 3898.714s
+2021-05-11T04:21:45.5447035Z Ran 1270 tests in 4032.457s
+2021-05-12T04:20:48.6349049Z Ran 1270 tests in 3940.342s
+2021-05-13T04:26:53.8376010Z Ran 1277 tests in 4130.863s
+2021-05-14T04:37:41.5689917Z Ran 1277 tests in 4476.880s
+2021-05-15T04:20:12.0126613Z Ran 1277 tests in 4007.927s
+2021-05-16T04:30:50.0329536Z Ran 1277 tests in 4077.010s
+2021-05-17T04:25:03.3302428Z Ran 1277 tests in 4034.791s
+2021-05-18T04:33:23.5513354Z Ran 1278 tests in 4422.760s
+2021-05-19T04:19:47.5664435Z Ran 1279 tests in 3910.031s
+2021-05-20T04:13:45.4617209Z Ran 1280 tests in 3508.342s
+2021-05-21T04:23:56.1103373Z Ran 1280 tests in 3946.563s
+2021-05-22T04:30:52.1649178Z Ran 1289 tests in 4406.863s
+2021-05-23T04:35:53.5526207Z Ran 1289 tests in 3818.054s
+2021-05-24T04:33:44.9770098Z Ran 1289 tests in 4069.751s
+2021-05-25T04:38:28.6369074Z Ran 1289 tests in 3809.039s
+2021-05-26T05:16:56.6913239Z Ran 1293 tests in 4340.973s
+2021-05-27T05:21:33.5230620Z Ran 1293 tests in 4303.062s
+2021-05-28T05:44:02.6763227Z Ran 1292 tests in 4013.921s
+2021-05-29T06:05:40.8639499Z Ran 1294 tests in 3581.055s
+2021-05-30T06:17:23.4265104Z Ran 1294 tests in 4257.736s
+2021-05-31T06:36:09.6446865Z Ran 1294 tests in 4782.606s
+2021-06-01T06:57:26.6049829Z Ran 1294 tests in 4391.030s
+2021-06-02T06:59:17.8345547Z Ran 1294 tests in 4737.580s
+2021-06-03T06:10:51.5533496Z Ran 1294 tests in 3453.557s
+2021-06-04T05:44:15.7873867Z Ran 1294 tests in 4113.770s
+2021-06-05T05:25:15.5789949Z Ran 1294 tests in 4383.014s
+2021-06-06T05:20:48.7371175Z Ran 1294 tests in 4386.210s
+2021-06-07T05:33:24.8643085Z Ran 1294 tests in 4303.855s
+2021-06-08T05:03:38.3420188Z Ran 1294 tests in 4371.387s
+```
+
+```shell
+(tinuous-dev) datalad@smaug:/mnt/datasets/datalad/ci/git-annex$ grep -h -i 'Ran .*tests in' builds/2021/0[56]/*/cron-*/*/*indows*/*_test-datalad\ \(master\).txt
+2021-05-01T05:29:21.7469495Z Ran 1250 tests in 4904.324s
+2021-05-02T05:33:35.7321469Z Ran 1250 tests in 4835.792s
+2021-05-03T05:32:36.9342468Z Ran 1250 tests in 5040.210s
+2021-05-04T05:18:53.5090364Z Ran 1250 tests in 4508.693s
+2021-05-05T05:29:53.0946195Z Ran 1251 tests in 4989.032s
+2021-05-06T05:26:05.6627667Z Ran 1251 tests in 4766.005s
+2021-05-07T05:19:54.3788683Z Ran 1251 tests in 4305.963s
+2021-05-08T05:32:49.9787816Z Ran 1251 tests in 4999.028s
+2021-05-09T05:38:03.4560444Z Ran 1251 tests in 5482.509s
+2021-05-10T05:34:58.3502335Z Ran 1251 tests in 5067.805s
+2021-05-11T05:29:07.7916431Z Ran 1251 tests in 4797.435s
+2021-05-12T05:23:10.5488731Z Ran 1251 tests in 4276.426s
+2021-05-13T05:25:09.1884039Z Ran 1258 tests in 4275.409s
+2021-05-14T05:39:20.0295201Z Ran 1258 tests in 4999.023s
+2021-05-15T05:31:48.8021685Z Ran 1258 tests in 4736.174s
+2021-05-16T05:33:12.0136713Z Ran 1258 tests in 4310.326s
+2021-05-17T05:30:27.7704400Z Ran 1258 tests in 4561.060s
+2021-05-18T05:31:34.3746293Z Ran 1259 tests in 4426.723s
+2021-05-19T05:31:11.8604863Z Ran 1260 tests in 4903.506s
+2021-05-20T05:22:56.6087010Z Ran 1261 tests in 4299.536s
+2021-05-21T05:28:25.7511300Z Ran 1261 tests in 4498.286s
+2021-05-22T05:44:54.2975226Z Ran 1270 tests in 5376.292s
+2021-05-23T05:35:29.5504579Z Ran 1270 tests in 4289.031s
+2021-05-24T05:33:40.4688984Z Ran 1270 tests in 4202.429s
+2021-05-25T05:45:30.0310577Z Ran 1270 tests in 4882.292s
+2021-05-26T06:03:08.4980635Z Ran 1274 tests in 4441.783s
+2021-05-27T06:05:25.0347805Z Ran 1274 tests in 4381.865s
+2021-05-28T06:35:10.3614775Z Ran 1273 tests in 4529.720s
+2021-05-29T07:10:28.5980900Z Ran 1275 tests in 4639.335s
+2021-05-30T07:01:37.6908114Z Ran 1275 tests in 5123.743s
+2021-05-31T07:01:41.6742606Z Ran 1275 tests in 4672.112s
+2021-06-01T07:36:38.0359361Z Ran 1275 tests in 5183.674s
+2021-06-02T07:21:46.3022239Z Ran 1275 tests in 4610.975s
+2021-06-03T07:20:14.4589015Z Ran 1275 tests in 5795.353s
+2021-06-04T06:44:13.4142157Z Ran 1275 tests in 4574.473s
+2021-06-08T06:10:00.4654735Z Ran 1275 tests in 5406.636s
+```
+</details>
+
+now will try to do timing on a local OSX to see if it is indeed just some coincidence with OSX VM getting slower or it is \"real\".
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_13_f6bec279f43603719694e44d99309fc7._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_13_f6bec279f43603719694e44d99309fc7._comment
new file mode 100644
index 0000000000..e8a5dbb31f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_13_f6bec279f43603719694e44d99309fc7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 13"
+ date="2021-06-08T19:08:01Z"
+ content="""
+One other test for “some coincidence with OSX VM getting slower“ is to try the current github CI test with an older git-annex.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_14_4d2998ea843dd8adee8b7b066d97d942._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_14_4d2998ea843dd8adee8b7b066d97d942._comment
new file mode 100644
index 0000000000..8204fee07e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_14_4d2998ea843dd8adee8b7b066d97d942._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="getting closer..."
+ date="2021-06-08T19:21:59Z"
+ content="""
+I think I have localized the slowdown to a single particular test in datalad which operates on a very heavy tree with tiny files.
+Good and bad runs:
+
+```
+*$> grep -h -A3 'datalad.support.tests.test_annexrepo.test_files_split(' builds/2021/05/*/cron-*/44196064/Build\ git-annex\ on\ macOS-29{2,3}-failed/1_test-datalad\ \(master\).txt
+2021-05-25T04:34:39.7723910Z datalad.support.tests.test_annexrepo.test_files_split(<class 'datalad.support.gitrepo.GitRepo'>,) ... ok
+2021-05-25T04:39:31.3031220Z datalad.support.tests.test_annexrepo.test_files_split(<class 'datalad.support.annexrepo.AnnexRepo'>,) ... ok
+2021-05-25T04:39:31.3032670Z datalad.support.tests.test_annexrepo.test_get_size_from_key ... ok
+2021-05-25T04:39:31.3043440Z datalad.support.tests.test_annexrepo.test_done_deprecation ... ok
+2021-05-25T04:39:31.3104830Z datalad.support.tests.test_ansi_colors.test_color_enabled ... ok
+--
+2021-05-26T05:01:12.6881120Z datalad.support.tests.test_annexrepo.test_files_split(<class 'datalad.support.gitrepo.GitRepo'>,) ... ok
+2021-05-26T06:47:04.8547640Z datalad.support.tests.test_annexrepo.test_files_split(<class 'datalad.support.annexrepo.AnnexRepo'>,) ... ok
+2021-05-26T06:47:04.8549600Z datalad.support.tests.test_annexrepo.test_get_size_from_key ... ok
+2021-05-26T06:47:04.8559760Z datalad.support.tests.test_annexrepo.test_done_deprecation ... ok
+2021-05-26T06:47:04.8636720Z datalad.support.tests.test_ansi_colors.test_color_enabled ... ok
+
+```
+you can see from timestamps (a guess github prepends time stamp AFTER getting full line) that there is over 1h30m spent there on `test_files_split(<class 'datalad.support.annexrepo.AnnexRepo'>,)`.  [Here is the actual test etc for posterity](https://github.com/datalad/datalad/blob/master/datalad/support/tests/test_annexrepo.py#L2354).  Yet to pin point more specifically on what is going on but most likely some interplay with command line length invocation limits (specific to OSX) etc.
+
+So good news is that it is not some widely spread drastic slow-down effect as far as I see it.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_15_c9488d6180e741dfec0793f546c9eb29._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_15_c9488d6180e741dfec0793f546c9eb29._comment
new file mode 100644
index 0000000000..a8051f172e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_15_c9488d6180e741dfec0793f546c9eb29._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 15"
+ date="2021-06-08T20:23:09Z"
+ content="""
+ok -- I think it (or at least a part of it, datalad test is still running) boils down to `git-annex add` now doing some `O(n-staged * n-cmdline-paths)` lookup/operation (instead of before just `O(n-cmdline-paths)`) whenever we have a series of `annex add --json cmdline-paths ...`. This is reflected by the fact that if before we had about `~30 sec` per each invocation of `annex add`, now we have `30 284 528 720`.
+
+In any case in datalad we should finally switch to use `annex add --batch`, filed [an issue](https://github.com/datalad/datalad/issues/5721), but I guess may be it could also be addressed on git-annex side since sounds like some suboptimal data structure is used for some paths' matching.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_16_65aaf8e15cd15187cd63863634f25091._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_16_65aaf8e15cd15187cd63863634f25091._comment
new file mode 100644
index 0000000000..39e0f92db3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_16_65aaf8e15cd15187cd63863634f25091._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2021-06-08T20:56:50Z"
+ content="""
+This is starting to make some sense. If you're running git-annex add
+N times adding M files each time, then each run will now diff the
+changes in the index made by the previous run.
+
+And the first part of diffing the index is generating a tree from all the
+files in it, which is to some extent `O(N*M)` (though IDK, git may have
+optimisations involving subtrees or such). So the combined N git-annex add
+runs come to `O(N*N*M)`
+
+On linux, `git write-tree` with 100,000 files in the index runs in under 1
+second, so athe `N*M` is not too bad. And then there's the overhead of
+git-annex processing the resulting diff, which takes more time but is what
+I've been optimising.
+
+Perhaps on OSX something is making the write-tree significantly slower.
+Or something is making it run the command more with fewer files per run.
+Although IIRC OSX has close to the same maximum command line length as
+linux.
+
+Or maybe the index diffing is diffing from the wrong start point.
+One way I can think of where this would happen is if
+it somehow misdetects the index as being locked.
+
+A --debug trace of the one of the later git-annex add runs in that
+test case would probably shed some useful light.
+
+Yes, --batch should avoid the problem...
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_17_045fd8ebe1f9441e42c9c6fbf5c06563._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_17_045fd8ebe1f9441e42c9c6fbf5c06563._comment
new file mode 100644
index 0000000000..d8b1baa3ef
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_17_045fd8ebe1f9441e42c9c6fbf5c06563._comment
@@ -0,0 +1,93 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 17"""
+ date="2021-06-09T18:53:14Z"
+ content="""
+Trying to repro on linux, batches of 1000 files each time:
+
+	joey@darkstar:~/tmp/bench6>/usr/bin/time git-annex add 1??? --quiet
+	7.17user 5.02system 0:11.33elapsed 107%CPU (0avgtext+0avgdata 69480maxresident)k
+	6880inputs+40344outputs (4major+404989minor)pagefaults 0swaps
+	joey@darkstar:~/tmp/bench>/usr/bin/time git-annex add 2??? --quiet
+	7.75user 5.63system 0:12.62elapsed 106%CPU (0avgtext+0avgdata 70296maxresident)k
+	3640inputs+42656outputs (9major+414106minor)pagefaults 0swaps
+	joey@darkstar:~/tmp/bench>/usr/bin/time git-annex add 3??? --quiet
+	8.04user 5.74system 0:12.92elapsed 106%CPU (0avgtext+0avgdata 70396maxresident)k
+	1456inputs+44200outputs (8major+414767minor)pagefaults 0swaps
+	joey@darkstar:~/tmp/bench>/usr/bin/time git-annex add 4??? --quiet
+	8.66user 5.57system 0:13.45elapsed 105%CPU (0avgtext+0avgdata 69620maxresident)k
+	768inputs+45768outputs (11major+416364minor)pagefaults 0swaps
+	joey@darkstar:~/tmp/bench>/usr/bin/time git-annex add 5??? --quiet
+	8.83user 5.58system 0:13.92elapsed 103%CPU (0avgtext+0avgdata 69956maxresident)k
+	5448inputs+47128outputs (45major+415820minor)pagefaults 0swaps
+	joey@darkstar:~/tmp/bench>/usr/bin/time git-annex add 6??? --quiet
+	9.00user 5.49system 0:13.60elapsed 106%CPU (0avgtext+0avgdata 70340maxresident)k
+	20864inputs+48768outputs (270major+418220minor)pagefaults 0swaps
+	joey@darkstar:~/tmp/bench>/usr/bin/time git-annex add 7??? --quiet
+	9.23user 5.56system 0:13.90elapsed 106%CPU (0avgtext+0avgdata 70352maxresident)k
+	12736inputs+50024outputs (492major+417882minor)pagefaults 0swaps
+	joey@darkstar:~/tmp/bench>/usr/bin/time git-annex add 8??? --quiet
+	9.27user 5.62system 0:13.89elapsed 107%CPU (0avgtext+0avgdata 70236maxresident)k
+	11320inputs+51816outputs (411major+419672minor)pagefaults 0swaps
+	joey@darkstar:~/tmp/bench>/usr/bin/time git-annex add 9??? --quiet
+	9.33user 5.80system 0:14.04elapsed 107%CPU (0avgtext+0avgdata 70380maxresident)k
+	10952inputs+53128outputs (281major+419771minor)pagefaults 0swaps
+
+There's some growth here, but it seems linear to the number of new files in the git index.
+
+Doing the same with the last git-annex release:
+
+0:10.97elapsed, 0:11.24elapsed, 0:11.65elapsed, 0:11.90elapsed,
+0:12.25elapsed, 0:12.86elapsed, 0:12.74elapsed, 0:12.84elapsed,
+0:13.26elapsed
+
+So close to the same, the slowdown feels minimal.
+
+Then on OSX:
+
+	datalads-imac:bench joey$ PATH=$HOME:$PATH /usr/bin/time ~/git-annex  add 1??? --quiet
+	       18.26 real         6.03 user         8.35 sys
+	datalads-imac:bench joey$ PATH=$HOME:$PATH /usr/bin/time ~/git-annex  add 2??? --quiet
+	       26.68 real         6.63 user         9.08 sys
+	datalads-imac:bench joey$ PATH=$HOME:$PATH /usr/bin/time ~/git-annex  add 3??? --quiet
+	       32.13 real         6.75 user         9.09 sys
+	datalads-imac:bench joey$ PATH=$HOME:$PATH /usr/bin/time ~/git-annex  add 4??? --quiet
+	       34.49 real         7.11 user         9.40 sys
+	datalads-imac:bench joey$ PATH=$HOME:$PATH /usr/bin/time ~/git-annex  add 5??? --quiet
+	       34.61 real         7.08 user         9.18 sys
+	datalads-imac:bench joey$ PATH=$HOME:$PATH /usr/bin/time ~/git-annex  add 6??? --quiet
+	       36.66 real         7.20 user         9.31 sys
+	datalads-imac:bench joey$ PATH=$HOME:$PATH /usr/bin/time ~/git-annex  add 7??? --quiet
+	       38.29 real         7.35 user         9.42 sys
+	datalads-imac:bench joey$ PATH=$HOME:$PATH /usr/bin/time ~/git-annex  add 8??? --quiet
+	       35.85 real         7.39 user         9.57 sys
+	datalads-imac:bench joey$ PATH=$HOME:$PATH /usr/bin/time ~/git-annex  add 9??? --quiet
+	       36.20 real         7.56 user         9.59 sys
+
+Well, this does not seem exponential but it's certainly growing
+faster than linux.
+
+Then tried on OSX with 100 chunks of 100 files each:
+
+	datalads-imac:bench joey$ for x in $(seq 10 99); do echo $x; PATH=$HOME:$PATH /usr/bin/time ~/git-annex  add $x?? --quiet; done
+	...
+	23
+	        3.91 real         0.83 user         1.17 sys
+	24
+	        3.31 real         0.83 user         1.25 sys
+	25
+	        3.32 real         0.83 user         1.26 sys
+	...
+	80
+	        5.68 real         1.05 user         1.60 sys
+	81
+	        6.18 real         1.06 user         1.60 sys
+	82
+	        7.06 real         1.06 user         1.59 sys
+
+There's more overhead because git-annex has to start up and diff
+the index trees, which takes longer than processing the 100 files
+in the chunk. But this is not taking hours to run, so either the
+test case involves a *lot* more than 10k files, or there is
+something else involved.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_17_8df0e346ed85e52ec94763d11c174ab3._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_17_8df0e346ed85e52ec94763d11c174ab3._comment
new file mode 100644
index 0000000000..1c3242e79d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_17_8df0e346ed85e52ec94763d11c174ab3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="OSX mystery resolved. add --batch is effective mitigation"
+ date="2021-06-08T21:56:53Z"
+ content="""
+> Perhaps on OSX something is making the write-tree significantly slower. Or something is making it run the command more with fewer files per run.
+
+The latter would be my guess... We seems to get 2 vs 5 splits on Linux vs OSX... our `datalad.utils.CMD_MAX_ARG` (logic is [here](https://github.com/datalad/datalad/blob/HEAD/datalad/utils.py#L103)) gets set to 1048576 on linux and 524288 on OSX.  So \"matches\" and \"OSX mystery resolved\"! ;)
+
+Meanwhile confirming that using `add --batch` mitigates it. With [ad-hoc patch to add add --batched to datalad](https://github.com/datalad/datalad/pull/5722) I get 187.8053s run for our test using `annex add --batch` and bleeding edge annex 57b567ac8 and 183.1654s (so about the same) using annex 9a5981a15 from 20210525 (which takes over hour with splitting); and then with our old splitting and that old git-annex 9a5981a15 I get 188.3987s run.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_18_3e57d7d4640de95a059b2ab3d1e9d54e._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_18_3e57d7d4640de95a059b2ab3d1e9d54e._comment
new file mode 100644
index 0000000000..029c410788
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_18_3e57d7d4640de95a059b2ab3d1e9d54e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 18"
+ date="2021-06-08T21:58:20Z"
+ content="""
+clarification: the \"(which takes over hour with splitting)\" was intended for the \"bleeding edge\" one, not the older one. That one is ok even with splitting.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_19_80372cd15a6a8812072a446c41fed4e7._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_19_80372cd15a6a8812072a446c41fed4e7._comment
new file mode 100644
index 0000000000..96aec33cda
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_19_80372cd15a6a8812072a446c41fed4e7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 19"
+ date="2021-06-08T22:02:33Z"
+ content="""
+and we seems to not run that test on windows (marked as `@known_failure_windows` ;)) so we do not see that \"regression\" on windows runs (was yet another part of mystery to me why OSX only ;))
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_1_3eb1b092f41dc5c04d74f7a03249aa0f._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_1_3eb1b092f41dc5c04d74f7a03249aa0f._comment
new file mode 100644
index 0000000000..d761dae81c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_1_3eb1b092f41dc5c04d74f7a03249aa0f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2021-06-05T13:50:42Z"
+ content="""
+Oh, fresh runs datalad tests fail because I guess you implemented that \"don't display message unless takes awhile\" I spotted in one of the comments but didn't have a chance to follow up - I guess from now on we weren't be able to test us passing through messages from git annex (unless there is some setting where were could disable that feature during tests).
+
+That is unrelated to this issue of slow down though
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_21_0119751108d8d9fe6848269594bec273._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_21_0119751108d8d9fe6848269594bec273._comment
new file mode 100644
index 0000000000..d3173a56ee
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_21_0119751108d8d9fe6848269594bec273._comment
@@ -0,0 +1,104 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="more &quot;mystery resolved&quot; -- identical (empty) keys"
+ date="2021-06-09T21:00:34Z"
+ content="""
+thank you Joey for timing it up! May be relevant: in our [test scenario](https://github.com/datalad/datalad/blob/master/datalad/support/tests/test_annexrepo.py#L2354) we have 100 directories with 100 files in each one of those and each directory or file name is 100 chars long (not sure if this is relevant either). So doing 5 subsequent adds (on OSX) should result in ~20k paths specified on the command line for each invocation.
+
+<details>
+<summary>so I did this little replication script which would do similar drill (just not long filenames for this one)</summary> 
+
+```shell
+#!/bin/bash
+
+export PS4='> '
+set -eu
+cd \"$(mktemp -d ${TMPDIR:-/tmp}/ann-XXXXXXX)\"
+
+echo \"Populating the tree\"
+for d in {0..99}; do
+    mkdir $d
+    for f in {0..99}; do
+        echo \"$d$f\" >> $d/$f
+    done
+done
+
+git init
+git annex init
+/usr/bin/time git annex add --json {,1}?/* >/dev/null
+/usr/bin/time git annex add --json {2,3}?/* >/dev/null
+/usr/bin/time git annex add --json {4,5}?/* >/dev/null
+/usr/bin/time git annex add --json {6,7}?/* >/dev/null
+/usr/bin/time git annex add --json {8,9}?/* >/dev/null
+
+```
+</details>
+
+<details>
+<summary>with \"older\" 8.20210429-g9a5981a15 on OSX - stable 30 sec per batch (matches what I observed from running our tests)</summary> 
+
+```shell
+       29.83 real         9.52 user        17.43 sys
+       30.49 real        10.02 user        17.34 sys
+       30.67 real        10.37 user        17.36 sys
+       31.00 real        10.57 user        17.39 sys
+       30.78 real        10.77 user        17.23 sys
+```
+</details>
+
+<details>
+<summary>and the newer 8.20210429-g57b567ac8 -- I got the same-ish nice timing without significant growth! -- damn it</summary> 
+
+```shell
+       31.26 real        10.08 user        18.14 sys
+       31.97 real        10.99 user        18.69 sys
+       31.77 real        11.23 user        18.24 sys
+       32.08 real        11.26 user        18.06 sys
+       32.53 real        11.45 user        18.27 sys
+```
+</details>
+
+so I looked into our test generation again and realized -- we are not populating unique files.  They are all empty!
+
+<details>
+<summary>and now confirming with this slightly adjusted script which just touches them:</summary> 
+
+```shell
+#!/bin/bash
+
+export PS4='> '
+set -eu
+cd \"$(mktemp -d ${TMPDIR:-/tmp}/ann-XXXXXXX)\"
+
+echo \"Populating the tree\"
+for d in {0..99}; do
+    mkdir $d
+    for f in {0..99}; do
+        touch $d/$f
+    done
+done
+
+git init
+git annex init
+/usr/bin/time git annex add --json {,1}?/* >/dev/null
+/usr/bin/time git annex add --json {2,3}?/* >/dev/null
+/usr/bin/time git annex add --json {4,5}?/* >/dev/null
+/usr/bin/time git annex add --json {6,7}?/* >/dev/null
+/usr/bin/time git annex add --json {8,9}?/* >/dev/null
+
+```
+</details>
+
+the case I had observed
+
+```
+(base) yoh@dataladmac2 ~ % bash macos-slow-annex-add-empty.sh
+...
+       21.65 real         8.47 user        10.89 sys
+      139.96 real        61.51 user        78.18 sys
+... waiting for the rest -- too eager to post as is for now
+```
+
+so -- sorry I have not spotted that peculiarity right from the beginning!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_22_192f2055345f1156a06d93b4c25e6722._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_22_192f2055345f1156a06d93b4c25e6722._comment
new file mode 100644
index 0000000000..2fc5dc4b9e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_22_192f2055345f1156a06d93b4c25e6722._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 22"
+ date="2021-06-09T22:28:06Z"
+ content="""
+FWIW the complete timing was
+```
+       21.65 real         8.47 user        10.89 sys
+      139.96 real        61.51 user        78.18 sys
+      253.47 real       112.01 user       142.78 sys
+      370.43 real       161.94 user       211.15 sys
+      481.03 real       210.78 user       274.31 sys
+```
+so goes pretty close with what I observed with 4 splits (`30 284 528 720`).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_23_8693e7e9c800f25cbd274b6781d834d6._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_23_8693e7e9c800f25cbd274b6781d834d6._comment
new file mode 100644
index 0000000000..af4a33a6ec
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_23_8693e7e9c800f25cbd274b6781d834d6._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2021-06-14T14:09:07Z"
+ content="""
+The file contents all being the same is the crucial thing. On linux,
+adding 1000 dup files at a time (all in same directory), I get:
+
+run 1: 0:08  
+run 2: 0:42  
+run 3: 1:14  
+run 4: 1:46
+
+After run 4, adding 1000 files with all different content takes 
+0:11, so not appreciably slowed down; it only affects adding dups,
+and only when there are a *lot* of them.
+
+This feels like quite an edge case, and also not
+really a new problem, since unlocked files would have already
+had the same problem before recent changes.
+
+I thought this might be an innefficiency in sqlite's index, similar to how
+hash tables can scale poorly when a lot of things end up in the same
+bucket. But disabling the index did not improve performance.
+
+Aha -- the slowdown is caused by `git-annex add` looking to see what other
+annexed files use the same content, so that it can populate any unlocked
+files that didn't have the content present before. With all these locked
+files now recorded in the db, it has to check each file in turn, and
+there's the `O(N^2)`
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_24_6d11f6aa4b1a435bdf6d165eb8e6db8a._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_24_6d11f6aa4b1a435bdf6d165eb8e6db8a._comment
new file mode 100644
index 0000000000..ff018e693e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_24_6d11f6aa4b1a435bdf6d165eb8e6db8a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 24"""
+ date="2021-06-14T15:36:30Z"
+ content="""
+If the database recorded when files were unlocked or not, that could be
+avoided, but tracking that would add a lot of complexity for what is just
+an edge case. And probably slow things down generally by some amount due to
+the db being larger.
+
+It seems almost cheating, but it could remember the last few keys it's added,
+and avoid trying to populate unlocked files when adding those keys again.
+This would slow down the usual case by some tiny amount (eg an IORef access) 
+but avoid `O(N^2)` in this edge case. Though it wouldn't fix all edge cases,
+eg when the files it's adding rotate through X different contents, and X is
+larger than the number of keys it remembers.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_25_5525b58ec94084a926c71f749d1f4233._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_25_5525b58ec94084a926c71f749d1f4233._comment
new file mode 100644
index 0000000000..ca226f11a4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_25_5525b58ec94084a926c71f749d1f4233._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 25"""
+ date="2021-06-14T15:52:37Z"
+ content="""
+Found an optimisation that sped it up 50%, but this edge case is still 
+`O(N^2)`, so *shrug*.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_26_cb64b1798af6ad507ce4a4196e9c5b1d._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_26_cb64b1798af6ad507ce4a4196e9c5b1d._comment
new file mode 100644
index 0000000000..c209d0628d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_26_cb64b1798af6ad507ce4a4196e9c5b1d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="git-annex-add slowdown"
+ date="2021-06-14T16:00:44Z"
+ content="""
+> git-annex add looking to see what other annexed files use the same content, so that it can populate any unlocked files that didn't have the content present before
+
+Could this be skipped if `annex.supportunlocked=false`?
+
+>The file contents all being the same is the crucial thing
+
+One not-quite-edge case where that happens is when empty files are used as placedholders for outputs of failed steps throughout a large workflow.
+
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_27_db91e10d0bea246686ba2241b348e67d._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_27_db91e10d0bea246686ba2241b348e67d._comment
new file mode 100644
index 0000000000..e1c5cfe399
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_27_db91e10d0bea246686ba2241b348e67d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 27"
+ date="2021-06-14T16:23:41Z"
+ content="""
+FWIW, without having a clear idea on code logic/data structures, it smells a bit like somewhere may be it could be `any` vs current `all` operation/check (in case of `add` at least) if needed just to test if there is already a path with a given key, and assuming that DB doesn't require a full rewrite of all `path` entries if a new path added for the key.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_28_0d6a37f823cd9cb3ed1e6e90066ebd2c._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_28_0d6a37f823cd9cb3ed1e6e90066ebd2c._comment
new file mode 100644
index 0000000000..f430ed767e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_28_0d6a37f823cd9cb3ed1e6e90066ebd2c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 28"""
+ date="2021-06-14T16:31:26Z"
+ content="""
+@Ilya sure can be skipped when annex.supportunlocked=false.
+I've implemented that. (And also for several other cases that have similar
+behavior, like dropping a key.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_29_0f3c8949ae362b43ac7db02eb4e11890._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_29_0f3c8949ae362b43ac7db02eb4e11890._comment
new file mode 100644
index 0000000000..3ab4eb9e6e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_29_0f3c8949ae362b43ac7db02eb4e11890._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 29"""
+ date="2021-06-14T16:32:38Z"
+ content="""
+@yarik no, it needs to check all files. Consider what happens when `foo` is
+an annexed link to key K, which is not present, and you copy 
+`.git/annex/objects/../K` from some other repo and run `git annex add K`
+(or reinject, or get, it's all the same) -- `foo` now points to the content
+of K. The same needs to also hold true for unlocked files, and so it has to
+check if `foo` is an unlocked pointer to K and populate the file with the
+content. Repeat for all the other 9999 files..
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_2_521f784d686fcaeb5e081599fbdf9903._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_2_521f784d686fcaeb5e081599fbdf9903._comment
new file mode 100644
index 0000000000..7d3c876067
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_2_521f784d686fcaeb5e081599fbdf9903._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-06-07T15:41:43Z"
+ content="""
+I assume these tests are creating lots of clones of repositories. Are they
+also doing lots of merges or switching between branches?
+
+The init scan time has already been optimised as much as seems feasible.
+The update scan time can still be optimised, see
+[[speed_up_keys_db_update_with_git_streaming]].
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_30_386c0cfe688effb1543ffd01a54717e0._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_30_386c0cfe688effb1543ffd01a54717e0._comment
new file mode 100644
index 0000000000..6ab1c624aa
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_30_386c0cfe688effb1543ffd01a54717e0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 30"
+ date="2021-06-14T17:36:16Z"
+ content="""
+> The same needs to also hold true for unlocked files, and so it has to check if foo is an unlocked pointer to K and populate the file with the content.
+
+but that should only needs to be done iff K became present/known whenever it was not present before. If K is already known (e.g. was just added for another file, or may be was added in previous \"commit\") no such checks are needed since those files could be expected to already be populated. Right?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_31_97fa9b7729805704a6a22cf18082e203._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_31_97fa9b7729805704a6a22cf18082e203._comment
new file mode 100644
index 0000000000..6065817da4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_31_97fa9b7729805704a6a22cf18082e203._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: comment 30"""
+ date="2021-06-14T18:36:11Z"
+ content="""
+I discussed that approach in comment #24.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_32_0ab5e774dad1e6e74a5c72b95e40d659._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_32_0ab5e774dad1e6e74a5c72b95e40d659._comment
new file mode 100644
index 0000000000..61f0dd11cc
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_32_0ab5e774dad1e6e74a5c72b95e40d659._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 32"""
+ date="2021-06-14T20:26:52Z"
+ content="""
+Some thoughts leading to a workable plan:
+
+It's easy to detect this edge case because getAssociatedFiles will be
+returning a long list of files. So it could detect say 10 files in the list
+and start doing something other than the usual, without bothering the usual
+case with any extra work.
+
+Git starts to get slow anyway in the 1 million to 10 million file range. So
+we can assume less than that many files are being added. And there need to
+be a fairly large number of duplicates of a key for speed to become a problem
+when adding that key. Around 1000 based on above benchmarks, but 100 would
+be safer.
+
+If it's adding 10 million files, there can be at most 10000 keys
+that have `>=` 1000 duplicates (10 million / 1000).
+No problem to remember 10000 keys; a key is less than 128 bytes long, so
+that would take 1250 kb, plus the overhead of the Map. Might as well
+remember 12 mb worth of keys, to catch 100 duplicates.
+
+It would be even better to use a bloom filter, which could remember many
+more, and I thought I had a way, but the false positive case seems the
+wrong way around. If the bloom filter remembers keys that have already had
+their associated files populated, then a false positive would prevent doing
+that for a key that it's not been done for.
+
+It would make sense to do this not only in populateUnlockedFiles but in
+Annex.Content.moveAnnex and Annex.Content.removeAnnex. Although removeAnnex
+would need a different bloom filter, since a file might have been populated
+and then somehow get removed in the same git-annex call.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_33_6e5121e066998a303cf68ebc53e9fc15._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_33_6e5121e066998a303cf68ebc53e9fc15._comment
new file mode 100644
index 0000000000..32eb08e113
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_33_6e5121e066998a303cf68ebc53e9fc15._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 33"""
+ date="2021-06-15T13:01:04Z"
+ content="""
+Oh, there's a much better solution: If the annex object file already exists
+when ingesting a new file, skip populating other associated files. They
+will have already been populated. moveAnnex has to check if the annex object
+file already exists anyway, so this will have zero overhead.
+
+(Maybe that's what yarik was getting at in comment #30)
+
+Implemented that, and here's the results, re-running my prior benchmark:
+
+run 1: 0:03.14
+run 2: 0:03.24
+run 3: 0.03.35
+run 4: 0.03.45
+run 9: 0:03.65
+
+That also shows the actual overhead of the diffing of the index,
+as its size grows, is quite small.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_34_86d07025980e0b50d1a52f73c049944a._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_34_86d07025980e0b50d1a52f73c049944a._comment
new file mode 100644
index 0000000000..8752b4c5c7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_34_86d07025980e0b50d1a52f73c049944a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 34"
+ date="2021-06-15T15:38:16Z"
+ content="""
+FWIW: Yes! ;-)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_35_d3437076c759eedc0c8d5d15db035455._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_35_d3437076c759eedc0c8d5d15db035455._comment
new file mode 100644
index 0000000000..cf1df1153d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_35_d3437076c759eedc0c8d5d15db035455._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="thanks"
+ date="2021-06-16T19:54:01Z"
+ content="""
+Thanks @joeyh for sorting this out ;)
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_36_25fa8b726e06dc69e3a0d9ed675da1d1._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_36_25fa8b726e06dc69e3a0d9ed675da1d1._comment
new file mode 100644
index 0000000000..c26a759356
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_36_25fa8b726e06dc69e3a0d9ed675da1d1._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 36"
+ date="2021-06-16T21:32:58Z"
+ content="""
+yes, awesome, thank you Joey!
+
+FWIW, here is the little trail of our tests (non-adjusted in released version) timings
+
+```
+$> grep -h Ran 0[56]/cron-*/build-macos.yaml-*/*_test-datalad\ \(release\).txt
+2021-05-01T04:28:55.4957910Z Ran 1257 tests in 6033.095s
+2021-05-02T04:24:43.3005800Z Ran 1257 tests in 5722.774s
+2021-05-03T04:24:54.5178860Z Ran 1257 tests in 5846.700s
+...
+2021-05-24T04:39:07.5375680Z Ran 1257 tests in 5710.372s
+2021-05-25T04:54:01.2232460Z Ran 1257 tests in 6459.339s
+2021-05-26T06:41:04.2956530Z Ran 1257 tests in 11655.761s
+2021-05-27T07:07:28.4722960Z Ran 1257 tests in 11954.671s
+...
+2021-06-13T05:59:36.9626910Z Ran 1257 tests in 11987.233s
+2021-06-14T06:05:36.1668770Z Ran 1257 tests in 12135.290s
+2021-06-15T04:45:33.3489450Z Ran 1257 tests in 7046.095s
+2021-06-16T04:26:46.1256550Z Ran 1257 tests in 5706.314s
+```
+so we are indeed back to normal (if not better ;)) !
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_3_d30a515103d04fd966aadee7f141aeee._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_3_d30a515103d04fd966aadee7f141aeee._comment
new file mode 100644
index 0000000000..e59b347f7e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_3_d30a515103d04fd966aadee7f141aeee._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-06-07T15:49:51Z"
+ content="""
+Also worth saying: When I have a choice between a bug fix and a performance
+change, I kind of have to pick the bug fix.
+[[bugs/indeterminite_preferred_content_state_for_duplicated_file]] was a
+longstanding bug that could cause *very* expensive misbehavior. The only
+way to fix it that would not have an on performance would be to
+remove include= and exclude= from the preferred content expression syntax,
+which would prevent a lot of current uses of preferred content.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_4_4011786784a140442dd7ecd1cefe559b._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_4_4011786784a140442dd7ecd1cefe559b._comment
new file mode 100644
index 0000000000..40b04f2f7e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_4_4011786784a140442dd7ecd1cefe559b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="deferring the scan"
+ date="2021-06-07T17:41:44Z"
+ content="""
+>The only way to fix it that would not have an on performance would be to remove include= and exclude= from the preferred content expression syntax
+
+What about deferring the scan until the first command that uses `include=/exclude=` gets run, if `annex.supportunlocked=false`?
+Also, could the scan be limited to the files that match one of the include/exclude globs?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_4_85d1031d2b51c0fc1271c283d8ee7888._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_4_85d1031d2b51c0fc1271c283d8ee7888._comment
new file mode 100644
index 0000000000..27c306ba7a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_4_85d1031d2b51c0fc1271c283d8ee7888._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-06-07T20:22:24Z"
+ content="""
+Turns out `git-annex init` got a lot slower than it had to, it was doing
+the same kind of scan twice. I think that probably explains much of the
+slowdown you saw. (Although it still needs to do somewhat more work than
+before, but also does it more efficiently than before.)
+
+Also I've optimised the update scan's use of git, around a 20% speedup,
+although I don't know if your test case speed was impacted much by that
+scan anyway.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_5_b0f1e94e96cf8fe992425cf81f8d1105._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_5_b0f1e94e96cf8fe992425cf81f8d1105._comment
new file mode 100644
index 0000000000..d6ea9e9b20
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_5_b0f1e94e96cf8fe992425cf81f8d1105._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-06-07T20:42:34Z"
+ content="""
+Looking at the CI log, I don't see any past runs that took 1h 46min.
+A month ago they were taking 2h 6min. Let's see if the changes I'm pushing
+now drop it back to that.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_7_35217e61ccf6936e105df8de7e1775d0._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_7_35217e61ccf6936e105df8de7e1775d0._comment
new file mode 100644
index 0000000000..8a32e5a426
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_7_35217e61ccf6936e105df8de7e1775d0._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="clarification"
+ date="2021-06-07T21:20:35Z"
+ content="""
+For completeness 
+
+> Looking at the CI log, I don't see any past runs that took 1h 46min. A month ago they were taking 2h 6min. 
+
+I was looking at OSX ones. And the timing was for the one right before slow down: It was [this one](https://github.com/datalad/git-annex/actions/runs/873390021), but even [previous one](https://github.com/datalad/git-annex/actions/runs/869970007) was 1h40min
+
+> Let's see if the changes I'm pushing now drop it back to that.
+
+🤞
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_8_29bde900ef625702b49cf020118f940f._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_8_29bde900ef625702b49cf020118f940f._comment
new file mode 100644
index 0000000000..e773865a70
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_8_29bde900ef625702b49cf020118f940f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 8"
+ date="2021-06-07T21:39:05Z"
+ content="""
+FWIW:
+
+> I assume these tests are creating lots of clones of repositories.
+
+lots of `git annex init` in new git repos.  Also a good number of clones AFAIK.  FWIW: we used to do more clones instead of just recreating new repos per test, but then we switched to just creating a new repo.  We still have a good number though of cloning.
+
+> Are they also doing lots of merges or switching between branches?
+
+Not that many AFAIK.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_9_431582f1c218f27e50849df1444dc845._comment b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_9_431582f1c218f27e50849df1444dc845._comment
new file mode 100644
index 0000000000..2676d6509b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/significant_performance_regression_impacting_datal/comment_9_431582f1c218f27e50849df1444dc845._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-06-08T13:45:18Z"
+ content="""
+I do not see 1h40min anywhere on the page you linked. It says
+2h 6m at the top. Oh I see, you are clicking around to get to
+https://github.com/datalad/git-annex/runs/2661363385?check_suite_focus=true,
+and that number is in there next to "Run datalad tests".
+
+My improvements yesterday did not improve your test suite time any. But
+they certainly sped it up a *lot* in my benchmarks. So I think what you
+think is taking more time, eg the scanning at init, does not really have
+much to do with whatever is really taking more time. And if your test suite
+is mostly not cloning repos but is initializing new empty repos, then the
+scanning at init was and still is effectively a noop, it will not have
+gotten more expensive.
+
+It might be that the incremental updating git-annex now does when it sees
+changes to the index is making your test suite run a bit longer. But twice
+as long? That is not a very expensive process.
+
+Also notice that the git-annex test part of the CI job used to take
+15m54s and is now taking 17m29s. That's doing some cloning and some adding
+of files etc, and it didn't double in run time.
+
+I did find another nice optimisation this morning
+[[!commit c831a562f550e6ff93e081f555eced3a8a0d524f]], so we can see if that
+improves things in the next run.
+
+I suspect you're going to have to look at specific parts of your test suite
+and/or the CI system to identify what's slower though.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit.mdwn b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit.mdwn
new file mode 100644
index 0000000000..4c36641de2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit.mdwn
@@ -0,0 +1,128 @@
+### Please describe the problem.
+
+I have mentioned this issue here and there but I believe I never filed an issue for it.  ATM I have a process running which does have a good number (see below). Originally we started to observe this issue after refactoring in datalad ([PR4829](https://github.com/datalad/datalad/pull/4829#issuecomment-680837746), but we have not found any possible reason on why it is happening, so decided just to let those batched processes let go without being stuck on them.  In that PR testing it was quite reproducible (testing `datalad-crawler` extension).  In real life it is some % of processes which exhibit the same behavior.  E.g. below it is I believe only those handful from over 1k of such processes.
+
+
+```
+    0     REG       0x34          0  226206175 /mnt/scrap/tmp/abcd/testds-fast-full4/sourcedata/.git/annex/journal.lck                                                                                                             
+    1    FIFO        0xc             184736925 pipe
+    2     REG       0x32          0  111383230 /home/yoh/.tmp/tmpo88ucekd (deleted)
+    3 a_inode        0xd          0      10388 [eventpoll]
+    4 a_inode        0xd          0      10388 [timerfd]
+    5    FIFO        0xc             184711928 pipe
+    6    FIFO        0xc             184711928 pipe
+    7 a_inode        0xd          0      10388 [eventfd]
+    8    FIFO        0xc             184711931 pipe
+    9    FIFO        0xc             184711931 pipe
+   10 a_inode        0xd          0      10388 [eventfd]
+   11 a_inode        0xd          0      10388 [eventpoll]
+   12    FIFO        0xc             184711936 pipe
+   13    FIFO        0xc             184711936 pipe
+   14 a_inode        0xd          0      10388 [eventfd]
+   15 a_inode        0xd          0      10388 [eventpoll]
+   16    FIFO        0xc             184711937 pipe
+   17    FIFO        0xc             184711937 pipe
+   18 a_inode        0xd          0      10388 [eventfd]
+   19 a_inode        0xd          0      10388 [eventpoll]
+   20    FIFO        0xc             184711940 pipe
+   21    FIFO        0xc             184711940 pipe
+   22 a_inode        0xd          0      10388 [eventfd]
+   23     REG       0x34          0  226206176 /mnt/scrap/tmp/abcd/testds-fast-full4/sourcedata/.git/annex/othertmp.lck
+   24     REG       0x34    1327104  227606027 /mnt/scrap/tmp/abcd/testds-fast-full4/sourcedata/.git/annex/othertmp/jlog3458164-0
+   25    FIFO        0xc             185127155 pipe
+   26    FIFO        0xc             184895622 pipe
+   27    FIFO        0xc             184895623 pipe
+   28    FIFO        0xc             184733096 pipe
+   29    FIFO        0xc             184733097 pipe
+   31    FIFO        0xc             184733098 pipe
+  cwd     DIR       0x34      47782  226206111 /mnt/scrap/tmp/abcd/testds-fast-full4/sourcedata
+  mem     REG       0x2d             110620457 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib64/ld-linux-x86-64.so.2 (path dev=0,50)
+  mem     REG       0x2d             110620869 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex (path dev=0,50)
+  mem     REG       0x2d             110621138 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib/x86_64-linux-gnu/libmagic.so.1 (path dev=0,50)
+  mem     REG       0x2d             110621139 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib/x86_64-linux-gnu/libc.so.6 (path dev=0,50)
+  mem     REG       0x2d             110621140 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib/x86_64-linux-gnu/libgmp.so.10 (path dev=0,50)
+  mem     REG       0x2d             110621145 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib/x86_64-linux-gnu/libm.so.6 (path dev=0,50)
+  mem     REG       0x2d             110621163 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib/x86_64-linux-gnu/libsqlite3.so.0 (path dev=0,50)
+  mem     REG       0x2d             110621175 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib/x86_64-linux-gnu/libbz2.so.1.0 (path dev=0,50)
+  mem     REG       0x2d             110621176 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib/x86_64-linux-gnu/liblzma.so.5 (path dev=0,50)
+  mem     REG       0x2d             110621187 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib/x86_64-linux-gnu/libpthread.so.0 (path dev=0,50)
+  mem     REG       0x2d             110621207 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib/x86_64-linux-gnu/libffi.so.7 (path dev=0,50)
+  mem     REG       0x2d             110621208 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib/x86_64-linux-gnu/libdl.so.2 (path dev=0,50)
+  mem     REG       0x2d             110621211 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib/x86_64-linux-gnu/libz.so.1 (path dev=0,50)
+  mem     REG       0x2d             111381598 /home/yoh/.cache/git-annex/locales/bb375eb6ec0d2706f1723307f068911a/en_US.UTF-8/LC_CTYPE (path dev=0,50)
+  rtd     DIR      0x900       4096          2 /
+  txt     REG       0x32     177928  110620457 /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/lib64/ld-linux-x86-64.so.2
+
+```
+
+the tail of the log file from above:
+
+```
+$> tail /mnt/scrap/tmp/abcd/testds-fast-full4/sourcedata/.git/annex/othertmp/jlog3458164-0
+768_b3b_URL-s129400--s3&c%%NDAR__Central__1%submission__-5b733a46f742db820f7b5552c7c576df.log
+f64_54f_URL-s428527--s3&c%%NDAR__Central__1%submission__-4103b9975e7643d71239cf50fd5b767d.log.web
+f64_54f_URL-s428527--s3&c%%NDAR__Central__1%submission__-4103b9975e7643d71239cf50fd5b767d.log
+9e8_f0f_URL-s428527--s3&c%%NDAR__Central__1%submission__-bc9437b29056960784bab28fb24e1f87.log.web
+9e8_f0f_URL-s428527--s3&c%%NDAR__Central__1%submission__-bc9437b29056960784bab28fb24e1f87.log
+276_2e8_URL-s425371--s3&c%%NDAR__Central__1%submission__-3012b0043ac8847cf38c2c97a12cfa26.log.web
+276_2e8_URL-s425371--s3&c%%NDAR__Central__1%submission__-3012b0043ac8847cf38c2c97a12cfa26.log
+dda_614_URL-s425371--s3&c%%NDAR__Central__1%submission__-6d7ea2d5b0d0771f6a44e2e51edef648.log.web
+dda_614_URL-s425371--s3&c%%NDAR__Central__1%submission__-6d7ea2d5b0d0771f6a44e2e51edef648.log
+b66_7bf_URL-s196404--s3&c%%NDAR__Central__1%submission% 
+```
+
+```
+  13411 yoh        20   0 17804  6452  1720 S  0.0  0.0  0:13.81 │  ├─ zsh
+3136785 yoh        20   0 4176M 4094M 11008 S 21.6  3.2 22:10.12 │  │  └─ python3 datalad-nda/scripts/datalad-nda --pdb add2datalad -i /proc/self/fd/15 -d testds-fast-full4 --fast
+3881942 yoh        20   0     8     8     0 R  2.0  0.0  0:00.03 │  │     ├─ python3
+3458129 yoh        20   0  6992  3312  2920 S  0.0  0.0  0:00.09 │  │     └─ git --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git/git annex addurl --fast --with-files --json --json-error-messages --batch
+3458164 yoh        20   0  1.0T 99344 35792 S  0.0  0.1 22:03.39 │  │        └─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3725766 yoh        20   0 12348  8568  3748 D  0.0  0.0  0:03.74 │  │           ├─ git --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs write-tree
+3549190 yoh        20   0  7140  4172  3644 S  0.0  0.0  0:06.23 │  │           ├─ git --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+3463573 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  0:00.11 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch                        
+3462846 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  0:00.07 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458347 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  0:00.13 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458216 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  2:12.84 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458215 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  0:00.20 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458209 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  0:02.94 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458207 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  0:30.23 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458181 yoh        20   0  100M 55756 17736 S  0.0  0.0  0:41.01 │  │           ├─ python3 /mnt/scrap/tmp/abcd/datalad/venvs/dev3/bin/git-annex-remote-datalad
+3458175 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  5:09.58 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458174 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  3:37.60 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458173 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  0:00.93 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458172 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  0:00.91 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458171 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  5:07.11 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458170 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  0:00.92 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458169 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  4:16.06 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458167 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  0:49.34 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458166 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  0:00.93 │  │           ├─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+3458165 yoh        20   0  1.0T 99344 35792 S  0.0  0.1  0:05.84 │  │           └─ git-annex --library-path /home/yoh/.tmp/ga-mgY44yd/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-mgY44yd/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+```
+
+### What version of git-annex are you using? On what operating system?
+
+```
+$> which git-annex
+/home/yoh/.tmp/ga-RIFzW89/git-annex.linux//git-annex
+
+$> git-annex version
+git-annex version: 8.20200908-gcfc74c2f4
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP
+512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+```
+
+
+I had placed that top process into background, and then when I brought it back to see if I could may be strace any of those processes, I ran into https://git-annex.branchable.com/bugs/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/ and although main process and a single `annex addurl --batch` was still hanging there, the rest was gone/finished...
+
+Any ideas joey on what could hold them?  if needed I could try to give reproducible docker or singularity recipe based on running datalad tests...
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[notabug|done]] per comments --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_1_4123b5b93a220c1ba46126a5d97b6ff9._comment b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_1_4123b5b93a220c1ba46126a5d97b6ff9._comment
new file mode 100644
index 0000000000..d03d21a20c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_1_4123b5b93a220c1ba46126a5d97b6ff9._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-10-05T18:54:30Z"
+ content="""
+That process tree seems to show git-annex with a bunch of child
+git-annex processes. (Assuming that the first field is the pid, and
+so those are not threads..)
+
+But git-annex rarely exec's git-annex, and when it does, it's never with
+the same params as the parent git-annex was run with. And, addurl in this
+situation normally has some other child processes like `git cat-file
+--batch` that this one is missing.
+
+So it kind of looks like a fork/exec stalled before the exec somehow, I
+don't know how. strace of a child process in this situation may shed some
+light on this strange state.
+
+If a fork/exec somehow stalled, it might explain why the jlog file
+is incompletely written, since the haskell IO manager might have gotten
+locked up.
+
+It seems at least plasible that the race you then hit is somehow related to
+it getting into this state. When I fixed that race, I noticed and fixed a
+condition where runshell would run git-annex with the locales not
+generated, which would lead to running with the system locales. Which, if
+there were an incompatibility between them and the bundled libc, might
+cause some kind of weird behavior.
+
+Or, it could be something like 
+<https://gitlab.haskell.org/ghc/ghc/-/issues/4074>
+But that was fixed in 2010, so unless this git-annex was built with an
+old haskell library, unlikely that precise bug.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_2_7d37b8d79fcb6a0edd99e0bd6f2b0515._comment b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_2_7d37b8d79fcb6a0edd99e0bd6f2b0515._comment
new file mode 100644
index 0000000000..dad9b3c741
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_2_7d37b8d79fcb6a0edd99e0bd6f2b0515._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="just comments"
+ date="2020-10-05T23:11:29Z"
+ content="""
+> git cat-file --batch that this one is missing.
+
+may be that one already exited \"peacefully\"? I believe I was looking at the moment when we already requested closing that `annex addurl --batch`.
+
+> But git-annex rarely exec's git-annex, and when it does, it's never with the same params as the parent git-annex was run with
+
+I wonder if may be `htop` (I believe I pasted process tree from it) somehow may be groupped incorrectly and those are \"independent\" hanging `git annex addurl` processes which got \"folded\"... I don't know..
+
+Anyways, to hopefully \"shine the light\", I have managed to reproduce (with up to date snapshot of annex, didn't get there with systemwide older git-annex) on smaug using initially stalling datalad-crawler tests (so 100% reproducible): just login as `test` user to `smaug`.  There is a screen session with one shell there with python's PDB where we were waiting for batched process to exit but it didn't;  then 2nd one shows `ps auxw -H | grep '^test'`.  Please `strace` or inspect anything you might find pertinent (IIRC, raising debug level for datalad, or disabling code tests coverage collection, was making the stall going away). FTR the command is `PATH=~/git-annex/20201005-snapshot/:$PATH DATALAD_LOG_LEVEL=WARNING DATALAD_TESTS_TEMP_KEEP=1 python -m nose -s -v --with-cov --cover-package datalad ../datalad_crawler/dbs/tests/test_files.py ../datalad_crawler/nodes/tests/test_annex.py` and it ends up in pdb (python debugger) if batched annex did not exit although we waited.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_3_7ec51c8996c7cc4b555313e84634e406._comment b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_3_7ec51c8996c7cc4b555313e84634e406._comment
new file mode 100644
index 0000000000..e8fa031e0d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_3_7ec51c8996c7cc4b555313e84634e406._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-10-06T14:30:42Z"
+ content="""
+Looks like this time it was a git-annex info --batch. And none of
+the child processes look unusual like what you showed before,
+it's the usual collection of git cat-file.
+
+	lr-x------ 1 test test 64 Oct  6 10:27 /proc/896711/fd/0 -> 'pipe:[190817413]'
+	l-wx------ 1 test test 64 Oct  6 10:44 /proc/896825/fd/7 -> 'pipe:[190817413]'
+
+The git-annex process's stdin is still connected to a pipe, the other end of
+which datalad still has open for write. So there's no reason for git-annex to exit,
+it's still waiting for batch requests.
+
+	datalad_crawler.nodes.tests.test_annex.test_annex_file('full',) ... [WARNING] Caught Command '['git', '-c', 'annex.merge-annex-branches=false', 'annex', 'info', '--bytes', '--json', '--json-error-messages', '--batch']' timed out after 3.0 seconds [subprocess.py:_wait:1616] on trial #1. Sleeping 1.000000 and retrying
+	[WARNING] Caught Command '['git', '-c', 'annex.merge-annex-branches=false', 'annex', 'info', '--bytes', '--json', '--json-error-messages', '--batch']' timed out after 3.0 seconds [subprocess.py:_wait:1616] on trial #2. Sleeping 1.000000 and retrying
+
+3 seconds? Are you sure this is the same problem? Or that this is a problem at 
+all? git-annex info could take longer than 3 seconds if you ask it for
+info on a directory, or if it needs to merge the git-annex branch,
+or maybe in other circumstances.
+
+Getting the feeling the problem may be in your test machinery..
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_4_7bd5a28d5ba1eefd5a96483b5f00a89e._comment b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_4_7bd5a28d5ba1eefd5a96483b5f00a89e._comment
new file mode 100644
index 0000000000..842fefc8d7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_4_7bd5a28d5ba1eefd5a96483b5f00a89e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2020-10-11T13:51:28Z"
+ content="""
+the mystery is that to our knowledge we do close the stdin (and stdout) of [git-annex process right before](https://github.com/datalad/datalad/blob/master/datalad/cmd.py#L1339), so pipe should have not remained open, unless something else may be somehow keeps it open...  And I cannot reproduce the bug ATM neither locally or on smaug where I did prepare you the reproduced case!
+
+Indeed though I agree that pretty much any timeout could not generally be \"sufficient\".  That is why we need to figure out what is happening/why some times batched processes do not quit.  Either the later \"reproducer\" was exactly the same situation as in the original reported (where it was a few out of 1000s of batched processes) -- I do not know.  may be there are multiple issues.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_5_3c407c1924e21aa1ec300875680dc3b3._comment b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_5_3c407c1924e21aa1ec300875680dc3b3._comment
new file mode 100644
index 0000000000..bab686d5dd
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_5_3c407c1924e21aa1ec300875680dc3b3._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-10-12T15:39:58Z"
+ content="""
+	test      894971  0.0  0.0 145856 67768 pts/23   S+   Oct05   0:02       python -m nose -s -v --with-cov --cover-package datalad ../datalad_crawler/dbs/tests/test_files.py ../datalad_crawler/nodes/tests/test_annex.py
+	test      896682  0.0  0.0   6988  1912 pts/23   S+   Oct05   0:00         /home/test/git-annex/20201005-snapshot/exe/git --library-path /home/test/git-annex/20201005-snapshot//lib/x86_64-linux-gnu: /home/test/git-annex/20201005-snapshot/shimmed/git/git -c annex.merge-annex-branches=false annex info --bytes --json --json-error-messages --batch
+	test      896711  0.0  0.0 1074040220 32428 pts/23 Sl+ Oct05   0:00           /home/test/git-annex/20201005-snapshot/exe/git-annex --library-path /home/test/git-annex/20201005-snapshot//lib/x86_64-linux-gnu: /home/test/git-annex/20201005-snapshot/shimmed/git-annex/git-annex info --bytes --json --json-error-messages --batch
+	test      896718  0.0  0.0   7076  2772 pts/23   S+   Oct05   0:00             /home/test/git-annex/20201005-snapshot/exe/git --library-path /home/test/git-annex/20201005-snapshot//lib/x86_64-linux-gnu: /home/test/git-annex/20201005-snapshot/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+	test      896719  0.0  0.0   6988  2040 pts/23   S+   Oct05   0:00             /home/test/git-annex/20201005-snapshot/exe/git --library-path /home/test/git-annex/20201005-snapshot//lib/x86_64-linux-gnu: /home/test/git-annex/20201005-snapshot/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+	test      896720  0.0  0.0   6988  1872 pts/23   S+   Oct05   0:00             /home/test/git-annex/20201005-snapshot/exe/git --library-path /home/test/git-annex/20201005-snapshot//lib/x86_64-linux-gnu: /home/test/git-annex/20201005-snapshot/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+	test      896721  0.0  0.0   6988  2544 pts/23   S+   Oct05   0:00             /home/test/git-annex/20201005-snapshot/exe/git --library-path /home/test/git-annex/20201005-snapshot//lib/x86_64-linux-gnu: /home/test/git-annex/20201005-snapshot/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+	test      896825  0.0  0.0 216756 55932 pts/23   Sl+  Oct05   0:08         python -m nose -s -v --with-cov --cover-package datalad ../datalad_crawler/dbs/tests/test_files.py ../datalad_crawler/nodes/tests/test_annex.py
+
+896825 is the process that still had the pipe open for write. It appears to not be the main python process
+894971 that started git-annex.
+
+So, my guess would be it inherits the pipe across a fork.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_6_58997665e5aa0a237a3ec90efca92891._comment b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_6_58997665e5aa0a237a3ec90efca92891._comment
new file mode 100644
index 0000000000..70ecee7b9a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_annex_addurl_--fast_--with-files_--json_--json-error-messages_--batch__do_not_quit/comment_6_58997665e5aa0a237a3ec90efca92891._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2020-10-12T16:00:31Z"
+ content="""
+Thank you Joey for the analysis!  I am not 100% certain why that nose fork process came about.  May be nose (testing framework) causes a fork if some processes are still lingering after a test completes...  I guess something for us to keep in mind
+
+Also I
+- [identified the change has caused the issue to disappear](https://github.com/datalad/datalad/pull/5013#issuecomment-707189474) while looking through recent datalad changes.  Not yet sure if that was anyhow a \"fix\" but at least I do not observe it any longer
+- reproduced the issue with elderly 7.20190819+git2-g908476a9b-1~ndall+1, so it confirms that it is not a regression within git-annex (due to some flaky run I thought about possible regression).
+
+I think you can close it, and we (datalad) should keep an eye on nose and real-life if any stalls... so far I only observed datalad abandoning `git-annex` process without waiting long enough (like in the original case I reported here) when it could be just taking longer to complete indeed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_test__40__s__63____41___regularly_fail_starting_recently.mdwn b/doc/projects/datalad/bugs-done/some_test__40__s__63____41___regularly_fail_starting_recently.mdwn
new file mode 100644
index 0000000000..47efd1771d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_test__40__s__63____41___regularly_fail_starting_recently.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+in datalad/git-annex builds/tests we started to observe `git annex test` to exit non-0 with e.g. (first instance we captured in the logs:)
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2022/12[master]git
+$> git grep 'codes.*ExitFailure'
+cron-20221208/build-ubuntu.yaml-937-499cc771-failed/4_test-annex (nfs-home, ubuntu-latest).txt:2022-12-08T03:22:17.8706324Z   Test subprocesses exited with unexpected exit codes: [ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitFailure (-6)]
+```
+
+it is not clear what actual test exited with fail, since no match for `FAIL` in that log.  It would have been really nice if there was some kind of a summary over failed tests at the end of the run of `git annex test` so there is no need to scroll/grep to see what actually failed.  (pytest provide such summaries in python world -- very convenient)
+
+that was
+
+```
+$> grep 'annex version: ' cron-20221208/build-ubuntu.yaml-937-499cc771-failed/4_test-annex\ \(nfs-home,\ ubuntu-latest\).txt | head     
+2022-12-08T03:12:16.1390286Z git-annex version: 10.20221103+git99-g56699a774-1~ndall+1
+```
+
+such errorring is regular since then:
+
+```
+$> git grep -l 'codes.*ExitFailure' | grep cron-.*failed/[0-9]
+cron-20221208/build-ubuntu.yaml-937-499cc771-failed/4_test-annex (nfs-home, ubuntu-latest).txt
+cron-20221209/build-ubuntu.yaml-938-499cc771-failed/1_test-annex (normal, ubuntu-latest).txt
+cron-20221209/build-ubuntu.yaml-938-499cc771-failed/3_test-annex (crippled-home, ubuntu-latest).txt
+cron-20221209/build-ubuntu.yaml-938-499cc771-failed/4_test-annex (nfs-home, ubuntu-latest).txt
+cron-20221210/build-ubuntu.yaml-939-499cc771-failed/4_test-annex (nfs-home, ubuntu-latest).txt
+cron-20221211/build-ubuntu.yaml-940-499cc771-failed/4_test-annex (nfs-home, ubuntu-latest).txt
+cron-20221212/build-ubuntu.yaml-942-499cc771-failed/4_test-annex (nfs-home, ubuntu-latest).txt
+```
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/some_test__40__s__63____41___regularly_fail_starting_recently/comment_1_d4c417df9a8e6c13c06ccfc21853de02._comment b/doc/projects/datalad/bugs-done/some_test__40__s__63____41___regularly_fail_starting_recently/comment_1_d4c417df9a8e6c13c06ccfc21853de02._comment
new file mode 100644
index 0000000000..d3e7137b4c
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_test__40__s__63____41___regularly_fail_starting_recently/comment_1_d4c417df9a8e6c13c06ccfc21853de02._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-12-22T19:20:12Z"
+ content="""
+`ExitFailure (-6)` says something went badly wrong. That is not a specific
+test failing, it's an entire test runner crashing. Apparently with SIGABRT,
+so something found a reason to `abort()`. git-annex does not do that,
+probably it was glibc that did.
+
+Looking in the log...
+
+	2022-12-08T03:13:27.8289753Z libgcc_s.so.1 must be installed for pthread_cancel to work
+
+Oho! Same as <https://git-annex.branchable.com/bugs/standalone_needs_more_depends_-_libgcc-s1__63__/>
+then it seems. I've fixed that earlier today, so try with an updated
+standalone build.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_test__40__s__63____41___regularly_fail_starting_recently/comment_2_16a96277aecccfa32cd918ac662ce6f8._comment b/doc/projects/datalad/bugs-done/some_test__40__s__63____41___regularly_fail_starting_recently/comment_2_16a96277aecccfa32cd918ac662ce6f8._comment
new file mode 100644
index 0000000000..f15c30c062
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_test__40__s__63____41___regularly_fail_starting_recently/comment_2_16a96277aecccfa32cd918ac662ce6f8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-12-26T19:04:15Z"
+ content="""
+	joey@smaug:/mnt/datasets/datalad/ci/git-annex/builds/2022/12>git grep -l 'codes.*ExitFailure' | grep cron-.*failed/[0-9]|tail -n 5
+	cron-20221220/build-ubuntu.yaml-951-bdbc3088-failed/4_test-annex (nfs-home, ubuntu-latest).txt
+	cron-20221221/build-ubuntu.yaml-952-bdbc3088-failed/4_test-annex (nfs-home, ubuntu-latest).txt
+	cron-20221222/build-ubuntu.yaml-953-bdbc3088-failed/1_test-annex (normal, ubuntu-latest).txt
+	cron-20221222/build-ubuntu.yaml-953-bdbc3088-failed/3_test-annex (crippled-home, ubuntu-latest).txt
+	cron-20221222/build-ubuntu.yaml-953-bdbc3088-failed/4_test-annex (nfs-home, ubuntu-latest).txt
+
+Has subsequently succeeded 3 days in a row. So my fix on the 22nd worked. Closing this.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_tests_fail_while_running_under_NFS.mdwn b/doc/projects/datalad/bugs-done/some_tests_fail_while_running_under_NFS.mdwn
new file mode 100644
index 0000000000..70fdb4df3d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_tests_fail_while_running_under_NFS.mdwn
@@ -0,0 +1,57 @@
+### Please describe the problem.
+
+4 out of 269 tests failed (4468.00s)
+
+hard to assess how critical they are... 
+
+### What steps will reproduce the problem?
+
+run git annex test
+
+### What version of git-annex are you using? On what operating system?
+
+6.20160307+gitgb095561-1~ndall+1
+
+### Please provide any additional information below.
+
+[Full log](http://www.onerussian.com/tmp/git-annex-tests-6.20160307+gitgb095561-1~ndall+1.log)
+
+[[!format sh """
+smaug:/mnt/nfs/scrap/datalad/test_annex
+$> grep -B5 FAIL git-annex-tests-6.20160307+gitgb095561-1~ndall+1.log
+    crypto:                                               OK (50.57s)
+    preferred content:                                    OK (20.36s)
+    add subdirs:                                          OK (8.97s)
+    addurl:                                               .t/tmprepo73/.git/annex/keys: removeDirectoryRecursive: unsatisfied constraints (Directory not empty)
+sleeping 10 seconds and will retry directory cleanup
+FAIL
+--
+   293ed4c..c16b350  git-annex -> synced/git-annex
+   dd272eb..ffe1721  master -> synced/master
+OK (11.64s)
+    addurl:                                               .t/tmprepo73/.git/annex/keys/.nfs0000000009a305870000020e: removeDirectoryRecursive: resource busy (Device or resource busy)
+sleeping 10 seconds and will retry directory cleanup
+FAIL
+--
+   0993b09..c09ddc4  git-annex -> synced/git-annex
+   a823824..520f58c  master -> synced/master
+OK (13.67s)
+    addurl:                                               .t/tmprepo73/.git/annex/keys/.nfs0000000009a305870000020e: removeDirectoryRecursive: resource busy (Device or resource busy)
+sleeping 10 seconds and will retry directory cleanup
+FAIL
+--
+OK (14.59s)
+    addurl:                                               On branch master
+nothing to commit, working directory clean
+.t/tmprepo73/.git/annex/keys/.nfs0000000009a305870000020e: removeDirectoryRecursive: resource busy (Device or resource busy)
+sleeping 10 seconds and will retry directory cleanup
+FAIL
+
+
+# End of transcript or log.
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[dup|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/some_tests_fail_while_running_under_NFS/comment_1_8e0f72f633ec79bd373b009046ab66b7._comment b/doc/projects/datalad/bugs-done/some_tests_fail_while_running_under_NFS/comment_1_8e0f72f633ec79bd373b009046ab66b7._comment
new file mode 100644
index 0000000000..f52704041d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_tests_fail_while_running_under_NFS/comment_1_8e0f72f633ec79bd373b009046ab66b7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-03-09T17:15:13Z"
+ content="""
+This is all down to those nfs lock files, so finding a way to probe for an
+NFS system and auto-enable pidlock is the best way to fix this.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_tests_fail_while_running_under_NFS/comment_2_ee9cc13cf34432be00a906bf65cebafd._comment b/doc/projects/datalad/bugs-done/some_tests_fail_while_running_under_NFS/comment_2_ee9cc13cf34432be00a906bf65cebafd._comment
new file mode 100644
index 0000000000..229b9cbde4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_tests_fail_while_running_under_NFS/comment_2_ee9cc13cf34432be00a906bf65cebafd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-06-24T16:49:26Z"
+ content="""
+It seems to me that the only way this is going to be fixed 
+is if
+<<https://git-annex.branchable.com/bugs/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/>>
+is fixed, so let's close this bug as a dup of that one.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry.mdwn b/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry.mdwn
new file mode 100644
index 0000000000..a7f723bf67
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry.mdwn
@@ -0,0 +1,35 @@
+### Please describe the problem.
+
+I quickly searched but could not find exactly the same issue, so filing it new, but feel welcome to refer/close if it is already filed.
+
+Upon some transfers between local hosts, I am getting some files failing to be transferred upon initial run, and I need to rerun `get` to get them.  Could may be `annex get` internally retry a few times (I think the same is done for http already) upon transfer failure?
+
+[[!format sh """
+
+(git)smaug:/mnt/btrfs/datasets/datalad/crawl/dbic/QA[master]git
+$> git annex get -J4 --from=origin --all --json 2>&1 | tee /tmp/qa-get.log
+{"command":"get","note":"from origin...\nchecksum...","success":true,"key":"SHA256E-s9037046--92b3f24faf39b0c3710311fa57a614bdc24f998e5a4f7c8b33063d4ef01a0aaf.nii.gz","file":null}
+...
+git-annex: get: 1 failed
+git annex get -J4 --from=origin --all --json 2>&1  87.01s user 22.58s system 73% cpu 2:29.82 total
+tee /tmp/qa-get.log  0.00s user 0.02s system 0% cpu 2:29.82 total
+
+$> grep -v -e 'success":true' /tmp/qa-get.log 
+{"command":"get","note":"from origin...\nrsync failed -- run git annex again to resume file transfer","success":false,"key":"SHA256E-s44080906--a534bdaa5b4143fb64135aa83d86cf4d4f29d2c23b7f2e7e1d72a811835f2bb8.nii.gz","file":null}
+git-annex: get: 1 failed
+
+$> git annex get --key SHA256E-s44080906--a534bdaa5b4143fb64135aa83d86cf4d4f29d2c23b7f2e7e1d72a811835f2bb8.nii.gz --from origin
+get SHA256E-s44080906--a534bdaa5b4143fb64135aa83d86cf4d4f29d2c23b7f2e7e1d72a811835f2bb8.nii.gz (from origin...) 
+(checksum...) ok                  
+(recording state in git...)
+
+$> git annex version                  
+git-annex version: 6.20180807+git291-g549114118-1~ndall+1
+
+"""]]
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[closing|done]] per my comment --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_1_b762aa4a31f2153c00988d185ce5efbe._comment b/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_1_b762aa4a31f2153c00988d185ce5efbe._comment
new file mode 100644
index 0000000000..40d8ae750e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_1_b762aa4a31f2153c00988d185ce5efbe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-09-25T17:05:13Z"
+ content="""
+You neglected to show the actual error message from git-annex or rsync or
+whatever actually failed. I can't do anything with this.
+
+annex.retry affects all transfers, not only http.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_2_7d5c57bf17659769d9cf4d56774ba67e._comment b/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_2_7d5c57bf17659769d9cf4d56774ba67e._comment
new file mode 100644
index 0000000000..1398291d87
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_2_7d5c57bf17659769d9cf4d56774ba67e._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-09-25T22:36:43Z"
+ content="""
+
+> You neglected to show the actual error message from git-annex or rsync or whatever actually failed. I can't do anything with this.
+
+oh lucky me still having that file where I dumped all the output and grepped in the original report to not flood the page: http://www.onerussian.com/tmp/qa-get.log
+but hey -- there were no actual error message as far as I see it:
+
+[[!format sh \"\"\"
+$> grep -v '^{' /tmp/qa-get.log
+git-annex: get: 1 failed
+\"\"\"]]
+
+so may be if annex included the message from git-annex/rsync in its record:
+
+[[!format sh \"\"\"
+$> grep rsync qa-get.log
+{\"command\":\"get\",\"note\":\"from origin...\nrsync failed -- run git annex again to resume file transfer\",\"success\":false,\"key\":\"SHA256E-s44080906--a534bdaa5b4143fb64135aa83d86cf4d4f29d2c23b7f2e7e1d72a811835f2bb8.nii.gz\",\"file\":null}
+\"\"\"]]
+
+we both would be happier...
+
+> annex.retry affects all transfers, not only http.
+
+that is great -- so why it didn't retry here?  is default `0`, i.e. no retries?
+
+[[!format sh \"\"\"
+$> grep a534bdaa5b4143fb64135aa83d86cf4d4f29d2c23b7f2e7e1d72a811835f2bb8 qa-get.log 
+{\"command\":\"get\",\"note\":\"from origin...\nrsync failed -- run git annex again to resume file transfer\",\"success\":false,\"key\":\"SHA256E-s44080906--a534bdaa5b4143fb64135aa83d86cf4d4f29d2c23b7f2e7e1d72a811835f2bb8.nii.gz\",\"file\":null}
+\"\"\"]]
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_3_8a5ceb261338ab55b5c8c2daa56d04ce._comment b/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_3_8a5ceb261338ab55b5c8c2daa56d04ce._comment
new file mode 100644
index 0000000000..cf16623732
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_3_8a5ceb261338ab55b5c8c2daa56d04ce._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-10-03T19:35:31Z"
+ content="""
+Yes, default is 0 retries.
+
+git-annex should pass rsync's stderr through to its stderr.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_4_bedf66f7257511d1d245ff0c6bcfe5f6._comment b/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_4_bedf66f7257511d1d245ff0c6bcfe5f6._comment
new file mode 100644
index 0000000000..17cba34297
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/some_transfers_for_get_-J4_fail_over_ssh__47__rsync_and_require_retry/comment_4_bedf66f7257511d1d245ff0c6bcfe5f6._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-04-15T18:00:35Z"
+ content="""
+Whatever caused rsync to fail like this, git-annex no longer even uses
+rsync in gets from git remotes, unless the remote has a git-annex-shell
+older than 6.20180316. Ie, debian oldstable.
+
+So it seems unlikely that whatever the problem was is still relevant.
+There is not enough information here to say anything more. I'm gonna close
+this, but do repopen it if it comes back.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__.mdwn b/doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__.mdwn
new file mode 100644
index 0000000000..95220dc79b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__.mdwn
@@ -0,0 +1,38 @@
+### Please describe the problem.
+
+Today's build testing of git-annex failed on NFS: https://github.com/datalad/git-annex/runs/6058121542?check_suite_focus=true  with 
+
+```
+$> grep -3 FAIL 29.txt
+2022-04-18T03:22:09.5662927Z       init:                                   OK (0.37s)
+2022-04-18T03:22:09.5663500Z       add:                                    OK (1.07s)
+2022-04-18T03:22:09.5663802Z     addurl:                                   OK (1.17s)
+2022-04-18T03:22:09.5664100Z     crypto:                                   FAIL
+2022-04-18T03:22:09.5665565Z       Exception: /tmp/gpgtmpSgOEyq/2/S.gpg-agent.ssh: removeDirectoryRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:getSymbolicLinkStatus: does not exist (No such file or directory)
+2022-04-18T03:22:09.5666237Z     directory remote:                         OK (2.14s)
+2022-04-18T03:22:09.5666709Z     uninit (in git-annex branch):             OK (0.79s)
+```
+
+
+it seems to start happening (sometimes, not always) only recently (no FAILs in month 03):
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2022/04[master]git
+$> git grep 'crypto: *FAIL' -- cron*
+cron-20220405/build-ubuntu.yaml-646-67bae4b2-failed/4_test-annex (nfs-home, ubuntu-latest).txt:2022-04-05T03:05:37.7854544Z     crypto:                                   FAIL
+cron-20220405/build-ubuntu.yaml-646-67bae4b2-failed/test-annex (nfs-home, ubuntu-latest)/7_Run tests.txt:2022-04-05T03:05:37.7854508Z     crypto:                                   FAIL
+cron-20220408/build-ubuntu.yaml-652-3e846b0e-failed/4_test-annex (nfs-home, ubuntu-latest).txt:2022-04-08T03:18:02.5454711Z     crypto:                                   FAIL
+cron-20220408/build-ubuntu.yaml-652-3e846b0e-failed/test-annex (nfs-home, ubuntu-latest)/7_Run tests.txt:2022-04-08T03:18:02.5454672Z     crypto:                                   FAIL
+cron-20220411/build-ubuntu.yaml-658-333680cf-failed/4_test-annex (nfs-home, ubuntu-latest).txt:2022-04-11T03:23:00.6339271Z     crypto:                                   FAIL
+cron-20220411/build-ubuntu.yaml-658-333680cf-failed/test-annex (nfs-home, ubuntu-latest)/7_Run tests.txt:2022-04-11T03:23:00.6339267Z     crypto:                                   FAIL
+cron-20220414/build-ubuntu.yaml-661-0346631d-failed/4_test-annex (nfs-home, ubuntu-latest).txt:2022-04-14T03:17:48.5929540Z     crypto:                                   FAIL
+cron-20220414/build-ubuntu.yaml-661-0346631d-failed/test-annex (nfs-home, ubuntu-latest)/7_Run tests.txt:2022-04-14T03:17:48.5929536Z     crypto:                                   FAIL
+cron-20220418/build-ubuntu.yaml-665-0346631d-failed/4_test-annex (nfs-home, ubuntu-latest).txt:2022-04-18T03:22:09.5664100Z     crypto:                                   FAIL
+cron-20220418/build-ubuntu.yaml-665-0346631d-failed/test-annex (nfs-home, ubuntu-latest)/7_Run tests.txt:2022-04-18T03:22:09.5664096Z     crypto:                                   FAIL
+```
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]] 
diff --git a/doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__/comment_1_9909507b034e25db04e5407717fab315._comment b/doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__/comment_1_9909507b034e25db04e5407717fab315._comment
new file mode 100644
index 0000000000..4cd1b50d8a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__/comment_1_9909507b034e25db04e5407717fab315._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2022-04-19T14:40:17Z"
+ content="""
+noticed something related to only these runs seems to me -- an odd/confusing message:
+
+```
+cron-20220405/build-ubuntu.yaml-646-67bae4b2-failed/4_test-annex (nfs-home, ubuntu-latest).txt:2022-04-05T03:10:55.6974698Z   Test subprocesses exited with unexpected exit codes: [ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess]
+```
+
+didn't do count -- may be it is \"unexpected\" in that there is 1 missing ExitSuccess? or what is unexpected otherwise?  A cleaner report would be appreciated.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__/comment_2_a254c4de61a74bf314eb33e301c199f0._comment b/doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__/comment_2_a254c4de61a74bf314eb33e301c199f0._comment
new file mode 100644
index 0000000000..547388a6e3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__/comment_2_a254c4de61a74bf314eb33e301c199f0._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-04-19T16:49:26Z"
+ content="""
+That is a *very* strange message! Because the list is all
+ExitSuccess, but before the code to check that message can run,
+it checks that the list is not `all (== ExitSuccess)`
+
+It should not be possible for a list without an ExitFailure in it to
+get past that check. And it certainly does not normally.
+
+And looking at the log, one of the tests *did* fail:
+
+	    crypto:                                   FAIL
+	      Exception: /tmp/gpgtmpSgOEyq/2/S.gpg-agent.ssh: removeDirectoryRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:getSymbolicLinkStatus: does not exist (No such file or directory)
+
+So there must have been an `ExitFailure 1` in the list, even though it
+somehow ends up displaying as containing all `ExitSuccess`. Almost as if
+the content of the list changed. But it cannot, barring a bug in the
+haskell runtime..
+
+As far as the cause of that failure, it should be fixable by using 
+removePathForcibly rather than removeDirectoryRecursive in removeTmpDir.
+I've made that change.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__/comment_3_89e9d65073a58188024290a2b32fda2e._comment b/doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__/comment_3_89e9d65073a58188024290a2b32fda2e._comment
new file mode 100644
index 0000000000..4467555517
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/sporadic___40____63____41___fail_of_crypto_test__63__/comment_3_89e9d65073a58188024290a2b32fda2e._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-05-02T17:57:21Z"
+ content="""
+Noticed this:
+	
+	Test subprocesses exited with unexpected exit codes: [ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitFailure 1,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess,ExitSuccess]
+
+In this test run: <https://github.com/datalad/git-annex/runs/6251550145?check_suite_focus=true>
+
+There was a test failure indeed there, which was another bug that
+is now fixed. But notice the `ExitFailure 1` in the list of exit codes.
+
+The code around handing exit codes has changed from before, and still had a bug,
+because a list with `ExitFailure 1` will cause that message, incorrectly.
+(Now fixed that.)
+
+But, this seems to show that it's no longer hiding the actual problem
+exit code when a test fails, which it was somehow apparently doing before.
+So I think this bug can be closed as fully fixed now.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/standalone_build_is_slightly_out_of_date.mdwn b/doc/projects/datalad/bugs-done/standalone_build_is_slightly_out_of_date.mdwn
new file mode 100644
index 0000000000..939d5b0251
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_build_is_slightly_out_of_date.mdwn
@@ -0,0 +1,48 @@
+
+[[!format sh """
+hopa:/tmp
+$> wget -S https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz
+--2018-09-25 09:25:06--  https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz
+Resolving downloads.kitenet.net (downloads.kitenet.net)... 66.228.36.95, 2600:3c03::f03c:91ff:fe73:b0d2
+Connecting to downloads.kitenet.net (downloads.kitenet.net)|66.228.36.95|:443... connected.
+HTTP request sent, awaiting response... 
+  HTTP/1.1 200 OK
+  Date: Tue, 25 Sep 2018 13:25:07 GMT
+  Server: Apache/2.4.34 (Debian)
+  Last-Modified: Thu, 13 Sep 2018 20:29:04 GMT
+  ETag: "3e30e83-575c68ee3f927"
+  Accept-Ranges: bytes
+  Content-Length: 65212035
+  Keep-Alive: timeout=5, max=100
+  Connection: Keep-Alive
+  Content-Type: application/x-gzip
+Length: 65212035 (62M) [application/x-gzip]
+Saving to: ‘git-annex-standalone-amd64.tar.gz’
+
+git-annex-standalone-amd64. 100%[===========================================>]  62.19M  1.77MB/s    in 28s     
+
+2018-09-25 09:25:35 (2.20 MB/s) - ‘git-annex-standalone-amd64.tar.gz’ saved [65212035/65212035]
+
+
+$> tar -xzf git-annex-standalone-amd64.tar.gz                                                    
+
+$> git-annex.linux/git-annex version         
+git-annex version: 6.20180808-ga1327779a
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.13 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+
+$> git -C ~/proj/git-annex describe --contains 6.20180808-ga1327779a
+6.20180913~3^2~1
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> I see no reason to have this open half a year and many many releases later, so
+> [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/standalone_build_is_slightly_out_of_date/comment_1_349f2d8f6ef0fddcfe576fc08b3cccb6._comment b/doc/projects/datalad/bugs-done/standalone_build_is_slightly_out_of_date/comment_1_349f2d8f6ef0fddcfe576fc08b3cccb6._comment
new file mode 100644
index 0000000000..3993949b2b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_build_is_slightly_out_of_date/comment_1_349f2d8f6ef0fddcfe576fc08b3cccb6._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-09-25T16:30:43Z"
+ content="""
+That's 6 commits back from the release tag for 6.20180913.
+The only code change missed is 
+[[!commit a7f0b99a3334fbc73e3cb53f37f5a065ee14b135]],
+which does not affect this build because this build bundles a newer version
+of git than the one that commit is dealing with.
+
+Without changing git-annex's build infrastructure to something that builds
+on released tags, a minor skew like this is to be expected, since I just
+ship the latest daily autobuilds with the release.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init.mdwn b/doc/projects/datalad/bugs-done/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init.mdwn
new file mode 100644
index 0000000000..4b10937e08
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init.mdwn
@@ -0,0 +1,19 @@
+### Please describe the problem.
+
+Currently if I using standalone annex builds mere 'annex init' immediately rushes to generate .ssh/git-annex-{shell,wrapper} helpers.  I would really prefer to keep ~/.ssh untouched by any magic from the tools which presumably unrelated to ssh.  Moreover it leads to failures such as 
+
+/usr/lib/git-annex.linux/runshell: 67: /usr/lib/git-annex.linux/runshell: cannot create /.ssh/git-annex-wrapper: Directory nonexistent
+
+happen if HOME was overridden (e.g. for testing etc) and I have no intent to use annex as an assistant etc.
+
+Originally described in http://git-annex.branchable.com/devblog/day_155__missing_bits/ as a solution to overcome problems with assistant's server operation from standalone builds.  Why those couldn't be installed alongside with git-annex wrapper? (actually there is also git-annex-shell at least in the Debian standalone packages)
+
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150916+gitg79661ef-1~ndall+1
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+Since packaged version suggestively (I think I did check) resolved the issue, marking it as [[done]]
diff --git a/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs.mdwn b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs.mdwn
new file mode 100644
index 0000000000..e8cb4517f1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+Originally reported against datalad [#4976](https://github.com/datalad/datalad/issues/4976). Ran into it again and decided to reproduce by simply trying to make `git config` in parallel (they should not crash, right?) and it brings to the same problem reported
+
+```shell
+#!/bin/bash
+
+set -eu
+export PS4='> '
+set -x
+cd "$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)"
+
+which git
+grep runshell `which git`
+
+git init
+git annex init
+
+for s in {1..30}; do
+    git config annex.version &
+done
+wait
+
+``` 
+
+I also wonder if it is possible to avoid dealing with locales upon **every** invocation of git/git-annex? couldn't it be done just once e.g. per installed annex? (sorry if we had this discussion already, but it feels not yet resolved optimally).
+
+### What version of git-annex are you using? On what operating system?
+
+`8.20200908-gcfc74c2f4`
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_1_343ac13424b0b65db2094c595bcabd7f._comment b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_1_343ac13424b0b65db2094c595bcabd7f._comment
new file mode 100644
index 0000000000..6d8e1f5652
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_1_343ac13424b0b65db2094c595bcabd7f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="standalone build"
+ date="2020-10-04T15:45:13Z"
+ content="""
+Just to note, the standalone build currently ends up being used for [many conda installs](https://anaconda.org/conda-forge/git-annex/files), so any fixes for it would be great.
+
+Is there a list somewhere of currently known issues affecting the standalone build but not the standard build?  This would be useful in helping people decide between a more recent standalone build or an older standard one.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_2_c43bb7ffa7b900f5824b4495a6a82d0e._comment b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_2_c43bb7ffa7b900f5824b4495a6a82d0e._comment
new file mode 100644
index 0000000000..3cca5ec64a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_2_c43bb7ffa7b900f5824b4495a6a82d0e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-10-05T16:43:02Z"
+ content="""
+Fixed the rm to not redirect errors to stdout. Traced back to a8a0f7fc58
+which involved a case where the rm was failing due to perms, so the intent
+must have been to also send stdout to /dev/null, but that was omitted then.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_3_57681d5959095d9a3e6ea9e4d0679c85._comment b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_3_57681d5959095d9a3e6ea9e4d0679c85._comment
new file mode 100644
index 0000000000..206e3b1ce3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_3_57681d5959095d9a3e6ea9e4d0679c85._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-10-05T16:46:25Z"
+ content="""
+I thought you were mostly using git-annex-standalone.deb @yoh,
+and that, I think sets `GIT_ANNEX_PACKAGE_INSTALL` which prevents doing
+anything with locales.
+
+It does a minumum amount of work every time to get the locales
+available, which is necessary because the user might have deleted the cache
+since a previous run. If the cached files are available, it does not do
+anything expensive. Clearing the old cache, which is what happened to fail
+here, needs to be done at some point, and only happens once per old cache
+directory, so I see no way to improve performance of that.
+
+Anyway, something needs to be done to make runshell's updating of this
+stuff idempotent, clearly.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_4_5c2c6003b45d78b9e0bee95f5a12c48c._comment b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_4_5c2c6003b45d78b9e0bee95f5a12c48c._comment
new file mode 100644
index 0000000000..540552786d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_4_5c2c6003b45d78b9e0bee95f5a12c48c._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-10-05T17:04:45Z"
+ content="""
+Hmm, that rm -rf is idempotent itself once the stderr is hidden;
+if a race causes one rm to fail the other one will probably succeed;
+if both manage to fail it ignores the nonzero exit code and, 
+the next run will clean up after it by running it again. AFAICS the cache
+eventually gets cleaned up in all circumstances.
+
+	rm: cannot remove '/home/yoh/.cache/git-annex/locales/bb375eb6ec0d2706f1723307f068911a': Directory not empty
+
+I think what happened there is, the first process created
+that cache directory, and was in the middle of writing/overwriting the
+base file when the second process ran. So the second process sees what
+looks like a cache directory with a missing or empty base file, so it
+decides to clean it up. In the meantime the first process has written
+base and other files and so the rm fails. Also, the first process may
+succeed and end up running git-annex with some locale files missing
+(if the rm happened to delete those), resulting in incompatable
+system locales being used.
+
+So, it ought to defer cleaning up old caches until after it's made sure its
+current cache is all set up. Then that race goes away.
+
+But, there's a problem with this, that comes right after the main cache
+cleanup:
+
+	# If the locale cache for this bundle is out of date, refresh it.
+	if [ -e "$LOCPATH/buildid" ] && ! cmp "$LOCPATH/buildid" "$base/buildid" >/dev/null 2>&1 ; then
+		rm -rf "$LOCPATH"
+	fi
+
+That runs if the git-annex.linux directory gets overwritten with a new version,
+so the cache is the same. And it's also prone to similar races. 
+I think, to fix this, it probably needs to use the buildid in the LOCPATH.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_5_57834ef04f206e1b351b36ba32ce447f._comment b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_5_57834ef04f206e1b351b36ba32ce447f._comment
new file mode 100644
index 0000000000..dc491776c1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_5_57834ef04f206e1b351b36ba32ce447f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-10-05T18:31:26Z"
+ content="""
+The test case works a bit inconsistently, I had the best luck 
+first removing ~/.cache/git-annex/locales/ and the running the test case 
+twice in a row, which made it reliably reproduce that error on the second
+run.
+
+After the above fixes, the test case no longer reproduces the problem.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_6_9ee31c8d92178b38bbc920df395ee284._comment b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_6_9ee31c8d92178b38bbc920df395ee284._comment
new file mode 100644
index 0000000000..6f10c0776e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_6_9ee31c8d92178b38bbc920df395ee284._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-10-05T18:37:39Z"
+ content="""
+@Ilya_Shlyakhter there is no separate bug tracker for runshell,
+but I don't know of any other open bugs involving it either.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_7_2abc6e368033bc636debbcd83dd2b4ed._comment b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_7_2abc6e368033bc636debbcd83dd2b4ed._comment
new file mode 100644
index 0000000000..f43d103a66
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_7_2abc6e368033bc636debbcd83dd2b4ed._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="FTR"
+ date="2020-10-06T00:04:36Z"
+ content="""
+Thank you Joey! FTR (if I located properly): fixed in [8.20200908-163-gd74d97896](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=d74d9789688fde1151ece6a751d1c549af87de84)
+
+If for what \"flavor\" of git-annex build I use -- every day is not like another these days ;)  But yeah -- tend to use a year old neurodebian built .deb when I can afford and do not feel adventurous, but I think in these cases was just using a standalone build indeed.
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__.mdwn b/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__.mdwn
new file mode 100644
index 0000000000..03e6a5fd90
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+
+I did manage to reach the rabbit hole bottom in the troubleshooting of my unique inability to use argcomplete for shell completion in datalad: [datalad issue](https://github.com/datalad/datalad/issues/4538) [argcomplete issue](https://github.com/kislyuk/argcomplete/issues/303)
+
+And the bottom looked liked:
+
+```
+$> IFS=$'\013' /usr/lib/git-annex.linux/git-annex version
+[1]    1040489 segmentation fault (core dumped)  IFS=$'\013' /usr/lib/git-annex.linux/git-annex version
+
+$> IFS=$'\013' /usr/lib/git-annex.linux/git version      
+[1]    1040532 segmentation fault (core dumped)  IFS=$'\013' /usr/lib/git-annex.linux/git version
+
+```
+
+whenever stock git is ok
+
+```
+$> IFS=$'\013' /usr/bin/git version  
+git version 2.27.0
+```
+
+most likely it is just a matter of sanitizing this variable in `runshell` or alike.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_1_ab8017246c0075b731c7d31235672c01._comment b/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_1_ab8017246c0075b731c7d31235672c01._comment
new file mode 100644
index 0000000000..a8cccc075d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_1_ab8017246c0075b731c7d31235672c01._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2020-07-24T15:22:36Z"
+ content="""
+- unsetting `IFS` at top of `runshell` \"fixes\" it but IMHO would not be proper since shell completion etc tools relying on passing it into calls of git etc would be effected.
+
+- 
+
+<details><summary>`bash` somehow seems to be also avoiding the segfault:</summary>
+
+```
+$> IFS=$'\013' dash /usr/lib/git-annex.linux/git-annex version
+[2]    1059479 segmentation fault (core dumped)  IFS=$'\013' dash /usr/lib/git-annex.linux/git-annex version
+1 9812 ->139 [1].....................................:Fri 24 Jul 2020 11:09:07 AM EDT:.
+(git)lena:~/proj/misc/git[master]git
+$> IFS=$'\013' posh /usr/lib/git-annex.linux/git-annex version    
+[2]    1059547 segmentation fault (core dumped)  IFS=$'\013' posh /usr/lib/git-annex.linux/git-annex version
+1 9813 ->139 [1].....................................:Fri 24 Jul 2020 11:09:12 AM EDT:.
+(git)lena:~/proj/misc/git[master]git
+$> IFS=$'\013' bash /usr/lib/git-annex.linux/git-annex version    
+git-annex version: 8.20200617+git192-g5849bd634-1~ndall+1
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+```
+</details>
+
+- most likely `runshell` (etc) shims within standalone need to sanitize IFS only when they invoke some tools they use and which rely on IFS, but pass IFS as is into the actual call.  It seems that the following patch does the trick
+
+```diff
+$> diff -Naur /home/yoh/proj/git-annex/standalone/linux/skel/runshell /usr/lib/git-annex.linux/runshell
+--- /home/yoh/proj/git-annex/standalone/linux/skel/runshell	2020-03-08 10:37:15.462465282 -0400
++++ /usr/lib/git-annex.linux/runshell	2020-07-24 11:19:17.707935260 -0400
+@@ -4,6 +4,9 @@
+ 
+ set -e
+ 
++orig_IFS=\"${IFS:-}\"
++unset IFS
++
+ os=\"$(uname -o 2>/dev/null || true)\"
+ base=\"$(dirname \"$0\")\"
+ 
+@@ -238,6 +241,11 @@
+ 	cmd=sh
+ fi
+ 
++if [ -n \"${orig_IFS}\" ]; then
++	IFS=\"${orig_IFS}\"
++	export IFS
++fi
++
+ if [ -z \"$tbase\" ]; then
+ 	if [ \"$useproot\" ]; then
+ 		exec proot \"$cmd\" \"$@\"
+```
+
+and it seems that git shell completion then still works fine
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_2_2b7afff24ba025fe3e272ff6f607eadf._comment b/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_2_2b7afff24ba025fe3e272ff6f607eadf._comment
new file mode 100644
index 0000000000..fa6e1d5b43
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_2_2b7afff24ba025fe3e272ff6f607eadf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-07-24T18:34:37Z"
+ content="""
+Hmm, that patch looks pretty good, but contains a bashism in the `${IFS:-}`
+and I don't actually understand what the point of that is, if seems to
+say it should expand to "" if IFS is not set, but it would expand to that
+anyway.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_3_ba1b34111d47d58517ea64f537214e98._comment b/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_3_ba1b34111d47d58517ea64f537214e98._comment
new file mode 100644
index 0000000000..1416c7cd12
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_3_ba1b34111d47d58517ea64f537214e98._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-07-24T18:43:32Z"
+ content="""
+Applied a version of the patch without the :- , although it seems the :- is
+not a bashism after all. It still makes no sense to me unless there's some
+other setting that might make the shell blow up when IFS isn't set.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_4_297b462c0344b8c7e5e113fdda3642f4._comment b/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_4_297b462c0344b8c7e5e113fdda3642f4._comment
new file mode 100644
index 0000000000..290de6e99f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/standalone_shim_is_segfaulting_if_IFS__61____36____39____92__013__39__/comment_4_297b462c0344b8c7e5e113fdda3642f4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2020-08-02T01:31:52Z"
+ content="""
+Oh, I see the reason for confusion: I usually as `set -u` to my scripts, so they would fail if variable is undefined. Indeed in the default mode of operation it isn't needed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows.mdwn b/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows.mdwn
new file mode 100644
index 0000000000..233b2cf6d5
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows.mdwn
@@ -0,0 +1,19 @@
+### Please describe the problem.
+Now we have github action which builds git-annex with libmagic support.  Unfortunately we had to "allow" `git annex test` to fail to proceed for now. Although it looks not that bad -- there is only one "test" which fails in various scenarios (to the total of `12 out of 704 tests failed (616.78s)`)
+
+```
+2020-10-22T18:50:07.2946875Z         storeKey when already present:                    FAIL (0.02s)
+2020-10-22T18:50:07.2948174Z           .\Command\TestRemote.hs:290:
+2020-10-22T18:50:07.2949772Z           failed
+```
+
+
+[full log copy](http://www.onerussian.com/tmp/git-annex-windows-failures-8.20201008-g577af1b.log)
+[link to original workflow run](https://github.com/datalad/datalad-extensions/runs/1294367575?check_suite_focus=true)
+
+When I ran `annex test` after installing that installer in a local Win 10 VM, I have got a lesser count (`8 out of 704 tests failed (1197.82s)`)  [full log](http://www.onerussian.com/tmp/git-annex-windows-failures-8.20201008-g577af1b-local.log)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> apparently [[fixed|done]]; followup if it reappears --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_1_7e089c436af03ffd8ad00dba45156a14._comment b/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_1_7e089c436af03ffd8ad00dba45156a14._comment
new file mode 100644
index 0000000000..66c94579fd
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_1_7e089c436af03ffd8ad00dba45156a14._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-10-23T16:50:31Z"
+ content="""
+So this is the testremote of the directory special remote, and the failing
+test tries to store content into the remote which already contains that
+content, an unusual edge case since git-annex normally knows when a remote
+has content and avoids resending it.
+
+Remote.Directory.finalizeStoreGeneric removes the old directory, and moves
+the new one into place. This is not the first time I've seen windows fail
+in such a situation, it seems that directory removals are not atomic, or
+don't really fully finish by the time the call returns, or something else
+like antivirus has a file open in the directory and so prevents deletion.
+Or something like that.
+
+This kind of thing is why I am not enthused about wasting any more time
+on supporting Windows. `rm -rf foo && mv bar foo` should not cause a bug report
+that requires me to dig out a VM and put in complex and expensive
+workarounds. The tar pit has no bottom.
+
+(Also, FWIW, git-annex test on the jenkins autobuilder always exploded from
+the very beginning, so was always || true, which is why the windows install
+page encourages windows users to test git-annex themselves.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_2_07f7881be6b0d29cdf64a7839b669b3e._comment b/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_2_07f7881be6b0d29cdf64a7839b669b3e._comment
new file mode 100644
index 0000000000..7c14b1e87f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_2_07f7881be6b0d29cdf64a7839b669b3e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-10-23T19:27:57Z"
+ content="""
+I've made it display whatever exception caused the test to fail, which
+should help pin down a bit more what the problem is.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_3_c570246b0484ed3694efff62feff968c._comment b/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_3_c570246b0484ed3694efff62feff968c._comment
new file mode 100644
index 0000000000..42ca756f52
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_3_c570246b0484ed3694efff62feff968c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-10-23T20:10:27Z"
+ content="""
+Turns out Remote.Directory was using removeDirGeneric everywhere it needed
+to remove a directory, except for in what I believe is failing here.
+And removeDirGeneric already has a workaround for some windows quirk in it.
+
+So I changed that to use it too. I don't know if that will fix the problem.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_4_2f701f39286c3a75a88407dcc6947081._comment b/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_4_2f701f39286c3a75a88407dcc6947081._comment
new file mode 100644
index 0000000000..a7ebabca4a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_4_2f701f39286c3a75a88407dcc6947081._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2020-10-24T01:21:09Z"
+ content="""
+Cool! We will see on the next cron run, I will check tomorrow
+"""]]
diff --git a/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_5_096b3af691987ef20281c87519a31935._comment b/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_5_096b3af691987ef20281c87519a31935._comment
new file mode 100644
index 0000000000..8d9c6f5e3d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/storeKey_when_already_present_failures_on_Windows/comment_5_096b3af691987ef20281c87519a31935._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2020-10-24T12:26:01Z"
+ content="""
+woohoo [last run](https://github.com/datalad/datalad-extensions/runs/1300942377?check_suite_focus=true) had ` All 704 tests passed (698.50s)` !!! so it might have fixed it.  I will submit a PR removing `|| true` to see if that sticks, and also will test locally
+"""]]
diff --git a/doc/projects/datalad/bugs-done/strips___95___from_extensions_in_E_backends__63__.mdwn b/doc/projects/datalad/bugs-done/strips___95___from_extensions_in_E_backends__63__.mdwn
new file mode 100644
index 0000000000..9031cd7269
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/strips___95___from_extensions_in_E_backends__63__.mdwn
@@ -0,0 +1,18 @@
+in my obscure case filename is ds001_R1.1.0_raw.tgz  and resultant extension annex takes for the E backend is .0raw.tgz which is formed from .0_raw.tgz with _ removed.  IMHO if _ is not expected in the extensions, the target extension then should have been just .tgz.  If it does expect/allow for _ in extension -- should have been .0_raw.tgz
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+$> f=ds001_R1.1.0_raw.tgz; rm -rf /tmp/repo1; mkdir /tmp/repo1; cd /tmp/repo1; git init; git annex init ; echo 123>$f; git annex add --backend MD5E $f; ls -ld $f              
+Initialized empty Git repository in /tmp/repo1/.git/
+init  ok
+(recording state in git...)
+add ds001_R1.1.0_raw.tgz ok
+(recording state in git...)
+lrwxrwxrwx 1 yoh yoh 126 May 25 14:27 ds001_R1.1.0_raw.tgz -> .git/annex/objects/g5/jW/MD5E-s4--ba1f2511fc30423bdbb183fe33f3dd0f.0raw.tgz/MD5E-s4--ba1f2511fc30423bdbb183fe33f3dd0f.0raw.tgz
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/test_fail_on_windows__58___permission_denied_.mdwn b/doc/projects/datalad/bugs-done/test_fail_on_windows__58___permission_denied_.mdwn
new file mode 100644
index 0000000000..61b2d459d2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/test_fail_on_windows__58___permission_denied_.mdwn
@@ -0,0 +1,32 @@
+### Please describe the problem.
+
+In the recent build of datalad/git-annex (8.20210803+git167-g608593fec) a test failed on Windows
+
+[CI log](https://github.com/datalad/git-annex/runs/3468868101?check_suite_focus=true)
+
+```
+    readonly:                                             FAIL (7.55s)
+      .\\Test\\Framework.hs:57:
+      drop vs readonly repo failed (transcript follows)
+      drop foo 
+      failed
+      git-annex: .git\annex\objects\6cd\e82\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77: DeleteFile "\\\\?\\C:\\Users\\runneradmin\\.t\\tmprepo3\\.git\\annex\\objects\\6cd\\e82\\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77": permission denied (Access is denied.)
+      drop: 1 failed
+    ignore deleted files:                                 OK (2.51s)
+```
+
+
+this is the first and only occurrence so far according to
+
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2021/08[master]
+$> git grep 'permission denied (Access is denied.)'
+cron-20210831/build-windows.yaml-369-69466103-failed/1_test-annex.txt:2021-08-31T03:47:09.0093593Z ...
+``` 
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] in [[!commit afdca0aff43747ce985a4caf655e8b3363dea370]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/test_fail_on_windows__58___permission_denied_/comment_1_9f46a99e5f570de2313a5521b58640b3._comment b/doc/projects/datalad/bugs-done/test_fail_on_windows__58___permission_denied_/comment_1_9f46a99e5f570de2313a5521b58640b3._comment
new file mode 100644
index 0000000000..7c9f574816
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/test_fail_on_windows__58___permission_denied_/comment_1_9f46a99e5f570de2313a5521b58640b3._comment
@@ -0,0 +1,78 @@
+[[!comment format=mdwn
+ username="jkniiv@b330fc3a602d36a37a67b2a2d99d4bed3bb653cb"
+ nickname="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/419f2eee8b0c37256488fabcc2737ff2"
+ subject="comment 1"
+ date="2021-08-31T20:47:24Z"
+ content="""
+At my end I ran the `readonly` test with the `--keep-failures` flags and found out the following:
+
+[[!format sh \"\"\"
+jkniiv@AINESIS MINGW64 /c/annx
+$ ./git-annex test -p \"Unit Tests v8 adjusted unlocked branch.readonly\" --keep-failures
+Tests
+  Unit Tests v8 adjusted unlocked branch
+    readonly: Init Tests
+  init: OK (4.00s)
+  add:  OK (5.78s)
+
+All 2 tests passed (9.77s)
+** Preserving repo for failure analysis in .t\tmprepo1
+** Preserving repo for failure analysis in .t\tmprepo0
+FAIL (16.98s)
+      .\\Test\\Framework.hs:57:
+      drop vs readonly repo failed (transcript follows)
+      drop foo
+      failed
+      git-annex: .git\annex\objects\6cd\e82\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77: DeleteFile \"\\\\?\\C:\\annx\\.t\\tmprepo1\\.git\\annex\\objects\\6cd\\e82\\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\": permission denied (Käyttö estetty.)
+      drop: 1 failed
+
+1 out of 1 tests failed (26.78s)
+  (Failures above could be due to a bug in git-annex, or an incompatibility
+   with utilities, such as git, installed on this system.)
+
+jkniiv@AINESIS MINGW64 /c/annx
+$ cd .t/tmprepo1
+
+jkniiv@AINESIS MINGW64 /c/annx/.t/tmprepo1 (adjusted/master(unlocked))
+$ ls -ld .git/annex/objects/6cd/e82/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+drwxr-xr-x 1 jkniiv 197121 0 Aug 31 23:08 .git/annex/objects/6cd/e82/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77/
+
+jkniiv@AINESIS MINGW64 /c/annx/.t/tmprepo1 (adjusted/master(unlocked))
+$ ls -ld .git/annex/objects/6cd/e82/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+-r--r--r-- 1 jkniiv 197121 20 Aug 31 23:08 .git/annex/objects/6cd/e82/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+
+jkniiv@AINESIS MINGW64 /c/annx/.t/tmprepo1 (adjusted/master(unlocked))
+$ chmod -Rv +w .git/annex/objects
+mode of '.git/annex/objects' retained as 0755 (rwxr-xr-x)
+mode of '.git/annex/objects/6cd' retained as 0755 (rwxr-xr-x)
+mode of '.git/annex/objects/6cd/e82' retained as 0755 (rwxr-xr-x)
+mode of '.git/annex/objects/6cd/e82/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77' retained as 0755 (rwxr-xr-x)
+mode of '.git/annex/objects/6cd/e82/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77' changed from 0444 (r--r--r--) to 0644 (rw-r--r--)
+
+jkniiv@AINESIS MINGW64 /c/annx/.t/tmprepo1 (adjusted/master(unlocked))
+$ ../../git-annex drop foo
+drop foo ok
+(recording state in git...)
+
+jkniiv@AINESIS MINGW64 /c/annx/.t/tmprepo1 (adjusted/master(unlocked))
+$ ls -ld ../tmprepo0/.git/annex/objects/6cd/e82/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+drwxr-xr-x 1 jkniiv 197121 0 Aug 31 23:15 ../tmprepo0/.git/annex/objects/6cd/e82/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77/
+
+jkniiv@AINESIS MINGW64 /c/annx/.t/tmprepo1 (adjusted/master(unlocked))
+$ ls -ld ../tmprepo0/.git/annex/objects/6cd/e82/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+-r--r--r-- 1 jkniiv 197121 20 Aug 31 23:07 ../tmprepo0/.git/annex/objects/6cd/e82/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+
+\"\"\"]]
+
+So it looks like the readonly status of the annex object got copied between r1 (`tmprepo0`) and r2
+(`temprepo1`) at the point of `get` and that prevented the removal of the file during `drop`.
+
+(Btw. I found out that in Msys2/MinGW what is represented as the POSIX readonly mode bits seems
+to be really represented by the readonly file attribute and not as readonly permissions/ACLs
+on the file. At least that seems to be the default setting. Cygwin on the other hand defaults
+to mapping mode bits to ACLs in a rather complex fashion. All of this are just some details
+that lie behind what calling out to an external `chmod` binary entails on Windows both above
+in my Git Bash session and in git-annex' unit test `test_readonly`.)
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/testremote_breeds_way_too_many_instances_of_the_externals_remote.mdwn b/doc/projects/datalad/bugs-done/testremote_breeds_way_too_many_instances_of_the_externals_remote.mdwn
new file mode 100644
index 0000000000..14af186c6f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/testremote_breeds_way_too_many_instances_of_the_externals_remote.mdwn
@@ -0,0 +1,221 @@
+### Please describe the problem.
+
+See more information and the initial cause (failing testing on travis with recent git annex) at [datalad/issues/4643](https://github.com/datalad/datalad/issues/4643)
+
+
+In brief, using git annex 8.20200617-g02765b8 resulted in the following pstree with a simple [custom special remote](https://github.com/datalad/datalad/pull/3727):
+
+```
+$>  pstree -l -a --compact-not -T -p 625823 | nl       
+     1	git,625823 annex testremote go
+     2	  `-git-annex,625824 testremote go
+     3	      |-git,625833 --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+     4	      |-git,625834 --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+     5	      |-(git-annex-remot,625841)
+     6	      |-(git-annex-remot,625847)
+     7	      |-git-annex-remot,625853 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+     8	      |-(git-annex-remot,625869)
+     9	      |-(git-annex-remot,625875)
+    10	      |-git-annex-remot,625881 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    11	      |-(git-annex-remot,625895)
+    12	      |-(git-annex-remot,625901)
+    13	      |-git-annex-remot,625908 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    14	      |-(git-annex-remot,625955)
+    15	      |-(git-annex-remot,625961)
+    16	      |-git-annex-remot,625967 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    17	      |-(git-annex-remot,625981)
+    18	      |-(git-annex-remot,625987)
+    19	      |-git-annex-remot,625993 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    20	      |-(git-annex-remot,626013)
+    21	      |-(git-annex-remot,626019)
+    22	      |-git-annex-remot,626025 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    23	      |-(git-annex-remot,626039)
+    24	      |-(git-annex-remot,626045)
+    25	      |-git-annex-remot,626053 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    26	      |-(git-annex-remot,626075)
+    27	      |-(git-annex-remot,626081)
+    28	      |-(git-annex-remot,626087)
+    29	      |-(git-annex-remot,626096)
+    30	      |-git-annex-remot,626102 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    31	      |-(git-annex-remot,626124)
+    32	      |-(git-annex-remot,626130)
+    33	      |-(git-annex-remot,626136)
+    34	      |-(git-annex-remot,626142)
+    35	      |-git-annex-remot,626148 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    36	      |-(git-annex-remot,626170)
+    37	      |-(git-annex-remot,626176)
+    38	      |-(git-annex-remot,626185)
+    39	      |-(git-annex-remot,626191)
+    40	      |-git-annex-remot,626198 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    41	      |-(git-annex-remot,626220)
+    42	      |-(git-annex-remot,626226)
+    43	      |-(git-annex-remot,626232)
+    44	      |-(git-annex-remot,626238)
+    45	      |-git-annex-remot,626244 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    46	      |-(git-annex-remot,626276)
+    47	      |-(git-annex-remot,626282)
+    48	      |-git-annex-remot,626288 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    49	      |-(git-annex-remot,626302)
+    50	      |-(git-annex-remot,626309)
+    51	      |-git-annex-remot,626315 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    52	      |-(git-annex-remot,626333)
+    53	      |-(git-annex-remot,626340)
+    54	      |-git-annex-remot,626346 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    55	      |-(git-annex-remot,626360)
+    56	      |-(git-annex-remot,626366)
+    57	      |-git-annex-remot,626372 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    58	      |-(git-annex-remot,626416)
+    59	      |-(git-annex-remot,626422)
+    60	      |-git-annex-remot,626428 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    61	      |-(git-annex-remot,626442)
+    62	      |-(git-annex-remot,626448)
+    63	      |-git-annex-remot,626454 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    64	      |-(git-annex-remot,626475)
+    65	      |-(git-annex-remot,626481)
+    66	      |-git-annex-remot,626487 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    67	      |-(git-annex-remot,626501)
+    68	      |-(git-annex-remot,626507)
+    69	      |-git-annex-remot,626513 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    70	      |-(git-annex-remot,626535)
+    71	      |-(git-annex-remot,626549)
+    72	      |-(git-annex-remot,626555)
+    73	      |-(git-annex-remot,626561)
+    74	      |-git-annex-remot,626567 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    75	      |-(git-annex-remot,626589)
+    76	      |-(git-annex-remot,626595)
+    77	      |-(git-annex-remot,626601)
+    78	      |-(git-annex-remot,626607)
+    79	      |-git-annex-remot,626613 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    80	      |-(git-annex-remot,626635)
+    81	      |-(git-annex-remot,626641)
+    82	      |-(git-annex-remot,626647)
+    83	      |-(git-annex-remot,626653)
+    84	      |-git-annex-remot,626660 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    85	      |-(git-annex-remot,626685)
+    86	      |-(git-annex-remot,626691)
+    87	      |-(git-annex-remot,626697)
+    88	      |-(git-annex-remot,626703)
+    89	      |-git-annex-remot,626709 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    90	      |-(git-annex-remot,626741)
+    91	      |-(git-annex-remot,626747)
+    92	      |-git-annex-remot,626753 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    93	      |-(git-annex-remot,626767)
+    94	      |-(git-annex-remot,626773)
+    95	      |-git-annex-remot,626779 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    96	      |-(git-annex-remot,626795)
+    97	      |-(git-annex-remot,626801)
+    98	      |-git-annex-remot,626807 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+    99	      |-(git-annex-remot,626821)
+   100	      |-(git-annex-remot,626828)
+   101	      |-git-annex-remot,626834 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   102	      |-(git-annex-remot,630376)
+   103	      |-(git-annex-remot,630382)
+   104	      |-git-annex-remot,630388 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   105	      |-(git-annex-remot,630813)
+   106	      |-(git-annex-remot,630819)
+   107	      |-git-annex-remot,630825 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   108	      |-(git-annex-remot,631249)
+   109	      |-(git-annex-remot,631255)
+   110	      |-git-annex-remot,631261 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   111	      |-(git-annex-remot,631679)
+   112	      |-(git-annex-remot,631685)
+   113	      |-git-annex-remot,631691 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   114	      |-(git-annex-remot,632944)
+   115	      |-(git-annex-remot,632950)
+   116	      |-(git-annex-remot,632956)
+   117	      |-(git-annex-remot,632962)
+   118	      |-git-annex-remot,632968 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   119	      |-(git-annex-remot,633804)
+   120	      |-(git-annex-remot,633810)
+   121	      |-(git-annex-remot,633816)
+   122	      |-(git-annex-remot,633822)
+   123	      |-git-annex-remot,633828 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   124	      |-(git-annex-remot,635086)
+   125	      |-(git-annex-remot,635092)
+   126	      |-(git-annex-remot,635098)
+   127	      |-(git-annex-remot,635104)
+   128	      |-git-annex-remot,635111 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   129	      |-(git-annex-remot,635133)
+   130	      |-(git-annex-remot,635139)
+   131	      |-(git-annex-remot,635145)
+   132	      |-(git-annex-remot,635151)
+   133	      |-git-annex-remot,635157 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   134	      |-(git-annex-remot,637445)
+   135	      |-(git-annex-remot,637451)
+   136	      |-git-annex-remot,637457 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   137	      |-(git-annex-remot,637471)
+   138	      |-(git-annex-remot,637477)
+   139	      |-git-annex-remot,637484 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   140	      |-(git-annex-remot,637500)
+   141	      |-(git-annex-remot,637506)
+   142	      |-git-annex-remot,637512 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   143	      |-(git-annex-remot,637526)
+   144	      |-(git-annex-remot,637532)
+   145	      |-git-annex-remot,637538 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   146	      |-git-annex-remot,641104 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   147	      |-(git-annex-remot,641110)
+   148	      |-git-annex-remot,641116 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   149	      |-git-annex-remot,641541 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   150	      |-(git-annex-remot,641547)
+   151	      |-git-annex-remot,641553 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   152	      |-(git-annex-remot,641971)
+   153	      |-(git-annex-remot,641977)
+   154	      |-git-annex-remot,641983 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   155	      |-git-annex-remot,642411 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   156	      |-(git-annex-remot,642417)
+   157	      |-git-annex-remot,642423 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   158	      |-git-annex-remot,643893 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   159	      |-(git-annex-remot,643899)
+   160	      |-(git-annex-remot,643905)
+   161	      |-(git-annex-remot,643911)
+   162	      |-git-annex-remot,643917 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   163	      |-git-annex-remot,644770 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   164	      |-(git-annex-remot,644776)
+   165	      |-(git-annex-remot,644782)
+   166	      |-(git-annex-remot,644788)
+   167	      `-git-annex-remot,644794 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+   168	          `-git,645597 -c gc.auto=0 fetch origin refs/annex-gitobjects/SHA256E-s1048576-S10485-C65--09bb4349a75edd87d52a9c0fa7c8962dd5f58b22e3a639924f9b625eda394e47.this-is-a-test-key:refs/annex-gitobjects/SHA256E-s1048576-S10485-C65--09bb4349a75edd87d52a9c0fa7c8962dd5f58b22e3a639924f9b625eda394e47.this-is-a-test-key
+```
+
+(pstree is taken at some point in time of `testremote` running)
+
+even with older version (7.20190819+git2-g908476a9b-1~ndall+1) it is not clear why some older instances linger around:
+
+```
+git,586534 annex testremote go
+  `-git-annex,586535 --library-path /usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/usr/lib/git-annex.linux//etc/ld.so.conf.d:/usr/lib/git-annex.linux//lib64:/u
+sr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu:/usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git-annex/git-annex testremote go
+      |-git,586558 --library-path /usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/usr/lib/git-annex.linux//etc/ld.so.conf.d:/usr/lib/git-annex.linux//lib64:/usr
+/lib/git-annex.linux//usr/lib/x86_64-linux-gnu:/usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+      |-git,586559 --library-path /usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/usr/lib/git-annex.linux//etc/ld.so.conf.d:/usr/lib/git-annex.linux//lib64:/usr
+/lib/git-annex.linux//usr/lib/x86_64-linux-gnu:/usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch-check=%(objectname) %(obj
+ecttype) %(objectsize)
+      |-git-annex-remot,586561 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+      |-git-annex-remot,586575 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+      |-git-annex-remot,586589 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+      |-git-annex-remot,586603 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+      |-git-annex-remot,586617 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+      |-git-annex-remot,586631 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+      |-git-annex-remot,586645 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+      |-git-annex-remot,586659 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+      |-git-annex-remot,586674 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+      |   `-git,596315 --library-path /usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/usr/lib/git-annex.linux//etc/ld.so.conf.d:/usr/lib/git-annex.linux//lib64:
+/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu:/usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git -c gc.auto=0 push origin :refs/annex-gitobjects/SHA256E-s1048576-S10485-C55--f29f024602
+c6bb2cce66bc08073e2770802707941f06270d03264e574b2b2c0d.this-is-a-test-key
+      |       `-sh,596316 -c git-receive-pack '/home/yoh/.tmp/dl-XfXTJ3K/a' git-receive-pack '/home/yoh/.tmp/dl-XfXTJ3K/a'
+      |           `-git-receive-pac,596317 --library-path /usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/usr/lib/git-annex.linux//etc/ld.so.conf.d:/usr/lib/git
+-annex.linux//lib64:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu:/usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git-receive-pack/git-receive-pack /home/yoh/.tmp/dl-XfXTJ3K/a
+      |               `-post-receive,596321 hooks/post-receive
+      |-git-annex-remot,586691 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects                                                                                                                                  
+      |-git-annex-remot,586705 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects                                                                                    
+      |-git-annex-remot,586719 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects                                                                                                                                  
+      |-git-annex-remot,586733 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects                                                                                                    
+      `-git-annex-remot,586747 /home/yoh/proj/datalad/datalad/sandbox/git-annex-remote-gitobjects
+```
+
+I also wonder if there could be some unittest added to test that annex stays "lean" (in terms of child processes) while using external remotes.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/testremote_breeds_way_too_many_instances_of_the_externals_remote/comment_1_6c4afa18ad31f46ff8c0b827415373e4._comment b/doc/projects/datalad/bugs-done/testremote_breeds_way_too_many_instances_of_the_externals_remote/comment_1_6c4afa18ad31f46ff8c0b827415373e4._comment
new file mode 100644
index 0000000000..7676382ed3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/testremote_breeds_way_too_many_instances_of_the_externals_remote/comment_1_6c4afa18ad31f46ff8c0b827415373e4._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-22T16:24:53Z"
+ content="""
+There should be 4-8, because it does make that many remote
+variants, each with a different config.
+
+But, each individual test case is starting a process.
+
+This is a reversion from around [[!commit 9fa940569c7941ad794637017ae5296e657c7f8d]].
+To make git-annex test be able to use testremote, that deferred generating
+Remote objects to inside the TestTree.. So it generates them when running
+each test case.
+
+Other remotes that allocate other resources will also allocate too many,
+not cache http connections in testremote, etc.
+
+The test suite was also affected in its use of testremote, but only
+tested a directory special remote so I think avoided any bad behavior.
+
+Fixed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/testremote_breeds_way_too_many_instances_of_the_externals_remote/comment_2_daa09ac406dea6cd3ab74fe19d89d956._comment b/doc/projects/datalad/bugs-done/testremote_breeds_way_too_many_instances_of_the_externals_remote/comment_2_daa09ac406dea6cd3ab74fe19d89d956._comment
new file mode 100644
index 0000000000..f439fabfeb
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/testremote_breeds_way_too_many_instances_of_the_externals_remote/comment_2_daa09ac406dea6cd3ab74fe19d89d956._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-06-22T18:27:30Z"
+ content="""
+> I also wonder if there could be some unittest added to test that annex stays "lean" (in terms of child processes) while using external remotes.
+
+Normally it will only start one per thread, testremote is unique in
+generating variants of a remote.
+
+It would be good to somehow catch situations where a lot of child processes
+get spawned in general, like the earlier -J8 starting too many
+git helper processes. But I don't know how a test suite could detect or
+judge that.
+
+Some of the work done for
+[[todo/more_extensive_retries_to_mask_transient_failures]]
+avoids potential situations where part of git-annex could leak a process
+during exception handling. Continuing work on that will probably improve
+things further.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220.mdwn b/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220.mdwn
new file mode 100644
index 0000000000..92ddca7365
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220.mdwn
@@ -0,0 +1,83 @@
+A DataLad test that calls `git-annex initremote ...` [started to
+fail][0] with a recent version of git-annex.  I can trigger the
+failure if I strip away the DataLad-bits by using the built-in
+directory remote:
+
+[[!format sh """
+cd "$(mktemp -d ${TMPDIR:-/tmp}/gx-testremote-XXXXXXX)"
+git annex version
+mkdir dremote
+git init a
+(
+    cd a
+    git annex init
+    git annex initremote d type=directory directory="$PWD/../dremote" encryption=none
+    git annex testremote d
+)
+"""]]
+
+
+```
+git-annex version: 8.20200331-geec124409
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify TorrentParser Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.4 feed-1.2.0.1 ghc-8.6.5 http-client-0.6.4 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+Initialized empty Git repository in /tmp/gx-testremote-wB72esA/a/.git/
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
+initremote d ok
+(recording state in git...)
+testremote d (generating test keys...) Remote Tests
+  unavailable remote
+    removeKey:                                         /dev/null/tmp/SHA256E-s1048576--46beaff739fefc2d8e88242e04c5be92ecfd14b7c28c06ffccc282767d891a0e.this-is-a-test-key/SHA256E-s1048576--46beaff739fefc2d8e88242e04c5be92ecfd14b7c28c06ffccc282767d891a0e.this-is-a-test-key: openBinaryFile: inappropriate type (Not a directory)
+[... 42 lines ...]
+    storeKey:                                        OK (0.03s)
+    present True:                                    FAIL
+      ./Command/TestRemote.hs:206:
+      failed
+    storeKey when already present:                   OK
+    present True:                                    FAIL
+      ./Command/TestRemote.hs:206:
+      failed
+    retrieveKeyFile:                                 FAIL
+      ./Command/TestRemote.hs:206:
+      failed
+    fsck downloaded object:                          OK
+    retrieveKeyFile resume from 33%:                 FAIL
+      Exception: .git/annex/objects/Fj/g7/SHA256E-s1048576--46beaff739fefc2d8e88242e04c5be92ecfd14b7c28c06ffccc282767d891a0e.this-is-a-test-key/SHA256E-s1048576--46beaff739fefc2d8e88242e04c5be92ecfd14b7c28c06ffccc282767d891a0e.this-is-a-test-key: openBinaryFile: does not exist (No such file or directory)
+    fsck downloaded object:                          OK
+    retrieveKeyFile resume from 0:                   FAIL
+      Exception: failed to lock content: .git/annex/objects/Fj/g7/SHA256E-s1048576--46beaff739fefc2d8e88242e04c5be92ecfd14b7c28c06ffccc282767d891a0e.this-is-a-test-key/SHA256E-s1048576--46beaff739fefc2d8e88242e04c5be92ecfd14b7c28c06ffccc282767d891a0e.this-is-a-test-key: getFileStatus: does not exist (No such file or directory)
+    fsck downloaded object:                          OK
+    retrieveKeyFile resume from end:                 cp: cannot stat '.git/annex/objects/Fj/g7/SHA256E-s1048576--46beaff739fefc2d8e88242e04c5be92ecfd14b7c28c06ffccc282767d891a0e.this-is-a-test-key/SHA256E-s1048576--46beaff739fefc2d8e88242e04c5be92ecfd14b7c28c06ffccc282767d891a0e.this-is-a-test-key': No such file or directory
+FAIL
+      Exception: failed to lock content: .git/annex/objects/Fj/g7/SHA256E-s1048576--46beaff739fefc2d8e88242e04c5be92ecfd14b7c28c06ffccc282767d891a0e.this-is-a-test-key/SHA256E-s1048576--46beaff739fefc2d8e88242e04c5be92ecfd14b7c28c06ffccc282767d891a0e.this-is-a-test-key: getFileStatus: does not exist (No such file or directory)
+    fsck downloaded object:                          OK
+    removeKey when present:                          OK
+[... 900 lines ...]
+
+212 out of 573 tests failed (0.92s)
+
+git-annex: failed to lock content: .git/annex/objects/Fj/g7/SHA256E-s1048576--46beaff739fefc2d8e88242e04c5be92ecfd14b7c28c06ffccc282767d891a0e.this-is-a-test-key/SHA256E-s1048576--46beaff739fefc2d8e88242e04c5be92ecfd14b7c28c06ffccc282767d891a0e.this-is-a-test-key: getFileStatus: does not exist (No such file or directory)
+failed
+(recording state in git...)
+git-annex: testremote: 1 failed
+```
+
+The output above is with the current master (eec124409).  I don't see
+the failures when using the latest release (8.20200330).  Based on
+bisecting, I believe these failures start happening with aeca7c220
+(Sped up query commands that read the git-annex branch by around 5%,
+2020-04-09).
+
+[0]: https://github.com/datalad/datalad/issues/4445
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_1_d779827a6cc3d3d7bb6edfa410170e09._comment b/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_1_d779827a6cc3d3d7bb6edfa410170e09._comment
new file mode 100644
index 0000000000..52112387df
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_1_d779827a6cc3d3d7bb6edfa410170e09._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-04-28T20:43:42Z"
+ content="""
+To be clear, have you only seen this when running testremote, or also
+another git-annex command?
+
+Verified that commit is where it started failing.
+
+(Seems like it would be worth adding testremote of a directory remote to
+the test suite..)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_2_4cfb0979773618a0bc18d52bf0f274e4._comment b/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_2_4cfb0979773618a0bc18d52bf0f274e4._comment
new file mode 100644
index 0000000000..36d5901d70
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_2_4cfb0979773618a0bc18d52bf0f274e4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 2"
+ date="2020-04-28T20:48:18Z"
+ content="""
+> To be clear, have you only seen this when running testremote, or
+> also another git-annex command?
+
+I've seen this only when running testremote.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_2_d53b98bca623d4d25bab58563e7577b3._comment b/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_2_d53b98bca623d4d25bab58563e7577b3._comment
new file mode 100644
index 0000000000..af8a46feff
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_2_d53b98bca623d4d25bab58563e7577b3._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-04-28T20:56:01Z"
+ content="""
+Fairly sure it's something to do with the chunk log. The tests with no
+chunks succeed, so the subsequent failures could be due to it failing to
+see information about chunks used to store the key when it then tries to
+retrieve it.
+
+Aha: It's using Annex.eval, so it does stuff, and throws away the changed
+state. So, after writing to the journal, when journalIgnorable = False,
+it will then forget that, and will try to read from the branch, ignoring
+the journal.
+
+I checked all Annex.eval, and all the rest have the pattern 
+Annex.eval =<< Annex.new. This is the only one that *reuses*
+an old state across multiple Annex.eval. And it's not like the commit that
+triggered this made Annex.eval more dangerous; that were never a good thing
+to do and probably only didn't break on some other state being lost before
+due to luck.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_4_a80f9277eb6f6c49710d5008bc2c2c42._comment b/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_4_a80f9277eb6f6c49710d5008bc2c2c42._comment
new file mode 100644
index 0000000000..985f9195a9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/testremote_failures_starting_with_aeca7c220/comment_4_a80f9277eb6f6c49710d5008bc2c2c42._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="thanks!"
+ date="2020-04-28T21:41:30Z"
+ content="""
+Wow, thanks for the quick fix.  Confirmed that the failing DataLad
+test that initiated this bug report is back to green with fa98025de.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/testremote_with_external_remote_hangs_after_asyncexternal_merge.mdwn b/doc/projects/datalad/bugs-done/testremote_with_external_remote_hangs_after_asyncexternal_merge.mdwn
new file mode 100644
index 0000000000..6d3ab6d0b1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/testremote_with_external_remote_hangs_after_asyncexternal_merge.mdwn
@@ -0,0 +1,60 @@
+The DataLad tests run one of our custom special remotes through `git
+annex testremote`.  As mentioned in a recent [DataLad issue][1], this
+test has started to fail.  When I run the test locally, it hangs.
+This starts with the recent merge of the asyncexternal branch
+(95d9a3cf8).
+
+Here's a reproducer that takes DataLad out of the equation.  It uses
+the example external remote.
+
+[[!format sh """
+#!/bin/sh
+
+set -eu
+
+ga_srcdir="$(realpath "${1?requires git-annex source directory as argument}")"
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/gx-testremote-XXXXXXX)"
+top="$PWD"
+
+mkdir bin
+git -C "$ga_srcdir" cat-file -p \
+    1740c4ef650dd2bf3b1d91322d55aace7667b822:doc/special_remotes/external/example.sh \
+    >bin/git-annex-remote-foo
+chmod +x bin/git-annex-remote-foo
+export PATH="$top/bin:$PATH"
+
+export MYPASSWORD="x"
+export MYLOGIN="x"
+mkdir d
+
+git init a
+(
+    cd a
+    git annex init main
+    git annex initremote d \
+        type=external externaltype=foo directory="$top/d" encryption=none
+    git annex testremote --fast d
+)
+"""]]
+
+With the latest commit on master checked out (67cad93f8), the above
+script stalls on my end at
+
+```
+testremote d (generating test keys...)
+  Cannot run git-annex-remote-!dne! -- It is not installed in PATH (/home/kyle/src/c/git-bin:/home/kyle/src/c/git-bin/bin-wrappers:/tmp/gx-testremote-aiS5Ztm/bin:/home/kyle/src/haskell/git-annex/.stack-work/install/x86_64-linux-tinfo6/5bf51f244130923958226fa250ede392c8c3d23ac815c7b4b9d65910222773d4/8.6.5/bin:/home/kyle/.stack/snapshots/x86_64-linux-tinfo6/5bf51f244130923958226fa250ede392c8c3d23ac815c7b4b9d65910222773d4/8.6.5/bin:/home/kyle/.stack/compiler-tools/x86_64-linux-tinfo6/ghc-8.6.5/bin:/home/kyle/.stack/programs/x86_64-linux/ghc-tinfo6-8.6.5/bin:/home/kyle/src/python/venvs/datalad//bin:/home/kyle/src/c/git-bin/bin-wrappers:/home/kyle/.guix-profile/bin:/home/kyle/.config/guix/current/bin:/home/kyle/.cabal/bin:/usr/lib/ccache/bin:/home/kyle/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games)
+Remote Tests
+  unavailable remote
+    removeKey:
+```
+
+With the first commit before the merge checked out (0900bb2ca), the
+`testremote` call completes successfully.
+
+[1]: https://github.com/datalad/datalad/issues/4825
+
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] thanks for reporting --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/testremote_with_external_remote_hangs_after_asyncexternal_merge/comment_1_854aecbc440dc3a5aa15f9de5f36c9e8._comment b/doc/projects/datalad/bugs-done/testremote_with_external_remote_hangs_after_asyncexternal_merge/comment_1_854aecbc440dc3a5aa15f9de5f36c9e8._comment
new file mode 100644
index 0000000000..25e9b8ef25
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/testremote_with_external_remote_hangs_after_asyncexternal_merge/comment_1_854aecbc440dc3a5aa15f9de5f36c9e8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="thanks"
+ date="2020-08-19T17:54:08Z"
+ content="""
+Great, thank you.  I've confirmed that this resolves the original
+datalad test failures for me locally.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container.mdwn b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container.mdwn
new file mode 100644
index 0000000000..e5799743e7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+
+I am trying to setup a cron job on github actions to daily test datalad against bleeding edge git-annex. All the few commands I am using are all in the workflow file: https://github.com/datalad/datalad-extensions/pull/7/files#diff-8364c688b76bfaf5df947cfd4d74eef7R42
+
+To build git-annex I am using a singularity container (based on buster with all build-dependencies installed).
+While building a binary standalone package (from first prepared .dsc) 3 tests fail:
+
+`3 out of 260 tests failed (195.33s)`
+
+- [web view of the logs](https://github.com/datalad/datalad-extensions/pull/7/checks?check_run_id=532056262)
+- [and here they are all in raw form (probably would expire soon)](https://pipelines.actions.githubusercontent.com/2UPlDxaVvvbkeFX4btxWorCjpJvj40zvWY5ogH2yZibhOMcU7O/_apis/pipelines/1/runs/182/signedlogcontent/3?urlExpires=2020-03-24T23%3A51%3A03.1656651Z&urlSigningMethod=HMACV1&urlSignature=zmkF8NBdaLU3pAOT3WJ2C6R81sZjH4%2Bka2QiVynkEkU%3D) 
+
+outside the container system is some ubuntu -- inside debian stable (buster).  singularity bind mounts HOME, /tmp and passes all environment variables inside the container.
+
+if you search for `Z FAIL` you would find the hit
+[[!format sh """
+2020-03-24T23:41:28.7154039Z     crypto:                                               [adjusted/master(unlocked) f647310] empty
+2020-03-24T23:41:28.7485256Z adjust ok
+2020-03-24T23:41:34.7685919Z gpg: can't connect to the agent: File name too long
+2020-03-24T23:41:34.7687700Z gpg: error getting the KEK: No agent running
+2020-03-24T23:41:34.7689081Z gpg: error reading '[stdin]': No agent running
+2020-03-24T23:41:34.7690114Z gpg: import from '[stdin]' failed: No agent running
+2020-03-24T23:41:34.7693611Z FAIL
+"""]]
+
+I wonder if it relates to the discrepancy of gpg-agent running outside of the container and gpg inside the container, which I have detected when saw
+
+[[!format sh """
+2020-03-24T23:34:08.8873100Z gpg: WARNING: server 'gpg-agent' is older than us (2.2.4 < 2.2.12)
+2020-03-24T23:34:08.8873946Z gpg: Note: Outdated servers may lack important security fixes.
+2020-03-24T23:34:08.8875072Z gpg: Note: Use the command "gpgconf --kill all" to restart them.
+2020-03-24T23:34:08.9223394Z  signfile git-annex_8.20200309+git101-ga51a94f61-1~ndall+1_source.buildinfo
+"""]]
+
+in the beginning of the run, or may be just the fact that inside the container it shouldn't use `gpg-agent`...
+I wonder if there is an easy way to disable tests which would rely on having connection to gpg-agent?
+
+FWIW,
+- similarish and [then mitigated situation happened awhile back](https://git-annex.branchable.com/bugs/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/)
+- the same version package builds fine using our conventional neurodebian build setup using cowbuilder (no singularity)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_1_d36c27dca4d266d1e6639e3435198016._comment b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_1_d36c27dca4d266d1e6639e3435198016._comment
new file mode 100644
index 0000000000..64da39ef67
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_1_d36c27dca4d266d1e6639e3435198016._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-26T16:19:02Z"
+ content="""
+After wasting 20 minutes on github's atrocious mess of an interface, I
+managed to download some raw logs that I can look at in something that does
+not freeze the javascript interpreter constantly while searching for "FAIL". 
+(This is quite a mess to inflict on yourself all in the name of proprietary
+monoculture, just saying.)
+
+Full relevant except:
+
+	2020-03-24T23:41:28.7154004Z     crypto:                                               [adjusted/master(unlocked) f647310] empty
+	2020-03-24T23:41:28.7485238Z adjust ok
+	2020-03-24T23:41:34.7685883Z gpg: can't connect to the agent: File name too long
+	2020-03-24T23:41:34.7687691Z gpg: error getting the KEK: No agent running
+	2020-03-24T23:41:34.7689073Z gpg: error reading '[stdin]': No agent running
+	2020-03-24T23:41:34.7690106Z gpg: import from '[stdin]' failed: No agent running
+	2020-03-24T23:41:34.7693591Z FAIL
+	2020-03-24T23:41:34.7695318Z       Exception: user error (gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--import","-q"] exited 2)
+
+Very odd that it omits any mention of what subtest failed. I have a feeling
+this log only contains stdout and not stderr, or something other weird is
+happening. Probably if that were not missing it would say "test harness
+self-test failed".
+
+gpg communicates with the agent over a unix socket. On linux, the path 
+to a socket is limited to 109 bytes. The test is being run in 
+"/home/runner/work/datalad-extensions/datalad-extensions/build/git-annex-8.20200309+git101-ga51a94f61"
+which is 100 bytes. Add ".t/gpgtest/" and the name of the socket, and it's too
+long.
+
+Quick fix is to cd to /tmp or something before running the test suite.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_2_c61b14b76cf06c0b10257c1a84d9478a._comment b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_2_c61b14b76cf06c0b10257c1a84d9478a._comment
new file mode 100644
index 0000000000..1e96fe5d50
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_2_c61b14b76cf06c0b10257c1a84d9478a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-03-26T16:55:30Z"
+ content="""
+Tried to reproduce it here running in a directory with the same lenth, but
+no failures. It could have to do with the old version of gpg-agent.
+
+(I don't see how gpg inside the container could talk to gpg-agent outside
+the container at all, unless the container shares a filesystem, and even
+then, gpg inside the container is being run with a nonstandard home
+directory, so it will not try to talk to a gpg-agent socket in the usual
+home directory.)
+
+I have a patch that makes the path to the socket file relative, but can't
+verify if it will fix the problem. I've applied it anyway.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_3_ea210a22073919be434884f006212e6a._comment b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_3_ea210a22073919be434884f006212e6a._comment
new file mode 100644
index 0000000000..278a14ff93
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_3_ea210a22073919be434884f006212e6a._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2020-03-31T01:22:53Z"
+ content="""
+Thank you Joey!
+TL;DR: If you don't manage to reproduce it with the call below -- let's consider the issue doesn't exist ;) at least I found a workaround.
+
+if you would like to try, after `apt-get install singularity-container`:
+ 
+```
+git clone git://github.com/datalad/datalad-extensions -b enh-git-annex && cd datalad-extensions && scripts/ci/build_git_annex build
+```
+(it might ask for a passkey to your gpg at some point - building signed pkgs) -- it might or might not fail for you!
+
+Ghosts: it fails if I just run `scripts/ci/build_git_annex build` in my original local git repository. If, instead of `build/` I am providing some path outside of current directory (i.e. not just `build`) when I am under $HOME -- it seems to work.  So I started to build out under /tmp/git-annex and github actions seems to pass now!: https://github.com/datalad/datalad-extensions/runs/547292760?check_suite_focus=true
+
+But it also passes for me when I do above like under `/tmp/` , or when I provide build directory still somewhere in my home, e.g. `~/build`.
+I think it is some singularity bind mounts madness somehow interfering.
+
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_4_0cfd7d0d93d0747d42d20f13b788fe43._comment b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_4_0cfd7d0d93d0747d42d20f13b788fe43._comment
new file mode 100644
index 0000000000..01cb516400
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_4_0cfd7d0d93d0747d42d20f13b788fe43._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-04-27T18:10:54Z"
+ content="""
+I guess your command there would need to be run in a directory /home/runner/work/datalad-extensions
+to replicate the path I saw earlier.
+
+I did try it, but the singulatriy pull is failing with "While pulling shub
+image: download did not succeed: 400 Bad Request".
+
+Running it in some directory like /tmp avoiding the problem
+more or less confirms my hypothesis that it's a socket path length
+problem. Both /tmp/build and /home/yoh/build are much shorter than
+/home/runner/work/datalad-extensions/datalad-extensions/build.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_5_944a4474401b2fa0b4f3631bac63a07d._comment b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_5_944a4474401b2fa0b4f3631bac63a07d._comment
new file mode 100644
index 0000000000..69d4552ea6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_5_944a4474401b2fa0b4f3631bac63a07d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2020-04-27T19:46:22Z"
+ content="""
+I should try to remember that (\"On linux, the path to a socket is limited to 109 bytes\") since I bet it might be biting me in some other cases... And [on other systems it seems might even be shorter](https://unix.stackexchange.com/questions/367008/why-is-socket-path-length-limited-to-a-hundred-chars). Someone might even like to check if it is not accounting for the path to the image/some mountpoint outside of the singularity container which would then limit it even further. 
+
+Re singularity: dunno.  I have now retried with 2.6.1-2~nd100+1 from neurodebian and 3.5.2+ds1-1 from Debian, in both cases `singularity pull --name buildenv.sif shub://datalad/datalad-extensions:buildenv-git-annex-buster` seems to start downloading.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_5_fa8c65c2223d2be21aa95e5889c1f352._comment b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_5_fa8c65c2223d2be21aa95e5889c1f352._comment
new file mode 100644
index 0000000000..6ceec4a22f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_5_fa8c65c2223d2be21aa95e5889c1f352._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-04-28T17:32:26Z"
+ content="""
+Reproduced on a host that is not behind a satellite http cache.
+
+My earlier change did not fix it. With my change, GNUPGHOME is something like
+"../gpgtmp/1". So the version of gpg in this singularity must be converting
+that relative path to an absolute path, too long for a socket path.
+Which seems like kind of ridiculous behavior, but gpg does `chdir()` in
+places so maybe that's why.
+
+Tried a few changes, including removing --use-agent and --no-tty
+(it still tries to use the agent), using --no-use-agent
+(option is obsolete and it still tries to use the agent).
+
+Affected version of gnupg is 2.2.12, and I think 2.2.20 does not behave
+that way, because it always puts the gpg agent socket in
+/run/user/uuid/gnupg/ not in GNUPGHOME. (OTOH, the docs for gpg say 
+it uses the standard socket since 2.1.) Or something about the singularity
+environment could be altering gpg's behavior.
+
+Anyway, this is kind of ridiculous behavior from gpg, and the only thing
+I can see that git-annex could do to avoid it is set GNUPGHOME to some
+short path in /tmp. But then git-annex would have to not honor TMPDIR
+for that, because that could be set to some path that is too long. Ignoring
+TMPDIR would be easily argued to be a bug in git-annex, while this is pretty
+clearly a bug in an old version of gpg.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_6_d358bf55d89f5d0609d792a26757d0f4._comment b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_6_d358bf55d89f5d0609d792a26757d0f4._comment
new file mode 100644
index 0000000000..04c0621436
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_6_d358bf55d89f5d0609d792a26757d0f4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-04-28T19:29:05Z"
+ content="""
+Hmm, it could be that /run is not mounted in the container and then gpg
+falls back to putting the socket in the home directory.
+
+Ok, I'm just going to make this test be skipped if it fails to import the
+test key.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/tests_fail_on_Linux_build.mdwn b/doc/projects/datalad/bugs-done/tests_fail_on_Linux_build.mdwn
new file mode 100644
index 0000000000..4485a41591
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/tests_fail_on_Linux_build.mdwn
@@ -0,0 +1,27 @@
+[https://github.com/datalad/git-annex/pull/7/checks?check_run_id=1376365603](https://github.com/datalad/git-annex/pull/7/checks?check_run_id=1376365603)
+
+```
+2020-11-09T20:27:43.3824770Z     prop_upFrom_basics:                                   FAIL
+2020-11-09T20:27:43.3827072Z       *** Failed! Exception: 'recoverEncode: invalid argument (invalid character)' (after 3 tests):
+2020-11-09T20:27:43.3828330Z       "\522233"
+2020-11-09T20:27:43.3829895Z       Use --quickcheck-replay=884646 to reproduce.
+2020-11-09T20:27:43.3836556Z     prop_relPathDirToFileAbs_basics:                      FAIL
+2020-11-09T20:27:43.3838482Z       *** Failed! Exception: 'recoverEncode: invalid argument (invalid character)' (after 3 tests and 2 shrinks):
+2020-11-09T20:27:43.3839816Z       "a"
+2020-11-09T20:27:43.3840575Z       "\1046632"
+2020-11-09T20:27:43.3841805Z       Use --quickcheck-replay=45910 to reproduce.
+...
+2020-11-09T20:27:52.3356280Z     prop_viewedFile_rountrips:                            FAIL
+2020-11-09T20:27:52.3358132Z       *** Failed! Exception: 'recoverEncode: invalid argument (invalid character)' (after 3 tests and 1 shrink):
+2020-11-09T20:27:52.3358797Z       "\897292"
+2020-11-09T20:27:52.3359408Z       Use --quickcheck-replay=262390 to reproduce.
+```
+
+that is for 8.20201103+git55-g0f2813377 
+
+OSX and Windows [still FTBFS differently](https://github.com/datalad/git-annex/pull/7#issuecomment-724306450) so cannot say either it is linux or not specific
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/tests_fail_on_Linux_build/comment_1_9932a7c60bb369fbffba52092e03bce3._comment b/doc/projects/datalad/bugs-done/tests_fail_on_Linux_build/comment_1_9932a7c60bb369fbffba52092e03bce3._comment
new file mode 100644
index 0000000000..3375596f75
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/tests_fail_on_Linux_build/comment_1_9932a7c60bb369fbffba52092e03bce3._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-11-09T22:52:59Z"
+ content="""
+[[!commit d44fb89d4f4d3120a34a192025ee901c064cab00]] fixed a problem
+with the same underlying cause.
+Also, [[!commit d44fb89d4f4d3120a34a192025ee901c064cab00]]
+
+Like those, this certianly cannot affect actual use of git-annex
+as the string QuickCheck has magiced up is normally unable to be produced
+by any input when LANG=C, and is not a problem in unicode locales.
+
+Probably there ought to be a newtype wrapper around FilePath with a more
+sane Arbitrary instance, since the default haskell one has this problem.
+Limiting to ascii only is probably fine. It would be good to use that in
+every quickcheck property, so we can stop tripping over these.
+
+(Also worth noting: As soon as everything gets converted to RawFilePath
+entirely, this entire class of problems goes away (and git-annex gets
+faster too).)
+
+(I wonder if it's also just a bug in QuickCheck, but it's hard to see how
+it could both do any testing of unicode and work in LANG=C given that
+Arbitrary is pure and has no way of knowing the locale.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/tests_fail_on_Linux_build/comment_2_c042d95b58500933e5932176037ead8f._comment b/doc/projects/datalad/bugs-done/tests_fail_on_Linux_build/comment_2_c042d95b58500933e5932176037ead8f._comment
new file mode 100644
index 0000000000..a84911b548
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/tests_fail_on_Linux_build/comment_2_c042d95b58500933e5932176037ead8f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-11-16T17:44:32Z"
+ content="""
+note: done marker seems have a `!` typo making it \"invalid\"?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone.mdwn b/doc/projects/datalad/bugs-done/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone.mdwn
new file mode 100644
index 0000000000..7b703f2196
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone.mdwn
@@ -0,0 +1,41 @@
+relates to having pidlock true
+
+[[!format sh """
+$> mkdir 123; cd 123; git init; git annex init; git config annex.pidlock true && echo "123" > 123.dat; git annex add 123.dat; git commit -m 'added';
+W: git-annex repositories not (yet) supported in the prompt
+Initialized empty Git repository in /tmp/123/.git/
+init  ok
+(recording state in git...)
+add 123.dat ok
+(recording state in git...)
+[master (root-commit) 9449f1b] added
+ 1 file changed, 1 insertion(+)
+ create mode 120000 123.dat
+
+$> git clone . ../123-clone && git remote add clone ../123-clone && git fetch clone && cd ../123-clone && git config annex.pidlock true && cd - && git annex move --to=clone .
+Cloning into '../123-clone'...                                                                                                                                         
+done.
+From ../123-clone
+ * [new branch]      master     -> clone/master
+move 123.dat git-annex: thread blocked indefinitely in an STM transaction
+
+$> echo $?
+1
+
+$> git annex version
+git-annex version: 6.20160226+gitg01f1de0-1~ndall+1
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 5 6
+upgrade supported from repository versions: 0 1 2 4 5
+
+"""]]
+
+and it works ok without pidlock enabled
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__.mdwn b/doc/projects/datalad/bugs-done/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__.mdwn
new file mode 100644
index 0000000000..35e870ef17
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+
+As described [elsewhere](http://git-annex.branchable.com/todo/make_addurl_respect_annex.largefiles_option/#comment-817c4d5c215ddc0ec7bc5c4c05dff091) but since that one is closed -- making a dedicated one
+
+unfortunately addurl doesn't care about large files if --fast (or --relaxed, although that one I guess I can understand ):
+
+[[!format sh """
+
+$ chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init;
+Initialized empty Git repository in /tmp/123/.git/
+init  ok
+(recording state in git...)
+
+$ git -c annex.largefiles=exclude=*.txt annex addurl --file=test.txt --fast \"http://www.onerussian.com/tmp/banner.png\"
+addurl test.txt ok
+(recording state in git...)
+
+$ ls -l test.txt
+lrwxrwxrwx 1 yoh yoh 132 Jan 13 18:44 test.txt -> .git/annex/objects/KW/kj/URL-s25319--http&c%%www.onerussian.com%tmp%banner.png/URL-s25319--http&c%%www.onerussian.com%tmp%banner.png
+
+"""]]
+
+it does consider largefiles for if addurl without  --fast, or --relaxed
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]]; this can't really be done, but I added `git annex
+> matchexpression` to allow scripting that checks expressions such as
+> annex.largefiles. --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms.mdwn b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms.mdwn
new file mode 100644
index 0000000000..fe09223da3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms.mdwn
@@ -0,0 +1,76 @@
+### Please describe the problem.
+
+For many collaborative workflows it is desired to provide read-only access to a git-annex repository on a remote ssh host.
+
+But apparently, even if user does have read access to the content, git-annex (shell?) tries to lock the entire remote repository leading to a crash:
+
+[[!format sh """
+lena:/tmp
+$> git clone localhost:/tmp/testroot testroot-clone       
+Cloning into 'testroot-clone'...
+remote: Enumerating objects: 19, done.
+remote: Counting objects: 100% (19/19), done.
+remote: Compressing objects: 100% (16/16), done.
+remote: Total 19 (delta 1), reused 0 (delta 0), pack-reused 0
+Receiving objects: 100% (19/19), done.
+Resolving deltas: 100% (1/1), done.
+
+$> git -C testroot-clone annex get .
+get 123 (from origin...) 
+git-annex: /tmp/testroot/.git/annex: openTempFile: permission denied (Permission denied)
+p2pstdio: 1 failed
+
+  Lost connection (fd:27: hGetChar: end of file)
+
+  Transfer failed
+
+  Unable to access these remotes: origin
+
+  No other repository is known to contain the file.
+failed
+get: 1 failed
+
+"""]]
+
+and original user reported a little different error (I have no access to see the details of that repository):
+
+```
+SENSORED's password:
+[2021-08-25 15:20:24.14821] (Utility.Process) process [2554781] done ExitSuccess
+[2021-08-25 15:20:24.1493] (Utility.Process) process [2555432] chat: ssh ["SENSORED","-S",".git/annex/ssh/SENSORED","-o","ControlMaster=auto","-o","ControlPersist=yes","-T","git-annex-shell 'p2pstdio' '/SENSORED' '--debug' '94ed180c-3f09-4b5b-a4c6-68b3a8acf900' --uuid d3e54e78-143b-4cee-89b6-217439bdb2e3"]
+[2021-08-25 15:20:24.883791] (P2P.IO) [ssh connection Just 2555432] [ThreadId 4] P2P < AUTH-SUCCESS d3e54e78-143b-4cee-89b6-217439bdb2e3
+[2021-08-25 15:20:24.883883] (P2P.IO) [ssh connection Just 2555432] [ThreadId 4] P2P > VERSION 1
+[2021-08-25 15:20:24.904358] (P2P.IO) [ssh connection Just 2555432] [ThreadId 4] P2P < VERSION 1
+[2021-08-25 15:20:24.904441] (P2P.IO) [ssh connection Just 2555432] [ThreadId 4] P2P > GET 0 2635065_20217_2_0.zip MD5E-s229347386--c8ba7095fa69c25cffeeaddf68124ea9.zip
+[2021-08-25 15:20:24.91475] (P2P.IO) [ThreadId 4] P2P < GET 0 2635065_20217_2_0.zip MD5E-s229347386--c8ba7095fa69c25cffeeaddf68124ea9.zip
+git-annex: /SENSORED/.git/annex/keysdb.lck: openFd: permission denied (Permission denied)
+p2pstdio: 1 failed
+
+  Lost connection (fd:22: hGetChar: end of file)
+[2021-08-25 15:20:25.019767] (Utility.Process) process [2555432] done ExitFailure 1
+
+  Transfer failed
+[2021-08-25 15:20:25.02038] (Utility.Process) process [2553967] done ExitSuccess
+[2021-08-25 15:20:25.020634] (Utility.Process) process [2553968] done ExitSuccess
+
+
+...
+```
+
+this severely limits git-annex usability for many collaboration  scenarios. I just wonder how come we did not run into this before...
+
+I guess the git-annex-shell must not lock anything until some write operation is really necessary.
+
+
+### What steps will reproduce the problem?
+
+create a git-annex repo owned by another user, provide permissions for others to read, try to `get` any annexed content via ssh
+
+### What version of git-annex are you using? On what operating system?
+
+8.20210803-g07dcb9c
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_10_2562d33a1cafb01b2cddb9a42a635616._comment b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_10_2562d33a1cafb01b2cddb9a42a635616._comment
new file mode 100644
index 0000000000..c17064a8f9
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_10_2562d33a1cafb01b2cddb9a42a635616._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 10"
+ date="2021-09-01T18:05:26Z"
+ content="""
+That issue I encountered using [reproducer](https://git.kitenet.net/index.cgi/git-annex.git/tree/doc/bugs/unable_to_get_content_via_ssh_without_write_perms/comment_5_9e4b82d27ddbb42d74f10a85635590e7._comment) (without ssh; sorry for broken markdown formatting, but can't edit a comment) still reproduces locally (no NFS) using originally reported 8.20210803+git133-ga7cf5abf3 if I reinstall that version, but it does not reproduce using recent 8.20210803+git167-g608593fec , so I guess it was addressed too.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_1_8b4fd2331ff62c984f91a9536a3a7e2b._comment b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_1_8b4fd2331ff62c984f91a9536a3a7e2b._comment
new file mode 100644
index 0000000000..12aa015923
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_1_8b4fd2331ff62c984f91a9536a3a7e2b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-08-30T16:03:07Z"
+ content="""
+This did used to work, see [[todo/read-only_removable_drives]] which ended
+with it working in 2016.
+
+There is a way to do it that's certian to work: Make a ssh key that logs
+into the host as the user who owns the repository, and lock that ssh key
+down to run git-annex-shell with `GIT_ANNEX_SHELL_READONLY=1
+GIT_ANNEX_SHELL_LIMITED=1`
+
+Still this should be investigated. Since one failure is certianly due to
+the keys database update, it seems likely that's what's changed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_2_3889b10d60b007de72b3af87e920e74e._comment b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_2_3889b10d60b007de72b3af87e920e74e._comment
new file mode 100644
index 0000000000..a8ad75eb0a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_2_3889b10d60b007de72b3af87e920e74e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-08-30T16:07:20Z"
+ content="""
+I can reproduce the keysdb.lck failure by simply making a new repository,
+owned by root, cloning it over ssh, running `git-annex init` (succeeds)
+and then `git-annex get` (fails).
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_3_a4f9bb23f0682a66e951b96aed6ae214._comment b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_3_a4f9bb23f0682a66e951b96aed6ae214._comment
new file mode 100644
index 0000000000..ebee761167
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_3_a4f9bb23f0682a66e951b96aed6ae214._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-08-30T16:24:52Z"
+ content="""
+keysdb error was a reversion in [[!commit f46e4c9b7c]], which reversed some
+logic and made database reads be treated as database writes, so it failed
+on permission denied, rather than the right behavior of returning
+DbUnavailable when it cannot read or the database does not exist yet. 
+
+Fixed that. It seems to work for me now, both get and drop, and over ssh or
+direct access to the readonly repository.
+
+I have not been able to reproduce the other error involving
+opening a temp file. All I can tell from the message is that it's writing
+to some file in .git/annex via a temp file in the same directory, but
+I don't know what file it is trying to write. I've made a change that
+will include more information in that error message. So either update
+your build of git-annex, or find a better reproduction recipe for that..
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_4_1b01ff1b092976af137bdfc2c9e28fba._comment b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_4_1b01ff1b092976af137bdfc2c9e28fba._comment
new file mode 100644
index 0000000000..c048a0198a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_4_1b01ff1b092976af137bdfc2c9e28fba._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2021-08-30T17:24:25Z"
+ content="""
+Thank you Joey for looking into this, very much appreciated!  The tricky part is that I am just a \"messenger\" here and it would be a bit tricky to instruct impacted users on howto to try out this new build until we release it via conda.  But let's see where we get ;-)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_5_9e4b82d27ddbb42d74f10a85635590e7._comment b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_5_9e4b82d27ddbb42d74f10a85635590e7._comment
new file mode 100644
index 0000000000..e12f3f18e4
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_5_9e4b82d27ddbb42d74f10a85635590e7._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="reproducer"
+ date="2021-08-30T18:07:05Z"
+ content="""
+> I have not been able to reproduce the other error involving opening a temp file.
+
+if of any help -- output from --debug:
+```
+[2021-08-30 13:59:19.423059134] (Utility.Process) process [2353815] chat: ssh [\"localhost\",\"-S\",\".git/annex/ssh/localhost\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git-annex-shell 'p2pstdio' '/tmp/testroot' '--debug' 'b438aaf1-df6e-4dcd-8342-6b4c3490ddc2' --uuid e5fb275a-f2d6-45ec-89e0-be9c5737a985\"]
+[2021-08-30 13:59:19.468653141] (P2P.IO) [ssh connection Just 2353815] [ThreadId 4] P2P < AUTH-SUCCESS e5fb275a-f2d6-45ec-89e0-be9c5737a985
+[2021-08-30 13:59:19.468876656] (P2P.IO) [ssh connection Just 2353815] [ThreadId 4] P2P > VERSION 1
+[2021-08-30 13:59:19.469785069] (P2P.IO) [ssh connection Just 2353815] [ThreadId 4] P2P < VERSION 1
+[2021-08-30 13:59:19.470001878] (P2P.IO) [ssh connection Just 2353815] [ThreadId 4] P2P > GET 0 123 MD5E-s4--ba1f2511fc30423bdbb183fe33f3dd0f
+[2021-08-30 13:59:19.470733309] (P2P.IO) [ThreadId 4] P2P < GET 0 123 MD5E-s4--ba1f2511fc30423bdbb183fe33f3dd0f
+git-annex: /tmp/testroot/.git/annex: openTempFile: permission denied (Permission denied)
+
+```
+
+and here is a reproducer which shows me that error using 8.20210803+git133-ga7cf5abf3-1~ndall+1
+
+```
+#!/bin/bash
+
+export PS4='> '
+set -eu
+
+set -x
+
+d=\"$(sudo mktemp -d ${TMPDIR:-/tmp}/ann-XXXXXXX)\"
+dclone=\"$d-clone\"
+
+
+umask 022
+
+sudo git -C $d init
+sudo git -C $d annex init
+sudo bash -c \"echo 123 > $d/123\"
+sudo git -C $d annex add $d/123
+sudo git -C $d commit -m 123
+sudo chmod go+rX -R \"$d\"
+
+git clone \"$d\" \"$dclone\"
+git -C \"$dclone\" annex get .
+
+```
+
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_6_11cb8251521014ef81b53090f5c78376._comment b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_6_11cb8251521014ef81b53090f5c78376._comment
new file mode 100644
index 0000000000..35f9d8d726
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_6_11cb8251521014ef81b53090f5c78376._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-08-30T18:39:33Z"
+ content="""
+Well I've already fixed their problem AFAICS. Just perhaps not the problem
+you are seeing.
+
+Your script does not reproduce any problem here. Are you running it on NFS
+or something?
+
+Anyway, if you can build current master the improved error message will
+probably help me find the problem.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_7_ba7e53135285dbf198f5aa12d7edc1cd._comment b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_7_ba7e53135285dbf198f5aa12d7edc1cd._comment
new file mode 100644
index 0000000000..d59723763f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_7_ba7e53135285dbf198f5aa12d7edc1cd._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-09-01T14:32:11Z"
+ content="""
+I'm going to close this, since I was able to replicate and fix one of the
+errors, and was not able to replicate the other one. If the other one
+still happens, follow up with the output of the current version of
+git-annex, as I've requested 3 times now.
+
+There is a test case now that tests the same thing, too. It has passed
+on all the builders. (Except windows. I've learned git-annex cannot support
+readonly repos on Windows, because it has to be able to create lock files
+there.)
+
+(There are still situations where git-annex needs to write to a repo in order to
+use it. The main one is if the it needs to upgrade the repo. I think
+failing in that specific situation is ok, and it fails with an informative
+error message IIRC. It's also possible there's some other situation of some
+kind where the readonly repo is in a state where git-annex wants to write
+to it, but if there is, I can fix it when the situation comes to light.)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_8_95ff27c621afe43abfd7403f343b612c._comment b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_8_95ff27c621afe43abfd7403f343b612c._comment
new file mode 100644
index 0000000000..e94fe4d5e1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_8_95ff27c621afe43abfd7403f343b612c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="clarification"
+ date="2021-09-01T15:39:06Z"
+ content="""
+FWIW, as I have mentioned, the original issue is reported by a user and I have no access to reproduce \"exactly\" myself.  I am still waiting on user to report success/failure while trying with the [8.20210803-165-g249d424b8](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=8.20210803+git165-g249d424b8) \"up-to-date-back-then\" standalone build on the remote ssh server side.  If still fails, I will build even newer standalone and ask to try again.  Great to hear there is a test case now -- thank you!
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_9_b70343f8cb81807a7da0da5637d8c750._comment b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_9_b70343f8cb81807a7da0da5637d8c750._comment
new file mode 100644
index 0000000000..c9f6e0503b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_content_via_ssh_without_write_perms/comment_9_b70343f8cb81807a7da0da5637d8c750._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-09-01T15:42:35Z"
+ content="""
+The user does not need to do anything, I have reproduced and fixed their
+problem.
+
+You reported a *different* error message when you tried to reproduce it
+yourself. That is the only thing i do not understand, and why I have,
+repeatedly, been trying to ask you to reproduce that error message again.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why.mdwn b/doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why.mdwn
new file mode 100644
index 0000000000..9a10bdcae1
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why.mdwn
@@ -0,0 +1,80 @@
+### Please describe the problem.
+
+As originally reported in the [comments](http://git-annex.branchable.com/devblog/day_518__S3_versioning_finishing_touches/?updated#comment-ecfa9f9e6075bf524a88f404bb19e086) and now wondering if it has to do with the awkwardness of that bucket -- its name has a period in its name, so https validation fails and we had to [workaround for that in datalad](https://github.com/datalad/datalad/commit/ea8977fddbd05faa3f299562b70d4a491a774cea) as well.  In either case - having at least some debug log message about the problem would be handy
+
+[[!format sh """
+test@hopa:/tmp$ mkdir testuser
+test@hopa:/tmp$ cd testuser
+test@hopa:/tmp/testuser$ git clone https://github.com/OpenNeuroDatasets/ds001506 ; cd ds001506; 
+Cloning into 'ds001506'...
+remote: Counting objects: 11017, done.
+remote: Compressing objects: 100% (6694/6694), done.
+remote: Total 11017 (delta 1856), reused 11007 (delta 1846), pack-reused 0
+Receiving objects: 100% (11017/11017), 1.17 MiB | 1.31 MiB/s, done.
+Resolving deltas: 100% (1856/1856), done.
+test@hopa:/tmp/testuser/ds001506$ git annex enableremote s3-PUBLIC public=yes
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+download failed: ConnectionFailure Network.Socket.connect: <socket: 11>: timeout (Connection timed out)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+enableremote s3-PUBLIC ok
+(recording state in git...)
+test@hopa:/tmp/testuser/ds001506$ git annex get --debug sub-01/ses-anatomy/anat
+[2018-09-11 13:00:24.89648131] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","sub-01/ses-anatomy/anat"]
+get sub-01/ses-anatomy/anat/sub-01_ses-anatomy_T1w.nii.gz [2018-09-11 13:00:24.900815381] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-09-11 13:00:24.90536002] process done ExitSuccess
+[2018-09-11 13:00:24.905485937] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-09-11 13:00:24.909586624] process done ExitSuccess
+[2018-09-11 13:00:24.909805571] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..a152bc6cd4a6b1f06115d683e6a296374219e9f7","--pretty=%H","-n1"]
+[2018-09-11 13:00:24.914170223] process done ExitSuccess
+[2018-09-11 13:00:24.914585144] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-09-11 13:00:24.91587481] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+(from s3-PUBLIC...) [2018-09-11 13:00:24.982444067] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff-tree","-z","--raw","--no-renames","-l0","-r","4b825dc642cb6eb9a060e54bf8d69288fbee4904","18df0d827a901db0a989999f765f2816b769bf49","--"]
+[2018-09-11 13:00:24.994539395] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-09-11 13:00:24.995000749] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-09-11 13:00:25.433359795] process done ExitSuccess
+
+  Unable to access these remotes: s3-PUBLIC
+
+  Try making some of these repositories available:
+  	810b2f6b-fb98-4401-9130-6c84dd7ddc50 -- root@b3ba225d5547:/datalad/ds001506
+   	ca9b233b-7567-48b3-89c7-efe7f6a97d4a -- [s3-PUBLIC]
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+[2018-09-11 13:00:25.657658586] process done ExitSuccess
+[2018-09-11 13:00:25.658108866] process done ExitSuccess
+[2018-09-11 13:00:25.658390098] process done ExitSuccess
+[2018-09-11 13:00:25.658635699] process done ExitSuccess
+git-annex: get: 1 failed
+test@hopa:/tmp/testuser/ds001506$ git annex version | head -n 1
+git-annex version: 6.20180807+git230-gaa291acfe-1~ndall+1
+test@hopa:/tmp/testuser/ds001506$ git annex info s3-PUBLIC
+uuid: ca9b233b-7567-48b3-89c7-efe7f6a97d4a
+description: [s3-PUBLIC]
+remote: s3-PUBLIC
+trust: untrusted
+cost: 200.0
+type: S3
+creds: not available
+bucket: openneuro.org
+endpoint: s3.amazonaws.com
+port: 80
+storage class: STANDARD
+partsize: 1.07 gigabytes
+public: yes
+versioning: no
+encryption: none
+chunking: none
+export: yes
+remote annex keys: 1287
+remote annex size: 103.28 gigabytes (+ 632 unknown size)
+
+"""]]
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[[fixed|done]] as the one no longer observed --[[yarikoptic]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why/comment_1_87983a598cacaa8800db4a01ec23ba1b._comment b/doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why/comment_1_87983a598cacaa8800db4a01ec23ba1b._comment
new file mode 100644
index 0000000000..d88c251786
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why/comment_1_87983a598cacaa8800db4a01ec23ba1b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-23T18:59:53Z"
+ content="""
+It kind of looks like this S3 remote is being used without login
+credentials. That's not clear, because you could have environment variables
+set or creds cached, or not.
+
+Since it's "public: yes", it would fall back to the public url code path to
+get the file when there are no creds.
+
+There are a lot of ways that could fail. Eg, perhaps no publicurl has been
+configured for the remote. But in that case (and many other cases),
+an exception should be thrown and displayed.
+
+I think I need to know how to reproduce this to get any further.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why/comment_2_b9e5b868dd5379de18ed77907d1b42a3._comment b/doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why/comment_2_b9e5b868dd5379de18ed77907d1b42a3._comment
new file mode 100644
index 0000000000..ba6ee5534f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why/comment_2_b9e5b868dd5379de18ed77907d1b42a3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-02-27T15:52:10Z"
+ content="""
+Not sure what you meant by \"need to know how to reproduce this to get any further\" since a full example was provided, and to reproduce \"this\" problem, commands could have been cut/paste'ed.
+Now, with all the changes to git-annex, and that dataset (may be next time I would do some kind of fast-export on them or host a dedicated clone), it would indeed be hard if not impossible to reproduce, and I do not observe it with git annex `7.20200219+git135-g34d726cba-1~ndall+1` so I will mark it as done
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why/comment_3_667c5b94580e2ca0305d4ed97c2e199f._comment b/doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why/comment_3_667c5b94580e2ca0305d4ed97c2e199f._comment
new file mode 100644
index 0000000000..d85558c245
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unable_to_get_from_public_S3_remote_without_clear_reasoning_why/comment_3_667c5b94580e2ca0305d4ed97c2e199f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-02-28T17:28:57Z"
+ content="""
+passing public=yes to initremote does not make git-annex use anonymous http
+to access a S3 remote, if you have S3 credentials in the environment. I
+don't remember if I tried to repro it w/o S3 credentials or not, but either
+way the bug is not clear about how git-annex was trying to access the
+remote when it failed.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before.mdwn b/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before.mdwn
new file mode 100644
index 0000000000..11cacc390d
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before.mdwn
@@ -0,0 +1,126 @@
+### Please describe the problem.
+
+Continuation of the prior brief troubleshooting in [devblog](http://git-annex.branchable.com/devblog/day_518__S3_versioning_finishing_touches/#comment-ced84e6126b523170638f36a73cdb4b1).
+
+Joey:
+
+> As to the problems you're having with that S3 remote, it looks like it does not have public=yes enabled in its configuration at all, which is why git-annex is failing to download from it. 
+
+I do not think that is the case.  s3-PUBLIC has `public=yes`.  But it is entirely not clear why git-annex fails to download - no diagnostic error message at --debug level.  Please try yourself:
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+~datalad > git clone https://github.com/OpenNeuroDatasets/ds001419               
+Cloning into 'ds001419'...
+remote: Enumerating objects: 420, done.
+remote: Counting objects: 100% (420/420), done.
+remote: Compressing objects: 100% (232/232), done.
+remote: Total 420 (delta 99), reused 418 (delta 97), pack-reused 0
+Receiving objects: 100% (420/420), 37.43 KiB | 2.88 MiB/s, done.
+Resolving deltas: 100% (99/99), done.
+
+~datalad > cd ds001419 
+
+~datalad/providers/openneuro/ds001419 > git annex enableremote s3-PUBLIC
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+download failed: Not Found
+
+  Remote origin not usable by git-annex; setting annex-ignore
+enableremote s3-PUBLIC ok
+(recording state in git...)
+
+~datalad/providers/openneuro/ds001419 > git annex whereis sub-01/anat/sub-01_T1w.nii.gz                                                                                       
+whereis sub-01/anat/sub-01_T1w.nii.gz (2 copies)  
+  	303581cd-3c58-4a60-b685-42cae4314c68 -- root@1f69c4ed80cf:/datalad/ds001419
+   	c21131c5-9e22-442d-a4d6-22d225603bc9 -- s3-PRIVATE
+
+  The following untrusted locations may also have copies:
+  	336309c0-d7f8-430e-bd2b-4bdc61e587cb -- [s3-PUBLIC]
+ok
+
+~datalad/providers/openneuro/ds001419 > git annex get --from s3-PUBLIC --debug sub-01/anat/sub-01_T1w.nii.gz
+[2018-09-25 11:30:48.623186962] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-09-25 11:30:48.6294298] process done ExitSuccess
+[2018-09-25 11:30:48.629531355] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-09-25 11:30:48.63678286] process done ExitSuccess
+[2018-09-25 11:30:48.637035079] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..a6e5981635fd80f9186e6aa840312a97153508a4","--pretty=%H","-n1"]
+[2018-09-25 11:30:48.648701597] process done ExitSuccess
+[2018-09-25 11:30:48.648965608] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-09-25 11:30:48.649547391] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-09-25 11:30:48.655933893] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","sub-01/anat/sub-01_T1w.nii.gz"]
+get sub-01/anat/sub-01_T1w.nii.gz (from s3-PUBLIC...) [2018-09-25 11:30:48.662890927] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff-tree","-z","--raw","--no-renames","-l0","-r","4b825dc642cb6eb9a060e54bf8d69288fbee4904","3bbd58c6720ad7a764409c219397a4e15e4ed77d","--"]
+[2018-09-25 11:30:48.670609446] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-09-25 11:30:48.672897086] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2018-09-25 11:30:48.681427258] process done ExitSuccess
+failed
+[2018-09-25 11:30:48.740042089] process done ExitSuccess
+[2018-09-25 11:30:48.740263179] process done ExitSuccess
+[2018-09-25 11:30:48.740549287] process done ExitSuccess
+[2018-09-25 11:30:48.740805353] process done ExitSuccess
+git-annex: get: 1 failed
+
+~datalad/providers/openneuro/ds001419 > git cat-file -p git-annex:remote.log
+336309c0-d7f8-430e-bd2b-4bdc61e587cb bucket=openneuro.org datacenter=US encryption=none exporttree=yes fileprefix=ds001419/ host=s3.amazonaws.com name=s3-PUBLIC partsize=1GiB port=80 public=yes publicurl=yes storageclass=STANDARD type=S3 timestamp=1537889429.294083309s
+c21131c5-9e22-442d-a4d6-22d225603bc9 bucket=openneuro-private datacenter=US encryption=none exporttree=yes fileprefix=ds001419/ host=s3.amazonaws.com name=s3-PRIVATE partsize=1GiB port=80 storageclass=STANDARD type=S3 timestamp=1531961539.924031958s
+
+~datalad/providers/openneuro/ds001419 > git annex info
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 5
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	303581cd-3c58-4a60-b685-42cae4314c68 -- root@1f69c4ed80cf:/datalad/ds001419
+ 	3cf65be0-250d-4456-bfee-8501390e28c7 -- yoh@hopa:~/proj/datalad/providers/openneuro/ds001419 [here]
+ 	c21131c5-9e22-442d-a4d6-22d225603bc9 -- s3-PRIVATE
+untrusted repositories: 1
+	336309c0-d7f8-430e-bd2b-4bdc61e587cb -- [s3-PUBLIC]
+transfers in progress: none
+available local disk space: 1.76 gigabytes (+1 megabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 7
+size of annexed files in working tree: 183.03 megabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+	MD5E: 7
+
+~datalad/providers/openneuro/ds001419 > git annex info s3-PUBLIC
+uuid: 336309c0-d7f8-430e-bd2b-4bdc61e587cb
+description: [s3-PUBLIC]
+remote: s3-PUBLIC
+trust: untrusted
+cost: 200.0
+type: S3
+creds: not available
+bucket: openneuro.org
+endpoint: s3.amazonaws.com
+port: 80
+storage class: STANDARD
+partsize: 1.07 gigabytes
+public: yes
+versioning: no
+encryption: none
+chunking: none
+export: yes
+remote annex keys: 27
+remote annex size: 183.03 megabytes (+ 20 unknown size)
+
+"""]]
+
+
+may be it is somehow interaction with the fact that the bucket is versioned, although export happened with annex version which didn't support versioning?
+
+It would be nice, before introducing versioning information as you outlined in the [comment](http://git-annex.branchable.com/devblog/day_518__S3_versioning_finishing_touches/#comment-01400aba452e6596e2b6b2967a0b9bc1) to enable access to the bucket at least to download the most recent version(s) of the file(s).
+
+### What version of git-annex are you using? On what operating system?
+
+6.20180913+git52-gdb1644808-1~ndall+1
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> Added an error message when download of an invalid url is attempted
+> and also made the url be listed by --debug. [[done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_1_08514c489b916b2ae8e4e0122051856f._comment b/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_1_08514c489b916b2ae8e4e0122051856f._comment
new file mode 100644
index 0000000000..769f0f3f59
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_1_08514c489b916b2ae8e4e0122051856f._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-09-25T17:31:36Z"
+ content="""
+Misconfiguration:
+
+	joey@darkstar:~/tmp/ds001419>git show git-annex:remote.log | grep openneuro.org
+	336309c0-d7f8-430e-bd2b-4bdc61e587cb bucket=openneuro.org datacenter=US encryption=none exporttree=yes fileprefix=ds001419/ host=s3.amazonaws.com name=s3-PUBLIC partsize=1GiB port=80 public=yes publicurl=yes storageclass=STANDARD type=S3 timestamp=1537895418.565736858s
+
+publicurl=yes means that the bucket's url is "yes".
+
+Since constructing an URI object from that invalid url fails, the url
+downloader fails early and this avoids the debug output that would normally be
+shown too when downloading an url by recent versions of git-annex.
+
+This also explains probably why whereis doesn't list any urls.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_2_1ae05c24612f50cfe03e2569b332a522._comment b/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_2_1ae05c24612f50cfe03e2569b332a522._comment
new file mode 100644
index 0000000000..2988e47778
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_2_1ae05c24612f50cfe03e2569b332a522._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="resolved!"
+ date="2018-09-25T17:55:30Z"
+ content="""
+oh man, thanks!  indeed I should have noticed it
+
+FTR here is a protocol of manual changes:
+
+[[!format sh \"\"\"
+$> cd ds001419 
+CHANGES  README  dataset_description.json  participants.tsv  sub-01/
+1 5689.....................................:Tue 25 Sep 2018 01:52:13 PM EDT:.
+(git-annex)hopa:~datalad/providers/openneuro/ds001419[master]
+$> git co git-annex                                    
+Switched to branch 'git-annex'
+1 5690.....................................:Tue 25 Sep 2018 01:52:15 PM EDT:.
+(git-annex)hopa:~datalad/providers/openneuro/ds001419[git-annex]git
+$> vim remote.log 
+1 5691.....................................:Tue 25 Sep 2018 01:53:06 PM EDT:.
+(git-annex)hopa:~datalad/providers/openneuro/ds001419[git-annex]git
+$> git diff
+diff --git a/remote.log b/remote.log
+index 162f6f6..6864376 100644
+--- a/remote.log
++++ b/remote.log
+@@ -1,2 +1,2 @@
+-336309c0-d7f8-430e-bd2b-4bdc61e587cb bucket=openneuro.org datacenter=US encryption=none exporttree=yes fileprefix=ds001419/ host=s3.amazonaws.com name=s3-PUBLIC partsize=1GiB port=80 public=yes publicurl=yes storageclass=STANDARD type=S3 timestamp=1537889429.294083309s
++336309c0-d7f8-430e-bd2b-4bdc61e587cb bucket=openneuro.org datacenter=US encryption=none exporttree=yes fileprefix=ds001419/ host=s3.amazonaws.com name=s3-PUBLIC partsize=1GiB port=80 public=yes publicurl=http://openneuro.org.s3.amazonaws.com/ storageclass=STANDARD type=S3 timestamp=1537889429.294083309s
+ c21131c5-9e22-442d-a4d6-22d225603bc9 bucket=openneuro-private datacenter=US encryption=none exporttree=yes fileprefix=ds001419/ host=s3.amazonaws.com name=s3-PRIVATE partsize=1GiB port=80 storageclass=STANDARD type=S3 timestamp=1531961539.924031958s
+1 5695.....................................:Tue 25 Sep 2018 01:53:08 PM EDT:.
+(git-annex)hopa:~datalad/providers/openneuro/ds001419[git-annex]git
+$> git commit -m 'made public url to be http://openneuro.org.s3.amazonaws.com/' -a
+[git-annex 7f1a89e] made public url to be http://openneuro.org.s3.amazonaws.com/
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+1 5696.....................................:Tue 25 Sep 2018 01:53:15 PM EDT:.
+(git-annex)hopa:~datalad/providers/openneuro/ds001419[git-annex]git
+$> git co master
+Switched to branch 'master'
+Your branch is up to date with 'origin/master'.
+1 5697.....................................:Tue 25 Sep 2018 01:53:17 PM EDT:.
+(git-annex)hopa:~datalad/providers/openneuro/ds001419[git-annex]git
+$> git annex get sub-01/anat/sub-01_T1w.nii.gz
+get sub-01/anat/sub-01_T1w.nii.gz (from s3-PUBLIC...) (checksum...) ok
+(recording state in git...)
+
+\"\"\"]]
+
+can be closed, thanks again
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_3_ae81a2ac4b2167d48c8a447811a492a2._comment b/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_3_ae81a2ac4b2167d48c8a447811a492a2._comment
new file mode 100644
index 0000000000..f9032fdcef
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_3_ae81a2ac4b2167d48c8a447811a492a2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2018-09-25T17:56:58Z"
+ content="""
+although if annex would have puked some warning or debug message about incorrect url, it would have saved both of us some time ;)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_4_c49e48ea12ed0a0edb675b532279a5a8._comment b/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_4_c49e48ea12ed0a0edb675b532279a5a8._comment
new file mode 100644
index 0000000000..88fe91a551
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/unclear_why_annex_fails_to_get_a_file_from_a_public_S3_bucket_where_it_exported_before/comment_4_c49e48ea12ed0a0edb675b532279a5a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2018-09-25T17:58:25Z"
+ content="""
+and on the third hand, annex could've generated urls for amazon buckets without mandating to specify them? ;)
+"""]]
diff --git a/doc/projects/datalad/bugs-done/upgrade___40__from_v5__41___fails_without_stating_any_reason__47__hints.mdwn b/doc/projects/datalad/bugs-done/upgrade___40__from_v5__41___fails_without_stating_any_reason__47__hints.mdwn
new file mode 100644
index 0000000000..e9b059708e
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/upgrade___40__from_v5__41___fails_without_stating_any_reason__47__hints.mdwn
@@ -0,0 +1,153 @@
+### Please describe the problem.
+
+I got into a repository I have not used for a while, and then `datalad` commands failed because annex failed to upgrade it from v5.  No details/reason is given at any level making it impossible to figure out for a user what to do/try next:
+
+<details>
+<summary>very original datalad invocation (click to expand)</summary> 
+
+[[!format sh """
+(git-annex)lena:~pymvpa/papers[master]bib
+$> datalad run -m "Regenerate haxbylab_hl.bib" --input haxbylab.bib --output haxbylab_hl.bib --explicit 'make {outputs}'
+[INFO   ] Making sure inputs are available (this may take some time) 
+CommandError: command '['git', '-c', 'annex.merge-annex-branches=false', 'annex', 'find', '-c', 'annex.dotfiles=true', '-c', 'remote.origin.annex-ssh-options=-o ControlMaster=auto -S /home/yoh/.cache/datalad/sockets/git.pymvpa.org -o ControlMaster=auto -S /home/yoh/.cache/datalad/sockets/1d961cfa', '--json', '--json-error-messages', '--not', '--in', '.', '--', 'bib/haxbylab.bib']' failed with exitcode 1
+Failed to run ['git', '-c', 'annex.merge-annex-branches=false', 'annex', 'find', '-c', 'annex.dotfiles=true', '-c', 'remote.origin.annex-ssh-options=-o ControlMaster=auto -S /home/yoh/.cache/datalad/sockets/git.pymvpa.org -o ControlMaster=auto -S /home/yoh/.cache/datalad/sockets/1d961cfa', '--json', '--json-error-messages', '--not', '--in', '.', '--', 'bib/haxbylab.bib'] under '/home/yoh/proj/pymvpa/papers'. Exit code=1. out= err=git-annex: Repository /home/yoh/proj/pymvpa/papers is at unsupported version 5. Automatic upgrade failed!
+
+git-annex: Repository /home/yoh/proj/pymvpa/papers is at unsupported version 5. Automatic upgrade failed!
+"""]]
+
+</details>
+
+[[!format sh """
+$> git annex version
+git-annex version: 8.20200309+git133-gc29943f40-1~ndall+1
+
+$> git annex info
+git-annex: Repository /home/yoh/proj/pymvpa/papers is at unsupported version 5. Automatic upgrade failed!
+
+
+$> git annex upgrade
+upgrade (v5 to v6...) failed
+git-annex: upgrade: 1 failed
+
+
+$> git annex upgrade --debug
+upgrade (v5 to v6...) [2020-05-07 10:52:03.727276447] read: git ["--version"]
+[2020-05-07 10:52:03.730015743] process done ExitSuccess
+[2020-05-07 10:52:03.730119216] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","show-ref","--head"]
+[2020-05-07 10:52:03.733213698] process done ExitSuccess
+[2020-05-07 10:52:03.733691083] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","ls-tree","--full-tree","-z","-r","--","HEAD"]
+[2020-05-07 10:52:03.736803336] chat: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","cat-file","--batch"]
+[2020-05-07 10:52:03.737004108] chat: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2020-05-07 10:52:03.954238715] process done ExitSuccess
+[2020-05-07 10:52:03.954308318] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","status","--porcelain"]
+[2020-05-07 10:52:04.017909723] process done ExitSuccess
+[2020-05-07 10:52:04.018217705] call: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","config","filter.annex.smudge","git-annex smudge -- %f"]
+[2020-05-07 10:52:04.022805323] process done ExitSuccess
+[2020-05-07 10:52:04.022870176] read: git ["config","--null","--list"]
+[2020-05-07 10:52:04.025862758] process done ExitSuccess
+[2020-05-07 10:52:04.025898818] call: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","config","filter.annex.clean","git-annex smudge --clean -- %f"]
+[2020-05-07 10:52:04.028657032] process done ExitSuccess
+[2020-05-07 10:52:04.028691215] read: git ["config","--null","--list"]
+[2020-05-07 10:52:04.031420328] process done ExitSuccess
+failed
+[2020-05-07 10:52:04.055445542] process done ExitSuccess
+[2020-05-07 10:52:04.058899774] process done ExitSuccess
+git-annex: upgrade: 1 failed
+
+"""]]
+
+Downgrading git-annex to 7.20190819+git2-g908476a9b-1~ndall+1 helped to reveal the issue:
+
+[[!format sh """
+$> git annex upgrade --debug                                                     
+upgrade (v5 to v6...) [2020-05-07 10:56:49.99032766] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","show-ref","--head"]
+[2020-05-07 10:56:50.00402489] process done ExitSuccess
+(scanning for unlocked files...)
+[2020-05-07 10:56:50.004777461] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","ls-tree","--full-tree","-z","-r","--","HEAD"]
+[2020-05-07 10:56:50.019113817] chat: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","cat-file","--batch"]
+[2020-05-07 10:56:50.020051726] chat: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2020-05-07 10:56:50.414585722] process done ExitSuccess
+[2020-05-07 10:56:50.414672616] read: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","status","--porcelain"]
+[2020-05-07 10:56:50.532708468] process done ExitSuccess
+[2020-05-07 10:56:50.532790172] call: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","config","filter.annex.smudge","git-annex smudge -- %f"]
+[2020-05-07 10:56:50.536471232] process done ExitSuccess
+[2020-05-07 10:56:50.536530991] read: git ["config","--null","--list"]
+[2020-05-07 10:56:50.540818414] process done ExitSuccess
+[2020-05-07 10:56:50.540897171] call: git ["--git-dir=../.git","--work-tree=..","--literal-pathspecs","config","filter.annex.clean","git-annex smudge --clean -- %f"]
+[2020-05-07 10:56:50.544562826] process done ExitSuccess
+[2020-05-07 10:56:50.544626978] read: git ["config","--null","--list"]
+[2020-05-07 10:56:50.552390589] process done ExitSuccess
+
+git-annex: ../.git/info/attributes: openFile: permission denied (Permission denied)
+failed
+[2020-05-07 10:56:50.57632181] process done ExitSuccess
+[2020-05-07 10:56:50.578345312] process done ExitSuccess
+git-annex: upgrade: 1 failed
+
+$> git annex version
+git-annex version: 7.20190819+git2-g908476a9b-1~ndall+1
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 5
+
+$> git annex info           
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 5
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	4435399f-0e03-432c-9ab2-cab8df04fc9b -- mih@meiner:~/psycho/papers/belka
+ 	bcefa304-7d94-11e3-bb19-532dbfa67366 -- origin
+ 	c44ff4fd-1cfb-46f9-b5d1-c471208c4947 -- yoh@novo:~/proj/pymvpa/papers [here]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 504.74 gigabytes (+1 megabyte reserved)
+temporary object directory size: 10.72 megabytes (clean up with git-annex unused)
+local annex keys: 242
+local annex size: 50.57 megabytes
+annexed files in working tree: 229
+size of annexed files in working tree: 377.47 megabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+	SHA256E: 229
+
+$> git annex upgrade
+upgrade (v5 to v6...) (scanning for unlocked files...)
+
+git-annex: ../.git/info/attributes: openFile: permission denied (Permission denied)
+failed
+git-annex: upgrade: 1 failed
+
+"""]]
+
+note that `info` works out without failing to upgrade with that older version.
+
+and indeed somehow I have:
+
+[[!format sh """
+$> ls -ld ../.git/info/attributes           
+-rw-r--r-- 1 root yoh 39 Jun  5  2009 ../.git/info/attributes
+
+$> find .git -uid 0
+.git/hooks/pre-commit.disabled
+.git/info/attributes
+"""]]
+
+fixing ownership and rerunning upgrade worked (older version was remained used):
+[[!format sh """
+$> git annex upgrade
+upgrade (v5 to v6...) (scanning for unlocked files...)
+(v6 to v7...) ok
+"""]]
+
+So it seems git-annex should revert back to reporting errors from underlying `git` invocations to make it possible to debug such cases
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]], thanks for tracking it back to the root cause. --[[Joey]] 
diff --git a/doc/projects/datalad/bugs-done/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink.mdwn b/doc/projects/datalad/bugs-done/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink.mdwn
new file mode 100644
index 0000000000..39ebc8d21f
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink.mdwn
@@ -0,0 +1,50 @@
+### Please describe the problem.
+
+Created a temp repository with a submodule under 3rd/visloc referring to another annex via ssh
+
+[[!format sh """
+
+# I have removed some output/wrong cmd calls, hopefully without side-effects
+
+hopa:/tmp/test
+$> cat 3rd/visloc/.git
+gitdir: ../../.git/modules/3rd/visloc
+
+$> git commit -m 'RF: ...' -a                                
+[master (root-commit) fc37b4f] RF: ...
+ 2 files changed, 4 insertions(+)
+ create mode 100644 .gitmodules
+ create mode 160000 3rd/visloc
+
+$> ls -l 3rd/visloc/.git                                                                            
+-rw------- 1 yoh yoh 38 Feb  8 10:26 3rd/visloc/.git
+
+$> cat 3rd/visloc/.git
+gitdir: ../../.git/modules/3rd/visloc
+
+$> cd 3rd/visloc/sub-01/rois 
+
+$> git annex get *
+fatal: Not a git repository: '../../.git'
+git-annex: First run: git-annex init
+
+$> cd -
+/tmp/test
+
+$> ls -l 3rd/visloc/.git    
+lrwxrwxrwx 1 yoh yoh 41 Feb  8 10:43 3rd/visloc/.git -> ../../../../../../.git/modules/3rd/visloc
+
+$> git annex version
+git-annex version: 6.20160126+gitg65f4442-1~ndall+1
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput DNS TDFA TorrentParser Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 5 6
+upgrade supported from repository versions: 0 1 2 4 5
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]]
diff --git a/doc/projects/datalad/bugs-done/using_regular_magic_file__warning_pollutes_stderr.mdwn b/doc/projects/datalad/bugs-done/using_regular_magic_file__warning_pollutes_stderr.mdwn
new file mode 100644
index 0000000000..c401a6d6b7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/using_regular_magic_file__warning_pollutes_stderr.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+
+Although probably not an annex issue but thought to let you know since you might see
+a quick resolution on your end
+
+Here is the log from datalad:
+
+[[!format sh """
+2016-02-25 22:53:32,886 [DEBUG] Running: ['git', '-c', 'receive.autogc=false', '-c', 'annex.alwayscommit=false', 'annex', 'add', '--debug', '--json', '-c', 'annex.largefiles=exclude=CHANGES* and exclude=README* and exclude=*.[mc] and exclude=dataset*.json and (exclude=*.txt or include=*/*.txt)  and (exclude=*.json or include=*/*.json) and (exclude=*.tsv or include=*/*.tsv)', 'README.txt'] (cmd.py:351)
+2016-02-25 22:53:32,979 [ERROR] stderr| /etc/magic, 4: Warning: using regular magic file `/usr/share/misc/magic' (cmd.py:351)
+
+
+or outside (file is already under annex)
+
+$> git annex --debug add -c 'annex.largefiles=exclude=CHANGES* and exclude=README*' README.txt
+/etc/magic, 4: Warning: using regular magic file `/usr/share/misc/magic'
+
+"""]]
+
+annex is up to date: 6.20160225+gitg229db26-1~ndall+1
+
+edit1: that is happening on jessie with file 1:5.22+15-2+deb8u1 if that is relevant
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__.mdwn b/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__.mdwn
new file mode 100644
index 0000000000..01b87c9e79
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__.mdwn
@@ -0,0 +1,52 @@
+### Please describe the problem.
+
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> mkdir repo; cd repo; git init; git annex init; git annex upgrade; mkdir -p subdir; cd subdir; touch file; git add file
+Initialized empty Git repository in /tmp/repo/.git/
+init  ok
+(recording state in git...)
+upgrade (v5 to v6...) ok
+git-annex: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
+error: external filter 'git-annex smudge --clean %f' failed 1
+error: external filter 'git-annex smudge --clean %f' failed
+
+$> echo $?; git status
+0
+git-annex: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
+error: external filter 'git-annex smudge --clean %f' failed 1
+error: external filter 'git-annex smudge --clean %f' failed
+On branch master
+
+Initial commit
+
+Changes to be committed:
+  (use "git rm --cached <file>..." to unstage)
+
+	new file:   file
+
+$> git commit -m 'added file'
+git-annex: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
+
+$> echo $?
+1
+
+$> git annex version
+git-annex version: 6.20180807+git230-gaa291acfe-1~ndall+1
+
+"""]]
+
+also happens with 6.20180807-1  but not with 6.20170101-1+deb9u2, so it is a regression
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_1_1c86937cee067b5980852fcb066b0bfb._comment b/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_1_1c86937cee067b5980852fcb066b0bfb._comment
new file mode 100644
index 0000000000..dbf7debf7b
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_1_1c86937cee067b5980852fcb066b0bfb._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="the reason is system wide git version!"
+ date="2018-09-07T00:13:33Z"
+ content="""
+HA -- it is compatibility issue with git somewhere.  
+I had system wide 1:2.13.0~rc1+next.20170430-1~nd90+1  installation of git, and that was the reason.  Similar blows with 1:2.11.0-3+nd1~nd90+1, but works fine with 1:2.19.0~rc2-1 .
+At least that explains how we did not run into it while testing in DataLad:
+
+1. we use git bundled with git-annex when git annex standalone is installed
+2. We use \"git annex add\" and not \"git add\" directly even in v6 mode repos
+
+But it brings the point of possibly needing to test with a regular debian build of git annex more  which would use system-wide git. Also that may be git annex should test git version used and blow with informative message whenever git is too old?
+"""]]
diff --git a/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_2_bd552525b7bb2ceaad72c8fa3bf41c6b._comment b/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_2_bd552525b7bb2ceaad72c8fa3bf41c6b._comment
new file mode 100644
index 0000000000..1921f54b5a
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_2_bd552525b7bb2ceaad72c8fa3bf41c6b._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-09-11T17:39:05Z"
+ content="""
+There are a few places in git-annex where it runs git with the cwd
+overridden, eg to the top of a git repository.
+If it somehow comes up with a path that doesn't exist,
+that would explain this error. The most likely one is
+in `Git.Config.read'`, which git-annex always runs at startup.
+
+So it probably comes down to git running the clean filter with
+the wrong `GIT_DIR` setting or something like that, leading to this as a
+cascading failure. And I vaguely remember seeing something like that in the
+git commit log, or having dealt with such a problem before.
+
+We could make git-annex upgrade fail to run with too old a git (and it
+probably should at least when used with a git too old to support
+smudge/clean filters at all!), but it wouldn't help if the repository was
+upgraded in a different environment. git is going to run the git-annex via
+the clean filter before any check can happen and the most git-annex can
+then do is error out somehow.
+
+See also
+<http://git-annex.branchable.com/forum/Why_git_commit_fails_from_within_a_newly_git-annexed_subdir__63__/>
+which seems to be the same problem without v6; they didn't say what git
+version.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_3_8cfa8fe790ff2586374f46ed10cc8fbe._comment b/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_3_8cfa8fe790ff2586374f46ed10cc8fbe._comment
new file mode 100644
index 0000000000..0057472a71
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_3_8cfa8fe790ff2586374f46ed10cc8fbe._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-09-11T18:08:43Z"
+ content="""
+Ah yes, I was remembering this workaround in git-annex:
+
+	* v6: Work around git bug that runs smudge/clean filters at the top of the
+	  repository while passing them a relative GIT_WORK_TREE that may point
+	  outside of the repository, by using GIT_PREFIX to get back to the
+	  subdirectory where a relative GIT_WORK_TREE is valid.
+
+Perhaps that broke with some older versions of git.
+[[!commit e50ed4ba48f93cf0addb3638a4a9605a10f17976]]
+has the gory details, which includes a git bug.
+
+A good way to debug this is to set:
+
+	git config filter.annex.clean 'bash -c "set | grep GIT_ >&2; pwd >&2; git-annex smudge --clean %f"'
+
+Then when git runs the clean filter it will display the git environment variables.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_4_40e9a5b641200c92725df31a654b6a05._comment b/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_4_40e9a5b641200c92725df31a654b6a05._comment
new file mode 100644
index 0000000000..c5813f3899
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_4_40e9a5b641200c92725df31a654b6a05._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-09-11T18:33:22Z"
+ content="""
+Reproduced in a debian stable chroot with current git-annex in it.
+
+	root@darkstar:/tmp# mkdir repo; cd repo; git init; git annex init; git annex upgrade; git config filter.annex.clean 'bash -c "set | grep GIT_ >&2; pwd >&2; git-annex smudge --clean %f"' ; mkdir -p subdir; cd subdir; touch file; git add file
+	...
+	GIT_DIR=.git
+	GIT_PREFIX=subdir/
+	/tmp/repo
+	git-annex: git: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)
+
+Verifies my theory.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_5_eaafc970cce2c71ce29f136c90e04504._comment b/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_5_eaafc970cce2c71ce29f136c90e04504._comment
new file mode 100644
index 0000000000..acb36873f3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/v6_-_under_subdir__58___git_add___34__whines__34____44___git_commit___34__blows__34__/comment_5_eaafc970cce2c71ce29f136c90e04504._comment
@@ -0,0 +1,57 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-09-11T18:51:07Z"
+ content="""
+Unfortunately git 2.11.0 has the bug that I made git-annex look at
+`GIT_PREFIX` to avoid.
+
+	root@darkstar:/tmp/repo/foo/bar# git --work-tree=../.. ls-files --modified /tmp/repo/
+	BASH_EXECUTION_STRING='set | grep GIT_ >&2; pwd >&2; git-annex smudge --clean '\''subdir/file'\'''
+	GIT_DIR=/tmp/repo/.git
+	GIT_PREFIX=foo/bar/
+	GIT_WORK_TREE=../..
+	/tmp/repo
+
+So, it's not as simple as not looking at `GIT_PREFIX` at all with this
+version of git. When `GIT_WORK_TREE` is relative, and `GIT_PREFIX` is set,
+it needs to combine them to get the actual path to the work tree.
+
+Perhaps git-annex should only use `GIT_PREFIX` 
+for fixup of relative `GIT_WORK_TREE`, but not for `GIT_DIR`. I've so
+far only seen it be needed for `GIT_WORK_TREE`; I only made it also
+be used for `GIT_DIR` out of an assumption git would be consistent in its
+bugginess.
+
+Oh hell, here's another way it fails, with git 2.19:
+
+	joey@darkstar:/tmp/repo/subdir/foo> git --work-tree=../.. status
+	BASH_EXECUTION_STRING='set | grep GIT_ >&2; pwd >&2; git-annex smudge --clean '\''subdir/file'\'''
+	GIT_DIR=/tmp/repo/.git
+	GIT_EXEC_PATH=/usr/lib/git-core
+	GIT_MERGE_AUTOEDIT=no
+	GIT_PAGER=
+	GIT_PREFIX=subdir/foo/
+	GIT_WORK_TREE=.
+	/tmp/repo
+	git-annex: subdir/file: getFileStatus: does not exist (No such file or directory)
+	git-annex: smudge: 1 failed
+
+That one does not involve `GIT_DIR`, instead `GIT_WORK_TREE` is not relative to
+`GIT_PREFIX` so the workaround that assumes it is breaks. I guess that we
+could say that `GIT_DIR` is not relative to some directory in this case,
+so the `GIT_PREFIX` is irrelevant.
+
+Kind of feels like git's behavior is so inconsistent and ill-specified
+that trying to work around the bugs in it is likely to just be a neverending
+source of bugs.
+
+Unfortunately the git devs have so far ignored my bug report despite it
+having an easy test case needing nothing more than a simple shell script to
+reproduce. And there are plenty of differently broken git versions out there
+even if they eventually fix it, so it seems git-annex has to deal with this
+mess somehow.
+
+I'm going with not using `GIT_PREFIX` for `GIT_DIR` and not for
+`GIT_WORK_TREE=.` and hope that's enough.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck.mdwn b/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck.mdwn
new file mode 100644
index 0000000000..99f3e3a2da
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+
+today's build/git-annex test on smaug failed testing due to running out of time (3600 seconds were given):
+
+```
++ source testlib.sh
++ workdir_base /mnt/datasets/datalad/git-annex-build-client
++ WORKDIR_BASE=/mnt/datasets/datalad/git-annex-build-client
++ mkdir -p /mnt/datasets/datalad/git-annex-build-client/698
++ trap 'cd "$WORKDIR_BASE" && chmod -R +w "$BUILDNO" && rm -rf "$BUILDNO"' EXIT
++ cd /mnt/datasets/datalad/git-annex-build-client/698
++ git annex version
+git-annex version: 10.20220504+git37-g514f50e5b-1~ndall+1
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
++ timeout 3600 git annex test
+Tests
+  Tasty
+    tasty self-check:                       
+...
+All 6 tests passed (115.95s)
+Tests
+  Tasty
+    tasty self-check:                      OK
+      +++ OK, passed 1 test.
+  Repo Tests v8 adjusted unlocked branch
+    Init Tests
+      init:                                OK (3.21s)
+      add:                                 OK (11.10s)
+    conflict resolution (adjusted branch): + cd /mnt/datasets/datalad/git-annex-build-client
++ chmod -R +w 698
++ rm -rf 698
+```
+
+didn't happen before AFAIK:
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/05[master]git
+$> git grep 'conflict resolution (adj' | grep -v OK
+result-smaug-698/handle-result.yaml-122-ffec0fe3-success/result-smaug-698/git-annex.log:    conflict resolution (adjusted branch): + cd /mnt/datasets/datalad/git-annex-build-client
+```
+
+and was ok on subsequent run:
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/05[master]git
+$> git grep 'conflict resolution (adj' result-smaug-699 
+result-smaug-699/handle-result.yaml-123-3c5c350a-success/result-smaug-699/git-annex.log:    conflict resolution (adjusted branch): OK (65.14s)
+result-smaug-699/handle-result.yaml-123-3c5c350a-success/result-smaug-699/git-annex.log:    conflict resolution (adjusted branch): OK (38.77s)
+result-smaug-699/handle-result.yaml-123-3c5c350a-success/result-smaug-699/git-annex.log:    conflict resolution (adjusted branch): OK (51.34s)
+```
+
+I don't know if that was somehow a fluke that may be testing of git-annex is in  general close to an hour on smaug, or it was too busy -- but unlikely.  I am adding Elapsed time reporting https://github.com/datalad/git-annex/pull/126
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] hopefully... --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_1_d530fb679b76e995c466fe17c3aab830._comment b/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_1_d530fb679b76e995c466fe17c3aab830._comment
new file mode 100644
index 0000000000..0f51814161
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_1_d530fb679b76e995c466fe17c3aab830._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-18T18:05:04Z"
+ content="""
+That test case only runs a few simple git-annex commands, there is not anything
+that takes a long time or that can loop.
+
+One possibility is that [[todo/test_suite_unsafe_use_of_setEnv]] could have
+led to some undefined behavior that caused it to hang.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_2_dcc764525370338fbf9b6f2728e3e5ac._comment b/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_2_dcc764525370338fbf9b6f2728e3e5ac._comment
new file mode 100644
index 0000000000..aea3cf2772
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_2_dcc764525370338fbf9b6f2728e3e5ac._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-05-18T20:47:12Z"
+ content="""
+I've fixed that setEnv problem now, so the test suite is free of strange
+segfault behavior, hopefully. And hopefully that will also avoid this bug
+from happening more.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_3_7c9fc177fcb76b76765cece36b4f939e._comment b/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_3_7c9fc177fcb76b76765cece36b4f939e._comment
new file mode 100644
index 0000000000..5e5f8085a7
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_3_7c9fc177fcb76b76765cece36b4f939e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-06-02T16:05:11Z"
+ content="""
+I checked smaug and it has not happened again. It may be best to close this
+bug as presumptively fixed unless it is seen to reoccur.
+"""]]
diff --git a/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_4_981d6d42f411476d1a5e38d987af6035._comment b/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_4_981d6d42f411476d1a5e38d987af6035._comment
new file mode 100644
index 0000000000..03f5774bd2
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/v8_conflict_resolution___40__adjusted_branch__41___teststuck/comment_4_981d6d42f411476d1a5e38d987af6035._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2022-06-03T01:40:17Z"
+ content="""
+FWIW indeed seems that all tests passed in reasonable time on smaug since I have added reporting of elapsed time:
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex-ci-client-jobs[master]builds/2022
+$> git submodule foreach \"git grep '^Elapsed time: [0-9]' | grep smaug || :\"
+Entering '02'
+Entering '03'
+Entering '04'
+Entering '05'
+result-smaug-700/handle-result.yaml-125-88838e79-success/result-smaug-700/git-annex.log:Elapsed time: 437 seconds
+result-smaug-701/handle-result.yaml-127-0b187de0-success/result-smaug-701/git-annex.log:Elapsed time: 404 seconds
+result-smaug-702/handle-result.yaml-129-d31f0988-success/result-smaug-702/git-annex.log:Elapsed time: 406 seconds
+result-smaug-703/handle-result.yaml-131-92d8565a-success/result-smaug-703/git-annex.log:Elapsed time: 496 seconds
+result-smaug-704/handle-result.yaml-133-25ffc5f5-success/result-smaug-704/git-annex.log:Elapsed time: 432 seconds
+result-smaug-705/handle-result.yaml-135-8d90e5e7-success/result-smaug-705/git-annex.log:Elapsed time: 411 seconds
+result-smaug-706/handle-result.yaml-137-b47dd77c-success/result-smaug-706/git-annex.log:Elapsed time: 427 seconds
+result-smaug-707/handle-result.yaml-139-ee5bee3b-success/result-smaug-707/git-annex.log:Elapsed time: 563 seconds
+result-smaug-709/handle-result.yaml-141-4dda2de6-success/result-smaug-709/git-annex.log:Elapsed time: 419 seconds
+result-smaug-710/handle-result.yaml-143-7df269b8-success/result-smaug-710/git-annex.log:Elapsed time: 442 seconds
+result-smaug-711/handle-result.yaml-145-206b0f6a-success/result-smaug-711/git-annex.log:Elapsed time: 414 seconds
+result-smaug-712/handle-result.yaml-147-fc2e89a9-success/result-smaug-712/git-annex.log:Elapsed time: 577 seconds
+result-smaug-713/handle-result.yaml-149-e633d635-success/result-smaug-713/git-annex.log:Elapsed time: 448 seconds
+result-smaug-714/handle-result.yaml-151-5156c589-success/result-smaug-714/git-annex.log:Elapsed time: 429 seconds
+Entering '06'
+result-smaug-715/handle-result.yaml-153-daa2f773-success/result-smaug-715/git-annex.log:Elapsed time: 411 seconds
+result-smaug-716/handle-result.yaml-155-5e82d554-success/result-smaug-716/git-annex.log:Elapsed time: 645 seconds
+```
+"""]]
diff --git a/doc/projects/datalad/bugs-done/wanted_on_read-only_repo_crashes_.mdwn b/doc/projects/datalad/bugs-done/wanted_on_read-only_repo_crashes_.mdwn
new file mode 100644
index 0000000000..ab59f9e7d0
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/wanted_on_read-only_repo_crashes_.mdwn
@@ -0,0 +1,61 @@
+### Please describe the problem.
+
+follow up on this particular issue from [https://git-annex.branchable.com/bugs/merge-annex-branches__61__false_-_automate_and_extend/#comment-5d414fbc11cff204b9bcc93685e3bbcb](https://git-annex.branchable.com/bugs/merge-annex-branches__61__false_-_automate_and_extend/#comment-5d414fbc11cff204b9bcc93685e3bbcb) . 
+
+### What steps will reproduce the problem?
+
+Couldn't reproduce on original machine/repo since that one was updated and same error does not appear any longer.  
+
+So did from scratch on some arbitrary repo but caught another "problem" (or not -- for you to decide) that `annex` would crash if I did not init it yet:
+
+
+```shell
+lena:/tmp
+$> umask 022
+1 28194.....................................:Wed 08 Dec 2021 01:49:40 PM EST:.
+lena:/tmp
+$> git clone http://datasets.datalad.org/repronim/containers/.git
+Cloning into 'containers'...
+remote: Enumerating objects: 6123, done.
+remote: Counting objects: 100% (6123/6123), done.
+remote: Compressing objects: 100% (3691/3691), done.
+remote: Total 6123 (delta 3353), reused 2747 (delta 1502)
+Receiving objects: 100% (6123/6123), 609.01 KiB | 4.61 MiB/s, done.
+Resolving deltas: 100% (3353/3353), done.
+1 28195.....................................:Wed 08 Dec 2021 01:49:43 PM EST:.
+lena:/tmp
+$> cd containers 
+LICENSE  README.md  artwork/  binds/  images/  licenses/  scripts/  travis/
+1 28196.....................................:Wed 08 Dec 2021 01:49:46 PM EST:.
+(git)lena:/tmp/containers[master]
+$> git update-ref refs/remotes/origin/git-annex refs/remotes/origin/git-annex^
+1 28197.....................................:Wed 08 Dec 2021 01:49:53 PM EST:.
+(git)lena:/tmp/containers[master]
+$> sudo -u nobody git -c annex.merge-annex-branches=false annex wanted here   
+fatal: cannot lock ref 'refs/heads/git-annex': Unable to create '/tmp/containers/.git/refs/heads/git-annex.lock': Permission denied
+error: could not lock config file .git/config: Permission denied
+git-annex: git [Param "config",Param "user.name",Param "nobody"] failed
+CallStack (from HasCallStack):
+  error, called at ./Git/Command.hs:42:17 in main:Git.Command
+1 28198 ->1.....................................:Wed 08 Dec 2021 01:49:58 PM EST:.
+(git)lena:/tmp/containers[master]git
+$> sudo -u nobody git annex wanted here         
+fatal: cannot lock ref 'refs/heads/git-annex': Unable to create '/tmp/containers/.git/refs/heads/git-annex.lock': Permission denied
+error: could not lock config file .git/config: Permission denied
+git-annex: git [Param "config",Param "user.name",Param "nobody"] failed
+CallStack (from HasCallStack):
+  error, called at ./Git/Command.hs:42:17 in main:Git.Command
+1 28199 ->1.....................................:Wed 08 Dec 2021 01:50:07 PM EST:.
+(git)lena:/tmp/containers[master]git
+$> git annex version
+git-annex version: 8.20211123
+...
+```
+
+the issue is different from original but still might be worth addressing one way or another (e.g. by providing a specific informative message that it was not yet init-ed)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> added a note that the errors were encountered during autonit
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/wanted_started_to_dump_debug_output_to_stdout_.mdwn b/doc/projects/datalad/bugs-done/wanted_started_to_dump_debug_output_to_stdout_.mdwn
new file mode 100644
index 0000000000..a078f58095
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/wanted_started_to_dump_debug_output_to_stdout_.mdwn
@@ -0,0 +1,68 @@
+### Please describe the problem.
+
+regression
+
+<details>
+<summary>with 8.20210330-1~ndall+1 -- goes to stderr</summary> 
+
+```shell
+(git-annex)lena:~/.tmp/datalad_temp__test_target_ssh_inherit45vhem5p[master]git-annex
+$> git annex --debug wanted magical >/dev/null
+[2021-07-07 17:54:22.761087128] process [1831247] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2021-07-07 17:54:22.764910568] process [1831247] done ExitSuccess
+[2021-07-07 17:54:22.765204421] process [1831248] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-07-07 17:54:22.769148287] process [1831248] done ExitSuccess
+[2021-07-07 17:54:22.769446197] process [1831249] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..304037fd0d391f6355dd47c597e68873ad9f1f95","--pretty=%H","-n1"]
+[2021-07-07 17:54:22.774727009] process [1831249] done ExitSuccess
+[2021-07-07 17:54:22.77555157] process [1831250] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-07-07 17:54:22.782439234] process [1831251] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-07-07 17:54:22.783351669] process [1831252] read: git ["config","--null","--list"]
+[2021-07-07 17:54:22.790612497] process [1831252] done ExitSuccess
+[2021-07-07 17:54:22.79412946] process [1831250] done ExitSuccess
+[2021-07-07 17:54:22.795914732] process [1831251] done ExitSuccess
+(dev3) 1 20603.....................................:Wed 07 Jul 2021 05:54:22 PM EDT:.
+(git-annex)lena:~/.tmp/datalad_temp__test_target_ssh_inherit45vhem5p[master]git-annex
+$> git annex version | head -n 1
+git-annex version: 8.20210330-1~ndall+1
+(dev3) 1 20604.....................................:Wed 07 Jul 2021 05:54:32 PM EDT:.
+(git-annex)lena:~/.tmp/datalad_temp__test_target_ssh_inherit45vhem5p[master]git-annex
+$> git annex  wanted magical           
+
+
+```
+</details>
+
+<details>
+<summary>with newer -- stdout</summary> 
+
+```shell
+(git-annex)lena:~/.tmp/datalad_temp__test_target_ssh_inherit45vhem5p[master]git-annex
+$> git annex version | head -n 1                                                                                           
+git-annex version: 8.20210630-1~ndall+1
+(dev3) 1 20607.....................................:Wed 07 Jul 2021 05:56:18 PM EDT:.
+(git-annex)lena:~/.tmp/datalad_temp__test_target_ssh_inherit45vhem5p[master]git-annex
+$> git annex --debug wanted magical >/dev/null
+(dev3) 1 20608.....................................:Wed 07 Jul 2021 05:56:22 PM EDT:.
+(git-annex)lena:~/.tmp/datalad_temp__test_target_ssh_inherit45vhem5p[master]git-annex
+$> git annex --debug wanted magical           
+[2021-07-07 17:56:27.664305073] (Utility.Process) process [1832476] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2021-07-07 17:56:27.667788119] (Utility.Process) process [1832476] done ExitSuccess
+[2021-07-07 17:56:27.668248788] (Utility.Process) process [1832477] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2021-07-07 17:56:27.671956413] (Utility.Process) process [1832477] done ExitSuccess
+[2021-07-07 17:56:27.672539643] (Utility.Process) process [1832478] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","log","refs/heads/git-annex..304037fd0d391f6355dd47c597e68873ad9f1f95","--pretty=%H","-n1"]
+[2021-07-07 17:56:27.679373344] (Utility.Process) process [1832478] done ExitSuccess
+[2021-07-07 17:56:27.695953125] (Utility.Process) process [1832479] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2021-07-07 17:56:27.698411189] (Utility.Process) process [1832480] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2021-07-07 17:56:27.704051561] (Utility.Process) process [1832481] read: git ["config","--null","--list"]
+[2021-07-07 17:56:27.713735999] (Utility.Process) process [1832481] done ExitSuccess
+
+[2021-07-07 17:56:27.717332702] (Utility.Process) process [1832479] done ExitSuccess
+[2021-07-07 17:56:27.718511353] (Utility.Process) process [1832480] done ExitSuccess
+(dev3) 1 20609.....................................:Wed 07 Jul 2021 05:56:27 PM EDT:.
+```
+</details>
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> All commands did. [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/whereis_shouldn__39__t_just_crash_if_one_of_the_special_remotes___34__drivers__34___is_not_available.mdwn b/doc/projects/datalad/bugs-done/whereis_shouldn__39__t_just_crash_if_one_of_the_special_remotes___34__drivers__34___is_not_available.mdwn
new file mode 100644
index 0000000000..fee0a997d6
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/whereis_shouldn__39__t_just_crash_if_one_of_the_special_remotes___34__drivers__34___is_not_available.mdwn
@@ -0,0 +1,40 @@
+[[!format sh """
+(git-annex)hopa:~/datalad/neurovault/snapshots[master]
+$> git annex whereis 1003/13873.nii.gz
+whereis 1003/13873.nii.gz git-annex: Cannot run git-annex-remote-datalad-archives -- It is not installed in PATH (/usr/lib/git-annex.linux/bin:/usr/lib/git-core:/home/yoh/gocode/bin:/home/yoh/gocode/bin:/home/yoh/bin:/home/yoh/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/lib/git-annex.linux/extra)
+
+
+$> source ~datalad/datalad-master/venvs/dev/bin/activate
+
+$> git annex whereis 1003/13873.nii.gz                  
+whereis 1003/13873.nii.gz (3 copies) 
+  	123c73e5-a8dc-4cff-8ffc-679c7ea67f94 -- yoh@smaug:/mnt/datasets/datalad/crawl/neurovault
+   	48c1556f-6241-45de-9497-338d437fcb62 -- yoh@falkor:/srv/datasets.datalad.org/www/neurovault/snapshots [origin]
+   	af2785da-2538-4346-a6f6-f2f30fc3f025 -- [datalad-archives]
+
+  datalad-archives: dl+archive:SHA256E-s6460020224--710cc05117e2290e2f793271d11e26452cdc111121e09a937dbf5a34b3cc0107.tar/neurovault_snapshot/1003/13873.nii.gz#size=23262
+
+$> git annex version
+git-annex version: 6.20180807+git230-gaa291acfe-1~ndall+1
+"""]]
+
+IMHO output should be like (since all information is actually available)
+
+[[!format sh """
+$> git annex whereis 1003/13873.nii.gz
+git-annex: ERROR - Cannot run git-annex-remote-datalad-archives
+whereis 1003/13873.nii.gz (3 copies)
+  	123c73e5-a8dc-4cff-8ffc-679c7ea67f94 -- yoh@smaug:/mnt/datasets/datalad/crawl/neurovault
+   	48c1556f-6241-45de-9497-338d437fcb62 -- yoh@falkor:/srv/datasets.datalad.org/www/neurovault/snapshots [origin]
+   	af2785da-2538-4346-a6f6-f2f30fc3f025 -- datalad-archives {ERROR}
+
+  datalad-archives: dl+archive:SHA256E-s6460020224--710cc05117e2290e2f793271d11e26452cdc111121e09a937dbf5a34b3cc0107.tar/neurovault_snapshot/1003/13873.nii.gz#size=23262
+"""]]
+
+and indeed with error code exit may be.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+
+> [[wontfix|done]], see my comment --[[Joey]]
diff --git a/doc/projects/datalad/bugs-done/whereis_shouldn__39__t_just_crash_if_one_of_the_special_remotes___34__drivers__34___is_not_available/comment_1_3f8100a4d9e6ab4302c89eeafd0f843e._comment b/doc/projects/datalad/bugs-done/whereis_shouldn__39__t_just_crash_if_one_of_the_special_remotes___34__drivers__34___is_not_available/comment_1_3f8100a4d9e6ab4302c89eeafd0f843e._comment
new file mode 100644
index 0000000000..40f5b4cba3
--- /dev/null
+++ b/doc/projects/datalad/bugs-done/whereis_shouldn__39__t_just_crash_if_one_of_the_special_remotes___34__drivers__34___is_not_available/comment_1_3f8100a4d9e6ab4302c89eeafd0f843e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-09-12T18:16:49Z"
+ content="""
+Hmm, but the special remote can add urls to the whereis output, indeed it
+is doing so in your example. So if the repository has the special remote
+enabled it seems it ought to need it to be in working order.
+
+External special remote programs are only spun up on demand, so the only
+way to get to this crash is when it's actually being used for something,
+AFAICS.
+"""]]
diff --git a/doc/projects/datalad/done.mdwn b/doc/projects/datalad/done.mdwn
new file mode 100644
index 0000000000..c298dba684
--- /dev/null
+++ b/doc/projects/datalad/done.mdwn
@@ -0,0 +1 @@
+This bug was closed, and has been archived.
diff --git a/doc/projects/datalad/potential.mdwn b/doc/projects/datalad/potential.mdwn
new file mode 100644
index 0000000000..4b24dc3f19
--- /dev/null
+++ b/doc/projects/datalad/potential.mdwn
@@ -0,0 +1,5 @@
+These are TODOs that have been tagged as potentially being useful for
+[[/projects/DataLad]] or a related project to fund work on.
+
+[[!inline pages="todo/* and !todo/done and !link(todo/done) and tagged(projects/datalad/potential)"
+sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]]
diff --git a/doc/projects/neurohub.mdwn b/doc/projects/neurohub.mdwn
new file mode 100644
index 0000000000..a501b686e7
--- /dev/null
+++ b/doc/projects/neurohub.mdwn
@@ -0,0 +1,25 @@
+NeuroHub [???](???)
+==========================================================
+
+???
+
+## TODOs
+
+[[!inline pages="todo/* and !todo/done and !link(todo/done) and tagged(projects/neurohub)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+### Done:
+
+[[!inline pages="todo/* and !todo/done and link(todo/done) and tagged(projects/neurohub)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+
+
+## BUGs
+
+[[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and tagged(projects/heurohub)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+### Done:
+
+[[!inline pages="bugs/* and !bugs/done and link(bugs/done) and tagged(projects/neurohub)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+
+
diff --git a/doc/projects/openneuro.mdwn b/doc/projects/openneuro.mdwn
new file mode 100644
index 0000000000..e822f437c6
--- /dev/null
+++ b/doc/projects/openneuro.mdwn
@@ -0,0 +1,28 @@
+OpenNeuro ([openneuro.org](https://openneuro.org))
+==================================================
+
+[OpenNeuro](https://openneuro.org) is a free and open platform for sharing [BIDS](https://bids.neuroimaging.io)-compliant neuroimaging (MRI, PET, MEG, EEG, and iEEG) data. 
+Git-annex is the core tool for data logistics at OpenNeuro, e.g. for exporting the content to AWS S3 into open `openneuro.org` S3 bucket, and providing all datasets as DataLad datasets (git/git-annex repositories with a unique DataLad ID) from the [github.com/OpenNeuroDatasets](https://github.com/OpenNeuroDatasets) organization.
+
+## TODOs
+
+[[!inline pages="todo/* and !todo/done and !link(todo/done) and tagged(projects/openneuro)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+<details>
+<summary>Done</summary>
+
+[[!inline pages="todo/* and !todo/done and link(todo/done) and tagged(projects/openneuro)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+</details>
+
+## BUGs
+
+[[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and tagged(projects/openneuro)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+<details>
+<summary>Done</summary>
+
+[[!inline pages="((bugs/* and !bugs/done and link(bugs/done)) or projects/openneuro/bugs-done/*) and tagged(projects/openneuro)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+</details>
+
diff --git a/doc/projects/repronim.mdwn b/doc/projects/repronim.mdwn
new file mode 100644
index 0000000000..daea30212b
--- /dev/null
+++ b/doc/projects/repronim.mdwn
@@ -0,0 +1,26 @@
+ReproNim [https://repronim.org](https://repronim.org)
+=====================================================
+
+The center for Reproducible Neuroimaging computation develops standards and tools to improve reproducibility. `git-annex` is used via [DataLad](http://datalad.org) and in the core of efforts such as [YODA](https://github.com/myyoda), [repronim/containers](https://github.com/ReproNim/containers), and heavily used by [ReproMan](https://github.com/ReproNim/reproman/).
+
+## TODOs
+
+[[!inline pages="todo/* and !todo/done and !link(todo/done) and tagged(projects/repronim)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+<details>
+<summary>Done</summary>
+
+[[!inline pages="todo/* and !todo/done and link(todo/done) and tagged(projects/repronim)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+</details>
+
+## BUGs
+
+[[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and tagged(projects/repronim)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+<details>
+<summary>Done</summary>
+
+[[!inline pages="((bugs/* and !bugs/done and link(bugs/done)) or projects/repronim/bugs-done/*) and tagged(projects/repronim)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] 
+
+</details>
diff --git a/doc/projects/repronim/bugs-done/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d.mdwn b/doc/projects/repronim/bugs-done/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d.mdwn
new file mode 100644
index 0000000000..280d8cd90e
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d.mdwn
@@ -0,0 +1,43 @@
+[[!format sh """
+
+neurodebian@smaug ..6.20181011+git109-gff9ba1f4d-1~ndall+1 % grep  -B10 FAIL git-annex_6.20181011+git109-gff9ba1f4d-1~ndall+1_amd64.build
+   a03a722..0dd2b80  git-annex  -> r2/git-annex
+To ../../.t/tmprepo331
+ * [new branch]      git-annex -> synced/git-annex
+To ../../.t/tmprepo330
+   a03a722..22937c6  git-annex -> synced/git-annex
+OK (2.15s)
+    adjusted branch merge regression:                     On branch master
+nothing to commit, working tree clean
+On branch master
+nothing to commit, working tree clean
+FAIL (0.50s)
+      Test.hs:1463:
+      adjust failed
+    adjusted branch subtree regression:                   On branch master
+nothing to commit, working tree clean
+FAIL (0.31s)
+--
+   059871b..4f97b0c  annex/direct/master -> r2/annex/direct/master
+conflictor.variant-a507
+conflictor.variant-75dc
+conflictor.variant-a507
+conflictor.variant-75dc
+OK (1.37s)
+    conflict resolution (adjusted branch):                On branch master
+nothing to commit, working tree clean
+On branch master
+nothing to commit, working tree clean
+FAIL (0.70s)
+
+"""]]
+
+
+Full log http://www.onerussian.com/tmp/git-annex_6.20181011+git109-gff9ba1f4d-1~ndall+1_amd64.build
+
+(not sure if relevant - this is I think the first build without my custom no LOCPATH patch)
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d/comment_1_244e138f7621c901dd7763159db84677._comment b/doc/projects/repronim/bugs-done/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d/comment_1_244e138f7621c901dd7763159db84677._comment
new file mode 100644
index 0000000000..39686228a4
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d/comment_1_244e138f7621c901dd7763159db84677._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-10-22T19:22:30Z"
+ content="""
+See also (same?) failure when trying to build the conda-forge package:
+https://circleci.com/gh/conda-forge/git-annex-feedstock/116?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
+"""]]
diff --git a/doc/projects/repronim/bugs-done/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d/comment_2_cbdfb3dea5c125b52d53811b96b3e01e._comment b/doc/projects/repronim/bugs-done/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d/comment_2_cbdfb3dea5c125b52d53811b96b3e01e._comment
new file mode 100644
index 0000000000..d5e15f413b
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/3_tests_fail_while_trying_to_build_fresh_git_annex_6.20181011+git109-gff9ba1f4d/comment_2_cbdfb3dea5c125b52d53811b96b3e01e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2018-10-24T16:01:53Z"
+ content="""
+Maybe, post a new git-annex version on hackage, with the test failure fixed?  I could then update the conda-forge recipe.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build.mdwn b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build.mdwn
new file mode 100644
index 0000000000..2191541bdd
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build.mdwn
@@ -0,0 +1,29 @@
+### Please describe the problem.
+
+Trying to build fresh snapshot for neurodebian but 3 tests report failing
+Full buildlogs are at [http://neuro.debian.net/_files/_buildlogs/git-annex/7.20181211+git29-gab4a1bed9](http://neuro.debian.net/_files/_buildlogs/git-annex/7.20181211+git29-gab4a1bed9)
+
+
+[[!format sh """
+neurodebian@smaug ../7.20181211+git29-gab4a1bed9-1~ndall+1 % grep -B3 '^FAIL' git-annex_7.20181211+git29-gab4a1bed9-1\~ndall+1_amd64.build 
+    bup remote:                                           OK (0.11s)
+    crypto:                                               gpg: can't connect to the agent: IPC connect call failed
+gpg: error getting the KEK: No agent running
+FAIL
+--
+    bup remote:                                           OK (0.19s)
+    crypto:                                               gpg: can't connect to the agent: IPC connect call failed
+gpg: error getting the KEK: No agent running
+FAIL
+--
+nothing to commit, working tree clean
+gpg: can't connect to the agent: IPC connect call failed
+gpg: error getting the KEK: No agent running
+FAIL
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[done]] I think.. --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_1_ddd60096d409a820358d5a57a3a449c9._comment b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_1_ddd60096d409a820358d5a57a3a449c9._comment
new file mode 100644
index 0000000000..0a84888481
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_1_ddd60096d409a820358d5a57a3a449c9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-01-01T16:10:48Z"
+ content="""
+I'll bet [[!commit 14971414dc263fcb8124b4cf6b14b9b7a19189af]]
+somehow led to this
+since the test suite now runs gpg with its home 
+directory set to be inside the test repo and not in the system's temporary
+directory.
+
+But I tested that commit on filesystems down to FAT, so it seems strange it
+would fail on whatever filesystem you are testing on.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_2_b496a4967b6bcc0a4e1cc55e06ba90c8._comment b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_2_b496a4967b6bcc0a4e1cc55e06ba90c8._comment
new file mode 100644
index 0000000000..7becb95ebf
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_2_b496a4967b6bcc0a4e1cc55e06ba90c8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="the build details"
+ date="2019-01-02T01:14:39Z"
+ content="""
+cowbuilder is used, underlying file system (dedicated to debian pkgs building) is ext4.
+but is it a filesystem effect somehow or just a \"partially\" isolated environment aspect (such as those pbuilder/cowbuilder chroots)?  The message `gpg: can't connect to the agent: IPC connect call failed` suggests that may be tests pass for you locally as connecting to your gpg agent?
+"""]]
diff --git a/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_3_bdadf679a2f82c2a1cae747d437add85._comment b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_3_bdadf679a2f82c2a1cae747d437add85._comment
new file mode 100644
index 0000000000..c070c31b1a
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_3_bdadf679a2f82c2a1cae747d437add85._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-01-18T17:51:09Z"
+ content="""
+Having what seems a related problem on my i386 autobuilder:
+
+	gpg: keyblock resource '/home/builder/gitbuilder/build/.t/tmprepo89/.git/annex/othertmp/gpgtest/2/pubring.kbx': No such file or directory
+	gpg: failed to create temporary file '/home/builder/gitbuilder/build/.t/tmprepo89/.git/annex/othertmp/gpgtest/2/.#lk0x57fed950.orca.13095': No such file or directory
+	gpg: can't connect to the agent: No such file or directory
+	gpg: problem with the agent: No agent running
+	gpg: can't create `/home/builder/gitbuilder/build/.t/tmprepo89/.git/annex/othertmp/gpgtest/2/random_seed': No such file or directory
+	user error (gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--batch","--passphrase-fd","28","--symmetric","--force-mdc","--no-textmode"] exited 2)
+	copy: 1 failed
+	FAIL (2.31s)
+	Test.hs:1645:
+	copy --to encrypted remote failed
+
+Probably gpg error output has failed, but this is also failing to connect
+to the agent. And it seems a file/directory gpg expects to find is not present
+when it's running in the test harness.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_4_90bc2857c83afae250834135a5884898._comment b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_4_90bc2857c83afae250834135a5884898._comment
new file mode 100644
index 0000000000..8730fa3f86
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_4_90bc2857c83afae250834135a5884898._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-01-21T18:12:13Z"
+ content="""
+I've fixed the problem I described above. But I don't think it was the
+same problem; the neurodebian build log is not complaining about missing
+files/directories.
+
+gpg in the test suite is using a separate home directory, so it starts a
+separate gpg-agent process for that. If the test suite is run on a
+filesystem where gpg-agent can't work, due say to unix sockets not being
+supported, that might be why it fails.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_5_d29518fef1b3b0b8937e078f9303d41c._comment b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_5_d29518fef1b3b0b8937e078f9303d41c._comment
new file mode 100644
index 0000000000..02edcb458a
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_5_d29518fef1b3b0b8937e078f9303d41c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-01-21T19:18:51Z"
+ content="""
+Anyway, see if [[!commit f5f059e288b5e618e5c7c86d1db4bfd23d8b39ad]] somehow
+fixed it..
+"""]]
diff --git a/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_6_24eca56dc972ecff0b553e93b7c649c4._comment b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_6_24eca56dc972ecff0b553e93b7c649c4._comment
new file mode 100644
index 0000000000..bd72afa573
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_6_24eca56dc972ecff0b553e93b7c649c4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2019-01-21T19:22:52Z"
+ content="""
+tried to build 7.20181211+git284-g6f0d98f2a - it seems that the failing one is different one now?
+
+    prop_parse_show_Config:                               FAIL
+      *** Failed! Falsifiable (after 3 tests and 1 shrink):
+      fromList [(\"\791992\",\"\")]
+      Use --quickcheck-replay=133129 to reproduce.
+    prop_upFrom_basics:                                   OK (0.03s)
+    ...
+    1 out of 291 tests failed (254.87s)
+
+"""]]
diff --git a/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_7_3adce9695e4e3786f0c68b092d8f6400._comment b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_7_3adce9695e4e3786f0c68b092d8f6400._comment
new file mode 100644
index 0000000000..767d6ba324
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/comment_7_3adce9695e4e3786f0c68b092d8f6400._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2019-01-21T20:30:52Z"
+ content="""
+If that unrelated test case is the only failure, then this problem is
+fixed.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/Please_include_version_of_used_to_build_ghc_within___34__git_annex_version__34__.mdwn b/doc/projects/repronim/bugs-done/Please_include_version_of_used_to_build_ghc_within___34__git_annex_version__34__.mdwn
new file mode 100644
index 0000000000..05813affe4
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/Please_include_version_of_used_to_build_ghc_within___34__git_annex_version__34__.mdwn
@@ -0,0 +1,6 @@
+Since git-annex version is not always sufficient to pin point the source of regression (e.g. see [the get -J issue](http://git-annex.branchable.com/bugs/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/)), it would be really nice if the version of ghc (and thus all its libraries if I get it right) was included in the output of `git annex version`
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> Closing as I was blind -- there is `dependency versions` reported [[done]] --[[yarikoptic]]
diff --git a/doc/projects/repronim/bugs-done/Regression_in___96__find_--json__96___output.mdwn b/doc/projects/repronim/bugs-done/Regression_in___96__find_--json__96___output.mdwn
new file mode 100644
index 0000000000..9784cb604e
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/Regression_in___96__find_--json__96___output.mdwn
@@ -0,0 +1,35 @@
+As of 436f10771 (make CommandStart return a StartMessage, 2019-06-06),
+`find --json` no longer outputs json.
+
+For example, with
+
+[[!format sh """
+cd $(mktemp -dt gx-find-json-XXXXXXX)
+git init && git annex init
+echo one >one && git annex add one && git commit -mone
+git annex find --json -- one
+"""]]
+
+the last command outputs
+
+```
+one
+```
+
+rather than
+
+```
+{"bytesize":"4","mtime":"unknown","keyname":"2c8b08da5ce60398e1f19af0e5dccc744df274b826abe585eaba68c525434806","backend":"SHA256E","key":"SHA256E-s4--2c8b08da5ce60398e1f19af0e5dccc744df274b826abe585eaba68c525434806","humansize":"4 B","hashdirmixed":"0J/J1/","file":"one","hashdirlower":"171/8dc/"}
+```
+
+436f10771 appears to touch a lot of things, so perhaps other commands
+show similar issues and `find` is just the first I noticed.
+
+### On what operating system?
+
+GNU/Linux, building git-annex with Guix
+
+[[!meta author=kyle]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/Regression_in___96__find_--json__96___output/comment_1_034f772098dfb9d3622c6f84976e69a2._comment b/doc/projects/repronim/bugs-done/Regression_in___96__find_--json__96___output/comment_1_034f772098dfb9d3622c6f84976e69a2._comment
new file mode 100644
index 0000000000..5ecb73e01f
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/Regression_in___96__find_--json__96___output/comment_1_034f772098dfb9d3622c6f84976e69a2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 1"
+ date="2019-07-08T16:37:50Z"
+ content="""
+Thanks for the quick fix.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/Unable_to_get__47__addurl_to_http_link__58___download_failed__58___InvalidHeader___34__preload__34__.mdwn b/doc/projects/repronim/bugs-done/Unable_to_get__47__addurl_to_http_link__58___download_failed__58___InvalidHeader___34__preload__34__.mdwn
new file mode 100644
index 0000000000..b2caea64a4
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/Unable_to_get__47__addurl_to_http_link__58___download_failed__58___InvalidHeader___34__preload__34__.mdwn
@@ -0,0 +1,80 @@
+Originally reported [here](https://github.com/CONP-PCNO/conp-dataset/pull/14)
+
+[[!format sh """
+$> wget https://datahub-khvul4ng.udes.genap.ca/ALL.chr10.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz
+--2019-04-10 09:26:54--  https://datahub-khvul4ng.udes.genap.ca/ALL.chr10.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz
+Resolving datahub-khvul4ng.udes.genap.ca (datahub-khvul4ng.udes.genap.ca)... 204.19.23.238
+Connecting to datahub-khvul4ng.udes.genap.ca (datahub-khvul4ng.udes.genap.ca)|204.19.23.238|:443... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 773788987 (738M) [application/octet-stream]
+Saving to: ‘ALL.chr10.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz’
+
+hr10.phase3_shapeit2_mvncall_integr   1%[                                                                  ]   9.44M  2.02MB/s    eta 6m 16s ^C
+# so wget works - I interrupted
+
+$> git annex addurl -d https://datahub-khvul4ng.udes.genap.ca/ALL.chr10.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz 
+[2019-04-10 09:27:04.412248] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2019-04-10 09:27:04.416582] process done ExitSuccess
+[2019-04-10 09:27:04.416692] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2019-04-10 09:27:04.420688] process done ExitSuccess
+[2019-04-10 09:27:04.420852] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..3db4e3c3bf941c1cff0936d4441366bd10c9b2f1","--pretty=%H","-n1"]
+[2019-04-10 09:27:04.424774] process done ExitSuccess
+[2019-04-10 09:27:04.425311] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2019-04-10 09:27:04.42596] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+addurl https://datahub-khvul4ng.udes.genap.ca/ALL.chr10.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz [2019-04-10 09:27:04.449013] Request {
+  host                 = "datahub-khvul4ng.udes.genap.ca"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding",""),("User-Agent","git-annex/7.20190322+git23-g9662cb332-1~ndallstack+1")]
+  path                 = "/ALL.chr10.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz"
+  queryString          = ""
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+}
+
+
+[2019-04-10 09:27:04.711525] Request {
+  host                 = "datahub-khvul4ng.udes.genap.ca"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding","identity"),("User-Agent","git-annex/7.20190322+git23-g9662cb332-1~ndallstack+1")]
+  path                 = "/ALL.chr10.phase3_shapeit2_mvncall_integrated_v5a.20130502.genotypes.vcf.gz"
+  queryString          = ""
+  method               = "GET"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+}
+
+download failed: InvalidHeader "preload"
+failed
+[2019-04-10 09:27:04.956626] process done ExitSuccess
+[2019-04-10 09:27:04.957293] process done ExitSuccess
+git-annex: addurl: 1 failed
+
+$> git annex version
+git-annex version: 7.20190322+git23-g9662cb332-1~ndallstack+1
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 5
+
+"""]]
+
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> closing as there are no code changes to git-annex that can fix this,
+> it has to be fixed in either http-client or the web server. [[done]]
+> --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/Unable_to_get__47__addurl_to_http_link__58___download_failed__58___InvalidHeader___34__preload__34__/comment_1_247f3c1dfea3cdb0b398c015f4c4d44b._comment b/doc/projects/repronim/bugs-done/Unable_to_get__47__addurl_to_http_link__58___download_failed__58___InvalidHeader___34__preload__34__/comment_1_247f3c1dfea3cdb0b398c015f4c4d44b._comment
new file mode 100644
index 0000000000..9f7a345b9a
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/Unable_to_get__47__addurl_to_http_link__58___download_failed__58___InvalidHeader___34__preload__34__/comment_1_247f3c1dfea3cdb0b398c015f4c4d44b._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-04-10T13:58:03Z"
+ content="""
+curl -v shows the problem response
+
+	< Server: openresty/1.7.10.1
+	< Date: Wed, 10 Apr 2019 13:57:10 GMT
+	< Content-Type: application/octet-stream
+	< Content-Length: 773788987
+	< Connection: keep-alive
+	< Last-Modified: Mon, 11 Mar 2019 16:35:02 GMT
+	< ETag: "5c868e36-2e1f153b"
+	< Accept-Ranges: bytes
+	< Strict-Transport-Security: max-age=15768000; includeSubdomains;
+	< preload
+	< X-Frame-Options: DENY
+	< X-Content-Type-Options: nosniff
+
+It looks like the server is sending "preload" on its own line rather
+than being part of the Strict-Transport-Security header.
+
+Just in case, I found another url that uses HSTS preload, and git-annex
+can download that:
+
+	joey@darkstar:~>curl -v -o foo https://www.torproject.org/ 2>&1 | grep preload
+	< Strict-Transport-Security: max-age=15768000; preload
+	joey@darkstar:~/tmp/c>git annex addurl https://www.torproject.org/
+	addurl https://www.torproject.org/ 
+	(to www.torproject.org_) ok
+
+The web server is probably violating standard HTTP to some extent with that
+response. Of course, it's possible to parse the response less strictly and
+not fail on the malformed header. Still, fixing the web server is probably the
+fastest way to fix the immediate problem (as well as make HSTS preloading
+actually be used).
+
+Issue filed on http-client, <https://github.com/snoyberg/http-client/issues/398>
+with a prospective patch.
+
+I don't see any changes to git-annex that can help with the problem, so
+I'll close this bug report.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/add_--json_should_provide_a___34__note__34___with_an_error_message_in_case_of_an_error.mdwn b/doc/projects/repronim/bugs-done/add_--json_should_provide_a___34__note__34___with_an_error_message_in_case_of_an_error.mdwn
new file mode 100644
index 0000000000..8a42a6701d
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/add_--json_should_provide_a___34__note__34___with_an_error_message_in_case_of_an_error.mdwn
@@ -0,0 +1,19 @@
+### Please describe the problem.
+
+[Originally blamed datalad](https://github.com/datalad/datalad/issues/3685#issuecomment-533075845) but apparently `git annex add --json` does not include error message in the json output.  In our case it was due to permission issues.
+
+
+[[!format sh """
+$ git annex add more --json
+  more: setFileMode: permission denied (Operation not permitted)
+{"command":"add","success":false,"file":"more"}
+git-annex: add: 1 failed
+"""]]
+
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+[[!meta project=repronim]]
+
+> If you use --json-error-messages it does work, at least in this
+> permissions error case. So nothing more needs to be [[done]]. --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/add_--json_should_provide_a___34__note__34___with_an_error_message_in_case_of_an_error/comment_1_636a375fbd8cf8573b3806d7a815b59f._comment b/doc/projects/repronim/bugs-done/add_--json_should_provide_a___34__note__34___with_an_error_message_in_case_of_an_error/comment_1_636a375fbd8cf8573b3806d7a815b59f._comment
new file mode 100644
index 0000000000..7168122567
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/add_--json_should_provide_a___34__note__34___with_an_error_message_in_case_of_an_error/comment_1_636a375fbd8cf8573b3806d7a815b59f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="about --json-error-messages"
+ date="2019-09-24T19:19:20Z"
+ content="""
+From \"any program parsing stderr for json would somehow have to deal with this non-json that could be mixed up with it, which seems very hard\" at 
+[another bug page](https://git-annex.branchable.com/bugs/git-annex-copy_--json-error-messages_does_not_write_error_messages_to_stderr_) , it sounds like parsing the output of `--json-error-messages` might not be reliable?
+"""]]
diff --git a/doc/projects/repronim/bugs-done/add_--json_should_provide_a___34__note__34___with_an_error_message_in_case_of_an_error/comment_2_50d096934badd3e59756939b5c418bcb._comment b/doc/projects/repronim/bugs-done/add_--json_should_provide_a___34__note__34___with_an_error_message_in_case_of_an_error/comment_2_50d096934badd3e59756939b5c418bcb._comment
new file mode 100644
index 0000000000..62a8a81ac0
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/add_--json_should_provide_a___34__note__34___with_an_error_message_in_case_of_an_error/comment_2_50d096934badd3e59756939b5c418bcb._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-24T21:01:48Z"
+ content="""
+--json-error-messages does not go to stderr, so does not have that problem.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/addurl_fails_with_non-youtube_url_with___34__This_url_is_supported_by_youtube-dl__44___but_youtube-dl_could_potentially_access_any_address__34__.mdwn b/doc/projects/repronim/bugs-done/addurl_fails_with_non-youtube_url_with___34__This_url_is_supported_by_youtube-dl__44___but_youtube-dl_could_potentially_access_any_address__34__.mdwn
new file mode 100644
index 0000000000..9f14fd3f2c
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/addurl_fails_with_non-youtube_url_with___34__This_url_is_supported_by_youtube-dl__44___but_youtube-dl_could_potentially_access_any_address__34__.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+Trying to add non youtube URL causes an error demanding to set `annex.security.allowed-http-addresses`, which is IMHO not warranted:
+
+[[!format sh """
+$> mkdir /tmp/testrepo; cd /tmp/testrepo; git init; git annex init; git annex addurl --file=index.html https://www.cs.toronto.edu/\~kriz/index.html
+Initialized empty Git repository in /tmp/testrepo/.git/
+init  ok
+(recording state in git...)
+addurl https://www.cs.toronto.edu/~kriz/index.html 
+
+  This url is supported by youtube-dl, but youtube-dl could potentially access any address, and the configuration of annex.security.allowed-http-addresses does not allow that. Not using youtube-dl.
+failed
+git-annex: addurl: 1 failed
+
+$> git annex version
+git-annex version: 7.20190219+git191-g2d6a364d4-1~ndall+1
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 5
+"""]]
+
+
+The same happens if I remove `youtube-dl` from the system entirely!
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> due to using --file which bypasses the usual check that youtube-dl
+> can extract media. [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description.mdwn b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description.mdwn
new file mode 100644
index 0000000000..dba33fd047
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description.mdwn
@@ -0,0 +1,100 @@
+### Please describe the problem.
+
+As of a14f6ce75 (fix repo description setting bugs, 2019-05-23), `git annex init` without a description sets the description to a blank string.  AFAICT from the description of that change and from the corresponding [bug report][0], that isn't an intentional change.
+
+[0]: https://git-annex.branchable.com/bugs/git-annex-init_with_no_args_overwrites_existing_repo_description/
+### What steps will reproduce the problem?
+
+```
+cd $(mktemp -dt gx-XXXXXXX)
+git init
+git annex init
+git annex info --json | jq
+```
+
+On the parent of a14f6ce75, this shows
+
+```
+Initialized empty Git repository in /tmp/gx-BLmU7TJ/.git/
+init  ok
+(recording state in git...)
+{
+  "local annex size": "0 bytes",
+  "size of annexed files in working tree": "0 bytes",
+  "command": "info",
+  "untrusted repositories": [],
+  "success": true,
+  "semitrusted repositories": [
+    {
+      "here": false,
+      "uuid": "00000000-0000-0000-0000-000000000001",
+      "description": "web"
+    },
+    {
+      "here": false,
+      "uuid": "00000000-0000-0000-0000-000000000002",
+      "description": "bittorrent"
+    },
+    {
+      "here": true,
+      "uuid": "d1ef2ae8-9604-4c33-8c3c-181f81c4348f",
+      "description": "kyle@hylob:/tmp/gx-BLmU7TJ"
+    }
+  ],
+  "bloom filter size": "32 mebibytes (0% full)",
+  "repository mode": "indirect",
+  "backend usage": {},
+  "transfers in progress": [],
+  "local annex keys": 0,
+  "available local disk space": "301.33 gigabytes (+1 megabyte reserved)",
+  "annexed files in working tree": 0,
+  "file": null,
+  "trusted repositories": []
+}
+```
+
+On a14f6ce75, this shows
+
+```
+Initialized empty Git repository in /tmp/gx-pK345zF/.git/
+init  ok
+{
+  "local annex size": "0 bytes",
+  "size of annexed files in working tree": "0 bytes",
+  "command": "info",
+  "untrusted repositories": [],
+  "success": true,
+  "semitrusted repositories": [
+    {
+      "here": false,
+      "uuid": "00000000-0000-0000-0000-000000000001",
+      "description": "web"
+    },
+    {
+      "here": false,
+      "uuid": "00000000-0000-0000-0000-000000000002",
+      "description": "bittorrent"
+    },
+    {
+      "here": true,
+      "uuid": "00b8da69-41a5-4de8-9a6a-9ed991289f81",
+      "description": ""
+    }
+  ],
+  "bloom filter size": "32 mebibytes (0% full)",
+  "repository mode": "indirect",
+  "backend usage": {},
+  "transfers in progress": [],
+  "local annex keys": 0,
+  "available local disk space": "301.22 gigabytes (+1 megabyte reserved)",
+  "annexed files in working tree": 0,
+  "file": null,
+  "trusted repositories": []
+}
+```
+
+Note that the description for here is a blank string.
+
+> [[fixed|done]] --[[Joey]]
+[[!meta author=kyle]]
+[[!tag projects/repronim]]
diff --git a/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_1_eb415152db43c02e4d474dade4a1faca._comment b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_1_eb415152db43c02e4d474dade4a1faca._comment
new file mode 100644
index 0000000000..f99e0ee5bd
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_1_eb415152db43c02e4d474dade4a1faca._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="uuid.log is also not created"
+ date="2019-06-05T15:18:30Z"
+ content="""
+As of that same commit (a14f6ce75), running `git annex init` in a fresh repository no longer creates uuid.log:
+
+```
+% cd $(mktemp -dt gx-XXXXXXX)            
+% git init
+Initialized empty Git repository in /tmp/gx-kpnGSjg/.git/
+% git annex init
+init  ok
+% git ls-tree -r git-annex  ;# no output
+```
+
+"""]]
diff --git a/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_2_c51d386f294529d6ebe7058438577ffe._comment b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_2_c51d386f294529d6ebe7058438577ffe._comment
new file mode 100644
index 0000000000..6459b7e103
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_2_c51d386f294529d6ebe7058438577ffe._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="Issue with description cache?"
+ date="2019-06-17T21:11:14Z"
+ content="""
+I took another look at this thinking that maybe I could spot something obvious in the condition added in a14f6ce75
+
+```
+	{- Avoid overwriting existing description with a default
+	 - description. -}
+	whenM (pure (isJust mdescription) <||> not . M.member u <$> uuidDescMap) $
+		describeUUID u =<< genDescription mdescription
+```
+
+but that looks fine.  Grepping around for uuidDescMap, I spotted a couple of places where the cache needed to be invalidated.  Blindly applying that same approach I did
+
+```
+diff --git a/Annex/Init.hs b/Annex/Init.hs
+index cb7f8905e..6303103df 100644
+--- a/Annex/Init.hs
++++ b/Annex/Init.hs
+@@ -76,6 +76,7 @@ genDescription Nothing = do
+ 
+ initialize :: Maybe String -> Maybe RepoVersion -> Annex ()
+ initialize mdescription mversion = checkCanInitialize $ do
++	uuidDescMapLoad
+ 	{- Has to come before any commits are made as the shared
+ 	 - clone heuristic expects no local objects. -}
+ 	sharedclone <- checkSharedClone
+```
+
+That fixes the problem on my end (i.e., `git annex init` sets the description to the default user@host:dir description) while still addressing the original issue fixed by a14f6ce75.
+
+So it seems like it has something to do with the uuidDescMap cache, but I haven't been able to figure out what in particular.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_3_6edae77c6ee7e4c4f94f9c0daff375ad._comment b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_3_6edae77c6ee7e4c4f94f9c0daff375ad._comment
new file mode 100644
index 0000000000..22bdd05c62
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_3_6edae77c6ee7e4c4f94f9c0daff375ad._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-06-21T00:12:51Z"
+ content="""
+Thanks Kyle, that does point at the problem. In uuidDescMapLoad
+it implicitly adds the UUID of the current repo, with an empty 
+description if none is set. So, the added check of uuidDescMap
+always finds the UUID in it already. Your uuidDescMapLoad hack
+avoids this by loading the map before the current repo has a UUID.
+
+Fixed more cleanly..
+"""]]
diff --git a/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_4_d92a7f2bc72b27c74cd86811c9bbf098._comment b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_4_d92a7f2bc72b27c74cd86811c9bbf098._comment
new file mode 100644
index 0000000000..61f1581050
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_4_d92a7f2bc72b27c74cd86811c9bbf098._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="thanks"
+ date="2019-06-21T02:05:24Z"
+ content="""
+Thank you for the explanation and fix!
+"""]]
diff --git a/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_5_0dd1d4e6cd16da2865c3153b61b9e282._comment b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_5_0dd1d4e6cd16da2865c3153b61b9e282._comment
new file mode 100644
index 0000000000..15abcae923
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_5_0dd1d4e6cd16da2865c3153b61b9e282._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="bug fix release"
+ date="2019-06-22T16:14:58Z"
+ content="""
+@joeyh Thanks for fixing this.  Would it be possible to make a new release on Hackage?  I'd like to make a new [[install/conda]] release that incorporates the improvements in version `7.20190615`, but don't want to make a release that fails DataLad tests the default one.  Thanks!
+"""]]
diff --git a/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_6_539039e237d9b0db0c97f64d877de7f7._comment b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_6_539039e237d9b0db0c97f64d877de7f7._comment
new file mode 100644
index 0000000000..61c2a21edb
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_init_no_longer_generates_default_description/comment_6_539039e237d9b0db0c97f64d877de7f7._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2019-06-25T17:14:03Z"
+ content="""
+Release soon.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container.mdwn b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container.mdwn
new file mode 100644
index 0000000000..e6b301ccb8
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container.mdwn
@@ -0,0 +1,88 @@
+### Please describe the problem.
+
+Initially reported in [heudiconv](https://github.com/nipy/heudiconv/pull/259).  I am not yet sure what is going on, but git-annex (tried "bleeding edge" from a few days back too) seems to believe being unable to get .git/config file, while I do not see any request being logged on the server side, and `curl` gets it just ok.
+
+To reproduce you can use ```docker run -it --rm --entrypoint bash nipy/heudiconv:latest -c "cd /tmp/ && rm -rf /tmp/MEEPI3; git clone http://datasets-tests.datalad.org/dicoms/velasco/MEEPI/.git MEEPI3 && cd MEEPI3 && git annex info --debug; echo -e '\n\nCURL:'; curl http://datasets-tests.datalad.org/dicoms/velasco/MEEPI/.git/config"```
+
+
+<details>
+<summary>A sample docker run</summary>
+
+[[!format sh """
+docker run -it --rm --entrypoint bash nipy/heudiconv:latest -c "cd /tmp/ && rm -rf /tmp/MEEPI3; git clone http://datasets-tests.datalad.org/dicoms/velasco/MEEPI/.git MEEPI3 && cd MEEPI3 && git annex info --debug; echo -e '\n\nCURL:'; curl http://datasets-tests.datalad.org/dicoms/velasco/MEEPI/.git/config"
+...
+[2018-11-12 17:58:02.246908731] Request {
+  host                 = "datasets-tests.datalad.org"
+  port                 = 80
+  secure               = False
+  requestHeaders       = [("Range","bytes=0-"),("Accept-Encoding","identity"),("User-Agent","git-annex/6.20181011+git124-g94aa0e2f6-1~ndall+1")]
+  path                 = "/dicoms/velasco/MEEPI/.git/config"
+  queryString          = ""
+  method               = "GET"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+}
+
+
+  Remote origin not usable by git-annex; setting annex-ignore
+[2018-11-12 17:58:02.247631556] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","remote.origin.annex-ignore","true"]
+[2018-11-12 17:58:02.249993683] process done ExitSuccess
+[2018-11-12 17:58:02.250056119] read: git ["config","--null","--list"]
+[2018-11-12 17:58:02.252212701] process done ExitSuccess
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 6
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	41bc6812-269a-47af-a7c9-ba2d30e55642 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/dicoms/velasco/MEEPI
+ 	757a81e7-f905-4796-9941-a2772ec190b6 -- yoh@falkor:/srv/datasets.datalad.org/www/dicoms/velasco/MEEPI
+ 	c04eb54b-4b4e-5755-8436-866b043170fa -- datalad-archives
+ 	ffa6417c-5511-4b43-a67a-036dd57ab974 -- root@d9efe0626d93:/tmp/MEEPI3 [here]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 12.08 gigabytes (+1 megabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: [2018-11-12 17:58:02.253291443] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","--others","-z","--","."]
+[2018-11-12 17:58:02.255650007] process done ExitSuccess
+3
+size of annexed files in working tree: 5.87 megabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+	MD5E: 3
+[2018-11-12 17:58:02.256351183] process done ExitSuccess
+[2018-11-12 17:58:02.256558475] process done ExitSuccess
+[2018-11-12 17:58:02.256945107] process done ExitSuccess
+
+
+CURL:
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+	sharedrepository = 2
+[receive]
+	denyNonFastforwards = true
+	denyCurrentBranch = updateInstead
+[annex]
+	uuid = 757a81e7-f905-4796-9941-a2772ec190b6
+	version = 5
+
+
+$> docker run -it --rm --entrypoint bash nipy/heudiconv:latest -c "git annex version | head -n1"
+git-annex version: 6.20181011+git124-g94aa0e2f6-1~ndall+1 
+"""]]
+
+</details>
+
+
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[done]]; git-annex displays a good error message and the dependency is
+> there. --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_1_130f2600057aa5b648f7798c49b4ea60._comment b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_1_130f2600057aa5b648f7798c49b4ea60._comment
new file mode 100644
index 0000000000..204c39ae06
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_1_130f2600057aa5b648f7798c49b4ea60._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-11-12T18:42:53Z"
+ content="""
+It does seem to work just fine with current git-annex outside
+docker.
+
+Given the insecurity-to-weight ratio of docker and the number of hoops
+I would have to jump through to run that docker command, 
+it may be several days until I have time, bandwidth, and power to try
+it myself.. If you want to show the debug output, that generally doesn't
+hurt.
+
+(Please include the git-annex version information in all bug reports.)
+"""]]
diff --git a/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_2_802f85441c42ac079b6ecaea39a63c81._comment b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_2_802f85441c42ac079b6ecaea39a63c81._comment
new file mode 100644
index 0000000000..e0458def71
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_2_802f85441c42ac079b6ecaea39a63c81._comment
@@ -0,0 +1,351 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-11-12T19:27:48Z"
+ content="""
+Just want to check first -- you didn't miss my fancy foldable \"A sample docker run\" in the original submission? (has annex version at the bottom), did you?
+
+and yes -- works fine outside of docker on the same box (well - my laptop).
+
+FWIW, you are welcome to try it on smaug, you are a part of `docker` group there.  For some reason docker is slowish there.
+
+Interestingly, the version of that image being different on smaug, output might be more informative (?):
+
+[[!format sh \"\"\"
+[2018-11-12 19:09:33.816486231] process done ExitSuccess
+download failed: ConnectionFailure Network.BSD.getProtocolByName: does not exist (no such protocol name: tcp)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+\"\"\"]]
+
+And here is (folded) full output of that run:
+
+<details>
+<summary>Docker run with older git annex 6.20180626+gitg12cd64369-1~ndall+1</summary>
+
+[[!format sh \"\"\"
+$> docker run -it --rm --entrypoint bash nipy/heudiconv:annex-6.20180626 -c \"cd /tmp/ && rm -rf /tmp/MEEPI3; git clone http://datasets-tests.datalad.org/dicoms/velasco/MEEPI/.git MEEPI3 && cd MEEPI3 && git annex info --debug; echo -e '\n\nCURL:'; curl http://datasets-tests.datalad.org/dicoms/velasco/MEEPI/.git/config; git annex version\"          
+Cloning into 'MEEPI3'...                                                
+remote: Counting objects: 101, done.
+remote: Compressing objects: 100% (82/82), done.
+remote: Total 101 (delta 35), reused 0 (delta 0)
+Receiving objects: 100% (101/101), 11.70 KiB | 0 bytes/s, done.
+Resolving deltas: 100% (35/35), done.
+[2018-11-12 19:09:33.497644702] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2018-11-12 19:09:33.502984282] process done ExitSuccess
+[2018-11-12 19:09:33.503282134] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-11-12 19:09:33.508604943] process done ExitFailure 1
+[2018-11-12 19:09:33.508770986] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--verify\",\"-q\",\"origin/git-annex\"]
+[2018-11-12 19:09:33.512907558] process done ExitFailure 1
+[2018-11-12 19:09:33.513545552] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2018-11-12 19:09:33.678146279] process done ExitSuccess
+[2018-11-12 19:09:33.678410423] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\",\"--no-gpg-sign\"]
+
+*** Please tell me who you are.
+
+Run
+
+  git config --global user.email \"you@example.com\"
+  git config --global user.name \"Your Name\"
+
+to set your account's default identity.
+Omit --global to set the identity only in this repository.
+
+fatal: unable to auto-detect email address (got 'root@5d3e0680b6fc.(none)')
+[2018-11-12 19:09:33.684364456] process done ExitFailure 128
+[2018-11-12 19:09:33.684636234] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"user.name\",\"root\"]
+[2018-11-12 19:09:33.68955458] process done ExitSuccess
+[2018-11-12 19:09:33.689684113] read: git [\"config\",\"--null\",\"--list\"]
+[2018-11-12 19:09:33.693793841] process done ExitSuccess
+[2018-11-12 19:09:33.693980718] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"user.email\",\"root\"]
+[2018-11-12 19:09:33.697545036] process done ExitSuccess
+[2018-11-12 19:09:33.697671055] read: git [\"config\",\"--null\",\"--list\"]
+[2018-11-12 19:09:33.701348909] process done ExitSuccess
+[2018-11-12 19:09:33.701520785] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-11-12 19:09:33.704126701] process done ExitFailure 1
+[2018-11-12 19:09:33.704281927] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--verify\",\"-q\",\"origin/git-annex\"]
+[2018-11-12 19:09:33.708300009] process done ExitFailure 1
+[2018-11-12 19:09:33.708510969] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2018-11-12 19:09:33.712223058] process done ExitSuccess
+[2018-11-12 19:09:33.712455349] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\",\"--no-gpg-sign\"]
+[2018-11-12 19:09:33.717700724] process done ExitSuccess
+[2018-11-12 19:09:33.717878364] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"b6d1fa4a9fd6e1e2b92cc4472374ff788f4ffe82\"]
+[2018-11-12 19:09:33.72191105] process done ExitSuccess
+[2018-11-12 19:09:33.72266107] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"annex.uuid\",\"f7e33e3d-b3aa-473a-9fa3-213ef312c646\"]
+[2018-11-12 19:09:33.726190775] process done ExitSuccess
+[2018-11-12 19:09:33.726346741] read: git [\"config\",\"--null\",\"--list\"]
+[2018-11-12 19:09:33.729706319] process done ExitSuccess
+[2018-11-12 19:09:33.73202387] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2018-11-12 19:09:33.73679675] process done ExitSuccess
+[2018-11-12 19:09:33.73698363] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-11-12 19:09:33.74067435] process done ExitSuccess
+[2018-11-12 19:09:33.741001325] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..b6d1fa4a9fd6e1e2b92cc4472374ff788f4ffe82\",\"--pretty=%H\",\"-n1\"]
+[2018-11-12 19:09:33.745857469] process done ExitSuccess
+[2018-11-12 19:09:33.74605887] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..04619d91febf86de056a8d091a5f06d464a01c04\",\"--pretty=%H\",\"-n1\"]
+[2018-11-12 19:09:33.751124219] process done ExitSuccess
+[2018-11-12 19:09:33.751630501] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-11-12 19:09:33.752216628] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+(merging origin/git-annex into git-annex...)
+[2018-11-12 19:09:33.755344426] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2018-11-12 19:09:33.756221301] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+[2018-11-12 19:09:33.756880319] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"04619d91febf86de056a8d091a5f06d464a01c04\",\"--\"]
+[2018-11-12 19:09:33.7622414] process done ExitSuccess
+[2018-11-12 19:09:33.763122925] process done ExitSuccess
+[2018-11-12 19:09:33.763684956] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"04619d91febf86de056a8d091a5f06d464a01c04..refs/heads/git-annex\",\"--pretty=%H\",\"-n1\"]
+[2018-11-12 19:09:33.768141316] process done ExitSuccess
+(recording state in git...)
+[2018-11-12 19:09:33.768438348] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2018-11-12 19:09:33.77206771] process done ExitSuccess
+[2018-11-12 19:09:33.772262959] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"f21c20ffe799304525ca1aeace21935c47926873\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\",\"-p\",\"04619d91febf86de056a8d091a5f06d464a01c04\"]
+[2018-11-12 19:09:33.776274369] process done ExitSuccess
+[2018-11-12 19:09:33.77643436] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"d076e4f8669ea8f8ddce8685e85af824a9697100\"]
+[2018-11-12 19:09:33.781233336] process done ExitSuccess
+[2018-11-12 19:09:33.783050992] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"annex.version\",\"5\"]
+[2018-11-12 19:09:33.787781391] process done ExitSuccess
+[2018-11-12 19:09:33.78793579] read: git [\"config\",\"--null\",\"--list\"]
+[2018-11-12 19:09:33.790756389] process done ExitSuccess
+[2018-11-12 19:09:33.790954849] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2018-11-12 19:09:33.795171566] process done ExitSuccess
+[2018-11-12 19:09:33.795368409] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2018-11-12 19:09:33.800060961] process done ExitSuccess
+[2018-11-12 19:09:33.800259221] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2018-11-12 19:09:33.803306615] process done ExitSuccess
+[2018-11-12 19:09:33.803473861] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/master\"]
+[2018-11-12 19:09:33.807579032] process done ExitSuccess
+[2018-11-12 19:09:33.807783985] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"checkout\",\"-q\",\"-B\",\"master\"]
+[2018-11-12 19:09:33.814124796] process done ExitSuccess
+[2018-11-12 19:09:33.815125257] read: uname [\"-n\"]
+[2018-11-12 19:09:33.816486231] process done ExitSuccess
+download failed: ConnectionFailure Network.BSD.getProtocolByName: does not exist (no such protocol name: tcp)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+[2018-11-12 19:09:33.94194622] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"remote.origin.annex-ignore\",\"true\"]
+[2018-11-12 19:09:33.947114461] process done ExitSuccess
+[2018-11-12 19:09:33.9474738] read: git [\"config\",\"--null\",\"--list\"]
+[2018-11-12 19:09:33.951509986] process done ExitSuccess
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 6
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	41bc6812-269a-47af-a7c9-ba2d30e55642 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/dicoms/velasco/MEEPI
+ 	757a81e7-f905-4796-9941-a2772ec190b6 -- yoh@falkor:/srv/datasets.datalad.org/www/dicoms/velasco/MEEPI
+ 	c04eb54b-4b4e-5755-8436-866b043170fa -- datalad-archives
+ 	f7e33e3d-b3aa-473a-9fa3-213ef312c646 -- root@5d3e0680b6fc:/tmp/MEEPI3 [here]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 34.84 terabytes (+1 megabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: [2018-11-12 19:09:33.953212804] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"--others\",\"-z\",\"--\",\".\"]
+[2018-11-12 19:09:33.957668639] process done ExitSuccess
+3
+size of annexed files in working tree: 5.87 megabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+	MD5E: 3
+[2018-11-12 19:09:33.958614844] process done ExitSuccess
+[2018-11-12 19:09:33.95905526] process done ExitSuccess
+[2018-11-12 19:09:33.959474605] process done ExitSuccess
+
+
+CURL:
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+	sharedrepository = 2
+[receive]
+	denyNonFastforwards = true
+	denyCurrentBranch = updateInstead
+[annex]
+	uuid = 757a81e7-f905-4796-9941-a2772ec190b6
+	version = 5
+git-annex version: 6.20180626+gitg12cd64369-1~ndall+1
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.16 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.1 persistent-sqlite-2.6.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+local repository version: 5
+
+\"\"\"]]
+</details>
+
+Having pulled the `nipy/heudiconv:latest`, original reported behavior reproduces 
+
+<details>
+<summary>Docker run with newer git annex </summary>
+
+[[!format sh \"\"\"
+$> docker run -it --rm --entrypoint bash nipy/heudiconv:latest -c \"cd /tmp/ && rm -rf /tmp/MEEPI3; git clone http://datasets-tests.datalad.org/dicoms/velasco/MEEPI/.git MEEPI3 && cd MEEPI3 && git annex info --debug; echo -e '\n\nCURL:'; curl http://datasets-tests.datalad.org/dicoms/velasco/MEEPI/.git/config; git annex version\"  
+Cloning into 'MEEPI3'...                                      
+remote: Counting objects: 101, done.
+remote: Compressing objects: 100% (82/82), done.
+remote: Total 101 (delta 35), reused 0 (delta 0)
+Receiving objects: 100% (101/101), 11.70 KiB | 0 bytes/s, done.
+Resolving deltas: 100% (35/35), done.
+[2018-11-12 19:16:30.168203115] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2018-11-12 19:16:30.173678013] process done ExitSuccess
+[2018-11-12 19:16:30.174017869] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-11-12 19:16:30.17921506] process done ExitFailure 1
+[2018-11-12 19:16:30.179386236] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--verify\",\"-q\",\"origin/git-annex\"]
+[2018-11-12 19:16:30.183673031] process done ExitFailure 1
+[2018-11-12 19:16:30.184420434] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2018-11-12 19:16:30.189923909] process done ExitSuccess
+[2018-11-12 19:16:30.190097446] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\",\"--no-gpg-sign\"]
+
+*** Please tell me who you are.
+
+Run
+
+  git config --global user.email \"you@example.com\"
+  git config --global user.name \"Your Name\"
+
+to set your account's default identity.
+Omit --global to set the identity only in this repository.
+
+fatal: unable to auto-detect email address (got 'root@b88726a4382b.(none)')
+[2018-11-12 19:16:30.194707379] process done ExitFailure 128
+[2018-11-12 19:16:30.194989101] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"user.name\",\"root\"]
+[2018-11-12 19:16:30.199736477] process done ExitSuccess
+[2018-11-12 19:16:30.199882502] read: git [\"config\",\"--null\",\"--list\"]
+[2018-11-12 19:16:30.204311006] process done ExitSuccess
+[2018-11-12 19:16:30.204467196] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"user.email\",\"root\"]
+[2018-11-12 19:16:30.209146004] process done ExitSuccess
+[2018-11-12 19:16:30.2092902] read: git [\"config\",\"--null\",\"--list\"]
+[2018-11-12 19:16:30.21315675] process done ExitSuccess
+[2018-11-12 19:16:30.213311976] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-11-12 19:16:30.217993425] process done ExitFailure 1
+[2018-11-12 19:16:30.218146321] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--verify\",\"-q\",\"origin/git-annex\"]
+[2018-11-12 19:16:30.22226559] process done ExitFailure 1
+[2018-11-12 19:16:30.596337472] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2018-11-12 19:16:30.601348306] process done ExitSuccess
+[2018-11-12 19:16:30.601517345] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\",\"--no-gpg-sign\"]
+[2018-11-12 19:16:30.607398795] process done ExitSuccess
+[2018-11-12 19:16:30.607513593] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"44bd175787872acfd21593ef7f75224da84f728e\"]
+[2018-11-12 19:16:30.612739367] process done ExitSuccess
+[2018-11-12 19:16:30.613560258] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"annex.uuid\",\"d886638a-7427-46c1-911d-2febef7fc831\"]
+[2018-11-12 19:16:30.617982319] process done ExitSuccess
+[2018-11-12 19:16:30.618139741] read: git [\"config\",\"--null\",\"--list\"]
+[2018-11-12 19:16:30.622404815] process done ExitSuccess
+[2018-11-12 19:16:30.624792574] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2018-11-12 19:16:30.629506669] process done ExitSuccess
+[2018-11-12 19:16:30.629670469] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-11-12 19:16:30.633873559] process done ExitSuccess
+[2018-11-12 19:16:30.634159315] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..44bd175787872acfd21593ef7f75224da84f728e\",\"--pretty=%H\",\"-n1\"]
+[2018-11-12 19:16:30.638868994] process done ExitSuccess
+[2018-11-12 19:16:30.63901631] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..04619d91febf86de056a8d091a5f06d464a01c04\",\"--pretty=%H\",\"-n1\"]
+[2018-11-12 19:16:30.644133907] process done ExitSuccess
+[2018-11-12 19:16:30.644558474] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-11-12 19:16:30.645069766] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+(merging origin/git-annex into git-annex...)
+[2018-11-12 19:16:30.648787618] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2018-11-12 19:16:30.649353618] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
+[2018-11-12 19:16:30.650115411] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"diff-index\",\"--raw\",\"-z\",\"-r\",\"--no-renames\",\"-l0\",\"--cached\",\"04619d91febf86de056a8d091a5f06d464a01c04\",\"--\"]
+[2018-11-12 19:16:30.654663147] process done ExitSuccess
+[2018-11-12 19:16:30.655618594] process done ExitSuccess
+[2018-11-12 19:16:30.656176449] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"04619d91febf86de056a8d091a5f06d464a01c04..refs/heads/git-annex\",\"--pretty=%H\",\"-n1\"]
+[2018-11-12 19:16:30.661120546] process done ExitSuccess
+(recording state in git...)
+[2018-11-12 19:16:30.661335622] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
+[2018-11-12 19:16:30.666151568] process done ExitSuccess
+[2018-11-12 19:16:30.666446029] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"f21c20ffe799304525ca1aeace21935c47926873\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\",\"-p\",\"04619d91febf86de056a8d091a5f06d464a01c04\"]
+[2018-11-12 19:16:30.67115132] process done ExitSuccess
+[2018-11-12 19:16:30.671318437] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"e9b0bb4be7614f8dab19660fc8b3c00fec9c1180\"]
+[2018-11-12 19:16:30.676528891] process done ExitSuccess
+[2018-11-12 19:16:30.678481925] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"annex.version\",\"5\"]
+[2018-11-12 19:16:30.682563316] process done ExitSuccess
+[2018-11-12 19:16:30.682715955] read: git [\"config\",\"--null\",\"--list\"]
+[2018-11-12 19:16:30.686466067] process done ExitSuccess
+[2018-11-12 19:16:30.68663411] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2018-11-12 19:16:30.690971999] process done ExitSuccess
+[2018-11-12 19:16:30.691134218] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2018-11-12 19:16:30.695344845] process done ExitSuccess
+[2018-11-12 19:16:30.695518841] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2018-11-12 19:16:30.699919641] process done ExitSuccess
+[2018-11-12 19:16:30.700082394] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/master\"]
+[2018-11-12 19:16:30.704659184] process done ExitSuccess
+[2018-11-12 19:16:30.704830677] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"checkout\",\"-q\",\"-B\",\"master\"]
+[2018-11-12 19:16:30.709278877] process done ExitSuccess
+[2018-11-12 19:16:30.710297742] read: uname [\"-n\"]
+[2018-11-12 19:16:30.730187288] process done ExitSuccess
+[2018-11-12 19:16:30.964899187] Request {
+  host                 = \"datasets-tests.datalad.org\"
+  port                 = 80
+  secure               = False
+  requestHeaders       = [(\"Range\",\"bytes=0-\"),(\"Accept-Encoding\",\"identity\"),(\"User-Agent\",\"git-annex/6.20181011+git124-g94aa0e2f6-1~ndall+1\")]
+  path                 = \"/dicoms/velasco/MEEPI/.git/config\"
+  queryString          = \"\"
+  method               = \"GET\"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+}
+
+
+  Remote origin not usable by git-annex; setting annex-ignore
+[2018-11-12 19:16:30.965795741] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"remote.origin.annex-ignore\",\"true\"]
+[2018-11-12 19:16:30.9707034] process done ExitSuccess
+[2018-11-12 19:16:30.970879863] read: git [\"config\",\"--null\",\"--list\"]
+[2018-11-12 19:16:30.975621212] process done ExitSuccess
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 6
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	41bc6812-269a-47af-a7c9-ba2d30e55642 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/dicoms/velasco/MEEPI
+ 	757a81e7-f905-4796-9941-a2772ec190b6 -- yoh@falkor:/srv/datasets.datalad.org/www/dicoms/velasco/MEEPI
+ 	c04eb54b-4b4e-5755-8436-866b043170fa -- datalad-archives
+ 	d886638a-7427-46c1-911d-2febef7fc831 -- root@b88726a4382b:/tmp/MEEPI3 [here]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 34.83 terabytes (+1 megabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: [2018-11-12 19:16:30.978614061] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"--others\",\"-z\",\"--\",\".\"]
+[2018-11-12 19:16:30.982161106] process done ExitSuccess
+3
+size of annexed files in working tree: 5.87 megabytes
+bloom filter size: 32 mebibytes (0% full)
+backend usage: 
+	MD5E: 3
+[2018-11-12 19:16:30.983219045] process done ExitSuccess
+[2018-11-12 19:16:30.984207325] process done ExitSuccess
+[2018-11-12 19:16:30.984715431] process done ExitSuccess
+
+
+CURL:
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+	sharedrepository = 2
+[receive]
+	denyNonFastforwards = true
+	denyCurrentBranch = updateInstead
+[annex]
+	uuid = 757a81e7-f905-4796-9941-a2772ec190b6
+	version = 5
+git-annex version: 6.20181011+git124-g94aa0e2f6-1~ndall+1
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.12 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+local repository version: 5
+\"\"\"]]
+</details>
+
+Reflecting on the discovery of that \"no such protocol name\", googled [github hit](https://github.com/fpco/haskell-scratch/issues/2#issuecomment-285923941), added `apt-get install -y libnss3 libnss-lwres libnss-mdns` to the new version of the docker image - that didn't help.
+
+"""]]
diff --git a/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_3_4d03d12bfba811e0a67551e10201200b._comment b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_3_4d03d12bfba811e0a67551e10201200b._comment
new file mode 100644
index 0000000000..8f05aa8a94
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_3_4d03d12bfba811e0a67551e10201200b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2018-11-12T19:34:00Z"
+ content="""
+even though not that -- probably due to `--no-install-recommends` while installing git-annex-standalone... may be at least core needed libs needed for annex operation could be added to Depends for the git-annex debian pkg?
+"""]]
diff --git a/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_4_1ea0f89c3c9e8bf1142b2c234cdf90c3._comment b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_4_1ea0f89c3c9e8bf1142b2c234cdf90c3._comment
new file mode 100644
index 0000000000..3ed3d19257
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_4_1ea0f89c3c9e8bf1142b2c234cdf90c3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="yeap -- it is netbase which is needed"
+ date="2018-11-13T04:20:28Z"
+ content="""
+spotted that netbase is among recommends thus is not installed while `apt-get install --no-install-recommends git-annex-standalone` .  Installed and issue is gone.
+
+- I feel like we had that issue/discussion before, but don't you think it would be valuable to make `netbase` a Depends not just Recommends?
+
+- Also it would be nice if there was a more logical error, info or at least debug message whenever annex fails to perform network operations, instead of just marking remote as \"non-annex\".
+"""]]
diff --git a/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_5_72c67ef575c90071040cf5347d81ce01._comment b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_5_72c67ef575c90071040cf5347d81ce01._comment
new file mode 100644
index 0000000000..53b41a1d40
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_5_72c67ef575c90071040cf5347d81ce01._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-11-13T17:30:33Z"
+ content="""
+netbase was already added to depends in version 6.20180926.
+
+Yes, I missed the folded data, the UI provides almost no clue that it's
+an interactive element. 
+"""]]
diff --git a/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_6_dcfb1dfb33a690a73547a5855e0ee55d._comment b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_6_dcfb1dfb33a690a73547a5855e0ee55d._comment
new file mode 100644
index 0000000000..14da6ef245
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/annex_sets_remote___40__regular_http__41___to_be_ignored_while_running_in_docker_container/comment_6_dcfb1dfb33a690a73547a5855e0ee55d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="my bad"
+ date="2018-11-15T12:34:58Z"
+ content="""
+eh, and when you added it, I incorrectly adjusted the standalone patch in 042e20d895e022f283d7fb210e61bc19a77b0c39 by not including netbase into Depends.
+I have emailed you the patch, and I think this issue could be closed with it
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name.mdwn b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name.mdwn
new file mode 100644
index 0000000000..b2d5eff73c
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name.mdwn
@@ -0,0 +1,70 @@
+### Please describe the problem.
+
+It is probably not a regression (since happens with now elderly git-annex in debian sid), it could be something either changed on debian sid or on datalad side (originally ran into it while trying to build 0.11.7 package for debian sid) to make test directory name even more "tricky" than before.
+
+Summary:  `git annex init` fails even though `git init` (and other commands, not shown here) works just fine:
+
+
+[[!format sh """
+root@smaug:/tmp/datalad_temp_test_create_with_obscure_name18qdmqwg/ "';a&b&cΔЙקم๗あ `| 1# pwd
+/tmp/datalad_temp_test_create_with_obscure_name18qdmqwg/ "';a&b&cΔЙקم๗あ `| 1
+
+# git init was ran before already
+root@smaug:/tmp/datalad_temp_test_create_with_obscure_name18qdmqwg/ "';a&b&cΔЙקم๗あ `| 1# git init
+Reinitialized existing Git repository in /tmp/datalad_temp_test_create_with_obscure_name18qdmqwg/ "';a&b&cΔЙקم๗あ `| 1/.git/
+
+root@smaug:/tmp/datalad_temp_test_create_with_obscure_name18qdmqwg/ "';a&b&cΔЙקم๗あ `| 1# git annex init
+init  fatal: Unable to create '/tmp/datalad_temp_test_create_with_obscure_name18qdmqwg/ "';a&b&c `| 1/.git/annex/index.lock': No such file or directory
+fatal: Unable to create '/tmp/datalad_temp_test_create_with_obscure_name18qdmqwg/ "';a&b&c `| 1/.git/annex/index.lock': No such file or directory
+
+git-annex: failed to read sha from git write-tree
+CallStack (from HasCallStack):
+  error, called at ./Git/Sha.hs:18:15 in main:Git.Sha
+failed
+git-annex: init: 1 failed
+
+root@smaug:/tmp/datalad_temp_test_create_with_obscure_name18qdmqwg/ "';a&b&cΔЙקم๗あ `| 1# git annex version
+git-annex version: 7.20190129
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+
+"""]]
+
+so above version is the one in Debian proper (apparently quite dated!).  I have tried with 7.20190819+git2-g908476a9b-1~ndall+1 and 7.20190819+git60-gcdb679818-1~ndall+1
+
+You can see that `git-annex` got unicode portion of the directory name stripped (reports ``` "';a&b&c `| 1``` instead of ``` "';a&b&cΔЙקم๗あ `| 1```).  
+
+My wild guess is that full path (instead of a relative path) is used somewhere, encoded/decoded with losses, and then kaboom comes.
+
+<details>
+<summary>locale is just C</summary> 
+
+[[!format sh """
+root@smaug:/tmp/datalad_temp_test_create_with_obscure_name18qdmqwg/ "';a&b&cΔЙקم๗あ `| 1# locale
+LANG=C
+LANGUAGE=
+LC_CTYPE="C"
+LC_NUMERIC="C"
+LC_TIME="C"
+LC_COLLATE="C"
+LC_MONETARY="C"
+LC_MESSAGES="C"
+LC_PAPER="C"
+LC_NAME="C"
+LC_ADDRESS="C"
+LC_TELEPHONE="C"
+LC_MEASUREMENT="C"
+LC_IDENTIFICATION="C"
+LC_ALL=C
+"""]]
+</details>
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> fixed in the haskell process library. [[done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_1_10045d7efa652ded4c41fd8c3e089bf4._comment b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_1_10045d7efa652ded4c41fd8c3e089bf4._comment
new file mode 100644
index 0000000000..35b3b24a3d
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_1_10045d7efa652ded4c41fd8c3e089bf4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="archaeological expedition summary"
+ date="2019-09-09T12:53:16Z"
+ content="""
+just notes on the mystery on why didn't trigger before:
+- example shown above was triggered by a `test_create_with_obscure_name` which was added only recently in 0.11.7~13^2~2
+- (here I was going to provide analysis for other tests, but ran out of time... ;))
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_2_6d57bda8ddc603f24e16018969ac780a._comment b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_2_6d57bda8ddc603f24e16018969ac780a._comment
new file mode 100644
index 0000000000..9076757039
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_2_6d57bda8ddc603f24e16018969ac780a._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-09T13:04:29Z"
+ content="""
+To reproduce this, set LANG=C. In a unicode locale, it does not have the
+problem.
+
+"קم๗あ" is a sufficient amount of unicode to cause the failure (so is "¡").
+The ascii punctuation is not involved, eg it works in a directory named
+"';a&b&c `| 1
+
+	joey@darkstar:/tmp/datalad_temp_test_create_with_obscure_name18qdmqwg/קم๗あ>LANG=C git-annex init
+	init  fatal: Unable to create '/tmp/datalad_temp_test_create_with_obscure_name18qdmqwg//.git/annex/index.lock': No such file or directory
+
+Notice that all the unicode has been stripped out of the directory name
+somehow.
+
+This is not happening to git-annex generally; .git/annex/ get created and
+populated with several files; it's the call to git update-index to create the
+annex index file that is failing.
+
+Dumping the env that git-annex sets when running that command, it includes eg 
+`("GIT_INDEX_FILE","/tmp/\56514\56481/.git/annex/index")`; the "¡"
+has been decomposed into what I think are two unicode surrigates; that's
+produced when getting the working directory.
+
+	joey@darkstar:/tmp/¡>LANG=C ghci
+	GHCi, version 8.6.5: http://www.haskell.org/ghc/  :? for help
+	Loaded GHCi configuration from /home/joey/.etc/.ghci
+	ghci> import System.Posix.Directory
+	ghci> getWorkingDirectory 
+	"/tmp/\56514\56481"
+
+This shell command does not exhibit the problem:
+
+	printf '100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1\tfrotz' | GIT_INDEX_FILE=`pwd`/.git/annex/index LANG=C git update-index --index-info
+
+So, the problem is probably in the process library's passing
+of unicode environment variables to exec. I've verified the problem in ghci,
+running createProcess with this:
+
+	CreateProcess {cmdspec = RawCommand "git" ["update-index","--index-info"], cwd = Nothing, env = Just [("GIT_INDEX_FILE","/tmp/\56514\56481/.git/annex/index")], std_in = Inherit, std_out = Inherit, std_err = Inherit, close_fds = False, create_group = False, delegate_ctlc = False, detach_console = False, create_new_console = False, new_session = False, child_group = Nothing, child_user = Nothing, use_process_jobs = False}
+
+This bug needs to be forwarded to process.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_3_1a982c19fc7360a2a231b5a23142bbba._comment b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_3_1a982c19fc7360a2a231b5a23142bbba._comment
new file mode 100644
index 0000000000..5cf48bf86e
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_3_1a982c19fc7360a2a231b5a23142bbba._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-09-09T18:41:05Z"
+ content="""
+<https://github.com/haskell/process/issues/152> forwarded with a
+prospective patch.
+
+----
+
+Normally git-annex tries to use relative paths, and if it used a relative
+path to .git/annex/index, it would avoid this problem. Except perhaps
+if `GIT_DIR` pointed to a different directory with unicode in its path.
+A relative `GIT_INDEX_FILE` would not suffice to close this bug, but would
+fix your test suite. But, git has some very strange behavior with a relative
+`GIT_INDEX_FILE`, it's not necessarily treated as relative to pwd.
+So I'd rather not open that can of worms.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_4_397686077b5a63196204327c178a7064._comment b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_4_397686077b5a63196204327c178a7064._comment
new file mode 100644
index 0000000000..8dfb06b618
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_4_397686077b5a63196204327c178a7064._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""fixed in process"""
+ date="2019-09-11T17:06:53Z"
+ content="""
+I've gotten the process library fixed, the version will probably be
+process-1.6.5.2.
+
+Doesn't seem to make sense to make git-annex require the fixed version,
+just use it when available. So closing this issue.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_5_b95c1da49c3a4eecca8038c03a46c709._comment b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_5_b95c1da49c3a4eecca8038c03a46c709._comment
new file mode 100644
index 0000000000..8900a7b66c
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_5_b95c1da49c3a4eecca8038c03a46c709._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2019-09-11T18:03:11Z"
+ content="""
+GREAT! thank you!  I should not forget to try backporting it after it gets released for buster so our -standalone package uses it.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_6_d2f9a37824dd2bb49892430f9f271f1c._comment b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_6_d2f9a37824dd2bb49892430f9f271f1c._comment
new file mode 100644
index 0000000000..9f1f0b162a
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fails_to_init_under_a_directory_with_a___34__tricky__34___name/comment_6_d2f9a37824dd2bb49892430f9f271f1c._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2019-09-11T19:50:43Z"
+ content="""
+Backporting it would be trivial, it's a single word change.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure.mdwn b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure.mdwn
new file mode 100644
index 0000000000..7bf7675d7f
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure.mdwn
@@ -0,0 +1,36 @@
+[[!meta title="double rsync run and test failure"]]
+
+might be a flaky test/operation, happened while building in i386 buster environment:
+
+[[!format sh """
+neurodebian@smaug ..7.20190730+git103-g070fbd693-1~ndall+1 % grep -B20 -A1 FAIL git-annex_7.20190730+git103-g070fbd693-1~ndall+1_i386.build
+             20 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+(checksum...) (recording state in git...)
+ok
+(recording state in git...)
+OK (1.00s)
+    move (ssh remote):                                    move foo (from origin...) 
+(checksum...) ok                  
+(recording state in git...)
+move foo (to origin...) 
+ok                                
+(recording state in git...)
+OK (0.99s)
+    copy:                                                 copy foo (from origin...) 
+SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+             20 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+
+SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+             20 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+failed
+copy: 1 failed
+FAIL (0.34s)
+      Test.hs:530:
+"""]]
+
+I have tried to rebuild (`debian/rules binary`) second time while in the same environment -- didn't succeed... but then I proceeded to build amd64 fine, and redid i386 build just fine
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] though w/o a true root cause analysis --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_1_ec7aa500a826beb813bc5313af9aa983._comment b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_1_ec7aa500a826beb813bc5313af9aa983._comment
new file mode 100644
index 0000000000..4d3cd495eb
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_1_ec7aa500a826beb813bc5313af9aa983._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-08-13T17:28:15Z"
+ content="""
+This is the same problem I tried to deal with in 
+[[!commit f27c5db5c566bdc0baae256b67df04a50027679f]].
+Apparently not fully
+
+Or at least the double run of rsync with no indication
+why it thought the first one failed appears to be the same.
+And IIRC I saw that sometimes without the permissions error and it still
+failed.
+
+I was having to run git-annex test in a loop for an hour or so to reproduce
+it.
+
+So, for some reason git-annex thinks the rsync failed, although it got to
+100%. If that happens once, it retries automatically. The second time it
+thinks rsync has failed, it sees the file didn't get any larger,
+and so gives up. That makes sense, but I don't know how rsync would get 
+to 100% and then apparently exit nonzero, without displaying any error
+message.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_2_a61ed5b8f438caf0b8c7a53e08e1986a._comment b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_2_a61ed5b8f438caf0b8c7a53e08e1986a._comment
new file mode 100644
index 0000000000..1ccfc9a364
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_2_a61ed5b8f438caf0b8c7a53e08e1986a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2019-08-13T18:15:36Z"
+ content="""
+and git-annex cannot rely on the check that size of the receiving file has reached the target size?
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_3_09343b67a0c6e82203b76ef591233869._comment b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_3_09343b67a0c6e82203b76ef591233869._comment
new file mode 100644
index 0000000000..e5eedd3725
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_3_09343b67a0c6e82203b76ef591233869._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-08-13T19:14:41Z"
+ content="""
+No, it cannot in general rely on that. Consider a file transfer program
+that allocates the whole file full of 0 to start.
+
+This needs to be reproduced in strace so we can see what it happening with
+rsync.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_4_8be6e27e081d4bc8c0fa178088a10a91._comment b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_4_8be6e27e081d4bc8c0fa178088a10a91._comment
new file mode 100644
index 0000000000..913b683b28
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_4_8be6e27e081d4bc8c0fa178088a10a91._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-08-15T18:00:42Z"
+ content="""
+And even if we assume rsync never pre-allocates a file before receiving it, it
+probably does do some things at the end, like setting the final permissions and
+timestamp.
+
+The permissions error looked like this:
+
+    get foo (from origin...)
+    SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+                 20 100%    0.00kB/s    0:00:00  ^M             20 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+    (from origin...)
+    SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+                 20 100%    0.00kB/s    0:00:00  ^M             20 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+    rsync: open "/home/joey/src/git-annex/.t/tmprepo1103/.git/annex/tmp/SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77" failed: Permission denied (13)
+    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]
+ 
+That looked as if the first rsync had gotten as far as removing the write bit
+from the file. Interestingly, the second rsync seems to have received the whole
+(small) file content before ever trying to open the file for write.
+
+The only recent change I can think of involving rsync was the CoW probing
+change, but I don't see how that could possibly lead to this behavior.
+
+And I'm not sure this is a new problem. The test suite has been intermittently
+failing for several months, around this same point. The failure did not
+include any useful error message, so I could not debug it, and I have IIRC
+done a few things to try to get the test suite to display an error message.
+Perhaps I succeeded.
+
+The intermittent test suite failure looks like this:
+
+	copy: [adjusted/master(unlocked) 05b89a6] empty
+	adjust ok
+	copy foo (from origin...)
+	SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+	20 100% 0.00kB/s 0:00:00 20 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1)
+	
+	SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+	20 100% 0.00kB/s 0:00:00 20 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1)
+	failed
+	copy: 1 failed
+	FAIL (1.12s)
+
+I am not sure if it only happens when testing adjusted unlocked branches/
+v7 unlocked files.
+
+I've run git-annex get; git-annex drop in a tight loop for
+thousands of iterations on an adjusted unlocked branch,
+and can't reproduce the failure that way.
+
+I've made git-annex display rsync's exit status when it's not 0 or 1,
+it has a lot of other exit statuses, so perhaps that will help track
+down how it's failing.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_5_b08d8859f873fcbdc78f938042fe0fbd._comment b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_5_b08d8859f873fcbdc78f938042fe0fbd._comment
new file mode 100644
index 0000000000..86410f6bdb
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_5_b08d8859f873fcbdc78f938042fe0fbd._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-08-15T21:18:20Z"
+ content="""
+I tested a git-annex made to say when the rsync process succeeded,
+and rsync is actually not failing.
+
+So something in git-annex is silently making the transfer fail.
+Could be, for example, that it thinks the file was modified while
+it was being transferred.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_6_357f297d1afab22a59b2bafe4b85facd._comment b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_6_357f297d1afab22a59b2bafe4b85facd._comment
new file mode 100644
index 0000000000..9ddaea9d56
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_6_357f297d1afab22a59b2bafe4b85facd._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2019-08-15T21:55:43Z"
+ content="""
+It is indeed detecting that the file it was sending
+appears to have been modified after the download started.
+
+Probably the file has not really been modified. Instead the inode cache
+for it is somehow wrong.
+
+An instrumented run had cached:
+
+	InodeCache (InodeCachePrim 21765306 20 (MTimeHighRes 1565905801.196804558s)
+	InodeCache (InodeCachePrim 22158907 20 (MTimeHighRes 1565905801.196804558s))
+
+And after the download the file it was sending had:
+
+	InodeCache (InodeCachePrim 21765305 20 (MTimeHighRes 1565905802.380791792s))
+
+Note that the test suite moves the same file from origin,
+and then moves it back, and a while after that get fails.
+So at least one of the cached inodes is for the old copy of the file.
+The other one is probably the work tree copy.
+
+Still have not had luck reproducing outside the test suite with a tight loop
+of move --from and --to and get.
+
+Hypothesis: The test suite uses Annex.main for many of its runs of git-annex,
+and so sqlite does not do whatever it normally does atexit. If flushing
+a change to the db file gets deferred for whatever reason, a later call to
+Annex.main might see old information.
+
+If so, converting the test suite to run git-annex instead of Annex.main
+would avoid the problem.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_7_2181d91c9b5b374c6102fdcc227349fc._comment b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_7_2181d91c9b5b374c6102fdcc227349fc._comment
new file mode 100644
index 0000000000..eed970fd34
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/fresh_build_for_neurodebian__58___test_failure/comment_7_2181d91c9b5b374c6102fdcc227349fc._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2019-08-16T15:03:11Z"
+ content="""
+Confirmed; avoiding calling main has gotten the test suite to be able to
+run at least 500 iterations over 12 hours w/o failing. It had been failing
+in under 1 hour.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD.mdwn b/doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD.mdwn
new file mode 100644
index 0000000000..2900f1ff2e
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD.mdwn
@@ -0,0 +1,59 @@
+Origin: [ReproNim/containers](https://github.com/ReproNim/containers/pull/17) repo where we were brave enough to start using v7 with unlocked files to avoid having symlinks for an image.  TL;DR: here is command to replicate:
+
+[[!format sh """
+$> git clone --depth=50 http://github.com/repronim/containers && cd containers && git fetch origin +refs/pull/19/merge: && git checkout -qf 'HEAD^{}' && git branch && git fetch origin git-annex && git remote add --fetch datalad.datasets.org http://datasets.datalad.org/repronim/containers/.git && git annex upgrade && git annex get scripts/tests/ && ls -l scripts/tests/                                    
+Cloning into 'containers'...                                                                                                                  
+warning: redirecting to https://github.com/repronim/containers/
+remote: Enumerating objects: 404, done.
+remote: Counting objects: 100% (404/404), done.
+remote: Compressing objects: 100% (208/208), done.
+remote: Total 404 (delta 198), reused 367 (delta 171), pack-reused 0
+Receiving objects: 100% (404/404), 59.13 KiB | 1.34 MiB/s, done.
+Resolving deltas: 100% (198/198), done.
+LICENSE  README.md  binds/  images/  scripts/
+warning: redirecting to https://github.com/repronim/containers/
+remote: Enumerating objects: 21, done.
+remote: Counting objects: 100% (21/21), done.
+remote: Compressing objects: 100% (10/10), done.
+remote: Total 12 (delta 9), reused 4 (delta 2), pack-reused 0
+Unpacking objects: 100% (12/12), done.
+From http://github.com/repronim/containers
+ * branch            refs/pull/19/merge -> FETCH_HEAD
+* (HEAD detached at 44d55ad)
+  master
+warning: redirecting to https://github.com/repronim/containers/
+remote: Enumerating objects: 798, done.
+remote: Counting objects: 100% (798/798), done.
+remote: Compressing objects: 100% (167/167), done.
+remote: Total 795 (delta 423), reused 788 (delta 416), pack-reused 0
+Receiving objects: 100% (795/795), 55.50 KiB | 1.50 MiB/s, done.
+Resolving deltas: 100% (423/423), done.
+From http://github.com/repronim/containers
+ * branch            git-annex  -> FETCH_HEAD
+Updating datalad.datasets.org
+From http://datasets.datalad.org/repronim/containers/
+ * [new branch]      git-annex     -> datalad.datasets.org/git-annex
+ * [new branch]      master        -> datalad.datasets.org/master
+ * [new branch]      synced/master -> datalad.datasets.org/synced/master
+upgrade (merging datalad.datasets.org/git-annex into git-annex...)
+(recording state in git...)
+(v5 to v6...) (v6 to v7...) ok
+(recording state in git...)
+get scripts/tests/arg-test.simg 
+  Remote origin not usable by git-annex; setting annex-ignore
+(from datalad.datasets.org...) 
+(checksum...) ok                  
+(recording state in git...)
+total 12
+-rw------- 1 yoh yoh 259 Jul 11 16:10 Singularity.arg-test
+-rw------- 1 yoh yoh  68 Jul 11 16:10 arg-test.simg
+-rwx------ 1 yoh yoh 981 Jul 11 16:10 test_singularity_cmd.bats*
+"""]]
+
+as you can see the arg-test.sim is only 68 bytes, not 2MB or a symlink.
+
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD/comment_1_a377e26b2eb75956c9de9beed0534cc2._comment b/doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD/comment_1_a377e26b2eb75956c9de9beed0534cc2._comment
new file mode 100644
index 0000000000..1442615976
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD/comment_1_a377e26b2eb75956c9de9beed0534cc2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2019-07-11T20:15:45Z"
+ content="""
+further debugging showed that the bug appears if `annex upgrade` is done in detached HEAD mode.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD/comment_2_d1ae8ccbfc3a9dd90cc03e68d5a78071._comment b/doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD/comment_2_d1ae8ccbfc3a9dd90cc03e68d5a78071._comment
new file mode 100644
index 0000000000..c5fb7e5de5
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD/comment_2_d1ae8ccbfc3a9dd90cc03e68d5a78071._comment
@@ -0,0 +1,65 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="a reduced script"
+ date="2019-07-11T20:19:23Z"
+ content="""
+```
+#!/bin/sh
+
+cd $(mktemp -dt gx-XXXXXXX)
+
+git init a
+cd a
+git annex init --version=7
+echo foo >foo
+git add foo
+git commit -mfoo
+
+cd ..
+git clone a b
+cd b
+
+git checkout HEAD^{}
+git annex init
+git annex upgrade
+
+git annex get foo
+cat foo
+
+```
+
+Output:
+
+```
+Initialized empty Git repository in /tmp/gx-RqdQyBF/a/.git/
+init  ok
+(recording state in git...)
+(recording state in git...)
+[master (root-commit) 2b5f739] foo
+ 1 file changed, 1 insertion(+)
+ create mode 100644 foo
+Cloning into 'b'...
+done.
+Note: checking out 'HEAD^{}'.
+
+You are in 'detached HEAD' state. You can look around, make experimental
+changes and commit them, and you can discard any commits you make in this
+state without impacting any branches by performing another checkout.
+
+If you want to create a new branch to retain commits you create, you may
+do so (now or later) by using -b with the checkout command again. Example:
+
+  git checkout -b <new-branch-name>
+
+HEAD is now at 2b5f739 foo
+init  (merging origin/git-annex into git-annex...)
+ok
+(recording state in git...)
+upgrade (v5 to v6...) (v6 to v7...) ok
+get foo (from origin...) (checksum...) ok
+(recording state in git...)
+/annex/objects/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c
+
+```
+"""]]
diff --git a/doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD/comment_3_cd7cc008c3d37caa76416bd2452da90d._comment b/doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD/comment_3_cd7cc008c3d37caa76416bd2452da90d._comment
new file mode 100644
index 0000000000..16434ff7fc
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/get_fails_to_place_v7_unlocked_file_content_into_the_file_tree_in_v7_in_repo_with_detached_HEAD/comment_3_cd7cc008c3d37caa76416bd2452da90d._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-07-16T16:13:49Z"
+ content="""
+I notice that the keys database is not populated in the clone.
+
+Also, the upgrade does not display "scanning for unlocked files".
+And in Annex.WorkTree, we can see why:
+
+	scanUnlockedFiles = whenM (isJust <$> inRepo Git.Branch.current) $ do
+	        showSideAction "scanning for unlocked files"
+
+There is no current git branch in this case.
+
+That check was added in [[!commit 9b995954731e05727d77c7bff487af10da9cb4b9]]
+"only do scan when there's a branch, not in freshly created new repo"
+
+Since it does a ls-tree of HEAD, what it really ought to check for is that
+HEAD is set, which it's not in a fresh new repo. Done.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call.mdwn b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call.mdwn
new file mode 100644
index 0000000000..7641ef9848
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call.mdwn
@@ -0,0 +1,102 @@
+### Please describe the problem.
+
+TL;DR - it seems that obsolete `.git/annex/index.lck  .git/annex/journal.lck  .git/annex/precommit.lck` could cause a new process to hang  on `git commit` or `git annex add` without announcing any problem. git annex version installed is 7.20181211-g1cdb7a2.  But that seems to be not a complete reason - and after removing them still gets stuck
+
+
+I think we initiated `git annex add` invocation over remote ssh session, and then connection eventually dropped before `git annex add` finished.  The repository is large - 47k files.
+So we ended up with some files annex/staged, some just annexed (symlinks to keys), and some not yet tracked by git and in their original form.
+
+I thought to commit first at least what we had already staged, but `git commit` pretty much hanged there for an hour.  It is an NFS mount on an HPC, so IO is not stellar but an hour with little to no CPU consumed sounds like it just got stuck.
+I have checked ps and saw that it is in the `pre-commit` hook with two zombies.  Interrupted and ran manually with `--debug`:
+
+[[!format sh """
+ fmriprep001]$ git annex --debug pre-commit .
+[2019-03-18 18:08:36.049933] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2019-03-18 18:08:36.060284] process done ExitSuccess
+[2019-03-18 18:08:36.060364] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2019-03-18 18:08:36.081517] process done ExitSuccess
+[2019-03-18 18:08:36.081776] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--cached","--name-only","-z","--diff-filter=ACMRT","--","."]
+[2019-03-18 18:08:44.780003] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--name-only","--diff-filter=T","-z","--cached","--","."]
+[2019-03-18 18:08:44.817133] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2019-03-18 18:08:44.827942] process done ExitSuccess
+[2019-03-18 18:08:44.827996] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2019-03-18 18:08:44.837793] process done ExitSuccess
+
+# just hanging there, no notable CPU utilization
+# ps output -- I think I did mistake and didn't grep for git but for annex
+    5765  0.0  0.0 127208  3800 pts/145  Ss   Mar07   0:00     /bin/bash
+   21340  0.0  0.0 113940  1400 pts/145  S+   18:08   0:00       git annex --debug pre-commit .
+   21341  2.0  0.0 1074154224 19164 pts/145 Sl+ 18:08   0:01         /ihome/crc/install/datalad/python3.7/bin/git-annex --debug pre-commit .
+   21353  0.0  0.0      0     0 pts/145  Z+   18:08   0:00           [git] <defunct>
+   21397  0.0  0.0      0     0 pts/145  Z+   18:08   0:00           [git] <defunct>
+
+$ git annex version
+git-annex version: 7.20181211-g1cdb7a2
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.13.1 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+
+"""]]
+
+Retrying to add everything again seems to lead to a stall as well:
+
+[[!format sh """
+fmriprep001]$ git annex --debug add *
+[2019-03-18 18:19:54.527228] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2019-03-18 18:19:54.537078] process done ExitSuccess
+[2019-03-18 18:19:54.537377] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2019-03-18 18:19:54.547586] process done ExitSuccess
+[2019-03-18 18:19:54.547873] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--others","--exclude-standard","-z","--","fmriprep","freesurfer"]
+[2019-03-18 18:19:55.557577] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+[2019-03-18 18:19:55.558288] read: git ["--version"]
+[2019-03-18 18:19:55.560309] process done ExitSuccess
+add freesurfer/sub-000457/mri/lh.ribbon.mgz   
+"""]]
+
+and that file seems to be freshly touched and initially was not staged for a commit according to `git status`:
+
+[[!format sh """
+fmriprep001]$ ls -l freesurfer/sub-000457/mri/lh.ribbon.mgz
+... Mar 18 18:19 freesurfer/sub-000457/mri/lh.ribbon.mgz -> ../../../.git/annex/objects/61/87/MD5E-s103445--f9f251a9f80317fbcf46cf11fa7be520.mgz/MD5E-s103445--f9f251a9f80317fbcf46cf11fa7be520.mgz
+"""]]
+
+here is ps
+
+[[!format sh """
+# ps auxw -H | grep annex    -- showing only relevant portion, no other annex processes detected; 
+#    should have grepped for git! :-/
+   26125  0.0  0.0 113940  1404 pts/145  S+   18:19   0:00       git annex --debug add fmriprep freesurfer
+   26126  0.4  0.0 1074154224 108492 pts/145 Sl+ 18:19   0:00         /ihome/crc/install/datalad/python3.7/bin/git-annex --debug add fmriprep freesurfer
+   26138  0.0  0.0 115916  3432 pts/145  S+   18:19   0:00           git --git-dir=.git --work-tree=. --literal-pathspecs check-attr -z --stdin annex.backend annex.numcopies annex.largefiles --
+"""]]
+
+looking at the list of files for 26126 process I see `.git/annex/journal.lck`  which seems to date to ` Feb 27 ` (3 weeks ago!), and altogether there are 3 lock files from that date:
+`.git/annex/index.lck  .git/annex/journal.lck  .git/annex/precommit.lck`. 
+FWIW, NFS mount options `type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.201.0.82,local_lock=none,addr=10.201.2.178)`
+
+I have removed them, and then called `git commit` which seemed to proceed normally, got to report `(recording state in git...)` but then seemed to get stuck as well:
+
+[[!format sh """
+   31711  0.0  0.0 1460028 3876 pts/145  S+   18:27   0:00       git commit -m Annexed portion of the results, probably was disconnected, so not all  Also there were some stale lock files present .git/annex/index.lck  .git/annex/journal.lck  .git/annex/precommit.lck  which caused precommit and add to hang, removed them
+   31788  0.0  0.0 113184  1412 pts/145  S+   18:27   0:00         /bin/sh .git/hooks/pre-commit
+   31789  0.0  0.0 113940  1404 pts/145  S+   18:27   0:00           git annex pre-commit .
+   31791  1.1  0.0 1074154220 19240 pts/145 Dl+ 18:27   0:04             /ihome/crc/install/datalad/python3.7/bin/git-annex pre-commit .
+   31802  0.0  0.0      0     0 pts/145  Z+   18:27   0:00               [git] <defunct>
+   31889  0.0  0.0      0     0 pts/145  Z+   18:27   0:00               [git] <defunct>
+   31901  1.6  0.0 113964  1608 pts/145  S+   18:27   0:06               git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+    1075  0.0  0.0 113944  1624 pts/145  S+   18:29   0:00               git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+    1076  0.0  0.0 113944  1408 pts/145  S+   18:29   0:00               git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+"""]]
+
+There is also two `.git/annex/misctmp/jlog*` files with one from Feb 28 and one from today.  Today's one is bigger, and used by 31901 but seems not to change for the last 15 minutes.
+
+what could be a reason and any way to mitigate?
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[closing|done]] per comments --[[Joey]] 
diff --git a/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_1_25dd2f0ba99913f26cbcbf55352bb1ab._comment b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_1_25dd2f0ba99913f26cbcbf55352bb1ab._comment
new file mode 100644
index 0000000000..d1ad9c7c57
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_1_25dd2f0ba99913f26cbcbf55352bb1ab._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-03-19T02:33:02Z"
+ content="""
+Since this is NFS, does it have annex.pidlock set?
+
+If so, an stale pid lock (.git/annex/pidlock) can cause a stall, for up to
+annex.pidlockimeout seconds.
+
+The hang points seem consistent with it preparing to commit the journal to
+the git-annex branch and indeed something related to locking.
+An strace would tell for sure.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_2_f5e21a674c54c5dc4c8474ce1b4ffaf1._comment b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_2_f5e21a674c54c5dc4c8474ce1b4ffaf1._comment
new file mode 100644
index 0000000000..11b33946ab
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_2_f5e21a674c54c5dc4c8474ce1b4ffaf1._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="reporting back"
+ date="2019-03-19T17:01:10Z"
+ content="""
+Removing .lck, setting `annex.pidlock=true` worked! got just one complaint from git:
+
+[[!format sh \"\"\"
+$ git commit -m 'Committing staged changes after annex process was killed
+>
+> Also removed stale .git/annex/*.lck and now set annex.pidlock=True for the repo'
+(recording state in git...)
+git-annex: .git/annex/journal/e64_e4a_MD5E-s55076--a7352bf6fd37902fc1dfb6228f2e8a53.log: removeLink: does not exist (No such file or directory)
+
+\"\"\"]]
+I found that file (via `find *  -lname *MD5E-s55076--a7352bf6fd37902fc1dfb6228f2e8a53*` FTR), it was not known to git yet, so I am now running `annex add` on it (takes awhile -- I guess repo is indeed got large + NFS) -- will report back when done/if there is more.
+
+
+
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_3_028eca36967a89e5f479802499232a90._comment b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_3_028eca36967a89e5f479802499232a90._comment
new file mode 100644
index 0000000000..3f8c80b6c9
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_3_028eca36967a89e5f479802499232a90._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2019-03-19T17:41:12Z"
+ content="""
+Managed to login to that node again, after hours (>3) of \"running\" `annex add` is still there with current process tree being
+
+[[!format sh \"\"\"
+  PID TTY      STAT   TIME COMMAND
+22168 pts/50   Ss     0:00 /bin/bash
+15560 pts/50   S+     0:00  \_ git annex add freesurfer/sub-000458/label/lh.BA4p_exvivo.thresh.label
+15565 pts/50   Dl+    0:18      \_ /ihome/crc/install/datalad/python3.7/bin/git-annex add freesurfer/sub-000458/label/lh.BA4p_exvivo.thresh.label
+15591 pts/50   Z+     0:00          \_ [git] <defunct>
+15601 pts/50   S+     0:00          \_ git --git-dir=.git --work-tree=. --literal-pathspecs check-attr -z --stdin annex.backend annex.numcopies annex.largefiles --
+15625 pts/50   S+     0:00          \_ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+15626 pts/50   S+     0:00          \_ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+15642 pts/50   Z+     0:00          \_ [git] <defunct>
+15650 pts/50   Z+     0:00          \_ [git] <defunct>
+15703 pts/50   S+     0:02          \_ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+
+\"\"\"]]
+
+and all the locks there, and I believe being generated by this `annex add` run:
+
+[[!format sh \"\"\"
+$ /bin/ls .git/annex/
+index  index.lck  journal  journal.lck  misctmp  objects  pidlock  precommit.lck  sentinal  sentinal.cache
+\"\"\"]]
+
+the process 15565 is slowly increasing its seconds (now 19)... is that a good sign (no lockup, just very slow IO) or not (it is locked up, and all the time corresponds just to the periodic querying of the lock)? if to strace -- which particular process? or should I interrupt and run the entire `annex add` under strace?  
+
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_4_6657ceac22df80251b74c6e4b47f8ba0._comment b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_4_6657ceac22df80251b74c6e4b47f8ba0._comment
new file mode 100644
index 0000000000..4679ce4e0d
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_4_6657ceac22df80251b74c6e4b47f8ba0._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-03-19T17:59:05Z"
+ content="""
+Certianly sounds like the process is not deadlocked.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_5_96f485e38778448804ae253f9032babc._comment b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_5_96f485e38778448804ae253f9032babc._comment
new file mode 100644
index 0000000000..5e148b2e12
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_5_96f485e38778448804ae253f9032babc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-03-19T19:55:24Z"
+ content="""
+Although, the haskell RTS uses a select loop with a timeout and so might use
+a small amount of CPU while otherwise blocked waiting on a lock..
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_6_0e3ae1862408b6d0c5e0acd9e9fa20b5._comment b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_6_0e3ae1862408b6d0c5e0acd9e9fa20b5._comment
new file mode 100644
index 0000000000..971c99ae1a
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_6_0e3ae1862408b6d0c5e0acd9e9fa20b5._comment
@@ -0,0 +1,54 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="more info on hanging"
+ date="2019-03-19T21:04:54Z"
+ content="""
+[[!format sh \"\"\"
+$ strace -f -p  15565
+strace: Process 15565 attached with 5 threads
+[pid 15570] futex(0x7f0c2c000924, FUTEX_WAIT_PRIVATE, 15, NULL <unfinished ...>
+[pid 15568] restart_syscall(<... resuming interrupted poll ...> <unfinished ...>
+[pid 15566] read(3,  <unfinished ...>
+[pid 15567] futex(0x4a454a4, FUTEX_WAIT_PRIVATE, 27143, NULL <unfinished ...>
+[pid 15566] <... read resumed> \"\1\0\0\0\0\0\0\0\", 8) = 8
+[pid 15566] read(3, \"\1\0\0\0\0\0\0\0\", 8) = 8
+[pid 15566] read(3, \"\1\0\0\0\0\0\0\0\", 8) = 8
+.... keeps going, had to bf, kill -9 strace process
+\"\"\"]]
+and that 15566 is a thread:
+[[!format sh \"\"\"
+$ ps -L -p 15565
+  PID   LWP TTY          TIME CMD
+15565 15565 pts/50   00:00:01 git-annex
+15565 15566 pts/50   00:00:31 ghc_ticker
+15565 15567 pts/50   00:00:00 ghc_worker
+15565 15568 pts/50   00:00:00 ghc_worker
+15565 15570 pts/50   00:00:00 ghc_worker
+
+$ ls -l /proc/15566/fd | anon
+total 0
+lrwx------ 1 USER GROUP 64 Mar 19 17:03 0 -> /dev/pts/50
+lrwx------ 1 USER GROUP 64 Mar 19 17:03 1 -> /dev/pts/50
+lrwx------ 1 USER GROUP 64 Mar 19 17:03 10 -> anon_inode:[eventfd]
+lrwx------ 1 USER GROUP 64 Mar 19 17:03 11 -> /dev/shm/cd6281f9a8c5f62e1da78a60ca9ca1b4D_fmriprep001_.git_annex_pidlock.lck
+lrwx------ 1 USER GROUP 64 Mar 19 17:03 12 -> /zfs1/GROUP/USER/R03/WM-R03/DIAMOND/fmriprep001/.git/annex/misctmp/jlog15565-2
+l-wx------ 1 USER GROUP 64 Mar 19 17:03 13 -> pipe:[233188705]
+lr-x------ 1 USER GROUP 64 Mar 19 17:03 14 -> pipe:[233188706]
+l-wx------ 1 USER GROUP 64 Mar 19 17:03 16 -> pipe:[233188711]
+lr-x------ 1 USER GROUP 64 Mar 19 17:03 17 -> pipe:[233188712]
+l-wx------ 1 USER GROUP 64 Mar 19 17:03 18 -> pipe:[233188714]
+lr-x------ 1 USER GROUP 64 Mar 19 17:03 19 -> pipe:[233188715]
+lrwx------ 1 USER GROUP 64 Mar 19 16:59 2 -> /dev/pts/50
+l-wx------ 1 USER GROUP 64 Mar 19 17:03 20 -> pipe:[233188718]
+lr-x------ 1 USER GROUP 64 Mar 19 17:03 21 -> pipe:[233188719]
+lrwx------ 1 USER GROUP 64 Mar 19 17:03 3 -> anon_inode:[timerfd]
+lrwx------ 1 USER GROUP 64 Mar 19 17:03 4 -> anon_inode:[eventpoll]
+lr-x------ 1 USER GROUP 64 Mar 19 17:03 5 -> pipe:[233191520]
+l-wx------ 1 USER GROUP 64 Mar 19 17:03 6 -> pipe:[233191520]
+lrwx------ 1 USER GROUP 64 Mar 19 17:03 7 -> anon_inode:[eventfd]
+lr-x------ 1 USER GROUP 64 Mar 19 17:03 8 -> pipe:[233191523]
+l-wx------ 1 USER GROUP 64 Mar 19 17:03 9 -> pipe:[233191523]
+
+\"\"\"]]
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_7_7fcb97b7d7f26fb6964a574ba1c8cd20._comment b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_7_7fcb97b7d7f26fb6964a574ba1c8cd20._comment
new file mode 100644
index 0000000000..9b4c4690b6
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_7_7fcb97b7d7f26fb6964a574ba1c8cd20._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2019-03-20T15:52:45Z"
+ content="""
+Hard to see for sure from this strace tail end, but the fd number sequence
+suggests it first took the pid lock:
+
+lrwx------ 1 USER GROUP 64 Mar 19 17:03 11 -> /dev/shm/cd6281f9a8c5f62e1da78a60ca9ca1b4D_fmriprep001_.git_annex_pidlock.lck
+
+And since it then seems to have proceeded to start to write to this file,
+the pid lock is apparently not the hang point.
+
+lrwx------ 1 USER GROUP 64 Mar 19 17:03 12 -> /zfs1/GROUP/USER/R03/WM-R03/DIAMOND/fmriprep001/.git/annex/misctmp/jlog15565-2
+
+So stageJournal is running, after openjlog. That does not involve any
+further locks, and would not normally take a long time unless 
+.git/annex/journal/ has an unusual number of files in it. It seems to have
+stalled for some reason. It should have started a git update-index process
+and fed data into it.
+
+Do you know if this process had a child git update-index running 
+at this point? It could be that child is what is stalled, somehow.
+
+The number of lines in the jlog15565-2 file would also be a clue to how far
+ it got before it got stuck.
+
+But I think a full strace may be needed to find the sticking point.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_8_ba2dd3b91147e2979bc90a022f6e0252._comment b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_8_ba2dd3b91147e2979bc90a022f6e0252._comment
new file mode 100644
index 0000000000..8693b4c2cf
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_8_ba2dd3b91147e2979bc90a022f6e0252._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2020-03-30T15:59:33Z"
+ content="""
+The precommit.lck is no longer used, it was not needed since v8. But
+this bug does not really appear to be about that lock at all.
+
+Pity there was no followup to my last questions. At this point I can either
+close the bug report, or mark it moreinfo or something, but it seems pretty
+unlikely we will get to the bottom of it.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_9_fe629ccb023c2564dbf78402d92bef66._comment b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_9_fe629ccb023c2564dbf78402d92bef66._comment
new file mode 100644
index 0000000000..2a4c9fe236
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git-annex_precommit_.__gets_stuck_after_likely_interrupted___96__annex_add__96___call/comment_9_fe629ccb023c2564dbf78402d92bef66._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="Let's just close"
+ date="2020-03-30T16:32:24Z"
+ content="""
+I guess let's just close it for now -- I have managed to miss your reply back then (may be didn't check \"email replies to me\"), so the path got cold.
+I hope that I will get back to exercising such workflows soon, so we might get back to it in a new manifestation if it happens again.
+Cheers
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__.mdwn b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__.mdwn
new file mode 100644
index 0000000000..6ba26d4abf
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__.mdwn
@@ -0,0 +1,47 @@
+### Please describe the problem.
+
+I got a new server for the repronim project (welcome `typhon` to the family of `smaug`, `drogon`, and `falkor`).  Wanted to redo https://www.datalad.org/test_fs_analysis.html benchmarking.  Added `git annex test` call to see how its time would vary across file systems etc.
+
+My surprise was that my script never exited.
+
+Current ps tree is  (yeah, running as `root`, likely will reinstall the thing anyways fully after I am done benchmarking)
+
+```
+root      185696  0.0  0.0  62536 54768 pts/1    S+   Nov15   2:56           python test_fs.py benchmark
+root     3655423  0.0  0.0   2484   516 pts/1    S+   Nov18   0:00             /bin/sh -c cd test9; git annex test
+root     3655424  0.0  0.0   9728  3340 pts/1    S+   Nov18   0:00               git annex test
+root     3655425  0.0  0.0 1076293924 28360 pts/1 Sl+ Nov18   0:00                 /usr/bin/git-annex test
+root     3696268  0.2  0.0 1074196636 41932 pts/1 Sl+ Nov18  13:14                   /usr/bin/git-annex --color=never test
+root     3710526  0.0  0.0 1074122856 44736 pts/1 Sl+ Nov18   0:00                     /usr/bin/git-annex move --to origin foo
+root     3710593  0.0  0.0      0     0 pts/1    Z+   Nov18   0:00                       [git] <defunct>
+root     3710594  0.0  0.0      0     0 pts/1    Z+   Nov18   0:00                       [git] <defunct>
+root     3710595  0.0  0.0      0     0 pts/1    Z+   Nov18   0:00                       [git] <defunct>
+root     3710596  0.0  0.0      0     0 pts/1    Z+   Nov18   0:00                       [git] <defunct>
+root     3710597  0.0  0.0   2484   516 pts/1    S+   Nov18   0:00                       sh -c git-annex test --fakessh -- 'localhost' 'git-annex-shell '"'"'p2pstdio'"'"' '"'"'/mnt/test/test9/.t/75/main0'"'"' '"'"'6129b8ec-34af-47d1-b7e6-3c4fcc0d33e3'"'"' --uuid c129397d-8209-40ea-8347-16a8c3fe69de'
+root     3710598  0.0  0.0 1074048960 20408 pts/1 Sl+ Nov18   0:00                         git-annex test --fakessh -- localhost git-annex-shell 'p2pstdio' '/mnt/test/test9/.t/75/main0' '6129b8ec-34af-47d1-b7e6-3c4fcc0d33e3' --uuid c129397d-8209-40ea-8347-16a8c3fe69de
+root     3710604  0.0  0.0   2484   580 pts/1    S+   Nov18   0:00                           /bin/sh -c git-annex-shell 'p2pstdio' '/mnt/test/test9/.t/75/main0' '6129b8ec-34af-47d1-b7e6-3c4fcc0d33e3' --uuid c129397d-8209-40ea-8347-16a8c3fe69de
+root     3710605  0.0  0.0 1074122860 18948 pts/1 Sl+ Nov18   2:39                             git-annex-shell p2pstdio /mnt/test/test9/.t/75/main0 6129b8ec-34af-47d1-b7e6-3c4fcc0d33e3 --uuid c129397d-8209-40ea-8347-16a8c3fe69de
+
+``` 
+
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 10.20221003
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+
+```
+
+any ideas? need access to troubleshoot?
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_10_d258114e6e8f8db28b65a39cb13f2a04._comment b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_10_d258114e6e8f8db28b65a39cb13f2a04._comment
new file mode 100644
index 0000000000..4a2a692b2b
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_10_d258114e6e8f8db28b65a39cb13f2a04._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2022-12-09T16:16:10Z"
+ content="""
+The retest seemed to hang again, but I'm not sure I was testing the right
+binary. Running it again.
+
+This patch exposes when the lock is held and so illustrates the bug
+reliably and quickly:
+
+	diff --git a/Command/Smudge.hs b/Command/Smudge.hs
+	index a5d8871998..cf6e2973f8 100644
+	--- a/Command/Smudge.hs
+	+++ b/Command/Smudge.hs
+	@@ -127,7 +129,8 @@ clean'
+	 	-> (Key -> Annex ())
+	 	-- ^ emitpointer: Emit a pointer file for the key.
+	 	-> Annex ()
+	-clean' file mk passthrough discardreststdin emitpointer =
+	+clean' file mk passthrough discardreststdin emitpointer = do
+	+	calcRestageLog () (\_ _ -> ())
+ 		ifM (fileOutsideRepo file)
+	 		( passthrough
+	 		, inSmudgeCleanFilter go
+
+With that patch, the unfixed git-annex hangs immediately. With
+my fix, it does not hang, which seems to show I fixed it correctly..
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_11_adc040aad7d339e22fef76a2cbc4a312._comment b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_11_adc040aad7d339e22fef76a2cbc4a312._comment
new file mode 100644
index 0000000000..23537088d8
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_11_adc040aad7d339e22fef76a2cbc4a312._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2022-12-10T16:02:15Z"
+ content="""
+Got a clean test run with the right binary for sure, and I've confirmed
+this bug is really fixed. Test ran 20k iterations successfully.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_1_e07a5dd0abb2049b4bb0bf26fa2ebab5._comment b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_1_e07a5dd0abb2049b4bb0bf26fa2ebab5._comment
new file mode 100644
index 0000000000..0df28ac7b5
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_1_e07a5dd0abb2049b4bb0bf26fa2ebab5._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-11-28T18:11:41Z"
+ content="""
+Seems like the test it is stuck in is "move (ssh remote)".
+
+Is this replicable?
+
+I wonder if `test_fs.py` is doing something that causes the problem.
+There is some complexity in there. Maybe it's happening on one
+particular FS.
+
+If it happens when not run by `test_fs.py`, it would be useful to get a
+debug log, because I think that seeing the P2P protocol dump would help
+explain what has happened.
+
+There was not a good way to get the test suite to output a full debug
+log, so I had to implement one. With an updated build of git-annex,
+you can use:
+
+	git-annex test -J1 --test-debug
+
+Here's the expected output of that section of the test suite, when it
+is working properly:
+
+	move foo [2022-11-28 14:54:11.10011679] (Utility.Process) process [390399] chat: sh ["-c","git-annex test --fakessh -- 'localhost' 'git-annex-shell '\"'\"'p2pstdio'\"'\"' '\"'\"'/home/joey/src/git-annex/.t/3/main1'\"'\"' '\"'\"'--debug'\"'\"' '\"'\"'c76e0406-38ea-413e-9fb0-56cc32847734'\"'\"' --uuid 000c7285-ec19-4c15-9c67-4dd4b7c74775'"]
+	[2022-11-28 14:54:11.129754519] (P2P.IO) [ThreadId 4] P2P > AUTH-SUCCESS 000c7285-ec19-4c15-9c67-4dd4b7c74775
+	[2022-11-28 14:54:11.130259741] (P2P.IO) [ssh connection Just 390399] [ThreadId 4] P2P < AUTH-SUCCESS 000c7285-ec19-4c15-9c67-4dd4b7c74775
+	[2022-11-28 14:54:11.13041388] (P2P.IO) [ssh connection Just 390399] [ThreadId 4] P2P > VERSION 1
+	[2022-11-28 14:54:11.130680315] (P2P.IO) [ThreadId 4] P2P < VERSION 1
+	[2022-11-28 14:54:11.13087982] (P2P.IO) [ThreadId 4] P2P > VERSION 1
+	[2022-11-28 14:54:11.131127415] (P2P.IO) [ssh connection Just 390399] [ThreadId 4] P2P < VERSION 1
+	[2022-11-28 14:54:11.131262307] (P2P.IO) [ssh connection Just 390399] [ThreadId 4] P2P > CHECKPRESENT SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+	[2022-11-28 14:54:11.131679501] (P2P.IO) [ThreadId 4] P2P < CHECKPRESENT SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+	[2022-11-28 14:54:11.132388822] (P2P.IO) [ThreadId 4] P2P > FAILURE
+	[2022-11-28 14:54:11.13261351] (P2P.IO) [ssh connection Just 390399] [ThreadId 4] P2P < FAILURE
+	(to origin...) 
+	[2022-11-28 14:54:11.135583194] (P2P.IO) [ssh connection Just 390399] [ThreadId 4] P2P > PUT foo SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+	[2022-11-28 14:54:11.136134981] (P2P.IO) [ThreadId 4] P2P < PUT foo SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77
+	[2022-11-28 14:54:11.136824468] (P2P.IO) [ThreadId 4] P2P > PUT-FROM 0
+	[2022-11-28 14:54:11.137123219] (P2P.IO) [ssh connection Just 390399] [ThreadId 4] P2P < PUT-FROM 0
+	...
+	[2022-11-28 14:54:11.148194515] (P2P.IO) [ssh connection Just 390399] [ThreadId 4] P2P > DATA 20
+	[2022-11-28 14:54:11.148414855] (P2P.IO) [ThreadId 4] P2P < DATA 20
+	[2022-11-28 14:54:11.148739395] (P2P.IO) [ssh connection Just 390399] [ThreadId 4] P2P > VALID
+	^M100%  20 B              2 KiB/s 0s[2022-11-28 14:54:11.152428942] (P2P.IO) [ThreadId 4] P2P < VALID
+	...
+	[2022-11-28 14:54:11.177599567] (P2P.IO) [ThreadId 4] P2P > SUCCESS
+	[2022-11-28 14:54:11.177858296] (P2P.IO) [ssh connection Just 390399] [ThreadId 4] P2P < SUCCESS
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_2_419de3fe25c490b251b8a6a7a9b24ed6._comment b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_2_419de3fe25c490b251b8a6a7a9b24ed6._comment
new file mode 100644
index 0000000000..5c38116c68
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_2_419de3fe25c490b251b8a6a7a9b24ed6._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-11-29T21:45:15Z"
+ content="""
+I examined this situation on the machine. I had to ctrl-z the process to
+get a shell. 
+
+Then I checked what the stdin of 3710605 was, and it was still 
+open, and was a pipe from 3710526. So that's why the p2pstdio process 
+was still running; that pipe should be closed when the parent git-annex
+is done, but the parent was apparently stuck on something.
+
+Then I straced 3710605 but it was suspended (oops). So I ran `fg`. This
+somehow unstuck everything! The test suite finished up very fast.
+
+Here is what it output for the test that had gotten stuck:
+
+	Tests
+	  Repo Tests v8 unlocked
+	    Init Tests
+	      init:            OK (2.54s)
+	      add:             OK (5.48s)
+	    move (ssh remote): FAIL (958561.16s)
+	      ./Test/Framework.hs:398:
+	      bad content in location log for foo key SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77 uuid UUID "c129397d-8209-40ea-8347-16a8c3fe69de"
+	      expected: True
+	       but got: False
+
+That seems like it must come from here in the test suite:
+
+        git_annex "move" ["--to", "origin", annexedfile] "move --to of file"
+        inmainrepo $ annexed_present annexedfile
+
+So it seems that the content was moved back to origin successfully
+(`annexed_present` checks that the object file is present before checking
+the location log), but that the location log didn't get updated. Need
+to check if that update would have been done by the `p2pstdio` process
+or the `move` process.
+
+Why would a SIGCONT have unstuck it I wonder?
+
+I have re-ran the command to see if the bug replicates..
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_3_2bb944b19503dcf90fdf55e5098a2c02._comment b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_3_2bb944b19503dcf90fdf55e5098a2c02._comment
new file mode 100644
index 0000000000..ed0234223a
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_3_2bb944b19503dcf90fdf55e5098a2c02._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2022-11-29T22:25:42Z"
+ content="""
+> I have re-ran the command to see if the bug replicates..
+
+note: it was considerable amount of time (days?) for it to take there ;)  I made a copy `test_fs_testonly.py` where I removed all other \"benchmarks\" prior running `annex test` -- might get there faster if works so feel free to interrupt and rerun that one.  That code is old (circa 2014 ;)) , and I should do some face lift but haven't had a chance yet :-/
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_4_a8847e219a57f3cf41330745e6a67b10._comment b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_4_a8847e219a57f3cf41330745e6a67b10._comment
new file mode 100644
index 0000000000..c7e6f15e3f
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_4_a8847e219a57f3cf41330745e6a67b10._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-12-05T17:48:52Z"
+ content="""
+The rerun did not get stuck. So it's not something directly the fault 
+of the script running `git-annex test`, I think.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_5_4e7be0dd1eb70af4790e2bcba7bb6ea1._comment b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_5_4e7be0dd1eb70af4790e2bcba7bb6ea1._comment
new file mode 100644
index 0000000000..257a4a3453
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_5_4e7be0dd1eb70af4790e2bcba7bb6ea1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2022-12-05T18:08:02Z"
+ content="""
+what kind of a \"fault\" could it be? ;)
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_6_d12ddfb48706454eba1bd552a681e5ba._comment b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_6_d12ddfb48706454eba1bd552a681e5ba._comment
new file mode 100644
index 0000000000..030f6816ee
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_6_d12ddfb48706454eba1bd552a681e5ba._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-12-07T16:36:44Z"
+ content="""
+Well, a specific filesystem or mount option that the script sets up, for
+example. 
+
+Or if it's something of that kind, it's also intermittent.
+
+This will limit the test suite to only running the that test:
+
+	git-annex test --pattern '/move (ssh remote)/ && /Repo Tests v8 unlocked/'
+
+I have that repeating locally in a loop, in case it's just something that
+happens every 1000 test runs or something like that.
+
+(I've patched git-annex to speed up the above command 400%.)
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_7_d897d97bfe8f13431f8c5d92e61bbd3d._comment b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_7_d897d97bfe8f13431f8c5d92e61bbd3d._comment
new file mode 100644
index 0000000000..f36245700e
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_7_d897d97bfe8f13431f8c5d92e61bbd3d._comment
@@ -0,0 +1,114 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-12-07T18:19:19Z"
+ content="""
+Very good news! Reproduced the hang on kite, after 500 iterations of test
+suite.
+
+	All 0 tests passed (0.01s)
+	Tests
+	  Repo Tests v10 adjusted unlocked branch
+	    Init Tests
+	      init:            OK (0.44s)
+	      add:             OK (0.81s)
+	    move (ssh remote):
+
+strace of the `git-annex move` process:
+
+	joey@kite:~/tmp>strace  -p 1710605 -f
+	strace: Process 1710605 attached with 6 threads
+	[pid 1710671] futex(0x7fab6801c398, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
+	[pid 1710614] futex(0x5a21968, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
+	[pid 1710613] restart_syscall(<... resuming interrupted read ...> <unfinished ...>
+	[pid 1710611] futex(0x4868648, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
+	[pid 1710610] futex(0x4868648, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
+	[pid 1710605] futex(0x5a2164c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
+	[pid 1710611] <... futex resumed>)      = 0
+	[pid 1710610] <... futex resumed>)      = -1 EAGAIN (Resource temporarily unavailable)
+	[pid 1710611] epoll_wait(3,  <unfinished ...>
+	[pid 1710610] futex(0x48685e0, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
+	[pid 1710611] <... epoll_wait resumed>[], 64, 0) = 0
+	[pid 1710610] <... futex resumed>)      = 0
+	[pid 1710611] epoll_wait(3,  <unfinished ...>
+	[pid 1710610] read(10,  <unfinished ...>
+	[pid 1710611] <... epoll_wait resumed>[], 64, 0) = 0
+	[pid 1710610] <... read resumed>"\344\16\0\0\0\0\0\0", 8) = 8
+	[pid 1710611] epoll_wait(3,  <unfinished ...>
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] write(9, "\377\0\0\0\0\0\0\0", 8 <unfinished ...>
+	[pid 1710613] <... restart_syscall resumed>) = 1
+	[pid 1710610] <... write resumed>)      = 8
+	[pid 1710613] read(9,  <unfinished ...>
+	[pid 1710610] read(10,  <unfinished ...>
+	[pid 1710613] <... read resumed>"\377\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710613] futex(0x5a21968, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
+	[pid 1710614] <... futex resumed>)      = 0
+	[pid 1710613] <... futex resumed>)      = 1
+	[pid 1710613] poll([{fd=7, events=POLLIN}, {fd=9, events=POLLIN}], 2, -1 <unfinished ...>
+	[pid 1710614] futex(0x5a21970, FUTEX_WAKE_PRIVATE, 1) = 0
+	[pid 1710614] sched_getaffinity(0, 128, [0, 1]) = 8
+	[pid 1710614] rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM CONT TSTP], [], 8) = 0
+	[pid 1710610] <... read resumed>"\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] read(10,  <unfinished ...>
+	[pid 1710614] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
+	[pid 1710614] futex(0x5a2196c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
+	[pid 1710610] <... read resumed>"\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710610] futex(0x486864c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY
+
+Strace of the child:
+
+	joey@kite:~/tmp>strace  -p 1710650 -f
+	strace: Process 1710650 attached with 6 threads
+	[pid 1710658] futex(0x51ef9ec, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
+	[pid 1710655] futex(0x51ef7ec, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
+	[pid 1710653] read(10,  <unfinished ...>
+	[pid 1710650] fcntl(12, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0} <unfinished ...>
+	[pid 1710673] futex(0x7f6ec001c3e8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
+	[pid 1710657] futex(0x7f6ed0000bf8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
+	[pid 1710653] <... read resumed>"\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710653] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710653] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710653] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710653] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710653] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710653] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710653] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710653] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710653] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710653] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+	[pid 1710653] read(10, "\1\0\0\0\0\0\0\0", 8) = 8
+
+Which looks like it's blocked on taking a lock of
+`/home/joey/tmp/.t/3/main0/.git/annex/restage.lck`
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_8_b3f282a0a0d4c5f174cf6831dbf3014c._comment b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_8_b3f282a0a0d4c5f174cf6831dbf3014c._comment
new file mode 100644
index 0000000000..39b6d3c854
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_8_b3f282a0a0d4c5f174cf6831dbf3014c._comment
@@ -0,0 +1,56 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-12-07T20:55:35Z"
+ content="""
+Oh interesting, the same process has restage.lck open twice.
+
+	lrwx------ 1 joey joey 64 Dec  7 14:20 /proc/1710650/fd/12 -> /home/joey/tmp/.t/3/main0/.git/annex/restage.lck
+	lrwx------ 1 joey joey 64 Dec  7 16:53 /proc/1710650/fd/16 -> /home/joey/tmp/.t/3/main0/.git/annex/restage.lck
+
+There are other processes that have the same restage.lck open too. 
+In the process tree below, pid 1710382 does, and so does pid 1710483.
+
+	1710368 pts/8    S+     0:00 sh -c git-annex test --fakessh -- 'localhost' 'git-annex-shell '"'"'p2pstdio'"'"' '"'"'/home/joey/tmp/.t/3/main0'"'"' '"'"'6e958d13-c3cb-4c78-a360-e14308368520'"'"' --uuid 3a4d8ec8-3f33-4b80-bd67-119b1c65fc88'
+	1710369 pts/8    Sl+    0:00  \_ git-annex test --fakessh -- localhost git-annex-shell 'p2pstdio' '/home/joey/tmp/.t/3/main0' '6e958d13-c3cb-4c78-a360-e14308368520' --uuid 3a4d8ec8-3f33-4b80-bd67-119b1c65fc88
+	1710380 pts/8    S+     0:00      \_ /bin/sh -c git-annex-shell 'p2pstdio' '/home/joey/tmp/.t/3/main0' '6e958d13-c3cb-4c78-a360-e14308368520' --uuid 3a4d8ec8-3f33-4b80-bd67-119b1c65fc88
+	1710382 pts/8    Sl+    0:00          \_ git-annex-shell p2pstdio /home/joey/tmp/.t/3/main0 6e958d13-c3cb-4c78-a360-e14308368520 --uuid 3a4d8ec8-3f33-4b80-bd67-119b1c65fc88
+	1710411 pts/8    S+     0:00              \_ git --git-dir=/home/joey/tmp/.t/3/main0/.git --work-tree=/home/joey/tmp/.t/3/main0 --literal-pathspecs cat-file --batch
+	1710476 pts/8    S+     0:00              \_ git --git-dir=/home/joey/tmp/.t/3/main0/.git --work-tree=/home/joey/tmp/.t/3/main0 --literal-pathspecs -c core.safecrlf=false update-index -q --refresh -z --stdin
+	1710479 pts/8    S+     0:00                  \_ /bin/sh -c git-annex filter-process git-annex filter-process
+	1710483 pts/8    Sl+    0:21                      \_ git-annex filter-process
+	1710504 pts/8    S+     0:00                          \_ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+	1710506 pts/8    S+     0:00                          \_ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+	1710533 pts/8    S+     0:00                          \_ git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+	1710540 pts/8    S+     0:00                          \_ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+
+    64 Dec  7 17:01 /proc/1710382/fd/13 -> /home/joey/tmp/.t/3/main0/.git/annex/restage.lck
+    64 Dec  7 16:53 /proc/1710483/fd/11 -> /home/joey/tmp/.t/3/main0/.git/annex/restage.lck
+    64 Dec  7 16:53 /proc/1710483/fd/19 -> /home/joey/tmp/.t/3/main0/.git/annex/restage.lck
+
+(Strange that pid 1710368 is not a child process of the main git-annex test
+run. I'm unsure why that happens. )
+
+Stracing 1710483, it is also stuck on `fcntl F_SETLKW`.
+This looks like it may be the main deadlock, because the parent is waiting on
+`git update-index`, which is waiting on `git-annex filter-process`, which is
+stuck waiting to take the lock... which its parent is holding!
+
+(There are also several other process trees, running `git-annex test --fakessh`,
+that have gotten deparented from the main test run, and are hanging around.
+Those also have restage.lck open, though in their cases it is a since-deleted
+file.)
+
+I think this is a bug in restagePointerFiles, which uses 
+streamRestageLog while refreshIndex is running.
+The restage.log was added 2 months ago, in
+[[!commit 6a3bd283b8af53f810982e002e435c0d7c040c59]].
+
+I suspect that `git-annex filter-process` is running populatePointerFile via
+Command.Smudge.getMoveRaceRecovery, which needs to write to the restage.log.
+That would explain why the deadlock only happens sometimes, because it
+involves a race that triggers that code.
+
+Reading the whole
+restage.log into memory first would probably avoid the bug, but is not ideal.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_9_230038504d75704baacd4d3ac750ee95._comment b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_9_230038504d75704baacd4d3ac750ee95._comment
new file mode 100644
index 0000000000..e9fb22ed77
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/git_annex_test_never_exits__63__/comment_9_230038504d75704baacd4d3ac750ee95._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-12-08T18:07:47Z"
+ content="""
+I've developed a fix. Gonna re-run the reproducer long enough to be sure
+the bug is squashed..
+"""]]
diff --git a/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___.mdwn b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___.mdwn
new file mode 100644
index 0000000000..6ff3c7d1e9
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___.mdwn
@@ -0,0 +1,35 @@
+### Please describe the problem.
+
+While running tests on a local HPC with 
+
+```
+(datalad) [discovery7 tmp]$ cat /etc/redhat-release
+CentOS Linux release 7.9.2009 (Core)
+
+(datalad) [discovery7 tmp]$ gpgconf --version
+gpgconf (GnuPG) 2.0.22
+Copyright (C) 2013 Free Software Foundation, Inc.
+
+```
+
+3 tests (also failed in [another more "prolific in fails" run](https://git-annex.branchable.com/bugs/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/) failed due to
+
+```
+(datalad) [d31548v@discovery7 tmp]$ grep -B1 FAIL annex-8.20210803-g99bb214-1.log
+gpgconf: invalid option "--kill"
+FAIL (18.37s)
+--
+gpgconf: invalid option "--kill"
+FAIL (16.43s)
+--
+gpgconf: invalid option "--kill"
+FAIL (17.07s)
+```
+
+Not sure if you would like to do anything on git-annex level (skip those tests on outdated etc)...
+Meanwhile - adding `gnupg >=2.1.1 ` dependency to conda build: https://github.com/conda-forge/git-annex-feedstock/pull/126
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_1_0351276d5eeb5d8af0cf0e72c3a213fd._comment b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_1_0351276d5eeb5d8af0cf0e72c3a213fd._comment
new file mode 100644
index 0000000000..cff00179f6
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_1_0351276d5eeb5d8af0cf0e72c3a213fd._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-08-24T15:54:15Z"
+ content="""
+It already ignores nonzero exit status of that command, since
+old gpg's don't support it.
+
+So, it must not really be the `gpgconf --kill` that is causing the test
+failure.
+
+Please post the actual test failure message.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_2_a8565fb1657318092a22e8ed18ae6cbc._comment b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_2_a8565fb1657318092a22e8ed18ae6cbc._comment
new file mode 100644
index 0000000000..16b8fafcc0
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_2_a8565fb1657318092a22e8ed18ae6cbc._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="more info"
+ date="2021-08-24T16:35:26Z"
+ content="""
+full log is available [for another issue](https://git-annex.branchable.com/bugs/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/) [http://www.onerussian.com/tmp/git-annex-noretry+pidlock1-1.log](http://www.onerussian.com/tmp/git-annex-noretry+pidlock1-1.log) which shows the same error as well.
+
+FWIW
+
+```
+[d31548v@discovery7 ~]$ /usr/bin/gpgconf --kill
+gpgconf: invalid option \"--kill\"
+[d31548v@discovery7 ~]$ echo $?
+2
+```
+"""]]
diff --git a/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_3_d3a478e3f7da91ab14c9b1e24d3e07d6._comment b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_3_d3a478e3f7da91ab14c9b1e24d3e07d6._comment
new file mode 100644
index 0000000000..6d53afe663
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_3_d3a478e3f7da91ab14c9b1e24d3e07d6._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-10-12T16:42:02Z"
+ content="""
+From the log:
+
+	    crypto:                                               gpgconf: invalid option "--kill"
+	gpgconf: invalid option "--kill"
+	FAIL (22.13s)
+	      ./Test/Framework.hs:57:
+	      copy --to encrypted remote failed (transcript follows)
+	      copy foo (to foo...)
+	      gpg: can't connect to the agent: Invalid value passed to IPC
+	      gpg: problem with the agent: No agent running
+
+That is not really be a problem with gpgconf --kill, but a problem
+talking to gpg-agent.
+
+The same crypto test fails a couple more times in that log, like this:
+
+	    crypto:                                               gpgconf: invalid option "--kill"
+	gpgconf: invalid option "--kill"
+	FAIL (12.00s)
+	      ./Test/Framework.hs:57:
+	      get of file failed (transcript follows)
+	      get foo (not available) 
+	        No other repository is known to contain the file.
+	      failed
+	      get: 1 failed
+
+That is also not a problem with gpgconf --kill, it's actually due to an
+earlier test failure, unrelated to this. That earlier failure was
+the one [the other issue](https://git-annex.branchable.com/bugs/__34__357_out_of_984_tests_failed__34___on_NFS_lustre_mount/)
+was about, which has since been fixed. So we can ignore these I think,
+leaving only the one above as an unexplained failure.
+
+"gpg: can't connect to the agent: Invalid value passed to IPC" could 
+be some kind of gpg bug. I found some other instances of gpg failing that way.
+One involved using --homedir (similar to the test suite's
+use of GNUPGHOME) but on windows.
+<https://lists.gnupg.org/pipermail/gnupg-users/2016-October/056817.html>
+And here's another one, in WSL when apt runs
+gpg. <https://github.com/microsoft/WSL/issues/5125>
+
+Perhaps this is a problem with the location of the gpg agent socket in the
+filesystem that git-annex test is running in. That somehow messes up not
+creation of that socket, but later use of it. It seems that the earlier
+self-test of the test harness did not trigger the problem though, which is
+odd because it sets up a gpg private key and I'd think would use the agent
+too.
+
+In [[!commit b426ff682570d8600dc8025bbcd20aa95819a7e4]] I considered
+putting the gpg directory inside the system temp dir, which would perhaps
+avoid the problem here. I've made that change.
+
+Please test a fresh build on this system again, if you can..
+"""]]
diff --git a/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_4_9add6c8e1d5b722eaeb2e5a0fe67cd32._comment b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_4_9add6c8e1d5b722eaeb2e5a0fe67cd32._comment
new file mode 100644
index 0000000000..caf8ba46ca
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_4_9add6c8e1d5b722eaeb2e5a0fe67cd32._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-06-02T16:23:44Z"
+ content="""
+Any chance you can try to reproduce this with a recent build of git-annex?
+"""]]
diff --git a/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_5_b411b96c73bba30557c2f3aa9d6077e7._comment b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_5_b411b96c73bba30557c2f3aa9d6077e7._comment
new file mode 100644
index 0000000000..6e4588a08d
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_5_b411b96c73bba30557c2f3aa9d6077e7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-06-03T18:00:16Z"
+ content="""
+Ok, that is behaving as expected then, it ignores failure to support older
+gpgs. Going to close this.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_5_e3a79f9480a7123feb924f3c1e72ce62._comment b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_5_e3a79f9480a7123feb924f3c1e72ce62._comment
new file mode 100644
index 0000000000..9a00b40e15
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/gpgconf__58___invalid_option___34__--kill__34_____40__gpg_2.0.22__41___/comment_5_e3a79f9480a7123feb924f3c1e72ce62._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="still reports about invalid option but doesn't fail"
+ date="2022-06-03T01:36:38Z"
+ content="""
+so I should try with outdated gpgconf on some older CentOS? ..already done - we do run annex tests daily on ndoli (part of discovery) now  and apparently: tests passed, but it did have those reports
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex-ci-client-jobs/builds/2022/06[master]git
+$> tail result-ndoli-715/handle-result.yaml-154-7a381a8a-success/result-ndoli-715/git-annex-tmp.rc          
+0
+
+$> tail result-ndoli-715/handle-result.yaml-154-7a381a8a-success/result-ndoli-715/git-annex-tmp.log 
+gpgconf: invalid option \"--kill\"
+gpgconf: invalid option \"--kill\"
+gpgconf: invalid option \"--kill\"
+gpgconf: invalid option \"--kill\"
+gpgconf: invalid option \"--kill\"
++ echo 'Elapsed time: 3278 seconds'
+Elapsed time: 3278 seconds
++ cd /dartfs/rc/lab/D/DBIC/DBIC/archive/tmp
++ chmod -R +w 715
++ rm -rf 715
+```
+"""]]
diff --git a/doc/projects/repronim/bugs-done/initial_get_-J_on_exported_S3_bucket_fails.mdwn b/doc/projects/repronim/bugs-done/initial_get_-J_on_exported_S3_bucket_fails.mdwn
new file mode 100644
index 0000000000..59756e891f
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/initial_get_-J_on_exported_S3_bucket_fails.mdwn
@@ -0,0 +1,52 @@
+I was excited to give a shot to https://github.com/OpenNeuroDatasets/ds001544/ which has proper publicurl set etc... unfortunately there is something forbidding immediate parallel get (in below example `-J8` but it is the same with `-J2`).  It works on the 2nd try, or if not using -J. Error message states "unknown export location":
+
+[[!format sh """
+$> git annex version | head -n 1; git clone https://github.com/OpenNeuroDatasets/ds001544/ ; cd ds001544; git annex enableremote s3-PUBLIC; git annex get -J8 . 2>&1 | head -n 20; echo "2nd run"; git annex get -J8 .
+git-annex version: 6.20181011+git7-g373c2abc2-1~ndall+1
+Cloning into 'ds001544'...
+remote: Enumerating objects: 866, done.
+remote: Counting objects: 100% (866/866), done.
+remote: Compressing objects: 100% (483/483), done.
+remote: Total 866 (delta 144), reused 863 (delta 141), pack-reused 0
+Receiving objects: 100% (866/866), 75.07 KiB | 4.69 MiB/s, done.
+Resolving deltas: 100% (144/144), done.
+
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+
+  Remote origin not usable by git-annex; setting annex-ignore
+enableremote s3-PUBLIC ok
+(recording state in git...)
+get code/convert_sub01_ses01.R (from s3-PUBLIC...) 
+  unknown export location
+
+  Unable to access these remotes: s3-PUBLIC
+
+  Try making some of these repositories available:
+  	1c66b8f9-34c7-42d1-8e9f-d7bc1982311a -- root@460f24a504cc:/datalad/ds001544
+   	837e28c7-9e4a-4792-b1b1-aa69d3430a42 -- [s3-PUBLIC]
+   	a7294efc-f620-445d-8e9d-803b3ec748ef -- s3-PRIVATE
+
+  (Note that these git remotes have annex-ignore set: origin)
+failed
+get sub-01/ses-01/fmap/sub-01_ses-01_acq-cf0PA_run-03_epi.nii.gz (from s3-PUBLIC...) 
+  unknown export location
+
+  Unable to access these remotes: s3-PUBLIC
+
+  Try making some of these repositories available:
+  	1c66b8f9-34c7-42d1-8e9f-d7bc1982311a -- root@460f24a504cc:/datalad/ds001544
+   	837e28c7-9e4a-4792-b1b1-aa69d3430a42 -- [s3-PUBLIC]
+2nd run
+get code/convert_sub01_ses02.R (from s3-PUBLIC...) (checksum...) ok
+get code/convert_sub01_ses01.R (from s3-PUBLIC...) (checksum...) ok
+get sub-01/ses-01/fmap/sub-01_ses-01_acq-cf1PA_run-02_epi.nii.gz (from s3-PUBLIC...) (checksum...) ok
+get sub-01/ses-01/func/sub-01_ses-01_task-Stroop_acq-cf0AP_run-03_physio.tsv.gz (from s3-PUBLIC...) (checksum...) ok
+...
+"""]]
+
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/initial_get_-J_on_exported_S3_bucket_fails/comment_1_005874771ab14efb94c4a739da31b523._comment b/doc/projects/repronim/bugs-done/initial_get_-J_on_exported_S3_bucket_fails/comment_1_005874771ab14efb94c4a739da31b523._comment
new file mode 100644
index 0000000000..98b3ec2f9a
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/initial_get_-J_on_exported_S3_bucket_fails/comment_1_005874771ab14efb94c4a739da31b523._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-22T16:37:06Z"
+ content="""
+Seems that the problem is that updateExportTreeFromLog gets started by the
+first thread, and once it's started it won't be run again. Meanwhile,
+other threads try to access the export database that populates.
+
+So, just needs some inter-thread locking..
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction.mdwn b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction.mdwn
new file mode 100644
index 0000000000..9bf10074d3
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction.mdwn
@@ -0,0 +1,63 @@
+### Please describe the problem.
+
+Originally reported (so more details could be found there) in [datalad issue #2988].
+
+While trying to `annex get` on local cluster, over ssh without a ssh-agent, I was prompted for password multiple times, although previous version didn't do it:
+
+[[!format sh """
+[yhalchen@discovery7 QA]$ git annex version | head -n1 ; git annex get -J2 sub-qa/
+git-annex version: 6.20180926-gc906aaf
+get sub-qa/ses-20161128/dwi/sub-qa_ses-20161128_acq-DTIX30Xp2Xs4_dwi.nii.gz get sub-qa/ses-20161128/dwi/sub-qa_ses-20161128_acq-DTIX30Xp2_dwi.nii.gz (from origin...) 
+(from origin...) 
+yoh@falkor.datalad.org's password: yoh@falkor.datalad.org's password: 
+"""]]
+
+
+and when I try an "imputated" from NeuroDebian .deb package recent build of git-annex then I am observing
+
+[[!format sh """
+[yhalchen@discovery7 QA]$ export PATH=/ihome/yhalchen/7.20181105+git22-g4c7236c58/usr/lib/git-annex.linux:$PATH
+[yhalchen@discovery7 QA]$ git annex version | head -n1 ; git annex get -J2 sub-qa/
+git-annex version: 7.20181105+git22-g4c7236c58-1~ndall+1
+get sub-qa/ses-20161128/dwi/sub-qa_ses-20161128_acq-DTIX30Xp2Xs4_dwi.nii.gz get sub-qa/ses-20161128/dwi/sub-qa_ses-20161128_acq-DTIX30Xp2_dwi.nii.gz (transfer already in progress, or unable to take transfer lock) 
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+  	6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA
+   	7d9ed214-3e5f-4cc8-ac88-f397145b2d4c -- yoh@falkor:/srv/datasets.datalad.org/www/dbic/QA [origin]
+   	ba8f2cea-f229-422c-82be-6580e5e07ed5 -- yoh@smaug:/mnt/datasets/datalad/crawl/dbic/QA
+failed
+get sub-qa/ses-20161128/func/sub-qa_ses-20161128_task-rest_acq-p2Xs4X35mm_bold.nii.gz (from origin...) 
+(from origin...) 
+
+
+  thread blocked indefinitely in an MVar operation
+  thread blocked indefinitely in an STM transaction
+
+  Unable to access these remotes: origin
+
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+  	6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA
+   	7d9ed214-3e5f-4cc8-ac88-f397145b2d4c -- yoh@falkor:/srv/datasets.datalad.org/www/dbic/QA [origin]
+   	ba8f2cea-f229-422c-82be-6580e5e07ed5 -- yoh@smaug:/mnt/datasets/datalad/crawl/dbic/QA
+failed
+
+  Try making some of these repositories available:
+  	6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA
+   	7d9ed214-3e5f-4cc8-ac88-f397145b2d4c -- yoh@falkor:/srv/datasets.datalad.org/www/dbic/QA [origin]
+   	ba8f2cea-f229-422c-82be-6580e5e07ed5 -- yoh@smaug:/mnt/datasets/datalad/crawl/dbic/QA
+failed
+git-annex: thread blocked indefinitely in an STM transaction
+"""]]
+so smells like may be recent fixes caused some other locking problems
+
+This is on an NFS mounted partition, but remains the same when run under `/tmp` 
+
+Running a significantly more outdated version I found laying around (6.20170815+gitg22da64d0f-1~ndall+1) shows a single password prompt
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_10_d2a5b1eb72cf0abbd0143339ff81a92a._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_10_d2a5b1eb72cf0abbd0143339ff81a92a._comment
new file mode 100644
index 0000000000..b219f4b1a2
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_10_d2a5b1eb72cf0abbd0143339ff81a92a._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2018-11-13T17:50:48Z"
+ content="""
+Use the script command to get a typescript.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_11_5ee016343b74fac9d6235db88744734a._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_11_5ee016343b74fac9d6235db88744734a._comment
new file mode 100644
index 0000000000..dd13146b6c
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_11_5ee016343b74fac9d6235db88744734a._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2018-11-13T18:04:15Z"
+ content="""
+Since you can reproduce it, why don't you bisect it?
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_12_c640da31be6bcd50dec6eabb2e792e07._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_12_c640da31be6bcd50dec6eabb2e792e07._comment
new file mode 100644
index 0000000000..dbd77949fd
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_12_c640da31be6bcd50dec6eabb2e792e07._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 12"
+ date="2018-11-13T20:02:18Z"
+ content="""
+bisection would require building, building would require build environment (which is not there), etc...  and need to get to grant writing/reporting/etc...
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_13_4bb69f0bc73b5d368cc9278b88223a5e._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_13_4bb69f0bc73b5d368cc9278b88223a5e._comment
new file mode 100644
index 0000000000..578e79b400
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_13_4bb69f0bc73b5d368cc9278b88223a5e._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2018-11-15T17:06:39Z"
+ content="""
+I don't think this bug will be able to be tracked down without
+rebuilding git-annex one way or another.
+
+I could use the technique in
+<https://www.fpcomplete.com/blog/2018/05/pinpointing-deadlocks-in-haskell>
+to instrument every possible place in git-annex that could deadlock.
+This would be a lot of work, probably hundreds of lines of code changes.
+
+It seems much easier to either find a way to reproduce the problem
+outside of this one machine with the problem, or bisect it.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_14_2d8cf0d8b020941d143abd424729c6bc._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_14_2d8cf0d8b020941d143abd424729c6bc._comment
new file mode 100644
index 0000000000..d142fc459d
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_14_2d8cf0d8b020941d143abd424729c6bc._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 14"
+ date="2018-11-15T18:06:10Z"
+ content="""
+about to start bisection for the locking issue. Relevant PR on datalad: https://github.com/datalad/datalad/pull/2995  to get a helper script and Singularity environment to build
+
+As for double password prompt - should I bisect too?  that one seems to be not that easy since if `annex get` is invoked within script, typescript records nothing:
+[[!format sh \"\"\"
+[yhalchen@discovery7 ~]$ cat bisect-git-annex-doublepasswd.sh
+#!/bin/bash
+set -eu
+
+err=\"thread blocked indefinitely\"
+
+cd ~/QA
+# script doesn't work in  a script since probably no tty
+timeout 10 script -f -c 'git annex get -J2 sub-*' || :
+test 1 -eq `sed -e 's, ,\n,g' typescript | grep -c 'password:' `
+[yhalchen@discovery7 ~]$ bash -x bisect-git-annex-doublepasswd.sh
++ set -eu
++ err='thread blocked indefinitely'
++ cd /ihome/yhalchen/QA
++ timeout 10 script -f -c 'git annex get -J2 sub-*'
+Script started, file is typescript
++ :
+++ sed -e 's, ,\n,g' typescript
+++ grep -c password:
++ test 1 -eq 0
+\"\"\"]]
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_14_7cc13b150c19a3c08f2b9cdeb880cfe9._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_14_7cc13b150c19a3c08f2b9cdeb880cfe9._comment
new file mode 100644
index 0000000000..f32be02e6a
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_14_7cc13b150c19a3c08f2b9cdeb880cfe9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2018-11-15T18:28:58Z"
+ content="""
+[[!commit 872af2b2f1049e4eecf274ac70caf99a367f3818]] allows ruling out
+a concurrent-output bug. If git-annex with that commit is run with --quiet
+and still exhibits the problem, it shouldn't involve concurrent-output at
+all.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_16_9d1f902cc0e029b483115c3c0de5d113._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_16_9d1f902cc0e029b483115c3c0de5d113._comment
new file mode 100644
index 0000000000..1d34d70aa3
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_16_9d1f902cc0e029b483115c3c0de5d113._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 16"
+ date="2018-11-15T20:43:27Z"
+ content="""
+woohoo `git bisect run ~/bisect-git-annex ~/git-annex-dev.img ~/bisect-git-annex-lock.sh` (on `git bisect start HEAD 6.20180926` with HEAD being 05bfce7ca8e67612c66e2cdb3c7c0c26fd8c5243 finished with ground breaking discovery
+
+[[!format sh \"\"\"
+2c0300c8b9cd97b7d2a86e48e19283be8c9ef278 is the first bad commit
+commit 2c0300c8b9cd97b7d2a86e48e19283be8c9ef278
+Author: Ilya_Shlyakhter <Ilya_Shlyakhter@web>
+Date:   Wed Sep 26 17:16:13 2018 +0000
+
+    Added a comment: question about special remote protocol
+
+:040000 040000 6e8d46c0b393e4b96ff53f28224154939fbe4883 e9db3cc46114d98fe77bf0392d8a90c314c9326e M      doc
+bisect run success
+\"\"\"]]
+so it is all destructive Ilya's comments! ;)
+
+That is a commit right after the 6.20180926 which I chose as \"good\" since the good was the 6.20180926-gc906aaf (installed via conda  build pl5.22.2.1_0).  
+So may be the problem is not in git annex per se but in its build-depends, which changed in buster (I've been building standalones with buster for a while).
+I will try to do manual comparison across a number of builds from datalad.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_17_0e4efb1686564f4d8e834b1e0843d397._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_17_0e4efb1686564f4d8e834b1e0843d397._comment
new file mode 100644
index 0000000000..71e61cb46a
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_17_0e4efb1686564f4d8e834b1e0843d397._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 17"
+ date="2018-11-16T22:12:58Z"
+ content="""
+ok, not sure yet if it is git-annex change or ghc change or both here is the point where things changed radically:
+
+going from 6.20180519+gitgf6f199be3 build which used ghc 8.0.1-17+b1 and where we had a nice single ssh password prompt:
+
+[[!format sh \"\"\"
+[yhalchen@discovery7 QA]$ PATH=$HOME/6.20180519+gitgf6f199be3-1~ndall+1/usr/lib/git-annex.linux:$PATH git annex get -J2 sub-*
+get sub-amit/ses-20180508/anat/sub-amit_ses-20180508_acq-MPRAGE_T1w.nii.gz get sub-amit/ses-20180508/dwi/sub-amit_ses-20180508_acq-DTIX30Xp2Xs4_dwi.nii.gz (from origin...) 
+(from origin...) 
+yoh@falkor.datalad.org's password: 
+
+\"\"\"]]
+
+to the next build I have 6.20180521+gitg0e3bebd71 which used ghc 8.0.2-11 and with which locking madness starts to kick in:
+
+[[!format sh \"\"\"
+[yhalchen@discovery7 QA]$ PATH=$HOME/6.20180521+gitg0e3bebd71-1~ndall+1/usr/lib/git-annex.linux:$PATH git annex get -J2 sub-*
+get sub-amit/ses-20180508/anat/sub-amit_ses-20180508_acq-MPRAGE_T1w.nii.gz get sub-amit/ses-20180508/dwi/sub-amit_ses-20180508_acq-DTIX30Xp2Xs4_dwi.nii.gz (transfer already in progress, or unable to take transfer lock) 
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+  	6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA
+   	7d9ed214-3e5f-4cc8-ac88-f397145b2d4c -- yoh@falkor:/srv/datasets.datalad.org/www/dbic/QA [origin]
+   	ba8f2cea-f229-422c-82be-6580e5e07ed5 -- yoh@smaug:/mnt/datasets/datalad/crawl/dbic/QA
+failed
+get sub-amit/ses-20180508/func/sub-amit_ses-20180508_task-rest_acq-p2_bold.nii.gz (from origin...) 
+(from origin...) 
+
+
+  thread blocked indefinitely in an STM transaction
+  thread blocked indefinitely in an MVar operation
+
+  Unable to access these remotes: origin
+
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+  	6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA
+   	7d9ed214-3e5f-4cc8-ac88-f397145b2d4c -- yoh@falkor:/srv/datasets.datalad.org/www/dbic/QA [origin]
+   	ba8f2cea-f229-422c-82be-6580e5e07ed5 -- yoh@smaug:/mnt/datasets/datalad/crawl/dbic/QA
+failed
+
+  Try making some of these repositories available:
+  	6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA
+   	7d9ed214-3e5f-4cc8-ac88-f397145b2d4c -- yoh@falkor:/srv/datasets.datalad.org/www/dbic/QA [origin]
+   	ba8f2cea-f229-422c-82be-6580e5e07ed5 -- yoh@smaug:/mnt/datasets/datalad/crawl/dbic/QA
+failed
+git-annex: thread blocked indefinitely in an STM transaction
+
+\"\"\"]]
+
+I hope that would give enough clues, Joey?
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_18_01371e8b9d56d4470af5277456763d12._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_18_01371e8b9d56d4470af5277456763d12._comment
new file mode 100644
index 0000000000..28978d899b
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_18_01371e8b9d56d4470af5277456763d12._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 18"
+ date="2018-11-19T04:08:37Z"
+ content="""
+FWIW 1, it was a switch from ghc 8.0.1-17+b1 because it was when (I guess) I switched from Debian stable (stretch) to testing (buster) build environment since build-dependencies were no longer satisfiable!
+
+FWIW 2, I have now tested the build in debian unstable with ghc 8.4.3+dfsg1-4 -- the same issue with locks
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_19_a171911a9bb7a278e673e4b6905c971d._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_19_a171911a9bb7a278e673e4b6905c971d._comment
new file mode 100644
index 0000000000..52b6ad6972
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_19_a171911a9bb7a278e673e4b6905c971d._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="dependencies information"
+ date="2018-11-19T15:54:14Z"
+ content="""
+not sure how I was blind that `git annex version` outputs dependencies information, so here is too nearby versions where 
+
+this one is good (no lock issues, but double password prompt):
+[[!format sh \"\"\"
+*[yhalchen@discovery7 QA]$ git annex version      
+git-annex version: 6.20180926-gc906aaf
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+local repository version: 5
+\"\"\"]]
+
+and here is a bad one (locks issue)
+[[!format sh \"\"\"
+*[yhalchen@discovery7 QA]$ PATH=$HOME/6.20180926+git93-gdc47dfe/usr/lib/git-annex.linux:$PATH git annex version      
+git-annex version: 6.20180926+git93-gdc47dfe90-1~ndall+1
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.19 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.2.2 http-client-0.5.12 persistent-sqlite-2.8.1.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+local repository version: 5
+\"\"\"]]
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_1_ffcede72f600ecc98b906f0d9b6d6d0a._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_1_ffcede72f600ecc98b906f0d9b6d6d0a._comment
new file mode 100644
index 0000000000..8c91e9b7ed
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_1_ffcede72f600ecc98b906f0d9b6d6d0a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-11-11T21:35:26Z"
+ content="""
+This looks like a know issue: [get -J cannot be used with password-based authentication](http://git-annex.branchable.com/bugs/get_-J_cannot_be_used_with_password-based_authentication/).
+
+Try without the -J2:
+
+    git annex version | head -n1 ; git annex get sub-qa/
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_20_2b76e74756e684a09387396fa2177d57._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_20_2b76e74756e684a09387396fa2177d57._comment
new file mode 100644
index 0000000000..071a57ff7c
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_20_2b76e74756e684a09387396fa2177d57._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 20"""
+ date="2018-11-19T17:04:18Z"
+ content="""
+I don't see anything in ghc 8.0.2's release notes that points to a breaking
+change to STM/MVar handling. There were a couple of changes in that version
+that involve concurrency and MVars though, that could somehow have led to
+the problem.
+
+Parallel programs should be significantly more reliable on platforms with
+weak memory consistency guarantees
+<https://ghc.haskell.org/trac/ghc/ticket/12469>
+
+Scheduling bug with forkOS + MVar
+<https://ghc.haskell.org/trac/ghc/ticket/12419>
+
+One thing that seems worth trying re the second of those
+is to edit CmdLine/Action.hs and delete the setNumCapabilities line:
+
+	--- a/CmdLine/Action.hs
+	+++ b/CmdLine/Action.hs
+	@@ -178,8 +178,6 @@ allowConcurrentOutput a = do
+	   where
+	 	goconcurrent n = do
+ 			c <- liftIO getNumCapabilities
+	-		when (n > c) $
+	-			liftIO $ setNumCapabilities n
+	 		withMessageState $ \s -> case outputType s of
+	 			NormalOutput -> ifM (liftIO concurrentOutputSupported)
+	 				( Regions.displayConsoleRegions $
+
+A compiler bug is looking not entirely unlikely..
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_21_8f7fd9bc58d8c2eff32f5fa200b57119._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_21_8f7fd9bc58d8c2eff32f5fa200b57119._comment
new file mode 100644
index 0000000000..9923c36b1c
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_21_8f7fd9bc58d8c2eff32f5fa200b57119._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 21"""
+ date="2018-11-19T18:46:32Z"
+ content="""
+I've added a DebugLocks build flag to try to track down the source
+of the deadlock. It's not enabled by default, so you'll need to eg modify
+the Makefile to set it:
+
+	cabal configure -fDebugLocks
+
+Calls to `debugLocks` are scattered around in a several of the places I
+suspect may be involved, around ssh prompting, transfer locks, and
+general lock files. If one of them is, it will display line number
+information when the deadlock happens.
+
+It will probably take several iterations of adding more calls to
+`debugLocks` to narrow in on the code that is involved in the
+deadlock.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_22_0827ffb4beb55f6553a40c722bc2ec12._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_22_0827ffb4beb55f6553a40c722bc2ec12._comment
new file mode 100644
index 0000000000..dff48f888c
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_22_0827ffb4beb55f6553a40c722bc2ec12._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 22"
+ date="2018-11-19T19:25:35Z"
+ content="""
+thanks! ... FYI: I am \"afraid\" that either I am completely lost my grip on things or may be bug was fixed somewhere in the recent days (within `05bfce7ca..900bf3436`)!  bisecting now which change possibly fixed it
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_23_c9102fdb9d99d2c19585e74b0dc0dff7._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_23_c9102fdb9d99d2c19585e74b0dc0dff7._comment
new file mode 100644
index 0000000000..64db6a7463
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_23_c9102fdb9d99d2c19585e74b0dc0dff7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 23"
+ date="2018-11-19T20:26:32Z"
+ content="""
+I guess I should have more paid attention to your [comment](http://git-annex.branchable.com/bugs/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/#comment-859cc85018f5871fcd70a1169f7095db) about a fix for concurrent outputs! It was the 872af2b2f1049e4eecf274ac70caf99a367f3818 which fixed it for my trials.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_23_d69e0931e520391551eb4c37eb2f809d._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_23_d69e0931e520391551eb4c37eb2f809d._comment
new file mode 100644
index 0000000000..e4f10301df
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_23_d69e0931e520391551eb4c37eb2f809d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2018-11-19T20:48:23Z"
+ content="""
+Did that fix the double password prompts too?
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_25_115c584098501e16292dc6c776141074._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_25_115c584098501e16292dc6c776141074._comment
new file mode 100644
index 0000000000..3be0b61c81
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_25_115c584098501e16292dc6c776141074._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 25"""
+ date="2018-11-19T20:52:20Z"
+ content="""
+My comment in the concurrent-output commit was that I didn't think git-annex
+could be affected, since it can only call waitDisplayChange once at a
+time. That analysis still looks right to me; Messages.prompt takes the
+promptLock before calling it.
+
+So I want to make very sure that fix did fix it, and it's not masked by
+some other change to the build environment, or by the problem being more
+intermittent than you thought it was. It would be good if you can
+revert the concurrent-output change, reproduce, re-introduce the change,
+and verify it fixes it.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_25_1adec4fa4c8af5409d2f5dc7adcaecf4._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_25_1adec4fa4c8af5409d2f5dc7adcaecf4._comment
new file mode 100644
index 0000000000..63b84c46b5
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_25_1adec4fa4c8af5409d2f5dc7adcaecf4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 25"
+ date="2018-11-19T20:55:27Z"
+ content="""
+reconfirming that as of current master 7.20181105-154-gc2e298e96 I do not see locking issue appearing and also I observe only a single password prompt! whoohoo, thanks Joey ;-)
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_27_e8b00ab555e94cf8826493ca6ce2d082._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_27_e8b00ab555e94cf8826493ca6ce2d082._comment
new file mode 100644
index 0000000000..71df9d0e1e
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_27_e8b00ab555e94cf8826493ca6ce2d082._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 27"""
+ date="2018-11-19T21:02:24Z"
+ content="""
+Also it would be good to build git-annex with the DebugLocks build flag
+described above, and the unfixed concurrent-output, and verify that
+the debug info when it crashes shows it crashed in Message.hs or
+concurrent-output.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_28_2fb1c54c41b31698909594106cb08cd4._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_28_2fb1c54c41b31698909594106cb08cd4._comment
new file mode 100644
index 0000000000..b337b3ea2e
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_28_2fb1c54c41b31698909594106cb08cd4._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 28"
+ date="2018-11-19T21:10:47Z"
+ content="""
+FWIW, regarding 
+
+> So I want to make very sure that fix did fix it, and it's not masked by some other change to the build environment, or by the problem being more intermittent than you thought it was. 
+
+`git bisect start 900bf3436 05bfce7ca^`
+
+`git bisect run bash -c '! ../bisect-git-annex ../git-annex-dev.img ../bisect-git-annex-lock.sh'`
+
+so build environment (singularity image) remained the same, the bisect script was
+
+[[!format sh \"\"\"
+#!/bin/bash
+set -eu
+
+err=\"thread blocked indefinitely\"
+
+cd ~/QA
+# script doesn't work in  a script since probably no tty
+#timeout 10 script -f -c 'git annex get -J2 sub-*' || :
+#test 1 -eq `sed -e 's, ,\n,g' typescript | grep -c 'password:' `
+timeout 5 git annex get -J2 sub-* 2>&1 | tee annex-get-log.txt
+if grep -q \"$err\" annex-get-log.txt; then
+	echo \"E: $err\"
+	exit 1
+fi
+\"\"\"]]
+
+and it did point to that commit... I can rerun it again for the geeks of it whenever I would have another guaranteed hour online (processes time out on that host, so can't reliably run screen)
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_29_750dbe3e118b1b6b8d0cca7d26ea1366._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_29_750dbe3e118b1b6b8d0cca7d26ea1366._comment
new file mode 100644
index 0000000000..99d7dabc0b
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_29_750dbe3e118b1b6b8d0cca7d26ea1366._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 29"
+ date="2018-11-19T21:14:10Z"
+ content="""
+FWIW, [http://www.onerussian.com/tmp/git-annex-test-discovery7-7.20181105-154-gc2e298e96.log](http://www.onerussian.com/tmp/git-annex-test-discovery7-7.20181105-154-gc2e298e96.log) contains detailed `git annex test` output on that box/that version with `85 out of 293 tests failed`
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_2_50c0db38a664adbb0c5a2290326195a6._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_2_50c0db38a664adbb0c5a2290326195a6._comment
new file mode 100644
index 0000000000..9ea40a942a
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_2_50c0db38a664adbb0c5a2290326195a6._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-11-12T15:22:12Z"
+ content="""
+@andrew, the bug you linked to is only about multiple password prompting
+when using `GIT_SSH`, which I don't think is in use here.
+
+Anyway that bug did not involve MVar/STM deadlocks, so this is not a
+duplicate.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_30_cd1362901ff08323ca134fc8de914318._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_30_cd1362901ff08323ca134fc8de914318._comment
new file mode 100644
index 0000000000..5f6b7115e3
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_30_cd1362901ff08323ca134fc8de914318._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 30"""
+ date="2018-11-19T21:29:38Z"
+ content="""
+Bisecting git-annex couldn't isolate the problem to any commit if the bug
+was fixed in concurrent-output. What commit did bisect point to?
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_31_e2cc841198c91709980cc2b2a8297925._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_31_e2cc841198c91709980cc2b2a8297925._comment
new file mode 100644
index 0000000000..e621204688
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_31_e2cc841198c91709980cc2b2a8297925._comment
@@ -0,0 +1,65 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="reconfirming with new build option"
+ date="2018-11-19T21:33:34Z"
+ content="""
+> Also it would be good to build git-annex with the DebugLocks build flag described above, and the unfixed concurrent-output, and verify that the debug info when it crashes shows it crashed in Message.hs or concurrent-output.
+
+Ok, did
+
+[[!format patch \"\"\"
+
+$ git co -b debug-locks 872af2b2f1049e4eecf274ac70caf99a367f3818^
+$ git cherry-pick 9127fe4821a9d4aeba18c8d240c9df71b54c1353
+$ # vim Makefile to add that flag
+$ git diff
+diff --git a/Makefile b/Makefile
+index 149309f59..2d87b34e0 100644
+--- a/Makefile
++++ b/Makefile
+@@ -21,7 +21,7 @@ build: $(all)
+ tmp/configure-stamp: Build/TestConfig.hs Build/Configure.hs
+        if [ \"$(BUILDER)\" = ./Setup ]; then ghc --make Setup; fi
+        if [ \"$(BUILDER)\" != stack ]; then \
+-               $(BUILDER) configure --ghc-options=\"$(shell Build/collect-ghc-options.sh)\"; \
++               $(BUILDER) configure --ghc-options=\"$(shell Build/collect-ghc-options.sh)\" -fDebugLocks; \
+        else \
+                $(BUILDER) setup; \
+        fi
+$ ../bisect-git-annex ../git-annex-dev.img ../bisect-git-annex-lock.sh
+...
+get sub-amit/ses-20180508/anat/sub-amit_ses-20180508_acq-MPRAGE_T1w.nii.gz get sub-amit/ses-20180508/dwi/sub-amit_ses-20180508_acq-DTIX30Xp2Xs4_dwi.nii.gz (from origin...) 
+(from origin...) 
+MVar deadlock detected CallStack (from HasCallStack):
+  debugLocks, called at Messages.hs:265:12 in main:Messages
+STM deadlock detected CallStack (from HasCallStack):
+  debugLocks, called at Messages.hs:265:12 in main:Messages
+MVar deadlock detected CallStack (from HasCallStack):
+  debugLocks, called at ./Annex/Ssh.hs:201:37 in main:Annex.Ssh
+STM deadlock detected CallStack (from HasCallStack):
+  debugLocks, called at ./Annex/Ssh.hs:201:37 in main:Annex.Ssh
+
+
+  thread blocked indefinitely in an MVar operation
+  thread blocked indefinitely in an STM transaction
+
+  Unable to access these remotes: origin
+
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+
+  Try making some of these repositories available:
+  	6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA
+   	7d9ed214-3e5f-4cc8-ac88-f397145b2d4c -- yoh@falkor:/srv/datasets.datalad.org/www/dbic/QA [origin]
+   	ba8f2cea-f229-422c-82be-6580e5e07ed5 -- yoh@smaug:/mnt/datasets/datalad/crawl/dbic/QA
+  	6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA
+failed
+   	7d9ed214-3e5f-4cc8-ac88-f397145b2d4c -- yoh@falkor:/srv/datasets.datalad.org/www/dbic/QA [origin]
+   	ba8f2cea-f229-422c-82be-6580e5e07ed5 -- yoh@smaug:/mnt/datasets/datalad/crawl/dbic/QA
+failed
+git-annex: thread blocked indefinitely in an STM transaction
+E: thread blocked indefinitely
+\"\"\"]]
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_32_eff60d2ee47af65f18dede31cc283adb._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_32_eff60d2ee47af65f18dede31cc283adb._comment
new file mode 100644
index 0000000000..b55f87700b
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_32_eff60d2ee47af65f18dede31cc283adb._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 32"""
+ date="2018-11-19T21:38:29Z"
+ content="""
+Ok so we know for sure it's crashing in Message.prompt, good.
+
+I see you mean that my commit to git-annex that avoids using
+concurrent-output in some circumstances "fixed" it. I'm not sure how your
+bisection environment avoids those circumstances; it does not seem to be
+passing --quiet or --json to git-annex. Perhaps piping the git-annex output
+causes it to decide it's not on a tty and so avoid using concurrent-output.
+Perhaps it's a locale setting. Doesn't really matter..
+
+Except, it seems we have still not verified that the actual source of the
+crash in concurrent-output is really fixed. That needs building with
+concurrent-output 1.10.8 and then trying to reproduce the crash
+at the command line.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_33_3338f896a983292bef576dcd369bba5a._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_33_3338f896a983292bef576dcd369bba5a._comment
new file mode 100644
index 0000000000..d185f85ba8
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_33_3338f896a983292bef576dcd369bba5a._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 33"""
+ date="2018-11-19T21:57:13Z"
+ content="""
+Interesting that one side of the deadlock is a MVar and the other side is STM:
+
+	MVar deadlock detected CallStack (from HasCallStack):
+	  debugLocks, called at Messages.hs:265:12 in main:Messages
+	STM deadlock detected CallStack (from HasCallStack):
+	  debugLocks, called at Messages.hs:265:12 in main:Messages
+
+This seems consistent with a single call of `waitDisplayChange` being involved.
+That's the STM side. The MVar side is the `takeMVar` call in `prompt`.
+
+So somehow `waitDisplayChange` is blocking and of course the `takeMVar`
+also blocks waiting for it. But with only a single caller to `waitDisplayChange`,
+my bug fix in concurrent-output can't have been the actual fix. It has to
+block with a single caller.
+
+Oh, what if `waitDisplayChange` is called when there are no display changes
+pending, because there are no console regions being displayed? 
+I think it would still block then!
+
+In a bench test I've at least verified it hangs in that situation, though I have not
+triggered ghc's deadlock detection. Which is good enough for me, I know
+I need to fix this problem in concurrent-output, and also it seems my earlier
+fix to git-annex is enough to avoid triggering the underlying bug; git-annex
+won't need to depend on the fixed concurrent-output.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_33_fe7e5c3340282f89c3393d8c5a2bc17c._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_33_fe7e5c3340282f89c3393d8c5a2bc17c._comment
new file mode 100644
index 0000000000..a8909719f0
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_33_fe7e5c3340282f89c3393d8c5a2bc17c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 33"""
+ date="2018-11-19T21:48:30Z"
+ content="""
+As of 451145738267b5858132554da2367a78c145b610 git-annex depends on the
+hopefully fixed concurrent-output, so if you build that version and it
+works at the command line, we can know for sure.
+
+You'll need to run `cabal update; cabal install --only-dependencies` in the
+git-annex source dir to get the fixed concurrent-output installed before
+building git-annex.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_35_296739c184ac8d0cc453aeeeff5b6f74._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_35_296739c184ac8d0cc453aeeeff5b6f74._comment
new file mode 100644
index 0000000000..de2fd458cd
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_35_296739c184ac8d0cc453aeeeff5b6f74._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 35"""
+ date="2018-11-19T22:42:12Z"
+ content="""
+Fixed underlying bug in concurrent-output. No more changes in git-annex
+needed for this, and I'm confident enough I've gotten to the root cause
+now.
+
+Note that you can  open a new bug report about the test suite failures on
+that system, if it's really a bug and not some NFS problem or whatever.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_36_75f52900d12931b4c6172e10401f28d3._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_36_75f52900d12931b4c6172e10401f28d3._comment
new file mode 100644
index 0000000000..9e22bfbfdc
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_36_75f52900d12931b4c6172e10401f28d3._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 36"
+ date="2018-11-19T22:46:01Z"
+ content="""
+> Bisecting git-annex couldn't isolate the problem to any commit if the bug was fixed in concurrent-output. What commit did bisect point to?
+
+[[!format sh \"\"\"
+
+[yhalchen@discovery7 git-annex]$ git bisect start 900bf3436 05bfce7ca^
+Already on 'master'
+Your branch is up to date with 'origin/master'.
+Bisecting: 7 revisions left to test after this (roughly 3 steps)
+[04b5ed09d8bcd9cef83e605d5cc061892010ada7] close old unreproducible bug report
+[yhalchen@discovery7 git-annex]$ git bisect run bash -c '! ../bisect-git-annex ../git-annex-dev.img ../bisect-git-annex-lock.sh'
+running bash -c ! ../bisect-git-annex ../git-annex-dev.img ../bisect-git-annex-lock.sh
+I: cleaning /ihome/yhalchen/git-annex
+I: building 7.20181105-119-g04b5ed09d
+...
+872af2b2f1049e4eecf274ac70caf99a367f3818 is the first bad commit
+commit 872af2b2f1049e4eecf274ac70caf99a367f3818
+Author: Joey Hess <joeyh@joeyh.name>
+Date:   Thu Nov 15 14:26:40 2018 -0400
+    
+    avoid using concurrent-output at all when --quiet or --json
+    
+    Of course, it wasn't used much in those modes, because normal output is
+    avoided. But it was still initialized and used in a few places,
+    including a call to hideRegionsWhile.
+
+:040000 040000 b81c7bae30915cdacf1fbfd11b0c203c59381ea1 5eff43f94de79fd18b6480a6ace8e3115533ca07 M      CmdLine
+:100644 100644 9e33bd7762e0488ab2d4d371ca40ee4f70a0bdd8 21422e4495ef77cadbfa8ba48e832b300a656839 M      Messages.hs
+:040000 040000 9d7b1b176904f78b29ffe92939411e2f42b0d770 fc3c3a51b5bdfab4c12198490825e801e7f08ac4 M      Messages
+bisect run success
+\"\"\"]]
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_3_eea08486fa9669bd197eb9e957b65ef8._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_3_eea08486fa9669bd197eb9e957b65ef8._comment
new file mode 100644
index 0000000000..6799afbb23
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_3_eea08486fa9669bd197eb9e957b65ef8._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-11-12T15:27:27Z"
+ content="""
+It certianly seems possible that
+[[!commit 6ecd55a9fa4c64399b5ede3944bd2aa5f78cf0b1]]
+could have introduced a locking problem causing such a crash, 
+assuming you are running that version (can't tell from your version string
+due to the git rev not being one from the git-annex repo). 
+
+As Andrew noted, the multiple ssh password prompt issue is expected if you
+are using `GIT_SSH` or `GIT_SSH_COMMAND`. From discussion in 
+<https://github.com/datalad/datalad/issues/2988> it seems like you might
+be?
+
+The fact that it says 
+"(transfer already in progress, or unable to take transfer lock)" strongly
+suggests they you have annex.pidlock set locally. It would be good to know
+about this or other configuration.
+
+I have not had any luck reproducing the crash so far. I have tried setting
+`GIT_SSH`, `GIT_ANNEX_USE_GIT_SSH`, and `annex.pidlock`.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_4_817a9d27a0b15798671f4dc5cd661164._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_4_817a9d27a0b15798671f4dc5cd661164._comment
new file mode 100644
index 0000000000..f42a884037
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_4_817a9d27a0b15798671f4dc5cd661164._comment
@@ -0,0 +1,72 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="reply on the issue "
+ date="2018-11-12T16:48:08Z"
+ content="""
+>  (can't tell from your version string due to the git rev not being one from the git-annex repo)
+
+patch for my \"custom\" version is now (if was not before) sent out -- needs adjustment in standalone patch
+
+> As Andrew noted, the multiple ssh password prompt issue is expected if you are using GIT_SSH or GIT_SSH_COMMAND. From discussion in https://github.com/datalad/datalad/issues/2988 it seems like you might be?
+
+in [a comment on that issue](https://github.com/datalad/datalad/issues/2988#issuecomment-437088252) I call `git annex` directly, so I think I did not have any custom env settings set...  Moreover as I [commented further](https://github.com/datalad/datalad/issues/2988#issuecomment-437095621) nothing changed when I set `GIT_ANNEX_USE_GIT_SSH=1` which I guess should have counteracted?  
+I have tried now with `6.20170815+gitg22da64d0f-1~ndall+1` -- provides a single prompt. 
+Here is again output now also checking for SSH variables:
+[[!format sh \"\"\"
+[yhalchen@discovery7 QA]$ export | grep GIT       
+[yhalchen@discovery7 QA]$ git annex version | head -n 1   
+git-annex version: 6.20180926-gc906aaf
+[yhalchen@discovery7 QA]$ git annex get -J2 sub-qa/ 
+get sub-qa/ses-20161128/dwi/sub-qa_ses-20161128_acq-DTIX30Xp2Xs4_dwi.nii.gz get sub-qa/ses-20161128/dwi/sub-qa_ses-20161128_acq-DTIX30Xp2_dwi.nii.gz (from origin...) 
+(from origin...) 
+yoh@falkor.datalad.org's password: yoh@falkor.datalad.org's password: 
+\"\"\"]]
+
+> ... suggests they you have annex.pidlock set locally. It would be good to know about this or other configuration.
+
+smth like?
+
+[[!format sh \"\"\"
+[yhalchen@discovery7 QA]$ git config annex.pidlock
+false
+\"\"\"]]
+
+I also no longer see that \"transfer already in progress...\" - may be I changed config since then:
+
+[[!format sh \"\"\"
+[yhalchen@discovery7 QA]$ git annex version | head -n1 ; git annex get -J2 sub-qa/
+git-annex version: 7.20181105+git22-g4c7236c58-1~ndall+1
+get sub-qa/ses-20161128/dwi/sub-qa_ses-20161128_acq-DTIX30Xp2Xs4_dwi.nii.gz get sub-qa/ses-20161128/dwi/sub-qa_ses-20161128_acq-DTIX30Xp2_dwi.nii.gz (from origin...) 
+(from origin...) 
+
+
+  thread blocked indefinitely in an STM transaction
+  thread blocked indefinitely in an MVar operation
+
+  Unable to access these remotes: origin
+
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+
+  Try making some of these repositories available:
+  	6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA
+  	6384a551-a41d-4290-b186-9258befede97 -- bids@rolando:/inbox/BIDS/dbic/QA
+   	7d9ed214-3e5f-4cc8-ac88-f397145b2d4c -- yoh@falkor:/srv/datasets.datalad.org/www/dbic/QA [origin]
+   	ba8f2cea-f229-422c-82be-6580e5e07ed5 -- yoh@smaug:/mnt/datasets/datalad/crawl/dbic/QA
+   	7d9ed214-3e5f-4cc8-ac88-f397145b2d4c -- yoh@falkor:/srv/datasets.datalad.org/www/dbic/QA [origin]
+failed
+   	ba8f2cea-f229-422c-82be-6580e5e07ed5 -- yoh@smaug:/mnt/datasets/datalad/crawl/dbic/QA
+failed
+git-annex: thread blocked indefinitely in an STM transaction
+\"\"\"]]
+
+FWIW, I have now ran `git annex test` with TMPDIR on that partition, with
+[[!format sh \"\"\"
+157 out of 293 tests failed (686.03s)
+\"\"\"]]
+as the result. [HEre is the full log](http://www.onerussian.com/tmp/annex-test-7.20181105+git22-g4c7236c58.txt) -- may be it would give you some hints.
+
+
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_4_c2df4fa0420c0db31b38e65a8d7dbf92._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_4_c2df4fa0420c0db31b38e65a8d7dbf92._comment
new file mode 100644
index 0000000000..d49cffbbfb
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_4_c2df4fa0420c0db31b38e65a8d7dbf92._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-11-12T15:52:44Z"
+ content="""
+I don't see anything in [[!commit 6ecd55a9fa4c64399b5ede3944bd2aa5f78cf0b1]]
+that could cause a STM deadlock; it uses a TVar and never retries.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_5_288741ae44f2dddbe53ab1dc294e2fb7._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_5_288741ae44f2dddbe53ab1dc294e2fb7._comment
new file mode 100644
index 0000000000..9be03f0e63
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_5_288741ae44f2dddbe53ab1dc294e2fb7._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2018-11-12T17:25:43Z"
+ content="""
+FWIW, running under /tmp with TMPDIR there -- `All 293 tests passed `, so aforementioned test failures are FS related.
+
+another (complete) attempt on `get` under `/tmp`, which is less noisy but still failing due to locking:
+[[!format sh \"\"\"
+[yhalchen@discovery7 tmp]$ git clone yoh@falkor.datalad.org:/srv/datasets.datalad.org/www/dbic/QA/
+Cloning into 'QA'...
+yoh@falkor.datalad.org's password: 
+Permission denied, please try again.
+yoh@falkor.datalad.org's password: 
+remote: Counting objects: 31315, done.
+remote: Compressing objects: 100% (10068/10068), done.
+remote: Total 31315 (delta 15553), reused 26858 (delta 14185)
+Receiving objects: 100% (31315/31315), 31.02 MiB | 43.04 MiB/s, done.
+Resolving deltas: 100% (15553/15553), done.
+
+[yhalchen@discovery7 tmp]$ cd QA
+
+[yhalchen@discovery7 QA]$ git annex get -J2 sub-*                                                               
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+git-annex: thread blocked indefinitely in an STM transaction
+
+[yhalchen@discovery7 QA]$ export | grep SSH
+declare -x SSH_CLIENT=\"10.31.184.44 54944 22\"
+declare -x SSH_CONNECTION=\"10.31.184.44 54944 129.170.232.78 22\"
+declare -x SSH_TTY=\"/dev/pts/6\"
+
+[yhalchen@discovery7 QA]$ export | grep GIT
+
+[yhalchen@discovery7 QA]$ git annex version | head -n 1
+git-annex version: 7.20181105+git22-g4c7236c58-1~ndall+1
+
+[yhalchen@discovery7 QA]$ git annex get --debug -J2 sub-*
+[2018-11-12 12:25:05.499642416] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2018-11-12 12:25:05.515163636] process done ExitSuccess
+[2018-11-12 12:25:05.515289739] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
+[2018-11-12 12:25:05.5303119] process done ExitSuccess
+[2018-11-12 12:25:05.530496533] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"sub-amit\",\"sub-emmet\",\"sub-qa\",\"sub-sid000143\"]
+[2018-11-12 12:25:05.547049728] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2018-11-12 12:25:05.561799248] process done ExitSuccess
+[2018-11-12 12:25:05.561984198] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-11-12 12:25:05.576759502] process done ExitSuccess
+[2018-11-12 12:25:05.577215967] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..b984c211b3b15db79921d77d1c30cf4b06140d0e\",\"--pretty=%H\",\"-n1\"]
+[2018-11-12 12:25:05.59389018] process done ExitSuccess
+[2018-11-12 12:25:05.594415045] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-11-12 12:25:05.596445232] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-11-12 12:25:05.612916] read: ssh [\"-o\",\"BatchMode=true\",\"-S\",\".git/annex/ssh/yoh@falkor.datalad.org\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"yoh@falkor.datalad.org\",\"true\"]
+[2018-11-12 12:25:05.712832294] process done ExitFailure 255
+git-annex: thread blocked indefinitely in an STM transaction
+
+```
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_7_44d25c37e26e71b2aff759a0d39c5803._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_7_44d25c37e26e71b2aff759a0d39c5803._comment
new file mode 100644
index 0000000000..9885cdfae0
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_7_44d25c37e26e71b2aff759a0d39c5803._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2018-11-12T17:54:07Z"
+ content="""
+	[2018-11-12 12:25:05.612916] read: ssh [\"-o\",\"BatchMode=true\",\"-S\",\".git/annex/ssh/yoh@falkor.datalad.org\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"yoh@falkor.datalad.org\",\"true\"]
+	[2018-11-12 12:25:05.712832294] process done ExitFailure 255
+	git-annex: thread blocked indefinitely in an STM transaction
+
+So sshing without letting it prompt for a password has failed.
+The next thing git-annex should do at that point is take a lock
+to prevent concurrent prompts (which does not use STM), 
+ask concurrent-output to hide any regions from the display
+(which does use STM), and run ssh again to prompt. 
+
+It's apparently crashing before it can run ssh again. (Although I'm not really
+sure if it is, it's also possible it overwrote some of the debug output while
+trying to hide console regions. Please capture a complete typescript.)
+
+It could be that concurrent-output's waitDisplayChange is buggy,
+with some kind of race. But this does not seem to be behaving like a race condition,
+does it? It happens every time?
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_8_24ab22004dd25169bb9191a92f1e0ac4._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_8_24ab22004dd25169bb9191a92f1e0ac4._comment
new file mode 100644
index 0000000000..48322996cc
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_8_24ab22004dd25169bb9191a92f1e0ac4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 8"
+ date="2018-11-12T19:15:53Z"
+ content="""
+> Please capture a complete typescript.
+
+Could you give me a hint on \"how\"?
+"""]]
diff --git a/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_9_c8a52578b5d7482683443bd5d95a5265._comment b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_9_c8a52578b5d7482683443bd5d95a5265._comment
new file mode 100644
index 0000000000..30deead73f
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/multiple_ssh_prompts__44___and_thread_blocked_indefinitely_in_an___63____63____63___transaction/comment_9_c8a52578b5d7482683443bd5d95a5265._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 9"
+ date="2018-11-13T04:14:28Z"
+ content="""
+Initially didn't spot the question:
+
+>  It happens every time?
+
+yes
+"""]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount.mdwn b/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount.mdwn
new file mode 100644
index 0000000000..73a0a8a936
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount.mdwn
@@ -0,0 +1,67 @@
+identification to need to setup pidlock worked fine in the past
+
+<details>
+<summary>e.g. here with 7.20181105+git22-g4c7236c58-1~ndall+1</summary> 
+
+[[!format sh """
+[bids@rolando BIDS] > mkdir d; cd d; git init; git annex init; cat .git/config
+Initialized empty Git repository in /inbox/BIDS/d/.git/
+init  
+  Detected a filesystem without POSIX fcntl lock support.
+
+  Enabling annex.pidlock.
+ok
+(recording state in git...)
+[core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = false
+        logallrefupdates = true
+[annex]
+        uuid = 718ca7cc-e0ee-49d9-9bac-37b77e44a20b
+        pidlock = true
+        version = 5
+[bids@rolando d] > git annex version
+git-annex version: 7.20181105+git22-g4c7236c58-1~ndall+1
+
+"""]]
+</details>
+
+but I saw it starting to fail with some upgrade and ignored too long to report:
+
+[[!format sh """
+bids@rolando:/inbox/BIDS$ mkdir d; cd d; git init; PATH=/home/bids/singularity_home/git-annex/7.20190731-gbb16a2610/:$PATH git annex init; cat .git/config 
+Initialized empty Git repository in /inbox/BIDS/d/.git/
+init  
+git-annex: waitToSetLock: resource exhausted (No locks available)
+failed
+git-annex: init: 1 failed
+[core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = false
+        logallrefupdates = true
+[annex]
+        uuid = 5183b554-a0a3-4363-9541-53ca5673ddae
+bids@rolando:/inbox/BIDS/d$ PATH=/home/bids/singularity_home/git-annex/7.20190731-gbb16a2610/:$PATH git annex version
+git-annex version: 7.20190731-gbb16a2610
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+
+"""]]
+
+mount point details: 
+
+```
+type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.232.11.5,mountvers=3,mountport=680,mountproto=udp,local_lock=none,addr=10.232.11.5)
+```
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_1_82a71d4e9656c83e2d50143cb8a31602._comment b/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_1_82a71d4e9656c83e2d50143cb8a31602._comment
new file mode 100644
index 0000000000..3f0f18e569
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_1_82a71d4e9656c83e2d50143cb8a31602._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-08-29T16:11:14Z"
+ content="""
+No changes in the code of the lock test. Somehow the exception
+was not caught, and it's only catching IO exceptions, so it must
+be another type of exception.
+
+Oddly, I can't find any indication that waitToSetLock can throw anything
+other than an IO exception.
+
+I've changed it to catch all exceptions, which will presumably fix the
+problem, but not closing this bug as I don't fully understand it and so am
+not certian of the fix.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_2_9bd5f0acb9761dcf59ecd38092e3e14d._comment b/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_2_9bd5f0acb9761dcf59ecd38092e3e14d._comment
new file mode 100644
index 0000000000..0f2f43a188
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_2_9bd5f0acb9761dcf59ecd38092e3e14d._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2019-08-31T13:00:57Z"
+ content="""
+I have ran git bisect, didn't double check but it points to
+
+[[!format sh \"\"\"
+...
+running /home/bids/git-annexes/datalad/tools/bisect-git-annex /home/bids/datalad-datalad-master-git-annex-dev.simg /home/bids/git-annexes/datalad/tools/bisect-git-annex.scripts/bisect-nfs-lock.sh
+I: cleaning /home/bids/git-annexes/git-annex
+I: building 7.20181211-248-gd5f246370
+I: running the script
+Initialized empty Git repository in /inbox/BIDS/.git/tmp/repo/.git/
+init
+git-annex: waitToSetLock: resource exhausted (No locks available)
+failed
+git-annex: init: 1 failed
+d5f2463702a7cd8e56ea000e21bfe5d4ba9cd386 is the first bad commit
+commit d5f2463702a7cd8e56ea000e21bfe5d4ba9cd386
+Author: Joey Hess <joeyh@joeyh.name>
+Date:   Thu Jan 17 15:40:44 2019 -0400
+    
+    misctmp cleanup
+    
+    * Switch to using .git/annex/othertmp for tmp files other than partial
+      downloads, and make stale files left in that directory when git-annex
+      is interrupted be cleaned up promptly by subsequent git-annex processes.
+    * The .git/annex/misctmp directory is no longer used and git-annex will
+      delete anything lingering in there after it's 1 week old.
+    
+    Also, in Annex.Ingest, made the filename it uses in the tmp dir be
+    prefixed with \"ingest-\" to avoid potentially using a filename used by
+    some other code.
+
+:040000 040000 3a3f3af1c5222bb96684c79b9bccc20b3ff266a2 24efba74a2b6e4a361e300f32325fafba76b8243 M      Annex
+:040000 040000 193fa3b2bc663031a0e387e921c720e022daabbc 6a0081f3e1df14a182416e734eedb0a2d8bdd46d M      Assistant
+:100644 100644 d313f9ee315a095e992b729f0d7001e14f413aee f5c5f511d85ffb52c303d1b718fc62e5179b66f9 M      CHANGELOG
+:040000 040000 432613892dd51d2ebb804f11c96d1d2c7956dab7 9bcbedc855d35faeeaf9b6d74cc2f48c48d8d764 M      Command
+:040000 040000 0d4841d00ee7ec5b59037ac2c37ab10482359671 0b12fe02a9028e3a7a083fd3dfdc01bf38a8626e M      Remote
+:100644 100644 555166e29905dca5984403500528d4594b4b7bb6 8f9c460306db4c9f3abed23d9181a10f20b42b77 M      Test.hs
+:040000 040000 2eb286c09f87da53c2377cc60b75c2c49fcd049a 33adb5b5e5b8a33b2012345b73f00eb094afd42c M      Types
+:040000 040000 0406fc6fff2205a48d6a215cf18dba2c682de99e a688ce72ede0bbb71b7e2f1f6a811602ee333a16 M      doc
+:100644 100644 839b469b5cea11a65f20652963fea316be367c93 ff2db6e39cee114d8bd386873b0dba6f89e4d4d1 M      git-annex.cabal
+bisect run success
+\"\"\"]]
+may be that gives ideas? (build env was the same, freshly regenerated buster singularity image available via `singularity pull shub://datalad/datalad:git-annex-dev`
+"""]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_3_6d2fceb790e675cb73b193bf67f7a6f4._comment b/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_3_6d2fceb790e675cb73b193bf67f7a6f4._comment
new file mode 100644
index 0000000000..90da4e1ec7
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_3_6d2fceb790e675cb73b193bf67f7a6f4._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="the issue persists in master"
+ date="2019-09-02T14:17:14Z"
+ content="""
+FWIW, the issue persists with current version in master (which comes after comment from 3 days ago where wider exception catching was told to be implemented):
+
+[[!format sh \"\"\"
+[bids@rolando git-annex] > ~/git-annexes/datalad/tools/bisect-git-annex.scripts/bisect-nfs-lock.sh
+Initialized empty Git repository in /inbox/BIDS/.git/tmp/repo/.git/
+init  
+git-annex: waitToSetLock: resource exhausted (No locks available)
+failed
+git-annex: init: 1 failed
+[bids@rolando git-annex] > echo $?
+1
+[bids@rolando git-annex] > git annex version
+git-annex version: 7.20190826-gf951a6221
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+
+\"\"\"]]
+"""]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_4_bf6487c1740f163745b7dcc41468ec4d._comment b/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_4_bf6487c1740f163745b7dcc41468ec4d._comment
new file mode 100644
index 0000000000..d6ed5f2afd
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___fails_to_detect_need_for_pidlock_on_an_NSF_mount/comment_4_bf6487c1740f163745b7dcc41468ec4d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-09-10T16:28:12Z"
+ content="""
+Thanks for the bisection. It's not the init code that's
+trying and failing to set a lock, but the misctmp cleanup code. Which is
+ironically now used in setting up the temp directory that init uses to
+probe for locking problems. Chicken and egg problem.
+
+Committed a fix.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported.mdwn b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported.mdwn
new file mode 100644
index 0000000000..e4f18fbefe
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported.mdwn
@@ -0,0 +1,71 @@
+### Please describe the problem.
+
+Redoing example from elderly and fixed [issue](https://git-annex.branchable.com/bugs/annex_drop_fails_to_determine_availability_on_a_http_url_redirecting_to_ftp/) which now fails even one step ahead (at `addurl` not `drop` where I guess it would fail too):
+
+[[!format sh """
+$> git annex addurl --debug --pathdepth=-1 http://www.nitrc.org/frs/downloadlink.php/1637
+[2019-05-09 16:37:34.647058788] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2019-05-09 16:37:34.651237646] process done ExitSuccess
+[2019-05-09 16:37:34.651310462] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2019-05-09 16:37:34.654835492] process done ExitSuccess
+[2019-05-09 16:37:34.655059565] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..fc38e19e73cbb843c7d4824256a40eb37cad38fc","--pretty=%H","-n1"]
+[2019-05-09 16:37:34.667342071] process done ExitSuccess
+[2019-05-09 16:37:34.667770788] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2019-05-09 16:37:34.668256112] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+addurl http://www.nitrc.org/frs/downloadlink.php/1637 [2019-05-09 16:37:34.696706993] Request {
+  host                 = "www.nitrc.org"
+  port                 = 80
+  secure               = False
+  requestHeaders       = [("Accept-Encoding",""),("User-Agent","git-annex/7.20190322+git133-g59922f1f4-1~ndall+1")]
+  path                 = "/frs/downloadlink.php/1637"
+  queryString          = ""
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+}
+
+
+[2019-05-09 16:37:35.881856173] Request {
+  host                 = "www.nitrc.org"
+  port                 = 80
+  secure               = False
+  requestHeaders       = [("Accept-Encoding","identity"),("User-Agent","git-annex/7.20190322+git133-g59922f1f4-1~ndall+1")]
+  path                 = "/frs/downloadlink.php/1637"
+  queryString          = ""
+  method               = "GET"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+}
+
+download failed: Found
+failed
+[2019-05-09 16:37:36.064903879] process done ExitSuccess
+[2019-05-09 16:37:36.065541286] process done ExitSuccess
+git-annex: addurl: 1 failed
+1 10323 ->1.....................................:Thu 09 May 2019 04:37:36 PM EDT:.
+(git)smaug:/tmp[master]
+$> git annex version
+git-annex version: 7.20190322+git133-g59922f1f4-1~ndall+1
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 5
+
+"""]]
+
+Originally [reported in DataLad #3321](https://github.com/datalad/datalad/issues/3321) with workarounds to force `curl` downloads
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_1_5184c1b87e249f203541f610278ed08e._comment b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_1_5184c1b87e249f203541f610278ed08e._comment
new file mode 100644
index 0000000000..fe831bfe01
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_1_5184c1b87e249f203541f610278ed08e._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-05-23T17:39:36Z"
+ content="""
+The old behavior changed due to a security fix in commit
+[[!commit b54b2cdc0ef1373fc200c0d28fded3c04fd57212]].
+
+When git-annex followed a http redirect with curl, the http server
+could provide a ftp url that causes curl to access localhost or the lan.
+Which basically violates annex.security.allowed-http-addresses.
+(That is aimed at http, but accessing a ftp server would have similar
+security problems.)
+
+(For the same reason, non-redirect ftp urls don't work unless using 
+curl is enabled.)
+
+To avoid that attack while following the ftp redirect, git-annex would need
+to parse out the ftp server's hostname, resolve it and I suppose substitute
+the IP address back into the ftp url before passing it to curl. (To avoid
+DNS tricks.)
+
+I don't know if replacing a ftp hostname with an IP address would always
+work; there may be something that cares about the specific ftp hostname
+to eg decide what password to give the ftp server? Been a while since I FTPed.
+
+----
+
+Maybe a new configuration item is a better fix?
+`git config annex.security.allowed-ftp-addresses all` could enable
+use of curl as needed for ftp, without forcing use of curl for http.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_2_860458173cb4d745e8c9833b804398d8._comment b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_2_860458173cb4d745e8c9833b804398d8._comment
new file mode 100644
index 0000000000..b286f624cc
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_2_860458173cb4d745e8c9833b804398d8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="configuration variable"
+ date="2019-05-23T19:31:46Z"
+ content="""
+I think then we could add in DataLad ability to record in the repository's configuration custom git annex configuration options to be passed to git annex calls (for that repo) and this way mitigate it where needed
+"""]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_3_921d2493f51ecb61b711773238c9f7e7._comment b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_3_921d2493f51ecb61b711773238c9f7e7._comment
new file mode 100644
index 0000000000..e4114dd155
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_3_921d2493f51ecb61b711773238c9f7e7._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-05-29T14:22:57Z"
+ content="""
+The netrc(5) file does use the hostname of the ftp server, so if git-annex
+swapped in an IP address it resolved it would not match the netrc file. But
+curl only reads the file when --netrc is used.
+
+If annex.web-options is set to --netrc (or anything), and
+annex.security.allowed-http-addresses=all, git-annex uses curl already
+and the security measures are disabled.
+
+So, git-annex could replace the ftp server hostname with the IP address
+when not so configured, and nothing that currently works would break, and
+this problem would be solved without needing any new configuration.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_4_b15837921956ad166cf53a5dd23cb7dd._comment b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_4_b15837921956ad166cf53a5dd23cb7dd._comment
new file mode 100644
index 0000000000..f08a5344f3
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_4_b15837921956ad166cf53a5dd23cb7dd._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""ftp bounce attack"""
+ date="2019-05-30T15:53:26Z"
+ content="""
+In a PASV ftp connection, the server provides to the client an IP address
+and port to connect to. That is exploited by a ftp bounce attack.
+(Which I last thought about in like 1998? Why are we still using these bad
+old protocols?)
+
+So it seems git-annex can't rely on checking the ftp server IP is not
+local, because the non-local ftp server could use that to get the client to
+connect to a local ftp server. After content from that gets added to the
+git annex, we're back to CVE-2018-10857.
+
+curl defaults to PASV of course (active FTP is unlikely to work on the
+"modern" non-p2p internet). Seems curl does have a --ftp-skip-pasv-ip
+that makes it ignore whatever IP address the FTP server might present and
+just continue to use the same server IP.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_5_2a66b890e3c60d1102acb7cef0b86308._comment b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_5_2a66b890e3c60d1102acb7cef0b86308._comment
new file mode 100644
index 0000000000..53324a29e6
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_5_2a66b890e3c60d1102acb7cef0b86308._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-05-30T15:59:57Z"
+ content="""
+Yet another problem: A ftp server might have both IPv4 and IPv6 addresses,
+and only one might work. So git-annex would need to run curl more
+than once if substituting in IP.
+
+Hmm.. curl has a --resolve that could be used instead of git-annex
+replacing the server hostname with its IP. This allows passing both ipv6
+and ipv4 addresses:
+
+	curl --resolve *:80:[::1],127.0.0.1 http://google.com/
+
+And it does also work for ftp and other protocols, but the protocol port
+number has to be included and can't be wildcarded. In particular, if 
+the ftp url is on a nonstandard port, that port has to be included,
+otherwise port 21.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_6_c42192a94651f34d32f6d5b91b1c09e8._comment b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_6_c42192a94651f34d32f6d5b91b1c09e8._comment
new file mode 100644
index 0000000000..ed30c0f83e
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_6_c42192a94651f34d32f6d5b91b1c09e8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2019-05-30T18:50:18Z"
+ content="""
+I've gotten secure ftp url downloading working now. Have not yet put back
+in the handling of http-to-ftp redirects.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_7_11f4424d3b9fb6c54fa510320affac73._comment b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_7_11f4424d3b9fb6c54fa510320affac73._comment
new file mode 100644
index 0000000000..44434ee0b8
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/regression__58___http_downloads_redirecting_to_ftp_are_no_longer_supported/comment_7_11f4424d3b9fb6c54fa510320affac73._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2019-05-30T20:03:28Z"
+ content="""
+All fixed now.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/rmurl_marks_url_not_available_in_wrong_remote.mdwn b/doc/projects/repronim/bugs-done/rmurl_marks_url_not_available_in_wrong_remote.mdwn
new file mode 100644
index 0000000000..958304e199
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/rmurl_marks_url_not_available_in_wrong_remote.mdwn
@@ -0,0 +1,83 @@
+### Please describe the problem.
+
+even if url is associated with `web` remote, if some other remote can claim it, `git annex rmurl` would announce it not available for a "custom remote" (with `:` prefix) thus not `web`, thus keeping it "available" in subsequent calls to `git annex info`
+
+<details>
+<summary>complete example reproducer but needs datalad</summary> 
+
+```shell
+#!/bin/bash
+
+export PS4='> '
+
+set -eu
+set -x
+
+cd "$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)"
+git clone http://github.com/ReproNim/containers
+cd containers
+
+git annex initremote datalad externaltype=datalad type=external encryption=none autoenable=true
+git annex enableremote datalad
+
+git annex info
+
+git annex whereis images/bids/bids-rshrf--1.4.4.sing
+git annex rmurl images/bids/bids-rshrf--1.4.4.sing 'https://storage.googleapis.com/singularityhub/singularityhub%2Fgithub.com%2FReproNim%2Fcontainers%2Feb098949b1061510767ef444c57a4f74e592f9fc%2F61b8e91176d796614444515a484f2a2d%2F61b8e91176d796614444515a484f2a2d.sif?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=153500186594-compute%40developer.gserviceaccount.com%2F20210223%2Fauto%2Fstorage%2Fgoog4_request&X-Goog-Date=20210223T213231Z&X-Goog-Expires=3&X-Goog-SignedHeaders=host&X-Goog-Signature=433fa7ffb52a59c5c36f95c2cba2eeb94cd42178a6afea27744cc61bc10a526cfc13ab2670186dc42b1a3d88c017cd544c018e3d5a198927814d748afd98cd66aaae0e154c93a610c9e71b93c9fb21cc4a0d86bbdfb0e803373253a1f6abd487a4400124313e80575dc38a17ba2dc7db137f1c50f5722f46f9be6682a6cb1a6550cb97107cdd1f6611e7e308998ef18223cebf39caaa283d5955dc20460028eb3f9973761282cf02416e8e8fdb66b90566f7b08c3a41e6e76d1a55274b6cfc7e0ff1cc415f34f81bd8650f2c49f889936053044e88d0bd486e371ee7b78f0326f1a4ffd4a634f4489920c323d5f5202a8544ad23abf34b3e9b9e8644685fd882'
+
+git annex whereis images/bids/bids-rshrf--1.4.4.sing
+git show -p git-annex
+git show git-annex:fe1/c89/MD5E-s116695071--61b8e91176d796614444515a484f2a2d.4.sing.log.web
+
+```
+</details>
+
+
+which ends with following output where you can see URL being listed associated with `web` (not datalad), `rmurl` "succeeding" but announcing it `0` on a custom remote (prefix `:`) and then subsequent `annex info` still shows that it is still available from `web`.  I would have expected that .log to be adjusted reflecting prior information (i.e. without `:`) and thus be removed from `web`:
+
+[[!format sh """
+> git annex whereis images/bids/bids-rshrf--1.4.4.sing
+whereis images/bids/bids-rshrf--1.4.4.sing (3 copies) 
+  	00000000-0000-0000-0000-000000000001 -- web
+   	23456fab-05d4-441e-8952-b8c6d90ad785 -- yoh@smaug:~/proj/repronim/containers
+   	71c620b5-997f-4849-bb30-c42dbb48a51e -- [datasets.datalad.org]
+
+  web: https://storage.googleapis.com/singularityhub/singularityhub%2Fgithub.com%2FReproNim%2Fcontainers%2Feb098949b1061510767ef444c57a4f74e592f9fc%2F61b8e91176d796614444515a484f2a2d%2F61b8e91176d796614444515a484f2a2d.sif?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=153500186594-compute%40developer.gserviceaccount.com%2F20210223%2Fauto%2Fstorage%2Fgoog4_request&X-Goog-Date=20210223T213231Z&X-Goog-Expires=3&X-Goog-SignedHeaders=host&X-Goog-Signature=433fa7ffb52a59c5c36f95c2cba2eeb94cd42178a6afea27744cc61bc10a526cfc13ab2670186dc42b1a3d88c017cd544c018e3d5a198927814d748afd98cd66aaae0e154c93a610c9e71b93c9fb21cc4a0d86bbdfb0e803373253a1f6abd487a4400124313e80575dc38a17ba2dc7db137f1c50f5722f46f9be6682a6cb1a6550cb97107cdd1f6611e7e308998ef18223cebf39caaa283d5955dc20460028eb3f9973761282cf02416e8e8fdb66b90566f7b08c3a41e6e76d1a55274b6cfc7e0ff1cc415f34f81bd8650f2c49f889936053044e88d0bd486e371ee7b78f0326f1a4ffd4a634f4489920c323d5f5202a8544ad23abf34b3e9b9e8644685fd882
+ok
+> git annex rmurl images/bids/bids-rshrf--1.4.4.sing 'https://storage.googleapis.com/singularityhub/singularityhub%2Fgithub.com%2FReproNim%2Fcontainers%2Feb098949b1061510767ef444c57a4f74e592f9fc%2F61b8e91176d796614444515a484f2a2d%2F61b8e91176d796614444515a484f2a2d.sif?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=153500186594-compute%40developer.gserviceaccount.com%2F20210223%2Fauto%2Fstorage%2Fgoog4_request&X-Goog-Date=20210223T213231Z&X-Goog-Expires=3&X-Goog-SignedHeaders=host&X-Goog-Signature=433fa7ffb52a59c5c36f95c2cba2eeb94cd42178a6afea27744cc61bc10a526cfc13ab2670186dc42b1a3d88c017cd544c018e3d5a198927814d748afd98cd66aaae0e154c93a610c9e71b93c9fb21cc4a0d86bbdfb0e803373253a1f6abd487a4400124313e80575dc38a17ba2dc7db137f1c50f5722f46f9be6682a6cb1a6550cb97107cdd1f6611e7e308998ef18223cebf39caaa283d5955dc20460028eb3f9973761282cf02416e8e8fdb66b90566f7b08c3a41e6e76d1a55274b6cfc7e0ff1cc415f34f81bd8650f2c49f889936053044e88d0bd486e371ee7b78f0326f1a4ffd4a634f4489920c323d5f5202a8544ad23abf34b3e9b9e8644685fd882'
+rmurl images/bids/bids-rshrf--1.4.4.sing ok
+(recording state in git...)
+> git annex whereis images/bids/bids-rshrf--1.4.4.sing
+whereis images/bids/bids-rshrf--1.4.4.sing (3 copies) 
+  	00000000-0000-0000-0000-000000000001 -- web
+   	23456fab-05d4-441e-8952-b8c6d90ad785 -- yoh@smaug:~/proj/repronim/containers
+   	71c620b5-997f-4849-bb30-c42dbb48a51e -- [datasets.datalad.org]
+
+  web: https://storage.googleapis.com/singularityhub/singularityhub%2Fgithub.com%2FReproNim%2Fcontainers%2Feb098949b1061510767ef444c57a4f74e592f9fc%2F61b8e91176d796614444515a484f2a2d%2F61b8e91176d796614444515a484f2a2d.sif?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=153500186594-compute%40developer.gserviceaccount.com%2F20210223%2Fauto%2Fstorage%2Fgoog4_request&X-Goog-Date=20210223T213231Z&X-Goog-Expires=3&X-Goog-SignedHeaders=host&X-Goog-Signature=433fa7ffb52a59c5c36f95c2cba2eeb94cd42178a6afea27744cc61bc10a526cfc13ab2670186dc42b1a3d88c017cd544c018e3d5a198927814d748afd98cd66aaae0e154c93a610c9e71b93c9fb21cc4a0d86bbdfb0e803373253a1f6abd487a4400124313e80575dc38a17ba2dc7db137f1c50f5722f46f9be6682a6cb1a6550cb97107cdd1f6611e7e308998ef18223cebf39caaa283d5955dc20460028eb3f9973761282cf02416e8e8fdb66b90566f7b08c3a41e6e76d1a55274b6cfc7e0ff1cc415f34f81bd8650f2c49f889936053044e88d0bd486e371ee7b78f0326f1a4ffd4a634f4489920c323d5f5202a8544ad23abf34b3e9b9e8644685fd882
+ok
+> git show -p git-annex
+commit 0738371567c5f925070e7da4c01ffa44c97bf830 (git-annex)
+Author: Yaroslav Halchenko <debian@onerussian.com>
+Date:   Mon Mar 15 18:46:06 2021 -0400
+
+    update
+
+diff --git a/fe1/c89/MD5E-s116695071--61b8e91176d796614444515a484f2a2d.4.sing.log.web b/fe1/c89/MD5E-s116695071--61b8e91176d796614444515a484f2a2d.4.sing.log.web
+index b3f20a7..5d25928 100644
+--- a/fe1/c89/MD5E-s116695071--61b8e91176d796614444515a484f2a2d.4.sing.log.web
++++ b/fe1/c89/MD5E-s116695071--61b8e91176d796614444515a484f2a2d.4.sing.log.web
+@@ -1 +1,2 @@
++1615848366.629329639s 0 :https://storage.googleapis.com/singularityhub/singularityhub%2Fgithub.com%2FReproNim%2Fcontainers%2Feb098949b1061510767ef444c57a4f74e592f9fc%2F61b8e91176d796614444515a484f2a2d%2F61b8e91176d796614444515a484f2a2d.sif?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=153500186594-compute%40developer.gserviceaccount.com%2F20210223%2Fauto%2Fstorage%2Fgoog4_request&X-Goog-Date=20210223T213231Z&X-Goog-Expires=3&X-Goog-SignedHeaders=host&X-Goog-Signature=433fa7ffb52a59c5c36f95c2cba2eeb94cd42178a6afea27744cc61bc10a526cfc13ab2670186dc42b1a3d88c017cd544c018e3d5a198927814d748afd98cd66aaae0e154c93a610c9e71b93c9fb21cc4a0d86bbdfb0e803373253a1f6abd487a4400124313e80575dc38a17ba2dc7db137f1c50f5722f46f9be6682a6cb1a6550cb97107cdd1f6611e7e308998ef18223cebf39caaa283d5955dc20460028eb3f9973761282cf02416e8e8fdb66b90566f7b08c3a41e6e76d1a55274b6cfc7e0ff1cc415f34f81bd8650f2c49f889936053044e88d0bd486e371ee7b78f0326f1a4ffd4a634f4489920c323d5f5202a8544ad23abf34b3e9b9e8644685fd882
+ 1614115961.926618255s 1 https://storage.googleapis.com/singularityhub/singularityhub%2Fgithub.com%2FReproNim%2Fcontainers%2Feb098949b1061510767ef444c57a4f74e592f9fc%2F61b8e91176d796614444515a484f2a2d%2F61b8e91176d796614444515a484f2a2d.sif?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=153500186594-compute%40developer.gserviceaccount.com%2F20210223%2Fauto%2Fstorage%2Fgoog4_request&X-Goog-Date=20210223T213231Z&X-Goog-Expires=3&X-Goog-SignedHeaders=host&X-Goog-Signature=433fa7ffb52a59c5c36f95c2cba2eeb94cd42178a6afea27744cc61bc10a526cfc13ab2670186dc42b1a3d88c017cd544c018e3d5a198927814d748afd98cd66aaae0e154c93a610c9e71b93c9fb21cc4a0d86bbdfb0e803373253a1f6abd487a4400124313e80575dc38a17ba2dc7db137f1c50f5722f46f9be6682a6cb1a6550cb97107cdd1f6611e7e308998ef18223cebf39caaa283d5955dc20460028eb3f9973761282cf02416e8e8fdb66b90566f7b08c3a41e6e76d1a55274b6cfc7e0ff1cc415f34f81bd8650f2c49f889936053044e88d0bd486e371ee7b78f0326f1a4ffd4a634f4489920c323d5f5202a8544ad23abf34b3e9b9e8644685fd882
+> git show git-annex:fe1/c89/MD5E-s116695071--61b8e91176d796614444515a484f2a2d.4.sing.log.web
+1615848366.629329639s 0 :https://storage.googleapis.com/singularityhub/singularityhub%2Fgithub.com%2FReproNim%2Fcontainers%2Feb098949b1061510767ef444c57a4f74e592f9fc%2F61b8e91176d796614444515a484f2a2d%2F61b8e91176d796614444515a484f2a2d.sif?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=153500186594-compute%40developer.gserviceaccount.com%2F20210223%2Fauto%2Fstorage%2Fgoog4_request&X-Goog-Date=20210223T213231Z&X-Goog-Expires=3&X-Goog-SignedHeaders=host&X-Goog-Signature=433fa7ffb52a59c5c36f95c2cba2eeb94cd42178a6afea27744cc61bc10a526cfc13ab2670186dc42b1a3d88c017cd544c018e3d5a198927814d748afd98cd66aaae0e154c93a610c9e71b93c9fb21cc4a0d86bbdfb0e803373253a1f6abd487a4400124313e80575dc38a17ba2dc7db137f1c50f5722f46f9be6682a6cb1a6550cb97107cdd1f6611e7e308998ef18223cebf39caaa283d5955dc20460028eb3f9973761282cf02416e8e8fdb66b90566f7b08c3a41e6e76d1a55274b6cfc7e0ff1cc415f34f81bd8650f2c49f889936053044e88d0bd486e371ee7b78f0326f1a4ffd4a634f4489920c323d5f5202a8544ad23abf34b3e9b9e8644685fd882
+1614115961.926618255s 1 https://storage.googleapis.com/singularityhub/singularityhub%2Fgithub.com%2FReproNim%2Fcontainers%2Feb098949b1061510767ef444c57a4f74e592f9fc%2F61b8e91176d796614444515a484f2a2d%2F61b8e91176d796614444515a484f2a2d.sif?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=153500186594-compute%40developer.gserviceaccount.com%2F20210223%2Fauto%2Fstorage%2Fgoog4_request&X-Goog-Date=20210223T213231Z&X-Goog-Expires=3&X-Goog-SignedHeaders=host&X-Goog-Signature=433fa7ffb52a59c5c36f95c2cba2eeb94cd42178a6afea27744cc61bc10a526cfc13ab2670186dc42b1a3d88c017cd544c018e3d5a198927814d748afd98cd66aaae0e154c93a610c9e71b93c9fb21cc4a0d86bbdfb0e803373253a1f6abd487a4400124313e80575dc38a17ba2dc7db137f1c50f5722f46f9be6682a6cb1a6550cb97107cdd1f6611e7e308998ef18223cebf39caaa283d5955dc20460028eb3f9973761282cf02416e8e8fdb66b90566f7b08c3a41e6e76d1a55274b6cfc7e0ff1cc415f34f81bd8650f2c49f889936053044e88d0bd486e371ee7b78f0326f1a4ffd4a634f4489920c323d5f5202a8544ad23abf34b3e9b9e8644685fd882
+"""]]
+
+git annex `8.20210310+git49-g4d6f74477-1~ndall+1`
+
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/rmurl_marks_url_not_available_in_wrong_remote/comment_1_2aa17a7067a183f5837b5a41d74fcde9._comment b/doc/projects/repronim/bugs-done/rmurl_marks_url_not_available_in_wrong_remote/comment_1_2aa17a7067a183f5837b5a41d74fcde9._comment
new file mode 100644
index 0000000000..7b0594e608
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/rmurl_marks_url_not_available_in_wrong_remote/comment_1_2aa17a7067a183f5837b5a41d74fcde9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-17T14:07:15Z"
+ content="""
+I'm inclined to think that rmurl should not look at url claiming at all,
+and should remove whichever is set of the the url and the mangled version
+used for claimed urls.
+
+I think probably unregisterurl should do the same. Currently it
+does not look at claiming and only removes the url, not the mangled form. 
+But registerurl does look at claiming, and may add the mangled form,
+so unregister may not undo the effets of register.
+"""]]
diff --git a/doc/projects/repronim/bugs-done/windows__58___autostart_for_annex_64bit_looks_under_x86.mdwn b/doc/projects/repronim/bugs-done/windows__58___autostart_for_annex_64bit_looks_under_x86.mdwn
new file mode 100644
index 0000000000..610080b1a4
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/windows__58___autostart_for_annex_64bit_looks_under_x86.mdwn
@@ -0,0 +1,12 @@
+### Please describe the problem.
+
+I had "fun" today doing some initial configuration of a laptop with Windows 10.  I remembered that I need to install Git first, so did that first, 64 bit since that is what is the laptop is.  Then when got to install git-annex remembered that it is recommended to install 32bit built of Git instead. Oh well, I left [a comment](http://git-annex.branchable.com/todo/windows_support/#comment-c1b06cae15fbebf97d58f5e7a498b2d2) and proceeded hoping to resolve rsync issue if/when arises.
+The problem came upon reboot when I got "Windows Script Host" error "Can not find script file C:\Program Files (x86)\Git\cmd\git-annex-autostart.vbs".  Oh well, indeed -- there is no " (x86)\Git" and as described above it was "on purpose".  So it feels that some "recommended" value is hard-coded somewhere?
+
+P.S. I really hope that someone eventually takes time to make git-annex become available for Windows from conda-forge.
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> Made the NSIS gitInstallDir probe which of PROGRAMFILES/Git
+> and PROGRAMFILES/Git exists, and use whichever. [[done]] --[[Joey]]
diff --git a/doc/projects/repronim/bugs-done/windows__58___autostart_for_annex_64bit_looks_under_x86/comment_1_b8a4128b08ef8dd25a8141b27531b9ae._comment b/doc/projects/repronim/bugs-done/windows__58___autostart_for_annex_64bit_looks_under_x86/comment_1_b8a4128b08ef8dd25a8141b27531b9ae._comment
new file mode 100644
index 0000000000..6d916a9325
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/windows__58___autostart_for_annex_64bit_looks_under_x86/comment_1_b8a4128b08ef8dd25a8141b27531b9ae._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-01-21T18:26:32Z"
+ content="""
+This is not making much sense to me, and the fact that the link to the
+comment that presumably provides some context is broken does not help much.
+
+The windows installation instructions are clear that only the 32 bit build
+of git for windows is supported. I don't see much benefit of chasing down
+some way that the windows installer messes up when not following the
+instructions..
+"""]]
diff --git a/doc/projects/repronim/bugs-done/windows__58___autostart_for_annex_64bit_looks_under_x86/comment_2_0f23c377b22788d9c540bd480398f47b._comment b/doc/projects/repronim/bugs-done/windows__58___autostart_for_annex_64bit_looks_under_x86/comment_2_0f23c377b22788d9c540bd480398f47b._comment
new file mode 100644
index 0000000000..fc036c0bac
--- /dev/null
+++ b/doc/projects/repronim/bugs-done/windows__58___autostart_for_annex_64bit_looks_under_x86/comment_2_0f23c377b22788d9c540bd480398f47b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2019-01-21T19:17:29Z"
+ content="""
+oops -- forgot indeed to add the [actual link](http://git-annex.branchable.com/todo/windows_support/#comment-c1b06cae15fbebf97d58f5e7a498b2d2) - fixed now.
+
+> The windows installation instructions are clear that only the 32 bit build of git for windows is supported.
+
+Windows installation instructions say actually nothing about what is \"supported\" at all. What they say is \"If you installed the 64 bit version of git, then parts of git-annex will still run, however, some features, including tools like rsync, will not work.\"  So here was I -- exploring uncharted territories by installing git-annex to see what parts will run and which wouldn't.  As I found no other report of the issue I have ran into -- I have filed a new issue instead of staying silent.  If you feel that it is something you wouldn't be interested to fix ATM -- I can live with that. But at least others who run into a similar case could find this report, and I guess it would get fixed when that roadblock with rsync gets resolved.
+
+Cheers!
+"""]]
diff --git a/doc/projects/repronim/done.mdwn b/doc/projects/repronim/done.mdwn
new file mode 100644
index 0000000000..c298dba684
--- /dev/null
+++ b/doc/projects/repronim/done.mdwn
@@ -0,0 +1 @@
+This bug was closed, and has been archived.
diff --git a/doc/publicrepos.mdwn b/doc/publicrepos.mdwn
new file mode 100644
index 0000000000..97ab9425a3
--- /dev/null
+++ b/doc/publicrepos.mdwn
@@ -0,0 +1,47 @@
+git-annex repositories are often kept private, but here's a list of some of
+the public repositories that you can clone to try out git-annex.
+
+* [downloads.kitenet.net](http://downloads.kitenet.net/)  
+  `git clone https://downloads.kitenet.net/.git/`  
+  Various downloads of things produced by Joey Hess, including git-annex
+  builds and videos.
+
+* debconf-share (currently unavailable via IPv4)  
+  `git clone http://annex.debconf.org/debconf-share/.git/`  
+  [DebConf](http://debconf.org/) Media, photos, videos, etc.
+
+* [conference-proceedings](https://github.com/RichiH/conference_proceedings)  
+  `git clone https://github.com/RichiH/conference_proceedings.git`  
+  A growing collection of videos of technology conferences.
+  Submit a pull request to add your own!
+
+* [ocharles's papers](https://github.com/ocharles/papers)  
+  Lots of CS papers read by [Oliver](http://ocharles.org.uk/blog/).
+
+* [rejuvyesh's papers](https://github.com/rejuvyesh/papers)   
+  Quite a few AI papers read by [rejuvyesh](http://rejuvyVesh.com)
+
+* [MRI brain scan data](http://studyforrest.org/pages/access.html)  
+  `git clone http://psydata.ovgu.de/forrest_gump/.git studyforrest`  
+  High-resolution, ultra-highfield fMRI dataset on auditory perception.
+
+* [gst-integration-testsuites](http://cgit.freedesktop.org/gstreamer/gst-integration-testsuites)  
+  GStreamer integration testsuite media assets management
+
+* [ccc-media-annex](https://github.com/ntnn/ccc-media-annex)  
+  `git clone https://github.com/ntnn/ccc-media-annex`  
+  git-annex repository using [the CDN](http://media.ccc.de/) of the German [CCC](http://www.ccc.de/).  
+  Contains a lot of talks (mostly in German) held on events from the CCC as well as other stuff.
+
+* [ifarchive](https://gitlab.com/umeboshi2/ifarchive.git)  
+  A slightly outdated mirror of http://ifarchive.org.  Scripts should probably be written
+  to update the archive regularly.
+
+* [datasets.datalad.org](http://datasets.datalad.org)
+  A large (over 50TB of data) collection of DataLad (git-annex) datasets, providing access primarily 
+  to public neural data resources. Organized via git submodule mechanism. Although underlying
+  repositories are pure git/git-annex repositories, use of datalad tool is advised for more functionality
+  (search, recursive operation, etc). It is regularly updated and enriched.  
+
+This is a wiki -- add your own public repository to the list!
+See [[tips/centralized_git_repository_tutorial]].
diff --git a/doc/related_software.mdwn b/doc/related_software.mdwn
new file mode 100644
index 0000000000..6dda61df3f
--- /dev/null
+++ b/doc/related_software.mdwn
@@ -0,0 +1,72 @@
+Some folks have built other software on top of git-annex, or that is
+designed to interoperate with it.
+
+* The [[git-annex assistant|assistant]] is included in git-annex,
+  and extends its use cases into new territory.
+ 
+* Emacs Org mode can auto-commit attached files to git-annex.
+
+* [git annex darktable integration](https://github.com/xxv/darktable-git-annex)
+
+* [Magit](http://github.com/magit/magit), an Emacs mode for Git, has
+  [an extension](https://github.com/magit/magit-annex) for git annex.
+
+* [git-annex-metadata-gui](https://github.com/alpernebbi/git-annex-metadata-gui)
+  is a GUI for editing the metadata. An easier alternative to using
+  [[git-annex-metadata]] at the command line.
+
+* [DataLad](http://datalad.org/) uses git-annex to provide access to
+  scientific data available from various sources.
+
+* [GIN](https://web.gin.g-node.org/) uses git-annex to manage data for
+  neuroscience.
+
+* The [Baobáxia](https://github.com/RedeMocambos/baobaxia) project
+  built by the Brazilian [Mocambos network](http://www.mocambos.net/)
+  is [using git-annex to connect isolated communities](http://www.modspil.dk/itpolitik/baob_xia.html).
+  Repositories sync over satellite internet and/or sneakernet.
+
+* The [Isuma Media Players project](http://isuma-media-players.readthedocs.org/en/latest/index.html)
+  uses git-annex to "create a two-way, distributed content distribution
+  network for communities with poor connexions to the internet".
+
+* [Densho](http://www.densho.org/)
+  uses git-annex to manage upwards of 10+ terabytes of collections,
+  transporting them from small cultural heritage sites on USB drives.
+  User interface is a [Django web app](https://github.com/densho).
+
+* [[forum/gadu_-_git-annex_disk_usage]] is a du like utility that
+  is git-annex aware.
+
+* [sizes](http://hackage.haskell.org/package/sizes) is another du-like
+  utility, with a `-A` switch that enables git-annex support.
+
+* [git-annex-watcher](https://github.com/rubiojr/git-annex-watcher)
+  is a status icon for your desktop.
+
+* [git-annex-adaptor](https://github.com/alpernebbi/git-annex-adapter)
+  is a python interface to git-annex.
+
+* [git-annex-turtle](https://github.com/andrewringler/git-annex-turtle)
+  is a macOS app providing Finder integration to git-annex.
+
+* [recastex](http://git-annex.branchable.com/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex/)
+  publishes podcasts and other files from by git-annex to your phone.
+
+* [AnnexRemote](https://github.com/Lykos153/AnnexRemote) is a python library for creating new external special remotes.
+
+* [Git::Annex](https://metacpan.org/release/Git-Annex) is a Perl interface to git-annex, including a script `git annex reviewunused` for interactively processing git-annex-unused output
+
+* [easy-git-annex](https://www.npmjs.com/package/easy-git-annex) is a 
+  TypeScript interface to git-annex (and git) commands. It can also be used
+  by JavaScript.
+
+* [rf](https://github.com/apuapaquola/rf) is a minimalist framework for
+  reproducible computational workflows in which version control is
+  done with git + git annex
+
+* [borg2annex](https://gitlab.com/hxtmdev/borg2annex)
+  converts a sequence of borgbackup archives into a git-annex repository,
+  storing nested Git repositories as subtrees or bundles.
+
+See also [[not]] for software that is *not* related to git-annex, but similar.
diff --git a/doc/repomap.png b/doc/repomap.png
new file mode 100644
index 0000000000000000000000000000000000000000..dcd777e1254698aed16dd2f6a2804b69b5e9533e
GIT binary patch
literal 67316
zcmb@uby!sG*EYOo=<aSLr9nV?P*OUCA*H)R5D*4Lq+7bB8w5mhKtei{?vfS|2`S&r
z{rsNievbF}{`rpY8({C*bIhJS*R|Jmu5+z*E+RD574fjCu>k<UQ&y7G1^_4m{3F9e
z2Var3QU3<+AfDQaPk`!C+FkGf-9klC4)}Zjlh<C71ipghrexp=05~M~e-I!eixPYh
z!%JCB9%BIom4tw)EU?8BfS`LR%gO5c&L3oBq>(<Kt{spSR7%NX)FNfUQ5wZm(oU3<
ztq(^qim9NJL6o5dc@{69>-lsB%|t^BDD_M}B8X7fe&3y$?vGACk`l^pEx*coH7Z0`
z!L@un9Wj?2{-1}^Gi8xEH0J+2posr|#{B=s)4-(Mz$@j~$6Xi&;6vbBZqS_px;_yR
z5d<bW^dL^M;8_ZHS;ixK=7$d-Qa9#!j*9Jl-p)ztdM+m?2aJ#WT75%M&Q;T<-Tr%0
z<^B`2cEO_phwr8NcPoFdg9Mu+!^1Iw7CNA&c^&&~Ea*;0S6BDZ!`sfk*D~H~Zz-^W
zf8GG@A|wBK4!-;UK2WGuZJIIlugVbjb}&xq^w@ef^~v=G-R$2U5{**zZ1FM*Q(q>w
zp}T&WyL`)j)4)I0xA52!AP<~Ba0BGoVO|{t{WW@C3D**KoaW{oVi5Bv984D~L2tah
zzNm1Tt1r`k@mkpC*s$Ht`+1|o^Z)B~R3M!7@XvPcOng|!<$BbW@CW!We0s^!l`o0?
zj;f0Qea#8|&?EBCX29jVW6f@~hV+<g`q-~r>x>nVA;n<mDP7>3v&)&zyQ00RiW1(A
zOAGJIWAk=nvEqO3Ah>}d3e2IaIvP?%e!q9}W$}tc7M>DF6|VUINVokyp8xcDwejcQ
z{?79a6G>-bcr?0=4pYA!+e9sT!c}<?J}a+3J%rch1uoXSkdZn;c@=cMu+k7Ud-HNA
zg=gwRoOJohi#m(951*GO2WD@b?S4~S0#C8e6^_g_h^_cv(-aPb%U3xsG*K7+7|X4h
zt~B^C_@1j|Fq!j1PT-aORA*4o?Q$}w&ZFNZfq%BHu935q1|J{I5}l?>__zqWulL|W
z2;s)9FRSiw$81Nl%48NwwI19qv8trlt#TPQl)gNwHw}o*NHY55^1MQ?N*f%+<n$Nt
zYn9^gHp86f>gAmmo3*5_4?cPrqXF`Aa;Shj`1=$MW?YS!KK!&&ZBnWF6@5Os(YY%G
z&0d+dPadZd5}~dFUh_~86~_IVn+EZPSSb-RcdH#7hW#oE^k@6U@}mmV-N~XeKMOKc
z$~uMmXmRho()mV572Ldk#ts??Xd*0tQX2!(dlebnZ~+lD72@v;+P<j6{qZ&7>Dk_t
z%HeXmM3ofd&$Z!1m}=XL{3maJ```i4Ae%Xx*Yv)tkh9Gs4TlP=cldO_9a(~ERUt44
z3|vIuDuTc!H~_*Z<CFE?=VLii-<DhNuJ(o9h%n$~+N{pOC|3y4O79-rj0=dMaowNO
z?J;5?25kZhfrd>w?qUN22x)~KlJ9uQk>2~$_WX}MHpAx|>~-cnl%No5xX)nMR{=7B
z6uc6+0Z8#sfOJH}mQVyaN8G|E*BW+f<1cd`ZD+`3PU%;e)W_Qt7EL<>{xCz4Cma2_
zXA3<P(3hh#1{g31&f3nzhi}V5Kdr^8|Cd!7e4osed{v(z>Y5X%ez5XmBy+0SedD|L
zj7bRzuWBWO-sfxypK>e`HoIde=AY4y*Vn(dC#3w(?JCx~-{PG4e_Hmd2!p{$9)Ib6
z*BE;NUrrOS^ulEtdzHPJSZCS4x6-#~yN;*KZ!Tp(E`Wg38?dLe+D$M!^Uw-fDT!Y+
zmi}v=rKSI04uCxH{Qv%d|2GH!+Q@&O|Bu1^KOTVZ1x?9ePv-6<E)S8A4yCuV$;I08
zk^7H1gFE>Rz=s2QToZJwB6YFoxd+0EK405$h~I8e>h~eO&Pvl)TV%KMAIGFC=wEFT
zc^|c3l!LZh*627>e!r5y>8{QYune2dbZJqJVURIh^4*BBuUQH>9dQ6n%uv6^v`WNz
zzVPMG#j>&M&f7!Rs|x}UtAgTIUZ3<*oQc;;|Gm5D6#k0I^1q-r%&ZXw$TI8Shb{hG
zYMttfp_u}g{!|DW&ZFA1!v+0D*A>(IMPII*#8w`7dsPmiZn@vtUb(|mdAZF<M!9Lb
zU%C56U-_%kA6Fm2`~Q6&#3Jtz;hDnSP%M(~$7^4{<q*(5)--vw_1;k8<w2=olT#UQ
z>w(}c4aJLqy1STr7yuXL{)*lA(uBJha0om5AiNP#GpF(x6}z+^iZs5yetCvOAt)`$
z4K#GsXXL=XcNF*D1>6;r9z&kMhzQ;Gt3H({JWzB<duY<qaF6kWDLk3te{W8o&s3XC
zoz1+cnXWP_p%1!oKg<1lqxkxCM09V#we$H((BJl}lYWM&-ESpRe4RH1f!BwkXV*ua
z6+*V7r80MyPjA6nrImZi{l>aZHRbPqO=tPNul&o~`4@!K-LpS8r(<U?A+JB$jA(=2
zq|sqKFL*GCJ#IM#^qGoJt#YMbf4}*2de&%F`3~v&&=CJ$n|O`s2cvh<X7jCl)vO1R
zs`SC55&5py0?un$*Bguq`6%+TcK-_pihb~N-?JuvR<1W>SpA*tvpnHqW#+Tk>|U-@
zqV9KH$6U`>>$D!$w?42v>xyKG-_++P{SP((q-O@qeU@=j#l@=W1xp{{$VhUYa&%nE
zJj>JCG>Dq|8FZ%?8~=^7#Pm2g0~OT54m-Ec%XK;LQNPi$AAhAK`rj`sh3${P!6IT&
zB~-*XHlJ(RE3f#TA?)~jGq!a)&W(akY4Z<_Yg;~vW?w8_h2bZcs;>BEISVGx0P-%x
zuBV5lW&c6PdvMf>Gq^+$8aIIh)I-A|*M0x+`Q!k#%+2u|glQJ?xU3{+k}!=+pBHZq
z5UCN1i%Lak0-E>S1KfQ_Sye21UuE=Z?_kzrYp^W;>AQ0F+yHHM80PO@3e@cDWERrc
zUJ!@8MLa-f<7Ggzj;{73;$KLy(@lD0t*WFBh>S`cNoMb65M_n4EQ?=W?blS`(}|Y~
zS`U`exHQYYC@Bta%;X9A4={q>nwPsxHJ$ib3MrSKY7CW-Li^dYQ432X{A!W&MZn41
zuv5=5DgD$j0qd8G*unqnv=A9Kt9tJ;OGT#5i)H^Y&+Ui8S2@1x5#d!15h;ocuOAib
z$#Mrb@9qY!Pjg%RJ4>lZ2E7L@2Jy2edlfZ)(}RjqvV&!z%snGy9GZ-u-@uz@aV<wT
z<UiBx;hB0($nSxCr*)tEe_vVocitN`Ix(e3;f>F^KU!O#NhAcO;?t*3QOUV`V?g10
zD_Eo@j*{sBrK(<)VG+2nizLc0|7(Fog8O36Yu*<f#xqAaWP{8J8~t&PQMwVttX^zf
ztEb~n33e|yoSz)b-;)y%`Gp(Wu79@L?|0eOO;hFLswu2`T^_G_9i31rJurYeG8lXu
zz0jO*+8WI^@?jMivYT%xbJ^(ot0Db|WyuF&wYbUBmo{VfT-0uy@s{o`^A<CF5~~R0
zX)PQg0`D7AJY9?`d$B4AWNvE9HS<IKK$c`|iS@6otJM>~(QET{Kl`R3(>rn)r9wR8
zaX8;Nl_ln>8%56Z=<;Bt^F?P62)X6plHB)nT5fx_7lOk(juxLiz7_h`|L14+r*7h2
zJL3ib{G*MUuz5GCu>B;<ZC1-$%yGvY9lLb$mmo;g2gdwlW$E@hT9(2)9{vTFxgxbR
z7pl=Ba0ijArOGIlR_yl?Q;B-^B;jX^UTnO1C$4O1Vspr&ev(>~daDRW3+TU#D#;1b
zW7r6SYjchaJQv6&VOQVTz9B$GUY+fieAej%X~RdxQ6yB8gcn%f6Mo`kywu`-X1Trr
zO+_iRVC{K^L27yUWl|I*Vhvk$D_MwMN3SFPkY0j3`5g>gTnnm4<o(FAsFK=PI6s$O
zWhqb1zkVKypl-|J9rgVRGJX&89aN~<LX-1Y$ir>hx>2ebw)DX@AkXu2yWiR5F%c$W
zbOo;%^h2YBv%WFpE;hFyIyW_pdGAij+ip#^qbRXVuq6QDH+R=Z;N5v5E@Ake75mSk
zP4$PEu5+qhB1SV^JIZoTWgY;y=n9g{_0}r$p6ff^5SVR2-+O)2G6}oKJW1;2L60|3
zW6TDIaDg~_sf_bQEW}Oces$~Q@&{Fw0?6_2-EY*uoauj73dpy#gslfjg`H+=!D(#P
ziV%{6aEnI)(pmcX!0P5e(wS$6QPDH9!{Qh;fL_c)t}{+0t+|Iz;$^9Z%&qR$P^w1%
zpA&zzj7JkEuciEcgWly&d)uqiJrMMX&4~}8f!o<WUIim6eC?Z&a)kf0KqpxC!4+R(
z6ftr51$ZhMnkJse0J^i1eO#!thSXVdVBB&yn|-&^*5LbZ(-^%T=!Hvu`&Ht_1mU=B
zRs<3xO7K|E%-Wx4`!jrpV&jTo{CSF<mZ3c{WjZB$%l(H7pJuQ~Nz-0dr|OjJ*HkYD
z{k?72zF6|fMdvN){q<{zZ$|k6k`kb4&ORYcG<kVA&uVQ3g5-Y@=)d|Xgl3#CI@;9z
z!c)z9g@n;-+RqK&3)!mUsi{8}ibMHpYqK<X(2l%73F4Z)cv>bw>6HD!pwk!j$-w4l
zx&5BDnoKdk|HWNa!e*yAL1!#Uw^f+&C=<6mTYd=c+*=%q!M9`>0;`Hk^4!^=aekZY
zblF2^1~|Zo72p6k_Lzm`-(V2X(<YK}(dIM$ij%o34ZK{#$WCS?mbrXjnNcqUYYz_i
z_g+rmlKBEadLBq>vQuDdQ_ILQ=xa=C=WwIK27)E+ot*V1Y2^PxS5LGLW75}^ycG4e
zWAxqwtf_XXhdiGa3uO7f&x$7W0J#a<xk08VWQRW<ySPMNko=ExRI3+UOFUB%BQ(s>
zdPmSqBOTD(L@U6Vls^xKFiX(GJ{s5WXwd@}MKXNyF}vLfWbxrW3^!j3=_Ot|&AaEv
z2{K|Df2O(v=lg!r!8N^+JZ{craF_I576UVuiQflgLOa9{Su8Yj@e!1QR^hxg-98+3
zAvCkUV}yrLX*v6FX%o9}NVO+Je{qb8`!k<Fq}SQ(^D%ZNGGa3#lgrnd-6|LHU;jH+
z0d#4LcHk2@o#po=Z@ygA3<*3hQKx&};${CF#4Hm#Dmx=E?5p<a7Z5h<zrf?SK_?DC
zf4nJrPY<JL^{Wh@qili8$Ggd%u_yd3zsHWmt6zmJr=t?yG%Znl9dIM-R9=&Eqc!(o
z%}=fV{{qzqR4F!flG(pIAL1N*4(NOq^Si3S;G|{SX`(>BktTJ05Po(k`O|dqO`kUD
zL;kd}6RG5!4iHduJ}AabYZ?^DVVNwywIXVXFiU@^T^KH{U#mM|zp)V~Go9X<4``GR
z)^y&LSNW4}u#senM|d%C8aLPSYMazq$ls><s)|PprwKg0Ap7C#rcUWt^{+SAus8=q
zxgBXyi~}1$zg(F%4SFMoR9-;gSmqeU#xdUS^R#Zyx)7a~0i=I;Y02-p4l$3bj6Z8r
z#Pzj1RlY+fb{DnGH|z-bytnYF#^v<o&(GU?<Sq{sqQ~htvrL4v2MTOa83TU}u>a#p
zz7?wpKek-^V6)O-|LwQ*Iy^D{i}cpt`@lUvE@b{d#VkI>8_D!G=MVmN1jYKjS^SrE
z^w!(Hp|5_vSQjUCp4L>qw)cS+2Z3bK7^;n>lW^E4IPSI55X4xCu<7<`Nidj3A&|@q
zCZ-TP2}WX>JqcO>3A0vf#>XqE<qaWjg78fVCz8WuJ2VVrGPi+tDi=uK;(jWEm}P?(
z=k(40sJ*1)=9kJD7+W+$*Pk@%YVRL|gm+4B?8`fXeJ6*(y5U@z7ySlJ4pYw<R9dPZ
z*^R>(UaSkUt7Q~kqh_W!cg2>SKCaUcBj2B?nK^#<JU&f5k8rhkiS7uJ05EN*ctP(2
z-TUy<OL>t#NhmI2ZhyY9qNz5)EZCong7@SFe03*1ii~4=ze{ddoba2d$EFgVHT*rC
z0uenEoCaqte*EH#-`8I;T>hW|&Bx#}*3**;vMCqAf}!PxjSha<wSnfZd%7_tZ?<Lr
zMmS!#!2TS39P`Rzt=2bQ1o`&lZA>t)@evGupC!4n%tmvm+i|CzQwJ_~OLFmBH0l<i
zb4AbIPrCI8+gjYz&zEG;z)1~iK)Sheib1()yq?9ZLW#pXZfEx2+)@tUADxzB#Nncx
z7B>FS;|r#ZRE=Ejvsyg<NIZk4zHX8#YrY4ccnJYq0Gn2)GGGT8jN&cHv`-cJo^SdZ
zi(fY470MG%Srk%p+1A_hg(>iUG@ucsiVhIMzahA%>Gr8$T^)rlnNoV$)G|uJn<J^F
z93n7yhyG~9Go{y-<L#FVxC@A(!g560N(DGW>~lq6Y;{lc_do_XT^A2us7+hX>Gg9=
zbg#9d-Z$d7PP`D)zocKl{{73S$327Qt!7G>fDIKq{FCcS^_Xx|>Y<rG{O5h-{$n(|
zVkUjeL*1=|b?_Mo%>RYYJN~`B@6O82x<Vc*#?p$1x&9bVpSQ3i7KE}d!PUA)x6Hh|
zEzr0jP#A$;hgoN;l79YN;A+}yR3}JaejuMIb|GP^eyJuC-Y^wig=SSw0$j!CU^c%h
z0!H(5Q8Qn1_T*6w<aH>SnaP&q*Bq(V*rT2+hrkER+adp1!$96P*$~z=xv@W(9-6E(
zg~z*nF&AJavN%7O6K}$CBqT5JeSgHi+U;6v+N{Dkr46R*oF}^dnp~E|Zw;iAhOgX5
zuR=g-I>R5*_)ynTpSe<(rHzs+Z?`t#>#b!h>q#Cwibm9>a%lj5z`T33Z(OW=od4pu
zCxYZTNG=+#(+_)N@ba_*!{Fm!Fk5yXZ_h}OKjqHK0>i#-?zoLG4@oV{3E?dV)x>zM
z|8f2rWN?w`N8G-u;mwe`a&zS_zqkG|_%tV|?PmMEmW;ovTYpXpyii@Qq)>iP91y+W
z(6=Vo`xeKG@b8b}gXhy|6_op777-|EiQaeaH`CQ76_yVmI-{L%gI!!os1y2T>FL)I
z9M-ph+2SvF?a19%Fsgj0Qykq<hs;(N#6F2%v~t4(&aA3DPoFkJ@(JKyBC=V2Bo(q*
zzy`waz?jxM-*IpamFpqzR>(i301Y6iW@C#}_5c$G;tDa;&Z^N?{lqo$VO+<(J@$hI
zJv3ITZIpz)Rya!8L3e-V6Tesu2?)vOETK;#1*mEPR7Tm#j561qVr^FBM+iMiaC3Q5
zV@{t%tJ~U>*Og)v%7l?y9iG!!k6?D(0nOp=Dk%Fbya`LgpD}LCv#qjKMe4PPwH}Z5
z*bu*j-LTD#CJQjfCQib@5OBIKt$DF7=aklN(+330e|#y4o)Z;X<<E|57w<24qC4Cg
z+<Y(wI=(coY^wJs=uq1ySSRku!Av;>`#1*m_bF1sNTX3_#;s^s%g)5_vi0ch&H&j0
zF{RHB@}lHO5*y9I=J=7!O7E9!Bk`Q-i<={&E0tpdR&dQ2Zz|Yk#;Oe#>pm41^S%Nc
zb(<p}^LuC^{PDCLGTv7X5vTna#>#77Ew(sjldH3tl^IGPeF=Mgdp5HN5{qe8pKh``
zmPn8@f&mkH<1YdGwT^Bnc^qM5XSmVJqvfil=cDwWBQg&DNKNBug1O+-rmXSxm|x75
zsUImlS=`Mdw3~u`<<7a#;vp1l-l7ydHn|v3#%GnZton)V%d|ezD4)2j?P@cq92<?U
zv@+9Vrl*W$0>a#|T<STho{Hsy{&kOra@3aid98)#N8x}=H|O0#`XbK2k+X>21*_Md
z+4$6tl-@i5240~Rl2lwyC^Fbz)FTW2D^G4_xMt0!v1kD2P@3m3YO0LQ{csSD<)Xoo
z_t>&74Rd!6%-g`*T^e3l7O+2fuPmL8MZ3naQ18B>kZm71lr`g)PlEG<?ZQi8pB@(o
zp3(ZC@VVP#KnzjA0PpQqND;$Qbooh=rA6+>F@6T-QuY&-S$cujNamAxI5Jo!GLpm;
zc%<z_Qz2DXYb=9!u=3$M!I9;w&H4VA82M~U`E$CuobP&@mnaFyU5TT%59YrvPc~X+
zMbFqlHhdA@rxUF5Pren&(mdj(qvb_eT0n{}yaY&B1~uy^36#+sTQ0dJ5bJ6<(ej$s
z^Ff{yYZTZYrf{e7xxYX%EcAxDawA+^^}_`JV01G$pFGxIv~m{Shco~SEY5DGo+uk7
zdT#1&-FU-ixZjCnl%UEAE0FIy58trH7bYEbT&uSxYUD_kfdvAbGtlkqNe}n!4UJ$~
zqUH^#QCKnvQ$d`%$(u!}BrtLE6@|7RnGN{G3#;h~udrJ#cv<G(u3fAI@zsJ*3^L_3
zOu#$@Qht88P=azr)l-Mguc>2*GNfEk6%fp-dFjkX%SLT%*xbb7i~HOBt!m+rSW2E6
z7B%;4(li^1bW~*kDQ-EK*8JKZKrVjvbi8<wtqpLod4IZ?vktPP`?4orpuij@$zG11
zM-t7Eq6WnlRbdn1Ct5`ve+`nGy%^Eu@omXkMRMt)6eWBV)X&w*iEG99Ll5$lUU4Ma
zP{xJFpiV0<Gw)}Nkq`{HTeiB{dY*>1W^KI7yqT@DoTpZ9?QvULfF|Eps5;PK?8Zd8
z>f_SxPm_NmJ>IbLz~iRmd@#D4(P$x*s-{+y?4C;&yQZRf&V$9r)Z|3sUcUC3aMzZP
zZpLn97N1cq+O_M$Z{u)CXPH%&c(!#bv1Kv3anYvhz7pwB^36tgr3b_ji*m$AJ}15f
zs{{>alN{3npH>2mj@Vs{v9$7&@wbW*a)~xOMQXtwmhX#E$>wHyo+t97+<eOqI}&_}
z64N}2Mtomt2*5zF;YYT*RRRrX-6mhMMH|2QF2Q9JpMSw~q<4RYI|{#YJ0f0D<dL<w
zT1;!FiESjqVQ|-N_KzqNOi@{G{d;%qy+{lEY;^VvLv_O!81UPLyDz&Nhr6=6Opwl>
z8}XT;@HjEdkdJQ)r$tzq1b?mRxOxVbDE#Lw)DHMpmC!{55)h32bo<OX1i%Ex8Wjf*
zVZ`enVaWw62NLr%+P^S{9&8ix9)L6e3kHG=HqhdjXfuvd96rSKG-Wfw3atyn@VJ(K
zZM2I{ae#dB37gPlg<c2p+@eQ4L)^_u1;fxH-N`N6kLf2Lmz#Mvix#q~$Wc%mi3uQ?
zV=E?I0ZL4U@6?4WP0HU1IR=b5`eL>cPOwEqL??S%*K>-kl0FhXu8RvTKc-Jn?zZPh
zm$!Sz`R(a2E4kXa4EdNDS_c|6IFV?;gZe=?{b$)Ci;?i})tz^KbX;HLQgO%K$i;rh
zm=K0vbP+4p83A7#`hN*tijmC_!&J;9^@?F!TqHM<WLypMeIu+6-C}*;8!gv8L5nel
z`}EmpKaJmbAH9)SYKm+)+E|qI+KGoLM6Xg)2)oBwDR|y#y1X0Z^;vX(*F@`Ks#RTX
z*&i!T8tRzq9^c<w`&p}B5R2afPYYcMsd=A>;Ah#w_dfkGA|91`An{C;#ZmAjd0a6e
zpZA|xjYS?&hwn-&$|&Wgp90V_k-Oot0aQygAqHQfty2m*8~RR%nvz%}S$hsyo$3ci
z*;1k{-$n6Fh_XaLVWHeFMr8wa5X^yQY43p;T7L_NGV^D?_}hR$rmstB)qt3C;w-o-
zh1)u>_A2(ks7GDjkNqQb)x!x45CYH<qm)AR`{4p#iZG4StLX-yGOPGL)YoCSTG*2o
z?^&ittS+z6Zid~>T1&J05NcVPHbwRb&w5+2mw|Hx&7a-2Eho<WPENrJ+b(nx?n+_+
z6W0Rl5UXIeWdiL(oi-Lnvxb`t${x#6+xfiX)eW*-$^6u@rd@A_pooUVy^;l~xt}-_
zam02LdSv5uvjxWiB7G@=^wQdv_*vN-;x~_7rsZ0zvsl$RCZIQN{n(cfIXGJk>!ilC
zw5=lX&%ubgp6sOOW0tFwGX&eQx#t-Dxw9P4ynS!eJZ{op>ALQ7M4jp3nJIFHKsF(w
zH^a$47<PnR<f@vfz!)!(W*FZ<*;9bWofsOH8lE{Nx)Pw%njWlL2iEf=!DK+To{ZqP
zND98{C}Eu)5rZP5+MD<~6&}84{NrEg8M{Yz-$O?dTx5_-VEtjKm2Ak7!`cDxMs_<6
z5a)9&!IesnwPX4!v6V;`zP?iXVcW*Up8)J+ZT``?AaM9SuzAG5)P;J%kHvwcr<(9J
z4_7X{W!a{V;0ndniX(~=Wlg+n1M)$-8U>6etL2B0VUfbwR4Jn6nyiGVDpk+FQ*8W9
zBxd|gBW&<K@G#~;l^WQ5jGr8VSt89um1afkM+D4CBV<0zDj={@3pl0Z65L5tD7awH
ztm>RRD>>;x{AnnoZOby{Q1U!IFv#7QCT-zt0YT3c`jcM<_VDVAC54h=dnCb>1YB_O
zLgj#17Cdu%(kSp7DTP4dBjQ>`)}`ET*(v~j7gO{wFx|PgccXgT2i?_o%+;y85>Q%S
z@0+9=_2CpBKKX)o(Cf^8ndL#@Wr2Avy$vZ6c&r~`u>SG8Z}imBx6v5udisbabdLkK
zQym(7j_CeZIoyC3b_&d5SWcS)^D|YRF5dLhbvdeyUDl;q^QYN6@<W~EJcc``p_B%}
zV1^%peB446vA{SQM{TMq9Z^d!wlvc0$(i+R7s@7!j>6_IV{{$T`;!OED!=D@VR|7f
zJixtnps`AYlNT{n2&<}d5QwL)bt4}rE{v{g5hGE*3|RH2B`{UYzIFKnW`!@ZhM*#X
zS9GUR9|L>vAZGBMOG#?@O2R3MXd($<Kq0+vTw=CB2^aZVS)-iNg*PO)^7_K$Hd`(?
zsFF)m%F8pqLA$c*XaF7djUjFReKJeJfH5GD7I3-t?uvSw)|~s%;kCHW&&s8*lpLkm
z9A;pk1W>-63jV8GQIbtWqR!0Y)K{eV4xi1WGB5%=%qJ6yBo$|y=F9lS2;g3m97C#S
zYrIgp-j13G{}fGH{jwxnt1Q9w>{|0#f14=C%}m%rE|fU(Ls9$Dd>$3OwENIcCvI({
z8HholQD@QHpiQ_)tC;w5XLqPx2|dp!Bv`%!qXEiV$*|pG|IwOs+%rdrg>{WyCg8F*
zFn3m|(uO<tBI~5Qq02JY;yLor3R{3=9;P6%Aj=sI)-rYu@o${h`I5}hY%`nL>VW=V
zer|8j##JYqf7uUlkbF`q4e5>dbz4X7f>E-D(_<`!-}WLrf1zXSVx9MZj<Oo}qyUfl
z(fCmREvf6V;9MNsB3y_iDw<NXUOYVwh38S=G*ZN+CrE2nETfPd2(!-bdx+5!U!*AO
zWEQsl+n#M2UDI;q^p)`_z+m<WOsL<AachY#`+nF1^A*)q;r?M(Xoh-3amvvg@}I!c
zdV1SCw8ZV?B*vz9{fnPZjlckm^n);<)MXYq`^yMkfaj~0BWYkuhED#uIF@SP35Y+m
ze8Twjv3|9&I1Q1?{C)ZP`ZwW^Pj$4=5P*Fy3bpv-7^js>9`Oas3e$P=3OnSXfk8JQ
zR+Ku+SND)?108roBKS6DPMTXvP&rD@f``SFum)YU)QZiMZbQC1N&Yd0GA9(Q0YMRv
z<9B3X;#R7wCy}Dq+_Sh=8BZovuaLp%i#h}AwoPRF7<w}E&Am|MTq^wM4q&lZfy8wo
zjTK0eb|D3T3wC+)VCj-x92J&T%SwBIc$*O>56Ji|eK%$qiaWy)2S*=J%r834Wforx
zm3EC4D$)S>xFee3f9SV^#W2)x8NJzs=GD!}%_KoNz#Vt+7Ml~qQ6xpqcp%FXQRu!=
z-%%-ZMuY`p?<3|%BOSS0sWty%px1Bp>G})Z@XN<l=cX922XM#7>g?)S@m;1YHf~=Z
zD|ldS(45kWeq6L0Z~X)21?#_{0y+dhOfMD=L2sx#MIX%_fQrI)V*?gazxjRhYfn~u
zWKa#yo@My`F!s3z&h@L=T61b3n;ceOHezc>ChvnDn0wLeSe(m&v<3*d80*5bd{~l?
z#plY}FfO&i(2yTG1*=U_5J2|8WS_Q@Erj@0?XcKVCX2h-E0KMS05rDXT4}070&a_D
zrx!uD-nVmL9=rrXk|J&D50-g<2Z_@>z95)>GAjE7&+XlYxDDN_>`Z2Mpk=EVHC4o2
z6FwaCevtsMV{_*Itoof@BZm|xMrn8ptO-q>684^)c)5L1yTrD{-Od85_BD`kdof1o
zXq)v>vp>G@Pibau`-#I{tFdI^5zD_}YVyaHxrFTfa<OEjQM%k!xd#hi5klSQCJRvd
z<_lv$JU}N9<?erTDTA&sjl-1zfyL4wdc;E3i%Uoef@j*|gyXkPUYQL8jGaTj!dY3H
zVlUkK^Jx8b;8~~nL4WV;$zdr}n20_Hssr@5-mIqIu@FC`P!O(dCt>Jn=zfTlmA;}#
zZ^9v#>1U>*hfqAPb@U$s3(n^;Mx%6#-)P_2jnaHF0Pv2@srtlum=iH^m}c-T38!r>
z-f(92rpYd}4tKCK13St%j43E=LE^SO-S3m<<lYjO^vb!eUk}S=L>}9k;Xby^UHuiU
z{|g{|`pt))2IyIeSa@%RnS){u@ASn*wb(-8#*G%>w_vT*ElX5iUiIdV!cBn>s@`O|
zuYjJ;CwzCkwXfcGS!m@8T9n{gCMAp=fLd|CTd(`!6Ky@gp(n+71<FjQpo|On$LW+$
zQ{GM`cK<NO8J+nv=E=SOL*jsB+0&3Osft#IyN*^7B^b2RZI+=XBK?OXHA)4r_-HTg
z&}c<UMM|7zb5;cdm?kj(4X_Its1p~M5K8YI+8Xj05Mf1+QqD|cWur3HkYDvQ-1@rH
zv-b=)JN@g1HRpQ3?)S2!I};QH{8TBCv6z6OM7f6vJw6m~F{;_Q?zaFT)CJ5~#3gb%
zUQKD2lIcsYm>00MrmhIY_lpzi^!o=)voypv_TxcTEaTBGRsS%V#jSX`ptwC<$BOSa
zqlJGX1PZxPBe<<NJ_el9|8!awB6rD)-G8@&ZZWbwt5J#59|}hJQTBC;s*L0c^*D2i
zF7?bGJ0Yx#@J0Arqw0YekdBy%>A{*+TbKtzp7b&Fak(I_&krlM$NnjgZtL7Gk^;ZO
z(c&-p*6UOaVtwByny>deJheqn1a1}!c)kOHYzCF~@LM3k*T6Kp6X(GEGxQD@NIY|3
z`-?<H*%l-64Lp{db;k`@0vLZTATOYu6wPtaAfeeK)SrAP2&yS%uW72`olipZ<lBMn
zmh5C71083or^wY9`Lj+34uQ+tixo#l0XIJ8MAbiFBtHcvKdKif1j9CDKX`<}(a-=B
zJVbFj=>R!=gX42If`RLpe}Hb0)BNPip`uOkpCw)IQ}L=t$&APrd1Yc0@rYTz8}vF?
zpp!G%$zi2eB^yW!f34c(b`@D%@15?6dm$l}o6SUSiUuo*?}|Bliv_PlFuT;_YMX{#
zy&v{B)+lozBL%!Zqq*H)or$l~oq9{I-+VPK`a!*W7MxA3O?3xYqGLH6tPyMU1$J3S
zIVKO};7<DfZQ|U?E<JqEmq7SN7adl@8oy7g62#FzhXaJiEA<Gdd#gl+x5CCH*+RoM
zi5@a(&T~&yg80vi2DA8Fi>sMTaTz7wmYxoWi>&t7a~5?mW|teZcg^o=iKAU`MTl6X
zu~mG)dP5?RoBt$uCOH$I*a2~<D}5Br8lNe}9b6n0I|CV4E$FeGB-Uiq?5Tn&Nr*qQ
zB&twdlI?cUhM<Gfh>ox+z__!Ul3&zsNa{SjZcYym&f}=UlBPJmRx~sc*xM&+l?!vO
z=gFs~F??_@uIV@^QbmYli)+`#S}8oU!1QK~=o~q?IgLac$E;oj3m;l+P@<VHj1jJ(
z#zeWQM&g3eBepl_Z@^)pz(`0!z40%jL=a0oRS;3D_w~m0(lJx4Q)>i8l2}w95Daue
zA*|XgII07cMTL-)+`u<34%bAMyL~J%R)-`o2F$`N4V&JAb|}K8n`I}*4ZRK;=_}t%
zK0seQ?Pw-O1%V}`LGvKOd!0magf4n!HtFrE^$kM>q2bCu36HNUqH*HYB1pdtJxWm)
zsjG()XFlO-lIwx65x=aJlW2Vxe#a-0+AP*mY2{VrHv$beGqDXI!6ZFNd>%h3keq1I
z)(v<2F-*0R^#vRa1cv_0r1j-)NPAuFP5M#Nu5M@G>m_;>i>gT@!<}4J17Mv=?bn+H
zV94shH>r?}z{*byjPbW>DMEU@pQ*%*KI?(>T$1>V1mz-u0z#-y?fobSlmw*{%1NRH
zV>)xT`W#ia+gUYVL%<q-5-y_e*SiQR%DK;;wyJCd#8h9+dW$%doURT`>;2qi))Na@
z5DS%oUDGra)Mr$jSex%GA;9{N-<D36m9b*xG>e4m#Q1s_<Bq^rtAR$vymmN5zU|>K
z6APAh?<$z*0uw0{20+AVx4a5_s8W((RyFhR)S`Wo)I(+ZU7-Moh4Dep_uke#&q|Xn
z)tm;AQ@<Dm9hYJ-2gkW$&PJ;FBTXpKcL{2Ti2L=-DK0!*pC<%fm;T~2r!DWv9$pM!
zmI#akG;@Kt$MA!KU>P=O<-6u7j+z7m;8l4rL%b{of$`d-^8Sn;!u%rrzM$lY`nWv{
z`K5z>F<&u`J`o`9R-=<j+=XsN<D4@C8On*><7`ZFay>(gmtP2EcGw_0ptxmIjF1#i
zWd?{Bp5}cD?zCIXK-Jd~35$3hDONI8-lv-@>S}5dHLRl78NCkKeHBI4TQO~dpj9~l
z>-K2BpP&W_UbtsxxS{c(Fbdj^(hB<?o266ANfHEO=5r4V6!&K7GlFqF7GQ^de9w5D
zI_<cFvV3t1Rnb}Enx%4h66BL1(%AbRK4F<l1lN7Eo@PL}hmE%mY!)ZIyLp`xzYUZY
z2e<K8&fXW?-+mOkyN4W2(+w~~lLUtmy+EuEB(ZzTM}PveNHk3rOQ6R>(b56^w^F_M
z$o5DfQh7V|VBAe*(TY?@`JCm1%K!Y}#DunRjy&?cg|hke<2#nyc>dLMCs!c;{7vy}
zliiMc5?F;&t;pW-1`5COdQZ#A-Jphmg~e}g$2zZnO3WCcfW`$Nz-s0=PX|8jW5T*E
z0vw8;mX$$e$vfsvB;l9`Cb+0;4=q=~5$hhkkU64RSKQrsVr&N1#dMpT<{Db)DwSRq
z993BX?-(RrjY(bX;L4q6r$XYDPr&;7xcg@-iKy^P<sG)}vp@HWIBo=U5QI@U)a@ID
zBjHJe`vsAl6ez=SK2#P?<wLx|nb=jwICm@gHuA=4PIrzE0Hz<I1aU<0y6~Kji1WZ}
zVU136+5rEPB1K`nzo3lFcODvkA5zU5KG7>`4w1jH!Ya(=A29k(;8np2-mYL^w$V}l
zd9f;0b}f-IGc-5o&sOTxR_cpt5*ls1J5}dLEf#>d*H<L*vrc1VT=!^mkPav0M{%Z$
zHmGdXz(DMz@E92{SW;X_5^}s9c%V_x)q-?C7X&h}-20-bS{_7)hp#ZkQ|gxo+$TIN
zAgb2+p(rRKKgAbQ6V89LUXuW-y;p&%0W4mWUpc{YbQl&lCL9gCMjt6b|9fi8AP%ZE
zmj<XuG?=hwk9el_P|qb+$UWFJmqX_IK<IFqoap4k%|++mDbr4HLT9~Gz`z%E08ex=
zZ=-=3B6|7<OvRMl3%|3rdYt~2YJC`m(vdt(j<j|?KU&Gf4@dC^#X{BGeKGsm*vX1P
zQsbG)G>kG|LCK`I7&j4-j3M-%{N8Kv?rXT=X#DT-r6Z}Dtp*bBD}k}TlOH+=4RUTY
zzW3Ny#schT+i7jD)Din&HKqK}XQ@cUX})l}(x^nQ(zGh2#<+}}50q0H)IE_gb#4#b
z55sd9YI5HDDdq3A<z?K!{qB;F+pkY8eNN;gy|r>>Fk9lnApYsi0;mersm`kvq6%{^
z(cmvK&mxzl&n%cZc$#cE5V-B@fvf2$smi?tX0xi}$n>5k;?H)HKIp4bwWoWyLef`j
zGeTX(vb^Xq#N!7QZLu04ZnT>y@Ty6=32h~C6Iih}psDmk^^xxEa{qC$V{!|sJa;A)
z8un3s8Td?3Rq_qKtd(l(KNlNAkwIZwP|kHV?gG0O%J}+JMx#J^rV@8vINw`=DsZB!
z>!H{H8{+Q1%IDu~^BtQvd4RrR01RhH1na1FEDMUF2k~@@ck*5j##)V~YFH0t>XQxR
zzL=_S_<&|MV>MQ-U?ko(nNIGj+Q4vn^<K=Q6n)xf&@gw)f3C704VyyGyK2C()O%)Z
zbFAkuv<vARbWqo?JDMdX)Zmq0My>JV0Jkd$7NO0bjAP!JhEII34Qje8K(+P06%~2`
zC_T5Ep%En)tK0|`zpxM7Pn#%+4{T5!waWhXG##!t=o268lAIAr!ltUE^NeXYLs$ir
zB5^M5f3N%E(Cf1U{~|2Q`Ji&6k^uImHT3Kyz2`cuflOYCggy7#y=YXvPC1hCj^ryU
zv)GFp{C7?`CP9Fc3-{6w!$_+v;});7j$J~c6D}OWnpk!XZUm<Xa^SnQ*-#~g8;1$-
z)sGdzl0uSdKu*GHqWto3xyq%M?Pn7x#oC)GFUl|^ab-}kHENlee3O#Xpevs*W9T<L
z$<A$JzRRz|_o*R4cvsYAMjekqNTI6p_GSALP|E2;lD4DSV5hZ2jF+}r(EV()ANK_i
zc8ffbom0;X03~_UwZKC}wOXdgJYB3ub;HMV)@OC@77CnEZ{EjmMlDp`f^OE-L?O&F
zX!9#kc8oHU&b-%WH4chjAO+or*MWTu`t4vE^=h$KJiIp^LbgL^nJob}b<AjDY8GTY
zKrp+%TMUQPAlOZm9=p~`u0OL4@_g;yQKvDC_tr>u;yc9Z7U4TeQWKYYFWc;>mY2I3
zM2)rv32lcuw)+>nOu&qGEe?xjADtKrD1Zwpy)^5N?X@C>OT-<tnv>I#4ksy+ePVRX
zLDOeYz<QOxmkSxwFlzZSsp34OVT)r{D@lbzIM=EA3*OM?G=i0qWo{~j7UcfkQn)V!
zy=P*g2fkA~3=z2(#_;zGpss4qd6N$|{k`0X+XLG^=E>d&H)!Nax5O5F{>%ZYV9@1>
zs{m_cyrp?d1**hYqW4cK0QF`$;8gATP>cCBI4M#=w4XbUnm6#%<>UgmqMt6-Mxl-O
z{{rR8djnhGHWnMGvomW9f38e`AQoLy!l5rW^-9>YQVZ}gyfP(sOR=N8nV$4lvZ`%x
z%70RB-5<Mmhe1E?qi(9o==RdJYfvtR!{RXfjpd{z%<M@?#{=@#`}QBTbU}Ha*Q=iJ
z_F9A%ACDm+F-+136p0sAMZxblbYmpadqPLEB`Uyb^R6Wdt%tD<*dX!}R0qgh4|3J)
zI6j=9+6m5v)jIrYnL!Kh_2AmB56|sqDi2QU=z=1oC6F9%4c#@UB2WSM3oTLp#Cm})
zZc;=KnAgyi#wk}Yx^g5A<}+S$u@^Az_1<@I<j|w~WcU|4Gr*#!+42T148%1{aKA$R
zMY0gl8wdD8#4oy;t!bN_7m9g8d%jHGw1axr`NVLQoK22u15cN}Z_g+(5w4&aXIy{Z
z-^N{ykua6(so59;%SshS@7Y>`7SJ%*@LOJ+O}TfF^8&>0dQ70frxWnD%b!tv?S+1z
zW^*uwBfkkwc-Ht1IaX%NeOpqLx;0qjAmUJH(gpv%2n3J%KCAS%n(#OPBn6Rm4w`K=
zzP%2i!WxLNg(t?$RXKq4x|eb^WRT-#zD$Qb`z+c!UNauf&WW~<hWnVv_25i^R8%Sg
z#>^Z@-mQtLNQ9FYhx%7~IvZ4`3NBgE;{zG76v>a7@Hw@S<{q<c)=>}jn`@gcUlCmi
zPGWHLm~$#~1(T;*S*<_=dN$1Im?e_1oHoBE$Vv!fZvHW9Ze<TlN(t~Ph1@BN&ow%x
zHW8xRu=HaC382*b%7P)W`O8SMF&A^7FnNNTBHfJDC>9hUAeqOZ%+P!dWi<v^T0er^
zaK4)iE9+)~S`x$fbz=*Mt@_!E+^*cYFr5_jrUt(l>iM@BN-B&=B!34g(ay)kJb&zj
z<o3rg%*>fWUzdsDqb?IB=DpFsmjJdr#W7QolDCk35Oau!3Oj8j&FWV>^!@|3pm{NQ
z5)pOAk_;2|P$b>*l7pd0HT@#2i!DSGGEVw}t%6T`h&<^@?sEGSnRH0UFw8BcXzHQf
zcWc>oEy8&##CqR@jg+1k&>r@%(tbT`4nRAXd-Ap$l$JYS_82Pq&|tstba_j%M>Gum
zdPG<fzKw`QF|Ee2W9vuKaDqM>YYJWIAqnvN5(v8bZBIw4?xfF;)ej9vOX%WT9DbrB
zTKmU3wJd?0^ma|#EUI6S0G{#5tSimunZQuD;Zq{(XLY|1=5#K6yqeAg$juTiyLAdz
z@T|p7qyvNZPwxqIcRx$ACQbD6XntRV%_dZVgHG-pS<O(r_0V^)TFXHZ9Pav-*PO)<
z8}JJV>9$s>sElUO1z7B8XO7fFmq<l!%;nRBf;y<}WS<qn<ZX`YDT57aw=`W3qaH(k
zd`M}sTQ)xWV#hQdkc*YVZL)Xl9<7n}m?@=$(c@rN;9it`iK{*BUUcbQxN`fm^=OhF
zh0Ne}PU|nZFFaH|q{qeIu$NTpp<Tm3{3dftx$iA4t3qU~h|KNpBx6VB4r`3WK1>>7
z;CE@j*_3{{{kP)uKsH^#%B+7-F3gdIP-h|o85r5Ue%_8}KhZtQK*jxTCboZ~`*9>z
zz*=|OceNfgg3E-7-K<b6L2)BD$Gr_Yb|AVzo^qwAFBkHmGL~+JUKmI+U)vO@E9$}W
z_|}DIqF@PA0PMIYlKt1yd`*;c%o)PNFUf%Wu+23O4UqB$Ca}pK+EJL>B&l!!Utx-D
zoOQB2Bw;w*JmOyCy-6Q}O9ey<mz;KEQe0|ZlrWyU#*QuF*v-YsG<EvS2Oiq1l*|sL
zoAcSq0|52oBGyH2m2JZ-3tZ#gh72y<W;flcwa55ihfmzkH&I5s6VL;*w*@=GDQ1zf
zH2KKKXQ&Z0`OyGc!N}*Y{wx##K|ro2@t@z{G`w3MU7bQjk2?Q$1ZG>uOP=0yp^LAN
zeehM`MRs)}uFGu=)=Z?b#XVS!^KKJs*d<N*(yo<br-o+6EFNH6;bD#!w#ymVccmgz
zoI*z~KK-`Ek1Z=?YjP!(+psAH_mA0esM(?ALMpd`2RWb(r$Ih(Tl<K2GYvNUco!%z
z0@}%Gg^_aEC^j^;0Ro(E8wpw%iNo9o%>HIjk7q!R@6+mrKfb5w(k6HF5ERotGbHkX
zAUQA`f7X{BrMwSyfE1=sB<VMMf62LASkXmuu$9Ns{OqK}g{x#RKLBwlq06Oluot^N
z89Kkl<KeN})xPfZ6pIOg1O9Vkf1DuKCqe?@7;U2&Ju{U?6wf1KK<ezMq!ecCf7tjC
zR9MUlBXFW`pVXO;iV<u2)_?+Y`y(oxfudB?at~0j_EQQqo>lt&45ze%DFz{j)$p(3
zZ8ejJgL6BUmhCPbA3e9#Z|Rr#FL_zjJ+?=yEaz0?Z05^OBml3xaq|b`&%S!Dizu6#
zN!13PypFWW1iLut`&mSfTO~1KQQn3^rr&MVj#e2qKEpsr{y>kqdR=K-``Q8^#QfmH
zpKU;#t!W+@#SLeBXI6(yhvfYU1m)A;%;qYf$VsgMDpxM%b@sKe+)N_~i~xJCC4bTS
z9TWj$aEHOIyBp!=y;RgiXoniDvmOf73zdM|i})j}P3Yab+e?|)iyf2zQ(WV&8Uw$P
zoe84P!D8s}x3yNRLwjIrvpBqGSPlKw0Ya7M1#0E4gjA0axUYlpR>#HTM;~M*p;Dp<
zwy9$fiw`owQ}F<8*O)QJ;zB$oynueHZ;@Nox@Fq-fYJ<>VF^{&vy}HZkA;B30Q|UY
zJv9rl5!>2usxD?Li^VKxGbG+g^ohot8K4xS?wp+?@WA;6B@R3Ab^pGJt9m1?l3O<k
zj^5@e`K1wHh6_iqpSPUhM!Do|!R31Ro|F>N6F^{b27l2(4Y<eFttJqUMUWTGa_)L<
z;!`FjfMB=9UCosRj>l91{tuK$nK!_y&9ys!j0pZQjmm=0KDid2JY$(fZ{)6V&Hw-t
ze2OBAHALpk7ED{OP`3<mC(RK-$SY8h^GnCErhAf!+JFMLM(_9;2sR1=k)HtOPvtuQ
zf}*EvGzXyQ6&`>pokjc%H;)7u5w-#dFNF0Jk;JpsCULZ4iRV-uj+<cj5%!f)PdnPn
zcuaIe4>WQ7Y1d0c+>Dq$F7S)iv78232Bw&(5zG*n@hrSv=I@QCM%*VS3{i%~(r_Ah
zk8Ae`pXeDBK@Wu)!lpne`R0)o8UlAm)gw6wq%uA~m#b|0sDMr{$)j`#a7V=qEIZ0b
z+XelVzdqR)m<_ApK3x20+XG<21?t!w>mdL{<lDnoO6ha5_@1B~8W2ZgayGN``a<K#
z=CG7m>HuH(0Kkocm@)PoF)))~B>S7aioA1!<^_+M0cjI~U#8ZK**{8+7Vk7C)fsCs
z5bUQyL~YM`3Hw_xu(41YmV~ZH0B1&kI$ues+7{avWdt4IJhfb>O2P|<`^=py0fbB+
z(k@kNR-8~S)T2Izhv&jWGQB`+##8FCYCq|t5kP?%$2G6It;r`g93$^;_Z(VpR2q~?
z=MD;Eg64nfn%3Ctvc8O7mQ*<nwSyQt@ojGbKp}&>fl4O4WybU;T}nzMI1@4|HFPr4
z%oO}9Ok!rgcP5lGZy+#6=k=Zl@pLpth7|MAX5mpOi&iBEq_zzZZ&ld(vqhz||LS8+
zFcV_}Aq1#-`VN0S#14qx0)4o8=U6?!hm1bh1~G1beV#kX8jnhl<te}t96Clg)cuFD
zvPDYyK>)fB{lXO3mHG&f^!r^Zeep+X&uqFvU!xyJ?e>72=xd>!heDB|+x9Q|>zGlR
z<_IAVh|l5t^BSRj2qO^=c(GfE*~zO!H{#dyX)6Vrgehj<yxE8WIk2~}Fz#Jyl`XB&
z6QM=3_hdv7MVNq}>JGZ>f$rnpppQ@(`m6Q7pe&b0YaN>8uZ#m&Xmz}0iCq+_ocj2p
zUr>KJ(7CPX_5hV&*`Em$faZTP%oqziYGd>U?6*X^!jw&ARua5v)rgg97C%oN(ugW#
zL54RYw|ZHmSp2#nK%Es4L4RP^WOUJBmOmR26zGw+Tg>T6IF?$roWyVeU@qK%RCcLl
z_9r%+v@J8?{l(880|_{~q3_1W$j3Ll^THv6JuQjZhM>UOYajO!)U7WjS4&NGdIHFX
zJjo-t5HWcUyfFRn4Li>U8MEcC>Z@8n+DV~`P$ZTG#L=gb;s}<B<0Vj2yE}G5&6+iQ
zxAo_~K5J>=>6=rTVntgqk|~ODNJxwgWSpj0r+Lm*h%T*wQH>#P`Mov~Fw;h7W|L)`
zaa$rXfH3}i#wH)K`(VWQ(DQ7HdYO2xYhw)X9meK;YT)vSd{~2<N3S@#DMVfe9o@H^
zOww_>GIZuI4mnEN)RAJn3&3doJcNg9_80VphFnRETOz-pQ6R_AfRjJ*D-zf*0`e6B
z%RZ}FdR|=|#{HPHxI*%ps5+~tfBH<><S7Fl3@8m@0}y;;w}kV*Qzwpm9i_ZqlN8xy
zFB|{5>M_m_@ahvs<se}!KlLmonw3b<pi~gEO4bJesdA2{Cy^shoqs}82o4+A(W`D)
zRR_m9`J8-CL{a-+;|y&sRa&>Nhr%MS*P99uE-cE7ecrG3>3mAbwHiWB1#fshH7Krh
zFkR^2$q%4+fNh7~QjaaB!+D}UJrC#Q?_ugQBIh&BN+IG-guCZRfT^QK_1}4bq$uqo
zuFVvNq%pAB2DaK4*{%&#iq_>P_Y+~>H;x0UrG&mN&^1eE$Yw0V*YH9VB{RW+<NT*n
z)-PYYc+WhIJWJ7&K5FA;A60t4wVuN+7V?XUMS<|ewinM}Aqz3~F;kXA&trT_epo-1
z>Fcv8``(qOVnJUZu+xQTJ~sNviYJm4Rwz;Tk~KE3V-ev-=Il+-?jxtymyzqFc%}TW
zRv)JGzp5`+86eDkvYH#~T%bm0LbDDD3?|n*=SeSRLFdo6c+OOZSRY_!HV9_eCZL*6
zHTH;5cUUV<MCElr*nB_dAt#4ff$jSChj(o)d~-4^kO92Zf9AD2^cQ(?r=27af1p&)
zn~rG#;cAwpI*!^L_>kknVs^7j;!{(<PpqvF=7IrN-@rn2nGwQEyusepB`*bgkmh^`
zV*{^Sv3f&!ZJKi>$}jEyJL61rj>^u8&lWUCQ5|#3bf^Yi(eMKGE|0SM-|ks=g($0l
z{{rA%1`~=&wo{fJHpFI14zoaTyri!Dp<fu^y$PE({-{@_t0OMyOAF23SNoF|xt&un
zy%OlZxY&^&!bl>9^#Ih|j#~$CBt6+BXETb#%1p6I?+OW*$&2$~{ViKufwcxr_Q<y!
z2YUp)v-q|n%QUD)#AqVW2$=%98Yq94H@GYrrs5Od_h$gnt^5(0)xb$TU}2KQZ~jDX
ziK{+@6tKE$dsVJ9SMN}Orq19?dbM+0w=n4$MXDv`cdq+4vO9#BkMR-DZK=DW$ge!v
zH(o;ie&-+!H8u)SYC}?c-dwud{~wmlIxMQLi{f{NE~PsLN$D;nL=X^=5*WHekOo1@
z0qHL3Mo=kfDG`wFMkx^_1Sttg`Of%$fBHN;&dj~%p1aT9YyFn{o?yGM<+%`(j6d?F
zY(lRacGcSraFkP9jKvxhnQ3!fXgR=aM@!Pq6HO^AnJlZ<*dP8A;qAVB!Q)_WgM}i`
zi^YMYI0&O~`9H9uwl;F!IDA<YZ-oLqZ~P=WHIQ-`qCV~`ihnS*#zHd?XlD|6xI&Le
z#H2zja=7B;0>h?MYQiqXP3fZq=g*WkA|hC^PhD3h6hp+^$U92x+<=op7t~_Yg^JOh
zbV}vg$Y9B(5<;z3=SR1&<S++4C5|Z;IlD9lM48e0TWbA+sJ}5Z!lZDNr%ePER1$6C
z_mi#OcbHc9gMqMandcMHVR+e#FO&^P3hTI%v7^0I#zLpGV&21bT?$@^$puE5Y{H}3
z+BJ#a*Ss>)dwxF~agdIAEna&fNhZE8$Fu~Rb(<bB67rLZFGm>BvYILw^#s;xbuZ&&
zYPa{&bEWWG)}ld!Kd3X)8T)}7V_a0?r@sFn?+1GVG7~-JOZcfhw^I4-TnLeSs!`rb
zpKKk1P=KS>v(4{p9<A8?T>99uyT<cROiWG1d=fwN80a5jeC3Bh`{$Ox*IqK{We2|A
zJ?OR7d_%L7k&~mJzR|U8yjyr&dFpXi@rAvT?NuP(_6rlom7F^+xs_&=>TbUjGzRFw
z%99GL6J~ivUL3akdu`CGOz5QP=ig2@*}c}oI>jejQ}3Fw=_~K^ggw1j`sn9n%v@=m
zq_!!4zr!`@5vQj5U2+DNJ_T%2n8L#t1*@Ik&Gmem5rY_C`j%|XNb_*U)<*NpILOC>
zaJYFY_U%cO_{~q)dV{S(bw{1V8OD*&ZHtiTxk34f1*Z>-?8zzr9&Z1TcBe_y-6hKQ
zV%4-#F!So>!DCJO&5jy8H*(RvUvX@2-=Vt5rTaLGUUCXS&_`+1JUC&;8_+xP-bvNu
zZM)L9Z#Q?^I{p|n&rDROK6@Ranjy4RSfZ}`J_uv_E<pr}mF&)%9s$#Sj}#myWxqg%
zrX2^F08JFDQh80Pi~kIPcoct`#qnN?J1@Mg5Madv#^HMyID`0g&Y8WxaCp>vwz}-T
zDp}KeED=wJc1ImXp9(k2j6EdOXBxfD-?g`&#Y%hdJW5VyIrBVOj=dejzV;HWdkg?$
z6R8J@zr~JlZcuO)kp#ZX;uCt?^s`e4D2Df*{NcX1L0uGshv=0tYjQ8n6t;__l?`m&
zy+0(=>wv?Fmav99r(4s{MQB-{HE&l=>fJq&bT(?pSlRxi;}K(-`1-poWc_IZt7mX|
z^!dZ@PygGk8gZQ)W6leEXrXHA@1!w`H0k!RUdaQ&@dTB-ekV`S=pEfZh0%`-F3+yr
z^=(Hhuc<~}slEbMZr!@NxZ+p573NP8vn6$J$XIcwmJx94YUfCK&&-T~Ld+Hy>Fl*v
z*yTHZBLOdBr&m$Jb5oOue1y`|)`-xW3}x06Y%&nEY)klN-=(e!Wocl|0F!NxGz_EQ
zdOWr(Vo3@sJ{*-bGoq}W?-gU|h8w(ACaGX;H194)R$FG)xV-i1{XOJ}<W~jEBH8$f
zGxpkVa@Dyjq`edbQ)q-m?_w;yr1nc5C?-04_x6a>FyYcw{y2n?@5CS5w&51oz?m`m
z?;@n*Q<9)K^f0XT022pJK%|HJ;oi+;qAE)sq#C{2-NwGEK4P-^)ykHshMoCohAi>2
zikTOTdkv->e~BC^2EY3ut5L?~Ce@p>bS?x;W0={0wr4e3@Tx1dE;B+Hc)Fg_&3Cm~
z_yP6RcFJEwYCL7|)blQPoAQcCOwvQ6@>MiMDJYkfd?tJ~sK&Hhcs@3?8~M2^$*ugW
z-f|ipygZEFy9mjW)BI$T{o~W+p);x7UNm+E=o`<Ey;cZju?M@?)WbORbWc7RQ2i|`
zXWH)fJ!o_L&~k9s{SK7Wr1s5%pJ4STnZ{k_gUVZIQCqbKKO)5gA#hhOi2@R`SgDK#
z<3;;ZO>6RfNFD{0+>Kh*hAXArD|V!U!A-b1sXD0`2$H-s4h=>IeOoy;13k{emUeo9
z=r#VYsgF;}suv>JZ$QJ;O7^J3rr8jQuSnL-NVGTRHBlInGJ+#&Z8@C+(iW}+7QeaQ
zx5$hyUs(;c*}{u)y*Ea3>gj4hOZHrlPuqA3*@kKxTBz@N_>hOD;v<TC;4yL0gM~~Z
zOPXq1QZl7sDTL@(XD!PER|*cH0~Kihg%vH$Pg6?E2a!$`|GoJ#j^oYI<4%c^!4a?n
zN|BIZDfD4d`F-FZ4m&1D6E#=rBq~OZNN&*Y%yf5#N0a@rmyqkMsa9C-<XDPTp`m({
z#nU7QuYQ5H5ms(1wB!kEFSK-FuEeDridOTPhp-j{OUmS=m6*8Ut$$Zjki^$psA{5D
zIJGjd93oaF+kGI5Rmwr<8$omb_NU-GsoLDEEJuJWl&0RHJ{Y)B``tP)a};_$<;+?T
zBq7_*zl4QiiTuW@6|Bt>Letny`^1ofl%UV+o^f9GMI?q?k60xU&yp!6=|*EU*?&LM
zu(IvkVW&B|9-J}NhNjp)YqO9U|4`v#rGO|>F6<W?tI<r9M`F;F&rJd*zD4Dg1H!uH
zhs81Y87W;(H4D~uE_QX5Q+_Pbsa~E&f5>MNU*C))>9};4;h2F({20#CPdh&-?G4M~
zODg-%npH%rR`vILQdBtj#CC!MP3!CdOsY(H08+5;VKE_r(=;cY{IK{5iwa%IraMm(
zr7Mw@dQljy;>&(xFRMtB+RAK~DK?Rd_6ka|Bx~2T=fxlM@}LCxDsrqf6ZdyFmD#4F
z=|9wm02echTYnPU6S;I{$hxy6o!5lHI(U%!1VwF}L2g>|j6sEHDyxWC2rE^+;|H>C
zL+BgMNHv!>$4yOU+hM0Q-|YM--B`;$%sw)^jT5Uu!O!@8qPLuvyWoh86M%q_mUbqa
zfB4<~zlT4f{6!z=C($1Mh}VQA1ZA(Z=SX=asR$@XQW%zKrDv_YxBd#8x_Z**n?-gM
zm2t;=R?-;foXcwZH~Fo_lVjv-!c}bD{M?*I0uUj5Y|eYfzr>-}R6<s9X`vx}{6>QR
zEE35)gr$vxD{SCE^HA*ec7g+0{^Z1i7@#|!e4{a2F<rHvSP|_-{)c<aZmy&o!&yy@
z*)5P9&M^}2rSgp7ljh7>+r{oAGhzArG`Xl_R_p{GpGp|4wF|Zknum<DZu}&cQT6{F
zTf&^K?q`WPl{yx&5kMK3Zrs{QU84}Sef8=H12^56k{|zqB)LY(+AJEfRUkmZJDEM$
z)2(XDKlVg!prW^{oXRbMl|*ZWopN{2+S;l1Q*E;fX)G^vYbvy>d1w0IqGhjbGUMvM
zm2YtqA(H0;w4if`)&@`z(Rt2!h08k+zlcA+p!qvpY0^?R2-aUQXM}#ysZd4dY59};
zsc*e7gj8smt<pV$jy+l^hFSf_oMZoXw&xjDq!h>_c78T86N|g9K*WR9X#`w=r6V;Q
zb=%qeUwNJI{bt96Lf(WAu(I~$KPvKL_xyAuZgZ#VccS^{XW#X@)$ywK(}iw${!o6<
znprDNYhzNC4@Qo|WTHQZ&J(jceXZ^tpT}Yd+&^QC3+jS{UF!v)66^%NIeAC5h89WS
z8Rq%_jvNd5S8e#npC!c0oO4!s#}_~dvZY^NYrS~o5nW|^GLyEknPH8`Ra*&-_ih@R
z(|H&7|58uw9-!IQ2UgW-fVeQ>9_0;9y5FB&9LjL<>iDE)ZS=XCg!o%^JHzS79x7-!
zT`8N_DqlbJHAhs-|8E{o-StBSVoy#eVg=qUzh0teX#isy>rx1zZ~&YAlYTOC1fzs&
zejI=2j${4|QNCqOWi$nMiIHWZ{|be&<>JqxXbREXjIn;WQH{1z3^g-lJEj3dGQ#1!
z(8?9!A_8i8d-;FW_)*I@;5lZqUM8S`XvS`P1rJW`kP)kJTe~E+22s4yb8Kg-wnyPr
z>WbGt@aP%VnhUKFT7Z1|z3>r&24r_sKFWUTiJqt#jh|oFgZy{uXQzPe`R<+6WZX_7
z5`*FY)`vkS)5Bj8lN3o$A<R-&CDP>e)WDjaEo+nuIJr5rqhNFH1FRvAX{Ry^ZO)F7
zl(>ONWSMSR$?UhT^XD+3p>v&;wbsLt$=;55S8L<LBfWLn{V3I?L8$MGH#m%#JnNSf
z^L@gjgc~jacm~9w|8Ck$@F1yUR2Gx~%R#1=RW=V$?3%FC%Het6ZV&fLN|M~3shB+Q
zK%NP4y;%`^i)?f)0Ij05FkSv<^52aCBA{k(bydRD+Ct|>AAi55^9LwNMHP?z4Kd?)
ztg?KXmL`&bi=7W_WXOM)(XnF~RDcB`gwzF~^+qv}DDabm_AN>ppV#U(owRS=Zk&Al
z3Q$yRi#?Y!D>tlQ8}RM_+a+pJrpLSU`#4EA^0>D&YAxPf68Tpf=2|5-ITClO25URT
zKy;>mu6GLg<?iwF7uNTZ6jJ&BE@{S+AnB3DGlxPj^AU-v=he!GTbt{``RuD7@TdpD
zu{;rflQm>A^x{WV`IPK}@#`sCJb$i4c4eB2V<0UyUlI7f(N?1ujI*|nrjrnaB&>P}
zO`<39P-t(xo7bny-_hrQoHf}Lem3g3E<I39jaGdgdmPHd=j4fx#%c$%yGnjvN(aZk
zFFNg9;M9@M+5~Vl(|@lnObAeo!qf??qGuMmodfcBnGDj<h^NZM+d3uo+f1o){6|T{
zgxP4;8PTI;4vj~(CBE;ZX)j((m+Cfuc(0<TQh$OP&J>-zKxip;=+Hn-50vBF;pSiq
z@ML-_FN>S!`izkIEP6I}LW|YOvO3qQUTjY=br=XTcFw>(oRk?PdIXSnfEPoc*$DO7
zy~Ef%ZtMB?j&^JK%Y3kVNx}<hKMM7EkDS4<o@g&r3TV6c68qgP#VGrID|2k@kNEx_
z?H1thI2WZ-@WZ-s!m66cS|<-sy=ebx3(}=JE!90q=F|QaE*0*KBlp_4$$ie(4ypn+
z`nj4gSDlB(2zhA@^H>RoA1*I0vH~BKSHa}w3~$kiJslebD8!09;U&#&l7cX{JwcgU
zXjzMCIFO5kf7}J!poeeumC&5cm%jl_hvV{*pfS`X-@B}uRbpSE+}HwR-m)gyT&y&?
zBdw|9nfB-7=E|_WAI!Gl)edl&z1e8*K=Q+o#s_Lu?+9fV(#>CWTCzgavXF>)XAFs1
zz_BhZw1mdT<#lvomoukm3Z+W1+z%rhpK-uI8Am^gMid(o8@gn!5odNt^w#vrKWI8w
zTNg=k%0J;GzWv|f^6_TfJ$CzBwcVXqa@eEaKZkFpXDhEP<@#>jMg!ZVIX#rrEo_a2
zTJ0XzpFWWnEp||TY$0#)!cWxM?OR*G+?FDH`Bdk{n;X;l#$*DV#MEX$qAu>7Km?KM
z*!A=SoC^=pf-?0_;45w3o0zBb5pGv<x_4-jOSaK_2;{7SPLez?0osu2t-^EqCt7yC
zv>ZZp|E}46`EP?@Z!QCuw11jXE`?gm0dBj7EtY&s<p#NVNu%iQD9}?G+x27=PB?Q9
z(8t63fyionmy_Rcc<4NpQ%ip5OZEMQ+!L9CDdLRH5JhE!^iw!OFfb%S0yY*w2GQvI
zsQJJ<1y>~N>2jdWIw;fh^CJjz#%D-9p5$SZ>nd#|8m*z8Bc=QH-~PJ)lnR!S0;odD
zr!GoxR5`bxZwI@y)dBp*pI={#aHJnL>^~2#?cc=0y}CitvonaLz>HiTjh=TDs_ysg
z-r5cox)b?$Io=vmw*I3B9V8^9Jrn?>m`}z4(WS2Lk6Q(;>;28c9X0sR=`ww(<vTzh
zsR{jHUudGwuXg?3`7^aU)`hiG)Y_6r@t?DPvL8)@K&wYIAjE(-`=ji1zDMyLOwqGo
zu6*=b*<38IfT^Tb*_BHzrAy#ZrijXi2N>xe@v9rxjp`kW2lst=pRkb(3==x{0z_ed
zTVxT|{>z&(V;3~cwxg^eh!nfC^(>bOX`J;_`s>kb$>ftIpr6RvmHg(B8ZS5~Xk*T)
zpiYW2*eSnx=`7Ldjpv=1>iX}=wCh)-GD*=J9RN~n?gW_@Ian%R&7OU-;vL}?ld2dA
zVIQ4-(Y|LGFB)-fL)*H8OucdCPvOfjKUnrM{$(O@@GGwAKU%F&0w$5r=*O+^_rCC>
z01g)2NzP25zIWmxWQe7Rk5YTqzEnSJT2?FX=Ali+`>NcZrs-3^ChO+HHt-$+N=A!+
z`cfC%uY+P+%ti(@y?7|wC142oogv^Yef}()qxuJs)TI9ZOJ64s^0la?>8gZ<OybAg
z%X#(`)3A0#%@^6k=@>lC{VIATbH<)L-X;$^HeIBQTLl2WcWCaMQwMq9AgwPa&SxSm
z^P3K^_Aht=eFt}abnPuv`f2}_q;dfq%4+x-)%{6B(AbmXf-4HIUsX@F26tzST&7*+
z%JXIoGrGA|DG4~eI#IIkn*-ES#WPaDtedi(!0nR-$(wdpkz+wDNSMm`VT9swDKWcM
zP4a(>z)K|<hJpQB+M5ir9KYq5_RG3FAmHL;`ruKCvhYjk<Lb@9j8Yqc7@L%<V7lxO
zs`oDm4dw^a_-A_!j6W4{i$m6tCGI@tcVYWz+xWp-Q?CMdEBk?QG?=kO0Lr{a=;N+e
zqQMSC!O{1!GmTiiG+R$I9V^G*V-3QKT}Aco8JoQm`zbl!GA^8wX<@pEWBc)a>+gq)
zS8@(lq3^r=-9L`i8uFm7`T16L!Q}PUNSAuU*ja?-^?&cabJ^o*d$*MG7DEn*v{#9)
z0gZPB9^z8)3~V!g%&50!VJDuYa{l}nQ?5OYm72f7o1o4zsY#vRLCy@tSMx<hs!has
z0m*|B#Fi75nTUPqfM=Ql8Y~*|73fd6eFN1~d~aF8t1O94L>dQ*eBbf=z8aJ6$?a5H
z{IPwS(ghu6*;fxkt8$S3Z+Gee0%O!@2zpVj?`cOeXy(c1S^0!N9Nzd9u3V4l0Qrs+
zsbLG`0%Q(o49kgHcHw$~rXK4wTqT-~Yk}<30~!LII*F+fZ2z!+J}~Rg<@KR|5_`9t
z1jrnZJiQ4$vY+Vos-qeMi}X9C0AMUFsbA{=Th3VocAFnx{CrC2XzTo6lfB1P0BX*r
z*dc=jU|&*)psA0l0RjdVO%a~Ial#@P=p<at2Ur7$nIe6qwcsDF0j1M3lIYzZs;tA8
zF=uz5|K8M#c-J7iN`zwN7}pyw3+_cB<vv7Dagn=8Lw|u#VJ<ZCV!*N4Yg=#e>SYZS
zc`9vpt-5mV{-duz?CF>MZv<-a$hu=1IaMv=Pmg>7E+{m2d%A4nd7Ak4h@>XK#F#OC
zP~a9!Ia1%9smMY?Ry?f6yoPn0uSatw+&XowWWG~OX%tJBWNonXV>Bq^!<JuMUzj;{
z(26}xcQ#m~U@J>C_wy}hU-{E_w`ht`n)i0m7!VRK$}vRNktsjW6C}mEG$hW9%-LDZ
zKJ=Zbb+elM`SRD=W8PJ=_W{wO#{k!<F^gdY3HVxk(~jdJF9^|Xa$iHkmQ4hA0WlRB
ze?cDQeYl`NSQZh%0aXF|juhFnYBEOky)?7HCcc6s+=%v-@NWDMQvk7?Inu>M0Ex^i
z5;9)}xpANOXIeLe-um?G{(GtmQIx!#^dcVS+)5ES@A{mj83EMuKsmd}U7j<TEqb4l
z=h(TQwAZ)aYhz}$SDo1dJ@PWA$5E;2Sjo6;pN~a=*^j^A6$t39cHQ1x_|Wk3y_`xQ
z8$TV%>0^znCj=@(-w0ETb^s}Qixyl58ZG3q<pL&iz~=<63yCEt!YFN@f*+2!2%}Am
z>2;Q7`p1P^EmuwBn|^8C%7ekKw*%@6eL%mP-8ECY=wMBSB1n@}o))DETfMaDUuo`m
zwHwZ35J%+9`16qNy5AFYdFQY)xV}!K*B*fH8QS|2LBl>P>$&5=sQ?U;dLlyB=mJCf
zErXON=N9z`K9lCRG{UxBY<h8Cw(TuHOR^pV*pt_jn>-{my7}>JP$sgyL_N#FyK2@7
zHr&Rlni|lxyosaAE|{M(86kF{BqG9%5Vv@@f*mIg-2#1HJpc)7-hdJggPNkQSOCKa
z+H{Ak1?H=*!nq7;URS<S5_b8U+(D;)mvJycl%7VF;-LV)*W!@a*h?W2$bJSx{K-4*
z;=4PhBHP1){6Jf|6ds6TGuC9SCVq1}A(gtg>qaEOyD<wk66j08eH;dvRYd~CEW@JQ
zLMA=yzmK!`!0t<^x_1WK^3#%#oCxlPFrCGr1VhbgZ2TluH0FEfx9H&di(9ZULiffX
z09;#p0*N>+xjJ5S&~~3KyjCGI$$M1(B2s6B1;5yX@hl*Z0}i3NTi|{ELj~$0UC6(O
zF-tj2g@$X@t-iJ$&8@H?N~2+5db_GXB(W>={Kf7<lT<QQ8UFP3&n=6scQhy{*uJ6x
z*ch%DM~R@{&jYRg>@JcR4XU*=ZR<6;+W;oaer@V2d&oL~lUIJdno2m>!0e=eNh&}h
zz8@Ucj((6iq*0B3u`!MZY~h<FfswK5?2vX#(n+!b1vj|#Lb<|Bn$A5w-kg;hPWrhR
z&s*caqdZW5d~&jY$okE;AolWHqgzof&X*E^9@F2uzqDEp+!T&Bfd#nFTDQG`iys#<
z9LR^gl{}8SvpaU}Mt~tkKE@_Ibw;xwZQR-#Pd9V61Q^qg0lfU!YJqy>4?r2y95l=P
z?qewh3ZyOY$|E`tEQF0g*ia*&YHD=DGdo_*C6PNF`@XqZtF9J?6xJy=$(v94ts0Va
zx_F$63;pQv1<*K^50E=qp0wXHlVhkI<77x;)Qz1yY=b>4yBF*{%5;afpWHXm+qf&2
z@eVXJj7Fb4jzZ{sJCpe?eGsEa`R^uh45NoLW}e8P&DU-~D_ILA_>=;@@pcEw8n(1i
z3t_S$BABhN8o9f)?fI;uf`tSu)U71}IWub0(k8=ZFjcoq|NY2VRJuJRG7xAv--vO7
zuOR3K>L>NjElidTY8`e-!R#8jzX<Y=xu~_SW1sqeqI{@94xzDg&BxX?umnj6Rg^D_
zQp)-O*2(4p0IPm(CL=V(4EzQmzAJ#1z+^)2u;BYd0q>(tEom2G?uV%YDtwSR=v{hl
zLWhH(=u2CdCPn|A7!N`O6)jb^;NmCXjj)3u7Wrek3DQ>sghC^OT7D#{j&P-@3A@Tz
z&1BqB!Y0H{bgg*I6Q6_&fa?QO6={T!waFJH9zP(n$&Hl6nDPMnR^~DO{E+U~%89pp
z=P~~#y=mN&xY1(+W@=65Dym{oO+}1T%*I_i9x?H=5+)IG6aNtiA@~D{i`Ppn>HfpO
zl)b1oj$sn|^6ABOT{YQ#jJ;|e0NR4dQ9=2W?sibZD9KY7Y<Vk#PWg!FFBzDfSU3=x
z|5Yw$xnf==Bb0AVA)C%afOz=y)=s*zrdvyKj8#;0?iV`QS38?P)*usp_4N7ghdj#>
zBrHc~YqRi$$hR1ql+cgUL`|Dkg_vICZ+n<>A^v;eM~9LasG~Wyzc;DG4(|blzgLXJ
zd(bvgPs3qZiXX*5Vc^_QyQA@MF9k-u##?Y$0>KokpDT`%`Cby6s%I-M9uqrXm$578
z0;rstYj!;BcE6vYkc5XS=XWMGHgnz;9}EEnL#Ietg&DhDxjIk;#Hr3S*`Kz{xjozR
zIIrh3FXTZjyk(<<Vtb)7J}U`6!}VM1(WGn-H;EBC_uBDLF~UQ15ChaFm87P;LVt*f
zQ1M4V%8EFLM*sF<JWM%Dp~mG#omI(76CE64=!f78g<bxKCb^~r+#7s=kr)^YD*%G3
zIiepitLC>LR$!dSUOP7zMU*6Tgq>&?7<z*5+jHC<=vqdQ<YoDyr$yRKC<-|l8vIKh
zCh%v$o|q%-LIV<TXSVJkg8H6W9tgYI^%&)1gkc}W9-!!;Ie{eeFcQ=c*;d7#<3VrE
z3Fq}pFc^GuML8(W$d10X?U<f$*!qy-kO!ZP&Hzk~kjJAl)N$p2nou2^no1A7pqnEl
zwvS*h8<mBFS!#J!CVp>>=IQnFJ_dVJ<}RX9)b)ihbqf((QVfzXm<r^Y3_8B~mW@$m
zc~E-bV3|EG=IJK`8!{qP#;afzOvwFmh?+^lMWSNYcGvuxxJCUKSJ*``Tp(?qA=Rc6
zW9V{a;RDb8fp$>9a_t?#*Mr&HUJiXz#?jsV>&lQJrS+W<-roS#RI2$dEKX#OIQ3$S
z6Ko{r8Gm|;LlfG?UM!D;|9(21RRmK%|681TA+Wxe((#}YIaT~ptc5J(v~dl=iM|)=
zGokO61#ojpN^|N#CT9%ex4>i@%NfV_6|y&G0}Ux1P{DdDGFu*Aq*!qR-dou!84K@?
zN59N$Q*Fk7Fff&$f+B$M!uAog&(D0e3n+HEm~uTHLScX-1FZWHbo=u?I4)Ke%b857
zY?P*wltCj56c6(IVz2g+iHv)WAN?VRS6x|OeJ)kVz-#VQ9u)WHvS6DE$&zp@gv>GB
zK?Bbr?Hv_tjFq5y{G1#8(xbLwdlsMD`F-IaLnUaXFoisVU2K>a>N~e`D{@p3ioT!q
zt+-UCS|PBuQ=od;`OS;^_B_8=+ezE=8f+G%V9YPZ!95cVDgWYtl(!}RJ=l4$d^fku
zdpXT!U6&!k#NWkAL<o-y3)R(J37||^So)ph#ngz%(KEVr!I>{$=6X>hO2vTPCv@aD
zFDTnis*Aaax0^;A3(z|Q#mf{2_>fdDqDStoJoNNI-ajnm5ho;sTVtx$i82GuI<GRZ
znr5W_n~O=z&{a~QvA$(IgqAEnCC1AvXpFq8c$!wU<_i_!SR>D{OoY<qchE?g2FQR4
z0MNHcT1h`0Rvb9-`t?Q2==zd;c5@afH-Jj`s*w&#woUmS8JmVyI4b5KMjS{+CKm5=
z#%XBngMsurMrq&1lFJl8j)BYxQ7?~$>T??BS7n1frJ4G^s|0f=fodp*QQA-g?w=M^
z2*~e(1k2z=mKo^+qAN<}L-A<`K+Q!qn@)|2cjs)(jr?OZR;=`fDf&PNH5sO9dEHuI
zyxIlVW><j(JioRDw4f)!V7K&YFG|+h7XLu*@UMu7=|Ct$fmH-KuV1zk#1UF7VLa?3
z$9~+%5;Kij79&6m2y&xqr&N~{A{)UKi+W4C>YDU#7T4N(;Q@OezQ|e@z5T%Hy2el}
zC-wCpu<y$wa?l9P8c$!Jp>7B4;_VTpAP=|&<V+L&Z(Fnyz=aEUKx1EVa|v>HnK6Ie
z;SD9nkF_yxoQD$rcBgO(&O4H;DwkKFE*Y!k>qZFb`n0pgV}rho6E00r73mhBUVSj`
z2#Mw~Yg;(1MuA)0BO-6ziis-M0Fd#~Ofpv+RZ{e^UIQANO7k%NA%_$D5kvS<&__Aq
zPI*P0ePnl66CPCk%=!nm;3A3TRhEd+=%)By^ERJZ*FXm0HV`nh$Z(q;J;j=9+Ff<~
zdqD!x(EXg>VS_L$&yRj4J70EStdu+r__s|_cl%55ds>b`f_9DwY{6zxYfKLEM{%Kw
z?dp)dc^T-O+d1)j_cq#ENm2{td+jY<m4Ca1L4A6tvn}2nXg+P7g;m;$wU-i6_<)@m
z0Y@1Of_B;Qa9kQh%(nhj@`e`Ukoq>qzo)F|)@N|uP;VI%cbfC096HD_Usei7Ew*^~
z)-9!H8Mm(s-dhNoca9S3-TDwwW?ATJXc^gLjX2RM#1to+5@CHUmp_m-P>%#1Wulj+
z()?stD1fM|Y_m8bh1}I(Jn|+(KAr$u*iwq9`?n@zYA&dUn)<Rto{*A@=~WtM+z9L=
zEs+pBp11s&>S;t-<stBz6`u2GNG4xIzMK~s1e*;UN?6Ng?udZT!*!M(mqH00>S3+=
zpGm<}&J=iB(3WwSiABsNlU<#Au$f_(n<zg94hE*!?dAd<`IA685s*l>O7b-SDcVeY
zN^-sal!8iC&W#0<dZj@4uu~vkA2=T0VzDkT4%jm3kbiCe2BK&D4QRWczG)gKKCaYW
zdaV#inj4Fy25O_fXB)Y2xsArpK1yN&YwxpXWc%Ti07%OW38f20EZ3|_#x7JZp`$Y9
zEEUIXqxM#UKeuXpw`0r$<=j@b$B5SFFrvxb5ujPJ*B8j|&0(U+!i1T5FM2)kzC57D
zTp&dKGFnLEZ#^xfm9S617Tsc9YO;woZ1!);l(Gt=6}AX&?wK3azd`?23VG3NGMc;f
z+j;S^s%n<u#mC~S#-d}>jkW;YypEUCRa!+;tlK|6o+hb2u55iSdTGJ%SsUB@cV5TH
zO{e8_1;aY~0<v(-!d51NzAtWIsz3nQ-uf1JQNaz6Q}rvfo+Bg+NAFEq^wMk!v&e{G
z0=RWR*<i;nJo4(c&V$~7XFz)r-|@1-EqZB;yyA`7Ik1nE_ugI?@99&B(FIk(Z30vf
z6_xk*g^CJ;+6Q(n7CDw<ur1WxcA`Oo_D+<N`ENRq-LOdJ(sowDh>7|L2HQF~n`r$4
z|H~xS9xMSsfy_CTQ_HNSLz(fQMpAtq1erCY!F+d`y&OPET>8A|L8)gDoJ%&tEj9H+
zT}A!-UgY(LLG$<o4)4{6Vt&K(l42L+dBN2+XXtC*tMKAKNpe;{)wcKy=f2E+Q!Kx3
zs%kLw4Sc6vnk>3GVMP;7&`T{r_^W4`LcsdtZMGkEh-lwCSy@6VA&CI9nFgk%+XsiU
zW-rufA@_1>acWuDc{4yl@b&L)R+=yarT5YBHJI^wb<(Ud$^jy+ptQcgiGUg8oq~gL
zUZRngD>iFRkA|v_JY$sdd@IH%kcwj%Zj~bfp2Z|>$Q}_I1TQwZxobdMkD+9}?iS?!
z{Vy=+34WDJ?e6X|zo`uR9h$waT3qWul{4*~R6U@njtylV+q&L4-70H#-6onWc~>&C
z=+b0Z|F|fLO;^?tGIRKOl`3QR^CI=H`A-^EUHT&p)lUsa)YamtyVXbRsx3wWrY-VV
zy6>D#rkm_E>h1eUrK_xBBW<L6d~QoCqWS$sL=XSm+`~W&e8G5(z7C*6WDi|_4`%|Z
zHF~m!*e2{jdOhhV@7cFn_c7>ZWaRcMJ}ha2oRff|hC|T#e*E5Wm19+ek@c?n5Lt-d
zm`w6P|IuY!cRl~VpWUYzi-pC_xUVQL55_<uB9d#Pvez*e4}@JcYvU#$)&z5t*Uq{9
zjB!VB4H2kDgQ<4LZ)11SVPACiE&kbI*~E-_Ky2}gQE2FKu;>?;+y+maR3%jc1H<<Z
zDMWWlvP4>IZWc-3IG6yspwe8*#%A6xCL+JL?Eoiy4nJhNPgOII6Pij6@ruor^5Sxa
zHe=Y>TXL(I%6+?|C?>^shGZktS&+`lH3#`sPNDb|+CYh~3(h4IR*&oY@1xf_25Lca
z+&fK(xy!~ChK97Nd^O*|8nJpN^VPCWmBnMaD?>quri%_T;K25e`@ALUIK>uAw=LyI
z=Jes09bZtJD{5a~_4@wZ!r}n;ADZ3e9<Pf;$Cm6m5UKY*pb!@UXe_aF-?j;>!nL=w
zpqO9-n7T~r&~!v%w}Xd=oe#3#s<Yf-sm$_`=BYuRR>`nW2qa`c?b+Oo5ilLY1R)It
zT7EzkTk(T_z?s<r+|}FDSkAdA|78Wv!Aocw^yDTC3PJsC>uS-C2y+{Vp(zC+Kc&?S
zWgE6%qA~GbeDG{4rZP1A^vtP#?%5eDU32;ZIzVjuLDa>p8L{$^K6-Ly><>rTVW80k
zR@kVXtC42ml5w4^EldDec3-?CRs%AEJEGQo#2{o$Qrga(jgSfxO(G;fm7LI1)&ueS
zW=j(Y!1-KH)!>m6;Z<PE2pEEwolR9%L@0JfY^T|V3NFivNp?qpzcU=mX%x6gKJxAl
zmkJf9fz!H61e?RSn^t8<0u4aF!a|{Nlg|K?AIu0LNMv>rob)}lDQ2gDXK@AZ)T1&B
zkFBr(^+b+%>k9&0nLCik%iGn)o<WGi83HP=DuQge7s2tjsff2i8B`&WWyyi_s{u)m
z(lZ&%HqGP4V%D0+?;opFAe)4S74wvdSN-#|iK`3YkN!quvFfDwx|#Mr1gjNv7;mwI
zqIG4rSdq=<W8n3bx5n_zj&=MbB?)iWo6&&nPz>7#s?zad{l>A6K3X_89!$k;f#e`%
zx1efB?vT!!lZyAT@?yGl%Q;Kv_q|cn&`LBfwX;J`bQckudnel+2FTM$2{!&^+Na#?
zQ(N2fV|gBP5LW>z$yi#5W*!%>(4XMzwQctC*4^*M-hXv$qo1y6I^P0ilRt2XC|jRu
zr)13en|`Xw*&fX?0Zp7*PaGuzRF9X8-wcngw2SHSD0ygG`NHQiUS9pS*0!$^x_Eiz
zp5QgsY#qUhI-R9ZJ9z?TsM3jRJED-abbr204w@riHUxfW6u|ZW^wC~{3)7|j_lfN{
zziI)QY2+#V9B4p1JG54?BJm<^QOhkOjY;;Qw2!TWY@c~k5fCgNJ(-+3n_>7p$_M*o
zCS(vVyYnX*7VJVoXYVbn5;E_cinV5a8y`B?hfycBb1E|pyH`1PU-%!<LfT7MgWmvp
zeusOXfL(+&|4`XB)f!Y*W>Eg^Uuta6qIi{j?Rvdw5Y$f_B~D*}33`P1FA(-LF&Htu
z$e{Uf7Q(LaK|*f#culM1M2TF_*o|tx_EUE(UGxQ-v5~;J$$3k22UeW#P$usH%)*g6
z3d;Xv1-p$i3H}wKdXI#AK=j~?RXiRfwT?5lOVaS&ThN2a#!{Ksf)7MN9Moea%pk4D
zNyg~-E;B}T?2}V1Xg=mm|H0_46TtU=o`Kgf2$Z^g#PC8`dw97G)lioH73G_i!Hkc8
z>?omAEy}!WmZ;-MTe|ByqZ!d!_Fq2DJLylK$SUSN;h&Boi!J{_D(+jC7V`s12eBIT
zS?}LT+u`x0{}ph!aF%=6q!K6u;VO4I_=BhuK$fVD0LPK}^>aKud&#LY=7|l1on)V1
z{HguM%F&W1>Q!`j;L?GPPj^o2F+XVm3+_uo6G;#aSG0(UK2z)-M~?+qfF7E!<}M&!
zjqsJ|X47bbLdj0lYwPi1n;nStYYu86gU;>}b;73Y`F+`O7UDYiwv=JSj`y#b?@y@;
zVzL{y5!KWs7uWK5HK%MFore~S8_jhd<h)9KR`2<?_}U9v7Ek4Cs4FUVWY|6}1|+>v
zmm1ZEY`0d~;faH|HU8?l+F}fz08#9Dhqn3QiO^`u?qU2s)-cuZJH9Zv>-+x{#5^7k
zX0m`6tWs$z>T_n_@(ub7F1!zm&$6)D=ggBN%$KY#5hE#kzhzdj;?Y2PbZi)irMmVU
zESQjgZ~F15vDYPC+vot2Gb~mFW7Q21P+8`8@PI4ix9h4CA|*-WXy*!qRZO%>4^fqv
zFzg-7fl<}l4KfyVq5<B&X;(mC?AUiJ5Om^u!z!@g2G5~VoofWQ&+i}omN4=Ie#o6!
z5cz<``jKGYnBA-3aiDdM3v|XNs^NcrlbdC418Cz~R)>}~8(l4Q3l;FL7%?~(X$jGd
zDMOq!_YXrJGm^9g$lJ841PF``MM?KAk==Nw3cDvPs)O_U>;CWm$!0A+J*zI3+_@Ir
z`7>mfWn|d@_r|Ephi?~C-{FBhf&K$py&6XHzczGvc`crp3^aY&V~8GafY%=L%0<7y
zO32Ok<RpfUK4};2g3*RPFn~ICLCP7)V3fPHw(k#4GrkiXDyR)l#arK5fsgWBP*bTy
za?dTfU*dr>p_4F-Q)bW)9d%Lpn3U_3?^8#k(l1M(9XT3yy$cCUNTD7J=l6NM7GGMw
zQ+K17k6S)RZw7SnogW?!Rq<zUJFdeKG%&<h*>>hIY>c0{?>(}IE`!(Nt{5vQ5}NQ<
zA5=wQftPX{B**s`^!XnI1bN(Z@BPslkptoOWpu<6%p(8TQ;vjQpjCextVv@Hy%1tM
zJi)lryr02a1nq1Muww%85qJ=sd?BMD-pzmE!E#!E*F+7h+Sga!{qBpdz#YYK)jtHi
zcKT8>cREc?5fB&MzSw;HUPE2}l}|yj%~MX1ypLbQhLKJ#WR6KO9FX=c%zY|IEfy&!
zG*msN<$srcum*smJd+C^{U#<>2&T89V6chtiV=(-^_X;k5@I}nMk{>7Gw*w?e|&WU
zkD<pTVL5Gq&lMQOnP8!icOvs*XAXm@!oSHuwkQ0W5$0H4aV_Qi3HBjZIBIkR%<|=L
zfQAEw{Hr#B$O$iuWfE73jiKXjJ1qpqFj-i_J%U<a9&DP@cXpVl^tItotmO=XlzX%i
zgye4sz7XDBAhG-#zg`#!QUOK!u;_l>!fO91Z2Q*HlA7s52X^fs?~cWjQ3T}Eci?Zu
z-cR59H<D%DIjFcv7?NA)V%zDZ;LUj|yKC`+FTKYhYu*sU|85Y(EtJm(rPDf_I}24e
zYayhvt(>6*w{aB9fs4;=&UhPV&*6<AjI9z=^l1p{6FTMFpc^&w+Y!CW?g|EKmv>+m
z{&Tk0ZZvS_SRvctF0^0vz6~__^~;e3eicgG>m_;Bc{?TI)weZ=U+@%;9DA`>Xnth=
ze9(*CPBTOOR6c4*sEA?(s+P;lT}LmGI;a6eK<+}D^j{(lgsC_KSexjciQO0_gf5P^
zsiu8}B5qO(AWA6Z3^l!?nF*(B3I>tAe<?7bc!{NNj-O5x*;NqhwVtf~$uNkqA@AFh
z>+2UM+hk6N%MoX*Ke0PpG7O)coNd*s4lv~w9yIQOUYSz$>56EC2woTHMGryC<3&oM
zPtAvgszNSE^E(uuLi-?)YW$n%uBDXve)dBG2(fAj)TqaP$g)lK!E|Luq4G!7<UNlt
zOcNmlv7_@+kpa$1hr!Ji;n?2DQ<(u_8s%rc$ub~?ux<m%>_&nS`-|gm?Pvs<2ozC2
z?a%0<%>yM^-FsSy{8x98x3UJ_GJyI<Rs|zD7o3C|`HUKP>?vKrAEADMz5o_hkg^rj
z)bg><aMsL<97AF%tgb0_$-egx3q$Vk(rDh@yUnRP%cA!t_8@$O5E^$+rEI8+SglWP
z@N3N2xnXMYQ#qVX(2(uf@1zH@pa8IPz{2c`SetKs?x6tLn+k)xTM)_i1h|`nkymK<
zA`Fw*6OQ=i0Y{*xN;0kkekdxybs4{9Ql9(zB@$ncC$P6&yAg^gd)3%%Z_<7#BQO&9
zIt%wVNQQgofA;$wIDfstc#MI1;PW0N^+`35>fgcol);frDMzM3%?()_;oZ6QOyWx*
zXxJTKL4{qC0)p(FSoF9kT<>sWd&0PKj?q;t)Ku*)E1pz?c1%3)-5GTZ-SQgL`x;nT
zkx99vFeIWv7qGK3F#YQ{7ckr{sX_ZUF6wn*ZoaYxQZo~UCx7OV=khTt*X$NHb?j|E
zwlD&yq-4dAHCa5Jf`cC70qCbVjvr@38N#|?Fz8tWTcr>mXU}HmhJM_M`J5eol;`xN
zsvr!}qfDxx#^YJuHKjAm)5KaPKgPP#ZTYe4w3-jOmp#)K&DXqH-qeMM@~6B>a=|co
z`+}JJ*2UsacpMmVUdazVuM)fuX?BT2$~hb!BoC5tExQax+Rsd@GBpZj@P?jB7T`N$
z?|!i|!KHQm8t`Ya)ORFXuq-}p-0ww*)|<U}V#kZCj1Kp|F*UXpobzX5se@4ztN6BX
z)H?<OWh}UH#&_fm3<751XPLBtDFG{zl=m<~*VnrnU#KTV97>8u`S%*&jAdYw-h?%{
zYT1d|+UjE4b_8S1&Cv{h$<ht@q<n$jTl66R%rryDMu>-o9aP~2(2pPMyN$q8>kCE9
zOzk}o^iD`2Z9k`qe}o{!WvRGxStid}&Jz%HeXcRwQ984D_n2Wdhk^@AZ+=Kf!>3>_
zKoam~aS9KumYIRlUlntgJwl|I^_QpS=dI(1bWvG$zkG#4-}_fsW1bky6@LNpuI;X}
z$NJFtx<B87&k@`<<GKMmI#A!F*rfVkEB`yyDNEw(;Nn5O@(4eEb6ERS1Kj<kYCUY_
z>%!wwb`nVWz@{dJ1xv2>=2!1VGnMvz@K+5PKW^$^D}#&w2kJw0VXDaEddCJ<VP+nG
z0uepO&uFL~-Q_{q=KqMRR{FDBTJJS`^$KOKsW14oCzJrB@ir;@HGuhL7)DTvbHQt+
zx7DaXnB0IVi4g-4M7zwaa+4qb>p<Wkd4|(>pM;befOS>tWkVOZu>43T=Fd@(-DJ;j
z8C8?P9=Hys->xPPSj+B78bTr$iTA93{$49>EUKz$|7JE9zsok$<qc9T-W)$r@3Q8G
z(&wN)w>OX=&4+iGDApB{K}udIGe9}WmQ-&EFs;AI<$uK<A=(O+0g7~kI5PAu3U3z?
zFY&S@6aJi!E_!pk5`ESzOMXj>V)ygipb)Wyp+=T}+T}ifV6sr2;Q)wshI-CihL{@j
z_4wSBJa7NJcl*r2#i$BtrmQ}yF#^(DGT&V=h^qF{15HH-$TRrnuKC=&mNxgq4<hj)
zGTWR;C)R$f)78s#Fg<V%3K!=nYC^AbZ*X$&E+m8peX6@xn3|Ht=U%RwqL(iFA`poY
zzylk*<O|v$WcMoX`0KCaW+VGD-=js($S{Ib^y>UwZ@C8-4Fp!8gR}E(Ci$#J>pYxD
zxLn{MxoI30l<7tkk6*F#wsikw-o<Z*7Iz5PH-o1Zs&odzGlP+mFgpjzhYWIwDKNP=
zztMrDT1FTug{Po(V`4)>$is49_X?onwjfg!FY-gY0?d3FbvDrPl2&dDs4}<KM&ED$
zVu;pKp%91V)iD3@74lborLBLoRlHk^%DyLJphpG520eI}&^dmL669YFFd%o9Z@@mD
z4$J=<&%Tt=DA!;G@}$q3sO~->_gOE=KL3C|j$^&cF~yTF_(DZZ96?vCKudNvPuKuJ
zj&8L925DBv9TvF+cs6*{)b;D74XBzAy_+112JTXAVcfi%(6IC!t^~?4SF_*OAaKe7
z%mhjm5^t40jiYZ)+hbzHytm;S=-|y;pzK+}r8@=k&n6gNS~o9%JwAs`{VhSG=g*1P
zdC8HGTq`q}TF2jpuqSzq8aCyxkeJmsnn^I9>^zu%gm0vC5`+9y-os&PX9~IA<{PGO
zKjlUDDG1E-`{z-JomWW4ooM@~xg_b`s;(-@#pw2dbhY>Pj5;_WDfhZ8fH>kO8G+8Q
z_L!56L;lu$F{h>Suy~rHEm5b^Or(Is&~Ep|Gs0-T-ic;Ad^K5@pS*QlHFa8`xuLi*
zvK0pM)I#pN%?~}~1b!j*L*w@I`#!3-gvOGIP(U&}9q9^Q-N}f~Kh;$r>rmHdgj&_D
zT3d>p#6zK~2R@|1>OJO=;#D}0-<_il+tYmIgmDQ{wqBcj_Dr#4JPPjC0r_5F2^-d^
z1%C!SVqLKP>7uhtZ>nY%Pj(WK-3d*za=VA&S0`8)fDS}H4(-jMUc=?wTj80CBxnQ>
zD|GPjoH0}7@$E#2dh?cTo>1S|hdTYerBc_#TU>s*cS}QyRe#O6$bJp*cu^b8c}=6V
zdB^IH7<<qvj_OUMRQE*Y%%X>wV-A;Y`P&Buy-dV7wq&oy!HkVII>vnAMY~GPNVo!Q
z8Ng5Kr@4W%vHgIskzEDzk8tSQvd8ZVqq&6*dfek&N666XY*Vq-ad5`<{ANMES>!~&
zO&%-W`E@+BDg1c^9iAm(xFKX>5%_J#k|AmzX4e8YL06@Z0K&KUCM_L*H-_3A#?BLV
zgv(x(E|bONzaO+aeLAgg_6`k;ou$77C#NIDE+GTTVtZFn48KONpKJXL^a+uUiLmH9
z5^rAhKX;q3XK+Mp%Li?1u8t<bP(iN4UF~A|H>EGDnm@xkzY<WsEej*kNi(|0w^$q4
zB6VDDnwmICHMROVoVxO0$?oSjUTNz;*NUGSQhY;X=dLwCbGZ1r`p8B#ug){Rc$?>A
z$AnC3L!s=O;^W_II_l+D-%3=eMBO_v>$@_Q8w_4HFJ1GuZTjwmQ~dCz;i_@|!mA*-
zEF6Il^4>KLSk2~y2p1mo2$FtB-J4khys^h=CeJc*nbMP+kyeA?Ra3u4ya%(wXR}SO
zO{c>ZUs=yP3!bn}sqg6a2O*nfK(+Dnc_;D@(iTkh>g;gKfN=TZXfF%7kBrq}PeJ*3
zqz;P-YFHSMN9RNNdoY38367F)Y~IG?=O9?Lyp7-oyg2DDjXwDttExEq=q3B!Lgfcv
zB0*#eSJET<`LH`wUkLu(62s%+$!oa>O{x7o*u*4tvH4bW^9vQf!A06VR{(%^Xu}F;
zDc{+isxRYv?qLDepih%~DN3}d;A})%-!Yez?dbZF9%K7BI5o8rsWn|{VkBBS63ZBH
z{??6*!@&_|kVLO^!i<rlFQ)-%iafT7>3sE}b5~(ip8&z9+A7))wa2t7UEU~=TFBSQ
z45#z!LFXry0!Y$k6G}3u8gw!LW<4(i!jAJsm@hRwT8+fp6r(jnk@3novKYGuN<tXC
zH<fnsX&<}ST7U#iL>+txgEz!D!gzndhR(5|dd^KBw`)Id^nk|W11@GJf#k#;@#JAe
zN_q@6v=}TKae*j;bq+)6U;ldTTGi$~ziIOVguqt|WnMY8efCJTYD@bCk{;y7eYhz(
z*qxk9Ndqc5fS)f6tLF&^287{adwU=@5#bsqV3kPIg3_NFA{!Z%=q*>syYmS0gfF2J
zXE%tGEO1pw!JRT6fSK1}up9)WPg=QI&=D*2U!o0i=&bt@dNBb9>=*ArP&^29f6Al1
z@RYPLY4h-w7WCz#pZ76H{BD9n!$>s~`MdW`+d7802&gxEk`<{ZL6QnP;$Koksdh?o
z<0n_)dim<~M0z0*&$**bE$(dG9AkmjevVIR2cO+O-_|EE2iB~bOEn-9JF?Mu#?a#f
zOe3x6#Bp?}^jv+c)@SSc1eoZwbKAo7%O~bHJiD#TZTAbX$tmwS1f$7&Em3a5|HYuk
zQT#iqkcn)BF~NulQj7org^VTKyLWrzQKJ{6Vpt%B^<5e5GC+Z)3YkB6_;hZ$<E58s
zu20Vx%?JKZuUM3B0Nnw9jxOb|6_BV5g2S1h-!FjuK}sd|Krr#@oem!4cBQSB@$KNg
zzncVPzfMYeU%9HNpcC!L{=o{ROF*nPSAB^ra}`_9x_P515>lPJG`cSS04#*A$&ci)
z<&A8QxMw87)Yx!y&~cHjzE+szCi4R{$Y~HJnwYA~$K{aXm;)y3N^X^`TiIQ-lrE6<
z!c8pbj@K6XY<21wone%_$6mMx_TT{k#WIcy7F^QQ<3*Bm9kK$6f<E+mgi+9?>!s_2
z?>&`6j-9*-_Q-Sf-OUGa^zT#^5{e%*!2sNzRj-fxLPO*uCD&tRqvzIU5!gBoeOjqe
zZX8;lBH3^Ukw9vdWfnyX5D-#)^N|!uwy>%2<H55|F|8VQQbEcN;8xk1unW1RMLplj
zS7`xjPlqFNM5yi69)8sKL?55{`aKy{LbMa+aBcsh6LzNG=_nm<j^EGPfypmWna-!Z
zE2n=CV0xuM_*25o%lz+W6W^4wW8I=J5Yf@2X&%Ry%X*cNZEpE~)on*BnwX&V+Xzi7
zUSbs4Z_X+8uhdccK<wK?4}Ihz$GQSBz{&3VKQ4!3>BLLXkR+~?_9KvyO?>2WYnPm-
z|KQn&NFV*iu%B`rL~rs~vlT*p`atOM>w#3>vPXdS#$iAyf73>eCO!v<6dq#a2XQ%^
zXjM%U$s5YL33*a?T)vpr)qjW9zX9&PW*5h*`f5)s+Rx`-tzNg#<&ijaCHdm7|KglZ
zPwyBZQCHDQMZ1H;Qt}l$l<p4MKMGu7wWs;<pkSJzI=E{@^EhYe75pWrdzQl3Ydk=P
zoA;>M=j^?@4z*NsEw(s1m&lm#??L9*f3LhcexcD#;8O*>V8mr~-U=fQTh7gz8Jzao
zGQg{}_$KMjE^vyd{rg@;WCCLfzcOcSfP|*`ZJ^Kz%fo<f`;{Ns4DgIY*F4pyVA(%}
z=O?1=(%e}_{KySO5F{<S(bx9*)sL7BVrsDF-L5g!ZXwb7&=<q*I+^9Z9!F<D#rQtP
zPb+viL)h*ySQL-Jo?I`kcJc<jks#bVu&CaGG_Qerju-j5=!8{W(0tVanaDG1O4;6>
z?%=o?)o8R?Kydf@nc)r?T6V6!`Dz9{KH6aDoMIhDJ$(D}jUJ25%eVJ9J-`hB|7U7F
zkWkJhbI3Yvq@&{k-;_Mc;SxX(jNByy&g(|{j(&>{#M-rP6JldfKC~lY;w7EG!naQ-
zeq<SYaJT=G8A>Omf)>@d^ecaz-D$#M^pTtOFBIT9&cg)Ea>a$)pmQ@_(bCH0DSC^9
zB~hL<_I5GLs-gcnNpnP_sGv3kE_kJPoyOgR5dMbH27fSNoC=x%$=@?>pi}(p6M>2h
zxP8vqPu(n5o_(g>tlv&NF8=hql|cQ@i+CT=xsT%;5?UABTC3snhy=_$kSwf$-qL_z
z0QHW!QJC}Tfa2aU*;3Qr@S99CJE1_-^}Z#~l}g<)-}*B`(Kym3MlW6Nr`R&NZ^1+$
zmlhy%kVdLyO9&3<{45p>-{#etP5a7k)bLab@UGP7wvSq4XHProv-=J{$9mw1bBa97
zkB)wB0v5&CEQfTcA&g8mcN4|Lw}J+i{)wOmPCQ@GNK3*FPWcQyEP4fS(s`oDNi`F&
zxOc$A^l4M*u_=a}ye+5dE6$E{Zy+*oL<$S}>@TO6W4KKQSz%RNXj4Er8@Cwr-X>TK
zT%ot%b3-)Mbdc`Uq{^Mophh9B$bRZ=;#`aO`*YBioitfKX#HYv0?MljoPBh7<VRqU
zX?`Q3Xz~q+6Fl?Qq=l}Bx<2RJrkQUYaqo$xdjr}f#b&b4ex)}M0^3nzybn`a&&A%S
z_klnfknUUrlAm7B!T@X_+LY9xPZW^4Ef5o>y4>|ZL*)7X4=|YL065CIuPqN$@(JYA
z)%M)XJ(TK19)euZH*~V-EfI)d-fUM01)4*yaP#HU4k1hFz(xkluh*>KsM8wJ?+Jd5
zXU0IL_Y(Du-@(If7;3iojLl%IE=kYG0hgmO&%v*g1`~0+#pj0$T>?TsHCt0ysZ8yz
zFw#B?!Ff?r&F+CE03j*3$Or-eltZ%^En&&i$#+SgZ@qgn(PXuH8w~$yb`y8W<&p6B
zU~u`uWarx_+0E0S4GfTf9_L(Z01(1gQWtkzB}eZb4jE9&t-Q_2V{VX|wg$4y=D+1Y
z0rcJm=wP2*vFWG-5c+F?!+FC6X5?XnG=(_#?flhvI5>S7J#hBOx3sY6+SMZ&<)TkC
zMzqDj3{?AnBwcqrm3<q(k1bpFRx;|?WP}c>$V|quWsmGlbc{sy-jT9}BYR|Ig@o*g
zNLKdDe1G@z{`I`i=kvTA_ql(+>$<+zclhr9Rz3oTl7OPFO)F?(WU53|z6}VRYg{0(
zfJ$N}>T%fXy~$hSv^PnC&%`y(R?p%4^u^%j+%KB|PNfyFQgpNC6`LRL%JB{`BVFrB
z>bq7Rz0=+cyUjfK_#_MJJ&mHD;k{l)vPg_dvR~%2fIG>3wMg*61z#%k!wVZ5f<+%9
zI?YEil!dSS-vd7ID#2IuUwWfD()Yh`IPAv}#+7D4wYipfn3<ic4oaq0+@#2G$O0JK
zfTL{08Ok5$xk}q^6-_JjQ^anBi*=p;*+9FeimppNWLt)|K7;H<a8ZHRUCzv!IX$>(
zUt-gSI0daMNWeQA=23X>sg=R)h_f1v`o*nD>^nA8guWjj9D5F!h@ps}g+9-~oF!{~
z%uJ9pJ|sqm`pCiqC2VVbFc9~g^_*B$#=U`nz4pLuP)>!yD{Z0=HE>0bEb<}mew;2V
z3qhdVXMxipsPK0jTA3lSepeh0PaWk^VwSs34NECWStOKya3M4@2nX|t1{K<f!FjQo
zs8AV$qi5XcF^tQ#X&zj79U-6K=&~FL_V{)c>AU=y63*j00d3a6pkqC1T+_0Q5&Y1d
z5bl^blq*g>R?Nh63}(BOCjiP|PIA=JgH?d)Hb%|(L`eZPzZNJL&%ze_K(c@*b^1pd
z(){N7@j74!+(RM502KM-s!kkgf-@-S{c<B?2*cg*yYEf@f{FWypE`#tB?URLpE)r|
zVaYc8BL}SFvSt{Ga0NrICnA(-VIq-PG8KxT4-P5);Lcr{Vdgv^6*SfymK<|=$9r>h
z?rnf>?t03A+2+t!Z`<gHQMuo#Q6I!(3jdK}U%4+2(t`Rk_TCSKl@$X<{i^`cWLwT#
zGz_m(T|Rb``B>L1_x9$CMKu)g1%5l0_eAV5=}KR0{ixG;Q3!@oJK)L{zENt@;y3LL
z@&a-r)$a6Ah{Q$Uisk&;0iJ75E}q|54a43wk-!CXEaj^xbFc_3XOEf{qT~ST?nLxr
z_^edmnU6t3Xxld%u}YiT9MPMPudaDt^EHJux#B0Nu^7uD=?{;cntx*7<D2}zQnw{=
zRS(=0K6X6Y-kprCq19_4CQfM3f`;gMBn$vpB!&AKPu>WP7C8YaHgJZv-_hm=HvhlE
zrp~S4`YN*og|q|!9_4S880lTH-S?atSGhrofJhKAMf7PB`8(|x_<*ZBnGb0RPfF+t
zh0lO)VcId$$^wx38^w*yC>~c(?1L{G+w4_uvXE^_^)*zH+p(-dKjjs3YA9(Lc%Obs
z+bH+Fm8`3d0ye$TnpxsNTs19zotl-XN-*ceg|9eBB-;?-i2Mt}ns@Pu0L<5^MO0Y7
z@cNdKubQT|FVLmCGTy3>;ax#4sQn^%@w3_YQ++WYRg&ahX!KoPkCnM*V;&V0N7@P+
zqP0c?%ijt54>P$1ao}t|<V$raE`BMJH%<3>F)aOfH?M=Xtdg9b%4d7?Slx)%Q%`M~
zRw@Pu^M*cwQT5g}skass!DziNpoNl4k-t)|HQlwJz26ZCeqBV(kaHc_0hGHJQ{~uJ
z*;|OSX?E~|)xBR?vheti;L|sGe}bOMf$#QB3p3ByIoO3JX2(Omz<QzPRuEnS;4rMG
zJQ*d7(i?|!3=N$Viu7#^;u`Mr1_7&IY?>3##3}f1mfB8#H|NJ(d&4TyfWHFlas@9z
z_`2r@-uO=9`-Ob`m>L9B*i0(^3FwExKo*}w*}+wmyh`^}p-|is$>V9DKC(4ow?n@p
zho{w)%!D1B0E$yte+A%>H0kNRSX{Lg4@aL)WL^6ng-5;c(no!Yad|mWcoN_}ohtSJ
zIOPV(5?5?;0t!xlb(?D~pL&dOj6ZI^b-_}{M`qC|83Ftg4Qxdf9XP4HAx>75BpaGw
z6|aMpr{)U|KXF8wB)Ak8Zg|Z63hN=8_;2p}f$Cn9{t47UfEoL|qx?yH=NrN5f0oa!
z%Tg?m(8_9Jx|hVhoQFg5g*Lu?C__7t7?r^K3OX&ZXN5WLc_<+RC@JVMm*`vB1rT%a
zX8(XgE)_YCCffW>B2bSaFaP$k*00m8Uy=t}@qMds9>;ml@?kv-5te{jPx0{-kixIa
zufQRkt}h3->WgVvtXv@U40m3hdj64stSuOAlBzx1cJ&I?S!W4=`LRGLP>}oi4hyJ^
zW?$K-5@}=bUrN?1Nxr4mr+5Qe2`JY6kfE*~*Ti@f!XXe&Z{i~lhj08BRL=tU4WJCt
zJRvbcLM|ZW)P5*e-X8R$d3mcz!K*Z3f6h1zZ!@lAno^i)kQ>9uR|kc&%p6~$GgwS7
zSHTOsPe!sGOu4SiQv}MK_8&C_%DEp@#8H5Sb-mw^=k2_r)Y48O*sLj$l>^{j0>!o1
z`?#T4s0}6y!Zb_iMI-Ie;>+WnyQ6cL7v2GbTISao*V{Zt^6rxu|CRufaus6``B4Mh
z{acLPo}U+n{<i$~#u$#mwX@)>fZ2xJT;R8U?&QgNo;OQ>?I)eV_u*8Al{`P$#C0I+
z{(fLaHl~IIc$qWw`);<o?PmhT8z)Dmf&Z)m7WV;W^`Hhh6NDBe?gvZpy8tUr`Yn@?
zUP%rXlYR!_w+uf$Z$Lu<zXjmyo1hY`Z`Vhd_mKrW>#x`YL5IC|B>*%h+OT(mL!aX3
zs{zfhrN*1Ulhts<VLKuFsPVN*?!FyWR!A(k@MYEAyJy=W1KBv3pLCC6!<i@9IaXxC
zk`ms^vfdDcL_}Iul6c=*52U>f$p}Hb2Z+M8G8gnkc+R^sD!K+m1rBiuyD^4n{P@gU
z(x;MdHO0iCp{Uf(kLn=c@Q*rp3WhNZp|~p1;m6;lm5$=OBI(yTe9R~$W<Wsn7+huM
z3iZSiKZ2jz%o!(K2oxnSJb6-ZovJmmDMdL`u1zM!vZWy?FOzy5xt*Fphw9ex!~d=x
zm!JUO6SPRhdJ9D@LcHjjxQ+r4Ev$3@HO=s&hIG(4J_Jb7<`onm5~-wWM&NZ{JO2uP
zX(=#o2tChiV|%nf_+jHWLxBLq<O>S(ft0Gg02U;0_~{Z^-v+M1#l$bs2*!cR7&Bt7
zCvM|q`ZhInefGd`mxhcGYFKT%sV1`v3$RJ<Gfysv&g2?_qJ1JO;-to63Je}b!Fzll
z)pwfY{mWBi0VJeew`lvCq`7ba`0%UOhJG1rqX{C|X>3wEfvvD8xtkp2)tf*DsQ)%Y
zRzN;}lx`5w=gt8ptPx^`QI-MFrLBPxj{GO+g10<n%c63@6f4F8SqA5iGtm;m!quy(
z5K@6^WupJohj;hS*U}%Zpb<4~+3mY^a;I~530R!9J~V$ALO`}}VN$A<|GIY675B5q
zKbgue&f96y&cD!zAhl0|J?hYq)aGNgkezrbZBTnKZ))(K;z!-SQ0Y8{7?8xFwL#75
z8%jpDs^wq?)dnF!$`i@JI7G|{LW0=!u)DAMV1Dms#>Juc%86pzkI^jsY{DV1*(I=k
z`NyJb&p}Q?`VD(+S088J_hLZwTM;M-t39LV77ZTb?IlWIxTvKST+hwVukVC-s%kgq
z6`dl6dI6X>3ZR~QyK(>JMpNT3N&*2WKMxi%QxaGNBZX;GWO_4btI7?zTEH{%qt3bQ
zXfUm4H{&bvHk<&r4QPG;6IK75K(AxO%Z5g;a5-d840r?I+S0if|0Occv}752bPDUr
zCKfwDaS`b~?fc;CB`KcY`zkS4_Vh_rAkd&Q(M!dyP6DK6Mc?j6?FTuq@WqEdGHpj?
z$psh$Y_}6Oj&rygSa$!4S)XmHt0iEQ@zI<!;<`CxI%)_J9k(1WL{0}pCJ#cn5fks+
z!z0>p|JZf`Ne0#fP)Vdf4DJtT9@s_HsHE)*qAw%`zdWbt%IK+bk=hHm@{r_=7_#Qd
zVlQ}~0h$V)C7|6MA*<}V0t9O1_*1<A*!w^LSlr-Y6`ZOiicf)2N<84iLstIk?^vB4
zkDxeZ9Vjj{#L&4#Csj{az-+O*Yxe<i4OWx6_f;}PvO~R9Ss-)L2^Ryga7=+*T-jP|
z7BKX1=ogpZNpELg=8ItGismZy%r26EDBs=-=L!W^(m0uFW~Pc@i*_B|RUpe#tUP&Y
zC!C&uCSasVuTKxf7Em^S`+eSdRl~MlJ<l*Wq7fHT77`IZ!0_W@+US-kHfrl5=EXT;
zGKmKH67hmPzY$|PNeFN_`rD;LRHo_!BQ7(g+^q{VdybUO=8deR+};5KW^x?I!>D2g
zO;DL{S^AB`{?r#(a3cgkE2=oc!Wa}A?#-*~B|4?mw_=FdZ)pN{t(ch8bhUERnG5k1
znv+%rF|6O9I>!v}C~!#*N%xID;;SXuPoH>fBDxb~d5RM>SpTFfba3t+;2aTGV=U6M
zOc~`_E7&DnP_IN>)cba*A<`~PFdSVK>-^tUG$UX+O$<ho2PBwwzhWk<h3>|V&KF?D
zuyY`xV-gXtqwTib$QrfM+LfSmb4R5z8GXVI*5+>sEm=y=RT)qOX6`wITDO{@sR-UF
z>S^bNrChh*fgErMX^h&EUQ#`&h0Kr$AyHn-Jgc@F4=5py`J5BSdTm}+;LBm_*~98>
ztK?!pgim^oA4K!MFom729?kXx-T-i%YnuOK^IPGZWqh@b52xbZ!$*ngQA?v--P7-a
z7KzVhFl)HxXFUX39pE6FF3(xn6WZcDCzq`qOcFco0${oEe5r6iM`oGKP~mpmx+(k?
zNIE7s5m=cN^d6X16YOk*Tm{{~2jOdqOyEPnL>=e3_5)tiPt7sK^i<IPdm&0uN}Lck
z`s)zzK_jJ$qaZT>_c<9xDB=Fq6C`Jq!d1DaY@|4Jl37kADiym=MCzvzajzUCcCv-w
z#6IQfN!-%3{!{zIsh@H!iiGKwI}k-3G;lA+KxSZ63~empVuQOYb<%CmwNbu}-}FSl
z9heTXw&cXy#mKJpL^Fy$ut}zVanFwG&7wLU1D0B(A@hqVx7SfqFcybe(;4YS!`8FF
zye1NU&;;uFm_@8?K~NP8NG|+~s)@DA*b8=NpAgKC`prTWO#o4Kzq`CRY8AnPU;3n;
zq@X_p0MogdkPriD)lZ1i)sW`jjX#lIo=H?vAWosC#s$!>8}k_$^9cwn^SleGap7I^
ztWzA)H6bLNjO^gFGhvrC<{UT_RrL1?AzYo(=v?4-doxhXs*gr?>d9V(X=`9YkN^`c
zl+lpDtYMyNbpd9%GD;Gq+XdiKU`7a)c2aZu=f<T8m=hv!X1c+vp$UuSQJCa#Wp?oc
z5`5A`@4u3SQr6W>9<@%);`Z9T{clfIfjxF`EoPAg5^_Dt_(r)IoE*0+;>M!*t_H~4
zQG+!wiirdT;U|si<h~SFt`1xsOu*iS`qAX=%|7gzre&I>g863{kpZYe;g49y*+!jv
z*CDEPEv~$`t3c^n(<MMT!%KB_O=R0-KA406Q(z_*p*T1}%)SEVcFVNL?oRwDv-X0n
z5;V9~WqJO*&$rzI+kMMd;PH|}qEC#vNq4!J&B(5)>;sYdFfkE^GyNSf%p9&%D!_hp
zh-j04PSelc)gBVWERh$)ILF90Zd%qH)X#xzOQHfGq~6fnTN4gC1t~Th%rKOjes{Ip
zbD<NEQ9++_MfeFgDaovy(8?`{l)z1<=aJInXV_E@&=24Be-ok_1rRu#+su;!#cI8m
zmb>zs>ZnJ~JD8EKMYEl>?eoUgnVjx@Kio_=V6&?$OL761<&OhPlHuJ~AY$PLpi=(c
z0tf-n3Sav<2$Ta~R}LgpiWW0!uMZ89qgJWBV$RBC9i=d)XY84ramTyd>j0u1`5_7Z
zF;%B7dHr50*Beb0LU5xPuYS^~V|0I3NlDN#=L-yn0dN;zPMci>nTZLQVYWa9)Htyk
zyefg8WD6g>Xx;qI2ky-);OeZQY-`hc8Oh+F^G3$kBi??RcQ9S_q0QUfz{*hSpva-4
z1Mvx?MDmfzieIC#Vsr1d#5C>J&SwExU^T_?tpdK|zhsN+On|~(1!HMH?EMH}B*yQ-
z0I`a{fPFbQfd$tf0$dv8BQ){w>1LBg>dm+NxK=hRcB+g_P<%T@B+ZVEDl(p?#OuQP
zCg#cyqUx_{!q>@0)0FNh4+`f#lwnVlyq}xB`LwSk%?ftpHm{+Lz6D+LA=4To0|O5(
z(Q`mBsmaF$Xe%C|LWw|OSHfg^JXO8;gl#P|78JN~)8nozgoI0o(Uq2!h0+L^02IzZ
zB=iSLDCt1>ena-!ncR;DoHj_ef-!bo9kXck%{Plz$hE1JqIPF!Fx<tVOS>#fr%B6Z
zzHK*pUeDc&9=lz75aq=lUcd&4ke31Rkx?5s3$%}T07c%!D-_;GrQI)i{AlReRMmZc
zqk2u7w+Ws`U`%l2@0?X$h$uE?C_{@+u+1y*-#Zk~QKoUhbE3dFAT!Fg+CvD(z>1|{
z?z4`H5!ck1>T}q;>?#C3Y+x1f;EQdSBFx3gj<VoShId_GjryGlG}J`^4q3mPd0w^g
zSMX;A@OT@Xyxr%XqVv&Ot%c>yp6^~g$i-;f7QKu<sPNfY@SAEL6!~hSPe0Sm!aj2X
z$q>u?$ghapt5|@$ufq@)4e8{#+>TGVDI5{*f3GH54Z7lp-Eid<M^J`*0r?nj*VTb1
zS_N#i`m-7*k2DGtJaB~Ss&I2LxNQ`AT-%Q;&E&IPXIfvpsPQ|npUogu;iTh*`WTxY
zXub9or1q}DK69PP?yAH-f_Xkn&mgIp2^K>P;qhBF<{LT&fVBe5QHo{_%kBuh^!xy5
zca6A&W|4PT=HCsF>yKi-gDJ<8Y7+pJN|)S2``ygWMZm{UDd2F*W(~A|dN4e!zdQjl
z)#%6n^|~p<!vp|;l|7>0u<Ecemb{JT06K(H&aD(fr(uaUh@&S=H+`RszyzTQQRm`m
z`jYwl4!C0Qy)=W1rg50^g;I-hAIWg}COj^s7zg&V;KmR#z1BgGGSi_#hj3$>;Cr42
zLHV{BN9P|<EaO8K?+7|HXHq+_RtZM%ybmGP6+-HDdorf6lAxcuULhb3a<Xe9Afat-
z0M23?Cak~-CPoL(2+h`ob=AksgGjf-nrM7DuQQp!`QW33?9X%Gu7dUc8caKDyH6Nu
zwoSJYUC8)Cf$Z*=wLL7U#Z!H>7ntdI$cn+>m=7cLV?FFI%6MAAX2fouupr`U3;51F
zQ{2JqEG`Mtyt9Gt+sU!kRwdw}*aPXJJy0Xr13rMAuC9d|jY^&bSQ<v@elX}dI|EY=
zu+?`d{FdF=31*@zQ1`^6Ud2!+VD;dQB-U+a=sHkNC4qu`ZkKtpP$2d8o4S^wy2^oE
zcv|Q6jaL1S)=Y|UOxg#d&bHxmo}_hy^7C!yHy^7M%zg1Hi|<RiE+~!xAtkHmqpu1U
zkDtwbY9Xg@%TQ8f9M}J3(MP8o{m2_9SBel5IMWVT?9l#SR9JEci)K0z{Hzx%>WM;X
zl-zG#rAx1%5$jG?Jy)MeY2z4g1hHqgEpKHTO>AQBO}j9yU!!{u<V+8G4BbBbis^pT
zzr)>5R7AMKr=i#piRjP-riY6T2t}fRmFb#N_$&1$L=te>+vK~ss=)5|ioE59Gqs(+
z@p0G_<y^fwDHaH<7Yen%>zM}J&`dRN3x61viMMczn6+(M<rtz<L`EcXtBnZfbAj+o
zb-gOv1t@OuVR#piFFpC=2mXq;l!cx1|2Ln@(YncHF=Y2196&#jYjl)H?5<BcGw{26
zBElJZUEa{EwqZD3-=IkV*k1B617J^So6oPNx}G5@IjLUzXky_T_e3BGu>?p!Rrlbh
z@=mi%n9F*`{hMs#0}fZe>Wn5Z{EaPiMS40mnYrG>3A`4MCRLv2Y|2tj=VCAGwG{sb
zEZ*ik;#@k=aeXKT4Ty^-q(M{%tb<WG<VaF37~20!3O@%T<Z~{E`RRN`qNRJiZ8z>E
zDUu>&;}wHBJxPO5Yy2aJiO;MSh@OlofFB~`{wGQxTk%ixe??pt6F07Y_!iVU$n4Mj
zE9!3#-&)##d3+~Encjgk+pC!<VDKQyBU{;H8(f<+8*Y1tBdZZ2cRLet__$Iual)y^
zibukPfDceywuZ3=T&Xok7+=x^+z?ho(!!Szqv2U^cMHHewXx=1`+??FYBbxzL{BON
z4LCE?LU9W<AI1p~{<@+}!u2uqnx)_q4Z-wz`nAT3?avhYfhkADr7K>&vTnb_2e}K$
zZ-|@m8L&G2az(U#1i(n={slNypK>Jdp#Ud*Be278It8O2FXVIk?3c;)@~wqP!Eq<k
zM}Az>Bd`3W=;#O=O@^jE|F@c~k^fAaOWv==t1zNp1f@KKEZx4Xee9fyCtjm<;E|vh
zW&Qo<<*q1;#NB(qe{ATlp1r%)>0_|99QsbFwB&F8u;}p(UGUciwYJX3GChMG7xA-J
zBQkAQ+=J=H3Cd#8vqg&$&ESMfBf9viQ?5TCMi>Pp!Pe_NA%GF;>}R+VOVXRMgone?
z`l>XuW8@V%YoALCgW!P3fb;cznm<iI>HKuse^eB&BrR=<pz#?;o0w47i6;BE2IsH4
zs#90-j_&;E>FoFZ3D$Mh7Qwrj1x{>NQ}<fTG;IQ7eFQ$;6QR&$UAFnBcF1}f9AJOQ
zZ&kgWRq34VxIQV!WsznD&^3h|m8>V7#ynREc8)zZXY^CkgdK_Sq3c%%l|_Qj1%N{t
zhxYqI#h38wF>m_Xsu?81Hu9rIUcPAx632@NUK{J%(H^)32W*MWzB3@kq8g}I2JgtH
zF5;o=DRs-x!m~Cjge<C)57jjngb&uT=J2(?`m5)wF>NbGW$bxY6=wIpa~8h*da{%D
zo_X0Dk`Gl~Z<~ATWWq~_I)O5`(&jwMdoT#xkqyy{t9PQCK)<a{nHyso%_P3>oPbcD
zm0XqvzA5~xbn=HJ{C_bh5NW$ehWV>fPAgKG==ub}ZPa@~LEYQM<9{B&JLfbUTD)Oq
z2ZO4Y3<4ri*$VvifP<a|<Q0_z7O2pSkOz<eH9BkJ(^bfo!op7M2U#1IWjY!E%J@5!
zCX<-0W`-4ox2Thdg)j-85Gs->f&d+%!9^Ee>!rSZWk&9iOWMIZGm#&*Wrnc+$K{?m
z`PO4m!CO#g4f%>i@x7IO%6el|<(`oc6t3Buxrj-Q3(zn%Gic$Ync*S+OeD?$XvxJN
zLcg$WVSkR)O`>_gq&63u<^QE>4PF~OM->5R_Ae!(ElHPK@$fUC#r(-=@-I{Ebh5(3
zShM0HhB^;3js%;x6&$5JUIPUd`7aI-5<8J{i;X$b7__!CdQckQZH-rnC`fcx6X!+b
zf$&yliud4#Xt^=oE&hJg<hU9CA;^e9z5#BX%BN%tOE`5TsqXWQ%uuK2*FCtZH{tu9
zfuO#EfEY(n`&!{CU8`E!+^&V20`t8uH<9S)Fy<1#Ssz6-33T$RI{AdRWc5LHUuT*i
z$J}<BsrL{XtuVdo30Mv91G+oQr4TR$ZMF6-02Y~8vf%|@HaCXToGqvnP#o5JI=f%u
zU<Q{G0)R+{bgk`Z)n66+Y}uI~tW<l52n^r&MoZq^W116&di_URMXP|*NgM=Hfip^+
z=RVne3u<ZG$OB|qKM3<j92sDVzxeZpe(yi2vLG5fi62T4bku4yE{k)(KiM%E<d~=y
z;bHQb*8w{V%3XeWby^Aox62tgw}IiI`bWhEd6$QaVV&6yRdMwE2Jejv$^`R`1sZ-Q
z<U%V+;CB`SAZzVCA-u!H;X{}3x_ouU8ns!2F_;rKmkNl20z;4ZRLqS&q0tC+CrQ@`
zbKgZ4vCZ#hZPpO%`>B>kn#}|<^PCkBs4~fBLZ5_5`NvxzU@IP<^4IgX0$fwmf9aRW
zJeT^CJ+;Vog3$zEOT6`()V$m8^#fd$1)LbtT&hNFoYLxqB&Z8CRPH#7_HcT`fA5UI
zWrth~xO~1<Dcrc1HWZHQ(I}3P6_Jj<mAuHFhNsYqE@S~QE6IYUa<gvXUAUc;Gr{Oz
z;n|`&2nO7b(eWT_DF}mq_RH-7Mg%j2yc)?+1>gbJ7d9ppV4^ZObbbISmF30*5({`Y
z6ncP#%;-0SH8K)-S&M*StNNVijKE2cLrHQSs(OY>p9sGct@)*z2Pxlb3!i#m&XBGD
z`3uuBh@~ky%Bjb^yIM9F8Xb-g?p%6>8M4iEc*OMz0}PuGj&j+Oi_E-l*5(@Bp{&OS
z*6Z=Z-Xi||BaZJx!~U7fUk;=&_nq9io2XA1qj_{+a=m@MJy0|&;5S`qoV#r0g^Aac
zmGl6jk{*h3YSrrQ?L?dm1DGx?SQll)izYbp)B10BZI0jBC+;$jA`2c3asSaNaE+S$
zjOrb_(ZkNMX4l=JUeN$@T~2&|gANpeIZ_5Rf;gt2s1y)vZiaB^Qd27wH9SNZo47Y_
z;}P7SL3WB$e^$=o;l$1Q7RV1}lR}E&m+$8r;Wy1W^yEP&YraD3J-C{el?9!(F2C{j
z_#hK}{)Hs~%u@Jx_l@i}-eDxMaUL(yr9Df^mu%ZK{1835y+eg#Z{VL%L688Oq>)Ob
z&jU*Kr5<;ft__WKK^cf*dE{StsqEEjt3XE;LI0Q2^5zq~%=cH<?j`JyCB+5(wehZC
zhA2zz!5O_l0G_s~LYoj-r<xrx6#|7Nx^TXRkH?q$$!o(Pd+E{JIoJae@O0L6ZE!-a
z?S#s`)=2!KGJad&Czz8QZi#2>X%QbMkYR`>S`4KLiNU3%T2!g=S4l*K1N7l7xqtnU
z{PmL<c@boB|0_?*R8SRGNHYJDQ(pT?tKhcXZRYC)noWUkpFLww<MSp^v0v8Itd3R0
zpbV+_UAdY4e~vLUP|_WB<It2QHLNAr>4iCQ;t}NlQ(&;5LXK72eXllfr-{X<0fRSd
zw#)qnDjTWfHV4gesY`>MtO|E>v-^2}DVK+V<%fr(;$S8W_z&`p7KkmUw7v01V)om~
zNfAIV0`0%lM2$~*!C^vT9ybWqU(%Zl(J@WuQDt`JPJb|zaJ=yh&~NO4aOcf@L{nGZ
zXL0(K2ZL9xDK;bgiDs`$O00w{>;yPnS^3)EfXbFLI3G@q2)*7xa?E0OZ&qqvqwSk9
zr1aQ*dJP68Pqd0&-3E-}bPTMSGP|Le-n)9uY~BSB&Fn!mT?tTCm%xJ}^}8m#@q4eo
zjs)PO$+#|rI^{f&Vv>F_6e(8fpjAF~+@3{+^g-QmJcI+1?*z?DapI<q2Y`OKMxdh0
zHD8BSVhk(>Mi*~N5MW4@AFx=sJLPu%8`g?pcp~lN@`h4tJ`{!M_>JILCfFc{4c$RI
zwPFfK5gO>>f%jo}vN1Y+Km9CyAJGBy(+0BJZMcnvTX04c@)x{rv2cT7{>8Rl#RqmR
z<6wmNZ~JY+eSII;UpDqQAvt-H5fq5+m4^d6oWF1?nMEwa?LlZ*%qiX|MkeMVV9iwP
zq}I#67QCvV#=?%WwO4g3Yw!xuKNxTaCU`7QkZJ)Z`^u-R$Zl=|9h8tS$h{H+o)s`J
zc4ZEc@P%kS6iovjVj^w?0YN2`$S^Cw_&<M!(f89iI9kEjwTqUCoKI6F%odn;d*m3Q
z;(bhJA~6d<NHzw*`F&3^p9Qai+znvVSIYT{tq#pxOt209|NpVp_3${HhDj#wf}Hht
zXk}~~^}ClkAeQ;l5PrhytuxTrm4d+SwY($CZ&mEB!xo;nwR~HMfnhQN5*9}h?4T}i
zp81f^<at;*SjCRO>Y4c7_?kgD-!*O3FQPB!^t3!6hTq9N=0;0YG`_ITQz1sE_aI)s
z)ei2gO=mctn63d!1$g?S@q9W$+}8l%ZRco-qp9tz9=e(>Bw?}uE4&EEE{bSx>B6R%
zE0Wb<J?t=#;0{-NU)=@X;iA4&!HWJUC{d>S#N(&$^6DlpK;HC#3g<hWvJ<(h9ZnkH
znLL39r3g~=7foauuPzevg?C&HY0*8h`rH}R9($l_u$${L?h6f7$(ox#YV_JD`QX_3
zjj@y$^MK0IAP4b`>+v>ADI<QuKNjef3fRT|T!W2y*ZX&|xeM0$Sroc*Gau1&E_;Xw
z?()QQhcfTMO{NGOLH9CO!jD^(q;64_iV4V$uZXQeCL(TJh>E(o-WB)?Li-=)ajYR)
za6k_}F@*~`*_7#`v8o-2aU=@ITLe<h!(ogC<hR_g7=Ve}=Qb^+7><G&YYbiz`427}
zvWVL!#YA2^B!h4@F{+OiC21qAfG<c5j>jMfkyy(oAZ5sHeMKE9<Mvz0_#zbiaUl8i
zU8HLT2xhGySr&;9E4%K}S-ZnPLPjU^`UY+X;2PLVt7HdBS2Su(k;icAFI!UJuKc}a
zHrL>YgV|wz)$r@T&s{@HIWY{*fE7SXUl(9rQdL5gm_k6tdf7sXv_mgIeU^@dm{%_;
zh!nwAy_7#4ed1Dh${!fxhzP_so0D|~N8U)bSoJ<~se)X9c-)T#ka?heS-gbyFe?<e
zq()oE+gmTsx2Dxz-<jM`BqL-ymYIL4LrJ8<O^M|P^~8w@kLd&GA5HEWH3#Cz*W&iG
z(-|+|^65tTv)oz-%4spuli~YWNXU{j8xYkiI^Ka}6ntgsWqnANCNOB@UCXKOXz@Q<
z6A`O7ydL4a_z^u3t}N=3{OpE>1SJ%`P;mG$b2N$l+82CEZU<VSeZ$AAmI#hYwaE~8
z)_l@&Md>+(6%klr+&{-9La$-upddw3<o);#L`#DHpy)T5#f-ce%dZ5us0GGzlSeNd
zEy|z)<@)x<NQqZmX+3QI$givd5W}Z9ehnEI4lwH@O85Mua8(7AzoNPifq2-&uPXFc
zY^)vL%O>zi+)F9XoSC+iBkW)&<}Xg*`X%#+n>f7l4U3f9O4V)4sLZ|gNTDoJ$fH&b
zew3<=w>VreH1hEOraAD+>-qCF)3XX%Mx<2PA~5a=cz7c2v(+Dx+`xufmFX<rPSuy8
zEU8#mr0bcWu4!BB$*WG{k&L*%PZR4G^Uo82QKb1F(8hsYJsw=ftJFZJhJ(rbS$z@>
z>`!~z9xsaOMj*JND^<Vecc|&29`!&kEW5SH!@zNtTWUTg$t`M7Qj=f1vpMy#=LwxW
zd;`Se8R9m4FO(>T3x1LJd@O_PYuP8H={?w+R2?F`mmOf=*GR@v>7rFP#7O^;>MvNR
zKcwATDU_5)=5^jr=nT=JjLe;qaQb-{p3Scjd*LtY?ifO4;HTyA_%z<v%!zek#fGt=
z5*CJN9Byw~N_4kM@f*@SzJ2bgzpTAg>QI~0Nx6oi-kJr*wPc4_A}UJwaY6f3cv@d_
zsA1w)-e&e_`VeU8OL;s_Cc57V2?=#M&j3*T&GcOj*@L9bx2i!awuxqEx>rZgcwg2E
z1i118X3*Nw>5vjb(0^a+BQW0qIKR;HAvi0ImApd2fz`wyIn;gTQQ)>A7e$;hshOXn
zX*`u`F@w$RvX#rS0(2yn={rS6jAl}-Yhsr+yb8IdT!jOpnbIMu@bNGfm;(%#65u}#
zUyzF0lTs}C(x~`r_dV{2RBQ+yjsZ5`fh9Q?37&Ns7sb**`jaDe?!-y5)0^oKuay~)
za<kzO7kt{N{V~$Q4NgNw7K6ZryBeJ03i#WCoExodU}B$j3?{XxpzG`oR(_%9if_}L
zgZTt6!1aQQOj;U0eQ7(-8BnBhg(=%yj5x5~3bu%u;sno4S^E(->88%3p2Zs?CXvjj
zZb*<`kH7?LUPW>Klaq_C{AmXX<^p)Z<v0CP+7DFWh7#@zfU=ji3)R243}od+!idE1
zZyK*|Kb<N|<?OWN6*|*;ykgE}9Z1Xxpw53*f8RD|0^7?l6x&sH+p2yw&Q)zh8y&yF
ze-aN4G%KJbaZ!R=nt@8)g4s1N2)L2(`F?6t)MN9{E_eK=aBR!;&^0R&$Yu1(@;q!`
zconCZ^B9m*xkpcs!tiq!hy$i#YG5Q#W4#+_1X}i7+bkXv^9mrS%l{AvSRiT!M+Dsd
zRrd(VSr}4}rE2%!O@5<s^C1vW*%F0!d40S{3Vq7*`9@Z6z!&G?e6Hc~A82_F3u@N9
z*Ytwr-7&1pA1$u^_q*7r>>oY`mjcZ#a3pNcU~z=Bb@ZE05lZ{Lq#5vSUf%F0qaNb;
zq0B5X&$}&)d{dqCd6!1T`@|~MxZszxi$Cv+s=#wU<GVuBgIs9F;t$JsjJ1gZ{3hk>
zy}}LqBPu#Ti%=sj^mDlYzQ*nwaS$Ab%L6a9`1)Y*uZ#0}zqv`g1;+^`XqK0bK+p8{
z<Y<eXo_-rHIql(EqU}HDn!KF{)+v6v_OO<yri(BMWK~#1SQ_W?`#7fHs%A{szD)%)
z7uol~UPaS7r|j|yNx<BwR()EG`(In*PQ=BW7KOqI1|9T$3%yBSP@tzf<N!vyapDm<
zX44T$Tmr`4Rftma2DcBW&5bn-xz<;R62%B6pDMq5Sb@0tnpDvAlhIcID88VVC_|u9
zzPi;nJYRYHYJV$(&IA43=LMiU+s&$@*)XIS&EM%qe0mls8h_j#IIdUXqzIat%neAl
z<2&417jc@A6bFrJ%QK@|nQn7ixt=Ys9J*)t`Iv0_D^?vi5RadR9NHsoKuXg|)3fVz
z>bRJK-&d@jPg;NaES?#~@Xa<su@W-z7``tpmt?^jn@J1bY*eXVz*4L{q!^Azf@wal
z9~7fs0X1a4N;7o#%gu)PcpNL5P;VR#O`_kD$$6tFh_c&#9&`Em6~zQbGfy$XBZrU)
z<d0jmHLGVaRuWO_6lu!aaO|ZS1Qz6quA`9CQp;KIj-~+3Ob1Y}M)=t$T!n}%?^NO}
zEVu`kyR$}p0+X?wrmY;w&@NMo+~Tw&h`_#}DD(I`xl^{(48#SiNQ@;HVPFAR@xJ*;
zfV1<L+30}fBf6&;2H;=U579O|{<tj*MczV#iNURuUH2C1Wrjt;P}Pq|Nki&n{qM2O
z*uXZne7o>pxF#^?3%EX&)_s9E^6#a!A#OafH}m|w_R{m}EynEoq>#De=TbAk<=O@m
zZ)bP)J+_p)$T%?KjGFZwMcugK{To)C_3+3sBNrz+aTe^oH{EglY3_C3h#nh+*wTm6
z5gbca^-li)FR^C?Gl?X$6$d{E9CdAY%f1x}x2aAyFfpP|Ln<JFl{m37H2HRlu_6~3
z0W~}GDSKH(aT`$Zp*p_G6PF0ITV$$VVh;LM(}zgt1<Lw^7)SsE_rnO%<QZ=4EnwsT
ztmi2E3+!(6xEtj&c0n1_&)cZKeUbFU;mE-s@S&g=bV9Q&-j)#dZl~e+V%rq%2viat
z8S7(=xVAC)>sHWEGaV@ueQ-;NU<hQ#<0{$ZM2%0-lpNY85dD$|D_5Oqx#+_z;FS$H
z%*AH_`8^Rh0Y#!p6da0ss{3YnfVx*$YcLCZ4a!%WGKQrs^7A}iyJ}eMAaqq{n1;rI
z<2mfZ?*TI9|D1A>&R@B`X(-ndNTiDMg%k?nEsH{{U}Y9=5)7f`<`~6n;{?(}tP&z(
zzRdus45JhMDO(-Z^(wQ==j>-OwEcuG*zt5E+WZ^`L0Kf)GlX0Qy}!mOKM!Qy@;hK=
z#i-CaK>rB%IQyK;Jm6#029L@EKfi?l(|U1I>VX6L*Drn4L}jDp#)j~wK993g_16M!
zfl^5u+3L#}ntB~R)8HDA(U+FM&Gj4-Q5^wZr)_L>VkWqKO20XrqAq_y975o$B~J!!
z{H!4ZTW%k=rP^)+>ajiWFP+v3PmbXtU7#187MLfm6PqCE3G##v2`JdgjQ6;tAg4C|
zRze0GPwsIcO6aSbKKc4cp+-*i(zcWhwGtfjIKUIZ`}dyFTqn6Se}u_qqZ=GXD)Qi&
zp;$_rC1M_C2F51CU5FB0xtV~M2t7V5`w7u_t!il*N`1>_zFTFZ7os&PXyf4M7I&UW
z;X=(5LkW`tB8FrfQamq^m~P|e00Fd}Bre0XEwiz_tU?~rdoE{96>_KJafs{kKv8Ly
z2~-1qPx(Epw+KonUfuBp4v?#Fmch2hkrANfBPkk2nKBh<Y@R{wGyQ4*?)!hMXI#&B
z)4?2<ldNjK232j;KLWnt$%l+aG2LG`5B9Px9_Eob{&xBP(C-ru2?UbYzEn%80bE#<
zi-hRC5O4bc+`p{$TL~2(0Wn=qFXE<C%u&DXoyzg2{Gv5`k`G;5%r|hZV3X1%<xqX~
zFK`o02E0|D=ely<aTwT{NlN;)_k6qo8TiUdayGJi*YfA0zrN?J&^8fohJn|hRoa1w
zfYHaFXXUFV!AwJBGMj@-amVczWrgZWZsmgO^AeFqZ)E*F&Ulpt;z#2FGsZ2Ep!4)g
zE||ipC5X;|y+F;6MW8D%#|MYt_#-EVK@6$e=}UFG)Qz0e#681K|N43G-4$m*pn1Ea
z-a{(hVZOp)e)u8#*i#C$0oh~|E42FjUR2S4bxeUqWRJ*+Uat}|D=FnOQq4-GH~!QP
z#g*w&>&<At6QYAb4sifT*Lz4)ozESh%!wfCn0!%v2o0REih95r3iP(__!NvHiWB?P
zFw|R0c$FmrSM}Ox<6g;_AexZu(cScCX05zCVdD0q+sP#3(VJ!qT*b3WhV7aa5nwiO
z&4oqb|Gh``3c5mc6j&feEnqqxUMK^L`bJ5S9pk_s>W^}vAnuf}f{(1RL7v0M)=8q>
zzsSk)>k|<e@YaqiO96HijM&f+Ph2?$l#n%yE3p37UR#qN=g==ox^OYPQ-`+prv7&S
zu}$kU<~YQtmidFh<zqvf$JEY1Igq&|o<Iu0oCVJZO>>}E<a$b}#4oV$vOba;ZYxZA
z#A0Z%6`&~{@tisPz57*Z>Vd)M^xO7<m5&}T5a?BAO+=9J*a8l!f$Mfud8#GEA>j_>
zCI5Y<2m%~>Bs$ml0eH0nb;=&l9Ou8up6F{*eD_RHHcIUuO@%YXc?{o~Lt}6__n$uz
zBT7J}6c8q%_60(T9D%(sunGlVKN+6+`R5u1Tps|!+^uoPeZI1fIwHA3U8sc<l-~TK
z#)1B^9fgDwMgF78g^ZKXyokq-u0K}H!kK9=e+xd(%K;c6`)`J@T{@b3F)_BMktG>F
zC=KSim9a)^4_A(`Vla$;Qr#!wVWZR&avYGfX(0{r2sAU~?L{v8E&Mu#y=;MpyG;M<
zH>41k%0JN70@VP}4ZOU?Kq3!#yzpr2=a<(Zt;qQs=#$ol2t@VsU;mIu8{rJa+4eu$
zJlOx#MvV{QTzC7#^QrqcxTy;rtf@6JpOJ7#c)=IrRuotoUQ<p4JY<K|bTk5xV{8xJ
zy<|>7RQ&*NN_*1lqy9eHW{?ciVv6CZ@ESF1aYZa%B$ji08NMG$XGhe@<WT+r{JrA=
zGJ5c0nkM2c?0x+KkX~UHNMRoc4+KA44`@QhI9863b4rI)bi+9KS5`=$R@63Lzg`2X
z`v?`6^6SEIZk(@~5)<V<gYOh^=Rq(_anC#~o&N8-NZFi+d)(|77ys-KwXk5v<B53>
z@cbAtpHg+aTZQOP;(N#Zc@c+ho8;3a?|KmaE2f}WnO!AmNv_fnl89^Q%gPHSZWlLa
z?zM@Eip0o-r-+%4HnDI7jo>mJ81>$hP%3GKv#b3DoDQ9`?@8{$_p^%C#y<u4&$eop
z1-@<SBR&vHLG7^_(^j4}%~pARlRYW|BTWB}hkP_j;fmMR&ukZnYanFj$$y`iTo)A@
znT1&gtRrQ(;wVq>yzx<>MWQuB9svr%LFW@d9opEv@m*(Lu-VI}KEyR0ByGwc1zNR^
z7<vM!Z28aFvOC#E+nT*Qs^zqC4wWDn`J~`lJk$%8WEMT}iu?WopCuVNxDUXyHX8}T
zcfgG^7khDW=7*D@7~8wJ+DlGQ02Tr9wWh_)wwUSY<qiNEA4C_sK8@s-U~@S;-hqKm
zVqBC#TEg(A9ymX)$v0d8>9X-k^PV_--zYXBr7p9!UoBku2@;CX7uU2C8MAKbm47_s
zKTnutvUsT01Hd?R9X4rkC8l1>iAmCV<s0*s)GD|Z#y3{aq}c%^T~F;(bPkU>X|_wv
zBzQFM04Y7*jf3jul3C?@ydM>4J>@H|*Nv_oDU(T>BbFo^adC<%dVO(8yZr+tUFI>H
zO4ne>KORpX0k^BO>LjHYC3`?vJ4PU5?l_?de7Ma-98LZHSvf}g{!7;LkRqZv%JLmp
zZ`Qy_<}CX^&snN$E^CXP<H24ZI#?ftv%O%}m<ZLwT!2MA0gHXRu+x-rQ<iVGz`Sd~
zvty_G!vI!dIbJGtWRPcFM&9)Ha`J}?$w9$=Ack*b-#$N@eKGEDU>bO1_UNnIKeA<C
z+rj%uo))b7dhRB#b);lUpMf}+t6KLCfvuj_!&tWeKn~^i&jCTF1Q@NYf$VDyUzJ>-
z!_pW!{5{}arNBPfYP!*Q>I9;LKCF%3+0=BW6VQIw9jg~`a-?V6<oU!=pw-A&x30Xz
zd6sgtX8v!Ud6)Kwj+Z)L6<%s58#U}(RI7hUI5{WKDJlAMuwHuTI9;?U>sJ(rOIU)P
zFs-2DH!N_PtAFfRgZjNG>pvPoA^RTpbgF`YE?m$}fw+Ax2}%bXyTF_;M&{6U?+=-8
z8dXbRqWaI)PPg=PwKEV!d*B=(Gawa=AGR0D(0oquSMPLlws7;OXWcY5;MKI>vTlv<
zqIJzqZM6MHUyc1vbC-R0wCL!8MTOpVf>=%5Q!?#yzk?@w9!(0K!0V;Pe&Uh1!<edg
zbMxDhvHFyfpOuX__3E;2n$|UsSJ9{HymX*dFT8J0``EYik4{7BZ(V!`8kzO;1o~v{
zrS)VD!v|voIy%u0#I-}{$g~qv)b^dd)@GD1<<>`9onMGQA94{7-1liIC$SdPbkHq(
z>^<Z6YWjJPb&b^?U5&*L@*4kTr<$WTEo(ui?3%GMXW{CP%uUm@6bY`8DM>#a*+LPU
zEdx{nptTw;Cu^my;t#6r#~x+N_>R==#R9>V1Amaw3Z7Xc{*XUpE3IJmug#C}8NVr3
z!PpU@|20xT3%@_<al@k|O<Mlk^)!hJCX1jpa}pe{#cAyR-IPGH)rTp8)~l{68U`o%
z`KD7R9~O5~4^N+OK2f>L^`Lje8+m?LrA}Y^+X&V8R`o!RX>xU7>YSkEhljEx45ucZ
z$zha@<WO*ZIz)jTQKSe|j}({?OOZ3%b|N_|E}m@Eaqv|C>8>5~OiKG5ceM6F$(YW+
zyd|A<94qZF%{O#*Sh{p}aJqD`ue-G0s*n`Ru<jLQox7L(ozUNw91HGwnNnW2FQCGX
z-Oov3tJybJxwHTl*Z=?2&sGal0-aXrQ{H&25UaFa$(x&I`YXF9`!P!J*^-1D_Qf8q
z;iW~zcVU&BkNd(ZM`*v&d=>s|r`6+UH<xp>ZhGsHNHWuF-xuU9c}>e#@Y+hSVDPJZ
z`Ay^8>YIA+vl=URUzR8@a+het%Gv*2!P;+TH8eU4MBHxUOi?}*m*5Z5b*aedDIg_X
zN?)O8`9|l+z^R@i$N%3YVc83|^aWcTT2oh6tRXS{1pT|*OeQ~S{Ob(d`uW!~fJe|?
zf!bJCgL|nTosqHK>NS;|s{N}fI@~8VbXz@-=05Jrt5nof*X64r9W8^N_TP3KEmBS#
z-PI`_1z>D}KJgP-0-?0hi<irn!KBlk8$X&f9H*-9e=xxs@MknBsj-RbldVXhJZ)#?
zjYsyWJ)O?ob!w;SRz|C<vH2Uw4QKgp)mb-xd>voZPr1m+uP{7G&u>LDt<L2<em)WX
zqE+8-hM@P-W>rpQ!t#_Pn9y*#eWYOOV!Abju3Qg2X0N4E<1}S(us*J#*6fv+@nY|J
z%|Z&T{r51nwKuXyD`|Q$@2=9QIX<Wh2IjVlJ+bR}*Zze25S_ktUF`n!#t=+zMuH@C
zNTt<XAtyW(&#|y?nPHuJO)W~+|I_oev$KC=swD4Cs`ekMyuj|OCddnp&YjPW<nW*W
z9I-*N+Ng=$D0A#Ht*=}g{#ZB-;wi$~wGr)RZ9T$s)xL?1u6@xZ59`=U><>!TvW%9C
znx}S4&hGD(%A_v;>zA&Z#))s$2bMr{h9~dx?;4(z=C>N2JiPMRsQKce@@S*t@YBVY
zpGR%`bNnr`nSFr)Udg3T1U%IlPt%qLDsF0*<w{p?<#xw1SBzJfR=n~3!{~_hyiO@i
zA`c81zm)*M%T<_CwaN)f_y4axCj2Ge94k!)8+r9d1~{`gApfriiYm3+t+p$1&AeSA
zUv6YykFRnxS&o)~Ov(^c-uu=n6}8p!z`e?<&S}kh{duR_fa0pvM21v3hF|D%BvR1s
zXxeez>50UwPa;#`fy)@y?x9X$AgfNLoqY0!+mD6N8mG+s%gX&$9GCL*e*3u>)=lrd
z4W;Kss8VVN3wFi6zAKR^DxVg!e@Ae{ROZxt@qo2L$p>#)#_72Qt;X+$Ej-kp;2>~o
z-`T9c{%27DzaKVx{tvW~K$!vl+bCe+r?^q3sY0YIlYC)Dmmq#XfF!iQFl5_X4%4EP
z8^`eZt=F!?#9;Oq$nZ>aGHswDz@7Mlc71GA2b@lH)iT9(r1qAyr`#-`NHObQ+Dz*<
zZ{e?L(a~YKFZxGrOlik>Nom*4Olcn)P3dg-)p#~3mMsjr^L=y|7zfldA*Bg6gV){m
zCdaV+N~Ut|K0q);DV2QFfP9i;$sUiJ1d5JKy>sSzmAi;Upjnfw3bVWeG3?$swjv0=
zi}n+ww6#lC5!Cs(JUEs@RcA%w&Jx`fruu!yqPvt_O}fZn%%K>N-%6joyKtkhzGK$(
ztm`$;i}dq=r#+lbH6981*;U0Pf{mIrB|jcTGl(dBFl{oC1wPA6<L1V{?+oFD115h5
zteQ-e3bKNdfv|q>Tm}ToE$|V+bi7ZZr(m>uLVyEugb0knaScAX<=;#aEo|(ISys6}
zPonb$<z#Euu+TL&n0@B}FOAe8SJWwXgfmw5B+a14E!qBOV?$rcTt?ZgDaOJIlHOj^
zDE=^ZV7lmu{F<sZW~cqohWAPL@@ipDOoXQp_&Cjg>u$$!HBw4GHlRNhc#?zX<ybxs
zn?^{aEDJ<WoRJ4b;GrxI{)@bO(T=|+-9!^feM~ZS^O#B2iT}e?Jyt-#F?i)FA`orJ
z`>|?ikY9T5utS8tq}h14<k@-|@xL2QSrKPnOs`!ip`_0AvTS2MNog<bChP1Gd>!kf
zy*1XZM{e)nAynrIl9P{P`)dtq?1gdLsIEWg{Ll?%E`Tf~Q7XlDgVezlBuKF7CWo+0
z@&CNa@rAw-@88e&HZ&L=IRNzkSkq=?5chRoK$Nv#`(0dOJC=9T(9>aIc7ck1Ge^H{
zF=vXJe(TRcXUtvWTF0Pu`HjyH=qOYA-##E^ed{1^&PTyhDwl>&`BrEj`1nyJ3fBRI
zws9Z|{s`eJoN*U<)tj$vIES<mD2spV!*vyFW~uVZ;>VFzMvFP*buPFng=*O)qR%Xh
z!(Kfb_`%;+=4YalTwx-Yyb*Y(^t;205F~5Dm(yha08a8&!*(w{CgWwdNh7CKEB)sM
z^@K4;sV}Tzm;a_cNfy*KX^QxI5I+{J^#H23{>mf{be%;#KVZTzq>2x^;T<tNH^Qk#
zPls#-H^jgQiOes=z`6yU9Gbe5rQ93(QEzvv^Xc`ay?=G2alK;D6LbwzW0ugF5~$(+
zZX@e7m4|WNQ~g=EKk!!aOdx&c19IcpdJKc$rQfN9c|-Fx{pWwQV)cdip3TZ-mKeM%
z5s<Z<hQdfNpw;@MP93F7XE4Dh4*Go1>B~StFzGS+&p8uC8WChv`z*aA@s=J_^%-NK
z!vB5Cx4PW)8Czbh`)je7v+;!)XA1Blg0|z^*i#bL%bV1fcysPq`ClIh?u&4{cft6_
zTLiaF^94`B+}9N4ad%09iKy}DM!)6GA%!$r=z=lt)~utz!re>z{M44mUY@?C{hk^t
zQBFxBI4HbW${oz`03R6Fjsni_0yNoFp2O7vM9r!lWk6=*z@_5FL8<nzv5>i)nuS}-
zaM(>YQ|sblX34IR=EL<Bk0!%jjTCbC=9rl3)AL%dX5F+&>7Ff_c^~H@3s$F^>bS+0
zOq_A&w-)Db$c|^93IAkAUUq=ISoJHyDXl>P1SQXAH^$ArycwW3H0Z^C>y{iR={FGm
zQI+!5OYM7KS<~X48ViJ;7y)2XEdgfws@Gj(w!3RS&Q7(hRhj?%w*(!urbS%VKV`hc
zcL~X7-k|eH-}t76_+gJpHlMt~T5(j@<WltU8;`N|a;sO<?LC9*O=XWNTQ8>__l}Kp
zR8FO#ZMD+_{=-YQn7QB1`4+92j`kaq%iknZqJbfAF;}+6;9ORQns`f@ok4<<Bm^Xk
z53^YqR*hgQn$8a&VSZ<>5(_8g$AH$r^XJ|>-GKk7?DVr)|DIl%ajWXhfBdr6-XpzR
zE)`xM_xYO+rtkj!HX^+letsNyD*Nfj_z3=Op-<+m7lJB1cLEE8$s!0A#?dEf=RPm<
zTc`Vf|69Wx-1%**qt`Jae7Gm->LP4vl#7{e@b~VlISW7PAMd$e-W=pru*`U;KkeMF
z^_)#8b(Ww|G-d)*le#hP@{R>c`#zF=8%17OZ3Y#wR<i4T<QzfWb5fz7!jE*ALLEfp
z&z<Y!2>f^%Ge<#yQO{1qM-Ep0+I&AN9MYPJ4ET8wE%7XJPUN(Okz7*NqGE6T(Cfln
zurPqzHK6Q;or=cfthAdHwC(7hEj>AZ_z;3JdSaylbC$R6picZwo7naJf?DQg&1jpY
zG8_Hc#^h()0luE%Y7@}rvIIcr5}R*t{@bXUgrXKEHSZd?0T;>5D*uDkcbif7W^xe1
zduMX5bT+0r#%p=_&pSr0rKD6<N92F}`|YmPi$5|dKhTW=^WHz*WwxH$$*P<h81R^7
zyKJSnK6f^Rj&U#+iwqX^og?|T^d8U<_F`{7&g(S2+RAL?15MB{Kg#Oa)g}C^Lsq%H
zeKAaG)D|5K=?OtI=7zxe`o;7XYpu%6woetA)%T6dsb|NGm#Ln7KhQmHId1zy*>;~T
zAH3K=@;@`Aef49=qr2Q+kHd^Ts=8HFG@RrZV;njB@83*1YMH8M@2NbrJ;8B0d1kzf
zQ875usYaaMW*$V0+8qWm(JcCO@qP&Mb^9}X|MD}U4J`lcZu!0kY)pZG#AG0y26-Dq
ze*ud>L(09txwh2qd%?68Jw5dN!gmaCFKYzVA)ms<f8P%s1Sc=q$&dfev3&DYCF_{+
zQj^`2J`X#c%xRt4nXO>SS$#+*r&3W_9oQ!Q6>Hq_$6o{QS>07=F`npSvM0Kl_ZkU@
zIKI10|9R@t02$;nN)VQf*v9@uU}}P)uc@5fkTo9W&p(yhL&;dv)9%2QT(a;7AAhW;
ze*M+)b)YXbJ#x2l!%e{Ea#Qfodt9n4%8F%No(IaX`u%b4ayal)XV^;A`119hJ*+$=
zH1u+9CM@>vvZ=no_{i|#dMV54=i;du3*$jk;nqg~quHkj4t_@9{X(}RIaQ#>%xaN&
z)3^Y()rEz>;GTLR&#{BK{xD|$<&C%$MGDz{O(TeszP}d)IrT{*%*a$;)b3L-cMH`0
ziaC<2yIa?bz%+ZcVWS=&`qw{?l{Trc@4?HMTQ$FX(OJu3zS=Y!xV3fY@BG8_UpWbc
zT9(eSF(kLh#xqY5Wu)J4^rX^<`2HzWC2oFQCxD)h5riH6U1t7YPiGw#RrkI90g+ZI
z38hOyKw7#>x*MdsyBq10E<unGkZu^H8|f6JyIbnr<NJJn{=;>7&CEG7d!N16Uh7_;
zTLdClYBp?r_13Ss6G5>0_u5+<1Cik;msW)g46nMPz4Q?o|M1wTS5_I6#u8PhjxAeC
z`_+>?{x<L#+zey&?yK7*fMl9kERinMj$y93=}|*823?=fFFe!XcmhGMTYji1%TFS7
zNbTLf%C65@-nw2I<-l+H34bldp-So(P+<h|@B>MD%;<QP1dz>;P?4h4O9bgQO$NZY
z0)dGiNNV8$rV8(<T`wSCOoAlaD!l(TwmfexcP}ksg_GcF&#kLjyi&}J*ZYtA&!nr7
z8bY^LIi9&Q#1?oFLD!sVQ(Q_#2K|q8aVmUckxI|T-%|&C2|;_Q^g`<$i3RR)qC9`G
z<MhCdfd2<-WJA@G)meQ8!s&MpO~$w1No$=9{YJ`_w-!eSTpu}x;UPJ$Z+js!0si;L
z!8UN{=*-s)eSh^aj|tv>bTcs^a<(*Ea9Nx^(Q;Yn;2e4w5jfb|yx$@!Fo>!f={miP
zA`&s@*B-@ueWQj8F@K<*`=N?9s~#EDaOBiXN^!jf#R>x_2@*B~I#x)RC#T!tVi-D7
zR1h%0lP~5<NOs#d1G8pX6YgdifD~PZ*=OA6u^NChlO1^TGyt;`$nO#xZI^e?aohQl
zAA04EuPMLS9S$ZF*CldqbDx$y`;w#O`OEjw=l0BOUo;`*;EMm*b=I;q8krP%A>q5*
zPg#;3M^M|Db=GB8D1mu_*TTac)X4fi!)`|vaK(&1=k1(Gm$BJA^&FwXxQ@{M8XJBq
zCLzAJ0C!?#$|paMTdi*WJ-I6J%@VrC<s%pI<AMP@+sP*;B=6q0k36?-`c;p9X+Qbl
zQI~54u1btrS?6<18=2<!tPGDN^WK{?1@-=z3&$OiSxPw&o-VYuTHm|0%9&3aV={pk
zC7C@^F5firf)Ye-K?A*y9s^6SoSs`1I?d%QfFw*Slb;OBozH1Xx8v?JW!C-dL;^?~
z=;yZtX?ZZWz`;`;^!Unu7*2Y@d+cBSh7K%A+GO9Y9`0_kb^Q)4fl<P0gC>N)_y~H$
zulgs`X?(HDuLl|8M)k$riKBTWJEJ+WCH$h&QuV+wybgm6(g-vcs<qBjP@P<o+x*tF
zyMpPQGoAatOn6>9SOpi)j?hM-7_LNuw#QPRwOZUAL=l5v_3Xt($reh7M3Clgt3`MK
zsI(H07|*UlNPerSbPtXJ4se3XhU?`-JSxS6T+Ty!rR~<*sDPL#@HYJE+uvqFt~6!k
z!nFtqI8}Ga8+7s~ynfvaSy&jK1ztQvKMt1p+~@C2O(12DoWAO(LySwdj~~JYXy~(=
zLK>_zW~0y;22epgX;q*&2ARN9$}T;ihTH|vnHYC_)B?PBX+7W7%ao{qa+^vsFCa%C
z;TLo!nlGeYTdUI9;sP|~Na#SgzdsC9p2}pu*PJR=*kZz1#Ej#j6QuF8t-ACvd2@I^
z`mIE*q$KqDtCDQ*T`3>pPmWHX2_Q;68~l6X^g6kVGF1b)l**FHynv4aV(dqTfId|K
zUk81>YmGd7L+7CVEjr`ruVVDjtt6%&h?+tBIkZc!-z#0;PK+qEl}ce>>{pNWbe*Q8
zv14qw!Dvre_u0*Ywn<-IpC{Sm_<y-;%vb&MXrjzDzwzrS)a!D$cx_Zt7}=Fk0@a`L
z9_AXpe-eMn6y;THd@llnAM)QF1Lbx6B;3z%fU`|G2J!A;I9j$#e(M-jiVhZYL+BI#
z9x7hzNg7pl{WfQ@6fxE#2AS{8X~}9;5YO}jy>O&!6V-RGtOlCc_a@_fMN~Q?UzZRL
zmxa3pvZDx?BRve}+;wALwpCZx(X##K$S84gAaYTy|2{b`CVg?y?t-}^t7r<5#P$bA
zFw#=ygiE{Ncu{P_HC0;R9{v}!c7ljo2@QUSNCs~GqndF22bd%!>CF<Z;8wd#hfs5!
zjp`w<$D|z3f?8?7&ehKxSL!p~53?HB6YN1qpKPYWKBX`B)V{#M((%(g8&o+YY*fuA
z_fUz6=XxkHyNc9ZK8(encD=#wb9%Tp$l-y`&2>#w7q`4TE6JR5Ea7(9EAnvK+Bq8y
z7U){_L`L*Cy)%^&04OhwGq}P0S>KX>;te3p$*x%jB_Sy~gmRF=QT?H(i}$e3UN1uW
z&66}PKiPhUT?gX)e0s5L+3Bd&GS0<Kw^@PgclcTkysy@k_I&mT#Y?)P@ac!{r)btx
zXn$F_W2p7wj8G<(4-LD=Us~>0RF;TU<CfS5b@)wH@7e9VYPRkp2q1=QBlVNm7oP5X
zq}$CZ^d(k>I{2`cF2Acae;}_tE6@7d^3^kd)&pnob?(qxf0$7=VCsly7*X{2gEK<G
zBCq=o_HWAc>Y(sv5;EHa!=?g=X7fCj`E+F7FUp{<1^86O1Z0;wTg^6|B)%hF)!dIl
zwL^^icZo;|tcGxY%L_iA>}qO00y@rRH{N%kJl(xdu#VKv@5OOr-jnCW)y4UHaac&F
zUQ`;fPLqe4!cgj{n<j0dZH!0tF!_A-kvV8}z>w?wl4QCiXTR#L{%kFpx|uT9?UqVN
z364@oHJ+M@^k-FF9yisqt>KyOL@u|6ofVxAT{pmn7Utf)3$jf!oP8@%#a)kCTu#&*
ztB*ZV1YbGqmH@^mVLrJXdVgS70tz<VBO?bG*D#qf@RFcef#9cl3}oHw?Uj3kKMgwI
zaaK@$OKNGl<0&ow7aeiAI`aL*K)GePPKnpilI8H<3rncW8HAV0a#cFGd6sZt>)}4r
z^Y2dK6sSM^sI!^-HeIGwXp8R_w7XQ>T(VTuG@v#GA9TjhIyvq;_W<98bkH%NshNcE
zJkjbWtKVd-_xN}cV0F8(H6H&E9!h$pqC~{wtg<E^qfDPtrs8JXrhL%q_Jf$7Yimry
ztQL5b)i3)tgA$p>tPzY(NO4-?t~sl>OYD2njRzJ~_y7PaQ>6OvS#prn>FlGRdYrax
zBUR}|)JurzI(ZMO{en$>G2`#%@2k_g*TB~EdwC_|&Vg%vY^?QO+Ja7l-2L<+hcG85
zmcFNUg?gO~foju-ms5U!1VL@atvKjMTl(he1^0Q#cbRKzp5DJxK|gj63gh<oGt9mV
zsXtSaeZ@A`T|Ahhtd~@IsXg{rO!bhs@sUogwPXC=^(vBc|KX>cRbE2|#p7*f-Mo*{
zo9h-kw~P1Y^*vwNm)EW7%%GVi_7fc?&Nt&Fi(DHjNeQYd_uLn%IoUpwHMA3xM6VBj
zl_BcajyRAG2BS3`@D3rvu*LbrKIdZ<J>wu5TmoEQ3vuo$%RnvFN^51$*akF0hkYkK
z1_sVBr{5+*{{^zRyaIv8JEsl?|6D=%aJpEHC(I5(ktqzyd|u}Ycwohi&`?kv8MjSl
ztT@Mfjh?7@bVMY5RO=jCV8g&*WZ@vqRHmh>`x^?aJ63E+OXbg!TtPOJXFnb+xkJZQ
zF#95q+}TUwrNejrM`X7RfCl-RuZnnVn?;73ERtVwyBAr`6lXORorslaTo}?VG`hZ6
zN=VK&v+$Aj(&io;r%JZ1Ja=fmpObKHZWPt*OK2Tp<@iNZcTU?Zf5MQw^s(1c&(uOp
zTH56HJNw5<>k@@2;S$fF-4c`LWJ|$EI9LwI@;?3IFaADAg!45#3i-$hTudrkOnZM`
z!^3CYopxfvha~h5&JvX?X#R}4DyAHAiPw+@3#|9E00a#6TGEd<ryJ!Vg45wbaqf7B
z>%yA7z`)@hX;;GWDUc@)j=@?9Oh<EmAU-E5Nw2pmWVHSzm{hDNqWWD!k)2Ud*rh*F
z;-X&Ax)hk3fqZ_J^H{|>oHR+*xuSNCBkz(O)GxLmgF)AJM>bhc;!#(cXMM2n)#tax
zj72({N#&Z#Q-CL;?Y5gAs^?XvRbw391e)ik=%=~IOQJ6>g0yFBDvERmNBIg9pS<^*
zTh_>!UDmLzs3_NL6(7!K)|PFuO?b8F2h!mMpDevJwOur`233O4UKeq1O({-EtEsEf
zsVF9WS5w>A{j9vj!K?n#T2o=;AXVMuC{5R-c_1)1H#z2E@U%cWey9?7Kz@Jw+Zb<f
z$!O=^RdE$*zc*Inuem?JNeY_>TiBA_UeG1WVWo5Z{p&sJD>|r8bt~h{Tt7B$y9tz~
zd0>JomTtD>3*A_LFrAl!rfQ{@m}-IHOVu(Jb{ECQNR@lKizyR4-EUf)mSyGJ&LOYt
zry%T?^Ocr8lLVGGRU7m0x4`9RXKx?qLzR*Axr+3BcQ$GocrP25M>Yf@#&<j(r};4N
zL=7X34S9go%1Ai-4UP-77og@XN(q6#k*_qzVq8QHF!d>N7XWzOxM^lhNUACqj$UB_
zff_|ARu?|sLl-u8n=Pn;TVABITOPJ}Sgz(vahrQIxXcW2ym<9q;o@*g`WZ2sB>e@{
z{V|kQdGhWl+T^^;-XvI%cPUBWr!*M{1wdU`&b80l2Vp+JPtW*VGlpmjt@osT0%?5Y
zwN475QOpH)tUxY99IUW6;=Bk7l>CphLDiNUbhY+Bg<Z~uGNyq4;RTnG^L}b&lP={}
ziZZR1x5*EB)knDdiB^8|W77Lpl(je8EaaV`&y_jl8WovRmK#jw7+#s*9N1{r@3^dZ
z8~?80PCH9*F?*fuyKB+PXZ?Diug*~Rg$qf+K;!En_%PK(<5K$`g;o5W=Nqne^1S%~
z<**ATwCt`c3?lssA-oo*v+mP0=?BJF_qX2xx!8;=47jsUl<Au#VBwcmnt#!Vf}d*X
z-MVg>C<ATw^SjQ98E3S|nU0nfXY>>sXOR92P~WB2<fP?w%?{e+MR%?oa0q_}NoW26
zWEZ<Y7K@H%zWu7>M7p-|0B~nY0EbvgA6TAX&WMmkcS|SHC8;s|j&_TXO=laMe#)s0
z5fi(&?(TvIlFnS`vSCqdBRFGgMvaOuj2l>o4L9KS3o<WaGm?Pq2>23V!SDeMmSJdJ
zd~4LmY~9~2EF|Q6L6fjagD((w<()*kP-WDBhNdb3EOh@!JSH{Jorz|(PicDGfyOjx
zWL7e41`>&G-Mlb+qO{0RPpL`N{GdSXr;<<Ay5VW)(%tDvr5K#^+}GnJjB_ZFA(el1
zJ$DKWVv}H=Ldg{>i7@6642xK<0sB(&LZk#8pe;uQEYNah0ZxN|$A$={{{WTRXj3O>
z<#`$Hr~a}%@Fd`^PWVNn0K^vn&31Rc|9C!_*S!UE$b#9xe9jmI?Xd;)L=6T@pq=C-
zUj~qFGRAhu_Nh}UFsE$*D#8qoRA|?jC?X=FM}oFr*djiQ$8F#tED=5cLYkEUG}GVL
zm^uTX;2`uJlttQ;jNEvm5&V~dDc*j%3+yu&#f%Zr2RLv5rx@JskW2E1s$>Fursn;s
znyc;ccm{0_pr2<{R2+M60mK9sE<hH{KS$!Q)N8DTN25S$EswsO!E7Wx0QoZ41J3a!
zuyO+IF~r5g@$m@1(FDq7`WZW*6Dk3nvSzh1SeTgMKkUzvEawWsaTkGx-tL8$PW~kc
z=V7t4H>`gR==yfjEB@IW36e5|(csJO6A_r$4q%AWTuPk|0Qc!k7Pl61@_t-YegLY{
zaup@)<(L@cASAO0K8bTbRC$Fa^*OhwAp@31;0zjrb*cF?h<*GGuVqTqc6TcMo5y{!
zNOAXkX97NuoE!zC<q1w?vK7Onu;d_M$aFjqud(T7D@paq9RX?SUJuNxUB4ej@rVG_
z2Vl+ohZ~ua(H<l(U_Reckx$~or9>%x12f`F;2g`k)hd=Y`r<|I&nM&!4%AEi0E%Dj
z@n+OdY2f`BNNE6Usy+~-gmv8-c0OCIx6_}3Wr*BX>LL#TOOG2H=3Z`A)*KclY2Eu|
zwLI)4ZuoD0U6|BS*7dz3;3Dxc7LKP%5MBd7oKB-H>_ADB5BjqCvrr^^(maM`gPy}p
z8Z-0UnxP_ttGK@X;)TJ!wf;9E3&S#qohfsisSmgSJNKumqy^EqDYtsM%#;^`aN!4&
zpiUW#W8CU_p#<EkGU%z{%y4G`=%jqU&gQ!=0**?O)CW<@OBis|<xe|YW1S%>&YWJe
ztIh0k=WCIhR29hwds80exW%$H(B3NfK_^UO0U6nC8r@mh`w#G8$Th-q1FZls$51YN
za&l&zzax6SHyc$Hd7n9#+(o7UEiUi%(reoWq2VkZPLs_{AbTzX=+GulUD!EDoTgU^
zpiFgHdZM2o0;|5hBt~8Cvby99OY!h9cNbyta6aj$S4O<OMKE4>w{qy-L+f^4q>`xs
z=H6_+6gJRXLH<129qF{&yq)0BHmb9pN5v!;jbFz|IJ*&{VtJV!UL`FhL;GzgpOJ2g
z)QFtR*pQ8SJXL{~-HAZ|`Htj-1)U{b{Aj)@_2|`Iwr1>J*3`V$kJ_vGz3WHa8J~mN
zD?O{$Bkq>bTfd{PecXK_7NAk|^<ZK|WH0EM+!gOP06osvKOaLdD$l^#E+bKnyT2fC
zTO)#q@q?5)?TD8fh&R&!nTd&h>5U@=(A@0@JC^v3QbNS0J>dV?`Q2umAy$2HX#bYp
zZm18O!TBaYLLV$+uiv0{>IY$vbKrN^f|iC>Oy+Vi&|_gAj{;TeIh_TEoiwo4rUA{o
z+4=m2{%fu+Af1wljC4g2j88&K|J3FUJeJ;pV!XZ2UnK{Uel$vN7Vm5OYVgLeD@<V=
zADMVGNfK_%1#ULb9(M*Nc5lt$_3apZNDTViF~4jM|8E_bm18x(G$f)FF92D98Z`Sa
zdLbzt{4w!!JzTT^!TUCEAgEa&pkm%KgH2QL42Cs-7LLUzs9kHRT6z)6LDNlumlCu5
z9kehuIOOltFv31efEGc!>X%>>&?uUMB?PnEkPcbxGP=?cEc%>Gt>;P~4hk`fM}VG8
zR{|o=vYSflJxr#b;LV{`k7K4=28@#DfCXU>bQETYX?2)mD+xixr2g_=2w2=NO_piT
zT-c*-w&o|`=LfJov&~?$Fa*W>3w<){tl40i>)BkQ@E6j%8no9w<Ol1V&>PuGV(GE4
z7oSW|y}ITH-Q`ayCk~n^;b=sIgI?kPk$phTS~MF<J<*@wR?1DQ`DAbfIz0=x&W2cr
zL4)!TIL3U(&cFz1M_&Mk&E4p*3c2g${z&R^h0NOEWHp^sQ_pVpvTpY*fJt)DI)oy8
z!4UH|i>6-z+d)HP%uo7O6|Ke80B?~0YtRw@i*g8<_64HfF-`&(S?I2d8{Wn+dmtTg
zkqxZ!OEhVN%IGlI(<$1ZG6ysx*Sye?UvE7DFr9!Qb!R*-BV%tKt$-fOUs%+`MaD@U
zD-VcCw-S7UWKER&Df*_aK%&(E0H6*M>Vbr``171R+3HU~vNez4Ieeeu4mBUkGbHF`
z(QB6=@u`^|jUVaBkGQ+LBPpfGZ;7L51d0CCX>>m*c*iU#tWtfQdHuKglsG;#apZ?G
zyh4~^SgFAMjy$7$-0{0N7;=)u4LQM|cBmvTj==^w3_dgeg;GA>`H3iGd?*XyZWX^9
z1?Xd2_aN;KN{d@k>R#aVI}F0Z+aQ;qcpHJ+xzUJ=M$#~l)!7<XU{SqOd>eM%`6Tra
z47VbDfEbPC&Uit2G21=D30?lG@AzYs4+Wcu{7(QmCR@D^?!$%aV?OQ`co_T4pgkQ<
z<~wQ%hYWhKojm+1zeU;Wi!K)zX75gS$>^Sim%fwj(LXM{ou>uEp83T*n1cn!D2j+@
zI!j^OHwRUizTp5Q0@6XhR--HDIx1rCFiJcFJVs|CEOFwr5`ssJ9WqA;p*06gkNHaC
zua%B~v1n#&;!;tP7HKw*WP%FDq>G?D7}z&FV|CtE*wV!Z>d>1#{l|1H;dc!$RD{Q`
z)4j!UA7I!mlI%V@xUey4>?0qGu($J)1tmr3c>Xv(*DiF^El{wQ{)7Q=3FseENq}Z`
zt68{N#xojR;PZGM95^*QsK=-fRryyatOiJjECv2NU}?B36u2*@w}*8?c-)=z>Qa5d
zNMnRlX4p3MtG?`I#fyuizjOd{#X}EFNt~F1JP4(HYF^xGsf5a{l47P*2hA*Y9Z(wD
zhB{M|gI@?fWEvD3twF2st{l2Mq7PbtN(uS5`LwpceG0>4uovD7$;F)_iczBow)iK}
zsj>iYVEEwK(^lU_(@@UaW)P@`T}dTFx~fCANZ<$u9S)A_fett^F>#GL#JD3JLuU)N
zr6;DOY@Ld-zC;luOMs{+*O=wn>4Rp0%qs)HcH9J+eklU7YY;Iu=G&K07Q0i+M^J7D
z9x{nGp$ak%9s7@w#4e15u^x(0oq(ud7}OhvfZl$XB9_+>cyE$#op=Goq%6?C4}mho
z5ZFH#A1-$$deMn_XLU7Bu8hM4E`2~NHRJtP&~3*^j=5JUBN4zl^1gHbcQfZ&n?7jm
zb;`o-+Z$PTkpr_I2SfYqw<y^TG$E@rAg5ktC|yD64c7|`T<DA(15IPfm4;$(bfjLr
ziB-rJia&(M5DJb*!?#JrJ>dkfgL)FS@T~?xwqu?S1JDw7$kF?ZOwA7psH#nCnYWbE
zca=x6e3z*Ug{!4V`raoYXLp!OBl$+z7yE#W#Icp-mi-zMxAW|r3KAkoMuxn;rYOq^
z)^(?8O|vvui0HCk_|u7QpW^leP^%ifdjOxTH*3-SVHZ1}3PG$1MbOS|(c#mX<;v5y
zyKUCZAY?QB(;mPW997YwOw0&rBq=6d)T^~jI=eIIM~7owt_Mof@)w4sz4TWmx*daQ
zQhP@^k9TG>ofu5Eb);a9M4$=F;YQ_seZ)!R!#9RHZONqoC?w&iXds^dC8rA3)zR|u
z1}^4+>GL9t9dZb!F*0XQCmDQ16LfTsLTCF?oJ_R=vhMm0>D^qTAMo>t+MDV1cA8i1
zuA&B6-@aCX^$*`}L$a6Mlyvb=!c*Ur#LMDUfQKL-1(`1RrFsda&4gWC%=z2ZunJ?5
zhV;X08N#3ReW?tmNEYFV*70<dkgw08$!&{fnMy*?dI|N|da}plF*>dEQz3T;c77Q(
z@ECRd?wr%;jN~(=nrA`czr+HzUcjZ%;?1!+i(kVuzU4mZb!GCfYp!&><i$(~mfPL|
z`=}erHaI;v=!x(K_b&>RY#+8>>7|&D<m1S3Wb$_OZc1T9s9^Z(QSt#@S@|1cJwXHm
zp{osH>#i_NTLFv!ozL-jcv29<_4^gF98h5eXnwCeRMy@JcZU2#Ab_6_Uyw``MCHz=
z)e^b8(aYWO9Qu3z&5~g3)0@w=EZQ?<;BjFQ#ZPE&0Y#0JE;)7IgyEBp-@t0obf#Pv
z<)!XQ2-({Pcce7tfjsH=w;+G$*1s;C9|1WRA7RL5;WZ8U9h;r4a$L=nZ$?^#5wM?f
z^d#(B#G5R;ME%F%!)Bxi*2ay9b)CgTPi^+8U!*t$KAU+7O;4U$hnK?lCJJNa++uh$
zQUP`wGRTOzpGeS%qKiNw;9y>15y&LV`vAh7PmI5<=A${U(e|+<1|xNE{I3PTN>2KG
zkBQ~K(&!I76N<c>K!7#xV`p(I{PJDkuX=Yf^%-@1Wt!E_pBm&H?bbm)fYl?Nc@^LB
z4Eoy~fz)Va`$Gi?iE0Fh1+M=*dE;;4dgOFpMFj4nN)&&5+W&*D9Q^vTZ1>f0#!ul7
zzA_KT>Yd>@`o7TjV+sM`g}ET9Rz8frsv2gDEa(fol!sIis-pwD((MX5`g&PR1{#hS
zql1(U#y{a@<%f`(cDAO4pa{lD_jH_idWW$Q&G6dkSf6SkAMLFw!7CtRHgyz|v9F@N
z5CUj%nXQqm-@*Q{DCqm9B$`zV-tKWC&l`Plvq}N{sifdK6sI>@`4RhA{z6vMrD=c)
zV;S%$p%6DA@j~7alBl_k$@q{u9-otQ6q6&_7!{B3MIgIRzw7K166^1n>OXB*s)Ake
z>1_Ql<d0P-2r=^BVTMS=U@%WSlhhGd3C3PL4+H?Fbb#rfRJ~P-*GWgSxOSpI#{8Cf
zzQflyiFo<+2NkejqJh)US{pz9Fmc5)m&ceKI=v`<r#Phas|{}*PPA)tb2EKZ;E|Uh
zghW|Zk~z274V=_;GVsdKz%vkrAA;u%_Lh+#K~+jUE?iY!iaX=Gm*K}ND{JHPBv|7o
zA22+P^q7fmrP@dYd|L*8Mr>XnqqLiM<0Q4^Oa6K@!s#XF0@vpy9D&q}*ehzVI*lgi
zm-(x%7;HS{=JZ6l>@T={pCF>!6DyQGfn8APV{Z%*V?82VXi8ih<{OO7r`X)zo<$v%
zy_8qPeQ>Yq+~$RnxTDf~lQEMpg<e6njY;7&2!*;Q(N9fw&bGXs;;Is54q@7bK>_KB
z`$RqU<1<vjm<f{mZHdjQK}PB3NLAl)1Am=fWjU_ya95%&*hLY3q9DkVO+|xbgKM@h
z0>KKaV;n|AO<q_{Sc-A(bHBG9{FFb|k|^JN2hpu9Nl~C)lXG!~F)1?*9DXF(9c;_&
z`8FmT9Ep}*QJBE_YwIpPG7PEo-Kf3-gdEqRTeP_du$H<uQe`L!_XyYAc{KI!-hUvP
zfnA$YH_5B-WxgN27~$LTTFWWNj^haW^7puEUclr@_pxJq9;stuojrac%q;lZ<X7=%
zM~@JdS8G%_SpFd%Q}6z&lXJ{6Hdf-uQ;BT9oZNbGA~B+`m@Sa=23B>(I~2QfSV`XP
z=s$YR1+AHA1oc+kY!Yl)XQ4N6G{KSv%*gJj(7(I%oZ~U?UPb2uh}NNSeefLUxv~N|
z029!oLNs;O-Som8dG-Osdh4giJ80rgdasmOrwl-X-(jv?(hn|7vg20b!xLp!^R)Gh
z_v+<3b3T3vn%gVUb#g<ioA8l=vF6!N<f&C3k&9I9LJ1d{V&r-Mg2St02(j;yJGTb|
z*xxY7(Z#z~iobpdihFIq;hT`*3_NhSV$q(GuHT8#zej7*zxDzDqst0(1~c#KK`#+w
zY@7w1jNO+hq!k;KPVkhu-{YHXi|PN`zUl4j7X1`}a>kMneUA9|jO?Lrp_7%M6v8O;
zi&4LAkq@bN8bk(4r_F?mBzaGU@CxH$vMMFR!$$Cw34dNif!Gldcm9Ar%*$#wob<fb
zMZ=eCXLC6iFNhpuIG0*J!7{Ij|Ja=A4#@G`&P8VmRl`7k%RL(Fh{CE5@x+ugz>d!D
z6#D~?5?F`#Yqy8>FhqXS2X98T2FY;h&%<}xdT4k&V=;l!xHxvY0MI*fHn6vO^>O7>
z90W($xB(*yVM&;pQQ>~j-m8n$XyZEk<5v%+?B~3pZE)67_0qG~SJ21SMu0k4l;nf*
z)jfXKzaKyulUx|@r}KIGW%P##LMWQxx2d?!^r8wTTI{HFv_p{EBZ`U6I!hD?%ocp)
zOfOnHF(Q7~=-2X1<)we{qSRBed_W%BHyU1kxtRp+B8)ub)l29(N-416;!)h(*l0Xv
zG~k(^`Ljadhis?sPO;OG%`?7?K?Z0W4rEq!-5gSVW^!*AekS(2I-h<JfWtq}W)^{k
zg}q&PcyM74qR4^>3m|Bt2>qHi+v$Vhse=*!0w3p_$`!HS-N|8I*nPAKu045-c8q{1
z@rrANRo@YXga$Ylkcoy129GfY?n<U>CSHj;>GP5UKm;4;M{lEttRRSXI|{wYv4_L!
zrw~ewSU(5-7tI)CNfGX-bI;4n@f$yJhEBg83zLrbhQqf;m8BW~6a=W<>k+hAl{Vtl
zPa_oqlR=EyVjApnzbvWy#{v8b&Uyl-J{06ZT!H-<{wvETV7hTJQTHO>lJH(S^ZvV~
z;!JN|oFvj&b5)TSwcyy78u5}o9k4@ZLT)gk!PIHGxm|v=eNN1~T|$lKS>ECJSyB%Q
zQU<bMefuqyQDPQMqxX6_CKLs|EhVkXU>CXlBN{Hh$f?jAe@<}@%Ft6p;pj-@7HB@r
zF}AkdW1GR6xO#y!%}jlAINMjwaSmF^2$ir7w<JqF)O_=;)kldDx}*c3RJsc|mac)I
z`?{T+E82Ivav>h)tya!l>44pfOi36=3358ZbJRd5y-A*UC1Fc8l^pC2fKZ1mUhcs(
z3gIeL`#I1r3M|!8{fhauPY>)<jobftp0>O%R=y!5G^4^|g7`cq@^B5~vlXba&uu(T
zkbX!EnrW=&I@qt4E&C=bt9sj*r2}m%R<18EwkvZunE#f0UvA&5*6K+;`tZYZt!Hzx
zdW0oftCoeY^t#b<2%mKr^#iZ_dEMICrGW|4JVumG96~n<-W#3w$G?UCj6E{xkS2uw
zIeQYBj-WK(I}J$Bn<Ys*ol=&FKcZb_uzbNHiX5*7kI96{V0HWo>qGfyKS-6i8B!ym
z3DsLp(WTh+`J5bz@i3*K8l^9=cm%o<0biLatAL-*FXzYYl_WAxGuvKhvE9Cf!_WHk
zBK}jE$1ZKP`;HQ;$F9mmp_%*y8|Tbq)q=H&O>nJM8K1FDeQnUR436vMydLkT>13@8
z<FX&Mq3bbPR%TCEHz>qYk+z1I2h~gMS7Sfu>(LYQMZ_R){r$yiqYK)*_gezuJ37Zk
z;A1%Rg<C-3i19J5=jdE<y*a~XSs8>i!F~2ZeapoVYMCLzb&v&bjCVh0qZ|UYdcH)f
zrw9Tk=kdSf-yZ`%GBMjTfEZxT@wrUPaQhGzZ|pli_U@_%=(Nk(pD&O_5$)WtoQP__
zg2%99TA627!^s-2$SsafF%wT=uu@w%Xt6s$vyvc3ZtC#mWJc~3nZDHY>YRTv?YX(0
z3c9fxXSe|WcKA#U9kDeiOn~ke1&V-ONOURvGq}F3z^(Z6PynytsT^?Qye9g5oCsSn
zO0mLKc*xOrDBMAcyjcw|s=#VIKb&4v2;WiI6bqGDQ0~(GZ(wefeIG%WbeFf5@Hks#
zkCi0VhP>}7w)%yP+^dCX759YlH|q(gf=m(au@(nTdqi%jmk0A{xR+dSG!`^v$kdh4
z@Z!QolBN+gt+dKB31pm38=Z6yNr`LiM`7Gi9Z&ci0U!7irCx0aB9uud^O#s^QIr`8
zj{-;FX)pbUV=1tr1S1Dsz6&0dj451USB+Caal$IFd3NKUx!w;4i`52mR=ebp<9fxh
z(p2~;(78~Q3IA-pQx+RIbKafoUj#r`IebT`b3P^fudRy}*@NlUX4;fQqr+z&e;!^^
z_ry?3A%{l({7QDTW;N}(Fj}c~vHMNu=Jb%Y0Fw<q>cO|=TVA^G?G-6596sY}!*)BG
ztQZ>}3-6odl|ODu9rCbeRg_t-N(lVITM73T8A78%Si2{$uuLhCDgmm?)|j}Pj;%oa
zTCoP>@InM90q?T?$%}?#vKx~JE*f3}PTNfER2;k(0L&Qa#NKQBRsunf5#AGUui#qX
z_thipsPD%J-YebE<|!0IbGprPYeEamql*aQdseKF&1R86z~gGIlEX9_o08^?c&d0)
ze!`E)L`r#03HE7WN+FsAzXpdjako5iQYFQGkzkwzQY@~WiTC&pTN%o?TWfA|=V2lp
zV>q?Pv#_HsaVRen`R5Mo$A*q?te?M;hKWJ`V$j@<?ETOv&(usL*K13N_<2;OYguNh
zmwofQMD=N?*Znf4-}*N-5K6TAt;dA=nJyJcZh8f$#Akmx-$BD=k^29mD5<E3j1x+F
zjr@#-%mfH3%AqR&Mk^Cb%$NBl-t^~sw4%jOi-u#bxpbA+mF<;A7lfEZI2wRc9SjpP
znXCZ<WrSYJmg0*3tr@f44;SEctcWJq(OR=>F<w>B$d9wjZb5g4dWy_%cCdfCF<dnE
zH7kXc2BCE;@ydUcXI8=<p#Ki}3Jx&w5WOF~@rpQlcqDx(@o>YjE`|RMV&Dm}D6jwe
ztMRrc@|bI*MIXiY$uO=3UJeB(VtOG<e=8zIFLtCJjT<v!n;ID%<viOOb&D=<WMZ&A
zCKt1GC5miM1wEG7%<dNvr*{mMd7QmVZa$&N(2lN;O!T`Cg?^8Zo+Q`a=6XcM@oYJm
zVifK-pop?X*H3l%Z?KS47Gry(EojOGmeSeFmD0S0Jc(CTJFF%_Xkv5|4D5^?m1&O2
zfi1(FM>@^>FBKtyI3;2P%Ho3<j?Zc7zA(Egx(ls}p_kbMY1~FI=`HTL_sOl%U~<|7
zy(-HQmEavw^x1ucm2xS2ea@336g@t=PBcsGPP5+BE_)%y6<CysAuRfgZyAG_4bryr
zEhAGs{KF<#qZ%`XTO!yP#nH(ZF@oK5@pU)FP=php6ohFOgEcswq)N!0H2hss4RHo+
zuU9N0)G>UK1yK#;DjvN!1M~zgHx_7)+<a&wercDngS4%%7lL7!1KGc;;Y8-~io2&G
zKayiue7@hzuxla|aeRg%zlxHNN^m0aejE+wl`hPT&I2Da0;lesY96T&EGxCSsRSn*
znId|1w(yE>h-TNfSr}XBgOxzrH{sMc`_b$}p8_(rYB!2jvoUYqf5RJ0<FXwdwiU}Y
zgi{tpz}izwx&w?jtTJ^!o1yI)9xPLx=lj^&uu@D3^IhLPK3EK^V?nJCl71bq!@*sT
z{xZ@>KIm1Re!!%epT%yvH{Isf*YsMNkDPvBk|VG14MH5D_~7t7FEz(qym*`HZEOQB
zY_B5|9bg5ih$4hP>olznPv?+oMp3**a&sSvknj25o>z;I*4*lDyRNmbF{0mlbDl#7
za=F?U+j_JLDsJ6SQ2G)=1ADb8Ua%;|qdz5a*ApTZgzY*Q<OR9Mlr#g#*g3%Zi_tF5
zo+YplB=V^)zmRoked;2Hj=r$5Qx=3Q;gi)LHUGM<TNBO}dGIyccGHhiqWWCed%!$R
z7uphd_h7u;rr-S&t)Y7!)Q)3^F&Gat+yDEyUV@6DN2wJ1+Nik`R_TLogL~zUdaiId
zy{&G}Ph`IgY!Gb`b235vFi&?w1VGA3gQCL+8YLps$K(Fy;8tu~9bN$zeFaNur)J5>
z3yETdP_9fc`L=!xAkeF`)}iy9LGXQa+qOIFMEEm?Ox#W|9rNPuet{g}<FFEj|LiB6
zpvfO3l?HVPUtobYh#PP?P;GarOg39GGqJoNy&=J~kz~xSA+=T0OA&wIK!%nn#CF-n
z23qSYh2h_F$ys`_zc?3t4Ys>~W5J>Zv7K!gQyCg&aKP;5oGyR9{wmwn#%TNT77f$C
z?Zuy<fL_Mu_uc~bP>0-w&K)EC6%YQ{Af#glD`mfvNTXIvaQ1;6I>MrG{D)c#u6_q9
zrSChiMJ&wX1uWpWey+UK#EE_6kGY3<sg&=R_;hxzgA4y#Tf{+r&!+5JYIA>iO<1+d
zM!5c#%3VKMV{g8>-oxQ+Gwdk#e_zu9-X2)Ar;VYcLtpo&3Omy3y|<dcu91D@PGeDm
zen<+-766j~_VkcbJSFY;l-31;U|u!rcu7omwjOA&7rIU~SpPaCNcb-GzySQ4F$7GI
z*5kP<lSqr1*5*crcesq2WGkY`a&(_FR7%ZFWpWM??1he^|920S@NqdR?J@Yw9W{M|
zD|k45@}FtfO2SisthQ(iY<d62wNC>MA15$MxOr_$fYZfl@*PyhUb3zxI<5OjS#9ed
z_-c@?4`a{=YumpctrX-|?C_1&nw)oy<>-`qtfhs0^`!WGB%ajAYGjz}OU!*p8UolM
z-M)I7A36WK6L$D_=GqUZcxT&rV&9}6A2tbZ30ceTS!Fv~X1`A}R=f6uze#`nMve_I
z!rk<s8eRYQPF47K8dNR7wFSrzNt925v1QtP+W4lQ7p9sW>rX!q-NdRdQt4lxF10vp
zIg_hqKc6>x2@6pFjh7l~`xkpd$3BvWV<c9q5kl5Kd66;`EG9!wFB|=c3LUJwZC;;2
zr^`Dh%*s@Q5KZ@kQA~G?Vu|Rj4IU%uAO7z<<M_u%8DeIit=yc+E`!}}$)YfALXLk<
z$3$#JxViOUdI=4s)32+)x}I~gErhFcqV!^<pIOyvhT~Z}JFAgh!_N@+xx&?8kN>6~
z$k*Vb|E#r`psoffgR|??jm_-aBTn@wd;{)mpE|BG;ipb{zaNUH`zZG94lJ#d%YNI~
z)YaZhZ))9|NY4Jo8u-0uScW;AUUougrWG*vL!F7$wgZ9HZ$<d5S@k>csN-F$gL1L;
zFl56*n}6dR2Z>_QiNfy`X#gdHYJla!<JN0*EJ))si@CX}u`pfi3f~-1{5oW!M){nW
zdom=E=@m<tj^j>&>2<81wfM$XhBmc42kT+$%v+6$c3>C_`ieb(N2X4v<#IzKTUYjf
zV@(E^Dx6I76Kq5OwnIsXX(I^#{!L#j|NjOiI1cjpzsETk;miNtm_Q4;+MhE5#z18B
zp|D<2Y5@U#eNg;>t(AP&>xuF*phPDN3L!GKw&kU%94@;mK57515_bLv)CxGkc{?HL
zR}3Ln9#bN0wjz^(D}hA^e89i818j`2c>(_X`$@nH{(U%j!M|+`ne5+(ffxMu<}l93
Z7b6D)2y7pzKSRJjDKR<Ga^a7G{|}WTQ-}Zn

literal 0
HcmV?d00001

diff --git a/doc/required_content.mdwn b/doc/required_content.mdwn
new file mode 100644
index 0000000000..d4535ff85d
--- /dev/null
+++ b/doc/required_content.mdwn
@@ -0,0 +1,22 @@
+Required content settings can be configured to do more complicated
+things than just setting the required number of [[copies]] of your data.
+For example, you could require that data be archived in at least two
+archival repositories, and also require that one copy be stored offsite.
+
+The format of required content expressions is the same as
+[[preferred_content]] expressions.
+
+Required content settings can be edited using `git annex vicfg`
+or set using `git annex required`.
+Each repository can have its own settings, and other repositories will
+try to honor those settings when interacting with it.
+
+While [[preferred_content]] expresses a preference, it can be overridden
+by simply using `git annex drop`. On the other hand, required content
+settings are enforced; `git annex drop` will refuse to drop a file if
+doing so would violate its required content settings.
+(Although even this can be overridden using `--force`).
+
+Also, `git-annex fsck` will warn about required contents that are not
+present.
+
diff --git a/doc/required_content/comment_1_b9576aaa31258e9bdf18a4eac8d61bfb._comment b/doc/required_content/comment_1_b9576aaa31258e9bdf18a4eac8d61bfb._comment
new file mode 100644
index 0000000000..5e859d8f2e
--- /dev/null
+++ b/doc/required_content/comment_1_b9576aaa31258e9bdf18a4eac8d61bfb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnG-DZQa3d3Jn7K2q36TlbmZ8v2YuV-23M"
+ nickname="Fer"
+ subject="Command line?"
+ date="2015-03-17T13:31:34Z"
+ content="""
+Th expression format in the file is the same as preferred, but the latter can be set through command line (git-annex wanted REPO EXP), but I can't find any way to set required through command line. Is there any way, in the works, or not planned?
+
+Thanks!
+"""]]
diff --git a/doc/required_content/comment_2_d475f4afc84a58afe7af6d492de3ebe5._comment b/doc/required_content/comment_2_d475f4afc84a58afe7af6d492de3ebe5._comment
new file mode 100644
index 0000000000..4db20c013b
--- /dev/null
+++ b/doc/required_content/comment_2_d475f4afc84a58afe7af6d492de3ebe5._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-04-29T18:04:52Z"
+ content="""
+`git annex required` was recently added to the CLI.
+"""]]
diff --git a/doc/scalability.mdwn b/doc/scalability.mdwn
new file mode 100644
index 0000000000..fd33fdf273
--- /dev/null
+++ b/doc/scalability.mdwn
@@ -0,0 +1,41 @@
+git-annex is designed for scalability. The key points are:
+
+* Arbitrarily large files can be managed. The only constraint
+  on file size are how large a file your filesystem can hold.
+
+  While git-annex does checksum files by default, there
+  is a [[WORM_backend|backends]] available that avoids the checksumming
+  overhead, so you can add new, enormous files, very fast. This also
+  allows it to be used on systems with very slow disk IO.
+
+* Memory usage should be constant. This is a "should", because there
+  can sometimes be leaks (and this is one of haskell's weak spots),
+  but git-annex is designed so that it does not need to hold all
+  the details about your repository in memory.
+
+* Many files can be managed. The limiting factor is git's own
+  limitations in scaling to repositories with a lot of files, and as git
+  improves this will improve. Scaling to hundreds of thousands of files
+  is not a problem, scaling beyond that and git will start to get slow.
+
+  To some degree, git-annex works around inefficiencies in git; for
+  example it batches input sent to certain git commands that are slow
+  when run in an enormous repository.
+
+* It can use as much, or as little bandwidth as is available. In
+  particular, any interrupted file transfer can be resumed by git-annex.
+
+## scalability tips
+
+* If the files are so big that checksumming becomes a bottleneck, consider
+  using the [[WORM_backend|backends]]. You can always `git annex migrate`
+  files to a checksumming backend later on.
+
+* If you're adding a huge number of files at once (hundreds of thousands),
+  you'll soon notice that git-annex periodically stops and say
+  "Recording state in git" while it runs a `git add` command that
+  becomes increasingly expensive. Consider adjusting the `annex.queuesize`
+  to a higher value, at the expense of it using more memory.
+
+* See also: [[tips/Repositories_with_large_number_of_files]]
+
diff --git a/doc/scalability/comment_1_a6656ae397277719d67d0953a28fe1d8._comment b/doc/scalability/comment_1_a6656ae397277719d67d0953a28fe1d8._comment
new file mode 100644
index 0000000000..5c0038e807
--- /dev/null
+++ b/doc/scalability/comment_1_a6656ae397277719d67d0953a28fe1d8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmiPEySoakXDQ4OUAmC9neEOZW17W1KvlU"
+ nickname="Francesco Saverio"
+ subject="Default value of annex.queuesize"
+ date="2015-01-14T15:45:46Z"
+ content="""
+What is the default value of :
+
+    annex.queuesize 
+
+Without knowing the default value it is impossible to increase it :) thank you
+"""]]
diff --git a/doc/scalability/comment_2_71c7c3aa97284602d0f64c11a98d1782._comment b/doc/scalability/comment_2_71c7c3aa97284602d0f64c11a98d1782._comment
new file mode 100644
index 0000000000..a6ca05c2ba
--- /dev/null
+++ b/doc/scalability/comment_2_71c7c3aa97284602d0f64c11a98d1782._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-01-15T18:56:42Z"
+ content="""
+annex.queuesize default is documented on the man page. Currently 10240
+commands.
+"""]]
diff --git a/doc/security.mdwn b/doc/security.mdwn
new file mode 100644
index 0000000000..2892e3c3ec
--- /dev/null
+++ b/doc/security.mdwn
@@ -0,0 +1,7 @@
+Information about all known security holes in git-annex, and their fixes.
+Subscribe to the RSS feed to be kept up to date.
+
+If you have discovered a security hole and wish to report it privately, see
+[[contact]].
+
+[[!inline pages="./security/* and !./security/*/* and !*/Discussion" rootpage="security" show="0"]]
diff --git a/doc/security/CVE-2014-6274.mdwn b/doc/security/CVE-2014-6274.mdwn
new file mode 100644
index 0000000000..8e9f4ae5aa
--- /dev/null
+++ b/doc/security/CVE-2014-6274.mdwn
@@ -0,0 +1,10 @@
+CVE-2014-6274: Security fix for S3 and glacier when using embedcreds=yes with
+encryption=pubkey or encryption=hybrid.
+
+The creds embedded in the git repo were *not* encrypted.
+git-annex enableremote will warn when used on a remote that has
+this problem. For details, see [[upgrades/insecure_embedded_creds]].
+
+Fixed in git-annex 5.20140919.
+
+[[!meta date="Fri, 19 Sep 2014 12:53:42 -0400"]]
diff --git a/doc/security/CVE-2017-12976.mdwn b/doc/security/CVE-2017-12976.mdwn
new file mode 100644
index 0000000000..bbc8961b1e
--- /dev/null
+++ b/doc/security/CVE-2017-12976.mdwn
@@ -0,0 +1,10 @@
+CVE-2017-12976: A hostname starting with a dash would get passed to ssh and be treated as
+an option. This could be used by an attacker who provides a crafted
+repository url to cause the victim to execute arbitrary code via
+`-oProxyCommand`.
+
+Fixed in git-annex 6.20170818
+
+This is related to a git security hole, [CVE-2017-1000117](https://marc.info/?l=git&m=150238802328673&w=2).
+
+[[!meta date="Fri, 18 Aug 2017 11:19:06 -0400"]]
diff --git a/doc/security/CVE-2018-10857_and_CVE-2018-10859.mdwn b/doc/security/CVE-2018-10857_and_CVE-2018-10859.mdwn
new file mode 100644
index 0000000000..ec445db3eb
--- /dev/null
+++ b/doc/security/CVE-2018-10857_and_CVE-2018-10859.mdwn
@@ -0,0 +1,92 @@
+CVE-2018-10857: Some uses of git-annex were vulnerable to a private data
+exposure and exfiltration attack. It could expose the content of files
+located outside the git-annex repository, or content from a private web
+server on localhost or the LAN. Joey Hess discovered this attack.
+
+CVE-2018-10859: A malicious server for a special remote could
+trick git-annex into decrypting a file that was encrypted to the user's gpg
+key. This attack could be used to expose encrypted data that was never
+stored in git-annex. Daniel Dent discovered this attack in collaboration
+with Joey Hess.
+
+These security holes were fixed in git-annex 6.20180626. After upgrading
+git-annex, you should restart any git-annex assistant processes.
+
+Also, some external special remotes (plugins) were improved, as a second
+line of defense against CVE-2018-10857:
+
+* git-annex-remote-pcloud 0.0.2 (thanks to Tocho Tochev)
+
+## attack descriptions
+
+To perform these attacks, the attacker needs to have control over one of
+the remotes of the victim's git-annex repository. For example, they may
+provide a public git-annex repository that the victim clones. Or,
+equivilantly, the attacker could have read access to the victim's git-annex
+repository or a repository it pushes to, and some channel to get commits
+into it (eg pull requests).
+
+These exploits are most likely to succeed when the victim is running the
+git-annex assistant, or is periodically running `git annex sync --content`.
+
+To perform the private data exfiltration attack (CVE-2018-10857), the 
+attacker runs `git-annex addurl --relaxed file:///etc/passwd` and commits
+this to the repository in some out of the way place. After the victim's
+git repository receives that change, git-annex follows the attacker-provided
+url to private data, which it stores in the git-annex repository.
+From there it transfers the content to the git-annex repository that
+the attacker has access to.
+
+(As well as `file:///` urls, the attacker can use urls to private web
+servers. The url can also be one that the attacker controls, that redirects
+to such urls.)
+
+To perform the gpg decryption attack (CVE-2018-10859), the attacker
+additionally needs to have control of the server hosting an encrypted
+special remote used by the victim's git-annex repository. The attacker uses
+`git annex addurl --relaxed` with an innocuous url, and waits for the
+user's git-annex to download it, and upload an (encrypted) copy to the
+special remote they also control. At some later point, when the user
+downloads the content from the special remote, the attacker instead sends
+them the content of a gpg encrypted file that they wish to have decrypted
+in its place. Finally, the attacker drops their own copy of the original
+innocuous url, and waits for git-annex to send them the accidentially
+decrypted file.
+
+## git-annex security fixes
+
+CVE-2018-10857 was fixed by making git-annex refuse to follow `file:///` urls
+and urls pointing to private/local IP addresses by default. Two new
+configuration settings, annex.security.allowed-url-schemes and
+annex.security.allowed-ip-addresses, can relax this security policy,
+and are intended for cases where the git-annex repository is kept
+private and so the attack does not apply.
+
+CVE-2018-10859 was fixed by making git-annex refuse to download encrypted
+content from special remotes, unless it knows the hash of the expected
+content. When the attacker provides some other gpg encrypted content, it
+will fail the hash check and be discarded.
+
+External special remotes (plugins) that use HTTP/HTTPS could also be
+attacked using the CVE-2018-10857 method, if the attacker additionally has
+control of the server they connect to. To prevent such attacks,
+git-annex refuses to download content from external special remotes unless
+it can verify the hash of that content.
+
+## impact on external special remotes
+
+One variant of CVE-2018-10857 can exploit a vulnerable external special
+remote, and could not be prevented by git-annex. (git-annex's own built-in
+special remotes are not vulnerable to this attack.)
+
+In this attack variant, the attacker guesses at the hash of a file stored
+on the victim's private web server, and adds it to the git-annex
+repository. The attacker also has control of the server hosting an
+encrypted special remote used by the victim's git-annex repository. They
+cause that server to redirect to the victim's web server. This allows the
+attacker to verify if the victim's web server contains a file that the
+attacker already knows the content of, assuming they can guess the URL to
+it.
+
+Developers of external special remotes are encouraged to prevent this
+attack by not following such HTTP redirects.
diff --git a/doc/security/checksum_exposure_to_encrypted_special_remotes.mdwn b/doc/security/checksum_exposure_to_encrypted_special_remotes.mdwn
new file mode 100644
index 0000000000..4301e1fda9
--- /dev/null
+++ b/doc/security/checksum_exposure_to_encrypted_special_remotes.mdwn
@@ -0,0 +1,12 @@
+A bug exposed the checksum of annexed files to encrypted
+special remotes, which are not supposed to have access to the checksum of
+the un-encrypted file. This only occurred when resuming uploads to the
+encrypted special remote, so it is considered a low-severity security hole.
+
+For details, see [[!commit b890f3a53d936b5e40aa9acc5876cb98f18b9657]]
+
+No CVE was assigned for this issue.
+
+Fixed in git-annex 6.20160419
+
+[[!meta date="Thu, 28 Apr 2016 09:31:14 -0400"]]
diff --git a/doc/security/comment_1_285da453a385bd4bd225e26377a47cd5._comment b/doc/security/comment_1_285da453a385bd4bd225e26377a47cd5._comment
new file mode 100644
index 0000000000..016012fd5b
--- /dev/null
+++ b/doc/security/comment_1_285da453a385bd4bd225e26377a47cd5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/iOGTltEpmOTQ.xZ99NFP5c7Zdcc-#6a7ba"
+ nickname="Ilya S"
+ avatar="http://cdn.libravatar.org/avatar/8a133555cc739a35b83b07d5724d28d9e2f7852c224e949eec6fd4fb7693331e"
+ subject="comment 1"
+ date="2018-09-07T21:08:24Z"
+ content="""
+It would be good if annex.security.allowed-http-addresses could add an exception not just for any 'localhost' access, but only for URLs matching a given regexp, e.g. only for
+http://localhost:808?/dnanexus/file-[a-f0-9]+
+"""]]
diff --git a/doc/security/comment_2_261b1904e41f4566490b977010ce8734._comment b/doc/security/comment_2_261b1904e41f4566490b977010ce8734._comment
new file mode 100644
index 0000000000..ea78b6f0f2
--- /dev/null
+++ b/doc/security/comment_2_261b1904e41f4566490b977010ce8734._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-09-11T16:39:14Z"
+ content="""
+@Ilya, it seems to me you could just configure your localhost webserver to
+listen on one of the other localnet addresses (eg 127.0.0.2), and 
+only serve up the "safe" files on that address.
+Then whitelist that address in git-annex.
+
+That seems better than adding user-configured regexps to a security path.
+(Worth noting that the example regexp you gave also matches port 808, probably
+by accident! Regexps and security are often not the best combination.)
+
+Also, I don't think it would be possible to implement anything that looks
+at the whole url in the restricted Http Manager, since the http-client
+library's interface does not provide the path being requested to the hook
+that is built on.
+"""]]
diff --git a/doc/security/comment_3_0cc44e032fc94f4d374fb297ca9a8f2d._comment b/doc/security/comment_3_0cc44e032fc94f4d374fb297ca9a8f2d._comment
new file mode 100644
index 0000000000..c94ab38953
--- /dev/null
+++ b/doc/security/comment_3_0cc44e032fc94f4d374fb297ca9a8f2d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="Another use case -- http_proxy"
+ date="2019-11-12T17:51:25Z"
+ content="""
+On some institutional servers they mandate for all http traffic to go through proxy.  In our case `http_proxy` looked like `http://ptn07-e0:3128`. 
+`datalad install` worked out but an attempt to `datalad get` a bunch of files resulted in massive list of errors, and `annex-ignore` being set for \"origin\" which is otherwise available.
+We managed to fish out that warning about security schemes and http_proxy being ignored for that reason in one of the subsequent attempts (after unsetting annex-ignore).
+Upon attempts to set that variable we realized that we had to provide IP  instead of `http_proxy` full value or just a name (`ptn07-e0`), netmasked address (e.g. 10.0.0.1/24) also didn't work.  That makes it really inflexible. Actual IP could change, without http_proxy being changed.  Even the value of http_proxy could change system wide.  It would be painful to require our users to adjust for that every time, and it is infeasible to demand sysadmins to somehow tune up their configuration across HPC (we have no direct connection to them).  If we could at least whitelist private network -- that would provide some remedy.  Regular expression, though indeed not a really security-friendly solution, could have also provided remedy.
+Have we missed some already existing way to make our lives easy on that system?
+"""]]
diff --git a/doc/security/comment_4_3822244fb9becc32385d57233fa036a4._comment b/doc/security/comment_4_3822244fb9becc32385d57233fa036a4._comment
new file mode 100644
index 0000000000..9263c59283
--- /dev/null
+++ b/doc/security/comment_4_3822244fb9becc32385d57233fa036a4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-02-20T20:29:20Z"
+ content="""
+If you have a problem with some change that was made to fix a security
+hole, about the only thing you can do is file a bug report. With some
+really well thought out way to improve it ideally. I'm certianly not going
+to revert security hole fixes because some comment here complains about
+them.
+"""]]
diff --git a/doc/security/comment_5_616b08553430a64beab196571c5b9cdc._comment b/doc/security/comment_5_616b08553430a64beab196571c5b9cdc._comment
new file mode 100644
index 0000000000..0bc9fba814
--- /dev/null
+++ b/doc/security/comment_5_616b08553430a64beab196571c5b9cdc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2020-02-21T00:07:53Z"
+ content="""
+[done](https://git-annex.branchable.com/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/)
+"""]]
diff --git a/doc/shortcuts.mdwn b/doc/shortcuts.mdwn
new file mode 100644
index 0000000000..d0f647a64e
--- /dev/null
+++ b/doc/shortcuts.mdwn
@@ -0,0 +1,12 @@
+[[!if test="enabled(shortcut)"
+     then="This wiki has shortcuts **enabled**."
+     else="This wiki has shortcuts **disabled**."]]
+
+This page controls what shortcut links the wiki supports.
+
+* [[!shortcut name=debbug url="http://bugs.debian.org/%S" desc="Debian bug #%s"]]
+* [[!shortcut name=iki url="http://ikiwiki.info/%S/"]]
+* [[!shortcut name=rfc url="https://www.ietf.org/rfc/rfc%s.txt" desc="RFC %s"]]
+* [[!shortcut name=cve url="https://cve.mitre.org/cgi-bin/cvename.cgi?name=%s"]]
+* [[!shortcut name=hackage url="http://hackage.haskell.org/package/%s"]]
+* [[!shortcut name=commit url="http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=%s"]]
diff --git a/doc/sidebar.mdwn b/doc/sidebar.mdwn
new file mode 100644
index 0000000000..7bbdefe357
--- /dev/null
+++ b/doc/sidebar.mdwn
@@ -0,0 +1,12 @@
+[[!img logo_small.png link=no]]
+
+* [[install]]
+* [[assistant]]
+* [[walkthrough]]
+* [[tips]]
+* [[bugs]]
+* [[todo]]
+* [[forum]]
+* [[comments]]
+* [[contact]]
+* [[thanks]]
diff --git a/doc/sitemap.mdwn b/doc/sitemap.mdwn
new file mode 100644
index 0000000000..c854ed6390
--- /dev/null
+++ b/doc/sitemap.mdwn
@@ -0,0 +1,4 @@
+[[!map pages="page(*) and !*/discussion and !recentchanges
+and !bugs/* and !examples/*/* and !news/* and !tips/* and !videos/*
+and !design/assistant/blog/*
+and !forum/* and !todo/* and !users/* and !ikiwiki/*"]]
diff --git a/doc/special_remotes.mdwn b/doc/special_remotes.mdwn
new file mode 100644
index 0000000000..7399ba34a8
--- /dev/null
+++ b/doc/special_remotes.mdwn
@@ -0,0 +1,136 @@
+git-annex can transfer data to and from configured git remotes.
+Normally those remotes are normal git repositories (bare and non-bare;
+local and remote), that store the file contents in their own git-annex
+directory.
+
+But, git-annex also extends git's concept of remotes, with these special
+types of remotes. These can be used by git-annex to store and retrieve
+the content of files. They cannot be used by other git commands, and
+the git history is not stored in them.
+
+* [[adb]] (for Android devices)
+* [[Amazon_Glacier|glacier]]
+* [[bittorrent]]
+* [[bup]]
+* [[ddar]]
+* [[directory]]
+* [[gcrypt]] (encrypted git repositories!)
+* [[git-lfs]]
+* [[hook]]
+* [[rsync]]
+* [[S3]] (Amazon S3, and other compatible services)
+* [[tahoe]]
+* [[tor]]
+* [[web]]
+* [[webdav]]
+* [[git]]
+* [[httpalso]]
+* [[borg]]
+* [[rclone]]
+
+The above special remotes are built into git-annex, and can be used
+to tie git-annex into many cloud services.
+
+Here are specific instructions for using git-annex with various services:
+
+* [[Amazon_Glacier|tips/using_Amazon_Glacier]]
+* [[Amazon_S3|tips/using_Amazon_S3]]
+* [[Backblaze B2|tips/using_Backblaze_B2]]
+* [[Box.com|tips/using_box.com_as_a_special_remote]]
+* [Ceph](https://github.com/mhameed/git-annex-remote-ceph)
+* [chef-vault](https://github.com/3ofcoins/knife-annex/)
+* [[Dropbox|tips/dropboxannex]]
+* [[FTP|rclone]]
+* [[Flickr|tips/flickrannex]]
+* [Freenet and Siacoin Skynet](https://github.com/xloem/gitlakepy)
+* [[Google Cloud Storage|tips/using_Google_Cloud_Storage]]
+* [[Google Drive|tips/using_Google_Drive]]
+* [[hubiC|tips/using_Hubic]]
+* [[IMAP|forum/special_remote_for_IMAP]]
+* [[tips/Internet_Archive_via_S3]]
+* [[ipfs]]
+* [[Jottacloud|rclone]]
+* [[Mega|tips/megaannex]]
+* [[Microsoft Azure Blob Storage|rclone]]
+* [[Microsoft OneDrive|rclone]]
+* [NNCP](https://git.sr.ht/~ehmry/git-annex-remote-nncp)
+* [[OpenDrive|rclone]]
+* [[Openstack Swift / Rackspace cloud files / Memset Memstore|rclone]]
+* [[OwnCloud|tips/owncloudannex]]
+* [[pCloud|rclone]]
+* [[QingStor|rclone]]
+* [[SFTP|rclone]]
+* [[SkyDrive|tips/skydriveannex]]
+* [smb / sftp](https://github.com/grawity/code/blob/master/net/git-annex-remote-gvfs)
+* [[Usenet|forum/nntp__47__usenet special remote]]
+* [[Yandex Disk|rclone]]
+
+If a service is not mentioned above, it's worth checking if 
+[rclone](https://rclone.org/) supports it, then you can use the
+[[rclone_special_remote|rclone]].
+
+Want to add support for something else? [[Write your own!|external]]
+
+## Ways to use special remotes
+
+There are many use cases for a special remote. You could use it as a
+backup. You could use it to archive files offline in a drive with
+encryption enabled so if the drive is stolen your data is not. You could
+git annex move --to specialremote large files when your local drive is
+getting full, and then git annex move the files back when free space is
+again available. You could have one repository copy files to a special
+remote, and then git annex get them on another repository, to transfer the
+files between computers that do not communicate directly.
+
+None of these use cases are particular to particular special remote types.
+Most special remotes can all be used in these and other ways. It largely
+doesn't matter for your use what underlying transport the special remote
+uses.
+
+## Setting up a special remote
+
+To initialize a new special remote, use 
+[[git-annex initremote|git-annex-initremote]]. See the documentation for
+the special remote you want to use for details about configuration and
+examples of how to initremote it.
+
+Once a special remote has been initialize, other clones of the repository can
+also enable it, by using [[git-annex enableremote|git-annex-enableremote]]
+with the same name that was used to initialize it. (Run the command without
+any name to get a list of available special remotes.)
+
+Initializing or enabling a special remote adds it as a remote of your git
+repository. You can't use git commands like `git pull` with the remote
+(usually, there are exceptions like [[git-lfs]]), but you can use git-annex
+commands.
+
+## Unused content on special remotes
+
+Over time, special remotes can accumulate file content that is no longer
+referred to by files in git. Normally, unused content in the current
+repository is found by running `git annex unused`. To detect unused content
+on special remotes, instead use `git annex unused --from`. Example:
+
+	$ git annex unused --from mys3
+	unused mys3 (checking for unused data...) 
+	  Some annexed data on mys3 is not used by any files in this repository.
+	    NUMBER  KEY
+	    1       WORM-s3-m1301674316--foo
+	  (To see where data was previously used, try: git log --stat -S'KEY')
+	  (To remove unwanted data: git-annex dropunused --from mys3 NUMBER)
+	$ git annex dropunused --from mys3 1
+	dropunused 12948 (from mys3...) ok
+
+## Removing special remotes
+
+Like git remotes, a special remote can be removed from your repository
+by using `git remote remove`. Note that does not delete the special remote,
+or prevent other repositories from enabling or using it.
+
+## Testing special remotes
+
+To make sure that a special remote is working correctly, you can use the
+[[git annex testremote|git-annex-testremote]] command. This expects you to
+have set up the remote as usual, and it then runs a lot of tests, using
+random data. It's particularly useful to test new implementations of
+special remotes.
diff --git a/doc/special_remotes/S3.mdwn b/doc/special_remotes/S3.mdwn
new file mode 100644
index 0000000000..843ab5c857
--- /dev/null
+++ b/doc/special_remotes/S3.mdwn
@@ -0,0 +1,165 @@
+This special remote type stores file contents in a bucket in Amazon S3
+or a similar service.
+
+See [[tips/using_Amazon_S3]], 
+[[tips/Internet_Archive_via_S3]], and [[tips/using_Google_Cloud_Storage]]
+for usage examples.
+
+## configuration
+
+The standard environment variables `AWS_ACCESS_KEY_ID` and
+`AWS_SECRET_ACCESS_KEY` are used to supply login credentials for S3. You
+need to set these only when running `git annex initremote` (or
+`enableremote`), as they will be cached in a file only you can read inside
+the local git repository. If you’re working with temporary security
+credentials, you can also set the `AWS_SESSION_TOKEN` environment variable.
+
+A number of parameters can be passed to `git annex initremote` to configure
+the S3 remote.
+
+* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
+  See [[encryption]].
+
+* `keyid` - Specifies the gpg key to use for [[encryption]].
+
+* `chunk` - Enables [[chunking]] when storing large files.
+  `chunk=1MiB` is a good starting point for chunking.
+
+* `embedcreds` - Optional. Set to "yes" embed the login credentials inside
+  the git repository, which allows other clones to also access them. This is
+  the default when gpg encryption is enabled; the credentials are stored
+  encrypted and only those with the repository's keys can access them.
+
+  It is not the default when using shared encryption, or no encryption.
+  Think carefully about who can access your repository before using
+  embedcreds without gpg encryption.
+
+* `datacenter` - Specifies which Amazon datacenter
+  to use for the bucket. Defaults to "US". Other values include "EU"
+  (which is EU/Ireland), "us-west-1", "us-west-2", "ap-southeast-1",
+  "ap-southeast-2", and "sa-east-1". See Amazon's documentation for a
+  complete list. Configuring this is equivilant to configuring both
+  `host` and `region`.
+
+* `storageclass` - Default is "STANDARD".  
+  Consult S3 provider documentation for pricing details and available
+  storage classes.  For example, the s3cmd(1) man page lists valid storage class names for Amazon S3.
+  
+  When using Amazon S3,
+  if the remote will be used for backup or archival,
+  and so its files are Infrequently Accessed, `STANDARD_IA` is a
+  good choice to save money (requires a git-annex built with aws-0.13.0).
+  If you have configured git-annex to preserve
+  multiple [[copies]], also consider setting this to `ONEZONE_IA`
+  to save even more money.
+
+  Amazon S3's `DEEP_ARCHIVE` is similar to Amazon Glacier. For that,
+  use the [[glacier]] special remote, rather than this one.
+
+  When using Google Cloud Storage, to make a nearline bucket, set this to
+  `NEARLINE`. (Requires a git-annex built with aws-0.13.0)
+
+  Note that changing the storage class of an existing S3 remote will
+  affect new objects sent to the remote, but not objects already
+  stored there.
+
+* `host` - Specify in order to use a different, S3 compatable
+  service.
+
+* `region` - Specify the region to use. Only makes sense to use when
+  you also set `host`.
+  (Requires a git-annex built with aws-0.24.)
+
+* `protocol` - Either "http" (the default) or "https". Setting
+  protocol=https implies port=443. 
+  
+  This option was added in git-annex version 7.20190322; to make
+  a special remote that uses http with older versions of git-annex,
+  explicitly specify port=443.
+
+* `port` - Specify the port to connect to. Only needed when using a service
+  on an unusual port. Setting port=443 implies protocol=https.
+
+* `requeststyle` - Set to "path" to use path style requests, instead of the
+  default DNS style requests. This is needed with some S3 services.
+
+  If you get an error about a host name not existing, it's a good
+  indication that you need to use this.
+
+* `signature` - This controls the S3 signature version to use.
+  "v2" is currently the default, "v4" is needed to use some S3 services.
+  If you get some kind of authentication error, try "v4".
+  To access a S3 bucket anonymously, use "anonymous".
+
+* `bucket` - S3 requires that buckets have a globally unique name, 
+  so by default, a bucket name is chosen based on the remote name
+  and UUID. This can be specified to pick a bucket name.
+
+* `versioning` - Indicate whether the S3 bucket should have versioning
+  enabled. Set to "yes" to enable.
+  
+  Enabling versioning along with "exporttree=yes"
+  allows git-annex to access old versions of files that were 
+  exported to the special remote by [[git-annex export|git-annex-export]].
+
+  And enabling versioning along with "importtree=yes"
+  allows [[git-annex import|git-annex-import]] to import the whole
+  history of files in the bucket, synthesizing a series of git commits.
+
+  Note that git-annex does not support dropping content from versioned
+  S3 buckets, since the versioning preserves the content.
+
+* `exporttree` - Set to "yes" to make this special remote usable
+  by [[git-annex export|git-annex-export]].
+  It will not be usable as a general-purpose special remote.
+
+* `importtree` - Set to "yes" to make this special remote usable
+  by [[git-annex-import]]. When set in combination with exporttree,
+  this lets files be imported from it, and changes exported back to it.
+
+  Note that exporting files to a S3 bucket may overwrite changes that
+  have been made to files in the bucket by other software since the last
+  time git-annex imported from the bucket. When versioning is enabled,
+  the content of files overwritten in this way can still be recovered,
+  but you may have to look through the git history to find them.
+  When versioning is not enabled, this risks data loss, and so git-annex
+  will not let you enable a remote with that configuration unless forced.
+
+* `publicurl` - Configure the URL that is used to download files
+  from the bucket. Using this with a S3 bucket that has been configured
+  to allow anyone to download its content allows git-annex to download
+  files from the S3 remote without needing to know the S3 credentials.
+
+  To configure the S3 bucket to allow anyone to download its content,
+  refer to S3 documentation to set a Bucket Policy.
+
+* `public` - Deprecated. This enables public read access to files sent to
+  the S3 remote using ACLs. Note that Amazon S3 buckets created after April
+  2023 do not support using ACLs in this way and a Bucket Policy must instead
+  be used. This should only be set for older buckets.
+
+* `partsize` - Amazon S3 only accepts uploads up to a certian file size,
+  and storing larger files requires a multipart upload process.
+
+  Setting `partsize=1GiB` is recommended for Amazon S3 when not using
+  chunking; this will cause multipart uploads to be done using parts
+  up to 1GiB in size. Note that setting partsize to less than 100MiB
+  will cause Amazon S3 to reject uploads.
+
+  This is not enabled by default, since other S3 implementations may
+  not support multipart uploads or have different limits,
+  but can be enabled or changed at any time.
+
+* `fileprefix` - By default, git-annex places files in a tree rooted at the
+  top of the S3 bucket. When this is set, it's prefixed to the filenames
+  used. For example, you could set it to "foo/" in one special remote,
+  and to "bar/" in another special remote, and both special remotes could
+  then use the same bucket.
+
+* `x-amz-meta-*` are passed through as http headers when storing keys
+  in S3.
+
+* `x-archive-meta-*` are passed through as http headers when storing keys
+  in the Internet Archive. See
+  [the Internet Archive S3 interface documentation](https://archive.org/help/abouts3.txt)
+  for example headers.
diff --git a/doc/special_remotes/S3/comment_10_c366f020c9b97a365e21878a33360079._comment b/doc/special_remotes/S3/comment_10_c366f020c9b97a365e21878a33360079._comment
new file mode 100644
index 0000000000..bc06156cff
--- /dev/null
+++ b/doc/special_remotes/S3/comment_10_c366f020c9b97a365e21878a33360079._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 10"
+ date="2013-05-23T20:04:03Z"
+ content="""
+You can enable a special remote on a clone by running `git annex enableremote $name`, where $name is the name you used to originally create the special remote. (Older versions of git-annex used `git annex initremote` to enable the special remote on the clone.)
+
+(Just in case, I have verified that embedcreds does cause the cipher= to be stored in the remote.log. It does.)
+"""]]
diff --git a/doc/special_remotes/S3/comment_11_c1da387e082d91feec13dde91ccb111a._comment b/doc/special_remotes/S3/comment_11_c1da387e082d91feec13dde91ccb111a._comment
new file mode 100644
index 0000000000..5cd9b73116
--- /dev/null
+++ b/doc/special_remotes/S3/comment_11_c1da387e082d91feec13dde91ccb111a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="basak"
+ ip="2001:8b0:1c8::2"
+ subject="comment 11"
+ date="2013-05-24T09:38:40Z"
+ content="""
+Thanks Joey - initremote on my slightly older version appears to work. I'll use `enableremote` when I can.
+
+> (Just in case, I have verified that embedcreds does cause the cipher= to be stored in the remote.log. It does.)
+
+This doesn't do what I expect. The documentation suggests that my S3 _login_ credentials would be stored. I understand that the cipher would be stored; but isn't this a separate concept? Instead, I'm being asked to set `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`; my understanding was that git-annex will keep them in the repository for me, so that I don't have to set them after running `initremote` before cloning. This works, apart from surviving the cloning. I'm using `encryption=shared`; does this affect anything? Or am I using a version of git-annex (3.20121112ubuntu3) that's too old?
+"""]]
diff --git a/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment b/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment
new file mode 100644
index 0000000000..f29a2e34c7
--- /dev/null
+++ b/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 12"
+ date="2013-05-24T15:33:12Z"
+ content="""
+Ah -- No, your AWS creds are not stored. While some other special remotes, like webdav, can store all necessary credentials, it's not done for AWS. I didn't want git-annex to be responsible for someone accidentally publishing their AWS creds to their friends, since that could cost them a lot of money.
+"""]]
diff --git a/doc/special_remotes/S3/comment_13_0789a21d980825188bb09f7fc8bba8be._comment b/doc/special_remotes/S3/comment_13_0789a21d980825188bb09f7fc8bba8be._comment
new file mode 100644
index 0000000000..c8e84021b6
--- /dev/null
+++ b/doc/special_remotes/S3/comment_13_0789a21d980825188bb09f7fc8bba8be._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="basak"
+ ip="2001:8b0:1c8::2"
+ subject="comment 13"
+ date="2013-05-24T15:47:14Z"
+ content="""
+That's not what the documentation here says! It even warns me: \"Think carefully about who can access your repository before using embedcreds without gpg encryption.\"
+
+My use case:
+
+Occasional use of EC2, and a desire to store some persistent stuff in S3, since the dataset is large and I have limited bandwidth. I want to destroy the EC2 instance when I'm not using it, leaving the data in S3 for later.
+
+If I use git-annex to manage the S3 store, then I get the ability to clone the repository and destroy the instance. Later, I can start a new instance, push the repo back up, and would like to be able to then pull the data back out of S3 again.
+
+I'd really like the login credentials to persist in the repository (as the documentation here says it should). Even if I have to add a --yes-i-know-my-s3-credentials-will-end-up-available-to-anyone-who-can-see-my-git-repo flag. This is because I use some of my git repos to store private data, too.
+
+If I use an Amazon IAM policy as follows, I can generate a set of credentials that are limited to access to a particular prefix of a specific S3 bucket only - effectively creating a sandboxed area just for git-annex:
+
+    { 
+      \"Statement\": [{\"Sid\": \"Stmt1368780615583\",
+                     \"Action\": [\"s3:GetObject\", \"s3:PutObject\", \"s3:DeleteObject\"],
+                     \"Effect\": \"Allow\",
+                     \"Resource\": [\"arn:aws:s3:::bucketname/prefix/*\"]}
+                    ],
+      \"Statement\": [{\"Sid\": \"Stmt1368781573129\",
+                    \"Action\": [\"s3:GetBucketLocation\"],
+                    \"Effect\": \"Allow\",
+                    \"Resource\": [\"arn:aws:s3:::bucketname\"]}
+                   ]
+    }
+
+Doing this means that I have a different set of credentials for every annex, so it would be really useful to be able have these stored and managed within the repository itself. Each set is limited to what the annex stores, so there is no bigger compromise I have to worry about apart from the compromise of the data that the annex itself manages.
+"""]]
diff --git a/doc/special_remotes/S3/comment_14_29574a51d5831c51e2e765eb2c06e567._comment b/doc/special_remotes/S3/comment_14_29574a51d5831c51e2e765eb2c06e567._comment
new file mode 100644
index 0000000000..2285e90621
--- /dev/null
+++ b/doc/special_remotes/S3/comment_14_29574a51d5831c51e2e765eb2c06e567._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 14"
+ date="2013-05-24T16:45:25Z"
+ content="""
+I apologise for incorrect information. I was thinking about defaults when using the webapp.
+
+I have verified that embedcreds=yes stores the AWS creds, always.
+
+
+"""]]
diff --git a/doc/special_remotes/S3/comment_15_ceb9048c743135f6beca57a23505f0a3._comment b/doc/special_remotes/S3/comment_15_ceb9048c743135f6beca57a23505f0a3._comment
new file mode 100644
index 0000000000..a8b5573e77
--- /dev/null
+++ b/doc/special_remotes/S3/comment_15_ceb9048c743135f6beca57a23505f0a3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawne_amN4fko4p5cRY_9EYwaYuJKNn7LRio"
+ nickname="Tobias"
+ subject="different s3 storage URLs"
+ date="2013-08-23T08:59:32Z"
+ content="""
+Is it possible to change the S3 endpoint hosts? I'm running a radosgw with S3 support which I'd like to define as S3 remote for git-annex
+"""]]
diff --git a/doc/special_remotes/S3/comment_16_7b79f8b5ef88a2775d61b5ac5774d3e0._comment b/doc/special_remotes/S3/comment_16_7b79f8b5ef88a2775d61b5ac5774d3e0._comment
new file mode 100644
index 0000000000..508cedca43
--- /dev/null
+++ b/doc/special_remotes/S3/comment_16_7b79f8b5ef88a2775d61b5ac5774d3e0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 16"
+ date="2013-08-23T17:39:56Z"
+ content="""
+Yes, you can specify the host to use when setting up the remote. It's actually documented earlier on this very page, if ou search for \"host\". Any S3 compatabile host will probably work -- the Internet Archive's S3 does, for example.
+"""]]
diff --git a/doc/special_remotes/S3/comment_17_52d3510016c099d083553f9b3fa40db9._comment b/doc/special_remotes/S3/comment_17_52d3510016c099d083553f9b3fa40db9._comment
new file mode 100644
index 0000000000..85145ffb72
--- /dev/null
+++ b/doc/special_remotes/S3/comment_17_52d3510016c099d083553f9b3fa40db9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlc-3pdibcizrdz4WmZooECL0k6AvM1cWc"
+ nickname="Joe"
+ subject="S3 file/folder names"
+ date="2015-02-19T22:22:26Z"
+ content="""
+Is there a way to tell the S3 backend to store the files as they are named locally, instead of by hashed content name? i.e., I've annexed foo/bar.txt and annex puts it in s3 as mybucket.name/foo/bar.txt instead of mybucket.name/GPGHMACSHA1-random.txt
+
+Or should I just write a script to s3cmd sync my annex, and add the S3/cloudfront distribution URL as a web remote?
+"""]]
diff --git a/doc/special_remotes/S3/comment_18_0dcb84048563fc9e45b66ca8f365f320._comment b/doc/special_remotes/S3/comment_18_0dcb84048563fc9e45b66ca8f365f320._comment
new file mode 100644
index 0000000000..b5e776c80f
--- /dev/null
+++ b/doc/special_remotes/S3/comment_18_0dcb84048563fc9e45b66ca8f365f320._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="darkfeline"
+ subject="Sharing S3 bucket between repos"
+ date="2015-10-09T01:16:25Z"
+ content="""
+What are the implications of sharing an S3 remote/bucket between two repositories with using fileprefix?  Can this be used to \"deduplicate\" files shared between repositories?
+"""]]
diff --git a/doc/special_remotes/S3/comment_19_9d0d622b6202698f09eb06c097579fbb._comment b/doc/special_remotes/S3/comment_19_9d0d622b6202698f09eb06c097579fbb._comment
new file mode 100644
index 0000000000..e38def8ba7
--- /dev/null
+++ b/doc/special_remotes/S3/comment_19_9d0d622b6202698f09eb06c097579fbb._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2015-10-12T17:10:21Z"
+ content="""
+@darkfeline I suppose you're talking about two completely disjoint git
+repositories, and not two clones of the same parent repo.
+
+If you don't use fileprefix, and have the same file in two disjoint
+repositories, git-annex will pick the same key for it in both cases, and
+so you'll get deduplication, but only if you don't use different
+fileprefixes.
+
+And this will mostly work pretty well. The danger is, if you drop the file
+from the S3 repo, because say, it's not used anymore in one repository,
+then you're also removing it from the S3 repo as used by the other
+repository. If that was the last copy of the file, that may not be what you
+want.
+"""]]
diff --git a/doc/special_remotes/S3/comment_1_4a1f7a230dad6caa84831685b236fd73._comment b/doc/special_remotes/S3/comment_1_4a1f7a230dad6caa84831685b236fd73._comment
new file mode 100644
index 0000000000..17e35e7d99
--- /dev/null
+++ b/doc/special_remotes/S3/comment_1_4a1f7a230dad6caa84831685b236fd73._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnoUOqs_lbuWyZBqyU6unHgUduJwDDgiKY"
+ nickname="Matt"
+ subject="environment variables"
+ date="2012-05-29T12:40:25Z"
+ content="""
+Just noting that the environment variables `ANNEX_S3_ACCESS_KEY_ID` and `ANNEX_S3_SECRET_ACCESS_KEY` seem to have been changed to `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`
+"""]]
diff --git a/doc/special_remotes/S3/comment_20_ce4ce50d51675ee4746a2528d4bea750._comment b/doc/special_remotes/S3/comment_20_ce4ce50d51675ee4746a2528d4bea750._comment
new file mode 100644
index 0000000000..f574dd1a49
--- /dev/null
+++ b/doc/special_remotes/S3/comment_20_ce4ce50d51675ee4746a2528d4bea750._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="cantora@432fae6be728a32ac472387df86a8922f059d4a6"
+ nickname="cantora"
+ subject="How to view configuration of special remotes?"
+ date="2015-12-08T08:29:12Z"
+ content="""
+I don't remember which gpg key my s3 remote is using, but I can't seem to get git annex to tell me about the configuration of my s3 remote, which has the gpg key ID that I need to find (I need to restore it from many backed up keys, but need to know which one). Is there a way to view the remote metadata? I was hoping to see a command like `git annex remoteinfo NAME`. (git annex version: `5.20140408-gb37d538`).
+"""]]
diff --git a/doc/special_remotes/S3/comment_21_26cbfd805dd45a80121f5e2079afba37._comment b/doc/special_remotes/S3/comment_21_26cbfd805dd45a80121f5e2079afba37._comment
new file mode 100644
index 0000000000..cb7eb095aa
--- /dev/null
+++ b/doc/special_remotes/S3/comment_21_26cbfd805dd45a80121f5e2079afba37._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 21"""
+ date="2015-12-10T15:20:43Z"
+ content="""
+@cantora with a recent enough version of git-annex, `git annex info
+$theremotename` will show quite a lot of information about a special
+remote, including encryption details.
+"""]]
diff --git a/doc/special_remotes/S3/comment_22_55a7e513713285b8ced84c8cfd525364._comment b/doc/special_remotes/S3/comment_22_55a7e513713285b8ced84c8cfd525364._comment
new file mode 100644
index 0000000000..f07e7af12d
--- /dev/null
+++ b/doc/special_remotes/S3/comment_22_55a7e513713285b8ced84c8cfd525364._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tim@5431dd39464df207b7d46d3cf1bc74c82123ac68"
+ nickname="tim"
+ subject="Sharing S3 bucket without fileprefix"
+ date="2016-04-13T19:02:24Z"
+ content="""
+I was hoping to use the same bucket for multiple repo's (100+) with a lot of files in common. Dropping unused files would not be an issue for me, so from what I read above this should be possible.
+However I cannot get initremote nor enableremote to add a repo with an existing uuid. How do I add an already initialized bucket to a new git annex repo?
+"""]]
diff --git a/doc/special_remotes/S3/comment_23_b503ce70a4f008be580a069420361686._comment b/doc/special_remotes/S3/comment_23_b503ce70a4f008be580a069420361686._comment
new file mode 100644
index 0000000000..9e3d243208
--- /dev/null
+++ b/doc/special_remotes/S3/comment_23_b503ce70a4f008be580a069420361686._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2016-04-13T19:13:35Z"
+ content="""
+@tim, are the git-annex repositories going to be connected? If so,
+`git-annex initremote` the S3 remote to one, merge it into the next
+repo, and then `git annex enableremote` the S3 remote there.
+
+That's the sane way. If you want for some reason to have multiple separate
+git-annex repositories, that all try to use the same S3 bucket, without
+knowing about one-another, I have to recommend against it. You're setting
+yourself up to shoot yourself in the foot, and quite possibly lose data.
+
+While you can `git annex enableremote` the same bucket repeatedly in the
+different repositories, each time it will be given a different uuid, and
+since the uuid is stored in the bucket, this will prevent `git annex
+enableremote` from being used for the old uuid, since it will see the
+bucket has a different uuid now.
+"""]]
diff --git a/doc/special_remotes/S3/comment_24_b209474b90befc79a7139d6c5703e2d8._comment b/doc/special_remotes/S3/comment_24_b209474b90befc79a7139d6c5703e2d8._comment
new file mode 100644
index 0000000000..5d28cad7f5
--- /dev/null
+++ b/doc/special_remotes/S3/comment_24_b209474b90befc79a7139d6c5703e2d8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="justin.lebar@7a36fcafc322d9a381e89f08ab6289033c6dde91"
+ nickname="justin.lebar"
+ avatar="http://cdn.libravatar.org/avatar/9fca4b61a1ab555f231851e7543f9a3e"
+ subject="comment 24"
+ date="2016-11-01T04:10:25Z"
+ content="""
+Is it possible to edit an existing special remote to set embedcreds to true?
+"""]]
diff --git a/doc/special_remotes/S3/comment_25_29f2760e433a0e6229e46e728c380275._comment b/doc/special_remotes/S3/comment_25_29f2760e433a0e6229e46e728c380275._comment
new file mode 100644
index 0000000000..45dc7ed85a
--- /dev/null
+++ b/doc/special_remotes/S3/comment_25_29f2760e433a0e6229e46e728c380275._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 25"""
+ date="2016-11-01T18:30:31Z"
+ content="""
+@justin.lebar I think you can turn on embedcreds when using `git annex
+enableremote`.
+"""]]
diff --git a/doc/special_remotes/S3/comment_26_6b99242a6a681a1848041a8b8875743d._comment b/doc/special_remotes/S3/comment_26_6b99242a6a681a1848041a8b8875743d._comment
new file mode 100644
index 0000000000..227511dc11
--- /dev/null
+++ b/doc/special_remotes/S3/comment_26_6b99242a6a681a1848041a8b8875743d._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="bec.watson@8b5998670cf3d60f88e6297923d1391706e0d15b"
+ nickname="bec.watson"
+ avatar="http://cdn.libravatar.org/avatar/85dbb458c368c0790d74923caa32a581"
+ subject="comment 26"
+ date="2016-11-05T01:04:47Z"
+ content="""
+Hi,
+
+I've been unable to setup a remote in Beijing (region cn-north-1) as the signature request type doesn't seem to be V4
+
+MacBook-Pro:gitannex-china iwatson$ git annex initremote ings3cn bucket=\"testbec\" type=S3 chunk=50MiB encryption=none datacenter=\"cn-north-1\" initremote ings3cn (checking bucket...) (creating bucket in cn-north-1...) git-annex: FailedConnectionException2 \"testbec.s3-cn-north-1.amazonaws.com\" 80 False getAddrInfo: does not exist (nodename nor servname provided, or not known)
+
+The endpoints for china default to \"testbec.s3-cn-north-1.amazonaws.com\" but should be \"s3.cn-north-1.amazonaws.com.cn\". Using host option I can set this: MacBook-Pro:gitannex-china iwatson$ git annex initremote ings3cn bucket=\"testbec\" type=S3 chunk=50MiB encryption=none host=\"s3.cn-north-1.amazonaws.com.cn\" datacenter=\"cn-north-1\" initremote ings3cn (checking bucket...) (creating bucket in cn-north-1...) git-annex: S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = \"Bad Request\"}, s3ErrorCode = \"InvalidRequest\", s3ErrorMessage = \"The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256.\", s3ErrorResource = Nothing, s3ErrorHostId = Just \"xxx=\", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+
+However, the message is that the authorization mechanism isn't AWS4-HMAC-SHA256 - if you see AWS this is V4 required by china and all new AWS regions: http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html
+
+Do the S3 remotes use the new V4 signature method? I can't see what else I'm doing wrong here but any help would be appreciated!
+
+Thanks :) bec
+"""]]
diff --git a/doc/special_remotes/S3/comment_28_163d81443ca5a05138e6f570b068ac6e._comment b/doc/special_remotes/S3/comment_28_163d81443ca5a05138e6f570b068ac6e._comment
new file mode 100644
index 0000000000..6b577d58b3
--- /dev/null
+++ b/doc/special_remotes/S3/comment_28_163d81443ca5a05138e6f570b068ac6e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="mca@8789632e0b00e8efb984c948c13d9de28665f534"
+ nickname="mca"
+ avatar="http://cdn.libravatar.org/avatar/758861fe4b6231b85e761a91d6f01a2e"
+ subject="https-only access, type=S3 port=443"
+ date="2017-01-05T13:10:43Z"
+ content="""
+(My own question, answered by Use The Source Luke method)
+
+If you need to point a `type=S3` special remote at a service which provides only https (in my case, a local CEPH RADOS gateway) then you can do it by setting `port=443`.
+
+This was implemented in 6fcca2f1 and next tag was 5.20141203 .  On Ubuntu, that version is available in Xenial but not Trusty.
+
+"""]]
diff --git a/doc/special_remotes/S3/comment_28_c4dafad82a898eafd6d9e3703fad2c48._comment b/doc/special_remotes/S3/comment_28_c4dafad82a898eafd6d9e3703fad2c48._comment
new file mode 100644
index 0000000000..864974205c
--- /dev/null
+++ b/doc/special_remotes/S3/comment_28_c4dafad82a898eafd6d9e3703fad2c48._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="David_K"
+ avatar="http://cdn.libravatar.org/avatar/09dd8544695feb9b8d8ee54e4ff0168d"
+ subject="comment 28"
+ date="2016-11-16T01:28:14Z"
+ content="""
+I'd like to reiterate a question that was unanswered above:
+
+Is there a way to tell the S3 backend to store the files as they are named locally, instead of by hashed content name? i.e., I've annexed foo/bar.txt and annex puts it in s3 as mybucket.name/foo/bar.txt instead of mybucket.name/GPGHMACSHA1-random.txt
+
+
+"""]]
diff --git a/doc/special_remotes/S3/comment_29_37430a66a9f39a635b32f04ff82db194._comment b/doc/special_remotes/S3/comment_29_37430a66a9f39a635b32f04ff82db194._comment
new file mode 100644
index 0000000000..c85693de3e
--- /dev/null
+++ b/doc/special_remotes/S3/comment_29_37430a66a9f39a635b32f04ff82db194._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 29"""
+ date="2017-09-08T20:46:28Z"
+ content="""
+@David_K @Joe, it's finally possible to publish annexed files to S3 while
+preserving filenames, using the new `git annex export` command!
+See [[tips/publishing_your_files_to_the_public]].
+"""]]
diff --git a/doc/special_remotes/S3/comment_2_5b22d67de946f4d34a4a3c7449d32988._comment b/doc/special_remotes/S3/comment_2_5b22d67de946f4d34a4a3c7449d32988._comment
new file mode 100644
index 0000000000..f535559aeb
--- /dev/null
+++ b/doc/special_remotes/S3/comment_2_5b22d67de946f4d34a4a3c7449d32988._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.81.112"
+ subject="comment 2"
+ date="2012-05-29T19:10:46Z"
+ content="""
+Thanks, I've fixed that. (You could have too.. this is a wiki ;)
+"""]]
diff --git a/doc/special_remotes/S3/comment_30_db7e1e3506cf7a912cf88ffe4caea20b._comment b/doc/special_remotes/S3/comment_30_db7e1e3506cf7a912cf88ffe4caea20b._comment
new file mode 100644
index 0000000000..1339e6f7c1
--- /dev/null
+++ b/doc/special_remotes/S3/comment_30_db7e1e3506cf7a912cf88ffe4caea20b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 30"
+ date="2019-05-02T16:04:05Z"
+ content="""
+\"When versioning is not enabled, this risks data loss\" -- maybe, add an option to always import before exporting?  I don't want to enable versioning since that permanently loses the chance of dropping any objects (even if they're stored elsewhere).
+
+Also, versioning on S3 buckets can be suspended/resumed; not sure if git-annex uses current bucket versioning state or the remote configuration.
+"""]]
diff --git a/doc/special_remotes/S3/comment_31_e46934941fca2de536f3705185098b6e._comment b/doc/special_remotes/S3/comment_31_e46934941fca2de536f3705185098b6e._comment
new file mode 100644
index 0000000000..6fa730a8c5
--- /dev/null
+++ b/doc/special_remotes/S3/comment_31_e46934941fca2de536f3705185098b6e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 31"""
+ date="2019-05-06T16:27:44Z"
+ content="""
+@Ilya, importing before exporting does not avoid losing any data that gets
+written at just the wrong time. Versioning is the only way to guarantee no
+data loss.
+
+If you enable versioning for the bucket and then disable it or don't
+version some items, git-annex won't notice and if you then do an export I'm
+afraid you again risk losing data.
+"""]]
diff --git a/doc/special_remotes/S3/comment_32_197d0c6d632c201a4ea9680653895c07._comment b/doc/special_remotes/S3/comment_32_197d0c6d632c201a4ea9680653895c07._comment
new file mode 100644
index 0000000000..06d23cb427
--- /dev/null
+++ b/doc/special_remotes/S3/comment_32_197d0c6d632c201a4ea9680653895c07._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Zoran"
+ avatar="http://cdn.libravatar.org/avatar/fec41ebb8626f00ca9c645d20a79e8fe"
+ subject="Deep Archive Storage Class"
+ date="2019-09-22T09:02:16Z"
+ content="""
+Does anybody have experience with the Deep Archive storage class?
+"""]]
diff --git a/doc/special_remotes/S3/comment_33_36788d742259b3b078e02d7b2a251ce5._comment b/doc/special_remotes/S3/comment_33_36788d742259b3b078e02d7b2a251ce5._comment
new file mode 100644
index 0000000000..2c47361014
--- /dev/null
+++ b/doc/special_remotes/S3/comment_33_36788d742259b3b078e02d7b2a251ce5._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="cnjr2"
+ avatar="http://cdn.libravatar.org/avatar/f7e9654cc967c8815947b19829bfd746"
+ subject="comment 33"
+ date="2020-02-12T10:37:24Z"
+ content="""
+First of all thanks for `git-annex`! I have recently discovered it and was so pleased to see how it solves problems that I had not anticipated!
+
+Related to [comment 26](http://git-annex.branchable.com/special_remotes/S3/#comment-e2000bfcb5d4c2d1a017f52c1c02a1ba) above, I want to create a bucket in Frankfurt. It seems like the aws library used by git-annex is from [aristidb/aws](https://github.com/aristidb/aws) where the topic of `V4` signing was raised in [this issue](https://github.com/aristidb/aws/issues/167) ([comment](https://github.com/aristidb/aws/issues/167#issuecomment-258864661) by you joey?). 
+
+Are there workarounds here? I can only use Frankfurt.
+
+Thanks again!
+
+
+"""]]
diff --git a/doc/special_remotes/S3/comment_34_cf57e8dbd9fdc7c487565b61808b6bb2._comment b/doc/special_remotes/S3/comment_34_cf57e8dbd9fdc7c487565b61808b6bb2._comment
new file mode 100644
index 0000000000..bfdb4b36a0
--- /dev/null
+++ b/doc/special_remotes/S3/comment_34_cf57e8dbd9fdc7c487565b61808b6bb2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""V4"""
+ date="2020-05-07T16:49:05Z"
+ content="""
+@bec.watson, I've now added a way to use V4 authentication, the signature=v4
+option. 
+
+Please file a bug report if it still doesn't work.
+"""]]
diff --git a/doc/special_remotes/S3/comment_35_a141196a77d77cc6e130185dbf01e48b._comment b/doc/special_remotes/S3/comment_35_a141196a77d77cc6e130185dbf01e48b._comment
new file mode 100644
index 0000000000..e00c23eff6
--- /dev/null
+++ b/doc/special_remotes/S3/comment_35_a141196a77d77cc6e130185dbf01e48b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 35"
+ date="2020-05-10T16:30:51Z"
+ content="""
+> I don't want to enable versioning since that permanently loses the chance of dropping any objects (even if they're stored elsewhere)
+
+I believe it is in principle [possible to remove object versions](https://docs.aws.amazon.com/cli/latest/reference/s3api/delete-object.html) from S3 and/or completely wipe out an object with all of its versions (so it wouldn't be just a DeleteMarker added as the most recent version).  So in principle git-annex could (if doesn't already, didn't check) delete previous versions in a versioned bucket upon `drop`.
+"""]]
diff --git a/doc/special_remotes/S3/comment_36_9c900d777c9add9c277d40bd5b32bdf6._comment b/doc/special_remotes/S3/comment_36_9c900d777c9add9c277d40bd5b32bdf6._comment
new file mode 100644
index 0000000000..8ded8d3ef4
--- /dev/null
+++ b/doc/special_remotes/S3/comment_36_9c900d777c9add9c277d40bd5b32bdf6._comment
@@ -0,0 +1,90 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="ACL deprecation vs public=yes "
+ date="2022-07-05T18:20:50Z"
+ content="""
+Amazon has [deprecated ACLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html)
+
+> A majority of modern use cases in Amazon S3 no longer require the use of ACLs, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually. With Object Ownership, you can disable ACLs and rely on policies for access control. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies.
+
+They are encouraging everyone to [migrate to bucket policies](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-ownership-migrating-acls-prerequisites.html) instead.
+
+## Implementation
+
+I've done this for a bucket I run. I wrote and attached this Bucket Policy to it:
+
+```
+{
+    \"Version\": \"2012-10-17\",
+    \"Statement\": [
+        {
+            \"Effect\": \"Allow\",
+            \"Principal\": \"*\",
+            \"Action\": \"s3:GetObject\",
+            \"Resource\": [
+                \"arn:aws:s3:::BUCKET-NAME\",
+                \"arn:aws:s3:::BUCKET-NAME/*\"
+            ]
+        }
+    ]
+}
+```
+
+I had to reset the ACLs on that bucket to the default:
+
+* Bucket owner (your AWS account):
+  * Objects:
+    - List
+    - Write
+  * Bucket ACL:
+    - Read
+    - Write
+
+and with that set Amazon let me also set
+
+* Object ownership: Bucket owner enforced
+
+
+## git-annex incompatibility
+
+But, attempting to use the new setup failed:
+
+```
+$ git annex copy --to amazon what.nii.gz 
+copy what.nii.gz (checking amazon...) (to amazon...) 
+41%   8.15 MiB         20 MiB/s 0s
+  S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = \"Bad Request\"}, s3ErrorCode = \"AccessControlListNotSupported\", s3ErrorMessage = \"The bucket does not allow ACLs\", s3ErrorResource = Nothing, s3ErrorHostId = Just \"a6+ieujj4z3Z4P8ooA306DdbGAoxWDiXd6O2ZwjdfapGnuOGPyL5/WQ4UBEytR80FG+5b6xdlsM=\", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+
+32%   6.43 MiB         16 MiB/s 0s 
+  S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = \"Bad Request\"}, s3ErrorCode = \"AccessControlListNotSupported\", s3ErrorMessage = \"The bucket does not allow ACLs\", s3ErrorResource = Nothing, s3ErrorHostId = Just \"bFOgMomROCOes9yI6HZHysQGoZaTbsPI5b7rHjcTI0wA8Yx5Dm1JOky9BvXvpcXxzY1kVt48FRQ=\", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+
+37%   7.37 MiB         21 MiB/s 0s 
+  S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = \"Bad Request\"}, s3ErrorCode = \"AccessControlListNotSupported\", s3ErrorMessage = \"The bucket does not allow ACLs\", s3ErrorResource = Nothing, s3ErrorHostId = Just \"hqd4HRNk5yp3tKJ6yMhcECEpCjBw8qB6oTpKF3PaOsYFeVG0C+dGI06xq3zgmvnPoFUttI040sY=\", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+
+39%   7.81 MiB         21 MiB/s 0s 
+  S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = \"Bad Request\"}, s3ErrorCode = \"AccessControlListNotSupported\", s3ErrorMessage = \"The bucket does not allow ACLs\", s3ErrorResource = Nothing, s3ErrorHostId = Just \"7m7wwG5woSPmICIuXr9QnBOEjUikuyzHSebMLuaNyZMc2Ki2vaqKpU9U+GOTYmR/NzFjOeyxngk=\", s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+failed
+git-annex: copy: 1 failed
+```
+
+## Workaround
+
+However, this fixed it:
+
+```
+$ git annex enableremote amazon public=no
+enableremote amazon ok
+(recording state in git...)
+$ git annex copy --to amazon what.nii.gz 
+copy what.nii.gz (checking amazon...) (to amazon...) 
+ok                                
+```
+
+
+## Feature Request
+
+- If public=yes, instead of trying to set an ACL, first try `HEAD` on the newly uploaded object without using the `AWS_ACCESS_KEY`. Only if that fails, fall over to trying to set an ACL. And if you get `AccessControlListNotSupported` (i.e. the error due to `BucketOwnerEnforced`), then give a warning that the bucket policy is not configured for public access.
+- Update the docs here to explain how to set up a public bucket policy as recommended by Amazon, and that `public=yes` will _either_ try to confirm that the bucket policy is public, or will fallback to using ACLs.
+"""]]
diff --git a/doc/special_remotes/S3/comment_37_fef35384191078ed9ac6ee819eea4aa7._comment b/doc/special_remotes/S3/comment_37_fef35384191078ed9ac6ee819eea4aa7._comment
new file mode 100644
index 0000000000..7f9492bef9
--- /dev/null
+++ b/doc/special_remotes/S3/comment_37_fef35384191078ed9ac6ee819eea4aa7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 37"""
+ date="2022-07-05T20:24:05Z"
+ content="""
+@nick.guenther A comment on this page is really not the place to report a bug like this.
+See [[bugs]] for where to file a bug.
+"""]]
diff --git a/doc/special_remotes/S3/comment_38_03ba1dcf23e04b8c54b53b10a93e1c45._comment b/doc/special_remotes/S3/comment_38_03ba1dcf23e04b8c54b53b10a93e1c45._comment
new file mode 100644
index 0000000000..f2d2bab2d5
--- /dev/null
+++ b/doc/special_remotes/S3/comment_38_03ba1dcf23e04b8c54b53b10a93e1c45._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="comment 38"
+ date="2022-07-15T15:55:38Z"
+ content="""
+Thanks for taking the time to direct me, Joey.  I usually find myself getting lost in this wiki amongst all the old notes and worklogs and documentation about old features, so sometimes someone coming along with a sign post is a very kind help :)
+"""]]
diff --git a/doc/special_remotes/S3/comment_3_bcab2bd0f168954243aa9bcc9671bd94._comment b/doc/special_remotes/S3/comment_3_bcab2bd0f168954243aa9bcc9671bd94._comment
new file mode 100644
index 0000000000..abb6aacc96
--- /dev/null
+++ b/doc/special_remotes/S3/comment_3_bcab2bd0f168954243aa9bcc9671bd94._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnoUOqs_lbuWyZBqyU6unHgUduJwDDgiKY"
+ nickname="Matt"
+ subject="comment 3"
+ date="2012-05-30T00:26:33Z"
+ content="""
+Thanks! Being new here, I didn't want to overstep my boundaries. I've gone ahead and made a small edit and will do so elsewhere as needed.
+"""]]
diff --git a/doc/special_remotes/S3/comment_4_38c0b062997fde1ad28facc05d973e83._comment b/doc/special_remotes/S3/comment_4_38c0b062997fde1ad28facc05d973e83._comment
new file mode 100644
index 0000000000..8c17f7d644
--- /dev/null
+++ b/doc/special_remotes/S3/comment_4_38c0b062997fde1ad28facc05d973e83._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmX5gPNK35Dub-HzR0Yb3KXllbqc0rYRYs"
+ nickname="Eduardo"
+ subject="bucket/folder s3 remotes"
+ date="2012-08-09T10:52:07Z"
+ content="""
+it'd be really nice being able to configure a S3 remote of the form `<bucket>/<folder>` (not really a folder, of course, just the usual prefix trick used to simulate folders at S3). The remote = bucket architecture is not scalable at all, in terms of number of repositories.
+
+how hard would it be to support this?
+
+thanks, this is the only thing that's holding us back from using git-annex, nice tool!
+"""]]
diff --git a/doc/special_remotes/S3/comment_5_409bc2b56382417cf26bb222fb783ba7._comment b/doc/special_remotes/S3/comment_5_409bc2b56382417cf26bb222fb783ba7._comment
new file mode 100644
index 0000000000..325db67998
--- /dev/null
+++ b/doc/special_remotes/S3/comment_5_409bc2b56382417cf26bb222fb783ba7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 5"
+ date="2012-08-09T18:01:06Z"
+ content="""
+I guess this could be useful if you have a *lot* of buckets already in use at S3, or if you want to be able to have a lot of distinct S3 special remotes. Implemented the `fileprefix` setting. Note that I have not tested it, beyond checking it builds, since I let my S3 account expire. Your testing would be appreciated.
+
+"""]]
diff --git a/doc/special_remotes/S3/comment_6_78da9e233882ec0908962882ea8c4056._comment b/doc/special_remotes/S3/comment_6_78da9e233882ec0908962882ea8c4056._comment
new file mode 100644
index 0000000000..742dbedc2f
--- /dev/null
+++ b/doc/special_remotes/S3/comment_6_78da9e233882ec0908962882ea8c4056._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnY9ObrNrQuRp8Xs0XvdtJJssm5cp4NMZA"
+ nickname="alan"
+ subject="Rackspace Cloud Files support?"
+ date="2012-08-23T21:00:11Z"
+ content="""
+Any chance I could bribe you to setup Rackspace Cloud Files support?  We are using them and would hate to have a S3 bucket only for this.
+
+https://github.com/rackspace/python-cloudfiles
+"""]]
diff --git a/doc/special_remotes/S3/comment_7_6af9781004d982d8e6b20a83ad29eead._comment b/doc/special_remotes/S3/comment_7_6af9781004d982d8e6b20a83ad29eead._comment
new file mode 100644
index 0000000000..c243cde132
--- /dev/null
+++ b/doc/special_remotes/S3/comment_7_6af9781004d982d8e6b20a83ad29eead._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmyFvkaewo432ELwtCoecUGou4v3jCP0Pc"
+ nickname="Eric"
+ subject="S3 Remote Future Proof?"
+ date="2013-01-20T09:21:50Z"
+ content="""
+Joey, I'm curious to understand how future proof an S3 remote is.  Can I restore my files without git-annex?
+"""]]
diff --git a/doc/special_remotes/S3/comment_8_0fa68d584ee7f6b5c9058fba7e911a11._comment b/doc/special_remotes/S3/comment_8_0fa68d584ee7f6b5c9058fba7e911a11._comment
new file mode 100644
index 0000000000..9212ca13f3
--- /dev/null
+++ b/doc/special_remotes/S3/comment_8_0fa68d584ee7f6b5c9058fba7e911a11._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="68.119.100.5"
+ subject="comment 8"
+ date="2013-01-20T20:37:09Z"
+ content="""
+If encryption is not used, the files are stored in S3 as-is, and can be accessed directly. The S3 bucket contains object named using the git-annex key, rather than the original filename. To get back to the original filename, a copy of the git repo would also be needed.
+
+With encryption, you need the gpg key used in the encryption, or, for shared encryption, a symmetric key which is stored in the git repo.
+
+See [[future proofing]] for non-S3 specific discussion of this topic.
+"""]]
diff --git a/doc/special_remotes/S3/comment_9_7ad757b3865b04967c79af0a263bb3b0._comment b/doc/special_remotes/S3/comment_9_7ad757b3865b04967c79af0a263bb3b0._comment
new file mode 100644
index 0000000000..51b7ab16ae
--- /dev/null
+++ b/doc/special_remotes/S3/comment_9_7ad757b3865b04967c79af0a263bb3b0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="basak"
+ ip="2001:8b0:1c8::2"
+ subject="Recovering from a clone"
+ date="2013-05-22T18:32:05Z"
+ content="""
+How do I recover a special remote from a clone, please? I see that `remote.log` has most of the details, but my remote is not configured on my clone and I see no obvious way to do it. And I used `embedcreds`, but the only credentials I can see are stored in .git/annex/creds/ so did not survive a clone. I'm confused because the documentation here for `embedcreds` says that clones should have access.
+
+As a workaround, it looks like copying the remote over from `.git/config` as well as the credentials from `.git/annex/creds/` seems to work. Is there some other way I'm supposed to do this, or is this the intended way?
+"""]]
diff --git a/doc/special_remotes/adb.mdwn b/doc/special_remotes/adb.mdwn
new file mode 100644
index 0000000000..ebd1c1c3da
--- /dev/null
+++ b/doc/special_remotes/adb.mdwn
@@ -0,0 +1,49 @@
+This special remote stores files on an Android device.
+
+The `adb` program is used to access the Android device, which
+allows connecting to it in various ways like a USB cable or wifi.
+
+## example
+
+To add a remote for the /sdcard/DCIM directory
+on the Android device, allowing to import and export photos:
+
+	git annex initremote android type=adb androiddirectory=/sdcard/DCIM encryption=none exporttree=yes importtree=yes
+	git annex export master --to android
+
+## configuration
+
+A number of parameters can be passed to `git annex initremote` to configure
+the adb remote.
+
+* `androiddirectory` - Set to the location on the Android device where
+  files for the special remote are stored.
+
+* `androidserial` - Normally this is not needed, but if multiple Android
+  devices are accessible, you'll be prompted to use it to specify which
+  one to use.
+
+* `exporttree` - Set to "yes" to make this special remote usable
+  by [[git-annex-export]]. It will not be usable as a general-purpose
+  special remote. Since this makes the exported files easily browsable
+  on the Android device, you will almost always want to enable this.
+
+* `importtree` - Set to "yes" to make this special remote usable
+  by [[git-annex-import]]. When set in combination with exporttree,
+  this lets files be imported from it, and changes exported back to it.
+
+* `oldandroid` - Set to "yes" if your Android device is too old
+  to support `find -printf`. Enabling this will make importing slower.
+  If you see an error like "bad arg '-printf'", you can enable this
+  option, by running eg: `git-annex enableremote android oldandroid=yes`
+
+* `ignorefinderror` - Set to "yes" to ignore errors when running "adb find"
+  on the Android device. This can be useful eg, if some subdirectories are
+  not readable, to let it import the other things that are readable.
+
+* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
+  See [[encryption]].
+
+* `keyid` - Specifies the gpg key to use for [[encryption]].
+
+* `chunk` - Enables [[chunking]] when storing large files.
diff --git a/doc/special_remotes/adb/comment_1_df47283c499cddd1d92a262679514531._comment b/doc/special_remotes/adb/comment_1_df47283c499cddd1d92a262679514531._comment
new file mode 100644
index 0000000000..0ba9387d1b
--- /dev/null
+++ b/doc/special_remotes/adb/comment_1_df47283c499cddd1d92a262679514531._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="iakornfeld@eaf45f0b645324dd9f1f57f226377caddf86a80e"
+ nickname="iakornfeld"
+ avatar="http://cdn.libravatar.org/avatar/491e18e0a8b039917830d2db0b3c4061"
+ subject="Git"
+ date="2018-05-09T13:51:55Z"
+ content="""
+Does this remotely access a normal repository, or does it store the files directly (with the metadata stored on the host)?
+"""]]
diff --git a/doc/special_remotes/adb/comment_2_f1f6c0a6f8c34c3d205988d2f69693ea._comment b/doc/special_remotes/adb/comment_2_f1f6c0a6f8c34c3d205988d2f69693ea._comment
new file mode 100644
index 0000000000..90b4b9fef3
--- /dev/null
+++ b/doc/special_remotes/adb/comment_2_f1f6c0a6f8c34c3d205988d2f69693ea._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-05-09T20:17:28Z"
+ content="""
+@iakornfeld, like all special remotes, the git repository is not stored in
+the special remote, only the content of annexed files.
+
+Using `git annex export` like in the example, the android device will
+contain files with the same names as those in your git-annex repository.
+
+If you want to use a git-annex repository on the Android device, see
+[[install/Android]] instead of this. However, for pushing a tree of annexed
+files to Android device and updating it, this special remote can be a good
+fit.
+"""]]
diff --git a/doc/special_remotes/adb/comment_3_1d08d2ded354328461e9a7288287779e._comment b/doc/special_remotes/adb/comment_3_1d08d2ded354328461e9a7288287779e._comment
new file mode 100644
index 0000000000..213630438e
--- /dev/null
+++ b/doc/special_remotes/adb/comment_3_1d08d2ded354328461e9a7288287779e._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="post@fe1e2f98b8a3e74db4acafa380bba9a4454f335d"
+ nickname="post"
+ avatar="http://cdn.libravatar.org/avatar/6faa6cc783a165b25fc1c8f3154ba449"
+ subject="Import fails with"
+ date="2021-03-15T23:58:59Z"
+ content="""
+I am getting the following error on recent imports using the adb remote:
+
+    list android find: exec stat: Argument list too long
+    
+    git-annex: Unable to list contents of android: adb find failed
+    failed
+    git-annex: import: 1 failed
+
+I dont know if this is due to a recent update of git-annex or simply the growth of the files on my phone.
+
+Cheers,
+Steffen
+"""]]
diff --git a/doc/special_remotes/adb/comment_4_9f5edeb544f6a26e9278410ef67e99ba._comment b/doc/special_remotes/adb/comment_4_9f5edeb544f6a26e9278410ef67e99ba._comment
new file mode 100644
index 0000000000..4dcdc7567c
--- /dev/null
+++ b/doc/special_remotes/adb/comment_4_9f5edeb544f6a26e9278410ef67e99ba._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-03-22T14:32:28Z"
+ content="""
+It would probably be better to file a bug report about it than to
+discuss the problem here. I guess something you could include in the bug
+report is how many files are in the directory.
+
+It may be that android's `find` command is either not breaking up the list
+of files that it passes to the -exec command at all, or is confused about
+how big an argument list it can build up. So this could also depend on your
+version of Android, so be sure to include that in the bug report.
+"""]]
diff --git a/doc/special_remotes/adb/comment_5_c9a3427bc8e924cd1f50246b3ec7c081._comment b/doc/special_remotes/adb/comment_5_c9a3427bc8e924cd1f50246b3ec7c081._comment
new file mode 100644
index 0000000000..f8f2de26a2
--- /dev/null
+++ b/doc/special_remotes/adb/comment_5_c9a3427bc8e924cd1f50246b3ec7c081._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="dud225@35a1ee469f82f3a7eb1f2dce4ad453f5e47bdfd3"
+ nickname="dud225"
+ avatar="http://cdn.libravatar.org/avatar/5147563e50c475918474594d93be95c2"
+ subject="Disabling a special remote"
+ date="2023-07-04T20:54:19Z"
+ content="""
+Is there any way to enable a special remote on demand?
+
+My configuration is comprised of local standard remotes (directories located on the same computer) and my phone as described in the Android tutorial [1]. I've noticed that git-annex automatically ignores the standard remotes that are missing (the aforementioned directories actually map to external drives that may or may not be connected), that's perfect, but for the phone special remote it seems to always try to connect to it, as a result the command \"git annex sync\" constantly outputs error messages:
+
+    list phone error: device 'xxxx' not found
+    
+    git-annex: Unable to list contents of phone: adb find failed
+    failed
+
+
+[1] https://git-annex.branchable.com/tips/android_sync_with_adb/
+"""]]
diff --git a/doc/special_remotes/adb/comment_7_73ea2ada02df871b0c9795a5b769f7db._comment b/doc/special_remotes/adb/comment_7_73ea2ada02df871b0c9795a5b769f7db._comment
new file mode 100644
index 0000000000..f20f80071d
--- /dev/null
+++ b/doc/special_remotes/adb/comment_7_73ea2ada02df871b0c9795a5b769f7db._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="dud225@35a1ee469f82f3a7eb1f2dce4ad453f5e47bdfd3"
+ nickname="dud225"
+ avatar="http://cdn.libravatar.org/avatar/5147563e50c475918474594d93be95c2"
+ subject="Disabling a special remote"
+ date="2023-07-07T14:16:24Z"
+ content="""
+Finally found the answer on my own:
+
+    git config remote.phone.annex-sync false
+
+
+"""]]
diff --git a/doc/special_remotes/bittorrent.mdwn b/doc/special_remotes/bittorrent.mdwn
new file mode 100644
index 0000000000..4e18757193
--- /dev/null
+++ b/doc/special_remotes/bittorrent.mdwn
@@ -0,0 +1,32 @@
+Similar to the [[web]] special remote, git-annex can use BitTorrent as
+a source for files that are added to the git-annex repository.
+
+It supports both `.torrent` files, and `magnet:` links. When you run `git
+annex addurl` with either of these, it will download the contents of the
+torrent and add it to the git annex repository.
+
+See [[tips/using_the_web_as_a_special_remote]] for usage examples.
+
+git-annex uses [aria2](http://aria2.sourceforge.net/) to download torrents.
+
+If git-annex is not built using the haskell torrent library to parse
+torrents, it also needs the `btshowmetainfo` program, from either
+bittornado or the original BitTorrent client.
+
+The bittorrent special remote is always enabled, without any manual setup being
+needed. Its name is "bittorrent".
+
+## notes
+
+Currently git-annex only supports downloading content from a torrent; 
+it cannot upload or remove content.
+
+Multi-file torrents are supported; to handle them, `git annex addurl`
+will add a directory containing all the files from the torrent.
+
+It's hard to say if a torrent is healthy enough to let a file be downloaded
+from it, and harder to predict if a torrent will stay healthy. So,
+git-annex takes a cautious approach and when dropping a file, won't
+treat this special remote as one of the required [[copies]]. It's probably
+a good idea to configure git-annex to fully distrust this remote, by
+running `git annex untrust bittorrent`
diff --git a/doc/special_remotes/bittorrent/comment_1_4ef590d88bacd763abd5ce209e6b9640._comment b/doc/special_remotes/bittorrent/comment_1_4ef590d88bacd763abd5ce209e6b9640._comment
new file mode 100644
index 0000000000..8518e0ff8d
--- /dev/null
+++ b/doc/special_remotes/bittorrent/comment_1_4ef590d88bacd763abd5ce209e6b9640._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="wzhd"
+ subject="attaching a torrent file to a downloaded and annexed directory"
+ date="2016-01-19T10:07:27Z"
+ content="""
+I have a multi-file torrent that has been downloaded and annexed. After reading the article about web remote, I thought `git-annex addurl --file` could be used. However, when I tried `git-annex addurl --file video/tvseries/someseries /tmp/some.torrent`, I get the error 
+
+    addurl video/tvseries/someseries git-annex: video/anime/tvseries/someseries already exists and is not annexed; not overwriting
+
+Attaching the torrent to one of the files inside failed, too, with the message:
+
+    addurl video/tvseries/someseries/someepisode.mkv 
+    while adding a new url to an already annexed file, failed to verify url exists: /tmp/some.torrent
+    failed
+    git-annex: addurl: 1 failed
+
+"""]]
diff --git a/doc/special_remotes/bittorrent/comment_2_bccc7409111e4df4f4aab3b21fa4d321._comment b/doc/special_remotes/bittorrent/comment_2_bccc7409111e4df4f4aab3b21fa4d321._comment
new file mode 100644
index 0000000000..56ac48bcce
--- /dev/null
+++ b/doc/special_remotes/bittorrent/comment_2_bccc7409111e4df4f4aab3b21fa4d321._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="Re: attaching a torrent file to a downloaded and annexed directory"
+ date="2016-10-07T09:11:55Z"
+ content="""
+wzhd, you can do `git annex addurl file:///full/path/to/file.torrent`. this has the downside of denoting a local file that may vanish or not be present at the same location in another checkout, but then again, same goes for http uris. (i'd rather like the torrent file or at least the info part thereof present in git or git-annex; adding the torrent with `addurl --raw` and then using its `file://` url at least gives all the data needed to use the torrent again).
+"""]]
diff --git a/doc/special_remotes/bittorrent/comment_3_1e2372988e37c07b47a407f2eb979190._comment b/doc/special_remotes/bittorrent/comment_3_1e2372988e37c07b47a407f2eb979190._comment
new file mode 100644
index 0000000000..40aa4a50c0
--- /dev/null
+++ b/doc/special_remotes/bittorrent/comment_3_1e2372988e37c07b47a407f2eb979190._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="workaround not working any more"
+ date="2019-08-21T11:34:23Z"
+ content="""
+The workaround I described above ceased to work when git-annex or aria2c got configured more strictly; attempting it now gives a \"download failed: Configuration does not allow accessing\" error message – that is understandable in a way (redirects from web pages should really not make git-annex access local files), but leaves wzhd's problem open again.
+"""]]
diff --git a/doc/special_remotes/bittorrent/comment_4_aedac7a8482f710637493464b9e76fa7._comment b/doc/special_remotes/bittorrent/comment_4_aedac7a8482f710637493464b9e76fa7._comment
new file mode 100644
index 0000000000..27f9b8473a
--- /dev/null
+++ b/doc/special_remotes/bittorrent/comment_4_aedac7a8482f710637493464b9e76fa7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-09-06T15:57:45Z"
+ content="""
+annex.security.allowed-url-schemes can be configured to allow using file:
+urls.
+
+However, adding a temp file as an url does not seem very useful. Seems
+that a much more typical bittorrent way to go would be to find or 
+generate a magnet: url for the torrent.
+"""]]
diff --git a/doc/special_remotes/borg.mdwn b/doc/special_remotes/borg.mdwn
new file mode 100644
index 0000000000..47ec791990
--- /dev/null
+++ b/doc/special_remotes/borg.mdwn
@@ -0,0 +1,44 @@
+This special remote type accesses annexed files stored in a
+[borg](https://www.borgbackup.org/) repository.
+
+Unlike most special remotes, git-annex cannot be used to store annexed
+files in this special remote. You store files by using `borg create` to
+store the git-annex repository in borg. Then `git-annex sync` will learn
+about the annexed files that are stored in the borg repository.
+
+## setup example
+
+	# borg init --encryption=keyfile /path/to/borgrepo
+	# git annex initremote borg type=borg borgrepo=/path/to/borgrepo
+	# borg create /path/to/borgrepo::{now} `pwd`
+	# git annex sync borg
+
+## configuration
+
+These parameters can be passed to `git annex initremote` to configure the
+remote:
+
+* `borgrepo` - The location of a borg repository, eg a path, or
+  `user@host:path` for ssh access.
+
+* `subdir` - The subdirectory within the borg repository where git-annex
+  should look for annex object files. The default is to look through the
+  whole borg repository.
+
+  This is useful to avoid learning about annex objects in the borg
+  repository that belong to unrelated git-annex repositories. It can also
+  make syncing faster.
+
+* `appendonly` - You could use borg to delete content from the
+  repository at any time, so this defaults to "no", which 
+  makes the remote be untrusted. If you set to "yes", you must
+  take care to avoid using commands like `borg delete`,
+  `borg prune` with the borg repository.
+
+## avoid archive name reuse
+
+Borg repositories contain archives, and git-annex assumes that, once
+created, the content of an archive does not change. So if you delete an
+archive and then create a new archive with the same name, it will confuse
+git-annex about what is contained in the borg repository. So will using
+`borg recreate` to remove files from an archive.
diff --git a/doc/special_remotes/borg/comment_1_2a650af185a4eee5fd7fc350ed395e2c._comment b/doc/special_remotes/borg/comment_1_2a650af185a4eee5fd7fc350ed395e2c._comment
new file mode 100644
index 0000000000..cf62744702
--- /dev/null
+++ b/doc/special_remotes/borg/comment_1_2a650af185a4eee5fd7fc350ed395e2c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="tomdhunt"
+ avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
+ subject="Memory issues"
+ date="2021-10-03T22:30:04Z"
+ content="""
+When I tried running `git annex sync borg` on a large (~6T) borg repo with many archives, git-annex spun until it used 52G of memory, then got OOM-killed.
+
+I don't know if this is a memory leak or just trying to load too much, but it seems like this is a thing you should be able to do on a machine with 64G of RAM.
+"""]]
diff --git a/doc/special_remotes/borg/comment_2_6e6baf5467efcae70729e18975d8eb1a._comment b/doc/special_remotes/borg/comment_2_6e6baf5467efcae70729e18975d8eb1a._comment
new file mode 100644
index 0000000000..19a31cac01
--- /dev/null
+++ b/doc/special_remotes/borg/comment_2_6e6baf5467efcae70729e18975d8eb1a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-10-05T15:12:00Z"
+ content="""
+I have opened a bug for that issue,
+[[bugs/borg_special_remote_memory_usage_high_for_large_borg_repo]].
+
+It would be good if you could followup there with details.
+"""]]
diff --git a/doc/special_remotes/bup.mdwn b/doc/special_remotes/bup.mdwn
new file mode 100644
index 0000000000..ca50569175
--- /dev/null
+++ b/doc/special_remotes/bup.mdwn
@@ -0,0 +1,40 @@
+This special remote type stores file contents in a 
+[bup](http://github.com/bup/bup) repository. By using git-annex
+in the front-end, and bup as a remote, you get an easy git-style
+interface to large files, and easy backups of the file contents using git.
+
+This is particularly well suited to collaboration on projects involving
+large files, since both the git-annex and bup repositories can be
+accessed like any other git repository.
+
+See [[walkthrough/using_bup]] for usage examples.
+
+Each individual key is stored in a bup remote using `bup split`, with
+a git branch named the same as the key name. Content is retrieved from
+bup using `bup join`. All other bup operations are up to you -- consider
+running `bup fsck --generate` in a cron job to generate recovery blocks,
+for example; or clone bup's git repository to further back it up.
+
+## configuration
+
+These parameters can be passed to `git annex initremote` to configure bup:
+
+* `buprepo` - Required. This is passed to `bup` as the `--remote`
+  to use to store data. To create the repository,`bup init` will be run.
+  Example: "buprepo=example.com:/big/mybup" or "buprepo=/big/mybup"
+  (To use the default `~/.bup` repository on the local host, specify "buprepo=")
+
+* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
+  See [[encryption]]. Note that using encryption will prevent
+  de-duplication of content stored in the buprepo.
+
+* `keyid` - Specifies the gpg key to use for [[encryption]].
+
+Options to pass to `bup split` when sending content to bup can also
+be specified, by using `git config annex.bup-split-options`. This
+can be used to, for example, limit its bandwidth.
+
+## notes
+
+[[git-annex-shell]] does not support bup, due to the wacky way that bup
+starts its server. So, to use bup, you need full shell access to the server.
diff --git a/doc/special_remotes/bup/comment_10_f78c1ed97d2e4c6ebffaa7482cfe0c9b._comment b/doc/special_remotes/bup/comment_10_f78c1ed97d2e4c6ebffaa7482cfe0c9b._comment
new file mode 100644
index 0000000000..97f9b9ea93
--- /dev/null
+++ b/doc/special_remotes/bup/comment_10_f78c1ed97d2e4c6ebffaa7482cfe0c9b._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://sekenre.wordpress.com/"
+ nickname="sekenre"
+ subject="Synchronizing Bup repositories"
+ date="2013-05-07T16:46:34Z"
+ content="""
+Hi All,
+
+I managed to answer my questions above about copying changes between local bup repositories efficiently.
+
+You run the following commands 
+
+    git annex copy . --to bup_repo_1                      # Uses bup split in the background (slow)
+    rsync -av /mnt/repodisk1/repo/ /mnt/repodisk2/repo/ \
+    --exclude=config --exclude=*.bloom --exclude=*.midx   # rsync without bup-specific indices (speed depends on delta between repositories)
+    BUP_DIR=/mnt/repodisk2/repo/ bup midx -a && bup bloom # rebuild bup-specific indices on the target (this is extremely fast)
+    git annex copy . --to bup_repo_2                      # Records file is now available in repo2 (also extremely fast)
+
+Now `git annex whereis` will show the correct location and `git annex get <file> --from bup_repo_2` will work.
+
+So far in my testing I haven't found any problems...
+
+"""]]
diff --git a/doc/special_remotes/bup/comment_11_b53bceb0058acf4d1ab12ea4853ee443._comment b/doc/special_remotes/bup/comment_11_b53bceb0058acf4d1ab12ea4853ee443._comment
new file mode 100644
index 0000000000..c699c62410
--- /dev/null
+++ b/doc/special_remotes/bup/comment_11_b53bceb0058acf4d1ab12ea4853ee443._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnAvbXOnK57sqgvZvxkbG74NUKBDwKDcuk"
+ nickname="Tim"
+ subject="bup location data not synced through annex assistant"
+ date="2013-05-15T15:08:54Z"
+ content="""
+I set up 2 servers running git annex assistant, both with a ~/annex dir and an additional ~/annex-bup bup repo. There is no additional cloud repository.
+For test, I added my /etc dir which uploaded correctly from server1, but which never arrived on server2
+
+    bup@bup1:~/annex/etc$ git annex whereis updatedb.conf
+    whereis updatedb.conf (3 copies) 
+  	    687d3a7f-4798-4dbe-8774-1785b8ab6b7d -- here (bup@bup1:~/annex)
+   	    adfc1307-771f-40e9-b794-bae2e1f21b8b -- bup2-annex-bup
+   	    e4e0ac0b-992a-4312-a4ac-fc8d3d9f7c0f -- bup1-annex-bup
+    ok
+
+    bup@bup2:~/annex/etc$ git annex whereis updatedb.conf
+    whereis updatedb.conf (1 copy) 
+  	    687d3a7f-4798-4dbe-8774-1785b8ab6b7d -- bup1 (bup@bup1:~/annex)
+    ok
+
+As you can see, server 2 just doesn't know the data is already on it's own disk in it's local bup repo.
+Is there a reason this data does not get synced? Should I set up a transfer repo?
+"""]]
diff --git a/doc/special_remotes/bup/comment_12_65d923226cf6120349d807c5c60f640c._comment b/doc/special_remotes/bup/comment_12_65d923226cf6120349d807c5c60f640c._comment
new file mode 100644
index 0000000000..a790daea3a
--- /dev/null
+++ b/doc/special_remotes/bup/comment_12_65d923226cf6120349d807c5c60f640c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnAvbXOnK57sqgvZvxkbG74NUKBDwKDcuk"
+ nickname="Tim"
+ subject="my bad"
+ date="2013-05-15T15:39:31Z"
+ content="""
+Sorry, looks like I did initremote twice on the same folder, instead of enableremote the second time...
+"""]]
diff --git a/doc/special_remotes/bup/comment_12_fca579678edde073716f099c767767e1._comment b/doc/special_remotes/bup/comment_12_fca579678edde073716f099c767767e1._comment
new file mode 100644
index 0000000000..0babee6000
--- /dev/null
+++ b/doc/special_remotes/bup/comment_12_fca579678edde073716f099c767767e1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkEYZEqLf3Aj_FGV7S0FvsMplmGqqb555M"
+ nickname="Sergiusz"
+ subject="bup-join local-arch/2014-12-03-235617 "
+ date="2014-12-04T19:38:07Z"
+ content="""
+How can I restore the previous commit from bup archives created with bup-split? Yes, I know I can use bup-join local-arch~1 git notation, but I would like to use bup-join local-arch/2014-12-03-235617 (bup-ls local-arch results) ...but this method does not work ...
+
+s.
+"""]]
diff --git a/doc/special_remotes/bup/comment_13_ce960bc69b27dfc2a233c9baa5b2cd2b._comment b/doc/special_remotes/bup/comment_13_ce960bc69b27dfc2a233c9baa5b2cd2b._comment
new file mode 100644
index 0000000000..e17e42c38f
--- /dev/null
+++ b/doc/special_remotes/bup/comment_13_ce960bc69b27dfc2a233c9baa5b2cd2b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="darkfeline@e6d098788a13ce41f3141a2dfc1bd31b401e83f0"
+ nickname="darkfeline"
+ subject="buprepo doesn't work properly"
+ date="2015-08-17T12:59:25Z"
+ content="""
+The buprepo parameter doesn't seem to work properly, at least for local repos.  For example, I added a bup remote with buprepo=/media/hdd/bup, yet when I try to move files onto it, it still tries to use /home/foo/.bup (the default path).  I suppose git-annex should be setting the envvar BUP_DIR before calling bup?
+
+I can do it manually like BUP_DIR=/media/hdd/bup git annex move --to hdd foo, but that almost seems to defeat the purpose...
+"""]]
diff --git a/doc/special_remotes/bup/comment_14_940b778f97377e83dc16439c0c7e5b38._comment b/doc/special_remotes/bup/comment_14_940b778f97377e83dc16439c0c7e5b38._comment
new file mode 100644
index 0000000000..7c0d5b9235
--- /dev/null
+++ b/doc/special_remotes/bup/comment_14_940b778f97377e83dc16439c0c7e5b38._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2015-08-19T18:30:16Z"
+ content="""
+@darkfeline, setting buprepo= causes git-annex to run bup with -r. 
+You can verify this by using the --debug switch.
+
+IIRC, bup still creates ~/.bup when used this way, but doesn't store the
+contents of annexed files there. It uses it only to store some small index
+files, which are also stored in the repo specified with -r. This seems
+weird, but I don't think this is a bug on bup's part; it seems to
+intentionally do that, using path names in ~/.bup that are constructed to
+not conflict when -r is used with different repositories.
+I suppose bup has a good reason to do this, though I don't know what the
+reason is.
+
+I can blow ~/.bup away, run "bup init" to make a fresh clean ~/.bup,
+and then git-annex can still get the content of files from the buprepo=
+repository. So, it seems that buprepo= is working ok.
+"""]]
diff --git a/doc/special_remotes/bup/comment_15_c4665d089f2ceb2ed798cf264d490a8c._comment b/doc/special_remotes/bup/comment_15_c4665d089f2ceb2ed798cf264d490a8c._comment
new file mode 100644
index 0000000000..fcd83ea252
--- /dev/null
+++ b/doc/special_remotes/bup/comment_15_c4665d089f2ceb2ed798cf264d490a8c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="barthalion@8758f91921f1def00205716519c57234f128c328"
+ nickname="barthalion"
+ subject="Compression level"
+ date="2016-10-08T18:31:00Z"
+ content="""
+Is it possible to specify compression level to be used for 'bup split'?
+"""]]
diff --git a/doc/special_remotes/bup/comment_16_4787e0373eeec3c7d1d562e47217566c._comment b/doc/special_remotes/bup/comment_16_4787e0373eeec3c7d1d562e47217566c._comment
new file mode 100644
index 0000000000..3a7b1a5fd6
--- /dev/null
+++ b/doc/special_remotes/bup/comment_16_4787e0373eeec3c7d1d562e47217566c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="barthalion@8758f91921f1def00205716519c57234f128c328"
+ nickname="barthalion"
+ subject="comment 16"
+ date="2016-10-11T21:00:53Z"
+ content="""
+Right, this is what happens when you don't even read the article you have commented on.
+"""]]
diff --git a/doc/special_remotes/bup/comment_17_360caa8972c2daa94044cc95188306e9._comment b/doc/special_remotes/bup/comment_17_360caa8972c2daa94044cc95188306e9._comment
new file mode 100644
index 0000000000..83027ed2e9
--- /dev/null
+++ b/doc/special_remotes/bup/comment_17_360caa8972c2daa94044cc95188306e9._comment
@@ -0,0 +1,18 @@
+[[!comment format=sh
+ username="eigood"
+ avatar="http://cdn.libravatar.org/avatar/fa5ae017e5432f6cfbf82109a94afaea"
+ subject="Add support for bup daemon?"
+ date="2019-07-16T23:45:18Z"
+ content="""
+==
+git annex --debug initremote originbup type=bup autoenable=true encryption=none buprepo=bup://localhost:1982/srv/app/fs/global-storage/XXXX/bup
+...
+[2019-07-16 23:24:01.852275553] process done ExitSuccess
+(storing uuid...) [2019-07-16 23:24:01.852581845] call: ssh [\"bup\",\"-S\",\".git/annex/ssh/bup\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-n\",\"-T\",\"cd '//localhost:1982/srv/app/fs/global-storage/XXXX/bup' && git config annex.uuid 11ddfb21-f6ca-4281-a0a1-aef9b17437e0\"]
+...
+==
+
+Annex is attempting to ssh to a machine called \"bup\", then doing a cd to a very wrong path.  To get this far, I had to do a few fixed to client.py in bup, as that code has decayed since 2017.  I haven't yet looked at the annex source, to see why it needs to do that cd, but I would prefer *not* have ssh access for this.
+
+This scenario I have locally is git-annex+bup+duplicity running inside a reduced, isolated, docker-container, where everything is trusted, and I can throw all pieces away.  
+"""]]
diff --git a/doc/special_remotes/bup/comment_1_96179a003da4444f6fc08867872cda0a._comment b/doc/special_remotes/bup/comment_1_96179a003da4444f6fc08867872cda0a._comment
new file mode 100644
index 0000000000..02691c6907
--- /dev/null
+++ b/doc/special_remotes/bup/comment_1_96179a003da4444f6fc08867872cda0a._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkgbXwQtPQSG8igdS7U8l031N8sqDmuyvk"
+ nickname="Albert"
+ subject="Error with bup and gnupg"
+ date="2012-10-22T20:56:56Z"
+ content="""
+Hello,
+
+I get this error when trying to use git-annex with bup and gnupg:
+
+<pre>
+move importable_pilot_surveys.tar (gpg) (checking localaseebup...) (to localaseebup...) 
+Traceback (most recent call last):
+  File \"/usr/lib/bup/cmd/bup-split\", line 133, in <module>
+    progress=prog)
+  File \"/usr/lib/bup/bup/hashsplit.py\", line 167, in split_to_shalist
+    for (sha,size,bits) in sl:
+  File \"/usr/lib/bup/bup/hashsplit.py\", line 118, in _split_to_blobs
+    for (blob, bits) in hashsplit_iter(files, keep_boundaries, progress):
+  File \"/usr/lib/bup/bup/hashsplit.py\", line 86, in _hashsplit_iter
+    bnew = next(fi)
+  File \"/usr/lib/bup/bup/helpers.py\", line 86, in next
+    return it.next()
+  File \"/usr/lib/bup/bup/hashsplit.py\", line 49, in blobiter
+    for filenum,f in enumerate(files):
+  File \"/usr/lib/bup/cmd/bup-split\", line 128, in <genexpr>
+    files = extra and (open(fn) for fn in extra) or [sys.stdin]
+IOError: [Errno 2] No such file or directory: '-'
+</pre>
+
+
+I was able to work-around this issue by altering /usr/lib/bup/cmd/bup-split (though I don't think its a bup bug) to just pull from stdin:
+
+files = [sys.stdin]
+
+on ~ line 128.
+
+Any ideas? Also, do you think that bup's data-deduplication does anything when gnupg is enabled, i.e. is it just as well to use a directory remote with gnupg?
+
+Thanks! Git annex rules!
+
+Albert
+"""]]
diff --git a/doc/special_remotes/bup/comment_2_612b038c15206f9f3c2e23c7104ca627._comment b/doc/special_remotes/bup/comment_2_612b038c15206f9f3c2e23c7104ca627._comment
new file mode 100644
index 0000000000..97af184f3b
--- /dev/null
+++ b/doc/special_remotes/bup/comment_2_612b038c15206f9f3c2e23c7104ca627._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.23"
+ subject="comment 2"
+ date="2012-10-23T20:01:43Z"
+ content="""
+@Albert, thanks for reporting this bug (but put them in [[bugs]] in future please).
+
+This is specific to using the bup special remote with encryption. Without encryption it works. And no, it won't manage to deduplicate anything that's encrypted, as far as I know. 
+
+I think bup-split must have used - for stdin in the past, but now, it just reads from stdin when no file is specified, so I've updated git-annex.
+"""]]
diff --git a/doc/special_remotes/bup/comment_3_1186def82741ddab1ade256fb2e59e6f._comment b/doc/special_remotes/bup/comment_3_1186def82741ddab1ade256fb2e59e6f._comment
new file mode 100644
index 0000000000..2e3e389921
--- /dev/null
+++ b/doc/special_remotes/bup/comment_3_1186def82741ddab1ade256fb2e59e6f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://sekenre.wordpress.com/"
+ nickname="sekenre"
+ subject="Bup remotes in git-annex assistant"
+ date="2013-03-13T12:54:56Z"
+ content="""
+Hi,
+
+Is the bup remote available via the Assistant user interface?
+
+Unrelated question;
+
+If you are syncing files between two bup repos on local usb drives, does it use git to sync the changes or does it use \"bup split\" to re-add the file? (Basically, is the syncing as efficient as possible using git-annex or would I have to go to a lower level)
+
+Many Thanks,
+Sek
+"""]]
diff --git a/doc/special_remotes/bup/comment_4_7d22a805dd2914971e7ca628ceea69be._comment b/doc/special_remotes/bup/comment_4_7d22a805dd2914971e7ca628ceea69be._comment
new file mode 100644
index 0000000000..0607e5f6ce
--- /dev/null
+++ b/doc/special_remotes/bup/comment_4_7d22a805dd2914971e7ca628ceea69be._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-03-13T16:05:50Z"
+ content="""
+I don't plan to support creating bup spefial remotes in the assistant, currently. Of course the assistant can use bup special remotes you set up.
+
+Your two bup repos would be synced using bup-split.
+"""]]
diff --git a/doc/special_remotes/bup/comment_6_5942333cde09fd98e26c4f1d389cb76f._comment b/doc/special_remotes/bup/comment_6_5942333cde09fd98e26c4f1d389cb76f._comment
new file mode 100644
index 0000000000..288f8765d2
--- /dev/null
+++ b/doc/special_remotes/bup/comment_6_5942333cde09fd98e26c4f1d389cb76f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZWCbRYPVnwscdkdEDwgQHZJLwW6H_AHo"
+ nickname="Tobias"
+ subject="bup fail?"
+ date="2013-03-31T21:05:32Z"
+ content="""
+I've run into problems storing a huge number of files in the bup repo. It seems that thousands of branches are a problem. I don't know if it's a problem of git-annex, bup, or the filesystem.
+
+How about adding an option to store tree/commit ids in git-annex instead of using branches in bup?
+"""]]
diff --git a/doc/special_remotes/bup/comment_7_cb1a0d3076e9d06e7a24204478f6fa98._comment b/doc/special_remotes/bup/comment_7_cb1a0d3076e9d06e7a24204478f6fa98._comment
new file mode 100644
index 0000000000..a2284c3e1c
--- /dev/null
+++ b/doc/special_remotes/bup/comment_7_cb1a0d3076e9d06e7a24204478f6fa98._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 7"
+ date="2013-04-02T21:24:06Z"
+ content="""
+`bup-split` uses a git branch to name the objects stored in the bup repository. So it will be limited by any scalability issues affecting large numbers of git branches. I don't know what those are.
+
+Yes, it would be possible to make git-annex store this in the git-annex branch instead.
+"""]]
diff --git a/doc/special_remotes/bup/comment_8_4cbc67e5911748d13cee3c483d7ece8a._comment b/doc/special_remotes/bup/comment_8_4cbc67e5911748d13cee3c483d7ece8a._comment
new file mode 100644
index 0000000000..62376a6e4e
--- /dev/null
+++ b/doc/special_remotes/bup/comment_8_4cbc67e5911748d13cee3c483d7ece8a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlsXhOlsW6RaGR83VNSMxPh159l5dFau70"
+ nickname="Yung-Chin"
+ subject="re scaling issue"
+ date="2013-05-03T14:57:51Z"
+ content="""
+Tobias/joey,
+
+I think there are at least two scaling issues that may be causing you trouble. One is that bup writes pack+idx files rather than bare objects, and if you send 1 file per call to bup-split, you end up with a pair of pack and idx files for each such call. When you later try to retrieve a blob, bup currently just calls git, and git will have to traverse all these tiny idx files looking for the right hash (bare objects you could at least find by name). You can probably ameliorate the pain by calling git repack (look at the -a and --max-pack-size switches) on your bup repository. The other is the \"thousands of branches\" issue, and I think \"git pack-refs --all\" (that's again on your bup repository) might help a little bit. 
+
+It would certainly help performance if you could store blob/tree ids in git-annex instead of branch names. For small files, all bup would need to store is a blob, but currently you end up storing a blob, a tree, and a commit (and looking-up all of those, plus the ref too, on calling bup-join). (you might want to patch bup-split, so it would allow you to ask it for \"--blob-or-tree\", because currently if you say you pass it -b for blob-ids, then for bigger files you get a series of IDs, whereas you'd be much better off with a tree-id there)
+"""]]
diff --git a/doc/special_remotes/bup/comment_9_ca7096a759961af375e6bd49663b45b3._comment b/doc/special_remotes/bup/comment_9_ca7096a759961af375e6bd49663b45b3._comment
new file mode 100644
index 0000000000..d6021f7649
--- /dev/null
+++ b/doc/special_remotes/bup/comment_9_ca7096a759961af375e6bd49663b45b3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlsXhOlsW6RaGR83VNSMxPh159l5dFau70"
+ nickname="Yung-Chin"
+ subject="comment 9"
+ date="2013-05-03T16:34:05Z"
+ content="""
+Thinking about this some more, a very elegant way to make a bup remote could actually be to just pass the whole .git/annex tree into bup-index/save (you could avoid sending some files by only bup-indexing select subtrees, or by using --exclude-*'s, but you'd run bup-save over the whole .git/annex tree). You could then use bup-restore to retrieve files or whole subtrees, and you'd refer to the files you're retrieving by their actual pathname under which they live in .git/annex (if that doesn't make sense it's because I've misunderstood how git-annex is organised!), so something like \"bup restore branch_name/latest/.git/annex/aa/bb/sha-of-some-sort\" would work - that's cute, right? And you'd only have 1 branch.
+
+However... somebody who is good with lazy-evaluation would need to rework bup.vfs: currently, if you'd call bup-restore on a path like that, it would instantiate a _lot_ of vfs-nodes you don't need - to begin with, it would make a node for every commit you ever made (on any branch!) - on a big repository you'd wait ages for it to just find the commit objects...
+"""]]
diff --git a/doc/special_remotes/comment_10_e9881290486a1770bd260f8650ada9c6._comment b/doc/special_remotes/comment_10_e9881290486a1770bd260f8650ada9c6._comment
new file mode 100644
index 0000000000..79cbe37134
--- /dev/null
+++ b/doc/special_remotes/comment_10_e9881290486a1770bd260f8650ada9c6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQqKSVY98PVGDIaYZdK9CodJdbh7cFfhY"
+ nickname="Ashwin"
+ subject="Rackspace Cloud Files support"
+ date="2013-03-22T08:20:40Z"
+ content="""
+It'd be really cool to have Rackspace cloud files support. Like the guy above me said, I would submit a patch but not if I have to learn Haskell first :)
+"""]]
diff --git a/doc/special_remotes/comment_11_e01b5cc5a0d81b071e93e27e7b91fe2a._comment b/doc/special_remotes/comment_11_e01b5cc5a0d81b071e93e27e7b91fe2a._comment
new file mode 100644
index 0000000000..f2f9c4a8f4
--- /dev/null
+++ b/doc/special_remotes/comment_11_e01b5cc5a0d81b071e93e27e7b91fe2a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andy"
+ ip="99.48.75.171"
+ subject="Re: Webhook special remote"
+ date="2013-04-12T08:54:47Z"
+ content="""
+@Alex: You might see if the newly-added [[todo/wishlist: allow configuration of downloader for addurl]] could be made to do what you need... I've not played around with it yet, but perhaps you could set the downloader to be something that can sort out the various URLs and send them to the correct downloading tool?
+"""]]
diff --git a/doc/special_remotes/comment_12_13237170ef5b6646e0e25d3421af3fe5._comment b/doc/special_remotes/comment_12_13237170ef5b6646e0e25d3421af3fe5._comment
new file mode 100644
index 0000000000..5146cca361
--- /dev/null
+++ b/doc/special_remotes/comment_12_13237170ef5b6646e0e25d3421af3fe5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://yarikoptic.myopenid.com/"
+ nickname="site-myopenid"
+ subject="How to establish local preference for (special) remotes"
+ date="2013-05-22T14:06:48Z"
+ content="""
+Sorry if it is RTFM... If I have multiple original (reachable) remotes, how could I establish my preference for which one to be used in any given location?
+
+usecase: if I clone a repository within amazon cloud instance -- I would now prefer if this (or all -- user-wide configuration somehow?) repository 'get's load from URLs originating in the cloud of this zone (e.g. having us-east-1.s3.amazonaws.com/ in their URLs).
+"""]]
diff --git a/doc/special_remotes/comment_13_1a36a0483a9db04d36e0234a192ebad8._comment b/doc/special_remotes/comment_13_1a36a0483a9db04d36e0234a192ebad8._comment
new file mode 100644
index 0000000000..8e5a8015dc
--- /dev/null
+++ b/doc/special_remotes/comment_13_1a36a0483a9db04d36e0234a192ebad8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="Remote costs"
+ date="2013-05-22T14:15:03Z"
+ content="""
+This should be implemented with costs
+
+I refer you too: http://git-annex.branchable.com/design/assistant/blog/day_213__costs/
+
+This has been implemented in the assistant, so if you use that, changing priority should be as simple as changing the order of the remotes on the web interface. Whichever remote is highest on the list, is the one your client will fetch from.
+"""]]
diff --git a/doc/special_remotes/comment_14_a8419963dc024b1d9eb73807596012dc._comment b/doc/special_remotes/comment_14_a8419963dc024b1d9eb73807596012dc._comment
new file mode 100644
index 0000000000..cd0a8eb581
--- /dev/null
+++ b/doc/special_remotes/comment_14_a8419963dc024b1d9eb73807596012dc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 14"
+ date="2013-05-22T14:30:00Z"
+ content="""
+You do not need to use the assistant to configure the costs of remotes. Just set `remote.<name>.annex-cost` to appropriate values. See also the documentation for the `remote.<name>.annex-cost-command` which allows your own code to calculate costs.
+"""]]
diff --git a/doc/special_remotes/comment_15_95ccfdd22a2391daa99e0beb04adedd6._comment b/doc/special_remotes/comment_15_95ccfdd22a2391daa99e0beb04adedd6._comment
new file mode 100644
index 0000000000..3e2ea9948d
--- /dev/null
+++ b/doc/special_remotes/comment_15_95ccfdd22a2391daa99e0beb04adedd6._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://yarikoptic.myopenid.com/"
+ nickname="site-myopenid"
+ subject="remotes costs"
+ date="2013-05-22T18:33:11Z"
+ content="""
+Thank you -- that is nice!
+
+Could costs be presented in 'whereis' and 'status' commands? e.g. like we know APT repositories priorities from  apt-cache policy -- now I do not see them (at least in 4.20130501... updating to sid's 0521 now)
+
+"""]]
diff --git a/doc/special_remotes/comment_16_b9d238fb15ad7628e33c90b071e07bb0._comment b/doc/special_remotes/comment_16_b9d238fb15ad7628e33c90b071e07bb0._comment
new file mode 100644
index 0000000000..8b1fcd831f
--- /dev/null
+++ b/doc/special_remotes/comment_16_b9d238fb15ad7628e33c90b071e07bb0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://yarikoptic.myopenid.com/"
+ nickname="site-myopenid"
+ subject="compression -- storage and transfer"
+ date="2013-05-22T18:48:59Z"
+ content="""
+Is there any remote which would not only compress during transfer (I believe rsync does that, right?) but also store objects compressed?
+
+I thought bup would do both -- but it seems that git annex receives data uncompressed from a bup remote, and bup remote requires ssh access.
+
+In my case I want to make publicly available files which are binary blobs which could be compressed very well.  It would be a pity if I waste storage on my end and also incur significant traffic, which could be avoided if data load was transferred compressed.  May be HTTP compression (http://en.wikipedia.org/wiki/HTTP_compression) could somehow be used efficiently for this purpose (not sure if load then originally could already reside in a compressed form to avoid server time to re-compress it)?
+"""]]
diff --git a/doc/special_remotes/comment_17_cc21b81a8f809f6efa5f5b6332513fc3._comment b/doc/special_remotes/comment_17_cc21b81a8f809f6efa5f5b6332513fc3._comment
new file mode 100644
index 0000000000..f576e27238
--- /dev/null
+++ b/doc/special_remotes/comment_17_cc21b81a8f809f6efa5f5b6332513fc3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://yarikoptic.myopenid.com/"
+ nickname="site-myopenid"
+ subject="Re: compression -- storage and transfer"
+ date="2013-05-22T19:17:33Z"
+ content="""
+ha -- apparently it is trivial to configure apache to serve pre-compressed files (e.g. see http://stackoverflow.com/questions/75482/how-can-i-pre-compress-files-with-mod-deflate-in-apache-2-x) and they arrive compressed to client with
+
+Content-Encoding: gzip
+
+but unfortunately git-annex doesn't like those (fails to \"verify\") -- do you think it could be implemented for web \"special remotes\"? that would be really nice -- then I could store such load on another website, and addurl links to the compressed content
+"""]]
diff --git a/doc/special_remotes/comment_18_3fe750118ff1edbe91a110b86fb5b662._comment b/doc/special_remotes/comment_18_3fe750118ff1edbe91a110b86fb5b662._comment
new file mode 100644
index 0000000000..2345bba210
--- /dev/null
+++ b/doc/special_remotes/comment_18_3fe750118ff1edbe91a110b86fb5b662._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 18"
+ date="2013-05-23T23:25:02Z"
+ content="""
+All special remotes store files compressed when you enable encryption. Not otherwise, though.
+
+As far as the web special remote and pre-compressed files, files are downloaded from the web using `wget` or (of wget is not available) `curl`. So if you can make it work with those commands, it should work.
+"""]]
diff --git a/doc/special_remotes/comment_19_6794eb52bd87c28ef1df3172aa7d5780._comment b/doc/special_remotes/comment_19_6794eb52bd87c28ef1df3172aa7d5780._comment
new file mode 100644
index 0000000000..b8c701ade9
--- /dev/null
+++ b/doc/special_remotes/comment_19_6794eb52bd87c28ef1df3172aa7d5780._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://yarikoptic.myopenid.com/"
+ nickname="site-myopenid"
+ subject="compressed storage/transfer -- gzip Content-Type"
+ date="2013-05-25T06:41:37Z"
+ content="""
+FWIW -- eh -- unfortunately it seems not that transparent.  wget seems to not support decompression at all, curl can do with explicit --compressed, BUT it doesn't distinguish url to a \"natively\" .gz file and pre-compressed content.  And I am not sure if it is possible to anyhow reliably distinguish the two urls.  In the case of obtaining pre-compressed file from my sample apache server the only difference in the http response header is that it gets \"compound\" ETag:
+compare ETag: \"3acb0e-17b38-4dd5343744660\" (for directly asking zeros100.gz) vs \"3acb0e-17b38-4dd5343744660;4dd5344e1537e\" (requesting zeros100) where portion past \";\" I guess signals the caching tag for gzipping, but not exactly sure on that since it seems to be not a part of standard.  Also for zeros100 I am getting \"TCN: choice\"... once again not sure if that is any how reliably indicative for my purpose.  So I guess there is no good way ATM via Content-Type request.
+"""]]
diff --git a/doc/special_remotes/comment_1_961276c18e9353ca8e25cad53e7ec51f._comment b/doc/special_remotes/comment_1_961276c18e9353ca8e25cad53e7ec51f._comment
new file mode 100644
index 0000000000..ec1bea4199
--- /dev/null
+++ b/doc/special_remotes/comment_1_961276c18e9353ca8e25cad53e7ec51f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
+ nickname="Jon Ander"
+ subject="MediaFire"
+ date="2013-01-17T12:17:54Z"
+ content="""
+MediaFire offers 50GB of free storage (max size 200MB). It would be great to support it as a new special remote.
+"""]]
diff --git a/doc/special_remotes/comment_20_6b7242721f2f2c77b634568cb737e3e3._comment b/doc/special_remotes/comment_20_6b7242721f2f2c77b634568cb737e3e3._comment
new file mode 100644
index 0000000000..b17896a683
--- /dev/null
+++ b/doc/special_remotes/comment_20_6b7242721f2f2c77b634568cb737e3e3._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnWvnTWY6LrcPB4BzYEBn5mRTpNhg5EtEg"
+ nickname="Bence"
+ subject="Testing a special remote"
+ date="2013-11-24T08:24:36Z"
+ content="""
+Is there a unit test or integration test to check for the behavior of a special remote implementation and/or validity?
+
+I don't speak Haskell, so maybe there are some in the source but maybe I wouldn't recognize, so I haven't checked. If there are any tests how should I use it?
+
+Thank you,
+Bence
+"""]]
diff --git a/doc/special_remotes/comment_22_308afc586b86c66bbb3437d63864d9cb._comment b/doc/special_remotes/comment_22_308afc586b86c66bbb3437d63864d9cb._comment
new file mode 100644
index 0000000000..c642f3975d
--- /dev/null
+++ b/doc/special_remotes/comment_22_308afc586b86c66bbb3437d63864d9cb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmp1ThsNNAbSn46ju-gwFELfStlhl8usJo"
+ nickname="donkeyicydragon"
+ subject="Enhancing special remotes as backup spaces"
+ date="2014-04-22T21:08:49Z"
+ content="""
+Hi Joey,
+
+I am thinking about using google drive as an encrypted backup for my important files. However, I fear that if all my git annex repositories are unrecoverable that the encrypted data on the special remote will not help me much. Assuming I have backed up my gpg key I still get a bunch of decrypted files but the folder structure is lost. Would it be possible to implement something like a safety feature that also uploads an (encrypted) tar of all symlinks (pointing to the respective encrypted files) of the (current/or master-branch) git working tree? 
+
+I am almost sure this is already implementable using hooks however I could not find information on which types of hooks are available. I am looking for one that is triggered once after all copy/move operations to a special remote are finished. Can you point me in the right direction?
+
+Marek
+
+
+"""]]
diff --git a/doc/special_remotes/comment_23_0f5440e0e54cf7ac2a68b1ba115b0930._comment b/doc/special_remotes/comment_23_0f5440e0e54cf7ac2a68b1ba115b0930._comment
new file mode 100644
index 0000000000..6ec99abc93
--- /dev/null
+++ b/doc/special_remotes/comment_23_0f5440e0e54cf7ac2a68b1ba115b0930._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 23"
+ date="2014-05-16T19:11:00Z"
+ content="""
+@donkeyicydragon one way to accomplish that would be to just tar up `.git` -- excluding `.git/annex/objects` and add that to git-annex like any other file. You could make a git post-commit hook that does that, but that seems overboard.
+
+Or, you could just make a git clone of your repo to a local removable drive, and use that as a local backup.
+"""]]
diff --git a/doc/special_remotes/comment_23_96ef232e13bc2dc102a667a06c856ee7._comment b/doc/special_remotes/comment_23_96ef232e13bc2dc102a667a06c856ee7._comment
new file mode 100644
index 0000000000..46e1472378
--- /dev/null
+++ b/doc/special_remotes/comment_23_96ef232e13bc2dc102a667a06c856ee7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="craig@6ddb6e2c94325e18a0d631a06e63fdc111ab1f12"
+ nickname="craig"
+ subject="Replicating my key for encrypted special remotes"
+ date="2015-10-17T16:29:24Z"
+ content="""
+I'm using git annex assistant to auto backup my pictures off-site to glacier.  The files in glacier are encrypted.  However, if I lose my main machine, I've also lost the encryption key, which makes my off-site backup useless.  I figured I could fix this by creating a manual mode remote on a usb drive that I keep on my keychain.  I figured this would replicate the encryption key (as I might want to pull down files from the full backup glacier remote), but would not replicate the files themselves, as I have more pictures than space on the usb drive.
+
+However, it seems the that the new remote is configured to only talk to my main machine and not glacier; the encryption key is not in the .git/ directory.  How do I ensure that I've got an off-site copy of the glacier encryption key?
+
+Thanks,
+Craig
+"""]]
diff --git a/doc/special_remotes/comment_24_2c9eda62766c9d5000346a092fe5d0d8._comment b/doc/special_remotes/comment_24_2c9eda62766c9d5000346a092fe5d0d8._comment
new file mode 100644
index 0000000000..2d5f5b0b15
--- /dev/null
+++ b/doc/special_remotes/comment_24_2c9eda62766c9d5000346a092fe5d0d8._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 24"""
+ date="2015-10-19T17:32:16Z"
+ content="""
+@craig, all of git-annex's information about a special remote is stored in
+the git-annex branch in git, so any clone of the git repository is
+sufficient to back that up. You can run `git annex enableremote`
+in an clone to enable an existing special remote.
+
+The only catch is that, if you have chosen to initremote a special remote
+using a gpg key, with `keyid=whatever`, you'll of course
+also need that gpg key to to use it. If you run `git annex info $myremote`
+it will tell you amoung other things, any gpg keys that are used by that
+remote.
+"""]]
diff --git a/doc/special_remotes/comment_25_d9f298f284d66fb0aff029eb01f1ce23._comment b/doc/special_remotes/comment_25_d9f298f284d66fb0aff029eb01f1ce23._comment
new file mode 100644
index 0000000000..564208f4c4
--- /dev/null
+++ b/doc/special_remotes/comment_25_d9f298f284d66fb0aff029eb01f1ce23._comment
@@ -0,0 +1,90 @@
+[[!comment format=mdwn
+ username="craig@6ddb6e2c94325e18a0d631a06e63fdc111ab1f12"
+ nickname="craig"
+ subject="Replicating my key for encrypted special remotes"
+ date="2015-10-25T19:00:56Z"
+ content="""
+Cool, thanks.  I see the gpg key in remote.log in the git-annex branch, so it's saved, which is the thing I care about most.  I'm now sure I could recover my data in a DR scenario.  However, I seem to be missing something with enableremote and how this is all supposed to work.
+
+My main repo is ~/local/pics and here's the result of git annex info glacier:
+
+    11:45:24 [24623]; git annex info glacier
+    remote: glacier
+    description: glacier backup [glacier]
+    uuid: e34c5f10-2a97-4477-a248-b96e050557dc
+    trust: semitrusted
+    cost: 1050.0
+    type: glacier
+    creds: stored locally
+    glacier vault: ...snip...
+    encryption: encrypted (encryption key stored in git repository)
+    chunking: none
+    remote annex keys: 27519
+    remote annex size: 47.95 gigabytes
+
+I used git annex assistant to create a manual mode remote on my usb key.  This created a annex-pics directory on the usb key with a bare repo.
+
+    11:50:50 [24626]; pwd
+    /media/craig/KINGSTON/annex-pics
+    11:50:51 [24627]; ls
+    annex  branches  config  description  HEAD  hooks  info  objects  refs
+
+I then did a git clone from the bare repo into a tmp dir:
+
+    11:52:48 [24670]; git clone /media/craig/KINGSTON/annex-pics annex-pics
+    Cloning into 'annex-pics'...
+    done.
+
+But when I enable the glacier remote, which I'd have to do in a DR scenario, I get an error:
+
+    11:53:29 [24672]; git annex enableremote glacier
+    (merging origin/git-annex into git-annex...)
+    (recording state in git...)
+    git-annex: Unknown special remote name.
+    Known special remotes: gitannexpics
+
+It knows about the remote, but hasn't assigned a name to it:
+
+    11:53:36 [24673]; git annex info glacier
+    git-annex: glacier is not a directory or an annexed file or a remote or a uuid
+    11:53:49 [24674]; git annex info
+    repository mode: indirect
+    trusted repositories: 0
+    semitrusted repositories: 7
+            00000000-0000-0000-0000-000000000001 -- web
+            00000000-0000-0000-0000-000000000002 -- bittorrent
+            082b6805-3264-4f1b-8e15-a5cd0cef3e7f -- craig@jester:~/local/pics
+            71132283-1a3b-47f8-a548-1d5fb2f645d4 -- craig@jester:~/tmp/annex-pics [here]
+            a4598ad6-390c-40cf-a71d-edfe7511b20c -- craig@storage:~/local/pics
+            d4ee044d-e0e0-4012-b6cd-353da37b9867 -- KINGSTON [origin]
+            e34c5f10-2a97-4477-a248-b96e050557dc -- glacier backup
+    untrusted repositories: 1
+            3796b34c-61af-4e45-a276-07097c1ac6f9 -- craig@desktop:~/local/pics
+    transfers in progress: none
+    available local disk space: 414.4 gigabytes (+1 megabyte reserved)
+    local annex keys: 0
+    local annex size: 0 bytes
+    annexed files in working tree: 33204
+    size of annexed files in working tree: 48.38 gigabytes (+ 148 unknown size)
+    bloom filter size: 32 mebibytes (0% full)
+    backend usage: 
+            SHA1: 148
+            SHA256E: 33056
+
+Doing a git annex info on the uuid does something, but I'm not clear what it does:
+
+    11:53:56 [24675]; git annex info e34c5f10-2a97-4477-a248-b96e050557dc
+    remote annex keys: 27519
+    remote annex size: 47.95 gigabytes
+
+An enable remote on the uuid doesn't work either:
+
+    11:57:33 [24678]; git annex enableremote e34c5f10-2a97-4477-a248-b96e050557dc
+    git-annex: Unknown special remote name.
+    Known special remotes: gitannexpics
+
+I feel like I'm missing a step.  What am I missing?
+
+Thanks,
+Craig
+"""]]
diff --git a/doc/special_remotes/comment_26_606c1bee71a265f9df3a8cf50fce9a21._comment b/doc/special_remotes/comment_26_606c1bee71a265f9df3a8cf50fce9a21._comment
new file mode 100644
index 0000000000..28a35bd9a7
--- /dev/null
+++ b/doc/special_remotes/comment_26_606c1bee71a265f9df3a8cf50fce9a21._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 26"""
+ date="2015-10-26T17:36:26Z"
+ content="""
+@craig, this can be slightly confusing, since `git-annex enableremote`
+uses the same name that you used when creating the remote in the first
+place, with `git-annex initremote`... which might be different than
+the name used for that remote in some repository or other, and from
+the description shown in `git annex into`.
+
+Since every remote listed by `git annex info` is apparently a regular git
+repo, not a special remote, with the exception of the glacier one, process
+of deduction suggests that the "gitannexpics" special remote is the same as
+the glacier one.
+
+I've made some changes now, so `git annex enableremote` will list the
+uuid and description, along with the name used by enableremote, and
+will accept any one of those things to specify which remote to enable.
+"""]]
diff --git a/doc/special_remotes/comment_27_b37c6ed2444bd7e8b4d7937abdfcbd1c._comment b/doc/special_remotes/comment_27_b37c6ed2444bd7e8b4d7937abdfcbd1c._comment
new file mode 100644
index 0000000000..b6ebf9775a
--- /dev/null
+++ b/doc/special_remotes/comment_27_b37c6ed2444bd7e8b4d7937abdfcbd1c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="alex@7ca398785b94de08e4386b708f32ff9f1af381c7"
+ nickname="alex"
+ subject="backblaze support"
+ date="2015-11-04T19:58:34Z"
+ content="""
+Backblaze B2 with unlimited storage at $.005/GB/mo seems to be a great option for a special remote.
+Is it feasible to add support for it?
+I'd love to contribute financially.
+
+https://www.backblaze.com/b2
+
+"""]]
diff --git a/doc/special_remotes/comment_28_c7ab32e1e63fc114b3b2f56bab62eafa._comment b/doc/special_remotes/comment_28_c7ab32e1e63fc114b3b2f56bab62eafa._comment
new file mode 100644
index 0000000000..fea43697ec
--- /dev/null
+++ b/doc/special_remotes/comment_28_c7ab32e1e63fc114b3b2f56bab62eafa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="craig@6ddb6e2c94325e18a0d631a06e63fdc111ab1f12"
+ nickname="craig"
+ subject="Thanks"
+ date="2015-11-16T05:34:35Z"
+ content="""
+Sorry, didn't post a follow up, but git annex enableremote did exactly what I expected.  Thanks.
+"""]]
diff --git a/doc/special_remotes/comment_29_8393a14f084d022986c8245ee01f4198._comment b/doc/special_remotes/comment_29_8393a14f084d022986c8245ee01f4198._comment
new file mode 100644
index 0000000000..c8a2fd0549
--- /dev/null
+++ b/doc/special_remotes/comment_29_8393a14f084d022986c8245ee01f4198._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="encryptio@2557a3f5b4ef0cddf8f011d7dbb3e76d46ed9c79"
+ nickname="encryptio"
+ subject="git-annex-remote-b2"
+ date="2015-12-04T03:19:29Z"
+ content="""
+I wrote an external remote for [Backblaze's B2](https://www.backblaze.com/b2/cloud-storage.html) object storage service: [git-annex-remote-b2](https://github.com/encryptio/git-annex-remote-b2). I can't be arsed to write a full page on it, but the README covers everything an experienced git-annex user needs to know to use it.
+"""]]
diff --git a/doc/special_remotes/comment_2_97543acfa7434e332ebea5672e446317._comment b/doc/special_remotes/comment_2_97543acfa7434e332ebea5672e446317._comment
new file mode 100644
index 0000000000..840a9d6261
--- /dev/null
+++ b/doc/special_remotes/comment_2_97543acfa7434e332ebea5672e446317._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 2"
+ date="2013-01-17T16:44:25Z"
+ content="""
+Mediafire does not appear to offer any kind of API for its storage.
+"""]]
diff --git a/doc/special_remotes/comment_30_8e5b17431507ee2115b992e5156b749b._comment b/doc/special_remotes/comment_30_8e5b17431507ee2115b992e5156b749b._comment
new file mode 100644
index 0000000000..660dfe1deb
--- /dev/null
+++ b/doc/special_remotes/comment_30_8e5b17431507ee2115b992e5156b749b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="anyone saw/worked on backend for watchdox service? (not free one but needed :-/)"
+ date="2015-12-08T19:45:02Z"
+ content="""
+subject
+"""]]
diff --git a/doc/special_remotes/comment_31_20ac13d009a4f451eb895ca16446ba88._comment b/doc/special_remotes/comment_31_20ac13d009a4f451eb895ca16446ba88._comment
new file mode 100644
index 0000000000..ac18c3ecab
--- /dev/null
+++ b/doc/special_remotes/comment_31_20ac13d009a4f451eb895ca16446ba88._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 31"
+ date="2015-12-09T20:18:48Z"
+ content="""
+How does git-annex handle space issues with special remotes? For example my Owncloud instance has 100 GB space. What happens if I run out of space on that remote? Does git-annex handle that gracefully? Do I have to do something? Can I set a sort of \"quota\"?
+"""]]
diff --git a/doc/special_remotes/comment_32_8dea734fed26e5d9336a2da5bd81eabc._comment b/doc/special_remotes/comment_32_8dea734fed26e5d9336a2da5bd81eabc._comment
new file mode 100644
index 0000000000..c0b3af0c52
--- /dev/null
+++ b/doc/special_remotes/comment_32_8dea734fed26e5d9336a2da5bd81eabc._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 32"""
+ date="2015-12-10T15:15:42Z"
+ content="""
+@openmedi git-annex doesn't currently keep track of how much space it's
+using on a special remote. It's actually quite a difficult problem to do
+that in general, since multiple distributed clones of a repository can be
+uploading to the same special remote at the same time.
+
+If it runs out of space and transfers fail, git-annex will handle the
+failures semi-gracefully, which is to say nothing will stop it from trying
+again or trying to send other data, but it will certianly be aware that
+files are not reaching the special remote.
+
+If a particular storage service has a way to check free space, it would not
+be hard to make git-annex's special remote implementation check it and
+avoid trying transfers when it's full.
+"""]]
diff --git a/doc/special_remotes/comment_33_317c4d5edc9de8159c3b03a3e161e257._comment b/doc/special_remotes/comment_33_317c4d5edc9de8159c3b03a3e161e257._comment
new file mode 100644
index 0000000000..ccf879f297
--- /dev/null
+++ b/doc/special_remotes/comment_33_317c4d5edc9de8159c3b03a3e161e257._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ subject="comment 33"
+ date="2016-05-02T18:41:53Z"
+ content="""
+I'm trying to write a remote (for smb:// support via GNOME's Gvfs), and I can't seem to find a way to change an existing special remote's parameters?
+
+Even when marked as \"dead\" (the closest to deleting a remote that I could find), it still blocks subsequent `annex initremote` calls with the same name.
+
+Also, ideally I'd want to reuse the same name _and_ keep the same UUID (e.g. when the backend is moved/renamed). Though of course there are situations where a new UUID would be wanted as well... (I guess that could depend on whether the remote is currently \"dead\" or not?)
+"""]]
diff --git a/doc/special_remotes/comment_34_31256dd4b74d344aa49902adec4bcf02._comment b/doc/special_remotes/comment_34_31256dd4b74d344aa49902adec4bcf02._comment
new file mode 100644
index 0000000000..f241f3d31d
--- /dev/null
+++ b/doc/special_remotes/comment_34_31256dd4b74d344aa49902adec4bcf02._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ subject="comment 34"
+ date="2016-05-02T18:43:33Z"
+ content="""
+Hmm, I just found that `annex enableremote` accepts parameters to be modified; that should work for now.
+
+Though I still wonder about situations where one wants to add a new empty remote with new UUID, but reuse the old name...
+"""]]
diff --git a/doc/special_remotes/comment_35_5801755d10149f0d3971fef0b6e1b62f._comment b/doc/special_remotes/comment_35_5801755d10149f0d3971fef0b6e1b62f._comment
new file mode 100644
index 0000000000..cdb0a1b16f
--- /dev/null
+++ b/doc/special_remotes/comment_35_5801755d10149f0d3971fef0b6e1b62f._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 35"""
+ date="2016-05-03T17:12:42Z"
+ content="""
+@grawity yes, enableremote is the way to change configuration of an
+existing special remote.
+
+The special remote names are a bit funky; to keep the user from needing to
+enter in a long uuid when enabling a particular special remote, a name
+has to be recorded for the remote, and that becomes shared across clones
+of that repository, in a way that the names of git remotes are not
+normally. (Normally, my "origin" might be your "upstream" etc.) 
+
+While it could ignore dead remotes when initializing a new remote with an
+existing name, then if the old remote got brought back from the dead, there
+would be a naming conflict. So, I think it's best to not go down that path,
+to avoid the undead horrors lurking there. ;-)
+"""]]
diff --git a/doc/special_remotes/comment_36_48859c5ea8f63e37b7531ed0e07f4a54._comment b/doc/special_remotes/comment_36_48859c5ea8f63e37b7531ed0e07f4a54._comment
new file mode 100644
index 0000000000..9faf5706e9
--- /dev/null
+++ b/doc/special_remotes/comment_36_48859c5ea8f63e37b7531ed0e07f4a54._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Dilyin"
+ subject="Special remote's annex cost"
+ date="2016-06-01T18:44:15Z"
+ content="""
+Looks like it's not possible to set the annex cost of the \"web\" and \"bittorrent\" special remotes annex cost.
+
+This doesn't seem to work:
+
+[remote \"web\"]
+  annex-cost = 500
+
+Perhaps, because these remotes don't actually exist.
+
+Setting annex cost for a webdav remote works but is incremented by 50 for some reason.
+
+"""]]
diff --git a/doc/special_remotes/comment_37_9fa2adc324ba25428a681158e58a5300._comment b/doc/special_remotes/comment_37_9fa2adc324ba25428a681158e58a5300._comment
new file mode 100644
index 0000000000..6c6acd250b
--- /dev/null
+++ b/doc/special_remotes/comment_37_9fa2adc324ba25428a681158e58a5300._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 37"""
+ date="2016-11-07T14:58:17Z"
+ content="""
+@bec.watson, better to open a bug report for this kind of problem.
+
+Seems that the [AWS library](http://hackage.haskell.org/package/aws) 
+that git-annex is using does not use V4 authorization yet. Work is in 
+progress: <https://github.com/aristidb/aws/pull/199>
+
+As to the endpoint hostname, that must be a special case for
+China, so I've made git-annex aware of that special case.
+"""]]
diff --git a/doc/special_remotes/comment_38_04366bcb840b7628d13546daf65650dc._comment b/doc/special_remotes/comment_38_04366bcb840b7628d13546daf65650dc._comment
new file mode 100644
index 0000000000..07cdc1b35b
--- /dev/null
+++ b/doc/special_remotes/comment_38_04366bcb840b7628d13546daf65650dc._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="andrew@d9c20810619d89ecb4d8ebe187df122112b82fd9"
+ nickname="andrew"
+ avatar="http://cdn.libravatar.org/avatar/06d3f4f0a82dd00a84f8f8fabc8e537d"
+ subject="Not connect to remote as part of initremote?"
+ date="2018-08-21T23:34:55Z"
+ content="""
+Hey,
+
+I'm setting up some git repos as part of a FAI [0] build, and part of this process is running \"git annex initremote\" to add an rsync remote.
+
+git annex is trying to connect to the remote, but as this an automated build there are no ssh keys available, and warnings etc are spat out. Is it possible to instruct initremote to not connect to the remote as part of this process?
+
+Cheers,
+Andrew
+
+[0] http://fai-project.org
+"""]]
diff --git a/doc/special_remotes/comment_39_990a0e67fdd30680631a90231d07c611._comment b/doc/special_remotes/comment_39_990a0e67fdd30680631a90231d07c611._comment
new file mode 100644
index 0000000000..6906d66b11
--- /dev/null
+++ b/doc/special_remotes/comment_39_990a0e67fdd30680631a90231d07c611._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Not connect to remote as part of initremote?"""
+ date="2018-09-11T17:31:53Z"
+ content="""
+@andrew while it might be possible in theory to set up a rsync special
+remote that's usable without connecting to the rsync server yet, there
+are other types of special remotes that do need to connect to the server.
+S3 comes to mind; it needs to either create a bucket or check if an
+existing bucket is already being used as a git-annex remote.
+
+So, I don't think this can be supported generally
+across all special remote implementations. We could try to support it for
+specific ones like rsync. I don't actually see anywhere in the code for the
+rsync special remote where initremote will connect to the remote server
+though.
+"""]]
diff --git a/doc/special_remotes/comment_3_9229776623c234204c8b164edff95da0._comment b/doc/special_remotes/comment_3_9229776623c234204c8b164edff95da0._comment
new file mode 100644
index 0000000000..84fe385e00
--- /dev/null
+++ b/doc/special_remotes/comment_3_9229776623c234204c8b164edff95da0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
+ nickname="Jon Ander"
+ subject="MediaFire REST API"
+ date="2013-01-17T16:53:41Z"
+ content="""
+Wouldn't this be enough? http://developers.mediafire.com/index.php/REST_API
+"""]]
diff --git a/doc/special_remotes/comment_40_2a36f9c874b00fd5de94836e3dcde782._comment b/doc/special_remotes/comment_40_2a36f9c874b00fd5de94836e3dcde782._comment
new file mode 100644
index 0000000000..9f71e141fc
--- /dev/null
+++ b/doc/special_remotes/comment_40_2a36f9c874b00fd5de94836e3dcde782._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="giuly.ippoliti@c1e2f0d5e40b128900f94f3d107d3719f87c3ff7"
+ nickname="giuly.ippoliti"
+ avatar="http://cdn.libravatar.org/avatar/4444ce1930af68fd817e9649d40e0359"
+ subject="Disable git annex logs"
+ date="2020-02-14T19:39:26Z"
+ content="""
+Hi,
+
+So while writing the globus special remote (git-annex-remote-globus) I often redirect my logs to annex. Nevertheless these logs are always logged out in the console, them being INFO, ERROR, DEBUG and I would like to control that. Is there a way to disable console logging of logs sent back to git annex?
+
+Something like ANNEX_LOG_LEVEL=self.annex.ERROR
+
+Thanks !!
+
+Regards
+Giulia
+"""]]
diff --git a/doc/special_remotes/comment_41_26a29fe6169eee1c62dd10672040851c._comment b/doc/special_remotes/comment_41_26a29fe6169eee1c62dd10672040851c._comment
new file mode 100644
index 0000000000..6d46a8c6ab
--- /dev/null
+++ b/doc/special_remotes/comment_41_26a29fe6169eee1c62dd10672040851c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 41"""
+ date="2020-02-17T16:26:45Z"
+ content="""
+@giuly.ippoliti this is not the best place to ask.. 
+[[design/external_special_remote_protocol]] is a better place to discuss
+special remote implementation.
+
+Anyway, git-annex's --quiet option will shut up the INFO.
+DEBUG is only ever displayed when you use the --debug option.
+ERROR should only be used if you have a problem that the user is going to
+care about seeing.
+"""]]
diff --git a/doc/special_remotes/comment_42_85e354eb058aea02be7b847bceb02313._comment b/doc/special_remotes/comment_42_85e354eb058aea02be7b847bceb02313._comment
new file mode 100644
index 0000000000..a4a30ba026
--- /dev/null
+++ b/doc/special_remotes/comment_42_85e354eb058aea02be7b847bceb02313._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="Avoid fetching from special remotes"
+ date="2020-02-19T00:22:04Z"
+ content="""
+I have a few special remotes configured in my git annex-ed repo. As far as `git` is concerned, these are just ordinary remotes (they have entries in the `.git/config` file). As a result, when I do something like `git fetch --all` it still tries to fetch from them. This of course fails (since they aren't actually git repositories). It isn't the end of the world, but causes some extra noise in my output (I use `magit` in emacs for most of my `git` workflow, so I have to drill down a bit to see what actually failed and then dismiss it as an expected failure).
+
+It'd be nice if I could just prevent `git` from fetching from these special remotes. Is there a clever way I can set `remote.<name>.fetch` in the local config so as to leave these remotes alone when fetching?
+"""]]
diff --git a/doc/special_remotes/comment_43_75a7c567db2b5256182b2cf06091dc12._comment b/doc/special_remotes/comment_43_75a7c567db2b5256182b2cf06091dc12._comment
new file mode 100644
index 0000000000..58ab3aba2a
--- /dev/null
+++ b/doc/special_remotes/comment_43_75a7c567db2b5256182b2cf06091dc12._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Avoid fetching from special remotes"""
+ date="2020-02-19T16:38:44Z"
+ content="""
+@Dan, set remote.name.skipFetchAll to true. Or make a remote group containing
+the remotes you do want to fetch from.
+"""]]
diff --git a/doc/special_remotes/comment_44_bc5871052d29f25eddcc0e02bb2e5a25._comment b/doc/special_remotes/comment_44_bc5871052d29f25eddcc0e02bb2e5a25._comment
new file mode 100644
index 0000000000..bf43dc65a1
--- /dev/null
+++ b/doc/special_remotes/comment_44_bc5871052d29f25eddcc0e02bb2e5a25._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="preventing fetching from special remotes"
+ date="2020-02-19T18:45:06Z"
+ content="""
+\"set remote.name.skipFetchAll to true\" -- is there a reason git-annex itself doesn't do that?
+
+"""]]
diff --git a/doc/special_remotes/comment_45_7553ddfb96499b52ddc300a457972645._comment b/doc/special_remotes/comment_45_7553ddfb96499b52ddc300a457972645._comment
new file mode 100644
index 0000000000..55b5a45219
--- /dev/null
+++ b/doc/special_remotes/comment_45_7553ddfb96499b52ddc300a457972645._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 45"""
+ date="2020-02-19T18:48:46Z"
+ content="""
+I mean, I made it do so already, but since this is not a bug tracking
+system, but an increasingly too long set of disjoint comments, I didn't
+want to follow up here to say that.
+
+Please, if you have some question about special remotes, post it in the
+forum. If you have an improvement, post a todo item. If you have a problem,
+file a bug report. If you're commenting on this page, please think about
+all the subsequent visitors who will see a huge comment thread and how they
+will react.
+"""]]
diff --git a/doc/special_remotes/comment_46_f3f5348ceeffb458bcd7bfaa5c420751._comment b/doc/special_remotes/comment_46_f3f5348ceeffb458bcd7bfaa5c420751._comment
new file mode 100644
index 0000000000..ddb8909586
--- /dev/null
+++ b/doc/special_remotes/comment_46_f3f5348ceeffb458bcd7bfaa5c420751._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="tomdhunt"
+ avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
+ subject="Any way to delete a remote?"
+ date="2021-03-07T01:53:21Z"
+ content="""
+I can't find any way to delete a special remote. I created one that was explicitly temporary (to transfer between some other systems), and now I can't get rid of it. I've already run \"git remote rm\" on it, but it seems git-annex didn't pick this up.
+"""]]
diff --git a/doc/special_remotes/comment_47_780e9ba56a2a83d64583521b8d987e33._comment b/doc/special_remotes/comment_47_780e9ba56a2a83d64583521b8d987e33._comment
new file mode 100644
index 0000000000..3458f3c8b2
--- /dev/null
+++ b/doc/special_remotes/comment_47_780e9ba56a2a83d64583521b8d987e33._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 47"
+ date="2021-03-07T13:38:54Z"
+ content="""
+Try [[`git-annex-dead`|git-annex-dead]] remotename
+"""]]
diff --git a/doc/special_remotes/comment_48_ee5aa6762ca9403c1a2afe1819984fef._comment b/doc/special_remotes/comment_48_ee5aa6762ca9403c1a2afe1819984fef._comment
new file mode 100644
index 0000000000..407caa4873
--- /dev/null
+++ b/doc/special_remotes/comment_48_ee5aa6762ca9403c1a2afe1819984fef._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="tomdhunt"
+ avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
+ subject="comment 48"
+ date="2021-03-08T03:28:45Z"
+ content="""
+I've tried git-annex-dead, it removes the remotes from command outputs but the name is still taken. This isn't great if I want to delete and reconfigure the same remote.
+
+I can always just call it remote2, but that's unaesthetic.
+"""]]
diff --git a/doc/special_remotes/comment_49_044a3d6c35fa1b522f7aeea2cec4199a._comment b/doc/special_remotes/comment_49_044a3d6c35fa1b522f7aeea2cec4199a._comment
new file mode 100644
index 0000000000..99bbc0d305
--- /dev/null
+++ b/doc/special_remotes/comment_49_044a3d6c35fa1b522f7aeea2cec4199a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="Re: &quot;Any way to delete a remote?&quot;"
+ date="2021-03-08T15:13:36Z"
+ content="""
+There is also [[`git-annex-renameremote`|git-annex-renameremote]] .  (And a old [[post|forum/How_to_rename_a_remote?]] on the topic, but that's before `git-annex-renameremote` was added.)
+"""]]
diff --git a/doc/special_remotes/comment_4_3bbda479d13f6bf393dcd59ed94ddeaa._comment b/doc/special_remotes/comment_4_3bbda479d13f6bf393dcd59ed94ddeaa._comment
new file mode 100644
index 0000000000..c5979f8194
--- /dev/null
+++ b/doc/special_remotes/comment_4_3bbda479d13f6bf393dcd59ed94ddeaa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmRFKwny4rArBaz-36xTcsJYqKIgdDaw5Q"
+ nickname="Andrew"
+ subject="JABOF special remote"
+ date="2013-01-19T08:34:32Z"
+ content="""
+Similar to a JABOD, this would be Just A Bunch Of Files. I already have a NAS with a file structure conducive to serving media to my TV. However, it's not capable (currently) of running git-annex locally. It would be great to be able to tell annex the path to a file there as a remote much like a web remote from \"git annex addurl\". That way I can safely drop all the files I took with me on my trip, while annex still verifies and counts the file on the NAS as a location.
+
+There are some interesting things to figure out for this to be efficient. For example, SHAs of the files. Maybe store that in a metadata file in the directory of the files? Or perhaps use the WORM backend by default?
+"""]]
diff --git a/doc/special_remotes/comment_50_4485e72f90f46beef3f216ffab82386e._comment b/doc/special_remotes/comment_50_4485e72f90f46beef3f216ffab82386e._comment
new file mode 100644
index 0000000000..9c391224d5
--- /dev/null
+++ b/doc/special_remotes/comment_50_4485e72f90f46beef3f216ffab82386e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 50"""
+ date="2021-03-08T16:46:57Z"
+ content="""
+It would be possible for initremote to allow reusing a name that is used
+for an old remote that has been marked as dead. The reason that is not
+allowed, I think, is that there is some footgun potential: If the old
+remote somehow was lost and then was found, it would either be hard to unmark
+it as dead, or if that was done, there would be 2 remotes with the same
+name, which would complicate using enableremote.
+
+So it seems best to rename the old one before creating the new one.
+That way it's got a unique name still.
+"""]]
diff --git a/doc/special_remotes/comment_51_1a8a217dc31b0a36dfa9975f72d40b3a._comment b/doc/special_remotes/comment_51_1a8a217dc31b0a36dfa9975f72d40b3a._comment
new file mode 100644
index 0000000000..59bb3cf8d3
--- /dev/null
+++ b/doc/special_remotes/comment_51_1a8a217dc31b0a36dfa9975f72d40b3a._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="gaknuyardi@f7280525ccd44eafd8d1485ec087f27532efd2e9"
+ nickname="gaknuyardi"
+ avatar="http://cdn.libravatar.org/avatar/2cfaf95a0836c7a00ef3efb16c3315ae"
+ subject="Understanding encrypted special remote folder structure"
+ date="2023-03-22T19:26:55Z"
+ content="""
+@joey While inspecting my special remote (rsync, encryption=hybrid) I noticed that a couple files ended up in the same folder tree, is that normal or is something wrong? Obfuscated tree output below.
+
+```
+├── [   0]  xxx
+│   └── [   0]  yyy
+│       ├── [   0]  GPGHMACSHA512--1234
+│       │   └── [29M]  GPGHMACSHA512--1234
+│       └── [   0]  GPGHMACSHA512--5678
+│           └── [ 2G]  GPGHMACSHA512--5678
+```
+"""]]
diff --git a/doc/special_remotes/comment_52_02172d2b81de8c5e212e5ed093a01aa1._comment b/doc/special_remotes/comment_52_02172d2b81de8c5e212e5ed093a01aa1._comment
new file mode 100644
index 0000000000..f15bf43f34
--- /dev/null
+++ b/doc/special_remotes/comment_52_02172d2b81de8c5e212e5ed093a01aa1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 52"""
+ date="2023-03-23T19:23:29Z"
+ content="""
+@gaknuyardi that is expected, they are hash directories. You can see the
+same effect in .git/annex/object/ hash directories when there are enough
+objects.
+"""]]
diff --git a/doc/special_remotes/comment_5_f7000975d38077828ab11a99095b39eb._comment b/doc/special_remotes/comment_5_f7000975d38077828ab11a99095b39eb._comment
new file mode 100644
index 0000000000..1a9eb390a0
--- /dev/null
+++ b/doc/special_remotes/comment_5_f7000975d38077828ab11a99095b39eb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.194"
+ subject="comment 5"
+ date="2013-01-19T16:05:13Z"
+ content="""
+The web special remote is recently able to use file:// URL's, so you can just point to files on some arbitrary storage if you want to.
+"""]]
diff --git a/doc/special_remotes/comment_6_5d2bd7c1e1493d3c3784708a9b0bc001._comment b/doc/special_remotes/comment_6_5d2bd7c1e1493d3c3784708a9b0bc001._comment
new file mode 100644
index 0000000000..0f11973f71
--- /dev/null
+++ b/doc/special_remotes/comment_6_5d2bd7c1e1493d3c3784708a9b0bc001._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlBia1J9-PoXgZYj2LASf7Bs__IqK3T8qQ"
+ nickname="Greg"
+ subject="Rackspace US/UK"
+ date="2013-01-30T11:33:12Z"
+ content="""
+It'd be awesome to be able to use Rackspace as remote storage as an alternative to S3, I would submit a patch, but know 0 Haskell :D
+"""]]
diff --git a/doc/special_remotes/comment_7_af01ee5ce31b1490af565cb087d65277._comment b/doc/special_remotes/comment_7_af01ee5ce31b1490af565cb087d65277._comment
new file mode 100644
index 0000000000..043ad8eb5d
--- /dev/null
+++ b/doc/special_remotes/comment_7_af01ee5ce31b1490af565cb087d65277._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn-UoTjMBsVh6q4HNViGwJi-5FNaCVQB7E"
+ nickname="Nico"
+ subject="Rapidshare"
+ date="2013-02-02T16:49:58Z"
+ content="""
+Would it be possible to support Rapidshare as a new special remote?
+They offer unlimited storage for 6-10€ per month. It would be great for larger backups.
+Their API can be found here: http://images.rapidshare.com/apidoc.txt
+"""]]
diff --git a/doc/special_remotes/comment_8_3d4ffec566d68d601eafe8758a616756._comment b/doc/special_remotes/comment_8_3d4ffec566d68d601eafe8758a616756._comment
new file mode 100644
index 0000000000..85e663296d
--- /dev/null
+++ b/doc/special_remotes/comment_8_3d4ffec566d68d601eafe8758a616756._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlRThEwuPnr8_bcuuCTQ0rQd3w6AfeMiLY"
+ nickname="Alex"
+ subject="'webhook' special remote?"
+ date="2013-02-24T15:05:27Z"
+ content="""
+Is there any chance a special remote that functions like a hybrid of 'web' and 'hook'? At least in theory, it should be relatively simple, since it would only support 'get' and the only meaningful parameters to pass would be the URL and the output file name.
+
+Maybe make it something like git config annex.myprogram-webhook 'myprogram $ANNEX_URL $ANNEX_FILE', and fetching could work by adding a --handler or --type parameter to addurl.
+
+The use case here is anywhere that simple 'fetch the file over HTTP/FTP/etc' isn't workable - maybe it's on rapidshare and you need to use plowshare to download it; maybe it's a youtube video and you want to use youtube-dl, maybe it's a chapter of a manga and you want to turn it into a CBZ file when you fetch it.
+
+"""]]
diff --git a/doc/special_remotes/comment_9_26af468952f0403171370b56e127830a._comment b/doc/special_remotes/comment_9_26af468952f0403171370b56e127830a._comment
new file mode 100644
index 0000000000..88f021c6a9
--- /dev/null
+++ b/doc/special_remotes/comment_9_26af468952f0403171370b56e127830a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlRThEwuPnr8_bcuuCTQ0rQd3w6AfeMiLY"
+ nickname="Alex"
+ subject="comment 9"
+ date="2013-02-24T15:13:16Z"
+ content="""
+A *ridiculously* cool possibility would be to allow them to match against URLs and then handle those (youtube-dl for youtube video URLs, for instance), but that would be additional work on your end and isn't really necessary.
+"""]]
diff --git a/doc/special_remotes/ddar.mdwn b/doc/special_remotes/ddar.mdwn
new file mode 100644
index 0000000000..8de86e2c79
--- /dev/null
+++ b/doc/special_remotes/ddar.mdwn
@@ -0,0 +1,40 @@
+This special remote type stores file contents in a
+[ddar](https://github.com/basak/ddar) repository. This provides easy
+de-duplication when you use git-annex to manage many files that are similar.
+
+Unlike bup, ddar uses its own storage format, which allows for both creation
+and deletion of de-deduplicated files. In addition to using local storage, ddar
+archives can be remote, providing that ddar is installed on the remote machine
+and ssh is available to it.
+
+See [[walkthrough/using_ddar]] for usage examples.
+
+## encryption
+
+Encryption is nominally supported, but is not useful. Since effective
+encryption necessarily obfuscates file contents, similar areas across different
+files are no longer visible to ddar and cannot be de-duplicated.
+
+## compression
+
+The same caveat with encryption also generally applies to compression, since
+file compression changes file contents such that similar regions across files
+no longer appear similar. An exception is `gzip --rsyncable`, which is
+specifically designed to work around this issue. This is the only compression
+mechanism with which de-duplication remains effective.
+
+## configuration
+
+These parameters can be passed to `git annex initremote` to configure ddar:
+
+* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
+  See [[encryption]]. However, note that encryption renders all de-duplication
+ineffective.
+
+* `keyid` - Specifies the gpg key to use for [[encryption]].
+
+* `ddarrepo` - Required. This is passed to `ddar` as the path to the ddar
+  archive to use. If it doesn't exist, the ddar repository will be created
+  automatically when a file is first copied to it. To use a remote ddar
+  repository, use a colon (`:`) to separate the hostname from the remote path.
+  Example: "ddarrepo=example.com:/big/myddar" or "ddarrepo=/big/myddar"
diff --git a/doc/special_remotes/directory.mdwn b/doc/special_remotes/directory.mdwn
new file mode 100644
index 0000000000..b984d1ec5f
--- /dev/null
+++ b/doc/special_remotes/directory.mdwn
@@ -0,0 +1,55 @@
+This special remote type stores file contents in directory.
+
+One use case for this would be if you have a removable drive that
+you want to use to sneakernet files between systems (possibly with
+[[encrypted|encryption]] contents). Just set up both systems to use
+the drive's mountpoint as a directory remote.
+
+With the exporttree=yes parameter, the directory contains a tree of files
+with the same filenames used in a branch of your repository. Without that
+parameter, the directory contains a directory structure similar to
+`.git/annex/objects` or other special remotes like [[rsync]].
+
+Bear in mind that you can also use a regular `git clone` of your git-annex
+repository, rather than a directory remote.
+
+## configuration
+
+These parameters can be passed to `git annex initremote` to configure the
+remote:
+
+* `directory` - The path to the directory where the files should be stored
+  for the remote. The directory must already exist. Typically this will
+  be an empty directory, or a directory already used as a directory remote.
+
+* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
+  See [[encryption]].
+
+* `keyid` - Specifies the gpg key to use for [[encryption]].
+
+* `chunk` - Enables [[chunking]] when storing large files.
+
+* `chunksize` - Deprecated version of chunk parameter above.  
+  Do not use for new remotes. It is not safe to change the chunksize
+  setting of an existing remote.
+
+* `exporttree` - Set to "yes" to make this special remote usable
+  by [[git-annex-export]]. It will not be usable as a general-purpose
+  special remote.
+
+* `importtree` - Set to "yes" to make this special remote usable
+  by [[git-annex-import]]. It will not be usable as a general-purpose
+  special remote.
+
+* `ignoreinodes` - Usually when importing, the inode numbers
+  of files are used to detect when files have changed. Since some
+  filesystems generate new inode numbers each time they are mounted,
+  that can lead to extra work being done. Setting this to "yes" will
+  ignore the inode numbers and so avoid that extra work.
+  This should not be used when the filesystem has stable inode numbers,
+  as it does risk confusing two files that have the same size and mtime.
+
+Setup example:
+
+	# git annex initremote usbdrive type=directory directory=/media/usbdrive/ encryption=none
+	# git annex describe usbdrive "usb drive on /media/usbdrive/"
diff --git a/doc/special_remotes/directory/comment_11_86f8c1b09cbd82bcd76378dfa1b3ca07._comment b/doc/special_remotes/directory/comment_11_86f8c1b09cbd82bcd76378dfa1b3ca07._comment
new file mode 100644
index 0000000000..f29d54b592
--- /dev/null
+++ b/doc/special_remotes/directory/comment_11_86f8c1b09cbd82bcd76378dfa1b3ca07._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="dietz"
+ ip="128.119.40.196"
+ subject="annexing external files"
+ date="2013-07-18T20:57:53Z"
+ content="""
+This is great work. I've developed a serious annex-addiction and now I want to use it everywhere! In particular I was hoping to apply it to this use case:
+
+I have large files/directories (approx 5 TB) on an nfs mount to which is a) write-protected (think \"read-only medium\") and b) used by non-git users. Both reasons prevent me from setting up a git-annex repos there. However, I would like to use git-annex to keep track of the paths and get/drop files from my different computers.
+
+On one of my servers, I set up a git annex repos, hoping to only manage the structure, the locations, and the number of copies. I don't want to have copies of the 5TB files in that repository, as disk space is not unlimited (just for the sake of making them available to my laptop).
+
+I as banking on using a special remote (either directory or rsync) to tell the git-annex repos where the actual data is. 
+
+I am not concerned with data loss, as it is backed up in regular time intervals by our sysadmin.
+
+
+I tried both directory remote and rsync remote but there seems to be a missing piece (I suppose its add). Any ideas?
+
+This is what I did:
+
+
+I added the directory remote and an rsync remote
+
+- $ git annex initremote collections type=directory directory=/my/nfs/dir encryption=none
+- $ git annex initremote rsync type=rsync rsyncurl=ssh://myserver/mnt/nfs/dir encryption=none
+
+the copy command fails without complaints
+ $ git annex copy --from collections
+
+I tried adding virtual files to git annex
+
+- $ git annex add file/inside/dir
+
+but still any kind of get/copy command does not get any new files
+
+
+It would be awesome if I could use git-annex for this, to keep track of my copies and copies of copies. And then I could also keep track of data on my write-protected DVDs.
+
+Is there any chance?
+
+Thanks a lot!
+
+-- Laura
+
+
+
+
+"""]]
diff --git a/doc/special_remotes/directory/comment_12._comment b/doc/special_remotes/directory/comment_12._comment
new file mode 100644
index 0000000000..608fb62cd6
--- /dev/null
+++ b/doc/special_remotes/directory/comment_12._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.25"
+ subject="comment 2"
+ date="2013-07-19T13:54:10Z"
+ content="""
+@Laura the directory special remote requires files to
+be in a particular directory structure with special names
+git-annex comes up with. So you can't use it on an existing
+tree of files like that.
+
+What you can do is use the [[web_special_remote|web]],
+with a `file://` url to point to the files wherever
+they are stored. So for example,
+`git annex addurl file:///media/dvd/file`
+"""]]
diff --git a/doc/special_remotes/directory/comment_12_311cd013fd8db47856d84161119e059d._comment b/doc/special_remotes/directory/comment_12_311cd013fd8db47856d84161119e059d._comment
new file mode 100644
index 0000000000..21ab5aaa92
--- /dev/null
+++ b/doc/special_remotes/directory/comment_12_311cd013fd8db47856d84161119e059d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="dietz"
+ ip="128.119.40.196"
+ subject="comment 12"
+ date="2013-07-20T06:06:31Z"
+ content="""
+Using the web remote is a pretty nice trick!
+ 
+Thanks, Joey - I would not have guessed that.
+
+-- Laura
+"""]]
diff --git a/doc/special_remotes/directory/comment_13_019660abe79fb1a3e6dbeb9a87a4c546._comment b/doc/special_remotes/directory/comment_13_019660abe79fb1a3e6dbeb9a87a4c546._comment
new file mode 100644
index 0000000000..b8d3d77e9f
--- /dev/null
+++ b/doc/special_remotes/directory/comment_13_019660abe79fb1a3e6dbeb9a87a4c546._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="dmitry.olyenyov@6d65bb07071e5517960a647c097dd453b91773dd"
+ nickname="dmitry.olyenyov"
+ subject="Limit max size of remote"
+ date="2015-06-17T11:24:54Z"
+ content="""
+Is there any way to limit size of directory remote except of mounting it from loop device?
+"""]]
diff --git a/doc/special_remotes/directory/comment_14_80d962f856de7510a437437fc0ca75e1._comment b/doc/special_remotes/directory/comment_14_80d962f856de7510a437437fc0ca75e1._comment
new file mode 100644
index 0000000000..2b7acd038d
--- /dev/null
+++ b/doc/special_remotes/directory/comment_14_80d962f856de7510a437437fc0ca75e1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2015-07-06T19:00:43Z"
+ content="""
+@dmitry, it just so happens that directory special remotes honor the
+annex.diskreserve configuration setting. This normally only applies to
+the local git repository, and not to remotes, but since directory
+special remotes are local annex.diskreserve is also checked for them.
+
+There's no currently a way to have a different diskreserve setting for
+a directory special remote than is used for the local git repository.
+"""]]
diff --git a/doc/special_remotes/directory/comment_15_3d091c87c1e4d1c086fb88ae21137a57._comment b/doc/special_remotes/directory/comment_15_3d091c87c1e4d1c086fb88ae21137a57._comment
new file mode 100644
index 0000000000..7e4a08299d
--- /dev/null
+++ b/doc/special_remotes/directory/comment_15_3d091c87c1e4d1c086fb88ae21137a57._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="aslkdjasd@656d48eb766881455ee14c8cd4adabdd14aad892"
+ nickname="aslkdjasd"
+ subject="layout reasoning"
+ date="2016-05-14T01:23:42Z"
+ content="""
+@joeyh - trying to understand the purpose behind the layout for the directory and rsync remotes
+
+Format appears to be /BASE_DIR/xxx/yyy/FILEKEY/FILEKEY
+
+What's the purpose of the filekey directory? I.e. why have FILEKEY as both a directory and then a file of the same name inside that directory?
+"""]]
diff --git a/doc/special_remotes/directory/comment_16_32f6695042fe1f6e40a64a785fab59b9._comment b/doc/special_remotes/directory/comment_16_32f6695042fe1f6e40a64a785fab59b9._comment
new file mode 100644
index 0000000000..0df6a87577
--- /dev/null
+++ b/doc/special_remotes/directory/comment_16_32f6695042fe1f6e40a64a785fab59b9._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2016-05-16T21:31:43Z"
+ content="""
+@aslkdjasd this layout is the same as used for .git/annex/objects
+in the local repository. 
+
+This allows the FILEKEY directory to have its write bit removed.
+This prevents an accidental rm -rf from losing the contents of 
+annexed files. Since that might be the only copy of a file,
+git-annex adds this extra protection.
+"""]]
diff --git a/doc/special_remotes/directory/comment_17_01559b914ed43c4468e0980f3f794ea7._comment b/doc/special_remotes/directory/comment_17_01559b914ed43c4468e0980f3f794ea7._comment
new file mode 100644
index 0000000000..bb6a89082a
--- /dev/null
+++ b/doc/special_remotes/directory/comment_17_01559b914ed43c4468e0980f3f794ea7._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="uwe.nagler@9f80ad68e498fcdb09e20b17ff4539f94ef73ea9"
+ nickname="uwe.nagler"
+ subject="subdirectories above FILEKEY directory"
+ date="2016-05-31T11:51:56Z"
+ content="""
+Format appears to be /BASE_DIR/xxx/yyy/FILEKEY/FILEKEY
+
+How can I get the xxx/yyy or the complete storage path of an annexed file in a fast way?
+
+Background:<br>
+I have to \"chmod\" the xxx/yyy within an '.git/hooks/pre-commit' action (shared used NFS location).<br>
+Following way using 'find' needs too much time in case of a big remote:
+
+    $ git annex info --fast inputbinaries | grep 'directory:' | awk '{print $2}'
+    /gitworkspace/inputbinaries/DWDM1830-all_playground
+
+    $ git annex info vendor-libs/x86/libsnmpdm.a | grep 'key:' | awk '{print $2}'
+    SHA256E-s3992448--82604383354b28f8efcdf8d83bb63607a8d5967551ded055e782ac342bb7f8e0.a
+
+    $ find /gitworkspace/inputbinaries/DWDM1830-all_playground -type f -name SHA256E-s3992448--82604383354b28f8efcdf8d83bb63607a8d5967551ded055e782ac342bb7f8e0.a
+    /gitworkspace/inputbinaries/DWDM1830-all_playground/28e/785/SHA256E-s3992448--82604383354b28f8efcdf8d83bb63607a8d5967551ded055e782ac342bb7f8e0.a/SHA256E-s3992448--82604383354b28f8efcdf8d83bb63607a8d5967551ded055e782ac342bb7f8e0.a
+"""]]
diff --git a/doc/special_remotes/directory/comment_18_1b24ac6abc99e2e4bc8c9f4687c81395._comment b/doc/special_remotes/directory/comment_18_1b24ac6abc99e2e4bc8c9f4687c81395._comment
new file mode 100644
index 0000000000..71ad7f10c3
--- /dev/null
+++ b/doc/special_remotes/directory/comment_18_1b24ac6abc99e2e4bc8c9f4687c81395._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 18"""
+ date="2016-05-31T16:18:45Z"
+ content="""
+The hash directories for a key can be looked up by passing the key to
+`git annex examinekey --format '${hashdirlower}\n'`
+"""]]
diff --git a/doc/special_remotes/directory/comment_19_0a6ae6ba0d2835da21fa62b2b376bf3f._comment b/doc/special_remotes/directory/comment_19_0a6ae6ba0d2835da21fa62b2b376bf3f._comment
new file mode 100644
index 0000000000..f4f56a0336
--- /dev/null
+++ b/doc/special_remotes/directory/comment_19_0a6ae6ba0d2835da21fa62b2b376bf3f._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="Rob"
+ avatar="http://cdn.libravatar.org/avatar/1d12b1e7e4d6ef1dd57cd9f3ec848dc7"
+ subject="creating directory special remote &quot;in-place&quot;"
+ date="2021-08-05T18:13:35Z"
+ content="""
+I'm using git-annex for backing up a variety of data, with several different remotes (including a USB drive for backup, rsync for encrypted cloud backup, etc).  I have one particular use case that I am trying to figure out how to implement:
+
+Pictures, Music, and Video are stored on a WD MyCloud under three corresponding folders.  They are accessible via NFS, as well as via AFP; I specifically mount them on my laptop via NFS.  I want to be able to access the files in the following ways:
+
+- Store new photos from other sources, including my laptop, using git-annex.
+- Have available the list of files on my laptop repository, in git-annex... i.e. like any repository.
+- Retain all the file contents on the WD MyCloud... i.e. like a special remote.
+- ONLY pull file contents to the laptop (or other repositories) if specifically requested (i.e. I don't want a sync to cause things to get pulled to the laptop).
+- When photos are pulled from the special remote, they go into ~/annex/photos (i.e. a different name than the folder on the remote).
+- I want to be able to access the files on the WD MyCloud \"normally\" from other computers, TVs, etc.  I realize there's some 'danger' here.  But I wanted to keep normal file trees for the special remote, not the hash-based filenames with symlinks.
+
+So what I decided I needed was a directory special remote, with both the exporttree and importtree options.  So I created the special remote using something like:
+
+    git annex initremote wdmycloud-pics directory=/net/wdmycloud/nfs/Public/Shared\ Pictures encryption=none exportree=yes importtree=yes
+
+On my laptop's repository, I executed the following:
+
+    git annex import master:photos --from wdmycloud-pics
+    git merge wdmycloud-pics/master
+
+Problem:
+- This imports the content from the special remote, into the laptop's repository.  I don't want that.
+
+I do realize that my main git-annex repository on the laptop probably has to actually download all of the files in order to compute their hashes.  However, I do not want them to stay on the laptop, as there is nowhere's near enough space for all of them.  I did try:
+
+    git-annex wanted wdmycloud-pics \"exclude=photos/*\"
+
+However, this results in none of the files on the WD MyCloud actually getting processed.
+
+What am I missing?
+
+Thanks!
+-Rob
+
+"""]]
diff --git a/doc/special_remotes/directory/comment_1_e8a53592adb13f7d7f212a2eb5a18a31._comment b/doc/special_remotes/directory/comment_1_e8a53592adb13f7d7f212a2eb5a18a31._comment
new file mode 100644
index 0000000000..b2a041c539
--- /dev/null
+++ b/doc/special_remotes/directory/comment_1_e8a53592adb13f7d7f212a2eb5a18a31._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlc1og3PqIGudOMkFNrCCNg66vB7s-jLpc"
+ nickname="Paul"
+ subject="how is this different than rsync?"
+ date="2012-06-22T22:10:19Z"
+ content="""
+Thanks for this great tool! I was wondering what the differences are between using `type=directory`, `type=rsync`, or a bare git repo for directories? 
+
+I guess I can't use just a regular repo because my USB drive is formatted as `vfat` -- which threw me for a loop the first time I heard about `git-annex` about a year ago, because I followed the walkthrough, and it didn't work as expected and gave up (now I know it was just a case of PEBKAC). It might be worth adding a note about [vfat](http://git-annex.branchable.com/bugs/fat_support/) to the \"Adding a remote\" section of the [walkthrough](http://git-annex.branchable.com/walkthrough/), since the unstated assumption there is that the USB drive is formatted as a filesystem that supports symlinks.
+
+Thanks again, my scientific data management just got a lot more sane!
+"""]]
diff --git a/doc/special_remotes/directory/comment_20_981eeeaee76f89a59e2dcbb368c14387._comment b/doc/special_remotes/directory/comment_20_981eeeaee76f89a59e2dcbb368c14387._comment
new file mode 100644
index 0000000000..db2bec22c9
--- /dev/null
+++ b/doc/special_remotes/directory/comment_20_981eeeaee76f89a59e2dcbb368c14387._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 20"
+ date="2021-08-06T06:02:38Z"
+ content="""
+Note that `git-annex-import` has a `--no-content` switch.
+"""]]
diff --git a/doc/special_remotes/directory/comment_21_4df82f23228dd2f95353f774d9bd8173._comment b/doc/special_remotes/directory/comment_21_4df82f23228dd2f95353f774d9bd8173._comment
new file mode 100644
index 0000000000..e8cd60f0ee
--- /dev/null
+++ b/doc/special_remotes/directory/comment_21_4df82f23228dd2f95353f774d9bd8173._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="dud225@35a1ee469f82f3a7eb1f2dce4ad453f5e47bdfd3"
+ nickname="dud225"
+ avatar="http://cdn.libravatar.org/avatar/5147563e50c475918474594d93be95c2"
+ subject="File visibility"
+ date="2023-04-25T05:09:49Z"
+ content="""
+This page warns against the use of the directory special remote if the user expects to be able to access his files:
+> Note that directory remotes have a special directory structure (by design, the same as the rsync remote). If you just want two copies of your repository with the files \"visible\" in the tree in both, the directory special remote is not what you want. 
+
+By setting the options `importtree` and `exporttree` it seems that the user can have the aforementioned behaviour right?
+"""]]
diff --git a/doc/special_remotes/directory/comment_22_2be4b4e74a41723b72ef92a28f81a4dd._comment b/doc/special_remotes/directory/comment_22_2be4b4e74a41723b72ef92a28f81a4dd._comment
new file mode 100644
index 0000000000..62e74f8a6d
--- /dev/null
+++ b/doc/special_remotes/directory/comment_22_2be4b4e74a41723b72ef92a28f81a4dd._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: File visibility"""
+ date="2023-04-25T16:14:50Z"
+ content="""
+Yes, that warning predated the exporttree feature. I've updated the docs.
+"""]]
diff --git a/doc/special_remotes/directory/comment_2_d949edad6a330079f9e15f703f9091e3._comment b/doc/special_remotes/directory/comment_2_d949edad6a330079f9e15f703f9091e3._comment
new file mode 100644
index 0000000000..77b4c4d220
--- /dev/null
+++ b/doc/special_remotes/directory/comment_2_d949edad6a330079f9e15f703f9091e3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.2.25"
+ subject="comment 2"
+ date="2012-06-25T15:29:29Z"
+ content="""
+The directory and rsync special remotes intentionally use the same layout. So the same directory could be set up as both types of special remotes.
+
+The main reason to use this rather than a bare git repo is that it supports encryption.
+"""]]
diff --git a/doc/special_remotes/directory/comment_3_49009f4e9e335c9a9d0422aa59c9a432._comment b/doc/special_remotes/directory/comment_3_49009f4e9e335c9a9d0422aa59c9a432._comment
new file mode 100644
index 0000000000..b8ec510493
--- /dev/null
+++ b/doc/special_remotes/directory/comment_3_49009f4e9e335c9a9d0422aa59c9a432._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://dzsino.myopenid.com/"
+ nickname="dzsino"
+ subject="dropping a directory remote?"
+ date="2013-01-15T22:29:15Z"
+ content="""
+How do I drop a directory remote after initremote? Say I want to start over and enable chunking (not supposed to be enabled on an existing directory), can I simply git remote rm it?
+"""]]
diff --git a/doc/special_remotes/directory/comment_4_f5e9b0b477c4e521f8633fd274757fa3._comment b/doc/special_remotes/directory/comment_4_f5e9b0b477c4e521f8633fd274757fa3._comment
new file mode 100644
index 0000000000..53fc857a38
--- /dev/null
+++ b/doc/special_remotes/directory/comment_4_f5e9b0b477c4e521f8633fd274757fa3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 4"
+ date="2013-01-17T18:22:26Z"
+ content="""
+The best way to remove a special remote is to first `git annex move --from $remote` to get all the content out of it, then `git annex dead $remote` and finally you can `git remote rm $remote`
+"""]]
diff --git a/doc/special_remotes/directory/comment_5_e790718423c41f5ea8047ea5225bfacd._comment b/doc/special_remotes/directory/comment_5_e790718423c41f5ea8047ea5225bfacd._comment
new file mode 100644
index 0000000000..dae22fc8f1
--- /dev/null
+++ b/doc/special_remotes/directory/comment_5_e790718423c41f5ea8047ea5225bfacd._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3HGoDpnOPob5jOjvIootmkve1-nCpRiI"
+ nickname="Kalle"
+ subject="Directory remote with files accessible from non git-annex system?"
+ date="2013-01-20T15:44:16Z"
+ content="""
+
+
+
+
+"""]]
diff --git a/doc/special_remotes/directory/comment_6_325aac80b86588912c4fd61339ccbd0b._comment b/doc/special_remotes/directory/comment_6_325aac80b86588912c4fd61339ccbd0b._comment
new file mode 100644
index 0000000000..7b9d216055
--- /dev/null
+++ b/doc/special_remotes/directory/comment_6_325aac80b86588912c4fd61339ccbd0b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://nicolas-schodet.myopenid.com/"
+ ip="2a01:e35:8ae6:f130:1e4b:d6ff:fe78:1ddb"
+ subject="comment 6"
+ date="2013-06-26T17:52:12Z"
+ content="""
+I tried the suggestion on comment 4, but when I add again a remote with the same path, it gets the same repository identifier and is considered dead. Is that expected?
+
+My use case: I use a usb drive to transfer some large files from one git annex to another, then I use the usb drive for something else and the special remote is removed.  Later I want to use the same usb drive again, but when I create the repository, it starts in the dead state.
+"""]]
diff --git a/doc/special_remotes/directory/comment_7_4206db69d68d9917623ce02500387021._comment b/doc/special_remotes/directory/comment_7_4206db69d68d9917623ce02500387021._comment
new file mode 100644
index 0000000000..b1a3b953ee
--- /dev/null
+++ b/doc/special_remotes/directory/comment_7_4206db69d68d9917623ce02500387021._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.193"
+ subject="comment 7"
+ date="2013-06-26T18:30:39Z"
+ content="""
+@nicolas, I suspect you are using `git annex initremote` with the same name that you used for the now dead-and-buried remote. That causes it to be reanimated, which is not what you want.
+
+Since git-annex version 4.20130501, `git annex initremote` is reserved for creating new remotes, not enabling old ones, so it will refuse to do this. That's to avoid exactly this confusion.
+
+Using `git annex initremote` with a different remote name, and the same directory should work just fine.
+"""]]
diff --git a/doc/special_remotes/directory/comment_8_acd9023511fe43817718bc89430f96c3._comment b/doc/special_remotes/directory/comment_8_acd9023511fe43817718bc89430f96c3._comment
new file mode 100644
index 0000000000..29801fa36c
--- /dev/null
+++ b/doc/special_remotes/directory/comment_8_acd9023511fe43817718bc89430f96c3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmRFKwny4rArBaz-36xTcsJYqKIgdDaw5Q"
+ nickname="Andrew"
+ subject="comment 8"
+ date="2013-06-26T18:46:40Z"
+ content="""
+For the use case you're describing, it might be better to define the usb key as a remote set to \"manual.\" Then, you can copy over the things you want with git annex copy --to=usbkey and when you're done drop everything with git annex drop --from=usbkey and never destroy the remote.
+"""]]
diff --git a/doc/special_remotes/directory/comment_9_d330eb808a990bb71034613c297a265e._comment b/doc/special_remotes/directory/comment_9_d330eb808a990bb71034613c297a265e._comment
new file mode 100644
index 0000000000..47ac7541d8
--- /dev/null
+++ b/doc/special_remotes/directory/comment_9_d330eb808a990bb71034613c297a265e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://nicolas-schodet.myopenid.com/"
+ ip="2a01:e35:8ae6:f130:1e4b:d6ff:fe78:1ddb"
+ subject="comment 9"
+ date="2013-06-26T20:05:20Z"
+ content="""
+Thanks for your answers. You're right, the simplest solution for me is to never remove the remote. If my directory is lost, I realized that I can simply create an empty directory.
+"""]]
diff --git a/doc/special_remotes/external.mdwn b/doc/special_remotes/external.mdwn
new file mode 100644
index 0000000000..aa61273570
--- /dev/null
+++ b/doc/special_remotes/external.mdwn
@@ -0,0 +1,39 @@
+There are three ways to implement a new special remote:
+
+1. Using the [[hook]] special remote to tell git-annex what commands
+   to run to store and retrieve data. This is the easiest way, and
+   is great for prototyping.
+2. Writing it in Haskell and adding it to git-annex.
+3. Writing a program in any language you like that speaks the
+   [[design/external_special_remote_protocol]].
+
+The rest of this page concentrates on writing new external special remotes.
+It's not hard!
+
+* All you need is to make a program with a name like `git-annex-remote-$bar`.
+* Install it in PATH.
+* When the user runs `git annex initremote foo type=external externaltype=$bar`,
+  it will use your program.
+* See [[design/external_special_remote_protocol]] for what the program
+  needs to do. There's an example at the end of this page.
+* If things don't seem to work, pass `--debug` and you'll see, amoung other
+  things, a transcript of git-annex's communication with your program.
+* If you build a new special remote, please add it to the list
+  of [[special_remotes]].
+
+## libraries
+
+For Python, there is a [library by Lykos153](https://github.com/Lykos153/AnnexRemote)
+and a [library by xloem](https://github.com/xloem/gitlakepy)
+that take care of all the protocol details.
+
+## examples
+
+Here's an example of using an external special remote to add torrent
+support to git-annex: [[external/git-annex-remote-torrent]]
+
+Here's a simple shell script example, which can easily be adapted
+to run whatever commands you need. Or better, re-written in some better
+language of your choice.
+
+[[!inline pages="special_remotes/external/example.sh" feeds=no]]
diff --git a/doc/special_remotes/external/example.sh b/doc/special_remotes/external/example.sh
new file mode 100755
index 0000000000..413065d1e0
--- /dev/null
+++ b/doc/special_remotes/external/example.sh
@@ -0,0 +1,309 @@
+#!/bin/sh
+# git-annex external special remote program
+# 
+# This is basically the same as git-annex's built-in directory special remote.
+# 
+# Install in PATH as git-annex-remote-directory
+#
+# Copyright 2013 Joey Hess; licenced under the GNU GPL version 3 or higher.
+
+set -e
+
+# This program speaks a line-based protocol on stdin and stdout.
+# When running any commands, their stdout should be redirected to stderr
+# (or /dev/null) to avoid messing up the protocol.
+runcmd () {
+	"$@" >&2
+}
+
+# Gets a value from the remote's configuration, and stores it in RET
+getconfig () {
+	ask GETCONFIG "$1"
+}
+
+# Stores a value in the remote's configuration.
+setconfig () {
+	echo SETCONFIG "$1" "$2"
+}
+
+# Sets LOC to the location to use to store a key.
+calclocation () {
+	ask DIRHASH "$1"
+	LOC="$mydirectory/$RET/$1"
+}
+
+# Asks for some value, and stores it in RET
+ask () {
+	echo "$1" "$2"
+	read resp
+	# Tricky POSIX shell code to split first word of the resp,
+	# preserving all other whitespace
+	case "${resp%% *}" in
+		VALUE)
+			RET="$(echo "$resp" | sed 's/^VALUE \?//')"
+		;;
+		*)
+			RET=""
+		;;
+	esac
+}
+
+# This remote doesn't need credentials to access it,
+# but many of them will. Here's how to handle requiring the user
+# set MYPASSWORD and MYLOGIN when running initremote. The creds
+# will be stored securely for later use, so the user only needs
+# to provide them once.
+setupcreds () {
+	if [ -z "$MYPASSWORD" ] || [ -z "$MYLOGIN" ]; then
+		echo INITREMOTE-FAILURE "You need to set MYPASSWORD and MYLOGIN environment variables when running initremote."
+	else
+		echo SETCREDS mycreds "$MYLOGIN" "$MYPASSWORD"	
+		echo INITREMOTE-SUCCESS
+	fi
+}
+
+getcreds () {
+	echo GETCREDS mycreds
+	read resp
+	case "${resp%% *}" in
+		CREDS)
+			MYLOGIN="$(echo "$resp" | sed 's/^CREDS \([^ ]*\) .*/\1/')"
+			MYPASSWORD="$(echo "$resp" | sed 's/^CREDS [^ ]* //')"
+		;;
+	esac
+
+}
+
+dostore () {
+	local key="$1"
+	local file="$2"
+	local loc="$3"
+	mkdir -p "$(dirname "$loc")"
+	# Store in temp file first, so that CHECKPRESENT does not see it
+	# until it is all stored.
+	mkdir -p "$mydirectory/tmp"
+	tmp="$mydirectory/tmp/$key"
+	# XXX when at all possible, send PROGRESS while transferring
+	# the file.
+	rm -f "$tmp"
+	if runcmd cp "$file" "$tmp" \
+	   && runcmd mv -f "$tmp" "$loc"; then
+		echo TRANSFER-SUCCESS STORE "$key"
+	else
+		echo TRANSFER-FAILURE STORE "$key"
+	fi
+	rmdir "$mydirectory/tmp"
+}
+
+doretrieve () {
+	local key="$1"
+	local file="$2"
+	local loc="$3"
+	
+	# XXX when easy to do, send PROGRESS while transferring the file
+	if [ -e "$loc" ]; then
+		if runcmd cp "$loc" "$file"; then
+			echo TRANSFER-SUCCESS RETRIEVE "$key"
+		else
+			echo TRANSFER-FAILURE RETRIEVE "$key"
+		fi
+	else
+		echo TRANSFER-FAILURE RETRIEVE "$key"
+	fi
+}
+
+docheckpresent () {
+	local key="$1"
+	local loc="$2"
+
+	if [ -e "$loc" ]; then
+		echo CHECKPRESENT-SUCCESS "$key"
+	else
+		if [ -d "$mydirectory" ]; then
+			echo CHECKPRESENT-FAILURE "$key"
+		else
+			# When the directory does not exist,
+			# the remote is not available.
+			# (A network remote would similarly
+			# fail with CHECKPRESENT-UNKNOWN
+			# if it couldn't be contacted).
+			echo CHECKPRESENT-UNKNOWN "$key" "this remote is not currently available"
+		fi
+	fi
+}
+
+doremove () {
+	local key="$1"
+	local loc="$2"
+
+	# Note that it's not a failure to remove a
+	# file that is not present.
+	if [ -e "$loc" ]; then
+		if runcmd rm -f "$loc"; then
+			echo REMOVE-SUCCESS "$key"
+		else
+			echo REMOVE-FAILURE "$key"
+		fi
+	else
+		echo REMOVE-SUCCESS "$key"
+	fi
+}
+
+# This has to come first, to get the protocol started.
+echo VERSION 2
+
+while read line; do
+	set -- $line
+	case "$1" in
+		LISTCONFIGS)
+			# One CONFIG line for each setting that we GETCONFIG
+			# later.
+			echo CONFIG directory store data here
+			echo CONFIGEND
+		;;
+		INITREMOTE)
+			# Do anything necessary to create resources
+			# used by the remote. Try to be idempotent.
+			# 
+			# Use GETCONFIG to get any needed configuration
+			# settings, and SETCONFIG to set any persistent
+			# configuration settings.
+			# 
+			# (Note that this is not run every time, only when
+			# git annex initremote or git annex enableremote is
+			# run.)
+
+			# The directory provided by the user
+			# could be relative; make it absolute,
+			# and store that.
+			getconfig directory
+			mydirectory="$(readlink -f "$RET")" || true
+			setconfig directory "$mydirectory"
+			if [ -z "$mydirectory" ]; then
+				echo INITREMOTE-FAILURE "You need to set directory="
+			else
+				if mkdir -p "$mydirectory"; then
+					setupcreds
+				else
+					echo INITREMOTE-FAILURE "Failed to write to $mydirectory"
+				fi
+			fi
+		;;
+		PREPARE)
+			# Use GETCONFIG to get configuration settings,
+			# and do anything needed to get ready for using the
+			# special remote here.
+			getcreds
+			getconfig directory
+			mydirectory="$RET"
+			if [ -d "$mydirectory" ]; then
+				echo PREPARE-SUCCESS
+			else
+				echo PREPARE-FAILURE "$mydirectory not found"
+			fi
+		;;
+		TRANSFER)
+			op="$2"
+			key="$3"
+			shift 3
+			file="$@"
+			case "$op" in
+				STORE)
+					# Store the file to a location
+					# based on the key.
+					calclocation "$key"
+					dostore "$key" "$file" "$LOC"
+				;;
+				RETRIEVE)
+					# Retrieve from a location based on
+					# the key, outputting to the file.
+					calclocation "$key"
+					doretrieve "$key" "$file" "$LOC"
+				;;
+			esac
+		;;
+		CHECKPRESENT)
+			key="$2"
+			calclocation "$key"
+			docheckpresent "$key" "$LOC"
+		;;
+		REMOVE)
+			key="$2"
+			calclocation "$key"
+			doremove "$key" "$LOC"
+		;;
+		# The requests listed above are all the ones
+		# that are required to be supported, so it's fine
+		# to respond to any others with UNSUPPORTED-REQUEST.
+
+		# Let's also support exporting...
+		EXPORTSUPPORTED)
+			echo EXPORTSUPPORTED-SUCCESS
+		;;
+		EXPORT)
+			shift 1
+			exportlocation="$mydirectory/$@"
+			# No response to this one; this value is used below.
+		;;
+		TRANSFEREXPORT)
+			op="$2"
+			key="$3"
+			shift 3
+			file="$@"
+			case "$op" in
+				STORE)
+					# Store the file to the exportlocation
+					dostore "$key" "$file" "$exportlocation"
+				;;
+				RETRIEVE)
+					# Retrieve from the exportlocation,
+					# outputting to the file.
+					doretrieve "$key" "$exportlocation" "$file"
+				;;
+			esac
+		;;
+		CHECKPRESENTEXPORT)
+			key="$2"
+			docheckpresent "$key" "$exportlocation"
+		;;
+		REMOVEEXPORT)
+			key="$2"
+			doremove "$key" "$exportlocation"
+		;;
+		REMOVEEXPORTDIRECTORY)
+			shift 1
+			dir="$@"
+			if [ ! -d "$dir" ] || rm -rf "$mydirectory/$dir"; then
+				echo REMOVEEXPORTDIRECTORY-SUCCESS
+			else
+				echo REMOVEEXPORTDIRECTORY-FAILURE
+			fi
+		;;
+		RENAMEEXPORT)
+			key="$2"
+			shift 2
+			newexportlocation="$mydirectory/$@"
+			mkdir -p "$(dirname "$newexportlocation")"
+			if runcmd mv -f "$exportlocation" "$newexportlocation"; then
+				echo RENAMEEXPORT-SUCCESS "$key"
+			else
+				echo RENAMEEXPORT-FAILURE "$key"
+			fi
+		;;
+
+		# This is optional, only provided as an example.
+		GETINFO)
+			echo INFOFIELD "repository location"
+			echo INFOVALUE "$mydirectory"
+			echo INFOFIELD "login"
+			echo INFOVALUE "$MYLOGIN"
+			echo INFOEND
+		;;
+
+		*)
+			echo UNSUPPORTED-REQUEST
+		;;
+	esac	
+done
+
+# XXX anything that needs to be done at shutdown can be done here
diff --git a/doc/special_remotes/external/git-annex-remote-ipfs b/doc/special_remotes/external/git-annex-remote-ipfs
new file mode 100755
index 0000000000..f546a1ae81
--- /dev/null
+++ b/doc/special_remotes/external/git-annex-remote-ipfs
@@ -0,0 +1,127 @@
+#!/bin/sh
+# This is a git-annex external special remote program,
+# which adds experimental ipfs support to git-annex.
+#
+# Install in PATH as git-annex-remote-ipfs
+#
+# Copyright 2015 Joey Hess; licenced under the GNU GPL version 3 or higher.
+
+set -e
+
+# use ipfs: as a prefix to indicate when an "url" is really stored in ipfs
+isipfsurl () {
+	echo "$1" | egrep -q "^ipfs:"
+}
+
+# convert an ipfs: url to an address that the ipfs client understands
+urltoaddress () {
+	echo "$1" | sed -e 's/^ipfs://'
+}
+
+addresstourl () {
+	echo "ipfs:$1"
+}
+
+# Gets a VALUE response and stores it in $RET
+getvalue () {
+	read resp
+	# Tricky POSIX shell code to split first word of the resp,
+	# preserving all other whitespace
+	case "${resp%% *}" in
+		VALUE)
+			RET="$(echo "$resp" | sed 's/^VALUE \?//')"
+		;;
+		*)
+		RET=""
+		;;
+	esac
+}
+
+# Get a list of all known ipfs addresses for a key,
+# storing it in a temp file.
+getaddrs () {
+        key="$1"
+        tmp="$2"
+
+        echo GETURLS "$key"
+        getvalue
+        while [ -n "$RET" ]; do
+                if isipfsurl "$RET"; then
+                        echo "$RET" >> "$tmp"
+                fi
+                getvalue
+        done
+}
+
+# This has to come first, to get the protocol started.
+echo VERSION 2
+
+while read line; do
+	set -- $line
+	case "$1" in
+		INITREMOTE)
+			echo INITREMOTE-SUCCESS
+		;;
+		PREPARE)
+			echo PREPARE-SUCCESS
+		;;
+		CLAIMURL)
+			url="$2"
+			if isipfsurl "$url"; then
+				echo CLAIMURL-SUCCESS
+			else
+				echo CLAIMURL-FAILURE
+			fi
+		;;
+		CHECKURL)
+			url="$2"
+			# TODO if size of file can be quickly determined
+			# (without downloading it) return the size
+			# instead of UNKNOWN
+			echo CHECKURL-CONTENTS UNKNOWN "$(urltoaddress "$url")"
+		;;
+		TRANSFER)
+			op="$2"
+			key="$3"
+			shift 3
+			file="$@"
+			case "$op" in
+				STORE)
+					addr=$(ipfs add -q "$file" </dev/null) || true
+					if [ -z "$addr" ]; then
+						echo TRANSFER-FAILURE STORE "$key" "ipfs add failed"
+					else
+						echo "SETURIPRESENT" "$key" "$(addresstourl "$addr")"
+						echo TRANSFER-SUCCESS STORE "$key"
+					fi
+				;;
+				RETRIEVE)
+					addrtmp=$(mktemp)
+					getaddrs "$key" "$addrtmp"
+					addr="$(urltoaddress "$(head "$addrtmp")")" || true
+					rm -f "$addrtmp"
+					if [ -z "$addr" ]; then
+						echo TRANSFER-FAILURE RETRIEVE "$key" "no known ipfs address for this key"
+					else
+						if ! ipfs get --output="$file" "$addr" >&2 </dev/null; then
+							echo TRANSFER-FAILURE RETRIEVE "$key" "failed downloading ipfs $addr"
+						else
+							echo TRANSFER-SUCCESS RETRIEVE "$key"
+						fi
+					fi
+				;;
+			esac
+		;;
+		CHECKPRESENT)
+			key="$2"
+			echo CHECKPRESENT-FAILURE "$key"
+		;;
+		REMOVE)
+			key="$2"
+			echo REMOVE-FAILURE "$key" "cannot remove content from ipfs (instead, run ipfs gc to clear your local ipfs cache)"
+		;;
+		*)
+			echo UNSUPPORTED-REQUEST
+		;;
+	esac	
+done
diff --git a/doc/special_remotes/external/git-annex-remote-torrent b/doc/special_remotes/external/git-annex-remote-torrent
new file mode 100755
index 0000000000..f41585b7c2
--- /dev/null
+++ b/doc/special_remotes/external/git-annex-remote-torrent
@@ -0,0 +1,205 @@
+#!/bin/sh
+# This is a demo git-annex external special remote program,
+# which adds basic torrent download support to git-annex.
+#
+# Uses aria2c. Also needs the original bittorrent (or bittornado) for the
+# btshowmetainfo command.
+# 
+# Install in PATH as git-annex-remote-torrent
+#
+# Enable remote by running:
+#  git annex initremote torrent type=external encryption=none externaltype=torrent
+#  git annex untrust torrent
+#
+# Copyright 2014 Joey Hess; licenced under the GNU GPL version 3 or higher.
+
+set -e
+
+# This program speaks a line-based protocol on stdin and stdout.
+# When running any commands, their stdout should be redirected to stderr
+# (or /dev/null) to avoid messing up the protocol.
+runcmd () {
+	"$@" >&2
+}
+
+# Gets a VALUE response and stores it in $RET
+getvalue () {
+	read resp
+	# Tricky POSIX shell code to split first word of the resp,
+	# preserving all other whitespace
+	case "${resp%% *}" in
+		VALUE)
+			RET="$(echo "$resp" | sed 's/^VALUE \?//')"
+		;;
+		*)
+		RET=""
+		;;
+	esac
+}
+
+# Get a list of all known torrent urls for a key,
+# storing it in a temp file.
+geturls () {
+	key="$1"
+	tmp="$2"
+
+	echo GETURLS "$key"
+	getvalue
+	while [ -n "$RET" ]; do
+		if istorrent "$RET"; then
+			echo "$RET" >> "$tmp"
+		fi
+		getvalue
+	done
+}
+
+# Does the url end in .torrent?
+# Note that we use #N on the url to indicate which file
+# from a multi-file torrent is wanted.
+istorrent () {
+	echo "$1" | egrep -q "\.torrent(#.*)?$"
+}
+
+# Download a single file from a torrent.
+#
+# Note: Does not support resuming interrupted transfers.
+# Note: Does not feed progress info back to git-annex, and since
+# the destination file is only populated at the end, git-annex will fail
+# to display a progress bar for this download.
+downloadtorrent () {
+	torrent="$1"
+	n="$2"
+	dest="$3"
+
+	tmpdir="$(mktemp -d)"
+
+	# aria2c will create part of the directory structure
+	# contained in the torrent. It may download parts of other files
+	# in addition to the one we asked for. So, we need to find
+	# out the filename we want, and look for it.
+	wantdir="$(btshowmetainfo "$torrent" | grep "^directory name: " | sed "s/^directory name: //" || true)"
+	if [ -n "$wantdir" ]; then
+		wantfile="$(btshowmetainfo "$torrent" | grep '^   ' | sed 's/^   //' | head -n "$n" | tail -n 1 | sed 's/ ([0-9]*)$//')"
+		if ! runcmd aria2c --select-file="$n" "$torrent" -d "$tmpdir"; then
+			false
+		fi
+	else
+		wantfile="$(btshowmetainfo "$torrent" | egrep "^file name.*: " | sed "s/^file name.*: //")"
+		wantdir=.
+		if ! runcmd aria2c "$torrent" -d "$tmpdir"; then
+			false
+		fi
+	fi
+	if [ -e "$tmpdir/$wantdir/$wantfile" ]; then
+		mv "$tmpdir/$wantdir/$wantfile" "$dest"
+		rm -rf "$tmpdir"
+	else
+		rm -rf "$tmpdir"
+		false
+	fi
+}
+
+# This has to come first, to get the protocol started.
+echo VERSION 2
+
+while read line; do
+	set -- $line
+	case "$1" in
+		INITREMOTE)
+			echo INITREMOTE-SUCCESS
+		;;
+		PREPARE)
+			echo PREPARE-SUCCESS
+		;;
+		CLAIMURL)
+			url="$2"
+			if istorrent "$url"; then
+				echo CLAIMURL-SUCCESS
+			else
+				echo CLAIMURL-FAILURE
+			fi
+		;;
+		CHECKURL)
+			url="$2"
+			# List contents of torrent.
+			tmp=$(mktemp)
+			if ! runcmd curl --proto -all,http,https -o "$tmp" "$url"; then
+				echo CHECKURL-FAILURE
+			else
+				oldIFS="$IFS"
+			IFS="
+"
+				printf "CHECKURL-MULTI"
+				n=0
+				for l in $(btshowmetainfo "$tmp" | grep '^   ' | sed 's/^   //'); do
+					# Note that the file cannot contain spaces.
+					file="$(echo "$l" | sed 's/ ([0-9]*)$//' | sed 's/ /_/g')"
+					size="$(echo "$l" | sed 's/.* (\([0-9]*\))$/\1/')"
+					n=$(expr $n + 1)
+					printf " $url#$n $size $file"
+				done
+				if [ "$n" = 0 ]; then
+					file="$(btshowmetainfo "$tmp" | egrep "^file name.*: " | sed "s/^file name.*: //")"
+					size="$(btshowmetainfo "$tmp" | egrep "^file size.*: " | sed "s/^file size.*: \([0-9]*\).*/\1/")"
+					printf " $url $size $file"
+				fi
+				printf "\n"
+				IFS="$oldIFS"
+			fi
+			rm -f "$tmp"
+		;;
+		TRANSFER)
+			op="$2"
+			key="$3"
+			shift 3
+			file="$@"
+			case "$op" in
+				STORE)
+					echo TRANSFER-FAILURE STORE "$key" "upload not supported"
+				;;
+				RETRIEVE)
+					urltmp=$(mktemp)
+					geturls "$key" "$urltmp"
+					url="$(head "$urltmp")" || true
+					rm -f "$urltmp"
+					if [ -z "$url" ]; then
+						echo TRANSFER-FAILURE RETRIEVE "$key" "no known torrent urls for this key"
+					else
+						tmp=$(mktemp)
+						if ! runcmd curl --proto -all,http,https -o "$tmp" "$url"; then
+							echo TRANSFER-FAILURE RETRIEVE "$key" "failed downloading torrent file from $url"
+						else
+							filenum="$(echo "$url" | sed 's/(.*#\(\d*\)/\1/')"
+							if downloadtorrent "$tmp" "$filenum" "$file"; then
+								echo TRANSFER-SUCCESS RETRIEVE "$key"
+							else
+								echo TRANSFER-FAILURE RETRIEVE "$key" "failed to download torrent contents from $url"
+							fi
+						fi
+						rm -f "$tmp"					
+					fi
+				;;
+			esac
+		;;
+		CHECKPRESENT)
+			key="$2"
+			# Let's just assume that torrents are never present
+			# for simplicity.
+			echo CHECKPRESENT-UNKNOWN "$key" "cannot reliably check torrent status"
+		;;
+		REMOVE)
+			key="$2"
+			# Remove all torrent urls for the key.
+			tmp=$(mktemp)
+			geturls "$key" "$tmp"
+			for url in $(cat "$tmp"); do
+				echo SETURLMISSING "$key" "$url"
+			done
+			rm -f "$tmp"
+			echo REMOVE-SUCCESS "$key"
+		;;
+		*)
+			echo UNSUPPORTED-REQUEST
+		;;
+	esac	
+done
diff --git a/doc/special_remotes/gcrypt.mdwn b/doc/special_remotes/gcrypt.mdwn
new file mode 100644
index 0000000000..db9543ed6e
--- /dev/null
+++ b/doc/special_remotes/gcrypt.mdwn
@@ -0,0 +1,65 @@
+[git-remote-gcrypt](https://spwhitton.name/tech/code/git-remote-gcrypt/)
+adds support for encrypted remotes to git. The git-annex gcrypt special
+remote allows git-annex to also store its files in such repositories.
+Naturally, git-annex encrypts the files it stores too, so everything
+stored on the remote is encrypted.
+
+This special remote needs the server hosting the remote repository
+to either have git-annex-shell or rsync accessible via ssh. git-annex
+uses those to store its content in the remote. If the remote repository
+is instead hosted on a server using git-lfs, you can use the [[git-lfs]]
+special remote instead of this one; it also supports using gcrypt.
+
+See [[tips/fully_encrypted_git_repositories_with_gcrypt]] for some examples
+of using gcrypt.
+
+## configuration
+
+These parameters can be passed to `git annex initremote` to configure
+gcrypt:
+
+* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
+  Required. See [[encryption]].
+
+* `keyid` - Specifies the gpg key to use for encryption of both the files
+  git-annex stores in the repository, as well as to encrypt the git
+  repository itself. May be repeated when multiple participants
+  should have access to the repository.
+
+* `gitrepo` - Required. The location of the git repository
+  for gcrypt to use. This repository should be either an unpopulated
+  bare git repo, or an existing gcrypt repository.
+
+  To use a local git repository, use: `gitrepo=/path/to/repo`
+
+  For a git repository accessed over ssh, an `rsync://` url uses rsync over
+  ssh, while a `ssh://` url uses git-annex-shell over ssh.
+  Note that each `git push` has to re-send the whole content of the git
+  repository when using the latter option, so rsync urls are generally more
+  efficient.
+
+* `chunk` - Enables [[chunking]] when storing large files.
+
+* `shellescape` - See [[rsync]] for the details of this option.
+
+## notes
+
+For git-annex to store files in a repository on a remote server, you need
+shell access, and it needs to be able to run `rsync` or `git-annex-shell`.
+
+If you can't run `rsync` or `git-annex-shell` on the remote server,
+you can't use this special remote. Other options are the [[git-lfs]]
+special remote, which can also be combined with gcrypt, or 
+using git-remote-gcrypt to encrypt a remote that git-annex cannot use.
+
+If you use encryption=hybrid, you can later add more gpg keys that can access
+the files git-annex stored in the gcrypt repository. However, due to the
+way git-remote-gcrypt encrypts the git repository, you will need to somehow
+force it to re-push everything again, so that the encrypted repository can
+be decrypted by the added keys. Probably this can be done by setting
+`GCRYPT_FULL_REPACK` and doing a forced push of branches.
+
+Recent versions of git-annex configure `remote.<name>`gcrypt-publish-participants` when
+setting up a gcrypt repository. This is done to avoid unnecessary gpg
+passphrase prompts, but it does publish the gpg keyids that can decrypt the
+repository. Unset it if you need to obscure that.
diff --git a/doc/special_remotes/gcrypt/comment_1_16a7b4978a58284b5ab3c58f2102e9d0._comment b/doc/special_remotes/gcrypt/comment_1_16a7b4978a58284b5ab3c58f2102e9d0._comment
new file mode 100644
index 0000000000..b0daadff39
--- /dev/null
+++ b/doc/special_remotes/gcrypt/comment_1_16a7b4978a58284b5ab3c58f2102e9d0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="aaron"
+ avatar="http://cdn.libravatar.org/avatar/8a07e2f7af4bbf1bfcb48bbc53e00747"
+ subject="How does the gcrypt type compare to the rsync special remote"
+ date="2022-01-09T05:31:34Z"
+ content="""
+For systems (such as rsync.net) that allow us to use both rsync and git-annex, which is the better option?  I noticed that the default for rsync.net was this type (gcrypt), does it provide additional capabilities or perform slightly better than the [rsync version](https://git-annex.branchable.com/special_remotes/rsync/)?
+"""]]
diff --git a/doc/special_remotes/gcrypt/comment_2_08245fd6716ee3ed5ac98fe95e7d5ca1._comment b/doc/special_remotes/gcrypt/comment_2_08245fd6716ee3ed5ac98fe95e7d5ca1._comment
new file mode 100644
index 0000000000..425f696e59
--- /dev/null
+++ b/doc/special_remotes/gcrypt/comment_2_08245fd6716ee3ed5ac98fe95e7d5ca1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="tomdhunt"
+ avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
+ subject="comment 2"
+ date="2022-01-09T05:45:35Z"
+ content="""
+The gcrypt special remote is for use with the git-remote-gcrypt protocol for making encrypted git remotes. The rsync special remote can also encrypt the files it stores, but it's not related to git-remote-gcrypt; it just puts files in a plain directory tree using rsync.
+
+If you want to keep a repository remote (not a special remote) on your rsync.net host, and want it to be encrypted, then you can use git-remote-gcrypt and use this special remote so that the data is all together. If you're not using git-remote-gcrypt, then the rsync special remote is what you want.
+"""]]
diff --git a/doc/special_remotes/gcrypt/comment_3_2b22c692fb98be1a964430b5b1a329a9._comment b/doc/special_remotes/gcrypt/comment_3_2b22c692fb98be1a964430b5b1a329a9._comment
new file mode 100644
index 0000000000..b26cc75a2e
--- /dev/null
+++ b/doc/special_remotes/gcrypt/comment_3_2b22c692fb98be1a964430b5b1a329a9._comment
@@ -0,0 +1,53 @@
+[[!comment format=mdwn
+ username="aaron"
+ avatar="http://cdn.libravatar.org/avatar/8a07e2f7af4bbf1bfcb48bbc53e00747"
+ subject="comment 3"
+ date="2022-01-09T08:36:34Z"
+ content="""
+@tomdhunt, Are you saying that the difference is the rsync remote only contains the files and the actual history stuff from git isn't tracked in it while the git-remote-gcrypt one also tracks history because it is a bare git repo?
+
+Additionally, I just started trying out the grcrypt version on rsync.net and it seems to use a slightly different initialization when compared to the others.  I've made some progress, but I am still not quite able to make it work, it seems that I'm having issues initializing the bare remote when I do it via the terminal.  If I don't try to create a bare and push it the first commit completely fails, I seem to be able to make more progress by creating a bare, pushing it, and then adding it (but it still fails).  This is what I have got to so far:
+
+```bash
+user@localhost:$ sudo chown <rsync.net user>:<rsync.net user> -R
+user@localhost:$ git init --bare shared=group test_repo.git
+user@localhost:$ sudo rsync -vrSP test_repo.git <rsync.net user>@<server>:annex
+user@localhost:$ git annex initremote \"<some_userful_name>\" type=gcrypt gitrepo=<rsync.net user>@<server>:annex chunk=1MiB keyid=<key_id> encryption=shared mac=HMACSHA512 autoenable=true
+```
+
+The error message that I get:
+
+```bash
+user@localhost:$ git annex sync
+commit 
+On branch master
+
+Initial commit
+
+nothing to commit (create/copy files and use \"git add\" to track)
+ok
+pull <rsync.net server> 
+gcrypt: Decrypting manifest
+gpg: selecting card failed: No such device
+gpg: Signature made Sun 09 Jan 2022 08:26:18 AM GMT
+gpg:                using EDDSA key <key>
+gpg: Good signature from \"<key comment>\" [ultimate]
+
+merge: refs/remotes/<remote name>/master - not something we can merge
+
+merge: refs/remotes/<remote name>/synced/master - not something we can merge
+failed
+sync: 1 failed
+
+```
+
+It also looks like this method fails to add `gcrypt-participants = <key>` and `gcrypt-signingkey = <key>` to the `.git/config` file like webapp does.
+
+Furthermore, when I use the `git annex webapp` to generate the repo, it does something that seems to be even more different (and successfully creates the bare repo by itself), specifically the URL looks something like this:
+
+```bash
+url = gcrypt::<rsync.net user>@git-annex-.<country>.2D<server_subname?>.2E<server_name>.2E<server_domain>-<rsync.net user>_22_annex:annex/
+```
+
+It seems to be encoding some of the characters to make a URL?  Is there another web API that we can interact with?
+"""]]
diff --git a/doc/special_remotes/git-lfs.mdwn b/doc/special_remotes/git-lfs.mdwn
new file mode 100644
index 0000000000..3a6d851de1
--- /dev/null
+++ b/doc/special_remotes/git-lfs.mdwn
@@ -0,0 +1,93 @@
+git-annex has a special remote that lets it store content in git-lfs
+repositories.
+
+See [[tips/storing_data_in_git-lfs]] for some examples of how to use this.
+
+## configuration
+
+These parameters can be passed to `git annex initremote` to configure
+the git-lfs special remote:
+
+* `url` - Required. The url to the git-lfs repository to use.
+  Can be either a ssh url (scp-style is also accepted) or a http url.
+
+* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
+  Required. See [[encryption]]. Also see the encryption notes below.
+
+* `keyid` - Specifies the gpg key to use for encryption of both the files
+  git-annex stores in the repository, as well as to encrypt the git
+  repository itself when using gcrypt.
+
+## efficiency note
+
+Since git-lfs uses SHA256 checksums, git-annex needs to keep track of the
+SHA256 of content stored in it, in order to be able to retrieve that
+content. When a git-annex key uses a [[backend|backends]]
+of SHA256 or SHA256E, that's easy. But, if a git-annex key uses some
+other backend, git-annex has to additionally store the SHA256 checksum
+into the git-annex branch when storing content in git-lfs. That adds a
+small bit of size overhead to using this remote.
+
+When encrypting data sent to the git-lfs remote, git-annex always has to
+store its SHA256 checksum in the git-annex branch.
+
+## encryption notes
+
+To encrypt a git-lfs repository, there are two separate things that
+have to be encrypted: the data git-annex stores there, and the content
+of the git repository itself. After all, a git-lfs remote is a git remote
+and git push doesn't encrypt data by default.
+
+To encrypt your git pushes, you can use 
+[git-remote-gcrypt](https://spwhitton.name/tech/code/git-remote-gcrypt/)
+and prefix the repository url with "gcrypt::"
+
+To make git-annex encrypt the data it stores, you can use the encryption=
+configuration.
+
+An example of combining the two:
+
+	git annex initremote lfstest type=git-lfs url=gcrypt::git@github.com:username/somerepo.git encryption=shared
+
+In that example, the git-annex shared encryption key is stored in
+git, but that's ok because git push will encrypt it, along with all
+the other git data, using your gpg key. You could instead use
+"encryption=shared keyid=" to make git-annex and gcrypt both encrypt
+to a specified gpg key.
+
+git-annex will detect if one part of the repository is encrypted,
+but you forgot to encrypt the other part, and will refuse to set up
+such an insecure half-encrypted repository.
+
+If you use encryption=hybrid, you can later add more gpg keys that can access
+the files git-annex stored in the git-lfs repository. However, due to the
+way git-remote-gcrypt encrypts the git repository, you will need to somehow
+force it to re-push everything again, so that the encrypted repository can
+be decrypted by the added keys. Probably this can be done by setting
+`GCRYPT_FULL_REPACK` and doing a forced push of branches.
+
+git-annex will set `remote.<name>`gcrypt-publish-participants` when setting
+up a repository that uses gcrypt. This is done to avoid unnecessary gpg
+passphrase prompts, but it does publish the gpg keyids that can decrypt the
+repository. Unset it if you need to obscure that.
+
+## limitations
+
+The git-lfs protocol does not support deleting content, so git-annex
+**cannot delete anything** from a git-lfs special remote.
+
+The git-lfs protocol does not support resuming uploads, and so an
+interrupted upload will have to restart from the beginning. Interrupted
+downloads will resume.
+
+git-lfs has a concept of git ref based access control, so a user may only
+be able to send content associated with a particular git ref. git-annex
+does not currently provide any git ref, so won't work with a git-lfs server
+that uses that.
+
+git-annex only supports the "basic" git-lfs transfer adapter, but that's
+the one used by most git-lfs servers.
+
+The git-lfs protocol is designed around batching of transfers, but
+git-annex doesn't do batching. This may cause it to fall afoul of
+rate limiting of git-lfs servers when transferring a lot of files.
diff --git a/doc/special_remotes/git.mdwn b/doc/special_remotes/git.mdwn
new file mode 100644
index 0000000000..3c61b750fe
--- /dev/null
+++ b/doc/special_remotes/git.mdwn
@@ -0,0 +1,18 @@
+Normally a git repository is not treated as a special remote, but as a git
+remote of the normal kind. Two exceptions to that are [[git-lfs]] and
+[[gcrypt]] special remotes.
+
+But it is possible to register a git repository as a special remote.
+git-annex and git will use the remote the same as any normal git remote,
+but its url will be recorded in the repository. One benefit of doing this
+is it allows [[git-annex init|git-annex-init]] to autoenable the remote.
+
+To set up such a special remote:
+
+	git annex initremote myremote type=git location=ssh://... autoenable=true
+
+Now `git annex init` in each clone of the repository will autoenable myremote.
+
+This only works for git repositories that have a git-annex uuid set,
+because special remotes have to have a uuid. So it cannot be used
+with git repositories that are not git-annex repositories.
diff --git a/doc/special_remotes/git/comment_1_4c76e1f29065cfb2f8bc05c187c1cc31._comment b/doc/special_remotes/git/comment_1_4c76e1f29065cfb2f8bc05c187c1cc31._comment
new file mode 100644
index 0000000000..fbfae2b614
--- /dev/null
+++ b/doc/special_remotes/git/comment_1_4c76e1f29065cfb2f8bc05c187c1cc31._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="matthias.risze@9f2c8f7faed4cac1905d1bf1ee4524d708c13688"
+ nickname="matthias.risze"
+ avatar="http://cdn.libravatar.org/avatar/c9f7f022a1d62c39497b72c56a6a535e"
+ subject="type=git special remote cannot be enabled, no uuid is generated"
+ date="2021-08-16T13:02:04Z"
+ content="""
+Following the instructions here, I cannot enable the remote. The error message is: `git-annex: Unknown remote name.`. I assume this is because git annex does not create a uuid for the type=git special remote, presumably because non is set for the actual git remote (the annex-uuid key does not exist for the existing git remote with the same url). This is the relevant line generated in remote.log: ` autoenable=true location=<ssh-url> name=<name> type=git timestamp=1629118438.628919s`, as you can see there is no uuid at the beginning. Any ideas if this is a bug or if the instructions are outdated?
+"""]]
diff --git a/doc/special_remotes/git/comment_2_12c53dbbdb77f98f337ad60c67171337._comment b/doc/special_remotes/git/comment_2_12c53dbbdb77f98f337ad60c67171337._comment
new file mode 100644
index 0000000000..fa47a6c0fd
--- /dev/null
+++ b/doc/special_remotes/git/comment_2_12c53dbbdb77f98f337ad60c67171337._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-08-24T16:42:27Z"
+ content="""
+This can only be used for git remotes that have an annex-uuid set. All
+special remotes have to have a uuid. git remotes that are hosted on a
+system with git-annex installed get the annex-uuid set up automatically,
+but it won't happen if your special remote is on github or something like
+that. You could `git config remote.foo.annex-uuid $(uuid)` to generate and 
+set a new uuid, I suppose.
+"""]]
diff --git a/doc/special_remotes/glacier.mdwn b/doc/special_remotes/glacier.mdwn
new file mode 100644
index 0000000000..5dde37208c
--- /dev/null
+++ b/doc/special_remotes/glacier.mdwn
@@ -0,0 +1,47 @@
+This special remote type stores file contents in Amazon Glacier.
+
+To use it, you need to have [glacier-cli](http://github.com/basak/glacier-cli)
+installed.
+
+The unusual thing about Amazon Glacier is the multiple-hour delay it takes
+to retrieve information out of Glacier. To deal with this, commands like
+"git-annex get" request Glacier start the retrieval process, and will fail
+due to the data not yet being available. You can then wait approximately 
+four hours, re-run the same command, and this time, it will actually
+download the data.
+
+## configuration
+
+The standard environment variables `AWS_ACCESS_KEY_ID` and 
+`AWS_SECRET_ACCESS_KEY` are used to supply login credentials
+for Amazon. You need to set these only when running
+`git annex initremote` (or `enableremote`), as they will be cached in
+a file only you can read inside the local git repository.
+
+A number of parameters can be passed to `git annex initremote` to configure
+the Glacier remote.
+
+* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
+  See [[encryption]].
+
+* `keyid` - Specifies the gpg key to use for [[encryption]].
+
+* `embedcreds` - Optional. Set to "yes" embed the login credentials inside
+  the git repository, which allows other clones to also access them. This is
+  the default when gpg encryption is enabled; the credentials are stored
+  encrypted and only those with the repository's keys can access them.
+
+  It is not the default when using shared encryption, or no encryption.
+  Think carefully about who can access your repository before using
+  embedcreds without gpg encryption.
+
+* `datacenter` - Defaults to "us-east-1".
+
+* `vault` - By default, a vault name is chosen based on the remote name
+  and UUID. This can be specified to pick a vault name.
+
+* `fileprefix` - By default, git-annex places files in a tree rooted at the
+  top of the Glacier vault. When this is set, it's prefixed to the filenames
+  used. For example, you could set it to "foo/" in one special remote,
+  and to "bar/" in another special remote, and both special remotes could
+  then use the same vault.
diff --git a/doc/special_remotes/glacier/comment_10_c0e841c3e305712d960e43a10e674215._comment b/doc/special_remotes/glacier/comment_10_c0e841c3e305712d960e43a10e674215._comment
new file mode 100644
index 0000000000..be2ef46878
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_10_c0e841c3e305712d960e43a10e674215._comment
@@ -0,0 +1,63 @@
+[[!comment format=mdwn
+ username="forbesmyester@2cec261fa984ee168bdbad63665c58953963c10e"
+ nickname="forbesmyester"
+ subject="Not sure what is wrong... looks like `glacier` might be called wrongly."
+ date="2015-08-18T07:42:38Z"
+ content="""
+Have done a full setup as much as I can, with all the GPG / AWS stuff but it keeps doing non stop...
+
+    copy 201/2011/05/20/P1010044.RW2 (checking familypictures-glacier...) [2015-08-18 08:37:05 BST] read: glacier [\"--region=us-east-1\",\"archive\",\"checkpresent\",\"familypictures\",\"--quiet\",\"GPGHMACSHA1--[SOME_HASH]\"]
+    (to familypictures-glacier...) 
+    [2015-08-18 08:37:05 BST] feed: glacier [\"--region=us-east-1\",\"archive\",\"upload\",\"--name\",\"GPGHMACSHA1--[SOME_HASH]\",\"familypictures\",\"-\"]
+    [2015-08-18 08:37:05 BST] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"40\",\"--symmetric\",\"--force-mdc\",\"--no-textmode\"]
+    0%            0.0 B/s 0s
+    glacier <command> [args]
+    
+        Commands
+            vaults    - Operations with vaults
+            jobs      - Operations with jobs
+            upload    - Upload files to a vault. If the vault doesn't exits, it is
+                        created
+    
+        Common args:
+            --access_key - Your AWS Access Key ID.  If not supplied, boto will
+                           use the value of the environment variable
+                           AWS_ACCESS_KEY_ID
+            --secret_key - Your AWS Secret Access Key.  If not supplied, boto
+                           will use the value of the environment variable
+                           AWS_SECRET_ACCESS_KEY
+            --region     - AWS region to use. Possible values: us-east-1, us-west-1,
+                           us-west-2, ap-northeast-1, eu-west-1.
+                           Default: us-east-1
+    
+        Vaults operations:
+    
+            List vaults:
+                glacier vaults 
+    
+        Jobs operations:
+    
+            List jobs:
+                glacier jobs <vault name>
+    
+        Uploading files:
+    
+            glacier upload <vault name> <files>
+    
+            Examples : 
+                glacier upload pics *.jpg
+                glacier upload pics a.jpg b.jpg
+    
+    gpg: [stdout]: write error: Broken pipe
+    gpg: DBG: deflate: iobuf_write failed
+    gpg: build_packet failed: file write error
+    gpg: [stdout]: write error: Broken pipe
+    gpg: iobuf_flush failed on close: file write error
+    gpg: [stdout]: write error: Broken pipe
+    gpg: iobuf_flush failed on close: file write error
+    gpg: symmetric encryption of `[stdin]' failed: file write error
+    git-annex: fd:46: hPutBuf: resource vanished (Broken pipe)
+    failed
+    
+
+"""]]
diff --git a/doc/special_remotes/glacier/comment_11_e062b823b4d0b365698a6488d756b85c._comment b/doc/special_remotes/glacier/comment_11_e062b823b4d0b365698a6488d756b85c._comment
new file mode 100644
index 0000000000..0c38120c27
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_11_e062b823b4d0b365698a6488d756b85c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2015-08-19T18:27:53Z"
+ content="""
+@forbesmyester, I think that the "glacier" program you have installed is
+the one from boto, not the one from glacier-cli. git-annex only supports
+the glacier-cli one.
+
+Note that, since version 5.20150219, git-annex probes to see if the
+"glacier" program in PATH is the one from boto, and fails with a nicer
+error message.
+"""]]
diff --git a/doc/special_remotes/glacier/comment_12_a097d78d15e103c10f67e237c852b222._comment b/doc/special_remotes/glacier/comment_12_a097d78d15e103c10f67e237c852b222._comment
new file mode 100644
index 0000000000..f033bab9a7
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_12_a097d78d15e103c10f67e237c852b222._comment
@@ -0,0 +1,59 @@
+[[!comment format=mdwn
+ username="git-annex,branchable.com@1fa4b21c7ece2d61d4730de8e83329049126cedc"
+ nickname="git-annex,branchable.com"
+ subject="Glacier-cli works, thanks, some encode / decode error now..."
+ date="2015-08-26T08:30:53Z"
+ content="""
+Hi Joey,
+
+Thanks for the hand, it started uploading once I had manually created the vault but then borked with:
+
+    fozz@cobol:~/Store/family_pictures $ git annex --verbose copy 201/2011/05/07/P1010004.RW2 --to familypictures-glacier
+    copy 201/2011/05/07/P1010004.RW2 (gpg) (checking familypictures-glacier...) (to familypictures-glacier...) 
+    81%           4.0MB/s 0sTraceback (most recent call last):
+      File \"/home/fozz/.vendor/bin/glacier\", line 730, in <module>
+        App().main()
+      File \"/home/fozz/.vendor/bin/glacier\", line 716, in main
+        self.args.func()
+      File \"/home/fozz/.vendor/bin/glacier\", line 498, in archive_upload
+        file_obj=self.args.file, description=name)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/vault.py\", line 177, in create_archive_from_file
+        writer.write(data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 219, in write
+        self.partitioner.write(data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 61, in write
+        self._send_part()
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 75, in _send_part
+        self.send_fn(part)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 222, in _upload_part
+        self.uploader.upload_part(self.next_part_index, part_data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 129, in upload_part
+        content_range, part_data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/layer1.py\", line 1279, in upload_part
+        response_headers=response_headers)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/layer1.py\", line 114, in make_request
+        data=data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/connection.py\", line 1071, in make_request
+        retry_handler=retry_handler)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/connection.py\", line 943, in _mexe
+        request.body, request.headers)
+      File \"/usr/lib/python2.7/httplib.py\", line 979, in request
+        self._send_request(method, url, body, headers)
+      File \"/usr/lib/python2.7/httplib.py\", line 1013, in _send_request
+        self.endheaders(body)
+      File \"/usr/lib/python2.7/httplib.py\", line 975, in endheaders
+        self._send_output(message_body)
+      File \"/usr/lib/python2.7/httplib.py\", line 833, in _send_output
+        msg += message_body
+    UnicodeDecodeError: 'ascii' codec can't decode byte 0x8c in position 0: ordinal not in range(128)
+    gpg: [stdout]: write error: Broken pipe
+    gpg: DBG: deflate: iobuf_write failed
+    gpg: build_packet failed: file write error
+    gpg: [stdout]: write error: Broken pipe
+    gpg: iobuf_flush failed on close: file write error
+    gpg: symmetric encryption of `[stdin]' failed: file write error
+    git-annex: fd:17: hPutBuf: resource vanished (Broken pipe)
+    failed                  
+    git-annex: copy: 1 failed
+
+"""]]
diff --git a/doc/special_remotes/glacier/comment_13_6ef8735fbd357a09dafe254c8da3b1a8._comment b/doc/special_remotes/glacier/comment_13_6ef8735fbd357a09dafe254c8da3b1a8._comment
new file mode 100644
index 0000000000..58ac2ada65
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_13_6ef8735fbd357a09dafe254c8da3b1a8._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="dave@2ab82f485adf7e2ce787066e35f5f9789bff430b"
+ nickname="dave"
+ subject="re: UnicodeDecodeError"
+ date="2015-08-26T21:54:08Z"
+ content="""
+This part:
+
+      File \"/usr/lib/python2.7/httplib.py\", line 833, in _send_output
+        msg += message_body
+    UnicodeDecodeError: 'ascii' codec can't decode byte 0x8c in position 0: ordinal not in range(128)
+
+Tells me that you need to read [glacier-cli problem report #61](https://github.com/basak/glacier-cli/issues/61).
+
+There is a one-line [code change in a library named boto](https://github.com/felixonmars/boto/commit/0676eaf014f56279908cdd3409a5bb6895e86bf6) (glacier-cli depends on it) which will fix this.  (And probably that change will get merged in sometime, so you won't have to do this anymore.)
+"""]]
diff --git a/doc/special_remotes/glacier/comment_14_53c965ab49c75fe2220a04f014ba577f._comment b/doc/special_remotes/glacier/comment_14_53c965ab49c75fe2220a04f014ba577f._comment
new file mode 100644
index 0000000000..7345a322e9
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_14_53c965ab49c75fe2220a04f014ba577f._comment
@@ -0,0 +1,56 @@
+[[!comment format=mdwn
+ username="victorsavu3@d059e0a74888923e70a555ce8ab75e8ba00b6eb7"
+ nickname="victorsavu3"
+ avatar="http://cdn.libravatar.org/avatar/4b54518265211913a82b83b930427c45"
+ subject="RequestTimeoutException when uploading to glacier"
+ date="2017-02-09T20:45:42Z"
+ content="""
+I sometimes receive the following error when trying to upload files to glacier:
+
+```
+Traceback (most recent call last):
+ File \"/home/victor/bin/glacier\", line 736, in <module>
+    main()
+  File \"/home/victor/bin/glacier\", line 732, in main
+    App().main()
+  File \"/home/victor/bin/glacier\", line 718, in main
+    self.args.func()
+  File \"/home/victor/bin/glacier\", line 500, in archive_upload
+    file_obj=self.args.file, description=name)
+  File \"/usr/lib/python2.7/site-packages/boto/glacier/vault.py\", line 178, in create_archive_from_file
+    writer.close()
+  File \"/usr/lib/python2.7/site-packages/boto/glacier/writer.py\", line 228, in close
+    self.partitioner.flush()
+  File \"/usr/lib/python2.7/site-packages/boto/glacier/writer.py\", line 79, in flush
+    self._send_part()
+  File \"/usr/lib/python2.7/site-packages/boto/glacier/writer.py\", line 75, in _send_part
+    self.send_fn(part)
+  File \"/usr/lib/python2.7/site-packages/boto/glacier/writer.py\", line 222, in _upload_part
+    self.uploader.upload_part(self.next_part_index, part_data)
+  File \"/usr/lib/python2.7/site-packages/boto/glacier/writer.py\", line 129, in upload_part
+    content_range, part_data)
+  File \"/usr/lib/python2.7/site-packages/boto/glacier/layer1.py\", line 1279, in upload_part
+    response_headers=response_headers)
+  File \"/usr/lib/python2.7/site-packages/boto/glacier/layer1.py\", line 119, in make_request
+    raise UnexpectedHTTPResponseError(ok_responses, response)
+boto.glacier.exceptions.UnexpectedHTTPResponseError: Expected 204, got (408, code=RequestTimeoutException, message=Request timed out.)
+gpg: [stdout]: write error: Broken pipe
+gpg: DBG: deflate: iobuf_write failed
+gpg: [stdout]: write error: Broken pipe
+gpg: filter_flush failed on close: Broken pipe
+gpg: [stdout]: write error: Broken pipe
+gpg: filter_flush failed on close: Broken pipe
+git-annex: fd:17: hPutBuf: resource vanished (Broken pipe)
+```
+
+It happens only sometimes. glacier-cli can upload files without problems. The progress of the file upload is also erratic, it jumps to ~90% and then gets stuck. Can I do something to resolve this?
+
+```
+git-annex version: 5.20140717
+build flags: Assistant Inotify DBus TDFA
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+remote types: git gcrypt bup directory rsync web glacier ddar hook external
+```
+
+I am using glacier-cli from git master.
+"""]]
diff --git a/doc/special_remotes/glacier/comment_15_e9df327e60ad0e69ace7102deef1efd8._comment b/doc/special_remotes/glacier/comment_15_e9df327e60ad0e69ace7102deef1efd8._comment
new file mode 100644
index 0000000000..8b3870ffb5
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_15_e9df327e60ad0e69ace7102deef1efd8._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="tim@5431dd39464df207b7d46d3cf1bc74c82123ac68"
+ nickname="tim"
+ avatar="http://cdn.libravatar.org/avatar/967c2815f001d24b5f9f33300c03ba6f"
+ subject="Archive not found"
+ date="2018-12-18T21:22:54Z"
+ content="""
+For a couple of years already I've been regularly uploading my pictures to glacier through git-annex. After losing my local disk I'm trying to restore my files. However I get these errors:
+
+    $ git annex get . --from glacier
+    get DSC05172.JPG (from glacier...) 
+    glacier: archive 'GPGHMACSHA1--a0c0b35b3c2967e78a012ec95af2a77abf78465a' not found
+    failed
+    get DSC05173.JPG (from glacier...) 
+    glacier: archive 'GPGHMACSHA1--272c741c5dc61a3a45246b55d9777c451425b2bc' not found
+    failed
+    get DSC05173.variant-611a.JPG (from glacier...) 
+    glacier: archive 'GPGHMACSHA1--272c741c5dc61a3a45246b55d9777c451425b2bc' not found
+    failed
+
+No files have been deleted, the glacier bucket still exists and has all its data. Has anything changed in the naming scheme or anything? Or is it possible that this error is masking a different issue?
+"""]]
diff --git a/doc/special_remotes/glacier/comment_16_ceb6a0cc74eea65fa60b58d1d000acf0._comment b/doc/special_remotes/glacier/comment_16_ceb6a0cc74eea65fa60b58d1d000acf0._comment
new file mode 100644
index 0000000000..16e6bdf94a
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_16_ceb6a0cc74eea65fa60b58d1d000acf0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="basak"
+ avatar="http://cdn.libravatar.org/avatar/b85cacece5b347853dc35d97371b9e0c"
+ subject="Re: Archive not found"
+ date="2018-12-18T23:54:27Z"
+ content="""
+@Tim
+
+Sounds like you need https://github.com/basak/glacier-cli/#user-content-cache-reconstruction
+"""]]
diff --git a/doc/special_remotes/glacier/comment_1_fcd856b99dc6b3f9141b65fe639ef76b._comment b/doc/special_remotes/glacier/comment_1_fcd856b99dc6b3f9141b65fe639ef76b._comment
new file mode 100644
index 0000000000..1d6d894339
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_1_fcd856b99dc6b3f9141b65fe639ef76b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c"
+ nickname="Justin"
+ subject="comment 1"
+ date="2013-05-16T00:54:21Z"
+ content="""
+The glacier-cli tool seems to have been abandoned, and there are a number of outstanding issues with it.  boto has a `glacier` tool, but it doesn't seem to include caching, which seems to be something git annex needs.
+
+Looking through the PRs, it seems like we should build a tool specifically tailored to git annex's needs.  It seems that there are at least three of us willing to hack on this if it's in Python.  I'm not sure any of us knows haskell, though...
+"""]]
diff --git a/doc/special_remotes/glacier/comment_2_38fcca87074f6ea31a12569a822aa8c9._comment b/doc/special_remotes/glacier/comment_2_38fcca87074f6ea31a12569a822aa8c9._comment
new file mode 100644
index 0000000000..939832b321
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_2_38fcca87074f6ea31a12569a822aa8c9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="basak"
+ ip="2001:8b0:1c8::2"
+ subject="comment 2"
+ date="2013-05-17T08:35:10Z"
+ content="""
+I'm the glacier-cli author. It is not abandoned!
+
+glacier-cli is supposed to map to Glacier exactly, so that it is compatible with all other tools. Most of the outstanding PRs break this essential behaviour, so I have not merged them. Many of the feature requests and bugs related to the upstream boto library, which is just about the best maintained client library that exists for AWS on any platform (and Amazon have adopted it now, IIRC). I have written appropriate reviews on all the PRs.
+
+If there is specific behaviour that git-annex needs, them I am happy to accept PRs for this, provided that they do not break the ability (and default) for glacier-cli to talk to Glacier natively without an extra layer of interpretation. If an extra layer of interpretation is needed (eg. forbidding duplicate \"keys\"), then this needs to be an option, or wrapped in a separate tool, or written into git-annex's Glacier special remote.
+"""]]
diff --git a/doc/special_remotes/glacier/comment_3_cea5bcb162e4288847ba5f25464a0406._comment b/doc/special_remotes/glacier/comment_3_cea5bcb162e4288847ba5f25464a0406._comment
new file mode 100644
index 0000000000..8a8b914add
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_3_cea5bcb162e4288847ba5f25464a0406._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c"
+ nickname="Justin"
+ subject="comment 3"
+ date="2013-05-19T05:56:45Z"
+ content="""
+Hi!  :)
+
+The main issue I'm hitting is the \"Multiple rows were found for one()\" error.  I think I get this when git-annex tries to upload the same file twice (which may be a bug in git-annex, which could apply de-duplication earlier), but I think I also get it when trying to upload a file whose upload I've canceled in the past.
+
+I don't quite understand what git-annex needs here, and I totally understand that you're writing a general-purpose tool.  But there does seem to be an issue that git-annex needs fixed one way or another.
+
+I'm happy to try fixing it myself if you can help me understand what's going on (I didn't quite understand your review in the PR), but if I'm the only person in the world using git-annex to back up to glacier, that scares me a little!
+
+    copy foo/bar/baz (checking glacier...) Traceback (most recent call last):
+      File \"/home/jlebar/code/glacier-cli/glacier\", line 694, in <module>
+        App().main()
+      File \"/home/jlebar/code/glacier-cli/glacier\", line 680, in main
+        args.func(args)
+      File \"/home/jlebar/code/glacier-cli/glacier\", line 579, in archive_checkpresent
+        last_seen = self.cache.get_archive_last_seen(args.vault, args.name)
+      File \"/home/jlebar/code/glacier-cli/glacier\", line 157, in get_archive_last_seen
+        result = self._get_archive_query_by_ref(vault, ref).one()
+      File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/query.py\", line 2182, in one
+        \"Multiple rows were found for one()\")
+    sqlalchemy.orm.exc.MultipleResultsFound: Multiple rows were found for one()
+
+"""]]
diff --git a/doc/special_remotes/glacier/comment_4_0c92cc82c7ac513130f862391a02d329._comment b/doc/special_remotes/glacier/comment_4_0c92cc82c7ac513130f862391a02d329._comment
new file mode 100644
index 0000000000..2de6632eb3
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_4_0c92cc82c7ac513130f862391a02d329._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="basak"
+ ip="2001:8b0:1c8::2"
+ subject="comment 4"
+ date="2013-05-22T18:10:32Z"
+ content="""
+Let's discuss this in a bug. I've created http://git-annex.branchable.com/bugs/Glacier_remote_uploads_duplicates/
+"""]]
diff --git a/doc/special_remotes/glacier/comment_5_8d1dcb4bf48386314bfb248ea6eeeb68._comment b/doc/special_remotes/glacier/comment_5_8d1dcb4bf48386314bfb248ea6eeeb68._comment
new file mode 100644
index 0000000000..ee535e1f1b
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_5_8d1dcb4bf48386314bfb248ea6eeeb68._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="comment 5"
+ date="2013-06-03T09:03:57Z"
+ content="""
+You are not the only one, Justin. I am just getting into git-annex and I am setting up a glacier remote as I write this.
+"""]]
diff --git a/doc/special_remotes/glacier/comment_6_adb1db354dc4941e4b004e4ba34660d7._comment b/doc/special_remotes/glacier/comment_6_adb1db354dc4941e4b004e4ba34660d7._comment
new file mode 100644
index 0000000000..717060fcb7
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_6_adb1db354dc4941e4b004e4ba34660d7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmZgZuUhZlHpd_AbbcixY0QQiutb2I7GWY"
+ nickname="Jimmy"
+ subject="I know this thread is old but..."
+ date="2013-11-18T00:27:50Z"
+ content="""
+It's working well for me, though I seem to sometimes still hit the duplicate bug listed above.
+"""]]
diff --git a/doc/special_remotes/glacier/comment_7_747e403aac5acaba00e220931e926951._comment b/doc/special_remotes/glacier/comment_7_747e403aac5acaba00e220931e926951._comment
new file mode 100644
index 0000000000..045fb60414
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_7_747e403aac5acaba00e220931e926951._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlq4ClC5EMN1Vq1DpWXAqP5TiDnCK1mSfk"
+ nickname="Jonas"
+ subject="Expected cost for a repository"
+ date="2013-11-24T22:32:16Z"
+ content="""
+Is there a way to estimate the cost of storing a repo on glacier?
+
+I'm especially worried because of the cost of STORE and RETRIEVE requests; there are hundreds of thousands of small files in my annex repo, so that request cost could easily dominate storage cost. Does the glacier remote do anything to minimize the number of objects stored in glacier?
+"""]]
diff --git a/doc/special_remotes/glacier/comment_8_a04bb5f27c1a7cfffe881903f973dbec._comment b/doc/special_remotes/glacier/comment_8_a04bb5f27c1a7cfffe881903f973dbec._comment
new file mode 100644
index 0000000000..4fc8319599
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_8_a04bb5f27c1a7cfffe881903f973dbec._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlhaXbLZQ5uQ6fM2kV0n8bj6IwZjx2CLeM"
+ nickname="Shane"
+ subject="Annex can't find Glacier remote"
+ date="2014-06-26T05:50:38Z"
+ content="""
+I'm setting up git-annex with glacier-cli for the first time.  I have installed git-annex via Yum and glacier-cli according to the instructions on Github.  The `glacier` command is in my path.  I did not set up hooks with Git annex as it appears that using hooks for glacier is no longer required.
+
+Here is my version information for git-annex:
+
+	$ git-annex version
+	git-annex version: 3.20120523
+	local repository version: 3
+	default repository version: 3
+	supported repository versions: 3
+	upgrade supported from repository versions: 0 1 2
+
+When I attempt to add my Glacier remote, here is what I see:
+
+	$ git annex initremote glacier type=glacier keyid=ABCDEFG
+	git-annex: Unknown remote type glacier
+
+Is there something else I need to do in order to correctly install Glacier integration with git-annex?  I'm having trouble finding up-to-date information that describes the installation process.
+"""]]
diff --git a/doc/special_remotes/glacier/comment_9_89c4506e079c299fd098d0fe746d032a._comment b/doc/special_remotes/glacier/comment_9_89c4506e079c299fd098d0fe746d032a._comment
new file mode 100644
index 0000000000..ae8c27ee2c
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_9_89c4506e079c299fd098d0fe746d032a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="that is an ancient version of git-annex, Shane"
+ date="2014-07-02T17:11:24Z"
+ content="""
+The first git-annex release to support glacier without using hooks was 3.20121126.
+"""]]
diff --git a/doc/special_remotes/hook.mdwn b/doc/special_remotes/hook.mdwn
new file mode 100644
index 0000000000..1878aba704
--- /dev/null
+++ b/doc/special_remotes/hook.mdwn
@@ -0,0 +1,112 @@
+This special remote type lets you store content in a remote of your own
+devising, configured via some simple hooks.
+
+It's not recommended to use this remote type when another like [[rsync]]
+or [[directory]] will do. If your hooks are not carefully written, data
+could be lost. 
+
+If you're building a special remote for others to use,
+instead consider building an [[external_special_remote|external]].
+
+## example
+
+Here's a simple example that stores content on clay tablets. If you
+implement this example in the real world, I'd appreciate a tour
+next Apert! :) --[[Joey]]
+
+	# git config annex.cuneiform-store-hook 'tocuneiform < "$ANNEX_FILE" | tablet-writer --implement=stylus --title="$ANNEX_KEY" | tablet-proofreader | librarian --shelve --floor=$ANNEX_HASH_1 --shelf=$ANNEX_HASH_2'
+	# git config annex.cuneiform-retrieve-hook 'librarian --get --floor=$ANNEX_HASH_1 --shelf=$ANNEX_HASH_2 --title="$ANNEX_KEY" | tablet-reader --implement=coffee --implement=glasses --force-monastic-dedication | fromcuneiform > "$ANNEX_FILE"'
+	# git config annex.cuneiform-remove-hook 'librarian --get --floor=$ANNEX_HASH_1 --shelf=$ANNEX_HASH_2 --title="$ANNEX_KEY" | goon --hit-with-hammer'
+	# git config annex.cuneiform-checkpresent-hook 'librarian --find --force-distrust-catalog --floor=$ANNEX_HASH_1 --shelf=$ANNEX_HASH_2 --title="$ANNEX_KEY" --shout-title'
+	# git annex initremote library type=hook hooktype=cuneiform encryption=none
+	# git annex describe library "the reborn Library of Alexandria (upgrade to bronze plates pending)"
+
+Can you spot the potential data loss bugs in the above simple example?
+(Hint: What happens when the `tablet-proofreader` exits nonzero?)
+
+## configuration
+
+These parameters can be passed to `git annex initremote`:
+
+* `hooktype` - Required. This specifies a collection of hooks to use for
+  this remote.
+
+* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
+  See [[encryption]].
+
+* `keyid` - Specifies the gpg key to use for [[encryption]].
+
+* `chunk` - Enables [[chunking]] when storing large files.
+
+## hooks
+
+Each type of hook remote is specified by a collection of hook commands.
+Each hook command is run as a shell command line, and should return nonzero
+on failure, and zero on success.
+
+These environment variables are used to communicate with the hook commands:
+
+* `ANNEX_KEY` - name of a key to store, retrieve, remove, or check.
+* `ANNEX_FILE` - a file containing the key's content
+* `ANNEX_HASH_1` - short stable value, based on the key, can be used for hashing
+  into 1024 buckets.
+* `ANNEX_HASH_2` - another hash value, can be used for a second level of hashing
+
+The settings to use in git config for the hook commands are as follows:
+
+* `annex.$hooktype-store-hook` - Command run to store a key in the special remote.
+  `ANNEX_FILE` contains the content to be stored.
+
+* `annex.$hooktype-retrieve-hook` - Command run to retrieve a key from the special remote.
+  `ANNEX_FILE` is a file that the retrieved content should be written to.
+  The file may already exist with a partial
+  copy of the content (or possibly just garbage), to allow for resuming
+  of partial transfers.
+
+* `annex.$hooktype-remove-hook` - Command to remove a key from the special remote.
+
+* `annex.$hooktype-checkpresent-hook` - Command to check if a key is present
+  in the special remote. Should output the key name to stdout, on its own line,
+  if and only if the key has been actively verified to be present in the
+  special remote (caching presence information is a very bad idea);
+  all other output to stdout will be ignored.
+
+## combined hook program
+
+Rather than setting all of the above hooks, you can write a single
+program that handles everything, and set a single hook to make it be used.
+
+	# git config annex.demo-hook /usr/local/bin/annexdemo
+	# git annex initremote mydemorepo type=hook hooktype=demo encryption=none
+
+But, doing that is deprecated -- it's better, and not much harder,
+to write an [[external_special_remote|external]]!
+
+If you still want to do this, the program just needs to look at the
+`ANNEX_ACTION` environment variable to see what it's being asked to do.
+For example:
+
+[[!format sh """
+#!/bin/sh
+set -e
+case "$ANNEX_ACTION" in
+	store)
+		demo-upload "$ANNEX_HASH_1/$ANNEX_HASH_2/$ANNEX_KEY" < "$ANNEX_FILE"
+	;;
+	retrieve)
+		demo-download "$ANNEX_HASH_1/$ANNEX_HASH_2/$ANNEX_KEY" > "$ANNEX_FILE"
+	;;
+	remove)
+		demo-nuke "$ANNEX_HASH_1/$ANNEX_HASH_2/$ANNEX_KEY"
+	;;
+	checkpresent)
+		if demo-exists "$ANNEX_HASH_1/$ANNEX_HASH_2/$ANNEX_KEY"; then
+			echo "$ANNEX_KEY"
+		fi
+	;;
+	*)
+		echo "unknown ANNEX_ACTION: $ANNEX_ACTION" >&2
+		exit 1
+	;;
+esac
+"""]]
diff --git a/doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment b/doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment
new file mode 100644
index 0000000000..2163ba76d5
--- /dev/null
+++ b/doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="helmut"
+ ip="89.0.176.236"
+ subject="Asynchronous hooks?"
+ date="2012-10-13T09:46:14Z"
+ content="""
+Is there a way to use asynchronous remotes? Interaction with git annex would have to
+split the part of initiating some action from completing it.
+
+I imagine I could `git annex copy` a file to an asynchronous remote and the command
+would almost immediately complete. Later I would learn that the transfer is
+completed, so the hook must be able to record that information in the `git-annex`
+branch. An additional plumbing command seems required here as well as a way to
+indicate that even though the store-hook completed, the file is not transferred.
+
+Similarly `git annex get` would immediately return without actually fetching the
+file. This should already be possible by returning non-zero from the retrieve-hook.
+Later the hook could use plumbing level commands to actually stick the received file
+into the repository.
+
+The remove-hook should need no changes, but the checkpresent-hook would be more like
+a trigger without any actual result. The extension of the plumbing required for the
+extension to the receive-hook could update the location log. A downside here is that
+you never know when a fsck has completed.
+
+My proposal does not include a way to track the completion of actions, but relies on
+the hook to always complete them reliably. It is not clear that this is the best road
+for asynchronous hooks.
+
+One use case for this would be a remote that is only accessible via uucp. Are there
+other use cases? Is the drafted interface useful?
+"""]]
diff --git a/doc/special_remotes/hook/comment_2_ee7c43b93c5b787216334f019643f6a0._comment b/doc/special_remotes/hook/comment_2_ee7c43b93c5b787216334f019643f6a0._comment
new file mode 100644
index 0000000000..ec64dd96d1
--- /dev/null
+++ b/doc/special_remotes/hook/comment_2_ee7c43b93c5b787216334f019643f6a0._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnWvnTWY6LrcPB4BzYEBn5mRTpNhg5EtEg"
+ nickname="Bence"
+ subject="More environment variables"
+ date="2013-07-09T10:28:58Z"
+ content="""
+Could you please include the original filename+path in the environment variables (_next to ANNEX_KEY & ANNEX_FILE_)? Like ANNEX_FILENAME and ANNEX_PATH.
+
+Having these infos in a hook would help eg. a flickr backend to be more usefull. [Tags](http://www.flickr.com/help/tags/) would contain the ANNEX_KEY and the image title could be the original filename (ANNEX_FILENAME). Also, having directory path (ANNEX_PATH) for the given file, the uploading process could put images into the proper sets/collections. Voila, you have a \"filesystem based\" flickr image gallery (almost like flickrfs).
+
+Other backends, like AmazonS3 having [meta data](http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html) also could benefit from this. 
+
+To build the Death Star further, an _annex.$hooktype-**sync**-hook_ would instruct the backend to sync data, eg. place or move images/files in the proper image-sets/directories after they are moved/repositioned in git-annex, but that would be the backend's job, not git-annex's. Maybe the sync-hook would be called when _git annex sync_ is called. This is just an idea.
+
+While writing this, a new hook for sharing came into my mind: _annex.$hooktype-**share**-hook_.
+Calling this on a file/directory (_git annex share my_image_to_share.jpg_) would return a publicly shareable (short)url pointing to the file/directory. This would work for web-backends like AmazonS3, flickr, DropBox, Google Drive, ...
+"""]]
diff --git a/doc/special_remotes/hook/comment_3_2593291795e732994862d08bf2ed467b._comment b/doc/special_remotes/hook/comment_3_2593291795e732994862d08bf2ed467b._comment
new file mode 100644
index 0000000000..0f8c802547
--- /dev/null
+++ b/doc/special_remotes/hook/comment_3_2593291795e732994862d08bf2ed467b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA"
+ nickname="Tobias"
+ subject="comment 3"
+ date="2013-07-09T10:54:58Z"
+ content="""
+I have requested this before. But it doesn't seem to be entirely doable because some items may have multiple equally correct filenames/paths. And some items may have zero filenames/paths.
+
+That said I hope a solution can be found because I really want this feature too. And would implement it in all my hooks.
+
+And for some of the cases i don't really see it as an issue. If you have a public flickr repo with clean(unencrypted) files. It is because you want to access existing files. If an object has no filename/path the hook could/would/should just ignore the file, sure this means no backup of old versions of files, but you can have other backends for those versions.
+
+The bigger issue is with the same file existing multiple places in the annex, which filename/path should be used? And the filename/path can change between sync(if it is deleted from one of the positions). I personally still see this as being entirely doable. The key for downloading would always be the same, so worst case scenario is the image may be duplicated on flickr. Or that the picture only one of the multiple folders it should be in on flickr. Still, i see these issues as being minor, and that usability would increase if this was implemented, even with these caveats.
+
+And there probably is some issues I haven't realized/know about.
+
+"""]]
diff --git a/doc/special_remotes/hook/comment_4_35d79b5ffa5a19056efcdc805070bc4b._comment b/doc/special_remotes/hook/comment_4_35d79b5ffa5a19056efcdc805070bc4b._comment
new file mode 100644
index 0000000000..988d17def0
--- /dev/null
+++ b/doc/special_remotes/hook/comment_4_35d79b5ffa5a19056efcdc805070bc4b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnWvnTWY6LrcPB4BzYEBn5mRTpNhg5EtEg"
+ nickname="Bence"
+ subject="checkpresent success and failure"
+ date="2013-07-31T13:06:21Z"
+ content="""
+What value should be returned in the \"checkpresent-hook\" to signal that the given file does not exist in the given backend? 
+
+Should the called hook process return an exit code less or greater then zero? In this case the following is displayed: 
+>(user error (sh [\"-c\",\"name_of_the_process\"] exited 1)) failed
+
+This tells that the process failed (no internet connection or something that prevents the process from doing its job) and not that result is false, which would mean the file/entry does not exist in the given backend.
+If the return code is zero the file is treated as existing file/entry (no matter what I write to stderr).
+
+Also I think, the \"checkpresent\" block misses the ending ;; in the example.
+
+Here is my work-in-progress hook: https://gist.github.com/parhuzamos/31bf4516eea434e0d248
+"""]]
diff --git a/doc/special_remotes/hook/comment_5_6fbf1e963fa3ea4b2eb8ca5a3819762d._comment b/doc/special_remotes/hook/comment_5_6fbf1e963fa3ea4b2eb8ca5a3819762d._comment
new file mode 100644
index 0000000000..a4c7b525e9
--- /dev/null
+++ b/doc/special_remotes/hook/comment_5_6fbf1e963fa3ea4b2eb8ca5a3819762d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 5"
+ date="2013-07-31T16:25:55Z"
+ content="""
+The checkpresent hook should always exit 0 unless there was an exceptional condition (eg, perhaps it cannot check if the file exists one way or the other). Like the documentation for it says, the important thing is what it outputs to stdout, which should contain the key name if it's present, and should not contain the key name if it's not present.
+
+I hope you post to this website about your special remote when you get it fully working!
+"""]]
diff --git a/doc/special_remotes/hook/comment_6_e0ab48d5333e5de85f016b097e6fdac1._comment b/doc/special_remotes/hook/comment_6_e0ab48d5333e5de85f016b097e6fdac1._comment
new file mode 100644
index 0000000000..e7c218f575
--- /dev/null
+++ b/doc/special_remotes/hook/comment_6_e0ab48d5333e5de85f016b097e6fdac1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnWvnTWY6LrcPB4BzYEBn5mRTpNhg5EtEg"
+ nickname="Bence"
+ subject="comment 6"
+ date="2013-07-31T17:34:50Z"
+ content="""
+Roger that.
+
+If this is acceptable: [terminal output screenshot](http://i.imgur.com/lsJJYwF.png), than I'm almost done and will publish soon.
+(Of course a REST API using client would much be better, but this is just the start.)
+
+"""]]
diff --git a/doc/special_remotes/hook/comment_7_cc2b1243c2c36e63241513bcaddfea67._comment b/doc/special_remotes/hook/comment_7_cc2b1243c2c36e63241513bcaddfea67._comment
new file mode 100644
index 0000000000..68cdf6545a
--- /dev/null
+++ b/doc/special_remotes/hook/comment_7_cc2b1243c2c36e63241513bcaddfea67._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 7"
+ date="2013-07-31T17:42:22Z"
+ content="""
+If I were you I'd suppress that \"File not found\" error.
+
+Hook special remotes *can* output messages to stderr, and it's also fine to output eg, progress bars to stdout when seding/receving files. But unnecessary cluttery output should be avoided.
+"""]]
diff --git a/doc/special_remotes/hook/comment_8_bbae315233bda48eb04662dfd48cf1ae._comment b/doc/special_remotes/hook/comment_8_bbae315233bda48eb04662dfd48cf1ae._comment
new file mode 100644
index 0000000000..81cc325116
--- /dev/null
+++ b/doc/special_remotes/hook/comment_8_bbae315233bda48eb04662dfd48cf1ae._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnWvnTWY6LrcPB4BzYEBn5mRTpNhg5EtEg"
+ nickname="Bence"
+ subject="checkpresent again"
+ date="2013-08-01T23:18:38Z"
+ content="""
+In the current [HEAD](https://github.com/joeyh/git-annex/commit/bb74db6ef094324062adcf26a677113ee6fd0e58) the \"checkpresent\" method in [Hook.hs](https://github.com/joeyh/git-annex/blob/master/Remote/Hook.hs#L145) is missing a \"return\" while other hooks have a return value eg. [Directory.hs](https://github.com/joeyh/git-annex/blob/master/Remote/Directory.hs#L241), [Rsync.hs](https://github.com/joeyh/git-annex/blob/master/Remote/Rsync.hs#L272), ...
+
+
+I noticed that if my *checkpresent* hook does not output anything (to be exact: I commented out all the lines in the block) it behaves strangely. I copied the test file to \"copyrepo\", removed it by hand (so git-annex does not know about the change) and executed a fsck.
+
+    ~/annex5/test1/123 $ git annex fsck --from copyrepo --fast
+    fsck somefile.1 (checking copyrepo...) (fixing location log) 
+      ** Based on the location log, somefile.1
+      ** was expected to be present, but its content is missing.
+    failed
+
+running the check again
+
+    ~/annex5/test1/123 $ ga fsck --from copyrepo --fast
+    fsck somefile.1 (checking copyrepo...) ok
+
+and running the check again without --fast
+
+    ~/annex5/test1/123 $ ga fsck --from copyrepo
+    fsck somefile.1 (checking copyrepo...) ok
+
+It thinks, the file is in the repo but it is not.
+
+"""]]
diff --git a/doc/special_remotes/hook/comment_9_037523d1994c702239ca96791156fe65._comment b/doc/special_remotes/hook/comment_9_037523d1994c702239ca96791156fe65._comment
new file mode 100644
index 0000000000..89719adfb5
--- /dev/null
+++ b/doc/special_remotes/hook/comment_9_037523d1994c702239ca96791156fe65._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.145"
+ subject="comment 9"
+ date="2013-08-01T23:51:48Z"
+ content="""
+The behavior you show with `fsck --from` is that the first time it's run against the damaged remote it notices the file is not present using the checkpresent hook. It then updates the location log. The subsequent times it's run, it sees that the location log says the file is not present in the remote. It verifies this is the case by calling the checkpresent hook. Since the two data sources agree, and numcopies is still satisfied, it prints \"ok\". There does not seem to be a bug here.
+
+(`return` in Haskell does not do what you would expect to happen in a traditional imperative language. It does not alter control flow, and any function using `return` can be mechanically converted to one that does not use `return`.)
+"""]]
diff --git a/doc/special_remotes/httpalso.mdwn b/doc/special_remotes/httpalso.mdwn
new file mode 100644
index 0000000000..b2805c366d
--- /dev/null
+++ b/doc/special_remotes/httpalso.mdwn
@@ -0,0 +1,38 @@
+This special remote allows downloading annexed objects from other special 
+remotes that also publish their content by http. Not to be confused with
+the [[web]] special remote, or with 
+[[accessing git-annex repositories over http|tips/setup_a_public_repository_on_a_web_site]],
+this is only useful in combination with some other special remote.
+
+Suppose, for example, that you have a [[directory]] special remote. And the
+directory happens to be published by a web server. (Or it could be a
+[[rsync]] special remote, or many other kinds.) To let git-annex know that
+the content of this special remote can also be accessed over http, set up
+a httpalso special remote.
+
+	git annex initremote --sameas=foo foo-http type=httpalso url=http://example.com/foo
+
+The --sameas parameter tells git-annex what other special remote this httpalso
+remote is accessing. (See [[tips/multiple_remotes_accessing_the_same_data_store]].)
+Since the httpalso remote is read-only, it can only be used to download
+content that is stored in that other remote.
+
+This special remote is compatible with many, but not all, other special
+remotes. If the special remote does something unusual with the name
+a file is stored under, or with how the data is stored, it might not work.
+See [[tips/multiple_remotes_accessing_the_same_data_store]]
+for a list of known working combinations.
+
+## configuration
+
+* `url` - The http or https url to where the content is stored by the
+  other special remote.
+* `exporttree` - If the other special remote has `exporttree=yes` set,
+  it also needs to be set when initializing the httpalso remote.
+  Setting this does not allow trees to be exported to the httpalso remote,
+  because it's read-only. But it does let exported files be downloaded
+  from it.
+
+Configuration of encryption and chunking is inherited from the other
+special remote, and does not need to be specified when initializing the
+httpalso remote.
diff --git a/doc/special_remotes/httpalso/comment_1_128e53b20a2f01bf55c83d52c4d42e93._comment b/doc/special_remotes/httpalso/comment_1_128e53b20a2f01bf55c83d52c4d42e93._comment
new file mode 100644
index 0000000000..f3ad736d2c
--- /dev/null
+++ b/doc/special_remotes/httpalso/comment_1_128e53b20a2f01bf55c83d52c4d42e93._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="tomdhunt"
+ avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
+ subject="comment 1"
+ date="2021-03-20T05:31:26Z"
+ content="""
+Is it possible to use httpalso with a standard git remote that also runs git-annex?
+
+Also, does it support HTTP authentication?
+"""]]
diff --git a/doc/special_remotes/httpalso/comment_2_aeeb2122814552f9cf83d950995b16ba._comment b/doc/special_remotes/httpalso/comment_2_aeeb2122814552f9cf83d950995b16ba._comment
new file mode 100644
index 0000000000..90cd450ffd
--- /dev/null
+++ b/doc/special_remotes/httpalso/comment_2_aeeb2122814552f9cf83d950995b16ba._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 2"
+ date="2021-03-20T17:48:47Z"
+ content="""
+I guess it could work by pointing the httpalso remote directly at the git-annex object store at `.git/annex/objects`.
+"""]]
diff --git a/doc/special_remotes/httpalso/comment_3_1c9384afe2779ab6c6ae689deea37b31._comment b/doc/special_remotes/httpalso/comment_3_1c9384afe2779ab6c6ae689deea37b31._comment
new file mode 100644
index 0000000000..c0e570a68a
--- /dev/null
+++ b/doc/special_remotes/httpalso/comment_3_1c9384afe2779ab6c6ae689deea37b31._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 3"
+ date="2021-03-20T17:55:42Z"
+ content="""
+Actually, no need to use httpalso at all. According to [[this|tips/setup_a_public_repository_on_a_web_site/]], it will just work.
+"""]]
diff --git a/doc/special_remotes/httpalso/comment_4_0bf4d78dec7ec997f781c5a46460b27b._comment b/doc/special_remotes/httpalso/comment_4_0bf4d78dec7ec997f781c5a46460b27b._comment
new file mode 100644
index 0000000000..a8a15a05c3
--- /dev/null
+++ b/doc/special_remotes/httpalso/comment_4_0bf4d78dec7ec997f781c5a46460b27b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-03-22T14:23:21Z"
+ content="""
+@tomdhunt I think it could probably be used with a git remote that exported
+its .git files over http, but since git-annex supports using such a remote
+as a normmal git remote, there does not seem to be any point in using it
+that way.
+
+http authentication is not currently supported, I suppose it could be added
+if useful, file a [[todo]] if you have a use case.
+"""]]
diff --git a/doc/special_remotes/httpalso/comment_5_500374b5826e87293dbd4e3aae570185._comment b/doc/special_remotes/httpalso/comment_5_500374b5826e87293dbd4e3aae570185._comment
new file mode 100644
index 0000000000..95aa39806e
--- /dev/null
+++ b/doc/special_remotes/httpalso/comment_5_500374b5826e87293dbd4e3aae570185._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="chunking"
+ date="2023-06-20T10:21:35Z"
+ content="""
+Hi Joey,
+
+Another question: could the httpalso special remote be made to support mirroring remotes that enable chunking (with chunk=xxMiB)? This would in general allow anonymous access to e.g. webdav shares also published over https.
+
+Best,
+KDM
+"""]]
diff --git a/doc/special_remotes/httpalso/comment_6_ee2c2a34e11bbbac835be7660830e298._comment b/doc/special_remotes/httpalso/comment_6_ee2c2a34e11bbbac835be7660830e298._comment
new file mode 100644
index 0000000000..1a1155ce81
--- /dev/null
+++ b/doc/special_remotes/httpalso/comment_6_ee2c2a34e11bbbac835be7660830e298._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-06-20T17:24:43Z"
+ content="""
+I've made it support chunking.
+
+(Please in the future post to [[todo]] rather than making a comment when
+you have a new feature to suggest.)
+"""]]
diff --git a/doc/special_remotes/httpalso/comment_7_cea7241b64264f3485e6759b9dc0dfaf._comment b/doc/special_remotes/httpalso/comment_7_cea7241b64264f3485e6759b9dc0dfaf._comment
new file mode 100644
index 0000000000..6f11f816f8
--- /dev/null
+++ b/doc/special_remotes/httpalso/comment_7_cea7241b64264f3485e6759b9dc0dfaf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="comment 7"
+ date="2023-06-21T07:34:18Z"
+ content="""
+Phenomenal, many many thanks Joey. Any chance of a new release/build that includes this change in the coming couple of weeks? And apologies for the misuse of comments -- I'll use todo in future.
+"""]]
diff --git a/doc/special_remotes/httpalso/comment_8_a5198f57b7eb6c458d5e88f8fc9776fa._comment b/doc/special_remotes/httpalso/comment_8_a5198f57b7eb6c458d5e88f8fc9776fa._comment
new file mode 100644
index 0000000000..6f19f5ff47
--- /dev/null
+++ b/doc/special_remotes/httpalso/comment_8_a5198f57b7eb6c458d5e88f8fc9776fa._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-06-21T15:40:53Z"
+ content="""
+@kdm some of the hourly autobuilds are updated with it already, eg the
+x86-64 linux one. Others should update today. I do hope to make a release
+soon.
+"""]]
diff --git a/doc/special_remotes/ipfs.mdwn b/doc/special_remotes/ipfs.mdwn
new file mode 100644
index 0000000000..828300212b
--- /dev/null
+++ b/doc/special_remotes/ipfs.mdwn
@@ -0,0 +1,84 @@
+This special remote stores file contents in [ipfs](http://ipfs.io/).
+
+Warning: ipfs is written in Go, a language controlled by Google, which
+collects user's data with its compiler. If installing ipfs from source
+you should consider investigating how to disable Go's data collection.
+Or install precompiled ipfs from a software distributor you trust.
+
+## prerequisites
+
+* Install [[external/git-annex-remote-ipfs]] somewhere in PATH
+  and `chmod +x` the script.
+* Install [go-ipfs](https://github.com/jbenet/go-ipfs) somewhere in PATH.
+* Run `ipfs init` and start the `ipfs daemon`
+
+(Note that this special remote does not use ipfs's FUSE support; it
+communicates with ipfs using the `ipfs` command-line utility.)
+
+## configuration
+
+These parameters can be passed to `git annex initremote` to configure the
+remote:
+
+* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
+  See [[encryption]]. Note that this is git-annex's encryption, not ipfs's
+  encryption.
+
+* `keyid` - Specifies the gpg key to use for [[encryption]].
+
+Setup example:
+
+	# git annex initremote ipfs type=external externaltype=ipfs encryption=none
+
+## content distribution
+
+After `git annex copy --to ipfs`, a file will typically only have
+been copied to your computer's local ipfs object store. It will not reach
+other ipfs nodes on the network until they request the content.
+
+If you set up a clone of your repository on another computer, and install
+ipfs and enable the ipfs remote there, you can proceed with using it to get
+files that have been stored in ipfs:
+
+	# git annex sync
+	# git annex enableremote ipfs
+	# git annex copy --from ipfs
+
+## content removal
+
+Removing content from ipfs requires all nodes that have a copy to decide to
+delete it. This is not something git-annex can arrange to happen, or
+reliably tell has happened, so `git annex drop --from ipfs` will always fail.
+
+## using ipfs addresses
+
+Once a file has been copied to ipfs, you can use `git annex whereis`
+to look up the ipfs address of the file:
+
+	# git annex whereis somefile
+	whereis somefile
+		ed1c811d-fe42-4436-aa75-56566c990aa8 -- ipfs
+	
+	ipfs: ipfs:QmYgXEfjsLbPvVKrrD4Hf6QvXYRPRjH5XFGajDqtxBnD4W
+
+In the example above, the ipfs address for the file is
+`QmYgXEfjsLbPvVKrrD4Hf6QvXYRPRjH5XFGajDqtxBnD4W`. You can give this
+address to any other ipfs user and they can use it to download the file!
+
+You can also use ipfs addresses with `git annex addurl`. For example:
+
+	# git annex addurl ipfs:QmYgXEfjsLbPvVKrrD4Hf6QvXYRPRjH5XFGajDqtxBnD4W --file somefile
+
+That's a real file; try it!
+
+## future directions
+
+While perhaps useful, this is just a proof of concept. It's particularly
+lacking in that it doesn't integrate well git-annex's [[location_tracking]]
+with ipfs. 
+
+Tracking which ipfs nodes have a copy of an annexed object
+would make this special remote work better. In particular, git-annex does
+not currently trust ipfs to contain a copy of an object, since it has no
+way of keeping track of which which ipfs nodes might contain it. So, eg, 
+`git annex drop` will refuse to trust ipfs.
diff --git a/doc/special_remotes/ipfs/comment_10_9fe1bef94c60fb47cad8b80b0cf0d722._comment b/doc/special_remotes/ipfs/comment_10_9fe1bef94c60fb47cad8b80b0cf0d722._comment
new file mode 100644
index 0000000000..654c9ef5d2
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_10_9fe1bef94c60fb47cad8b80b0cf0d722._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="IPFS Deduplication"
+ date="2017-10-07T19:46:12Z"
+ content="""
+IPFS now has an experimental feature for not duplicating file content in the ipfs store, which could be very helpful for this use.  See description at [[https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-284337564]] .
+
+To use this, git-annex needs to pass the `--nocopy` flag when running `ipfs add`.
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_12_1e38459dccd1ef3e23335e9bebca3241._comment b/doc/special_remotes/ipfs/comment_12_1e38459dccd1ef3e23335e9bebca3241._comment
new file mode 100644
index 0000000000..eae3b62fe1
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_12_1e38459dccd1ef3e23335e9bebca3241._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="comment 12"
+ date="2022-02-19T07:50:53Z"
+ content="""
+addendum: note that filecoin itself is not permanent, the server needs to keep recreating deals for the data. a permanent solution would be something like arweave, a permastorage blockchain with tools, which is one of the solutions i found in the ethereum storage docs.
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_12_5f8f72a832c8439e3769a1199dc46c4e._comment b/doc/special_remotes/ipfs/comment_12_5f8f72a832c8439e3769a1199dc46c4e._comment
new file mode 100644
index 0000000000..ba50beffdd
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_12_5f8f72a832c8439e3769a1199dc46c4e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="free dweb storage services"
+ date="2022-02-19T07:47:28Z"
+ content="""
+ipfs appears to be running some free storage services for large files on ipfs backed by filecoin.
+https://nft.storage/ and htps://web3.storage/ are both presently ostensibly free and permanent and have cli interfaces to upload to them.
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_13_551c4dc55b73d6f07c4ddee546b5e938._comment b/doc/special_remotes/ipfs/comment_13_551c4dc55b73d6f07c4ddee546b5e938._comment
new file mode 100644
index 0000000000..041c9504e0
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_13_551c4dc55b73d6f07c4ddee546b5e938._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2022-02-21T18:54:04Z"
+ content="""
+@xloem I'm not sure how services that have CLI interfaces to upload
+files to them, and then presumably pin them in IPFS are relevant to this
+IPFS special remote?
+
+Your history of good comments is keeping me from deleting the above 2 as
+spam, but...
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_14_8cfb0f54444e78089837e62502ef9f61._comment b/doc/special_remotes/ipfs/comment_14_8cfb0f54444e78089837e62502ef9f61._comment
new file mode 100644
index 0000000000..7d0b0a4cd0
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_14_8cfb0f54444e78089837e62502ef9f61._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2022-02-21T19:53:58Z"
+ content="""
+<https://nft.storage/terms/> claims this is limited to NFTs and not other
+data. (Whatever that means; why can't I mint a NFT for a nice gpg encrypted
+blob?)
+
+I also doubt it actually will store anything for longer than the current
+NFT mania; the terms have a loophole that allow them to provide 90 days
+notice before ending the service.
+
+It does have an API if someone wants to build a special remote and use it
+for general data storage. But that's out of scope for this IPFS special
+remote AFAICS.
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_15_82b398be82a0b4ec7765606352ec0942._comment b/doc/special_remotes/ipfs/comment_15_82b398be82a0b4ec7765606352ec0942._comment
new file mode 100644
index 0000000000..0ebd9143a9
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_15_82b398be82a0b4ec7765606352ec0942._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="comment 15"
+ date="2023-04-11T18:03:26Z"
+ content="""
+sorry for the comments that could come across as marketing or spam
+
+i am often in a situation where i have nowhere to back files up, so simply appreciated the free services and thought others might need something similar as well
+
+their terms may have changed by now, not sure. they helped me a lot at the time. i'm now using arweave for doing similar free things, which has a custom protocol but is intended to never kick data out. node2.bundlr.network provides free \"bundlr\" arweave storage for objects 100,000 bytes or smaller.
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_16_331655ed1b7ebb02444aa693b551e728._comment b/doc/special_remotes/ipfs/comment_16_331655ed1b7ebb02444aa693b551e728._comment
new file mode 100644
index 0000000000..fb05cb11ce
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_16_331655ed1b7ebb02444aa693b551e728._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="comment 16"
+ date="2023-04-11T18:07:04Z"
+ content="""
+i had written a hacky special remote for web3.storage at https://github.com/xloem/gitlakepy/blob/master/scripts/git-annex-remote-w3-subprocess but it was kind of flaky, wrapped the cli tool.
+
+i guess arweave isn't relevant here for ipfs. the support for ipfs is nice with w3.storage because you can download things with the ipfs url without requiring the special remote installed.
+
+i have cognitive decline, haven't found recovery from political trafficking, so depending on how my life goes i may make more and more spammy expressions. feel free to clean them up, and thank you for commenting on this one.
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_1_d1b2da148715476015716a2f866558b9._comment b/doc/special_remotes/ipfs/comment_1_d1b2da148715476015716a2f866558b9._comment
new file mode 100644
index 0000000000..ea56ab66bb
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_1_d1b2da148715476015716a2f866558b9._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="about copying to the local store"
+ date="2015-03-07T13:16:02Z"
+ content="""
+there's a [discussion](https://github.com/jbenet/go-ipfs/issues/875) happening upstream about how copying to the local datastore could be avoided.
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_2_564271a8660d7bbade6e4ed396fcfb57._comment b/doc/special_remotes/ipfs/comment_2_564271a8660d7bbade6e4ed396fcfb57._comment
new file mode 100644
index 0000000000..426c21cb3d
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_2_564271a8660d7bbade6e4ed396fcfb57._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="rob.syme@92895c98b16fd7a88bed5f10913c522ebfd76c31"
+ nickname="rob.syme"
+ subject="Finding IPFS hash"
+ date="2015-05-26T04:55:32Z"
+ content="""
+I'm using git-annex version: 5.20150522-gb199d65
+
+The example above gives the ipfs hash for the file, but when I run whereis, the hash is not reported:
+
+    $ git annex whereis test.txt
+    whereis test.txt (2 copies) 
+            1bd0f840-2247-4888-9237-596515788671 -- rob@rob-G60JX:/tmp/gitannextest [here]
+            adf361b3-7b1a-43e1-8360-937f7e436e90 -- [ipfs]
+    ok
+
+Is there a way for git-annex to report the file's ipfs hash ID?
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_3_b8c7e402e0ee63d659ae33e3e2504ca2._comment b/doc/special_remotes/ipfs/comment_3_b8c7e402e0ee63d659ae33e3e2504ca2._comment
new file mode 100644
index 0000000000..b2161ae107
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_3_b8c7e402e0ee63d659ae33e3e2504ca2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="rob.syme@92895c98b16fd7a88bed5f10913c522ebfd76c31"
+ nickname="rob.syme"
+ subject="Finding IPFS hash"
+ date="2015-05-26T05:08:38Z"
+ content="""
+I see now that git-annex only reports the ipfs hash when the remote is unencrypted. It the ipfs hash not reported for encrypted ipfs remotes for security reasons?
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_4_06611859079239659ba7d73d655f517e._comment b/doc/special_remotes/ipfs/comment_4_06611859079239659ba7d73d655f517e._comment
new file mode 100644
index 0000000000..6955bfe163
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_4_06611859079239659ba7d73d655f517e._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-05-27T19:02:30Z"
+ content="""
+@rob.syme, the reason that does not work when using encryption
+is that git-annex internally generates an encrypted key, and stores
+that on IPFS. The ipfs special remote records the IPFS address
+that can be used for a key, but it's recorded on the encrypted
+key, which is not the one you're querying with whereis.
+
+This is a general problem with git-annex; ipfs is probably the
+first special remote that exposes the problem.
+
+Anyway, I'm not sure what benefit knowing the IPFS address of a file
+encrypted by git-annex is. You need to use git-annex to decrypt it, in
+general. You might be able to use your gpg key to decrypt it, if the
+special remote was set up using pubkey encryption, but that's not going to
+help anyone else you give the IPFS address to access the encrypted data..
+
+Does your use case involve pinning the IPFS address, or something like
+that?
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_5_ba7d08b2bcb6614102c48b4cb3de5b1a._comment b/doc/special_remotes/ipfs/comment_5_ba7d08b2bcb6614102c48b4cb3de5b1a._comment
new file mode 100644
index 0000000000..e8102ff246
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_5_ba7d08b2bcb6614102c48b4cb3de5b1a._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="rob.syme@92895c98b16fd7a88bed5f10913c522ebfd76c31"
+ nickname="rob.syme"
+ subject="Finding IPFS hash"
+ date="2015-11-18T14:55:33Z"
+ content="""
+The use case is only very silly - I just wanted to look directly at the data stored at that IPFS hash - it was not important and certainly not worth changing the way git-annex stores its keys.
+
+On a new machine with a new version of git-annex, I can no longer initialize a new IFPS remote:
+
+    ⟫ ipfs version
+    ipfs version 0.3.10-dev
+
+    ⟫ git annex version
+    git-annex version: 5.20151116-gbe86081
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput DNS Feeds Quvi TDFA TorrentParser Database
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+    ⟫ git annex initremote ipfs type=external externaltype=ipfs encryption=none
+    initremote ipfs 
+    git-annex: git-annex-remote-ipfs: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
+    failed
+    git-annex: initremote: 1 failed
+
+It looks like I'm missing a binary somewhere, but I'm not sure which one is missing.
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_6_8621bbd87982f73cf401cfa09d95d1e4._comment b/doc/special_remotes/ipfs/comment_6_8621bbd87982f73cf401cfa09d95d1e4._comment
new file mode 100644
index 0000000000..4d547ea3b1
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_6_8621bbd87982f73cf401cfa09d95d1e4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2015-11-18T16:22:51Z"
+ content="""
+@rob.syme I think that error message is pretty clear: git-annex-remote-ipfs
+is not present in your PATH or perhaps is not executable.
+
+(Still, the error message could be improved a bit, doing that now.)
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_7_062f266f26b5788b418de6955bff442d._comment b/doc/special_remotes/ipfs/comment_7_062f266f26b5788b418de6955bff442d._comment
new file mode 100644
index 0000000000..29b370a68d
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_7_062f266f26b5788b418de6955bff442d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="rob.syme@92895c98b16fd7a88bed5f10913c522ebfd76c31"
+ nickname="rob.syme"
+ subject="git-annex-remote-ipfs"
+ date="2015-11-19T14:46:03Z"
+ content="""
+Silly me - I messed up my bashrc. Fixed now, thanks!
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_8_eedf260df630192b49557bfc84c9ce82._comment b/doc/special_remotes/ipfs/comment_8_eedf260df630192b49557bfc84c9ce82._comment
new file mode 100644
index 0000000000..62a67913cd
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_8_eedf260df630192b49557bfc84c9ce82._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="git remote"
+ date="2016-03-24T14:15:06Z"
+ content="""
+there is now a [git remote for IPFS](https://github.com/cryptix/git-remote-ipfs). I *believe* it suffers from the same problem as all files within ipfs, namely that the contents are duplicated inside the repo. However, it certainly make for an interesting decentralised way of sharing metadata. --[[anarcat]]
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_9_630964c11465751773d1082e35737e70._comment b/doc/special_remotes/ipfs/comment_9_630964c11465751773d1082e35737e70._comment
new file mode 100644
index 0000000000..719f5e1940
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_9_630964c11465751773d1082e35737e70._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="fiatjaf"
+ avatar="http://cdn.libravatar.org/avatar/b760f503c84d1bf47322f401066c753f"
+ subject="comment 9"
+ date="2017-07-10T13:08:53Z"
+ content="""
+There's now a service that pins your IPFS files for a low price: [https://www.eternum.io/](https://www.eternum.io/), I was looking for something like this to start using IPFS with git-annex. Maybe I'll do try now.
+"""]]
diff --git a/doc/special_remotes/rclone.mdwn b/doc/special_remotes/rclone.mdwn
new file mode 100644
index 0000000000..d8d058e9a7
--- /dev/null
+++ b/doc/special_remotes/rclone.mdwn
@@ -0,0 +1,37 @@
+[rclone](https://rclone.org/) is a command line program to sync files and
+directories to and from a vast variety of cloud provider and protocols. At
+the time of writing, this includes the following services:
+
+  * Amazon S3 / Dreamhost / Ceph / Minio / Wasabi
+  * Backblaze B2
+  * Box
+  * Dropbox
+  * FTP
+  * Google Cloud Storage
+  * Google Drive
+  * HTTP
+  * Hubic
+  * Jottacloud
+  * Mega
+  * Microsoft Azure Blob Storage
+  * Microsoft OneDrive
+  * OpenDrive
+  * Openstack Swift / Rackspace cloud files / Memset Memstore / OVH / Oracle Cloud Storage
+  * pCloud
+  * QingStor
+  * SFTP
+  * Webdav / Owncloud / Nextcloud
+  * Yandex Disk
+  * The local filesystem
+
+That list is regularly expanding. 
+
+There are two ways to use rclone as a git-annex special remote.
+
+1. Install [git-annex-remote-rclone](https://github.com/DanielDent/git-annex-remote-rclone).
+   This will work with any versions of rclone and git-annex.
+2. With a recent version of rclone and git-annex, it is not necessary to
+   install anything else, just use `git-annex initremote type=rclone ...`
+
+   For documentation on using rclone that way, see the output of
+   `rclone gitannex -h` or [here](https://github.com/rclone/rclone/blob/master/cmd/gitannex/gitannex.md).
diff --git a/doc/special_remotes/rclone/comment_1_3fa761ad2e7a87e160b6d0e86814801c._comment b/doc/special_remotes/rclone/comment_1_3fa761ad2e7a87e160b6d0e86814801c._comment
new file mode 100644
index 0000000000..c698e2154a
--- /dev/null
+++ b/doc/special_remotes/rclone/comment_1_3fa761ad2e7a87e160b6d0e86814801c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="oadams"
+ avatar="http://cdn.libravatar.org/avatar/ac166a5f89f10c4108e5150015e6751b"
+ subject="Need for git-annex-remote-rclone"
+ date="2024-03-14T01:03:46Z"
+ content="""
+In order to use rclone as a special remote, the user needs to download a separate Bash scriptfrom https://github.com/DanielDent/git-annex-remote-rclone and put it in their PATH. Since that extra dependency is only a few hundred lines of Bash, I would be interested in attempting to implement `Remote/Rclone.hs` so that the rclone special remote is entirely built into git-annex. However, I wanted to run it by you before more seriously considering investing time in doing that. What are your thoughts on this? I'm assuming the only reason rclone support isn't built into git-annex is just a lack of time and incentive, rather than a more fundamental technical reason. Is that right?
+
+Thanks for all your work on this tool. 
+"""]]
diff --git a/doc/special_remotes/rclone/comment_2_e5babe3bc4535946ee04e8339403fda4._comment b/doc/special_remotes/rclone/comment_2_e5babe3bc4535946ee04e8339403fda4._comment
new file mode 100644
index 0000000000..084df436a2
--- /dev/null
+++ b/doc/special_remotes/rclone/comment_2_e5babe3bc4535946ee04e8339403fda4._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Need for git-annex-remote-rclone"""
+ date="2024-03-22T15:01:43Z"
+ content="""
+That's right, I have actually thought before that enough people use it that
+it would make sense to either build it in as haskell or ship the program
+with git-annex in a kind of contrib.
+
+With that said, there is also something to be said for distributing
+maintenance, and I think I'd at least want a committment to maintain it if
+it were added to git-annex, since git-annex-remote-rclone already has
+ongoing maintenance.
+
+Another angle is [[forum/New_external_special_remote_for_rclone]] which
+might see the special remote built into rclone itself, and so able to take
+advantage of rclone's internal API. That might supplant the shell script if
+it turns out to be better.
+"""]]
diff --git a/doc/special_remotes/rclone/comment_3_d946b28311da5e3632c651f52357a2c1._comment b/doc/special_remotes/rclone/comment_3_d946b28311da5e3632c651f52357a2c1._comment
new file mode 100644
index 0000000000..2ecffcaf68
--- /dev/null
+++ b/doc/special_remotes/rclone/comment_3_d946b28311da5e3632c651f52357a2c1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="oadams"
+ avatar="http://cdn.libravatar.org/avatar/ac166a5f89f10c4108e5150015e6751b"
+ subject="comment 3"
+ date="2024-04-02T03:56:50Z"
+ content="""
+That makes a lot of sense. Yeah, I saw that post not long after posting my last comment. Looks promising, I'll have to try it out when I set up my next remote.
+"""]]
diff --git a/doc/special_remotes/rsync.mdwn b/doc/special_remotes/rsync.mdwn
new file mode 100644
index 0000000000..04af848543
--- /dev/null
+++ b/doc/special_remotes/rsync.mdwn
@@ -0,0 +1,61 @@
+This special remote type rsyncs file contents to somewhere else.
+
+Setup example:
+
+	# git annex initremote myrsync type=rsync rsyncurl=rsync://rsync.example.com/myrsync encryption=shared
+	# git annex describe myrsync "rsync server"
+
+Or for using rsync over SSH
+
+	# git annex initremote myrsync type=rsync rsyncurl=ssh.example.com:/myrsync encryption=shared
+	# git annex describe myrsync "rsync server"
+
+## configuration
+
+These parameters can be passed to `git annex initremote` to configure rsync:
+
+* `rsyncurl` - Required. This is the url or `hostname:/directory` to 
+  pass to rsync to tell it where to store content.
+
+* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
+  See [[encryption]].
+
+* `keyid` - Specifies the gpg key to use for [[encryption]].
+
+* `exporttree` - Set to "yes" to make this special remote usable
+  by [[git-annex-export]]. It will not be usable as a general-purpose
+  special remote.
+
+* `shellescape` - Optional. This has no effect when using rsync 3.2.4 or
+  newer. Set to "no" to avoid shell escaping
+  normally done when using older versions of rsync over ssh. That escaping
+  is needed with typical setups, but not with some hosting providers that do
+  not expose rsynced filenames to the shell. You'll know you need this
+  option if `git annex get` from the special remote fails with an error
+  message containing a single quote (`'`) character. If that happens, you
+  can run enableremote setting shellescape=no.
+
+* `chunk` - Enables [[chunking]] when storing large files.  
+  This is typically not a win for rsync, so no need to enable it.
+  But, it makes this interoperate with the [[directory]] special remote.
+
+The `remote.name.annex-rsync-options` git configuration setting can be used
+to pass parameters to rsync. To pass parameters to rsync only when it's
+downloading and uploading, use `remote.name.annex-rsync-download-options`
+and `remote.name.annex-rsync-upload-options`
+
+## annex-rsync-transport
+
+You can use the `remote.name.annex-rsync-transport` git configuration
+setting to choose whether we run rsync over ssh or rsh.  This setting
+is also used to specify parameters that git annex will pass to ssh/rsh.
+
+ssh is the default transport; if you'd like to run rsync over rsh:
+
+	git config remote.name.annex-rsync-transport rsh
+
+To pass parameters to ssh/rsh, include the parameters after "rsh" or
+"ssh".  For example, to configure ssh to use the private key at
+`/path/to/private/key`:
+
+	git config remote.name.annex-rsync-transport "ssh -i /path/to/private/key"
diff --git a/doc/special_remotes/rsync/comment_10_43e8fa3517c1f5935f02ad06fbed63dc._comment b/doc/special_remotes/rsync/comment_10_43e8fa3517c1f5935f02ad06fbed63dc._comment
new file mode 100644
index 0000000000..185bd97ec5
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_10_43e8fa3517c1f5935f02ad06fbed63dc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://cstork.org/"
+ nickname="Chris Stork"
+ subject="comment 10"
+ date="2013-08-25T20:59:41Z"
+ content="""
+@joey I don't understand you last comment where you state that special remotes can act as transfer repositories \"to transfer the files between computers that do not communicate directly\".  If there's no communication, ie git pushes or pulls, between the computers then they don't know what file names the files on the special remote map to. They need to somehow communicate the git repo too, don't they?
+"""]]
diff --git a/doc/special_remotes/rsync/comment_11_8cafc1a8b37e6fb056185ec058c0c3e8._comment b/doc/special_remotes/rsync/comment_11_8cafc1a8b37e6fb056185ec058c0c3e8._comment
new file mode 100644
index 0000000000..c8fc8831ac
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_11_8cafc1a8b37e6fb056185ec058c0c3e8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 11"
+ date="2013-08-26T18:36:03Z"
+ content="""
+@Chris yes in that case you still need, a central git repository (which need not be on a host that supports git-annex), or the assistant can use xmpp to sync the git data.
+"""]]
diff --git a/doc/special_remotes/rsync/comment_12_fa21b66a1722d226f1819646b9c45308._comment b/doc/special_remotes/rsync/comment_12_fa21b66a1722d226f1819646b9c45308._comment
new file mode 100644
index 0000000000..343e823701
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_12_fa21b66a1722d226f1819646b9c45308._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="davidriod@e75b369a4b1cced29c14354bce7493c61f00b1c7"
+ nickname="davidriod"
+ avatar="http://cdn.libravatar.org/avatar/d6e327bd88b88802d6f0c20c83f682a2"
+ subject="ssh and encryption"
+ date="2016-11-03T06:50:26Z"
+ content="""
+I was wondering if the transmission of data was safe over ssh with encryption=none ?
+"""]]
diff --git a/doc/special_remotes/rsync/comment_13_368f90773db9522c373168e127a39ae6._comment b/doc/special_remotes/rsync/comment_13_368f90773db9522c373168e127a39ae6._comment
new file mode 100644
index 0000000000..67e09c0922
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_13_368f90773db9522c373168e127a39ae6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2016-11-07T17:40:15Z"
+ content="""
+@davidriod if you're using a rsyncurl that uses ssh, then yes, the
+transmission goes over a secure connection. If the rsyncurl uses
+the rsync protocol, there would be no encryption.
+
+Of course, encryption=none does not keep the data encrypted at rest,
+so the admin of the rsync server can see it etc.
+"""]]
diff --git a/doc/special_remotes/rsync/comment_14_2261b1b7441eff9e28ec8e1f98d77980._comment b/doc/special_remotes/rsync/comment_14_2261b1b7441eff9e28ec8e1f98d77980._comment
new file mode 100644
index 0000000000..4d6f0cfc28
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_14_2261b1b7441eff9e28ec8e1f98d77980._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="davidriod@e75b369a4b1cced29c14354bce7493c61f00b1c7"
+ nickname="davidriod"
+ avatar="http://cdn.libravatar.org/avatar/d6e327bd88b88802d6f0c20c83f682a2"
+ subject="Sharing rsync special remote between repository"
+ date="2016-11-24T19:23:42Z"
+ content="""
+I was wondering if it is possible to share a rsync special remote between repository which are not parented in any way. The use case would be that even if these repositories are not related at all they still may contains the same binary file. It would be useful to have a single rsync remote in order to reduce space usage. I think it could work as the object names are based on their checksum, but I wonder if anyone has already try that ?
+"""]]
diff --git a/doc/special_remotes/rsync/comment_15_a4a0491a7dcee2e7b7786127518866af._comment b/doc/special_remotes/rsync/comment_15_a4a0491a7dcee2e7b7786127518866af._comment
new file mode 100644
index 0000000000..2f68c3f574
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_15_a4a0491a7dcee2e7b7786127518866af._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2016-12-13T16:43:42Z"
+ content="""
+@davidriod you can do things like this with special remotes, as long
+as the special remotes are not encrypted.
+
+I don't really recommend it. With such a shared special remote R and two
+disconnected git repos -- call them A and B, some confusing situations can
+occur. For example, the only copies of some files may be 
+on special remote R and git repo B. A knows about the copy in R, so 
+git-annex is satisfied there is one copy of the file. But now, B can drop
+the content from R, which is allowed as the content is in B. A is then left
+unable to recover the content of the files at all, since they have been
+removed from R.
+
+Better to connect the two repositories A and B, even if you do work in
+two separate branches. Then if a file ends up located only on B, A will be
+able to say where it is, and could even get it from B (if B was set up as a
+remote).
+"""]]
diff --git a/doc/special_remotes/rsync/comment_16_509514d6e3d790a80a2125068f499a72._comment b/doc/special_remotes/rsync/comment_16_509514d6e3d790a80a2125068f499a72._comment
new file mode 100644
index 0000000000..3d46b00945
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_16_509514d6e3d790a80a2125068f499a72._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="aurelia@b44312a63326710de6cea9c43290e5debbd55607"
+ nickname="aurelia"
+ avatar="http://cdn.libravatar.org/avatar/818bf579caf9992f9123bd9b58321b2b"
+ subject="comment 16"
+ date="2022-08-07T10:28:09Z"
+ content="""
+turns out that if you get into the habit of writing rsync remotes like rclone remotes, git annex breaks
+
+I had a SSH config entry with the name `annex` and set the rsync URL to `annex:`. The works for moving content in, but fsck and get will fail and undo the content tracking.
+"""]]
diff --git a/doc/special_remotes/rsync/comment_1_9e180c397486989beab21699b8e8f103._comment b/doc/special_remotes/rsync/comment_1_9e180c397486989beab21699b8e8f103._comment
new file mode 100644
index 0000000000..a4c403e7e3
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_1_9e180c397486989beab21699b8e8f103._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="diepes"
+ ip="105.227.34.36"
+ subject="rsync description and example"
+ date="2013-03-29T15:57:20Z"
+ content="""
+Hi, I would like to see a example of setting up / using e.g. rsync.net as a repo.
+
+
+Please also provide a highlevel description of how the rsync repo fits in with git-annex.
+
+ 
+Q1. can you adds files to the remote rsync repo, and will they be detected and synced back ?
+Q2. is all the git history rsync'd to remote ?   how do i recover if i loose all data except the remote rsync repo ?
+  
+"""]]
diff --git a/doc/special_remotes/rsync/comment_2_25545dc0b53f09ae73b29899c8884b02._comment b/doc/special_remotes/rsync/comment_2_25545dc0b53f09ae73b29899c8884b02._comment
new file mode 100644
index 0000000000..3a6e25b0db
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_2_25545dc0b53f09ae73b29899c8884b02._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-03-29T17:12:47Z"
+ content="""
+No, special remotes do not contain a copy of the git repository, and no, git-annex does not notice when files are added to remote rsync repositories. Suggest you read [[special_remotes]].
+"""]]
diff --git a/doc/special_remotes/rsync/comment_3_960a89b1ae7e3888ffba06baa963dc21._comment b/doc/special_remotes/rsync/comment_3_960a89b1ae7e3888ffba06baa963dc21._comment
new file mode 100644
index 0000000000..37911a7e76
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_3_960a89b1ae7e3888ffba06baa963dc21._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="diepes"
+ ip="105.227.34.36"
+ subject="sshfs ?  and no sync from special remote to 2nd git-annex ?"
+ date="2013-03-29T22:09:49Z"
+ content="""
+* It sound to me it would be 1st prize if the cloud provider supported the git-annex functionality over ssh. 
+* Then it could be a full git-annex repo, and used for recovery if my laptop with the git info gets lost. 
+* From special remotes \"These can be used just like any normal remote by git-annex\" 
+* Your comment \"No, special remotes do not contain a copy of the git repository\" 
+
+ * so a special remote is
+
+1. \"A. just a remote filesystem, that contains the objects with sha1 names ? \"
+2. \"B. there is no git info and thus no file name & directory details or am i missing something ?\" 
+3. \"C. you can't use the remote as a cloud drive to sync changes e.g. file moves, renames between two other git-annex repositories ? (no meta data)\" 
+4. \"D. the data on the cloud/rsync storage can not be used directly it has to moved into a git-annex capable storage location. \"
+
+* Would it not be better to mount the remote storage over ssh(sshfs) and then use full git-annex on mounted directory ?
+"""]]
diff --git a/doc/special_remotes/rsync/comment_4_db84816c31239953dd21f23a8c557b43._comment b/doc/special_remotes/rsync/comment_4_db84816c31239953dd21f23a8c557b43._comment
new file mode 100644
index 0000000000..4e95fac20b
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_4_db84816c31239953dd21f23a8c557b43._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="diepes"
+ ip="41.160.8.49"
+ subject="rsync.net support git and rsync, not git-annex"
+ date="2013-05-13T14:44:53Z"
+ content="""
+how would i use rsync.net as a full repository ?  (annex files and git repo)
+
+It support's rsync, and I discovered now git as well.
+
+I had a look at the webapp and can't figure out how to set it up, so I can have multiple remote's sync to rsync.net for annex files and git sync.
+
+Link: http://www.rsync.net/resources/howto/github_integration.html
+
+"""]]
diff --git a/doc/special_remotes/rsync/comment_5_ccaffa4aded9dab88c76a856b96ea5b9._comment b/doc/special_remotes/rsync/comment_5_ccaffa4aded9dab88c76a856b96ea5b9._comment
new file mode 100644
index 0000000000..3368b59ed9
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_5_ccaffa4aded9dab88c76a856b96ea5b9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="cehteh"
+ ip="217.8.62.137"
+ subject="rsync daemon mode"
+ date="2013-07-27T01:35:37Z"
+ content="""
+rsync has a --daemon mode with a simple challenge-response authentication but no encryption. This offers a nice lightweight alternative to ssh, especially when we
+store/transfer encrypted content anyways. Is this already supported in git-annex, if yes how to set it up?
+"""]]
diff --git a/doc/special_remotes/rsync/comment_6_e687b9482b177e1351c8c65ea617d3fa._comment b/doc/special_remotes/rsync/comment_6_e687b9482b177e1351c8c65ea617d3fa._comment
new file mode 100644
index 0000000000..a5cf0514bd
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_6_e687b9482b177e1351c8c65ea617d3fa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.246.110"
+ subject="comment 6"
+ date="2013-07-28T00:11:38Z"
+ content="""
+The first example on this page shows using rsync:// to store files on a system using the rsync daemon.
+"""]]
diff --git a/doc/special_remotes/rsync/comment_7_e122979ea811d9ef835ba05bb936190f._comment b/doc/special_remotes/rsync/comment_7_e122979ea811d9ef835ba05bb936190f._comment
new file mode 100644
index 0000000000..8cb1d72b49
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_7_e122979ea811d9ef835ba05bb936190f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://olivier.berger.myopenid.com/"
+ nickname="obergix"
+ subject="rsync remote is basically more intended for backups ?"
+ date="2013-08-17T17:40:47Z"
+ content="""
+If I get it correctly, it is mainly useable as a backup, which will accumulate contents of the objects managed by git-annex over time.
+
+It would be great to have a use case illustrating its use in concrete matters. Thanks in advance.
+"""]]
diff --git a/doc/special_remotes/rsync/comment_8_d566113318d0aa7500d76ffe1bd46069._comment b/doc/special_remotes/rsync/comment_8_d566113318d0aa7500d76ffe1bd46069._comment
new file mode 100644
index 0000000000..1e6bf8aa43
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_8_d566113318d0aa7500d76ffe1bd46069._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 8"
+ date="2013-08-22T18:02:00Z"
+ content="""
+There are many use cases for a rsync special remote. You could use it as a backup. You could use it to archive files offline in a drive with encryption enabled so if the drive is stolen your data is not. You could `git annex move --to rsyncremote` large files when your local drive is getting full, and then `git annex move` the files back when free space is again available. You could have one repository copy files to a rsync remote, and then `git annex get` them on another repository, to transfer the files between computers that do not communicate directly. The git-annex assistant makes it easy to set up rsync remotes using this last scenario, which is referred to as a transfer repository, and arranges to drop files from the transfer repository once they have been transferred to all known clients.
+
+None of these use cases are particular to rsync remotes. Most special remotes can all be used in these and other ways. It largely doesn't matter for your use what underlying transport the special remote uses.
+"""]]
diff --git a/doc/special_remotes/rsync/comment_9_5dcf10a502b2d4feac46b620d43e9d00._comment b/doc/special_remotes/rsync/comment_9_5dcf10a502b2d4feac46b620d43e9d00._comment
new file mode 100644
index 0000000000..b7690cf685
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_9_5dcf10a502b2d4feac46b620d43e9d00._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://olivier.berger.myopenid.com/"
+ nickname="obergix"
+ subject="Added use cases to &quot;special remotes&quot;"
+ date="2013-08-22T20:23:13Z"
+ content="""
+Thanks @joeyh. I've taken the liberty to add your use case description to [[special remotes]]. Hope this helps.
+"""]]
diff --git a/doc/special_remotes/tahoe.mdwn b/doc/special_remotes/tahoe.mdwn
new file mode 100644
index 0000000000..df1ca620fb
--- /dev/null
+++ b/doc/special_remotes/tahoe.mdwn
@@ -0,0 +1,47 @@
+This special remote stores file contents using
+[Tahoe-LAFS](http://tahoe-lafs.org/). There are a number of commercial
+providers, or you can build your own tahoe storage grid.
+
+Since Tahoe-LAFS encrypts all data stored in it, git-annex does not do any
+additional encryption of its own.
+
+Note that data stored in a tahoe remote cannot be dropped from it, as 
+Tahoe-LAFS does not support removing data once it is stored in the Tahoe grid.
+This, along with Tahoe's ability to recover data when some nodes fail,
+makes a tahoe special remote an excellent choice for storing backups.
+
+Typically you will have an account on a Tahoe-LAFS storage grid, which
+is represented by an "introducer furl". You need to supply this to
+git-annex in the `TAHOE_FURL` environment variable when initializing the
+remote. git-annex will then generate a tahoe configuration directory for
+the remote under `~/.tahoe/git-annex/`, and automatically start the tahoe
+daemon as needed.
+
+## configuration
+
+These parameters can be passed to `git annex initremote` to configure
+the tahoe remote.
+
+* `shared-convergence-secret` - Optional. Can be useful to set to
+  allow tahoe to deduplicate information. By default, a new
+  shared-convergence-secret is created for each tahoe remote.
+
+* `embedcreds` - Optional. Set to "yes" embed the tahoe credentials 
+  (specifically the introducer-furl and shared-convergence-secret)
+  inside the git repository, which allows other clones to also use them
+  in order to access the tahoe grid.
+
+  Think carefully about who can access your git repository, and
+  whether you want to give them access to your tahoe system before
+  using embedcreds!
+
+Setup example:
+
+	# TAHOE_FURL=... git annex initremote tahoe type=tahoe embedcreds=yes
+
+## old version of tahoe special remote
+
+An older implementation of tahoe for git-annex used
+the hook special remote. It is not compatible with this newer
+implementation. See
+[[tahoe-lafs|forum/tips:_special__95__remotes__47__hook_with_tahoe-lafs]].
diff --git a/doc/special_remotes/tahoe/comment_10_90d6937e95301f83268e0c9190f0f8c5._comment b/doc/special_remotes/tahoe/comment_10_90d6937e95301f83268e0c9190f0f8c5._comment
new file mode 100644
index 0000000000..942a8e29a9
--- /dev/null
+++ b/doc/special_remotes/tahoe/comment_10_90d6937e95301f83268e0c9190f0f8c5._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="jk@3f2b4ce16bbac41470815333505aa47b91b7a9a6"
+ nickname="jk"
+ avatar="http://cdn.libravatar.org/avatar/c55729c75302ae278a98d1622b30fe49"
+ subject="spurious processes being started"
+ date="2019-06-28T06:50:53Z"
+ content="""
+On debian buster, copying to or from tahoe seems to alway cause an attempt to start a new tahoe process, even if one is already running, resulting in error messages like this  on second or subsequent attempts:
+
+    copy P5273249.JPG STARTING '/home/jk/.tahoe-git-annex/3677c81a-5cd0-4817-9ad3-a7c29b74a7b7'
+    starting node in '/home/jk/.tahoe-git-annex/3677c81a-5cd0-4817-9ad3-a7c29b74a7b7'
+    Another twistd server is running, PID 20860
+   
+    This could either be a previously started instance of your application or a
+    different application entirely. To start a new one, either run it in some other
+    directory, or use the --pidfile and --logfile parameters to avoid clashes.
+
+Not a massive problem as everything seems to work.
+"""]]
diff --git a/doc/special_remotes/tahoe/comment_1_d30f5958cca5dbcb93e4ea56a25586da._comment b/doc/special_remotes/tahoe/comment_1_d30f5958cca5dbcb93e4ea56a25586da._comment
new file mode 100644
index 0000000000..63bb8f44a7
--- /dev/null
+++ b/doc/special_remotes/tahoe/comment_1_d30f5958cca5dbcb93e4ea56a25586da._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="junk@5e3eeba2290e8a3fcf938d9f93b0dfa2565dc7b1"
+ nickname="junk"
+ subject="Tahoe-LAFS helper: multiple FURLs for the same grid"
+ date="2015-05-24T13:48:33Z"
+ content="""
+Hi,
+
+I would like to uses git-annex in combination with Tahoe-LAFS. The grid will consist of private Servers connected though slow DSL-Lines. Thus I would like to use the Tahoe-LAFS helper feature (like a Tahoe-LAFS upload proxy):
+
+https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/helper.rst 
+
+This will result in a different FURL for each location pointing to the same Tahoe-LAFS grid. 
+
+How can I setup two git-annex clients to use two different FURLs for the same remote (the same Tahoe-LAFS grid)?
+
+Thank you very much for your help!
+
+Oliver
+"""]]
diff --git a/doc/special_remotes/tahoe/comment_2_84d59f41949987381369ab75efc1b65e._comment b/doc/special_remotes/tahoe/comment_2_84d59f41949987381369ab75efc1b65e._comment
new file mode 100644
index 0000000000..25d8a3c8b2
--- /dev/null
+++ b/doc/special_remotes/tahoe/comment_2_84d59f41949987381369ab75efc1b65e._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-06-02T19:01:53Z"
+ content="""
+@junk, I think the thing for you to do is avoid setting embedcreds=yes.
+So, git-annex won't store the furl (or the shared-convergence-secret)
+in the git repository.
+
+Instead, you can set TAHOE_FURL in the environment each time
+you use `git annex initremote` to set up your tahoe remote in a git-anex
+repository. (Also pass shared-convergence-secret=  if you have one.)
+
+Or, you could bypass git-annex's automated setup of tahoe, and set it up
+yourself, however works for you. The automated setup is targeted at users
+who want to get tahoe working with git-annex but don't have complicated
+needs, so maybe it's best for you to just bypass it. The way to do 
+that is to set the git config `remote.<name>.tahoe`, to point to a tahoe
+coniguration directory. You can do this before running `git annex
+initremote`, and it *should* just use that directory. I have not tested
+this and may have gone too far in making git-annex automate tahoe setup,
+and too hard to use a manual tahoe setup -- please file a bug report if
+that doesn't work.
+"""]]
diff --git a/doc/special_remotes/tahoe/comment_3_8a425ab612c3b46efb9658ab79038661._comment b/doc/special_remotes/tahoe/comment_3_8a425ab612c3b46efb9658ab79038661._comment
new file mode 100644
index 0000000000..63c9bc5323
--- /dev/null
+++ b/doc/special_remotes/tahoe/comment_3_8a425ab612c3b46efb9658ab79038661._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="junk@5e3eeba2290e8a3fcf938d9f93b0dfa2565dc7b1"
+ nickname="junk"
+ subject="Tahoe-LAFS helper: multiple FURLs for the same grid"
+ date="2015-06-05T09:19:19Z"
+ content="""
+Hi Joey,
+
+thank you very much for your reply! 
+
+I've continued to wrap my head around this because it does not seem to be the intended way to do it in git-annex and also the helper is still in development (it only works for uploads so far). Right now I've figured out that I could also add two rsync-remote with the same uuid and have csync2 sync the two servers. This way I could use which ever remote is closest to upload and download my files and csync will make sure that the files end up on all remotes. So in my case this would achieve the same as the Tahoe-LAFS solution but use more of git-annexes fetures then of Tahoe-LAFS. Also I will be able to easily delete files from the git.
+
+I'll keep you posted on how it went.
+
+Best regards,
+
+Oliver
+"""]]
diff --git a/doc/special_remotes/tahoe/comment_4_11513056ee7de3dc8bf54c7e0948538d._comment b/doc/special_remotes/tahoe/comment_4_11513056ee7de3dc8bf54c7e0948538d._comment
new file mode 100644
index 0000000000..0c6c17844b
--- /dev/null
+++ b/doc/special_remotes/tahoe/comment_4_11513056ee7de3dc8bf54c7e0948538d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="sanket"
+ subject="Integrating Tahoe and Git annex using special remote"
+ date="2015-08-12T00:00:09Z"
+ content="""
+I am trying to integrate Git annex and Tahoe filesystem with each other using special remote. We have 2 systems connected to same Tahoe grid and we managed to upload the file on Tahoe from 1 file system using Git annex and special remote. Now I need to download same file from other system. But for downloading the file from other system we will need the key which was generated when we uploaded the file from first system which was handled by Git annex on first system. We tried to sync only git annex repositories but we did not get the key.( We can not use Sync content because that will kill the purpose of using Tahoe, we need to somehow transfer only keys between 2 git annex systems). Is there any way using which we can share the keys of files uploaded on Tahoe between 2 systems using Git annex or is there any way to share the file between 2 systems on Tahoe grids using git annex and special remote?
+"""]]
diff --git a/doc/special_remotes/tahoe/comment_5_588d129cc2eaf0a8df9fc2fc6de014a9._comment b/doc/special_remotes/tahoe/comment_5_588d129cc2eaf0a8df9fc2fc6de014a9._comment
new file mode 100644
index 0000000000..3d39160efd
--- /dev/null
+++ b/doc/special_remotes/tahoe/comment_5_588d129cc2eaf0a8df9fc2fc6de014a9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-08-14T18:03:52Z"
+ content="""
+@sanket you need to get your git repositories on the two systems connected
+in some way (ie, push one to github, pull in the other one). Once the git
+repositories are in sync, `git annex get` can be run in the second repository
+and will know how to download files that were uploaded to tahoe from the
+first repository.
+
+Nothing tahoe specific here, that's how any git-annex special remote
+works..
+"""]]
diff --git a/doc/special_remotes/tahoe/comment_6_9b23112d568a7edfce05e95478c30e4f._comment b/doc/special_remotes/tahoe/comment_6_9b23112d568a7edfce05e95478c30e4f._comment
new file mode 100644
index 0000000000..7f805ccd1e
--- /dev/null
+++ b/doc/special_remotes/tahoe/comment_6_9b23112d568a7edfce05e95478c30e4f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="vvghadge@ec0c34f6cadf7a32fc6cf0b2bee34c3ce9c568f2"
+ nickname="vvghadge"
+ subject="location of Mapping of file to tahoe uri?"
+ date="2015-11-06T02:28:04Z"
+ content="""
+@JOEY
+
+Where is the TAHOE URI - the file cap in tahoe stored when we use git annex and tahoe?
+
+i am guessing: 1) in the meta data file in git annex 2) in ./git folder
+
+Where is the mapping maintained? That xyz.txt is this particular tahoe URI.
+"""]]
diff --git a/doc/special_remotes/tahoe/comment_7_5aa703bb3d3f7de9e78a6d831bd515dc._comment b/doc/special_remotes/tahoe/comment_7_5aa703bb3d3f7de9e78a6d831bd515dc._comment
new file mode 100644
index 0000000000..d3c6b3ac53
--- /dev/null
+++ b/doc/special_remotes/tahoe/comment_7_5aa703bb3d3f7de9e78a6d831bd515dc._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2015-11-10T18:57:33Z"
+ content="""
+The Tahoe file cap is stored in the git-annex remote state log, which is
+checked into the git-annex branch of the git-annex repository. It can be
+displayed using `git-annex whereis`.
+"""]]
diff --git a/doc/special_remotes/tahoe/comment_9_75eccd07ea57f44d5a198533a907225a._comment b/doc/special_remotes/tahoe/comment_9_75eccd07ea57f44d5a198533a907225a._comment
new file mode 100644
index 0000000000..7350ee5159
--- /dev/null
+++ b/doc/special_remotes/tahoe/comment_9_75eccd07ea57f44d5a198533a907225a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2015-11-30T19:36:03Z"
+ content="""
+Hmm, seems I was wrong about `git annex whereis` displaying the tahoe
+capability. That was not implemented. I have just made a commit that will
+implement it though.
+
+The git-annex branch is part of your git repository when you're using
+git-annex. See [[internals]].
+"""]]
diff --git a/doc/special_remotes/tahoe/comment_9_f5e45af55cd18af73e2d3d5911039418._comment b/doc/special_remotes/tahoe/comment_9_f5e45af55cd18af73e2d3d5911039418._comment
new file mode 100644
index 0000000000..98954f073e
--- /dev/null
+++ b/doc/special_remotes/tahoe/comment_9_f5e45af55cd18af73e2d3d5911039418._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="vvghadge@ec0c34f6cadf7a32fc6cf0b2bee34c3ce9c568f2"
+ nickname="vvghadge"
+ subject="location of Mapping of file to tahoe uri?"
+ date="2015-11-26T00:35:11Z"
+ content="""
+@joey
+
+I tried your solution but git annex whereis displays the remotes and the uuid of the remotes and not the URI of the file on tahoe.
+Example in plain text file name is \"hello.txt\" containing some data and the URI for it in plain text on tahoe is \"URI:CHK:wvyj4ah75mh77oehnwv236jogi:a2d4nx7c7jtyllfle573fgkdvfykci2o2glzknv54vhyo23qb2ya:1:1:110\".
+
+So i intend to find how and where is the plain text URI of the file stored ? Is it stored in some encrypted form? Where/how can i retrieve the plaintext URI.
+
+Also Question 2) You mentioned about git annex branch. Where is the git annex branch? where is the state log? 
+
+
+"""]]
diff --git a/doc/special_remotes/tor.mdwn b/doc/special_remotes/tor.mdwn
new file mode 100644
index 0000000000..bb07bd3a82
--- /dev/null
+++ b/doc/special_remotes/tor.mdwn
@@ -0,0 +1,10 @@
+git-annex can communicate over the Tor network. This allows direct
+communication between git-annex repositories, no matter where they are
+located.
+
+A git remote using tor has an url that looks like
+`tor-annex::2lssjzicvsxkdc2v.onion:19984`
+
+To set this up, use [[git-annex-enable-tor]] and [[git-annex-p2p]],
+and run [[git-annex-remotedaemon]] to serve the Tor hidden service.
+It's explained in detail in [[tips/peer_to_peer_network_with_tor]].
diff --git a/doc/special_remotes/web.mdwn b/doc/special_remotes/web.mdwn
new file mode 100644
index 0000000000..134d547065
--- /dev/null
+++ b/doc/special_remotes/web.mdwn
@@ -0,0 +1,42 @@
+git-annex can use the web as a special remote, associating an url with an
+annexed file, and downloading the file content from the web.
+See [[tips/using_the_web_as_a_special_remote]] for usage examples.
+
+The web special remote is always enabled, without any manual setup being
+needed. Its name is "web".
+
+This special remote can only be used for downloading content,
+not uploading content, or removing content from the web.
+
+This special remote uses urls on the web as the source for content.
+There are several other ways http can be used to download annexed objects,
+including a git remote accessible by http, S3 with a `publicurl` configured,
+and the [[httpalso]] special remote.
+
+## configuration
+
+These parameters can be passed to `git annex initremote` or
+`git-annex enableremote` to configure a web remote:
+
+* `urlinclude` - Only use urls that match the specified glob.  
+  For example, `urlinclude="https://s3.amazonaws.com/*"`  
+* `urlexclude` - Don't use urls that match the specified glob.  
+  For example, to prohibit http urls, but allow https,
+  use `urlexclude="http:*"`  
+  
+Globs are matched case-insensitively.
+
+When there are multiple special remotes of type web, and some are not
+configured with `urlinclude` and/or `urlexclude`, those will avoid using
+urls that are matched by the configuration of other web remotes.
+
+For example, this creates a second web special remote named "slowweb" that
+is only used for urls on one host, and that has a higher cost than the
+"web" special remote. With this configuration, `git-annex get` will first
+try to get the file from the "web" special remote, which will avoid
+using any urls that match slowweb's urlinclude. Only if the content 
+can't be downloaded from "web" (or some other remote) will it fall back
+to downloading from slowweb.
+
+    git-annex initremote --sameas=web slowweb type=web urlinclude='*//slowhost.com/*'
+    git config remote.slowweb.cost 300
diff --git a/doc/special_remotes/web/comment_1_0bd570025f6cd551349ea88a4729ac8e._comment b/doc/special_remotes/web/comment_1_0bd570025f6cd551349ea88a4729ac8e._comment
new file mode 100644
index 0000000000..d01e17da35
--- /dev/null
+++ b/doc/special_remotes/web/comment_1_0bd570025f6cd551349ea88a4729ac8e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://olivier.berger.myopenid.com/"
+ nickname="obergix"
+ subject="Which URL prefix are supported ?"
+ date="2013-08-17T08:44:05Z"
+ content="""
+It is not clear whether only http:// URLs are supported. Can you list others ?
+"""]]
diff --git a/doc/special_remotes/web/comment_2_333141cc9ec6c26ffd19aa95303a91e3._comment b/doc/special_remotes/web/comment_2_333141cc9ec6c26ffd19aa95303a91e3._comment
new file mode 100644
index 0000000000..456186a67d
--- /dev/null
+++ b/doc/special_remotes/web/comment_2_333141cc9ec6c26ffd19aa95303a91e3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 2"
+ date="2013-08-17T08:59:11Z"
+ content="""
+When it says \"arbitrary urls\", it means it. The only requirement is that the url be well formed and that wget or whatever command you have it configured to use via annex.web-download-command knows how to download it.
+
+Update 2018: That used to be the case, but it's now limited by default to
+http and https urls.
+"""]]
diff --git a/doc/special_remotes/web/comment_3_e6ce9bb92c973350852c9498b7ffb50f._comment b/doc/special_remotes/web/comment_3_e6ce9bb92c973350852c9498b7ffb50f._comment
new file mode 100644
index 0000000000..01b1b2a1c6
--- /dev/null
+++ b/doc/special_remotes/web/comment_3_e6ce9bb92c973350852c9498b7ffb50f._comment
@@ -0,0 +1,32 @@
+[[!comment format=sh
+ username="spiderbit"
+ avatar="http://cdn.libravatar.org/avatar/5c1baf041aa5516cb28a2618f7263a56"
+ subject="dont have success with other download commands"
+ date="2016-11-05T17:00:54Z"
+ content="""
+First a few questions:
+1. is this backend supposed to be recursive or does it supports that?
+2. does it need a download command in the following format: 
+  <program> <url>
+
+I assumed this 2 are true.
+
+Well rsync, sftp and scp need a second <to> paramater, they did not work.
+
+So I wrote a small wrapper to add the default \".\" as target location:
+
+filename: rsync-get
+#!/usr/bin/env bash
+rsync -r \"$1\" .
+
+sadly still no sucess:
+
+~/annex $ git annex addurl -c annex.web-download-command=rsync-get mars:/mnt/data/folder/
+addurl _mnt_data_folder_ (downloading mars:/mnt/data/folder/ ...) 
+failed
+git-annex: addurl: 1 failed
+CallStack (from HasCallStack):
+  error, called at ./CmdLine/Action.hs:41:28 in main:CmdLine.Action
+
+I also tried it with a url to a file, in the case that it not supports recursive operations, that did not work, too.
+"""]]
diff --git a/doc/special_remotes/web/comment_4_8a8369e0398a7ec6c65e493e4d836db9._comment b/doc/special_remotes/web/comment_4_8a8369e0398a7ec6c65e493e4d836db9._comment
new file mode 100644
index 0000000000..812cc4147f
--- /dev/null
+++ b/doc/special_remotes/web/comment_4_8a8369e0398a7ec6c65e493e4d836db9._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="spiderbit"
+ avatar="http://cdn.libravatar.org/avatar/5c1baf041aa5516cb28a2618f7263a56"
+ subject="update"
+ date="2016-11-05T17:38:26Z"
+ content="""
+Sorry, should have read the man page.
+
+of course I have to use %url and %file
+
+So it works with \"rsync %url %file\"  but it seems to not work recursive also it renames the files instead of adding them with their normal name. So not useful for what I want to do.
+
+I want to access a normal unmodified directory on my server and add the files to my local directory. That would be a minimal setup, everything else means just extremly big setups with assistant runnig and a cronjob to delete unused files, and lots of cpu load for indexing this files on the server.
+
+I think such minimal setup would be great to get startet without having very complex setups, you dont want to commit to such a tool and hours of setup to get somethnig useful, just to look if its useful for you.
+
+there are 2 aproaches either have a normal repos on the server, with again cronjob and flat setup. which is quite a setup to get.
+
+or use only a real repos on the client, both have big disadvantages normal repos complex setup, to complex to just test it. web links seem to be simple enough but is not recursive therefor only good for youtube links or stuff like that.
+
+Is there really no simple solution for what I want to do?
+"""]]
diff --git a/doc/special_remotes/web/comment_5_1ad36ff51dfe69256fb0c8803da4efd6._comment b/doc/special_remotes/web/comment_5_1ad36ff51dfe69256fb0c8803da4efd6._comment
new file mode 100644
index 0000000000..10399e028d
--- /dev/null
+++ b/doc/special_remotes/web/comment_5_1ad36ff51dfe69256fb0c8803da4efd6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-11-07T14:40:03Z"
+ content="""
+@spiderbit, to support recursively adding content, it would need
+to parse html, and that's simply too complex and too unlikely to
+be useful to many people.
+"""]]
diff --git a/doc/special_remotes/webdav.mdwn b/doc/special_remotes/webdav.mdwn
new file mode 100644
index 0000000000..5acf99a054
--- /dev/null
+++ b/doc/special_remotes/webdav.mdwn
@@ -0,0 +1,44 @@
+This special remote type stores file contents in a WebDAV server.
+
+## configuration
+
+The environment variables `WEBDAV_USERNAME` and `WEBDAV_PASSWORD` are used
+to supply login credentials. You need to set these only when running `git
+annex initremote` (or `enableremote`), as they will be cached in a file
+only you can read inside the local git repository.
+
+A number of parameters can be passed to `git annex initremote` to configure
+the webdav remote.
+
+* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
+  See [[encryption]].
+
+* `keyid` - Specifies the gpg key to use for [[encryption]].
+
+* `embedcreds` - Optional. Set to "yes" embed the login credentials inside
+  the git repository, which allows other clones to also access them. This is
+  the default when gpg encryption is enabled; the credentials are stored
+  encrypted and only those with the repository's keys can access them.
+
+  It is not the default when using shared encryption, or no encryption.
+  Think carefully about who can access your repository before using
+  embedcreds without gpg encryption.
+
+* `url` - Required. The URL to the WebDAV directory where files will be
+  stored. This can be a subdirectory of a larger WebDAV repository, and will
+  be created as needed. Use of a https URL is strongly
+  encouraged, since HTTP basic authentication is used.
+
+* `exporttree` - Set to "yes" to make this special remote usable
+  by [[git-annex-export]]. It will not be usable as a general-purpose
+  special remote.
+
+* `chunk` - Enables [[chunking]] when storing large files.
+
+* `chunksize` - Deprecated version of chunk parameter above.  
+  Do not use for new remotes. It is not safe to change the chunksize
+  setting of an existing remote.
+
+Setup example:
+
+	# WEBDAV_USERNAME=id@joeyh.name WEBDAV_PASSWORD=xxxxxxx git annex initremote box.com type=webdav url=https://dav.box.com/dav/git-annex chunk=10mb keyid=id@joeyh.name
diff --git a/doc/special_remotes/webdav/comment_10_2c087a132c2203ac20636800bf73dfa7._comment b/doc/special_remotes/webdav/comment_10_2c087a132c2203ac20636800bf73dfa7._comment
new file mode 100644
index 0000000000..48f89ca415
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_10_2c087a132c2203ac20636800bf73dfa7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnq-RfkVpFN15SWvQ2lpSGAi0XpNQuLxKM"
+ nickname="Yuval"
+ subject="re: Change Password"
+ date="2014-05-04T19:09:55Z"
+ content="""
+I have Carl's problem as well. Changed box.com's password and now things are crazy.
+"""]]
diff --git a/doc/special_remotes/webdav/comment_11_cde4fccaf551ba1eab8235ebf6654316._comment b/doc/special_remotes/webdav/comment_11_cde4fccaf551ba1eab8235ebf6654316._comment
new file mode 100644
index 0000000000..267fc35802
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_11_cde4fccaf551ba1eab8235ebf6654316._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 11"
+ date="2014-05-16T18:19:21Z"
+ content="""
+You can change the webdav password by running:
+
+WEBDAV_USERNAME=whatever WEBDAV_PASSWORD=newpassword git annex enableremote $remotename
+"""]]
diff --git a/doc/special_remotes/webdav/comment_12_76423262fceeced32ab18fa38ed53bdb._comment b/doc/special_remotes/webdav/comment_12_76423262fceeced32ab18fa38ed53bdb._comment
new file mode 100644
index 0000000000..3d15fc0fbc
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_12_76423262fceeced32ab18fa38ed53bdb._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
+ nickname="Carl"
+ subject="comment 12"
+ date="2014-05-17T20:47:00Z"
+ content="""
+I tried it, but I do have som troubles. Changing password seemed to have worked. At least I do think it did say OK. Any further action generates the following response:
+
+$ git annex fsck --from box.com3 Literatur/Science/Papers/Modén/2006.pdf
+
+fsck Literatur/Science/Papers/Modén/2006.pdf (gpg) (checking box.com3...) (StatusCodeException (Status {statusCode = 401, statusMessage = \"Unauthorized\"}) [(\"Server\",\"nginx\"),(\"Date\",\"Sat, 17 May 2014 19:04:51 GMT\"),(\"Content-Type\",\"application/xml; charset=utf-8\"),(\"Content-Length\",\"235\"),(\"Connection\",\"keep-alive\"),(\"Vary\",\"Host\"),(\"WWW-Authenticate\",\"Basic realm=\\"dav.box.com\\"\"),(\"X-Response-Body-Start\",\"<?xml version=\\"1.0\\" encoding=\\"utf-8\\"?>\n<d:error xmlns:d=\\"DAV:\\" xmlns:s=\\"http://sabredav.org/ns\\">\n  <s:exception>Sabre_DAV_Exception_NotAuthenticated</s:exception>\n  <s:message>Username or password does not match</s:message>\n</d:error>\n\")] (CJ {expose = []})) failed
+git-annex: fsck: 1 failed
+
+It seems it is not available to use the correct password. I tried to use initremote and create a new remote, and this works. In the end no data is lost, as three copies out of my four are still there. I will keep my old remote around for some time if there is any sort of errorfinding that can be done. 
+"""]]
diff --git a/doc/special_remotes/webdav/comment_14_2390020fa7daac8a6d3e8b713bd3b8e7._comment b/doc/special_remotes/webdav/comment_14_2390020fa7daac8a6d3e8b713bd3b8e7._comment
new file mode 100644
index 0000000000..b6f624a622
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_14_2390020fa7daac8a6d3e8b713bd3b8e7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmZilYULa6CDEGfuagoDlesyakBgnf-dF8"
+ nickname="Maarten"
+ subject="Box.com and unknown CA?"
+ date="2014-05-21T04:07:36Z"
+ content="""
+When trying to enable box.com for jabber sharing, I get:
+
+    WebDAV failed to write file: TlsException (HandshakeFailed (Error_Protocol (\"certificate has unknown CA\",True,UnknownCa))): user error
+
+How can I debug this situation?
+"""]]
diff --git a/doc/special_remotes/webdav/comment_14_45e3b7094d0611b2e082be352f74151a._comment b/doc/special_remotes/webdav/comment_14_45e3b7094d0611b2e082be352f74151a._comment
new file mode 100644
index 0000000000..c7c2aafb06
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_14_45e3b7094d0611b2e082be352f74151a._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://olivier.mehani.name/"
+ nickname="olivier-mehani"
+ subject="comment 14"
+ date="2014-11-05T22:57:21Z"
+ content="""
+I have a similar problem to Maarten's, with some potential differences:
+* The WebDAV server is actually an ownCloud 7 instance;
+* The WebDAV server's SSL cert is issued by CAcert (whose root keys are otherwise installed on my system);
+* The cetificate lists the WebDAV VHost's name as an Subject Alt Name rather than its Common Name.
+
+    $ WEBDAV_USERNAME=shtrom WEBDAV_PASSWORD=correcthorsebatterystaple git annex initremote owncloud type=webdav url=https://owncloud/remote.php/webdav/annexdav chunk=10mb encryption=none
+    initremote owncloud (testing WebDAV server...)
+    git-annex: WebDAV failed to write file: TlsException (HandshakeFailed (Error_Protocol (\"certificate rejected: [NameMismatch \\"owncloud\\"]\",True,CertificateUnknown))): user error
+failed
+    git-annex: initremote: 1 failed
+
+"""]]
diff --git a/doc/special_remotes/webdav/comment_15_d43673b8c8ed3534f31d026098ab673c._comment b/doc/special_remotes/webdav/comment_15_d43673b8c8ed3534f31d026098ab673c._comment
new file mode 100644
index 0000000000..4e78113ac0
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_15_d43673b8c8ed3534f31d026098ab673c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn6NYODTE1Sy9YZoi2pvb6i-lcq3dYBxZI"
+ nickname="Karol"
+ subject="android client"
+ date="2014-11-17T18:34:12Z"
+ content="""
+I am stuck at the same problem as Maarten, I cannot create box.com repository..
+"""]]
diff --git a/doc/special_remotes/webdav/comment_16_2a11dfc1fd159a6b9a25cde71ffec80b._comment b/doc/special_remotes/webdav/comment_16_2a11dfc1fd159a6b9a25cde71ffec80b._comment
new file mode 100644
index 0000000000..eba946eaa2
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_16_2a11dfc1fd159a6b9a25cde71ffec80b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Marco"
+ avatar="http://cdn.libravatar.org/avatar/8cf5e1484973d4f4e58b00720e0dbb26"
+ subject="1und1 Online Speicher"
+ date="2016-10-19T03:42:42Z"
+ content="""
+1und1 (a german ISP) will give you up to 1 TB of space hooked to your DSL account. The setup is a bit weird, so here a short way through that worked for me.
+
+FIrst you need to create a service account to connect to your online storage. To create this account you need to go to the legacy control center. https://login.1und1.de/xml/config/ConfigMain;jsessionid=expired.TCpfix90a?__reuse=123
+Go to \"Online Speicher\" and activate it. Next go to \"Zugänge > Dienstepasswort\" and ensure that one is set up. It seems that you have to wait some time until the password is useable.
+
+The host you need to use is: https://sd2dav.1und1.de/ instead of the one that is mentioned in the manual.
+
+Now you can set the remote up:
+
+> WEBDAV_USERNAME='...' WEBDAV_PASSWORD='...' git annex initremote one type=webdav url=https://sd2dav.1und1.de/git-annex chunk=100mb encryption=shared
+"""]]
diff --git a/doc/special_remotes/webdav/comment_17_cfd2786a998af5034dc707f23aa81678._comment b/doc/special_remotes/webdav/comment_17_cfd2786a998af5034dc707f23aa81678._comment
new file mode 100644
index 0000000000..c92c14a9a3
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_17_cfd2786a998af5034dc707f23aa81678._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="git@3af0a87771c4b55bee8a599b934914cd98d4bc0b"
+ nickname="git"
+ avatar="http://cdn.libravatar.org/avatar/6e2a7e8679033ad4a5df260c0ac721f5"
+ subject="Unknown remote type webdav"
+ date="2020-09-08T13:19:47Z"
+ content="""
+When I try to use a WebDAV server as remote storage, \"git annex initremote\" stops with the error message
+
+```
+git-annex: Unknown remote type webdav (pick from: git gcrypt p2p S3 bup directory rsync web bittorrent adb tahoe glacier ddar git-lfs hook external)
+```
+
+This looks like I need to explicitly add WebDAV support, but then this page says that it is built in.
+
+I installed git-annex via Guix, so I checked the Guix package definition where I found the configuration flag \"-WebDAV\". I didn't find any documentation on this flag, nor configuration flags in general, so I don't know if this asks for including or excluding WebDAV support (or maybe even something completely different). So I compiled git-annex under Guix both with and without this flag. In both cases, the build log includes the lines
+
+```
+   BuildFlags.hs:42:2: error:
+        warning: #warning Building without WebDAV. [-Wcpp]
+        #warning Building without WebDAV.
+         ^~~~~~~
+      |
+   42 | #warning Building without WebDAV.
+      |  ^
+```
+
+There is no further explanation, so I have no idea why WebDAV was excluded. Any suggestions? I am completely unfamiliar with Haskell and its build system, so I don't even know how to explore this any further.
+"""]]
diff --git a/doc/special_remotes/webdav/comment_18_c0aff1c36b500ae67c6cb4b34292a54b._comment b/doc/special_remotes/webdav/comment_18_c0aff1c36b500ae67c6cb4b34292a54b._comment
new file mode 100644
index 0000000000..f4f571582f
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_18_c0aff1c36b500ae67c6cb4b34292a54b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Unknown remote type webdav"""
+ date="2020-09-08T16:26:41Z"
+ content="""
+Yes, that flag disables building with webdav. And if the build environment
+is limited in some way that the DAV dependency is not available, that flag
+can be turned on automatically by the dependency resolver.
+
+Probably guix needs to package the [DAV library](http://hackage.haskell.org/package/DAV)
+or add it to the dependencies of the package such that it's available
+to build with.
+
+Actually, I've gone ahead and removed the build flag in the next git-annex
+version, so it will always be required to build.
+"""]]
diff --git a/doc/special_remotes/webdav/comment_19_8bf8d365c0a13f684ed9f9cb013396e7._comment b/doc/special_remotes/webdav/comment_19_8bf8d365c0a13f684ed9f9cb013396e7._comment
new file mode 100644
index 0000000000..9b7d054ed9
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_19_8bf8d365c0a13f684ed9f9cb013396e7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="git@3af0a87771c4b55bee8a599b934914cd98d4bc0b"
+ nickname="git"
+ avatar="http://cdn.libravatar.org/avatar/6e2a7e8679033ad4a5df260c0ac721f5"
+ subject="Re: Unknown remote type webdav"
+ date="2020-09-09T09:48:15Z"
+ content="""
+Thanks a lot for those explanations! I managed to package DAV for Guix, and after rebuilding git-annex, webdav support seems to work as promised. I will clean up my packages and submit them for inclusion in Guix.
+
+"""]]
diff --git a/doc/special_remotes/webdav/comment_1_6b523eea78eae1d19fe2a9950ee33e3a._comment b/doc/special_remotes/webdav/comment_1_6b523eea78eae1d19fe2a9950ee33e3a._comment
new file mode 100644
index 0000000000..768720fe5a
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_1_6b523eea78eae1d19fe2a9950ee33e3a._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://rfhbuk.myopenid.com/"
+ ip="109.145.123.81"
+ subject="git-annex initremote failing for webdav servers"
+ date="2012-12-01T10:18:04Z"
+ content="""
+Unfortunately, trying to set up the following webdav servers fail. Some of the terminal output of git-annex --debug initremote ... is below, but it may not really helpful. Can I help any further, can a webdav remote be set up in a different way? (The box.com webdav initremote worked fine.) Cheers 
+
+
+With livedrive.com:
+
+    [2012-12-01 10:15:12 GMT] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--encrypt\",\"--no-encrypt-to\",\"--no-default-recipient\",\"--recipient\",\"xxxxxxxxxxxxxx\"]
+    (encryption setup with gpg key xxxxxxxxxxxxxx) (testing WebDAV server...)
+    git-annex: \"Bad Request\": user error
+    failed
+    git-annex: initremote: 1 failed
+
+
+With sd2dav.1und1.de: 
+
+    [2012-12-01 10:13:10 GMT] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--encrypt\",\"--no-encrypt-to\",\"--no-default-recipient\",\"--recipient\",\"xxxxxxxxxxxxxx\"]
+    (encryption setup with gpg key xxxxxxxxxxxxxx) (testing WebDAV server...)
+    git-annex: \"Locked\": user error
+    failed
+    git-annex: initremote: 1 failed
+"""]]
diff --git a/doc/special_remotes/webdav/comment_20_a85a41709bbc0c7c138838ac94ba499f._comment b/doc/special_remotes/webdav/comment_20_a85a41709bbc0c7c138838ac94ba499f._comment
new file mode 100644
index 0000000000..fadba15854
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_20_a85a41709bbc0c7c138838ac94ba499f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="git@3af0a87771c4b55bee8a599b934914cd98d4bc0b"
+ nickname="git"
+ avatar="http://cdn.libravatar.org/avatar/6e2a7e8679033ad4a5df260c0ac721f5"
+ subject="Re: Unknown remote type webdav"
+ date="2020-09-09T10:19:21Z"
+ content="""
+Well... someone beat me to it! git-annex in Guix got WebDAV support eight hours ago!
+"""]]
diff --git a/doc/special_remotes/webdav/comment_21_e86cfc56014df46412f08b36bc019fb6._comment b/doc/special_remotes/webdav/comment_21_e86cfc56014df46412f08b36bc019fb6._comment
new file mode 100644
index 0000000000..e208dc9e22
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_21_e86cfc56014df46412f08b36bc019fb6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 21"
+ date="2020-09-09T14:28:47Z"
+ content="""
+> Well... someone beat me to it! git-annex in Guix got WebDAV support eight hours ago!
+
+That someone thanks you for working on the patches (and is sorry about the duplicate effort) :)
+"""]]
diff --git a/doc/special_remotes/webdav/comment_22_556386f26497f4075ab533e21e2077ce._comment b/doc/special_remotes/webdav/comment_22_556386f26497f4075ab533e21e2077ce._comment
new file mode 100644
index 0000000000..238c1a0df5
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_22_556386f26497f4075ab533e21e2077ce._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="git@3af0a87771c4b55bee8a599b934914cd98d4bc0b"
+ nickname="git"
+ avatar="http://cdn.libravatar.org/avatar/6e2a7e8679033ad4a5df260c0ac721f5"
+ subject="comment 22"
+ date="2020-09-10T17:12:57Z"
+ content="""
+Well, better two packagers than zero :-)
+
+If I figured out what happened, it was my question here that prompted Joey to update git-annex to make WebDAV a requirement, which in turn prompted you to package the new dependencies in order to update the package in Guix. Complaint-driven packaging ;-)
+
+It wasn't a waste of time either, because at that occasion I found out that the Guix infrastructure for Haskell code is very nice. I hadn't done much more than import the packages from Hackage.
+"""]]
diff --git a/doc/special_remotes/webdav/comment_23_b57fdd5322088e9b08dca7512c7e7793._comment b/doc/special_remotes/webdav/comment_23_b57fdd5322088e9b08dca7512c7e7793._comment
new file mode 100644
index 0000000000..f2f9fc4425
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_23_b57fdd5322088e9b08dca7512c7e7793._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="read-only webdav access"
+ date="2023-06-20T10:22:57Z"
+ content="""
+Hi Joey et al.,
+
+Thanks yet again for a fantastic tool.
+
+We are using it to distribute scientific data, via a webdav share backed by a customised owncloud deployment.
+
+As this repository will be public, we want to have two special remotes: data-rw and data. The former is used by staff to upload data, and uses a share URL & password with list-read-write-upload-delete permission which works fine.
+
+We also have a share link that only allows listing and reading content. If I try to initremote with the same settings as for the rw remote (but changing the username and password), then we get a failure during remote testing, as git-annex is unable to create a test file. I can get it to work if I temporary enable RW access for that share URL, but then an external user's `git annex enableremote` would fail when they go to initialise it later after I've reset the share link to RO.
+
+I've tried with `git annex initremote ... readonly=true`, but that complains that readonly isn't a valid parameter for webdav. I also see in the source code that readonly is hard-coded to false for the webdav remote (I think -- my Haskell is very rusty).
+
+Is there any chance that we can enable setting readonly=true for webdav, and disabling the write tests for a webdav remote, effectively turning it into a RO special remote *a la* http/ftp/etc?
+
+I've tried using httpalso or web, but that's incompatible with the chunking we need to enable for Webdav.
+
+Any other suggestions?
+
+Thanks again and in advance,
+
+KDM
+"""]]
diff --git a/doc/special_remotes/webdav/comment_24_6c16a7c9abb257be4d046e27e11bacdf._comment b/doc/special_remotes/webdav/comment_24_6c16a7c9abb257be4d046e27e11bacdf._comment
new file mode 100644
index 0000000000..094399f650
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_24_6c16a7c9abb257be4d046e27e11bacdf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 24"""
+ date="2023-06-20T17:25:27Z"
+ content="""
+httpalso now supports chunking. So I think there's no need to add readonly
+support to webdav, probably. But if you disagree, I do think it would be
+possible to add. Just probably not useful.. after all webdav minus writing
+is little different than http. If you disagree, open a [[todo]].
+"""]]
diff --git a/doc/special_remotes/webdav/comment_2_83fc4e7d9ba7a05c8500da659f561b8f._comment b/doc/special_remotes/webdav/comment_2_83fc4e7d9ba7a05c8500da659f561b8f._comment
new file mode 100644
index 0000000000..8a23ad493d
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_2_83fc4e7d9ba7a05c8500da659f561b8f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 2"
+ date="2012-12-01T18:34:05Z"
+ content="""
+I tried signing up for livedrive, but I cannot log into it with WebDav at all. Do they require a Pro account to use WebDav?
+
+When it's \"testing webdav server\", it tries to make a collection (a subdirectory), and uploads a file to it, and sets the file's properties, and deletes the file. One of these actions must be failing, perhaps because the webdav server implementation does not support it. Or perhaps because the webdav client library is doing something wrong. I've instrumented the test, so it'll say which one.
+"""]]
diff --git a/doc/special_remotes/webdav/comment_3_239367ad639c61ecdf87a89f7ac53efe._comment b/doc/special_remotes/webdav/comment_3_239367ad639c61ecdf87a89f7ac53efe._comment
new file mode 100644
index 0000000000..2d559b7afa
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_3_239367ad639c61ecdf87a89f7ac53efe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 3"
+ date="2012-12-01T20:13:36Z"
+ content="""
+I've identified the problem keeping it working with livedrive. Once a patch I've written is applied to the Haskell DAV library, I'll be able to update git-annex to support it.
+
+I don't know about sd2dav.1und1.de. The error looks like it doesn't support WebDAV file locking.
+"""]]
diff --git a/doc/special_remotes/webdav/comment_4_ffa52f7776cdc8caa28667b5eadae123._comment b/doc/special_remotes/webdav/comment_4_ffa52f7776cdc8caa28667b5eadae123._comment
new file mode 100644
index 0000000000..24dd85bf55
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_4_ffa52f7776cdc8caa28667b5eadae123._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 4"
+ date="2012-12-01T21:14:34Z"
+ content="""
+Good news, livedrive is supported now, by git-annex's master branch.
+"""]]
diff --git a/doc/special_remotes/webdav/comment_5_5b8cbdb5e9a1b90d748a5074997e1cd5._comment b/doc/special_remotes/webdav/comment_5_5b8cbdb5e9a1b90d748a5074997e1cd5._comment
new file mode 100644
index 0000000000..7d5f3af5db
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_5_5b8cbdb5e9a1b90d748a5074997e1cd5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://peter-simons.myopenid.com/"
+ ip="192.100.130.7"
+ subject="WebDAV without locking"
+ date="2013-01-16T12:44:16Z"
+ content="""
+Hi Joey,
+
+you are right, the 1-und-1.de implementation of WebDAV does not support locking.
+
+Do you think there is a way to make that service work with git-annex anyhow -- say, by allowing the user to disable file-locking? I've worked around the problem with 1-und-1.de by using fuse+davfs2 to mount the storage in my file system and access it through the directory backend, but FUSE is dead slow, unfortunately, and this solution really sucks.
+"""]]
diff --git a/doc/special_remotes/webdav/comment_6_d3be3e588c3a2abb2025ceb82c18b0ef._comment b/doc/special_remotes/webdav/comment_6_d3be3e588c3a2abb2025ceb82c18b0ef._comment
new file mode 100644
index 0000000000..150c984a82
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_6_d3be3e588c3a2abb2025ceb82c18b0ef._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 6"
+ date="2013-01-17T18:23:27Z"
+ content="""
+It seems it must advertise it supports the LOCK and UNLOCK http actions, but fails when they're used.
+
+The DAV library I am using always locks if it seems the server supports it. So this will need changes to that library. I've filed a bug requesting the changes. <http://bugs.debian.org/698379>
+"""]]
diff --git a/doc/special_remotes/webdav/comment_7_6fa7e11331db5a943015bd5367eb3d73._comment b/doc/special_remotes/webdav/comment_7_6fa7e11331db5a943015bd5367eb3d73._comment
new file mode 100644
index 0000000000..324760c4c3
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_7_6fa7e11331db5a943015bd5367eb3d73._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
+ nickname="Tobias"
+ subject="SSL certificates"
+ date="2013-03-25T16:09:54Z"
+ content="""
+Trying to use webdav leads in:
+
+    git-annex: HandshakeFailed (Error_Protocol (\"certificate rejected: not coping with anything else Start (Container Context 0)\",True,CertificateUnknown))
+
+How can I disable the SSL certificate check?
+"""]]
diff --git a/doc/special_remotes/webdav/comment_8_2627b41f80c7511b27464e2040b128a8._comment b/doc/special_remotes/webdav/comment_8_2627b41f80c7511b27464e2040b128a8._comment
new file mode 100644
index 0000000000..96ae19d111
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_8_2627b41f80c7511b27464e2040b128a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 8"
+ date="2013-03-27T16:38:47Z"
+ content="""
+I don't think the checking of SSL certificates can currently be disabled.
+"""]]
diff --git a/doc/special_remotes/webdav/comment_9_b8f17efe524bb45a3e16705996df1265._comment b/doc/special_remotes/webdav/comment_9_b8f17efe524bb45a3e16705996df1265._comment
new file mode 100644
index 0000000000..365bf7042f
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_9_b8f17efe524bb45a3e16705996df1265._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
+ nickname="Carl"
+ subject="Change Password"
+ date="2014-05-02T12:30:58Z"
+ content="""
+I want to change the password that I use on a webdav service (Heartbleed mitigration). What do I need to do to in git annex to make it have access to the new password? Thanks in anvance.
+"""]]
diff --git a/doc/special_remotes/xmpp.mdwn b/doc/special_remotes/xmpp.mdwn
new file mode 100644
index 0000000000..3e9d66a1fe
--- /dev/null
+++ b/doc/special_remotes/xmpp.mdwn
@@ -0,0 +1,4 @@
+XMPP (Jabber) used to be able to be used by the [[assistant]] as a git remote.
+This never worked very well, and it was not entirely secure, since the XMPP
+server saw the contents of git pushes without encryption. So, XMPP support
+has been removed. Use [[tor]] instead.
diff --git a/doc/special_remotes/xmpp/comment_10_c7c2e2e81cb5b2b9a5272430c835dd39._comment b/doc/special_remotes/xmpp/comment_10_c7c2e2e81cb5b2b9a5272430c835dd39._comment
new file mode 100644
index 0000000000..0380af3593
--- /dev/null
+++ b/doc/special_remotes/xmpp/comment_10_c7c2e2e81cb5b2b9a5272430c835dd39._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmZilYULa6CDEGfuagoDlesyakBgnf-dF8"
+ nickname="Maarten"
+ subject="Google Apps & SRV"
+ date="2013-11-27T18:13:18Z"
+ content="""
+To make XMPP via a Google Apps account work out of the box, all you need to do is add the correct SRV records to your domain's DNS zone.  If you do, you don't need to manually create creds/xmpp, you can just use the web interface, enter your full apps email address and password (remember, if 2-factor, this needs to be an application-specific password).
+
+To create the correct SRV records (and check whether they're correct), see http://www.olark.com/gtalk/check_srv
+"""]]
diff --git a/doc/special_remotes/xmpp/comment_11_05d9a67b9331656b4035399641cedb1b._comment b/doc/special_remotes/xmpp/comment_11_05d9a67b9331656b4035399641cedb1b._comment
new file mode 100644
index 0000000000..4b343bda2d
--- /dev/null
+++ b/doc/special_remotes/xmpp/comment_11_05d9a67b9331656b4035399641cedb1b._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm0yDI6AsAuXPDHIDXm5H9EGDXkuwb1efA"
+ nickname="Yann"
+ subject="XMPP not working in Raspberry PI build"
+ date="2013-12-27T23:16:23Z"
+ content="""
+Hi,
+
+I have the same problem that users Carlo and RaspberryPie have: XMPP not working and no XMPP log in the build.
+
+I did a quick strace during the daemon start and I noticed than the raspberry pi build doesn't even try to read the creds/xmpp files contrary to the standard git-annex package on my ubuntu workstation.
+
+To me, it seems the XMPP thread is not started at all.
+Does someone know any reason why the XMPP thread could not be started ?
+
+If there is anything I can do to help debug this issue, let me know.
+
+Yann
+
+
+
+"""]]
diff --git a/doc/special_remotes/xmpp/comment_1_568247938929a2934e8198fca80b7184._comment b/doc/special_remotes/xmpp/comment_1_568247938929a2934e8198fca80b7184._comment
new file mode 100644
index 0000000000..060aa5bd7b
--- /dev/null
+++ b/doc/special_remotes/xmpp/comment_1_568247938929a2934e8198fca80b7184._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA"
+ nickname="Tobias"
+ subject="User defined server"
+ date="2013-04-17T09:45:59Z"
+ content="""
+It would be nice if you could expand the XMPP setup in the assistant to support an \"advanced\" settings view where a custom server could be defined.
+
+Example: I have a google Apps domain called mytest.com, with the users bla1@mytest.com and bla2@mytest.com. When trying to add either of those accounts to the assistant XMPP will try to use mytest.com as the jabber server, and not googles server.
+
+"""]]
diff --git a/doc/special_remotes/xmpp/comment_2_9fc3f512020b7eb2591d6b7b2e8de2d7._comment b/doc/special_remotes/xmpp/comment_2_9fc3f512020b7eb2591d6b7b2e8de2d7._comment
new file mode 100644
index 0000000000..02f70d0f2e
--- /dev/null
+++ b/doc/special_remotes/xmpp/comment_2_9fc3f512020b7eb2591d6b7b2e8de2d7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmRFKwny4rArBaz-36xTcsJYqKIgdDaw5Q"
+ nickname="Andrew"
+ subject="comment 2"
+ date="2013-04-17T22:28:39Z"
+ content="""
+Yeah, I agree, this would be nice. 
+
+For your own domain, you can configure DNS like this: [[http://support.google.com/a/bin/answer.py?hl=en&answer=34143]] to make XMPP find the right server. But for some that's not an option and the \"advanced\" mode would be useful in that case.
+"""]]
diff --git a/doc/special_remotes/xmpp/comment_3_48ddbba1402d89acaea07cff747c48e0._comment b/doc/special_remotes/xmpp/comment_3_48ddbba1402d89acaea07cff747c48e0._comment
new file mode 100644
index 0000000000..7643d4d7da
--- /dev/null
+++ b/doc/special_remotes/xmpp/comment_3_48ddbba1402d89acaea07cff747c48e0._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="46.19.143.203"
+ subject="Missing prerequisites for XMPP syncing?"
+ date="2013-09-17T06:53:59Z"
+ content="""
+I set up two fresh annexes that can talk via XMPP and no other way. After I fire up the assistants I expect them to sync their metadata, but nothing happens. One log gives me an 'XMPPClient: received: [\"Unknown message\"]' message every two minutes. The other one doesn't contain the string XMPP at all, not once. So my suspicion is that this particular version of git-annex doesn't support XMPP, which is weird because:
+
+    $ git annex version
+    git-annex version: 4.20130909
+    build flags: Assistant Pairing Testsuite S3 Inotify XMPP DNS Feeds
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3 4
+    upgrade supported from repository versions: 0 1 2
+
+This is the version output from the other machine: 
+
+    $ git annex version
+    git-annex version: 4.20130827
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3 4
+    upgrade supported from repository versions: 0 1 2
+
+What am I missing? Are there more build flags for XMPP than the one called XMPP? (Also, no, I can't just copy versions between machines b/c the architectures are different. And yep, the one giving me trouble is ARM.)
+"""]]
diff --git a/doc/special_remotes/xmpp/comment_4_59857879abaae22bde444a215e00bf18._comment b/doc/special_remotes/xmpp/comment_4_59857879abaae22bde444a215e00bf18._comment
new file mode 100644
index 0000000000..db217cff97
--- /dev/null
+++ b/doc/special_remotes/xmpp/comment_4_59857879abaae22bde444a215e00bf18._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.105"
+ subject="comment 4"
+ date="2013-09-19T21:07:35Z"
+ content="""
+If you have the XMPP flag in your git-annex build, it will support XMPP. Are you sure you set up the xmpp creds file and the xmpp special remote correctly on the ARM machine? (I assume it has no webapp, so you had to set that up manually..)
+
+Here's how you can do that manually:
+
+1. Run git-annex on a machine with the webapp, set up XMPP, and copy the .git/annex/creds/xmpp to the machine without the webapp.
+2. On the machine without the webapp, add a git remote that has its \"url = xmpp::loginname@xmppserver.com\" and its annex-uuid set to the annex.uuid of the repository on the first machine.
+3. Run git-annex assistant on the machine without the webapp.
+"""]]
diff --git a/doc/special_remotes/xmpp/comment_5_583ee374bd34fcc9ae26c2fd690e8c47._comment b/doc/special_remotes/xmpp/comment_5_583ee374bd34fcc9ae26c2fd690e8c47._comment
new file mode 100644
index 0000000000..298c4392a8
--- /dev/null
+++ b/doc/special_remotes/xmpp/comment_5_583ee374bd34fcc9ae26c2fd690e8c47._comment
@@ -0,0 +1,73 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="37.221.161.234"
+ subject="Nope"
+ date="2013-09-24T22:05:55Z"
+ content="""
+Your guess is right, Joey, I'm configuring by hand as the ARM machine has no webapp. And yes, I'm mostly sure I set up everything correctly. The XMPP account is working, and my configuration of git-annex is all but identical to your example.
+
+Here's what I do. First on the machine with the webapp:
+
+    mkdir ~/test
+    cd ~/test
+    git init
+    git annex init
+    git annex webapp
+
+I set up XMPP from within the webapp. The file ~/test/.git/annex/creds/xmpp is created with the correct credentials. (BTW: The file's default permissions are 620 instead of 600 - is that a bug?)
+
+I add a file or two to the annex for good measure. Then, on the ARM machine:
+
+    mkdir ~/test
+    cd ~/test
+    git init
+    git annex init
+    mkdir .git/annex/creds
+    scp -2 webappmachine:~/test/.git/annex/creds/xmpp .git/annex/creds 
+    chmod 600 .git/annex/creds/xmpp
+    git remote add webappmachine xmpp::login@server
+
+The final step is to edit .git/config on the ARM machine. The [remote] section now looks like this:
+
+    [remote \"webappmachine\"]
+        url = xmpp::login@server
+        fetch = +refs/heads/*:refs/remotes/webappmachine/*
+        annex-uuid = aaaaaaaa-bbbb-cccc-dddddddddddd
+
+where aaaaaaaa-bbbb-cccc-dddddddddddd is the return value of `git config --get annex.uuid` on the webapp machine.
+
+I then run `git annex assistant` on the ARM machine and expect the two machines to synchronize their metadata, e.g. the number of knownn annex keys in the repo. But it doesn't happen.
+
+So I set `debug = true`, restart the assistants and check the log. This is what I get on the webapp machine:
+
+    [2013-09-24 17:45:41 EDT] XMPPClient: connected a5/25577ac4-3248-4c83-8391-bd93708bcf2b
+    [2013-09-24 17:45:41 EDT] XMPPClient: received: [\"Presence from a5/dc9bcde8-fe18-47de-807c-c620019279f2 Just (Element {elementName = Name {nameLocalName = \\"git-annex\\", nameNamespace = Just \\"git-annex\\", namePrefix = Nothing}, elementAttributes = [(Name {nameLocalName = \\"query\\", nameNamespace = Nothing, namePrefix = Nothing},[ContentText \\"\\"])], elementNodes = []})\",\"QueryPresence\"]
+    [2013-09-24 17:45:42 EDT] XMPPClient: received: [\"Presence from a5/900e3b6e-a7f4-4a6a-8d12-ed94de429258 Just (Element {elementName = Name {nameLocalName = \\"git-annex\\", nameNamespace = Just \\"git-annex\\", namePrefix = Nothing}, elementAttributes = [(Name {nameLocalName = \\"push\\", nameNamespace = Nothing, namePrefix = Nothing},[ContentText \\"43357474-abbb-4667-a334-e4615ea6d4a2\\"])], elementNodes = []})\",\"NotifyPush [UUID \\"43357474-abbb-4667-a334-e4615ea6d4a2\\"]\"]
+    [2013-09-24 17:45:42 EDT] XMPPClient: push notification for
+    [2013-09-24 17:45:42 EDT] read: git [\"--git-dir=/home/pi/test/.git\",\"--work-tree=/home/pi/test\",\"symbolic-ref\",\"HEAD\"]
+    [2013-09-24 17:45:42 EDT] read: git [\"--git-dir=/home/pi/test/.git\",\"--work-tree=/home/pi/test\",\"show-ref\",\"refs/heads/master\"]
+    [2013-09-24 17:45:42 EDT] XMPPClient: received: [\"Pushing \\"a59\\" (CanPush (UUID \\"d50c4cc9-e7c0-4ef0-84c6-f11012051eb9\\") [34f875cc7fa1198414f93990af9ab78e6cee893e,6fad42234060361435d6cf2ab4bd40e438c2d05c])\"]
+    [2013-09-24 17:45:42 EDT] read: git [\"--git-dir=/home/pi/test/.git\",\"--work-tree=/home/pi/test\",\"show-ref\",\"git-annex\"]
+    [2013-09-24 17:45:42 EDT] read: git [\"--git-dir=/home/pi/test/.git\",\"--work-tree=/home/pi/test\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+    [2013-09-24 17:45:42 EDT] read: git [\"--git-dir=/home/pi/test/.git\",\"--work-tree=/home/pi/test\",\"log\",\"refs/heads/git-annex..6fad42234060361435d6cf2ab4bd40e438c2d05c\",\"--oneline\",\"-n1\"]
+    [2013-09-24 17:45:42 EDT] chat: git [\"--git-dir=/home/pi/test/.git\",\"--work-tree=/home/pi/test\",\"cat-file\",\"--batch\"]
+    [2013-09-24 17:45:42 EDT] XMPPClient: received: [\"Ignorable Presence from a5/25577ac4-3248-4c83-8391-bd93708bcf2b Just (Element {elementName = Name {nameLocalName = \\"git-annex\\", nameNamespace = Just \\"git-annex\\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})\"]
+    [2013-09-24 17:45:42 EDT] XMPPClient: received: [\"Unknown message\"]
+    [2013-09-24 17:45:42 EDT] XMPPClient: received: [\"Pushing \\"a59\\" (PushRequest (UUID \\"d50c4cc9-e7c0-4ef0-84c6-f11012051eb9\\"))\"]
+    [2013-09-24 17:45:42 EDT] XMPPSendPack: started running push Pushing \"a59\" (PushRequest (UUID \"d50c4cc9-e7c0-4ef0-84c6-f11012051eb9\"))
+    [2013-09-24 17:45:42 EDT] read: git [\"--git-dir=/home/pi/test/.git\",\"--work-tree=/home/pi/test\",\"symbolic-ref\",\"HEAD\"]
+    [2013-09-24 17:45:42 EDT] XMPPClient: received: [\"Ignorable Presence from a5/25577ac4-3248-4c83-8391-bd93708bcf2b Just (Element {elementName = Name {nameLocalName = \\"git-annex\\", nameNamespace = Just \\"git-annex\\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})\"]
+    [2013-09-24 17:45:42 EDT] read: git [\"--git-dir=/home/pi/test/.git\",\"--work-tree=/home/pi/test\",\"show-ref\",\"refs/heads/master\"]
+    [2013-09-24 17:45:42 EDT] call: git [\"--git-dir=/home/pi/test/.git\",\"--work-tree=/home/pi/test\",\"branch\",\"-f\",\"synced/master\"]
+    [2013-09-24 17:45:42 EDT] XMPPSendPack: finished running push Pushing \"a59\" (PushRequest (UUID \"d50c4cc9-e7c0-4ef0-84c6-f11012051eb9\")) False
+
+And from then on, in two-minute intervals:
+
+    [2013-09-24 17:47:42 EDT] XMPPClient: received: [\"Unknown message\"]
+    [2013-09-24 17:49:42 EDT] XMPPClient: received: [\"Unknown message\"]
+    [2013-09-24 17:51:42 EDT] XMPPClient: received: [\"Unknown message\"]
+    
+The log on the ARM machine is rather unhelpful. Actually it doesn't even contain the string \"XMPP\". This looks to me like the webapp machine tries to communicate via Jabber but doesn't get any intelligible answer. And this is the reason I wondered whether the problem lies with my self-compiled ARM git-annex  binary. I actually spent a while compiling 4.20130909 with all flags but webapp and webdav, but the result is still the same. 
+
+Any other ideas what I'm doing wrong here?
+"""]]
diff --git a/doc/special_remotes/xmpp/comment_6_8f0b5bba1271d031a67e7f0c175d67d5._comment b/doc/special_remotes/xmpp/comment_6_8f0b5bba1271d031a67e7f0c175d67d5._comment
new file mode 100644
index 0000000000..750e0874a4
--- /dev/null
+++ b/doc/special_remotes/xmpp/comment_6_8f0b5bba1271d031a67e7f0c175d67d5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.220"
+ subject="comment 6"
+ date="2013-09-25T18:13:24Z"
+ content="""
+If you're not getting an \"XMPPClient: connected\", then my guess would be that your git-annex build's XMPP is screwed up somehow. For example, if it hung forever when connecting to the XMPP server, it would never get as far as printing that message. (If it tried and failed to connect, you'd get a message about the connection having failed.)
+"""]]
diff --git a/doc/special_remotes/xmpp/comment_7_ac7acbded03325b015959d82ae77faf1._comment b/doc/special_remotes/xmpp/comment_7_ac7acbded03325b015959d82ae77faf1._comment
new file mode 100644
index 0000000000..0ad65336b7
--- /dev/null
+++ b/doc/special_remotes/xmpp/comment_7_ac7acbded03325b015959d82ae77faf1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="RaspberryPie"
+ ip="46.165.221.166"
+ subject="comment 7"
+ date="2013-09-26T03:46:18Z"
+ content="""
+I see. Is there a way to check whether the build is corrupt? The build logs gave me nothing. 
+
+Anyway, XMPP is not the most important feature to me. It still bugs me though that it doesn't work when it should.  
+"""]]
diff --git a/doc/special_remotes/xmpp/comment_8_81a9636a1e8a36a58185468a26f8633d._comment b/doc/special_remotes/xmpp/comment_8_81a9636a1e8a36a58185468a26f8633d._comment
new file mode 100644
index 0000000000..79dd2892b2
--- /dev/null
+++ b/doc/special_remotes/xmpp/comment_8_81a9636a1e8a36a58185468a26f8633d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="comment 8"
+ date="2013-10-22T14:30:58Z"
+ content="""
+Same setup, same problem... no log output on raspberry pi.
+"""]]
diff --git a/doc/special_remotes/xmpp/comment_9_eda76b826491c96b1ce072aacf9d3adf._comment b/doc/special_remotes/xmpp/comment_9_eda76b826491c96b1ce072aacf9d3adf._comment
new file mode 100644
index 0000000000..3505f3aafa
--- /dev/null
+++ b/doc/special_remotes/xmpp/comment_9_eda76b826491c96b1ce072aacf9d3adf._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlu-fdXIt_RF9ggvg4zP0yBbtjWQwHAMS4"
+ nickname="Jörn"
+ subject="Same problem, no XMPP showing up in daemon.log"
+ date="2013-11-21T21:13:16Z"
+ content="""
+I have the same setup like @RaspberryPie, except that my server is not running on the Pi but on Debian7-amd64. On my client (OSX, self-compiled using cabal) I can see XMPP log entries like @RaspberryPi, however, on the Debian7 machine (also self-compiled) I do not see any XMPP entry in the daemon.log. Setup regarding .git/annex/creds/xmpp and the special xmpp remote is correct (checked a thousand times).
+
+Do you have any idea what could be wrong, Joey? Thanks a lot.
+
+Output of git annex version:
+
+    git-annex version: 5.20131120
+    build flags: Assistant Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS Feeds Quvi CryptoHash 
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav glacier hook
+    local repository version: 4
+    default repository version: 3
+    supported repository versions: 3 5
+    upgrade supported from repository versions: 0 1 2 4
+
+Jörn
+"""]]
diff --git a/doc/stickers.mdwn b/doc/stickers.mdwn
new file mode 100644
index 0000000000..76da6c220c
--- /dev/null
+++ b/doc/stickers.mdwn
@@ -0,0 +1,21 @@
+Hexagonal sticker design using the [[logo]] with add-on tiles to expand
+the annex.
+
+[[stickers/hex.svg]]
+[download hex.svg](hex.svg)
+
+[[stickers/hexdemos.svg]]
+[download hexdemos.svg](hexdemos.svg)
+
+This complies with <https://github.com/terinjokes/StickerConstructorSpec/>
+and so is intended to combine with other hexagonal stickers.
+
+Some of the add-on tiles contain enough white-space to add other art work
+as desired.
+
+It includes some smaller tiles that can bridge between hexagonal and
+square/regtangular stickers, as illustrated in
+<https://github.com/terinjokes/StickerConstructorSpec/issues/13>.
+
+License: Same as git-annex [[logo]]; Joey would appreciate spare 
+git-annex stickers mailed his way, but does not require it. ;)
diff --git a/doc/stickers/comment_1_96f9b35048793c1cc0902cced82b65c5._comment b/doc/stickers/comment_1_96f9b35048793c1cc0902cced82b65c5._comment
new file mode 100644
index 0000000000..8cdd7c7160
--- /dev/null
+++ b/doc/stickers/comment_1_96f9b35048793c1cc0902cced82b65c5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://bret.io/"
+ subject="Woo!  "
+ date="2015-11-19T23:48:01Z"
+ content="""
+Rad! Cant wait to add it to:
+
+<img src=\"https://camo.githubusercontent.com/0133cd5cab79bd8e9945d0e89337e2041d157076/68747470733a2f2f63312e737461746963666c69636b722e636f6d2f312f3732302f32313339393337353133395f303564383938316231395f622e6a7067\" height=\"400\">
+
+I like the idea of adapters too :)
+
+https://www.stickermule.com/ and https://hexi.pics/help_en both print high quality spec compliant stickers.
+"""]]
diff --git a/doc/stickers/comment_2_39cfee29eae5e69d88d84b2c65eb83fe._comment b/doc/stickers/comment_2_39cfee29eae5e69d88d84b2c65eb83fe._comment
new file mode 100644
index 0000000000..63bc285091
--- /dev/null
+++ b/doc/stickers/comment_2_39cfee29eae5e69d88d84b2c65eb83fe._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2015-11-20T08:37:39Z"
+ content="""
+I don't usually like any decals on my stuff.. but I've never come across this before and it looks interesting. I'm really tempted..
+
+However, I wouldn't be able to do it without having some nice way of dealing with tolerance stacking. The overlapping stickers (bottom-right) on the photo above would drive me mad! :)
+
+I went ahead and [raised an issue](https://github.com/terinjokes/StickerConstructorSpec/issues/18) in case they want to deal with this in the specification by having a(some?) guide specification(s) too.
+"""]]
diff --git a/doc/stickers/hex.svg b/doc/stickers/hex.svg
new file mode 100644
index 0000000000..9d9e222eb3
--- /dev/null
+++ b/doc/stickers/hex.svg
@@ -0,0 +1,1017 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="220mm"
+   height="110mm"
+   viewBox="0 0 779.52757 389.76378"
+   id="svg5535"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="hex.svg">
+  <defs
+     id="defs5537">
+    <clipPath
+       id="clip1">
+      <path
+         inkscape:connector-curvature="0"
+         d="m 0,340.15625 481.89062,0 L 481.89062,0 0,0 0,340.15625 Z m 0,0"
+         id="path7" />
+    </clipPath>
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.32"
+     inkscape:cx="201.37678"
+     inkscape:cy="300.86122"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="false"
+     showguides="true"
+     inkscape:window-width="800"
+     inkscape:window-height="730"
+     inkscape:window-x="0"
+     inkscape:window-y="12"
+     inkscape:window-maximized="0"
+     units="mm">
+    <inkscape:grid
+       type="xygrid"
+       id="grid3730" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata5540">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title></dc:title>
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:groupmode="layer"
+     id="layer2"
+     inkscape:label="guides"
+     style="display:inline"
+     transform="translate(0,-662.59842)">
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="M 325.6126,1538.1481 518.7035,1339.6027"
+       id="path4177"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 325.8853,1538.6936 76.9091,-132.8182"
+       id="path3841"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="M 401.9762,1538.9663 325.3398,1405.0572"
+       id="path3843"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="M 401.4307,1538.6936 209.9762,1338.5118"
+       id="path4179"
+       inkscape:connector-curvature="0" />
+    <path
+       style="display:none;fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="M 231.27273,631.81675 153.81818,498.18039"
+       id="path3851"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 441.2489,1339.0572 c 0.5455,268.3636 0.5455,268.3636 0.5455,268.3636"
+       id="path4171"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 171.7944,1404.5118 153.2727,1.0909"
+       id="path3849"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 286.8853,1339.0572 -76.9091,133.0909"
+       id="path3847"
+       inkscape:connector-curvature="0" />
+    <path
+       inkscape:connector-curvature="0"
+       id="path4193"
+       d="m 517.4996,1338.5586 c 0.5454,268.3636 0.5454,268.3636 0.5454,268.3636"
+       style="display:inline;fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 479.6507,1539.6233 0,-220.6174"
+       id="path4232"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 441.0812,1472.8981 77.5246,133.0646"
+       id="path4230"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 517.0631,1472.8981 c -75.2105,133.4503 -75.2105,133.4503 -75.2105,133.4503"
+       id="path4228"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="M 516.5216,1472.1481 326.158,1272.5118"
+       id="path4293"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="M 287.1891,1472.5124 210.8215,1338.2907"
+       id="path4314"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="M 632.7035,1273.0572 C 442.3398,1472.6936 442.3398,1472.6936 442.3398,1472.6936"
+       id="path4310"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="M 210.0502,1472.5124 402.5118,1273.1083"
+       id="path4325"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 287.5748,1207.9259 -77.1389,263.0437"
+       id="path4341"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="M 94.7275,1271.1798 286.032,1472.5124"
+       id="path4339"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 305.4307,1372.3299 -121.6363,69.8182"
+       id="path4367"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 249.2489,1405.0572 0,80.7273"
+       id="path4365"
+       inkscape:connector-curvature="0" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:35px;line-height:50%;font-family:Sans;-inkscape-font-specification:'Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="304.93979"
+       y="592.7428"
+       id="text5006"
+       sodipodi:linespacing="50%"><tspan
+         sodipodi:role="line"
+         id="tspan5010"
+         x="304.93979"
+         y="592.7428" /></text>
+    <flowRoot
+       xml:space="preserve"
+       id="flowRoot5012"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:5px;line-height:50%;font-family:Sans;-inkscape-font-specification:'Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"><flowRegion
+         id="flowRegion5014"><rect
+           id="rect5016"
+           width="132.58252"
+           height="37.565048"
+           x="174.56699"
+           y="544.12921" /></flowRegion><flowPara
+         id="flowPara5018" /></flowRoot>    <flowRoot
+       xml:space="preserve"
+       id="flowRoot5020"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:5px;line-height:50%;font-family:Sans;-inkscape-font-specification:'Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"><flowRegion
+         id="flowRegion5022"><rect
+           id="rect5024"
+           width="159.09903"
+           height="70.710678"
+           x="150.26019"
+           y="519.82239" /></flowRegion><flowPara
+         id="flowPara5026" /></flowRoot>    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:5px;line-height:50%;font-family:Sans;-inkscape-font-specification:'Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="243.06796"
+       y="583.90393"
+       id="text5028"
+       sodipodi:linespacing="50%"><tspan
+         sodipodi:role="line"
+         id="tspan5030"
+         x="243.06796"
+         y="583.90393" /></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:35px;line-height:100%;font-family:Sans;-inkscape-font-specification:'Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="303.64539"
+       y="1196.0898"
+       id="text5032"
+       sodipodi:linespacing="100%"><tspan
+         sodipodi:role="line"
+         id="tspan5034"
+         x="303.64539"
+         y="1196.0898">workshop</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:22.5px;line-height:80.00000119%;font-family:Sans;-inkscape-font-specification:'Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="795.43005"
+       y="817.12488"
+       id="text5052"
+       sodipodi:linespacing="80.000001%"><tspan
+         sodipodi:role="line"
+         id="tspan5054"
+         x="795.43005"
+         y="817.12488">&lt;- cut</tspan><tspan
+         sodipodi:role="line"
+         x="795.43005"
+         y="835.12488"
+         id="tspan5056">after</tspan><tspan
+         sodipodi:role="line"
+         x="795.43005"
+         y="853.12488"
+         id="tspan5058">printing -&gt;</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:35px;line-height:100%;font-family:Sans;-inkscape-font-specification:'Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="834.16504"
+       y="53.573872"
+       id="text5060"
+       sodipodi:linespacing="100%"><tspan
+         sodipodi:role="line"
+         id="tspan5062"
+         x="834.16504"
+         y="53.573872" /></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:35px;line-height:100%;font-family:Sans;-inkscape-font-specification:'Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="1068.3942"
+       y="556.28259"
+       id="text5064"
+       sodipodi:linespacing="100%"><tspan
+         sodipodi:role="line"
+         id="tspan5066"
+         x="1068.3942"
+         y="556.28259" /></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:35px;line-height:100%;font-family:Sans;-inkscape-font-specification:'Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="31.25"
+       y="1105.4872"
+       id="text3511"
+       sodipodi:linespacing="100%"><tspan
+         sodipodi:role="line"
+         id="tspan3513"
+         x="31.25"
+         y="1105.4872">(remove yellow borders before printing)</tspan></text>
+  </g>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(0,-662.59842)">
+    <path
+       d="m 288.0751,1205.5751 -77.0088,0 -38.505,66.6925 38.505,66.6925 77.0088,0 38.505,-66.6925 -38.505,-66.6925 z"
+       style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="path3770"
+       inkscape:connector-curvature="0" />
+    <path
+       d="m 172.3513,1271.5836 -77.0087,0 -38.505,66.6925 38.505,66.6925 77.0087,0 38.505,-66.6925 -38.505,-66.6925 z"
+       style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="path3772"
+       inkscape:connector-curvature="0" />
+    <path
+       d="m 403.2324,1272.7809 -77.0087,0 -38.505,66.6925 38.505,66.6925 77.0087,0 38.505,-66.6925 -38.505,-66.6925 z"
+       style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="path3776"
+       inkscape:connector-curvature="0" />
+    <path
+       inkscape:connector-curvature="0"
+       id="path3780"
+       style="display:inline;fill:#ffff00;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 403.0232,1405.6381 -77.0087,0 -38.505,66.6925 38.505,66.6925 77.0087,0 38.505,-66.6925 -38.505,-66.6925 z" />
+    <path
+       d="m 518.2852,1472.9918 -77.0087,0 -38.505,66.6925 38.505,66.6925 77.0087,0 38.505,-66.6925 -38.505,-66.6925 z"
+       style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="path3782"
+       inkscape:connector-curvature="0" />
+    <path
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="ccccccccccccccccccc"
+       id="path1927"
+       d="m 361.244,1519.695 c -4.9886,-0.6427 -10.1226,-5.3595 -10.8399,-10.8931 -0.6879,-4.6263 0.3046,-10.0263 4.1288,-13.0794 1.6773,-1.1432 3.959,-2.4242 5.971,-2.2718 0.06,2.0481 -0.06,4.5376 0,6.5857 -2.3965,0.2668 -4.7163,2.9908 -4.6681,5.4849 0.059,3.2457 1.4952,6.2278 4.6179,7.1992 3.4541,1.1622 7.4079,0.8316 10.6054,-1.1006 2.6413,-2.058 2.8857,-5.8898 1.5042,-8.8058 -0.6214,-1.6046 -1.961,-2.7827 -3.7792,-2.7777 l 0,5.7124 -5.1268,0 0,-12.2981 15.5251,0 0,4.4225 -4.2524,0.039 c 3.9682,2.2621 4.3749,7.1442 4.1716,10.5313 0.1429,5.8185 -5.6054,10.5624 -11.3067,11.1967 -2.0627,0.1546 -3.808,0.1628 -6.5509,0.054 z"
+       style="fill:#000000;fill-opacity:1" />
+    <path
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="ccccc"
+       id="path1925"
+       d="m 350.1524,1491.0078 -0.033,-6.454 29.1036,0 0,6.485 -29.0677,-0.031 z"
+       style="fill:#40bf4c;fill-opacity:1" />
+    <path
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="ccccccccccccc"
+       id="path1917"
+       d="m 361.2446,1482.2867 0,-6.9069 -11.283,0 0,-6.0105 11.283,0 0,-7.7504 6.7486,0 0,7.7504 11.2302,0 0,6.0105 -11.2302,0 -0.1112,6.8925 -6.6374,0.014 z"
+       style="fill:#ff0000;fill-opacity:1" />
+    <path
+       inkscape:connector-curvature="0"
+       style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+       d="m 421.0825,1439.8168 1.0226,11.5259 -3.2195,-1.897 c -0.535,0.8922 -1.1307,1.7304 -1.7687,2.5149 l -4.6621,-3.5184 c 0.4505,-0.5552 0.8728,-1.4186 1.2524,-2.0477 l -3.2025,-1.887 z"
+       id="path2836"
+       sodipodi:nodetypes="cccccccc"
+       inkscape:transform-center-x="-7.5938808"
+       inkscape:transform-center-y="-14.892703" />
+    <path
+       sodipodi:nodetypes="cc"
+       inkscape:connector-curvature="0"
+       id="path4173"
+       d="m 381.5079,1472.0799 c 13.1692,0.9841 18.358,-2.9516 32.181,-19.8195"
+       style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1" />
+    <path
+       inkscape:transform-center-y="-14.892703"
+       inkscape:transform-center-x="-7.5938808"
+       sodipodi:nodetypes="cccccccc"
+       id="path4234"
+       d="m 421.0825,1439.8168 1.0226,11.5259 -3.2195,-1.897 c -0.535,0.8922 -1.1307,1.7304 -1.7687,2.5149 l -4.6621,-3.5184 c 0.4505,-0.5552 0.8728,-1.4186 1.2524,-2.0477 l -3.2025,-1.887 z"
+       style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+       inkscape:connector-curvature="0" />
+    <path
+       inkscape:transform-center-y="-14.892703"
+       inkscape:transform-center-x="-7.5938808"
+       sodipodi:nodetypes="cccccccc"
+       id="path4234-6"
+       d="m 421.0825,1439.8168 1.0226,11.5259 -3.2195,-1.897 c -0.535,0.8922 -1.1307,1.7304 -1.7687,2.5149 l -4.6621,-3.5184 c 0.4505,-0.5552 0.8728,-1.4186 1.2524,-2.0477 l -3.2025,-1.887 z"
+       style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+       inkscape:connector-curvature="0" />
+    <g
+       id="g4200"
+       transform="matrix(-1,0,0,1,672.584,839.94568)">
+      <path
+         inkscape:connector-curvature="0"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         d="m 364.9245,600.03084 1.0226,11.52597 -3.21949,-1.89699 c -0.53498,0.89217 -1.13069,1.7304 -1.76867,2.51487 l -4.66214,-3.51845 c 0.45046,-0.55521 0.8728,-1.41853 1.25235,-2.04767 l -3.20246,-1.88696 z"
+         id="path4202"
+         sodipodi:nodetypes="cccccccc"
+         inkscape:transform-center-x="-7.5938808"
+         inkscape:transform-center-y="-14.892703" />
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path4204"
+         d="m 325.34987,632.29397 c 13.1692,0.98414 18.35807,-2.95155 32.18101,-19.81947"
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1" />
+    </g>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:5px;line-height:125%;font-family:Sans;-inkscape-font-specification:'Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="295"
+       y="612.36218"
+       id="text4210"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan4214"
+         x="295"
+         y="612.36218" /></text>
+    <g
+       id="g4296"
+       transform="translate(56.158,839.78592)">
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path3369"
+         d="m 368.32919,596.00324 c 16.28841,-12.44463 11.95901,-34.92532 5.48374,-49.13832"
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1" />
+      <path
+         inkscape:connector-curvature="0"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         d="m 366.86495,534.32461 10.72674,4.33949 -3.1552,2.00212 c 0.55054,0.88265 1.02545,1.79476 1.43327,2.72001 l -5.25579,2.54784 c -0.28914,-0.65386 -0.86528,-1.4231 -1.25249,-2.04757 l -3.13851,1.99153 z"
+         id="path4288"
+         sodipodi:nodetypes="cccccccc"
+         inkscape:transform-center-x="-4.9547788"
+         inkscape:transform-center-y="-2.0479419" />
+    </g>
+    <g
+       id="g4268"
+       transform="translate(78.15537,281.85591)">
+      <path
+         d="m 462.58897,499.84363 -77.00875,0 -38.505,66.6925 38.505,66.6925 77.00875,0 38.505,-66.6925 -38.505,-66.6925 z"
+         style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         id="path3778"
+         inkscape:connector-curvature="0" />
+      <g
+         id="g4262">
+        <path
+           sodipodi:nodetypes="cc"
+           inkscape:connector-curvature="0"
+           id="path4264"
+           d="m 369.14737,596.54869 c 179.79378,-174.98868 95.13045,83.3911 55.1201,-80.50195"
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1" />
+        <path
+           inkscape:transform-center-y="-18.010798"
+           inkscape:transform-center-x="0.7747508"
+           sodipodi:nodetypes="cccccccc"
+           id="path4266"
+           d="m 422.69966,500.95772 -6.24535,9.74111 3.73197,-0.18982 c 0.0609,1.03849 0.20054,2.05731 0.40251,3.04807 l 5.7616,-0.95861 c -0.14198,-0.70071 -0.11643,-1.66145 -0.16137,-2.39484 l 3.71224,-0.18884 z"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           inkscape:connector-curvature="0" />
+      </g>
+    </g>
+    <g
+       id="g4278"
+       transform="matrix(-1,0,0,1,682.6161,291.09305)">
+      <g
+         id="g4865">
+        <path
+           transform="matrix(-1,0,0,1,646.48904,412.98535)"
+           inkscape:connector-curvature="0"
+           id="path4276"
+           style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+           d="m 183.90007,86.85828 77.00875,0 38.505,66.6925 -38.505,66.6925 -77.00875,0 -38.505,-66.6925 38.505,-66.6925 z" />
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1"
+           d="m 369.14737,596.54869 c 212.57536,-152.79796 34.16912,123.05809 55.1201,-80.50195"
+           id="path4280"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+        <path
+           inkscape:connector-curvature="0"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           d="m 422.69966,500.95772 -6.24535,9.74111 3.73197,-0.18982 c 0.0609,1.03849 0.20054,2.05731 0.40251,3.04807 l 5.7616,-0.95861 c -0.14198,-0.70071 -0.11643,-1.66145 -0.16137,-2.39484 l 3.71224,-0.18884 z"
+           id="path4282"
+           sodipodi:nodetypes="cccccccc"
+           inkscape:transform-center-x="0.7747508"
+           inkscape:transform-center-y="-18.010798" />
+      </g>
+      <g
+         id="g4870">
+        <path
+           sodipodi:nodetypes="cc"
+           inkscape:connector-curvature="0"
+           id="path4874"
+           d="m 369.14737,596.54869 c 212.57536,-152.79796 34.16912,123.05809 55.1201,-80.50195"
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1" />
+        <path
+           inkscape:transform-center-y="-18.010798"
+           inkscape:transform-center-x="0.7747508"
+           sodipodi:nodetypes="cccccccc"
+           id="path4876"
+           d="m 422.69966,500.95772 -6.24535,9.74111 3.73197,-0.18982 c 0.0609,1.03849 0.20054,2.05731 0.40251,3.04807 l 5.7616,-0.95861 c -0.14198,-0.70071 -0.11643,-1.66145 -0.16137,-2.39484 l 3.71224,-0.18884 z"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           inkscape:connector-curvature="0" />
+      </g>
+    </g>
+    <path
+       inkscape:connector-curvature="0"
+       id="path4286"
+       style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 518.3442,1339.9866 -77.0088,0 -38.505,66.6925 38.505,66.6925 77.0088,0 38.505,-66.6925 -38.505,-66.6925 z" />
+    <g
+       id="g4300"
+       transform="matrix(-1,0,0,1,903.4486,839.49381)">
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1"
+         d="m 368.32919,596.00324 c 16.28841,-12.44463 11.95901,-34.92532 5.48374,-49.13832"
+         id="path4302"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+      <path
+         inkscape:transform-center-y="-2.0479419"
+         inkscape:transform-center-x="-4.9547788"
+         sodipodi:nodetypes="cccccccc"
+         id="path4304"
+         d="m 366.86495,534.32461 10.72674,4.33949 -3.1552,2.00212 c 0.55054,0.88265 1.02545,1.79476 1.43327,2.72001 l -5.25579,2.54784 c -0.28914,-0.65386 -0.86528,-1.4231 -1.25249,-2.04757 l -3.13851,1.99153 z"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         inkscape:connector-curvature="0" />
+    </g>
+    <path
+       inkscape:connector-curvature="0"
+       id="path4306"
+       style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 633.9707,1406.4858 -77.0088,0 -38.505,66.6925 38.505,66.6925 77.0088,0 38.505,-66.6925 -38.505,-66.6925 z" />
+    <path
+       d="m 633.9707,1273.1689 -77.0088,0 -38.505,66.6925 38.505,66.6925 77.0088,0 38.505,-66.6925 -38.505,-66.6925 z"
+       style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="path4308"
+       inkscape:connector-curvature="0" />
+    <g
+       id="g4329" />
+    <g
+       id="g4353" />
+    <g
+       id="g4386"
+       transform="translate(56.158,839.78592)">
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1"
+         d="m 368.32919,596.00324 c 16.28841,-12.44463 11.95901,-34.92532 5.48374,-49.13832"
+         id="path4388"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+      <path
+         inkscape:transform-center-y="-2.0479419"
+         inkscape:transform-center-x="-4.9547788"
+         sodipodi:nodetypes="cccccccc"
+         id="path4390"
+         d="m 366.86495,534.32461 10.72674,4.33949 -3.1552,2.00212 c 0.55054,0.88265 1.02545,1.79476 1.43327,2.72001 l -5.25579,2.54784 c -0.28914,-0.65386 -0.86528,-1.4231 -1.25249,-2.04757 l -3.13851,1.99153 z"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         inkscape:connector-curvature="0" />
+    </g>
+    <g
+       id="g4400"
+       transform="translate(391.60209,6.75397)">
+      <g
+         transform="translate(111.34978,210.75404)"
+         id="g4375">
+        <path
+           d="m 231.07321,499.9747 -77.00876,0 -38.505,66.6925 38.505,66.69249 77.00876,0 38.505,-66.69249 -38.505,-66.6925 z"
+           style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+           id="path626"
+           inkscape:connector-curvature="0" />
+        <path
+           sodipodi:nodetypes="cc"
+           inkscape:connector-curvature="0"
+           id="path4319"
+           d="m 249.29398,597.77999 c -7.62767,-9.76104 -74.35507,-18.74907 -10.66556,-55.41105"
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1" />
+        <path
+           inkscape:connector-curvature="0"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           d="m 249.2985,533.94593 -3.05391,11.16099 -2.35772,-2.89913 c -0.81214,0.65008 -1.66238,1.2285 -2.53352,1.74184 l -3.14561,-4.92138 c 0.61552,-0.36371 1.31203,-1.02593 1.88688,-1.48358 l -2.34526,-2.88379 z"
+           id="path4321"
+           sodipodi:nodetypes="cccccccc"
+           inkscape:transform-center-x="-0.8537788"
+           inkscape:transform-center-y="-5.2672031" />
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1"
+           d="m 192.65946,503.68994 c -5.55525,6.2109 -9.2174,75.03571 -47.31146,41.52113"
+           id="path4347"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+        <path
+           inkscape:transform-center-y="-5.2672031"
+           inkscape:transform-center-x="-0.8537788"
+           sodipodi:nodetypes="cccccccc"
+           id="path4349"
+           d="m 136.1536,533.7696 11.16099,3.05391 -2.89913,2.35772 c 0.65008,0.81214 1.2285,1.66238 1.74184,2.53352 l -4.92138,3.14561 c -0.36371,-0.61552 -1.02593,-1.31203 -1.48358,-1.88688 l -2.88379,2.34526 z"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           inkscape:connector-curvature="0" />
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1"
+           d="m 137.82586,596.30242 c 2.73241,5.35647 49.24076,-69.47997 55.40614,19.54145"
+           id="path4359"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+        <path
+           inkscape:transform-center-y="-1.9921231"
+           inkscape:transform-center-x="3.1470162"
+           sodipodi:nodetypes="cccccccc"
+           id="path4361"
+           d="m 192.94014,632.35933 -7.22736,-9.03656 3.73144,-0.20046 c -0.0478,-1.03918 -0.0152,-2.067 0.0824,-3.07343 l 5.83015,0.3524 c -0.0681,0.71169 0.0575,1.66452 0.0893,2.39861 l 3.7117,-0.19942 z"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           inkscape:connector-curvature="0" />
+      </g>
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path4394"
+         d="m 342.11112,710.63678 -39.34085,66.72517"
+         style="fill:none;fill-rule:evenodd;stroke:#f8ff00;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path4396"
+         d="m 226.78843,777.74764 75.98184,-0.3857"
+         style="fill:#000000;fill-opacity:0;fill-rule:evenodd;stroke:#fffb00;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path4398"
+         d="M 342.11112,843.70142 303.54166,777.36195"
+         style="fill:none;fill-rule:evenodd;stroke:#ffe900;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+    </g>
+    <g
+       transform="translate(245.16964,204.81767)"
+       id="g4622">
+      <path
+         d="m 175.5925,655.30669 -77.00876,0 -38.505,66.6925 38.505,66.69249 77.00876,0 38.505,-66.69249 -38.505,-66.6925 z"
+         style="display:inline;fill:#ffff00;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         id="path4624"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:#000000;fill-opacity:1"
+         d="m 133.81328,769.36362 c -4.98858,-0.64265 -10.12259,-5.35945 -10.83989,-10.89312 -0.68794,-4.62623 0.30456,-10.02623 4.12875,-13.07935 1.67733,-1.14327 3.959,-2.42422 5.97107,-2.27178 0.0603,2.0481 -0.0603,4.53751 0,6.58561 -2.39655,0.26682 -4.71638,2.99081 -4.6681,5.48492 0.0587,3.24569 1.4952,6.2278 4.61788,7.1992 3.45403,1.16223 7.40791,0.83167 10.60533,-1.10057 2.64137,-2.05802 2.88574,-5.8898 1.50423,-8.8058 -0.62143,-1.60464 -1.96101,-2.78268 -3.77919,-2.77775 l 0,5.71246 -5.12679,0 0,-12.29807 15.52512,0 0,4.42245 -4.25241,0.0393 c 3.96819,2.26207 4.37493,7.14424 4.17158,10.53133 0.14295,5.81845 -5.6054,10.56238 -11.30674,11.19666 -2.06269,0.15465 -3.80795,0.16279 -6.55084,0.0545 z"
+         id="path4626"
+         sodipodi:nodetypes="ccccccccccccccccccc"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:#40bf4c;fill-opacity:1"
+         d="m 122.72168,740.67638 -0.0326,-6.45396 29.10361,0 -0.003,6.48504 -29.06768,-0.0311 z"
+         id="path4628"
+         sodipodi:nodetypes="ccccc"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:#ff0000;fill-opacity:1"
+         d="m 133.81384,731.95529 0,-6.90684 -11.28293,0 0,-6.01053 11.28293,0 0,-7.75042 6.74866,0 0,7.75042 11.2302,0 0,6.01053 -11.2302,0 -0.11125,6.89243 -6.63741,0.0144 z"
+         id="path4630"
+         sodipodi:nodetypes="ccccccccccccc"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1"
+         d="m 154.07714,721.74852 c 13.1692,0.98414 18.35807,-2.95155 32.18101,-19.81947"
+         id="path4632"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+      <path
+         inkscape:connector-curvature="0"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         d="m 193.65177,689.48539 1.0226,11.52597 -3.21949,-1.89699 c -0.53498,0.89217 -1.13069,1.7304 -1.76867,2.51487 l -4.66214,-3.51845 c 0.45046,-0.55521 0.8728,-1.41853 1.25235,-2.04767 l -3.20246,-1.88696 z"
+         id="path4634"
+         sodipodi:nodetypes="cccccccc"
+         inkscape:transform-center-x="-7.5938808"
+         inkscape:transform-center-y="-14.892703" />
+      <g
+         transform="matrix(-1,0,0,1,445.15327,89.614307)"
+         id="g4636">
+        <path
+           inkscape:transform-center-y="-14.892703"
+           inkscape:transform-center-x="-7.5938808"
+           sodipodi:nodetypes="cccccccc"
+           id="path4638"
+           d="m 364.9245,600.03084 1.0226,11.52597 -3.21949,-1.89699 c -0.53498,0.89217 -1.13069,1.7304 -1.76867,2.51487 l -4.66214,-3.51845 c 0.45046,-0.55521 0.8728,-1.41853 1.25235,-2.04767 l -3.20246,-1.88696 z"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           inkscape:connector-curvature="0" />
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1"
+           d="m 325.34987,632.29397 c 13.1692,0.98414 18.35807,-2.95155 32.18101,-19.81947"
+           id="path4640"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+      </g>
+    </g>
+    <g
+       transform="translate(1119.7747,19.39156)"
+       id="g4642">
+      <g
+         id="g4644"
+         transform="translate(77.454547,62.727274)">
+        <path
+           sodipodi:nodetypes="cc"
+           inkscape:connector-curvature="0"
+           id="path4646"
+           d="m -106.81811,732.93789 c -7.62767,-9.76104 -74.35507,-18.74907 -10.66556,-55.41105"
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1" />
+        <path
+           inkscape:connector-curvature="0"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           d="m -106.81359,669.10383 -3.05391,11.16099 -2.35772,-2.89913 c -0.81214,0.65008 -1.66238,1.2285 -2.53352,1.74184 l -3.14561,-4.92138 c 0.61552,-0.36371 1.31203,-1.02593 1.88688,-1.48358 l -2.34526,-2.88379 z"
+           id="path4648"
+           sodipodi:nodetypes="cccccccc"
+           inkscape:transform-center-x="-0.8537788"
+           inkscape:transform-center-y="-5.2672031" />
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#f8ff00;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+           d="m -125.35075,635.04064 -39.34085,66.72517"
+           id="path4650"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ffe900;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+           d="m -125.35075,768.10528 -38.56946,-66.33947"
+           id="path4652"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+      </g>
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#f9ff00;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+         d="m -48.545453,698.36219 39.272726,65.45455 -38.727276,66"
+         id="path4654"
+         inkscape:connector-curvature="0" />
+    </g>
+    <g
+       transform="translate(1120.3201,-101.15389)"
+       id="g4656">
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1"
+         d="m -97.179901,820.75693 c -5.555249,6.2109 -9.217399,75.03571 -47.311459,41.52113"
+         id="path4658"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+      <path
+         inkscape:transform-center-y="-5.2672031"
+         inkscape:transform-center-x="-0.8537788"
+         sodipodi:nodetypes="cccccccc"
+         id="path4660"
+         d="m -153.68576,850.83659 11.16099,3.05391 -2.89913,2.35772 c 0.65008,0.81214 1.2285,1.66238 1.74184,2.53352 l -4.92138,3.14561 c -0.36371,-0.61552 -1.02593,-1.31203 -1.48358,-1.88688 l -2.88379,2.34526 z"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:#000000;fill-opacity:0;fill-rule:evenodd;stroke:#fffb00;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         d="m -174.40071,884.06059 75.981839,-0.3857"
+         id="path4662"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+      <path
+         inkscape:connector-curvature="0"
+         id="path4664"
+         d="m -99.000001,883.54402 39.81818,-66.81819"
+         style="fill:none;fill-rule:evenodd;stroke:#fff700;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+      <path
+         inkscape:connector-curvature="0"
+         id="path4666"
+         d="m -59.463711,816.94972 -76.753229,0 -38.56946,66.33948"
+         style="fill:none;fill-rule:evenodd;stroke:#f0ff00;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+    </g>
+    <g
+       transform="translate(1121.9565,-101.69934)"
+       id="g4668">
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1"
+         d="m -156.10441,923.00578 c 2.73241,5.35647 49.24076,-69.47997 55.40614,19.54145"
+         id="path4670"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+      <path
+         inkscape:transform-center-y="-1.9921231"
+         inkscape:transform-center-x="3.1470162"
+         sodipodi:nodetypes="cccccccc"
+         id="path4672"
+         d="m -100.99013,959.06269 -7.22736,-9.03656 3.73144,-0.20046 c -0.0478,-1.03918 -0.0152,-2.067 0.0824,-3.07343 l 5.830147,0.3524 c -0.0681,0.71169 0.0575,1.66452 0.0893,2.39861 l 3.7117,-0.19942 z"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:#000000;fill-opacity:0;fill-rule:evenodd;stroke:#fffb00;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         d="m -178.49162,893.69696 75.98184,-0.3857"
+         id="path4674"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+      <path
+         inkscape:connector-curvature="0"
+         id="path4676"
+         d="m -103.90909,893.18039 40.909087,67.09091"
+         style="fill:none;fill-rule:evenodd;stroke:#f3ff00;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+      <path
+         inkscape:connector-curvature="0"
+         id="path4678"
+         d="m -178.63637,893.72584 39.27273,66.81818 76.363637,-0.54545"
+         style="fill:none;fill-rule:evenodd;stroke:#ffe800;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+    </g>
+    <g
+       id="g4722"
+       transform="translate(-68.56602,362.48887)">
+      <path
+         d="m 231.51016,498.82244 -77.00876,0 -38.505,66.6925 38.505,66.69249 77.00876,0 38.505,-66.69249 -38.505,-66.6925 z"
+         style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         id="path4384"
+         inkscape:connector-curvature="0" />
+      <path
+         sodipodi:nodetypes="csc"
+         inkscape:connector-curvature="0"
+         id="path4692"
+         d="m 248.23414,597.36687 c -12.08969,-7.29009 -21.44443,-80.08465 -50.01457,-3.56579 -18.39769,49.27419 -42.43019,-41.02463 -51.52732,-48.47894"
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1" />
+      <path
+         inkscape:connector-curvature="0"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         d="m 136.03878,533.85322 1.62247,11.45695 2.7044,-2.57875 c 0.7237,0.74728 1.49423,1.42828 2.29371,2.04734 l 3.74095,-4.48555 c -0.56476,-0.4384 -1.17222,-1.18315 -1.68478,-1.70962 l 2.6901,-2.56512 z"
+         id="path4694"
+         sodipodi:nodetypes="cccccccc"
+         inkscape:transform-center-x="-0.4755438"
+         inkscape:transform-center-y="-5.8683169" />
+    </g>
+    <g
+       id="g4711"
+       transform="matrix(-1,0,0,1,318.82406,215.12694)">
+      <path
+         inkscape:connector-curvature="0"
+         id="path4713"
+         style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         d="m 231.51016,498.82244 -77.00876,0 -38.505,66.6925 38.505,66.69249 77.00876,0 38.505,-66.69249 -38.505,-66.6925 z" />
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1"
+         d="m 248.23414,597.36687 c -12.08969,-7.29009 -18.12987,-116.54484 -46.70001,-40.02598 -18.39769,49.27419 -45.74475,-4.56444 -54.84188,-12.01875"
+         id="path4715"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="csc" />
+      <path
+         inkscape:transform-center-y="-5.8683169"
+         inkscape:transform-center-x="-0.4755438"
+         sodipodi:nodetypes="cccccccc"
+         id="path4717"
+         d="m 136.03878,533.85322 1.62247,11.45695 2.7044,-2.57875 c 0.7237,0.74728 1.49423,1.42828 2.29371,2.04734 l 3.74095,-4.48555 c -0.56476,-0.4384 -1.17222,-1.18315 -1.68478,-1.70962 l 2.6901,-2.56512 z"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         inkscape:connector-curvature="0" />
+    </g>
+    <g
+       transform="matrix(-1,0,0,1,991.43724,158.30858)"
+       id="g4743">
+      <g
+         id="g4745"
+         transform="translate(111.34978,210.75404)">
+        <path
+           inkscape:connector-curvature="0"
+           id="path4747"
+           style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+           d="m 231.07321,499.9747 -77.00876,0 -38.505,66.6925 38.505,66.69249 77.00876,0 38.505,-66.69249 -38.505,-66.6925 z" />
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1"
+           d="m 249.29398,597.77999 c -7.62767,-9.76104 -74.35507,-18.74907 -10.66556,-55.41105"
+           id="path4749"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+        <path
+           inkscape:transform-center-y="-5.2672031"
+           inkscape:transform-center-x="-0.8537788"
+           sodipodi:nodetypes="cccccccc"
+           id="path4751"
+           d="m 249.2985,533.94593 -3.05391,11.16099 -2.35772,-2.89913 c -0.81214,0.65008 -1.66238,1.2285 -2.53352,1.74184 l -3.14561,-4.92138 c 0.61552,-0.36371 1.31203,-1.02593 1.88688,-1.48358 l -2.34526,-2.88379 z"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           inkscape:connector-curvature="0" />
+        <path
+           sodipodi:nodetypes="cc"
+           inkscape:connector-curvature="0"
+           id="path4753"
+           d="m 192.65946,503.68994 c -5.55525,6.2109 -9.2174,75.03571 -47.31146,41.52113"
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1" />
+        <path
+           inkscape:connector-curvature="0"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           d="m 136.1536,533.7696 11.16099,3.05391 -2.89913,2.35772 c 0.65008,0.81214 1.2285,1.66238 1.74184,2.53352 l -4.92138,3.14561 c -0.36371,-0.61552 -1.02593,-1.31203 -1.48358,-1.88688 l -2.88379,2.34526 z"
+           id="path4755"
+           sodipodi:nodetypes="cccccccc"
+           inkscape:transform-center-x="-0.8537788"
+           inkscape:transform-center-y="-5.2672031" />
+        <path
+           sodipodi:nodetypes="cc"
+           inkscape:connector-curvature="0"
+           id="path4757"
+           d="m 137.82586,596.30242 c 2.73241,5.35647 49.24076,-69.47997 55.40614,19.54145"
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1" />
+        <path
+           inkscape:connector-curvature="0"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           d="m 192.94014,632.35933 -7.22736,-9.03656 3.73144,-0.20046 c -0.0478,-1.03918 -0.0152,-2.067 0.0824,-3.07343 l 5.83015,0.3524 c -0.0681,0.71169 0.0575,1.66452 0.0893,2.39861 l 3.7117,-0.19942 z"
+           id="path4759"
+           sodipodi:nodetypes="cccccccc"
+           inkscape:transform-center-x="3.1470162"
+           inkscape:transform-center-y="-1.9921231" />
+      </g>
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#f8ff00;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         d="m 342.11112,710.63678 -39.34085,66.72517"
+         id="path4761"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+      <path
+         style="fill:#000000;fill-opacity:0;fill-rule:evenodd;stroke:#fffb00;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         d="m 226.78843,777.74764 75.98184,-0.3857"
+         id="path4763"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#ffe900;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         d="M 342.11112,843.70142 303.54166,777.36195"
+         id="path4765"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+    </g>
+    <g
+       id="g4767"
+       transform="matrix(-1,0,0,1,926.46374,167.44204)">
+      <g
+         transform="translate(77.454547,62.727274)"
+         id="g4769">
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1"
+           d="m -106.81811,732.93789 c -7.62767,-9.76104 -74.35507,-18.74907 -10.66556,-55.41105"
+           id="path4771"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+        <path
+           inkscape:transform-center-y="-5.2672031"
+           inkscape:transform-center-x="-0.8537788"
+           sodipodi:nodetypes="cccccccc"
+           id="path4773"
+           d="m -106.81359,669.10383 -3.05391,11.16099 -2.35772,-2.89913 c -0.81214,0.65008 -1.66238,1.2285 -2.53352,1.74184 l -3.14561,-4.92138 c 0.61552,-0.36371 1.31203,-1.02593 1.88688,-1.48358 l -2.34526,-2.88379 z"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           inkscape:connector-curvature="0" />
+        <path
+           sodipodi:nodetypes="cc"
+           inkscape:connector-curvature="0"
+           id="path4775"
+           d="m -125.35075,635.04064 -39.34085,66.72517"
+           style="fill:none;fill-rule:evenodd;stroke:#f8ff00;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+        <path
+           sodipodi:nodetypes="cc"
+           inkscape:connector-curvature="0"
+           id="path4777"
+           d="m -125.35075,768.10528 -38.56946,-66.33947"
+           style="fill:none;fill-rule:evenodd;stroke:#ffe900;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+      </g>
+      <path
+         inkscape:connector-curvature="0"
+         id="path4779"
+         d="m -48.545453,698.36219 39.272726,65.45455 -38.727276,66"
+         style="fill:none;fill-rule:evenodd;stroke:#f9ff00;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+    </g>
+    <g
+       id="g4781"
+       transform="matrix(-1,0,0,1,925.91828,46.89659)">
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path4783"
+         d="m -97.179901,820.75693 c -5.555249,6.2109 -9.217399,75.03571 -47.311459,41.52113"
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1" />
+      <path
+         inkscape:connector-curvature="0"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         d="m -153.68576,850.83659 11.16099,3.05391 -2.89913,2.35772 c 0.65008,0.81214 1.2285,1.66238 1.74184,2.53352 l -4.92138,3.14561 c -0.36371,-0.61552 -1.02593,-1.31203 -1.48358,-1.88688 l -2.88379,2.34526 z"
+         id="path4785"
+         sodipodi:nodetypes="cccccccc"
+         inkscape:transform-center-x="-0.8537788"
+         inkscape:transform-center-y="-5.2672031" />
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path4787"
+         d="m -174.40071,884.06059 75.981839,-0.3857"
+         style="fill:#000000;fill-opacity:0;fill-rule:evenodd;stroke:#fffb00;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#fff700;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+         d="m -99.000001,883.54402 39.81818,-66.81819"
+         id="path4789"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#f0ff00;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+         d="m -59.463711,816.94972 -76.753229,0 -38.56946,66.33948"
+         id="path4791"
+         inkscape:connector-curvature="0" />
+    </g>
+    <g
+       id="g4793"
+       transform="matrix(-1,0,0,1,924.28192,46.35114)">
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path4795"
+         d="m -156.10441,923.00578 c 2.73241,5.35647 49.24076,-69.47997 55.40614,19.54145"
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1" />
+      <path
+         inkscape:connector-curvature="0"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         d="m -100.99013,959.06269 -7.22736,-9.03656 3.73144,-0.20046 c -0.0478,-1.03918 -0.0152,-2.067 0.0824,-3.07343 l 5.830147,0.3524 c -0.0681,0.71169 0.0575,1.66452 0.0893,2.39861 l 3.7117,-0.19942 z"
+         id="path4797"
+         sodipodi:nodetypes="cccccccc"
+         inkscape:transform-center-x="3.1470162"
+         inkscape:transform-center-y="-1.9921231" />
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path4799"
+         d="m -178.49162,893.69696 75.98184,-0.3857"
+         style="fill:#000000;fill-opacity:0;fill-rule:evenodd;stroke:#fffb00;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#f3ff00;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+         d="m -103.90909,893.18039 40.909087,67.09091"
+         id="path4801"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#ffe800;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+         d="m -178.63637,893.72584 39.27273,66.81818 76.363637,-0.54545"
+         id="path4803"
+         inkscape:connector-curvature="0" />
+    </g>
+    <path
+       inkscape:connector-curvature="0"
+       id="path4858"
+       style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 287.2562,1338.4273 -77.0088,0 -38.505,66.6925 38.505,66.6925 77.0088,0 38.505,-66.6925 -38.505,-66.6925 z" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:35px;line-height:100%;font-family:Sans;-inkscape-font-specification:'Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="9.375"
+       y="558.61218"
+       id="text5571"
+       sodipodi:linespacing="100%"><tspan
+         sodipodi:role="line"
+         id="tspan5573"
+         x="9.375"
+         y="558.61218">git-annex tiling stickers</tspan><tspan
+         sodipodi:role="line"
+         x="9.375"
+         y="593.61218"
+         id="tspan5577">compliant with</tspan><tspan
+         sodipodi:role="line"
+         x="9.375"
+         y="628.61218"
+         id="tspan5575">https://github.com/terinjokes/StickerConstructorSpec/</tspan></text>
+  </g>
+</svg>
diff --git a/doc/stickers/hexdemos.svg b/doc/stickers/hexdemos.svg
new file mode 100644
index 0000000000..7f956c676d
--- /dev/null
+++ b/doc/stickers/hexdemos.svg
@@ -0,0 +1,628 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:ns2="http://ns.adobe.com/AdobeIllustrator/10.0/"
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="210mm"
+   height="297mm"
+   viewBox="0 0 744.09448819 1052.3622047"
+   id="svg3720"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="hexdemos.svg">
+  <defs
+     id="defs3722">
+    <clipPath
+       id="clip1">
+      <path
+         inkscape:connector-curvature="0"
+         d="m 0,340.15625 481.89062,0 L 481.89062,0 0,0 0,340.15625 Z m 0,0"
+         id="path7" />
+    </clipPath>
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.35"
+     inkscape:cx="375"
+     inkscape:cy="520"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="false"
+     inkscape:window-width="1366"
+     inkscape:window-height="768"
+     inkscape:window-x="0"
+     inkscape:window-y="0"
+     inkscape:window-maximized="0" />
+  <metadata
+     id="metadata3725">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title></dc:title>
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1">
+    <g
+       id="g10"
+       clip-path="url(#clip1)"
+       style="clip-rule:nonzero;display:inline"
+       transform="matrix(0.10894991,0,0,0.10894991,528.54623,740.43302)">
+      <path
+         id="path12"
+         d="M 0,340.15625 113.38672,170.07812 0,0 85.039062,0 198.42578,170.07812 85.039062,340.15625 0,340.15625 Z m 0,0"
+         style="fill:#0013ec;fill-opacity:1;fill-rule:nonzero;stroke:none"
+         inkscape:connector-curvature="0" />
+      <path
+         id="path14"
+         d="M 113.38672,340.15625 226.77344,170.07812 113.38672,0 l 85.03906,0 226.76953,340.15625 -85.03906,0 -70.86328,-106.29688 -70.86719,106.29688 -85.03906,0 z m 0,0"
+         style="fill:#82a7ff;fill-opacity:1;fill-rule:nonzero;stroke:none"
+         inkscape:connector-curvature="0" />
+      <path
+         id="path16"
+         d="m 387.40234,240.94531 -37.79297,-56.6914 132.28125,-0.004 0,56.69531 -94.48828,0 z m 0,0"
+         style="fill:#0013ec;fill-opacity:1;fill-rule:nonzero;stroke:none"
+         inkscape:connector-curvature="0" />
+      <path
+         id="path18"
+         d="m 330.71094,155.90625 -37.79688,-56.691406 188.97656,-0.0039 0,56.695316 -151.17968,0 z m 0,0"
+         style="fill:#0013ec;fill-opacity:1;fill-rule:nonzero;stroke:none"
+         inkscape:connector-curvature="0" />
+    </g>
+    <g
+       style="display:inline"
+       transform="matrix(0.47991457,0,0,0.47991457,210.94383,674.58843)"
+       id="Layer_1"
+       ns2:layer="yes"
+       ns2:dimmedPercent="50"
+       ns2:rgbTrio="#4F008000FFFF">
+      <g
+         id="g7">
+        <path
+           style="fill:#a80030"
+           inkscape:connector-curvature="0"
+           ns2:knockout="Off"
+           d="m 51.986,57.297 c -1.797,0.025 0.34,0.926 2.686,1.287 0.648,-0.506 1.236,-1.018 1.76,-1.516 -1.461,0.358 -2.948,0.366 -4.446,0.229"
+           id="path9" />
+        <path
+           style="fill:#a80030"
+           inkscape:connector-curvature="0"
+           ns2:knockout="Off"
+           d="m 61.631,54.893 c 1.07,-1.477 1.85,-3.094 2.125,-4.766 -0.24,1.192 -0.887,2.221 -1.496,3.307 -3.359,2.115 -0.316,-1.256 -0.002,-2.537 -3.612,4.546 -0.496,2.726 -0.627,3.996"
+           id="path11" />
+        <path
+           style="fill:#a80030"
+           inkscape:connector-curvature="0"
+           ns2:knockout="Off"
+           d="m 65.191,45.629 c 0.217,-3.236 -0.637,-2.213 -0.924,-0.978 0.335,0.174 0.6,2.281 0.924,0.978"
+           id="path13" />
+        <path
+           style="fill:#a80030"
+           inkscape:connector-curvature="0"
+           ns2:knockout="Off"
+           d="m 45.172,1.399 c 0.959,0.172 2.072,0.304 1.916,0.533 1.049,-0.23 1.287,-0.442 -1.916,-0.533"
+           id="path15" />
+        <path
+           style="fill:#a80030"
+           inkscape:connector-curvature="0"
+           ns2:knockout="Off"
+           d="M 47.088,1.932 46.41,2.072 47.041,2.016 47.088,1.932"
+           id="path17" />
+        <path
+           style="fill:#a80030"
+           inkscape:connector-curvature="0"
+           ns2:knockout="Off"
+           d="m 32.372,59.764 -0.252,1.26 c 1.181,1.604 2.118,3.342 3.626,4.596 -1.085,-2.118 -1.891,-2.993 -3.374,-5.856"
+           id="path21" />
+        <path
+           style="fill:#a80030"
+           inkscape:connector-curvature="0"
+           ns2:knockout="Off"
+           d="m 35.164,59.654 c -0.625,-0.691 -0.995,-1.523 -1.409,-2.352 0.396,1.457 1.207,2.709 1.962,3.982 l -0.553,-1.63"
+           id="path23" />
+        <path
+           style="fill:#a80030"
+           inkscape:connector-curvature="0"
+           ns2:knockout="Off"
+           d="m 84.568,48.916 -0.264,0.662 c -0.484,3.438 -1.529,6.84 -3.131,9.994 1.77,-3.328 2.915,-6.968 3.395,-10.656"
+           id="path25" />
+        <path
+           style="fill:#a80030"
+           inkscape:connector-curvature="0"
+           ns2:knockout="Off"
+           d="M 45.527,0.537 C 46.742,0.092 48.514,0.293 49.803,0 48.123,0.141 46.451,0.225 44.8,0.438 l 0.727,0.099"
+           id="path27" />
+        <path
+           style="fill:#a80030"
+           inkscape:connector-curvature="0"
+           ns2:knockout="Off"
+           d="m 2.872,23.219 c 0.28,2.592 -1.95,3.598 0.494,1.889 1.31,-2.951 -0.512,-0.815 -0.494,-1.889"
+           id="path29" />
+        <path
+           style="fill:#a80030"
+           inkscape:connector-curvature="0"
+           ns2:knockout="Off"
+           d="M 0,35.215 C 0.563,33.487 0.665,32.449 0.88,31.449 -0.676,33.438 0.164,33.862 0,35.215"
+           id="path31" />
+      </g>
+    </g>
+    <g
+       id="g4533"
+       transform="matrix(-1,0,0,-1,337.47913,1609.9151)">
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path4511"
+         d="m -97.179901,820.75693 c -5.555249,6.2109 -9.217399,75.03571 -47.311459,41.52113"
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1" />
+      <path
+         inkscape:connector-curvature="0"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         d="m -153.68576,850.83659 11.16099,3.05391 -2.89913,2.35772 c 0.65008,0.81214 1.2285,1.66238 1.74184,2.53352 l -4.92138,3.14561 c -0.36371,-0.61552 -1.02593,-1.31203 -1.48358,-1.88688 l -2.88379,2.34526 z"
+         id="path4513"
+         sodipodi:nodetypes="cccccccc"
+         inkscape:transform-center-x="-0.8537788"
+         inkscape:transform-center-y="-5.2672031" />
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path4515"
+         d="m -174.40071,884.06059 75.981839,-0.3857"
+         style="fill:#000000;fill-opacity:0;fill-rule:evenodd;stroke:#fffb00;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#fff700;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+         d="m -99.000001,883.54402 39.81818,-66.81819"
+         id="path4517"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#f0ff00;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+         d="m -59.463711,816.94972 -76.753229,0 -38.56946,66.33948"
+         id="path4519"
+         inkscape:connector-curvature="0" />
+    </g>
+    <g
+       id="g4591"
+       transform="translate(184.79893,205.58643)">
+      <path
+         inkscape:connector-curvature="0"
+         id="path4573"
+         style="display:inline;fill:#ffff00;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         d="m 175.5925,655.30669 -77.00876,0 -38.505,66.6925 38.505,66.69249 77.00876,0 38.505,-66.69249 -38.505,-66.6925 z" />
+      <path
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="ccccccccccccccccccc"
+         id="path4575"
+         d="m 133.81328,769.36362 c -4.98858,-0.64265 -10.12259,-5.35945 -10.83989,-10.89312 -0.68794,-4.62623 0.30456,-10.02623 4.12875,-13.07935 1.67733,-1.14327 3.959,-2.42422 5.97107,-2.27178 0.0603,2.0481 -0.0603,4.53751 0,6.58561 -2.39655,0.26682 -4.71638,2.99081 -4.6681,5.48492 0.0587,3.24569 1.4952,6.2278 4.61788,7.1992 3.45403,1.16223 7.40791,0.83167 10.60533,-1.10057 2.64137,-2.05802 2.88574,-5.8898 1.50423,-8.8058 -0.62143,-1.60464 -1.96101,-2.78268 -3.77919,-2.77775 l 0,5.71246 -5.12679,0 0,-12.29807 15.52512,0 0,4.42245 -4.25241,0.0393 c 3.96819,2.26207 4.37493,7.14424 4.17158,10.53133 0.14295,5.81845 -5.6054,10.56238 -11.30674,11.19666 -2.06269,0.15465 -3.80795,0.16279 -6.55084,0.0545 z"
+         style="fill:#000000;fill-opacity:1" />
+      <path
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="ccccc"
+         id="path4577"
+         d="m 122.72168,740.67638 -0.0326,-6.45396 29.10361,0 -0.003,6.48504 -29.06768,-0.0311 z"
+         style="fill:#40bf4c;fill-opacity:1" />
+      <path
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="ccccccccccccc"
+         id="path4579"
+         d="m 133.81384,731.95529 0,-6.90684 -11.28293,0 0,-6.01053 11.28293,0 0,-7.75042 6.74866,0 0,7.75042 11.2302,0 0,6.01053 -11.2302,0 -0.11125,6.89243 -6.63741,0.0144 z"
+         style="fill:#ff0000;fill-opacity:1" />
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path4581"
+         d="m 154.07714,721.74852 c 13.1692,0.98414 18.35807,-2.95155 32.18101,-19.81947"
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1" />
+      <path
+         inkscape:transform-center-y="-14.892703"
+         inkscape:transform-center-x="-7.5938808"
+         sodipodi:nodetypes="cccccccc"
+         id="path4583"
+         d="m 193.65177,689.48539 1.0226,11.52597 -3.21949,-1.89699 c -0.53498,0.89217 -1.13069,1.7304 -1.76867,2.51487 l -4.66214,-3.51845 c 0.45046,-0.55521 0.8728,-1.41853 1.25235,-2.04767 l -3.20246,-1.88696 z"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         inkscape:connector-curvature="0" />
+      <g
+         id="g4585"
+         transform="matrix(-1,0,0,1,445.15327,89.614307)">
+        <path
+           inkscape:connector-curvature="0"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           d="m 364.9245,600.03084 1.0226,11.52597 -3.21949,-1.89699 c -0.53498,0.89217 -1.13069,1.7304 -1.76867,2.51487 l -4.66214,-3.51845 c 0.45046,-0.55521 0.8728,-1.41853 1.25235,-2.04767 l -3.20246,-1.88696 z"
+           id="path4587"
+           sodipodi:nodetypes="cccccccc"
+           inkscape:transform-center-x="-7.5938808"
+           inkscape:transform-center-y="-14.892703" />
+        <path
+           sodipodi:nodetypes="cc"
+           inkscape:connector-curvature="0"
+           id="path4589"
+           d="m 325.34987,632.29397 c 13.1692,0.98414 18.35807,-2.95155 32.18101,-19.81947"
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1" />
+      </g>
+    </g>
+    <g
+       transform="translate(12.550131,294.22209)"
+       id="g4612">
+      <path
+         inkscape:connector-curvature="0"
+         id="path4614"
+         style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         d="m 462.58897,499.84363 -77.00875,0 -38.505,66.6925 38.505,66.6925 77.00875,0 38.505,-66.6925 -38.505,-66.6925 z" />
+      <g
+         id="g4616">
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1"
+           d="m 369.14737,596.54869 c 179.79378,-174.98868 95.13045,83.3911 55.1201,-80.50195"
+           id="path4618"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+        <path
+           inkscape:connector-curvature="0"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           d="m 422.69966,500.95772 -6.24535,9.74111 3.73197,-0.18982 c 0.0609,1.03849 0.20054,2.05731 0.40251,3.04807 l 5.7616,-0.95861 c -0.14198,-0.70071 -0.11643,-1.66145 -0.16137,-2.39484 l 3.71224,-0.18884 z"
+           id="path4620"
+           sodipodi:nodetypes="cccccccc"
+           inkscape:transform-center-x="0.7747508"
+           inkscape:transform-center-y="-18.010798" />
+      </g>
+    </g>
+    <g
+       id="g4680"
+       transform="matrix(1,0,0,-1,127.78383,1360.044)">
+      <path
+         inkscape:connector-curvature="0"
+         id="path4682"
+         style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         d="m 462.58897,499.84363 -77.00875,0 -38.505,66.6925 38.505,66.6925 77.00875,0 38.505,-66.6925 -38.505,-66.6925 z" />
+      <g
+         id="g4684">
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1"
+           d="m 369.14737,596.54869 c 179.79378,-174.98868 95.13045,83.3911 55.1201,-80.50195"
+           id="path4686"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+        <path
+           inkscape:connector-curvature="0"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           d="m 422.69966,500.95772 -6.24535,9.74111 3.73197,-0.18982 c 0.0609,1.03849 0.20054,2.05731 0.40251,3.04807 l 5.7616,-0.95861 c -0.14198,-0.70071 -0.11643,-1.66145 -0.16137,-2.39484 l 3.71224,-0.18884 z"
+           id="path4688"
+           sodipodi:nodetypes="cccccccc"
+           inkscape:transform-center-x="0.7747508"
+           inkscape:transform-center-y="-18.010798" />
+      </g>
+    </g>
+    <g
+       transform="matrix(1,2.0107719e-5,2.0107719e-5,-1,-101.29487,1223.1898)"
+       id="g4727">
+      <g
+         id="g4853"
+         transform="matrix(-0.9999191,0.01271977,-0.01271977,-0.9999191,626.31079,1260.0115)"
+         inkscape:transform-center-x="-16.572815"
+         inkscape:transform-center-y="-15.467961">
+        <path
+           inkscape:connector-curvature="0"
+           id="path4729"
+           style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+           d="m 231.51016,498.82244 -77.00876,0 -38.505,66.6925 38.505,66.69249 77.00876,0 38.505,-66.69249 -38.505,-66.6925 z" />
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1"
+           d="m 248.23414,597.36687 c -12.08969,-7.29009 -18.12987,-116.54484 -46.70001,-40.02598 -18.39769,49.27419 -45.74475,-4.56444 -54.84188,-12.01875"
+           id="path4731"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="csc" />
+        <path
+           inkscape:transform-center-y="-5.8683169"
+           inkscape:transform-center-x="-0.4755438"
+           sodipodi:nodetypes="cccccccc"
+           id="path4733"
+           d="m 136.03878,533.85322 1.62247,11.45695 2.7044,-2.57875 c 0.7237,0.74728 1.49423,1.42828 2.29371,2.04734 l 3.74095,-4.48555 c -0.56476,-0.4384 -1.17222,-1.18315 -1.68478,-1.70962 l 2.6901,-2.56512 z"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           inkscape:connector-curvature="0" />
+      </g>
+    </g>
+    <g
+       transform="matrix(0.52225441,0.85278973,-0.85278973,0.52225441,588.38542,265.88987)"
+       id="g4735">
+      <path
+         inkscape:connector-curvature="0"
+         id="path4737"
+         style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         d="m 231.51016,498.82244 -77.00876,0 -38.505,66.6925 38.505,66.69249 77.00876,0 38.505,-66.69249 -38.505,-66.6925 z" />
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1"
+         d="m 248.23414,597.36687 c -12.08969,-7.29009 -21.44443,-80.08465 -50.01457,-3.56579 -18.39769,49.27419 -42.43019,-41.02463 -51.52732,-48.47894"
+         id="path4739"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="csc" />
+      <path
+         inkscape:transform-center-y="-5.8683169"
+         inkscape:transform-center-x="-0.4755438"
+         sodipodi:nodetypes="cccccccc"
+         id="path4741"
+         d="m 136.03878,533.85322 1.62247,11.45695 2.7044,-2.57875 c 0.7237,0.74728 1.49423,1.42828 2.29371,2.04734 l 3.74095,-4.48555 c -0.56476,-0.4384 -1.17222,-1.18315 -1.68478,-1.70962 l 2.6901,-2.56512 z"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         inkscape:connector-curvature="0" />
+    </g>
+    <g
+       transform="matrix(0.52823316,0.84909936,0.84909936,-0.52823316,-149.77447,1484.5351)"
+       id="g4831">
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1"
+         d="m -156.10441,923.00578 c 2.73241,5.35647 49.24076,-69.47997 55.40614,19.54145"
+         id="path4833"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+      <path
+         inkscape:transform-center-y="-1.9921231"
+         inkscape:transform-center-x="3.1470162"
+         sodipodi:nodetypes="cccccccc"
+         id="path4835"
+         d="m -100.99013,959.06269 -7.22736,-9.03656 3.73144,-0.20046 c -0.0478,-1.03918 -0.0152,-2.067 0.0824,-3.07343 l 5.830147,0.3524 c -0.0681,0.71169 0.0575,1.66452 0.0893,2.39861 l 3.7117,-0.19942 z"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:#000000;fill-opacity:0;fill-rule:evenodd;stroke:#fffb00;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         d="m -178.49162,893.69696 75.98184,-0.3857"
+         id="path4837"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+      <path
+         inkscape:connector-curvature="0"
+         id="path4839"
+         d="m -103.90909,893.18039 40.909087,67.09091"
+         style="fill:none;fill-rule:evenodd;stroke:#f3ff00;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+      <path
+         inkscape:connector-curvature="0"
+         id="path4841"
+         d="m -178.63637,893.72584 39.27273,66.81818 76.363637,-0.54545"
+         style="fill:none;fill-rule:evenodd;stroke:#ffe800;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+    </g>
+    <g
+       id="g4843"
+       transform="matrix(-0.48344807,-0.87537304,-0.87537304,0.48344807,910.12857,689.09663)"
+       inkscape:transform-center-x="48.4375"
+       inkscape:transform-center-y="-140.625">
+      <path
+         inkscape:connector-curvature="0"
+         id="path4845"
+         style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         d="m 462.58897,499.84363 -77.00875,0 -38.505,66.6925 38.505,66.6925 77.00875,0 38.505,-66.6925 -38.505,-66.6925 z" />
+      <g
+         id="g4847">
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1"
+           d="m 369.14737,596.54869 c 179.79378,-174.98868 95.13045,83.3911 55.1201,-80.50195"
+           id="path4849"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+        <path
+           inkscape:connector-curvature="0"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           d="m 422.69966,500.95772 -6.24535,9.74111 3.73197,-0.18982 c 0.0609,1.03849 0.20054,2.05731 0.40251,3.04807 l 5.7616,-0.95861 c -0.14198,-0.70071 -0.11643,-1.66145 -0.16137,-2.39484 l 3.71224,-0.18884 z"
+           id="path4851"
+           sodipodi:nodetypes="cccccccc"
+           inkscape:transform-center-x="0.7747508"
+           inkscape:transform-center-y="-18.010798" />
+      </g>
+    </g>
+    <g
+       transform="matrix(-1,0,0,1,629.2069,294.58461)"
+       id="g4878">
+      <g
+         id="g4880">
+        <path
+           d="m 183.90007,86.85828 77.00875,0 38.505,66.6925 -38.505,66.6925 -77.00875,0 -38.505,-66.6925 38.505,-66.6925 z"
+           style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+           id="path4882"
+           inkscape:connector-curvature="0"
+           transform="matrix(-1,0,0,1,646.48904,412.98535)" />
+        <path
+           sodipodi:nodetypes="cc"
+           inkscape:connector-curvature="0"
+           id="path4884"
+           d="m 369.14737,596.54869 c 212.57536,-152.79796 34.16912,123.05809 55.1201,-80.50195"
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1" />
+        <path
+           inkscape:transform-center-y="-18.010798"
+           inkscape:transform-center-x="0.7747508"
+           sodipodi:nodetypes="cccccccc"
+           id="path4886"
+           d="m 422.69966,500.95772 -6.24535,9.74111 3.73197,-0.18982 c 0.0609,1.03849 0.20054,2.05731 0.40251,3.04807 l 5.7616,-0.95861 c -0.14198,-0.70071 -0.11643,-1.66145 -0.16137,-2.39484 l 3.71224,-0.18884 z"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           inkscape:connector-curvature="0" />
+      </g>
+      <g
+         id="g4888">
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1"
+           d="m 369.14737,596.54869 c 212.57536,-152.79796 34.16912,123.05809 55.1201,-80.50195"
+           id="path4890"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+        <path
+           inkscape:connector-curvature="0"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           d="m 422.69966,500.95772 -6.24535,9.74111 3.73197,-0.18982 c 0.0609,1.03849 0.20054,2.05731 0.40251,3.04807 l 5.7616,-0.95861 c -0.14198,-0.70071 -0.11643,-1.66145 -0.16137,-2.39484 l 3.71224,-0.18884 z"
+           id="path4892"
+           sodipodi:nodetypes="cccccccc"
+           inkscape:transform-center-x="0.7747508"
+           inkscape:transform-center-y="-18.010798" />
+      </g>
+    </g>
+    <g
+       transform="matrix(0,1,-1,0,962.67982,79.118649)"
+       id="g4906">
+      <path
+         d="m 175.5925,655.30669 -77.00876,0 -38.505,66.6925 38.505,66.69249 77.00876,0 38.505,-66.69249 -38.505,-66.6925 z"
+         style="display:inline;fill:#ffff00;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         id="path4908"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:#000000;fill-opacity:1"
+         d="m 133.81328,769.36362 c -4.98858,-0.64265 -10.12259,-5.35945 -10.83989,-10.89312 -0.68794,-4.62623 0.30456,-10.02623 4.12875,-13.07935 1.67733,-1.14327 3.959,-2.42422 5.97107,-2.27178 0.0603,2.0481 -0.0603,4.53751 0,6.58561 -2.39655,0.26682 -4.71638,2.99081 -4.6681,5.48492 0.0587,3.24569 1.4952,6.2278 4.61788,7.1992 3.45403,1.16223 7.40791,0.83167 10.60533,-1.10057 2.64137,-2.05802 2.88574,-5.8898 1.50423,-8.8058 -0.62143,-1.60464 -1.96101,-2.78268 -3.77919,-2.77775 l 0,5.71246 -5.12679,0 0,-12.29807 15.52512,0 0,4.42245 -4.25241,0.0393 c 3.96819,2.26207 4.37493,7.14424 4.17158,10.53133 0.14295,5.81845 -5.6054,10.56238 -11.30674,11.19666 -2.06269,0.15465 -3.80795,0.16279 -6.55084,0.0545 z"
+         id="path4910"
+         sodipodi:nodetypes="ccccccccccccccccccc"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:#40bf4c;fill-opacity:1"
+         d="m 122.72168,740.67638 -0.0326,-6.45396 29.10361,0 -0.003,6.48504 -29.06768,-0.0311 z"
+         id="path4912"
+         sodipodi:nodetypes="ccccc"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:#ff0000;fill-opacity:1"
+         d="m 133.81384,731.95529 0,-6.90684 -11.28293,0 0,-6.01053 11.28293,0 0,-7.75042 6.74866,0 0,7.75042 11.2302,0 0,6.01053 -11.2302,0 -0.11125,6.89243 -6.63741,0.0144 z"
+         id="path4914"
+         sodipodi:nodetypes="ccccccccccccc"
+         inkscape:connector-curvature="0" />
+      <path
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1"
+         d="m 154.07714,721.74852 c 13.1692,0.98414 18.35807,-2.95155 32.18101,-19.81947"
+         id="path4916"
+         inkscape:connector-curvature="0"
+         sodipodi:nodetypes="cc" />
+      <path
+         inkscape:connector-curvature="0"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         d="m 193.65177,689.48539 1.0226,11.52597 -3.21949,-1.89699 c -0.53498,0.89217 -1.13069,1.7304 -1.76867,2.51487 l -4.66214,-3.51845 c 0.45046,-0.55521 0.8728,-1.41853 1.25235,-2.04767 l -3.20246,-1.88696 z"
+         id="path4918"
+         sodipodi:nodetypes="cccccccc"
+         inkscape:transform-center-x="-7.5938808"
+         inkscape:transform-center-y="-14.892703" />
+      <g
+         transform="matrix(-1,0,0,1,445.15327,89.614307)"
+         id="g4920">
+        <path
+           inkscape:transform-center-y="-14.892703"
+           inkscape:transform-center-x="-7.5938808"
+           sodipodi:nodetypes="cccccccc"
+           id="path4922"
+           d="m 364.9245,600.03084 1.0226,11.52597 -3.21949,-1.89699 c -0.53498,0.89217 -1.13069,1.7304 -1.76867,2.51487 l -4.66214,-3.51845 c 0.45046,-0.55521 0.8728,-1.41853 1.25235,-2.04767 l -3.20246,-1.88696 z"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           inkscape:connector-curvature="0" />
+        <path
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1"
+           d="m 325.34987,632.29397 c 13.1692,0.98414 18.35807,-2.95155 32.18101,-19.81947"
+           id="path4924"
+           inkscape:connector-curvature="0"
+           sodipodi:nodetypes="cc" />
+      </g>
+    </g>
+    <g
+       id="g4926"
+       transform="matrix(0.00271106,0.99999633,-0.99999633,0.00271106,872.97406,-95.227214)"
+       inkscape:transform-center-x="-104.62014"
+       inkscape:transform-center-y="7.2910125">
+      <path
+         d="m 462.58897,499.84363 -77.00875,0 -38.505,66.6925 38.505,66.6925 77.00875,0 38.505,-66.6925 -38.505,-66.6925 z"
+         style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         id="path4928"
+         inkscape:connector-curvature="0" />
+      <g
+         id="g4930">
+        <path
+           sodipodi:nodetypes="cc"
+           inkscape:connector-curvature="0"
+           id="path4932"
+           d="m 369.14737,596.54869 c 179.79378,-174.98868 95.13045,83.3911 55.1201,-80.50195"
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:0;stroke-opacity:1" />
+        <path
+           inkscape:transform-center-y="-18.010798"
+           inkscape:transform-center-x="0.7747508"
+           sodipodi:nodetypes="cccccccc"
+           id="path4934"
+           d="m 422.69966,500.95772 -6.24535,9.74111 3.73197,-0.18982 c 0.0609,1.03849 0.20054,2.05731 0.40251,3.04807 l 5.7616,-0.95861 c -0.14198,-0.70071 -0.11643,-1.66145 -0.16137,-2.39484 l 3.71224,-0.18884 z"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           inkscape:connector-curvature="0" />
+      </g>
+    </g>
+    <g
+       id="g4946"
+       transform="matrix(1,2.0107719e-5,2.0107719e-5,-1,-18.687743,786.98373)">
+      <g
+         inkscape:transform-center-y="-21.861258"
+         inkscape:transform-center-x="-6.0002714"
+         transform="matrix(-0.85808244,-0.51351196,0.51351196,-0.85808244,202.35599,1269.6551)"
+         id="g4948">
+        <path
+           d="m 231.51016,498.82244 -77.00876,0 -38.505,66.6925 38.505,66.69249 77.00876,0 38.505,-66.69249 -38.505,-66.6925 z"
+           style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+           id="path4950"
+           inkscape:connector-curvature="0" />
+        <path
+           sodipodi:nodetypes="csc"
+           inkscape:connector-curvature="0"
+           id="path4952"
+           d="m 248.23414,597.36687 c -12.08969,-7.29009 -18.12987,-116.54484 -46.70001,-40.02598 -18.39769,49.27419 -45.74475,-4.56444 -54.84188,-12.01875"
+           style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1" />
+        <path
+           inkscape:connector-curvature="0"
+           style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+           d="m 136.03878,533.85322 1.62247,11.45695 2.7044,-2.57875 c 0.7237,0.74728 1.49423,1.42828 2.29371,2.04734 l 3.74095,-4.48555 c -0.56476,-0.4384 -1.17222,-1.18315 -1.68478,-1.70962 l 2.6901,-2.56512 z"
+           id="path4954"
+           sodipodi:nodetypes="cccccccc"
+           inkscape:transform-center-x="-0.4755438"
+           inkscape:transform-center-y="-5.8683169" />
+      </g>
+    </g>
+    <g
+       id="g4956"
+       transform="matrix(-0.87044162,0.49227164,-0.49227164,-0.87044162,888.94556,730.52873)">
+      <path
+         d="m 231.51016,498.82244 -77.00876,0 -38.505,66.6925 38.505,66.69249 77.00876,0 38.505,-66.69249 -38.505,-66.6925 z"
+         style="display:inline;fill:#fff6d5;fill-opacity:0;stroke:#edff24;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+         id="path4958"
+         inkscape:connector-curvature="0" />
+      <path
+         sodipodi:nodetypes="csc"
+         inkscape:connector-curvature="0"
+         id="path4960"
+         d="m 248.23414,597.36687 c -12.08969,-7.29009 -21.44443,-80.08465 -50.01457,-3.56579 -18.39769,49.27419 -42.43019,-41.02463 -51.52732,-48.47894"
+         style="fill:none;fill-rule:evenodd;stroke:#ff0000;stroke-width:6;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3, 3, 9, 3;stroke-dashoffset:4.80000019;stroke-opacity:1" />
+      <path
+         inkscape:connector-curvature="0"
+         style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:none"
+         d="m 136.03878,533.85322 1.62247,11.45695 2.7044,-2.57875 c 0.7237,0.74728 1.49423,1.42828 2.29371,2.04734 l 3.74095,-4.48555 c -0.56476,-0.4384 -1.17222,-1.18315 -1.68478,-1.70962 l 2.6901,-2.56512 z"
+         id="path4962"
+         sodipodi:nodetypes="cccccccc"
+         inkscape:transform-center-x="-0.4755438"
+         inkscape:transform-center-y="-5.8683169" />
+    </g>
+    <rect
+       style="fill:#006e93;fill-opacity:1;fill-rule:evenodd;stroke:#009453;stroke-width:2.09441543;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:4.80000019;stroke-opacity:1"
+       id="rect5559"
+       width="74.023422"
+       height="96.675735"
+       x="515.27136"
+       y="627.57892"
+       rx="0"
+       ry="0" />
+    <rect
+       ry="0"
+       rx="0"
+       y="627.59033"
+       x="437.39053"
+       height="96.652977"
+       width="75.657951"
+       id="rect5569"
+       style="fill:#ff7f26;fill-opacity:1;fill-rule:evenodd;stroke:#ff5739;stroke-width:2.11716366;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:4.80000019;stroke-opacity:1" />
+  </g>
+</svg>
diff --git a/doc/submodules.mdwn b/doc/submodules.mdwn
new file mode 100644
index 0000000000..68c0fef4c0
--- /dev/null
+++ b/doc/submodules.mdwn
@@ -0,0 +1,22 @@
+[Git submodules](http://git-scm.com/book/en/v2/Git-Tools-Submodules) are
+supported by git-annex since version 5.20150303.
+
+Git normally makes a `.git` **file** in a
+submodule, that points to the real git repository under `.git/modules/`.
+This presents problems for git-annex. So, when used in a submodule,
+git-annex will automatically replace the `.git` file with a symlink
+pointing at the git repository. (When the filesystem doesn't support
+symlinks, an adjusted unlocked branch is used, and submodules are
+supported in that setup too.)
+
+With that taken care of, git-annex should work ok in submodules. Although
+this is a new and somewhat experimental feature.
+
+The conversion of .git file to .git symlink mostly won't bother git.
+
+Known problems:
+
+* If you want to delete a whole submodule, `git rm submodule`
+  will refuse to delete it, complaining that the
+  submodule "uses a .git directory". Workaround: Use `rm -rf`
+  to delete the tree, and then `git commit`.
diff --git a/doc/submodules/comment_10_936e145bbe3b6bd928571c17d3416937._comment b/doc/submodules/comment_10_936e145bbe3b6bd928571c17d3416937._comment
new file mode 100644
index 0000000000..eda12b3fb8
--- /dev/null
+++ b/doc/submodules/comment_10_936e145bbe3b6bd928571c17d3416937._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="TTTTAAAx"
+ avatar="http://cdn.libravatar.org/avatar/9edd4b69b9f9fc9b8c1cb8ecd03902d5"
+ subject="Datalad cannot detect submodule path changed on disk"
+ date="2024-02-22T08:34:47Z"
+ content="""
+> Sounds like you might want to use datalad, which is built around git annex and where submodules are a first-class citizen. 
+
+Datalad handles submodules as subdatasets and add python code layers on it to handle datasets(e.g. dedup submodules). But it doesn't detect the submodules path changed like git.
+
+So, it doesn't do my needs sadly.
+"""]]
diff --git a/doc/submodules/comment_11_78fffae9facce1600915bc19429d81e2._comment b/doc/submodules/comment_11_78fffae9facce1600915bc19429d81e2._comment
new file mode 100644
index 0000000000..8e7289cc69
--- /dev/null
+++ b/doc/submodules/comment_11_78fffae9facce1600915bc19429d81e2._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: comment 6"""
+ date="2024-02-22T16:50:34Z"
+ content="""
+@TTTTAAAx kindly posted a full example of their problem, 
+which I've moved to 
+[[todo/detect_and_handle_submodules_after_path_changed_by_mv]].
+
+I do think that using `git mv` to rename directories that contain
+submodules is the right way to avoid that kind of problem. 
+Note that renaming such a directory without using git followed by running
+`git add` on the new directory has the same behavior as running
+`git-annex assist` does. This is not a git-annex problem, but I think it
+could be considered a git problem; git could make `git add` of a moved
+submodule do the right thing.
+"""]]
diff --git a/doc/submodules/comment_12_d59882712e0547c748d3b354e8607d62._comment b/doc/submodules/comment_12_d59882712e0547c748d3b354e8607d62._comment
new file mode 100644
index 0000000000..d48ebbc83d
--- /dev/null
+++ b/doc/submodules/comment_12_d59882712e0547c748d3b354e8607d62._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="TTTTAAAx"
+ avatar="http://cdn.libravatar.org/avatar/9edd4b69b9f9fc9b8c1cb8ecd03902d5"
+ subject="comment 12"
+ date="2024-03-05T05:21:59Z"
+ content="""
+I agree with you. Specifically, [this](https://git-annex.branchable.com/todo/detect_and_handle_submodules_after_path_changed_by_mv/) is related to git, not git-annex.
+
+I wanted to run `git annex assist` just and expect to be fixed.
+
+I wrote a simple python script to fix the issue, which changed the path of the submodule. And by adding the script in pre-commit hook, I can do `git annex assist` now without fixing the submodules manually.
+(I used python to manipulate the text files such as dot-gitmodules etc. Perl or Ruby would be much compact in this job.)
+
+It seems to work well for my needs, even though just a prototype script. 
+
+After some polishing (and testing), I'll upload the script here.
+
+Thank you.
+"""]]
diff --git a/doc/submodules/comment_1_15a2633524fc376b6a6c4f76187e435b._comment b/doc/submodules/comment_1_15a2633524fc376b6a6c4f76187e435b._comment
new file mode 100644
index 0000000000..4498c1711a
--- /dev/null
+++ b/doc/submodules/comment_1_15a2633524fc376b6a6c4f76187e435b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="aschoise@2386473665998adccbe71286036e57d7f3ad3a58"
+ nickname="aschoise"
+ avatar="http://cdn.libravatar.org/avatar/4e92ae64165f51610395247226b6bfad"
+ subject="Issue when using flag --recurse-submodules with git-checkout and git-switch"
+ date="2021-01-18T23:04:16Z"
+ content="""
+After setting up git-annex in one of my submodules, I noticed that executing `git checkout mybranch --recurse-submodules` will cause a fatal error (see error message below) and my working copy will be left in a state somewhere in between the origin and the destination branch.  
+As a workaround, this two-step alternative seems to work fine though: `git checkout mybranch && git submodule update`.  
+Everything above applies to command `git switch` as well.  
+I use git version 2.27.0 and git-annex version 8.20200618  
+
+Error Message: **fatal: could not open 'path/to/my/submodule/.git' for writing: Is a directory**
+"""]]
diff --git a/doc/submodules/comment_2_fb006a18240230aefb80ee8aeebdccb7._comment b/doc/submodules/comment_2_fb006a18240230aefb80ee8aeebdccb7._comment
new file mode 100644
index 0000000000..e3a16ebd10
--- /dev/null
+++ b/doc/submodules/comment_2_fb006a18240230aefb80ee8aeebdccb7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="DavidD"
+ avatar="http://cdn.libravatar.org/avatar/9e7cced3eede4bf75fb932bfdd4f8847"
+ subject="comment 2"
+ date="2023-04-15T22:16:11Z"
+ content="""
+The submodule .git file having been converted to a symlink is still a problem when using `git checkout` with `--recurse-submodules` in the parent repo. The previous poster's solution to use `git checkout mybranch && git submodule update` does not work with git version 2.40.0 and git-annex version 10.20230407. 
+
+Are there other suggestions for workarounds?
+
+The original post states that the .git as a symlink fixes problems that exist for a .git file which points to the `.git/modules/` folder of the parent. What problems are these problems?
+"""]]
diff --git a/doc/submodules/comment_3_92cdc81ccc4831f5ad493736ca87e87d._comment b/doc/submodules/comment_3_92cdc81ccc4831f5ad493736ca87e87d._comment
new file mode 100644
index 0000000000..0abd35cb1b
--- /dev/null
+++ b/doc/submodules/comment_3_92cdc81ccc4831f5ad493736ca87e87d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 3"
+ date="2023-04-16T17:49:50Z"
+ content="""
+The obvious problem I guess is that you can't have a file and a folder of the same name. git annex needs to put stuff in `$repo/.git/...`, but if `.git` is a *file*, that doesn't work.
+"""]]
diff --git a/doc/submodules/comment_4_9da0d19529dfb8a997ad469169e55895._comment b/doc/submodules/comment_4_9da0d19529dfb8a997ad469169e55895._comment
new file mode 100644
index 0000000000..8f8f517329
--- /dev/null
+++ b/doc/submodules/comment_4_9da0d19529dfb8a997ad469169e55895._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="DavidD"
+ avatar="http://cdn.libravatar.org/avatar/9e7cced3eede4bf75fb932bfdd4f8847"
+ subject="comment 4"
+ date="2023-04-17T15:27:49Z"
+ content="""
+I might have this wrong, but I thought git also put things into `$repo/.git/...`? If git can figure out that the `.git` file points to the actual location of the `.git` folder (in the parent repo) than I would think that git annex can conclude this as well. Again, I don't know how the guts of git annex works, so there is possibly other considerations that I am missing.
+"""]]
diff --git a/doc/submodules/comment_5_9ccb133a957498724188a8749359a422._comment b/doc/submodules/comment_5_9ccb133a957498724188a8749359a422._comment
new file mode 100644
index 0000000000..3f16afb082
--- /dev/null
+++ b/doc/submodules/comment_5_9ccb133a957498724188a8749359a422._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-04-20T16:45:38Z"
+ content="""
+The above issue is being discussed at
+[[bugs/Git_checkout_fails_using_--recurse-submodules]].
+
+DavidD's comment #2 is misleading, `git submodule update` does work fine when
+you've checkout out a branch and want to update an existing submodule.
+
+When `git submodule update` does not work 100% is the case where you checked out
+a branch, added a submodule in that branch, and then checked out another
+branch that does not contain the submodule. What happens then is:
+
+	warning: unable to rmdir 'sub': Directory not empty
+
+And the solution is to `rm -rf sub` manually. This is essentially the same
+problem discussed above on this page where it talks about deleting a whole
+submodule.
+"""]]
diff --git a/doc/submodules/comment_6_d1877da19346bbd6067ff95252974a9b._comment b/doc/submodules/comment_6_d1877da19346bbd6067ff95252974a9b._comment
new file mode 100644
index 0000000000..6a14a15ffe
--- /dev/null
+++ b/doc/submodules/comment_6_d1877da19346bbd6067ff95252974a9b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="TTTTAAAx"
+ avatar="http://cdn.libravatar.org/avatar/9edd4b69b9f9fc9b8c1cb8ecd03902d5"
+ subject="comment 6"
+ date="2024-01-11T13:58:27Z"
+ content="""
+Since git 1.8.5, `git mv projects/2023/prj_1 archives/2023/prj_1` can update local path of submodule.
+Currently, `git-annex` doesn't detect submodule path changed and Just moving parent directories breaks git-modules thoroughly.
+The only way I found is to move all submodule to another tree structure one by one using `git mv ...`.
+
+If the parent directory name(e.g: projects->01_Projects) or its depth was changed by chance, all submodules inside the directory are broken.
+
+So I cannot use submodules to handle source code in my git-annex repo.
+Is there an easy (cool) way for this?
+"""]]
diff --git a/doc/submodules/comment_7_899cf2aa74cbb8160b1e249b314e7d60._comment b/doc/submodules/comment_7_899cf2aa74cbb8160b1e249b314e7d60._comment
new file mode 100644
index 0000000000..0ea3c9f4df
--- /dev/null
+++ b/doc/submodules/comment_7_899cf2aa74cbb8160b1e249b314e7d60._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Try datalad"
+ date="2024-01-12T09:23:16Z"
+ content="""
+Sounds like you might want to use [datalad](https://datalad.org), which is built around git annex and where submodules are a first-class citizen.
+"""]]
diff --git a/doc/submodules/comment_8_8755b0d18c1b013ed0dc121ecfb83360._comment b/doc/submodules/comment_8_8755b0d18c1b013ed0dc121ecfb83360._comment
new file mode 100644
index 0000000000..8eb3679826
--- /dev/null
+++ b/doc/submodules/comment_8_8755b0d18c1b013ed0dc121ecfb83360._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="TTTTAAAx"
+ avatar="http://cdn.libravatar.org/avatar/9edd4b69b9f9fc9b8c1cb8ecd03902d5"
+ subject="comment 8"
+ date="2024-01-15T01:43:28Z"
+ content="""
+> Sounds like you might want to use datalad, which is built around git annex and where submodules are a first-class citizen. 
+
+Thank you for information. I'll try datalad. I considered it for audio and transcription dataset management few years ago. But I didn't use it because datalad using git-annex in it and I already used git-annex for data management. It was seemd to be redundant to me.
+
+I think submodule path detecting can be implemented still and be useful in `git-annex-assist` also.
+"""]]
diff --git a/doc/submodules/comment_9_5e3a7d5c81fb37efbfe22cbbe8b8a247._comment b/doc/submodules/comment_9_5e3a7d5c81fb37efbfe22cbbe8b8a247._comment
new file mode 100644
index 0000000000..7cae80016e
--- /dev/null
+++ b/doc/submodules/comment_9_5e3a7d5c81fb37efbfe22cbbe8b8a247._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2024-01-18T16:14:11Z"
+ content="""
+Datalad relies on git-annex's handling of submodules to work afaik so I
+don't see why using it would avoid this problem.
+
+If I understand correctly, the .git symlink in the submodule that git-annex
+sets up gets broken when the submodule is relocated. But I would have
+expected that moving from `a/b/` to `x/y/` would keep the symlink working,
+since it's at the same path depth.
+
+I'd need more information to fix this problem, so I recommend filing a
+[[bugs|bug]] report with details.
+"""]]
diff --git a/doc/summary.mdwn b/doc/summary.mdwn
new file mode 100644
index 0000000000..a5e5400d3b
--- /dev/null
+++ b/doc/summary.mdwn
@@ -0,0 +1,12 @@
+git-annex allows managing large files with git, without storing the file
+contents in git. It can sync, backup, and archive your data, offline
+and online. Checksums and encryption keep your data safe and secure. Bring
+the power and distributed nature of git to bear on your large files with
+git-annex.
+
+[[!img assistant/thumbnail.png link=assistant align=right]]
+git-annex is designed for git users who love the command line.
+For everyone else, the [[git-annex assistant|assistant]] turns
+git-annex into an easy to use folder synchroniser.
+
+To get a feel for git-annex, see the [[walkthrough]].
diff --git a/doc/sync.mdwn b/doc/sync.mdwn
new file mode 100644
index 0000000000..eb86133f46
--- /dev/null
+++ b/doc/sync.mdwn
@@ -0,0 +1,49 @@
+The `git annex sync` command provides an easy way to keep several
+repositories in sync. 
+
+Often git is used in a centralized fashion with a central bare repository
+which changes are pulled and pushed to using normal git commands.
+That works fine, if you don't mind having a central repository.
+
+But it can be harder to use git in a fully decentralized fashion, with no
+central repository and still keep repositories in sync with one another.
+You have to remember to pull from each remote, and merge the appropriate
+branch after pulling. It's difficult to *push* to a remote, since git does
+not allow pushes into the currently checked out branch.
+
+`git annex sync` makes it easier using a scheme devised by Joachim
+Breitner. The idea is to have a branch `synced/master` (actually,
+`synced/$currentbranch`), that is never directly checked out, and serves
+as a drop-point for other repositories to use to push changes.
+
+When you run `git annex sync`, it merges the `synced/master` branch
+into `master`, receiving anything that's been pushed to it. (If there is a
+conflict in this merge, [[automatic_conflict_resolution]] is used to
+resolve it). Then it fetches from each remote, and merges in any changes that
+have been made to the remotes too. Finally, it updates `synced/master`
+to reflect the new state of `master`, and pushes it out to each of the remotes.
+
+This way, changes propagate around between repositories as `git annex sync`
+is run on each of them. Every repository does not need to be able to talk
+to every other repository; as long as the graph of repositories is
+connected, and `git annex sync` is run from time to time on each, a given
+change, made anywhere, will eventually reach every other repository.
+
+(`git-annex sync` will also attempt to push the master branch to remotes, 
+which does work for bare repositories.)
+
+The workflow for using `git annex sync` is simple:
+
+* Make some changes to files in the repository, using `git-annex`,
+  or anything else.
+* Run `git annex sync` to save the changes.
+* Next time you're working on a different clone of that repository,
+  run `git annex sync` to update it.
+
+Note that by default, `git annex sync` only synchronises the git
+repositories, but does not transfer the content of annexed files. If you
+want to fully synchronise two repositories content,
+you can use `git annex sync --content`. You can also configure
+[[preferred_content]] settings to make only some content be synced.
+
+See [[git-annex-sync]] for the command's man page.
diff --git a/doc/sync/comment_10_2cd8ab86f498d6f676f859b552f831eb._comment b/doc/sync/comment_10_2cd8ab86f498d6f676f859b552f831eb._comment
new file mode 100644
index 0000000000..da4d019654
--- /dev/null
+++ b/doc/sync/comment_10_2cd8ab86f498d6f676f859b552f831eb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkI9AR8BqG4RPw_Ov2lnDCJWMuM6WMRobQ"
+ nickname="Dav"
+ subject="Sorry to just be getting back..."
+ date="2014-01-26T22:51:28Z"
+ content="""
+The URLs in question in this case were read-only github https URLs. In any case, my problems are solved by what you've already suggested. I think a less error-sounding response to read-only https repos sounds nice!
+"""]]
diff --git a/doc/sync/comment_11_7683879f6982c0eb0aa39b66ff5a5ea9._comment b/doc/sync/comment_11_7683879f6982c0eb0aa39b66ff5a5ea9._comment
new file mode 100644
index 0000000000..430322975c
--- /dev/null
+++ b/doc/sync/comment_11_7683879f6982c0eb0aa39b66ff5a5ea9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
+ nickname="Matthias"
+ subject="sync slow with content switch"
+ date="2014-04-22T20:37:05Z"
+ content="""
+I noticed that in a test with 2 local repositories and around 2'000 files \"git annex sync\" is still very fast, but \"git annex sync --content\" takes multiple seconds. Is this avoidable?
+
+I have a central repo and client repos. I want to copy all content to the central repo after a commit. Right now, I use \"git annex group central backup\", \"git annex wanted central standard\", and a hook that triggers \"git annex sync --content\" after each commit. Maybe there is a more efficient way to do this? Thanks for sharing thoughts.
+"""]]
diff --git a/doc/sync/comment_12_2fea14fa314ddb7ab645a5cca5a95fd9._comment b/doc/sync/comment_12_2fea14fa314ddb7ab645a5cca5a95fd9._comment
new file mode 100644
index 0000000000..b7e2ea1899
--- /dev/null
+++ b/doc/sync/comment_12_2fea14fa314ddb7ab645a5cca5a95fd9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://mshri.livejournal.com/"
+ ip="129.170.212.202"
+ subject="Sync specific branch or ignore a branch during sync"
+ date="2014-04-25T15:37:53Z"
+ content="""
+
+I too feel that syncing all remotes by default is the right thing to do, but I think it should be limited to the 'master' and 'git-annex' branch. I often create branches that I want to keep local and do not want them to be synced. But I want 'master' and 'git-annex' branches to be synced with all remotes.
+
+So it would be nice to able to set an option to sync all branches or just the 'master' and 'git-annex' or to able to ignore some branches during git annex sync
+
+Shri
+
+"""]]
diff --git a/doc/sync/comment_13_690f66be9cefe28844d8df653b7a0331._comment b/doc/sync/comment_13_690f66be9cefe28844d8df653b7a0331._comment
new file mode 100644
index 0000000000..08ea5e8430
--- /dev/null
+++ b/doc/sync/comment_13_690f66be9cefe28844d8df653b7a0331._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="134.147.14.84"
+ subject="comment 13"
+ date="2014-05-15T08:28:09Z"
+ content="""
+I agree with mshri. It’s confusing to have every local branch wind up on every remote (and it hinders «git annex unused»).
+
+I tried working around this by just including relevant branches in the «fetch» refspec, but this will only work until another remote pushes the branches again.
+"""]]
diff --git a/doc/sync/comment_14_db342785a4dade30b5b75cb95031bed1._comment b/doc/sync/comment_14_db342785a4dade30b5b75cb95031bed1._comment
new file mode 100644
index 0000000000..66798dbb16
--- /dev/null
+++ b/doc/sync/comment_14_db342785a4dade30b5b75cb95031bed1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="134.147.14.84"
+ subject="comment 14"
+ date="2014-05-15T08:58:26Z"
+ content="""
+Added a wishlist item <http://git-annex.branchable.com/todo/Allow_syncing_only_selected_branches/>
+"""]]
diff --git a/doc/sync/comment_15_168e0ab10b4084e13df1a3058fa7e8a9._comment b/doc/sync/comment_15_168e0ab10b4084e13df1a3058fa7e8a9._comment
new file mode 100644
index 0000000000..94d34a2a87
--- /dev/null
+++ b/doc/sync/comment_15_168e0ab10b4084e13df1a3058fa7e8a9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 15"
+ date="2014-05-15T19:53:16Z"
+ content="""
+We seem to have some rumor going around that `git annex sync` pushes all branches. It does not. It pushes only the git-annex branch and the currently checked out branch.
+"""]]
diff --git a/doc/sync/comment_16_96096f994fc55f921f2b24b274f998f7._comment b/doc/sync/comment_16_96096f994fc55f921f2b24b274f998f7._comment
new file mode 100644
index 0000000000..587444d36c
--- /dev/null
+++ b/doc/sync/comment_16_96096f994fc55f921f2b24b274f998f7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 16"
+ date="2014-05-15T19:54:54Z"
+ content="""
+@Matthias, `git annex sync --content` has to check each file to see if any other repository wants it. This is necessarily going to get slow when there are a lot of files. The assistant does a similar syncing but uses some tricks to avoid scanning all the files too often, while still managing to keep them all in sync -- it can do this since it's a long-running daemon and is aware when files have changed.
+"""]]
diff --git a/doc/sync/comment_17_44a4ae4685c4bf2b4e7c61897eb3ff80._comment b/doc/sync/comment_17_44a4ae4685c4bf2b4e7c61897eb3ff80._comment
new file mode 100644
index 0000000000..ac808ef8cf
--- /dev/null
+++ b/doc/sync/comment_17_44a4ae4685c4bf2b4e7c61897eb3ff80._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm_YXzEdPHzbSGVwtmTR7g1BqDtTnIBB5s"
+ nickname="Matthias"
+ subject="comment 17"
+ date="2015-01-22T22:04:09Z"
+ content="""
+git sync … >> fetches from each remote
+
+Well, I have two git annex-ed repositories where \"git remote -v\" properly lists the other repo, and \"git annex sync foo\" manages to pull from foo, but \"git annex sync\" without a remote name simply does a local sync. Also, neither command pushes anything anywhere.
+
+So, where does \"git annex\" get its list of remotes from? What could prevent it from accessing them?
+
+
+"""]]
diff --git a/doc/sync/comment_18_838fb249cd5be83962770d5cc394389a._comment b/doc/sync/comment_18_838fb249cd5be83962770d5cc394389a._comment
new file mode 100644
index 0000000000..094a0b9330
--- /dev/null
+++ b/doc/sync/comment_18_838fb249cd5be83962770d5cc394389a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 18"""
+ date="2015-02-04T19:12:23Z"
+ content="""
+If a remote has "remote.<name>.annex-sync" set to false in the git
+config, `git-annex sync` will skip that remote unless you specify the name.
+That's probably what's going on in your case.
+"""]]
diff --git a/doc/sync/comment_19_d409ad20c5a6671f0d0b834232368030._comment b/doc/sync/comment_19_d409ad20c5a6671f0d0b834232368030._comment
new file mode 100644
index 0000000000..e25cd8b364
--- /dev/null
+++ b/doc/sync/comment_19_d409ad20c5a6671f0d0b834232368030._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="git-config for manual sync-like operations"
+ date="2016-04-14T08:21:03Z"
+ content="""
+My way of working with git-annex doesn't seem to mesh well with the Assistant or even with `git annex sync`. I seem to have a bit of a control need when it comes to what gets committed when. But here's my workflow approximating what it does, with a twist. I have this in git config on `mylaptop`:
+
+    remote.myserver.fetch=+refs/heads/*:refs/remotes/myserver/*
+    remote.myserver.push=refs/heads/*:refs/remotes/mylaptop/*
+    remote.myserver.push=refs/heads/master:refs/heads/master
+    remote.myserver.push=refs/heads/git-annex:refs/heads/git-annex
+
+I don't need a `synced/git-annex`. If upstream is not up-to-date I fetch and merge. In this case upstream happens to be a bare git repo, so I don't need `synced/master` either. If upstream is non-bare, I use `synced/master` -- or sometimes I keep upstream usually checked out on an orphan branch and just switch into master to check things and then switch away to avoid conflict. If I can avoid it, I prefer not to have several branches where I don't know which one is the latest one.
+
+But here's the twist, look at this row:
+
+    remote.myserver.push=refs/heads/*:refs/remotes/mylaptop/*
+
+If I just do `git push`, close the lid and run into the forest, it may or may not have a non-fastforward event on master and git-annex ... but it always succeeds in pushing to the `mylaptop` remote on my server.
+
+If I have added a batch of files, I usually push first to all my remotes, to get that precious metadata up there. At that point I don't care if there's a conflict upstream. Then I `git annex copy` to wherever, fetch all remotes, `git annex merge`, maybe merge `master` if I have to (usually not), then push to all remotes again. It's less of a bother than it sounds like. I don't even have any handy aliases for this, I prefer to just get the for loop from my command-line history.
+"""]]
diff --git a/doc/sync/comment_1_59681be5568f568f5c54eb0445163dd2._comment b/doc/sync/comment_1_59681be5568f568f5c54eb0445163dd2._comment
new file mode 100644
index 0000000000..fa228c5aed
--- /dev/null
+++ b/doc/sync/comment_1_59681be5568f568f5c54eb0445163dd2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="very nice"
+ date="2012-02-25T15:02:18Z"
+ content="""
+Here's a way to get from a starting point of two or more peer directory trees *not* tracked by git or git-annex, to the point where they can be synced in the manner described above: [[forum/syncing_non-git_trees_with_git-annex/]]
+"""]]
diff --git a/doc/sync/comment_20_537b27219871a565ae7bb7f357cd3793._comment b/doc/sync/comment_20_537b27219871a565ae7bb7f357cd3793._comment
new file mode 100644
index 0000000000..4a3721eb6e
--- /dev/null
+++ b/doc/sync/comment_20_537b27219871a565ae7bb7f357cd3793._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="kartynnik@c8b57e8688e66fe58144cae5833b23948ae9b599"
+ nickname="kartynnik"
+ subject="Branch names containing slashes"
+ date="2016-08-29T17:30:44Z"
+ content="""
+1) When I have a branch \"some/branch/name\" containing slashes in its name, git-annex sync strips everything up to the last slash and creates \"synced/name\", which may clash with \"some/other/name\". Is there a workaround?
+
+2) Could the \"don't use synced branches\" behavior referred in the comments above somehow be configured on the repository side so that everyone cloning it doesn't need to configure it for himself?
+"""]]
diff --git a/doc/sync/comment_21_9c0368eb796f1191c22c186cbb06c642._comment b/doc/sync/comment_21_9c0368eb796f1191c22c186cbb06c642._comment
new file mode 100644
index 0000000000..bd40a8a8cf
--- /dev/null
+++ b/doc/sync/comment_21_9c0368eb796f1191c22c186cbb06c642._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Branch names containing slashes"""
+ date="2016-09-21T18:56:22Z"
+ content="""
+@kartynnik, that's a bug: [[bugs/sync_uses_conflicting_names_for_deep_branches]]
+
+Please file bugs there and not as comments here, it's too easy to lose
+track of a comment deep in a thread.
+"""]]
diff --git a/doc/sync/comment_22_e83ed5c0034c48baed7943c596f708ae._comment b/doc/sync/comment_22_e83ed5c0034c48baed7943c596f708ae._comment
new file mode 100644
index 0000000000..07d93f5d9c
--- /dev/null
+++ b/doc/sync/comment_22_e83ed5c0034c48baed7943c596f708ae._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="mario"
+ avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7"
+ subject="Compressed file transfers"
+ date="2017-05-03T20:52:43Z"
+ content="""
+Hi,
+
+how does \"git-annex sync --content\" transfers its file to a (regular) ssh-remote? I think it uses rsync.. Is that correct?
+
+I want to use compression for the file transfers. Therefore, I tried in .git/config to set:
+
+    [remote \"origin\"]
+        annex-rsync-upload-options = \"--compress\"
+
+However, it seems that this crashes the upload. The sync just seems to hang.. Is it possible to use compression for the transfer? How?
+"""]]
diff --git a/doc/sync/comment_23_e5e7ec9fbafe5e0429161b977e483752._comment b/doc/sync/comment_23_e5e7ec9fbafe5e0429161b977e483752._comment
new file mode 100644
index 0000000000..cfb62ba112
--- /dev/null
+++ b/doc/sync/comment_23_e5e7ec9fbafe5e0429161b977e483752._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2017-05-09T17:52:11Z"
+ content="""
+@mario, great question! (Not the best place for such a question, start a
+thread on the forum next time..)
+
+git-annex does use rsync when transferring files between ssh remotes.
+Rsync normally goes over ssh, and it might be better to enable compression
+at the ssh level. For example, I have "Compression yes" in `~/.ssh/config`
+
+I think that the reason your annex-rsync-upload-options setting broke
+it is that rsync needs --compress to be passed on to the other
+rsync process (in the remote repository), and that is run via
+git-annex-shell, which has a whitelist of options it will pass to rsync.
+Passing arbitrary options to rsync could allow unwanted behavior
+when git-annex-shell is being used as a security barrier. And --compress is
+one of the options that both the rsync sender and receiver have to agree
+on for the rsync protocol to work.
+
+I have added a note to the man page about this limitation of what
+the rsync-options settings can be used to do.
+"""]]
diff --git a/doc/sync/comment_24_1d1eb1bddc835644c7f9d6e83e09b752._comment b/doc/sync/comment_24_1d1eb1bddc835644c7f9d6e83e09b752._comment
new file mode 100644
index 0000000000..955b441659
--- /dev/null
+++ b/doc/sync/comment_24_1d1eb1bddc835644c7f9d6e83e09b752._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/45b0925215b6b772921a50eca1f55b55"
+ subject="sync only git-annex branch"
+ date="2019-07-18T19:52:35Z"
+ content="""
+I've finally taken the time to learn git-annex and am extraordinarily impressed by its usefulness and documentation.
+
+I'm currently using git-annex as part of a scientific workflow, wherein I use git to track my analysis source code and LaTeX reports, and git-annex to handle large binary files (typically input data).
+`git annex sync` is really handy for making sure my `git-annex` branch propagates between my remotes, and it's hard to beat the usefulness of `git annex sync --content` now that I've wrapped my head around [standard groups](http://git-annex.branchable.com/preferred_content/standard_groups/).
+However, I'd prefer if there was a flag (or configurable option) to suppress `git annex sync` from pushing/pulling whatever branch currently happens to be checked out.
+I'm a pretty thoughtful committer and want more control over where my code branches (e.g., `master`) get pushed around.
+I saw the `--no-pull` and `no-push` options for `git annex sync`, but it seems that this suppresses *all* push/pull behavior, and thus `git annex sync --no-push --no-pull` will not sync up my special `git-annex` branch.
+Is there an option or workflow that accomplishes what I'm looking for?
+
+TLDR
+I want a way to tell `git annex sync` to leave my `master` (or whatever currently checked out branch is) alone (no pushing/pulling), but otherwise behave normally (e.g., `git annex sync` will just push/pull my special `git-annex-branch` around, or `git annex sync --content` will push/pull the special `git-annex` branch, and also move content around as it makes sense).
+Apologies if this is already possible, but I haven't been able to figure it out.
+"""]]
diff --git a/doc/sync/comment_25_7e69a963102ceaa5b691ad9ed15c5a42._comment b/doc/sync/comment_25_7e69a963102ceaa5b691ad9ed15c5a42._comment
new file mode 100644
index 0000000000..6d36477df4
--- /dev/null
+++ b/doc/sync/comment_25_7e69a963102ceaa5b691ad9ed15c5a42._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: sync only git-annex branch"""
+ date="2019-07-19T16:55:33Z"
+ content="""
+@Dan, there's an open todo about that, 
+<http://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/>
+
+Please followup there if the suggested new option would work for you.
+"""]]
diff --git a/doc/sync/comment_25_ea6f4e1f5ab31cd74d67fe95e83084cb._comment b/doc/sync/comment_25_ea6f4e1f5ab31cd74d67fe95e83084cb._comment
new file mode 100644
index 0000000000..d656a30488
--- /dev/null
+++ b/doc/sync/comment_25_ea6f4e1f5ab31cd74d67fe95e83084cb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="+1 for a command to sync only the git-annex branch"
+ date="2019-07-19T18:16:08Z"
+ content="""
+I've also missed this functionality.  One use is to sync the [[metadata|git-annex-metadata]].
+"""]]
diff --git a/doc/sync/comment_27_8925805ff8902d7b2d1f47c1395aadc7._comment b/doc/sync/comment_27_8925805ff8902d7b2d1f47c1395aadc7._comment
new file mode 100644
index 0000000000..71352bca83
--- /dev/null
+++ b/doc/sync/comment_27_8925805ff8902d7b2d1f47c1395aadc7._comment
@@ -0,0 +1,54 @@
+[[!comment format=mdwn
+ username="dscheffy@c203b7661ec8c1ebd53e52627c84536c5f0c9026"
+ nickname="dscheffy"
+ avatar="http://cdn.libravatar.org/avatar/62a3a0bf0e203e3746eedbe48fd13f6d"
+ subject="Duplicate content creates frustrating cycles"
+ date="2020-12-16T17:10:52Z"
+ content="""
+I'm currently cleaning up 3 machines (with the goal of eventually upgrading my OS's) and 2 large external drives filled with 10 plus years of backups, so my current situation is somewhat temporary and may not apply to others. 
+
+I've started using preferred content to manage which repos hang onto which content. My main cleanup workflow involves moving files into a staging repository and then adding them to the annex -- then letting the preferred content settings figure out where to send the content. If I know exactly where I want the content to go, I'll move it directly into the appropriate folder, but if I haven't figured that out yet, sometimes I'll just put it in a `stage` folder. I've simplified my preferred content settings to assume that I only have one `big` external drive where everything except the contents of the `stage` directory should go, but in reality it's split up a bit across the two drives I already mentioned...
+
+```
+$ git annex wanted big
+include=* and exclude=stage/*
+$ git annex wanted stage
+include=stage/*
+```
+
+I noticed the other day that I had some missing content in `big/photo/raw`, so I went into that folder and ran `git annex get .` to rehydrate the missing files. 
+
+Today I staged some new files and ran the following from my staging annex:
+
+```
+git annex add stage
+git commit -m 'stage some new photos'
+git annex sync --content
+```
+
+This when I noticed some weirdness:
+
+```
+pull big
+...
+ok
+(merging big into stage...)
+(recording state in git...)
+copy photos/raw/pict0001.jpg (to big...) 
+SHA256E-abc--xyz.jpg
+(checksum...) ok
+drop photos/raw/pict0001.jpg ok
+...
+get stage/cats.jpg (from big...) 
+SHA256E-abc--xyz.jpg
+(checksum...) ok
+drop big stage/cats.jpg ok
+pull big 
+```
+
+Basically, if two copies of the same content live in two different files that have an affinity to two or more mutually exclusive annexes, it seems like the rule that applies to the last file in the directory tree is arbitrarily going to be the one that wins out in the end. It also means if you have such a situation, you're going to see a strange dance like this everytime you run `git annex sync --content` as the content moves across annexes only to make it's way back to where it started. 
+
+I'm currently running v6.2, so maybe this has been fixed in the interim. Has anybody else seen this? Do standard groups address this problem? I started out tryint to use standard groups, but fell back on my own custom folder definitions when I couldn't figure out how to keep my standard groups from grabbing more content than I wanted them to. 
+
+Thanks!
+"""]]
diff --git a/doc/sync/comment_28_e5c5da7fc0d0d034bfae33481f1ae067._comment b/doc/sync/comment_28_e5c5da7fc0d0d034bfae33481f1ae067._comment
new file mode 100644
index 0000000000..9dd7d3509b
--- /dev/null
+++ b/doc/sync/comment_28_e5c5da7fc0d0d034bfae33481f1ae067._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 28"""
+ date="2020-12-17T16:45:20Z"
+ content="""
+@dscheffy,
+<https://git-annex.branchable.com/bugs/indeterminite_preferred_content_state_for_duplicated_file/>
+"""]]
diff --git a/doc/sync/comment_29_161c5d3f693de45070e037d27ee7e8aa._comment b/doc/sync/comment_29_161c5d3f693de45070e037d27ee7e8aa._comment
new file mode 100644
index 0000000000..c234527fac
--- /dev/null
+++ b/doc/sync/comment_29_161c5d3f693de45070e037d27ee7e8aa._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="talmukoydu@ab15521191b4d02584d003f3f211d90f575d5ebb"
+ nickname="talmukoydu"
+ avatar="http://cdn.libravatar.org/avatar/965ffeb49ec136674054e50928ddb2ed"
+ subject="`git annex sync` not automatically syncing gcrypt remotes using relative paths"
+ date="2023-03-19T19:20:44Z"
+ content="""
+@joey Is this a bug or am I missing something?
+
+Notes:
+
+* I am using the latest git-remote-gcrypt, version 1.5
+
+Flow 1
+
+* `git remote add test gcrypt::rsync://user@user.rsync.net:relative/path/to/repo`
+* `git annex sync` -> DOES NOT SYNC to test remote
+* Nothing has been synced so I CANNOT successfully clone from the test remote with `git clone gcrypt::rsync://user@user.rsync.net:relative/path/to/repo`
+* `git push test git-annex master`
+* I can successfully clone from the test remote with `git clone gcrypt::rsync://user@user.rsync.net:relative/path/to/repo`
+
+Flow 2
+
+* `git remote add test gcrypt::rsync://user@user.rsync.net/full/path/to/repo`
+* `git annex sync` -> DOES SYNC to test remote
+* I can successfully clone from the test remote with `git clone gcrypt::rsync://user@user.rsync.net:relative/path/to/repo`
+"""]]
diff --git a/doc/sync/comment_2_9301ff5e81d37475f594e74fbe32f24e._comment b/doc/sync/comment_2_9301ff5e81d37475f594e74fbe32f24e._comment
new file mode 100644
index 0000000000..901bb41bd3
--- /dev/null
+++ b/doc/sync/comment_2_9301ff5e81d37475f594e74fbe32f24e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlDDW-g2WLLsLpcnCm4LykAquFY_nwbIrU"
+ nickname="Daniel"
+ subject="Its just grand"
+ date="2013-01-04T14:45:35Z"
+ content="""
+I cam upon git-annex a few months ago. I saw immidiately how it could help with some frustrations I've been having. One in particlar is keeping my vimrc in sync accross multiple locations and platforms. I finally took the time to give it a try after I finally hit my boiling point this morning. I went through the [walkthrough](http://git-annex.branchable.com/walkthrough/) and now I have an annax everywhere I need it. `git annex sync` and my vimrc is up-to-date, simply grand!
+
+Thanks so much for making git-annex, 
+[Daniel Wozniak](http://woz.io)
+"""]]
diff --git a/doc/sync/comment_30_f75f5957dbd0f6fd7b2d7291f06e7489._comment b/doc/sync/comment_30_f75f5957dbd0f6fd7b2d7291f06e7489._comment
new file mode 100644
index 0000000000..41a455d79d
--- /dev/null
+++ b/doc/sync/comment_30_f75f5957dbd0f6fd7b2d7291f06e7489._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="talmukoydu@ab15521191b4d02584d003f3f211d90f575d5ebb"
+ nickname="talmukoydu"
+ avatar="http://cdn.libravatar.org/avatar/965ffeb49ec136674054e50928ddb2ed"
+ subject="RE: `git annex sync` not automatically syncing gcrypt remotes using relative paths"
+ date="2023-03-19T19:27:46Z"
+ content="""
+@joey definitely seems like a bug. I am able to easily verify by changing the remote url back and forth in the .git/config and then running git annex sync. If the relative url is used git annex sync does not sync to that remote.
+"""]]
diff --git a/doc/sync/comment_31_c85edac65571caff70e87dff2317a4e5._comment b/doc/sync/comment_31_c85edac65571caff70e87dff2317a4e5._comment
new file mode 100644
index 0000000000..7c524394fa
--- /dev/null
+++ b/doc/sync/comment_31_c85edac65571caff70e87dff2317a4e5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 31"""
+ date="2023-03-21T17:47:45Z"
+ content="""
+@talmukoydu you need to file a bug report and include things like the
+version of git-annex you are using..
+<https://git-annex.branchable.com/bugs/>
+"""]]
diff --git a/doc/sync/comment_3_49560003da47490e4fabd4ab0089f2d7._comment b/doc/sync/comment_3_49560003da47490e4fabd4ab0089f2d7._comment
new file mode 100644
index 0000000000..b3b45a1e4d
--- /dev/null
+++ b/doc/sync/comment_3_49560003da47490e4fabd4ab0089f2d7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnVX_teMpJeQkyheivad_1XSCFSjpiWgx8"
+ nickname="Diggory"
+ subject="synchronising stored files with a bare repository"
+ date="2013-01-11T16:52:38Z"
+ content="""
+Good for syncing indexes, but if I want to synchronise all data files too (specifically pushing to a remote bare repository), how do I do that?
+"""]]
diff --git a/doc/sync/comment_4_cf29326408e62575085d1f980087c923._comment b/doc/sync/comment_4_cf29326408e62575085d1f980087c923._comment
new file mode 100644
index 0000000000..1ba0e61ade
--- /dev/null
+++ b/doc/sync/comment_4_cf29326408e62575085d1f980087c923._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 4"
+ date="2013-01-11T18:18:07Z"
+ content="""
+Yes, sync only syncs the git branches, not git-annex data. To sync the date, you can run a command such as `git annex copy --to bareremote`. You could run that in cron. Or, the [[assistant]] can be run as a daemon, and automatically syncs git-annex data.
+"""]]
diff --git a/doc/sync/comment_5_18c396c59907147bb2bf713e55392b6b._comment b/doc/sync/comment_5_18c396c59907147bb2bf713e55392b6b._comment
new file mode 100644
index 0000000000..dd7be6f455
--- /dev/null
+++ b/doc/sync/comment_5_18c396c59907147bb2bf713e55392b6b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://elmimmo.myopenid.com/"
+ nickname="chocolate.camera"
+ subject="How to sync content with git-annex, not assistant"
+ date="2013-10-11T09:58:12Z"
+ content="""
+Sure assistant can sync git-annex data across remotes. But how do I tell a repo to sync git-annex data, but not so manually as to having to know what exactly needs to be copied from/to where?
+"""]]
diff --git a/doc/sync/comment_6_012e9d4468d0b88ee3c5dad3911c3606._comment b/doc/sync/comment_6_012e9d4468d0b88ee3c5dad3911c3606._comment
new file mode 100644
index 0000000000..24381237f5
--- /dev/null
+++ b/doc/sync/comment_6_012e9d4468d0b88ee3c5dad3911c3606._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkI9AR8BqG4RPw_Ov2lnDCJWMuM6WMRobQ"
+ nickname="Dav"
+ subject="Syncing only a specific branch"
+ date="2013-11-24T17:48:22Z"
+ content="""
+By default, `git annex sync` will sync to all remotes, unless you specify a remote. So, I have to specify, e.g., `git annex sync origin`. I can simplify this with aliases, I suppose, but I do a lot of teaching non-programmer scientists... so it'd be nice to be able to configure this (so beginning users don't have to keep track of as many things).
+
+Is there (or will there be) a way to do this?
+"""]]
diff --git a/doc/sync/comment_7_6276e100d1341f1a0be368f54de0ae7b._comment b/doc/sync/comment_7_6276e100d1341f1a0be368f54de0ae7b._comment
new file mode 100644
index 0000000000..c40a31200c
--- /dev/null
+++ b/doc/sync/comment_7_6276e100d1341f1a0be368f54de0ae7b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 7"
+ date="2013-11-26T20:08:33Z"
+ content="""
+I feel that syncing with all remotes by default is the right thing for git annex sync to do. 
+"""]]
diff --git a/doc/sync/comment_8_b89161c82c05634d35f6b65bf8360a96._comment b/doc/sync/comment_8_b89161c82c05634d35f6b65bf8360a96._comment
new file mode 100644
index 0000000000..115a0866a9
--- /dev/null
+++ b/doc/sync/comment_8_b89161c82c05634d35f6b65bf8360a96._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkI9AR8BqG4RPw_Ov2lnDCJWMuM6WMRobQ"
+ nickname="Dav"
+ subject="Use case for not syncing to all remotes"
+ date="2013-12-08T19:20:26Z"
+ content="""
+Just in case you haven't considered such a scenario - maybe you have suggestions for how to collaborate more effectively with git annex (and avoid warning messages):
+
+I'm trying to teach beginning scientist programmers (mostly graduate students), and a common scenario is to fork some scientific code. I'd like forking on github to be mundane, and not trigger warnings, and generally have as little for folks to explicitly keep track of as possible (this seems to be a common concern we share, which leads you to prefer syncing to all remotes without the option to configure the default behavior!).
+
+However, I am currently working with students on forking and fixing up scientific code where the upstream maintainer doesn't want to allow pushes upstream, except via pull request. So, part of our approach is to set up some common shared datasets in git annex (and these just end up in our fork). If we have an \"upstream\" remote, git annex will try to sync with it, and report an error.
+
+So - that's why I'd like to be able to configure the deactivation of syncing to a defined branch (e.g., \"upstream\"). However, if you have other suggestions to smooth the workflow, I would also like to hear those!
+"""]]
diff --git a/doc/sync/comment_9_849883b7cc05bfcb01914d8737098010._comment b/doc/sync/comment_9_849883b7cc05bfcb01914d8737098010._comment
new file mode 100644
index 0000000000..ac65b03e67
--- /dev/null
+++ b/doc/sync/comment_9_849883b7cc05bfcb01914d8737098010._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 9"
+ date="2013-12-12T17:54:55Z"
+ content="""
+@Dav what kind of url does the upstream remote have? Perhaps it would be sufficient to make sync skip trying to push to git:// and http[s]:// remotes. Both are unlikely to accept pushes and in the cases where they do accept pushes it would be fine to need a manual `git push`. 
+
+Anyway, you can already configure which remotes get synced with. From the man page:
+
+<pre>
+       remote.&lt;name&gt;.annex-sync
+              If set to false, prevents  git-annex  sync  (and  the  git-annex
+              assistant) from syncing with this remote.
+</pre>
+
+So `git config remote.upstream.annex-sync=false`
+"""]]
diff --git a/doc/templates/bare.tmpl b/doc/templates/bare.tmpl
new file mode 100644
index 0000000000..2d476b716f
--- /dev/null
+++ b/doc/templates/bare.tmpl
@@ -0,0 +1 @@
+<TMPL_VAR CONTENT>
diff --git a/doc/templates/blogpost.tmpl b/doc/templates/blogpost.tmpl
new file mode 100644
index 0000000000..e9722ea255
--- /dev/null
+++ b/doc/templates/blogpost.tmpl
@@ -0,0 +1,16 @@
+<form <TMPL_IF POSTFORMID>id="<TMPL_VAR POSTFORMID ESCAPE=HTML>"</TMPL_IF> action="<TMPL_VAR CGIURL>" method="get">
+<div class="blogform">
+<TMPL_IF RSSURL>
+<a class="feedbutton" type="application/rss+xml" rel="alternate" title="<TMPL_VAR RSSDESC>" href="<TMPL_VAR RSSURL>">RSS</a>
+</TMPL_IF>
+<TMPL_IF ATOMURL>
+<a class="feedbutton" type="application/atom+xml" rel="alternate" title="<TMPL_VAR ATOMDESC>" href="<TMPL_VAR ATOMURL>">Atom</a>
+</TMPL_IF>
+<input type="hidden" name="do" value="blog" />
+<input type="hidden" name="from" value="<TMPL_VAR ROOTPAGE>" />
+<input type="hidden" name="subpage" value="1" />
+<TMPL_VAR POSTFORMTEXT>
+<input name="title" size="40" maxlength="50" />
+<input type="submit" value="Edit" />
+</div>
+</form>
diff --git a/doc/templates/buglist.tmpl b/doc/templates/buglist.tmpl
new file mode 100644
index 0000000000..70e60bfeb3
--- /dev/null
+++ b/doc/templates/buglist.tmpl
@@ -0,0 +1,27 @@
+<div class="archivepage">
+<TMPL_IF PERMALINK>
+<a href="<TMPL_VAR PERMALINK>"><TMPL_VAR TITLE></a>
+<TMPL_ELSE>
+<a href="<TMPL_VAR PAGEURL>"><TMPL_VAR TITLE></a>
+</TMPL_IF>
+<TMPL_IF TAGS>
+<small>
+<TMPL_LOOP TAGS>
+ [<TMPL_VAR LINK>]
+</TMPL_LOOP>
+</small>
+</TMPL_IF>
+<br />
+<span class="archivepagedate">
+Posted <TMPL_VAR CTIME>
+<TMPL_IF AUTHOR>
+by <span class="author">
+<TMPL_IF AUTHORURL>
+<a href="<TMPL_VAR AUTHORURL>"><TMPL_VAR AUTHOR></a>
+<TMPL_ELSE>
+<TMPL_VAR AUTHOR>
+</TMPL_IF>
+</span>
+</TMPL_IF>
+</span>
+</div>
diff --git a/doc/templates/bugtemplate.mdwn b/doc/templates/bugtemplate.mdwn
new file mode 100644
index 0000000000..f255df90e6
--- /dev/null
+++ b/doc/templates/bugtemplate.mdwn
@@ -0,0 +1,22 @@
+### Please describe the problem.
+
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+
diff --git a/doc/templates/note.mdwn b/doc/templates/note.mdwn
new file mode 100644
index 0000000000..8de7374bc0
--- /dev/null
+++ b/doc/templates/note.mdwn
@@ -0,0 +1,12 @@
+[[!templatebody <<ENDBODY
+<div class="notebox">
+<TMPL_VAR text>
+</div>
+ENDBODY]]
+
+Use this template to insert a note into a page. The note will be styled to
+float to the right of other text on the page. This template has one
+parameter:
+<ul>
+<li>`text` - the text to display in the note
+</ul>
diff --git a/doc/templates/walkthrough.tmpl b/doc/templates/walkthrough.tmpl
new file mode 100644
index 0000000000..a500a5a865
--- /dev/null
+++ b/doc/templates/walkthrough.tmpl
@@ -0,0 +1,2 @@
+<h2><a href="<TMPL_VAR PAGEURL>"><TMPL_VAR TITLE></a></h2>
+<TMPL_VAR CONTENT>
diff --git a/doc/testimonials.mdwn b/doc/testimonials.mdwn
new file mode 100644
index 0000000000..65fe8adce7
--- /dev/null
+++ b/doc/testimonials.mdwn
@@ -0,0 +1,34 @@
+<div>
+<blockquote class="twitter-tweet"><p>Git annex. Brilliant. Powerful. <a href="http://t.co/AM9B6peM" title="http://git-annex.branchable.com/">git-annex.branchable.com</a></p>&mdash; Gert van Dijk (@gertvdijk) <a href="https://twitter.com/gertvdijk/status/186456474246053888" data-datetime="2012-04-01T14:14:22+00:00">April 1, 2012</a></blockquote>
+<script src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
+<blockquote class="twitter-tweet"><p>git-annex is like dropbox without the chrome. <a href="http://t.co/qcENNt3g" title="http://git-annex.branchable.com/">git-annex.branchable.com</a></p>&mdash; Wil Chung (@iamwil) <a href="https://twitter.com/iamwil/status/185997581229367296" data-datetime="2012-03-31T07:50:53+00:00">March 31, 2012</a></blockquote>
+<script src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
+<blockquote class="twitter-tweet"><p>blender 2.62 + ffmpeg + dnxhd + git-annex = who needs final cut?</p>&mdash; cdotwright (@cdotwright) <a href="https://twitter.com/cdotwright/status/187645142864375808" data-datetime="2012-04-04T20:57:42+00:00">April 4, 2012</a></blockquote>
+<script src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
+<blockquote class="twitter-tweet"><p>I want <a href="https://twitter.com/search/%2523git">#git</a>-annex whereis for all the stuff (not) in my room.</p>&mdash; topr (@derwelle) <a href="https://twitter.com/derwelle/status/172356564072673280" data-datetime="2012-02-22T16:26:21+00:00">February 22, 2012</a></blockquote>
+<script src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
+<blockquote class="twitter-tweet"><p>Git-annex now auto-syncing photos from my android phone to a Tor hidden SSH service I control (via <a href="https://twitter.com/guardianproject">@guardianproject</a>&#39;s Orbot) <a href="https://twitter.com/search?q=%23prismbreak&amp;src=hash">#prismbreak</a></p>&mdash; Richard King (@graphiclunarkid) <a href="https://twitter.com/graphiclunarkid/statuses/347658443479449601">June 20, 2013</a></blockquote>
+<script src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
+</div>
+
+<blockquote>
+What excites me about GIT ANNEX is how it fundamentally tracks the
+backup and availability of any data you own, and allows you to share
+data with a large or small audience, ensuring that the data survives.
+</blockquote>
+-- Jason Scott <http://ascii.textfiles.com/archives/3625>
+
+Seen on IRC:
+<pre>
+oh my god, git-annex is amazing
+this is the revolution in fucking with gigantic piles of files that I've been waiting for
+</pre>
+
+And then my own story: I have a ton of drives. I have a lot of servers. I
+live in a cabin on **dialup** and often have 1 hour on broadband in a week
+to get everything I need. Without git-annex, managing all this would not be
+possible. It works perfectly for me, not a surprise since I wrote it, but
+still, it's a different level of "perfect" than anything I could put
+together before. --[[Joey]]
+
+See also: [[design/assistant/blog/day_288__success_stories]]
diff --git a/doc/testimonials/comment_1_2bf439f7a3bc3d6fab91849017946182._comment b/doc/testimonials/comment_1_2bf439f7a3bc3d6fab91849017946182._comment
new file mode 100644
index 0000000000..2c5facd1f9
--- /dev/null
+++ b/doc/testimonials/comment_1_2bf439f7a3bc3d6fab91849017946182._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="gjost"
+ ip="108.205.152.179"
+ subject="distributed digital repository"
+ date="2013-11-14T00:39:49Z"
+ content="""
+I am in the process of building a distributed digital repository using Git and git-annex as a foundation. Our project is to collect and preserve archival-quality audio and video from multiple bandwidth-challenged remote sites. We're using git-annex to help us sneakernet the metadata and binaries around and to maintain multiple copies in geographically separate locations. Git very neatly addresses the problem of tracking changes, while git-annex makes it possible to track the flow of information through a network of distributed repositories. 
+"""]]
diff --git a/doc/thanks.mdwn b/doc/thanks.mdwn
new file mode 100644
index 0000000000..aa0d090b4c
--- /dev/null
+++ b/doc/thanks.mdwn
@@ -0,0 +1,448 @@
+Financially, the development of git-annex was made possible by the generous
+donations of many people. I want to say "Thank You!" to each of
+you individually, but until I meet all 1500+ of you, this page will have to
+do. You have my most sincere thanks. --[[Joey]]
+
+You can support my git-annex development
+[on Patreon](https://www.patreon.com/joeyh) or
+[on Liberapay](https://liberapay.com/joeyh/) or
+[other ways](https://joeyh.name/thanks/)
+
+(If I got your name wrong, or you don't want it publically posted here,
+email <id@joeyh.name>.)
+
+## code and other bits
+
+git-annex is mostly developed by Joey Hess, with code contributions
+from Sören Brunk, Robie Basak, Klaus Ethgen, Sebastian Reuße, Oliver
+Matthews, guilhem, fftehnik, Ben Gamari, Eric Siegerman, Sean T Parsons,
+Félix Sipma, aristidb, Daniel Brooks, Alper Nebi Yasak,
+James MacMahon, Farhan Kathawala, divergentdave, Gabor Greif, wzhd, Pieter
+Kitslaar, Øyvind A. Holm, Michael Alan Dorman, Ben Boeckel, Robert Schütz,
+Magnus Therning, Yaroslav Halchenko, silvio, Magnus Therning,
+Justin Geibel, Trent, Jon Ander Peñalba, divB, Fraser Tweedale,
+jlebar, Johan Kiviniemi, Alberto Berti, ion, Anarcat, Adam Spiers,
+Peter Simmons, Nicolas Pouillard, Eskild Hustvedt, Nathan Collins,
+Sergei Trofimovich, Mark Wright, Jimmy Tang, Josh Triplett,
+and Joachim Breitner.
+
+Many folks have [[contributed|contribute]] documentation fixes, 
+tips, user support, etc. Two names that come to mind are Anarcat and
+CandyAngel. John Lawrence made the logo. And many others have
+contributed good bug reports and great ideas.
+
+## financial support, 2024
+
+git-annex development is supported in large part by:
+
+* [DANDI](https://www.dandiarchive.org/), funded by
+  [a NIH grant](https://projectreporter.nih.gov/project_info_description.cfm?aid=9981835)
+  awarded to MIT, Dartmouth College, and Kitware.
+* [ReproNim](https://repronim.org/), funded by
+  [a NIH grant](https://projectreporter.nih.gov/project_info_details.cfm?aid=8999833)
+  awarded to UMass Medical School Worcester, Dartmouth College, MIT, et al.
+
+Thanks also to these folks for their support: 
+[[!inline raw=yes pages="thanks/list"]] and anonymous supporters.
+
+## financial support, 2019-2023
+
+<img alt="McGill logo" src="https://mcgill.ca/hbhl/sites/all/themes/moriarty/images/logo-red.svg" width=100>
+<img alt="Neurohub" src="https://joeyh.name/blog/pics/neurohub.png" width=100>
+<img alt="Powderhouse logo" src="https://d33wubrfki0l68.cloudfront.net/e9285c9a8db37874efdadd61f2231774ce1d86cb/5de87/assets/phs-leftaligned-logo.svg" width=100>
+
+git-annex development was supported in large part by:
+
+* [NeuroHub](https://www.mcgill.ca/hbhl/research/platforms), funded
+  by the Canada First Research Excellence Fund, awarded to McGill
+  University for the Healthy Brains for Healthy Lives initiative.
+* [Datalad](http://datalad.org/), funded by
+  [a NSF grant](https://www.nsf.gov/awardsearch/showAward?AWD_ID=1912266),
+  awarded to Dartmouth College in cooperation with
+  University Magdeburg and Research Center Jülich.
+* [DANDI](https://www.dandiarchive.org/), funded by
+  [a NIH grant](https://projectreporter.nih.gov/project_info_description.cfm?aid=9981835)
+  awarded to MIT, Dartmouth College, and Kitware.
+* [ReproNim](https://repronim.org/), funded by
+  [a NIH grant](https://projectreporter.nih.gov/project_info_details.cfm?aid=8999833)
+  awarded to UMass Medical School Worcester, Dartmouth College, MIT, et al.
+* [Powderhouse Studios](https://powderhouse.org/)
+* Gioele Barabucci ENK
+
+Thanks also to these folks for their support: 
+[[!inline raw=yes pages="thanks/list.2023"]] and anonymous supporters.
+
+## financial support, 2014-2018
+
+git-annex development was partially supported by the
+[Datalad project](http://datalad.org/), funded by a
+[NSF grant](https://www.nsf.gov/awardsearch/showAward?AWD_ID=1429999),
+and niceman (repronim tr&d3).
+
+Thanks also to these folks for their support: 
+[[!inline raw=yes pages="thanks/list.2018"]] and anonymous supporters.
+
+## financial support, 2013-2014
+
+Continued git-annex development was [crowd funded](https://campaign.joeyh.name/)
+by these excellent people. *Hug*
+
+Eric Hanchrow, Michael Barabanov, Douglas Butts, Cody Woodard, Anna Hess,
+Maggie Hess, Francois Marier, Michael Linksvayer, Alexander Brem, Yaroslav
+Halchenko, Otavio Real Salvador, Giovanni Moretti, Mark Hepburn, Jim
+Cheetham, Ali Gündüz, Chia Shee Liang, Vincent Arel-Bundock, Mark R Jones,
+Willard Korfhage, Faidon Liambotis, Daniel Callahan, Sheila Miguez,
+Christopher Webber, Daniel Patterson, Charity Hanif, Blair Mckenzie, Romain
+Lenglet, Joseph Liu, Robert Beaty, Remy van Elst, Juho Snellman, Jason
+Davidson, Dane Larsen, Kuno Woudt, Navishkar Rao, Ryan Sorensen, Jonathan
+Castello, Nimrod Mesika, Amitai Schlair, Zellyn Hunter, Jan Pieper, Boyd
+Smith, Brett Eisenberg, Péter Károly Juhász, Allan Franta, Aaron De Vries,
+Donald Plummer, Joona Lehtomäki, Evan Anderson, Pedro Côrte-Real, Bradley
+Unterrheiner, Wietse van Buitenen, James Shubin, Daniel de Kok, Michael
+Zehrer, Peter deHaan, David Schmitt, Ian Downes, Gioele Barabucci, Gergely
+Nagy, Diego Ongaro, Jonas Wiklund, Strakhov Artem, £ukasz Szczęsny, Peter
+Olson, Thomas Berker, Greg Young, narf, Michael Jakl, Andrea Rota, Tobias
+Nix, Andreas Olsson, Tobias Ussing, Pere Quintana Segui, Pierre Gambarotto,
+Yuriy Zaytsev, Thomas Djärv, Thomas Hochstein, Simon Lundmark, Damien
+Diederen, Arthur Lutz, Gert Van Gool, Jed Brown, Sören Brunk, Thorsten
+Bormer, Vincent Sanders, Thomas Lundstrøm, Robert Connolly, Marc Seeger,
+Per Andreas Buer, Thomas Andersen, Hendrik Müller Hofstede, Dominik
+Wagenknecht, Robert Walker, Nicholas Weigand, Maximilian Weigand, Thomas
+Jost, John, Angel Ramboi, Thomas Bartels, Fernando Jimenez, Tobias
+Mersmann, András Veres-Szentkirályi, Richard Hartmann, John Hedges,
+Nedialko Andreev, Roderik Koenders, Sławomir Gwizdowski, Aapo Laitinen,
+Jonathan Harrington, Dirk Kraft, Fabian Bartschke, Philip Frank, Patrick
+Steegstra, Roberto Zedda, Leon Major, Torbjørn Thorsen, Lukas Anzinger,
+Pollan Ruben, Daniel Hofer, Johannes Krampf, Jörn Gersdorf, Kristoffer Egil
+Bonarjee, David Iwanowitsch, Daniel Egger, Titus Stahl, Robin Sheat, Thomas
+Nicolaisen, Karsten Heymann, Askings & Medina Business Services, Pieter
+Mulder, Geoffrey Huntley, Wouter Mooij, Kari Oikarinen, sven dowideit,
+Ethan Aubin, Nathan Rickerby, Tobias Brunner, Stian Haukaas Eikeland, Jan
+Dittberner, Jeffrey Goeke-Smith, Joseph Cullen, James Orr, Markus Plangg,
+Glendon Solsberry, Georg Bauer, Andreas Leha, Ian Kozhurin, Boris Hupkens
+van der Elst, Daniel Brockman, Scott Robinson, Olaf Lorenzen, Øyvind
+Andersen Holm, Logan Owen, Christopher Douglass, Nicolas Pouillard, Florian
+Schlegel, Hans-Christian Jehg, Thomas Mechtler, Joshua McKinney, Tom
+Atkins, Paul Scott-Wilson, Rafal Czlonka, Benjamin Williams, Ulises Vitulli, Mesar
+Hameed, Vishakh Vishakh, Daniel Washburn, Maximilian Haack, Jan Gondol,
+Carlo Matteo Capocasa, Jevgenijs Zolotarskis, John Cooper, Matthew Gregg,
+Peter Jarosak, Edward Heil, Kyle Kurtenbach, David Kaminski, Joonathan
+Mägi, Piotr Ożarowski, Ernest Braganza, Adam Sjøgren, Simon Michael,
+Protonet, Valentin Churavy, Trenton Cronholm, Ellis Whitehead, Maarten
+Everts, Paul Tötterman, Julien Lefrique, Robert F Donnelly,
+LeastAuthority.com, Floris Bruynooghe, Kevin Krouse, Bernhard Schmidt,
+Jason Woofenden, Jacek Nykis, Benjamin Carrillo, Teemu Hukkanen, William
+Heinbockel, Kristofer Bergstrom, Richard Gibson, Julian Andres Klode,
+Jeffrey Guenthner, Jochen Kupperschmidt, Andrew Eskridge, Eric Wallmander,
+Aaron Haviland, Evan Deaubl, Felix Crux, Matthew Marshall, Hamish Coleman,
+xymostech, Matthew Mercer, Ben Challenor, András Csáki, Stelian Iancu,
+Dmitri Popov, Anthony DiSanti, Perttu Luukko, Daniel Glassey, Aurélien
+Pinceaux, Svenne Krap, Sven Hartge, Frank Blendinger, Lisa Feilen, Kyle
+Kujala-Korpela, Walter Somerville, Filippo Giunchedi, Tyler Willingham,
+Gernot Schulz, Daniel Gervais, Denver Gingerich, Nicolas Joseph, tommy,
+bak, Grejdi G, Gabriel de Perthuis, Mayank Jain, Radu Raduta, Gregory
+Grossmeier, Errol Hess, Janin Kolenc, Sean Whitton, Philippe Gauthier,
+Ananda Widyadharma, Jochen Bartl, Fredrik Hammar, THM Schoemaker, Marek
+Jawurek, Johan Herland, Gian-Maria Daffre, Justine Lam, Ori Livneh, Arnaud
+Berthomier, Chad Horohoe, Lois DeFiore, Lieven Baes, Patrick Wheeler, James
+Kim, Carlos Trijueque Albarran, Ritesh Nadhani, chesty, Andre Pereira,
+Eskild Hustvedt, David Wagner, Maximiliano Curia, András Széll, Allan
+Holman, Thomas Langewouters, Anonymous, Peter Daengeli, Josh Taylor, Abhishek Dasgupta, Maarten Aertsen, Mark Sheppard,
+Daengeli, Josh Taylor, Abhishek Dasgupta, Maarten Aertsen, Mark Sheppard,
+Markus Engström, Samuel Tardieu, Geog Wechslberger, Abdó Roig, Dmitry
+Markushevich, Sergio Rubio, Jim Paris, Vivek Gani, Brock Spratlen, Nathan
+Howell, Alan Chan, Alexandre Dupas, Daniel Atlas, Patrick Hallen, Matthew
+Forrester, Binyamin Cherniavsky, Florent Fourcot, Nathan Yergler, Hannibal
+Skorepa, Cedric Staub, Melissa Binde, Marc Bobillier, Zoran Zaric, Ralph
+Mayer, Jay Pozo, Walter Somerville, Remy Honig, Bernhard Urban, Nurullah
+Akkaya, Ari Pollak, Kalle Svensson, Stephan Schulz, Joshua Honeycutt,
+Justin Keyes, Filias Heidt, Manish Sharma, Benoît Zugmeyer, Andrew Kraut,
+Markus Breitenberger, Dominik Deobald, Ayla Ounce, Tobias Ammann, Peter
+Lloyd, Pierre Chambart, Michael Alan Dorman, Kyle Meyer, Kristoffer
+Gronlund, Jay Dugger, Jeff McNeill, Oskari Timperi, Mathias Linden,
+Ole-Morten Duesund, Tom Lowenthal, Anders Lannerback, Tony Cantor,
+Stephanie Eikenberry, Vanja Cvelbar, Fabrice Rossi, Franz Pletz, Karl
+Wiberg, Sam Kleinman, Vincent Demeester, Tristan Helmich, Zero Art Radio,
+Bruno Bigras, Ævar Arnfjörð Bjarmason, Stanley Yamane, Christopher Browne,
+David Whittington, Fredrik Gustafsson, Peter Hogg, Tom Francart, Wouter
+Verhelst, Christian Savard, wundersolutions, Andreas Fuchs, Eric Kidd,
+Georg Lehner, Berin Martini, Stewart Wright, Bence parhuzamos, Stefan
+Schmitt, Antoine Boegli, jscit, Christopher Kernahan, A Marshall, Jürgen
+Peters, Aaron Whitehouse, Jouni K Seppanen, Michael Albertson, Andreas
+Laas, Thomas Herok, Aurelien Gazagne, Bryan W Stitt, anonymous, Chris
+Kastorff, Henning Hasemann, Leonardo Taglialegne, Frank Thomas, Frédéric
+Schütz, Riad Wahby, Maxwell Swadling, Bram Senders, Péter Párkányi, Tom
+Dimiduk, Christian Kellermann, Kilian Evang, Christian Studer, Tim
+Humphrey, Jürgen, Richard Collins, Renaud Casenave-Péré, Patrick Lynn,
+Gregor Gramlich, Hugo Mougard, Arun Srinivasan, Paul Tagliamonte, Don
+Armstrong, Adam DeWitt, Timothy Hobbs, Jacob Briggs, Mark Eichin, Matthew
+Raso-Barnett, Damien Raude-Morvan, Mark Lopez, Mattias Olsson, Marco A L
+Barbosa, Thomas de Ruiter, Anders Claesson, Philipp Meier, Henrik Ahlgren,
+Michael Hofmann, Audric SCHILTKNECHT, Wojtek Burakiewicz, Christian
+Dietrich, Jacob Kirkwood, Fabian Jansen, gregor herrmann, Martin Werner,
+Adam Baxter, Sören Köpping, Pierce Lopez, David Lehn, Michal Politowski,
+John Lawrence, Nicholas Golder, Adam Spiers, Pär Mattsson, Matt Lee,
+Timo Heister, Asbjørn Sloth Tønnesen, James Valleroy, Felix Gruber, Björn
+Pettersson, Nicola Chiapolini, Christer Stenbrenden, Hannes Maier-Flaig,
+Paul Walker, Cary Kempston, Andrew Cant, Albert Drengg,
+Martin Pollow, Karl-Georg Sommer, Francois Cocquemas, Daniel Bross, Martin
+Florian, Grigorios Prasinos, Olivier Berger, Andreas Herten, Kyle MacLea,
+Sozykin Mikhail, André Klärner, Pascal VITOUX, Gunilla Johansson, Dara
+Adib, Nicolas Bonifas, Glen Ogilvie, TasLUG, Shaun Westmacott, Georgi
+Valkov, Nicolas Dietrich, Auroch, Rasmus Pank Roulund, Michael Niewiera,
+Benjamin Koch, Joe Bogner, Christoph Varga, Florian Eitel, Tobias Braun,
+Jochen Schulz, Diggory Hardy, Stephane Barland, Sebastian Bober, Arash
+Rouhani-Kalleh, Geoffrey Irving, Hans Tzou, Mark Booth, Christoph Neckel,
+Aleksandar Iliev, Baldur Kristinsson, Adam Colton, KAWACHI TAKASHI, Michal
+Sojka, Alexander Brandstedt, Jarno Elonen, Rob Sharp, John Pybus, Antonino
+Mazzurco, Damon Haley, Jason Locklin, ULRICH KORTENKAMP, Karthik
+Poobalasubramanian, Alexandre Garel, David Clark, Jeff Johnson,
+Mica Semrick, Paul Staab, Rémi Vanicat, Martin Holtschneider, Jan Ivar
+Beddari, Peter Simons, Thomas Koch, Justin Geibel, Guillaume DELVIT, Shanti
+Bouchez, Oliver Brandt, François Deppierraz, Chad Walstrom, Tim Mattison,
+Jakub Antoni Tyszko, Casa do Boneco, Florian Tham,
+and 30 anonymous bitcoin users
+
+With an especial thanks to the WikiMedia foundation,
+and Rede Mocambos.
+
+## financial support, 2012-2013
+
+<a name="kickstarter">
+The git-annex assistant was [crowd funded on Kickstarter](http://www.kickstarter.com/projects/joeyh/git-annex-assistant-like-dropbox-but-with-your-own/).
+
+### Major Backers
+
+These people are just inspiring in their enthusiasm and generosity to this
+project.
+
+* Jason Scott
+* strager
+
+### Beta Testers
+
+Whole weeks of my time were made possible thanks to each of these
+people, and their testing is invaluable to the development of
+the git-annex assistant.
+
+* Jimmy Tang
+* David Pollak
+* Pater
+* Francois Marier
+* Paul Sherwood
+* Fred Epma
+* Robert Ristroph
+* Josh Triplett
+* David Haslem
+* AJ Ashton
+* Svenne Krap
+* Drew Hess
+* Peter van Westen
+
+### Prioritizers
+
+These forward-thinking people contributed generously just to help
+set my priorities in which parts of the git-annex assistant were most
+important to develop.
+
+Paul C. Bryan, Paul Tötterman, Don Marti, Dean Thompson, Djoume, David Johnston
+Asokan Pichai, Anders Østhus, Dominik Wagenknecht, Charlie Fox, Yazz D. Atlas,
+fenchel, Erik Penninga, Richard Hartmann, Graham, Stan Yamane, Ben Skelton,
+Ian McEwen, asc, Paul Tagliamonte, Sherif Abouseda, Igor Támara, Anne Wind,
+Mesar Hameed, Brandur K. Holm Petersen, Takahiro Inoue, Kai Hendry,
+Stephen Youndt, Lee Roberson, Ben Strawbridge, Andrew Greenberg, Alfred Adams
+Andrew, Aaron De Vries, Monti Knazze, Jorge Canseco, Hamish, Mark Eichin,
+Sherif Abouseda, Ben Strawbridge, chee rabbits, Pedro Côrte-Real
+
+And special thanks to Kevin McKenzie, who also gave me a login to a Mac OSX
+machine, which has proven invaluable, Jimmy Tang who has helped
+with Mac OSX autobuilding and packaging, and Yury V. Zaytsev who
+provided the Windows autobuilder.
+
+### Other Backers
+
+Most of the success of the Kickstarter is thanks to these folks. Some of
+them spent significant amounts of money in the guise of getting some
+swag. For others, being listed here, and being crucial to making the 
+git-annex assistant happen was reward enough. Large or small, these
+contributions were, literally, my bread and butter this year.
+
+Amitai Schlair, mvime, Romain Lenglet, James Petts, Jouni Uuksulainen,
+Wichert Akkerman, Robert Bellus, Kasper Souren, rob, Michiel Buddingh',
+Kevin, Rob Avina, Alon Levy, Vikash, Michael Alan Dorman, Harley Pig,
+Andreas Olsson, Pietpiet, Christine Spang, Liz Young, Oleg Kosorukov,
+Allard Hoeve, Valentin Haenel, Joost Baaij, Nathan Yergler, Nathan Howell,
+Frédéric Schütz, Matti Eskelinen, Neil McGovern, Lane Lillquist, db48x,
+Stuart Prescott, Mark Matienzo, KarlTheGood, leonm, Drew Slininger, 
+Andreas Fuchs, Conrad Parker, Johannes Engelke, Battlegarden, Justin Kelly,
+Robin Wagner, Thad Ward, crenquis, Trudy Goold, Mike Cochrane, Adam Venturella,
+Russell Foo, furankupan, Giorgio Occhioni, andy, mind, Mike Linksvayer,
+Stefan Strahl, Jelmer Vernooij, Markus Fix, David Hicks, Justin Azoff,
+Iain Nicol, Bob Ippolito, Thomas Lundstrøm, Jason Mandel, federico2,
+Edd Cochran, Jose Ortega, Emmett Agnew, Rudy Garcia, Kodi, Nick Rusnov,
+Michael Rubin, Tom de Grunt, Richard Murray, Peter, Suzanne Pierce, Jared
+Marcotte, folk, Eamon, Jeff Richards, Leo Sutedja, dann frazier, Mikkel
+kristiansen, Matt Thomas, Kilian Evang, Gergely Risko, Kristian Rumberg,
+Peter Kropf, Mark Hepburn, greymont, D. Joe Anderson, Jeremy Zunker, ctebo,
+Manuel Roumain, Jason Walsh, np, Shawn, Johan Tibell, Branden Tyree, Dinyar
+Rabady, Andrew Mason, damond armstead, Ethan Aubin, TomTom Tommie, Jimmy
+Kaplowitz, Steven Zakulec, mike smith, Jacob Kirkwood, Mark Hymers, Nathan
+Collins, Asbjørn Sloth Tønnesen, Misty De Meo, James Shubin,
+Jim Paris, Adam Sjøgren, miniBill, Taneli, Kumar Appaiah, Greg Grossmeier,
+Sten Turpin, Otavio Salvador, Teemu Hukkanen, Brian Stengaard, bob walker,
+bibeneus, andrelo, Yaroslav Halchenko, hesfalling, Tommy L, jlargentaye,
+Serafeim Zanikolas, Don Armstrong, Chris Cormack, shayne.oneill, Radu
+Raduta, Josh S, Robin Sheat, Henrik Mygind, kodx, Christian, Geoff
+Crompton, Brian May, Olivier Berger, Filippo Gadotti, Daniel Curto-Millet,
+Eskild Hustvedt, Douglas Soares de Andrade, Tom L, Michael Nacos, Michaël
+P., William Roe, Joshua Honeycutt, Brian Kelly, Nathan Rasch, jorge, Martin
+Galese, alex cox, Avery Brooks, David Whittington, Dan Martinez, Forrest
+Sutton, Jouni K. Seppänen, Arnold Cano, Robert Beaty, Daniel, Kevin Savetz,
+Randy, Ernie Braganza, Aaron Haviland, Brian Brunswick, asmw, sean, Michael
+Williams, Alexander, Dougal Campbell, Robert Bacchas, Michael Lewis, Collin
+Price, Wes Frazier, Matt Wall, Brandon Barclay, Derek van Vliet, Martin
+DeMello, kitt hodsden, Stephen Kitt, Leif Bergman, Simon Lilburn, Michael
+Prokop, Christiaan Conover, Nick Coombe, Tim Dysinger, Brandon Robinson,
+Philip Newborough, keith, Mike Fullerton, Kyle, Phil Windley, Tyler Head,
+George V. Reilly, Matthew, Ali Gündüz, Vasyl Diakonov, Paolo Capriotti,
+allanfranta, Martin Haeberli, msingle, Vincent Sanders, Steven King, Dmitry
+Gribanov, Brandon High, Ben Hughes, Mike Dank, JohnE, Diggory Hardy,
+Michael Hanke, valhalla, Samuli Tuomola, Jeff Rau, Benjamin Lebsanft, John
+Drago, James, Aidan Cooper, rondie, Paul Kohler, Matthew Knights, Aaron
+Junod, Patrick R McDonald, Christopher Browne, Daniel Engel, John SJ
+Anderson, Peter Sarossy, Mike Prasad, Christoph Ender, Jan Dittberner,
+Zohar, Alexander Jelinek, stefan, Danny O'Brien, Matthew Thode, Nicole
+Aptekar, maurice gaston, Chris Adams, Mike Klemencic, Reedy, Subito, Tobias
+Gruetzmacher, Ole-Morten Duesund, André Koot, mp, gdop, Cole Scott, Blaker,
+Matt Sottile, W. Craig Trader, Louis-Philippe Dubrule, Brian Boucheron,
+Duncan Smith, Brenton Buchbach, Kyle Stevenson, Eliot Lash, Egon Elbre,
+Praveen, williamji, Thomas Schreiber, Neil Ford, Ryan Pratt, Joshua Brand,
+Peter Cox, Markus Engstrom, John Sutherland, Dean Bailey, Ed Summers,
+Hillel Arnold, David Fiander, Kurt Yoder, Trevor Muñoz, keri, Ivan
+Sergeyenko, Shad Bolling, Tal Kelrich, Steve Presley, gerald ocker, Essex
+Taylor, Josh Thomson, Trevor Bramble, Lance Higgins, Frank Motta, Dirk
+Kraft, soundray, Joe Haskins, nmjk, Apurva Desai, Colin Dean, docwhat,
+Joseph Costello, Jst, flamsmark, Alex Lang, Bill Traynor, Anthony David,
+Marc-André Lureau, AlNapp, Giovanni Moretti, John Lawrence, João Paulo
+Pizani Flor, Jim Ray, Gregory Thrush, Alistair McGann, Andrew Wied,
+Koutarou Furukawa, Xiscu Ignacio, Aaron Sachs, Matt, Quirijn, Chet
+Williams, Chris Gray, Bruce Segal, Tom Conder, Louis Tovar, Alex Duryee,
+booltox, d8uv, Decklin Foster, Rafael Cervantes, Micah R Ledbetter, Kevin
+Sjöberg, Johan Strombom, Zachary Cohen, Jason Lewis, Yves Bilgeri, Ville
+Aine, Mark Hurley, Marco Bonetti, Maximilian Haack, Hynek Schlawack,
+Michael Leinartas, Andreas Liebschner, Duotrig, Nat Fairbanks, David
+Deutsch, Colin Hayhurst, calca, Kyle Goodrick, Marc Bobillier, Robert
+Snook, James Kim, Olivier Serres, Jon Redfern, Itai Tavor, Michael
+Fladischer, Rob, Jan Schmid, Thomas H., Anders Söderbäck, Abhishek
+Dasgupta, Jeff Goeke-Smith, Tommy Thorn, bonuswavepilot, Philipp Edelmann,
+Nick, Alejandro Navarro Fulleda, Yann Lallemant, andrew brennan, 
+Dave Allen Barker Jr, Fabian, Lukas Anzinger, Carl Witty, Andy Taylor,
+Andre Klärner, Andrew Chilton, Adam Gibbins, Alexander Wauck, Shane O'Dea,
+Paul Waite, Iain McLaren, Maggie Ellen Robin Hess, Willard Korfhage,
+Nicolas, Eric Nikolaisen, Magnus Enger, Philipp Kern, Andrew Alderwick,
+Raphael Wimmer, Benjamin Schötz, Ana Guerrero, Pete, Pieter van der Eems,
+Aaron Suggs, Fred Benenson, Cedric Howe, Lance Ivy, Tieg Zaharia, Kevin
+Cooney, Jon Williams, Anton Kudris, Roman Komarov, Brad Hilton, Rick Dakan,
+Adam Whitcomb, Paul Casagrande, Evgueni Baldin, Robert Sanders, Kagan
+Kayal, Dean Gardiner, micah altman, Cameron Banga, Ross Mcnairn, Oscar
+Vilaplana, Robin Graham, Dan Gervais, Jon Åslund, Ragan Webber, Noble Hays,
+stephen brown, Sean True, Maciek Swiech, faser, eikenberry, Kai Laborenz,
+Sergey Fedoseev, Chris Fournier, Svend Sorensen, Greg K, wojtek, Johan
+Ribenfors, Anton, Benjamin, Oleg Tsarev, PsychoHazard, John Cochrane,
+Kasper Lauritzen, Patrick Naish, Rob, Keith Nasman, zenmaster, David Royer,
+Max Woolf, Dan Gabber, martin rhoads, Martin Schmidinger, Paul
+Scott-Wilson, Tom Gromak, Andy Webster, Dale Webb, Jim Watson, Stephen
+Hansen, Mircea, Dan Goodenberger, Matthias Fink, Andy Gott, Daniel, Jai
+Nelson, Shrayas Rajagopal, Vladimir Rutsky, Alexander, Thorben Westerhuys,
+hiruki, Tao Neuendorffer Flaherty, Elline, Marco Hegenberg, robert, Balda,
+Brennen Bearnes, Richard Parkins, David Gwilliam, Mark Johnson, Jeff Eaton,
+Reddawn90, Heather Pusey, Chris Heinz, Colin, Phatsaphong Thadabusapa,
+valunthar, Michael Martinez, redlukas, Yury V. Zaytsev, Blake, Tobias
+"betabrain" A., Leon, sopyer, Steve Burnett, bessarabov, sarble, krsch.com,
+Jack Self, Jeff Welch, Sam Pettiford, Jimmy Stridh, Diego Barberá, David
+Steele, Oscar Ciudad, John Braman, Jacob, Nick Jenkins, Ben Sullivan, Brian
+Cleary, James Brosnahan, Darryn Ten, Alex Brem, Jonathan Hitchcock, Jan
+Schmidle, Wolfrzx99, Steve Pomeroy, Matthew Sitton, Finkregh, Derek Reeve,
+GDR!, Cory Chapman, Marc Olivier Chouinard, Andreas Ryland, Justin, Andreas
+Persenius, Games That Teach, Walter Somerville, Bill Haecker, Brandon
+Phenix, Justin Shultz, Colin Scroggins, Tim Goddard, Ben Margolin, Michael
+Martinez, David Hobbs, Andre Le, Jason Roberts, Bob Lopez, Gert Van Gool,
+Robert Carnel, Anders Lundqvist, Aniruddha Sathaye, Marco Gillies, Basti
+von Bejga, Esko Arajärvi, Dominik Deobald, Pavel Yudaev, Fionn Behrens,
+Davide Favargiotti, Perttu Luukko, Silvan Jegen, Marcelo Bittencourt,
+Leonard Peris, smercer, Alexandre Dupas, Solomon Matthews, Peter Hogg,
+Richard E. Varian, Ian Oswald, James W. Sarvey, Ed Grether, Frederic
+Savard, Sebastian Nerz, Hans-Chr. Jehg, Matija Nalis, Josh DiMauro, Jason
+Harris, Adam Byrtek, Tellef, Magnus, Bart Schuurmans, Giel van Schijndel,
+Ryan, kiodos, Richard 'maddog' Collins, PawZubr, Jason Gassel, Alex
+Boisvert, Richard Thompson, maddi bolton, csights, Aaron Bryson, Jason Chu,
+Maxime Côté, Kineteka Systems, Joe Cabezas, Mike Czepiel, Rami Nasra,
+Christian Simonsen, Wouter Beugelsdijk, Adam Gibson, Gal Buki, James
+Marble, Alan Chambers, Bernd Wiehle, Simon Korzun, Daniel Glassey, Eero af
+Heurlin, Mikael, Timo Engelhardt, Wesley Faulkner, Jay Wo, Mike Belle,
+David Fowlkes Jr., Karl-Heinz Strass, Ed Mullins, Sam Flint,
+Hendrica, Mark Emer Anderson, Joshua Cole, Jan Gondol, Henrik Lindhe,
+Albert Delgado, Patrick, Alexa Avellar, Chris, sebsn1349, Maxim Kachur,
+Andrew Marshall, Navjot Narula, Alwin Mathew, Christian Mangelsdorf, Avi
+Shevin, Kevin S., Guillermo Sanchez Estrada, Alex Krieger, Luca Meier, Will
+Jessop, Nick Ruest, Lani Aung, Ulf Benjaminsson, Rudi Engelbrecht, Miles
+Matton, Cpt_Threepwood, Adam Kuyper, reacocard, David Kilsheimer, Peter
+Olson, Bill Fischofer, Prashant Shah, Simon Bonnick, Alexander Grudtsov,
+Antoine Boegli, Richard Warren, Sebastian Rust, AlmostHuman, Timmy
+Crawford, PC, Marek Belski, pontus, Douglas S Butts, Eric Wallmander, Joe
+Pelar, VIjay, Trahloc, Vernon Vantucci, Matthew baya, Viktor Å tujber,
+Stephen Akiki, Daniil Zamoldinov, Atley, Chris Thomson, Jacob Briggs, Falko
+Richter, Andy Schmitz, Sergi Sagas, Peder Refsnes, Jonatan, Ben, Bill
+Niblock, Agustin Acuna, Jeff Curl, Tim Humphrey, bib, James Zarbock,
+Lachlan Devantier, Michal Berg, Jeff Lucas, Sid Irish, Franklyn, Jared
+Dickson, Olli Jarva, Adam Gibson, Lukas Loesche, Jukka Määttä, Alexander
+Lin, Dao Tran, Kirk, briankb, Ryan Villasenor, Daniel Wong, barista, Tomas
+Jungwirth, Jesper Hansen, Nivin Singh, Alessandro Tieghi, Billy Roessler,
+Peter Fetterer, Pallav Laskar, jcherney, Tyler Wang, Steve, Gigahost, Beat
+Wolf, Hannibal Skorepa, aktiveradio, Mark Nunnikhoven, Bret Comnes, Alan
+Ruttenberg, Anthony DiSanti, Adam Warkiewicz, Brian Bowman, Jonathan, Mark
+Filley, Tobias Mohr, Christian St. Cyr, j. faceless user, Karl Miller,
+Thomas Taimre, Vikram, Jason Mountcastle, Jason, Paul Elliott, Alexander,
+Stephen Farmer, rayslava, Peter Leurs, Sky Kruse, JP Reeves, John J Schatz,
+Martin Sandmair, Will Thompson, John Hergenroeder, Thomas, Christophe
+Ponsart, Wolfdog, Eagertolearn, LukasM, Federico Hernandez, Vincent Bernat,
+Christian Schmidt, Cameron Colby Thomson, Josh Duff, James Brown, Theron
+Trowbridge, Falke, Don Meares, tauu, Greg Cornford, Max Fenton, Kenneth
+Reitz, Bruce Bensetler, Mark Booth, Herb Mann, Sindre Sorhus, Chris
+Knadler, Daniel Digerås, Derek, Sin Valentine, Ben Gamari, david
+lampenscherf, fardles, Richard Burdeniuk, Tobias Kienzler, Dawid Humbla,
+Bruno Barbaroxa, D Malt, krivar, James Valleroy, Peter, Tim Geddings,
+Matthias Holzinger, Hanen, Petr Vacek, Raymond, Griff Maloney, Andreas
+Helveg Rudolph, Nelson Blaha, Colonel Fubar, Skyjacker Captain Gavin
+Phoenix, shaun, Michael, Kari Salminen, Rodrigo Miranda, Alan Chan, Justin
+Eugene Evans, Isaac, Ben Staffin, Matthew Loar, Magos, Roderik, Eugenio
+Piasini, Nico B, Scott Walter, Lior Amsalem, Thongrop Rodsavas, Alberto de
+Paola, Shawn Poulen, John Swiderski, lluks, Waelen, Mark Slosarek, Jim
+Cristol, mikesol, Bilal Quadri, LuP, Allan Nicolson, Kevin Washington,
+Isaac Wedin, Paul Anguiano, ldacruz, Jason Manheim, Sawyer, Jason
+Woofenden, Joe Danziger, Declan Morahan, KaptainUfolog, Vladron, bart, Jeff
+McNeill, Christian Schlotter, Ben McQuillan, Anthony, Julian, Martin O,
+altruism, Eric Solheim, MarkS, ndrwc, Matthew, David Lehn, Matthew
+Cisneros, Mike Skoglund, Kristy Carey, fmotta, Tom Lowenthal, Branden
+Tyree, Aaron Whitehouse
+
+## also thanks to
+
+* The Kickstarter team, who have unleashed much good on the world.
+* The Haskell developers, who toiled for 20 years in obscurity
+  before most of us noticed them, and on whose giant shoulders I now stand,
+  in awe of the view.
+* The Git developers, for obvious reasons.
+* All of git-annex's early adopters, who turned it from a personal
+  toy project into something much more, and showed me the interest was there.
+* Rsync.net, for providing me a free account so I can make sure git-annex
+  works well with it.
+* LeastAuthority.com, for providing me a free Tahoe-LAFS grid account,
+  so I can test git-annex with that.
+* Yury V. Zaytsev for running the Windows autobuilder.
+* Kevin McKenzie for providing a OSX account for testing.
+* Anna and Mark, for the loan of the video camera; as well as the rest of
+  my family, for your support. Even when I couldn't explain what I was
+  working on.
+* And Mom, for stamping and stuffing so many thank you envelopes, and all the
+  rhubarb pies.
diff --git a/doc/thanks/list b/doc/thanks/list
new file mode 100644
index 0000000000..2ebbdf39a5
--- /dev/null
+++ b/doc/thanks/list
@@ -0,0 +1,119 @@
+Kanak Kshetri, 
+Andrew Gilbert, 
+Noam Kremen, 
+Mark Reidenbach, 
+Martin D, 
+James Greenaway, 
+Timothy Schumann, 
+Graham Spencer, 
+sirmacik, 
+Cesar, 
+Rian McGuire, 
+Jelmer Vernooij, 
+Svenne Krap, 
+Ryan Rix, 
+James Read, 
+Luke Shumaker, 
+EVAN HENSHAWPLATH, 
+Nikhil, 
+Josh Moller-Mara, 
+André Pereira, 
+Brennen Bearnes, 
+N. A., 
+Denis Dzyubenko, 
+paul walmsley, 
+Pluralist Extremist, 
+Falk Hüffner, 
+Nick Piper, 
+Brett Eisenberg, 
+Eric Prestemon, 
+John Pellman, 
+Markus Hauru, 
+Ewen McNeill, 
+Nicolas Pouillard, 
+Johannes Grødem, 
+Gioele Barabucci, 
+TD, 
+Erik Bjäreholt, 
+Silvio Ankermann, 
+Michael Alan Dorman, 
+Lars Wallenborn, 
+John Kozak, 
+Michael Tolly, 
+Daniel Takamori, 
+Jack Hill, 
+Alex Watson, 
+William Hay, 
+Michal Sojka, 
+Rob Hunter, 
+Boris, 
+Trenton Cronholm, 
+E. Dunham, 
+Jake Vosloo, 
+Brock Spratlen, 
+Filippo Giunchedi, 
+LND, 
+Karl Semich, 
+Boyd Stephen Smith Jr., 
+Jochen Bartl, 
+Nathan Howell, 
+Kuno Woudt, 
+Baldur Kristinsson, 
+BonusWavePilot, 
+Mark Eichin, 
+FBC, 
+Marco Roeland, 
+Josh, 
+visnescire, 
+Simon Michael, 
+Thomas, 
+Henrik Riomar, 
+allanfranta, 
+Abdó Roig-Maranges, 
+John Carr, 
+Eskild Hustvedt, 
+Shaddy Baddah, 
+Andreas Skielboe, 
+Martin Heistermann, 
+Kevin Mueller, 
+Jarkko Kniivilä, 
+Alex, 
+Dr. Land Raider, 
+Bence parhuzamos, 
+Nick White, 
+dukeofcool199, 
+Matt, 
+Shae Erisson, 
+mortoise, 
+Jeff Moe, 
+Markus, 
+Nick, 
+Nicholas Golder-Manning, 
+Troels Henriksen, 
+Max Thoursie, 
+Thomas Haller, 
+Michael K., 
+Tobias Ammann, 
+Ilya Shlyakhter, 
+David Oates, 
+k0ld, 
+Johannes Söderlund, 
+Lawrence Brogan, 
+M K, 
+Yann Büchau, 
+unqueued, 
+Tee, 
+Arnaud Legrand, 
+Joshua Antonishen, 
+Leon Schuermann, 
+KDM, 
+vemek, 
+David W, 
+Luke T. Shumaker, 
+Alexander Thompson, 
+Nathaniel B, 
+kk, 
+Jaime Marquínez Ferrándiz, 
+Stephen Seo, 
+Antoine Balaine, 
+mycroft, 
diff --git a/doc/thanks/list.2018 b/doc/thanks/list.2018
new file mode 100644
index 0000000000..0c87020750
--- /dev/null
+++ b/doc/thanks/list.2018
@@ -0,0 +1,108 @@
+martin f. krafft, 
+John Byrnes, 
+Aurélien Couderc, 
+Jeffrey Chiu, 
+Amitai Schlair, 
+Andreas, 
+Anthony DeRobertis, 
+Baldur Kristinsson, 
+Boyd Stephen Smith Jr., 
+Brock Spratlen, 
+Christian Diller, 
+Denis Dzyubenko, 
+Eskild Hustvedt, 
+Evgeni Kunev, 
+FBC, 
+Fernando Jimenez, 
+Greg Young, 
+Henrik RIomar, 
+Ignacio, 
+Jake Vosloo, 
+James Valleroy, 
+Jason Woofenden, 
+Jeff Goeke-Smith, 
+Jim, 
+Jochen Bartl, 
+Johannes Schlatow, 
+John Carr, 
+Josh Taylor, 
+Josh Triplett, 
+Kuno Woudt, 
+Matthias Urlichs, 
+Mattias J, 
+Nathan Howell, 
+Nick Daly, 
+Nicolas Schodet, 
+Ole-Morten Duesund, 
+Remy van Elst, 
+RémiV, 
+Thom May, 
+Thomas Ferris Nicolaisen, 
+Thomas Hochstein, 
+Tyler Cipriani, 
+encryptio, 
+Øyvind A. Holm, 
+Bruno BEAUFILS, 
+Rémi Vanicat, 
+Trenton Cronholm, 
+Francois Marier, 
+Peter Hogg, 
+Amitai Schleier, 
+Brennen Bearnes, 
+Tim Howes, 
+Willard Korfhage, 
+Shane-o, 
+Michal Sojka, 
+BonusWavePilot, 
+William Hay, 
+Jack Hill, 
+Alexander Thompson, 
+Jeff Moe, 
+Michal Politowski, 
+Michael Tolly, 
+Daniel Takamori, 
+Chris Lamb, 
+Anton Grensjö, 
+Stan Yamane, 
+John Peloquin, 
+Thomas Schwinge, 
+Lars Wallenborn, 
+tj, 
+Carlos Pita, 
+Lee Hinman, 
+Lukas Platz, 
+Sergey Karpukhin, 
+Silvio Ankermann, 
+Paul Tötterman, 
+Erik Bjäreholt, 
+André Pereira, 
+Kanak Kshetri, 
+Josh, 
+tdittr, 
+Peter, 
+Nicolas Pouillard, 
+Johannes Grødem, 
+Calvin Beck, 
+mo, 
+Ewen McNeill, 
+Markus Hauru, 
+Christopher Goes, 
+Michael Magin, 
+Andreas Karlsson, 
+andrea rota, 
+Riku Voipio, 
+Ethan Aubin, 
+Pedro Luz, 
+John Pellman, 
+Duncan Holm, 
+Eric Drechsel, 
+Eric Prestemon, 
+Diederik de Haas, 
+Nick Piper, 
+Ryan Newton, 
+Brett Eisenberg, 
+paul walmsley, 
+John Lee, 
+Ilya Shlyakhter, 
+AlexS, 
+Boris, 
diff --git a/doc/thanks/list.2023 b/doc/thanks/list.2023
new file mode 100644
index 0000000000..a549f5fc64
--- /dev/null
+++ b/doc/thanks/list.2023
@@ -0,0 +1,145 @@
+Ethan Aubin, 
+Thomas May, 
+Jake Vosloo, 
+Trenton Cronholm, 
+Denis Dzyubenko, 
+Thomas Koch, 
+mo, 
+Jochen Bartl, 
+Brock Spratlen, 
+Jack Hill, 
+Nick Piper, 
+Eric Drechsel, 
+Brett Eisenberg, 
+John Pellman, 
+Boyd Stephen Smith Jr., 
+Ilya Shlyakhter, 
+Markus Hauru, 
+Kuno Woudt, 
+Ewen McNeill, 
+FBC, 
+Amitai Schleier, 
+Michal Sojka, 
+Brennen Bearnes, 
+Eric Prestemon, 
+BonusWavePilot, 
+Baldur Kristinsson, 
+Matthias Urlichs, 
+Diederik de Haas, 
+Boris, 
+Jason Woofenden, 
+William Hay, 
+Nathan Howell, 
+Josh, 
+Silvio Ankermann, 
+John Carr, 
+Henrik Riomar, 
+Eskild Hustvedt, 
+Nick Daly, 
+Daniel Takamori, 
+John Lee, 
+Lars Wallenborn, 
+Willard Korfhage, 
+Erik Bjäreholt, 
+Calvin Beck, 
+Johannes Grødem, 
+Michael Tolly, 
+AlexS, 
+paul walmsley, 
+tdittr, 
+Peter, 
+Fernando Jimenez, 
+Sergey Karpukhin, 
+Jeff Moe, 
+Alexander Thompson, 
+Nicolas Pouillard, 
+Tyler Cipriani, 
+Josh Moller-Mara, 
+Lp and Nick Daly, 
+Walltime, 
+Caleb Allen, 
+TD, 
+Pedro Araújo, 
+Ryan Newton, 
+David W, 
+L N D, 
+EVAN HENSHAWPLATH, 
+James Read, 
+Luke Shumaker, 
+Marius Konitzer, 
+Ryan Rix, 
+Svenne Krap, 
+Jelmer Vernooij, 
+Rian McGuire, 
+Cesar, 
+LND, 
+sirmacik, 
+Abdó Roig-Maranges, 
+Alex Watson, 
+allanfranta, 
+André Pereira, 
+E. Dunham, 
+Falk Hüffner, 
+Filippo Giunchedi, 
+Gioele Barabucci, 
+John Kozak, 
+Karl Semich, 
+Madison McGaffin, 
+Marco Roeland, 
+Mark Eichin, 
+Michael Alan Dorman, 
+N. A., 
+Nikhil, 
+Rob Hunter, 
+Simon Michael, 
+Stephan Burkhardt, 
+Thomas, 
+visnescire, 
+Graham Spencer, 
+Timothy Schumann, 
+Mark Reidenbach, 
+Martin D, 
+James Greenaway, 
+Kanak Kshetri, 
+Andrew Gilbert, 
+Noam Kremen, 
+Pluralist Extremist, 
+Shaddy Baddah, 
+Andreas Skielboe, 
+Martin Heistermann, 
+Kevin Mueller, 
+Jarkko Kniivilä, 
+Alex, 
+Dr. Land Raider, 
+Bence parhuzamos, 
+Nick White, 
+dukeofcool199, 
+Matt, 
+Shae Erisson, 
+mortoise, 
+Markus, 
+Nick, 
+Nicholas Golder-Manning, 
+Troels Henriksen, 
+Max Thoursie, 
+Thomas Haller, 
+Michael K., 
+Tobias Ammann, 
+David Oates, 
+k0ld, 
+Johannes Söderlund, 
+Lawrence Brogan, 
+M K, 
+Yann Büchau, 
+unqueued, 
+Tee, 
+Arnaud Legrand, 
+Joshua Antonishen, 
+Leon Schuermann, 
+KDM, 
+vemek, 
+Luke T. Shumaker, 
+Nathaniel B, 
+Jaime Marquínez Ferrándiz, 
+Lukas Waymann, 
+kk, 
diff --git a/doc/tips.mdwn b/doc/tips.mdwn
new file mode 100644
index 0000000000..eda84c8672
--- /dev/null
+++ b/doc/tips.mdwn
@@ -0,0 +1,4 @@
+This page is a place to document tips and techniques for using git-annex.
+
+[[!inline pages="tips/* and !tips/*/*" archive="yes"
+rootpage="tips" postformtext="Add a new tip about:" show=0]]
diff --git a/doc/tips/Accessing_files_in_bare_remotes_without_git-annex.mdwn b/doc/tips/Accessing_files_in_bare_remotes_without_git-annex.mdwn
new file mode 100644
index 0000000000..a1322e1546
--- /dev/null
+++ b/doc/tips/Accessing_files_in_bare_remotes_without_git-annex.mdwn
@@ -0,0 +1,8 @@
+
+git-annex is amazing for my large files backup necessities, but I am a bit scared for the long-term possibility of accessing data, without git-annex.
+
+For this reason I have prepared a small Python tool that accesses the content of bare git-annex repositories. The tool retrieves the locations of a file, and the path to the file in the current annex. This works with the last v7 version of the git-annex format.
+
+This is motivated by the fact that in the master branch the files are stores as links to .git/annex/objects/XX/YY/KEY/KEY (as it is correct for non-bare repos), while in the bare the files are stored in annex/objecst/ZZ/WW/KEY/KEY.
+
+The source code is available here: <https://gist.github.com/eruffaldi/924f6b53a63dede6e59f>
diff --git a/doc/tips/Accessing_files_in_bare_remotes_without_git-annex/comment_1_9243af1c87fdaf33e336ec34e99c0f74._comment b/doc/tips/Accessing_files_in_bare_remotes_without_git-annex/comment_1_9243af1c87fdaf33e336ec34e99c0f74._comment
new file mode 100644
index 0000000000..4843f702a1
--- /dev/null
+++ b/doc/tips/Accessing_files_in_bare_remotes_without_git-annex/comment_1_9243af1c87fdaf33e336ec34e99c0f74._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="emanuele.ruffaldi@56b9c9a5c1f873994b869248e9b53aa20f437d20"
+ nickname="emanuele.ruffaldi"
+ subject="Updated"
+ date="2016-01-12T22:47:49Z"
+ content="""
+- support for non-bare repositories
+- option for creating a tar file containing all the master checked out with the symbolic links to the content files. This is mountable with the archivemount tool
+"""]]
diff --git a/doc/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex.mdwn b/doc/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex.mdwn
new file mode 100644
index 0000000000..9e6d7654f5
--- /dev/null
+++ b/doc/tips/Announcing_recastex_-___40__re__41__podcast__from_your_annex.mdwn
@@ -0,0 +1,15 @@
+Hi all,
+
+I've written a simple tool in Python to re-podcast from an annex:  [recastex](https://github.com/stewart123579/recastex)
+
+Starting with the [downloading podcasts](https://git-annex.branchable.com/tips/downloading_podcasts/) page, I've got a number of podcasts on my laptop, but they were not really synced to my podcast app on my phone.  Not a problem any longer.
+
+The app uses the metadata associated with *locally available* files to generate feeds for each of your "subscribed" podcasts - and collects anything else you have (like individual files) into a catch-all feed.
+
+It's designed with git-annex + limited network + privacy in mind separating the public internet queries from the things that can be done over git-annex.
+
+*(As the author of [git-annex-metadata-gui](https://git-annex.branchable.com/tips/a_gui_for_metadata_operations/) said...)*  I hope these can be useful to someone other than myself.
+
+
+
+
diff --git a/doc/tips/Building_git-annex_on_Debian_OR___37____164____35____34____164____37____38____34____35___Haskell__33__.mdwn b/doc/tips/Building_git-annex_on_Debian_OR___37____164____35____34____164____37____38____34____35___Haskell__33__.mdwn
new file mode 100644
index 0000000000..c32eb966f7
--- /dev/null
+++ b/doc/tips/Building_git-annex_on_Debian_OR___37____164____35____34____164____37____38____34____35___Haskell__33__.mdwn
@@ -0,0 +1,111 @@
+I've been wrestling with git-annex to try to make it build on Debian, or more specifically, wrestling with Haskell dependencies.
+
+After a fair amount of futzing around, and pestering a bunch of people in the process (thanks for the help! :) ) I finally managed to make it build.
+
+I figured I would post the steps here, since it's not completely trivial, and I expect that a few others might be interested in building newer versions as well.
+
+There appears to currently be two methods:
+
+* Debian packages on Wheezy plus Sid
+  * Starting out on Wheezy, and then picking the rest from Sid (it seems at least libghc-safesemaphore-dev from Sid is critical for newer git-annex)
+  * WebDAV suport will not be available with this method
+* Cabal packages
+
+
+#Debian packages on Wheezy plus Sid
+
+##Start off with a clean wheezy chroot
+
+    sudo debootstrap wheezy debian-wheezy
+    sudo chroot debian-wheezy
+
+##Install some build tools
+
+    apt-get update
+    apt-get install devscripts git
+
+##Get git-annex (either by cloning or simply moving the source into the chroot)
+
+    mkdir /src
+    cd /src
+    git clone git://git-annex.branchable.com/source.git git-annex
+    cd git-annex
+
+##Remove WebDAV dependency which can't be satisfied anywhere
+
+    sed '/libghc-dav-dev/d' -i debian/control
+
+##Create dummy build-depends package and install all available Wheezy dependencies using it
+
+    mk-build-deps
+    dpkg -i git-annex-build-deps*.deb
+    apt-get install -f
+
+(this will remove the build-depends package)
+
+##Add Sid sources and install all available Sid dependencies
+
+    echo "deb http://http.debian.net/debian sid main" >>/etc/apt/sources.list
+    apt-get update
+    dpkg -i git-annex-build-deps*.deb
+    apt-get install -f
+
+(the build-depends package should now be fully installed)
+
+##Disable the 'make test' that fails due to missing hothasktags
+
+    echo >>debian/rules
+    echo "override_dh_auto_test:" >>debian/rules
+
+##Build!
+
+    debuild -us -uc -Igit
+
+
+#Cabal packages
+
+##Start off with a clean Sid(/Wheezy) chroot
+
+    sudo debootstrap sid debian-sid
+    sudo chroot debian-sid
+
+##Install a smaller set of tools and build-depends from Debian (cabal needs these to compile the Haskell stuff)
+
+    apt-get update
+    apt-get install ghc cabal-install devscripts libz-dev pkg-config c2hs libgsasl7-dev libxml2-dev libgnutls-dev c2hs git debhelper ikiwiki perlmagick uuid rsync openssh-client fakeroot
+
+##Get git-annex (either by cloning or simply moving the source into the chroot)
+
+    mkdir /src
+    cd /src
+    git clone git://git-annex.branchable.com/source.git git-annex
+    cd git-annex
+
+##Install the Haskell build-dependencies from cabal
+
+    cabal update
+    cabal install --only-dependencies
+
+##Optional step which doesn't work (might in the future)
+If we want to run the 'make test' after build we need hothasktags, which is only available via cabal
+
+    apt-get install happy
+    cabal install hothasktags
+    export PATH=$PATH:~/.cabal/bin
+
+But this currently fails silently inside make test->fast->tags, and if you dig a bit (manually edit the makefile to be more verbose) you see
+
+    hothasktags: ./Command/AddUnused.hs: hGetContents: invalid argument (invalid byte sequence)
+
+##Disable the 'make test' that fails
+
+    echo >>debian/rules
+    echo "override_dh_auto_test:" >>debian/rules
+
+##Remove all Debian package haskell depends (taken care of by cabal instead)
+
+    sed '/\tlibghc/d' -i debian/control
+
+## Build!
+
+    debuild -us -uc -Igit
diff --git a/doc/tips/Building_git-annex_on_Debian_OR___37____164____35____34____164____37____38____34____35___Haskell__33__/comment_1_835a3608df3e9d044cabe822d0f3e7e4._comment b/doc/tips/Building_git-annex_on_Debian_OR___37____164____35____34____164____37____38____34____35___Haskell__33__/comment_1_835a3608df3e9d044cabe822d0f3e7e4._comment
new file mode 100644
index 0000000000..55cf0b97b9
--- /dev/null
+++ b/doc/tips/Building_git-annex_on_Debian_OR___37____164____35____34____164____37____38____34____35___Haskell__33__/comment_1_835a3608df3e9d044cabe822d0f3e7e4._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkCw26IdxXXPBoLcZsQFslM67OJSJynb1w"
+ nickname="Alexander"
+ subject="can't install git-annex on OS X Mountain Lion without disabling WebDAV support"
+ date="2013-04-29T17:57:03Z"
+ content="""
+possibly related to this Debian issue:
+
+trying to install git-annex with cabal on OS X 10.8.3, the build fails with
+
+
+    Loading package DAV-0.4 ... linking ... ghc: 
+    lookupSymbol failed in relocateSection (relocate external)
+    ~/.cabal/lib/DAV-0.4/ghc-7.4.2/HSDAV-0.4.o: unknown symbol `_DAVzm0zi4_PathszuDAV_version1_closure'
+    ghc: unable to load package `DAV-0.4'
+    Failed to install git-annex-4.20130417
+    cabal: Error: some packages failed to install:
+    git-annex-4.20130417 failed during the building phase. The exception was:
+    ExitFailure 1
+
+
+This was after following all of the instructions for the Homebrew install at [http://git-annex.branchable.com/install/OSX/](http://git-annex.branchable.com/install/OSX/)
+I was able to work around this issue by installing with the WebDAV flag disabled (ie, added the option --flags=\"-WebDAV\" to last command in the OS X install instructions):
+
+    cabal install git-annex --bindir=$HOME/bin --flags=\"-WebDAV\"
+
+"""]]
diff --git a/doc/tips/Building_git-annex_on_Debian_OR___37____164____35____34____164____37____38____34____35___Haskell__33__/comment_2_080b30cba72a718e73ea715e259e1cfb._comment b/doc/tips/Building_git-annex_on_Debian_OR___37____164____35____34____164____37____38____34____35___Haskell__33__/comment_2_080b30cba72a718e73ea715e259e1cfb._comment
new file mode 100644
index 0000000000..7e8e295fdc
--- /dev/null
+++ b/doc/tips/Building_git-annex_on_Debian_OR___37____164____35____34____164____37____38____34____35___Haskell__33__/comment_2_080b30cba72a718e73ea715e259e1cfb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-04-30T21:51:50Z"
+ content="""
+@Alexander that DAV-0.4 problem is a bug in DAV, not git-annex. I've informed its author and it should be fixed soon, in a new version of DAV.
+"""]]
diff --git a/doc/tips/Bup_repositories_in_git-annex.mdwn b/doc/tips/Bup_repositories_in_git-annex.mdwn
new file mode 100644
index 0000000000..542dc2f587
--- /dev/null
+++ b/doc/tips/Bup_repositories_in_git-annex.mdwn
@@ -0,0 +1,51 @@
+I'd like to share my setup for keeping [bup](https://github.com/bup/bup/) repositories in git-annex.¹
+I'm not sure if this is a *good* tip, so comments are welcome.
+
+The purpose of this setup is to (kind of) bring encryption to bup,
+and make it easy to keep bup backups in untrusted storage by making use of the encryption modes and backends provided by git-annex.
+This approach can be used to make encrypted *backups of bup repositories*;
+it can not replace encrypted filesystems such as EncFS or S3QL
+which wouldn't necessarily require local bup repositories but also can't be combined with storage like Amazon Glacier.
+
+To add a bup repository to git-annex, initialize a regular indirect git-annex repository,
+and make the bup repository a subdirectory of it.²
+Then `git annex add $BUP_REPO/objects/packs`, i.e. the location of the large data files (.pack & .par2).
+The rest of the bup repository should be tracked by Git (`git add $BUP_REPO`).³
+This way the repository stays fully functional.
+
+After a bup-save the following steps will synchronize all remotes:⁴
+
+    git annex add $BUP_REPO/objects/pack
+    git add $BUP_REPO
+    git commit -m "Backup on $(date)"
+	git annex sync --content
+
+In my current setup, the git-annex repositories are located on a local file server.
+Various clients use bup to create backups on the server.
+This server also makes backups of other servers.
+Afterwards, it uploads the annexed data to Glacier
+(via an [encrypted S3 special remote](/special_remotes/S3/)),
+and pushes the small Git repositories to an S3QL filesystem and another off-site server.
+Using these repositories (and my GPG key) the bup repositories could be recovered.
+
+It may be important to note that in order to be able to *access* a bup repository,
+*all* files have to be available locally.
+Bup will not function if any pack files are missing (maybe this can be improved?).
+
+-----
+
+¹) Not to be confused with git-annex's [bup special remote](/special_remotes/bup/).
+
+²) You can't initialize git-annex repositories directly inside bup repositories
+because git-annex will (rightfully) identify them as bare git repositories and set itself up accordingly.
+
+³) I've come up with these .gitignore rules to exclude potentially large files not needed for recovery:
+
+    /bup_repo/bupindex*
+    /bup_repo/objects/pack/bup.bloom
+    /bup_repo/objects/pack/midx*midx
+    /bup_repo/objects/tmp*.pack
+    /bup_repo/index-cache/
+
+⁴) `git annex sync` might not be the safest command to use because it would merge changes from the remotes.
+However, assuming normal bup usage, external changes to the bup repository are not to be expected.
diff --git a/doc/tips/Bup_repositories_in_git-annex/comment_1_738959a699755704baab6df778ecd120._comment b/doc/tips/Bup_repositories_in_git-annex/comment_1_738959a699755704baab6df778ecd120._comment
new file mode 100644
index 0000000000..5b9566c3ae
--- /dev/null
+++ b/doc/tips/Bup_repositories_in_git-annex/comment_1_738959a699755704baab6df778ecd120._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="sfowijowa"
+ subject="bup.bloom must be unlocked"
+ date="2015-07-17T17:45:24Z"
+ content="""
+Hi, Thanks for the help :) I didn't exlude any files. Therefore \"$BUP_REPO/objects/pack/bup.bloom\" gets added by git-annex. This file has to be unlocked beforehand for bup to be running correctly. Best regards
+"""]]
diff --git a/doc/tips/Crude_Windows_Sync.mdwn b/doc/tips/Crude_Windows_Sync.mdwn
new file mode 100644
index 0000000000..88138a0b1d
--- /dev/null
+++ b/doc/tips/Crude_Windows_Sync.mdwn
@@ -0,0 +1,35 @@
+Here's a workaround to start syncing folders on Windows right now. It's a bit command line heavy, so you might need to set this up for your users. But I would much rather do this than use some other syncing solution and then have to migrate.
+
+(1) Create a remote server git annex repository with the assistant on Linux or Mac.
+
+(2) [Install git](http://git-scm.com/) on the Windows machine.
+
+(3) [Install git-annex for Windows](http://git-annex.branchable.com/install/Windows/) on the Windows machine. Don't forget to run the installer as administrator.
+
+(4) Run _Git Bash_ from the system menu, and run these commands to clone your repository.
+
+    ssh-keygen
+    cat .ssh/id_rsa.pub | ssh username@my-server.com "cat >> ~/.ssh/authorized_keys"
+    git clone username@my-server.com:/path/to/annex
+    cd annex
+    git annex init
+
+(5) Create a script that will trigger a full sync
+
+    echo '
+    #!/bin/bash
+    git annex sync
+    git annex get *
+    git annex add .
+    git annex sync
+    git annex copy * --to origin  
+    ' > sync.sh
+    chmod +x sync.sh
+    ./sync.sh
+
+(6) Copy the "Git Bash" shortcut from your windows menu to your desktop, and change the link target to:
+
+    C:\Program Files\Git\bin\sh.exe" --login -i "annex/sync.sh"
+
+Now ask your users to run this shortcut before and after they change files. You can also put it into the "autostart" folder to sync at boot.
+
diff --git a/doc/tips/Decentralized_repository_behind_a_Firewall.mdwn b/doc/tips/Decentralized_repository_behind_a_Firewall.mdwn
new file mode 100644
index 0000000000..9e347c73f7
--- /dev/null
+++ b/doc/tips/Decentralized_repository_behind_a_Firewall.mdwn
@@ -0,0 +1,59 @@
+If you're anything like me¹, you have a copy of your annex on a computer running at home², set up so you can access it from anywhere like this:
+
+    ssh myhome.no-ip.org
+
+This is totally great! Except, there is no way for your home computer to pull your changes, because there is no *on-the-go.no-ip.org*. You can get clunky and use a *bare git repository and git push*, but there is a better way.
+
+First, install *openssh-server* on your *on-the-go* computer
+
+    sudo apt-get install openssh-server # Adjust to your flavor of unix
+
+Then, log into your *home* computer, with *port forwarding*:
+
+    ssh me@myhome.no-ip.org -R 2201:localhost:22
+
+Your *home* computer can now ssh into your *on-the-go* computer, as long as you keep the above shell running.
+
+You can now add your *on-the-go* computer as a remote on your *home* computer. Use the port forwarding shell you just connected with the command above, if you like. 
+
+    ssh-keygen -t rsa
+    ssh-copy-id "me@localhost -p 2201"
+    cd ~/annex
+    git remote add on-the-go ssh://me@localhost:2201/home/myuser/annex
+
+Now you can run normal annex operations, as long as the port forwarding shell is running³.
+
+    git annex sync
+    git annex get on-the-go some/big/file
+    git annex info
+
+You can add more computers by repeating with a different port, e.g. 2202 or 2203 (or any other).
+
+If you're security paranoid (like me), read on. If you're not, that's it! Thanks for reading!
+
+---
+Paranoid Area
+
+Note you're granting passwordless access to your on-the-go computer to your home computer. I believe that's all right, as long as:
+
+* Your home computer is really in your home, and not at a friend's house or some datacenter
+* Your home computer can be accessed only by ssh, and not HTTP or Samba or NTP or (shoot me now!) FTP
+* Only you (and perhaps trustworthy family) have access to your home computer
+* You have reasonably strong passwords or key-only logins on both your home and on-the-go computers.
+* You regularly install security updates on both computers (sudo apt-get update && sudo apt-get upgrade)
+
+In any case, the setup is much, much, much more secure than Dropbox. With Dropbox, you have exactly the same setup, but:
+
+* Your data is stored in some datacenter. It's supposed to be encrypted. It might not be.
+* Lot's of people have routine access to your files, and plausible reason to. Bored employees might regularly be doing some 'maintenance work' involving your pictures.
+* The dropbox software can do anything it likes on your computer, and it's closed source so you don't know if it does. A disgruntled employee could put a trojan into it.
+* Dropbox might have a backdoor for employee access to any file on your computer. This might be done with the best of intentions, but a mal-intentioned or careless employee might still erase things or send sensitive files from your computer by email.
+* A truly huge amount of eyes connected to incredibly smart brains have looked at openssh and found it secure. Everybody trusts openssh. With dropbox, there is, well, dropbox. Whoever that is.
+
+-----
+
+¹ Me=Carlo, not Joey. I'm pretty sure doing what I wrote here is a good idea, but in case it turns out to be catastrophically dumb, it's my fault, not his.
+
+² My always-on computer at home is a raspberry pi with a 32GB USB stick. Best self-hosted dropbox you could imagine.
+
+³ You can just forward the port, but not open a shell, by adding the -N command. This could be useful for connecting on startup, e.g. in /etc/rc.local. I prefer to open the shell to forward the ports, maybe use it, and close it to stop it.
diff --git a/doc/tips/Decentralized_repository_behind_a_Firewall/comment_1_78b9035234a690ca5a7c9f3cc78fa092._comment b/doc/tips/Decentralized_repository_behind_a_Firewall/comment_1_78b9035234a690ca5a7c9f3cc78fa092._comment
new file mode 100644
index 0000000000..71a1db9c88
--- /dev/null
+++ b/doc/tips/Decentralized_repository_behind_a_Firewall/comment_1_78b9035234a690ca5a7c9f3cc78fa092._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 1"
+ date="2012-11-30T16:25:58Z"
+ content="""
+If you don't trust your home computer with shell access, you can lock it down in `.ssh/authorized_keys` to only be able to run git-annex-shell. See [[forum/Restricting_git-annex-shell_to_a_specific_repository]]
+"""]]
diff --git a/doc/tips/Decrypting_files_in_special_remotes_without_git-annex.mdwn b/doc/tips/Decrypting_files_in_special_remotes_without_git-annex.mdwn
new file mode 100644
index 0000000000..3d2fd35a11
--- /dev/null
+++ b/doc/tips/Decrypting_files_in_special_remotes_without_git-annex.mdwn
@@ -0,0 +1,123 @@
+One of the selling points of `git-annex` is that it uses standard tools like `git` and `gpg` to deal with files, so that years from now it should be possible to explore and get useful data out of an old annex repository (this helps with [[future_proofing]]). If for whatever reason you need to decrypt files on [[special_remotes]] that use [[encryption]] without using `git-annex`, this can be done fairly easily using `gpg` (and `openssl` to compute the HMAC keys used to create the file names used on the special remote so you can look up the right file to decrypt). Here is an example script demonstrating how to compute the special remote file names and how to decrypt the special remote files.
+
+    #!/usr/bin/env bash
+    
+    usage() {
+    	echo "Usage: ga_decrypt.sh -r REMOTE [-k SYMLINK] [-d FILE]"
+    	echo ""
+    	echo "    Either lookups up key on REMOTE for annex file linked with SYMLINK"
+    	echo "    or decrypts FILE encrypted for REMOTE."
+    	echo ""
+    	echo "    -r: REMOTE is special remote to use"
+    	echo "    -k: SYMLINK is symlink in annex to print encrypted special remote key for"
+    	echo "    -d: FILE is path to special remote file to decrypt to STDOUT"
+    	echo ""
+    	echo "NOTES: "
+    	echo "    * Run in an indirect git annex repo."
+    	echo "    * Must specify -k or -d."
+    	echo "    * -k prints the key including the leading directory names used for a "
+    	echo "       directory remote (even if REMOTE is not a directory remote)"
+    	echo "    * -d works on a locally accessible file. It does not fetch a remote file"
+    	echo "    * Must have gpg and openssl"
+    }
+    
+    decrypt_cipher() {
+    	cipher="$1"
+    	echo "$(echo -n "$cipher" | base64 -d | gpg --decrypt --quiet)"
+    }
+    
+    lookup_key() {
+    	encryption="$1"
+    	cipher="$2"
+    	symlink="$3"
+    
+    	if [ "$encryption" == "hybrid" ] || [ "$encryption" == "pubkey" ]; then
+    		cipher="$(decrypt_cipher "$cipher")"
+    	fi
+    
+    	# Pull out MAC cipher from beginning of cipher
+    	if [ "$encryption" = "hybrid" ] ; then
+    		cipher="$(echo -n "$cipher" | head  -c 256 )"
+    	elif [ "$encryption" = "shared" ] ; then
+    		cipher="$(echo -n "$cipher" | base64 -d | tr -d '\n' | head  -c 256 )"
+    	elif [ "$encryption" = "pubkey" ] ; then
+    		# pubkey cipher includes a trailing newline which was stripped in
+    		# decrypt_cipher process substitution step above
+    		IFS= read -rd '' cipher < <( printf "$cipher\n" )
+    	fi
+    
+    	annex_key="$(basename "$(readlink "$symlink")")"
+    	hash="$(echo -n "$annex_key" | openssl dgst -sha1 -hmac "$cipher" | sed 's/(stdin)= //')"
+    	key="GPGHMACSHA1--$hash"
+    	checksum="$(echo -n $key | md5sum)"
+    	echo "${checksum:0:3}/${checksum:3:3}/$key"
+    }
+    
+    decrypt_file() {
+    	encryption="$1"
+    	cipher="$2"
+    	file_path="$3"
+    
+    	if [ "$encryption" = "pubkey" ] ; then
+    		gpg --quiet --decrypt "${file_path}"
+    	else
+    		if [ "$encryption" = "hybrid" ] ; then
+    			cipher="$(decrypt_cipher "$cipher" | tail -c +257)"
+    		elif [ "$encryption" = "shared" ] ; then
+    			cipher="$(echo -n "$cipher" | base64 -d | tr -d '\n' | tail  -c +257 )"
+    		fi
+    		gpg --quiet --batch --passphrase "$cipher" --output - "${file_path}"
+    	fi
+    }
+    
+    main() {
+    	OPTIND=1
+    
+    	mode=""
+    	remote=""
+    
+    	while getopts "r:k:d:" opt; do
+    		case "$opt" in
+    			r)  remote="$OPTARG"
+    				;;
+    			k)  if [ -z "$mode" ] ; then
+    					mode="lookup key"
+    				else
+    					usage
+    					exit 2
+    				fi
+    				symlink="$OPTARG"
+    				;;
+    			d)  if [ -z "$mode" ] ; then
+    					mode="decrypt file"
+    				else
+    					usage
+    					exit 2
+    				fi
+    				file_path="$OPTARG"
+    				;;
+    		esac
+    	done
+    
+    	if [ -z "$mode" ] || [ -z "$remote" ] ; then
+    		usage
+    		exit 2
+    	fi
+    
+        shift $((OPTIND-1))
+    
+    	# Pull out config for desired remote name
+    	remote_config="$(git show git-annex:remote.log | grep 'name='"$remote ")"
+    
+    	# Get encryption type and cipher from config
+    	encryption="$(echo "$remote_config" | grep -oP 'encryption\=.*? ' | tr -d ' \n' | sed 's/encryption=//')"
+    	cipher="$(echo "$remote_config" | grep -oP 'cipher\=.*? ' | tr -d ' \n' | sed 's/cipher=//')"
+    
+    	if [ "$mode" = "lookup key" ] ; then
+    		lookup_key "$encryption" "$cipher" "$symlink"
+    	elif [ "$mode" = "decrypt file" ] ; then
+    		decrypt_file "$encryption" "$cipher" "${file_path}"
+    	fi
+    }
+
+    main "$@"
diff --git a/doc/tips/Decrypting_files_in_special_remotes_without_git-annex/comment_1_9288805fae0710b19da6c82f9dc32f2a._comment b/doc/tips/Decrypting_files_in_special_remotes_without_git-annex/comment_1_9288805fae0710b19da6c82f9dc32f2a._comment
new file mode 100644
index 0000000000..d61c152740
--- /dev/null
+++ b/doc/tips/Decrypting_files_in_special_remotes_without_git-annex/comment_1_9288805fae0710b19da6c82f9dc32f2a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yibe"
+ avatar="http://cdn.libravatar.org/avatar/649c9e417b6c509a17f7b48caf065c91"
+ subject="comment 1"
+ date="2017-06-04T19:26:47Z"
+ content="""
+I have modified the script to add support for chunks and auto-detection of the MAC algorithm used: <https://gist.github.com/edb505a973999fe9aaa6c039c5ed0fbe>
+"""]]
diff --git a/doc/tips/Delay_Assistant_Startup_on_Login.mdwn b/doc/tips/Delay_Assistant_Startup_on_Login.mdwn
new file mode 100644
index 0000000000..74652308ae
--- /dev/null
+++ b/doc/tips/Delay_Assistant_Startup_on_Login.mdwn
@@ -0,0 +1,13 @@
+# Problem
+I noticed that after installing git-annex assistant, my start up times greatly increased because the assistant does a startup scan while everything else is loading.
+# Solution (for people using Gnome)
+The solution I came up with is to delay the assistant's startup, as well as setting its IO priority as idle. To do this in Gnome 3, run:
+
+    gnome-session-properties
+Find the "Git Annex Assistant" entry in the Startup Programs tab, then click edit. Change this:
+
+    /usr/local/bin/git-annex assistant --autostart (your location of git-annex may be different)
+to this:
+
+    bash -c "sleep 30; ionice -c3 /usr/local/bin/git-annex assistant --autostart" (replace /usr/local/bin to wherever git-annex is installed)
+The "sleep 30" command delays the startup of the assistant by 30 seconds, and "ionice -c3" sets git-annex's IO priority to "idle," the lowest level.
diff --git a/doc/tips/Delay_Assistant_Startup_on_Login/comment_1_c63917150527efab4b1106183b3aa7ef._comment b/doc/tips/Delay_Assistant_Startup_on_Login/comment_1_c63917150527efab4b1106183b3aa7ef._comment
new file mode 100644
index 0000000000..fe8cb80ba3
--- /dev/null
+++ b/doc/tips/Delay_Assistant_Startup_on_Login/comment_1_c63917150527efab4b1106183b3aa7ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~alphapapa"
+ nickname="alphapapa"
+ subject="ionice not supported by deadline scheduler"
+ date="2013-06-28T17:43:47Z"
+ content="""
+Linux's deadline I/O scheduler does not support ionice.  It is now the default on some distros, including Ubuntu.  CFQ does support ionice.
+"""]]
diff --git a/doc/tips/Faster_bash_autocompletion_with_big_annex_repos.mdwn b/doc/tips/Faster_bash_autocompletion_with_big_annex_repos.mdwn
new file mode 100644
index 0000000000..61d49192ca
--- /dev/null
+++ b/doc/tips/Faster_bash_autocompletion_with_big_annex_repos.mdwn
@@ -0,0 +1,50 @@
+I'm currently using git annex to manage my entire file collection
+(including tons of music and books) and I noticed how slow
+autocompletion has become for files in the index (say for git add).
+The main offender is a while-read-case-echo bash loop in
+`__git_index_files` that can be readily substituted with a much faster
+sed invocation. Here is my benchmark:
+
+```
+__git_index_files ()
+{
+    local dir="$(__gitdir)" root="${2-.}" file;
+    if [ -d "$dir" ]; then
+        __git_ls_files_helper "$root" "$1" | while read -r file; do
+            case "$file" in
+                ?*/*)
+                    echo "${file%%/*}"
+                ;;
+                *)
+                    echo "$file"
+                ;;
+            esac;
+        done | sort | uniq;
+    fi
+}
+
+time __git_index_files > /dev/null
+
+real    0m0.830s
+user    0m0.597s
+sys    0m0.310s
+
+__git_index_files ()
+{
+    local dir="$(__gitdir)" root="${2-.}" file;
+    if [ -d "$dir" ]; then
+        __git_ls_files_helper "$root" "$1" | \
+            sed -r 's@/.*@@' | uniq | sort | uniq
+    fi
+}
+
+
+time __git_index_files > /dev/null
+
+real    0m0.075s
+user    0m0.083s
+sys    0m0.010s
+
+```
+
+10 times faster! So you might redefine `__git_index_files` as above in your .bashrc after sourcing the git autocomplete script. 
diff --git a/doc/tips/Faster_bash_autocompletion_with_big_annex_repos/comment_1_a41fb1037186319bbb44f7a67df6120f._comment b/doc/tips/Faster_bash_autocompletion_with_big_annex_repos/comment_1_a41fb1037186319bbb44f7a67df6120f._comment
new file mode 100644
index 0000000000..3a44fef020
--- /dev/null
+++ b/doc/tips/Faster_bash_autocompletion_with_big_annex_repos/comment_1_a41fb1037186319bbb44f7a67df6120f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-05-11T17:29:47Z"
+ content="""
+Could you send this improvement to the git mailing list?
+"""]]
diff --git a/doc/tips/Git_annex_and_Calibre.mdwn b/doc/tips/Git_annex_and_Calibre.mdwn
new file mode 100644
index 0000000000..c503e2d9c5
--- /dev/null
+++ b/doc/tips/Git_annex_and_Calibre.mdwn
@@ -0,0 +1,108 @@
+The problem
+===========
+
+[Calibre](http://calibre-ebook.com/) is a ebook manager that is
+available in [debian](http://packages.debian.org/sid/calibre). I use
+it to maintain my library, but also to dowload every day an epub
+version of a French newspaper and then put it on my kobo.
+
+Configuring git annex for this
+==============================
+
+I wanted to use git-annex, so
+
+    $ git init
+    $ git annex init "some useful name"
+
+But I don't want every thing in annex, because Calibre use some text
+file to save some metadata, so I used:
+
+    $ git config annex.largefiles "include=* exclude=*.opf exclude=*.json"
+
+then lets add everything
+
+    $ git annex add *
+    $ git add *
+    $ git commit -m "first commit"
+
+Calibre need read and write access on the its database, so let unlock it:
+
+    $ git annex unlock metadata.db
+
+On my other computer I only need to do
+
+    $ git clone $user@$host:Calibre\ library
+    $ cd Calibre\ library
+    $ git annex init "another useful name"
+    $ git annex get .
+    $ git annex unlock metadata.db
+
+The problem is that every time you will `git annex sync`, git annex
+will lock again the metadata.db, so lets unlock it automatically. I
+use git hooks, in `.git/hooks/post-commit` I have
+
+    #!/bin/bash
+
+    git annex edit metadata.db
+
+don't forget to make this file executable
+
+    $ chmod a+x .git/hooks/post-commit
+
+Day to day operation
+====================
+
+    $ git annex add .
+
+Will put new file into the annex
+
+    $ git add .
+
+Will take care of the files that should no go into annex
+
+    $ git annex sync
+
+Will make the repositories exchange informations about all this, and
+make remote change local
+
+    $ git annex get .
+
+Will make remote book locally available
+
+Merge conflict
+--------------
+You should not run calibre on the two computer simultaneously, or
+without syncing before it. If you do, you will have a conflict that
+git-annex will automatically *solve* by rename both of the file.
+
+You can then either:
+
+ - Choose one. If no books have been changed or added on one of the
+   computer, to use the other `metadata.db` will not make you loose
+   any information
+ - rebuild it. `calibredb restore_database` won't do it, but will tell
+   you how to do it.
+
+Checking the library
+--------------------
+You can use `calibredb check_library` to check you library is
+correct. If you use git for it, it will always tell you that it is not
+correct: there is this author ".git" it doesn't know about. Just don't
+care about it.
+
+Maybe this can be solved by using `vcsh` but apparently
+`vcsh`+`git annex` it not well tested yet.
+
+Automatic stuff
+---------------
+I use `mr` to automatically run all this, but some config could be
+done (I believe) to have `git annex copy --auto` do what it should.
+
+There are also the git annex assistant for this kind of automatic
+synchronizations of contents, but I don't know if my automatic
+unlocking of one file will break this.
+
+It might be interesting to find someway to unlock and lock the library
+only when running calibre, a simple script to launch calibre will do
+that. Note that each time you will lock and unlock, you will have a
+new commit in git.
diff --git a/doc/tips/Git_annex_and_Calibre/comment_1_b0ef346eaab9ff616aa1ba6b5f4530bc._comment b/doc/tips/Git_annex_and_Calibre/comment_1_b0ef346eaab9ff616aa1ba6b5f4530bc._comment
new file mode 100644
index 0000000000..7636b77022
--- /dev/null
+++ b/doc/tips/Git_annex_and_Calibre/comment_1_b0ef346eaab9ff616aa1ba6b5f4530bc._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="spurious changes in metadata.db"
+ date="2015-02-15T05:03:20Z"
+ content="""
+note that metadata.db seems to change even though no change was performed on the library. i filed a [bug report upstream](https://bugs.launchpad.net/calibre/+bug/1422058) to try and figure out what is going on here. -- [[anarcat]]
+"""]]
diff --git a/doc/tips/Git_annex_and_Calibre/comment_2_9e8122ea81bbd0a86bd6c5173db801f8._comment b/doc/tips/Git_annex_and_Calibre/comment_2_9e8122ea81bbd0a86bd6c5173db801f8._comment
new file mode 100644
index 0000000000..de485fb73b
--- /dev/null
+++ b/doc/tips/Git_annex_and_Calibre/comment_2_9e8122ea81bbd0a86bd6c5173db801f8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="undo to the rescue"
+ date="2015-02-15T05:52:58Z"
+ content="""
+note: to avoid having too many such changes, i end up using [[todo/direct_mode_undo]] quite often.
+"""]]
diff --git a/doc/tips/Git_annex_and_Calibre/comment_3_ee1372977919229d17d216cfc3fb0f61._comment b/doc/tips/Git_annex_and_Calibre/comment_3_ee1372977919229d17d216cfc3fb0f61._comment
new file mode 100644
index 0000000000..998280d29b
--- /dev/null
+++ b/doc/tips/Git_annex_and_Calibre/comment_3_ee1372977919229d17d216cfc3fb0f61._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Dilyin"
+ subject="comment 3"
+ date="2016-06-02T18:10:33Z"
+ content="""
+Actually you do want to exclude \"cover.jpg\" from being annexed because it will allow you to view the covers of all your books without getting them.
+Keeping metadata.opf out of annex is not that important because you cannot safely edit the metadata without getting the books first.
+
+It would be great to teach Calibre to see broken symlinks as normal zero length files and work with them accordingly.
+And we do need a Calibre plugin with buttons \"annex get\" and \"annex unlock\".
+"""]]
diff --git a/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo.mdwn b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo.mdwn
new file mode 100644
index 0000000000..97f5828d39
--- /dev/null
+++ b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo.mdwn
@@ -0,0 +1,19 @@
+I worked out how to retroactively annex a large file that had been checked into a git repo some time ago.  I thought this might be useful for others, so I am posting it here.
+
+Suppose you have a git repo where somebody had checked in a large file you would like to have annexed, but there are a bunch of commits after it and you don't want to loose history, but you also don't want everybody to have to retrieve the large file when they clone the repo.  This will re-write history as if the file had been annexed when it was originally added.
+
+This command works for me, it relies on the current behavior of git which is to use a directory named .git-rewrite/t/ at the top of the git tree for the extracted tree.  This will not be fast and it will rewrite history, so be sure that everybody who has a copy of your repo is OK with accepting the new history.  If the behavior of git changes, you can specify the directory to use with the -d option.  Currently, the t/ directory is created inside the directory you specify, so "-d ./.git-rewrite/" should be roughly equivalent to the default.
+
+Enough with the explanation, on to the command:
+<pre>
+git filter-branch --tree-filter 'for FILE in file1 file2 file3;do if [ -f "$FILE" ] && [ ! -L "$FILE" ];then git rm --cached "$FILE";git annex add "$FILE";ln -sf `readlink "$FILE"|sed -e "s:^../../::"` "$FILE";fi;done' --tag-name-filter cat -- --all
+</pre>
+
+replace file1 file2 file3... with whatever paths you want retroactively annexed.  If you wanted bigfile1.bin in the top dir and subdir1/bigfile2.bin to be retroactively annexed try:
+<pre>
+git filter-branch --tree-filter 'for FILE in bigfile1.bin subdir1/bigfile2.bin;do if [ -f "$FILE" ] && [ ! -L "$FILE" ];then git rm --cached "$FILE";git annex add "$FILE";ln -sf `readlink "$FILE"|sed -e "s:^../../::"` "$FILE";fi;done' --tag-name-filter cat -- --all
+</pre>
+
+**If your repo has tags** then you should take a look at the git-filter-branch man page about the --tag-name-filter option and decide what you want to do.  By default this will re-write the tags "nearly properly".
+
+You'll probably also want to look at the git-filter-branch man page's section titled "CHECKLIST FOR SHRINKING A REPOSITORY" if you want to free up the space in the existing repo that you just changed history on.
diff --git a/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_1_7eaf73fb3355bd706ab18a43790b3c10._comment b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_1_7eaf73fb3355bd706ab18a43790b3c10._comment
new file mode 100644
index 0000000000..d4e34e8cda
--- /dev/null
+++ b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_1_7eaf73fb3355bd706ab18a43790b3c10._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 1"
+ date="2012-12-16T00:11:38Z"
+ content="""
+Man, I wish you'd written this a couple weeks ago. :)  I was never able to figure that incantation out and ended up unannexing and re-annexing the whole thing to get rid of the file I inadvertently checked into git instead of the annex.
+"""]]
diff --git a/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_2_dac1a171204f30d7c906e878eb6bd461._comment b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_2_dac1a171204f30d7c906e878eb6bd461._comment
new file mode 100644
index 0000000000..a3ea62385e
--- /dev/null
+++ b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_2_dac1a171204f30d7c906e878eb6bd461._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~arand"
+ nickname="arand"
+ subject="comment 2"
+ date="2013-03-13T12:05:49Z"
+ content="""
+Based on the hints given here I've worked on a filter to both annex and add urls via filter-branch:
+
+[https://gitorious.org/arand-scripts/arand-scripts/blobs/master/annex-filter](https://gitorious.org/arand-scripts/arand-scripts/blobs/master/annex-filter)
+
+The script above is very specific but I think there are a few ideas that can be used in general, the general structure is
+
+    #!/bin/bash
+    
+    # links that already exist
+    links=$(mktemp)
+    find . -type l >\"$links\"
+    
+    # remove from staging area first to not block and then annex
+    git rm --cached --ignore-unmatch -r bin*
+    git annex add -c annex.alwayscommit=false bin*
+
+    # compare links before and after annexing, remove links that existed before
+    newlinks=$(mktemp -u)
+    mkfifo \"$newlinks\"
+    comm -13 <(sort \"$links\") <(find . -type l | sort) > \"$newlinks\" &
+    
+    # rewrite links
+    while IFS= read -r file
+    do
+        # link is created below .git-rewrite/t/ during filter-branch, strip two parents for correct target
+        ln -sf \"$(readlink \"$file\" | sed -e 's%^\.\./\.\./%%')\" \"$file\"
+    done < \"$newlinks\"
+
+    git annex merge
+
+which would be run using
+
+    git filter-branch --tree-filter path/annex-filter --tag-filter cat -- --all
+
+or similar.
+
+* I'm using `find` to make sure the only rewritten symlinks are for the newly annexed files, this way it is possible to annex an unknown set of filenames
+* If doing several git annex commands using `-c annex.alwayscommit=false` and doing a `git annex merge` at the end instead might be faster.
+"""]]
diff --git a/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_3_b62ec0b848d2487d68d7032682622193._comment b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_3_b62ec0b848d2487d68d7032682622193._comment
new file mode 100644
index 0000000000..9b8aa58f8e
--- /dev/null
+++ b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_3_b62ec0b848d2487d68d7032682622193._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="arand"
+ ip="130.238.245.202"
+ subject="comment 3"
+ date="2013-03-18T14:39:52Z"
+ content="""
+One thing I noticed is that git-annex needs to checksum each file even if they were previously annexed (rather obviously since there is no general way to tell if the file is the same as the old one without checksumming), but in the specific case that we are replacing files that are already in git, we do actually have the sha1 checksum for each file in question, which could be used.
+
+So, trying to work with this, I wrote a filter script that starts out annexing stuff in the first commit, and continously writes out sha1<->filename<->git-annex-object triplets to a global file, when it then starts with the next commit, it compares the sha1s of the index with those of the global file, and any matches are manually symlinked directly to the corresponding git-annex-object without checksumming.
+
+I've done a few tests and this seems to be considerably faster than letting git-annex checksum everything.
+
+This is from a git-svn import of the (free software) Red Eclipse game project, there are approximately 3500 files (images, maps, models, etc.) being annexed in each commit (and around 5300 commits, hence why I really, really care about speed):
+
+10 commits: ~7min
+
+100 commits: ~38min
+
+For comparison, the old and new method (the difference should increase with the amount of commits):
+
+old, 20 commits ~32min
+
+new, 20 commits: ~11min
+
+The script itself is a bit of a monstrosity in bash(/grep/sed/awk/git), and the files that are annexed are hardcoded (removed in forming $oldindexfiles), but should be fairly easy to adapt:
+
+[https://gitorious.org/arand-scripts/arand-scripts/blobs/master/annex-ffilter](https://gitorious.org/arand-scripts/arand-scripts/blobs/master/annex-ffilter)
+
+The usage would be something like:
+
+    rm /tmp/annex-ffilter.log; git filter-branch --tree-filter 'ANNEX_FFILTER_LOG=/tmp/annex-ffilter.log ~/utv/scripts/annex-ffilter' --tag-name-filter cat -- branchname
+
+I suggest you use it with at least two orders of magnitude more caution than normal filter-branch.
+
+Hope it might be useful for someone else wrestling with filter-branch and git-annex :)
+"""]]
diff --git a/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_4_2423904e41a86cd1c6bc155d7b733642._comment b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_4_2423904e41a86cd1c6bc155d7b733642._comment
new file mode 100644
index 0000000000..ab1d4e0064
--- /dev/null
+++ b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_4_2423904e41a86cd1c6bc155d7b733642._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawknOATcOkmzX4jKuET5Z2RsaFUNnLKnQsU"
+ nickname="Stephen"
+ subject="comment 4"
+ date="2013-06-22T07:43:09Z"
+ content="""
+Thanks for the tip :) One question though: how do I push this new history out throughout my other Annexes?
+All I managed to make it do was revert the rewrite so the raw file appeared again...
+"""]]
diff --git a/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_5_3062c0794ecd7c6237efae66f4d9b62f._comment b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_5_3062c0794ecd7c6237efae66f4d9b62f._comment
new file mode 100644
index 0000000000..e8ef98d999
--- /dev/null
+++ b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_5_3062c0794ecd7c6237efae66f4d9b62f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlcfH7xkyz1kyG_neK4GcFFfFWuIY7l_6A"
+ nickname="Primiano"
+ subject="large scale rewrite tips"
+ date="2015-01-06T22:55:20Z"
+ content="""
+I recently had the need of re-kind-of-annexing an unusually large repo (one of the largest?).
+With some tricks and the right code I managed to get it down to 170000 commits in 19 minutes and extracing ~8GB of blobs. 
+Attaching the link here as I feel it might be helpful for very large projects (where git-filter-branch can become prohibitively slow) 
+
+[https://www.primianotucci.com/blog/large-scale-git-history-rewrites](https://www.primianotucci.com/blog/large-scale-git-history-rewrites)
+
+"""]]
diff --git a/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_6_1eceb980814f95b28caac9d4d9894f01._comment b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_6_1eceb980814f95b28caac9d4d9894f01._comment
new file mode 100644
index 0000000000..17592b2870
--- /dev/null
+++ b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_6_1eceb980814f95b28caac9d4d9894f01._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Dilyin"
+ subject="Retroactively annex"
+ date="2016-06-01T18:36:40Z"
+ content="""
+Hmm, guyz? Are you serious with these scripts?
+
+1. git rm -r --cached large_files
+# files are indexed as both removed and untracked and are still in place
+2. commit the changes
+# files are seen as untracked
+3. git annex add large_files
+# files are replaced with symlinks and are in the index
+4. commit changes again
+
+Make sure that you don't have annex.largefiles settings that would prevent annexing the files.
+"""]]
diff --git a/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_7_603db6818d33663b70b917c04fd8485b._comment b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_7_603db6818d33663b70b917c04fd8485b._comment
new file mode 100644
index 0000000000..5527c2b430
--- /dev/null
+++ b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_7_603db6818d33663b70b917c04fd8485b._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="&quot;Hmm, guyz? Are you serious with these scripts?&quot; Well, what's the matter?"
+ date="2016-11-15T10:58:32Z"
+ content="""
+## Wow, scary
+
+Dilyin's comment is scary.  It suggests bad things can happen, but is not very clear.
+
+Bloated history is one thing.  
+Obviously broken repo is bad but can be (slowly) recovered from remotes.  
+Subtly crippled history that you don't notice can be a major problem (especially once you have propagated it to all your remotes to \"recover from bloat\").
+
+## More common than it seems
+
+There's a case probably more common than people actually report: mistakenly doing `git add` instead of `git annex add` and realizing it only after a number of commits. Doing `git annex add` at that time will have the file duplicated (regular git and annex). 
+
+Extra wish: when doing `git annex add` of a file that is already present in git history, `git-annex` could notice and tell.
+
+## Simple solution?
+
+Can anyone elaborate on the scripts provided here, are they safe?  What can happen if improperly used or in corner cases?
+
+* \"files are replaced with symlinks and are in the index\" -> so what ?
+* \"Make sure that you don't have annex.largefiles settings that would prevent annexing the files.\" -> What would happen? Also `.gitattributes`.
+
+Thank you.
+"""]]
diff --git a/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_8_834410421ccede5194bd8fbaccea8d1a._comment b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_8_834410421ccede5194bd8fbaccea8d1a._comment
new file mode 100644
index 0000000000..2c36962aa5
--- /dev/null
+++ b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_8_834410421ccede5194bd8fbaccea8d1a._comment
@@ -0,0 +1,82 @@
+[[!comment format=mdwn
+ username="StephaneGourichon"
+ avatar="http://cdn.libravatar.org/avatar/8cea01af2c7a8bf529d0a3d918ed4abf"
+ subject="Walkthrough of a prudent retroactive annex."
+ date="2016-11-24T11:27:59Z"
+ content="""
+Been using the one-liner.  Despite the warning, I'm not dead yet.
+
+There's much more to do than the one-liner.
+
+This post offers instructions.
+
+# First simple try: slow
+
+Was slow (estimated >600s for 189 commits).
+
+# In tmpfs: about 6 times faster
+
+I have cloned repository into /run/user/1000/rewrite-git, which is a tmpfs mount point. (Machine has plenty of RAM.)
+
+There I also did `git annex init`, git-annex found its state branches.
+
+On second try I also did 
+
+    git checkout -t remotes/origin/synced/master
+
+So that filter-branch would clean that, too.
+
+There, `filter-branch` operation finished in 90s first try, 149s second try.
+
+`.git/objects` wasn't smaller.
+
+# Practicing reduction on clone
+
+This produced no visible benefit:
+
+time git gc --aggressive
+time git repack -a -d 
+
+Even cloning and retrying on clone. Oh, but I should have done `git clone file:///path` as said on git-filter-branch man page's section titled \"CHECKLIST FOR SHRINKING A REPOSITORY\" 
+
+This (as seen on https://rtyley.github.io/bfg-repo-cleaner/ ) was efficient:
+
+    git reflog expire --expire=now --all && git gc --prune=now --aggressive
+
+`.git/objects` shrunk from 148M to 58M
+
+All this was on a clone of the repo in tmpfs.
+
+# Propagating cleaned up branches to origin
+
+This confirmed that filter-branch did not change last tree:
+
+    git diff remotes/origin/master..master
+    git diff remotes/origin/synced/master synced/master
+
+This, expectedly, was refused:
+
+    git push origin master
+    git push origin synced/master
+
+On origin, I checked out the hash of current master, then on tmpfs clone
+
+    git push -f origin master
+    git push -f origin synced/master
+
+Looks good.
+
+I'm not doing the aggressive shrink now, because of the \"two orders of magnitude more caution than normal filter-branch\" recommended by arand.
+
+# Now what? Check if precious not broken
+
+I'm planning to do the same operation on the other repos, then :
+
+* if everything seems right, 
+* if `git annex sync` works between all those fellows
+* etc, 
+* then I would perform the reflog expire, gc prune on some then all of them, etc.
+
+Joey, does this seem okay?  Any comment?
+
+"""]]
diff --git a/doc/tips/Internet_Archive_via_S3.mdwn b/doc/tips/Internet_Archive_via_S3.mdwn
new file mode 100644
index 0000000000..9bceeb3482
--- /dev/null
+++ b/doc/tips/Internet_Archive_via_S3.mdwn
@@ -0,0 +1,80 @@
+[The Internet Archive](http://www.archive.org/) allows members to upload
+collections using an Amazon S3 
+[compatible API](http://www.archive.org/help/abouts3.txt), and this can
+be used with git-annex's [[special_remotes/S3]] support. 
+
+So, you can locally archive things with git-annex, define remotes that
+correspond to "items" at the Internet Archive, and use git-annex to upload
+your files to there. Of course, your use of the Internet Archive must
+comply with their [terms of service](http://www.archive.org/about/terms.php).
+
+A nice added feature is that whenever git-annex sends a file to the
+Internet Archive, it records its url, the same as if you'd run `git annex
+addurl`. So any users who can clone your repository can download the files
+from archive.org, without needing any login or password info. 
+The url to the content in the Internet Archive is also displayed by
+`git annex whereis`. This makes the Internet Archive a nice way to
+publish the large files associated with a public git repository.
+
+## webapp setup
+
+Just go to "Add Another Repository", pick "Internet Archive",
+and you're on your way.
+
+## basic setup
+
+Sign up for an account, and get your access keys here:
+<http://www.archive.org/account/s3.php>
+	
+	# export AWS_ACCESS_KEY_ID=blahblah
+	# export AWS_SECRET_ACCESS_KEY=xxxxxxx
+
+Specify `host=s3.us.archive.org` when doing `initremote` to set up
+a remote at the Archive. This will enable a special Internet Archive mode:
+Encryption is not allowed; you are required to specify a bucket name
+rather than having git-annex pick a random one; and you can optionally
+specify `x-archive-meta*` headers to add metadata as explained in their
+[documentation](http://www.archive.org/help/abouts3.txt).
+
+	# git annex initremote archive-panama type=S3 \
+		host=s3.us.archive.org bucket=panama-canal-lock-blueprints \
+		x-archive-meta-mediatype=texts x-archive-meta-language=eng \
+                x-archive-meta-collection=test_collection \
+		x-archive-meta-title="original Panama Canal lock design blueprints"
+	initremote archive-panama (Internet Archive mode) ok
+	# git annex describe archive-panama "a man, a plan, a canal: panama"
+	describe archive-panama ok
+
+The above uploads to the [test collection](https://archive.org/details/test_collection) where items are removed
+after thirty days. Uploads can persist by changing to another writable
+[collection](https://internetarchive.readthedocs.io/en/latest/metadata.html#collection).
+
+Then you can annex files and copy them to the remote as usual:
+
+	# git annex add photo1.jpeg --backend=SHA256E
+	add photo1.jpeg (checksum...) ok
+	# git annex copy photo1.jpeg --fast --to archive-panama
+	copy (to archive-panama...) ok
+
+## update lag
+
+It may take a while for archive.org to make files publically visible after
+they've been uploaded.
+
+While files can be removed from the Internet Archive, 
+[derived versions](https://archive.org/help/derivatives.php)
+of some files may continued to be stored there for a while
+after the originals were removed.
+
+## exporting trees
+
+By default, files stored in the Internet Archive will show up there named
+by their git-annex key, not the original filename. If the filenames
+are important, you can run `git annex initremote` with an additional
+parameter "exporttree=yes", and then use [[git-annex-export]] to publish
+a tree of files to the Internet Archive.
+
+Note that the Internet Archive may not support certian characters
+in filenames ([see FAQ](http://archive.org/about/faqs.php#1099)).
+If exporting a filename fails due to such limitations, you would need
+to rename it in your git annex repository in order to export it.
diff --git a/doc/tips/Internet_Archive_via_S3/comment_1_d53a3848c20dce61867283fc03c2adaa._comment b/doc/tips/Internet_Archive_via_S3/comment_1_d53a3848c20dce61867283fc03c2adaa._comment
new file mode 100644
index 0000000000..7c2ce48fcf
--- /dev/null
+++ b/doc/tips/Internet_Archive_via_S3/comment_1_d53a3848c20dce61867283fc03c2adaa._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="how to use with simply addurl?"
+ date="2013-10-09T22:27:27Z"
+ content="""
+It doesn't seem like git annex addurl by itself supports the archive.org urls...
+
+[[!format txt \"\"\"
+anarcat@marcos:presentations$ git annex addurl --file=re_publica_2012___Eben_Moglen___Freedom_of_Thought_Requires_Free_Media.webm http://archive.org/download/Republica2012-EbenMoglen-FreedomOfThoughtRequiresFreeMedia/re_publica_2012___Eben_Moglen___Freedom_of_Thought_Requires_Free_Media.webm
+addurl re_publica_2012___Eben_Moglen___Freedom_of_Thought_Requires_Free_Media.webm
+  failed to verify url exists: http://archive.org/download/Republica2012-EbenMoglen-FreedomOfThoughtRequiresFreeMedia/re_publica_2012___Eben_Moglen___Freedom_of_Thought_Requires_Free_Media.webm
+failed
+git-annex: addurl: 1 failed
+\"\"\"]]
+
+I also tried the \"details\" url (<http://archive.org/details/Republica2012-EbenMoglen-FreedomOfThoughtRequiresFreeMedia>) - but that just downloads the webpage, not the video either...
+
+Even the ultimate video URL doesn't work:
+
+[[!format txt \"\"\"
+anarcat@marcos:presentations$ git annex addurl --debug --file=re_publica_2012___Eben_Moglen___Freedom_of_Thought_Requires_Free_Media.webm http://ia601009.us.archive.org/9/items/Republica2012-EbenMoglen-FreedomOfThoughtRequiresFreeMedia/re_publica_2012___Eben_Moglen___Freedom_of_Thought_Requires_Free_Media.webm
+[2013-10-09 18:26:30 EDT] call: quvi [\"-v\",\"mute\",\"--support\",\"http://ia601009.us.archive.org/9/items/Republica2012-EbenMoglen-FreedomOfThoughtRequiresFreeMedia/re_publica_2012___Eben_Moglen___Freedom_of_Thought_Requires_Free_Media.webm\"]
+addurl re_publica_2012___Eben_Moglen___Freedom_of_Thought_Requires_Free_Media.webm [2013-10-09 18:26:30 EDT] read: curl [\"-s\",\"--head\",\"-L\",\"http://ia601009.us.archive.org/9/items/Republica2012-EbenMoglen-FreedomOfThoughtRequiresFreeMedia/re_publica_2012___Eben_Moglen___Freedom_of_Thought_Requires_Free_Media.webm\",\"-w\",\"%{http_code}\"]
+
+  failed to verify url exists: http://ia601009.us.archive.org/9/items/Republica2012-EbenMoglen-FreedomOfThoughtRequiresFreeMedia/re_publica_2012___Eben_Moglen___Freedom_of_Thought_Requires_Free_Media.webm
+failed
+git-annex: addurl: 1 failed
+\"\"\"]]
+
+... even though that URL actually gives out a proper 200 OK response code.
+
+Any ideas? --[[anarcat]]
+"""]]
diff --git a/doc/tips/Internet_Archive_via_S3/comment_2_91c1472da27b00e5d682d22bc1ef04e0._comment b/doc/tips/Internet_Archive_via_S3/comment_2_91c1472da27b00e5d682d22bc1ef04e0._comment
new file mode 100644
index 0000000000..9b4ac58b23
--- /dev/null
+++ b/doc/tips/Internet_Archive_via_S3/comment_2_91c1472da27b00e5d682d22bc1ef04e0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.22"
+ subject="comment 2"
+ date="2013-10-11T17:08:27Z"
+ content="""
+This was a misleading error message. The url you are trying to add to the file does not match the size recorded for the file already in the annex. (Or possibly the file's key has no recorded size). If you really want to add the url to the file despite it being a different encoding, you can use --relaxed, although fsck may not like the result if you ever end up downloading that url..
+
+(Please file bug reports for problems in the future, rather than posting comments on only vaguely related pages which as we can see here can turn out to be entirely offtopic.)
+"""]]
diff --git a/doc/tips/Internet_Archive_via_S3/comment_3_e23cf781c532f80d47d52265f2b2c87e._comment b/doc/tips/Internet_Archive_via_S3/comment_3_e23cf781c532f80d47d52265f2b2c87e._comment
new file mode 100644
index 0000000000..3745d544ce
--- /dev/null
+++ b/doc/tips/Internet_Archive_via_S3/comment_3_e23cf781c532f80d47d52265f2b2c87e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="still a bug, filed separately!"
+ date="2013-10-11T18:49:06Z"
+ content="""
+Aaah, of course, sorry for the noise here. It turns out that this is *not* because the filesize (or even the checksum, for that matter) are different, so there's clearly a bug there, and i filed it in [[bugs/addurl_fails_on_the_internet_archive]]. Thanks!
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files.mdwn b/doc/tips/Repositories_with_large_number_of_files.mdwn
new file mode 100644
index 0000000000..347f6f94aa
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files.mdwn
@@ -0,0 +1,55 @@
+Just as git does not scale well with large files, it can also become painful to work with when you have a large *number* of files. Below are things I have found to minimise the pain.
+
+[[!toc]]
+
+# Using version 4 index files
+
+During operations which affect the index, git writes an entirely new index out to index.lck and then replaces .git/index with it. With a large number of files, this index file can be quite large and take several seconds to write every time you manipulate the index!
+
+This can be mitigated by changing it to version 4 which uses path compression to reduce the filesize:
+
+    git update-index --index-version 4
+
+*NOTE: The git documentation warns that this version may not be supported by other git implementations like JGit and libgit2.*
+
+Personally, I saw a reduction from 516MB to 206MB (*40% of original size*) and got a much more responsive git!
+
+It may also be worth doing the same to git-annex's index:
+
+    GIT_INDEX_FILE=.git/annex/index git update-index --index-version 4
+
+Though I didn't gain as much here with 89MB to 86MB (96% of original size).
+
+# Packing
+
+As I have gc disabled:
+
+    git config gc.auto 0
+
+so I control when it is run, I ended up with a lot of loose objects which also cause slowness in git. Using
+
+    git count-objects
+
+to tell me how many loose objects I have, when I reach a threshold (~25000), I pack those loose objects and clean things up:
+
+    git repack -d
+    git gc
+    git prune
+
+# File count per directory
+
+If it takes a long time to list the files in a directory, naturally, git(-annex) will be affected by this bottleneck.
+
+You can avoid this by keeping the number of files in a directory to between 5000 and 20000 (depends on the filesystem and its settings).
+
+[fpart](https://sourceforge.net/projects/fpart/) can be a very useful tool to achieve this.
+
+This sort of usage was discussed in [[forum/Handling_a_large_number_of_files]] and [[forum/__34__git_annex_sync__34___synced_after_8_hours]]. -- [[CandyAngel]]
+
+# Forget tracking information
+
+In addition to keeping track of where files are, git-annex keeps a *log* that keeps track of where files *were*. This can take up space as well and slow down certain operations.
+
+You can use the [[git-annex-forget]] command to drop historical location tracking info for files.
+
+Note: this was discussed in [[forum/scalability_with_lots_of_files]]. -- [[anarcat]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_10_3fac08b817ca3dbfcac3a03ce521464e._comment b/doc/tips/Repositories_with_large_number_of_files/comment_10_3fac08b817ca3dbfcac3a03ce521464e._comment
new file mode 100644
index 0000000000..249af5ad38
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_10_3fac08b817ca3dbfcac3a03ce521464e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 10"
+ date="2021-11-04T16:04:06Z"
+ content="""
+@pat: Sorry, I don't have such performance information for git-annex as I stopped using it ~2 years ago.
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_11_49585db4fbf9f22bf806ee08d73b7db1._comment b/doc/tips/Repositories_with_large_number_of_files/comment_11_49585db4fbf9f22bf806ee08d73b7db1._comment
new file mode 100644
index 0000000000..a6f7af3695
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_11_49585db4fbf9f22bf806ee08d73b7db1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 11"
+ date="2022-09-04T22:31:14Z"
+ content="""
+I'm trying to use a repo consisting of about 150,000 photos/videos.  I tried all the tipes here as well as the ones at [[/forum /__34__git_annex_sync__34___synced_after_8_hours]] and the time is still quite poor.  I don't know if using the special remote directory with importtree=yes hurts; I don't think it should.  The problem seems to be largely CPU-bound and RAM-bound; syncs can use many GB of RAM and a large amount of CPU time (even when there is no evident hashing of source files).  --jobs=10 hasn't caused much evident parallelization.  Changing the git index type, repacking, etc. rocketed through almost instantly and made no evident change.  I'd be very interested in ideas here, because at this rate, a sync that is a no-op has been running for 15 minutes just sitting there after \"list source ok\".  I'll let it run and see what it does.
+
+If it makes a difference, this is an unlocked repo (via git annex adjust --unlocked), not running assistant.  There are no directories with excessive numbers of photos.  The underlying filesystem is ZFS.
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_12_e1f3b19d1dd62b1c9314e1e826fec54f._comment b/doc/tips/Repositories_with_large_number_of_files/comment_12_e1f3b19d1dd62b1c9314e1e826fec54f._comment
new file mode 100644
index 0000000000..8a85021b7f
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_12_e1f3b19d1dd62b1c9314e1e826fec54f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 12"
+ date="2022-09-05T01:01:59Z"
+ content="""
+To expand: this took about 2 hours to run.  A git annex sync from another git annex repo is a lot faster (a minute or so).  It is the directory remote that's so slow.  Examining with strace and lsof, I don't believe this is chechsumming.  In fact, it seems to be mostly continuous reading from cidsdb/db, which is only 49MB in size and therefore certainly cached.  The process is entirely CPU-bound.
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_13_6b4cd0667d700c0c5ec6e0054b43f2e7._comment b/doc/tips/Repositories_with_large_number_of_files/comment_13_6b4cd0667d700c0c5ec6e0054b43f2e7._comment
new file mode 100644
index 0000000000..ddbc49020f
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_13_6b4cd0667d700c0c5ec6e0054b43f2e7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 13"
+ date="2022-09-05T09:07:05Z"
+ content="""
+You may try the following: Set the preferred-content expression for the repo to just `present` or `anything` and then run `git annex sync --content --all`. This allows git-annex to use a optimization and should run faster. Don't use `--jobs` and unset `annex.jobs` git config, since these slow the optimization down a bit in my experience (note that just specifying `--jobs=1` is not the same AFAIK).
+
+See also [[todo/Incremental\_git\_annex\_sync\_--content\_--all]]
+
+Using unlocked files will slow down things in general, but from your description it doesn't sound like that's the issue here.
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_14_f8af84e301d271e9822556f23395dde7._comment b/doc/tips/Repositories_with_large_number_of_files/comment_14_f8af84e301d271e9822556f23395dde7._comment
new file mode 100644
index 0000000000..2314f12524
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_14_f8af84e301d271e9822556f23395dde7._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2022-09-05T18:09:59Z"
+ content="""
+Importing a large tree from a special remote does have a price. git-annex
+has to list the files, check to see if these are files it
+has imported before (that is the cid lookup), and also has to feed 
+the files and sha1s to git to build a tree object. Only once it's built
+the tree object can it see that no files have changed and it has nothing
+to do.
+
+That is always going to be slower than making a git repository in the
+directory and running git-annex add there. Because in that case, git can
+use the index to quickly tell what files are modified or new, and skip the
+unchanged files.
+
+Bear in mind that the directory special remote is not the only special
+remote that supports importing, and so the import interface has to be
+general enough to support others. So it can't use the filesystem level
+tricks that git is able to use with its index.
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_15_71def7a311980e89a3b877175ea5bbe2._comment b/doc/tips/Repositories_with_large_number_of_files/comment_15_71def7a311980e89a3b877175ea5bbe2._comment
new file mode 100644
index 0000000000..48b361f582
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_15_71def7a311980e89a3b877175ea5bbe2._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 15"
+ date="2022-09-05T23:57:01Z"
+ content="""
+Hi Joey,
+
+Thanks for this!  I may be missing some important detail here...
+
+So what I'm seeing is that it says \"list source\" and then stats every file in the importdir location.  That makes sense, and goes through in a minute or two.
+
+Then it sits at 100% CPU for an hour or two, reading a lot from the cidsdb, but not opening, stating, or reading from any other file.
+
+Maybe it checksummed something while I wasn't watching, but generally while I'm watching at least, I don't see it actually checksumming every file on every call to import.
+
+So is it building the tree object that's slow here?  And, since it doesn't store mtime, how does it detect changes?
+
+Thanks again for your patience with all these questions as I dive back into git-annex!
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_1_fac49a6d3f6a18c9925c34521221307d._comment b/doc/tips/Repositories_with_large_number_of_files/comment_1_fac49a6d3f6a18c9925c34521221307d._comment
new file mode 100644
index 0000000000..42550a0645
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_1_fac49a6d3f6a18c9925c34521221307d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="ghen1"
+ subject="comment 1"
+ date="2015-07-08T04:08:28Z"
+ content="""
+This is some excellent information. Thank you.
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_2_f8417d9ebcfdcba34dfbbf76070ad95c._comment b/doc/tips/Repositories_with_large_number_of_files/comment_2_f8417d9ebcfdcba34dfbbf76070ad95c._comment
new file mode 100644
index 0000000000..86bb069b5b
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_2_f8417d9ebcfdcba34dfbbf76070ad95c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-09-22T16:51:51Z"
+ content="""
+As writing the index file becomes the bottleneck, turning on split index
+mode might be a help as well. See git-update-index's man page.
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_3_992f2a85ce0cdcef2f97ff978560fdb8._comment b/doc/tips/Repositories_with_large_number_of_files/comment_3_992f2a85ce0cdcef2f97ff978560fdb8._comment
new file mode 100644
index 0000000000..514c829fef
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_3_992f2a85ce0cdcef2f97ff978560fdb8._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="umeboshi"
+ subject="comment 3"
+ date="2016-01-04T21:26:05Z"
+ content="""
+I have been playing with tracking a large number of url's for about one month now.  Having already been disappointed by how git performs when there are a very large amount of files in the annex, I tested making multiple annexes.  I did find that splitting the url's into multiple annexes increased performance, but at the cost of extra housekeeping, duplicated url's, and more work needed to keep track of the url's.  Part of the duplication and tracking problem was mitigated by using a dumb remote, such as rsync or directory, where a very large amount of objects can be stored.  The dumb remotes perform very well, however each annex needed to be synced regularly with the dumb remote.
+
+I found the dumb remote to be great for multiple annexes.  I have noticed that a person can create a new annex and extract a tarball of symlinks into the repo, the ```git commit``` the links.  Subsequently, executing ```git-annex fsck --from dummy``` would setup the tracking info, which was pretty useful.
+
+However, I found that by the time I got to over fifty annexes, the overall performance far worse than just storing the url's and file paths in a postgresql database.  In fact, the url's are already being stored and accessed from such a database, but I had the desire to access the url's from multiple machines, which is a bit more difficult with a centralized database.
+
+After reading the tips and pages discussing splitting the files into multiple directories, and changing the index version, I decided to try a single annex to hold the url's.  Over the new year's weekend, I decided to write a script that generates rss files to use with importfeed to add url's to this annex.  I have noticed that when using ```git commit``` the load average of the host was in the mid twenties and persisted for hours until I had to kill the processes to be able to use the machine again (**I would really like to know if there is a git config setting that would keep the load down, so the machine can be used during a commit**).  I gave up on ```git-annex sync``` this morning, since it was taking longer than I was able to sit in the coffee shop and wait for it (~3 hrs).
+
+I came back to the office, and started ```git gc``` which has been running for ~1hr.
+
+When making the larger annex, I decided to use the hexidecimal value of uuid5(url) for each filename, and use the two high nybbles and the two low nybbles for a two state directory structure, with respect for the advice from [CandyAngel](http://git-annex.branchable.com/forum/Handling_a_large_number_of_files/#comment-48ac38361b131b18125f8c43eb6ad577).  When my url's are organized in this manner, I still need access to the database to perform the appropriate ```git-annex get``` which impairs the use of this strategy, but I'm still testing and playing around.  I suspended adding url's to this annex until I get at least one sync performed.
+
+The url annex itself is not very big, and I am guessing the average file size to be close to 500K.  The large number of url's seems to be a problem I have yet to solve.  I wanted to experiment with this to further the idea of the public git-annex repositories that seem to be a useful idea, even though the utility of this idea is very limited at the moment.
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_4_8ff3aa032fb778ff69276984152578b0._comment b/doc/tips/Repositories_with_large_number_of_files/comment_4_8ff3aa032fb778ff69276984152578b0._comment
new file mode 100644
index 0000000000..78b79ef081
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_4_8ff3aa032fb778ff69276984152578b0._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 4"
+ date="2016-01-05T11:41:13Z"
+ content="""
+@umeboshi: Odd that you report your machine freezes during commits.. I find the exact opposite.. waiting for a long time with no load at all.
+
+My current setup for my sorting annex (where I import all the files off old HDDs) is to have the HDD plugged into my home server (Atom 330 @ 1.6Ghz) and import the files on a cloned (empty) annex. Doing so for 1.1M files (latest HDD) is a long wait, because 80% of the time is waiting for something to happen (but there being no load on the machine). Once that is done, the HDD is transferred to my desktop, where the annex is \"joined\" to the others and files are sorted in a dedicated VM[1], where commit times are reasonable.
+
+[1] Fully virtualising my desktop is possibly the best thing I've ever done, in terms of setup. Locking up any VM affects none of the others (which is handy, as I discovered an issue that causes X to almost hardlock whenever libvo is used..).
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_5_8540bf807eaf1b4e927eafc03deef304._comment b/doc/tips/Repositories_with_large_number_of_files/comment_5_8540bf807eaf1b4e927eafc03deef304._comment
new file mode 100644
index 0000000000..2d1e238662
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_5_8540bf807eaf1b4e927eafc03deef304._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 5"
+ date="2016-02-02T10:08:06Z"
+ content="""
+Splitting the index (git update-index --split-index) doesn't work for me at all. While it may initially reduce the size of .git/index, making a commit inflates it back to its original size anyway.
+
+I thought it might be some interaction with v4 index and its compression mechanics but it does the same if I set it to v3 index. For (manufactured) example:
+
+    $ git update-index --split-index
+    $ du -sh .git/*index*
+    4.0K    .git/index
+    76M     .git/sharedindex.70e661456302b51a7ec59bf5b32d630e74b34c7c
+
+    ... add 8000 files ...
+
+    $ git commit -m \"add files\"
+    $ du -sh .git/*index*
+    80M     .git/index
+    76M     .git/sharedindex.70e661456302b51a7ec59bf5b32d630e74b34c7c
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_6_9169a33c06cf8aea231cdd8f51ce17b6._comment b/doc/tips/Repositories_with_large_number_of_files/comment_6_9169a33c06cf8aea231cdd8f51ce17b6._comment
new file mode 100644
index 0000000000..1fb1de999a
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_6_9169a33c06cf8aea231cdd8f51ce17b6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="merge with scalability?"
+ date="2017-04-24T14:10:29Z"
+ content="""
+shouldn't this tip be merged into the [[scalability]] page directly?
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_7_f56f1ffeb5e1f382d3227b4ace7f84a1._comment b/doc/tips/Repositories_with_large_number_of_files/comment_7_f56f1ffeb5e1f382d3227b4ace7f84a1._comment
new file mode 100644
index 0000000000..56a7373957
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_7_f56f1ffeb5e1f382d3227b4ace7f84a1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="breck7@4bbace32c18ebb98fc730d56c6ed76b7bcc0798e"
+ nickname="breck7"
+ avatar="http://cdn.libravatar.org/avatar/96a1ef57fee8349bd6f92faf153f9ec3"
+ subject="Thank you"
+ date="2020-01-30T15:15:24Z"
+ content="""
+I just ran into related git scaling issues while trying to make a repo in a folder with 6.5 million files. [Writeup](https://breckyunits.com/building-a-treebase-with-6-point-5-million-files.html). I did things the naive/wrong way on purpose, but now I'm curious if I could actually get this work fast, and your pointers are a good help. Thanks!
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_8_25a26f5210986655808992533aa48d3d._comment b/doc/tips/Repositories_with_large_number_of_files/comment_8_25a26f5210986655808992533aa48d3d._comment
new file mode 100644
index 0000000000..ce124ab71b
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_8_25a26f5210986655808992533aa48d3d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 8"
+ date="2021-05-05T19:39:11Z"
+ content="""
+Do you have any information on actual times for working with big repos?
+
+As an example, I created one with 400k files. After following the steps here, `git status` takes 8 seconds to complete. I have plenty of resources. So, it's just slow. I am curious what sort of times you're getting with your big repos.
+
+I will have to see if submodules help with this at all. This material is all reference information, and isn't going to be changed very much. So it's possible I'd be better off with an \"active\" repo, and a \"reference\" repo (maybe connected by submodule, maybe not).
+
+Joey did make the suggestion of storing those sorts of files in a separate branch. I just did a test, and it appears that the limiting factor is in fact the number of files in the working tree. Deleting a lot of the files brought git back up to speed. So from a simplicity standpoint, I may want to have a `reference` branch with those files in it. And perhaps have two local clones of the repo - one `main` and one `reference` so I can explore and copy files from `reference` to `main` as needed.
+"""]]
diff --git a/doc/tips/Repositories_with_large_number_of_files/comment_9_c2b44076201d8152f16e12cb23c50397._comment b/doc/tips/Repositories_with_large_number_of_files/comment_9_c2b44076201d8152f16e12cb23c50397._comment
new file mode 100644
index 0000000000..364832cc1e
--- /dev/null
+++ b/doc/tips/Repositories_with_large_number_of_files/comment_9_c2b44076201d8152f16e12cb23c50397._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 9"
+ date="2021-05-05T22:51:28Z"
+ content="""
+Separate branch is a no-go. `git annex info` takes 3 minutes 30 seconds to report 320k annex keys.
+
+So for my purposes I think I will keep one slow reference repo, and one fast working repo.
+"""]]
diff --git a/doc/tips/Shamir_secret_sharing_and_git-annex.mdwn b/doc/tips/Shamir_secret_sharing_and_git-annex.mdwn
new file mode 100644
index 0000000000..df19f68b8e
--- /dev/null
+++ b/doc/tips/Shamir_secret_sharing_and_git-annex.mdwn
@@ -0,0 +1,21 @@
+Combining git-annex with [Shamir secret sharing](http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing)
+is an useful way to securely back up highly sensitive files,
+such as a gpg key or bitcoin wallet.
+
+Shamir secret sharing creates N shares of a file, of which any M can be
+used to reconstitute the original file. Anyone who has less than M shares
+cannot tell anything about the original file, other than its size.
+
+Where git-annex comes in is as a way to manage these shares. They can be
+added to the annex, and then git-annex used to move one share to each clone
+of the repository. Since git-annex keeps track of where each file is
+stored, this can aid later finding the shares again when they're needed, as
+well as making ongoing management of the shares easier.
+
+Note that this conveniece comes at a price: Any attacker who gets a copy
+of the git repository can use it to figure out where the shares are
+located. While this is not a crippling flaw, and can be worked around, it
+needs to be considered when implementing this technique.
+
+Here is an example of this method being used for a ~/.gnupg directory:
+<http://git.kitenet.net/?p=gpg.git;a=blob;f=README.sss>
diff --git a/doc/tips/Synology_NAS_and_git_annex.mdwn b/doc/tips/Synology_NAS_and_git_annex.mdwn
new file mode 100644
index 0000000000..8a6d282c92
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex.mdwn
@@ -0,0 +1,59 @@
+# How to use git-annex on a Synology NAS
+
+This is known to work with DSM 4.3-3810 Update 1 and git-annex standalone version 5.20131224-g6ca5271.
+
+## Installation Steps
+
+(1) In the DSM Package Center, install Git, which is available from Synology (no third-party repository needed).
+
+(2) Download the latest [[standalone|install/Linux_standalone]] git-annex build for Linux on armel.
+
+(3) Extract it somewhere sensible (eg: a bin/ directory your users home directory)
+
+(4) Go into the git-annex.linux directory and ./runshell. You can now run git-annex as you normally would.
+
+## How to sync with the Synology NAS
+
+### On the Synology
+(1) Setup port forwarding and associated dynamic dns, if applicable. Many good guides online for this.
+
+(2) Setup ssh key based authentication with the Synology for each computer you want to sync with it. You want a specific key that is used only by git-annex, for each computer. Again, many good guides online.
+
+(3) In the Synology .ssh/authorized_keys file for your account, add (substituting your username)
+[[!format sh """
+command="/home/$yourusername/.ssh/git-annex-shell"
+"""]]
+to the beginning of the line. Eg, it would look like this:
+[[!format sh """
+command="/home/greg/.ssh/git-annex-shell" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDT1yE96E/JQNPt0ziiNYJRvndCvLK4uG5h/SNYoAIBF1uH6L7VYAt3HWVqSyi3BcV70WDZ/yWgtNzbrcir46JpvEHMcvYaXLbANwoDGNjG/gsz7kP/8VUxZ6hG3P3ICuwnqVum5+rYXm6oj3xzWPfTRhhRoDZLOQdevSNpdGNaa/lSg8Vuq2suHwjQlQb8AIUuCZmS5cm6XwoUq/jJtN4LTuTPqMjzA6NkdhWM2Kigi9jPQBFborkYBPMphmZwBZiVnhsH1XpaOff+mP03D2gF/huC+b1vbWQstjuehUbY59rvJ4ijb3810Uq2ep7dwLagmILtX5GbL+GS64pAn9sIP annex-othercomputer
+"""]]
+
+(4) the git-annex-shell script in your .ssh should be created for you aftering your initial ./runshell
+
+(5) Double check that the script points to the correct directory of where your extracted git-annex.linux lives.
+
+### On the other computers - the manual way
+(1) See step 2 above about creating the specific git-annex ssh keys.
+
+(2) In your .ssh/config, create an alias for your Synology that includes specifying the right sshkey. For example, mine looks like:
+[[!format sh """
+Host synologyhost
+    HostName mydynamicdomain.no-ip.org
+    IdentityFile /home/greg/.ssh/annex_rsa
+"""]]
+
+(3) Now when you clone the git repo from the Synology, or add it as a remote, do the following:
+[[!format sh """
+git clone greg@synologyhost:/absolute/path/to/annexname annexname
+"""]]
+or
+
+[[!format sh """
+git remote add synology greg@synologyhost:/absolute/path/to/annexname
+"""]]
+
+(4) Run git-annex sync
+
+### On the other computers - Using the assistant
+
+(1) Use the webapp to add the remote. I'm not sure if there are any gotchas here as I have not done it this way yet.
diff --git a/doc/tips/Synology_NAS_and_git_annex/comment_10_ee03a12ac5ba760b038ac5b93eea4be3._comment b/doc/tips/Synology_NAS_and_git_annex/comment_10_ee03a12ac5ba760b038ac5b93eea4be3._comment
new file mode 100644
index 0000000000..562326bd62
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex/comment_10_ee03a12ac5ba760b038ac5b93eea4be3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2016-04-13T18:04:42Z"
+ content="""
+Right, it would need a standalone package. It's quite easy to build such a
+package on any Debian system, just run "make linuxstandalone" in
+git-annex's source tree. I don't have a PowerPC system handy to do such builds
+on myself.
+"""]]
diff --git a/doc/tips/Synology_NAS_and_git_annex/comment_11_ab2487da061a23e14198875a00ae801e._comment b/doc/tips/Synology_NAS_and_git_annex/comment_11_ab2487da061a23e14198875a00ae801e._comment
new file mode 100644
index 0000000000..6a4e9128c6
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex/comment_11_ab2487da061a23e14198875a00ae801e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="git-annex on Synology DS216+ (x86-64)"
+ date="2017-05-28T01:19:16Z"
+ content="""
+I used a similar approach, with a bit of refinement to not require a custom ssh key/user, to [get `git-annex` running on a Synology DS216+ NAS](http://ewen.mcneill.gen.nz/blog/entry/2017-05-28-git-annex-on-synology-ds216+/), which is based around a Celeron chip (and thus needs the `x86-64` build).  Once all the `PATH` related issues are taken care of (which some symlinks into `/usr/bin`) it appears to work like any other Linux/Unix-based `git-annex` install.  (Definitely much more successful than [trying to use `git-annex` via a SMB share](http://git-annex.branchable.com/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/) at this point.)
+
+Ewen
+"""]]
diff --git a/doc/tips/Synology_NAS_and_git_annex/comment_13_44b28cff77db57a83d9448f768695d2b._comment b/doc/tips/Synology_NAS_and_git_annex/comment_13_44b28cff77db57a83d9448f768695d2b._comment
new file mode 100644
index 0000000000..659ffe5684
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex/comment_13_44b28cff77db57a83d9448f768695d2b._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="se394@012e89e10cc49919adf6ca062ea68c23230eebe5"
+ nickname="se394"
+ avatar="http://cdn.libravatar.org/avatar/13c222702203beeda07567d774433675"
+ subject="Exception thrown for runshell"
+ date="2019-07-23T18:01:31Z"
+ content="""
+Hi, 
+
+I followed these instructions but was unable to get git-annex to install on my Synology running `Linux Anvil 4.4.59+ #24922 SMP PREEMPT Fri May 10 02:49:58 CST 2019 x86_64 GNU/Linux synology_denverton_1618+`
+
+Seems to be an issue regarding locale settings. The default locales are
+```
+LANG=/usr/lib/locale/en_US
+LC_CTYPE=\"en_US.utf8\"
+LC_NUMERIC=\"en_US.utf8\"
+LC_TIME=\"en_US.utf8\"
+LC_COLLATE=\"en_US.utf8\"
+LC_MONETARY=\"en_US.utf8\"
+LC_MESSAGES=\"en_US.utf8\"
+LC_PAPER=\"en_US.utf8\"
+LC_NAME=\"en_US.utf8\"
+LC_ADDRESS=\"en_US.utf8\"
+LC_TELEPHONE=\"en_US.utf8\"
+LC_MEASUREMENT=\"en_US.utf8\"
+LC_IDENTIFICATION=\"en_US.utf8\"
+LC_ALL=en_US.utf8
+```
+
+The exception thats thrown is 
+```
+rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
+./runshell: line 135: 27709 Aborted                 (core dumped) rm -rf \"$localecache\" 2>&1
+rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
+./runshell: line 135: 27716 Aborted                 (core dumped) rm -rf \"$localecache\" 2>&1
+./runshell: line 181: 27719 Aborted                 (core dumped) cmp \"$LOCPATH/buildid\" \"$base/buildid\" > /dev/null 2>&1
+rm: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
+./runshell: line 181: 27722 Aborted                 (core dumped) rm -rf \"$LOCPATH\"
+```
+
+any ideas how to fix?
+"""]]
diff --git a/doc/tips/Synology_NAS_and_git_annex/comment_1_ef7e19f1fd2005eb7cc74509ffb92766._comment b/doc/tips/Synology_NAS_and_git_annex/comment_1_ef7e19f1fd2005eb7cc74509ffb92766._comment
new file mode 100644
index 0000000000..e7a1db9373
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex/comment_1_ef7e19f1fd2005eb7cc74509ffb92766._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnrP-0DGtHDJbWSXeiyk0swNkK1aejoN3c"
+ nickname="sebastien"
+ subject="new dev site for syno dsm 5.0"
+ date="2014-03-25T10:20:46Z"
+ content="""
+There is a new website with documentation to create App for new synology dsm 5.0 here : http://www.synology.com/en-us/support/developer
+A good way to distribute git annex to lot of people ? :)
+"""]]
diff --git a/doc/tips/Synology_NAS_and_git_annex/comment_2_5e723ccf026fe970ad31207f9f036b69._comment b/doc/tips/Synology_NAS_and_git_annex/comment_2_5e723ccf026fe970ad31207f9f036b69._comment
new file mode 100644
index 0000000000..60122bb137
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex/comment_2_5e723ccf026fe970ad31207f9f036b69._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawllyDAwjTPuM6G2d3eKE481V0qGXRKtF8s"
+ nickname="Pieter"
+ subject="Syncing metadata only with Synology NAS and git annex"
+ date="2014-10-06T12:03:35Z"
+ content="""
+I am not able to get full syncing working. It says \"syncing enabled (metadata only)\".
+When I click on Actions -> Edit it says:
+
+Just a git repository. 
+
+This repository is not currently set up as a git annex; only git metadata is synced with this repository.
+
+If this repository's ssh server has git-annex installed, you can upgrade this repository to a full git annex, which will store the contents of your files, not only their metadata.
+
+When I try to upgrade the repository it does not work. The log says:
+
+sh: git-annex-shell: not found
+
+rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+
+rsync error: remote command not found (code 127) at io.c(226) [sender=3.1.1]
+
+I'm using Version: 5.20140717 on the Linux Ubuntu 14.10.
+
+Ssh'ing from Ubuntu to gituser@synology works fine and shows the git-annex-shell options
+
+Any ideas?
+
+"""]]
diff --git a/doc/tips/Synology_NAS_and_git_annex/comment_3_8beb2b4b79c7787a92689aaad3bfc452._comment b/doc/tips/Synology_NAS_and_git_annex/comment_3_8beb2b4b79c7787a92689aaad3bfc452._comment
new file mode 100644
index 0000000000..681b001d02
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex/comment_3_8beb2b4b79c7787a92689aaad3bfc452._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 3"
+ date="2014-10-06T15:51:38Z"
+ content="""
+Pieter, I suspect you didn't follow the part of the instructions where it says to run \"./runshell\" on the NAS. If you didn't do that, there will be no ~/.ssh/git-annex-shell script set up.
+
+You have put git-annex-shell in your PATH somehow, but you probably did it by editing a bash dotfile. Those files are used for interactive login shells, but not when git-annex is sshing noninteractively into the NAS to run git-annex-shell.
+"""]]
diff --git a/doc/tips/Synology_NAS_and_git_annex/comment_4_b04a1245378d3580432e85dff8eefdec._comment b/doc/tips/Synology_NAS_and_git_annex/comment_4_b04a1245378d3580432e85dff8eefdec._comment
new file mode 100644
index 0000000000..b0eb9bdfa6
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex/comment_4_b04a1245378d3580432e85dff8eefdec._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnjDzZkA6SzZHgT5_Jy3Rw3s7m_W3-oNLY"
+ nickname="Antoni"
+ subject="Process seems to hang on Synology"
+ date="2015-01-22T20:18:12Z"
+ content="""
+I think I've completed the setup correctly, as I
+
+* am able to execute git-annex-shell on the server
+* locally running ``git-annex sync`` triggers the git-annex process on the server
+
+However, once I provide the password to the key on my local machine, nothing seemingly happens - there is no output after the password prompt.
+
+The repository I'm trying to sync with the remote on the server is ~200 mb and is in my lan.
+
+When monitoring the remote server, I see the following in process being triggered:
+
+````
+31433 31431 amk      D     656m270.7  7.1 /volume1/homes/amk/bin/git-annex.linux//lib/ld-linux.so.3 --library-path /volume1/homes/amk/bin/git-annex.linux//etc/ld.so.conf.d:/volume1/homes/amk/bin/git-annex.linux//usr/lib/arm-linux-gnueabi/audit:/volume1/homes/amk/bin/git-annex.linux//usr/lib/arm-linux-gnueabi/gconv:/volume1/homes/amk/bin/git-annex.linux//usr/lib:/volume1/homes/amk/bin/git-annex.linux//usr/lib/arm-linux-gnueabi:/volume1/homes/amk/bin/git-annex.linux//lib:/volume1/homes/amk/bin/git-annex.linux//lib/arm-linux-gnueabi: /volume1/homes/amk/bin/git-annex.linux/shimmed/git-annex-shell/git-annex-shell -c git-annex-shell 'configlist' '/volume1/homes/amk/archive/annex'
+````
+
+The memory usage goes up graudally, reaching well over 200mb, hogging the cpu significantly. I have never used git-annex before, so I'm not sure what else I should be looking for. This is what the server runs on:
+``armv7l GNU/Linux synology_armada370_214se``
+
+Is this an issue caused by the host architecture mismatch? 
+"""]]
diff --git a/doc/tips/Synology_NAS_and_git_annex/comment_5_7e4ec2b22fb15e653d3b2274493e460c._comment b/doc/tips/Synology_NAS_and_git_annex/comment_5_7e4ec2b22fb15e653d3b2274493e460c._comment
new file mode 100644
index 0000000000..af36ba5131
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex/comment_5_7e4ec2b22fb15e653d3b2274493e460c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-02-04T19:16:36Z"
+ content="""
+@Antoni git-annex-shell configlist does not do anything that would
+normally make it use much memory at all.
+
+You might find strace or similar tools useful to figure out what's going
+on.
+"""]]
diff --git a/doc/tips/Synology_NAS_and_git_annex/comment_6_954fc1b423208928fafdeb8cdac47c50._comment b/doc/tips/Synology_NAS_and_git_annex/comment_6_954fc1b423208928fafdeb8cdac47c50._comment
new file mode 100644
index 0000000000..b9d037bd1d
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex/comment_6_954fc1b423208928fafdeb8cdac47c50._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2015-02-11T17:05:15Z"
+ content="""
+There's a bug report for the memory use hang now: 
+[[bugs/git-annex_on_NAS_eats_all_memory]]
+"""]]
diff --git a/doc/tips/Synology_NAS_and_git_annex/comment_7_b862cb6ad0f912cc2ffede21df10c2fe._comment b/doc/tips/Synology_NAS_and_git_annex/comment_7_b862cb6ad0f912cc2ffede21df10c2fe._comment
new file mode 100644
index 0000000000..15b66d40a6
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex/comment_7_b862cb6ad0f912cc2ffede21df10c2fe._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Jan"
+ subject="git-annex on a PowerPC based synology?"
+ date="2016-04-12T15:41:24Z"
+ content="""
+I use a DS210 which is based on the PowerPC e500 CPU. Has anyone successfully compiled git-annex  for that architecture?
+"""]]
diff --git a/doc/tips/Synology_NAS_and_git_annex/comment_8_38775efe367033a9a96cf98a49f8cdde._comment b/doc/tips/Synology_NAS_and_git_annex/comment_8_38775efe367033a9a96cf98a49f8cdde._comment
new file mode 100644
index 0000000000..45b27df189
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex/comment_8_38775efe367033a9a96cf98a49f8cdde._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2016-04-12T19:28:15Z"
+ content="""
+@Jan, there is a powerpc build of git-annex in Debian. Not sure if it
+targets the e500 CPU.
+"""]]
diff --git a/doc/tips/Synology_NAS_and_git_annex/comment_9_52e1684fc40d1ab487a06cf13530871b._comment b/doc/tips/Synology_NAS_and_git_annex/comment_9_52e1684fc40d1ab487a06cf13530871b._comment
new file mode 100644
index 0000000000..452f68fe4d
--- /dev/null
+++ b/doc/tips/Synology_NAS_and_git_annex/comment_9_52e1684fc40d1ab487a06cf13530871b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Jan"
+ subject="comment 9"
+ date="2016-04-13T09:05:23Z"
+ content="""
+I doubt that the Debian package would be usable as-is on a Synology NAS? Perhaps it would require a standalone package, similar to armel but for PowerPC?
+"""]]
diff --git a/doc/tips/Systemd_unit.mdwn b/doc/tips/Systemd_unit.mdwn
new file mode 100644
index 0000000000..f56e20dfee
--- /dev/null
+++ b/doc/tips/Systemd_unit.mdwn
@@ -0,0 +1,103 @@
+---
+---
+
+/!\ __THIS PAGE IS A DRAFT__ /!\
+
+---
+---
+
+## Introduction
+
+Systemd is a suite of tools for system and user daemon management.
+
+It can be used as an alternative to XDG autostart files to start the git-annex daemon and optionally the webapp, either at startup (system service) or when an user logs in (user service).
+
+---
+
+##Setup
+
+### User service
+
+Sample unit file (`/etc/systemd/user/git-annex.service`):
+
+```
+[Unit]
+Description=git-annex assistant daemon
+
+[Service]
+ExecStart=/usr/bin/git-annex assistant --autostart --foreground
+Restart=on-failure
+
+[Install]
+WantedBy=default.target
+```
+
+Commands for enabling and starting the service as the current user:
+
+```
+systemctl --user enable git-annex.service
+systemctl --user start git-annex.service
+```
+
+Usually services in `default.target` start during login. (Note however that they also _delay_ the login process.) However, if you enable "linger" via `loginctl`, then these services start on boot instead.
+
+### System service
+
+If for some reason you cannot use `systemd --user`, the other option is to have system-wide services:
+
+Sample unit file (`/etc/systemd/system/git-annex@.service`):
+
+```
+[Unit]
+Description=git-annex assistant daemon
+After=network.target
+
+[Service]
+User=%i
+ExecStart=/usr/bin/git-annex assistant --autostart --foreground
+Restart=on-failure
+
+[Install]
+WantedBy=multi-user.target
+```
+
+Commands for enabling and starting the service as user `u`:
+
+```
+systemctl enable git-annex@u.service
+systemctl start git-annex@u.service
+
+```
+
+---
+
+## Considerations
+
+### Webapp
+
+The webapp may be started instead of the assistant, by launching the associated command in the unit file. This will run an associated assistant automatically. However, it may also attempt to open a potentially unwanted browser window.
+
+```
+ExecStart=git-annex webapp
+```
+
+_TODO: try this._
+
+### Encrypted home directory
+
+Users may store their keyring and repositories in their encrypted home directory mounted at login. This may break a system service running at boot.
+
+_TODO: try this._
+
+### Common daemon
+
+One daemon may be used to sync repositories for multiple users. For this, it might be helpful to make use of ACLs to access other user directories.
+
+---
+
+## References
+
+- [systemd.unit man page](https://www.freedesktop.org/software/systemd/man/systemd.unit.html)
+- [systemd on ArchWiki](https://wiki.archlinux.org/index.php/Systemd)
+- [TL;DR Syncthing with systemd documentation](https://docs.syncthing.net/users/autostart.html#using-systemd)
+- [Syncthing systemd unit files](https://github.com/syncthing/syncthing/tree/master/etc/linux-systemd)
diff --git a/doc/tips/Systemd_unit/comment_1_06399a293f08401032bef1b94f05547c._comment b/doc/tips/Systemd_unit/comment_1_06399a293f08401032bef1b94f05547c._comment
new file mode 100644
index 0000000000..7af170ef1c
--- /dev/null
+++ b/doc/tips/Systemd_unit/comment_1_06399a293f08401032bef1b94f05547c._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="oberix@c7a19cddb1663df0c612a979b9d13b0d67f1f69a"
+ nickname="oberix"
+ avatar="http://cdn.libravatar.org/avatar/e8b871f3d0bf96df9a3fc8cdca7abe09"
+ subject="autostart and foreground together doesn't seem to work"
+ date="2017-03-30T10:43:18Z"
+ content="""
+With systemd using `--autostart --foreground` either ignore foreground or quit immediatelly.
+
+I managed to have the process stay alive with `RemainAfterExit=on`:
+
+    [Service]
+    User=%i
+    ExecStart=/usr/bin/git-annex assistant --autostart --foreground
+    ExecStop=/usr/bin/git-annex assistant --autostop
+    RemainAfterExit=on
+    Restart=on-failure
+    RestartSec=5
+
+but git-annex processes does not maintain the `--foreground` option which is causing a lot of zombies in the long period (not totally clear why).
+
+My current solution is to have a service for each annex repository and avoid `--autosart` but this is annoying because it require to pass the path as `%I` and wrap git-annex in bash script to get the repo owner as the user.
+
+
+"""]]
diff --git a/doc/tips/Systemd_unit/comment_2_389a2b36c3115eb3342429b0b68ddef2._comment b/doc/tips/Systemd_unit/comment_2_389a2b36c3115eb3342429b0b68ddef2._comment
new file mode 100644
index 0000000000..ed61b19ebf
--- /dev/null
+++ b/doc/tips/Systemd_unit/comment_2_389a2b36c3115eb3342429b0b68ddef2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-04-05T15:43:21Z"
+ content="""
+@oberix, the --autostart --foreground combination is only supported
+properly since git-annex version 6.20170214. Before that, the --forground
+was ignored when using --autostart.
+"""]]
diff --git a/doc/tips/The_perfect_preferred_content_settings_for_my_android_phone.mdwn b/doc/tips/The_perfect_preferred_content_settings_for_my_android_phone.mdwn
new file mode 100644
index 0000000000..ccae0fced2
--- /dev/null
+++ b/doc/tips/The_perfect_preferred_content_settings_for_my_android_phone.mdwn
@@ -0,0 +1,36 @@
+I have an annex that syncs my personal files on all my computers. It works great. Phones are different.
+
+For one, everything's a bit slower to sync, there's battery considerations, and I just don't need every last old file on my phone. Then there's some files I explicitly don't want on my phone in case it gets lost, like family pictures, passport scans, or private keys.
+
+But I still want photos, videos and voice recordings I make on my phone to be synced to my server. A transfer repo would work, but I want to keep them. Then there's my PDF book collection; that would certainly be nice to always have around in case I have half on hour on a bus. And my music collection ought to be around as well.
+
+So I came up with this solution, and I'm very happy with it.
+
+    include=Music/* or include=Books/* or present
+
+This will sync my music and book collections to my phone whenever I add something new on my computers, and it will sync and keep anything I add to the annex on my phone. Best of all worlds! Impressed how flexible preferred content is. More full-sync folders can be added like this: 
+
+    include=Music/* or include=Books/* or include = Notes/* or present
+
+To add them, I first had to figure out the uuid of my phone repo. So I added a new tab on android, and did
+
+    cd /sdcard/annex
+    git config annex.uuid
+
+Then I went to one of my computers, and did
+
+    git annex vicfg
+
+And changed the line
+
+    content [phone-uuid] = standard
+
+to
+
+    content [phone-uuid] = include=Music/* or include=Books/* or Notes/* or present
+
+and commented out
+
+    #group [phone-uuid] = client
+
+And waited for it to sync.
diff --git a/doc/tips/The_perfect_preferred_content_settings_for_my_android_phone/comment_1_393d1636bb313530be383a075bd3440a._comment b/doc/tips/The_perfect_preferred_content_settings_for_my_android_phone/comment_1_393d1636bb313530be383a075bd3440a._comment
new file mode 100644
index 0000000000..8938684f89
--- /dev/null
+++ b/doc/tips/The_perfect_preferred_content_settings_for_my_android_phone/comment_1_393d1636bb313530be383a075bd3440a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 1"
+ date="2013-11-16T17:29:03Z"
+ content="""
+That's great, that's how I hoped people would be able to use preferred content settings.
+
+I'd suggest adding support for archive directories to this. So if you create a file on the phone and are done with it, you can move it to an archive directory, and it will then be dropped from the phone once it reaches an archive repository. 
+
+This should accomplish that. (Untested)
+
+`((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and (include=Music/* or include=Books/* or present)`
+"""]]
diff --git a/doc/tips/The_perfect_preferred_content_settings_for_my_android_phone/comment_2_51a013213118660bdc06ff4d6c8110ba._comment b/doc/tips/The_perfect_preferred_content_settings_for_my_android_phone/comment_2_51a013213118660bdc06ff4d6c8110ba._comment
new file mode 100644
index 0000000000..1b84eee813
--- /dev/null
+++ b/doc/tips/The_perfect_preferred_content_settings_for_my_android_phone/comment_2_51a013213118660bdc06ff4d6c8110ba._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXlmnJKsPulm2S_hwwRm3Ky27Zyf-wKMw"
+ nickname="Chad"
+ subject="Pulling *.flac files as well... too much data"
+ date="2013-12-31T19:26:36Z"
+ content="""
+I've tried setting up my own phone in a similar manner. Unfortunately for me, I store my `*.flac` files in the same location as my `*.mp3` files. For obvious reasons, I do not want to copy these up to my phone. This, however, is not working for me.
+
+    content PHONEUID = ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and (include=keepass/* or include=Books/* or present) and (include=Music/* and exclude=Music/*.flac and exclude=Music/*/*.flac)
+
+I still get `*.flac` files in the repo.
+"""]]
diff --git a/doc/tips/Using_Git-annex_as_a_web_browsing_assistant.mdwn b/doc/tips/Using_Git-annex_as_a_web_browsing_assistant.mdwn
new file mode 100644
index 0000000000..e8239abd40
--- /dev/null
+++ b/doc/tips/Using_Git-annex_as_a_web_browsing_assistant.mdwn
@@ -0,0 +1,40 @@
+[[todo/wishlist: an "assistant" for web-browsing -- tracking the sources of the downloads]] suggests using git-annex as a tool to store downloads tied
+to their URLs. This also enables people to have their files stored offline,
+while being able to git annex drop them at any time and redownload them
+with git annex get. Additionally, a clone of the repo can be used to
+download whatever files are desired from online.
+
+This tip explains how to implement a similar system to the one described in
+the linked wishlist with existing software and features of git-annex.
+
+The first step is to install the Firefox plugin
+[FlashGot](http://flashgot.net/). We will use it to provide the Firefox
+shortcuts to add things to our annex.
+
+Once we have installed all that, we need a script that has an interface
+which FlashGot can treat as a downloader, but which calls git-annex to do
+the actual downloading. Such a script is available from
+<https://gist.github.com/andyg0808/5342434>. Download it and store it
+somewhere it can live, or cut and paste:
+
+[[!format sh """
+#!/bin/bash
+# $1=folder to cd to (must be a git annex repo)
+# $2=URL to download
+
+cd "$1"
+git-annex addurl "$2"
+"""]]
+
+Finally, we need to configure FlashGot to use the script as a downloader.
+Go to Tools > Add-ons in Firefox. Click "Preferences" on FlashGot. Click
+the Add button next to the list of download managers. Enter a name for the
+git-annex downloader. Choose the script that was downloaded from the
+"Locate executable file" dialog that appears. Now set the command line
+arguments template to be "[FOLDER] [URL]" (you can find more substitution
+expressions in the Placeholders dropdown above the Command line arguments
+template field). You're done!
+
+Go ahead and test it by trying to download a file using FlashGot. It should
+offer as one of its available download managers the new manager you created
+just above. Select it and have fun!
diff --git a/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn b/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
new file mode 100644
index 0000000000..1cda5aef6d
--- /dev/null
+++ b/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
@@ -0,0 +1,250 @@
+The following steps are tested on Windows 10 21h1 with Ubuntu 20 and are designed to allow use of the annexed files through both WSL and Windows.
+
+** Limitations **
+
+* The repository must be created with `annex.tune.objecthashlower=true`.
+* `git annex adjust --unlock` will not work. Avoid `annex.addunlocked=true` and do not add multiple unlocked files to the index.
+
+**Setup**
+
+* Enable Developer mode in Windows settings so that symlinks can be created without elevated privileges.
+* Mount the NTFS drive with metadata option. [`/etc/wsl.conf`](https://docs.microsoft.com/en-us/windows/wsl/wsl-config) can be used or a line such as `C: /mnt/c drvfs metadata` can be added in `/etc/fstab`.
+* Follow these steps in order when creating a new repository.
+    * `git config annex.sshcaching false`
+    * `git annex init`
+    * git-annex should not detect the filesystem as crippled but now set `git config annex.crippledfilesystem true`
+* Safety of locked files will require these settings and scripts.
+    * `git config annex.freezecontent-command 'wsl-freezecontent %path'`
+    * `git config annex.thawcontent-command 'wsl-thawcontent %path'`
+
+<details>
+<summary>wsl-freezecontent</summary>
+
+```
+#!/usr/bin/env bash
+
+if [ -f "$1" ]; then
+	if \[[ "$1" == *.git/annex/objects/* ]]; then
+		PERM='(DE,WD,AD)'
+	else
+		PERM='(WD,AD)'
+	fi
+elif [ -d "$1" ]; then
+	PERM='(DE,DC,WD,AD)'
+else
+	exit 0
+fi
+
+OUTPUT="$(icacls.exe "$(wslpath -w "$1")" /deny "Authenticated Users:$PERM")"
+
+if [ "$?" -ne 0 ]; then
+	echo "$OUTPUT"
+	exit 1
+fi
+
+```
+</details>
+
+<details>
+<summary>wsl-thawcontent</summary>
+
+```
+#!/usr/bin/env bash
+
+if [ -f "$1" ]; then
+	PERM='(DE,WD,AD)'
+elif [ -d "$1" ]; then
+	PERM='(DE,DC,WD,AD)'
+else
+	exit 0
+fi
+
+OUTPUT="$(icacls.exe "$(wslpath -w "$1")" /grant "Authenticated Users:$PERM")"
+
+if [ "$?" -ne 0 ]; then
+	echo "$OUTPUT"
+	exit 1
+fi
+
+```
+</details>
+
+** Patches **
+
+These patches may introduce problems when there are multiple independent processes writing to the repository. Use at your own risk.
+
+<details>
+<summary>Create symlink to annexed objects in-place. The add, addunused, lock, and rekey commands will create symlinks in-place instead of in a temporary directory.</summary>
+
+```
+From d871289d22d2e86cb62776841343baf6c0f83484 Mon Sep 17 00:00:00 2001
+From: Reiko Asakura <asakurareiko@protonmail.ch>
+Date: Wed, 12 Oct 2022 17:13:55 -0400
+Subject: [PATCH 2/3] Create symlink to annexed objects in-place
+
+---
+ Annex/Ingest.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Annex/Ingest.hs b/Annex/Ingest.hs
+index 89dc8acea..ec35fb15d 100644
+--- a/Annex/Ingest.hs
++++ b/Annex/Ingest.hs
+@@ -301,7 +301,7 @@ restoreFile file key e = do
+ makeLink :: RawFilePath -> Key -> Maybe InodeCache -> Annex LinkTarget
+ makeLink file key mcache = flip catchNonAsync (restoreFile file key) $ do
+ 	l <- calcRepo $ gitAnnexLink file key
+-	replaceWorkTreeFile file' $ makeAnnexLink l . toRawFilePath
++	makeAnnexLink l file
+ 
+ 	-- touch symlink to have same time as the original file,
+ 	-- as provided in the InodeCache
+-- 
+2.30.2
+
+```
+</details>
+
+<details>
+<summary>Recreate symlinks after remote transfer. The copy, move, get, sync commands will recreate the symlink after transferring the file from a remote.</summary>
+
+```
+From 82ea0ffb02fbc5e4003a466a216c8d1030b7d70a Mon Sep 17 00:00:00 2001
+From: Reiko Asakura <asakurareiko@protonmail.ch>
+Date: Wed, 12 Oct 2022 19:10:07 -0400
+Subject: [PATCH 3/3] Recreate symlinks after remote transfer
+
+---
+ Annex/Link.hs   | 7 +++++++
+ Command/Get.hs  | 3 ++-
+ Command/Move.hs | 3 ++-
+ 3 files changed, 11 insertions(+), 2 deletions(-)
+
+diff --git a/Annex/Link.hs b/Annex/Link.hs
+index 1a344d07e..e0f172d1d 100644
+--- a/Annex/Link.hs
++++ b/Annex/Link.hs
+@@ -96,6 +96,13 @@ getAnnexLinkTarget' file coresymlinks = if coresymlinks
+ 					then mempty
+ 					else s
+ 
++relinkAssociatedFile :: AssociatedFile -> Bool -> Annex ()
++relinkAssociatedFile (AssociatedFile (Just file)) True =
++	getAnnexLinkTarget file >>= \case
++		Just target -> makeAnnexLink target file
++		_ -> noop
++relinkAssociatedFile _ _ = noop
++
+ makeAnnexLink :: LinkTarget -> RawFilePath -> Annex ()
+ makeAnnexLink = makeGitLink
+ 
+diff --git a/Command/Get.hs b/Command/Get.hs
+index a25fd8bf1..e16362f79 100644
+--- a/Command/Get.hs
++++ b/Command/Get.hs
+@@ -12,6 +12,7 @@ import qualified Remote
+ import Annex.Transfer
+ import Annex.NumCopies
+ import Annex.Wanted
++import Annex.Link
+ import qualified Command.Move
+ 
+ cmd :: Command
+@@ -95,7 +96,7 @@ getKey' key afile = dispatch
+ 		showNote "not available"
+ 		showlocs []
+ 		return False
+-	dispatch remotes = notifyTransfer Download afile $ \witness -> do
++	dispatch remotes = observe (relinkAssociatedFile afile) $ notifyTransfer Download afile $ \witness -> do
+ 		ok <- pickRemote remotes $ \r -> ifM (probablyPresent r)
+ 			( docopy r witness
+ 			, return False
+diff --git a/Command/Move.hs b/Command/Move.hs
+index 55fed5c37..d733a7cbb 100644
+--- a/Command/Move.hs
++++ b/Command/Move.hs
+@@ -20,6 +20,7 @@ import Logs.Presence
+ import Logs.Trust
+ import Logs.File
+ import Annex.NumCopies
++import Annex.Link
+ 
+ import qualified Data.ByteString.Char8 as B8
+ import qualified Data.ByteString.Lazy as L
+@@ -241,7 +242,7 @@ fromPerform src removewhen key afile = do
+ 			then dispatch removewhen deststartedwithcopy True
+ 			else dispatch removewhen deststartedwithcopy =<< get
+   where
+-	get = notifyTransfer Download afile $
++	get = observe (relinkAssociatedFile afile) $ notifyTransfer Download afile $
+ 		download src key afile stdRetry
+ 	
+ 	dispatch _ deststartedwithcopy False = do
+-- 
+2.30.2
+
+```
+</details>
+
+<details>
+<summary>Allow git-annex fix on crippled filesystem</summary>
+
+```
+From 65fe6e362dfbf2f54c8da5ca17c59af26de5ff83 Mon Sep 17 00:00:00 2001
+From: Reiko Asakura <asakurareiko@protonmail.ch>
+Date: Sat, 23 Oct 2021 17:13:50 -0400
+Subject: [PATCH 1/2] Allow git-annex fix on crippled filesystem
+
+---
+ Command/Fix.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Command/Fix.hs b/Command/Fix.hs
+index 39853c894..2d66c1461 100644
+--- a/Command/Fix.hs
++++ b/Command/Fix.hs
+@@ -31,7 +31,7 @@ cmd = noCommit $ withAnnexOptions [annexedMatchingOptions] $
+ 		paramPaths (withParams seek)
+ 
+ seek :: CmdParams -> CommandSeek
+-seek ps = unlessM crippledFileSystem $
++seek ps =
+ 	withFilesInGitAnnex ww seeker =<< workTreeItems ww ps
+   where
+ 	ww = WarnUnmatchLsFiles
+-- 
+2.30.2
+
+```
+</details>
+
+** Usage tips **
+
+* WSL1 will not create symlinks that work in Windows if created before the target file exists. This can be fixed by recreating them with any method, such as delete them and `git checkout`. Also see the above patches to make git-annex automatically recreate symlinks.
+
+<details>
+<summary>Sample script to recreate all symlinks under the current directory</summary>
+
+```
+#!/usr/bin/env python3
+
+import pathlib
+import os
+
+def do(p):
+	for c in list(p.iterdir()):
+		if c.is_symlink() and c.resolve().exists():
+			target = os.readlink(c) # use readlink here to get the relative link path
+			c.unlink()
+			c.symlink_to(target)
+		elif c.is_dir() and c.name != '.git':
+			do(c)
+
+do(pathlib.Path('.'))
+```
+</details>
+
+** Related bugs **
+
+* [[bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol]]
+* [[bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem]]
diff --git a/doc/tips/Using_git-annex_on_NTFS_with_WSL1/comment_1_426bcb5c31f6ddf078b5f7c9bba00672._comment b/doc/tips/Using_git-annex_on_NTFS_with_WSL1/comment_1_426bcb5c31f6ddf078b5f7c9bba00672._comment
new file mode 100644
index 0000000000..dc82065577
--- /dev/null
+++ b/doc/tips/Using_git-annex_on_NTFS_with_WSL1/comment_1_426bcb5c31f6ddf078b5f7c9bba00672._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="HiDefender"
+ avatar="http://cdn.libravatar.org/avatar/da26f59fad0edc71a2615149155b42ab"
+ subject="Using git-annex on NTFS with WSL2"
+ date="2022-09-09T19:24:56Z"
+ content="""
+Is there a guide on using git-annex with WSL2?
+
+For my use case I don't even need symlinks (e.g. $ git config annex.addunlocked true ).
+"""]]
diff --git a/doc/tips/Using_git-annex_on_NTFS_with_WSL1/comment_2_df6e152f1291c3dc1ba2b1b03b18083e._comment b/doc/tips/Using_git-annex_on_NTFS_with_WSL1/comment_2_df6e152f1291c3dc1ba2b1b03b18083e._comment
new file mode 100644
index 0000000000..78f67b141d
--- /dev/null
+++ b/doc/tips/Using_git-annex_on_NTFS_with_WSL1/comment_2_df6e152f1291c3dc1ba2b1b03b18083e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Using git-annex on NTFS with WSL2"""
+ date="2022-09-13T19:00:44Z"
+ content="""
+I have not had the chance to try WSL2, but I think that git-annex should
+work on it more or less without any issues or anything special.
+
+When the repository is on a filesystem that either does not support
+symlinks, or where you will also want to be able to access files in the
+repository from Windows outside of WSL2 without the complication of
+symlinks, it does make sense to avoid locked files. 
+`git-annex adjust --unlock` is a good way to make that be the
+case for all the files in the repository.
+"""]]
diff --git a/doc/tips/Using_git-worktree_with_annex.mdwn b/doc/tips/Using_git-worktree_with_annex.mdwn
new file mode 100644
index 0000000000..4772fb9468
--- /dev/null
+++ b/doc/tips/Using_git-worktree_with_annex.mdwn
@@ -0,0 +1,18 @@
+[Git worktrees](https://git-scm.com/docs/git-worktree) are supported since version 6.20180719.
+
+Git normally makes a `.git` **file** in a
+worktree, that points to the real git repository under `.git/worktrees/`.
+This presents problems for git-annex. So, when used in a worktree,
+git-annex will automatically replace the `.git` file with a symlink
+pointing at the git repository. It also places an appropriate `annex` link
+to `.git/worktrees/<name>/annex` to point to the object store. I don't know
+how crippled filesystems are handled.
+
+Getting, dropping and syncing content works fine in a worktree, however
+if there is change in the tree then syncing doesn't update git worktrees
+and their indices, but updates the checked out branches. This is different to
+the handling of the main working directory as it's either got updated or left
+behind with its branch if there is a conflict.
+
+In its current state I use git-worktree to copy symlinks across branches and run `git annex fix`
+on them. I only use temporary worktrees due to the syncing behavior.
diff --git a/doc/tips/Using_git-worktree_with_annex/comment_1_8e1493eae66a483ece338649c763115a._comment b/doc/tips/Using_git-worktree_with_annex/comment_1_8e1493eae66a483ece338649c763115a._comment
new file mode 100644
index 0000000000..228205d4b4
--- /dev/null
+++ b/doc/tips/Using_git-worktree_with_annex/comment_1_8e1493eae66a483ece338649c763115a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="worktrees vs. bare repositories"
+ date="2022-12-15T13:33:23Z"
+ content="""
+Note that while bare repos can have worktrees in git, the combination is not really supported in git-annex; as a result,
+
+* `git annex add` doesn't work (\"You cannot run this command in a bare repository.\") and
+* `git annex fix` would change all object links from two-character (`../.git/annex/objects/KP/4p/SHA256...`) to three-character (`../.git/annex/objects/7e3/613/SHA256...`) names.
+"""]]
diff --git a/doc/tips/ZSH_completion.mdwn b/doc/tips/ZSH_completion.mdwn
new file mode 100644
index 0000000000..f3ececd466
--- /dev/null
+++ b/doc/tips/ZSH_completion.mdwn
@@ -0,0 +1,13 @@
+ZSH users, here's some good news: after 2 years of silence, the completion function for git-annex has been updated. It now supports *all* git-annex commands (as of 5.20140517) and has many improvements for completing arguments, remotes, groups, and backends.
+
+To install it:
+
+1. make sure your have Python 3 installed (as `python3` somewhere in your `$PATH`; tested with 3.4, should work with 3.2+)
+2. get it from [GitHub](https://github.com/Schnouki/git-annex-zsh-completion)
+3. copy `_git-annex` to somewhere in your `$fpath` (I use `$HOME/.config/zsh/completion`)
+4. run `autoload -U path/to/_git-annex`
+5. type `git annex <TAB>`
+
+This is very far from being perfect, but it's (IMHO) better than nothing. If you have any issue or suggestion, please [tell me](https://github.com/Schnouki/git-annex-zsh-completion/issues)!
+
+Many thanks to Frank Terbeck and Valentin Haenel, the original authors of this completion function ([source](https://github.com/esc/git-annex-zsh-completion)).
diff --git a/doc/tips/ZSH_completion/comment_1_a810be47633dc83d737a9ef6e8870431._comment b/doc/tips/ZSH_completion/comment_1_a810be47633dc83d737a9ef6e8870431._comment
new file mode 100644
index 0000000000..c3c12ab318
--- /dev/null
+++ b/doc/tips/ZSH_completion/comment_1_a810be47633dc83d737a9ef6e8870431._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-09T15:34:59Z"
+ content="""
+When git-annex is built with optparse-applicative version 0.14.0.0,
+it can generate its own zsh completion file. The Makefile installs that,
+and it seems to work well.
+
+So, I think that the hand-built zsh completions won't need to be maintained
+much longer!
+"""]]
diff --git a/doc/tips/ZSH_completion/comment_4_0e6f7035350ec0c9c61eeafb02ab7af7._comment b/doc/tips/ZSH_completion/comment_4_0e6f7035350ec0c9c61eeafb02ab7af7._comment
new file mode 100644
index 0000000000..bc35bf98a0
--- /dev/null
+++ b/doc/tips/ZSH_completion/comment_4_0e6f7035350ec0c9c61eeafb02ab7af7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lykos153"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 4"
+ date="2017-11-09T17:35:14Z"
+ content="""
+Well I guess that depends on habit/workflow. I often let tab completion show me the directory content before beginning to type. Thanks for the links, I'll look into it (though I have no experience with Haskell yet).
+"""]]
diff --git a/doc/tips/ZSH_completion/comment_4_2bdaf6a00723b975808a52863e417321._comment b/doc/tips/ZSH_completion/comment_4_2bdaf6a00723b975808a52863e417321._comment
new file mode 100644
index 0000000000..3c037688a2
--- /dev/null
+++ b/doc/tips/ZSH_completion/comment_4_2bdaf6a00723b975808a52863e417321._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lykos153"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 4"
+ date="2017-11-09T02:15:37Z"
+ content="""
+Doesn't work so well for me. The hand-build one performs way better in terms of clearness and efficiency. It groups the suggestions instead of sorting them by name and it prints a description for each command. But most importently, it does only suggest switches when `-` was typed and completes file names otherwise. The auto generated one (at least the one that is shipped with the Arch Linux package) puts the file names last, which makes it unusable.
+"""]]
diff --git a/doc/tips/ZSH_completion/comment_5_182c13292016baf46d8f53a306cb4b05._comment b/doc/tips/ZSH_completion/comment_5_182c13292016baf46d8f53a306cb4b05._comment
new file mode 100644
index 0000000000..9fd7b628fb
--- /dev/null
+++ b/doc/tips/ZSH_completion/comment_5_182c13292016baf46d8f53a306cb4b05._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-11-09T16:11:10Z"
+ content="""
+Well, the code that generates the zsh completions could
+always be improved.
+<https://github.com/pcapriotti/optparse-applicative/issues>
+
+I don't really understand why completing options before filenames makes
+it unusable. It means that "git-annex tabtabtab" cycles through options
+first, but if you type part of the filename tab will complete the rest.
+It does seem that someone else agrees with you though, as they filed
+this issue: <https://github.com/pcapriotti/optparse-applicative/issues/173>
+"""]]
diff --git a/doc/tips/a_gui_for_metadata_operations.mdwn b/doc/tips/a_gui_for_metadata_operations.mdwn
new file mode 100644
index 0000000000..1e11800682
--- /dev/null
+++ b/doc/tips/a_gui_for_metadata_operations.mdwn
@@ -0,0 +1,13 @@
+Hey everyone.
+
+I wrote a GUI for git-annex metadata in Python: [git-annex-metadata-gui](https://github.com/alpernebbi/git-annex-metadata-gui). 
+It shows the files that are in the current branch (only those in the annex) in the respective folder hierarchy.
+The keys that are in the repository, but not in the current branch are also shown in another tab.
+You can view, edit or remove fields for individual files with support for multiple values for fields.
+There is a file preview for image and text files as well.
+I uploaded some screenshots in the repository to show it in action.
+
+While making it, I decided to move the git-annex calls into its own Python package, 
+which became [git-annex-adapter](https://github.com/alpernebbi/git-annex-adapter).
+
+I hope these can be useful to someone other than myself as well.
diff --git a/doc/tips/a_gui_for_metadata_operations/comment_1_1ce311d8328ea370a6a3494adea0f5db._comment b/doc/tips/a_gui_for_metadata_operations/comment_1_1ce311d8328ea370a6a3494adea0f5db._comment
new file mode 100644
index 0000000000..2a55de0beb
--- /dev/null
+++ b/doc/tips/a_gui_for_metadata_operations/comment_1_1ce311d8328ea370a6a3494adea0f5db._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-12-07T19:58:11Z"
+ content="""
+Thank you for this, I've always wanted such a GUI, and it's been a common
+user request!
+"""]]
diff --git a/doc/tips/android_sync_with_adb.mdwn b/doc/tips/android_sync_with_adb.mdwn
new file mode 100644
index 0000000000..c5d1261a04
--- /dev/null
+++ b/doc/tips/android_sync_with_adb.mdwn
@@ -0,0 +1,116 @@
+While git-annex can be [[installed_on_your_Android_device|/Android]],
+it might be easier not to install it there, but run it on your computer
+using `adb` to pull and push changes to the Android device.
+
+A few reasons for going this route:
+
+* Easier than installing git-annex on Android.
+* Avoids needing to type commands into a terminal on Android.
+* Avoids problems with putting a git-annex repository on Android's `/sdcard`,
+  which is crippled by not supporting hard links etc.
+
+All you should need is a USB cable (or adb over wifi), and the `adb`
+command.
+
+## setting it up
+
+First, initialize your git-annex repository on your computer, if you haven't
+already.
+
+Then, in that repository, set up an adb special remote:
+
+	git-annex initremote android type=adb androiddirectory=/sdcard encryption=none exporttree=yes importtree=yes
+
+The above example syncs with the /sdcard directory of the
+Android device. That can be a lot of files, so you may want a more
+limited directory. See the sample workflows below for some more examples.
+
+Next, configure how trees of files imported from it will be merged into your
+git repository.
+
+        git config remote.android.annex-tracking-branch master:android
+
+Setting "master:android" makes the phone be treated as containing a branch
+of the master branch, and makes all its files appear to be inside a
+subdirectory named `android`. If you want its files to not be in a
+subdirectory, set it to "master" instead.
+
+Finally, you may want to configure a preferred content expression for the
+remote. That will limit both what is exported to it, and what is imported
+from it. If you want to fully sync all files, you don't need to do this.
+
+For example, to limit the files that get imported and exported to sound files:
+
+	git annex wanted android 'include=*.mp3 or include=*.ogg'
+
+## syncing with it
+
+	git annex sync --content android
+
+This command does a bi-directional sync with the phone, first importing
+new and changed files from it, merging that into the master branch,
+and then exporting from the master branch back to the android device so any
+modifications you have made get synced over to it.
+
+See [[git-annex-import, [[git-annex-export]], and [[git-annex-sync]]
+for more details, and bear in mind that you can also use commands like
+these to only import from or export to the android device:
+
+	git annex import master:android --from android
+	git annex merge android/master
+	git annex export master:android --to android
+
+## sample workflows
+
+### photos
+
+Set up the remote to use the /sdcard/DCIM directory where the phone's
+camera stores them.
+
+	git-annex initremote android type=adb androiddirectory=/sdcard/DCIM encryption=none exporttree=yes importtree=yes
+       
+The annex-tracking-branch can be the same as before, to limit
+the files that are synced to those in an android directory:
+
+	git config remote.android.annex-tracking-branch master:android
+
+If you don't want to keep old photos on your Android device, you can simply
+`git mv` the files from the android directory to another directory, and
+the next sync with the phone will delete them from the Android device:
+
+	git mv android/* .
+	git annex sync --content
+
+### music and podcasts
+
+You could set up the remote to use the /sdcard/Music directory.
+But, I sometimes download music to other locations, and perhaps you do too.
+Let's instead limit the remote to mp3 and ogg files:
+
+	git-annex initremote android type=adb androiddirectory=/sdcard encryption=none exporttree=yes importtree=yes
+	git annex wanted android 'include=*.mp3 or include=*.ogg'
+
+The annex-tracking-branch can be the same as before, to limit
+the files that are synced to those in an android directory:
+	
+	git config remote.android.annex-tracking-branch master:android
+
+And then do an initial sync:
+
+	git annex sync --content android
+
+Now, you can copy music and podcasts you want to listen 
+to over to the Android device, by first copying them to the android
+directory of your git-annex repo:
+
+	cp -a podcasts/LibreLounge/Episode_14__Secure_Scuttlebutt_with_Joey_Hess.ogg android/
+	git annex add android
+	git annex sync --content android
+
+That will also import any new sound files from the Android device into 
+your git-annex repo.
+
+Once you're done with listening to something on the Android device, you can
+simply delete it from the device, and the next time git-annex syncs, it
+will get removed from the android directory. Or, you can delete it from the
+android directory and the next sync will delete it from the Android device.
diff --git a/doc/tips/android_sync_with_adb/comment_1_18e0b24a2907ba8df033454315e50212._comment b/doc/tips/android_sync_with_adb/comment_1_18e0b24a2907ba8df033454315e50212._comment
new file mode 100644
index 0000000000..057a5d968d
--- /dev/null
+++ b/doc/tips/android_sync_with_adb/comment_1_18e0b24a2907ba8df033454315e50212._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="https://dead-doomer.livejournal.com/"
+ subject=" How do I specify a merge command if I don't need separate branches?"
+ date="2020-06-16T16:17:48Z"
+ content="""
+>>If you want its files to not be in a subdirectory, set it to \"master\" instead.
+
+I did that. Than I issued:
+
+```
+git annex import master --from android
+```
+
+which downloaded a lot of files
+
+Then:
+```
+git annex merge android/master 
+merge android/master 
+merge: android/master - not something we can merge 
+failed 
+git-annex: merge: 1 failed
+```
+
+I tried different combinations of android/master, ./master, master/. , but all seem to fail.
+
+plain git status shows a lot of non-added files for an \"initial commit\", and no files added. git annex status lists a lot of
+
+```
+? sdcard/bla
+```
+
+files.
+
+Any suggestions?
+
+"""]]
diff --git a/doc/tips/android_sync_with_adb/comment_1_ae0ae08f76cce010999ec8d366f52400._comment b/doc/tips/android_sync_with_adb/comment_1_ae0ae08f76cce010999ec8d366f52400._comment
new file mode 100644
index 0000000000..72d8e38bb4
--- /dev/null
+++ b/doc/tips/android_sync_with_adb/comment_1_ae0ae08f76cce010999ec8d366f52400._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-16T16:48:27Z"
+ content="""
+`git-annex import master --from android` should have created an
+android/master branch with the imported files in it. There is apparently no
+such branch in your case.
+
+But I see that you also posted [[forum/--verbose_not_really_verbose__63__]]
+where you talk about having interrupted the import before it was complete.
+Since the branch only gets created when the import is allowed to finish, I
+think that explains your problem.
+
+It's rarely a good idea to not fully explain what you actually did when
+reporting what seems like a problem. If I had not happened to read that
+forum post first, and noticed it was also from you, we would have embarked
+on a snipe hunt to find some bug that doesn't really exist.
+"""]]
diff --git a/doc/tips/android_sync_with_adb/comment_2_68affd1a753abdeca0f161698cc63413._comment b/doc/tips/android_sync_with_adb/comment_2_68affd1a753abdeca0f161698cc63413._comment
new file mode 100644
index 0000000000..0f1c960c68
--- /dev/null
+++ b/doc/tips/android_sync_with_adb/comment_2_68affd1a753abdeca0f161698cc63413._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://dead-doomer.livejournal.com/"
+ subject="comment 2"
+ date="2020-06-16T16:31:32Z"
+ content="""
+At which point should I do ordinary git commits?
+
+So far the repo has been at just the \"Initial commit\"
+
+"""]]
diff --git a/doc/tips/android_sync_with_adb/comment_4_d3e6d777a26c6719df4fd2b4cf89763b._comment b/doc/tips/android_sync_with_adb/comment_4_d3e6d777a26c6719df4fd2b4cf89763b._comment
new file mode 100644
index 0000000000..37919216d1
--- /dev/null
+++ b/doc/tips/android_sync_with_adb/comment_4_d3e6d777a26c6719df4fd2b4cf89763b._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://dead-doomer.livejournal.com/"
+ subject="comment 4"
+ date="2020-06-17T01:13:46Z"
+ content="""
+Well, how would I know that that was significant? I resumed the import after interrupting it and let it run till it finished (several days actually). 
+
+In fact, I let \"import\" run several times till the end, the first time taking a lot of time, and the next ones taking ~10 minutes each.
+
+Indeed, there seems to be no android_cable/master branch
+
+```
+
+$ git --no-pager branch -ra
+  git-annex
+  synced/master
+
+```
+
+I tried to create the branch manually, but there seems to be no `git-annex branch`.
+
+In addition, this post is easily googleable, whereas \"forum\" is not. I believe that documenting a typical-of-the-typical issue that a user may encounter at the place which if the point of the first consultation is fairly useful.
+
+"""]]
diff --git a/doc/tips/android_sync_with_adb/comment_5_1ac315bee17c7f4cdc5de1427852d609._comment b/doc/tips/android_sync_with_adb/comment_5_1ac315bee17c7f4cdc5de1427852d609._comment
new file mode 100644
index 0000000000..dfe67dc1c9
--- /dev/null
+++ b/doc/tips/android_sync_with_adb/comment_5_1ac315bee17c7f4cdc5de1427852d609._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://dead-doomer.livejournal.com/"
+ subject="comment 5"
+ date="2020-06-17T06:42:53Z"
+ content="""
+How do I manually create this android_cable/master remote branch?
+
+For the sake of testing, I created another remote on the same smartphone, and indeed, if \"import\" finishes in one try, there is a 
+
+```
+
+   $ cat refs/remotes/android_test_cable/master 
+   8d7ada85897ef7df05bcdf1f2464ca678e03bd3b
+
+```
+
+How do I find an object that corresponds to the original `android_cable` special remote?
+
+"""]]
diff --git a/doc/tips/android_sync_with_adb/comment_6_4aefa716b1d37b89c3dc002f85ab6607._comment b/doc/tips/android_sync_with_adb/comment_6_4aefa716b1d37b89c3dc002f85ab6607._comment
new file mode 100644
index 0000000000..f63c32e85d
--- /dev/null
+++ b/doc/tips/android_sync_with_adb/comment_6_4aefa716b1d37b89c3dc002f85ab6607._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-08-10T18:53:15Z"
+ content="""
+
+This tip seems to work just fine when I try it. After `git annex sync
+--content android`, it had merged the remotes/android/master branch
+in. So I don't think there's a general problem with this tip that needs
+to be discussed here.
+
+The remote tracking branch is created or updated every time git-annex
+imports from the android remote, eg every time that sync command is run.
+
+If it's not creating it for you, you might have run into a bug, but if
+so you'll need to work out how others can reproduce it, and file a bug
+report.
+"""]]
diff --git a/doc/tips/android_sync_with_adb/comment_7_44a985a0cbd0adfe3a2ca4ef20443083._comment b/doc/tips/android_sync_with_adb/comment_7_44a985a0cbd0adfe3a2ca4ef20443083._comment
new file mode 100644
index 0000000000..25346c70c5
--- /dev/null
+++ b/doc/tips/android_sync_with_adb/comment_7_44a985a0cbd0adfe3a2ca4ef20443083._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="amerlyq+annex@12121d70a602f094228689a0a24d348d478a8af1"
+ nickname="amerlyq+annex"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="&quot;mirror&quot; workflow: usage of &quot;wanted&quot; expression is inconsistent with regular annex remote"
+ date="2020-12-21T07:34:27Z"
+ content="""
+Desired workflow with \"adb\":
+
+* my repo of books is large :: dld/ new/ old/ read/ ... (so can't sync whole repo 1:1 to phone and *must exclude old/ directory*)
+* usually I download books on phone, rarely on PC, and place them into dld/, then promising ones are moved into new/ and then read/ and each month lukewarm remainings in dld/ are moved into old/$date
+* so files are never edited but moved extensively between folders -- and books added from both phone and PC are expected to have the same backend (currently PC uses SHA256 but why phone is unconditionally prefers SHA1 ???)
+* this repo also contains textual journal with recorded progress (so I set largefiles to *not mimefile=text/* and failed [Mixed_content_repos_with_import_and_export](https://git-annex.branchable.com/forum/Mixed_content_repos_with_import_and_export/#comment-764ac971faf756140055333649ffb94c))
+* expecting to fully mirror _hierarchy_ of files and its changes on both phone and PC (therefore I *use \"master\"* instead of \"master:android\" to prevent manually syncing duplicate hierarchy from subdir)
+* expecting to NOT copy unwanted old/ files from PC to phone when exporting (works OK)
+* expecting to auto-move all old/ files from phone to PC when importing (like usual \"wanted\" expression for \"group=source\" -- but they are ignored instead)
+* expecting \"delete\" on phone will delete file only in \"android/master\" BUT not in \"master\" -- e.g. add symlinks back in merge commit when doing \"git annex sync --content --not-only-annex\" like described in \"import after limited export\"
+
+Concerns:
+
+* FAIL:(special-remote): using  \"git annex wanted android 'exclude=old/\*'\" **ignores** present files in old/ directory on phone and **deletes** all old/ symlinks on PC after sync.
+* BUT:(git-annex): proper remote with same \"wanted\" expression behaves differently -- it tranfers old/ files content to other remotes and then drops them in current one (but keeps symlink untouched, not deleted like above)
+* Why \"import after limited export\" is marked \"done\" if unwanted files are deleted? Or is it my misconception? <https://git-annex.branchable.com/todo/export_preferred_content/>
+
+So, maybe expressions for \"wanted content on remote\" and \"completely ignored in ALL remotes\" must be two different options?
+However the current behavior of this \"ignored\" thing is too much counter-intuitive, making its existence questionable.
+Otherwise how can I accomplish abovementioned workflow i.e. make \"adb special remote\" to visibly behave during sync as regular annex repo w/o listed quirks?
+"""]]
diff --git a/doc/tips/android_sync_with_adb/comment_8_036ff21f5eee0c165a41e472ffdfa341._comment b/doc/tips/android_sync_with_adb/comment_8_036ff21f5eee0c165a41e472ffdfa341._comment
new file mode 100644
index 0000000000..eedb91999c
--- /dev/null
+++ b/doc/tips/android_sync_with_adb/comment_8_036ff21f5eee0c165a41e472ffdfa341._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="g@aaed65f19d6c3a2a18c33da828e66c7bb915e65a"
+ nickname="g"
+ avatar="http://cdn.libravatar.org/avatar/10470d6f8a18833e04dee17126d53372"
+ subject="adb sync problem (after some upgrades) "
+ date="2022-05-29T09:59:45Z"
+ content="""
+Hello,
+some time ago (it was Jan 2022) I set up an adb remote like explained here and I was able to sync multiple times with my phone.
+
+After some time with no syncs, today I'm trying to sync again but I get this error:
+
+```
+[...]
+list android_samsung_S4_01 find: bad arg '-printf'
+stat: Needs 1 argument (see \"stat --help\")
+
+git-annex: Unable to list contents of android_samsung_S4_01: adb find failed
+failed
+
+Merge made by the 'ort' strategy.
+(recording state in git...)
+sync: 1 failed
+```
+
+My doubt is that something changed when I upgraded git-annex, this is my currently installed version:
+
+```
+git-annex version: 10.20220504
+build flags: Assistant Pairing Inotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.11 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 8
+```
+
+Please do you have any hint on what I should do to make this running again?
+
+Thanks! Giovanni
+"""]]
diff --git a/doc/tips/android_sync_with_adb/comment_9_af84d2eaeba2d5a8df087e097095eba5._comment b/doc/tips/android_sync_with_adb/comment_9_af84d2eaeba2d5a8df087e097095eba5._comment
new file mode 100644
index 0000000000..c5b9db1de3
--- /dev/null
+++ b/doc/tips/android_sync_with_adb/comment_9_af84d2eaeba2d5a8df087e097095eba5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-07-13T18:57:13Z"
+ content="""
+@g, when you have a problem like this, don't post a comment to a random
+place. File a bug report! 
+
+In this case, someone else has filed a bug: [[bugs/adb_remote_fails_to_import_treeish]]
+"""]]
diff --git a/doc/tips/antipatterns.mdwn b/doc/tips/antipatterns.mdwn
new file mode 100644
index 0000000000..0beed5b005
--- /dev/null
+++ b/doc/tips/antipatterns.mdwn
@@ -0,0 +1,150 @@
+This page tries to regroup a set of Really Bad Ideas people had with
+git-annex in the past that can lead to catastrophic data loss, abusive
+disk usage, improper swearing and other unfortunate experiences.
+
+This could also be called the "git annex worst practices", but is
+different than [[what git annex is not|not]] in that it covers normal
+use cases of git-annex, just implemented in the wrong way. Hopefully,
+git-annex should make it as hard as possible to do those things, but
+sometimes, you just can't help it, people figure out the worst
+possible ways of doing things.
+
+[[!toc]]
+
+---
+
+# **Symlinking the `.git/annex` directory**
+
+Symlinking the `.git/annex` directory, in the hope of saving
+disk space, is a horrible idea. The general antipattern is:
+
+    git clone repoA repoB
+    mv repoB/.git/annex repoB/.git/annex.bak
+    ln -s repoA/.git/annex repoB/.git/annex
+
+This is bad because git-annex will believe it has two copies of the
+files and then would let you drop the single copy, therefore leading
+to data loss.
+
+Proper pattern
+--------------
+
+The proper way of doing this is through git-annex's hardlink support,
+by cloning the repository with the `--shared` option:
+
+    git clone --shared repoA repoB
+
+This will setup repoB as an "untrusted" repository and use hardlinks
+to copy files between the two repos, using space only once. This
+works, of course, only on filesystems that support hardlinks, but
+that's usually the case for filesystems that support symlinks.
+
+Alternatively, `git worktree` can be used to add another worktree to a git
+repository. This way, multiple worktrees can share the same git-annex
+object store.
+
+Real world cases
+----------------
+
+ * [[forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/]]
+ * at least one IRC discussion
+
+Fixes
+-----
+
+Probably no way to fix this in git-annex - if users want to shoot
+themselves in the foot by messing with the backend, there's not much
+we can do to change that in this case.
+
+---
+
+# **Reinit repo with an existing uuid without `fsck`**
+
+To quote the [[git-annex-reinit]] manpage:
+
+> Normally, initializing a repository generates a new, unique
+> identifier (UUID) for that repository. Occasionally it may be useful
+> to reuse a UUID -- for example, if a repository got deleted, and
+> you're setting it back up.
+
+[[git-annex-reinit]] can be used to reuse UUIDs for deleted
+repositories. But what happens if you reuse the UUID of an *existing*
+repository, or a repository that hasn't been properly emptied before
+being declared dead? This can lead to git-annex getting confused
+because, in that case, git-annex may think some files are still
+present in the revived repository (while they may not actually be).
+
+This should never result in data loss, because git-annex does not
+trust its records about the contents of a repository, and checks
+that it really contains files before dropping them from other
+repositories. (The one exception to this rule is trusted repositories,
+whose contents are never checked. See the next two sections for more
+about problems with trusted repositories.)
+
+Proper pattern
+--------------
+
+The proper way of using reinit is to make sure you run
+[[git-annex-fsck]] (optionally with `--fast` to save time) on the
+revived repo right after running reinit. This will ensure that at
+least the location log will be updated, and git-annex will notice if
+files are missing.
+
+Real world cases
+----------------
+
+ * [[bugs/remotes_disappeared]]
+
+Fixes
+-----
+
+An improvement to git-annex here would be to allow
+[[reinit to work without arguments|todo/reinit_should_work_without_arguments]]
+to at least not encourage UUID reuse.
+
+# **Deleting data from trusted repositories**
+
+When you use [[git-annex-trust]] on a repository, you disable
+some very important sanity checks that make sure that git-annex
+never loses the content of files. So trusting a repository
+is a good way to shoot yourself in the foot and lose data. Like the
+man page says, "Use with care."
+
+When you have made git-annex trust a repository, you can lose data
+by dropping files from that repository. For example, suppose file `foo` is
+present in the trusted repository, and also in a second repository.
+
+Now suppose you run `git annex drop foo` in both repositories.
+Normally, git-annex will not let both copies of the file be removed,
+but if the trusted repository is able to verify that the second
+repository has a copy, it will delete its copy. Then the drop in the second
+repository will *trust* the trusted repository still has its copy,
+and so the last copy of the file gets deleted.
+
+Proper pattern
+--------------
+
+Either avoid using trusted repositories, or avoid dropping content
+from them, or make sure you `git annex sync` just right, so
+other reposities know that data has been removed from a trusted repository.
+
+# **Deleting trusted repositories**
+
+Another way trusted repositories are unsafe is that even after they're
+deleted, git-annex will trust that they contained the files they
+used to contain.
+
+Proper pattern
+--------------
+
+Always use [[git-annex-dead]] to tell git-annex when a repository has
+been deleted, especially if it was trusted.
+
+Other cases
+===========
+
+Feel free to add your lessons in catastrophe here! It's educational
+and fun, and will improve git-annex for everyone.
+
+PS: should this be a toplevel page instead of being drowned in the
+[[tips]] section? Where should it be linked to?  -- [[anarcat]]
diff --git a/doc/tips/assume-unstaged.mdwn b/doc/tips/assume-unstaged.mdwn
new file mode 100644
index 0000000000..63f5f820a5
--- /dev/null
+++ b/doc/tips/assume-unstaged.mdwn
@@ -0,0 +1,31 @@
+[[!meta title="using assume-unstages to speed up git with large trees of annexed files"]]
+
+Git update-index's assume-unstaged feature can be used to speed
+up `git status` and stuff by not statting the whole tree looking for changed
+files.
+
+This feature works quite well with git-annex. Especially because git
+annex's files are immutable, so aren't going to change out from under it,
+this is a nice fit. If you have a very large tree and `git status` is
+annoyingly slow, you can turn it on:
+
+	git config core.ignoreStat true
+
+When `git mv` and `git rm` are used, those changes *do* get noticed, even
+on assume-unchanged files. When new files are added, eg by `git annex add`,
+they are also noticed.
+
+There are two gotchas. Both occur because `git add` does not stage
+assume-unchanged files.
+
+1. When an annexed file is moved to a different directory, it updates
+   the symlink, and runs `git add` on it. So the file will move,
+   but the changed symlink will not be noticed by git and it will commit a
+   dangling symlink.
+2. When using `git annex migrate`, it changes the symlink and `git adds`
+   it. Again this won't be committed.
+
+These can be worked around by running `git update-index --really-refresh`
+after performing such operations. I hope that `git add` will be changed
+to stage changes to assume-unchanged files, which would remove this
+only complication. --[[Joey]] 
diff --git a/doc/tips/assume-unstaged/comment_1_44abd811ef79a85e557418e17a3927be._comment b/doc/tips/assume-unstaged/comment_1_44abd811ef79a85e557418e17a3927be._comment
new file mode 100644
index 0000000000..d253feb5b8
--- /dev/null
+++ b/doc/tips/assume-unstaged/comment_1_44abd811ef79a85e557418e17a3927be._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2djv2EYwk43rfJIAQXjYt_vfuOU-#a11a6"
+ nickname="Olivier R"
+ subject="It doesn't work 100%"
+ date="2012-05-03T21:42:54Z"
+ content="""
+When you remove tracked files... it doesn't show the new status. it's like if the file was ignored.
+
+
+"""]]
diff --git a/doc/tips/assume-unstaged/comment_2_5b589f37cfc03bf7be33a51826cc4dba._comment b/doc/tips/assume-unstaged/comment_2_5b589f37cfc03bf7be33a51826cc4dba._comment
new file mode 100644
index 0000000000..474d7b3995
--- /dev/null
+++ b/doc/tips/assume-unstaged/comment_2_5b589f37cfc03bf7be33a51826cc4dba._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnxlx1UrzVhdy6_gFjzmF42x6QXxBUxg00"
+ nickname="Jakukyo"
+ subject="comment 2"
+ date="2013-09-05T12:14:42Z"
+ content="""
+> There are two gotchas...
+
+So just always run `git annex add` after editing a file
+and `git update-index --really-refresh` after migrating
+backend?
+
+"""]]
diff --git a/doc/tips/automatically_adding_metadata.mdwn b/doc/tips/automatically_adding_metadata.mdwn
new file mode 100644
index 0000000000..b3118a75ed
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata.mdwn
@@ -0,0 +1,49 @@
+git-annex's [[metadata]] works best when files have a lot of useful
+metadata attached to them.
+
+To make git-annex automatically set the year and month when adding files,
+run: `git config annex.genmetadata true`
+
+## git commit hook
+
+A git commit hook can be set up to extract lots of metadata from files
+like photos, mp3s, etc. Whenever annexed files are committed, their
+metadata will be extracted and stored.
+
+Download [[pre-commit-annex]] and install it in your git-annex repository
+as `.git/hooks/pre-commit-annex`  
+Remember to make the script executable! `chmod +x .git/hooks/pre-commit-annex`
+
+### using extract
+
+The git commit hook can use extract to get metadata.
+
+Install it from <http://www.gnu.org/software/libextractor/>  
+`apt-get install extract`
+
+Configure which metadata fields to ask extract for: `git config metadata.extract "artist album title camera_make video_dimensions"`
+
+To get a list of all possible fields, run: `extract -L | sed 's/ /_/g'`
+
+### using exiftool
+
+The git commit hook can also use exiftool to get metadata.
+
+Install it from <http://owl.phy.queensu.ca/~phil/exiftool/>  
+`apt-get install libimage-exiftool-perl`
+
+Configure which metadata fields to ask exiftool for: `git config metadata.exiftool "Model ImageSize FocusRange GPSAltitude GPSCoordinates"`
+
+To get a list of all possible fields, run: `exiftool -list`
+
+### using both extract and exiftool
+
+If you want some metadata that extract knows about, and other metadata
+that exiftool knows about, just install them both, and set both
+`metadata.extract` and `metadata.exiftool`.
+
+### overwriting existing metadata
+
+By default, if a git-annex already has a metadata field for a file,
+its value will not be overwritten with metadata taken from files.
+To allow overwriting, run: `git config metadata.overwrite true`
diff --git a/doc/tips/automatically_adding_metadata/comment_10_cf770ba8eed7963f08517877bd460d3f._comment b/doc/tips/automatically_adding_metadata/comment_10_cf770ba8eed7963f08517877bd460d3f._comment
new file mode 100644
index 0000000000..8cb52f1924
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_10_cf770ba8eed7963f08517877bd460d3f._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="max"
+ avatar="http://cdn.libravatar.org/avatar/ebbd4dd37b341d018077a12e7ccf9fbd"
+ subject="adding support for additional metadata tools?"
+ date="2020-02-10T04:45:55Z"
+ content="""
+hi there, sincere gratitude for your work on git-annex.
+
+is it worth considering a more modular setup (maybe a python script :) or even haskell) for working with metadata extractors?
+
+currently it really only supports field-based filtering extractors. i am particularly interested in using (minimally):
+
+mp3info - offers a formatting string for printing but doesn't fit super nicely into the \"want\" fields in shell script. could probably be hacked in.
+
+mp4info - does not seem to offer any native parameters for filtering; would likely need some engineering/thought about how to take in all possible fields then filtering off of those.
+
+alternatively i could just write some personal scripts here, but just thought others would find it useful for auto extracting content from mp3/m4a files. extract doesn't seem to perform as well on these as, say, .flac files.
+
+thanks again!
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/comment_11_6eeb21b66aa3541491ddc0dd3058ddc7._comment b/doc/tips/automatically_adding_metadata/comment_11_6eeb21b66aa3541491ddc0dd3058ddc7._comment
new file mode 100644
index 0000000000..ad09dd6361
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_11_6eeb21b66aa3541491ddc0dd3058ddc7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: adding support for additional metadata tools?"""
+ date="2020-02-17T16:55:20Z"
+ content="""
+@max, notice that the hook script contains special case handling for
+exiftool, including a config option for it. That was contributed by
+Klaus Ethgen. I'd be inclined to merge patches that add handling
+for other tools.
+
+I imagine you could add config settings for the format string etc.
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/comment_12_92c28dee004562d7085191f3b9e29fec._comment b/doc/tips/automatically_adding_metadata/comment_12_92c28dee004562d7085191f3b9e29fec._comment
new file mode 100644
index 0000000000..5d9ba60c9b
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_12_92c28dee004562d7085191f3b9e29fec._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="aurelf"
+ avatar="http://cdn.libravatar.org/avatar/99aa02fcf7f5a1453b1e2528f2f543ac"
+ subject="Automatically adding metadata can be very slow "
+ date="2021-09-03T12:46:06Z"
+ content="""
+Running extract on very large files (system backups) can be too long (killed it after running several hours). 
+In general `extract` seem slow on tar.gz archives. 
+
+I added `timeout 100s` before the tool is called in the pre commit script:
+
+`LC_ALL=C timeout 100s $tool_exec \"./$f\" | ...`
+
+This allows to have the commit to complete in reasonable time, probably loosing some metadata.
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/comment_13_065b018dc290549b5ef00b50c3b09fcc._comment b/doc/tips/automatically_adding_metadata/comment_13_065b018dc290549b5ef00b50c3b09fcc._comment
new file mode 100644
index 0000000000..4135d0ae0d
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_13_065b018dc290549b5ef00b50c3b09fcc._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Automatically adding metadata can be very slow"""
+ date="2021-09-03T15:36:08Z"
+ content="""
+You could add a config to the script that skips over files larger than a
+certian size.
+
+Or for that matter, the script could be adapted to filter the files
+to only include images/videos, using eg:
+
+	git annex find --mimetype='image/*' --or --mimetype='video/*'
+
+Should be a fairly easy change, patches accepted.
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/comment_1_ffc308cc6aedabbc55820db4f401e0fb._comment b/doc/tips/automatically_adding_metadata/comment_1_ffc308cc6aedabbc55820db4f401e0fb._comment
new file mode 100644
index 0000000000..59f0e958a9
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_1_ffc308cc6aedabbc55820db4f401e0fb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2014-03-03T07:44:29Z"
+ content="""
+http://projects.iq.harvard.edu/fits might be an even better choice than libextractor. We use it in work and its not too bad, but it can be slow to startup due to the JVM.
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/comment_2_bd64a53914107bc000c887b4d4bdf6af._comment b/doc/tips/automatically_adding_metadata/comment_2_bd64a53914107bc000c887b4d4bdf6af._comment
new file mode 100644
index 0000000000..13b3865e10
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_2_bd64a53914107bc000c887b4d4bdf6af._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="2001:1928:1:9::1"
+ subject="comment 2"
+ date="2014-04-01T04:18:10Z"
+ content="""
+is there a way for this to be done globally, without having to install and configure the hook for each repository? it seems like a fairly useful feature that could be factored in git-annex itself (as opposed to be shipped as a shell script)...
+
+also, is there a way to retroactively parse the tags from existing files (as opposed to only new files added to the repo).
+
+thanks
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/comment_3_02e5314f827d17d482343e8f22c42fd9._comment b/doc/tips/automatically_adding_metadata/comment_3_02e5314f827d17d482343e8f22c42fd9._comment
new file mode 100644
index 0000000000..644ece527d
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_3_02e5314f827d17d482343e8f22c42fd9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 3"
+ date="2014-04-17T20:15:07Z"
+ content="""
+@anarcat, I have modified [[pre-commit-annex]] so if it's passed already annexed files, it'll extract their metadata. 
+
+So this can be used to add metadata to files added before you installed the hook, or if you've configured more fields to be extracted.
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/comment_4_cd3c8e2f45db93576d1b82cfbfbe601b._comment b/doc/tips/automatically_adding_metadata/comment_4_cd3c8e2f45db93576d1b82cfbfbe601b._comment
new file mode 100644
index 0000000000..f6b2773eb2
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_4_cd3c8e2f45db93576d1b82cfbfbe601b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnW_CrhP9p50n9UUhTg_a9glyKWSvnrjRQ"
+ nickname="Michele"
+ subject="direct mode pre-commit hooks [on windows]"
+ date="2015-01-20T12:43:24Z"
+ content="""
+seemingly pre-commit hooks are not being called on windows, it could have to do with git annex sync bypassing them when doing commits ?
+
+on the other side genmetadata works. although that is not enough for me since I'd want to preserve complete last modification date/time and I was in the process of modifying the supplied pre-commit script to call for \"stat %Y\" (which btw is working fine on windows, while the last binaries for extract are failing there).
+
+am I correct in assuming that direct mode [on windows at least] bypasses hooks [namely pre-commit as well as pre-commit-annex] ?
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/comment_5_888f0a77405d616a0d51a6176b44f605._comment b/doc/tips/automatically_adding_metadata/comment_5_888f0a77405d616a0d51a6176b44f605._comment
new file mode 100644
index 0000000000..29f5cecb46
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_5_888f0a77405d616a0d51a6176b44f605._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-01-20T16:52:28Z"
+ content="""
+@Michele git annex sync in a direct mode repository does bypass the
+pre-commit hook. However, it will try to run the pre-commit-annex hook.
+
+Most likely, the hook script does not appear executable on Windows, so 
+git-annex cannot run it.
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/comment_6_34f0c55d09ddee3de642f6b25a9f6269._comment b/doc/tips/automatically_adding_metadata/comment_6_34f0c55d09ddee3de642f6b25a9f6269._comment
new file mode 100644
index 0000000000..ab5bc7b76b
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_6_34f0c55d09ddee3de642f6b25a9f6269._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2015-01-20T17:19:34Z"
+ content="""
+@Michele after testing, git-annex on Windows seems to not see a file that
+does have the executable bit set as executable. I have opened a bug report
+[[bugs/windows_isExecutable_fail]], and worked around the problem now.
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/comment_7_94877b21bf80374c2874b971f26f0e55._comment b/doc/tips/automatically_adding_metadata/comment_7_94877b21bf80374c2874b971f26f0e55._comment
new file mode 100644
index 0000000000..74bd602243
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_7_94877b21bf80374c2874b971f26f0e55._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnW_CrhP9p50n9UUhTg_a9glyKWSvnrjRQ"
+ nickname="Michele"
+ subject="pre-commit is OK on windows now - auto adding last mod datetime"
+ date="2015-01-30T11:48:24Z"
+ content="""
+@Joey just tested a nightly build and now pre-commit-annex is called, and with my modifications it autoadds last modified times for content.
+Trivially it's just the matter of adding:
+
+	field=\"datemod\"
+	value=$(stat -c %Y $f)
+	addmeta \"$f\" \"$field\" \"$value\"
+
+to the body of the process() function to the supplied pre-commit-annex script.
+thanks
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/comment_8_3880fb7f13e74d33d9c4e86772cc6b0e._comment b/doc/tips/automatically_adding_metadata/comment_8_3880fb7f13e74d33d9c4e86772cc6b0e._comment
new file mode 100644
index 0000000000..813c3f0065
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_8_3880fb7f13e74d33d9c4e86772cc6b0e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="woffs"
+ avatar="http://cdn.libravatar.org/avatar/198790d74209efe4896fd4cfc37ec2a6"
+ subject="hook and quoting"
+ date="2017-12-09T11:18:10Z"
+ content="""
+Hi,
+
+just detected that the provided pre-commit-annex script is broken for filenames containing a '
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/comment_9_db9c2fa8545188520d4bdda5ba545624._comment b/doc/tips/automatically_adding_metadata/comment_9_db9c2fa8545188520d4bdda5ba545624._comment
new file mode 100644
index 0000000000..d833316253
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_9_db9c2fa8545188520d4bdda5ba545624._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2017-12-11T18:23:58Z"
+ content="""
+@woffs hmm, the hook script seems to quote every use of the filename,
+which should avoid such problems. I tested it, using both extract
+and exiftool, and a file named "foo'bar.jpg", and it worked fine.
+
+If you have a case where it does not work, suggest you file a bug
+report with enough information to reproduce the problem.
+"""]]
diff --git a/doc/tips/automatically_adding_metadata/pre-commit-annex b/doc/tips/automatically_adding_metadata/pre-commit-annex
new file mode 100755
index 0000000000..982fcca7de
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/pre-commit-annex
@@ -0,0 +1,118 @@
+#!/bin/sh
+#
+# Copyright (C) 2014 Joey Hess <id@joeyh.name>
+# Copyright (C) 2016 Klaus Ethgen <Klaus@Ethgen.ch>
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+#
+# This script can be used to add git-annex metadata to files when they're
+# committed. It is typically installed as .git/hooks/pre-commit-annex
+#
+# You can also run this script by hand, passing it the names of files
+# already checked into git-annex, and it will extract/refresh the git-annex
+# metadata from the files.
+
+tool="$(git config metadata.tool || :)"
+if [ -z "$tool" ]; then
+	tool=extract
+fi
+case "$tool" in
+	exiftool)
+		tool_exec="exiftool -unknown -zip -veryShort -ignoreMinorErrors -use MWG -dateFormat '%Y-%m-%dT%H:%M:%S'"
+	;;
+	*)
+		tool_exec="$tool"
+	;;
+esac
+
+extract_fields="$(git config metadata.extract || :)"
+if [ -n "$extract_fields" ]; then
+	tools=extract
+	extract_want="^($(echo "$extract_fields" | sed -e 's/ /|/g' -e 's/_/ /g'))"
+fi
+exiftool_fields="$(git config metadata.exiftool || :)"
+if [ -n "$exiftool_fields" ]; then
+	tools="exiftool $tools"
+	exiftool_want="^($(echo "$exiftool_fields" | sed -e 's/ /|/g' -e 's/_/ /g'))"
+fi
+if [ -z "$tools" ]; then
+	exit 0
+fi
+
+case "$(git config --bool metadata.overwrite || :)" in
+	true)
+		equal="="
+	;;
+	*)
+		equal="?="
+	;;
+esac
+
+if git rev-parse --verify HEAD >/dev/null 2>&1; then
+	against="HEAD"
+else
+	# Initial commit: diff against an empty tree object
+	against="4b825dc642cb6eb9a060e54bf8d69288fbee4904"
+fi
+
+addmeta() {
+	file="$1"
+	field="$2"
+	value="$3"
+	afield="$(echo "$field" | tr ' ' '_')"
+	git -c annex.alwayscommit=false annex metadata \
+		--set "$afield$equal$value" --quiet -- "$file"
+}
+
+process() {
+	if [ -e "$f" ]; then
+		echo "adding metadata for $f"
+		for tool in $tools; do
+			case "$tool" in
+				exiftool)
+					tool_exec="exiftool -unknown -zip -veryShort -ignoreMinorErrors -use MWG -dateFormat '%Y-%m-%dT%H:%M:%S'"
+				;;
+				*)
+					tool_exec="$tool"
+				;;
+			esac
+			LC_ALL=C $tool_exec "./$f" | eval egrep --text -i \""\$${tool}_want"\" | while read line; do
+				case "$tool" in
+					extract)
+						field="${line%% - *}"
+						value="${line#* - }"
+					;;
+					exiftool)
+						field="${line%%: *}"
+						value="${line#*: }"
+					;;
+				esac
+				
+				if [ -n "$value" ]; then
+					addmeta "$f" "$field" "$value"
+				fi
+			done
+		done
+	fi
+}
+
+if [ -n "$*" ]; then
+	for f in "$@"; do
+		process "$f"
+	done
+else
+	git diff-index -z --name-only --cached $against | sed 's/\x00/\n/g' | while read f; do
+		process "$f"
+	done
+fi
diff --git a/doc/tips/automatically_getting_files_on_checkout.mdwn b/doc/tips/automatically_getting_files_on_checkout.mdwn
new file mode 100644
index 0000000000..bbb3b302eb
--- /dev/null
+++ b/doc/tips/automatically_getting_files_on_checkout.mdwn
@@ -0,0 +1,15 @@
+Normally git-annex does not retrieve file contents when checking out a
+tree. In some use cases, it makes sense to always have the contents of
+files available after a `git checkout` or `git update`. This can be
+accomplished by installing the following as `.git/hooks/post-checkout`
+
+	#!/bin/sh
+	# Uses git-annex to get all files in the specified directories
+	# (relative to the top of the repository) on checkout.
+	dirs=.
+	top="$(git rev-parse --show-toplevel)"
+	for dir in "$dirs"; do git annex get $top/$dir"; done
+
+By default, all files in the whole repository will be made available. The
+`dirs` setting can be configured if you only want to get files in certian
+directories. 
diff --git a/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes.mdwn b/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes.mdwn
new file mode 100644
index 0000000000..0983c7d31b
--- /dev/null
+++ b/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes.mdwn
@@ -0,0 +1,2 @@
+When git annex does fsck on (for example) a GPG-encrypted special directory remote, it first transfers the whole file into .git/annex/tmp directory.
+If your annex is on an SSD, it's a good idea to make .git/annex/tmp a symlink to say /var/tmp so SSD isn't worn down.  This actually may be a better default.
diff --git a/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_1_e7c5c46112a2406b873d08bbf53c40d8._comment b/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_1_e7c5c46112a2406b873d08bbf53c40d8._comment
new file mode 100644
index 0000000000..9c7bc2ed17
--- /dev/null
+++ b/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_1_e7c5c46112a2406b873d08bbf53c40d8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 1"
+ date="2013-07-31T15:15:41Z"
+ content="""
+Of course, this only works when /var/tmp isn't on SSD itself.  Perhaps tmpfs (e.g. a /tmp on many distros) is good -- after checking that there's enough space to transfer a particular file.
+"""]]
diff --git a/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_2_daf45ce29fed986fa9aa8b173760d0b7._comment b/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_2_daf45ce29fed986fa9aa8b173760d0b7._comment
new file mode 100644
index 0000000000..929019705b
--- /dev/null
+++ b/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_2_daf45ce29fed986fa9aa8b173760d0b7._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="there's a problem"
+ date="2013-08-04T17:15:05Z"
+ content="""
+If .git/annex/tmp is a symlink to another fs, then adding doesn't work:
+
+    add file1.jpg (checksum...) 
+    git-annex: /path/to/.git/annex/tmp/tmp30148: rename: unsupported operation (Invalid cross-device link)
+
+It looks like it would be good to have two types of tmp directories here, one for adding, another one for verifying (and that one could be redirected off SSD).
+
+"""]]
diff --git a/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_3_72d222020af4a9c6c753eb1ee7e1f1cf._comment b/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_3_72d222020af4a9c6c753eb1ee7e1f1cf._comment
new file mode 100644
index 0000000000..2624a4fd34
--- /dev/null
+++ b/doc/tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/comment_3_72d222020af4a9c6c753eb1ee7e1f1cf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="guilhem"
+ ip="46.239.117.180"
+ subject="comment 3"
+ date="2013-08-19T01:05:40Z"
+ content="""
+A nice feature would be to perform the `fsck` on the (encrypted) remote itself, as it would avoid to clutter either the network or the tmpdir. However, that requires some changes in git-annex's backend. Indeed it would no longer be enough to store a single digest per (plain) file: a new digest needs to be stored for each encrypted copy. It is not necessarily a big deal, but the backend would need to be reorganized carefully.
+"""]]
diff --git a/doc/tips/centralised_repository__58___starting_from_nothing.mdwn b/doc/tips/centralised_repository__58___starting_from_nothing.mdwn
new file mode 100644
index 0000000000..7018697a0e
--- /dev/null
+++ b/doc/tips/centralised_repository__58___starting_from_nothing.mdwn
@@ -0,0 +1,71 @@
+If you are starting from nothing (no existing `git` or `git-annex` repository) and want to use a server as a centralised repository, try the following steps.
+
+On the server where you'll hold the "master" repository:
+
+	server$ cd /one/git
+	server$ mkdir m
+	server$ cd m
+	server$ git init --bare
+	Initialized empty Git repository in /one/git/m/
+	server$ git annex init origin
+	init origin ok
+	server$ 
+
+Clone that to the laptop:
+
+	laptop$ cd /other
+	laptop$ git clone ssh://server//one/git/m
+	Cloning into 'm'...
+	remote: Counting objects: 5, done.        
+	remote: Compressing objects: 100% (3/3), done.        
+	remote: Total 5 (delta 0), reused 0 (delta 0)        
+	Receiving objects: 100% (5/5), done.
+	warning: remote HEAD refers to nonexistent ref, unable to checkout.
+
+	laptop$ cd m
+	laptop$ git annex init laptop
+	init laptop ok
+        laptop$ 
+
+Add some content:
+
+	laptop$ git annex addurl http://kitenet.net/~joey/screencasts/git-annex_coding_in_haskell.ogg
+	addurl kitenet.net_~joey_screencasts_git-annex_coding_in_haskell.ogg (downloading http://kitenet.net/~joey/screencasts/git-annex_coding_in_haskell.ogg ...) --2011-12-15 08:13:10--  http://kitenet.net/~joey/screencasts/git-annex_coding_in_haskell.ogg
+	Resolving kitenet.net (kitenet.net)... 2001:41c8:125:49::10, 80.68.85.49
+	Connecting to kitenet.net (kitenet.net)|2001:41c8:125:49::10|:80... connected.
+	HTTP request sent, awaiting response... 200 OK
+	Length: 39362757 (38M) [audio/ogg]
+	Saving to: `/other/m/.git/annex/tmp/URL--http&c%%kitenet.net%~joey%screencasts%git-annex_coding_in_haskell.ogg'
+
+	100%[======================================>] 39,362,757  2.31M/s   in 17s     
+
+	2011-12-15 08:13:27 (2.21 MB/s) - `/other/m/.git/annex/tmp/URL--http&c%%kitenet.net%~joey%screencasts%git-annex_coding_in_haskell.ogg' saved [39362757/39362757]
+
+	(checksum...) ok
+	(Recording state in git...)
+
+Don't forget to commit it:
+
+	laptop$ git commit -m 'See Joey play.'
+	[master (root-commit) 106e923] See Joey play.
+	 1 files changed, 1 insertions(+), 0 deletions(-)
+	  create mode 120000 kitenet.net_~joey_screencasts_git-annex_coding_in_haskell.ogg
+	laptop$ 
+
+All fine, now push it back to the centralised master:
+
+	laptop$ git push origin master
+	Counting objects: 20, done.
+	Delta compression using up to 4 threads.
+	Compressing objects: 100% (11/11), done.
+	Writing objects: 100% (18/18), 1.50 KiB, done.
+	Total 18 (delta 1), reused 1 (delta 0)
+	To ssh://server//one/git/m
+	   3ba1386..ad3bc9e  git-annex -> git-annex
+	laptop$ 
+
+You'll probably want to use `git annex copy --to origin` to copy the
+annexed file contents to the server. See the [[walkthrough]] for details.
+
+You can add more "client" repositories by following the `laptop`
+sequence of operations.
diff --git a/doc/tips/centralised_repository__58___starting_from_nothing/comment_1_b0d22822017646775869ce1292e676f4._comment b/doc/tips/centralised_repository__58___starting_from_nothing/comment_1_b0d22822017646775869ce1292e676f4._comment
new file mode 100644
index 0000000000..22857af3e8
--- /dev/null
+++ b/doc/tips/centralised_repository__58___starting_from_nothing/comment_1_b0d22822017646775869ce1292e676f4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-12-23T19:19:53Z"
+ content="""
+See also: [[centralized_git_repository_tutorial]]
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial.mdwn b/doc/tips/centralized_git_repository_tutorial.mdwn
new file mode 100644
index 0000000000..4019c116e2
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial.mdwn
@@ -0,0 +1,18 @@
+The [[walkthrough]] builds up a decentralized git repository setup, but
+git-annex can also be used with a centralized git repository. 
+
+We have separate tutorials depending on where the centralized git
+repository is hosted.
+
+* [[centralized_git_repository_tutorial/On_GitHub]] --
+  However, GitHub does not currently let git-annex
+  store the contents of large files there. So, things get a little more
+  complicated when using it.
+
+* [[centralized_git_repository_tutorial/On_GitLab]] -- 
+  This service is similar to GitHub, but supports
+  git-annex.
+
+* [[centralized_git_repository_tutorial/On_your_own_server]] --
+  use any unix system with ssh and git and git-annex installed.
+  A VPS, a home server, etc.
diff --git a/doc/tips/centralized_git_repository_tutorial/comment_1_9072ebc0c61446d7b151fcfab616fea9._comment b/doc/tips/centralized_git_repository_tutorial/comment_1_9072ebc0c61446d7b151fcfab616fea9._comment
new file mode 100644
index 0000000000..c509d75796
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/comment_1_9072ebc0c61446d7b151fcfab616fea9._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkC0W3ZQERUaTkHoks6k68Tsp1tz510nGo"
+ nickname="Georg"
+ subject="sync, push, pull with/to/from centralized bare repository"
+ date="2013-10-07T06:45:19Z"
+ content="""
+Hi Joey,
+
+thanks for tutorial with the centralized repo. I am currently trying to set up a central bare repo for two clients (they cannot communicate directly with each other). I am not sure if I am pushing/pulling the right way.
+
+On the server I did:
+
+    git init --bare
+    git annex init origin
+
+On Cĺient Alice (I want to give Bob a chance get call \"git annex get\" from \"origin\"):
+
+    git clone ssh://tktest@192.168.56.104/~/annex .
+    git annex init Alice
+    git annex merge
+    git annex add .
+    git commit -a -m \"Added tutorial\"
+    git push origin master git-annex
+    git annex copy . --to origin
+
+On Client Bob I have called \"clone, init, merge, add, push, copy\" also.
+
+Now the tricky part - do I have to call \"git annex sync\" at Alice's side to get the updates from Bob over origin?
+I ran into troubles if I called \"copy --to origin\" before \"git push origin master git-annex\". How can I resolve a non-fast-forware on the git-annex branch?
+Some notes about how to sync over a central bare repo would be nice here =)
+
+Thanks a lot, Georg
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/comment_2_528e92b21f0551fde4adb956654953ae._comment b/doc/tips/centralized_git_repository_tutorial/comment_2_528e92b21f0551fde4adb956654953ae._comment
new file mode 100644
index 0000000000..21b286fff2
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/comment_2_528e92b21f0551fde4adb956654953ae._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.253.80"
+ subject="How can I resolve a non-fast-forware on the git-annex branch?"
+ date="2013-10-07T17:08:32Z"
+ content="""
+By either running `git annex sync`, or if you want to pull and push yourself, by running `git annex merge` before pushing.
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/comment_3_8894229043935e70089caf67f0cc4ddb._comment b/doc/tips/centralized_git_repository_tutorial/comment_3_8894229043935e70089caf67f0cc4ddb._comment
new file mode 100644
index 0000000000..b0324d47a1
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/comment_3_8894229043935e70089caf67f0cc4ddb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn8d6WBPNtmyeANT-gjlN19QnCTQ0psRPs"
+ nickname="James"
+ subject="S3 special remote?"
+ date="2015-01-22T21:52:13Z"
+ content="""
+Is it possible to use special remotes (like S3) with this centralized method?
+
+Public web content works fine, but I've had no luck with S3.
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/comment_4_b496622537d2491854b02884acf1672c._comment b/doc/tips/centralized_git_repository_tutorial/comment_4_b496622537d2491854b02884acf1672c._comment
new file mode 100644
index 0000000000..9ef4ddd1d2
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/comment_4_b496622537d2491854b02884acf1672c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-02-04T19:29:01Z"
+ content="""
+You can add any kind of special remotes to such a repository.
+
+Each clone from the central repository will need to have `git annex
+enableremote` used to enable any special remote(s) you need to use
+from that clone.
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/comment_5_c6e3468c95bc875e17724ee4a3a283a3._comment b/doc/tips/centralized_git_repository_tutorial/comment_5_c6e3468c95bc875e17724ee4a3a283a3._comment
new file mode 100644
index 0000000000..d9a62cccbc
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/comment_5_c6e3468c95bc875e17724ee4a3a283a3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="spalax@b201acef21dca7798b874036bbbaa9e0079a0b7e"
+ nickname="spalax"
+ avatar="http://cdn.libravatar.org/avatar/3f1353e4135221fc25bfecd1b812bcc8"
+ subject="git-annex support dropped"
+ date="2017-06-27T09:26:11Z"
+ content="""
+For information, gitlab is going to drop support for git-annex (see issue [#1648](https://gitlab.com/gitlab-org/gitlab-ee/issues/1648)).
+
+-- Louis
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_GitHub.mdwn b/doc/tips/centralized_git_repository_tutorial/on_GitHub.mdwn
new file mode 100644
index 0000000000..4522319b3f
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_GitHub.mdwn
@@ -0,0 +1,129 @@
+This tutorial shows how to set up a centralized repository hosted on
+GitHub.
+
+GitHub does not currently let git-annex store the contents of large files
+there. This doesn't prevent using git-annex with GitHub, it just means you
+have to set up some other centralized location for the large files.
+
+## set up the repository, and make a checkout
+
+I've created a repository for technical talk videos, which you can
+[fork on Github](https://github.com/joeyh/techtalks).
+Or make your own repository on GitHub now.
+
+On your laptop, [[install]] git-annex, and clone the repository:
+
+	# git clone git@github.com:joeyh/techtalks.git
+	# cd techtalks
+
+Tell git-annex to use the repository, and describe where this clone is
+located:
+
+	# git annex init 'my laptop'
+	init my laptop ok
+
+## add files to the repository
+
+Add some files, obtained however.
+
+	# git annex add *.mp4
+	add Haskell_Amuse_Bouche-b9OVqxmI.mp4 (checksum) ok
+	(Recording state in git...)
+	# git commit -m "added a video. I have not watched it yet but it sounds interesting"
+
+This file is available on the web; so git-annex can download it:
+
+	# git annex addurl http://kitenet.net/~joey/screencasts/git-annex_coding_in_haskell.ogg
+	addurl kitenet.net_~joey_screencasts_git-annex_coding_in_haskell.ogg
+	(downloading http://kitenet.net/~joey/screencasts/git-annex_coding_in_haskell.ogg ...)
+	(checksum...) ok
+	(Recording state in git...)
+	# git commit -a -m 'added a screencast I made'
+
+Feel free to rename the files, etc, using normal git commands:
+
+	# git mv Haskell_Amuse_Bouche-b9OVqxmI.mp4 Haskell_Amuse_Bouche.mp4
+	# git mv kitenet.net_~joey_screencasts_git-annex_coding_in_haskell.ogg git-annex_coding_in_haskell.ogg
+	# git commit -m 'better filenames'
+
+Now push your changes back to the central repository on GitHub. As well as 
+pushing the master branch, remember to push the git-annex branch, which is
+used to track the file contents. You can do this push manually as shown
+below, or you can just run `git annex sync` to do the same thing.
+
+	# git push origin master git-annex
+	To git@github.com:joeyh/techtalks.git
+	 * [new branch]      master -> master
+	 * [new branch]      git-annex -> git-annex
+
+That push went fast, because it didn't upload large videos to GitHub.
+To check this, you can ask git-annex where the contents of the videos are:
+
+	# git annex whereis
+	whereis Haskell_Amuse_Bouche.mp4 (1 copy) 
+	  	767e8558-0955-11e1-be83-cbbeaab7fff8 -- here
+	ok
+	whereis git-annex_coding_in_haskell.ogg (2 copies) 
+	  	00000000-0000-0000-0000-000000000001 -- web
+	   	767e8558-0955-11e1-be83-cbbeaab7fff8 -- here
+	ok
+
+## make more checkouts
+
+So far you have a central repository, and a checkout on a laptop.
+You, or anyone you allow to can clone the central repository, and
+use git-annex with it.
+
+But, since GitHub doesn't currently support storing large files there
+with git-annex, other checkouts of your repository won't be able to
+access the files you added to the repository on your laptop.
+
+	# git clone git@github.com:myrepo/techtalks.git
+	# git annex get Haskell_Amuse_Bouche-b9OVqxmI.mp4
+	get Haskell_Amuse_Bouche-b9OVqxmI.mp4
+
+	  Try making some of these repositories available:
+		767e8558-0955-11e1-be83-cbbeaab7fff8 -- my laptop
+	failed
+
+## add a special remote
+
+So, to complete your setup, you need to set up a repository where git-annex
+can store the contents of large files. This is often done by setting up
+a [[special_remote|special_remotes]]. One free option is explained in
+[[using_box.com_as_a_special_remote]]. Another useful approach is
+explained in [[public_Amazon_S3_remote]].
+
+Once you have the special remote set up on your laptop, you can
+send files to it:
+
+	# git annex copy --to myspecialremote Haskell_Amuse_Bouche-b9OVqxmI.mp4
+	copy Haskell_Amuse_Bouche-b9OVqxmI.mp4 (to myspecialremote...)
+	100% 255.11kB/s
+	ok
+
+You can also `git annex move` files to it, to free up space on your laptop.
+And then you can `git annex get` files back to your laptop later on, as
+desired.
+
+After you use git-annex to move files around, remember to sync,
+which will broadcast its updated location information.
+
+	# git annex sync
+
+After setting up the special remote and storing some files on it,
+you can download them on other clones. You'll first need to enable the same
+special remote on the clones.
+
+	# git annex sync
+	# git annex enableremote myspecialremote
+	# git annex get git-annex_coding_in_haskell.ogg
+	100% 255.11kB/s
+	ok
+
+## take it farther
+
+You can add remotes for each direct connection between machines you find you
+need -- so make the laptop have the desktop as a remote, and the desktop
+have the laptop as a remote, and then on either machine git-annex can
+access files stored on the other.
diff --git a/doc/tips/centralized_git_repository_tutorial/on_GitHub/comment_1_98a1986ff2047de981d77755c462b690._comment b/doc/tips/centralized_git_repository_tutorial/on_GitHub/comment_1_98a1986ff2047de981d77755c462b690._comment
new file mode 100644
index 0000000000..6ea1c722fc
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_GitHub/comment_1_98a1986ff2047de981d77755c462b690._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="tomi.ollila@7588dbee63d5e035a85167fe207afb49287f9d1a"
+ nickname="tomi.ollila"
+ avatar="http://cdn.libravatar.org/avatar/a794ec01b038c83c4d568d17dc4ceeab"
+ subject="git config remote.origin.annex-ignore true"
+ date="2018-12-26T20:33:36Z"
+ content="""
+Something like 
+
+    git config remote.origin.annex-ignore true
+
+could be useful information in this page. It took me 1.5 hours to figure this out for me (while coding)...
+
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_GitLab.mdwn b/doc/tips/centralized_git_repository_tutorial/on_GitLab.mdwn
new file mode 100644
index 0000000000..e0aa5a9b78
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_GitLab.mdwn
@@ -0,0 +1,78 @@
+Update: GitLab [removed support](https://gitlab.com/gitlab-org/gitlab-ee/issues/1648) for git-annex in 2017 with the 9.0 release.
+
+This tutorial shows how to set up a centralized repository hosted on
+GitLab. 
+
+Since GitLab has [added support for git-annex on their servers](https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/),
+you can store your large files on GitLab, quite easily.
+
+Note that as I'm writing this, GitLab is providing this service for free,
+and will store up to 10 gb per project.
+
+## create the repository
+
+Go to <https://gitlab.com/> and sign up for an account, and create the
+repository there. Take note of the SSH clone url for the repository, which
+will be something like `git@gitlab.com:yourlogin/annex.git`. 
+
+We want to clone this locally, on your laptop. (If the clone fails, you
+need to generate a ssh key and add it to GitLab.)
+
+	# git clone git@gitlab.com:yourlogin/annex.git
+	# cd annex
+
+Tell git-annex to use the repository, and describe where this clone is
+located:
+
+	# git annex init 'my laptop'
+	init my laptop ok
+
+Add some files, obtained however.
+
+	# git annex add *.mp4
+	add Haskell_Amuse_Bouche-b9OVqxmI.mp4 (checksum) ok
+	(Recording state in git...)
+	# git commit -m "added a video. I have not watched it yet but it sounds interesting"
+
+Feel free to rename the files, etc, using normal git commands:
+
+	# git mv Haskell_Amuse_Bouche-b9OVqxmI.mp4 Haskell_Amuse_Bouche.mp4
+	# git commit -m 'better filenames'
+
+## push to GitLab
+
+Now make a first push to the GitLab repository.
+As well as pushing the master branch, remember to push the git-annex
+branch, which is used to track the file contents.
+
+	# git push origin master git-annex
+	To git@gitlab.com:yourlogin/annex.git
+	 * [new branch]      master -> master
+	 * [new branch]      git-annex -> git-annex
+
+That push went fast, because it didn't upload the large file contents yet.
+
+So, to finish up, tell git-annex to sync all the data in the repository
+to GitLab:
+
+	# git annex sync --content
+	...
+
+## make more checkouts
+
+So far you have a central repository on GitLab, and a checkout on a laptop.
+Let's make another checkout elsewhere. Clone the central repository as before.
+(If the clone fails, you need to generate a ssh key and add it to GitLab.)
+
+	elsewhere# git clone git@gitlab.com:yourlogin/annex.git
+	elsewhere# cd annex
+
+Notice that your clone does not have the contents of any of the files yet.
+If you run `ls`, you'll see broken symlinks. It's easy to download them from
+GitLab either by running `git annex sync --content`, or by asking
+git-annex to download individual files:
+
+	# git annex get Haskell_Amuse_Bouche.mp4
+	get Haskell_Amuse_Bouche.mp4 (from origin...)
+	12877824   2%  255.11kB/s    00:00
+	ok
diff --git a/doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_1_9d0694204984ec96379a62f0f70ba696._comment b/doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_1_9d0694204984ec96379a62f0f70ba696._comment
new file mode 100644
index 0000000000..3a17029ee7
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_1_9d0694204984ec96379a62f0f70ba696._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="Need advice on using gitlab with the assistant"
+ date="2015-10-03T21:03:45Z"
+ content="""
+There is a GUI and I followed it but when upgrading it to a full git-annex repository I get:
+
+remote: GitLab: You are not allowed to force push code to a protected branch on this project.        
+To git@git-annex-gitlab.com-git_22_pacuraru.2Fgitannex.2Egit:pacuraru/gitannex.git
+ ! [remote rejected] refs/gcrypt/gitception+ -> master (pre-receive hook declined)
+error: failed to push some refs to 'git@git-annex-gitlab.com-git_22_pacuraru.2Fgitannex.2Egit:pacuraru/gitannex.git'
+error: failed to push some refs to 'gcrypt::git@git-annex-gitlab.com-git_22_pacuraru.2Fgitannex.2Egit:pacuraru/gitannex.git'
+[2015-10-03 23:01:30.409376] main: Syncing with gitlab.com_pacuraru_gitannex.git 
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_2_1c33d3f62ec7119c116ad02b75c91f8a._comment b/doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_2_1c33d3f62ec7119c116ad02b75c91f8a._comment
new file mode 100644
index 0000000000..cdbc035e4e
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_2_1c33d3f62ec7119c116ad02b75c91f8a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 2"
+ date="2015-10-03T21:27:46Z"
+ content="""
+I managed to overcome that hurdle but now gitlab shows as \"just a git repository\" and I don't seem to be able to do the conversion \"Upgrade Repository\" - nothing in the logs, any ideas?
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_3_7d3ea328a42c3a1df01f87e5233eca62._comment b/doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_3_7d3ea328a42c3a1df01f87e5233eca62._comment
new file mode 100644
index 0000000000..5143342473
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_3_7d3ea328a42c3a1df01f87e5233eca62._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 3"
+ date="2015-10-03T21:29:29Z"
+ content="""
+oh, and btw. there's no button in the assistant to delete this useless gitlab repo, I can only edit it and try and upgrade it which doesn't work :-(
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_4_3c40b855e9914d8987b2f89d9abc29ae._comment b/doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_4_3c40b855e9914d8987b2f89d9abc29ae._comment
new file mode 100644
index 0000000000..cc2eab05eb
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_GitLab/comment_4_3c40b855e9914d8987b2f89d9abc29ae._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-11-18T19:14:32Z"
+ content="""
+@ovidiu, this tutorial is about setting up GitLab as a remote using
+git-annex at the command line. The steps given here should work.
+
+You're trying to use GitLab from the git-annex assistant. The first
+version that supported that was version 5.20150731. I guess you might have
+been trying to use an older version. Or encountered some other problem
+which is offtopic to this page. If you have a problem, file a bug report
+with full details about the version of git-annex you used and what you did.
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_your_own_server.mdwn b/doc/tips/centralized_git_repository_tutorial/on_your_own_server.mdwn
new file mode 100644
index 0000000000..049e523ee8
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_your_own_server.mdwn
@@ -0,0 +1,94 @@
+This tutorial shows how to set up a centralized git repository
+hosted on your own git server, which can be any unix system with
+ssh and git and git-annex installed. A VPS, a home server, etc.
+
+This sets up a very simple git server. More complex setups are possible.
+See for example [[using_gitolite_with_git-annex]].
+
+## set up the server
+
+On the server, you'll want to [[install]] git, and git-annex, if you haven't
+already. If possible, install it using your distribution's package manager:
+
+	server# sudo apt-get install git git-annex
+
+Note that git-annex-shell needs to be located somewhere in the PATH, so
+that a client can successfully run "ssh yourserver git-annex-shell".
+Installing git-annex using a package manager will take care of this for
+you. But if you're not root or otherwise can't install git-annex that way,
+you may need to do more work; see [[get_git-annex-shell_into_PATH]].
+
+Decide where to put the repository on the server, and create a bare git repo
+there. In your home directory is a simple choice:
+
+	server# cd
+	server# git init annex.git --bare --shared
+	server# cd annex.git
+	server# git annex init
+	init ok
+
+That's the server setup done!
+
+## make a checkout
+
+Now on your laptop, clone the git repository from the server:
+
+	laptop# git clone ssh://example.com/~/annex.git
+	Cloning into 'annex'...
+	warning: You appear to have cloned an empty repository.
+	Checking connectivity... done.
+
+Tell git-annex to use the repository:
+
+	laptop# cd annex
+	laptop# git annex init
+	init ok
+
+## add files to the repository
+
+Add some files, obtained however.
+
+	# git annex add *.mp4
+	add Haskell_Amuse_Bouche-b9OVqxmI.mp4 (checksum) ok
+	(Recording state in git...)
+	# git commit -m "added a video. I have not watched it yet but it sounds interesting"
+
+Feel free to rename the files, etc, using normal git commands:
+
+	# git mv Haskell_Amuse_Bouche-b9OVqxmI.mp4 Haskell_Amuse_Bouche.mp4
+	# git commit -m 'better filenames'
+
+Now push your changes back to the central repository on your server. As
+well as pushing the master branch, remember to push the git-annex branch,
+which is used to track the file contents.
+
+	# git push origin master git-annex
+	To git@github.com:joeyh/techtalks.git
+	 * [new branch]      master -> master
+	 * [new branch]      git-annex -> git-annex
+
+That push went fast, because it didn't upload large videos to the server.
+
+So, to finish up, tell git-annex to sync all the data in the repository
+to your server:
+
+	# git annex sync origin --content
+	...
+
+## make more checkouts
+
+So far you have a central repository on your server, and a checkout on a laptop.
+Let's make another checkout elsewhere. Clone the central repository as before.
+
+	elsewhere# git clone ssh://example.com/~/annex.git
+	elsewhere# cd annex
+
+Notice that your clone does not have the contents of any of the files yet.
+If you run `ls`, you'll see broken symlinks. It's easy to download them from
+your server either by running `git annex sync --content`, or by asking
+git-annex to download individual files:
+
+	# git annex get Haskell_Amuse_Bouche.mp4
+	get Haskell_Amuse_Bouche.mp4 (from origin...)
+	12877824   2%  255.11kB/s    00:00
+	ok
diff --git a/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_1_ae5af47faf95f008f1b07dbed5181286._comment b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_1_ae5af47faf95f008f1b07dbed5181286._comment
new file mode 100644
index 0000000000..2534105664
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_1_ae5af47faf95f008f1b07dbed5181286._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="tom_clune"
+ subject="git annex using the &quot;wrong&quot; ssh socket"
+ date="2016-02-24T19:23:13Z"
+ content="""
+To avoid frequent typing of pin + RSA passcode + password,  we typically establish an ssh control master just once.   This works fine with regular git commands, but the git-annex command apparently try to create a different socket.  Even that would be ok, except that apparently it is a new socket each time we enter a command.
+
+With sufficient \"-vvvv\" we see things like:  
+
+    ...
+    debug1: Executing proxy command: exec ssh -l fred proxy.xxx.yyy direct host
+    ...
+
+(Note I have eliminated references to the actual machine names and userid's.)
+
+If the command had instead been:
+
+     exec ssh -l fred proxy.xxx.yyy direct /home/fred/.ssh/master_host:22
+
+everything would have worked fine.  In fact, we are now using:
+
+     git config remote.origin.annex-ssh-options '-S /home/fred/.ssh/master_host:22'
+
+and this eliminates the issue.    But it would be nice if git annex could somehow automatically use
+the pre-existing connection.     Is there a better way to achieve this?
+
+
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_2_b6a70e698eb4c46e753a620716c5956c._comment b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_2_b6a70e698eb4c46e753a620716c5956c._comment
new file mode 100644
index 0000000000..54c8a6b3e0
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_2_b6a70e698eb4c46e753a620716c5956c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-04-14T19:40:32Z"
+ content="""
+git-annex sets up its own ssh connection caching because this makes it a
+lot faster.
+
+To disable this feature, you can set annex.sshcaching=false, or set
+remote.origin.annex-ssh-options as you have.
+
+git-annex has no way to know if you have another ssh socket to use, so it
+seems fine for you to need to configure it if you want it to use one.
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_3_371f22ec58cf953c2b8abe3af71d3f91._comment b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_3_371f22ec58cf953c2b8abe3af71d3f91._comment
new file mode 100644
index 0000000000..c39263fa51
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_3_371f22ec58cf953c2b8abe3af71d3f91._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="ynikitenko"
+ avatar="http://cdn.libravatar.org/avatar/168d629704097ddc596f75ca32a687a3"
+ subject="Is it essential to clone from the server?"
+ date="2017-11-03T11:28:01Z"
+ content="""
+    Now on your laptop, clone the git repository from the server:
+
+Is it possible to init git-annex repo on your local machine, add git-remote there and push local data to the server? Won't there be any problems with this 'non-official' approach?
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_4_6610f58b031d587f07f05b31754e4d97._comment b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_4_6610f58b031d587f07f05b31754e4d97._comment
new file mode 100644
index 0000000000..6fa1891374
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_4_6610f58b031d587f07f05b31754e4d97._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="ynikitenko"
+ avatar="http://cdn.libravatar.org/avatar/168d629704097ddc596f75ca32a687a3"
+ subject="tutorial up to date?"
+ date="2017-11-03T20:23:12Z"
+ content="""
+When I follow the tutorial and run
+
+    git push origin master git-annex
+
+it replies
+
+    error: src refspec master does not match any.
+    error: failed to push some refs to 'vds:~/test.git'
+
+However one can use `git-annex sync` instead and that works fine.
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_5_b18e841b77cbec354d7641f37d030f49._comment b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_5_b18e841b77cbec354d7641f37d030f49._comment
new file mode 100644
index 0000000000..9d6cec148c
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_5_b18e841b77cbec354d7641f37d030f49._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="metst13@1d16544ec52801db7efb2895d3dc7a4458b8eb45"
+ nickname="metst13"
+ avatar="http://cdn.libravatar.org/avatar/168d629704097ddc596f75ca32a687a3"
+ subject="clone to the server"
+ date="2018-11-06T14:58:39Z"
+ content="""
+As usually, create a directory on the server, `git init`, then `git-annex init` there. 
+
+Add that locally: `git remote add my-server-name my-server:~/my-repo`
+
+`git-annex sync` locally seems to work fine and pushes data to the server. 
+
+I needed to have this workaround before, because I could not get data from my laptop while on the server (I wasn't sure I had an open IP address for my laptop). This is mostly a basic thing in git, but I had errors with git-annex earlier and I try to be cautious now.
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_6_a75d657dc322e1ccb02871492bef6f12._comment b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_6_a75d657dc322e1ccb02871492bef6f12._comment
new file mode 100644
index 0000000000..8b14dad5cf
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_6_a75d657dc322e1ccb02871492bef6f12._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="metst13@1d16544ec52801db7efb2895d3dc7a4458b8eb45"
+ nickname="metst13"
+ avatar="http://cdn.libravatar.org/avatar/168d629704097ddc596f75ca32a687a3"
+ subject="comment 6"
+ date="2018-11-06T16:10:11Z"
+ content="""
+I must add that after the previous commands finished, content of the repository was not shown on the server (it was all in .git). I made
+
+    git checkout synced/master
+
+and files appeared. Unfortunately it seems all timestamps were new, which I didn't like, and it was already asked here (http://git-annex.branchable.com/todo/does_not_preserve_timestamps/).
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_7_e818be55d40623167ce2d0381e7168e3._comment b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_7_e818be55d40623167ce2d0381e7168e3._comment
new file mode 100644
index 0000000000..6380a9a447
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_7_e818be55d40623167ce2d0381e7168e3._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="jrollins"
+ avatar="http://cdn.libravatar.org/avatar/129f3c58226661d01c5bfc18f0048d81"
+ subject="problems with init after clone"
+ date="2021-01-31T20:34:31Z"
+ content="""
+I'm trying to following the instructions here, but keep running into the following problem whenever I try to clone the remote repo:
+
+```
+0$ git clone ssh://remote.example.com/~/tmp/archive/git
+Cloning into 'git'... warning: You appear to have cloned an empty repository.
+0$ cd git/
+0$ git annex init local
+init servo (scanning for unlocked files...)
+
+  Unable to parse git config from origin
+
+  Remote origin does not have git-annex installed; setting annex-ignore
+
+  This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote origin
+ok
+(recording state in git...)
+0$ 
+```
+
+What am I doing wrong? The remote repo is setup bare, exactly as suggested.
+
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_8_0778c23a67f7474753fb143ced6227a5._comment b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_8_0778c23a67f7474753fb143ced6227a5._comment
new file mode 100644
index 0000000000..116a9c4462
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_8_0778c23a67f7474753fb143ced6227a5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: problems with init after clone"""
+ date="2021-02-01T16:03:04Z"
+ content="""
+@jrollins Well, it looks like you have maybe not installed git-annex on
+your server. If it is installed and you still have this problem, you may
+need to consult [[get_git-annex-shell_into_PATH]].
+"""]]
diff --git a/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_9_915965b46b03186eec466c51131c734c._comment b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_9_915965b46b03186eec466c51131c734c._comment
new file mode 100644
index 0000000000..6dfad4987e
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_your_own_server/comment_9_915965b46b03186eec466c51131c734c._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="zoran.bosnjak@683708e9d46ca9d9fa8957bd513e6648cbcbf421"
+ nickname="zoran.bosnjak"
+ avatar="http://cdn.libravatar.org/avatar/83221ce6eaa0b62d27a6507c96a61fae"
+ subject="centralized repository workflow"
+ date="2024-02-06T12:33:20Z"
+ content="""
+Hi, what would be a recommended setup and the working procedures for the following scenario:
+
+- using git-annex version: 8.20210223, which is the one in ubuntu-22.04 (can't upgrade easily)
+- a central server as a mutable central archive, many users (over ssh)
+- users are all trusted
+- the server shall keep all annexed files, but only the HEAD version is relevant, that is:
+  if the file is removed by the user, it shall eventually be permanently removed from the central server too,
+  to save space.
+- users would tipically not need all the files, but only some, so `git annex get files...` would do
+- users would also add or remove annexed files (and push them to the central repository)
+- a user might remove his/her local repository at any time, so the central server shall not keep track about clones
+  or at least shall not care if any or all clones get removed
+
+I have created central repository like this (please correct me):
+
+    git init test --bare                                                                                       
+    cd test                                                                                                    
+    git annex init                                                                                             
+    git annex required . \"include=*\" 
+
+On the user site
+
+    git clone ssh://some.server/repo/test test
+    cd test
+    dd if=/dev/random of=./bigfile bs=1M count=10
+    git annex add bigfile
+    # how to sync (push only)?
+    # how to permanently remove big file?
+    cd ..
+    # done with the task
+    chmod -R 777 test
+    rm -rf test
+
+What I am looking for is the sequence of commands for the users, to:
+
+- sync to the latest state (without fetching the content)
+- add new annexed file to the repository and push it
+- permanently delete annexed file
+
+There are several issues I am facing at the moment.
+I was expecting to push the new file with `git annex sync --content --no-pull`, but this command also pulls the contents of all annexd files, which I don't want. The server does not want to remove the old content. It looks like I am doing something wrong. Appreciate your suggestions about this scenario.
+
+"""]]
diff --git a/doc/tips/cloning_a_repository_privately.mdwn b/doc/tips/cloning_a_repository_privately.mdwn
new file mode 100644
index 0000000000..d88e984e6a
--- /dev/null
+++ b/doc/tips/cloning_a_repository_privately.mdwn
@@ -0,0 +1,57 @@
+Normally, when you clone a git-annex repository, and use git-annex in it,
+and then push or otherwise send changes back to origin, information gets
+committed to the git-annex branch about your clone. Things like the annexed
+files that are in it, its description, etc.
+
+If you don't want the world to know about your clone, either for privacy
+reason or only because the clone is a temporary copy of the repository,
+here's how.
+
+Recently git-annex got a new config setting, `annex.private`.
+Set it before you start using git-annex in a repository, and git-annex
+will avoid recording any information about the repository into the
+git-annex branch.
+
+	git clone ssh://... myclone
+	cd myclone
+	git config annex.private true
+	git annex init
+
+Now you can use git-annex as usual, adding files to the repository,
+getting the contents of files, etc.
+
+When you push changes back to origin, do still push the git-annex branch,
+since git-annex still uses it to record anything it needs to keep track of
+that does not involve your private repository.
+
+And be sure, when adding or editing annexed files, that you `git-annex copy`
+them to a publically accessible repository. Otherwise, to everyone else,
+there will seem to be no copies of that file availble anywhere, since they
+won't know about your private repo's copy.
+
+## private special remotes
+
+You can also make private special remotes, by using `git annex initremote
+--private`. 
+
+Like a private repository, git-annex avoids storing any information about
+a private special remote to the git-annex branch. It will only be available in
+the repository where the special remote was created. 
+
+Bear in mind that, if you lose the repository where the private special 
+remote was created, you'll lose the information git-annex needs to access
+that special remote, and that will likely mean you'll not be able to
+recover any files stored in it.
+
+## private git remotes
+
+When the git config "remote.name.private" is set, git-annex will avoid
+recording anything in the git-annex branch about the remote. This is
+set by `git-annex initremote --private`, and could also be set for
+git remotes. This could be useful, perhaps. Update this tip if you have a
+good way to use it.
+
+## where the data is actually stored
+
+The private data gets stored in .git/annex/journal-private/ rather
+than in the git-annex branch.
diff --git a/doc/tips/cloning_a_repository_privately/comment_1_f5490d034074ca80a712bdd41c307139._comment b/doc/tips/cloning_a_repository_privately/comment_1_f5490d034074ca80a712bdd41c307139._comment
new file mode 100644
index 0000000000..fb46c94c95
--- /dev/null
+++ b/doc/tips/cloning_a_repository_privately/comment_1_f5490d034074ca80a712bdd41c307139._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="What about temporary annex.private declaration?"
+ date="2023-11-07T15:49:47Z"
+ content="""
+The instructions indicate that `annex.private` should be set in the local repository configuration.
+
+However, the following approach is also a possibility:
+
+```
+❯ mkdir priv
+❯ cd priv
+❯ git init
+Initialized empty Git repository in /tmp/priv/.git/
+
+❯ git -c annex.private=1 annex init
+init  ok
+
+❯ ls .git/annex/journal-private
+uuid.log
+
+❯ cat .git/config
+[core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = false
+        logallrefupdates = true
+[annex]
+        uuid = 955373ac-6044-493e-a696-1a706437b542
+        version = 10
+[filter \"annex\"]
+        smudge = git-annex smudge -- %f
+        clean = git-annex smudge --clean -- %f
+        process = git-annex filter-process
+```
+
+It seems this repository was in private mode when it was initialized (expected). What is the implication of the switch not being permanent in the config? And by extension: what are the implications of removing the switch later in the lifetime of a repository clone?
+"""]]
diff --git a/doc/tips/cloning_a_repository_privately/comment_2_0fb78b2183932da08809d60dfc5a7374._comment b/doc/tips/cloning_a_repository_privately/comment_2_0fb78b2183932da08809d60dfc5a7374._comment
new file mode 100644
index 0000000000..7ba12def9b
--- /dev/null
+++ b/doc/tips/cloning_a_repository_privately/comment_2_0fb78b2183932da08809d60dfc5a7374._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: What about temporary annex.private declaration?"""
+ date="2023-11-29T16:50:05Z"
+ content="""
+I'm sure that the private information will not leak out from
+`.git/annex/journal-private/` into the git-annex branch
+after annex.private is unset. The design ensures this because, when
+making a change to the branch, it only reads the private journal file
+when the repository whose information is being changed is private.
+
+However, when git-annex does not have any private repositories configured,
+an optimisation makes it skip trying to read from the private journal. So
+information about those repositories, that were private, will no longer be
+read.
+
+This effect is easy to see, for example:
+
+	joey@darkstar:~/tmp/xxx>git-annex whereis
+	whereis foo (1 copy)
+	  	ff1f0bbd-7be6-45ff-8c90-fd322820b717 -- joey@darkstar:~/tmp/xxx [here]
+	ok
+	joey@darkstar:~/tmp/xxx>git config annex.private false
+	joey@darkstar:~/tmp/xxx>git-annex whereis
+	whereis foo (0 copies) failed
+	whereis: 1 failed
+
+I think this could be improved, eg it could check once if the private
+journal exists and if so read from it even when no private uuids are
+currently configured. A single stat to support this would be ok; the goal
+was to avoid checking nonexistany files on every branch read when private
+repositories are not used.
+
+Configuring any remote with annex-private can be used to work around that
+problem, that lets it read information about all previously-private repositories
+as well.
+"""]]
diff --git a/doc/tips/deleting_unwanted_files.mdwn b/doc/tips/deleting_unwanted_files.mdwn
new file mode 100644
index 0000000000..921517a0ec
--- /dev/null
+++ b/doc/tips/deleting_unwanted_files.mdwn
@@ -0,0 +1,38 @@
+It's quite hard to delete a file from a git repository once it's checked in and pushed to origin. This is normally ok, since git repositories contain mostly small files, and a good thing since losing hard work stinks. 
+
+With git-annex this changes some: Very large files can be managed with git-annex, and it's not uncommon to be done with such a file and want to delete it. So, git-annex provides a number of ways to handle this, while still trying to avoid accidental foot shooting that would lose the last copy of an important file.
+
+## the garbage collecting method
+
+In this method, you just remove annexed files whenever you want, and commit the changes. This is probably the most natural way to go.
+
+You can do this the same way you would in a regular git repository. For example, `git rm foo; git commit -m "removed foo"`. This leaves the contents of the files still in the annex, not really deleted yet.
+
+Either way, deleting files can leave some garbage lying around in either the local repository, or other repositories that contained a copy of the content of the file you deleted. Eventually you'll want to free up some disk space used by one of these repositories, and then it's time to take out the garbage.
+
+To collect the garbage, you can run `git annex unused` inside the repository which you want to slim down. That will list files stored in the annex that are not used by any git branches or tags. Followed by `git annex dropunused 1-10` to delete a range of the unused files from the annex.
+
+In recent versions of git-annex, `git annex dropunused` checks that enough other copies of a file's content exist in other repositories before deleting it, so this won't ever delete the last copy of some file. This is a good default, because these unused files are still referred to by some commits in the git history, and you might want to retain the full history of every version of a file.
+
+But, let's say you don't care about that, you only want to keep files that are in use by branches and tags. Then you can use `git annex dropunused --force` with a range of files, which will delete them even if it's the last copy.
+
+Finally, sometimes you want to remove unused files from a special remote. To accomplish this, pass `--from remotename` to the unused and dropunused commands, and they will act on
+files stored in that remote, rather than on the local repository.
+
+## let the assistant take care of it
+
+If you're using the git-annex assistant, you don't normally need to worry about this. Just delete files however you normally would. The assistant will try to migrate unused file contents away from your local repository and store them in whatever backup repositories you've set up.
+
+## delete all the copies method
+
+You have a file. You want that file to immediately vanish from the face of the earth to the best of your abilities.
+
+Note that, since git-annex deduplicates files by default, any files with
+the same content will be removed by these commands.
+
+1. `git annex drop --force file`
+2. `git annex whereis file`
+3. `git annex drop --force file --from $repo` repeat for each repository listed by the whereis command
+4. `rm file; git annex sync`
+
+Of course, if you have offline backup repositories that contain this file, you'll have to bring them online before you can drop it from them, etc.
diff --git a/doc/tips/deleting_unwanted_files/comment_1_2d3cf347c754047875a26d7f73c6fbb2._comment b/doc/tips/deleting_unwanted_files/comment_1_2d3cf347c754047875a26d7f73c6fbb2._comment
new file mode 100644
index 0000000000..5d0e709212
--- /dev/null
+++ b/doc/tips/deleting_unwanted_files/comment_1_2d3cf347c754047875a26d7f73c6fbb2._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="fbaca1610@41d03d827c5fd52d594eef456b6196c057c0944f"
+ nickname="fbaca1610"
+ avatar="http://cdn.libravatar.org/avatar/43f0d5bb6f1b878853d43f69600310cd"
+ subject="dropunused and copies"
+ date="2020-10-15T10:19:16Z"
+ content="""
+Hey there, love git annex!
+
+I have a (silly?) question: `git annex dropunused` tells me that there are not enough copies. I agree it is a good thing or at least might be in some cases.
+
+The problem is this: I have synced and used `git annex copy --to` for all my repositories and still I have unused files that `dropunused` will not delete, since it finds no copies.
+
+Am I doing something wrong here? Why are these (now) unused files not copied and therefore okay to delete locally?
+"""]]
diff --git a/doc/tips/deleting_unwanted_files/comment_2_8471758f2e02ebcfd9c015691ba9f15f._comment b/doc/tips/deleting_unwanted_files/comment_2_8471758f2e02ebcfd9c015691ba9f15f._comment
new file mode 100644
index 0000000000..9eb461de99
--- /dev/null
+++ b/doc/tips/deleting_unwanted_files/comment_2_8471758f2e02ebcfd9c015691ba9f15f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 2"
+ date="2020-10-15T14:46:33Z"
+ content="""
+`git annex sync/copy/move/etc.` don't operate on old/unused files by default. You have to use the `--all` option to operate on every file (even old/unused ones) or the `--unused` option to operate only on files found by `git annex unused`.
+"""]]
diff --git a/doc/tips/disabling_a_special_remote.mdwn b/doc/tips/disabling_a_special_remote.mdwn
new file mode 100644
index 0000000000..c14b383702
--- /dev/null
+++ b/doc/tips/disabling_a_special_remote.mdwn
@@ -0,0 +1,35 @@
+In our quest to find dumb replacements for [[todo/wishlist: 'get' queue and schedule.]] (and a more complete [[git-annex-schedule]]), we have setup a cronjob that would start and stop the assistant during certain time windows, to ensure that it would not download during prime bandwidth time.
+
+But that isn't exactly what we're looking for: we would like the assistant to continue doing its usual thing of adding and removing files, and even syncing the git branches. Just not get/move files around.
+
+One way I thought of doing this was to disable a remote locally. [[git-annex-dead]] of course comes to mind, but that applies to all repositories, so it's not an option. If the remote was in git, i could just `git remote rm origin` and `git remote add origin` and be done with it, but this is the *web* remote, so it doesn't even show up in `git remote -v`.
+
+But this doesn't work with [[special remotes]]. Another solution is
+simply to use the `remote.name.annex-ignore` configuration documented
+in the main [[git-annex]] manpage. For example, to disable the web
+remote, you would use:
+
+    git config remote.web.annex-ignore true
+
+The result would be:
+
+	joey@darkstar:~/tmp/a>git annex addurl --fast http://localhost
+	addurl localhost ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/a>git config remote.web.annex-ignore true
+	joey@darkstar:~/tmp/a>git annex get localhost
+	get localhost (not available) 
+	  Try making some of these repositories available:
+	  	00000000-0000-0000-0000-000000000001 -- web
+	
+	  (Note that these git remotes have annex-ignore set: web)
+	failed
+	git-annex: get: 1 failed
+	joey@darkstar:~/tmp/a>git config remote.web.annex-ignore false
+	joey@darkstar:~/tmp/a>git annex get localhost
+	get localhost (from web...) 
+	/home/joey/tmp/a/.g 100%[=====================>]      10  --.-KB/s   in 0s     
+	ok
+
+The assistant (probably?) needs to be restarted for those changes to
+take effect.  --[[anarcat]] and [[joeyh]].
diff --git a/doc/tips/disabling_a_special_remote/comment_1_8762ffef0024a9396979fc2586965c5d._comment b/doc/tips/disabling_a_special_remote/comment_1_8762ffef0024a9396979fc2586965c5d._comment
new file mode 100644
index 0000000000..9b2353f135
--- /dev/null
+++ b/doc/tips/disabling_a_special_remote/comment_1_8762ffef0024a9396979fc2586965c5d._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2020-09-24T18:49:02Z"
+ content="""
+Indeed -- I think having `disableremote` (to complement `initremote` and `enableremote`) would make sense.  E.g. I failed to \"disable\" it via config.
+```shell
+(git)lena:/tmp/ds000001[master]
+$> git config remote.datalad.annex-ignore true
+
+$> time SCHEMES=\"datalad-archives\" PATH=~datalad/trash/speedyannex2:$PATH git annex fsck --from datalad --fast --debug sub-01/anat/sub-01_inplaneT2.nii.gz
+[2020-09-24 14:45:48.868954] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2020-09-24 14:45:48.876348] process done ExitSuccess
+[2020-09-24 14:45:48.877109] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2020-09-24 14:45:48.892383] process done ExitSuccess
+[2020-09-24 14:45:48.893294] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..cdad4332bce8deff94e89ae35e6378ab1b87e4df\",\"--pretty=%H\",\"-n1\"]
+[2020-09-24 14:45:48.899769] process done ExitSuccess
+[2020-09-24 14:45:48.901763] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2020-09-24 14:45:48.928262] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+git-annex: there is no available git remote named \"datalad\"
+SCHEMES=\"datalad-archives\" PATH=~datalad/trash/speedyannex2:$PATH git annex    0.03s user 0.08s system 87% cpu 0.126 total
+
+$> git annex version | head
+git-annex version: 8.20200309-g07fcace
+
+```
+"""]]
diff --git a/doc/tips/disabling_a_special_remote/comment_2_325dc29b8e82595806741b0ff8dd6215._comment b/doc/tips/disabling_a_special_remote/comment_2_325dc29b8e82595806741b0ff8dd6215._comment
new file mode 100644
index 0000000000..7ddd95d74c
--- /dev/null
+++ b/doc/tips/disabling_a_special_remote/comment_2_325dc29b8e82595806741b0ff8dd6215._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Oumaima"
+ avatar="http://cdn.libravatar.org/avatar/252ac40793aa70c6113ba1d44e76bef8"
+ subject="adding disableremote"
+ date="2021-06-16T07:37:24Z"
+ content="""
+We are currently working on implementing a new special remote using Zenodo as a backend and we would like to be able to disable some remotes that we no longer aim to upload to. We also thought that adding a new disableremote command could be really useful in this case and in so many other cases and so we would like to know if it's something in the works or something that's being considered to be added.
+"""]]
diff --git a/doc/tips/disabling_a_special_remote/comment_3_6c7c92a9c5ce9cee1450117f0bab1354._comment b/doc/tips/disabling_a_special_remote/comment_3_6c7c92a9c5ce9cee1450117f0bab1354._comment
new file mode 100644
index 0000000000..869455a017
--- /dev/null
+++ b/doc/tips/disabling_a_special_remote/comment_3_6c7c92a9c5ce9cee1450117f0bab1354._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-06-16T16:02:04Z"
+ content="""
+This tip is mostly talking about the web special remote, which is unusual
+in that it's enabled by default. So there is nothing in `.git/config` about
+it.
+
+Any special remote that you set up with `initremote` or `enableremote` does
+have a section in `.git/config` same as a regular git remote would
+(just with git-annex specific configs in there). So `git remote`
+can be used to list it, and `git remote rm` will disable it.
+
+As far as setting annex-ignore goes, it prevents git-annex from using that
+remote *unless* you explicitly ask it to. @yarikoptic's example above
+sets that for a remote and then explicitly fscks it.
+"""]]
diff --git a/doc/tips/downloading_podcasts.mdwn b/doc/tips/downloading_podcasts.mdwn
new file mode 100644
index 0000000000..1b82211aeb
--- /dev/null
+++ b/doc/tips/downloading_podcasts.mdwn
@@ -0,0 +1,94 @@
+You can use git-annex as a podcatcher, to download podcast contents.
+No additional software is required, but your git-annex must be built
+with the Feeds feature (run `git annex version` to check).
+
+All you need to do is put something like this in a cron job:
+
+`cd somerepo && git annex importfeed http://url/to/podcast http://other/podcast/url`
+
+This downloads the urls, and parses them as RSS, Atom, or RDF feeds.
+All enclosures are downloaded and added to the repository, the same as if you
+had manually run `git annex addurl` on each of them.
+
+git-annex will avoid downloading a file from a feed if its url has already
+been stored in the repository before. So once a file is downloaded,
+you can move it around, delete it, `git annex drop` its content, etc,
+and it will not be downloaded again by repeated runs of
+`git annex importfeed`. Just how a podcatcher should behave.  (git-annex versions 
+since 2015 also tracks the podcast `guid` values, as metadata, to help avoid 
+duplication if the media file url changes; use `git annex metadata ...` to inspect.)
+
+## templates
+
+To control the filenames used for items downloaded from a feed,
+there's a --template option. The default is
+`--template='${feedtitle}/${itemtitle}${extension}'`
+
+Other available template variables:  
+feedauthor, itemauthor, itemsummary, itemdescription, itemrights, itemid,
+itempubdate, author, title.
+
+## catching up
+
+To catch up on a feed without downloading its contents,
+use `git annex importfeed --relaxed`, and delete the symlinks it creates.
+Next time you run `git annex addurl` it will only fetch any new items.
+
+## fast mode
+
+To add a feed without downloading its contents right now,
+use `git annex importfeed --fast`. Then you can use `git annex get` as
+usual to download the content of an item.
+
+## storing the podcast list in git
+
+You can check the list of podcast urls into git right next to the
+files it downloads. Just make a file named feeds and add one podcast url
+per line.
+
+Then you can run git-annex on all the feeds:
+
+`xargs git-annex importfeed < feeds`
+
+## recreating lost episodes
+
+If for some reason git-annex refuses to download files you are certain are in the podcast, it is quite possible it is because they have already been downloaded. In any case, you can use `--force` to redownload them:
+
+`git-annex importfeed --force http://example.com/feed`
+
+## distributed podcatching
+
+A nice benefit of using git-annex as a podcatcher is that you can
+run `git annex importfeed` on the same url in different clones
+of a repository, and `git annex sync` will sync it all up.
+
+## centralized podcatching
+
+You can also have a designated machine which always fetches all podcstas
+to local disk and stores them. That way, you can archive podcasts with
+time-delayed deletion of upstream content. You can also work around slow
+downloads upstream by podcatching to a server with ample bandwidth or work
+around a slow local Internet connection by podcatching to your home server
+and transferring to your laptop on demand.
+
+## youtube channels
+
+You can also use `git annex importfeed` on youtube channels.
+It will use yt-dlp to automatically download the videos.
+
+You can either use `git-annex importfeed --scrape` with the url to the
+channel, or you can find the RSS feed for the channel, and
+`git-annex importfeed` that url (without `--scrape`).
+
+Use of yt-dlp is disabled by default as it can be a security risk. 
+See the documentation of annex.security.allowed-ip-addresses
+in [[git-annex]] for details.)
+
+## metadata
+
+As well as storing the urls for items imported from a feed, git-annex can
+store additional [[metadata]], like the author, and itemdescription.
+This can then be looked up later, used in [[metadata_driven_views]], etc.
+
+To make all available metadata from the feed be stored:
+`git config annex.genmetadata true`
diff --git a/doc/tips/downloading_podcasts/comment_10_4d4f6c22070b58918ee8d34c5e7290ad._comment b/doc/tips/downloading_podcasts/comment_10_4d4f6c22070b58918ee8d34c5e7290ad._comment
new file mode 100644
index 0000000000..3bf5afe681
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_10_4d4f6c22070b58918ee8d34c5e7290ad._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 10"
+ date="2013-08-05T16:47:30Z"
+ content="""
+`cabal install feed` should get the necessary library installed so that git-annex will build with feeds support.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_11_d8d77048c7e2524968c188e1ad517873._comment b/doc/tips/downloading_podcasts/comment_11_d8d77048c7e2524968c188e1ad517873._comment
new file mode 100644
index 0000000000..fd34599265
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_11_d8d77048c7e2524968c188e1ad517873._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="http://a-or-b.myopenid.com/"
+ ip="220.244.41.108"
+ subject="comment 11"
+ date="2013-08-06T04:20:16Z"
+ content="""
+    $ cabal install feed
+    Resolving dependencies...
+    All the requested packages are already installed:
+    feed-0.3.9.1
+    Use --reinstall if you want to reinstall anyway.
+
+Then I reinstalled `git-annex` but it still doesn't find the feeds flag.
+
+    $ git annex version
+    git-annex version: 4.20130802
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS
+
+Do I need to do something like:
+
+    cabal install git-annex --bindir=$HOME/bin -f\"-assistant -webapp -webdav -pairing -xmpp -dns -feed\"
+
+...but what are the default flags to include in addition to `-feed`
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_12_0859317471b43c88744dd3df95c879f7._comment b/doc/tips/downloading_podcasts/comment_12_0859317471b43c88744dd3df95c879f7._comment
new file mode 100644
index 0000000000..e75a44a8cd
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_12_0859317471b43c88744dd3df95c879f7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 12"
+ date="2013-08-06T04:24:10Z"
+ content="""
+-f-Feed will disable the feature. -fFeed will try to force it on.
+
+You can probably work out what's going wrong using cabal install -v3
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_13_e8c3c97282d17e2a1d47fb9d5e2b2f7b._comment b/doc/tips/downloading_podcasts/comment_13_e8c3c97282d17e2a1d47fb9d5e2b2f7b._comment
new file mode 100644
index 0000000000..8d12428185
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_13_e8c3c97282d17e2a1d47fb9d5e2b2f7b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://a-or-b.myopenid.com/"
+ ip="220.244.41.108"
+ subject="comment 13"
+ date="2013-08-06T05:42:45Z"
+ content="""
+So I ran `cabal install -v3` and looked at the output, 
+
+    Flags chosen: feed=True, tdfa=True, testsuite=True, android=False,
+    production=True, dns=True, xmpp=True, pairing=True, webapp=True,
+    assistant=True, dbus=True, inotify=True, webdav=True, s3=True
+
+This looks like feed should be on.
+
+There doesn't appear to be any errors in the compile either.
+
+Is it as simple as a bug where this flag just doesn't show in the `git annex version` command?
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_14_05a3694052de36848fbbad6eeeada895._comment b/doc/tips/downloading_podcasts/comment_14_05a3694052de36848fbbad6eeeada895._comment
new file mode 100644
index 0000000000..4bc831f7f1
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_14_05a3694052de36848fbbad6eeeada895._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 14"
+ date="2013-08-07T16:03:12Z"
+ content="""
+Yes, it did turn out to be as simple as my having forgotten that I have to manually add features to the version list.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_15_21028bed8858c2dae1ac9c2d014fd2a1._comment b/doc/tips/downloading_podcasts/comment_15_21028bed8858c2dae1ac9c2d014fd2a1._comment
new file mode 100644
index 0000000000..0f998d0669
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_15_21028bed8858c2dae1ac9c2d014fd2a1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://23.gs/"
+ ip="46.165.197.5"
+ subject="No file extension?"
+ date="2013-08-12T13:21:50Z"
+ content="""
+It seems git-annex is a bit overzealous when sanitizing the file extension, currently I get: \"Nerdkunde/Let_s_go_to_the_D_M_C_A_m4a\" from http://www.nerdkunde.de/episodes.m4a.rss with the default template and only \"Nerdkunde/Let_s_go_to_the_D_M_C_A._m4a\" if I add the \".\" in the template myself...
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_16_4869fb5c9f896acc477c44de06c36ca7._comment b/doc/tips/downloading_podcasts/comment_16_4869fb5c9f896acc477c44de06c36ca7._comment
new file mode 100644
index 0000000000..4419d02a81
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_16_4869fb5c9f896acc477c44de06c36ca7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="arand"
+ ip="130.243.226.21"
+ subject="comment 16"
+ date="2013-08-12T13:32:46Z"
+ content="""
+The filename extension is a known issue and already fixed in the development version, see <http://git-annex.branchable.com/bugs/importfeed_uses___34____95__foo__34___as_extension/>
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_17_2e278ff200c1c15efd27c46a3e0aed40._comment b/doc/tips/downloading_podcasts/comment_17_2e278ff200c1c15efd27c46a3e0aed40._comment
new file mode 100644
index 0000000000..bc49e5dd07
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_17_2e278ff200c1c15efd27c46a3e0aed40._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlpKmTa1OPwy5Jk24pOoD8Vlo2jahzTPnw"
+ nickname="Stephen"
+ subject="rss authentication"
+ date="2013-08-13T13:32:52Z"
+ content="""
+If a podcast requires authentication, is there a way to pass credentials through? I tried `http://user:pass@site.com/rss.xml` but it didn't work.
+
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_18_382f2b970738d9b1af577955c3083e90._comment b/doc/tips/downloading_podcasts/comment_18_382f2b970738d9b1af577955c3083e90._comment
new file mode 100644
index 0000000000..9e32443159
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_18_382f2b970738d9b1af577955c3083e90._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="--fast and --relaxed"
+ date="2013-08-16T07:27:59Z"
+ content="""
+Hi,
+
+the explanations to --fast and --relaxed on this page could be extended a bit. I looked it up in the man page, but it is not yet clear to me when I would use one or the other with feeds. Also, does “Next time you run git annex addurl it will only fetch any new items.” really only apply to --relaxed, and not --fast?
+
+Furthermore, it would be good if there were a template variable `itemnum` that I can use to ensure that `ls` prints the casts in the right order, even when the titles of the items are not helpful.
+
+Greetings,
+Joachim
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_19_f76fc6835e5787b0156380bf09fd81ca._comment b/doc/tips/downloading_podcasts/comment_19_f76fc6835e5787b0156380bf09fd81ca._comment
new file mode 100644
index 0000000000..41313a87d1
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_19_f76fc6835e5787b0156380bf09fd81ca._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 19"
+ date="2013-08-22T15:25:02Z"
+ content="""
+I would expect user:pass@site.com to work if the site is using http basic auth. `importfeed` just runs `wget` (or `curl`) to do all downloads, and wget's documentation says that works. It also says you can use ~/.netrc to store the password for a site.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_1_f04bc32a34baeeffcd691e9f7cce0230._comment b/doc/tips/downloading_podcasts/comment_1_f04bc32a34baeeffcd691e9f7cce0230._comment
new file mode 100644
index 0000000000..014fe3f50e
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_1_f04bc32a34baeeffcd691e9f7cce0230._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="ckeen"
+ ip="79.249.110.228"
+ subject="Filename too long"
+ date="2013-07-30T14:39:44Z"
+ content="""
+It seems that some of my feeds get stored into keys that generate a too long filename:
+
+    podcasts/.git/annex/tmp/b1f_325_URL-s143660317--http&c%%feedproxy.google.com%~r%mixotic%~5%urTIRWQK2OQ%Mixotic__258__-__Michael__Miller__-__Galactic__Technolgies.mp3.log.web:
+    openBinaryFile: invalid argument (File name too long)
+
+Is there a way to work around this?
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_20_65ebf3a3bbf0a2aebd2b69640b757e16._comment b/doc/tips/downloading_podcasts/comment_20_65ebf3a3bbf0a2aebd2b69640b757e16._comment
new file mode 100644
index 0000000000..6060be6557
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_20_65ebf3a3bbf0a2aebd2b69640b757e16._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 20"
+ date="2013-08-22T15:29:11Z"
+ content="""
+The git-annex man page has a bit more to say about --relaxed and --fast. Their behavior when used with `importfeed` is the same as with `addurl`.
+
+If the podcast feed provides an `itemid`, you can use that in the filename template. I don't know how common that is. Due to the way `importfeed` works, it cannot keep track of eg, an incrementing item number itself.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_21_98a1dacc8d264ff31801e6c5c5f2612d._comment b/doc/tips/downloading_podcasts/comment_21_98a1dacc8d264ff31801e6c5c5f2612d._comment
new file mode 100644
index 0000000000..eebc00ad96
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_21_98a1dacc8d264ff31801e6c5c5f2612d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Sazius"
+ ip="62.78.213.233"
+ subject="comment 21"
+ date="2014-07-01T20:52:06Z"
+ content="""
+For some podcast feeds I typically wish to view the description of the show before I decide to download it or not. Is there some way to perform that use case using git annex? I know `itemdescription` is something I can include in the template for the filename, but the descriptions can be really long... doesn't seem very elegant to have that in the file name. Could the description for example be included as metadata of the item?
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_22_00cc7a2fb936d7ea3d5d3764a1637663._comment b/doc/tips/downloading_podcasts/comment_22_00cc7a2fb936d7ea3d5d3764a1637663._comment
new file mode 100644
index 0000000000..2fba1b57dd
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_22_00cc7a2fb936d7ea3d5d3764a1637663._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="metadata"
+ date="2014-07-03T18:25:32Z"
+ content="""
+Good idea, Sazius!
+
+I've made importfeed store the metadata, as long as annex.genmetadata is set in .git/config.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_23_62603cda8e581a2eb2cc799dffe8a740._comment b/doc/tips/downloading_podcasts/comment_23_62603cda8e581a2eb2cc799dffe8a740._comment
new file mode 100644
index 0000000000..13909c27cd
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_23_62603cda8e581a2eb2cc799dffe8a740._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="ewen"
+ subject="itempubdate"
+ date="2015-01-03T22:01:37Z"
+ content="""
+Using a `--template='${feedtitle}/${itempubdate}-${itemtitle}${extension}'` with a libsyn RSS feed (eg, [Poly Weekly](http://polyweekly.libsyn.com/rss)), I found that `itempubdate` was expanding to \"none\", even though there is a date with each entry in the RSS, eg,
+
+    <pubDate>Fri, 26 Dec 2014 15:25:38 +0000</pubDate>
+
+Maybe the date string cannot be parsed?  But it does look like a fairly typical datestamp to me.  If the cause is the mixed-case in the tag, could `pubDate` be supported in addition to `pubdate`?  (AFAICT [`pubDate` is the standardised mix of lower/upper case](http://validator.w3.org/feed/docs/rss2.html), but maybe not the most common, in which case supporting both `pubDate` and `pubdate` might help?)  As seen with `git-annex version: 5.20141024~bpo70+1`, installed from Debian Backports; AFAICT it's still the latest release to make it to backports.
+
+For now I'm just omitting \"itempubdate\" from my template.
+
+Ewen
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_24_e75af243654d15bc7b917fcd888bcf2f._comment b/doc/tips/downloading_podcasts/comment_24_e75af243654d15bc7b917fcd888bcf2f._comment
new file mode 100644
index 0000000000..25deb97b41
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_24_e75af243654d15bc7b917fcd888bcf2f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""pubDate"""
+ date="2015-01-05T22:55:06Z"
+ content="""
+@ewen, I tested that feed and it is able to get the pubDate from it and
+parses it ok.
+
+Most likely, your version of git-annex is not built with a new enough
+version of the haskell feed library. Version 0.3.9 or newer is needed to be
+able to extract pubdates. For example, Debian stable doesn't have a new
+enough version.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_25_2ee88c3375eca23fe34cab65df1e7aeb._comment b/doc/tips/downloading_podcasts/comment_25_2ee88c3375eca23fe34cab65df1e7aeb._comment
new file mode 100644
index 0000000000..4f39988a9c
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_25_2ee88c3375eca23fe34cab65df1e7aeb._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="Track GUIDs to avoid duplicate downloads"
+ date="2017-03-21T08:59:59Z"
+ content="""
+While tracking podcast media URLs usually works to avoid duplicate downloads, when it fails it usually fails spectacularly. In particular if a podcast feed decides to update all the URLs (for old and new podcasts) to use a different URL scheme, then suddenly that looks like a huge volume of new URLs, and all of them get downloaded again -- even if the content has actually already been retrieved from a different URL (ie, older URL scheme). For instance the `acast.com` service has changed their URL scheme a couple of times in the last 1-2 years, rewriting all the historical URLs, so I have three copies of many of the episodes on podcasts on their service :-( (Many downloaded; some skipped once I caught the bulk download and stopped it/reran with `--fast` or `--relaxed` to make placeholders instead. `acast.com` seem to have managed to cause even more confusion by rewriting many of the older `mp3` files with new `id3` tags, thus changing the file size/hashes -- it definitely made cleaning up more complicated.)
+
+Some (all?) podcast feeds also have a `guid` field, which specifies what should be a unique per-episode and unchanging, that other podcatchers use to track \"seen this\" content.  In theory that `guid` value should be stable even across media URL changes -- at least if it isn't, then a podcaster changing the `guid` *and* media URL will almost certainly induce re-downloads in most podcatchers, and thus hopefully realise early on (eg, during testing) rather than in production.
+
+Can `git-annex` be extended to track the `guid` values as well as the filenames, so `git annex importfeed` can avoid downloading episodes where it has already processed that `guid`, and instead just add the newly listed url as an alternate web URL for that specific episode (which has been my manual work around).  Perhaps the episode `guid` could be stored as additional metadata, along with some sort of feed unique ID (link?), and then an index built/consulted when `importfeed` runs (although that \"feed unique ID\" would probably also have to be updatable by the user, to cope with \"the feed URL has now changed from `http://` to `https://` which also seems to be happening a bunch at present.)
+
+Ewen
+
+PS: Apologies for duplicate partial comment; I think my browser decided some key combination meant \"do default form action\", which is post -- and I wasn't finished writing.  I couldn't see a way to edit the comment, hence deleting/readding.
+
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_26_a69b4c033d85406675bb70e6996590ce._comment b/doc/tips/downloading_podcasts/comment_26_a69b4c033d85406675bb70e6996590ce._comment
new file mode 100644
index 0000000000..c884f0569b
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_26_a69b4c033d85406675bb70e6996590ce._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 26"""
+ date="2017-03-21T17:28:27Z"
+ content="""
+@ewen importfeed already tracks guids, since 2015. Relevant commit is
+[[!commit f95a8c867223b2e17d036d0d3377bf0fc9d3adff]]
+
+You may well have an
+older version of git-annex that didn't do that. But there are probably also
+feeds that lack a useful guid, or that even make a change that changes the
+guid of an existing item.
+
+With `git annex metadata`, you can see the `itemid` which is where the guid
+is stored.
+
+PS, please post in [[todo]] when you have a request..
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_27_e343aeda7c16c834599fb3caab2a51a2._comment b/doc/tips/downloading_podcasts/comment_27_e343aeda7c16c834599fb3caab2a51a2._comment
new file mode 100644
index 0000000000..ec2aef02aa
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_27_e343aeda7c16c834599fb3caab2a51a2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="Tracking GUIDs"
+ date="2017-03-21T21:46:27Z"
+ content="""
+@joey - thanks, that's prompt feature request fulfilment :-)
+
+Looking more closely at the duplicates, it turns out that not *everything* got duplicated, just the \"older\" episodes.  It turns out the newer episodes do have `guid` values saved (as `itemid` in the metadata) and the older episodes do not.  I think this is most likely because I *was* running a fairly old git-annex until about October 2016, on a fairly old OS install, but then upgraded to a more recent one (now about 6 months old) which does track them.  My assumption (without checking every file) is the episodes downloaded before October 2016 are ones that got duplicated.
+
+I've edited the main page and added a note that GUIDs are tracked in versions since 2015, since I didn't obviously find that listed anywhere before.
+
+Ewen
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_28_f57a89a32a55dfae0dfa237a8981a667._comment b/doc/tips/downloading_podcasts/comment_28_f57a89a32a55dfae0dfa237a8981a667._comment
new file mode 100644
index 0000000000..85fada6df0
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_28_f57a89a32a55dfae0dfa237a8981a667._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="howto importfeed youtube playlists (not entire channels)"
+ date="2022-09-01T19:26:20Z"
+ content="""
+e.g. channel [https://www.youtube.com/channel/UCzLPuKXYJxfwK6Vg7zuqjZQ](https://www.youtube.com/channel/UCzLPuKXYJxfwK6Vg7zuqjZQ) has [two playlists](https://www.youtube.com/channel/UCzLPuKXYJxfwK6Vg7zuqjZQ/playlists), e.g. one pointed to by [https://www.youtube.com/playlist?list=PLIa3r7AIaTikMGfiZlIuArLujETxVfOKP](https://www.youtube.com/playlist?list=PLIa3r7AIaTikMGfiZlIuArLujETxVfOKP).  I had a question \"What would be the importfeed url for that one?\".  Google into [this youtube video](https://www.youtube.com/watch?v=WmbPhkW8PHQ) and the fun is that it is the same approach but need `playlist_id` instead of `channel_id` in the `https://www.youtube.com/playlist?<query>` URL.  My immediate problem was that it fetched only last videos... will need to resort to [manual treat](http://git-annex.branchable.com/forum/importfeed_does_not_work_with_youtube_anymore/#comment-e8e0862d6c52de0e9ce61403cdfb1189) or alike to feed the rest
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_2_a9a98cad7358d16792853a2ee413fe6c._comment b/doc/tips/downloading_podcasts/comment_2_a9a98cad7358d16792853a2ee413fe6c._comment
new file mode 100644
index 0000000000..f8ba1155cb
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_2_a9a98cad7358d16792853a2ee413fe6c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 2"
+ date="2013-07-30T17:16:07Z"
+ content="""
+@ckeen You seem to be using a filesystem that does not support filenames 150 characters long. This is unusual -- even windows and android can support a filename up to 255 characters in length. `git-annex addurl` already deals with this sort of problem by limiting the filename to 255 characters. If you'd like to file a bug report with details about your system, I can try to make git-annex support its limitations, I suppose.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_3_5a8068a5cb0fd864581157a3aa5d1113._comment b/doc/tips/downloading_podcasts/comment_3_5a8068a5cb0fd864581157a3aa5d1113._comment
new file mode 100644
index 0000000000..7e5633865a
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_3_5a8068a5cb0fd864581157a3aa5d1113._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="Great stuff!"
+ date="2013-07-30T21:21:57Z"
+ content="""
+Looking forward to seeing it in Debian unstable; where it will definitely replace my hpodder setup.
+
+I guess there is no easy way to re-use the files already downloaded with hpodder? At first I thought that `git annex importfeed --relaxed` followed by adding the files to the git annex would work, but `importfeed` stores URLs, not content-based hashes, so it wouldn’t match up.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_4_e7072a9da30b4c4b4c526013144238d4._comment b/doc/tips/downloading_podcasts/comment_4_e7072a9da30b4c4b4c526013144238d4._comment
new file mode 100644
index 0000000000..1693c4bdcf
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_4_e7072a9da30b4c4b4c526013144238d4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="comment 4"
+ date="2013-07-30T21:29:50Z"
+ content="""
+@nomeata, well, you can, but it has to download the files again.
+
+When run without --fast, `importfeed` does use content based hashes, so if you run it in a temporary directory, it will download the content redundantly, hash it and see it's the same, and add the url to that hash. You can then delete the temporary directory, and the files hpodder had downloaded will have the url attached to them now. I don't know if this really buys you anything over deleting the hpodder files and starting over though.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_5_79b3f8d678ac9f67df4c0cd649657283._comment b/doc/tips/downloading_podcasts/comment_5_79b3f8d678ac9f67df4c0cd649657283._comment
new file mode 100644
index 0000000000..f5df9910f3
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_5_79b3f8d678ac9f67df4c0cd649657283._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ckeen"
+ ip="79.249.110.228"
+ subject="Force a reload of a feed?"
+ date="2013-07-31T10:35:50Z"
+ content="""
+Currently I have my podcasts imported with --fast. For some reason there are podcast episodes missing. This has been done propably during my period of toying with the feature. If I retry on a clean annex I see all episodes. My suspicion is that git-annex has been interrupted during downloading a feed but now somehow thinks it's already there. How can I debug this situation and/or force git annex to retry all the links in a feed?
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_6_35106fee5458bdd5c21868fbc49d3616._comment b/doc/tips/downloading_podcasts/comment_6_35106fee5458bdd5c21868fbc49d3616._comment
new file mode 100644
index 0000000000..caeca01511
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_6_35106fee5458bdd5c21868fbc49d3616._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.21"
+ subject="use the force"
+ date="2013-07-31T16:20:39Z"
+ content="""
+The only way it can skip downloading a file is if its url has already been seen before. Perhaps you deleted them?
+
+I've made `importfeed --force` re-download files it's seen before.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_7_ceb16498b7aadbf04a27acd5d6561d46._comment b/doc/tips/downloading_podcasts/comment_7_ceb16498b7aadbf04a27acd5d6561d46._comment
new file mode 100644
index 0000000000..ac2c89a366
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_7_ceb16498b7aadbf04a27acd5d6561d46._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ckeen"
+ ip="78.108.63.46"
+ subject="--force reload all URLs"
+ date="2013-08-01T09:47:34Z"
+ content="""
+Is it intentionally saving URLs with a prefixed 2_? I have sorted out all missing URLs and renamed it, so no harm done, but it has been a bit of a hassle to get there.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_8_147397603f0b3fdb42ca387d1da7c5ef._comment b/doc/tips/downloading_podcasts/comment_8_147397603f0b3fdb42ca387d1da7c5ef._comment
new file mode 100644
index 0000000000..0995d80752
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_8_147397603f0b3fdb42ca387d1da7c5ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.145"
+ subject="comment 8"
+ date="2013-08-01T16:05:10Z"
+ content="""
+I've now made importfeed --force a bit smarter about reusing existing files.
+"""]]
diff --git a/doc/tips/downloading_podcasts/comment_9_6a26a6cc7683d38fae0f23c5a52d1e23._comment b/doc/tips/downloading_podcasts/comment_9_6a26a6cc7683d38fae0f23c5a52d1e23._comment
new file mode 100644
index 0000000000..3045c98949
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_9_6a26a6cc7683d38fae0f23c5a52d1e23._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="http://a-or-b.myopenid.com/"
+ ip="220.244.41.108"
+ subject="How do I switch on the 'feeds' feature?"
+ date="2013-08-05T04:52:41Z"
+ content="""
+Joey - your initial post said:
+
+    git-annex must be built with the Feeds feature (run git annex version to check).
+
+...but how do I actually switch on the feeds feature?
+
+I install git-annex from cabal, so I do
+
+    cabal update
+    cabal install git-annex
+
+which I did this morning and now `git annex version` gives me:
+
+    git-annex version: 4.20130802
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS
+
+So it is the latest version, but without Feeds.  :-(
+"""]]
diff --git a/doc/tips/dropboxannex.mdwn b/doc/tips/dropboxannex.mdwn
new file mode 100644
index 0000000000..5a6b4baa5c
--- /dev/null
+++ b/doc/tips/dropboxannex.mdwn
@@ -0,0 +1,12 @@
+For using Dropbox as a special remote, there are currently several choices:
+
+* rclone supports the Dropbox API,
+  so the [[rclone_special_remote|special_remotes/rclone]] can be used.  
+  (Actively maintained)
+* Alternatively, there are some dedicated special remotes:
+  * <https://github.com/TobiasTheViking/dropboxannex>  
+    (Last updated 2014)
+  * <https://pypi.org/project/git-annex-remote-dbx/>
+
+At this time it's not clear which is better, so if you find one works
+best, please comment below.
diff --git a/doc/tips/dumb_metadata_extraction_from_xbmc.mdwn b/doc/tips/dumb_metadata_extraction_from_xbmc.mdwn
new file mode 100644
index 0000000000..e3611ec30b
--- /dev/null
+++ b/doc/tips/dumb_metadata_extraction_from_xbmc.mdwn
@@ -0,0 +1,29 @@
+I wanted to get the list of movies I haven't seen yet in XBMC, and i'm lazy. So I'll use [[metadata]] to be able to extract those movies only, for the road for example.
+
+First I fiddled around with shell scripts to extract the list of those films, which in XBMC-speak means that have a `NULL playCount`. Since there are two ways that XMBC can represent those files (in a `stack://` if there is multiple files for the movie or not), there are two scripts. For "stacked" movies:
+
+    echo 'SELECT files.strFileName FROM movie JOIN files ON files.idFile=movie.idFile JOIN path ON path.idPath=files.idPath WHERE playCount IS NULL AND files.strFileName LIKE "stack://%";' | sqlite3 /home/video/.xbmc/userdata/Database/MyVideos75.db | sed "s#stack://##;s/, /\n/g" | sed "s#/home/media/video/##"
+
+And the rest:
+
+    echo 'SELECT path.strPath || files.strFileName FROM movie JOIN files ON files.idFile=movie.idFile JOIN path ON path.idPath=files.idPath WHERE playCount IS NULL AND files.strFileName NOT LIKE "stack://%";' | sqlite3 /home/video/.xbmc/userdata/Database/MyVideos75.db | sed "s#/home/media/video/##"
+
+Also notice how I remove the absolute prefix for the annex so that i can refer to files as a relative path.
+
+So this quick and dirty hack could have been used to mark files as "new". Unfortunately, this won't unmark them when the playcount increases. So instead I think this should be a field, and we need to extract the playcount. Play around with shell scripting enough to get sick, get back into bad perl habits and you'll end up with this nasty script: [[git-annex-xbmc-playcount.pl]].
+
+After the script is ran, you can sort the files by play count with:
+
+    git annex view "playCount=*"
+
+Or just show the files that haven't been played yet:
+
+    git annex view playCount=0
+
+Use `git checkout master` to reset the view. Note that the above will flatten the tree hierarchy, which you may not want. Try this in that case:
+
+    git annex view playCount=0 films/=*
+
+For more information, see [[tips/metadata_driven_views/]].
+
+-- [[anarcat]]
diff --git a/doc/tips/dumb_metadata_extraction_from_xbmc/git-annex-xbmc-playcount.pl b/doc/tips/dumb_metadata_extraction_from_xbmc/git-annex-xbmc-playcount.pl
new file mode 100644
index 0000000000..56f902cb03
--- /dev/null
+++ b/doc/tips/dumb_metadata_extraction_from_xbmc/git-annex-xbmc-playcount.pl
@@ -0,0 +1,227 @@
+#! /usr/bin/perl -w
+
+use Getopt::Long;
+use Pod::Usage;
+
+my $help = 0;
+my $usage = 0;
+my $dryrun = 0;
+my $verbose = 0;
+my $path = '';
+my $annex = '';
+my $home = $ENV{'HOME'};
+
+sub main() {
+    checkargs();
+    if (!$path) {
+        $path = $home . '/.xbmc/userdata/Database';
+    }
+    print("# checking XBMC directory '$path'\n") if ($verbose);
+    $dbpath = finddb($path);
+    if (!$dbpath) {
+        pod2usage("$0: can't find a XBMC database in '$path'.");
+    }
+    print("# using database '$dbpath'\n") if ($verbose);
+    checkdb();
+}
+
+# list videos database, find the latest one
+# modified version of
+# http://stackoverflow.com/questions/4651092/getting-the-list-of-files-sorted-by-modification-date-in-perl
+sub finddb($) {
+    my $path = shift(@_);
+    opendir my($dirh), $path or die "can't opendir $path: $!";
+    my @flist = sort {  -M $a <=> -M $b } # Sort by modification time
+        map  { "$path/$_" } # We need full paths for sorting
+        grep { /^MyVideos.*\.db$/ }
+        readdir $dirh;
+    closedir $dirh;
+    if ($#flist > 0) {
+        return $flist[0];
+    }
+    else {
+        return 0;
+    }
+}
+
+sub checkargs() {
+    pod2usage(1) if $help;
+    pod2usage(-exitval => 0, -verbose => 2) if $usage;
+
+    GetOptions('h|?' => \$help,
+               'help|usage' => \$usage,
+               # we want to operate on relative links, so set this to
+               # the common annex to the git annex repo
+               'annex=s' => \$annex,
+               'path=s' => \$path,
+               'home=s' => \$home,
+               'dryrun|n' => \$dryrun,
+               'verbose|v' => \$verbose,
+        )
+        or die("Error parsing commandline\n");
+}
+
+sub checkdb() {
+    my @lines = `echo 'SELECT playCount, path.strPath, files.strFileName FROM movie JOIN files ON files.idFile=movie.idFile JOIN path ON path.idPath=files.idPath;' | sqlite3 $dbpath`;
+    print "# finding files...\n" if $verbose;
+    for (@lines) {
+        my ($count, $dir, $file) = split /\|/;
+        chomp $file;
+        # empty or non-numeric count is zero
+        if ($count !~ /[0-9]/) {
+            $count = 0;
+        }
+        print "# $dir/$file\n" if $verbose;
+        if ($file =~ s#stack://##) {
+            for (split /,/, $file) {
+                s/$annex//;
+                s/^ //;
+                s/ $//;
+                my @cmd = (qw(git annex metadata --set), "playCount=$count", $_);
+                if ($dryrun) {
+                    print join(' ', @cmd) . "\n";
+                }
+                else {
+                    system(@cmd);
+                }
+            }
+        }
+        else {
+            $dir =~ s/$annex//;
+            my @cmd = (qw(git annex metadata --set), "playCount=$count", "$dir$file");
+            if ($dryrun) {
+                print join(' ', @cmd) . "\n";
+            }
+            else {
+                system(@cmd);
+            }
+        }
+    }
+}
+
+main();
+
+__END__
+=encoding utf8
+
+=head1 NAME
+
+git-annex-xbmc-playcount - register XBMC playcounts as git-annex metadata
+
+=head1 SYNOPSIS
+
+git-annex-xbmc-playcount [--path .xbmc/userdata/Database]
+
+ Options:
+  -h         short usage
+  --help     complete help
+  --dryrun, -n do nothing and show the commands that would be ran
+  --annex    path to the git-annex repo
+  --home     the home directory where the .xbmc directory is located
+  --path     the location of the Database directory of XBMC, overrides --home
+  --verbose  show interaction details with the database
+
+=head1 DESCRIPTION
+
+This program will look into the XBMC database for the "playcount"
+field to register that number as metadata in the git-annex repository.
+
+=head1 OPTIONS
+
+=over 8
+
+=item B<--dryrun>
+
+Do nothing but show all the steps that would be ran. The output can be
+piped through a POSIX shell after inspection. B<-n> is an alias of
+this command. Example:
+
+    git-annex-xbmc-playcount -n | tee runme
+    # inspect the output
+    sh < runme
+
+=item B<--annex>
+
+This option allows the user to specify the root of the git-annex
+repository, which is then stripped off the paths found in the XBMC
+database.
+
+=item B<--home>
+
+Home of the user running XBMC. If not specified, defaults to the $HOME
+environment variables. The script will look into
+B<$home/.xbmc/userdata/Database> for a file matching
+B<^MyVideos.*\.db$> and will fail if none is found.
+
+=item B<--path>
+
+Manually specify the path to B<.xbmc/userdata/Database>. This
+overrides B<--home>.
+
+Note that this doesn't point directly to the database itself, because
+there are usually many database files and we want to automatically
+find the latest. This may be a stupid limitation.
+
+=item B<--verbose>
+
+Show more information about path discovery. Doesn't obstruct
+B<--dryrun> output because lines are prefixed with C<#>.
+
+=back
+
+=head1 EXAMPLES
+
+You have a git annex in B</srv/video> and XBMC is ran as the
+B<video> user and you want to be cautious:
+
+    $ ./git-annex-xbmc-playcount.pl --home /home/video/ -n --annex /srv/video/ | tee set-metadata
+    git annex metadata --set playCount=0 films/Animal.Farm.1954.DVDRip.DivX-MDX.avi
+
+This looks about right, set the metadata:
+
+    $ git annex metadata --set playCount=0 films/Animal.Farm.1954.DVDRip.DivX-MDX.avi
+    metadata films/Animal.Farm.1954.DVDRip.DivX-MDX.avi
+      lastchanged=2014-10-04@22-17-42
+      playCount=0
+      playCount-lastchanged=2014-10-04@22-17-42
+    ok
+    (Recording state in git...)
+
+=head1 ENVIRONMENT
+
+B<$HOME> is looked into to find the B<.xbmc> home directory if none of
+B<--home> or B<--path> is specified.
+
+=head1 FILES
+
+=over 8
+
+=item B<$HOME/.xbmc/userdata/Database/MyVideos.*\.db>
+
+This is where we assume the SQLite database of videos XBMC uses is
+stored.
+
+=back
+
+=head1 BUGS
+
+If there are pipes (C<|>) in filenames, the script may fail to find
+the files properly. We would need to rewrite the database code to use
+B<DBD::SQLite>(3pm) instead of a pipe to B<sqlite3>(1).
+
+=head1 LIMITATIONS
+
+It took longer writing this help than writing the stupid script.
+
+The script will not tag files not yet detected by XBMC.
+
+The script is not incremental, so it will repeatedly add the same
+counts to files it has already found.
+
+=head1 SEE ALSO
+
+B<git-annex>(1), B<xbmc>(1)
+
+=head1 AUTHOR
+
+Written by Antoine Beaupré <anarcat@debian.org>
diff --git a/doc/tips/emacs_integration.mdwn b/doc/tips/emacs_integration.mdwn
new file mode 100644
index 0000000000..b81244fb15
--- /dev/null
+++ b/doc/tips/emacs_integration.mdwn
@@ -0,0 +1,25 @@
+bergey has developed an emacs mode for browsing git-annex repositories,
+dired style.
+
+<https://gitorious.org/emacs-contrib/annex-mode>
+
+Locally available files are colored differently, and pressing g runs
+`git annex get` on the file at point.
+
+----
+
+John Wiegley has developed a brand new git-annex interaction mode for
+Emacs, which aims to integrate with the standard facilities
+(C-x C-q, M-x dired, etc) rather than invent its own interface.
+
+<https://github.com/jwiegley/git-annex-el>
+
+He has also added support to org-attach; if
+`org-attach-git-annex-cutoff` is non-nil and smaller than the size
+ of the file you're attaching then org-attach will `git annex add` the
+file; otherwise it will `git add` it.
+
+----
+
+[magit-annex](https://github.com/magit/magit-annex) adds git annex
+operations to Magit.
diff --git a/doc/tips/enable_tor_on_nixos.mdwn b/doc/tips/enable_tor_on_nixos.mdwn
new file mode 100644
index 0000000000..48dfd9f2c1
--- /dev/null
+++ b/doc/tips/enable_tor_on_nixos.mdwn
@@ -0,0 +1,55 @@
+On NixOS tor is run with a `torrc` directly in `/nix/store`, but `git-annex
+enable-tor` attempts to both read and modify `/etc/tor/torrc`.
+
+This behavior can be accomodated by making a copy:
+
+```sh
+torrc=$( ps -ef | egrep -o '(\S*?torrc)$' )
+
+sudo mkdir -p /etc/tor
+sudo cp $torrc /etc/tor/torrc
+```
+
+This should allow you to run:
+
+```sh
+git-annex enable-tor
+```
+
+without seeing an error, but the edited `torrc` will have no effect so
+git-annex will keep waiting for the hidden service to come online. While it
+does that, check what lines were added:
+
+
+```sh
+diff -u $torrc /etc/tor/torrc
+```
+
+and then add a hidden service to your `configuration.nix`:
+
+```nix
+  # add a service for the repository
+  services.tor.relay.onionServices.git-annex-5e77c94c-5907-4f43-96bf-282ae233b240 = {
+    # this is where git annex configures it, which works fine, but doesn't
+    # actually seem necessary, so it could be left empty
+    path = "/var/lib/tor/tor-annex_1000_5e77c94c-5907-4f43-96bf-282ae233b240";
+
+    # the HiddenServicePort directive requires both tor and git-annex # remotedaemon
+    # to be able to access the socket which is why git annex places it in a separate
+    # directory, but this also needs to be made visible to tor
+    map = [ {
+      port = 12345;
+      target.unix = "/var/lib/tor-annex/1000_5e77c94c-5907-4f43-96bf-282ae233b240/s";
+    } ];
+  };
+
+  # make the sockets directory visible to the otherwise sandboxed tor daemon
+  systemd.services.tor.serviceConfig.BindPaths = [ "/var/lib/tor-annex" ];
+```
+
+Note that without the `BindPaths` the tor daemon will not be able to access the
+sockets and connections will be rejected (can be diagnosed by sending tor a
+`SIGUSR2` to enable debug logging).
+
+You should now be able to run `nixos-rebuild switch` and git-annex will
+detect that the hidden service is running.
diff --git a/doc/tips/file_manager_integration.mdwn b/doc/tips/file_manager_integration.mdwn
new file mode 100644
index 0000000000..43d5a59ed6
--- /dev/null
+++ b/doc/tips/file_manager_integration.mdwn
@@ -0,0 +1,123 @@
+Integrating git-annex and your file manager provides an easy way to select
+annexed files to get or drop. The file manager can also be used to undo
+changes to file managed by git-annex.
+
+[[!toc]]
+
+## GNOME (nautilus)
+
+Recent git-annex comes with built-in integration for Nautilus.
+
+[[!img assistant/nautilusmenu.png]]
+
+[[!img assistant/downloadnotification.png]]
+
+This is set up by git-annex creating simple scripts in
+`~/.local/share/nautilus/scripts`, with names like "git-annex get"
+
+## KDE (Dolphin/Konqueror)
+
+Even more recent git-annex comes with built-in integration with Konqueror.
+
+[[!img assistant/konquerormenu.png]]
+
+This is set up by git-annex creating a 
+`$XDG_DATA_HOME/kservices5/ServiceMenus/git-annex.desktop` file.
+
+## Xfce (Thunar)
+
+Xfce uses the Thunar file manager.
+
+Install <https://pypi.org/project/thunar-plugins/> to use its integrated
+git-annex support.
+
+Alternatively, thunar can also be easily configured to allow for custom
+actions. Just go to the "Configure custom actions..." item in the "Edit"
+menu, and create a custom action for get, drop, and undo with the following
+commands:
+
+    git-annex drop --notify-start --notify-finish -- %F
+
+for drop, and for get:
+
+    git-annex get --notify-start --notify-finish -- %F
+    
+and for undo:
+
+    git-annex undo --notify-start --notify-finish -- %F
+
+This gives me the resulting config on disk, in `.config/Thunar/uca.xml`:
+
+    <action>
+        <icon>git-annex</icon>
+        <name>git-annex get</name>
+        <unique-id>1396278104182858-3</unique-id>
+        <command>git-annex get --notify-start --notify-finish -- %F</command>
+        <description>get the files from a remote git annex repository</description>
+        <patterns>*</patterns>
+        <directories/>
+        <audio-files/>
+        <image-files/>
+        <other-files/>
+        <text-files/>
+        <video-files/>
+    </action>
+    <action>
+        <icon>git-annex</icon>
+        <name>git-annex drop</name>
+        <unique-id>1396278093174843-2</unique-id>
+        <command>git-annex drop --notify-start --notify-finish -- %F</command>
+        <description>drop the files from the local repository</description>
+        <patterns>*</patterns>
+        <directories/>
+        <audio-files/>
+        <image-files/>
+        <other-files/>
+        <text-files/>
+        <video-files/>
+    </action>
+
+The complete instructions on how to setup actions is [in the Xfce documentation](http://docs.xfce.org/xfce/thunar/custom-actions).
+
+## OS X (Finder) Full Integration
+
+Download and install the [git-annex-turtle](https://github.com/andrewringler/git-annex-turtle) app (beta software). Provides Finder integration, badges and context menus.
+
+## OS X (Finder) Context Menus
+
+For OS X, it is possible to get context menus in Finder. Due to how OS X
+deals with symlinks, one needs to operate on folders.
+
+1. Open Automator and create a new Service.
+2. Using the Drop down menus in the top create the sentence "Service receives selected folders in Finder.app" to have it work on folders. For direct mode operation it is probably reasonable to select "files or folders".
+3. Add a "Run shell script" element and fill in line with the following script:
+
+        #!/usr/bin/bash
+        source ~/.bash_profile
+        for f in "$@"
+        do
+            cd "$(dirname "$f")" && git-annex get "$f"
+        done
+
+The purpose of the first line is there to get git-annex on to the path. The
+reason for the for loop is in case multiple files or folders are marked
+when running the context menu command.
+
+Finally save the the workflow under the name for which it should be listed in the context menu.
+
+## your file manager here
+
+Edit this page and add instructions!
+
+## general
+
+If your file manager can run a command on a file, it should be easy to
+integrate git-annex with it. A simple script will suffice:
+
+	#!/bin/sh
+	git-annex get --notify-start --notify-finish -- "$@"
+
+The --notify-start and --notify-stop options make git-annex display a
+desktop notification. This is useful to give the user an indication that
+their action took effect. Desktop notifications are currently only
+implemented for Linux.
diff --git a/doc/tips/file_manager_integration/comment_1_0f82520f415b4715946358658e1799a8._comment b/doc/tips/file_manager_integration/comment_1_0f82520f415b4715946358658e1799a8._comment
new file mode 100644
index 0000000000..2dedcc884e
--- /dev/null
+++ b/doc/tips/file_manager_integration/comment_1_0f82520f415b4715946358658e1799a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw"
+ nickname="Carl"
+ subject="Finder added"
+ date="2014-04-23T13:19:02Z"
+ content="""
+For some reason I do not manage to get the shell script to pretty print. I can also supply a screenshot of the Automator, but do not manage to upload it to the wiki.
+"""]]
diff --git a/doc/tips/file_manager_integration/comment_2_9cb6b7fcb8e33a75efd2f92d7e40a9c5._comment b/doc/tips/file_manager_integration/comment_2_9cb6b7fcb8e33a75efd2f92d7e40a9c5._comment
new file mode 100644
index 0000000000..ad3e4c0b41
--- /dev/null
+++ b/doc/tips/file_manager_integration/comment_2_9cb6b7fcb8e33a75efd2f92d7e40a9c5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 2"
+ date="2014-04-23T17:49:09Z"
+ content="""
+@Carl, I've fixed the formatting. To add a picture, you'd need to send me a pull request adding it to the git repo.
+"""]]
diff --git a/doc/tips/file_manager_integration/comment_3_e7096737268cf66fce2709e9e4937f51._comment b/doc/tips/file_manager_integration/comment_3_e7096737268cf66fce2709e9e4937f51._comment
new file mode 100644
index 0000000000..1c3c7eeb58
--- /dev/null
+++ b/doc/tips/file_manager_integration/comment_3_e7096737268cf66fce2709e9e4937f51._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 3"
+ date="2014-10-01T02:02:39Z"
+ content="""
+for some reason this doesn't work in gnome2. i had to add the shortcuts in /usr/share/nautilus-scripts (iirc). --[[anarcat]]
+"""]]
diff --git a/doc/tips/finding_duplicate_files.mdwn b/doc/tips/finding_duplicate_files.mdwn
new file mode 100644
index 0000000000..94fc85400e
--- /dev/null
+++ b/doc/tips/finding_duplicate_files.mdwn
@@ -0,0 +1,21 @@
+Maybe you had a lot of files scattered around on different drives, and you
+added them all into a single git-annex repository. Some of the files are
+surely duplicates of others.
+
+While git-annex stores the file contents efficiently, it would still
+help in cleaning up this mess if you could find, and perhaps remove
+the duplicate files.
+
+Here's a command line that will show duplicate sets of files grouped together:
+
+	git annex find --include '*' --format='${file} ${escaped_key}\n' | \
+		sort -k2 | uniq --all-repeated=separate -f1 | \
+		sed 's/ [^ ]*$//'
+
+Here's a command line that will remove one of each duplicate set of files:
+
+	git annex find --include '*' --format='${file} ${escaped_key}\n' | \
+		sort -k2 | uniq --repeated -f1 | sed 's/ [^ ]*$//' | \
+		xargs -d '\n' git rm
+
+--[[Joey]] 
diff --git a/doc/tips/finding_duplicate_files/comment_11_5efc6b6ee1dfec88512183e9679ca616._comment b/doc/tips/finding_duplicate_files/comment_11_5efc6b6ee1dfec88512183e9679ca616._comment
new file mode 100644
index 0000000000..03ab1b3c7d
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_11_5efc6b6ee1dfec88512183e9679ca616._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="sameerds"
+ ip="106.51.197.116"
+ subject="a shell script that handles spaces in file names"
+ date="2013-12-31T10:24:06Z"
+ content="""
+I used the following shell pipeline to remove duplicate files in one go:
+
+    (1) git annex find --format='${key}:${file}\n' \
+    (2)    | cut -d '-' -f 4- \
+    (3)    | sort \
+    (4)    | uniq --all-repeated=separate -w 40 \
+    (5)    | awk -vRS= -vFS='\n' '{for (i = 2; i <= NF; i++) print $i}' \
+    (6)    | cut -d ':' -f 2- \
+    (7)    | xargs -d '\n' git rm
+
+1. Generate a list of keys and file names separated by a colon (':').
+2. Cut out the initial part of the key so that the hash is at the beginning of the line. The `-f 4-` ensures that dashes in the filename do not result in truncation.
+3. Sort the entire list.
+4. Uniquify and print duplicates in groups separated by blank lines. Use the first 40 characters, which matches the length of a SHA1 hash. Other hashes will require a different length.
+5. Use awk to print all but the first line in each group. The empty `-vRS` sets blank line as the record separator, and the `-vFS` sets newline as the field separator. The for-loop prints each field except the first.
+6. Cut out the key and keep only the file name by relying on the colon introduced in the first step.
+7. Use xargs to separate file names by newline, which takes care of spaces in the file names. Send this list of arguments to `git rm`.
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_12_630b065f41019716a5f6848e0adcd0f0._comment b/doc/tips/finding_duplicate_files/comment_12_630b065f41019716a5f6848e0adcd0f0._comment
new file mode 100644
index 0000000000..1f17e6711a
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_12_630b065f41019716a5f6848e0adcd0f0._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 12"
+ date="2015-05-21T15:39:07Z"
+ content="""
+My method uses Perl to do a lot of the work, cutting out the need to sort and being careful about spaces and such. Below is an (**untested**) command line version (my version has the perl in ~/bin/annex-dupe.pl):
+
+    git annex find --format='${key} ${file}\n' > ~/tmp/annex_kf.txt
+    perl -pe '($k,$f) = split / /, $_, 2; $cf{$k}++; $_ = sprintf \"%s%s\n\", ($cf{$k}>1?\"\":\"#\", $f;' ~/tmp/annex_kf.txt > ~/tmp/annex_dupes.txt
+    grep '^#' ~/tmp/annex_dupes.txt | xargs -d'\n' git rm
+
+And the equivalent \"one liner\":
+
+    git annex find --format='${key} ${file}\n' \
+    | perl -pe '($k,$f) = split / /, $_, 2; $cf{$k}++; $_ = sprintf \"%s%s\n\", ($cf{$k}>1?\"\":\"#\", $f;' \
+    | grep '^#' \
+    | xargs -d'\n' git rm
+
+It works by getting a list of keys and paths and passing them to Perl, which prefixes the first instance of each key's path with a '#', which is removed by grep, leaving only duplicate paths being passed to xargs and thus, to 'git rm'.
+
+This can be particularly handy as it lets you delete duplicates from specific subdirectories, just by adding another 'grep DIR/PATH' in front of xargs, without worrying you will lose all references if all instances are in DIR/PATH (because the first one will have been removed from the file list by the first grep!).
+
+For example, after outputting all the duplicates (~/tmp/annex_dupe.txt), I will then do a:
+
+    grep '^#' ~/tmp/annex_dupes.txt | grep 'some/sub/dir/somewhere' | xargs -d'\n' git rm
+    git commit -m \"Cleaned up 'some/sub/dir/somewhere'\"
+
+loop, if I want more control over where things are removed from.
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_14_21f6ff2f7c51ca148fb8836a5e325e23._comment b/doc/tips/finding_duplicate_files/comment_14_21f6ff2f7c51ca148fb8836a5e325e23._comment
new file mode 100644
index 0000000000..ad01f83ab0
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_14_21f6ff2f7c51ca148fb8836a5e325e23._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 14"
+ date="2016-01-15T09:34:40Z"
+ content="""
+I think it is worth mentioning that in the script I showed above, the \"uniqueness\" key can be set to anything.
+
+Just recently, I ran a de-duplication where I set such a key to be the key *and* the file name, making it remove only files that are the same, but don't have different filenames. As I have a lot of files without their proper filenames (e.g. recovered with photorec), this prevents me removing the version with the proper filename and keeping the recovered one.
+
+Very useful (in my sorting-annex case anyway).
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_15_cd191275a277aee5de80507d5b5da69b._comment b/doc/tips/finding_duplicate_files/comment_15_cd191275a277aee5de80507d5b5da69b._comment
new file mode 100644
index 0000000000..cf1c7212e0
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_15_cd191275a277aee5de80507d5b5da69b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="chris@a3ac8acdfdc53fa269c7b9bda4306c25b92d6624"
+ nickname="chris"
+ avatar="http://cdn.libravatar.org/avatar/eb7f91e7b7b3457ca57701a40f920f2a"
+ subject="Files with spaces"
+ date="2019-02-19T14:04:04Z"
+ content="""
+For anyone dealing with files with spaces, try this:
+
+```
+git annex find --include '*' --format='${escaped_file} ${escaped_key}\n' | \
+    sort -k2 | uniq --all-repeated=separate -f1 | \
+    sed 's/ [^ ]*$//'
+```
+
+Using `escaped_file` escapes the filename, which will avoid whitespace so the rest of the pipe commands work correctly. You'll need to deal with the files being escaped in the final output, but you'll see them correctly. This worked for me.
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_16_05827cf95647c56c344d150564cdf01d._comment b/doc/tips/finding_duplicate_files/comment_16_05827cf95647c56c344d150564cdf01d._comment
new file mode 100644
index 0000000000..45aa9e8e4a
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_16_05827cf95647c56c344d150564cdf01d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 16"
+ date="2019-02-19T14:13:48Z"
+ content="""
+As the key never contains spaces, it is better to have the key first. Then the filename is anything after key(plus separator) up to the newline.
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_17_9ea2c23d6099281f55122e39655d7353._comment b/doc/tips/finding_duplicate_files/comment_17_9ea2c23d6099281f55122e39655d7353._comment
new file mode 100644
index 0000000000..4d74a72697
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_17_9ea2c23d6099281f55122e39655d7353._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="thk"
+ avatar="http://cdn.libravatar.org/avatar/bfef10a428769701aeee1db978951461"
+ subject="Delete duplicates and specify preferred locations"
+ date="2020-04-26T11:18:39Z"
+ content="""
+I leave this here for people who understand python. I wrote the output of Joey's first script in file \"duplicates\". You want to comment out the last line while trying and add some print statements.
+
+
+```
+from itertools import *
+from functools import partial
+from pprint import pprint
+import subprocess
+
+with open('duplicates', 'rb') as f:
+  duplicates = f.read()
+
+duplicates = duplicates.split(b\"\n\n\")
+
+preferences = b\"\"\"XXXXXXXXXXXXXXXXXXXXXXXXX Add more lines below
+\"\"\".splitlines()
+
+ignore = b\"\"\"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Add more lines below
+\"\"\".splitlines()
+
+deletes = []
+
+def matches(prefixes, f):
+  for prefix in prefixes:
+    if f.startswith(prefix):
+      return True
+  return False
+
+for block in duplicates:
+  files = block.splitlines()
+  if any(filter(partial(matches, ignore), files)):
+    continue
+
+  delete = list(filterfalse(partial(matches, preferences), files))
+
+  if len(delete) + 1 == len(files):
+    deletes.extend(delete)
+
+for d in deletes:
+  pprint(d)
+  subprocess.run([b\"git\", b\"rm\", d], capture_output=True, check=True)
+```
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_1_ddb477ca242ffeb21e0df394d8fdf5d2._comment b/doc/tips/finding_duplicate_files/comment_1_ddb477ca242ffeb21e0df394d8fdf5d2._comment
new file mode 100644
index 0000000000..d1bd4475e5
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_1_ddb477ca242ffeb21e0df394d8fdf5d2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="Cool"
+ date="2011-12-23T19:16:50Z"
+ content="""
+Very nice :)  Just for reference, here's [my Perl implementation](https://github.com/aspiers/git-config/blob/master/bin/git-annex-finddups).  As per [this discussion](http://git-annex.branchable.com/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/#comment-fb15d5829a52cd05bcbd5dc53edaffb2) it would be interesting to benchmark these two approaches and see if one is substantially more efficient than the other w.r.t. CPU and memory usage.
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_2_900eafe0a781018ff44b35ac232e3ad3._comment b/doc/tips/finding_duplicate_files/comment_2_900eafe0a781018ff44b35ac232e3ad3._comment
new file mode 100644
index 0000000000..605c804dd8
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_2_900eafe0a781018ff44b35ac232e3ad3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="bremner"
+ ip="156.34.89.108"
+ subject="problems with spaces in filenames"
+ date="2012-09-05T02:12:18Z"
+ content="""
+note that the sort -k2 doesn't work right for filenames with spaces in them. On the other hand, git-rm doesn't seem to like the escaped names from escaped_file.
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_3._comment b/doc/tips/finding_duplicate_files/comment_3._comment
new file mode 100644
index 0000000000..44eeb50759
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_3._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="mhameed"
+ ip="82.32.202.53"
+ subject="problems with spaces in filenames"
+ date="Wed Sep  5 09:38:56 BST 2012"
+ content="""
+
+Spaces, and other special chars can make filename handeling ugly.
+If you don't have a restriction on keeping the exact filenames, then 
+it might be easiest just to get rid of the problematic chars.
+
+    #!/bin/bash
+
+    function process() {
+        dir="$1"
+        echo "processing $dir"
+        pushd $dir >/dev/null 2>&1
+
+        for fileOrDir in *; do
+            nfileOrDir=`echo "$fileOrDir" | sed -e 's/\[//g' -e 's/\]//g' -e 's/ /_/g' -e "s/'//g" `
+            if [ "$fileOrDir" != "$nfileOrDir" ]; then
+                echo renaming $fileOrDir to $nfileOrDir
+                git mv "$fileOrDir" "$nfileOrDir"
+            else
+                echo "skipping $fileOrDir, no need to rename."
+            fi
+        done
+
+        find ./ -mindepth 1 -maxdepth 1 -type d | while read d; do
+        process "$d"
+        done
+        popd >/dev/null 2>&1
+    }
+
+    process .
+
+Maybe you can run something like this before checking for duplicates.
+
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_4_1494143a74cc1e9fbe4720c14b73d42b._comment b/doc/tips/finding_duplicate_files/comment_4_1494143a74cc1e9fbe4720c14b73d42b._comment
new file mode 100644
index 0000000000..f1a86f43ce
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_4_1494143a74cc1e9fbe4720c14b73d42b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="bremner"
+ ip="156.34.89.108"
+ subject="more about spaces..."
+ date="2012-09-09T19:33:01Z"
+ content="""
+Ironically, previous renaming to remove spaces, plus some synching is how I ended up with these duplicates. For what it is worth, aspiers perl script worked out for me with a small modification. I just only printed out the duplicates with spaces in them (quoted).
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_5_1a35ca360468bcb84a67ad8d62a2ef7d._comment b/doc/tips/finding_duplicate_files/comment_5_1a35ca360468bcb84a67ad8d62a2ef7d._comment
new file mode 100644
index 0000000000..23beb779f8
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_5_1a35ca360468bcb84a67ad8d62a2ef7d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkaBh9VNJ-RZ26wJZ4BEhMN1IlPT-DK6JA"
+ nickname="Alex"
+ subject="printing keys first is the easiest workaround"
+ date="2013-04-01T23:32:23Z"
+ content="""
+Since the keys are sure to have nos paces in them, putting them first makes working with the output with tools like sort, uniq, and awk simpler.
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_6_a6e88c93b31f67c933523725ff61b287._comment b/doc/tips/finding_duplicate_files/comment_6_a6e88c93b31f67c933523725ff61b287._comment
new file mode 100644
index 0000000000..31601a9893
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_6_a6e88c93b31f67c933523725ff61b287._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnkBYpLu_NOj7Uq0-acvLgWhxF8AUEIJbo"
+ nickname="Chris"
+ subject="Find files by key"
+ date="2013-05-03T04:14:55Z"
+ content="""
+Is there any simple way to search for files with a given key?
+
+At the moment, the best I've come up with is this:
+
+````
+git annex find --include '*' --format='${key} ${file}' | grep <KEY>
+````
+
+where `<KEY>` is the key. This seems like an awfully longwinded approach, but I don't see anything in the docs indicating a simpler way to do it. Am I missing something?
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_7_347b0186755a809594bd42feda6363e2._comment b/doc/tips/finding_duplicate_files/comment_7_347b0186755a809594bd42feda6363e2._comment
new file mode 100644
index 0000000000..d97b0d500b
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_7_347b0186755a809594bd42feda6363e2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 7"
+ date="2013-05-13T18:42:14Z"
+ content="""
+@Chris I guess there's no really easy way because searching for a given key is not something many people need to do.
+
+However, git does provide a way. Try `git log --stat -S $KEY`
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_8_3af51722da0980b724facb184f0f66e9._comment b/doc/tips/finding_duplicate_files/comment_8_3af51722da0980b724facb184f0f66e9._comment
new file mode 100644
index 0000000000..26c34fcfa8
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_8_3af51722da0980b724facb184f0f66e9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmTNrhkVQ26GBLaLD5-zNuEiR8syTj4mI8"
+ nickname="Juan"
+ subject="This is an awesome feature"
+ date="2013-08-28T13:40:23Z"
+ content="""
+Thanks. I have quite a lot of papers in PDF formats. Now I'm saving space, have them controlled, synchronized with many devices and found more than 200 duplicates.
+Is there a way to donate to the project? You really deserve it.
+Thanks.
+"""]]
diff --git a/doc/tips/finding_duplicate_files/comment_9_7b4b78a5cd253abfe4f6001049bf64f3._comment b/doc/tips/finding_duplicate_files/comment_9_7b4b78a5cd253abfe4f6001049bf64f3._comment
new file mode 100644
index 0000000000..a20ca16ed2
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_9_7b4b78a5cd253abfe4f6001049bf64f3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.7"
+ subject="comment 9"
+ date="2013-08-28T20:25:20Z"
+ content="""
+@Juan the best thing to do is tell people about git-annex, help them use it, and file bug reports. Just generally be part of the git-annex community.
+
+(If you really want to donate to me, <http://campaign.joeyh.name/> is still open.)
+"""]]
diff --git a/doc/tips/finding_which_file_matches_a_key.mdwn b/doc/tips/finding_which_file_matches_a_key.mdwn
new file mode 100644
index 0000000000..7f172ccd7c
--- /dev/null
+++ b/doc/tips/finding_which_file_matches_a_key.mdwn
@@ -0,0 +1,18 @@
+I have a music file which makes my music player unhappy. unfortunately, it (the music player) only shows me the target of the symlink, the "key" of the file, e.g. `SHA256E-s16279847--ce02487cd9f78f5944cbc1acb6622d270f7c16172d0fa12ae1330a4d9c3144a0.mp3`. There's a way to find which remotes have that key:
+
+    $ git annex whereis --key=SHA256E-s16279847--ce02487cd9f78f5944cbc1acb6622d270f7c16172d0fa12ae1330a4d9c3144a0.mp3
+    whereis SHA256E-s16279847--ce02487cd9f78f5944cbc1acb6622d270f7c16172d0fa12ae1330a4d9c3144a0.mp3 (7 copies) 
+      	059b8bdb-2716-4ac9-b06e-9b1176af361d -- anarcat@curie:~/mp3 [here]
+    ok
+
+But that doesn't show me which file(s) actually point to it. [[git-annex-list]] and [[git-annex-find]] don't have the `--key` parameter and [[git-annex-matching-options]] doesn't have it either, so it makes it difficult to find which file points to that key.
+
+The only way I found to do this was to use the `find` command, like this:
+
+    find -lname '*SHA256E-s16279847--ce02487cd9f78f5944cbc1acb6622d270f7c16172d0fa12ae1330a4d9c3144a0.mp3'
+
+You can also use:
+
+    git log --stat -1 -SKEY
+
+to find the commits (and therefore the files) that link to the given key. That said, `git-annex` does not have any knowledge that would let it do better than either of these commands, at least not reliably. -- [[anarcat]]
diff --git a/doc/tips/finding_which_file_matches_a_key/comment_1_0379aaad5d1dc13e90c13ddd82719ce5._comment b/doc/tips/finding_which_file_matches_a_key/comment_1_0379aaad5d1dc13e90c13ddd82719ce5._comment
new file mode 100644
index 0000000000..e79b8923dd
--- /dev/null
+++ b/doc/tips/finding_which_file_matches_a_key/comment_1_0379aaad5d1dc13e90c13ddd82719ce5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2019-10-21T16:27:49Z"
+ content="""
+You can also use
+    git log --stat -S'SHA256E-...'
+"""]]
diff --git a/doc/tips/finding_which_file_matches_a_key/comment_2_8feecf0ed92b958c902ea2032b5d9576._comment b/doc/tips/finding_which_file_matches_a_key/comment_2_8feecf0ed92b958c902ea2032b5d9576._comment
new file mode 100644
index 0000000000..d761c00baa
--- /dev/null
+++ b/doc/tips/finding_which_file_matches_a_key/comment_2_8feecf0ed92b958c902ea2032b5d9576._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-10-21T16:50:52Z"
+ content="""
+git log -1 --stat -S $key
+
+But that will often be slower than finding the file on disk using your
+method.
+
+git-annex does not have any knowledge that would let it do better than
+either of these commands, at least not reliably.
+"""]]
diff --git a/doc/tips/finding_which_file_matches_a_key/comment_3_1775ca681b8471938a0173b21019f743._comment b/doc/tips/finding_which_file_matches_a_key/comment_3_1775ca681b8471938a0173b21019f743._comment
new file mode 100644
index 0000000000..6c9dec36fc
--- /dev/null
+++ b/doc/tips/finding_which_file_matches_a_key/comment_3_1775ca681b8471938a0173b21019f743._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="right! forgot about log -S"
+ date="2019-10-23T20:16:26Z"
+ content="""
+aah yes, log -S, I forgot about that one. Good tip, I added it to the main body... thanks!
+"""]]
diff --git a/doc/tips/flickrannex.mdwn b/doc/tips/flickrannex.mdwn
new file mode 100644
index 0000000000..7e836a0031
--- /dev/null
+++ b/doc/tips/flickrannex.mdwn
@@ -0,0 +1,50 @@
+flickrannex
+=========
+
+Hook program for gitannex to use flickr as backend
+
+# Requirements:
+
+    python2
+
+Credit for the flickr api interface goes to: http://stuvel.eu/flickrapi
+Credit for the png library goes to: https://github.com/drj11/pypng
+Credit for the png tEXt patch goes to: https://code.google.com/p/pypng/issues/detail?id=65
+
+# Install
+Clone the git repository in your home folder.
+
+    git clone git://github.com/TobiasTheViking/flickrannex.git 
+
+This should make a ~/flickrannex folder
+
+# Setup
+Make the file executable, and link it into PATH
+
+    cd ~/flickrannex; chmod +x git-annex-remote-flickr; sudo ln -sf `pwd`/git-annex-remote-flickr /usr/local/bin/git-annex-remote-flickr
+
+# Commands for gitannex:
+
+    USERNAME="username@provider.com" git annex initremote flickr type=external externaltype=flickr encryption=shared folder=gitannex
+
+An oauth authentication link should now be launched in the default browser. The hook will wait for 30s for you to login and authenticate.
+
+    git annex describe dropbox "the flickr library"
+
+# Notes
+
+## Unencrypted mode
+The photo name on flickr is currently the GPGHMACSHA1 version.
+
+## Encrypted mode
+The current version base64 encodes all the data, which results in ~35% larger filesize.
+
+## Including directories as tags
+This feature is currently disabled, if it gets implemented again it will most likely not require user action to enable it.
+
+In this case the image:
+   /home/me/annex-photos/holidays/2013/Greenland/img001.jpg
+would get the following tags:  "holidays" "2013" "Greenland"
+(assuming "/home/me/annex-photos" is the top level in the annex...)
+
+Caveat Emptor - Tags will *always* be NULL for indirect repos - we don't (easily) know the human-readable file name.
diff --git a/doc/tips/flickrannex/comment_10_50707f259abe5829ce075dfbecd5a4ba._comment b/doc/tips/flickrannex/comment_10_50707f259abe5829ce075dfbecd5a4ba._comment
new file mode 100644
index 0000000000..7bda45e5ca
--- /dev/null
+++ b/doc/tips/flickrannex/comment_10_50707f259abe5829ce075dfbecd5a4ba._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="comment 10"
+ date="2013-06-07T09:39:59Z"
+ content="""
+I'm not even sure if chunksize is exposed to the hooks at all.
+
+As it is, the hook will check the filesize, and if the filesize is more than 30mbyte it will exit 1.
+
+Chunking may be implemented down the road. I do believe joeyh might have some plans that will touch this issue, so I'd rather wait. Than re-invent the wheel yet again.
+
+"""]]
diff --git a/doc/tips/flickrannex/comment_11_ab5bcb025381b3da4d7c6dfd0c7310dd._comment b/doc/tips/flickrannex/comment_11_ab5bcb025381b3da4d7c6dfd0c7310dd._comment
new file mode 100644
index 0000000000..e59aa65003
--- /dev/null
+++ b/doc/tips/flickrannex/comment_11_ab5bcb025381b3da4d7c6dfd0c7310dd._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="git annex get failed"
+ date="2013-08-02T14:29:30Z"
+ content="""
+Hi, I am coming back to this and testing Flickr as a repository for moving files about and have run into what may be my very basic misunderstanding with vanilla annex.
+
+I copied one file to Flickr and dropped it elsewhere (--force).  I assumed that the file was on Flickr ok but that the numcopies setting required the force because of the semi-trust level of the Flickr remote.
+
+Then I find I can't get the file back, even though there is a record of it from whereis.
+
+Can you help enlighten me as to what am I missing?  I assumed whereis would only report files that exist and can be copied back.  If not my error, I can raise bug or search for logs.  Thanks in advance for any help.
+
+[[!format  perl \"\"\"
+
+
+nrb@nrb-ThinkPad-T61:~/tmp$ git annex whereis
+whereis libpeerconnection.log (3 copies) 
+  	31124688-0792-4214-9e00-7ed115aa6b8e -- flickr (the flickr library)
+   	3e3d40d7-de8f-4591-a4ab-747d74a3b278 -- origin (my laptop)
+   	ec2d64fc-30d6-48b4-99bf-7b1bc22d420d -- portable USB drive
+ok
+whereis test.cgi (1 copy) 
+  	31124688-0792-4214-9e00-7ed115aa6b8e -- flickr (the flickr library)
+ok
+whereis walkthrough.sh (3 copies) 
+  	31124688-0792-4214-9e00-7ed115aa6b8e -- flickr (the flickr library)
+   	3e3d40d7-de8f-4591-a4ab-747d74a3b278 -- origin (my laptop)
+   	ec2d64fc-30d6-48b4-99bf-7b1bc22d420d -- portable USB drive
+ok
+whereis walkthrough.sh~ (3 copies) 
+  	31124688-0792-4214-9e00-7ed115aa6b8e -- flickr (the flickr library)
+   	3e3d40d7-de8f-4591-a4ab-747d74a3b278 -- origin (my laptop)
+   	ec2d64fc-30d6-48b4-99bf-7b1bc22d420d -- portable USB drive
+ok
+nrb@nrb-ThinkPad-T61:~/tmp$ git annex get test.cgi
+get test.cgi (from flickr...) 
+
+git-annex: /home/nrb/tmp/.git/annex/tmp/SHA256E-s48--a01eedbee949120aeda41e566f9ae8faef1c2bacaa6d7bb8e45050fb8df6d09d.cgi: rename: does not exist (No such file or directory)
+failed
+git-annex: get: 1 failed
+nrb@nrb-ThinkPad-T61:~/tmp$ 
+
+\"\"\"]]
+"""]]
diff --git a/doc/tips/flickrannex/comment_12_90a331275d888221bc695003c8acbe46._comment b/doc/tips/flickrannex/comment_12_90a331275d888221bc695003c8acbe46._comment
new file mode 100644
index 0000000000..003755f301
--- /dev/null
+++ b/doc/tips/flickrannex/comment_12_90a331275d888221bc695003c8acbe46._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="re: git annex get failed"
+ date="2013-08-02T15:02:14Z"
+ content="""
+Another try - this time a slightly simpler setup using my version of the walkthrough commands
+
+[[!format  bash \"\"\"
+
+nrb@nrb-ThinkPad-T61:~/repos/annex/laptop-annex$ git annex drop walkthrough.sh --from usbdrive
+drop usbdrive walkthrough.sh ok
+(Recording state in git...)
+nrb@nrb-ThinkPad-T61:~/repos/annex/laptop-annex$ git annex move walkthrough.sh --to flickr
+move walkthrough.sh (gpg) (checking flickr...) (to flickr...) 
+/home/nrb/repos/gits/flickrannex/flickrannex.py:92: FutureWarning: The behavior of this method will change in future versions.  Use specific 'len(elem)' or 'elem is not None' test instead.
+  if res:
+/home/nrb/repos/gits/flickrannex/flickrannex.py:100: FutureWarning: The behavior of this method will change in future versions.  Use specific 'len(elem)' or 'elem is not None' test instead.
+  if res:
+ok
+(Recording state in git...)
+nrb@nrb-ThinkPad-T61:~/repos/annex/laptop-annex$ git annex whereis
+whereis walkthrough.sh (1 copy) 
+  	161b7af0-2075-4314-9767-308a49b86018 -- flickr (the flickr library)
+ok
+whereis walkthrough.sh~ (3 copies) 
+  	161b7af0-2075-4314-9767-308a49b86018 -- flickr (the flickr library)
+   	7803d853-d231-4bb4-b696-f12a950fb96b -- here (my laptop)
+   	d60d75f9-d878-4214-af20-fa055134ae77 -- usbdrive (portable USB drive)
+ok
+nrb@nrb-ThinkPad-T61:~/repos/annex/laptop-annex$ git annex get walkthrough.sh
+get walkthrough.sh (from flickr...) (gpg) 
+git-annex: /home/nrb/repos/annex/laptop-annex/.git/annex/tmp/GPGHMACSHA1--02f600d7e8b071d2945270fd5e7fc26dd066ff31: openBinaryFile: does not exist (No such file or directory)
+gpg: decrypt_message failed: eof
+
+  Unable to access these remotes: flickr
+
+  Try making some of these repositories available:
+  	161b7af0-2075-4314-9767-308a49b86018 -- flickr (the flickr library)
+failed
+git-annex: get: 1 failed
+nrb@nrb-ThinkPad-T61:~/repos/annex/laptop-annex$ git annex fsck --from flickr
+fsck walkthrough.sh (gpg) (checking flickr...) (fixing location log) 
+  ** Based on the location log, walkthrough.sh
+  ** was expected to be present, but its content is missing.
+
+  ** No known copies exist of walkthrough.sh
+failed
+fsck walkthrough.sh~ (checking flickr...) (fixing location log) 
+  ** Based on the location log, walkthrough.sh~
+  ** was expected to be present, but its content is missing.
+failed
+(Recording state in git...)
+git-annex: fsck: 2 failed
+nrb@nrb-ThinkPad-T61:~/repos/annex/laptop-annex$ 
+
+\"\"\" ]]
+"""]]
diff --git a/doc/tips/flickrannex/comment_13_1596e70dca71c853fd1d6fc9bde02b18._comment b/doc/tips/flickrannex/comment_13_1596e70dca71c853fd1d6fc9bde02b18._comment
new file mode 100644
index 0000000000..19faa585e8
--- /dev/null
+++ b/doc/tips/flickrannex/comment_13_1596e70dca71c853fd1d6fc9bde02b18._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="Version 0.1.10 pushed"
+ date="2013-09-11T20:31:25Z"
+ content="""
+Since the initial release of this hook a lot of issues have been fixed, and a few features added.
+
+I would highly suggest that everyone who is using this hook update to the latest version as i would consider one of the bugs to be fairly major.
+
+
+"""]]
diff --git a/doc/tips/flickrannex/comment_14_c728f10074d194efa8b2c60e97d275e7._comment b/doc/tips/flickrannex/comment_14_c728f10074d194efa8b2c60e97d275e7._comment
new file mode 100644
index 0000000000..f625d6bc00
--- /dev/null
+++ b/doc/tips/flickrannex/comment_14_c728f10074d194efa8b2c60e97d275e7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="great job on that plugin!"
+ date="2014-04-15T04:47:17Z"
+ content="""
+it's pretty awesome to have 1TB of free storage like that out there... but for storing photos, it could be improved - I filed a few bugs on the github repo here:
+
+https://github.com/TobiasTheViking/flickrannex/issues/created_by/anarcat?state=open
+
+thanks!
+"""]]
diff --git a/doc/tips/flickrannex/comment_15_2dd75800e4db58761fcbbd1954a36f1f._comment b/doc/tips/flickrannex/comment_15_2dd75800e4db58761fcbbd1954a36f1f._comment
new file mode 100644
index 0000000000..67f7d3b74d
--- /dev/null
+++ b/doc/tips/flickrannex/comment_15_2dd75800e4db58761fcbbd1954a36f1f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmvzzyDA8uXFz8yokeCrepbh8PwWe_WrjE"
+ nickname="Michael"
+ subject="current status?"
+ date="2014-08-08T16:00:18Z"
+ content="""
+Hi, just wondering what the current status of this plugin is.
+The repo at TobiasTheViking looks a little odd - it has a few large commits from January with an unknown author, and the last one appears to completely remove the main script.
+
+What's going on? does it need a fork?
+"""]]
diff --git a/doc/tips/flickrannex/comment_16_2f65093ec9f6d67d2cfe5b5fae201123._comment b/doc/tips/flickrannex/comment_16_2f65093ec9f6d67d2cfe5b5fae201123._comment
new file mode 100644
index 0000000000..f45aad147a
--- /dev/null
+++ b/doc/tips/flickrannex/comment_16_2f65093ec9f6d67d2cfe5b5fae201123._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmvzzyDA8uXFz8yokeCrepbh8PwWe_WrjE"
+ nickname="Michael"
+ subject="a more recent fork"
+ date="2014-08-08T16:03:24Z"
+ content="""
+Just a note that I poked around on github and saw a more recent cleaned up version in this fork: https://github.com/magthe/flickrannex/tree/devo
+
+
+"""]]
diff --git a/doc/tips/flickrannex/comment_17_5bfe0988260b7825eeec204cd8f79b98._comment b/doc/tips/flickrannex/comment_17_5bfe0988260b7825eeec204cd8f79b98._comment
new file mode 100644
index 0000000000..200a81aa36
--- /dev/null
+++ b/doc/tips/flickrannex/comment_17_5bfe0988260b7825eeec204cd8f79b98._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="fiatjaf"
+ subject="How I got it working"
+ date="2016-08-06T23:51:48Z"
+ content="""
+I'm using [pipsi](https://github.com/mitsuhiko/pipsi) to install packages without polluting the system, [Michael's fork](https://github.com/mikemccracken/flickrannex) from magthe's fork from TobiasTheViking repo (I don't know if the other branches are better or worse, but this is working).
+
+## Instructions
+
+**First thing**: go to https://www.flickr.com/services/apps/create/noncommercial/? and create an app (if you use the keys provided in the flickrannex repository you'll be giving access to your flickr to everybody).
+
+Now follow the steps:
+
+```
+wget https://github.com/mikemccracken/flickrannex/archive/master.zip
+unzip master.zip
+cd flickrannex-master/
+edit setup.py # replace 'flickrapi' with 'flickrapi==1.4.5'
+              # otherwise it will install a wrong version of the dependency.
+edit flickrannex # on lines 46 and 47, replace the api_key and api_secret
+                 # with the values from the application you created in the
+                 # first step.
+pipsi install ./
+cd
+flickrannex # go through the oauth setup, will open a window in the browser
+            # some commands will appear after you're successful. ignore them.
+cd ~/annex # your git-annex folder
+git config annex.flickr-hook $HOME/.local/bin/flickrannex
+git annex initremote flickr type=hook hooktype=flickr encryption=none
+```
+"""]]
diff --git a/doc/tips/flickrannex/comment_18_ef71e2f8c48b0399d9fbc419e850dc5d._comment b/doc/tips/flickrannex/comment_18_ef71e2f8c48b0399d9fbc419e850dc5d._comment
new file mode 100644
index 0000000000..93a0ac15b1
--- /dev/null
+++ b/doc/tips/flickrannex/comment_18_ef71e2f8c48b0399d9fbc419e850dc5d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Dead project, or just working smoothly? Also, which hat color?"
+ date="2016-10-23T18:23:34Z"
+ content="""
+Q1: No commit on https://github.com/TobiasTheViking/flickrannex/commits/master since Jan 13, 2014. Is it still working?
+
+Q2: I'm not sure I get it correctly.  Is it to use Flickr *photo* storage so that you can store git-annex content that is actually *photos* to visible Flickr collections (on web site) and vice versa (a nice white-hat hack)? Or is it just a cuckoo's hack to stuff arbitrary data on Flickr's servers without any content (a grey-zone hack)?
+
+"""]]
diff --git a/doc/tips/flickrannex/comment_2_d74c4fc7edf8e47f7482564ce0ef4d12._comment b/doc/tips/flickrannex/comment_2_d74c4fc7edf8e47f7482564ce0ef4d12._comment
new file mode 100644
index 0000000000..d015dc1955
--- /dev/null
+++ b/doc/tips/flickrannex/comment_2_d74c4fc7edf8e47f7482564ce0ef4d12._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="comment 2"
+ date="2013-06-05T21:33:42Z"
+ content="""
+Get the statically linked version from here http://git-annex.branchable.com/install/Linux_standalone/
+
+I believe the new hook format was introduced in version 4.20130521
+"""]]
diff --git a/doc/tips/flickrannex/comment_2_f53d0d5520e2835e9705bea4e75556f0._comment b/doc/tips/flickrannex/comment_2_f53d0d5520e2835e9705bea4e75556f0._comment
new file mode 100644
index 0000000000..14d7a1b7c4
--- /dev/null
+++ b/doc/tips/flickrannex/comment_2_f53d0d5520e2835e9705bea4e75556f0._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="missing configuration for flickr-checkpresent-hook"
+ date="2013-06-05T20:44:25Z"
+ content="""
+<https://github.com/TobiasTheViking/flickrannex/issues/3>
+
+9 days ago: [the annex] \"hook format a few versions ago, and this is using the new hook format\".
+
+Looks very handy. I am just starting with this, but can't seem to get it working as a remote after following the simple walkthrough. All goes well until:
+
+    $ git annex copy . --to flickr
+    copy walkthrough.sh (checking flickr...) 
+      missing configuration for flickr-checkpresent-hook
+    git-annex: checkpresent hook misconfigured
+
+my Ubuntu 12.04:
+
+    $ git annex version
+    git-annex version: 4.20130516.1
+    build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3 4
+    upgrade supported from repository versions: 0 1 2
+
+I guess my \"git-annex version is still too old\"? Any idea what version is needed? Even better if I can figure out which Linux distribution/release has the most up to date version of annex.
+
+"""]]
diff --git a/doc/tips/flickrannex/comment_4_9ebba4d61140f6c2071e988c9328cf7e._comment b/doc/tips/flickrannex/comment_4_9ebba4d61140f6c2071e988c9328cf7e._comment
new file mode 100644
index 0000000000..741b0c5bac
--- /dev/null
+++ b/doc/tips/flickrannex/comment_4_9ebba4d61140f6c2071e988c9328cf7e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
+ nickname="develop"
+ subject="comment 4"
+ date="2013-06-05T22:02:29Z"
+ content="""
+The path for the binary \"/usr/bin/python2\" is wrong.
+
+It could be any of /usr/bin/python /usr/bin/python2.6 /usr/bin/python2.7
+
+Or maybe in /usr/local/bin
+
+you can try running \"which python\" or \"which python2\" to get the real path.
+"""]]
diff --git a/doc/tips/flickrannex/comment_5_4470dae270613dd8712623474bc80ab0._comment b/doc/tips/flickrannex/comment_5_4470dae270613dd8712623474bc80ab0._comment
new file mode 100644
index 0000000000..1c19711df9
--- /dev/null
+++ b/doc/tips/flickrannex/comment_5_4470dae270613dd8712623474bc80ab0._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="missing configuration for flickr-checkpresent-hook"
+ date="2013-06-05T22:00:48Z"
+ content="""
+Many thanks.
+
+I used gitannex-install and was left with a slight anomaly:
+
+    Installing...........done
+    git-annex version 4.20130601 has been installed
+    $ git-annex version
+    git-annex version: 4.20130531-g5df09b5
+
+But I guess this includes the new hook format.  I get a bit further:
+
+    $ git annex copy . --to flickr
+    copy walkthrough.sh (checking flickr...) (user error (sh [\"-c\",\"/usr/bin/python2 /home/nrb/repos/gits/flickrannex/flickrannex.py\"] exited 1)) failed
+    copy walkthrough.sh~ (checking flickr...) (user error (sh [\"-c\",\"/usr/bin/python2 /home/nrb/repos/gits/flickrannex/flickrannex.py\"] exited 1)) failed
+    git-annex: copy: 2 failed
+
+
+"""]]
diff --git a/doc/tips/flickrannex/comment_5_d395cdcf815cb430e374ff05c1a63ff4._comment b/doc/tips/flickrannex/comment_5_d395cdcf815cb430e374ff05c1a63ff4._comment
new file mode 100644
index 0000000000..dbeaafb734
--- /dev/null
+++ b/doc/tips/flickrannex/comment_5_d395cdcf815cb430e374ff05c1a63ff4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="comment 5"
+ date="2013-06-05T22:11:14Z"
+ content="""
+Thanks, but on my machine I get:
+
+    $ which python2
+    /usr/bin/python2
+
+I have scripted all my walkthrough commands, blowing away the test repositories and flickr settings first each time.  This re-runs the flickr scripts and git config annex.flickr-hook etc.
+
+I can't spot anything here.
+
+
+"""]]
diff --git a/doc/tips/flickrannex/comment_6_8cf730097001ffe106f2c743edce9d0a._comment b/doc/tips/flickrannex/comment_6_8cf730097001ffe106f2c743edce9d0a._comment
new file mode 100644
index 0000000000..8e7b15ed0a
--- /dev/null
+++ b/doc/tips/flickrannex/comment_6_8cf730097001ffe106f2c743edce9d0a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA"
+ nickname="Tobias"
+ subject="comment 6"
+ date="2013-06-06T09:44:11Z"
+ content="""
+That's weird...
+
+You could try adding \"--dbglevel 1 --stderr\" arguments to the hook command and give me the output. But the way i read the log it seems like it doesn't even launch the python intrepreter. I might be wrong though.
+
+
+"""]]
diff --git a/doc/tips/flickrannex/comment_7_a80c8087c4e1562a4c98a24edc182e5a._comment b/doc/tips/flickrannex/comment_7_a80c8087c4e1562a4c98a24edc182e5a._comment
new file mode 100644
index 0000000000..9e0eb0a73f
--- /dev/null
+++ b/doc/tips/flickrannex/comment_7_a80c8087c4e1562a4c98a24edc182e5a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="Unencrypted flickr can only accept picture and video files"
+ date="2013-06-06T10:24:58Z"
+ content="""
+Thanks and sorry to trouble you, it is my error, I picked unencrypted option (thinking it would be less of an issue) and am using a text file for test, gave an error line:
+
+    10:53:07 [flickrannex-0.1.5] main : 'Unencrypted flickr can only accept picture and video files'
+
+I've not looked through your code yet, but could that message be printed when not in debug mode?
+"""]]
diff --git a/doc/tips/flickrannex/comment_8_94f84254c32cf0f7dd1441b7da5d2bc6._comment b/doc/tips/flickrannex/comment_8_94f84254c32cf0f7dd1441b7da5d2bc6._comment
new file mode 100644
index 0000000000..ff11a618a5
--- /dev/null
+++ b/doc/tips/flickrannex/comment_8_94f84254c32cf0f7dd1441b7da5d2bc6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA"
+ nickname="Tobias"
+ subject="comment 8"
+ date="2013-06-06T10:51:39Z"
+ content="""
+I'll make it so, in the next version i push.
+"""]]
diff --git a/doc/tips/flickrannex/comment_9_5299b4cab4a4cb8e8fd4d2b39f0ea59c._comment b/doc/tips/flickrannex/comment_9_5299b4cab4a4cb8e8fd4d2b39f0ea59c._comment
new file mode 100644
index 0000000000..f25cd04c14
--- /dev/null
+++ b/doc/tips/flickrannex/comment_9_5299b4cab4a4cb8e8fd4d2b39f0ea59c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawleVyKk2kQsB_HgEdS7w1s0BmgRGy1aay0"
+ nickname="Milan"
+ subject="chunksize"
+ date="2013-06-07T09:09:56Z"
+ content="""
+Hi! Does this backend support chunksize option? If yes, is it possible to set it after the remote has been added to the repository?
+Thanks, Milan.
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt.mdwn b/doc/tips/fully_encrypted_git_repositories_with_gcrypt.mdwn
new file mode 100644
index 0000000000..4484d5bf21
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt.mdwn
@@ -0,0 +1,156 @@
+[git-remote-gcrypt](https://spwhitton.name/tech/code/git-remote-gcrypt/)
+adds support for encrypted remotes to git. Combine this with git-annex
+encrypting the files it stores in a remote, and you can fully encrypt
+all the data stored on a remote.
+
+Here are some ways you can use this awesome stuff..
+
+[[!toc ]]
+
+This page will show how to set it up at the command line, but the git-annex
+[[assistant]] can also be used to help you set up encrypted git
+repositories.
+
+## prerequisites
+
+* Install [git-remote-gcrypt](https://spwhitton.name/tech/code/git-remote-gcrypt/).
+
+* Set up a gpg key. You might consider generating a special purpose key
+  just for this use case, since you may end up wanting to put the key
+  on multiple machines that you would not trust with your main gpg key.
+
+  The examples below use "$mykey" where you should put your gpg keyid.
+
+## encrypted backup drive
+
+Let's make a USB drive into an encrypted backup repository. It will contain
+both the full contents of your git repository, and all the files you
+instruct git-annex to store on it, and everything will be encrypted so that
+only you can see it.
+
+Here's how to set up the encrypted repository:
+
+	git init --bare /mnt/encryptedbackup
+	git annex initremote encryptedbackup type=gcrypt gitrepo=/mnt/encryptedbackup keyid=$mykey
+	git annex sync encryptedbackup
+
+(Remember to replace "$mykey" with the keyid of your gpg key.)
+
+This uses the [[gcrypt special remote|special_remotes/gcrypt]] to encrypt
+pushes to the git remote, and git-annex will also encrypt the files it
+stores there.
+
+Now you can copy (or even move) files to the repository. After
+sending files to it, you'll probably want to do a sync, which pushes
+the git repository changes to it as well.
+
+	git annex copy --to encryptedbackup ...
+	git annex sync encryptedbackup
+
+Note that if you lose your gpg key, it will be *impossible* to get the
+data out of your encrypted backup. You need to find a secure way to store a
+backup of your gpg key. Printing it out and storing it in a safe deposit box,
+for example.
+
+You can actually specify keyid= as many times as you like to allow any one
+of a set of gpg keys to access this repository. So you could add a friend's
+key, or another gpg key you have.
+
+To restore from the backup, just plug the drive into any machine that has
+the gpg key used to encrypt it, and then:
+
+	git clone gcrypt::/mnt/encryptedbackup restored
+	cd restored
+	git annex enableremote encryptedbackup gitrepo=/mnt/encryptedbackup
+	git annex get --from encryptedbackup
+
+## encrypted git-annex repository on a ssh server
+
+If you have a server that has ssh and rsync installed on it, you can set up an
+encrypted repository there. Works just like the encrypted drive except
+without the cable.
+
+This example uses rsync urls in a form supported by git-remote-gcrypt since
+version 1.4. Older versions won't work with the urls used here, consult
+its documentation if you have to use an old version.
+
+First, on the server, run:
+
+	git init --bare encryptedrepo
+
+Now, in your existing git-annex repository, set up the encrypted remote:
+
+	git annex initremote encryptedrepo type=gcrypt gitrepo=rsync://my.server/home/me/encryptedrepo keyid=$mykey
+	git annex sync encryptedrepo
+
+(Remember to replace "$mykey" with the keyid of your gpg key.)
+
+This uses the [[gcrypt special remote|special_remotes/gcrypt]] to encrypt
+pushes to the git remote, and git-annex will also encrypt the files it
+stores there. Data is transferred using rsync over ssh.
+
+If you're going to be sharing this repository with others, be sure to also
+include their keyids, by specifying keyid= repeatedly.
+
+Now you can copy (or even move) files to the repository. After
+sending files to it, you'll probably want to do a sync, which pushes
+the git repository changes to it as well.
+
+	git annex copy --to encryptedrepo ...
+	git annex sync encryptedbackup
+
+Anyone who has access to the repo it and has one of the keys
+used to encrypt it can check it out:
+
+	git clone gcrypt::rsync://my.server/home/me/encryptedrepo myrepo
+	cd myrepo
+	git annex enableremote encryptedrepo gitrepo=rsync://my.server/home/me/encryptedrepo
+	git annex get --from encryptedrepo
+
+## private encrypted git remote on a git-lfs hosting site
+
+Some git repository hosting sites do not support git-annex, but do support
+the similar git-lfs for storing large files alongside a git repository.
+git-annex can use the git-lfs protocol to store files in such repositories,
+and with gcrypt, everything stored in the remote can be encrypted.
+
+First, make a new, empty git repository on the hosting site.
+Get the ssh clone url for the repository, which might look
+like "git@github.com:username/somerepo.git"
+
+Then, in your git-annex repository, set up the encrypted remote:
+
+	git annex initremote lfstest type=git-lfs url=gcrypt::git@github.com:username/somerepo.git keyid=$mykey
+
+(Remember to replace "$mykey" with the keyid of your gpg key.)
+
+This uses the [[git-lfs special remote|special_remotes/git-lfs]], and the
+`gcrypt::` prefix on the url makes pushes be encrypted with gcrypt.
+
+## private encrypted git remote on a git hosting site
+
+You can use gcrypt to store your git repository in encrypted form on any
+hosting site that supports git. Only you can decrypt its contents. Using it
+this way, git-annex does not store large files on the hosting site; it's
+only used to store your git repository itself.
+
+	git remote add encrypted gcrypt::ssh://hostingsite/myrepo.git
+	git push encrypted master git-annex
+
+Now you can carry on using git-annex with your new repository. For example,
+`git annex sync` will sync with it.
+
+To check out the repository from the hosting site, use the same gcrypt::
+url you used when setting it up:
+
+	git clone gcrypt::ssh://hostingsite/myrepo.git
+
+## multiuser encrypted git remote on a git hosting site
+
+Suppose two users want to share an encrypted git remote. Both of you
+need to set up the remote, and configure gcrypt to encrypt it so that both
+of you can see it.
+	
+	git remote add sharedencrypted gcrypt::ssh://hostingsite/myrepo.git
+	git config remote.sharedencrypted.gcryt-participants "$mykey $friendkey"
+	git push sharedencrypted master git-annex
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_10_4440a80d64c60c7312d5c405d54e607a._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_10_4440a80d64c60c7312d5c405d54e607a._comment
new file mode 100644
index 0000000000..b1031646f7
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_10_4440a80d64c60c7312d5c405d54e607a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="tanen"
+ ip="83.128.159.25"
+ subject="comment 10"
+ date="2013-11-04T17:58:36Z"
+ content="""
+> \"We could symetrically encrypt the repository with a keyfile that's stored in the repository itself\"
+> Then you would need to decrypt the repository in order get the key you need to decrypt the repository. The impossibility of this design is why I didn't do that!
+
+Sorry, I ment that the file containing the symmetric encryption key should obviously not be used to encrypt itself, it would be stored in the repository \"unencrypted\" (but protected with a passphrase)
+
+> store a non-encrypted gpg key alongside the repository encrypted with it, but then you have to rely on a passphrase for all your security.
+
+Exactly. I think such a mode be a great addition. It might not be as secure as encryption based on a private key - depending on the passphrase strength -, but it would certainly be a lot more convenient and portable (and still much more secure than the shared encryption method).
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_11_28eb9d4ebf28ca310f9b357b1dad244a._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_11_28eb9d4ebf28ca310f9b357b1dad244a._comment
new file mode 100644
index 0000000000..9aab8b22e6
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_11_28eb9d4ebf28ca310f9b357b1dad244a._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlY4LE-xEyztjJeXSot7JIGGFWgBfabgwc"
+ nickname="Peter"
+ subject="GPG Key specification"
+ date="2013-12-09T13:32:51Z"
+ content="""
+Hi there,
+
+I try to follow the instructions provided here but I don't manage it to get my repo encrypted. Here are the steps:
+
+1) git init --bare Encrypted
+2) git-annex init
+3) git annex initremote encryptedbackup type=gcrypt gitrepo=~/tmp/Encrypted encryption=pubkey keyid=DXXXX
+
+The last step takes a lof of time to run. Basically my key doesn't get used at all:
+
+    # ps -ax | grep gpg
+    4743 pts/4    SL+    0:00 gpg --quiet --trust-model always --gen-random --armor 2 256
+    4753 pts/0    S+     0:00 grep gpg
+
+
+... instead a new pgp key is generated. How comes??!
+
+Any help would be appreciated.
+
+Thx and cheers,
+
+cyneox
+
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_12_b697b2ab10705b090a78e7717ec59b18._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_12_b697b2ab10705b090a78e7717ec59b18._comment
new file mode 100644
index 0000000000..182b5eabbb
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_12_b697b2ab10705b090a78e7717ec59b18._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 12"
+ date="2013-12-12T19:27:23Z"
+ content="""
+@Peter, in your example, it *is* going to use your gpg key to encrypt files. gpg is being used to generate a 256 bit random value (not a key), which will be used as a random seed for HMAC scrambling of the keys stored in the encrypted special remote.
+
+If that's taking too long to generate for your liking, you can pass --fast, which will make gpg use /dev/urandom to generate it rather than /dev/random.
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_13_4e37146a870576f09f56d2e5ee784ed7._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_13_4e37146a870576f09f56d2e5ee784ed7._comment
new file mode 100644
index 0000000000..7bce4c1c28
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_13_4e37146a870576f09f56d2e5ee784ed7._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://jspk.clavid.com/"
+ nickname="flabbergast"
+ subject="gcrypted repository structure"
+ date="2013-12-30T12:07:44Z"
+ content="""
+I'm a bit confused about how do the gcrypted repositories actually work with git-annex. As far as I can tell, using git-remote-gcrypt with pure git produces a directory containing a couple of files with names looking like hashes. These files contain the whole repository - I checked by cloning the encrypted repo.
+
+With git-annex: The instructions on this page suggest first creating a bare repo (creating a normal git repo layout). When I do this and then do the next step (`git annex initremote ...`) git-remote-gcrypt complains that the repository doesn't exist (which is correct from its point of view, as there is no encrypted repo yet) and creates a new one (so now there are both structures of a bare git repo _and_ an encrypted repo alongside in the same directory). The setup sort of works, but the bare git repo is never touched after that (or at least it shouldn't be, as it has nothing to do with the encrypted repo).
+
+I've tried also following the instructions, only skipping the first step entirely (ie. no bare repo created). As far as I can tell, git-remote-gcrypt will run \"fine\" (will create a new encrypted repo), but git-annex itself complains that \"could not lock config file \<dir\>/.git/config\" and quits. Interestingly enough, the following gets around this \"problem\" and also results in a working setup (`~/annex` is a git-annex repo).
+
+         cd ~/annex
+         mkdir -p /tmp/test/.git
+         touch /tmp/test/.git/config
+         git annex initremote encr type=gcrypt gitrepo=/tmp/test keyid=\"XXX\"
+         git annex sync encr
+
+Then `git clone gcrypt::/tmp/test restored` will successfully recover the whole git-annex repo into `restored`.
+
+So finally the question: is creating a bare git repo really necessary; and if not, is writing into `.git/config` necessary?
+
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_14_2044e821d841fcd37a51ae768fa88df2._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_14_2044e821d841fcd37a51ae768fa88df2._comment
new file mode 100644
index 0000000000..6df29f9916
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_14_2044e821d841fcd37a51ae768fa88df2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 14"
+ date="2013-12-31T19:26:55Z"
+ content="""
+@flabbergast, you seem to be confused about how git-remote-gcrypt stores its data. The data is stored as git commits inside a bare repository. That is why the instructions say to create a bare repository first. (I think it's also possible to use git-remote-gcrypt in a rsync mode where it just uploads encrypted files to an empty directory and does not use a bare git repository, but git-annex does not use it like that.)
+
+Your mkdir and touch commands effecetively create a bare git repository too.
+
+If you're having a problem, I suggest filing a bug report (not a comment on this page) with the full details. The examples show on this page have been tested, and work.
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_15_de4838d82987685896d4c76dac7cdb6c._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_15_de4838d82987685896d4c76dac7cdb6c._comment
new file mode 100644
index 0000000000..3eb3812064
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_15_de4838d82987685896d4c76dac7cdb6c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tanen"
+ subject="comment 15"
+ date="2015-08-23T20:34:20Z"
+ content="""
+I just created the same setup again that I attempted 1-2 years ago, with the latest self-contained git-annex build. Two clients, one SSH server, using gcrypt. Setup worked flawless now (although the process of having to manually export the generated GPG key and import it into all clients is still very awkward); changes made on a client are immediately detected and synced with the server. However, the changes made on client A are never automatically propagated to client B. They are picked up when I restart the annex assistant on client B, but never automatically.
+
+Is this a bug or simply not supported? I read about XMPP being deprecated in favor of notifications via the annex-shell, but I couldn't find a post detailing these changes.
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_16_c1194234e9f4fd469fa4b9fea72219e1._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_16_c1194234e9f4fd469fa4b9fea72219e1._comment
new file mode 100644
index 0000000000..1a091fee4a
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_16_c1194234e9f4fd469fa4b9fea72219e1._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="jonas@1491caea7d71fcf350b6f200807141f1b59857b8"
+ nickname="jonas"
+ subject="gcrypt and map"
+ date="2015-10-27T10:14:17Z"
+ content="""
+I'm having a problem generating a proper annex map where one of the remotes is gcrypt. Specifically, the map command fails as per below. I will concede that it's not clear though if the failure is that of encryptedown, or the third and final remote dsown, which is an rsync one.
+
+jonas@silk:~/own$ git annex map
+map /home/jonas/own ok
+map encryptedown 
+failed
+jonas@silk:~/own$ git annex info encryptedown
+remote: encryptedown
+description: VM / Montreal / gcrypt [encryptedown]
+uuid: 51ee1422-67d5-56f5-83f3-2718c9996080
+cost: 250.0
+type: gcrypt
+repository location: ssh://198.50.187.233/home/jonas/encryptedown/
+encryption: encrypted (to gpg keys: 0C5161298A31D11A) (hybrid mode)
+chunking: none
+jonas@silk:~/own$ git annex info dsown
+remote: dsown
+description: DiskStation NAS / Asgatan / rsync [dsown]
+uuid: ef3b81aa-47bd-41b4-8672-e371742306cf
+cost: 250.0
+type: rsync
+url: diskstation:/volume1/silkbackup/
+encryption: encrypted (encryption key stored in git repository)
+chunking: none
+
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_17_098998132fb0bcf130b5bf8a16ac8b8a._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_17_098998132fb0bcf130b5bf8a16ac8b8a._comment
new file mode 100644
index 0000000000..8026567a69
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_17_098998132fb0bcf130b5bf8a16ac8b8a._comment
@@ -0,0 +1,54 @@
+[[!comment format=mdwn
+ username="spam@9590d16798fd27f4e38472862e296fc9828e3d39"
+ nickname="spam"
+ avatar="http://cdn.libravatar.org/avatar/838ad52bf6bddd532ff179811be47f52"
+ subject="remote &quot;origin&quot; missing some gcrypt commands?"
+ date="2017-11-11T19:51:56Z"
+ content="""
+
+I just discovered that cloning over ssh an gcrypt encrypted repository and enabling the remote afterwards is somehow messing up the git config:
+
+git clone grypt::ssh://user@ip.com:/mnt/encrypted_backup
+cd encrypted_backup
+git annex enableremote encrypted_backup gitrepo=/.../encrypted_backup
+
+leads to following in the .git/config of the just cloned repository:
+
+...
+[remote \"origin\"]
+url = grypt::ssh://user@ip.com:/mnt/encrypted_backup
+gcrypt-id = :id:12312312
+fetch = +refs/heads/*:refs/remotes/origin/*
+
+[remote \"encrypted_backup\"]
+url = grypt::ssh://user@ip.com:/mnt/encrypted_backup
+fetch = +refs/heads/*:refs/remotes/server/*
+gcrypt-participants = keyid
+gcrypt-signingkey = keyid
+gcrypt-publish-participants = true
+gcrypt-id = :id:adsasd
+annex-gcrypt = shell
+annex-uuid = 312312312
+...
+
+Note, that for the remote \"origin\" some config like the signingkey is missing compared to the remote \"encrypted_backup\"
+
+Then, running
+git annex sync --content
+
+leads to a error saying
+
+\"gcrypt: Failed to decrypt manifest!\"
+
+during the push process.
+After that I am not able to sync the repository anymore, even with the original repostitory, which initiated the remote.
+The encrypted_backup is then somehow messed up.
+
+Removing the \"origin\" remote via
+git remote remove origin
+
+solves the problem for me. But that command has to be launched right before the first sync, pull or push command! Otherwise the sync process cannot be done anymore.
+
+
+
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_18_bdcb4bace530ac8b2018916893ae7e93._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_18_bdcb4bace530ac8b2018916893ae7e93._comment
new file mode 100644
index 0000000000..8153055da7
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_18_bdcb4bace530ac8b2018916893ae7e93._comment
@@ -0,0 +1,87 @@
+[[!comment format=mdwn
+ username="itn@23fdfea9e5c13d8bb24e4cbde30d2a98293154c1"
+ nickname="itn"
+ avatar="http://cdn.libravatar.org/avatar/09ed2f8a3623192b3d38df2e420cd09d"
+ subject="Cloning and syncing leads to confusing &quot;gcrypt: Failed to decrypt manifest!&quot; errors."
+ date="2018-04-08T00:50:14Z"
+ content="""
+# Details
+
+I followed the instructions to create a new encrypted ssh-accessible remote (gcrypt, hybrid). As an additional detail, I have a key generated with instructions from <https://alexcabal.com/creating-the-perfect-gpg-keypair>). Everything worked until I tried to setup another machine (which has the same encryption GPG subkey available) to use the repo. After that, neither machine could no longer sync successfully. Here is the result of the commands on the second machine (partially omitted):
+
+    $ git clone gcrypt::ssh://server/user/annex
+    <output omitted>
+    $ cd annex
+    $ git annex sync
+    (merging origin/git-annex into git-annex...)
+    (recording state in git...)
+    commit  (recording state in git...)
+    
+    On branch master
+    Your branch is up-to-date with 'origin/master'.
+    
+    nothing to commit, working tree clean
+    ok
+    pull origin
+    gcrypt: Decrypting manifest
+    gpg: Good signature from \"...\" [ultimate]
+    ok
+    push origin
+    gcrypt: Decrypting manifest
+    gpg: Good signature from \"...\" [ultimate]
+    Counting objects: 6, done.
+    Compressing objects: 100% (5/5), done.
+    Total 6 (delta 1), reused 1 (delta 0)
+    gcrypt: Encrypting to: --throw-keyids --default-recipient-self
+    gcrypt: Requesting manifest signature
+    To gcrypt::ssh://server/home/user/annex   
+       494c59d..935583f  git-annex -> synced/git-annex
+    gcrypt: Decrypting manifest
+    gpg: decryption failed: No secret key
+    gcrypt: Failed to decrypt manifest!
+    ok
+
+Looking at the output, I was convinced that the following line explained the issue:
+
+    gcrypt: Encrypting to: --throw-keyids --default-recipient-self
+
+So I did everything again and took copies of the repo on the server after each interaction. I found out that when the remote is initialized, the encrypted \"session key\" contained the information on the recipients, but if the remote in synced with the cloned repo, the session key is modified.
+
+I took a look at the encrypted session key in the remote repo before and after (I cloned it directly without trying to decrypt). Here, I've replaced the real key id with \"DEADBEEFDEADBEEF\":
+
+    $ gpg --list-packets --list-only <session-key-before>
+    # off=0 ctb=85 tag=1 hlen=3 plen=524
+    :pubkey enc packet: version 3, algo 1, keyid DEADBEEFDEADBEEF
+            data: [4096 bits]
+    # off=527 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
+    :encrypted data packet:
+            length: unknown
+            mdc_method: 2
+
+  
+    $ gpg --list-packets --list-only <session-key-after>
+    # off=0 ctb=85 tag=1 hlen=3 plen=524
+    :pubkey enc packet: version 3, algo 1, keyid 0000000000000000
+            data: [4092 bits]
+    # off=527 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
+    :encrypted data packet:
+            length: unknown
+            mdc_method: 2
+
+This means that the recipient information is not included in the file. In practice this means that you need to check if you are the recipient by trying to decrypt the file. 
+Unfortunately, it seems that no key is actually tried. The file is decrypted successfully with:
+
+    gpg --try-all-secrets <session-key-after>
+
+# Solution
+
+As the core issue is that GnuPG fails to use the correct key if recipients are not known, we can tell gpg which keys to try. This can be done by editing ~/.gnupg/gpg.conf. Set the 'default-key' or alternatively, if the key you are using for this purpose is not your default key, set the 'try-secret-key'
+ 
+The other issue is that the recipients are removed from the session key, you can make sure that the correct recipients are kept if you set the following options for the remote in the cloned repo (.git/config):
+
+    gcrypt-participants = <insert-key(s)-here>
+    gcrypt-signingkey = <insert-key-here>
+    gcrypt-publish-participants = true
+
+I suspect that many users who have multiple keys may run into this issue. The previous comment also seems to be a variant of this.
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_1_5c54690586f2a781905ea4b25aa1147f._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_1_5c54690586f2a781905ea4b25aa1147f._comment
new file mode 100644
index 0000000000..71305e6505
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_1_5c54690586f2a781905ea4b25aa1147f._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM"
+ nickname="Fabrice"
+ subject="Is there a way to specify a preferred pgp key?"
+ date="2013-11-01T18:57:38Z"
+ content="""
+Hi,
+
+I think the current behavior of the special remote is a bit annoying when one has several pgp keys. 
+
+Indeed, I've followed the encrypted backup drive example specifying the id of a dedicated key in the initremote step, so far so good. Doing that, I was prompted for my key phrase by the gnome keyring daemon, as expected. 
+
+The annoying part starts right at the git annex sync step. Indeed, when git-remote-gcrypt tries to decrypt the manifest from the encrypted remote, rather than trying only the key specified during the initremote step, it tries all my (secret) keys. This means that I get prompted for the key phrase of all those keys (minus the correct one which is already unlocked...). 
+
+In the future, this might possible to avoid by allowing gcrypt to fetch a preferred key from git config and to use with the --try-secret-key option available gnupg 2.1.x. But for 1.x or 2.0.x, the simpler option --default-key does not seem to alter the order in which keys are tried to decrypt the manifest. Also, it does not seem to be a problem of the gnome keyring daemon, but rather a gpg problem as when the daemon is replaced by the standard gpg-agent, the same problem occurs. 
+
+Meanwhile, is there any way to avoid this problem? 
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_2_07feedb4348f8c31176cc744c19368a1._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_2_07feedb4348f8c31176cc744c19368a1._comment
new file mode 100644
index 0000000000..b154263fe4
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_2_07feedb4348f8c31176cc744c19368a1._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM"
+ nickname="Fabrice"
+ subject="A possible solution"
+ date="2013-11-02T14:22:13Z"
+ content="""
+I'm answering to myself :-). A possible solution to the annoying pass phrase asking with current gnupg is to use a specialized secret keyring. One first exports the secret key used for this repository in a specific keyring as follows:
+
+`gpg --export-secret-keys keyid | gpg --import --no-default-keyring --secret-keyring mygitannexsecret.gpg`
+
+This will create a keyring in $HOME/.gnupg with only the specific key. 
+
+Then, in the git-remote-gcrypt shell script, gpg should be called as follows 
+
+`gpg --no-default-keyring --secret-keyring mygitannexsecret.gpg -q -d ...`
+
+when decrypting the manifest in order to try only the specific key. This behavior can be easily triggered via some git configuration variable.
+
+Any comment?
+
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_3_c2f873dffa015f1d72ad0c3921909316._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_3_c2f873dffa015f1d72ad0c3921909316._comment
new file mode 100644
index 0000000000..0ce74d7676
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_3_c2f873dffa015f1d72ad0c3921909316._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 3"
+ date="2013-11-02T17:32:28Z"
+ content="""
+Fabrice, I've filed a bug report about this: <https://github.com/blake2-ppc/git-remote-gcrypt/issues/9>
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_4_f8a6e4415f4fe6da14f6a3b7334bc952._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_4_f8a6e4415f4fe6da14f6a3b7334bc952._comment
new file mode 100644
index 0000000000..9b1307df4c
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_4_f8a6e4415f4fe6da14f6a3b7334bc952._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="tanen"
+ ip="83.128.159.25"
+ subject="comment 4"
+ date="2013-11-03T22:35:07Z"
+ content="""
+The way I would want to setup git-annex (assistant) is \"Wuala/Spideroak style\": two computers with a full checkout of the repository, changes automatically being synced between them, even if the two computers are never online simultaneously, and encryption should be done locally: the (special) remote should not be able to view file listings or content. 
+
+Do I understand it correctly that the gcrypt remote is the only way to make this happen? I tried to create such a setup via the webapp but failed. Adding the repository and remote (via \"Encrypt with GnuPG key\") on the first computer went OK*, but trying to enable that remote on the other computer fails: clicking enable asks me for the SSH password, but after that I just get redirected to a blank screen, with nothing to see in the logfile after the succesful call to ssh-keygen. No entry for the second computer is being added to authorized_keys on the remote.
+
+Perhaps this is because at this point the assistant is unable to actually parse the content of the encrypted repository? I tried importing the private key that was used while creating the repository on the other computer, but that made no difference.
+
+Thinking about this for a while, I believe gpg keys aren't actually particularly suited for this usecase. Even without the bug above, one would either have to awkwardly copy a private key to all hosts that are syncing to the repository; or, every time a new (or reinstalled) host wants to sync the repository, you would manually have to add the new keyid to the config and do the forced push + GCRYPT_FULL_REPACK, presumably having to reupload your entire history. Apart from this, having to backup a private key (outside of your git-annex based backups!) would be quite inconvenient.
+
+How would you feel about adding a new mode of operation where encryption is simply based on a passphrase? We could symetrically encrypt the repository with a keyfile that's stored in the repository itself, protecting the keyfile with a passphrase which - if stored at all - would be stored on the individual computers, outside of the repository.
+
+*although it erroneously used \"E0D2F776E7F674E3\" as key-id while the actual id is E7F674E3; where did that other half come from?
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_5_11b8e82d2a234f65b58b823e71c6d6a2._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_5_11b8e82d2a234f65b58b823e71c6d6a2._comment
new file mode 100644
index 0000000000..8e767254c9
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_5_11b8e82d2a234f65b58b823e71c6d6a2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="comment 5"
+ date="2013-11-04T04:40:53Z"
+ content="""
+> How would you feel about adding a new mode of operation where encryption is simply based on a passphrase? We could symetrically encrypt the repository with a keyfile that's stored in the repository itself, protecting the keyfile with a passphrase which - if stored at all - would be stored on the individual computers, outside of the repository.
+
+Isn't that what the regular shared-encryption remote already does?  Except it doesn't put a passphrase on the key, because anyone who has access to the local repo wouldn't need access to the remote one anyway.
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_6_3e41948e1beffcf279bb05ef8e61cc07._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_6_3e41948e1beffcf279bb05ef8e61cc07._comment
new file mode 100644
index 0000000000..1a5d7f6e1c
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_6_3e41948e1beffcf279bb05ef8e61cc07._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM"
+ nickname="Fabrice"
+ subject="comment 6"
+ date="2013-11-04T07:39:21Z"
+ content="""
+> _How would you feel about adding a new mode of operation where encryption is simply based on a passphrase? We could symetrically encrypt the repository with a keyfile that's stored in the repository itself, protecting the keyfile with a passphrase which - if stored at all - would be stored on the individual computers, outside of the repository._
+
+As Adam wrote, without a passphrase, this is the shared encryption method. With an encrypted key, this is more or less the hybrid (default) scheme. The thing is that you have to share a secret to have a encrypted remote. I don't use the webapp, so I don't know what's happening in your case, but this is how it should work with the command line tools. First Alice create the encrypted remote with her pgp key. As far as I understand, git annex creates (via gpg) a  key for a symmetric cypher which is stored in the repository, encrypted with Alice public key. If Alice wants to share the repository with Bob, she must either give a key pair (so the private key also, of course) to Bob or ask Bob for his public key. In the first case, Bob can clone the repository directly (upon reception of the key pair), while in the second case, Alice has to active Bob's public key (with `git annex enableremote myremote keyid+=bobsId`). In this case, again as far as I understand, the symmetric key is reencrypted for both Alice and Bob in the repo. 
+
+I understand that you tried the first case with the webapp and that it did not work. I had a similar problem documented in this [http://git-annex.branchable.com/bugs/git-annex-shell:_gcryptsetup_permission_denied](bug). Maybe you could had some comments to this bug description? 
+
+> _*although it erroneously used \"E0D2F776E7F674E3\" as key-id while the actual id is E7F674E3; where did that other half come from?_
+
+This is the long id of your pgp key (16 characters as opposed to 8 for the short id).
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_7_4ce0b26b25b336f07b2e27246cdfba3e._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_7_4ce0b26b25b336f07b2e27246cdfba3e._comment
new file mode 100644
index 0000000000..dfb2a3b92f
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_7_4ce0b26b25b336f07b2e27246cdfba3e._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="tanen"
+ ip="83.128.159.25"
+ subject="comment 7"
+ date="2013-11-04T09:01:13Z"
+ content="""
+Thanks for the responses. Please correct me if I'm wrong, but the way I understood it, using the shared encryption scheme creates a conflict between \"changes being synced between them, even if the two computers are never online simultaneously\" and \"encryption should be done locally: the (special) remote should not be able to view file listings or content.\"
+
+- If I use shared encryption \"the webapp way\", only the file contents will be rsynced to the remote, not the repository itself. This means that different hosts are unable to sync unless they are online simultaneously, so that commit data can be sent directly between them via XMPP. In practice, this would mean my hosts are never synced (because I don't keep my home computer running when I leave for work, and vice versa)
+
+- If I use shared encryption and additionally put the repository itself on a remote, that remote would have the keys to fully decrypt the repository, that's not acceptable.
+
+Reading through the docs again, the hybrid scheme actually seems to be closer to what I want than the shared scheme, but it still has a major downside: the encryption only applies to the files itself, so in order to get \"offline sync\" there still has to be a 'remote' for the repository itself, which will contain all your metadata unencrypted. And also it would depend on the user being able to manually setup and backup a set of gpg keys instead of just memorizing a secure passphrase.
+
+@Fabrice Looks like the bug you found could very well be the cause of the problem I had; I'll try it again when a new version is available.
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_8_49aa34d75d24a2066baa8a585bc9c2e9._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_8_49aa34d75d24a2066baa8a585bc9c2e9._comment
new file mode 100644
index 0000000000..86f3f5cadc
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_8_49aa34d75d24a2066baa8a585bc9c2e9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM"
+ nickname="Fabrice"
+ subject="comment 8"
+ date="2013-11-04T10:31:56Z"
+ content="""
+I think you are (at least partially) right. Of course, the only way to sync completely computers that are not on together is to use either a usb drive or a third always on computer. (I've to confess I did not understand first when I read git annex docs, shame on me ;-) If you don't want to trust completely this computer (I don't, for instance), you must :
+
+* use an encrypted git repository on this computer;
+
+* and use either hybrid or pubkey encryption. 
+
+But contrarily to what you seem to imply (I hope I understand you correctly), if you do that, the third computer can still figure out a few things (usage patterns, such as where connections come from), but that's all. You've got full sync and everything is encrypted, both the git part and the files handled by the annex. This applied only to encrypted git special remotes as other remotes do not store the git part.
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_9_3784e0c828cd60b6a9075c2d32d070cc._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_9_3784e0c828cd60b6a9075c2d32d070cc._comment
new file mode 100644
index 0000000000..7a452e8f03
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_9_3784e0c828cd60b6a9075c2d32d070cc._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 9"
+ date="2013-11-04T17:07:55Z"
+ content="""
+\"We could symetrically encrypt the repository with a keyfile that's stored in the repository itself\"
+
+Then you would need to decrypt the repository in order get the key you need to decrypt the repository. The impossibility of this design is why I didn't do that!
+
+It would certainly be possible to store a non-encrypted gpg key alongside the repository encrypted with it, but then you have to rely on a passphrase for all your security.
+
+You should file a bug report for the bug you saw..
+"""]]
diff --git a/doc/tips/get_git-annex-shell_into_PATH.mdwn b/doc/tips/get_git-annex-shell_into_PATH.mdwn
new file mode 100644
index 0000000000..8ecdd16099
--- /dev/null
+++ b/doc/tips/get_git-annex-shell_into_PATH.mdwn
@@ -0,0 +1,55 @@
+The [[git-annex-shell]] program is a part of git-annex that is used when
+accessing a git-annex repository on a remote server. The client runs
+something like "ssh server git-annex-shell". For this to work,
+git-annex-shell needs to be installed in PATH.
+
+If you install git-annex on your server as root, using a distribution's
+package manager, like apt-get, or otherwise installing it into /usr/bin, or
+/usr/local/bin, then git-annex-shell will be in PATH, and you'll not have
+any trouble (and can stop reading here).
+
+But, if you need to install git-annex on a server without being root,
+it can be tricky to get it into PATH. The bash shell doesn't source all of
+its config files when ssh uses it to run a non-interactive command like
+git-annex-shell, so even if git-annex-shell seems to be in PATH when you're
+logged onto the server, "ssh server git-annex-shell" won't find it.
+
+	bash: git-annex-shell: command not found; failed; exit code 127
+
+----
+
+In some systems (when it's compiled with `SSH_SOURCE_BASHRC` set), bash will
+load your `~/.bashrc` (but not your `~/.bash_profile`). So you can add to
+PATH in the .bashrc.
+
+Note that many .bashrc files start with something like this: 
+
+	# If not running interactively, don't do anything
+	[ -z "$PS1" ] && return
+
+So, make sure to make any PATH changes before such a guard. For example:
+
+	PATH=$HOME/bin/:$PATH
+
+	# If not running interactively, don't do anything else
+	[ -z "$PS1" ] && return
+
+----
+
+In some systems, bash won't load *any* config files at all.
+A few ways to deal with that:
+
+* Move or symlink git-annex-shell into a directory like
+  /usr/bin, that is in the default PATH.
+
+* If you're not root, ask the system administrator to please install
+  git-annex system-wide.
+
+* As a last resort, you can configure the git repository that's using
+  the server to know where git-annex shell is installed, by configuring
+  `remote.<name>.annex-shell`
+
+  For example, if git-annex-shell is installed in ~/bin/git-annex-shell
+  on the server, and the git remote named "annoyingserver" uses the server:
+
+	git config remote.annoyingserver.annex-shell /home/me/bin/git-annex-shell
diff --git a/doc/tips/git-annex_extensions_for_ranger__44___the_file_manager.mdwn b/doc/tips/git-annex_extensions_for_ranger__44___the_file_manager.mdwn
new file mode 100644
index 0000000000..9a89a54034
--- /dev/null
+++ b/doc/tips/git-annex_extensions_for_ranger__44___the_file_manager.mdwn
@@ -0,0 +1,28 @@
+If you use [ranger](https://github.com/ranger/ranger), the console-based file manager, you can benefit of its plugin system to get it easily entangled with git-annex. As far as I know, there 2 main types of extensions:
+
+## Custom commands
+
+ranger lets you [define custom commands](https://github.com/ranger/ranger/wiki/Commands) that can be called. Basically you could easily write proxy ranger commands for all git-annex commands you use. [Here](https://github.com/fiatjaf/dotfiles/blob/master/ranger-commands.py) have written
+
+  * `:ga_whereis` for outputting whereis information;
+  * `:ga_set` and `:ga_tag` for metadata changing;
+  * `:ga_get` and `:ga_drop` for quick fetching from remotes and dropping them from local (really useful).
+
+## Linemodes
+
+The small string of information that shows on each file line, aligned to the right, is called a `infostring`. [Linemodes in ranger](https://github.com/ranger/ranger/wiki/Custom-linemodes) lets you change between its default linemodes or add your own custom linemodes. I have written two git-annex linemodes: 
+
+  * [git-annex-metadata](https://github.com/fiatjaf/dotfiles/blob/5087963cead99f65afee153be672c8e5e624d638/ranger-plugins/linemode_gitannex.py#L8-L51), which shows tags and metadata fields from git-annex; and
+  * [git-annex-whereis](https://github.com/fiatjaf/dotfiles/blob/5087963cead99f65afee153be672c8e5e624d638/ranger-plugins/linemode_gitannex.py#L54-L104), which shows the name of the repositories where each file is (except the current repository, as that should be clear from the ranger colours).
+
+To switch linemodes, just type `:linemode git-annex-whereis` or `:linemode git-annex-metadata`.
+
+You can also set `default_linemode path=/your/annex/path/.* git-annex-whereis`, for example, to have that linemode automatically set whenever you browse your git-annex folder on ranger.
+
+Beware of folders with too many files, as this will read output from git-annex for all the files, so ranger can freeze for some seconds.
+
+---
+
+As I didn't have any better place to put the code, eveything here is referenced in my [dotfiles repository on GitHub](https://github.com/fiatjaf/dotfiles). Just copy the two referenced files to your `~/.config/ranger/plugins/` folder and `~/.config/ranger/commands.py` file to get this working.
+
+Much other interesting commands and plugins can still be added. Modify this page if you come up with other ideas.
diff --git a/doc/tips/git-annex_extensions_for_ranger__44___the_file_manager/comment_1_358d4041c0158c247340cd4588286df4._comment b/doc/tips/git-annex_extensions_for_ranger__44___the_file_manager/comment_1_358d4041c0158c247340cd4588286df4._comment
new file mode 100644
index 0000000000..130b4d2d49
--- /dev/null
+++ b/doc/tips/git-annex_extensions_for_ranger__44___the_file_manager/comment_1_358d4041c0158c247340cd4588286df4._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="fiatjaf"
+ subject="related work"
+ date="2016-10-11T13:35:07Z"
+ content="""
+Just find some related / complimentary work for this. It is a bunch of ranger functions that wrap git-annex commands inside ranger:
+
+```
+:annex_add → git annex add + git commit -a
+:annex_get → git annex get
+:annex_drop → git annex drop
+:annex_copy <remote> → git annex copy --to=<remote>
+:annex_sync → git annex sync --fast --quiet
+```
+
+
+The code is at [https://github.com/matze/ranger-annex](https://github.com/matze/ranger-annex)
+
+More information on [this blog post](https://bloerg.net/2014/04/28/writing-a-git-annex-plugin-for-ranger.html).
+"""]]
diff --git a/doc/tips/git-annex_on_NFS.mdwn b/doc/tips/git-annex_on_NFS.mdwn
new file mode 100644
index 0000000000..b6a8a45b13
--- /dev/null
+++ b/doc/tips/git-annex_on_NFS.mdwn
@@ -0,0 +1,75 @@
+There are multiple issues that have been reported that are related to using git-annex on networked file systems. We're generally talking about NFS, which we'll cover here, but this may also be the case on SMB filesystems.
+
+Locking issues
+==============
+
+Here is the prior art here:
+
+* [[devblog/day_27__locking_fun/]]
+* [[devblog/day_286-287__rotten_locks/]]
+* [[forum/Can__39__t_init_git_annex/]]
+* [[bugs/git-annex_merge_stalls/]]
+
+All of those issues but the first are related to locking on NFS filesystems, which is [notoriously bad](https://en.wikipedia.org/wiki/File_locking#Problems). However, the problems with it are not insurmountable and git-annex can actually be used, even if unreliably, on NFS filesystems.
+
+The problem I mainly hit with NFS filesystems is with unreliable locking. If you have similar platforms (both running Linux for example, NFS locking doesn't work in BSD systems), locking *should* work, but sometimes fails without reason. This problem and the solution is well described in [this stackoverflow answer](http://serverfault.com/a/455080), taken from [this excellent blog](http://sophiedogg.com/lockd-and-statd-nfs-errors/). Basically, you need to restart a bunch of NFS daemon that get stuck on the server side and then locking works again. This generally fixed it for me:
+
+<pre>
+service nfs-kernel-server stop
+service rpcbind stop
+service nfs-common stop
+service rpcbind start
+service nfs-common start
+service nfs-kernel-server start
+</pre>
+
+This needs to be run as root on the server side. Having a simple test script to see if locking works is also useful, i use the following:
+
+<pre>
+#! /usr/bin/perl -w
+
+use Fcntl qw(LOCK_SH LOCK_EX LOCK_UN);
+
+$child = fork();
+open(TESTLCK, ">testlock");
+
+if ($child == 0) { # in child
+	print "locking exclusively\n";
+	flock(TESTLCK, LOCK_EX) || die "failed to lock exclusively: $!";
+	print "holding exclusively lock for 3 seconds\n";
+	sleep 3;
+	flock(TESTLCK, LOCK_UN) || die "failed to unlock exclusively: $!";
+	print "done locking exclusively\n";
+} else { # in parent
+	print "locking shared\n";
+	flock(TESTLCK, LOCK_SH) || die "failed to lock shared: $!";
+	print "holding shared lock for 3 seconds\n";
+	sleep 3;
+	flock(TESTLCK, LOCK_UN) || die "failed to unlock shared: $!";
+	print "done locking shared, waiting for child to finish\n";
+	wait;
+}
+</pre>
+
+Also note that the [NFS FAQ](http://nfs.sourceforge.net/) (currently offline, thanks to Sourceforge, see [this archive](https://archive.is/QMMO)) also has interesting snippets about NFS locking. In short: it's a mess, but it can be worked around! -- [[anarcat]]
+
+Socket issues
+=============
+
+Another thing that may fail is the "ssh caching code". Examples:
+
+* [[forum/git_annex_sync_dies___40__sometimes__41__/]]
+* [[forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote/]]
+* [[todo/git-annex_ignores_GIT__95__SSH/]]
+* [[bugs/git-annex-shell_doesn__39__t_work_as_expected/]]
+
+As you can see, this affects way more than NFS, which often just works there. But it can be that the SSH client can't create a socket for the SSH multiplexing that git-annex uses. Normally, git-annex should detect that and fallback properly, but sometimes this fails, especially with older versions of git-annex. A workaround is to disable the feature:
+
+    git config annex.sshcaching false
+
+The tradeoff is that syncs are faster, but it works. -- [[anarcat]]
+
+Stray files issue
+=================
+
+This is a completely different issue, but could be related to file locking: [[bugs/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/]]. Basically, tons of files are left behind by git-annex when it is ran on an NFS server. It is yet unclear how this problem happens and how to resolve it. But it has been reproduced and could affect you, so until it is resolved, it is still an open issue here... -- [[anarcat]]
diff --git a/doc/tips/git-annex_on_NFS/comment_1_e2e99f2c484597c0d314ae597be078c3._comment b/doc/tips/git-annex_on_NFS/comment_1_e2e99f2c484597c0d314ae597be078c3._comment
new file mode 100644
index 0000000000..6649c2ace5
--- /dev/null
+++ b/doc/tips/git-annex_on_NFS/comment_1_e2e99f2c484597c0d314ae597be078c3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="current status?"
+ date="2016-09-06T14:11:24Z"
+ content="""
+Hi Joey,
+
+Since this issue is > year old, and some fixes/workarounds were done to how locking mechanisms, could you please update on the status of \"NFS support\".  Thank you in advance 
+"""]]
diff --git a/doc/tips/git-annex_on_NFS/comment_2_06f2ee5095cd35063a434560375e172e._comment b/doc/tips/git-annex_on_NFS/comment_2_06f2ee5095cd35063a434560375e172e._comment
new file mode 100644
index 0000000000..53525fadd4
--- /dev/null
+++ b/doc/tips/git-annex_on_NFS/comment_2_06f2ee5095cd35063a434560375e172e._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-09-21T19:28:36Z"
+ content="""
+git-annex will probe to detect if the filesystem does not support FIFOs and
+disables `annex.sshcaching` in that case. It's done so since 2013. So I would
+be surprised if NFS had any problems with annex.sshcaching.
+
+`git config annex.pidlock true` will make git-annex avoid FCNTL locking,
+and so work on filesystems that don't support that. It should also
+avoid the ".nfs" files.
+
+It's not enabled by default on NFS because I don't currently have a good
+way to probe if a given directory is on NFS.
+
+Also, annex.pidlock makes git-annex significantly slower and less safe.
+But if you're using NFS, speed and safety must have already been
+de-prioritized.
+
+Seriously, my main advice for using git-annex on NFS is: 
+Don't. Make local clones of repositories and use git-annex to distribute
+the files around. Unless your institution forces you to use a networked
+filesystem to access gobs of disk space, and you need to have more files
+present in a repository than will fit locally.
+"""]]
diff --git a/doc/tips/hashdeep_integration.mdwn b/doc/tips/hashdeep_integration.mdwn
new file mode 100644
index 0000000000..f246c0b3d5
--- /dev/null
+++ b/doc/tips/hashdeep_integration.mdwn
@@ -0,0 +1,114 @@
+## What is hashdeep
+
+[hashdeep](http://md5deep.sourceforge.net/) is a handy tool that allows you to check file integrity
+across whole directory trees. It can detect renames and missing files,
+for example.
+
+## How to use it with git-annex
+
+The general working principle of hashdeep is that it iterates over a
+set of files and produces a manifest that looks like this:
+
+    $ hashdeep -r *
+    %%%% HASHDEEP-1.0
+    %%%% size,md5,sha256,filename
+    ## Invoked from: /home/jessek
+    ## $ hashdeep -r archives bin lib doc
+    21508,6178d221a1714b7e2089565e997d6ad1,92caa3f5754b22ca792e4f8626362d2ef39596b080abfcfed951a86bee82bec3,/home/jessek/archives/foo-1.2.1.tar.gz
+    12292,116e77a5dc6af0996597f7bc1b9252a2,c2afc6aa8d5c094a7226db1695d99a37fa858548f5d09aad9e41badfc62b1d27,/home/jessek/archives/bar-0.9.tar.bz2
+    145684,4409c1e0b5995c290c2fc3d1d6d74bac,f56881fb277358c95ed3ddf64f28c4ff3f3937e636e17d6a26d42822b16fd4ed,/home/jessek/bin/ls
+
+Then this manifest can be used to check consistency of the files
+later. Because git-annex also uses hashes to identify files, it fits
+nicely with this pattern and I have used it to verify files that were
+outside of git-annex's control yet still from the repository. First,
+we produce the manifest file:
+
+    (
+    echo '%%%% HASHDEEP-1.0'
+    echo '%%%% size,sha256,filename'
+    git annex find --format '${bytesize},${keyname},${file}\n' | sed 's/\.[^,]*,/,/'
+    ) > manifest.txt
+
+Then this can be used to verify an external fileset with the following
+command:
+
+    hashdeep -k manifest.txt -a -vv -e -r /mnt/ > result
+
+This will create a listing of every file that was moved, that is
+missing and so on. I have used this to audit corrupted files on my
+phone's microSD card as it turned out that about half of the files
+were corrupted for some mysterious reason:
+
+    hashdeep: Audit failed
+       Input files examined: 0
+      Known files expecting: 0
+              Files matched: 0
+    Files partially matched: 0
+                Files moved: 3411
+            New files found: 2179
+      Known files not found: 42117
+
+The non-zero numbers are interesting: 3411 files were detected as
+being sane and just the filenames had changed. 2179 files were "new"
+which means that they were not in the original set. Since files were
+supposed to *only* come from the original set, this means those files
+were corrupt. Actually, that's not completely true: some files (JPG
+image files, namely) *were* created in the external fileset so I had
+to be careful to exclude those false positives by hand. The 42117
+"known files not found" were files that were simply not transferred
+over to the phone for lack of space.
+
+This way, I was able to quickly find which files were corrupt and
+remove them. This created a list of files to remove:
+
+    grep 'No match' result  | grep -v '.jpg' | sed 's/: No match$//'
+
+And I used the following loop to remove the files one by one:
+
+    grep 'No match' result  | grep -v '.jpg' | sed 's/: No match$//' | while read file; do rm "$file" ; done
+
+Note the above is actually quite dangerous and you might want to
+insert an `echo` in there to avoid shenanigans, especially if you do
+not trust the filesystem.
+
+## How else this might work
+
+Naturally, I could have imported all the files into git-annex and work
+only with git-annex to operate this. But because the files were
+renamed to some canonical version by the software transferring the file
+([dSub](https://f-droid.org/en/packages/github.daneren2005.dsub/) and [Airsonic](https://airsonic.github.io/)), it would have been difficult to make a
+diff with the original set. This is on a (ex)fat filesystem too, which
+might make git-annex operation difficult. Yet I can't help but think
+this is something that [[git-annex-export]] should be able to do, but
+I am not sure it could deal with the renames. And I must say I have
+found it a little inconvenient to have to `initremote` to be able to
+use what are essentially ephemeral storage mountpoints.
+
+The above procedure reuses the best of both world: hashdeep does the
+fuzzy matching and git-annex provides the catalog of files.
+
+## Future improvements
+
+It would be nice if [[git-annex-find]] would allow listing only the
+checksum, which would remove a potentially error-prone pattern
+substitution above (`sed 's/\.[^,]*,/,/'`). This is necessary because
+`${keyname}` includes the file extension which is expected with the
+`SHA256E` backend, but it is somewhat inconvenient to deal with. Of
+course, it would be pretty awesome if git-annex could output
+hashdeep-compatible catalogs out of the box: it would improve
+interoperability here... And the icing on cake would be a git-annex
+command (a variation of [[git-annex-import]]?) that would audit an
+external, non-annexed repository for consistency in the same way.
+
+Also note that hashdeep can operate in "chunk" mode which means that
+it can work across file boundaries, detecting partial matches, for
+example. This is something that, as far as I know, is impossible in
+git-annex as checksums are only file-based. This would be useful in
+eliminating the false positives by distinguishing the "this file is
+completely new" and "this file is corrupt" cases.
+
+## Comments
+
+Those notes were provided by [[anarcat]] but would gladly welcome
+corrections and improvements.
diff --git a/doc/tips/hiding_missing_files.mdwn b/doc/tips/hiding_missing_files.mdwn
new file mode 100644
index 0000000000..49f6c661a0
--- /dev/null
+++ b/doc/tips/hiding_missing_files.mdwn
@@ -0,0 +1,146 @@
+Annexed files can have their content either present in the repository, or
+not locally present (but stored in other repositories). Normally such
+missing files are represented by broken symlinks or pointer files.
+
+Sometimes it can be useful to hide the missing files, so you can focus on
+only the files whose content is available to use. This is possible to do,
+but it needs some different workflows of using git-annex.
+
+## getting started
+
+To get started, your repository needs to be upgraded to v7, since the
+feature does not work in v5 repositories.
+
+	git annex upgrade
+
+The [[git-annex adjust|git-annex-adjust]] command sets up an adjusted form
+of a git branch, in this case we'll ask it to hide missing files.
+
+	git annex adjust --hide-missing
+
+And now the working tree only contains annexed files whose content is
+present. Files with missing content are gone (but not forgotten).
+
+The command switched to a branch with a name like "master(hidemissing)". Since
+it's a regular git branch, you can switch back and forth between it and the
+full branch at any time:
+
+	git checkout master
+	...
+	git checkout "master(hidemissing)"
+
+## git commands in the adjusted branch
+
+When in the adjusted branch, you can use the usual git commands, adding files,
+renaming them, and deleting them, and committing. But bear in mind you're not
+in the master branch, and so your commits won't touch the master branch. So,
+you need a way to update the master branch the changes you made to the adjusted
+branch. That's easy, just sync:
+
+	touch new-file
+	git annex add new-file
+	git commit -m 'added a file'
+	git annex sync --no-push --no-pull
+
+That sync updated the master branch, cherry-picking the commit into it:
+
+	> git log --stat master -n 1
+	commit 175ce2309a9a6f61b2c918f0878ea3060eab10ea
+	Author: Joey Hess <joeyh@joeyh.name>
+	Date:   Sat Oct 20 12:12:00 2018 -0400
+	
+	    added a file
+	
+	 new-file | 1 +
+	 1 file changed, 1 insertion(+)
+
+Similarly, you can delete a file and sync, and it will be removed from the master
+branch. 
+
+[[!template id=note text="""
+A tricky point, that's worth mentioning here is that, when you `git annex drop`
+a file, and then delete it, and sync, it *won't* be removed from the master branch. 
+
+Why not? Well, the adjusted branch hides missing files; after dropping the file
+is missing, and after deletion it's hidden. And you generally don't want to
+remove hidden files from the master branch in a sync from the adjusted branch.
+
+If that seems complicated, don't worry, the behavior will probably
+make sense when you encounter this situation.
+"""]]
+
+You can also use `git annex sync` to pull changes from remotes into the adjusted
+branch. It will automatically filter out missing files while merging the other
+changes.
+
+So that's all the usual git operations covered; you can use regular git commands
+on the working tree and to commit files, and you use `git annex sync` to push
+and pull. Now we need to talk about git-annex operations that get or drop
+content, which can be tricky since missing files are hidden.
+
+## getting and dropping files
+
+So, you're in a branch, missing files are hidden, and you want git-annex to get
+some file. What do you do?
+
+	> git annex get some_file
+	git-annex: some_file not found
+	git-annex: get: 1 failed
+
+Well of course, that doesn't work, the file's pointer is not in the working tree;
+it's been hidden. Asking git-annex to get a whole directory won't work either;
+all files in the working tree are present so it won't find any missing ones to
+operate on. (This might be improved later, but it's how things are currently.)
+
+What will work is to use `git annex sync`, which knows you're in an adjusted branch
+and can get hidden files.
+
+	git annex sync --content-of some_file --no-push --no-pull
+
+Unlike getting files that are hidden, dropping files is no problem, since
+the file you want to drop will be present. But, after dropping a file,
+it won't be hidden right away. This is because updating the adjusted branch to
+hide the dropped file is a bit expensive. Here's how to drop and then hide
+files:
+
+	git annex drop some_file
+	git annex adjust --hide-missing
+
+Re-running `git annex adjust` while in the adjusted branch updates the branch
+to hide any newly missing files, and unhide any files whose content is
+now present. (Running `git annex sync` also does that, along with the other
+syncing.)
+
+If this seems a bit of a pain, read on for a simpler way ...
+
+## a simple workflow
+
+Here's how I use this for my podcasts repository. I [[use git-annex to download
+podcasts|downloading_podcasts]] to a server. I want to keep all the podcasts,
+but on my laptop of phone, I mostly want to only see podcasts I've not already
+listened to.
+
+I set up the repository like this:
+
+	git clone server:/path/to/podcasts
+	cd podcasts
+	git annex upgrade
+	git annex adjust --hide-missing
+	git annex group here client
+	git annex wanted here standard
+
+The last two commands make the repository use the 
+[[standard preferred content setting for client repositories|preferred_content/standard_groups]],
+so it wants to get a copy of all files except for files inside "archive"
+directories. When I'm done with listening to a podcast, I'll move it into an
+"archive" directory to indicate I'm done with it.
+
+To download all the new podcasts and make the files visible,
+and drop the drop the archived podcasts, and hide their files, I now
+only need to run one command:
+
+	git annex sync --content
+
+Later, when I want to revisit an old podcast, I can simply check
+out the master branch to make all the old files appear, and
+`git annex get` the one I want.
diff --git a/doc/tips/hiding_missing_files/comment_1_eba2b140f9d5a9f7ee23cb3ba7da7612._comment b/doc/tips/hiding_missing_files/comment_1_eba2b140f9d5a9f7ee23cb3ba7da7612._comment
new file mode 100644
index 0000000000..d04505e09e
--- /dev/null
+++ b/doc/tips/hiding_missing_files/comment_1_eba2b140f9d5a9f7ee23cb3ba7da7612._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="comment 1"
+ date="2019-03-07T20:15:10Z"
+ content="""
+i have had many problems trying this on a ntfs filesystem. the idea was to share files with a friend using a Mac (we're desperate) and having a partial checkout that only showed the files that were present.
+
+first, `git annex upgrade --version=7` doesn't work - i don't know when or if [[git-annex-upgrade]] ever supported that option.
+
+then `git annex sync --content some_file some_directory --no-push --no-pull` doesn't work either: this will tell you that `some_file` is not a remote, because that's the argument git-annex expects to `sync`. I tried the `-C` (`--content-of`) option, but it doesn't work on missing files:
+
+    git-annex: /media/anarcat/red-rhl/video/tv/directory/missing-file.mkv not found
+
+note that this is the local repository path, not the remote. `missing-file.mkv` *is* present on the remote, but is totally missing locally. I have no idea how I can fetch that file, even in unlocked mode, it's really strange... -- [[anarcat]]
+"""]]
diff --git a/doc/tips/hiding_missing_files/comment_2_9bff461eb281f67d169d4be30129bc13._comment b/doc/tips/hiding_missing_files/comment_2_9bff461eb281f67d169d4be30129bc13._comment
new file mode 100644
index 0000000000..108c2aa3c1
--- /dev/null
+++ b/doc/tips/hiding_missing_files/comment_2_9bff461eb281f67d169d4be30129bc13._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-03-22T13:50:10Z"
+ content="""
+I've fixed the two problems you spotted in the tip.
+
+git annex sync -C does work for me to get missing files.
+It would be good to file a bug report if you know how to make it not work.
+"""]]
diff --git a/doc/tips/imapannex.mdwn b/doc/tips/imapannex.mdwn
new file mode 100644
index 0000000000..eed2d4ab74
--- /dev/null
+++ b/doc/tips/imapannex.mdwn
@@ -0,0 +1,25 @@
+imapannex 0.2.0
+=========
+
+Hook program for gitannex to use imap as backend
+
+# Requirements:
+
+    python2
+
+# Install
+Clone the git repository in your home folder.
+
+    git clone git://github.com/TobiasTheViking/imapannex.git 
+
+This should make a ~/imapannex folder
+
+# Setup
+Make the file executable, and link it into PATH
+
+    cd ~/imapannex; chmod +x git-annex-remote-imap; sudo ln -sf `pwd`/git-annex-remote-imap /usr/local/bin/git-annex-remote-imap
+
+# Commands for gitannex:
+
+    USERNAME="username@provider.com" PASSWORD="password" git annex initremote imap type=external externaltype=imap encryption=shared folder=gitannex method="Normal password" ssl="SSL/TLS" host="imap.host.com" port="993"
+    git annex describe imap "the imap library"
diff --git a/doc/tips/install_on_Android_in_Termux.mdwn b/doc/tips/install_on_Android_in_Termux.mdwn
new file mode 100644
index 0000000000..5112377fec
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux.mdwn
@@ -0,0 +1 @@
+The content that was here has moved to [[Android]].
diff --git a/doc/tips/install_on_Android_in_Termux/comment_1_dc277facdcfba4e175831467b0e450d5._comment b/doc/tips/install_on_Android_in_Termux/comment_1_dc277facdcfba4e175831467b0e450d5._comment
new file mode 100644
index 0000000000..28ecb70df5
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/comment_1_dc277facdcfba4e175831467b0e450d5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-11T17:26:38Z"
+ content="""
+Bunch of old comments about problems with this that have been fixed were
+moved to [[old_comments]].
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments.mdwn b/doc/tips/install_on_Android_in_Termux/old_comments.mdwn
new file mode 100644
index 0000000000..78102c78a0
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments.mdwn
@@ -0,0 +1 @@
+Some old comments, all obsoleted now. --[[Joey]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_10_8c24553afc5352c8a4c9cd0555423325._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_10_8c24553afc5352c8a4c9cd0555423325._comment
new file mode 100644
index 0000000000..087fb6c113
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_10_8c24553afc5352c8a4c9cd0555423325._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Debugging &quot;No such file or directory&quot;"
+ date="2018-05-15T19:57:34Z"
+ content="""
+Setting all the environment variables from inside still did not break the tar execution; last resort was disabling proot in runshell. I still had to keep the termux-fix-shebang workaround.
+
+    $ ./git-annex.linux/runshell
+    $ mkdir test; cd test
+    $ git init
+    $ git annex init
+
+From a first glance, things appear to be working now. I had to run termux-fix-shebang on the `.git/hooks/*` and set TMPDIR=something-that-actually-exists, but short of that, local adding and committing as well as moving data around.
+
+Joey, you mentioned ghc runtime issues when introducing proot. Anything particular I should test?
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_11_8f5f8f47305b45dca53222ac0e3bde29._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_11_8f5f8f47305b45dca53222ac0e3bde29._comment
new file mode 100644
index 0000000000..a3cc6759ce
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_11_8f5f8f47305b45dca53222ac0e3bde29._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Platform addendum for &quot;Debugging &quot;No such file or directory&quot;&quot;"
+ date="2018-05-15T20:29:57Z"
+ content="""
+Probably should have given some platform details to my findings that proot is counter-productive on my device: I'm running LineageOS 14.1-20180206-NIGHTLY-gts210vewifi (LineageOS API level 7, Android 7.1.2, Kernel 3.10.102) on a Samsung SM-T813 (arm64).
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_12_a7bbf9e61e2e993eca9a9222de899920._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_12_a7bbf9e61e2e993eca9a9222de899920._comment
new file mode 100644
index 0000000000..474b3baab4
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_12_a7bbf9e61e2e993eca9a9222de899920._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="madapeedikakkaran@2c5c8bb4520ebf2526afb49c8dcbcb60fb295973"
+ nickname="madapeedikakkaran"
+ avatar="http://cdn.libravatar.org/avatar/15c58acba4fc6f75abd783d5836e0254"
+ subject="Termux Error"
+ date="2018-06-12T11:54:02Z"
+ content="""
+I followed the instruction to install git-annex on my Lenovo Vibe K4 running Android 6
+
+At first I got the error `/bin/sh/ is missing`, which I worked around with termux-fix-shebang on runshell. Now I am getting this error. 
+
+`proot info: vpid 1: terminated with signal 11`
+
+Please advice. 
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_13_b46679eac8d4d86b2abe9baff1f0a609._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_13_b46679eac8d4d86b2abe9baff1f0a609._comment
new file mode 100644
index 0000000000..3c9081ff41
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_13_b46679eac8d4d86b2abe9baff1f0a609._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="bqone@ea19c1433d6c23d05a56fe7b055d92010ab75ffb"
+ nickname="bqone"
+ avatar="http://cdn.libravatar.org/avatar/b7e0d9ab01e602042db731ee959d8f7e"
+ subject="Not working on OnePlus 6"
+ date="2018-06-25T15:57:13Z"
+ content="""
+I copied and pasted the instructions, here is my output:
+
+https://pastebin.com/ZVJ7uSeU
+
+Almoços for including my entire session, the relevant error is at the bottom.
+
+I'm fairly certain this device has ARM64 arch.
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_14_20a995c941f9a3582a8913d412e3d090._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_14_20a995c941f9a3582a8913d412e3d090._comment
new file mode 100644
index 0000000000..f694589b05
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_14_20a995c941f9a3582a8913d412e3d090._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="Not working on OnePlus 5T either"
+ date="2018-06-26T10:32:09Z"
+ content="""
+As I mentioned in [Package request: git-annex · Issue #420 · termux/termux-packages](https://github.com/termux/termux-packages/issues/420#issuecomment-400258309) just now, I also get:
+
+    % ./git-annex.linux/runshell
+    proot info: vpid 1: terminated with signal 11
+
+Some further digging suggests that this is due to the architecture mismatch between my OnePlus 5T which is aarch64, and the linker which is 32-bit:
+
+    % PROOT_VERBOSE=9 ./git-annex.linux/runshell |& tail -n3
+    proot info: vpid 1: translate(\"/\" + \"/data/data/com.termux/files/home/git-annex.linux/lib/ld-linux.so.3\")
+    proot info: vpid 1:          -> \"/data/data/com.termux/files/home/git-annex.linux/lib/ld-linux.so.3\"
+    proot info: vpid 1: terminated with signal 11
+    % file /data/data/com.termux/files/home/git-annex.linux/lib/ld-linux.so.3
+    /data/data/com.termux/files/home/git-annex.linux/lib/ld-linux.so.3: ELF 32-bit LSB pie executable ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=59819e8e8c922b822204d3778cd4d6c843422462, stripped
+    % termux-info
+    Updatable packages:
+    All packages up to date
+    System information:
+    Linux localhost 4.4.78-perf+ #1 SMP PREEMPT Wed Jun 13 17:23:58 CST 2018 aarch64 Android
+    Termux-packages arch:
+    aarch64
+    Android version:
+    8.1.0
+    Device manufacturer:
+    OnePlus
+    Device model:
+    ONEPLUS A5010
+
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_15_387e69f3ed94a00c01b0a097132f989c._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_15_387e69f3ed94a00c01b0a097132f989c._comment
new file mode 100644
index 0000000000..c12649af28
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_15_387e69f3ed94a00c01b0a097132f989c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 15"
+ date="2018-06-26T10:38:21Z"
+ content="""
+Running
+
+    termux-fix-shebang git-annex.linux/bin/*
+
+actually seems to have fixed my installation. `runshell` and `webapp` both execute now, with webapp bringing up the browser.
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_16_2d7181f765cdbf545f161825c4cfeca9._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_16_2d7181f765cdbf545f161825c4cfeca9._comment
new file mode 100644
index 0000000000..d1938acb52
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_16_2d7181f765cdbf545f161825c4cfeca9._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="still broken on aarch64"
+ date="2018-07-29T08:48:22Z"
+ content="""
+I didn't explicitly mention it in my last comment (only in [the issue I linked to](https://github.com/termux/termux-packages/issues/420#issuecomment-400258309)), but I had already applied the `termux-fix-shebang` fix.  Whilst this helps resolve the other issue, it does *not* help with the fact that `./git-annex.linux/lib/ld-linux.so.3` is a 32-bit binary which crashes with a segfault (SIG11) when run via `runshell`.
+
+So this is still broken for me :-(  Has anyone else had better luck on aarch64 (ARM v8) ?
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_17_37ba50a8378b2ac3d920fc8155eea42a._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_17_37ba50a8378b2ac3d920fc8155eea42a._comment
new file mode 100644
index 0000000000..34b6f2577c
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_17_37ba50a8378b2ac3d920fc8155eea42a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="msloco@dab095e2e54192078b3eedcd000f7d838a169f5b"
+ nickname="msloco"
+ avatar="http://cdn.libravatar.org/avatar/50b4d89811af4f1413ab778c9e998ee4"
+ subject="samee here"
+ date="2018-07-31T22:21:48Z"
+ content="""
+Aarch64 incurs signal 11
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_18_c1b5fefdc9a654579d0ada3db7a40ad8._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_18_c1b5fefdc9a654579d0ada3db7a40ad8._comment
new file mode 100644
index 0000000000..70066392ac
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_18_c1b5fefdc9a654579d0ada3db7a40ad8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Teyras"
+ avatar="http://cdn.libravatar.org/avatar/d874f8fa5e6480461f368400b9089a2f"
+ subject="gcrypt support"
+ date="2018-10-06T12:14:44Z"
+ content="""
+Is it possible to use gcrypt remotes when running git-annex in Termux?
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_19_5e0aa7c4341867374a67f5fe0a242e00._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_19_5e0aa7c4341867374a67f5fe0a242e00._comment
new file mode 100644
index 0000000000..7545c018e6
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_19_5e0aa7c4341867374a67f5fe0a242e00._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2018-10-08T16:09:26Z"
+ content="""
+@Teyras, I think this would be possible, but you'd have to get gpg and
+git-remote-gcrypt installed and working in that environment.
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_1_320b1fa3328cf8b8e584e72a9cd7735a._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_1_320b1fa3328cf8b8e584e72a9cd7735a._comment
new file mode 100644
index 0000000000..9e937b6e04
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_1_320b1fa3328cf8b8e584e72a9cd7735a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="hobbes@b2cacef69071743c3a831e60511062f7e014e52f"
+ nickname="hobbes"
+ avatar="http://cdn.libravatar.org/avatar/44b70169c4d862b3619812c360aa8f1e"
+ subject="Bad system call"
+ date="2018-04-26T19:36:44Z"
+ content="""
+This line causes termux to say \"Bad System Call\"
+
+git-annex.linux/runshell
+
+It also first complained about /bin/sh being missing, but stopped after restarting termux.
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_20_9651ab0e1e43d193cca16963f5fde858._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_20_9651ab0e1e43d193cca16963f5fde858._comment
new file mode 100644
index 0000000000..815b3b469c
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_20_9651ab0e1e43d193cca16963f5fde858._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="aarch64 still broken, please help"
+ date="2018-10-09T09:17:11Z"
+ content="""
+@joey, any update on this signal 11 issue?  Currently we aarch64 users are completely stuck, AFAICS.  Thanks!
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_21_3d1c6a1dc4ff8f04dffa4a02ad56fef2._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_21_3d1c6a1dc4ff8f04dffa4a02ad56fef2._comment
new file mode 100644
index 0000000000..7a6d537feb
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_21_3d1c6a1dc4ff8f04dffa4a02ad56fef2._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 21"""
+ date="2018-10-10T20:14:17Z"
+ content="""
+Well, I see the signal 11 too, on my arm64 phone running LineageOS Android 8.1. 
+Some others had earlier reported it worked on arm64, but perhaps newer
+versions of Android don't or whatever.
+
+I made a test arm64 build, and it does work. Get it here:
+<https://tmp.joeyh.name/git-annex-arm64-test-build/>
+
+(I also had to run termux-fix-shebang as described above.) 
+
+I do not yet have an arm64 autobuilder running, todo for that is
+[[todo/arm64_autobuilder]] -- if anyone has an arm64 machine that could run
+the autobuilder, that would help!
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_22_39e2f2100a49f986760db389cf10240b._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_22_39e2f2100a49f986760db389cf10240b._comment
new file mode 100644
index 0000000000..accc0561c7
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_22_39e2f2100a49f986760db389cf10240b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="Works now!!"
+ date="2018-10-11T16:09:00Z"
+ content="""
+Thanks a lot @joey, after running `termux-fix-shebang git-annex.linux/bin/*` this new build works!
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_2_3a8c8facaa8b2989c88ebaabb984c7de._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_2_3a8c8facaa8b2989c88ebaabb984c7de._comment
new file mode 100644
index 0000000000..fea67485f1
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_2_3a8c8facaa8b2989c88ebaabb984c7de._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-04-27T17:13:08Z"
+ content="""
+@hobbes we're working on that issue, which seems likely to involve arm64,
+here: https://github.com/termux/termux-packages/issues/420
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_2_663de2e553ea050dd5a00fc88aeb6412._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_2_663de2e553ea050dd5a00fc88aeb6412._comment
new file mode 100644
index 0000000000..8337b7db15
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_2_663de2e553ea050dd5a00fc88aeb6412._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="hobbes@b2cacef69071743c3a831e60511062f7e014e52f"
+ nickname="hobbes"
+ avatar="http://cdn.libravatar.org/avatar/44b70169c4d862b3619812c360aa8f1e"
+ subject="Bad system call fix"
+ date="2018-04-30T15:01:09Z"
+ content="""
+Found this issue thread:
+
+https://github.com/termux/termux-packages/issues/420
+
+which had the solution to this particular issue! Yay \o/! Needed to call
+
+```
+unset LD_PRELOAD
+```
+
+I'm noticing that the arm builds are missing now (current 403s, autobuild 404s), but maybe that's intentional for now? Either way, I have gotten past the bad system call issue with `runshell`, but now when I try to run `git annex webapp` I get...
+
+```
+fatal: 'annex' appears to be a git command, but we were not able to execute it. Maybe you need to 'pkg install perl'?
+```
+
+I ran `pkg install perl`, but I get the same message :(. Either way, I'm glad this seems to be moving forward, and very excited that I might finally be able to put git-annex back on my phone after all these years!
+
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_4_338e7f1b0fdf273d5fa453fe8ed2578b._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_4_338e7f1b0fdf273d5fa453fe8ed2578b._comment
new file mode 100644
index 0000000000..47d8c5a1d7
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_4_338e7f1b0fdf273d5fa453fe8ed2578b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-04-30T20:07:00Z"
+ content="""
+@hobbes, that error means Android's system call filter has blocked
+a system call that's needed to run git-annex, unfortunately.
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_5_82c4de6ad0ff016e72133d2552b5158d._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_5_82c4de6ad0ff016e72133d2552b5158d._comment
new file mode 100644
index 0000000000..4c74bcabda
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_5_82c4de6ad0ff016e72133d2552b5158d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-05-05T12:57:00Z"
+ content="""
+We now have a workaround that seems to work, `pkg install proot` and use
+proot to run git-annex. Tomorrrow's daily build of the git-annex standalone 
+bundle will do that automatically.
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_6_66bfd7ca3dd81bb7632cb91fd8637dae._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_6_66bfd7ca3dd81bb7632cb91fd8637dae._comment
new file mode 100644
index 0000000000..9589d23952
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_6_66bfd7ca3dd81bb7632cb91fd8637dae._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 6"
+ date="2018-05-10T10:23:49Z"
+ content="""
+Are the instructions complete/correct? I get an error when following them and trying to execute runshell. Seems to be looking in the wrong place for /bin/sh.
+
+    $ git-annex.linux/runshell
+    proot-error: execve(\"/data/data/com.termux/files/home/git-annex.linux/bin/sh\"): No such file or directory
+
+
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_7_b475d3c36cf6d52d6b4720d00a5ae245._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_7_b475d3c36cf6d52d6b4720d00a5ae245._comment
new file mode 100644
index 0000000000..f0996d87ff
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_7_b475d3c36cf6d52d6b4720d00a5ae245._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2018-05-15T15:54:54Z"
+ content="""
+@CandyAngel git-annex.linux/bin/sh is included in the bundle.
+If proot cannot run it, it seems likely that you have downloaded a build of
+git-annex that does not match the CPU architecure of your Android device.
+While most Android devices are arm, some use intel or mips..
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_8_35329178895fc03395f08a37044e7c94._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_8_35329178895fc03395f08a37044e7c94._comment
new file mode 100644
index 0000000000..c38d5c8c9e
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_8_35329178895fc03395f08a37044e7c94._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 8"
+ date="2018-05-15T16:15:32Z"
+ content="""
+My phone is an ARMv7, according to /proc/cpuinfo in Termux, so armel would be the correct package? That is the one I have installed..
+"""]]
diff --git a/doc/tips/install_on_Android_in_Termux/old_comments/comment_9_7ae18460ca6201cc313215a8a03e0d57._comment b/doc/tips/install_on_Android_in_Termux/old_comments/comment_9_7ae18460ca6201cc313215a8a03e0d57._comment
new file mode 100644
index 0000000000..00d7c57358
--- /dev/null
+++ b/doc/tips/install_on_Android_in_Termux/old_comments/comment_9_7ae18460ca6201cc313215a8a03e0d57._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Debugging &quot;No such file or directory&quot;"
+ date="2018-05-15T19:19:38Z"
+ content="""
+I'm experiencing the same issue as CandyAngel on an arm64 tablet (which should be able to execute regular arm code).
+
+Tracing down from the error message:
+
+    $ ./git-annex.linux/runshell
+    proot error: execve(\"/data/data/com.termux/files/home/git-annex.linux/bin/sh\"): No such file or directory
+    [...]
+    $ head -n1 /data/data/com.termux/files/home/git-annex.linux/bin/sh
+    #!/bin/sh
+    $ which sh
+    /data/data/com.termux/files/usr/bin/sh
+
+So it might just be that the different environments disagree which sh is now executable. For contrast, trying a bash (which is not in /bin/):
+
+    $ ./git-annex.linux/runshell bash
+    bash-4.4$ git-annex
+    bash: /data/data/com.termux/files/home/git-annex.linux/bin/git-annex: /bin/sh: bad interpreter: No such file or directory
+
+Ok, /bin/sh is obviously bad influence here.
+
+    $ termux-fix-shebang git-annex.linux/bin/*
+    $ ./git-annex.linux/runshell bash
+    bash-4.4$ git-annex
+    Segmentation fault
+
+At first glance this does sound like \"Mh, we can't execute 32bit binaries her\", but look:
+
+    bash-4.4$ ./git-annex.linux/lib/ld-linux.so.3  # that's what exe/sh is symliked to
+    Segmentation fault
+    $ exit                                         # now we're out of the runshell again
+    $ /git-annex.linux/lib/ld-linux.so.3
+    Usage: ld.so [OPTION]... EXECUTABLE-FILE [...]
+
+Something in the environment is breaking things. My current stage of drilling is that I can run the variables-expanded version of [[!toggle text=tar id=tarcommand]] [[!toggleable id=tarcommand \"\"\"
+``GIT_ANNEX_PROGRAMPATH=tar ./git-annex.linux/exe/tar --library-path /data/data/com.termux/files/home/git-annex.linux//usr/lib/arm-linux-gnueabi/gconv:/data/data/com.termux/files/home/git-annex.linux//usr/lib/arm-linux-gnueabi/audit:/data/data/com.termux/files/home/git-annex.linux//etc/ld.so.conf.d:/data/data/com.termux/files/home/git-annex.linux//lib:/data/data/com.termux/files/home/git-annex.linux//lib/arm-linux-gnueabi:/data/data/com.termux/files/home/git-annex.linux//usr/lib/arm-linux-gnueabi: ./git-annex.linux/shimmed/tar/tar --help``
+\"\"\"]] successfully from the outside but not from within runshell. Will update when I've found more.
+"""]]
diff --git a/doc/tips/largefiles.mdwn b/doc/tips/largefiles.mdwn
new file mode 100644
index 0000000000..5a5906bfbf
--- /dev/null
+++ b/doc/tips/largefiles.mdwn
@@ -0,0 +1,123 @@
+[[!meta title="annex.largefiles: configuring mixed content repositories"]]
+
+Normally commands like `git annex add` always add files to the annex,
+while `git add` adds files to git.
+
+Let's suppose you're developing a video game, written in C. You have
+source code, and some large game assets. You want to ensure the source
+code is stored in git -- that's what git's for! And you want to store
+the game assets in the git annex -- to avoid bloating your git repos with
+possibly enormous files, but still version control them.
+
+You could take care to use `git annex add` after changes to the assets,
+but it would be easy to slip up and `git commit -a` (which runs `git add`),
+checking your large assets into git. Configuring annex.largefiles
+saves you the bother of keeping things straight when adding files.
+Once you've told git-annex what files are large, both `git annex add`
+and `git add`/`git commit -a` will add the large files to the annex and the
+small files to git.
+
+Other commands that use the annex.largefiles configuration include
+`git annex import`, `git annex addurl`, `git annex importfeed`, and
+the assistant.
+
+## examples
+
+For example, let's make only files larger than 100 kb be added to the annex,
+and never `*.c` and `*.h` source code files.
+
+	git config annex.largefiles 'largerthan=100kb and not (include=*.c or include=*.h)'
+
+That is a local configuration, so will only apply to your clone of the
+repository. To set a default that will apply to all clones, unless
+overridden, do this instead:
+
+	git annex config --set annex.largefiles 'largerthan=100kb and not (include=*.c or include=*.h)'
+
+There's one other way to configure the same thing, you can put this in
+the `.gitattributes` file:
+
+	* annex.largefiles=largerthan=100kb
+	*.c annex.largefiles=nothing
+	*.h annex.largefiles=nothing
+
+The syntax in .gitattributes is a bit different, because the .gitattributes
+matches files itself, and the values of attributes cannot contain spaces.
+So using .gitattributes for this is not recommended (but it does work for
+older versions of git-annex, where the `git annex config` setting does
+not). Any .gitattributes setting overrides the `git annex config` setting,
+but will be overridden by the `git config` setting.
+
+Another example. If you wanted `git add` to put all files the annex
+in your local repository:
+
+	git config annex.largefiles anything
+
+Or in all clones:
+
+	git annex config --set annex.largefiles anything
+
+## syntax
+
+See [[git-annex-matching-expression]] for details about the syntax.
+
+## gitattributes format
+
+Here's that example `.gitattributes` again:
+
+	* annex.largefiles=largerthan=100kb
+	*.c annex.largefiles=nothing
+	*.h annex.largefiles=nothing
+
+The way that works is, `*.c` and `*.h` files have the annex.largefiles
+attribute set to "nothing", and so those files are never treated as large
+files. All other files use the other value, which checks the file size.
+
+Since git attribute values cannot contain whitespace, when you need
+a more complicated annex.largefiles expression, you can instead
+parenthesize the terms of the annex.largefiles attribute.
+For example, this is the same as the git config shown earlier, shoehorned
+into a single git attribute:
+
+	* annex.largefiles=(largerthan=100kb)and(not((include=*.c)or(include=*.h)))
+
+It's generally a better idea to use `git annex config` instead.
+
+## temporarily override
+
+If you've set up an annex.largefiles configuration but want to force a file to
+be stored in the annex, you can temporarily override the configuration like
+this:
+
+	git annex add --force-large smallfile
+
+## converting git to annexed
+
+When you have a file that is currently stored in git, and you want to
+convert that to be stored in the annex, here's how to accomplish that:
+
+	git rm --cached file
+	git annex add --force-large file
+	git commit file
+
+This first removes the file from git's index cache, and then adds it back
+using git-annex. You can modify the file before the `git-annex add` step,
+perhaps replacing it with new larger content that necessitates git-annex.
+
+The --force-large option needs git-annex version 7.20200202.7 or newer.
+
+## converting annexed to git
+
+When you have a file that is currently stored in the annex, and you want to
+convert that to be stored in git, here's how to accomplish that:
+
+	git annex unlock file
+	git rm --cached file
+	git annex add --force-small file
+	git commit file
+
+You can modify the file after unlocking it and before adding it to
+git. And this is probably a good idea if it was really a big file,
+so that you can replace its content with something smaller.
+
+The --force-small option needs git-annex version 7.20200202.7 or newer.
diff --git a/doc/tips/largefiles/comment_10_18f17926c44ea4b0c17a61a91c6bb5b5._comment b/doc/tips/largefiles/comment_10_18f17926c44ea4b0c17a61a91c6bb5b5._comment
new file mode 100644
index 0000000000..acd68b4ca9
--- /dev/null
+++ b/doc/tips/largefiles/comment_10_18f17926c44ea4b0c17a61a91c6bb5b5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="davicastro"
+ avatar="http://cdn.libravatar.org/avatar/4e708663cf4d5b9e8cfea74caf4307fc"
+ subject="Adopting &quot;git annex add&quot; as default command in workflow"
+ date="2018-03-08T11:21:55Z"
+ content="""
+Hi, from technical point of view, are there any drawbacks/limitations on adopting a workflow of everyone in the project using \"git annex add\" and relying on the annex.largefiles settings instead of them having to use the separate commands?
+* I would use repo v5 as repo v6 seems to still need work to do, and I don't need it's features. I just would like to avoid human error of people not using by mistake regular git add for bigfiles. I understand that repo v6 would allow, but I don't like it's default behavior of using unlocked mode when I add things with git add (although it would properly annex the files, but in unlocked mode these files would occupy space in the work copy, and I don't want that). Thanks.
+"""]]
diff --git a/doc/tips/largefiles/comment_11_e7c83e38c92b8fc91bae140c1d7c007d._comment b/doc/tips/largefiles/comment_11_e7c83e38c92b8fc91bae140c1d7c007d._comment
new file mode 100644
index 0000000000..a29114eebd
--- /dev/null
+++ b/doc/tips/largefiles/comment_11_e7c83e38c92b8fc91bae140c1d7c007d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Adopting "git annex add" as default command in workflow"""
+ date="2018-08-09T19:46:22Z"
+ content="""
+@davicastro yes, using git-annex add for adding both kinds of files is
+workflow this is about. Other than git add features like `--interactive`
+I see no need to ever use git add once you have this set up.
+"""]]
diff --git a/doc/tips/largefiles/comment_13_16176199c4c98c66dd40b5eae95122ed._comment b/doc/tips/largefiles/comment_13_16176199c4c98c66dd40b5eae95122ed._comment
new file mode 100644
index 0000000000..dff40c305d
--- /dev/null
+++ b/doc/tips/largefiles/comment_13_16176199c4c98c66dd40b5eae95122ed._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="lh"
+ avatar="http://cdn.libravatar.org/avatar/d31bade008d7da493d9bfb37d68fd825"
+ subject="Discrepancy between `git add` and `git annex add` when annex.largefiles is set"
+ date="2022-04-13T23:15:25Z"
+ content="""
+> Once you've told git-annex what files are large, both git annex add and git add/git commit -a will add the large files to the annex and the small files to git.
+
+I have a repo where I have run:
+    git annex config --set annex.largefiles '(mimeencoding=binary and not mimetype=inode/symlink) or mimeencoding=unknown-8bit'
+
+My git-annex package is built with support for MIME detection. It works for other files. But I have noticed that for certain files, `git add` does not add them to the annex. I have verified the MIME type and encoding with `file` so that I could check `git annex matchexpression`, and it matches. What might be happening here?
+"""]]
diff --git a/doc/tips/largefiles/comment_13_b541d011d4c7f23227426c783a4bdc20._comment b/doc/tips/largefiles/comment_13_b541d011d4c7f23227426c783a4bdc20._comment
new file mode 100644
index 0000000000..9981bb5614
--- /dev/null
+++ b/doc/tips/largefiles/comment_13_b541d011d4c7f23227426c783a4bdc20._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="Can conversion to/from annexed be made easier?"
+ date="2019-09-29T22:04:32Z"
+ content="""
+IMHO it's somewhat user-unfriendly and error-prone to have to remember a sequence of three commands to convert an unannexed file to annexed, or vice-versa.  So it would be nice if there were git-annex commands to do this in one go.
+
+In fact, I would expect `git annex add` to handle adding to the annex, and `git annex unannex` to do the opposite.  Are there good reasons why they should not be made to do that?  Even if there are, aren't those subcommands already doing very similar things?  In which case maybe the solution would be to add extra option to each to enable this behaviour?  For example `--force` or something like that in order to tell it to ignore `annex.largefiles` (although for `add` that is already used to allow adding ignored files, so we probably shouldn't conflate the two cases under one option).
+"""]]
diff --git a/doc/tips/largefiles/comment_14_2f8d8e73e4218b1e36e358770016cabe._comment b/doc/tips/largefiles/comment_14_2f8d8e73e4218b1e36e358770016cabe._comment
new file mode 100644
index 0000000000..a29fe44937
--- /dev/null
+++ b/doc/tips/largefiles/comment_14_2f8d8e73e4218b1e36e358770016cabe._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="Follow-up thought"
+ date="2019-09-29T22:08:29Z"
+ content="""
+Afterthought on the immediately preceding comment - if the intention of `unannex` is to reverse `add`, then IMHO `unadd` or `undo-add` seem like more logical choices.  Renaming to one of these would free up `unannex` for the conversion use case.  But I appreciate that this is potentially confusing for users already used to `unannex`'s current behaviour, so I expect the idea will be rejected.
+"""]]
diff --git a/doc/tips/largefiles/comment_14_cd71d1c6e69a9fc7feadf9aa6a39c406._comment b/doc/tips/largefiles/comment_14_cd71d1c6e69a9fc7feadf9aa6a39c406._comment
new file mode 100644
index 0000000000..b40aff5619
--- /dev/null
+++ b/doc/tips/largefiles/comment_14_cd71d1c6e69a9fc7feadf9aa6a39c406._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2022-04-19T16:03:49Z"
+ content="""
+@lh two possibilities are:
+
+1. When `git add` is run, git-annex does some additional checks to detect
+   things like a file that was checked into git before but has been
+   renamed, and will avoid annexing such a file even when annex.largefiles
+   says to.
+2. Perhaps `git add` is finding some other git-annex
+   version that behaves differently. Seems unlikely, but possible.
+"""]]
diff --git a/doc/tips/largefiles/comment_15_d1f24df21ac577b89a8ae385532de6f2._comment b/doc/tips/largefiles/comment_15_d1f24df21ac577b89a8ae385532de6f2._comment
new file mode 100644
index 0000000000..f5c2110e06
--- /dev/null
+++ b/doc/tips/largefiles/comment_15_d1f24df21ac577b89a8ae385532de6f2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="lh"
+ avatar="http://cdn.libravatar.org/avatar/d31bade008d7da493d9bfb37d68fd825"
+ subject="comment 15"
+ date="2022-04-21T01:18:21Z"
+ content="""
+@joey Thanks. I don't think 2 is even possible since I just installed git-annex. 1 seems likely. I'm guessing that could occur if I previously ran `git annex add` with a different `annex.largefiles` that caused some files to be added (though not committed) via git rather than git-annex? That's roughly the scenario I was in.
+"""]]
diff --git a/doc/tips/largefiles/comment_16_4c6f52958246757dfbedd0b410d43ffe._comment b/doc/tips/largefiles/comment_16_4c6f52958246757dfbedd0b410d43ffe._comment
new file mode 100644
index 0000000000..7575720540
--- /dev/null
+++ b/doc/tips/largefiles/comment_16_4c6f52958246757dfbedd0b410d43ffe._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="imlew"
+ avatar="http://cdn.libravatar.org/avatar/23858c3eed3c3ea9e21522f4c999f1ed"
+ subject="comment 16"
+ date="2023-12-12T13:32:17Z"
+ content="""
+I thought I had the same problem as lh (`git add` not respecting the largefiles config), but when I tried to make a minimal example I noticed that `git add` does add files to the annex, it just doesn't print the progress message that `git annex add` usually prints.
+
+Is there any way to get it to do that?
+It would help newbs like me know that largefiles is indeed working and for files that are actually large it can be helpful to see the progress.
+"""]]
diff --git a/doc/tips/largefiles/comment_17_066fdebc2655dd11077fda1ef6e102e4._comment b/doc/tips/largefiles/comment_17_066fdebc2655dd11077fda1ef6e102e4._comment
new file mode 100644
index 0000000000..7f862aa4b7
--- /dev/null
+++ b/doc/tips/largefiles/comment_17_066fdebc2655dd11077fda1ef6e102e4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 17"""
+ date="2023-12-18T17:52:30Z"
+ content="""
+@imlew `git add` runs git-annex as a filter, so it cannot output progress
+displays or other messages on stdout at that point. It would have to output
+to stderr, but outputting non-errors to stderr is not great either.
+"""]]
diff --git a/doc/tips/largefiles/comment_1_b84e5cb8316c30fc7b355234384a5899._comment b/doc/tips/largefiles/comment_1_b84e5cb8316c30fc7b355234384a5899._comment
new file mode 100644
index 0000000000..79374cd14a
--- /dev/null
+++ b/doc/tips/largefiles/comment_1_b84e5cb8316c30fc7b355234384a5899._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="acbg@8d58f794ce92f6be28b5dbd402059bc30262eb92"
+ nickname="acbg"
+ subject="Since which version does this apply?"
+ date="2016-03-03T16:16:28Z"
+ content="""
+I use version 5.20140412, and I've tried the annex.largefiles in .gitattributes, but doesn't work.   Every file is added to .git/annex/objects, including the ones that are excluded in .gitattributes.
+
+I've just started using git-annex so maybe I'm doing something wrong...
+"""]]
diff --git a/doc/tips/largefiles/comment_2_825b72391117f88062a585684cf62eeb._comment b/doc/tips/largefiles/comment_2_825b72391117f88062a585684cf62eeb._comment
new file mode 100644
index 0000000000..316f33c2af
--- /dev/null
+++ b/doc/tips/largefiles/comment_2_825b72391117f88062a585684cf62eeb._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="workspace"
+ subject="same problem"
+ date="2016-03-04T20:44:26Z"
+ content="""
+I have the same problem:
+the annex.largefiles is ignored by \"git add\" when set in .gitattributes
+allthouch git check-attr does list it.
+
+but it works when set with git config annex.largefiles
+
+git annex version 6.20160126
+"""]]
diff --git a/doc/tips/largefiles/comment_3_f4df42fe943011cc8feb2921a59616e9._comment b/doc/tips/largefiles/comment_3_f4df42fe943011cc8feb2921a59616e9._comment
new file mode 100644
index 0000000000..b266607781
--- /dev/null
+++ b/doc/tips/largefiles/comment_3_f4df42fe943011cc8feb2921a59616e9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-03-07T17:23:19Z"
+ content="""
+The first version to support largefiles in .gitattributes was 6.20160211,
+so both the above commenters just have too old a version.
+"""]]
diff --git a/doc/tips/largefiles/comment_4_b6380286f60c1cd46a82a2e90c7aa05f._comment b/doc/tips/largefiles/comment_4_b6380286f60c1cd46a82a2e90c7aa05f._comment
new file mode 100644
index 0000000000..359c01e4d2
--- /dev/null
+++ b/doc/tips/largefiles/comment_4_b6380286f60c1cd46a82a2e90c7aa05f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="christophfischer@4706e95f48874dfd46092b278315693b92ea7d23"
+ nickname="christophfischer"
+ subject="how to recursively exclude files from git-annex (.gitattributes)"
+ date="2016-06-21T11:42:37Z"
+ content="""
+Hello 
+
+it took me some time to figure out how to exclude directories matching a specific structure within the .gitattributes file: 
+
+    **/some_dir/**/below_this_dir_is_everything_in_plane_text/**/* annex.largefiles=nothing
+
+Maybe it helps someone else. (In case this way is the intended way)
+"""]]
diff --git a/doc/tips/largefiles/comment_5_20c6702f83dbade1ac4d6eee30c40b4b._comment b/doc/tips/largefiles/comment_5_20c6702f83dbade1ac4d6eee30c40b4b._comment
new file mode 100644
index 0000000000..1bded6026c
--- /dev/null
+++ b/doc/tips/largefiles/comment_5_20c6702f83dbade1ac4d6eee30c40b4b._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joern.mankiewicz@06fb5bc9b732f143dee3606866362f562531310d"
+ nickname="joern.mankiewicz"
+ avatar="http://cdn.libravatar.org/avatar/446365f4d50dddc42965fa0432e70cdb"
+ subject="Git-annex ignores annex.largefiles in .gitattributes"
+ date="2017-03-20T20:58:12Z"
+ content="""
+Hi guys!
+
+*sigh*
+
+Currently I am pulling my hair, maybe anybody here can clear things up a bit. I tried to setup a brand new mixed content repo with git-annex but it bluntly ignores my .gitattributes and annexes everything. When I set largefiles in config everything is fine and restrictions are applied right, in .gitattributes even a \"* annex.largefiles=nothing\" has no effect. All attributes show up right with git check-attr, I double checked. :-/ Same thing with a newly initialized minimal example repo. 
+
+I tried git-annex as distributed by openSUSE and the current stand-alone-package (in case it's a distribution bug), too. So no clues here, too.
+
+Output of git annex version:
+
+git-annex version: 6.20170302-gb35a50cca
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+
+System: OpenSUSE Tumbleweed
+Linux 4.9.3-1-default #1 SMP PREEMPT Thu Jan 12 11:32:53 UTC 2017 (2c7dfab) x86_64 x86_64 x86_64 GNU/Linux
+
+
+Any ideas? After trying around for hours I am somewhat flabberghasted. Did I miss some config- or buildoption to enable support for .gitattributes? 
+
+Kind regards
+
+Jörn
+"""]]
diff --git a/doc/tips/largefiles/comment_6_639b1492271643566846b48fe13f7b8d._comment b/doc/tips/largefiles/comment_6_639b1492271643566846b48fe13f7b8d._comment
new file mode 100644
index 0000000000..7c5733fd39
--- /dev/null
+++ b/doc/tips/largefiles/comment_6_639b1492271643566846b48fe13f7b8d._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2017-03-20T21:16:30Z"
+ content="""
+@joern.mankiewicz, you need to file a bug report with enough information to
+reproduce your problem.
+
+annex.largefiles in .gitattributes works fine:
+
+	joey@darkstar:~/tmp> git init ttt
+	Initialized empty Git repository in /home/joey/tmp/ttt/.git/
+	joey@darkstar:~/tmp> cd ttt
+	joey@darkstar:~/tmp/ttt> git annex init
+	init  ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/ttt> echo '* annex.largefiles=nothing' > .gitattributes
+	joey@darkstar:~/tmp/ttt> touch foo
+	joey@darkstar:~/tmp/ttt> git annex add foo
+	add foo (non-large file; adding content to git repository) ok
+	(recording state in git...)
+"""]]
diff --git a/doc/tips/largefiles/comment_7_35a634c5e6d780972b9e938065837988._comment b/doc/tips/largefiles/comment_7_35a634c5e6d780972b9e938065837988._comment
new file mode 100644
index 0000000000..bcb87bb981
--- /dev/null
+++ b/doc/tips/largefiles/comment_7_35a634c5e6d780972b9e938065837988._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2017-03-20T21:18:24Z"
+ content="""
+Note that if annex.largefiles is set in git config (including global git
+config), it overrides the .gitattributes setting. So a reasonable guess
+would be that you set it in the git config.
+"""]]
diff --git a/doc/tips/largefiles/comment_8_f036356b23a4690705a2b4df604e82ba._comment b/doc/tips/largefiles/comment_8_f036356b23a4690705a2b4df604e82ba._comment
new file mode 100644
index 0000000000..d9845890fe
--- /dev/null
+++ b/doc/tips/largefiles/comment_8_f036356b23a4690705a2b4df604e82ba._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joern.mankiewicz@06fb5bc9b732f143dee3606866362f562531310d"
+ nickname="joern.mankiewicz"
+ avatar="http://cdn.libravatar.org/avatar/446365f4d50dddc42965fa0432e70cdb"
+ subject="Beware global configurations!"
+ date="2017-03-20T22:47:50Z"
+ content="""
+Thanks, joey.
+
+Your last comment brought me onto the right track. The Problem was not in the repository, but an old stale global .gitconfig in my homedir. I just checked $XDG_CONFIG_HOME/git/config were currently my global git-config is residing and totaly forgot about this old config. Stupid me!
+
+    git config --show-origin --get annex.largefiles
+
+was my savior here as it clearly indicated that there is indeed a (unintended) config setting and where to find the file. So i can strongly recommend anybody experiencing strange behavior to try this one-liner. It might have saved me hours of time.
+
+Thanks for your help! :)
+
+Cheers
+
+Jörn
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files.mdwn b/doc/tips/local_caching_of_annexed_files.mdwn
new file mode 100644
index 0000000000..460100c0d6
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files.mdwn
@@ -0,0 +1,105 @@
+Here's how to set up a local cache of annexed files, that can be used
+to avoid repeated downloads.
+
+An example use case: Your CI system is operating on a git-annex repository,
+so every time it runs it makes a fresh clone of the repository and uses
+`git-annex get` to download a lot of data into it.
+
+We'll create a cache repository, set it as a remote of the other git-annex
+repositories, and configure git-annex to check the cache first before other
+more expensive ways of retrieving content. The cache can be cleaned out
+whenever you like with simple unix commands. 
+
+Some other nice properties -- When used on a system like BTRFS with COW
+support, content from the cache can populate multiple other repositories
+without using any additional disk space. And, git-annex repositories that
+are otherwise unrelated can share use of the cache if they happen to
+contain a common file.
+
+You'll need git-annex 6.20180802 or newer to follow these instructions.
+
+## creating the cache
+
+First let's create a new, empty git-annex repository. It will be put in
+~/.annex-cache in the example, but for best results, put it in the same
+filesystem as your other git-annex repositories.
+
+	git init --bare ~/.annex-cache
+	cd ~/.annex-cache
+	git annex init
+	git config annex.hardlink true
+	git annex untrust here
+
+The cache does not need to be a git annex repository; any kind of special
+remote can be used as a cache too. But, using a git repository lets
+annex.hardlink be used to make hard links between the cache and
+repositories using it.
+
+The cache is made untrusted, because its contents can be cleaned at any
+time; other repositories should not trust it to retain content.
+
+## making repositories use the cache
+
+Now in each git-annex repository that you want to use the cache, add it as
+a remote, and configure it as follows:
+
+	cd my-repository
+	git remote add cache ~/.annex-cache
+	git config remote.cache.annex-speculate-present true
+	git config remote.cache.annex-cost 10
+	git config remote.cache.annex-pull false
+	git config remote.cache.annex-push false
+	git config remote.cache.fetch do-not-fetch-from-this-remote:
+
+The annex-speculate-present setting is the essential part. It makes
+git-annex know that the cache repository may contain the content of any
+annexed file. So, when getting a file, git-annex will try the cache
+repository first.
+
+The low annex-cost makes git-annex try to get content from the cache remote
+before any other remotes.
+
+The annex-pull and annex-push settings prevent `git-annex sync` from
+pulling and pushing to the remote, and the remote.cache.fetch setting
+further prevents git commands from fetching from it or pushing to it. The
+cache repository will remain an empty git repository (except for the
+content of annexed files). This means that the same cache can be used with
+multiple different git-annex repositories, without intermingling their git
+data.
+
+## populating the cache
+
+For the cache to be used, you need to get file contents into it somehow.
+A simple way to do that is, in a git-annex repository that already
+contains the content of files:
+
+	git annex copy --to cache
+
+You could run that anytime after you get content. There are also ways to
+automate it, but getting some files into the cache manually is a good
+enough start.
+
+## cleaning the cache
+
+You safely can remove content from the cache at any time to free up disk
+space.
+
+To remove everything:
+
+	cd ~/.annex-cache
+	git annex drop --force
+
+To remove files that have not been requested from the cache for the past day:
+
+	cd ~/.annex-cache
+	git annex drop --force --not --accessedwithin=1d
+
+## automatically populating the cache
+
+The assistant can be used to automatically populate the cache with files
+that git-annex downloads into a repository.
+
+## more caches
+
+The example above used a local cache on the same system. However, it's also
+possible to have a cache repository shared amoung computers on a LAN.
diff --git a/doc/tips/local_caching_of_annexed_files/comment_10_c93895a509ab4e458043450bccf930dc._comment b/doc/tips/local_caching_of_annexed_files/comment_10_c93895a509ab4e458043450bccf930dc._comment
new file mode 100644
index 0000000000..68143ccc42
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_10_c93895a509ab4e458043450bccf930dc._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2018-08-03T17:18:04Z"
+ content="""
+I fear that preventing merging of branches fetched from the cache remote
+in git-annex would be a game of whack-a-mole. There are just too many
+ways the user could bypass such protections. Including, for example,
+configuring git to fetch from cache to origin/ tracking branches.
+
+I remember at some point discussing isolating repos from one-another so
+that data from one repo can't leak across a boundary to another repo, while
+still having it be a remote, and it was similarly just not tractable. Can't
+seem to find the thread, but it's basically the same problem.
+
+If you do accidentially merge the git-annex branch from a cache remote,
+you can always make it dead and use git-annex forget --drop-dead.
+
+If you really want to avoid any possibility of git fetching from the caching
+remote, make it a directory special remote! But, there is not currently
+any way to make annex.hardlink work for directory special remotes, so it
+will be less efficient.
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_11_5bf79eae24dd6b69daa1cd10e0b4d296._comment b/doc/tips/local_caching_of_annexed_files/comment_11_5bf79eae24dd6b69daa1cd10e0b4d296._comment
new file mode 100644
index 0000000000..f5ea28992e
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_11_5bf79eae24dd6b69daa1cd10e0b4d296._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="could we just make it &quot;avoidable&quot;?"
+ date="2018-08-03T17:54:01Z"
+ content="""
+> There are just too many ways the user could bypass such protections. Including, for example, configuring git to fetch from cache to origin/ tracking branches.
+
+My concern is not really about making it impossible, but about making it unlikely or avoidable.   It is as similar as you cannot avoid completely someone merging `git-annex` branch \"manually\" using regular git-merge with some -Sours to \"avoid\" the conflicts. It is unavoidable but very unlikely ;)   ATM my problem is \"likely\" (as likely as me, the first user of the feature, ran into this problem right away) and \"unavoidable\" (`annex merge` has no option/mode to avoid merging those).  As long as we could avoid it somehow (e.g. by providing some option to `annex merge`) in those situations, it would be great.  My concern is that we cannot avoid it at all.
+
+> make it dead and use `git-annex forget --drop-dead`
+
+yeap, we will add that information to some FAQ etc, very useful.  But it might be a bit too late if we share that blown up git-annex branch publicly and people merge it into their git-annex'es.  If someone is as advanced as configuring git with alternative fetch settings, they could indeed resort to this.
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_12_cbc8fbd8a98574683008ca363d3ac6b7._comment b/doc/tips/local_caching_of_annexed_files/comment_12_cbc8fbd8a98574683008ca363d3ac6b7._comment
new file mode 100644
index 0000000000..c259bafe93
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_12_cbc8fbd8a98574683008ca363d3ac6b7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2018-08-03T18:09:26Z"
+ content="""
+Found a remote.cache.fetch that will prevent most accidents, though of
+course the determined footgun script may find a way.
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_13_18514bbfab0ff0d8a70ce5b08436cd44._comment b/doc/tips/local_caching_of_annexed_files/comment_13_18514bbfab0ff0d8a70ce5b08436cd44._comment
new file mode 100644
index 0000000000..f4608f625b
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_13_18514bbfab0ff0d8a70ce5b08436cd44._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 13"
+ date="2018-10-26T11:35:19Z"
+ content="""
+This would be super useful for my sorting annex! Being able to just drop the symlinks into other git-annex repositories and fetch the file from any of the \"storage\" ones (acting as caches) resolves [[todo/transfer_between_git-annexes]] in a very neat and safe way!
+
+I see that git-annex won't merge the cache's git-annex branch with this setup (which is great, because some of them are *huge*) but when a repo fetches a file from the cache, it will note that the cache repo had the file in the location log, right?
+Can this be avoided so the cache is entirely transient (once you remove the remote, there is no trace of it at all)?
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_14_7afa02db922ef1ad9d4031a87e4b688c._comment b/doc/tips/local_caching_of_annexed_files/comment_14_7afa02db922ef1ad9d4031a87e4b688c._comment
new file mode 100644
index 0000000000..ea80c00a17
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_14_7afa02db922ef1ad9d4031a87e4b688c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 14"
+ date="2018-10-27T22:33:20Z"
+ content="""
+I just tried this and git-annex doesn't add the cache in the location tracking for the files. Perfect! Yay! :D
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_15_a1ce74ef47a0512bc56ff323c2c03c75._comment b/doc/tips/local_caching_of_annexed_files/comment_15_a1ce74ef47a0512bc56ff323c2c03c75._comment
new file mode 100644
index 0000000000..b69daf7d89
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_15_a1ce74ef47a0512bc56ff323c2c03c75._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Mowgli"
+ avatar="http://cdn.libravatar.org/avatar/17ab194dddf7b7da59ec039cbb3ac252"
+ subject="reflink and subvolume"
+ date="2018-11-21T19:01:11Z"
+ content="""
+It doesn't work well if the source of the copy is in a btrfs subvolume and the cache is in another subvolume of the same filesystem.
+
+With that setup every file is really copied instead of using reflink=always.
+
+I solved it currently by copying .git/annex/objects manual into the cache (`cp -a --reflink=always .git/annex/objects ~/.cache/annex/` and afterwards doing the git annex cp which recognice the existence of the objects.
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_16_3f4950f7dc51472b5f0405baeac187a0._comment b/doc/tips/local_caching_of_annexed_files/comment_16_3f4950f7dc51472b5f0405baeac187a0._comment
new file mode 100644
index 0000000000..70f487dec5
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_16_3f4950f7dc51472b5f0405baeac187a0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 16"
+ date="2018-11-21T19:21:48Z"
+ content="""
+Hi Mowgli,  could you please elaborate for a slow me -- are you saying that `--reflink=auto` is not causing CoW between different subvolumes of the same filesystem while `--reflink=always` does?
+
+P.S. glad to see more of BTRFS & git-annex tandem users around ;-)
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_17_d1f0d7ac76f704ea71c4971ee7ed0cde._comment b/doc/tips/local_caching_of_annexed_files/comment_17_d1f0d7ac76f704ea71c4971ee7ed0cde._comment
new file mode 100644
index 0000000000..99eb3adc93
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_17_d1f0d7ac76f704ea71c4971ee7ed0cde._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Mowgli"
+ avatar="http://cdn.libravatar.org/avatar/17ab194dddf7b7da59ec039cbb3ac252"
+ subject="reflink and subvolume"
+ date="2018-11-21T19:41:30Z"
+ content="""
+Well, I did not check reflink=auto. I just checked first with `git annex copy --to=cache` which simply duplicated every file. So there are two posibilities:
+
+1. reflink=auto doesn't work (I did not check but I think it work)
+2. git-annex does not recognise the other path to be on the same filesystem so went back to simply copy (very likely but joey has to check.)
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_18_6b21f1ed5a2cbbba7c7042dcfec080a8._comment b/doc/tips/local_caching_of_annexed_files/comment_18_6b21f1ed5a2cbbba7c7042dcfec080a8._comment
new file mode 100644
index 0000000000..7377139391
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_18_6b21f1ed5a2cbbba7c7042dcfec080a8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 18"
+ date="2018-11-21T19:56:45Z"
+ content="""
+I think that annex always uses `cp --reflink=auto` for local paths (cache remote was on a local path right?).  I guess running with `--debug` could have helped to resolve the mystery ;-)
+
+BTW -- checked locally - `reflink=auto` seems to work nicely across subvolumes of the same BTRFS filesystem. \"copying\" gigabytes takes half a second or so ;-) (without reflink=auto - takes considerably longer)
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_19_490c15d7673c535e83c7f1df3082e7ed._comment b/doc/tips/local_caching_of_annexed_files/comment_19_490c15d7673c535e83c7f1df3082e7ed._comment
new file mode 100644
index 0000000000..d97f120924
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_19_490c15d7673c535e83c7f1df3082e7ed._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2018-12-03T17:34:10Z"
+ content="""
+git-annex looks at the file's stat() and only if the device id is the same
+as the stat of the destination directory does it use `cp`. If you see it
+running `rsync` instead, it's under the perhaps mistaken impression that
+it's a cross-device copy.
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_1_ad1ab9d78cc0c45fcda54bf9f03b4f8f._comment b/doc/tips/local_caching_of_annexed_files/comment_1_ad1ab9d78cc0c45fcda54bf9f03b4f8f._comment
new file mode 100644
index 0000000000..cde6979a47
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_1_ad1ab9d78cc0c45fcda54bf9f03b4f8f._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="is not going from cache with parallel get e.g. -J 2 "
+ date="2018-08-02T13:33:08Z"
+ content="""
+Sweet! Thank you Joey
+
+The main issue so far detected is that if it is a parallel download (we have it as a default in datalad), it doesn't consider cache:
+
+[[!format sh \"\"\"
+$> git annex get -J1 sub-01/anat/sub-*_T1w.nii.gz      
+get sub-01/anat/sub-01_T1w.nii.gz (from cache...) ok
+(recording state in git...)
+
+$> datalad drop sub-01/anat/sub-*_T1w.nii.gz
+drop(ok): /home/yoh/datalad/openfmri/ds000001/sub-01/anat/sub-01_T1w.nii.gz (file)
+
+$> git annex get -J2 sub-01/anat/sub-*_T1w.nii.gz
+get sub-01/anat/sub-01_T1w.nii.gz (from web...) 
+22%   1.2 MiB         880 KiB/s 4s
+16%   891.34 KiB      895 KiB/s 5s
+
+\"\"\"]]
+
+I am still digesting either having cache operations/state reflected in git-annex branch is a ok or not so ok (whenever # of files is large etc) thing
+
+[[!meta author=yoh]]
+
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_20_af084d315d82c1bae85122939042305b._comment b/doc/tips/local_caching_of_annexed_files/comment_20_af084d315d82c1bae85122939042305b._comment
new file mode 100644
index 0000000000..cb209083da
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_20_af084d315d82c1bae85122939042305b._comment
@@ -0,0 +1,76 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="more details on coreutils cp treatment of reflink"
+ date="2019-03-06T16:00:35Z"
+ content="""
+> git-annex looks at the file's stat() and only if the device id is the same
+
+<details>
+<summary>They are indeed not the same across subvolumes of the same BTRFS file system</summary>
+
+```
+$> time cp --reflink=auto home/yoh/reprotraining.ova scrap/tmp
+cp --reflink=auto home/yoh/reprotraining.ova scrap/tmp  0.00s user 0.00s system 92% cpu 0.004 total
+
+$> stat home/yoh/reprotraining.ova scrap/tmp/reprotraining.ova
+  File: home/yoh/reprotraining.ova
+  Size: 5081213952	Blocks: 9924248    IO Block: 4096   regular file
+Device: 2fh/47d	Inode: 61771704    Links: 1
+Access: (0600/-rw-------)  Uid: (47521/     yoh)   Gid: (47522/     yoh)
+Access: 2018-06-14 19:23:25.000000000 -0400
+Modify: 2018-06-11 15:35:57.000000000 -0400
+Change: 2018-06-14 19:23:25.891351983 -0400
+ Birth: -
+  File: scrap/tmp/reprotraining.ova
+  Size: 5081213952	Blocks: 9924248    IO Block: 4096   regular file
+Device: 30h/48d	Inode: 190040764   Links: 1
+Access: (0600/-rw-------)  Uid: (47521/     yoh)   Gid: (47522/     yoh)
+Access: 2019-03-06 10:38:02.610657786 -0500
+Modify: 2019-03-06 10:38:02.610657786 -0500
+Change: 2019-03-06 10:38:02.610657786 -0500
+ Birth: -
+```
+</details>
+
+`cp` seems to just to attempt a cheap clone
+
+```
+/* Perform the O(1) btrfs clone operation, if possible.
+   Upon success, return 0.  Otherwise, return -1 and set errno.  */
+static inline int
+clone_file (int dest_fd, int src_fd)
+{
+#ifdef FICLONE
+  return ioctl (dest_fd, FICLONE, src_fd);
+#else
+  (void) dest_fd;
+  (void) src_fd;
+  errno = ENOTSUP;
+  return -1;
+#endif
+```
+
+and if that one fails, assumes that full copy is required:
+
+```c
+  /* --attributes-only overrides --reflink.  */
+  if (data_copy_required && x->reflink_mode)
+    {
+      bool clone_ok = clone_file (dest_desc, source_desc) == 0;
+      if (clone_ok || x->reflink_mode == REFLINK_ALWAYS)
+        {
+          if (!clone_ok)
+            {
+              error (0, errno, _(\"failed to clone %s from %s\"),
+                     quoteaf_n (0, dst_name), quoteaf_n (1, src_name));
+              return_val = false;
+              goto close_src_and_dst_desc;
+            }
+          data_copy_required = false;
+        }
+    }
+```
+
+BTW, why `rsync` instead of a regular `cp` for local filesystem if it is across the devices?
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_21_3776a0371faccc673c868323278f3b0d._comment b/doc/tips/local_caching_of_annexed_files/comment_21_3776a0371faccc673c868323278f3b0d._comment
new file mode 100644
index 0000000000..d9f2ca4c3a
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_21_3776a0371faccc673c868323278f3b0d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="FTR: a dedicated issue on CoW across subvolumes"
+ date="2019-07-08T19:05:45Z"
+ content="""
+[bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/](https://git-annex.branchable.com/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/)
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_22_b047ea1c6b9247a42b560a111d4fdeae._comment b/doc/tips/local_caching_of_annexed_files/comment_22_b047ea1c6b9247a42b560a111d4fdeae._comment
new file mode 100644
index 0000000000..7c24be4fe8
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_22_b047ea1c6b9247a42b560a111d4fdeae._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="preferred way to automate population of the cache upon `get`"
+ date="2020-01-13T19:01:07Z"
+ content="""
+```
+# Populating the cache
+For the cache to be used, you need to get file contents into it somehow. A simple way to do that is, in a git-annex repository that already contains the content of files:
+
+    git annex copy --to cache
+
+You could run that anytime after you get content. There are also ways to automate it, but getting some files into the cache manually is a good enough start.
+```
+
+Hi Joey.  What would be the preferred way you would advise to use (ideally with minimal manual configuration) to make it happen? I.e. whenever user(s) `get` some load, it gets automagically `annex copied` to the cache?
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_23_994f408b01fa09e80599538a4ff28485._comment b/doc/tips/local_caching_of_annexed_files/comment_23_994f408b01fa09e80599538a4ff28485._comment
new file mode 100644
index 0000000000..0e9fba1835
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_23_994f408b01fa09e80599538a4ff28485._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="kousu"
+ avatar="http://cdn.libravatar.org/avatar/ad9a5f59c296f9cb4e8f8a85510b049c"
+ subject="Hardlinks"
+ date="2021-04-16T08:17:35Z"
+ content="""
+I tried following the recipe above using git-annex v8 and successfully made a cache to which I can *write* efficient hardlinks to my working repos, but I am unable to *read* them back the same way, as hardlinks.
+
+This means that on a 10GB dataset, where `annex.thin` lets me use only those 10GB, adding the cache doubles it to 20GB. This is not really a feasible amount of overhead for my use-case.
+
+I've done a full report with test cases comparing different solutions (check the branches!) at https://github.com/kousu/test-git-annex-hardlinks.
+
+There seem to be several tangled issues: `annex.hardlink` in the cache overrides `annex.thin` in the working repo (despite the manpage claming `annex.thin` overrides `annex.hardlink`), `annex get` and `annex copy` both want to do the equivalent of a one-step `fetch` and `checkout` and the `checkout` does a copy despite `annex.thin` being set.
+
+Either:
+
+* I get hardlinks from `~/.annex-cache/.git/annex/objects <-> dataset/.git/annex/objects` but a copy between `dataset/.git/annex/objects <-> dataset/`, or
+* If I disable `annex.hardlink` **[in the cache](https://github.com/kousu/test-git-annex-hardlinks/blob/4b74841c8b9297879968f4fee69c31a6b82e9354/annex-hardlinks.sh#L165)**, then vice-versa: a copy happens between `~/.annex-cache/.git/annex/objects <-> dataset/.git/annex/objects` and a hardlink happens between `dataset/.git/annex/objects <-> dataset/`.
+
+In either case there's an extra full copy of my dataset, and I would rather not spend the time and space it takes to construct that every time I want to use my dataset somewhere.
+
+I also tried `mv ~/.annex-cache/.git/annex dataset/.git/` but that just confused `git-annex` fiercely.
+
+I also tried `git annex fix` but it just seemed to do nothing. And anyway isn't much help since I need to run it after `copy` which has already done a wasteful copy. I thought maybe `fix` could at least recognize that `annex.thin` is set and undo the wasted copy but it doesn't.
+
+I managed to work around it by side-stepping `git-annex` with `find .git/annex/objects | ... | ln -f` [directly](https://github.com/kousu/test-git-annex-hardlinks/blob/1edcdd2b13d4a8abd7d32c1727da1f820b23409c/annex-hardlinks.sh#L189-L195). This seems to work, and to not confuse `git-annex` [too much](https://github.com/kousu/test-git-annex-hardlinks#-bare-) -- it just makes an extra hardlink for some reason, but I can live with that.
+
+What's the most supported way to cache and directly use the data in the cache? That's one of the main features I want in a cache and I can't figure out how to do it with `git-annex`.
+
+Thanks for any pointers or clues towards getting this to work.
+
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_2_d3ac760cfee0decfbcb4f81ddbc39a3f._comment b/doc/tips/local_caching_of_annexed_files/comment_2_d3ac760cfee0decfbcb4f81ddbc39a3f._comment
new file mode 100644
index 0000000000..3c94fda3dd
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_2_d3ac760cfee0decfbcb4f81ddbc39a3f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="is it &quot;safe&quot; to tune?"
+ date="2018-08-02T13:53:04Z"
+ content="""
+Hi Joey,
+
+Would it be safe to init that repo with those `tunables` such as ` -c annex.tune.objecthash1=true -c annex.tune.branchhash1=true` to save some inodes etc?   Any other tunable which might be of benefit (I still hope that I will see the time whenever the \"KEY/\" directory would be gone ;-))?
+I've tried with those two above (although annex.tune.branchhash1=true is probably irrelevant here) and it seems to do the right thing (at least for the objecthash1), but I just wanted to make sure I am not shooting myself into the foot.
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_3_2a80533f259cde64662db7e6a1c1742c._comment b/doc/tips/local_caching_of_annexed_files/comment_3_2a80533f259cde64662db7e6a1c1742c._comment
new file mode 100644
index 0000000000..0a2240882d
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_3_2a80533f259cde64662db7e6a1c1742c._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="could be taken as a feature! but also annex should avoid merging cache git-annex"
+ date="2018-08-02T14:30:51Z"
+ content="""
+I have two cache repos -- `cache` is just a regular one and `cache2` with those tuned up parameters:
+
+[[!format sh \"\"\"
+$> git annex merge       
+merge git-annex (merging cache/git-annex cache2/git-annex into git-annex...)
+git-annex: Remote repository is tuned in incompatible way; cannot be merged with local repository.
+
+\"\"\"]]
+
+and it didn't merge any of those which is good -- we do not want a possibly monstrous history of the cache to be merged into every repo using it
+
+But then when I remove that `cache2` git-annex does merge it:
+
+[[!format sh \"\"\"
+$> git remote rm cache2
+$> git annex merge     
+merge git-annex (merging cache/git-annex into git-annex...)
+(recording state in git...)
+ok
+\"\"\"]]
+which imho shouldn't happen -- annex shouldn't merge \"cache\" histories into this repository git-annex history.  I guess there should be one more config option to set for those remotes?
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_4_42906e52528907a0960ab8b08c2eedd4._comment b/doc/tips/local_caching_of_annexed_files/comment_4_42906e52528907a0960ab8b08c2eedd4._comment
new file mode 100644
index 0000000000..f19586dfcb
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_4_42906e52528907a0960ab8b08c2eedd4._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-08-02T16:58:45Z"
+ content="""
+Parallel downloads will use the cache repository for everything if it has a
+lower cost than other repositories. That's why the cost is set to 10 in the
+example. If it has the same cost as another repository, parallel downloads
+will spread the load between them. (This also means you can have multiple
+caches with the same cost and distribute load amoung them..)
+
+You should never be pulling from the cache repo, so there should be nothing
+to merge from it. That's what the remote.cache.annex-pull is there to prevent
+git-annex sync doing, but you also have to avoid pulling from it yourself.
+
+Using tunables with the cache does seem to work. Since all remotes usually
+have the same tunables as the local repo, there could potentially be
+bugs (or optimisations?) where it applies the local tunables to the
+remote, but in a little testing it seemed to work.
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_5_dc1e5e3d256a2618f6c2a7864b01c08e._comment b/doc/tips/local_caching_of_annexed_files/comment_5_dc1e5e3d256a2618f6c2a7864b01c08e._comment
new file mode 100644
index 0000000000..a49d91cc8c
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_5_dc1e5e3d256a2618f6c2a7864b01c08e._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="re: parallel and costs"
+ date="2018-08-02T17:28:46Z"
+ content="""
+Sorry - I am still missing.  
+I followed your example so the cost for cache is 10, whenever for web it is default 200:
+[[!format sh \"\"\"
+$> git annex info cache web | grep -e remote: -e cost
+remote: cache
+cost: 10.0
+remote: web
+cost: 200.0
+\"\"\"]]
+but it does download from the web in parallel download case -- so what am I missing?
+[[!format sh \"\"\"
+~/datalad/openfmri/ds000001 > datalad get -J 1 sub-01/anat/sub-*_T1w.nii.gz 
+get(ok): /home/yoh/datalad/openfmri/ds000001/sub-01/anat/sub-01_T1w.nii.gz (file) [from cache...]               
+
+~/datalad/openfmri/ds000001 > git annex drop sub-01/anat/sub-*_T1w.nii.gz
+drop sub-01/anat/sub-01_T1w.nii.gz (checking http://openneuro.s3.amazonaws.com/ds000001/ds000001_R1.1.0/uncompressed/sub001/anatomy/highres001.nii.gz?versionId=8TJ17W9WInNkQPdiQ9vS7wo8ZJ9llF80...) ok
+(recording state in git...)
+
+~/datalad/openfmri/ds000001 > datalad get -J 2 sub-01/anat/sub-*_T1w.nii.gz  
+get(ok): /home/yoh/datalad/openfmri/ds000001/sub-01/anat/sub-01_T1w.nii.gz (file) [from web...] 
+\"\"\"]]
+nothing in --debug output hints on the costs:
+[[!format sh \"\"\"
+~/datalad/openfmri/ds000001 > git annex get -J 2 --debug sub-01/anat/sub-*_T1w.nii.gz
+[2018-08-02 13:28:03.896215705] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"sub-01/anat/sub-01_T1w.nii.gz\"]
+[2018-08-02 13:28:03.900141316] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
+[2018-08-02 13:28:03.904139213] process done ExitSuccess
+[2018-08-02 13:28:03.904230988] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2018-08-02 13:28:03.908376239] process done ExitSuccess
+[2018-08-02 13:28:03.908608977] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..ff8578c5e3bdd1c67b2d9ca8082893fe6425f729\",\"--pretty=%H\",\"-n1\"]
+[2018-08-02 13:28:03.913502761] process done ExitSuccess
+[2018-08-02 13:28:03.914221081] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-08-02 13:28:03.914683852] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
+[2018-08-02 13:28:03.920509994] read: git [\"config\",\"--null\",\"--list\"]
+[2018-08-02 13:28:03.925910945] process done ExitSuccess
+get sub-01/anat/sub-01_T1w.nii.gz 
+[2018-08-02 13:28:03.926689119] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
+[2018-08-02 13:28:03.9274736] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objectty(from web...) ze)\"]
+76%   4.12 MiB        859 KiB/s 1s
+73%   3.96 MiB        842 KiB/s 1s
+...
+\"\"\"]]
+
+
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_6_c0d79b07a4c83c9d081d7c8f702fa4dc._comment b/doc/tips/local_caching_of_annexed_files/comment_6_c0d79b07a4c83c9d081d7c8f702fa4dc._comment
new file mode 100644
index 0000000000..7b79e27d83
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_6_c0d79b07a4c83c9d081d7c8f702fa4dc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="re: annex merge cache"
+ date="2018-08-02T17:35:22Z"
+ content="""
+>  but you also have to avoid pulling from it yourself.
+
+I think we do call out to `annex merge` from time to time to update information about annex objects availability from any remote it might want to do so.  Since `sync` does more we avoid using it for those cases.  `git annex merge` doesn't even care about any argument given to it, so we cannot simply avoid calling it on `cache` remotes by specifying all other remotes.  Would it be possible to get some option `--only-pullable` or alike to make it prevent merging \"caches\"?
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_7_ffdf07bac38a6c29b799281441fd32c9._comment b/doc/tips/local_caching_of_annexed_files/comment_7_ffdf07bac38a6c29b799281441fd32c9._comment
new file mode 100644
index 0000000000..8e4dbbf76e
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_7_ffdf07bac38a6c29b799281441fd32c9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2018-08-02T18:15:13Z"
+ content="""
+Well, git-annex merge does not fetch, it only merges refs it sees. With
+the configuration I gave in the tip, you will not have a cache/git-annex branch for it
+to merge.
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_8_0e4571cc81ade6510b7a1ddfff9cb055._comment b/doc/tips/local_caching_of_annexed_files/comment_8_0e4571cc81ade6510b7a1ddfff9cb055._comment
new file mode 100644
index 0000000000..cc846529c6
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_8_0e4571cc81ade6510b7a1ddfff9cb055._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="re: annex merge cache"
+ date="2018-08-02T18:49:51Z"
+ content="""
+> Well, git-annex merge does not fetch, it only merges refs it sees.
+
+That is correct!  My alias to fetch all remotes (useful to quickly update on the current state of development in feature branches of others) fetched the cache as well.  Despite viral nature of git tags I consider it to be a good general approach.  But fetching is not merging -- I can remove any of those remotes at any moment happen some remote became too heavy or smth like that (tags are trickier).
+
+IMHO `annex merge` should also not merge those remotes which are not \"pullable\" by default.  May be it could take remote name(s) as its argument(s) to merge only specified ones (ATM arguments seems to be silently ignored), happen someone really need to merge somehow any of those.  That would prevent accidental blow up of the git-annex branch in case cache remote gets fetched.
+"""]]
diff --git a/doc/tips/local_caching_of_annexed_files/comment_9_7db7787a306c70ba3c1687c1d103608d._comment b/doc/tips/local_caching_of_annexed_files/comment_9_7db7787a306c70ba3c1687c1d103608d._comment
new file mode 100644
index 0000000000..d539ec97a3
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_9_7db7787a306c70ba3c1687c1d103608d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2018-08-03T16:30:35Z"
+ content="""
+The -J2 web bug was not related to caching remotes at all
+but was an accidental sort by remote uuid rather than cost.
+I've fixed it.
+"""]]
diff --git a/doc/tips/making_a_remote_repo_update_when_changes_are_pushed_to_it.mdwn b/doc/tips/making_a_remote_repo_update_when_changes_are_pushed_to_it.mdwn
new file mode 100644
index 0000000000..821c679d13
--- /dev/null
+++ b/doc/tips/making_a_remote_repo_update_when_changes_are_pushed_to_it.mdwn
@@ -0,0 +1,25 @@
+Normally, pushing a change into a remote git repository does not update its
+working tree. But it can be very convenient to only need to `git push`
+(or `git annex sync --content`) to a remote to update the files checked out
+there.
+
+Git has a way to let you do this, by setting `receive.denyCurrentBranch`
+to `updateInstead` in the remote repository. For example:
+
+	ssh remote
+	cd /path/to/repo
+	git config receive.denyCurrentBranch updateInstead
+
+Now after a push to the remote, its working tree will be updated.
+
+Changes in the remote's working tree can prevent this update from working;
+normally you'll want to avoid manually changing the remote's working tree,
+and only push changes into it in this configuration.
+
+When the remote is using [[direct_mode]] or
+[[adjusted_branches|git-annex-adjust]], you need the 
+[[git-annex post-receive|git-annex-post-receive]]
+hook to be set up for pushes to update the remote's working tree.
+This is a new feature in git-annex 6.20170217. If the remote was
+initialized with an older version of git-annex, you will need to re-run
+`git annex init` in the remote after upgrading git-annex.
diff --git a/doc/tips/mc_menu_integration.mdwn b/doc/tips/mc_menu_integration.mdwn
new file mode 100644
index 0000000000..1701188302
--- /dev/null
+++ b/doc/tips/mc_menu_integration.mdwn
@@ -0,0 +1,18 @@
+Put the following in your ~/.config/mc/menu to map g and G to
+git-annex-get and git-annex-drop in the famous mc file manager:
+
+    + ! t t
+    g git annex get
+      git annex get %f
+
+    + t t
+    g git annex get
+      git annex get %u
+
+    + ! t t
+    G git annex drop
+      git annex drop %f
+
+    + t t
+    G git annex drop
+      git annex drop %u
diff --git a/doc/tips/megaannex.mdwn b/doc/tips/megaannex.mdwn
new file mode 100644
index 0000000000..b0899c04f8
--- /dev/null
+++ b/doc/tips/megaannex.mdwn
@@ -0,0 +1,14 @@
+For using [Mega](https://mega.nz)
+as a special remote, there are currently three choices:
+
+* There is a dedicated special remote,
+  <https://github.com/dxtr/megaannex-go>  
+  Last updated 2016
+* Alternatively, rclone supports Mega,
+  so the [[rclone_special_remote|special_remotes/rclone]] can be used.
+* Alternatively, there's an older dedicated special remote,
+  <https://github.com/TobiasTheViking/megaannex>  
+  Reported to be no longer working
+
+At this time it's not clear which is better, so if you find one works
+best, please comment below.
diff --git a/doc/tips/megaannex/comment_1_eec701662debd2a78c48243dbcebf59a._comment b/doc/tips/megaannex/comment_1_eec701662debd2a78c48243dbcebf59a._comment
new file mode 100644
index 0000000000..8b4b7f82be
--- /dev/null
+++ b/doc/tips/megaannex/comment_1_eec701662debd2a78c48243dbcebf59a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-21T19:56:13Z"
+ content="""
+Note that there has apparently been an API break, so this special remote may not work anymore. See: <http://git-annex.branchable.com/forum/MegaAnnex_not_working./>
+"""]]
diff --git a/doc/tips/megaannex/comment_2_c1158b7ec15646d64cae8215ce845642._comment b/doc/tips/megaannex/comment_2_c1158b7ec15646d64cae8215ce845642._comment
new file mode 100644
index 0000000000..99da0e370d
--- /dev/null
+++ b/doc/tips/megaannex/comment_2_c1158b7ec15646d64cae8215ce845642._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw"
+ nickname="dxtrish"
+ subject="comment 2"
+ date="2014-09-07T21:16:09Z"
+ content="""
+Because megaannex apparently isn't working nowadays I have created a compatible program in Go. I think it should handle everything except REMOVE right now.
+
+You can find it on github: https://github.com/dxtr/megaannex-go
+"""]]
diff --git a/doc/tips/metadata_driven_views.mdwn b/doc/tips/metadata_driven_views.mdwn
new file mode 100644
index 0000000000..1826ed1cef
--- /dev/null
+++ b/doc/tips/metadata_driven_views.mdwn
@@ -0,0 +1,152 @@
+git-annex now has support for storing 
+[[arbitrary metadata|metadata]] about annexed files. For example, this can be
+used to tag files, to record the author of a file, etc. The metadata is
+synced around between repositories with the other information git-annex
+keeps track of.
+
+One nice way to use the metadata is through **views**. You can ask
+git-annex to create a view of files in the currently checked out branch
+that have certain metadata. Once you're in a view, you can move and copy
+files to adjust their metadata further. Rather than the traditional
+hierarchical directory structure, views are dynamic; you can easily
+refine or reorder a view.
+
+Let's get started by setting some tags on files. No views yet, just some
+metadata:
+
+[[!template id=note text="""
+To avoid needing to manually tag files with the year (and month),
+run `annex.genmetadata true`, and git-annex will do it for you
+when adding files.
+"""]]
+
+	# git annex metadata --tag todo work/2014/*
+	# git annex metadata --untag todo work/2014/done/*
+	# git annex metadata --tag urgent work/2014/presentation_for_tomorrow.odt
+	# git annex metadata --tag done work/2013/* work/2014/done/*
+	# git annex metadata --tag work work
+	# git annex metadata --tag video videos
+	# git annex metadata --tag work videos/operating_heavy_machinery.mov
+	# git annex metadata --tag done videos/old
+	# git annex metadata --tag new videos/lotsofcats.ogv
+	# git annex metadata --tag sound podcasts
+	# git annex metadata --tag done podcasts/*/old
+	# git annex metadata --tag new podcasts/*/recent
+
+So, you had a bunch of different kinds of files sorted into a directory
+structure. But that didn't really reflect how you approach the files.
+Adding some tags lets you categorize the files in different ways.
+
+Ok, metadata is in place, but how to use it? Time to change views!
+
+	# git annex view tag=*
+	view  (searching...)
+
+	Switched to branch 'views/_'
+	ok
+
+[[!template id=note text="""
+Notice that a single file may appear in multiple directories
+depending on its tags. For example, `lotsofcats.ogv` is in
+both `new/` and `video/`.
+"""]]
+
+This searched for all files with any tag, and created a new git branch
+that sorts the files according to their tags.
+
+	# tree -d
+	work
+	todo
+	urgent
+	done
+	new
+	video
+	sound
+
+Ah, but you're at work now, and don't want to be distracted by cat videos.
+Time to filter the view:
+
+	# git annex vfilter tag=work
+	vfilter
+	Switched to branch 'views/(work)/_'
+	ok
+
+Now only the work files are in the view, and they're otherwise categorized
+according to their other tags. So you can check the `urgent/` directory
+to see what's next, and look in `todo/` for other work related files.
+
+Now that you're in a tag based view, you can move files around between the
+directories, and when you commit your changes to git, their tags will be
+updated.
+
+	# git mv urgent/presentation_for_tomorrow_{work;2014}.odt ../done
+	# git commit -m "a good day's work"
+	metadata tag-=urgent
+	metadata tag+=done
+
+You can return to a previous view by running `git annex vpop`. If you pop
+all the way out of all views, you'll be back on the regular git branch you
+originally started from. You can also use `git checkout` to switch between
+views and other branches.
+
+## fields
+
+Beyond simple tags and directories, you can add whatever kinds of metadata
+you like, and use that metadata in more elaborate views. For example, let's
+add a year field.
+
+	# git checkout master
+	# git annex metadata --set year=2014 work/2014
+	# git annex metadata --set year=2013 work/2013
+	# git annex view year=* tag=*
+
+Now you're in a view with two levels of directories, first by year and then
+by tag.
+
+	# tree -d
+	2014
+	  |-- work
+	  |-- todo
+	  |-- urgent
+	  `-- done
+	2013
+	  |-- work
+	  `-- done
+
+Oh, did you want it the other way around? Easy!
+
+	# git annex vcycle
+	# tree -d
+	work
+	  |-- 2014
+	  `-- 2013
+	todo
+	  `-- 2014
+	urgent
+	  `-- 2014
+	done
+	  |-- 2014
+	  `-- 2013
+
+## location fields
+
+Let's switch to a view containing only new podcasts. And since the
+podcasts are organized into one subdirectory per show, let's
+include those subdirectories in the view.
+
+	# git checkout master
+	# git annex view tag=new podcasts/=*
+	# tree -d
+	This_Developers_Life
+	Escape_Pod
+	GitMinutes
+	The_Haskell_Cast
+	StarShipSofa
+
+That's an example of using part of the directory layout of the original
+branch to inform the view. Every file gets fields automatically set up
+corresponding to the directory it's in. So a file"foo/bar/baz/file" has
+fields "/=foo", "foo/=bar", and "foo/bar/=baz". These location fields
+can be used the same as other metadata to construct the view.
+
+This has probably only scratched the surface of what you can do with views.
diff --git a/doc/tips/metadata_driven_views/comment_1_1d6793701fd8a1a66bae04662cf853ce._comment b/doc/tips/metadata_driven_views/comment_1_1d6793701fd8a1a66bae04662cf853ce._comment
new file mode 100644
index 0000000000..808a332afc
--- /dev/null
+++ b/doc/tips/metadata_driven_views/comment_1_1d6793701fd8a1a66bae04662cf853ce._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlFZFMFm-AapYAgV_V5X9HRJxWvhdiX9fY"
+ nickname="Reiner"
+ subject="comment 1"
+ date="2014-03-24T21:11:31Z"
+ content="""
+I have played around with views and found out that I can create new tags by creating directories in the view and that I can created files in those new directories that are not contained in the original working tree. The behavoiur of git annex in this behaviour is a bit strange.
+
+Assume for example you have a file \"foo\" with tag \"t1\" and switch to the tag view. Then create a directory \"t2\" and a file \"bar\" in it. Add the file, sync, and switch back to the master branch. If you enter the tag view again, the directory \"t2\" will be vanished, i.e. your newly created file is gone, too. This is not surprising, as the file has never been added to the original working tree. However, another \"git annex sync\" will restore the file.
+
+I am unsure what behaviour I would expect, maybe it shouldn't be possible to files to a view in the first place, or newly created files might be collected in a separate branch. On the other hand, it seems reasonable to add a new file with a new tag at the same time. Anyway, I found it confusing that I can seemingly lose a file like this. It took me a bit of time to figure out that another sync recovers the file.
+"""]]
diff --git a/doc/tips/metadata_driven_views/comment_2_13ae4e3668b693c0eefaca23b88515cf._comment b/doc/tips/metadata_driven_views/comment_2_13ae4e3668b693c0eefaca23b88515cf._comment
new file mode 100644
index 0000000000..3ec5633111
--- /dev/null
+++ b/doc/tips/metadata_driven_views/comment_2_13ae4e3668b693c0eefaca23b88515cf._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="possible to have a view based on file location info?"
+ date="2014-06-08T03:55:24Z"
+ content="""
+For example, I'd like to have a view that only contains files present in this git-annex repository (no dangling symlinks).
+
+"""]]
diff --git a/doc/tips/metadata_driven_views/comment_3_196f55e52a5d8a8f061603ab87ad04ad._comment b/doc/tips/metadata_driven_views/comment_3_196f55e52a5d8a8f061603ab87ad04ad._comment
new file mode 100644
index 0000000000..e522ed8379
--- /dev/null
+++ b/doc/tips/metadata_driven_views/comment_3_196f55e52a5d8a8f061603ab87ad04ad._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnPgn611P6ym5yyL0BS8rUzO0_ZKRldMt0"
+ nickname="Samuel"
+ subject="git annex view */=podcast"
+ date="2014-08-19T06:11:50Z"
+ content="""
+Hi,
+
+Would it be hard to handle the wildcard character in the location view before the = sign.
+
+    git annex foo/=*
+
+works but
+
+    git annex *=/bar
+
+does not.
+"""]]
diff --git a/doc/tips/migrating_data_to_a_new_backend.mdwn b/doc/tips/migrating_data_to_a_new_backend.mdwn
new file mode 100644
index 0000000000..d81a42e0f9
--- /dev/null
+++ b/doc/tips/migrating_data_to_a_new_backend.mdwn
@@ -0,0 +1,31 @@
+Maybe you started out using the SHA1 backend, and have now configured
+git-annex to use SHA256. But files you added to the annex before still
+use the SHA1 backend. There is a simple command that can migrate that
+data:
+
+	# git annex migrate my_cool_big_file
+	migrate my_cool_big_file (checksum...) ok
+
+This stages a change to the file, which you can `git commit` like any other
+change.
+
+You can only migrate files whose content is currently available. Other
+files will be skipped.
+
+## distributed migration
+
+When you pull changes into your repository that include migration of files,
+your repository then needs to be updated to follow the migration.
+
+    # git-annex migrate --update
+	migrate my_cool_big_file (checksum...) ok
+
+This is done automatically by commands like `git-annex pull`.
+
+## unused old content
+
+After migrating a file to a new backend, the old content in the old backend
+will still be present. That is necessary because multiple files
+can point to the same content. The `git annex unused` subcommand can be
+used to clear up that detritus later. Note that hard links are used,
+to avoid wasting disk space.
diff --git a/doc/tips/migrating_two_seperate_disconnected_directories_to_git_annex.mdwn b/doc/tips/migrating_two_seperate_disconnected_directories_to_git_annex.mdwn
new file mode 100644
index 0000000000..8a14b35dc8
--- /dev/null
+++ b/doc/tips/migrating_two_seperate_disconnected_directories_to_git_annex.mdwn
@@ -0,0 +1,77 @@
+Note: this is the reverse of [[splitting_a_repository]].
+
+Scenario
+--------
+
+You are a new git-annex user. You have already files spread around many computers and wish to migrate those into git-annex, without having to recopy all files all over the place.
+
+Let's say, for example, you have a server, named `marcos` and a workstation named `angela`. You have your audio collection stored in `/srv/mp3` in `marcos` and `~/mp3` on `angela`, but only `marcos` has all the files, and `angela` only has a subset.
+
+We also assume that `marcos` has an SSH server.
+
+How do you add all this stuff to git-annex?
+
+Create the biggest git-annex repository
+---------------------------------------
+
+Start with `marcos`, with the complete directory:
+
+    cd /srv/mp3
+    git init
+    git annex init
+    git annex add .
+    git commit -m "git annex yay"
+
+This will checksum all files and add them to the `git-annex` branch of the git repository. Wait for this process to complete.
+
+Create the smaller repo and synchronise
+---------------------------------------
+
+On `angela`, we want to synchronise the git annex metadata with `marcos`. We need to initialize a git repo with `marcos` as a remote:
+
+    cd ~/mp3
+    git init
+    git remote add marcos marcos.example.com:/srv/mp3
+    git fetch marcos
+    git annex info # this should display the two repos
+    git annex add .
+
+This will, again, checksum all files and add them to git annex. Once that is done, you can verify that the files are really the same as marcos with `whereis`:
+
+    git annex whereis
+
+This should display something like:
+
+    whereis Orange Seeds/I remember.wav (2 copies)
+            b7802161-c984-4c9f-8d05-787a29c41cfe -- marcos (anarcat@marcos:/srv/mp3)
+            c2ca4a13-9a5f-461b-a44b-53255ed3e2f9 -- here (anarcat@angela)
+    ok
+
+Once you are sure things went on okay, you can synchronise this with `marcos`:
+
+    git annex sync --allow-unrelated-histories
+
+This will push the metadata information to marcos, so it knows which files
+are available on `angela`. From there on, you can freely get and move files
+between the two repos!
+
+Importing files from a third directory
+--------------------------------------
+
+Say that some files on `angela` are actually spread out outside of the `~/mp3` directory. You can use the `git annex import` command to add those extra directories:
+
+    cd ~/mp3
+    git annex import ~/music/
+
+(!) Be careful that `~/music` is not a git-annex repository.
+
+Deleting deleted files
+----------------------
+
+It is quite possible some files were removed (or renamed!) on `marcos` but not on `angela`, since it was synchronised only some time ago. A good way to find out about those files is to use the `--not --in` argument, for example, on `angela`:
+
+    git annex whereis --in here --not --in marcos
+
+This will show files that are on `angela` and not on `marcos`. They could be new files that were only added on `angela`, so be careful! A manual analysis is necessary, but let's say you are certain those files are not relevant anymore, you can delete them from `angela`:
+
+    git annex drop <file>
diff --git a/doc/tips/migrating_two_seperate_disconnected_directories_to_git_annex/comment_1_d94ae69945416e57faa6e6dd5536f66e._comment b/doc/tips/migrating_two_seperate_disconnected_directories_to_git_annex/comment_1_d94ae69945416e57faa6e6dd5536f66e._comment
new file mode 100644
index 0000000000..2f739fe461
--- /dev/null
+++ b/doc/tips/migrating_two_seperate_disconnected_directories_to_git_annex/comment_1_d94ae69945416e57faa6e6dd5536f66e._comment
@@ -0,0 +1,59 @@
+[[!comment format=mdwn
+ username="Stefan"
+ avatar="http://cdn.libravatar.org/avatar/1474db4b030b82320e3bd5e899ef2bad"
+ subject="This guide fails with &quot;fatal: refusing to merge unrelated histories&quot;"
+ date="2022-10-29T10:28:18Z"
+ content="""
+This no longer works, here is a MWE to copy-paste (uses /tmp/{A,B}):
+
+```
+mkdir /tmp/A && touch /tmp/A/bigfile
+mkdir /tmp/B && touch /tmp/B/bigfile
+cd /tmp/A
+git init
+git annex init
+git annex add .
+git commit -m \"git annex yay\"
+cd /tmp/B
+git init
+git remote add A /tmp/A
+git fetch A
+git annex info # this should display the two repos
+git annex add .
+git annex whereis
+git annex sync
+```
+
+This fails with
+
+```
+commit 
+[main (root-commit) e9435bf] git-annex in stefan@notebook:/tmp/B
+ 1 file changed, 1 insertion(+)
+ create mode 120000 bigfile
+ok
+pull A 
+
+fatal: refusing to merge unrelated histories
+failed
+push A 
+Enumerating objects: 19, done.
+Counting objects: 100% (19/19), done.
+Delta compression using up to 8 threads
+Compressing objects: 100% (11/11), done.
+Writing objects: 100% (14/14), 1.37 KiB | 1.37 MiB/s, done.
+Total 14 (delta 2), reused 0 (delta 0), pack-reused 0
+To /tmp/A
+ * [new branch]      main -> synced/main
+ * [new branch]      git-annex -> synced/git-annex
+To /tmp/A
+ ! [rejected]        main -> main (non-fast-forward)
+error: failed to push some refs to '/tmp/A'
+hint: Updates were rejected because the tip of your current branch is behind
+hint: its remote counterpart. Integrate the remote changes (e.g.
+hint: 'git pull ...') before pushing again.
+hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+ok
+sync: 1 failed
+```
+"""]]
diff --git a/doc/tips/migrating_two_seperate_disconnected_directories_to_git_annex/comment_2_c6c11a9d5f9f136fa541404cdc49f45c._comment b/doc/tips/migrating_two_seperate_disconnected_directories_to_git_annex/comment_2_c6c11a9d5f9f136fa541404cdc49f45c._comment
new file mode 100644
index 0000000000..dc693fa467
--- /dev/null
+++ b/doc/tips/migrating_two_seperate_disconnected_directories_to_git_annex/comment_2_c6c11a9d5f9f136fa541404cdc49f45c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-10-31T16:09:12Z"
+ content="""
+Indeed, you will need to use `git-annex sync --allow-unrelated-histories`
+now in that situation. I have updated the tip.
+"""]]
diff --git a/doc/tips/multiple_remotes_accessing_the_same_data_store.mdwn b/doc/tips/multiple_remotes_accessing_the_same_data_store.mdwn
new file mode 100644
index 0000000000..d332e43700
--- /dev/null
+++ b/doc/tips/multiple_remotes_accessing_the_same_data_store.mdwn
@@ -0,0 +1,61 @@
+A remote configures git-annex with a way to access a particular data
+store. Sometimes, there's more than one way for git-annex to access the
+same underlying data store. It then makes sense to have multiple remotes.
+
+The most common and easy case of this is when the data store is itself a
+git-annex repository. For example, using git-annex on your laptop, you
+might add a ssh remote which works from anywhere. But, when you're located
+on the same LAN as the server, it might be faster or simpler to use a
+different ssh url.
+
+	git remote add server someserver.example.com:/data
+	git remote add lanserver someserver.lan:/data
+
+git-annex is able to realize automatically that these two remotes both
+access the same repository (by contacting the repository and looking up its
+git-annex uuid). You can use git-annex to access which ever remote you
+want to at a given time.
+
+[[Special_remotes]] don't store data in a git-annex repository. It's
+possible to configure two special remotes that access the same underlying
+data store, at least in theory. Whether it will work depends on how the
+two special remotes store their data. If they don't use the same filename
+(or whatever), it might not work.
+
+The case almost guaranteed to work is two special remotes of the same type,
+and other configuration, but with different urls that point to the same
+data store. For example, a [[special_remotes/git-lfs]] repository can be
+accessed using http or ssh. So two git-lfs special remotes can be set up,
+and both access the same data.
+
+	git annex initremote lfs-ssh type=git-lfs encryption=shared url=git@example.com:repo
+	git annex initremote --sameas=lfs-ssh lfs-http type=git-lfs url=https://example.com/repo
+
+The `--sameas` parameter tells git-annex that the new special remote
+uses the same data store as an existing special remote. Note that
+the encryption= parameter, which is usually mandatory, is omitted.
+The two necessarily encrypt data in the same way, so it will
+inherit the encryption configuration. Other configuration is not inherited,
+so if you need some parameter to initremote to make a special remote behave
+a certian way, be sure to pass it to both.
+
+Finally, it's sometimes possible to access the same data stored in two
+special remotes with different types. One combination that works is
+a [[special_remotes/directory]] special remote 
+and a [[special_remotes/rsync]] special remote.
+
+	git annex initremote dir type=directory encryption=none directory=/foo
+	git annex initremote --sameas=dir rsync type=rsync rsyncurl=localhost:/foo
+
+If a combination does not work, git-annex will be unable to access files
+in one remote or the other, it could get into a scrambled mess. So it's
+best to test a a combination carefully before you start using it for real.
+If you find combinations that work, please edit this page to list them.
+
+## known working combinations
+
+* directory and rsync
+* httpalso and directory
+* httpalso and rsync
+* httpalso and rclone (any layout except for frankencase)
+* httpalso and any special remote that uses exporttree=yes
diff --git a/doc/tips/offline_archive_drives.mdwn b/doc/tips/offline_archive_drives.mdwn
new file mode 100644
index 0000000000..1063cbc267
--- /dev/null
+++ b/doc/tips/offline_archive_drives.mdwn
@@ -0,0 +1,69 @@
+After you've used git-annex for a while, you will have data in your repository
+that you don't want to keep in the limited disk space of a laptop or a server,
+but that you don't want to entirely delete.
+
+This is where git-annex's support for offline archive drives shines.
+You can move old files to an archive drive, which can be kept offline if
+it's not practical to keep it spinning. Better, you can move old files to
+two or more archive drives, in case one of them later fails to spin up.  
+(One consideration when [[future_proofing]] your archive.)
+
+To set up an archive drive, you can take any removable drive, format
+it with a filesystem you'll be able to read some years later, and then follow
+the [[walkthrough]] to set up a repository on it that is a git remote of 
+the repository in your computer you want to archive. In short:
+
+	cd /media/archive
+	git clone ~/annex
+	cd ~/annex
+	git remote add archivedrive /media/archive/annex
+	git annex sync archivedrive
+
+Don't forget to  tell git-annex this is an archive drive (or a backup
+drive; see [[preferred_content]].). Also, give the drive a description that matches something you write on
+its label, so you can find it later:
+
+	git annex group archivedrive archive
+	git annex wanted archivedrive standard
+	git annex describe archivedrive "my first archive drive (SATA)"
+
+Or you can use the assistant to set up the drive for you.  
+(Nice video tutorial here: [[videos/git-annex_assistant_archiving]])
+
+(Keeping the archive drive in an offsite location? Consider encrypting
+it! See [[fully_encrypted_git_repositories_with_gcrypt]].)
+
+Then, when the archive drive is plugged in, you can easily copy files to
+it:
+
+	cd ~/annex
+	git-annex copy --auto --to archivedrive
+
+Or, if you're using the assistant, it will automatically notice when the drive
+gets plugged in and copy files that need to be archived.
+
+When you want to get rid of the local file, leaving only the copy on the
+archive, you can just:
+
+	git annex drop file
+
+The archive drive has to be plugged in for this to work, so git-annex
+can verify it still has the file. If you had configured git-annex to
+always store 2 [[copies]], it will need 2 archive drives plugged in.
+You may find it useful to configure a [[trust]] setting for the drive to
+avoid needing to haul it out of storage to drop a file.
+
+Now the really nice thing. When your archive drive gets filled up, you
+can simply remove it, store it somewhere safe, and replace it with a new
+drive, which can be mounted at the same location for simplicity. Set up
+the new drive the same way described above, and use it to archive even more
+files.
+
+Finally, when you want to access one of the files you archived, you can
+just ask for it:
+
+	git annex get file
+
+If necessary git-annex will tell you which archive drive you need to
+pull out of storage to get the file back. This is where the description
+you entered earlier comes in handy.
diff --git a/doc/tips/offline_archive_drives/comment_1_3d4fdf42191a9d81434d00f51c3609ff._comment b/doc/tips/offline_archive_drives/comment_1_3d4fdf42191a9d81434d00f51c3609ff._comment
new file mode 100644
index 0000000000..5855b0f7a7
--- /dev/null
+++ b/doc/tips/offline_archive_drives/comment_1_3d4fdf42191a9d81434d00f51c3609ff._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkC0W3ZQERUaTkHoks6k68Tsp1tz510nGo"
+ nickname="Georg"
+ subject="git annex sync"
+ date="2013-10-06T08:59:24Z"
+ content="""
+Shouldn't it be
+git annex sync archivedrive
+instead of
+git annex sync archive
+in the first examples. As the name of the remote is \"archivedrive\", IMO \"sync\" should be called with the name of the remote.
+"""]]
diff --git a/doc/tips/offline_archive_drives/comment_2_864c752aa8d064791a4b14dbbe2e6882._comment b/doc/tips/offline_archive_drives/comment_2_864c752aa8d064791a4b14dbbe2e6882._comment
new file mode 100644
index 0000000000..3ff074ff3c
--- /dev/null
+++ b/doc/tips/offline_archive_drives/comment_2_864c752aa8d064791a4b14dbbe2e6882._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkC0W3ZQERUaTkHoks6k68Tsp1tz510nGo"
+ nickname="Georg"
+ subject="git annex copy not working"
+ date="2013-10-06T10:18:10Z"
+ content="""
+Is the feature \"git-annex copy --auto --to usb\" working?
+I have created a backup repo on my usb drive but when I call \"git-annex copy --auto --to usb\" nothing happens.
+
+I have called \"git annex group usb backup\" and \"git annex sync usb\" to set up the repo.
+
+What is the correct way to get the data out to the backup repo?
+
+Best regards, Georg
+"""]]
diff --git a/doc/tips/offline_archive_drives/comment_3_7be2ccaf70c9ecfc9a34384e0e31f490._comment b/doc/tips/offline_archive_drives/comment_3_7be2ccaf70c9ecfc9a34384e0e31f490._comment
new file mode 100644
index 0000000000..cd58880093
--- /dev/null
+++ b/doc/tips/offline_archive_drives/comment_3_7be2ccaf70c9ecfc9a34384e0e31f490._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.243"
+ subject="thanks for your checking.."
+ date="2013-10-06T17:04:24Z"
+ content="""
+The example was missing a preferred content setting, without which --auto doesn't copy anything unless needed to satisfy numcopies:
+
+git annex wanted archivedrive standard
+"""]]
diff --git a/doc/tips/offline_archive_drives/comment_4_f9f2f8c59818d3d48475fa3cbf339ba3._comment b/doc/tips/offline_archive_drives/comment_4_f9f2f8c59818d3d48475fa3cbf339ba3._comment
new file mode 100644
index 0000000000..acd3ac1e94
--- /dev/null
+++ b/doc/tips/offline_archive_drives/comment_4_f9f2f8c59818d3d48475fa3cbf339ba3._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="dud225@35a1ee469f82f3a7eb1f2dce4ad453f5e47bdfd3"
+ nickname="dud225"
+ avatar="http://cdn.libravatar.org/avatar/5147563e50c475918474594d93be95c2"
+ subject="Groups comprised of archive drives of various size"
+ date="2023-04-17T10:12:58Z"
+ content="""
+I'd like to store multiple copies of my data but I'm not sure how to implement it with drives of various sizes.
+
+Let's assume that I'd like 3 copies of every file and I'd like the data to be laid out in 3 disk groups:
+
+1. big drive of 1TB
+2. 1 medium drive of 500GB and 2 small drives of 250GB
+3. 4 small drivers of 250GB
+
+The idea is to keep 1 group permanently at home while the 2 others would be stored in different remote locations and resynchronized from time to time. Each disk group would hold all the data, so that a loss of one of them wouldn't matter. Also the composition of those disk group would allow me to easily know which disks can be put aside while being ensured that they could contain all the data.
+
+How could this model be implemented with git-annex?
+"""]]
diff --git a/doc/tips/offline_archive_drives/comment_5_25c92a3602a1365d68e6bab080e4a41d._comment b/doc/tips/offline_archive_drives/comment_5_25c92a3602a1365d68e6bab080e4a41d._comment
new file mode 100644
index 0000000000..5422997e8c
--- /dev/null
+++ b/doc/tips/offline_archive_drives/comment_5_25c92a3602a1365d68e6bab080e4a41d._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-04-17T17:51:43Z"
+ content="""
+This is like the "archive" group, but you want 3 different ones. 
+git-annex already has a built-in "smallarchive" group that is not
+quite what you want (see [[preferred_content/standard_groups]]), so
+let's call them "archive1", "archive2", and "archive3".
+
+Configure the groups like this, so any member of a group wants to contain a file
+only if it will be the only member of the group to contain a copy.
+
+	git annex groupwanted archive1 "not copies=archive1:1"
+	git annex groupwanted archive2 "not copies=archive2:1"
+	git annex groupwanted archive3 "not copies=archive3:1"
+
+Then use `git-annex group` to put  to put each drive's repository in its
+respective group, and set `wanted` to "standard" to make it use the
+groupwanted expression. For example:
+
+	git-annex group bigdrive archive1
+	git-annex wanted bigdrive standard
+
+Then, `git-annex copy --to bigdrive --auto` and other similar commands
+with `--auto` (or `git-annex sync --content`) will distribute files to the
+drives.
+"""]]
diff --git a/doc/tips/offline_archive_drives/comment_6_f64f48f2bb5325bf9e14e2aa96a94429._comment b/doc/tips/offline_archive_drives/comment_6_f64f48f2bb5325bf9e14e2aa96a94429._comment
new file mode 100644
index 0000000000..0512076076
--- /dev/null
+++ b/doc/tips/offline_archive_drives/comment_6_f64f48f2bb5325bf9e14e2aa96a94429._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="dud225@35a1ee469f82f3a7eb1f2dce4ad453f5e47bdfd3"
+ nickname="dud225"
+ avatar="http://cdn.libravatar.org/avatar/5147563e50c475918474594d93be95c2"
+ subject="Groups comprised of archive drives of various size"
+ date="2023-05-03T07:49:19Z"
+ content="""
+Thanks Joey for your clear and comprehensive answer.
+
+Quoting a part of your answer:
+
+> and set wanted to \"standard\" to make it use the groupwanted expression.
+
+According to the documentation the \"standard\" groupwanted expression only allows to use the predefined expressions, so I assume that the groupwanted expression shall be set to \"groupwanted\" instead:
+
+    git-annex wanted bigdrive groupwanted
+"""]]
diff --git a/doc/tips/offline_archive_drives/comment_7_c8b506c4b2da98be430016e219680e34._comment b/doc/tips/offline_archive_drives/comment_7_c8b506c4b2da98be430016e219680e34._comment
new file mode 100644
index 0000000000..98ef311b5d
--- /dev/null
+++ b/doc/tips/offline_archive_drives/comment_7_c8b506c4b2da98be430016e219680e34._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2023-05-03T19:24:59Z"
+ content="""
+You're totally right, it needs groupwanted.
+"""]]
diff --git a/doc/tips/owncloudannex.mdwn b/doc/tips/owncloudannex.mdwn
new file mode 100644
index 0000000000..509f8749c1
--- /dev/null
+++ b/doc/tips/owncloudannex.mdwn
@@ -0,0 +1,14 @@
+For using Owncloud and Nextcloud 
+as a special remote, there are currently three choices:
+
+* Use git-annex's builtin [[special_remotes/webdav]] support.
+
+* Alternatively, rclone supports them
+  so the [[rclone_special_remote|special_remotes/rclone]] can be used.
+
+* Alternatively, there is a dedicated special remote,
+  <https://github.com/TobiasTheViking/owncloudannex>
+  (Last updated 2014)
+
+At this time it's not clear which is better, so if you find one works
+best, please comment below.
diff --git a/doc/tips/owncloudannex/comment_1_129652308c3c499462828dcaf8e747a4._comment b/doc/tips/owncloudannex/comment_1_129652308c3c499462828dcaf8e747a4._comment
new file mode 100644
index 0000000000..47e33042ec
--- /dev/null
+++ b/doc/tips/owncloudannex/comment_1_129652308c3c499462828dcaf8e747a4._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQvRLq7nMMEGoEKuYx9oaf67IC0nZfmVI"
+ nickname="chung yan"
+ subject="owncloud hook exited nonzero"
+ date="2013-07-10T05:03:47Z"
+ content="""
+hi 
+
+I got the above message, and cannot sync to my owncloud. Here is the log file i had: 
+
+>[2013-07-10 12:30:31 HKT] main: starting assistant version 4.20130627
+(scanning...) [2013-07-10 12:30:31 HKT] Watcher: Performing startup scan
+(started...) git-annex: Daemon is already running.
+git-annex: Daemon is already running.
+[2013-07-10 12:44:04 HKT] Committer: Adding sync2Servers.sh
+
+>add syncByRsync/sync2Servers.sh (checksum...) [2013-07-10 12:44:04 HKT] Committer: Committing changes to git
+(gpg) 
+
+>owncloud hook exited nonzero!
+>git-annex: Daemon is already running.
+[2013-07-10 12:51:07 HKT] main: Syncing with owncloud 
+
+>owncloud hook exited nonzero!
+>[2013-07-10 12:53:10 HKT] Committer: Adding 2 files
+ok
+(Recording state in git...)
+(Recording state in git...)
+add syncByRsync/DSCN1810.JPG (checksum...) ok
+add syncByRsync/DSCN1810.JPG (checksum...) [2013-07-10 12:53:10 HKT] Committer: Committing changes to git
+
+>owncloud hook exited nonzero!
+[2013-07-10 12:53:50 HKT] main: Syncing with owncloud 
+  owncloud hook exited nonzero!
+  owncloud hook exited nonzero!
+
+thanks
+
+yan
+"""]]
diff --git a/doc/tips/owncloudannex/comment_2_38604990368666f654d41891ba99ac61._comment b/doc/tips/owncloudannex/comment_2_38604990368666f654d41891ba99ac61._comment
new file mode 100644
index 0000000000..6ea0b033c0
--- /dev/null
+++ b/doc/tips/owncloudannex/comment_2_38604990368666f654d41891ba99ac61._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="comment 2"
+ date="2013-07-10T08:21:39Z"
+ content="""
+Personally i've only seen that when the server ran out of space. But lets see what is going on.
+
+Please run this command
+
+git config annex.owncloud-hook '/usr/bin/python2 ~/owncloudannex/owncloudannex.py --dbglevel 1 --stderr'
+
+And then replicate the error. It should give me some debug information to work with.
+
+"""]]
diff --git a/doc/tips/owncloudannex/comment_3_1bfd290d00d6536da7d31818db46f8ec._comment b/doc/tips/owncloudannex/comment_3_1bfd290d00d6536da7d31818db46f8ec._comment
new file mode 100644
index 0000000000..f7e3f0ee4d
--- /dev/null
+++ b/doc/tips/owncloudannex/comment_3_1bfd290d00d6536da7d31818db46f8ec._comment
@@ -0,0 +1,87 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQvRLq7nMMEGoEKuYx9oaf67IC0nZfmVI"
+ nickname="chung yan"
+ subject="comment 3"
+ date="2013-07-10T08:46:27Z"
+ content="""
+hi Tobias 
+
+Thanks your suggestion for list of my error log, here it is: 
+
+[2013-07-10 16:27:58 HKT] main: starting assistant version 4.20130627
+(scanning...) [2013-07-10 16:27:58 HKT] Watcher: Performing startup scan
+(started...) [2013-07-10 16:28:14 HKT] Committer: Adding 2 files
+
+add syncByRsync/sync2Servers.sh (checksum...) ok
+add syncByRsync/sync2Servers.sh (checksum...) [2013-07-10 16:28:14 HKT] Committer: Committing changes to git
+[2013-07-10 16:31:12 HKT] Watcher: add direct DSCN1810.JPG
+[2013-07-10 16:31:12 HKT] read: lsof [\"-F0can\",\"+d\",\"/home/yan/annex_testing/.git/annex/tmp/\"]
+[2013-07-10 16:31:12 HKT] Committer: Adding DSCN1810.JPG
+ok
+(Recording state in git...)
+(Recording state in git...)
+add DSCN1810.JPG [2013-07-10 16:31:12 HKT](checksum...)  Watcher: add direct DSCN1810.JPG
+[2013-07-10 16:31:12 HKT] read: sha256sum [\"/home/yan/annex_testing/.git/annex/tmp/DSCN181012023.JPG\"]
+
+  DSCN1810.JPG changed while it was being added
+[2013-07-10 16:31:12 HKT] Committer: delaying commit of 1 changes
+[2013-07-10 16:31:13 HKT] read: lsof [\"-F0can\",\"+d\",\"/home/yan/annex_testing/.git/annex/tmp/\"]
+[2013-07-10 16:31:13 HKT] Committer: Adding 2 files
+failed
+add DSCN1810.JPG (checksum...) [2013-07-10 16:31:13 HKT] read: sha256sum [\"/home/yan/annex_testing/.git/annex/tmp/DSCN181012023.JPG\"]
+[2013-07-10 16:31:13 HKT] chat: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"hash-object\",\"-t\",\"blob\",\"-w\",\"--stdin\",\"--no-filters\"]
+ok
+add DSCN1810.JPG (checksum...) [2013-07-10 16:31:13 HKT] read: sha256sum [\"/home/yan/annex_testing/.git/annex/tmp/DSCN181012024.JPG\"]
+[2013-07-10 16:31:13 HKT] chat: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"hash-object\",\"-t\",\"blob\",\"-w\",\"--stdin\",\"--no-filters\"]
+[2013-07-10 16:31:13 HKT] Committer: committing 2 changes
+[2013-07-10 16:31:13 HKT] Committer: Committing changes to git
+[2013-07-10 16:31:13 HKT] feed: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"update-index\",\"-z\",\"--index-info\"]
+[2013-07-10 16:31:13 HKT] read: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"commit\",\"--allow-empty-message\",\"--no-edit\",\"-m\",\"\",\"--quiet\",\"--no-verify\"]
+[2013-07-10 16:31:13 HKT] Committer: queued Upload UUID \"df02d32a-7e3a-4e12-a417-7f1d1a1cf1a6\" DSCN1810.JPG Nothing : new file created
+[2013-07-10 16:31:13 HKT] chat: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2013-07-10 16:31:13 HKT] feed: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"update-index\",\"-z\",\"--index-info\"]
+[2013-07-10 16:31:13 HKT] read: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2013-07-10 16:31:13 HKT] read: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"write-tree\"]
+[2013-07-10 16:31:13 HKT] chat: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"commit-tree\",\"a8337a989b58b29eee5fd2fa7a4c0b8ec45d5e59\",\"-p\",\"refs/heads/git-annex\"]
+[2013-07-10 16:31:13 HKT] call: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"update-ref\",\"refs/heads/git-annex\",\"267bf35da4d9abe5ed7fe82ea5df8a8df2ddf940\"]
+[2013-07-10 16:31:13 HKT] read: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"symbolic-ref\",\"HEAD\"]
+[2013-07-10 16:31:13 HKT] read: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"show-ref\",\"refs/heads/master\"]
+[2013-07-10 16:31:13 HKT] Transferrer: Transferring: Upload UUID \"df02d32a-7e3a-4e12-a417-7f1d1a1cf1a6\" DSCN1810.JPG Nothing
+[2013-07-10 16:31:13 HKT] read: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"show-ref\",\"git-annex\"]
+[2013-07-10 16:31:13 HKT] call: git-annex [\"transferkeys\",\"--readfd\",\"46\",\"--writefd\",\"36\"]
+[2013-07-10 16:31:13 HKT] read: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2013-07-10 16:31:13 HKT] read: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"log\",\"refs/heads/git-annex..267bf35da4d9abe5ed7fe82ea5df8a8df2ddf940\",\"--oneline\",\"-n1\"]
+[2013-07-10 16:31:13 HKT] read: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"show-ref\",\"git-annex\"]
+[2013-07-10 16:31:13 HKT] read:[2013-07-10 16:31:13 HKT] read: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"ls-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"preferred-content.log\"]
+ git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2013-07-10 16:31:13 HKT] read: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"log\",\"refs/heads/git-annex..267bf35da4d9abe5ed7fe82ea5df8a8df2ddf940\",\"--oneline\",\"-n1\"]
+[2013-07-10 16:31:13 HKT] chat: git [\"--git-dir=/home/yan/annex_testing/.git\",\"--work-tree=/home/yan/annex_testing\",\"cat-file\",\"--batch\"]
+(gpg) [2013-07-10 16:31:13 HKT] TransferWatcher: transfer starting: Upload UUID \"df02d32a-7e3a-4e12-a417-7f1d1a1cf1a6\" DSCN1810.JPG Nothing
+[2013-07-10 16:31:13 HKT] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"48\",\"--symmetric\",\"--force-mdc\"]
+[2013-07-10 16:31:14 HKT] call: sh [\"-c\",\"/usr/bin/python2 /home/yan/annex/SocialBusiness/Resources/Infrastructure/Computer_Tools/Records/AsusU24/owncloudannex/owncloudannex.py --dbglevel 1 --stderr\"]
+
+ 16:31:16 [owncloudannex-0.1.1] <module> : 'START'
+ 16:31:16 [owncloudannex-0.1.1] main : 'ARGS: 'ANNEX_ACTION=store ANNEX_KEY=GPGHMACSHA1--0179fbbf559d5c25cf69b4e92025ff1f007d4f1f ANNEX_HASH_1=fp ANNEX_HASH_2=23 ANNEX_FILE=/home/yan/annex_testing/.git/annex/tmp/GPGHMACSHA1--0179fbbf559d5c25cf69b4e92025ff1f007d4f1f /home/yan/annex/SocialBusiness/Resources/Infrastructure/Computer_Tools/Records/AsusU24/owncloudannex/owncloudannex.py --dbglevel 1 --stderr''
+ 16:31:16 [owncloudannex-0.1.1] readFile : ''/home/yan/annex/SocialBusiness/Resources/Infrastructure/Computer_Tools/Records/AsusU24/owncloudannex/owncloudannex.conf' - 'r''
+ 16:31:16 [owncloudannex-0.1.1] readFile : 'Done'
+ 16:31:16 [owncloudannex-0.1.1] login : ''
+ 16:31:16 [owncloudannex-0.1.1] login : 'Using base: wingyan.no-ip.org - {'Authorization': 'Basic Y2h1bmd5YW41QGdtYWlsLmNvbTp5YW5fd2lraQ=='}'
+ 16:31:16 [owncloudannex-0.1.1] login : 'res: <davlib.DAV instance at 0x12915f0>'
+ 16:31:16 [owncloudannex-0.1.1] findInFolder : 'u'gitannex'(<type 'unicode'>) - '/'(<type 'str'>)'
+ 16:31:17 [owncloudannex-0.1.1] findInFolder : 'propfind: /owncloud/remote.php/webdav - '<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<d:error xmlns:d=\"DAV:\" xmlns:s=\"http://sabredav.org/ns\">\n  <s:exception>Sabre_DAV_Exception_NotAuthenticated</s:exception>\n  <s:message>Username or password does not match</s:message>\n  <s:sabredav-version>1.7.6</s:sabredav-version>\n</d:error>\n''
+ 16:31:17 [owncloudannex-0.1.1] findInFolder : 'Failure'
+ 16:31:17 [owncloudannex-0.1.1] createFolder : '/gitannex'
+ 16:31:18 [owncloudannex-0.1.1] createFolder : 'Failure: 401 - '<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<d:error xmlns:d=\"DAV:\" xmlns:s=\"http://sabredav.org/ns\">\n  <s:exception>Sabre_DAV_Exception_NotAuthenticated</s:exception>\n  <s:message>Username or password does not match</s:message>\n  <s:sabredav-version>1.7.6</s:sabredav-version>\n</d:error>\n''
+
+
+  owncloud hook exited nonzero!
+[2013-07-10 16:31:18 HKT] TransferWatcher: transfer finishing: Transfer {transferDirection = Upload, transferUUID = UUID \"df02d32a-7e3a-4e12-a417-7f1d1a1cf1a6\", transferKey = Key {keyName = \"911ba6148fbcbe4afe53772f1216b8204f403ed4ee06cb90c3c3ac25e56d9402.JPG\", keyBackendName = \"SHA256E\", keySize = Just 1893431, keyMtime = Nothing}}
+
+I figured out it is a *Username or password does not match*, and i saw the content of owncloudannex.conf as \"uname\": \"myGmail@gmail.com\", but i quickly saw my WebDAV login to owncloud as my user name, not gmail address, so i changed this \"uname\": \"my_normal_user_name_not_gmail_acc\" inside owncloudannex.conf. Finally, i got it work. So, i think, user name should not be a gmail address, should be owncloud login user name. 
+
+Another issue, i had a look into /WebDAV.../gitannex/, it is git repos. file, for my user opinion, it is better that it is a real file content that we can see the file(such as photos) by owncloud web client directly, rather that owncloud is a file server to keep git repos only. 
+
+Thanks
+
+yan
+"""]]
diff --git a/doc/tips/owncloudannex/comment_4_492b6922a7c5bb5464fedb46b0c5303b._comment b/doc/tips/owncloudannex/comment_4_492b6922a7c5bb5464fedb46b0c5303b._comment
new file mode 100644
index 0000000000..c7a0875df1
--- /dev/null
+++ b/doc/tips/owncloudannex/comment_4_492b6922a7c5bb5464fedb46b0c5303b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="comment 4"
+ date="2013-07-10T08:54:13Z"
+ content="""
+Hm, an error like that it really should print without the need of debug information. I'll look into it.
+
+And if you want the real file content, not encrypted, just change \"shared\" to \"none\" in the line:
+
+git annex initremote owncloud type=hook hooktype=owncloud encryption=shared
+
+I'm not sure if you can change this after you initialized the remote though. And also, the folder structure and filenames will be as you see them now on the owncloud. I'd need some more data from gitannex to make it show the real directory structure. But that doesn't seem feasible.
+
+Why would you even want the data unencrypted on owncloud anyways? i mean on flickr, or googledocs, i kinda get it. but for owncloud?
+
+"""]]
diff --git a/doc/tips/owncloudannex/comment_5_1d48ac08714fadcb06d874570d745bd8._comment b/doc/tips/owncloudannex/comment_5_1d48ac08714fadcb06d874570d745bd8._comment
new file mode 100644
index 0000000000..170e8b857a
--- /dev/null
+++ b/doc/tips/owncloudannex/comment_5_1d48ac08714fadcb06d874570d745bd8._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQvRLq7nMMEGoEKuYx9oaf67IC0nZfmVI"
+ nickname="chung yan"
+ subject="comment 5"
+ date="2013-07-10T09:43:55Z"
+ content="""
+hi Tobias
+
+thanks your sharing, i am still in have a trial of git-annex, so i do not yet have real data on the server, so i just del. all and re-create both client and server repos in owncloud, i can got what you said, and see my photo. 
+
+Actually, i am studying git-annex. 1) It can syncs the data from my client computer to server. 2) i would like that other and anywhere computers through browser can view my server data which do not need to download all data into a new client. So my original goal is i can have a web to display the content of my files, and see owncloud have a nice web. 
+
+Regarding to GDoc, flickr, etc. they have space limitation, so i install owncloud as my own computer. I also see the <http://git-annex.branchable.com/design/assistant/partial_content/>, but it is not yet at roadmap. 
+
+thanks
+"""]]
diff --git a/doc/tips/owncloudannex/comment_6_65959f49a2f56bffd6fe48670c0c8d5a._comment b/doc/tips/owncloudannex/comment_6_65959f49a2f56bffd6fe48670c0c8d5a._comment
new file mode 100644
index 0000000000..7b10068c50
--- /dev/null
+++ b/doc/tips/owncloudannex/comment_6_65959f49a2f56bffd6fe48670c0c8d5a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLB39PC89rfGaA8SwrsnB6tbumezj-aC0"
+ nickname="Tobias"
+ subject="comment 6"
+ date="2013-07-10T09:50:14Z"
+ content="""
+A 1 terabyte limit(for flickr) should be enough for most people. No?
+"""]]
diff --git a/doc/tips/owncloudannex/comment_7_7482002991672ef67836bae43b8d0be8._comment b/doc/tips/owncloudannex/comment_7_7482002991672ef67836bae43b8d0be8._comment
new file mode 100644
index 0000000000..56e71276d6
--- /dev/null
+++ b/doc/tips/owncloudannex/comment_7_7482002991672ef67836bae43b8d0be8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQvRLq7nMMEGoEKuYx9oaf67IC0nZfmVI"
+ nickname="chung yan"
+ subject="comment 7"
+ date="2013-07-10T09:56:54Z"
+ content="""
+i have not got this 1 terabyte limit from flick before. I will have a look. I still consider some my own data, it is better to keep at my own server. 
+"""]]
diff --git a/doc/tips/owncloudannex/comment_8_6579203d726f4a39db02fcdda156e12c._comment b/doc/tips/owncloudannex/comment_8_6579203d726f4a39db02fcdda156e12c._comment
new file mode 100644
index 0000000000..c0295be033
--- /dev/null
+++ b/doc/tips/owncloudannex/comment_8_6579203d726f4a39db02fcdda156e12c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn97aJ3CN48pBix54RDHRhqtBzeklNEbSA"
+ nickname="Manuel"
+ subject="advantage of owncloudannex over webdav remote?"
+ date="2015-01-08T18:00:48Z"
+ content="""
+It seems that owncloud can also be accessed using the webdav remote. Does owncloudannex offer any features which aren't implemented in the webdav remote?
+"""]]
diff --git a/doc/tips/owncloudannex/comment_9_e52582d76e9b57cc11791f2730389605._comment b/doc/tips/owncloudannex/comment_9_e52582d76e9b57cc11791f2730389605._comment
new file mode 100644
index 0000000000..b145cabd8b
--- /dev/null
+++ b/doc/tips/owncloudannex/comment_9_e52582d76e9b57cc11791f2730389605._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="asked upstream"
+ date="2018-10-07T18:07:05Z"
+ content="""
+i [asked that question upstream](https://github.com/TobiasTheViking/owncloudannex/issues/6) more directly to see what we're missing out in webdav land. :) One thing webdav *has* over this special remote is support for the new [[git-annex-export]] command...
+"""]]
diff --git a/doc/tips/peer_to_peer_network_with_tor.mdwn b/doc/tips/peer_to_peer_network_with_tor.mdwn
new file mode 100644
index 0000000000..2a9287a5a8
--- /dev/null
+++ b/doc/tips/peer_to_peer_network_with_tor.mdwn
@@ -0,0 +1,232 @@
+git-annex has recently gotten support for running as a
+[Tor](https://torproject.org/) hidden service. This is a nice secure
+and easy to use way to connect repositories in different
+locations. No account on a central server is needed; it's peer-to-peer.
+
+## dependencies
+
+To use this, you need to get Tor installed and running. See
+[their website](https://torproject.org/), or try a command like:
+
+	sudo apt-get install tor
+
+You also need to install [Magic Wormhole](https://github.com/warner/magic-wormhole) -
+here are [the installation instructions](https://magic-wormhole.readthedocs.io/en/latest/welcome.html#installation).
+
+*Important:*
+
+* At the time of writing, you need to install Magic Wormhole under Python 2,
+  because [Tor support is only available under python2.7](https://magic-wormhole.readthedocs.io/en/latest/tor.html).
+
+* The installation process must make a `wormhole` executable available
+  somewhere on your `$PATH`.  Some distributions may only install executables
+  which reference the Python version, e.g. `wormhole-2.7`, in which case you
+  will need to manually create a symlink (and maybe file a bug with your distribution).
+
+* You need git-annex version 6.20180705. Older versions of git-annex
+  unfortunately had a bug that prevents this process from working correctly.
+
+## pairing two repositories
+
+You have two git-annex repositories on different computers, and want to
+connect them together over Tor so they share their contents. Or, you and a
+friend want to connect your repositories together. Pairing is an easy way
+to accomplish this.
+
+(The instructions below use the command line. If you or your friend would
+rather avoid using the command line, follow the
+[[webapp_walkthrough|assistant/share_with_a_friend_walkthrough]]. It's fine
+for one person to use the command line and the other to use the webapp.)
+
+In each git-annex repository, run these commands:
+
+	git annex enable-tor
+	git annex remotedaemon
+
+The enable-tor command may prompt for the root password, since it
+configures Tor. Now git-annex is running as a Tor hidden service, but 
+it will only talk to peers after pairing with them.
+
+In both repositories, run this command:
+
+	git annex p2p --pair
+
+This will print out a pairing code, like "11-incredible-tumeric",
+and prompt for you to enter the other repository's pairing code.
+
+So you have to get in contact with your friend to exchange codes.
+See the section below "how to exchange pairing codes" for tips on
+how to do that securely.
+
+Once the pairing codes are exchanged, the two repositories will be securely
+connected to one-another via Tor. Each will have a git remote, with a name
+like "peer1", which connects to the other repository. 
+
+Then, you can run commands like `git annex sync peer1 --content` to sync
+with the paired repository.
+
+Pairing connects just two repositories, but you can repeat the process to
+pair with as many other repositories as you like, in order to build up
+larger networks of repositories.
+
+## example session
+
+Here's how it all looks:
+
+	$ git annex enable-tor
+	enable-tor
+	  You will be prompted for root's password
+	Password:
+	
+	  Tor hidden service is configured. Checking connection to it. This may take a few minutes.
+
+	  Tor hidden service is working.
+	ok
+	$ git annex remotedaemon
+	$ git annex p2p --pair
+	p2p pair peer1 (using Magic Wormhole) 
+	
+	This repository's pairing code is: 11-incredible-tumeric
+	
+	Enter the other repository's pairing code: 1-revenue-icecream
+	Exchanging pairing data...
+	Successfully exchanged pairing data. Connecting to peer1...
+	ok
+	$ git annex sync peer1 --content
+		commit 
+	On branch master
+	nothing to commit, working tree clean
+	ok
+	pull peer1 
+	remote: Enumerating objects: 10, done.
+	remote: Counting objects: 100% (10/10), done.
+	remote: Compressing objects: 100% (7/7), done.
+	remote: Total 8 (delta 0), reused 0 (delta 0)
+	Unpacking objects: 100% (8/8), done.
+	From tor-annex::wa3i6wgttmworwli.onion:5162
+	   452db22..a894c60  git-annex  -> peer1/git-annex
+	   c0ac431..44ca7f6  master     -> peer1/master
+	
+	Updating c0ac431..44ca7f6
+	Fast-forward
+	 amazing_file | 1 +
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 amazing_file
+	ok
+	(merging peer1/git-annex into git-annex...)
+	get amazing_file (from peer1...) 
+	(checksum...) ok
+
+## how to exchange pairing codes
+
+When pairing with a friend's repository, you have to exchange
+pairing codes. How to do this securely?
+
+The pairing codes can only be used once, so it's ok to exchange them in
+a way that someone else can access later. However, if someone can overhear
+your exchange of codes in real time, they could trick you into pairing
+with them.
+
+Here are some suggestions for how to exchange the codes,
+with the most secure ways first:
+
+* In person.
+* In an encrypted message (gpg signed email, Off The Record (OTR)
+  conversation, etc).
+* By a voice phone call.
+
+## starting git-annex remotedaemon on boot
+
+Notice the `git annex remotedaemon` being run in the above examples.
+That command runs the Tor hidden service so that other peers
+can connect to your repository over Tor.
+
+So, you may want to arrange for the remotedaemon to be started on boot.
+You can do that with a simple cron job:
+
+	@reboot cd ~/myannexrepo && git annex remotedaemon
+
+If you use the git-annex assistant, and have it auto-starting on boot, it
+will take care of starting the remotedaemon for you.
+
+## speed of large transfers
+
+Tor prioritizes security over speed, and the Tor network only has so much
+bandwidth to go around. So, distributing large quantities (gigabytes) 
+of data over Tor may be slow, and should probably be avoided.
+
+One way to avoid sending much data over tor is to set up an encrypted
+[[special_remote|special_remotes]] someplace. git-annex knows that Tor is
+rather expensive to use, so if a file is available on a special remote as
+well as over Tor, it will download it from the special remote.
+
+You can contribute to the Tor network by
+[running a Tor relay or bridge](https://www.torproject.org/getinvolved/relays.html.en).
+
+## onion addresses and authentication
+
+You don't need to know about this, but it might be helpful to understand
+how it works.
+
+git-annex's Tor support uses onion address as the address of a git remote.
+You can `git pull`, push, etc with those onion addresses:
+
+	git pull tor-annex::eeaytkuhaupbarfi.onion:4412
+	git remote add peer1 tor-annex::eeaytkuhaupbarfi.onion:4412
+
+Onion addresses are semi-public. When you add a remote, they appear in your
+`.git/config` file. For security, there's a second level of authentication
+that git-annex uses to make sure that only people you want to can access
+your repository over Tor. That takes the form of a long string of numbers
+and letters, like "7f53c5b65b8957ef626fd461ceaae8056e3dbc459ae715e4".
+
+The addresses generated by `git annex p2p --gen-addresses` 
+combine the onion address with the authentication data.
+
+When you run `git annex p2p --link`, it sets up a git remote using
+the onion address, and it stashes the authentication data away in a file in
+`.git/annex/creds/`
+
+When you pair repositories, these addresses are exchanged using 
+[Magic Wormhole](https://github.com/warner/magic-wormhole).
+
+## security
+
+Tor hidden services can be quite secure. But this doesn't mean that using
+git-annex over Tor is automatically perfectly secure. Here are some things
+to consider:
+
+* Anyone who learns the onion address address and authentication data of a peer
+  can connect to that peer, download the whole history of the git repository,
+  and any available annexed files. They can also upload new files to the peer,
+  and even remove annexed files from the peer. So consider ways that the
+  authentication data of a peer might be exposed.
+
+* While Tor can be used to anonymize who you are, git defaults to including
+  your name and email address in git commit messages. So if you want an
+  anonymous git-annex repository, you'll need to configure git not to do
+  that.
+
+* Using Tor prevents listeners from decrypting your traffic. But, they'll
+  probably still know you're using Tor. Also, by traffic analysis,
+  they may be able to guess if you're using git-annex over tor, and even
+  make guesses about the sizes and types of files that you're exchanging
+  with peers.
+
+* There have been past attacks on the Tor network that have exposed
+  who was running Tor hidden services.
+  <https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack>
+
+* An attacker who can connect to the git-annex Tor hidden service, even
+  without authenticating, can try to perform denial of service attacks.
+
+* Magic wormhole is pretty secure, but the code phrase could be guessed
+  (unlikely) or intercepted. An attacker gets just one chance to try to enter
+  the correct code phrase, before pairing finishes. If the attacker
+  successfully guesses/intercepts both code phrases, they can MITM the
+  pairing process.
+
+  If you don't want to use magic wormhole, you can instead manually generate
+  addresses with `git annex p2p --gen-addresses` and send them over an
+  authenticated, encrypted channel (such as OTR) to a friend to add with
+  `git annex p2p --link`. This may be more secure, if you get it right.
diff --git a/doc/tips/peer_to_peer_network_with_tor/comment_1_72d4ea5ffa23f5048c453c2e7510e2f0._comment b/doc/tips/peer_to_peer_network_with_tor/comment_1_72d4ea5ffa23f5048c453c2e7510e2f0._comment
new file mode 100644
index 0000000000..a3cfa01b43
--- /dev/null
+++ b/doc/tips/peer_to_peer_network_with_tor/comment_1_72d4ea5ffa23f5048c453c2e7510e2f0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="dvicory"
+ avatar="http://cdn.libravatar.org/avatar/9e4b9df55a9c1440101dc66aa0a6b62d"
+ subject="Security of P2P repo is unclear"
+ date="2017-02-28T20:30:30Z"
+ content="""
+In the security section, you say that
+
+> Anyone who learns the address of a peer can connect to that peer, download the whole history of the git repository, and any available annexed files. They can also upload new files to the peer, and even remove annexed files from the peer. So consider ways that the address of a peer might be exposed.
+
+Do you mean the addresses from `git annex peer --gen-addresses` here? Say, if someone has only my onion service address, and none of the authentication data that is normally placed in `.git/annex/creds/`, what can they do with my git repository? I think I might be confused by the use of \"address\" because of onion addresses, which are not private.
+"""]]
diff --git a/doc/tips/peer_to_peer_network_with_tor/comment_2_8180e202fc493ad07999a3367ccd9425._comment b/doc/tips/peer_to_peer_network_with_tor/comment_2_8180e202fc493ad07999a3367ccd9425._comment
new file mode 100644
index 0000000000..de78462af0
--- /dev/null
+++ b/doc/tips/peer_to_peer_network_with_tor/comment_2_8180e202fc493ad07999a3367ccd9425._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-03-02T17:24:23Z"
+ content="""
+@dvicory if someone only knows the onion service address, they can do
+nothing to your repository except connect to it and get rejected
+due to failure to authenticate. They need the authentication data too
+in order to do any of those things. That was talking about the
+addresses generated by `git annex peer --gen-addresses`, 
+which include authentication data.
+
+I've improved the wording to avoid confusion between git-annex's addresses
+and onion addresses.
+"""]]
diff --git a/doc/tips/peer_to_peer_network_with_tor/comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment b/doc/tips/peer_to_peer_network_with_tor/comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment
new file mode 100644
index 0000000000..583495994a
--- /dev/null
+++ b/doc/tips/peer_to_peer_network_with_tor/comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="onion-grater"
+ date="2017-03-30T14:49:12Z"
+ content="""
+you may want to consider using [onion-grater][] to limit possible escalations in the use of that control port:
+
+ [onion-grater]: https://github.com/Whonix/onion-grater
+
+RFP: [[!debbug 859125]]
+"""]]
diff --git a/doc/tips/peer_to_peer_network_with_tor/comment_4_917eee70600e13470f70555abe06597d._comment b/doc/tips/peer_to_peer_network_with_tor/comment_4_917eee70600e13470f70555abe06597d._comment
new file mode 100644
index 0000000000..a9326dbe8a
--- /dev/null
+++ b/doc/tips/peer_to_peer_network_with_tor/comment_4_917eee70600e13470f70555abe06597d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-04-05T15:47:55Z"
+ content="""
+@anarcat, I'm not sure I follow how git-annex would use that. It
+does not currently use the tor control port at all when setting up
+its tor hidden service. But please file a todo item if I'm wrong
+and there's something to be improved.
+
+(What would be useful is if tor came with the control port enabled
+by default, and perhaps protected by something like onion-grater.
+Then git-annex could use it when it installs its hidden service,
+instead of its current approach of prompting for the root password
+and modifying the torrc file.)
+"""]]
diff --git a/doc/tips/peer_to_peer_network_with_tor/comment_5_6db70bb9266a92e249587bc4d095c472._comment b/doc/tips/peer_to_peer_network_with_tor/comment_5_6db70bb9266a92e249587bc4d095c472._comment
new file mode 100644
index 0000000000..7051cc3f3c
--- /dev/null
+++ b/doc/tips/peer_to_peer_network_with_tor/comment_5_6db70bb9266a92e249587bc4d095c472._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="Issue on openSUSE with Tor's requirement for Python 2.7 "
+ date="2019-09-29T16:41:15Z"
+ content="""
+I have updated the instructions to note two extra dependencies, the combination of which break this setup process out of the box on openSUSE.  I've filed [a bug with openSUSE](https://bugzilla.opensuse.org/show_bug.cgi?id=1152403) to improve their python-magic-wormhole package.  Hopefully I can work with the package maintainers to make this a non-issue. 
+"""]]
diff --git a/doc/tips/playlist_fetch.mdwn b/doc/tips/playlist_fetch.mdwn
new file mode 100644
index 0000000000..1f353eb311
--- /dev/null
+++ b/doc/tips/playlist_fetch.mdwn
@@ -0,0 +1,29 @@
+I have made a small script to fetch a specific set of songs from a
+playlist. It just iterates through a [M3U][] playlist and makes sure
+that git-annex has a copy of every file in the list.
+
+Sample run:
+
+    [1041]anarcat@angela:Music1$ ~/bin/get-playlist -p1 -v ~/playlists/Favoris.m3u
+    git-annex: Bach/Unknown Album/Concerto for 2 Violins in D.mp3 not found
+    git-annex: get: 1 failed
+    git annex failed to get Bach/Unknown Album/Concerto for 2 Violins in D.mp3 (originally espresso/Bach/Unknown Album/Concerto for 2 Violins in D.mp3)
+    get Groovy Aardvark/Oryctérope/05 - Téléthargique.flac (from marcos...)
+    SHA256E-s26735079--13c04501b9c6fa5ddda02438484d569f4d3d9b1f0bcdd8740f3b927ab756c968.flac
+         26,735,079 100%   10.00MB/s    0:00:02 (xfr#1, to-chk=0/1)
+    (checksum...) ok
+    Groovy Aardvark/Oryctérope/05 - Téléthargique.flac
+    [...]
+    merge git-annex ok
+
+I use this to synchronize specific playlists to my phone, instead of
+the whole music collection, because of the limited space of the
+device.
+
+The source is AGPL and available in my
+[personal git repository][]. Unfortunately, it is written in Python
+and can probably not be merged into git-annex, but since it is so
+specific, I figured it wouldn't be anyways. -- [[anarcat]]
+
+[personal git repository]: http://src.anarc.at/scripts.git/blob_plain/HEAD:/get-playlist
+[M3U]: https://en.wikipedia.org/wiki/M3U
diff --git a/doc/tips/playlist_fetch/comment_1_5310fd53406d35f36deff68e8c2cb599._comment b/doc/tips/playlist_fetch/comment_1_5310fd53406d35f36deff68e8c2cb599._comment
new file mode 100644
index 0000000000..87d4420642
--- /dev/null
+++ b/doc/tips/playlist_fetch/comment_1_5310fd53406d35f36deff68e8c2cb599._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="datamanager"
+ avatar="http://cdn.libravatar.org/avatar/7d4ca7c5e571d4740ef072b83a746c12"
+ subject="an alternative"
+ date="2021-06-23T01:29:23Z"
+ content="""
+This is cool! I had to do the same thing earlier tonight, and ended up with this:
+
+```
+cat ~/path/to/playlist.m3u | sed -e \"s/\ /\\\ /g\" | xargs git annex copy --to remote
+```
+
+I thought I might stick that into a bash alias, or function. 
+"""]]
diff --git a/doc/tips/powerful_file_matching.mdwn b/doc/tips/powerful_file_matching.mdwn
new file mode 100644
index 0000000000..47f8c8a64c
--- /dev/null
+++ b/doc/tips/powerful_file_matching.mdwn
@@ -0,0 +1,36 @@
+git-annex has a powerful syntax for making it act on only certain files.
+
+The simplest thing is to exclude some files, using wild cards:
+
+	git annex get --exclude '*.mp3' --exclude '*.ogg'
+
+But you can also exclude files that git-annex's [[location_tracking]]
+information indicates are present in a given repository. For example,
+if you want to populate newarchive with files, but not those already
+on oldarchive, you could do it like this:
+
+	git annex copy --not --in oldarchive --to newarchive
+
+Without the --not, --in makes it act on files that *are* in the specified
+repository. So, to remove files that are on oldarchive:
+
+	git annex drop --in oldarchive
+
+Or maybe you're curious which files have a lot of copies, and then
+also want to know which files have only one copy:
+
+	git annex find --copies 7
+	git annex find --not --copies 2
+
+The above are the simple examples of specifying what files git-annex
+should act on. But you can specify anything you can dream up by combining
+the things above, with --and --or -( and -). Those last two strange-looking
+options are parentheses, for grouping other options. You will probably
+have to escape them from your shell.
+
+Here are the mp3 files that are in either of two repositories, but have
+less than 3 copies:
+
+	git annex find --not --exclude '*.mp3' --and \
+		-\( --in usbdrive --or --in archive -\) --and \
+		--not --copies 3
diff --git a/doc/tips/public_Amazon_S3_remote.mdwn b/doc/tips/public_Amazon_S3_remote.mdwn
new file mode 100644
index 0000000000..84f912e549
--- /dev/null
+++ b/doc/tips/public_Amazon_S3_remote.mdwn
@@ -0,0 +1,61 @@
+Here's how to create a Amazon [[S3 special remote|special_remotes/S3]] that
+can be read by anyone who gets a clone of your git-annex repository,
+without them needing Amazon AWS credentials.
+
+If you want to publish files to S3 so they can be accessed without using
+git-annex, see [[publishing_your_files_to_the_public]].
+
+Note: Bear in mind that Amazon will charge the owner of the bucket
+for public downloads from that bucket.
+
+## create public remote
+
+First, export your Amazon AWS credentials:
+
+	# export AWS_ACCESS_KEY_ID="08TJMT99S3511WOZEP91"
+	# export AWS_SECRET_ACCESS_KEY="s3kr1t"
+
+Now, create the remote:
+
+	# git annex initremote pubs3 type=S3 encryption=none public=yes
+	initremote pubs3 (checking bucket) (creating bucket in US) ok
+
+The public=yes makes git-annex set a S3 ACL so the files in the bucket
+are publically readable. For git-annex to be able to download files from
+that bucket without needing your AWS credentials, you then need to tell
+it the url of the bucket. Find that url, and run:
+
+	# git annex enableremote pubs3 publicurl=...
+
+In the above example, no encryption was used, but it will also work
+if you enable encryption=shared. Then files will be encrypted on S3, and
+anyone with a clone of the git repository will be able to download and
+decrypt them.
+
+It's also ok to enable chunking when setting up the remote.
+
+Now, copy some files to the remote, in the usual way, and push your
+git repository to someplace where someone else can access it.
+
+## use public remote
+
+Once the S3 remote is set up, anyone who can clone the git repositry
+can get files from the remote, without needing any Amazon AWS credentials.
+
+Start by checking out the git repository. 
+
+In the checkout, enable the S3 remote:
+
+	# git annex enableremote pubs3
+	enableremote pubs3 ok
+
+Now, git-annex can be used as usual to download files from that remote.
+
+## sharing urls
+
+You can also share urls to files stored in a public S3 remote to people
+who are not using git-annex. To find the url, use `git annex whereis`.
+
+----
+
+See [[special_remotes/S3]] for details about configuring S3 remotes.
diff --git a/doc/tips/public_Amazon_S3_remote/comment_1_a2684b49dbc2de45b644523f47b3c891._comment b/doc/tips/public_Amazon_S3_remote/comment_1_a2684b49dbc2de45b644523f47b3c891._comment
new file mode 100644
index 0000000000..bc94d7e939
--- /dev/null
+++ b/doc/tips/public_Amazon_S3_remote/comment_1_a2684b49dbc2de45b644523f47b3c891._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="jared@ce91556d9548d318ec3f690b5f9bc33721256e4d"
+ nickname="jared"
+ avatar="http://cdn.libravatar.org/avatar/09bdb433e2a9448d780086be1e3d4f10"
+ subject="Unable to access public s3 remote without S3 credentials."
+ date="2018-06-21T13:47:27Z"
+ content="""
+I'm setting up a repository using the following commands:
+
+    git annex init
+    export AWS_ACCESS_KEY_ID=\"[MY KEY]\"
+    export AWS_SECRET_ACCESS_KEY=\"[MY SECRET]\"
+    git annex initremote publics3 type=S3 encryption=none bucket=[BUCKET] exporttree=yes public=yes encryption=none
+    git annex export --tracking master --to publics3
+
+I then add something and export it to s3 using:
+
+    git annex sync --content
+
+I then go on to a different computer and clone the repository and run:
+
+    git annex init
+    git annex enableremote publics3
+    git annex get .
+
+and receive this message:
+
+    # git annex get .
+    get IMG_2714.MOV (from publics3...) 
+    Set both AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to use S3
+
+    No S3 credentials configured
+
+    Unable to access these remotes: publics3
+
+    Try making some of these repositories available:
+         6bc91baa-5250-41e2-8195-d3c1ef3c86e3 -- .
+         7f84dcff-5a74-42b0-b422-5b74490e4aa7 -- [publics3]
+
+     (Note that these git remotes have annex-ignore set: origin)
+failed
+    git-annex: get: 1 failed
+
+
+It is my understanding that setting the remote to \"public=yes\" should allow me to download the files from the remote repository without entering the credentials again. Am I missing something?
+
+Thanks!
+"""]]
diff --git a/doc/tips/public_Amazon_S3_remote/comment_2_f155c3aa054a23df1ab057baaa300a62._comment b/doc/tips/public_Amazon_S3_remote/comment_2_f155c3aa054a23df1ab057baaa300a62._comment
new file mode 100644
index 0000000000..bc6d1a0c6d
--- /dev/null
+++ b/doc/tips/public_Amazon_S3_remote/comment_2_f155c3aa054a23df1ab057baaa300a62._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-07-02T16:18:37Z"
+ content="""
+It seems to me that you need to tell git-annex the publicurl to use to
+download files from this S3 remote. That's the url to the top of the S3
+bucket. Run `git annex enableremote publics3 publicurl=...' and push,
+and it should then become available in every clone.
+
+The documentation for publicurl says it's enabled by default when
+public=yes, but AFAICS it's never actually done that. And I'm not sure I
+want to hardcode those urls into git-annex. I've updated the documentation
+instead.
+"""]]
diff --git a/doc/tips/publishing_your_files_to_the_public.mdwn b/doc/tips/publishing_your_files_to_the_public.mdwn
new file mode 100644
index 0000000000..79ca1afa3b
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public.mdwn
@@ -0,0 +1,78 @@
+You have a git-annex repository, and you want to publish the files
+in it to the public. One way is to
+[[setup_a_public_repository_on_a_web_site]], but perhaps you don't have a
+web server that can run git-annex, and you just want to publish the current
+files, not the whole git-annex repository.
+
+The [[git-annex export|git-annex-export]] command is the solution. It lets
+a tree of files from your git-annex repository be published to Amazon 
+[[special_remotes/S3]], as well as other types of special remotes like
+[[special_remotes/webdav]] and [[special_remotes/directory]].
+
+# Publishing to Amazon S3
+
+Let's create a bucket in Amazon S3 named $BUCKET and a special remote
+named public-s3. Exporting has to be enabled when setting up a special
+remote for the first time.
+
+Set up your special [[S3 remote|special_remotes/S3]] with (at least) these options:
+
+	git annex initremote public-s3 type=S3 encryption=none bucket=$BUCKET exporttree=yes public=yes
+
+Be sure to replace $BUCKET with something like 
+"public-bucket-joey" when you follow along in your shell.
+
+[[!template id=note text="""
+Want to only export files in a subdirectory of the master branch?
+Use `master:subdir`. 
+
+Any git treeish can be used with the export command, so you can also
+export tags, etc.
+"""]]
+
+Then export the files in the master branch to the remote:
+
+	git annex export master --to public-s3
+
+Each exported file will be available to the public at
+`http://$BUCKET.s3.amazonaws.com/$FILE`
+
+Note: Bear in mind that Amazon will charge the owner of the bucket
+for public downloads from that bucket.
+
+# Using `git-annex sync --content`
+
+So far, the current contents of the master branch have been exported to
+public-s3, and to update the export when the branch changes, you have to
+remember to run `git annex export` again.
+
+If you use a `git annex sync` workflow, it's useful to configure
+it to also export changes to the remote. This is done by setting
+the remote's `annex-tracking-branch` configuration:
+	
+	git config remote.public-s3.annex-tracking-branch master
+
+That tells git-annex that the export should track changes to master.
+When you run `git annex sync --content`, it will update all tracking
+exports. The git-annex assistant also automatically updates tracking
+exports.
+
+Want to only export files in a subdirectory of the master branch?
+
+	git config remote.public-s3.annex-tracking-branch master:subdir
+
+# Amazon S3 indexes
+
+By default, there is no index.html file exported, so if you open
+`http://$BUCKET.s3.amazonaws.com/` in a web browser, you'll see an
+XML document listing the files.
+
+For a nicer list of files, you can make an index.html file, check it into
+git, and export it to the bucket. You'll need to configure the bucket to
+use index.html as its index document, as
+[explained here](https://stackoverflow.com/questions/27899/is-there-a-way-to-have-index-html-functionality-with-content-hosted-on-s3).
+
+# Old method
+
+To use `git annex export`, you need git-annex version 6.20170909 or
+newer. Before we had `git annex export` an [[old_method]] was used instead.
diff --git a/doc/tips/publishing_your_files_to_the_public/comment_1_40f690c59de96159da96855c61bb5963._comment b/doc/tips/publishing_your_files_to_the_public/comment_1_40f690c59de96159da96855c61bb5963._comment
new file mode 100644
index 0000000000..ba405bbe0b
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/comment_1_40f690c59de96159da96855c61bb5963._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="jajpater"
+ avatar="http://cdn.libravatar.org/avatar/17a62a7410a3ea7d62715efced72158e"
+ subject="Problem with publishing subdir. Subdir does not exist, but it does."
+ date="2017-10-20T09:21:33Z"
+ content="""
+When trying this, I get the following error. 
+
+    git annex export master:subdir -t box.com   
+    fatal: Path 'subdir:' does not exist in 'master'
+    git-annex: unknown tree
+
+I really don't get it, since as far as I can see the subdir actually does exist in master
+"""]]
diff --git a/doc/tips/publishing_your_files_to_the_public/comment_2_0287fd56eea34fcd5831768252335a7b._comment b/doc/tips/publishing_your_files_to_the_public/comment_2_0287fd56eea34fcd5831768252335a7b._comment
new file mode 100644
index 0000000000..41c9ec54a5
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/comment_2_0287fd56eea34fcd5831768252335a7b._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="jajpater"
+ avatar="http://cdn.libravatar.org/avatar/17a62a7410a3ea7d62715efced72158e"
+ subject="Also fails when using UUID but differently"
+ date="2017-10-20T09:47:24Z"
+ content="""
+I tried to use the dir UUID - found by using 
+
+    git ls-tree origin/master
+
+This however also fails:
+
+    git annex export fd94c0f44ff40b07bcbe58d4c3921c6fb35c7074 -t box.com
+    export box.com file1 (not available) failed
+    export box.com file2 (not available) failed
+    ...
+    export box.com file10 (not available) failed
+    (recording state in git...)
+    git-annex: export: 10 failed
+
+Does anybody know what's wrong?
+
+"""]]
diff --git a/doc/tips/publishing_your_files_to_the_public/comment_3_4ae6d6c5137e5f9b667417c2c77fca85._comment b/doc/tips/publishing_your_files_to_the_public/comment_3_4ae6d6c5137e5f9b667417c2c77fca85._comment
new file mode 100644
index 0000000000..a84bd6cc60
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/comment_3_4ae6d6c5137e5f9b667417c2c77fca85._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="jajpater"
+ avatar="http://cdn.libravatar.org/avatar/17a62a7410a3ea7d62715efced72158e"
+ subject="Works when first using git annex get"
+ date="2017-10-20T09:59:29Z"
+ content="""
+I dropped the files from the local directory. Publishing does work when I first do a
+
+    git annex get *.*
+
+But now my question has changed:
+
+I have a git repository on a server. 
+Is there a possibility to publish/export directly from the server to a special remote?
+So without checking out the files locally?
+
+
+"""]]
diff --git a/doc/tips/publishing_your_files_to_the_public/comment_4_33b50a2de3f1268c875fc388a85c0296._comment b/doc/tips/publishing_your_files_to_the_public/comment_4_33b50a2de3f1268c875fc388a85c0296._comment
new file mode 100644
index 0000000000..f871c5d8f5
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/comment_4_33b50a2de3f1268c875fc388a85c0296._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jajpater"
+ avatar="http://cdn.libravatar.org/avatar/17a62a7410a3ea7d62715efced72158e"
+ subject="Publishing subdir is publishing files but not subdir?"
+ date="2017-10-20T10:22:25Z"
+ content="""
+When using the uuid the files get exported to the root of the specified webdav folder.
+Is there a possibility to keep the directory structure intact, so that the special remote has the same folder structure as has the repository?
+
+Thanks in advance
+"""]]
diff --git a/doc/tips/publishing_your_files_to_the_public/comment_5_3216edeefa99f484194d6de061283170._comment b/doc/tips/publishing_your_files_to_the_public/comment_5_3216edeefa99f484194d6de061283170._comment
new file mode 100644
index 0000000000..3d7d1196eb
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/comment_5_3216edeefa99f484194d6de061283170._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Problem with publishing subdir. Subdir does not exist, but it does."""
+ date="2017-10-30T15:53:33Z"
+ content="""
+I reproduced export of master:subdir not working. It's a bug in git-annex,
+now fixed!
+"""]]
diff --git a/doc/tips/publishing_your_files_to_the_public/comment_6_06cba66922cc382c112fdac52b98bb4d._comment b/doc/tips/publishing_your_files_to_the_public/comment_6_06cba66922cc382c112fdac52b98bb4d._comment
new file mode 100644
index 0000000000..118865da05
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/comment_6_06cba66922cc382c112fdac52b98bb4d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2017-10-30T16:04:24Z"
+ content="""
+You should be able to run `git annex export` in the bare git repository on
+your server. It just needs the branch you want to export to be known to
+git, and the annexed file contents to be available there.
+"""]]
diff --git a/doc/tips/publishing_your_files_to_the_public/comment_7_caf9ad71e3805347df98f4d6df352cec._comment b/doc/tips/publishing_your_files_to_the_public/comment_7_caf9ad71e3805347df98f4d6df352cec._comment
new file mode 100644
index 0000000000..37149d4ebf
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/comment_7_caf9ad71e3805347df98f4d6df352cec._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Publishing subdir is publishing files but not subdir?"""
+ date="2017-10-30T16:06:36Z"
+ content="""
+The reason exporting a subdir puts the files at the root of the folder
+is that it's exporting a git tree, and files in the tree of a subdir
+are relative to that subdir.
+
+It's certianly possible to make git construct a tree object that
+contains a subdirectory containing the files you want to export, and
+then exporting that tree object would replicate that tree structure,
+including the subdir. One way is to check out a branch, delete the files
+you don't want to export and once things are arranged as you like,
+commit to that branch and then export it.
+
+(Or you could just make the webdav special remote's url include the
+subdir where you wanrt it to export stuff.)
+"""]]
diff --git a/doc/tips/publishing_your_files_to_the_public/old_method.mdwn b/doc/tips/publishing_your_files_to_the_public/old_method.mdwn
new file mode 100644
index 0000000000..fe304cda24
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/old_method.mdwn
@@ -0,0 +1,88 @@
+# Creating a special S3 remote to hold files shareable by URL
+
+(In this example, I'll assume you'll be creating a bucket in S3 named **public-annex** and a special remote in git-annex, which will store its files in the previous bucket, named **public-s3**, but change these names if you are going to do the thing for real)
+
+Set up your special [S3](http://git-annex.branchable.com/special_remotes/S3/) remote with (at least) these options:
+
+    git annex initremote public-s3 type=s3 encryption=none bucket=public-annex chunk=0 public=yes
+
+This way git-annex will upload the files to this repo, (when you call `git
+annex copy [FILES...] --to public-s3`) without encrypting them and without
+chunking them. And, thanks to the public=yes, they will be
+accessible by anyone with the link.
+
+(Note that public=yes was added in git-annex version 5.20150605.
+If you have an older version, it will be silently ignored, and you
+will instead need to use the AWS dashboard to configure a public get policy
+for the bucket.)
+
+Following the example, the files will be accessible at `http://public-annex.s3.amazonaws.com/KEY` where `KEY` is the file key created by git-annex and which you can discover running
+
+    git annex lookupkey FILEPATH
+
+This way you can share a link to each file you have at your S3 remote.
+
+## Sharing all links in a folder
+
+To share all the links in a given folder, for example, you can go to that folder and run (this is an example with the _fish_ shell, but I'm sure you can do the same in _bash_, I just don't know exactly):
+
+    for filename in (ls)
+        echo $filename": https://public-annex.s3.amazonaws.com/"(git annex lookupkey $filename)
+    end
+
+## Sharing all links matching certain metadata
+
+The same applies to all the filters you can do with git-annex.
+
+For example, let's share links to all the files whose _author_'s name starts with "Mario" and are, in fact, stored at your public-s3 remote.
+However, instead of just a list of links we will output a markdown-formatted list of the filenames linked to their S3 urls:
+
+    for filename in (git annex find --metadata "author=Mario*" --and --in public-s3)
+       echo "* ["$filename"](https://public-annex.s3.amazonaws.com/"(git annex lookupkey $filename)")"
+    end
+
+Very useful.
+
+## Sharing links with time-limited URLs
+
+By using pre-signed URLs it is possible to create limits on how long a URL is valid for retrieving an object. 
+To enable use a private S3 bucket for the remotes and then pre-sign actual URL with the script in [AWS-Tools](https://github.com/gdbtek/aws-tools).
+Example:
+
+    key=`git annex lookupkey "$fname"`;  sign_s3_url.bash --region 'eu-west-1' --bucket 'mybuck' --file-path $key --aws-access-key-id XX --aws-secret-access-key XX --method 'GET' --minute-expire 10
+
+## Adding the S3 URL as a source
+
+Assuming all files in the current directory are available on S3, this will register the public S3 url for the file in git-annex, making it available for everyone *through git-annex*:
+
+<pre>
+git annex find --in public-s3 | while read file ; do
+  key=$(git annex lookupkey $file)
+  echo $key https://public-annex.s3.amazonaws.com/$key
+done | git annex registerurl
+</pre>
+
+`registerurl` was introduced in `5.20150317`.
+
+## Manually configuring a public get policy
+
+Here is how to manually configure a public get policy
+for a bucket, in the AWS dashboard.
+
+    {
+      "Version": "2008-10-17",
+      "Statement": [
+        {
+          "Sid": "AllowPublicRead",
+          "Effect": "Allow",
+          "Principal": {
+            "AWS": "*"
+          },
+          "Action": "s3:GetObject",
+          "Resource": "arn:aws:s3:::public-annex/*"
+        }
+      ]
+    }
+
+This should not be necessary if using a new enough version
+of git-annex, which can instead be configured with public=yes.
diff --git a/doc/tips/publishing_your_files_to_the_public/old_method/comment_1_48f545ce26dbec944f96796ed3b9204d._comment b/doc/tips/publishing_your_files_to_the_public/old_method/comment_1_48f545ce26dbec944f96796ed3b9204d._comment
new file mode 100644
index 0000000000..6ee85367e8
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/old_method/comment_1_48f545ce26dbec944f96796ed3b9204d._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""nice tip"""
+ date="2014-12-01T22:59:58Z"
+ content="""
+Thanks Giovanni for that nice tip!
+
+You can additionally publish the whole git repository
+by eg pushing it to github. (Not if it contains private files
+or if you have embedded encryption keys or credentials though.)
+
+You can tell git-annex the public url for the files too, and then others
+can just clone the git repository and use git-annex to download the files
+from S3.
+
+You could set that up by running something like this:
+
+	for filename in $(git annex find --in public-s3); do
+		git annex addurl --file "$filename" https://public-annex.s3.amazonaws.com/"$(git annex lookupkey $filename)"
+	done
+"""]]
diff --git a/doc/tips/publishing_your_files_to_the_public/old_method/comment_2_27a40806d009d617b3ad56873197bf87._comment b/doc/tips/publishing_your_files_to_the_public/old_method/comment_2_27a40806d009d617b3ad56873197bf87._comment
new file mode 100644
index 0000000000..9cca4e2fa8
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/old_method/comment_2_27a40806d009d617b3ad56873197bf87._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="BojanNikolic"
+ subject="Publishing using rsync/directory layout"
+ date="2015-02-16T10:04:41Z"
+ content="""
+Is it possible to easily do the same with rsync/directory layout of the special remote? These have prefixes which are not shown when doing git annex lookupkey
+"""]]
diff --git a/doc/tips/publishing_your_files_to_the_public/old_method/comment_3_2f5045629e40e8d881725876190c7846._comment b/doc/tips/publishing_your_files_to_the_public/old_method/comment_3_2f5045629e40e8d881725876190c7846._comment
new file mode 100644
index 0000000000..c76d3a30c5
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/old_method/comment_3_2f5045629e40e8d881725876190c7846._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-02-25T19:44:40Z"
+ content="""
+You can look up the hash directories for a key using:
+
+git annex examinekey $key --format '${hashdirlower}\n'
+"""]]
diff --git a/doc/tips/publishing_your_files_to_the_public/old_method/comment_4_37405f20da790141187e9f780c999448._comment b/doc/tips/publishing_your_files_to_the_public/old_method/comment_4_37405f20da790141187e9f780c999448._comment
new file mode 100644
index 0000000000..2855c3fddf
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/old_method/comment_4_37405f20da790141187e9f780c999448._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="BojanNikolic"
+ subject="comment 4"
+ date="2015-02-27T09:55:15Z"
+ content="""
+Many thanks. The command line I ended up using is:
+
+    fname=\"2015/01/04/myfile.pdf\" ;  git annex copy --to pubweb $fname; key=`git annex lookupkey \"$fname\"`;  git annex examinekey $key --format 'https://www.myweb.com/d/${hashdirlower}${key}/${key}\n'
+
+to publish selected documents in my git-annex repository onto the web via a rsync special remote on a conventional http server. 
+"""]]
diff --git a/doc/tips/publishing_your_files_to_the_public/old_method/comment_5_29c3ee4aed6a5b53b6767a96a7b85ad9._comment b/doc/tips/publishing_your_files_to_the_public/old_method/comment_5_29c3ee4aed6a5b53b6767a96a7b85ad9._comment
new file mode 100644
index 0000000000..bd77d03ce2
--- /dev/null
+++ b/doc/tips/publishing_your_files_to_the_public/old_method/comment_5_29c3ee4aed6a5b53b6767a96a7b85ad9._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 5"
+ date="2015-05-27T21:50:10Z"
+ content="""
+[registerurl](http://source.git-annex.branchable.com/?p=source.git;a=blobdiff;f=doc/git-annex.mdwn;h=c33633e03378b0125a3feb5d1a9fa61ce9bfa9cc;hp=3af9bbb8c1d2e84506f3db80ad7253a7cd8de1d4;hb=abfe3c09b2caac0827a2196076c9bd9185451b9f;hpb=b24bb6b435ddc91510163c7b22db2ba52703724c) may provide a faster version of the above. i've also creted a [[feature request|todo/credentials-less_access_to_s3]] to make this easier with s3 (so that we don't have to setup urls for each individual file). --[[anarcat]]
+"""]]
diff --git a/doc/tips/recover_data_from_lost+found.mdwn b/doc/tips/recover_data_from_lost+found.mdwn
new file mode 100644
index 0000000000..0e7391a7fb
--- /dev/null
+++ b/doc/tips/recover_data_from_lost+found.mdwn
@@ -0,0 +1,18 @@
+Suppose something goes wrong, and fsck puts all the files in lost+found.
+It's actually very easy to recover from this disaster.
+
+First, check out the git repository again. Then, in the new checkout:
+
+	$ mkdir recovered-content
+	$ sudo mv ../lost+found/* recovered-content
+	$ sudo chown you:you recovered-content
+	$ chmod -R u+w recovered-content
+	$ git annex add recovered-content
+	$ git reset HEAD recovered-content
+	$ rm -rf recovered-content
+	$ git annex fsck
+
+The way that works is that when git-annex adds the same content that was in
+the repository before, all the old links to that content start working
+again. So, this works as long as you're using one of the SHA* or other
+checksumming backends, which is the default.
diff --git a/doc/tips/recover_data_from_lost+found/comment_1_f0901527a4f0faf0b1fd916d5b809314._comment b/doc/tips/recover_data_from_lost+found/comment_1_f0901527a4f0faf0b1fd916d5b809314._comment
new file mode 100644
index 0000000000..f609d8def9
--- /dev/null
+++ b/doc/tips/recover_data_from_lost+found/comment_1_f0901527a4f0faf0b1fd916d5b809314._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmWBvsZvSsAL8P2ye3F0OBStjFCVnOImzM"
+ nickname="Jarno"
+ subject="Why fsck?"
+ date="2014-01-02T22:09:03Z"
+ content="""
+Other steps I understand but what is the purpose of the last, \"git annex fsck\"?
+Shouldn't \"git annex add\" recreate any missing annex files and therefore fix dangling symlinks?
+"""]]
diff --git a/doc/tips/recover_data_from_lost+found/comment_2_ac405575058beeac992d07c55f7c53a8._comment b/doc/tips/recover_data_from_lost+found/comment_2_ac405575058beeac992d07c55f7c53a8._comment
new file mode 100644
index 0000000000..f1afdca495
--- /dev/null
+++ b/doc/tips/recover_data_from_lost+found/comment_2_ac405575058beeac992d07c55f7c53a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.35"
+ subject="comment 2"
+ date="2014-01-03T21:19:39Z"
+ content="""
+The `git annex fsck` at the end will verify if you've managed to recover all the files.
+"""]]
diff --git a/doc/tips/recover_data_from_lost+found/comment_3_02cb9efd54d8447d0bd11e5981e7dca7._comment b/doc/tips/recover_data_from_lost+found/comment_3_02cb9efd54d8447d0bd11e5981e7dca7._comment
new file mode 100644
index 0000000000..7121f380ca
--- /dev/null
+++ b/doc/tips/recover_data_from_lost+found/comment_3_02cb9efd54d8447d0bd11e5981e7dca7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="atrent"
+ subject="comment 3"
+ date="2015-11-16T09:06:34Z"
+ content="""
+This procedure is also very useful when you accidentally rename files in the object dir.
+
+Such a case occurred to me when I 'detoxed' a git-annex: detox renames files and it substitutes \"--\" with \"-\", thus destroying my annex.
+
+I find git-annex very elegant in this situation: rather than trying to rename back the files (objects) you just re-add them (since content is still there unmodified) recreating the symlink targets!
+
+Kudos!
+"""]]
diff --git a/doc/tips/recover_data_from_lost+found/comment_4_960fcfe8c5c7bcb7350f61ecfb84f36c._comment b/doc/tips/recover_data_from_lost+found/comment_4_960fcfe8c5c7bcb7350f61ecfb84f36c._comment
new file mode 100644
index 0000000000..3c2105e024
--- /dev/null
+++ b/doc/tips/recover_data_from_lost+found/comment_4_960fcfe8c5c7bcb7350f61ecfb84f36c._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Isn't this procedure assuming that lost+found contains only uncorrupted previously annexed files?"
+ date="2017-03-14T19:15:40Z"
+ content="""
+    git annex add recovered-content
+
+lost+found does not contain only annexed file, right? It may contain any kind of file not originally annexed.
+
+Examples:
+
+* a file that was imported in the regular git part of the git annex repository
+* a corrupted variant of an annexed file
+* a git pack, a git index or any git administrative file
+* a file totally unrelated that happened to be on the same filesystem.
+
+In all these cases, this command will result in new additions to the annex.
+
+This is not what a recovery should do, is it?
+
+Shouldn't that become rather something like:
+
+    git annex reinject --known 
+
+"""]]
diff --git a/doc/tips/recover_data_from_lost+found/comment_5_e887b2d2ecbce3de22c517afd500e783._comment b/doc/tips/recover_data_from_lost+found/comment_5_e887b2d2ecbce3de22c517afd500e783._comment
new file mode 100644
index 0000000000..125b470837
--- /dev/null
+++ b/doc/tips/recover_data_from_lost+found/comment_5_e887b2d2ecbce3de22c517afd500e783._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-03-14T23:40:45Z"
+ content="""
+If you're worried about lost+found containing non-annexed content, you can
+copy (`cp`) the files, rather than moving them (`mv`). After adding the
+files, `git annex unused` will find any non-annexed ones that were added,
+and they can then be removed.
+
+This tip was written before `git annex reinject --known` existed, but that
+is also a good way to do it.
+"""]]
diff --git a/doc/tips/recovering_from_a_corrupt_git_repository.mdwn b/doc/tips/recovering_from_a_corrupt_git_repository.mdwn
new file mode 100644
index 0000000000..084f76852e
--- /dev/null
+++ b/doc/tips/recovering_from_a_corrupt_git_repository.mdwn
@@ -0,0 +1,17 @@
+I have found this the most reliable way to recover from a corrupt git repository. I have had a lot of them lately, there might be a regression in btrfs in Ubuntu's Linux 3.8.0-33 (!).
+
+1. Create a clone of a known good repository.
+2. Add the clone as an object alternate to the broken repository.
+3. Do a `git-repack -a -d` to lift the external objects into repo-local packs.
+4. Remove the clone
+
+[[!format sh """
+$ cd /tmp/
+$ git clone good-host:/path/to/good-repo
+$ cd /home/user/broken-repo
+$ echo /tmp/good-repo/.git/objects/ > .git/objects/info/alternates
+$ git repack -a -d
+$ rm -rf /tmp/good-repo
+"""]]
+
+... and push early, push often. ;-)
diff --git a/doc/tips/recovering_from_a_corrupt_git_repository/comment_1_f5827be97f78dbae113a5ba0c9ced896._comment b/doc/tips/recovering_from_a_corrupt_git_repository/comment_1_f5827be97f78dbae113a5ba0c9ced896._comment
new file mode 100644
index 0000000000..d212e23f34
--- /dev/null
+++ b/doc/tips/recovering_from_a_corrupt_git_repository/comment_1_f5827be97f78dbae113a5ba0c9ced896._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 1"
+ date="2013-11-11T16:01:59Z"
+ content="""
+Better, since version 4.20131024, `git annex repair` can be run to automatically do this, and more. (Including recovering data in corrupt git repositories that you forgot to push!)
+"""]]
diff --git a/doc/tips/recovering_from_a_corrupt_git_repository/comment_2_e98df7275bb032308bb87e3607bdde32._comment b/doc/tips/recovering_from_a_corrupt_git_repository/comment_2_e98df7275bb032308bb87e3607bdde32._comment
new file mode 100644
index 0000000000..c018c4ca56
--- /dev/null
+++ b/doc/tips/recovering_from_a_corrupt_git_repository/comment_2_e98df7275bb032308bb87e3607bdde32._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="comment 2"
+ date="2013-11-12T16:14:50Z"
+ content="""
+I am using git-annex 20131106 and I tried `git annex repair` first. It seems git is making assumptions that if I have object A then I must have object B that A depends on. Or maybe it freaks out because the object is not missing, just full of zeroes. I haven't done any analysis on exactly what situation causes this. When I have time, I will.
+"""]]
diff --git a/doc/tips/recovering_from_a_corrupt_git_repository/comment_3_11bece6dfac090edbcd783b266c482a3._comment b/doc/tips/recovering_from_a_corrupt_git_repository/comment_3_11bece6dfac090edbcd783b266c482a3._comment
new file mode 100644
index 0000000000..63f443a31d
--- /dev/null
+++ b/doc/tips/recovering_from_a_corrupt_git_repository/comment_3_11bece6dfac090edbcd783b266c482a3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="comment 3"
+ date="2013-11-12T16:17:42Z"
+ content="""
+Luckily, so far the objects getting corrupted have been in past commits (maybe only in packfiles?), not the latest ones, so I have been able to recover even though HEAD has been unique to the local repo.
+"""]]
diff --git a/doc/tips/recovering_from_a_corrupt_git_repository/comment_4_86e99017f7585ac2f76753051214637e._comment b/doc/tips/recovering_from_a_corrupt_git_repository/comment_4_86e99017f7585ac2f76753051214637e._comment
new file mode 100644
index 0000000000..8d454fc3e4
--- /dev/null
+++ b/doc/tips/recovering_from_a_corrupt_git_repository/comment_4_86e99017f7585ac2f76753051214637e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="comment 4"
+ date="2013-11-12T17:10:06Z"
+ content="""
+Hm. This is bad. My hunch that btrfs was the culprit seems to have been wrong. After having switched things around, along with lots of `git annex sync` in various places, I now have a corrupt repo on ext4. It must be git or git-annex that does something wrong.
+"""]]
diff --git a/doc/tips/recovering_from_a_corrupt_git_repository/comment_6_c8953732ce353cdf0c4fb81ddc98c04a._comment b/doc/tips/recovering_from_a_corrupt_git_repository/comment_6_c8953732ce353cdf0c4fb81ddc98c04a._comment
new file mode 100644
index 0000000000..eeb3ceef23
--- /dev/null
+++ b/doc/tips/recovering_from_a_corrupt_git_repository/comment_6_c8953732ce353cdf0c4fb81ddc98c04a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 6"
+ date="2013-11-12T18:10:21Z"
+ content="""
+If you can reliably corrupt a git repository, it's highly likely your hardware (disk or memory) is broken.
+"""]]
diff --git a/doc/tips/recovering_from_a_corrupt_git_repository/comment_6_d0da84df0241dc6ccf0aa0c7598917df._comment b/doc/tips/recovering_from_a_corrupt_git_repository/comment_6_d0da84df0241dc6ccf0aa0c7598917df._comment
new file mode 100644
index 0000000000..16b2329b98
--- /dev/null
+++ b/doc/tips/recovering_from_a_corrupt_git_repository/comment_6_d0da84df0241dc6ccf0aa0c7598917df._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="comment 6"
+ date="2013-11-12T17:22:01Z"
+ content="""
+This is my symptom too: [[forum/Git annex 'corrupting' itself]]
+"""]]
diff --git a/doc/tips/recovering_from_a_corrupt_git_repository/comment_7_addf49556e4c33d55a41c393f519d0a4._comment b/doc/tips/recovering_from_a_corrupt_git_repository/comment_7_addf49556e4c33d55a41c393f519d0a4._comment
new file mode 100644
index 0000000000..5047bcca48
--- /dev/null
+++ b/doc/tips/recovering_from_a_corrupt_git_repository/comment_7_addf49556e4c33d55a41c393f519d0a4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 7"
+ date="2013-11-12T18:12:49Z"
+ content="""
+> I tried git annex repair first. It seems git is making assumptions that if I have object A then I must have object B that A depends on. Or maybe it freaks out because the object is not missing
+
+`git annex repair` is supposed to deal with these situations. If it fails to fix such a broken repository, please file a detailed bug report, ideally with a link to a copy of the repository.
+"""]]
diff --git a/doc/tips/recovering_from_a_corrupt_git_repository/comment_8_505a2fc2b841fe8eb419801f923ef35f._comment b/doc/tips/recovering_from_a_corrupt_git_repository/comment_8_505a2fc2b841fe8eb419801f923ef35f._comment
new file mode 100644
index 0000000000..78144b8938
--- /dev/null
+++ b/doc/tips/recovering_from_a_corrupt_git_repository/comment_8_505a2fc2b841fe8eb419801f923ef35f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="comment 8"
+ date="2013-11-14T10:00:20Z"
+ content="""
+Several machines started showing this behavior around 4.20131106 or 4.20131101. I will find a way to reproduce when I can find the time.
+"""]]
diff --git a/doc/tips/redacting_history_by_converting_git_files_to_annexed.mdwn b/doc/tips/redacting_history_by_converting_git_files_to_annexed.mdwn
new file mode 100644
index 0000000000..5eca035138
--- /dev/null
+++ b/doc/tips/redacting_history_by_converting_git_files_to_annexed.mdwn
@@ -0,0 +1,53 @@
+git-annex can be used to let people clone a repository, without being
+able to access the content of annexed files whose content you want to keep
+private.
+
+But what to do if you're using a repository like that, and accidentially
+add a file to git that you intended to keep private? And you didn't notice
+for a while and made other changes.
+
+Here's a way to recover from that mistake without throwing away the commits
+you made. It creates a separate, redacted history where the private
+file (`$privatefile`) is an annexed file. And uses `git replace` to let you
+locally keep using the unredacted history.
+
+Start by identifiying the parent commit of the commit that added the
+private file to git (`$lastsafecommit`).
+
+Reset back to `$lastsafecommit` and squash in all changes made since then:
+
+    git branch unredacted-master master
+    git reset --hard $lastsafecommit
+    git merge --squash unredacted-master
+
+Then convert `$privatefile` to an annexed file:
+
+    git rm --cached $privatefile
+    git annex add --force-large $privatefile
+
+Commit the redacted version of master, and locally replace it with your
+original unredacted history.
+
+    git commit
+    git replace master unredacted-master
+
+Now you can push master to other remotes, and it will push the redacted
+form of master:
+
+    git push --force origin master
+
+(Note that, if you already pushed the unredacted commits to origin, this
+push will not necessarily completely delete the private content from it.
+Making a new origin repo and pushing to that is an easy way to be sure.)
+
+If you do want to share the unredacted history with any other repositories,
+you can, by fetching the replacement refs into them:
+
+    git fetch myhost:myrepo 'refs/replace/*'
+    git fetch myhost:myrepo unredacted-master
+    git replace master unredacted-master
+
+Note that the above example makes the redacted history contain a single
+squashed commit, but this technique is not limited to that. You can make
+redacted versions of individual commits too, and build up whatever form of
+redacted history you want to publish.
diff --git a/doc/tips/redacting_history_by_converting_git_files_to_annexed/comment_1_aece062800c6ed78988161d40e36bba4._comment b/doc/tips/redacting_history_by_converting_git_files_to_annexed/comment_1_aece062800c6ed78988161d40e36bba4._comment
new file mode 100644
index 0000000000..e8af23f4c9
--- /dev/null
+++ b/doc/tips/redacting_history_by_converting_git_files_to_annexed/comment_1_aece062800c6ed78988161d40e36bba4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2024-02-11T18:54:45Z"
+ content="""
+Thank you!  In my case, since safe commit is too far in the past, what I had in mind is a little different: I wanted to have a completely disconnected history with a commit which had `$privatefile`s moved to annex, but I think the approach is \"the same\" in effect.
+The only thing I would do differently is to first convert files to git-annex in `master` (to become `unredacted-master`), so I end up with the same tree in `unredacted-master` and `master` happen that later I would need to cherry-pick some changes accidentally committed (e.g. by collaborators) on top of `unredacted-master`.
+
+Another note worthwhile making IMHO is that AFAIK those `git replace` markers are local only, and whoever has unredacted-master later on might need to set them up as well for their local clones to make such a \"collapse\" of histories.
+"""]]
diff --git a/doc/tips/redacting_history_by_converting_git_files_to_annexed/comment_2_6b682415956756b969767f7de267f1f0._comment b/doc/tips/redacting_history_by_converting_git_files_to_annexed/comment_2_6b682415956756b969767f7de267f1f0._comment
new file mode 100644
index 0000000000..081ca287dc
--- /dev/null
+++ b/doc/tips/redacting_history_by_converting_git_files_to_annexed/comment_2_6b682415956756b969767f7de267f1f0._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2024-02-12T17:01:13Z"
+ content="""
+> Another note worthwhile making IMHO is that AFAIK those `git replace` markers
+> are local only, and whoever has unredacted-master later on might need to set
+> them up as well for their local clones to make such a \"collapse\" of histories
+
+Right, any repository you fetch unredacted-master into, you will also want to 
+fetch refs/redacted/ to as well, and run git replace there, as shown in the last
+code block of the tip above.
+"""]]
diff --git a/doc/tips/redacting_history_by_converting_git_files_to_annexed/comment_3_7e92db3d8a392e43b305fa8ecc0e39d3._comment b/doc/tips/redacting_history_by_converting_git_files_to_annexed/comment_3_7e92db3d8a392e43b305fa8ecc0e39d3._comment
new file mode 100644
index 0000000000..404146779a
--- /dev/null
+++ b/doc/tips/redacting_history_by_converting_git_files_to_annexed/comment_3_7e92db3d8a392e43b305fa8ecc0e39d3._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="a script to hide history"
+ date="2024-02-15T22:05:12Z"
+ content="""
+Here is a script I crafted to use to make it easy and reuse current tree object for new \"squashed history\" commit
+
+```bash
+#!/bin/bash
+#
+# A helper to establish an alternative history to hide commits which could have
+# leaked personal data etc.
+#
+# More information on motivation etc and another implementation could be
+# found at https://git-annex.branchable.com/tips/redacting_history_by_converting_git_files_to_annexed/
+#
+
+set -eu
+
+BRANCH=$(git rev-parse --abbrev-ref HEAD)
+: \"${SECRET_BRANCH:=unredacted-$BRANCH}\"
+SAFE_BASE=\"$1\"
+
+git branch \"${SECRET_BRANCH}\"
+
+rm -f .git/COMBINED_COMMIT_MESSAGE
+echo -e \"Combined commits to hide away sensitive data\n\" >> .git/COMBINED_COMMIT_MESSAGE
+git log --format=%B \"$SAFE_BASE..HEAD\" >> .git/COMBINED_COMMIT_MESSAGE
+
+# the tree we are on ATM
+TREE_HASH=$(git log -1 --format=%T HEAD)
+NEW_COMMIT=$(git commit-tree $TREE_HASH -p \"$SAFE_BASE\" -F .git/COMBINED_COMMIT_MESSAGE)
+rm -f .git/COMBINED_COMMIT_MESSAGE
+git reset --hard $NEW_COMMIT
+
+git replace \"$BRANCH\" \"$SECRET_BRANCH\"
+```
+"""]]
diff --git a/doc/tips/remote_webapp_setup.mdwn b/doc/tips/remote_webapp_setup.mdwn
new file mode 100644
index 0000000000..57993df761
--- /dev/null
+++ b/doc/tips/remote_webapp_setup.mdwn
@@ -0,0 +1,49 @@
+Here's the scenario: You have a remote server you can ssh into,
+and you want to use the git-annex webapp there, displaying back on your local
+web browser.
+
+Sure, no problem! It can even be done securely!
+
+Let's start by making the git-annex repository on the remote server.
+
+	git init annex
+	cd annex
+	git annex init
+
+Now, you need to generate a private key and a certificate for HTTPS.
+These files are stored in `.git/annex/privkey.pem` and 
+`.git/annex/certificate.pem` inside the git repository. Here's
+one way to generate those files, using a self-signed certificate:
+
+	(umask 077 ; openssl genrsa -out .git/annex/privkey.pem 4096)
+	openssl req -new -x509 -key .git/annex/privkey.pem > .git/annex/certificate.pem
+
+With those files in place, git-annex will automatically only accept HTTPS
+connections. That's good, since HTTP connections are not secure over the
+big bad internet.
+
+All that remains is to make the webapp listen on the external interface
+of the server. Normally, for security, git-annex only listens on localhost.
+Tell it what hostname to listen on:
+
+	git config annex.listen host.example.com
+
+(If your hostname doesn't work, its IP address certianly will..)
+
+When you run the webapp configured like that, it'll print out the
+URL to use to open it. You can paste that into your web browser.
+
+	git annex webapp
+	http://host.example.com:42232/?auth=ea7857ad...
+
+Notice that the URL has a big jumble of letters at the end -- this is a
+secret token that the webapp uses to verify you're you. So random attackers
+can't find your webapp and do bad things with it.
+
+If you like, you can make the server run `git annex assistant --autostart`
+on boot.
+
+To automate opening the remote server's webapp in your local browser,
+just run this:
+
+	firefox "$(ssh host.example.com git annex webapp)"
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant.mdwn b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant.mdwn
new file mode 100644
index 0000000000..cfe422edbe
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant.mdwn
@@ -0,0 +1,41 @@
+Sparkleshare and dvcs-autosync are tools to automatically commit your
+changes to git and keep them in sync with other repositories. Unlike
+git-annex, they don't store the file content on the side, but directly in
+the git repository. Great for small files, less good for big files.
+
+Here's how to use the [[git-annex assistant|/assistant]] to do the same
+thing, but even better!
+
+----
+
+Let's suppose you're developing a video game, written in C. You have
+source code, and some large game assets. You want to ensure the source
+code is stored in git -- that's what git's for! And you want to store
+the game assets in the git annex -- to avod bloating your git repos with
+possibly enormous files, but still version control them.
+
+All you need to do is configure git-annex to treat your C files
+as small files. And treat any file larger than, say, 100kb as a large
+file that is stored in the annex.
+
+	git config annex.largefiles "largerthan=100kb and not (include=*.c or include=*.h)"
+
+For more details about this configuration, see [[largefiles]].
+
+----
+
+Now if you run `git annex add`, it will only add the large files to the
+annex; small files will be stored in git.
+
+Or, run `git annex assistant`. It will *automatically*
+add the large files to the annex, and store the small files in git.
+It'll notice every time you modify a file, and immediately commit it,
+too. And sync it out to other repositories you configure using `git annex
+webapp`.
+
+----
+
+It's also possible to disable the use of the annex entirely, and just
+have the assistant *always* put every file into git, no matter its size:
+
+	git config annex.largefiles "exclude=*"
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_10_d1bd5d6b33951f6d11185bb4a8228269._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_10_d1bd5d6b33951f6d11185bb4a8228269._comment
new file mode 100644
index 0000000000..b00d961d09
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_10_d1bd5d6b33951f6d11185bb4a8228269._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 10"
+ date="2013-12-12T17:35:28Z"
+ content="""
+The behavior is direct mode is a bug: [[bugs/when syncing a direct repository, git annex delete non annexed new git files]]. Hopefully it will be fixed soon.
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_11_54692ebf854ecbcc5314bb29c33ecc66._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_11_54692ebf854ecbcc5314bb29c33ecc66._comment
new file mode 100644
index 0000000000..cc48eca66e
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_11_54692ebf854ecbcc5314bb29c33ecc66._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 11"
+ date="2013-12-12T19:58:53Z"
+ content="""
+The abovementioned bug is fixed in git, and will be in a release tomorrow.
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_1_907e4032ca4a39adb846cf16dbf447dc._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_1_907e4032ca4a39adb846cf16dbf447dc._comment
new file mode 100644
index 0000000000..b0ff0114a6
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_1_907e4032ca4a39adb846cf16dbf447dc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://hands.com/~phil/"
+ nickname="hands"
+ subject="software from the future?"
+ date="2013-03-31T17:30:34Z"
+ content="""
+I think you probably meant at least version 4.20130323 ;-)
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_2_902d001ba86657ef0f8cca5b175f99ca._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_2_902d001ba86657ef0f8cca5b175f99ca._comment
new file mode 100644
index 0000000000..2367c938d3
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_2_902d001ba86657ef0f8cca5b175f99ca._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-03-31T18:50:35Z"
+ content="""
+I meant 4.20130329
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_3_a1cf93f9b29658f0f26e9e0ae6057ee3._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_3_a1cf93f9b29658f0f26e9e0ae6057ee3._comment
new file mode 100644
index 0000000000..91122360aa
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_3_a1cf93f9b29658f0f26e9e0ae6057ee3._comment
@@ -0,0 +1,60 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
+ nickname="Tobias"
+ subject="Trying this feature"
+ date="2013-04-14T13:04:55Z"
+ content="""
+I just gave this feature a try, but it seems it doesn't work as expected or maybe I don't understand it:
+
+    ~/annex/largefilestest % git init
+    ~/annex/largefilestest (git)-[master] % git annex init \"test repo\"
+    ~/annex/largefilestest (git)-[master] % git config annex.largefiles \"not include=*.txt\"
+
+Now I copy two files to this directory and add both to the annex
+
+    ~/annex/largefilestest (git)-[master] % ll
+    total 100
+    -rw-rw-r-- 1 tobru tobru 93709 Oct 19 16:14 dpkg-get-selections.txt
+    -rw-rw-r-- 1 tobru tobru  7256 Jan  6 15:52 x3400.jpg
+    ~/annex/largefilestest (git)-[master] % git annex add .
+    add x3400.jpg (checksum...) ok
+    (Recording state in git...)
+    ~/annex/largefilestest (git)-[master] % git status
+    # On branch master
+    #
+    # Initial commit
+    #
+    # Changes to be committed:
+    #   (use \"git rm --cached <file>...\" to unstage)
+    #
+    #       new file:   x3400.jpg
+    #
+    # Untracked files:
+    #   (use \"git add <file>...\" to include in what will be committed)
+    #
+    #       dpkg-get-selections.txt
+    ~/annex/largefilestest (git)-[master] % ll
+    total 96
+    -rw-rw-r-- 1 tobru tobru 93709 Oct 19 16:14 dpkg-get-selections.txt
+    lrwxrwxrwx 1 tobru tobru   192 Jan  6 15:52 x3400.jpg -> .git/annex/objects/vf/QX/SHA256E-s7256--60e5b69ade5619e37f7fcaa964626da9c415959d861241aa13e2516fffc2dddf.jpg/SHA256E-s7256--60e5b69ade5619e37f7fcaa964626da9c415959d861241aa13e2516fffc2dddf.jpg
+
+So the picture is added to the annex as expected. But the .txt file is not added to git. Do I have to manually add this to git? And why is the picture seen as new file by git?
+
+The second question could be answered by: \"run git annex sync\". Is this correct? Because after running this command, git does not see this file as a new file anymore:
+
+    ~/annex/largefilestest (git)-[master] % git annex sync
+    commit  
+    [master (root-commit) a0afb14] git-annex automatic sync
+     1 file changed, 1 insertion(+)
+     create mode 120000 x3400.jpg
+    ok
+    git-annex: no branch is checked out
+    ~/annex/largefilestest (git)-[master] % git status
+    # On branch master
+    # Untracked files:
+    #   (use \"git add <file>...\" to include in what will be committed)
+    #
+    #       dpkg-get-selections.txt
+    nothing added to commit but untracked files present (use \"git add\" to track)
+
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_4_e10671908b58c554375787d0f76e2366._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_4_e10671908b58c554375787d0f76e2366._comment
new file mode 100644
index 0000000000..14a9090148
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_4_e10671908b58c554375787d0f76e2366._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-04-14T18:37:50Z"
+ content="""
+Like it says in the tip, `git annex add` will add the large files to git. You can add the small files with `git add`; git-annex won't do that for you. 
+
+To automatically add both sorts of files, you can use the `git annex watch` or `git annex assistant` daemons. The latter also keeps files in sync between repositories automatically.
+
+(Why did the picture show up as a new file in git? Because you hadn't committed it. This is the same as when you `git add` a file;
+it's only staged in the index; `git status` will show it is new until you `git commit`)
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_5_4114380f66b6376c851e93f6876d590b._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_5_4114380f66b6376c851e93f6876d590b._comment
new file mode 100644
index 0000000000..5d638a3b83
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_5_4114380f66b6376c851e93f6876d590b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo"
+ nickname="Tobias"
+ subject="mimetypes"
+ date="2013-05-01T20:37:33Z"
+ content="""
+Does `annex.largefiles` support mimetypes? F.e. `git config annex.largefiles \"not mimetype=text/plain\"`
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_6_6a5d6af107b297afd008b021f73d787b._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_6_6a5d6af107b297afd008b021f73d787b._comment
new file mode 100644
index 0000000000..bd2212ffb7
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_6_6a5d6af107b297afd008b021f73d787b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnPOttrEmm9CQYxzWrmgGN7LXy98gDkrlM"
+ nickname="binet"
+ subject="annex.largefiles and direct mode"
+ date="2013-09-16T22:50:48Z"
+ content="""
+I was wondering if the annex.largefiles feature was compatible with direct mode?
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_7_74d57cf503a86d8f7ace2d769dbb58be._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_7_74d57cf503a86d8f7ace2d769dbb58be._comment
new file mode 100644
index 0000000000..2144b0ec84
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_7_74d57cf503a86d8f7ace2d769dbb58be._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.105"
+ subject="comment 7"
+ date="2013-09-19T18:03:29Z"
+ content="""
+annex.largefiles does not support mime types. I agree it would be a useful addition.
+
+annex.largefiles can be used with direct mode. I would only recommending using it this way using the assistant, which will keep straight which files are which and commit them appropriately. 
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_8_85765c0cfeb5b326c06cf60c98147cbf._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_8_85765c0cfeb5b326c06cf60c98147cbf._comment
new file mode 100644
index 0000000000..466d03e29c
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_8_85765c0cfeb5b326c06cf60c98147cbf._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLdL4zLty4fsfaIXNtPMS5RXs4y8OAk0o"
+ nickname="Marc"
+ subject="Disappearing files"
+ date="2013-12-08T12:16:37Z"
+ content="""
+I've tried this with version 5.20131130, but my files disappear if I modify them on the remote end.
+
+My setup:
+- A local repository, direct mode, client group, annex.largefiles \"exclude=*.txt\"
+- A remote one, also direct mode, backup group, annex.largefiles \"exclude=*.txt\"
+Both are running the assistant.
+
+If I create a .txt file locally, it gets committed and pushed to the remote as described. But, if I then modify that file on the remote end, the file gets deleted from both repositories. Also, if I create a file on the remote end, it's pushed to the local one (according to the log) but it never appears in the directory.
+
+Changing the remote from 'backup' to 'client' group doesn't seem to make any difference.
+
+Is there a 'best practice' on using git-annex like SparkleShare? I mean, syncing changes on all repositories but keeping a history of changes in git.
+
+Thanks!
+"""]]
diff --git a/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_9_082b5d90ffc836e7c86e40b63a75780d._comment b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_9_082b5d90ffc836e7c86e40b63a75780d._comment
new file mode 100644
index 0000000000..3f104e7025
--- /dev/null
+++ b/doc/tips/replacing_Sparkleshare_or_dvcs-autosync_with_the_assistant/comment_9_082b5d90ffc836e7c86e40b63a75780d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmLdL4zLty4fsfaIXNtPMS5RXs4y8OAk0o"
+ nickname="Marc"
+ subject="comment 9"
+ date="2013-12-08T20:41:41Z"
+ content="""
+After further testing, it seems that the setup I wanted works when both repos are set as indirect, instead of direct as comment 7 recommends. With both repos in indirect mode, the changes are propagated correctly and the files not selected by annex.largefiles are kept in git.
+"""]]
diff --git a/doc/tips/semi-synchronized_remotes.mdwn b/doc/tips/semi-synchronized_remotes.mdwn
new file mode 100644
index 0000000000..c91eabf12d
--- /dev/null
+++ b/doc/tips/semi-synchronized_remotes.mdwn
@@ -0,0 +1,138 @@
+In general, git-annex repositories that are "synchronized" (e.g. with
+the [[git-annex-sync]] command, whatever the backend) have a global
+namespace. Repositories will eventually converge to have very exactly
+the same content, generally using git's push/pull/merge
+mechanisms.
+
+What if we do *not* wish to exactly have the same content across all
+repositories, but still want to share some objects?
+
+An example use case here is content (e.g. `.git/annex/objects` blobs)
+sharing, without having to deliberately collaborate over a globally
+consistent set of objects in the `master` branch. Think of a
+decentralized [conference proceedings][] repository where each
+conference could add their own content to a conference-specific
+repository, while at the same time allowing a unified view in another,
+more centralized repository, or allowing users to pick and choose
+which conference they would want content from.
+
+ [conference proceedings]: https://github.com/RichiH/conference_proceedings
+
+While each repository could have its own distinct branch, all
+repositories will see all those branches and this may affect content
+retention, as git-annex may consider files to be "in use" because they
+are on some remote branch, for example. Furthermore, I consider git
+branching to be a rather advanced topic in git usage. While git-annex
+uses those mechanisms (e.g. the `git-annex` and `sync/*` branches),
+those are generally hidden from the user until something goes
+wrong. Therefore I looked into providing a more straightforward
+approach to this problem for my users and myself.
+
+In my use case, I have the following repositories:
+
+* repoA: my own curated media collection
+* repoB: a third-party media collection
+
+I do not wish for my local curated collection (repoA) to be completely
+synchronized with the third-party collection (repoB). This is because
+we may have different tastes and retention policies: while I archive
+everything, there are certain media I am not interested in. On the
+other hand repoB might keep only (say) the last month of media and
+disard older content but have a more varied collection, which only a
+subset is interesting to me. Yet I still want to access some of that
+content!
+
+So I did the following to add the third party repository:
+
+    git remote add repoB example.net:repoB
+    git annex sync --no-push repoB
+    git annex get --from=repoB
+
+This works well: I get the files from repoB locally. Of course, if
+repoB expires some files, this will be impacted locally, but I can
+always revert those choices without conflict, because I do not push
+those back.
+
+The downside of the `--no-push` option in [[git-annex-sync]] is that
+it needs to be made explicit at each invocation of the
+command. Furthermore, this option is not supported by the assistant,
+which will happily sync the master branch to all remotes by default.
+
+An alternative is to manually fetch and merge content:
+
+    git fetch repoB
+    git annex merge repoB
+    git reset HEAD^
+    # revert any possible changes upstream we don't want
+    git commit
+
+Needless to say this quickly becomes quite messy, but it's the amazing
+level of control git and git-annex provides, which obviously comes
+with its price in complexity. Such a method will also be ignored by
+the assistant and further `sync` commands.
+
+To make sure those principles are respected in the assistant or a
+plain `git annex sync` that may mistakenly be ran in that repository,
+I need some special setting. There are the options I considered, in
+[.gitconfig](https://manpages.debian.org/git-config.1.en.html) or [[git-annex]]'s config options:
+
+ * `remote.<name>.annex-ignore=true`: `sync` and `assistant` will not
+   sync *content* to the repository, but explicit `get --from=repoB`
+   will still work.
+ * `remote.<name>.annex-sync=false`: `sync` (and `assistant`?) will
+   not sync the git repository with the remote
+ * `remote.<name>.push=nothing`: git won't push by default, unless
+   branches are explicitly given, which may actually be the case for
+   git-annex, so unlikely to work.
+ * `remote.<name>.pushurl=/dev/null`: will completely disable any push
+   functionality to that remote. any sync will yield the following
+   error:
+   
+       fatal: '/dev/null' does not appear to be a git repository
+       [...]
+       git-annex: sync: 1 failed
+
+ * `remote.<name>.pushurl=.`: will push to the local repo
+   instead. crude hack and may confuse the hell out of git-annex, but
+   at least doesn't yield errors.
+
+A similar approach to hacking the `pushurl` is to make `repoB`
+read-only to the user. This however, may trigger the activation of
+`annex-ignore` by git-annex and will otherwise yield the same warnings
+as the `pushurl=/dev/null` hack.
+
+Right now, I am using `annex-sync = false` in `.git/config`. I have
+also configured the repository to be in the "manual" [[standard
+group|preferred_content/standard_groups]] which will avoid copying
+files into that repository:
+
+    $ git annex group repoB manual
+    group repoB ok
+    (recording state in git...)
+    $ git annex wanted repoB standard
+    wanted repoB ok
+    (recording state in git...)
+
+This is roughly equivalent to setting `annex-ignore = true`, yet it
+allows for more flexibility. I could, for example, create custom
+content expressions to sync certain folders automatically.
+
+A disadvantage of the `annex-sync` settings is that it affects both
+ways (push and pull), not just push, which is what I am interested
+in. Although it could be argued that restricting both is fine here
+because we want to manually review changes when we pull changes from
+those remotes anyways.
+
+The best approach may be to have git-annex respect the
+`remote.<name>.push=nothing` setting. Another approach would be to add
+`remote.<name>.annex-push` and `remote.<name>.annex-pull` settings
+that would match the `sync --[no-]push --[no-]pull` flags.
+
+Note that this is similar in concept to
+[[todo/Bittorrent-like_features]], although here we assumes you
+already have some transport to share anything you need, yet still have
+to address the question of semi-synchronized git repositories in some
+way.
+
+I would obviously welcome additional comments and questions on this
+approach. -- [[anarcat]]
diff --git a/doc/tips/semi-synchronized_remotes/comment_1_d0459d72b7e0441fe833a5c8e1588a4f._comment b/doc/tips/semi-synchronized_remotes/comment_1_d0459d72b7e0441fe833a5c8e1588a4f._comment
new file mode 100644
index 0000000000..0a6aeb9d68
--- /dev/null
+++ b/doc/tips/semi-synchronized_remotes/comment_1_d0459d72b7e0441fe833a5c8e1588a4f._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-05T16:11:57Z"
+ content="""
+Setting `remote.<name>.annex-readonly=true` prevents git-annex sync
+from pushing changes to the remote. It also prevents any git-annex command
+from copying annexed file contents to the remote, or deleting annexed file
+contents. So I think it's ideal for this kind of situation.
+
+There does seem to be room for configs to prevent sync from pulling/pushing
+without making the remote fully readonly. For example, the remote might be
+a source of content, that only knows about the files it added and not other
+files in the local repository, so dropping files from it should be allowed
+but not pushing to it.
+
+So, I've added `remote.<name>.annex-push` and
+`remote.<name>.annex-pull`.
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site.mdwn b/doc/tips/setup_a_public_repository_on_a_web_site.mdwn
new file mode 100644
index 0000000000..e8cfd8f978
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site.mdwn
@@ -0,0 +1,31 @@
+Let's say you want to distribute some big files to the whole world.
+You can of course, just drop them onto a website. But perhaps you'd like to
+use git-annex to manage those files. And as an added bonus, why not let
+anyone in the world clone your site and use `git-annex get`!
+
+My site like this is [downloads.kitenet.net](https://downloads.kitenet.net).
+Here's how I set it up. --[[Joey]]
+
+1. Set up a web site. I used Apache, and configured it to follow symlinks.
+   `Options FollowSymLinks`
+2. Put some files on the website. Make sure it works.
+3. `git init; git annex init`
+4. `git config core.sharedrepository world` (Makes sure files
+   are always added with permissions that allow everyone to read them.)
+5. `git config receive.denyCurrentBranch updateInstead` (Makes the
+   [[working tree update when changes are pushed to it|making_a_remote_repo_update_when_changes_are_pushed_to_it]].)
+6. We want users to be able to clone the git repository over http, because
+   git-annex can download files from it over http as well. For this to
+   work, `git update-server-info` needs to get run on the server after
+   commits or pushes to it. The git `post-update` hook will take care of
+   this, you just need to enable the hook on the server.
+   `mv .git/hooks/post-update.sample .git/hooks/post-update`
+7. `git annex add; git commit -m added`
+8. Make sure users can still download files from the site directly.
+9. Instruct advanced users to clone a http url that ends with the "/.git/"
+   directory. For example, for downloads.kitenet.net, the clone url
+   is `https://downloads.kitenet.net/.git/`
+
+When users clone over http, and run git-annex, it will
+automatically learn all about your repository and be able to download files
+right out of it, also using http. 
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_10_5554d52c568fdd5235c498ba999545cb._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_10_5554d52c568fdd5235c498ba999545cb._comment
new file mode 100644
index 0000000000..ef2a0f6d89
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_10_5554d52c568fdd5235c498ba999545cb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 10"
+ date="2021-03-23T07:19:39Z"
+ content="""
+I got it. If the server is on a local network, you have to set `annex.security.allowed-ip-addresses` to allow access.
+
+@joey
+Is this intentional for this remote type? If it is, a better error message would be helpful.
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_11_5fc7b153f1822c8ae2d415963fcb9ce2._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_11_5fc7b153f1822c8ae2d415963fcb9ce2._comment
new file mode 100644
index 0000000000..c2bd3052eb
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_11_5fc7b153f1822c8ae2d415963fcb9ce2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2021-03-23T15:49:51Z"
+ content="""
+Filed a bug: [[bugs/http_remote_on_local_network_bad_error_message]]
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_12_eb732e9c1c44942bc313aa1ab3ff56fc._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_12_eb732e9c1c44942bc313aa1ab3ff56fc._comment
new file mode 100644
index 0000000000..1ff98f9616
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_12_eb732e9c1c44942bc313aa1ab3ff56fc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="tomdhunt"
+ avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
+ subject="comment 12"
+ date="2021-03-23T22:59:04Z"
+ content="""
+Okay, setting allowed-ip-addresses worked fine. Thanks much.
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_13_4332e21dcbe4fdcbab58f01aca295fc9._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_13_4332e21dcbe4fdcbab58f01aca295fc9._comment
new file mode 100644
index 0000000000..9853ca04dc
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_13_4332e21dcbe4fdcbab58f01aca295fc9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="comment 13"
+ date="2022-09-07T23:22:40Z"
+ content="""
+`chmod +x .git/hooks/post-update` is out of date; on modern git, the right command is `mv .git/hooks/post-update.sample .git/hooks/post-update`
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_1_1d0fa6da33e401df1d7ff31979247fec._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_1_1d0fa6da33e401df1d7ff31979247fec._comment
new file mode 100644
index 0000000000..cc0a0f2b33
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_1_1d0fa6da33e401df1d7ff31979247fec._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnYLUTs4jFpBPwOlIIJ6qD8xdqZPboJafM"
+ nickname="Oluf"
+ subject="Combine this with a 'public' repository-group"
+ date="2013-07-16T09:44:26Z"
+ content="""
+Hi,
+
+would it be possible to do this whith the contents of a public repository-group (a non-bare public repository)?
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_2_b98b761dee9d923153e3c288c1d987ee._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_2_b98b761dee9d923153e3c288c1d987ee._comment
new file mode 100644
index 0000000000..7bfb89b36a
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_2_b98b761dee9d923153e3c288c1d987ee._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.90"
+ subject="comment 2"
+ date="2013-07-16T17:54:28Z"
+ content="""
+You can choose which files get stored in the public repository, and are thus accessible to the public.
+However, note that since the git repository is published, anyone could clone it and see all the names and hashes of your files, even if you've not pushed the file contents to the public repository.
+
+Currently the way the \"public\" [[repository group|preferred_content]] works only makes it be usable with special remotes. This is because it uses a `preferreddir` setting in the special remote configuration.
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_3_a6698218f15c598c9b32e0af850133bf._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_3_a6698218f15c598c9b32e0af850133bf._comment
new file mode 100644
index 0000000000..05894c73e9
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_3_a6698218f15c598c9b32e0af850133bf._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnRRUUZo3W7pAoRoST8P_l0PtUBhvYuzDg"
+ nickname="Lyle"
+ subject="web storage"
+ date="2014-01-17T22:59:27Z"
+ content="""
+Is there a low cost web hosting solution that would support a public git-annex repo relatively simply with simple access to download the public files. 
+
+I figure I could set up an Amazon EC2 micro instance and mount an s3 share, hosting the git-annex remote, but this is a lot of overhead for something that dropbox does with 1 click \"share dropbox link\"?
+
+Any suggestions would be great!
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_4_e20ea0dc04d4d62b699271483f81a136._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_4_e20ea0dc04d4d62b699271483f81a136._comment
new file mode 100644
index 0000000000..8559a57001
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_4_e20ea0dc04d4d62b699271483f81a136._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-09-17T13:31:34Z"
+ content="""
+For those not wanting to run their own web server, using Amazon S3 with
+git-annex can work well; it can be configured to let the public download
+files over http. See [[public_Amazon_S3_remote]].
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_5_0bb7c62b71d2c9da6fbfe8f889baff38._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_5_0bb7c62b71d2c9da6fbfe8f889baff38._comment
new file mode 100644
index 0000000000..a86565f544
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_5_0bb7c62b71d2c9da6fbfe8f889baff38._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="tomdhunt"
+ avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
+ subject="comment 5"
+ date="2021-03-21T01:11:27Z"
+ content="""
+I'm trying to set up a read-only HTTP mirror of my repository, such that I can clone and get files but not upload anything. I've set up an HTTP file server pointing to the repository, and I can clone it over git (dumb protocol):
+
+```
+$ git clone http://server.name/annex/.git clone_test
+Cloning into 'clone_test'...              
+Fetching objects: 1987364, done.
+Checking connectivity: 1987364, done.
+Updating files: 100% (551410/551410), done.
+```
+
+However, git-annex doesn't seem to like it:
+
+```
+$ cd clone_test/
+$ git annex init
+init  (merging origin/git-annex into git-annex...)
+(recording state in git...)       
+(scanning for unlocked files...)      
+                                                           
+  Remote origin not usable by git-annex; setting annex-ignore
+ok
+(recording state in git...)
+```
+
+And thereafter I can't get any of the files using `git annex get`:
+
+```
+$ git annex get file.name
+get file.name (not available)
+  Maybe add some of these git remotes (git remote add ...):
+    (...)
+  (Note that these git remotes have annex-ignore set: origin)
+failed                                           
+git-annex: get: 1 failed                  
+$ git annex get file.name --from=origin
+git-annex: cannot determine uuid for origin (perhaps you need to run \"git annex sync\"?) (remote.origin.annex-ignore is set)
+```
+
+Running `git annex sync` fails for inability to push to origin, which is as expected since it's meant to be read-only.
+
+How can I get git-annex to fetch data over this http remote?
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_6_89eac454cfbdffabb916355b355e1b94._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_6_89eac454cfbdffabb916355b355e1b94._comment
new file mode 100644
index 0000000000..ac9c6b9e90
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_6_89eac454cfbdffabb916355b355e1b94._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 6"
+ date="2021-03-21T08:11:00Z"
+ content="""
+Did you actually run `git annex init` on the remote which is exposed as http? And `http://server.name/annex/.git/config` needs to be accessible too.
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_7_6015b7ad6a19f412d0b50bfb3a661fe2._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_7_6015b7ad6a19f412d0b50bfb3a661fe2._comment
new file mode 100644
index 0000000000..0b3531bc09
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_7_6015b7ad6a19f412d0b50bfb3a661fe2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="tomdhunt"
+ avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
+ subject="comment 7"
+ date="2021-03-21T17:10:41Z"
+ content="""
+Yes, the HTTP-exposed repo is my main repository copy, which has been initialized and is where I do most of my git-annex operations. And yes, the .git/config file is visible over HTTP.
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_8_ceb528ff60b9c7544eae28292ef74ddb._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_8_ceb528ff60b9c7544eae28292ef74ddb._comment
new file mode 100644
index 0000000000..8c5b8fd3bd
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_8_ceb528ff60b9c7544eae28292ef74ddb._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2021-03-22T14:39:06Z"
+ content="""
+@tomdhunt a few problems could result in this error message.
+
+1. The .git/config file might not be readable by the web server, or some
+   similar problem might cause the web server to fail to serve it.
+   Just for example, a web server might be configured to not serve .git
+   directories, since exposing them can sometimes be a mistake.
+   The web server would have to fail with some problem other than a
+   404 not found.. in that case there would be no error message.
+
+2. git might somehow be failing to parse the .git/config file once it is
+   downloaded. You would have to be running an older version of
+   git-annex to get this error message in that situation though;
+   recent versions display a different message if the config parse fails.
+
+I think that's all the possibilities. To determine which it is, 
+I suggest you download the .git/config file from the webserver yourself
+(that would be `http://server.name/annex/.git/config` in your example),
+and pass the downloaded file to `git config --list --file` to get git to
+parse it, making sure git doesn't exit with an error.
+"""]]
diff --git a/doc/tips/setup_a_public_repository_on_a_web_site/comment_9_2dfb5b225ed62c0310ddadb0d83ceb79._comment b/doc/tips/setup_a_public_repository_on_a_web_site/comment_9_2dfb5b225ed62c0310ddadb0d83ceb79._comment
new file mode 100644
index 0000000000..d6b179de1b
--- /dev/null
+++ b/doc/tips/setup_a_public_repository_on_a_web_site/comment_9_2dfb5b225ed62c0310ddadb0d83ceb79._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="tomdhunt"
+ avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
+ subject="comment 9"
+ date="2021-03-22T23:35:30Z"
+ content="""
+```
+[tom@trafalgar clone_test]$ wget http://breitenfeld.lan/annex/.git/config
+--2021-03-22 10:23:32--  http://breitenfeld.lan/annex/.git/config
+Resolving breitenfeld.lan (breitenfeld.lan)... 192.168.1.241
+Connecting to breitenfeld.lan (breitenfeld.lan)|192.168.1.241|:80... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 1064 (1.0K)
+Saving to: ‘config’
+
+config                                                      100%[========================================================================================================================================>]   1.04K  --.-KB/s    in 0s      
+
+2021-03-22 10:23:32 (153 MB/s) - ‘config’ saved [1064/1064]
+
+[tom@trafalgar clone_test]$ file config
+config: ASCII text
+[tom@trafalgar clone_test]$ git config --list --file config
+core.repositoryformatversion=0
+core.filemode=true
+core.bare=false
+core.logallrefupdates=true
+annex.uuid=4ad5f0f5-9b92-475b-9abf-c1845a42c758
+annex.version=8
+annex.dotfiles=true
+annex.thin=true
+annex.addunlocked=include=torrent-downloads/*
+annex.sshcaching=true
+filter.annex.smudge=git-annex smudge -- %f
+filter.annex.clean=git-annex smudge --clean -- %f
+remote.surface.url=ssh://tom@DESKTOP-K1RQ50D/home/tom/bigdata
+remote.surface.fetch=+refs/heads/*:refs/remotes/surface/*
+remote.surface.annex-uuid=b4b17fe9-4c46-44a9-b6cb-0c2c17904830
+remote.zfsrent2.url=gcrypt::rsync://user@redacted.server.name/rent_data/data/git/bigdata
+remote.zfsrent2.fetch=+refs/heads/*:refs/remotes/zfsrent2/*
+remote.zfsrent2.gcrypt-participants=BDF1CB2C01162329
+remote.zfsrent2.gcrypt-signingkey=BDF1CB2C01162329
+remote.zfsrent2.gcrypt-publish-participants=true
+remote.zfsrent2.gcrypt-id=:id:iSB2By8j7YrAY1Zycx+Q
+remote.gnubee.url=gcrypt::rsync://archive@gnubee/data2/bigdata
+remote.gnubee.fetch=+refs/heads/*:refs/remotes/gnubee/*
+remote.gnubee.gcrypt-participants=BDF1CB2C01162329
+remote.gnubee.gcrypt-signingkey=BDF1CB2C01162329
+remote.gnubee.gcrypt-publish-participants=true
+remote.gnubee.gcrypt-id=:id:wAwSE2kqUs9HLuq1usaP
+[tom@trafalgar clone_test]$ git remote -v
+origin  http://breitenfeld.lan/annex/.git/ (fetch)
+origin  DISABLE (push)
+```
+FWIW on the server side the only requests I'm seeing to the .git/config URL are my wget tests, so it seems like git-annex never even gets as far as trying to fetch it.
+"""]]
diff --git a/doc/tips/shared_git_annex_directory_between_multiple_users.mdwn b/doc/tips/shared_git_annex_directory_between_multiple_users.mdwn
new file mode 100644
index 0000000000..45c622aa70
--- /dev/null
+++ b/doc/tips/shared_git_annex_directory_between_multiple_users.mdwn
@@ -0,0 +1,39 @@
+Scenario
+========
+
+You have a server where you want to welcome other people to push files, say for a family photo album. People have their own user account, so by default they will not be able to read/write from each other's repositories, due to git-annex strict restrictions.
+
+Solution
+========
+
+Setup a shared git repository:
+
+    git init shared ; cd shared # you can also do this on an existing git annex repo
+    git config core.sharedrepository group
+    chmod g+rwX -R .
+    chgrp -R $group .
+
+The idea here is to use the new (since [[news/version 4.20130909]]) support for git's `sharedRepository` configuration and restrict access to a specific group (instead of the default, a single user). You can also this to make the files accessible to all users on the system:
+
+    git config core.sharedrepository world
+    chmod a+rwX -R .
+
+This will make sure that you anyone can operate that git annex repository remotely.
+
+Third party applications
+------------------------
+
+Now if another application that is not aware of git's `sharedRepository` configuration (say a [[bittorrent]] daemon) writes files there, you may want to make sure that the files created are also writable by everyone. This is more tricky, but one way of doing this is with the [[!wikipedia setgid]] bit:
+
+    find -type d -exec chmod g+s {} \;
+
+You will also need to start the process with a proper [[!wikipedia umask]] (`002` instead of `022`).
+
+(!) I haven't actually tested this part. --[[anarcat]]
+
+See also
+========
+
+ * [[tips/setup a public repository on a web site]]
+ * [[news/version 4.20130909]]
+ * [[bugs/acl not honoured in rsync remote]]: why this does not work on encrypted remotes
diff --git a/doc/tips/shared_git_annex_directory_between_multiple_users/comment_1_01db8cf9dff016bd8e0498d36f325418._comment b/doc/tips/shared_git_annex_directory_between_multiple_users/comment_1_01db8cf9dff016bd8e0498d36f325418._comment
new file mode 100644
index 0000000000..4b7b516c5f
--- /dev/null
+++ b/doc/tips/shared_git_annex_directory_between_multiple_users/comment_1_01db8cf9dff016bd8e0498d36f325418._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="madduck"
+ ip="2001:a60:f0fb:0:224:d7ff:fe04:c82c"
+ subject="Does not work"
+ date="2014-04-06T10:48:06Z"
+ content="""
+This does not seem to work, even with latest git-annex. I think it's because git-annex [[!debbug desc=\"creates files without honouring +s on the parent directory\" 729757]]. I just found out it also doesn't honour default ACLs. I hope this can be fixed soon.
+"""]]
diff --git a/doc/tips/shared_git_annex_directory_between_multiple_users/comment_2_07ad0b2f6fd2644241a605a10d8fb8d0._comment b/doc/tips/shared_git_annex_directory_between_multiple_users/comment_2_07ad0b2f6fd2644241a605a10d8fb8d0._comment
new file mode 100644
index 0000000000..cce6f14435
--- /dev/null
+++ b/doc/tips/shared_git_annex_directory_between_multiple_users/comment_2_07ad0b2f6fd2644241a605a10d8fb8d0._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 2"
+ date="2015-05-27T21:05:24Z"
+ content="""
+i believe the bug madduck mentionned here was fixed. but i can't confirm by my own tests, things seem confused over here...
+"""]]
diff --git a/doc/tips/shared_git_annex_directory_between_multiple_users/comment_3_3bfb9e0e028f71c8a47e5363dcfdbd36._comment b/doc/tips/shared_git_annex_directory_between_multiple_users/comment_3_3bfb9e0e028f71c8a47e5363dcfdbd36._comment
new file mode 100644
index 0000000000..7740987dfe
--- /dev/null
+++ b/doc/tips/shared_git_annex_directory_between_multiple_users/comment_3_3bfb9e0e028f71c8a47e5363dcfdbd36._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="thk"
+ avatar="http://cdn.libravatar.org/avatar/bfef10a428769701aeee1db978951461"
+ subject="Also problem with USB drives"
+ date="2020-03-31T06:36:12Z"
+ content="""
+With a git annex repo on an USB drive and a linux filesystem (e.g. ext4) one often has the problem that users on different machines have different user ids. Thus one always needs to correct the user (chown) or permissions (chmod) before one can write to that repo.
+
+So it would help a lot, if git-annex would respect gits config setting \"core.sharedrepository\".
+
+From what I can see, the SUID bit seems to work at least. I use the group \"floppy\" as owner group for my USB drive repos since its group id is the same on all Debian machines and there is no harm to add users to it.
+"""]]
diff --git a/doc/tips/skydriveannex.mdwn b/doc/tips/skydriveannex.mdwn
new file mode 100644
index 0000000000..3b4aee04a4
--- /dev/null
+++ b/doc/tips/skydriveannex.mdwn
@@ -0,0 +1,32 @@
+skydriveannex 0.2.1
+=========
+
+Hook program for gitannex to use [skydrive](http://en.wikipedia.org/wiki/SkyDrive) (previously *Windows Live SkyDrive* and *Windows Live Folders*) as backend
+
+# Requirements:
+
+    python2
+    python-yaml
+
+Credit for the Skydrive api interface goes to https://github.com/mk-fg/python-skydrive
+
+# Install
+Clone the git repository in your home folder.
+
+    git clone git://github.com/TobiasTheViking/skydriveannex.git 
+
+This should make a ~/skydriveannex folder
+
+# Setup
+Make the file executable, and link it into PATH
+
+    cd ~/skydriveannex; chmod +x git-annex-remote-skydrive; sudo ln -sf `pwd`/git-annex-remote-skydrive /usr/local/bin/git-annex-remote-skydrive
+
+# Commands for gitannex:
+
+    git annex initremote skydrive type=external externaltype=skydrive encryption=shared folder=gitannex
+    
+An oauth authentication link should now be launched in the default browser. Authenticate, and use the last url as OAUTH key.
+
+    OAUTH='URL after last redirect' git annex initremote skydrive type=external externaltype=skydrive encryption=shared folder=gitannex
+    git annex describe skydrive "the skydrive library"
diff --git a/doc/tips/skydriveannex/comment_10_c3465b5587548dea56b80b32cd66d653._comment b/doc/tips/skydriveannex/comment_10_c3465b5587548dea56b80b32cd66d653._comment
new file mode 100644
index 0000000000..58b6c9077e
--- /dev/null
+++ b/doc/tips/skydriveannex/comment_10_c3465b5587548dea56b80b32cd66d653._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="Syncing not working :-/"
+ date="2014-05-17T19:52:33Z"
+ content="""
+Error log says:
+
+    git-annex-remote-skydrive is not installed in PATH (/Applications/git-annex.app/Contents/MacOS/bundle:/Applications/git-annex.app/Contents/MacOS/bundle:/Applications/git-annex.app/Contents/MacOS/bundle:/Applications/git-annex.app/Contents/MacOS/bundle:/Applications/git-annex.app/Contents/MacOS/bundle:/Applications/git-annex.app/Contents/MacOS/bundle:/Applications/git-annex.app/Contents/MacOS/bundle:/Applications/git-annex.app/Contents/MacOS/bundle:/usr/bin:/bin:/usr/sbin:/sbin)
+
+BUT I did a symlink, I even did 2 to 2 different locations that are in my path:
+
+    cd /Users/ovi/skydriveannex/
+    ln -sf `pwd`/git-annex-remote-skydrive /usr/bin/git-annex-remote-skydrive
+    ln -sf `pwd`/git-annex-remote-skydrive /opt/local/bin/git-annex-remote-skydrive
+"""]]
diff --git a/doc/tips/skydriveannex/comment_11_13692d8cb9ccf10ced26d90739385a6a._comment b/doc/tips/skydriveannex/comment_11_13692d8cb9ccf10ced26d90739385a6a._comment
new file mode 100644
index 0000000000..981c3dcdc1
--- /dev/null
+++ b/doc/tips/skydriveannex/comment_11_13692d8cb9ccf10ced26d90739385a6a._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626"
+ nickname="ovidiu"
+ subject="comment 11"
+ date="2015-10-03T19:18:24Z"
+ content="""
+shiny:skydriveannex ovi$ git annex initremote skydrive type=external externaltype=skydrive encryption=shared folder=gitannex
+initremote skydrive (encryption setup) (shared cipher)  21:14:20 [skydriveannex-0.2.1] <module> : 'Starting'
+ 21:14:20 [skydriveannex-0.2.1] login : 'EXCEPTION api.auth_get_token:AuthenticationError(u\"Insufficient authentication data provided (missing keys: [u'code'])\",)'
+osascript: OpenScripting.framework - scripting addition \"/Library/ScriptingAdditions/AeroFSFinderExtension.osax\" cannot be used with the current OS because it has no OSAXHandlers entry in its Info.plist.
+git-annex: You need to set OAUTH environment variables and folder and encryption parameters when running initremote.
+
+the folder gitannex was created on my onedrive but that is all.
+
+Log files:
+[2015-10-03 21:12:43.322605] main: Syncing with onedrive 
+ 21:12:50 [skydriveannex-0.2.1] <module> : 'Starting'
+ 21:12:5
+
+9  [ sYkoyud rnieveeda ntnoe xs-e0t. 2O.A1U]T Hl oegnivni r:o n'mEeXnCtE PvTaIrOiNa balpeis. aauntdh _fgoeltd_etro kaennd: PernoctroycpotliEornr opra(r4a0m0e,t e'r4s0 0f oCrl itehnet  rEermrootre:. 
+Bad Request')'
+[2015-10-03 21:13:07.435901] main: Syncing with onedrive 
+
+
+  You need to set OAUTH environment variables and folder and encryption parameters for the remote.
+[2015-10-03 21:15:14.60821] main: Syncing with onedrive 
+
+
+  You need to set OAUTH environment variables and folder and encryption parameters for the remote.
+[2015-10-03 21:15:57.926083] main: starting assistant version 5.20150929-g7010007
+(scanning...) [2015-10-03 21:15:58.506776] Watcher: Performing startup scan
+(started...) gpg: Signature made Wed Sep 30 20:45:53 2015 CEST using DSA key ID 89C809CB
+gpg: /var/folders/m6/zkd11n111m38ff37zbtgq0lr0000gp/T/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from \"git-annex distribution signing key (for Joey Hess) <id@joeyh.name>\"
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+ 21:16:01 [skydriveannex-0.2.1] <module> : 'Starting'
+ 21:16:
+
+01   [Ysokuy dnreievde atnon esxe-t0 .O2A.U1T]H  leongviinr o:n m'eEnXtC EvPaTrIiOaNb laepsi .aanudt hf_ogledte_rt oaknedn :ePnrcortyopctoiloEnr rpoarr(a4m0e0t,e r's4 0f0o rC ltiheen tr eEmrortoer.:
+ Bad Request')'
+[2015-10-03 21:16:34.655604] main: Syncing with onedrive 
+
+
+  You need to set OAUTH environment variables and folder and encryption parameters for the remote.
+"""]]
diff --git a/doc/tips/skydriveannex/comment_1_bf383481b2bbb962fbfe783b9f2f213a._comment b/doc/tips/skydriveannex/comment_1_bf383481b2bbb962fbfe783b9f2f213a._comment
new file mode 100644
index 0000000000..5bca3dfee3
--- /dev/null
+++ b/doc/tips/skydriveannex/comment_1_bf383481b2bbb962fbfe783b9f2f213a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="working for git-annex assistant?"
+ date="2014-05-13T18:40:31Z"
+ content="""
+Will following these steps lead to the Skydrive repo being visible and recognized by the assistant too?
+"""]]
diff --git a/doc/tips/skydriveannex/comment_2_1f747018b35ab8accd2bf0905e6ad926._comment b/doc/tips/skydriveannex/comment_2_1f747018b35ab8accd2bf0905e6ad926._comment
new file mode 100644
index 0000000000..0c737129bd
--- /dev/null
+++ b/doc/tips/skydriveannex/comment_2_1f747018b35ab8accd2bf0905e6ad926._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 2"
+ date="2014-05-16T16:26:50Z"
+ content="""
+The assistant will use any repositories you set up, no matter how you set them up.
+"""]]
diff --git a/doc/tips/skydriveannex/comment_3_8b9444006734262693f71e50a40eae1d._comment b/doc/tips/skydriveannex/comment_3_8b9444006734262693f71e50a40eae1d._comment
new file mode 100644
index 0000000000..892462cb30
--- /dev/null
+++ b/doc/tips/skydriveannex/comment_3_8b9444006734262693f71e50a40eae1d._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="Hitting trouble"
+ date="2014-05-16T17:49:59Z"
+ content="""
+    shiny-2:skydriveannex ovi$ git annex initremote skydrive type=external externaltype=skydrive encryption=shared folder=git-annex
+    git-annex: First run: git-annex init
+    shiny-2:skydriveannex ovi$
+
+Above wasn't mentioned in the tutorial so I tried it:
+
+    shiny-2:skydriveannex ovi$ git-annex init
+    init  ok
+    (Recording state in git...)
+    shiny-2:skydriveannex ovi$
+
+What now? Never got asked about any OAUTH...
+"""]]
diff --git a/doc/tips/skydriveannex/comment_4_8b01dc6ca1082a8c24ff65fec9d759d8._comment b/doc/tips/skydriveannex/comment_4_8b01dc6ca1082a8c24ff65fec9d759d8._comment
new file mode 100644
index 0000000000..7edc9d4149
--- /dev/null
+++ b/doc/tips/skydriveannex/comment_4_8b01dc6ca1082a8c24ff65fec9d759d8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="comment 4"
+ date="2014-05-16T17:51:29Z"
+ content="""
+And no link was opened automatically
+"""]]
diff --git a/doc/tips/skydriveannex/comment_5_1d220d96945d497f3a93b5d848eb3995._comment b/doc/tips/skydriveannex/comment_5_1d220d96945d497f3a93b5d848eb3995._comment
new file mode 100644
index 0000000000..f6a4c74158
--- /dev/null
+++ b/doc/tips/skydriveannex/comment_5_1d220d96945d497f3a93b5d848eb3995._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 5"
+ date="2014-05-16T19:03:34Z"
+ content="""
+You have to run git-annex init before you can use other git-annex commands. I think if you run git annex initremote now, it will work.
+"""]]
diff --git a/doc/tips/skydriveannex/comment_6_a7a3afdc7eed9a0eda48dcb57f1e87c6._comment b/doc/tips/skydriveannex/comment_6_a7a3afdc7eed9a0eda48dcb57f1e87c6._comment
new file mode 100644
index 0000000000..d589a676c7
--- /dev/null
+++ b/doc/tips/skydriveannex/comment_6_a7a3afdc7eed9a0eda48dcb57f1e87c6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="comment 6"
+ date="2014-05-16T19:25:03Z"
+ content="""
+tried it but no luck:
+
+    git annex initremote skydrive type=external externaltype=skydrive encryption=shared folder=git-annex
+    initremote skydrive (encryption setup) (shared cipher) env: python2: No such file or directory
+    git-annex: external special remote protocol error, unexpectedly received \"\" (unable to parse command)
+"""]]
diff --git a/doc/tips/skydriveannex/comment_7_7fcd9c6b5e2a3fc7b753eeac06164036._comment b/doc/tips/skydriveannex/comment_7_7fcd9c6b5e2a3fc7b753eeac06164036._comment
new file mode 100644
index 0000000000..d789a8d946
--- /dev/null
+++ b/doc/tips/skydriveannex/comment_7_7fcd9c6b5e2a3fc7b753eeac06164036._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="making some progress"
+ date="2014-05-17T19:08:16Z"
+ content="""
+Figured out how to solve that:
+    which python
+    /opt/local/bin/python
+    shiny-2:git-annex ovi$ sudo ln -s `which python` /usr/bin/python2
+
+The URL opened in my browser, I allowed access, waited for the redirect, copied the URL, hit the next problem:
+
+    OAUTH='https://login.live.com/oauth20_desktop.srf?code=hidden_on_purpose' git annex initremote skydrive type=external externaltype=skydrive encryption=shared folder=git-annex
+initremote skydrive (encryption setup) (shared cipher)  21:06:27 [skydriveannex-0.2.1] <module> : 'Starting'
+     21:06:27 [skydriveannex-0.2.1] login : 'EXCEPTION api.auth_get_token:ImportError('No module named requests',)'
+    git-annex: You need to set OAUTH environment variables and folder and encryption parameters when running initremote.
+"""]]
diff --git a/doc/tips/skydriveannex/comment_8_856eaa1b167033aede91a937099c7833._comment b/doc/tips/skydriveannex/comment_8_856eaa1b167033aede91a937099c7833._comment
new file mode 100644
index 0000000000..0fc61da005
--- /dev/null
+++ b/doc/tips/skydriveannex/comment_8_856eaa1b167033aede91a937099c7833._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="Done! Success!"
+ date="2014-05-17T19:23:06Z"
+ content="""
+realized I need requests. to install I need pip.
+
+    sudo port install py27-pip
+
+    pip install requests
+
+    login : 'EXCEPTION api.auth_get_token:ImportError('No module named six',)' 
+
+    pip install six
+
+Finished! Seems to be working and I can see this repository in my assistant!
+"""]]
diff --git a/doc/tips/skydriveannex/comment_9_cfcf767a1bf07957b76d7f44ef8a9500._comment b/doc/tips/skydriveannex/comment_9_cfcf767a1bf07957b76d7f44ef8a9500._comment
new file mode 100644
index 0000000000..614e74c98f
--- /dev/null
+++ b/doc/tips/skydriveannex/comment_9_cfcf767a1bf07957b76d7f44ef8a9500._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="QUESTION"
+ date="2014-05-17T19:29:37Z"
+ content="""
+Wondering about this:
+
+    encryption=shared
+
+I read what it means: http://git-annex.branchable.com/encryption/ 
+
+But now I'm wondering how the repos which I set up via the assistant have been setup. when setting them up I only had the choice between \"encrypt all files\" and \"disable encryption\" so how can I check what settings my other repos are using?
+"""]]
diff --git a/doc/tips/splitting_a_repository.mdwn b/doc/tips/splitting_a_repository.mdwn
new file mode 100644
index 0000000000..d20497c74d
--- /dev/null
+++ b/doc/tips/splitting_a_repository.mdwn
@@ -0,0 +1,126 @@
+[[!meta title="Splitting a git-annex repository"]]
+
+I have a [git annex](https://git-annex.branchable.com/) repo for all my media
+that has grown to 57866 files and git operations are getting slow, especially
+on external spinning hard drives, so I decided to split it into separate
+repositories.
+
+Here is how to split out a repository that contains a subset of the files
+in the larger repository. The larger repository is left as-is, but similar
+methods can be used to remove the files from it. Or, it can be deleted
+once it gets split up into several smaller repositories.
+
+(This is the reverse of [[migrating two seperate disconnected directories
+to git annex]].)
+
+Suppose the old big repo is at `~/oldrepo`, and you want to split out
+photos from it, and those are all located inside `~/oldrepo/photos`.
+
+First, let's create a new empty repo.
+
+	mkdir ~/photos
+	cd photos
+	git init
+
+Now to populate the new repo with the files we want from the old repo. We
+can use `git filter-branch` to create a git branch that contains only the
+history of the files in `photos`. That command has a *lot* of options and
+ways to use it, but here is one simple way:
+
+	cd ~/oldrepo
+
+	# filter a branch to with only the files wanted by the new repository
+	git branch split-master master
+	git filter-branch --prune-empty --subdirectory-filter photos split-master
+
+	# replace the new repo's master branch with the filtered branch
+	git push ~/photos split-master
+	git branch -D split-master
+	cd ~/photos
+	git reset --hard split-master
+	git branch -d split-master
+
+Next, the git-annex branch needs to be filtered to include only
+the files in `photos`, and that filtered branch sent to the new repository.
+That can be done with the [[git-annex-filter-branch]](1) command.
+
+	cd ~/oldrepo
+	annexrev=$(git annex filter-branch photos --include-all-key-information --include-all-repo-config --include-global-config)
+	git push ~/photos $annexrev:refs/heads/git-annex
+
+Next, initialize git-annex on the new repository. This uses
+the same annex.uuid as was in the old repository. That's ok, because
+the repository that's been split off will never have the old repository
+as a remote.
+
+	cd ~/photos
+	git annex reinit $(git config --file ../tofilter/.git/config annex.uuid)
+
+Finally the annexed file contents need to be copied to the new repository:
+
+	cd ~/photos
+
+	# Hardlink all the annexed data from the old repo
+	cp -rl ~/oldrepo/.git/annex/objects .git/annex/
+
+	# Remove unneeded hard links
+	git annex unused --quiet
+	git annex drop --unused --force
+
+	# Fix up annex links to content and make sure it's all ok.
+	git annex fsck
+
+Warning: This method of copying the annexed file contents and dropping
+the unused ones causes the git-annex branch to log information.
+
+# alternative older method
+
+Here is another way to do it. Suppose the old big repo is at `~/oldrepo`:
+
+```
+# Create a new repo for photos only
+mkdir ~/photos
+cd photos
+git init
+git annex init laptop
+
+# Hardlink all the annexed data from the old repo
+cp -rl ~/oldrepo/.git/annex/objects .git/annex/
+
+# Regenerate the git annex metadata
+git annex fsck --fast
+
+# Also split the repo on the usb key
+cd /media/usbkey
+git clone ~/photos
+cd photos
+git annex init usbkey
+cp -rl ../oldrepo/.git/annex/objects .git/annex/
+git annex fsck --fast
+
+# Connect the annexes as remotes of each other
+git remote add laptop ~/photos
+cd ~/photos
+git remote add usbkey /media/usbkey
+```
+
+At this point, I went through all repos doing standard cleanup:
+
+```
+# Remove unneeded hard links
+git annex unused
+git annex dropunused --force 1-12345
+
+# Sync
+git annex sync
+```
+
+To make sure nothing is missing, I used `git annex find --not --in=here`
+to see if, for example, the usbkey that should have everything could be missing
+some thing.
+
+Update: Antoine Beaupré pointed me to
+[this tip about Repositories with large number of files](http://git-annex.branchable.com/tips/Repositories_with_large_number_of_files/)
+which I will try next time one of my repositories grows enough to hit a performance issue.
+
+> This document was originally written by [Enrico Zini](http://www.enricozini.org/blog/2017/debian/splitting-a-git-annex-repository/) and added to this wiki by [[anarcat]].
diff --git a/doc/tips/splitting_a_repository/comment_1_654527ef2350fe871e2d7ff6addc6713._comment b/doc/tips/splitting_a_repository/comment_1_654527ef2350fe871e2d7ff6addc6713._comment
new file mode 100644
index 0000000000..8ba3b7981c
--- /dev/null
+++ b/doc/tips/splitting_a_repository/comment_1_654527ef2350fe871e2d7ff6addc6713._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-05-11T16:28:32Z"
+ content="""
+2021 update: The new [[git-annex-filter-branch]] command
+can be used to produce a filtered version of the git-annex branch that only
+includes information for the files you want. I have updated the tip to
+show how to do it that way, and kept the old way as an alternative
+
+The old, alternative way is a simple way to split a repository, but the
+resulting split git repository will be larger than is really necessary.
+(The new method avoids this problem.)
+
+When you `dropunused` all the hard links that are not present in the
+repository, git-annex will commit a log to the git-annex branch saying "I
+don't have this content" for each of them. That seems unnecessary since
+it probably does not have an earlier log saying it contained the content
+that was hard linked into it, and perhaps could be improved in git-annex
+to not record that unncessarily, but that's what it does currently.
+
+So I suggest running `git annex forget` after the dropunused or at some
+later point. That will delete all traces of those log files from
+the git-annex branch.
+"""]]
diff --git a/doc/tips/splitting_a_repository/comment_2_2437e95397e1b06ade5360405e399591._comment b/doc/tips/splitting_a_repository/comment_2_2437e95397e1b06ade5360405e399591._comment
new file mode 100644
index 0000000000..9da0c3d200
--- /dev/null
+++ b/doc/tips/splitting_a_repository/comment_2_2437e95397e1b06ade5360405e399591._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="sameerds"
+ avatar="http://cdn.libravatar.org/avatar/b6d36a03115d3ececaafe16e327e9e27"
+ subject="did not work for me"
+ date="2019-03-16T10:07:09Z"
+ content="""
+I tried this on a version 7 repo, and nothing happened. The \"git annex fsck --fast\" returned immediately. Is there any git stuff missing in the above instructions? I would expect that we should at least setup the refs correctly and check out a working directory, right?
+"""]]
diff --git a/doc/tips/splitting_a_repository/comment_3_c0ccbf6758eabf645075d3b84188825e._comment b/doc/tips/splitting_a_repository/comment_3_c0ccbf6758eabf645075d3b84188825e._comment
new file mode 100644
index 0000000000..472c78216b
--- /dev/null
+++ b/doc/tips/splitting_a_repository/comment_3_c0ccbf6758eabf645075d3b84188825e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="indeed a useful use case"
+ date="2019-04-19T13:26:05Z"
+ content="""
+Indeed it would be nice if there was an easy way to split a git annex repository into smaller ones, while those smaller ones also obtain all the git-annex branch availability/metadata information about the files they inherit.  The situations comes up quite frequently whenever it is desired to modularize bigger repositories. The simplest use case is to make a specific subdirectory into a git/git-annex submodule.  Is there a way/recipe to easily accomplish also moving all git-annex branch metadata. And the original repository should get those files removed within its git tree.
+
+One possible way we see is to clone the original repository, remove all other files, move subdirectory files \"up\" needed number of directories, and then rewrite git history to forget and then use `annex forget` but that one wouldn't \"forget\" information about the files which are not in the current tree, so would also require some manual trimming of `git-annex` branch before `annex forget`.
+
+But may be there is a better way?
+"""]]
diff --git a/doc/tips/splitting_a_repository/comment_4_fbf9d86fd3aee4542a7cabacce9578cd._comment b/doc/tips/splitting_a_repository/comment_4_fbf9d86fd3aee4542a7cabacce9578cd._comment
new file mode 100644
index 0000000000..889596585f
--- /dev/null
+++ b/doc/tips/splitting_a_repository/comment_4_fbf9d86fd3aee4542a7cabacce9578cd._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="jochen.keil@38b1f86ab65128dab3e62e726403ceee4f5141bf"
+ nickname="jochen.keil"
+ avatar="http://cdn.libravatar.org/avatar/a1329c0b3a262017553cc5497aa12c18"
+ subject="comment 4"
+ date="2020-09-15T13:34:47Z"
+ content="""
+I have my repositories set up like this:
+
+local repository (local) <-> bare backup repository (bkp)
+
+My repository has several subfolders dir1, dir2, dir3, .., that I want to split up in separate repositories.
+
+What I did was this:
+
+    cd ${local}
+    git annex drop --force dir1 dir2 dir3 ..
+    git filter-branch -f --index-filter 'git rm -f --cached -r --ignore-unmatch dir1 dir2 dir3 ..' --prune-empty -- --all
+    git reflog expire --expire=now --all && git gc --prune=now --aggressive
+
+Now I'm left with the only directory that I want to keep. My plan would be to run
+
+    git annex get --from=bkp dirK
+    git annex copy --to=bkpK dirK
+
+Repeat for dir1 .. dirN.
+
+I know it's a lot of back and forth copying but apart from that are there any downsides with this approach?
+
+Thank you!
+"""]]
diff --git a/doc/tips/splitting_a_repository/comment_5_baf4871cb78b337c627a352333c4e39d._comment b/doc/tips/splitting_a_repository/comment_5_baf4871cb78b337c627a352333c4e39d._comment
new file mode 100644
index 0000000000..3a1a1be764
--- /dev/null
+++ b/doc/tips/splitting_a_repository/comment_5_baf4871cb78b337c627a352333c4e39d._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-09-15T20:32:13Z"
+ content="""
+@jochen.keil, your use of drop --force risks data loss if a file is not
+backed up to a remote. I don't think the --force is necessary. And it
+should be possible to use `git annex dropunused` instead, after the
+filtering.
+
+If you are doing this in several copies of the repo, you will end up with
+multiple git-annex repos that all have the same annex.uuid. While you
+intend to keep these repos separate, that's still somewhat asking for
+trouble.
+
+You have not filtered the git-annex branch at all, so it still has
+information about files that you have filtered out of the git history
+otherwise.
+
+To solve both, I think you could `git-annex reinit` with a new uuid
+you make up, `git annex fsck --fast` to update its location tracking
+to use the new uuid, and then `git-annex dead` the old uuid,
+and all remotes (such as bkp). Then `git annex forget` will clean out the
+data in the git-annex branch about the files you've filtered out.
+"""]]
diff --git a/doc/tips/splitting_a_repository/comment_6_ce243a141a286e5e1a55af8321238b5c._comment b/doc/tips/splitting_a_repository/comment_6_ce243a141a286e5e1a55af8321238b5c._comment
new file mode 100644
index 0000000000..8fc2919939
--- /dev/null
+++ b/doc/tips/splitting_a_repository/comment_6_ce243a141a286e5e1a55af8321238b5c._comment
@@ -0,0 +1,94 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~barthelemy"
+ nickname="barthelemy"
+ avatar="http://cdn.libravatar.org/avatar/e99cb15f6029de3225721b3ebdd0233905eb69698e9b229a8c4cc510a4135438"
+ subject="comment 6"
+ date="2020-12-01T21:55:31Z"
+ content="""
+Hello,
+
+I want to split my big git annex repo into smaller ones
+in order to workaround scalability issues (too many files),
+and to enable simpler synchronization rules and authorizations.
+As I first step, I'd like to split out my family pictures
+in a separate repo which does not know about the other
+content.
+
+Based on the instructions from this page, I came up with the test script below.
+It works, thank you!
+
+However, there is a drawback: in order to really forget the non-pictures content,
+I had to also forget about an old offsite backup (a git clone), which holds (some of)
+the pictures. Is there a way to keep tracking the pictures in this backup?
+
+I think I wouldn't have had the issue if this backup had been
+a special remote instead of a clone.
+
+    set -x
+    set -e
+    chmod -R u+w annexes
+    rm -rf annexes
+
+    ### setup the main repo
+    mkdir -p annexes/annex
+    cd annexes/annex
+    git init
+    git annex init main
+
+    # add data
+    mkdir -p private/Pictures/2019
+    echo \"big file a\" > private/Pictures/2019/a
+    echo \"big file b\" > private/Pictures/2019/b
+    git annex add private/Pictures/2019/{a,b}
+    git commit -m \"add pictures a b\"
+
+    mkdir -p public/
+    echo \"big file c\" > public/c
+    git annex add public/c
+    git rm private/Pictures/2019/a
+    git commit -m \"add document c\"
+
+    ### make an offsite \"time capsule\" backup.
+    # I don't want to ever touch it again, except for disaster recovery.
+    # Ideally, I want to keep tracking the data on it even after the split.
+    cd ..
+    git clone annex offsite
+    cd offsite
+    git annex get private
+    git annex sync
+    OFFSITE_UUID=$(git annex info  --json here | jq .uuid -r)
+
+    ### prepare for the split: let use hardlink instead of copies
+    cd ../annex
+    git config annex.hardlink true
+    git annex untrust here
+
+    # clone and prune
+    cd ..
+    git clone annex pictures
+    cd pictures
+    # remove everything except private/Pictures
+    git filter-branch --subdirectory-filter private/Pictures -- --all
+    # useless?
+    git reflog expire --expire=now --all && git gc --prune=now --aggressive
+    # get the pictures (just b, because I could not find a way to get a without getting c)
+    git annex get --from origin
+    # attemp to forget about the other files (just c)
+    MAIN_UUID=$(git annex info  --json here | jq .uuid -r)
+    git annex reinit `uuidgen`
+    git annex fsck --fast
+    git commit -m \"fixup links\"
+    git annex dead $MAIN_UUID
+    git annex dead $OFFSITE_UUID # sadly, I won't be able to track my old offsite backup
+    git annex dead origin
+    git annex forget --drop-dead --force
+    # try to get again
+    # nothing happens: this annex
+    # * already has b
+    # * knows a existed, but not where to find it (not great, but ok for me)
+    # * does not know about c (which was the whole point)
+    git annex get --all
+    # check what we have
+    find .git/annex/objects -type f -exec cat \{\} \;
+
+"""]]
diff --git a/doc/tips/splitting_a_repository/comment_7_0d11c72712da0cf36b8cc91ba7501d52._comment b/doc/tips/splitting_a_repository/comment_7_0d11c72712da0cf36b8cc91ba7501d52._comment
new file mode 100644
index 0000000000..a2099f11a0
--- /dev/null
+++ b/doc/tips/splitting_a_repository/comment_7_0d11c72712da0cf36b8cc91ba7501d52._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="eric.w@eee65cd362d995ced72640c7cfae388ae93a4234"
+ nickname="eric.w"
+ avatar="http://cdn.libravatar.org/avatar/8d9808c12db3a3f93ff7f9e74c0870fc"
+ subject="comment 7"
+ date="2021-01-11T22:48:27Z"
+ content="""
+> ```
+> # Regenerate the git annex metadata
+> git annex fsck --fast
+> ```
+
+Exactly what does this command do? What metadata is regenerated and what does \"regenerated\" in this context mean?
+
+"""]]
diff --git a/doc/tips/splitting_a_repository/comment_8_72ebd848d406190e12e3291cff824f7e._comment b/doc/tips/splitting_a_repository/comment_8_72ebd848d406190e12e3291cff824f7e._comment
new file mode 100644
index 0000000000..2bc59aa55c
--- /dev/null
+++ b/doc/tips/splitting_a_repository/comment_8_72ebd848d406190e12e3291cff824f7e._comment
@@ -0,0 +1,137 @@
+[[!comment format=mdwn
+ username="jochen.keil@38b1f86ab65128dab3e62e726403ceee4f5141bf"
+ nickname="jochen.keil"
+ avatar="http://cdn.libravatar.org/avatar/a1329c0b3a262017553cc5497aa12c18"
+ subject="comment 8"
+ date="2023-05-10T12:57:54Z"
+ content="""
+Hi,
+
+I went through the hassle of splitting up repositories once again. I wrote earlier about it ([comment 4](http://git-annex.branchable.com/tips/splitting_a_repository/#comment-7285540d397c0f0c0b790f9de3ce8458)) and got some valuable input from Joey!
+
+My repositories contain pictures only. They are organized by `YYYY/MM/DD/YYYY-MM-DDTHH:MM:SS_Filename.ext` where the `YYYY` directory is also the repository (i.e. contains the `.git` subfolder). Every repository is backed by a bare repository which is located on a much larger, but slower, zfs RAID. Here's an example:
+
+
+```
+ls -la 2020
+total 4K
+drwxrwxr-x 1 jchnkl jchnkl  44 Apr 12 12:25 .
+drwxr-xr-x 1 jchnkl jchnkl 770 Mai  9 22:43 ..
+drwxrwxr-x 1 jchnkl jchnkl  16 Jan 30 11:55 01
+drwxrwxr-x 1 jchnkl jchnkl  32 Feb 28 18:21 02
+drwxrwxr-x 1 jchnkl jchnkl   4 Mär  3 10:23 03
+drwxrwxr-x 1 jchnkl jchnkl  28 Apr 12 12:26 04
+[..]
+drwxrwxr-x 1 jchnkl jchnkl 196 Mai 10 14:19 .git
+-rw-rw-r-- 1 jchnkl jchnkl  14 Jan 19 12:21 .gitignore
+```
+
+```
+ls -la 2020/01/01
+total 1400K
+drwxrwxr-x 1 jchnkl jchnkl 13320 Jan 19 12:23 .
+drwxrwxr-x 1 jchnkl jchnkl    16 Jan 30 11:55 ..
+lrwxrwxrwx 1 jchnkl jchnkl   206 Jan  1 09:19 2020-01-01T08:19:17+0100_0092.arw -> ../../.git/annex/objects/f1/v3/SHA256E-s85557248--bda9d67b8d39afd96041f063ec2b9431ca8cc6fa9d88c35ae9015bf591a85265.arw/SHA256E-s85557248--bda9d67b8d39afd96041f063ec2b9431ca8cc6fa9d88c35ae9015bf591a85265.arw
+-rw-rw-r-- 1 jchnkl jchnkl  1226 Jan 19 12:31 2020-01-01T08:19:17+0100_0092.arw.xmp
+lrwxrwxrwx 1 jchnkl jchnkl   206 Jan  1 09:20 2020-01-01T08:20:03+0100_0093.arw -> ../../.git/annex/objects/Mw/M9/SHA256E-s85557248--a4c5c050078a4ab94e1b686794d017c7500bb9b2c2e9b8063f6eeb9772055056.arw/SHA256E-s85557248--a4c5c050078a4ab94e1b686794d017c7500bb9b2c2e9b8063f6eeb9772055056.arw
+-rw-rw-r-- 1 jchnkl jchnkl  1226 Jan 19 12:31 2020-01-01T08:20:03+0100_0093.arw.xmp
+[..]
+```
+
+My problem was that I had a bunch (hundreds) of files that I didn't want to be there. So, the first step was to create a list of globs of all files that I wanted to move away, for example:
+
+```
+01/02/* # all files
+02/03/*_{0001..1234}* # a range of files
+# etc.
+```
+
+I used `bash` to expand those globs to a list of files:
+
+```
+for g in $(< globs.txt); do bash -O nullglob -c \"echo $g\"; done | tr ' ' '\n' > files.txt
+```
+
+Then I cloned the original repository (here: `2020`) twice, and removed the remote:
+
+```
+git clone 2020 2020.new.1
+cd 2020.new.1
+git remote rm origin
+cd ..
+
+git clone 2020 2020.new.2
+cd 2020.new.2
+git remote rm origin
+```
+
+I also created two new bare repositories:
+
+```
+git init --bare 2020.new.1.git
+cd 2020.new.1.git && git annex init tank
+cd ..
+
+git init --bare 2020.new.2.git
+cd 2020.new.2.git && git annex init tank
+```
+
+Where I hardlinke'd the annexed objects from the original bare repository (`2020.git`):
+
+```
+cp -ranl 2020.git/annex/objects 2020.new.1/annex
+cp -ranl 2020.git/annex/objects 2020.new.2/annex
+```
+
+After that I went back to the first clone, added the new remote and fixed the file location using `fsck`:
+
+```
+cd 2020.new.1
+git remote add tank /path/to/2020.new.1.git
+git annex sync tank
+git annex fsck --fsck --from tank
+```
+
+Once that was done I could easily remove the files:
+
+```
+for f in $(< files.txt); do git rm -f $f; done
+git commit -a -m 'remove files'
+git annex sync tank
+git annex unused --from=tank
+git annex dropunused --force --from=tank all
+```
+
+Fixing up the second repository requires a second list of files: everything that's left over in `2020.new.1`:
+
+```
+find ?? -type f -or -type l > files.2.txt
+```
+
+Now in the second repository I did the same as for the first but with `files.2.txt`:
+
+```
+cd 2020.new.2
+git remote add tank /path/to/2020.new.2.git
+git annex sync tank
+git annex fsck --fsck --from tank
+for f in $(< files.2.txt); do git rm -f $f; done
+git commit -a -m 'remove files'
+git annex sync tank
+git annex unused --from=tank
+git annex dropunused --force --from=tank all
+```
+
+Before removing the old repositories (`2020` and `2020.git`) I double checked that all files are still around:
+
+```
+find 2020.git/annex/objects -type f | sed -e 's|.*/||' > 2020.git.annex.objects.txt
+find 2020.new.1.git/annex/objects -type f | sed -e 's|.*/||' > 2020.new.1.git.annex.objects.txt
+find 2020.new.2.git/annex/objects -type f | sed -e 's|.*/||' > 2020.new.2.git.annex.objects.txt
+diff -u <(echo old; sort -u 2020.git.annex.objects.txt) <(echo new; sort -u 2020.new.{1,2}.git.annex.objects.txt)
+```
+
+Finally, there should be no differences and it's save to `rm -rf` `2020` and `2020.git`.
+
+Hope this helps. Any comments and suggestions welcome!
+"""]]
diff --git a/doc/tips/storing_data_in_git-lfs.mdwn b/doc/tips/storing_data_in_git-lfs.mdwn
new file mode 100644
index 0000000000..a5b504d994
--- /dev/null
+++ b/doc/tips/storing_data_in_git-lfs.mdwn
@@ -0,0 +1,69 @@
+git-annex can store data in [git-lfs](https://git-lfs.github.com/)
+repositories, using the [[git-lfs special remote|special_remotes/git-lfs]].
+
+You do not need the git-lfs program installed to use it, just a recent
+enough version of git-annex.
+
+## getting started
+
+Here's how to initialize a git-lfs special remote on Github.
+
+	git annex initremote lfs type=git-lfs encryption=none url=https://github.com/yourname/yourrepo
+
+In this example, the remote will not be encrypted, so anyone who can access
+it can see its contents. It is possible to encrypt everything stored in a
+git-lfs remote, see [[fully_encrypted_git_repositories_with_gcrypt]].
+
+Once the git-lfs remote is set up, git-annex can store and retrieve
+content in the usual ways:
+
+	git annex copy * --to lfs
+	git annex get --from lfs
+
+But, git-annex **cannot delete anything** from a git-lfs special remote,
+because the protocol does not support deletion.
+
+A git-lfs special remote also functions as a regular git remote. You can
+use things like `git push` and `git pull` with it.
+
+## enabling existing git-lfs special remotes
+
+There are two different ways to enable a git-lfs special 
+remote in another clone of the repository.
+
+Of course, you can use `git annex enableremote` to enable a git-lfs special
+remote, the same as you would enable any other special remote.
+Eg, for the "lfs" remote initialized above:
+
+	git annex enableremote lfs
+
+But perhaps more simply, if git-annex sees a git remote that matches
+the url that was provided to initremote earlier, it will *automatically*
+enable that git remote as a git-lfs special remote.
+
+So you can just git clone from the url, and the "origin" remote will be
+automatically used as a git-lfs special remote.
+
+	git clone https://github.com/yourname/yourrepo
+	cd yourrepo
+	git-annex get --from origin
+
+Nice and simple, and much the same as git-annex handles its regular
+remotes.
+
+(Note that git-annex versions 7.20191115 and older didn't remember the url
+privided to initremote, so you'll need to pass the url= parameter
+to enableremote in that case. Newer versions of git-annex will then
+remember the url.)
+
+## multiple urls
+
+Often there are multiple urls that can access the same git repository.
+You can set up git-lfs remotes for each url. For example,
+to add a remote accessing the github repository over ssh:
+
+	git annex initremote lfs-http --sameas=lfs url=git@github.com:yourname/yourrepo.git
+
+The `--sameas` parameter tells git-annex that this is the same as the "lfs"
+repository, so it will understand that anything it stores in one remote can
+be accessed also with the other remote.
diff --git a/doc/tips/storing_data_in_git-lfs/comment_1_e4eb406a4bf146c1f442047a4c1b1e1a._comment b/doc/tips/storing_data_in_git-lfs/comment_1_e4eb406a4bf146c1f442047a4c1b1e1a._comment
new file mode 100644
index 0000000000..24908e6a6a
--- /dev/null
+++ b/doc/tips/storing_data_in_git-lfs/comment_1_e4eb406a4bf146c1f442047a4c1b1e1a._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ nickname="beryllium"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="Colocating git-annex and git-lfs"
+ date="2024-02-22T02:55:25Z"
+ content="""
+Is it possible to add git-lfs capabilities to a git-annex, without using a special remote?
+
+I guess what I want is, are there any reasonable instructions to graft the hooks so that this is possible:
+
+
+	$ git init
+	$ git-lfs install
+	$ git-annex init
+
+And you can alternate between something like below:
+
+	$ git-lfs track \"*.exif_thumbnail.*\"
+	$ git-annex add IMG_0001.jpg
+	$ git add IMG_0001.exif_thumbnail.jpg
+
+Obviously this betrays the scenario of extracting thumbnails from the EXIF header and storing them alongside, as another form of metadata. If there's a better workflow to this, that would be appreciated too.
+"""]]
diff --git a/doc/tips/transmission_integration.mdwn b/doc/tips/transmission_integration.mdwn
new file mode 100644
index 0000000000..12f556b90f
--- /dev/null
+++ b/doc/tips/transmission_integration.mdwn
@@ -0,0 +1,11 @@
+[[This simple script|transmission_integration/transmission_integration.sh]] will make sure files downloaded by the
+[Transmission BitTorrent client](https://www.transmissionbt.com/) will
+be added into git-annex.
+
+To enable it, install it to /usr/local/bin and add the following to
+your settings.json:
+
+	"script-torrent-done-enabled": true,
+	"script-torrent-done-filename": "/usr/local/bin/transmission-git-annex-add",
+
+-- [[users/anarcat]]
diff --git a/doc/tips/transmission_integration/transmission_integration.sh b/doc/tips/transmission_integration/transmission_integration.sh
new file mode 100644
index 0000000000..8b4dcd4d02
--- /dev/null
+++ b/doc/tips/transmission_integration/transmission_integration.sh
@@ -0,0 +1,38 @@
+#! /bin/sh
+
+set -e
+
+# environment from transmission:
+# TR_APP_VERSION
+# TR_TIME_LOCALTIME
+# TR_TORRENT_DIR
+# TR_TORRENT_HASH
+# TR_TORRENT_ID
+# TR_TORRENT_NAME
+# source: https://trac.transmissionbt.com/wiki/Scripts
+
+if [ -z "$TR_APP_VERSION" ]; then
+  echo "missing expected $TR_APP_VERSION from Transmission"
+  exit 1
+fi
+
+message="transmission adding torrent '$TR_TORRENT_NAME'
+
+TR_APP_VERSION: $TR_APP_VERSION
+TR_TIME_LOCALTIME: $TR_TIME_LOCALTIME
+TR_TORRENT_DIR: $TR_TORRENT_DIR
+TR_TORRENT_HASH: $TR_TORRENT_HASH
+TR_TORRENT_ID: $TR_TORRENT_ID
+TR_TORRENT_NAME: $TR_TORRENT_NAME
+"
+
+# heredocs preserve newlines
+cat <<EOF
+$message
+EOF
+# add the actual torrent and commit whatever's left to commit
+cd "$TR_TORRENT_DIR"
+git annex add "$TR_TORRENT_NAME" && \
+git commit -F- <<EOF
+$message
+EOF
diff --git a/doc/tips/unlocked_files.mdwn b/doc/tips/unlocked_files.mdwn
new file mode 100644
index 0000000000..4f6d5901c6
--- /dev/null
+++ b/doc/tips/unlocked_files.mdwn
@@ -0,0 +1,160 @@
+Normally, git-annex stores annexed files in the repository, locked down,
+which prevents the content of the file from being modified.
+That's a good thing, because it might be the only copy, you wouldn't
+want to lose it in a fumblefingered mistake.
+
+	# git annex add some_file
+	add some_file
+	# echo oops > some_file
+	bash: some_file: Permission denied
+
+Sometimes though you want to modify a file. Maybe once, or maybe
+repeatedly. To support this, git-annex also supports unlocked files.
+They are stored in the git repository differently, and they appear as
+regular files in the working tree, instead of the symbolic links used for
+locked files.
+
+## using unlocked files
+
+You can unlock any annexed file:
+
+	# git annex unlock my_cool_big_file
+
+That changes what's stored in git between a git-annex symlink
+(locked) and a git-annex pointer file (unlocked). You can commit
+the change, if you want that file to be unlocked in other clones of the
+repository. To lock the file again, use `git annex lock`.
+
+The nice thing about an unlocked file is that you can modify it
+in place -- it's a regular file. And you can commit your changes.
+
+	# echo more stuff >> my_cool_big_file
+	# git commit -a -m "some changes"
+	[master 196c0e2] some changes
+	 1 files changed, 1 insertion(+), 1 deletion(-)
+
+Notice that `git commit -a` added the new content of the file to the annex,
+and only committed a change to the pointer. That happened because git-annex
+knows this was an annexed file before. Git leaves the file unlocked, so
+you can continue to make modifications to it.
+
+By default, using git to add a file that has not been annexed before will
+still add its contents to git, not to the annex. If you tell git-annex what
+files are large, it will arrange for the large files to be added to the
+annex, and the small ones to be added to git. This is done by configuring
+annex.largefiles. See [[largefiles]] for full documentation of that.
+
+All the regular git-annex commands (find, get, drop, etc) can be used on
+unlocked files as well as locked files. When you drop the content of
+an unlocked file, it will be replaced by a pointer file, which
+looks like "/annex/objects/...". So if you open a file and see
+that, you'll need to use `git annex get`.
+
+Under the hood, unlocked files use git's smudge/clean filter interface,
+and git-annex converts between the content of the big file and a pointer
+file, which is what gets committed to git.
+
+[[!template id=note text="""
+By default, git-annex commands will add files in locked mode,
+unless used on a filesystem that does not support symlinks, when unlocked
+mode is used. To make them always use unlocked mode, run:
+`git config annex.addunlocked true`  
+`git add` always adds files in unlocked mode.
+"""]]
+
+## adjusted branches
+
+If you want to mostly keep files locked, but be able to locally switch
+to having them all unlocked, you can do so using `git annex adjust
+--unlock`. See [[git-annex-adjust]] for details. This is particularly
+useful when using filesystems like FAT, and OS's like Windows that don't
+support symlinks. Indeed, `git-annex init` detects such filesystems and
+automatically sets up a repository to use all unlocked files.
+
+## finding unlocked files
+
+While it's easy to see when a file is a git-annex symlink, unlocked files
+look the same as files stored in git. To see what files are unlocked or
+locked, many git-annex commands support `--unlocked` and `--locked`
+options.
+
+	git annex find --unlocked
+
+## imperfections
+
+Unlocked files mostly work very well, but there are a
+few imperfections which you should be aware of when using them.
+
+1. `git stash`, `git cherry-pick` and `git reset --hard` don't update
+   the working tree with the content of unlocked files. The files
+   will contain pointers, the same as if the content was not in the
+   repository. So after running these commands, you will need to manually
+   run `git annex smudge --update`.
+
+2. When git-annex is running a command that gets or drops the content
+   of an unlocked file, git's index will briefly be locked, which might
+   prevent you from running a `git commit` at the same time.
+
+3. Conversely, if you have a git commit in progress, running git-annex may
+   complain that the index is locked, though this will not prevent it from
+   working.
+
+4. When an operation such as a checkout or merge needs to update a large
+   number of unlocked files, it can become slow. So can be `git add` of
+   a large number of files (`git annex add` is faster).
+
+(The technical reasons behind these imperfections are explained in
+detail in [[todo/git_smudge_clean_interface_suboptiomal]].)
+
+## using less disk space
+
+Unlocked files are handy, but they have one significant disadvantage
+compared with locked files: On most filesystems, they use more disk space.
+
+While only one copy of a locked file has to be stored, often
+two copies of an unlocked file are stored on disk. One copy is in
+the git work tree, where you can use and modify it,
+and the other is stashed away in `.git/annex/objects` (see [[internals]]).
+
+The reason for that second copy is to preserve the old version of the file,
+when you modify the unlocked file in the work tree. Being able to access
+old versions of files is an important part of git after all!
+
+(Some filesystems including btrfs and xfs support reflinks, and on those,
+the extra copy is a reflink, and takes up no additional space.)
+
+So two copies is a good safe default. But there are ways to use git-annex that
+make the second copy not be worth keeping:
+
+* When you're using git-annex to sync the current version of files across
+  devices, and don't care much about previous versions.
+* When you have set up a backup repository, and use git-annex to copy
+  your files to the backup.
+
+In situations like these, you may want to avoid the overhead of the second
+local copy of unlocked files. There's a config setting for that.
+
+[[!template id=note text="""
+Note that setting annex.thin only has any effect on systems that support
+hard links. It is supported on Windows, but not on FAT filesystems.
+"""]]
+
+	git config annex.thin true
+
+After changing annex.thin, you'll want to fix up the work tree to
+match the new setting:
+
+	git annex fix
+
+[[!template id=note text="""
+When a [[direct_mode]] repository is upgraded, annex.thin is automatically
+set, because direct mode made the same single-copy tradeoff.
+"""]]
+
+Setting annex.thin can save a lot of disk space, but it's a tradeoff
+between disk usage and safety. 
+
+Keeping files locked is safer and also avoids using unnecessary
+disk space, but trades off easy modification of files.
+
+Pick the tradeoff that's right for you.
diff --git a/doc/tips/unlocked_files/comment_10_add35d419c7735571208aa5e47437f99._comment b/doc/tips/unlocked_files/comment_10_add35d419c7735571208aa5e47437f99._comment
new file mode 100644
index 0000000000..b756b204fd
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_10_add35d419c7735571208aa5e47437f99._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="meribold"
+ avatar="http://cdn.libravatar.org/avatar/54bd34d32b12aa20ebfa37c0ca05ed68"
+ subject="Re: Best solution to save disk space on exFAT"
+ date="2019-03-19T14:22:57Z"
+ content="""
+Oh, I guess `git annex sync` unlocks everything again.
+"""]]
diff --git a/doc/tips/unlocked_files/comment_11_08102655fbb13e4977e82f3f097f28db._comment b/doc/tips/unlocked_files/comment_11_08102655fbb13e4977e82f3f097f28db._comment
new file mode 100644
index 0000000000..5d1dc85baf
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_11_08102655fbb13e4977e82f3f097f28db._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="meribold"
+ avatar="http://cdn.libravatar.org/avatar/54bd34d32b12aa20ebfa37c0ca05ed68"
+ subject="Re: Best solution to save disk space on exFAT"
+ date="2019-03-19T14:32:29Z"
+ content="""
+Maybe using a bare repository is the way to go.
+"""]]
diff --git a/doc/tips/unlocked_files/comment_12_8cd7855dc6419297174a32e847e5f49a._comment b/doc/tips/unlocked_files/comment_12_8cd7855dc6419297174a32e847e5f49a._comment
new file mode 100644
index 0000000000..6e07cbacef
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_12_8cd7855dc6419297174a32e847e5f49a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="comment 12"
+ date="2019-03-21T22:59:38Z"
+ content="""
+Same problem here! I would love to have an alternative to annex.thin on FAT.
+"""]]
diff --git a/doc/tips/unlocked_files/comment_13_99f82c84aa9d886062aa3e3956e1acf8._comment b/doc/tips/unlocked_files/comment_13_99f82c84aa9d886062aa3e3956e1acf8._comment
new file mode 100644
index 0000000000..c4e2d4a1c6
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_13_99f82c84aa9d886062aa3e3956e1acf8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2019-03-22T13:31:52Z"
+ content="""
+[[todo/annex.thin_without_hardlinks]] is a tracking bug for annex.thin not
+working on FAT etc.
+"""]]
diff --git a/doc/tips/unlocked_files/comment_14_e3425d219001fc34470f0cd55fc7241e._comment b/doc/tips/unlocked_files/comment_14_e3425d219001fc34470f0cd55fc7241e._comment
new file mode 100644
index 0000000000..2d935ed62d
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_14_e3425d219001fc34470f0cd55fc7241e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="annex.thin without hardlinks  would be useful for non-crippled systems as well"
+ date="2019-03-25T18:57:36Z"
+ content="""
+One of the concerns with use of git-annex on HPC and other heavily loaded systems is the >3x consumption of inodes due to all the symlinks etc.  In some cases it could be completely avoided probably, if repository is instructed to be installed just for consumption (to access data) only.  In this way it would be nice if we could get the same \"annex.thin without hardlinks\" that there would not be even any `.git/annex/objects` (`superthin`?) and files just get installed in-place.
+"""]]
diff --git a/doc/tips/unlocked_files/comment_15_4be14df022612d6301442b3210a17d0a._comment b/doc/tips/unlocked_files/comment_15_4be14df022612d6301442b3210a17d0a._comment
new file mode 100644
index 0000000000..8b868d8d8c
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_15_4be14df022612d6301442b3210a17d0a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="rshalaev@3e2130a1e3cb0aaff7dd80aba7548ad9be0ea2d4"
+ nickname="rshalaev"
+ avatar="http://cdn.libravatar.org/avatar/d7f181d338cbcef7418faa01f0441e86"
+ subject="comment 15"
+ date="2020-12-03T01:43:00Z"
+ content="""
+Is where any way to make Git Annex use Windows 10 NTFS hardlinks in the working tree?
+
+Looking to conserve disk-space while still being able to browse and view files content. Currently Git Annex is doubling the ammount of disk space.
+"""]]
diff --git a/doc/tips/unlocked_files/comment_16_61121c6b95e1310df8132aca13924b88._comment b/doc/tips/unlocked_files/comment_16_61121c6b95e1310df8132aca13924b88._comment
new file mode 100644
index 0000000000..e5496b4244
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_16_61121c6b95e1310df8132aca13924b88._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 16"
+ date="2020-12-03T07:38:30Z"
+ content="""
+Yes, as the page above explains, `git config annex.thin true` and then `git annex fix`
+"""]]
diff --git a/doc/tips/unlocked_files/comment_17_15c6f8db289812e76859b21d158b1b2e._comment b/doc/tips/unlocked_files/comment_17_15c6f8db289812e76859b21d158b1b2e._comment
new file mode 100644
index 0000000000..882cdd1247
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_17_15c6f8db289812e76859b21d158b1b2e._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="rshalaev@3e2130a1e3cb0aaff7dd80aba7548ad9be0ea2d4"
+ nickname="rshalaev"
+ avatar="http://cdn.libravatar.org/avatar/d7f181d338cbcef7418faa01f0441e86"
+ subject="Windows 10 NTFS hardlinks not working"
+ date="2020-12-03T11:43:07Z"
+ content="""
+Lukey - I tried git config annex.thin true and then git annex fix
+
+Doing it on Windows NTFS drive did not create hard-links. I've followed the instructions. Could not get it to work. Always got copies of files instead of hardlinks. 
+
+From: -- Joey Hess <id@joeyh.name>  Mon, 18 Apr 2016 18:33:52 -0400
+git-annex (6.20160412) Changelog
+  * annex.thin and annex.hardlink are now supported on Windows.
+
+Based on Joey change log - hard links should work on NTFS. According to my obesrvation and a report from colin.brosseau above (titles \"NTFS Make it clear that it'll not work with annex.thin\") it does not work.
+
+Can anyone confirm if git annex can creates NTFS hardlinks? I can file a bug report if needed.
+
+Thanks!
+"""]]
diff --git a/doc/tips/unlocked_files/comment_1_29cef6b8e48e722fafed3fe9b7cefe08._comment b/doc/tips/unlocked_files/comment_1_29cef6b8e48e722fafed3fe9b7cefe08._comment
new file mode 100644
index 0000000000..9a0c6c990e
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_1_29cef6b8e48e722fafed3fe9b7cefe08._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ subject="usage changes"
+ date="2016-01-15T13:31:37Z"
+ content="""
+This sounds interesting. But OTOH I'm curious about upgrades from direct mode (which I assume will soon go away):
+
+If currently I just use `annex add; annex sync --content` on a media repo, would that change to `git add --all; git commit -m whatever; annex unlock *; annex sync --content`? That is, will v6 require the manual commit step?
+
+Also, when `annex get` or `annex sync` retrieve files from another repo, will there be an option to have the files unlocked by default, as in v5 direct mode?
+
+(I'm kinda hoping for `annex init --thin` or something similar to the v5 `annex direct`, as manually setting config options is easy to forget.)
+"""]]
diff --git a/doc/tips/unlocked_files/comment_2_54a1811ef2f57f0843e48572ab6713b8._comment b/doc/tips/unlocked_files/comment_2_54a1811ef2f57f0843e48572ab6713b8._comment
new file mode 100644
index 0000000000..83788d4794
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_2_54a1811ef2f57f0843e48572ab6713b8._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-01-15T19:07:24Z"
+ content="""
+Direct mode is not going away any time soon.
+
+`git add` adds the file to the annex in unlocked mode, and `git annex sync`
+commits any such adds the same as any other changes, so all you need is
+`git add --all; git annex sync --content`
+
+Whether a file is locked or unlocked is a property of the file, that gets
+committed to git, so when you commit some unlocked files, they'll be
+unlocked when they appear in other clones of the repository.
+"""]]
diff --git a/doc/tips/unlocked_files/comment_3_f5f29661bd04a6bba6158307465981d9._comment b/doc/tips/unlocked_files/comment_3_f5f29661bd04a6bba6158307465981d9._comment
new file mode 100644
index 0000000000..435afcdcfe
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_3_f5f29661bd04a6bba6158307465981d9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d"
+ nickname="wsha.code+ga"
+ subject="comment 3"
+ date="2016-01-16T13:03:26Z"
+ content="""
+1. If you want to save a committed version of a file, is there a way to do that, other than `sync`ing to a remote that does not have `annex.thin` set?
+2. If you `add` and `commit` a file multiple times in a repo without `sync`ing to a remote, what does the commit history look like on a remote when you do `sync` it? It just has several commits for which the file contents are not available?
+3. If you want to preserve history with `annex.thin` set, do you just have to `sync` manually after each commit? I guess you might want to set up a git commit hook to do that in that case.
+"""]]
diff --git a/doc/tips/unlocked_files/comment_4_a8139747da8cbb2510b3647ba448d72d._comment b/doc/tips/unlocked_files/comment_4_a8139747da8cbb2510b3647ba448d72d._comment
new file mode 100644
index 0000000000..2261ccdfb2
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_4_a8139747da8cbb2510b3647ba448d72d._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-01-20T18:49:07Z"
+ content="""
+@wsha.code, if you opt to use annex.thin, then commit a file, and then
+edit the same file again and commit again, the older commit will be in
+git's history, but if you check it out, the old content of the file won't
+be available. This is very similar to what happens when not using annex.thin,
+but later running git-annex unused and dropping the "unused" intermediate
+version of the file.
+
+Running `git annex sync --content` or just `git annex copy --to remote`
+will get the thin version of the file saved on a remote, and then editing
+it won't lose the content. But note that if you edited a file while it was
+being copied off to the remote, the previous version would still get lost.
+
+If these seem like troublesome behaviors, well that's why annex.thin is not
+enabled by default.
+"""]]
diff --git a/doc/tips/unlocked_files/comment_5_8225cb96640697d4955badfee5b75e39._comment b/doc/tips/unlocked_files/comment_5_8225cb96640697d4955badfee5b75e39._comment
new file mode 100644
index 0000000000..c3f227760b
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_5_8225cb96640697d4955badfee5b75e39._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="stefan.huchler@5f110ab85a15aec7e2b38586eb7ec37b12e2e6aa"
+ nickname="stefan.huchler"
+ avatar="http://cdn.libravatar.org/avatar/5c1baf041aa5516cb28a2618f7263a56"
+ subject="how to use normal rm to files directly?"
+ date="2016-11-04T21:04:56Z"
+ content="""
+My problem is following, I delete files from a directory over normal delete functionality. I expect this files than be really deleted, at least on that repos. so that the diskspace for it is free.
+
+I thought direct mode or now v6 with addunlocked setting is the solution to that. But either with thinmode there is a hardlink still there or without there is a copy in the directory.
+
+I would rather not have to use dropunused to get rid of that, it would be good if git annex sync or assist could just add this changes to the history. I dont care if that would be the last copy, that does not matter for me in that usecase.
+
+I want:
+
+1. access files (or hard links) not soft links
+2. only saved space 1 time per file
+3. deleted files give free the full space without usind drop-unused
+4. files should be added/deleted in that repos, not only transfered from somewhere else.
+
+Do I need therefor a special repos like web/directory/rsync or can I do that somehow with such a normal repos? as far as I understand even if I would use web with a directory as parameter it would not save the files normaly in that directory?
+"""]]
diff --git a/doc/tips/unlocked_files/comment_6_666d88b862a7f6f5cd719e454a8a6469._comment b/doc/tips/unlocked_files/comment_6_666d88b862a7f6f5cd719e454a8a6469._comment
new file mode 100644
index 0000000000..85918f352e
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_6_666d88b862a7f6f5cd719e454a8a6469._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="stefan.huchler@5f110ab85a15aec7e2b38586eb7ec37b12e2e6aa"
+ nickname="stefan.huchler"
+ avatar="http://cdn.libravatar.org/avatar/5c1baf041aa5516cb28a2618f7263a56"
+ subject="workaround to my request"
+ date="2016-11-05T14:53:36Z"
+ content="""
+I guess adding a hourly cronjob that drop all unused filed would be accaptable maybe?
+
+Or is there a better solution?
+"""]]
diff --git a/doc/tips/unlocked_files/comment_7_46ff6b142c4cc9ad07b0c8dc07ba9c09._comment b/doc/tips/unlocked_files/comment_7_46ff6b142c4cc9ad07b0c8dc07ba9c09._comment
new file mode 100644
index 0000000000..ce68d1cc0f
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_7_46ff6b142c4cc9ad07b0c8dc07ba9c09._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="colin.brosseau@d444b2b3412af38b85f7b4b340b9c44a412b5698"
+ nickname="colin.brosseau"
+ avatar="http://cdn.libravatar.org/avatar/23872b72fbb19f62ac611e9a80e27f29"
+ subject="NTFS Make it clear that it'll not work with annex.thin"
+ date="2019-01-03T18:04:58Z"
+ content="""
+On the doc it's said that
+
+\"Note that setting annex.thin only has any effect on systems that support hard links. It is supported on Windows, but not on FAT filesystems.\"
+
+Having read that, I was thinking that I'd be able to use _annex.thin_ with NTFS but it doesn't work. 
+I'd specify clearly that NTFS would also not work with _annex.thin_
+
+Thanks
+"""]]
diff --git a/doc/tips/unlocked_files/comment_8_9e5d1a9523239cb601612951af5eb9f1._comment b/doc/tips/unlocked_files/comment_8_9e5d1a9523239cb601612951af5eb9f1._comment
new file mode 100644
index 0000000000..13235ea927
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_8_9e5d1a9523239cb601612951af5eb9f1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tjbk123@277355c7f00c6df42e960e85caafa4b294872337"
+ nickname="tjbk123"
+ avatar="http://cdn.libravatar.org/avatar/8957c069e5030708a4c144b658437b49"
+ subject="Best solution to save disk space on exFAT"
+ date="2019-03-05T18:23:03Z"
+ content="""
+I see that `annex.thin` doesn't support FAT. What's the best option to save disk space when you *are* using FAT? I'm currently trying to put files that are more than 50% of a drive's size on that drive, with a v7 repository. Is that possible?
+"""]]
diff --git a/doc/tips/unlocked_files/comment_9_1cfd5f680f2d19ea1039ff0e7324083f._comment b/doc/tips/unlocked_files/comment_9_1cfd5f680f2d19ea1039ff0e7324083f._comment
new file mode 100644
index 0000000000..6002e7907a
--- /dev/null
+++ b/doc/tips/unlocked_files/comment_9_1cfd5f680f2d19ea1039ff0e7324083f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="meribold"
+ avatar="http://cdn.libravatar.org/avatar/54bd34d32b12aa20ebfa37c0ca05ed68"
+ subject="Re: Best solution to save disk space on exFAT"
+ date="2019-03-19T14:14:37Z"
+ content="""
+@tjbk123, I was wondering the same thing.  I think just locking all files works.
+"""]]
diff --git a/doc/tips/untrusted_repositories.mdwn b/doc/tips/untrusted_repositories.mdwn
new file mode 100644
index 0000000000..cdb5da7c3d
--- /dev/null
+++ b/doc/tips/untrusted_repositories.mdwn
@@ -0,0 +1,28 @@
+Suppose you have a USB thumb drive and are using it as a git annex
+repository. You don't trust the drive, because you could lose it, or
+accidentally run it through the laundry. Or, maybe you have a drive that
+you know is dying, and you'd like to be warned if there are any files
+on it not backed up somewhere else. Maybe the drive has already died
+or been lost.
+
+You can let git-annex know that you don't trust a repository, and it will
+adjust its behavior to avoid relying on that repositories's continued
+availability.
+	
+	# git annex untrust usbdrive
+	untrust usbdrive ok
+
+Now when you do a fsck, you'll be warned appropriately:
+
+	# git annex fsck .
+	fsck my_big_file
+	  Only these untrusted locations may have copies of this file!
+	  	05e296c4-2989-11e0-bf40-bad1535567fe  -- portable USB drive
+	  Back it up to trusted locations with git-annex copy.
+	failed
+
+Also, git-annex will refuse to drop a file from elsewhere just because
+it can see a copy on the untrusted repository.
+
+It's also possible to tell git-annex that you have an unusually high
+level of trust for a repository. See [[trust]] for details.
diff --git a/doc/tips/using_Amazon_Glacier.mdwn b/doc/tips/using_Amazon_Glacier.mdwn
new file mode 100644
index 0000000000..501f4d0059
--- /dev/null
+++ b/doc/tips/using_Amazon_Glacier.mdwn
@@ -0,0 +1,74 @@
+Amazon Glacier provides low-cost storage, well suited for archiving and
+backup. But it takes around 4 hours to get content out of Glacier.
+
+Recent versions of git-annex support Glacier. To use it, you need to have
+[glacier-cli](http://github.com/basak/glacier-cli) installed.
+
+First, export your Amazon AWS credentials:
+
+        # export AWS_ACCESS_KEY_ID="08TJMT99S3511WOZEP91"
+        # export AWS_SECRET_ACCESS_KEY="s3kr1t"
+
+Now, create a gpg key, if you don't already have one. This will be used
+to encrypt everything stored in Glacier, for your privacy. Once you have
+a gpg key, run `gpg --list-secret-keys` to look up its key id, something
+like "2512E3C7"
+
+Next, create the Glacier remote.
+
+	# git annex initremote glacier type=glacier keyid=2512E3C7
+	initremote glacier (encryption setup with gpg key C910D9222512E3C7) (gpg) ok
+
+The configuration for the Glacier remote is stored in git. So to make another
+repository use the same Glacier remote is easy:
+
+        # cd /media/usb/annex
+        # git pull laptop
+        # git annex enableremote glacier
+        initremote glacier (gpg) ok
+
+Now the remote can be used like any other remote.
+
+        # git annex move my_cool_big_file --to glacier
+        copy my_cool_big_file (gpg) (checking glacier...) (to glacier...) ok
+
+But, when you try to get a file out of Glacier, it'll queue a retrieval
+job:
+
+	# git annex get my_cool_big_file
+	get my_cool_big_file (from glacier...) (gpg)
+	glacier: queued retrieval job for archive 'GPGHMACSHA1--862afd4e67e3946587a9ef7fa5beb4e8f1aeb6b8'
+	  Recommend you wait up to 4 hours, and then run this command again.
+	failed
+
+Like it says, you'll need to run the command again later. Let's remember to
+do that:
+
+	# at now + 4 hours
+	at> git annex get my_cool_big_file
+
+Another oddity of Glacier is that git-annex is never entirely sure
+if a file is still in Glacier. Glacier inventories take hours to retrieve,
+and even when retrieved do not necessarily represent the current state.
+
+So, git-annex plays it safe, and avoids trusting the inventory:
+
+	# git annex copy important_file --to glacier
+	copy important_file (gpg) (checking glacier...) (to glacier...) ok
+	# git annex drop important_file
+	drop important_file (gpg) (checking glacier...)
+	  Glacier's inventory says it has a copy.
+	  However, the inventory could be out of date, if it was recently removed.
+	
+	(unsafe) 
+	  Could only verify the existence of 0 out of 1 necessary copies
+
+To avoid this problem, you can either use `git annex move` to move
+content to Glacier, or you can set the remote to be [[trusted]].
+
+A final potential gotcha with Glacier is that glacier-cli keeps a local
+mapping of file names to Glacier archives. If this cache is lost, or
+you want to retrieve files on a different box than the one that put them in
+glacier, you'll need to use `glacier vault sync` to rebuild this cache.
+
+See [[special_remotes/Glacier]] for details.
diff --git a/doc/tips/using_Amazon_Glacier/comment_1_ccee7f4f5a483a3650270b6e09ab7293._comment b/doc/tips/using_Amazon_Glacier/comment_1_ccee7f4f5a483a3650270b6e09ab7293._comment
new file mode 100644
index 0000000000..9d81d6bca8
--- /dev/null
+++ b/doc/tips/using_Amazon_Glacier/comment_1_ccee7f4f5a483a3650270b6e09ab7293._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="http://grossmeier.net/"
+ nickname="greg"
+ subject="missing steps?"
+ date="2014-02-18T23:51:00Z"
+ content="""
+I setup a glacier remote on one machine and it successfully created the vault and is syncing files to it.
+
+One another machine, after git-annex sync'ing, I did:
+
+
+[[!format sh \"\"\"
+greg@x200s:~/Photos$ git-annex enableremote glacier
+enableremote glacier 
+  Set both AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to use glacier
+git-annex: Failed creating glacier vault.
+\"\"\"]]
+
+So then I try:
+[[!format sh \"\"\"
+greg@x200s:~/Photos$ AWS_ACCESS_KEY_ID=HAHA AWS_SECRET_ACCESS_KEY=NOPE git-annex --debug enableremote glacier
+[2014-02-18 15:43:56 PST] read: git [\"--git-dir=/home/greg/Photos/.git\",\"--work-tree=/home/greg/Photos\",\"show-ref\",\"git-annex\"]
+[2014-02-18 15:43:56 PST] read: git [\"--git-dir=/home/greg/Photos/.git\",\"--work-tree=/home/greg/Photos\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-02-18 15:43:56 PST] read: git [\"--git-dir=/home/greg/Photos/.git\",\"--work-tree=/home/greg/Photos\",\"log\",\"refs/heads/git-annex..8108714116d08f93aa427b9ddced48cd5f2b4b72\",\"--oneline\",\"-n1\"]
+[2014-02-18 15:43:56 PST] read: git [\"--git-dir=/home/greg/Photos/.git\",\"--work-tree=/home/greg/Photos\",\"log\",\"refs/heads/git-annex..742ba908f791e440a6cc85073ef505a96dd66aa4\",\"--oneline\",\"-n1\"]
+[2014-02-18 15:43:56 PST] read: git [\"--git-dir=/home/greg/Photos/.git\",\"--work-tree=/home/greg/Photos\",\"log\",\"refs/heads/git-annex..071487394544a20253a70ada4ea71fcc28f9fc13\",\"--oneline\",\"-n1\"]
+[2014-02-18 15:43:56 PST] read: git [\"--git-dir=/home/greg/Photos/.git\",\"--work-tree=/home/greg/Photos\",\"log\",\"refs/heads/git-annex..c8aecc22da7b84bbb82f083ce783cc699cef1c67\",\"--oneline\",\"-n1\"]
+[2014-02-18 15:43:56 PST] chat: git [\"--git-dir=/home/greg/Photos/.git\",\"--work-tree=/home/greg/Photos\",\"cat-file\",\"--batch\"]
+enableremote glacier [2014-02-18 15:43:56 PST] call: glacier [\"--region=us-west-2\",\"vault\",\"create\",\"glacier-7e5c0010-2634-4a5e-bc7b-6fea84b8b947\"]
+git-annex: Failed creating glacier vault.
+\"\"\"]]
+
+What am I missing?
+
+Also, why is it trying to *create* the valut? It's already there with content in it!
+"""]]
diff --git a/doc/tips/using_Amazon_Glacier/comment_2_d34e05f9244d3a4fcec87b3c360adb4e._comment b/doc/tips/using_Amazon_Glacier/comment_2_d34e05f9244d3a4fcec87b3c360adb4e._comment
new file mode 100644
index 0000000000..ed482906b9
--- /dev/null
+++ b/doc/tips/using_Amazon_Glacier/comment_2_d34e05f9244d3a4fcec87b3c360adb4e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 2"
+ date="2014-02-20T19:24:09Z"
+ content="""
+@greg, the only thing you might have missed is the need to use `glacier vault sync` to build a cache if enabling the glacier remote in another place. And that whole issue with it needing a local cache may mean few people are using glacier with more than one repository accessing the remote.
+
+However, this sounds like a bug. There is a comment in the source code that \"glacier vault create will succeed even if the vault already exists.\" .. perhaps it has changed since that was written. Or perhaps the command failed for some other reason, I don't know.
+"""]]
diff --git a/doc/tips/using_Amazon_Glacier/comment_3_4c504fd22775afe36296cf54d3e04a8e._comment b/doc/tips/using_Amazon_Glacier/comment_3_4c504fd22775afe36296cf54d3e04a8e._comment
new file mode 100644
index 0000000000..a8c765bcbf
--- /dev/null
+++ b/doc/tips/using_Amazon_Glacier/comment_3_4c504fd22775afe36296cf54d3e04a8e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 3"
+ date="2014-02-20T19:34:48Z"
+ content="""
+I've changed it to avoid running glacier value create when enabling an existing glacier remote. Hopefully that fixes it.
+"""]]
diff --git a/doc/tips/using_Amazon_Glacier/comment_4_e6ac76b0c20285f4f96b3d0975e8ac66._comment b/doc/tips/using_Amazon_Glacier/comment_4_e6ac76b0c20285f4f96b3d0975e8ac66._comment
new file mode 100644
index 0000000000..47fa6868ff
--- /dev/null
+++ b/doc/tips/using_Amazon_Glacier/comment_4_e6ac76b0c20285f4f96b3d0975e8ac66._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="http://grossmeier.net/"
+ nickname="greg"
+ subject="comment 4"
+ date="2014-02-20T22:04:58Z"
+ content="""
+Along with stupid python problems which are now fixed (all my fault, and hopefully didn't cause more noise here than needed), the only thing that didn't go as stated was:
+
+[[!format sh \"\"\"
+greg@x200s:~/Photos$ git-annex enableremote glacier
+enableremote glacier 
+  Set both AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to use glacier
+git-annex: Failed creating glacier vault.
+greg@x200s:~/Photos$ AWS_ACCESS_KEY_ID=lolno AWS_SECRET_ACCESS_KEY=lolno git-annex enableremote glacier
+enableremote glacier ok
+(Recording state in git...)
+greg@x200s:~/Photos$ 
+\"\"\"]]
+
+The guide says that info is sync'd.
+"""]]
diff --git a/doc/tips/using_Amazon_Glacier/comment_5_7788890f58f714b0cdf1462c718ea536._comment b/doc/tips/using_Amazon_Glacier/comment_5_7788890f58f714b0cdf1462c718ea536._comment
new file mode 100644
index 0000000000..5e0e6c716b
--- /dev/null
+++ b/doc/tips/using_Amazon_Glacier/comment_5_7788890f58f714b0cdf1462c718ea536._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="good"
+ date="2014-02-21T15:20:39Z"
+ content="""
+If you mean the creds are not remembered, that's controlled by the embedcreds= option to initremote, and it only defaults to embedding them for gacier when using strong encryption (not encryption=shared).
+"""]]
diff --git a/doc/tips/using_Amazon_Glacier/comment_6_0fbe528a57552622e8128196ad80c863._comment b/doc/tips/using_Amazon_Glacier/comment_6_0fbe528a57552622e8128196ad80c863._comment
new file mode 100644
index 0000000000..65128b72cd
--- /dev/null
+++ b/doc/tips/using_Amazon_Glacier/comment_6_0fbe528a57552622e8128196ad80c863._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://grossmeier.net/"
+ nickname="greg"
+ subject="confirmed"
+ date="2014-02-21T17:53:02Z"
+ content="""
+Yeah, I choose no encryption for this one for worst case scenario reasons (I still want photos of my kid even if I loss my gpg key and my house burns down). Now about setting up http://git.kitenet.net/?p=gpg.git;a=blob;f=README.sss;hb=HEAD ......
+"""]]
diff --git a/doc/tips/using_Amazon_Glacier/comment_7_a83cfe55f4c70bd8801e0c05c5be8323._comment b/doc/tips/using_Amazon_Glacier/comment_7_a83cfe55f4c70bd8801e0c05c5be8323._comment
new file mode 100644
index 0000000000..8b7fc85452
--- /dev/null
+++ b/doc/tips/using_Amazon_Glacier/comment_7_a83cfe55f4c70bd8801e0c05c5be8323._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="ben"
+ subject="Problems initializing glacier remote"
+ date="2015-12-08T10:39:30Z"
+ content="""
+Hi, when I try to create a glacier remote, the command freezes without further output:
+
+    $ git init
+    $ git annex init
+    $ git annex initremote glacier type=glacier keyid=xxxxxxxx
+    initremote glacier (encryption setup)
+
+I can see the following processes in sleep state:
+
+
+    11438 pts/0    S+     0:00 git --git-dir=/home/b/Documents/annex/.git --work-tree=/home/b/Documents/annex cat-file --batch
+    11440 pts/0    SL+    0:00 gpg2 --batch --no-tty --use-agent --quiet --trust-model always --gen-random --armor 2 512
+
+I'm on fedora 22, git-annex version: 5.20140717. Any suggestions appreciated, thanks!
+
+
+"""]]
diff --git a/doc/tips/using_Amazon_Glacier/comment_8_ddef6cc5d1a5fd3d69cfe8cccfa58a53._comment b/doc/tips/using_Amazon_Glacier/comment_8_ddef6cc5d1a5fd3d69cfe8cccfa58a53._comment
new file mode 100644
index 0000000000..5fd6832aa6
--- /dev/null
+++ b/doc/tips/using_Amazon_Glacier/comment_8_ddef6cc5d1a5fd3d69cfe8cccfa58a53._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2015-12-08T15:12:59Z"
+ content="""
+@ben, it's generating the encryption key, and is blocked waiting on enropy.
+You can pass --fast to use lower-quality randomness.
+"""]]
diff --git a/doc/tips/using_Amazon_S3.mdwn b/doc/tips/using_Amazon_S3.mdwn
new file mode 100644
index 0000000000..90512dfe66
--- /dev/null
+++ b/doc/tips/using_Amazon_S3.mdwn
@@ -0,0 +1,43 @@
+git-annex extends git's usual remotes with some [[special_remotes]], that
+are not git repositories. This way you can set up a remote using say,
+Amazon S3, and use git-annex to transfer files into the cloud.
+
+First, export your Amazon AWS credentials:
+
+	# export AWS_ACCESS_KEY_ID="08TJMT99S3511WOZEP91"
+	# export AWS_SECRET_ACCESS_KEY="s3kr1t"
+
+Now, create a gpg key, if you don't already have one. This will be used
+to encrypt everything stored in S3, for your privacy. Once you have
+a gpg key, run `gpg --list-secret-keys` to look up its key id, something
+like "2512E3C7"
+
+Next, create the S3 remote, and describe it. 
+
+	# git annex initremote cloud type=S3 chunk=1MiB keyid=2512E3C7
+	initremote cloud (encryption setup with gpg key C910D9222512E3C7) (checking bucket) (creating bucket in US) (gpg) ok
+	# git annex describe cloud "at Amazon's US datacenter"
+	describe cloud ok
+
+The configuration for the S3 remote is stored in git. So to make another
+repository use the same S3 remote is easy:
+
+	# export AWS_ACCESS_KEY_ID="08TJMT99S3511WOZEP91"
+	# export AWS_SECRET_ACCESS_KEY="s3kr1t"
+	# git pull laptop
+	# git annex enableremote cloud
+	enableremote cloud (gpg) (checking bucket) ok
+
+Notice that to enable an existing S3 remote, you have to provide the Amazon
+AWS credentials because they were not stored in the repository. (It is
+possible to configure git-annex to do that, but not the default.)
+
+## further reading
+
+See [[special_remotes/S3]] for details about configuring S3 remotes.
+
+See [[public_Amazon_S3_remote]] for how to set up a Amazon S3 remote that
+can be used by the public, without them needing AWS credentials.
+
+If you want to publish files to S3 so they can be accessed without using
+git-annex, see [[publishing_your_files_to_the_public]].
diff --git a/doc/tips/using_Amazon_S3/comment_10_43f3f12a83e3ace1674eae395b865409._comment b/doc/tips/using_Amazon_S3/comment_10_43f3f12a83e3ace1674eae395b865409._comment
new file mode 100644
index 0000000000..fa306212f6
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_10_43f3f12a83e3ace1674eae395b865409._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkPIqJZ88VZEVqLhLOd1LMdYXcy6bAW9qE"
+ nickname="Lemao"
+ subject="comment 10"
+ date="2015-01-07T23:53:32Z"
+ content="""
+My bad. I didn't realize git annex creates a new branch. After I pushed it, the clone was able to enableremote and I was able to get the file.
+
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_11_70b4e62aabb93d078811cbdcd3cced20._comment b/doc/tips/using_Amazon_S3/comment_11_70b4e62aabb93d078811cbdcd3cced20._comment
new file mode 100644
index 0000000000..6789086862
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_11_70b4e62aabb93d078811cbdcd3cced20._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn8d6WBPNtmyeANT-gjlN19QnCTQ0psRPs"
+ nickname="James"
+ subject="comment 11"
+ date="2015-01-22T22:16:46Z"
+ content="""
+Even after enableremote I can't get from s3.
+
+
+	get Docs.zip (from s3...)
+
+	  Unable to access these remotes: s3
+
+	  Try making some of these repositories available:
+	  	02b4e373-02b1-42b9-8285-c353c047895c -- my laptop
+	   	f287b4f7-4e5a-4734-bd6b-62b1f4498838 -- [s3]
+
+	  (Note that these git remotes have annex-ignore set: origin)
+	failed
+	git-annex: get: 1 failed
+
+
+This is after all branches are pushed from my original repo. Any suggestions?
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_12_d00472bf4ac5f7b2212073c081ba04c2._comment b/doc/tips/using_Amazon_S3/comment_12_d00472bf4ac5f7b2212073c081ba04c2._comment
new file mode 100644
index 0000000000..9494e118fe
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_12_d00472bf4ac5f7b2212073c081ba04c2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn8d6WBPNtmyeANT-gjlN19QnCTQ0psRPs"
+ nickname="James"
+ subject="RE: last comment"
+ date="2015-01-23T01:02:18Z"
+ content="""
+RE: my last comment
+
+The reason I couldn't get it to work is because I didn't have proper read access to the bucket. My bad for not checking first but it would be great it there was a clearer error message from git-annex and/or a way to get more detailed information on the s3 extension (-d doesn't do much).
+
+Regardless git-annex is pretty cool, thanks to all the maintainers for their hard work.
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_13_30bdbd217fd2b603984cf7d3a3dce266._comment b/doc/tips/using_Amazon_S3/comment_13_30bdbd217fd2b603984cf7d3a3dce266._comment
new file mode 100644
index 0000000000..60e3c49fc2
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_13_30bdbd217fd2b603984cf7d3a3dce266._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="james@2468840dc8f314e837e1fde99a5fb1b884fa993a"
+ nickname="james"
+ subject="enable s3 remote on clone"
+ date="2015-07-03T14:46:49Z"
+ content="""
+Hi,
+I am trying to enable access to my s3 area from a clone. I am running into this issue:
+
+~~~
+$ git annex enableremote mys3 
+enableremote mys3 (encryption update) (hybrid cipher with gpg key EA1CF14BD8467AFB) (gpg) gpg: decryption failed: secret key not available
+
+git-annex: user error (gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"] exited 2)
+failed
+git-annex: enableremote: 1 failed
+~~~
+
+
+My gpg key is available :
+
+~~~
+$ gpg -K EA1CF14BD8467AFB
+sec   4096R/D8467AFB 2010-10-25
+uid                  James Richardson (email) <james@jamestechnotes.com>
+uid                  James Richardson <james.richardson.jr@gmail.com>
+uid       [ revoked] James Richardson (list) <jr@jamesr.biz>
+uid       [ revoked] James Richardson (James Richardson) <james@jamesr.biz>
+ssb   4096R/F90CF7F0 2010-10-25
+ssb   4096R/005D609B 2010-10-26
+~~~
+
+I would expect this to pop up a dialog asking me for my passphrase, as it will when I run the gpg command from a term.
+
+Any ideas?
+
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_14_5bb12e6fa51da00ecf48f2dee1bfb050._comment b/doc/tips/using_Amazon_S3/comment_14_5bb12e6fa51da00ecf48f2dee1bfb050._comment
new file mode 100644
index 0000000000..3d99cca80a
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_14_5bb12e6fa51da00ecf48f2dee1bfb050._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2015-07-06T17:42:28Z"
+ content="""
+@james, since your keyring apparenty contains your secret key, the problem
+may be in the configuration of your gpg agent or pinentry program. If the agent 
+is unable to use pinentry for some reason, gpg will complain that the
+secret key is unavailable since it is unable to get the passphrase to
+unlock it.
+
+I had a similar problem with gpg2 the other day:
+<http://bugs.debian.org/791379>
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_15_d8cc20706debc17f4f738d2019577dea._comment b/doc/tips/using_Amazon_S3/comment_15_d8cc20706debc17f4f738d2019577dea._comment
new file mode 100644
index 0000000000..1bc4ed8669
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_15_d8cc20706debc17f4f738d2019577dea._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="NathanCollins"
+ avatar="http://cdn.libravatar.org/avatar/8354544a22bb5a0ac8005ca008f94ad1"
+ subject="The initremote command appears to hang due to low entropy"
+ date="2017-09-10T02:32:26Z"
+ content="""
+For me, the `git annex initremote amazon-s3 encryption=shared embedcreds=yes` [1] command hung for several minutes after printing
+
+    initremote amazon-s3 (encryption setup)
+
+Turns out the problem was that I was low on entropy. Figured this out by running
+
+    gpg --gen-random 2
+
+per [this bug comment](https://github.com/DanielDent/git-annex-remote-rclone/issues/6#issuecomment-231347642). According to [this blog post](https://delightlylinux.wordpress.com/2015/07/01/is-gpg-hanging-when-generating-a-key/) a solution is to
+
+    sudo aptitude install rng-tools
+    sudo rngd -r /dev/urandom
+
+The `git annex initremote` command had finished by the time I found that solution, but I verified that it made `gpg --gen-random 2` work.
+
+System: Ubuntu 16.04 with Git Annex 5.20151208-1build1 installed via package manager.
+
+[1] I'm using AWS credentials that are restricted to a specific bucket, so I'm not worried about the conjunction `encryption=shared` and `embedcreds=yes`.
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_16_bb2cb128d9c6a8e9176604cef1f6fc91._comment b/doc/tips/using_Amazon_S3/comment_16_bb2cb128d9c6a8e9176604cef1f6fc91._comment
new file mode 100644
index 0000000000..708a25e637
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_16_bb2cb128d9c6a8e9176604cef1f6fc91._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2017-09-29T17:45:59Z"
+ content="""
+You can also use the --fast option to make git-annex use less entropy
+when generating the encryption key. That's a little less secure, but
+probably still secure enough.
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_1_666a26f95024760c99c627eed37b1966._comment b/doc/tips/using_Amazon_S3/comment_1_666a26f95024760c99c627eed37b1966._comment
new file mode 100644
index 0000000000..60d96cb44e
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_1_666a26f95024760c99c627eed37b1966._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnoUOqs_lbuWyZBqyU6unHgUduJwDDgiKY"
+ nickname="Matt"
+ subject="ANNEX_S3 vs AWS for keys"
+ date="2012-05-29T12:24:25Z"
+ content="""
+The instructions state ANNEX_S3_ACCESS_KEY_ID and ANNEX_SECRET_ACCESS_KEY but git-annex cannot connect with those constants. git-annex tells me to set both \"AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY\" instead, which works. This is with Xubuntu 12.04.
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_2_f5a0883be7dbb421b584c6dc0165f1ef._comment b/doc/tips/using_Amazon_S3/comment_2_f5a0883be7dbb421b584c6dc0165f1ef._comment
new file mode 100644
index 0000000000..dc809cb126
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_2_f5a0883be7dbb421b584c6dc0165f1ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.81.112"
+ subject="comment 2"
+ date="2012-05-29T19:10:42Z"
+ content="""
+Thanks, I've fixed that. (You could have too.. this is a wiki ;)
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_3_32acba030c2ad252e2f7027075e4303e._comment b/doc/tips/using_Amazon_S3/comment_3_32acba030c2ad252e2f7027075e4303e._comment
new file mode 100644
index 0000000000..e83ade0c74
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_3_32acba030c2ad252e2f7027075e4303e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="annexuser"
+ ip="64.71.7.82"
+ subject="Altering AWS credentials"
+ date="2014-04-15T21:59:43Z"
+ content="""
+If I revoke old AWS credentials and create new ones, how would I inform git-annex of the change to `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`?
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_4_92df5a9f923beafba55a1c455728112e._comment b/doc/tips/using_Amazon_S3/comment_4_92df5a9f923beafba55a1c455728112e._comment
new file mode 100644
index 0000000000..5bcf34b74d
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_4_92df5a9f923beafba55a1c455728112e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 4"
+ date="2014-04-17T19:44:55Z"
+ content="""
+You can use `git annex enableremote` to change an existing remote's configuration. So this should work:
+
+    # export AWS_ACCESS_KEY_ID=\"newRANDOMGOBBLDEYGOOK\"
+    # export AWS_SECRET_ACCESS_KEY=\"news3kr1t\"
+    # git annex enableremote cloud
+
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_5_6b288e06010bedbb71e0afed6b427704._comment b/doc/tips/using_Amazon_S3/comment_5_6b288e06010bedbb71e0afed6b427704._comment
new file mode 100644
index 0000000000..320a09d63d
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_5_6b288e06010bedbb71e0afed6b427704._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkmN2ZZIdYNiFKmEH7rz4jMb6sYsx_dptA"
+ nickname="Jack William"
+ subject="What if you do not want to encrypt?"
+ date="2014-09-07T18:35:19Z"
+ content="""
+Once use case for GIT with Amazon S3 is to maintain a web site on S3 you can easily update from a local machine. In that case you would not want to encrypt. Is encryption optional? This isn't clear from the instructions.
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_6_3b6c74b40ea666389ac04b52ab0819a0._comment b/doc/tips/using_Amazon_S3/comment_6_3b6c74b40ea666389ac04b52ab0819a0._comment
new file mode 100644
index 0000000000..0fce69dad8
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_6_3b6c74b40ea666389ac04b52ab0819a0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://schnouki.net/"
+ nickname="Schnouki"
+ subject="comment 6"
+ date="2014-09-09T12:48:59Z"
+ content="""
+Jack, if you don't want to use encryption you can use `encryption=none` as documented [here](http://git-annex.branchable.com/special_remotes/S3/).
+
+I'm not sure exactly what you're trying to do, but please note that you files won't be easily available on S3: they will be named as git-annex keys, with long and unreadable names such as \"SHA256E-s6311--c7533fdd259d872793b7298cbb56a1912e80c52a845661b0b9ff391c65ee2abc.html\" instead of \"index.html\".
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_7_cf6755d88463878f2ea6e4c300899027._comment b/doc/tips/using_Amazon_S3/comment_7_cf6755d88463878f2ea6e4c300899027._comment
new file mode 100644
index 0000000000..3c7b817f72
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_7_cf6755d88463878f2ea6e4c300899027._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmH7o6q2l99M-PQolOfbR3_i5B_jtTIcAE"
+ nickname="Giovanni"
+ subject="How to publish your files to the public"
+ date="2014-09-13T15:29:18Z"
+ content="""
+I don't know if this is what Jack wanted, but you can upload your files to S3 and let them be accessible through a public URL.
+
+First, go to (or create) the bucket you will use at [S3](https://console.aws.amazon.com/s3/) and add a public get policy to it:
+
+```
+   {
+    	\"Version\": \"2008-10-17\",
+    	\"Statement\": [
+    		{
+    			\"Sid\": \"AllowPublicRead\",
+    			\"Effect\": \"Allow\",
+    			\"Principal\": {
+    				\"AWS\": \"*\"
+    			},
+    			\"Action\": \"s3:GetObject\",
+    			\"Resource\": \"arn:aws:s3:::BUCKETNAME/*\"
+    		}
+    	]
+    }
+```
+
+Then set up your special remote with the options `encryption=none`, `bucket='BUCKETNAME'` `chunk=0` (and any others you want).
+
+Your files will be accessible through `http://BUCKETNAME.s3-website-LOCATION.amazonaws.com/KEY` where location is the one specified through the options `datacenter` and KEY is the SHA-SOMETHING hash of the file, created by git annex and accessible if you run `git annex lookupkey FILEPATH`.
+
+This way you can share a link to each file you have at your S3 remote.
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_8_4f9c2f6627f8ed3423bcc8b7bf2f76cb._comment b/doc/tips/using_Amazon_S3/comment_8_4f9c2f6627f8ed3423bcc8b7bf2f76cb._comment
new file mode 100644
index 0000000000..0616e0c87e
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_8_4f9c2f6627f8ed3423bcc8b7bf2f76cb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkPIqJZ88VZEVqLhLOd1LMdYXcy6bAW9qE"
+ nickname="Lemao"
+ subject="comment 8"
+ date="2015-01-07T13:54:23Z"
+ content="""
+I use github as my central git repository and I would like to use S3 to store large files with annex. Since the s3 remote in .git/config is not stored in github, how do I make sure I reconnect to the same s3 bucket in case I delete my local clone? Reinitializing the remote will create a completely new bucket.
+
+I would also be a good idea to centralize git-annex folders inside a single bucket so I keep the global namespace under control and can narrow down the permissioning.
+"""]]
diff --git a/doc/tips/using_Amazon_S3/comment_9_47e4ea77d0262d332d86a06d7aaeddd8._comment b/doc/tips/using_Amazon_S3/comment_9_47e4ea77d0262d332d86a06d7aaeddd8._comment
new file mode 100644
index 0000000000..277e1c02b2
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_9_47e4ea77d0262d332d86a06d7aaeddd8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 9"
+ date="2015-01-07T17:25:43Z"
+ content="""
+Lemao, make sure you have pushed your git-annex branch to your central git repository.
+
+When you clone that repo elsewhere, you can add the S3 remote by running `git annex enableremote cloud` (replace \"cloud\" with whatever name you originally picked when you used `git annex initremote` to set up the S3 remote in the first place.
+
+git-annex stores the necessary configuration of the S3 remote on the git-annex branch.
+"""]]
diff --git a/doc/tips/using_Backblaze_B2.mdwn b/doc/tips/using_Backblaze_B2.mdwn
new file mode 100644
index 0000000000..2669876cc6
--- /dev/null
+++ b/doc/tips/using_Backblaze_B2.mdwn
@@ -0,0 +1,25 @@
+For using Backblaze B2 as a special remote, there are currently three
+choices:
+
+* Using [[special_remotes/rclone]]  
+  (Actively maintained)
+
+* Backblaze B2 supports supports the same API as Amazon S3, so
+  git-annex's built-in [[S3 special remote|special_remotes/S3]] can be used
+  with it. 
+
+  However, it needs S3 version 4 signatures, which are only supported by
+  git-annex 8.20200508 and newer.
+
+  Here is how to set up the special remote:
+
+        git annex initremote backblaze type=S3 signature=v4 host=$endpoint bucket=$bucketid protocol=https
+
+  Remember to replace $endpoint with the actual backblaze endpoint and $bucketid with
+  the bucketid.
+
+* A dedicated special remote, <https://github.com/encryptio/git-annex-remote-b2>  
+  (Last updated 2016)
+
+At this time it's not clear which is better, so if you find one works
+better than the other, please comment below.
diff --git a/doc/tips/using_Backblaze_B2/comment_1_b8b045d5f3d2bed1905c05b4fa00c5ca._comment b/doc/tips/using_Backblaze_B2/comment_1_b8b045d5f3d2bed1905c05b4fa00c5ca._comment
new file mode 100644
index 0000000000..48d60f7ffd
--- /dev/null
+++ b/doc/tips/using_Backblaze_B2/comment_1_b8b045d5f3d2bed1905c05b4fa00c5ca._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="emi@f69ad15b49bfecb4ea3836b6480e5ab8df9a5f7d"
+ nickname="emi"
+ avatar="http://cdn.libravatar.org/avatar/84bf8bb9fcad258f264f28740d91981e"
+ subject="Rclone B2 vs S3"
+ date="2023-10-15T15:03:18Z"
+ content="""
+ I've been using the rclone B2 special remote for a while now, and it seems to produce a very large number of Class C (the most expensive class) transactions while performing certain operations (uploads & dropunused, at least). I just started using the S3 special remote today, and while I've only uploaded so far, it seems to produce far fewer Class C transactions (after uploading a pretty large number of files, I'm only seeing 13). If cost is a concern, that might be one reason to prefer the S3 special remote. That said, this is mostly anecdotal. Perhaps someone else might chip in empirical data or check out the code to back up these observations. 
+"""]]
diff --git a/doc/tips/using_Backblaze_B2/comment_2_d7fd727cb38a0290de10f06539a23d27._comment b/doc/tips/using_Backblaze_B2/comment_2_d7fd727cb38a0290de10f06539a23d27._comment
new file mode 100644
index 0000000000..2cc81b7689
--- /dev/null
+++ b/doc/tips/using_Backblaze_B2/comment_2_d7fd727cb38a0290de10f06539a23d27._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="aaa"
+ avatar="http://cdn.libravatar.org/avatar/df34e736d4a63a5c29e8bd513ed719ca"
+ subject="Key permissions"
+ date="2023-12-12T22:29:24Z"
+ content="""
+I tried to use Backblaze B2 using the second method, and tried different application key permissions. Hopefully I can save your time if you’re going to use this special remote.
+
+In order to init a B2 remote, you should create a key with the ability to read & write all buckets, and you must create a new bucket using git-annex (by setting a unique name in `bucket=`). If you create an empty bucket using Backblaze's web UI, then use that bucket for `git annex initremote`, you will receive this error message: `(InternalException (HandshakeFailed (Error_Protocol (\"expecting server hello, got alert : [(AlertLevel_Fatal,IllegalParameter)]\",True,HandshakeFailure))))`.
+
+In order to enable a B2 remote, you need a key with read & write permission to the bucket you're using. If you created a key with only read permission, you can’t use `git annex get` on that remote.
+"""]]
diff --git a/doc/tips/using_Google_Cloud_Storage.mdwn b/doc/tips/using_Google_Cloud_Storage.mdwn
new file mode 100644
index 0000000000..62c939130e
--- /dev/null
+++ b/doc/tips/using_Google_Cloud_Storage.mdwn
@@ -0,0 +1,19 @@
+For using [Google Cloud Storage](https://cloud.google.com/products/cloud-storage)
+as a special remote, there are currently three choices:
+
+* Google Cloud Storage supports supports the same API as Amazon S3, so
+  git-annex's built-in [[S3 special remote|special_remotes/S3]] can be used
+  with it. You may need to configure Google Cloud Storage to allow
+  "Interoperable Access". Here is how to set up the special remote:
+
+	git annex initremote cloud type=S3 encryption=none host=storage.googleapis.com port=80
+
+* Alternatively, rclone supports Google Cloud Storage's native API,
+  so the [[rclone_special_remote|special_remotes/rclone]] can be used.
+
+* Alternatively, there is a dedicated special remote,
+  <https://github.com/bgilbert/gcsannex>  
+  (Last updated 2016)
+
+At this time it's not clear which is better, so if you find one works
+best, please comment below.
diff --git a/doc/tips/using_Google_Cloud_Storage/comment_1_c576182f39563ae68767391c4227a177._comment b/doc/tips/using_Google_Cloud_Storage/comment_1_c576182f39563ae68767391c4227a177._comment
new file mode 100644
index 0000000000..3a4d02f327
--- /dev/null
+++ b/doc/tips/using_Google_Cloud_Storage/comment_1_c576182f39563ae68767391c4227a177._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="AWS credentials"
+ date="2013-05-31T10:23:23Z"
+ content="""
+This looks very valuable - Google are offering a free 5GB up until 2013 June 30th
+
+Sign in here[1] get your credentials here[2] under the section “Interoperable Access” (Source[3])
+
+    # Set up AWS credentials
+    $ export AWS_ACCESS_KEY_ID=\"YOUR-KEY\"
+    $ export AWS_SECRET_ACCESS_KEY=\"YOUR-SECRET\"
+
+1. http://gs-signup-redirect.appspot.com/ -or- https://developers.google.com/storage/docs/signup
+2. https://storage.cloud.google.com/m
+3. http://fog.io/storage/
+"""]]
diff --git a/doc/tips/using_Google_Cloud_Storage/comment_2_0843bfb776b8b6d5de4de7fda4489f34._comment b/doc/tips/using_Google_Cloud_Storage/comment_2_0843bfb776b8b6d5de4de7fda4489f34._comment
new file mode 100644
index 0000000000..5a888348ec
--- /dev/null
+++ b/doc/tips/using_Google_Cloud_Storage/comment_2_0843bfb776b8b6d5de4de7fda4489f34._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlPfB0_GcGJ827kZqRE1PF4D23rxpfOeg4"
+ nickname="Björn"
+ subject="Can't find developer API key and secret"
+ date="2014-06-01T21:25:54Z"
+ content="""
+According to the last comment, and this page:
+* https://developers.google.com/storage/docs/migrating#keys
+
+there's supposed to be a \"Interoperable Access\" menu option, something I can't find. Note that both the previous comment and this page refers to Googles old Developer Console.
+
+I can find a few things under \"APIs and Auth\" => \"Credentials\" under the heading \"Public API access\", but no matter what kind of key I try to create I can't get anything other than an API key. No secrets here, and no \"Show\"-button for newly created keys.
+
+Another thing worth mentioning is that these API keys I'm seeing do not like described in that first link in this comment. It's much longer, contains both upper- and lowercase and also contains dashes.
+"""]]
diff --git a/doc/tips/using_Google_Cloud_Storage/comment_3_9738f145014d8eae1f1aae7c39e71d31._comment b/doc/tips/using_Google_Cloud_Storage/comment_3_9738f145014d8eae1f1aae7c39e71d31._comment
new file mode 100644
index 0000000000..cd8caecc77
--- /dev/null
+++ b/doc/tips/using_Google_Cloud_Storage/comment_3_9738f145014d8eae1f1aae7c39e71d31._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlPfB0_GcGJ827kZqRE1PF4D23rxpfOeg4"
+ nickname="Björn"
+ subject="comment 3"
+ date="2014-06-17T19:18:09Z"
+ content="""
+I just found the \"Interoperable access\" thing. The instructions from Google (linked in previous comments) are not perfect.
+
+After step 4 click \"Google Cloud Storage\", then at the bottom you have a heading called \"Interoperable Access\" where you have to activate it for this project.
+
+Then it appears at the bottom of the left hand menu.
+"""]]
diff --git a/doc/tips/using_Google_Cloud_Storage/comment_4_63f29692ef270cd4a196ec94ff97185a._comment b/doc/tips/using_Google_Cloud_Storage/comment_4_63f29692ef270cd4a196ec94ff97185a._comment
new file mode 100644
index 0000000000..59f63afb11
--- /dev/null
+++ b/doc/tips/using_Google_Cloud_Storage/comment_4_63f29692ef270cd4a196ec94ff97185a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="bgilbert@a0c64716cf22216de5eeb15a5ca4f009164c8fb3"
+ nickname="bgilbert"
+ subject="External special remote"
+ date="2015-08-09T22:59:16Z"
+ content="""
+I've written [an external special remote](https://github.com/bgilbert/gcsannex) for Google Cloud Storage using Google's Python bindings to the native JSON API.  The special remote supports all storage classes, including Nearline, and doesn't require Interoperable Access to be enabled.  Feedback welcome.
+"""]]
diff --git a/doc/tips/using_Google_Cloud_Storage/comment_5_865f27a393f24fd5723c895d4d70dde3._comment b/doc/tips/using_Google_Cloud_Storage/comment_5_865f27a393f24fd5723c895d4d70dde3._comment
new file mode 100644
index 0000000000..6d1a895a2f
--- /dev/null
+++ b/doc/tips/using_Google_Cloud_Storage/comment_5_865f27a393f24fd5723c895d4d70dde3._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-11-02T14:59:08Z"
+ content="""
+Nice job bgilbert on the external special remote.
+
+git-annex's S3 special remote also supports nearline now:
+
+	git annex initremote cloud type=S3 encryption=none host=storage.googleapis.com port=80 storageclass=NEARLINE
+
+For the nearline support to work, git-annex has to be built with version 0.13.0 of
+the haskell aws library.
+
+But, it seems like bgilbert's external special remote is easier to set up,
+due to not needing to configure Google Cloud Storage for interoperable access.
+"""]]
diff --git a/doc/tips/using_Google_Cloud_Storage/comment_6_d1462d9d1d425e609bf8ad8fb8f0a9d5._comment b/doc/tips/using_Google_Cloud_Storage/comment_6_d1462d9d1d425e609bf8ad8fb8f0a9d5._comment
new file mode 100644
index 0000000000..e1878f00fc
--- /dev/null
+++ b/doc/tips/using_Google_Cloud_Storage/comment_6_d1462d9d1d425e609bf8ad8fb8f0a9d5._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Dosenpfand"
+ subject="comment 6"
+ date="2016-09-01T18:40:31Z"
+ content="""
+
+When trying to use google cloud storage i get the following error: 
+
+    $ git annex initremote cloud type=S3 encryption=none host=storage.googleapis.com port=80 storageclass=NEARLINE
+    initremote cloud (checking bucket...) (creating bucket in US...) git-annex: S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = \"Bad Request\"}, s3ErrorCode = \"MalformedHeaderValue\", s3ErrorMessage = \"An HTTP header value was malformed.\", s3ErrorResource = Nothing, s3ErrorHostId = Nothing, s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing}
+
+Does anybody know what is causing this? I am pretty sure that the credentials are correctly set and ommiting storageclass=NEARLINE does not help.
+
+"""]]
diff --git a/doc/tips/using_Google_Cloud_Storage/comment_7_6896ea720bb29db35db4c5e2463fa818._comment b/doc/tips/using_Google_Cloud_Storage/comment_7_6896ea720bb29db35db4c5e2463fa818._comment
new file mode 100644
index 0000000000..8b3e938179
--- /dev/null
+++ b/doc/tips/using_Google_Cloud_Storage/comment_7_6896ea720bb29db35db4c5e2463fa818._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2016-09-05T18:24:37Z"
+ content="""
+@Dosenpfand at a guess, perhaps you have missed enabling
+"Interoperable Access" in google cloud storage?
+
+Or, maybe Google managed to break their S3 compatability..
+
+gcsannex is probably a better way to tie git-annex and GCS together than
+using the S3 interface.
+"""]]
diff --git a/doc/tips/using_Google_Cloud_Storage/comment_8_1b4eb7e0f44865cd5ff0f8ef507d99c1._comment b/doc/tips/using_Google_Cloud_Storage/comment_8_1b4eb7e0f44865cd5ff0f8ef507d99c1._comment
new file mode 100644
index 0000000000..1a71f7726a
--- /dev/null
+++ b/doc/tips/using_Google_Cloud_Storage/comment_8_1b4eb7e0f44865cd5ff0f8ef507d99c1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="scottgorlin@a32946b2aad278883c1690a0753241583a9855b9"
+ nickname="scottgorlin"
+ avatar="http://cdn.libravatar.org/avatar/2dd1fc8add62bbf4ffefac081b322563"
+ subject="Coldline"
+ date="2016-11-21T00:49:23Z"
+ content="""
+Wanted to add that \"storageclass=COLDLINE\" appears to work seamlessly, both from my mac and arm NAS.  As far as I can tell, this appears to be a no-brainer vs glacier - builtin git annex client, simpler/cheaper billing, and no 4 hour delay!
+"""]]
diff --git a/doc/tips/using_Google_Drive.mdwn b/doc/tips/using_Google_Drive.mdwn
new file mode 100644
index 0000000000..be25ea55c9
--- /dev/null
+++ b/doc/tips/using_Google_Drive.mdwn
@@ -0,0 +1,9 @@
+For using [Google Drive](https://google.com/drive)
+as a special remote, there are currently two choices:
+
+* A dedicated special remote,
+  <https://github.com/Lykos153/git-annex-remote-googledrive>  
+  Includes support for exporttree and other features.
+* Using [[special_remotes/rclone]]
+
+If you find one works best, please comment below.
diff --git a/doc/tips/using_Hubic.mdwn b/doc/tips/using_Hubic.mdwn
new file mode 100644
index 0000000000..0824b19891
--- /dev/null
+++ b/doc/tips/using_Hubic.mdwn
@@ -0,0 +1,9 @@
+For using Hubic as a special remote, there are currently two choices:
+
+* Using [[special_remotes/rclone]]  
+  Actively maintained.
+* A dedicated special remote,
+  <https://github.com/Schnouki/git-annex-remote-hubic>  
+  Not actively maintained.
+
+If you find one works best, please comment below.
diff --git a/doc/tips/using_borg_for_efficient_storage_of_old_annexed_files.mdwn b/doc/tips/using_borg_for_efficient_storage_of_old_annexed_files.mdwn
new file mode 100644
index 0000000000..27be72e2f4
--- /dev/null
+++ b/doc/tips/using_borg_for_efficient_storage_of_old_annexed_files.mdwn
@@ -0,0 +1,60 @@
+If your git-annex repository contains 10 versions of a 100 megabyte file,
+it will need 1000 megabytes of disk space to store them all. To save space
+those old versions can be moved to a remote, but most remotes also don't
+store similar versions efficiently.
+
+[Borg](https://www.borgbackup.org/) is a deduplicating archiver
+with compression and encryption. This makes it a good solution to this
+problem, only the differences between the old versions of the file will be
+stored by borg.
+
+Borg can be used with git-annex as an unusual kind of remote.
+git-annex is not able to store files in borg itself. Instead the way this
+works is you use borg to store your git-annex repository, and then
+`git-annex sync` scans the borg repository to find out what annexed files are
+stored in it.
+
+Let's set that up. Run this from the top directory of your git-annex repository
+to create a borg repository next to it that stores all the files in it, and
+let git-annex treat it as a remote.
+
+	# borg init --encryption=keyfile ../borgrepo
+	# git annex initremote borg type=borg borgrepo=../borgrepo
+	# borg create ../borgrepo `pwd`::{now}
+	# git annex sync borg
+
+Now git-annex knows that all the files in the repository, including all the
+old versions, have been stored in borg. But when you try to drop a file,
+you'll find that git-annex does not trust the borg repository.
+
+	drop file (unsafe) 
+	  Could only verify the existence of 0 out of 1 necessary copies
+	
+	  Also these untrusted repositories may contain the file:
+	  	ca863c47-9ded-4dd0-bd7d-9b65e5624171 -- [borg]
+
+Why is this? Well, you could use `borg delete` or `borg prune` to delete
+the content of the file from the borg repository at any time, so git-annex
+defaults to not trusting it. This is fine when you're using borg to take
+backups, and need to delete old borg archives to free up space on the
+backup drive. And it can be useful to use git-annex with such borg backups.
+But our goal is instead to move old versions of files to borg. So, you need
+to tell git-annex that you will only use borg to append to the borg
+repository, not to delete things from it.
+
+	# git annex enableremote borg appendonly=yes
+
+Now all the old versions of files can be dropped from the git-annex
+repository, freeing up disk space.
+
+	# git annex unused
+	# git annex drop --unused
+
+You can continue running `borg create` and `git-annex sync` to store
+changed files in borg and let git-annex know what's stored there.
+
+It's possible to access the same borg repository from another clone of the
+git-annex repository too. Just run `git annex enableremote borg` in that
+clone to set it up. This uses the same `borgrepo` value that was passed
+to initremote, but you can override it, if, for example, you want to access
+the borg repository over ssh from this new clone.
diff --git a/doc/tips/using_box.com_as_a_special_remote.mdwn b/doc/tips/using_box.com_as_a_special_remote.mdwn
new file mode 100644
index 0000000000..e1cf8b8fe0
--- /dev/null
+++ b/doc/tips/using_box.com_as_a_special_remote.mdwn
@@ -0,0 +1,81 @@
+[Box.com](http://box.com/) is a file storage service.
+
+** WebDAV access to box.com will be deprecated at some point in the near future (originally was scheduled to be January 31, 2019 - but it has been pushed back to a yet to be defined date). At that point, the method described on this page will no longer work. See [this announcement](https://community.box.com/t5/Box-Product-News/Deprecation-WebDAV-Support/ba-p/55684) for further details. **
+
+git-annex can use Box as a [[special remote|special_remotes]].
+Recent versions of git-annex make this very easy to set up
+and use.
+
+
+## git-annex setup
+
+Create the special remote, in your git-annex repository.
+** This example is non-encrypted; fill in your gpg key ID for a securely
+encrypted special remote! **
+
+	WEBDAV_USERNAME=you@example.com WEBDAV_PASSWORD=xxxxxxx git annex initremote box.com type=webdav url=https://dav.box.com/dav/git-annex chunk=50mb encryption=none
+
+Note the use of [[chunking]]. Box has a limit on the maximum size of file
+that can be stored there (currently 256 MB). git-annex can break up large
+files into chunks to avoid the size limit. This needs git-annex version
+3.20120303 or newer, which adds support for chunking.
+
+Now git-annex can copy files to box.com, get files from it, etc, just like
+with any other special remote.
+
+	% git annex copy bigfile --to box.com
+	bigfile (to box.com...) ok
+	% git annex drop bigfile
+	bigfile (checking box.com...) ok
+	% git annex get bigfile
+	bigfile (from box.com...) ok
+
+## exporting trees
+
+By default, files stored in Box will show up there named
+by their git-annex key, not the original filename. If the filenames
+are important, you can run `git annex initremote` with an additional
+parameter "exporttree=yes", and then use [[git-annex-export]] to publish
+a tree of files to Box.
+
+Note that chunking can't be used when exporting a tree of files,
+so Box's 250 mb limit will prevent exporting larger files.
+
+# old davfs2 method
+
+This method is deprecated, but still documented here just in case.
+Note that the files stored using this method cannot reliably be retreived
+using the webdav special remote.
+
+## davfs2 setup
+
+* First, install
+  the [davfs2](http://savannah.nongnu.org/projects/davfs2) program,
+  which can mount Box using WebDAV. On Debian, just `sudo apt-get install davfs2`
+* Allow users to mount davfs filesystems, by ensuring that
+  `/sbin/mount.davfs` is setuid root. On Debian, just `sudo dpkg-reconfigure davfs2`
+* Add yourself to the davfs2 group.
+
+        sudo adduser $(whoami) davfs2
+
+* Edit `/etc/fstab`, and add a line to mount Box using davfs.
+
+        sudo mkdir -p /media/box.com
+        echo "https://dav.box.com/dav/	/media/box.com	davfs	noauto,user	0 0" | sudo tee -a /etc/fstab
+
+* Create `~/.davfs2/davfs2.conf` with some important settings:
+
+        mkdir ~/.davfs2/
+        echo use_locks 0 > ~/.davfs2/davfs2.conf
+        echo cache_size 1 >> ~/.davfs2/davfs2.conf
+        echo delay_upload 0 >> ~/.davfs2/davfs2.conf
+
+* Create `~/.davfs2/secrets`. This file contains your Box.com login and password.
+  Your login is probably the email address you signed up with.
+
+        echo "/media/box.com id@joeyh.name mypassword" > ~/.davfs2/secrets
+        chmod 600 ~/.davfs2/secrets
+
+* Now you should be able to mount Box, as a non-root user:
+
+        mount /media/box.com
diff --git a/doc/tips/using_box.com_as_a_special_remote/comment_1_be39f063e8a6155cc2eb71829e884a63._comment b/doc/tips/using_box.com_as_a_special_remote/comment_1_be39f063e8a6155cc2eb71829e884a63._comment
new file mode 100644
index 0000000000..075fd802a6
--- /dev/null
+++ b/doc/tips/using_box.com_as_a_special_remote/comment_1_be39f063e8a6155cc2eb71829e884a63._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlmvi8Z-rUen8xIety5uiJitI5rnMrz8Jk"
+ nickname="Timothy"
+ subject="updated url for drive mount"
+ date="2013-12-18T20:20:12Z"
+ content="""
+I had to change the url in fstab to https://**dav**.box.com/dav
+"""]]
diff --git a/doc/tips/using_git-annex_from_your_program.mdwn b/doc/tips/using_git-annex_from_your_program.mdwn
new file mode 100644
index 0000000000..cee0062694
--- /dev/null
+++ b/doc/tips/using_git-annex_from_your_program.mdwn
@@ -0,0 +1,100 @@
+Want to write a program that uses git-annex? Lots of people have, see
+[[related_software]] for a list. This tip is an overview of ways git-annex
+facilitates being used by other programs.
+
+## batch mode communication
+
+Many git-annex commands have a --batch option. This is handy if your
+program is operating on a lot of files; rather than running git-annex once
+per file, you can construct batch pipelines and probably it will run a lot
+faster.
+
+The way the --batch option typically works is, it makes the command read
+lines from standard input. Each line is a filename or whatever other thing
+the command operates on. It will reply with whatever output it usually
+outputs.
+
+For example:
+
+	git-annex get --batch
+	foo
+	get foo (from origin...)
+	(checksum...) ok
+	bar
+
+	baz
+	get baz (from origin...)
+	(checksum...) ok
+
+Notice the blank line it replies in response to "bar"? That's because,
+in this example, the file "bar" is already present, and it does not need to
+do anything to get it. Normally, git-annex silently skips files it does not
+need to operate on, but in batch mode, it will reply with a blank line when
+there's nothing to do for a given input line.
+
+## JSON output
+
+Notice that git-annex happened to output 2 lines per file in the example
+above. But it could output any number of lines. How can your program know
+when the output for one batch item is complete? Let alone parse it to
+determine if it succeeded or failed? Some git-annex commands don't have
+this problem, and are documented to output exactly one line, in a specific
+format, in batch mode.
+
+For the rest, the answer is `--json`. Use it with `--batch` and now each
+batch mode request results in a json object being output:
+
+	git-annex get --batch --json
+	foo
+	{"command":"get","note":"from origin...\nchecksum...","success":true,"input":["foo"],"key":"SHA256E-s30--f888da7dd6c0d6f37e3847f390d848c9a8e1e2d876865a91aca7e5a6a83715e0","file":"foo"}
+	bar
+
+	baz
+	{"command":"get","note":"from origin...\nchecksum...","success":true,"input":["baz"],"key":"SHA256E-s1048576000--da87281c9f9ab6cef8f9362935f4fc864db94606d52212614894f1253461a762","file":"baz"}
+
+Notice that it still outputs a blank line when there is nothing to do
+for a request, so be prepared for that in your JSON parser.
+
+There are also `--json-progress`, which adds more JSON messages giving
+progress of transfers, and `--json-error-messages` which makes some error
+messages be included in JSON objects instead of going to stderr.
+
+The format of git-annex's JSON output is not documented in full,
+because it varies from command to command. The shape is typically the same,
+but a few commands have a more custom JSON. Try a command and see
+what JSON it outputs and go from there. Fields won't be removed or renamed,
+but new ones might be added from time to time.
+
+## concurrency and batch mode
+
+If you use `-J` with `--batch`, some git-annex commands do support that,
+and will handle multiple batch requests concurrently.
+
+Suppose you want to get files concurrently in batch mode as the user clicks
+on them, and display to the user in your GUI when each file transfer is
+complete. But a problem: How to know which file a JSON reply corresponds
+to, now that they are not always in the same order as you sent the
+requests?
+
+	git-annex get --batch -J3 --json
+	./foo
+	bar
+	baz
+
+	{"command":"get","note":"from origin...\nchecksum...","success":true,"input":["baz"],"key":"SHA256E-s1048576000--da87281c9f9ab6cef8f9362935f4fc864db94606d52212614894f1253461a762","file":"baz"}
+	{"command":"get","note":"from origin...\nchecksum...","success":true,"input":["./foo"],"key":"SHA256E-s30--f888da7dd6c0d6f37e3847f390d848c9a8e1e2d876865a91aca7e5a6a83715e0","file":"foo"}
+
+You might think the "file" field is the thing to look at. And it can work.
+But, the example above shows a way it can fail to work. `./foo` was
+requested, but that got normalized internally, and the response has 
+`"file":"foo"`
+
+And looking at the "file" field won't help with other git-annex commands,
+such as addurl, where you don't request filenames.
+
+What will always work is to look at the "input" field. This is
+always the exact input that git-annex was operating on when it output a
+JSON object. (Older versions of git-annex don't include that field, but 
+those old versions don't run `--batch` concurrently either,
+so if it's omitted, you can assume the JSON objects are in the same order
+as you made requests.)
diff --git a/doc/tips/using_git_annex_with_no_fixed_hostname_and_optimising_ssh.mdwn b/doc/tips/using_git_annex_with_no_fixed_hostname_and_optimising_ssh.mdwn
new file mode 100644
index 0000000000..ade91c9047
--- /dev/null
+++ b/doc/tips/using_git_annex_with_no_fixed_hostname_and_optimising_ssh.mdwn
@@ -0,0 +1,59 @@
+## Intro
+
+This tip is based on my (Matt Ford) experience of using `git annex` with my out-and-about netbook which hits many different wifi networks and has no fixed home or address.
+
+I'm not using a bare repository that allows pushing (an alternative solution) nor do I fancy allowing `git push` to run against my desktop checked out repository (perhaps I worry over nothing?)
+
+None of this is really `git annex` specific but I think it is useful to know...
+
+## Dealing with no fixed hostname
+
+Essentially set up two repos as per the [[walkthrough]].
+
+Desktop as follows:
+
+    cd ~/annex
+    git init
+    git annex init "desktop"
+
+And the laptop like this
+
+    git clone ssh://desktop/annex
+    git init
+    git annex init "laptop"
+
+Now we want to add the the repos as remotes of each other.  
+
+For the laptop it is easy:
+
+    git remote add desktop ssh://desktop/~/annex 
+
+However for the desktop to add an ever changing laptops hostname it's a little tricky.  We make use of remote SSH tunnels to do this.  Essentially we have the laptop (which always knows its own name and address and knows the address of the desktop) create a tunnel starting on an arbitrary port at the desktop and heads back to the laptop on its own SSH server port (22).
+
+To do this make part of your laptop's SSH config look like this:
+
+    Host desktop
+    User matt
+    HostName desktop.example.org
+    RemoteForward 2222 localhost:22
+
+Now on the desktop to connect over the tunnel to the laptop's SSH port you need this:
+
+    Host laptop
+    User matt
+    HostName localhost
+    port 2222
+
+So to add the desktop's remote:
+
+a) From the laptop ensure the tunnel is up
+
+    ssh desktop
+
+b) From the desktop add the remote
+
+    git remote add laptop ssh://laptop/~/annex
+
+So now you can work on the train, pop on the wifi at work upon arrival, and sync up with a `git pull && git annex get`.
+
+An alternative solution may be to use direct tunnels over Openvpn.
diff --git a/doc/tips/using_git_annex_with_no_fixed_hostname_and_optimising_ssh/comment_1_c0b7682a2b6f3078457b85683c825baf._comment b/doc/tips/using_git_annex_with_no_fixed_hostname_and_optimising_ssh/comment_1_c0b7682a2b6f3078457b85683c825baf._comment
new file mode 100644
index 0000000000..e627ead47c
--- /dev/null
+++ b/doc/tips/using_git_annex_with_no_fixed_hostname_and_optimising_ssh/comment_1_c0b7682a2b6f3078457b85683c825baf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://adamspiers.myopenid.com/"
+ nickname="Adam"
+ subject="comment 1"
+ date="2011-12-23T13:31:33Z"
+ content="""
+ControlPersist is awesome - thanks!
+
+Here's [an alternative, git-specific approach](http://thread.gmane.org/gmane.comp.version-control.home-dir/502).
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex.mdwn b/doc/tips/using_gitolite_with_git-annex.mdwn
new file mode 100644
index 0000000000..0d20c93723
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex.mdwn
@@ -0,0 +1,149 @@
+[Gitolite](https://github.com/sitaramc/gitolite) is a git repository
+manager. Here's how to add git-annex support to gitolite, so you can
+`git annex copy` files to a gitolite repository, and `git annex get`
+files from it.
+
+A nice feature of using gitolite with git-annex is that users can be given
+read-only access to a repository, and this allows them to `git annex get`
+file contents, but not change anything.
+
+First, you need new enough versions:
+
+* the current `master` branch of gitolite works with git-annex (tested 2014-04-19),
+  but v3.5.3 and earlier v3.x require use of the `git-annex` branch.
+* gitolite 2.2 also works -- this version contains a git-annex-shell ADC
+  and supports "ua" ADCs.
+* git-annex 3.20111016 or newer needs to be installed on the gitolite
+  server. Don't install an older version, it wouldn't be secure!
+
+### Instructions for gitolite `master` branch
+
+To setup gitolite to work with git-annex, you can follow the instructions on the gitolite website,
+and just add `'git-annex-shell ua',` to the ENABLE list in `~/.gitolite.rc`.
+
+Here are more detailed instructions:
+
+1: Create a `git` user
+
+<pre>
+sudo adduser \
+   --system \
+   --shell /bin/bash \
+   --gecos 'git version control' \
+   --group \
+   --disabled-password \
+   --home /home/git git
+</pre>
+
+2: Copy a public SSH key for the user you want to be the gitolite administrator.
+In the instructions below, I placed the key in a file named `/home/git/me.pub`. 
+
+3: Clone and install gitolite
+
+First switch to the `git` user (e.g. `sudo su - git`) and then run:
+
+<pre>
+cd
+git clone https://github.com/sitaramc/gitolite.git
+mkdir -p bin
+./gitolite/install -ln
+</pre>
+
+4: Add `~/bin` to `PATH`
+
+Make sure that `~/bin` is in the `PATH`, since that's where gitolite installed its binary.  Do something like this:
+
+<pre>
+echo 'export PATH=/home/git/bin:$PATH' >> .profile
+export PATH=/home/git/bin:$PATH
+</pre>
+
+5: Configure gitolite
+
+Edit `~/.gitolite.rc` to enable the git-annex-shell command.
+Find the `ENABLE` list and add this line in there somewhere:
+
+<pre>
+'git-annex-shell ua',
+</pre>
+
+Now run gitolite's setup:
+
+<pre>
+gitolite setup -pk me.pub
+rm me.pub
+</pre>
+
+### Instructions for gitolite 2.2
+
+And here's how to set it up. The examples are for gitolite as installed
+on Debian with apt-get, but the changes described can be made to any
+gitolite installation, just with different paths.
+
+Set `$GL_ADC_PATH` in `.gitolite.rc`, if you have not already done so.
+
+<pre>
+echo '$GL_ADC_PATH = "/usr/local/lib/gitolite/adc/";' >>~gitolite/.gitolite.rc
+</pre>
+
+Make the ADC directory, and a "ua" subdirectory.
+
+<pre>   
+mkdir -p /usr/local/lib/gitolite/adc/ua
+</pre>
+
+Install the git-annex-shell ADC into the "ua" subdirectory from the gitolite repository.
+
+<pre>   
+cd /usr/local/lib/gitolite/adc/ua/
+cp gitolite/contrib/adc/git-annex-shell .
+</pre>
+
+Now all gitolite repositories can be used with git-annex just as any
+ssh remote normally would be used. For example:
+
+<pre>
+# git clone gitolite@localhost:testing
+Cloning into testing...
+Receiving objects: 100% (18/18), done.
+# cd testing
+# git annex init
+init  ok
+# cp /etc/passwd my-cool-big-file
+# git annex add my-cool-big-file
+add my-cool-big-file ok
+(Recording state in git...)
+# git commit -m added
+[master d36c8b4] added
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+ create mode 120000 my-cool-big-file
+# git push --all
+Counting objects: 17, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (12/12), done.
+Writing objects: 100% (14/14), 1.39 KiB, done.
+Total 14 (delta 0), reused 1 (delta 0)
+To gitolite@localhost:testing
+   c552a38..db4653e  git-annex -> git-annex
+   29cd204..d36c8b4  master -> master
+# git annex copy --to origin
+copy my-cool-big-file (checking origin...) (to origin...) 
+WORM-s2502-m1318875140--my-cool-big-file
+        2502 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/1)
+
+sent 2606 bytes  received 31 bytes  1758.00 bytes/sec
+total size is 2502  speedup is 0.95
+ok
+</pre>
+
+
+### Troubleshooting
+
+I got an error like this when setting up gitolite *after* setting up a local git repo and git annex:
+
+<pre>
+git-annex-shell: First run: git-annex init
+Command ssh ["git@git.example.com","git-annex-shell 'configlist' '/~/myrepo.git'"] failed; exit code 1
+</pre>
+
+because I forgot to "git push --all" after adding the new gitolite remote.
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_10_8767bc8014b459a3cd76f275fd4fa8d6._comment b/doc/tips/using_gitolite_with_git-annex/comment_10_8767bc8014b459a3cd76f275fd4fa8d6._comment
new file mode 100644
index 0000000000..b01779cb44
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_10_8767bc8014b459a3cd76f275fd4fa8d6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://ertai.myopenid.com/"
+ nickname="npouillard"
+ subject="git-annex no longer supported by gitolite g3"
+ date="2013-03-25T12:47:21Z"
+ content="""
+See http://gitolite.com/gitolite/dev-status.html for some details.
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_11_00715e0b47f09130e0e536e29f7b9258._comment b/doc/tips/using_gitolite_with_git-annex/comment_11_00715e0b47f09130e0e536e29f7b9258._comment
new file mode 100644
index 0000000000..1fbbd9b8a0
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_11_00715e0b47f09130e0e536e29f7b9258._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="http://mildred.fr/"
+ nickname="mildred"
+ subject="Problems with URL ending with &quot;.git&quot;"
+ date="2013-05-24T12:15:16Z"
+ content="""
+Hi,
+
+I noticed using the git-annex branch of gitolite v3 that the same URL with \".git\" at the end would not work in git-annex. For example my test repository was `git@git2.mildred.fr:u/mildred/Annex.git` but it didn't work until I converted it to `git@git2.mildred.fr:u/mildred/Annex`
+
+On the server, the repository is in `repositories/u/mildred/Annex.git`
+
+If I try a copy with git-annex for example, I would get:
+
+    $ git annex copy titi --to test
+    copy titi (checking test...) FATAL: u/mildred/Annex.git mildred DENIED
+    
+    (unable to check test) failed
+    git-annex: copy: 1 failed
+
+(test is the name of my remote and titi is my file)
+
+Note, in my gitolite conf, I have:
+
+    repo u/CREATOR/[a-zA-Z0-9].*
+      C    = @all
+      RW+D = CREATOR
+      RW   = WRITERS
+      R    = READERS
+
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_12_7027ce60265b8f24c8ab54553e544068._comment b/doc/tips/using_gitolite_with_git-annex/comment_12_7027ce60265b8f24c8ab54553e544068._comment
new file mode 100644
index 0000000000..f692dd93ea
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_12_7027ce60265b8f24c8ab54553e544068._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn5RcmefXjrl1vmbHIiOWQyXGXVKxlm3rg"
+ nickname="Kavin"
+ subject="comment 12"
+ date="2013-07-25T03:20:15Z"
+ content="""
+latest code of gitolite does not support git-annex ? I could not find a way to make it work ?
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_13_75218b7409c0e281cb01c9b2791e8cdf._comment b/doc/tips/using_gitolite_with_git-annex/comment_13_75218b7409c0e281cb01c9b2791e8cdf._comment
new file mode 100644
index 0000000000..bc674a5921
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_13_75218b7409c0e281cb01c9b2791e8cdf._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm9tgeFE5v-arAYYftSv3yUTI5Q4qB2C9M"
+ nickname="Khaije"
+ subject="git-annex with gitolite FTW"
+ date="2013-08-13T15:13:07Z"
+ content="""
+The steps to activate git-annex integration have changed/simplified for v3.
+
+
+1) during install, be sure to use the 'git-annex' branch, rather than master[fn:1]. 
+
+2) to enable git-annex-shell, open ~/.gitolite.rc and insert 'git-annex-shell' => 'ua' into the hash list in the COMMANDS array.[fn:2] 
+#'git-annex-shell'   =>  'ua',
+   
+
+
+
+[fn:1] We'd like to have this feature-branch merged to master, so please send Sitaram feedback, positive and negative, based on your experiences.
+[fn:2] There is no GL_ADC_PATH and no \"ua\" subdirectory here, and nothing to \"install\"; the command now comes with gitolite.
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_14_7d4d4515218d1259d32be3baeb5ee56e._comment b/doc/tips/using_gitolite_with_git-annex/comment_14_7d4d4515218d1259d32be3baeb5ee56e._comment
new file mode 100644
index 0000000000..048dfa6986
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_14_7d4d4515218d1259d32be3baeb5ee56e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSbvo_NbY-ev1VKtzwo7nEqUmvRO6rXGA"
+ nickname="François"
+ subject="comment 14"
+ date="2013-09-22T18:30:45Z"
+ content="""
+@khaije
+
+Could you paste your config file? Here is mine: http://paste.debian.net/44856/
+I don't have any COMMANDS array. Could you elaborate your modifications please?
+
+Thanks.
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_15_dc6f21b5a3d5931c8d949a9753411b9e._comment b/doc/tips/using_gitolite_with_git-annex/comment_15_dc6f21b5a3d5931c8d949a9753411b9e._comment
new file mode 100644
index 0000000000..f07116983b
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_15_dc6f21b5a3d5931c8d949a9753411b9e._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnRaueN1AcM8pIMofH5-wQ1Kr4T0GBe8sA"
+ nickname="wayne"
+ subject="git-annex with gitolite-rc"
+ date="2013-10-19T17:03:32Z"
+ content="""
+@François
+
+The proper array in .gitolite.rc seems to be the \"ENABLE\" array, which it appears is parsed into the COMMANDS array in src/lib/Gitolite/Rc.pm
+
+@Khaije
+
+Using 'git-annex-shell' => 'ua' doesn't seem to work for me. The program still fails in src/gitolite-shell around line 163 (gitolite repo version b1d3c05):
+
+    _die \"suspicious characters loitering about '$soc'\"
+      if $rc{COMMANDS}{ words[0] } ne 'ua' and $soc !~ $REMOTE_COMMAND_PATT;
+
+When I insert $rc{COMMANDS}{ words[0] } into the _die message, it shows up as \"1\" instead of \"ua\" as I was expecting.
+
+When I manually set $rc{COMMANDS}{ words[0] } to 'ua' slightly earlier in the script, the git-annex-shell command gets run but it seems to fail to parse the result of the configlist command properly because then I get 
+
+    Failed to get annex.uuid configuration of repository origin
+
+    Instead, got: \"annex.uuid=\ncore.gcrypt=\n\"
+
+
+I am actually about to give up on the notion of using git-annex and gitolite together. Maybe. I am interested to know if anyone else is having similar problems.
+
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_16_8e5039e6655fc80dc863b6cdf44ef02a._comment b/doc/tips/using_gitolite_with_git-annex/comment_16_8e5039e6655fc80dc863b6cdf44ef02a._comment
new file mode 100644
index 0000000000..5e0e6acd60
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_16_8e5039e6655fc80dc863b6cdf44ef02a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmbo-yMzW_lkBrS4ICNn5XMr8saYtI1_WY"
+ nickname="Douglas"
+ subject="Any further info regarding gitolite support?"
+ date="2013-11-14T03:20:31Z"
+ content="""
+We have reached the same point as the previous poster from 25 days ago. 
+$ git annex copy --to origin
+FATAL: suspicious characters loitering about 'git-annex-shell 'configlist' '/~/testing''
+
+  Remote origin does not have git-annex installed; setting remote.origin.annex-ignore
+git-annex: cannot determine uuid for origin
+
+Anyone actually have this working?
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_17_9c40e1da8bb44f7207e802377f5cf923._comment b/doc/tips/using_gitolite_with_git-annex/comment_17_9c40e1da8bb44f7207e802377f5cf923._comment
new file mode 100644
index 0000000000..57152bad7d
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_17_9c40e1da8bb44f7207e802377f5cf923._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm9tgeFE5v-arAYYftSv3yUTI5Q4qB2C9M"
+ nickname="Khaije"
+ subject="comment 17"
+ date="2013-11-23T02:14:12Z"
+ content="""
+my gitolite.rc is available at https://gist.github.com/khaije1/7609848
+
+For whatever reason I've found this to be very simple to get working so I'd guess there's a missing ingredient somewhere. The combination of gitolite and git-annex is valuable to me so I'll add documents to the url above in hopes it will assist some people with getting the same value.
+
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_18_f1a180d5cf65b7a870a13ddb4f76d00d._comment b/doc/tips/using_gitolite_with_git-annex/comment_18_f1a180d5cf65b7a870a13ddb4f76d00d._comment
new file mode 100644
index 0000000000..882478f5b6
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_18_f1a180d5cf65b7a870a13ddb4f76d00d._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawll4Kgp7nMuOKdB0FfbcYZ3KRq7HCS0Slc"
+ nickname="Laura"
+ subject="Using Gitolite 3.2"
+ date="2014-01-17T20:14:16Z"
+ content="""
+Adding:
+
+ 'git-annex-shell' =>1, 
+
+To the .gitolite.rc file resulted in the \"FATAL: suspicous characters loitering about 'git-annex-shell 'configlist' '/~/testing''...
+
+
+Gitolite source code (https://github.com/sitaramc/gitolite/commit/b1d3c0571409b7c6279fc6a77253c3bc262ab425#diff-79a3701e9e2cee0ea1316451c21a3fec) requires this entry:
+
+'git-annex-shell ua'
+
+
+
+
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_19_33c19097b6f2b48dfe09ec4c8d952d06._comment b/doc/tips/using_gitolite_with_git-annex/comment_19_33c19097b6f2b48dfe09ec4c8d952d06._comment
new file mode 100644
index 0000000000..636794abae
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_19_33c19097b6f2b48dfe09ec4c8d952d06._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnftLWVOF0DUdXr2HSW4IKzuqtW8V7X3YU"
+ nickname="Adrian"
+ subject="How can the git annex init command be called on the server?"
+ date="2014-03-25T06:58:56Z"
+ content="""
+The latest commit in the gitolite repository \"git-annex support, finally in master!\" looks really promissing. I'm currently using ubuntu trusty with updated gitolite3 package and the configuration provided by Khaije. One line needs to be changed: 'git-annex-shell' => 'ua', instead of 'git-annex-shell' =>1,
+
+However, one little detail is still open for me. I need to call the server side \"git annex init\" on the server (sudo su gitolite3; cd ~/repositories/testing.git && git annex init). I cannot find a way to initialize the server from client side. E.g. git annex init && git push --all is not enough. The man page describes git annex initremote for other server types but not for gitolite remotes. Wouldn't we need something similar for gitolite as well? Or is there a better solution which I do not recognize?
+
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_1_9a2a2a8eac9af97e0c984ad105763a73._comment b/doc/tips/using_gitolite_with_git-annex/comment_1_9a2a2a8eac9af97e0c984ad105763a73._comment
new file mode 100644
index 0000000000..807180660b
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_1_9a2a2a8eac9af97e0c984ad105763a73._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://www.openid.albertlash.com/openid/"
+ ip="71.178.29.218"
+ subject="comment 1"
+ date="2011-12-24T06:08:45Z"
+ content="""
+Looks like you are missing a closing double quote on the line:
+
+
+echo '$GL_ADC_PATH = \"/usr/local/lib/gitolite/adc/;' >>~gitolite/.gitolite.rc
+
+right after /;
+
+I got this working by the way - great stuff.
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_20_c82af00db3dd74ee9bfe12668e76e57b._comment b/doc/tips/using_gitolite_with_git-annex/comment_20_c82af00db3dd74ee9bfe12668e76e57b._comment
new file mode 100644
index 0000000000..45ff960f43
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_20_c82af00db3dd74ee9bfe12668e76e57b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.41"
+ subject="comment 20"
+ date="2014-03-26T18:24:30Z"
+ content="""
+@Adrian, that's good news. It would be helpful if someone could update the top of this page to document how to use git-annex with the new version of gitolite.
+This is a wiki..
+
+You're not supposed to need to use initremote when dealing with normal git remotes. It seems that something got lost that automatically initialize the remote repository in this situation. I've fixed it so that it will be set up when `git-annex-shell configlist` is run. 
+
+(@wayne, this fixes the problem you reported too..)
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_21_d2feaaf22d41413048dabf706d1b267e._comment b/doc/tips/using_gitolite_with_git-annex/comment_21_d2feaaf22d41413048dabf706d1b267e._comment
new file mode 100644
index 0000000000..2746ee41b8
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_21_d2feaaf22d41413048dabf706d1b267e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn26WQjIP5fnMgQF_L_k3Q3UrR5v8mjRTY"
+ nickname="Ellis"
+ subject="Worked for me, updated wiki"
+ date="2014-04-19T09:41:11Z"
+ content="""
+I tried the `master` branch of gitolite today on my server, and it works fine!  Updated the wiki with the commands I used to setup gitolite.
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_22_90ead0e1fe8615fe11f6f1bd7dcd7e84._comment b/doc/tips/using_gitolite_with_git-annex/comment_22_90ead0e1fe8615fe11f6f1bd7dcd7e84._comment
new file mode 100644
index 0000000000..6f959c0d72
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_22_90ead0e1fe8615fe11f6f1bd7dcd7e84._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3gWkz5Qgy5qEa-myg8KWtiTrHSKW1x7Q"
+ nickname="Nicolas"
+ subject="Using Gitolite 3.6.1"
+ date="2014-09-11T00:11:32Z"
+ content="""
+Hi!
+
+I've made a fresh install of Gitolite 3.6.1 and got this error when trying to sync :
+
+FATAL: bad git-annex-shell command: git-annex-shell 'configlist' '/nicolas.git' at /home/git/bin/commands/git-annex-shell line 25, <DATA> line 1.
+
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_23_70dcb7e7ffdd14351adaf4c40ee7fdd0._comment b/doc/tips/using_gitolite_with_git-annex/comment_23_70dcb7e7ffdd14351adaf4c40ee7fdd0._comment
new file mode 100644
index 0000000000..095159afa9
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_23_70dcb7e7ffdd14351adaf4c40ee7fdd0._comment
@@ -0,0 +1,29 @@
+[[!comment format=hs
+ username="risca"
+ subject="Problem solved!"
+ date="2015-03-17T09:37:04Z"
+ content="""
+I was experiencing the same issue (FATAL: bad git-annex-shell command: git-annex-shell 'configlist' '/myrepo' at /usr/share/gitolite3/commands/git-annex-shell line 25, <DATA> line 1.)
+
+I solved with the following patch:
+
+--- /usr/share/gitolite3/commands/git-annex-shell       2015-03-17 10:26:46.114680811 +0100
++++ orig.git-annex-shell        2015-03-17 10:25:16.074680925 +0100
+@@ -23,7 +23,7 @@ my $cmd = $ENV{SSH_ORIGINAL_COMMAND};
+ # the second parameter.
+ # Further parameters are not validated here (see below).
+ die \"bad git-annex-shell command: $cmd\"
+-  unless $cmd =~ m#^(git-annex-shell '\w+' ')/(?:\~\/)?([0-9a-zA-Z][0-9a-zA-Z._\@/+-]*)('( .*|))$#;
++  unless $cmd =~ m#^(git-annex-shell '\w+' ')/\~/([0-9a-zA-Z][0-9a-zA-Z._\@/+-]*)('( .*|))$#;
+ my $start = $1;
+ my $repo  = $2;
+ my $end   = $3;
+
+
+References: http://git-annex.branchable.com/tips/using_gitolite_with_git-annex/#comment-16ee81f0d9e973ecb2fbb9d4a1fff261
+It was shown 3 years ago! I don't know why the bug it's still on. I'm using debian with:
+ - git-annex:
+  Installed: 5.20141024~bpo70+1
+ - gitolite3:
+  Installed: 3.6-1~bpo70+1
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_24_a62f59295b3912dc38def5e493bdb55a._comment b/doc/tips/using_gitolite_with_git-annex/comment_24_a62f59295b3912dc38def5e493bdb55a._comment
new file mode 100644
index 0000000000..c6e4c02f19
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_24_a62f59295b3912dc38def5e493bdb55a._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="git-annex@5b470e1f6ed6d30997d729f0a8b1c841dea886f1"
+ nickname="git-annex"
+ subject="Using gitolite 3.6.6 mirror not working with annex"
+ date="2016-09-28T18:12:56Z"
+ content="""
+I find out that I need to add the following lines to the gitolite.rc
+in the server side.
+
+'git-annex-shell ua'
+
+The signal repository works with gitolite as expected.
+However, the mirroring feature is not working for slaves.
+When I do
+
+git annex copy --to origin
+
+The master server store the annex file correctly.
+The file managed by annex is not syncing to the slave
+mirrors at all.
+
+
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_25_08b3b257b3dbd32cb807e29f512ea9c9._comment b/doc/tips/using_gitolite_with_git-annex/comment_25_08b3b257b3dbd32cb807e29f512ea9c9._comment
new file mode 100644
index 0000000000..7b52cb8ace
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_25_08b3b257b3dbd32cb807e29f512ea9c9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="davicastro"
+ avatar="http://cdn.libravatar.org/avatar/4e708663cf4d5b9e8cfea74caf4307fc"
+ subject="Where does gitolite stores the annex objects contents?"
+ date="2018-04-27T21:06:42Z"
+ content="""
+Hi. Does anyone knows where does gitolite stores the annex objects' contents? (I got it to work, and git annex is working fine, but I want to \"see the annex files\" in the central gitolite server. And it puzzles me I can't find them! It definitively is not in the repo.git bare repository under the gitolite admin repositores folder)
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_2_d8efea4ab9576555fadbb47666ecefa9._comment b/doc/tips/using_gitolite_with_git-annex/comment_2_d8efea4ab9576555fadbb47666ecefa9._comment
new file mode 100644
index 0000000000..007a009ea1
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_2_d8efea4ab9576555fadbb47666ecefa9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-12-24T16:54:31Z"
+ content="""
+I've fixed the typo (anyone can edit pages in this wiki FWIW.)
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_3_807035f38509ccb9f93f1929ecd37417._comment b/doc/tips/using_gitolite_with_git-annex/comment_3_807035f38509ccb9f93f1929ecd37417._comment
new file mode 100644
index 0000000000..243764054d
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_3_807035f38509ccb9f93f1929ecd37417._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="bremner"
+ ip="156.34.79.193"
+ subject="repo name conventions?"
+ date="2011-12-30T21:41:13Z"
+ content="""
+I'm confused by the fact that the git-annex-shell adc rejects any repo names that don't start with /~/ since none of my repos start that way. It seems work ok if I just delete /\~ from the front of the regex, but I feel like I must be missing something. 
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_4_eb81f824aadc97f098379c5f7e4fba4c._comment b/doc/tips/using_gitolite_with_git-annex/comment_4_eb81f824aadc97f098379c5f7e4fba4c._comment
new file mode 100644
index 0000000000..c53ce01d94
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_4_eb81f824aadc97f098379c5f7e4fba4c._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 4"
+ date="2011-12-31T00:29:45Z"
+ content="""
+Well a repo url like `gitolite@localhost:testing` puts it in the gitolite user's /~/testing
+
+This worked when I added the gitolite stuff, anyway.. Let's see if it still does:
+
+<pre>
+joey@gnu:~/tmp>mkdir g
+joey@gnu:~/tmp>cd g
+joey@gnu:~/tmp/g>git init
+Initialized empty Git repository in /home/joey/tmp/g/.git/
+joey@gnu:~/tmp/g>git annex init
+init  ok
+joey@gnu:~/tmp/g>git remote add test 'gitolite@localhost:testing'
+joey@gnu:~/tmp/g>touch foo
+joey@gnu:~/tmp/g>git annex add foo
+add foo (checksum...) ok
+(Recording state in git...)
+joey@gnu:~/tmp/g>git annex copy foo --to test --debug
+git [\"--git-dir=/home/joey/tmp/g/.git\",\"--work-tree=/home/joey/tmp/g\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"foo\"]
+git [\"--git-dir=/home/joey/tmp/g/.git\",\"--work-tree=/home/joey/tmp/g\",\"check-attr\",\"annex.numcopies\",\"-z\",\"--stdin\"]
+git [\"--git-dir=/home/joey/tmp/g/.git\",\"--work-tree=/home/joey/tmp/g\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+git [\"--git-dir=/home/joey/tmp/g/.git\",\"--work-tree=/home/joey/tmp/g\",\"show-ref\",\"git-annex\"]
+git [\"--git-dir=/home/joey/tmp/g/.git\",\"--work-tree=/home/joey/tmp/g\",\"cat-file\",\"--batch\"]
+Running: ssh [\"-4\",\"gitolite@localhost\",\"git-annex-shell 'configlist' '/~/testing'\"]
+</pre>
+
+Still seems right, the ADC's regexp will match this the git-annex shell command.
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_5_f688309532d2993630e9e72e87fb9c46._comment b/doc/tips/using_gitolite_with_git-annex/comment_5_f688309532d2993630e9e72e87fb9c46._comment
new file mode 100644
index 0000000000..052fc90d6b
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_5_f688309532d2993630e9e72e87fb9c46._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="bremner"
+ ip="156.34.79.193"
+ subject="gitolite gets different paths for different urls"
+ date="2011-12-31T01:50:49Z"
+ content="""
+I guess there is some path rewriting going in in gitolite proper because if try a url of the form 
+ssh://git@localhost/testing, then it still works with gitolite, but fails with the ADC because 
+the repo is passed as /testing:
+<pre>
+Running: ssh [\"git@host\",\"git-annex-shell 'configlist' '/recommend'\"]
+Running: ssh [\"git@host\",\"git-annex-shell 'configlist' '/recommend'\"]
+</pre>
+
+What I have to ask Sitaram and or find in the docs is if this is a bug or a feature in gitolite.  I can see how the leading slash would get swallowed up by this line 
+<pre>
+$repo = \"'$REPO_BASE/$repo.git'\"
+</pre>
+in gl-auth-command, but I guess that isn't the whole story.
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_6_3e203e010a4df5bf03899f867718adc5._comment b/doc/tips/using_gitolite_with_git-annex/comment_6_3e203e010a4df5bf03899f867718adc5._comment
new file mode 100644
index 0000000000..ce888cb135
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_6_3e203e010a4df5bf03899f867718adc5._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="bremner"
+ ip="156.34.79.193"
+ subject="ssh://gitolite-host/repo-name is supposed to work"
+ date="2011-12-31T03:34:17Z"
+ content="""
+I confirmed with Sitaram that this is intentional, if probably under-documented.
+Since the ADC strips the leading /~/ in assigning $start anyway, I guess something like the following will  work 
+<pre>
+
+diff --git a/contrib/adc/git-annex-shell b/contrib/adc/git-annex-shell
+index 7f9f5b8..523dfed 100755
+--- a/contrib/adc/git-annex-shell
++++ b/contrib/adc/git-annex-shell
+@@ -28,7 +28,7 @@ my $cmd=$ENV{SSH_ORIGINAL_COMMAND};
+ # the second parameter.
+ # Further parameters are not validated here (see below).
+ die \"bad git-annex-shell command: $cmd\"
+-    unless $cmd =~ m#^(git-annex-shell '\w+' ')/\~/([0-9a-zA-Z][0-9a-zA-Z._\@/+-
++    unless $cmd =~ m#^(git-annex-shell '\w+' ')/(?:\~\/)?([0-9a-zA-Z][0-9a-zA-Z.
+ my $start = $1;
+ my $repo = $2;
+ my $end = $3;
+</pre>
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_7_f8fd08b6ab47378ad88c87348057220d._comment b/doc/tips/using_gitolite_with_git-annex/comment_7_f8fd08b6ab47378ad88c87348057220d._comment
new file mode 100644
index 0000000000..bdbecd4d99
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_7_f8fd08b6ab47378ad88c87348057220d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 7"
+ date="2011-12-31T18:32:28Z"
+ content="""
+That patch seems ok, it doesn't seem to allow through any repo locations that were blocked before.
+
+So, it has my blessing.. but the ADC is in gitolite and will need to be patched there.
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_8_8249772c142117f88e37975d058aa936._comment b/doc/tips/using_gitolite_with_git-annex/comment_8_8249772c142117f88e37975d058aa936._comment
new file mode 100644
index 0000000000..0717bab1c2
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_8_8249772c142117f88e37975d058aa936._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="bremner"
+ ip="156.34.79.193"
+ subject="afaict git annex normalizes urls on the client side."
+ date="2011-12-31T22:29:38Z"
+ content="""
+After some debugging printing, here is my current understanding.
+
+- urls of the form git@host:~repo or ssh://git@host
+
+  - git sends commands like  \"git-receive-pack '~/repo'
+  - gitolite converts these to $REPO_BASE/~/repo which fails.  ~/repo would also fail fwiw.
+  - git-annex sends seems /~/repo, which works
+
+- urls of the form git@host:/repo or ssh://git@host/repo
+
+  - git sends \"git-receive-pack '/db/cs3383'\"
+  - gitolite converts this to $REPO_BASE/repo which works
+  - git annex sends \"git-annex-shell 'inannex' '/repo' ...\" which works, but only with the patch above.
+
+- urls of the form git@host:repo
+
+  - git sends \"git-receive-pack 'repo'
+  - gitolite converts this to $REPO_BASE/repo, which works
+  - git-annex sends \"git-annex-shell 'inannex' '/~/db/cs3383'...\", which also works for git-annex-shell.
+
+So the weird case is the last one where git and git-annex are sending different things over the wire.
+I don't know if you have other motivations for doing the url normalization on the client side, but it isn't needed for gitolite, and in some sense complicates things a little.  On the other hand, now that I see what is going on, it isn't a big deal to just strip the leading /~ off in the adc. It does lead to the odd situation of some URLs working for git-annex but not git.
+"""]]
diff --git a/doc/tips/using_gitolite_with_git-annex/comment_9_28418635a6ed7231b89e02211cd3c236._comment b/doc/tips/using_gitolite_with_git-annex/comment_9_28418635a6ed7231b89e02211cd3c236._comment
new file mode 100644
index 0000000000..fc297ff175
--- /dev/null
+++ b/doc/tips/using_gitolite_with_git-annex/comment_9_28418635a6ed7231b89e02211cd3c236._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 9"
+ date="2012-01-02T16:27:55Z"
+ content="""
+Ah right. git-annex normalizes all git ssh style user@host:dir to valid uris, which is where the `/~/` comes from. I don't anticipate this changing on the git-annex side.
+"""]]
diff --git a/doc/tips/using_nested_git_repositories.mdwn b/doc/tips/using_nested_git_repositories.mdwn
new file mode 100644
index 0000000000..6ebd9e64c8
--- /dev/null
+++ b/doc/tips/using_nested_git_repositories.mdwn
@@ -0,0 +1,7 @@
+Using nested git repositories in git is not possible and thus this also applies to git-annex. However, here is a good workaround that I found:
+
+Rename the `.git` directory of the nested repo to `dotgit` (or similar), `git annex add` it and then create a symbolic link from `.git` to `dotgit`. It's important that the link is created only after the nested repo has been `git annex add`'ed. Also, the link needs to be created manually on each clone. Finally you'll need to hide the `dotgit` directory from the nested repo itself by adding `/dotgit` to `dotgit/info/exclude`.
+
+    mv nested/.git nested/dotgit; echo "/dotgit" >>nested/dotgit/info/exclude
+    git annex add nested; git commit -m "add nested"
+    cd nested; ln -s dotgit .git # needs to be done on every clone
diff --git a/doc/tips/using_nested_git_repositories/comment_1_cd7f673de1c39d2f37d9958357d5e72d._comment b/doc/tips/using_nested_git_repositories/comment_1_cd7f673de1c39d2f37d9958357d5e72d._comment
new file mode 100644
index 0000000000..92c56b1916
--- /dev/null
+++ b/doc/tips/using_nested_git_repositories/comment_1_cd7f673de1c39d2f37d9958357d5e72d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="nested git repositories are git submodules"
+ date="2022-01-14T13:02:36Z"
+ content="""
+Using nested git repositories is well possible; if they are checked in they are called submodules, otherwise they just sit there unadded.
+
+Apart from some [[odd quirx you never run into in normal operation|bugs/creating dot-git-as-symlink workaround drops worktree configuration from submodules]], submodules work fine also with git-annex.
+"""]]
diff --git a/doc/tips/using_nested_git_repositories/comment_2_63f30b652c0cbdb0acf6745891f9f09e._comment b/doc/tips/using_nested_git_repositories/comment_2_63f30b652c0cbdb0acf6745891f9f09e._comment
new file mode 100644
index 0000000000..bc6b5fbdd7
--- /dev/null
+++ b/doc/tips/using_nested_git_repositories/comment_2_63f30b652c0cbdb0acf6745891f9f09e._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-01-19T15:51:17Z"
+ content="""
+I agree, submodules are the usual way to nest git repositories, and will
+more or less just work with git-annex.
+
+I think that the author of this tip is wanting to version control the
+contents of `.git` itself. Eg, to version control `.git/config` and 
+`.git/hooks/`.
+
+One problem with this approach is that when the outer repository has
+"dotgit/annex/objects/` files added to it, running `git-annex drop` inside
+the nested git repository will drop the content, but the outer repository
+will still contain a copy too. You would have to use `git-annex unused`
+to eventually clean up those copies. And it stores 2 copies of every
+annexed file to use it this way.
+"""]]
diff --git a/doc/tips/using_nested_git_repositories/comment_3_029571d8331ba2dcf0b149d071fef75c._comment b/doc/tips/using_nested_git_repositories/comment_3_029571d8331ba2dcf0b149d071fef75c._comment
new file mode 100644
index 0000000000..669a1979bd
--- /dev/null
+++ b/doc/tips/using_nested_git_repositories/comment_3_029571d8331ba2dcf0b149d071fef75c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="branch"
+ subject="comment 3"
+ date="2023-10-05T21:40:54Z"
+ content="""
+On a similar topic, I also have multiple git repositories that I want to backup (multiple copies...). These repositories belong to a parent repository that is properly set up with git-annex, and the necessary remotes. I want to be able to recover the entire state of the parent folder (including these children repositories) at any given time.
+
+I am quite unfamiliar with submodules, so feel free to correct me, but based on my experiments, using them makes each child repository/submodule independent/invisible to the parent one. If all these child repositories were submodules, I wouldn't be able to use the parent config to back them up, and I would have to repeat the same configuration on each submodule.
+
+If I were to leave the repositories as they are, the enclosing files seem to be annexed by the parent repository as I would want them up, but the .git repository is ignored. To achieve my goal, I can imagine one solution where every child .git folder would be zipped and annexed alongside, maybe on a pre-commit hook, to be restored in certain occasions.
+
+Is my understanding of the issue reasonable? Is there any other option?
+"""]]
diff --git a/doc/tips/using_nested_git_repositories/comment_4_3c701a4c6789fc6c73f71217e7ed8c65._comment b/doc/tips/using_nested_git_repositories/comment_4_3c701a4c6789fc6c73f71217e7ed8c65._comment
new file mode 100644
index 0000000000..abf5049da8
--- /dev/null
+++ b/doc/tips/using_nested_git_repositories/comment_4_3c701a4c6789fc6c73f71217e7ed8c65._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 4"
+ date="2023-10-06T03:22:12Z"
+ content="""
+Submodules can feel a bit clunky, that's right. They're 'invisible to the parent repo' in that they indeed have separate configs (remotes, etc.), so one needs to manually set it up again when replicating.
+
+DataLad embraces this and provides e.g. `datalad save`, which commits recursively into all submodules and it will also initialize and handle submodules a bit more automatic. But it lacks the fully bidirectional `git annex sync|assist`.
+
+I use submodules extensively and am not entirely happy with it due to the fragile manual config necessary.
+
+Auto-enabled special remotes can help out a bit (those will be configured upon first submodule creation by git annex). 
+"""]]
diff --git a/doc/tips/using_signed_git_commits.mdwn b/doc/tips/using_signed_git_commits.mdwn
new file mode 100644
index 0000000000..cf1b744c8a
--- /dev/null
+++ b/doc/tips/using_signed_git_commits.mdwn
@@ -0,0 +1,79 @@
+Git uses SHA1, which is becoming increasingly broken. Using git-annex
+and signed commits, we can work around the weaknesses of SHA1, and
+let anyone who clones a repository verify that the data they receive
+is the same data that was originally commited to it.
+
+This is recommended if you are storing any kind of binary 
+files in a git repository.
+
+## Configuring git-annex
+
+You need git-annex 6.20170228. Upgrade if you don't have it.
+
+git-annex can use many types of [[backends]] and not all of them are
+secure. So, you need to configure git-annex to only use
+cryptographically secure hashes.
+
+	git annex config --set annex.securehashesonly true
+
+Each new clone of the repository will then inherit that configuration.
+But, any existing clones will not, so this should be run in them:
+
+	git config annex.securehashesonly true
+
+## Signed commits
+
+It's important that all commits to the git repository are signed.
+Use `git commit --gpg-sign`, or enable the commit.gpgSign configuration.
+
+Use `git log --show-signature` to check the signatures of commits.
+If the signature is valid, it guarantees that all annexed files
+have the same content that was orignally committed.
+
+## Why is this more secure than git alone?
+
+SHA1 collisions exist now, and can be produced using a common-prefix
+attack. See <https://shattered.io/>. Let's assume that a chosen-prefix
+attack against SHA1 will also become feasible too. However, a full preimage
+attack still seems unlikely, so we won't consider such attacks in the
+analysis below.
+
+The reason that git-annex can work around git's problematic use of SHA1 is
+that git-annex uses other, [[stronger hashes|backends]] of the contents of
+annexed files. For example, an annexed file may be a symlink to
+".git/annex/objects/Ab/Cd/SHA256--eb45a55eb8756646e244e6c5f47349294568d58a9321244f4ee09a163da23a27".
+
+Such a symlink is stored as a git blob object. The SHA1 of the git blobs
+are listed in a git tree object, and the git commit object contains the
+SHA1 of the tree. Finally, the commit object is gpg signed.
+
+So, by checking the signature of a commit (`git log --show-signature`),
+you can verify that this is the same commit that was originally made
+to the repository. As far as the git developers know, there is no way
+to produce multiple colliding git tree objects (at least not without
+creating files with spectacularly ugly and long names), so you
+know that the tree object pointed to by the signed commit is the original one.
+
+Now, what about the blob objects that the tree lists? If these blobs
+were regular git files, a SHA1 collision could mean your git repository
+does not contain the same file that was orignally committed, and the signed
+commit would not help.
+
+But, if the blob object is a git-annex symlink target, it has to contain the
+strong hash of the file content. If a SHA1 collision swaps in some other
+blob object, it will need to contain the strong hash of a different file's
+content. The current common-prefix attack cannot do that.
+
+A chosen-prefix attack could make two strong hashes SHA1 the same,
+but it would need to include additional data after the hash to do it. Since
+git-annex version 6.20170224, there is no place for an attacker to
+put such data in a git-symlink target. (See
+[[todo/sha1_collision_embedding_in_git-annex_keys]] for details
+of how this was prevented.)
+
+So, we have a SHA1 chain from the gpg signature to the git-annex symlink target,
+and at no point in the chain is a SHA1 collision attack feasible.
+Finally, git-annex verifies the strong hash when transferring
+the content of a file into the repository (and `git annex fsck` verifies it
+too), and so the content that the symlink is pointing to must be the same
+content that was originally committed.
diff --git a/doc/tips/using_signed_git_commits/comment_1_82241dc5666e1b573a24b3e84f3991ae._comment b/doc/tips/using_signed_git_commits/comment_1_82241dc5666e1b573a24b3e84f3991ae._comment
new file mode 100644
index 0000000000..b8f9c787f5
--- /dev/null
+++ b/doc/tips/using_signed_git_commits/comment_1_82241dc5666e1b573a24b3e84f3991ae._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="Non-conforming blobs"
+ date="2017-03-03T12:29:51Z"
+ content="""
+It seems git-annex needs some way to verify that all blobs match its expected format for this security to be strong.  My histories have tons of huge binary blobs in them from when I tried upgrading to v6 before it was stable and got a lot of data committed raw.  I guess I need to rewrite my history to contain only verified blobs?
+
+It's really too bad git hasn't upgraded to a newer hashing function by now.  They should make a plan to do that at least once a decade.
+"""]]
diff --git a/doc/tips/using_signed_git_commits/comment_2_5fb568fcd3aa376d2ee36c660a4a02a2._comment b/doc/tips/using_signed_git_commits/comment_2_5fb568fcd3aa376d2ee36c660a4a02a2._comment
new file mode 100644
index 0000000000..2d321bb8ba
--- /dev/null
+++ b/doc/tips/using_signed_git_commits/comment_2_5fb568fcd3aa376d2ee36c660a4a02a2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-03-03T17:58:40Z"
+ content="""
+To clarify, this only prevents SHA1 collision attacks from causing problems
+with annexed files. Files checked into the git repository itself are still
+vulnerable to collision attacks.
+"""]]
diff --git a/doc/tips/using_signed_git_commits/comment_3_3edce6f128e96e1156601c6136118427._comment b/doc/tips/using_signed_git_commits/comment_3_3edce6f128e96e1156601c6136118427._comment
new file mode 100644
index 0000000000..5144396baf
--- /dev/null
+++ b/doc/tips/using_signed_git_commits/comment_3_3edce6f128e96e1156601c6136118427._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="aaron"
+ avatar="http://cdn.libravatar.org/avatar/8a07e2f7af4bbf1bfcb48bbc53e00747"
+ subject="Not auto-signing commits with webapp (and possible assistant)"
+ date="2022-01-09T04:29:26Z"
+ content="""
+Are we still concerned about this (and does this still apply if we are using encrypted remotes?)?  I do have my normal git stuff configured to use GPG signing because I like the concept, but noticed that when running `git annex webapp` the automated commits seemed to bypass my normal global git config and not add a signature.
+"""]]
diff --git a/doc/tips/using_signed_git_commits/comment_4_5ad0596373cc363ec9bc0b69efbac03c._comment b/doc/tips/using_signed_git_commits/comment_4_5ad0596373cc363ec9bc0b69efbac03c._comment
new file mode 100644
index 0000000000..7ac72d40d7
--- /dev/null
+++ b/doc/tips/using_signed_git_commits/comment_4_5ad0596373cc363ec9bc0b69efbac03c._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-01-11T17:02:59Z"
+ content="""
+Are we still concerned about this? Well, git has a workaround for SHA1's
+insecurity and will eventually change hashes. There are plenty of other
+reasons to want to sign git commits, certianly.
+
+The webapp bypasses gpg signing because it commits automatically and
+potentially frequently, and depending on how gpg handles password
+prompting, that could flood the user with repeated password prompts.
+But you can change this default with the `annex.allowsign` configuration.
+
+(Commits to the git-annex branch are also not signed by default, for similar
+reasons. Also, the risks of SHA1 collisions involving the git-annex branch
+seem small to nonexistant, since that branch only records bookeeping
+information git-annex cares about, and a small amount of configuration.
+git-annex does not use data from that branch in any way that would let
+an untrusted person who modified the branch do anything malicious.)
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote.mdwn b/doc/tips/using_the_web_as_a_special_remote.mdwn
new file mode 100644
index 0000000000..b326983393
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote.mdwn
@@ -0,0 +1,150 @@
+[[!toc ]]
+
+## basic use
+
+The web can be used as a [[special_remote|special_remotes]] too.
+
+	# git annex addurl http://example.com/video.mpeg
+	addurl example.com_video.mpeg (downloading http://example.com/video.mpeg)
+	########################################################## 100.0%
+	ok
+
+Now the file is downloaded, and has been added to the annex like any other
+file. So it can be renamed, copied to other repositories, and so on.
+
+To add a lot of urls at once, just list them all as parameters to
+`git annex addurl`.
+
+## trust issues
+
+Note that git-annex assumes that, if the web site does not 404, and has the
+right file size, the file is still present on the web, and this counts as
+one [[copy|copies]] of the file. If the file still seems to be present 
+on the web, it will let you remove your last copy, trusting it can be
+downloaded again:
+
+	# git annex drop example.com_video.mpeg
+	drop example.com_video.mpeg (checking http://example.com/video.mpeg) ok
+
+If you don't [[trust]] the web to this degree, just let git-annex know:
+
+	# git annex untrust web
+	untrust web ok
+
+With the result that it will hang onto files:
+
+	# git annex drop example.com_video.mpeg
+	drop example.com_video.mpeg (unsafe) 
+	  Could only verify the existence of 0 out of 1 necessary copies
+	  Also these untrusted repositories may contain the file:
+	  	00000000-0000-0000-0000-000000000001  -- web
+	  (Use --force to override this check, or adjust numcopies.)
+	failed
+
+## attaching urls to existing files
+
+You can also attach urls to any file already in the annex:
+
+	# git annex addurl --file my_cool_big_file http://example.com/cool_big_file
+	addurl my_cool_big_file ok
+	# git annex whereis my_cool_big_file
+	whereis my_cool_big_file (2 copies) 
+  	00000000-0000-0000-0000-000000000001 -- web
+   	27a9510c-760a-11e1-b9a0-c731d2b77df9 -- here
+
+## configuring addurl filenames
+
+By default, `addurl` will generate a filename for you. You can use
+`--file=` to specify the filename to use.
+
+If you're adding a bunch of related files to a directory, or just don't
+like the default filenames generated by `addurl`, you can use `--pathdepth`
+to specify how many parts of the url are put in the filename.
+A positive number drops that many paths from the beginning, while a negative
+number takes that many paths from the end.
+	
+	# git annex addurl http://example.com/videos/2012/01/video.mpeg
+	addurl example.com_videos_2012_01_video.mpeg (downloading http://example.com/videos/2012/01/video.mpeg)
+	# git annex addurl http://example.com/videos/2012/01/video.mpeg --pathdepth=2
+	addurl 2012_01_video.mpeg (downloading http://example.com/videos/2012/01/video.mpeg)
+	# git annex addurl http://example.com/videos/2012/01/video.mpeg --pathdepth=-2
+	addurl 01_video.mpeg (downloading http://example.com/videos/2012/01/video.mpeg)
+
+## videos
+
+<a name=videos></a>
+
+There's support for downloading videos from sites like YouTube, Vimeo,
+and many more. This relies on yt-dlp to download the videos.
+
+When you have yt-dlp installed, you can just 
+`git annex addurl http://youtube.com/foo` and it will detect that
+it is a video and download the video content for offline viewing.
+
+(However, this is disabled by default as it can be a security risk. 
+See the documentation of annex.security.allowed-ip-addresses
+in [[git-annex]] for details.)
+
+Later, in another clone of the repository, you can run `git annex get` on
+the file and it will also be downloaded with yt-dlp. This works
+even if the video host has transcoded or otherwise changed the video
+in the meantime; the assumption is that these video files are equivalent.
+
+There is an `annex.youtube-dl-options` configuration setting that can be used
+to pass parameters to yt-dlp. For example, you could set `git config
+annex.youtube-dl-options "--format worst"` to configure it to download low
+quality videos from YouTube.
+
+To download all the videos in a youtube channel, you can use 
+`git-annex importfeed --scrape` with the url to the
+channel, or you can find the RSS feed for the channel, and 
+`git-annex importfeed` that url (without `--scrape`).
+
+## bittorrent
+
+The [[bittorrent_special_remote|special_remotes/bittorrent]] lets git-annex
+also download the content of torrent files, and magnet links to torrents.
+
+You can simply pass the url to a torrent to `git annex addurl`
+the same as any other url.
+
+You have to have [aria2](http://aria2.sourceforge.net/) 
+and bittornado (or the original bittorrent) installed for this
+to work.
+
+## podcasts
+
+This is done using `git annex importfeed`. See [[downloading podcasts]].
+
+## configuring which url is used when there are several
+
+An annexed file can have content at multiple urls that git-annex knows
+about, and git-annex may use any of those urls for downloading a file.
+
+If some urls are especially fast, or especially slow, you might want to
+configure which urls git-annex prefers to use first, or should only use as
+a last resory. To accomplish that, you can create additional remotes, that
+are web special remotes, and are configured to only be used for some urls,
+and have a different cost than the web special remote.
+
+For example, suppose that you want to prioritize using urls on "fasthost.com".
+
+    git-annex initremote --sameas=web fasthost type=web urlinclude='*//fasthost.com/*' cost=150
+
+Now, `git-annex get` of a file that is on both fasthost.com and another url
+will prefer to use the fasthost special remote, rather than the web special
+remote (which has a higher cost of 200), and so will use the fasthost.com
+url. If that url is not available, it will fall back to the web special
+remote, and use the other url.
+
+Suppose that you want to avoid using urls on "slowhost.com", except
+as a last resort.
+    
+    git-annex initremote --sameas=web slowhost type=web urlinclude='*//slowhost.com/*' cost=300
+
+Now, `git-annex get` of a file that is on both slowhost.com and another url
+will first try the fasthost remote. If fasthost does not support the url,
+it will next try the regular "web" remote. Which will avoid using
+urls that are used by the configuration of either fasthost or slowhost.
+Finally, if it's unable to get the file from some other url, it will
+use the slowhost remote to get it from the slow url.
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_11_9889828caa47aad88267d0ec35f2240d._comment b/doc/tips/using_the_web_as_a_special_remote/comment_11_9889828caa47aad88267d0ec35f2240d._comment
new file mode 100644
index 0000000000..ccd27bf3c4
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_11_9889828caa47aad88267d0ec35f2240d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="thnetos"
+ subject="How to get the URL of an added file?"
+ date="2014-12-18T18:56:57Z"
+ content="""
+Once a file has been added with either `addurl` or `importfeed`, how can I get the URL of the file or feed from git-annex?
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_12_1704dcd7fc94432af5aa18459495c9ab._comment b/doc/tips/using_the_web_as_a_special_remote/comment_12_1704dcd7fc94432af5aa18459495c9ab._comment
new file mode 100644
index 0000000000..522f8c63f1
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_12_1704dcd7fc94432af5aa18459495c9ab._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="how to get access to urls needing authentication without private info in the url"
+ date="2015-09-22T14:05:45Z"
+ content="""
+wget by default consults ~/.netrc where you could specify your account information (man netrc for more detail)
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_12_2ce018f181e039b5dd52e2b712f63eea._comment b/doc/tips/using_the_web_as_a_special_remote/comment_12_2ce018f181e039b5dd52e2b712f63eea._comment
new file mode 100644
index 0000000000..7e3d8c9c72
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_12_2ce018f181e039b5dd52e2b712f63eea._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2014-12-18T19:59:54Z"
+ content="""
+You can see the url(s) of a file when you run `git annex whereis $file`
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_13_39122e2587f84633fda262bfc9d076eb._comment b/doc/tips/using_the_web_as_a_special_remote/comment_13_39122e2587f84633fda262bfc9d076eb._comment
new file mode 100644
index 0000000000..d7448cd71a
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_13_39122e2587f84633fda262bfc9d076eb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="hobbes@b2cacef69071743c3a831e60511062f7e014e52f"
+ nickname="hobbes"
+ avatar="http://cdn.libravatar.org/avatar/44b70169c4d862b3619812c360aa8f1e"
+ subject="Youtube-dl options per file?"
+ date="2018-03-08T18:47:57Z"
+ content="""
+If I have a big repo of YouTube stuff I might have some videos that I want to download with different options. Maybe I want higher quality for some videos, and don't care for others. It seems like youtube-dl-options can only be specified for an entire annex, though. I'd like to be able to do it *per file*.
+
+The main motivation for this is YouTube videos where I only want the audio. Is there a good way to do this? Best I can think of is having a separate annex for audio and video.
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_14_3a923511cf20d816b468044c03eb171f._comment b/doc/tips/using_the_web_as_a_special_remote/comment_14_3a923511cf20d816b468044c03eb171f._comment
new file mode 100644
index 0000000000..7fd9e7f697
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_14_3a923511cf20d816b468044c03eb171f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2018-03-21T19:55:52Z"
+ content="""
+@hobbes, there's not currently a way to do per-file youtube-dl options.
+The difficulty is that we don't know what youtube-dl options might be
+unsafe, and which such a feature could make eg `git annex get` use when run
+by a different user.
+
+I feel that this needs some support in youtube-dl to avoid git-annex
+needing to know about all its safe options.
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_15_8981dfd222cbf349bac3d74f53675fde._comment b/doc/tips/using_the_web_as_a_special_remote/comment_15_8981dfd222cbf349bac3d74f53675fde._comment
new file mode 100644
index 0000000000..da9c1ffc77
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_15_8981dfd222cbf349bac3d74f53675fde._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="tobiasBora"
+ avatar="http://cdn.libravatar.org/avatar/80a7d8c2a7b475b6b71198cce0faa6b0"
+ subject="Download either video and audio"
+ date="2019-09-23T09:14:28Z"
+ content="""
+First thanks a lot for this great software. I am also very interested by a way to use git-annex to download both audio and video from youtube in the same git repository. I don't really understand the security argument: why would youtube-dl be secure with global arguments and not per-file arguments? What does it mean for youtube-dl to be secure? And if it is indeed insecure for local arguments only, would it be possible to implement two differents global config, one for audio, one for video, and let the user specify in the command which config he wants? Or if it's not possible, maybe add a flag like  \"--insecure-youtubedl-arg\", to let the user take a risks if he thinks the risk is okay (either just one user on the machine, or safe arguments on youtube dl)… Thanks a lot!
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_1_321a41d611c6fe45e047af9c96c5176c._comment b/doc/tips/using_the_web_as_a_special_remote/comment_1_321a41d611c6fe45e047af9c96c5176c._comment
new file mode 100644
index 0000000000..ee1a271eac
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_1_321a41d611c6fe45e047af9c96c5176c._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlc1og3PqIGudOMkFNrCCNg66vB7s-jLpc"
+ nickname="Paul"
+ subject="can addurl use hashing once the file is downloaded?"
+ date="2012-09-20T21:01:30Z"
+ content="""
+There are resources that I want to add to my annex that are currently available
+via a URL, but it seems like if I add these using `git-annex addurl`, they get
+symlinked to file in the annex/objects directory that starts with `URL-...`,
+instead of the more typical `SHA256-...`, and this does not change even after
+the files are downloaded.
+
+My concern is that I really want to ensure that these files don't change, which
+is the appeal of content-addressable symlinking of normal files (as opposed to
+URL addressable ones).
+
+Would there be a way to automate the injection of hash-based symlinking for
+files that are added via addurl? Sometimes I add a bunch of files via ``addurl
+--fast``, and after I've download them via ``get``, it would be nice to have
+those files have the same level of data integrity as when I download them using
+something outside of git-annex, add them to the annex, and do an ``addurl
+--file`` afterward.
+
+Thanks for all of your hard work!
+
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_2_dfe9c8c49aadff80d2020288584e0390._comment b/doc/tips/using_the_web_as_a_special_remote/comment_2_dfe9c8c49aadff80d2020288584e0390._comment
new file mode 100644
index 0000000000..b015cdcece
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_2_dfe9c8c49aadff80d2020288584e0390._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 2"
+ date="2012-09-20T21:55:57Z"
+ content="""
+`addurl` only uses the URL- keys if you run it with --fast. Otherwise it downloads the content and hashes it the same as `add` does.
+
+If you use `--fast`, you can go back and `git annex migrate` the file once it's been downloaded, to convert 
+it to the SHA backend.
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_3_ed8dd3bbd9b9ae7f2309b72b94f61eb1._comment b/doc/tips/using_the_web_as_a_special_remote/comment_3_ed8dd3bbd9b9ae7f2309b72b94f61eb1._comment
new file mode 100644
index 0000000000..0601f30058
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_3_ed8dd3bbd9b9ae7f2309b72b94f61eb1._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="how to drop one of the urls?"
+ date="2013-04-12T14:53:29Z"
+ content="""
+is there a way to remove one of the urls? e.g. if I have
+
+    $> git annex whereis fail2ban_logo.png
+    whereis fail2ban_logo.png (1 copy) 
+      	00000000-0000-0000-0000-000000000001 -- web
+
+      web: http://www.fail2ban.org/fail2ban_logo.png
+      web: http://www.onerussian.com/tmp/statsmodes.png
+    ok
+
+and would like to remove the fail2ban.org one... ?
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_4_c1133a524989a940f1b5db588707157a._comment b/doc/tips/using_the_web_as_a_special_remote/comment_4_c1133a524989a940f1b5db588707157a._comment
new file mode 100644
index 0000000000..bd55a78727
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_4_c1133a524989a940f1b5db588707157a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-04-22T21:28:03Z"
+ content="""
+You can use `git annex rmurl $file $url`, which I just added to git-annex.
+
+(Also, `git annex drop $file --from web` will remove all the urls..)
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_5_5ee9717e74ca2afed98e81fc0ea98a95._comment b/doc/tips/using_the_web_as_a_special_remote/comment_5_5ee9717e74ca2afed98e81fc0ea98a95._comment
new file mode 100644
index 0000000000..b1060147f2
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_5_5ee9717e74ca2afed98e81fc0ea98a95._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="87.194.19.134"
+ subject="comment 5"
+ date="2014-04-04T15:25:39Z"
+ content="""
+Adding videos from youtube ends up with it using the URL backend, even without fast.
+
+    $ git init quvitest
+    $ cd quvitest/
+    $ git annex init
+    $ git annex addurl https://www.youtube.com/watch?v=mghhLqu31cQ
+    (... file is downloaded ...)
+    $ find .git/annex/objects/ -type f
+    .git/annex/objects/1J/Wp/URL--quvi&chttps&c%%www.youtube.com%watch,63v,61mghhLqu31cQ/URL--quvi&chttps&c%%www.youtube.com%watch,63v,61mghhLqu31cQ
+
+Is migrating manually required or should I log a bug?
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_6_dceb15bd656e69eefa3ca975d9d642de._comment b/doc/tips/using_the_web_as_a_special_remote/comment_6_dceb15bd656e69eefa3ca975d9d642de._comment
new file mode 100644
index 0000000000..0c39eb1831
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_6_dceb15bd656e69eefa3ca975d9d642de._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.244"
+ subject="comment 6"
+ date="2014-04-07T20:07:45Z"
+ content="""
+Using the URL backend for youtube is intentional. Youtube may serve up different encodings for the same video over time, and this way git-annex treats them all as equvilant. If you want to \"freeze\" the repository to the current one, use `git annex migrate`, and be prepared for `git annex get --from web` to not work long term.
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_7_0bde977c62a53c90cb20491936bc399d._comment b/doc/tips/using_the_web_as_a_special_remote/comment_7_0bde977c62a53c90cb20491936bc399d._comment
new file mode 100644
index 0000000000..df5b0ef41e
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_7_0bde977c62a53c90cb20491936bc399d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnkXKIAfgPsuV-EJpXm3jCc3q9IZwzvCcw"
+ nickname="Garrett"
+ subject="Default pathdepth"
+ date="2014-05-08T21:36:00Z"
+ content="""
+Is there away to change the default pathdepth so I do not need to add --pathdepth=-1 everything I run addurl?
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_8_3f32d536f51d5e9908953caf5736b0a0._comment b/doc/tips/using_the_web_as_a_special_remote/comment_8_3f32d536f51d5e9908953caf5736b0a0._comment
new file mode 100644
index 0000000000..c3403500a3
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_8_3f32d536f51d5e9908953caf5736b0a0._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnvr2UPmp7ABeH0yI8KGAHCqFhl91Ju4Tc"
+ nickname="Calvin"
+ subject="HTTP Authentication?"
+ date="2014-09-29T21:37:44Z"
+ content="""
+Hi!
+
+I have a somewhat interesting use case. My course notes require HTTP authentication. This is possible with wget, but is there any way to make git annex do it?
+
+[wget authentication stuff!](http://stackoverflow.com/questions/4272770/wget-with-authentication)
+
+It would be nice to have the user and pass encrypted with GPG too. This might be a strange use case, but I can see other people wanting to do something like this in the future.
+
+Thanks!
+"""]]
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_9_b420b1f320d620a9909cce5086c549bf._comment b/doc/tips/using_the_web_as_a_special_remote/comment_9_b420b1f320d620a9909cce5086c549bf._comment
new file mode 100644
index 0000000000..d6b194d69a
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_9_b420b1f320d620a9909cce5086c549bf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 9"
+ date="2014-09-30T18:09:04Z"
+ content="""
+For urls using http basic auth, you can use the standard url form, http://username:password@example.org/url/ , which should work with `git annex addurl`. The url, including the password, will be stored in the git-annex branch though. If you want to protect the password from being exposed to anyone who gets a clone of the repository, just download manually, and then `git annex add` the file.
+"""]]
diff --git a/doc/tips/visualizing_repositories_with_gource.mdwn b/doc/tips/visualizing_repositories_with_gource.mdwn
new file mode 100644
index 0000000000..25a69c1b7a
--- /dev/null
+++ b/doc/tips/visualizing_repositories_with_gource.mdwn
@@ -0,0 +1,22 @@
+[Gource](http://code.google.com/p/gource/) is an amazing animated
+visualisation of a git repository.
+
+Normally, gource shows files being added, removed, and changed in
+the repository, and the user(s) making the changes. Of course it can be
+used in this way in a repository using git-annex too; just run `gource`.
+
+The other way to use gource with git-annex is to visualise the movement of
+annexed file contents between repositories. In this view, the "users" are
+repositories, and they move around the file contents that are being added
+or removed from them with git-annex.
+
+[[!img screenshot.jpg]]
+
+To use gource this way, first go into the directory you want to visualize,
+and use `git annex log` to make an input file for `gource`:
+
+	git annex log --gource | tee gource.log
+	sort gource.log | gource --log-format custom -
+
+The `git annex log` can take a while, to speed it up you can use something
+like `--after "4 months ago"` to limit how far back it goes.
diff --git a/doc/tips/visualizing_repositories_with_gource/comment_1_01c5cd21375990c612b8f291904ddb3e._comment b/doc/tips/visualizing_repositories_with_gource/comment_1_01c5cd21375990c612b8f291904ddb3e._comment
new file mode 100644
index 0000000000..38bde579da
--- /dev/null
+++ b/doc/tips/visualizing_repositories_with_gource/comment_1_01c5cd21375990c612b8f291904ddb3e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm9IQStaE1el95_9s77CgmJhxZwCwUeN9A"
+ nickname="Sam"
+ subject="You can also use it for LIVE display now"
+ date="2013-12-19T14:29:18Z"
+ content="""
+hi, check out http://puffingdev.com/live-gource-visually-display-your-svngit-activity-live/
+
+You can use it to display LIVE updates of a git repo, nice to have on a screen in your company's common area for example.
+"""]]
diff --git a/doc/tips/visualizing_repositories_with_gource/screenshot.jpg b/doc/tips/visualizing_repositories_with_gource/screenshot.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..9d3096b99bbaba15008aa0d1b675b9db64d20493
GIT binary patch
literal 78509
zcmb5VbyQRTA3uIKY9mKYq`RjeT{5~mgbfu0q`ON83_%)%i3pQ!kd#nbNs(4kL{daV
zM8bgI<^B16&-woQy&M*=*R8|h`KZ_Pp3j|s0ucJzdfEU40s(ZvAK?59fa&-I`8ztF
zF9I3>3G`yScqIWhQgYIZ4Mt8*Mh=HjQo><yI3+b5H6;}-6&y}OPeV(GK+q#7sTmj<
z5RBkw#KlP<7e|ti!oUL&RB$SA^#5@??*ZsxP#aQ!1i}kI=^-Takn`672LOO~b#deW
zX9K^Hl95vYFgQ4EivYk2L&=~dWMtqdB?TM;KuJi+=*f8)B-P9uC>VMDqG3$eG76db
z)Ejz{=9ByUQW|%fE(r+wH?B%+IXMRg#S~Bdkkzzu%*-lc5t6a6v<|?RfTw1=IMe@q
zVE}+!oSK{hoK&U<Zwmq?B_St=kU%LeZVv*bCn4n_124;H=0FZ!He;XZT46))Bp<W-
zs`(EJ<i&;kEn?0W0BREO-1H>$fGThTP#2k!(?e!~P-;GsD%`aMQV2>b`8i~Q7XpOR
zMze5S!tEwdbJIcaUX(ze1Og)AgC9s4Ks0+pJ+vuF+1NT7ST^uw&}S^`xrpsSfjfew
z+NuI~B+BsDCI8O0EuM=0NUruv)z>v_U|F_(_!6HpxY=l(3-=CT#d^}ZX4VCx`}Wk{
z`MQqJRP#O!OlZ}gr*FX|J*=a3T>3!M>(<L<^((u2;+auxZm6jh<}y|?jp4oFaYS0M
z93RD}eTuJR_E7?d<%YIFMmrwW+-*^lKVE!Xco6R^*+aZG-4Lt;lRsn7ky$tgG-tGZ
zlRWNEf1g-82WsrIocW0>l|MH!*8-Z|S!r}Q`oeZx1w9-7j9-1H&?;1Tnak=>y4#K8
z%2!|JAZ9;9+eZMdeSVkyI@heTO7Jx1POE{n-RHux2OTRU<%zC2th;jl)2a5!DZjJJ
zf9oAZ7JUf!MwwN5%SboRK9NqhXnEy~TT6M<gM(85wAig6pVeO&<#BSMG51jkcR%+Z
zp($3LfmhKovcxXTcg4bb9kPKf-;j@u{zsB29(Np6+5nYCyV~$(X|DqV$(fqCnTchQ
z*qcH>E-6F%?ssVWE74J9dW^9JA8LPLzLnKA;_8vstTNEb^NE4=C@pT$DHa#@FM^nH
zIB4?maI9<NdF5)?Qh9WfuFFRjsvc#@0Xo>=6>&fIfNkkJ1jB~#FrAM#eadgIXJsaB
znK=4YyjtXKjqoLqKOk>O0RTk+8TZAGRd6z7mT|$MEVTn0PorngZpcpUYrp%EcP;vZ
z$_t|_Y0n?se&bL&!}z9bQU7#>?h@1LSOA9Cv-~rSGI~p(pA;%P5MUART=ES$|243b
zJs4Z)m?Y}<aCCWknSvK>a$TJ0gb2a%WJZ1!OFZ^D+I5<7_|fpn?bn~B{@>jdsAgnr
z1v=@wY&>PI&dbZk@vE+?-|sPgs&!a#GZHa#bIO)_uOYQIT>j@}-tG};q-xbfGctX4
z#g*#iN`=pO%&1py_M`+|@_{4UXhQPFpgflZa%{(E{_}Y8;qK!U)u5^hFQ&V;MK#oZ
zl4-9on8_IO6TYCwvNx>@Rjgq%D&Za9HKotUGiqgRBUXyK-urnB6jaaruG^@*bL_fo
z{R#VRNFxXEz{tnnLMGQZ5k8nGR906K3b*{f!1@0U-?oc-7RZ@iFokf3S8VU>$;@X=
z>-Kzi%Zp{D?Ppt08CDfAnZ0i)eN@whO{q-B?rc@3vOX-bhy37r?Kjj0=w6p-Z=7%@
zUcHpN__0g1aMre{bW~^b-W<zZX@|<`)yBPh_;5$s{HPa7e71a!{qFxhTs~<yX=@r+
zT4VVUci>&zq}YG&d4ryC_TjZZk!Z(<CC+ufn`0W?o5Q3l6+%#h*-qQ``Iq$qBdYh3
z${225ihKCDD5;oF<Z7Cb@AHl;Zda4~V)+xVB=uQ*KGXkMJYb&Bngo4R%m<@_wr!t!
zM^CO5#qwJQP~zS=)&HHy>D^9;Nyg4c#P<0*a4_wM3bUlrQ7v&Y8iww@V#P6CUNr%B
zpZ0G=#E$^CDPoFadyQ5PI{P;OF<h{z?W$7z$T3|OK>Y6z118_U6VN1O;nh<i-@h}+
zP&8cJtbao(wl9?lh?ymOxKR-rSwOlUs&0E=yt;3RJVC=&)iFd2z6IcJ?PHiZm=UOe
zkX2Aw#mtahd@!&WH6;{KZd4dV3K0rWXc$TzoB!y9*3#Dj;EQLUK$a6u&{#YG?q0d)
zP9Xzux4_+$W5Vu+RiOHeaH-VXJj!_5%LWzOYA{`6)S^AUiHrY8ZAQ&ur=XeiGa@}Z
z6`wIllADJK;}O@rL*-x4)Ghs4iHA=ZBG8$hk<~Z-R#<!o$DnOWaOn$!z+n(&`OSi4
zroN>^vwos0M3V=l++&2|$fCysb?iUQ`tgwhq0L!95qX%f@*^rsdzy4;{f#!g?Hue3
z8H+H)j-TU0lA58osC-0GUz~58ibQgAKwmPc&6}%&$kb3XToOWF<#Bxk?=Ahg-rn7U
zly<&bTJ_8^uTpxoDV%z6O3!_ZRxSFJxFM?)MMQRgt>mjBJf`w0Sr3R6xV?uGkci9L
zY)c}myQOFfnAKI(Igl%sc4l<-U*_|D2a8u}r@7tdfcE3FUgLN*K9D%LnJ9-fWvP02
zUD2E*RT7F77cT{LkXaTEOGuU%42sr<?sJ$)bHiPGjXX@79i&Ntfs}p5Vz?)pvr4Qg
z|0Mln+OTahzxK77!QYjz2Cki2P3F+P7KDYmbIwBDq=}4xrj_M)al)k++VTOkZbN)K
z%<{+9#guN-yvIs`s%}UvFQ*#@S{~)p{hjgB18b@4F;a^ZJIx+C)r#%8FIp|lS>{Gw
zw4|2aGmND9OY?4!Pw3wIUqU5vWLk-=D^kNEv%PfU4Grxxj+yYM+D*SqtiOs%xn`z{
zD%!%1v5ZN{ISRdgUx?8`X}X=Bt!~RA24z0KYD=O>RNBfSOi1Q4(L-$XqxY$d4uv%5
zTL{&m-42JA^zgTrd!DSX)`t9fHT=DPrz`%$?@L-A0~fz#+HMz!I~;M5qEaT=J+V01
zA47FzNhVb@T05t+hbx`;1~{~<O-gd7h5vfA9z`C1HL09o-P2b>Jshu0rHoc8r{TVC
zh-|5$@W0O2JxW#o#a89!^a7`d_iyd+oJxDn8NZo&D;C^hqFfM3S?G(6>>iaXbq$NZ
zS_t3#VkC`BtOxa8Ut_tCe+HRT)jBHmt}4n*e!&0_u#`sa2q;fyUw_Ib74cAwZ~gu6
z*(#?Gh#f`D?U%hqY?Uc&dA{4jWJ|_pN9Ywcd#`boj<V`m4vUhNpck&Eu4g}}l5a;;
z*+0Uk5a$NA29eiqo<u(WCVvjth+Z*&!=Y8Acr>zy+^FLQwj3+gMqfRz=c@MlIRO_T
za_!Y4+snCQWO+=q#vbPzN1e?z&bVhBd??QSSU%OU@D+6i=Ps|xQdzJ6p}8-asqiT^
zO8dHp>#rN{msJ9%vk6bFe4kgep?~}GxlyM)C%q(}F4rqhQuRK{w5oN-3yb-~H?N$P
zvH#AocXR<BOlL<;vVOIoQ~L0OmRqNY?)Q0VW|<b#YnYD8LXQ=`r3qcKexBljvv%uk
zLa`{}G5cfQy?+r=hYG(p%6o-(gplihu4-)jBiqp~os=!qLC@{D<r$oPm*m4g8Y}Tu
z&1CDYTKN3ye(TLPTkTQL&!Gir%4BoBR~1GZ;at4dlV1r>8ouP483|;PTTCx4@+FJU
zCr3~P^eK|OmfgRhB0lf;^VNczGVM*;7jO+_q)lD9UHiXMk+V;CG6!$D8_2q_MHPMj
zefm!I=mvuDqU%p^ZMWUcC)J#{cB!c!4TX{b;tx|GX?^9g#e(4$QB)4F{z9!ue5>~J
zoT+?<x1(lhf%k70SrqR#(kAs86j4%Vqy^q%$VUb=4k_{%bB<6uQ|NR{x9W5YM84^;
zC|b!(x~w;Of_B`m>rknG{Ot%XS@fJ-R+NglXk6GpiT_&LotU@&*3?lrv;G4#^NId3
z+*thdsxJuKt71z6N{joi9QSdIeK*?leJF69;69YABQdY{xH6CF@IWf!6$WI6&=wGj
z`(no7OY)`|90PV$hc0W6j*`k0O67}h?F(~fm;qu|VE<t`Hz^3?`~L^<p|kd_eNb?A
zMw!DZmA1mblq^J!FOW8^u^tmQhGrhs(Il(t^}&;JlPXj?SM|DI>?_qsOGi0Kj%crx
zCG$rhi0aU#lJwuO08;{|+eVJM`qd%P*MuV&%s9XlnVG>u$|L@L*an4G2lU*bj0x(t
z%OKT6r4xcocpx0$Aj>*FwNSpbieW+y1`#OP!?#u%^N=H;3F>N_j7ffDYAowG28^y*
zbgEuy2{T!7t~e=C*H_<<!<6u7QjDeXV=3HKg)!6;iNi7BoADoL+syj29$Y0;b9aH?
zTHV7H+VRjzHu}JJ3!0gLW`54$9FE8J2<U#qRr@2&S2zla#v?kXP?anmKz=_SUnYX0
zL|@H3P$t`@9WD$a(`C_QRj6D&$OS_EOXOhvzDe<Yxh#;bOKpCWEHK<|NjeqHUe&F0
z;Ed|_IZ!lu4%pYk(}q=r44eaRACsH|nHNKqrjqu25HtrpWYXMH_cBN&+=8^aBt3z!
zp6vosdu}+1aE~d4rhPD)fx;3r6eF^D2)AIfC!$$U8$rS%+ZUk7Iqb<+E+L3ll({SY
zK#V?)S0Jaai7N;rb619+tS!6ZuV{vtU$(Sn18Xb&NF{3vLnfot!fmr<>DmRc&N9>C
z94fmH_bxU6bmQpm^~S`1sI>|#B&=xNbrx@IZu-t^A>yh$str(V<y{FtUWz;nnDDT!
ztRJlW<@Ael_SU_x1|%of0o}E*fslb7N3Y{|mkcycYQ{cIcXn$$tNkm>-{f+W)@}PN
z=3dJz(|gv$#};bbQZqwKezJl;X~xZUIi>RVyV7Rw;lD(eZnVzt9aq6M?IhcloHMWa
z4NqS3MTFy^o4M7-&(wd#Axoxz(N(lsDon6Ahpu^R8_0L8Q^%&QE<3eQEND;t@p!7G
zhebJfUuLSIcD#A^v(f*$L1{_qW4+YS7QKLTfTLn-$GLLm-Q~dAgZtOZkueKi)8hs_
zZzqPfo%c8M=uhK*JxDoZ?Kdg?^0|BYIkOC750|v>l5-3!>45=eKpsl&_b6{o$%Sft
z0q*WzQt`anFEIPs6T7v)#{8N0uf5!e{YI~+<&^lyRKt2C!IAo!de6}adLS&Baqip3
z-PJJZ`eC7G8+VBUG=@J0d+xK!(5RJ)MDc#`^kUZ7@%mNcm$uyNn<gJY=YLIZSAD*Y
zv;6j<7KaLoqrFwhsb-9y_`@-0e2*hReqF(nA+YXQ?H?@<x#emn!gBd;3iXMul<pQo
zsG0&~kS)Il2pHM!D)_BcUaM$~@o@Sn%NqOyO*Fpt*5@^y<T^@zf3tFP>Ko11)5W1O
z+x=E**8HuNla;rpO%^-Y&9<(_Z$Sy_LugMkX~f)O-naZ=p(nbZtgA$vN-Lt2+twU<
z2e0M=Z+eFnjEyZK@)NWr5|hK3-`-<l`76e&{G4Uh^NHT%RuQ&n|GA<nj5@;Kj6ab!
z;Z#2`!oi7)!Jyd8DI+Zs>#rYp3#m03suy{S3C{8psVI>1N<8-ScGmU_vjXAk%30)B
zcD@z~b8z7wm`k3(4DT^FapA9|^`R{!k1oCyjl&G>L8NrS3*_w8ARVh>mVSY<_4K*#
z-|5iE=f0<C%1@w_4K@CsEar>tJEp*Ye#3qp0X6tf3Gbh1^sfT^4InIjUZIpXh05P^
zz0k9(YVLp<2#yEiFoQ^LQe+`Y1Qfa;YMK&2S*wo0i4iJ3?Wo@;-=Q)k^Ix6-NB@(+
zXbchC%@1NCvhZS>!n|-yuU@qMX@z)S{bniQ#2{D^p$@%9)J7nknYf_sK5=9@%Qh$j
z9-0&$S`Y(A!-d8BG{p8p)G>ML7l?`=Yy}>?zEIu;+`h)B{emX;2`H7Gx-EW72JZIG
z7l-(S*v~qcKoE!t5VAIPOoY(>vAT|C%^fPKF*P4UAtXZqP7%DHM-68Eu^oP-DKQLh
zzt8eKM3EG6GUTV!<C6=>kb4Eqf&?Z|KjWBF6D4#sr$E3p;RlMQ$3Saw?OHLu06^^&
zL!|J9s9rP`ihagjkPs6O0fd`_Z}q_AirLfmQ-=Ucd%m7qG-M>)(gA&$6KN!kM^INX
zd)h?wxU_To3RQ2R9*h%_AP0*Luk6_^dq68Ssq40>E^)0?kBlU_l1BUeiB|8t5jT>h
zas_kWVd?&%UiU6@=4xN@J&GgdK`@SZde&=Ri@yOua9HxOzxOY~E+aT@;4~?mASe#A
zW?>TH1;qk5goT3%$f3}LaD%W4TbKdSQrf=4ReJ)*^1fV3d1~$&qm3LoUh1@bAhUN;
zC4VM8iN4zG$jYW>AeY`bamES3Z1Y=;K2M}fFv(MNM!!TyRlqO5qml<%{O^YU;phiN
z8mY3PhLx>Mh^9R6lLm!v0aEom1?k#;qm8Q#VrGA_^cnLWQ#*}rLgUF}mD7&18jpB7
ze|PSrAYVlZ)Q#?qnvj0{QyxJTx)KApDt&^6h~4mD`Rgam?muM3ohZoOC@6jGfxh8r
zHbxA8`0CNlU_7<2nq$1Cjs2H6hm@h-K0^l^d(p<}qTd=jriW)$Wx189f8rcGh}-jz
zwSTlC$=4m9-F$!?-%)*T&DI%Hx9FUU8Oa^Wr}$kyFxUTp>Y*=b9tVyprQxN&p_lR%
zWo<#m6+CM0BsJ0|64se)E6w8X{G+5*R?;o=XUXRoiAalS`Nks2w^AguXCBbYXX<l-
zUi-G*?96<rsTC0x^#|PFvK613ura@V!8oXAs<IG9AtZfhyV<_>uIp~apXb@R`*#&Z
zKJ7p2ZFT-MmQCHjoO}<#a&$wb8^i_v0rNmN?}xV~IfuQI>X<I`J1$?smuo82#1_q?
zegx_j=BzPT6b*~<Zr3XaC~{HqNp7M}1v;)${wW&NEPwN<A{zY$lwi!qI{0#(4W6vz
zC{qQZRX-QLRp*m%v}seB>Hev;-FPO2RNc_!n{U5nvtPG3xvm>}T^C|^{YG14+5X?h
zZTBv|m=ac1<JSvX03p1vI0zU8O~MdmP6VNR|L+9oWZ@{#4BK3o;TE_L{y#G;kU$k|
zg4+LYOo!Ye>DnvIBl{b^eb8BlF*F7bf(3%OS%5MG!9e`omyIWzg=72R4xsj_CVMGB
zD4mHSrN@)yTgAMqu$!3+5^Kl(L}TZb@nms4*-JBI?bcNOabuwKMQ`Kq2TKLwgVI3E
z(g7M9=P<TQz-9sQGH?fx4P1cwW&tSz*P`51#UOcrhKVmzJ+K&+8iT`aMmF*%2#0X+
zHDi(+VY`wWqa=iMhI`AwSTaApN=L3LH=ns0pwV!?Muz3-gnfJrj<G+cu)oR$&Z9#s
zD-7Xh1R*7?oPH9{f~G`~X-ni_ERp=sgk`nMptVk4D?>o*BZRp#h9zR?1a>)xSPBq?
z?_+ZK=g3_gbN>e1$F9ux^cHH|5~xEYNIU3yoB5s^LRP7kc(^DDEqZ{m3X|^<yx^*D
z-i96k>0*k`0_7GCn#lpBK$pk`Ius%ttoeccBTZHvO*?r_wpAl;K*nr_1j&|u4h(Ic
z1NGJ>ab`0#Z(=s@A1HuuAv(vUj)V1>DilMUh52bRqUSZjib<+~bVWXrAb<}7AUMpT
zaRoG!(X)Vox;=-bv>>Dd_=(A(aHfIdF1+-xv8#v|{OxWu^<Bz{Yax2B17CLc5F}4l
zZSH7>n%rHH;X&G1CCuIxqbH8&CA88H?5y9i5<aqC6V*#-=Q0sp($CYWYQ1c3Xo-D@
zO<S*eU8`A=Q_+gBcBE_$v;GX9tB8O`V6s`P9XTEW3(M`OpC(<X+xCx)tX2QXW?dFu
zS04XUt?i-T>0Luyyg}n7HR=@CJJ$P;IcIC=cw5`7nHS^cwh_rF(WpD@ksB5hAM4!d
z{>MvYbCI_3g~T0GHk*O8zH{I^N-DO`mTzd=FBt#FojO8{oieH^6<al&O?~frrFW9j
zr|L3Q7zbxqMFW^n?U*kk|5U$AAt~NZe;b*xexM(CTP8j57Q+fx5RzPB(lcxOz1rk%
z=E>A$wI5lJwXKc^R|O_d%)snwKXWtm25}sI#RZ=;;_ZSbzn=3CBxXu#$J_*FdAd8V
zw!7SiU7Wvr($4~xM?Kq}y=Obke77Wn;S<cEs>`>;&w(J!QJOR7N=zcXVS}2(X|-`$
zALHfS^pQNVH&wk3J8^G!qO(UWeNT*07i<j{p!e`b7lKeg3PxJ{&Z=<{u^bHc+$~hO
zL=3J)pp6*}rY=}|^TZtbG8f;Z!gvBPy(mr8JjA^oL)Zi>k8<N>q4-V>SPbq_B$ak8
z5ce?e9V(@Y<Qf}%tFwJ-9BK^xTA|Y0C(fz0k3uf;7wC8-J1D5j+jzu<LEhFRYqO@(
zaUy#Hj++w59QykhUPJ7fkJPczjS=y9f&3|!RCX}`N=@u_6Q=U(&_LLj5^zLpeme3P
z4dc!d$N@c$w<%P28{hm4{-$jkj|Va*XCWLGNyh%Bgya&a?g+zlUe>`3yHdfOBvYc^
zD{f{|@Bi#h|FRsuaJ6@tn+XGrksJ~vB=ZamalrlYGxEz2G%^#kDxZ$jF#*F!=%}$J
z`LQ8N0Ot0N5ipQ!+v)7fQ5zHhIEQia92w-e1ZX&K?`{bWSc)>E&vGcg+;@;k3CIQU
zygV>mrPQ#T=%v|Dkp8K8IZN$jH3G_-7T>|W#7EN60CcgFX_!f|hHsmk1C!vdeNBPu
zX2b84?!(|O=RhGiLS5O?L@_Y{nPlNWM9;FRzjlF<f(B+g8C);9ples{$ytC=-BBHx
z`tYLiwsR)p3MC5x1Z+W3*wv7v0L}1zRk8rgz3e%lfGjnBbC)m?RxSaJrgjP36p&Id
zw%=hiq-eUI*@Pf@CS#jFXyqI&i7Z~KHVd)hlV|g;)#@U*Oi%J-ug(ax{0tVTE>#2j
zC$S9A%Dy^H^~^h{*R=yxudUkJ&w-D*cZ%LRfMJ==s%^4kZZ>WclK&`IkvpYw7e?Rg
z>ai~SyLF+?CaCL^N+l+oai|LO%*3d?uF*{CO2S{?SN;KXsP`hV6nvgn;(R`RP_$pz
z<X-klzKSFIOSNVP-hRlbGaGo8&>b{C9($=xQK;im!+-)SW-|{-w0|CPkC}gD<B9sF
zGv?EeIL?pc=8mE)`%)l-t=a`hbs-d0$uymX-h3*(E)zCcdR-MFNJgR4%Kunv^>$!{
zzh2-yCUn8cUw%bZ%D)*WqAznEUDo<>B61~7Wp=Bn%sih9oz6@hx{e>HW9iaYc@7b!
z68U4R$!q;u`3Q!;4h`ge+-R9&HBI|B=9&FkW}ukl*?8O<UCi@8LLH2Br+vcWgNhud
z+=17TS`#M*f!8T5l_cwuC^E6deM8r;!ofh>h<3#IuKI0?F>GMyHeqwO=vsphUZ4`p
zlM#~2@&^Si%3yV+nIga>Ss9EJX1Ng<T&rlWkESv=|1!vEp12kp)G}(!pyK^vLVz#6
zNoiHNNvRNJQV@gyi?y288-a8QqEGm=g9mxHRfYtyS+KfS<9mz-c@NAUI+<gpE|Tay
zdjsFTdRw9{mE;(hdOWuT?*SC7ed5mkU}4?8r{8-wtPmy2eFFss4a%(?ptQ~;zu~)$
zZ>_4w;v41WxJff6A*9LWgb=h2m|IUEGA8Bgf2m{Vxe+${&?PZ2{6;UrSYoCueWS;e
zE`tY-p!t(`@y%JEfpr9ZS1(DSKotyLnxIQk1Wpv9M*KJcb!?YJbmA&36fIKv@`4r_
z(7X85UU^(N_rM&Q3Jj8CQ+0>>4ghO9=RJ1sC;eSJp~1#I*6{6D+6tsS(9D@0tlAdd
zMkT`@uhwaq4u$NN7P7c=FJ~t}P-GE!!Ion7Eb`=PMDJ?PJd4|IiCmRz^O1#`CXhf~
z)U%r)gNaA)pIG@=|L#~;3iIMn+K^auFMou0iIIK%d5g1$EK=sK@RjD^Z)~-d?($fa
zH?cNRh@<uBHX)6uv);Nbee%opy?EnBlKIN&W$7+2fuEF3#OQez7}}7e@$+RpcL^r2
z!Y>O0xibTJZa!BuDbyZ@Q7n_@hJrO*gv1Zv0V8+{48zEZfPiE>Nrg6Y1uMI(*?~&U
z&=m$rUY3bvpTg}DC$nH4<fqn`J2V~1RNBx;+cW*9%T`bFUxNRV`g(~;evz|7FZ#;q
zcWd8_2l4m3q+hSotbFa4GCOqdVM06dU-n!>%B*}a2lG&Sr65^bW34u`P3sL_j+pGk
zB>I%>2ef+hX`-X#i=?k5Q}!E!l}e2=H)sa3Un>eh(aM9S4ZGfp<<f%rN@#D)=P?rt
zYSyla-edjMKby_>s~=TheD7L+DeyjgJyv#QOIi-n2R{eyp5ddcDbE4N%IOcbwb>|z
zlogT=g-*&=0lk3d&t4}k-o4W%*`{twd|JML)z`C<|AzQ}^xM5!kOFLqbSpLmREW%j
zQcjO00gC`-(eEyCQM>auBGi+h$tiH!yMM&SU9w`{=9LUsM8M|72dw%p?;`%(=dYmb
z`Vhx^_1LNqp+cV!DVTvAiD8^)wBN6TMGC&4IR_{+HL=2fxb}*UXcfe9<zM=e_SPD+
zDc`!(o90lCM6L8OntbBR5`TRilHX^rIw<fslErF0POGr&&h1P1hrIiZ{_4zOeES8H
z{BIrC7Be;G8n5YejWj3sC23|Dy&V@|XJOBd<)q!F3KzbnPGyP&y)Pe3mlRom0u^g~
z>^(hjaR(HoC)QM^3RNoF88^q!*lhb2IvD(rwus8F5u011P(kHiBvT*r_Ae+xZBTs_
zG9+T{6`>L31joQD?m*pUfw=PYsA3^s5m5ID-&7UmVo3{wfO#R?hH`U&uz^&E^|c0f
zhNVDjD!+O(cBM!IVVgzk9+9iSgBsWXZlK1cX<gy#JSYy(vr|Hqh1yFYE`c~THzjUV
zUqlSU$8DCFrCnSz&GgVNzO@6*oti+U1adoS$5fJ(2W8Cd4>Qoyy<>o$hj2*bZQ}WZ
zK?A_g6QCpgc{)p=7!=0TJScu4f6#9W*z-4Mv%p^ofsh43LX*(y+KdUiczg|Mx}|;D
z{skN3Xc@<;mV~NY-TF8ga(Y&K=MB`x`JKxtF?7!Sl1}Ug<`7ttKKBZxEBZll@hS|r
zlF7|9v5lCVHv!m+R>>~Wp=;1o*hvH|Hj)=e0V|(oco-g?&-CC(o2{{hnw`DIyMpA8
zOz`44P%(ZE(2R<|2S?l#-M_!^Q!~AP>}|38`ZtRp-iyPuHPfEslJbawj^zLz1;=^f
z;KfxS1>?P7KrSOI=$sWmDmHXAonU081h~PXjqdPJ2MB5KT23%>{I9BAP2Yp%4R_to
zo$xO#5R_&DhI&jq%x$h&%)vlotzhk_o5m(4Sw>dz;P0_@(MUC0c(ot3gEa4w!XnSj
zB!DJczNxVtrX<3BrN4c>u7BEDpTTOVDZK=5mn6FGV41)fhfQ!PN=Fs}Vv_5Jx@mW6
z2J7dgsRPLMzj3+TH{NBf>u5Z!D0ViK-I7V4>fY~CmwNqU29iu$@_pFv0jf#uYjsy#
z+x5ETKSM5%rk<O9{3IFU>eqZjHm!b#sb6Lso_Nmdjne!r_x`F$^P7dfom^4HaHVWE
zsxMm!zK(4BFWDFF8z*_!yLKvQ*q4{rmX_D$O-nwSG49#Y4-MHG^7d7_`uNvYom`5U
zXXdb1i-G0>A!m!AC;!nVtfh?wIQ}+&S9<ID<7$;ewxEMWRAjw`gb~w{K#!+<FU5Vn
zgPSI=zq~T|XE@Gjj8P<upETkSs`w=%r8$qH*ZBShy~W8D`jSP(fI``Yxby%yy0cP_
zF+VLY@lqjE5eSlYo|)F1=$oQgmEW9BMzlq=oVB&?$akX4JxX58Xo}=hMSH5Xj{~Y7
z-~Gk@{MMKf@b%5-bHFom+P%d{^Y??Cjr@ZjZPLkzw~*vx(;v+v*R0+j{rvL}?(gKK
zr0~kbY4YLap<{FG7!4C`c{$Df&qDmc#(W)XO&GEEmrRf4`kGhA1lBkhpw$Z*d{&ig
z8-i%R#w6&|MdCwa7w%elpHw%kmj}Ae0i1ucBEq(x^_1u=F~J{t-eSZe!<hyKKb1GC
zaxhJC&k_1Z@8r$Nty?|N8dk^<DN$>3o8nCKh;q~P4vuid>SVI1XvWCCN{v)8c}pFJ
z`FCu%d^kH|V6+!^I4ik_`PLt=4x3Bki3%zRib`$L!K&WfmlYN%j$ibVUwV(j==iFy
zuDC|ba@;FvwwQW5Xu>GKOzk%8VQ1Sz=h&30e0nqTH|);zN#*y}ckg7M-hL`u`Z>$Z
z=ZB@gk7M7WbXrOHG<K@1W7xyB#0|yFIK=0er|@7aB#InKx3GU-;FnJ+rs~~4h+A1n
zfPAIMQ|cNY*`bv;8SCr+{F}C$8)n7^ZYKTuU6bqSZZrF0{85l>X6F}!N8jXjE?HPg
zI6>7so-Wt1A?nThQ<K{Mm9)^jsPk}U7nJ)jC{+@GQ48SVBjsGuA-z9q=Wp{;G$@C!
z{Oyl73)=aDVJ@%BWsGv%cr7=Q>X3I_Q<+5^HyfHg4d3W-#o7MYa4Nm~r)o+kHL;RW
zi=v5*zcb%zu$4?;Y%30GZ3TuHd7us>L112C8-3jwW|2@T^HHmKYHl#0C~N=|z_>9J
zlu%Kcj|#&MtO}doQSphdsD0OK7>+;a3%vFy_i_L1%|QM@{Xk96Z0f4b()OzUC#!I8
zSzXGFHWqaoA~x%aH-aog2I6DRoXWXPWzG`wZrdPS40KA^R6XiCES?tZ0;tE%6!?PH
z2|#1?tl3|awXNgC+6(+)>`R9xC;>2F!GSvpbZ3V71d;}Vl1p-kTU^Cr)NhRB={!#Y
zAIty_E>z)~OC<R{an1i2lh9~Pm;)d%Mp6V-1Vti$U>~67k|of|nB<R-ZnTCP=z-QR
z%x#2Wf}x(_lM)X~Kq<Bi3{D^Lx4_-~TsPv_g&F~4IwxhJst~w3wgVc6{5}Tp{_@Us
zvp81yk(zpsDK;keeKtS4pdu5-FYXg9{eHHxfD!d=+Ixv;Lz-KwKqU`?d?`bkc0`BY
z2spInNoVWk_wwGs%our7HUR8G!aXZN{OrXLEd3;;U8^raT7*Wyx{#A*-p6|JCh@9v
zOXu>K;~s<U6*Is5w_Z%+Cpw;6Lfg$arC)ko%hlgHbWEqGO!}E`)>Vn*Xlq12?El%T
zRM!praA)=Oquu1DUDIvy&r|os{soKUv*bLQWVq>DU@V4^uwuXnd?T^IK!J1+&RZl4
zxJf{OM^9K_C;w-^{wL9D|0mHvjOT%XE{siGHjV~f%aKmnEZEHB3Tige-i`oFbfF43
zM<H-m6;2=LE;+i6<3d`srNvnbc=I%7G9!!RZ}19OCWvJ?NM7O*B5@ApwGwWud()Vn
zl;N~$mq6UfyTv^8!W@lBAaj?@#;D9zjH7dqEJ{L6eVXq5jF4Im3kv=hr$!WI7WCcW
zAz{VO%PS_1x6<0}$hia3epiMwSGiL$-_7fo!HDHxPT0}>o~sja>LOfBDFh)xXFN}T
zj#$M9wM&%?lC7A#u~Cgp4}#O)NNdzB%_gm+glL8<DcG`ci=@td`neH1NzyK=ml(>C
zNo35+`h-LLNKgM%quQv^mjrERD?m{c1;pc7_R`<@o@l?1Q&wrr>7A6;B6>grST5x(
ztp%Pe4jUmHbXew9GLmcir@Bp?f6<wpjYb(%R(zTNK5IDnnA{0?zvazqJiieWGH~hU
z2QHUR87+q>>&L`8(S_hk<m18-E<NkPEJB5Bp;$jRf9Eu5<9kuT><UPc&a>ZnCR$jn
zMT<r8gJsbQk*}h~sV=>eDR0`B+ey8{=mer3h%elFFyfW<zC+e*-}le;X#+dOE!6~K
z$zFJ!?U&a1qfv`HC0#pJRjt-mk}dQaCRbm~vHD^&$qi09?P+gW`(uOKS-YO;ntm`J
z^CVm{{F=Ng=xQ?sadYK)9`>0<iRM6iP{jyb7U*U;yL~_E-IZ=}8Cx;-Zq$m;pMMja
zPh2@JyLR8c;%6~ErW~ZM7_3XuwcR)H>Ot&K=3eBF=oOjH&?ZdP;Tx~_1P!g*YVcge
zDi;=_M#v|Dwjt&E@VuIh`(=_}^utHrWxldLo2mS_eh%D!x|~?~$!h>Cm;&(uCHlrf
z=fmICGbvKcJ{A6>Cd{U5UM~{O2XJ(K&i6L9JaG~fcElU!K#F5v)pzfe+ua(9!(qq}
zCH*c{lWvQ3>j_!6>!;G+^T(C#OqL$46WyKCh@-8yy2ihky`NDGegm$~&Rdo4N$Hb3
zGkm}I$uE`ne*9zNmiz2|7aBgYxO1RE^sB@3hfkcQ^*QI+!CV`Hi*%&QIH8{MvOWj8
zd-l47%G0j=i&Bg<A#A1P7Ahg{Hs<e}prmVGr*}@ObT0=O!~XUSydB$bKd=nq{T^^x
z+%d@9I@DI=N!Lh8#!t(k29_^u)9@?F)l*XSx{~V^(x6c2%@ULd7t=<4=xi8;@MJBs
zsBiya_I<N<XaF`86lRTrIK`n@eOH<1sOc?V1@j^@+%s?FPPiET^ka^gmo&m`Kuxl^
zGelo^{gvy{dXs1Ieva#lzoOq^*{m~JCDaa<guK?G`Lg1k^@drdwoN91)R<(_497@*
zg(ML(T4oWxL9P5MddpTAl~OfX1#EbLNt?S>`IILhT!>JJ8XV(EKn)B#Ck|2s(sF`W
zPX{ybC1UZd&|nyZ7DgopE@(j@E|$2uO;8alj6oni>*?ES-XUm=f*5J20cueC0nb|%
z({zw4$O^m>l4KR^jH3Zr7hPqY6B+XgW9sVG&`{qHFbr3DJ18yC`C#~>i>y<k23*Kb
zE|CQHA{?2ZRszWi{L!xod4;HDc~HLxj{w+sJMIwascAevH8?|bhYcC=dFxA<LN)ZZ
zJ7edi;>olXxyf3}8;Okbm#nxMav^p?%2|Xg=W+#$*m)y>#;q@Ndfq@?*<OSPM^CHo
zx5P`**8oBJWT8bM2%l_sAT(GAmOG<XvZ2c&Z_PvW&^9Blq}hB}-1ma}8X-5lBjJmi
zLu8Zwrvb@Wfp^L{+uE=%+Ep)H*?uiln3G#9>^Nu2zBO2wWPJD~HhQjjqBYzASyJ}A
z#$K`&^_g#<vGvmFUdQdK--*QPsWD650E4>??{T}k0VF?Sf8AP}-=pYnOQRjHoHaVh
zFfYls(rRAG?<Rb7nz2aoJdLVYphTwXrQB9jSd|7<ISQV#iGzcQ8Wota0fJ@HAd36&
z14a<AQ4AFFB(B@J6Q<IF&7e^S(S0I!0^C`q;D1m*kuy<vk;O5pnb;e6SQN8ylWWi3
zmHf>w;avm%2`L6@b;g}<Ne<hlNb}Cvf=0YbyY@8`t{r}ZciAF|a!DuCRclVy`t!0y
zLbV@fqWTr>2r;uNzijtwImjHV2h3J+Dsd9x(uYQFr~ER*(aU;h8ZwvWTUC`)a&uSG
zzav9k94^x(|0MG`-RsPnc3Yrm@BUp{DpLCk;a-hcYrZ+y(Kp@fqdeCP?YLjsx<Iu-
zW>VIXsr~Q$D@HB8@!wB60=}Guqe#qcs+-3)tA_m?JZHvHOO6SFe0_OS_YN2q9g*MR
z#@e3=pQ{{^U?-l&nch2*tD@Y(zeb?+O3(O3sP_$h#>Bm5B~wQ-c?at4tIde|O#!Pm
z$=T9sPsd9a4vZ+Gf+BLZre+4e8NY|TCiiDoj-4L9$#o;D@bK@8%C+WE6)TS%TQ=$|
zj+nLCH*<3VJ@4*Y^*IVbWEuw69&7hSCf7Zn3ARJ5$KAh8^6Z&LysQa>M?i<`)n;aD
z*1M@I70b%ZzS;}EN9teLWXW04uKWy=FBA^2^~JvwjWqPCDr)xMxTogt5(q`UBkdYP
z%4%&WH+DXnfat9}&fC|wFQ*`DTbA;@35~3xIh)xTnocNJ)g*vZhhn>{Ik>T)s+BU=
zE$8Ip+dt7Ov`QO+hfe}r;=KMuMV{@hdF&4wJ^JhSHRS&Ns1&1xcUx6EqPyY#A1ti=
zN_@UQQTBeo8p09ZaqPby?5)?^v(xZxb|Gz=L&3yoM_euLN%9S|mTC0gObjgrBS%Ur
zi~QX8XqV}8z#{OCaZ&gD7nk_&yrqp!2<o*(*DF4e2%YutDq`~vMt@oCwuiHFww0By
zLe}A=wo}Htq5c!J5RJUTM*U86yHUA-UDes8{hw0WT<bQaH2IPD%CEir{co@q)$#)4
zw$W<d{<)z2)zutjdqV7Je9k+m4^;LuE3UPYe-uqRhAqr2FYizPx#IFBB{naZWFxzu
z&xP8)3&I}D^Qo1TzF|aj^7YTh10T5f#4^sxiKx!j!!P?v-CsJwte2_nD=ME8>(;E!
z8mn9k*HV)5^n`wjT$9c_x>3Ty0szcz*oiB4%X{xitoXRZ<mN3iRmq&3eAJm;n#!29
z5(-WZ!UQ_5?EFZo(AZtyE!L`J`AKUcutt8`*SULQ>ad?pn@AfcG8t-nNn@3yuxC9V
zk|OC+wu7bpn?0z}LD0x#&}HByJ|m3skx7IYO{gJPL(+6=-iJpij}|7%SzC7g^_Pck
zHp}BC=e(XNoL>0=Tb=rB`-*=jyY<8O%3^XZ*2q>Jmc+*c!(};+EH|eu-Kxnpf2f(6
zvHLxXs>y0yJ;rwT_^q&?{=^zZaTFhURHO)~E|1D<s!R5#&aHPcMG=O|)<nL|f4H64
znc_Fmt`M<Im%UXsXhaZgq;_#WB*ae>*bF>&cs$MDxj$oxz+HJ5%VIC|Smn>RRkyAe
z6X4?n&TOxI2Nn{;SU(Els1`m$+`f;iYCSXCeP<VLyCWduXVkLr`1!NZi8_o9`#nAv
z@~ZgU0mHHP{uLCof(J@9hGUzrZfP(IBM;Rv%<*#mxYkNb$prDg6UaRx_7S))ItlRf
zf-2v~5@ZruH#7zc#=2x(4A6F0r7YUZ+coko>0m>0&UW1<DXEJ+ag$iVE;$KuSs!%z
zZ8_m0PQC-CQw$S%n>bu+hcy(Yl8&q<4F!*>Aw_~s6=>pSh%juIfhBW^J&UY;P6#~a
zQ}jdBz&1Ohfu6iNsIb+*1>;{Ps2zktCqh!7Z5`hlH9e}!(sxN3Y>LK1<Ky{viP)4L
zbxaaOph8|fA{QS$&s}(hq>({xP6$D#DNxS-h=XcXe!a8LEP67uIVP84208_{_$f2*
zF@Viw1%a9rns!Rg#u7{urWCo{v;1CJXtFyby%h^nuO>GbF;<n)n|QQ$X(5t1!M^3y
zB(6X%il9C0*x^q3e({@hD)Ekd0t=+LUC92rhcUawxJ(*@w@DH91(P`-F56Ik&CR3z
zxP-=wMx#wW4bCeUi2e2x?S504FS8>-C9_T9`lTPZ&%Tgvj}Ec2jfaWjZii1Tmb|6L
zR0gP+gS2hVSmutVJ9{801O3lbsk%##d>-!HvJv;DW5+(0d)XrQvm@}j_Vo2A*PWc@
z{kTp>R>kMs_8>)dB4j{P^5U=nGbcqs8Gy|KJwl!`&8h&h)P)BD=?wfNQVU~c#2_He
zOan1-g)$fHWaKK0xflXzjOoIyTui>FnUEH&=O&k_+}$Qj<}q!O0w+CxXLA}_*Q*ET
zZBn2po$0<-q?PVS3j$mc@<Y^VTgi8bnPp9w1@mQl^HvP#x6qq6n1#zZ+op_UdGFLT
zEHgG-Vo{Ia$TmwgaeP#dk{Rlc7Z?2&g3kFMWUs7LV9qgD5-;+3G1r<bLDad7sF=WM
z%Wq8Q5ig<s_4tJ6SAd$7rKyCH>6|0|2kn(N(rC}`V#$}h8W&U)-_I&?nX3gjtd*w!
zu`+$MKYV#^Ju<6UbpG&;>+F&)KYQ#vYH(!xV}olhmU)22r2HHRyVE7NQXZlGHf;H=
zs?}KD#$~~L$=Y5&{SYT_m8m=vbirJYQUKbR@-Y+H8*Z4AaPL9(GvS5RVd>YS)YmQ6
zeCI@ygDvL1b%>Oy747<r)DKpfwS}5EcIm$!l8!3<lKs-yZH!IL#FgH6j5NSV%J0c~
zfZA1|=PEC09*g|49=}`p3p(*Tj7xvC_^y{pqwj~#(mc9=FviFB#0avt;<w7ba>#fi
z7p=6ECnSil9UD6qI*BQmsz&3mTUEY6wTE~3sHtT<l_wXi1nZQX2g~H>J?CIm#+cAk
z`}~d*QF)ug%f6cgTLZ7NV7G&Qk}EQeeaA1Q<SFt~2g?+^FTMYmIx$z%LA$8J<5A_|
zHg9&r^w>{N9Pbpb^knrN@Fgwxlu{vIjQV*`VCq$F|6v8JK-x^_&C=S<71zob8;C&t
zOnrOp_;m&tUzdV-huz7Kv6D`&jORB?h~=z!E{*U%y5_bbJKN7^8X85bD&I2tdhMmM
z|Dc~qhCDltk9)JOaPX}1>hCn0r6;#5+(|kc`Ua#R$v$_RL%xq$Mntb$VO~v)WskF#
zxJ@|_s6`orC(6&NUJgc0FGb)VQ`dMsWe`)TG)_~_E}F1pIWRApNqlgXQYAliWUFO~
z?<k^Fa|BBLoCUIp)R{LszPBpFpe;T9iv(^Gt0HIXqMm*d>HP?Ohl7?b4wb~geBA%S
z+%QzXLiiAcB_?+4xa%1)Cn9IAX}sPp83$Aj6#Q-Sl}dN&)@O}ZjkGuq4F5e)7EhVB
zwJ@FTdQ-x8RP<NMYVGs=$SW^m!lW}XL>J00H*fb(uQfPb;run}W8wa?t=5TIAf}PR
z@0xt7<HMDY?~F~dMxI;9xGbqeo9KTr2#wloUJqM+C-plNlWZq0uoo7w<iEw~R1}5g
z2*z@;y$=}i9r_@5yW?NQvlNvD=da{d-Cx!$qyymh4u0}y80yi6ZSJP@ijmaFsGI{<
zLvvy_LvCxz>R^96ZN#Je5vS>tW1Ei3ru_Hfc@~!YDsl;@%Fn<3txI^7S%;k)n4u*n
zr|H*5UUTR|s+aEIpJui-IXjzA=u?m$gT}-PeFHQjcSFFH2~&BnRk?x+v??<NsGW2e
zN|=4hVrh9op$+V@F+~#HHWH}(GkC~KN(pPZ^_v9&O5oEir6f=B2OndLpl=22xxtkO
zD*qZ}h+6-LA~bg^5z4?gw2eTnf*b<c8AiL<c%>|AH8QyC4iP)yk5(t=kBN^{Zt8$a
z4Ff!5>ev}luu%`WWe+~ta^YGy9wnKkEAcb&H)km;Z02G7W8+7}1HnWJqJ$?U1sx3K
zpglfz6kY{WSjRCZbLxZdIco22B*+^{ki>;HliG)vqv!R2S6*@QniTfs9MD`AA#mj&
z`o*e&_M#XfO`6o+r*WS|7}wVzNpxN2qV;70A0MH74Mca1mW9hjwk`_P6+eq>VI(M&
z{EW~J<`Uo9X|IzUW>XvDPS@d8h@1bkWE{z7OXI}c_Hl*TFzcq0QhY^jE`dfBG_VbA
znwkm&hTZ+Ru)I(IkPmA+v8^|w#AleSd@?DkMg=^tue{K`8c65;+AEpZhCyjDwfN9g
z)Di9ckJ;_er`ZP98f?-*n-Y@`uvLD~&Vkn(UxGd^e3emfc|^I9T=aSR<L~b+J}-6s
zhZX`ofFMJ6Kq6<ND>NV$B3V!Xk*oj~a%X7%7gc$vljGmx0WWw8*?(q7HU_jd0O)9F
z3jVV_V0bl=HxYf|Xe0|j$8%wL$U%?uAB(U@Jz8MMRT8824l5v+a0$925h0)rnAk6q
zRy44z*9<U+_Ad4{u?TaC+`XQ-q$!&5H@o6Y-<rL&Vm4>LYM@4^@y-USKD|a_)zYy;
zj5;{1zzAt`R{71ps(*&*{maH+?Ifd+z=_?xDw#72l2>J#jqFT6f=1B(S5$=|OHnhI
z1pJQ8-pm5Qw{^cC{k!Q{efY@Ikd4OC;M=2@K6gDmAzz;T9QI!}xYOnqv3&Ev7pmfl
zlJxr68Ip$IRZQ6}OfqKHQzP4((Vw*y%1Py!7hB>`a<!cKTF-0ETK{M`CTj%6J?**+
zY5MW@95}G(a=tkcD6gk#Nvkr`mL96hooZj&c5Fp`iE~J5!ywIx_OwJIw!TEQJg^Iu
z6}y4t?bqAO8RSf?mtPb~30ABW6io68+qRhdxoqw+jpepzq`CBzXRjlOf}?mcDc>Q$
zA#+vYVcihvFScX5{O1Q9k1L4F&!(1ToUaBvv-~N-9l+;nGI=}EYV4|dUe%ZIyp2rX
zfk~p8M(Ma^tRRIn?PJlpI}0qQ%B7EKoyEIHV*dWr8*(ExaiYjQy76F#e@dC$jGWhX
zFL%JZ#3r34&2v?<!Nr#m^UlV^$!0xQGvj9cTG4US2P)_3aM|N3r;Ha>!GHYh^~6(G
z9rf0wX8vaE&|Hd`HXme;Qo1#tM(u<D(em!>yZF|Zj+y4Lk5@0N9i09<2ei7_Ps6Gm
ztpXu8GU=#_xb#~53jchG$&Zgunh)%Lb?QHGui89u^0tMI*AMd{ch)`VJC0ro3gNNh
z@n|6e&22P6q5r3-#MS6`$|yJfZ#adTU$i-eE#^rdE3?#qkMi)75*1n7;nhahP|exi
z?8hN=G4wATuUn@D*R-uvjYTco`T3}y^Byt{az)qen0Rn-aB>c)mvWZ4)0o|^&@C-<
zD0(s2>|4LaH}Xc}1#-XHp7hkVzn)9L_N(~8i2vr(C8LkK4$nBupP3O~W%7sDox)Z`
zuXERU&ayd*;-|L6riP5Qtz6n~h|E!Dzs`z>=6%u|cWPY9BQpqw8blNZSR|-pQ{BKO
z2!>HLkv$l@B9IP8jZi@F#{dGE>PD^R3Zn`yr_YS;<#`xjD(`5Y2j=yirq|ltHlxRc
z<V{c`m*ficqV2#8Nq4E7uofuLsh_|+svomd4z7N0u98+5;PidLHVk2^2<|&}l38Rg
z%L%EAg(w(=tUQ-t$=^7@_*7k8O&zv=(KZ5u31w>H<!RE158t%074UhbLqh|`=wQZt
zf$Z{|>2QCB>3R9+dAJ++aA1Xjc8D>GWf|fvr<JS+aO%_Xe+bY3`!t|=({XzYXv0;r
z)Ztk5o<5$T%2ji=Nj)-1@>Rz=`cH8xOcT8%9s4Z8F-PQ<)08SPY2fn~+_cOOqq&_~
z*m&48qBpQeCbZj5&g3es0ywmB6Dg5PZY^~q?KfY9it62&bD+<EB)Vh3gYGQhHpQ7&
z<vD=g@VP5AF?;dg291%=p$#=eMy5EE{33J*@e0N^Dbqa*uw5uw*4!Dui%h1F<bIK(
zA~!jxX$4w~Ji`7{zGPs4f6bJH^;+)#4`ZPIMMWzVfZ>g?z52jbZh$&@x)<P}kdKh8
z-1V`~CI}}xMpRQ@R%4^Ea;Sxf2^O(?ZPyHpi+En{vF2mXaGD_>m~}{5&+P3MaENuX
zIi-*+;dI-b7b)hFJ|f*s!o6o4Dwp0`&s-6yB`M0z@Z+4a!0hf;x4e-o=X2VveO=Fy
zGD-1EgeFAO{?~}J7aiR}g8Wb2&*tpv!J79kW$*D51@`!H4k1Au;YK^mI^_#htj9#9
zAl)Oeg5YnNLZ1G}v^Q~N^Xh@SwE17t%G2GHmN4-qXU8VDpB`6<U|-tikHR?uvfsk@
zUbYs8Ec#R|Shr4k*(!x@l6$Ba;_oU93dW98_)Pkx=-9Wrc`Q4}e1|92C0a1yVibZn
zDgA$<UnRQ<Ks5dF-#TjSGs7x>W|RIhYga&%Pp6DX{KzUr$(uJIG5a|m;%rn{!rc;v
zuyYHEJMJNJ33_5I*d+$?OM1T!3TKWzIASE;H$I4tUheNX2cRu<hF%9ZgJz2|B?-9?
zo+!&@s8+Rq)f!Mrt2_>QaZB~3?=(j@{O;U2pfWod1U}m?6QEr=aQ_u<NZ%|xmbYqD
z*gnKr8S9<Nk+)YOU+P#`a3qqVw3q(z%i9&FN$L1{PW{(jyN@`n+Md?;<qBd8UwpVh
zkt-^)bu`HMuVU$perYX}pwsbt&;VQWf{hGCR+u46{(AcL(%l>MFNfKO_Z}5V2d6!q
z`SN|L-_YYuF*CgdLPFqJ!kr`{)pjpnJm|Azgior)=vdsr8##{Spsg1leupUiK7*sk
zvv=5QtGZFko@amG`F*K1Bw)E;EO|9ezWc%<ra7r7C1reFcAb`I$ZJ*ZhC8LaOVKrp
z>!rI@iMPFFFSVz5L|;QdxXBK$Rv-<olurG6|FWND+wf{=)~-XS8?QDo?$ytKm)Ir`
zgP$7bl_bWE`DP*w#Gj0og}IIne|@$QcX$psbk^LP+TKd)TPKPdEtfs}|42HksJ7Z}
z3x`tNDee>~#l5%{cXw@Zm*8HsSSa46xVuAeCs=WJf_rg?o_zng${r(oXXI+__0ILo
zxfE5{Zi{a?Z5wg4v&fawAjl3c^w&Ypnp{&Y?Z)QM0)JDXe8?r`5L0LNdJWOM_Rx{y
zekpgr+nU7A0QS6NlcZt;DN!kl?r&F56yOI$Fyhd0Ty~W(Yf(k$3b08@Mi(kS*l<N1
zRZIE(tRt&UDcK~UJF0c2;qmrG=vl?!3+shbXVjQuZh1xK^tp<T`rqh&-sabsjH$Gw
zg*T{+VN>2Oj0$#5i%b!CaZj~P3iKp@Ky-p5`&8w9&P7=m8Oja}CF#q_QO>k+7u0Ee
zN9}v{OD%`jYTEnGOrP3ZOsKuPCTe>Pd<*3Seq|Cefh7!>z}x}MT38DyiFWZR9y;_B
z64ieQ1<A_3GK&i;0(H_G=^^epP=+1^XSihEf=Yo8hhp4;k+?+n@^2I2>Nwm(nd5q%
zAQ|mCEFmX-2N0rRqnL)XF7PoaV_N+5>e@71y~qLjGq!ZRd9xa*iGWS{!!_lO9~D&t
zf!!Gymnds^=L_2qJwp#G9Bbow$fbqPiq+4H6EkvLPnY2KJh(pc?mHA0?^~;syaK8*
zPmL-Y1A?=d9i{?&REv<oC>)T(Mk@dIhvJ*bcdP5RsHnBkY!lK9ZAEQmZ`KQGa-Atd
z-{4qI3+1{?<;t`HC5%FT_i7XUZ3QSGQv87NjZysAd;>-&kepxu_$brt%5qI{ed`tG
zFn=4Um-6GA$gD*#H+MTpL6ig&oiL0T+n2-j2f++t_ZRuSTr#k^&s%eMb>V!(ye3x5
zZ2*CUmHci58~LrC%=Zs(kdH~r2VZbHsh?N0{sGWNnUSB<IP?=9sRQ8NlK(H=Eu!D9
ztqZ1xx$?`9ua#Y7zVAnlM^_%e8^@d+WInE3w)SMh5E8glp0;jRdGP;N<I!;vn6|36
zO8@B-2=OZL3ze?`3rQ7oiFJia_*W_xz!nK;lGZXVZzLxpSH~n*^O}DAw-2LV!{S>G
zD!7^@pxZxm>0B-~>JEB`E!1?ZxnP)1JK5yo;P~`G5@i>*)JU8$OvkedZmuO3HvM4>
zw<fK{Rj1TF{$^DNVQkwvQ&LtWzMPK^a+XjCQ<2OzR>wmTAL|=_Wl99ix>5@g;k>u;
zbs_Jmw3B&82uQ><5aXv`+n7*Fb_%VyzfbOp=qqAxFiRy`Ibm*{6~~gN)SP&lqLiu*
z#cdsRWaNx{vn)+;r+%|vb1QFH=y8Mm`C3x+LxFtoyqW#wh_5MOenaK3L#O65*6RdG
zafepDjr<g(E#d01I`guXI8Ur-_^`7I<X3yPbcT2a`A88&+<zK97*|ZZ6eb80*VzV@
zm-;;%hWp`Y)}4NRdClsC{PlWR<c2n`oZ}0{RT+Jo`%r?gQFoc7u*iXYCvUzTkcWL%
z9L^*`_4ZDhBEp~HO@4V`=101+1#1{jm$yq{k{+f9&EM<6qn7pDX7Z|nHse?f6&d63
zoqYj;iNn-|K$PN7Yvh%DlHrYi@_47(_p!G~NFIb)qGafH?Z7ta3M{efZgENOzATnU
zXoQ9Cj&|Ob4E<L~KKINB8=fX<>gI8d?F+OhHJUT6@+b|U=!(l9W66u|MZf5cB8=j-
z6Rhlc9+>iEckOP(4Gh?(Rt^{nOJeZ)NJ`^c{<uh>(xqpVd6`&MF*SzqdGIrlyAL)A
zNC1udAdsHXsKLO8vs$lmPpA1ZA(lYleXu5?;Z*8WoRI(Yi0p*>?HO5&?(12G^P)&L
zbA||u+?Zg6hVjCm<I0=I-`qzxWEo1>b`Yecj?UL&pX>GEia@oQMy<zG9YVIZ<F^J<
z&R-(t@HX+SeA!*?#s!S}GANR;vFnc}iunxRGc)lb85t=tNPEm^>RQY8E@Yt8c1M}N
zYZlyZ;%vxP4w_77<DxYARLV1kqzv`hiO7Xggkbo%bFbAmJ*7&`Q8$pxZg}TTUuYB6
z<q7U)d7WRJ3xDUT9Cwu`Wvtui&5a6IZE)y|^}jrI=*m3(2SDM+v<l;IX>frg)=lKF
znO-?x>CJcUlM5JWGr(ZyBw|$5Z>a@^tE4I#b*r76f_{6-2w1A#uF<n@`Y+1Lx~p=d
zjuUNY9TQfjNc~lxYjUQ(Q8A~<>REz{j}x<&w`!Ylc&10^V?Omf)BQjM;N)P;xjECu
zka;w;1Rjb$nAxwt`1xhVs~S6Tpf)<pf+PE!2(*DRAMNPnc$C6`lenL|O_^PYk6;Gg
z=_0~>`4nuFArxt{a-Q0Sq6@!<tLLnG8?J^{iDmpL&a^Y9RGo7*e%g3?eN`;v9A7kk
zz|7}=Pbimweo`rtYCsmur-i3;y2dbeQqhdis^AiV%q9H=S*VyOhXz|7fgPpp&8p+O
z+Bq~zO$2sS&J0=iZ+#w-jO4qBky;r538Omc@Mbu>=w`PU0ue5FqvRSAzQrB%U49r|
z_h)ly-cGMxNo?ZNGxULte!+7xrupH%9k`wiSIL?BX`#b_q<%OJlOdSn3e{xzY`jVX
zCnUFo3){c|tyYF+c)$EnNmBkToQTF>gQ(CUAdrr0lB8qqqbhl=354JZ*f3!#pi)d{
z$-XiACMYrR10VsL<E^<I!3R+Mcq1<ehnx=!JU?&x(;yMW<#Zznjvc2UWvRbeo5J|E
z#2LqgxrG*wfi?8--a+{7-e8@F>wW-}jJ}4^is)xroCwc`{%aM26?eUl*l}i!FpPW}
zcLRPc^Gn4*K}v#_&vCxa#F0-d*l`Vs;l(^C9}k#mu%78CCgGj}H5p5NFHCpMZtNq@
zI802IJm@>$zr$Z|zC#l_;gLo4_FXVRD=-47ex*fILgzog(Q@^@svcu4@f0}O_XF=2
zM86MwmVz+IV-Y0D2wpueC9vSqfTF!aa2~)xjviVF@4x;2>%<$`zVX3d0sLSG&E<DL
zaS>`5c^TkOH3GQ8&??ZJkl=mMSqM2vH$0r8*XT`6PZK_C3^}=b1y=|DB4>r{blw<l
ze0+RaANi<d^UAPMd>E;Q;~Xl=f4zD9XDAD%xw_*Vre$pw;rEqcX}A5nnxRl#(^_1p
zm0$(40hQp}y&9(<v5c?~@+q#$^Eg?~@0_6Tb@)&z!&o@pltm!HWFUPJf^rbc?Bfqq
zFZz|{%2-4|2?Cg!?hzz&kMQ~nmyY}8UPK5U5X4=|HA7^v)m<i;&O>XivaI|?e}KB_
zHoXLCaNPID{DGGmy>fhl6Z8nzW_b&vF6Cgd`pGd9;h=|iCR$%gQ{tK=UnfK^AeY9(
z>Wl1#U+)ae+a<o1=cNp=pwhW5cn~QK1ZB5QuREpUL>49Kjttf=3Zk$anCYIRP&GZe
zDI8m;7n`@Q<U5Jw6vbH$BEDFoJnUs_P=B&O*A6L0tdl}Pl6UdYXYfY?;GmkqP;2yR
z)KT1uzS~XI-9Y`K!>IksarsHt3fy>u{0V!1t`h-JXxjEGD-u-wSaLloxCFpC_7uk6
zh!=c=Ep&8woA<pLPw#Qhx-|i`swh?>qN$EQ1vV_DNYx84a{-P5x};qUCT$;THcN|m
zjV;m!3p_Hn^;XFx?Tgu|PZ{Vo<GdM6ub*awi|T+?eE8_(eEfr22JB;4l*qoRzvjh?
zSDYHyCtrUK+}RUhqyG+BR+yj*TQWf{+spoJ=WVU|w-nyh7S2}Bv~pdna#T|g@;&#<
zmDuki+sA-QS<3f4Zn(1;I|dn9s8#2oX!I>-f<Vwt*3nR~43nk%O3m5mH<)j3NIEh^
z^t>ER$V#oHP8TuDa8nA56N*o<iA)9<l!%z7I#lyh`G(&G(b4?ujl}hLxL4~NGrsv6
zVHO&5d!m))Tl#%x+W~6g^D?XVr7Coo_dL%cbKWyl(uB1_A&K{zW-fI1!7^HjW-;;B
zhQK&)ooqY|3vfvMy)SFP_0NNJE`gnT>^&H3{CU+Fwh;5UHNSGBFz%)xtt(n#^BRKf
zh;#&A-J97h1OX*i2HF@l30UX53>^Bm79UBH&{1&qGQ%n8z_AFbh)Kl!b#~4hyhsIB
zv@t-}G&${Qo(EdGBxL$9xJH_?wVDeA4kP~e%XE1Tzr*RjeBh;zqhUJ&%f0`$@@j{v
z6=jK(U*{0X9TI0nLtxZ-fFljBb4KC+QGBGTw5$bO>;PJt{UkeQ-&~O&Tnz1#xEV$%
z*Z>+NT=#HDwszkb4)y_pToU3iUw2T6D_1xm51p77#@D@_^adOE&Aoyw6rZzz_bihf
z-PZPF9=(-OWJXr(?1g1SVkFiB8)r0c#2_51shf|d3+j}kPy4NX!y0?h5`Qmwnq_bv
zN(PL$!TymnELC`VZlpwx$h2sbutjf~ypxgCmcbGwWx`K7l4Qm+?JwNJb&)XxGPr~?
z-<Eqrf@dGZibC}nJa|4Iz?*NNF{k9o=TcS@Dm|^6(pm9kA=1Oe9yV>~cNV_@A-%yb
zQim|$QZD%pYikET>~fTFjiQPn?-{ww&x+kyZ?;<n8*NEDz=1~#_3b9B$Df{^nqiG^
zd5I(kaUPnRIgZ*|tFbt!Q6dC%Kc(dvOo$KxgAB3r;xE{p7VwJ6{9naH=!N*!aGR-m
znq0O&xk_1AItsoDD&t@c&e;tTi~e{pPR{?;;I86wBQfhlVt{Q9ErNixw2a08d~k7<
zf&cMCeICH#v%_bj;4-*;f!xT|HN{q1A%W>4J@27ps|trupl|oWi;5a7H))U|kBl|u
zNC!--CyrHv(kJeU!%(*Gah|$)F2UftwT#u1pY!LL(~d2&QL_BH?<tZjC{jy)XMC*J
z6-bC~k7*=V)OJEVsFa;E`m`M~v|K4i<;~>AUqx6l$Urpq<6Emy!wVKY90DJ<qT2=z
z;!c1@(fo5FSM=V|3V>X<pvf6{e}ZyNAxBJELx<UtS{m$JKP9{Z+UVg-EkDG>!FjT^
zDdKuc=C!im0@Eouv6j)<l$Zx6u3mfN_=(!|HqsbH>*U#{uhzLm(;iEpqa|f`BpvL{
z=nT#wo1KS@EMA{>63xUMk}Swy`k-xuBR*f^9PUyT7JX|-XclY^kZG63=|@8h9y7gR
zvfQbbnvh$})NYo0EEalhU+sGFTf1&uZ*N-y)vg$ssc(M@ED2#pypP@y|J;Ng%h%~6
zn$|s(flPMG|2E+1MHhLD!PpaFRzt{?>w;h4t;g`;mG0SNo>DNOu+z+-MjY=53d$c`
zHT-h%m`iQ!zxCXkenA+57nq7G_NwYGzlUXwtD9ys4E>j)0s^=ds3bjHJe&tVW21uz
zVgrCb9`@-w_1q|~7+af+5~4lcuQ><gi+tUCAeujVu3R|$eEvD~(@L3*2oik4@Q0L!
zrHU9ro=-!27{U9;;61|7n!j781_kZ-CKA16l4w}`)F7$1G@W}L0p~?CCR3pm8)i`s
zM-NOd*h-ibX3(ZmJJXUVN1k=}W4-}1NsZ>s!Qj-G`Z9G#E1CHj6^G5*{i|^^@W!ad
z_HtikJ3jmi)2p_d!s(f_svt8?T+KFyZ|m|JVm3iyT1R-}7~NaEKZIoqlD*q?qe<B8
zzur+G>uEiSKNkK2Fp@QBt)X;$X~$_bHg_FWGJz0Jxt~~A(Rk}1%yv#vrBbW%xvW=;
zch219-nDs32)bZEHYXBxT3j&>v*oIFH;g(yRb0#IXhT;zIvKU~?JWhpd&RNUTy{FW
zI~S`AoiFshw#_K0>B+F<rY1OJOG1MbYPgPvLV9meEJNZ5{rcn>JkLVofA~Y~f3EcO
z4fG2{x(izfo|jhs157%Q|9ve#JmQo?Wd6;Xb7Q`rF!4|X`5K7TcIu>Y;y{l4({ej>
z!VbhJz2NSJOd&V)182<jX6ki{-={jL!JcW0-L)`9<AO>q%&Faix@=#Xk<tBYOaZF1
z;w24wsu4YFh_?I3p<W?-!<eP*!oqJ?DlB38P|TLW8gzMpEjw)vzQQ8*am4|(f*rZN
z(Dp1iVaW?sj+~USk3m(4*VkZ8^l&`wI&zq({l;Ea$@KOq?dhYSKj;$&HQ(rq<PDvs
zUncNrcS}-D5^aD1(@5?e3N1*nKZQSiGF`REVOCt1`6kSuxMB9gR8eUVN$J+T$wx}#
zhLW)NwhqW|q)=_U(Y~$WySsb!o-_>$6`=|3YFpgOQn|-cruApK7mSoe?K{Uv)ejY0
z)b6RaDEeQ9#Up0m?-6qb7_3parBfMCa@rhKPY(>lr@AL<?@LN4tH}hBz4;5<tI(LX
z46XNQphL7u0}4I>H6n;+US_#hWKm&8FU7JZ&XeF6!!M_ZA$QHZ@3vd>O}>`o{hGZ|
zC)u&#lsl^Txk$;-TBEqB8We1nRcKru57u%91QAA5z%5G$I%&^u1av!G^Ppb3Q0rBL
zlgXpf8hI!Yw{4AUQ|qHM#YyAi&kzRVUo(TkTrNlm<cveB)MZ+c?gh4=Yr{!Yy|uB?
z@CoFuBqSL4#+DFB&^QT<l0xEV<oCisSp>2ysFZVp-3)kRh(vJT;_8RQKP7Z!$n<fT
z@YkjrIYZiMN`)P|D^wjXW$-QgYc!@($Y%*<y1>cpMES39Qr;+K!8xdea*l>zlON5}
zQ<au&<y8UGU<1vnwBJiYRuP$L4VUNyEU|=wt^Vfw(YLX)3<(5eGzP%OOZb_hs2LE^
z4P!wN5zff%M&fO_kqY@11BJ&qWqe}+=)+x!M$L-mx^(+Z1Y6M9l#>nDx|CCtgW87Y
z`L)~%jU!P>6~`<s0`~h|*JoqIpHylLGgIbS)x4Zv^_Y0m2hs*i2junJtRp5NhW?mZ
zIvZuBua^^^DO0uK(v;0>n}27&fdX|+t3My~IC`=;HcW-Aev-wM7r6jVjD6j_L5`eK
zU_%<Ot?3N;PIbo%>*ghD`!Z|c{9vXI3mW^fxzw)8AkeVT)~5Khw&0xEddF|KFG~La
z`;eWVpXvao&#Y%B0>=-IV4QcfzqYYmse9#U<6E3Y(-|r!NKV>{z(q4b1-fG;Eap$E
zM2D1W%EOXa!0!$jm+ScyG>H3jX<VJf2jxhjaN|T3h*_aj-xBzRg3TX=Q;u~z(YTZ0
zq@iAly-SMz!sTPRQ{#HJYU$jKQmL-IqSKD^35-tzFF7JMGu+A%*iB6W^hR;5)#2R_
zOb-Eb50l7!OF^GK$Mt1iX*er6lg#=3=RI9O1Qw|<i#7otKUwoZsRc)x9&!VV#Q~a`
z6hq+&_r`I*;AW^e$R<k#?#y1VIU+f0wZF1%2p}54a8i;LUlx#tpTTA7k7DD5Oc%#!
zt$&aWhw#<&|AZUzftC8uzI>O&ZzD@O|7m3w=}}bjH-BG<EbnMGTkl@uzqBWlrNQ+r
z18fQS6l3pOX(h!E1jv7HexuJ0ZvYnW4AGJQJ05-Gi*|aAjynh;TaT{XNm-Bn1J}q%
z^$uyaU01+`)SUI7pl@z>KPaNFk@^R=#qq-oex6d}!1O!@I#TC6uHoae#0|V-kj-(#
z+*Z@%pwgZ0j4Ul3Qid>fHgF%@m#tmXS}vAwQd}$8QP7tx;{H)q*!g#h&K!GeVV6m=
zK&DE4lsGz6MXmb;w>8x|uDYtSw79W<u!&WGZ=we#@G1>+AU44&Wf~8*mVbqXF&|jR
zrEX}AJNSr|D}a4$P~4n^bSs5C>=PrL@#e&z#Qna%Uas-Dz3jpKgoK(-j_f2adkdDi
z<&forY#T3wC*2~PKO{pu65nlm(OZChH{)2;6L#{(er}s6;Wg^V7cz4Vu@=@X=(ufh
zA~#kFaQJplSQ+o+Rc4xCCy2pa(M4e?8`2Q#z9J*lWyI6OGh%A*PQO5|7oE`|i^_Tw
z{^(V~ID{n2S6q>Om$HSuoaUukmJhJ46%bEiRzKczZ&xuxd1-l?L#9m^9hqoi2%_w>
z9Kb>(G9dNOX#C13u|w%CI}ViY-Z5zG=v>6t*qC1_4IFf5vSKuU$Np-X2i~_W!YRr1
zhA<BF^>fc$QFO{Z>-as6j_1eErad{vh2TMrCAR2_R8cG<>c>un7@HjZ0~ljPYUc<M
zOULLx{0zf0XA^}AKF<c|Lne$~v+sm3meyq9Fh`M`9!H=1tC@FprKaZt|K&fx@nrRv
zh=%#aO;%XqFZ?&yK2gC%_<Yi}G7cUSgXE@DRDKy};;gTVoq1Iy`K1K}z$cfVf>kt#
zO|sb7YidWemG$e@)6vXj%lF$W(JQ<@0PNs9rtPp~1EWGO_vUPZ!J-+pr4BJt%aQz{
zQfB+)z2iAXmw$k!TefC@!;7J~aQ#J=RIk=pe}gmRmMHVRjBneXMp58{UPZ;JOHr=`
zu~?SAlCZdRn^_HK+_a*^VFdDWjp31qW@lWyIo^Z_#7OR<I8t1a#au*>US##e3#NR6
zDXhhc#+nerTE+{O2B50|%lpG$OEcGe(6j}=oa!=j5A_j>6Od_8#%t_>ohK#Sy6vSz
z-L&WCc7aXdJ;BP6>~u#(@n-i&N!7c7)0aKjhAUe)n7GUaY*m#^UO-i3v}`?=%f=^J
zsio=YSf%&Wvw7V~ove)b8wUYhY!rYuvn?a_54#!0>P#()D+G(Jy6TavaAuhqaXTFg
z%p~`Y-o=rv$S_#t#cX2LCPCGn7z^gx|Bf0ZuctJ{Q!7orHQ8xlaH#a`WJ_RpB(>K5
z1+ny6#i+EpX}^E<`5nK{x)82zJBsIo-N4Ly%Z9br!$Ox7!^jEEdzO#Zj#Hw=<Y5`q
zC`pgh^BtlNH_0>0)Fus{Jmh9-xRFoFJ?Xp+&RZzz!JkE{!Nev{0*{r%#mj}aMu+%z
zEB8;80czri+^F~#$6+uULHx@jYFlbWhU-2<`H%H%pugZY$IT1=kTZRgp~UPG<1QqC
zuXjT2T2)rC#xchnmYY@D8k<yCE1BfmY?0a<V``*8wp-`o*YQV%BdUfHM|C$1uzs-{
zBAY84eO8EY*BIZdTJF_)X^WcAoZjz3B}4j>s+0^LH^k!*v2wCdI=ZDZ<vY>83==?*
zQuLmJ?2leVbW}}<xbh40oN39rkz=h!vsOKJX}M3odVMMTZZ<lL7jj2YL&ufA39R<;
z5smq1U%-I`Z7_L}{gjss=cLck5kfR`gcYnlvDUpRCWP;oO-odDLnrNrWS1@JCwa2!
z$y<4Q#$P88t}3$J2MajV5Vh*9GD@AUGHh*GHDjG_ZW*WF)z9YW55xff*4VfiICGLI
zW7#P$|CxlC&_{AIHOUOvw%SC$iqb(o{hk3M#z*KJ0>|dYVRuVYX32bX86(H`%j<R_
z5`4dPnf8ey5h3efk1$+beI_|VU`TU5i?yT$&z%y({qr9UX>KC+%(jX(3}9bfnLGDx
z7Sw(NAj0xBzmVi@L^OmG)7*x|wn2uX5szC1Y|PU-nB-BhZO`pqG+te3C$k)x243za
zTMVH;A^jGXEvVypR|Ek{a}eNwN*iG7*G_gguobU6co5=U#YQn9-n3YW7%mN~3p5x*
zete_)079NtRIfEiz+-Ip^C5$jB52$FY7&s&*WjlBOY<FF-{?|1Ilte(54aq~F1vl5
z_|3jdr!hSx)R{LXOoRBn4Uvs<h&-XhkZ}BW*61-tst0SK4+q8fy-w54VN3}6-?sB7
zw#?Thie>?jxQs4E`)U4^t0`l$@lG*WHJx;;WZX$(%wmmv@2a!8<#Sr4@oIDBq)l!2
zAIv{%G>~6<jJD`4B<M2%2F4&OWNxkXb-1Yo;q3rk3cVF6iBx=wJ_cRc8=<1anGs@o
zF2(>FI>!%*;Up^`=~)}xQBgON>`;w`-u|T3myp#m=BhIwLBl87Oq10zc~Qsv^EO1o
zMKf(P3pR#;hA9;(&ifWP;^wR_*s_yI%T6(w7{0}ci#G=N*od$P-l>CITVj1_X*olE
zKhj{r13XV#@r6I&H65XU?{CS!`Fy4TdV7MKwhLelt9vt(>Mmp>PR`i0zCA^tKu6dI
z`hrRsIy@$^_qVs4J9X8k_s!4mxxiMI#A)HWA$6nsp?h6>7Fmft?X6e>a=yLKdzrn%
z%g#Ew;DhpmolP(?3h%WTPK0&QszGvZZ9Okkw?fb=Qqk38{_qi$p&F)l%+Rgz^m%$)
zkOYT&Pvj2DbN!-=y?+O{Tq&2dwCp)#WY~N+ZwuG~h2`igaeA7JfKv;?=tD4BUm?v+
zfuBb{uKsn7q3IS1&T^Qv_ZhGMzO^^EvsalevrxX$LCnNY{K3*AsH}YYv;M&*{>&e#
zY+_=xEySOq7tf)YMn^~!T3SL2N>U8GnwyHoXN>J$yCFpAzhFI<Uu~JTw*40Ef{`c^
z`Yx|8I~zU@&r#CJ`tjL#MrM_3d{Q{Fv7v5Q!XU>LiCjs34Cb2%RGDmO)on~tSKQas
z7O1WC9k!^=qPSTRcwjHi^W=MlIS{xlm6yGq2#DV6W2l)c&}~79*>65S0Xx@>Y{6?9
z(#wJvv5YR55gY4tIq>Mj>s1|BwQJiB5k28DkB4dph|yi=x@<<PuN?aD$gG*1YW8@^
zJ|XYw?V5#EabF8tUR64<ZeUC$Y&hUZV|9Pz!v}#(C>faoBLKVHKazwODP*n8aKYsG
zcZ}_Xz_MS_A(o(mjLL_~F5XWuDb^pdZ>tX)k2{=93tJU@Dt8oc>+{K{%s^sfduK)@
z_YS{q0>$g!E*2#jFdt=^i3~=ci7G-JWG&=2f^VGko*CH+W;}Yk9e!f)I^Dx{bt0YM
zUUv_hq$RMh?}x^Zm>(Lofyi*#2a=~1{6E3GKF=YzOiSnk<S_@ik*`!m#U22c)GdVI
zn)!cZb`2vR(|?mxvT+AC=k$ovwXa4mgk|1o&CbaT#HwSDW2WXndW(DGUW#cUT!^oz
zWS}TJ7D@~IC!oo>O$$ZuPKxJlNPyDE(Nfs6(kBxUo*)muakNu$+)X#|l;y7GQ7PX=
z@l>_=>Uiua>;||R^bf$xk%FtFDij|TpK9RgTo^qV`k)C*=)JRKRffEIJ}V~`7y%Cw
zl!4$@_mW}$#IY5xwT_jeu}CanxxQC36t;8`TIYE4<~ev?OA{X3YErHdn+G9gApIJ4
z;?Ot1_v0|}#pUkPL1SM5^`T!-{GfRETvFo(8-GmX<Z$utcLgZeTlZe1J7P+T3E&}h
z?NJ3`<}U&PHgppavdS!}mp8)C{P8=H`Q&r6wWaJ<qeQDtW>$+EaL>d_V71E`Cqlv*
z=4-%0<&_~UP056~hd~foe)Xhz$0l~D2g5Ymu#@DRErEO6V({FiD>$!jC9k4cS4oG*
z_^^z!=@b3^Nz3`nZst8G@y40<)Ejxqx-UKaD@dUuo7LBh#e^f(e?hzSy6BF7G$*v~
zlM%JX>9G3kc}Nf|Zxlr!g5KA>{D>SGW$5_{1<Jrbz}Eg_r6wDbYr(Jd4<nXo{3wwq
zR-2%gSBZ+<&MUrvtzRk5*sv{+hz$Vc)BfP`oF1z)*BxcmzMj;;xqV~8i<<I<b?Qf;
z>}nolX{PA6)123uhBG+Q#=jS)byu?b53pAI#}=XEJHYb!cJYI@`p9B_%z{9EU!)Yt
z^g6}g5LtxdI^>x#iQ#>ag1vJ1(4IitKH~X(_agNef!hSID8@$2P_{XmjKt7XqK9;d
zCZN;k3Y{Dd^~srR_ivsHDD@XTcG|<U;~s-4Ry>Ml>yDi;3xxb^cZ2WNCruu%sHHz0
zGUWx#-!}ycLnio90FqY|)G~^Pen~UE!yng}fbI*Nuwsg<*`W4G1L~kOh4P~kJ4_u+
z*zGPo{%R<EDTEYhZ>_8<{}e^08SeDff~=5;@k4&V4T?RRw+F--ysmeoKa1c0Xszzw
zD_B+t5_n9!h|BOYKy^yN>pKmc=f^Z}8ABQz*TrWpw_@v8aBI*OfS$|a10)ZCe-e`F
zb;{XlhNNA!)2IwwINp|1i6q8oG`XF-o#B<v?M?Li(y`^GBs(#9We%3Rj7|=$m2T%%
z^VTMZ_Rt{+iqLOAgqCKN3)>dY2!)<JmUo;?zZoaGK%Dr2MP0V|>u@f#MnK(xOithu
zznvdt2eLgpN>DueVDk<(s#7-lTOvJt=RuFVp_BO9By9~801MGvdm)xeo*I*+clJc`
zB-A+Up#i+;au-i$x~UF|-wGGf707+hKBxxCi|uDk^m+RH1AOAY?phubrqre?=g}$f
z<a<ZSpp#U^x$bNI50K6mpBCCgL~5O%8Aq{tFobwislw}axt&4X4t^l4?bP5+J0oB^
zD6&YjCoAR&D5q|qOz5v2+bIBQHc7OwX=Mo(H2!r6kMni-Hbk?TPzK<RW<e~q%{FE^
zO^KfYZ>^8XSa|my?DwR7xU=Y*m~%{bk@i^c$Vt|G<nja6AYUlirgp30olMQS)^OGl
z3BT;C7}K>bI`d5F$VxgU3Zpo`%ylx9W&Hy*53I2f3o{rUu+P5J)RuKU*!^OMq;2+j
zDbVuzZq84@W1;d^f3u244(T>YjJR?2n-8_he9IBXQlI9bA-}y7qXt#MOdXE9P#H)3
zAM1_ie8#e{1P{7AKRr*#OHK!K#dWZ@HqI#$m?LOH`y4T2em~r1kZyaY)3$x-OepAB
z&$3NRD61|;Pl{J{ZvoqWFM0MZ@LlQ0MusdsDI=Gk@{{g7ASdszp@?hZYOv<aQD<b%
z&6Sh{B~x^*X=$Fd@dD<X?FBYr>bHcrVwPq~qP2E7wHbSQ9cQzixgibaKVG__z9{^_
ze}LhD>CRtIiit&m@2;<8HK6k{ykG4|+?B`->7DuaGvcr2cs~S;OhtYJ#rU`vRsu7~
z=93h<0nUn#7}H%6PP)HYI@E4j3)3>il{dV|n7-rdcnzKSA+%gfVa^3oUgMu0(Rk%`
z&IUoJucJUkonLyXrvC7VygCRUWmoIAsg%B^`B5ser3txyEpOqsvmb(+_Xks}AE%CQ
z7G|ORN{8R6EvK%7+ahCVyKQV2iMNY{e2sJC9Gzh1-KeTf5}0nNJ%SA5|BcpC>A&EI
z3gw_em(;ycFPaDtTED+RCWzeJRplR+B~!(lL`CfV08gkD{LmP~_QU-xJc6<VuZi1R
z8Sjk1h{Ziu#d>IkO0XCevhx!zwuL1c{USKMZ($w7mL(E`ZwN^$S_~~u=GjU8P1w=x
zT3N3;IlES#lT&ENt+<ISgng`3kWNDDSt%|m7CNmqI~R|<ZHnpPme?kFRJ)hXyizUz
zKB*=MT-&)-njJl+{JesRcW_J)GDISF$FJ^}@XHY6(C+FCfAeIYW;^JpfG=5be@;iy
zOyrCsaj=xxvV3T-G?EWHQbjD$Jf6L}{EFPCecj$pg|2E2JB(!0BYekKWMa<lCf<?F
zbzEUj_iIxz%~|7d-1FSI&g7w84U}9)Bcw%KaLs|Qt-0c*SCzE_OC5zpTXm06mg-AV
zxnL*ZgCRWArq9Db8)T>EV)bQgF9jA?q#xewApvW3h~j~vk$+4g@Oz#V_E^AtoBt=r
zT)@T!6?KjG?mRqUmgejCqi~QFS6?2AV;(PSTvFP3#%W#JXJn?8AY0VMBEb?ID<UpS
z;77`?ou8+5;c;&x*@jTNl?S!!zQxip9({Y!GJ))cfUE!?<AUT-hgDoBc0wR^00WXG
zG!hj$>Lh~=bk?t#!;+LUhO3#0=-$HQ^g_&8wz&!4!|ybOpGq4VcEmlPi9w-J3FK^`
zD3v+gY-do6!8)?i*Dr2}oo`BQEyQpo%yj&$lx%aS=C7m|`-;9R33rovL}jTNyFap5
zW5ABTTe-ULDi|F25TpJB=>EBAaWAO63v{s9Rf<pPHK9lpOt9;DYaX^(!IguVOk#4i
zFm$RuEae_u+f-zL$?Y0P3?bbTJ$Dr=kI`wVNKTrloC$izGvICVXH_o>u96%T7Q46p
zy;yCu%;Dq1(~?D@sCFRFGGIgq6t}*H$gVg!7G=$0S+<iT`9>P=Teyq2U7N8R9lv$9
z!|p+$0mU{fzi79`v+<2Lg(@t`B2u$DcY7x{ZHOaz_<YJ&2-SR+)^aH<zt60;<`WTD
zW6h3JTwZFlZ>s`zMn)Z(L~az_u+Fy<3oiwH_6Y+i87h!W7!zgZ?cFgVCr4z@f{WU8
zOf&r|EG!V(F)e(#@&!nb|74HZrwhStfqFbz$rN=X`nT~Xt^z6Nma{uqncCzY9hkSF
zabo9>!@$#N=zjCIRe0Lw(Q%<kKuDAdPlCuz@5r*%r%Xa%D^VLL|4x|{>c4%^NG2%S
z{BvCnU2}L8#QE@Z=iv+C)u%_H5Q!dx7`rA?7WMpc7@cSB;*#ieD@GuXQo%1+4w4A4
z<HzR7W4g>*h1;PavXSY$#E>hBF}z_7*cZHPk*iu@u_(&P{Fd$S5z!VzN5s!~92Xc+
z!QM1Gy=Wp==+Ou)EzGmFw~nQLm%!=AhMwCvcVpdpX!!Vx!rl0e_}xRbT;(<f`!73R
zZv_sO_5_>$z=Fu)s8=M5QcbmC9goL=?<MB+yJpjm8jq3NQO^WF0)Rule7WqQYkJ;Q
zF`*#t2P-dRAzvf*@+zye7&e3=siN|d?usN_rHt)oMDi*Ey760)IGXG(_Smy{2ZQzP
zuKBtd2N#GPBnx#}P+m@J&4OGW(TkjQO*O7-@sL!*wSHEs*HvJ3Eoy?Iv+Oio-kwtO
z-ERFdGxN`}j9Um6N|Wl+c~i#+pPlo4<ieequEMu&R<k?1;YP_P$-#Mideb)u4t}rL
zlz1hof`(-iue+l;+RF~5Wn-;*AloDG86w6{sryz;puU<8uUB5fBe10WjL7dh%}b)L
z&+58ai?@jTW2u}1*fk{=dDd^*Kfr6T_=BJfA497^l7;3BSxXdw#eZjl|E9taI8^iB
znV^v8zvBVGLCY{@c0T970WcRs*OVX}gXe>v3R3=~Cb3+u)m(1mzxu=Pt0iAW;j>B>
zPE#!Ezs<=oa7%C#PPG>MqMZP47?&vFzUQ7b5wl;F`&tUsDFOWh@F6=vM{BPhS$<HN
z>X3{d?bxIdkakhT)@GUUfoEoVkOqnZ0#w)>63(09I~c^uQSipm>-wg2k|-|Ru7r&_
zOxUT*2g^fMdWzNZtGm)o2c@`c<ACd%^9@%082}<kaWxnE<9tiE)+m#QGaU)32wiv2
zs}dqF{wxU5fYas<Bidz>txIvGwB+<8i)(<jAYJ5&gx=h1r{ynt5AxpGtyp={ZJ2mt
zhMF2B0TBoC-fG8jL*5+o(wb-IlZIF4jg*wCwa1Bn?KxM~TlinhDs$p5^LrH74X6Mq
ze>ru7qVC6CYxAiP5~Nsn>JPSH{7%Qp*pw#`eb_&!v|AREo#rmh1^GwAR?ZP1`>)J}
zsQ1PT9aC$={XTiy#}X+bVyezB9M#!;rzR{%U;paaE0%X)Fio_N_=@`&4R<I05Izyt
zfynXDn+G^!J3!ug>aVQv@us-Xb$)tkxM(>I;_oJf22`52T=ioTYW7pV4C3PaVabiR
z4psM<>RGtRl&fpkV!d%Qpvz=pr1q>b^JM#5JQ!5o%3<bU#Bfm~MFTV<#tiXrWfvbs
zqrcHUw6!R93nuk%%ZgcvSp!idYFvsL3^e|YcHp+(DIJ5Dnt5P^sk%=+&|o@H(3`_t
zH`oN2fn$=wEQ$TYv^Db!n(azzW}1W8((=LS3@LdFhU4q6%uWghz2e^{M%AXiP<TJk
zj-)dOYNQ@<Z$BqFz+3-%Kgi?K5fa{e`+H`Cgx>q#8PDgshQAle4$-Xs$}KZ5CG@{X
z8oXL^-yTNW%Z{La59z;gcsYIcewkXxzcHJ^$X6!*2T)#yCd7jHp9RlROh#%cM^82a
zTxvxr=jZ<c27XM=gR*0*#mqLFN0M85(<9rsqutO(ub>=o7gkq{aJXs4BVq9OSjJN1
z)Ki*lcYb`q6NSa#)p$6Id>q&lpRDqjYEe2KMEZe3749EmC(-ZaG!&;__GKu<eyX_a
z83b`S?Y0cE!o+l2xr<BsIL4v_e#==_J+b<wB9gN;s4vv)GbA^5u{s0i92V3h19cmD
z#Z>4FgjIdwFxjylGH_<<W}U$GI))hW^%|?@j1<LgP+^<&DW|4v(--3gS-LO-orzv|
zECp_JFQ{8WUeJY+pRbq04PP55ZZ7TDTRkjc*XVwm7pV+!uEfk1RudHl9rAvil<DqE
zfiTN2c66OMLser=PsWd>N+^xMm<3?ZKY*R;{2O6h<bME>iZzbq-Z=x}7v}5GKJDj!
zfEyn$8s&Xvv&c-7<RJOMM3x+1=cB{1So3vjiCCX2_ms%%V`xr#56uzRvp8pKeTT&p
z*U^VTt<t~`Ss?dy{I9?Qe*mL%{GhQ-nK>jd?uLrR$Pex!;W!_;ghI$&$R+90<F1at
z9#ZMU=`vlD8x66Dr_%%Ze7}DuBhc2&3jgZf@jmSu<CtC!w7T`3=drEUVvBfG(xh%x
z(8>~0zq90fILtV2raGd5kAa8-6CrGj#~#`zzJF-P9mr5uY}&&z!fr-R4N(-1mW3GY
zG9@cm$&OXz*AWP%`cpOPNuJGJ+p!)tzYX2UES5a@&nCz?lcCHDn}B9;+8o;E2SlqR
z+(oN6ji*(Yoc{s1M)Q`$79G=`j*7CTn#c^wjw;ijl9a5h?B0JVFnqmtuh#;7&2k%F
zpjl%oTB>&#NXnkt*c_wztUIfjqi)|o-Cl;&rRp<&E(RVqEXoH$YbxbciA|_`czewH
z%K}FISM}u0yBE}`c+iIGB16QJEA!$ToOuKDimr|#rNGQ8Y_=e76ttyrlKnUwMytLK
zts8&6$38z#xOba`ZK~}BdyVvEmhCX>>`ZacAvUT+2zsYg&UZ~r%DgH8EGiCg>*fi8
zhH_2~0UBY$A5cO7=2$6Iwm-6LB|cx6YR)d=7Up}NIDf~Ql?Yi)*@IYNId5Cu)?5B&
zNk)o0%UEn<iqDvfl&h<(D^-lB6HQ(r4j<Y&ui$2DVP5%|(*KF=;luX;7S^c1UfU>9
z0*V+b?(#2#GS(lqi>0UFIc!a=ghq+l#nz*_tdTGNky)R~)$s6Dx4f{>Uz_HzX8oea
zioDov_nrvGD4G^i-NS^`B(+y55Lws_Vp#VD#Du(_(-M_8>}gha5|jK>Q-hP7O^rBq
zb|r%tMd~^emx4L&dES=;FmnQR7srW2M*Ily6@6Jg&gW37=%q$f{ElV*b4g*tLaMGX
zd|CWXS70ix+{?X|50Sp2;dERF?dve}&UhrhEVurg9XZU>Dgk(@WBC<qT{1K{G@B0k
zVx0Kfnb3~xm%EpqD|8(f*ZrL(sgfwJ3cA;!Gs(yoQi=0WbG(^e3g@5d1#gB%j3O0O
zL_!TnkUl72cyouxcgumSaI`~=B8T<&v@*Ey6D*?vaGrQ2rLRdH_s2k69;Q=DFLy`|
zQeyTP;$xAp<y+uK00r(g0x4wxtw@UgKwI!I8b#<A@<7}Ms~+0;!s2Z@t6v3;Pay%!
z9aS{@Sm`R)+wuct)ip*8DFdi>X*T>6##m5^|84V04Z`G}-~&;bLOVWy{W5C%;*F9E
zY!m9vLzQ&J4CyfHdpjFu#Zv4@PpS&@@|@_W>hFLxyQ>nxM8UXcop$Y-f$MfTu6?k?
zDG_WCe3|J_qvj~g(Y}H-L+>3=foi0&-WF3`aJp>!f=)|xe#YlbZitg$Rdt#hAtjP4
zZpS^B{Q8H#D|LG}@1E2aZ$6KfZ_|$XA{Enw4Vw>weG11=l=tm!3_R-h`xuG$n)ti4
zBCa>`0xyf>lcecG+}^C?+_}}P+3MW11W6jrLt4mh!y3$%podI2Yr8PP!HFI27Axu9
zv(<do)!jd9iw@k1zQ#LecTHxIoBC%Cg-g{GR4HZ?#9QVr;&<s(+pa7DIloS?)6Qgr
zm=J??P)B}Y@gAvd!ZU*nN?P2ck^NXjrK?jHo#8^R_h-|so{1m2C)(`I>r70D#y-2w
zZj&ExtcZ3F#*WP%x|9u0;_d!4|9TMD$ey#8d=?--sejFx|5UH5geVZ$`mvu4a49Oc
z*LcUY<Ne+syGyCo89k0Yy<k5<?r<d2!gT5`+VE@cmpx-SzFa$Ug4W0@EZk)ppFMBc
z8sNyVgOeQP?c=CP$6}LVRQ)?SMgbu6D$n_X@B`78Ac_FF%cpB<8BrPIBwZbWPQNI(
zj=@qEE-aQkn1!KIh6G}Z{%`o+Cs|_m>)4qVhh{#8apdnLYHQ$sfNj@TR<DtnqJeZB
zaUA>>a$X_URVn6yZ$?k63-m>?Gftlzb}dW-o9l7wE0jfbS*B5@wCw%BEBRr^A0nXq
zUD<eav82ZdGc1BfS!rGBW*eTJYLv>J^fA746BrV&RPTnW0_lO=USygV9K=1{@?HU7
zJnn;v0_e;VKFJ$}wFU>ZaU1>-^!U|Ik+|!20?(NHwc&|0vcXoBN4mQ3`KxzJma)K^
zb%V_OFi~>TpoHO&f$|?-Oe)p@gR6}FalJR~T5C?9hK_E;@;s`Nk;#aY6i$B#zUWfL
zYS@1yd-z!WZW`r`r0@LIIK6&LY|dhKA0z`R)pJ<en3+6w72~7A0vm9Den|DJ{QG)v
z1`$pTd-9j$Q)^<OR^f~ixk&7qpz!$zSk~t-b>^M+6Rq5eiz2pLf$z6?wIe12mKRsO
z<eQkW&QTbf!hG3>cHC>$OHDa$9#J$THT<#+-R#Rh@C#?rdJR&%mf8hY4umPCzrAo_
zx3}+F1#c`Yj9UB}5J=dr-x<$0-k78C<tnv{Hxm~50fq0=nZH(axmIzJ2F!cFVNOLG
zX?WwJ4VW)#WGek%3$E&Nqu_F_`W4^+m-+u+vG2cy-x3Lb_P<ZSd~qXfJKXt#%WDu<
zu8|p9NZOZLlE6S@LSz(o`B2W4su6|$$4Ul#G1Ng08G(@Ql*pbCIy1VXW07<H>3CQB
zP_E1z=d4Q?L_qeb*G3v*1cOM>#^<!h$v-=9FC4<Yo~2If+gmu1({asRz;TrjSEw7v
z;4N$5r;0RCiX0zZnE*24&l3udq1SR84Y$h9)n9tTm~I32q*M8jq?Vu852kWkY;BL(
zU$$Q7UBA0lD20nDPgQBB3V7^6v}cUO+9$mCs*J1j9A=g<FHpbOO<?%iw211eZn%{~
z<a$&M_cjAKb|IJgx9{qJsy$Bn=J~@$)WYc$3rc$Tcd7SXH>R&TyE@C|lVdBzm9tvI
zguO&E3dj@(V70%-zLqzLq=UmY_8&`+>>_x!5#mW~PzO<l?Rj<TCdV1W_j6Ga(Z>e$
zXPfA-*f8=_SNuUD5&=!C&+{U!0Wk_+je-Uzn>iXYI2dt;n)_So+V&cq9qP188K#>Q
zp4LvvjORyrX}eoVDamVBDL%qwItJBHL6X5?K@m+Vy5z2fk-FXKm=)lT!KKVtGqdiY
zFN^1+y1`yfn`6n@w?Sq*5^m*;vwV?RZ;jc~0*m4I#$M{awBw3N-kP!ooawD4<0Eo>
z?<2`*htYrd(Ma-xIbGHH!Sn!!(b1tdMq>(qD?ly^5?5S6wWC|@g#VC(;Z%~s4nP9K
zL!<3C!XtafL2;hY@$4^)(#U-iiy7@DkGa>Ud~;Iz?@(7Yo|S;qrbmZcpZZ0|uFKTp
zMn|vT6qxU%ToRwTXFU<N;qvM#c{YLrRc&B_3)yY<6J^ffMzKera9~;wE@o0;m`f~m
zL~%CiV-8MrpxE3a`bv>A(F+%_w5q|*8nw(BI0{|bU8RCgj(HM8Pb2+q3?UWSwk%x*
zkWm$dnT9(PKJS8eQX*=sKZhs6@!dk#;E)q^?REzYn|jo_RjNPK-?9?z)03y<Rb^Om
zsM$ZmF<-#CNWSJbfp1o+KB-%xx3K2`^9@?J6z*0oQt4aEqLBx%LA^&1PCP3)ZWFJ~
zW&tBC5tan0*bJc<DS*a)%q)D_ZAy8>Y^(HHL&lkvmyadhMP9L|5V6g))mv&(Olvf+
z7oH|>vy47$L^_(vWM#jwN)IO~X5RI}>O9uXdvY!|HkS{Zmn18Q)Hxboy%!%1{{afb
zMhS7)W{G0glRVx=q2+lBSj$rr2}F|)iWl=mP}`V&=Hq`1O1()V$w`0FcJJiui*EuB
ziS+z!?OqC+zl$l;T?tg0CR$TaoZlQi<x9Fc%#2*~-SJ&MRr!6=anvJT=X_;HUQy+X
znfcQqyFNj5=yH2hKxPUhaq#NBz1RR4ln=^RbBN`GX4BWmDg@&wXGA9N)7tZM)J0X?
zHfPhF;A)@0kti&|Pv6b~0L5JE7AESu${w9+*LYP61J5Ee_E6Myn_-nb4pP7<N3J;6
z7xcNVU7Ll<cZTn)=7?Lrpuu==B%Y)bYoL9iUZP@O*exHi1!=`c#=I^L%}SPo#Jw)^
z*&D{TU?SQ(iI6YJ@hzA7=)awMLm+==`3PS3d;%9U##w<-+2_H%HqqqMsAIyn*;jG5
zD=CuA4%EtYf)jdJL;J5RmibR+)5c2U_19^mMx)5cjpN<{zYuzMN5!S_Jpy*1XP<P*
z*3zf5FS~BdXUD8ei?7G?B6G)JFRQY8vfRO~Qf>>5S7$%RxNapoaXPf@mt(b)pT7!4
zug*h+x5IIwb`wF0Y^h3H0c!;QEL_megnxir(@DY$;U~ePG1kkD;uXuk(FIh$06VXe
z7VP4dY=H`>Ni$xJ#?d0+D-zflMk}0{A~b5!_&8c8VCm*qF^JoHa3@|rSa$0=dCI|H
zMg+W*ix%*O*MT;Xv<}xvaOZ@u9UMP~VMf4d-u<9_Ix)dA%j41{r>Y{PAD2s_KXy{h
zr#ne032Ivs{^vR{lw8G|68v$dqw)*hO`ESIK_n%PT8Ef^Q{yGV+6AGq-pY=`UmRP}
zqw9|ht$+44BP6?xlJ9B>UJlf=2fPvqstt3Q7PbdX<<t)Le$5GS0|duXz{^q@Q82^g
zcxK`3^3Tsl4h@ZZf>xNN78anSpS-YmV3tn-{l2wjNMoyiVd%EwH8d{`)OgYrG*w>a
z%GC(>bFO};$4i2p)mBn;3Zm`28vrSh-3PvIPnoCiUUacM{(S~-|4vG!)7?c%1KoJc
z>xD_VdUmdqIaKo2$nlA|kHEBeyg1k_ENmKS02$}C9g2giwhi&1v~4}FX5Be3%c&?x
zfbDe^l%`N>rintNB#CLuF4%n^C1Vps?{sb*FRPouti@S5f9y1UOIppd&dlzvWpt+f
zsZ5_K|4UY0UR7eFTUd5Da<@`O@EQ%vf(jSbg1&=N_*PxfhJ982N-0fY0O!y)TV9fK
z7?T6pTA}Z8@~(<SVgT3B?sUKRkal5g)~Fx6a5<26>X@<fdGg+lR<fm`R<5rmP3UN#
zWyWs}n`1>(0YP4Dv|j_IvEV5neggE{MfrhEWWiD4sAEOZPuRbJtABsTq_Ze41!yTQ
z6)RDTCzY}gY1*C>GW`Twf0u_2O~ud2LEP)`Ay%ro+hW?ud@`w2;z=4LwE8|!MWxV0
zcU)O?Be+jHNrMts`P~ZvUNh>@tGrMFG(;4CV~+Py(VI6C;j>1Ttr}-CN!=&Kvy96W
z*#T*Dyd-r&o>s((1Gq>Jpn)zai{fU<BS_m^eTGeO#&?#;Lp4bt!O}ENDXM$<lyANd
z2tU%gY@w}>X3peY6uSaoh}@rsr6`Ccru>Qm`8*;IRicRAEYxJU)m)Lng@SahZ)ee?
zOiDmj#4X*eQC3Z@*rIqL$E%qgkg;<?X8r;Aub~rP?I%!XeO-}8Wb{umXf~tp3o&Mg
zlxtpjDgUQ-CE-80<0RX|jNb$1czkH0q5@O|QEH7E(osb<XT*X2%N(~QSEM^OaoDDc
z3uOyd^9wPLluq7+vu@#O-tB($rGC%j3a-iQixvJ^XE6gtR+i&2)<mNJ*$P}gO9I&a
zZIC*~uB6&cuPcw0N63ud^YpLv(7QZdE&+QN_+dZ3j4kyEuCi6nj8>m?sHs3tWCXdy
z9pfLf=hWw$q73->oTyRY;X_H{QHbIH0Akr-m8F1}XRh?Ljj3;RNG{raQPa#<FONy$
zGI_~KkXEyVX|jui8&CRII}dmeQvm72;3hRq(_d9PqbJ3@Q=VXNDa4J8(+oE0AcRW{
zkA}8emtsAKIAy9`sg4{qW8e!xetn$)-QShdmVyc4a)+|=0vLOijWEp>d<oAmLcZsL
z(f={_mT^r#?i=qA6_pn00V*KUAl)F+F}g;G<bcs3Eg%g;Mk68JHF`+L2<h&w(cOH{
z{=f6+JUfrJ*K42c;a>N3-`DlN+DX7O>;;l~lwQqsUR4poZ>`e1paJ9e*NVT*>B-?*
zO)0{Cas{^xvJ1G~Ck=E<Futt$+5O|1w75p5B7HHiuY2J{tpMj^1@R?heuN8((1wlc
zdNp?1XGI|u44*IJXyh?J5R1aMQlo^~V@Jh4jfbimN~1yb(#m4};h?uTGUw4HS|bJ@
zAuA>3u3Wt@^2`x@c_%?tfO2&jqo8pWZn|aTaXfGsYOUlq2C+gqWZAmhEZ5?F!R}fS
zzxGjXH9TEhDW|h`d}O#gRJYcPHYWIl*-_|Bidj)HRoK7uc52xd1|PO5f~sh;Jk9-l
z__mE|HBfd|)bKC6-@2ydIXYfT=U97b%i%DKI_z&k$Y0&vOb|U(>?P^dwg6-Ig8F!7
zlG{)ThZ|olsJx=kb@Fu@CcLMM<{R=f)_=6R_3w*|aALM~dp%*UpfHv<%6Ok*Fp%el
zZoCr7-O|r+#uDLme|a*b<f!vH_1ikKe@vS9$j-56yKx>c3Rldg1g2NV{F_HiH|WrT
z!M1znWJRf|DMv6|c2|T1HD6i4#?iTvrpm3EuBe3n-)@1L(O3|!Qm#kPEQA(eGZ0k6
zQCMlfZeOb|2PuVFiUlM7dUN(ViUf~(`TXiaY(%R2(uh406e2Lly@gA`k3uRonwSya
zWr*nik1S9z#mEL_t1p1dQxzMfS1xMU;0F>t$N1%))TJ=2gN@YAz+Yn-6M)Mz9eNK&
z{a~TcrwsaJ#!;JM!J5%CI?2x21M4j8Rr4j>B6Mslb|NLjO*bEFY<>=mw!#r87Vg)i
zg^M$VqxqD$rSJ5juQAz)gZN9@K6S5tL%ZJ}YP)r;&Q&2BjuDJ&Fr37lIgQ`ra5MRr
zqm&jDIU*m2zvZAanKSgC40XSXODojK;XS2gDh~AG6g)tX6QC6+Em*~(tZ+NUbd%yE
z%!je#RW?E?Ho^<CUv)Y#(x;MTg#E$_`YDgYpz;yW-XBk&x+5O%#aSYz+i>UJAj6Iz
z_s=u@@KlDxYvn@3S(2(eWvu?e%sr$p{~%6hN?Fp*2?jo6`eUM~w%e-oIKZE8axpQ2
z#&_bCI#29f0L}oNT7>cb0}$VO=pAUHw+ohj%(1wVXKNiB*5ab-jl5(3n!@%vykcj7
zgd(J87CkN7-i;uymW2-$6-6Gv>VJn!f(0W+Dwz|RS{Iom9y#A9-G+z+Y;0bneIXL4
zbkN*5jN2Vb`K@bfE1nVfX;oXB+UTx@Kjeh4ON1umVXE%c(Xu(~Qyg6*zRB)fb;#UH
zOAZbo<4j-g_Af3uQ0A9D8E}?_oeGH5y|v!@w@cbb*UdLh&mCd3qR^n>w-yEYovEA%
zj_Qc%vSL@2(SL6B8k#NX|Ga-Z*8l(r%p0J?rs<94LZuaBHf0vx6V*i93#<(B4H8iz
zKIXJ2%G=^g>Otd-zoSb##$YjESwb!m!9tI`U~lgb|L2!(JS{~#yRNjYe<7i=U>bHQ
zuJp>C1?LyozqSJc>c~o4V(+x(tZP*>$CeOt`qcBT`4;SUv5Ci_0d*jwOA65d!9|}r
zka=<p$>>YKzN~K2uOG9n(}l=+g$ds+RN>xRQJEn~{I4}xfn|p8L*$yZ4+U0@oisRw
zw~B!m<ZYdTQT*y7O>d#gUqKhE^zg(RwRkOLf_dl53pu~XLEp?~X)D^a=Dz&BrNN?Y
z3Ny!}5%YD99l78NG+}jJO>Na=qUN);s1qTCMr&9iOs{9-rVST<97;<LkR=<>=R2$#
z=VOBp7P729yK$j;=VFvz|4gb!{k{TinJ8NMA7DP=R${+NcenX=5zLqGwMSq6OLmr_
zuG_r;UiGI^9xI@nbND3=#n7wixt=uOlcvQ;J?&w%eOA4V*fY|ORNDlauZ_vy@!rlu
z1asHvvC7`2$G9oUqp~?MjxqO`tcoHide1enP-8?x3unA8YpF}-;x+H*=`Y7pR$bp!
z*KwHZmM~$Tc?~UR|Jh0Ru(EoPt0r<~c2Rz3Yc+N-tQJ9p)r-AgjagNIjT6eIT}MG)
zwKjbR@gv`aY*{%}0-p<^EKd{<Y3ZYpWi2s^dm-c25n!3XS+S>+<e@t9*WZd`YeKS#
zf$t>^r#6Gahaf|GjyjP}Rg*R)q(3m`*wXsh3i5n$epC+~)8Cn0EBZoiIS!h~tAyuq
z3uUJRuKP>O&5(;EMeROm?c!x!CS2O(=I298uRj4h_}>N%JJk)?);$!vZHnSWY+BYX
zFgyx0P_!>sdqU41BU2v-%Et~{a5Y!Ur-<|qjv^Aj`yCJXXlj$0_pEjp_b#%fi5vue
zZYs3DK-wp1wuB_k?RC9zf3iI+k3uBo7gv74*wRjMe(>FkwutM^e$JaskRZ0t9i4?5
zH}6KC#9db8$LAeuiWisXEQAQIMn|uCM=nPJuoix$$avlf*s$`}2NXzH%`dz+EAfqc
z^Y-6LZ>KRxfE>WZ(_m<G=7|KaO?`gJ{H5ajVDePrP%RN@RaaInJ`4FejOhHqJ)EV7
zp3>$S7e-T-YsYme8JXKT_3<>faLy4u!BqSBV4;ctA0?Ptjk`6{H4?;|lPqj|58+;>
zJ7Q}K=y~y~#0ZM52qrCYyBcx1=iER4Vx0&LVwXE2bU@N&WD%jdyAKv1a3UGe8p__2
zxWgUYK)N%bvU@N@Y0F~rRDhKmhRxHQ80Qqkfj9g@+$o{X%j!^bft5Z#Q9f$q>#<-x
zgB2wTI%V`_rD{F~J$>nX4YT7O7Xs1DE&Vonw48N3mzx9|9S(a`gKGxol%xgU6_zII
zAU}8y{|f0M#B$=4pj+FVVF!5eplbtTl=T;LiZaPkpju87nn?{WEQlTt(&V0Eg9wyD
z{77Js8iOOFxz3_OH|-9xZq_#1BVsyYw1<RtmB#HE+V_o9r4h5$3V=jR(8(X}a$lLZ
z&P26*?mwC>T&fWW+ttl^gt_V4O$3UpH0^i^?d~1%7<bdCh_1cJ_uhyd6GE-w@PIOs
z{m2^CN!Q9FQWHzTIT)QyS6}>$_c=drgkprHG>L3`R(15yc2NH<6=zNN!6`p$KD=IA
zQl9X7m`r$uIM9cc?sRh3=meo*Bcb|*tHEN(4(ej)ER5+9y=7W6xoZX8C6-oY3@}aV
zniQRFOqXO;v`kML9JqDt8p#;p^FFS?$j8;X<xx)9T|j;6v*@aKuc9puk6epe7x-vW
zQ7!`gw<1A>#(k73z?yS)jjF-+HJsp>lh9u+!9J~)_{!slpNju|+Y9|n;4jW$0;1H;
zJGUK$%00&AKd45$K(%*V)xbEslVXD!9{54s@Iw<yb6<wcLI3u%TKu(b83iY(Z^nS}
zU9`8oi5s^tmGuWR!`_D$!m#H(+dREa!+haQx<(FjAtyx@$~my&BQeo(SS-v=J*;r0
z0D#@{h@m6y6dxhd$I1?qK(@Hrb`(H%+w07msAqYLE&m=%NBE8&LP;@5`&XVngO{F5
zl#`r*wFZgxZBhkmr2#{vFXu-c1S(YcHq&F^+qs9lt7)CtLI=I}Iyoi|r8%p2iwq-9
z+o20l^@7_`_Z?~GDL&Lj%4~!4EV*T~=9Uh8vZjLuDdl*1A7|gKV;RKTX+uOlSce-u
zz=uC2pCEBAK#ku3St5S&F$@IqaKNdgSB`tHe4G4N59v+Hd1iZNJaGL-nn^BLiyCoS
zt~?Gj{^?hG4=s+zFs$zw&pzSXploFTJtO9HLOh9G&&>VfvmFunFRmYWjTY=9p@PuC
z7jT`Pv3bFs?_R8&HMDdc^(w@9OcPf&-YPsl{SK8j=-=~W!T0?+8917}&Sg91g)Hi_
zt@r5dzaT`|J@@4#eVk8`sj8%fQ{NH|l`O8R7DgOZbcwo7R~3_fm-s0i(6LQ||9J}P
z72)Q%lU;cIxuj#@w5OvU0E!3#iEqk;S1D}k4EtED=ox@UpJEH0=2^P4FO19^q+PO-
z5qgF|f$f!Iz3T{aXEnPrg#zmxs;N=AVs^Y~FF*e12HO?u#Te8Y>RaOgl08Qnje`8n
z#8>)KcU!SI`PoybpxB|1N+FSD=1>RaU03qs3X%&9@&9=v*EJf;HhN+<-Fj)G-n(OA
z{trb01oAA9w%G1a`i|>F8{rxq@^gd4sa!H8iVP?L>{pWV0~dh@xmMPUCzO9EBw{ke
z{YPb0>&b8izhe%<F6k@mr!&JYW481D4buMs9+YI@%x}H3Qt~RI5*ujOx9S&xQxiM*
zN=h7t%RzSk0SMLN)8CFix;NA9yJW$LxJTH>wNAjzLbYnm3xp-VqXMR>iEr5XQ!?(>
zVg%RO?LF5;*gGf5>u~fA@Eslr6&WyI$s)Zf=*xl43*P)51-!2e=|6z|%ba8Q#D7d{
zBqfn1;>=-Ny?1OL1ye5$ryW`*S2WaOyfi$a7`9Bo4K99(1H#5vPTj@n!;9f+fEWe;
z3uVXu0JH)Ell!f4#46a8{onNr*M9)0;Z4S=H3q(%V`DbHveLFJl(BRtr?b(IB_zA$
z@Ou3N_-$y3^tYT`h_46(U0BRo`vY0MHvgZC-|8)^+-~d{$(eS7tFc^e;$DR&qD8Kp
zorKR>poW<;_wfux6D>t(3Cxz`g@L~t-JKx)*{J1_FmgWoV`c$w<g8ftdPs4lLx<Oo
zLK~=wlvR#<+{p4%vz4M!y72A7XAt6!nK>u;dZW{p;z&W?c#-m{vw-TxZR<|;Rk-0c
zh!+Nj5Rxpd!xhgMI6oG$Pu43Yj;U$3KnxwJMiZJfA<Y6g@1TB_B~TfCp!!IU6vK@=
z7=h`)6gb$@9y8!L@)zHuzr^4jx05Vu*k|h>_;U2DT?cvW1w>6RK$K>L!Fda{>3bRh
z3S{h;Q~Ukj>w3?Ezs;)v*|4Iqk&D53BcqgZv@^Fi7(4gaoXxhhx>-(<dHa^U!Iel!
znp_tsZJRadp@=d6amZ*Rxb(^bp&Rb>uYOLH0ps^hf}9_X3rLwoAog6#%oFTh*JV&*
z>ysFM;`!yrai2tZCu^PJIvJ^@AU0$$Q*2i|*3N+XL`y-F*t8itfV}mmTC1LL)LToW
z1*<ntvg|6AW7sZ-?r!(w;QUc`9qS2`a`e<xv;U#b62`-%=)lmEa3<Y}Z)45O&Wx#I
z0gk11z%d$WC=6>*)kd1cKoQ{mzfc5kK8BZJ>&3*C`#;<#P8DDCYbwXIu^+&t@KR=#
zoz!LY58BR2v8GiW8yA{DBHjV+48<<{cRE&Ic80&CBD&wN({yPU4v|s}J*lNe<j7RT
zI`j1DM?GL_kcB#`DP_n}@1UVH+KED1Q6=2)2sV8s?$}wepFoy<=0UlS_v!~?#L;7O
z5^yswrhb{t7X&+vc$`?PL=KEB%!!hic4LA?b)R^%B9-?ks%<E@r>~R2$S4B&?1Fbz
zPb<t^eZ<HsBi_ykwrc=Hih2fS<mDRQt4GDKww+6MLcWY_3-bMes{(-i)mGIDN7EGS
zIuSxP#l=8spi>PTH0n!iIbxjtkOAdF{|C@D57{lswT1_xs2iH=X=SBWc}rDB1J9fG
zA3$O`k7^I#@`r%DUDRJ{o(9HZ>m96xC&gYBm(fKN{8!e5N*@;sT+<~E8&*Y0w6Ur<
z=p6~gJq<XEmdb7EbU8A8CbY%7Tgd&h!K>Hbf`fjc-usk&0gQ%3Jr&q^=?TXed!674
zeN4`Zyl>Az#d)bPolZ5XSsH3ad_vnWvk(K-mpyXQNa;5%u$oDcaS248@8n-@LpSp^
z3L|PPr>M+el;}x=(C(t6iim01gn(e-$KBj`C%$nqB0>5!KogVcpgX8mWi$RYBu05B
zPkb^p9HGUBaEWcRqAz!+7yAq<BRA8gR9+b+criCR^1jd5SULCBV+5J+m9hgXJkLjb
zL-)T})|V6;F>j*|3FN0f4ro}oPx?33&Gx$G<!mRLDx0@60g&LueE+VAm6)zkZnH+6
zjs`;E-R}sNM7|l?sh2Kc8;&DKiO!jqv7;lqbegsnSqX6P5kObH5w-@2Zln7d0HbN6
z&XDV%-7y-{`};RX=p%)GpX`z~4zG%k8VNNWpJ@t3yY?)iiemAD_WMbfLxEIJW)5Ve
zn)aA7wuu5ex@=;|ngXBeE@PPhFps(Zaf@mQ2WHgO!P5`$d|ch&<2by89Y@f?0UsJT
z{SIkERi(B<wdlsb1Z3T+l+rU&#vUY#!FL)ZQc>+{8R~B?0qk84_FXkrqCMTN1E3;z
z;Sx8oIJI3Td@+%yT*I~*iVE3L0swybNMj*0Kn!bA2mh;cdWw!gIE#_0WzHMt!`q4v
zlQf?v|1`5A`5`ryIVCkylbDrYerddx*oGNLT2oBqkW!sq#L<_-OGQWu4e#Xn*@PUJ
zx2!l(S4$a%!+k0=#Nmf)AV(=0IQb4cOwgPxEl?=1&YQMkqVCf(<N?>${{U9+)~!TO
zS=kcx9`#MSwl-iT<c~{A#u|^Kp`{2EPl;JWw|2KvK9o`3XN<Qc{jXk3a;Lb!J{KWz
zf4$fnzRJ4Pg6NStz3r9PLS>xM?f)2_2v)AVz@dN3eoLrcCgAQZTmq8jms(5xu)6Rc
z!1#eQX1^t>1)DMCoH>_ajTtt3khw$3DH5}-La|+uDDiOJaC>2*WzF}-aawZDt6bpA
zY)<C<|M$1;e$*4H?wTh)GTKXj3t!L!o>jh@lqe9OuyQJ8_hCo94DZBP)c|!5+zx+g
zM#Wk5q8z-hb2;wycZc&OQuKLjOc_q{oxf+2cCQSO2|y2aN~dZ$QnPHg*zzvToz|ic
z_Uh4<iOskk6;WD~nte*oKMDR0ZQ58eLnF2Oi(wgxx;lxDeIk^U9vnQ^e#QIM)tN-g
z{lj>1C>-i*prIjHJ&5rAZS!L&S?lgD+aaNOpnQfSp_)(W)99fYaAM=%QINX2lme@{
z=-18AcMUxrH)S#h*Uoj20-<$PUyyF6i^X67h*QUG>#I<&-fbAYyL2+)sKp2SPuk2V
zz9OEA=bCQ5V}PmgMcZ%0KPc!6y}wItJSV_xn$f7Dx*~&H8e8Y+vbT4B+ifet#IvT`
z)Ctj<DLO2c`x>@cW6=KqHXxm{au=KOHwh!_Sa8i6;EmJM_0&3X3<TOQdK5jZTuRzW
zPXHtCIlN&?QdNqYaMMG>io0L5pyX)vZ_*J3lQGpj*-xNyyB0D}+m4+iPp{0{sLfpJ
z2Q`YTAL5S?{Mq<Qj@8Jog!pnR_VX5{_Y#bqThs}%mVq9CqEfffYS&N8TCi1t+3oSW
za2MXAlA70IZFkU8_OR`IIi6cK8jo2`qZgTc8GANJ$HV1sj#NiQ5~EJrRiz1tO2_70
zAx!_M+<TD^W6Kp&w*i_mJ{7?S8(_74zb`9A9|v76lluva`I}IGGK%KRu0D)Sl9<lC
z2bcsb3-*YYs5L^wRBYp=O}>?dqkLDHE@<30>TIpbT8i~&wlr<2W`F-Om|ZZQx(~g+
z1e4OuB~28X5-onMGve}}*9-|1{UIRkoW5Zc$Du@hI3z8~BgGu@J(GHVumbWFI+L4`
z$+s|j88xoGCSU_nD07i_>49MD`N2er;`Dq|D_k1u@fl5^J{zG5s<=OxDo7e#w&MC2
zrx>OLTi}99t;IO*M#Fc+mu@Xdn)(lt8G#;$Jwvz)!UrR#_i&~=kvZG-wQ=!WeRO8}
z&uZS+B91UQbW$|!9ZnF(e3}&MBcaSxxrt?~`Yx`C%ri#UFMfhs)<VYuy$0#yV-9Ku
z8j0Evn<e7M(b8+ei7fM=o%Z!qbhO~9)S@}d{*{fK{M>J-vftGAfoyjGaLCiF9~Fm4
zAp-FdERtyqbNzUSdhv3Wc>ChBtn;rYp6^7%H4Y0^=Rd;V0);Hf;DD2aP^Lm1NWo<<
zbGEvx8}wPRYVzN97h9znEb}tp0HLVohF@gqQnSU_@q9X)+v9nfh-8mQR0fLPA@j_H
zcg*k_aGel-$n_7WVX6VPSCqGwa-O`z=3wbXOM|))6~OI`NcAo;qRVR1n1xc!=uVFs
z&Z_A1=F7IfYx7=&@B7Nnx|HeWJMasKenLjC{z((X3lw?G<Yaae5a^O#`PBpNty#5z
z`V|=diBelywdjw!XGBCb;D?I){s;JDcr&QvF|i5yAiA7sd6&vsCwZupJD7j&S7ll_
zUVD&LipgSnB(IRWw267fNH7+dxTYVrGh6slcYboBmo<>Rd(321c>{Wy)vCP}^^OvJ
z__K9nVTW;K4pZ(nhUva}nzFoazI$%)ZYPMbd=2t8=+|eB1(;|Iu#8enCI3+P+cqPz
z<rA)|-pRG`(ofO@I(N4uwK3f%g3{MU!|oZsJvQo9Bs}W(?s!~bIVn{OruH9MX{wlV
zfL_6Wj7ujkaigXNqCN;^yA#NEdAxeLjJ!=80!CY)#xKu#{PJdlOEi_#v2hkl=2++*
zhhB=_`=9DdfKapv6IGZjJJ95pj{U#K87~(lm+0Wh#Bcg<0dV~R=nXVxQ1`rQEj#1R
zjvW&o{d~oHCD=o%YO?Mz(=5Y=#>9dSqgfTlBK9Vc@%5352|2jzXsy$!J<k<OTvN06
z(K)U3x4~9p^WK>y?=8QlDAIKug6oq`RmbXj&?ai-<d8HKHj)-kW0xp`Ohy5gq;}HJ
z<k2!7{#9lgs*9xA%=^5Ds|`jdVDmiP-tq-YX5Jk3or=-b{10veYjL4X_x3J_&djZ!
zV0+^duOOa}(%m9-2X~>z-PEev?Yn2-B@D(M6rPc29p18MpKbk6WxV*qUcidnW%9G8
z?ShfXjtQPEL*v|)8N%4%$lcZ}bsdbJyt~AYUUnUGcM1PMhs&_K<!6-GSjy+dl}{xi
z=eITwIvy6`=OG^U>q~9bQP&*BC(f3uvMab|VWF-raNKUS2pC5i?D?hFxTgw8+zr#?
zJHWN83cnO^=qsvnFM%q~oAIRI*+KE5Ti0|Jzn(vqBMIl~`{wQHsy&pL+Z~U|ES<6+
z1i$)%Q#_l^R>PZ6l&3WVQ-3B>r%I`RR&Z}$xmIp)=Ol8aH@dQJgm4Zwoj(417&e)=
zt3(d(KD_u!AEI~_(6zo;qW%-4t%WgJ`Kl;~dWdeo>%4XIuY|Hl$pyOY^8l}RRSCFf
zN_sB-xTdhzjsI>oQvk}jKY4NV;LVyvC>Aa_<UMS0HN(!C>)-*$<AuRE5b|6S+AU-A
zH984l;&)C^H+c;AoUn_hZh6~xT0%GzY=dAf!XVz$XJ{t{+uF~DDIS$X>_$nsxwMV#
ziN<PT!pB-UBvN;F=VCUZ@0FYiD|#y?(*p<gf@9;w7af{p=^3NeqK65rHv>oK8*pL1
ze=htlmz7MG?E-Z*)%7`^%5SYSaS1lg>~M`#J1sm&RKuQJEq-{)8?)MbTw9@W;cMYg
zK!r#h_!=0JYD?;3?&<_k5(_;s5140dObW9Y4(b@>Gfwx<sV-knZMKX%Zrmv181OJ+
z&lIoaE?`y>jRQaE;vEN3r7l5KR3M80zSdE`^w+7MZRIhsjtfi$Wn%o)uOGmPp1l79
z0|JEdgo^P0r-}|#9C#DoOvMAX-fX=|{6Bx1t0aMqt!HkPP%uE~C&o@@z<Yfb`}2uK
z;gyaVORg_z^3{tEx!|x8b>OOY6sx+qt7<rN;`%P4nnK%br%W#G=Z%6(BK@mQ$(vlc
z1k)b{{j_hVVt{c5L|m^^r>;Qpkty`l@7qO8mB1|mvQ#9SZ@1V4UOA0C9ePp_TF<)^
zl$=3R+1!z;AB228rjae$aV@ndN3ff`qh%&y`XR7;{h1WS!Ur>!7wUi)J*&{A3@_7S
zU!^Ag#jiPz;Z1{DCt+C*8X(4+TgXnd?4KO>@~O$_s$DN96#JL$;IWv)O1f9mh2qVU
z1K?({bN84_j`Wx-7j0h0VeM!H2%XobxWUBgMq<}=8?cLkCQL1UNID;lzYWq8Ygsg!
zT@e<xa>F}qBug(Zo2dW&ST*U?s=iQmiToYUTg$-#{c^C155c~cb(Y+(nOP^^oaJzV
z8Ll}i93}i7o8GB8m@wST&-hC3jkCCQnFpb_;#&xybys&rs7F&@v`-DVMc^yBj9lhV
z;FIcq_ho(O>ZGJISJ#6INULoS#IDn(j(;<GYiT>-<vfqyQy{0k@KnonL$*J;c$UJO
zGA^hMbY@^#I(g-525vKQ$*$|ReTeJSH2hFh96ff2pfnz#4qOo@;{FkfIc{m_XzHq)
zuomTK=lRlbN7#9Di{0Df(;79ZGg#K9H(koK%68s~)gTO^q<nD=)xoC?TE|rwX1mqb
zI`9bsBEq+JB9mLj=N79DnHql;hG^%L_iv<cyVu9xJT+WH6z{o~Myz_b7}~oLec5^M
zYxua04Sf7WC4|@H8>=&ASpHdWuY3~G%~ND}ozB@NBlw<dz4|-s3E<#XD${L(YVdNv
zqC7TKetxg_u9f<2q6cq7Rqj64({-^pF_p$$@8&gx*A{NDibeDlxzaOCCY|OZ;mZ4*
zs89SgHBT0x@#!?cDNY$azxsx0Ln9;aeAqO0^C3C^$5d%BC8}eIE>pXk&Uu2AOk)2Y
znTTc|6Cly#&ka%LfzwR{dPW^)r&r6$i|Vaq`VJ-7`=<IjnU0U`ih!XLw>H$Z-?`)X
zw2pG&s;~F&-;%+MJoNU+A9!nankvWK^;pUUgo`~PyVqI4$8yRa92yS#=zTKGT@9pd
z52MNxH)-aoYBk3Ae=0Iw=LA$GcT&zcHpCQDDK-VSu-d&5P;7W#(>ylzNl2c!ck4MO
z?lQGX(I1<(cNr(eOU5oEtpv53tY}v6<EvX{WP27n(zw66F68+%7FDOyUGhb|&^OsN
zq%P0Twx*j`3xkv$uA6D2ocD1C){7oDe3=W?owPbK7`x#xyfU2xKiT<b1;8T=?t(75
z4<ov_BEH){#u+j?=KLKM7XEtk63-ia96JxZIW$c3aFsQ-dNJf-{OU5hS_{&2;2T)z
zcNysMc|}#eeO?6r1QrPt${YFhZzG>;l>zvs2Uz$rCdSP)^i_@3t4@Nu+<tSz$m5_@
zaAbBKaW5UCJw2TC6OVFl8`r0b@x!VU+6>Yig^i-v$ak@!bj8ijg;vd0-DgmY?&QFA
z5f+ATDPH1IV9TL3$h*$MnPT-O2Y4OIAp;#w`N5$jZIOdSSIIuL>?ok}F4}g;Q3@OT
z?1Ah~;%OC<$)fS8#a~pP%QEO-k_`_2TQF1bb@hs-ud@(b%V?*)?>cd~7A06CayPT}
zc@3SP6I+<m?o<pb`fCfVSaaYPv3N#`c%jPVUnkaQ4oHFv+z?{f)<@C+1q!rLtPd&g
z0UFy^P<K_M7<z1A-A8770eK@8sV_5|gt1kbZm1P2UC*}NY2=KpUEOWegc2o5h~rC_
z6RfoLGh?JU9ofj~?w`15w|T!^36r}xeShN61qI!<@k4%ZnfBIQcQiyvuEU6ev6Zp!
zBDyXlL{>|!ejcXl*qAaS(lLaFI(SttvfA<KTsBBP60>~?q9<568VQtukCtEAlr+sB
z3d~3UOsp1aKLly~o#5Vt*?QCGb?~PC)z{j17>>@4TBu%B|Bb`4(XEzz2_D`1qn>VN
zg+`DFMwQwfZk5R{Sc?Dg(bL<#ExCAls3Yvx%IK<c-OqEO^?_v{#i*8|7d_MO0xTZh
zJJYe)JJUAyEWuYNI$Bc{9S3^m(QO4zP6Rss$goEGs(DCp+uJG#S>MNZGt?}YxMk>l
zM|B_ktry%(<0L_nwCr-H2;&<SAF!{~*(e2z6Ow_s8GKdu%(E_*C&9K9y|p4}T#1Oh
zz|Th+?gpHoV(dxXk1`iu)`d8t_M+~T(BTZW4pjD|PLW^FcqN-?xd6<|r=z>g3&>2h
zTYZ3eX818t&(&ht4F~U`wQ<&pG=fdPU@`rd?!)h+6Ebo5rnQT_5P%oERkM-qiZN5U
znXb7~3-TX8Bjv?CBfJ_PXCQsrv0)YyiSAvjvR3M_J?)F>29>H$qs50VYCk#6xcO!y
zd9Drm0{qW$u}yY33nw&0{RYhc;aJHq(aQBT8sNF{adB6TPicLg%KRzEnu@cb^DW54
z)>hv%Yf|9FZ(4u@QvR*080buWvmeR(D6P?To8R*7kcwOnOm#I4nVXRo+7kN@@UBtM
zCPEnLelnpkNTNFHjVtSIUw=zz+^mojcU3RX@~sD#@#ky*OPG!<rwO|FdkUu6JfkYO
zHM|P;$*;**W2+z8^Ju2tb*oSjA;i4j3?~?<_z%#}nVZxw=a7-vr+f*=3g7JV1YneQ
zAFn|()?deA(xH}_U14Re(eY!L{7LHlsQF*qdxRVfiBQ8LXlXH~OZS_9jxg=Yk@EnW
zhIRh!nwiCWu^2Xze{6gXvv*pb1X^ZY>UED#FY^F&MIY~F#ScTyZ**m>IN%rxkNTF*
zrsH{%i5f3b=?!A#@ZI&vHe$NueDiWivb1KRM`6Q^>Bd>(<Q+#;v09o}4mo`KCB@n_
z@BUUA@dX$fH}Sjs>HCl)YL0lrC>MYsPGGH24xEW%(=7R9u$+Q^=f|bSK2aZ=cXv90
z5<$dNz&Heb;!rM<3V~sXoZdd@WcrTj4oa~8Hu-YgrpjPFAiwMr1MkKWf~}iH8VV6P
z%1uJuB{Uq!W*#?P%{W};%z$m=SSy9%79&l+$xMcdZpt&I)nE$mVi8@ZsLD{jwv|96
zv@SnrQsiTe;X<$5Giq)Xq4^_#|I5>o7F1Ski4k95V_pB1J!DG|;xx>ea$9Dwn}5Lp
zD}^e@pZ0w7c;kX<a^H(RRg2S{wd?Eo)ZXkOb5YTpl03ra0y&TqPi_8e7EvjjVZ9_I
zc#vUI+-E&tdp=z_$uE@b+nDm!3`w@~OURRsJt2`wLaWTKw1Bv?=%9>{ee>$q;@QSN
zB39rsT{}|STc%d4`W4lPJNt49-FE7*&_zpy)ycj!iXi@g33BUULa#qEp;Dubj@TBB
zlLMAgn-O64Trt@fNO*C3mM@a!+g?k4THVKx?O;@rxKZyea(;EZ;__%>q>|?{q3y|c
zPhQ&hJ_on#<--L<yDUS+<z@zRA63MV0%`pGSbsxLw`aA*K7;RZPj-JRaGFg12atU-
zo{uWHwGrbqbNzN=MAvAfcc``BbI62xOU^QRTP`5;5Hhl~UKCWNtF@5AVvctCcUW&E
z2lk(y<l~33(-)Ol+*C9v9fyO|#%Emr1H37b$ym;(=M{cE#Nk2L$=H+C5WzD|xg9L(
zkmTvWbkztf8eTxv=uF>pZl>ntjHlw#0RHZ!ZjESQb<H{YdvlIHb4Rq;kl{=0USufw
zHZH%6jS_Vx(B}a2rhdq%E4hSKHfWjHUU^gz-sS_H_i=`Or_?8=W#z6ELCD#n%g(nB
zz#+<$VX>aQ&yXV~|0;uyvBLdU-Lrjb-lgC3Wkio7Qv!*auLYNe#F=U8x0l`gsPB3I
z1MGO=Dz@m>BtC3?AL?>D7CPhy<MKA+aqvB#=X0G|<Cz`^$c)8E^2mgK7>w!DdI|H#
zcVF8>f*a}o16Vt=>})FiNo0(M)*oG1mYL-9k<Pp-gBE4yMnxrKQbA0=hRyn(@p^q4
z!fet;t%{qp2;LK7;SUGu7GGEfX2%}o)oB|Q00^D4ZU`QO)k`jful26&rskA<zGLN;
zQr^c;$<4m$*ULV<!rZ22zxfyH0_f}Ki|o#Gv6H?E;<;m*y5J8Y)<1l=b#0wQeq7I>
zPOw|mggE?7{3ZlGAGI#A&`z7J*oIl(xNDo4;SOXbHLP<u_1#aFFl6fJvYnhdtUu5f
zYud!9+69G7Lo!-)@Y4<gn5y(lG@2C~b-g@_+0V&R4Ok%iwN(=MK$-G@)#WT!-Td#=
zyr#NSFeYgm&IfJX{{YVh?3s~os{6Y0>K0+{OX1Oq5M@YzY$w(DEcajd?*~nAAAql@
z>@i&B9bX=RubBiq%AEUw_YV$leoZ_^DPh!5{MMV0GYmq@ThrhdroR6FJtU2#j{TtR
zNL!qAcLl|KeFdnTxMVrG(xDggeydzX>#mcdy?!=o5XG!kT1{0;=VriY&-Dr}^-n)W
z#IEd%D8rYLvM#Q?&s#JU!>Tr&RPKsV-*wDr-@wVap!N&nsZT<9id`u3z8HpKcYL+^
zQ2F6GeZ1=D28CNr#|zMk@rul=E;3i?4u8h4RoK5LKGyJdkzuMsxH7=7NS@qt3^EpM
zIBQ#_j?`^{39PStJybL-LrT}wTM{Hj6u0EX$Mc?ocz^OmnK>JRg6B$U({~9K4xIK(
zbPCKT^Rmv}b%4#N0xFh)%aC)jgb6C&N)xyE=&ppPPBMx<E{jgyn_Cyf_VA?(MxTU)
zIAD?}oO*>ILWRx9!(7u-*e*I~B1XGbu9y^hcZN|3vn$sS=m;&v%u)(=O2_!zRPA4U
z3KT<UeIItHw({@9{aTh;;xs$m>fl4$nf67=^w$Jhg#Zr??uoaqeFTRoAd+I6_XVa{
zW6h;cPx}NHIRU5OnA|xZ8+;f00{EvL(_bo_?Xe+8F*Ncw42!I6-4XiEY_?4TCWba^
z<EiwDUT%sM(=TL<qy-pg&Cmq%=d96zl5JpzlG|X+S`?gaX6~Jp|32fb{|kJyxEZb*
z!C}rbb&jb)CDC{<_M~<@GQ~?p+PBSJZ~g_;B&3ecMN}xFZQX9+E+o4w6j#7B$56Zt
z0^gH`XFvOl`_!A;4q735?DQ3NWxjT1GGsaVc0U6_N7ByVd1&A1X4iGS(G^JXNVEA#
zgWiYl8N2xzHgDHBhU*(e&IIq}GOlkpo@@#ItdmU?DtMOrHE4p=ZrcA7k+<$I=~OeL
zpr5Vph}yK(KZu1Efy@#t@y=AOzQ(b{dNJ8OX~eE9l&M@OQ5QVZ>Z8mz&vNI|-l1z)
zc8dzX(f#V@SOn)Dq|`InPHn=TVj;g^Gzw8|)KZ|>CSjt!0$avbb~?M(v*tv(qq)0T
zVGCbeakXnSlw8U~B8Zgo95Mc8U+8zJ$h*<H?3vx7`P9JWb&rG?9%!i(=4|-InGgOO
z-W~~2YK0#@ic6x!^wkT^p)}Yk?B!`|g7fuc!U=I>$iAtMbTV2DiBAss8+=qv(E>X)
zGig*KQ&E7lS&;;s5CYM7?Kr8x?|&)f9H!U(EHA)llUpr<n%aAH#aY}X?lj=>4}ta#
zAC4Hisrc!B3D4L*>KPoMc_0>j7FzT%a(m^NCN}Cy-<!6esCvSw4iwNCJSY+<(ak7&
zYiKWQRgH!jSN#0ATE;QxSAYrM5iK5Q^Yl)=T!Z+4=woSkW=;*=9j_PkS#g0vL8Gn)
zk(=6RTC(Phc0m{Yi5txSq)bS&UQSv5S|ol#(5lC|xJ1%UBNfy?IJQ&3<J?k}up}|^
zUKkerfKR2H=CW0!d|ax-Zvdfry3ZCH`m7)urSfj!b<^mgfmk_j9+DM<uF>0F9zN5_
z|GwOh`uFHv0v9loQ49@AfThp&*NgP*(TSio%4GMgi&(1@K3maD78!DRXytiTQGbm%
zP0+sYcUc_NbwcMytG`(vWJ`~4_#^tuAb`nSNF<x-8)n*Oc)8^#@5S7YJ%Em*q->J}
z@fy9NMYDY+LE^l3TEq>LY;(q*-iq$!83erCP|J`HpUGk{m5Iih-pR@dTLqb9e{6j%
z%{emW4Wnke;LEG9W=y$daSy@6%-*zNkUKGO@nP+#4Db1&onzGs(Z8squNR^L$2tcD
zv3o9Zct$4fZr?2f4W&gLWhSrA!I)kH9*Qpk$u6o=)I{E;D#}U1l)ksN(OM3`u=w>;
z5zbOE)v8$z9m=hu2r?zrPWlg+ek$tN3>0FmHkDdoN&``7OZB}gdKfosz=zc1^=gH5
zQYTbtVzK)>hbnb~l;XHflb37tZ;ji?@&gBts-ohhB`LT_c+O7so2ACRWYfz%zip#d
z=Jx=zA)E^xTV8@+wu{~6?{0ZXHSY+sLWZZdcVDlAK+mrtgcPa5&i#woWAqOaR2&Y<
zu%&qZ1BA6<`)eXI4|H>MnWalyYqjy<hwBt;?P7iN=)!c)-Mn}I0hFdv);14i!2@+%
z0hcifzlU}CmOnIVvk{pjPPZfcH!-G~$m>zZ-6PpU7}xxTwhRz<|6a{lZXjDL13qW7
zJ{SiE7r1-MAHSq~TO>TY3&4p~?>~xD3{kt4c*z;@U@%P_xU*m&ujZ8I&z3pX{+aVk
zR)Xn^_AO5-v$SOvm)5!jP$MMvbeZ*?lr~y5?Q3?^Og>UAHuRIM6F^{w<oq}gw!WL!
zB;hh~l^^#om${jtB!E-o^?8|sZ9+Gt;kmyjy*bm4XYnRmnWpZkHG&9*<CNet{&94U
zO~BxC;e4Wcru;-CaxNj4tBI-No7}(hAgj6o7gtzO4$;&Qw#|F1)r9r<Xq0imnL)Ee
zsh2R)avTxZ(xPieWgWm&Acfc!w!BcL=r6K68~G$l)XpPq6cltVHS6@fr$RhZLG&cJ
zp)6_XVqxDgnuEqNU(j$&!@KrMcg9ZGUKrB32QV}DAU^2+!JUE5&q54f4jwW^YZlGP
zbRMRwpVo6?q*e_l4Pe1_v!JFBzTC#y9&uwGCdDOtsu-15$Sj8HFIS(>sDqSx0o$kV
z93L{*yvi9v^xcRH$aRno_vu3doi+CoY)+=`x#cZ%?FQv2>1SLa2zk@opFUi8pFRXE
zxZRdno|M+GC-RWWY^7EG<dq{H@B>3{^3g%LkcDkDJEu=FZ;}(m^4r_5W$#r~cJMR=
z6$)4=KR6!>Go4rs4NR>@!t4F%|5^0@*%hpa{tqCz*lbhT*-eu@sjeoq`t%<A@wiqg
zw1g_ZB0BNb%iuY=Kd!UW#fHx8L-sk<AE&yZt$;c_)tK|%`w8mhEF<<Ge*SB9Qd0i4
z$=hon3{HoMy}`I*S~tniflnjQrGr+I7AIJ0q_Qdc#ydtpaO2Uo!f*LpmL5e4AOJQv
z6P_6hXO2F`!~Lx8b;1Tc{X(n?>YaOA3f=<<B%iJKxh2^+C<sf+4S!V4JI|!%3)&hh
zRb`7=O?t52=u9;eD$nI(%KNgvBR2?>9hBO2avvWf{QU~a9eH$%^M4O*^B(jmOsQb*
zQpiXec0T`OL*$~^-8kEUt|Z3B3cGlJ^5?@jN>@%=U((7qWMwAEOjKqo{Th|F>dLhq
z?B_7zJf25(lO(;hb*^kbqliPH43S@fVFoy6w*O@v$~ICb^7Apn8m1V`i=igJ2ICO?
zx0BqJAKw!XxP+&U{Tlm!=d~`(BzG=J=)f?Q%X_L~DoJSX5^S2M6Lpx;*&rFoeTs6k
z6lEE8(fPJ}Q}m83XREA70$xI-lk-Ymxt7F}HI`5NCu=N$qICcUaAD#6mh}7YKEv>0
z1>&j`URGrrWiw1a`LGOcSRHpX$V|vCIC@8OjvJXkTs;VprSL2}9N4KS^ceWqGNwP*
z?@_%FT&*~>k<g55;L*ODX0=g+#<*IA!<kuDeRw{v_0fAfZZ)_(b=6E{Zf9atNRa0J
z#Gl15#~M=Mn16h(-XV)d%)c@CQL7K5WQwhl##FRqkk#feWDMl#)sSM=r254V%E{8S
zPvfVK{XMyNUZ@H#+&)EobmKB0AM1Zmqj7H<Vs}^ckFY6f0S5dN5bf``Insenf$dW1
z$Gl7$M(epJ7Nninw#x}E%57UU98z~XmPurgeK?)ZfD$j*{{wgfr*i3SsXL}to+>KR
z?u%zpG>T-7R2<MUDbX)7R0z2&Id9W$6pCva@*tj&xm$mZF=rr3>1ggKv8W1b0iGM<
z?`UFs{gf)kPm-gFz}pYw<C*WspnJuh$oBb~9CD7Ux@g0G^}9BEX?HJ^xFG-C3?TMj
zhV)Z9k#fHFx>*w^FDBcps#|Z{+yYywE4f4Yl@Z(pRc9Rn`eH9TUE0#!<9~FUp0=kI
zllwkpCCzvj)N*4gUVp)VGRPap1{r}NlK<ceZ+|$}Ji#)_Chudm%7v#|^2={PY*SZ%
zNo~ElCe$0(9I?5pea8P(eWLXTfyy(KLv}^T-gdD)CD~qYMcDE6?kccy=Z@#KEO}Cl
z1qE)YQ|g~oq3n4CnSGcKoOrxtI5oYF#*-9Z$~yP2to4>{b*R;^gXq3xM8|DRKK;1x
z?Rr60z0gVR<DSJ8&9(9N*OeH`?Ma&{<ShF%mBIDWC6y=mgPtE7c8hpqxz}yGiT=0g
zj0;=H;Tvv*Y&UfzUKt&k{ERDgiAICZt6R{Tv)(LuEg&S|f+Jz<$?+)w-;o9<9vb+8
z@*1+JcD+UXV(#9|4i18u@Ft_*b8Ci9XpP@lYUq;y{Ye6>=i4+G^WuB2P;8=_<h5<D
z4}osj<sRB_yU@hD?$YRg0PIj#v4ldg<RZ($L~LeLGlL~@;v_)=e=WFqN%~kj-cS@@
z*|R~>FHswrXQQIeWt135jraZ5*B!-YC4$@1;nqJR@g0!wT)B=Z4bAW{DBh|Je@2T+
zQTdsf>kST%7c1@_`^BC5Bv$!Q5e9C_Gy06n<0Qc-0L~9ZD9sn%quh{GA>a(HdF-JB
zfjd2Rt7vg<1Vhx1A2p(PRb)NDZL(HD6rXbjP6KafjT7JS;><NTDs$3|`EeWg94@%&
z<O(v&V{fCRm~mq{L%&a?e?zP+nVZVim^_dMj@c-Je;TA`n2CaN@JNTi*fRuZP{GjH
z#ve|76z<p!f-P?e>4RaOW-Vv!B;jt<ruNkLCS;vwul5lwS*JbIT7tuEqtq1Go>)y)
z8EFZx<xzYjexsEr>#VYtf7hAn)V>Y$Ykg~?b+<8tX2rZ0QplDx<1#nx;UWt@bH@pC
zWMbAzEU@(jU>*CLNAFhIa>-D7jmCJp>XicTU{O2uU%s+cI`%Mw3!SW5bzKFS0y_aK
z1*aAn&jxL61b;h;z8X3RXm1;t>ymK@{I&d(?VA4OnJOkHZ~k>;tvh97SfI(Ze!q32
znG`7d3f<|F^JZ#pY6QedU1`Zji+XYG@>oqT;-TD97Z|B$biRnF%P6YbHI1T(>;*c?
zF?AV^@Fb;&I0|}~e#n|2Q{X*VR)yS=<!0pXdPc0+u&jg#nweJI4a^7{D_}Dbv<(T_
zr+;sh*7TboPkp7>yIxupaNLs3&m}Ca@`l4!&`{|I_cjyohSdu8iZ{BEYc0wkvi{`4
ztXtaf6AI^vQ*0k@UVEQbD)<dFy1??slhEPl>OL#$uB^tCdJ`6Q#EI;R!D`?%UN91D
zf1V^r&F~s<@1q`fLU{KVgY`13J*&`Iw6XqRcRrSwNc*<&c8P{YV+%HRhjwwhe^1qW
zCJlM~4?yw<EhdIPm)1u>sn&ihl0_2}vpHV1Mfxu>(Q14`c1yl9l=s|-rMtMuL9$IU
z;t$sGwiUER!l+fVh1JGLM8W&(uPvdu7q;_J58hEnF%#z7NjcLSBcS8ky!wNOoRrQ6
zm@#GCF|zB%-{HXb7FZ6EMgK&&EE+XwXd9q2<@D*WXKw^OXvt{xMJu$Q7m$8zQoj1`
zY4v}vhDUlg>BC#;yp8=iJU1&CNzg$*Yx#Fd_{A<eX?06gg|CQNfp^rP{r5-!9T9~P
zed4P;{KN~xTkD<Di&}zmjyGiy=|?<?j~sY}ku*+yu8TBi{0cd1G}MB9C_QPATW?Pr
z5qpZosKlYES#{4Y5hmMP4D`my*c<x0tE7sUm?KnKI1o@|7sy*5pE3w9kIBnR^kkJW
z0^KTuAZF1bvy|`Fzh5gXluVEsrLGlj*QBzX=tCz+33AF|$gVl%`FYtZE#=#Y21sh#
zVA>eoD$1-<gxz^n1`I7q3|yBJV^`)_g;TC$BvBP)!B<y5Nu$rlvZcnrt?oBsDxJr&
zMv4!AND8|E+QG~iT<apg&X!O9VxY4@?!^K?aYRh{@92V?1s^{CTE_mKOyIJVV_AN(
z%A3gp*CBtr9EjjIHxb+bdNz^$-_h@{t92PR{xBToW>_n1WgCQv{&Le$d>T%q`YI5^
z+9+g7RtTUJWHwJ*r4${DtXDS=6YU^()>uc9zrhQ2Qxa1rx4;q|c}gqq&5RLMiywGp
zRkeDKfuY4X(AEUvlsgMGQ~N!yvALf00wy=@I?KS-j!RLC3Yt&kY=MQ9XB!A7BV6!x
z!VF^IO?>ulj!ve!nCO(UeJ+yM6>5gI&zqRAuN}bCIzK`+yk|JM=3q(+9=83*_VbIu
znB+p<pqmrUnjW&aUX*5hurR~Z#oT?s&1-+I?>c2;<3TZjxMLeAyEv&UO*Gs_V!WoR
z*5sC+td|2cb8O44O1{TF)$sht^zkcO?cWBujo?9hi5K^AEBS>b$x=$Vo3RV2?eKbU
zP~KR#D#u*UCVuu$A45*ZD<J<2;Xi+E97fu_<SG#Tm3p?OhKfE9WEZl?2AkoF?gI}N
zj1_b$&(~EqNLgjmk>mDW(PF+ce6MNKtT=99AOL<4L3~mO>1oMpWH@Nhv&9e9^h$U4
zg<fv6?!FUsBkA3jqxK3I)n-;G*=g1M;<O%Ba;DVhdi#4T0Xb(`=vF=M&HBEeU@8AZ
zXEFKtCt0tusmVg-{9M;c)tlW+rp5JC=@V^*d(5m`jKer!TfsJ=ecqDd<<$wYG3&HJ
zr&Q--p8#QLQ=KZ`bCcAyM&>%76)27h#l}Vnt8pETlu}lnUEE#Y`@mqpg(jx+UB661
zp07x2gMrp(GK>#LVKvRMpd_-`e*!+Fm2(itjvcXp^4}qPh|8K&XRgNyk(UUHF)+Ke
zB~oe50p#gT@2xcKF0>#q`K>$&wNnPY(zn5d>iz?P-frSG%OCp>%fKm^zdI=~&azye
z^9_7zeXY_|0$nyvSApZ3vV+av{Ls0R3$d~KF&8%E@vPv)FOo#$oVJ)Czr1$*u8U}A
zz_$_WhHiWHdEWRj`U+V*sllF_8vWM}&SYB4zT*>g%i$|tnparJkAcR=<dy#niMYnW
zo?Gp0YB;U^)|GLxcZ)gS$QqV&6d*4!CI-AAV=>^E08Yc)p|iT;J{jr*_xUqOy}wK?
zAC}9`Prld_J3Xi4o73uxPqz3HimdDjPBvhk*09xKTbJny&W-$WG-G~Q2SqubyG>3M
z#&ZSyy8i1a^nCtnophIym8C)_NI=7|;%LKpJ|wdVY;jovjq7rj{Ac9`a{)h$-f;fO
zoe*%rp|Qw@UC6HfjW2&TgSrB(Nx<7D<#u6zJZiPE>a|E<l+*{m<d3f9&J5nn-S-Z&
zQ?<IA7{RzZmJeh4q->q8<u;J%{<&`w@UHefESrDQ5~<2X-<GNF?QZ4OZA3_mNcM3b
z-7;5rXJvT#RHCE7!L5sQaC19|&<Y*gZh|!a(1nFL*VI9@-t<Baj|rL(PO3=*qIS8)
z*@!Jop4x$amX`bvkZN=5f5o9M?B!DTxu|TFeIzvu)4lKpbD(H<o)3R*yJ*Gze?`Ue
zg330P8~+m}>?)9r{}pXL7O^u&eZ)FYv5{6#fneVJUj-L@EOp5mYY-z`6xf+dKVl84
zK-%RY|NEG^jG0YP1tLjCFH!9MqQAVe5)`!`K$auIs&0zO45<6dFudO|w=0uD7SYK#
z6ZfeQTl6N(XbT25k)LUPp>zh?m3KVvPZR5JdR;|ik=&#Dq!Aam%@+l6Npl2HG89+g
zC)`qnTcb@&e#SUcQqw#0ui?<&Fy}cq6OJ4ic<lF}f3vb&kUkn1+?cHsNl_clC;-#e
z{OAV+QUA^iJI?Z#v-y6yM{Ym+qID+2I`Dj4s{0@I!V~TV(gmn-3&dtXnz0-yEiHj_
z^e*|=ic<^!b!gwWq6cQ$Y9s23;v*99fwLrYVe*U%yEN6drDohQZzBr(=`XBV_cI8W
zC}agPVE@ppN<d@jqZv1ejOlDGST34*H|ak2+s<W79))5s9Zhs*r~f7%xtXbL3pr{j
z=##N9vrM#<0lkf(BUP2}@m{HI<*N1y8e?~{n0zBF0kTm<X&PpnJS|N*ksWz%a>xt(
ze~5aksJ8m<`<Irs&|(FOTPaXlw8dSE7lON#2KV4ji)$!Biv*Vh5AN;~+$nCs-Fg0b
ze;4Om<(oZnu``k}_F8MM`I)$QXMzt`20;H2y7^CgHF%lot+o4(NkZAwC$D5!Q&x`%
z1C^ZRxD=B-M8ElxyjeE>52J1>^sn`W#;J(Xwt@Y9Y|cGr-#yh*1In^?U9YDL_kCv{
zFlmS5_VCOQoGWER&dbxNRUN8dpZ?6{85_GuCbXL~`|mzeXu;eb8Vp*Mf(;Q&(Z3?B
zd;xUEX0SUmWYF?%&~uuqNu-od2_Ac#zkK1Kiyt5oe+zfh_Y)JbUT8Ypv>Mx<9(6|l
z3$M73GZpS+RB+NrHq`r9LUQrJ>1aw*L+RPM=QJ7FvfE4G&fmT@YjGT`A0!|OmlcsS
zAw8&PCIeW31%Huba3DTy*?^%GOkMWxK;zeD!a>3gV}t4lwnnHb>E_zk#iG9L;yBm0
z)GPvuBIa)$gzVsPRn%-4!_MEx0X$<PSKHBFfNmNVOP(Q4p6U!(g}WIYh(A3zJS9wz
ztd?#os%ok=g#?NDa{}!z{S<N?YNk37i4_fKrNL=3eMkHs=B5t*h5s_yq25u=v+RUJ
zTx*8-*vGyLqmEfyzt(UWz%LBsEPNeg*gW!6{?d?Dj#^(!&@J9^v(}_Ek$1LeeZ&st
zMk7)~5@Wh*{ep+ug>{p{yrh1amBVf1gH41H!;{%j(^F*&BCDl=s*KmKFfyq^ege~i
z8MtiFxk0U6><+45GEagXG?536FVV9fX$8&{U8Q=FEPg+WH_Xu&G9|xdutUdo-<ub@
z!`O!pv!oS_3g%W0le22v*JqS;3b(F*TKQvJz85@PsblJGKWWU&N*3t3YWhAS@c8do
z@g|)8g(V&GkIuUBrB~wSyh+?(>X;K~i`-fdXBlB2gKC}S)}Ni2662!$^6DPfH}T7a
zV3EK$E8^K7{8vg0aw5E2Z3FVQ^+C&wvG0F?MAH4Of_xZkg`n1Iq+Jnt#cKRXL^-Ct
zr~^XFH-A4wG}554Ejp{Qe;(EM*5-b&C5lj2km{v4%YVuipkgacjk(mJv~dS=#<h)n
zeB<oJp7u@kegP6y#YiCR@*jqv?l~ZdJ$*#Q;k$D(#LPSNY6Lc~IGi-zK7+q_RPnM!
z+eP!48r(r;Z9!0pdj*H`rgB^@%FdenqIDaaQ!1OBTvVOO)==LhzN5+6{mtThh>C+v
z_Xx<HMd9o82L&fk;vQ6DStChG2*zkaKDWob11WCxjecG{B%TQ=L4p6Ot8qr-*q1?}
zvLgW2Tpu*)E&XjByI>g%^}(LxpTq04Dn@s-b??RXneR>#KoAnZQib|jFYtbcm9Jbf
z$^hRm${*SIX~wBpM4IlSOq=Dh-z|-f<|2$!vscicLNA`GeYx=A0v!?oR&oyXeiJsS
zSr;-QE+rh2QN1q+TNq>ws$Zkx1FZkpyP(@iA}QYFsnhor?24iQOSW=9bnaM-I8bn6
zah&+kT|VSu5rF*(#JhI>5#&C#C0NBP@}s|+WTTs%`sDXr3rC!^Tf!w4A`wm*N}KV6
zuXz(zhRyiPBlv5A6cimt@Mc-eRPr$z$QszXJm5PV>HHV|Ne%pV#qL}C@J?8;=_ft`
zG);kWJbe}Sg|o10&f)p8e8byyekm0c4k9aK;z0hIh&p37V)>bH-T*^iDlu|5E1iS_
zy)sH`ikVQKfd83D<Vc=?i9?v4*(_Af6$_GnA)&H{;Zr2hjIMMK7`dnw$w)XP0K9~M
zRPc3z{;BlK4|Fyt0ghb1+k!-hMC{&>O}72TF)gS${e4n6Vs+!vH7=$;Dmx-3OS)r*
zaITuvXJP&$sf@W9xA>~2fmP7)V$h17j9tfwrYzc5rd*tY%2f>n1XC#A7mcqL78NH}
zXh_`}A1PZ67-SSr3jQo4Q`U2eoR!BSv|SSDpQkY?()UpAMbThc+EqOZG7uPj>>NL;
zQ|ftg(ekMuQa>NaU%~O0lpCvL(`~#*Uhqd|s=03ejhUi+H8@bPX$z-<rt}|G8??-v
z7ujU!`8OzOp1E}H_%dt~=~K?2IrNC#7Ge#!rJsy+4=*BZ9R~9s!EmM3w3c(1L4I`4
zYK_WjA<1EJlhMcnp_^gH$ejE|-cssz(diM#vb}<Wr(Ub1#|0$dWQ5z@O}g=TUbbOY
zReKVTE;rTMZfXS=!f&Y}#|1Et7;Ch=m-a2Jd-YqT>qupz|BK6Dh>Onzdkx*`&*j$g
z8{<%<DWSJVmW>-*T<B6+=@&Jg*l?Z$!{WK`wT?>VWR}&b#X&a$nd!~v%v-UW6|H$T
z@|PTWJk{v+LX+K#LuxP|leyd4V{$ed>Bp_nB9G?tp?+~lP|WnDUDaQi8rnFmbH9<h
zlt^?>o)xlloxs)K$@d^!T_QRxZsM(g=Yav)GZTM{u5*B~=a(o1rD6{Mo~Sq)0efR!
zD2}AdnR%pdteu5Bq^egwXkM26c`MmR=HOSWcT3s80h=%WE2cY?m*}5HoWuLQF*1;q
zVLzHIlD^LoHj2}>#9YK`R+?YsT`I#~yF<l(m->q|qrzD3948(%q-+eHuHmUj{$`rI
zT<CvaeLVcAy~t$P*gB72R5^6*Cu55-IzzK%wZCP=W?ds-e|`UMV{mUhwYIUG_c2$C
zM89b=tvMl3;qwYbSFY2rdfirkU{z?9jP1<5+bP$OyHk5&?ll*kXwsr%ldhjZRhrCR
zbU}+ob!b~0qZ`eWQas9!-F;&EIH$gSb<F>@#Er4gTdg?Q<$R(UfT;d{ETHgWIHVI<
z!bAP^Ktjy-oNM5xm#d1Sj18UYUYTm7k)C;I1!3o2t^-YUKt_@{V1KbCCet}R@(#=H
z&iaWymSVGtXz!7|B*mt>RLRN~e3X;EN<5!$m=>!}=-$@-1UPmcA;E*gwsU1sFzb)&
zp!?>DKRDrA(6;v_ZCd-wLYR*3y*iy^a`nAO9*ap!t+pA<Y}c$z3Zbp3@=VrqXAhBs
zdNr-tHU0-$ekkInLDM+!3g@YYB9RXqd#6xk{pp@NYivJ*-uJO*B79=d3CAKf{JFO!
z)EQB^%g*HE*yI3VYg&IC4iZ<bQ8efcpOWA@cX-Sc4n6C;@w!AK>KaETz5R6P?i`XE
z5jkI!ens3kAwg%i8A%7a1^;1iHpjd%d{j^Ff;CyS$yYzJ78EziT<?I^KW+5`slcTu
zf4`*6t3P8`wtzxP$e~5Py&!m6dmb2j^48R;p9UXvSK1~aJSAvjmc`d#Gfz&t3F&9}
zda>O1{%n(9zkETcNmX^19bns{m!BVM%L@W)H_OihDxPwGU^)2dOo%v;po55RMJO}0
z&W@2gBSvCw25J_{q$XXWQoU3B|1$gl@sj=Dtrf9yfI6edPrUhGn<svMM;F>7^k4It
z(C}1zv__zSuC37rW$XXhf0-~u(3|a{Xi4A~EqZmM7_Alj{|dp|mr1k=2f{4F^rB%u
zev>iK>xYM^aFu@ZQ2$^Q9Xnze93sp8Fx{`1`eEn<s(8Q*$$tIjg4ylo|K1vF2Pp3~
zUBOBpGYbzjW>v6=(}>-zj@I3+&J<^}MUp2?ESk0g!<4ipcq$XOi(2#k!=Ot0-5!A2
zc<;4tP%Y#JAFLc04>KxCN+TX1u|o#}y@nr<Q7UO2jqtv^MDPiScH&U4OJE2P34x3E
zhUl`zGW9QRvdik;-2G*EyfiEmF~3==qWfj}hfdwARB856N$D{r)!S>H=DXIr<2;Z!
zS^YevKb?q($@dbb;zK4!zewhPu;LH!tCQ`{_HEIwD#TZ4UvlDXU*W{=xgrJAJZ}J8
z;MN&+Sq~Jksq-+&F0c_-=1|?YiJ>ptwQQ{aqA5YSR4=9S%xm+D<coBCqgj^;q2BVz
zWhRG;{YY-Jq$KgCZd4e7jcnb?x`dJo`0r?+9h-QTfA+YIeulJbxtWuWvKq1e@Mdjd
z=?xXM9`q-Z!+^P1r<7l-kSX+<$~>1#CW&S!ofaE!KQsAzvFn|uq>>ot;BmQ1n|i5=
z?_WzAKC6q;`(?j3iTbfRvnz*`VJg-(i!sm-w=6abV`JN*DX-qIQ=f46Bn4t`B|?iY
ziIPxwjVnjfGo<Ni9aPbq;2%{K4);U{&t`EfqSOs&9Al=+O{057D@F|k7HPj!w-Ccz
zi!QO$<!~$gCtP_tff+Xv?h?1=&AO+Fu=AdCq1vlE_pcud(l#H8Z;zZxO$%D&{Cqy~
zzDiG>mIIZ3#8~g+8DMQ7tN6nW)uT@KtMGogHxjE7<t775tRaZKzI3iXZMa#gqYM7O
zpDpV$R(*_HW@(F?7aaL~msVvR)NJOpfk%%{++9%oeMO$>onI1J!cAbthHnO@GB0GH
zIPmh)6`>a33P{!bcmLG86R!pDB8$)x-M`?W(aE+g)&Hl=01WgAhWzGbCI9!Ch7c*@
z-tppWQJ6(2USgky8Iz?3FEj^2L4f@ysiomSNdXhph|KoSTDYWzwf%GW!-bP5%>Yg(
zh74-|hk*$&iSqF1H@JqS26jJk8xQ5hJ@%tJWY^{cSwRBEv)<dzY^Mjk4Ymr`x^kvd
zUNQPieBHGK$Nby2-)B^jN_BHt`7quuSWPJc;yfy%WOy07fgS?Jz3#@NL+x-g+uoA&
zkG%D}A<gIGUvquojH6KU7c-Z=d%s(zc-%gh(oAz%YLIeay3Yd$LQ=922;JZsfQxjm
z{tRK}-%kO+!NFeXn+?$VI{J=Wu#h(;Pa+&8=-ThrAfoRDFD)^wIvM)N?xt|}u#23U
zR?fd*7c2mQ5eTR4&FE+}4*^dDJ&eO86br?&2fsIJLq8`Wf}Bp1TwmsT$h$!oPJRCS
znlAjeETAr0`|Z+Hznn4DjfyT1vK7XnaOF0;W5-fz>jm?8S9^1Q&WdHE=iD?^dEQAr
z<7_M2VGiYPeXbD}Qcn9xa!GB&jW~T;Au;OJ7ga*AVprN4TlJOxPtf@{Qo*j2m%1^B
zB3HNhHHEGcBx2u2-Q_>(*%9{h+X9B*Lwh#Kx-~Cf&b&56T396e>XIWh=3MUBh$#)~
z-Nh7_+=zI<@2SO^IP~N^tJrdRZ}r;lR(^g#)gSZ3362?AFAB>qVa9HIu%<VXeOWtv
zf8K#pY4aw9S0~?nXttfXdf=engPP$%$Puv<gX`nol`5y)0pQtsZD90$Y)S<u$u|2J
z;qlP3uW=;}*}u^PkS=I$4xxQl1X{s<zxJp}s*70Z?zo&Q#noFXzBn<9N$8U14w&EZ
zPunss3=ZVNR!swBYo0NWgA0O8e<55imVRMd|CqBwRA1co4v}iRAT~wu_}P;d_qIN{
z=l>$C03tU@i75RI>}rvK_1?VTjYl+Q5VB)Kce8aO(D;zKn%R-s@{h=oA1moRqemS=
zQx%flBpub`zv#0CEQobbtQU8Cg{D`6#b4f&d!@)~^JTG(DDklpY7H2WI`kg&ObHxS
z)(`=Oi>DoWwLcVmchTvg!9{m4{E1rU8P}2`b1Vt*4jwv;cELDA0Hm9?0s?Y-y<Obu
z$fEc$yxlII_F;V7cqa?wa2&BT2VhuY^Nn|G(8`M!RbvAU(CV?uK)R?aw^FO^YFs7_
zv(}l}MPgM0dTdERjZlDnA4B%h?;7X!qmLrLr(8cHre$;}tapaN*&4Cb)kjIE3}Lv{
zWl5)xkwoIIVNK4Z<BP>*bu2zwjaUE;t@mJ3{<H`ai8=p4_gnUoG&K}ur5*!j3pyUP
zG&-(788dU-KA8GHjL*9~BEo9rb-(qE?ijXrgqhe!DLVf>YF?CW?6tUf!tsn+f#Glg
zPkG_Bvh!cn&krYTpj&zuw>%BBZ17Z3s0~h=%*(|!Nrsmn5DMttqnsFlMT5wZKaV6M
zYF<|*zGHk*e-I?>n_P8AkNg%I&Uh5Y<QadP&C$C@^gd&(p_^0SDcn#ME8Sg6WoT6R
zJ(4GdXk+@7_vdwyKg81?zsv`2rPavd{9=9474|Z%W^|_hV-)?=zJJoLw~>)6L}-t8
zP*JyQ3-`U?W;$=y1xn#`hc(|uT)x`nQ*gBtKprRpSWQH3SZ!m2M1@VAO#qk8jVjI4
zyrH@lmM_MG0%e`C&&1&iHOXZ>yrd1*Y$sEcFkQVKR!jp@IWbG-I+;BlJx^Cxb+A>L
z-}UjHT*I26z&B6dBzVJhlR+DY$<6W93}@r{_q|;_+Q6z>Yfy{b;Xc?DG$QTXYyywb
zI$C2_ikQ!PV84Bt4l#aXC;$wHV1<-vH*p9UyE|`-xcg2(mzyIccuTt^uocvuvGu54
zMmDJ%(bp`lbNYrkzZ#(#EX@AP%q(A*>zZLv()dO`zym<OQIv8pHz&ARlGHY%iI7?*
z$fG&bw|b)3vgq{y`xG}Ws;gNmIX-0W-u_OAz3nXx^AIkUG&~aMW?!S@^2si?_&Z=4
z8%Eo*a{37A@4|?QxqCUbnQ-T`cb-r8a{Wm_S3FXnsf6}d1=ph=5Y<Y_^2IV^CyA<+
zR9GLyjA~I(Gn|YR0v@PWWdYp>m5sYW|6xQDFnb`L^rEUJn`hKJ+YPT3mo6E1+-mOX
z_}pk{niWpe)N9f)&JIAAx-De#w!ES*enj)B?)bJ1NS4F@>XdS**DT5MW5)(Aw<QtT
zY!bSKwDEy|=M=Y$5KA+hi0y%_7+oEia%~hce#}m5CEVI>6p>)sZHTr;nU85aZpi%m
z{7O0t!XGFMGRqwJ;inptx$ucqf7tIVE_T%GHzF8#%=J*(Ob9tN8E?2Nw2RfS9%MI>
zp|yzodK4Nn<Q<#+sKZgQV#{+m$eKuuBqr!yI@rE^>AIrCF}8GZX$&o)Uw`XQgtaP6
zSNOP}YU9IJi!-g<DB(%IzB|gtCK4B+?&KE&yKZnJJibp8E66f6qdZq=7)Quqsq|lc
z8JKk#a-3|e9Y-;h%w4`9Y^*8mdp$SsbWR|>=3-9+e+h<N)RbP^Uji4Q3`1D(7&Ty~
zlHq#&LLn$O{l2=Y;*9z<5g2mR7|iWlPUz~VbEY?AoT<IH(})O)EcmBD{li!7#%Z^P
zd=tVP@gZ*5M@2f-N$NmIL%&K>!*4Wy9I-od(f|o4E_MW>VST@*7D%CM$2xmO!y26m
zMOpqxQ<TBd=N^{}lpM!PrghWZpNEZTi2A$38k@n7OE6F;lfbp!r8Y}7FK;ig>-gnJ
zX<;96marl+XTk_KuDOo^$9OUjyW^!<DT&)mW76~@$}ChneJhOaVKR~hY;2EUeH?PV
zIP0K~%wd+jN++%V5mGhJYHNRnuwj9jx_CL&{~j@C_XhXC<`$F<zAbnMRoR--1pIrm
z>>ggPzfLm6Y41k3TqWK5Pr{(0r`(%qynA9hsM@_;(Jg`GiWsl+2Wl?QqY)Ii8t}Sr
z2y?eOv&Qdfg+EUyDFW&E?_=%MJzoDhdBlTCpPiYXjtJPx6wR^W`O|Di-A7vQ8?Ijn
zQ&ZpznVKfyMGXIkF?X5PuN3h(beFgnFvHAFx0dds1x;hFo=nE^#=^Vxa-3Y-L2v0r
z@aF&(l@x(0WKc0@URca$<<Bv@zbN0>s_Sb|qPaneKzRilD|El{Ip%-e1$x4d9^vDC
zF8#j)OVj^`{?EG<fr`=!yXhTESvYLM%)Rbf8+#!ZUsOK~o1qP}ER{hcda?A%gzUXr
z&SWfVnQxYK4+_E&7fi;%x4OGvLDq@}WkL%@B2txQP<ibzi~V%f#PGA{^2YkBVy33+
z9!$>6b|q2P3#<@;g>n6~@$ob+^wPVigpJ%facha8f;w#6gW#JVDZ&<qwT3h=$wS?z
zEEJl=d;$tRFx+wJb;cmy)WMBdEko`e!;<j?t)b(hB;Tr48z%Xz(z-ujojw<~^o>4e
z^$+VB$b7he@K~AJ*`Lu}wS9%Wx#0R&aHj^yMtv^3qg>OF?NgjHMtTMjkal!DoTfj=
z_bRK~14HW6tru)#o{Egis;XNR;mrz%K@WsMRkB~xT}1AHJ0@B!Hk5F>gQIja<h2>?
z#gPMdP?f%zr{GDWWnn6CCWbdJ2dq!!dg??0EGRDZ)nZ#;30?y`a`&%Br*Hg0ZFq`!
z$&pOE?*$NO#21BH7R1Id=KEdQ`zj~h=UUtHZo!4^QDuuZFyGL|$W#wG>SlHhY7Dv{
zMpN_<>b!B8_f_JAN>w8SM~j^T2&iIbw2#y^itX;JdqMNm;*xk4ntw@UG-WGfgKE^U
zDMAdd4gw*RM}T$aQxG0{@nW&@FyZhrS8FfMDZ6rky}T$Yl1y8>ZK;DwM3&si``3=|
z)G6xA)&OJt;$-<{+t20&!}{FUiq@R5%ZI0e(8zKAa;?iA3+R-0L9LHllERB)&Y@VG
zA&ej5*c=@zSU+@>W=$*)>7)zIl9eJ;^#`qnQW#VE=ff%1oIKdB$+sI`g-i*BO|Tmo
z-Md57c=CD-UORCJZ;H^WtT?#@zFBt5T;Q74uuX-I&}dFWzEnateR0Dx5C<8jbN;rp
zbX@`pJ3hzOmlwGXo~Q?_W`gC#LV$rF9+P3h5f~om(Rt<j9l}i7P*~646nN=6<?)1F
zb{7aQBOlct$YbOm6|@}8b=WZH?8at<h$)N)7?z2PK=Q7H4Pi~TP7E=BWEs$-X-zU0
z)g7i}w>Jew&(aM(W7$JI!@fzjpRq(xIpuT_n9UGQ>)0mVYh*uWWBn7KKJ{-AH)NZq
zW3fASdZ3Fy;_@YPE3U}cvj(USyANJ>GQTTZeFRKq?&d&W+t3}hcV2t$ogdUfzm9Eb
z=cUF>XhvE-zZ!}FjnC2T>?9697<g1(ef|$)?I?}bP%YF$<+iMJqRr!0WzVtxYMQjN
z%^NRL2ltPBFPbGRu@GUx?N?;D8_qbCQ8kJA_co?Yvngmd8t?x4S=5q+KzkqA+dlEx
zUM=W*gxx*#p4$1`lOrHGIpA6xz4x2bh-y66#DuRqi7f_$d!=<HnSBGqbEcO8ChsO&
zThn`v`pvBR-<v@s=<N~$BWg(KJaCDUG5HBZHqhWa=x*^=o*lj)=sD>hL%^`9UKDfa
zacMf8l>q<UHss7q&1u`Fjs4;}Z6#;rDcSG)3-`gjpWJdP>%*4L&luW;GjsAzB-t6T
z;;?d-Jv;776(7~!wo-cb-{e>agdIPAsa>5CiQlqBKEki030{u%=|r(QOjyrc`@ql2
z(hge^z#BQwx##&Yu?1xB%c22EJ1^V5nKr1-93y~|2j%ixo3BfiZGArh0cP7(jg<_-
zmhu;+hmCrUsfx}!d}Wx7_D(~dzvc*vm|W^4+1bi}CD)wRSEM_|hg4WmWg$?hLUnc%
z$M$_ubgy^L4=?rnl(UcdX#zAXCTHet@=L@$W1<<J75-&Bn2C-V=p0);18OxHyc7JS
zeD3O#8m#49_x!tvzl?DqEaC?L=JgS27yOZNCY39qj;f`VUxPSo=tZC;#a_>p?=8Fj
zN9VzzWaUAW;$LM`B(0Trc3S=q;kp-|dIIl({Tn}+3#2+GK$s^`A|H~}yrMrp1h5DO
zT+Y^Pvymf_YP-YvqPS)l&t96*=Q?4Mi|3Tf@u>7kZ<()RL<hd<iW?MFanKtTm5;>2
zH81uWBmJzWeV?ynLRXDz2TY5G@C#q`ou4FTTUj$fZ03VZ*ce}-U0nD95w1!`Ez@Ni
zE;stv7y+JTc4tE$0k1xtdq29KjqH78zenqMy4I1{dnk@-Wmgy8UIl}0c~6wbrgnsm
zk_fJC{_g_<3Tqen{?o(@ru*+{J~Aql1{n(~pe<W|A#Z(@j>dHN07dkJG8R_rzS#G_
zJoa5&d-oK%-P|XAt2ViA`z_QTiZR9Eo!aS^2vknwJga9+Ys$mA^-~0~e#y~;Hk|wX
zciU=JD|alNt~gvsX#v->aU(zzq}Z1+LsX^=*6~Ok`Png&`U{<jR3+Y_n%Yyi3}vOM
zf7sJ|dP8>`|4#g7WtyyOVd?FDq=}{zWkek-9b=!!>==<Q&-Tu}xIOYIitdJ`d~(4q
z2+a*V%zRQ8KT-b=W5g3}(0bQeG|^HsiRKA}n&_s#JYPMR_kGf_t=Fx-S6HiD>>ErB
zx?}gRowl?V;e&rYL*Hoa&#Nd><CK+Y8fEbs0q%<)rgJ$Ch(`aruz^`t?|OCpEL-TE
zko<yRJe35U)^8XD85?#Kpz?B}r<+vE2KUhVCf$WKnxd@rTRgq>kOIzU4W^b-4%%L<
zYYFiIV18=CPB4GwwRZjHwh_f-Uvh@Owu5o3;ofJ_Z&gUWPK=aS@%@5+ko{@qs$ND%
zj{UV|Jabs94K_m#D0be{C(r7ECi3nB;@H3;+sf3g42W?vu=32Vi}~Gz=uVZOu_#YM
zZq0%P)*-t`LD9InPcYp@(G8X{n=sC{l^JJ5nP{CsTk-Vlh@{rLnncfn@Kq^f=Oolt
z-U|1Jm9VJ}zum^^h}=4_gO(-)J7X-_@mwuFn5i%IcRx<}+H3a}rk8WlJ>wsF6x{o9
z>Wl{sBGkyg9iK}WHHHz7;6zG`sO%~jGn>6!G^K~gGi?8Y`oKmdCA_jMBRYvdm&Tw^
zO23yeJe#mS88)j(s6ij!$$AQxoBxF7Rm4n7Ipu~2rDs`R^XVJZVPHl<?2;u;A<snn
z^(%^8yogHG2luckl;tax{|e^&KGY4um@qTj@U`_<<c{9T8^jb&mMVDW-e0!%sqxS-
zwp)1&2_VM}aJdIjuj}?2a`DqR^3T?z;xCk+`gjW~W|oQ>va)|qD6`h<j*)H@mA!)|
z&IeSv>(m-a8Y3@Yy-!_$lbyzY#k-~d;;lQ3ujIt?&=F?6{P*>ufS>hRqe6e-`Q>Ga
zlbWOJJLs%5)pS8VKZQ}c5Ur={y8z_D&y-p73Hh^IT2Ck%%3&;$oUWuY#F@{|Wqh14
zWry`kL`)7ph6)awk3e^5b13ttzB_kaY;(WO)gSopk^9Iq!@G~+xwx2r3^<ECl8kvN
z@(Y=dYPavd{&Md>eex;=@y|rLD7ZM6MFBw<jjx7a{wL=rlizmYF1Bk}V{}$H5~n@;
znpDq`m7PnE!mIgpCJs%fa*EpoFJh8@6K61dFUJs)GL|?}&l8;JAvv{_zG#%4npm-S
zaJ*Y!uJ;n?EJWdaPqM|cH9ErR!h~Xp(IBEG6pPlU$_nDe_r5f=3evPeM3n)3Ik;@`
z9CbQ^VZuKw83Vp0cyPwH1h$ILhmGk}nop@JG2Hx2xp%hv8uSF%t^E%}qa<+6k^d7#
zkD8+hXZ!Lvtz6Q780!tT#=A@N<WAdvR(;FbY?~yVE60}Lo<`Iq_c6Nt0>}^Qngy9D
z)n^*PmE2(VE`@(E4oxm=*86jS_!Ay0_*8sn{zr{ylD)WBQSET&Oy!aq6l}UF)qVO_
z()v9ZZe3r+l~4(AVfLsobR8M);D6`*?da2{^|sJk?dw7}RyW{>K<`Q!{{r&BJnGl&
zPh=jtK3aqEx{FkWj$E&Fq*g8zlU>A*AT{2Rl>5BxlcTfJA{=uu4Q_8#NYo=-&DX@N
zj>)bsg_P}6gLJ;%;RNH>*kHTAkCs#QiA|kCRX_UWluo%_jDlsU9r(ng7B3!qgACPW
z&?{}9%f<*U^xK^b<=!jK!B9Vo#OI9y0Ea_#T`#T3ooKkcL#o~}WLj1|Qn*(3v22@|
ztlj-xQSuX<L{><;H>q|RXz1dcep)xP8^ypAwuF6htGD<KD{QcyedFyNA^I2Q)vfR%
zkZLk+ly4JpC$6%uq+w)Rry*@*AG;o!H-+7f<%<UnU`JG&XwDa#HObhv=s)dYzJ_p+
z-N(ddd(fFAJ)<~ljW0%a0o#GGw6ul^iD$>d@D*MM=;L)`u3@!zx&Wz1OwoTB(*}P2
z<8Eix$|ljI3l86$kw?&goNZ|N+)=G4G3-Oh?|<{v+D`q;3u^~$@Ig)fU^c#n={hS>
z{%O9{uv&Pk54)==;s}Ti65Y<EFs9sKI<_08u%zfYw|f{Rnn;-{NU&!z6TnQ>pc-My
z|C;wd|13{l_5ZvXJO#W=u>Wh3(7h5`pTQ8#=gp_j=l$PjZdEKEwcO7EvDnYMM3^gK
zYITq*Dq{JVm>Br5ol->PlpTx0o35DV#FWJ~Tu`C~-w(UIKP8_Q*Ysl@BEH-BJWnK~
zqtMP3oz})>#TAX0GM`(HW(6s10XIMfp&64-Z!~<ToF5lf=(;g$U7;8{z+i+>gtkHv
zt9i!P0*ht~1YA;ClJso&F;w`a!+nV!BQwBSJJp8Nm+QOuyJD<>=}8o|!QlZ<QcA6v
z@?6`1rYU<wb_w}2<1;zR&7SiBzerO4xbw|h&em;@@0t^O<?j0ll~{dBI=E-})XBW%
zFJk*S5o@!xLm{x5DJ{aGchT!ayzO;#yr(!!uOU8=?p*^7Ham}XTVrXXbLz;+oLPTD
zo(*@4nO%kwko~0WartEk{2ZlJ#<$(4rGOoQhyznBbtTg=(BXTp`2lP$@h3g2`kZQq
z=YPiiec`$ocOa+QN}pF4nL@O@<OL}aJrm=X9sK(fpWFkpzyC}K_G4X)R6zyQY8k*q
z38uk42_`Pn@VE@nP+fVHa;+UqQl{1%Df~MuXdRcoxq69?6b*qv`luUX7(H<4l$A-o
zZs2nSxQy#^S;BkLSV!VE{YK_MC91l!rsxN3IQ3HqWB;%IBD)59aDa1i-!l7zmlD?}
zuDK+E`y3)W_<h=EqT^`vz`uK_#D9L!g$|K5z&|etaVUzL?qFbG?>yS}aWXXS-5?kF
z597gb%;2w@gbAY?hg~fBke9z)=CqDo8{@XpB&%>Ai8aGmSA@;ZClxQVC2uiH+qKr-
zEgD>hLNgDH!3Mc?*XS3P?Y+<WJG!^|1T(4aAHF+$Sz8q88@C-peg6Ep+j+9_N5?N+
zrvu-{e61CS9~0ULGHI%GIn3W3G?Jo<+e-LKTe$}*Ek&zHCF)AY)ZAg%IZGaTI6sRf
zO^?hw*sX&hV*Fj0^gg{f8&<Y$B952(Znh32ldUYpzY-)FQe?k8!=h-PH!7R1LNL&X
z;-s;LVlH{6ip13E!e0$h(J^)>4|;-C{=?A91w<;UXvig8^?`TYJWp5GCf%Bn*?ZZ=
zB1+>u+5l->1SJhUm_Kssh4^^0>ji{8nVpIzCt5!nsfo01f=6$WVrGzx-gjj9`@Zz#
zP4c&+RYsX=FL4`~m}nzvCvFT}xuYB+xqb=YA>QqX^y~iwzw*Mh#zffSg9e!DkJ9J{
zjN?YqXnVo7ju$HuI^JOck8w(>3syg)N7PiePhW8h%(;P>P2*+}Q+mU8b;k-d7vA{y
z>@o&M*Fycl&JDRt!PGT#D8WrH{p!<T1d~`Oo+g4#-Ls7!=sOc&nZon<_u5a;2UY~j
zvrgzz?R`2ALx*PB`Cz7>82}1|A}7QSy)#b#7Vpk~pU3X?e9hD#s^St$OH_<b%tq~H
zPcCRT3WtoY-4`*~8g)>Jtgu#|)HEZFDqg7(NTk_}aqZ2y@l0wxw=hG7^G3&4U~CeU
z-*6y9aMb}c!UmIzliN<_P>r57)RywaqW4ow?3A*RMgFAQ#L{N8x(@*`^-SFBj~vDk
zfT_KO`eI=X<)&H6YvP)d)A!FtKp=uSUSBA_?RV@Sy+fQ`nth|k?J6CV5Xwf8C2W%G
z!v<Tdk2}cPy`y2%$)#<?v9{P=eEv>P?_NqV4X;xclRNiui>F>-1MflE3H7QQuTIlE
zcHNvRmQCFcy<I3S*$bKgCQ%bLv?;e57tl>{O2VoWla#i=r@Ts^b<LnGNp;~BE-p$E
zRCp(HY{%m+ls~`VyR*XYlK1^n>#Z9XwaS`xrgSD-GfKm0$-5RLT_R|n3A+q#%p}Jt
zkdeB8TdEM7r?|SO1D|-^T3ng)lDszj#SP}>_6)H?5)0zP;yODthKAh!go1`xqmr1s
za_sLMF81w}mW(mt>R00WWF|_y2j`_$7o$f)(nuB3tLX%mL8O{!hj8Y-to9e)GIC4|
zlKznbf0m(`NdX}!4Kl+rbV6<lG^AW)zwYR>T#(Tab08j3Sj3v(UEx3}E9CWAz#^*z
z6bv~ctGPkG7T$b||3om|h&5fzj+ewLn*)F6td5Vp<pRK*A2Y)Xr*fQQ$DAqGv~R4R
zm^;9C9n(-gZgrl(TnWUm5?;lk89YE$FHqm{exA(WjJdvjH>7x}A6_z6+t@mN`lUvH
z6i&)peG$iV+|#>$ycH5&e2ITDs(In{A4bvf6H{0ztk*;L%>u-w4OOqUwqQB)`td<!
zhJ!HACO<~J{L1{uKhK6juLBdd7cR&NW`poAt}_Dn#%*hib8TkgyFAeAmooohbXIEB
zP{kz%6{o#8zAM$eafq{DliO{JFD+cXBZr>=F96q7tS++)h_bJ^bps1yM{J!`grkqT
z&lvm-lPHb!U;$6-4QREpLA(bDXByasDR6!-^}O)*WC062l3ln}oIG*}Oo3$3G~lmK
zQ8jf<rJdq7jXOH(y-neK*6Ak%zQmhPHt~6jsS0Qk!_t2kIpgHAZ*pMXb`E`Dfmt>p
zrE#Wv)mix@6Qpa^$9|>Q?L7TIGK=R@I~!&%ZzK%46Nu#Z#p0I_uZGMfoa&A_y=;+&
zu6p-ZWp;7(Sm$T;0!76^9J$3w89P6Bmt@iG)yo%Q1WlvIX@kk4EW(Zc92Kj&UfxtS
zs0tkloKb_o>LT<I9>SM?A`qKX{=QjpVt|7y2?~rpDgY-;@&q2lk4QEN-eo9G@l3GA
zkH7Z##?;61dimQhq0@G7lkb+?Tj{uHcX>h%G1YhkksPDocH9S-k=GtFFXuifEYm{_
z!=f4ky|Xz`Ia~@I5?e2}@ST1`j1bfps)o;ryn~-H%?U~w%}WYyhedpRMm$YGCY8%9
zAhj_<4^g?%DUv66!3Gkf)rz#Pr+yp3{<lpRkH6(L>_t!SiW9!C;0m40WedsZjD1BT
zSU#9`@tb7I8gB30X~?O0<3`8t?pkkqJ-_^d`<mKIjqk`KUUYx|*yKm%7<?*zvBT+p
zaA}M@ZT4l(Fbm^KbltBzu@kG-n$)!Y^?}{vjsde>Jml7E1xY}#+aNQa%g8p|y0PPj
zri3Nw5Gh44LcAaV-iT7#jfmZbg%YTko;keEk|7)wKm~(lvuxXsmklGM%p0vcm)Y}d
zFL_q^tUE%}S1tV)pG+Vfs`J|ovpsS+uU*UW=DhR*G*ILVku>b`>!w*hT<e9&ppVmP
zG0c2s-3`S3_x{^4gkJbb-$8@x*S@1DrBK5D(RYO|nri9Ght5<11s*p2VK^wWs}6J)
zjy@X@*XpEBY4PcJ&yDdrwb-MELht-hb(SDTzQFW{gGJ|ZX~Ep$ktTIj&9KmFMa-%x
zcZ2QXto8h<8FV(z7lGP*Fpa`Z#GSKYXJQ%HY8wxU*;Sct`O<w5C2620&3#7YUYjD%
z@biTK?o7Rp%GGMpXDq@0dTzC2wE~FvCn{8GZ|Jt*;3Z(7L-+1mQ+)3R=3XL9%OEc=
zRo_Fd^QX_>=pCv8y<)TK<<I+b@>kH;D^y-u^;g_LN9sw7E%&^59qX``5%HP>{IB2t
zIY8cn;zN+ZmWaJ;p}0afbK3l%SD}Y*iN9oky<(@HYza%yK3-$Wdsl}f@J58Sr>slQ
z0|Sk7wX?{dZ6lxL?Y@ylRPEE>{N8z>k6BDlnRWmBGgiM`o(0t0CzN6TG0({3R3>`E
zHaGjMM0t0+uCOMpr1lp%RqszCo<XcflRaeT^j>aJPLcUHd{^gQXY9E^lBZWj!b)uV
zfMKZ7$6Tq2sSS|&xw8HR6#$?isrfUpEYd0?Q1GqPzP|IJ-AvMzE-%$0jUDh^jb)o`
zQ|GMzA)wTL#jg+uY?|c1j;8Wyce^d2;m!**CVSpjaU}RwJACbAuXJ+v6Mx8Iv)(0s
zL|Gv6XJMsQ-C|L;b<Clt2cvMm$XUa6nGT92yvUk9F%%YmpZ-2@yRTCcX$KK!imbF@
z5mj?U5398Rf%!q9kOuIY58zsXhP2Rc;?kWeeyu_9OgJi{TsQ(t8d^NQx$Zoar|)k(
zZ3&;gml1j3wc5ag$v%>}pD(WdM9n#C$D>#Sc4c$WZHX4z6keyFylGdBRPz|Si~j#C
z7VCq;wEQ3U(w(Rao+rHFE3qWE)u5EpP*Dr~MLjwGHJ=fE9i7l%T`B^hRJ2t^cOI1g
z6KDQ+&{vdJboCp18Hyh{EU6RC>J(iNN2(XmmQzRN#n}C(3HL`a(TBPITwxOTPYv%Q
z*@`P=Dm3JyEOR1s%>v>K@MFe=G7V>1!;}||RDW8zA_P0)x(PU#X<E}q@fTTzswN+m
zv*Gg!MfOj~MsDg7Ctt_oF#Oy)Uhm1xlLup+p`E$>oj&B+Ifo<1c5VNC@Jt;IF{aSQ
zcKBDVZwI6`yfH4}wv>h{bC}MN&?IkI8UR4y^UsO$mG<hOt@iIcd%smK`2PE0o?NG{
zExlM`=p)gQ^hYhc#=5!7vLS~_S7o%6-EL;_#$?@V?@xtCi=5Lm?+2T<Wp!>V>qWGL
zqC^F1SaQ4!U2{)q*?eHz9bbGydGHy)QYLTL77#%W^gxQW)wQ<}-$-EExoQKG&13AK
z8uOf5>gLsE^UT}n^S&i6AJ5P)M;Vb(hY7(yrI*$0I>?i0)PCmd#`!FF79Jh79No%*
zqhtY}Xg-vg&p%5js#TyriXX)MB#-V5Fj;~aYuO_BJL8z0;S^-SP3O1p`5gSHk>oNB
zJx+5l(FWWq84j0UiF7sl%W1e;$mg&Hq~KfpSnKP;QUC^v6eu9b-acc@s72M%n9@f=
zk%~JGGd?N%_4+MMkvX;4DThlZh&vQ4Ocjw)#(Xpu3apjY_Ub*8@m0Bs7Z1xqii_z!
z)jhl$&VBQ(CGpv3hQBh$FP-IRy`l=VXxC7%`{k(!=d#Ez=0oP~=d;+UXNpCP-);NM
zebq*WggJP7^dc5na05bY$UJozaObBU2`<j2%Q<TRt^FI)_CVSj^7TpXbO4S5Rp<k=
zzzPKQufSV4x1e%B3|iY`UtVbHD@!D8*8afp;_`UdKPu?XtGu|HW&$nZd>_-S;PMQr
zSLhfrBml+VW~MIIa4ygar?Y40R?qYuwUlI>zs32<ys?TWTp#_*`Rj<gYpl}he;9Gc
zE#=}2A@H8!q<jFCZ(Ct$%!SXl{S=OOjp*mLbq+@K;2PCV_!Flct#2(e2DG?Bc=`=a
zsmYah%(;>qW97_M=YJT@SolAxV}l8fiKt@ELlF8k_K<=RWl@Cu2zRz)<zX~`5EX`y
z{kV;gkB&8Yi(-8{9pL__BI(y7^7U1G<{&h7@HGSU>%3z}sJ^GVQrYavs`I%;65Kg`
zt<k9M&*4I@niZvf-9G%&?&puiK6|L29t}9;8z%_4XD3Yq<f7+@PTN600BYv1pIB55
z36G2XJdGZAOA(aZrHhb(6P>;;;dCJDGGu>Ar8b{gu)hdeb)#GU$ArHmKzJkP>_x!J
zoabgAnX6#HRNWAmpe{S7KN6%*iG?pj7!B-9Sc9l-mM*M}M&|OrsQPq2dv<@DE<L`Y
zV0Fm>E6bTlP?umEiJnrYuAGoRSS1n<TVrN`&Iy;*p!oCj#SEynC$Dx(Yc38r!#m~e
zQs_du1XkL<-f?)9JsL#G-i0ZNBKS0gyn%R~ADi&|NPn)}cX7^Lc>K{O(|yd@YFgN?
z)3dK}(j1+nDkx&7T~z6==1EU?78NWrJhiTHk#gR1Z>my3Z%0rtq*5`P5NK%Tmzc%a
zZaBR^(^-f0X~7nme0f$yjuhO5+2UDMo-uhf|KZ>4vFKiC$Ku`4|9X>zbv%d3gtLG3
zphUfD>G{2R8u)^m`dT+4FO;9Gx3~IQ%d%W_MhM;}xUAK$NRBn5ZAP3JR8qXtief2t
z7cODfve<Fs#mtU+OOhy@G4lcL3vodR!PDbgNx8hv%A>9JeuiL*%x}V5RcsiODOOwq
z9}<7c)@O$*k0o2C>bbvd=>Pbo8Sjr^zk-wz;#D9>YW;1p8U6Zh-20`~;0AmtS`O<k
z*iFJ)lEUYb-NE%6n>k<7Rg-CLUiWYR${2h_;XW^A_^bYTZdA@ILJv)*WhtVAA`bG~
zPY}k8KSc7XhF^n4bU$Or^mC6(y1yY(r(l{JByw`jN<Rv2GK(Nue?!ZWkpS|LQhEC#
znVw13rIC8WVHYE+s*#o>T;U)$N;qGdF`Z=XBfb<q`T_$)nsaixp-@my(R+t5y5xnW
z6T<Zu<dx>S3fl;mjy%7S%Y-PCIdtlN%btgq1duo!yJY1QkxTs>rQ&fIG64H9`W$7P
zsCQ}ZvO}tY`AL86SS+iaJC-^vW~efjx@z1z)7-^$5=3r>#CKDvZS>3V_D{Arq|M|g
zX6cFKQ1^>Vn0+VYqcX^=#6DJQBm3u^9B&=V6dD{9(r)Xwm}n$3VVXQG(yu@x#L=^_
zoT)WFsWCo{otF!Xe<jZielI92e0|bTlJMbE8adrBjKV_;U!gMk&p*Og@_n@0gzgdE
zhhp{|azQ*^`Uf`g8gIQ=3Nq$5wFh{~ejrjcB$h7y>=LGEmq49kdj;_)6|{y8@j-PV
z+ZT6i3&Z0bfgI||-=e9L_DC*+>0HO$S@f`QHbDYAr<j?i`o5Yyqf{JSsDiNiF+Fz2
zXoR<qS9h61pI?3DqWFkQs<()MT{TFI3br=?fcKr+T<O?8%0+go4)Q#5rRR4S;xH){
zsFuTa{jq;mD6mMHAv66X134>zlV)J8|Md^qOrvw3IYQTZm;K}$Jz?O+ukYaABM?eK
z=LAZ{?z-6kWAvu8tQV=z+fHauSG;O%;k%_{vON^}#LI4H7Zrkt`y`65{a2I#2Rzj1
zy&@y2?3)YC_??p-YeCijBX%cq+*xSOpx2AdyM?<WRd)rL*nI(zfkR&lTc`2DQ&9G=
zd8t~3nt(06mV#^lVF;I2O`uQ)(XO@oC1P7L1!`)_-CVMK4E{?`QR)}}8mh@=G=^6{
zqkcym3U(lGk>hq(qM~~Cmv3;i7+X8s0K|;%Gnbzj&IPc}adhzd#Ji;grfVn4qrO!)
zKwoc6$rwbL<W{>Y?&s6zdf>k@fT*-{{^fm9op_hJ$BtoL;ERrLb`}W=KT!cp`+fBv
z(|6dhh2^LIJ-u(QZxuA0p!Vpe=o3rn3ppR@?Hr=%ESobUQh1Th;r}%*x_YBP5@+UK
zx$9EM&T}h~ne?t)Xm9dq$8mvHkb@Ij5*>Dh9P1p{(p*3<VJXp@#ia)d-56-Ov2zq;
zyIsw+FVu(HWI1v_o#5!gqq&7S^~)}kynClLM55^;TBwBrn@6FFwA+9|boPLzm*;59
z?3gbvhod_7L+9>-&_19<nx{4^dU$TZ<lWkwkG^1ZsnoG!VZ#KPJ;_#jL(}q&A>HBl
zOv_Gu;f+vuxpw3m*tZv%pg#@6y<a5XJNN47NQanCclAW2v-2x7#rh>a9w;d4F1rhB
z9ZT)rvO5--!^yE7yV!i>C&x}*#0|@nTjYO4$=eL7a4>5a6lZ%t=Ahhn94*Z7#AGtA
z6&g55jkB{0a<$Wr$-LQM0&8@>wHVhgC^%K(v4GDSFqkmlC?OGN08|TE4TYzF6*Y6$
zhHu^Ql(m)}bU=^#P=&pR`fGFiGZebkghuUHV%sYI`27Cj`~NHivJ(lD<5Y?mE{eA5
zl>aL+7tpol{~bD(bz^T?N`#BQ(iRc3ca!YOF)6++@8m~UlN=H&I1DPI1}v^?X0Qc5
z?L6&y8&dqi1GTk}uka9c02NX3M)a`FK52#ZJ&@eIsL028E*FcUPhFv%DnQGhO?`+7
zo7Jw6Lw7wYeVNgHr7AQVF}6o>Sc+$E=mvn~=4Nzb;k4?K-@S{iw#cai<k1kPcc?L*
zK2A}C$avf9W2psS+@4hmArI~ia!V#mcxnralX9S3d%9Rv45_aafT=DS4YYn^yT~dn
zr2hQgC13UQbcvstl%gl-sGmW&y5ShqD~ZIWGme@JKs^w&-}uZLXqg1Sb^<P1`8PzA
z%kzb+qGV2c2fp5<66}^P+Pit^*Q$+m?$Mr)IiG276!|f?ST6$}Gp=)?WZcW(B7D-6
zjt)lJZ*Ei<T8@<9<@~*s9}~ZnwAZ@S^rBa<Z~`wTdRJm<{0`h_vdxq_|2<uQL^MwB
zJqqS$U+p_O^REZ+btUF0Gb!6E?U!*kT5k$+fYj&uUGfuq6^xy)>o+0Un=D+LF7tNH
zQI){W<)epwX5VtGTP2suk!Rl7$vKl|E1ye~u~M@bzZ0D)c1A~;A87pLPmD3kb5XWy
z)u_m2{CF1i??79$$}U=Ii}aldF{e+f7Cp;#!xrls4hr9Ft|Rz;t0slJLS@qTR#gg-
zJc@S|BLAy=w;l&$JqF8<=&#>V2q0FIMV(_1P*iyQAm32pE0fpbzTZ>kBXg;Sz=H>0
z1Xnt<#>=S}xf^A_Y6aw33*ZG%oIRJ#Eho`WT6-_d2e6~PF~BOEnWRxRUy#LrBjh1K
zyh0U{H+ajOYEvj2KE#lb4rCDak4z|M@RzgvC>IshDSoNY2GP_fK5S5DMt;yD@Sq~n
zjA;9(!|2SE(C@SCtX8Y;@e;Vm;W21y_NF^}a==0c;i+tvR^np*Qr9f#&F)`jR?f;N
zt)jfW#y;7TlD?1F%lgr0OUOBUH=X?!rqn3fOT!#KGU{hgvl~pei$~7+<H<%Pfj~HA
zBRrd~PuqsNj|}KcNq|lB8*5Z&FsUhDtDqGp5w}-x56T$Rm5ozZg{BFUW^rgHj!(b(
z(L;=xy0O+B(+WH{QlYzX&y1Y#Z<S++kk(?Rd)9dIwGpU<c9s{)Wz)fJ-`50P7xI0M
zw#cD7I`AhW!e;z&02=qhbeZ%P6aJcIo*F8U%7t|JSTpP)_I|D2-D7>!rB!F(&S+tO
zx=sD%KA?BdCenedR)^?AUQAn9#GK&3=$s(qVaUv*O1*bs_5oh0y=d(gxg&0kDrlR?
zef_I&%6a^zslz0aNImHR)_7d^K+c;|DDo$kOFiFaKY-iyVpho@D-cn84e~?55+R6;
z%h+rG<G1sr7zZ?9hhD|0M~^)F)DiZ31#Km37+Cgktvc*?RZU+QQ?3Jj<@(MqsjYvp
zs7&>bO+#h~8Jb?D=uvoLA}2dx{LPk2-x_sQ<q4O^lAqaxaY2tH-aj~ES<5b8Y)hH<
zeE>0EhZo24>T@q3_30FEDuvUa6Iw)YG-&O75UD^-4Dhz?@5vfW1V~=AEGkdhlv*<>
zPqgleoy|P14V&4yA2L>l33fXuh=O7euE)9;G<8yj)~J#y@goxO*YHgb!bk}&43Yl#
zw0_`ybA)%LLOxFoCzXwP?Y9nU=gv{?x0n_pW`tn0`Gcvy1#qciqFTHMV?P-p!D9=R
z{R`@27+v~?_X|^iR&f9xno8*p8?rgSM_F~?8P;&9J0=H&kQiuzVWp*u7$p?&PP*0~
z=Z3GlQA#v_Hw?W6*)Jc{D;!EY9ux@5&Z-n&`oB&|Z38xDi-H7~ffi-`y;>BuDjN~n
zt9sN-3z5U|jXhJ-#M2*aS}j?krzu3na%@6{@V#SM5+Jvdj1Bu0TFW0*P_8!7R{Y{j
zuig1246~X(C*={ktL~UF-J4>O?qT>Ed>VXyIF{`2r;DSvU#U*YXc{LYV}ktK>Sne}
z7!T9Dl)OY22P!w>nZIhXT~515w#%PWbDY?Oh!0A?)w+H1lTGDFZzOujXm=Glb`Z~x
zSp*<JNr7x;;q3KKo^6bwgy`w!yp+nW;ZZhyu*wa(dW}yIQNaD+92RB9G^c9#XMh=7
z;Vi4^lTzdR*J#%eb55Y@sfWbN^v8D~^Vb4P^c>`UnxVQ8UGTxNCZ~#McRoEzy&DO2
zaCgo~LC7kGj>|=m-okE4EMiJbpb)GhkC~2DPc!AgKz{e~e3@Mr<44IKIB<gv^g`fA
z$n==4dCnlB{on-5EJjkKA8jp~YJJO%xSK4oui@i2_yCKU=I-z8{o3B}y9}R0U~7m@
zYrq4-*RV7sDGur5qg4HWRefhzQ%$sW5D^gs0VOB_fe<<Y>7hyQy|(}gNH3vxk**XW
zG)0<pLX*&obO;3LAR?erLKB0aG%4QWd+(3$`!(}SIp^f$nSIu*S$l6Hf9qNpJ+|?4
zA@QxARdrU2U?NQUq>jGe&TIs`YcuAAo`Y@CyJm0tLPN>UUx&=?HNC6#JXXzJ_?nQO
z?yEmF%xE#(E2P<!j)Y^ojzvJb(jDcDad&SOZfZA;yKvTBJ^rv4i#;MwW>8eYeup3G
z>NIQqf)pWwN^&qvN&%Bb$MTU@fXU%QGt03Tn8?{djzj%+?p6Efmje$5P{ULN)E~x|
z%f-H@Yu%Z@1FP@Z>ROBbPzl|#^FUJR<{-=`=N}crN>c0&dTr%o>Zh93<L;^UdLC67
z6<AdpjTvXn5hA+E@)3RIeg2fU*GqC5=YLz4X4bFyw@v=3srbRLF*z{Icb6&1f{2Dp
zBB-K-!II%d#p5&_+1Bcpu#NpEBjtg~GeR!@r@w`LdnLeI9@&_xu8JnTirSa`l@3==
z?tUVfe46+1je-9BL)K0Fg6QDD$4ToSFe0b9R*sZ|4{pwdKXspBALWf+I#@5yfx9AD
zejJ`;xC)Po>~sF;s+;{VslBz~P<^iL?R^@Z`O&j!y6eSQ&6ddV3wJd*&Nro%D3XbD
z;pn9--QxXd{lo00gg8xmKL=Znout>xDXTIcoEW#1o8N_*qGd3$f8tm?<f|pmf~LJc
zwtAw!LBp$A@4|iaxAn+jQ=rtJs+vcmJJ!~_?jmbFOoDQ1s+$TzC&efiYG$>VN+-si
zhp>fJh`q%ilyS$=RZc_T{D{ai)>Z0SO=m)JuX>bIvvzI3Ot>av<h87rf7ZPB%jYL$
znZ4=JqmjFM>s^Uu`BC|Cl9ft#DH-n#i7?(A`eYec`sMXD{tXp)^ar1tE1%WS@Rzk-
zdMS5A`UDKw;qn<Tpr+taZ=EbwTiDj1`i*5v$x@FviVYkR@=bZ;-j%&uHPVmz==^!a
z1ZjqwI{aS0&9!^kqVd*pd!DZxIURmKJ8Sv*jPcQR|L`vu&LKW#h%VF}H#j(;_IQ`-
zFX&7CLualj;}F^E1tI%ZelenpEQIwb#px!cYt_`f5VXWct8e}=)YTWw>YJJxm-{Fg
zrQYES@Wc7f5t#1DF@OI#vB%gl*@ppPv_jr0v?=-e^L7zH>XEOk9?vqjn<!SMpA78R
z1v`XBAZJ34-=F7oWuUn3a!ZDYtQHzXFYvRxW#s!to_mkR*gnU|ps|qrN^%KIv=~64
zUJgU4=o@zbr#Y9UzZX(SJ``wLB$FwLZ=hYzp%=bo?-)V-$i6TTmRc_JB8T-usnp2K
zqsNtbBaS>vLU*S4($JA8+GpL4UoIf^-vL-(#Vcqg3q#()Hs?}s@Ly9u(N%a5jY}S1
zLaet*l=)}jnNg0_9dSA4uAesdBW^v7DIi&bg=bq}xRJ^$Ojv91+i#!M9lWG7CEs`D
zjngp9X)!-CXo8o$_C2Kd+!s~*Qf0ua=|e(XuewsSwZhF~7VnSLPZN^9t-)-t-_PQ5
zW{gGeeNI^5tK43^om|1Hx;m9q|1B#Ol}nnIH!aIHcTeg;g&p=46I=TTOyh~11VhUz
z^J40*->1SuJ)><;KJA>CA(uD)rM{%&1J6k~Qff#M+p&vA+3_dwV&Sq<7rGDGgJr1I
zZ0q#iz71(|J`^$6)9{_SXS3>&s=6uHaMQkoW+({Cp>7o^vGTP{^?M?gR`1oQy7xnd
z;7$A)y1_(WLs?soTF~<o;yimOqR`s;yR3ZI4f3HKUm;&D1nOtY%cp<NwGxK_?T<x9
zP51khZi?Aa_MluB!S^4SCe~Ar?Q<kLiB&*`F}{h04my^f0h+>Wp~s&}+T~5$>uHYF
z{MoH}BQ|ab`aWupMHijHblks~%Az^N^<WIV!dE;_i;p`oSCDDX!!mZcJ2@9Zmk%nR
z3n!>&rX)seX0C9W*rGz0G;u2FoZzJB_8MY1`2AR03F*ltM)J?ql!rz85yn=`G;6yC
zVrOfZ8eC+G#JTk}=j+#nFO!mp&6YQAeWSTCU!!}Mvc$Qy(jjkJQvod=&7?Qs`+M=1
z@somhFm%eB1#(i`z=9Sw@b&j<d0L>89pJ>{@dFzYj;ai`choV8CWQn-%a)Fr;EqNr
zKa`o0?BM<SpGsq=)Q8@uFakk)z`Sh}x~CZEvz}%i$WXzaD1G!P|7Z6v967|0J@<<|
zYkC%PieC!l%trw&UY<ah?P&7?elEW>!L#A-`K043hQ|`0YPL>G2-=+sYJML_K4EUA
z<9#`BCZdMxwhs9w3F`;-AJXw*KBq?7HLoSt52~>W6MT0eT_$l_En<%y?g^)jE|rr<
z*Y`5N7*Z1t7}j&R7&gS-WFFl;uC2M}85*0@h`ZWU=a8np3VM1S8ZCP~%<N;j|DCHs
zJfYEXJgW%H*@exr41!XV?S<yZ_iR4PO`i&@CvJM$VTPi}A0{Bin6ve0XoKFJSXZ{Y
zUUG>D-i*_}lz!?AEHbA&FV7i?k-s1}MB3$KIjwMDD##a^Pp8NK7bFCBJOt0a5oiH2
z+<lxKfF9+3#0^lEqL{>rYt4phLhYUH14!L@ef4{e_nXF@W%@+VRkrsJxXaFjX1zZ-
zjjgsEB^Ri;mVf@d6S6y@f_N~-)WS$iG%;Vp&We}C#81whdw1S!*)na048MZDv}2ek
zt21u7r?wsXA#(8HB@MKDp}XumgafPApADE<{ApUPRN=9PzXmx%Ex4$%!A#4m%Jcr+
z&80x|O0LC%4eW^Mc2-F~VVk$(4)Rc~y%eS}L@+}aVjP}xGptt~U`9;32&Q41?KK?b
zyv@%m*bZh{G#k?$=(0}3N~Cn&6{}S0_p>Ps=1reup!^g>g*w<&1GK0Wk=>$k_ZfB|
z>(oAUyM?51eAJI-g~2J+fT2K*B=+66s{jSa#0F<A5xviFqG+uzd8&xa*Ps&Kbua9`
zPKmvh?a{7H3J2K5&I&GfM`dTO+cL;o`+oAs7+_5DESNex6=m;F26&KOyBlcCafoLT
zl$qSOJ27C6(beC#&xz7U(*bm&zFr0dIg9dBVpQn?+!zNb0;r9_PXCUXcW$E`oG^66
z1dW{=*JuO86?K6QKaLfU1_~dgCU!N+S00(1N)m5ZKKOtfVM4)ZvnH@^cyd$Z0htAP
zPU~pAPt(S@qP;7P8c*ev81x|!H3Y?p?PSI_b-#!F(oT7|nS*|Hn%tb<AWd-pV{f|j
zdszwNft5IpBp(6<20sx#UuBLD+Lpy04UcA-=C|5~X_-Q%aWKht=b31O^s67Ob%CgY
zo`0%llQk-xmp%NUJca2lk`$<?QES5j)+9HjAEQP{{fYq^84bfsn3ThVcVJ^_ivn}s
zeciZLozl|}=}kC=ui)N~bGes~a?#@TNd}EZpK!HhOy7Z*bt$~Q?*97Gu21FiR`Q*V
z+H7|UtsL^l?^W0Ij38ryG^EeQrTCAU%3Ruv<{#9oR7FY_NUpai-IvSz3p#w-Cf3O}
zJYO^lq|)^ve%JY&-&EUUe<{fJDCqin0=c6JV<U_U{De?j=mA^XYdpDq_<>$D^4ez3
z#{$DuaXzOEfKc*N5ANToN!d~jdRl%WASy$f8lkzZnpaC`vwi=egDBdWp+iii;KKTa
z&lbIK-;&aryO)drHZ8STMMc~`P(NkxwStx2zo0u^T6S~C?N#BYnUjlhKVDm@LA76|
zC)hoQT)!zP*)uLvdtb$H$MTiyy~#DI<RJ32-f?hH@!^dz3$Hr@twy+?gfX;g(}&Zj
z09%D4gVm2bN=E5HX1rZCd3$act8n)p@CTTQGE41-<2xQ(9Tqm|!>3(HOydu+(x0<a
zjd#mmuYIz67!xHC5JGju+cy>y(&RoHA~7ZFp@FnqY?3*WPS>t)Sq!sTrz6cm`%EHp
zqtg~CdCD#fv3W+ey4$Zl!Q3D7#=FnAby{0+rGB;lR_*l}a5$eRz1N;(ro=yIDz#<*
zLL#0HNjjv9Aju`ZhllGz{#Y-Z`<<F9=anvC2wQs|-y<+dFZ+Y6-+c95)enKXnsfK=
zbWsPV6&|Y67#D`bcyN={aDNVgiT+mom+R!!4Ru+gdm*gX05RwP3Oe8YHZArk>F>Ie
zuuQnFJ={l(wSBf&Z7sN7r+DsJt$g=&d4yEW+Kd3}MPL<==t+g>&yhixa^V#VCRJUM
zodD7i>&tvyEzilEt}4}?du~6VK^L7^^<OEH6Auc8&wDHz_wJ3}2OoR^0uRXfOQhJ`
z->B*0nlamJ7>|h?II=9MF0Dx}AXC~DMoH4Fx-8!37tort^4BeyJ^Was7gCkK{N$1S
zkBPh?uF(OjKH@HfYh^uPyS_5?Ov@tA)7QnWCa1dP+q3;RQR$0Kr|eO_tgU2^@R=5T
zvW^B+N5$yNcFxZr$5ljt{IBj0@XKPOqQMHB44>!W^m|<vX1O{}ihjPYO{WEqL!!(4
z&OahlimnTo{OsH7FqslkJV{`pYPsv#FCcx#P2NTJp<1c4EAdC%9;&j;p~<8vnO=6>
zS3$rfAjn)w)Xsks-DNvx)9zYz*z9H^R+$lTrtPD<fP}W{$uURXWe(Jv&Tn>27A)W1
z{iTodb`+6qZFpe+sduE@KG$a(JAYYIvVU6Tda$^CK9zkTV)E_a%kgIS{7J);!*Sj-
z=F7OLk~*;rzre_oH%e3k%JWfEaY^R_GWIJ>?(NihXClth$md0e0*?N8^=CP68(w{$
zU-KSHen%5_U@PV->r~+%_crR-`+lHkY*}8?RdIgEkGv5sA2Y|YGtEV4W3%+EKXCB;
z%J=ch<hsDKa_Mky?DnA)f7^kc@Zv?w%=|akiSoI%{_88D$F*JYLWktKBC4)05~=)E
zgZi&d%Jz^;39H}5=_}mVt})fPQeSnLsoFYM*VUfePicQ^pwGvOaa=eQt?{SY9erwj
zQ!74EkmleE&g)7+{C)agrYmyB@fzKJG-(_o1V{Jj)L)z-brd%+jtC=S0I#_4cLyE!
zww(%b?L%$%R~xC|H-Z_DP1H3O7@x-Uv~qmSVdK&_dB8?YTslZ)xR~G#A3MbqsmO$D
zs3bKI!_D50@3e;GW>ou`ui^7q({Qohew+fhDy``R>Rq*e)mnvAB<oLMpM(_>L;Mpc
zu3jn-8hp!Jar51{d2n^I?8t{p7=`N5llO9E<{YKuI(}}I-Ahd-M`h$j!j(}HRFaL?
zT3>RVGqiB5USFC%Z(Gbv@}FGW&om5KJtw}UGKiZp_MG1jH=}h8sZR0WH6=z>6+9m_
zqyCBB+=patboirip2q@B7d|-)GO;>!+HQE~XhC5;HUu^-^V+bH6`P^9stWp)V(g74
zkP7^U?~^Uf90yBb)L6{XhkE`@bN61&;YJ7L-dnHu1G~G$*q`!hq!pbO;G@OW#N;P7
z5A~g7uyHt*7M&K+bm<(x-`LWJ#t}IatSKB-Y_I-xAmj6dj+T+(CS`1q&?W=Tizf~s
z^4!!$3?^tTB{=A7!rBW}(Pz1G@?)23578bk&I}xC@92Xza>?IqQiGz;dn}S4X<F|6
zxXGbEs^FKLL@Oaf%g~V^0jPc%06{FGo7OiFsmAzm=!WF>x8v~1<BesQ>ZecV_Fk!;
z5pGnQl9B4YIQS^*p9R9}>Cvn5QW?`fC0M=l1utP5Qx8cK^CkK|j2iOF;=-p{)>2$Q
zBn@5MvACz02vf8s#tKZ_HN3!TD&?w)(J4u`;G_0<92XrbR>@S7TmtnAJ1}Mp0XC~!
z03kGC0zuN9bi9QxgG3U;-U{wK8&?`!W@XefhMhtt!J8NseqVKa%IDXE>akbOZ*v@~
zr-oU*<@zme6aO4^H^La~ueI81Fi=EF*&YKA2xeW~ihs_o0QQqLM)}FF5hx<`ALJrw
z#O~rP0`q239M_$|eh5e^*vbFuI)^$tpm1BD@K)3_j+EoyjZef}+5LCOc{`3pRX9G8
ziIt0-SF&M@Ek@4~BA+2+u9W&LW^Im!A^0sE>bM$kT1df#p(BtDxW}~m$X`{T5L;cn
zHh3ikngOzQ@a44-ykX&OkfA@78t3z%eOSp<js0C3x>}8m6ja5&!0}<m^`&3LDbzpl
zInlJ(H*du)7HevCwGBY9uH4Q$n6Ez!XS76mCaB!ulBZYyf;{#+v8srdF1>DX*X2xy
zA7=}Sxr+#tiPp>*&tLQ{F!@Xka@27Miyw2HlC^xl0HYesoi|?LjE<G!M_AOZ%h9NK
zO}kapW6N&*v0(MEe|1t8N@>MO0%04l%R7+RF`cR2`#I{C&$vBi{4#mz_6LYw_RzHe
zqS@4m9%z#A?O+0}H-LW1S(`23H5KM%uPTYl4xF8?j!1Ns9xQFqC@(LfYf0fQqZahu
zQokSnupqW%*+cB3<+jH>Bb8B~_sR#B0hYqLk_xdJfPuij5}w{T*9ltjb7E@hIe=F1
z#f4;A2rQZ;CUb~rsD5H1-MQ*{l>2itFE5G3&LP;E8rt{!M2P2G3vB-VX}6}V)BSHt
z5=w7zZ#2XS&BtN$Upm5KoLx6&mI}Nopr5KACHJI#*nJo1hHA3LaN9iiA@lQKxg5=_
zI-Apaxp@_hpGRFAqCnwB+@*Fh=WZF;Y9X2Odm%r(S>sQyx<BnjWpVL`&0)`Wf@#K5
zI+L|nIUg)?q{p&r-!bGBcmSwBc^(5H%lUji9p0#N;HgQ+xAO;BlttY`oi!7K)7#AN
z>sM@dziUUUHbx2Di2(uWUJr8|swnCR<59DKcb=%})83G_(WR&4XTrh}-zDv&i^+J(
zi-gSb5lU8LjIwmkRB0SQlLk>4G{$y?<fJinzkx7Z4@Q7I(u{yBd?eu1k#QuA!OX;b
zM1X9c@2m?FqUzJ$Tg9I2l)PqeEX+>D4=V^}#=g+Stc%!_@(v7(I<cpv;Fv5U?0I*M
zs6gW8lI49Z%&JmVw-ZF4SV$6IapFu~c&KGOF2{!r1Z$_|25O;ATOak@GNCshP-0|C
z)-~9B(`pt9Nj_0=$hrHdhi$9c@-~l@$j-p-N|#6(U(@5giB_*4@*Pu8Goy1a#Zpz!
z2{bEv1erv47E{YJM4uPa+^7i5@bCdOa$Jvj@h*Utg4~b9DJetYi^(Id7==y9Bw4-;
zk04i3Ei(ZO9wTLeBp_H3j6R@1@E8~zlk$+ewab}gWs!%5jRO(-9AtisydZo#Kh#(~
z6-1q<lAd(AE!m3JKIB`9&?k%Q=I;N)`}Ra;isH&uYqxVwaTOhGF!w-#7{`E(d%^%F
zG8;HHB1qGQHw5#H6?i(@$8;Gqd-0m`3bS0EPlaBZ%4mkh%I)JsXYPPwc9<V#s(sPl
z?kwtMUjbY)B0@2bwNqTCx@C>sT^KBVOurZNK592K-j;sGvTPJoIdXZI99B9Yj1@K1
z&=U0*LeCF<`=*!+!|xVw-^n`NaxE*WNNP5>G5=<GpIUXaW^&6V+@#fVhyRzFo|ry=
zZQ8dqM!S&+a*;{ul4P7%t7}2SO|o_zOebA`b__}H+p9m6u+HiOfeK8_x#9YMZ6@Z!
zTy8)4Xg4!vKfK+rQTfQ2^Ci=Y6Q(kcX&I6%5DKx}NQ=7uDVku<Tf7UFEk-iBe8zNE
z9p3DF3m-J?F$1eW9K!Ww2Ow{K(ImO%yp%1Ps|%qCY3<M1VwZgiJKRh6e;W)EK=;AQ
z@PIAKcQGA2pm8{c5}Q3#{L=mQgE+ukU(k)d1cKRc2#rQ6B4=3zC&p+P!~xTtnoS_5
zqucdNCyDK6)JJAucZr1^6$Xrs3rrcXVam=5_^^B*d<Wc$PJH(scgku{*&a)_?30C@
z<zBroyxI@Pvv6=6DI(Lb%F$f4fr{1$f8Yy2!2@z!zCjm4paCn5Q3Qx<0-M|5-FRsN
zg|{>}Tqaeh6&t7z_+c(Sj%kgFg!AXkI!Ob@Uhx{Oq`_eGmR7@*0<;~(e`qtVd4>4G
z(ui^EXjx9e-y~=E>eg~QmYX(!UEYk1H%XURtGHY9Y6QB~t+n7>IBo1%dNhzOvXpm*
zLagtluVqiM|4=G-YpN-$ZA;B=JD?^fd7fygJ`qNnIaFg=boL~&->u5|5#ngwi{5t)
zTO&5FzwDX1^!<A->{-vy2IQL8IV%uXC%&ou{_k@sr>G@_fMH!gi|swHa<jIl37CpM
zar<IqDqWfu3y}KZ>1iBQl=P!V7l;z<VzrDhU9;J!XxHv|ApO_AW6*RcNQnHTMrkHJ
z{G;J)`=QTZSB6-wP@}L$t{VHwFv$cX7Zm@=UoPJ>uW`hnIEcH<Y4A9V^mg8X)P2_T
z`TE}Kxb|DClKXNhcm2=5!e$zFejFXX*XWLjbJe^l>ofcDb?r^Ni(ffbxfDNfk`KOq
z0Y!R8AWg^ov!XP~XNHHr(l7M)$O}N58Q8Ox7R!s{JQUbk&FVXCj)JV{|ANj6A5u&I
z`sCT>R3UL;^teOI?rn#-y6r7Af)eyf2rYyhMUZ=wXqnaE`cUg1odz3ow$1!Cv|2nr
zcAhWrv<jT%F)2)a67UnVZMZ0g?l`!k-K~YZ@8$<FXVJ`QY;!g0_4iqOPo;Ru#^*Zv
zgx=Y>C@;#God5YcZ)od_<SV_fK-oUy<Eo3JJw4b)-LXJ`q(y@zjf|-Off;%>)Zpz{
z-<K3dR~-`%e9KP3_vziLK^^W)(*8K5hU8{N2T*lwb#wE4fG?{j&xUiDvQzfyrPkHW
zNT1Hzt1Da#MzB#{#{&Ob*&yC0M!D>3gmx%9Y@cT@Hg+CO|JMK3#3fJFUr-bw9PNki
z|NdO0NbEY`oBdCiTjO(V+hZ6il2S}zk7f;lvwdK^A!PVDgq^$y<SeN=GX;DZ#4|vX
zMkE?!jNBwWhpN;6OHp%w4%8q66cbn+AMFUi(Cu9=E<ip<*g&%y2bZe0;xL6~>IjQE
z78l?fnB|G}{BM|z7KF2fD)7z4%tmDLGA{<3-Tk%cJ;vl78Kj-{5DUlkOq9MHlz-6}
z_OljY_3JV*5`O6`^CHon|E_SMtQieH|KW&y>dzmiW#qgo!=Klw-Z2xHtgD)UDv6zB
zu^XDCj}@pP{<STr&OZXlAQ%HiNQR?RN&7pCRu9mS@<co+$VX1_Myn5?o*`Koj_xcW
zcTYfoB&G5B9I1P}LH|tr0^mx-Asd?52MP+zBntAd4Y#I}N_JM#;EZe8-w)`Mp8T3q
zPj53hNl?C@aUIJcJ4GRbc{{*EqdTb5%R@{A2;8&yTJZbXUCLE2${}}NopdOAKNa>E
z9$I{!!Rf_Y*Rfu4OdVWF5{%v(vx+^1QqqkCniZzEX^t4Yj{I%G2<jV{d6=!z?i_v-
zBera`ElOye*o}OWNu)|)4R*xUJxgD)N}(HpoAWu8a`(wh`z7~J<smt9x?U}<+P^OC
zlvNE4_ioQ`Jj4!qHpvA)$#VMEEXhRq*@n0PCEYxq=a$Rck);WJ-j04=?N;ntxsklG
z-*)Cs<4qwcDed56hFOimkk8BxEkIMf+iLG#<yl{|Ot}-{X<KI!q1Jxn^%r#WUFf62
zFoR7(z}juJODiDqeqZX<eAqU^Y$Q8WRJ&pb@;Bal{fRKJs)3uuh-p(+SX|J~AAdI@
ze*CWOJ%wJ=c6wdk6?70}{qYwl#bU^J!S~H_SM!XOSUW)rCZ<ijf<|1U)U*&HB$;Xq
zmYh$moYq&P`|onDe)iiduKPBRiI>gdEq-ijShIj1m_<0+;j#H6VMuWPkMV8Tva!5N
z#E#_t9DkcafT8`}L4Y6())K@={&<%<1a?$o5Z78gPi-3pjqDV5%cO#T<Ei;MNF|4a
z;uHPIhPBX)eY<S%@hwTLP;p|r5>*GUWIHU|9v!tyd=@|W6)10G&ns59ih7(FZUZ|2
z_?BkW<#Q@w{cL*&8S@1o>ta6~H==-ID&3FJq<nErBoUH<3eZ}`!5~O<VSQ{*#VU|J
z31ac7L|x`k(K<K-wwwXJ5=klhA_cxBY?j#00r<42(e6Z|#r2U>Y_Yj@VA|nAE~biA
zVru^?qf**3wNK%ZA)|fxlxV8qQ1Dd?R!&mVUsF;N)bCB6<jvgssf$NlIoJJ~(?Q>}
zQ(rHAU|Jk;Vp)$?)dUBdJq{wx864POwtBvnZ~95t)H8<<V3%BBqez(O$uZ+hD>RLg
ztvcK)g`jvAo|k#WA|A*k(kVk)OD=P233bq>c@mVUs%9;yR(ceTESr{PK%AwVd8Y5A
zpZ(@6+eyjuIz&r)7$h!<QB_j)Cuvi=O>7A1IgWefpvz5M>HYm!W>F2F?S0XVB1!qD
zC=KB#2__gSE=dR^4Jxf&`||}FB^9n*%Qq8<6rA`?E`DV15U}{mq$B`ub6z6*4GwkS
z|Lj>SF~&s}bag^8h&j^7YQ$ySTM}W#`Lf!+Jby+`7Bj?<*Iwh({`$9Ax<TiyM<~w~
zJ&Eq?>!%OX5M2%><ct&k>`EEANtJHLlIs;J0Tylvh~>xr4I@*Q(POoBm-JaGCBMvT
zT=kCNmr@a<n7^PHg4dbFUD?+o3Oflbm3AwPlGeVtj6Bh3eM#m2pmKCZVJMUw19Fx%
zh@ORANxBW1^iD42hCp59Z@Or^p%qkbfV{as?{YL2lYuPUE@KgB-ejI+lzd`!`hkvn
zd3(_Uy(J)3<a!Kzvk#JV2>Ncr+BA|Xv0&xao$@7o#e#H(qO!SxvqmP{iOihcszFrh
zR#5Pc5ou;X8<X|3tb6MoKDG0~+SGlZP-IHQ=RMxmfbD0)|7;wZv_%yX$xqHstxm1{
z|5W}%xYF&c>!6=|+|koY8S$*-@jNtr>OQIKpi4n?{zD!ao7?e)<m9I+gTK^QPkCq#
zBAEw&8M36~2%#_Wpr_ziq96s^_az08bYkBzIHndzp?ixodcslWk=g1E%1N>mIehp;
zPR&qg<*`hmN*ed~%suZwlceZM6(aQtC+UZ1$mCh1KgBiq;v_CRYln^lGnb7a3G)E;
zJFlEre`%-H&*&uG`MtN$ZMonq+N6__C0w7Wmt(p~ohk{M4`yWi6Ku<^U@!`E*sdx`
zitiU$4O%~0vRpY}bD!M#@=_R|dBi>El2r$eTfT1?Ug$r@<oBj1uCm@#&N&&X012ic
z8z*g{xy6-rveT+QH^05CbDWKX2{JK@*gLzGJW=rVoq<9fEAX(YS9(^qvP$i*S*%y(
z9ICoQNIIc**M{de<2r=LB&(3pc`SFT=e<2d8*{7=lDJOM9$c>7o@Wn@i1)no-H$0{
zOtMa2a~KX$QX=djonhI-m#sUz(k&HrqVzaE3(etje%6<MU^-!`NK2YgW`+U-?`m2p
zUbkc&Y2?Y9+qG`UUm)VU<TyzdM?pcrH`{$4WmY{<-#Rrk?Y*@vEc3#Y*|-B;?>mC_
zE-(<{Al6ThrjMa4rohnS@e#*ioAV5kFM$Rmxe>-FuXck#>xxx8$R*%L)a8h^rsP>h
zoMcC>{(dPK0LEA)MkE2SnJ3+15OaC*!I^&w7qTz<*_)n~pg!V1$c_82Elwm6nv()Q
zM~}8w2;!Ba;a}Mld~6v2gB1fB=l^9exXj;yiQ27r$7nlQ0sqQO*IM6f*4oY?v=sIh
z&aD-xG?+mp2XC`k-N`^kXRZ?4<cCm48-*QjHCHK@!T}<VqA!X#D3}PDZ*3<~xx^31
z>sv=B%FNPd#L))a1~lTxWd$e&$Pt&yOWDpk4jkV6v(2&JG?w}Ee$rl1GwvHAT~=ez
z9VFqX^z!E*4SGlWV6l`A;YhD5Rmra2jI(p#8oI<JBGI|H729i~A2NJ=OpDX(q3O)P
zX`{?RlcG`s=ZH6=?78olJwPn>!k0cK3<n@Z{FI28{5?bC(D!pM6dbcPHI2SvHPW&1
z(rrqQ>wnMbmQ|#@O+h60E>KET+qv(RzV9J#F=JfA9cMM+unRRQ;5;!C*9fZF{^dkg
zj{{55?*oQ|o9!n>-T}EfZeEzI%_4?PZ(>-&K|4I<cTU-vr^m<d<~!<65Pj7l0?|ti
zazI`*(;sA0^@8xzuYSWVZ~?aSRq+N~H|?#6Bw)pApVk9Ts~2V_fFsAK_neevi{_FJ
zvr<g`Lrxy6k^bSWFaagN()@=11p)b$cDh#(N=Bul#koJ7Uh)?QB#ama_^|pU+-{Vw
zlky#kO1S+llpT^vN}@`mTo?j%*@|SOrfn<*&JAdkL6iR)GH4VNZiBu7WC687(=bVm
zkC5TB9a^z}mZw*pObF;Qy0;z)cyzJc5L%A|Y*i!+HDJ7M*!h4$t&<=e<WOpP8fsNY
zDkMqT0rYeI(HBF~w11WeN_|ij@1BGJ$w=evd}<;8TN45dn~%^QH_6I!8hJ2a(3r6R
zOv_OCKb)6F&Oy#j16=R`z<O%n5imFd^o_ta!nPB1=}dC25}Hs-?)VSdJq7;<?RJ7v
zNrO7;P{Eq3d`l`I>6a5b?{NgKggVr1&=*0zB^$%m7ss^nH&+ijkp#ZP>sr`IrUB!4
zj{P8g+Zdty1BGpTFE<Li@fx7Xa~7BCZ1Vg&ihF!x>CB3Djztwi5@zg}gLnLI!e<r@
zqQ^)Z>^z=Gt!Mypr{G6qrc3k5wwW9w7Fk)<X=8>t<zeVbsfx5Vll6*`jpE1HftgKA
zDM#D*7E(N<1aWHMel2_5k-q~EB2fDPtF%Q7U@lvKO6c2WfWF88d(t!lcQ=zDc;zOj
z=MZov;!#=7K%E*eP7^D%u-StJIVm#!z#8-0iRqvKsL)|~D){)R!C*$M%$-dHTbyky
z*<vAl0zfEq%yGyCHHP5QefxEQDpjIMWXdF4Mvop8CtfFsT{s1RPu9Ny0S1M42WN^>
z-~jBB;$AxkP*ccTE({ACFNyVj7CV>;v5?nO22N=obRsiQr0=xgi;v$AJQxEBbrhxW
z`)I8a3t0wvnUhwTjp_5%wc<HskZ9&4IHHekWrPOo4^W<4N=y^HK`;GCJ+%fGq|24+
zBQvbc7X-@jDeOk-*P;+bt3%r!HcYvdZ$E8FCcp571Y^cFUO__m^f|5U@xBhcZ)_Cp
zffwax!6zuLy9MYbFv$@ThVz^GCL_<hmToAwEtss~SudC7p2ucM&L=i}D2cD6#^+E<
zg!64D9~<c>7QDa7%=hbul)hHU0cd+2vpVlPC6$~JDD;KGX9}v<b98+5{1l#8B6iqZ
zhSLLu8E9R7loHc=WhrR4vCfF--!jn=G1M|Q_aayuJF7rh0I{R;-hY;~*L7wmSoB>I
zOgZzj!u7YW4;~$m_sg#dpI-YHbYrPK!_cj=#&(OWeNU9%tLGO{=tt6>kG~5lX2k+3
zT%P1`yFN;;Z<lD5;GlAB+W?Edr}cd|jbs#o$w4!&AcC#-ipAgXId621vu8DS4o!cf
zh%Ih;9C~DY#v`js&AsnpNf@sAivH?l{Pjo=VvRKp&GEv7)VFBvgqrZN*iuEA4O_}{
zM1k&Z2<e_@#n<>=Bz8aDX|FrcMV`&&P^$RnxJ9qL+%tag8u|(Zd2o){4Gx>1_}r&D
zS|o@S-TjU<_zPM_I2?886kO}_9fQFgU22+_O+q3{LlR_soY(CLxA;a!H`TaVy%X*b
z)<JfM*Pq$g$X~m`>eJa7c^y(r790#><nF~E9Du|#?CJzrNy&g2!z7W#)c=hWGRsaS
zX&Ua&28wv7+y7Vm8*z0W`rkli!Yv=*8m#M&Mn{K1(P`v@f~;4lm0AAX1@T{3zToxf
z`RvrI@jPn>Kr08Z4HV1)rW}LE)I)$WA4U|U933WIvH`bt0<&pQK{l(v9d6kaCvE@}
zWCwp4;0VCuYT3^4QUVWh6<o3U6X;;oNZE?{VwRoSBN(nwu+!OD^y-XcFMW=(6u8fu
ztK7prok;A#fpR2V-@(R4{W^S^hUNR{@D<7o6!3emuN}O{b&C<!U-iOm;6T3v>bIhG
z2=D;c;Rd+m>}>QE$@&qBfIu4?rMnP|jbdPl5(u=Z$T@|8MPR<&zCHT*7Vw;;gHvh@
z2th&aXGDG<edKAKAcx43`9@(TVV#ODq+)dfxCaSD4RZ{31X_+65EbLVHRW00Tb<Yc
zy+~`--q6JMg9CfzeZTe6a^N39D^W_@OBdb6i4h2*B#kSKz-y>hqH^N?ta)%yPZmF*
z@u`@aZxsJ2QUO196J|10%X^O-DW*)MN>1KbHOtPrxRx(fW6DqGSIS-f%Y{zMH=s2{
zsp7}Se(&ST&CKN0FxvD~8Tt<=ma4j_k>KFa`|d&4UPkGGSLii0K70N#{RfiKyt0(W
zw;N5&Zm7dS_W~yvGt!eJ5}cl9na!}bFY76PsvJNK3|$iz2i^PlED{8XIyl$`VniO<
z(y$bvy91x5FRm<Qahdw?&QFh35v6=y&~2E?a|$FmsKF_usjckJ@$)r-Z-&xpbMBdW
z%a%u(JCal5_>&Xl%(Ang&-={T4^JFN#j;Q)P4MpUmd75Y&J8e}X-H;Z=}fY_Un>5*
zI~o>wb95;<ms+Wd!E1I;ttQ~1=Ao>k*q72@1`B+SGVWfKCw9S5QdDjruogOcTO+6i
e`bEAsjSh?$nJzA731Bca$DHU~Na^g~h5rF(8_Q_`

literal 0
HcmV?d00001

diff --git a/doc/tips/what_to_do_when_a_repository_is_corrupted.mdwn b/doc/tips/what_to_do_when_a_repository_is_corrupted.mdwn
new file mode 100644
index 0000000000..78f4977a27
--- /dev/null
+++ b/doc/tips/what_to_do_when_a_repository_is_corrupted.mdwn
@@ -0,0 +1,27 @@
+A git-annex repository on a removable USB drive is great, until the cable
+falls out at the wrong time and git's repository gets trashed. The way
+git checksums everything and the poor quality of USB media makes this
+perhaps more likely than you would expect. If this happens to you,
+here's a way to recover that makes the most of whatever data is left
+on the drive.
+
+* First, run `git fsck`. If it does not report any problems, your data
+  is fine, and you don't need to proceed further.
+* So `git fsck` says the git repository is corrupted. But probably the data
+  git-annex stored is fine. Your first step is to clone another copy
+  of the git repository from somewhere else. Let's call this clone
+  "$good", and the corrupted repository "$bad".
+* Preserve your git configuration changes, and the `annex.uuid` setting:
+  `mv $bad/.git/config $good/.git/config`
+* Move annexed data into the new repository: `mkdir $good/.git/annex; mv
+  $bad/.git/annex/objects $good/.git/annex/objects`
+* Reinitalize git-annex: `cd $good; git annex init`
+* Check for any problems with the annexed data: `cd $good; git annex fsck`
+* Now you can remove the corrupted repository, the new one is ready to use.
+
+Alternatively, recent versions of git-annex have a `git annex repair`
+command that uses <http://git-repair.branchable.com/> to repair a
+repository in-place. The git-annex assistant will detect most corruptions
+and offer to run the repair for you automatically.
+
+--[[Joey]]
diff --git a/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_1_c3543190eae2af594f3e050057e80db6._comment b/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_1_c3543190eae2af594f3e050057e80db6._comment
new file mode 100644
index 0000000000..3954bef0d9
--- /dev/null
+++ b/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_1_c3543190eae2af594f3e050057e80db6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnq-RfkVpFN15SWvQ2lpSGAi0XpNQuLxKM"
+ nickname="Yuval"
+ subject="Automation"
+ date="2014-04-27T11:34:44Z"
+ content="""
+Could this step be automated?
+"""]]
diff --git a/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_2_025178c2b11affe2d42a87544b897dc8._comment b/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_2_025178c2b11affe2d42a87544b897dc8._comment
new file mode 100644
index 0000000000..beb177d001
--- /dev/null
+++ b/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_2_025178c2b11affe2d42a87544b897dc8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmZilYULa6CDEGfuagoDlesyakBgnf-dF8"
+ nickname="Maarten"
+ subject="comment 2"
+ date="2014-05-23T23:50:58Z"
+ content="""
+What if the drive is destroyed?  How would I re-initialize a new drive to act as a substitute for the remote that was just lost?
+"""]]
diff --git a/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_3_9a6bae9c0326ecc7610f5415db20f49e._comment b/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_3_9a6bae9c0326ecc7610f5415db20f49e._comment
new file mode 100644
index 0000000000..870d7b93fe
--- /dev/null
+++ b/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_3_9a6bae9c0326ecc7610f5415db20f49e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.36"
+ subject="comment 3"
+ date="2014-05-24T18:29:03Z"
+ content="""
+@Maarten git clone from one of the other clones of the repository to the new drive. Also, recent versions of git-annex have a `git annex reinit` command that can be used to easily initialize a repository with the same settings as a repository that was lost. 
+"""]]
diff --git a/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_4_d4178d99179e8761162c74673042e28a._comment b/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_4_d4178d99179e8761162c74673042e28a._comment
new file mode 100644
index 0000000000..0f09dfabab
--- /dev/null
+++ b/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_4_d4178d99179e8761162c74673042e28a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="bjornw@6a7d7d0413efc7ed3bb44922586f040bb768b71c"
+ nickname="bjornw"
+ avatar="http://cdn.libravatar.org/avatar/676a7c403af0627c9bde84ee1ab3975c"
+ subject="Thanks!"
+ date="2021-10-05T21:09:44Z"
+ content="""
+This worked like a charm.
+"""]]
diff --git a/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_5_9b3738aa678015a58f30a22baa2012df._comment b/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_5_9b3738aa678015a58f30a22baa2012df._comment
new file mode 100644
index 0000000000..b951df26c3
--- /dev/null
+++ b/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_5_9b3738aa678015a58f30a22baa2012df._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="sng@353ca358075d9aa328f60a5439a3cee10f8301fe"
+ nickname="sng"
+ avatar="http://cdn.libravatar.org/avatar/d64f4854965b2b1c3ecafee4b2a66fac"
+ subject="corrupted bare repo"
+ date="2023-11-29T15:34:30Z"
+ content="""
+I've tried following these steps with a bare repo that became corrupted somehow, but at the cloning another repo step I'm stuck... how do I clone a repo when the bare repo is the one corrupted? (if it matters, this is a very large repo of photo files)
+"""]]
diff --git a/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_6_0e3224af10362a10aa1c8786423960a9._comment b/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_6_0e3224af10362a10aa1c8786423960a9._comment
new file mode 100644
index 0000000000..d31da3d014
--- /dev/null
+++ b/doc/tips/what_to_do_when_a_repository_is_corrupted/comment_6_0e3224af10362a10aa1c8786423960a9._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-11-29T16:44:35Z"
+ content="""
+@sng you can clone any git repository, it does not need to be a bare one.
+"""]]
diff --git a/doc/tips/what_to_do_when_you_lose_a_repository.mdwn b/doc/tips/what_to_do_when_you_lose_a_repository.mdwn
new file mode 100644
index 0000000000..363eeea4e0
--- /dev/null
+++ b/doc/tips/what_to_do_when_you_lose_a_repository.mdwn
@@ -0,0 +1,19 @@
+So you lost a thumb drive containing a git-annex repository. Or a hard
+drive died or some other misfortune has befallen your data.
+
+Unless you configured backups, git-annex can't get your data back. But it
+can help you deal with the loss.
+
+Go somewhere that knows about the lost repository, and mark it as
+dead:
+
+	git annex dead usbdrive
+
+This retains the [[location_tracking]] information for the repository,
+but avoids trying to access it, or list it as a location where files
+are present.
+
+If you later found the drive, you could let git-annex know it's found
+like so:
+
+	git annex semitrust usbdrive
diff --git a/doc/tips/what_to_do_when_you_lose_a_repository/comment_1_cf19b8dc304dc37c26717174c4a98aa4._comment b/doc/tips/what_to_do_when_you_lose_a_repository/comment_1_cf19b8dc304dc37c26717174c4a98aa4._comment
new file mode 100644
index 0000000000..a7fce26ef8
--- /dev/null
+++ b/doc/tips/what_to_do_when_you_lose_a_repository/comment_1_cf19b8dc304dc37c26717174c4a98aa4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://dlaxalde.myopenid.com/"
+ nickname="dl"
+ subject="comment 1"
+ date="2012-05-31T14:36:33Z"
+ content="""
+Is there a way to have git-annex completely ignore a repository? I see that
+the `dead` command adds the uuid of the repository to `trust.log` but does
+not change `uuid.log`. Is it enough to remove the corresponding line in
+`uuid.log` and `trust.log`?
+"""]]
diff --git a/doc/tips/what_to_do_when_you_lose_a_repository/comment_3_fa9ca81668f5faebf2f61b10f82c97d2._comment b/doc/tips/what_to_do_when_you_lose_a_repository/comment_3_fa9ca81668f5faebf2f61b10f82c97d2._comment
new file mode 100644
index 0000000000..a8d044c287
--- /dev/null
+++ b/doc/tips/what_to_do_when_you_lose_a_repository/comment_3_fa9ca81668f5faebf2f61b10f82c97d2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.8.243"
+ subject="comment 3"
+ date="2012-05-31T17:01:37Z"
+ content="""
+`dead` is the best we can do. The automatic merging used on the git-annex branch tends to re-add lines that are deleted in one repo when merging with another that still has them.
+"""]]
diff --git a/doc/tips/what_to_do_when_you_lose_a_repository/comment_3_fdcfca8707e310ca7bb94d359adf8607._comment b/doc/tips/what_to_do_when_you_lose_a_repository/comment_3_fdcfca8707e310ca7bb94d359adf8607._comment
new file mode 100644
index 0000000000..37058399c2
--- /dev/null
+++ b/doc/tips/what_to_do_when_you_lose_a_repository/comment_3_fdcfca8707e310ca7bb94d359adf8607._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica Semrick"
+ subject="Update?"
+ date="2013-12-16T00:31:27Z"
+ content="""
+Is it reasonable to update this page to include `git-annex forget`?
+"""]]
diff --git a/doc/tips/what_to_do_when_you_lose_a_repository/comment_4_679eb9be0bfb9d48a2b96383c4816f62._comment b/doc/tips/what_to_do_when_you_lose_a_repository/comment_4_679eb9be0bfb9d48a2b96383c4816f62._comment
new file mode 100644
index 0000000000..e0aa916a65
--- /dev/null
+++ b/doc/tips/what_to_do_when_you_lose_a_repository/comment_4_679eb9be0bfb9d48a2b96383c4816f62._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 4"
+ date="2013-12-16T17:04:44Z"
+ content="""
+I wouldn't recommend running `git annex forget --drop-dead` right after losing a drive. You might find the drive again, or get the dead drive to work again. Even if you know you'll never find it, you may want to query git-annex to find files that were only located on that drive, and deal with them, etc.
+
+But if you're worried about that information in the git-annex branch cluttering up the git repository, you keep in mind that `git annex forget` will let you remove it at some point in the future.
+"""]]
diff --git a/doc/tips/what_to_do_when_you_lose_a_repository/comment_5_4fb04b70d88ec93ff9ed4f884747d5d4._comment b/doc/tips/what_to_do_when_you_lose_a_repository/comment_5_4fb04b70d88ec93ff9ed4f884747d5d4._comment
new file mode 100644
index 0000000000..49323b29e5
--- /dev/null
+++ b/doc/tips/what_to_do_when_you_lose_a_repository/comment_5_4fb04b70d88ec93ff9ed4f884747d5d4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/e65e6d0e-58ba-41de-84cc-1f2ba54cf574"
+ nickname="Mica Semrick"
+ subject="forget command"
+ date="2013-12-17T05:52:52Z"
+ content="""
+Unfortunately, I plugged in the drive and it was alive just long enough to clone the repo and pull down about half of the data. Then it just started clicking. I did my best to wipe the drive before I returned it, but it didn't even make it that far.
+
+Now I've got a replacement drive. Since my system auto-mounts based on the partition label; I had been using the label to identify external drives. So I want to describe the drive the same way to my system & git-annex. 
+
+In this case, I think I'd like to completely get rid of any notion the repos have of the old drive. 
+"""]]
diff --git a/doc/tips/what_to_do_when_you_lose_a_repository/comment_6_05db504cbff2ec2a6346bf43e57a3c25._comment b/doc/tips/what_to_do_when_you_lose_a_repository/comment_6_05db504cbff2ec2a6346bf43e57a3c25._comment
new file mode 100644
index 0000000000..5a124cc1b0
--- /dev/null
+++ b/doc/tips/what_to_do_when_you_lose_a_repository/comment_6_05db504cbff2ec2a6346bf43e57a3c25._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 6"
+ date="2013-12-17T16:11:52Z"
+ content="""
+You could use `git annex forget --drop-dead` in that situation, but what I would do is first `git annex describe lostremote \"my old drive that I lost\"` and then set up the replacement drive with whatever description you had before.
+"""]]
diff --git a/doc/tips/what_to_do_when_you_lose_a_repository/comment_7_4e6baa41bfee6edf2b17d4ade2909c7b._comment b/doc/tips/what_to_do_when_you_lose_a_repository/comment_7_4e6baa41bfee6edf2b17d4ade2909c7b._comment
new file mode 100644
index 0000000000..3b4b79da36
--- /dev/null
+++ b/doc/tips/what_to_do_when_you_lose_a_repository/comment_7_4e6baa41bfee6edf2b17d4ade2909c7b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://alan.petitepomme.net/"
+ nickname="Alan Schmitt"
+ subject="still need to remove the remote after a &quot;dead&quot;"
+ date="2014-03-07T18:03:47Z"
+ content="""
+Hello,
+
+I decommissioned a machine and installed git annex on another machine, with the same IP as the initial one. To avoid errors, I declared the first repository as dead and created a new one (with a new remote). However, I also had to remove the git remote to the dead machine as \"git annex sync\" kept telling me synchronizing to this dead machine failed (the ssh succeeded, using the name automatically generated by git annex, but the repository was not at the same path on the new machine, so it could not find it).
+
+Should a dead repository not tried to be synchronized at all during git annex sync?
+
+Thanks,
+
+Alan
+"""]]
diff --git a/doc/tips/what_to_do_when_you_lose_a_repository/comment_8_596bcfa25a4fa6e81bb6a0940c55a2f2._comment b/doc/tips/what_to_do_when_you_lose_a_repository/comment_8_596bcfa25a4fa6e81bb6a0940c55a2f2._comment
new file mode 100644
index 0000000000..addeccbf5b
--- /dev/null
+++ b/doc/tips/what_to_do_when_you_lose_a_repository/comment_8_596bcfa25a4fa6e81bb6a0940c55a2f2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="fiatjaf"
+ subject="comment 8"
+ date="2016-04-23T15:01:23Z"
+ content="""
+I've issued `git annex dead` for a full git-annex repo (not a special remote) I had in a VPS, but my local machine keeps trying to sync with it on `git annex sync`, asking me to confirm the ssh public key and so on. Is that correct?
+"""]]
diff --git a/doc/tips/what_to_do_when_you_lose_a_repository/comment_9_525e58e5941220b23b0ed73fa7611db1._comment b/doc/tips/what_to_do_when_you_lose_a_repository/comment_9_525e58e5941220b23b0ed73fa7611db1._comment
new file mode 100644
index 0000000000..a917935689
--- /dev/null
+++ b/doc/tips/what_to_do_when_you_lose_a_repository/comment_9_525e58e5941220b23b0ed73fa7611db1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2016-05-03T19:15:58Z"
+ content="""
+Both `git annex sync` and `git pull` will still try to access the git
+remote for the repository. Thing to do to prevent this is `git remote
+remove` it.
+
+I think it makes sense for `git annex sync` to still try to push/pull
+from a dead remote, since git pull/push will still try to access it
+too. Marking the remote dead does prevent other git-annex commands
+from trying to use it for data storage.
+"""]]
diff --git a/doc/tips/yet_another_simple_disk_usage_like_utility.mdwn b/doc/tips/yet_another_simple_disk_usage_like_utility.mdwn
new file mode 100644
index 0000000000..961776e193
--- /dev/null
+++ b/doc/tips/yet_another_simple_disk_usage_like_utility.mdwn
@@ -0,0 +1,9 @@
+Here's the annex-du script that I use:
+
+#!/bin/sh
+git annex find "$@" --include '*' --format='${bytesize}\n' |awk '{ sum += $1; nfiles++; } END { printf "%d files, %.3f MB\n", nfiles, sum/1000000 } '
+
+This one can be slow on a large number of files, but it has an advantage of being able to use all of the filtering available in git annex find.
+For example, to figure out how much is stored in remote X, do
+
+annex-du --in=X
diff --git a/doc/tips/yet_another_simple_disk_usage_like_utility/comment_1_41b212bde8bc88d2a5dea93bd0dc75f1._comment b/doc/tips/yet_another_simple_disk_usage_like_utility/comment_1_41b212bde8bc88d2a5dea93bd0dc75f1._comment
new file mode 100644
index 0000000000..4c3e3c22b3
--- /dev/null
+++ b/doc/tips/yet_another_simple_disk_usage_like_utility/comment_1_41b212bde8bc88d2a5dea93bd0dc75f1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 1"
+ date="2013-07-12T19:36:28Z"
+ content="""
+Ah, I just found that git annex info can do the same :)
+Disregard this.
+"""]]
diff --git a/doc/tips/yet_another_simple_disk_usage_like_utility/comment_2_73698913837bfd5a58cf15721211e43e._comment b/doc/tips/yet_another_simple_disk_usage_like_utility/comment_2_73698913837bfd5a58cf15721211e43e._comment
new file mode 100644
index 0000000000..fe4b3d0d21
--- /dev/null
+++ b/doc/tips/yet_another_simple_disk_usage_like_utility/comment_2_73698913837bfd5a58cf15721211e43e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="comment 2"
+ date="2013-08-30T06:09:29Z"
+ content="""
+You may want to try my `sizes` tool on Hackage.  Just pass `-A` and it will be aware of the annex and report sizes as if no files were annexed.  The only downside is that it reports file usage for replicated content multiple times, as if you'd copied the data out of the annex rather than hardlinked all duplicate copies (although, this may be exactly the behavior some people want).
+"""]]
diff --git a/doc/todo.mdwn b/doc/todo.mdwn
new file mode 100644
index 0000000000..8c6d4f4f71
--- /dev/null
+++ b/doc/todo.mdwn
@@ -0,0 +1,8 @@
+This is git-annex's todo list. Link items to [[todo/done]] when done,
+or tags: [[todo/confirmed]] [[todo/moreinfo]] [[todo/needsthought]] [[todo/unlikely]] 
+
+[[!inline pages="./todo/* and !./todo/*/* and !./todo/done and !link(done) 
+and !*/Discussion and !./todo/moreinfo and !./todo/confirmed
+and !./todo/needsthought and !./todo/unlikely"
+actions=yes postform=yes postformtext="Add a new todo titled:"
+show=0 feedlimit=10 archive=yes template=buglist]]
diff --git a/doc/todo/--batch_for_add.mdwn b/doc/todo/--batch_for_add.mdwn
new file mode 100644
index 0000000000..d9acf7054a
--- /dev/null
+++ b/doc/todo/--batch_for_add.mdwn
@@ -0,0 +1,8 @@
+should be extremely helpful when adding many files one at a time ;)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> Implemented; made it not recurse into directories and output a blank line
+> if it doesn't add the file, so there's aways 1 line of output for each
+> input. [[done]] --[[Joey]]
diff --git a/doc/todo/--batch_for_add/comment_1_b1362c86e162a49717d7e3b0816025ba._comment b/doc/todo/--batch_for_add/comment_1_b1362c86e162a49717d7e3b0816025ba._comment
new file mode 100644
index 0000000000..2e70d8ab25
--- /dev/null
+++ b/doc/todo/--batch_for_add/comment_1_b1362c86e162a49717d7e3b0816025ba._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-19T15:32:48Z"
+ content="""
+Has similar problems to batching find; if a whole directory is added any
+number of lines can be output.
+
+So, either needs a similar thing to indicate end of output for current
+item, or perhaps it would make sense for the batched add to not recurse
+into directories, so it would always output exactly 1 line per input.
+"""]]
diff --git a/doc/todo/--batch_for_find.mdwn b/doc/todo/--batch_for_find.mdwn
new file mode 100644
index 0000000000..a97014b064
--- /dev/null
+++ b/doc/todo/--batch_for_find.mdwn
@@ -0,0 +1,6 @@
+I am using `annex find filename` after running 'annex add` to figure out if file was added to annex or to git.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/--batch_for_find/comment_1_d164ad661617d29cb1ceb3d6fc3bb37f._comment b/doc/todo/--batch_for_find/comment_1_d164ad661617d29cb1ceb3d6fc3bb37f._comment
new file mode 100644
index 0000000000..d9a04c220e
--- /dev/null
+++ b/doc/todo/--batch_for_find/comment_1_d164ad661617d29cb1ceb3d6fc3bb37f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-19T15:30:01Z"
+ content="""
+Couldn't you use the existing info --batch for the same purpose?
+
+batching find has the problem that it can output any number of lines
+(0 for a non-annexed file, 1 for an annexed file, N for a directory). So,
+the consumer has no way to tell when it reaches the end of output. So some
+additional thing would be needed to indicate end of output.
+"""]]
diff --git a/doc/todo/--batch_for_find/comment_2_9873396186f4d24088fd746f42373678._comment b/doc/todo/--batch_for_find/comment_2_9873396186f4d24088fd746f42373678._comment
new file mode 100644
index 0000000000..416e588e1b
--- /dev/null
+++ b/doc/todo/--batch_for_find/comment_2_9873396186f4d24088fd746f42373678._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 2"
+ date="2016-01-19T16:39:49Z"
+ content="""
+info -- nope, since it returns the same success and size = 0 bytes for a 0-length file which is under annex regardless either its precious load is present locally or not
+
+[[!format sh \"\"\"
+
+$> git annex find empty
+$> git annex info --json empty
+{\"command\":\"info empty\",\"file\":\"empty\",\"size\":\"0 bytes\",\"key\":\"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\",\"success\":true}
+
+$> git annex get empty
+get empty (from web...) 
+/tmp/123/.git/annex/tmp/SHA256E-s0--e3b0c44298fc1c149af     [ <=>                                                                                                                            ]       0  --.-KB/s    in 0s      
+(checksum...) ok
+(recording state in git...)
+
+$> git annex info --json empty
+{\"command\":\"info empty\",\"file\":\"empty\",\"size\":\"0 bytes\",\"key\":\"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\",\"success\":true}
+
+
+\"\"\"]]
+
+I could use whereis (--batch is TODO for it as well) and analyze output either any remote claims it to be \"here\" though.
+"""]]
diff --git a/doc/todo/--batch_for_find/comment_3_598a0500a3a4573c50a559d1931f1918._comment b/doc/todo/--batch_for_find/comment_3_598a0500a3a4573c50a559d1931f1918._comment
new file mode 100644
index 0000000000..e2e75dd881
--- /dev/null
+++ b/doc/todo/--batch_for_find/comment_3_598a0500a3a4573c50a559d1931f1918._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-01-19T17:13:05Z"
+ content="""
+You were talking about determining if a file is in git-annex or git, and
+git-annex info can do that.
+"""]]
diff --git a/doc/todo/--batch_for_find/comment_4_830cf616968e25cee8e7d35f9709f79b._comment b/doc/todo/--batch_for_find/comment_4_830cf616968e25cee8e7d35f9709f79b._comment
new file mode 100644
index 0000000000..35f2873c03
--- /dev/null
+++ b/doc/todo/--batch_for_find/comment_4_830cf616968e25cee8e7d35f9709f79b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 4"
+ date="2016-01-19T19:24:11Z"
+ content="""
+you caught me! ;) indeed in this case we could use 'info' for that purpose.  But if we decide if content is present under annex (which is what actually our function does, we just used it for determining \"if under annex\" after addurl) -- then find --batch would be needed, or whois --batch could be used.  So we are both correct! ;)
+"""]]
diff --git a/doc/todo/--batch_for_info.mdwn b/doc/todo/--batch_for_info.mdwn
new file mode 100644
index 0000000000..a365151c3c
--- /dev/null
+++ b/doc/todo/--batch_for_info.mdwn
@@ -0,0 +1,6 @@
+I guess as other commands which take separate files/keys as its argument(s), having --batch for info command would be of benefit
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex.mdwn b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex.mdwn
new file mode 100644
index 0000000000..c25098f60e
--- /dev/null
+++ b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex.mdwn
@@ -0,0 +1,7 @@
+In the light of the recent debugging of git-annex+datalad special remote tandem, I would have appreciated if there was a way to see reflection of git-annex actions beyond current `--debug`: what is annex intending to do internally (not just reporting which commands to be ran etc).  Most likely such higher level of debug information would generally be not needed, so probably not worth "enriching" default `--debug` output, so I wonder if there could be an option or config setting which would set `git-annex` on the path to provide more debug output if requested (e.g. like those on closing stdin/stdout/stderr/stderr-handler), may be it could be a config setting which would allow for `DEFAULT|HEAVY|VERYHEAVY` or alike values.
+I hope that I would never need to use that, but it might end up being "days-savior" 
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]] 
diff --git a/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_1_58e729e2fa58b28d247eeda579bb9329._comment b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_1_58e729e2fa58b28d247eeda579bb9329._comment
new file mode 100644
index 0000000000..b7846d2372
--- /dev/null
+++ b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_1_58e729e2fa58b28d247eeda579bb9329._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-11-02T18:48:44Z"
+ content="""
+Every call to debugM does add overhead both in time to run it
+(checking if debugging is enabled is nonzero overhead and this will add up
+if it's done a few million times or whatever) and in time to write
+a useful explanation.
+
+It seems to me that debugging is best added when trying to debug something,
+or when there's a readily available value that can be output (such as the
+safety proof that is debugged when dropping, or external special remote
+messages).
+
+Trying to add enough useful debugging information to 60,000 lines of code
+that any possible thing it might do will have a useful debug trace seems
+like a recipe to end up with 100,000 lines of code. It would be easier to
+run the code in a debugger and step through it at that point.
+"""]]
diff --git a/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_2_66a32cef4ff6bc93ad04346612f543ec._comment b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_2_66a32cef4ff6bc93ad04346612f543ec._comment
new file mode 100644
index 0000000000..4243193749
--- /dev/null
+++ b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_2_66a32cef4ff6bc93ad04346612f543ec._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-11-02T20:37:47Z"
+ content="""
+> Every call to debugM does add overhead both in time to run it (checking if debugging is enabled is nonzero overhead and this will add up if it's done a few million times or whatever) and in time to write a useful explanation.
+
+debug-vs-not could be decided at start up once, and debug function could be set to noop if no debugging output (given the level requested) was desired.  I really doubt that any reasonable number of noop function calls would add any notable burden on top of operation/interaction with external git commands and remotes.
+
+> It seems to me that debugging is best added when trying to debug something, or when there's a readily available value that can be output (such as the safety proof that is debugged when dropping, or external special remote messages).
+
+yes, but then first you need to identify the code where to add it and know how to add it...  users (myself included) would not be be able to do so that easily.
+
+> Trying to add enough useful debugging information to 60,000 lines of code that any possible thing it might do will have a useful debug trace seems like a recipe to end up with 100,000 lines of code
+
+sure thing should not be added to every code line!  But there would be value from knowing some critical \"interface\" points where e.g. hanging or incorrect operation could happen, e.g. if I saw earlier the output of what `trace.patch` you provided today I might have saved myself quite a lot of time, so sounds like a location of value to add some `heavydebug()` logging.
+
+> It would be easier to run the code in a debugger and step through it at that point.
+
+might not be that easy especially when relevant git-annex call is sandwiched deep in the hierarchy of datalad/git/git-annex/datalad/git-annex/datalad/git-annex calls through all the special remotes etc.
+"""]]
diff --git a/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_3_ea60112be683188e43b27942667ddd77._comment b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_3_ea60112be683188e43b27942667ddd77._comment
new file mode 100644
index 0000000000..a14cdc39ef
--- /dev/null
+++ b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_3_ea60112be683188e43b27942667ddd77._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-11-03T01:47:26Z"
+ content="""
+It would be possible to split out of AnnexState a value that is
+immutable, and have that part not gated behind a MVar, and so avoid the
+MVar lookup overhead, since it would just be part of the Annex Reader
+monad. And the debug action in that could just be a noop when it's disabled,
+and so be essentially zero overhead. One little problem is that option
+parsing (eg for --debug) currently runs in the Annex monad, so too late to
+change that immutable value.
+
+Obviously having debug logging in a place where you just needed debug
+logging would have been useful. It does not logically follow that we can
+determine such places prior to your needing debug logging, or that we will
+need debug logging there later. After all, it seems to have been debugged
+now.
+
+I suppose we can say that anything involving canceling a thread, or closing
+a file descriptor connected to a pipe, is fairly delicate and so it makes
+sense to wrap and debug log those. (Which were the things needing debug
+logging in your case.) But the only information available to display is
+"thread N" or "FD N", so it would also need to debug log each thread spawn
+and FD open point in order to work out which are interesting. (Or wrap the
+values with more information, but that rapidly gets ugly.)
+
+Anyway, I rarely find myself adding debugM calls when debugging git-annex,
+generally just playing with the test case rapidly lets a theory be formed
+about what's happening, and then do something to test the theory, and I'm
+probably most of the way to a fix or at least understanding the problem.
+
+The main way the current debug output is useful to me is it often hints at
+the proximate location of the problem, because of whatever git command
+git-annex ran just before it. It would certianly be useful to have
+additional debugM wherever there's a lot of code that does not involve
+anything that currently logs.. But I don't know a good way to identify
+such stretches of code.
+"""]]
diff --git a/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_4_03cd162638a9b4f2b7981cee141693f6._comment b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_4_03cd162638a9b4f2b7981cee141693f6._comment
new file mode 100644
index 0000000000..14714794cc
--- /dev/null
+++ b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_4_03cd162638a9b4f2b7981cee141693f6._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-04-02T16:09:45Z"
+ content="""
+I benchmarked calls to debugM when no debug output is enabled,
+and it looks like around 1 million can be made per second
+on my netbook. So if a 1% slowdown due to debugging is acceptable (which
+seems a bit above the upper bound to me), that would allow 10 thousand
+debugM calls per second.
+
+Current call rate is probably always under 10 per second. Keeping it
+out of tight loops would probably be sufficient.
+
+Once place I sometimes wish had debugging is reads from the git-annex
+branch. But running eg "git-annex get --from foo" in a repository with
+many thousands of files, none of them in foo, does tends of 
+thousands of reads per second in a tight loop. Benchmarked
+that command with debugM of reads added, and it was 0.05% slower
+than without debugM.
+
+So, to add debugM there, would need to do what comment #3 discussed.
+"""]]
diff --git a/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_5_f27efaef3d9cb8db3de9dd42df252059._comment b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_5_f27efaef3d9cb8db3de9dd42df252059._comment
new file mode 100644
index 0000000000..0a4619965f
--- /dev/null
+++ b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_5_f27efaef3d9cb8db3de9dd42df252059._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-04-02T17:31:57Z"
+ content="""
+Re comment #3, it occurs to me that currently anything that accesses
+AnnexState does an MVar access, which will have around the same overhead as
+a call to debugM. But much more frequently used.
+
+So, anything in AnnexState that is frequently used and is immutable
+and could be split out to Reader will avoid that MVar access and be a
+free performance win. Good reason to split AnnexState, whether or not
+it's used to speed debugging.
+"""]]
diff --git a/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_6_d9014e7e964f47a4fdc680ffc53e17b8._comment b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_6_d9014e7e964f47a4fdc680ffc53e17b8._comment
new file mode 100644
index 0000000000..eed0947a1c
--- /dev/null
+++ b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_6_d9014e7e964f47a4fdc680ffc53e17b8._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-04-05T19:28:36Z"
+ content="""
+I've implemented --debugfilter which can select the debug output you want
+to see.
+
+Also started splitting out the immutable parts of AnnexState, but that does
+not yet include debug options, due to the way option parsing currently
+works. Once that gets done, there's a new fastDebug that can be used inside
+tight loop code paths.
+"""]]
diff --git a/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_7_5ae9913b8b9a9fe443c211976adce002._comment b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_7_5ae9913b8b9a9fe443c211976adce002._comment
new file mode 100644
index 0000000000..c7476f97b5
--- /dev/null
+++ b/doc/todo/--debug-level___40__and__47__or_-c_annex.debug-level__41___+_more_debug_information_from_git-annex/comment_7_5ae9913b8b9a9fe443c211976adce002._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-04-06T19:42:06Z"
+ content="""
+fastDebug is implemented.. Benchmarking, I get:
+
+- without debugging in Annex.Branch: 4.75s
+- debug in Annex.Branch: 4.88s, 0.027% slower
+- fastDebug in Annex.Branch: 4.83s, 0.016% slower
+
+So I was right that fastDebug would be faster, but I guess there's still
+some small overhead to check the data structure to see if debugging is
+enabled, and it may not be possible to avoid that. (Maybe unboxing would
+help?)
+
+I'm not bothered by such a small slowdown;
+git-annex has been sped up a lot in recent times and it's ok to pay that.
+(Although I actually finessed it by not debugging cache hits.)
+But cumulative slowdowns from adding debugging lots of places that end up
+all being used in the same tight loop is still something to keep an eye on.
+
+With that said, it should be easy to add
+additional debug info to most parts of git-annex now, so get in touch if
+you have something specific you want debug info for. I'm closing this todo
+here.
+
+(See also, [[todo/move_readonly_values_to_AnnexRead]])
+"""]]
diff --git a/doc/todo/--get_option_for_diffdriver.mdwn b/doc/todo/--get_option_for_diffdriver.mdwn
new file mode 100644
index 0000000000..6e424d0293
--- /dev/null
+++ b/doc/todo/--get_option_for_diffdriver.mdwn
@@ -0,0 +1,5 @@
+since there is no generic 'fuse' mode, I would like to request to have `--get` (or `--auto-get`) option for diffdriver.  I am trying to compare files across two branches on a repo I just cloned.  I cannot download all the files  and downloading differing keys across branches for the same file is a bit painful.  So I felt that it would be super nice if git annex could auto get those files from somewhere (well -- original clone)
+
+[[!tag confirmed]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/--get_option_for_diffdriver/comment_1_6b2501b2dc0318242e444e8d4b8b314f._comment b/doc/todo/--get_option_for_diffdriver/comment_1_6b2501b2dc0318242e444e8d4b8b314f._comment
new file mode 100644
index 0000000000..afaa14e986
--- /dev/null
+++ b/doc/todo/--get_option_for_diffdriver/comment_1_6b2501b2dc0318242e444e8d4b8b314f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-02-08T17:28:21Z"
+ content="""
+This is a good idea. I wonder what to do about the objects it downloads for
+a diff; should they be left in the annex for later use/dropunused, or
+immediately deleted after the diff completes. 
+
+My inclination is to keep
+them around, for one thing when I'm diffing stuff I often run diff more
+than once, perhaps to widen the diff or because I want to take a second
+look at it, and re-downloading a bunch of big files would be painful then.
+
+By the way, what diffdriver program are you using? I've had a hard time
+finding any real-life examples of git diffdrivers.
+"""]]
diff --git a/doc/todo/--get_option_for_diffdriver/comment_2_cb4eb05f447a214353a5bd5c29d207d0._comment b/doc/todo/--get_option_for_diffdriver/comment_2_cb4eb05f447a214353a5bd5c29d207d0._comment
new file mode 100644
index 0000000000..8f2f810c0d
--- /dev/null
+++ b/doc/todo/--get_option_for_diffdriver/comment_2_cb4eb05f447a214353a5bd5c29d207d0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2023-08-09T05:31:26Z"
+ content="""
+How about handling them as if they were manually fetched with `git annex get`? The next run of `satisfy`, `sync`, etc. will then take care of dropping.
+"""]]
diff --git a/doc/todo/--json_for_registerurl.mdwn b/doc/todo/--json_for_registerurl.mdwn
new file mode 100644
index 0000000000..da22801cb3
--- /dev/null
+++ b/doc/todo/--json_for_registerurl.mdwn
@@ -0,0 +1,14 @@
+(and `--json-error-messages`?) to provide more formalized machine readable serialization.
+
+(weak) motivation: [https://github.com/datalad/datalad/issues/6431](datalad/issues/6431)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> Added --json and --json-error-messages. Note that this did change the 
+> --batch output in a way that could possibly break something that expected
+> the old output to never change. I think it's acceptable to break that
+> because there has never been a guarantee of unchanging output format
+> except with --batch for most commands.
+> 
+> [[done]] --[[Joey]]
diff --git a/doc/todo/--json_for_registerurl/comment_1_68fd330b6f20ef2d56234a639a5323c4._comment b/doc/todo/--json_for_registerurl/comment_1_68fd330b6f20ef2d56234a639a5323c4._comment
new file mode 100644
index 0000000000..7e3013a05c
--- /dev/null
+++ b/doc/todo/--json_for_registerurl/comment_1_68fd330b6f20ef2d56234a639a5323c4._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-14T16:26:52Z"
+ content="""
+The particular batch output format is not specified for this, and it's
+rather ad-hoc. I think this is the only --batch that is treated all as a
+single action with "registerurl (stdin)" at start and only one "ok" at the
+end of all the batched input. That was inherited from the non-batch
+behavior. Implementing --batch --json would need a second, redundant
+implementation that treats each batch input as its own action. Only using
+that for --json would be weird, but using it for --batch generally would be
+a behavior change. Urk.
+
+Aside from crashing if an invalid key is provided,
+or perhaps some other exceptional error, there are no real ways it could
+fail so --json-error-messages is unlikely to be useful. But adding --json
+always adds it anyway.
+
+(unregisterurl has the same interface and mostly same implementation,
+and so same problems as registerurl.)
+"""]]
diff --git a/doc/todo/--json_for_unannex__and_ideally_any_other_command_.mdwn b/doc/todo/--json_for_unannex__and_ideally_any_other_command_.mdwn
new file mode 100644
index 0000000000..1a3f8591ea
--- /dev/null
+++ b/doc/todo/--json_for_unannex__and_ideally_any_other_command_.mdwn
@@ -0,0 +1,118 @@
+While looking for various spots where `core.quotepath=true` is now treated
+by git-annex
+([ref](https://github.com/datalad/datalad/pull/7372#issuecomment-1533507701))
+I found that `unannex` doesn't have `--json` and we do some really ad-hoc
+splitting which fails with spaces and we never actually tested enough.
+With all the `quotepath` and other fun, we really should get
+machine-readable, thus `--json`, output for all annex commands IMHO. E.g.
+`unannex` has recently come up within treatment of BIDS datasets, and so
+far we were lucky that BIDS filenames do not allow for spaces in the
+filenames, but there is always `derivatives/` and `sourcedata/` which are
+not formalized and could have all kinds of odd filenames.
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+These commands have been updated to support --json:
+
+* git-annex-unannex
+* git-annex-rmurl 
+* git-annex-log
+* git-annex-fix
+* git-annex-setpresentkey
+* git-annex-rekey
+* git-annex-undo
+* git-annex-migrate
+* git-annex-addunused
+* git-annex-dropunused
+* git-annex-expire
+* git-annex-trust
+* git-annex-semitrust
+* git-annex-untrust
+* git-annex-dead
+* git-annex-describe
+* git-annex-unused
+* git-annex-init
+* git-annex-reinit
+* git-annex-reinject
+* git-annex-renameremote
+* git-annex-importfeed
+* git-annex-merge
+* git-annex-upgrade
+* git-annex-initremote
+* git-annex-enableremote
+* git-annex-configremote
+* git-annex-uninit
+
+These commands have been reviewed and should not support json:
+
+(Discussion welcome of course if you disagree..)
+
+* git-annex-contentlocation, git-annex-lookupkey, git-annex-calckey,
+  (plumbing, output already machine parseable)
+* git-annex-setkey (plumbing)
+* git-annex-checkpresentkey (plumbing, has batch interface with machine
+  parseable output)
+* git-annex-readpresentkey (plumbing, no output)
+* git-annex-matchexpression (no output)
+* git-annex-list (because it's a compact display of whereis so no new information)
+* git-annex-direct (deprecated noop)
+* git-annex findref (deprecated, can use find to do same thing)
+* git-annex indirect (deprecated noop)
+* git-annex proxy (deprecated and displays git command output so nothing
+  structured)
+* git-annex-pre-commit (used internally)
+* git-annex-post-receive (used internally)
+* git-annex-smudge, git-annex-filter-process (run by git)
+* git-annex-p2p (used internally)
+* git-annex-shell (run by git)
+* git-annex-assistant (too high level)
+* git-annex-watch (too high level and a daemon)
+* git-annex-webapp (too high level)
+* git-annex-test, git-annex testremote (ouput not useful to consume and generated by tasty)
+* git-annex-fuzztest (output not useful to consume)
+* git-annex-map (already generates machine-parseable output file, stdout is incidental)
+* git-annex-transferkey, git-annex-transferkeys (plumbing)
+* git-annex-transferrer (plumbing, has its own protocol)
+* git-annex-resolvemerge (no output except to stderr)
+* git-annex-diffdriver (run by git)
+* git-annex-restage (no output)
+* git-annex-benchmark (no useful output, and output generated by criterion)
+* git-annex-config (only useful output is when it outputs the current value
+  of a config setting, which is already machine parseable)
+* git-annex-required, git-annex-wanted, git-annex-groupwanted (like git-annex-config)
+* git-annex-mincopies, git-annex-numcopies (like git-annex-config)
+* git-annex-group (like git-annex-config)
+* git-annex-ungroup (no point if group doesn't)
+* git-annex-filter-branch (output is already machine parseable)
+* git-annex-remotedaemon (plumbing, speaks its own protocol)
+* git-annex-repair (seems unlikely to be useful to integrate with
+  something?)
+* git-annex-vicfg (interactive)
+* git-annex-enable-tor (prompts for password, more or less interactive so
+  seems unlikely to be useful to jsonize)
+* git-annex-multicast (runs uftp and displays its output)
+* git-annex-whereused (output is already machine parseable)
+* git-annex forget (output does not contain anything useful to a program)
+* git-annex-adjust, git-annex-vadd, git-annex-vcycle, git-annex-vfilter, git-annex-view, git-annex-vpop
+  (no output that would be useful to a program using these. They enter a
+  new branch and git branch will tell what it is.)
+* git-annex-inprogress (output is already machine readable)
+* git-annex-sync (while it would be pretty easy to support, it outputs
+  different types of messages depending on what remotes it syncs with and
+  what needs to be done. Eg, copy to remote, or export to remote, or import
+  from remote. Each would be a different format of json message, which
+  violates the principle that all git-annex json output should be
+  discoverable by simply running the command. And of course, everything it
+  does can be done by other commands, which can support json without having
+  that problem.)
+* git-annex-version (--raw already exists, and the other output is fairly
+  machine parseable already. It would be possible to jsonize the output to
+  make it possibly more machine parseable. But I'm doubtful that would be
+  useful.
+  Also, this command needs to work when not run in a git-annex repo,
+  and usual json display needs the Annex monad. So it would need to use
+  aeson manually.
+
+> Calling this [[done]]. Of course, if I was wrong about any of the
+> commands above not needing json, just let me know. --[[Joey]]
diff --git a/doc/todo/--json_for_unannex__and_ideally_any_other_command_/comment_1_9cc7829b4742f21077a27caad7ae638e._comment b/doc/todo/--json_for_unannex__and_ideally_any_other_command_/comment_1_9cc7829b4742f21077a27caad7ae638e._comment
new file mode 100644
index 0000000000..8ec161dbc3
--- /dev/null
+++ b/doc/todo/--json_for_unannex__and_ideally_any_other_command_/comment_1_9cc7829b4742f21077a27caad7ae638e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-05-03T19:33:50Z"
+ content="""
+I agree generally, anything that is not already
+explicitly machine parseable should support --json
+(and --json-error-options will be available for free once that's added)
+
+I'd exclude things like `git-annex find` which have
+--format that can be used similarly; and a separate json
+output would not be very useful for find anyway probably?
+
+I've added a list of commands that currently don't support --json above.
+
+Did unannex already, as it was trivial.
+"""]]
diff --git a/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison.mdwn b/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison.mdwn
new file mode 100644
index 0000000000..a7eea78b13
--- /dev/null
+++ b/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison.mdwn
@@ -0,0 +1,95 @@
+Thank you for `git-annex`, it's awesome!
+
+I recently figured I could add `git-annex metadata` to my research data files that contains the start and end date of timeseries data inside the files so a quick lookup by date range (”which files contain data in that time range”) is possible.
+
+This is possible when using numeric timestamps (e.g. unix timestamp like `1669981463`) but not with stringy dates (e.g. `2022-11-12T20:10:14+0200`) as `--metadata fieldname>=VALUE` does _numeric_ comparison.
+
+## Proposal: How about when `--metadata fieldname>=VALUE` falls back to string comparison when `VALUE` can't be parsed as a number?
+
+## Test case
+
+Consider this script `make-git-annex-dir-with-timestamps.sh`:
+
+```sh
+#/bin/sh
+fmt="$1";test -n "$fmt" || fmt="%FT%T%z"
+# make a new git annex repository
+d=git-annex-with-times-"$fmt";chmod +w -R "$d";rm -rf "$d";mkdir "$d";cd "$d"
+git init
+git annex init
+# create some files
+for i in `seq 1 9`;do echo "File $i" > "file$i";done
+git annex add .
+git commit -m "Add files"
+# add metadata to files
+for i in `seq 1 9`;do 
+    time_start="$(date -d"$((-20 + $i)) hours" +"$fmt")"
+    (set -x;git annex metadata --set time-start="$time_start" "file$i")
+    time_end="$(date -d"$((-10 + $i)) hours" +"$fmt")"
+    (set -x;git annex metadata --set time-end="$time_end" "file$i")
+done
+timerange_start="$(date -d "-16 hours -5 minutes" +"$fmt")"
+timerange_end="$(date -d "-12 hours +5 minutes" +"$fmt")"
+(
+set -x
+git annex find \
+    "-(" --metadata "time-start>=$timerange_start"  --and --metadata "time-start<=$timerange_end" "-)" \
+    --or \
+    "-(" --metadata "time-end>=$timerange_start"  --and --metadata "time-end<=$timerange_end" "-)"
+)
+echo "⬆⬆⬆ This should only output file4 through file8 ⬆⬆⬆"
+```
+
+Invoked with unix timestamps time format, it works as expected:
+
+```sh
+> ./make-git-annex-dir-with-timestamps.sh '%s'
+# ...
++ git annex find '-(' --metadata 'time-start>=1669923315' --and --metadata 'time-start<=1669938315' '-)' --or '-(' --metadata 'time-end>=1669923315' --and --metadata 'time-end<=1669938315' '-)'
+file4
+file5
+file6
+file7
+file8
+⬆⬆⬆ This should only output file4 through file8 ⬆⬆⬆
+```
+
+However, other stringy date formats match all files:
+
+```bash
+# typical ISO-ish time format
+> ./make-git-annex-dir-with-timestamps.sh "%FT%T%z"
+# ...
++ git annex find '-(' --metadata 'time-start>=2022-12-01T20:49:37+0100' --and --metadata 'time-start<=2022-12-02T00:59:37+0100' '-)' --or '-(' --metadata 'time-end>=2022-12-01T20:49:37+0100' --and --metadata 'time-end<=2022-12-02T00:59:37+0100' '-)'
+file1
+file2
+file3
+file4
+file5
+file6
+file7
+file8
+file9
+⬆⬆⬆ This should only output file4 through file8 ⬆⬆⬆
+```
+
+```sh
+# git-annex's own time format for 'FIELDNAME-lastchanged'
+> ./make-git-annex-dir-with-timestamps.sh "%Y-%m-%d@%H-%M-%S"
+# ...
++ git annex find '-(' --metadata 'time-start>=2022-12-01@20-38-04' --and --metadata 'time-start<=2022-12-02@00-38-04' '-)' --or '-(' --metadata 'time-end>=2022-12-01@20-38-04' --and --metadata 'time-end<=2022-12-02@00-38-04' '-)'
+file1
+file2
+file3
+file4
+file5
+file6
+file7
+file8
+file9
+⬆⬆⬆ This should only output file4 through file8 ⬆⬆⬆
+```
+
+Yann / @nobodyinperson
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_1_e2da4d1fceb5f7c37e3c19d42256c8d5._comment b/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_1_e2da4d1fceb5f7c37e3c19d42256c8d5._comment
new file mode 100644
index 0000000000..32799822fa
--- /dev/null
+++ b/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_1_e2da4d1fceb5f7c37e3c19d42256c8d5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-12-12T17:06:40Z"
+ content="""
+I think this is a good idea. Particularly there was no good reason for
+it to default to false when either value is not a number.
+
+I've implemented this.
+"""]]
diff --git a/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_2_38c46dee95ef2f246cd403717faaaa09._comment b/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_2_38c46dee95ef2f246cd403717faaaa09._comment
new file mode 100644
index 0000000000..9e80fe0aa5
--- /dev/null
+++ b/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_2_38c46dee95ef2f246cd403717faaaa09._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2022-12-22T11:39:41Z"
+ content="""
+Thanks joey! However I don't think it works quite now. Slightly modifying the script above I made a [testsuite](https://gitlab.com/-/snippets/2475815) and it seems metadata fields are still interpreted as numbers somehow:
+
+```bash
+# old version without lexicographical ordering
+❯ git annex version --raw
+10.20221212-gab11fd70e
+❯ bash make-git-annex-dir-with-timestamps.sh %s %Y%m%d%H%M%S %Y.%m%d%H%M%S %Y:%m%d%H%M%S %Y-%m-%dT%H%:M:%S %Y-%m-%dT%H%:M:%S%z %FT%T %FT%T%z
+                  %s ok
+        %Y%m%d%H%M%S ok
+       %Y.%m%d%H%M%S ok
+       %Y:%m%d%H%M%S fail
+   %Y-%m-%dT%H%:M:%S fail
+ %Y-%m-%dT%H%:M:%S%z fail
+               %FT%T fail
+             %FT%T%z fail
+
+# new version apparently with lexicographical ordering but no change
+❯ git annex version --raw
+10.20221213-gac6ccb513
+❯ bash make-git-annex-dir-with-timestamps.sh %s %Y%m%d%H%M%S %Y.%m%d%H%M%S %Y:%m%d%H%M%S %Y-%m-%dT%H%:M:%S %Y-%m-%dT%H%:M:%S%z %FT%T %FT%T%z
+                  %s ok
+        %Y%m%d%H%M%S ok
+       %Y.%m%d%H%M%S ok
+       %Y:%m%d%H%M%S fail
+   %Y-%m-%dT%H%:M:%S fail
+ %Y-%m-%dT%H%:M:%S%z fail
+               %FT%T fail
+             %FT%T%z fail
+
+```
+"""]]
diff --git a/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_3_9c298fbda8d395fe9b8395105708c3bd._comment b/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_3_9c298fbda8d395fe9b8395105708c3bd._comment
new file mode 100644
index 0000000000..d27c4641b5
--- /dev/null
+++ b/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_3_9c298fbda8d395fe9b8395105708c3bd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-12-22T18:30:46Z"
+ content="""
+Thanks for double-checking. I have not tried your test but I think I see
+what is going on from the pattern. Strings starting with a number but then
+subsequently not a number were still being parsed to numbers and compared
+numerically. I've fixed that now.
+"""]]
diff --git a/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_4_b8f2602e633dae4c85f89c97c8f03d81._comment b/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_4_b8f2602e633dae4c85f89c97c8f03d81._comment
new file mode 100644
index 0000000000..a20013aa3c
--- /dev/null
+++ b/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_4_b8f2602e633dae4c85f89c97c8f03d81._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 4"
+ date="2022-12-23T09:39:57Z"
+ content="""
+Now it works, thank you very much joey! 🎉
+
+```bash
+❯ ./make-git-annex-dir-with-timestamps.sh                                                                                            
++ git annex version --raw                                                                                                                  
+10.20221213-g29176f131                                                                                                                     
+                  %s ok                                                                                                                    
+        %Y%m%d%H%M%S ok                                                                                                                    
+       %Y.%m%d%H%M%S ok                                                                                                                    
+       %Y:%m%d%H%M%S ok                                                                                                                    
+   %Y-%m-%dT%H:%M:%S ok                                                                                                                    
+ %Y-%m-%dT%H:%M:%S%z ok                                                                                                                    
+               %FT%T ok                                                                                                                    
+             %FT%T%z ok
+```
+
+(I had a typo in the above tests - a `%` out of place - but it didn't change the picture, now everything works as expected anyway.)
+"""]]
diff --git a/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_5_afba02fb24eddc6569dce63ffe606dcf._comment b/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_5_afba02fb24eddc6569dce63ffe606dcf._comment
new file mode 100644
index 0000000000..ffa3fb6893
--- /dev/null
+++ b/doc/todo/--metadata_fieldname__62____61__VALUE_string_comparison/comment_5_afba02fb24eddc6569dce63ffe606dcf._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 5"
+ date="2022-12-23T10:05:26Z"
+ content="""
+A very nice benefit of this feature is that we can now `git annex find` files depending on when their metadata was changed:
+
+```sh
+# annexed files which have recently had their metadata changed
+git annex find --metadata \"lastchanged>=$(date -d'2 days ago' +%Y-%m-%d@%H-%M-%S)\"
+
+# annexed files which have their tag changed in a specific week
+git annex find --metadata \"tag-lastchanged>=2022-12-18\"  --and --metadata \"tag-lastchanged<=2022-12-25\"
+```
+"""]]
diff --git a/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__.mdwn b/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__.mdwn
new file mode 100644
index 0000000000..b11bcfe9a4
--- /dev/null
+++ b/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__.mdwn
@@ -0,0 +1,8 @@
+In DataLad we have a special mode for cloning git-annex repos called `--reckless=ephemeral` which we discussed with you Joey awhile back as a solution for throw away temporary copies of repos for processing in such a way that we would not need to fetch all TBs of already present on local drive data.
+
+One gotcha is that in such a case population of `.git/annex` with new keys in the clone, does not inform original one about those changes. What we then need to do is to eventually run `git annex fsck` in original location so it realizes that it got all those possibly new keys.  That might take at times quite a while.
+
+I wondered if may be git-annex could gain some "native" support for such use-case which would avoid need for `annex fsck` and possibly would immediately reflect information on changes to availability either in that reckless clone (e.g. if it knows UUID of original one e.g. as stored in `annex.orig-uuid` config), or even in the original repo (by following the symlink or just some `annex.orig-path` dedicated config variable).  WDYT Joey?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
diff --git a/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_1_7815551c0ec6d933ae5537e28fb183ad._comment b/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_1_7815551c0ec6d933ae5537e28fb183ad._comment
new file mode 100644
index 0000000000..da38edfc01
--- /dev/null
+++ b/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_1_7815551c0ec6d933ae5537e28fb183ad._comment
@@ -0,0 +1,78 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2023-03-10T02:52:08Z"
+ content="""
+doh - forgot to add example of what kind of mode of operation I am talking about
+
+<details>
+<summary>Here is the script</summary> 
+
+```shell
+#!/bin/bash
+set -ex
+
+cd \"$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)\"
+
+mkdir orig
+( cd orig; git init; git annex init; echo 123 > 123; git annex add 123; git commit -m 123 123; )
+
+git clone orig ephemeral
+
+(
+cd ephemeral
+
+# making it ephemeral
+ln -s ../../orig/.git/annex .git/annex
+
+git annex init; 
+
+echo 124 > 124
+git annex add 124
+git commit -m 124 124
+
+git annex whereis 124
+)
+
+(
+cd orig;
+
+git remote add ephemeral ../ephemeral
+git pull ephemeral master
+
+: it would still not know that it got 124
+git annex whereis 124 || echo \"exited with $?\"
+
+git annex fsck
+
+: but would know now after fsck
+git annex whereis 124
+)
+
+```
+</details>
+
+running which at the end produces
+
+```
++ : it would still not know that it got 124
++ git annex whereis 124
+whereis 124 (0 copies) failed
+whereis: 1 failed
++ echo 'exited with 1'
+exited with 1
++ git annex fsck
+fsck 123 (checksum...) ok
+fsck 124 (fixing location log) (checksum...) ok
+(recording state in git...)
++ : but would know now after fsck
++ git annex whereis 124
+whereis 124 (1 copy) 
+  	a813ca99-ce43-4e57-b7d9-c3a1456c6b55 -- yoh@lena:~/.tmp/dl-hlNOqBM/orig [here]
+ok
+```
+
+where `124` file was annex added in the reckless clone.
+```
+"""]]
diff --git a/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_2_2debe0cb11763f0673255cfd7f764815._comment b/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_2_2debe0cb11763f0673255cfd7f764815._comment
new file mode 100644
index 0000000000..764d477a31
--- /dev/null
+++ b/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_2_2debe0cb11763f0673255cfd7f764815._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-03-10T15:43:58Z"
+ content="""
+Is there any reason you don't initialize the clone with the same uuid as
+the parent remote? That seems to me like it would make sense, since they
+*are* the same git-annex repository.
+
+Can you refresh my memory of where we discussed this --reckless=ephemeral
+hack? I can't find it discussed by that name anywhere in git-annex or mail
+mail archives. Just want to understand the motivation of doing that,
+and why other approaches were not considered.
+"""]]
diff --git a/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_3_b559ac06e7fc622b8bbb5e73d4cc0930._comment b/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_3_b559ac06e7fc622b8bbb5e73d4cc0930._comment
new file mode 100644
index 0000000000..8ab0c7a6c6
--- /dev/null
+++ b/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_3_b559ac06e7fc622b8bbb5e73d4cc0930._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-04-04T17:38:22Z"
+ content="""
+Occurs to me that this is very similar to `git worktree`. The difference
+is that you can make whatever changes to git branches in this "ephemeral
+clone" without affecting the parent repository. But as far as git-annex is
+concerned, in both cases there are two git repositories that share their
+.git/annex and so are essentially the same git-annex repository.
+"""]]
diff --git a/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_4_8cb8cdef0cc563714d7bc7d91743762b._comment b/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_4_8cb8cdef0cc563714d7bc7d91743762b._comment
new file mode 100644
index 0000000000..d0cbc0d853
--- /dev/null
+++ b/doc/todo/Add_annex.orig-uuid_config_for___39__ephemeral_clones__39__/comment_4_8cb8cdef0cc563714d7bc7d91743762b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-04-04T17:48:04Z"
+ content="""
+See downstream discussion here: <https://github.com/datalad/datalad/issues/7363>
+"""]]
diff --git a/doc/todo/Adding_a_matcher_for___39__recently_touched_files__39__.mdwn b/doc/todo/Adding_a_matcher_for___39__recently_touched_files__39__.mdwn
new file mode 100644
index 0000000000..1ad30494e7
--- /dev/null
+++ b/doc/todo/Adding_a_matcher_for___39__recently_touched_files__39__.mdwn
@@ -0,0 +1,46 @@
+First mentioned [here](https://git-annex.branchable.com/todo/new_command_for_syncing_content_only/#comment-0814894ed5e40c9d0f7aef694cce53c1)
+
+## TL;DR: Feature Proposal: A matching option to operate only on files within a git revision range
+
+## Motivation
+
+I use git-annex for several repositories where content is added automatically, e.g.:
+
+- my phone (pictures I take, selected pictures others send me, etc.)
+- my research data repo (new files are added as data comes in)
+
+Those repos don't necessarily have the assistant running as I want to control when and what's being added. I also have `annex.synccontent=false` set because full availability of all files doesn't make sense. I imagine I am not the only one using git annex like this.
+
+Most of the time, when I want to access content from such repos from another machine, it is often just the most recent content. Example: I take a picture on my phone and would like to have it *now* on my desktop. The workflow is:
+
+[[!format  bash """
+yann@phone> git annex assist # takes ages for some reason, but only when --content functionality is active
+yann@desktop> git annex assist # doesn't pull all content from server because I have annex.synccontent=false set (too much space otherwise)
+# selectively get files I want (tedious, manual picking)
+yann@desktop> git annex get file1 file2 file3 ...
+"""]]
+
+## Workaround
+
+One can script the following to only sync the recently touched files:
+
+[[!format  bash """
+# Specifying a git rev range by having `git diff` figure out the details
+yann@desktop> git diff --name-only HEAD~20  | xargs -d'\n' git annex get
+# Specifying a time range
+yann@desktop> git log -p --since="1 week ago" | grep -e '^[+-]\{3\}' | cut -c5- | grep -vx '/dev/null' | cut -c3- | sort -u | xargs -d'\n' git annex get 
+"""]]
+
+This kinda works but...
+
+- is fragile shell scripting
+- doesn't like deleted files that much (they get handed to git-annex, which complains that those don't exist)
+- is two very separate solutions for the same thing: only operating on recent files
+
+## Proposal
+
+How about a `--recent` or `--since` or `--revs` etc. option which you can hand either a commit(range) or a `git log --since`-compatible string like `1 week ago`, which will cause git-annex to only consider those files for `get`ing or `drop`ing or `sync`ing or whatnot?
+
+I observed that `git annex sync --content` is often very much slower than `git annex sync --no-content` (without the time the actual syncing takes naturally), apparently because it needs to check a whole lot of files for syncing necessity. If that is the case, then a `--since` option could result in a speed improvement as only a very small amount of files would need to be checked for.
+
+Also, it would be awesome if one could say `git annex assist|sync --since=yesterday` and one would end up with a perfectly synced repo and the files touched yesterday being available. This is a situation I find myself needing on a daily basis.
diff --git a/doc/todo/Adding_a_matcher_for___39__recently_touched_files__39__/comment_1_bcb54e40904b04006dd7f8962add6994._comment b/doc/todo/Adding_a_matcher_for___39__recently_touched_files__39__/comment_1_bcb54e40904b04006dd7f8962add6994._comment
new file mode 100644
index 0000000000..688e16cfad
--- /dev/null
+++ b/doc/todo/Adding_a_matcher_for___39__recently_touched_files__39__/comment_1_bcb54e40904b04006dd7f8962add6994._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-05T21:12:07Z"
+ content="""
+There's a plan for speeding up sync --content (and `assist`) at
+<https://git-annex.branchable.com/todo/Incremental_git_annex_sync_--content_--all/>
+
+That method is farly similar, and it wouldn't need the user to specify
+an additional matching option to get the speedup.
+
+I do think this could be a useful option to have though. (It would not be
+possible to implement it as a matcher, but that's an implementation
+detail.)
+"""]]
diff --git a/doc/todo/Adding_unmatched_files_to_a_view.mdwn b/doc/todo/Adding_unmatched_files_to_a_view.mdwn
new file mode 100644
index 0000000000..6babf5bdd7
--- /dev/null
+++ b/doc/todo/Adding_unmatched_files_to_a_view.mdwn
@@ -0,0 +1,15 @@
+Hey joey,
+
+👀 Views are **really** cool, thanks again for this great idea. It makes managing the metadata of annexed files really fun as you can just drag files around and create, rename or delete folders.
+
+What would make it perfect is if there was a possibility to optionally add unmatched files to a view, e.g. into a specially-named folder (like `unmatched`, `___unmatched___` or `?????` or even configurable). Otherwise, unmatched files are not accessible from the view, so they can't be sorted into metadata from there.
+
+Currently this is possible by default-setting the field you want to view with `git annex metadata --force --set 'myfield?=???'`. Then, these objects will appear in the `???` folder with `git annex view myfield='*'`. But that forcefully adds a value to the field, which might not be desired.
+
+What do you think? Is something like `git annex view --show-unmatched '???'` worth it?
+
+Thanks again for git-annex, I love it, it's so versatile... 💛
+
+Yann
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/Adding_unmatched_files_to_a_view/comment_1_dee34c34b2df1d430a4f6c2792d35e28._comment b/doc/todo/Adding_unmatched_files_to_a_view/comment_1_dee34c34b2df1d430a4f6c2792d35e28._comment
new file mode 100644
index 0000000000..3d393c4399
--- /dev/null
+++ b/doc/todo/Adding_unmatched_files_to_a_view/comment_1_dee34c34b2df1d430a4f6c2792d35e28._comment
@@ -0,0 +1,52 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-02-07T16:44:08Z"
+content="""
+The existing support for "field!=value" kind of hints at a direction for
+this. If that supported globs (which it does not despite some now fixed docs
+saying it did), you could imagine this as a view where you want both files
+with an author and files without:
+
+	git-annex view author=* author!=*
+
+Although, it seems "!=*" would be somehow special, because "author!=Joey"
+would not mean that you want to put everything not authored by me in the
+no-author directory! So perhaps using glob syntax for this is not the right
+choice.
+
+How about:
+
+	git-annex view author?=*
+
+Where the '?' means make a directory for files that don't have the field
+set at all. So "author?=Joey" makes one directory for files authored by me,
+and one directory for files with no author; and all files with other
+authors are not included in the view.
+
+('field?=glob' also seems a good choice because it rhymes with 
+`git-annex metadata --set field?=value`)
+
+----
+
+I was going to say it seems better to avoid having any special directory
+name if possible, and just put files that lack a field in the parent
+directory that contains the directories for values of that field. But,
+thinking that through, I found a big problem with it. Consider this:
+
+	git-annex view author=* author!=* year=* year!=*
+
+If a file has a year set but no author, it would need to be left in the top
+directory in this view. But then if it were moved to author/, it would
+have an author but no year, and git-annex would have to remove the year
+that was set. Because it can't differentiate that from a file that was in
+author/year/ and got moved to author/ in order to remove the year.
+
+Using a special directory name for unset does avoid that problem.
+
+The name would have to be configurable, since any value might be a valid
+valid for some type of metadata out there. I'd probably lean toward a
+default like '_' just because it avoids defaulting to an English word, and
+a name like '?' seems like asking for trouble with unsafe shell
+globbing.
+"""]]
diff --git a/doc/todo/Adding_unmatched_files_to_a_view/comment_2_271f37d6c3e0f61324f9f50cb9cf24c7._comment b/doc/todo/Adding_unmatched_files_to_a_view/comment_2_271f37d6c3e0f61324f9f50cb9cf24c7._comment
new file mode 100644
index 0000000000..c5104e48a9
--- /dev/null
+++ b/doc/todo/Adding_unmatched_files_to_a_view/comment_2_271f37d6c3e0f61324f9f50cb9cf24c7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-02-07T20:19:29Z"
+ content="""
+Implemented this! Using the "field?=*" syntax described.
+With the directory configurable by annex.viewunsetdirectory
+"""]]
diff --git a/doc/todo/Adding_unmatched_files_to_a_view/comment_3_2e2a15ffc429db4b09215e7a7118e502._comment b/doc/todo/Adding_unmatched_files_to_a_view/comment_3_2e2a15ffc429db4b09215e7a7118e502._comment
new file mode 100644
index 0000000000..428273a962
--- /dev/null
+++ b/doc/todo/Adding_unmatched_files_to_a_view/comment_3_2e2a15ffc429db4b09215e7a7118e502._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 3"
+ date="2023-02-07T20:54:48Z"
+ content="""
+Oh joey, you're just awesome! 🎉 Thank you so much! I'll try it as soon as I can. 😀
+"""]]
diff --git a/doc/todo/Adressing_.gitattributes_inefficiency.mdwn b/doc/todo/Adressing_.gitattributes_inefficiency.mdwn
new file mode 100644
index 0000000000..a668a6d952
--- /dev/null
+++ b/doc/todo/Adressing_.gitattributes_inefficiency.mdwn
@@ -0,0 +1,22 @@
+## The Problem
+
+Apparently, `.gitattributes`-based configuration (of e.g. `numcopies`, `largefiles`, `addunlocked` (not even implemented due to the inefficienty), etc.) is slow as every file needs to be queried individually for its attributes (`git check-attr` under the hood, I guess).
+
+## The Motivation
+
+From a user's perspective, `.gitattributes`-based configuration has several benefits over the `git annex --set annex....` approach:
+
+- `.gitattributes` can differ between branches
+- `.gitattributes` lists file name matches much more easily readable, while e.g. `git annex --set annex.largefiles 'include=*.txt and include=*.md and include=*.bla and mimetype shenanigans and largerthan and whatnot...'` gets confusing quickly.
+- `.gitattributes` nests well in subdirs, enabling quite concise and fine-grained control (e.g. all files in THAT folder should be annexed, but if I delete the folder at some point, nvm, my `git config --get annex.largefiles` won't stay cluttered with that path config)
+
+Furthermore, Datalad [relies on `.gitattributes` configuration](https://git-annex.branchable.com/todo/annex.addunlocked_in_gitattributes/#comment-431d5040eac3b9a01d97724e25194f17) to specify the backend and e.g. the `text2git` procedure
+
+## Suggestion
+
+Couldn't the [separate-git-tree-for-diffing-technique you used lately to speed up repeated imports](https://git-annex.branchable.com/devblog/day_649-650__speeding_up_repeated_imports/) be used to cache `.gitattributes` for all (or relevant) files in a git tree (e.g. have the same paths in that tree but file contents are the attributes), querying the attributes is a matter of quering this tree and updating them just requires re-querying the touched paths.
+
+One problem I see with this tough is that it wouldn't be possible to cache the user's `.git/info/attributes` settings, which can change independently.
+
+[[!tag confirmed]]
+[[!tag projects/datalad/potential]]
diff --git a/doc/todo/Adressing_.gitattributes_inefficiency/comment_1_335b8d3c5a903c1e83a7f84b7bfc2998._comment b/doc/todo/Adressing_.gitattributes_inefficiency/comment_1_335b8d3c5a903c1e83a7f84b7bfc2998._comment
new file mode 100644
index 0000000000..aef451c3fc
--- /dev/null
+++ b/doc/todo/Adressing_.gitattributes_inefficiency/comment_1_335b8d3c5a903c1e83a7f84b7bfc2998._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-06-26T14:53:36Z"
+ content="""
+I think that the most likely way to speed it up is for git-annex to include
+its own .gitattributes parser. It could then cache .gitattributes files,
+probably in memory for a single command would be sufficient.
+
+Stracing `git check-attr --stdin` shows it has a small in-memory cache.
+And it is pretty fast. The problem is that its batch interface is not well
+suited to querying multiple different gitattributes, and the roundtrips
+through stdin are not very fast compared with what could be a very quick
+in-memory calculation.
+
+See [[todo/annex.addunlocked_in_gitattributes]] for a currently rejected
+todo that it would probably make sense to revisit if this were implemented.
+That todo's comments also have some information about gitattributes query
+speed and other arguments in favor of supporting them for more stuff,
+including <https://github.com/datalad/datalad/issues/5383#issuecomment-770108778>.
+
+I've always felt a gitattributes parser might be worth doing. But
+the pattern syntax used by git is pretty complicated, and it would need to
+imitate it perfectly.
+
+Anyway, if a patch doing this landed in my inbox, (or someone wanted to fund
+a medium sized project), I think I'd accept it. So I'll confirm this todo.
+"""]]
diff --git a/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from.mdwn b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from.mdwn
new file mode 100644
index 0000000000..5d5a01e89e
--- /dev/null
+++ b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from.mdwn
@@ -0,0 +1,14 @@
+ATM, special remotes store content (keys) in a keystore which has no reflection of original files hierarchy.
+
+In many cases though it is plausible and reasonable to replicate original files hierarchy, e.g. when uploading path/file1.ext, have it stored on a remote also under such name with additional part of the path to allow for multiple versions, e.g. path/file1-Key[:5].ext (collision is possible but unlikely) or path/file1.ext/Key . This way we could replicate initial files hierarchy on a special remote, making it useful/usable without annex.  I guess (didn't check yet) that File in TRANSFER STORE request points to original file location (not resolved key location), so we can have information about original sample location within special remote.  Since it would be virtually impossible (or expensive to locate) to retrieve content solely by a Key, we could use URLs mechanism to associate given uploaded Key with a new custom URL (e.g. custom-schema:path-file1.ext/Key) so later this special remote could provide the content by claiming that url.  Sure thing custom remote could just use 'addurl' call independently within a call to "TRANSFER" to it, but I wondered if may be protocol could be adjusted to support
+
+TRANSFER-SUCCESS STORE Key URL
+
+response when upon STORE success special remote provides a url under which content should be registered available from.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> I think this was trying to implement something like what `git annex
+> export`, and since that's implemented now, we shouldn't need to worry
+> about this. [[done]] --[[Joey]]
diff --git a/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_1_9f4245bd016f9283464a25698563786c._comment b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_1_9f4245bd016f9283464a25698563786c._comment
new file mode 100644
index 0000000000..1976eda523
--- /dev/null
+++ b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_1_9f4245bd016f9283464a25698563786c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-10-26T17:29:46Z"
+ content="""
+Well no, the filename passed to "TRANSFER STORE" is wherever the content
+of the file is, in most circumstances it will not be a file in the working
+tree.
+
+(And even if the filename is a worktree file in some case, the special
+remote needs to support storing multiple versions of a file. So trying to
+use the name used in the working tree on the special remote seems very
+problimatic.)
+
+In any case, the external special remote protocol already has
+`SETURLPRESENT` which can be used if a TRANSFER STORE makes a key be
+available at an url.
+"""]]
diff --git a/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_2_34d1eab194b7913dd453131d9187287a._comment b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_2_34d1eab194b7913dd453131d9187287a._comment
new file mode 100644
index 0000000000..c99ddd8ca0
--- /dev/null
+++ b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_2_34d1eab194b7913dd453131d9187287a._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ avatar="http://cdn.libravatar.org/avatar/8122123b4c2bc77187e32d7e025f7d445d7a08de1ba532237876a31159ac01da"
+ subject="how to get ahold of the filename?"
+ date="2016-10-27T10:10:24Z"
+ content="""
+SETURLPRESENT -- sounds like could be used indeed, but
+
+- *Note that this does not make git-annex think that the url is present on the web special remote.* -- so does it mean that this git/annex repo will not be able to download from that URL (which could be just a simple public http:// url) without having this special remote available?
+- *The readonly=true parameter makes git-annex download content from the urls recorded earlier by SETURLPRESENT.*  -- so otherwise URL would not be used?  a bit confused
+
+**\"remote needs to support storing multiple versions of a file\"**
+
+SURE (e.g. as I have described before)
+
+**\"in most circumstances it will not be a file in the working tree\"**
+
+could then there be a reasonable (scalable, via git annex interface) way to discover the (original) path(s) within repository which was given to \"git add PATH\"?
+
+Once again -- the idea is to make some special remotes useful on their own without relying on having an annex and original git/annex repository to associate those with specific files.
+
+Related:
+I see that there is now also SETURIPRESENT.  Is there difference how annex handles URIs in comparison to URLs? in an example which I saw with ipfs: URI.  it feels that those are still URLs as prescribing \"how\" content should be retrieved (via ipfs). We have used similarly addurl command to register our urls for content from archives (e.g. dl+archive:MD5E-s2416581890--662e0713d0ce42bcdbadb8251b893b8a.tgz#path=ds001/sub-01/anat/sub-01_T1w.nii.gz)
+"""]]
diff --git a/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_3_f667aa26dadadede318d31176292102d._comment b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_3_f667aa26dadadede318d31176292102d._comment
new file mode 100644
index 0000000000..ba7c8ded88
--- /dev/null
+++ b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_3_f667aa26dadadede318d31176292102d._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""SETURLPRESENT"""
+ date="2016-10-31T18:51:07Z"
+ content="""
+git-annex does not keep track of which urls belong to which remote.
+Urls are, after all, Universal; it shoudn't matter which remote
+set an url.
+
+So, if `SETURLPRESENT` was used, and if git-annex thinks that the web
+special remote is recorded as having the content, it will try to download
+from that url, as well as any other urls that might be set.
+
+But, `SETURLPRESENT` does not make it think that the web special remote
+has the content. So, if the special remote that git-annex does think has to
+content is not enabled, `git annex get` won't try the web special remote.
+
+So, what you can do is run `git annex setpresentkey $key 00000000-0000-0000-0000-000000000001`
+to make it think  the web special remote has the url after `SETURLPRESENT`.
+Then it'll be the same as if `addurl` had been used; it will download from
+the web.
+
+(There's also a way to enable a external special remote in readonly mode.
+In this mode, the special remote program does not have to be in PATH, and
+when git-annex wants to get content from the remote it will download
+content from any urls.)
+
+(The difference with `SETURIPRESENT` is that it's assumed the URI cannot
+be downloaded via HTTP/FTP. So, while `git annex whereis` displays
+URIs, git-annex won't try to download them itself.)
+"""]]
diff --git a/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_4_16d30e86132d6a3cefaa8e2fecbda7ca._comment b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_4_16d30e86132d6a3cefaa8e2fecbda7ca._comment
new file mode 100644
index 0000000000..ccef300fc4
--- /dev/null
+++ b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_4_16d30e86132d6a3cefaa8e2fecbda7ca._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""associated files"""
+ date="2016-10-31T19:12:56Z"
+ content="""
+git-annex keeps track of the AssociatedFile, which (when available) is 
+the worktree file corresponding to the Key that's being operated on.
+
+This information is not exposed in the external special remote interface.
+I'm worried that, if it were, people would try to do stuff that
+just can't work, like
+<http://git-annex.branchable.com/todo/dumb__44___unsafe__44___human-readable_backend/>
+
+Worktree files can be renamed or deleted or copied at any time and can have
+multiple versions, and any special remote that used this information to try
+to create something that resembles the worktree would have massive
+problems.
+
+I am having a hard time thinking of any use that an external special remote
+could make of the information that would not be a mistake.
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote.mdwn b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote.mdwn
new file mode 100644
index 0000000000..a67469d545
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote.mdwn
@@ -0,0 +1,34 @@
+Per our brief discussion ATM git-annex allows to prioritize URLs only by assigning them to be handled by different special remotes and having different costs for those different remotes.
+
+This doesn't allow for e.g. prioritization within built-in special "web" remote which is the most frequent use case. Our use case:
+
+
+```
+(base) dandi@drogon:/mnt/backup/dandi/dandizarrs/ea8c43c7-757e-4653-8e4a-a6d356120836$ git annex whereis 0/0/0/3/6/169
+(recording state in git...)
+whereis 0/0/0/3/6/169 (2 copies)
+        00000000-0000-0000-0000-000000000001 -- web
+        86da9d10-da54-4371-8d6f-7559c6a236f5 -- dandi@drogon:/mnt/backup/dandi/dandizarrs/ea8c43c7-757e-4653-8e4a-a6d356120836 [here]
+
+  web: https://api.dandiarchive.org/api/zarr/ea8c43c7-757e-4653-8e4a-a6d356120836.zarr/0/0/0/3/6/169
+  web: https://dandiarchive.s3.amazonaws.com/zarr/ea8c43c7-757e-4653-8e4a-a6d356120836/0/0/0/3/6/169?versionId=h3qb0rOswsssHxEdfN8QAWUMoVhddQrY
+ok
+
+```
+
+where we have API-server based URL -- we do not want to access unless really really needed (would be the slowest, would bring load to the server etc), and then direct access to public bucket -- fastest (unless some other local remote has it even better).
+
+Joey envisioned potentially being able to assign priorities via e.g.
+
+    git-annex enableremote web url-priority-1=s3.amazonaws.com/ url-prority-2=/api.dandiarchive.org/
+
+but I also wondered if there could just be some way to provide costs (or adjustments to costs) for different URLs so they all become considered while considering costs across remotes?
+
+E.g. may be I have a URL which is fast (s3 bucket), then I have bunch of average regular remotes with decent speed (e.g. dropbox etc), and then URL to some slow archive (API server). Both urls are served by `web` remote, and there would be no way to "order" all data access schemes/remotes in the optimal sequence of costs unless different URLs could have different costs considered along with different remotes.
+
+PS somehow I have some odd memory of seeing some config option to provide git-annex a script which would output cost given a URL... I disliked that approach since it would require me to code the script, and thus didn't use it. Did I dream it up? 
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_10_ff4c23b4ccaf649a9914f4aa4435968d._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_10_ff4c23b4ccaf649a9914f4aa4435968d._comment
new file mode 100644
index 0000000000..3d6f075d43
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_10_ff4c23b4ccaf649a9914f4aa4435968d._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2023-01-10T18:43:38Z"
+ content="""
+I think this todo is not fully done yet, because every web special
+remote that is split out this way still needs to have its cost
+configured in each clone.
+
+So this seems to be pointing to needing a global way to configure
+the  default cost of a special remote, similar to `git-annex config`.
+Local configs would of course need to override that.
+
+One way that might make sense is to add a cost=N setting to all special
+remotes. Then when generating the Remote, it can just look at the value
+set there, and use that for Remote.cost. Simple and efficient too.
+
+(That assumes that only special remotes should have their default cost
+be configurable, not git repositories. Which seems right, since
+the same git repo can have different costs depending on whether it's
+accessed locally or remotely, etc.)
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_11_a7087acb84b3139418c597496e18f4a1._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_11_a7087acb84b3139418c597496e18f4a1._comment
new file mode 100644
index 0000000000..4b01ae9e22
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_11_a7087acb84b3139418c597496e18f4a1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2023-01-12T17:38:38Z"
+ content="""
+Went ahead and implememented cost=, so now all you need is:
+
+	git-annex initremote --sameas=web dandiapi type=web urlinclude='*//api.dandiarchive.org/*' cost=300
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_12_69e39ee8140ef0cafd1b0f21be6a8d37._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_12_69e39ee8140ef0cafd1b0f21be6a8d37._comment
new file mode 100644
index 0000000000..f2431bfc40
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_12_69e39ee8140ef0cafd1b0f21be6a8d37._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 12"
+ date="2023-01-12T20:48:47Z"
+ content="""
+Great, thanks!  Should I also `urlexclude` that URL somehow from regular web remote so it is not considered by `web` remote with lower cost?  
+or for each url you would first see which remotes handle it and choose the one with highest cost for that url to be considered?
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_13_afb7fb3750e3b16bf144c52ffc68c153._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_13_afb7fb3750e3b16bf144c52ffc68c153._comment
new file mode 100644
index 0000000000..6d931d9771
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_13_afb7fb3750e3b16bf144c52ffc68c153._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2023-01-16T16:57:52Z"
+ content="""
+You do not need to `urlexclude` from regular web remote,
+it will automatically exclude urls that are an `urlinclude`
+of some other web remote.
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_1_f2172080e8e3e324a739d8769dca2ed0._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_1_f2172080e8e3e324a739d8769dca2ed0._comment
new file mode 100644
index 0000000000..aae4124bea
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_1_f2172080e8e3e324a739d8769dca2ed0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="satra"
+ avatar="http://cdn.libravatar.org/avatar/d3afc58453bc273dc015254e1d9581b3"
+ subject="use list order for cost"
+ date="2023-01-06T19:36:07Z"
+ content="""
+as a starting point is order an implicit notion of cost? so could having s3 before dandi achieve the expected outcome. try s3 first then try api?
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_2_1ab2634c8a7058c5aa09f1ba72be3471._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_2_1ab2634c8a7058c5aa09f1ba72be3471._comment
new file mode 100644
index 0000000000..a8680693d6
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_2_1ab2634c8a7058c5aa09f1ba72be3471._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-01-09T18:25:56Z"
+ content="""
+It does happen to try the urls in the order listed in the log file.
+
+With that said, the order of lines in files in the git-annex branch is
+not guaranteed to be preserved when eg, merging..
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_3_6970e60b7d826beb025fda452cc1bc13._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_3_6970e60b7d826beb025fda452cc1bc13._comment
new file mode 100644
index 0000000000..8a10c800a9
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_3_6970e60b7d826beb025fda452cc1bc13._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-01-09T18:27:36Z"
+ content="""
+See previous discussion in the since-closed todo 
+[[assign_costs_per_URL_or_better_repo-wide_(regexes)]].
+
+In that I suggested using --sameas, and yarikoptic thought the datalad
+special remote could use that to be used to handle urls and do its own
+prioritization. I suppose that probably didn't get done in datalad.
+
+But I do like the idea of using --sameas. It avoids several problems
+with providing "url-priority-N=" configs to the web special remote:
+
+* Two clones could have url-priority-1 set to different values, and merging
+  the remote.log would lose one of them.
+* It may be that one group of urls is slow from repo A, but fast from repo
+  B. So there needs to be a local override, and we already have that
+  for remote costs.
+* Using --sameas means that cost configs can be used, rather than
+  adding a separate config that's essentially for the same thing.
+
+So, what if it were possible to initremote versions of the web special
+remote that were limited to particular urls, and skipped over any other
+urls:
+
+	git-annex initremote --sameas web s3public type=web urllimit=s3.amazonaws.com/ autoenable=true
+	git config remote.s3public.annex-cost 150
+
+	git-annex initremote --sameas web dandiapi type=web urllimit=/api.dandiarchive.org/ autoenable=true
+	git config remote.dandiapi.annex-cost 250
+
+As well as adding the urllimit= config, that would need the web special
+remote to allow initremote of other instances of it. Currently, that will
+fail:
+
+	git-annex initremote --sameas web web2 type=web autoenable=true
+	git-annex: not supported
+	CallStack (from HasCallStack):
+	  error, called at ./Remote/Web.hs:32:19 in main:Remote.Web
+	failed
+	initremote: 1 failed
+
+Which is not ideal when it comes to using autoenable=true because using
+a current git-annex after this gets implemented would try to autoenable
+the remote, and display all that. Compare with how autoenable handles
+remote types it does not know -- it silently skips them. This could be avoided
+by using something other than type=web for these.
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_4_8fe7f4c03784f519fd184e6d59fb0b2a._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_4_8fe7f4c03784f519fd184e6d59fb0b2a._comment
new file mode 100644
index 0000000000..e7ba9241ad
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_4_8fe7f4c03784f519fd184e6d59fb0b2a._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-01-09T20:48:18Z"
+ content="""
+I've implemented support for multiple web special remotes, 
+and have added configurations urlinclude= and urlexclude=
+(both case-insensitive globs).
+
+Example use:
+
+	git-annex initremote --sameas=web fastweb type=web urlinclude='*//fasthost.com/*' autoenable=true
+	git config remote.fastweb.annex-cost 150
+
+And then `git-annex get --from fasthost` will only use urls on that host,
+not any other urls. `git-annex get --from web` will still use any urls.
+The cost of 150 makes `git-annex get` use fasthost before web.
+
+That's enough to handle the example you gave, just use
+`urlinclude='*//dandiarchive.s3.amazonaws.com/*'
+
+---
+
+But, I don't think this is quite sufficient. Because it should also be
+possible to deprioritize urls. And there's not a good way to yet.
+
+In particular, this doesn't work:
+
+	git-annex initremote --sameas=web slowweb type=web urlinclude='*//slowhost.com/*' autoenable=true
+	git config remote.slowhost.annex-cost 300
+
+Because when getting a file, the main web special remote is tried before
+this high-cost slowhost one, and will use any url, including
+slowhost.com urls.
+
+Now you can instead do this:
+
+        git-annex initremote --sameas=web fastweb type=web urlexclude='*//slowhost.com/*' autoenable=true
+        git config remote.fasthost.annex-cost 150
+
+But when there's a second slow host, that approach falls down, because you
+can't specify urlexclude= twice. And even if you could, there would be a
+distributed configs merging issue same as discussed in comment #3.
+
+I think what's needed is for the main web special remote to notice that a
+web remote such as fastweb or slowweb exists, and automatically exclude
+from using the urls that other web remote is configured to use. Which
+will be a little bit tricky to implent, but seems doable.
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_5_4d8e8abe8b31174ccc536387a96b0228._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_5_4d8e8abe8b31174ccc536387a96b0228._comment
new file mode 100644
index 0000000000..babcd48e03
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_5_4d8e8abe8b31174ccc536387a96b0228._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2023-01-09T22:04:11Z"
+ content="""
+> Because when getting a file, the main web special remote is tried before this high-cost slowhost one, and will use any url, including slowhost.com urls.
+
+can't I just give the entire `web` remote the highest cost so it is then considered last by default and all the prior \"*web\" remotes with custom costs for fast/slow would be considered in their \"weighted\" fashion?
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_6_b6261ff8e442ee6df79834844f6b3565._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_6_b6261ff8e442ee6df79834844f6b3565._comment
new file mode 100644
index 0000000000..cacfc2368a
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_6_b6261ff8e442ee6df79834844f6b3565._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="Concern"
+ date="2023-01-10T13:17:29Z"
+ content="""
+BTW, would it be digested well by older versions of git-annex? How would they behave?
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_7_50516fc4b3c315a9e5d771777fb27e9f._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_7_50516fc4b3c315a9e5d771777fb27e9f._comment
new file mode 100644
index 0000000000..c0408483c8
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_7_50516fc4b3c315a9e5d771777fb27e9f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2023-01-10T15:43:50Z"
+ content="""
+Older versions of git-annex will fail with the error shown in comment #3
+when trying to enable the second instance of the web remote.
+
+When autoenabling, it won't be a fatal error, but the ugly error message
+will still be shown.
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_8_87ad54a694bde70713e71acd4e074894._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_8_87ad54a694bde70713e71acd4e074894._comment
new file mode 100644
index 0000000000..ff4a17e810
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_8_87ad54a694bde70713e71acd4e074894._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-01-10T15:45:03Z"
+ content="""
+Setting default web to higher cost than the other web remotes doesn't avoid
+this problem: If you have a bunch of urls on different sites that are an
+averge speed, and one site that is slow, you'd have to make a new web remote
+for each individual site, and for each new site.
+"""]]
diff --git a/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_9_4029b264ea2b0d47e6949f832af69282._comment b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_9_4029b264ea2b0d47e6949f832af69282._comment
new file mode 100644
index 0000000000..4c71e2526d
--- /dev/null
+++ b/doc/todo/Allow_for_URLs_prioritization_WITHIN___40__web__41___remote/comment_9_4029b264ea2b0d47e6949f832af69282._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2023-01-10T18:41:09Z"
+ content="""
+100-some lines of code later, I got deprioritizing urls working well.
+Eg:
+
+	git-annex initremote --sameas=web slowweb type=web urlinclude='*//slowhost.com/*'
+	git config remote.slowweb.annex-cost 300
+
+Now when the regular "web" special remote is asked to get a file,
+it will skip any urls that match the urlinclude of other web remotes.
+So, it won't use the slowhost.com urls, leaving those for slowweb to later
+use if necessary.
+"""]]
diff --git a/doc/todo/Allow_globally_limiting_filename_length.mdwn b/doc/todo/Allow_globally_limiting_filename_length.mdwn
new file mode 100644
index 0000000000..18e87c32a5
--- /dev/null
+++ b/doc/todo/Allow_globally_limiting_filename_length.mdwn
@@ -0,0 +1,11 @@
+I have some Git Annex repos that I keep copies of on both NTFS on Linux and on ecryptfs (which Ubuntu uses for home directory encryption) on Linux. Now, ecryptfs allows each path component of a filename to be only up to 140-ish characters, because it has to encrypt that filename, add some encryption info to it, and store it inside another filename on a backing ext4 filesystem (which limits path components to 255 characters).
+
+Several times now I've added a bunch of stuff to my annex on the NTFS checkout, where path components are allowed to be longer than 140 characters, synced it over to my other annex checkout on ecryptfs, and then had Git Annex fail during the sync, trying to create these empty symlinks with path components too long for the filesystem it is on. When in this state, I don't really know how to fix it. I can't just "git mv" the offending file to a valid name, both because "git mv" needs the source file to be on disk in the first place and because the failed "git checkout" leaves my repo thinking it has thousands of untracked files (because some stuff did get created, but git refused to officially move to the commit it was trying to check out, because the checkout failed).
+
+I am looking for a solution for this inside Git Annex. The simplest thing, I think, would be to set a max path component length for the whole set of repos, so I could get an error when I go to "git annex add" on the NTFS checkout that the filenames being added are too long for some of the repos that will eventually want to check them out. Is it possible to do this with a pre-commit hook somehow?
+
+The next simplest thing would be for Git Annex to look at the filesystem it is running on and do something smarter than exploding and leaving my repo in a weird out-of-sync state if some of the filenames it wants to create can't be created. Maybe it should fail the sync earlier, in Git Annex itself rather than in git checkout. Maybe it should just leave those files out of the checkout, or force/allow me to rename them right then.
+
+The most complex thing would be to somehow make it work anyway and check out the symlinks under different, valid names. Perhaps it could just truncate those path components in the symlink view? There's already support for different metadata views; this would be sort of like that. You get a special view of the repo subject to the constraints of your filesystem.
+
+> [[rejected|done]] --[[Joey]]
diff --git a/doc/todo/Allow_remote_sync__42___and_ignore__42___in_git_annex_config.mdwn b/doc/todo/Allow_remote_sync__42___and_ignore__42___in_git_annex_config.mdwn
new file mode 100644
index 0000000000..506dfe1fba
--- /dev/null
+++ b/doc/todo/Allow_remote_sync__42___and_ignore__42___in_git_annex_config.mdwn
@@ -0,0 +1,12 @@
+I've been using git annex in a star topology (one NAS always available to all repositories) for the longest time but now want to interconnect the repositories on the "outside" aswell. A hurdle to that is that not all remotes will be online all the time (in fact some of them will rarely be online) but git annex expects them to be reachable via ssh at all times.  
+
+There is an escape hatch here in the form of the `remote.<remote>.annex-sync-command` and `remote.<remote>.annex-ignore-command` git config flags where you can script a liveness check.  
+However, in order to actually use that, you must set these options on each and every instance of the repository which is not feasible. Usually for cases like this, there is `git annex config` but it doesn't allow this setting.
+
+Could these become git annex config flags aswell?
+
+Alternatives:
+
+* A built-in liveness check with configurable optionality (though you'd probably want this setting on the git-annex branch aswell)
+
+Am I missing another way to do this without manually setting the commands perhaps?
diff --git a/doc/todo/Allow_remote_sync__42___and_ignore__42___in_git_annex_config/comment_1_7a55c03691a6b6738d1a0e2555cb4cea._comment b/doc/todo/Allow_remote_sync__42___and_ignore__42___in_git_annex_config/comment_1_7a55c03691a6b6738d1a0e2555cb4cea._comment
new file mode 100644
index 0000000000..9be581fbdb
--- /dev/null
+++ b/doc/todo/Allow_remote_sync__42___and_ignore__42___in_git_annex_config/comment_1_7a55c03691a6b6738d1a0e2555cb4cea._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-10-09T18:39:21Z"
+ content="""
+We can't put commands in `git-annex config` because cloning
+a git repository and using git(-annex) in it should not
+expose you to executing arbitrary code.
+
+It's not clear to me what kind of liveness check git-annex could do. A ssh
+host is not necessarily pingable.
+
+Configuring ssh to use ConnectTimeout=1 or something like that can help
+with long timeouts.
+"""]]
diff --git a/doc/todo/Android__58___add_a___34__Share_via__34___shortcut___34__Add_to_Annex__34__.mdwn b/doc/todo/Android__58___add_a___34__Share_via__34___shortcut___34__Add_to_Annex__34__.mdwn
new file mode 100644
index 0000000000..d04eee18d9
--- /dev/null
+++ b/doc/todo/Android__58___add_a___34__Share_via__34___shortcut___34__Add_to_Annex__34__.mdwn
@@ -0,0 +1 @@
+Having it named starting with "Add to ..." would improve its convenience visibility (would even position before "Add to Dropbox" ;) )
diff --git a/doc/todo/Android__58___add_a___34__Share_via__34___shortcut___34__Add_to_Annex__34__/comment_1_286279b96fc7940c9e7eeb0eb57cc279._comment b/doc/todo/Android__58___add_a___34__Share_via__34___shortcut___34__Add_to_Annex__34__/comment_1_286279b96fc7940c9e7eeb0eb57cc279._comment
new file mode 100644
index 0000000000..803f657f0f
--- /dev/null
+++ b/doc/todo/Android__58___add_a___34__Share_via__34___shortcut___34__Add_to_Annex__34__/comment_1_286279b96fc7940c9e7eeb0eb57cc279._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-05-08T18:59:08Z"
+ content="""
+We have a way to run the regular git-annex build for linux on Android in termux:
+<https://git-annex.branchable.com/tips/install_on_Android_in_Termux/>
+
+So you can use the x86 autobuild on android now. I don't currently have a
+mips autobuild, but you can build git-annex on a Debian mips system
+with "make linuxstandalone" and the resulting tarball should work with the
+above instructions on a mips android system, presumably.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__.mdwn b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__.mdwn
new file mode 100644
index 0000000000..a20f7955ee
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__.mdwn
@@ -0,0 +1,9 @@
+For a heavy tree it takes indeed quite a while.  And it is just wasteful if not just tree, but the entire repository does not have any unlocked files which is majority of the cases.  So I wondered if this operation could be avoided.
+
+E.g. following idea came to mind: git-annex could add some flag/beacon file (e.g. `has-no-unlocked`) within its `git-annex` branch which it would set upon initializing the `git-annex` branch, and which it would remove as soon as any path gets unlocked.  Then upon initial initialization of the clone'd worktree it could avoid this "Scanning" entirely if according to `git-annex` branch repository is still known to now carry any unlocked file.  It would not provide an ultimate solution which would be "tree specific" but at least it would provide remedy for majority of the cases (in our case) where there is no unlocked files.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> I think I've improved this all that it can reasonably be sped up,
+> so [[done]]. --[[Joey]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_10_41cf16d6d14d1551c43736f854da3d05._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_10_41cf16d6d14d1551c43736f854da3d05._comment
new file mode 100644
index 0000000000..1e72209654
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_10_41cf16d6d14d1551c43736f854da3d05._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="annex.supportunlocked=false"
+ date="2021-03-23T20:02:16Z"
+ content="""
+\"annex.supportunlocked=false does prevent installing smudge/clean filters\" -- then, do I understand correctly that, if it were a `git-annex-config` setting and `annex.supportunlocked=false` implied `annex.gitaddtoannex=false`, this would prevent inadvertently adding unlocked files?  Then, assuming \"typical\" repo usage, it would also prevent inadvertently merging unlocked files, since you'd
+have to add them first.
+
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_11_2ad0467b36d7e7be3b346dd54ba4f46b._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_11_2ad0467b36d7e7be3b346dd54ba4f46b._comment
new file mode 100644
index 0000000000..976842dddf
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_11_2ad0467b36d7e7be3b346dd54ba4f46b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2021-05-31T14:39:17Z"
+ content="""
+This got slower again since it now also has to scan locked files as well as
+unlocked. And so disabling smudge filters doesn't avoid it either.
+
+It should be possible to speed this up by streaming the ls-tree through
+cat-file, like is done in CmdLine.Seek (catObjectStreamLsTree). Speedup
+probably in the order of 2-3x.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_12_70c4c9f6c35acd7ca1134ac74356e5be._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_12_70c4c9f6c35acd7ca1134ac74356e5be._comment
new file mode 100644
index 0000000000..26af7699a3
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_12_70c4c9f6c35acd7ca1134ac74356e5be._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2021-05-31T16:30:11Z"
+ content="""
+Implemented streaming through git. In a repo with 100000 unlocked files,
+version 8.20210429 took 46 seconds, now reduced to 36 seconds.
+
+When the files are locked, of course the old version was faster
+due to being able to skip all symlinks, 2 seconds. The new version takes
+slightly less time than it does for unlocked files, 35 seconds.
+
+Now the git query and processing is only a few seconds of the total run time,
+writing information about all the files to sqlite is most of the rest,
+and may also be possible to speed up.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_13_440624874dd3697dd538655765f2b6a2._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_13_440624874dd3697dd538655765f2b6a2._comment
new file mode 100644
index 0000000000..e37504992c
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_13_440624874dd3697dd538655765f2b6a2._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2021-05-31T18:40:59Z"
+ content="""
+There was an unnecessary check of the current time per sql insert, removing
+that sped it up by 3 seconds in my benchmark.
+
+Also tried increasing the number of inserts per sqlite transaction from 1k
+to 10k. Memory use increased to 90 mb, but no measurable speed increase.
+
+I don't see much else that can speed up the sqlite part, without going deep
+into the weeds of populating sqlite databases without using sql, or using
+multi-value inserts ([like described here](https://medium.com/@JasonWyatt/squeezing-performance-from-sqlite-insertions-971aff98eef2).
+Both would prevent using persistent to abstract sql away, and would
+only be usable in this case, not speeding up git-annex generally, 
+so not too enthused.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_14_cf70ca1f6dac58c44ee3ece2199d25a9._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_14_cf70ca1f6dac58c44ee3ece2199d25a9._comment
new file mode 100644
index 0000000000..cd60c38771
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_14_cf70ca1f6dac58c44ee3ece2199d25a9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="startup scan for files"
+ date="2021-05-31T20:50:36Z"
+ content="""
+\"it now also has to scan locked files as well as unlocked\" -- can you remind, what necessitated this change?
+
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_15_06641815750038a0ed908d929868c1c3._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_15_06641815750038a0ed908d929868c1c3._comment
new file mode 100644
index 0000000000..0488fad8e1
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_15_06641815750038a0ed908d929868c1c3._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2021-05-31T21:49:35Z"
+ content="""
+[[bugs/indeterminite_preferred_content_state_for_duplicated_file]]
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_16_adf57675c5fa1047ee48b16dd356f4fe._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_16_adf57675c5fa1047ee48b16dd356f4fe._comment
new file mode 100644
index 0000000000..99de4ebdfd
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_16_adf57675c5fa1047ee48b16dd356f4fe._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="keys-to-paths db"
+ date="2021-05-31T23:15:21Z"
+ content="""
+The lengthy scan would only happen once -- when the worktree is first checked out -- and would be incremental from then on, right?
+But it would slow things down every time a new checkout of a large repo happens?  Maybe the scan could be done lazily, invoked when the results are first needed?
+Also, if you just need to know which keys are used more than once, maybe a Bloom filter of the keys used in the worktree would suffice, instead of a full keys-to-paths SQL db?
+
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_17_c41b669837be95b731bd68f1b3269fef._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_17_c41b669837be95b731bd68f1b3269fef._comment
new file mode 100644
index 0000000000..50ec39f1fe
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_17_c41b669837be95b731bd68f1b3269fef._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 17"""
+ date="2021-06-04T17:37:30Z"
+ content="""
+The scan could be done lazily, but there are situations that use the
+database where unexpectedly taking a much longer time than usual
+would be a real problem. For example "git add".
+
+The bloom filter idea does not work.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_18_4e1e8fd89ea9be43d89e72562236c979._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_18_4e1e8fd89ea9be43d89e72562236c979._comment
new file mode 100644
index 0000000000..2d9c0444a2
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_18_4e1e8fd89ea9be43d89e72562236c979._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="deferring the keys-to-files scan"
+ date="2021-06-07T16:11:00Z"
+ content="""
+>The scan could be done lazily, but there are situations that use the database where unexpectedly taking a much longer time than usual would be a real problem
+
+For unlocked files, certainly.  When `annex.supportunlocked=false`, it sounded like the only situation that uses the database is `drop --auto`, or a [[matching expression|git-annex-matching-options]] with `--includesamecontent/--excludesamecontent`?  (And maybe [[todo/git-annex_whereused]]).
+Personally I would prefer an unexpected delay in these rare cases, to a [delay](https://git-annex.branchable.com/bugs/significant_performance_regression_impacting_datal) in the more common case of checking out or switching branches.
+ 
+
+
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_19_b34a9cf4114ed943fe4ba2de78eb0bbc._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_19_b34a9cf4114ed943fe4ba2de78eb0bbc._comment
new file mode 100644
index 0000000000..b7bacf2f90
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_19_b34a9cf4114ed943fe4ba2de78eb0bbc._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2021-06-07T17:07:26Z"
+ content="""
+It can't know if there are unlocked files without doing this scan.
+
+Except for when annex.supportunlocked=false, but then that config option
+would have the side effect of making git-annex *slower* at some point after
+init, with the situations where it does hard to enumerate and probably
+growing. This would be a hard behavior to explain to the user.
+
+And there are numerous other points than the ones you listed where
+git-annex accesses the keys db and would trigger a deferred scan. Eg, anytime
+it might need to update a pointer file. Eg, when `git annex get` is run. 
+Avoiding using the keys db when annex.supportunlocked=false in all such
+cases in order to avoid the scan would be effectively the same complexity
+as continuing to support v5 repos, which I've NAKed before.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_1_94395a48d99e4737dd0ee28a597bfe70._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_1_94395a48d99e4737dd0ee28a597bfe70._comment
new file mode 100644
index 0000000000..63d2f37666
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_1_94395a48d99e4737dd0ee28a597bfe70._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-16T18:29:26Z"
+ content="""
+Hmm, this does a git ls-tree -r and parses it looking for files that are
+not symlinks. Each such file has to pass through cat-file --batch to see if
+it is unlocked.
+
+So I think this should be reasonably fast unless the repo has a lot of
+non-annexed files. Does your repo, or is it simply so large that ls-tree -r
+is very expensive? 
+
+Benchmarking here, a repo with 100,000 annexed files (all locked):
+the git ls-tree ran in 3 seconds; the init took 17 seconds overall,
+with most time needed to set up the git-annex branch etc.
+
+One speedup I notice that scanUnlockedFiles uses catKey,
+which first checks catObjectMetaData to determine if the file is so large
+that it's clearly not a pointer file (and so avoid catting such a large file).
+If the file size was known, it could instead use catKey', which would
+double the speed of processing non-annexed files, as well as actual locked
+files. To get the size, git ls-tree has a --long switch. (git still has
+to do some work to get the size since tree objects don't contain it, but
+it should be much less expensive than a round trip through
+catObjectMetaData. In my benchmark it doubled the git ls-tree time to add
+--long.) Implementing this will need adding support for parsing
+the --long output so I've not done it quite yet.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_20_e9a36e9600561201969c4d21499833af._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_20_e9a36e9600561201969c4d21499833af._comment
new file mode 100644
index 0000000000..ea193d0c2d
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_20_e9a36e9600561201969c4d21499833af._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 20"""
+ date="2021-06-07T19:22:03Z"
+ content="""
+Turns out git-annex init was running both scanAnnexedFiles and
+reconcileStaged, which after recent changes to the latter, both do
+close to the same scan when run in a fresh clone. So double work!
+
+Benchmarking with 100,000 files, git-annex init took 88 seconds.  
+Fixed not to use reconcileStaged it took 37 seconds.
+
+(Keeping reconcileStaged and removing scanAnnexedFiles it took 47 seconds.
+That makes sense; reconcileStaged is an incremental updater and is not
+able to use SQL as efficiently as scanAnnexedFiles.)
+
+---
+
+Also the git clone of that 100,000 file repo itself, from another repo on
+the same SSD, takes 9 seconds. git-annex init taking 4x as long as
+a fast local git clone to do a scan is not bad.
+
+This is EOT for me, but I will accept pathes if someone wants to make
+git-annex faster. 
+
+(Also see
+[[todo/display_when_reconcileStaged_is_taking_a_long_time]])
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_21_8f5dd9ba761e636ce5413da4e596296d._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_21_8f5dd9ba761e636ce5413da4e596296d._comment
new file mode 100644
index 0000000000..ee83200fcf
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_21_8f5dd9ba761e636ce5413da4e596296d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 21"""
+ date="2021-06-14T16:41:15Z"
+ content="""
+Note that the bug report the previous comment links to is not actually
+about the overhead of this scan.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_2_bd7c278922a52004540db79099e35763._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_2_bd7c278922a52004540db79099e35763._comment
new file mode 100644
index 0000000000..4d4e652a72
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_2_bd7c278922a52004540db79099e35763._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="install clean/smudge filter only when needed"
+ date="2021-03-18T15:47:02Z"
+ content="""
+On a related note, maybe some way to [not install git-annex's clean/smudge filter when all annexed files are locked](https://git-annex.branchable.com/todo/only_pass_unlocked_files_through_the_clean__47__smudge_filter/) could be found?  Maybe, a flag could be stored on the git-annex branch to indicate that a repo is locked-files-only?  My repos often are.  Or maybe a flag in .gitattributes could indicate this.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_3_c3f029b865bcd489d03bcf722dfa4e44._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_3_c3f029b865bcd489d03bcf722dfa4e44._comment
new file mode 100644
index 0000000000..6c7ddc92c5
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_3_c3f029b865bcd489d03bcf722dfa4e44._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-03-23T15:54:18Z"
+ content="""
+The idea of putting a flag in the git-annex branch means that every time
+the smudge filter gets run, it would have to check the git-annex branch to
+see if it needs to unset that flag. I do not want to make the smudge filter
+even slower than it is, and trading off a one-time (per repository) cost
+with an ongoing cost does not seem good.
+
+The flag would also be a source of problems in complex
+situations. Eg, someone could be operating on the repo w/o git-annex
+installed, merge in a branch that contains unlocked files, and push the
+result. Leading to the flag in the git-annex branch being left incorrectly
+set, and so causing breakage to someone who clones the repo later on.
+
+Also, a transient unlock/modify/add of a file leaves no unlocked files in
+the worktree, but the unlock would set the flag, so any performance benefit
+would need all users of the repo to avoid such workflows.
+
+So viable approaches seem to be to optimise the scanning as much as
+possible, and possibly to add some config to git-annex that avoids doing
+the scanning, which could be used if you happen to know your repo doesn't
+contain unlocked files.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_4_2cb31617bb7003c5bf0e5def358da0e4._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_4_2cb31617bb7003c5bf0e5def358da0e4._comment
new file mode 100644
index 0000000000..b525275114
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_4_2cb31617bb7003c5bf0e5def358da0e4._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-03-23T17:02:49Z"
+ content="""
+That catKey optimisation actually only helps if the tree has a lot of files
+that are not annex symlinks, but are either unlocked or not annexed. 
+If most of the files are locked, that would actually make the scan
+somewhere around twice as slow as it currently is. So not a worthwhile
+optimisation.
+
+Update: Now that the scan also scans for locked files to make the
+associated files include information about them, the catKey optimisation
+did make sense. Unfortunately, that does mean this scan got a little bit
+slower still, since it has to use git ls-tree --long.
+
+I don't see much else there that could be optimised. Possibly the
+ls-tree parser could be made faster but it's already using attoparsec
+so unlikely to be many gains.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_5_2aab5c685ad934486e60065b3c8da1bf._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_5_2aab5c685ad934486e60065b3c8da1bf._comment
new file mode 100644
index 0000000000..3cf9b89631
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_5_2aab5c685ad934486e60065b3c8da1bf._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-03-23T17:10:22Z"
+ content="""
+If we zoom out a bit, and also consider Ilya's desire to skip installing
+smudge/clean filters, maybe what you guys want is a way to tell git-annex
+that a particular repo does not use unlocked files, so git-annex can
+avoid expensive stuff needed to support them.
+
+So, I've added an `annex.supportunlocked` config that can be set to false
+before running `git-annex init`, and it will disable the smudge filters
+and skip this expensive scan.
+
+(The config will also let you measure the actual time this scan takes,
+which I'm still curious about, because I've not seen it being a majority of
+the init time, even in a large repository. Seems likely to me that init is
+doing other expensive things right after this scan, in particular setting
+up the git-annex branch, and that it may be those are what was really
+seeming slow to you.)
+
+The config as implemented does not prevent later adding unlocked files, and
+if you do that, git-annex will get confused and not make the content
+accessible until you change the config back and re-run git-annex init, or
+you lock the file.
+
+While the config could grow in scope to preventing adding
+unlocked files, it seems like probably a bad idea (and a whole lot of work).
+For one thing `git add` with a largefiles configuration would then
+need to prevent adding the file unlocked.. but it can't add it locked, and
+the smudge filter can't prevent git from adding the file -- so it would
+need to ignore the largefiles configuration and add the file to git. Which
+could be pretty suprising.
+
+And really there's no way for git-annex to enforce that a repo doesn't
+contain unlocked files. Even if this became a repo-global config (probably
+not a good idea), someone could merge new unlocked files from a repo that
+does, using just git. Or add them using an old version of git-annex. (Or
+just convert symlinks to unlocked files manually, it's not hard..) If
+setting this config, you're telling git-annex you don't expect there to be
+any unlocked file, and are ok with some minor breakage if there are some.
+
+Combining the config with `git-annex adjust --lock` would somewhat
+avoid such problems, although it's still possible to add files
+unlocked when in such a branch.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_6_a5089531b5d9bdcc90a07cb9d3f1da7d._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_6_a5089531b5d9bdcc90a07cb9d3f1da7d._comment
new file mode 100644
index 0000000000..648216813a
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_6_a5089531b5d9bdcc90a07cb9d3f1da7d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2021-03-23T18:43:30Z"
+ content="""
+>  I've added an annex.supportunlocked config that can be set 
+
+you are talking about a regular `git config` configuration variable? then FWIW it is of no use for the original use case of a user cloning an existing git-annex repo since I would have no clue if that repository contains any unlocked files or not.  It could indeed come handy for timing when desired to investigate.
+
+I am yet to appreciate how \"repo-global config\" situation would be different from handling any other git-annex manipulation within `git-annex` branch (e.g. of annex config there) where we already rely on git-annex to \"do the right thing\" (deciding on taking keys availability information based on timestamping etc).
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_6_e2718b6492d5da64a8bd6b13ad1cfa45._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_6_e2718b6492d5da64a8bd6b13ad1cfa45._comment
new file mode 100644
index 0000000000..c59aabe207
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_6_e2718b6492d5da64a8bd6b13ad1cfa45._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-03-23T19:15:23Z"
+ content="""
+Found a way to speed up git-annex init's setup of the git-annex branch when
+run in a clone of an existing repo. In a 100,000 file repo, it improved
+from 17s to 10s. I have a feeling that might have been what was really
+making it seem slow to you.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_7_71d3936dc37349392e6f7b0bd8292b7b._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_7_71d3936dc37349392e6f7b0bd8292b7b._comment
new file mode 100644
index 0000000000..264c24a5f2
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_7_71d3936dc37349392e6f7b0bd8292b7b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="annex.supportunlocked"
+ date="2021-03-23T19:30:39Z"
+ content="""
+Thanks for adding `annex.supportunlocked`!
+
+It seems to me that this is a repo property that you'd want to be consistent across clones, i.e. a candidate for a [[`git-annex-config`|git-annex-config]] setting.
+
+\"there's no way for git-annex to enforce that a repo doesn't contain unlocked files\" -- maybe, have [[`git-annex-fsck`|git-annex-fsck]] check that there are none if `annex.supportunlocked` is set?
+
+\"git add with a largefiles configuration... would need to ignore the largefiles configuration and add the file to git\" -- which the `annex.gitaddtoannex` config setting already does, so maybe just document that `annex.supportunlocked=false` implies `annex.gitaddtoannex=false`?  Could you then uninstall (or skip installing) the smudge/clean filters?
+
+\"someone could merge new unlocked files from a repo that does, using just git\" -- they can't do that inadvertently if the repo has a `git-annex-config` setting disallowing the adding of unlocked files.   If they manually override the repo setting, or \"convert symlinks to unlocked files manually\", they're doing something odd you can't plan for anyway.
+"""]]
diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_9_7ada8d7e9438f2740b700e2e54b045da._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_9_7ada8d7e9438f2740b700e2e54b045da._comment
new file mode 100644
index 0000000000..2dfec1fbf1
--- /dev/null
+++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_9_7ada8d7e9438f2740b700e2e54b045da._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-03-23T19:48:36Z"
+ content="""
+Just to be clear, annex.supportunlocked=false does prevent installing
+smudge/clean filters.
+"""]]
diff --git a/doc/todo/Bidirectional_metadata.mdwn b/doc/todo/Bidirectional_metadata.mdwn
new file mode 100644
index 0000000000..c455cf03ce
--- /dev/null
+++ b/doc/todo/Bidirectional_metadata.mdwn
@@ -0,0 +1,23 @@
+In one of my annexes I will g-a-add a (e.g.) zip file, extract and g-a-add its contents and then set metadata on "each side"..
+
+    git annex metadata -s extracted_from+=$key_for_original.zip files_from_zip/
+    git annex metadata -s extracted_to+=$key_for_file1 original.zip
+    git annex metadata -s extracted_to+=$key_for_file2 original.zip
+    git annex metadata -s extracted_to+=$key_for_file3 original.zip
+    git annex metadata -s extracted_to+=$key_for_file4 original.zip
+
+This means that if the content for a file in files_from_zip/ is lost, you can easily find that it came from original.zip (which may not be lost) *or any other zip in that annex that also contains that file*.
+
+I was wondering if this would be worth building in?
+
+    git annex metadata --fromto original.zip files_from_zip/
+
+There are other situations this is useful (and I use), for example, when I convert an annexed file to another format, I record the "source" and "target" keys against each other. I suppose a very general name would be:
+
+    git annex metadata --parentchild original.zip files_from_zip/
+    git annex metadata --parentchild original.wav compressed.flac
+    git annex metadata --parentchild original.svg compressed.png
+
+and this would set 'parent' and 'child' metadata respectively.
+
+[[!tag needsthought]]
diff --git a/doc/todo/Bidirectional_metadata/comment_1_9974d17e407fab14b12399016d3d66c2._comment b/doc/todo/Bidirectional_metadata/comment_1_9974d17e407fab14b12399016d3d66c2._comment
new file mode 100644
index 0000000000..011482b803
--- /dev/null
+++ b/doc/todo/Bidirectional_metadata/comment_1_9974d17e407fab14b12399016d3d66c2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2017-05-09T14:25:50Z"
+ content="""
+It could also be possible to extend 'whereis' (maybe with a '--check-metadata' option?) to let the user know that *some* version (source or derivative) may be available.
+"""]]
diff --git a/doc/todo/Bidirectional_metadata/comment_2_c791aca6da2bb1be70991bc1a76982a4._comment b/doc/todo/Bidirectional_metadata/comment_2_c791aca6da2bb1be70991bc1a76982a4._comment
new file mode 100644
index 0000000000..449f415b78
--- /dev/null
+++ b/doc/todo/Bidirectional_metadata/comment_2_c791aca6da2bb1be70991bc1a76982a4._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-05-09T17:27:35Z"
+ content="""
+I think that the core primitive here may not be the bidirectional
+relationship, but instead setting a metadata field to a key.
+
+If the metadata is known to be a key rather than some other type
+of value, then key-specific things can be done with it.
+
+So perhaps the real core thing is to be able to define what the type of a
+metadata field is. That could be done using $field-type to define the type
+of $field, but it seems it would be better to define it somewhat
+globally so that fields with the same name can't have different types.
+
+(The datalad project does something similar for tarballs, using a custom
+special remote that retrieves the tarball as an annexed object and then
+explodes it to get the requested member object.)
+"""]]
diff --git a/doc/todo/Bittorrent-like_features.mdwn b/doc/todo/Bittorrent-like_features.mdwn
new file mode 100644
index 0000000000..2ffe7fecc7
--- /dev/null
+++ b/doc/todo/Bittorrent-like_features.mdwn
@@ -0,0 +1,66 @@
+There are two different possible ways git-annex could use bittorrent:
+
+Let's describe those one by one.
+
+[[!toc]]
+
+Downloading files from multiple git-annex sources simultaneously
+================================================================
+
+Having your remotes (optionally!) act like a swarm would be an awesome feature to have because you bring in a lot of new features that optimize storage, bandwidth, and overall traffic usage. This would be made a lot easier if parts of it were implemented in small steps that added a nifty feature. The best part is, each of these could be implemented by themselves, and they're all features that would be really useful.
+
+ 1. Concurrent downloads of a file from remotes.
+
+    This would make sense to have, it saves upload traffic on your remotes, and you also get faster DL speeds on the receiving end.
+
+ 2. Implementing part of the super-seeding capabilities.
+
+    You upload pieces of a file to different remotes from your laptop, and on your desktop you can download all those pieces and put them together again to get a complete file. If you really wanted to get fancy, you could build in redundancy (ala RAID) so if a remote or two gets lost, you don't lose the entire file. This would be a very efficient use of storage if you have a bunch of free cloud storage accounts (~1GB each) and some big files you want to back up.
+
+ 3. Setting it up so that those remotes could talk to one another and share those pieces.
+
+    This is where it gets more like bittorrent. Useful because you upload 1 copy and in a few hours, have say, 5 complete copies on 5 different remotes. You could add or remove remotes from a swarm locally, and push those changes to those remotes, which then adapt themselves to suit the new rules and share those with other remotes in the swarm (rules should be GPG-signed as a safety precaution). Also, if/when deltas get implemented, you could push that delta to the swarm and have all the remotes adopt it. This is cooler than regular bittorrent because the shared file can be updated. As a safety precaution, the delta could be GPG signed so a corrupt file doesn't contaminate the entire swarm. Each remote could have bandwidth/storage limits set in a dotfile.
+
+This is a high-level idea of how it might work, and it's also a HUGE set of features to add, but if implemented, you'd be saving a ton of resources, adding new use cases, and making git-annex more flexible.
+
+Obviously, Step 3 would only work on remotes that you have control of processes on, but if given login credentials to cloud storage remotes (potentially dangerous!) they could read/write to something like dropbox or rsync.
+
+Another thing, this would be completely trackerless. You just use remote groups (or create swarm definitions) and share those with your remotes. **It's completely decentralized!**
+
+This was originally posted [[as a forum post|forum/Wishlist:_Bittorrent-like_transfers]] by [[users/GLITTAH]].
+
+Update: there are multiple projects trying to solve this problem space outside of git-annex, which git-annex should reuse.
+
+ * [[design/assistant/telehash/]] support is still not complete, as the upstream spec and implementation (particularly Haskell bits), need to mature
+ * [[special_remotes/ipfs/]] is now a special remote that does respond to some of the requirements (but [duplicates files around](https://github.com/ipfs/go-ipfs/issues/875) even more and is [kind of](https://github.com/ipfs/go-ipfs/issues/872) [slow](https://github.com/ipfs/go-ipfs/issues/898))
+ * [dat](https://datproject.org/) is a bit like IPFS, except it doesn't duplicate files around so it might be a better match to sync stuff around
+ * [Maidsafe](http://maidsafe.net/) is another option, which provides storage and uses crypto-currency incentives
+ * [Storj](http://storj.io/) is similar
+ * [camlistore](https://camlistore.org/) is yet another option
+ * [syncthing](https://syncthing.net/) looks like a btsync replacement, and could also be interesting, see the [[todo/syncthing_special_remote]] discussion
+ * [gittorrent](http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decentralized-github/) allows for decentralised sharing of the git objects, which could replace pairing between repositories, except it [doesn't support push yet](https://github.com/cjb/GitTorrent/issues/3)
+ * [gitocalypse](https://github.com/SeekingFor/gitocalypse) is similar to gittorrent, except it uses Freenet and HG (Mercurial?!) instead of the bittorrent DHT
+ * [tox](https://tox.chat/) - DHT-enabled chat, file transfer and messaging platform, [no stable release](https://github.com/irungentoo/toxcore/issues/1353), [security concerns](http://lists.alioth.debian.org/pipermail/pkg-privacy-maintainers/Week-of-Mon-20150928/000046.html)
+ * [ricochet](https://ricochet.im/) - similar, but relies on Tor, unclear if it supports file transfers, packaged in Debian
+ * [pond](https://pond.imperialviolet.org/) - similar to ricochet
+ * [scout](https://github.com/bittorrent/scout) - DHT-based messaging and peer discovery, used for the Bittorrent-based [bleep messenger](http://www.bleep.pm), could be used to sync git history? [introduction article](http://blog.bittorrent.com/2016/09/09/scout-securely-locate-peers-without-central-servers/)
+ * [pwnat](http://samy.pl/pwnat/) can similarly be used to create tunnels to bypass NATs
+
+joeyh worked on [[design/assistant/telehash/]] for a while but then switched to [[wait and see|devblog/day_219__catching_up_and_looking_back/]], when it became clear telehash wasn't quite mature enough yet. he eventually implemented a solution for part 3 of this problem (connecting to peers without setting up a server) with the [[tor special remote|special_remotes/tor/]], see [[tips/peer_to_peer_network_with_tor/]] for instructions. This doesn't directly address the other two requirements in the sense that each remote need a custom setup to join the p2p exchange, which is still one-to-one and not many-to-many as typical p2p applications are. -- [[anarcat]] 2018-08-24
+
+Using an external client (addurl torrent support)
+=================================================
+
+The alternative to this would be to add `addurl` support for bittorrent files. The same way we can now add Youtube videos to a git-annex repository thanks to [[quvi]], we could also simply do:
+
+    git annex addtorrent debian-live-7.0.0-amd64-standard.iso.torrent
+
+or even better:
+
+    git annex addurl http://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/debian-live-7.0.0-amd64-standard.iso.torrent
+
+This way, a torrent would just become another source for a specific file. When we `get` the file, it fires up `$YOUR_FAVORITE_TORRENT_CLIENT` to download the file.
+
+That way we avoid the implementation complexity of shoving a complete bittorrent client within the assistant. The `get` operation would block until the torrent is downloaded, i guess... --[[anarcat]]
+
+> This is now [[implemented|special_remotes/bittorrent/]]. Including magnet link support, and multi-file torrent support. Leaving todo item open for the blue-sky stuff at top. --[[Joey]]
diff --git a/doc/todo/Bittorrent-like_features/comment_1_f4c110ef35ebf4fd89f06edf2c4f0c48._comment b/doc/todo/Bittorrent-like_features/comment_1_f4c110ef35ebf4fd89f06edf2c4f0c48._comment
new file mode 100644
index 0000000000..eba291af97
--- /dev/null
+++ b/doc/todo/Bittorrent-like_features/comment_1_f4c110ef35ebf4fd89f06edf2c4f0c48._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Gastlag"
+ ip="109.190.97.30"
+ subject="Gittorrent"
+ date="2013-08-28T21:49:56Z"
+ content="""
+May this could interest you : few years ago somes tried to mix Git and Bittorrent.
+
+http://www.advogato.org/article/994.html
+http://utsl.gen.nz/gittorrent/rfc.html
+http://code.google.com/p/gittorrent/
+https://git.wiki.kernel.org/index.php/SoC2010Application#Did_your_organization_participate_in_past_GSoCs.3F_If_so.2C_please_summarize_your_involvement_and_the_successes_and_challenges_of_your_participation
+"""]]
diff --git a/doc/todo/Bittorrent-like_features/comment_2_83148bd5c5c5e6c2eff3ad6e1d4fb82c._comment b/doc/todo/Bittorrent-like_features/comment_2_83148bd5c5c5e6c2eff3ad6e1d4fb82c._comment
new file mode 100644
index 0000000000..ed6e92fd8f
--- /dev/null
+++ b/doc/todo/Bittorrent-like_features/comment_2_83148bd5c5c5e6c2eff3ad6e1d4fb82c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmTIL7ubr5opWM69Q5VtCxuxC2H0SSnzic"
+ nickname="Petr"
+ subject="Regarding the approach to connect all nodes in one network and stream from them"
+ date="2013-12-29T07:32:05Z"
+ content="""
+Have a look at http://socialvpn.wordpress.com/. Behind that project is couple of interesting tools worth to investigate. 
+"""]]
diff --git a/doc/todo/Bittorrent-like_features/comment_3_84f149b30de1562593623aa23dc0396c._comment b/doc/todo/Bittorrent-like_features/comment_3_84f149b30de1562593623aa23dc0396c._comment
new file mode 100644
index 0000000000..a405bed09f
--- /dev/null
+++ b/doc/todo/Bittorrent-like_features/comment_3_84f149b30de1562593623aa23dc0396c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 3"
+ date="2014-01-02T01:31:05Z"
+ content="""
+> git annex addurl http://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/debian-live-7.0.0-amd64-standard.iso.torrent
+
+This is bad idea; it means you will be reliant on torrent files and trackers when magnet links are the way to go.
+"""]]
diff --git a/doc/todo/Bittorrent-like_features/comment_4_7c54c83e582c0d4848aaf3d70e312707._comment b/doc/todo/Bittorrent-like_features/comment_4_7c54c83e582c0d4848aaf3d70e312707._comment
new file mode 100644
index 0000000000..6787a24607
--- /dev/null
+++ b/doc/todo/Bittorrent-like_features/comment_4_7c54c83e582c0d4848aaf3d70e312707._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 4"
+ date="2014-01-02T01:32:37Z"
+ content="""
+There's a bittorrent library for Haskell, btw: http://hackage.haskell.org/package/bittorrent
+
+Native support in form of a special remote would arguably be best...
+"""]]
diff --git a/doc/todo/Bittorrent-like_features/comment_5_194dd0e8404ea72af9fb6ff34b994998._comment b/doc/todo/Bittorrent-like_features/comment_5_194dd0e8404ea72af9fb6ff34b994998._comment
new file mode 100644
index 0000000000..620c82e973
--- /dev/null
+++ b/doc/todo/Bittorrent-like_features/comment_5_194dd0e8404ea72af9fb6ff34b994998._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="2001:1928:1:9::1"
+ subject="comment 5"
+ date="2014-04-01T04:43:16Z"
+ content="""
+re #3, sure, magnet link support would be awesome as well but i'd prefer to start with something i could digest more easily.
+
+looking at the source, it seems to me that the [quvi implementation](http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=46b6d75) could serve as an example as to how this would work. more particularly, there's this concept of a [downloader](http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=46b6d75#patch5) that can be used to tap into `addurl` directly. there's a check to see if the downloader is supported, for example.
+
+so we would need:
+
+1. see if the URL / magnet link can be turned into a .torrent somehow
+2. figure out what the filename(s!) will be
+3. start the torrent and wait for its completion, ideally with some progress bar
+
+i asked around to see if transmission-remote could do this, because it would be nice if we could use an existing daemon (instead of having to rebootstrap the whole DHT at every download). so far, I can't see how it could be done cleanly - maybe we would need to use the simpler \"bittorrent\" commandline client, or maybe tap into libtorrent...
+
+in any case, one of the key problems here is that addurl assumes that the URL maps to a single file, not a directory full of file, which is the way bittorrent works. I am not sure how to fix that assumption.
+"""]]
diff --git a/doc/todo/Bittorrent-like_features/comment_6_489505da4143fb1c2bf21e7af695cdef._comment b/doc/todo/Bittorrent-like_features/comment_6_489505da4143fb1c2bf21e7af695cdef._comment
new file mode 100644
index 0000000000..678bb109b9
--- /dev/null
+++ b/doc/todo/Bittorrent-like_features/comment_6_489505da4143fb1c2bf21e7af695cdef._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmHp5oVW8Z9v_vHs5FRtlYj80TYMQWVTS0"
+ nickname="dhead"
+ subject="comment 6"
+ date="2014-06-10T02:18:43Z"
+ content="""
+What about Syncthing protocol ? 
+https://github.com/calmh/syncthing/blob/master/protocol/PROTOCOL.md
+"""]]
diff --git a/doc/todo/CHECKPRESENT-MULTI.mdwn b/doc/todo/CHECKPRESENT-MULTI.mdwn
new file mode 100644
index 0000000000..884747dd44
--- /dev/null
+++ b/doc/todo/CHECKPRESENT-MULTI.mdwn
@@ -0,0 +1,5 @@
+Having very big files in chunked special remotes makes operations like fsck, move or drop extremely slow. Eg. a movie of 20GiB in a special remote with the [recommended chunk size](https://github.com/DanielDent/git-annex-remote-rclone/issues/1) of 50MiB results in 400 lookups each time the presence of the key is checked. One could increase the chunk size, but that has other disadvantages: a) Chunks are apparently still [buffered in memory](https://git-annex.branchable.com/todo/upload_large_chunks_without_buffering_in_memory/) b) one would lose more transfer progress if the special remote does not implement resumable transfers and c) it would render the use of `git annex inprogress` for streaming purposes useless. Letting the remote know about all the keys that are about to be checked would allow it to optimise the request to the remote server.
+
+So I propose a protocol extension `CHECKPRESENT-MULTI Key1 Key2...` to let the remote do the optimised lookup after which it can reply with a list of present keys `PRESENT Key1 Key2...`. This list can be empty if none of the keys are present: `PRESENT`.
+
+--Lykos
diff --git a/doc/todo/CHECKPRESENT-MULTI/comment_1_181a908a9f77a4c51d1d09f1aff526b7._comment b/doc/todo/CHECKPRESENT-MULTI/comment_1_181a908a9f77a4c51d1d09f1aff526b7._comment
new file mode 100644
index 0000000000..d81b7be40e
--- /dev/null
+++ b/doc/todo/CHECKPRESENT-MULTI/comment_1_181a908a9f77a4c51d1d09f1aff526b7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="batch presence checking"
+ date="2020-02-27T20:33:44Z"
+ content="""
+Beyond individual large files, maybe this could speed up checking that a whole directory is present in an export remote, by using a command like [`gsutil ls`](https://cloud.google.com/storage/docs/gsutil/commands/ls) to list the present files, instead of calling [`gsutil stat`](https://cloud.google.com/storage/docs/gsutil/commands/stat) on each file individually.
+"""]]
diff --git a/doc/todo/CHECKPRESENT-MULTI/comment_2_87857aeaf45927846cde8cea70f9e6f4._comment b/doc/todo/CHECKPRESENT-MULTI/comment_2_87857aeaf45927846cde8cea70f9e6f4._comment
new file mode 100644
index 0000000000..9b64d4efee
--- /dev/null
+++ b/doc/todo/CHECKPRESENT-MULTI/comment_2_87857aeaf45927846cde8cea70f9e6f4._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-02-28T18:58:48Z"
+ content="""
+Export remotes don't use chunks, and use CHECKPRESENTEXPORT rather than
+CHECKPRESENT. And git-annex tries to not buffer the whole worktree in
+memory, but stream through it, so it can support very large worktrees.
+So this idea, which I do think is a good idea, seems limited to checking 
+chunks.
+
+(I'd probably want to make the chunk handling code only include up to 1
+million or so chunk keys in a request, again to avoid using too much memory.
+1 million chunk keys needs 160 mb ram max, 80 or less typically.)
+
+At least for purposes of chunks, the reply to CHECKPRESENT-MULTI only needs
+to say if all the keys are present. If even one chunk is missing, the object
+as a whole is not present in the remote. That seems like a useful simplication.
+
+Internally, probably Remote.checkPresent should change to taking a `[Key]`
+list. Simpler than adding a whole other method for this.
+
+Remote.External could use CHECKPRESENT when there's one key in the list,
+and CHECKPRESENT-MULTI when the are multiple, falling back to CHECKPRESENT
+on an UNSUPPORTED-REQUEST reply. But, I think it ought to be an
+extension to the protocol, to avoid that extra roundtrip.
+"""]]
diff --git a/doc/todo/CHECKPRESENT-MULTI/comment_4_5228016c35ca0b13545b82bbd3b9455e._comment b/doc/todo/CHECKPRESENT-MULTI/comment_4_5228016c35ca0b13545b82bbd3b9455e._comment
new file mode 100644
index 0000000000..04c5c71316
--- /dev/null
+++ b/doc/todo/CHECKPRESENT-MULTI/comment_4_5228016c35ca0b13545b82bbd3b9455e._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 4"
+ date="2020-09-29T08:36:18Z"
+ content="""
+
+I agree about the simplification. However, when resuming an upload with, say, 400 chunks where only 10 are missing, after CHECKPRESENT-MULTI-FAILURE, we'd need to CHECKPRESENT another 390 keys until we can continue. Sure, the remote could cache the replies, but another idea would be for the remote to reply with the last key in the list that is present.
+
+Example:
+
+```
+$ CHECKPRESENT-MULTI a b c d e  # git annex calls CHECKPRESENT-MULTI with an ordered list
+CHECKPRESENT-MULTI-SUCCESS      # all keys are present
+CHECKPRESENT-MULTI-FAILURE      # all keys are missing
+CHECKPRESENT-MULTI-FAILURE c    # Everything up to c is present, d is missing. e could be present or missing
+```
+
+"""]]
diff --git a/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client.mdwn b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client.mdwn
new file mode 100644
index 0000000000..941ac9e5ac
--- /dev/null
+++ b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client.mdwn
@@ -0,0 +1,22 @@
+Note: This may not be a bug maybe the software doesn't work the way I think.
+
+What steps will reproduce the problem?
+
+Using the webapp, I created a normal repo on my desktop. I then added a 'Removable drive' repo on my usb stick.
+
+I want all my files to be synced and accessibles on both repos so I set the 'Removable drive' repo to 'client'.
+
+
+What is the expected output? What do you see instead?
+
+When I look in the 'annex' folder on my usb stick. I see a git repo (annex, branches, hooks) instead of seeing the files in the same way the 'annex' repo on my desktop is.
+
+
+What version of git-annex are you using? On what operating system?
+
+I'm using 9e57edff287ac53fc4b1cefef7271e9ed17f2285 (Fri Feb 22 15:19:25 2013 +0000).
+
+Ubuntu 12.10 x86_64
+
+[[!tag /design/assistant]]
+[[!meta title="assistant should set up non-bare repos on removable drives, and update them when syncing with them"]]
diff --git a/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_10_e33dddf4d1f104107c86800a0a9a89b2._comment b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_10_e33dddf4d1f104107c86800a0a9a89b2._comment
new file mode 100644
index 0000000000..0e2c11656e
--- /dev/null
+++ b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_10_e33dddf4d1f104107c86800a0a9a89b2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 10"
+ date="2014-11-25T21:28:56Z"
+ content="""
+[[forum/usability:_creating_an_archive_on_a_new_external_drive]] has discussion of why the assistant cannot do this by default.
+"""]]
diff --git a/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_1_25eb2d7d0a9cdd1c55df0cec68472723._comment b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_1_25eb2d7d0a9cdd1c55df0cec68472723._comment
new file mode 100644
index 0000000000..282e78298b
--- /dev/null
+++ b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_1_25eb2d7d0a9cdd1c55df0cec68472723._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.253.75"
+ subject="comment 1"
+ date="2013-02-22T21:46:59Z"
+ content="""
+You have a bare git repository on your USB stick. The assistant uses bare repositories on USB sticks currently, although recent changes to support FAT make it possible to use non-bare repositories.
+
+For this to really work the way you want it to, the assistant would need to start updating local non-bare repositories whenever it pushed changes to them. Currently the assistant only updates the repository it's running in, so a non-bare repository on USB would lag behind and show an old version of the directory until manually updated with `git annex sync`.
+"""]]
diff --git a/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_2_9e9b96e5113a50533251e946c2560d81._comment b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_2_9e9b96e5113a50533251e946c2560d81._comment
new file mode 100644
index 0000000000..da1fcbc0f2
--- /dev/null
+++ b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_2_9e9b96e5113a50533251e946c2560d81._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="87.194.19.134"
+ subject="comment 2"
+ date="2013-02-27T00:02:01Z"
+ content="""
+Struggling to get the assistant to behave properly, including a similar situation to the above.
+
+I start the assistant with 'git annex webapp' and create an annex from the webapp.
+Adding an SSH remote (even if just a different directory on localhost) with \"Remote server\", creates the remote directory with what looks like what the contents of .git should be (annex, branches, hooks, objects etc.), regardless of the group chosen.
+
+Judging from your above comment, this means it is creating a bare repository. Why would it be doing this for an SSH remote, where git-annex-shell is available?
+
+System: Arch Linux
+git-annex version: 3.20130216
+Installed with: yaourt -S git-annex-bin
+"""]]
diff --git a/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_3_6b091198ddd6ed709b076df1296aeb77._comment b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_3_6b091198ddd6ed709b076df1296aeb77._comment
new file mode 100644
index 0000000000..48d1b26040
--- /dev/null
+++ b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_3_6b091198ddd6ed709b076df1296aeb77._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 3"
+ date="2013-02-27T01:12:29Z"
+ content="""
+Xyem, if you use git to clone a repo, instead of letting the assistant do it for you, you can get a non-bare repo.  See the walkthrough for some examples.  You can keep its working tree up to date with \"git annex sync\" run in that directory.
+
+Only helpful if you don't mind using git annex at the command line, I know.
+
+"""]]
diff --git a/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_4_118b588685b535cca4c02eb6ef297c67._comment b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_4_118b588685b535cca4c02eb6ef297c67._comment
new file mode 100644
index 0000000000..8ad0de3a5c
--- /dev/null
+++ b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_4_118b588685b535cca4c02eb6ef297c67._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="87.194.19.134"
+ subject="comment 4"
+ date="2013-02-27T12:16:45Z"
+ content="""
+@edheil:
+Yes, I have found that creating the repositories outside of the assistant (or directly on each machine through the assistant) and adding the remotes manually doesn't have this issue.. but as I am not setting this up for myself, so dropping to the command line is an issue (she's not averse to it, but also isn't a power user).
+
+It seems that the assistant/webapp is replacing dropbox functionality, while ignoring the functionality of git-annex. Perhaps I am misunderstanding the goal of it..?
+
+My intended use case in the situation where this issue comes up is:
+
+Repository on desktop has a copy of all files in indirect mode.
+Repository on netbook only has a copy of files added locally or fetched manually.
+Dropping a file in the netbook annex should cause it to be uploaded to the desktop repository (when it is available). Files should be fetchable/droppable (and unlockable) using the webapp from the desktop/netbook repository respectively.
+
+But it looks like this is (currently) unachievable as the webapp provides no method of fetching/dropping files, the assistant does not create the remote repositories correctly and requires dropping to the command line if worked around. Eep!
+
+Hope this doesn't come off as sour complaining. I was introduced to git-annex by a friend about a week ago (she only learned about it about 2-3 weeks ago and *loves* it) and it is a very nice and flexible tool which fits my own use case perfectly, meeting and exceeding every expectation.. until it came to the assistant and webapp (which makes me wonder why Joey is working on an Android port..).
+"""]]
diff --git a/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_5_5cead277493e1c020e16be6f9245fe33._comment b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_5_5cead277493e1c020e16be6f9245fe33._comment
new file mode 100644
index 0000000000..26b472dc75
--- /dev/null
+++ b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_5_5cead277493e1c020e16be6f9245fe33._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 5"
+ date="2013-02-27T17:05:07Z"
+ content="""
+There is a way to fetch/drop files if you don't want to use the command line, though it's not nearly as flexible as using a command line.  If you've got a machine set as \"client\" then dragging files into a subdirectory named \"archive\" drops them, and dragging them out of that subdirectory fetches them.
+
+Honestly, moving files in and out of directories, and preferred content settings, have both been subject to the occasional regression, so there have been times this hasn't worked right, but in theory, that's how you do it.
+
+Unfortunately if you've got more than one \"client\" machine, this means adding/dropping files on one will affect them all, as file movements propagate.
+"""]]
diff --git a/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_6_0f135f97c2808dce094628dc6608e617._comment b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_6_0f135f97c2808dce094628dc6608e617._comment
new file mode 100644
index 0000000000..3fadb6219f
--- /dev/null
+++ b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_6_0f135f97c2808dce094628dc6608e617._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 6"
+ date="2013-02-27T17:06:45Z"
+ content="""
+also... I've never used the feature where you have two local machines running git-annex and you tell one to share a repo with the other through the web interface, but maybe it would be helpful for this scenario?  Apologies if you've already tried that.
+"""]]
diff --git a/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_7_1d6f47f9e6cf935f19d68af6d5aa92fa._comment b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_7_1d6f47f9e6cf935f19d68af6d5aa92fa._comment
new file mode 100644
index 0000000000..03d9950bca
--- /dev/null
+++ b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_7_1d6f47f9e6cf935f19d68af6d5aa92fa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 7"
+ date="2013-02-27T17:43:45Z"
+ content="""
+The way this is supposed to (and does) work is that you use the webapp to create a repository on each computer, and then you pair them together using either local pairing or xmpp pairing.
+
+Today's release of git-annex also adds UI in the webapp to create additional local repositories that are connected to the current repository. However these are not really intended to be put on removable drives since the assistant needs to be running on them to keep them up-to-date.
+"""]]
diff --git a/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_8_c5758fdb32348b9cd804ff17d27864e1._comment b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_8_c5758fdb32348b9cd804ff17d27864e1._comment
new file mode 100644
index 0000000000..1ef87e6a65
--- /dev/null
+++ b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_8_c5758fdb32348b9cd804ff17d27864e1._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="87.194.19.134"
+ subject="comment 8"
+ date="2013-02-27T18:36:16Z"
+ content="""
+@Joey:
+As my use case is 1 person using multiple machines, I didn't think local/XMPP pairing was appropriate.
+
+Local pairing because the netbook leaves the network the desktop machine is on, which is when transferring the files is wanted (otherwise, they would just use the desktop...).
+XMPP pairing description implies that it is for 2 different people (thus 2 different addresses). Can it be used where both annexes are using the same address? Or does the address also allow you to include the location (i.e. name@host.com/netbook)?
+
+It definitely sounds like I am misunderstanding how this is supposed to work so I apologise for that. Please keep up the excellent work. git-annex is one of those tools I wish I had learned about a long time ago!
+
+@edheil: Interesting workaround, thanks.
+"""]]
diff --git a/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_9_3f0bfc5a79aa59ac76a6968aacda6655._comment b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_9_3f0bfc5a79aa59ac76a6968aacda6655._comment
new file mode 100644
index 0000000000..d370bb28d2
--- /dev/null
+++ b/doc/todo/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client/comment_9_3f0bfc5a79aa59ac76a6968aacda6655._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="confusing..."
+ date="2014-05-14T05:04:01Z"
+ content="""
+this is still really confusing. having to create the repo by hand is a really confusing step - i have setup an external drive to have my files with me as i move around, having to go through hoops to find them in a bare repository seems contrary to the spirit of \"future proofing\" inherent to git annex.
+
+the solution i found was to `git init` the repo on the removable drive before adding it through the webapp. i hope this can eventually be fixed, as it led to confusion among many other users (e.g. [[forum/Accessing_files_in_bare_repository/]], [[bugs/Adding a repository as a \"remote server\" creates a bare repository next to the existing one/]],  [[forum/remote server client repositories are bare!?/]] and so on). --[[anarcat]]
+"""]]
diff --git a/doc/todo/Configuring_metadata_view_filenames.mdwn b/doc/todo/Configuring_metadata_view_filenames.mdwn
new file mode 100644
index 0000000000..220c470014
--- /dev/null
+++ b/doc/todo/Configuring_metadata_view_filenames.mdwn
@@ -0,0 +1 @@
+Currently, in a git annex view, filenames take the form basename%path%.ext. I understand that this is a carefully drafted mapping to allow changes to be merged back into metadata. However, maybe it would be possible to make the separator ('%') and the order (e.g. path%basename.ext instead) configurable?
diff --git a/doc/todo/Configuring_metadata_view_filenames/comment_1_08f8f27e5a8dbd80a91ffd9fd6f64e6c._comment b/doc/todo/Configuring_metadata_view_filenames/comment_1_08f8f27e5a8dbd80a91ffd9fd6f64e6c._comment
new file mode 100644
index 0000000000..b498df6316
--- /dev/null
+++ b/doc/todo/Configuring_metadata_view_filenames/comment_1_08f8f27e5a8dbd80a91ffd9fd6f64e6c._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-04T19:38:58Z"
+ content="""
+git-annex really doesn't care what filenames are used with in a view.
+It only needs to ensure that each file gets a unique filename. Which
+is why the directory is included in the filename, to avoid conflicts
+if 2 files with the same name appear in different directories.
+
+It would probably be better to make it avoid needing to include the
+directory in the filename unless there is such a conflict, rather than
+adding complexity configuring that.
+
+However, since views are currently built by streaming the contents of the
+branch to git update-index, git-annex can't just eg, examine the working
+tree to see if a conflicting file exists. It seems it would need to keep
+a map of the files it's added to the view branch so far, and check against
+the map. But that would make memory use scale with the number of files in
+the view, which I'd prefer to avoid..
+
+I'm going to move this from bugs to todo.
+"""]]
diff --git a/doc/todo/Configuring_metadata_view_filenames/comment_2_34efe1424a9b02dca706565517900bd6._comment b/doc/todo/Configuring_metadata_view_filenames/comment_2_34efe1424a9b02dca706565517900bd6._comment
new file mode 100644
index 0000000000..99429806a2
--- /dev/null
+++ b/doc/todo/Configuring_metadata_view_filenames/comment_2_34efe1424a9b02dca706565517900bd6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Tafnzart"
+ avatar="http://cdn.libravatar.org/avatar/45f62eccc7caece0d1f963f6662ccfde"
+ subject="Maybe provide an option to force without name change"
+ date="2017-05-07T14:05:03Z"
+ content="""
+This name change shouldn't be necessary if on view that has directory structure from master:
+git annex view todo=* \"/=*\"
+"""]]
diff --git a/doc/todo/Configuring_metadata_view_filenames/comment_3_dd7aa7560412d4589d2fc28eb978a71e._comment b/doc/todo/Configuring_metadata_view_filenames/comment_3_dd7aa7560412d4589d2fc28eb978a71e._comment
new file mode 100644
index 0000000000..f8377f8fec
--- /dev/null
+++ b/doc/todo/Configuring_metadata_view_filenames/comment_3_dd7aa7560412d4589d2fc28eb978a71e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 3"
+ date="2017-05-09T10:05:14Z"
+ content="""
+>  But that would make memory use scale with the number of files in the view, which I'd prefer to avoid..
+
+This sounds like another use case for bloom filters :)
+"""]]
diff --git a/doc/todo/Configuring_metadata_view_filenames/comment_4_1873c7cdd142dffc210ec0172bf29997._comment b/doc/todo/Configuring_metadata_view_filenames/comment_4_1873c7cdd142dffc210ec0172bf29997._comment
new file mode 100644
index 0000000000..310cd68bc6
--- /dev/null
+++ b/doc/todo/Configuring_metadata_view_filenames/comment_4_1873c7cdd142dffc210ec0172bf29997._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-05-09T17:41:33Z"
+ content="""
+True, it could use a bloom filter.
+
+I had not thought of `/=*` (or forgot about it). Views could, as a special
+case, use the original paths in that case. That's getting very close to
+adjusted branch territory, and I want to rewrite the view branch generation
+code to use adjusted branches eventually (so changes made in the view
+branch can be propigated back out to the source branch and so view branches
+can be updated when the source branch changes).
+"""]]
diff --git a/doc/todo/Configuring_metadata_view_filenames/comment_5_b222634d9f97e2ef604b476df357d54b._comment b/doc/todo/Configuring_metadata_view_filenames/comment_5_b222634d9f97e2ef604b476df357d54b._comment
new file mode 100644
index 0000000000..4eb0f26f99
--- /dev/null
+++ b/doc/todo/Configuring_metadata_view_filenames/comment_5_b222634d9f97e2ef604b476df357d54b._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="Xyem"
+ avatar="http://cdn.libravatar.org/avatar/dea2d98057721c21166c3721f6d55c06"
+ subject="comment 5"
+ date="2023-03-23T17:05:24Z"
+ content="""
+Has the format been changed since this previously asked? I am currently trying to leverage git-annex and its metadata views with AI tooling, but the format seems to be filename_%path%, resulting in the extension being in the middle of the path. I have set `annex.maxextensionlength` to `12` so the extensions are present on the files in the backend.
+
+    $ git annex view type=model model/=*
+    $ ls -lr
+    .:
+    sd
+    
+    ./sd:
+    v1.4.safetensors_%model%sd%  v1.5.safetensors_%model%sd%
+
+whereas I would expect (or rather, I am trying to achieve):
+
+    $ ls -lr
+    .:
+    sd
+    
+    ./sd:
+    v1.4.safetensors  v1.5.safetensors
+
+"""]]
diff --git a/doc/todo/Configuring_metadata_view_filenames/comment_6_1eb8c2d70ff9e3e5b3dbebf88270eb93._comment b/doc/todo/Configuring_metadata_view_filenames/comment_6_1eb8c2d70ff9e3e5b3dbebf88270eb93._comment
new file mode 100644
index 0000000000..7a0ddb9053
--- /dev/null
+++ b/doc/todo/Configuring_metadata_view_filenames/comment_6_1eb8c2d70ff9e3e5b3dbebf88270eb93._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-03-23T20:39:33Z"
+ content="""
+@Xyem no, it's unchanged. But annex.maxextensionlength does not configure
+the extension length here currently. I think it would be a good thing for
+it to do, probably.
+"""]]
diff --git a/doc/todo/Configuring_metadata_view_filenames/comment_7_ae259f68ab5b366b6fd29e5df1a05469._comment b/doc/todo/Configuring_metadata_view_filenames/comment_7_ae259f68ab5b366b6fd29e5df1a05469._comment
new file mode 100644
index 0000000000..4a005a956a
--- /dev/null
+++ b/doc/todo/Configuring_metadata_view_filenames/comment_7_ae259f68ab5b366b6fd29e5df1a05469._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Xyem"
+ avatar="http://cdn.libravatar.org/avatar/dea2d98057721c21166c3721f6d55c06"
+ subject="comment 7"
+ date="2023-03-23T22:26:24Z"
+ content="""
+So if my understanding is correct, the file paths generated for this view should something like `sd/v1.5_%model%.safetensors` but as `annex.maxextensionlength` isn't being considered during this, it doesn't realise `safetensors` is the extension?
+
+Unfortunately, the software will only regard certain extensions as being usable files, so I will be unable to use metadata views for now. I've set up separate branches and will copy symlinks between branches in the meantime.
+"""]]
diff --git a/doc/todo/Configuring_metadata_view_filenames/comment_8_2bcfc677da72637f34904b84fdd95c10._comment b/doc/todo/Configuring_metadata_view_filenames/comment_8_2bcfc677da72637f34904b84fdd95c10._comment
new file mode 100644
index 0000000000..b379529f5c
--- /dev/null
+++ b/doc/todo/Configuring_metadata_view_filenames/comment_8_2bcfc677da72637f34904b84fdd95c10._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-03-24T17:48:43Z"
+ content="""
+I've made git-annex view use `annex.maxextensionlength`. Note that refining
+an existing view will reuse the extension length that was configured when
+initially constructing the view.
+"""]]
diff --git a/doc/todo/Copy-on-Write__47__reflink__47__clonefile_support_on_macOS.mdwn b/doc/todo/Copy-on-Write__47__reflink__47__clonefile_support_on_macOS.mdwn
new file mode 100644
index 0000000000..cc35f33847
--- /dev/null
+++ b/doc/todo/Copy-on-Write__47__reflink__47__clonefile_support_on_macOS.mdwn
@@ -0,0 +1,11 @@
+Thank you for your previous message here: [[/todo/Copy-on-Write__47__reflink_support_for_unlocked_files/]].
+
+I indeed discovered it was done for Linux after I posted it, but macOS with APFS also supports reflinks, under the `-c` (clonefile) option, which does the same as the `--reflink=always` option on Linux.
+
+The biggest problem is that there is no auto option, but in theory it’s possible to first try the clone option, and then fall back if it doesn’t work, although that would be inefficient. 
+
+I can try to code something, although I am not that proficient in Haskell, or run test code if needed on macOS 12. 
+
+-- Lena Wildervanck
+
+> [[dup|done]] --[[Joey]] 
diff --git a/doc/todo/Copy-on-Write__47__reflink__47__clonefile_support_on_macOS/comment_1_81bf4ac2fe810cc4e7a21c8bb4d0f15a._comment b/doc/todo/Copy-on-Write__47__reflink__47__clonefile_support_on_macOS/comment_1_81bf4ac2fe810cc4e7a21c8bb4d0f15a._comment
new file mode 100644
index 0000000000..cf619af016
--- /dev/null
+++ b/doc/todo/Copy-on-Write__47__reflink__47__clonefile_support_on_macOS/comment_1_81bf4ac2fe810cc4e7a21c8bb4d0f15a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-11-21T19:11:52Z"
+ content="""
+This todo aleady exists for the same thing:
+<https://git-annex.branchable.com/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/>
+"""]]
diff --git a/doc/todo/Copy-on-Write__47__reflink_support_for_unlocked_files.mdwn b/doc/todo/Copy-on-Write__47__reflink_support_for_unlocked_files.mdwn
new file mode 100644
index 0000000000..bc49a7512f
--- /dev/null
+++ b/doc/todo/Copy-on-Write__47__reflink_support_for_unlocked_files.mdwn
@@ -0,0 +1,3 @@
+Some filesystems, like BTRFS or ZFS have copy on write support, which means that if files are copied in a special way they share sectors until one of the files is edited. Implementing support would make files take up less space if they are in unlocked mode and not significantly edited.
+
+> Already [[done]]. I did add a mention of it to the tip. --[[Joey]]
diff --git a/doc/todo/Copy-on-Write__47__reflink_support_for_unlocked_files/comment_1_52db92711e28abb0eb7a346646b91573._comment b/doc/todo/Copy-on-Write__47__reflink_support_for_unlocked_files/comment_1_52db92711e28abb0eb7a346646b91573._comment
new file mode 100644
index 0000000000..15052ef9d7
--- /dev/null
+++ b/doc/todo/Copy-on-Write__47__reflink_support_for_unlocked_files/comment_1_52db92711e28abb0eb7a346646b91573._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="lena.wildervanck@4b6aac156870f72a36b090e210e4747f702b69cb"
+ nickname="lena.wildervanck"
+ avatar="http://cdn.libravatar.org/avatar/8a423528476e6f6dc6a06588b5bbf457"
+ subject="comment 1"
+ date="2022-11-13T19:03:48Z"
+ content="""
+Oh, nvm, there already seem to be some references in the code to it.
+
+Maybe it should be added that it does that under [[https://git-annex.branchable.com/tips/unlocked_files/]] under using less disk space?
+
+Also, macOS uses a `-c` flag instead of `reflink`, according to [the cp man page](https://www.unix.com/man-page/mojave/1/cp/).
+"""]]
diff --git a/doc/todo/Describe_a_file_in_function_of_another_file.mdwn b/doc/todo/Describe_a_file_in_function_of_another_file.mdwn
new file mode 100644
index 0000000000..4993b3b3ad
--- /dev/null
+++ b/doc/todo/Describe_a_file_in_function_of_another_file.mdwn
@@ -0,0 +1,17 @@
+Hello,
+
+In order to save space/bandwith/... I would like to create a way to describe a file compared to another. You could see this as a kind of very special "remote" (which is local :P), that says "To produce file XXX, take file YYY, and run command CCC with args YYY".
+
+You may ask why it is useful? I have several usecases:
+
+1) my first usecase is that I would like to be able to generate thumbnails for my pictures in order to speed up display. A thumbnail can be easily created from a picture (with for example the convert command), but when you don't need the thumbnail, you may prefer to remove them locally to save space.
+
+2) similarly, I have some RAW photo files, and a script to turn them into .JPG file. Or even better, I could have several scripts to convert my initial RAW files into several .JPG files, with different parameters/look. Keeping both RAW and developed JPG can be heavy, so this kind of tool could allow me to remove the .JPG file(s) when I don't need them anymore, so I don't mind to drop the .JPG file as soon as the RAW does exist (but if the RAW does not exist anymore, I shouldn't be able to remove the .JPG of course).
+
+3) I also have on my desktop some compressed files (.iso for example, or old projects). Most of the time, I don't really need to keep the uncompressed .iso, but from time to time, I may need them. For now I manually uncompress them, use them, and delete them... But it could be cool to let git-annex deal with them automatically.
+
+Does git-annex provide such functionnality? If not, do you think it could be implementable?
+
+Thanks!
+
+[[!tag unlikely]]
diff --git a/doc/todo/Describe_a_file_in_function_of_another_file/comment_1_b0132288c67054485e9681f3f5138768._comment b/doc/todo/Describe_a_file_in_function_of_another_file/comment_1_b0132288c67054485e9681f3f5138768._comment
new file mode 100644
index 0000000000..6ea202b65e
--- /dev/null
+++ b/doc/todo/Describe_a_file_in_function_of_another_file/comment_1_b0132288c67054485e9681f3f5138768._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2019-10-03T00:36:54Z"
+ content="""
+See [related discussion](https://github.com/datalad/datalad/issues/2850)
+"""]]
diff --git a/doc/todo/Describe_a_file_in_function_of_another_file/comment_2_4efe2044282c8ccd6d570e84bb2ab68a._comment b/doc/todo/Describe_a_file_in_function_of_another_file/comment_2_4efe2044282c8ccd6d570e84bb2ab68a._comment
new file mode 100644
index 0000000000..cf19d83bd0
--- /dev/null
+++ b/doc/todo/Describe_a_file_in_function_of_another_file/comment_2_4efe2044282c8ccd6d570e84bb2ab68a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="tobiasBora"
+ avatar="http://cdn.libravatar.org/avatar/80a7d8c2a7b475b6b71198cce0faa6b0"
+ subject="comment 2"
+ date="2019-10-03T00:48:23Z"
+ content="""
+So if I get it, it's interesting, but not implemented, and mayae tricky to implement? (The discution is dead now)
+"""]]
diff --git a/doc/todo/Describe_a_file_in_function_of_another_file/comment_3_a9e02d7a27fd4448c1afd19e3f171a5c._comment b/doc/todo/Describe_a_file_in_function_of_another_file/comment_3_a9e02d7a27fd4448c1afd19e3f171a5c._comment
new file mode 100644
index 0000000000..08ec2a2852
--- /dev/null
+++ b/doc/todo/Describe_a_file_in_function_of_another_file/comment_3_a9e02d7a27fd4448c1afd19e3f171a5c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="special remote that restores contents by running a command"
+ date="2019-10-04T18:16:39Z"
+ content="""
+I still think it's doable and worth doing, don't have the bandwidth right now to implement it, but can help brainstorm.  If you're interested in working on it, post in the [github thread](https://github.com/datalad/datalad/issues/2850), and maybe we can refine the design.
+
+The key issues are: (1) you can't just [[`git-annex-copy`|git-annex-copy]] a file to this remote, you'll need to use [[`git-annex-setpresentkey`|git-annex-setpresentkey]] and [[`git-annex-registerurl`|git-annex-registerurl]] to record that contents with a given key can be obtained by running a given command, and (2) the result of running a command depends not just on the command line and the input file(s), but also on the environment in which the command is run, so to get bit-for-bit reconstruction of the contents you'd need to use Docker, or at least something like [conda](https://docs.conda.io/en/latest/).  But even then, sometimes the exact output file depends on the current time or the name of some intermediate tempfile.  So unless the command is 100% deterministic, re-running the command might produce contents that does not match the [[git-annex key|backends]].
+
+For local use, you could make a simple webserver that handles URLs like `http://localhost:3000/cgi-bin/make_thumbnail.sh?orig_file_key=MD5-xxxxxx` , and have the CGI script run [[`git-annex-get --key`|git-annex-get]] to get the file contents and then extract the thumbnail and return that.  Then you can use [[`git-annex-addurl`|git-annex-addurl]] to store the file in git-annex.
+"""]]
diff --git a/doc/todo/Display_fingerprint_to_WebApps_GPG___34__create_encrypted_new_repo__34__.mdwn b/doc/todo/Display_fingerprint_to_WebApps_GPG___34__create_encrypted_new_repo__34__.mdwn
new file mode 100644
index 0000000000..146b0622b3
--- /dev/null
+++ b/doc/todo/Display_fingerprint_to_WebApps_GPG___34__create_encrypted_new_repo__34__.mdwn
@@ -0,0 +1,14 @@
+ I'm using git-annex 5.20150205-gbf9058a and just used the WebApp to create a new remote SSH repo, and thought I'd try the encrypted option.
+
+It give me three GPG keys to choose from (all valid keys) but only displayed the email addresses which were all identical so I couldn't tell which was which.
+
+I then clicked the first key selection button, hoping it would display more info but it seemed to start doing things immediately. It requested the GPG passphrase which I cancelled but it was still doing things, and worse it wasn't clear what state the repo was in (encrypted or not), so I deleted it and started again (it's fine now).
+
+The passphrase dialog box does display the key fingerprint, but it's then too late to alter the key selection.
+
+Request: Could the WebApp always display the fingerprint after the email address?
+
+Some clarity on what happens when you cancel would be nice too.
+
+Thanks
+Giovanni
diff --git a/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp.mdwn b/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp.mdwn
new file mode 100644
index 0000000000..6a461cffff
--- /dev/null
+++ b/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp.mdwn
@@ -0,0 +1 @@
+I've implemented true resumable upload in git-annex-remote-googledrive which means that uploads can, just as downloads, be resumed at any point, even within one chunk. However, it currently does not work with encrypted files (or chunks) due to the non-deterministic nature of GPG. In order to make this feature useable on encrypted files, I propose to not overwrite encrypted files which are already present inside the `tmp` directory.
diff --git a/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_1_0650918c86fca0554755aede19a12fd3._comment b/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_1_0650918c86fca0554755aede19a12fd3._comment
new file mode 100644
index 0000000000..01ebb8c021
--- /dev/null
+++ b/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_1_0650918c86fca0554755aede19a12fd3._comment
@@ -0,0 +1,53 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-17T15:33:31Z"
+ content="""
+@lykos, what happens when git-annex-remote-googledrive tries
+to resume in this situation and git-annex has written a different tmp file
+than what it partially uploaded before?
+
+I imagine it might resume after the last byte it sent before, and so
+the uploaded file gets corrupted?
+
+If so, there are two hard problems with this idea:
+
+1. If git-annex changes to reuse the same tmp file, then git-annex-remote-googledrive
+   will work with the new git-annex, but corrupt files when used with an old
+   git-annex.
+2. If someone has two clones, and starts an upload in one, but it's 
+   interrupted and then started later in the second clone, it would again
+   corrupt the file that gets uploaded. (This would also happen,
+   with a single clone, if git-annex unused gets used in between upload
+   attempts, and cleans up the tmp file.)
+
+The first could be dealt with by some protocol flag, but the second seems
+rather intractable, if git-annex-remote-googledrive behaves as I
+hypothesize it might. And even if git-annex-remote-googledrive behaves
+better that that somehow, it's certianly likely that some other remote
+would behave that way at some point.
+
+----
+
+As to implementation details, I started investigating before thinking
+about the above problem, so am leaving some notes here:
+
+This would first require that the tmp file is written atomically,
+otherwise an interruption in the wrong place would resume with a partial
+file. (File size can't be used since gpg changes the file size with
+compression etc.) Seems easy to implement: Make
+Remote.Helper.Special.fileStorer write to a different tmp file and rename
+it into place. 
+
+Internally, git-annex pipes the content from gpg, so it is only written to
+a temp file when using a remote that operates on files, as the external
+remotes do. Some builtin remotes don't. So resuming an upload to an
+encrypted remote past the chunk level can't work in general.
+
+There would need to be some way for the code that encrypts chunks
+(or whole objects) to detect that it's being used with a remote that
+operates on files, and then check if the tmp file already exists, and avoid
+re-writing it. This would need some way to examine a `Storer` and tell
+if it operates on files, which is not currently possisble, so would need
+some change to the data type.
+"""]]
diff --git a/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_2_aa6bf987de3dfc9f78eba30b4b2c8c16._comment b/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_2_aa6bf987de3dfc9f78eba30b4b2c8c16._comment
new file mode 100644
index 0000000000..0ce322ed06
--- /dev/null
+++ b/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_2_aa6bf987de3dfc9f78eba30b4b2c8c16._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 2"
+ date="2020-02-27T13:12:28Z"
+ content="""
+git-annex-remote-googledrive compares partial checksums after every transmitted chunk and before resuming a transfer, so it would not be affected by both problems you describe. However, you're probably right that some other remote might not behave that way.
+
+My current workaround is to move the file to a tmp directory specific to the remote (and UUID) and when uploading, prefer files inside this directory. Downsides are that it can use slightly more disc space and that git-annex-remote-googledrive has to handle cleanup itself. But I think it's good enough. And the problem probably does not justify changes as big as apparently needed. Thanks for your thoughts on this!
+"""]]
diff --git a/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_3_3419d2603af199fd311f6898adef5ed3._comment b/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_3_3419d2603af199fd311f6898adef5ed3._comment
new file mode 100644
index 0000000000..30d708840c
--- /dev/null
+++ b/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_3_3419d2603af199fd311f6898adef5ed3._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-02-28T18:00:01Z"
+ content="""
+There are probably some other special remotes that are similarly able
+to resume and would safely deal with the problems I mentioned. rsync
+comes to mind. But I'm inclined to agree with you that the scope of the
+changes I found needed to support it in git-annex may not be warranted.
+
+Using your own tmp file a reasonable workaround.
+
+git-annex actually has an internal concept of a "tmp work dir"
+which is associated with a key and can contain whatever tmp files
+might be needed to transfer that key. The nice thing about it is
+that any time git-annex deletes a key's tmp file, it first deletes
+its tmp work dir. The annoying this about it is that the tmp file
+has to exist (even if empty) as long as the tmp work dir does,
+otherwise there's a risk the directory will never get cleaned up.
+
+It's currently only used for downloads, eg with youtube-dl. But it would
+probably also work for uploads. It might make sense to extend the protocol
+to request git-annex tell what the tmp work dir is, and to make sure the
+above invariant is satisfied. But if you would like to live a little
+dangerously, just take the name of the tmp file, and prefix "work.".
+Eg, for the tmp file ".git/annex/tmp/SHA256--x", use
+".git/annex/tmp/work.SHA256--x/".
+"""]]
diff --git a/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts.mdwn b/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts.mdwn
new file mode 100644
index 0000000000..67e95edaa7
--- /dev/null
+++ b/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts.mdwn
@@ -0,0 +1,13 @@
+Currently, git-annex handles merge conflicts of annexed files well. It makes two differently named versions of the conflicting files (A more descriptive naming scheme including date and commit hash would be nice, but that's a different topic).
+
+However, a conflict of git-tracked files is not resolved, leading to merge conflicts being left open after a `git annex sync` (thus leaving file contents with the weird merge markers `<<<<<` etc., breaking file contents.)
+
+Could `git annex [resolve]merge` be extended to also handle those git conflicts and leave the repo in a clean, merged state after `git annex sync|pull|assist`?
+
+To not confuse users, it could be opt-in (`git annex --set annex.resolvegitmerge true`), but maybe the default for `git annex assist`?
+
+On conflict, it would remove the conflicting file and instead create two versions with suffixes either like annexed files or better the commit hash and/or date.
+
+Submodule conflicts can't be resolved like this, in that case I would use the most recent commit of the two in question.
+
+> [[rejected|done]] --[[Joey]]
diff --git a/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts/comment_1_c08e7f51503f103c447064a01b085783._comment b/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts/comment_1_c08e7f51503f103c447064a01b085783._comment
new file mode 100644
index 0000000000..887b4d7111
--- /dev/null
+++ b/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts/comment_1_c08e7f51503f103c447064a01b085783._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-06-05T18:49:43Z"
+ content="""
+I think this would violate least surprise. Users expect git-annex
+to behave like git, and that means merge conflicts like git handles them,
+when the files are text files tracked by git.
+
+Consider that, if the file is a config file, applying git-annex's
+resolvemerge to it would make 2 files with different names be in the
+repository. So the config file would stop taking effect for whatever it was
+supposed to configure. It would be easy for the user to miss that, because
+the repository would not be left in a conflicted state.
+
+When you check a file into git rather than git-annex, you are
+choosing to have git manage that file normally. If you want the git-annex
+behavior, you can check the file into git-annex.
+"""]]
diff --git a/doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running.mdwn b/doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running.mdwn
new file mode 100644
index 0000000000..7f7a482b9c
--- /dev/null
+++ b/doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running.mdwn
@@ -0,0 +1,5 @@
+I’m just experimenting with git-annex on a repo of ~150k files in about the same number of directories (WORM-backend). Calling, e.g., «git annex status» will take several minutes while stat()-ing all the files (for changes, I presume).
+
+This might already be on you todo list, but I was wondering whether it is possible to increase the performance of «annex status» (or related commands) when «annex watch» is running in the background. In that case, «status» could rely on cached data built-up at some point during initialization, plus based on the data that was accumulated via inotify. (Hopefully, all this won’t even be needed anymore on btrfs at some point in the future.)
+
+(I’m not very knowledgable in these things, so just out of curiosity: I noticed that, even though the «status» invocation takes ages, no HDD activity occurs and all the metadata is probably already in the Linux caches from a run I conducted immediately beforehand. Why do you figure that is? Is context switching so hugely expensive?)
diff --git a/doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running/comment_1_e5f2630591ffa7758ca4250a061a8589._comment b/doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running/comment_1_e5f2630591ffa7758ca4250a061a8589._comment
new file mode 100644
index 0000000000..446562f858
--- /dev/null
+++ b/doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running/comment_1_e5f2630591ffa7758ca4250a061a8589._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 1"
+ date="2014-07-10T19:37:38Z"
+ content="""
+Neither `git annex watch` nor the `assistant` persistently store any data about the files in the repository in memory. They cannot speed up `git annex status`.
+
+I'm not sure what's the point of running `git annex status` while the daemon is running, since the daemon will normally immediately notice changes and commit them. The status output should thus generally be empty.
+
+FWIW, `git annex status` takes 0.3s in my largest repo (55k files), on an SSD. That's in indirect mode, and the time is almost completely spent in running `git ls-files --modified`, which is probably about as fast as it can be. In a direct mode repository, it will be rather slower, since it has to query git for the key that was last committed for each file, in order to look up that key's info and see if the file has been modified. 
+"""]]
diff --git a/doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running/comment_2_f8a5cc905d5b06bdbb1a778ab866a28c._comment b/doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running/comment_2_f8a5cc905d5b06bdbb1a778ab866a28c._comment
new file mode 100644
index 0000000000..315569ca15
--- /dev/null
+++ b/doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running/comment_2_f8a5cc905d5b06bdbb1a778ab866a28c._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="134.147.14.84"
+ subject="comment 2"
+ date="2014-07-11T11:46:08Z"
+ content="""
+Yes, you’re probably right that the benefit of this is slim when the
+watching daemon auto-adds new files. So the «status» output would
+never change and show the status that upheld before starting the
+daemon.
+
+The reason I brought this up that I recall reading a comment of yours
+somewhere on the site, to the effect that the assistant can sometimes
+speed up certain operations, because it can make certain valid
+assumptions on the state of the repo due to the fact that the
+assistant has been monitoring it. I don’t recall what those operations
+were, though. That’s why it occurred to me whether there might be a
+daemon that just monitors via inotify, and neither adds nor syncs, and
+only provides information to certain commands to speed things up under
+some circumstances.
+
+In general, is it accurate to say that git-annex mostly takes the
+«space» option when making a space/time-trade-offs? I noticed that the
+memory consumption is really slim most of the time, and wondered
+whether there might be options of speeding operations up by relying on
+more memory instead (perhaps also doing persistent caching). On the
+other hand, in some regards you are probably committed to the
+time/memory trade-offs taken by vanilla git, so maybe there’s not much
+room for improvement, git-annex wise…
+
+Maybe direct-mode repos on the order of 100k’s of files are just not
+practical. I’m using indirect mode for my really big repos now, and
+it’s now responsive enough to use (except for «annex unused», which is
+inherently expensive, as you once explained). At least commiting won’t
+take tens of minutes that way. I’ll just have to make the software
+play nicely with the symlinks.
+
+BTW, the file-system seems to have a huge impact on this. My large
+direct mode annex is practically unusable on ext (tens of minutes per
+commit), but still usable on btrfs (a few minutes). I’m migrating one
+disk to btrfs at home and will do some controlled benchmarks then. The
+added bonus is that directories don’t always take up a full block.
+
+"""]]
diff --git a/doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running/comment_3_626c629654508d0d948ece849d43ed86._comment b/doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running/comment_3_626c629654508d0d948ece849d43ed86._comment
new file mode 100644
index 0000000000..58cf33c105
--- /dev/null
+++ b/doc/todo/Faster___171__git_annex_status__187___when___171__git_annex_watch__187___is_running/comment_3_626c629654508d0d948ece849d43ed86._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="134.147.14.84"
+ subject="comment 3"
+ date="2014-07-11T11:54:26Z"
+ content="""
+Ah, interesting, some caching ideas are already discussed at [https://git-annex.branchable.com/design/caching_database/].
+"""]]
diff --git a/doc/todo/File_deletion_workflow.mdwn b/doc/todo/File_deletion_workflow.mdwn
new file mode 100644
index 0000000000..a35b2c5ce7
--- /dev/null
+++ b/doc/todo/File_deletion_workflow.mdwn
@@ -0,0 +1,24 @@
+In a perfect world, we could hoard infinite amounts of data but unfortunately, our world is a finite one and we need to delete stuff sometimes.
+
+# Current situation
+
+You can drop files but that's seems to be intended for when you want to get rid of singular copies of a file in some repos, while copies in other repos remain untouched.    
+Dropping files with `--force` works but only drops from the current repo and thus needs to be run for each file on every remote which is cumbersome and, more importantly, error-prone.  
+You can also drop keys using `dropunused` but the same downsides apply here and you might want to keep old version of all the other files around (that's kinda the point of managing them with git).
+
+Dropping files completely like this also makes fsck complain about their inexistance. Fsck shouldn't care about intentionally deleted files.
+
+You can `dead` unwanted files to make fsck semi-ignore them but that should be reserved for unintentionally lost files and is a bit cumbersome (`git annex dead --key $(readlink path/to/file) && git annex drop path/to/file && git rm path/to/file`). It also still doesn't propagate deletion to remotes; they will (and should!) hold on to copies of seemingly dead keys.
+
+Thus, there needs to be a new specific workflow for intentionally deleting files.  
+A user needs to be able to express: "These files, I don't need them anymore. Delete them from all my repos please.".  
+
+Ideally, this should be a very explicit action to avoid accidental deletion.  
+What's important though is that this workflow doesn't involve manually running magic git annex commands for every deleted file on all possible remotes (especially not hard to reach ones). An explicit deletion should be final, irreversible.
+
+# Implementation
+
+[There has been some discussion around specific implementations of a deletion workflow few years ago already](https://git-annex.branchable.com/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/)
+
+I'd personally like to see a recycle bin in the form of a special (gitignored?) directory inside the working tree where deleted files would land. One could then either delete the files from the bin (thus marking them for final deletion) or move them back into the repo, cancelling deletion. (Any copy present in the regular working tree should imply that the file is wanted.)  
+This would be quite a simple workflow from a user's perspective IMO and would mimic the behaviour of all major desktop environments (Windows, OSXI, GNOME, KDE).
diff --git a/doc/todo/File_deletion_workflow/comment_1_7b80d9a202ede51730cbd443731e1fa7._comment b/doc/todo/File_deletion_workflow/comment_1_7b80d9a202ede51730cbd443731e1fa7._comment
new file mode 100644
index 0000000000..2a42f8d313
--- /dev/null
+++ b/doc/todo/File_deletion_workflow/comment_1_7b80d9a202ede51730cbd443731e1fa7._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-10-15T16:21:19Z"
+ content="""
+Since this was posted, fsck has stopped complaining about files dropped
+with `dropunused`.
+
+> What's important though is that this workflow doesn't involve manually
+> running magic git annex commands for every deleted file on all possible
+> remotes (especially not hard to reach ones).
+
+If a repository is not accessible, this is difficult to implement.
+
+It seems that the closest we can get to implementing it is
+something like `dropunused`, which can be run in that inaccessible
+repository at some later point when it's accessible, and catch up on
+dropping all the files that have become unwanted while it was inaccessible.
+
+One way to do that without relying on the idea of "unused" would be to tag
+a file with metadata saying its content ought to be deleted from
+everywhere. That is possible to do now, eg:
+
+	git annex metadata --tag deletethis foo
+	git annex drop --all --metadata tag=deletethis --force
+
+That drop can be run in every clone over time to delete all the tagged
+files.
+
+I could imagine formalizing this ad-hoc tag into something standard in
+git-annex. Perhaps similar to how dead files are currently indicated.
+But one problem with it is it may not play well in multiuser
+environments where people have different ideas about what files they want
+to delete all copies of. If two users are using dropunused and have a
+disagreement, they will have 2 different branches, which are forked, and
+neither will step on the other's toes when they run dropunused against
+their branches and drop content that is still used on the other person's
+branch. But a tag like "deletethis" is repository global.
+"""]]
diff --git a/doc/todo/File_deletion_workflow/comment_2_60b54e6bbb37464697b4f5c4ebe561da._comment b/doc/todo/File_deletion_workflow/comment_2_60b54e6bbb37464697b4f5c4ebe561da._comment
new file mode 100644
index 0000000000..6c43e974c1
--- /dev/null
+++ b/doc/todo/File_deletion_workflow/comment_2_60b54e6bbb37464697b4f5c4ebe561da._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 2"
+ date="2021-10-19T12:26:33Z"
+ content="""
+> Since this was posted, fsck has stopped complaining about files dropped with `dropunused`.
+
+Thank you!
+
+> I could imagine formalizing this ad-hoc tag into something standard in git-annex.
+
+This is the best option I think; some sort of flag you can set on a key that marks it as unwanted and propagates via the git-annex branch.
+The actual deletions could then be carried out on the individual repos by using a dedicated command (`dropdeleted`?), by the assistant or perhaps even using `sync --content`. 
+
+The important bit is that it shouldn't be synchronous or depend on the repository being reachable directly though; it should be recorded and propagated asynchronously.  
+E.g. in any tree of repos with assistants running (so, no transitive connections), marking a key as deleted in any one of them should result in the key being deleted from all of them.
+
+> But one problem with it is it may not play well in multiuser environments where people have different ideas about what files they want to delete all copies of.
+
+Ah, I didn't consider that. A recycle bin with tracked files is likely infeasible but an untracked one could still be valuable. That's a topic for another issue though.
+
+"""]]
diff --git a/doc/todo/Filter_a_tree_with_pattern.mdwn b/doc/todo/Filter_a_tree_with_pattern.mdwn
new file mode 100644
index 0000000000..c32996446a
--- /dev/null
+++ b/doc/todo/Filter_a_tree_with_pattern.mdwn
@@ -0,0 +1,55 @@
+Git-annex is able to create trees that are a perspective of the "real" tree via adjustment and metadata-driven views. 
+
+It would be useful if git-annex was also able to create trees that are the same as the main branch but only include a subset of the files; decided based on internal and external metadata.
+
+Use-cases:
+
+* Only check out subtitles in a specific language to reduce clutter
+* Only check out movies in one format
+* Only check out images with a certain metadata tag
+* Only check out files that are present
+
+Some of these are already possible but would require manual metadata tagging or would result in a totally different tree. This can be confusing to both users and software.
+
+UX examples:
+
+```
+$ ls Movies/
+movie.mkv movie.iso movie.mp4 movie.en_US.ass movie.de_DE.ass
+$ git annex filterview include=*.mkv
+$ ls Movies/
+movie.mkv
+$ git annex filterview include=*.mp4 or include=*.enUS.ass
+$ ls Movies/
+movie.mp4 movie.en_US.ass
+$ git annex filterview reset
+$ ls Movies/
+movie.mkv movie.iso movie.mp4 movie.en_US.ass movie.de_DE.ass
+$ git annex get Movies
+$ git annex filterview in=here
+$ ls Movies/
+movie.mkv movie.iso movie.mp4 movie.en_US.ass movie.de_DE.ass
+$ git annex drop Movies/*.ass
+$ ls Movies/
+movie.mkv movie.iso movie.mp4
+$ ls Photos/Cats/
+very_cute.jpg awwwww.jpg :3.jpg
+$ git annex filterview year=2022
+$ ls Photos/Cats/
+very_cute.jpg :3.jpg
+```
+
+Discussion points:
+
+* Should filters be additive or replace the old one?
+* Should it be possible to apply a filter to just a subtree?
+
+***
+
+Another useful feature that is tangentially related would be something like this:
+
+```
+$ git annex filterview root=Movies/
+$ ls
+movie.mkv movie.iso movie.mp4 movie.en_US.ass movie.de_DE.ass
+```
diff --git a/doc/todo/Filter_a_tree_with_pattern/comment_1_17dac31227b8f95c5ca50f4a4cf5a425._comment b/doc/todo/Filter_a_tree_with_pattern/comment_1_17dac31227b8f95c5ca50f4a4cf5a425._comment
new file mode 100644
index 0000000000..fb2ddcdde1
--- /dev/null
+++ b/doc/todo/Filter_a_tree_with_pattern/comment_1_17dac31227b8f95c5ca50f4a4cf5a425._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-06-13T17:39:41Z"
+ content="""
+Most of this can be done with either `git-annex adjust --hide-missing` or views. 
+
+The only thing that cannot is limiting files to those matching a glob,
+though views can limit files to the contents of directories.
+
+Unfortunately, adjusted branches and views don't compose. There is a todo
+about that, [[todo/unify_adjust_with_view]]. I think that is what you're
+looking for, or very close.
+"""]]
diff --git a/doc/todo/Filter_a_tree_with_pattern/comment_2_e2b0b3eafdfdab1e315066ac57c8b838._comment b/doc/todo/Filter_a_tree_with_pattern/comment_2_e2b0b3eafdfdab1e315066ac57c8b838._comment
new file mode 100644
index 0000000000..d63812f750
--- /dev/null
+++ b/doc/todo/Filter_a_tree_with_pattern/comment_2_e2b0b3eafdfdab1e315066ac57c8b838._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 2"
+ date="2022-06-22T12:34:45Z"
+ content="""
+My main use-case is actually the glob patterns; the first two use-cases. The other ones would just come as a bonus thanks to git-annex-matching-expressions.
+
+"""]]
diff --git a/doc/todo/Filter_a_tree_with_pattern/comment_3_ca3058fe82eff771f3664ab2f8aa78ae._comment b/doc/todo/Filter_a_tree_with_pattern/comment_3_ca3058fe82eff771f3664ab2f8aa78ae._comment
new file mode 100644
index 0000000000..f76d855997
--- /dev/null
+++ b/doc/todo/Filter_a_tree_with_pattern/comment_3_ca3058fe82eff771f3664ab2f8aa78ae._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-01-25T17:11:33Z"
+ content="""
+Well, ajusted branches and views can be composed now.
+
+Leaving this open for the glob patterns.
+"""]]
diff --git a/doc/todo/Fsck_remote_files_in-flight.mdwn b/doc/todo/Fsck_remote_files_in-flight.mdwn
new file mode 100644
index 0000000000..93bd87f2a0
--- /dev/null
+++ b/doc/todo/Fsck_remote_files_in-flight.mdwn
@@ -0,0 +1,7 @@
+When fsck'ing a remote repo, files seem to be copied from the remote to a local dir (thus written to disk), read back again for checksumming and then deleted.
+
+This is very time-inefficient and wastes precious SSD erase cycles which is especially problematic in the case of special remotes because they can only be fsck'd "remotely" (AFAIK).
+
+Instead, remote files should be directly piped into an in-memory checksum function and never written to disk on the machine performing the fsck.
+
+> [[done]] per my comments --[[Joey]] 
diff --git a/doc/todo/Fsck_remote_files_in-flight/comment_1_1a70ae7c9821d664ddf72fd4c431be29._comment b/doc/todo/Fsck_remote_files_in-flight/comment_1_1a70ae7c9821d664ddf72fd4c431be29._comment
new file mode 100644
index 0000000000..7c6f486e88
--- /dev/null
+++ b/doc/todo/Fsck_remote_files_in-flight/comment_1_1a70ae7c9821d664ddf72fd4c431be29._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-14T17:07:50Z"
+ content="""
+Only some remotes support checksums in-flight; this recently includes
+downloads from other git-annex repositories over ssh. Progress
+on that front is being tracked at
+<https://git-annex.branchable.com/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/>
+Most special remotes can't yet, but that should change eventually
+for at least some of them.
+
+I've made fsck notice when content was able to be verified as part of a
+transfer, and avoid a redundant checksum of them.
+
+What I've not done, and don't think I will be able to, is make the file
+not be written to disk by fsck in that case. Since the `retrieveKeyFile`
+interface is explicitly about writing to a file on disk, it would take ether
+a whole separate interface being implemented for all remotes that avoids
+writing to the file when they can checksum in flight, or it would need
+some change to the `retrieveKeyFile` interface to do the same.
+
+Neither seems worth the complication to implement just to reduce disk IO in
+this particular case. And it seems likely that, for files that fit in
+memory, it never actually reaches disk before it's deleted. Also if this is
+a concern for you, you can I guess avoid fscking remotes too frequently or
+use a less fragile medium?
+"""]]
diff --git a/doc/todo/Fsck_remote_files_in-flight/comment_2_3baff888fbc3068571cdc9fee73fbe36._comment b/doc/todo/Fsck_remote_files_in-flight/comment_2_3baff888fbc3068571cdc9fee73fbe36._comment
new file mode 100644
index 0000000000..35c53cd76c
--- /dev/null
+++ b/doc/todo/Fsck_remote_files_in-flight/comment_2_3baff888fbc3068571cdc9fee73fbe36._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-10-14T15:55:14Z"
+ content="""
+Checksum during transfer is now implemented for as many remotes as it
+reasonably can be, which is almost all of them. But not 100% of all
+remotes in all circumstances. And there's no way to know if a remote
+will support it before doing the transfer.
+
+To avoid changing the API, it occurs to me that retrieveKeyFile could be
+passed `/dev/null`. But any remote that does not support resuming and tries
+to overwrite the existing destination file would fail.
+
+Also some kinds of remotes download to the file in one process or thread
+and while the download is happening, git-annex checksums the file as new
+data appears in it. External special remotes in particular do this.
+That would break with `/dev/null` too.
+
+Putting the temp file on some other medium seems like the only way to
+address this. If there were a config of a directory to use, you could point
+it at a disk rather than the SSD, or even at a ram disk, if you have
+sufficient memory. Unsure if it's worth adding such an option though,
+probably few people would use it. And cloning the repository onto the other
+medium and running the remote fsck from there would have the same result
+without needing an option.
+
+I'm inclined to close this, since I don't think it can be addressed.
+"""]]
diff --git a/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext.mdwn b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext.mdwn
new file mode 100644
index 0000000000..c54e0e0580
--- /dev/null
+++ b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext.mdwn
@@ -0,0 +1,13 @@
+Currently, SHA256E creates duplicate files for different extensions, i.e.:
+
+```
+$ l * && l -Li * && sha256sum *
+lrwxrwxrwx 1 atemu users 198 2021-05-04 03:47 random.1 -> .git/annex/objects/F9/Kk/SHA256E-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a.1/SHA256E-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a.1
+lrwxrwxrwx 1 atemu users 198 2021-05-05 10:01 random.2 -> .git/annex/objects/Pm/J1/SHA256E-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a.2/SHA256E-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a.2
+ 3720 -r--r--r-- 1 atemu users 100M 2021-05-04 03:47 random.1
+49696 -r--r--r-- 1 atemu users 100M 2021-05-05 10:01 random.2
+2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a  random.1
+2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a  random.2
+```
+
+These have the exact same content though, they could be hardlinks of one another instead and nothing would change.
diff --git a/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_1_5af33851bdac4f34d83e8ef2e1d45355._comment b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_1_5af33851bdac4f34d83e8ef2e1d45355._comment
new file mode 100644
index 0000000000..3ad2e200f6
--- /dev/null
+++ b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_1_5af33851bdac4f34d83e8ef2e1d45355._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="different keys for the same content"
+ date="2021-05-07T15:37:46Z"
+ content="""
+Related: [[todo/alternate_keys_for_same_content]]
+"""]]
diff --git a/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_2_ad76bcde941d6f1719260179a7bd27ba._comment b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_2_ad76bcde941d6f1719260179a7bd27ba._comment
new file mode 100644
index 0000000000..48a74a8510
--- /dev/null
+++ b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_2_ad76bcde941d6f1719260179a7bd27ba._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-07-13T16:20:10Z"
+ content="""
+There is some precident for this; `git annex migrate`
+hard links the annex objects for the old and new key.
+
+But hard links are also used for unlocked files with annex.thin,
+and when the object file is hard linked to somewhere already,
+it is unable to hard link it to the unlocked file location, and so
+annex.thin doesn't work.
+
+It would perhaps make sense for such a hard link to be broken when
+populating an unlocked file when annex.thin is enabled. Ie, replace
+the object file with a copy of itself. Which can then be hard linked to the
+unlocked file. That would also improve the situation when it's been
+migrated.
+
+This feature would also need a way to find all the other equivilant keys
+that are in use, which would have to be done whenever an object file gets
+populated. So it would need to be very fast, otherwise it would slow down
+eg `git annex get`. While the keys database does have the necessary
+information in it (finally), it would need to select keys matching a
+pattern, which I doubt would be an optmised query, even if the index
+in the database can be used. 
+(See <https://sqlite.org/optoverview.html#like_opt>)
+Even if the query were optimised, it could turn out to be a significant
+speed hit.
+
+And I have a feeling that most people bothered by this duplication
+would just do better to migrate away from SHA256E to SHA256..
+"""]]
diff --git a/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_3_51945c553d70ae76297ed4aaf3c8b624._comment b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_3_51945c553d70ae76297ed4aaf3c8b624._comment
new file mode 100644
index 0000000000..b21a50d24e
--- /dev/null
+++ b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_3_51945c553d70ae76297ed4aaf3c8b624._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 3"
+ date="2021-07-13T21:13:12Z"
+ content="""
+> when the object file is hard linked to somewhere already, it is unable to hard link it to the unlocked file location
+
+Why? You should be able to create as many hardlinks of any hardlink as you please or am I missing something? A \"regular\" file is just a hardlink with refcount = 1 and if it works there, it should work for any other refcount.
+
+> This feature would also need a way to find all the other equivilant keys that are in use, which would have to be done whenever an object file gets populated. So it would need to be very fast, otherwise it would slow down eg `git annex get`.
+
+A simpler approach might be to change the file layout so that files with the same hash are always in the same directory, I.e.:
+
+```
+.git/annex/objects/F9/Kk/SHA256E-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a.1/SHA256E-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a.1
+.git/annex/objects/Pm/J1/SHA256E-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a.2/SHA256E-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a.2
+```
+
+->
+
+```
+.git/annex/objects/F9/Kk/SHA256E-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a/SHA256E-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a.1
+.git/annex/objects/F9/Kk/SHA256E-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a/SHA256E-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a.2
+```
+
+This is basically the SHA256 backend but the files in the final dir in have the respective extensions like the SHA256E backend but they are hardlinks of another (SHA256H^ybrid/SHA256H^ardlink ?).
+
+Lookups should be super cheap with this method because files with the same hash are simply in the same directory as all the others. These probably shouldn't be treated as separate keys either but as \"instances\" of the same key.
+"""]]
diff --git a/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_4_2f496cb303c90eaefef955082e2bfb00._comment b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_4_2f496cb303c90eaefef955082e2bfb00._comment
new file mode 100644
index 0000000000..e0f18a96c6
--- /dev/null
+++ b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_4_2f496cb303c90eaefef955082e2bfb00._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-07-14T15:57:43Z"
+ content="""
+@Atemu because the hard link to an unlocked file risks
+it being modified, and losing the content of another key
+is outside the risk profile allowed by annex.thin.
+
+Also it could be hard linked for other reasons, like
+a local clone does, and that also should not be exposed
+to modification.
+
+Moving all the object files to the same directory does not
+help in the case of git-annex get, where the object files
+don't exist yet. It would still need a way to find all the equivilant keys
+to populate those.
+"""]]
diff --git a/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_5_272be474bd9ee8d087821bd8a6e88175._comment b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_5_272be474bd9ee8d087821bd8a6e88175._comment
new file mode 100644
index 0000000000..e5dd0d0e26
--- /dev/null
+++ b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_5_272be474bd9ee8d087821bd8a6e88175._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 5"
+ date="2021-07-14T21:27:42Z"
+ content="""
+> the hard link to an unlocked file risks it being modified, and losing the content of another key is outside the risk profile allowed by annex.thin
+
+I see. I guess annex.thin's risk profile would simply need to be different when using SHA256H then. If you use annex.thin with hardlinks, you're at high risk of accidental modification anyways, so that wouldn't be much of a change tbh.
+
+Also, since it'd be the exact same file and key, such behaviour should be expected and would be exactly the same as with the SHA256 backend.
+
+> Moving all the object files to the same directory does not help in the case of git-annex get, where the object files don't exist yet. It would still need a way to find all the equivilant keys to populate those.
+
+I'm not 100% familiar with how `get` works but what I'm thinking of might work like this:
+
+`git annex get random.1`
+
+```
+file = \"random.1\" 
+key = keyOf file = \"SHA256-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a\"
+ext = extOf file = \".1\"
+pathWanted = hybridPathOf key ext = \".git/annex/objects/F9/Kk/SHA256-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a/SHA256H-s104857600--2fdbdc9c3b23d1986a743aede593765e57ade9f173f9fd9766057f0efd63197a.1\"
+sha256Path = pathOf key
+
+when (!inLocalAnnex key) (fetch key)
+unless (fileExists pathWanted) (hardLink sha256Path pathWanted)
+```
+
+SHA256H should behave just like SHA256 here; it gets the SHA256-indexed key with the same logic. The only difference should be that it adds another file with a suffix when writing.
+
+"""]]
diff --git a/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_6_be9a58f2028fb3c155ff2020dee2b46b._comment b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_6_be9a58f2028fb3c155ff2020dee2b46b._comment
new file mode 100644
index 0000000000..e95d44df16
--- /dev/null
+++ b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_6_be9a58f2028fb3c155ff2020dee2b46b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-07-15T16:19:02Z"
+ content="""
+But making a hardlink from SHA256-foo.1 to SHA256-foo does
+not help when another file calls it SHA256-foo.2 ...
+"""]]
diff --git a/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_7_fed82ecac17e6ed86eb18232d4b5ae6a._comment b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_7_fed82ecac17e6ed86eb18232d4b5ae6a._comment
new file mode 100644
index 0000000000..99716212a8
--- /dev/null
+++ b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_7_fed82ecac17e6ed86eb18232d4b5ae6a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 7"
+ date="2021-07-16T11:21:43Z"
+ content="""
+Ah I see. The whole tree would have to be scanned for SHA256H references of a certain SHA256 key on `get` and tree-modifying commands like `checkout`.
+
+With the existing backends that doesn't need to happen since the key existing in the local repo implies that it is reachable via the symlinks in the checkout.
+
+Trickier than I had anticipated, thank you for your insights!
+
+Maybe the extension aliases of a key could be recorded and simply applied in every repo a key exists in. This might require another lookup on get (though it could perhaps be done in the same lookup) but, since it'd require a lookup of a key anyways under SHA256E because they're entirely separate, we wouldn't lose on performance either.  
+The only problem would be propagating new aliases on `sync`...
+"""]]
diff --git a/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_8_82c04709fe3b69d6a75e44d71b500681._comment b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_8_82c04709fe3b69d6a75e44d71b500681._comment
new file mode 100644
index 0000000000..a4c8c90da7
--- /dev/null
+++ b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_8_82c04709fe3b69d6a75e44d71b500681._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2021-07-16T19:13:36Z"
+ content="""
+Right. It is possible to get this into a sqlite database and update it
+incrementally. The keys database is populated this way, but that's by
+tracking changes to the HEAD branch. This would instead involve
+tracking changes to the git-annex branch.
+
+See [[cache_key_info]] for discussion of this kind of thing.
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add.mdwn b/doc/todo/Having___39__git_annex_sync__39___optionally_add.mdwn
new file mode 100644
index 0000000000..5a357bb233
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add.mdwn
@@ -0,0 +1,38 @@
+Hey joey,
+
+Currently, there is no one-command-to-rule-them-all to actually 'get the repo synced entirely'. Current workarounds:
+
+[[!format  bash """
+# plain git-annex
+git annex add
+(git add -A) # for the weird filter issues, see https://github.com/datalad/datalad/issues/7268
+git annex sync --content
+
+# with DataLad
+datalad save # no way around the weird filter issues currently
+git annex sync --content
+"""]]
+
+Whenever I introduce new people to git annex, it's always a pain point to explain these multiple steps. It would be awesome to have just one command that syncs everything. Especially for beginners.
+
+`git annex sync` already does quite a bit including `git add`ing and `git commit`ting changes to tracked files. However it doesn't add new files. It would be awesome if `git annex sync` could optionally also do `git annex add`:
+
+[[!format  bash """
+# configure 'git annex sync' to run 'git annex add' before as well (opt-in)
+git annex config --set annex.syncadd true
+# have it sync the content as well
+git annex config --set annex.synccontent true
+
+# From then on, 'git annex sync' does a *real* sync: everything that's new/changed here gets pushed elsewhere and new changes get pulled as well.
+git annex sync
+
+# This would then basically be a poor-mans-git-annex-assistant 😛
+while true;do git annex sync --content;done
+"""]]
+
+
+What do you think?
+
+Cheers, Yann
+
+> [[done]] as `git-annex assist` --[[Joey]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_10_6d9ef10f9534c7b95ca58913cfe3b5fd._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_10_6d9ef10f9534c7b95ca58913cfe3b5fd._comment
new file mode 100644
index 0000000000..be5c98392b
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_10_6d9ef10f9534c7b95ca58913cfe3b5fd._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2023-05-18T17:45:44Z"
+ content="""
+Implementing `git-annex assist` now...
+
+A tricky point is, should it add files only in the current directory and
+below, or all files in the repository? Note that the assistant can be run
+in a directory and it will only add changed/new files in that directory,
+although it can receive pulls that change files in other directories
+(and will then download those files content).
+
+OTOH, `git-annex sync` commits all changes, not only those in the
+current directory. (The assistant does in some circumstanges commit
+changes made outside the current directory. Its behavior is a bit
+inconsistent in this area.)
+
+So I think it makes sense for `git-annex assist` to only add files in the
+current directory by default. (Of course an option like -A could be added
+later.)
+
+And while I'm a bit ambivilant about it, I'm making it commit all staged
+changes, not only those in the current directory. As well as following the
+behavior of `git-annex sync` and to an extent the assistant, it seems to 
+me that if you run `git-annex add ../foo; git-annex assist`, you are
+intentionally building up a commit that includes file "foo". The same
+as if you ran `git-annex add ../foo; git-annex add .` ... If you're not,
+and you care about what files get added in what commit, you can of course
+commit manually.
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_11_25be855ca688e37644fa86357b96b3d2._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_11_25be855ca688e37644fa86357b96b3d2._comment
new file mode 100644
index 0000000000..898518f353
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_11_25be855ca688e37644fa86357b96b3d2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="👍 git annex assist"
+ date="2023-05-19T05:54:43Z"
+ content="""
+Cool, joey!
+
+I personally would like `assist` to add all changes in the entire repo by default. For beginners it's always a hassle to know what directory one is in and if one opens a terminal in a subfolder via a file manager, then run `git annex assist`, it won't sync all changes.
+
+But I see that this would be inconsistent with `git annex add`... On the other hand, `assist` should help you easily sync the repo state without typing too much. One can always do `git annex assist .` for only this directory. A `-A` option is also an option, but effectively one would need to use it every time. As you said in the other comment - if you want more control, use the lower level commands. The assistant makes syncing a no-brainer, `git annex assist` should do so, too.
+
+That the assistant can operate on only a subdir (do people do this?) itself is again an inconsistency then... A config like `annex.assistaddall` could be introduced, but meh...
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_12_8327e0a3f3d4bf35c52b1f2f4089dcbc._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_12_8327e0a3f3d4bf35c52b1f2f4089dcbc._comment
new file mode 100644
index 0000000000..5a2a2033d8
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_12_8327e0a3f3d4bf35c52b1f2f4089dcbc._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2023-05-19T18:37:28Z"
+ content="""
+I'm also not too happy with the inconsistency of assist committing all staged
+changes and syncing all file contents, but only adding files in the cwd.
+
+I suppose that consistency with the assistant doesn't really matter. The
+assistant's behavior when ran in a subdirectory is surprising,
+inconsistent, and undocumented.
+
+So I'm going to change assist to add all files. Except when -C is used,
+then only add files in the specified directory.
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_13_8b150a2a4b9b0de8039ee8995c01bf8c._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_13_8b150a2a4b9b0de8039ee8995c01bf8c._comment
new file mode 100644
index 0000000000..ad680ade0b
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_13_8b150a2a4b9b0de8039ee8995c01bf8c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 13"
+ date="2023-05-20T06:03:30Z"
+ content="""
+Sounds good! Maybe also a `-m` short form of `--message` for less typing. Consistent with sync and datalad save.
+
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_14_0156a70246f19beeee6ce5cfb510de86._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_14_0156a70246f19beeee6ce5cfb510de86._comment
new file mode 100644
index 0000000000..dc07b3495d
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_14_0156a70246f19beeee6ce5cfb510de86._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2023-05-23T15:46:27Z"
+ content="""
+Oh, this new command and sync always supported -m. I've added it to the man
+page. 
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_15_b0f6d52ef7a94badd572c6cfa759efb3._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_15_b0f6d52ef7a94badd572c6cfa759efb3._comment
new file mode 100644
index 0000000000..8972a3b1b7
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_15_b0f6d52ef7a94badd572c6cfa759efb3._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="Breaking change to &quot;sync&quot;"
+ date="2023-07-12T10:21:03Z"
+ content="""
+Via a comment on [my bug about the new `sync` warning suddenly appearing in 10.20230626](https://git-annex.branchable.com/bugs/Changing_sync_to_include_content_breaks_UX/?updated) I see that this fairly hidden discussion seems to have been the rationale for completely changing what \"sync\" does \"because some users expect it to do everything\".
+
+At the beginning of the design I might have agreed with you about \"what the sync command should do\" (and having another, eg, \"metasync\" command for the smaller version).  But changing a fundamental command, a decade later, to do something different, based entirely on a \"wouldn't it have been nice (for some use cases) if...\" seems quite a stretch.
+
+As per the other bug, if you want to implement new behaviour for such a fundamental command (\"git annex sync\" is something one runs pretty constantly if using git annex actively from the command line) then it'd be best to implement it in another command name, instead of dramatically changing an existing one.  (The other thread has a few more suggestions; I personally still like \"fullsync\" for the expanded version.)
+
+Either way, such a major -- behaviour breaking -- change needs to be much better documented than \"discussion in a bug that a few people saw\", and a note in passing in a changelog (which people have to find by noticing strange new output in probably scripted git annex usage).
+
+Ewen
+
+PS: I too think it's a terrible idea to have git annex default to auto-adding any files it can find.  Maybe that makes some \"Dropbox-like\" use cases nicer, but it also entirely breaks other long standing use cases.
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_16_6c4c1541a146c66c11ebe6abaf7f1810._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_16_6c4c1541a146c66c11ebe6abaf7f1810._comment
new file mode 100644
index 0000000000..5b4329eae5
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_16_6c4c1541a146c66c11ebe6abaf7f1810._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Clarification"
+ date="2023-07-12T11:29:41Z"
+ content="""
+@ewen for the record:
+
+I never suggested that `git annex sync` auto-adds new files by default, see [my comment above](http://git-annex.branchable.com/todo/Having___39__git_annex_sync__39___optionally_add/#comment-37c3eb24df11d85c07b78c0297447c45):
+
+> Exactly, I also would never want git annex sync to do the adding by default - strictly as an opt-in configuration.
+
+As `git annex sync` already had so many options for configuring its behaviour, I thought having one more that runs `git annex add` in the beginning wouldn't hurt. I never suggested changing `git annex sync`'s default behaviour. Purely opt-in. Same for the existing options like `annex.synccontent` etc.
+
+Changing `git annex sync`'s default behaviour of now syncing content was joey's idea, not mine.
+
+> if you want to implement new behaviour for such a fundamental command
+
+There is already `git annex assist` to do exactly that. See above or the changelogs.
+
+Just to clarify. Please read the discussions you're referring to thoroughly before claiming things between the lines. 🙂 
+
+Now back to constructive discussion.
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_1_2160800299fff5dc920847bec1ab0220._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_1_2160800299fff5dc920847bec1ab0220._comment
new file mode 100644
index 0000000000..5fdfb6bce5
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_1_2160800299fff5dc920847bec1ab0220._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="adding all files or only in current directory?"
+ date="2023-05-03T14:23:04Z"
+ content="""
+`git annex add` only adds files in the current directory and below and has no flag to do a `git add -A` equivalent. For the purpose of making `git annex sync` also adding all files (e.g. with `git annex sync --add` or with prior `git annex config --set annex.syncadd true`), such an `git annex add --all|-A` option would be handy (which would also be used by `git annex sync --add`). It would also make `git annex add` more consistent with `git add`.
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_2_eeb1bb0b1a02a74291daa41e9a8eb725._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_2_eeb1bb0b1a02a74291daa41e9a8eb725._comment
new file mode 100644
index 0000000000..0e1d8ee110
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_2_eeb1bb0b1a02a74291daa41e9a8eb725._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Git Alias for a 'full sync'"
+ date="2023-05-15T07:31:41Z"
+ content="""
+This alias pretty much does what I mean:
+
+[[!format  perl \"\"\"
+# set the alias
+git config --global alias.sync '!sh -xc '\"'\"'cd \"$(git rev-parse --show-toplevel)\";git annex add;git add -A;git annex sync'\"'\"''
+# This then goes into the repo root, adds stuff with git annex, adds the rest git-annex didn't add and syncs with git annex
+git sync
+\"\"\"]]
+
+
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_3_a49dcb3963a986c530571f69fa9326b4._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_3_a49dcb3963a986c530571f69fa9326b4._comment
new file mode 100644
index 0000000000..62b9ccbd36
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_3_a49dcb3963a986c530571f69fa9326b4._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-05-15T20:09:30Z"
+ content="""
+I don't think this can possibly become the default behavior, because plenty
+of users will have temporary files that they don't want to add (and haven't
+gitignored), or even sensitive files that happen to be in the same
+repository that it would be a security hole level surprise for `git-annex
+sync` to start adding, when it has not before.
+
+For the same reason, `git-annex config` couldn't be used to make this a
+default `git-annex sync` behavior. A local git config to enable it would be
+ok.
+
+It would would need to look at annex.largefiles, and add small files to git
+directly.
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_4_cf4ed68e05fd7d553a314746b444b7c0._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_4_cf4ed68e05fd7d553a314746b444b7c0._comment
new file mode 100644
index 0000000000..dbe999bfe8
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_4_cf4ed68e05fd7d553a314746b444b7c0._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 4"
+ date="2023-05-15T21:13:34Z"
+ content="""
+Exactly, I also would never want `git annex sync` to do the adding by default - strictly as an opt-in configuration.
+
+I see your point that people might have sensitive files in a repo that they don't have `.gitignore`d and would not want to get pushed. However, I argue:
+
+- If you clone a git annex repo and do `git annex sync` on it, you're pretty much already trusting that repo and the remotes. You either already have push access (that doesn't happen easily unless you're in control of the repo) or you don't, but then it's not a problem when you add your sensitive files because your changes won't ever get synced back. Even if they do at some later point: You `git annex drop --force` them (or just `git rebase -i`) to remove them from the repo entirely and worst case is that the file metadata is leaked back into the repo collection. Again, something I'd consider OK if you trust the repo.
+- When you trust a git annex repo, you also trust its `git annex config` settings like `synccontent` and consent with it.
+- Thus, if that repo has a `git annex config --set annex.syncadd true` setting that has `git annex sync` also do a prior `git annex add`, that's fine.
+
+I think that only having a local `git config annex.syncadd true` setting is basically the same as having a customized alias like mine above, so that doesn't really improve the situation: in both cases users of the repo need to do local configs. A `git annex config` will be stored in the repo and be immediately effective for everybody using it - a major benefit for collaboration, for which git annex is a golden tool. If I understand correctly, any `annex.*` config can be overridden locally with a `git config annex.*` setting (right?). So cautious users can have `git config --global annex.syncadd false` to prevent `git annex sync` from ever adding files, even if the repo is configured to do so.
+
+If the `git config annex.syncadd true` setting would just literally run `git annex add`, it automatically obeys the largefiles settings (also from the .gitattributes file).
+
+All in all I'd consider the `syncadd` a matching feature considering how much `git annex sync` is already doing: committing, pulling, merging, pushing all over the place - only the adding it doesn't do.
+
+The more behaviour can be configured in the repo directly, the better the out-of-the-box experience for (inexperienced) end users of a repo will be. I maintain many git annex repos and collaborate with different students like this on scientific projects. Together with [default preferred content expressions](https://git-annex.branchable.com/todo/Setting_default_preferred_content_expressions/) the workflow would be extremely straight-forward:
+
+[[!format  bash \"\"\"
+# get the repo
+git clone URL/repo
+cd repo
+# ”whenever you're done, run”:
+git annex sync
+# - auto-enables common remotes
+# - auto-sets preferred content expressions (to prevent the repos from uselessly downloading EVERYTHING - just what's sensible by default)
+# - auto-adds/commits/pulls/merges/pushes changes
+# - auto-syncs content around
+\"\"\"]]
+
+Sensible settings for largefiles in `.gitattributes` or the `git annex config` can be set by those who understand it, others just do `git annex sync` and are done with it.
+
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_5_3a2fe8d0c0dd6f5066370086c0f03300._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_5_3a2fe8d0c0dd6f5066370086c0f03300._comment
new file mode 100644
index 0000000000..559780738f
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_5_3a2fe8d0c0dd6f5066370086c0f03300._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-05-16T16:32:51Z"
+ content="""
+sync's intent is to replicate as close as possible the following common
+git workflow:
+
+	first stage some changes, and then run:
+	git commit -m foo
+	git pull
+	git push
+
+Since git-annex has some complications involving pulling and pushing 
+the git-annex branch, and transferring the content, it adds a learning
+curve that was too high. Giving users one new command to learn minimizes
+the learning curve. (It's unfortunate it didn't originally send content,
+and annex.synccontent aims to fix that oversight and I hope it may eventually
+become default.)
+
+For git-annex sync to default to doing something not in the above
+pull+commit+push workflow would be surprising, because that's the workflow
+users have been told it handles.
+
+Notice that the git-annex assistant will happily add all files to the
+repository and send their content. That's because it's *not* targeting
+users who expect to use that git workflow. So it's not surprising that it
+does what it does.
+
+In conclusion, if having this behavior enabled by git config is not useful,
+then it does not belong in `git-annex sync`. It could go in a new command.
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_6_2e0ad0cdb9d813d0fbc514c1642669ca._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_6_2e0ad0cdb9d813d0fbc514c1642669ca._comment
new file mode 100644
index 0000000000..e05874f65b
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_6_2e0ad0cdb9d813d0fbc514c1642669ca._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-05-16T17:05:35Z"
+ content="""
+I also generally feel like `git-annex sync` was probably a bad conflation
+of 3 git commands into 1 command when there could have just been `git-annex
+pull` and `git-annex push`. The fact that it conflates several things makes
+users think of it as just a big "does all the things" command, which makes
+users want it to do more things.
+
+It is not too late to split it up, and eventually deprecating it would be a
+good path to making annex.synccontent default.
+
+Update: Implemented `git-annex pull` and `git-annex push`, although I have
+no plans yet to deprecate `git-annex sync`.
+
+Update: I found a better path to transition to sync --content by
+default, and have started that transition. `git-annex pull/push` sync
+content by default already.
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_7_bb6b5503ec5f699749fa8e3ffce59aab._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_7_bb6b5503ec5f699749fa8e3ffce59aab._comment
new file mode 100644
index 0000000000..df6d21fe52
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_7_bb6b5503ec5f699749fa8e3ffce59aab._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2023-05-17T17:24:03Z"
+ content="""
+Brainstorming some names for a new command that is `git add -A` + sync...
+
+`git-annex publish` kind of implies more exposure of local files to others
+than just syncing. But it more implies sending data, not also receiving it.
+
+`git-annex addsync` is clear what it does, but not very memorable.
+
+`git-annex assist` has a nice analogy to the `git-annex assistant`,
+which is close in behavior. Users who don't know about the assistant
+will miss the analogy though. "assist" also suggests git-annex will take
+care of everything, even more broadly than sync.
+
+`git-annex share` also implies more exposure of local files than git-annex
+sync, and sharing goes both ways so it's better than `git-annex publish`.
+
+I'd be inclined toward `git-annex share` or `git-annex assist`, but welcome
+better ideas.
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_7_e6e6b344d533de57ce7661b5f1ada027._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_7_e6e6b344d533de57ce7661b5f1ada027._comment
new file mode 100644
index 0000000000..4941288362
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_7_e6e6b344d533de57ce7661b5f1ada027._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 7"
+ date="2023-05-17T10:41:18Z"
+ content="""
+Cool, thanks joey! 
+
+If you want to go as far as deprecating `git annex sync` (a huge change in habits for git-annex users if that one goes away), I wonder how adding the `annex.syncadd` config (a strictly opt-in consensus for users of a repo) is too much of a disruption 😅 But okay, you're the maintainer.
+
+I still think that having **one command** that does what the assistant does, but as a one-shot manual step, would benefit git-annex immensely. I recently tried running the assistant on my SailfishOS phone (https://fosstodon.org/@nobodyinperson/110203412944552425) and realised that having the assistant running in the background all the time is not ideal due to e.g. the power consumption - maybe due to the permanent SSH connection to the remotes. I am now using a systemd service that basically does `git annex add;git annex sync`. Would be awesome and certainly good for the understanding of new users if there was a command that basically one-steps the assistant - This is something I as a previous Syncthing user was dearly missing: one-stepping the syncing to see what's the bottleneck/problem/what it does exactly, etc. If you'd rather put this into a new command, I'm fine with that, though I still think `git annex sync` is a perfect candidate also due to the name. 
+"""]]
diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_9_e128886c09b9ca2127ff540c2af0beda._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_9_e128886c09b9ca2127ff540c2af0beda._comment
new file mode 100644
index 0000000000..3e523b0482
--- /dev/null
+++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_9_e128886c09b9ca2127ff540c2af0beda._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 9"
+ date="2023-05-18T08:40:37Z"
+ content="""
+Good suggestions, I'd prefer `assist`, as it'll be one step of what the assistant does. I'll also through `git annex update` into the ring. `update`ing goes both ways, `share`ing also sounds more like you getting your stuff out there, not necessarily others' stuff to you.
+"""]]
diff --git a/doc/todo/INFO_message_for_custom_special_remotes.mdwn b/doc/todo/INFO_message_for_custom_special_remotes.mdwn
new file mode 100644
index 0000000000..f0712adc46
--- /dev/null
+++ b/doc/todo/INFO_message_for_custom_special_remotes.mdwn
@@ -0,0 +1,6 @@
+I wondered if it would be sensible to ask to extend [externals special remote protocol](https://git-annex.branchable.com/design/external_special_remote_protocol/) with ability for custom remotes to pass back some INFO level message (not only DEBUG or ERROR).  The reason is:  in datalad-archives special remote we usually need to `git annex get` first the key containing the archive, which might be sizeable.  Since there is ATM no way to communicate back to git-annex, so it could communicate back to the datalad which runs it, it results in no output/message to the user that possibly a heavy download is happening in the background.  So, we would need to establish our own communication from datalad-archives special remote all the way to top level datalad process to report that, or I wondered if may be we could report back to git-annex, and it in turn report back to the original process (running e.g. `annex get --json --json-progress`) so it could spit out that message wrapped into a json record within the stream, so we could process and output that to the user.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/INFO_message_for_custom_special_remotes/comment_1_ea99a5099f78767859c05aeb5217a12d._comment b/doc/todo/INFO_message_for_custom_special_remotes/comment_1_ea99a5099f78767859c05aeb5217a12d._comment
new file mode 100644
index 0000000000..c2e9f318e9
--- /dev/null
+++ b/doc/todo/INFO_message_for_custom_special_remotes/comment_1_ea99a5099f78767859c05aeb5217a12d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-02-06T16:58:04Z"
+ content="""
+I've added it. However, note that previous versions of git-annex will
+not react well to an unknown message being sent, so to use it safely you
+will need to detect a new enough version of git-annex. (I've had a todo item
+on the protocol for a while to have a way to detect what messages git-annex
+understands.)
+"""]]
diff --git a/doc/todo/INFO_message_for_custom_special_remotes/comment_2_69535d7d9b7266eaac6f9bb70d2660dc._comment b/doc/todo/INFO_message_for_custom_special_remotes/comment_2_69535d7d9b7266eaac6f9bb70d2660dc._comment
new file mode 100644
index 0000000000..5714e78369
--- /dev/null
+++ b/doc/todo/INFO_message_for_custom_special_remotes/comment_2_69535d7d9b7266eaac6f9bb70d2660dc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-02-06T20:15:35Z"
+ content="""
+Great!  I will give it a shot.  No problem checking version of git-annex available so I will make it conditional on git-annex version.
+
+As for \"todo on protocol...\" -- FWIW I left some comments [close to original discussion](http://git-annex.branchable.com/design/exporting_trees_to_special_remotes/#comment-b3876cc7b791c6b8cb12949bdbbf8268)
+"""]]
diff --git a/doc/todo/Idea_for_emulating_a_versioned_tree_export.mdwn b/doc/todo/Idea_for_emulating_a_versioned_tree_export.mdwn
new file mode 100644
index 0000000000..18695f80db
--- /dev/null
+++ b/doc/todo/Idea_for_emulating_a_versioned_tree_export.mdwn
@@ -0,0 +1,72 @@
+Dear Joey,
+
+During DistriBits 2024, we discussed a concept that you seemed to like: emulating versioned tree export on a special remote with a non-versioned filesystem. This could be a generic mechanism of git-annex. Maybe a new option for the special remote (say: 'versioning = yes / no / emulated' or 'exporttree = yes / no / emulated')?
+
+The idea is to save target files in the remote at paths reflecting the ones in the repo, but:
+
+* create an extra directory at the end of the path identical to the filename,
+* directory name includes the original extension of the file, which may seem a bit odd, but ensures no ambiguities,
+* inside the directory, save the file under filename = key (preferably add the original extension).
+
+Example: the content of the git-annex repo and remote filesystem after a few tree exports:
+
+	[git-annex]
+	repo-name
+	|
+	|-- phd
+	|   |
+	|   |-- thesis.pdf
+	|   |-- images
+	|       |
+	|       |-- figure.png
+	|       |-- diagram.png
+	|
+	|-- guidelines.pdf
+
+
+	[remote filesystem]
+	repo-name
+	|
+	|-- phd
+	|   |
+	|   |-- thesis.pdf
+	|   |   |
+	|   |   |--- SHA256E-...-key1.pdf
+	|   |   |--- SHA256E-...-key2.pdf
+	|   |   |--- SHA256E-...-key3.pdf
+	|   | 
+	|   |-- images
+	|       |
+	|       |-- figure.png
+	|       |   |
+	|       |   |-- SHA256E-...-key1.png
+	|       |   
+	|       |-- diagram.png
+	|           |
+	|           |-- SHA256E-...-key1.png
+	|           |-- SHA256E-...-key2.png
+	|
+	|-- guidelines.pdf
+	|   |
+	|   |-- SHA256E-...-key1.pdf
+
+----------------------
+
+Advantages:
+
+* easy to implement,
+* you get (kind of) versioning on any POSIX-like filesystem,
+* older versions of files are never overwritten (history tracking),
+* it's sufficient to push only the changed files,
+* users can use the remote filesystem directly, as it represents something meaningful.
+
+Disadvantages:
+
+* not perfect,
+* users need to accept the inconvenience caused by file naming on the bottom level,
+* it may be hard to find the right file version in the remote, especially if there are lots of them;
+	- modification times will certainly help here,
+	- can we concatenate some extra information to the file names that could help in identification?
+
+
+Feel free to contact me, I'd be happy to discuss and help make this happen.
diff --git a/doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_1_d944fd707130be6ebe35302794a0b73f._comment b/doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_1_d944fd707130be6ebe35302794a0b73f._comment
new file mode 100644
index 0000000000..dba76ec6b8
--- /dev/null
+++ b/doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_1_d944fd707130be6ebe35302794a0b73f._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-04-08T20:46:26Z"
+ content="""
+When we were talking about this idea, I thought there was a problem, but
+didn't quite manage to find it then. 
+
+I see it now: If `foo` is an annexed file that gets exported
+this way to `foo/SHA--x`, and then that annexed file
+is deleted and a new annexed file `foo/SHA--x` is added,
+it will want to export it to `foo/SHA--x/SHA--y`.
+
+It would either fail because the file exists, or delete it and replace
+it with the directory. The former would cause the export to fail, the
+latter could case data loss. It's not defined what a special remote will do
+in this situation.
+
+It seems that this case would never occur accidentially, but it's still worth
+considering it.
+
+Perhaps it should simply skip exporting any files that have names
+that look like annex keys.
+"""]]
diff --git a/doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_2_e0f6d78620a89f60010607b37328f754._comment b/doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_2_e0f6d78620a89f60010607b37328f754._comment
new file mode 100644
index 0000000000..1fd0ecfa3b
--- /dev/null
+++ b/doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_2_e0f6d78620a89f60010607b37328f754._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="when someone names files like keys, they probably want trouble 🙃"
+ date="2024-04-09T10:43:16Z"
+ content="""
+> skip exporting any files that have names that look like annex keys.
+
+A general regex for a key looks like `^[A-Z0-9]+(?:-[a-z]\d+)*--.+$`, right? This seems like there would be many possible false positives that would not be exported, like `GIT--The Book.pdf`. 
+
+I can't see a situation where git annex would produce or rename files named like their (or another) key. So if someone deliberately names a file like `SHA256E-s31390--f50d7ac4c6b9031379986bc362fcefb65f1e52621ce1708d537e740fefc59cc0.mp3` and then exports it to such a versioned tree, I'd be fine with overwriting. After all, export remotes aren't primarily for full backups, rather for access convenience and filesystem limitations, right?
+
+I don't know if it's a problem internally for git-annex though when an export suddenly causes keys to vanish from the remote, but I guess your git-tree-diffing automatically takes care of that?
+"""]]
diff --git a/doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_3_19e77a51911d3c2d39a558162223e78e._comment b/doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_3_19e77a51911d3c2d39a558162223e78e._comment
new file mode 100644
index 0000000000..2968adabb7
--- /dev/null
+++ b/doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_3_19e77a51911d3c2d39a558162223e78e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="or use numcopies for safety"
+ date="2024-04-09T10:48:10Z"
+ content="""
+Or, even better: If such an export action would cause data loss, the potentially vanishing keys would be known, because they reside in a git-tree that you diff anyway, right? Git annex could then apply its usual logic of 'I shall never execute an action that reduces a file's copies below `$numcopies`' and error out with an explanation. That feels right and consistent with git annex' typical behavior.
+"""]]
diff --git a/doc/todo/Improving_diffdriver_--text.mdwn b/doc/todo/Improving_diffdriver_--text.mdwn
new file mode 100644
index 0000000000..4ad12ff20c
--- /dev/null
+++ b/doc/todo/Improving_diffdriver_--text.mdwn
@@ -0,0 +1,32 @@
+Thank you joey for `git annex diffdriver --text`, that is a big step towards easier diffing of annexed files. The following is now a copy-paste solution to 'make git diff work with git annex':
+
+```
+echo '* diff=annextextdiff' >> .git/info/attributes && git config diff.annextextdiff.command "git annex diffdriver --text"
+```
+
+This however then has `git diff` use git-annex' diffing mechanism for *all* files, including normal git-tracked files. There probably is no gitattributes-way of applying a diff command only to annexed files, right?
+
+## Customizing `diff` options
+
+Apparently, `git annex diffdriver --text` uses the system's `diff` command and doesn't (allow to) give it any specific options. The below points could be worked around by having something like `git annex diffdriver --text --diffopts='--color=auto'` so that the user can customize the `diff` invocation. Alternatively you could introduce an environment variable like `GIT_ANNEX_DIFFDRIVER_DIFF_OPTIONS` or shorter `GIT_ANNEX_DIFF_FLAGS` that could also be used to temporarily diff *that one file* with specific options.
+
+## Coloring the output
+
+How about passing the (sanitized, `false`→`never` and `true`→`auto`) `git config color.diff` (and fallback `color.ui`) setting as the `diff --color=...` option? The experience would then match the users configured expectation.
+
+
+## Handling all files as text
+
+`diff` detects some files as binary, although it can make sense to text-diff them (e.g. PDFs), just to get an impression of the changes. `diff` (and `git diff` as well, AFAIK without any good workaround without an external driver again) then just displays the unhelpful message that the 'binary files differ' (you don't say...🙄).
+
+How about having `git annex diffdriver --text` always using `diff --text`? That would deviate from the usual `git diff` behaviour, but I argue that:
+
+- a) People *explicitly* configure (a subset of) files in `.gitattributes` to be diffed with `git annex diffdriver --text`.
+- b) If they wouldn't care about the diff between files, then they wouldn't configure it.
+- c) Tracking binary(-like) files is something git-annex is explicitly designed for, it makes sense that git just skips over those, but git-annex could add value here
+
+Thanks again a ton for git-annex, the Tübix2023-Workshop was well appreciated and lots of fun. 👍
+
+Yann
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/Improving_diffdriver_--text/comment_1_a38b0f30f9b4011d703e70c093f139ab._comment b/doc/todo/Improving_diffdriver_--text/comment_1_a38b0f30f9b4011d703e70c093f139ab._comment
new file mode 100644
index 0000000000..a116744826
--- /dev/null
+++ b/doc/todo/Improving_diffdriver_--text/comment_1_a38b0f30f9b4011d703e70c093f139ab._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-05T18:55:33Z"
+ content="""
+If your annexed files have a common extension you can match them in
+.gitattributes that way.
+
+I've added support for passing options for diff. Eg:
+	
+	git annex diffdriver --text -- --color --text --
+
+As for passing --color automatically, I don't know if every diff(1) supports
+--color, and this would be more complexity.
+
+I doubt that most users would appreciate diff --text by default for large
+binary files. That is really getting into territory that an external 
+diff driver program can handle much better. Eg, if you're diffing jpegs and
+also zip files, you can write a diff driver program that lists the contents of
+zip files and passes that to diff, and that uses imagemagick
+`compare -compose` or <https://github.com/x1ddos/imgdiff> 
+to show a visual diff between two jpegs.
+
+The point off the --text option is that sometimes you know you have plain
+text and so writing such a program is not necessary.
+"""]]
diff --git a/doc/todo/Improving_diffdriver_--text/comment_2_2a59862281c1be5ee92912912c2045e9._comment b/doc/todo/Improving_diffdriver_--text/comment_2_2a59862281c1be5ee92912912c2045e9._comment
new file mode 100644
index 0000000000..98c5696b48
--- /dev/null
+++ b/doc/todo/Improving_diffdriver_--text/comment_2_2a59862281c1be5ee92912912c2045e9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2023-07-06T05:44:57Z"
+ content="""
+Wonderful, thank you joey!
+"""]]
diff --git a/doc/todo/Incremental_git_annex_sync_--content_--all.mdwn b/doc/todo/Incremental_git_annex_sync_--content_--all.mdwn
new file mode 100644
index 0000000000..11ea484f52
--- /dev/null
+++ b/doc/todo/Incremental_git_annex_sync_--content_--all.mdwn
@@ -0,0 +1,21 @@
+Hi,<br>
+So I have yet another idea to speed up git annex. For now only for the 2nd pass of git annex sync --content --all.
+
+1. Check which remotes are currently available (i.e. online and connected).
+2. If any of the (available) remotes doesn't have a commit recorded (See below), do a full sync.
+3. If numcopies.log, mincopies.log, trust.log, group.log, preferred-content.log, required-content.log, group-preferred-content.log or transitions.log (on the git-annex branch) changed since the last time we synced, do a full sync (since if any of those logs changed, it may affect the preferred-content expressions and we need to reevaluate every key).
+4. If every check passed, do an incremental sync.
+
+##Full sync:
+
+1. Do a normal (full) git annex sync.
+2. For every remote that we synced with, record the commit id of the current tip of the git-annex branch.
+    * Record the commit id only if every file was successfully transferred/dropped.
+
+##Incremental sync:
+
+1. In the 2nd pass of git annex sync --content --all, only look at keys whose location log changed since the last (full or incremental) sync via `git diff-tree -r --name-only <lowest recorded commit id of all remotes> git-annex`.
+2. Again, update the commit id of remotes that we successfully synced with.
+
+[[!tag confirmed]]
+[[!tag projects/datalad/potential]]
diff --git a/doc/todo/Incremental_git_annex_sync_--content_--all/comment_1_9d812c6dd2fd7b4c255ea88580da4396._comment b/doc/todo/Incremental_git_annex_sync_--content_--all/comment_1_9d812c6dd2fd7b4c255ea88580da4396._comment
new file mode 100644
index 0000000000..0c7148c739
--- /dev/null
+++ b/doc/todo/Incremental_git_annex_sync_--content_--all/comment_1_9d812c6dd2fd7b4c255ea88580da4396._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-01-19T16:27:07Z"
+ content="""
+So I implemented this with an bash script, see [[here|https://gist.github.com/Lukey3332/203ea6f30d48323e7bd1d05c16b5da9c]]. It's a bit hacky, since `git annex sync` doesn't have `--batch` and even if it did, `--batch` can't work with keys. Instead it check out a temporary branch, link the keys to sync in a directory and then uses --content-of= to sync only the keys within that directory.
+
+I'll use it with my repos and see if it works reliably.
+"""]]
diff --git a/doc/todo/Incremental_git_annex_sync_--content_--all/comment_2_9fff9eb8a7a897c5aabe9878f4d0b23b._comment b/doc/todo/Incremental_git_annex_sync_--content_--all/comment_2_9fff9eb8a7a897c5aabe9878f4d0b23b._comment
new file mode 100644
index 0000000000..16484474a9
--- /dev/null
+++ b/doc/todo/Incremental_git_annex_sync_--content_--all/comment_2_9fff9eb8a7a897c5aabe9878f4d0b23b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 2"
+ date="2021-07-15T18:40:13Z"
+ content="""
+The script needed a few tweaks, you can find the updated version [here](https://gist.github.com/Lukey3332/203ea6f30d48323e7bd1d05c16b5da9c).
+
+I used the script here since half a year now and everything works fine. I even had a problem with failed transfers due to a bad SATA-cable and the script did handle it properly. `git annex fsck --all` confirms that everything is alright.
+"""]]
diff --git a/doc/todo/Incremental_git_annex_sync_--content_--all/comment_3_638f40462d4bb2a447350ce0a5dc7a92._comment b/doc/todo/Incremental_git_annex_sync_--content_--all/comment_3_638f40462d4bb2a447350ce0a5dc7a92._comment
new file mode 100644
index 0000000000..5db686d831
--- /dev/null
+++ b/doc/todo/Incremental_git_annex_sync_--content_--all/comment_3_638f40462d4bb2a447350ce0a5dc7a92._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-07-16T17:42:49Z"
+ content="""
+Thank you for rewording, which should not have been necessary, but seems to
+have helped my reading comprehension.
+
+This does seem like a good idea! That diff should be fast and if the
+location log changed, it needs to recheck preferred content against the
+changed situation, and if it didn't, we know preferred content will have
+the same result as currently applies. Elegant.
+
+I suppose it needs to record the branch tip for each remote, because
+different remotes can be synced at different times. It can record it
+locally, in a hidden ref or something.
+
+Your script checks for changes to the preferred-content.log etc 
+by storing a copy and comparing it with the current one. But since it knows
+the old git-annex branch tip, it can just request a diff of those files
+between the old and new shas, eg:
+
+	git diff-tree refs/annex/last-sync/origin/git-annex..git-annex --name-only -- preferred-content.log required-content.log etc
+
+If that outputs anything the logs changed and the optimisation can't be
+used.
+
+Weirdly, this will make --all often faster than not using --all, because it
+will be able to quickly see there is nothing to do. Occurs to me that
+the same method could be used to tell when a non-all sync is a no-op,
+and so speed up those, although only in the case where there was a previous
+--all sync. Or, it could record a tuple of (tree, git-annex branch), and
+use that to speed up non-all syncs, at least of the variety that don't
+operate on a specific list of files, but on a whole tree.
+"""]]
diff --git a/doc/todo/Incremental_git_annex_sync_--content_--all/comment_4_c232e1e1cfcc47f70079f2d32c2b4633._comment b/doc/todo/Incremental_git_annex_sync_--content_--all/comment_4_c232e1e1cfcc47f70079f2d32c2b4633._comment
new file mode 100644
index 0000000000..bd167f075e
--- /dev/null
+++ b/doc/todo/Incremental_git_annex_sync_--content_--all/comment_4_c232e1e1cfcc47f70079f2d32c2b4633._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-06-23T16:00:04Z"
+ content="""
+My recent optimisations of `git-annex sync` with importtree remotes uses a
+similar diffing approach.
+
+`git-annex satisfy` syncs `--content` by default, so this optimisation would
+be especially nice to have for it.
+"""]]
diff --git a/doc/todo/Incremental_git_annex_sync_--content_--all/comment_5_e81719f23565579674249db5d0a883da._comment b/doc/todo/Incremental_git_annex_sync_--content_--all/comment_5_e81719f23565579674249db5d0a883da._comment
new file mode 100644
index 0000000000..d68d10d4a7
--- /dev/null
+++ b/doc/todo/Incremental_git_annex_sync_--content_--all/comment_5_e81719f23565579674249db5d0a883da._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-10-24T17:26:53Z"
+ content="""
+To implement this optimisation for a non-all sync, when 
+the tree being synced has changed, it ought to diff from the old
+tree to the current tree, and sync those files. Preferred
+content can vary depending on filename, and diffing like that will avoid
+scanning every file in the whole tree.
+
+And when there are location log changes, it needs to also sync files in the
+tree that use keys whose location log changed, using the git-annex branch
+diff to find those keys. (And presumably then using the keys database to get
+back to the filenames.)
+
+So, implementing an optimisation like this for a non-all sync has two
+separate diffs which would have to be combined together somehow.
+
+Doing that in constant memory would be hard. It seems that a bloom filter
+cannot be used to check if a file was processed in the first diff and avoid
+processing it again in the second diff. Because a false positive would
+avoid processing a file whose location log did change. I think it would
+need to use an on-disk structure maybe (eg sqlite)?
+
+None of which should prevent implementing this nice optimisation for --all.
+"""]]
diff --git a/doc/todo/Invert_remote_selection.mdwn b/doc/todo/Invert_remote_selection.mdwn
new file mode 100644
index 0000000000..a30b23093f
--- /dev/null
+++ b/doc/todo/Invert_remote_selection.mdwn
@@ -0,0 +1,32 @@
+Say I have:
+
+    $> git remote
+    Alpha
+    Beta
+    Gamma
+    Delta
+
+It is easy to sync with all repos via:
+
+    $> git annex sync
+
+Or specific repos via:
+
+    $> git annex sync Alpha Beta
+
+However, it is currently awkward to exclude specific repos. Is it possible to 'invert' or 'negate' specific remotes, so that the following are equivalent?
+
+    $> git annex sync \! Gamma
+    $> git annex sync Alpha Beta Delta
+
+This problem comes up surprisingly often due to:
+
+  1. An external host being temporarily down (which causes sync to hang for a while),
+  2. Repos being available, but the machine is under heavy IO load or memory pressure,
+  3. Repos on external drives that are swapped out and mounted to a specific location (e.g., /mnt/),
+  4. Wanting to roll out repo-wide changes in stages, or keeping 1-2 repos untouched for whatever reason, or
+  5. Some repos being too large for a machine (e.g., repacking fails due to low memory), but which can still act like a dumb file-store.
+
+The problem gets worse when you have a lot of remotes or a lot of repos to manage (I have both). My impression is that this feature would require a syntax addition for git-annex-sync only. I like '!' because it behaves the same in GNU find and sh.
+
+[[!tag needsthought]]
diff --git a/doc/todo/Invert_remote_selection/comment_1_5aa12a96f54a40adbfe18267a6bde87b._comment b/doc/todo/Invert_remote_selection/comment_1_5aa12a96f54a40adbfe18267a6bde87b._comment
new file mode 100644
index 0000000000..3742da867f
--- /dev/null
+++ b/doc/todo/Invert_remote_selection/comment_1_5aa12a96f54a40adbfe18267a6bde87b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-28T17:45:11Z"
+ content="""
+I think you could just use this:
+	
+	git annex sync -c remote.Gamma.annex-sync=false
+"""]]
diff --git a/doc/todo/Invert_remote_selection/comment_2_9ad4c9b2217f739e67198d16d14d32e7._comment b/doc/todo/Invert_remote_selection/comment_2_9ad4c9b2217f739e67198d16d14d32e7._comment
new file mode 100644
index 0000000000..5acf39f956
--- /dev/null
+++ b/doc/todo/Invert_remote_selection/comment_2_9ad4c9b2217f739e67198d16d14d32e7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="supernaught"
+ avatar="http://cdn.libravatar.org/avatar/55f92a50f2617099e2dc7509130ce158"
+ subject="comment 2"
+ date="2017-08-28T22:01:23Z"
+ content="""
+It's not very ergonomic to type out so much each for each sync, but I suppose it technically accomplishes the idea.
+
+Still -- wouldn't making '\!x' alias to '-c remote.x.annex-sync=false' have minimal impact and provide a bit more symmetry with the matching-options?
+
+I'm not familiar with Haskell, but could probably fumble my way through this one. Would you accept a patch?
+"""]]
diff --git a/doc/todo/Invert_remote_selection/comment_3_2aec5f535c84c37d59802e4759a1c242._comment b/doc/todo/Invert_remote_selection/comment_3_2aec5f535c84c37d59802e4759a1c242._comment
new file mode 100644
index 0000000000..549beaaa78
--- /dev/null
+++ b/doc/todo/Invert_remote_selection/comment_3_2aec5f535c84c37d59802e4759a1c242._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-09-29T16:26:54Z"
+ content="""
+Sure, if you want to develop a patch..
+"""]]
diff --git a/doc/todo/Invert_remote_selection/comment_4_f5ab9eec7ed0f080c57dbb594deafd13._comment b/doc/todo/Invert_remote_selection/comment_4_f5ab9eec7ed0f080c57dbb594deafd13._comment
new file mode 100644
index 0000000000..0e80fa2272
--- /dev/null
+++ b/doc/todo/Invert_remote_selection/comment_4_f5ab9eec7ed0f080c57dbb594deafd13._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-01-30T19:13:25Z"
+ content="""
+git-annex sync does support remote groups, so that might also help with
+this use case without needing additional syntax?
+"""]]
diff --git a/doc/todo/Keeping_a_repo__39__s_description_up_to_date.mdwn b/doc/todo/Keeping_a_repo__39__s_description_up_to_date.mdwn
new file mode 100644
index 0000000000..199e4a9cac
--- /dev/null
+++ b/doc/todo/Keeping_a_repo__39__s_description_up_to_date.mdwn
@@ -0,0 +1,14 @@
+Hi joey,
+
+I was recently moving many of my git annex repos around. This caused all of the (partly auto-generated) repo descriptions (e.g. `user@host:path`) to be outdated, making it more difficult to re-add them later from another host. Updating all of them manually was really error prone and tedious.
+
+What do you think about having git annex update the repo description "from time to time"? `git annex sync|assist|...` could check if the current repo description matches what the auto-generated string would be and update it accordingly.
+
+I see the following problems with this:
+
+- Adding this check to each and every git annex command is probably not a good idea. Maybe `git annex sync` and `git annex assist`. The overhead might be negligible though.
+- How to detect if the current description was really auto-generated and not user-specified? git annex could parse it with a regex (e.g. `(?P<user>[^@]+@(?P<host>[^:]+:(?P<path>.*)$`) and if that matches could assume it was auto-generated. Feels a little fragile though.
+
+Maybe the whole auto-updating idea is not ideal, but a new command like `git annex redescribe` or `git annex autodescribe` or `git annex describe --auto` could be introduced, so users can run it periodically or on-demand. Following the discussion on '`git annex sync` defaulting to syncing content', I have a feeling that people wouldn't like git annex messing with their repo descriptions 😉. Ideally, auto-describing would (optionally) also be able to update remotes' descriptions properly.
+
+All of this could also be done by a third-party program, but having this functionality in git annex itself would be handy.
diff --git a/doc/todo/Keeping_a_repo__39__s_description_up_to_date/comment_1_2fcce6a8fcfec28a6edeab40291deaba._comment b/doc/todo/Keeping_a_repo__39__s_description_up_to_date/comment_1_2fcce6a8fcfec28a6edeab40291deaba._comment
new file mode 100644
index 0000000000..263dcb789d
--- /dev/null
+++ b/doc/todo/Keeping_a_repo__39__s_description_up_to_date/comment_1_2fcce6a8fcfec28a6edeab40291deaba._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-10-25T17:21:16Z"
+ content="""
+I think a good thing to do if you plan to be moving a repo around is to
+describe it with something that does not depend on its current location.
+
+For example, suppose I am making a repo on a removable USB drive. I'm gonna
+literally move that from place to place by plugging it into different
+computers. So the default user@host:/mntpoint description is not a good one
+for that repository. Instead I use something like "2 tb passport USB drive", 
+or even better I slap a sticker on that drive and give it a real 
+name and use that as the description.
+
+I guess that someone who was moving a USB drive back and forth between 2
+computers would not be enthused if git-annex started updating the
+description after each move. Even if that prevented the 
+description from being wrong half the time.
+
+I do think that `git-annex describe --auto` is a reasonable idea.
+"""]]
diff --git a/doc/todo/Keeping_a_repo__39__s_description_up_to_date/comment_2_1c73d94cc84bbfdeb65a71995265491f._comment b/doc/todo/Keeping_a_repo__39__s_description_up_to_date/comment_2_1c73d94cc84bbfdeb65a71995265491f._comment
new file mode 100644
index 0000000000..3f75359f85
--- /dev/null
+++ b/doc/todo/Keeping_a_repo__39__s_description_up_to_date/comment_2_1c73d94cc84bbfdeb65a71995265491f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-10-25T17:57:50Z"
+ content="""
+Note that `git-annex describe remote --auto` has a small problem 
+when the remote is a git ssh remote, that there
+may be multiple hostnames, the one that happens to be used locally
+might not be as fully qualified as the "right" one. Or it may even be a ssh
+host alias, which can't be converted to a FQDN.
+
+For special remotes, `git-annex initremote` does not set a description at
+all, and whatever hostname might be used for one is hidden underneath an
+abstraction layer anyway. So it couldn't do anything useful for those.
+
+So that limits it to local git repositories..
+"""]]
diff --git a/doc/todo/Keeping_a_repo__39__s_description_up_to_date/comment_3_394c87782dd3318a6fa3705322fea4fb._comment b/doc/todo/Keeping_a_repo__39__s_description_up_to_date/comment_3_394c87782dd3318a6fa3705322fea4fb._comment
new file mode 100644
index 0000000000..bad3c205dd
--- /dev/null
+++ b/doc/todo/Keeping_a_repo__39__s_description_up_to_date/comment_3_394c87782dd3318a6fa3705322fea4fb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 3"
+ date="2023-10-26T17:46:27Z"
+ content="""
+> I think a good thing to do if you plan to be moving a repo around is to describe it with something that does not depend on its current location.
+> 
+> For example, suppose I am making a repo on a removable USB drive. I'm gonna literally move that from place to place by plugging it into different computers. So the default user@host:/mntpoint description is not a good one for that repository. Instead I use something like \"2 tb passport USB drive\", or even better I slap a sticker on that drive and give it a real name and use that as the description.
+
+I do that too (adding unique information about the storage medium, e.g. the HDD's manufacturer, serial number and human-readable description), but still it is important (to me) to have a (be it partly) copy-pastable link/path that simplifies re-adding the remote later elsewhere. In my case, I moved three HDDs (some of them internal, some connected via USB) to a different host and had to change the mountpoints for consistency. On all of these I stored many (>10) git annex repos, so that makes >30 remote descriptions I had to update manually -- probably forgot a lot of those. 
+
+Automating this would have helped a lot. A quick'n'dirty way to get FQDN(s) is this `nslookup \"$(curl -s icanhazip.com)\" | perl -ne 'print if s|^.*name\s+=\s+(.*)\.$|$1|g'` (doesn't work for DynDNS though...).
+
+I'd agree with you if you said, something like this is too specific to have git annex do it ('it' being updating descriptions of *remotes*). But if `git annex describe here --auto` would check if `here`'s description looks auto-generated and if yes, update it with the default auto-generated one, that would already help. Maybe just `git annex describe --auto` would suffice, as the `here` is kind of redundant -- any other remote wouldn't work like this.
+"""]]
diff --git a/doc/todo/LIst_of_Available_Remotes_in_Webapp.mdwn b/doc/todo/LIst_of_Available_Remotes_in_Webapp.mdwn
new file mode 100644
index 0000000000..89274bb8dd
--- /dev/null
+++ b/doc/todo/LIst_of_Available_Remotes_in_Webapp.mdwn
@@ -0,0 +1 @@
+When using git-annex in a distributed fashion (lots of repos everywhere) It is easy to lose track of which remotes has a particular repo and enable it. Currently I have to run `git annex info` and see which remotes are available then add them through the webapp. Would it be possible to make webapp show all repos not just the ones it is syncing give an option to enable it.
diff --git a/doc/todo/LIst_of_Available_Remotes_in_Webapp/comment_1_23fe2f3cd44c4357a385452dcd5eedef._comment b/doc/todo/LIst_of_Available_Remotes_in_Webapp/comment_1_23fe2f3cd44c4357a385452dcd5eedef._comment
new file mode 100644
index 0000000000..9e22dafca3
--- /dev/null
+++ b/doc/todo/LIst_of_Available_Remotes_in_Webapp/comment_1_23fe2f3cd44c4357a385452dcd5eedef._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.191"
+ subject="comment 1"
+ date="2014-04-17T20:54:18Z"
+ content="""
+I chose to make the webapp only show available remotes when it knows how to enable them. So it will show S3 special remotes, Box.com special remotes, etc. This avoids cluttering up the display of a shared repository with a list of all of your friend's removable drives, for example.
+
+I would like to make the webapp smarter about handling repositories on remote ssh servers. As long as the server name is in the global DNS, the webapp could easily walk the user through setting up such a remote. The missing piece is that nothing is logged in remotes.log for these remotes, and so the assistant doesn't know the server name.
+"""]]
diff --git a/doc/todo/Long_Running_Filter_Process.mdwn b/doc/todo/Long_Running_Filter_Process.mdwn
new file mode 100644
index 0000000000..2f42c09724
--- /dev/null
+++ b/doc/todo/Long_Running_Filter_Process.mdwn
@@ -0,0 +1,24 @@
+Hello,
+
+while reading the release notes of git 2.11 I noticed a cool new feature has been merged:
+
+> If the filter command (a string value) is defined via
+> `filter.<driver>.process` then Git can process all blobs with a
+> single filter invocation for the entire life of a single Git
+> command.
+
+see the [git documentation][1].
+
+This has been developed in the context of git-lfs (see [PR 1382] [2]).
+
+If I understand correctly how it works this could speed up v6 repos. Looking at the history/website 
+of git-annex there doesn't seem to be yet any work on this so I though it was worth calling the 
+attention on the feature.
+
+Thanks a lot for all the work on git-annex, it's a really amazing project! The more I study it the more cool features I discover :)
+
+
+[1]: https://github.com/git/git/blob/v2.11.0/Documentation/gitattributes.txt#L384
+[2]: https://github.com/git-lfs/git-lfs/pull/1382
+
+> [[done]] --[[Joey]] 
diff --git a/doc/todo/Long_Running_Filter_Process/comment_1_f155ffc7dbd074964dd53165274ec8a0._comment b/doc/todo/Long_Running_Filter_Process/comment_1_f155ffc7dbd074964dd53165274ec8a0._comment
new file mode 100644
index 0000000000..34d05d7711
--- /dev/null
+++ b/doc/todo/Long_Running_Filter_Process/comment_1_f155ffc7dbd074964dd53165274ec8a0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-12-13T15:57:05Z"
+ content="""
+Yes, this will make [[smudge]] faster when eg checking out a lot of working
+tree changes. I will need to add support for it.
+"""]]
diff --git a/doc/todo/Long_Running_Filter_Process/comment_3_24d89d0e8eb2da6e43d107caa71e042b._comment b/doc/todo/Long_Running_Filter_Process/comment_3_24d89d0e8eb2da6e43d107caa71e042b._comment
new file mode 100644
index 0000000000..f37fdf21f3
--- /dev/null
+++ b/doc/todo/Long_Running_Filter_Process/comment_3_24d89d0e8eb2da6e43d107caa71e042b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-08-13T20:24:02Z"
+ content="""
+The "filterdriver" branch implements support for these.
+
+However, it's actually slower than the old interface, because the new
+interface requires git-annex read the whole file content from git when
+adding a file, and the old interface let it not read any content.
+
+Since the new interface does have capabilities, a new capability could
+prevent schepping the content over the pipe, and let the filter driver
+refer to the worktree file instead, and respond with the path of a file.
+This would be similar to my old patch set for the old interface.
+"""]]
diff --git a/doc/todo/Long_Running_Filter_Process/comment_4_96c20518a6bd2806fed3646331b3ca1c._comment b/doc/todo/Long_Running_Filter_Process/comment_4_96c20518a6bd2806fed3646331b3ca1c._comment
new file mode 100644
index 0000000000..401d81ed54
--- /dev/null
+++ b/doc/todo/Long_Running_Filter_Process/comment_4_96c20518a6bd2806fed3646331b3ca1c._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-10-26T16:21:28Z"
+ content="""
+While `git add` would be a lot slower when using this interface to add
+large files, it would make `git checkout` and other commands that update
+the work tree a lot faster.
+
+Since the smudge filter is not providing git with the file content any more,
+using filterdriver would avoid git running many git-annex smudge processes,
+greatly speeding up large checkouts.
+
+Unfortunately, `git annex smudge --update` ends up running the smudge filter
+on all files that the clean filter earlier acted on, so even if filterdriver were
+used to speed up the clean filter, there would still be one process spawned per
+file for the smudge filter.
+
+So some interface improvement is needed before git-annex can usefully use
+this.
+"""]]
diff --git a/doc/todo/Lower-case_extension_for_SHA256E_and_similar.mdwn b/doc/todo/Lower-case_extension_for_SHA256E_and_similar.mdwn
new file mode 100644
index 0000000000..fccd2510c0
--- /dev/null
+++ b/doc/todo/Lower-case_extension_for_SHA256E_and_similar.mdwn
@@ -0,0 +1,19 @@
+Please consider making the `*E` backends lower-case the file extensions. This improves deduplication especially with image files, where cameras often use `*.JPG`, while other software such as the Dropbox Android app rename the images to `*.jpg`.
+We talked about that very shortly a few months ago:
+
+(Log starts 2015-08-06 21:11:40 CET)
+
+     tribut  is there a backend that lowercases the extension? or do the *E backends do that anyway?
+     joeyh   it does not
+     tribut  but would it make sense? or am i missing something?
+     joeyh   I don't know.. the extension is only there for stupid programs that follow symlinks and
+             check extensions. If such a program cares about .GIF vss .gif, you might have a problem
+     joeyh   I think that you can git-annex migrate from hashE to hash, then migrate back, and it'll
+             update to the new file extension.
+     tribut  i was thinking about content-identical images with .JPG or .jpg extension
+     tribut  and because even the most retarded of programs wont care, i thought the backend could
+             lowercase the extension
+     joeyh   ah, sure, using the E backend reduces the ability to de-duplicate
+     joeyh   I'd not want to add a e backend set just for this. There's no requirement that the
+             extension extraction code be stable, so it could be considered changing it to lower-case
+     joeyh   otoh, I have no idea if some programs are dumb enough to care about .git vs .GIF
diff --git a/doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_1_71a32962c081e42be0bfc468f74230e8._comment b/doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_1_71a32962c081e42be0bfc468f74230e8._comment
new file mode 100644
index 0000000000..29cd817c63
--- /dev/null
+++ b/doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_1_71a32962c081e42be0bfc468f74230e8._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2016-01-18T13:16:59Z"
+ content="""
+Joey implemented the '--force' option in *git annex migrate* at my request to deal with this issue.
+
+* Rename symlinks to lowercase extension
+* git annex migrate --force (causes the keys to be recreated using the new, lowercase extension)
+* git annex unused (for removing the now unused upper/mixed case files in the store).
+
+It's not the smoothest method, but it works well enough :)
+"""]]
diff --git a/doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_2_db432973421d3974e027cef13caa3033._comment b/doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_2_db432973421d3974e027cef13caa3033._comment
new file mode 100644
index 0000000000..2fc61b5149
--- /dev/null
+++ b/doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_2_db432973421d3974e027cef13caa3033._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tribut"
+ subject="comment 2"
+ date="2016-01-18T16:22:54Z"
+ content="""
+Thanks for the hint, CandyAngel.
+
+This is useful, however it has to be done periodically. I would still prefer if those keys were never created in the first place.
+"""]]
diff --git a/doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_3_15ec3c411b0a92b073eb8c65e192c8b8._comment b/doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_3_15ec3c411b0a92b073eb8c65e192c8b8._comment
new file mode 100644
index 0000000000..22ea13591a
--- /dev/null
+++ b/doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_3_15ec3c411b0a92b073eb8c65e192c8b8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="michael@ff03af62c7fd492c75066bda2fbf02370f5431f4"
+ nickname="michael"
+ avatar="http://cdn.libravatar.org/avatar/125bdfa8a2b91432c072615364bc3fa1"
+ subject="Import --clean-duplicates"
+ date="2018-12-31T10:40:03Z"
+ content="""
+I would like to revive this request for lower-case file extensions in the SHA256E backend. At some point, I migrated all my photos to use lower-case filenames.  However, the images stored on the SD card of my camera still use upper-case filenames including the extension. I would love to be able to use git annex import --clean-duplicates to remove already imported images from the SD card. However, this no longer works due to my files being directly added with lower-case extensions.
+"""]]
diff --git a/doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_4_2ef3cc0ff00cc735e3400120ae49d14a._comment b/doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_4_2ef3cc0ff00cc735e3400120ae49d14a._comment
new file mode 100644
index 0000000000..dfad674cac
--- /dev/null
+++ b/doc/todo/Lower-case_extension_for_SHA256E_and_similar/comment_4_2ef3cc0ff00cc735e3400120ae49d14a._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-05-25T15:33:29Z"
+ content="""
+Let's step back a second and think about why the extension is included at
+all: Some programs, particularly on OSX but also IIRC one or two on linux
+such as calibre, when presented with a symlink, follow the symlink and look
+at the extension of the file it points to in order to guess what type of
+file it is.
+
+That's the entire reason. Since people may end up using such a program
+or sharing a repo with someone who does, it defaults to SHA256E.
+
+If you are not in that situation, and are being bothered by the extension
+being preserved, you can just set annex.backend to SHA256.
+
+Also, if someone does have that problem with a repo using SHA256, they can 
+`git annex adjust --unlocked` and get around the problem that way.
+(Though there are enough caveats about unlocked files that is may not be
+a suitable solution for everyone.)
+
+And I still don't know if some program might care about a particular casing
+of a filename extension. It seems possible at least. There's also the
+problem that, if git-annex started lower-casing extensions when adding new
+files, it would *cause* exactly the problem that michael is complaining
+about above, who are in the opposite situation of having added filenames
+that have upper-case extensions and would see deduplication stop working
+for those after git-annex changed.
+
+(Most of which, on review, I said already in the IRC log at the top.)
+
+---
+
+My feeling at this point is, defaulting to SHA256E was probably a
+mistake, it makes git-annex worse for users who are
+not afflicted by stupid symlink-following software in an effort to cater
+to those who are. It would probably be better to swtich to SHA256 by default
+and let whatever users are bitten by that either manually enable SHA256E
+or use unlocked files.
+"""]]
diff --git a/doc/todo/Make_addunlocked_configurable_like_largefiles.mdwn b/doc/todo/Make_addunlocked_configurable_like_largefiles.mdwn
new file mode 100644
index 0000000000..a9719ec87d
--- /dev/null
+++ b/doc/todo/Make_addunlocked_configurable_like_largefiles.mdwn
@@ -0,0 +1,45 @@
+Hi joey,
+
+How about making `annex.addunlocked` configurable similar to `annex.largefiles` so different file types can be configured to be added unlocked and others locked?
+
+The following illustrates a use case:
+
+[[!format  bash """
+#!/bin/sh -x
+# make a repo
+export LC_ALL=C.UTF-8
+chmod -R +w addunlocked;rm -rf addunlocked
+git init addunlocked
+cd addunlocked
+git annex init
+# configure *.txt files to be added unlocked so they stay editable
+echo '*.txt   annex.addunlocked=true' > .gitattributes
+git add .gitattributes
+git commit -m "Add .gitattributes"
+# make a note
+echo bla > notes.txt
+git annex add
+git annex sync -m "add notes.txt"
+# However editing doesn't work as it was added locked
+echo blubb >> notes.txt  # fails as it was not added unlocked
+"""]]
+
+Probably not all matching options (like `copies` for example) make sense or work at all in this context, but at least `include=` would be useful („all files in that dir should be added unlocked always”). For example, in a synced folder for collaboration, PDFs could stay locked to save space, but Spreadsheets and ODT documents for example make sense to be added unlocked by default to stay editable. This could be achieved with something like this:
+
+[[!format  bash """
+# repo-wide stored in git-annex branch
+git annex config --set annex.addunlocked 'include=*.odt or include=**.pdf'
+
+# folder-specific via .gitattributes
+echo '*.pdf  annex.addunlocked=true' >> .gitattributes # (or 'anything')
+echo '*.odt  annex.addunlocked=true' >> .gitattributes # (or 'anything')
+
+# repo-specific
+git config annex.addunlocked 'include=**/*.odt or include=**/*.pdf'
+"""]]
+
+What do you think?
+
+Cheers, Yann
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/todo/Make_addunlocked_configurable_like_largefiles/comment_1_823bddc3b3824419f1123748f163e0ff._comment b/doc/todo/Make_addunlocked_configurable_like_largefiles/comment_1_823bddc3b3824419f1123748f163e0ff._comment
new file mode 100644
index 0000000000..1ec57c8d68
--- /dev/null
+++ b/doc/todo/Make_addunlocked_configurable_like_largefiles/comment_1_823bddc3b3824419f1123748f163e0ff._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-06-06T12:54:35Z"
+ content="""
+[git annex matching options](https://git-annex.branchable.com/git-annex-matching-options/) that make sense for `annex.addunlocked`:
+
+- include
+- exclude
+- mimetype
+- mimeencoding
+- largerthan
+- smallerthan
+- (securehash)
+- (inbackend)
+
+All the others won't work AFAICS because location tracking hasn't yet happened at adding time.
+"""]]
diff --git a/doc/todo/Make_addunlocked_configurable_like_largefiles/comment_2_89ea6c764e18ed4335733f979fb31140._comment b/doc/todo/Make_addunlocked_configurable_like_largefiles/comment_2_89ea6c764e18ed4335733f979fb31140._comment
new file mode 100644
index 0000000000..a8e6eb4799
--- /dev/null
+++ b/doc/todo/Make_addunlocked_configurable_like_largefiles/comment_2_89ea6c764e18ed4335733f979fb31140._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-06-06T16:50:16Z"
+ content="""
+annex.addunlocked can already be set to a [[git-annex-matching-expression]]
+and this allows configuring it differently for different filenames, etc.
+This has been supported since 7.20191230.
+
+You can already configure annex.addunlocked with `git-annex config`.
+
+Adding gitattributes for configs is problimatic because querying
+for them is not fast. They have to be queried for every file. Also the
+gitattributes format is not well suited to complex expressions since the
+value cannot contain spaces.
+
+The only benefit to supporting it in gitattributes would be to configure it
+differently in different branches of the repository. 
+
+There was a todo already suggesting this,
+[[annex.addunlocked_in_gitattributes]] and I decided to close it.
+"""]]
diff --git a/doc/todo/Make_addunlocked_configurable_like_largefiles/comment_3_8f32ef554635d852383eeaf3f0629d45._comment b/doc/todo/Make_addunlocked_configurable_like_largefiles/comment_3_8f32ef554635d852383eeaf3f0629d45._comment
new file mode 100644
index 0000000000..90265dab09
--- /dev/null
+++ b/doc/todo/Make_addunlocked_configurable_like_largefiles/comment_3_8f32ef554635d852383eeaf3f0629d45._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 3"
+ date="2023-06-07T04:49:04Z"
+ content="""
+Heh, didn't check that as I assumed when gitattributes does't work, git annex config won't either. Different branch config is a point but I guess not a huge one, right. 
+
+Maybe a note about addunlocked would fit into the docs: https://git-annex.branchable.com/git-annex-add/
+"""]]
diff --git a/doc/todo/Make_addunlocked_configurable_like_largefiles/comment_4_17d12c5d9f5aa40aa8c20ae478b324b2._comment b/doc/todo/Make_addunlocked_configurable_like_largefiles/comment_4_17d12c5d9f5aa40aa8c20ae478b324b2._comment
new file mode 100644
index 0000000000..1b37740122
--- /dev/null
+++ b/doc/todo/Make_addunlocked_configurable_like_largefiles/comment_4_17d12c5d9f5aa40aa8c20ae478b324b2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-06-12T20:29:05Z"
+ content="""
+I've updated the man page to document annex.addunlocked.
+"""]]
diff --git a/doc/todo/Make_git_annex_sync_--content_trust_location_logs.mdwn b/doc/todo/Make_git_annex_sync_--content_trust_location_logs.mdwn
new file mode 100644
index 0000000000..8fcb0a5f84
--- /dev/null
+++ b/doc/todo/Make_git_annex_sync_--content_trust_location_logs.mdwn
@@ -0,0 +1,4 @@
+Hello Joey,<br>
+`git annex sync --content (--all)` checks if the content of a key exists locally by checking if the path exists instead looking at the location log. I suspect that this has a large impact on performance if the cache is cold.
+
+[[!tag moreinfo]]
diff --git a/doc/todo/Make_git_annex_sync_--content_trust_location_logs/comment_1_006e3e3ab0c08852239c0f8fec851201._comment b/doc/todo/Make_git_annex_sync_--content_trust_location_logs/comment_1_006e3e3ab0c08852239c0f8fec851201._comment
new file mode 100644
index 0000000000..7be5bcc728
--- /dev/null
+++ b/doc/todo/Make_git_annex_sync_--content_trust_location_logs/comment_1_006e3e3ab0c08852239c0f8fec851201._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-11-30T17:09:28Z"
+ content="""
+Statting a file is typically much faster than
+piping a request through to git, git reading complex files, and git-annex
+parsing the result.
+
+There may be a case, when annex.thin is set, where it has to hash the whole
+file to determine if it's got the expected content. Normally this is
+avoided by inode cache information though. And if it did, it would only
+be slow once for that particular version of the file as it would cache its
+informaton.
+
+If you have a case where this is actually slow, please explain how I can
+see it.
+"""]]
diff --git a/doc/todo/Make_webapp_port_configurable.mdwn b/doc/todo/Make_webapp_port_configurable.mdwn
new file mode 100644
index 0000000000..2c94690293
--- /dev/null
+++ b/doc/todo/Make_webapp_port_configurable.mdwn
@@ -0,0 +1,42 @@
+### Please describe the problem.
+This is more of a feature request then a bug. 
+
+It would be nice and more intuitive if the webapp --listen parameter accepted a port specifier too allowing configuration of the port. 
+
+For my workflow, I thought I would contain all of git annexes dependencies inside a docker image since I'm quite comfortable with docker(and emerge on gentoo took a long time and finally failed). With an unconfigurable dynamic port though, it makes running the webapp subcommand in docker not really viable since I don't want to use docker run's port range mapping feature which will lock all those ports.
+
+### What steps will reproduce the problem?
+Dockerfile:
+ARG DEBIAN_TAG=buster-slim
+FROM debian:${DEBIAN_TAG}
+
+RUN set -ex \
+  && apt-get update \
+  && apt-get install -y \
+     git \
+     git-annex
+
+docker build -t git-annex:test .
+docker run --rm -it git-annex:test git annex webapp --listen 0.0.0.0:8888
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 7.20190129
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+git annex seems awesome with the little bit of testing I've done. It seems like the perfect tool for what I want to accomplish. Thanks!
+
+> [[done]] via --port option --[[Joey]]
diff --git a/doc/todo/Mbps.mdwn b/doc/todo/Mbps.mdwn
new file mode 100644
index 0000000000..a411df7310
--- /dev/null
+++ b/doc/todo/Mbps.mdwn
@@ -0,0 +1,17 @@
+Download speed is displayed in bytes/second, but in some situations, it
+would be better to use bits/second, eg Mbps and Kbps rather than MiB/s and
+KiB/s.
+
+I noticed this now that I have an internet connection that is
+capable of 150-200 Mbps, but varies widely (satellite). While I could think
+of that as 19-25 MiB/s those are less round numbers and harder to remember
+and match up with the other bandwidth displays.
+
+This might make sense as a per-remote configurable value. Allowing
+using MiB/s for a hard drive and Mbps for a network remote. --[[Joey]]
+
+> I've implemented bandwidthUnits now, but it's not used for display yet.
+> It is possible to specify such units in eg annex.stalldetection now.
+> Note that it uses Mbit, not Mb because that is just confusingly close to
+> "MB" and git-annex parses data units case insensitively. So the actual
+> display will end up being "Mbit/s" rather than Mbps probably. --[[Joey]]
diff --git a/doc/todo/Metadata_changes_are_not_reflected_in_a_view.mdwn b/doc/todo/Metadata_changes_are_not_reflected_in_a_view.mdwn
new file mode 100644
index 0000000000..7b698bc3a0
--- /dev/null
+++ b/doc/todo/Metadata_changes_are_not_reflected_in_a_view.mdwn
@@ -0,0 +1,33 @@
+### Please describe the problem.
+Changing metadata while being in an active view will not update the view.
+
+### What steps will reproduce the problem?
+(inside a repository)
+
+1. Create a file
+
+        $ uuidgen >file
+
+2. switch into a view
+
+       $ git annex view !blah
+       $ ls
+       file
+
+3. changed the metadata the view is based upon
+
+       $ git annex metadata -t blah file
+       $ ls
+       file
+
+   It would be nice/expected that the view gets updated when the metadata changes, hiding 'file' now
+  
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20141024~bpo70+1
+on debian wheezy with backports
+
+### Please provide any additional information below.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment
new file mode 100644
index 0000000000..9b079791b1
--- /dev/null
+++ b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-20T17:45:13Z"
+ content="""
+This might be worth adding. But, one of the ways views can be used
+is to use file operations to adjust the metadata that is being viewed.
+
+So, when you delete a file from a view, and git commit, git-annex
+will remove the metadata that had made the file be in the view.
+
+And, if you copy or move a file in a view to a different subdirectory,
+and add and git commit the change, the metadata will be updated to
+update the metadata to reflect the files new location.
+
+As such, I see this as a wishlist todo item at best, and will move it from
+the bugs list to the todo list.
+"""]]
diff --git a/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_2_74597dc57b426adccfa5aab456e499d2._comment b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_2_74597dc57b426adccfa5aab456e499d2._comment
new file mode 100644
index 0000000000..4b0e8aa0f3
--- /dev/null
+++ b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_2_74597dc57b426adccfa5aab456e499d2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="👍 +1 for updating the view when committing"
+ date="2023-02-03T13:25:21Z"
+ content="""
+I'd also love to see the current view being updated to reflect the new metadata after committing. Workaround is currently to `git switch` back to the main branch and re-make the view with `git annex view bla='*'`.
+
+BTW views are **really** cool, what an awesome idea, joey!
+"""]]
diff --git a/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_3_39d7b5588595067332909c53b232c413._comment b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_3_39d7b5588595067332909c53b232c413._comment
new file mode 100644
index 0000000000..73785d7e55
--- /dev/null
+++ b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_3_39d7b5588595067332909c53b232c413._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-02-08T16:29:36Z"
+ content="""
+Another time it would make sense to update the view is after git pull from
+elsewhere, which could change the metadata, or change the files present in
+the parent branch. I think it would make sense for `git-annex sync` run in
+a view to update the view after pulling.
+
+Updating the branch after `git-annex metadata` is run locally is of course
+also possible. There is a similarity to updating an adjusted branch after
+get/drop. Which has a config annex.adjustedbranchrefresh to tune how
+frequently to update the branch. Or the user could just run
+`git-annex sync --no-pull --no-push` themselves.
+
+There is probably a lot of scope for optimisation in updating the view
+branch, that might be able to get it reasonably quick. 
+I have not fully thought through it, but basically diffing from the old
+parent branch to the new parent to find files that have changed, and
+adding/removing those from the view. And also diffing from the old
+git-annex branch tree to the new one to get changes to metadata logs,
+parsing those and using changes to metadata to also move/delete/add
+files to the view branch.
+
+But it would be ok to start with a simple, slow implementation.
+"""]]
diff --git a/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_4_6ab0e38d8be8a70d501108f207d41d82._comment b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_4_6ab0e38d8be8a70d501108f207d41d82._comment
new file mode 100644
index 0000000000..75af01c6c8
--- /dev/null
+++ b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_4_6ab0e38d8be8a70d501108f207d41d82._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-02-08T19:32:34Z"
+ content="""
+`git-annex sync` when in a view branch will now update it.
+
+Leaving this open for optimising it.
+
+Also because of this problem:
+
+	joey@darkstar:~/tmp/m#master(author=_)>git-annex sync
+	commit
+	On branch views/master(author=_)
+	nothing to commit, working tree clean
+	ok
+	merge synced/master
+	fatal: refusing to merge unrelated histories
+	failed
+
+Looks like it should not be trying to merge the synced/master
+branch into the view branch. But, this makes me wonder, does the master branch
+get updated with new files pulled from remotes? If not, the view branch
+won't be updated to have them either.
+
+Also, I think that it may try to import trees from importree special remotes,
+into the view branch. Perhaps those should also get imported but merged into
+the master branch...
+"""]]
diff --git a/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_5_b1b381c560fd81f372fc393ec5d63d8d._comment b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_5_b1b381c560fd81f372fc393ec5d63d8d._comment
new file mode 100644
index 0000000000..7d50e72b75
--- /dev/null
+++ b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_5_b1b381c560fd81f372fc393ec5d63d8d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="`git annex sync` when in view"
+ date="2023-02-08T20:17:12Z"
+ content="""
+Right, git refusing to merge unrelated histories is something I also bumped into while developing `thunar-plugins`. There I worked around it by having the *Synchronize* menu item do `git add -A;git commit -m ...;git annex sync --only-annex`, which works fine.
+"""]]
diff --git a/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_6_9d3d9877e8581f986257dd3d495a8eab._comment b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_6_9d3d9877e8581f986257dd3d495a8eab._comment
new file mode 100644
index 0000000000..426bbd21e6
--- /dev/null
+++ b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_6_9d3d9877e8581f986257dd3d495a8eab._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-02-10T19:49:51Z"
+ content="""
+I've now fixed `git-annex sync`'s other behavior when ran in a view branch
+to be acceptable.
+
+I'm going to close this as fixed. But have opened
+[[faster_incremental_update_of_view_branch_by_git-annex_sync]] as the
+performance could be improved.
+"""]]
diff --git a/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_7_f97d171fdd715d984e43c1a8139bb8ae._comment b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_7_f97d171fdd715d984e43c1a8139bb8ae._comment
new file mode 100644
index 0000000000..0dfbb93e00
--- /dev/null
+++ b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_7_f97d171fdd715d984e43c1a8139bb8ae._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="👍 This made it easier for the Thunar plugin!"
+ date="2023-02-14T09:35:32Z"
+ content="""
+[`thunar-plugins`](https://gitlab.com/nobodyinperson/thunar-plugins) now detect git annex' support for this (checking if `view` appears in `git annex help sync`, which it didn't before) and does `git annex sync` instead of the `git add -A;git commit;git annex sync --only-annex` workaround in that case. Very nice, joey!
+"""]]
diff --git a/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_8_e10e8e6daf155fc493454f1d0d8595a8._comment b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_8_e10e8e6daf155fc493454f1d0d8595a8._comment
new file mode 100644
index 0000000000..0690c708a3
--- /dev/null
+++ b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_8_e10e8e6daf155fc493454f1d0d8595a8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-02-14T16:17:05Z"
+ content="""
+I'd recommend not relying on the `git-annex help sync` to detect this,
+since man pages may not be available. Look for '?=' in 
+`git-annex view --help`
+"""]]
diff --git a/doc/todo/Metadata_on_regular_git_objects___40__blob__44___trees__41____63__.mdwn b/doc/todo/Metadata_on_regular_git_objects___40__blob__44___trees__41____63__.mdwn
new file mode 100644
index 0000000000..b3793501a7
--- /dev/null
+++ b/doc/todo/Metadata_on_regular_git_objects___40__blob__44___trees__41____63__.mdwn
@@ -0,0 +1 @@
+Is it technically possible for the metadata interface to also support regular git objects, so that committed files or directories were also subject to tagging? For most metadata-related intents and purposes it seems I’d like to treat annexed and regular files alike; so I’d like to tag the LaTeX/ReST/etc. source for a presentation the same way I treat the output PDF, only that the former are likely not annexed. In the design docs it says metadata is attached to annex keys. Could it equally be attached to git blobs and trees, or would that break horribly somewhere?
diff --git a/doc/todo/Metadata_on_regular_git_objects___40__blob__44___trees__41____63__/comment_1_30c513b68101442dbcdec0eb109203fe._comment b/doc/todo/Metadata_on_regular_git_objects___40__blob__44___trees__41____63__/comment_1_30c513b68101442dbcdec0eb109203fe._comment
new file mode 100644
index 0000000000..9990e18678
--- /dev/null
+++ b/doc/todo/Metadata_on_regular_git_objects___40__blob__44___trees__41____63__/comment_1_30c513b68101442dbcdec0eb109203fe._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-06-02T17:08:32Z"
+ content="""
+metadata can be attached to sha1 git-annex keys, which can correspond
+to the sha1's of git objects.
+
+	joey@darkstar:~/tmp/a>git annex metadata -t wow --key=SHA1--b4432e7473849adb8d408696c81355bc708a1bd0
+	metadata SHA1--b4432e7473849adb8d408696c81355bc708a1bd0 
+	  lastchanged=2015-06-02@17-10-37
+	  tag=wow
+	  tag-lastchanged=2015-06-02@17-10-37
+	ok
+	joey@darkstar:~/tmp/a>git annex metadata --key SHA1--$(git show-ref master -s)
+	metadata SHA1--b4432e7473849adb8d408696c81355bc708a1bd0 
+	  lastchanged=2015-06-02@17-10-37
+	  tag=wow
+	  tag-lastchanged=2015-06-02@17-10-37
+	ok
+
+Might be worth improving this interface. A `--sha1=` would be a minor
+improvement.
+
+It would certianly be possible for git-annex metadata to be taught that
+if the file is not annexed, and is in git, to look up the sha1 of its
+blob object, and attach the metadata to it.
+
+Of course, modifying a file would not carry over the metadata. But the 
+same problem exists when modifying annexed files that have metadata attached.
+
+This would also need changes to view generation, I guess that when building
+a view it would need to consider regular git-tracked files, look up 
+their metadata, and add matching ones to the view tree.
+"""]]
diff --git a/doc/todo/More_precise_jobs_count_config.mdwn b/doc/todo/More_precise_jobs_count_config.mdwn
new file mode 100644
index 0000000000..ebcb4868f4
--- /dev/null
+++ b/doc/todo/More_precise_jobs_count_config.mdwn
@@ -0,0 +1,7 @@
+There is `annex.jobs` to configure job count globally but the need for parallelisation varies greatly for me.
+
+For example, sync should do its git commands with as many remotes in parallel as it can to minimise sync runtime but copy, move, fsck etc. on a local slow hard drive should only do one or two files at a time.
+
+Could there be a way to be more precise with how much parallelisation you want by default?
+
+Maybe for each sub-command or resource access pattern.
diff --git a/doc/todo/More_precise_jobs_count_config/comment_1_8b7dbf6025c99172925f037e9096ead1._comment b/doc/todo/More_precise_jobs_count_config/comment_1_8b7dbf6025c99172925f037e9096ead1._comment
new file mode 100644
index 0000000000..3051cfa64a
--- /dev/null
+++ b/doc/todo/More_precise_jobs_count_config/comment_1_8b7dbf6025c99172925f037e9096ead1._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-08T17:13:13Z"
+ content="""
+It could be helpful to have some kind of git config, similar to
+remote.name.annex-cost, that categorizes remotes by what amount of
+concurrency is desirable when accessing them.
+
+But then the kind of access can also matter, eg git pull from a ssh remote
+might as well be run concurrently with all other ssh remote pulls,
+but not so when downloading annex objects from ssh remotes.
+
+There is also the problem that what action will be taken on a particular file
+is up to the command, but the amount of concurrency to use has to be
+determined before running that command on that file. Eg, git-annex get
+might use a slow hard drive, or a fast ssd that benefits from
+concurrency. We don't know until that code runs, but we have to decide how
+many threads to spawn before hand.
+"""]]
diff --git a/doc/todo/More_space_savings_for_annex.thin.mdwn b/doc/todo/More_space_savings_for_annex.thin.mdwn
new file mode 100644
index 0000000000..a852dd5304
--- /dev/null
+++ b/doc/todo/More_space_savings_for_annex.thin.mdwn
@@ -0,0 +1,11 @@
+Currently with `annex.thin=true`, only one copy will be hardlinked so that duplicate copies do not get silently modified. It would be good to have an option such as `annex.thinmode` for alternative ways of unlocking files, especially for cases when all files need to be kept unlocked.
+
+1. `annex.thinmode=forcehardlink`
+
+    In some cases most of the files in the repository will never be modified, and if a file does need to be modified, the hardlink can be first broken by making a copy. This can save a lot of space if git-annex is also used for file level deduplication.
+
+2. `annex.thinmode=reflink`
+
+    For some copy-on-write filesystems such as BTRFS, reflink copies can be made, such as with `cp --reflink`. This both saves space and also prevents files in .git/annex/objects from being modified.
+
+git-annex-fix can be used to apply these settings to existing repositories.
diff --git a/doc/todo/More_space_savings_for_annex.thin/comment_1_cd571b1b3b6e73041ee629d031481d09._comment b/doc/todo/More_space_savings_for_annex.thin/comment_1_cd571b1b3b6e73041ee629d031481d09._comment
new file mode 100644
index 0000000000..67a083681d
--- /dev/null
+++ b/doc/todo/More_space_savings_for_annex.thin/comment_1_cd571b1b3b6e73041ee629d031481d09._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-10-16T15:27:35Z"
+ content="""
+git-annex already uses reflinks by default if the filesystem supports it.
+"""]]
diff --git a/doc/todo/More_space_savings_for_annex.thin/comment_2_95d195f2bad7e6a912e5d201928a94b9._comment b/doc/todo/More_space_savings_for_annex.thin/comment_2_95d195f2bad7e6a912e5d201928a94b9._comment
new file mode 100644
index 0000000000..704c7407ca
--- /dev/null
+++ b/doc/todo/More_space_savings_for_annex.thin/comment_2_95d195f2bad7e6a912e5d201928a94b9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 2"
+ date="2021-10-16T15:46:32Z"
+ content="""
+Then in such cases I don't think annex.thin=true need to create hardlinks.
+"""]]
diff --git a/doc/todo/More_space_savings_for_annex.thin/comment_3_15cc8f9e428df04199d139e2677afd8a._comment b/doc/todo/More_space_savings_for_annex.thin/comment_3_15cc8f9e428df04199d139e2677afd8a._comment
new file mode 100644
index 0000000000..6114e5a411
--- /dev/null
+++ b/doc/todo/More_space_savings_for_annex.thin/comment_3_15cc8f9e428df04199d139e2677afd8a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-10-20T18:01:31Z"
+ content="""
+If your filesystem supports reflinks, you should not need to enable
+annex.thin, just let git-annex make copies. It makes the copy
+using `cp --reflink=auto`, so when reflinks are supported, you'll get a
+nice cheap reflink.
+
+WRT annex.thinmode=forcehardlink, this would be something that aimed the
+gun right at the user's foot and then waits for the trigger to be pulled
+by any program that ever might write to a file.
+"""]]
diff --git a/doc/todo/More_space_savings_for_annex.thin/comment_4_a87baf5ad6b7688bb40a6c463cb1b8db._comment b/doc/todo/More_space_savings_for_annex.thin/comment_4_a87baf5ad6b7688bb40a6c463cb1b8db._comment
new file mode 100644
index 0000000000..bf7dab77fc
--- /dev/null
+++ b/doc/todo/More_space_savings_for_annex.thin/comment_4_a87baf5ad6b7688bb40a6c463cb1b8db._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 4"
+ date="2021-10-22T15:58:11Z"
+ content="""
+I understand `annex.thinmode=forcehardlink` presents a greater risk. Personally that's something I can manage. In case anyone else is interested in doing the same, this patch will make `git annex fix` always create hardlinks with `annex.thin=true`.
+
+```
+diff --git a/Annex/Content/LowLevel.hs b/Annex/Content/LowLevel.hs
+index c686e462e..b7cf95d24 100644
+--- a/Annex/Content/LowLevel.hs
++++ b/Annex/Content/LowLevel.hs
+@@ -57,10 +57,8 @@ linkOrCopy' canhardlink key src dest destmode = catchDefaultIO Nothing $
+   where
+ 	hardlink = do
+ 		s <- getstat
+-		if linkCount s > 1
+-			then copy s
+-			else liftIO (R.createLink src dest >> preserveGitMode dest destmode >> return (Just Linked))
+-				`catchIO` const (copy s)
++		liftIO (R.createLink src dest >> preserveGitMode dest destmode >> return (Just Linked))
++			`catchIO` const (copy s)
+ 	copy s = ifM (checkedCopyFile' key src dest destmode s)
+ 		( return (Just Copied)
+ 		, return Nothing
+diff --git a/Command/Fix.hs b/Command/Fix.hs
+index 6a84652ce..40a93b357 100644
+--- a/Command/Fix.hs
++++ b/Command/Fix.hs
+@@ -62,10 +62,10 @@ start fixwhat si file key = do
+ 			thin <- annexThin <$> Annex.getGitConfig
+ 			fs <- liftIO $ catchMaybeIO $ R.getFileStatus file
+ 			os <- liftIO $ catchMaybeIO $ R.getFileStatus obj
+-			case (linkCount <$> fs, linkCount <$> os, thin) of
+-				(Just 1, Just 1, True) ->
++			case (fileID <$> fs, fileID <$> os, thin) of
++				(Just n, Just n', True) | n /= n' ->
+ 					fixby $ makeHardLink file key
+-				(Just n, Just n', False) | n > 1 && n == n' ->
++				(Just n, Just n', False) | n == n' ->
+ 					fixby $ breakHardLink file key obj
+ 				_ -> stop
+ 
+```
+"""]]
diff --git a/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config.mdwn b/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config.mdwn
new file mode 100644
index 0000000000..419b6795e4
--- /dev/null
+++ b/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config.mdwn
@@ -0,0 +1,9 @@
+### Please describe the problem.
+Instead of storing config for each remote in ~/.ssh/config, which mixes the user own config with that of git-annex-assistant, which is irritating if (like me) you store your ssh config in a vcs. Since the option -F allows the choice of the config file, it should be possible to move the config into ~/.ssh/git-annex/config. The only issue I see is according to the ssh man page on my system states that the system-wide config is ignored if a config file is specified on the command line.
+
+### What version of git-annex are you using? On what operating system?
+I'm using git-annex 4.20130601 on a Debian Testing/Unstable/Experimental mix.
+
+[[!tag design/assistant]]
+
+[[wontfix]]
diff --git a/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_1_284c806e83a32af81b02aea7c7bc285a._comment b/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_1_284c806e83a32af81b02aea7c7bc285a._comment
new file mode 100644
index 0000000000..5997664e0d
--- /dev/null
+++ b/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_1_284c806e83a32af81b02aea7c7bc285a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-06-11T14:44:47Z"
+ content="""
+The only interface git provides to do this is `GIT_SSH`, which would have to be set to a wrapper script that runs ssh with the desirned options.
+
+And if that were used, `git pull` by itself would not work on the repositories set up by the assistant. I don't consider that very nice.
+"""]]
diff --git a/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_2_1f55ad6b39906458779b2d604b003ffe._comment b/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_2_1f55ad6b39906458779b2d604b003ffe._comment
new file mode 100644
index 0000000000..3cf75df08d
--- /dev/null
+++ b/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_2_1f55ad6b39906458779b2d604b003ffe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-06-11T14:48:01Z"
+ content="""
+Also, if you're going to set up something like local pairing, why would you *not* want to commit that config to git along with your other ssh configs? Config files in $HOME are quite frequently edited by helper programs to configure changes, and I personally commit those changes all the time.
+
+Perhaps your real problem is that you have one `.ssh/config` that is shared between multiple hosts, and the git-annex settings are specific to a single host. Have you considered using [vcsh](https://github.com/RichiH/vcsh)?
+"""]]
diff --git a/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_3_b00dce2374aac6968317d05d23bcfaf7._comment b/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_3_b00dce2374aac6968317d05d23bcfaf7._comment
new file mode 100644
index 0000000000..3442fb2b2b
--- /dev/null
+++ b/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_3_b00dce2374aac6968317d05d23bcfaf7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk3Wgg0XiqYFwM_Pw1RxZwlpNFi65g17sM"
+ nickname="James"
+ subject="comment 3"
+ date="2013-06-12T01:12:24Z"
+ content="""
+Ah, ok, I presumed there was an option in git to set a per-repository ssh command. I've looked at vcsh, but I'm not that confident with git remotes, so I don't use it (I use hg). If a per-repository ssh command added to git, would you consider adding this?
+"""]]
diff --git a/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_4_743d0b077110c5cac1e2f47187b75333._comment b/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_4_743d0b077110c5cac1e2f47187b75333._comment
new file mode 100644
index 0000000000..5a22c98f72
--- /dev/null
+++ b/doc/todo/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_4_743d0b077110c5cac1e2f47187b75333._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 4"
+ date="2013-06-12T19:23:50Z"
+ content="""
+If it were sane, I'd probably use it.
+
+In the meantime, I'm moving this to [[todo]].
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__.mdwn b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__.mdwn
new file mode 100644
index 0000000000..70071138db
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__.mdwn
@@ -0,0 +1,29 @@
+Given that git-annex has interactions with AWS S3 built-in, similar to my whining about ssh:// urls, I wondered if may be s3:// urls could be supported directly by git-annex.
+Unfortunately not the case, and messages are a tiny bit misleading (see below) that initially annex just says that configuration disallows access to S3 but when tried to allow, seems to offload that to libcurl which doesn't support it.
+
+The reason I am asking, is that lots of data is on S3 and for now we either relied on our datalad special remote to provide access to S3:// so we could authenticate, but for public buckets it would be overkill to demand datalad.  Although we could replace them with http urls, I thought it might be better if annex could just download s3:// directly.
+
+[[!format sh """
+$> git annex addurl s3://images.cocodataset.org/annotations/image_info_test2014.zip         
+addurl s3://images.cocodataset.org/annotations/image_info_test2014.zip Configuration does not allow accessing s3://images.cocodataset.org/annotations/image_info_test2014.zip
+
+Configuration does not allow accessing s3://images.cocodataset.org/annotations/image_info_test2014.zip
+failed
+git-annex: addurl: 1 failed
+
+$> git -c annex.security.allowed-url-schemes="http https s3" -c annex.security.allowed-http-addresses=all annex addurl s3://images.cocodataset.org/annotations/image_info_test2014.zip
+addurl s3://images.cocodataset.org/annotations/image_info_test2014.zip 
+curl: (1) Protocol "s3" not supported or disabled in libcurl
+failed
+git-annex: addurl: 1 failed
+
+$> git annex version
+git-annex version: 6.20180913+git33-g2cd5a723f-1~ndall+1
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+[[!tag moreinfo unlikely]]
+
+> [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_10_ed3a47b10ce2303041d9b9271bb9a2c8._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_10_ed3a47b10ce2303041d9b9271bb9a2c8._comment
new file mode 100644
index 0000000000..0bbb455cea
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_10_ed3a47b10ce2303041d9b9271bb9a2c8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 10"
+ date="2018-10-09T18:53:30Z"
+ content="""
+\"Remote url claiming iterates through remotes ordered by cost\" -- my web remote has lower cost than my dnanexus external special remote; the latter claims dx:// URLs.  But git-annex never seems to ask dnanexus to process dx:// URLs, even when I've manually set the URL to be present there.  Does the web remote always win, and if it can't handle a URL does git-annex then not try external special remotes?
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_11_2afa6133bfa8932ea1fb02b2052e2939._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_11_2afa6133bfa8932ea1fb02b2052e2939._comment
new file mode 100644
index 0000000000..5d064fa289
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_11_2afa6133bfa8932ea1fb02b2052e2939._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 11"
+ date="2018-10-10T14:05:53Z"
+ content="""
+Ilya -- what version of annex you are using?  Upgrade might help since there were some fixes related to the priorities in the past month or two (initially detected when using -J setting)
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_12_6c9336be070b04d5736b943889370c13._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_12_6c9336be070b04d5736b943889370c13._comment
new file mode 100644
index 0000000000..4028276909
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_12_6c9336be070b04d5736b943889370c13._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 12"
+ date="2018-10-10T16:04:38Z"
+ content="""
+(master_env_py27_v28) [11:52 AM /data/ilya-work]$ git annex version
+git-annex version: 6.20180926-gc906aaf
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser MagicMime Feed\
+s Testsuite
+dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-s\
+qlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_2\
+24 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE\
+2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256\
+ BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
+operating system: linux x86_64
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+local repository version: 5
+
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_13_20184de38c2adeed7e20fa323d9a3ba4._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_13_20184de38c2adeed7e20fa323d9a3ba4._comment
new file mode 100644
index 0000000000..19f9bc7d32
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_13_20184de38c2adeed7e20fa323d9a3ba4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 13"
+ date="2018-10-11T12:03:12Z"
+ content="""
+So, it was some odd misconfiguration — I initremote’d a new external special remote of the same externaltype, set the old one to annex-ignore, and things seem to work.
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_14_58965ac55e2e9aebdd0e38f8eef097a3._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_14_58965ac55e2e9aebdd0e38f8eef097a3._comment
new file mode 100644
index 0000000000..fd1d127411
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_14_58965ac55e2e9aebdd0e38f8eef097a3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: comment 9"""
+ date="2023-03-01T16:30:42Z"
+ content="""
+An external special remote can hook into addurl by implementing
+CLAIMURL and CHECKURL. So yes, an external special remote could implement
+s3 urls.
+
+Looking over this thread, I think it's clear that git-annex should not
+implement support for these s3 urls itself.
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_1_312f32bd35f06837463e541773986b4f._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_1_312f32bd35f06837463e541773986b4f._comment
new file mode 100644
index 0000000000..095cffbd15
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_1_312f32bd35f06837463e541773986b4f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-03T16:37:37Z"
+ content="""
+Is a s3 uri scheme standardized somewhere?
+
+AFAICS this would be identical to http..
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_2_7ea1c35ce23a57fea52a593c41a8fb69._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_2_7ea1c35ce23a57fea52a593c41a8fb69._comment
new file mode 100644
index 0000000000..d0784d0ce0
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_2_7ea1c35ce23a57fea52a593c41a8fb69._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-10-03T17:39:48Z"
+ content="""
+great question. 
+I think there is \"none\" or may be it is even incorrect to use `s3` in \"s3://\" because underlying protocol is probably http(s).
+
+I was using `s3://` because
+- that is what [s3cmd](https://s3tools.org/s3cmd) consumes and probably it was the first cmdline helper I used for interaction with S3
+- `aws` from [awscli](http://aws.amazon.com/cli/) from Amazon itself, describes `s3://mybucket/myprefix/myobject` as S3Uri; although I found no mentioning of it yet in https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html.  Here is what `aws s3 help` says
+
+```
+       S3Uri: represents the location of a S3 object, prefix, or bucket.  This
+       must  be  written in the form s3://mybucket/mykey where mybucket is the
+       specified S3 bucket, mykey is the specified S3 key.  The path  argument
+       must  begin with s3:// in order to denote that the path argument refers
+       to a S3 object. Note that prefixes are separated  by  forward  slashes.
+       For  example, if the S3 object myobject had the prefix myprefix, the S3
+       key would be myprefix/myobject, and if the object  was  in  the  bucket
+       mybucket, the S3Uri would be s3://mybucket/myprefix/myobject.
+```
+
+so it seems that in neither of those two cases there is any provisioning to specify the specific versionId (like pure http url would have), or identify the key/object by etag (somewhat volatile AFAIK, could change for the same version if recomputed).  So even if s3:// gets supported, there is no standard way to point to the particular version of the file.
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_3_337217fc0ae8cfd432c7df45942b86ef._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_3_337217fc0ae8cfd432c7df45942b86ef._comment
new file mode 100644
index 0000000000..2d384811a4
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_3_337217fc0ae8cfd432c7df45942b86ef._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-10-04T16:41:00Z"
+ content="""
+I suspect that Amazon's tools also allow uris where
+the bucket is not a domain name and is assumed to be
+on AWS. The documentation kind of reads that way.
+That would not fly in git-annex.
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_4_8778b93dbc123c484727bb55e39608c9._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_4_8778b93dbc123c484727bb55e39608c9._comment
new file mode 100644
index 0000000000..689f09a8c5
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_4_8778b93dbc123c484727bb55e39608c9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2018-10-05T19:56:24Z"
+ content="""
+If the s3 remote claims s3:// URLs, does the bucket name have to be a DNS domain?  I thought, when a special remote claims a URL, it can interepret it however it wants?
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_5_9c7bdcb483b371f421bcdca3d8c2073c._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_5_9c7bdcb483b371f421bcdca3d8c2073c._comment
new file mode 100644
index 0000000000..20bedc11dc
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_5_9c7bdcb483b371f421bcdca3d8c2073c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2018-10-05T20:20:42Z"
+ content="""
+yes, for `s3://` urls there is only a bucket name, not a domain.  Since bucket name is allowed to have `.`, some folks started to use their project domain name as a bucket name (e.g. `openneuro.org`, `images.cocodataset.org`).  Then if you are to access them directly via url, full domain name would be e.g. http://images.cocodataset.org.s3.amazonaws.com, which would start causing troubles if you try to access it via https
+
+[[!format sh \"\"\"
+$> wget -S https://images.cocodataset.org.s3.amazonaws.com 
+--2018-10-05 16:19:48--  https://images.cocodataset.org.s3.amazonaws.com/
+Resolving images.cocodataset.org.s3.amazonaws.com (images.cocodataset.org.s3.amazonaws.com)... 52.216.18.32
+Connecting to images.cocodataset.org.s3.amazonaws.com (images.cocodataset.org.s3.amazonaws.com)|52.216.18.32|:443... connected.
+The certificate's owner does not match hostname ‘images.cocodataset.org.s3.amazonaws.com’
+\"\"\"]]
+
+for which we started to provide workarounds in datalad.
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_6_c94fdab4db1d5f94929ae068c546b533._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_6_c94fdab4db1d5f94929ae068c546b533._comment
new file mode 100644
index 0000000000..64fd793eb1
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_6_c94fdab4db1d5f94929ae068c546b533._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 6"
+ date="2018-10-05T21:31:33Z"
+ content="""
+My current planned solution is to write an external special remote that claims s3:// URLs and downloads them.  Then can use addurl --fast .  My use case is that, if I run a batch job that reads inputs from s3 and writes outputs to s3, what I get at the end are pointers to s3, and I want to check these results into git-annex.  Ideally there'd be a way for me to tell the batch system to use git-annex to send things to s3, but currently that's not possible.
+
+Question: if an external special remote claims a URL that a built-in special remote could handle, does the external special remote take priority?
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_7_e3c50b7ab1c5cd49a3e5376e20b7d4c0._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_7_e3c50b7ab1c5cd49a3e5376e20b7d4c0._comment
new file mode 100644
index 0000000000..3996306c07
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_7_e3c50b7ab1c5cd49a3e5376e20b7d4c0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2018-10-05T21:41:45Z"
+ content="""
+FWIW datalad special remote already supports download from such s3:// URLs
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_8_72eb9bc8d12bc8719f49f6528a086234._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_8_72eb9bc8d12bc8719f49f6528a086234._comment
new file mode 100644
index 0000000000..db5ad67204
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_8_72eb9bc8d12bc8719f49f6528a086234._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2018-10-08T16:14:23Z"
+ content="""
+@Ilya_Shlyakhter it is possible for git-annex to send things to S3 though,
+particularly `git-annex export` sounds like it may meet your use case.
+(Or the planned [[todo/import_tree]].)
+
+Remote url claiming iterates through remotes ordered by cost, so the
+cheapest remote wins. I'm not decided if that really makes sense, it's
+just what fell out of the code.
+
+As to s3:// stealthily hiding the fact that what look like real urls are
+forced to be hosted by Amazon -- ugh. Amazon may not want S3 to be a
+protocol, but it is one, and so that is inappropriate hard-coding.
+"""]]
diff --git a/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_9_6d1a630fbf036144c9559c9c01fca845._comment b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_9_6d1a630fbf036144c9559c9c01fca845._comment
new file mode 100644
index 0000000000..b01e8b8fc0
--- /dev/null
+++ b/doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_9_6d1a630fbf036144c9559c9c01fca845._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 9"
+ date="2018-10-09T15:33:59Z"
+ content="""
+@joey If I understand correctly, addurl requires a standard URL downloadable by curl?   Would it be possible to add 'adduri' and 'registeruri' counterparts, that would be exactly like addurl/registerurl, except they would be for custom URIs not expected to be fetchable by curl?   There seems to be an odd asymmetry, where the external special remote protocol has SETURIPRESENT/SETURLPRESENT, but the command-line only has the URL versions.
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation.mdwn b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation.mdwn
new file mode 100644
index 0000000000..bad6d44987
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation.mdwn
@@ -0,0 +1,16 @@
+In neurophysiology we encounter HUGE files (HDF5 .nwb files).
+Sizes reach hundreds of GBs per file (thus exceeding any possible file system memory cache size).  While operating in the cloud or on a fast connection it is possible to fetch the files with speeds up to 100 MBps. 
+Upon successful download such files are then loaded back by git-annex for the checksum validation, and often at slower speeds (eg <60MBps on EC2 SSD drive).
+So, ironically, it does not just double, but rather nearly triples overall time to obtain a file.
+
+I think ideally, 
+
+- (at minimum) for built-in special remotes (such as web), it would be great if git-annex was check-summing incrementally as data comes in;
+- made it possible to for external special remotes to provide desired checksum on obtained content. First git-annex should of cause inform them on type (backend) of the checksum it is interested in, and may be have some information reported by external remotes on what checksums they support.
+
+If needed example, here is http://datasets.datalad.org/allen-brain-observatory/visual-coding-2p/.git with >50GB files such as ophys_movies/ophys_experiment_576261945.h5 .
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_10_695d1269ab20c66630ddfa2d8cbabbef._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_10_695d1269ab20c66630ddfa2d8cbabbef._comment
new file mode 100644
index 0000000000..4e754e0b88
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_10_695d1269ab20c66630ddfa2d8cbabbef._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-02-10T19:48:58Z"
+ content="""
+Incremental hashing implemented for local git remotes.
+
+Next step should be a special remote, such as directory,
+that uses byteRetriever. Chunking and encryption will complicate them..
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_12_f85f81450c5d59e6722b46299f2ae29c._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_12_f85f81450c5d59e6722b46299f2ae29c._comment
new file mode 100644
index 0000000000..02eab47cd3
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_12_f85f81450c5d59e6722b46299f2ae29c._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: comment 9"""
+ date="2021-02-11T01:33:47Z"
+ content="""
+Not a bad idea, yoh!
+
+It could be taken further: Keep reading from the file as it grows and hash
+incrementally. Use inotify to know when more has been written, or poll
+periodically or when PROGRESS is received. If the hash is wrong at the end,
+rehash the file. Only remotes that write chunks out of order would pay a
+time penalty for that extra hashing.
+
+That could be enabled by a protocol extension. Or disabled by a protocol
+extension for that matter, since remotes that write out of order are
+probably rare.
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_13_a19823409648828b8b9f7a0f2fa7d935._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_13_a19823409648828b8b9f7a0f2fa7d935._comment
new file mode 100644
index 0000000000..d206602758
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_13_a19823409648828b8b9f7a0f2fa7d935._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2021-08-11T18:16:41Z"
+ content="""
+Some special remotes now support incremental update. So far, limited to
+ones that use the byteRetriever interface.
+Others, that use fileRetriever, including external special remotes, still
+need work.
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_14_14f46277adb38d5cb802cd23eb2cde04._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_14_14f46277adb38d5cb802cd23eb2cde04._comment
new file mode 100644
index 0000000000..d290f80a88
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_14_14f46277adb38d5cb802cd23eb2cde04._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2021-08-12T18:42:03Z"
+ content="""
+I've implemented a tailVerify; all that remains to be done is hook
+all special remotes that retrieve to a file up to use it.
+
+That's mostly ones using fileRetriever, which will come down to making
+retrieveChunks use it, probably. Although it may be that a few of them,
+like Remote.Directory, could avoid using it and feed the verifier
+themselves, more efficiently.
+
+There are also a couple of special remotes that don't use fileRetriever or
+retrieveChunks but could also use tailVerify. Looks like only Remote.BitTorrent
+and Remote.Web. But bittorrent is just the kind of thing that tailVerify
+will not support well due to random access. And Remote.Web could feed the
+verifier itself.
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_15_85e2368381e15cd86b5340fcec1a083b._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_15_85e2368381e15cd86b5340fcec1a083b._comment
new file mode 100644
index 0000000000..2119af3724
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_15_85e2368381e15cd86b5340fcec1a083b._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2021-08-13T20:06:56Z"
+ content="""
+Status update: This is implemented, and seems to work in limited testing.
+
+The directory special remote's Cow probing has a (create, delete, create)
+sequence that prevents incremental hashing from being done. It should be
+possible to make that remote incrementally hash on its own, while copying,
+rather than using tailVerify. That would avoid the problem, and be more
+efficient besides.
+
+The web special remote still needs to be made to do incremental hashing.
+Besides bittorrent, I think it's the only other one that won't do it now.
+
+One thing I don't like: When the incremental checksumming falls behind
+the transfer, it has to catch up at the end, reading the remainder of the
+file. That currently runs in the transfer stage. If concurrency is enabled,
+it's possible for all jobs to be stuck doing that, rather than having any
+actually running transfers, and so fail to saturate bandwidth. This is kind
+of a reversion of a past optimisation that made checksums happen in a separate
+stage to avoid that problem. Although now it only happens when the transfer
+runs at the same speed as the disk (or perhaps when resuming an interrupted
+transfer), otherwise the checksumming won't fall behind. It would be better
+to defer the rest of the incremental checksumming to the transfer stage
+(by returning the action inside Verification and running it when
+the verification is checked), or perhaps switch to the checksum stage
+before doing it. (update: this is fixed)
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_16_fbbcf1d8b35078274cfe322cea6de21c._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_16_fbbcf1d8b35078274cfe322cea6de21c._comment
new file mode 100644
index 0000000000..155bdd2f7a
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_16_fbbcf1d8b35078274cfe322cea6de21c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2021-08-16T19:08:29Z"
+ content="""
+The concurrency problem is fixed now.
+
+All special remotes now do incremental hashing in most cases
+(on linux, subset on other OS's).
+
+Only thing remaining is:
+Retrieval from export/import special remotes does not do incremental
+hashing (except for versioned ones, which sometimes use retrieveKeyFile).
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_17_39db598e93d0d858984052e3894cd96e._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_17_39db598e93d0d858984052e3894cd96e._comment
new file mode 100644
index 0000000000..ad8573939b
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_17_39db598e93d0d858984052e3894cd96e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 17"""
+ date="2022-05-09T17:48:31Z"
+ content="""
+Update: incremental hashing is also now done for all export remotes.
+Only import (and export+import) remotes don't support incremental hashing
+now.
+
+Update 2: Now also done for import remotes. All done!
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_1_29e601ea3ea4f22301c6cf6eed403ba4._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_1_29e601ea3ea4f22301c6cf6eed403ba4._comment
new file mode 100644
index 0000000000..7b2bf7b358
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_1_29e601ea3ea4f22301c6cf6eed403ba4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="use named pipes?"
+ date="2019-11-25T16:45:26Z"
+ content="""
+For external remotes can pass to the `TRANSFER` request, as the `FILE` parameter, a named pipe, and use `tee` to create a separate stream for checksumming.
+
+An external remote could also do its own checksum checking and then set remote.<name>.annex-verify=false.
+Could also make a “wrapper” external remote that delegates all requests to a given external remote but does checksum-checking in parallel with downloading (by creating a named pipe and passing that to the wrapped remote).
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_2_fa9e2c0a83bad2e0c2da3016b9bf2100._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_2_fa9e2c0a83bad2e0c2da3016b9bf2100._comment
new file mode 100644
index 0000000000..ca032f7a00
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_2_fa9e2c0a83bad2e0c2da3016b9bf2100._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2019-12-10T22:01:12Z"
+ content="""
+> An external remote could also do its own checksum checking and then set `remote..annex-verify=false`
+
+that is an interesting idea, thanks!  Not sure if that makes it easy for mass consumption though since it is a feature of a external remote, not sure why it should be in the config.  Ideally it should be a property of a remote.
+
+Joey, what do you think in regard of built-in remotes?
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_3_529c38fc63540b32c51ae75529e9005e._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_3_529c38fc63540b32c51ae75529e9005e._comment
new file mode 100644
index 0000000000..d2a79d3cf3
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_3_529c38fc63540b32c51ae75529e9005e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="annex-verify"
+ date="2019-12-11T18:13:48Z"
+ content="""
+\"it is a feature of a external remote, not sure why it should be in the config\" -- because the user might not trust an external remote's implementation of this feature.  Besides bugs, there might be [[security exploits|security/CVE-2018-10857_and_CVE-2018-10859]] if external remotes could single-handedly disable verification.
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_4_82707d36ed580d62c73e441f959ccd9e._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_4_82707d36ed580d62c73e441f959ccd9e._comment
new file mode 100644
index 0000000000..b5fd006951
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_4_82707d36ed580d62c73e441f959ccd9e._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-12-30T18:15:40Z"
+ content="""
+When -J is used, recent versions use a separate pool of worker threads for
+the checksumming than the downloading. So even with -J1 checksum of the
+previous download will not block the next download.
+
+I've thought about making this the default without -J.. It relies on
+concurrent-output working well, which it sometimes may not, eg when
+filenames are not valid unicode, or perhaps on a non-ANSI terminal, and so
+far it's been worth not defaulting to -J1 to avoid breaking in such edge
+cases.
+
+Anyway, it seems to me using -J should avoid most of the overhead, except
+of course for the remaining checksumming after all downloads finish.
+
+Incremental checksumming could be done for some of the built-in remotes,
+but not others like bittorrent which write out of order. Some transfers
+can resume, and the checksumming would have to somehow catch
+up to resume point, which adds significant complexity.
+
+External remotes would need to send the content over a pipe for incremental
+checksumming, so it would need a protocol extension.
+
+git-annex's remote API does have the concept that a remote can sufficiently
+verify the content of a file during transfer that additional checksumming
+is not necessary. Currently only used for git remotes when hard linking an
+object from a sibling remote. I don't think it actually matters what
+checksum a remote uses to do such verification, as long as it's
+cryptographically secure and runs on the local machine.
+
+A protocol extension that let an external remote communicate to git-annex
+that it had done such verification at the end of transfer is worth thinking
+about.
+
+Re Ilya's security concerns, as long as the external remote runs the
+verification on the local machine, it seems there is no added security
+impact.
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_5_aad1896b58e58cbc870c4526ebb824ec._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_5_aad1896b58e58cbc870c4526ebb824ec._comment
new file mode 100644
index 0000000000..22766007cb
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_5_aad1896b58e58cbc870c4526ebb824ec._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="named pipes and external remotes"
+ date="2019-12-31T01:38:03Z"
+ content="""
+\"External remotes would need to send the content over a pipe for incremental checksumming, so it would need a protocol extension\" -- in the current protocol, if you pass to the TRANSFER request, as the FILE parameter, a named pipe, would something break?
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_6_3d2f62f0946528c9986135f8db86a237._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_6_3d2f62f0946528c9986135f8db86a237._comment
new file mode 100644
index 0000000000..228348cda9
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_6_3d2f62f0946528c9986135f8db86a237._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="michael.hanke@c60e12358aa3fc6060531bdead1f530ac4d582ec"
+ nickname="michael.hanke"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Documentation of demand"
+ date="2020-10-27T14:59:47Z"
+ content="""
+We are routinely working with datasets in the 100TB range, with individual file sizes of up to 16TB. Some of our systems have ~500MB/s disk read throughput only. The separation of download and checksuming leads to 6+ hours of additional disk reads and delay the availability of a file. Having this feature would be a stellar performance improvement for our use case. Thanks in advance.
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_7_48842fb1e006a05573ab34048db45c8b._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_7_48842fb1e006a05573ab34048db45c8b._comment
new file mode 100644
index 0000000000..76ef15db46
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_7_48842fb1e006a05573ab34048db45c8b._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-02-09T16:31:47Z"
+ content="""
+I investigated feasability of a protocol extension that when 
+an external special remote enables it, means it always verifies a checksum
+itself before sending `TRANSFER-SUCCESS RETRIEVE`.
+
+Which checksum would be up to the special remote. Question is, would
+it need to be cryptographically secure, or would a CRC, sha1, or md5 suffice?
+
+annex.security.allow-unverified-downloads prevents download from special
+remotes when the content can't be verified, and that is to avoid a class of
+security holes (CVE-2018-10859). For the purposes of fixing that hole, sha1
+and md5 were considered good enough. The attacker does not control the
+original content, so a preimage attack won't work. The attacker has a
+gpg encrypted file they want to get decrypted, and they might be able to
+modify the file (eg appending junk, or messing with the gpg data in some
+way?) and cause a collision. I think sha1 and md5 are secure enough to
+avoid this attack. CRC is certianly not good enough. I'd be wary of md4
+since its preimage resistance is broken.
+
+So, doing this as a protocol extension would need to document that
+the hash needs to have preimage resistance, or be generally
+cryptographically secure. And then if a external special remote was using
+sha1 or whatever and it got sufficiently broken, it would be up to the
+maintainer of it to update it to stop using the protocol extension.
+
+I also looked at special remotes built into git-annex. Tahoe certianly
+does enough verification of downloads. Bittorrent doesn't because the
+torrent file is downloaded often w/o verification (magnet links could be
+verified enough maybe). Rsync usually uses a good enough checksum, but 
+can fall back to md4 or perhaps no checksum at all, and the attacker might
+control the rsync server, so the rsync special remote and also ssh
+remotes still need their own verification. Bup uses sha1 so does
+enough verification. All the rest don't.
+
+I think the question is, would this protocol extension really get used
+by any external special remotes? Anyone have an example of one? The
+alternative is to change the protocol so the downloaded content gets
+streamed to git-annex in some way, and have git-annex incrementally
+checksum as content comes in. Which really seems better all around, except
+probably a lot harder to implement, and using a small amount more CPU in
+cases where the external special remote is really doing its own
+checksumming.
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_8_593b8710c25bec1182409b36d6c44b4a._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_8_593b8710c25bec1182409b36d6c44b4a._comment
new file mode 100644
index 0000000000..e1b0bf777f
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_8_593b8710c25bec1182409b36d6c44b4a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2021-02-09T21:04:12Z"
+ content="""
+The incrementalhash branch has a mostly complete implementation of
+incremental hashing on download, for retrieiving from git-annex
+remotes. And the Backend interface added for that should be easy to use in
+some special remotes as well. Let's start with that, worry about external
+special remotes only after the low-hanging fruit is picked.
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_9_4f4f4a42adafe52207ed32a5d20e94be._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_9_4f4f4a42adafe52207ed32a5d20e94be._comment
new file mode 100644
index 0000000000..41b1d41acc
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_9_4f4f4a42adafe52207ed32a5d20e94be._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""update"""
+ date="2021-02-10T16:42:46Z"
+ content="""
+Incremental hashing implemented for transfers over ssh and tor.
+
+A good next step would be transfers to/from local git remotes.
+Currently those use rsync, or cp for CoW. It does not make sense to trust
+rsync's checksum verification here, because garbage in, garbage out --
+rsync doesn't know what the hash should be and will happily transfer a
+corrupted file. So instead, this would need to stop using rsync, and
+instead implement our own file to file copying with resuming and incremental
+hashing. Which would not be hard, and gets rid of the dependency on
+rsync besides (except for talking with really old git-annex-ssh).
+
+As for cp, CoW also suffers from GIGO, so I think the file will still
+need to be read, after its copied, to make sure it has the expected
+checksum.
+
+Urk: Using rsync currently protects against
+[[bugs/URL_key_potential_data_loss]], so the replacement would also need to
+deal with that. Eg, by comparing the temp file content with the start of
+the object when resuming.
+"""]]
diff --git a/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_9_b92774b0feec3049bf6aef89614543df._comment b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_9_b92774b0feec3049bf6aef89614543df._comment
new file mode 100644
index 0000000000..6dbdad3779
--- /dev/null
+++ b/doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_9_b92774b0feec3049bf6aef89614543df._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 9"
+ date="2021-02-09T22:48:04Z"
+ content="""
+Thank you Joey!  In my particular/initial use case having it done only for \"native\" git annex downloads would already be great.  
+
+In the long term I do see us implementing it for `datalad` special remote.  Having it somehow just \"streaming\" into git annex would probably be the \"easiest on custom remotes\" and would provide most flexibility since it would be up to annex to use corresponding to backend checksum.  
+
+But I wonder if \"streaming\" is really needed -- through `TRANSFER STORE somekey tmpfile` annex already knows where the file downloaded so far is, most recently written blocks are likely to be in the FS cache, so may be it would suffice for a special remote to, in addition to PROGRESS, announce how many sequential bytes from the beginning have been downloaded already, and so if git-annex incrementally reads from the \"growing\" file it would just work? (I am not sure if Windows would allow for such \"collaborative\" use of the file where one process writes and another one reads)   Although I guess it would mean that `git-annex` would still need to trust external remote to not later change some earlier bytes in the file, so might be not sufficiently secure.  Thus probably true streaming/named pipe Ilya suggested would be needed.
+"""]]
diff --git a/doc/todo/PATCH__58___drop_url_parameters_from_extension.hs b/doc/todo/PATCH__58___drop_url_parameters_from_extension.hs
new file mode 100644
index 0000000000..580ed96bab
--- /dev/null
+++ b/doc/todo/PATCH__58___drop_url_parameters_from_extension.hs
@@ -0,0 +1,56 @@
+commit e233211d1d3bdc844d44f73be37c926393a57571
+Author: James MacMahon <jwm@operand.ca>
+Date:   Sat Oct 8 01:23:22 2016 -0400
+
+    Drop URL parameters from file extension
+    
+    During RSS feed importing, some enclosures have URL parameters in them:
+    
+        http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/classictales/CT_491_The_Blood_is_the_Life.mp3?dest-id=60626
+    
+    With --template='${feedtitle}/${itempubdate}-${itemtitle}${extension}',
+    this is sanitized to
+    
+        "The_Classic_Tales_Podcast/2016_10_07-Ep._491__The_Blood_Is_The_Life__by_F._Marion_Crawford.mp3_dest_id_60626"
+    
+    The culprit here is `takeExtension` in Command/ImportFeed.hs:
+    
+        rundownload url (takeExtension url) $ \f -> do
+    
+    `takeExtension` is a Posix function that returns the file extension,
+    which means all characters after the last '.':
+    
+        > takeExtension "http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/classictales/CT_491_The_Blood_is_the_Life.mp3?dest-id=60626"
+        ".mp3?dest-id=60626"
+    
+    This commit implements the function dropUrlParameters to take care of
+    this:
+    
+        > dropUrlParameters $ takeExtension "http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/classictales/CT_491_The_Blood_is_the_Life.mp3?dest-id=60626"
+        ".mp3"
+
+diff --git a/Command/ImportFeed.hs b/Command/ImportFeed.hs
+index 498d504..210aca0 100644
+--- a/Command/ImportFeed.hs
++++ b/Command/ImportFeed.hs
+@@ -158,10 +158,16 @@ downloadFeed url
+                                , return Nothing
+                                )
+ 
++dropUrlParameters :: String -> String
++dropUrlParameters (x:xs) = case x of
++       '?'       -> []
++       otherwise -> [x] ++ dropUrlParameters xs
++dropUrlParameters (x) = x
++
+ performDownload :: ImportFeedOptions -> Cache -> ToDownload -> Annex Bool
+ performDownload opts cache todownload = case location todownload of
+        Enclosure url -> checkknown url $
+-               rundownload url (takeExtension url) $ \f -> do
++               rundownload url (dropUrlParameters $ takeExtension url) $ \f -> do
+                        r <- Remote.claimingUrl url
+                        if Remote.uuid r == webUUID || rawOption opts
+                                then do
+
+> Hmm, didn't cleanly apply for some reason. And, `takeWhile (/= '?')` is a 
+> simpler way to do that. Thank you for the bug report and patch; [[done]] --[[Joey]]
diff --git a/doc/todo/Package_for_Lacie_NasOS__63__.mdwn b/doc/todo/Package_for_Lacie_NasOS__63__.mdwn
new file mode 100644
index 0000000000..635a9fcb82
--- /dev/null
+++ b/doc/todo/Package_for_Lacie_NasOS__63__.mdwn
@@ -0,0 +1,3 @@
+Would it be possible to create a package for Lacie's NacOS?
+
+> [[closing|done]] --[[Joey]]
diff --git a/doc/todo/Package_for_Lacie_NasOS__63__/comment_1_1b1b23b95b1fa29a8d71848a5cec9008._comment b/doc/todo/Package_for_Lacie_NasOS__63__/comment_1_1b1b23b95b1fa29a8d71848a5cec9008._comment
new file mode 100644
index 0000000000..4fffad28c5
--- /dev/null
+++ b/doc/todo/Package_for_Lacie_NasOS__63__/comment_1_1b1b23b95b1fa29a8d71848a5cec9008._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-01-20T18:56:36Z"
+ content="""
+If that is a Linux-based NAS, there's a reasonably good chance that one
+of the [Linux standalone builds](https://git-annex.branchable.com/install/Linux_standalone/)
+of git-annex will run on it.
+
+Actually, from what I can see, it's based on Debian, so you might be able
+to just apt-get install git-annex
+"""]]
diff --git a/doc/todo/Package_for_Lacie_NasOS__63__/comment_2_81b181781da615c56aa30eab131cec53._comment b/doc/todo/Package_for_Lacie_NasOS__63__/comment_2_81b181781da615c56aa30eab131cec53._comment
new file mode 100644
index 0000000000..7795a7ca4d
--- /dev/null
+++ b/doc/todo/Package_for_Lacie_NasOS__63__/comment_2_81b181781da615c56aa30eab131cec53._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="db"
+ subject="comment 2"
+ date="2016-01-22T19:00:57Z"
+ content="""
+Yes it is Linux:
+
+$ uname -a
+Linux nas 3.10.59-svn15282 #1 SMP Fri Jul 31 13:36:10 UTC 2015 x86_64 GNU/Linux
+
+But it does not have apt. And probably not a compiler either.
+
+Is it complicated to install a compiled version manually? Or is it \"self-containing\"? Any instructions for cross compiling on a Mac?
+"""]]
diff --git a/doc/todo/Package_for_Lacie_NasOS__63__/comment_3_fd7eeee6a86101867f0ab17f883f0c6a._comment b/doc/todo/Package_for_Lacie_NasOS__63__/comment_3_fd7eeee6a86101867f0ab17f883f0c6a._comment
new file mode 100644
index 0000000000..b69146873c
--- /dev/null
+++ b/doc/todo/Package_for_Lacie_NasOS__63__/comment_3_fd7eeee6a86101867f0ab17f883f0c6a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-01-22T19:39:17Z"
+ content="""
+Get a build from
+<https://git-annex.branchable.com/install/Linux_standalone/>
+"""]]
diff --git a/doc/todo/Pause_all_transfers_in_all_annexes_watched_by_the_assistant.mdwn b/doc/todo/Pause_all_transfers_in_all_annexes_watched_by_the_assistant.mdwn
new file mode 100644
index 0000000000..2ce33f726b
--- /dev/null
+++ b/doc/todo/Pause_all_transfers_in_all_annexes_watched_by_the_assistant.mdwn
@@ -0,0 +1,11 @@
+## Use case:
+
+You have a few annexes that the assistant is watching for you. You're somewhere with poor wifi speed. You also just added a bunch of big files to a few annexes. Now all of a sudden your connection suffers and you want an easy way to pause all transfers until you're on a faster connection without losing the automatic 'add' and such of the assistant (iow: without having to shutdown the daemon).
+
+## Proposal:
+
+A "Pause all transfers" button in the webapp that pauses all transfers from all annexes the assistant is watching.
+
+It should toggle to "Resume all transfers" when pushed so you can also easily start the transfers again when you get somewhere else.
+
+This may or may not make more sense if the webapp showed all watched repos in a single view (instead of the separate pages/views as it is now).
diff --git a/doc/todo/Prevent_simultaneous_pushing_to_idential_remotes.mdwn b/doc/todo/Prevent_simultaneous_pushing_to_idential_remotes.mdwn
new file mode 100644
index 0000000000..2e44fc770e
--- /dev/null
+++ b/doc/todo/Prevent_simultaneous_pushing_to_idential_remotes.mdwn
@@ -0,0 +1,22 @@
+Hi joey,
+
+(This might be considered a bug but it is not a dealbreaker so I put it as a todo)
+
+When multiple configured git remotes have the same `annex-uuid` (e.g. there's multiple URLs to the same repo, which can be the case if there's a fast local url and a slow publicly accessible url), `git annex sync|assist|push --jobs=cpus` (nightly build) pushes simultaneously via all paths. Depending on who wins the race, slower pushes fail with something like:
+
+```
+remote: error: cannot lock ref 'refs/heads/synced/master': is at ce08fb81df1df82357dfd58aad9d1f65e6d2e58a but expected e8a067f2
+19eaa5947c3553e7d06c23d5f830a6de                                                                                               
+To ssh://URL                                                                      
+ ! [remote rejected] master -> synced/master (failed to update ref) 
+```
+
+Immediately syncing again afterwards skips the pushing as everything is up to date.
+
+This is just a cosmetic inconvenience and doesn't stop syncing from working. However, I guess nobody likes having red error messages thrown at them (can cause a certain spike in heart rate if one is on a tight schedule 😉). git annex knows that the remotes are effectively the same repo, so it could just push to them in sequence (sorted by lowest cost) and stop after the first successful push.
+
+Cheers,
+
+Yann
+
+P.S.: Thanks for git-annex, it is just a joy to use 🙂
diff --git a/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__.mdwn b/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__.mdwn
new file mode 100644
index 0000000000..0cf990e830
--- /dev/null
+++ b/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__.mdwn
@@ -0,0 +1,5 @@
+Original whining and use case [is buried in the comments to CVE fix announcement](https://git-annex.branchable.com/security/#comment-7d9435f13213b85896a3424c342c9a1f). In summary: `http_proxy` environment variable could point to some address within local network (e.g. `10.0.0.1/24`). `security.allowed-ip-addresses` (or older `annex.security.allowed-http-addresses`) seems to support only a whitespace separate list of addresses (too tedious to list for sizeable private networks) or "all" (too much) not support networks.  
+In case of `http_proxy` it would also be valuable to be able to limit to specific (e.g. privileged) port(s) (thus kicking back to `http` from a generic `ip`), to avoid opening access to some malicious user providing URLs on the same private network on some other port.  I think both address + port "wishlist" items are related thus filing in a single issue. 
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
diff --git a/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_1_26d81cbc8732b65c2f0a86a33ef0f8fd._comment b/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_1_26d81cbc8732b65c2f0a86a33ef0f8fd._comment
new file mode 100644
index 0000000000..7e2910ec03
--- /dev/null
+++ b/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_1_26d81cbc8732b65c2f0a86a33ef0f8fd._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-25T17:47:45Z"
+ content="""
+If the goal is just to allow the `http_proxy` to be used even though it
+points to a proxy on the local network, then it could be done
+with some "trustproxy" config, without needing to complicate
+annex.security.allowed-http-addresses.
+
+I am doubtful about the security of local http proxies though,
+in the threat model that git-annex needs to worry about. When
+`http_proxy` is set, urls get passed to it as-is; git-annex is not
+currently able to interpose any checking that the url is on an allowed
+IP address.
+
+(git-annex cannot send http://$ipaddr/ to the http proxy, 
+because the http server may require a specific hostname.
+And if git-annex only resolved the hostname and rejected ones on invalid
+IPs, then the http proxy would again resolve the hostname, and might
+see a different IP address than git-annex did.)
+
+So allowing a local http proxy seems just as insecure as
+annex.security.allowed-http-addresses=all.
+"""]]
diff --git a/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_2_64ffa9a560bf11ba22c715da0b4b1cfe._comment b/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_2_64ffa9a560bf11ba22c715da0b4b1cfe._comment
new file mode 100644
index 0000000000..946577f65c
--- /dev/null
+++ b/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_2_64ffa9a560bf11ba22c715da0b4b1cfe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-02-25T18:32:02Z"
+ content="""
+As to ports, it seems reasonable to support eg
+security.allowed-ip-addresses=[127.0.0.1]:80 to make sure that the massive
+electron app I have running on some random other port doesn't get abused
+to exfiltrate the contents of my $HOME. As a non-random example. :)
+"""]]
diff --git a/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_3_da5363a268008a88014972987de10323._comment b/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_3_da5363a268008a88014972987de10323._comment
new file mode 100644
index 0000000000..c9b29b3462
--- /dev/null
+++ b/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_3_da5363a268008a88014972987de10323._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-02-25T19:30:35Z"
+ content="""
+Implemented specifying allowed ports.
+"""]]
diff --git a/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_4_620fd718bd2c97a6fa4ce775e311a2d6._comment b/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_4_620fd718bd2c97a6fa4ce775e311a2d6._comment
new file mode 100644
index 0000000000..af1d3ba05a
--- /dev/null
+++ b/doc/todo/Provide_a_way_to_white_list_local_networks___40__not_just_specific_IPs__41__/comment_4_620fd718bd2c97a6fa4ce775e311a2d6._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-02-25T19:46:02Z"
+ content="""
+Back to the proxy question, I suppose if you have multiple internal 
+networks and the proxy can only access one of them (eg your DMZ),
+then allowing access to the proxy is not as bad as "all".
+
+And then DMZ/24 makes explicit that git-annex can access everything in that
+network.
+
+Nor am I opposed to that syntax generally (although as I user, I consider
+it pretty opaque TBH, not being in the habit of counting bits in my head).
+The only haskell implementation I can find is in the `ip` package,
+which would be a new dependency for git-annex.
+"""]]
diff --git a/doc/todo/RawFilePath_conversion.mdwn b/doc/todo/RawFilePath_conversion.mdwn
new file mode 100644
index 0000000000..b1e1d3e9cd
--- /dev/null
+++ b/doc/todo/RawFilePath_conversion.mdwn
@@ -0,0 +1,75 @@
+For a long time (since 2019) git-annex has been progressively converting from
+FilePath to RawFilePath (aka ByteString).
+
+The reason is mostly performance, also a simpler representation of
+filepaths that doesn't need encoding hacks to support non-UTF8 values.
+
+Some commands like `git-annex find` use RawFilePath end-to-end. 
+But this conversion is not yet complete. This is a todo to keep track of the
+status.
+
+* The Abstract FilePath proposal (AFPP) has been implemented, and so a number of
+  libraries like unix and directory now have versions that operate on
+  OSPath. That could be used in git-annex eg for things like
+  getDirectoryContents, when built against those versions.
+  (But OSPath uses ShortByteString, while RawFilePath is ByteString, so
+  conversion still entails a copy.)
+* withFile remains to be converted, and is used in several important code
+  paths, including Annex.Journal and Annex.Link. 
+  There is a RawFilePath version in file-io library, but that is
+  not currently a git-annex dependency. (withFile is in base, and base is
+  unlikely to convert to AFPP soon)
+
+[[!tag confirmed]]
+
+----
+
+The following patch can be useful to find points where conversions are
+done. Especially useful to identify cases where a value is converted
+`FilePath -> RawFilePath -> FilePath`.
+
+    diff --git a/Utility/FileSystemEncoding.hs b/Utility/FileSystemEncoding.hs
+    index 2a1dc81bc1..03e6986f6e 100644
+    --- a/Utility/FileSystemEncoding.hs
+    +++ b/Utility/FileSystemEncoding.hs
+    @@ -84,6 +84,9 @@ encodeBL = L.fromStrict . encodeBS
+     encodeBL = L8.fromString
+     #endif
+     
+    +debugConversions :: String -> IO ()
+    +debugConversions s = hPutStrLn stderr ("conversion: " ++ s)
+    +
+     decodeBS :: S.ByteString -> FilePath
+     #ifndef mingw32_HOST_OS
+     -- This does the same thing as System.FilePath.ByteString.decodeFilePath,
+    @@ -92,6 +95,7 @@ decodeBS :: S.ByteString -> FilePath
+     -- something other than a unix filepath.
+     {-# NOINLINE decodeBS #-}
+     decodeBS b = unsafePerformIO $ do
+    +	debugConversions (show b)
+     	enc <- Encoding.getFileSystemEncoding
+     	S.useAsCStringLen b (GHC.peekCStringLen enc)
+     #else
+    @@ -106,17 +110,19 @@ encodeBS :: FilePath -> S.ByteString
+     -- something other than a unix filepath.
+     {-# NOINLINE encodeBS #-}
+     encodeBS f = unsafePerformIO $ do
+    +	debugConversions f
+     	enc <- Encoding.getFileSystemEncoding
+    -	GHC.newCStringLen enc f >>= unsafePackMallocCStringLen
+    +	b <- GHC.newCStringLen enc f >>= unsafePackMallocCStringLen
+    +	return b
+     #else
+     encodeBS = S8.fromString
+     #endif
+     
+     fromRawFilePath :: RawFilePath -> FilePath
+    -fromRawFilePath = decodeFilePath
+    +fromRawFilePath = decodeBS -- decodeFilePath
+     
+     toRawFilePath :: FilePath -> RawFilePath
+    -toRawFilePath = encodeFilePath
+    +toRawFilePath = encodeBS -- encodeFilePath
+     
+     {- Truncates a FilePath to the given number of bytes (or less),
+      - as represented on disk.
diff --git a/doc/todo/Request__58___Date_limit_with_importfeed.mdwn b/doc/todo/Request__58___Date_limit_with_importfeed.mdwn
new file mode 100644
index 0000000000..1448fe0c26
--- /dev/null
+++ b/doc/todo/Request__58___Date_limit_with_importfeed.mdwn
@@ -0,0 +1,3 @@
+I'm using importfeed with some podcasts, but I only want the most recent items. Importfeed seems to import all items in the feed, so I'm ending up with hundreds of them going back into last year and beyond. There doesn't seem to be a way to limit this.
+
+A switch to define the oldest file to download would be nice. Perhaps something with this format (for Jan 1st 2020): --oldest 20200101
diff --git a/doc/todo/Request__58___Date_limit_with_importfeed/comment_1_5d3d762eaf755410f5ee70a22fc95ab6._comment b/doc/todo/Request__58___Date_limit_with_importfeed/comment_1_5d3d762eaf755410f5ee70a22fc95ab6._comment
new file mode 100644
index 0000000000..c8249dd39a
--- /dev/null
+++ b/doc/todo/Request__58___Date_limit_with_importfeed/comment_1_5d3d762eaf755410f5ee70a22fc95ab6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-07-27T15:34:53Z"
+ content="""
+What I do in this situation is use importfeed with --fast, and then delete
+the old episodes I am not interested in, and `git-annex get` the ones I do
+want. Or even use --relaxed if there are so many episodes that the http
+traffic to check their sizes takes too long.
+"""]]
diff --git a/doc/todo/S3_export_redirecting_to_key-value_store.mdwn b/doc/todo/S3_export_redirecting_to_key-value_store.mdwn
new file mode 100644
index 0000000000..942e66a441
--- /dev/null
+++ b/doc/todo/S3_export_redirecting_to_key-value_store.mdwn
@@ -0,0 +1,5 @@
+S3 lets you [redirect](https://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-redirect.html) requests for an object to another object, or to a URL.  This could be used to export a git branch, in the manner of [[`git-annex-export`|git-annex-export]], but with annexed objects redirecting to a key-value S3 remote in the same bucket.
+
+Related: [[todo/simpler__44___trusted_export_remotes]] ; [[forum/Using_hashdirlower_layout_for_S3_special_remote]].
+
+[[!tag needsthought unlikely]]
diff --git a/doc/todo/S3_multipart_interruption_cleanup.mdwn b/doc/todo/S3_multipart_interruption_cleanup.mdwn
new file mode 100644
index 0000000000..adb5fd2cb0
--- /dev/null
+++ b/doc/todo/S3_multipart_interruption_cleanup.mdwn
@@ -0,0 +1,14 @@
+When a multipart S3 upload is being made, and gets interrupted,
+the parts remain in the bucket, and S3 may charge for them.
+
+I am not sure what happens if the same object gets uploaded again. Is S3
+nice enough to remove the old parts? I need to find out..
+
+If not, this needs to be dealt with somehow. One way would be to configure an
+expiry of the uploaded parts, but this is tricky as a huge upload could
+take arbitrarily long. Another way would be to record the uploadid and the
+etags of the parts, and then resume where it left off the next time the
+object is sent to S3. (Or at least cancel the old upload; resume isn't
+practical when uploading an encrypted object.) 
+
+It could store that info in either the local FS or the git-annex branch.
diff --git a/doc/todo/Set_total_storage_limit_for_special_remotes.mdwn b/doc/todo/Set_total_storage_limit_for_special_remotes.mdwn
new file mode 100644
index 0000000000..59c5794a87
--- /dev/null
+++ b/doc/todo/Set_total_storage_limit_for_special_remotes.mdwn
@@ -0,0 +1,3 @@
+I'd like to be able to set a fixed limit on how much storage can be uploaded to a special remote. A use case for this may be that I want to spend no more than Y dollars, on a storage service that charges $X per gigabyte. I would thus set a limit where I a upload would be interrupted with a warning about the limit, and to continue I would need to use a --force option.
+
+> dup of [[Specify_maximum_usable_space_per_remote]]; [[done]] --[[Joey]]
diff --git a/doc/todo/Set_total_storage_limit_for_special_remotes/comment_1_8945025ad54e28f48474f8931746a775._comment b/doc/todo/Set_total_storage_limit_for_special_remotes/comment_1_8945025ad54e28f48474f8931746a775._comment
new file mode 100644
index 0000000000..0df5669d66
--- /dev/null
+++ b/doc/todo/Set_total_storage_limit_for_special_remotes/comment_1_8945025ad54e28f48474f8931746a775._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T20:01:42Z"
+ content="""
+This totally makes sense to want, but it's rather difficult to implement since
+multiple git-annex repos can all be uploading content to the same special
+remote, while disconnected from each other.
+"""]]
diff --git a/doc/todo/Set_total_storage_limit_for_special_remotes/comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment b/doc/todo/Set_total_storage_limit_for_special_remotes/comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment
new file mode 100644
index 0000000000..818b7f3862
--- /dev/null
+++ b/doc/todo/Set_total_storage_limit_for_special_remotes/comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="mawillcockson"
+ subject="comment 2"
+ date="2015-07-18T19:13:03Z"
+ content="""
+Perhaps server-side [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)?
+
+Maybe a git hook script that uses [inotify](https://en.wikipedia.org/wiki/Inotify) for inode size notifications.
+
+I would have no idea how to implement this, though.
+"""]]
diff --git a/doc/todo/Setting_default_preferred_content_expressions.mdwn b/doc/todo/Setting_default_preferred_content_expressions.mdwn
new file mode 100644
index 0000000000..19c5100e39
--- /dev/null
+++ b/doc/todo/Setting_default_preferred_content_expressions.mdwn
@@ -0,0 +1,26 @@
+Hey Joey,
+
+If I understand correctly, the default content expression (when it's empty, e.g. after a `git annex init` or `git clone ...;git annex sync`) is currently apparently `anything`. This means that a `git annex sync --content` (or just `git annex sync` if `git config --set annex.synccontent true`) will fetch all files.
+
+It would be very handy if there was something like:
+
+[[!format  bash """
+git annex config --set annex.defaultwanted ...
+git annex config --set annex.defaultgroup ...
+git annex config --set annex.defaultgroupwanted ...
+git annex config --set annex.defaultrequired ...
+
+# and the corresponding git variant for user-overriding
+git config [--global|--system] annex.defaultwanted ...
+git config [--global|--system] annex.defaultgroup ...
+git config [--global|--system] annex.defaultgroupwanted ...
+git config [--global|--system] annex.defaultrequired ...
+"""]]
+
+These defaults would be applied when `git annex` initializes a repository (i.e. gives it a `annex.uuid`, e.g. `git annex init` or `git annex sync` of a fresh clone of a repo with annex).
+
+I like my annexed/datalad repos (mostly research data next to analysis code for collaboration) to have `annex.synccontent = true` so people can just do (`datalad save`/`git annex add`) `git annex sync` and be sure afterwards everything is in order and safe. However as the default `wanted` is `anything` (apparently), they also get all files they probably don't want if they don't to `git annex wanted . present` manually (and manual boilerplate config and extra steps is always something that's nice to automate). Something like `git annex config --set annex.defaultwanted present` would solve this.
+
+Thanks again very much for git-annex, I love it! 💛
+
+Yann
diff --git a/doc/todo/Setting_default_preferred_content_expressions/comment_1_45d57933a45ddc1e31ba46519b944239._comment b/doc/todo/Setting_default_preferred_content_expressions/comment_1_45d57933a45ddc1e31ba46519b944239._comment
new file mode 100644
index 0000000000..fc120b0747
--- /dev/null
+++ b/doc/todo/Setting_default_preferred_content_expressions/comment_1_45d57933a45ddc1e31ba46519b944239._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-08-08T17:00:09Z"
+ content="""
+See also <https://github.com/datalad/datalad/issues/7468>
+"""]]
diff --git a/doc/todo/Setting_default_preferred_content_expressions/comment_2_575320e07f005d46d26cc6db9ad3ebd3._comment b/doc/todo/Setting_default_preferred_content_expressions/comment_2_575320e07f005d46d26cc6db9ad3ebd3._comment
new file mode 100644
index 0000000000..9ebfd99b8e
--- /dev/null
+++ b/doc/todo/Setting_default_preferred_content_expressions/comment_2_575320e07f005d46d26cc6db9ad3ebd3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="more use cases for configurable default preferred content"
+ date="2024-04-06T15:12:50Z"
+ content="""
+This came up again at the distribits meeting.
+
+DataLad itself is designed to work like `git annex wanted . present` (i.e. content is supposed to be fetched manually. It is assumed that the user does not generally want all content of a DataLad dataset / git annex repo). DataLad could itself run `git annex wanted . present` as part of its setup (talked about that with @mih), but I still think a setting in the git-annex branch that auto-sets the above settings in fresh clones (even when using plain git annex, not DataLad), is useful. It enhances the user experience of sparse checkouts (a `git annex assist` in a freshly cloned annex repo can then be configured to only pull specific or no files).
+
+I also discussed it with people in the context of handling confidential patient data that should not necessarily be copied everywhere. The default of just wanting all worktree content increases the delicacy of the matter a bit. Were there a way to have fresh clones (or even freshly created remotes that were not yet given a preferred content manually) have a preconfigured default wanted content, it would reduce the possibility of confidential data accidentally being copied all over the place.
+"""]]
diff --git a/doc/todo/Setting_default_preferred_content_expressions/comment_3_971b3efe8a6ebdeede0184f13774e86b._comment b/doc/todo/Setting_default_preferred_content_expressions/comment_3_971b3efe8a6ebdeede0184f13774e86b._comment
new file mode 100644
index 0000000000..0594820a87
--- /dev/null
+++ b/doc/todo/Setting_default_preferred_content_expressions/comment_3_971b3efe8a6ebdeede0184f13774e86b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-04-10T16:58:39Z"
+ content="""
+I agree, after discussions at distribits it's clear there is use for this
+in datalad, and in git-annex generally.
+"""]]
diff --git a/doc/todo/Should_git_annex_diffdriver_fetch_non-present_file.mdwn b/doc/todo/Should_git_annex_diffdriver_fetch_non-present_file.mdwn
new file mode 100644
index 0000000000..ac67e8406b
--- /dev/null
+++ b/doc/todo/Should_git_annex_diffdriver_fetch_non-present_file.mdwn
@@ -0,0 +1,9 @@
+I noticed that `git annex diffdriver` doesn't make sure that files it tries to diff are actually present. Would it make sense that `git annex diffdriver ...` runs `git annex get` to ensure files are present? 🤔 A `git diff` could then result in a lot of traffic if the user configured the `diffdriver`. But I'd say that users who took their time to configure would be are aware of this or even expect that to happen - after all they want to see the differences to a past version.
+
+A manual workaround is to handle the `get`ting in a custom supplied diffing program.
+
+Context:
+
+- [recently added `git annex diffdriver --text`](https://git-annex.branchable.com/todo/Improving_diffdriver_--text/)
+
+> Duplicate of [[--get_option_for_diffdriver]], so closing [[done]]. --[[Joey]]
diff --git a/doc/todo/Show_repo_type_in_repo_list.mdwn b/doc/todo/Show_repo_type_in_repo_list.mdwn
new file mode 100644
index 0000000000..40fbe6537e
--- /dev/null
+++ b/doc/todo/Show_repo_type_in_repo_list.mdwn
@@ -0,0 +1 @@
+It would be helpful to show each repo's type in the list.
diff --git a/doc/todo/Show_repo_type_in_repo_list/comment_1_ac6eb1072ef902a094b79dd8e0917c4d._comment b/doc/todo/Show_repo_type_in_repo_list/comment_1_ac6eb1072ef902a094b79dd8e0917c4d._comment
new file mode 100644
index 0000000000..10c0c17df4
--- /dev/null
+++ b/doc/todo/Show_repo_type_in_repo_list/comment_1_ac6eb1072ef902a094b79dd8e0917c4d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-02T23:45:39Z"
+ content="""
+Currently if you go to the edit page for the repository, it shows some information about it, including its type and often its location, at the bottom of the page.
+
+I tend to feel that putting anything else in the repo list would result in it being too cluttered.
+"""]]
diff --git a/doc/todo/Show_repo_type_in_repo_list/comment_2_6979c487f707a724a048d20e2e5744e6._comment b/doc/todo/Show_repo_type_in_repo_list/comment_2_6979c487f707a724a048d20e2e5744e6._comment
new file mode 100644
index 0000000000..7d4a363242
--- /dev/null
+++ b/doc/todo/Show_repo_type_in_repo_list/comment_2_6979c487f707a724a048d20e2e5744e6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU"
+ nickname="Adam"
+ subject="comment 2"
+ date="2013-11-02T23:59:16Z"
+ content="""
+I understand.  Well, here's what I'm looking at right now.  :)
+
+[[http://alphapapa.net/outbox/view.png]]
+
+I just think it would be very useful to say \"Client\" or \"Transfer\" or \"Full Backup\" next to each one, and there's often plenty of room, depending on the size of the window.  Especially when one's trying to wrap one's head around git-annex, being reminded what each repo is for would help a lot.  Otherwise you basically have to put it in the name or description yourself...so why not just go ahead and show it?  :)
+
+Another option might be to have an icon for each type.
+"""]]
diff --git a/doc/todo/Show_repo_type_in_repo_list/comment_3_529254a6cc20de7259d60a3cbc5ccaf7._comment b/doc/todo/Show_repo_type_in_repo_list/comment_3_529254a6cc20de7259d60a3cbc5ccaf7._comment
new file mode 100644
index 0000000000..3f8b826950
--- /dev/null
+++ b/doc/todo/Show_repo_type_in_repo_list/comment_3_529254a6cc20de7259d60a3cbc5ccaf7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 3"
+ date="2013-11-03T00:19:34Z"
+ content="""
+I'd be happy to put in some icons if someone finds some good (and suitably licensed) ones that cover the different types of repositories.
+"""]]
diff --git a/doc/todo/Sorting_remotes_by_description_in___96__git_annex_info__96__.mdwn b/doc/todo/Sorting_remotes_by_description_in___96__git_annex_info__96__.mdwn
new file mode 100644
index 0000000000..ae825b0e81
--- /dev/null
+++ b/doc/todo/Sorting_remotes_by_description_in___96__git_annex_info__96__.mdwn
@@ -0,0 +1,5 @@
+Hey joey,
+
+How about sorting the remotes in `git annex info` by their description instead of their UUID (which is effectively a random order)? Would make for a better overview IMO.
+
+Cheers, Yann
diff --git a/doc/todo/Special_remotes__58___support_for_MULTIREMOVE.mdwn b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE.mdwn
new file mode 100644
index 0000000000..eb4393a2bc
--- /dev/null
+++ b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE.mdwn
@@ -0,0 +1,3 @@
+Currently, when we use small chunks for large files, `git annex drop` can take a long time on external remotes. One possible solution seems to be that we batch multiple REMOVEs in a single call to the special remote so that it can be optimized by it if needed.
+
+This is still not ideal, but seems reasonably safe and easy to do. Thoughts?
diff --git a/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_1_cc95104ae0803db35fee504152db046a._comment b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_1_cc95104ae0803db35fee504152db046a._comment
new file mode 100644
index 0000000000..966e9d220b
--- /dev/null
+++ b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_1_cc95104ae0803db35fee504152db046a._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-13T16:02:58Z"
+ content="""
+This extension to the protocol would only be useful when removing chunks,
+because otherwise git-annex doesn't have a way to build up a list of keys
+that are going to be removed, in a way that could usefully be sent to the
+external special remote together.
+
+For chunks, it has a list of keys. So this is feasible.
+
+I wonder if it's necessary to extend the protocol though. If an external
+special remote wants to, it can buffer a list of keys that it's been told
+to remove, and return REMOVE-SUCCESS to each request before actually
+doing the removal. It could then
+remove all the buffered keys in a single API call or whatever.
+
+The risk of course is that if the removal fails, or it's interrupted before
+it can do the removal, it will have incorrectly claimed to remove the keys.
+And git-annex will have recorded incorrect information and wrongly
+indicated the removal succeeded. This would not be a good idea for non-chunk
+keys (although `fsck --fast --from` the remote could recover from it).
+
+For a set of chunk keys that are all chunks of the same key, though,
+git-annex doesn't record anything until they've all been successfully
+removed. Also, it so happens that after asking for all the chunked keys to
+be removed, git-annex normally[1] then asks for the unchunked key to be
+removed too. So, a special remote could buffer chunked keys until it sees
+an unchunked key, and then remove them all efficiently, and reply to the
+removal of the unchunked key with the combined result of all the removals.
+
+[1] The exception is that, if the special remote is not currently
+configured to use chunking, git-annex happens to remove the unchunked key
+first, followed by all the chunked keys. I don't think there is a good
+reason for this in removal; it's a useful optimisation for retrieving
+content that happens to affect removal too.
+"""]]
diff --git a/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_2_f58cc7b04948a8c758f97778631b0f02._comment b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_2_f58cc7b04948a8c758f97778631b0f02._comment
new file mode 100644
index 0000000000..37ef514e6e
--- /dev/null
+++ b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_2_f58cc7b04948a8c758f97778631b0f02._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-13T16:26:06Z"
+ content="""
+I don't know that the above comment is really a good idea for an external
+remote to try to implement. Needing to know about chunk keys is not too
+bad, but it also relies on details of git-annex's implementation.
+
+But it seems worth considering possibilities
+like that, since this extension would only be used in such a relative
+corner case.
+
+Or possibly considering ways to generalize the idea to be usable in more
+cases..
+
+Along those lines, it occurs to me that the async extension to the
+protocol is somewhat similar, since git-annex can ask the external remote
+to do several things at the same time. Removals of chunk keys are not
+currently run concurrently, but they could be. An external remote could
+then gather together some number of concurrent remove requests and perform
+them all in a single API call (or whatever).
+
+But how would the external remote know when it's seen all the remove
+requests for chunks of a key? It seems like it would need to use a
+heuristic, like no new requests in some amount of time means git-annex is
+waiting on it to remove everything it's been requested to remove.
+
+So it might be that a protocol extension would be useful, some way for
+git-annex to indicate that it is blocked waiting on current requests to
+finish. That seems more general purpose than a MULTIREMOVE extension.
+For example, git-annex could also send it when retrieving chunks.
+(Although retrieving chunks is also not currently done concurrently.)
+
+(There's also a question of how many concurrent removals of chunk
+keys it would make sense for git-annex to request at the same time. It
+could request removing all chunks concurrently but if the special
+remote needs to do much work or use resources for each request, that
+might not be good. It would probably be more natural to use something
+based on -J.)
+"""]]
diff --git a/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_3_4f18712f974f85c3cef810714d304d85._comment b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_3_4f18712f974f85c3cef810714d304d85._comment
new file mode 100644
index 0000000000..1edb09b9d0
--- /dev/null
+++ b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_3_4f18712f974f85c3cef810714d304d85._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="prancewit"
+ avatar="http://cdn.libravatar.org/avatar/f6cc165b68a5cca3311f9a1cd7fd027c"
+ subject="My current use case"
+ date="2022-09-13T19:45:23Z"
+ content="""
+Thanks for the response, Joey.
+
+Let me start by providing more details the use case where I noticed this slowness.
+
+I was using a slow remote with a lot of chunks. I stopped the upload and wanted to do a cleanup of the uploaded chunks. That's when I noticed that git-annex was requesting a removal of each chunk individually, even ones that never actually got uploaded.
+
+In this particular case, I could \"preload\" the data since I knew which chunks were valid and which ones weren't to make it faster (though I actually just waited it out)
+
+Also, like you mentioned, this MULTIREMOVE is most useful for this specific case so a more generic solution will definitely be much better.
+"""]]
diff --git a/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_4_2dbf3558c7c969281f1cc5e1738d2c0b._comment b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_4_2dbf3558c7c969281f1cc5e1738d2c0b._comment
new file mode 100644
index 0000000000..3e838fd098
--- /dev/null
+++ b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_4_2dbf3558c7c969281f1cc5e1738d2c0b._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="prancewit"
+ avatar="http://cdn.libravatar.org/avatar/f6cc165b68a5cca3311f9a1cd7fd027c"
+ subject="comment 4"
+ date="2022-09-13T21:36:38Z"
+ content="""
+At a high level, I see 2 possible ways in which special remotes can optimize for larger queries
+
+* Pre-fetch or cache state of existing keys (Mostly useful only for no-op requests. For instance, pre-fetch the list of keys in the remote enabling no-op REMOVEs, but hard to tell if there's been a separate change since the fetch)
+* Batch multiple requests in a single call. (Batching can be done before or after sending the SUCCESS response to git-annex with corresponding results)
+
+
+> So it might be that a protocol extension would be useful, some way for git-annex to indicate that it is blocked waiting on current requests to finish.
+
+I can think of a few related ways to do this:
+
+* Have the remote send ACKs to notify that it's ready for the next request, and send SUCCESS when the request is actually completed. The remote can then have the flexibility to run them in whatever batch/async manner suitable. In the case of chunk-keys, git-annex could rapidly send successive keys in sequence since there's no additional lookup required making it pretty efficient.
+* Have git-annex send some kind of group identifier (all chunks of same key might be grouped together) or delimiter(eg: GROUP_COMPLETED). This acts as a hint that these requests could be batched together without any obligation from the remote to do so. Coupled with a guarantee that all items in one group will be sent sequentially, the first item that belongs to a different group provides a guarantee that the previous group is completed. In this case, the SUCCESS for the last item could be taken to mean that the entire group is completed. One issue here is that this could leak some information in encrypted repositories.
+* Define a CACHE_TIMEOUT_SECONDS. This could be used by the remote to decide if any pre-fetched or cached data can be trusted or if they should be re-checked. Git-annex would use this during merge/sync with other remotes to determine if there's a conflict that needs to be handled differently. (Seems too complicated TBH, but trying to see how we can make pre-fetch/caching work)
+
+"""]]
diff --git a/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_5_4a9f2e1e3f30b472d4c5aa9c07684cc0._comment b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_5_4a9f2e1e3f30b472d4c5aa9c07684cc0._comment
new file mode 100644
index 0000000000..fb1cc4ed65
--- /dev/null
+++ b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_5_4a9f2e1e3f30b472d4c5aa9c07684cc0._comment
@@ -0,0 +1,96 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-09-15T16:41:44Z"
+ content="""
+I think what's needed is essentially a way for the external remote, when it
+gets a request, to ask git-annex, "is there anything else I could do
+at the same time?"
+
+This way the external remote can build up a list of requests of whatever
+size makes sense for it. And when git-annex answers "no, nothing else",
+the external remote knows that it needs to process the current list it has
+built up; git-annex is blocked waiting on the response.
+
+That seems to capture what is needed in the simplest way possible
+(aside from just implementing a special purpose MULTIREMOVE that is!)
+
+At the protocol level, it could look something like this:
+
+	REMOVE keya
+	ANY-MOREa
+	REMOVE keyb
+	ANY-MORE
+	REMOVE keyc
+	ANY-MORE
+	NO-MORE
+	REMOVE-SUCCESS keya
+	REMOVE-FAILURE keyb permission denied somehow
+	REMOVE-SUCCESS keyc
+
+But, implementation of that is not generic. removeKey sends REMOVE and
+waits for a `REMOVE-SUCCESS/FAILURE`. So it would need to handle the
+ANY-MORE by sending the next key. So, removeKey would need to be changed to
+take a list of keys, and return a list of results. Which seems
+unsatisfying, since it's the same change that would be needed to implement
+MULTIREMOVE. Any other actions would also need to be changed to take lists
+in order to support ANY-MORE.
+
+What if it were only used with the async protocol? Then it could look
+like this:
+
+	J 1 REMOVE keya
+	J 1 ANY-MORE
+	J 2 REMOVE keyb
+	J 1 SENT-MORE 2
+	J 2 ANY-MORE
+	J 3 REMOVE keyc
+	J 2 SENT-MORE 3
+	J 3 ANY-MORE
+	J 3 NO-MORE
+	J 1 REMOVE-SUCCESS keya
+	J 2 REMOVE-FAILURE keyb permission denied somehow
+	J 3 REMOVE-SUCCESS keyc
+
+This is more complicated due to using the async protocol. And also
+it's complicating what the remote needs to do, because it has to parse the
+SENT-MORE to find the job number that the next request was sent to.
+(Needed since there could be other, unrelated jobs being started at the
+same time.)
+
+The advantage is, it should be possible to implement that in git-annex
+without changing removeKey but only handleRequestKey. That will need a
+TVar that contains related requests. To handle ANY-MORE, it can get the
+next item from the TVar, start a thread to run it, and send the job
+number in SENT-MORE.
+
+A separate function `runMulti` can then discover that TVar somehow,
+and call removeKey with the first key, populating the TVar with
+the rest, etc. Resulting in a list of removeKey responses.
+
+Would each call to removeKey need to have the TVar be passed
+to it? Maybe not.. It seems to me that it would be ok to use the same TVar
+for all removeKeys for the same external remote, even ones that are
+handling different jobs. Eg, when git-annex -J2 is dropping two different
+keys, which each has a set of chunk keys, it's ok for the external remote to
+collect a set of keys to remove that combines both sets of chunk keys. It's
+even a win, because it lets the special remote batch more actions together!
+
+And this is generalized; it could support checkPresent and storeKey and 
+retrieveKeyFile, by using a separate TVar for each.
+Doing those operations on chunks would need further
+changes to use `runMulti`. 
+
+It might even be possible to get an external remote to 
+remote bundle together 10 checkPresent calls when handling
+`git-annex drop -J10` (for example). Which would allow for a 
+nice speedup even when not using chunks. This would I suppose need an
+equivilant `runSingle` that's used when calling checkPresent? Something
+like that.
+
+(I'm not sure how `runMulti` would discover the TVar to use
+for a given action and remote. Implementing that does not seem
+straightforward. One way, though hopefully not the only way, would
+be to make removeKey return a tuple of the TVar and an action that
+actually handles the removal.)
+"""]]
diff --git a/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_6_f756a8ea12af1a01406f1bf05d9dba11._comment b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_6_f756a8ea12af1a01406f1bf05d9dba11._comment
new file mode 100644
index 0000000000..ed497b634b
--- /dev/null
+++ b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_6_f756a8ea12af1a01406f1bf05d9dba11._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="prancewit"
+ avatar="http://cdn.libravatar.org/avatar/f6cc165b68a5cca3311f9a1cd7fd027c"
+ subject="comment 6"
+ date="2022-09-16T08:39:08Z"
+ content="""
+I love these ideas Joey. Couple of comments.
+
+> I think what's needed is essentially a way for the external remote, when it gets a request, to ask git-annex, \"is there anything else I could do at the same time?\"
+
+100% agreed. ANY-MORE is super generic and will be useful in all case. There's a simpler but slightly less generic option too. Instead of git-annex asking the remote after every action, it could instead ask first about the number of actions the remote wants. Something like,
+
+```
+git-annex -- remote
+-> REMOVE-COUNT
+<- REMOVE-COUNT 3
+-> REMOVE keya
+-> REMOVE keyb
+-> REMOVE keyc
+<- REMOVE-SUCCESS keya
+<- REMOVE-FAILURE keyb permission denied somehow
+<- REMOVE-SUCCESS keyc
+-> REMOVE-COUNT
+<- REMOVE-COUNT 3
+.
+.
+.
+```
+
+What we primarily lose here is that the remote does not have any information about the current action to base the decision on, and is instead a generic decision based on the action type (For instance, the remote could ask for 100 REMOVEs at a time, but only 10 ADDs). I'm not sure if there are use-cases where this additional information is useful to the remote, since remotes are typically \"dumb\" (What I mean is that by design the remotes typically doesn't understand the intent behind the action, they just need to know which file to add/remove/delete etc).
+
+
+> This is more complicated due to using the async protocol. And also it's complicating what the remote needs to do, because it has to parse the SENT-MORE to find the job number that the next request was sent to. (Needed since there could be other, unrelated jobs being started at the same time.)
+
+I'm assuming you mean that it is difficult to batch related operations in a single job due to implementation details in git-annex. However, just in case I'm misunderstanding that, I'd like to see if there's a good way for us to batch all related operations in one job instead of splitting them across jobs. My main argument for this case would be that if we send related keys/operations to multiple jobs, the only performance benefit we get is in IO with git-annex. This might be worth losing for the simplicity in which each job is guaranteed to get all related keys/operations. Maybe something like,
+
+```
+git-annex -- remote
+-> J 1 REMOVE-COUNT
+-> J 2 REMOVE-COUNT
+<- J 1 REMOVE-COUNT 3
+<- J 2 REMOVE-COUNT 3
+-> J 1 REMOVE keya
+-> J 1 REMOVE keyb
+-> J 1 REMOVE keyc
+-> J 2 REMOVE keyd
+<- J 1 REMOVE-SUCCESS keya
+<- J 1 REMOVE-FAILURE keyb permission denied somehow
+-> J 2 REMOVE keye
+-> J 2 REMOVE keyf
+<- J 1 REMOVE-SUCCESS keyc
+<- J 2 REMOVE-SUCCESS keyd
+<- J 2 REMOVE-SUCCESS keye
+<- J 2 REMOVE-SUCCESS keyf
+```
+
+It could potentially have slightly less performance (For instance, all keys might belong to one batch, so we are effectively single threaded), but the simplicity seems useful. I'm not super clear on the haskell/git-annex implementation which might be why I'm not understanding this.
+"""]]
diff --git a/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_7_993ed66935c0d95488751a0e0e2c57b8._comment b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_7_993ed66935c0d95488751a0e0e2c57b8._comment
new file mode 100644
index 0000000000..df432c53ca
--- /dev/null
+++ b/doc/todo/Special_remotes__58___support_for_MULTIREMOVE/comment_7_993ed66935c0d95488751a0e0e2c57b8._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-09-16T16:27:58Z"
+ content="""
+> I'm not sure if there are use-cases where this additional information is useful to the remote
+
+It would be useful when the actions transfer content, since the remote
+could look at the key sizes and accumulate a reasonable amount of data
+for it to handle in one operation.
+
+>> This is more complicated
+
+By that I meant, it's more complicated for the poor author of the external
+special remote, who has to learn about the async protocol.
+
+But not using the async protocol will always have the problem I discussed
+in comment #5, since the implementation in git-annex is always
+to send a command like REMOVE and wait for a response like REMOVE-SUCCESS.
+Using the async protocol lets it keep that implementation simple, by
+multiplexing the multiple removes into different jobs, which when
+demultiplexed look the same as a single remove looks now.
+"""]]
diff --git a/doc/todo/Specify_maximum_usable_space_per_remote.mdwn b/doc/todo/Specify_maximum_usable_space_per_remote.mdwn
new file mode 100644
index 0000000000..14f9d548b2
--- /dev/null
+++ b/doc/todo/Specify_maximum_usable_space_per_remote.mdwn
@@ -0,0 +1,9 @@
+I would like to be able to limit the amount of space git-annex will use on a remote.
+
+Obviously this would not limit the total amount of space used on whatever filesystem the remote is on, but would only apply to space used within the remote for the particular annex in question.
+
+Many of the cloud storage providers that git-annex supports through special remotes have free tiers. For instance, Google offers 15GB of free storage. If I have an annex with > 15 GB of storage I don't just want to add a Google Drive special remote and start attempting to copy everything over. But it would be great to be able to take advantage of that storage by adding a special remote to the annex and telling git-annex to only use a maximum of 13 GB (to leave myself a 2 GB buffer, in case things get added to the Google Drive through some mechanism outside of the annex). I could then add the remote to a preferred content group like `backup` and do a `git-annex copy --auto gdrive`, which would copy everything to Google Drive, unless transferring the next file would cause the remote to use over 13 GB.
+
+Currently I can see the size of a remote using `git annex info gdrive`, so git-annex appears to have the needed information.
+
+This is sort of like `annex.diskreserve`, but more useful for special remotes where setting an amount of space to keep free is not relevant.
diff --git a/doc/todo/Specify_maximum_usable_space_per_remote/comment_1_fdc0c518b6cbc5dc7e5b64748c2d7b01._comment b/doc/todo/Specify_maximum_usable_space_per_remote/comment_1_fdc0c518b6cbc5dc7e5b64748c2d7b01._comment
new file mode 100644
index 0000000000..1365e932c7
--- /dev/null
+++ b/doc/todo/Specify_maximum_usable_space_per_remote/comment_1_fdc0c518b6cbc5dc7e5b64748c2d7b01._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-05T16:40:56Z"
+ content="""
+This poses difficulties when several different git-annex repositories
+are uploading to the same special remote. They would have to somehow maintain a
+count of the amount of space used on the remote, but the repositories
+could be completely disconnected, other than being able to all access the
+special remote. So, the count would have to be stored on the remote, and
+updated atomically. But, not all remotes support atomic operations well
+enough to support such a distributed counter.
+
+If the storage service has an API call to get the space used, then the
+special remote can use that. I think that such a thing unfortunately can
+only be implemented that way, on a per-special-remote implementation basis.
+"""]]
diff --git a/doc/todo/Specify_maximum_usable_space_per_remote/comment_2_b81af6dac4042c0d4dab58c91a46b09d._comment b/doc/todo/Specify_maximum_usable_space_per_remote/comment_2_b81af6dac4042c0d4dab58c91a46b09d._comment
new file mode 100644
index 0000000000..8fe3597c79
--- /dev/null
+++ b/doc/todo/Specify_maximum_usable_space_per_remote/comment_2_b81af6dac4042c0d4dab58c91a46b09d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="pigmonkey"
+ subject="comment 2"
+ date="2016-09-06T23:10:47Z"
+ content="""
+Is it not possible to implement per-annex?
+
+For instance, take the walkthrough example where you create an annex at `~/annex` and then clone it at `/media/usb/annex`. Take that setup and add a special remote -- say, a Google Drive remote called `annex-gdrive`. Now both `~/annex` and `/media/usb/annex` know which files are stored on the `annex-gdrive` remote. So we go into `~/annex` and set the maximum usable space for `annex-gdrive` and upload a couple files. Then we can go into `/media/usb/annex`, sync, and it will be able to determine the space still available on `annex-gdrive`, not through any special API but just by looking at the size of the files it knows are stored on that special remote.
+
+In the case that we create a brand new annex `~/foo` and add a Google Drive special remote to it `foo-gdrive` that happens to use the same Google account as the `annex-gdrive` remote from the previous annex, I would not expect that new annex to know about the storage used for `annex-gdrive`. That would need some sort of special API from the provider.
+
+I just want the annex `~/annex` to know about the storage used at `annex-gdrive` and the annex `~/foo` to know about the storage used at `foo-gdrive`.
+
+Hope that makes sense!
+"""]]
diff --git a/doc/todo/Specify_maximum_usable_space_per_remote/comment_3_afc7f278c02d7bf9f92a90e51cb5a2a9._comment b/doc/todo/Specify_maximum_usable_space_per_remote/comment_3_afc7f278c02d7bf9f92a90e51cb5a2a9._comment
new file mode 100644
index 0000000000..02ad7ca406
--- /dev/null
+++ b/doc/todo/Specify_maximum_usable_space_per_remote/comment_3_afc7f278c02d7bf9f92a90e51cb5a2a9._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-09-07T15:08:37Z"
+ content="""
+git-annex repositories can all be clones of one another, but not currently
+connected. They can stay disconnected for an arbitrary amount of time,
+up to forever.
+
+For example, /media/usb/annex can be packed up, sent half way around the
+world and used with a different computer, which has no way to communicate
+with its parent ~/annex on the original computer.
+
+So, git-annex has to deal with split-brain and other distributed
+inconsistencies. And it does. However, a keeping count of how much space is
+used on a remote can't be consistent in these kinds of situations, unless,
+as I said, the count is kept in sync using the remote in question, and not
+information in the git-annex repositories.
+"""]]
diff --git a/doc/todo/Specify_maximum_usable_space_per_remote/comment_4_a760351ed7a6d3d232af7c22b2063871._comment b/doc/todo/Specify_maximum_usable_space_per_remote/comment_4_a760351ed7a6d3d232af7c22b2063871._comment
new file mode 100644
index 0000000000..f4af1c867f
--- /dev/null
+++ b/doc/todo/Specify_maximum_usable_space_per_remote/comment_4_a760351ed7a6d3d232af7c22b2063871._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="pigmonkey"
+ subject="comment 4"
+ date="2016-09-07T20:38:35Z"
+ content="""
+That makes sense. Thanks.
+"""]]
diff --git a/doc/todo/Specify_maximum_usable_space_per_remote/comment_5_c5069ffed5e8c4e1d001aedb971aca75._comment b/doc/todo/Specify_maximum_usable_space_per_remote/comment_5_c5069ffed5e8c4e1d001aedb971aca75._comment
new file mode 100644
index 0000000000..f9c24659e7
--- /dev/null
+++ b/doc/todo/Specify_maximum_usable_space_per_remote/comment_5_c5069ffed5e8c4e1d001aedb971aca75._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="Still seems useful"
+ date="2017-03-07T10:19:41Z"
+ content="""
+I dunno. I get your point. However I can also see this being a really useful feature. I can imagine it being implemented simply with a warning / note mentioning disconnected repos might overflow the limit (and perhaps a buffer should be left ie: limit = 15gb, allocate = 13gb). It would be up to the user to figure out what is right for them.
+
+I'm sure plenty of people either using the remote alone, in a small team, or with linked up repos (github/gitlab/whatever) would appreciate this option. I know I came to this page looking to see if it was possible already. :)
+
+Thanks too for the hard work! Amazing software!
+"""]]
diff --git a/doc/todo/Specify_maximum_usable_space_per_remote/comment_6_bef44c8f571f2be177d6ee949c721a6a._comment b/doc/todo/Specify_maximum_usable_space_per_remote/comment_6_bef44c8f571f2be177d6ee949c721a6a._comment
new file mode 100644
index 0000000000..dc3faefeb5
--- /dev/null
+++ b/doc/todo/Specify_maximum_usable_space_per_remote/comment_6_bef44c8f571f2be177d6ee949c721a6a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="Still useful"
+ date="2022-06-25T16:36:38Z"
+ content="""
+Implementing a hard limit concurrently isn't feasible but only providing a best-effort target size would still be useful.
+
+It should fully work in all non-concurrent use-cases which are the majority in my case.
+
+This would also open up the possibility of allowing me to know which drive I need to plug in when there is new data to be backed up because git-annex would know how much a repo is able to store and how much it currently holds.  
+This obviously isn't perfect either (there might be other data on that drive; other annex repos or entirely untracked data for example) but it'd still be good enough to make a manual decision on for me.
+"""]]
diff --git a/doc/todo/Speed_up___39__import_--clean-duplicates__39__.mdwn b/doc/todo/Speed_up___39__import_--clean-duplicates__39__.mdwn
new file mode 100644
index 0000000000..34c21ab01c
--- /dev/null
+++ b/doc/todo/Speed_up___39__import_--clean-duplicates__39__.mdwn
@@ -0,0 +1,7 @@
+I'm currently in the process of gutting old (some broken) git-annex's and cleaning out download directories from before I started using git-annex.
+
+To do this, I am running `git annex import --clean--duplicates $PATH` on the directories I want to clear out but sometimes, this takes a unnecessarily long time.
+
+For example, git-annex will calculate the digest for a huge file (30GB+) in $TARGET, even though there are no files in the annex of that size.
+
+It's a common shortcut to check for duplicate sizes first to eliminate definite non-matches really quickly. Can this be added to git-annex's `import` in some way or is this a no-go due to the constant memory constraint?
diff --git a/doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_1_9268c639d3d21cce4ca7b60d08e9cb65._comment b/doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_1_9268c639d3d21cce4ca7b60d08e9cb65._comment
new file mode 100644
index 0000000000..8584d5ae8c
--- /dev/null
+++ b/doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_1_9268c639d3d21cce4ca7b60d08e9cb65._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="interesting idea"
+ date="2014-07-30T15:03:46Z"
+ content="""
+This could be done in constant space using a bloom filter of known file sizes. Files with wrong sizes would sometimes match, but no problem, it would then just do the work it does now.
+
+However, to build such a filter, git-annex would need to do a scan of all keys it knows about. This would take approximately as long to run as `git annex unused` does. It might make sense to only build the filter if it runs into a fairly large file. Alternatively, a bloom filter of file sizes could be cached and updated on the fly as things change (but this gets pretty complex).
+"""]]
diff --git a/doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_2_9c6688901ef20badd834419202627d5c._comment b/doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_2_9c6688901ef20badd834419202627d5c._comment
new file mode 100644
index 0000000000..e372b405e3
--- /dev/null
+++ b/doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_2_9c6688901ef20badd834419202627d5c._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="Xyem"
+ ip="81.111.193.130"
+ subject="comment 2"
+ date="2014-08-01T09:05:45Z"
+ content="""
+Could be tested out with an additional flag `--with-size-bloom` on import?
+
+It would then build a bloom (and use a cached one with --fast) and do the usual import.
+
+So I could do this:
+
+    # Bloom is created and the import is done using it
+    git annex import --clean-duplicates --with-size-bloom $TARGET
+
+    # Previously created bloom is used
+    git annex import --clean-duplicates --with-size-bloom --fast $TARGET2
+    git annex import --clean-duplicates --with-size-bloom --fast $TARGET3
+
+I can implement this behaviour in Perl with Bloom::Filter and let you know how it performs if that would be useful to you..?
+"""]]
diff --git a/doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_3_b53f2e881af1426adb0f45e2b11e4be6._comment b/doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_3_b53f2e881af1426adb0f45e2b11e4be6._comment
new file mode 100644
index 0000000000..3454d80574
--- /dev/null
+++ b/doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_3_b53f2e881af1426adb0f45e2b11e4be6._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-06-23T16:47:29Z"
+ content="""
+`git-annex import --from remote` has recently been sped up a lot,
+and the plan is to [[todo/remove_legacy_import_directory_interface]]
+in favor of it or reimplement the lecacy interface on top of it.
+
+Using `git-annex import --from remote --fast`, when there's a huge file in
+the directory remote, will hash it, but only once. On subsequent runs it
+will recognise the file it has seen before.
+
+So all that's needed to emulate --clean-duplicates is a way to do this:
+
+	git-annex move --from remote --copies 2
+
+Which doesn't work currently, but see [[drop_from_export_remote]].
+"""]]
diff --git a/doc/todo/Split_autocommit_option.mdwn b/doc/todo/Split_autocommit_option.mdwn
new file mode 100644
index 0000000000..76b611f25a
--- /dev/null
+++ b/doc/todo/Split_autocommit_option.mdwn
@@ -0,0 +1,20 @@
+Follow-up to https://git-annex.branchable.com/forum/Use_assistant_to_sync_just_git_repos__63__/#comment-88286ff5bb273eda1d731ac91197cb37
+
+Currently, the annex.autocommit controls 3 things:
+
+1. assistant automatically committing
+2. assistant automatically syncing committs to other repos
+3. sync committing when invoked
+
+As of ff6b36c706efe1a63f121e57e45776f5f6628163 it no longer affects 2\. but that also means there's no way to control 2\. :/
+
+The autocommit option should only configure whether the assistant automatically adds and commits new files and changes. Perhaps it should be namespaced to make its function more obvious: `annex.assistant.autocommit`
+
+Additionally, there should be two more options to control the other two. `annex.assistant.autosync` and `annex.sync.commit` perhaps.
+
+Making the new options namespaced would also allow the old option to retain its current function; enabling all three.
+
+I've got multiple use-cases for git-annex where I cannot use the assistant because these finer-grained options don't exist.
+
+> Closing because remote.name.annex-sync seems to be sufficient. [[done]]
+> --[[Joey]] 
diff --git a/doc/todo/Split_autocommit_option/comment_1_fc127bc73c650404df4f21c9a04b3dd4._comment b/doc/todo/Split_autocommit_option/comment_1_fc127bc73c650404df4f21c9a04b3dd4._comment
new file mode 100644
index 0000000000..f4862bed16
--- /dev/null
+++ b/doc/todo/Split_autocommit_option/comment_1_fc127bc73c650404df4f21c9a04b3dd4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-04-04T16:10:21Z"
+ content="""
+remote.name.annex-sync controls #2
+
+I don't think it makes sense for different git-annex commands that do
+substantially the same thing to have different options to control that
+thing. So I do not see why annex.autocommit should not be used by both the
+assistant and git-annex sync. If you need to run one command with the
+option set and another with the option unset, there are ways to do that, eg
+a shell script or git alias.
+"""]]
diff --git a/doc/todo/Store_git_pack_files_on_special_remotes.mdwn b/doc/todo/Store_git_pack_files_on_special_remotes.mdwn
new file mode 100644
index 0000000000..0a9938c04a
--- /dev/null
+++ b/doc/todo/Store_git_pack_files_on_special_remotes.mdwn
@@ -0,0 +1,5 @@
+It would be nice to be able to upload and download git history with special remotes.  This could be a move towards full special remote syncing.
+
+> I feel this is out of scope. git has its own interface to let a program
+> be registered as performing a transport, to store a git repository
+> anywhere. [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/Straight-forward_diffing_with___39__git_annex_diff__39__.mdwn b/doc/todo/Straight-forward_diffing_with___39__git_annex_diff__39__.mdwn
new file mode 100644
index 0000000000..243697db7a
--- /dev/null
+++ b/doc/todo/Straight-forward_diffing_with___39__git_annex_diff__39__.mdwn
@@ -0,0 +1,29 @@
+Hi joey,
+
+Currently, getting a useful diff between annexed file versions is quite involved [(setting up git-annex diffdriver)](https://git-annex.branchable.com/forum/git-like_git-annex_diff/).
+
+It would be very nice if showing changes between annexed files was a little more straight-forward and ideally without any user config needed. UI suggestions:
+
+- `git annex diff`: would behave exactly like `git diff`, but operatign on both unannexed and annexed contents 
+  - ideally re-implementing all its options (e.g. `--word-diff`, `--word-diff-regex`, etc.)
+  - would need a diff implementation in Haskell (surely there is one)
+  - sounds complicated to do TBH
+- Teaching `git diff` to use the annexed content instead of the pointer links/files
+  - software like [`nbstripout`](https://github.com/kynan/nbstripout) passes the git-tracked contents through a filter before diffing. This sounds like git-annex could do the same to add straight-forward `git diff` support without user configuration.
+  - git-annex already has a `*  filter=annex` attribute in place, for text diffing there apparently needs to be a `*  diff=annex` attribute and a `[diff "annex"] textconv=git-annex-output-content-instead-of-pointer` config.
+  - even if the above works, I don't know how to temporarily switch this off without uncommenting the `textconv` e.g. with `git config --edit`. Sometimes you just want to see the actual hashes of old and new file.
+
+Maybe `git annex diffdriver` kind of does part of this, but I don't really understand what it actually does.
+
+Here other posts related to diffing:
+
+- https://git-annex.branchable.com/forum/enabling_git-annex-diffdriver_for_gitk/
+- https://git-annex.branchable.com/todo/--get_option_for_diffdriver/
+
+What do you think?
+
+Cheers, Yann
+
+PS: Thank you very much for git-annex, it's awesome! I'm giving a git-annex workshop next weekend [@Tuebix](https://cfp.tuebix.org/tuebix-2023/talk/review/GWRP3UKE3VFKVDG8RNQ8ZZPCZPNZYYWM), really looking forward to it.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/Straight-forward_diffing_with___39__git_annex_diff__39__/comment_1_2f5ea091b7f6defa397d15055d04a67d._comment b/doc/todo/Straight-forward_diffing_with___39__git_annex_diff__39__/comment_1_2f5ea091b7f6defa397d15055d04a67d._comment
new file mode 100644
index 0000000000..618195c7c7
--- /dev/null
+++ b/doc/todo/Straight-forward_diffing_with___39__git_annex_diff__39__/comment_1_2f5ea091b7f6defa397d15055d04a67d._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-06-28T17:43:19Z"
+ content="""
+This works:
+
+	echo * diff=text >>.gitattributes
+	git config diff.text.command "git-annex diffdriver -- sh -c 'echo diff a/\$0 b/\$0; echo \$0; diff -u \$1 \$4 || true' --"
+
+Unfortunatly, the textconv approach will not work for locked files, because
+git does not apply the textconv to symlinks. It could be made to work for
+unlocked files but the above works for all annexed files.
+
+diffing like this is only useful on text files, and most annexed files
+are not text files. That's why the diffdriver command focuses on using some
+external diff driver that knows how to diff whatever type of binary file is
+being stored in git-annex. So this should certianly not be enabled by
+default. It makes sense to enable it in .gitattributes when you have
+annexed some textual files.
+
+That command is a bit hard to come up with, with the complex shell quoting.
+So rather than try to document it, I made an easier way to do the same
+thing:
+
+	echo * diff=text >>.gitattributes
+	git config diff.text.command "git annex diffdriver --text"
+"""]]
diff --git a/doc/todo/Straight-forward_diffing_with___39__git_annex_diff__39__/comment_2_cae9e0be287bd42498caf1f61c518f0e._comment b/doc/todo/Straight-forward_diffing_with___39__git_annex_diff__39__/comment_2_cae9e0be287bd42498caf1f61c518f0e._comment
new file mode 100644
index 0000000000..286e43b453
--- /dev/null
+++ b/doc/todo/Straight-forward_diffing_with___39__git_annex_diff__39__/comment_2_cae9e0be287bd42498caf1f61c518f0e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Awesome, thanks!"
+ date="2023-06-28T21:09:50Z"
+ content="""
+Awesome, thanks joey!
+"""]]
diff --git a/doc/todo/Usability_improvements_for_new_users.mdwn b/doc/todo/Usability_improvements_for_new_users.mdwn
new file mode 100644
index 0000000000..6fad95e82d
--- /dev/null
+++ b/doc/todo/Usability_improvements_for_new_users.mdwn
@@ -0,0 +1,21 @@
+Hi there,
+
+I'm a relatively new to `git-annex` and quite impressed so far.
+
+I've found the command to be somewhat less self-documenting than I'd like it to be for a new user.
+Particularly, since it's a `git` subcommand, I'd wish for annex to 'mirror' as many subcommands as possible
+with `annex`-enabled equivalents. My chief complaint at the moment is that it is a bit hard to remember the
+specific commands for showing remotes (`git annex info` has no equivalent `git info`) and `git annex remote`
+should ideally return a list of remotes for parallelism.
+
+Similarly, it'd be nice if some of the commands were a bit nested to match `git` semantics. This would increase discoverability:
+For instance, `git annex enableremote` -> `git annex remote enable` or `git annex renameremote -> git annex remote rename`. Then subcommands for dealing with remotes
+could be more easily summarized on a single page in the `git-annex-remote` section.
+
+It's worth noting that such changes could happen alongside the current commands without a loss of functionality. Git core
+has recently gone through a similar process to simplify the semantics of some of its commands. I'd ask for such changes to be considered.
+
+Daven
+
+> [[wontfix|done]] at least for the listed things, for reasons explained
+> in my comment below. --[[Joey]]
diff --git a/doc/todo/Usability_improvements_for_new_users/comment_1_70ecef547308f9b049bd67f3d2f14117._comment b/doc/todo/Usability_improvements_for_new_users/comment_1_70ecef547308f9b049bd67f3d2f14117._comment
new file mode 100644
index 0000000000..096e25a0cf
--- /dev/null
+++ b/doc/todo/Usability_improvements_for_new_users/comment_1_70ecef547308f9b049bd67f3d2f14117._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-01-16T17:16:54Z"
+ content="""
+> `git annex info` has no equivalent `git info`
+
+git-annex can't be limited to commands that happen to have equivilant git
+commands. `git annex drop` also has no equivilant in git, but is
+fundamental to git-annex.
+
+If you're thinking of `git annex info` as equivilant to `git remote` in 
+listing remotes, that does not consider everything the info command does.
+
+> git annex remote should ideally return a list of remotes for parallelism
+
+`git remote` lists all remotes including git-annex special remotes,
+so `git annex remote` would be unnecessary duplication.
+
+> git annex renameremote -> git annex remote rename
+
+This would encourage drawing a false equivilance with `git remote rename`.
+
+I'm also not convinced that stacking subcommands 3 levels deep is a good
+idea. The user has to dig through every level to find something then.
+
+There's also an intentional similarity in naming between `git annex init`
+and `git annex initremote`, which I think makes sense and helps users
+learn and remember the latter command after having first learned the former. 
+And `enableremote` and `renameremote` then flow naturally from that.
+This is, IMHO, a more natural learning flow than searching for strained
+equivilances to `git remote` commands.
+
+I do think that `git annex add` has a very good reason to parallel `git
+add`, and if there are other git-annnex commands that could directly
+parallel a git command like that and don't, that would be worth addressing.
+"""]]
diff --git a/doc/todo/Usability_improvements_for_new_users/comment_2_ea77f0894802a17854aeedeceababf8a._comment b/doc/todo/Usability_improvements_for_new_users/comment_2_ea77f0894802a17854aeedeceababf8a._comment
new file mode 100644
index 0000000000..d7c2398dd7
--- /dev/null
+++ b/doc/todo/Usability_improvements_for_new_users/comment_2_ea77f0894802a17854aeedeceababf8a._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="daven.quinn@d0ed4e0e5e4462d9a74a5d5a8fbd1b17f85db13e"
+ nickname="daven.quinn"
+ avatar="http://cdn.libravatar.org/avatar/4811a26fff610f0c9668d183481a7158"
+ subject="comment 1 response"
+ date="2023-01-16T21:45:35Z"
+ content="""
+Fair enough, I suppose. However, I think that feedback from early-stage users should be weighted highly, as we interact with \"onboarding\"/\"discoverability\" problems that eventually fade from being users' primary impediments to use.
+
+> git-annex can't be limited to commands that happen to have equivalant git commands.
+
+I'm not suggesting that all commands should have `git` equivalents. Instead, when a commonly used equivalent (or close relative) is available, the name should be mirrored to increase discoverability of common idioms.
+
+
+> This would encourage drawing a false equivilance with git remote rename.
+
+I'm not quite sure why the equivalence would be false — yes, the commands do somewhat different things. But they both fundamentally rename a remote.
+
+> searching for strained equivilances to git remote commands.
+
+Again, I am not sure the equivalences are so strained. Users should not (and I think broadly won't) expect a git-annex subcommand to do exactly the same thing as a git equivalent. But semantic-level parallelism with git top-level commands, and adopting git's pattern of grouping like functionality into subcommands, could greatly improve discoverability. As it stands, the goals of *preventing confusion between similarly named functionality* and *allowing functionality to be easily found* are in tension. 
+
+Another way to frame my suggestion is to consider the layout of the `git-annex` command line help output. Right now, when seeking assistance, the user is presented with a long list of commands and has to hunt for related functionality (`renameremote`, `enableremote`, etc.) within it. In contrast, when I type `git remote --help`, I see all of the commands for managing remotes in a single, shorter output. It is another nesting level, true, but I think a help page entry of `remote - manages git-annex special remotes` would be easier to parse than the current output.
+
+Anyway, I appreciate your work on this system and consideration of user feedback.
+
+Regards,
+Daven
+"""]]
diff --git a/doc/todo/Use_MediaScannerConnection_on_Android.mdwn b/doc/todo/Use_MediaScannerConnection_on_Android.mdwn
new file mode 100644
index 0000000000..afce9308d3
--- /dev/null
+++ b/doc/todo/Use_MediaScannerConnection_on_Android.mdwn
@@ -0,0 +1,7 @@
+Currently if photos or videos are copied into the Camera/DCIM directory on an Android device, or deleted the Gallery doesn't notice the changes.
+
+It is necessary to call MediaScannerConnection - http://developer.android.com/reference/android/media/MediaScannerConnection.html - to notify the system of the change.
+
+More info, and some sample Java code: http://stackoverflow.com/questions/13270789/how-to-run-media-scanner-in-android
+
+It'd be awesome if the assistant did this on files it has changed.  Possibly just under Camera/DCIM, but perhaps it should be configurable. MediaScannerConnection is also used to notify and index new music files.
diff --git a/doc/todo/Use_a_remote_as_a_sharing_site_for_files_with_obfuscated_URLs.mdwn b/doc/todo/Use_a_remote_as_a_sharing_site_for_files_with_obfuscated_URLs.mdwn
new file mode 100644
index 0000000000..a42a81d02b
--- /dev/null
+++ b/doc/todo/Use_a_remote_as_a_sharing_site_for_files_with_obfuscated_URLs.mdwn
@@ -0,0 +1,7 @@
+There are times when it is handy to be able to upload a file to a web host somewhere and share a link for that file to a select few people.
+
+It seems to be that the assistant could handle this scenario. It could generate a directory with a random name on the remote, and transfer the file there (using the existing filename) and the appropriate URL could be displayed in the assistant webapp to allow the user to copy the URL to send it to the appropriate people.
+
+Note: Joey and I had a quick chat about this use case at LCA2013.
+
+[[!tag design/assistant]]
diff --git a/doc/todo/Use_a_remote_as_a_sharing_site_for_files_with_obfuscated_URLs/comment_1_1a1f34f4f389267d67e79409c0ca8b1d._comment b/doc/todo/Use_a_remote_as_a_sharing_site_for_files_with_obfuscated_URLs/comment_1_1a1f34f4f389267d67e79409c0ca8b1d._comment
new file mode 100644
index 0000000000..35f7351915
--- /dev/null
+++ b/doc/todo/Use_a_remote_as_a_sharing_site_for_files_with_obfuscated_URLs/comment_1_1a1f34f4f389267d67e79409c0ca8b1d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 1"
+ date="2013-02-09T22:38:56Z"
+ content="""
+This would be an extremely cool feature to rip off from Dropbox. :)
+
+"""]]
diff --git a/doc/todo/Use_a_remote_as_a_sharing_site_for_files_with_obfuscated_URLs/comment_2_735afa6f87a93cdf333c17da32010620._comment b/doc/todo/Use_a_remote_as_a_sharing_site_for_files_with_obfuscated_URLs/comment_2_735afa6f87a93cdf333c17da32010620._comment
new file mode 100644
index 0000000000..b2e6c0dace
--- /dev/null
+++ b/doc/todo/Use_a_remote_as_a_sharing_site_for_files_with_obfuscated_URLs/comment_2_735afa6f87a93cdf333c17da32010620._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="2001:1928:1:9::1"
+ subject="comment 2"
+ date="2014-04-07T04:35:39Z"
+ content="""
+i wonder if the assistant or the new daemon couldn't do this job as well... -- [[anarcat]]
+"""]]
diff --git a/doc/todo/Use_editorconfig_for_formatting_rules.mdwn b/doc/todo/Use_editorconfig_for_formatting_rules.mdwn
new file mode 100644
index 0000000000..06bb32080c
--- /dev/null
+++ b/doc/todo/Use_editorconfig_for_formatting_rules.mdwn
@@ -0,0 +1,3 @@
+https://editorconfig.org/ is a cross-editor standard for setting formatting rules like indent etc.
+
+A blurb of elisp probably isn't too useful to vim users and I had some really strange memory leak with it in my Emacs.
diff --git a/doc/todo/Use_editorconfig_for_formatting_rules/comment_1_20e6d6467dcc9e4814c657355a7f2e74._comment b/doc/todo/Use_editorconfig_for_formatting_rules/comment_1_20e6d6467dcc9e4814c657355a7f2e74._comment
new file mode 100644
index 0000000000..0d73fe2a17
--- /dev/null
+++ b/doc/todo/Use_editorconfig_for_formatting_rules/comment_1_20e6d6467dcc9e4814c657355a7f2e74._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-05-10T14:41:53Z"
+ content="""
+I guess you're talking about the elisp in [[coding_style]].
+
+editorconfig looks reasonable though pretty limited in what it can do. 
+I like that plugins are included in Debian. If you want to develop
+an editorconfig file we can add it to git-annex.
+"""]]
diff --git a/doc/todo/View_for_old_versions_of_a_file.mdwn b/doc/todo/View_for_old_versions_of_a_file.mdwn
new file mode 100644
index 0000000000..2d7df8246e
--- /dev/null
+++ b/doc/todo/View_for_old_versions_of_a_file.mdwn
@@ -0,0 +1,24 @@
+Hey joey,
+
+I often find myself wanting to compare older versions of files (plots, images, etc...) and currently browse the git history and copy-paste paths to the old files in the `.git/annex/objects` to open them or launch a diffing program. This works, but is quite tedious.
+
+I see there is [`git annex diffdriver`](https://git-annex.branchable.com/git-annex-diffdriver/), but haven't tried it yet.
+
+Wouldn't a **view showing old versions of files** be nice? I haven't thought this through fully, but I think this could be implemented similar to the `/=foo` or `/foo=bar` original path filtering logic by introducing a new virtual metadata field (maybe `:`? or `^` like ”anchor”/”history”? 🤔 Aren't that many ASCII characters without special shell meaning left that aren't allowed in a field name... 😅) where old versions of files get assigned that `^` field with their own path or filename and the view would just use the filename as folder level like any other field. 
+
+Or a `git annex view --historical` could be added that allows for scanning the entire history (or up to a certain reach into the past) to include old files as well and adds a git commit identifier to the filename to avoid conflicts.
+
+
+[[!format  bash """
+# show all versions of files tagged with 'plot' in the foo directory
+git annex view --historical tag=plot /=foo
+# This would then make a folder structure like
+"""]]
+
+Not only would this facilitate easy history browsing, but also a more visual way of (force) dropping old content selectively - especially with graphical tools like my Thunar plugin (switch into historical view, select and right-click unneeded files, drop).
+
+What do you think?
+
+Thanks again for git-annex, It's amazing! 🥳
+
+Yann 
diff --git a/doc/todo/View_for_old_versions_of_a_file/comment_1_8e233fd006bd8f16533df63579f02fb1._comment b/doc/todo/View_for_old_versions_of_a_file/comment_1_8e233fd006bd8f16533df63579f02fb1._comment
new file mode 100644
index 0000000000..147279255a
--- /dev/null
+++ b/doc/todo/View_for_old_versions_of_a_file/comment_1_8e233fd006bd8f16533df63579f02fb1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-02-23T18:43:07Z"
+ content="""
+I don't think this would necessarily be an easy or fast branch to
+construct.
+
+And of course `git checkout` of a commit that contains an old version of a
+file is a standard way to look at the old version of a file when using git,
+and works with git-annex..
+"""]]
diff --git a/doc/todo/View_for_old_versions_of_a_file/comment_2_9b1c6f41f77ec6ba9c90a5e9ec088647._comment b/doc/todo/View_for_old_versions_of_a_file/comment_2_9b1c6f41f77ec6ba9c90a5e9ec088647._comment
new file mode 100644
index 0000000000..c34f16dde0
--- /dev/null
+++ b/doc/todo/View_for_old_versions_of_a_file/comment_2_9b1c6f41f77ec6ba9c90a5e9ec088647._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2023-02-23T22:59:49Z"
+ content="""
+Yes, probably it would be slower as it has to browse the history. `git checkout` works, sure, but it doesn't help if you want to have all old versions of a file in a directory for comparison. Is there git magic (something in the direction of worktree?) to do that? Or can git-annex produce a list of paths to all versions of an annexed file? Then a script could be written to make a poor-mans-`view --historical` manually. I guess one could manually parse `git log -p` or `git diff --name-only` somehow, but I have a feeling that this gets ugly fast...
+"""]]
diff --git a/doc/todo/When_autostarting_the_assistant_on_boot_delay_the_execution_2min.mdwn b/doc/todo/When_autostarting_the_assistant_on_boot_delay_the_execution_2min.mdwn
new file mode 100644
index 0000000000..88df27a2a3
--- /dev/null
+++ b/doc/todo/When_autostarting_the_assistant_on_boot_delay_the_execution_2min.mdwn
@@ -0,0 +1,36 @@
+I think the assistant should have a delay before starting so it doesn't impact on the system boot performance.
+
+I know this can be configured per user (I have it set to 5min), but I think 2min is a sane default.
+
+I don't really know how to submit patches (I can't attach it), so I simply copy it here. It's trivial enough.
+
+[[!format txt """
+From bc6b90ce333659bd2511eedd4ab9067241f73780 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Jon=20Ander=20Pe=C3=B1alba?= <jonander.penalba@gmail.com>
+Date: Wed, 28 Oct 2015 12:00:51 +0100
+Subject: [PATCH] When autostarting the assistant on boot delay the execution
+ 2min
+
+---
+ Assistant/Install/AutoStart.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Assistant/Install/AutoStart.hs b/Assistant/Install/AutoStart.hs
+index 5745030..6a09c3a 100644
+--- a/Assistant/Install/AutoStart.hs
++++ b/Assistant/Install/AutoStart.hs
+@@ -35,6 +35,6 @@ fdoAutostart command = genDesktopEntry
+ 	"Git Annex Assistant"
+ 	"Autostart"
+ 	False
+-	(command ++ " assistant --autostart")
++	(command ++ " assistant --autostart --startdelay=120")
+ 	Nothing
+ 	[]
+-- 
+2.6.2
+
+
+"""]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/When_autostarting_the_assistant_on_boot_delay_the_execution_2min/comment_1_49990eaf4a3d6ee89f668dfc159f5eae._comment b/doc/todo/When_autostarting_the_assistant_on_boot_delay_the_execution_2min/comment_1_49990eaf4a3d6ee89f668dfc159f5eae._comment
new file mode 100644
index 0000000000..129eeac977
--- /dev/null
+++ b/doc/todo/When_autostarting_the_assistant_on_boot_delay_the_execution_2min/comment_1_49990eaf4a3d6ee89f668dfc159f5eae._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-11-02T15:14:20Z"
+ content="""
+There's actually an undocumented default startdelay of 5 seconds when using
+autostart. I've now documented it.
+
+Maybe 5 seconds is too little. OTOH, 2 minutes may be a bit too much;
+if the user is booting up their computer to access a new file in their
+annex they'd expect it to start syncing ASAP.
+
+I think my justification for the 5 seconds default was that about how long
+it seems to take a typical desktop system to get loaded (after the login
+screen) and for the user to open a web browser, on reasonably modern
+hardware. Even windows in an emulator doesn't take much longer than that.
+"""]]
diff --git a/doc/todo/Wishlist__58___Parity_files_on_all_files.mdwn b/doc/todo/Wishlist__58___Parity_files_on_all_files.mdwn
new file mode 100644
index 0000000000..7e6d44aecd
--- /dev/null
+++ b/doc/todo/Wishlist__58___Parity_files_on_all_files.mdwn
@@ -0,0 +1,67 @@
+To make sure we can archive our data safely, we need to:
+
+- Store revisions
+- Allow files to be tracked while moved to archival spaces
+- Be platform-agnostic
+- Sync
+- Protect against bit-rot
+
+
+1 and 3 are handled by git itself; everything is a straight forward graph-structure comprised of plain text pointers *(accepting that some filesystems do not easily expose file metadata, but that's on them as we can simply chose to use a different system if that's important)
+
+2 and 4 seem to be handled by git-annex
+
+**But 5 is missing.**
+
+
+Thankfully, we already have a technology that can fill in elegantly here: parity files.
+
+
+### 2 potential user stories:
+
+#### Put everything together
+
+- This user wants everything together and in the filesystem in case one of the tools she relies on disappears.
+- Might have a structure like this:
+   - Project
+     - documents
+       - contract.pdf
+       - contract.pdf.vol000+01.par2
+       - contract.pdf.vol001+02.par2
+       - contract.pdf.vol003+04.par2
+       - Client brochure.zip
+       - Client brochure.zip.vol000+01.par2
+       - Client brochure.zip.vol001+02.par2
+       - Client brochure.zip.vol003+04.par2
+
+- Or like this:
+   - Project
+     - documents
+       - contract.pdf
+       - Client brochure.zip
+     - documents.vol000+01.par2
+     - documents.vol001+02.par2
+     - documents.vol003+04.par2
+
+
+
+#### Keep everything clean
+
+- This user doesn't want to clutter folders with extra files. He would rather only have the data files themselves in case they need to be zipped and sent to clients. If he had setup 1, he would delete *.par before zipping, leading to potential data loss.
+- Might have a structure like this:
+   - Project
+     - documents
+       - contract.pdf
+       - Client brochure.zip
+   - [git-annex]
+       - contract.pdf.vol000+01.par2
+       - contract.pdf.vol001+02.par2
+       - contract.pdf.vol003+04.par2
+       - Client brochure.zip.vol000+01.par2
+       - Client brochure.zip.vol001+02.par2
+       - Client brochure.zip.vol003+04.par2
+
+
+This would also enhance the data-checking capabilities of git-annex, as data loss could be fixed and new parity files generated from the recovered files transparently, self-healing the archive.
+
+[[!tag unlikely]]
diff --git a/doc/todo/Wishlist__58___Parity_files_on_all_files/comment_1_3900fa7c3ed1455fe07d097c3dc0c9f2._comment b/doc/todo/Wishlist__58___Parity_files_on_all_files/comment_1_3900fa7c3ed1455fe07d097c3dc0c9f2._comment
new file mode 100644
index 0000000000..86b1111d96
--- /dev/null
+++ b/doc/todo/Wishlist__58___Parity_files_on_all_files/comment_1_3900fa7c3ed1455fe07d097c3dc0c9f2._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-01-31T16:55:27Z"
+ content="""
+git repositories don't contain parity files for their data. Instead, git
+relies on multiple copies of the repository to keep things safe. Not as
+efficient as parity files, but a lot easier, and protects against many more
+disasters than do parity files. git-annex takes the same approach.
+Lots Of Copies Keeps Stuff Safe.
+
+Even if git-annex started generating parity files for its objects,
+the git repository would still not have them, so bit flips could still
+corrupt your git-annex repository.
+
+Nothing stops you from writing git hooks that maintain parity files
+alongside all the files in a git repository. If you do that, you'll get
+parity files for the git-annex files too. But I don't see this being needed
+in git-annex itself and AFAICS there are plenty of hooks in git and
+git-annex to allow doing that.
+"""]]
diff --git a/doc/todo/Wishlist__58___Parity_files_on_all_files/comment_2_60dc7823a1814af18861b459a9b3cd0e._comment b/doc/todo/Wishlist__58___Parity_files_on_all_files/comment_2_60dc7823a1814af18861b459a9b3cd0e._comment
new file mode 100644
index 0000000000..637e4a5b3f
--- /dev/null
+++ b/doc/todo/Wishlist__58___Parity_files_on_all_files/comment_2_60dc7823a1814af18861b459a9b3cd0e._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joshfindit"
+ avatar="http://cdn.libravatar.org/avatar/180f1a763647bfc099e97ac88b8f7b37"
+ subject="comment 2"
+ date="2017-02-04T16:24:32Z"
+ content="""
+Unless I'm not understanding correctly, Git and git-annex have different expected use-cases.
+
+With Git, it assumed that you will have a repository for each contained project, and keep the number of files small for easy replication across devices (which leads to multiple copies)
+With git-annex, it's possible (and seems more convenient for setup/clients) to have a monolithic repository where parts of it are replicated to devices.
+Yes, it's best practice to have multiple complete copies, but as the repository grows to 4TB, 12TB, or more, it's much less likely especially for a 'I guess I'm not a casual user any more' user who has simply been purchasing hard drives and maybe a NAS when needed.
+
+
+Certainly, I'm just being selfish: git-annex looks like an excellent answer to my ongoing question of 'how could I do files better', and this suggestion is squarely aimed at my personal wishlist. If checking integrity and self-healing large-file repositories doesn't interest anyone else then I'll look in to rolling my own solution to share.
+In the meantime; which git-annex hooks do you suggest I look at? (Bonus points if you can share the high-level logic that would make this work)
+"""]]
diff --git a/doc/todo/Wishlist__58___Parity_files_on_all_files/comment_3_d69eba0afc48c49bdcd7f1f6a7716bbb._comment b/doc/todo/Wishlist__58___Parity_files_on_all_files/comment_3_d69eba0afc48c49bdcd7f1f6a7716bbb._comment
new file mode 100644
index 0000000000..06d9ed17a2
--- /dev/null
+++ b/doc/todo/Wishlist__58___Parity_files_on_all_files/comment_3_d69eba0afc48c49bdcd7f1f6a7716bbb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 3"
+ date="2017-02-05T02:20:31Z"
+ content="""
+I've wanted parity files in git-annex for a really long time, but never asked about it because I expected the response it got :P
+
+So there are other people interested in this!
+"""]]
diff --git a/doc/todo/Wishlist__58___Parity_files_on_all_files/comment_4_01c382342237e4713ab32a3e95497926._comment b/doc/todo/Wishlist__58___Parity_files_on_all_files/comment_4_01c382342237e4713ab32a3e95497926._comment
new file mode 100644
index 0000000000..0a341158dc
--- /dev/null
+++ b/doc/todo/Wishlist__58___Parity_files_on_all_files/comment_4_01c382342237e4713ab32a3e95497926._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-02-07T17:02:03Z"
+ content="""
+The post-update-annex hook is run whenever the git-annex branch changes,
+so any change to the annexed files stored in the repository will be
+followed by this hook running.
+
+But then how would that hook figure out which content files have been added,
+in order to add parity files for them? Well, someone else had a similar
+type of redundancy information they wanted to add, see
+[[Log_function_to_enumerate_all_recent_git-annex_changes]] for a thread
+about it.
+"""]]
diff --git a/doc/todo/Wishlist__58___additional_environment_variables_for_hooks.mdwn b/doc/todo/Wishlist__58___additional_environment_variables_for_hooks.mdwn
new file mode 100644
index 0000000000..720db90099
--- /dev/null
+++ b/doc/todo/Wishlist__58___additional_environment_variables_for_hooks.mdwn
@@ -0,0 +1,19 @@
+It would be nice if a couple of additional environment variables to be set for hook uses.
+
+In particular:
+
+    GIT_ANNEX_DIRECT=`git config annex.direct`
+
+and
+
+    GIT_TOP_LEVEL=`git rev-parse --show-toplevel`
+
+
+I've made some changes to flickrannex to allow the sub-directories above the uploaded image to be added as tags.  This change has been merged into trunk: [[https://github.com/TobiasTheViking/flickrannex]]
+
+What I needed was both the environment variables mentioned above.  One is set as part of the annex-hook and the other I guestimate from the file path.  If it was set in git-annex it would be much cleaner (and accurate).  So...I think this info would be useful for other hook.
+
+> I think this was referring to the old hook special remote. External
+> special remotes have supplanted that. And when using an external special
+> remote you can query for such data once when starting your special remote
+> program, so no need for git-annex to do it. [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/Wishlist__58___additional_environment_variables_for_hooks/comment_1_d82cbbb478a81a651fbe6cb8b71c1192._comment b/doc/todo/Wishlist__58___additional_environment_variables_for_hooks/comment_1_d82cbbb478a81a651fbe6cb8b71c1192._comment
new file mode 100644
index 0000000000..4d0409d58e
--- /dev/null
+++ b/doc/todo/Wishlist__58___additional_environment_variables_for_hooks/comment_1_d82cbbb478a81a651fbe6cb8b71c1192._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.154"
+ subject="comment 1"
+ date="2014-03-18T19:36:08Z"
+ content="""
+Is this still relevant?
+"""]]
diff --git a/doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant.mdwn b/doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant.mdwn
new file mode 100644
index 0000000000..972247c840
--- /dev/null
+++ b/doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant.mdwn
@@ -0,0 +1,3 @@
+Auto-repair takes up a lot of computing power, greatly slowing down the machine. It also still happens very often here, several times a month on different hardware, leading it to become an annoyance (and it would be easier and faster to perform manual repairs if that should be required).
+
+Therefore I'd like a setting that makes the assistant not attempt to repair on its own. Either not do anything at all, or display a message about it instead.
diff --git a/doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant/comment_1_3274820a0d1f10c505f15cd29a37b95a._comment b/doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant/comment_1_3274820a0d1f10c505f15cd29a37b95a._comment
new file mode 100644
index 0000000000..d4839cb1d5
--- /dev/null
+++ b/doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant/comment_1_3274820a0d1f10c505f15cd29a37b95a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.3"
+ subject="comment 1"
+ date="2014-05-21T18:29:16Z"
+ content="""
+What auto-repair are you referring to?
+
+If you schedule a fsck of the repository in the webapp, then when that finds a problem with the git repository, it will be repaired. So if you don't want this, remove any scheduled fsck jobs.
+
+The assistant also detects a few common problems at startup that prevent it from working, such as a corrupt index file, and automatically repairs those. These repairs only happen at startup. If the index file is corrupt, it has to delete it and re-add every file to the repository, which is expensive, but otherwise it would be completely non-functional.
+"""]]
diff --git a/doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant/comment_2_2cf5aef3f1d340c4ed6249ef94c1b607._comment b/doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant/comment_2_2cf5aef3f1d340c4ed6249ef94c1b607._comment
new file mode 100644
index 0000000000..015dd8cd74
--- /dev/null
+++ b/doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant/comment_2_2cf5aef3f1d340c4ed6249ef94c1b607._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.3"
+ subject="comment 2"
+ date="2014-05-21T18:35:42Z"
+ content="""
+Note that this is asking for a workaround for the bug [[bugs/Auto-repair_greatly_slows_down_the_machine]]. I would rather get to the bottom of that bug, but need more information to do so.
+"""]]
diff --git a/doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant/comment_3_6c53d82e62b2d269a941ba967d05adf5._comment b/doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant/comment_3_6c53d82e62b2d269a941ba967d05adf5._comment
new file mode 100644
index 0000000000..07b1b2557a
--- /dev/null
+++ b/doc/todo/Wishlist__58___disable_auto-repair_for_the_assistant/comment_3_6c53d82e62b2d269a941ba967d05adf5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="80.202.103.55"
+ subject="comment 3"
+ date="2014-05-21T19:18:19Z"
+ content="""
+I'm referring to the large auto-repairs of the actual git repository, as mentioned in the bug report you are referring to. I was under the impression that the fscks also did the equivalent of 'git annex fsck' (which is greatly desired, even without the 'git fsck' checks). I realize it is a sort of workaround, but it is because the 'annex fsck' bit is desired, while the 'git annex repair' bit makes my computer unusable, the last time for over 24 hours, while it was running (at which point I needed to kill it and perform a manual repair).
+"""]]
diff --git a/doc/todo/Wishlist__58___sanitychecker_fix_wrong_UUID__47__duplicate_remote.mdwn b/doc/todo/Wishlist__58___sanitychecker_fix_wrong_UUID__47__duplicate_remote.mdwn
new file mode 100644
index 0000000000..0f01ae680b
--- /dev/null
+++ b/doc/todo/Wishlist__58___sanitychecker_fix_wrong_UUID__47__duplicate_remote.mdwn
@@ -0,0 +1,9 @@
+In certain situations different client annexes might get the same remote repository added, but before being synced.
+
+Once the two clients sync they will both have two remotes with the same name. But only one UUID will have any content(Assuming only one client pushed).
+
+It would be nice to have some (automatic?) way to resolve this conflict.
+
+Not sure if anything sane can be done if both clients have pushed?
+
+> [[done]] see comment --[[Joey]]
diff --git a/doc/todo/Wishlist__58___sanitychecker_fix_wrong_UUID__47__duplicate_remote/comment_1_a9e54e4bc540cbab7cdbbfdeaa973f4a._comment b/doc/todo/Wishlist__58___sanitychecker_fix_wrong_UUID__47__duplicate_remote/comment_1_a9e54e4bc540cbab7cdbbfdeaa973f4a._comment
new file mode 100644
index 0000000000..57083fb239
--- /dev/null
+++ b/doc/todo/Wishlist__58___sanitychecker_fix_wrong_UUID__47__duplicate_remote/comment_1_a9e54e4bc540cbab7cdbbfdeaa973f4a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-01-16T17:54:51Z"
+ content="""
+This does not make sense to me. If the remote is a git repo,
+it will be initialized by git-annex only once, so there will only be one
+UUID. The second "client" that uses that remote will see the earlier UUID.
+
+Unless there were some kind of a race in initializing the same repo
+concurrently, but that seems unlikely and if so this is lacking in any
+details about it.
+
+I'm going to close this since it does not make sense, but do followup if
+you remember what this was supposed to be about.
+"""]]
diff --git a/doc/todo/Workflow_guide.mdwn b/doc/todo/Workflow_guide.mdwn
new file mode 100644
index 0000000000..5cc971b13d
--- /dev/null
+++ b/doc/todo/Workflow_guide.mdwn
@@ -0,0 +1,15 @@
+I try to use git annex, but I frequently don't know if I'm doing things correctly, and my files are getting messed up.
+
+An expert guide to the full workflow would go a long way toward user-friendliness for me. The walkthrough currently has guides to a number discrete items in the workflow, but it doesn't give me a clear sense of the process.
+
+I'm always confused about when I'm supposed to be using pure git commands and when they should be git annex commands, when to commit, add, and sync --content, and when each of these is redundant.
+
+If possible, most helpful would be a guide to how you imagine the workflow from the beginning and including each step of the process, in the order you'd do it.
+
+I want to start keeping track of some files I have in a directory
+I want to copy them to a second computer.
+From a third place, I want to get them from the second computer.
+I change the files on one computer, and I want to make sure the changes get synced to the others.
+What are the commands you'd run at each step?
+
+Many thanks.
diff --git a/doc/todo/Workflow_guide/comment_1_f4242a3bdeffb90336f562f9ec182e5d._comment b/doc/todo/Workflow_guide/comment_1_f4242a3bdeffb90336f562f9ec182e5d._comment
new file mode 100644
index 0000000000..40b109ce0a
--- /dev/null
+++ b/doc/todo/Workflow_guide/comment_1_f4242a3bdeffb90336f562f9ec182e5d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-21T16:52:10Z"
+ content="""
+I think this is a good idea for an extension to the walkthrough. I
+am probably the worst person to write it. How about, you write it, and I'll
+fact check and edit it.
+"""]]
diff --git a/doc/todo/Workflow_guide/comment_2_ee6da4cc639bca0b17156d51ebfc05c2._comment b/doc/todo/Workflow_guide/comment_2_ee6da4cc639bca0b17156d51ebfc05c2._comment
new file mode 100644
index 0000000000..a396da0784
--- /dev/null
+++ b/doc/todo/Workflow_guide/comment_2_ee6da4cc639bca0b17156d51ebfc05c2._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="Workflow Summary"
+ date="2016-10-09T13:39:38Z"
+ content="""
+I'll try to address some of this.
+
+Git-annex supports a wide variety of workflows, a spectrum that ranges from completely automatic behavior where git-annex handles everything, through manual behavior where git-annex does only what you say, when you tell it to, down to internal behavior, where you have complete control and understand how everything is stored and exactly what changes are happening.
+
+I will proceed to summarize all of these.  Your question sounds like a high-level question, so I will begin at the automatic end, hoping that this is most useful, and drill down to the low level approaches.  Note, however, that this the opposite order of how git-annex was apparently developed.  A list of workflows that started from manual, commandline usage would be much more intuitive, but you'd have to be willing to read the man page and wiki pages to get started, and that's pretty much what's already out there anyway.
+
+Note that for each of these levels of interaction, all the levels _following_ will also work as well.  So you can actually manually move annexed files around while the webapp is running, etc.
+
+(0) `git annex webapp`.  This command launches a local web server which serves a graphical user interface and automatically manages git annex.  It will attempt to guide you through the whole process and do everything for you.  I think the intent is that no other commands are needed.  This should be run on every machine that may produce file changes.
+
+(1) `git annex assistant` without running the webapp.  You could call this the command-line version of the webapp, giving you more control over creating and connecting your repositories, and configuring how files are moved between them.  The assistant, when running, will automatically watch for file changes and synchronize them to other repositories, but you must manually create the repositories and configure the rules for syncing.  To create a repository, use `git init` and then `git annex init`, and then `git remote add` it to any other repositories.  If you want more than one annex, you can add their paths to ~/.config/git-annex/autostart if you would like them to automatically begin syncing when `git annex assistant --autostart` is run, perhaps on boot or login.  You can configure rules for where files are copied using the repository setup commands such as preferred content expressions, `git annex numcopies`, and `git config annex.largefiles`; most of the settings are accessible in one place with `git annex vicfg`.
+
+(2) `git annex watch` without running the assistant.  This command is like the assistant but has no automatic network behavior, giving you complete control over when repositories are pushed and pulled, and when files are moved between systems.  The repository is watched, and any file changes are added to git-annex.  In order to synchronize between repositories, you must run `git annex sync --content` in the repository with the changes, which will merge the git history and logs with your remotes, and automatically transfer files to match your preferred and required content expressions.
+
+(3) No background processes, allowing you to decide when and what files are annexed.  In order to tell git-annex to manage files, you must `git annex add` the files.
+
+(4) Plain `git annex sync` without `--content`, giving you fine-grained control of where copies of your files are stored.  This tells git-annex to merge git histories, but it does not automatically transfer your large files between systems.  To transfer files and directories, you can use `git annex get`, `git annex drop`, `git annex move`, and `git annex copy`.  Git-annex will not violate a required content expression or your numcopies setting unless you pass --force, so your files are still safe.  This is the workflow I mostly use, and I find it the most stable.  I'm trying to migrate up to `--content`, but I have too many large files that haven't reached their numcopies yet for that to be effective.
+
+(5) Manual management of git history without running the syncronizer, allowing you to control precisely what is committed, what commit message is used, and how your history is merged between repositories.  You must have an understanding of git, and run `git commit` after `git annex add` to store the change.  You must manage the git history yourself, using `git pull` and `git push`, to synchronize repositories.  You may freely use git normally side-by-side with git-annex.
+
+(6) Manual management of git annex keys, giving you control of what and where git annex stores your files under the hood, and how they are associated with your working tree, rather than using the `git annex add` and `git annex get` commands which reference files automatically.  Git-annex has a variety of plumbing commands listed in the man page that let you directly store and retrieve data in an annex associated with your git repository, where every datafile is enumerated by a unique hashkey.
+
+There are a lot of possible workflows with git annex.  It provides an array of tools that allow you to both completely automate things and have very fine control of them.  The more you can learn, the more power you will have.
+"""]]
diff --git a/doc/todo/Workflow_guide/comment_3_8cf0f9913dc307cd18001656ba390159._comment b/doc/todo/Workflow_guide/comment_3_8cf0f9913dc307cd18001656ba390159._comment
new file mode 100644
index 0000000000..ff5fa0327a
--- /dev/null
+++ b/doc/todo/Workflow_guide/comment_3_8cf0f9913dc307cd18001656ba390159._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-10-17T19:42:08Z"
+ content="""
+@xloem nice start!
+
+It would be helpful to get this into a set of wiki pages documenting the
+workflows in detail. Since this site is a wiki, you can add pages as you like.
+Start by clicking the question mark to create [[/workflow]], and see
+[[ikiwiki/wikilink]] for how to add sub-pages like [[/workflow/assistant]].
+"""]]
diff --git a/doc/todo/Workflow_guide/comment_4_b6f5ce361529356a77b0e6141a62c06d._comment b/doc/todo/Workflow_guide/comment_4_b6f5ce361529356a77b0e6141a62c06d._comment
new file mode 100644
index 0000000000..6127e3e8d7
--- /dev/null
+++ b/doc/todo/Workflow_guide/comment_4_b6f5ce361529356a77b0e6141a62c06d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="marekj"
+ avatar="http://cdn.libravatar.org/avatar/65a60e8f5183feeeef8cef815bf73e61"
+ subject="I took the liberty to do it"
+ date="2016-12-14T07:49:26Z"
+ content="""
+I simply copied @xloem's into a new [[workflow]] page. I have been looking for such a guide myself for quite some time.
+"""]]
diff --git a/doc/todo/Workflow_guide/comment_5_6ec6fb45021ba82ed6a4bb9a6f3cfceb._comment b/doc/todo/Workflow_guide/comment_5_6ec6fb45021ba82ed6a4bb9a6f3cfceb._comment
new file mode 100644
index 0000000000..fe30f61064
--- /dev/null
+++ b/doc/todo/Workflow_guide/comment_5_6ec6fb45021ba82ed6a4bb9a6f3cfceb._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-12-20T19:04:12Z"
+ content="""
+Good start on the workflow page!
+
+I've added some links to it to make it discoverable.
+
+Not sure if the workflow page quite gets to what was originally requested:
+
+> I want to start keeping track of some files I have in a directory
+> I want to copy them to a second computer.
+> From a third place, I want to get them from the second computer.
+> I change the files on one computer, and I want to make sure the changes get synced to the others.
+> What are the commands you'd run at each step?
+
+Leaving this todo open for now..
+"""]]
diff --git a/doc/todo/Workflow_guide/comment_6_640e5c6cdea8a6fae63c3fab6970f1f2._comment b/doc/todo/Workflow_guide/comment_6_640e5c6cdea8a6fae63c3fab6970f1f2._comment
new file mode 100644
index 0000000000..9eae8e9119
--- /dev/null
+++ b/doc/todo/Workflow_guide/comment_6_640e5c6cdea8a6fae63c3fab6970f1f2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2016-12-21T18:19:07Z"
+ content="""
+In a way the use cases on the front page of the website are trying to
+accomplish the same thing requested here. I think that section could be
+moved more in the direction of listing some ways to use git-annex and
+linking to walkthroughs for the different use cases.
+"""]]
diff --git a/doc/todo/Workflow_guide/comment_7_805e877b23adcf562feeb7d927fca08d._comment b/doc/todo/Workflow_guide/comment_7_805e877b23adcf562feeb7d927fca08d._comment
new file mode 100644
index 0000000000..01ad920cec
--- /dev/null
+++ b/doc/todo/Workflow_guide/comment_7_805e877b23adcf562feeb7d927fca08d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://anarc.at/openid/"
+ nickname="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/b36dcf65657dd36128161355d8920a99503def9461c1bb212410980fe6f07125"
+ subject="answers"
+ date="2017-01-17T16:56:39Z"
+ content="""
+i actually answered this in [[forum/Full_workflow_guide]] before realizing this post was a duplicate.
+
+i am not sure where that should be put - it's not a \"full workflow guide\", it's actually a \"specific workflow guide\", namely \"i have 3 computers and need to sync files from A to B to C\"... 
+
+i wonder if this should be marked as resolved or if we want to add a specific workflow for this or what?
+
+this reminds me of my broader [[todo/build_a_user_guide]] task... -- [[anarcat]]
+"""]]
diff --git a/doc/todo/__39__info_filename__39___to_provide_information_either_content_is_locally_present.mdwn b/doc/todo/__39__info_filename__39___to_provide_information_either_content_is_locally_present.mdwn
new file mode 100644
index 0000000000..5b91b7d6a3
--- /dev/null
+++ b/doc/todo/__39__info_filename__39___to_provide_information_either_content_is_locally_present.mdwn
@@ -0,0 +1,7 @@
+ATM in DataLad we rely on 'git annex find' to determine either files have content locally.  Even though it could be used in a batch mode, I wondered if we could may be just use 'annex info' to obtain information either a file (or a key) has content locally?  Another benefit would be is that within single command output we could determine also if a file under annex or not (instead of first doing e.g. 'info' to figure out if under annex and then 'find' again to figure out if content is present locally)
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> sure, [[done]] --[[Joey]]
diff --git a/doc/todo/__91__FR__93___No_consistency_check_while_on_battery-only.mdwn b/doc/todo/__91__FR__93___No_consistency_check_while_on_battery-only.mdwn
new file mode 100644
index 0000000000..815ce6a1b7
--- /dev/null
+++ b/doc/todo/__91__FR__93___No_consistency_check_while_on_battery-only.mdwn
@@ -0,0 +1,14 @@
+I hope this has not been mentioned before.  I only found in mentioned in a comment of a devblog post.
+
+### Please describe the problem.
+With `git annex assistant` running, consistency checks is sometimes triggered while the computer is battery-powered (as opposed to plugged into AC).
+
+### What steps will reproduce the problem?
+Configure `git annex assistant` to make consistency check daily (or whatever the default is), unplug from power and wait.
+
+### What version of git-annex are you using? On what operating system?
+`5.20141231` on Archlinux 64 bit.  (From the changelog I guess it's also present in the newest version).
+
+### Please provide any additional information below.
+
+It would be nice if one could toggle whether consistency check may run while not plugged into AC.
diff --git a/doc/todo/__91__FR__93___No_consistency_check_while_on_battery-only/comment_1_b557db02c3719152d392fa454c9c5ce5._comment b/doc/todo/__91__FR__93___No_consistency_check_while_on_battery-only/comment_1_b557db02c3719152d392fa454c9c5ce5._comment
new file mode 100644
index 0000000000..99de27120f
--- /dev/null
+++ b/doc/todo/__91__FR__93___No_consistency_check_while_on_battery-only/comment_1_b557db02c3719152d392fa454c9c5ce5._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-04T19:48:10Z"
+ content="""
+I agree this would be nice. However, how to detect if it's on battery?
+
+Debian has a `on_ac_power` command which is rather complicated; 88 lines of
+code that deal with APM, PMU (powerpc), and two different kernel interfaces
+for ACPI (new sysfs and old /proc/acpi).
+
+Then there's OSX, Windows, Android..
+
+I'm going to move this from bugs to todo.
+"""]]
diff --git a/doc/todo/__91__FR__93___No_consistency_check_while_on_battery-only/comment_2_374567f37635613a5d671c877d601367._comment b/doc/todo/__91__FR__93___No_consistency_check_while_on_battery-only/comment_2_374567f37635613a5d671c877d601367._comment
new file mode 100644
index 0000000000..bf6179b72d
--- /dev/null
+++ b/doc/todo/__91__FR__93___No_consistency_check_while_on_battery-only/comment_2_374567f37635613a5d671c877d601367._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="rasmus"
+ subject="comment 2"
+ date="2015-02-10T18:33:20Z"
+ content="""
+Yeah, probably it's more complicated than just checking `/sys/class/power_supply/BAT0/`...  There's something called [`pmset`](https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pmset.1.html) for macs, but I don't have a mac so I don't know how relevant it is.  For Windows there seems also to be some sort of [api](https://msdn.microsoft.com/en-us/library/windows/desktop/aa372659%28v=vs.85%29.aspx), but again I don't know anything about windows...
+"""]]
diff --git a/doc/todo/__91__PATCH__93___Change_--copies__39___meta_parameter_to_NUMBER.mdwn b/doc/todo/__91__PATCH__93___Change_--copies__39___meta_parameter_to_NUMBER.mdwn
new file mode 100644
index 0000000000..bdb8e4c60a
--- /dev/null
+++ b/doc/todo/__91__PATCH__93___Change_--copies__39___meta_parameter_to_NUMBER.mdwn
@@ -0,0 +1,31 @@
+There is a documentation issue with `--copies` (e.g. used in `git annex find`), parameter should be a number, not a remote.
+
+```
+From dc8c177efcfdd82f62ae1d49a7b1276774a4fbc3 Mon Sep 17 00:00:00 2001
+From: Gergely Risko <errge@nilcons.com>
+Date: Mon, 22 Apr 2024 17:32:06 +0200
+Subject: [PATCH] Change --copies' meta parameter to NUMBER
+
+---
+ CmdLine/GitAnnex/Options.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/CmdLine/GitAnnex/Options.hs b/CmdLine/GitAnnex/Options.hs
+index 694b60d240..07cf54069e 100644
+--- a/CmdLine/GitAnnex/Options.hs
++++ b/CmdLine/GitAnnex/Options.hs
+@@ -298,7 +298,7 @@ keyMatchingOptions' =
+ 		<> completeRemotes
+ 		)
+ 	, annexOption (setAnnexState . Limit.addCopies) $ strOption
+-		( long "copies" <> short 'C' <> metavar paramRemote
++		( long "copies" <> short 'C' <> metavar paramNumber
+ 		<> help "skip files with fewer copies"
+ 		<> hidden
+ 		)
+-- 
+2.43.0
+```
+
+> Thanks! I've applied this for the next release.
+> [[done]] --[[Joey]]
diff --git a/doc/todo/__91__PATCH__93___Fix_annex.adviceNoSshCaching_no_effect.mdwn b/doc/todo/__91__PATCH__93___Fix_annex.adviceNoSshCaching_no_effect.mdwn
new file mode 100644
index 0000000000..082a73997b
--- /dev/null
+++ b/doc/todo/__91__PATCH__93___Fix_annex.adviceNoSshCaching_no_effect.mdwn
@@ -0,0 +1,30 @@
+```
+From 1a67bc14aa74262a304e7b6bd6372b0eca40486e Mon Sep 17 00:00:00 2001
+From: Reiko Asakura <asakurareiko@protonmail.ch>
+Date: Fri, 30 Sep 2022 10:56:17 -0400
+Subject: [PATCH] Fix annex.adviceNoSshCaching having no effect
+
+git will always return option names in lowercase
+---
+ Types/GitConfig.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Types/GitConfig.hs b/Types/GitConfig.hs
+index 44629d412..4b892bd5f 100644
+--- a/Types/GitConfig.hs
++++ b/Types/GitConfig.hs
+@@ -265,7 +265,7 @@ extractGitConfig configsource r = GitConfig
+ 			| otherwise = Nothing
+ 		  in mapMaybe get (M.toList (Git.config r))
+ 		]
+-	, annexAdviceNoSshCaching = getbool (annexConfig "adviceNoSshCaching") True
++	, annexAdviceNoSshCaching = getbool (annexConfig "advicenosshcaching") True
+ 	}
+   where
+ 	getbool k d = fromMaybe d $ getmaybebool k
+-- 
+2.30.2
+
+```
+
+> Thanks for the fix! [[done]] --[[Joey]]
diff --git a/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs.mdwn b/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs.mdwn
new file mode 100644
index 0000000000..ea6ffb1a7b
--- /dev/null
+++ b/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs.mdwn
@@ -0,0 +1,76 @@
+This patch allows hooks to be run in WSL1 for a repo created on an NTFS volume but I think it also applies in general.
+
+```
+From d4587806d8fd1ea767a8effc06edc1a4e10f5bca Mon Sep 17 00:00:00 2001
+From: Reiko Asakura <asakurareiko@protonmail.ch>
+Date: Sun, 25 Sep 2022 15:21:24 -0400
+Subject: [PATCH] Run freeze and thaw hooks on crippled filesystems
+
+The user sets these hooks deliberately so they should always be run. For
+example this allows hooks to be used to manage file permissions on NTFS
+volumes in WSL1.
+---
+ Annex/Perms.hs | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/Annex/Perms.hs b/Annex/Perms.hs
+index 6681da7e0..69e344452 100644
+--- a/Annex/Perms.hs
++++ b/Annex/Perms.hs
+@@ -154,7 +154,7 @@ createWorkTreeDirectory dir = do
+  - that happens with write permissions.
+  -}
+ freezeContent :: RawFilePath -> Annex ()
+-freezeContent file = unlessM crippledFileSystem $
++freezeContent file =
+ 	withShared $ \sr -> freezeContent' sr file
+ 
+ freezeContent' :: SharedRepository -> RawFilePath -> Annex ()
+@@ -163,7 +163,7 @@ freezeContent' sr file = freezeContent'' sr file =<< getVersion
+ freezeContent'' :: SharedRepository -> RawFilePath -> Maybe RepoVersion -> Annex ()
+ freezeContent'' sr file rv = do
+ 	fastDebug "Annex.Perms" ("freezing content " ++ fromRawFilePath file)
+-	go sr
++	unlessM crippledFileSystem $ go sr
+ 	freezeHook file
+   where
+ 	go GroupShared = if versionNeedsWritableContentFiles rv
+@@ -253,7 +253,7 @@ thawContent' sr file = do
+  - permissions. -}
+ thawPerms :: Annex () -> Annex () -> Annex ()
+ thawPerms a hook = ifM crippledFileSystem
+-	( void (tryNonAsync a)
++	( hook >> void (tryNonAsync a)
+ 	, hook >> a
+ 	)
+ 
+@@ -263,9 +263,9 @@ thawPerms a hook = ifM crippledFileSystem
+  - file.
+  -}
+ freezeContentDir :: RawFilePath -> Annex ()
+-freezeContentDir file = unlessM crippledFileSystem $ do
++freezeContentDir file = do
+ 	fastDebug "Annex.Perms" ("freezing content directory " ++ fromRawFilePath dir)
+-	withShared go
++	unlessM crippledFileSystem $ withShared go
+ 	freezeHook dir
+   where
+ 	dir = parentDir file
+@@ -287,9 +287,9 @@ createContentDir dest = do
+ 	unlessM (liftIO $ R.doesPathExist dir) $
+ 		createAnnexDirectory dir 
+ 	-- might have already existed with restricted perms
+-	unlessM crippledFileSystem $ do
++	do
+ 		thawHook dir
+-		liftIO $ allowWrite dir
++		unlessM crippledFileSystem $ liftIO $ allowWrite dir
+   where
+ 	dir = parentDir dest
+ 
+-- 
+2.30.2
+
+```
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs/comment_1_b943081483e4f1f9897b214004d48493._comment b/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs/comment_1_b943081483e4f1f9897b214004d48493._comment
new file mode 100644
index 0000000000..c1abde42f3
--- /dev/null
+++ b/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs/comment_1_b943081483e4f1f9897b214004d48493._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-26T17:01:33Z"
+ content="""
+Thank you for this patch. I've applied it.
+"""]]
diff --git a/doc/todo/a_way_to_figure_out_the_origin_of_largefiles.mdwn b/doc/todo/a_way_to_figure_out_the_origin_of_largefiles.mdwn
new file mode 100644
index 0000000000..1c581b07e5
--- /dev/null
+++ b/doc/todo/a_way_to_figure_out_the_origin_of_largefiles.mdwn
@@ -0,0 +1,10 @@
+we spent some time scratching our heads while trying to figure out WTF git-annex was adding some mouse atlas `.nii` file into `git` while `.gitattributes` had it set so it wouldn't and nothing was in `git annex vicfg` to only then realize that there is also generic `git config annex.largefiles` which effects it.
+
+I wondered if there could be some kind of a "mix" between `git check-attr [PATH]`, `git annex config`, and `git config --list --show-origin` which would not just state the final decision (not large) for a given PATH but also based on what value of `annex.largefiles` it did it and where it got it from (the `.gitattributes`? `git annex config`? `git config` file/option as via `--show-origin`?)
+
+I guess the same functionality might be useful for some other options which could be picked from various sources.
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/a_way_to_figure_out_the_origin_of_largefiles/comment_1_9b0826c1d5b063a3e63d4d2cc030a55b._comment b/doc/todo/a_way_to_figure_out_the_origin_of_largefiles/comment_1_9b0826c1d5b063a3e63d4d2cc030a55b._comment
new file mode 100644
index 0000000000..1d3d67d545
--- /dev/null
+++ b/doc/todo/a_way_to_figure_out_the_origin_of_largefiles/comment_1_9b0826c1d5b063a3e63d4d2cc030a55b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-06-10T06:06:58Z"
+ content="""
+I absolutely second this! Maybe a flag like --explain or an entirely new command that details why exactly git-annex is doing what it does.
+"""]]
diff --git a/doc/todo/a_way_to_figure_out_the_origin_of_largefiles/comment_2_6bfe8e1b6b2c3334803d8a6676862e8a._comment b/doc/todo/a_way_to_figure_out_the_origin_of_largefiles/comment_2_6bfe8e1b6b2c3334803d8a6676862e8a._comment
new file mode 100644
index 0000000000..349c4bbd02
--- /dev/null
+++ b/doc/todo/a_way_to_figure_out_the_origin_of_largefiles/comment_2_6bfe8e1b6b2c3334803d8a6676862e8a._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-06-12T20:08:40Z"
+ content="""
+I think it makes sense to have a command that displays the value of a
+config that will be used, and where that value is configured. I've implemented 
+`git-annex config --show-origin` to do that.
+
+For example:
+
+	% git-annex config --show-origin annex.largefiles
+	  annex.largefiles may be configured in gitattributes. Pass --for-file= with a filename to check
+	branch:git-annex	exclude=*.c
+	% git-annex config --show-origin annex.largefiles --for-file=foo
+	gitattributes	largerthan=100kb
+	% git config annex.largefiles oops
+	% git-annex config --show-origin annex.largefiles --for-file=foo
+	file:.git/config	oops
+"""]]
diff --git a/doc/todo/a_way_to_figure_out_the_origin_of_largefiles/comment_3_def75a3ad8907cb62eb5d96c85aabd5e._comment b/doc/todo/a_way_to_figure_out_the_origin_of_largefiles/comment_3_def75a3ad8907cb62eb5d96c85aabd5e._comment
new file mode 100644
index 0000000000..c1e11650f7
--- /dev/null
+++ b/doc/todo/a_way_to_figure_out_the_origin_of_largefiles/comment_3_def75a3ad8907cb62eb5d96c85aabd5e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-07-25T15:04:28Z"
+ content="""
+Hmm, --show-origin only implements part of what was requested here. The
+other part is to explain what part of a largefiles expression caused it to
+match (or not match).
+
+I think that nobodyinperson's suggestion of --explain got into my brain
+and marinated a while, because I later opened [[todo/option_to_explain]].
+"""]]
diff --git a/doc/todo/absolute_symlinks.mdwn b/doc/todo/absolute_symlinks.mdwn
new file mode 100644
index 0000000000..348ef67b8c
--- /dev/null
+++ b/doc/todo/absolute_symlinks.mdwn
@@ -0,0 +1,7 @@
+A lot of my git-annex content doesn't have a "stable" location within the repository, I might decide to move things to subdirectories or out of subdirectories. This always invalidates the relative `../../.git/` symlinks that git-annex uses and I have to `annex fix` them every time I move things around. This is especially useful when I'm accessing my homeserver over SMB from Windows PCs, where symlinks are followed automatically – and broken symlinks simply don't show up via SMB at all, so moving a file into a subfolder causes it to "disappear" until `annex fix`.
+
+But the repository as a whole does have a stable location in the filesystem, so it would be much more convenient if I had an option for the item symlinks to use absolute paths, e.g. `Foo.mkv -> /hdd/Videos/.git/annex/[etc]`. (I *could* ensure that the `/hdd/Videos` path is valid on all the hosts that the repository is on, and I don't mind running `annex fix` on the rare occasion when I need to move it.)
+
+I thought such an option already exists, but could not find it anywhere within the git-annex manual.
+
+I considered having the files unlocked (which seems to work well with Btrfs automatically providing thin copies even without needing to use the fragile-looking annex.thin mode), but 1) even missing files appear as regular files when they're unlocked, which is *very* confusing; 2) the files are no longer read-only and I don't like the idea of some tool accidentally damaging them.
diff --git a/doc/todo/add_--all___40__or_alike__41___to_find_and_findref.mdwn b/doc/todo/add_--all___40__or_alike__41___to_find_and_findref.mdwn
new file mode 100644
index 0000000000..c6a57de89b
--- /dev/null
+++ b/doc/todo/add_--all___40__or_alike__41___to_find_and_findref.mdwn
@@ -0,0 +1,10 @@
+Original discussion and need is within [datalad/issues/7038](https://github.com/datalad/datalad/issues/7038) -- we had been using `annex find` and `annex findref` with `--copies 0` to simply force those two commands to return information for all keys used in the current tree, regardless of their local presence.
+
+Unfortunately as that issue shows, adding `--copies 0` results in significant run time penalty over a run without it, or some different invocation with similar (albeit not as generic, since would miss keys without size) `--largerthan -1`.
+
+I found no other way to make `find` (or `findref`) to do what is needed. So I felt that may be it does need some additional option, or may be some special ad-hoc value for some of the possible "fast" expressions (like `--largerthan idonotcare`).
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]]; added --anything (and --nothing). --[[Joey]]
diff --git a/doc/todo/add_--all___40__or_alike__41___to_find_and_findref/comment_1_8407146882e97ee8510f28df2ba5129c._comment b/doc/todo/add_--all___40__or_alike__41___to_find_and_findref/comment_1_8407146882e97ee8510f28df2ba5129c._comment
new file mode 100644
index 0000000000..b3b68572df
--- /dev/null
+++ b/doc/todo/add_--all___40__or_alike__41___to_find_and_findref/comment_1_8407146882e97ee8510f28df2ba5129c._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-12-20T19:21:34Z"
+ content="""
+Using --copies necessarily loads up the location tracking log for
+each file, which does add overhead.
+
+Any other matching option that matches everything will work just as well
+for you. I think that `git-annex find --include='*'` is the best thing
+currently available. Indeed, the git-annex-find man page suggests to use
+that. The only overhead is an unncessary glob match, which
+should be almost unmeasurable.
+
+It does seem like it might be worth adding --anything that simply matches
+anything. Preferred content expressions already support "anything". And
+`git-annex find --anything` makes sense and is easier to type.
+
+But, you'll probably be better off using `--include='*'` since it works
+with older versions of git-annex.
+
+(--all is the wrong name for such an option since it already has another
+meaning, although I don't think it makes sense for `git-annex find` to
+support --all, it has certianly been requested before by people who want to
+generalize that existing meaning..)
+"""]]
diff --git a/doc/todo/add_--dry-run.mdwn b/doc/todo/add_--dry-run.mdwn
new file mode 100644
index 0000000000..dd21381eab
--- /dev/null
+++ b/doc/todo/add_--dry-run.mdwn
@@ -0,0 +1,25 @@
+Previous discussion which touched upon it was [7 years ago](https://git-annex.branchable.com/todo/wishlist__58___--dry-run_option_for_all_commands/) (unless I missed some) where part of the response was 
+
+> I don't see the benefit to justify this work. git annex add is entirely predictable; it's very similar to git add. Which itself lacks a dry-run option. 
+
+Oh well:
+
+```
+$> git add --help | grep -e '-n, --dry' -A1
+       -n, --dry-run
+           Don’t actually add the file(s), just show if they exist and/or will be ignored.
+
+```
+and users [submit requests against DataLad](https://github.com/datalad/datalad/issues/6909) to be able to discover what file would go to git and which to git-annex. Also would be useful to know if to git-annex -- would it be locked or unlocked?  Someone else might even want to discover what would be the annex key if it would go into annex, but so far I do not think it is within our desired use-case and it might be too lengthy to compute the key checksum etc.
+
+As for 
+
+> And like git add, you can certianly undo the effects of git annex add.
+
+
+well -- unless there was a version staged already you don't want to loose etc.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] joey
diff --git a/doc/todo/add_--dry-run/comment_1_4daf51eec7db67a89bec8f81b742a094._comment b/doc/todo/add_--dry-run/comment_1_4daf51eec7db67a89bec8f81b742a094._comment
new file mode 100644
index 0000000000..1709202877
--- /dev/null
+++ b/doc/todo/add_--dry-run/comment_1_4daf51eec7db67a89bec8f81b742a094._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-03T13:54:44Z"
+ content="""
+That old todo was about adding --dry-run to all git-annex commands.
+That would be infeasible as discussed there. I'm willing to consider adding
+it to specific commands like `git-annex add` or maybe `git-annex drop`.
+
+It's certianly possible to use `git-annex matchexpression` to check if a
+file matches an annex.largefiles or annex.addunlocked expression. But I think
+you're probably not looking for a machine-parseable way to do it.
+(It would not be appropriate for `--dry-run` output to be machine-parseable
+either.)
+
+While `git-annex add` does report when it adds a file to git rather than
+the annex, it does not currently have any output difference at all for
+locked vs unlocked adds. I don't think I would want to change that
+either. If add does not do what the user wants WRT locked/unlocked, they
+can just use `git-annex lock` or `git-annex unlock` to get to the desired
+state.
+
+> > And like git add, you can certianly undo the effects of git annex add.
+> 
+> well -- unless there was a version staged already you don't want to loose etc.
+
+That does not make sense. Why would --dry-run help you avoid such a mistake?
+It's not going to tell you that you have a previous staged version
+that would be overwritten. If you're concerned about that happening, commit
+first.
+"""]]
diff --git a/doc/todo/add_--dry-run/comment_2_312127fc2780fd894332d7d8b7f7a209._comment b/doc/todo/add_--dry-run/comment_2_312127fc2780fd894332d7d8b7f7a209._comment
new file mode 100644
index 0000000000..9f9a72f144
--- /dev/null
+++ b/doc/todo/add_--dry-run/comment_2_312127fc2780fd894332d7d8b7f7a209._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-08-03T14:53:35Z"
+ content="""
+Implemented `git-annex add --dry-run`.
+
+As noted it does not let you tell if a file would be added locked or unlocked
+since `git-annex add` output is the same either way.
+
+Also when JSON output is enabled, `git-annex add` usually outputs the key,
+but with `--dry-run`, it does not. Generating the key would involve locking
+down the file, and by that point the command is making changes to the
+filesystem. Use `git-annex calckey` instead.
+
+Implementation was not as simple as making CommandPerform a no-op. Some parts
+of CommandPerform actions needed to be run when doing a dry-run, in order for
+addingExistingLink to display its warning, and for showNote to display the
+very information that the user is interested in seeing from --dry-run.
+
+A cleaner implementation would probably involve moving those actions out of
+CommandPerform, perhaps by splitting CommandPerform into two parts.
+Which would be a lot of work and still failure prone. That is why I don't
+think it's a good idea to add --dry-run to very many commands.
+"""]]
diff --git a/doc/todo/add_--jobs_for_dropunused_command.mdwn b/doc/todo/add_--jobs_for_dropunused_command.mdwn
new file mode 100644
index 0000000000..6128ff2f58
--- /dev/null
+++ b/doc/todo/add_--jobs_for_dropunused_command.mdwn
@@ -0,0 +1,3 @@
+Simple "drop" have it, but no for "dropunused". Missed?
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/add_--jobs_for_dropunused_command/comment_1_bcd06faab6b5f6394333e74a17249d08._comment b/doc/todo/add_--jobs_for_dropunused_command/comment_1_bcd06faab6b5f6394333e74a17249d08._comment
new file mode 100644
index 0000000000..4f643b2874
--- /dev/null
+++ b/doc/todo/add_--jobs_for_dropunused_command/comment_1_bcd06faab6b5f6394333e74a17249d08._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="git annex drop --unused --jobs=cpus works"
+ date="2023-07-15T05:53:43Z"
+ content="""
+If you want to drop all unused files, `git annex unused;git annex drop --unused --jobs=cpus` works.
+"""]]
diff --git a/doc/todo/add_--json-progress_support_in_push_and_pull.mdwn b/doc/todo/add_--json-progress_support_in_push_and_pull.mdwn
new file mode 100644
index 0000000000..36c8337293
--- /dev/null
+++ b/doc/todo/add_--json-progress_support_in_push_and_pull.mdwn
@@ -0,0 +1 @@
+The pull and push commands do not have --json-progress support.  Please add.
diff --git a/doc/todo/add_--json-progress_support_in_push_and_pull/comment_1_403acf073a2a8d53eaa880cc2564347d._comment b/doc/todo/add_--json-progress_support_in_push_and_pull/comment_1_403acf073a2a8d53eaa880cc2564347d._comment
new file mode 100644
index 0000000000..0f76888df8
--- /dev/null
+++ b/doc/todo/add_--json-progress_support_in_push_and_pull/comment_1_403acf073a2a8d53eaa880cc2564347d._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-02-05T17:57:49Z"
+ content="""
+They don't have --json, which would be a necessary first step.
+
+This was considered in
+[this_todo](https://git-annex.branchable.com/todo/--json_for_unannex__and_ideally_any_other_command_/)
+when adding --json to many commands, and the thinking for not adding it
+was:
+
+> git-annex-sync (while it would be pretty easy to support, it outputs
+> different types of messages depending on what remotes it syncs with and
+> what needs to be done. Eg, copy to remote, or export to remote, or import
+> from remote. Each would be a different format of json message, which
+> violates the principle that all git-annex json output should be
+> discoverable by simply running the command. And of course, everything it
+> does can be done by other commands, which can support json without having
+> that problem.)
+
+sync had not been split into pull and push at that point. Being split does
+reduce the space of different things, but it's still multiple things, so
+still a problem for json output discoverability.
+
+(Also push and pull can drop from a remote or locally, and of course there are
+the git operations they do, which would probably have to become silent in
+json mode.)
+"""]]
diff --git a/doc/todo/add_--json-progress_support_in_push_and_pull/comment_2_ff0b1ca16b03d2e6c8331645adad84a6._comment b/doc/todo/add_--json-progress_support_in_push_and_pull/comment_2_ff0b1ca16b03d2e6c8331645adad84a6._comment
new file mode 100644
index 0000000000..73609e31df
--- /dev/null
+++ b/doc/todo/add_--json-progress_support_in_push_and_pull/comment_2_ff0b1ca16b03d2e6c8331645adad84a6._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="jstritch"
+ avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
+ subject="comment 2"
+ date="2024-02-06T16:10:56Z"
+ content="""
+To me, the purpose of any progress message is twofold: 1) let the user know the program is not stuck and 2) provide information about what was happening if it does get stuck. Push and pull do this now without JSON.
+
+I agree the same JSON progress object format should be used for all commands. Currently the action progress information includes: command, file, input, byte-progress, total-size, and percent-progress.
+
+The calling application is able to \"know\" which command it issued to cause the progress reports.
+
+A separate, optional field could be added for the particular remote involved. For example, messages like \"Copy file A to remote-one X% complete\" and \"Export file B to remote-two X% complete\" should be possible.
+
+I'm in favor of documenting data structures. Forcing developers to reverse-engineer the structure is inefficient at best. While the principle that all git-annex json output should be discoverable by simply running the command sounds good, I find it leaves much to be desired. Just to find out what's available, someone must setup and run the command. I suggest updating the requirement to \"All git-annex JSON output objects are documented.\"
+
+Users will get impatient and grow frustrated without some type of indication work is in progress.
+
+I'm OK with leaving Git operations silent for now.
+
+Please improve the end-user experience by devising a way to inform the user git-annex is making progress with JSON.
+"""]]
diff --git a/doc/todo/add_--json-progress_support_in_push_and_pull/comment_3_a11ee71f4ee907b011aebcfe270b7ee3._comment b/doc/todo/add_--json-progress_support_in_push_and_pull/comment_3_a11ee71f4ee907b011aebcfe270b7ee3._comment
new file mode 100644
index 0000000000..aec53b9cf7
--- /dev/null
+++ b/doc/todo/add_--json-progress_support_in_push_and_pull/comment_3_a11ee71f4ee907b011aebcfe270b7ee3._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="jstritch"
+ avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
+ subject="comment 3"
+ date="2024-02-07T15:52:18Z"
+ content="""
+Additional clarification of my posts above:
+
+1) JSON allows optional fields. That is, fields which are only present when needed. I am specifically saying not to include all fields every time with `null` values as needed.
+
+2) Occasionally tacking the remote name onto the end of a string named `command` is not discoverable. The `command` key would have to be renamed to something like `commandAndSometimesRemote` to be discoverable. jstritch's naming rule #5: If a name needs a conjunction to accurately describe it, the design can be improved.
+
+3) The optional field name is more easily observed than the optional string content.
+
+4) Consider the application code consuming the JSON. A test for the presence of the remote name is required either way. Do you want those applications writing the test \"if the command value contains one space\" or \"if the remote key is present\"? Code is written once and read hundreds of times. The second test conveys the intent, reducing maintenance cost.
+
+5) The application code to deal with splitting the string and handling each part becomes unnecessary with the optional field.
+
+6) The documentation of the JSON could include a matrix showing the key name and its data type versus the commands, similar to a feature comparison table.
+
+7) Documenting the JSON does not make it less discoverable.
+
+I hope you find this information helpful to improve the end-user experience. Let me know if you have any questions.
+"""]]
diff --git a/doc/todo/add_--json-progress_support_in_push_and_pull/comment_4_0f3c22853b50550237f9659ed2120ab2._comment b/doc/todo/add_--json-progress_support_in_push_and_pull/comment_4_0f3c22853b50550237f9659ed2120ab2._comment
new file mode 100644
index 0000000000..24a52672ad
--- /dev/null
+++ b/doc/todo/add_--json-progress_support_in_push_and_pull/comment_4_0f3c22853b50550237f9659ed2120ab2._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2024-02-27T17:22:52Z"
+ content="""
+Rather than using git-annex push/pull/sync with a complex json format,
+complications of knowing what remote it's acting on, etc, a program can
+simply use git-annex get/copy/drop/import/export to do the same operations,
+all of which already support json.
+
+> I'm OK with leaving Git operations silent for now.
+
+In the case where the git operation needs to prompt for a password, this
+would leave the user with a password prompt with no prior indication of what is
+being done. I don't think that's acceptable.
+
+> Please improve the end-user experience by devising a way to inform the
+> user git-annex is making progress with JSON.
+
+> I hope you find this information helpful to improve the end-user experience.
+> Let me know if you have any questions.
+
+Yikes, that almost triggered my ChatGPT detector.
+"""]]
diff --git a/doc/todo/add_--json-progress_to___96__git_annex_add__96__.mdwn b/doc/todo/add_--json-progress_to___96__git_annex_add__96__.mdwn
new file mode 100644
index 0000000000..514bbffe97
--- /dev/null
+++ b/doc/todo/add_--json-progress_to___96__git_annex_add__96__.mdwn
@@ -0,0 +1,8 @@
+ATM there is no `--json-progress` in `git annex add` (only `--json`), so no feedback to the user could be provided on ETA etc.  Would be nice to have `--json-progress` there to echo similar one for `get` and `copy`.
+
+Cheers!
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/add_--json-progress_to___96__git_annex_add__96__/comment_1_9acc343305dd5a2aaf569a6396d09896._comment b/doc/todo/add_--json-progress_to___96__git_annex_add__96__/comment_1_9acc343305dd5a2aaf569a6396d09896._comment
new file mode 100644
index 0000000000..6a501a7498
--- /dev/null
+++ b/doc/todo/add_--json-progress_to___96__git_annex_add__96__/comment_1_9acc343305dd5a2aaf569a6396d09896._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-04-26T14:17:58Z"
+ content="""
+First things first.. There is no progress of any kind for add of an
+individual item.
+
+This would need changes to the Backend interface so it can display progress
+while hashing..
+"""]]
diff --git a/doc/todo/add_--json-progress_to_fsck_--json.mdwn b/doc/todo/add_--json-progress_to_fsck_--json.mdwn
new file mode 100644
index 0000000000..c228b321d9
--- /dev/null
+++ b/doc/todo/add_--json-progress_to_fsck_--json.mdwn
@@ -0,0 +1,17 @@
+Please add the feature/switch `--json-progress` to `git annex fsck --json`.
+
+For a basic version, it would be nice to show the percentage using the number of processed chunks / total number of chunks for a given file while calculating checksum.
+
+Let's not forget that a file on a remote can be fsck-ed when using `--from <remote>`. In this case if the file is not present locally, the file must be downloaded first (`--json-progress` is already supported for `get`). Usually this takes much-much longer as the checksum calculation. When checking a large file (~1Gb) on a not too fast remote, it's quite a time for the first "response" that something is happening when using the `--json` switch. To be exact, the first and only response is that the check has finished (happy way). It would be nice to see the json progress of the download+checksum calculation.
+
+
+Test environment:
+
+Docker Community 20.10.5
+
+Ubuntu 20.04.2 LTS (Focal Fossa)
+
+git-annex version: 8.20210224-gf951847c6 (kitenet: SHA256E-s51232145--1e57d2e334cffdb3c3874785cfba4f6d5fc521808d0b1deef4fb68160dd88d48.tar.gz)
+
+> [[done]] via incremental checksum while downloading, for nearly all
+> remotes. --[[Joey]]
diff --git a/doc/todo/add_--json-progress_to_fsck_--json/comment_1_170acd9fc5b5a40ae22de0bf418b424c._comment b/doc/todo/add_--json-progress_to_fsck_--json/comment_1_170acd9fc5b5a40ae22de0bf418b424c._comment
new file mode 100644
index 0000000000..adb705703f
--- /dev/null
+++ b/doc/todo/add_--json-progress_to_fsck_--json/comment_1_170acd9fc5b5a40ae22de0bf418b424c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="parhuzamos"
+ avatar="http://cdn.libravatar.org/avatar/79ed445f40e89bd8ba696bab3942ec56"
+ subject="comment 1"
+ date="2021-05-24T09:33:50Z"
+ content="""
+Is this possible? Or makes no sense? Do you plan implementing this?
+
+Thank you,
+Bence
+"""]]
diff --git a/doc/todo/add_--json-progress_to_fsck_--json/comment_2_2ce9c3c35ea5c4033bfa42e2f3365a64._comment b/doc/todo/add_--json-progress_to_fsck_--json/comment_2_2ce9c3c35ea5c4033bfa42e2f3365a64._comment
new file mode 100644
index 0000000000..7fb6967d69
--- /dev/null
+++ b/doc/todo/add_--json-progress_to_fsck_--json/comment_2_2ce9c3c35ea5c4033bfa42e2f3365a64._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-06-28T17:00:33Z"
+ content="""
+It seems problimatic to have json progress for both downloading the file
+and for checksumming it. I don't know how that json would look.
+
+In the meantime, though, git-annex has changed to checksum files while they
+are being downloaded from most remotes, and when it can do that, fsck
+--from avoids the separate checksumming step.
+
+While some special remotes do not support that, it's a very limited list:
+only bittorrent on linux, and adb, external, gcrypt, hook, and rsync on
+other OSs.
+
+This makes me think that complicating the json output to display two
+different kinds of progress is probably not worth the complication.
+"""]]
diff --git a/doc/todo/add_--json-progress_to_fsck_--json/comment_3_5c0c3bdf1e5cf68f2dcebdd85a8253ac._comment b/doc/todo/add_--json-progress_to_fsck_--json/comment_3_5c0c3bdf1e5cf68f2dcebdd85a8253ac._comment
new file mode 100644
index 0000000000..a54b4bee12
--- /dev/null
+++ b/doc/todo/add_--json-progress_to_fsck_--json/comment_3_5c0c3bdf1e5cf68f2dcebdd85a8253ac._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="jstritch"
+ avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
+ subject="comment 3"
+ date="2023-07-11T18:56:39Z"
+ content="""
+The --json-progress flag should produce progress. I do not understand why it would be a problem to intermix types of 'action' in the output. If file A is uploaded and file B is downloaded and checksummed, that's (at least) three different progress objects to produce. This is exactly the type of information I want to see on the screen instead of wondering if it's stuck. I would also apply this pattern to sync and friends.
+
+Upload A 35%
+
+Upload A 100%
+
+Download B 100%
+
+Checksum B 50%
+
+Checksum B 100%
+
+Go ahead and make per-file json error results available and describe in the documentation.
+"""]]
diff --git a/doc/todo/add_ancient_armel_build.mdwn b/doc/todo/add_ancient_armel_build.mdwn
new file mode 100644
index 0000000000..602cc76568
--- /dev/null
+++ b/doc/todo/add_ancient_armel_build.mdwn
@@ -0,0 +1,3 @@
+Add an armel build like the i386ancient build.
+
+> [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/add_ancient_armel_build/comment_1_704f1a854e5ef62edbca60ab209d2123._comment b/doc/todo/add_ancient_armel_build/comment_1_704f1a854e5ef62edbca60ab209d2123._comment
new file mode 100644
index 0000000000..28842b5c08
--- /dev/null
+++ b/doc/todo/add_ancient_armel_build/comment_1_704f1a854e5ef62edbca60ab209d2123._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="rustikus@9db90d0c115a1825e2f1e5f15257ec1298a6c7b6"
+ nickname="rustikus"
+ avatar="http://cdn.libravatar.org/avatar/6fe372a7a46198829723c408af75c8cc"
+ subject="Any update or help needed?"
+ date="2017-01-12T13:40:38Z"
+ content="""
+Hi,
+
+is there any update? I do have an older version of Synology DiskStation (DS211+) which does have this CPU. Anything I can do to help?
+Disclaimer: I am quite familiar with Linux but I am no expert in programming with haskel.
+
+Thanks!
+"""]]
diff --git a/doc/todo/add_ancient_armel_build/comment_2_0b02f96699e9ec9447e336b74b255801._comment b/doc/todo/add_ancient_armel_build/comment_2_0b02f96699e9ec9447e336b74b255801._comment
new file mode 100644
index 0000000000..5964c7a486
--- /dev/null
+++ b/doc/todo/add_ancient_armel_build/comment_2_0b02f96699e9ec9447e336b74b255801._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://schnouki.net/"
+ nickname="Schnouki"
+ avatar="http://cdn.libravatar.org/avatar/5f6406e9db28564121169f0051645b8c30a12a20ca7bc40287ac9bf2cd3ad283"
+ subject="comment 2"
+ date="2017-02-02T22:05:23Z"
+ content="""
++1. Can't upgrade the kernel on my NAS (Synology DS413j, running Linux 2.6.32...), so I'm stuck with git-annex 5.20150731...
+"""]]
diff --git a/doc/todo/add_ancient_armel_build/comment_3_eaeb9aec42fde6b8a25199b1e1e6a78c._comment b/doc/todo/add_ancient_armel_build/comment_3_eaeb9aec42fde6b8a25199b1e1e6a78c._comment
new file mode 100644
index 0000000000..b645d7b6c1
--- /dev/null
+++ b/doc/todo/add_ancient_armel_build/comment_3_eaeb9aec42fde6b8a25199b1e1e6a78c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-02-20T16:22:58Z"
+ content="""
+The build is set up; it's not run to completion yet, but fingers crossed it
+will eventually.
+"""]]
diff --git a/doc/todo/add_ancient_armel_build/comment_4_da51390e7b67cd1dc075c793e99d4367._comment b/doc/todo/add_ancient_armel_build/comment_4_da51390e7b67cd1dc075c793e99d4367._comment
new file mode 100644
index 0000000000..7ef936ff96
--- /dev/null
+++ b/doc/todo/add_ancient_armel_build/comment_4_da51390e7b67cd1dc075c793e99d4367._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-10-03T16:58:26Z"
+ content="""
+Unfortunately the build failed in an obscure way while installing the deps
+of git-annex back when I tried to set it up.
+
+I tried it again today, and there's no longer a binary of stack for armel,
+only for armhf, so I don't think this build can be provided, at least not
+without quite a lot of backporting.
+"""]]
diff --git a/doc/todo/add_import_--to_command.mdwn b/doc/todo/add_import_--to_command.mdwn
new file mode 100644
index 0000000000..1b2683932a
--- /dev/null
+++ b/doc/todo/add_import_--to_command.mdwn
@@ -0,0 +1,8 @@
+I have a bunch of files I want to track with `git-annex` that are sitting in an external drive. I have a repository sitting on my laptop, but I don't actually have enough free disk space on my laptop to import the files. Really, I just want the file content to be sitting in a special remote. I was thinking the following workflow could be useful:
+
+    cd ~/my-laptop-repo
+    git-annex import --to=s3-remote /mnt/usb-drive/myfiles
+
+The proposed `--to=remote` option would add the files to my repo as `import` normally does, but it wouldn't every keep the content in the repo, the only copy would now sit in `s3-remote`. As little disk space as possible would be staged temporarily in `~/my-laptop-repo`. Perhaps the easiest option would be to import a file normally, but them immediately do a `move` to `s3-remote`? But, ideally for larger files, we would want to stream them directly from `/mnt/usb-drive/myfiles` to `s3-remote` without ever staging them at `~/my-laptop-repo`.
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/add_import_--to_command/comment_1_b70d10190722c0d21c2343fe51e38414._comment b/doc/todo/add_import_--to_command/comment_1_b70d10190722c0d21c2343fe51e38414._comment
new file mode 100644
index 0000000000..684f3aff00
--- /dev/null
+++ b/doc/todo/add_import_--to_command/comment_1_b70d10190722c0d21c2343fe51e38414._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2019-01-14T16:11:39Z"
+ content="""
+Cf. [[todo/import_tree]].
+
+"""]]
diff --git a/doc/todo/add_import_--to_command/comment_2_c7a95793a46ed948301b01a1f29bfac1._comment b/doc/todo/add_import_--to_command/comment_2_c7a95793a46ed948301b01a1f29bfac1._comment
new file mode 100644
index 0000000000..11ac58a048
--- /dev/null
+++ b/doc/todo/add_import_--to_command/comment_2_c7a95793a46ed948301b01a1f29bfac1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 2"
+ date="2019-01-21T11:57:07Z"
+ content="""
+Import tree won't help here. Actually I've got the same problem on one of my machines. I'm currently using a script that imports a bunch of files and moves them to the remote, then imports some more files and so on. It's quite cumbersome, to be honest. So yes, I'd appreciate `git annex import --to <remote>` as well. (Same with `git annex move --from remote-a --to remote-b` actually.)
+"""]]
diff --git a/doc/todo/add_import_--to_command/comment_3_f393450ae2daa14e1e7008db2b3c7dc8._comment b/doc/todo/add_import_--to_command/comment_3_f393450ae2daa14e1e7008db2b3c7dc8._comment
new file mode 100644
index 0000000000..fcc2eddd14
--- /dev/null
+++ b/doc/todo/add_import_--to_command/comment_3_f393450ae2daa14e1e7008db2b3c7dc8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-01-22T15:39:49Z"
+ content="""
+Import tree + move --from --to would be equivilant functionality to import --to.
+The directory you want to import "to" would be set up as a directory
+special remote and import tree used on it.
+
+However, it seems to me that if I wanted to accomplish this today, I'd
+simply make a clone of my git-annex repository onto the external drive,
+move the files I want into that clone (a cheap operation as it's the same
+drive), and `git annex copy --to s3-remote`
+"""]]
diff --git a/doc/todo/add_import_--to_command/comment_4_4a30627ac78b32911604c3377b958cd0._comment b/doc/todo/add_import_--to_command/comment_4_4a30627ac78b32911604c3377b958cd0._comment
new file mode 100644
index 0000000000..20d03ae2c1
--- /dev/null
+++ b/doc/todo/add_import_--to_command/comment_4_4a30627ac78b32911604c3377b958cd0._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-11-19T16:58:06Z"
+ content="""
+Since git-annex does now support importtree from directory special remotes,
+you can almost get what you said you want by:
+
+	git annex initremote usb-drive type=directory directory=/mnt/usb-drive/myfiles \
+		exporttree=yes importtree=yes encryption=none
+
+Then `git annex import master --from usb-drive` will import the files
+into a usb-drive/master branch that you can merge. And you can run it
+repeatedly to import new and changed files from the directory.
+
+So then you have the files sitting in a special remote like you wanted.
+Namely the directory special remote on the USB drive. Only problem is that
+importing the files does also copy them into the git-annex repo. So you'd
+have to drop the files again, assuming you had disk space for them all
+to begin with.
+
+I wonder, if it were possible to import the files without add their content
+to the repo you ran the import from, leaving them on the special remote,
+would that meet your use case? That seems like something it would be
+possible to add.
+
+It would still probably have to copy the file into the local repo, in order
+to hash it, and then just delete the content from the local repo. Of course
+when the file is in a directory on the local system, that's not strictly
+necessary; it could do the hashing of the file in place. But that would
+need an extension to the special remote API to hash a file.
+
+But like I said in my other comment, I'd just clone my git-annex repo onto the
+drive and add the files to the repo there. Avoids all this complication.
+You'd need to provide a good justification for why you can't do that for
+me to pursue this any further.
+
+(As far as adding a --to switch to import, [[transitive_transfers]]
+discusses this kind of thing, and some issues with implementing that.)
+"""]]
diff --git a/doc/todo/add_import_--to_command/comment_5_549edb19b222bf4bd1b87aceba007005._comment b/doc/todo/add_import_--to_command/comment_5_549edb19b222bf4bd1b87aceba007005._comment
new file mode 100644
index 0000000000..ce52fec86e
--- /dev/null
+++ b/doc/todo/add_import_--to_command/comment_5_549edb19b222bf4bd1b87aceba007005._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-06-23T16:38:50Z"
+ content="""
+It's now possible to `git-annex import --no-content --from
+a-directory-special-remote`. So then you have the files sitting on the
+external drive and not filling up the git repository.
+
+And `git-annex copy --from foo --to bar` is also supported, so you can
+use that to send the files over the S3 or wherever.
+
+So, I think this todo can be closed.
+"""]]
diff --git a/doc/todo/add_import_tree_to_external_special_remote_protocol.mdwn b/doc/todo/add_import_tree_to_external_special_remote_protocol.mdwn
new file mode 100644
index 0000000000..5c597df861
--- /dev/null
+++ b/doc/todo/add_import_tree_to_external_special_remote_protocol.mdwn
@@ -0,0 +1,28 @@
+The external special remote protocol supports export tree, but not yet
+import tree. There is a draft protocol extension in
+[[design/external_special_remote_protocol/export_and_import_appendix]].
+
+My main concern about this is, will external special remotes pick good
+ContentIdentifiers and will they implement STOREEXPORTEXPECTED
+in a way that avoids race conditions (at least as well as git does)?
+See [the original import tree todo for discussion about the race conditions](http://source.git-annex.branchable.com/?p=source.git;a=blob;f=doc/todo/import_tree.mdwn;hb=a9db0a505592bf7ee1db24c45b19ebbc96066a55).
+
+Mistakes in these things can result in data loss, and it's
+rather subtle stuff. --[[Joey]]
+
+What I'd like to do is implement this in concert with someone who is
+implementing a special remote that uses it. So we can iterate on the
+protocol as needed to make it better. --[[Joey]]
+
+> @mih expressed some interest in this in [a comment](https://git-annex.branchable.com/design/external_special_remote_protocol/export_and_import_appendix/#comment-d0cffbe55870a469052ebb7ed36f8300)
+> so maybe him? --[[Joey]]
+
+I do want to implement this though, assuming it turns out to be feasible
+for people to implement it despite its complexity, so I'm tagging this confirmed.
+
+(This is probably a prerequisite for the [[importtree_only_remotes]] idea,
+although it might make sense to implement that as a simpler protocol
+extension.)
+
+[[!tag confirmed]]
+[[!tag projects/datalad/potential]]
diff --git a/doc/todo/add_limit_to_matching_options.mdwn b/doc/todo/add_limit_to_matching_options.mdwn
new file mode 100644
index 0000000000..7bcdce2a7c
--- /dev/null
+++ b/doc/todo/add_limit_to_matching_options.mdwn
@@ -0,0 +1,16 @@
+It would be really useful to have something like the limit option in SQL for matching options.
+
+Here is a scenario where it makes sense, and which actually comes up for me quite a bit:
+
+You have 2TB of files, where none of the files are larger than 1TB. You want to transfer the entire 2TB annex to another location (we'll call it target), but you can only do it with a single 1TB hard drive.
+
+By being able to git annex copy . -t <1tb drive> --in=here --not --in=target --limit=1TB, I can ensure that an arbitrary group of any files, not to exceed 1TB, is copied to my transport drive. After I move the files from the transport drive to the target repo, I can repeat the process with the next 1TB.
+
+I don't care which of the specific files are copied, I just want a subset of them copied, because they are part of a batch transfer job.
+
+I often transfer files via mediums that have transfer limits, but I am eventually going to transfer all of them, so I don't have to care which ones are selected.
+
+
+Currently, I've been using tricks to select a subset of the files, such as a range of file-sizes.
+
+[[!tag needsthought]]
diff --git a/doc/todo/add_limit_to_matching_options/comment_1_2358e0503ca6c65644ca68c0ebd89723._comment b/doc/todo/add_limit_to_matching_options/comment_1_2358e0503ca6c65644ca68c0ebd89723._comment
new file mode 100644
index 0000000000..b9100e70a0
--- /dev/null
+++ b/doc/todo/add_limit_to_matching_options/comment_1_2358e0503ca6c65644ca68c0ebd89723._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-11-28T15:33:57Z"
+ content="""
+Well, git-annex will avoid copying files to the drive once it's full, so
+you don't really need to tell it the size of the drive.
+
+It seems to me that your command would work without any new --limit option.
+"""]]
diff --git a/doc/todo/add_limit_to_matching_options/comment_2_187a47171265eeaf2aa144beed53bfc3._comment b/doc/todo/add_limit_to_matching_options/comment_2_187a47171265eeaf2aa144beed53bfc3._comment
new file mode 100644
index 0000000000..39afd40617
--- /dev/null
+++ b/doc/todo/add_limit_to_matching_options/comment_2_187a47171265eeaf2aa144beed53bfc3._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="toh_corpora"
+ avatar="http://cdn.libravatar.org/avatar/c4265d106fd775ab35231ea3f9696cb0"
+ subject="comment 2"
+ date="2018-11-28T15:56:54Z"
+ content="""
+Thanks for your reply Joey.
+
+There are other times when I want to limit that size of a query, besides when the filesystem of the target device is exhausted.
+
+I would be able to minimize the number of round trips required for transporting two or more repos on one hard drive. It would be great to have more control over the amount of space used on the remote, via the amount of space that is passed to copy or move.
+
+Beyond that, what would be really cool, is to have something like --limitfiles and --limitsize, to constrain a query by the total number of files, or the total size, especially for certain cloud-based services. That is, cap the query to return a total number of files, regardless of size, along with --greaterthan and --lessthan.
+
+
+"""]]
diff --git a/doc/todo/add_limit_to_matching_options/comment_3_cfff69317903879bba2a9a9de1e73a8e._comment b/doc/todo/add_limit_to_matching_options/comment_3_cfff69317903879bba2a9a9de1e73a8e._comment
new file mode 100644
index 0000000000..1d9600705b
--- /dev/null
+++ b/doc/todo/add_limit_to_matching_options/comment_3_cfff69317903879bba2a9a9de1e73a8e._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-12-03T17:09:03Z"
+ content="""
+So you want this limit option to make git-annex stop processing files once
+the files it's processed sum up to a given size, or after some number of
+files are transferred. Similar to --time-limit then.
+
+It seems this would need to only count a file once git-annex decides to
+do something with it. Otherwise, a `git annex copy` would count all the
+files that are already on the drive as it scans through them, and stop too
+soon.
+
+So this seems to need something that sits in between the seek stage and the
+perform stage, that can see the key that is being processed. There's not
+currently a way to do that, it would need changes to the Command types,
+or would need to be manually inserted into every command that should do
+this. Either way, needs some changes to be made to every command in
+git-annex to implement.
+
+Hmm, if it's limited to commands that transfer files, it could be hooked
+into Annex.Transfer instead; that does know the key being transferred.
+It could refuse to do the transfer and report a failure, and git-annex
+would then display failures to transfer every file after the limit. (I'm
+not very comfortable making that interface throw an exception and anyway
+users of it may already catch transfer exceptions.)
+"""]]
diff --git a/doc/todo/add_maxextensionlength_to_git-annex-config.mdwn b/doc/todo/add_maxextensionlength_to_git-annex-config.mdwn
new file mode 100644
index 0000000000..5aad71840a
--- /dev/null
+++ b/doc/todo/add_maxextensionlength_to_git-annex-config.mdwn
@@ -0,0 +1 @@
+To the list of config settings applied to all clones of a repo, add `annex.maxextensionlength`.
diff --git a/doc/todo/add_maxextensionlength_to_git-annex-config/comment_1_df1113eb2b0b9cf6c13b1e8ea0995f1d._comment b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_1_df1113eb2b0b9cf6c13b1e8ea0995f1d._comment
new file mode 100644
index 0000000000..3d78008e41
--- /dev/null
+++ b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_1_df1113eb2b0b9cf6c13b1e8ea0995f1d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="jkniiv@b330fc3a602d36a37a67b2a2d99d4bed3bb653cb"
+ nickname="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/419f2eee8b0c37256488fabcc2737ff2"
+ subject="comment 1"
+ date="2021-07-06T19:49:07Z"
+ content="""
+I wholeheartedly agree that this could be useful. On that note I (meekly) query why not put `annex.backend`
+also in the set of configs stored in the git-annex branch? Personally I have a script/command file called
+`_scripts/init-git-annex.cmd` checked into the repo so that after cloning I can easily `git config` any settings
+I need and also `git annex init` the clone by running said script. In OOP terminology it works as a kind
+of constructor, if you will. :)
+
+"""]]
diff --git a/doc/todo/add_maxextensionlength_to_git-annex-config/comment_2_580ed143221abbcced40f020b849cc27._comment b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_2_580ed143221abbcced40f020b849cc27._comment
new file mode 100644
index 0000000000..b383248c30
--- /dev/null
+++ b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_2_580ed143221abbcced40f020b849cc27._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-07-12T14:58:34Z"
+ content="""
+It's already possible to configure the backend via .gitattributes;
+that is strictly better than a `git-annex config` setting for it would be:
+It allows selecting different backends in for different types of files, and
+even in different branches.
+
+Anyway, this todo can only be about one thing, and that's
+maxextensionlength, not backends or whatever other suggestions might have
+later be added to it.
+"""]]
diff --git a/doc/todo/add_maxextensionlength_to_git-annex-config/comment_3_6bcf92e8cc78b47ed42f58a610e27d76._comment b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_3_6bcf92e8cc78b47ed42f58a610e27d76._comment
new file mode 100644
index 0000000000..6b0ae05fed
--- /dev/null
+++ b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_3_6bcf92e8cc78b47ed42f58a610e27d76._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-07-12T15:05:57Z"
+ content="""
+I went back and looked at why this config was added in the first place, and
+it seemed to be partly to support extensions of length 5, but also partly
+someone wanted to configure it to something large, so the entire filename
+(or a lot of it) was treated as an "extension" and appeared in a key!
+
+It should probably be hard capped to something sensible. Setting something
+wacky like that locally is shooting your own foot, but once it becomes a global
+setting, you can make other users shoot their feet.
+
+I can see how, if a repo's domain includes files that have a longer than
+usual extension, it would be useful to set this globally. But I also
+have to push back against adding global configs, because the general
+trend is toward users requesting a global config for *everything*, which
+is not where I want git-anenx to end up. global configs can be an *imposition*
+on other users of the repository, and also risk slowing git-annex down.
+"""]]
diff --git a/doc/todo/add_maxextensionlength_to_git-annex-config/comment_4_f0894e2797e1188bdf4bdc09bd10553e._comment b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_4_f0894e2797e1188bdf4bdc09bd10553e._comment
new file mode 100644
index 0000000000..b43a05840e
--- /dev/null
+++ b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_4_f0894e2797e1188bdf4bdc09bd10553e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="about maxextensionlength"
+ date="2021-07-12T15:38:22Z"
+ content="""
+>the entire filename (or a lot of it) was treated as an \"extension\" and appeared in a key
+
+What problems do you see this causing, other than some possible loss of deduplication?
+
+>It should probably be hard capped
+
+>global configs can be an imposition on other users
+
+Hard caps are the ultimate global configs ;)
+
+"""]]
diff --git a/doc/todo/add_maxextensionlength_to_git-annex-config/comment_5_9499ecd6136102803f1d6691c03e6b20._comment b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_5_9499ecd6136102803f1d6691c03e6b20._comment
new file mode 100644
index 0000000000..cd6a017f34
--- /dev/null
+++ b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_5_9499ecd6136102803f1d6691c03e6b20._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="jkniiv@b330fc3a602d36a37a67b2a2d99d4bed3bb653cb"
+ nickname="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/419f2eee8b0c37256488fabcc2737ff2"
+ subject="comment 5"
+ date="2021-07-12T22:48:25Z"
+ content="""
+_joey:_
+> It's already possible to configure the backend via .gitattributes;
+
+Thanks for reminding me about that option. I shall use the .gitattributes trick to shorten
+my init-git-annex.cmd script. :)
+
+_joey:_
+> It should probably be hard capped to something sensible.
+
+As long as that sensible setting is >= 8 as that is a lower bound is what I use. I tend to think
+that at most two extension components is what you usually need for identifying a file's \"type\" (think \".tar.gz\").
+As for the length of a component, Windows (and probably other modern desktop environments) produces
+for instance such extensions as \".search-ms\" (9 characters excluding the dot) for saved Explorer searches.
+I don't think that's an unreasonably long extension component for this use case. For more standard file types
+to be exchanged via public methods maybe at most five characters per component should be the maximum. However,
+git-annex should be lenient towards what it accepts as long as that is reasonably possible to uphold. IMHO, a practical
+upper limit for annex.maxextensionlength could be 16 to 20 characters.
+
+"""]]
diff --git a/doc/todo/add_maxextensionlength_to_git-annex-config/comment_6_9ff852c12549985f6e88bd2316a69def._comment b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_6_9ff852c12549985f6e88bd2316a69def._comment
new file mode 100644
index 0000000000..26d2a042d6
--- /dev/null
+++ b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_6_9ff852c12549985f6e88bd2316a69def._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="(partial) filenames in keys"
+ date="2021-07-13T15:13:27Z"
+ content="""
+WOM and URL keys [[already contain|backends]] filenames or parts of filenames.  Docs warn that too-long keys might cause issues on Windows, but also that 512 and 384 length hashes already have that problem.  So it seems that permitting larger `maxextensionlength` should not add new issues?
+"""]]
diff --git a/doc/todo/add_maxextensionlength_to_git-annex-config/comment_7_2b02c97fc9cfdb30d89676ec82760538._comment b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_7_2b02c97fc9cfdb30d89676ec82760538._comment
new file mode 100644
index 0000000000..49962ccb8e
--- /dev/null
+++ b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_7_2b02c97fc9cfdb30d89676ec82760538._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-04-04T17:53:39Z"
+ content="""
+[[need_a_clear_criteria_for_adding_git-annex-config_settings]] will need to
+be resolved before I do anything about this.
+"""]]
diff --git a/doc/todo/add_maxextensionlength_to_git-annex-config/comment_8_6302aa8c3ff1f1096bc9978dd6407744._comment b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_8_6302aa8c3ff1f1096bc9978dd6407744._comment
new file mode 100644
index 0000000000..25c9f7e9ad
--- /dev/null
+++ b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_8_6302aa8c3ff1f1096bc9978dd6407744._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="maxextensionlength"
+ date="2022-04-08T19:13:38Z"
+ content="""
+What about adding `annex.maxextensionlength` to `.gitattributes`, rather than to `git-annex-config`?  This would solve the use case of `.fastq.gz` files common in bioinformatics repos.
+"""]]
diff --git a/doc/todo/add_maxextensionlength_to_git-annex-config/comment_9_5027255cc1b0dec41e315df8472fe60e._comment b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_9_5027255cc1b0dec41e315df8472fe60e._comment
new file mode 100644
index 0000000000..541fbd34d7
--- /dev/null
+++ b/doc/todo/add_maxextensionlength_to_git-annex-config/comment_9_5027255cc1b0dec41e315df8472fe60e._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-04-19T16:42:16Z"
+ content="""
+Well, maxextensionlength does at least have some connection to the
+filename, which does point at it being somewhat suitable for
+gitattributes. Eg, you might want to allow files with one long extension
+to include it all, but not others.
+
+The current implementation uses a single git check-attr process which
+reports on all 4 currently supported git-annex attributes for every query.
+So adding a new attribute also slows down queries for all the rest by some
+amount. To quantify that, I did a benchmark, modifiying git-annex to 
+request (but ignore) an additional attribute. git-annex add of 10000
+small files did not slow down by any measurable amount due to that change.
+(1:53.78 before the change and 1:52.00 afterwards actually, so the
+difference is lost in the noise)
+
+An attribute does impose more overhead than git-annex
+config though, since it has to be queried for every file rather than one
+time. I benchmarked the overhead of checking annex.maxextensionlength
+once per file added, over 10000 files. It slowed down by around 5%.
+
+git-annex add already queries the annex.largefiles attribute once per file.
+So, if it could also query annex.maxextensionlength at the same time, 
+it would be free to support the attribute. And then I'd certianly be in
+favor of it. This would need some nontrivial refactoring of the code.
+"""]]
diff --git a/doc/todo/add_option_to_disable_fsck_upgradable_key_warnings.mdwn b/doc/todo/add_option_to_disable_fsck_upgradable_key_warnings.mdwn
new file mode 100644
index 0000000000..9c3d17e46f
--- /dev/null
+++ b/doc/todo/add_option_to_disable_fsck_upgradable_key_warnings.mdwn
@@ -0,0 +1,3 @@
+Currently [[`git-annex-fsck`|git-annex-fsck]] gives a warning for all my files stored with MD5 keys that they can be upgraded to the more secure SHA256: `Can be upgraded to an improved key format. You can do so by running: git annex migrate`.  In my case the key choice is deliberate, so it would be good if this warning could be disabled, to prevent it from drowning out more serious ones.
+
+[[!tag moreinfo]]
diff --git a/doc/todo/add_option_to_disable_fsck_upgradable_key_warnings/comment_1_f91174aef6f7a5a41fb9b9b54249be1c._comment b/doc/todo/add_option_to_disable_fsck_upgradable_key_warnings/comment_1_f91174aef6f7a5a41fb9b9b54249be1c._comment
new file mode 100644
index 0000000000..45c68dbb9a
--- /dev/null
+++ b/doc/todo/add_option_to_disable_fsck_upgradable_key_warnings/comment_1_f91174aef6f7a5a41fb9b9b54249be1c._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-09T16:24:11Z"
+ content="""
+git-annex fsck only displays that warning when annex.securehashesonly=true.
+That is not a default setting.
+
+Seems to me, setting that when your repo legitimately uses insecure
+hashes will cause other problems, eg git-annex will refuse to transfer
+content using insecure hashes since it cannot verify it.
+So, you could just unset that.
+
+I suppose, if you've migrated away from those hashes, but still have old
+objects using them present in the annex, and turned on
+annex.securehashesonly=true, fsck --all will warn about the objects.
+If that's the problem, it might make sense to disable the warning for
+--all and --key.
+"""]]
diff --git a/doc/todo/add_option_to_disable_fsck_upgradable_key_warnings/comment_2_eb2a5ee55df954b243bf0ea87801fbce._comment b/doc/todo/add_option_to_disable_fsck_upgradable_key_warnings/comment_2_eb2a5ee55df954b243bf0ea87801fbce._comment
new file mode 100644
index 0000000000..648a105cbc
--- /dev/null
+++ b/doc/todo/add_option_to_disable_fsck_upgradable_key_warnings/comment_2_eb2a5ee55df954b243bf0ea87801fbce._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="anatoly.sayenko@880a118acc67f3244b406a2700f0556b2f10672c"
+ nickname="anatoly.sayenko"
+ avatar="http://cdn.libravatar.org/avatar/f64c8f28fe60aacbed60e4adaf301599"
+ subject="migration warning still present after migration "
+ date="2021-04-18T09:37:09Z"
+ content="""
+Hi, I'm trying to get rid of that warning by migrating my repo to SHA256E, as the messages during fsck suggest, but right after the migration I still get the warning.
+For example:  
+
+    $ git annex fsck study/sport/kite/kiteboarding_progression_beginner.avi
+    fsck study/sport/kite/kiteboarding_progression_beginner.avi (checksum...) 
+    study/sport/kite/kiteboarding_progression_beginner.avi: Can be upgraded to an improved key format. You can do so by running: git annex migrate --backend=SHA256E study/sport/kite/kiteboarding_progression_beginner.avi
+    ok
+    (recording state in git...)
+
+    $ git annex migrate --backend=SHA256E study/sport/kite/kiteboarding_progression_beginner.avi
+    migrate study/sport/kite/kiteboarding_progression_beginner.avi (checksum...) (checksum...) ok
+    (recording state in git...)
+
+    $ git annex fsck study/sport/kite/kiteboarding_progression_beginner.avi
+    fsck study/sport/kite/kiteboarding_progression_beginner.avi (checksum...) 
+    study/sport/kite/kiteboarding_progression_beginner.avi: Can be upgraded to an improved key format. You can do so by running: git annex migrate --backend=SHA256E study/sport/kite/kiteboarding_progression_beginner.avi
+    ok
+
+    $ ls -la study/sport/kite/kiteboarding_progression_beginner.avi
+    lrwxrwxrwx 1 tsayen tsayen 211 Apr 18 11:27 study/sport/kite/kiteboarding_progression_beginner.avi -> ../../../.git/annex/objects/5b6/SHA256E-s1802139648--3d86059c3b74145c7085467ff4661f2ab248daa4a9845ddb9228766dc8f2720e.avi/SHA256E-s1802139648--3d86059c3b74145c7085467ff4661f2ab248daa4a9845ddb9228766dc8f2720e.avi
+    (recording state in git...)
+
+    $ git annex unused
+    unused . (checking for unused data...) ok
+
+
+I've tried squashing the entire history on master to 1 commit, removing all remotes, running `git annex forget` and rerunnig `migrate`, but it didn't help.
+Could you suggest where should I look for that old key that keeps this message popping up? I have the same situation with all my annex repos.
+I'm using version 8.20200226
+
+
+"""]]
diff --git a/doc/todo/add_option_to_disable_fsck_upgradable_key_warnings/comment_3_3b9f1387cc5de5d0bce5fee5fff91002._comment b/doc/todo/add_option_to_disable_fsck_upgradable_key_warnings/comment_3_3b9f1387cc5de5d0bce5fee5fff91002._comment
new file mode 100644
index 0000000000..4be975ecea
--- /dev/null
+++ b/doc/todo/add_option_to_disable_fsck_upgradable_key_warnings/comment_3_3b9f1387cc5de5d0bce5fee5fff91002._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-06-25T17:39:41Z"
+ content="""
+Actually, fsck never warns about upgrading MD5 to any SHA hash.
+The message you are seeing is about upgrading something already using
+SHA256E to an improved version. The `--backend=SHA256E` displayed by
+git-annex fsck comes from the backend it sees the file is already using.
+
+The most likely reason a SHA256E file would need migration would be if it
+has non-alphanumeric characters in its extension. There are some other
+historical problems that it migrates to solve as well. A `git diff` of the
+changes that `git annex migrate` made would tell what it did the migration for.
+
+I don't know why fsck then wants to migrate it again. It only looks at the
+file staged in git. When I stage that same symlink here, it does not want
+to migrate it.
+
+Since your git-annex version is over a year out of date, upgrading to the
+current version and checking if it still has the problem is the first step.
+
+(You also seem to have some unusual configuration of your repository, eg
+annex.tune.objecthash1=true and annex.tune.objecthashlower=true ... 
+is that right?)
+"""]]
diff --git a/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn b/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn
new file mode 100644
index 0000000000..3cc20d72a4
--- /dev/null
+++ b/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn
@@ -0,0 +1,22 @@
+I thought that whereis command would report only based on the knowledge annex has locally in git-annex branch, but apparently it is trying to query for information even in --fast mode:
+
+[[!format sh """
+$> git annex whereis --fast bold.nii.gz
+yoh@dat....
+Permission denied (publickey,password).
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+whereis bold.nii.gz 
+(2 copies) 
+  	899f0347-0888-48ef-91b6-bac213ca8cef -- [datalad-archives]
+   	c8bd3d05-33d4-4b59-9d53-ca7efbdcdd13 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/openfmri/ds000001 [here]
+
+  datalad-archives: dl+archive:MD5E-s2527262329--bd3ea399057c529b37b09dcecec1ca60.0raw.tgz/ds001_R1.1.0/sub001/BOLD/task001_run001/bold.nii.gz#size=47241449
+
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+Was [[done]] by [[Joey]] as of 6.20160524+gitg2b7b2c4-1~ndall+1
diff --git a/doc/todo/add_sftp_special_remote.mdwn b/doc/todo/add_sftp_special_remote.mdwn
new file mode 100644
index 0000000000..b25f294114
--- /dev/null
+++ b/doc/todo/add_sftp_special_remote.mdwn
@@ -0,0 +1,25 @@
+A sftp special remote would be nice because gpg operations could be
+pipelined to the network transfer, not requiring the creation of a full
+file to disk with gpg before the network transmission, as it happens with
+the rsync special remote.
+
+That's assuming a sftp library; the sftp command wouldn't support that.
+<http://hackage.haskell.org/package/libssh2> has support for sftp, using
+the C libssh2. However, it does not integrate with ssh-agent, and
+it has two different entry points for authentication with a ssh key
+and with a password, and this would leave git-annex to somehow decide which
+method to use, and somehow remembering the ssh password or prompting for it
+each time. That seems suboptimal.
+
+Driving the `sftp` command is also suboptimal because there would be a trafeoff
+between reusing a single sftp session, which would prevent sftp from
+displaying progress (it doesn't when stdout is not a tty), and running sftp
+repeatedly (though ssh connection caching helps some with that).
+
+> Another reason to build this is that sftp has a `SFTP_FXP_STAT`
+> that can get disk free space information. "echo df | sftp user@host"
+> exposes this, when available. Some sftp servers can be locked down
+> so that the user can't run git-annex on them, so that could be the only
+> way to get diskreserve working for such a remote. --[[Joey]]
+
+[[!tag confirmed]]
diff --git a/doc/todo/add_sftp_special_remote/comment_1_28c98e879c16f56da2a89ed9d50e4398._comment b/doc/todo/add_sftp_special_remote/comment_1_28c98e879c16f56da2a89ed9d50e4398._comment
new file mode 100644
index 0000000000..e7fb49bf5a
--- /dev/null
+++ b/doc/todo/add_sftp_special_remote/comment_1_28c98e879c16f56da2a89ed9d50e4398._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Grothausmann.Roman@343b033fef650d362015d5593ec935121340e082"
+ nickname="Grothausmann.Roman"
+ avatar="http://cdn.libravatar.org/avatar/7883b2b02c31cc2b5e8672cfea4ec9da"
+ subject="Up-vote for sftp special remote"
+ date="2019-02-13T12:11:05Z"
+ content="""
+I'd really welcome an __sftp special remote__ because SFTP it is the only officially allowed way for our institution to exchange data with external collaborators and I had no luck using the [gvfs](https://github.com/grawity/code/blob/master/net/git-annex-remote-gvfs) approach. 
+
+Even without an sftp special remote, it would be great to have some short walkthrough how to use SFTP with git-annex (if SFTP is currently actually possible with e.g. gvfs).
+
+"""]]
diff --git a/doc/todo/add_sftp_special_remote/comment_2_1fcefc50041b363a86f596f8d4121611._comment b/doc/todo/add_sftp_special_remote/comment_2_1fcefc50041b363a86f596f8d4121611._comment
new file mode 100644
index 0000000000..b60c1effdd
--- /dev/null
+++ b/doc/todo/add_sftp_special_remote/comment_2_1fcefc50041b363a86f596f8d4121611._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-02-13T16:46:25Z"
+ content="""
+This can be implemented as an external special remote in Python with a combination of https://github.com/althonos/fs.sshfs and  https://github.com/Lykos153/AnnexRemote .  Implementing using https://www.pyfilesystem.org/ would make a remote that works with a range of filesystems ( https://www.pyfilesystem.org/page/index-of-filesystems/ ).   I don't have time right now but maybe you can try.
+"""]]
diff --git a/doc/todo/add_testremote_cleanup.mdwn b/doc/todo/add_testremote_cleanup.mdwn
new file mode 100644
index 0000000000..6d4cb4119c
--- /dev/null
+++ b/doc/todo/add_testremote_cleanup.mdwn
@@ -0,0 +1 @@
+If [[`git-annex-testremote`|git-annex-testremote]] fails midway for some reason, it leaves many files on the remote that were used for the test.  Maybe, add a command to clean up / drop these files?  Or can an existing command do that?
diff --git a/doc/todo/add_testremote_cleanup/comment_1_9dc28d46dfcd693def4cbb3837de55e0._comment b/doc/todo/add_testremote_cleanup/comment_1_9dc28d46dfcd693def4cbb3837de55e0._comment
new file mode 100644
index 0000000000..4da49321e1
--- /dev/null
+++ b/doc/todo/add_testremote_cleanup/comment_1_9dc28d46dfcd693def4cbb3837de55e0._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-24T17:05:50Z"
+ content="""
+Like the man page for this command says, it's best to make a new remote for
+testing purposes, not use a production one.
+
+I think that a simple improvement to it would be for it to generate the
+same test keys every time. Then if it failed once or was interrupted or
+the remote was buggy, once that got fixed the same command could be run
+again, and would clean up the test keys that were earlier stored on the
+remote.
+
+It's generating random data and a key from that,
+but a predictable random data would not impair the test really.
+Although testExportTree currently starts with a test that might fail
+if the key is already present in the remote.
+"""]]
diff --git a/doc/todo/add_testremote_cleanup/comment_2_a87de50ab7c39d955d5c1f6a1c51f761._comment b/doc/todo/add_testremote_cleanup/comment_2_a87de50ab7c39d955d5c1f6a1c51f761._comment
new file mode 100644
index 0000000000..809b584699
--- /dev/null
+++ b/doc/todo/add_testremote_cleanup/comment_2_a87de50ab7c39d955d5c1f6a1c51f761._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-08-24T17:15:06Z"
+ content="""
+Problem with that idea: testremote makes variants of the remote with
+shared encryption enabled. So the content being stored on the remote is not
+only random, but is encrypted with a random key. It would have to
+initialize the encrypted remote with a fixed encryption key. This would
+need some significant changes to accomplish.
+"""]]
diff --git a/doc/todo/add_testremote_cleanup/comment_3_976fd7b1db867bf5fe785e0d32acddcb._comment b/doc/todo/add_testremote_cleanup/comment_3_976fd7b1db867bf5fe785e0d32acddcb._comment
new file mode 100644
index 0000000000..da14e2a60b
--- /dev/null
+++ b/doc/todo/add_testremote_cleanup/comment_3_976fd7b1db867bf5fe785e0d32acddcb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="testremote cleanup"
+ date="2022-08-28T20:15:38Z"
+ content="""
+>Like the man page for this command says, it's best to make a new remote for testing purposes, not use a production one.
+
+My fault for not re-reading the webpage.
+
+There's some value, I think, in being able to test production remotes.  There's always a chance that a test remote got configured differently than a production one, so there's more confidence from having tested the production remote.
+
+If [find/prefer keys by file extension in key](https://git-annex.branchable.com/todo/find__47__prefer_keys_by_file_extension_in_key/) could be implemented, one could delete keys matching `*.this-is-a-test-key`.
+
+
+"""]]
diff --git a/doc/todo/add_testremote_cleanup/comment_4_ef144de6384eb89a2d4caa13e6895872._comment b/doc/todo/add_testremote_cleanup/comment_4_ef144de6384eb89a2d4caa13e6895872._comment
new file mode 100644
index 0000000000..dd5be3e8ed
--- /dev/null
+++ b/doc/todo/add_testremote_cleanup/comment_4_ef144de6384eb89a2d4caa13e6895872._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-08-29T16:44:20Z"
+ content="""
+The keys used by testremote never reach the git-annex branch, so there is
+not a way to list them.
+
+What would work is to make testremote record the keys it stores to a log
+file, and then it could clean up ones from previous runs.
+"""]]
diff --git a/doc/todo/add_testremote_cleanup/comment_5_0a3c3cc6c9b4efd7a6c4cf7333f2b120._comment b/doc/todo/add_testremote_cleanup/comment_5_0a3c3cc6c9b4efd7a6c4cf7333f2b120._comment
new file mode 100644
index 0000000000..223b1fd4e5
--- /dev/null
+++ b/doc/todo/add_testremote_cleanup/comment_5_0a3c3cc6c9b4efd7a6c4cf7333f2b120._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="testremote cleanup"
+ date="2022-08-29T18:09:24Z"
+ content="""
+>What would work is to make testremote record the keys it stores to a log file, and then it could clean up ones from previous runs.
+
+Yes -- I thought to suggest that but was thinking of a file the user has to deal with, which is clumsy.  But I think you're suggesting a file somewhere under `.git/annex`, which would be a clean solution.
+"""]]
diff --git a/doc/todo/add_tests_under_concurrency.mdwn b/doc/todo/add_tests_under_concurrency.mdwn
new file mode 100644
index 0000000000..3363bd0c02
--- /dev/null
+++ b/doc/todo/add_tests_under_concurrency.mdwn
@@ -0,0 +1,3 @@
+To [[git-annex-test]] and [[git-annex-testremote]], add option to run tests under concurrency (-J).  Many possible bugs are unique to the concurrent case, and it's the case I often use.  While any bugs detected may be hard to reproduce, it's important to know _whether_ there are concurrency-related bugs.  Much of the trust in git-annex comes from its extensive test suite, but it's somewhat concerning to trust it with important data when the concurrency case is not tested at all.
+
+[[!tag unlikely]]
diff --git a/doc/todo/add_tests_under_concurrency/comment_1_9879c63f9de342b6831d5794d8f6212e._comment b/doc/todo/add_tests_under_concurrency/comment_1_9879c63f9de342b6831d5794d8f6212e._comment
new file mode 100644
index 0000000000..e332fda02a
--- /dev/null
+++ b/doc/todo/add_tests_under_concurrency/comment_1_9879c63f9de342b6831d5794d8f6212e._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-09T14:47:59Z"
+ content="""
+As the test suite is constructed, there is a single origin repository
+shared by clones used for each test case, and there are test cases that do
+eg `git annex move --from origin ; git annex move --to origin` and so would break
+other tests cases using the same origin if they were run concurrently, without it
+being an actual concurrency bug in git-annex.
+
+So parallelizing the test suite would need each test case to have its own
+isolated set of test repos. But then concurrency bugs could not be found by
+the test suite; concurrency would only possibly make it run faster.
+
+Finding concurrency bugs seems to need the test repos to contain more
+files than the two or three they now do, so that a single test case can
+run some git-annex operation concurrently on several files at once.
+
+Also, if you look at the CHANGELOG, you'll find that concurrency bugs in
+git-annex beyond the UI level are fairly rare. And I can think of only one
+concurrency bug that ever caused even theoretical data loss; it involved 3
+repos in a triangle topology all dropping the same file at the same time.
+"""]]
diff --git a/doc/todo/add_tests_under_concurrency/comment_2_3713c706c8a0689f527c4558176a7b48._comment b/doc/todo/add_tests_under_concurrency/comment_2_3713c706c8a0689f527c4558176a7b48._comment
new file mode 100644
index 0000000000..9f1feef624
--- /dev/null
+++ b/doc/todo/add_tests_under_concurrency/comment_2_3713c706c8a0689f527c4558176a7b48._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-05-09T21:07:38Z"
+ content="""
+\"Finding concurrency bugs seems to need the test repos to contain more files than the two or three\" -- it should be enough to run a concurrent operation many times on a small repo.  This will test the different possible orders of operation.  Most concurrency bugs only involve a conflict of two or three operations.
+
+Running under something like https://rr-project.org/ can be used to reliably reproduce concurrency bugs.
+
+\"I can think of only one concurrency bug that ever caused even theoretical data loss\" -- that's good.  But beyond data loss, when a complex operation fails in the middle, it can be non-trivial to figure out which parts to redo.
+"""]]
diff --git a/doc/todo/add_xxHash_backend.mdwn b/doc/todo/add_xxHash_backend.mdwn
new file mode 100644
index 0000000000..cf9143ea09
--- /dev/null
+++ b/doc/todo/add_xxHash_backend.mdwn
@@ -0,0 +1 @@
+From https://cyan4973.github.io/xxHash/ , xxHash seems much faster than md5 with comparable quality.  There's a Haskell implementation.
diff --git a/doc/todo/add_xxHash_backend/comment_1_8993f493a8b43ffda9f8e0b6d5e186ac._comment b/doc/todo/add_xxHash_backend/comment_1_8993f493a8b43ffda9f8e0b6d5e186ac._comment
new file mode 100644
index 0000000000..40e7e02f20
--- /dev/null
+++ b/doc/todo/add_xxHash_backend/comment_1_8993f493a8b43ffda9f8e0b6d5e186ac._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-06T19:30:43Z"
+ content="""
+I looked at xxHash recently. I can't seem to find benchmarks of it compared
+with other fast hashes like Blake2.
+"""]]
diff --git a/doc/todo/add_xxHash_backend/comment_2_945217badfaeba8672329d4f6ac4b8e2._comment b/doc/todo/add_xxHash_backend/comment_2_945217badfaeba8672329d4f6ac4b8e2._comment
new file mode 100644
index 0000000000..1339435f8f
--- /dev/null
+++ b/doc/todo/add_xxHash_backend/comment_2_945217badfaeba8672329d4f6ac4b8e2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-01-09T20:52:25Z"
+ content="""
+Let alone blake3, which is 5-6 times as fast as blake2 while still
+apparently being a cryptographically secure hash.
+"""]]
diff --git a/doc/todo/add_xxHash_backend/comment_3_93892ef71d40f0b10e5fdcb703faf3ad._comment b/doc/todo/add_xxHash_backend/comment_3_93892ef71d40f0b10e5fdcb703faf3ad._comment
new file mode 100644
index 0000000000..bf60981f8e
--- /dev/null
+++ b/doc/todo/add_xxHash_backend/comment_3_93892ef71d40f0b10e5fdcb703faf3ad._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-12-15T20:23:15Z"
+ content="""
+https://cyan4973.github.io/xxHash/ now includes blake2, and xxh3 is much
+faster, 28 times as fast.
+
+Would need haskell library, http://hackage.haskell.org/package/xxhash is
+out of date. It would probably not be hard to make a xxh3 haskell library,
+but I'm inclined to wait for someone who really wants it.
+
+Debian already has it in libxxhash0.
+
+Interestingly, the ghc RTS uses xxhash and recently updated to xxh3.
+https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4248
+But I don't think that's exposed to haskell code.
+"""]]
diff --git a/doc/todo/additional_git-annex-config_settings__63__.mdwn b/doc/todo/additional_git-annex-config_settings__63__.mdwn
new file mode 100644
index 0000000000..b31427ebee
--- /dev/null
+++ b/doc/todo/additional_git-annex-config_settings__63__.mdwn
@@ -0,0 +1,5 @@
+Should `annex.gitaddtoannex` and `annex.addsmallfiles` be [[`git-annex-config`|git-annex-config]] settings, given that `annex.largefiles`, `annex.dotfiles` and `annex.addunlocked` already are?
+Also, [maybe](https://git-annex.branchable.com/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/#comment-85cb4d3eac345df7b08a31ea4bd810f6) make `annex.supportunlocked` a `git-annex-config` setting as well.
+
+
+> [[rejected|done]] --[[Joey]]
diff --git a/doc/todo/additional_git-annex-config_settings__63__/comment_1_74d61d6a4412223092f468628d3f2f45._comment b/doc/todo/additional_git-annex-config_settings__63__/comment_1_74d61d6a4412223092f468628d3f2f45._comment
new file mode 100644
index 0000000000..a110770fd8
--- /dev/null
+++ b/doc/todo/additional_git-annex-config_settings__63__/comment_1_74d61d6a4412223092f468628d3f2f45._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="+1 on supportunlocked in git-annex config"
+ date="2021-07-09T15:25:53Z"
+ content="""
+supportunlocked would definitely make sense; it can help protect against users accidentally checking in a file in the wrong mode even though it doesn't fit the repo's workflows.
+
+The alternative to setting this across all repos using git-annex config, at least in my workflows, would be to set a git hook to reject pushes (to master or synced/master) that contain unlocked files, but that sounds way more complex.
+"""]]
diff --git a/doc/todo/additional_git-annex-config_settings__63__/comment_2_2973d438e8f3fda50cfb151534a8ec73._comment b/doc/todo/additional_git-annex-config_settings__63__/comment_2_2973d438e8f3fda50cfb151534a8ec73._comment
new file mode 100644
index 0000000000..b9c837ba3e
--- /dev/null
+++ b/doc/todo/additional_git-annex-config_settings__63__/comment_2_2973d438e8f3fda50cfb151534a8ec73._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="+1 on supportunlocked in git-annex config"
+ date="2021-07-09T15:26:13Z"
+ content="""
+supportunlocked would definitely make sense; it can help protect against users accidentally checking in a file in the wrong mode even though it doesn't fit the repo's workflows.
+
+The alternative to setting this across all repos using git-annex config, at least in my workflows, would be to set a git hook to reject pushes (to master or synced/master) that contain unlocked files, but that sounds way more complex.
+"""]]
diff --git a/doc/todo/additional_git-annex-config_settings__63__/comment_3_3abeddccdf5c742962b25b7dbe8fb69e._comment b/doc/todo/additional_git-annex-config_settings__63__/comment_3_3abeddccdf5c742962b25b7dbe8fb69e._comment
new file mode 100644
index 0000000000..6891dd4e89
--- /dev/null
+++ b/doc/todo/additional_git-annex-config_settings__63__/comment_3_3abeddccdf5c742962b25b7dbe8fb69e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2021-07-09T16:04:47Z"
+ content="""
+Related: [[todo/add_maxextensionlength_to_git-annex-config]]
+"""]]
diff --git a/doc/todo/additional_git-annex-config_settings__63__/comment_4_1d777383fda7c50d630e19ec1d1ade52._comment b/doc/todo/additional_git-annex-config_settings__63__/comment_4_1d777383fda7c50d630e19ec1d1ade52._comment
new file mode 100644
index 0000000000..11ad13656e
--- /dev/null
+++ b/doc/todo/additional_git-annex-config_settings__63__/comment_4_1d777383fda7c50d630e19ec1d1ade52._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-07-12T14:49:12Z"
+ content="""
+annex.supportunlocked is documented to be about avoiding
+extra work needed to support unlocked files, and not
+about preventing them from being added to a branch.
+
+In general, I do not want to add global config settings for every single
+git config setting. So if your only rartionalle for adding global configs
+is that other global configs that are somewhat related exist, that is not a
+compelling reason to me.
+"""]]
diff --git a/doc/todo/additional_git-annex-config_settings__63__/comment_5_ba2cbf8dcf14a1d0b20621b48b8e8600._comment b/doc/todo/additional_git-annex-config_settings__63__/comment_5_ba2cbf8dcf14a1d0b20621b48b8e8600._comment
new file mode 100644
index 0000000000..4bfab326ab
--- /dev/null
+++ b/doc/todo/additional_git-annex-config_settings__63__/comment_5_ba2cbf8dcf14a1d0b20621b48b8e8600._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 5"
+ date="2021-07-12T15:30:25Z"
+ content="""
+>I do not want to add global config settings for every single git config setting
+
+Of course.  Just the settings that reflect the nature of the repo data and the intended usage processes.
+E.g. I want to be able to enforce that a repo be locked-files-only.  Or to set `maxextensionlength` based on the
+fact that the repo stores `.fastq.gz` files.
+
+>annex.supportunlocked is documented to be about avoiding extra work needed to support unlocked files, and not about preventing them from being added to a branch
+
+To me it seems more natural to have it prevent the addition of unlocked files, and be a global setting.
+"""]]
diff --git a/doc/todo/additional_git-annex-config_settings__63__/comment_6_4ec0261f3b8bc6d2492fa3dabb0121e5._comment b/doc/todo/additional_git-annex-config_settings__63__/comment_6_4ec0261f3b8bc6d2492fa3dabb0121e5._comment
new file mode 100644
index 0000000000..820de1eddb
--- /dev/null
+++ b/doc/todo/additional_git-annex-config_settings__63__/comment_6_4ec0261f3b8bc6d2492fa3dabb0121e5._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-07-12T15:42:52Z"
+ content="""
+Almost anything can be argued to reflect the nature of some repo in some way.
+That's not a useful criteria.
+
+And the same could be argued about many git configs, and of course they
+cannot be set globally, and noone is bothered much by this, because we can
+all arrange for git configs to be set after cloning a repo.
+
+I don't know what the right criteria is, but I do know I don't want to
+force users to have to worry about overriding every possible config locally
+because it's been set globally. git-annex should not behave in a near infinity
+of different ways in clones of different repos, because that would make its
+starting behavior impossible to understand.
+
+So the more there are requests for more global configs, the more it seems
+like adding any global configs, without a strong criteria, is not a good
+idea.
+
+Some global configs that do make sense are numcopies and required copies
+settings, because those values need to be coordinated globally to make sure
+enough copies are preserved. Similarly, preferred content because one
+repo needs to know what is preferred content of another repo. And I think
+annex.securehashesonly makes sense as a global, to avoid adding files
+with insecure hashes that would then not be accessible in repos with
+that config set. annex.largefiles mostly makes sense because .gitattributes
+has a whitespace problem which it avoids, and it's similar to using
+.gitattributes (although not identical). It feels on the edge.
+
+annex.synccontent etc are explicitly about changing the default behavior
+of a command. At the moment I feel like they were a bad idea.
+"""]]
diff --git a/doc/todo/additional_git-annex-config_settings__63__/comment_7_c1768ab8568c8e58525ed40e76cc13f2._comment b/doc/todo/additional_git-annex-config_settings__63__/comment_7_c1768ab8568c8e58525ed40e76cc13f2._comment
new file mode 100644
index 0000000000..10d506ec08
--- /dev/null
+++ b/doc/todo/additional_git-annex-config_settings__63__/comment_7_c1768ab8568c8e58525ed40e76cc13f2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 7"
+ date="2021-07-13T03:05:45Z"
+ content="""
+Realized that for the use case I was thinking of -- setting repo-wide policies such as locked-files-only -- git-annex-config isn't right, since the value can be changed by any clone.  For that use case, have to configure hooks/triggers on the central repo to reject pull requests that break the policy.
+"""]]
diff --git a/doc/todo/additional_git-annex-config_settings__63__/comment_8_845a504ea9f038a19a21d8a985585b2b._comment b/doc/todo/additional_git-annex-config_settings__63__/comment_8_845a504ea9f038a19a21d8a985585b2b._comment
new file mode 100644
index 0000000000..777399c181
--- /dev/null
+++ b/doc/todo/additional_git-annex-config_settings__63__/comment_8_845a504ea9f038a19a21d8a985585b2b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-04-04T17:54:33Z"
+ content="""
+I have opened a new todo,
+[[need_a_clear_criteria_for_adding_git-annex-config_settings]].
+
+I am going to close this one, because I'm certianly not adding a bunch of
+configs listed here without that crieria.
+"""]]
diff --git a/doc/todo/addurl_--raw-except_REMOTEs__63__.mdwn b/doc/todo/addurl_--raw-except_REMOTEs__63__.mdwn
new file mode 100644
index 0000000000..a7f8cbc3d1
--- /dev/null
+++ b/doc/todo/addurl_--raw-except_REMOTEs__63__.mdwn
@@ -0,0 +1,7 @@
+In [backups2datalad](https://github.com/dandi/backups2datalad/pull/21#issuecomment-1917911205) we ran into a behavior that `addurl --raw` does not only not considers all the fancy handling for youtube and .torrents, but also disregards our (`git-annex-remote-datalad`) external special remote (although still CLAIMURLs it first).
+I think generally we would still prefer to use `--raw` as to avoid possible side-effects when someone manages to add some `.torrent` file which we want to add as a file, not to download it. But we would like to explicitly allow interactions with our special remote. That is why I think the most viable solution would be to provide `--raw-except` which would be like `--raw` but allowing explicitly listed special remotes (or hardcoded keywords like `:torrents:`, `:youtube:`) to be handled if encountered.
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/addurl_--raw-except_REMOTEs__63__/comment_1_d9b88a0f157ce8143d52a35256beaaab._comment b/doc/todo/addurl_--raw-except_REMOTEs__63__/comment_1_d9b88a0f157ce8143d52a35256beaaab._comment
new file mode 100644
index 0000000000..f922e0d30e
--- /dev/null
+++ b/doc/todo/addurl_--raw-except_REMOTEs__63__/comment_1_d9b88a0f157ce8143d52a35256beaaab._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-02-05T18:12:31Z"
+ content="""
+Seems pretty reasonable.
+
+--raw-except=bittorrent would handle bittorrent, no special case needed for
+that.
+
+Since yt-dlp is effectively part of the web special remote (despite being
+implemented as a special case in addurl), seems reasonable to make
+--raw-except=web disable other special remotes while still letting yt-dlp
+be used for appropriate urls.
+
+Implemented.
+"""]]
diff --git a/doc/todo/addurl_--raw-except_REMOTEs__63__/comment_2_2cd05802f25c9868b1b975dd359b66b4._comment b/doc/todo/addurl_--raw-except_REMOTEs__63__/comment_2_2cd05802f25c9868b1b975dd359b66b4._comment
new file mode 100644
index 0000000000..0886468b92
--- /dev/null
+++ b/doc/todo/addurl_--raw-except_REMOTEs__63__/comment_2_2cd05802f25c9868b1b975dd359b66b4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2024-02-09T13:50:21Z"
+ content="""
+fixed in [10.20240129-42-g6b38d0c427](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=6b38d0c427a645d421ebf2d21111c0ca224dfef3)
+"""]]
diff --git a/doc/todo/addurl___8211__force-torrent_option.mdwn b/doc/todo/addurl___8211__force-torrent_option.mdwn
new file mode 100644
index 0000000000..acbb953c0c
--- /dev/null
+++ b/doc/todo/addurl___8211__force-torrent_option.mdwn
@@ -0,0 +1 @@
+There are sites that don't provide direct links to `.torrent` files. Currently there is no way to download contents of such torrents with `git annex`, it simply uses web remote instead of bittorrent.  Something like `--force-torrent` option could help here.
diff --git a/doc/todo/addurl___8211__force-torrent_option/comment_1_15be1914c8d05cd1ad8220bcfea9d0bf._comment b/doc/todo/addurl___8211__force-torrent_option/comment_1_15be1914c8d05cd1ad8220bcfea9d0bf._comment
new file mode 100644
index 0000000000..456fb1ab4a
--- /dev/null
+++ b/doc/todo/addurl___8211__force-torrent_option/comment_1_15be1914c8d05cd1ad8220bcfea9d0bf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-14T19:11:28Z"
+ content="""
+I'd prefer torrent:url; this is consistent with quvi:url for forcing quvi
+be used.
+"""]]
diff --git a/doc/todo/addurl___8211__force-torrent_option/comment_2_52c04c388b807993cecacc7f98b73cd3._comment b/doc/todo/addurl___8211__force-torrent_option/comment_2_52c04c388b807993cecacc7f98b73cd3._comment
new file mode 100644
index 0000000000..f6d52be655
--- /dev/null
+++ b/doc/todo/addurl___8211__force-torrent_option/comment_2_52c04c388b807993cecacc7f98b73cd3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkutSE8_3fFAETmO_E598zja4gKwYXbb8E"
+ nickname="Сергей"
+ subject="comment 2"
+ date="2015-04-14T19:57:52Z"
+ content="""
+Sure, that's even better.
+"""]]
diff --git a/doc/todo/adjusted_branch_with_hashdirlower_links.mdwn b/doc/todo/adjusted_branch_with_hashdirlower_links.mdwn
new file mode 100644
index 0000000000..9441ccf4d9
--- /dev/null
+++ b/doc/todo/adjusted_branch_with_hashdirlower_links.mdwn
@@ -0,0 +1,18 @@
+This would be like enabling the annex.tune.objecthashlower=true 
+[[tuning]] when creating a repository, but could be done after the fact,
+eg when a user needs to clone an existing reppsitory to a filesystem
+that has problems with mixed case hash directories.
+
+The adusted branch would simply convert annex links to use lower-case
+hashing, which is easy. But it would also need to enable storing new object
+files in lower-case hash directories, and move any currently stored object
+files to those directories.
+
+How to handle a `git checkout master` then? None of the annex links in
+master would work. Normally the user can leave an adjusted branch that way,
+but if they wanted to leave this one, there would have to be a command
+to move everything back.
+
+Note that, annexLocationsNonBare does fall back to looking for
+hashDirLower, so getting files from a repository with this enabled to
+another repository should work ok. --[[Joey]]
diff --git a/doc/todo/aeson_2.0.mdwn b/doc/todo/aeson_2.0.mdwn
new file mode 100644
index 0000000000..9a30ac968d
--- /dev/null
+++ b/doc/todo/aeson_2.0.mdwn
@@ -0,0 +1,7 @@
+Need to update to allow building with aeson 2.0.
+
+I have a patch in my mailbox from sternenseemann that
+mostly gets there, but it needs some revision to fix a problem I spotted.
+--[[Joey]]
+
+[[done]]
diff --git a/doc/todo/allow_configuring_assistant_to_add_files_locked.mdwn b/doc/todo/allow_configuring_assistant_to_add_files_locked.mdwn
new file mode 100644
index 0000000000..00c67762ea
--- /dev/null
+++ b/doc/todo/allow_configuring_assistant_to_add_files_locked.mdwn
@@ -0,0 +1,12 @@
+The assistant adds files unlocked, even when git-annex is otherwise
+configured to add them locked.
+
+There are good reasons for that different behavior to be the default,
+but it would be worth having a config to override that.
+
+Eg, when annex.assistant.honor.addunlocked is set, honor the
+annex.addunlocked configuration, which defaults to adding files locked.
+Or perhaps a better name would be annex.assistant.allowaddlocked.
+
+See here for some motivating use cases
+<https://git-annex.branchable.com/forum/Is_there_a_way_to_have_assistant_add_files_locked__63__/>
diff --git a/doc/todo/allow_disk_space_quota_independent_of_free_disk_space.mdwn b/doc/todo/allow_disk_space_quota_independent_of_free_disk_space.mdwn
new file mode 100644
index 0000000000..a972ee77c0
--- /dev/null
+++ b/doc/todo/allow_disk_space_quota_independent_of_free_disk_space.mdwn
@@ -0,0 +1,7 @@
+Feature Request. Instead of (or perhaps in addition to) setting
+`annex.diskreserve`, I'd like to be able to tell git-annex "use up to 2TB
+of disk space".
+
+> This would need changes for git-annex to keep a running total of the
+> space it's using, which becomes a little hairy in light of concurrency,
+> possibly manual changes to the object store, etc. --[[Joey]]
diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access.mdwn b/doc/todo/allow_for_annonymous_AWS_S3_access.mdwn
new file mode 100644
index 0000000000..1eabf4a618
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access.mdwn
@@ -0,0 +1,20 @@
+Should be possible for any public bucket which allows for annonymous access.  ATM git-annex demands AWS credentials for importtree on such public bucket
+
+```shell
+(dandisets) dandi@drogon:/mnt/backup/dandi/tmp/dandisets/test-importtree-s3$ git annex  initremote s3-origin type=S3 importtree=yes encryption=none autoenable=true bucket=dandiarchive fileprefix=zarr-checksums/2ac71edb-738c-40ac-bd8c-8ca985adaa12/            initremote s3-origin (checking bucket...)
+  Set both AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to use S3
+
+git-annex: No S3 credentials configured
+failed
+initremote: 1 failed
+
+(dandisets) dandi@drogon:/mnt/backup/dandi/tmp/dandisets/test-importtree-s3$ git annex version
+git-annex version: 10.20220525-gf1fdc90
+```
+
+in my searches information on "anonymous access to S3" is scarce, but in DataLad we rely on old-ish version of `boto` library which does it for us, more info/pointers [eg here on SO](https://stackoverflow.com/questions/34865927/can-i-use-boto3-anonymously) 
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access/comment_1_0723643146ba36131218be090e6d5c73._comment b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_1_0723643146ba36131218be090e6d5c73._comment
new file mode 100644
index 0000000000..b22dd9cc35
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_1_0723643146ba36131218be090e6d5c73._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-07-13T18:16:57Z"
+ content="""
+I've checked and the haskell aws library does not currently support this.
+Since the library currently needs a maintainer, I have not filed an issue
+to implement this.
+
+It might be possible to work around it, by using s3SignQuery with a dummy
+credentials, and then modifying the SignedQuery that it returns to remove
+the authentication headers. Or by bypassing s3SignQuery and constructing
+a SignedQuery that is not actually signed. Update: No, it's not possible,
+because s3SignQuery is used internally in aws.
+
+Do you have a sample bucket that does allow anonymous access, not only
+to individual files, but to listing the content of the bucket?
+"""]]
diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access/comment_2_2626e1d0b2aa5a2af19d7fef1d13beaa._comment b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_2_2626e1d0b2aa5a2af19d7fef1d13beaa._comment
new file mode 100644
index 0000000000..c97b09aeef
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_2_2626e1d0b2aa5a2af19d7fef1d13beaa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-07-13T20:05:34Z"
+ content="""
+> Do you have a sample bucket that does allow anonymous access, not only to individual files, but to listing the content of the bucket?
+
+doesn't that `dandiarchive` allows for listing?  if not, also try `fcp-indi`. Also, if looking for a small one, checkout our test one `datalad-test0-versioned` - I think it is fully public.  At least for fcp-indi and datalad-test0-versioned query like `curl -v https://s3.amazonaws.com/fcp-indi/` works and seems to list it
+"""]]
diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access/comment_3_6f79f3ecab275d594182fff5e2fd81f9._comment b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_3_6f79f3ecab275d594182fff5e2fd81f9._comment
new file mode 100644
index 0000000000..0ea4323921
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_3_6f79f3ecab275d594182fff5e2fd81f9._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-07-14T18:49:59Z"
+ content="""
+Ok, I hacked up the aws library to omit the authentication headers, and
+provided git-annex with dummy AWS credentials. I was able to import 
+from datalad-test0-versioned after a small fix to git-annex.
+
+Here's the patch I used. This is certianly not upstreamable as-is, but
+is a nice proof of concept.
+
+	diff -ur aws-0.22/Aws/S3/Core.hs aws/Aws/S3/Core.hs
+	--- aws-0.22/Aws/S3/Core.hs	2001-09-08 21:46:40.000000000 -0400
+	+++ aws/Aws/S3/Core.hs	2022-07-14 14:39:33.277075769 -0400
+	@@ -230,7 +230,7 @@
+	       , sqStringToSign = stringToSign
+	       }
+	     where
+	-      amzHeaders = merge $ sortBy (compare `on` fst) (s3QAmzHeaders ++ (fmap (\(k, v) -> (CI.mk k, v)) iamTok))
+	+      amzHeaders = merge $ sortBy (compare `on` fst) s3QAmzHeaders
+	           where merge (x1@(k1,v1):x2@(k2,v2):xs) | k1 == k2  = merge ((k1, B8.intercalate "," [v1, v2]) : xs)
+	                                                  | otherwise = x1 : merge (x2 : xs)
+	                 merge xs = xs
+	@@ -264,8 +264,6 @@
+	              (False, ti') -> ti'
+	              (True, AbsoluteTimestamp time) -> AbsoluteExpires $ s3DefaultExpiry `addUTCTime` time
+	              (True, AbsoluteExpires time) -> AbsoluteExpires time
+	-      sig = signature signatureCredentials HmacSHA1 stringToSign
+	-      iamTok = maybe [] (\x -> [("x-amz-security-token", x)]) (iamToken signatureCredentials)
+	       stringToSign = Blaze.toByteString . mconcat . intersperse (Blaze8.fromChar '\n') . concat  $
+	                        [[Blaze.copyByteString $ httpMethod s3QMethod]
+	                        , [maybe mempty (Blaze.copyByteString . Base64.encode . ByteArray.convert) s3QContentMd5]
+	@@ -278,13 +276,10 @@
+	                        ]
+	           where amzHeader (k, v) = Blaze.copyByteString (CI.foldedCase k) `mappend` Blaze8.fromChar ':' `mappend` Blaze.copyByteString v
+	       (authorization, authQuery) = case ti of
+	-                                 AbsoluteTimestamp _ -> (Just $ return $ B.concat ["AWS ", accessKeyID signatureCredentials, ":", sig], [])
+	+                                 AbsoluteTimestamp _ -> (Nothing, [])
+	                                  AbsoluteExpires time -> (Nothing, HTTP.toQuery $ makeAuthQuery time)
+	       makeAuthQuery time
+	-          = [("Expires" :: B8.ByteString, fmtTimeEpochSeconds time)
+	-            , ("AWSAccessKeyId", accessKeyID signatureCredentials)
+	-            , ("SignatureMethod", "HmacSHA256")
+	-            , ("Signature", sig)] ++ iamTok
+	+          = [("Expires" :: B8.ByteString, fmtTimeEpochSeconds time)]
+	 s3SignQuery S3Query{..} S3Configuration{ s3SignVersion = S3SignV4 signpayload, .. } sd@SignatureData{..}
+	     = SignedQuery
+	     { sqMethod = s3QMethod
+"""]]
diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access/comment_4_9cf7360f849964689133af60b8e1175b._comment b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_4_9cf7360f849964689133af60b8e1175b._comment
new file mode 100644
index 0000000000..d8f73f46ae
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_4_9cf7360f849964689133af60b8e1175b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-07-14T19:04:44Z"
+ content="""
+I've filed an issue for this: <https://github.com/aristidb/aws/issues/279>
+"""]]
diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access/comment_5_b680494cd2fb1cf117b110e08e0ff476._comment b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_5_b680494cd2fb1cf117b110e08e0ff476._comment
new file mode 100644
index 0000000000..ee3191400c
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_5_b680494cd2fb1cf117b110e08e0ff476._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="comment 5"
+ date="2022-09-20T21:30:51Z"
+ content="""
+We are hosting two datasets on S3 that allows anonymous downloads: https://github.com/spine-generic/data-multi-subject, https://github.com/spine-generic/data-single-subject.
+
+You can try it right now:
+
+```
+p115628@joplin:~/datasets/t$ git clone https://github.com/spine-generic/data-multi-subject
+Clonage dans 'data-multi-subject'...
+remote: Enumerating objects: 123344, done.
+remote: Counting objects: 100% (26796/26796), done.
+remote: Compressing objects: 100% (19491/19491), done.
+remote: Total 123344 (delta 6052), reused 25545 (delta 5941), pack-reused 96548
+Réception d'objets: 100% (123344/123344), 15.50 Mio | 8.48 Mio/s, fait.
+Résolution des deltas: 100% (46253/46253), fait.
+p115628@joplin:~/datasets/t$ cd data-multi-subject/
+p115628@joplin:~/datasets/t/data-multi-subject$ git annex get
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+get derivatives/labels/sub-amu01/anat/sub-amu01_T1w_labels-disc-manual.nii.gz (from amazon...) 
+
+(checksum...) ok                  
+get derivatives/labels/sub-amu01/anat/sub-amu01_T1w_seg-manual.nii.gz (from amazon...) 
+
+(checksum...) ok                  
+get derivatives/labels/sub-amu01/anat/sub-amu01_T2star_seg-manual.nii.gz (from amazon...) 
+
+(checksum...) ok                  
+get derivatives/labels/sub-amu01/anat/sub-amu01_T2w_labels-disc-manual.nii.gz (from amazon...) 
+
+[...]
+```
+
+
+The trick was simply to set `public=yes` and `publicurl` when running `initremote`. The final config I have stored is
+
+```
+5a5447a8-a9b8-49bc-8276-01a62632b502 autoenable=true bucket=data-multi-subject---spine-generic---neuropoly datacenter=ca-central-1 encryption=none host=s3.ca-central-1.amazonaws.com name=amazon port=443 public=yes publicurl=https://data-multi-subject---spine-generic---neuropoly.s3.ca-central-1.amazonaws.com signature=v4 storageclass=STANDARD type=S3 timestamp=1661783824.374956s
+```
+
+
+Why would `importtree` behave so differently?
+"""]]
diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access/comment_6_b1e14d6baef8d03aaa6ace717aebc0f9._comment b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_6_b1e14d6baef8d03aaa6ace717aebc0f9._comment
new file mode 100644
index 0000000000..b5c7de5b02
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_6_b1e14d6baef8d03aaa6ace717aebc0f9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2022-09-20T22:50:46Z"
+ content="""
+interesting idea. May be my invocation is still incomplete (no host or datacenter) but with the following one I am still queried for the credentials:
+
+```
+git annex initremote s3-origin type=S3 importtree=yes encryption=none autoenable=true bucket=dandiarchive fileprefix=zarr-checksums/2ac71edb-738c-40ac-bd8c-8ca985adaa12/ public=yes publicurl=https://dandiarchive.s3.amazonaws.com/ signature=v4 storageclass=STANDARD port=443
+```
+
+or may be whenever you ran `initremote` you did have those credential variables exported already? ;)
+"""]]
diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access/comment_7_d44dea0d8c0d46dd8c75ae40f66072e1._comment b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_7_d44dea0d8c0d46dd8c75ae40f66072e1._comment
new file mode 100644
index 0000000000..0c2dc3ee8d
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_7_d44dea0d8c0d46dd8c75ae40f66072e1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-09-21T17:01:18Z"
+ content="""
+@nick.guenther importtree needs a way to list the files stored in a bucket,
+and doing that involves using the S3 API.
+
+In the case of your remote, it knows what files are stored in the
+bucket, since git-annex stored them there previously.
+"""]]
diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access/comment_8_b0d9dbe81f01e80809381a9e5f6a883d._comment b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_8_b0d9dbe81f01e80809381a9e5f6a883d._comment
new file mode 100644
index 0000000000..7aa88f7cb6
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_8_b0d9dbe81f01e80809381a9e5f6a883d._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-10-10T21:04:49Z"
+ content="""
+I've finished the work on aws, which is in
+<https://github.com/aristidb/aws/pull/281> and I hope will be merged soon.
+
+git-annex now has a branch `anons3` that implements this, when
+the S3 remote is configured with signature=anonymous.
+
+	$ git-annex initremote s3-origin type=S3 importtree=yes encryption=none bucket=dandiarchive fileprefix=zarr-checksums/2ac71edb-738c-40ac-bd8c-8ca985adaa12/  signature=anonymous
+	initremote s3-origin (checking bucket...) ok
+	(recording state in git...)
+	$ git-annex import master --from s3-origin
+	list s3-origin ok
+	import s3-origin .checksum 
+	ok                                
+	import s3-origin 0/.checksum 
+	ok                                
+	import s3-origin 0/0/.checksum 
+	ok
+	^C
+
+Also, I've fixed it to only list files in the fileprefix, which
+sped up the listing a *lot* in this bucket with many other files..
+"""]]
diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access/comment_9_7fa3b2aafcad92c20f8a3467aa3ae6b9._comment b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_9_7fa3b2aafcad92c20f8a3467aa3ae6b9._comment
new file mode 100644
index 0000000000..a2a3569074
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_9_7fa3b2aafcad92c20f8a3467aa3ae6b9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-11-04T19:46:26Z"
+ content="""
+I've finished up the work on this. To use it, you will need a git-annex
+built with aws 0.23. It will take some time before that is available in
+some builds, but when building git-annex with stack, it will use it
+already.
+"""]]
diff --git a/doc/todo/alternate_keys_for_same_content.mdwn b/doc/todo/alternate_keys_for_same_content.mdwn
new file mode 100644
index 0000000000..81e93be62d
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content.mdwn
@@ -0,0 +1,12 @@
+Designate a metadata field, say alt_keys, to store alternate keys for the content designated by the key with the metadata.
+Then, after initially adding a URL key, and after some time getting its content, a checksum-based key such as MD5 could be added as the URL key's metadata.
+Then, without needing to migrate, the URL key could be treated like checksum-based keys, e.g. downloaded from untrusted remotes, fsck'ed, etc.
+
+The problem with migrating keys is that a separate copy of the contents is stored in the annex under the old key; but it you force-drop that, symlinks in
+older commits will become invalid.   You could rewrite git history, but that brings its own problems.
+
+Also, sometimes one can determine the MD5 from the URL without downloading the file; e.g. with gsutil stat for gs:// URIs, or by downloading an .md5 file stored next to the main file,
+or because an MD5 was computed by a workflow manager that produced the file (Cromwell does this).   The special remote's "CHECKURL" implementation could record an MD5E key in the
+alt_keys metadata field of the URL key.   Then 'addurl --fast' could check alt_keys, and store in git an MD5E key rather than a URL key, if available.
+
+[[!tag unlikely]]
diff --git a/doc/todo/alternate_keys_for_same_content/comment_10_22ff867952875856b20339a8829c5944._comment b/doc/todo/alternate_keys_for_same_content/comment_10_22ff867952875856b20339a8829c5944._comment
new file mode 100644
index 0000000000..47ce3cdfbb
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_10_22ff867952875856b20339a8829c5944._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: simpler proposal"""
+ date="2023-12-01T18:00:20Z"
+ content="""
+About the idea of recording a checksum of the content of a URL or WORM key,
+without migrating to a SHA key, that does seem worth considering. (And
+maybe was the original idea of this todo really..)
+
+If that were implemented, it would be necessary for more than one checksum
+to be able to be recorded for a given URL key. Because different
+clones might get different content from the URL and each add its checksum.
+
+So, this would not be as strong an assurance as using a SHA key that you're
+referring to a specific peice of data. It would be useful to protect
+against bit rot, but not as a way to pin a file to a particular version.
+Which is often something one does want to do in a git repository!
+
+I do think that implementing that would be a lot simpler. And it would
+only affect performance when verifying the content of URL or WORM keys,
+when it would need to look up the checksum in the git-annex branch.
+"""]]
diff --git a/doc/todo/alternate_keys_for_same_content/comment_11_3323eff3d94d366595bf2b7e78c01dce._comment b/doc/todo/alternate_keys_for_same_content/comment_11_3323eff3d94d366595bf2b7e78c01dce._comment
new file mode 100644
index 0000000000..154fa5a8b5
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_11_3323eff3d94d366595bf2b7e78c01dce._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2023-12-01T18:41:30Z"
+ content="""
+See [[distributed_migration]]...
+"""]]
diff --git a/doc/todo/alternate_keys_for_same_content/comment_1_7a7f287bcde5353072100294dd8edce6._comment b/doc/todo/alternate_keys_for_same_content/comment_1_7a7f287bcde5353072100294dd8edce6._comment
new file mode 100644
index 0000000000..bb54600244
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_1_7a7f287bcde5353072100294dd8edce6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-30T18:36:17Z"
+ content="""
+This would mean that, every time something about a key is looked up in the
+git-annex branch, it would also need to look at the metadata to see if this
+`alt_keys` field is set.
+
+So it doubles the time of every single query of the git-annex branch.
+
+I don't think that's a good idea, querying the git-annex branch is already
+often a bottleneck to commands.
+"""]]
diff --git a/doc/todo/alternate_keys_for_same_content/comment_2_0f464f4970e499371fcb65e0d06202cf._comment b/doc/todo/alternate_keys_for_same_content/comment_2_0f464f4970e499371fcb65e0d06202cf._comment
new file mode 100644
index 0000000000..2eddbbf4de
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_2_0f464f4970e499371fcb65e0d06202cf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="alternate keys"
+ date="2020-01-31T19:23:35Z"
+ content="""
+\"every time something about a key is looked up in the git-annex branch, it would also need to look at the metadata to see if this alt_keys field is set\" -- not every time, just when checking if the key is checksum-based, and if content matches the checksum.  Also, isn't metadata [[cached in a database|design/caching_database]]?
+"""]]
diff --git a/doc/todo/alternate_keys_for_same_content/comment_3_c99b23e878e37e205a3182d3b6d3f2b2._comment b/doc/todo/alternate_keys_for_same_content/comment_3_c99b23e878e37e205a3182d3b6d3f2b2._comment
new file mode 100644
index 0000000000..857b25bc12
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_3_c99b23e878e37e205a3182d3b6d3f2b2._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Re: comment 1 "
+ date="2020-01-31T19:47:59Z"
+ content="""
+The proposed implementation may be inefficient, but the idea has merit.
+
+What if that information is stored in a place where it can be used to verify migrations?
+
+For example, when entering that the migrating remote dropped the data into `git-annex:aaa/bbb/SHA1-s1234--somehash.log`, somewhere near there a record could be added that this was migrated to SHA512-s1234--longerhash. When then all the other remotes are asked to drop that file, they can actually do that because they see that it has been migrated, can verify the migration and are free to drop the file.
+
+Even later, when a remote wants to get an old name (eg. because it checked out an old version of master), it can look up the key, find where it was migrated to, and make the data available under its own name (by copying, or maybe by placing a symlink pointing file from `.git/annex/objects/Aa/Bb/SHA1-s1234--somehash/SHA1-s1234--somehash` to the new.
+"""]]
diff --git a/doc/todo/alternate_keys_for_same_content/comment_4_a5fb6045595da0c490098e46f76db9b8._comment b/doc/todo/alternate_keys_for_same_content/comment_4_a5fb6045595da0c490098e46f76db9b8._comment
new file mode 100644
index 0000000000..a37c5b6224
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_4_a5fb6045595da0c490098e46f76db9b8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2020-01-31T20:32:00Z"
+ content="""
+\"can be used to verify migrations\" -- my hope was to *avoid* migrations, i.e. to get the benefit you'd get from migrating to a checksum-based key, without doing the migration.
+"""]]
diff --git a/doc/todo/alternate_keys_for_same_content/comment_5_230d35bd623189818002901455964ca4._comment b/doc/todo/alternate_keys_for_same_content/comment_5_230d35bd623189818002901455964ca4._comment
new file mode 100644
index 0000000000..4be01e4257
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_5_230d35bd623189818002901455964ca4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="simpler proposal"
+ date="2020-01-31T21:46:57Z"
+ content="""
+So, to fully and properly implement what the title of this todo suggests -- \"alternate keys for same content\" -- might be hard.  But to simply enable adding checksums to WORM/URL keys, stored separately on the git-annex branch rather than encoded in the key's name, is simpler.  This would let some WORM/URL keys to be treated as checksum-based keys when getting contents from untrusted remotes or when checking integrity with `git-annex-fsck`.  But this isn't really \"alternate keys for same content\": the content would be stored under only the WORM/URL key under which it was initially recorded.  The corresponding MD5 key would not be recorded in [[location_tracking]] as present.
+
+Checking whether a WORM/URL key has an associated checksum could be sped up by keeping a Bloom filter representing the set of WORM/URL keys for which `alt_keys` is set.
+
+In the `addurl --fast` case for special remotes, where the remote can determine a file's checksum without downloading, a checksum-based key would be recorded to begin with, as happens with `addurl` without `--fast`.  Currently I do this by manually calling plumbing commands like `git-annex-setpresentkey`, but having `addurl` do it seems better.
+"""]]
diff --git a/doc/todo/alternate_keys_for_same_content/comment_6_ae8355ec917e7a7a240cdb88714c55d0._comment b/doc/todo/alternate_keys_for_same_content/comment_6_ae8355ec917e7a7a240cdb88714c55d0._comment
new file mode 100644
index 0000000000..92d5ba48f7
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_6_ae8355ec917e7a7a240cdb88714c55d0._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="Chel"
+ avatar="http://cdn.libravatar.org/avatar/a42feb5169f70b3edf7f7611f7e3640c"
+ subject="comment 6"
+ date="2020-02-01T02:32:01Z"
+ content="""
+There is also `aaa/bbb/*.log.cid` in git-annex branch for \"per-remote content identifiers for keys\".
+It could be another place to store alternate keys, but it is per-remote, so... no.
+
+As for the metadata field `alt_keys` — it is another case of
+\"[setting a metadata field to a key](/todo/Bidirectional_metadata/#comment-788380998b25267c5b99c4a865277102)\"
+in [[Bidirectional metadata]].
+
+Also, there is an interesting idea of [[git-annex-migrate using git-replace]].
+
+By the way, as far as I know (maybe things have changed since then),
+ipfs has a similar problem of different identifiers for the same content.
+Because it encodes how things are stored. And hash functions can also be changed.
+"""]]
diff --git a/doc/todo/alternate_keys_for_same_content/comment_7_1c0a975893c63c14b3f6e17712b5191c._comment b/doc/todo/alternate_keys_for_same_content/comment_7_1c0a975893c63c14b3f6e17712b5191c._comment
new file mode 100644
index 0000000000..80f61be55d
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_7_1c0a975893c63c14b3f6e17712b5191c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="potential security issues?"
+ date="2020-02-06T21:00:55Z"
+ content="""
+I wonder if storing checksums in a general-purpose mutable metadata field may cause security issues.  Someone could use the [[`git-annex-metadata`|git-annex-metadata]] command to overwrite the checksum.  It should be stored in a read-only field written only by `git-annex` itself, like the `field-lastchanged` metadata already is.
+
+Of course, if someone is able to write the [[git-annex branch|internals#The_git-annex_branch]] directly, or get the user to pull merges to it, they could alter the checksum stored there.  Maybe, only trust stored checksums if `merge.verifySignatures=true`?
+"""]]
diff --git a/doc/todo/alternate_keys_for_same_content/comment_8_4b16c48a2d9f4926d63f6ab54fe801d3._comment b/doc/todo/alternate_keys_for_same_content/comment_8_4b16c48a2d9f4926d63f6ab54fe801d3._comment
new file mode 100644
index 0000000000..cea7fe2855
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_8_4b16c48a2d9f4926d63f6ab54fe801d3._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-11-30T20:43:53Z"
+ content="""
+I think Ilya Shlyakhter gets to a fundamental problem in his comment above.
+Any way that git-annex stores data about an alternate key that is recorded
+in git, allows anyone to spoof bad data.
+
+For example, if I have a SHA256 key stored in git-annex, it would be a bad
+security hole if I fetched from Ilya's repository and suddenly git-annex
+was willing to accept some MD5 key as being the same content as my SHA256
+key. Even if the two keys had the same content currently, that MD5 key can
+be collision attacked later.
+
+So there would need to be a direction in which key upgrades were allowed.
+Which is fine for `WORM -> SHA256`, but less clear for `SHA1 -> SHA256`
+and much less clear for other pairs of modern hashes.
+"""]]
diff --git a/doc/todo/alternate_keys_for_same_content/comment_9_42d240bbfc6ab858219ffa0f873c3eb4._comment b/doc/todo/alternate_keys_for_same_content/comment_9_42d240bbfc6ab858219ffa0f873c3eb4._comment
new file mode 100644
index 0000000000..5b185f2ef6
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_9_42d240bbfc6ab858219ffa0f873c3eb4._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""git-annex branch size when storing migration information"""
+ date="2023-12-01T16:10:11Z"
+ content="""
+I did a small experiment to gauge how much the git repo size would grow if
+migration were recorded in log files in the git-annex branch.
+
+In my experiment, I started with 1000 files using sha256. The size of the
+git objects (after repack by git gc --aggressive) was 0.5 mb. I then
+migrated them to sha512, which increased the size of git objects to 1.1 mb
+(after repacking).
+
+Then I recorded in the git-annex branch additional log files for each of
+the sha512 keys that contained the corresponding sha256 key. That grew the
+git objects to 1.4 mb after repacking.
+
+This was a little disappointing. I'd hoped that repacking would avoid
+duplication of the sha256 keys, which are both in the log files I wrote
+and are used as filenames. But the data I wrote to the logs is only 75 kb
+total, and git grew 4x that.
+
+I tried the same thing except instead of separate log files I added to git
+one log file that contained pairs of sha256 and sha512 keys. That log file
+was 213 kb and adding it to the git repo grew it by 102 kb. So there was
+some compression there, but less than I would have hoped, and not much
+better than just gzip -9 of the log file (113 kb). Of course putting all
+the migration information in a single file like this would add a lot of  
+complexity to accessing it.
+
+So adding this information to the git-annex branch would involve at best
+around a 16% overhead, which is a surprising amount. 
+
+(It would be possible to make `git-annex forget --drop-dead` remove the
+information about old migrated keys if they later get marked as dead, and
+so regain the space.)
+
+This is also rather redundant information to store in git, since most
+of the time when file foo has been migrated, the old key can be determined
+by looking at `git log foo`. Not always of course because foo might have
+been renamed after migration, for example.
+
+Another way to store migration information in the git-annex branch would to
+be graft in the pre-migration tree and the post-migration tree. Diffing
+those two trees would show what migrated, and most of the time this would
+use almost no additional space in git, because the user will have committed
+both those trees anyway, or something very close to them. But it would be
+more expensive to extract the migration information then, and this would
+need a local cache of migrations to be built up from examining those diffs..
+"""]]
diff --git a/doc/todo/annex.addunlocked_in_gitattributes.mdwn b/doc/todo/annex.addunlocked_in_gitattributes.mdwn
new file mode 100644
index 0000000000..22ff605a53
--- /dev/null
+++ b/doc/todo/annex.addunlocked_in_gitattributes.mdwn
@@ -0,0 +1,13 @@
+Make annex.addunlocked be able to be configured in .gitattributes,
+the same way as annex.largefiles can be.
+
+This would be useful if certain filename extensions need to be unlocked to
+be used, and others are desired to be kept locked.
+
+The annex.addunlocked git config is a boolean, but this gitattributes one
+would effectively build up a file match expression. So it might then follow
+that the git config should also be a file match expression, with "true"
+being the same as "anything" and "false" the same as "nothing" for
+back-compat. --[[Joey]]
+
+> This got accomplished by other means, [[done]] --[[Joey]]
diff --git a/doc/todo/annex.addunlocked_in_gitattributes/comment_1_1d21cde3d21a9b5bb129b17b9e0fc95d._comment b/doc/todo/annex.addunlocked_in_gitattributes/comment_1_1d21cde3d21a9b5bb129b17b9e0fc95d._comment
new file mode 100644
index 0000000000..b657a5043b
--- /dev/null
+++ b/doc/todo/annex.addunlocked_in_gitattributes/comment_1_1d21cde3d21a9b5bb129b17b9e0fc95d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2022-02-18T20:18:04Z"
+ content="""
+Dear Joey,  could you please elaborate on what \"other means\" it was accomplished through?  we are on the expedition ATM to discover. 
+"""]]
diff --git a/doc/todo/annex.addunlocked_in_gitattributes/comment_2_38f248f7596646dfc11248f0149c0beb._comment b/doc/todo/annex.addunlocked_in_gitattributes/comment_2_38f248f7596646dfc11248f0149c0beb._comment
new file mode 100644
index 0000000000..f3b93cba26
--- /dev/null
+++ b/doc/todo/annex.addunlocked_in_gitattributes/comment_2_38f248f7596646dfc11248f0149c0beb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-02-18T21:56:19Z"
+ content="""
+I guess it is the fact that this particular config variable is also supported by `git annex config` so could be set persistently (across clones) this way.
+"""]]
diff --git a/doc/todo/annex.addunlocked_in_gitattributes/comment_3_270c5156c8adce0aff86eda5f2746703._comment b/doc/todo/annex.addunlocked_in_gitattributes/comment_3_270c5156c8adce0aff86eda5f2746703._comment
new file mode 100644
index 0000000000..bfbc9afeab
--- /dev/null
+++ b/doc/todo/annex.addunlocked_in_gitattributes/comment_3_270c5156c8adce0aff86eda5f2746703._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-02-21T19:40:50Z"
+ content="""
+Yes, annex.addunlocked with a matching expression was
+implemented in 2019 and accomplishes the same thing
+as this would have, without the problems of using git attributes.
+"""]]
diff --git a/doc/todo/annex.addunlocked_in_gitattributes/comment_4_d87e08ccdec98867dd52b629e6fad330._comment b/doc/todo/annex.addunlocked_in_gitattributes/comment_4_d87e08ccdec98867dd52b629e6fad330._comment
new file mode 100644
index 0000000000..67d8b41c87
--- /dev/null
+++ b/doc/todo/annex.addunlocked_in_gitattributes/comment_4_d87e08ccdec98867dd52b629e6fad330._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2022-02-21T21:53:03Z"
+ content="""
+just it is getting a bit \"confusing\" to use `.gitattributes` for some types of annotations (e.g., `largefiles`) for files patterns and then `git annex config` for others.  Ideally there should either be a singular or equivalently expressive (not complimentary) multiple ways.
+
+> without the problems of using git attributes
+
+could you please remind (or point to prior composed list) of those? I personally just keep forgetting which one (first or last match) applies ;)
+"""]]
diff --git a/doc/todo/annex.addunlocked_in_gitattributes/comment_5_be25f3b3c2279eb3fd3ef69c4d1cb52d._comment b/doc/todo/annex.addunlocked_in_gitattributes/comment_5_be25f3b3c2279eb3fd3ef69c4d1cb52d._comment
new file mode 100644
index 0000000000..d4436a15ca
--- /dev/null
+++ b/doc/todo/annex.addunlocked_in_gitattributes/comment_5_be25f3b3c2279eb3fd3ef69c4d1cb52d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-02-25T17:28:20Z"
+ content="""
+git-annex config does work for both largefiles and addunlocked.
+
+gitattributes does not allow setting an attribute containing a space
+and so complex expressions, which either of these can have, become very
+annoying to shoehorn in. gitattributes also adds a round-trip overhead
+to query it for every file.
+"""]]
diff --git a/doc/todo/annex.addunlocked_in_gitattributes/comment_6_f672dee4c1712e0d20dd820999598d87._comment b/doc/todo/annex.addunlocked_in_gitattributes/comment_6_f672dee4c1712e0d20dd820999598d87._comment
new file mode 100644
index 0000000000..09941c90b5
--- /dev/null
+++ b/doc/todo/annex.addunlocked_in_gitattributes/comment_6_f672dee4c1712e0d20dd820999598d87._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="question about backend"
+ date="2022-02-28T22:42:33Z"
+ content="""
+ATM we rely on .gitattributes to set default (to DataLad datasets) backend to be MD5E, so every dataset then is guaranteed to have `.gitattributes`. We also rely in many configurations on setting `largefiles` for different extensions within `.gitattributes`.  I think this is two primary target use cases.  You say that having `.gitattributes` slows down `git` (and `git-annex`) operations -- so would you recommend to switch to specifying those (backend, largefiles) via `git annex config` instead?  
+
+In [datalad/issues/5383 (Stop using .gitattributes for annex.largefiles config )](https://github.com/datalad/datalad/issues/5383)  note was that default backend cannot be specified via `git-annex config` -- is that still the case?
+"""]]
diff --git a/doc/todo/annex.addunlocked_in_gitattributes/comment_7_d06e3412f07d98c784b420d82d2d8d49._comment b/doc/todo/annex.addunlocked_in_gitattributes/comment_7_d06e3412f07d98c784b420d82d2d8d49._comment
new file mode 100644
index 0000000000..dc4eea27e7
--- /dev/null
+++ b/doc/todo/annex.addunlocked_in_gitattributes/comment_7_d06e3412f07d98c784b420d82d2d8d49._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-08-01T16:10:31Z"
+ content="""
+Well, moving your annex.largefiles settings from gitattributes to `git-annex
+config` won't speed up queries for it, because the gitattribute overrides
+the `git-annex config` setting. And so git-annex still has to do the work
+of querying for the gitattribute anyway, even when it's not set. 
+
+In [[!commit 4acbb40112aa73dcde63841d8d8c04c433f6a806]] I benchmarked that 
+as making `git-annex add` 2% slower than it would be otherwise (excluding
+hashing). We will just have to live with that, unless the gitattribute
+can eventually somehow be deprecated.
+That is a good lesson about the risks of adding more gitattributes. 
+
+annex.backend is not currently configurable by `git-annex config`.
+It would be listed in its man page if it were.
+
+I'd support adding that, but annex.backend is currently the name of a
+single backend, so this would not allow setting the backend differently for
+different filenames. Which is something that gitattributes can do. So it
+would need annex.backend to be expanded, so it can specify different
+backends for different filenames or other properties. I don't know how that
+syntax would look; the syntax git-annex currently uses for annex.largefiles
+etc is not suitable here. It would certianly be an added complication.
+
+Also, it seems that the reasoning that made the annex.largefiles 
+gitattributes override `git-annex config` would also make sense for
+annex.backend, and if so there would be no performance benefit to moving
+it. I'm not sure what that reasoning was. Possibly that there
+might be cases where the desired value depends on the branch that's checked
+out.
+"""]]
diff --git a/doc/todo/annex.addunlocked_in_gitattributes/comment_8_73a402df13f30b279dfd2914adec5f35._comment b/doc/todo/annex.addunlocked_in_gitattributes/comment_8_73a402df13f30b279dfd2914adec5f35._comment
new file mode 100644
index 0000000000..a688bb6937
--- /dev/null
+++ b/doc/todo/annex.addunlocked_in_gitattributes/comment_8_73a402df13f30b279dfd2914adec5f35._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-08-01T16:37:20Z"
+ content="""
+I would support adding annex.backend to `git-annex config` using the
+current simple value though. There is benefit to doing it for consistencty,
+surely. If a more complicated syntax is needed someone
+can still use gitattributes or git-annex could be changed later.
+
+Please open a new todo if this would be useful to you..
+"""]]
diff --git a/doc/todo/annex.addunlocked_in_gitattributes/comment_9_02866c504617c2914eff01d3529d5cc7._comment b/doc/todo/annex.addunlocked_in_gitattributes/comment_9_02866c504617c2914eff01d3529d5cc7._comment
new file mode 100644
index 0000000000..ea7d96fc27
--- /dev/null
+++ b/doc/todo/annex.addunlocked_in_gitattributes/comment_9_02866c504617c2914eff01d3529d5cc7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-08-01T16:39:40Z"
+ content="""
+I also think that the thinking in this comment is worth considering:
+<https://github.com/datalad/datalad/issues/5383#issuecomment-770108778>
+
+Those are valid reasons to prefer to be able to set things like this
+in gitattributes rather than the global config. Those kinds of
+considerations are why the global config always has a local way to override
+it. Sometimes that is necessarily .git/config, not .gitattributes though.
+"""]]
diff --git a/doc/todo/annex_add___40__-u__124__--update__41___mode.mdwn b/doc/todo/annex_add___40__-u__124__--update__41___mode.mdwn
new file mode 100644
index 0000000000..558c1e3e5e
--- /dev/null
+++ b/doc/todo/annex_add___40__-u__124__--update__41___mode.mdwn
@@ -0,0 +1,6 @@
+to supplement 'git add -u' behavior -- to add only updated (tracked only, no untracked) files to be committed.  ATM all files would be added, including untracked.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]]
diff --git a/doc/todo/annex_add___40__-u__124__--update__41___mode/comment_1_bde2b1e2c45e110d56ce98b43dd77743._comment b/doc/todo/annex_add___40__-u__124__--update__41___mode/comment_1_bde2b1e2c45e110d56ce98b43dd77743._comment
new file mode 100644
index 0000000000..e6a632902e
--- /dev/null
+++ b/doc/todo/annex_add___40__-u__124__--update__41___mode/comment_1_bde2b1e2c45e110d56ce98b43dd77743._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-07T19:41:02Z"
+ content="""
+Good idea, adding.
+"""]]
diff --git a/doc/todo/annex_merge_--remotes.mdwn b/doc/todo/annex_merge_--remotes.mdwn
new file mode 100644
index 0000000000..0325127b35
--- /dev/null
+++ b/doc/todo/annex_merge_--remotes.mdwn
@@ -0,0 +1,8 @@
+ATM 'annex merge' does not accept any parameter to specify which remotes to consider -- it merges all.  In some cases it might be desirable to merge only information from some remotes (e.g. I keep some annex remote "private" or smth like that)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+[[!tag moreinfo]]
+
+> [[closing|done]] because there is a way to do it with git config, and no
+> better way for git-annex to do it. --[[Joey]]
diff --git a/doc/todo/annex_merge_--remotes/comment_1_d4d1c3dae7cff4119b7c111ac6e6f947._comment b/doc/todo/annex_merge_--remotes/comment_1_d4d1c3dae7cff4119b7c111ac6e6f947._comment
new file mode 100644
index 0000000000..a6d05f56a4
--- /dev/null
+++ b/doc/todo/annex_merge_--remotes/comment_1_d4d1c3dae7cff4119b7c111ac6e6f947._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-08-08T15:32:19Z"
+ content="""
+There's been discussion of keeping private forks of git-annex
+repositories before.
+
+IIRC, the remote.name.annex-sync and remote.name.annex-readonly
+settings can accomplish that. 
+
+For example, if the private repository A has a remote B, it can set
+annex-readonly, and this will prevent A from pushing any data to B. A
+can still pull from B. If A is on a locked down machine that B cannot
+itsef access, this guarantees that the changes in A remain private.
+I think this is the best way to accomplish this kind of scenario.
+
+If B has A as a remote, then B could set annex-sync to false, which
+would prevent it from pulling from A, and so B would never merge
+in git-annex branches from A, at least unless A pushed them to B.
+Of course, in this scenario, a manual `git pull A` on B bypasses
+the protection.
+
+It might make sense to make git-annex merge honor annex-ignore,
+and skip merging branches that belong to a remote, even if they
+were somehow pulled down. Unfortunately, git's remote branch
+name mapping can be quite complicated; IIRC it's not as simple
+as skipping branches remotes/B/*
+"""]]
diff --git a/doc/todo/annex_merge_--remotes/comment_2_be8596676823e916a56d774e0a161945._comment b/doc/todo/annex_merge_--remotes/comment_2_be8596676823e916a56d774e0a161945._comment
new file mode 100644
index 0000000000..38bd4e45b6
--- /dev/null
+++ b/doc/todo/annex_merge_--remotes/comment_2_be8596676823e916a56d774e0a161945._comment
@@ -0,0 +1,68 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-10-13T17:27:36Z"
+ content="""
+For a `git annex merge --remotes` to be useful, there would need to be a
+config to disable the automatic merging of git-annex branches, which all
+git-annex commands do when they notice it needs to be done.
+So, this needs to be a git config and not a switch, so it can also
+control the automatic git-annex branch merging.
+
+Using remote.name.annex-ignore as the config does not make sense on second
+look, because that gets set automatically when the remote is on eg
+github.
+
+Using remote.name.annex-sync=false as the config makes some sense, although
+as noted above, that prevents `git annex sync` from fetching from the
+remote already, so unless `git pull` is run manually, the existing config
+should suffice.
+
+To implement that, git-annex would have to parse the remote.name.fetch
+config in order to tell what name a remote's git-annex branch is fetched
+to. I am reluctant to do this for several reasons:
+
+* The syntax of remote.name.fetch is only documented by example. It's
+  not clear what's supposed to be done if eg, the `*` appears twice
+  in a branch name or different numbers of times on the left and right hand
+  sides.
+
+* Two remotes can have remote.name.fetch set such that the same remote
+  tracking branch is locally used for fetches from both remotes. So
+  git-annex would not know if such a branch should be synced or not.
+
+* remote.name.fetch can be overridden when using git fetch or git pull at
+  the command line, so again git-annex can't know for sure what remote a
+  given tracking branch came from.
+
+Four approaches that could work:
+
+1. Add a config that is a list of remote tracking branches, and
+   make `git annex merge` and the automatic git-annex branch merging merge
+   only those tracking branches. For example, 
+   `annex.allowmerge=refs/remotes/origin/git-annex refs/remotes/origin/master`
+
+   Doable, but it seems this would be an annoying list to maintain,
+   especially when new branches are made.
+
+2. Embed some information in a branch that can be looked at to determine
+   that git-annex should not auto-merge this branch. Note that this would
+   need to be done for both the git-annex branch and the regular branch.
+   The latter seems particularly hard to do.
+
+3. Configure remote.name.fetch so that the remote git-annex branch is
+   either not fetched, or fetched to a tracking branch that does not end
+   in `/git-annex`. I think this is possible to do, but due to the lack of
+   documentation for that config, it would take some experimentation to
+   find how to do it. This would prevent the automatic merging of that
+   branch by git-annex. 
+   
+   And if you make the remote master branch be
+   fetched to eg refs/remotes/name/master/nomerge then `git annex merge`
+   won't merge that into master.
+
+4. Prevent adding a remote to a repository if that remote contains private
+   information that you don't want to get merged into the local repository.
+   This still seems like the best solution to me; if the information is
+   private it should not be possible to fetch it from the remote.
+"""]]
diff --git a/doc/todo/annex_merge_--remotes/comment_3_35614da544e315529b236a36e1b28e2d._comment b/doc/todo/annex_merge_--remotes/comment_3_35614da544e315529b236a36e1b28e2d._comment
new file mode 100644
index 0000000000..be9e733035
--- /dev/null
+++ b/doc/todo/annex_merge_--remotes/comment_3_35614da544e315529b236a36e1b28e2d._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-08-06T15:47:56Z"
+ content="""
+This came up again in <https://git-annex.branchable.com/tips/local_caching_of_annexed_files/>
+and there it was sufficient to configure remote.name.fetch so that no
+branches were fetched from the cache remote.
+
+Approach #3 can be implemented using:
+
+	fetch = refs/heads/master:refs/remotes/private/nomerge/master
+
+This prevents git-fetch from fetching the git-annex branch, and
+it makes the remote master banch fetch into a name that
+git-annex won't automatically merge into master.
+"""]]
diff --git a/doc/todo/annex_merge_--remotes/comment_4_8cb7787fbfae63c45a155ee6ef270922._comment b/doc/todo/annex_merge_--remotes/comment_4_8cb7787fbfae63c45a155ee6ef270922._comment
new file mode 100644
index 0000000000..be908e6592
--- /dev/null
+++ b/doc/todo/annex_merge_--remotes/comment_4_8cb7787fbfae63c45a155ee6ef270922._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-01-29T15:10:09Z"
+ content="""
+Based on my last comment, I think, if you still need this, you
+should try configuring remote.name.fetch to avoid fetching the git-annex
+branches you don't want to merge.
+
+If that's not sufficient, followup and we can think about the other options
+I discussed earlier.
+"""]]
diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed.mdwn b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed.mdwn
new file mode 100644
index 0000000000..ffc25229e6
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed.mdwn
@@ -0,0 +1,29 @@
+As seen in <https://github.com/datalad/datalad/pull/6510> datalad
+is having to parse error messages to determine when nonexistant
+filenames were passed to git-annex. It would be better if there was some
+kind of API that it could use, since error messages can (and have) changed.
+
+What would this API look like? It seems it could not be a special
+exit status of git-annex, because exit status 101 is already allocated
+for indicating when things like --size-limit and --time-limit have caused
+it to skip processing certian files.
+
+Perhaps something like `--json-error-unmatch` which would make it output
+an additional line with a JSON record indicating that git ls-files
+--error-unmatch had errored out.
+
+Or `--json` could enable this additional JSON record output.
+The advantage would be that datalad would not need to check the git-annex
+version to see if the option is supported. It would need to output a
+JSON record even when git-ls-files did not fail. Perhaps something like
+this:
+
+	{"git-ls-files exit status": 0}
+	{"git-ls-files exit-status": 1}
+
+This does risk breaking things that parse the existing JSON and fall
+over on the new record, but I think git-annex should be free to add new
+records and fields to its JSON output in general, and it has probably
+at least added new fields before. --[[Joey]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_10_32ebb1ea1278b891b58dd3c4a8546453._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_10_32ebb1ea1278b891b58dd3c4a8546453._comment
new file mode 100644
index 0000000000..1c4470eba6
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_10_32ebb1ea1278b891b58dd3c4a8546453._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2023-04-26T16:42:24Z"
+ content="""
+I decided to rename it "message-id" since it could go on warning or other
+messages too conceivably.
+"""]]
diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_1_672457817d5dca898f5aefbe97da9b23._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_1_672457817d5dca898f5aefbe97da9b23._comment
new file mode 100644
index 0000000000..d37afaf7d7
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_1_672457817d5dca898f5aefbe97da9b23._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2022-02-28T18:48:50Z"
+ content="""
+> This does risk breaking things that parse the existing JSON and fall over on the new record, but I think git-annex should be free to add new records and fields to its JSON output in general, and it has probably at least added new fields before. 
+
+Although sounds logical, FWIW, not sure if DataLad would be robust to such an assumption since I don't think it was exercised before and indeed all returned records were typically associated with some particular `\"path\"` so our code might rely on that.  Also it makes it a bit unclear on what datalad code should do with \"unrecognized\" outputs -- are they sign of a problem, or could be safely ignored?
+
+Ideally, IMHO and IIRC, DataLad should not concern itself with exit codes of `git` commands which `git-annex` ran -- it should be up to `git-annex` to decide on what any particular underlying `git` invocation supposed to do etc.  I guess only in the cases of some faulty, unknown to git-annex how to handle, behavior where git-annex itself reports an error, might be worth including details on underlying failed `git` invocation in the output, so datalad also could channel it to the user. 
+"""]]
diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_2_b6a76bfc063dcba439b2ead004caabc9._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_2_b6a76bfc063dcba439b2ead004caabc9._comment
new file mode 100644
index 0000000000..4212e006f7
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_2_b6a76bfc063dcba439b2ead004caabc9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-02-28T19:40:13Z"
+ content="""
+But datalad is apparently concerning itself with just that, since
+there was a bug when git-annex's "not found" stderr changed.
+
+I do think this needs to have a good motivation before it's implemented,
+and that's currently all I have, that datalad for some reason cares about
+it. Maybe there is not a good reason for datalad to care though..
+
+You may well be right about adding new JSON objects breaking parsers.
+"""]]
diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_3_3f0872f13160a77a82bd5a95fc3f397d._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_3_3f0872f13160a77a82bd5a95fc3f397d._comment
new file mode 100644
index 0000000000..b48dd361f7
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_3_3f0872f13160a77a82bd5a95fc3f397d._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-04-25T16:57:58Z"
+ content="""
+I see that datalad parses the error messages to get the filename that
+caused it, and so an exit status is not enough information.
+
+(See `./datalad/support/annex_utils.py`
+`_get_non_existing_from_annex_output`)
+
+So the additional json would need to include the filename that didn't
+exist.
+
+[this closed todo](https://git-annex.branchable.com/projects/datalad/bugs-done/copy_does_not_reflect_some_failed_copies_in_--json_output/)
+argues persuasively that --json-error-messages cannot be extended to
+include these errors as-is. In particular, putting them in the current
+json would mean outputting a record without a "key" field in situations
+where that field is always present, so json consumers might 
+misbehave without it.
+
+bpoldrack makes a good point
+[here](https://github.com/datalad/datalad/pull/6510#issuecomment-1057320621):
+
+> Ideally, there'd be some indication of the problem that isn't meant to
+> be a message to the user and not (so easily) subject to change - pretty
+> much something that's akin to an exception name. That's because there
+> are possible errors that we can deal with from within datalad if we can
+> "understand" the problem - not everything needs to be passed onto the
+> user.
+
+So eg:
+
+	{"exception":"UNIQUEID", "file":"foo", "error-messages":["foo not found"]}
+
+That seems about right to me, and it future proofs git-annex to be able to
+report other exceptions in json output later on.
+"""]]
diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_4_0217c8acd2a9eb3bba1fc497856cd96a._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_4_0217c8acd2a9eb3bba1fc497856cd96a._comment
new file mode 100644
index 0000000000..d977b33910
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_4_0217c8acd2a9eb3bba1fc497856cd96a._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-04-25T17:49:23Z"
+ content="""
+What should enable that new json output for exceptions, 
+--json-error-messages or a new option like --json-exceptions?
+
+The risk is that, since this is a new object type, it breaks a json
+consumer that expects to find a `{"command":...}` object.
+
+I do think that git-annex should be free to add new fields to existing json
+objects. But adding a new object type seems considerably more risky.
+git-annex has never done that before (eg --json-progress outputs the
+"command" object with updated values).
+
+I took a look at datalad's parsing of json from git-annex, to see what it might
+do if it got a new object type unexpectedly. I'm not convinced it wouldn't
+misbehave. For example, in `datalad/interface/results.py` `annexjson2result`:
+
+    res['status'] = 'ok' if d.get('success', False) is True else 'error'
+
+Without a "status" field this will yield "error" which could go on to
+cause unexpected behavior
+
+So, I think this would need to be a new --json-exceptions option.
+"""]]
diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_5_7501eed2e6cb732966277ef2f1ff28e9._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_5_7501eed2e6cb732966277ef2f1ff28e9._comment
new file mode 100644
index 0000000000..3bf70bb5fb
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_5_7501eed2e6cb732966277ef2f1ff28e9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2023-04-25T18:31:20Z"
+ content="""
+Yes -- having some UNIQUEIDs for errors might be quite great!
+
+As for specific field to identify what that error applicable to: the other changed behavior which broke our code/tests was the change to behavior of `annex info` to no longer list unknown to annex path in `\"file\"` and rather list it in `\"input\"` for which the [PR](https://github.com/datalad/datalad/pull/7372/files) was cooked up already.  So may be here it also just should be `\"input\"` field if `annex` desires to not make claims on either it is a `\"file\"` or may be some \"pathspec\" (well -- in DataLad nobody was brave enough to open that -- path-vs-pathspec -- pandora box  [see issues/6933](https://github.com/datalad/datalad/issues/6933))?
+"""]]
diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_6_7a5b3d2694a48e4e44436f6bf7ed6642._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_6_7a5b3d2694a48e4e44436f6bf7ed6642._comment
new file mode 100644
index 0000000000..d60f16611f
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_6_7a5b3d2694a48e4e44436f6bf7ed6642._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2023-04-25T18:45:58Z"
+ content="""
+Just for completeness -- do we really need a new type of record for this?  In immediate use case which is [in the heart of the path escaping change discussion](https://git-annex.branchable.com/bugs/started_to_escape_characters_in_the_output/) let's consider other commands.  E.g. `addurl` already reports `--json-errors` just fine in a similar case
+
+```shell
+❯ git annex addurl --json --json-error-messages '\e[31mfo\o\e[0m'
+{\"command\":\"addurl\",\"error-messages\":[\"git-annex: bad url \\e[31mfo\\o\\e[0m\"],\"file\":null,\"input\":[\"\\e[31mfo\\o\\e[0m\"],\"success\":false}
+addurl: 1 failed
+```
+
+so why just not to make `add`'s 
+
+```shell
+❯ git annex add --json --json-error-messages '\e[31mfo\o\e[0m'
+git-annex: \e[31mfo\o\e[0m not found
+add: 1 failed
+```
+
+into
+
+```shell
+{\"command\":\"add\",\"error-messages\":[\"git-annex: \\e[31mfo\\o\\e[0m not found\"],\"file\":null,\"input\":[\"\\e[31mfo\\o\\e[0m\"],\"success\":false}
+add: 1 failed
+```
+
+or if you want to expand with unambigous ID:
+
+```
+{\"command\":\"add\",\"error-messages\":[\"git-annex: \\e[31mfo\\o\\e[0m not found\"],\"file\":null,\"input\":[\"\\e[31mfo\\o\\e[0m\"],\"success\":false, \"errorid\": \"NOT_FOUND\"}
+add: 1 failed
+```
+or alike without requiring some new CLI option?
+"""]]
diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_8_2550e1760dcfb90c9c2ca1ee145adcf1._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_8_2550e1760dcfb90c9c2ca1ee145adcf1._comment
new file mode 100644
index 0000000000..a72b9b3286
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_8_2550e1760dcfb90c9c2ca1ee145adcf1._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-04-25T22:45:24Z"
+ content="""
+Ok, implemented the simple alternative. Here's how it looks:
+
+	joey@darkstar:~/tmp/xxx>git-annex add 'dne' --json --json-error-messages
+	{"command":"add","error-messages":["git-annex: dne not found"],"errorid":"FileNotFound","file":"dne","input":["dne"],"success":false}
+	add: 1 failed
+
+The errorid will remain stable. I can add those to other error messages
+now, on request BTW.
+
+Note that when git-annex relies on `git ls-files --error-unmatch` to
+complain about nonexistant or non-git files, the error messages from
+git will still be displayed to stderr, not this nice json. So
+datalad will need to keep its parser for that part.
+"""]]
diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_8_f34293aa30b8b9abc71fac4e713aded3._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_8_f34293aa30b8b9abc71fac4e713aded3._comment
new file mode 100644
index 0000000000..1bec987de0
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_8_f34293aa30b8b9abc71fac4e713aded3._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: comment 6"""
+ date="2023-04-25T21:10:21Z"
+ content="""
+Oh well spotted yarikoptic! I wish I had noticed your comment 2 hours ago,
+but I was head down implementing --json-exceptions.
+
+Ok, so `addurl` does `giveup "bad url"` and that does indeed result in json
+output that lacks a `key` and has `"file":null` as well.
+
+I'm sure that somewhere in `git-annex add`, it's possible for it to
+`giveup` with an error too. Oh of course... a device file!
+
+	joey@darkstar:/home/joey/tmp/xxx>git-annex add --force-small null --json --json-error-messages
+	{"command":"add","error-messages":["git-annex: null is not a regular file"],"file":"null","input":["null"],"note":"adding content to git repository","success":false}
+	add: 1 failed
+
+Other perhaps more likely cases where add can `giveup` include when it's unable
+to remove all write perms due to an xattr, and probably some permissions
+problems.
+
+So, json consumers of add already have to deal with the `key` being missing.
+
+Now, it might be that some git-annex commands don't `giveup`, so this would be
+a new complication for consumers of their json. But so would adding a `giveup`
+for any reason to a command, and I don't worry about that.
+
+While I've implemented --json-exceptions, I don't like the complexity, so this new
+information inclines me to rip it back out and instead handle the case of the
+nonexistant file like:
+
+	{"command":"add","exception":"UNIQUEID","file":"foo","input":["foo"],"error-messages":["foo not found"],"success":false}
+"""]]
diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_9_d7e879ae1e7ae5e27e15dab9d5b99f16._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_9_d7e879ae1e7ae5e27e15dab9d5b99f16._comment
new file mode 100644
index 0000000000..d3b130a16a
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_9_d7e879ae1e7ae5e27e15dab9d5b99f16._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 9"
+ date="2023-04-26T16:38:26Z"
+ content="""
+quick/small one -- given that there is `\"error-messages\"`, would it may be make sense to name new one `\"error-id\"` and not `\"errorid\"` for consistency?
+"""]]
diff --git a/doc/todo/arm64_autobuild_broken_since_2022.mdwn b/doc/todo/arm64_autobuild_broken_since_2022.mdwn
new file mode 100644
index 0000000000..fcaff06c3b
--- /dev/null
+++ b/doc/todo/arm64_autobuild_broken_since_2022.mdwn
@@ -0,0 +1,10 @@
+Hi joey,
+
+Could you have a look at the arm64 autobuilds? The last successful build is from January 2022, the recent ones (which still run) fail: https://downloads.kitenet.net/git-annex/autobuild/arm64/
+
+Would be awesome to use latest git-annex on my Raspberry PIs etc. 🙂
+
+Cheers, 
+Yann
+
+> [[fixed_in_april_already|done]] --[[Joey]]
diff --git a/doc/todo/arm64_autobuild_broken_since_2022/comment_1_0642002d8ad1eb318de5fdb63956a2fc._comment b/doc/todo/arm64_autobuild_broken_since_2022/comment_1_0642002d8ad1eb318de5fdb63956a2fc._comment
new file mode 100644
index 0000000000..2d51d5f855
--- /dev/null
+++ b/doc/todo/arm64_autobuild_broken_since_2022/comment_1_0642002d8ad1eb318de5fdb63956a2fc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-06-12T16:44:41Z"
+ content="""
+Um, the autobuild you linked to is a successful build, and the last release of
+git-annex included a current arm64 build.
+
+I stood up a new arm64 build box in April...
+"""]]
diff --git a/doc/todo/arm64_autobuild_broken_since_2022/comment_2_48e40f76e0480adc965505543a4f25e5._comment b/doc/todo/arm64_autobuild_broken_since_2022/comment_2_48e40f76e0480adc965505543a4f25e5._comment
new file mode 100644
index 0000000000..355879eeb8
--- /dev/null
+++ b/doc/todo/arm64_autobuild_broken_since_2022/comment_2_48e40f76e0480adc965505543a4f25e5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2023-06-12T21:12:29Z"
+ content="""
+Huh, this is very weird. I could've sworn that the date 202201 was all over the place this morning and was also the version one got when downloading the standalone arm64 version or the autobuild version. But now everything seems to be fine. Sorry for the confusion, then.
+"""]]
diff --git a/doc/todo/assign_costs_per_URL_or_better_repo-wide___40__regexes__41__.mdwn b/doc/todo/assign_costs_per_URL_or_better_repo-wide___40__regexes__41__.mdwn
new file mode 100644
index 0000000000..24fa82e701
--- /dev/null
+++ b/doc/todo/assign_costs_per_URL_or_better_repo-wide___40__regexes__41__.mdwn
@@ -0,0 +1,62 @@
+I could have bet all my savings (well, not that much anyways - kids keep eating) that there was a way to give different costs for different URLs.  I believe it was in the same spirit as `remote.<name>.annex-cost-command` - that there could be a command which then be used to prioritize one url over another.  But I fail to find any hint on it
+
+<details>
+<summary>e.g. nothing in `cost` related config vars</summary> 
+
+```shell
+$> grep '^\*.*cost' doc/git-annex.mdwn
+* `remote.<name>.annex-cost`
+* `remote.<name>.annex-cost-command`
+
+$> grep '^\*.*web' doc/git-annex.mdwn 
+* `webapp`
+* `remote.<name>.annex-webdav`
+* `annex.web-options`
+
+$> grep '^\*.*url' doc/git-annex.mdwn
+* `addurl [url ...]`
+* `rmurl file url`
+* `importfeed [url ...]`
+* `registerurl [key url]`
+* `unregisterurl [key url]`
+* `remote.<name>.annex-rsyncurl`
+* `annex.security.allowed-url-schemes`
+
+```
+</details>
+
+but even with such command it would have made it not really fit my need -- I would like to assign costs and propagate that information through the clones without requiring users to install additional commands or configure their clones.
+
+Use case: 
+
+For the same file we provide API end-point which redirects to a minted url (with content-disposition etc), and file could be accessed directly from that url.  E.g. both 
+https://api.dandiarchive.org/api/dandisets/000027/versions/draft/assets/ff453f4c-a435-4a5d-a48b-128abca5ec47/download/
+and
+https://dandiarchive.s3.amazonaws.com/blobs/2db/af0/2dbaf0fd-5003-4a0a-b4c0-bc8cdbdb3826
+point to the same (small) file.
+
+I would like git-annex to know both, since if we migrate backend storage, I would like users to still be able to access via api url.  But by default, while still works, I would like them to access via direct url to s3.
+
+ATM, regardless of the order in which I add those two urls to a file, git-annex seems (didn't look in the code etc) to use them in a "sorted" order, so it would go for the API one, thus causing unnecessary url minting etc.  I would like to make direct url having lower cost so it would be preferred over the api one.
+
+May be there is a way already?  
+
+If not, I think it could be flexibly achieved if in `git annex config` I could provide url regexes with costs.  Then I could encode that information while allowing users/clones to tune it if becomes desired.  If possible, smth like
+
+```
+# assuming default cost of web remote 100 if it is
+cost url-https?://api.dandiarchive.org/.* = 200
+```
+
+or alike in my case. May be it could even be like `[+-]COST` so it would then add or subtract from the cost of the remote, thus allowing to account for the remote cost if assigned/set and costs are considered across remotes and their URLs.
+
+Alternative could be - a cost per url (while registerurl or addurl) but IMHO that might be too much, and harder to tune per specific clone "globally".
+
+PS question -- how to see the costs?  `annex whereis --json FILE` seems to not provide them.
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> Closing this since yarik said my suggestion would work. Even though I
+> think neither of us is entirely satisfied with it, I can't think of a
+> better approach. [[done]] --[[Joey]]
diff --git a/doc/todo/assign_costs_per_URL_or_better_repo-wide___40__regexes__41__/comment_1_55652562111e83129eb19a61da14ee4a._comment b/doc/todo/assign_costs_per_URL_or_better_repo-wide___40__regexes__41__/comment_1_55652562111e83129eb19a61da14ee4a._comment
new file mode 100644
index 0000000000..9684ac00ba
--- /dev/null
+++ b/doc/todo/assign_costs_per_URL_or_better_repo-wide___40__regexes__41__/comment_1_55652562111e83129eb19a61da14ee4a._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-05-04T14:33:42Z"
+ content="""
+Costs are information about the connection from the local repository to a
+remote, which is why they are stored only locally in the git config -- I
+may have much different cost than you to access the same repository.
+
+When there are multiple urls all claimed by the web remote, that's a
+single remote, and the code that looks at costs decides which remote is
+lowest cost, and tries that one first. When it gets down to the web remote,
+it tries the urls in whatever order it happens to have them.
+
+So, the proposed way to assign costs to urls could only change the order
+that urls are presented to the web remote. It would not let git-annex
+try to get first from web (cheap url), followed by another repo, followed
+by web (expensive url).
+
+What you can do is have a special remote, that claims all the relevent
+urls and then does its own ordering of them. Or perhaps different
+special remotes that claim different sets of urls, and assign costs to
+those remotes. (Using --sameas so the several remotes do not
+count as more than 1 copy.)
+"""]]
diff --git a/doc/todo/assign_costs_per_URL_or_better_repo-wide___40__regexes__41__/comment_2_0d1e17e92d6022552406fef144e8c104._comment b/doc/todo/assign_costs_per_URL_or_better_repo-wide___40__regexes__41__/comment_2_0d1e17e92d6022552406fef144e8c104._comment
new file mode 100644
index 0000000000..b14fa55db2
--- /dev/null
+++ b/doc/todo/assign_costs_per_URL_or_better_repo-wide___40__regexes__41__/comment_2_0d1e17e92d6022552406fef144e8c104._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2021-05-04T16:53:18Z"
+ content="""
+FWIW, verified that `git annex --debug initremote --sameas web datalad externaltype=datalad type=external encryption=none autoenable=true` makes `git-annex` to make `datalad` special remote to handle those urls.  And since we do not have any prioritization handling in datalad we also grab the first one (the api. one) returned by git-annex and proceed with it.
+
+So, indeed, if you do not like (or even just feel lukewarm) about an idea of adding costs within built-in `web` remote, feel welcome to close, and we will still have a way forward by providing such handling within datalad external special remote. It would be a bit sub-optimal since would require people to install datalad, but at least it would enable desired prioritization in some use cases (e.g. for QA `annex fsck --fast` run).
+
+And indeed with the singular cost (not even a range of costs) assigned/returned by a remote and no e.g. cost provisioned to be returned by CLAIMURL, I guess there is no (easy) way to mix-in the URL based costs into overall decision making to order the remotes.
+
+NB with `--sameas` trick above, `git-annex` doesn't even ask `datalad` with CLAIMURL and immediately passes `TRANSFER` of the key to `datalad` external remote.  Without `--sameas` - `git-annex` (8.20210330-g0b03b3d) doesn't even bother asking datalad (within `whereis` at least) on either it could CLAIMURL those... even if I assign `annex-cost = 1.0` for datalad remote.  Not sure yet if that is \"by design\".
+
+> When it gets down to the web remote, it tries the urls in whatever order it happens to have them.
+
+FWIW - I think I have tried to add them in different orders but it always went for the `api` one so I concluded that the order it has them is sorted and there is no way to \"tune it up\".
+
+P.S. I still wonder why I have some memory of git-annex supporting some (external) way to prioritize URLs... may be it was indeed \"craft a special remote to do that\"...
+"""]]
diff --git a/doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn b/doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn
new file mode 100644
index 0000000000..f5088ccee3
--- /dev/null
+++ b/doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn
@@ -0,0 +1,50 @@
+[[!meta title="webapp does not accept ssh alias for ssh remote"]]
+
+What steps will reproduce the problem?
+
+Using the assistant, create an SSH remote.  Try to use an alias as the name
+of the remote (e.g. I have a server which I have aliased to "homeworld" in
+my .ssh/config.  When I'm at home, that is an alias for 192.168.1.253.
+When I'm not at home, I edit .ssh/config so that "homeworld" becomes an
+alias for a hostname at no-ip.com.)  Despite the fact that "homeworld" is a
+viable ssh target because of the alias, the assistant doesn't recognize it
+as a valid host to ssh to.
+
+I had trouble with an ip address the first time I tried it but just tried
+it again and it worked fine, so please disregard that part of the title of
+this bug report.
+
+
+What is the expected output? What do you see instead?
+
+expected output = move to the "create a repository -- rsync or regular" page.
+observed output = "cannot resolve host name"
+
+
+What version of git-annex are you using? On what operating system?
+
+ Version: 3.20130102 OS X Lion
+
+
+Please provide any additional information below.
+
+I realize this is kind of a power user whine.  Using an ssh alias which
+does not correspond to an actual resolvable hostname (and cannot, because
+it's supposed to be a layer of indirection over the hostname) is not an
+everyday problem for an average user.
+
+> The assistant tries to resolve the hostname explicitly
+> to catch user's typos, and also expands it to a FQDN, to make
+> it more likely to be able to reach the host when roaming to other
+> networks.
+> 
+> Also, the assistant sets up it *own* .ssh/config hostname alias,
+> in order to make it use the special ssh key that it generates for the host.
+> So that is not compatable with using a ssh host alias you've set up.
+> Even if it knew about your alias, it would set up a new hostname alias, and
+> whatever machinery you have to update the alias would not work.
+>  
+> You can, of course, add git remotes using any ssh alias you like, by
+> hand, and restart the assistant and it will use them. --[[Joey]]
+
+[[!tag /design/assistant]]
diff --git a/doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address/comment_1_6b71a390fd16f593216793aec590d9a8._comment b/doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address/comment_1_6b71a390fd16f593216793aec590d9a8._comment
new file mode 100644
index 0000000000..6f4d00b2b7
--- /dev/null
+++ b/doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address/comment_1_6b71a390fd16f593216793aec590d9a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2014-05-22T20:05:54Z"
+ content="""
+A temporary workaround is to add an entry to /etc/hosts until the remote is added.
+"""]]
diff --git a/doc/todo/assistant_importtree.mdwn b/doc/todo/assistant_importtree.mdwn
new file mode 100644
index 0000000000..a8ee54d33b
--- /dev/null
+++ b/doc/todo/assistant_importtree.mdwn
@@ -0,0 +1,2 @@
+The assistant currently will export to exporttree=yes remotes, but it will
+not import from importtree=yes remotes.
diff --git a/doc/todo/assistant_parallel_file_transfers.mdwn b/doc/todo/assistant_parallel_file_transfers.mdwn
new file mode 100644
index 0000000000..aafddf0383
--- /dev/null
+++ b/doc/todo/assistant_parallel_file_transfers.mdwn
@@ -0,0 +1,15 @@
+Hi and thank you for an incredible piece of software and great work!
+
+I've noticed that when I add new files to a repository and I have my USB drive connected, the assistant alternate it's transfers of files. And only transfers one queued file at the time.
+
+file1 -->> Internet offsite computer
+file1 -->> USB drive
+file2 -->> Internet offsite computer
+file2 -->> USB drive
+
+
+I would prefer a logic where the assistant transfer files in parallel to my different repositories. I know that it might not be a good thing doing that with network accessed repositories, but when I have "low cost", locally attached USB drives it would be great if the transfers could be done in parallel.
+
+
+Is there a configuration option for this already?
+
diff --git a/doc/todo/assistant_should_detect_added_remotes.mdwn b/doc/todo/assistant_should_detect_added_remotes.mdwn
new file mode 100644
index 0000000000..4e690c8805
--- /dev/null
+++ b/doc/todo/assistant_should_detect_added_remotes.mdwn
@@ -0,0 +1,7 @@
+I think it would be useful if the assistant (when monitoring a repo) could automatically detect when the user adds a new remote to that repo. For example, right now, if I have two local repos (`repo1` and `repo2`) neither with any remotes and each is listed in `~/.config/git-annex/autostart` and I run `git annex assistant --autostart` then the assistant will detect files added to each remote but won't sync between them (since they have no remotes) per design.
+
+If I then add each repo as a remote of the other (from the command-line), assistant will still not sync files between the repos until I stop all the assistants running and then restart them. Presumably only on launch does the assistant check the list of remotes?
+
+I think this is perhaps causing issues for users not just on the command-line but also for users who create multiple local remotes from the webapp and then combine them, since the webapp is perhaps not restarting the assistant daemons after the combine operation? I'm not sure about this…
+
+[[!tag confirmed]]
diff --git a/doc/todo/assistant_should_detect_added_remotes/comment_1_1cadcd0d5c61a04bd1118d94e3fc7f45._comment b/doc/todo/assistant_should_detect_added_remotes/comment_1_1cadcd0d5c61a04bd1118d94e3fc7f45._comment
new file mode 100644
index 0000000000..0fc3e5e768
--- /dev/null
+++ b/doc/todo/assistant_should_detect_added_remotes/comment_1_1cadcd0d5c61a04bd1118d94e3fc7f45._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-03T17:48:38Z"
+ content="""
+The assistant watches for changes to the git-annex branch, and reloads its
+list of remotes within 60 seconds after a change.
+
+If you're using `git remote add`, that doesn't affect the git-annex branch,
+so the assistant won't notice the new remote. Once `git annex
+sync` with that remote, the git-annex branch will be updated and the
+assistant will notice it then.
+"""]]
diff --git a/doc/todo/assistant_should_detect_added_remotes/comment_2_2a282fcacad94b9590f5bc440ff6ea64._comment b/doc/todo/assistant_should_detect_added_remotes/comment_2_2a282fcacad94b9590f5bc440ff6ea64._comment
new file mode 100644
index 0000000000..061a5f93fc
--- /dev/null
+++ b/doc/todo/assistant_should_detect_added_remotes/comment_2_2a282fcacad94b9590f5bc440ff6ea64._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 2"
+ date="2018-12-08T17:09:27Z"
+ content="""
+Could the assistant put a file watch on `.git/config` to detect when new remotes are added/removed?
+
+I am pretty sure this user [assistant to have synced folders](http://git-annex.branchable.com/forum/assistant_to_have_synced_folders/) ran into this issue. They added two local remotes then hit the combine button, then looked for synced files. Assistant never started syncing, presumably for the reasons outlined in your comment. They did everything through the web gui so they really didn't have any expectation that they would need to manually restart all the assistant daemons after hitting the combine button.
+"""]]
diff --git a/doc/todo/assistant_should_detect_added_remotes/comment_3_35435a0b4d98483fa5c67759ae5baa35._comment b/doc/todo/assistant_should_detect_added_remotes/comment_3_35435a0b4d98483fa5c67759ae5baa35._comment
new file mode 100644
index 0000000000..25c0fa3ca5
--- /dev/null
+++ b/doc/todo/assistant_should_detect_added_remotes/comment_3_35435a0b4d98483fa5c67759ae5baa35._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 3"
+ date="2018-12-30T23:29:16Z"
+ content="""
+Linking to another poster asking for assistant to monitor changes to `~/.git/config`
+
+<https://git-annex.branchable.com/bugs/annex.autocommit_seems_ignored_for_new_files/>
+"""]]
diff --git a/doc/todo/assistant_support_hide-missing.mdwn b/doc/todo/assistant_support_hide-missing.mdwn
new file mode 100644
index 0000000000..9df2bcec8d
--- /dev/null
+++ b/doc/todo/assistant_support_hide-missing.mdwn
@@ -0,0 +1,13 @@
+While `git annex sync` supports branches set up by `git annex adjust
+--hide-missing`, the assisitant does not yet.
+
+This would invole:
+
+* The assistant also needs to scan the original branch when looking for
+  files to download.
+
+* The assistant ought to update the adjusted branch at some point after
+  downloads, but it's not clear when. Perhaps this will need to be deferred
+  until it can be done more cheaply, so it can do it after every file.
+
+[[!tag confirmed]]
diff --git a/doc/todo/assistant_web_switch_repo_Internal_Server_Error.mdwn b/doc/todo/assistant_web_switch_repo_Internal_Server_Error.mdwn
new file mode 100644
index 0000000000..722866c4f4
--- /dev/null
+++ b/doc/todo/assistant_web_switch_repo_Internal_Server_Error.mdwn
@@ -0,0 +1,55 @@
+## Steps to reproduce:
+
+- create 2 separate repos
+- Top right: Repository: path dropdown
+  - Select the other repository
+
+## Expected result
+
+I expect the UI to switch over to the other repo.
+
+## Actual result
+
+```
+Internal Server Error
+HttpExceptionRequest Request {
+  host                 = "127.0.0.1"
+  port                 = 52482
+  secure               = False
+  requestHeaders       = [("Accept-Encoding","")]
+  path                 = "/"
+  queryString          = "?auth=REDACTED"
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+  proxySecureMode      = ProxySecureWithConnect
+}
+ (ConnectionFailure Network.Socket.connect: <socket: 51>: does not exist (Connection refused))
+```
+
+## Context
+
+```
+git-annex version: 8.20210127
+build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.28 DAV-1.3.4 feed-1.3.0.1 ghc-8.10.3 http-client-0.7.4 persistent-sqlite-2.11.0.0 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: darwin x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+```
+
+This is macOS 11.2.1 (Big Sur), installed via `brew install git-annex`. I've tried the same behaviour on 2 separate macs, same error both times. It seems like the switching in the web UI is a bit tricky. I've also tried a few browsers (Safari, Chrome) and my dev browser without any ad blocking. It seems like there's an HTTP request to `/config/repository/switchto/...` which returns a 500.
+
+## Workaround
+
+It seems that if I stop the webapp, and start it again, it has actually switched repos. So it's a bit inconvenient, but usable nonetheless.
+
+## Thanks
+
+I've just started the missing of moving from nextcloud to git-annex after the second random deletion of data by nextcloud. I'm deeply grateful to the authors for giving me the confidence of git to manage my files. Wonderful.
diff --git a/doc/todo/assistant_web_switch_repo_Internal_Server_Error/comment_1_b4add1998a9a81fb2c95539408bbeb64._comment b/doc/todo/assistant_web_switch_repo_Internal_Server_Error/comment_1_b4add1998a9a81fb2c95539408bbeb64._comment
new file mode 100644
index 0000000000..3ba82122ac
--- /dev/null
+++ b/doc/todo/assistant_web_switch_repo_Internal_Server_Error/comment_1_b4add1998a9a81fb2c95539408bbeb64._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="git-annex.branchable.com@d12f3f46c9222459d17f96bc7be04f7cd03a6732"
+ nickname="git-annex.branchable.com"
+ avatar="http://cdn.libravatar.org/avatar/e3748ecfbbcafc96ccec69fb2db01c3f"
+ subject="comment 1"
+ date="2021-02-21T15:50:47Z"
+ content="""
+Apologies, I realise I think I filed this as a \"todo\" instead of under \"bugs\", apologies. I can't see how to move it unfortunately...
+"""]]
diff --git a/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters.mdwn b/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters.mdwn
new file mode 100644
index 0000000000..493c8e42db
--- /dev/null
+++ b/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters.mdwn
@@ -0,0 +1,18 @@
+Related is [todo/some way to get a list of options for a special remote of a given type](https://git-annex.branchable.com/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/) .
+
+At the moment there is no checks in place even for built-in special remotes on either provided special remote options/parameters are not mystyped, and either values of type `bool` are in correct form (`true`/`false` and not `on`/`off` etc)?  E.g.
+
+[[!format sh """
+(git-annex)hopa:~datalad/datalad/najafi-2018-nwb[git-annex]git
+$> git annex initremote datasets.datalad.org4 location=http://datasets.datalad.org/labs/churchland/najafi-2018-nwb/.git type=git mumbojumbo=crap autoenable=ofcause
+initremote datasets.datalad.org4 ok
+(recording state in git...)
+"""]]
+proceeds just fine although one of the options is not anything that special remote would care about, and a bool value for a known one is incorrectly specified (I often missed trailing `e` in `true`)
+
+At least for the built in special remotes (not external) this should be possible and would help to avoid issues such as [OpenNeuroOrg/datalad-service/issues/67](https://github.com/OpenNeuroOrg/datalad-service/issues/67) etc.  Ideally parameters verification should also be provisioned in external special remotes protocol.
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[done]] --[[Joey]] 
diff --git a/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_1_63d48db769863cdfe411404e8c26a399._comment b/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_1_63d48db769863cdfe411404e8c26a399._comment
new file mode 100644
index 0000000000..a3e2d62db4
--- /dev/null
+++ b/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_1_63d48db769863cdfe411404e8c26a399._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-06T16:12:01Z"
+ content="""
+There's a subtle backwards compatibility issue here: The stored config of a
+special remote is used when enabling it, so if an older version of
+git-annex is used to enable a remote, there might be a setting that it does
+not know about, or a value it doesn't understand. If that caused it to fail
+to enable the remote it wouldn't be possible to use it, at least w/o
+changing/removing the config.
+
+For example, autoenable=true did not used to be a config setting, but older
+versions of git-annex can still use remotes that have that.
+
+Another example is chunk=. While older versions of git-annex don't
+understand that, and so won't use chunks when storing/retrieving, 
+the newer git-annex falls back to getting the unchunked object.
+So things stored by the old git-annex can be retrieved by the new,
+but not vice-versa.
+
+Another example is S3's storageclass=. Older git-annex doesn't understand
+it, so uses the default storage class, but that behavior is interoperable
+with the new behavior.
+
+So the stored config of a remote should not be checked
+everytime the remote is instantiated, but only the new settings passed
+to initremote/enableremote. That will complicate the API, since currently
+the old and new config are combined together by enableremote.
+"""]]
diff --git a/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_2_afa8c10bd3b1df649c1f643430b300e9._comment b/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_2_afa8c10bd3b1df649c1f643430b300e9._comment
new file mode 100644
index 0000000000..d5c16d746f
--- /dev/null
+++ b/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_2_afa8c10bd3b1df649c1f643430b300e9._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-01-07T17:59:35Z"
+ content="""
+I was thinking about implementing this today, but the shattered attack got
+in the way. Anyway, it seems like most of a plan:
+
+* Make RemoteConfig contain Accepted or Proposed values. enableremote and initremote
+  set Proposed values; Accepted values are anything read from git-annex:remote.log
+  (update: done)
+* When a RemoteConfig value fails to parse, it may make sense to use a
+  default instead when it's Accepted, and error out when it's Proposed. This could
+  be used when parsing foo=yes/no to avoid treating foo=true the same as
+  foo=no, which some things do currently do 
+  (eg importtree, exporttree, embedcreds).
+  (update: Done for most yes/no and true/false parsers, surely missed a
+  few though, (including autoenable).)
+* Add a Remote method that returns a list of all RemoteConfig fields it
+  uses. This is the one part I'm not sure about, because that violates DRY.
+  It would be nicer to have a parser that can also generate a list of the
+  fields it parses.
+* Before calling Remote setup, see if there is any Proposed value in 
+  RemoteConfig whose field is not in the list. If so, error out.
+* For external special remotes, add a LISTCONFIG message. The program
+  reponds with a list of all the fields it may want to later GETCONFIG.
+  If the program responds with UNSUPPORTED-REQUEST then it needs to return
+  something that says any and all fields are allowed.
+* External special remotes are responsible for parsing the content of
+  GETCONFIG, as they do now, and can error out if there's a problem.
+
+Having a method return a list of fields will also allow
+implementing
+<https://git-annex.branchable.com/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/>.
+It may be worthwhile to add, along with the field name, a human readable
+description of its value.
+"""]]
diff --git a/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_3_f19ff768a3903f80dbaa378b74d2a7e3._comment b/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_3_f19ff768a3903f80dbaa378b74d2a7e3._comment
new file mode 100644
index 0000000000..45fa03522e
--- /dev/null
+++ b/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_3_f19ff768a3903f80dbaa378b74d2a7e3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-01-15T17:52:07Z"
+ content="""
+Unknown fields will now result in an error message. And values like yes/no
+and true/false get parsed upfront.
+
+External special remotes currently still accept all fields, so work still
+needs to be done to extend the protocol to list acceptable fields.
+"""]]
diff --git a/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_4_b031ee12622b1ed28b6ffc8c037f7d30._comment b/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_4_b031ee12622b1ed28b6ffc8c037f7d30._comment
new file mode 100644
index 0000000000..526b389028
--- /dev/null
+++ b/doc/todo/assure_correct_names___40__and_values__41___for_special_remotes_parameters/comment_4_b031ee12622b1ed28b6ffc8c037f7d30._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-01-17T21:15:16Z"
+ content="""
+Added LISTCONFIGS to external special remote protocol, and once your
+special remotes implement it, initremote will notice if the user provides
+any setting with the wrong name.
+
+(external special remotes could already verify the values of settings using
+GETCONFIG at the INITREMOTE stage, and use INITREMOTE-FAILURE to inform the
+user of bad or missing values)
+"""]]
diff --git a/doc/todo/auto-lock_files_after_one_edit.mdwn b/doc/todo/auto-lock_files_after_one_edit.mdwn
new file mode 100644
index 0000000000..e9164c46e2
--- /dev/null
+++ b/doc/todo/auto-lock_files_after_one_edit.mdwn
@@ -0,0 +1,5 @@
+Can an option be added to unlock a file in such a way that the next time it gets committed, it is automatically re-locked?  Or to just have this done for all unlocked files?
+
+It's a common use case to just do one edit / re-generation of a locked file.  If you forget to lock it (or a script that was supposed to lock it after modification fails in the middle), you end up with a permanently unlocked file, which can cause [[performance issues|bugs/git_status_extremely_slow_with_v7]] downstream, and also [[look odd when missing|todo/symlinks_for_not-present_unlocked_files]], lead to multiple copies when present (or risk [[annex.thin issues|bugs/annex.thin_can_cause_corrupt___40__not_just_missing__41___data]]), and leave the file open to inadvertent/unintended modification.  Also, locking the file manually litters the git log with commits that don't really change repo contents.
+
+[[!tag needsthought]]
diff --git a/doc/todo/auto-lock_files_after_one_edit/comment_1_afc78ecd06f0ee9a70ea6c89a8b63e46._comment b/doc/todo/auto-lock_files_after_one_edit/comment_1_afc78ecd06f0ee9a70ea6c89a8b63e46._comment
new file mode 100644
index 0000000000..4f2d451eff
--- /dev/null
+++ b/doc/todo/auto-lock_files_after_one_edit/comment_1_afc78ecd06f0ee9a70ea6c89a8b63e46._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2019-09-25T17:34:33Z"
+ content="""
+Maybe also, an option to auto-unlock the file right after commit?  E.g. based on `.gitattributes`.  Basically, unlocked files would look locally modified to `git`, but if their contents hasn't changed, the modification would just look like `typechange` from symlink to blob.  It can actually be useful to see all unlocked files this way.
+
+This of course negates the point of v7, but [[sometimes|forum/Preserving_the_v5_experience]] the v5 model is a better fit.
+"""]]
diff --git a/doc/todo/auto-lock_files_after_one_edit/comment_2_4a6274dd1da7746a5be673ffb0c5d520._comment b/doc/todo/auto-lock_files_after_one_edit/comment_2_4a6274dd1da7746a5be673ffb0c5d520._comment
new file mode 100644
index 0000000000..7d36fc8270
--- /dev/null
+++ b/doc/todo/auto-lock_files_after_one_edit/comment_2_4a6274dd1da7746a5be673ffb0c5d520._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-27T17:06:29Z"
+ content="""
+I think it should be possible for a pre-commit hook to do this.
+
+There are some subtleties to a pre-commit hook changing what's going to be
+committed, which I was happy to jettison when removing the v5 support. But
+it should be able to work at least as well as it did in v5.
+"""]]
diff --git a/doc/todo/avoid_storing_contentidentifier_log_for_borg.mdwn b/doc/todo/avoid_storing_contentidentifier_log_for_borg.mdwn
new file mode 100644
index 0000000000..453d31291f
--- /dev/null
+++ b/doc/todo/avoid_storing_contentidentifier_log_for_borg.mdwn
@@ -0,0 +1,20 @@
+Borg uses an empty ContentIdentifier for everything; it does not need to
+record anything. But that empty value gets stored in the log for each key
+that is stored in borg. This unncessarily bloats the size of the git-annex
+branch, by one content identifier per key stored in borg.
+
+I think that it also slows down importing many archives from borg,
+because for each of them it has to record the content identifier,
+which is always the same, but still results in a db write.
+
+Omitting storing any ContentIdentifier would break code such as
+Remote.Helper.ExportImport's retrieveKeyFileFromImport.
+
+If the borg Remote could indicate with a flag that it does not use
+ContentIdentifiers, then code like that could pass it a null
+ContentIdentifier without needing to read it from the db.
+
+Annex.Import uses getContentIdentifierKeys, but only when it's not
+thirdpartypopulated. So this change would not break that for borg,
+but a clean way to handle that would be to make it also return a null
+ContentIdentifier when the remote has the flag set. --[[Joey]]
diff --git a/doc/todo/batch_async.mdwn b/doc/todo/batch_async.mdwn
new file mode 100644
index 0000000000..634c05738f
--- /dev/null
+++ b/doc/todo/batch_async.mdwn
@@ -0,0 +1,75 @@
+Make --batch -J run multiple jobs at the same time, so big batch operations
+can potentially run faster.
+
+Currently, it does not, but it still accepts the combination of options.
+
+Hmm, probably most users of this will use --json too, and then the output
+for at least some commands already contains enough information so they can
+keep different async jobs straight:
+
+	(echo foo; echo bar) | git-annex add --batch --json
+	{"command":"add","success":true,"key":"SHA256E-s30--ce0c29e173009d77fa8803fae163b7c85920248add208bc378d465cae3087962","file":"foo"}
+	{"command":"add","success":true,"key":"SHA256E-s30--ce0c29e173009d77fa8803fae163b7c85920248add208bc378d465cae3087962","file":"bar"}
+
+Other commands not though; addurl does not include the url in its --json
+output (though it could be made to without breaking back-compat).
+
+Also the filename in --json output may get normalized to something
+other than the input. Eg, git-annex add, for "./foo" outputs "foo".
+(Due to relPathCwdToFile in batchStart, which is there to handle
+absolute filepaths. So even if that case were changed, it would need to
+normalize absolute filepaths.)
+
+Maybe the json output should include a field that mirrors the input that
+resulted in this line, be it a filename or an url, or a directory, or
+whatever.
+	
+	{"command":"add","input":["./foo"],"success":true,"key":"SHA256E-s30--ce0c29e173009d77fa8803fae163b7c85920248add208bc378d465cae3087962","file":"foo"}
+
+> This is now implemented on the batchasync branch, for all commands
+> that support json output.
+
+(Note that, --batch currently does not operate on directories.
+Because of the one line or reply per line of input rule.
+Adding such a field would go a long way toward allowing that, 
+if it were wanted later.)
+
+And some --batch commands like lookupkey do not support --json 
+(though could be made to).
+
+Some subcommands in --batch mode ouput a blank line instead of
+json when they don't need to do anything to handle the thing they were told
+to act on (eg, getting a file that is already present). (copy, drop, get,
+move, add, find, whereis). That's a bit of a problem since when it's async
+there would be no indication what thing they skipped,
+except for their other output about the things they didn't skip.
+
+> I looked at datalad's handling of this as an example, and it currently
+> ignores the blank line, not caring when nothing needs to be done.
+> Which seems about what you'd expect.. The only real reason the blank
+> line is there currently is so a program can write one batch line
+> and read one batch line in reply and keep things straight.
+> 
+> Would any program really care if git-annex didn't need to get a file
+> that was already present or skipped over a file that other options
+> told it not to operate on? Probably not. So, can probably get away with
+> leaving the blank line as-is.
+
+---
+
+Making the changes to --json output to address the above stuff, if
+possible, feels cleaner than wrapping input and output with a job id like
+the ASYNC extension does. Those changes would also generally be an
+improvement to json output in non-async mode.
+
+> Ok, the input field is implemented, and it seems we can probably
+> ignore the complication of the blank line for skipped input.
+> So, it should be possible to actually implement the concurrent
+> batch mode now. --[[Joey]]
+
+[[!tag projects/datalad]]
+
+> [[implemented|done]]. 
+
+> See <https://git-annex/bramchable.com/tips/using_git-annex_from_your_program/>
+> for some docs. --[[Joey]]
diff --git a/doc/todo/batch_async/comment_1_b68dcc98856f7b757e539c499db7ebd1._comment b/doc/todo/batch_async/comment_1_b68dcc98856f7b757e539c499db7ebd1._comment
new file mode 100644
index 0000000000..23ba505af0
--- /dev/null
+++ b/doc/todo/batch_async/comment_1_b68dcc98856f7b757e539c499db7ebd1._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-09-14T18:30:02Z"
+ content="""
+Started a batchasync branch for this.
+"""]]
diff --git a/doc/todo/batch_operations_for_remotes.mdwn b/doc/todo/batch_operations_for_remotes.mdwn
new file mode 100644
index 0000000000..a7638a0040
--- /dev/null
+++ b/doc/todo/batch_operations_for_remotes.mdwn
@@ -0,0 +1,3 @@
+Current special remote protocol works on one file at a time.  With some remotes, a batch operation can be more efficient, e.g. querying the status of many URLs in one API call.  It would be good if special remotes could optionally implement batch versions of their operations, and these versions were used by batch-mode git-annex commands.  Or maybe, keep the current set of commands but let the remote read multiple requests and then send multiple replies?
+
+[[!tag moreinfo]]
diff --git a/doc/todo/batch_operations_for_remotes/comment_1_9a2f21febec8f49c782e464973dbc4fc._comment b/doc/todo/batch_operations_for_remotes/comment_1_9a2f21febec8f49c782e464973dbc4fc._comment
new file mode 100644
index 0000000000..a9ec7789d8
--- /dev/null
+++ b/doc/todo/batch_operations_for_remotes/comment_1_9a2f21febec8f49c782e464973dbc4fc._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-03-19T17:41:19Z"
+ content="""
+What is being optimised here? A single external special remote process
+is already used for multiple operations, and the overhead is only
+in the necessary context switches between processes and pipe IO.
+
+Note that git-annex -J will start up several external special remote
+processes and distribute jobs between them. The way git-annex processes
+files, it never builds up a big list of queries to make later; each query or
+other operation needs to be completed before it knows what the next
+operation will be for a given key. So it seems hard to see how it could
+use something like this if it were in the protocol.
+"""]]
diff --git a/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit.mdwn b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit.mdwn
new file mode 100644
index 0000000000..46e85840f8
--- /dev/null
+++ b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit.mdwn
@@ -0,0 +1,6 @@
+ATM many commit messages in git-annex branch are just an "update".  But I wondered if it could be relatively simple to implement to be able to provide a custom commit message, e.g. by defining some environment variable (e.g. GIT_ANNEX_UPDATE_MESSAGE) during whatever process is initiating the actual commit?  sure thing there could be cases whenever multiple processes "contributed" to the changes which are finally "flushed" by committing, but imho it could provide a good way to annotate changes within git-annex branch at least to some degree.  E.g. I could use "update: added URLs to the files for datalad-archives remote" ;)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] as annex.commitmessage config. --[[Joey]]
diff --git a/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_1_c8836a164c8c1efedd5467233237bfd0._comment b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_1_c8836a164c8c1efedd5467233237bfd0._comment
new file mode 100644
index 0000000000..6d4f9b0267
--- /dev/null
+++ b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_1_c8836a164c8c1efedd5467233237bfd0._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-07T16:39:59Z"
+ content="""
+Such an env var could easily be supported.
+
+It's desirable to mostly keep the mantainace of the git-annex branch
+out of the user's view, because it's a complication that should not
+need to worry about.
+
+Keeping it in an env var does avoid complicating the discoverable
+interface with some parameter to specify the commit message. Another
+way would be to make the commit message configurable in git config.
+Then it could be overridden with -c. Seems like the user of this 
+feature is likely going to also use annex.alwayscommit=false sometimes
+in order to construct git-annex branch commits that bundle up several
+changes.
+
+Anyway, I'm curious what kind of use cases make using custom commit
+messages for the git-annex branch makes sense. I doubt that typical git
+workflows with cherry-picking patches, patch review, etc, work with that
+branch.
+"""]]
diff --git a/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_2_41a25215d9a1f635573d5e5f5c30fd62._comment b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_2_41a25215d9a1f635573d5e5f5c30fd62._comment
new file mode 100644
index 0000000000..4044f7d1b3
--- /dev/null
+++ b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_2_41a25215d9a1f635573d5e5f5c30fd62._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-07-31T14:27:17Z"
+ content="""
+My usecase is to be able to associate changes in main branches and in git-annex branch, so instead of non-informative \"update\" commit message it could carry e.g.
+
+    [DATALAD] Updated git/annex from a remote location
+    
+    URLs processed: 7
+     downloaded: 7
+     size: 17.1 GB
+    Files processed: 7
+     skipped: 7
+     overwritten: 7
+
+or I might even include the branch in which changes were done, e.g. short ones become
+
+    [DATALAD, incoming] Updated git/annex from a remote location
+    [DATALAD, incoming-processed] Added files from extracted archives
+    ...
+    
+Then looking at `git log git-annex` would allow me to quickly see what actions lead to \"updates\" in git-annex branch
+"""]]
diff --git a/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_3_5241eace21e873678a0fbb353f4ece69._comment b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_3_5241eace21e873678a0fbb353f4ece69._comment
new file mode 100644
index 0000000000..68432661f1
--- /dev/null
+++ b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_3_5241eace21e873678a0fbb353f4ece69._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-08-02T17:38:23Z"
+ content="""
+There are a few other messages than "update" that show up in some rare
+occasions including (message ++ " (recovery from race #"..) and
+"new branch for transition".
+
+And, there's "merging remote/git-annex into git-annex"
+which is common enough.
+
+I kind of have the feeling that the rare ones are rare enough
+that we might want to always use them, and only override 
+merging and update.
+"""]]
diff --git a/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_4_caf913b53a54ac010dba253fca1ef76e._comment b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_4_caf913b53a54ac010dba253fca1ef76e._comment
new file mode 100644
index 0000000000..fa3e71d147
--- /dev/null
+++ b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_4_caf913b53a54ac010dba253fca1ef76e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-08-02T17:46:51Z"
+ content="""
+OTOH, maybe merging is never something one would want to add a custom
+message for -- it's an entirely a function of the inputs -- and so only
+"update" should get replaced.
+"""]]
diff --git a/doc/todo/better_error_messages_for_local_remote.mdwn b/doc/todo/better_error_messages_for_local_remote.mdwn
new file mode 100644
index 0000000000..a66a0138ba
--- /dev/null
+++ b/doc/todo/better_error_messages_for_local_remote.mdwn
@@ -0,0 +1,13 @@
+When using a local git remote on eg a removable drive, error messages don't
+make clear if the problem occurred in the local git repo or the remote
+repo.
+
+For example, I was copying files to a removable drive and got an error
+about a broken git object, but it was not clear which repo had the broken
+object in it.
+
+This should be fixable by eg, catching all exceptions when running Annex
+operations on a remote, adding its path to the message and rethrowing.
+--[[Joey]]
+
+[[!tag confirmed]]
diff --git a/doc/todo/better_error_messages_for_local_remote/comment_1_094e6a7b62c8b81185cda06a62104f1f._comment b/doc/todo/better_error_messages_for_local_remote/comment_1_094e6a7b62c8b81185cda06a62104f1f._comment
new file mode 100644
index 0000000000..763c2aa377
--- /dev/null
+++ b/doc/todo/better_error_messages_for_local_remote/comment_1_094e6a7b62c8b81185cda06a62104f1f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="thk"
+ avatar="http://cdn.libravatar.org/avatar/bfef10a428769701aeee1db978951461"
+ subject="Also no clear error for permission problems"
+ date="2020-03-06T17:51:20Z"
+ content="""
+I was exporting (with exporttree) to a directory remote on an external ext4 formatted USB drive.
+As is usually the case, there was permission problem. My current user did not have write permission for one directory I was exporting to.
+git-annex just printed \"failed\" after it actually completed the file transfer with 100%.
+Even with --verbose and --debug I could not figure out the problem until I discovered the permission problem.
+"""]]
diff --git a/doc/todo/better_error_messages_for_local_remote/comment_2_4c8115fa0a41bd1cbecdcf7a4d9608ed._comment b/doc/todo/better_error_messages_for_local_remote/comment_2_4c8115fa0a41bd1cbecdcf7a4d9608ed._comment
new file mode 100644
index 0000000000..5bfbf7349b
--- /dev/null
+++ b/doc/todo/better_error_messages_for_local_remote/comment_2_4c8115fa0a41bd1cbecdcf7a4d9608ed._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="thk"
+ avatar="http://cdn.libravatar.org/avatar/bfef10a428769701aeee1db978951461"
+ subject="No clear error message for failing names on NTFS"
+ date="2020-03-07T12:50:19Z"
+ content="""
+I tried to export a tree to NTFS with a filename that contained spaces, single quotes and dots. Only after removing all of them the export succeeded. There error messages was just \"failed\".
+"""]]
diff --git a/doc/todo/better_error_messages_for_local_remote/comment_3_2dd5e994a8ce6352eac78cfd69934316._comment b/doc/todo/better_error_messages_for_local_remote/comment_3_2dd5e994a8ce6352eac78cfd69934316._comment
new file mode 100644
index 0000000000..1b122606e6
--- /dev/null
+++ b/doc/todo/better_error_messages_for_local_remote/comment_3_2dd5e994a8ce6352eac78cfd69934316._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-02-02T17:06:36Z"
+ content="""
+Neither of the above 2 comments are what this todo item is about, which is
+specfically local git remotes.
+
+However, the exception handling code was recently reworked, to make it
+display exceptions when things fail like described in those comments.
+"""]]
diff --git a/doc/todo/better_mangling_of_filenames_in_views_via_unicode.mdwn b/doc/todo/better_mangling_of_filenames_in_views_via_unicode.mdwn
new file mode 100644
index 0000000000..31337643fc
--- /dev/null
+++ b/doc/todo/better_mangling_of_filenames_in_views_via_unicode.mdwn
@@ -0,0 +1,28 @@
+Currently views mangle filenames to be unique by converting a file 
+named "foo/bar.ext" to "bar_%foo.ext". That is kind of ugly and weird.
+
+But also in views, metadata like author="fred/barney" is made into a
+directory that looks like "fred/barney" but the / is a different unicode
+character that looks like a regular /.
+
+So, why not also use that in the filename mangling? Then a view
+could have a "fred/barney" subdirectory containing a "foo/bar.ext" file!
+
+The unicode might pose challenages for users typing the filename, but
+probably users will tab complete or use a gui anyway. If that did cause a
+problem for some users, there could be a config added to disable the unicode.
+
+How to handle upgrading git-annex when a view branch is checked out,
+if this change is made? It seems it would need to handle both the new and
+the old names when unmangeling (in dirFromViewedFile). Perhaps something
+additional could be recorded when entering a view branch that indicates what
+kind of name mangling was used, so it doesn't have to try both.
+--[[Joey]]
+
+> When several files are in a deep directory tree like `foo/bar/baz`, 
+> that would be an annoying common prefix to deal with, which the current
+> mangling avoids. So perhaps keeping it postfix is still a good idea, but
+> it could still use the psdudoslash. Eg, `somefile@foo/bar/baz.ext`?
+> --[[Joey]]
+
+Related: [[Configuring_metadata_view_filenames]]
diff --git a/doc/todo/better_mangling_of_filenames_in_views_via_unicode/comment_1_85eb622f3e651ad3cd42def62e2a83fd._comment b/doc/todo/better_mangling_of_filenames_in_views_via_unicode/comment_1_85eb622f3e651ad3cd42def62e2a83fd._comment
new file mode 100644
index 0000000000..8cd2816477
--- /dev/null
+++ b/doc/todo/better_mangling_of_filenames_in_views_via_unicode/comment_1_85eb622f3e651ad3cd42def62e2a83fd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="long filenames in view"
+ date="2023-02-08T22:11:30Z"
+ content="""
+Another thing to consider is the too-long-filenames problem, especially on filesystems like ecryptfs which have a max filename length of 144 chars or so. I don't know if git-annex caps the filename length somehow, however I have run into problems of too long filenames when entering a view on ecryptfs.
+"""]]
diff --git a/doc/todo/better_mangling_of_filenames_in_views_via_unicode/comment_2_b6d583625aa8821bde31464e8f19a34f._comment b/doc/todo/better_mangling_of_filenames_in_views_via_unicode/comment_2_b6d583625aa8821bde31464e8f19a34f._comment
new file mode 100644
index 0000000000..ac482f6e1c
--- /dev/null
+++ b/doc/todo/better_mangling_of_filenames_in_views_via_unicode/comment_2_b6d583625aa8821bde31464e8f19a34f._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-02-10T18:34:36Z"
+ content="""
+Hardly the only place ecryptfs's filename length limits have caused
+problems to git-annex users. SHA256, for example is generally too long for
+it.
+
+It seems to me that the only other thing git-annex could do re mangling
+filenames in views is to append a SHA1 of the path to the filename. 
+Or perhaps when there is a "foo", use the name "foo.2" for the second foo.
+That would also guarantee it's unique, but it seems strictly worse than the
+current behavior of using the path for that. It prevents the user
+from telling which of two "foo" files is which. (Also it would need a
+lookup table to be maintained.)
+
+I think it's ok if a feature can't be used on a filesystem that is too
+limited to support it.
+"""]]
diff --git a/doc/todo/better_message_for_external_special_remote_protocol_mismatch.mdwn b/doc/todo/better_message_for_external_special_remote_protocol_mismatch.mdwn
new file mode 100644
index 0000000000..6380701855
--- /dev/null
+++ b/doc/todo/better_message_for_external_special_remote_protocol_mismatch.mdwn
@@ -0,0 +1,27 @@
+git-annex's handling of an external special remote that sends VERSION 2 is not
+stellar currently:
+
+	joey@darkstar:~/tmp/b>git-annex initremote t type=external externaltype=test encryption=none 
+	initremote t 
+	  external special remote protocol error, unexpectedly received "CONFIG directory store data here" (command not allowed at this time)
+	
+	git-annex: unable to use special remote due to protocol error
+
+	joey@darkstar:~/tmp/b>git-annex copy --to t
+	
+	  external special remote protocol error, unexpectedly received "UNSUPPORTED-REQUEST" (command not allowed at this time)
+
+	  external special remote protocol error, unexpectedly received "UNSUPPORTED-REQUEST" (command not allowed at this time)
+	copy x 
+	  external special remote protocol error, unexpectedly received "UNSUPPORTED-REQUEST" (command not allowed at this time)
+	(unable to use special remote due to protocol error) failed
+	copy: 1 failed
+
+Protocol debug shows what's happening:
+
+	[2023-03-28 16:00:09.361602472] (Annex.ExternalAddonProcess) /home/joey/bin/git-annex-remote-test[3] --> VERSION 2
+	[2023-03-28 16:00:09.361764519] (Annex.ExternalAddonProcess) /home/joey/bin/git-annex-remote-test[3] <-- ERROR unsupported VERSION
+	[2023-03-28 16:00:09.361897595] (Annex.ExternalAddonProcess) /home/joey/bin/git-annex-remote-test[3] <-- EXTENSIONS INFO GETGITREMOTENAME ASYNC
+	[2023-03-28 16:00:09.362112912] (Annex.ExternalAddonProcess) /home/joey/bin/git-annex-remote-test[3] --> UNSUPPORTED-REQUEST
+	[2023-03-28 16:00:09.362212948] (Annex.ExternalAddonProcess) /home/joey/bin/git-annex-remote-test[3] <-- PREPARE
+	[2023-03-28 16:00:09.362332494] (Annex.ExternalAddonProcess) /home/joey/bin/git-annex-remote-test[3] --> UNSUPPORTED-REQUEST
diff --git a/doc/todo/better_way_to_get_missing_files.mdwn b/doc/todo/better_way_to_get_missing_files.mdwn
new file mode 100644
index 0000000000..5ee1c895cb
--- /dev/null
+++ b/doc/todo/better_way_to_get_missing_files.mdwn
@@ -0,0 +1,26 @@
+Currently in a `git annex adjust --hide-missing` branch, the only way to
+get missing files is to run `git annex sync --content`, with appropriate preferred
+content settings or with `-C path` to get a specific path. This is kind of
+klunky for ad-hoc getting files.
+
+It would be possible to make `git annex get`, `git annex copy --from remote`, etc
+operate on hidden files. Some of the infrastructure is there; it may be as
+simple as using LsFiles.inRepoOrBranch instead of LsFiles.inRepo to seek
+the files.
+
+Open questions:
+
+* Would it make more sense for this to be the default behavior when in the
+  adjusted branch, or for it to be an option, like "--branch=master"?
+
+  One advantage to the latter is that it would also be usable in bare
+  repos, or if you just for some reason want to get files present in some
+  other branch than the current one.
+
+  The former might be easier, but it could also be kind of surprising.
+  `git annex get .` would download tons of files, which `ls` doesn't
+  display.
+
+  Of course, both things could be supported too.
+
+[[!tag needsthought]]
diff --git a/doc/todo/bittorrent__58___support_offline_operation_and_verification.mdwn b/doc/todo/bittorrent__58___support_offline_operation_and_verification.mdwn
new file mode 100644
index 0000000000..bfee0e7d9a
--- /dev/null
+++ b/doc/todo/bittorrent__58___support_offline_operation_and_verification.mdwn
@@ -0,0 +1,77 @@
+adding torrents whose data is already present on disk or in the annex seems not
+to be supported right now.
+
+let's assume for example that the files were obtained by means outside of
+git-annex' scope, and that all files in here were `git annex add`ed and
+committed:
+
+    .
+    ├── chaos-math_multi-language_1080p_mkv.ea15601881aa1be1.torrent
+    └── chaos-math_multi-language_1080p_mkv
+        ├── 01. Motion and determinism - Panta Rhei [1080p].mkv
+        ├── [...]
+        ├── 10. Générique Chaos - French [1080p].mkv
+        └── subtitles
+            ├── Chaos1_ar.srt
+            ├── [...]
+            └── README.txt
+
+starting the `addurl` from a local file is supported as described in the
+comment to [[special_remotes/bittorrent]], but then goes ahead to download all
+the data in a different location. neither can be used the `--file` option
+(because it's a multi-file torrent) nor the `--pathdepth` option (because it
+would result in the very filename already used for the .torrent file), so first
+i'd have to rename the torrent directory, then start the addurl:
+
+    $ mv chaos-math_multi-language_1080p_mkv _tmp_annex_test_chaos_math_multi_language_1080p_mkv.ea15601881aa1be1.torrent
+    $ git annex addurl file:///tmp/annex-test/chaos-math_multi-language_1080p_mkv.ea15601881aa1be1.torrent
+
+even then, most of the files in the torrent are downloaded again, because the
+file names are meddled with by git-annex (`01. Motion and determinism - Panta Rhei [1080p].mkv`
+becomes `01._Motion_and_determinism___Panta_Rhei__1080p_.mkv`). and if the
+files come pre-renamed, their content does *not* get checked against the
+torrent info file (with all files pre-renamed and some subjected to random
+bit-flipping, the whole torrent was still accepted and entered as the wrong
+hash file's web remote).
+
+suggestions
+===========
+
+to make git-annex suitable for archiving torrents, i'd like to suggest the
+following additions:
+
+* add an option to switch off the file name meddling. (both file systems
+  and tools nowadays accept whitespace in file names, and all but
+  you-know-which do support colons and other characters except '\0' and '/').
+  this would have the additional benefit of making a http/ftp view of the
+  repository suitable as a [BEP19](http://bittorrent.org/beps/bep_0019.html)
+  web seed.
+
+* support `--file` to mean the base directory of a multi-file download, or just
+  pick the directory file name from inside the torrent info's directory name
+  (without that, the BEP19 use case would require explicit renaming).
+
+* before adding the `timestamp 1 $URL#n` line to the .log.web records of a
+  locally present file, check against the hashes from the torrent. (this may
+  require adjacent files from the torrent to be present, but it should be
+  complete anyway at check-in time).
+
+related issues / suggestions
+============================
+
+* especially on systems where file name meddling can not be turned off,
+  guessing suitable present files from their length could be worth considering,
+  as under those conditions, it might be impossible to find the already
+  downloaded file from its name (as the original downloading torrent client
+  might have used a different filename escaping scheme). with those guesses, it
+  would be up to aria2c to determine whether that file fits or not, and
+  download without complaining on demand.
+
+* to later allow seeding from the downloaed torrent, it'd be nice to have a
+  less convoluted way of always having the .torrent file present than
+  constructing a `file:///` url of it. having `addurl` (and thus also `get`
+  when dereferencing the .log.web entry) accept local file names would be
+  practical; a `--additionally-raw` option on `addurl` (or equivalent setting)
+  that stores the torrent file in git or git-annex would be nice.
+
+--[[chrysn]]
diff --git a/doc/todo/bittorrent__58___support_offline_operation_and_verification/comment_1_ab16dfb6c3fe2a70ddfb0cee287c6127._comment b/doc/todo/bittorrent__58___support_offline_operation_and_verification/comment_1_ab16dfb6c3fe2a70ddfb0cee287c6127._comment
new file mode 100644
index 0000000000..47eddfaeac
--- /dev/null
+++ b/doc/todo/bittorrent__58___support_offline_operation_and_verification/comment_1_ab16dfb6c3fe2a70ddfb0cee287c6127._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-10-17T20:05:51Z"
+ content="""
+The filename **sanitization** is needed for security reasons. A
+bittorrent file could contain `../` and similar evil which should not be
+allowed to be written to disk as-is. Or control characters which could
+cause an exploit via terminal key remapping. Or filenames starting with
+dashes to make an unguarded `rm *` end up expanding to `rm -rf something`.
+
+I'd not be surprised if whatever bittorrent program you used to download
+that does some filename sanitization too. Opinions on safe sanitization
+will vary, so it's not practical to expect git-annex and multiple
+bittorrent programs to behave identically.
+
+----
+
+It would be possible to make `addurl --file` usable with a multi-file
+torrent. Something like:
+
+	git annex addurl http://example.com/foo.torrent --file bar.mkv
+	That url contains multiple files; pick the one that corresponds to
+	local file "bar.mkv", and pass it in the --subfile option
+		bar.sub
+		bar.mkv
+		README.txt
+	Eg: git annex addurl 'http://example.com/foo.torrent' --file 'bar.mkv' --subfile 'bar.mkv'
+
+Of course this could be skipped if the torrent only contains one file
+with the same size and name as the `--file` file.
+
+I don't know if such an interface would be too annoying to be worth
+using in your use case or not?
+"""]]
diff --git a/doc/todo/bittorrent__58___support_offline_operation_and_verification/comment_2_262f9d68a865300d894c4077e0e8a70c._comment b/doc/todo/bittorrent__58___support_offline_operation_and_verification/comment_2_262f9d68a865300d894c4077e0e8a70c._comment
new file mode 100644
index 0000000000..781af4ef6c
--- /dev/null
+++ b/doc/todo/bittorrent__58___support_offline_operation_and_verification/comment_2_262f9d68a865300d894c4077e0e8a70c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/bf293be5f036c0b6a1ac26519c8b6b07bfe749b971329c5014e8d84b53579735"
+ subject="comment 2"
+ date="2016-10-24T13:00:56Z"
+ content="""
+the `--file`/`--subfile` syntax would be workable; i'd probably employ a dedicated script to either know the sanitization mapping of the downloading client or to do heuristics based on file sizes. (side note on sanitization mappings: at least transmission seems to map every sane name through the identity map).
+
+i'm worried though that adding the pre-downloaded files file-by-file will then make it harder for git-annex to do a verified check-in; if, for example, we have a two-file torrent, and add the first one, git-annex can't veriyf that file because the second half of its last chunk is missing. unless git-annex started a download of the last chunk, it couldn't be sure that the #1 .log.web line is valid, and would need to keep that in some unverified staging area a la \"./file1 could be ./two-part.torrent#1, but i couldn't check that yet\", and only commit that information when file2 is added.
+"""]]
diff --git a/doc/todo/build_a_user_guide.mdwn b/doc/todo/build_a_user_guide.mdwn
new file mode 100644
index 0000000000..1fcf9bf939
--- /dev/null
+++ b/doc/todo/build_a_user_guide.mdwn
@@ -0,0 +1,45 @@
+there's a lot of good documentation on this wiki, but it's hard to find sometimes. it's also unclear if we should look in the [[git-annex]] manpage or elsewhere in the wiki or where. this is a typical problem with the use of wikis for documentation: it's there, but hard to find. it doesn't mean a wiki shouldn't be used but, as with any user manual, special care needs to be taken about structure, organisation and making sure the manual is exhaustive.
+
+a good example of this problem is [[todo/document_standard_groups_more_extensively_in_the_UI]]. --[[anarcat]]
+
+update: a beginning of this may be the the [[workflow]] page but it lacks a lot of details... 
+
+So we have those entry points so far:
+
+  * [[git-annex]] - the manpage
+  * [[walkthrough]] - "A walkthrough of some of the basic features of git-annex, using the command line", described as "only one possible workflow for using git-annex"
+  * [[assistant]] - a whole subtree of pages describing the assistant, includes a [[assistant/quickstart]] - introduction to the assistant with a series of screenshots, described in [[walkthrough]] as "If you don't want to use the command line, see quickstart instead.", linked from the [[assistant]] page
+  * [[workflow]] - a summary of the different workflows that git-annex can use
+  * [[special remotes]] - a good list of "supported backends", which may be a better wording
+  * inversely, [[not]] is what is *not* supported, obviously
+  * [[install]] - how to install git-annex, of course
+  * [[tips]] - a mish-mash list of "how to do X in git-annex", 68 pages at the time of writing
+  * there's the "details" section on the frontpage which covers lots of the [[internals]], [[design]] and so on
+  * there are also what i consider to be "leaf" pages like [[how it works]] or [[sync]] there
+
+So it seems the fundamentals of such a user guide are there. It's just a matter of grouping this in a meaningful way.
+
+I am thinking the following structure may be a good basis:
+
+ * Introduction
+   * [[how it works]]?
+   * ...?
+ * [[Install|install]]
+ * Walkthrough
+   * [[comandline|walkthrough]]
+   * [[graphical|assistant/quickstart]]?
+ * How do I...
+   * [[Supported backends|special remotes]]
+   * [[Unsupported features|not]]
+   * [[split repositories|tips/splitting_a_repository]]
+   * [[merge repositories|tips/migrating_two_seperate_disconnected_directories_to_git_annex]]
+   * deal with lots of files: [[tips/Repositories_with_large_number_of_files]] or merge into [[scalability/]]?
+   * decide which files go where? something about [[preferred_content]] and [[preferred_content/standard_groups/]]?
+   * sort and regroup the best [[tips]] pages
+ * Troubleshooting / FAQ?
+   * [[Common mistakes|tips/antipatterns]]
+   * sort out the best of [[forums]] and [[tips]] that commonly occur
+ * [[Design]]
+   * [[internals]]
+   * [[encryption]]
+   * ... etc - all the developer stuff users shouldn't usually have to know unless they care about performance or need to reimplement something
diff --git a/doc/todo/cache_key_info.mdwn b/doc/todo/cache_key_info.mdwn
new file mode 100644
index 0000000000..805a45ca74
--- /dev/null
+++ b/doc/todo/cache_key_info.mdwn
@@ -0,0 +1,42 @@
+Most of git-annex is designed to be fast no matter how many other files are
+in the annex. Things like add/get/drop/move/fsck have good locality;
+they will only operate on as many files as you need them to. 
+
+(git commit can get a little slow with a great deal of files,
+but that's out of scope -- and recent git-annex versions use queuing
+to save git add from piling up too much in the index.)
+
+But currently two git-annex commands are quite slow when annexes become large
+in quantity of files. These are unused and status.
+(Both have --fast versions that don't do as much).
+> (Update: status has become acceptably fast; most of its slowdown was due to using a bad data structure; scanning the tree is not particularly slow and it no longer looks at the git-annex branch.)
+
+unused is slow because it needs two pieces of information that are not
+quick to look up, and require examining the whole repo, very seekily:
+
+1. The keys present in the annex. Found by looking thru .git/annex/objects
+2. The keys referenced by files in git. Found by finding every file
+   in git, and looking at its symlink.
+
+Of these, the first is less expensive (typically, an annex does not have every
+key in it). It could be optimized fairly simply, by adding a database
+of keys present in the annex that is optimised to list them all. The
+database would be updated by the few functions that move content in and
+out.
+
+The second is harder to optimise, because the user can delete, revert,
+copy, add, etc files in git at will, and git-annex does not have a good way
+to watch that and maintain a database of what keys are being referenced.
+
+It could use a post-commit hook and examine files changed by commits, etc.
+But then staged files would be left out. It might be sufficient to 
+make --fast trust the database... except unused will suggest *deleting*
+data if nothing references it. Or maybe it could be required to have a
+clean tree with nothing staged before running git-annex unused.
+
+Anyway, this is a semi-longterm item for me. --[[Joey]] 
+
+> Update: It seems like #2 has been accomplished now, the keys database
+> tracks associated files in all cases now. Although with the caveat
+> that there can be stale information sometimes, so it might still not be
+> useful for these purposes. --[[Joey]]
diff --git a/doc/todo/cache_key_info/comment_1_578df1b3b2cbfdc4aa1805378f35dc48._comment b/doc/todo/cache_key_info/comment_1_578df1b3b2cbfdc4aa1805378f35dc48._comment
new file mode 100644
index 0000000000..086e7f3e84
--- /dev/null
+++ b/doc/todo/cache_key_info/comment_1_578df1b3b2cbfdc4aa1805378f35dc48._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2011-05-17T07:27:02Z"
+ content="""
+Sounds like a good idea.
+
+* git annex fsck (or similar) should check/rebuild the caches
+* I would simply require a clean tree with a verbose error. 80/20 rule and defaulting to save actions.
+"""]]
diff --git a/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__.mdwn b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__.mdwn
new file mode 100644
index 0000000000..7647050dae
--- /dev/null
+++ b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__.mdwn
@@ -0,0 +1,12 @@
+May be it is already available and thus not really todo (feel welcome to close then or I will), and/or I have asked before, but I failed to find it.  Sorry if duplicating the issue.
+
+In some scenarios we do know ahead of time url + size + filename (thus extension) + corresponding checksum for the content. We would like to implement `addurl` which would not even talk to the remote server but just "mint" corresponding path to the key under `.git/annex/objects` and `registerurl` to it.  But I failed to find a convenience annex command which would allow us to get the full key (accounting for `E` the way git annex does), and full path to it (thus adding `DIRHASH` which special remotes could "query", and which is appropriate given the repository settings).
+
+I made subject prefixed with `calckey`  since it seems like the closest hit but it does need an actual file.
+
+edit1: I was pointed to [forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/#comment-a80b2371012dda93ad7fb4926af91b48](https://git-annex.branchable.com/forum/Is_it_possible_adding_files_to_git_annex_bypassing___40__some_parts_of__41___the_git_annex_tools/#comment-a80b2371012dda93ad7fb4926af91b48) which seems to be the closest hit, but relies on assuming how extension is extracted by annex, which might be incorrect for some files.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_1_c81e5d438b06e28392e4ae789a84a2e8._comment b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_1_c81e5d438b06e28392e4ae789a84a2e8._comment
new file mode 100644
index 0000000000..882827c6f2
--- /dev/null
+++ b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_1_c81e5d438b06e28392e4ae789a84a2e8._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-11-12T15:45:01Z"
+ content="""
+Any extension you pick to use would work fine; it's not a value that needs
+to be calculated in a long-term reproducible way, and git-annex has refined
+the extensions it picks repeatedly.
+
+I'm wary about exposing a way for git-annex to calculate the extension.
+It risks a slippery slope to exposing other internal details of how other
+backends (eg URL) construct parts of their keys. Especially with the
+external backends existing now.
+
+This does generate the path to the annex object:
+
+	git annex examinekey $KEY --format='.git/annex/objects/${hashdirmixed}${key}/${key}'
+
+Except, hmm, when the repo is tuned with annex.tune.objecthash1=true
+it does not take that into account. And if the repo is tuned with
+annex.tune.objecthashlower=true that needs to be `${hashdirlower}` instead.
+
+I think it would be a good idea to add something to examinekey that
+simplifies this, eg `${objectpath}` that would exand to the full path.
+Taking the tuning edge cases into account and also future-proofing the
+interface.
+"""]]
diff --git a/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_2_2cdaffbc72d5ef197a3ef7ffb306312e._comment b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_2_2cdaffbc72d5ef197a3ef7ffb306312e._comment
new file mode 100644
index 0000000000..2d0046c684
--- /dev/null
+++ b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_2_2cdaffbc72d5ef197a3ef7ffb306312e._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-11-12T16:47:12Z"
+ content="""
+Another approach would be to generate a SHA256 key, make the annex link,
+and then use `git-annex migrate --backend=SHA256E` to convert the annex link.
+
+And hmm, that does point toward a way to use the existing backend API
+cleanly. Why bother with writing out the symlinks only to have migrate
+convert them? The fastMigrate API has well-defined inputs, so we can just
+expose it.
+
+Eg:
+
+	git-annex examinekey SHA256--xxx --format="${key} ${objectpath}" \
+		--migrate-to-backend=SHA256E --filename=foo.tar.gz
+
+--batch would need to input the filename as well as the key when
+used with --migrate-to-backend.
+"""]]
diff --git a/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_3_4520660c0f66bd73158887f22586886e._comment b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_3_4520660c0f66bd73158887f22586886e._comment
new file mode 100644
index 0000000000..728d3e3f5e
--- /dev/null
+++ b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_3_4520660c0f66bd73158887f22586886e._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-11-12T16:59:34Z"
+ content="""
+Implemented examinekey ${objectpath} and ${objectpointer}.
+"""]]
diff --git a/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_4_ee750e205acefe400d13c3a5e967ca3b._comment b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_4_ee750e205acefe400d13c3a5e967ca3b._comment
new file mode 100644
index 0000000000..38001fd3a7
--- /dev/null
+++ b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_4_ee750e205acefe400d13c3a5e967ca3b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-11-12T18:08:37Z"
+ content="""
+Implemented examinekey --migrate-to-backend
+"""]]
diff --git a/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_5_ec644589ec44a442dc2f3bd2244c9800._comment b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_5_ec644589ec44a442dc2f3bd2244c9800._comment
new file mode 100644
index 0000000000..aa249dacd2
--- /dev/null
+++ b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_5_ec644589ec44a442dc2f3bd2244c9800._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2020-11-14T02:00:13Z"
+ content="""
+Woohoo -- thank you Joey!
+
+Here is my complete example which seems to work quite neatly.  One aspect which you might (or not -- shouldn't matter to me but bash people might appreciate): could \"${filename}\" (if provided to examinekey) be passed into `format` as well? that would allow for easy looping like in this example, but on more than one key at a time.
+
+Unrelated, just curious -- what is the best way to \"chain\" multiple batch processes in bash, like here `examinekey` and `registerurl`?
+
+
+```bash
+$> cat ./addurl-uberfast.sh
+#!/bin/bash
+
+export PS4='> '
+set -x
+set -eu
+cd \"$(mktemp -d ${TMPDIR:-/tmp}/dl-XXXXXXX)\"
+
+md5=f92bbc617f8c8714a251f1f208af37a0
+size=6605
+filename=GLwDrawA.h
+url=http://www.onerussian.com/tmp/$filename
+
+git init
+git annex init
+
+echo MD5-s$size--$md5 $filename | \
+ git-annex examinekey --batch --format='${key} ${objectpath}\n' --migrate-to-backend=MD5E | \
+ while read key objectpath; do
+    git-annex registerurl \"$key\" \"$url\"
+    # examinekey does not know ${filename} in its format so such looping isn't exactly
+    # possible easily in bash ATM
+    ln -s \"$objectpath\" \"$filename\"
+    git add \"$filename\"
+    git annex get \"$filename\"
+    git annex drop \"$filename\"
+ done
+```
+"""]]
diff --git a/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_6_aa8c191593789900e966a37f9117dd97._comment b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_6_aa8c191593789900e966a37f9117dd97._comment
new file mode 100644
index 0000000000..9eb50aa4a6
--- /dev/null
+++ b/doc/todo/calckey___91__--path__93___given_a_checksum_and_filename__63__/comment_6_aa8c191593789900e966a37f9117dd97._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-11-16T13:52:12Z"
+ content="""
+Good idea, I added ${file}
+"""]]
diff --git a/doc/todo/calckey_cannot_be_used_outside_of_git_repo.mdwn b/doc/todo/calckey_cannot_be_used_outside_of_git_repo.mdwn
new file mode 100644
index 0000000000..06645a196b
--- /dev/null
+++ b/doc/todo/calckey_cannot_be_used_outside_of_git_repo.mdwn
@@ -0,0 +1,11 @@
+Not sure if this is a bug or a feature request, but calckey can only be used while inside a git repository (though the specified file can be anywhere).
+
+Can this be changed so it can be run from anywhere?
+
+    ~$ git annex version
+    git-annex version: 6.20160613-g1e4e6f4
+
+    ~$ git annex calckey /some/file/some/wh.ere
+    git-annex: Not in a git repository.
+    CallStack (from HasCallStack):
+      error, called at ./Git/CurrentRepo.hs:55:37 in main:Git.CurrentRepo
diff --git a/doc/todo/calckey_cannot_be_used_outside_of_git_repo/comment_1_c54b53c5f81132bedf75eb6b439a202d._comment b/doc/todo/calckey_cannot_be_used_outside_of_git_repo/comment_1_c54b53c5f81132bedf75eb6b439a202d._comment
new file mode 100644
index 0000000000..6a9f823028
--- /dev/null
+++ b/doc/todo/calckey_cannot_be_used_outside_of_git_repo/comment_1_c54b53c5f81132bedf75eb6b439a202d._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-05T16:17:22Z"
+ content="""
+Well, calckey's behavior is influenced by the annex.backends setting,
+so it might behave differently when run in a different git repo, or outside
+any git repo.
+
+In fact, `git annex calckey` currently can be run in a git repo that is not
+a git-annex repo; it does not check if the repo is initialized for
+git-annex (which many commands do). The failure about "Not in a git
+repository." comes when it tries to run code in the Annex monad, which 
+requires a git repository.
+
+To support being run without being in a git repo at all would
+really need an entirely separate code path to be implemented, not using the
+Annex monad, and so necessarily not looking at git configs. It's doable,
+but it would be a lot of work; I'd need some convincing motivation to add
+a lot of code to accomplish that.
+"""]]
diff --git a/doc/todo/change_git-annex-import_not_to_delete_original_files_by_default.mdwn b/doc/todo/change_git-annex-import_not_to_delete_original_files_by_default.mdwn
new file mode 100644
index 0000000000..e4482c5a1f
--- /dev/null
+++ b/doc/todo/change_git-annex-import_not_to_delete_original_files_by_default.mdwn
@@ -0,0 +1,7 @@
+[[git-annex-import]] by default deletes the original files.  Keeping them by default would be better. "import" in many other tools (e.g. the bioinformatics tool [Geneious](https://www.geneious.com/)) means a non-destructive import.  The short description of `git-annex-import` on its man page says it "adds" files to the repo, which does not suggest erasure.  When I first used `git-annex-import`, I was surprised by the default behavior, and others may be too.  Also, the command has now been "overloaded" for importing from a special remote, and in that mode the originals are not erased; giving the import-from-dir mode the same default would be more consistent.  In general, erasing data by default seems dangerous: what if it was being imported into a temporary or untrusted repo?
+
+Changing the default would also let one [[repeatedly re-import a directory while keeping original files in place|bugs/impossible__40____63____41___to_continuously_re-import_a_directory_while_keeping_original_files_in_place]].
+
+I realize this would be a breaking change for some workflows; warning of it [[like git does|todo/warn_of_breaking_changes_same_way_git_does]] would mitigate the breakage.
+
+[[!tag unlikely]]
diff --git a/doc/todo/change_git-annex-import_not_to_delete_original_files_by_default/comment_1_4eb794daaeef843b104bd480e11f7b42._comment b/doc/todo/change_git-annex-import_not_to_delete_original_files_by_default/comment_1_4eb794daaeef843b104bd480e11f7b42._comment
new file mode 100644
index 0000000000..7e10050360
--- /dev/null
+++ b/doc/todo/change_git-annex-import_not_to_delete_original_files_by_default/comment_1_4eb794daaeef843b104bd480e11f7b42._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-11-19T17:09:00Z"
+ content="""
+My general feeling about git-annex import is that everything not involving
+importing from a special remote should be deprecated and eventually
+removed.
+
+The --duplicate option probably does what you want, but if the interface is
+going to be changed, such as making that the default, I'd rather the
+interface change move toward the goal of deprecating the old mode.
+
+The fundamental mistake that the legacy interface made is it conflated
+copying content into the repository, dropping content from the directory, 
+and updating the working tree. The new interface decouples all 3,
+only doing the first, and updating a tracking branch, which the user is then
+free to merge as-is, or otherwise modify before merging. Dropping requires
+an export of a new tree, which is the main pain point in emulating
+the old interface, but you happen to not want to drop the content from the
+directory, so that pain point shouldn't affect you.
+"""]]
diff --git a/doc/todo/change_git-annex-import_not_to_delete_original_files_by_default/comment_2_f2d436822490e74544bf58a4f1c9ee79._comment b/doc/todo/change_git-annex-import_not_to_delete_original_files_by_default/comment_2_f2d436822490e74544bf58a4f1c9ee79._comment
new file mode 100644
index 0000000000..c4c86551d8
--- /dev/null
+++ b/doc/todo/change_git-annex-import_not_to_delete_original_files_by_default/comment_2_f2d436822490e74544bf58a4f1c9ee79._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="import/export"
+ date="2019-11-19T17:39:47Z"
+ content="""
+Makes sense.  It's certainly better if import/export did complementary things.  Maybe, move the old `git-annex-import` functionality to a new command called `git-annex-ingest`?
+
+\"everything not involving importing from a special remote should be deprecated\" -- i.e. to ingest a directory you'd first create a directory special remote for it, and then `git-annex-import` from that?
+"""]]
diff --git a/doc/todo/change_git-annex-import_not_to_delete_original_files_by_default/comment_3_6a7c2cbd85b5ac8e90933aaa9147e004._comment b/doc/todo/change_git-annex-import_not_to_delete_original_files_by_default/comment_3_6a7c2cbd85b5ac8e90933aaa9147e004._comment
new file mode 100644
index 0000000000..4d1829de44
--- /dev/null
+++ b/doc/todo/change_git-annex-import_not_to_delete_original_files_by_default/comment_3_6a7c2cbd85b5ac8e90933aaa9147e004._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-01-30T17:09:00Z"
+ content="""
+See [[todo/remove_legacy_import_directory_interface]].
+"""]]
diff --git a/doc/todo/checkpresentkey_without_explicit_remote.mdwn b/doc/todo/checkpresentkey_without_explicit_remote.mdwn
new file mode 100644
index 0000000000..96aacb1bfd
--- /dev/null
+++ b/doc/todo/checkpresentkey_without_explicit_remote.mdwn
@@ -0,0 +1,6 @@
+While being asked to check if file is available from "[datalad-archives]" remote I need to check if the archive's key available.  Ideally I wish I could ask through the ongoing interaction protocol, but if not, I could use smth like 'git annex checkpresentkey' but that one demands specification also of a remote which to check.  In my case I just want to know if that key is available from any remote, so I could confirm that the file is still present in our archives remote, i.e. that it could be retrieved later on
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/cleaner_hack_for_man_pages.mdwn b/doc/todo/cleaner_hack_for_man_pages.mdwn
new file mode 100644
index 0000000000..63a4a2d15a
--- /dev/null
+++ b/doc/todo/cleaner_hack_for_man_pages.mdwn
@@ -0,0 +1,119 @@
+In recent history, we have realized that the small Perl script that
+generates the man pages from Markdown is fairly limited.
+
+Two approaches have been considered:
+
+* go-md2man
+* pandoc
+
+Here is how pandoc does it:
+
+    $ pandoc -f markdown -t man doc/git-annex-shell.mdwn | pastebinit
+    http://paste.debian.net/424341/
+
+Both initially fail at setting a proper `.TH` line on top, but
+otherwise seem to work more or less correctly. --[[anarcat]]
+
+Okay, update: the above commandline was incorrect for some reason. The
+proper incantation is:
+
+    pandoc -s -t man doc/git-annex-shell.mdwn -o git-annex-shell.1
+
+For example:
+
+    $ pandoc -s -t man doc/git-annex-shell.mdwn | man -l - | pastebinit
+    http://paste.debian.net/430630/
+
+So by default, there is no title or section header, which is, if you
+ask me a little stupid: pandoc could guess a little better and parse
+the `.SH NAME` section.
+
+The workaround for this is to add Pandoc metadata either to the file,
+for example:
+
+[[!format diff """
+diff --git a/doc/git-annex-shell.mdwn b/doc/git-annex-shell.mdwn
+index 9b3d126..13f64ae 100644
+--- a/doc/git-annex-shell.mdwn
++++ b/doc/git-annex-shell.mdwn
+@@ -1,3 +1,6 @@
++% git-annex-shell(1) Git-annex manual | Version 5
++% Joey Hess
++
+ # NAME
+ 
+ git-annex-shell - Restricted login shell for git-annex only SSH access
+"""]]
+
+But Ikiwiki is likely to barf on such comments, so it's probably
+preferable to pass those parameters at build time:
+
+    $ pandoc -s -V title="git-annex-shell" -V section=1 -t man doc/git-annex-shell.mdwn  | man -l - | pastebinit
+    http://paste.debian.net/430632/
+
+Looks better already! But we can improve on that even more!
+
+    $ pandoc -s -V title="git-annex-shell" -V section=1 \
+        -V header="Git Annex manual" -V footer="Version 5.xxx" \
+        -t man doc/git-annex-shell.mdwn  | man -l - | pastebinit
+    http://paste.debian.net/430633/
+
+Much better. And the version can probably be passed in from the build
+system (or that footer can just be dropped).
+
+So a more complete patch would involve fixing the build system to use
+(and depend on!) pandoc then remove the pesky warnings at the bottom
+of all Markdown files.
+
+More investigation would probably be necessary to check the resulting
+man pages for syntax errors. For example, the above rendering, in the
+`SEE ALSO` section, has `[git-annex] (1)` instead of
+`git-annex(1)`, since Pandoc doesn't know about ikiwiki links. Maybe
+some pre-processing would be necessary there? :/ It sure is useful to
+have those links working in the web version!
+
+I hope that helps regardless.
+
+Update: regarding preprocessing, it seems there are basically two
+options for preprocessing with pandoc:
+
+* [scripting](http://pandoc.org/scripting.html)
+* [preprocessors](https://github.com/jgm/pandoc/wiki/Pandoc-Extras#preprocessors)
+  like gpp
+* external filters
+
+Preprocessors don't support arbitrary patterns like Ikiwiki links, so
+they're out already. Scripting looks a little too complicated for us,
+but could be a more stable alternative in the long term (if not for
+Ikiwiki itself ;).
+
+So I ended up using a simple sed(1) filter for now. It would be quite
+interesting to implement a better filter directly in Pandoc, if only
+for the benefit of Ikiwiki (which could then all be reimplemented in
+Haskell, No Big Deal™). But for now, I am afraid that will have to do.
+
+The resulting manpages are quite different, [here's the diff][]. It
+seems mostly better escapes and markup, in general. We get nicer
+bullet lists, cleaner command names (`git-annex add` instead of
+`git-annex-add`).
+
+[here's the diff]: http://fpaste.org/353524/
+
+I have pushed a [patch][] that implements a Pandoc build to my
+[personnal git-annex repo][]. It also adds pandoc as a build-dep to
+the debian package - and I may be missing some parts of the build
+system, hopefully you will find the missing bits and fix them, if
+any.
+
+Pandoc is awesome, and I think a great fit for this! --[[anarcat]]
+
+Oh, and I forgot: another thing that is not handled through this
+(yet?) is the "Version" footer I was using in the above examples. I
+couldn't figure out how to pull that value out of the Makefile, but
+maybe I missed something obvious there. I also didn't notice the
+`git-union-merge.1` manpage, but it seems to be broken anyways, as it
+is not in the `man/` directory and there is a comment there saying it
+is "not built normally" so I ignored it.
+
+ [personnal git-annex repo]: http://src.anarc.at/git-annex.git/
+ [patch]: http://src.anarc.at/git-annex.git/commitdiff/d8a8f42f5a7ec0458718d65b72f1f814862b125b
diff --git a/doc/todo/cleaner_hack_for_man_pages/comment_1_d51be0df42cba6f3eba2b5157dc9d427._comment b/doc/todo/cleaner_hack_for_man_pages/comment_1_d51be0df42cba6f3eba2b5157dc9d427._comment
new file mode 100644
index 0000000000..b2243d75db
--- /dev/null
+++ b/doc/todo/cleaner_hack_for_man_pages/comment_1_d51be0df42cba6f3eba2b5157dc9d427._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-11T15:35:43Z"
+ content="""
+Comparing the outputs, the pandoc man page uses `\f[C]` for
+`backticked literals`. At least in my terminal, that does not render
+specially at all, unlike the `\fB` that mdwn2man uses to render them in
+bold. This makes some man pages significantly harder to follow.
+"""]]
diff --git a/doc/todo/cleaner_hack_for_man_pages/comment_2_3dd91f4c788c81a4f7368f673778c106._comment b/doc/todo/cleaner_hack_for_man_pages/comment_2_3dd91f4c788c81a4f7368f673778c106._comment
new file mode 100644
index 0000000000..0d94424109
--- /dev/null
+++ b/doc/todo/cleaner_hack_for_man_pages/comment_2_3dd91f4c788c81a4f7368f673778c106._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-08-17T14:27:55Z"
+ content="""
+Filed an issue about this: <https://github.com/jgm/pandoc/issues/7506>
+"""]]
diff --git a/doc/todo/command_to___34__migrate__34___from_adjusted_mode.mdwn b/doc/todo/command_to___34__migrate__34___from_adjusted_mode.mdwn
new file mode 100644
index 0000000000..024e1b2f7e
--- /dev/null
+++ b/doc/todo/command_to___34__migrate__34___from_adjusted_mode.mdwn
@@ -0,0 +1,9 @@
+A somewhat follow up to https://git-annex.branchable.com/bugs/add_config_var_preventing_adjusted_branch_mode/ where we ended up in adjusted branch mode and want to get back to original indirect mode using the thaw/freeze commands.
+Checking out `master` branch is not sufficient since `.git/annex/objects` uses different layout I guess to ensure that symlinks do not jeopardize actual annex storage on systems without read-only protection.  But we need some command to migrate .git/annex/objects layout. May be it is already there and I just failed to find 
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[[!meta title="command to migrate object files from hashdirlower to hashdirmixed"]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_10_551012fe6261269363719d83113d4e3c._comment b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_10_551012fe6261269363719d83113d4e3c._comment
new file mode 100644
index 0000000000..6161e1d57a
--- /dev/null
+++ b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_10_551012fe6261269363719d83113d4e3c._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 10"
+ date="2023-05-23T16:12:42Z"
+ content="""
+FWIW: confirming that `git-annex fsck --fast` worked out nicely on a sample test repo.
+
+Re question above on how we got there:  it is trivial.  While having no globally defined thawcontent-command/freezecontent-command we created a new repo with git annex `10.20230126-1~ndall+1` (so - recent).
+
+```
+[d31548v@discovery7 test]$ git init; git annex init; echo 123 > 123 ; git annex add 123; git commit -m 123 123; ls -l 
+Initialized empty Git repository in /dartfs-hpc/rc/lab/C/CANlab/labdata/projects/test/test/.git/
+init  
+  Filesystem does not allow removing write bit from files.
+
+  Detected a crippled filesystem.
+
+  Disabling core.symlinks.
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Switched to branch 'adjusted/master(unlocked)'
+ok
+(recording state in git...)
+add 123 
+ok                                
+(recording state in git...)
+[adjusted/master(unlocked) 6fc2d66] 123
+ 1 file changed, 1 insertion(+)
+ create mode 100644 123
+total 24
+-rwxrwx--- 1 d31548v rc-CANlab-admin 4 May 23 12:01 123
+[d31548v@discovery7 test]$ ls -lta
+total 120
+drwxrwx--- 9 d31548v rc-CANlab-admin 293 May 23 12:01 .git
+-rwxrwx--- 1 d31548v rc-CANlab-admin   4 May 23 12:01 123
+drwxrwx--- 3 d31548v rc-CANlab-admin  43 May 23 12:01 .
+drwxrwx--- 4 d31548v rc-CANlab-admin  62 May 23 12:01 ..
+```
+
+so we ended up in adjusted branches mode, with .git/config having those `core.symlinks = false` and `annex.crippledfilesystem = true`.  
+
+Then we wanted to move back to \"normal\" -- enabled those thaw/freeze config options, `git config --unset core.symlinks; git config --unset annex.crippledfilesystem`, ran `git annex fsck --fast` and seems got it all alright.
+"""]]
diff --git a/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_1_8e9ecd2a3f9fc5cb80785b100aeb6e36._comment b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_1_8e9ecd2a3f9fc5cb80785b100aeb6e36._comment
new file mode 100644
index 0000000000..8f713e9e72
--- /dev/null
+++ b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_1_8e9ecd2a3f9fc5cb80785b100aeb6e36._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-09T14:57:55Z"
+ content="""
+But adjusted branches do not affect the location of git-annex object files.
+
+The git-annex adjust man page says to use `git checkout` to switch back,
+and it certianly does work.
+
+If you are having a problem with this, you need to explain what the problem
+is and what is happening...
+"""]]
diff --git a/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_2_845206fa688ed4786262fe6d82464d97._comment b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_2_845206fa688ed4786262fe6d82464d97._comment
new file mode 100644
index 0000000000..73b2252b69
--- /dev/null
+++ b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_2_845206fa688ed4786262fe6d82464d97._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="hm..."
+ date="2022-05-09T19:10:10Z"
+ content="""
+I will need to figure out/try to reproduce how user ended up with .git/annex/objects in xxx/yyy instead of xx/yy layout...
+"""]]
diff --git a/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_3_4375a63a864306c39323fa4b159425d6._comment b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_3_4375a63a864306c39323fa4b159425d6._comment
new file mode 100644
index 0000000000..8257beda68
--- /dev/null
+++ b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_3_4375a63a864306c39323fa4b159425d6._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-05-09T19:54:35Z"
+ content="""
+Ok, so the object location usually used in bare repositories.. 
+
+One way that could happen is if core.symlinks=false and
+annex.crippledfilesystem=true. Then it does use the bare form of object
+filenames, which is kind of ok since it's not going to be using symlinks in
+that repository.
+
+Also, before 2016
+([[commit 2d00523609def535588b693a00d4092768e1c3c6]]), 
+git-annex used those names whenever annex.crippledfilesystem=true,
+no matter what core.symlinks was set to. So if the files are that old..
+
+This does seem to point to there needing to be a way to migrate the object
+files in a repository to the right names. It might be a reasonable thing
+for git-annex fsck to do, when it sees a symlink to an object file that
+is in the other location.
+"""]]
diff --git a/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_4_a0d4ffdf3edadb5381f242f65fa38932._comment b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_4_a0d4ffdf3edadb5381f242f65fa38932._comment
new file mode 100644
index 0000000000..484e3c9b17
--- /dev/null
+++ b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_4_a0d4ffdf3edadb5381f242f65fa38932._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-05-10T16:37:21Z"
+ content="""
+The rationalle for using the bare object layout when on a crippled
+filesystem was given in [[!commit f1b0a4b404ed835f1c4a27a92352180be8564f8a]].
+Basically it may be more portable. Not a strong rationalle at all, as the
+later change to not do it when symlinks are supported shows. But
+I don't think worth changing at this point.
+
+So teaching fsck to move object files to the preferred location seems the
+best way. It will also deal with the situation where a bare repository gets
+converted by the user into a non-bare repo.
+"""]]
diff --git a/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_5_55b5beaeba0de7bb1efcc2626570d3b5._comment b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_5_55b5beaeba0de7bb1efcc2626570d3b5._comment
new file mode 100644
index 0000000000..6fa9576070
--- /dev/null
+++ b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_5_55b5beaeba0de7bb1efcc2626570d3b5._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-05-10T16:56:47Z"
+ content="""
+As well as moving the object file, fsck will need to move any other associated
+files, including the object lock file. It may as well move the whole
+object directory.
+
+Locking is a concern for implementing this in fsck. There
+would be a race where another process that is locking the object file
+sees the object file in the old location, so tries to lock it in the old
+location, but by then the object file has been moved.
+
+Experimentally: In v10, moving the object file after it has checked its
+location in preparation for locking for drop results in it making a
+separate lock file in the old object directory. That lock file remains after
+the drop succeeds. In v8/v9, it seems to not create the object
+file when trying to lock it. (Based on reading the code, I though perhaps
+it would!) In v8-v10, moving the object directory in the race when it's locking
+content in place causes the lock to fail; it does not create any lock file
+or object file. 
+
+So, v10 post drop lock file cleanup is the problem. Or at least one
+problem, there could be other points in the race than the one I tested
+that have other behavior. This seems like an ugly race to insert fsck into
+the middle of; it would be much preferable if fsck could somehow avoid
+such races when moving the object directory. But how?
+
+fsck could lock the object file for drop, and then rather than removeing it,
+move it to a holding location. Then it could move the object file
+into the right place the same as `get` does. This should avoid the race.
+Interrupting fsck at the wrong time would leave the object file in this
+holding location though. Re-running fsck would need to recover from this
+situation. Putting it in `.git/annex/tmp/` might make sense, although
+`git-annex get` does not necessarily recover when the object file is
+located there.
+"""]]
diff --git a/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_6_a383c7303f1e942a830d9f730f1c0f00._comment b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_6_a383c7303f1e942a830d9f730f1c0f00._comment
new file mode 100644
index 0000000000..00a24e2cf8
--- /dev/null
+++ b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_6_a383c7303f1e942a830d9f730f1c0f00._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2022-05-13T15:12:29Z"
+ content="""
+I guess fsck could just lock the entire repo for its duration forbidding any operation?  I would love to be able to migrate the layout also on \"older\" versions of repo/annex without upgrading all the way to 10.  Meanwhile I think I am doomed to write a little helper to do those renames (once, and hopefully never ever again... I might even protect myself by making those top xxx known to me now non-writable at the level of ACL, so the attempt to migrate would lead to an error) 
+"""]]
diff --git a/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_6_e8ab74bb4951fe7f0c71630bb278ad6f._comment b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_6_e8ab74bb4951fe7f0c71630bb278ad6f._comment
new file mode 100644
index 0000000000..3b17573088
--- /dev/null
+++ b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_6_e8ab74bb4951fe7f0c71630bb278ad6f._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-05-16T15:24:43Z"
+ content="""
+If fsck locks the content for removal, then moves it to the preferred
+location, how is that any different from git-annex first dropping content
+and then very quickly retrieving another copy and storing it in the other
+location? The only difference is timing, but things like being suspended
+and resumed can affect timing.
+
+So, if there is a problem with fsck doing that, there would also be a more
+general problem, that could occur in other circumstances, even if only
+rarely.
+
+One way to see the general problem happen would be to have two processes
+trying to drop the same object. One process finds the object location, then
+stalls. Meanwhile, the second process drops the object. Then the first
+process resumes, and locks for removal. Per comment #5 this will result in
+a dangling lock file in the object directory. I have not managed to get
+this to happen yet though.
+
+A fix for the general problem is to make it not create the
+object directory when opening the object lock file. So I've made that
+change.
+"""]]
diff --git a/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_7_0ccaf798086a8c9511d3733b12b24c8b._comment b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_7_0ccaf798086a8c9511d3733b12b24c8b._comment
new file mode 100644
index 0000000000..8b2aa82175
--- /dev/null
+++ b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_7_0ccaf798086a8c9511d3733b12b24c8b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-05-16T19:17:34Z"
+ content="""
+Made `git-annex fsck` move the object files to the preferred location for
+the repository type. 
+
+You can run it with --fast and it should solve your problem. I'm still not
+certain what circumstance led to you having the problem, but unless I hear
+back I'll assume it was something like an old version of git-annex. So will
+close this bug with this as the fix..
+"""]]
diff --git a/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_7_e2d45ac485456ed9cb86f8e6bd23617c._comment b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_7_e2d45ac485456ed9cb86f8e6bd23617c._comment
new file mode 100644
index 0000000000..e9eb6decf1
--- /dev/null
+++ b/doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_7_e2d45ac485456ed9cb86f8e6bd23617c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="shell helper"
+ date="2022-05-13T16:51:22Z"
+ content="""
+FWIW made this shell helper to migrate all keys into desired layout: [https://raw.githubusercontent.com/datalad/datalad/maint/tools/convert-git-annex-layout](https://raw.githubusercontent.com/datalad/datalad/maint/tools/convert-git-annex-layout)
+"""]]
diff --git a/doc/todo/command_to_list_keys_for_old_versions_of_files.mdwn b/doc/todo/command_to_list_keys_for_old_versions_of_files.mdwn
new file mode 100644
index 0000000000..17fe085417
--- /dev/null
+++ b/doc/todo/command_to_list_keys_for_old_versions_of_files.mdwn
@@ -0,0 +1,46 @@
+A command like `git-annex oldkeys $file` that lists the keys used for all
+previous versions of the file.
+
+It would allow a workflow like eg:
+
+    edit foo
+    git-annex add foo
+    git commit -m new\ foo
+    git-annex oldkeys foo | git-annex move --batch-keys --to bar
+
+Or this, to send someone the current version of a file, and also all old
+versions:
+
+    git-annex copy foo --to baz
+    git-annex oldkeys foo | git-annex copy --to baz
+
+Or like this:
+
+    git-annex oldkeys foo | git-annex get --batch-keys
+    # proceed to diff between old versions of the file 
+    # (although git-annex-diffdriver --get is another way to do this)
+
+Or this to make every old version visible as files to flip through in a
+slideshow:
+
+    n=0
+    for k in $(git-annex oldkeys my.gif); do
+        $n=$(expr $n + 1)
+        ln -s $(git-annex examinkey $k --format='${objectpath}') my.$n.gif
+    done
+
+----
+
+Is oldkeys the best name for this? `git-annex log` is already taken.
+
+Since this would be implemented on top of `git log --raw`, it would
+be possible to support multiple files at once, or whole directories.
+
+If an old key is the same as the current key, should it list the old key or
+not? If it did, then the move example above would move the current 
+version of the file away. And there are tricky cases involving renames 
+and reverts. So it seems that it ought to avoid
+ever listing a key currently used by the file(s) it is run on 
+as an old key.
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/command_to_list_keys_for_old_versions_of_files/comment_1_43c11d9467b4d4460aa97bfb88b4896f._comment b/doc/todo/command_to_list_keys_for_old_versions_of_files/comment_1_43c11d9467b4d4460aa97bfb88b4896f._comment
new file mode 100644
index 0000000000..34183374ed
--- /dev/null
+++ b/doc/todo/command_to_list_keys_for_old_versions_of_files/comment_1_43c11d9467b4d4460aa97bfb88b4896f._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Oh yes please 🤩"
+ date="2023-08-22T16:48:58Z"
+ content="""
+`unusedkeys` would be consistently named with `git annex unused`. Would it make sense to teach `git annex unused` that? It could be taught to accept paths as arguments (it doesn't currently, right?) and then only operate on those to find old versions. Then no new command is necessary and people already know `unused`. The workflow would be:
+
+```
+# two-step
+git annex unused file.txt
+git annex move --unused --to there
+
+# new option to only list keys for further scripting
+git annex unused --onlykeys file.txt | xargs ...
+# maybe --batch is a better name 🤷
+```
+"""]]
diff --git a/doc/todo/command_to_list_keys_for_old_versions_of_files/comment_2_5062a0f8b57fdebf74fef8a65ac0a0b2._comment b/doc/todo/command_to_list_keys_for_old_versions_of_files/comment_2_5062a0f8b57fdebf74fef8a65ac0a0b2._comment
new file mode 100644
index 0000000000..152a91ecc0
--- /dev/null
+++ b/doc/todo/command_to_list_keys_for_old_versions_of_files/comment_2_5062a0f8b57fdebf74fef8a65ac0a0b2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2023-08-22T17:57:45Z"
+ content="""
+Or better: make `git annex unused` accept the common matching options. Then `git annex unused --include=myfile.txt` can be used for the same effect.
+"""]]
diff --git a/doc/todo/command_to_list_keys_for_old_versions_of_files/comment_3_3c605fbd4c20522e265ef080675c3669._comment b/doc/todo/command_to_list_keys_for_old_versions_of_files/comment_3_3c605fbd4c20522e265ef080675c3669._comment
new file mode 100644
index 0000000000..e5f0ba4be4
--- /dev/null
+++ b/doc/todo/command_to_list_keys_for_old_versions_of_files/comment_3_3c605fbd4c20522e265ef080675c3669._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-08-22T19:02:26Z"
+ content="""
+This is certainly adjacent to unused, but it's not quite the same.
+
+I think users will generally want this to list keys even if they are 
+still used by some other files in the tree besides the files that they
+are querying. (There may be cases where that is not desirable of course,
+but at least 3 of the 4 examples I came up with seem desirable to operate
+that way.)
+
+And a key listed by this command might be used by other branches, so unused
+would not list it.
+"""]]
diff --git a/doc/todo/comment_1_98d09316dc39619203e507f862716bab._comment b/doc/todo/comment_1_98d09316dc39619203e507f862716bab._comment
new file mode 100644
index 0000000000..ed46d7ba19
--- /dev/null
+++ b/doc/todo/comment_1_98d09316dc39619203e507f862716bab._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-07-31T18:41:03Z"
+ content="""
+	Matches files that git-annex believes are present in at least one
+	repository that is in the specified group, and are not present in any
+	repositories that are not in the specified group.
+
+That's a pretty simple description and it allows matching when a repository
+is in the specified group but is also in some other groups.
+
+So that makes me happy with onlyingroup and I implemented it.
+"""]]
diff --git a/doc/todo/complete_annex.skipunknown_transition_in_2022.mdwn b/doc/todo/complete_annex.skipunknown_transition_in_2022.mdwn
new file mode 100644
index 0000000000..a8de0c61b6
--- /dev/null
+++ b/doc/todo/complete_annex.skipunknown_transition_in_2022.mdwn
@@ -0,0 +1,6 @@
+annex.skipunknown should be changed to default to false in early 2022.
+This transition was started in mid 2020 and there should have been plenty
+of time for people to learn about it and either set their preferred
+behavior or change workflows for the new behavior.
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/compute_special_remote.mdwn b/doc/todo/compute_special_remote.mdwn
new file mode 100644
index 0000000000..a4c57c0b27
--- /dev/null
+++ b/doc/todo/compute_special_remote.mdwn
@@ -0,0 +1,62 @@
+# Enable git-annex to provision file content by other means than download
+
+This idea [goes back many years](https://github.com/datalad/datalad/issues/2850), and has been [iterated on repeatedly afterwards](https://github.com/datalad/datalad-next/issues/143), and most recently at Distribits 2024.
+The following is a summary of what role git-annex could play in this functionality.
+
+The basic idea is to wrap a provision-by-compute process into the standard interface of a git annex remote.
+A consumer would (theoretically) not need to worry about how an annex key is provided, they would simply get-annex-get it, whether this leads to a download or a computation.
+Moreover, access cost and redundancies could be managed/communicated using established patterns.
+
+## Use cases
+
+Here are a few concrete use cases that illustrate why one would want to have functionality like this
+
+### Generate annex keys (that have never existed)
+
+This can be useful for leaving instructions how, e.g. other data formats can be generated from a single format that is kept on storage.
+For example, a collection of CSV files is stored, but an XLSX variant can be generated upon request automatically.
+Or a single large live stream video is stored, and a collection of shorter clips is generated from a cue sheet or cut list.
+
+
+### Re-generate annex keys
+
+This can be useful when storing a key is expensive, but its exact identity is known/important. For example, an outcome of a scientific computation yields a large output that is expensive to compute and to store, yet needs to be tracked for repeated further processing -- the cost of a recomputation may be reduced, by storing (smaller) intermediate results, and leaving instruction how to perform (a different) computation that yields the identical original output.
+
+This second scenario, where annex keys are reproduced exactly, can be considered the general case. It generally requires exact inputs to the computation, where as the first scenario can/should handle an application of a compute instruction on any compatible input data.
+
+
+## What is in scope for git-annex?
+
+The execution of arbitrary code without any inherent trust is a problem. A problem that git-annex may not want to get into. Moreover, there are many candidate environments for code execution -- a complexity that git-annex may not want to get into either.
+
+### External remote protocol sufficient?
+
+From my point of view, pretty much all required functionality could be hidden behind the external remote protocol and thereby inside on or more special remote implementations.
+
+- `STORE`: somehow capture the computing instructions, likely linking some code to some (key-specific) parameters, like input files
+- `CHECKPRESENT`: do compute instruction for a key exist?
+- `RETRIEVE`: compute the key
+- `REMOVE`: remove the instructions/parameter record
+- `WHEREIS`: give information on computation/inputs
+
+where `SET/GETSTATE` may implement the instruction deposit/retrieval.
+
+### Worktree provisioning?
+
+Such external remote implementation would need a way to create suitable worktrees to (re)run a given code. Git-annex support to provide a (separate) worktree for a repository at a specific commit, with efficient (re)use of the main repository's annex would simplify such implementations.
+
+### Request one key, receive many
+
+It is possible that a single computation yields multiple annex keys, even when git-annex only asked for a single one (which is what it would do, sequentially, when driving a special remote). It would be good to be able to capture that and avoid needless duplication of computations.
+
+### Instruction deposition
+
+Using `STORE` (`git annex copy --to`) record instructions is possible (say particular ENV variables are used that pass information to a special remote), but is more or less a hack. It would be useful to have a dedicated command to accept and deposit such a record in association with one or more annex keys (which may or may not be known at that time). This likely require settling on a format for such records.
+
+### Storage redundancy tests
+
+I believe that no particular handling of annex key that are declared inputs to computing instructions for other keys are needed. Still listing it here to state that, and be possibly proven wrong.
+
+### Trust
+
+We would need a way for users to indicate that they trust a particular compute introduction or the entity that provided it. Even if git-annex does not implement tooling for that, it would be good to settle on a concept that can be interpreted/implemented by such special remotes.
diff --git a/doc/todo/compute_special_remote/comment_1_9f4835cd08d9d02009b685f4a366a245._comment b/doc/todo/compute_special_remote/comment_1_9f4835cd08d9d02009b685f4a366a245._comment
new file mode 100644
index 0000000000..539e311fff
--- /dev/null
+++ b/doc/todo/compute_special_remote/comment_1_9f4835cd08d9d02009b685f4a366a245._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="m.risse@77eac2c22d673d5f10305c0bade738ad74055f92"
+ nickname="m.risse"
+ avatar="http://cdn.libravatar.org/avatar/59541f50d845e5f81aff06e88a38b9de"
+ subject="prior art"
+ date="2024-04-13T20:30:56Z"
+ content="""
+I just want to mention that I've implemented/tried to implement something like this in <https://github.com/matrss/datalad-getexec>. It basically just records a command line invocation to execute and all required input files as base64-encoded json in a URL with a custom scheme, which made it surprisingly simple to implement. I haven't touched it in a while and it was more of an experiment, but other than issues with dependencies on files in sub-datasets it worked pretty well. The main motivation to build it was the mentioned use-case of automatically converting between file formats. Of course it doesn't address all of your mentioned points. E.g. trust is something I haven't considered in my experiments, at all. But it shows that the current special remote protocol is sufficient for a basic implementation of this.
+
+I like the proposed \"request one key, receive many\" extension to the special remote protocol and I think that could be useful in other \"unusual\" special remotes as well.
+
+I don't quite understand the necessity for \"Worktree provisioning\". If I understand that right, I think it would just make things more complicated and unintuitive compared to always staying in HEAD.
+
+\"Instruction deposition\" is essentially just adding a URL to a key in my implementation, which is pretty nice. Using the built-in relaxed option automatically gives the distinction between generating keys that have never existed and regenerating keys.
+"""]]
diff --git a/doc/todo/compute_special_remote/comment_2_bdb9c77b3ac97cef8d1b8eeaaf300d8b._comment b/doc/todo/compute_special_remote/comment_2_bdb9c77b3ac97cef8d1b8eeaaf300d8b._comment
new file mode 100644
index 0000000000..34d518f309
--- /dev/null
+++ b/doc/todo/compute_special_remote/comment_2_bdb9c77b3ac97cef8d1b8eeaaf300d8b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Need for more than HEAD/URL?"
+ date="2024-04-15T05:00:58Z"
+ content="""
+> \"Instruction deposition\" is essentially just adding a URL to a key in my implementation, which is pretty nice. Using the built-in relaxed option automatically gives the distinction between generating keys that have never existed and regenerating keys.
+
+Thanks for the pointer, very useful!
+
+Regarding the points you raised:
+
+Datalad's `run` feature has been around for some years, and we have seen usage in the wild with command lines that are small programs and dozens, sometimes hundreds of inputs. It is true that anything could be simply URL-encoded. However, especially with command-patterns (always same, except parameter change) that may be needlessly heavy. Maybe it would compress well (likely), but it still poses a maintenance issue. Say the compute instructions need an update (software API change): Updating one shared instruction set is a simpler task than sifting through annex-keys and rewriting URLs.
+
+> I don't quite understand the necessity for \"Worktree provisioning\". If I understand that right, I think it would just make things more complicated and unintuitive compared to always staying in HEAD.
+
+We need a worktree different from `HEAD` whenever HEAD has changed from the original worktree used for setting up a compute instruction. Say a command needs two input files, but one has been moved to a different directory in current `HEAD`. An implementation would now either say \"no longer available\" and force maintenance update, or be able to provision the respective worktree. In case of no provision capability we would need to replace the URL-encoded instructions (this would make the key uncomputable in earlier versions), or amend with an additional instruction set (and now we would start to accumulate cruft where changes in the git-annex branch need to account for (unrelated) changes in any other branch).
+"""]]
diff --git a/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls.mdwn b/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls.mdwn
new file mode 100644
index 0000000000..fea3e171a8
--- /dev/null
+++ b/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls.mdwn
@@ -0,0 +1,10 @@
+Ref: all heated discussions around https://github.com/datalad/datalad/issues/2844
+
+The main point is -- `git annex init --version=6`, while running  on a crippled system might need some time to accomplish the mission of unlocking a big number of files, which leads to `Checking out` progress update spit out by `git`.  BUT if someone (us) swallows stderr, `git` does not produce any progress output unless that command (checkout, pull, fetch, etc...) provides explicit `--progress` flag.  According to IRC there is no config setting to trigger that behavior in `git`.  Could may be `git annex` get a config setting alike `force-git-progress` which would add `--progress` to any relevant `git` call whenever git is ran without stderr being swallowed by annex?
+
+Thanks in advance for considering
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]]
diff --git a/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_1_06d6dd17b7bd45b96276770b09bedca9._comment b/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_1_06d6dd17b7bd45b96276770b09bedca9._comment
new file mode 100644
index 0000000000..23ce220f69
--- /dev/null
+++ b/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_1_06d6dd17b7bd45b96276770b09bedca9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-03T16:27:45Z"
+ content="""
+Hrm, git checkout does not have a --progress flag that I can see.
+Perhaps they were thinking about git clone, which does have a progress, but
+the repo is already cloned at this point.
+"""]]
diff --git a/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_2_d9135802f29b78749833b7fd9967cc0b._comment b/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_2_d9135802f29b78749833b7fd9967cc0b._comment
new file mode 100644
index 0000000000..ce5a59b0af
--- /dev/null
+++ b/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_2_d9135802f29b78749833b7fd9967cc0b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-10-03T17:55:04Z"
+ content="""
+hm...
+
+```
+$> git checkout --help | grep progress
+       --[no-]progress
+           This flag enables progress reporting even if not attached to a
+
+$> git --version
+git version 2.19.0
+```
+"""]]
diff --git a/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_3_8a6027fb58c4b7aaa3f82b5fd1c2812a._comment b/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_3_8a6027fb58c4b7aaa3f82b5fd1c2812a._comment
new file mode 100644
index 0000000000..0b8089a8d0
--- /dev/null
+++ b/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_3_8a6027fb58c4b7aaa3f82b5fd1c2812a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-10-04T16:53:31Z"
+ content="""
+Ah, I see, I was searching for "--progress".
+
+I suppose what would make sense is to add the same option to the git-annex
+commands that can do a git checkout: init, adjust, sync, view, vpop, vadd,
+vcycle.
+"""]]
diff --git a/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_4_ceb543ebac42bf7a5f1571ff3f4ef977._comment b/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_4_ceb543ebac42bf7a5f1571ff3f4ef977._comment
new file mode 100644
index 0000000000..55b02b182c
--- /dev/null
+++ b/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_4_ceb543ebac42bf7a5f1571ff3f4ef977._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-01-30T16:23:55Z"
+ content="""
+Occurs to me that any git-annex command could result in an automatic
+init, and since v7 is default, will enter an adjusted branch when on a
+crippled filesystem.
+
+I don't think it makes sense to add --progress to every single
+git-annex command.
+
+I suppose, if your code always runs git-annex init after clone, then it
+would be good enough to have git-annex init be the only thing that
+supports --progress. If something else needs it (maybe the view commands),
+we can treat that separately.
+"""]]
diff --git a/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_5_ec99ba117fac299fc361a32de4ff29a5._comment b/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_5_ec99ba117fac299fc361a32de4ff29a5._comment
new file mode 100644
index 0000000000..42452649f0
--- /dev/null
+++ b/doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_5_ec99ba117fac299fc361a32de4ff29a5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-01-30T16:38:30Z"
+ content="""
+Heh, looking at the code, [[!commit
+24838547e2475b37d7e910361f9b6e087a1a0648]] in 2018
+made --progress be unconditionally passed when entering an adjusted branch.
+
+That was done for unrelated reasons, but I don't think there's anything more
+to do on this now.
+"""]]
diff --git a/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems.mdwn b/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems.mdwn
new file mode 100644
index 0000000000..0f0cc48d3f
--- /dev/null
+++ b/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems.mdwn
@@ -0,0 +1,7 @@
+ATM `git-annex init` switches repository to direct mode if detects a crippled filesystem.  Since version 6 is now generally more usable than direct mode in many scenarios, it would be nice if it was possible to instruct to choose v6 mode instead of direct whenever a crippled system is encountered.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> Since v7, direct mode is not used by default in crippled filesystems, so
+> [[done]] --[[Joey]]
diff --git a/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_1_e3cd8d86869d8a63337f7eff0b91ddbc._comment b/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_1_e3cd8d86869d8a63337f7eff0b91ddbc._comment
new file mode 100644
index 0000000000..dbe286a286
--- /dev/null
+++ b/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_1_e3cd8d86869d8a63337f7eff0b91ddbc._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-01T15:57:40Z"
+ content="""
+Wouldn't git annex init --version=6 work? If not that is a bug.
+"""]]
diff --git a/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_2_3580025d828b27072530eb8ccda9bdf4._comment b/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_2_3580025d828b27072530eb8ccda9bdf4._comment
new file mode 100644
index 0000000000..319002b34e
--- /dev/null
+++ b/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_2_3580025d828b27072530eb8ccda9bdf4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-10-01T16:29:19Z"
+ content="""
+I think that is correct.
+But isn't `annex init` is also indirectly invoked by any annex command, e.g. if I just do `git clone URL ; cd DIR; git annex get FILEs`?
+"""]]
diff --git a/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_3_d300407d70f799958734df1722fe923b._comment b/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_3_d300407d70f799958734df1722fe923b._comment
new file mode 100644
index 0000000000..cb5e408b86
--- /dev/null
+++ b/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_3_d300407d70f799958734df1722fe923b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-10-03T16:31:50Z"
+ content="""
+Yes, it will auto-init in a clone. But you can still manually init of
+course.
+
+I am reluctant to add this if the only use for it is going to be until v6
+becomes the default; it would make more sense to spend the time on getting
+v6 closer to that point.
+
+Especially because "v6 is worth using instead of direct mode" is a pretty specific
+opinion to hardcode into git-annex. I can imagine other opinions, like "v6
+is worth using instead of direct mode but not in WSL because sqlite
+sometimes crashes there" (closer to my own opinion). Seems to me that if there
+were a setting at all, it would need to make git-annex default to v6 mode always.
+"""]]
diff --git a/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_4_9367cfc5e12e43db6b53f43dc468757f._comment b/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_4_9367cfc5e12e43db6b53f43dc468757f._comment
new file mode 100644
index 0000000000..5ff51f4a4e
--- /dev/null
+++ b/doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_4_9367cfc5e12e43db6b53f43dc468757f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2018-10-03T18:03:56Z"
+ content="""
+> until v6 becomes the default
+
+default only for the crippled FS or for all?
+
+Anyways, it is up to you of cause.  But even with your use-case (when to prefer direct instead of v6) it sounds like such an option would be handy so I could set it within ~/.gitconfig and have all new repos uniformly in `direct` mode (whenever v6 is the default).  Especially since `annex init` seems to have no option for getting into direct mode right away, so whenever v6 becomes default there, it would require a jump first into v6 and then running `annex direct` (if I am not missing anything).
+"""]]
diff --git a/doc/todo/confirmed.mdwn b/doc/todo/confirmed.mdwn
new file mode 100644
index 0000000000..8df3805a1a
--- /dev/null
+++ b/doc/todo/confirmed.mdwn
@@ -0,0 +1,8 @@
+This tag is for todo items that have an agreed upon plan of action, but
+have not been implemented yet.
+
+[[!inline pages="todo/* and !todo/*/* and !todo/done and !link(todo/done) 
+and link(todo/confirmed)
+and !*/Discussion and !todo/moreinfo and !todo/confirmed
+and !todo/needsthought and !todo/unlikely" show=0 feedlimit=10
+archive=yes template=buglist]]
diff --git a/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info.mdwn b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info.mdwn
new file mode 100644
index 0000000000..0e7c150684
--- /dev/null
+++ b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info.mdwn
@@ -0,0 +1,18 @@
+An ability to copy key availability information from one git-annex'ed repo to another had been a use case we needed for quite some time. Michael even implemented [datalad copy-file](http://docs.datalad.org/en/stable/generated/datalad.api.copy_file.html?highlight=copy_file) remotes - that was an immediate use-case whenever it was necessary to craft "custom" smaller datasets from a much larger (super)dataset . And now we came to the same need to facilitate "splitting" a larger dataset into sub-datasets: [issues/600](https://github.com/datalad/datalad/issues/600#issuecomment-824715427).
+
+I think, in particular with [https://git-annex.branchable.com/todo/hiding_a_repository/](https://git-annex.branchable.com/todo/hiding_a_repository/), something like `git annex copy-key --from hidden-repo KEY` could become the ultimate tool for such operations.  Alternatively may be it could be `git annex copy-key --from-repo /repo/path KEY` so there would not even be a need to link original one as some hidden repo, but rather even "include" original one as a `git submodule` (e.g. `original/`).
+
+Such command would need to pretty much do whatever `git annex merge` already does, just limiting its effects to only relevant key(s) and only the remotes which are known to have that key.
+
+Although I concentrated on "copy-**key**" pretty much the same feature could be useful to provide a `git annex copy-file PATH1 PATH2 ... DEST` where PATH?s would be paths in other git-annex repo(s) -- so it would pretty be similar (just better since not only URLs copied) to `datalad copy-file`.
+
+`--batch` mode in both cases would be super handy to streamline use of the command(s).
+
+WDYT Joey?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> In progress in the `filter-branch` branch. --[[Joey]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_1_68c86b06b3b0c8cc9c3faac97e3f6c3f._comment b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_1_68c86b06b3b0c8cc9c3faac97e3f6c3f._comment
new file mode 100644
index 0000000000..8cd9485a9f
--- /dev/null
+++ b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_1_68c86b06b3b0c8cc9c3faac97e3f6c3f._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-05-04T14:58:17Z"
+ content="""
+If I understand correctly, this might be as straightforard as extracting
+the various per-key logs from the git-annex branch, and shoving them into a
+new git tree, which the user can then do whatever with. Something like:
+
+	git-annex copy-key path/
+	8e1c53342eb6461eedf13ee7d15038b400c70269
+
+The obvious thing for the user to do with such a tree would be 
+to git push it to the other repo with a name ending in /git-annex,
+which git-annex there will then auto-merge into that repo's git-annex
+branch.
+
+When you start talking about hidden repos though, things get more complex,
+because exporting key logs from a hidden repo would necessarily expose the
+uuid of that repo, and maybe other logged information that was only
+stored in the hidden repo as well. If it has to filter it to only the parts
+of logs that are used by non-hidden repos, that would be a lot more complex.
+
+It also seems to me that, if you're splitting a repo, you would also want
+to include things like trust.log and remote.log, or at least parts of them
+for some remotes?
+"""]]
diff --git a/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_2_8993cf9badc8348604c662e35ba6f199._comment b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_2_8993cf9badc8348604c662e35ba6f199._comment
new file mode 100644
index 0000000000..e3c8336543
--- /dev/null
+++ b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_2_8993cf9badc8348604c662e35ba6f199._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2021-05-04T17:50:45Z"
+ content="""
+> It also seems to me that, if you're splitting a repo, you would also want to include things like trust.log and remote.log, or at least parts of them for some remotes?
+
+yes. Even if not splitting but just copying a key (or multiple keys) since might need special remote configuration etc.
+"""]]
diff --git a/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_3_53a7a0d5ba6be411bdae10a6f8ba16fc._comment b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_3_53a7a0d5ba6be411bdae10a6f8ba16fc._comment
new file mode 100644
index 0000000000..e39fb27d1e
--- /dev/null
+++ b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_3_53a7a0d5ba6be411bdae10a6f8ba16fc._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-05-13T16:10:39Z"
+ content="""
+Hmm, it seems possible that two repos could use the same uuid for a
+remote, but have different configurations for it. Eg, an internal use repo
+that might even embed creds for the remote, and a public use repo that
+relies on public http urls to download from the remote.
+
+So there would then be 3 things that need to be able to be specified:
+
+* keys to copy
+* uuids whose per-key information should be copied (or ones to skip)
+* uuids whose non-per-key information should be copied (or ones to skip)
+  (remote description, special remote config, trust, group, preferred
+  content, etc)
+
+Might as well add, for completeness:
+
+* whether to copy global config settings, or not (numcopies, mincopies,
+  git-annex-config, group-preferred-content, difference.log)
+
+Could get more granular than this, eg only copying some metadata fields and
+not others, or description but not trust log, but I'd want to see a use
+case. A line has to be drawn somewhere or it just gets ridiculous, and the
+user might as well pull up [[internals]] and git-filter-branch and
+post-process the tree generated by this command.
+
+So a UI for these 3 or 4 things..
+
+	git-annex filter-branch --keys-from=path 
+		--include-key-information-for=repo
+		--exclude-key-information-for=repo
+		--include-config-for=repo
+		--exclude-config-for=repo
+		--include-global-config
+		--exclude-global-config
+
+Eg: 
+
+	git-annex filter-branch --keys-from=.
+		--exclude-key-information-for=privateremote
+		--exclude-config-for=privateremote
+		--include-global-config
+"""]]
diff --git a/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_4_d82ee205451cf55eb283952c4774d32a._comment b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_4_d82ee205451cf55eb283952c4774d32a._comment
new file mode 100644
index 0000000000..8af41e1564
--- /dev/null
+++ b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_4_d82ee205451cf55eb283952c4774d32a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-05-13T16:29:41Z"
+ content="""
+The other axis is, I guess, should it include past commits to the git-annex
+branch, or only the current data? I'm inclined toward only the current
+data. The only thing that uses past data really is `git-annex log` and it's just
+not worth the added time expense. And also `git annex forget` already
+throws away the past data.
+
+There is the added wart of exported treeishes being grafted into the
+git-annex branch (to avoid them being lost in GC in some edge cases).
+It would need to do like `git annex forget` was recently fixed to, and
+include those grafts when throwing away the rest of the history.
+(See [[!commit 8e7dc958d20861a91562918e24e071f70d34cf5b]])
+"""]]
diff --git a/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_5_3565680846a8d547d0912d1ef31430b2._comment b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_5_3565680846a8d547d0912d1ef31430b2._comment
new file mode 100644
index 0000000000..7a816fa126
--- /dev/null
+++ b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_5_3565680846a8d547d0912d1ef31430b2._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-05-13T16:55:36Z"
+ content="""
+The filtering of uuids from logs this command needs is very closely
+related to how the git-annex branch is filtered when dropping dead uuids
+and keys.
+
+Annex.Branch.Transitions.dropDead could alsmost be used as-is, just
+providing it a trustmap that has the excluded uuids marked as dead.
+
+But, it does not currently modify the trustLog, which makes sense for
+transitions, but for this the trust log needs to include only the desired
+uuids.
+
+And, providing a trustmap does have the problem that,
+if a uuid is mentioned in the branch without being in uuid.log,
+it would not be in the trustmap, and so it would not be excluded. One way
+for that to happen is well, using this command to copy only per-key info
+for a remote, but not config for a remote. Hmm. Using a filtering
+function, rather than a trustmap, would avoid this problem. But,
+dropDead does some processing to handle sameas-uuid pointing to a dead
+uuid, including a special case involving remoteLog.
+
+Implementation plan:
+
+* Address above problems with dropDead, somehow, so it can be reused.
+  (done; refactored to filterBranch)
+* Add a function (in Logs) from a key to all possible git-annex branch log
+  files for that key. (done; keyLogFiles)
+* For each key seeked, run that function, query the branch to see which 
+  log files exist, and pass through dropDead to filter and populate
+  the temporary index. This way, the command does not need to buffer
+  the whole set of keys in memory.
+* Pass nonKeyLogFiles through dropDead as well.
+* Refactor regraftexports from Annex.Branch, and call it after
+  constructing the filtered index.
+"""]]
diff --git a/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_6_e479e9b65a512727f2816d4abd72b900._comment b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_6_e479e9b65a512727f2816d4abd72b900._comment
new file mode 100644
index 0000000000..476f389b54
--- /dev/null
+++ b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_6_e479e9b65a512727f2816d4abd72b900._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-05-17T18:15:55Z"
+ content="""
+This is implemented.
+"""]]
diff --git a/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_7_d64e8d82f139146338ce2fd4af1b7ad7._comment b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_7_d64e8d82f139146338ce2fd4af1b7ad7._comment
new file mode 100644
index 0000000000..374790a1d3
--- /dev/null
+++ b/doc/todo/copy-key___40__--batch__41___to_copy__47__merge_availability_info/comment_7_d64e8d82f139146338ce2fd4af1b7ad7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mih"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="Thanks!"
+ date="2022-03-04T16:23:16Z"
+ content="""
+I just had the chance to try this out, and it has worked great! Thanks much!
+"""]]
diff --git a/doc/todo/copy__47__move_support_for_pushinsteadOf_.mdwn b/doc/todo/copy__47__move_support_for_pushinsteadOf_.mdwn
new file mode 100644
index 0000000000..48c440f1eb
--- /dev/null
+++ b/doc/todo/copy__47__move_support_for_pushinsteadOf_.mdwn
@@ -0,0 +1,58 @@
+ATM
+
+files didn't `datalad push` as they should have due to existing settings of `wanted`:
+
+```
+❯ git annex wanted datasets.datalad.org
+include=.datalad/* and (not metadata=distribution-restrictions=*)
+❯ git annex find --not --in datasets.datalad.org .
+crcns-2022-dataland.pdf
+crcns-2022-dataland.png
+crcns-2022-dataland.svg
+❯ git annex metadata *
+metadata crcns-2022-dataland.pdf 
+
+ok
+metadata crcns-2022-dataland.png 
+
+ok
+metadata crcns-2022-dataland.svg 
+
+ok
+❯ git annex copy --auto --to datasets.datalad.org *
+❯ git annex version
+git-annex version: 10.20231227-1~ndall+1
+
+```
+
+so I was confused... the reason was
+
+```
+❯ git annex copy  --to datasets.datalad.org *
+copy crcns-2022-dataland.pdf (to datasets.datalad.org...) 
+  copying to non-ssh repo not supported
+failed
+copy crcns-2022-dataland.png (to datasets.datalad.org...) 
+  copying to non-ssh repo not supported
+failed
+copy crcns-2022-dataland.svg (to datasets.datalad.org...) 
+  copying to non-ssh repo not supported
+failed
+copy: 3 failed
+```
+
+wherever I have 
+
+```shell
+❯ git remote show -n datasets.datalad.org
+* remote datasets.datalad.org
+  Fetch URL: https://datasets.datalad.org/datalad/artwork/.git
+  Push  URL: falkor.dartmouth.edu:/srv/datasets.datalad.org/www/datalad/artwork/.git
+...
+```
+
+and the use case is quite common for me and in particular for ReproNim/containers which is shared/adjusted in similar ways
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
diff --git a/doc/todo/copy__47__move_support_for_pushinsteadOf_/comment_1_c5eec865ac5493f8bedf4fcba6759d6e._comment b/doc/todo/copy__47__move_support_for_pushinsteadOf_/comment_1_c5eec865ac5493f8bedf4fcba6759d6e._comment
new file mode 100644
index 0000000000..8256d1e1f2
--- /dev/null
+++ b/doc/todo/copy__47__move_support_for_pushinsteadOf_/comment_1_c5eec865ac5493f8bedf4fcba6759d6e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-02-02T17:23:13Z"
+ content="""
+This would not have prevented `copy --auto` from trying to copy the files
+and failing the same way as `copy` without that option. So I think there
+must be something in your preferred content that made it skip trying to
+copy those files.
+
+	include=.datalad/* and (not metadata=distribution-restrictions=*)
+
+Maybe you meant to have an "or" there? With the and it only wants files
+that are in .datalad/ as well as not having the metadata set.
+"""]]
diff --git a/doc/todo/copy__47__move_support_for_pushinsteadOf_/comment_2_b6d694d34e6d5a684249b11f53a8532f._comment b/doc/todo/copy__47__move_support_for_pushinsteadOf_/comment_2_b6d694d34e6d5a684249b11f53a8532f._comment
new file mode 100644
index 0000000000..093a4b358e
--- /dev/null
+++ b/doc/todo/copy__47__move_support_for_pushinsteadOf_/comment_2_b6d694d34e6d5a684249b11f53a8532f._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2024-02-02T17:25:54Z"
+ content="""
+As for `pushInsteadOf`, in 2011 this was considered
+in <https://bugs.debian.org/644278>. And the result was that git-annex
+honors `insteadOf` but not `pushInsteadOf` or `pushurl`. With the (weak?)
+rationalle that what git-annex does is neither pushing or pulling really.
+
+So it seems to me better for you to use `insteadOf`. Unless there's some
+reason why you need git to pull from the http url rather than from the ssh
+url?
+
+Perhaps you're setting this up for many users,
+some of whom are limited to read-only access.
+Pulling from http would work for those users. And git-annex get
+from http also works read-only the way your repository is set up.
+
+If that is the reason you want to use `pushInsteadOf` rather than
+`insteadOf`, it would follow that you would want git-annex to use
+the pull url for getting files, but use the push url for putting/dropping
+files.
+"""]]
diff --git a/doc/todo/copy__47__move_support_for_pushinsteadOf_/comment_3_e53e69ae3adc42bb2bf36af1f07a4c83._comment b/doc/todo/copy__47__move_support_for_pushinsteadOf_/comment_3_e53e69ae3adc42bb2bf36af1f07a4c83._comment
new file mode 100644
index 0000000000..e34fd8eba8
--- /dev/null
+++ b/doc/todo/copy__47__move_support_for_pushinsteadOf_/comment_3_e53e69ae3adc42bb2bf36af1f07a4c83._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-02-02T17:57:51Z"
+ content="""
+But: If this change were made, it would risk breaking existing
+working setups, that happen to have a push url that points to a different
+repository. When git-annex was upgraded to use the push url, it would start
+noticing that the repository behind the url has a different uuid than the
+remote does.
+
+For a ssh repository, that would prevent it from using the repository until
+the user did something to fix the configuration. 
+
+For a local repository, git-annex currently automatically updates the
+cached repository uuid. It's not clear to me how that would work if there were
+two urls pointing to two different repositories. Does seem like this would
+prevent eg, getting files from the remote that it was able to get before.
+
+I don't know how common such a setup with a push url pointing to a 
+different repository might be. I think it is much more
+likely that `remote.foo.pushurl` be pointed to some other url that is not
+on the same server. pushInsteadOf is really intended to configure a
+different access method for the same server as the repository url.
+"""]]
diff --git a/doc/todo/copy_instead_of_rename_on_reinject.mdwn b/doc/todo/copy_instead_of_rename_on_reinject.mdwn
new file mode 100644
index 0000000000..7b9c72510d
--- /dev/null
+++ b/doc/todo/copy_instead_of_rename_on_reinject.mdwn
@@ -0,0 +1,36 @@
+The same way that [[git-annex-import]] has a `--duplicate` option,
+there should be a way to reinject content without dropping the
+original file.
+
+My use case is that I had imported content in the wrong git-annex
+repository, by mistake. Unaware of my mistake, I moved the files (now
+symlinks) to the proper git-annex repo, where I added them and where
+they (obviously) were broken. So I tried to fix that with reinject:
+
+    $ git annex reinject --known ~/mp3/.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac
+    reinject /home/anarcat/mp3/.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac 
+    git-annex: /home/anarcat/mp3/.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac: rename: permission denied (Permission denied)
+    failed
+    (recording state in git...)
+    git-annex: reinject: 1 failed
+
+It *almost* worked but failed because it cannot rename the git-annex
+file on the other side. But worse, copying the file by hand does not 
+work either:
+
+    $ LANG=C cp ~/mp3/.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac ../../../.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac
+    cp: cannot create regular file '../../../.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac': Permission denied
+
+... obviously because the directory already exists and is not
+writable. The workaround is to create those directories if missing
+(`mkdir -p`) or change the mode if present (`chmod u+w`), then run
+`git-annex-fsck` which will fix those modes.
+
+Other than making reinject work against a fellow git-annex repository,
+I think this would be useful to avoid deleting files which might
+surprise users... I suggest using a logic similar to
+[[git-annex-import]] for consistency reasons.
+
+Thanks! -- [[anarcat]]
+
+[[!tag unlikely]]
diff --git a/doc/todo/copy_instead_of_rename_on_reinject/comment_1_8e1fefa8231cc93f0f1958e44d869c47._comment b/doc/todo/copy_instead_of_rename_on_reinject/comment_1_8e1fefa8231cc93f0f1958e44d869c47._comment
new file mode 100644
index 0000000000..12dd344bf5
--- /dev/null
+++ b/doc/todo/copy_instead_of_rename_on_reinject/comment_1_8e1fefa8231cc93f0f1958e44d869c47._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-29T19:20:15Z"
+ content="""
+The first word of the git-annex-reinject man page is "moves", so 
+I find it hard to believe users would be surprised that it does that.
+(Also, "inject" suggests movement.)
+
+I can't see this being anything but an option added to reinject, because
+changing behavior to copying when it's been move *would* be surprising, and
+could result in a lot of unwanted disk space being used or other problems
+with some workflow that involves reinject.
+
+I am doubtful that such an option is worth it given the way git-annex
+reinject is usually used.
+
+And if I were in your situation, which I have been, I'd just delete the symlinks
+I moved by accident, check them back out in the other repository,
+and then unannex the files and move them. Much easier than running reinject
+with long paths into the other repository.
+"""]]
diff --git a/doc/todo/copy_with_both_--to_and_--from_.mdwn b/doc/todo/copy_with_both_--to_and_--from_.mdwn
new file mode 100644
index 0000000000..8183d93c09
--- /dev/null
+++ b/doc/todo/copy_with_both_--to_and_--from_.mdwn
@@ -0,0 +1,18 @@
+We are 
+- creating git-annex repositories by minting annex keys based on metadata (size, filename extension, checksum) which we share on  https://github.com/dandisets/ and https://github.com/dandizarrs .
+- back them up as a tandem of `annex get` following by `annex move --to=backup` commands.
+
+That results 
+- temporarily first fully populate those datasets (could be TBs in size)
+- for every annexed key to have two commits to adjust the state of that key in git-annex branch -- first to announce local availability and then that it moved to another remote
+
+Ideally I would have loved if I could just say something like `git annex copy --from=someremote --to=backup .` or even better just smth like `git annex copy --auto-get --to=backup . ` and ensure that 
+- we get the file before moving it to backup
+- we do not bother recording in git-annex that the file ever existed locally
+
+NB may be some `annex sync` would do that magic?
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[implemented|done]] --[[Joey]]
diff --git a/doc/todo/copy_with_both_--to_and_--from_/comment_10_81fb304a2cdd50aa58f839a89d25f2ae._comment b/doc/todo/copy_with_both_--to_and_--from_/comment_10_81fb304a2cdd50aa58f839a89d25f2ae._comment
new file mode 100644
index 0000000000..7df7f53c68
--- /dev/null
+++ b/doc/todo/copy_with_both_--to_and_--from_/comment_10_81fb304a2cdd50aa58f839a89d25f2ae._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Thank you!!"
+ date="2023-01-24T21:15:50Z"
+ content="""
+**VERY** awesome, joey!! 🎉 Thank you so much for implementing this! 🙏
+"""]]
diff --git a/doc/todo/copy_with_both_--to_and_--from_/comment_1_0c42c2269e2fe2888254cc14a4967535._comment b/doc/todo/copy_with_both_--to_and_--from_/comment_1_0c42c2269e2fe2888254cc14a4967535._comment
new file mode 100644
index 0000000000..c9ce05d844
--- /dev/null
+++ b/doc/todo/copy_with_both_--to_and_--from_/comment_1_0c42c2269e2fe2888254cc14a4967535._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="{copy,move} with both --to and --from would be great!"
+ date="2023-01-10T09:38:39Z"
+ content="""
+That would indeed be awesome! However I guess the current implementation wouldn't support streaming files without caching them in their entirety.
+"""]]
diff --git a/doc/todo/copy_with_both_--to_and_--from_/comment_2_7db9f62f5aa3640d1f4aeeb599e02e7c._comment b/doc/todo/copy_with_both_--to_and_--from_/comment_2_7db9f62f5aa3640d1f4aeeb599e02e7c._comment
new file mode 100644
index 0000000000..252c09cbf9
--- /dev/null
+++ b/doc/todo/copy_with_both_--to_and_--from_/comment_2_7db9f62f5aa3640d1f4aeeb599e02e7c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-01-16T17:02:37Z"
+ content="""
+See [[todo/transitive_transfers]] for past discussion of this kind of
+feature (and why supporting streaming would complicate git-annex significantly
+for typically little gain).
+
+The extra commits to the git-annex branch can be avoided by
+annex.alwayscommit=false
+
+I wonder to what extent alternating getting a file with sending it on
+(and dropping it) would meet the use case? Are some files so large a single
+file cannot fit in local storage at all?
+"""]]
diff --git a/doc/todo/copy_with_both_--to_and_--from_/comment_3_05a8fbcf2b069c561b6e24286565af5f._comment b/doc/todo/copy_with_both_--to_and_--from_/comment_3_05a8fbcf2b069c561b6e24286565af5f._comment
new file mode 100644
index 0000000000..c4af4438b5
--- /dev/null
+++ b/doc/todo/copy_with_both_--to_and_--from_/comment_3_05a8fbcf2b069c561b6e24286565af5f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2023-01-16T21:43:40Z"
+ content="""
+FWIW -- alternating is fine, all my files should be able to fit on the drive individually (but not all at once) while doing some number of them in parallel.  **BUT** in some use cases (e.g. AWS) - drive IO could be slower than network IO (it was the use case which inspired me to complain to get checksumming done inbound with downloading). So, if stored locally, it has potential to become much slower.  But I am not sure if that would be feasible anyhow to establish generic pipe-ing between various remotes.
+"""]]
diff --git a/doc/todo/copy_with_both_--to_and_--from_/comment_4_b4d6b876c8f36a61268e2144d3bcf082._comment b/doc/todo/copy_with_both_--to_and_--from_/comment_4_b4d6b876c8f36a61268e2144d3bcf082._comment
new file mode 100644
index 0000000000..b0ebe44ff5
--- /dev/null
+++ b/doc/todo/copy_with_both_--to_and_--from_/comment_4_b4d6b876c8f36a61268e2144d3bcf082._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-01-17T17:09:50Z"
+ content="""
+Ok, I think this should be implemented, with alternating behavior.
+
+As for disk speed, hopefully the files mostly fit in cache...
+"""]]
diff --git a/doc/todo/copy_with_both_--to_and_--from_/comment_5_8fbf7e5ef86892f05b63e73373a97f0f._comment b/doc/todo/copy_with_both_--to_and_--from_/comment_5_8fbf7e5ef86892f05b63e73373a97f0f._comment
new file mode 100644
index 0000000000..032e0e923c
--- /dev/null
+++ b/doc/todo/copy_with_both_--to_and_--from_/comment_5_8fbf7e5ef86892f05b63e73373a97f0f._comment
@@ -0,0 +1,53 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-01-18T16:44:11Z"
+ content="""
+When there is already a local copy of a file, 
+there are two different ways that `git-annex move --from foo --to bar`
+could behave:
+
+* Drop it from foo, copy it to bar, drop it from local
+* Drop it from foo, copy it to bar
+
+Also, when there is a local copy, but foo does not have a copy, there are
+two possible behaviors:
+
+* Copy it to bar, drop it from local
+* Do nothing, since foo does not have a copy.
+
+Picking the first choice makes the behavior always be the same as
+`git-annex move --from foo; git-annex move --to bar`, except using less
+disk space.
+
+Picking the second choice in both situations makes this a move that behaves
+much as if the local repository is not involved at all (besides temporarily
+storing the content as necessary for the transfers).
+
+If `git-annex copy` also gets the feature, the choice made for move should
+probably also affect it. 
+
+Following the first path would result in
+`git-annex copy --from foo --to bar` being equivilant to
+`git-annex copy --from foo; git-annex copy --to bar`. This would not be a
+useful new feature because the local repo would end up containing all the
+content.
+
+Following the second path would mean that, when foo has a copy but there
+is no local copy, it would copy from foo, copy to bar, and drop the
+intermediate local copy. And when there is a local copy, but foo does not
+have a copy, it would do nothing.
+
+---
+
+Which is the better choice? The second is more complicated, but it adds
+a genuine new capability, rather than only a disk space optimisation.
+
+If the second is implemented but the user wants the first behavior
+instead, they can first `git-annex move --from foo --to bar`
+followed by `git-annex move --to bar`, and the result will be the same.
+
+The second will be more complicated to implement, since it will sometimes
+need to use a temp file to store the object content (when the local repo
+does not contain a copy of the content).
+"""]]
diff --git a/doc/todo/copy_with_both_--to_and_--from_/comment_6_4397649b4a2115891cb0f597999cca66._comment b/doc/todo/copy_with_both_--to_and_--from_/comment_6_4397649b4a2115891cb0f597999cca66._comment
new file mode 100644
index 0000000000..8c52557902
--- /dev/null
+++ b/doc/todo/copy_with_both_--to_and_--from_/comment_6_4397649b4a2115891cb0f597999cca66._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2023-01-18T17:55:49Z"
+ content="""
+FWIW: I also feel that 2nd one (absent affect on a possibly present locally copy) would be preferable.
+"""]]
diff --git a/doc/todo/copy_with_both_--to_and_--from_/comment_6_959f6081cb3cb777ea4fad70bad07da3._comment b/doc/todo/copy_with_both_--to_and_--from_/comment_6_959f6081cb3cb777ea4fad70bad07da3._comment
new file mode 100644
index 0000000000..4745538330
--- /dev/null
+++ b/doc/todo/copy_with_both_--to_and_--from_/comment_6_959f6081cb3cb777ea4fad70bad07da3._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-01-20T15:11:50Z"
+ content="""
+I've started on an implementation of this, in the `fromto` branch.
+
+Downloading to a local temp file has some complications which make me want
+to avoid it is possible. For one thing, these temp files would have to
+somehow get cleaned up after an interrupted move. For another, two
+concurrent move processes from different remotes to different remotes would
+need to either use separate temp files (wasting disk space) or locking so
+only one uses the temp file at one time. The existing code in
+Annex.Transfer would have to be parameterized with the temp file to use,
+but then the transfer log/lock files that are used by that code would be
+problematic. So perhaps that Annex.Transfer code could not be reused, but
+then it would need to independeantly deal with resuming, locking, and stall
+detection.
+
+So, I'm considering downloading --from the remote as usual, populating the
+local annex with the content, sending that --to the remote, and then
+dropping the local copy. That has its own complications, but they seem
+mostly less. Although there are two small races that I have not been able
+to resolve yet, which would result in `git-annex move --from --to`, when
+run concurrently with a `git-annex get` type process, result in the local
+copy not being present at the end (see [[!commit a46c385aec2584419330c5dbb571c19ceb92f6fb]]).
+That would be surprising behavior, but also unlikely to happen. 
+(And perhaps not too surprising, since running `git-annex move --to`
+concurrently with `git-annex get` can of course result in the local copy
+not being present at the end..)
+
+The latter approach also has the problem that, when the file is unlocked, the
+unlocked file would get populated after downloading the content, which would be
+unncessary work.
+"""]]
diff --git a/doc/todo/copy_with_both_--to_and_--from_/comment_8_a230b52cd5985437827bb432a85349ce._comment b/doc/todo/copy_with_both_--to_and_--from_/comment_8_a230b52cd5985437827bb432a85349ce._comment
new file mode 100644
index 0000000000..0d6ec2d0bf
--- /dev/null
+++ b/doc/todo/copy_with_both_--to_and_--from_/comment_8_a230b52cd5985437827bb432a85349ce._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2023-01-23T21:45:37Z"
+ content="""
+I did implement this using the second path described in comment #5.
+
+And it does download the content to the local annex, and then after
+sending it to the destination remote, will drop the local content
+(unless it was already present). So running it concurrent with
+`git-annex get` may leave local files present or not, depending on which
+process gets to a file first.
+"""]]
diff --git a/doc/todo/copy_with_both_--to_and_--from_/comment_9_3152d196f56561d31a00514c343669ad._comment b/doc/todo/copy_with_both_--to_and_--from_/comment_9_3152d196f56561d31a00514c343669ad._comment
new file mode 100644
index 0000000000..6cb8d89399
--- /dev/null
+++ b/doc/todo/copy_with_both_--to_and_--from_/comment_9_3152d196f56561d31a00514c343669ad._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 9"
+ date="2023-01-23T22:38:28Z"
+ content="""
+Thank you, joey for your work! I'll try it when I find the time.
+"""]]
diff --git a/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__.mdwn b/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__.mdwn
new file mode 100644
index 0000000000..2dbba4e6dc
--- /dev/null
+++ b/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__.mdwn
@@ -0,0 +1,8 @@
+Since in datalad we are invoking git and git-annex quite frequently, and on debian systems atm relying on git-annex-standalone pkg, I wondered, if there is a possibility to get all 'shimmed' binaries prelinked against shipped core libs to avoid a current bunch of unsucesfull searches for libraries.... I thought it might provide a notable benefit.
+
+just an idea
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]], but without prelinking. --[[Joey]]
diff --git a/doc/todo/create_debug_logs_but_erase_them_on_success.mdwn b/doc/todo/create_debug_logs_but_erase_them_on_success.mdwn
new file mode 100644
index 0000000000..28e1ebc482
--- /dev/null
+++ b/doc/todo/create_debug_logs_but_erase_them_on_success.mdwn
@@ -0,0 +1,5 @@
+To help understand hard-to-replicate failures, add an option to always generate a debug log but to erase it as a final step if an operation succeeds.  If an operation fails, keep the log and print a message pointing to it.
+
+Maybe, save such logs somewhere under .git/annex and have a command to upload them (over https and encrypted with @joeyh's key?)  to some server where they can be examined.
+
+> [[rejected|done]] --[[Joey]]
diff --git a/doc/todo/create_debug_logs_but_erase_them_on_success/comment_1_72b1e3b25a221f42ea7919aaecd6012d._comment b/doc/todo/create_debug_logs_but_erase_them_on_success/comment_1_72b1e3b25a221f42ea7919aaecd6012d._comment
new file mode 100644
index 0000000000..5dcf61d1ff
--- /dev/null
+++ b/doc/todo/create_debug_logs_but_erase_them_on_success/comment_1_72b1e3b25a221f42ea7919aaecd6012d._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-16T18:09:30Z"
+ content="""
+I'm doubtful about this:
+
+* It's not super likely that a debug log will have enough information in it
+  to replicate a one-off problem. At best they generally provide some clues
+  that need to be confirmed with experiments, so the problem needs to be
+  reproduced before I can fix it.
+* This risks accumulating a bunch of debug logs if the user is doing things
+  that fail. Things can fail for a wide array or reasons that do not need
+  to be debugged, eg git-annex get fails all the time for valid reasons
+  such as a host not being accessible or drive not being mounted.
+* A debug log might contain some sensitive information, git-annex should
+  certianly not be sending them around without the user's eyes on them.
+* If the user noticed git-annex is accumulating a bunch of debug logs,
+  and does feel they are sensitive information, they may lose trust in
+  git-annex.
+"""]]
diff --git a/doc/todo/create_debug_logs_but_erase_them_on_success/comment_2_8809f216aac308962917053ea24b9022._comment b/doc/todo/create_debug_logs_but_erase_them_on_success/comment_2_8809f216aac308962917053ea24b9022._comment
new file mode 100644
index 0000000000..e28490bc0a
--- /dev/null
+++ b/doc/todo/create_debug_logs_but_erase_them_on_success/comment_2_8809f216aac308962917053ea24b9022._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 2"
+ date="2020-03-26T20:36:28Z"
+ content="""
+When testing a new version of git-annex-remote-googledrive, I often use a wrapper script like this:
+
+```
+# .zshrc.local
+
+f_git_annex () {
+        log_file=$(mktemp \"$(git rev-parse --git-dir 2>/dev/null)/annex/debug.XXX.log\" 2>/dev/null)
+        if [ $? -ne 0 ]; then
+                echo \"Error creating log file. Proceeding without logging.\"
+                git annex $@
+                return $?
+        fi
+
+        git annex $@ --debug 2> $log_file
+        if [ $? -ne 0 ]; then
+                echo \"Errors occurred. Debug log in $log_file\"
+                return $?
+        else
+                rm $log_file
+        fi
+      }
+alias ga='f_git_annex'
+```
+It's good enough for me in those cases. Changing the first line of the function to something like this
+```
+log_file=$(umask 077; mktemp /tmp/annex.debug.XXX.log\" 2>/dev/null)
+```
+would help against accumulating logs.
+"""]]
diff --git a/doc/todo/debug_for___34__content_changed_while_it_was_being_sent.mdwn b/doc/todo/debug_for___34__content_changed_while_it_was_being_sent.mdwn
new file mode 100644
index 0000000000..d1254d910f
--- /dev/null
+++ b/doc/todo/debug_for___34__content_changed_while_it_was_being_sent.mdwn
@@ -0,0 +1,29 @@
+Ben is trying to troubleshoot an issue with ora external special remote [datalad/issues/5613](https://github.com/datalad/datalad/issues/5613) which seems (I didn't check, Michael [bisected](https://github.com/datalad/datalad/issues/5613#issuecomment-828731447)) to start with  [8.20200501-67-gc1cd40208 AKA 8.20200522~38](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=c1cd40208144b9aa2e65690bedf538780f2e47d1)
+
+```
+% git annex --debug copy --to inm7-storage --key MD5E-s190--e6e1f4d3923cfd861e23f0f4cb20fa03.mat     
+...
+[2021-04-28 19:04:24.889361743] /home/mih/venvs/datalad/bin/git-annex-remote-ora[1] --> TRANSFER-SUCCESS STORE MD5E-s190--e
+6e1f4d3923cfd861e23f0f4cb20fa03.mat
+[2021-04-28 19:04:24.889712207] /home/mih/venvs/datalad/bin/git-annex-remote-ora[1] <-- REMOVE MD5E-s190--e6e1f4d3923cfd861
+e23f0f4cb20fa03.mat
+[2021-04-28 19:04:24.896431701] /home/mih/venvs/datalad/bin/git-annex-remote-ora[1] --> REMOVE-SUCCESS MD5E-s190--e6e1f4d39
+23cfd861e23f0f4cb20fa03.mat
+
+  content changed while it was being sent
+failed
+[2021-04-28 19:04:24.944472153] process [173173] done ExitSuccess
+git-annex: copy: 1 failed
+```
+
+so from all looks everything went well but then git-annex decided that file has changed (locally?).  
+
+Could there be more information somehow (e.g. that size changed, file disappeared, inode changed, ...)?
+
+May be extra logging could already be triggered with some new more detailed debug info?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> <https://git-annex.branchable.com/bugs/__34__failed_to_send_content_to_remote__34__/>
+> is fixed, so [[done]] --[[Joey]]
diff --git a/doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_1_bce631c26907d03314cfc2e94933cce9._comment b/doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_1_bce631c26907d03314cfc2e94933cce9._comment
new file mode 100644
index 0000000000..67379855f8
--- /dev/null
+++ b/doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_1_bce631c26907d03314cfc2e94933cce9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-05-19T15:01:06Z"
+ content="""
+It's a change to the stat information. The only likely scenario would be if
+annex.hardlink is in use and the file is unlocked and gets modified.
+
+There's not much to debug, all it knows is the before and after stat.
+"""]]
diff --git a/doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_2_8093d410c2b359967ee7ee8886d7e4c4._comment b/doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_2_8093d410c2b359967ee7ee8886d7e4c4._comment
new file mode 100644
index 0000000000..9c9bb34124
--- /dev/null
+++ b/doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_2_8093d410c2b359967ee7ee8886d7e4c4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-07-22T17:32:30Z"
+ content="""
+This request seems like it might be related to 
+<https://git-annex.branchable.com/bugs/__34__failed_to_send_content_to_remote__34__/>.
+Same basic problem and I think Michael is involved with both. Are these the
+same problem?
+"""]]
diff --git a/doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_3_78551b601b04b8336a858adfcff29507._comment b/doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_3_78551b601b04b8336a858adfcff29507._comment
new file mode 100644
index 0000000000..6a52dfa01c
--- /dev/null
+++ b/doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_3_78551b601b04b8336a858adfcff29507._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2023-05-12T13:22:00Z"
+ content="""
+since referenced issue was \"cleaned up\", I deduce from git log that it was fixed in [8.20210714-78-g3b5a3e168d AKA 8.20210803~31](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=3b5a3e168d8decd196509ad582ad4b8795d979a6).  In my case I am getting it with `8.20210223-1~ndall+1` so I better upgrade first indeed.
+"""]]
diff --git a/doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_4_d9faaaf2dd44e609fcf361189b247bed._comment b/doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_4_d9faaaf2dd44e609fcf361189b247bed._comment
new file mode 100644
index 0000000000..c6b6b643a3
--- /dev/null
+++ b/doc/todo/debug_for___34__content_changed_while_it_was_being_sent/comment_4_d9faaaf2dd44e609fcf361189b247bed._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2023-05-12T13:22:19Z"
+ content="""
+since referenced issue was \"cleaned up\", I deduce from git log that it was fixed in [8.20210714-78-g3b5a3e168d AKA 8.20210803~31](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=3b5a3e168d8decd196509ad582ad4b8795d979a6).  In my case I am getting it with `8.20210223-1~ndall+1` so I better upgrade first indeed.
+"""]]
diff --git a/doc/todo/deferred_update_mode.mdwn b/doc/todo/deferred_update_mode.mdwn
new file mode 100644
index 0000000000..84193fd92e
--- /dev/null
+++ b/doc/todo/deferred_update_mode.mdwn
@@ -0,0 +1,42 @@
+`git annex sync` and the assistant do a merge of new revs, and then
+download the content of files. However, this means that broken links can
+show up, when a file has changed, or a new file was added. In some
+workflows, the user would prefer not to ever see such broken links
+(or at least never for files that are in the repo's preferred content).
+
+So, how about a new mode, that defers updating the work tree until
+the content of everything wanted is available?
+
+This could be a annex.merge=downloadfirst setting; it would make sync/assistant
+look at the diff between HEAD and the new rev, and try to get all annexed files
+added in that diff, before merging it. 
+
+Of course, it could take a long time to get to see a new work tree.
+Might have to download a lot of content.
+
+What to do if it fails to download a file's content? Could either
+abort, leaving the current work tree as-is, or could go ahead and merge,
+letting broken links show up in this case. I kind of prefer the abort
+option. But, if the content never reaches any remote, or has gone missing
+entirely, that would make sync never succeed. That could be surprising
+behavior.
+
+Probably best to let the user pick either behavior, so
+annex.merge=trydownloadfirst and annex.merge=reqdownloadfirst
+
+Let `git annex merge` be used to force a merge, even when content is not
+available.
+
+## alternatively
+
+What about just making `git-annex sync --content` try to get the content of
+all files before updating the work tree? (The assistant would need changes
+too; it would need to queue all the downloads and trigger a work tree
+update once all the downloads have been tried.)
+
+> `git-annex adjust --hide-missing` implements this. The assistant
+> does not support it yet, and there's a todo for that,
+> [[todo/assistant_support_hide-missing]]
+> 
+> So, closing this as there's a path forward in that other todo. [[done]]
+> --[[Joey]]
diff --git a/doc/todo/deleting_a_repository_from_history.mdwn b/doc/todo/deleting_a_repository_from_history.mdwn
new file mode 100644
index 0000000000..c5be914ad7
--- /dev/null
+++ b/doc/todo/deleting_a_repository_from_history.mdwn
@@ -0,0 +1,11 @@
+Say I have two **unrelated** videos repositories. Say that, by some mistake of history, one was added as the git remote of the other. I somehow managed to clean the git history and disentangle the files between the two repos.
+
+Now git-annex still thinks about that other repository. I can mark it as dead, but it will still have location tracking information for all the files of the other repository.
+
+I know about [[git-annex-forget]]: I'm not sure it's what I want. I do not want to "[throw] away historical data about past locations of files", I would actually *want* to keep historical location data for relevant files. I want to forget a *repository* ever existed.
+
+Is that possible?
+
+Marking it with [[git-annex-dead]] doesn't cut it, from what I understand. In [[tips/what_to_do_when_you_lose_a_repository]], joeyh seemed to say "`dead` is the best we can do", as "the automatic merging used on the git-annex branch tends to re-add lines that are deleted in one repo when merging with another that still has them." But now we have something like `forget`, could that be coerced into forgetting just a subset of stuff?
+
+Thanks! -- [[anarcat]]
diff --git a/doc/todo/deleting_a_repository_from_history/comment_1_bcaa591f37f3496c2f7a2e1f06450002._comment b/doc/todo/deleting_a_repository_from_history/comment_1_bcaa591f37f3496c2f7a2e1f06450002._comment
new file mode 100644
index 0000000000..1ed45abc29
--- /dev/null
+++ b/doc/todo/deleting_a_repository_from_history/comment_1_bcaa591f37f3496c2f7a2e1f06450002._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-08-10T01:08:16Z"
+ content="""
+This has happened repeatedly to me and I feel your pain. It is especially likely to happen when using submodules, which can sometimes be uninitialized, so when you enter them and modify `git remote`s from there, you're actually messing up the parent repo.
+
+I'm afraid there's no convenient way to purge git annex remotes except marking as `dead` and then `forget --drop-dead`, which loses past location history as well.
+
+What you can do though is trying to manually kick the bad commit out of the git-annex branch (e.g. `git rebase -i`), then force-push the git-annex branch to all remotes. If you miss one remote, the bad commit will be reintroduced somewhen later.
+"""]]
diff --git a/doc/todo/deleting_a_repository_from_history/comment_2_69de586c7c030f75fd540d05a6ca4ddb._comment b/doc/todo/deleting_a_repository_from_history/comment_2_69de586c7c030f75fd540d05a6ca4ddb._comment
new file mode 100644
index 0000000000..8e3f4ff74c
--- /dev/null
+++ b/doc/todo/deleting_a_repository_from_history/comment_2_69de586c7c030f75fd540d05a6ca4ddb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-08-22T16:03:55Z"
+ content="""
+`git-annex forget --drop-dead` is probably the best answer.
+
+Yes, this also deletes historical data about past locations of files. The
+only user-visible effect of that is that `git-annex log` won't show where
+files used to be located.
+
+It has to delete history, because history includes all the data that was
+merged from the other repository. And it would be too hard to traverse all
+history and delete any information that came from that repository in every
+commit.
+"""]]
diff --git a/doc/todo/detect_and_handle_submodules_after_path_changed_by_mv.mdwn b/doc/todo/detect_and_handle_submodules_after_path_changed_by_mv.mdwn
new file mode 100644
index 0000000000..2e41a31131
--- /dev/null
+++ b/doc/todo/detect_and_handle_submodules_after_path_changed_by_mv.mdwn
@@ -0,0 +1,75 @@
+It's an enhancement feature to handle submodules to manage data with associated its projects.
+
+I want `git-annex` could detect submodule paths changed on disks which was cause by `mv` or file explorer.
+If user uses `git-annex-assist daemon` or `git-annex-assist` command directly after `mv` command, The submodules would be totally broken.
+
+Currently, the workaround is just use `git-mv` on each submodules manually.
+
+I made a testing shell script for this. 
+
+
+```shell
+#!/bin/bash
+# This is test script for submodule path changing.
+# set -e
+USE_GIT_MV=false # USE_GIT_MV=true works correctly
+cd /tmp/
+mkdir -p test_sub/{archive/projects,projects/2023_01_personal_some_cool_project,resources}
+cd test_sub
+git init
+git annex init
+git annex version
+cd projects/2023_01_personal_some_cool_project
+
+echo NOTE: Add some data and sub-projects for testing
+touch README.md 01_dataset_lists.csv 09_reports.md
+git submodule add https://github.com/Lykos153/git-annex-remote-googledrive.git
+git submodule add https://github.com/alpernebbi/git-annex-adapter.git
+git submodule status # check it
+git annex assist
+echo
+
+echo NOTE: I think that the projects are need to be changed "01_Projects" for sorting order.
+cd /tmp/test_sub
+if $USE_GIT_MV; then
+    git mv projects 01_Projects
+else
+    # NOTE: Just rename file makes submodules broken. directory depth is same
+    mv projects 01_Projects
+    (
+        cd 01_Projects/2023_01_personal_some_cool_project/git-annex-adapter
+        git status # it shows 'No such file or directory'
+    )
+fi
+git submodule status # check it
+git annex assist
+echo
+
+echo NOTE: I want to change some submodule name is for referencing just for work.
+cd /tmp/test_sub/01_Projects/2023_01_personal_some_cool_project
+if $USE_GIT_MV; then
+    git mv git-annex-adapter ref_sample_adapter_code
+else
+    # NOTE: Just rename file makes submodules broken. directory depth is same
+    mv git-annex-adapter ref_sample_adapter_code
+fi
+git submodule status # check it
+git annex assist
+echo
+
+echo NOTE: Now, i want to archive my old projects.
+cd /tmp/test_sub
+if $USE_GIT_MV; then
+    git mv 01_Projects/2023_01_personal_some_cool_project archive/projects/2023_01_personal_some_cool_project
+else
+    # NOTE: Just rename file makes submodules broken. directory depth is changed
+    mv 01_Projects/2023_01_personal_some_cool_project archive/projects/2023_01_personal_some_cool_project
+fi
+git submodule status # check it
+git annex assist
+echo
+
+echo test done
+``
+
+> [[wontfix|done]] as it is out of scope --[[Joey]]`
diff --git a/doc/todo/detect_and_handle_submodules_after_path_changed_by_mv/comment_1_9f9da126a031d2a4c98555b381dbcbdc._comment b/doc/todo/detect_and_handle_submodules_after_path_changed_by_mv/comment_1_9f9da126a031d2a4c98555b381dbcbdc._comment
new file mode 100644
index 0000000000..1c315954de
--- /dev/null
+++ b/doc/todo/detect_and_handle_submodules_after_path_changed_by_mv/comment_1_9f9da126a031d2a4c98555b381dbcbdc._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-02-22T16:43:01Z"
+ content="""
+AFAICS, the behavior is the same if you do not use git-annex at all and mv
+submodules around generally.
+
+This strongly suggests that dealing with this is out of scope for
+git-annex.
+"""]]
diff --git a/doc/todo/distributed_migration.mdwn b/doc/todo/distributed_migration.mdwn
new file mode 100644
index 0000000000..45a6d14398
--- /dev/null
+++ b/doc/todo/distributed_migration.mdwn
@@ -0,0 +1,71 @@
+Currently `git-annex migrate` only hard links the objects in the local
+repo. This leaves other clones without the new keys' objects unless
+they re-download them, or unless the same migrate command is
+re-run, in the same tree, on each clone.
+
+It would be good to support distributed migration, so that whatever
+migration is done in one repo is reflected in the other repos.
+
+This needs some way to store, in the git repo, a mapping between the old
+key and the new key it has been migrated to. (I investigated
+how much space that would need in the git repo, in 
+[this comment](https://git-annex.branchable.com/todo/alternate_keys_for_same_content/#comment-917eba0b2d1637236c5d900ecb5d8da0).)
+The mapping might be communicated via the git branch but be locally stored
+in a sqlite database to make querying it fast.
+
+Once that mapping is available, one simple way to use it would be a
+git-annex command that updates the local repo to reflect migrations that
+have happened elsewhere. It would not touch the HEAD branch, but would 
+just hard link object files from the old to new key, and update the location
+log for the new key to indicate the content is present in the repo.
+This command could be something like `git-annex migrate --update`.
+
+Rather than a dedicated command that users need to remember to run,
+distributed migration could be done automatically when merging a git-annex
+branch that adds migration information. Just hardlink object files and
+update the location log.
+
+It would be possible to avoid updating the location log, but then all
+location log queries would have to check the migration mapping. It would be
+hard to make that fast enough. Consider `git-annex find --in foo`, which
+queries the location log for each file.
+
+--[[Joey]]
+
+> [[done]] --[[Joey]]
+
+# security
+
+It is possible for bad migration information to be recorded in the
+git-annex branch by someone malicious. To avoid bad or insecure behavior
+when bad migration information is recorded:
+
+* When updating the local repository with a migration, verify that
+  the object file hashes to the new key before hardlinking.
+
+> This was done.
+
+That leaves at these possible security problems:
+
+* DOS by flooding the git-annex branch with migrations, resulting in 
+  lots of hard links (or copies on filesystems not supporting hard links)
+  and hashing of large files.
+
+Note that a malicious person who can write to the git-annex branch
+can already set their own repo as trusted, wait for someone
+to drop their local copy, and then demand a ransom for the content.
+For that matter, someone hosting a git-annex remote on a server can wait
+for someone to rely on it to contain the only copy of content and ransom
+it then. 
+
+git-annex is probably not normally used in situations where we
+need to worry about this kind of attack; if we don't trust someone we
+shouldn't pull the git-annex branch from them, and should not trust their
+remote to contain the only copy.
+
+If we pull a git-annex branch from someone, they can already DOS disk space
+and CPU by checking a lot of junk into git. So maybe a DOS by migration is
+not really a concern.
+
+> If people are worried about this kind of thing, they can avoid using the
+> feature. --[[Joey]]
diff --git a/doc/todo/distributed_migration/comment_1_8734d30aa0c1cb27dce81a0277d24948._comment b/doc/todo/distributed_migration/comment_1_8734d30aa0c1cb27dce81a0277d24948._comment
new file mode 100644
index 0000000000..180e937c2d
--- /dev/null
+++ b/doc/todo/distributed_migration/comment_1_8734d30aa0c1cb27dce81a0277d24948._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-12-01T19:00:41Z"
+ content="""
+Even if the stuff with special remotes turned out to be too complicated to
+implement, `git-annex migrate --update` would be useful for some users.
+So it's worth implementing the mapping and then incrementally implementing
+these ideas.
+"""]]
diff --git a/doc/todo/distributed_migration/comment_2_fdaef5d870221d44c57fc3bd1501e7ee._comment b/doc/todo/distributed_migration/comment_2_fdaef5d870221d44c57fc3bd1501e7ee._comment
new file mode 100644
index 0000000000..40276efe9d
--- /dev/null
+++ b/doc/todo/distributed_migration/comment_2_fdaef5d870221d44c57fc3bd1501e7ee._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-12-06T19:31:42Z"
+ content="""
+On the `distributedmigration` branch I have `git-annex migrate` recording
+migrations on the git-annex branch.
+
+Its method of grafting in 2 trees, one with the old keys and one with the
+new is quite efficient. In a migration of 1000 files from SHA256E to SHA1,
+the git objects only needs 52kb to record the migration trees. 
+Compared with 424 kb needed to update the location logs. 
+The total git repo grew from 508kb to 984k.
+
+Next up: Make `git-annex migrate --update` find new migrations started
+elsewhere and apply them to the local annex objects.
+"""]]
diff --git a/doc/todo/distributed_migration_for_special_remotes.mdwn b/doc/todo/distributed_migration_for_special_remotes.mdwn
new file mode 100644
index 0000000000..5794aed185
--- /dev/null
+++ b/doc/todo/distributed_migration_for_special_remotes.mdwn
@@ -0,0 +1,41 @@
+[[distributed_migration]] is implemented for local repositories via
+`git-annex migrate --update`.
+
+That leaves updating special remotes after a migration as the main pain
+point in doing migrations.
+
+One approach would be a command like `git-annex migrate
+--update-remote=foo` that uploads new keys and drops old keys.
+But that would double the data stored in the special remote and use a lot
+of bandwidth.
+
+Alternatively, the old key could be left on a special remote, but update
+the location log for the special remote to say it has the new key,
+and have git-annex request the old key when it wants to get (or checkpresent)
+the new key from the special remote.
+This would need the mapping to be cheap enough to query that it won't
+signficantly slow down accessing a special remote.
+
+Dropping the new key from the special remote would then need to drop the
+old key. But that could violate numcopies for the old key. Perhaps it could
+check numcopies for the old key and drop it, otherwise leave the old key on
+the special remote.
+
+--[[Joey]]
+
+# security
+
+
+When downloading content from a special remote by getting the old
+pre-migration key it's important to verify that download hashes to the new key.
+See [[distributed_migration]]'s security section for relevant background.
+
+Another problem to consider: checkpresent against the special remote has to
+trust that the content stored on it for the old key will hash to the new
+key. This could result in data loss when a bad migration is provided, and
+the special remote is trusted.
+
+Eg, if key A is locally present, and B is present on the special
+remote, and then wrong migration is recorded from B to A, 
+the special remote will be treated as containing a copy of A,
+allowing dropping the local copy of A, which was the only copy.
diff --git a/doc/todo/ditch_yesod.mdwn b/doc/todo/ditch_yesod.mdwn
new file mode 100644
index 0000000000..d8ef722ae5
--- /dev/null
+++ b/doc/todo/ditch_yesod.mdwn
@@ -0,0 +1,36 @@
+I'd like to move away from using yesod for the web app, for a number of
+reasons:
+
+* It's by far the largest use of TH in git-annex, and TH is of course very
+  painful for the android port, other builds like debian mips that don't
+  currently support TH, etc. (Update: mips does support it now, it seems!)
+* I think it's responsible for at least 50% of the executable size, and I
+  suspect a lot of that is unnecessary bloat for parts of yesod that
+  git-annex doesn't really use.
+* Hamlet constantly annoys me by rejecting any file that contains tabs.
+  **Rage**
+* Hamlet contains code that's not really haskell, but looks a lot like it.
+  This is a continual frustration when dealing with the hamlet files.
+* I find that Hamlet does not lend itself to being refactored, everything
+  is essentially an IO action with side effects of generating html, so
+  can't really bring proper FP tools to bear.
+
+At the moment, servant seems like the nicest place to end up. Just as type
+safe as yesod afaik, and very lightweight and simple and rather awesome.
+
+As for the html generation, lucid seems like a good way to do it. Just as
+fast as hamlet, and pure haskell code.
+
+Game plan:
+
+1. Upload a yesod-lucid to hackage. (done)
+2. Get servant (done), lucid (done), maybe yesod-lucid, packaged in Debian
+3. Start converting individual yesod Handler Html to Handler LucidHtml.
+   This will ditch the hamlet. This is by far the most work, but it can be
+   done incrementally w/o breaking the build.
+4. Need to find a way to deal with Hamlet widgets that add CS and JS to
+   the page. Hamlet basically serves as a Writer monad to collect the HTML,
+   CS, and JS that widgets add to a page, so a replacement for that would
+   need to be developed.
+5. Once all the hamlet is gone, remove the rest of the yesod stuff and
+   re-implement the routing etc with servant.
diff --git a/doc/todo/ditch_yesod/comment_1_976dcb99ebe30c02c9b223f19a67c875._comment b/doc/todo/ditch_yesod/comment_1_976dcb99ebe30c02c9b223f19a67c875._comment
new file mode 100644
index 0000000000..d09065e016
--- /dev/null
+++ b/doc/todo/ditch_yesod/comment_1_976dcb99ebe30c02c9b223f19a67c875._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="umeboshi"
+ subject="Link to TH"
+ date="2015-12-29T20:36:41Z"
+ content="""
+I had to google for [TH](https://wiki.haskell.org/Template_Haskell).  I'm posting this link for those who, like me, are less familiar with Haskell.
+"""]]
diff --git a/doc/todo/do_not_bug_me_about_intermediate_files.mdwn b/doc/todo/do_not_bug_me_about_intermediate_files.mdwn
new file mode 100644
index 0000000000..99a8f5b194
--- /dev/null
+++ b/doc/todo/do_not_bug_me_about_intermediate_files.mdwn
@@ -0,0 +1,7 @@
+[[!meta title="--notify-finish operates on a per-file, not per-process basis"]]
+
+so this is another UX pickyness, but it seems important to me.
+
+i like the new [[desktop notifications|tips/file_manager_integration]], but they are little too verbose. when i choose "git annex get" on the folder, if there's a lot of files, it will flood me with all the files being transfered in a mostly incomprehensible list of files being transfered.
+
+what i would expect is more: "starting transfer of folder X", "transfer of folder X finished!", only two message per item i chose. this is especially a problem with DVD backups, which have a bunch of small files (screenshots, .nfos and so on) and large video files - so it seems the thing has finished transfering, while it's only partly done. --[[anarcat]]
diff --git a/doc/todo/do_not_count_trusted_repos_toward_mincopies.mdwn b/doc/todo/do_not_count_trusted_repos_toward_mincopies.mdwn
new file mode 100644
index 0000000000..69f7dff948
--- /dev/null
+++ b/doc/todo/do_not_count_trusted_repos_toward_mincopies.mdwn
@@ -0,0 +1,56 @@
+Currently, setting a repo to trusted can result in data loss if content
+gets removed from that repo. For this reason, --trust has been disabled,
+and `git-annex trust` needs --force.
+
+My idea for a better way to handle this is to make trusted repos that
+cannot be checked not count toward satisfying mincopies. So while trusting
+a repository would let numcopies be violated still, it would avoid data
+loss. That would be enough to bring back --trust and not need --force.
+
+Aside from preventing data loss in some situations, the impact of this
+behavior change would be that dropping content would fail in some
+situations where it used to work. Specifically, when a trusted repo
+contains content, but is not accessible, and no other accessible repo
+contains the content. That has been a valid use of trusted repos, but it's
+also obviously an unsafe one -- if that trusted repo has dropped the
+content in the meantime, it risks data loss.
+
+So, is it worth breaking an existing, but unsafe use case, in order to make
+it easier to use trust safely?
+
+Without an answer to that question, one approach would be to add an
+ultimatelytrusted level, which behaves like trusted does now. The
+serialization of ultimatelytrusted would be what is used for trusted now,
+so existing trusted repositories would convert to it, and no behavior would
+change. The new trusted would use a different serialization, which old
+versions of git-annex would be unable to parse, but parsing defaults to
+semitrusted, so old versions of git-annex would behave safely.
+
+Then after some amount of time, users can be polled to see if they
+need ultimatelytrusted, and if not it can be deprecated and eventually be
+changed to be the same as new trusted. Or, a gitconfig can be added that
+makes ultimatelytrusted behave the same as trusted.
+
+That seems like a reasonable plan.
+
+(I thought about just adding a gitconfig now to control which behavior
+to use for trusted, but that would not be safe, if a user expects the new
+trusted behavior, they could `git-annex trust` a repo, but then later
+the gitconfig gets unset, or is not set in a clone.)
+
+----
+
+A complication with implementation: Currently when checking if a drop is safe,
+trusted repositories result in a TrustedCopy, and are not checked. And it
+checks other repositories until it has enough other evidence that the drop
+is safe. But now it would need to check some trusted repositories,
+while providing TrustedCopy for ones that it has not checked.
+
+One way to deal with that is, check trusted repositories in amoung the
+rest (in cost order). If content is present, add a LockedCopy or
+a RecentlyVerifiedCopy to the evidence. If the content is not present,
+add nothing to the evidence (or could add TrustedCopy, but there seems 
+no benefit to doing that). If the repository cannot be accessed, add
+a TrustedCopy to the evidence.
+
+--[[Joey]]
diff --git a/doc/todo/do_not_count_trusted_repos_toward_mincopies/comment_1_66a71fdd9bdc2387870f4216841b9900._comment b/doc/todo/do_not_count_trusted_repos_toward_mincopies/comment_1_66a71fdd9bdc2387870f4216841b9900._comment
new file mode 100644
index 0000000000..955a2cff0e
--- /dev/null
+++ b/doc/todo/do_not_count_trusted_repos_toward_mincopies/comment_1_66a71fdd9bdc2387870f4216841b9900._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 1"
+ date="2022-03-31T10:39:28Z"
+ content="""
+Perhaps there could be a way to manually \"lock\" a remote into append-only permanently such that all repos perceive it as locked and therefore trust it to keep its content.
+
+Obviously this isn't as good of a trust as having it connected directly and actively locking it at runtime but it's the best you could do for cold storage. (Btw, does git-annex check whether the content to be dropped is actually present in the repos it locked?)
+
+The append-only repo would only be allowed to unlock itself and drop content again when all other (unlocked?) repos ack'd the unlock (or via `--force`).
+"""]]
diff --git a/doc/todo/do_not_count_trusted_repos_toward_mincopies/comment_2_058f521451ff38d2072af6c944143ab1._comment b/doc/todo/do_not_count_trusted_repos_toward_mincopies/comment_2_058f521451ff38d2072af6c944143ab1._comment
new file mode 100644
index 0000000000..b2d25c6abd
--- /dev/null
+++ b/doc/todo/do_not_count_trusted_repos_toward_mincopies/comment_2_058f521451ff38d2072af6c944143ab1._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-06-28T16:13:05Z"
+ content="""
+Perhaps it would be better to leave trusted working as it does now, and
+introduce a new intermediate trust level. It could be called eg, "offline".
+
+An offline repo would count toward numcopies when not available, but 
+would only count toward mincopies if it happened to be available at the
+time.
+
+It might then be that there's no real need for the less safe trusted,
+and users could be polled and it deprecated if so.
+
+(This might also be a good opportunity to improve the "semitrust" name,
+which would not make much sense if the list was untrust, semitrust,
+offline, trust. "normal" perhaps. Would need to still accept the old name
+for back-compat of course.)
+"""]]
diff --git a/doc/todo/dockerized_external_special_remotes.mdwn b/doc/todo/dockerized_external_special_remotes.mdwn
new file mode 100644
index 0000000000..af06524e6a
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes.mdwn
@@ -0,0 +1,3 @@
+If an external special remote is implemented as a Docker container, it can be safely autoenabled and run in a sandboxed way.  So the distributor of a repo that has annex files fetchable with a given special remote, could have the docker tag for the special remote configured on the git-annex branch, and users could then clone and use the repo without needing to install anything.
+
+[[!tag needsthought]]
diff --git a/doc/todo/dockerized_external_special_remotes/comment_10_82d0eba3b5658990aa1e909758d75291._comment b/doc/todo/dockerized_external_special_remotes/comment_10_82d0eba3b5658990aa1e909758d75291._comment
new file mode 100644
index 0000000000..26cca29872
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_10_82d0eba3b5658990aa1e909758d75291._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-04-08T17:40:40Z"
+ content="""
+Prompting users about things rarely improves security.
+(Not saying it doesn't in the case of emacs org mode, which may be a
+special case.) A good way to make clear to a user that they are running
+code that comes from a git repository is to make them take the effort to
+run ./setup or something like that.
+
+It would also be weird for git-annex to prompt for this, since it never
+prompts about anything else, and auto-enabling these special remotes could
+happen when running any git-annex command.
+"""]]
diff --git a/doc/todo/dockerized_external_special_remotes/comment_1_d1a0106951c070b56bc30a67c8804374._comment b/doc/todo/dockerized_external_special_remotes/comment_1_d1a0106951c070b56bc30a67c8804374._comment
new file mode 100644
index 0000000000..5c10c0f4bb
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_1_d1a0106951c070b56bc30a67c8804374._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-12-04T19:56:36Z"
+ content="""
+Some external special remotes need to run git-annex, for things not directly supported by the protocol; a dockerized remote implementation couldn't do that.  But maybe, the protocol could be extended with a command by which the remote asks git-annex to run a given git-annex command, and return paths to files containing the output and the exit code?
+"""]]
diff --git a/doc/todo/dockerized_external_special_remotes/comment_2_61a23adb5b871b178d3fb5a51602cf46._comment b/doc/todo/dockerized_external_special_remotes/comment_2_61a23adb5b871b178d3fb5a51602cf46._comment
new file mode 100644
index 0000000000..07c9427657
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_2_61a23adb5b871b178d3fb5a51602cf46._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-12-05T16:24:17Z"
+ content="""
+Couldn't the docker image come with its own copy of git-annex?
+Not super space efficient, but it ensures that the special remote has
+access to a version of git-annex with the features it needs.
+"""]]
diff --git a/doc/todo/dockerized_external_special_remotes/comment_3_a044848ea54aebc2196376f9a59ccc70._comment b/doc/todo/dockerized_external_special_remotes/comment_3_a044848ea54aebc2196376f9a59ccc70._comment
new file mode 100644
index 0000000000..914b27aa43
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_3_a044848ea54aebc2196376f9a59ccc70._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-12-05T16:27:47Z"
+ content="""
+I think this could be a good idea, although I would not want to be forced
+to use docker as the only way to install an external special remote either.
+
+It seems that the minimum needed is a way to add a shell script to
+PATH with the name of the external special remote program, so git-annex can
+run it as usual. Or git-annex could invoke `docker run` itself, but I like
+having a shell script because it means git-annex doesn't need to know about
+docker and other containerization technologies.
+
+OTOH, I can see it would be nice if `git annex enableremote` could somehow
+get everything set up to use docker, and `git annex init` could fully set
+up autoenable=true special remotes.
+
+A balance could be for `git annex enableremote` to set up the shell script,
+perhaps in `.git/annex/externals/`. Store a few values like which docker
+image to use in the remote config, and generate the shell script from that.
+Then when a user needs to pass extra parameters to docker, or if they want
+to use rkt etc, they can just edit the shell script.
+"""]]
diff --git a/doc/todo/dockerized_external_special_remotes/comment_4_3ace886382ff165db6f36df8743ca7c1._comment b/doc/todo/dockerized_external_special_remotes/comment_4_3ace886382ff165db6f36df8743ca7c1._comment
new file mode 100644
index 0000000000..3998cb0e15
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_4_3ace886382ff165db6f36df8743ca7c1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="autoenabling external special remotes"
+ date="2021-03-30T15:17:02Z"
+ content="""
+\"the minimum needed is a way to add a shell script to PATH with the name of the external special remote program\" -- that would of course be simpler; could specify a relative path within the repo itself.  But auto-running an untrusted script fetched along with the repo may be risky.  A Docker/Singularity container could be sandboxed; or maybe `chroot` or `bash -r` would suffice?
+
+"""]]
diff --git a/doc/todo/dockerized_external_special_remotes/comment_5_4e09e2a08f07924ef791d63da56df066._comment b/doc/todo/dockerized_external_special_remotes/comment_5_4e09e2a08f07924ef791d63da56df066._comment
new file mode 100644
index 0000000000..f4028c6e81
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_5_4e09e2a08f07924ef791d63da56df066._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 5"
+ date="2021-03-30T16:21:10Z"
+ content="""
+IMHO, docker is too insecure to auto-install, enable and execute random special-remote programs. It has a extremely large attack surface (syscalls, ioctls, etc.) compared to, say, virtual machines. [And people regularly are able to break out of the latter](https://en.wikipedia.org/wiki/Virtual_machine_escape).
+"""]]
diff --git a/doc/todo/dockerized_external_special_remotes/comment_6_c43d5137b595edc3db130158293431ff._comment b/doc/todo/dockerized_external_special_remotes/comment_6_c43d5137b595edc3db130158293431ff._comment
new file mode 100644
index 0000000000..3b9f492a9d
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_6_c43d5137b595edc3db130158293431ff._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="dockerized special remotes: security"
+ date="2021-04-01T15:20:01Z"
+ content="""
+\"docker is too insecure to auto-install, enable and execute random special-remote programs\" -- interesting, didn't realize that.   Maybe prompt the user for permission, and/or tell them to set a git config setting to enable auto-install?
+
+In practice people often end up running less-than-vetted code, e.g. when trying out python packages written by people they don't know.  Running sandboxed code seems relatively safe next to that.
+
+Related: [dockerized external backends](https://git-annex.branchable.com/todo/external_backends/#comment-8d1d693391b3b30778c9ad8a0e8330e8) .
+
+"""]]
diff --git a/doc/todo/dockerized_external_special_remotes/comment_7_dc3e46508758b1df241ba0af78fbc692._comment b/doc/todo/dockerized_external_special_remotes/comment_7_dc3e46508758b1df241ba0af78fbc692._comment
new file mode 100644
index 0000000000..9ce1857d03
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_7_dc3e46508758b1df241ba0af78fbc692._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-04-01T16:22:32Z"
+ content="""
+There is an expectation that checking out and looking at a git repository
+will not cause arbitrary code to be run, sandboxed or not.
+
+I think this can easily be dealt with in layers above git-annex, which can
+have different expectations about what code is safe to run.
+"""]]
diff --git a/doc/todo/dockerized_external_special_remotes/comment_8_a32b4ec09da1bee3c960fa8fcfa0d797._comment b/doc/todo/dockerized_external_special_remotes/comment_8_a32b4ec09da1bee3c960fa8fcfa0d797._comment
new file mode 100644
index 0000000000..40b3968bdf
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_8_a32b4ec09da1bee3c960fa8fcfa0d797._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2021-04-01T19:41:10Z"
+ content="""
+How about this as a compromise that avoids any unwanted code execution
+while making it easy to enable if you do want it:
+
+When git-annex enables an external special remote (including autoenable),
+and the special remote program is not available in PATH, and a git config
+(call it annex.special-remote-installer) is set to a command, git-annex
+runs that command with the name of the special remote program it wanted to
+install. The command should install the special remote program into a
+particular subdirectory in .git/annex/, and git-annex will then use it.
+
+It would then be up to users to decide if they want to set that git config,
+or if something is being built on top of git-annex and sets up the git repo
+for them, it could set the config to point to whatever command it provides
+to install special remote programs.
+
+This also has the benefit of not tying git-annex to any particular
+technology like docker.
+"""]]
diff --git a/doc/todo/dockerized_external_special_remotes/comment_9_f5c0b77e06b7a65f2582c56011217d5c._comment b/doc/todo/dockerized_external_special_remotes/comment_9_f5c0b77e06b7a65f2582c56011217d5c._comment
new file mode 100644
index 0000000000..3858b42103
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_9_f5c0b77e06b7a65f2582c56011217d5c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="running untrusted code"
+ date="2021-04-07T16:52:41Z"
+ content="""
+My main reason for wanting dockerized special remotes and external backends, is to be able to use custom remotes/backends without adding a burden on repo users (beyond the standard `git-annex-init` after checkout), similar to what autoenabling of remotes does.  So needing users to know about and set some special git config kind of removes the point.   Maybe, instead, can just prompt the user for permission to install an external remote/backend, like [what emacs does](https://orgmode.org/manual/Code-Evaluation-Security.html) for calling untrusted code?
+
+In practice you'd typically trust code from a specific repo or author, so not sure `annex.special-remote-installer` could automatically determine the trust.  
+
+I understand \"the benefit of not tying git-annex to any particular technology like docker\"; OTOH it's already tied to some particular technologies, like with the built-in S3 special remote.
+
+
+"""]]
diff --git a/doc/todo/document_git-annex_dependencies.mdwn b/doc/todo/document_git-annex_dependencies.mdwn
new file mode 100644
index 0000000000..90b98c7898
--- /dev/null
+++ b/doc/todo/document_git-annex_dependencies.mdwn
@@ -0,0 +1,3 @@
+It would help to document, in one place, the external programs and libraries on which git-annex depends for various functionalities, including optional ones.  Ones I know: curl, gpg, bup.  But there are also references in places to lsof, rsync, nocache.  For reliable packaging, it would be useful to have an authoritative list of dependencies and which functionality each supports.
+
+[[!tag unlikely]]
diff --git a/doc/todo/document_git-annex_dependencies/comment_1_bb9cbd703e57adb9ca45e2cea94308a0._comment b/doc/todo/document_git-annex_dependencies/comment_1_bb9cbd703e57adb9ca45e2cea94308a0._comment
new file mode 100644
index 0000000000..9b0e305781
--- /dev/null
+++ b/doc/todo/document_git-annex_dependencies/comment_1_bb9cbd703e57adb9ca45e2cea94308a0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-04-03T17:12:38Z"
+ content="""
+There is a comprehensive list (AFAIK) in the debian/control file's
+Depends, Recommends, and Suggests.
+
+As far as exactly where each is used, that's pretty easy to grep the code
+for (search for `"$command"`) and would be a lot of documentation to write
+and keep up to date.
+"""]]
diff --git a/doc/todo/document_git-annex_dependencies/comment_2_bcd0fa1ace9a22b0cc09cea2e7cad84c._comment b/doc/todo/document_git-annex_dependencies/comment_2_bcd0fa1ace9a22b0cc09cea2e7cad84c._comment
new file mode 100644
index 0000000000..75639b4ee5
--- /dev/null
+++ b/doc/todo/document_git-annex_dependencies/comment_2_bcd0fa1ace9a22b0cc09cea2e7cad84c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="gsasl dependency"
+ date="2020-03-11T22:13:47Z"
+ content="""
+Thanks for the `debian/control` pointer.
+
+Is `gsasl` a dependency?  Homebrew thinks it is, and it's mentioned in the forums, but I can't find uses of it in the code.
+"""]]
diff --git a/doc/todo/document_git-annex_dependencies/comment_3_ac0b1db3d447240b49686920a71ff91b._comment b/doc/todo/document_git-annex_dependencies/comment_3_ac0b1db3d447240b49686920a71ff91b._comment
new file mode 100644
index 0000000000..33262f99ad
--- /dev/null
+++ b/doc/todo/document_git-annex_dependencies/comment_3_ac0b1db3d447240b49686920a71ff91b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-05-05T16:32:06Z"
+ content="""
+gsasl was an indirect dependency of a ssl dependency, iirc it was dropped
+when xmpp support was removed although I could be mistaken.
+"""]]
diff --git a/doc/todo/document_standard_groups_more_extensively_in_the_UI.mdwn b/doc/todo/document_standard_groups_more_extensively_in_the_UI.mdwn
new file mode 100644
index 0000000000..1e9afdef90
--- /dev/null
+++ b/doc/todo/document_standard_groups_more_extensively_in_the_UI.mdwn
@@ -0,0 +1,14 @@
+i have been using git-annex for a while now, yet I still can't quite wrap my head around [[preferred_content/standard groups]], especially how they are documented in about/repogroups in the assistant web interface. i have repeatedly synced files where they shouldn't have been synced (usually by setting the repo as "client" or "transfer") and also destroyed files I wanted to keep by setting it to "unwanted" (actually, that was by pressing the "delete" button on the repo, which i didn't expect to drop the files on the remote...)
+
+i have been able to understand a lot of what's going on by trial and error and by decrypting the [[preferred_content]] expressions on the wiki.
+
+it seems to me the [[preferred_content/standard groups]] wiki page and the `about/repogroups` URL in the assistant should be merged:
+
+ 1. the assistant should be more explicit: maybe it should have examples of what will happen in some cases to give an idea. maybe "stories" like "a transfer repo is for when you have two client repos that can't talk to each other, so you use a transfer repo, e.g. a portable hard drive, to transfer files between them". having the actual, current [[preferred_content]] expressions from the [[preferred_content/standard groups]] groups page would also help, maybe in a smaller font to not scare people of
+ 2. the [[preferred_content/standard groups]] wiki page should be expanded to include narratives like the ones that are in the `about/repogroups` page of the assistant. that way people looking at the software from the outside can understand the mechanics better
+
+ideally, that documentation would be the one and the same so that a change on one side would reflect on the other.
+
+in fact, having an inline manual in the assistant would be a must: we want this thing to work offline, so it should be able to access this wiki, or whatever of it is shipped with git-annex.
+
+that way we wouldn't have this kind of inconsistencies... more generally, maybe we could even [[build a user guide]]! -- [[anarcat]]
diff --git a/doc/todo/documentation__58___improve_on_special_remotes.mdwn b/doc/todo/documentation__58___improve_on_special_remotes.mdwn
new file mode 100644
index 0000000000..703689702f
--- /dev/null
+++ b/doc/todo/documentation__58___improve_on_special_remotes.mdwn
@@ -0,0 +1,12 @@
+Even though there is a [special_remotes](https://git-annex.branchable.com/special_remotes/) page, description there is quite superficial and does not provide a good overview of various aspects on special remotes 
+
+- life cycle, e.g. how they relate to Git remotes -- that they become listed among `git remote`s whenever enabled, that git remotes get the corresponding `annex-uuid` assigned when "sensed" or get annex-ignore, how to "disable" an enabled remote (just `git remote remove`)
+- clearly list commands to operate on the special remotes (initremote, enableremote) or interrogate them (e.g. how to figure out if there is already a special remote with a target uuid but may be not enabled yet, etc)
+
+Without such a documentation it is hard to "on board" new git-annex users and developers.
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> Hard to say that documentation is ever done, but I've made some
+> improvements and I guess am going to call this [[done]] --[[Joey]]
diff --git a/doc/todo/documentation__58___improve_on_special_remotes/comment_1_edd0a4e9894d07e7bae9fef1fe4acf6d._comment b/doc/todo/documentation__58___improve_on_special_remotes/comment_1_edd0a4e9894d07e7bae9fef1fe4acf6d._comment
new file mode 100644
index 0000000000..634aaa1970
--- /dev/null
+++ b/doc/todo/documentation__58___improve_on_special_remotes/comment_1_edd0a4e9894d07e7bae9fef1fe4acf6d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-02-05T19:44:16Z"
+ content="""
+The walkthrough has enough to get a user started in the right direction
+in <https://git-annex.branchable.com/walkthrough/#index12h2>.
+
+I don't know if <https://git-annex.branchable.com/special_remotes> is a
+good entry point for a user to learn the basics of what they are. It's
+mostly a list, and I doubt most readers make it past the list.
+
+I have expanded it to mention the main commands.
+"""]]
diff --git a/doc/todo/documenting_sqlite_database_schemas.mdwn b/doc/todo/documenting_sqlite_database_schemas.mdwn
new file mode 100644
index 0000000000..9702501f5d
--- /dev/null
+++ b/doc/todo/documenting_sqlite_database_schemas.mdwn
@@ -0,0 +1,5 @@
+If a spec of the [[sqlite database schemas|todo/sqlite_database_improvements]] could be added to the [[internals]] docs, this would open some possibilities for third-party tools based on this info.  E.g. one could write some sqlite3 queries to get aggregate info on the number (and total size?) of keys present in specific combinations of repos.  It would of course be understood that this is internal info subject to frequent change.
+
+Also, if [[Sometimes the databases are used for data that has not yet been committed to git|devblog/day_607__v8_is_done]], this would improve [[future_proofing]].
+
+[[!tag needsthought unlikely]]
diff --git a/doc/todo/documenting_sqlite_database_schemas/comment_1_cc94cb2467c2b261c0b79c64853103a5._comment b/doc/todo/documenting_sqlite_database_schemas/comment_1_cc94cb2467c2b261c0b79c64853103a5._comment
new file mode 100644
index 0000000000..4003cda633
--- /dev/null
+++ b/doc/todo/documenting_sqlite_database_schemas/comment_1_cc94cb2467c2b261c0b79c64853103a5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-06T18:07:00Z"
+ content="""
+There are not any situations where after losing the sqlite databases 
+git-annex can't recover the information that was stored in them by other
+means. I know because the v8 upgrade deletes all the old sqlite databases
+and then recovers the information by other means. So no future-proofing
+impact here.
+"""]]
diff --git a/doc/todo/documenting_sqlite_database_schemas/comment_2_06bc5d625d9a3e7522c7f6df53a7ac3d._comment b/doc/todo/documenting_sqlite_database_schemas/comment_2_06bc5d625d9a3e7522c7f6df53a7ac3d._comment
new file mode 100644
index 0000000000..77b033984a
--- /dev/null
+++ b/doc/todo/documenting_sqlite_database_schemas/comment_2_06bc5d625d9a3e7522c7f6df53a7ac3d._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-01-06T18:16:13Z"
+ content="""
+It's easy enough to dump the database and see its schema.
+
+	joey@darkstar:~/lib/big>sqlite3 .git/annex/keys/db
+	sqlite> .dump
+	CREATE TABLE IF NOT EXISTS "associated"("id" INTEGER PRIMARY KEY,"key" VARCHAR NOT NULL,"file" VARCHAR NOT NULL,CONSTRAINT "key_file_index" UNIQUE ("key","file"),CONSTRAINT "file_key_index" UNIQUE ("file","key"));
+	CREATE TABLE IF NOT EXISTS "content"("id" INTEGER PRIMARY KEY,"key" VARCHAR NOT NULL,"cache" VARCHAR NOT NULL,CONSTRAINT "key_cache_index" UNIQUE ("key","cache"));
+
+Or the fully typed schema can be looked up in the haskell code
+(Database/Keys/Sql.hs)
+
+I think that how the information in the databases relates to the state of the
+repository, and how it's updated from the git-annex branch etc is just as
+important as the schema. For example, if you wanted to use this database to
+query files using a key, you'd need to know this database only gets
+populated for unlocked files not locked files. And that the database may not
+reflect recent changes to the working tree, and there's a complicated process
+that can be used to update it to reflect any recent changes.
+
+That's rather deep into the implementation details to be documenting
+outside the code.
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps.mdwn b/doc/todo/does_not_preserve_timestamps.mdwn
new file mode 100644
index 0000000000..c0b3667b03
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+I see that files are synced between my computers with git-annex but the timestamps do not match. The one that receives files always puts the current time of file creation on the file.
+
+### What steps will reproduce the problem?
+Install git-annex on two computers. Connect with XMPP. Then add cloud storage with shared encryption for transferring files. Since you want also backup, choose "full backup" as the type of cloud storage.
+
+
+### What version of git-annex are you using? On what operating system?
+Downloaded binary package dated 13/09/2014 amd64 Ubuntu 14.04.
+
+
+### Please provide any additional information below.
+
+Files are in sync. For example, I move a file from a directory to my synced annex directory. It contains timestamp of 01/01/2010 for example. Once the file gets transferred to the remote computer, it gets current time, for example 20/09/2014 rather than keeping 01/01/2010. 
+
+All computers are linux based, ext4 filesystems. File transfers are done through shared encryption rsync remote.
+
+> [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_10_8cce043ff86fefc3dcd97cf5c4428786._comment b/doc/todo/does_not_preserve_timestamps/comment_10_8cce043ff86fefc3dcd97cf5c4428786._comment
new file mode 100644
index 0000000000..7080a5877e
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_10_8cce043ff86fefc3dcd97cf5c4428786._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="vrs+annex@ea5fa24dbb279be61a8e50adb638bf8366300717"
+ nickname="vrs+annex"
+ avatar="http://cdn.libravatar.org/avatar/74219abcec6eece8e2c9d4351c2c912c"
+ subject="related bugs"
+ date="2018-03-17T19:06:46Z"
+ content="""
+I've created a number of timestamp-related bugs that will hopefully result in better timestamp support:
+
+* [annex.genmetadata should default to true](/bugs/annex.genmetadata_should_default_to_true/)
+* [file modification time should be stored in exactly one metadata field](/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/)
+* [if annex.genmetadata is true, modification metadata is imported from older file versions after unlock+add](/bugs/if_annex.genmetadata_is_true__44___modification_metadata_is_imported_from_older_file_versions_after_unlock+add/)
+* [proposal for timestamp semantics](/bugs/proposal_for_timestamp_semantics/)
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_11_eea115becce4ac79932d8cfa2903f20c._comment b/doc/todo/does_not_preserve_timestamps/comment_11_eea115becce4ac79932d8cfa2903f20c._comment
new file mode 100644
index 0000000000..6ef3a96290
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_11_eea115becce4ac79932d8cfa2903f20c._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Summary; Application: shared thumbnails"
+ date="2020-01-10T08:41:18Z"
+ content="""
+There are two conflicting approaches to mtimes:
+
+* Treat them as local artifacts
+
+  This works great with Make, and generally with any software that works on \"is newer than\" properties.
+
+* Treat them as preservation-worthy file attributes
+
+  This is generally required by tools that compare time stamps by identity.
+
+Both approaches break tools that expect the other, and no single out-of-the-box choice will make all users happy. Tools like metastore, a bespoke solution like etckeeper's generated mkdir/chmod file or a git-annex solution like [[storing the full mtime at genmetadata time|bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/]] with a (local or repository-wide) option to set the mtime at annex-get time would be convenient.
+
+One more application where this would be relevant is sharing generated thumbnails among clones of repositories (to eventually maybe even have them available when the full files are not present) following the [XDG specification on shared thumnail repositories](https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html#SHARED). Not only does that design rely on the mtimes of the thumbnail and the file to match, it even encodes the mtime again inside the thumbnail, practically requiring all checkouts to not only have consistent mtimes between thumbnails and files, but identical ones.
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_12_a8b69299c9278c16c6c5061d88bc7eca._comment b/doc/todo/does_not_preserve_timestamps/comment_12_a8b69299c9278c16c6c5061d88bc7eca._comment
new file mode 100644
index 0000000000..afe36e709a
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_12_a8b69299c9278c16c6c5061d88bc7eca._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Cebtenzzre"
+ avatar="http://cdn.libravatar.org/avatar/238202b8214db86e24636e11f4452a12"
+ subject="comment 12"
+ date="2020-11-22T16:07:15Z"
+ content="""
+The semantics described in [proposal for timestamp semantics](https://git-annex.branchable.com/bugs/proposal_for_timestamp_semantics/) would be all I need to stop wishing I just used rsync instead of git-annex. It seems easier to track history with rsync (snapshots and a CHANGELOG?) than to synchronize timestamps (or xattrs for comments) with git-annex. I don't care if it impacts performance, or if I have to set flags to non-default values, or how it resolves conflicts. I know git doesn't do it natively, but I thought the point of git-annex was to be better than native git with data files. Metadata like this is very useful to me, and often I want to sort by *some* kind of meaningful timestamp. ls can't read Exif or ID3 tags, and sometimes they aren't available or even relevant.
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_13_e37ea5188bd48817ccac82141906ee83._comment b/doc/todo/does_not_preserve_timestamps/comment_13_e37ea5188bd48817ccac82141906ee83._comment
new file mode 100644
index 0000000000..834513db0e
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_13_e37ea5188bd48817ccac82141906ee83._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="mtree can help"
+ date="2022-09-03T17:30:57Z"
+ content="""
+You can see my workaround for this using mtree at [[/forum/Use_on_large_media_collection_without_modifying_it]].
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_14_9a3f50f1b8cfd1cc0da83937a36e1369._comment b/doc/todo/does_not_preserve_timestamps/comment_14_9a3f50f1b8cfd1cc0da83937a36e1369._comment
new file mode 100644
index 0000000000..a48afdc01d
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_14_9a3f50f1b8cfd1cc0da83937a36e1369._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2022-09-20T17:55:45Z"
+ content="""
+Note that `git-annex add` does preserve the timestamp of the file
+while adding it to the annex. Much the same as a file's timestamp is
+the same after `git add` as it was before running that command.
+When `git-annex add` replaces a file with a symlink, it even makes the
+symlink's timestamp be the same as the original file.
+
+What git-annex does not do is try to store the timestamp in git and arrange
+for clones that receive the file to get the same timestamp. There are lots
+of things like this that someone *might* want git to preserve, but git
+doesn't, and it's out of scope for git-annex to try to work around git's
+limitations in these areas. Plenty of room for other tools that add
+git tracked timestamps, etc. Many such tools exist.
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_1_caf5e5cb17f4d05fff8c2fab661cd93f._comment b/doc/todo/does_not_preserve_timestamps/comment_1_caf5e5cb17f4d05fff8c2fab661cd93f._comment
new file mode 100644
index 0000000000..48ec44d2b1
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_1_caf5e5cb17f4d05fff8c2fab661cd93f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.144"
+ subject="comment 1"
+ date="2014-09-23T20:27:25Z"
+ content="""
+The closest git comes to storing a timestamp is the date of the last commit of a file for mtime, and first commit for ctime. However, those are pretty expensive to look up for a given file. And git doesn't try to preserve timestamps in checkouts at all, which argues that git-annex, at least at the command line, should not either.
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_2_c337fca1474b5b78f61ad6f421138ae4._comment b/doc/todo/does_not_preserve_timestamps/comment_2_c337fca1474b5b78f61ad6f421138ae4._comment
new file mode 100644
index 0000000000..4b5a750cf2
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_2_c337fca1474b5b78f61ad6f421138ae4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="comment 2"
+ date="2014-09-23T20:58:10Z"
+ content="""
+Thanks Joey for the comment. 
+
+But when syncing two repos, timestamps are critical at least for my use case. I can't lose this info. Even if it's expensive. 
+
+Appreciate if you can consider to add it for direct mode repos, ie when a file is synced to another repo and created there, it shall carry at least the mtime of the file in source repo. Owncloud sync does it, btsync does it, although I know git-annex is different than those. 
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_3_9a3eeddc46e5a420575f00cb47caf703._comment b/doc/todo/does_not_preserve_timestamps/comment_3_9a3eeddc46e5a420575f00cb47caf703._comment
new file mode 100644
index 0000000000..ba34823d45
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_3_9a3eeddc46e5a420575f00cb47caf703._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="comment 3"
+ date="2014-09-23T21:15:29Z"
+ content="""
+Btw, git storing the last commit time as Mtime is not enough, it shall store the original timestamp of the file, not the date of commit. Hope I could explain and hope this is something doable.
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_4_99b064259fc2e3c6eb83c3da3b2d3bac._comment b/doc/todo/does_not_preserve_timestamps/comment_4_99b064259fc2e3c6eb83c3da3b2d3bac._comment
new file mode 100644
index 0000000000..08de756190
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_4_99b064259fc2e3c6eb83c3da3b2d3bac._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 4"
+ date="2014-09-24T07:15:09Z"
+ content="""
+You can try to store the timestamps just before commit and restore them on checkout.
+
+Have a look at [metastore](https://github.com/przemoc/metastore): it is a ready-made solution for plain git. Maybe you can adapt it to git-annex.
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_5_c95c8b9bd617830604500213c962fc7a._comment b/doc/todo/does_not_preserve_timestamps/comment_5_c95c8b9bd617830604500213c962fc7a._comment
new file mode 100644
index 0000000000..7632548cdf
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_5_c95c8b9bd617830604500213c962fc7a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlM_DRhi_5pJrTA0HbApHR25iAgy-NBXTY"
+ nickname="Tor Arne"
+ subject="comment 5"
+ date="2014-10-01T22:02:43Z"
+ content="""
+I was just about to start using git-annex for my data when I saw this bug report, which unfortunately is a blocker. Persisting basic metadata of files that are synced seems like a core feature of a file sync/transfer tool, so I'm really hoping this can be solved somehow :/
+
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_6_b99e00d0bc4258c4cb28b544b19ea3b8._comment b/doc/todo/does_not_preserve_timestamps/comment_6_b99e00d0bc4258c4cb28b544b19ea3b8._comment
new file mode 100644
index 0000000000..67fe255950
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_6_b99e00d0bc4258c4cb28b544b19ea3b8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlM_DRhi_5pJrTA0HbApHR25iAgy-NBXTY"
+ nickname="Tor Arne"
+ subject="comment 6"
+ date="2014-10-01T22:39:01Z"
+ content="""
+Isn't this what the metadata feature does though? http://git-annex.branchable.com/design/metadata/
+
+With annex.genmetadata true set, it should store year and mont (but not day/time? if so why not?
+
+Is the missing piece of the puzzle to apply the metadata again on checkout?
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_7_eefa6afce824f1069bb5216b392405b7._comment b/doc/todo/does_not_preserve_timestamps/comment_7_eefa6afce824f1069bb5216b392405b7._comment
new file mode 100644
index 0000000000..19c508c508
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_7_eefa6afce824f1069bb5216b392405b7._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="fastguy"
+ subject="Any updates?"
+ date="2015-09-25T19:35:18Z"
+ content="""
+Hi, would there be any updates on this issue or do we still not preserve timestamps when syncing between locations?
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_8_f2a32e39356f7b772ab9cf3136436700._comment b/doc/todo/does_not_preserve_timestamps/comment_8_f2a32e39356f7b772ab9cf3136436700._comment
new file mode 100644
index 0000000000..6085171f25
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_8_f2a32e39356f7b772ab9cf3136436700._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="graboluk@f6de53961ab0f884e203f602f65eb5cdc0fb7513"
+ nickname="graboluk"
+ subject="timestamps are wrong as of 5.20150731"
+ date="2015-09-26T18:31:46Z"
+ content="""
+I confirm this issue is still present in the debian testing version 5.20150731. This really makes git-annex quite unusable for me, as part of my setup is that my server downloads various podcasts (think news videos from euronews, german tagesschau, some youtube podcasts), which then get distributed to my other computers. This way I don't have to use youtube etc., which makes a huge difference in terms of speed (my main home  computer is from 2006 and it plays all hte videos just fine, but a website likie youtube.com is too much for it). At a speed of single shortcut I see a list of newest podcasts and I can choose one without bothering to open the webbrowser.
+
+The point is that I really like to have all those podcasts to be sorted by their modified date, for rather obvious reasons. (with dropbox it works fine.) 
+"""]]
diff --git a/doc/todo/does_not_preserve_timestamps/comment_9_62736ee2f299d62f685800353fc36ccf._comment b/doc/todo/does_not_preserve_timestamps/comment_9_62736ee2f299d62f685800353fc36ccf._comment
new file mode 100644
index 0000000000..ed9c0e41ea
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_9_62736ee2f299d62f685800353fc36ccf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kalle@bdf75651b439b088e51f28f10f5a46ffcd2a704d"
+ nickname="kalle"
+ subject="importfeed template"
+ date="2015-09-28T19:52:16Z"
+ content="""
+You can use the `--template` flag and prefix the filename with the date. See [[/tips/downloading_podcasts]]. If you need very accurate modification times that won't work but should work in this case?
+"""]]
diff --git a/doc/todo/done.mdwn b/doc/todo/done.mdwn
new file mode 100644
index 0000000000..2ab037cfbd
--- /dev/null
+++ b/doc/todo/done.mdwn
@@ -0,0 +1,4 @@
+recently fixed [[todo]] items.
+
+[[!inline pages="./* and link(./done) and !*/Discussion" sort=mtime show=0
+archive=yes feedlimit=10]]
diff --git a/doc/todo/drop_--batch.mdwn b/doc/todo/drop_--batch.mdwn
new file mode 100644
index 0000000000..b00f7673c9
--- /dev/null
+++ b/doc/todo/drop_--batch.mdwn
@@ -0,0 +1,7 @@
+There is a dropkey --batch, so I guess I could workaround but probably would be nice for consistency to have --batch mode for drop itself as well
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]]; went ahead and added drop --batch to be symmetric with get
+> --batch. --[[Joey]]
diff --git a/doc/todo/drop_from_export_remote.mdwn b/doc/todo/drop_from_export_remote.mdwn
new file mode 100644
index 0000000000..2783428ee9
--- /dev/null
+++ b/doc/todo/drop_from_export_remote.mdwn
@@ -0,0 +1,32 @@
+It should be possible for this to work:
+
+	joey@darkstar:~/tmp/bench3/a>git annex move x --from d
+	move x (from d...)
+	  dropping content from an export is not supported; use `git annex export` to export a tree that lacks the files you want to remove
+	failed
+
+git-annex could just alter the tree exported to the remote to remove the file.
+It might be a little slow to do that for a lot of files, and it would create
+some unattached tree objects that would linger until gc. 
+
+A simple optimisation would be to remove the file (with removeExport) but not update the
+export tree for one file. Keep a log of removed files, and at the end of the command,
+or some future point where the export tree is used, update the export tree to remove the
+files from it.
+
+This seems like a prerequisite for [[remove_legacy_import_directory_interface]] because
+`git-annex import --deduplicate` and `--clean-duplicates` need to remove individual files
+from the remote.
+
+> Note that doing this with an importtree=yes remote would 
+> result, after import, in the remote tracking branch having the file
+> deleted. That could be surprising when merged, since it would delete
+> the file from master!
+> 
+> I think this problem can be avoided by rewriting the remote tracking
+> branch's previous commit to not include the file that got deleted. Then
+> merging would need --allow-unrelated-histories, but would not cause the
+> file to be deleted from master.
+
+[[!tag confirmed]]
+[[!tag projects/datalad/potential]]
diff --git a/doc/todo/dynamic_stall_detection.mdwn b/doc/todo/dynamic_stall_detection.mdwn
new file mode 100644
index 0000000000..a7db6ae90f
--- /dev/null
+++ b/doc/todo/dynamic_stall_detection.mdwn
@@ -0,0 +1,24 @@
+annex.stalldetection lets remotes be configured with a minimum throughput
+to detect and retry stalls. But most users are not going to configure this. 
+Could something be done to dynamically detect a stall, without configuration?
+
+Eg, wait until data starts to flow, and then check if there's at least some
+data being sent each half minute. If so, the progress display is being updated
+at least every minute. So then if 1 minute goes by without more data
+flowing, it's almost certainly stalled. And if the progress display is
+updated less frequently, see if it's updated every 2 minutes, etc. Although
+realistically, progress displays are updated every chunk, and there's
+typically more than 1 chunk per minute. So longer durations than 1 minute
+may be an unnecessary complication. And a minute to detect a stall is fine.
+
+> Implemented this, annex.stalldetection = true enables automatic.
+
+It may still need a config to turn it on, because running
+transfers in separate processes can lead to more resource use, or even
+password prompting, which could be annoying to existing users. Also, if it
+gets it wrong and the remote does not support resuming transfers,
+defaulting to on could lead to bad waste of resources. It could
+detect stalls even when not turned on, but only display a message
+suggesting enabling the config. --[[Joey]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/enable_a_discussion_forum_or_support_system.mdwn b/doc/todo/enable_a_discussion_forum_or_support_system.mdwn
new file mode 100644
index 0000000000..ba057ea384
--- /dev/null
+++ b/doc/todo/enable_a_discussion_forum_or_support_system.mdwn
@@ -0,0 +1,134 @@
+I has been [[discussed|devblog/day_268_stressed_out]]
+[[twice|devblog/day_285__tuning_git-annex_unused_refs]] that the
+current [[forum]] support system is not ideal for providing
+support. It constitutes the [largest part of this wiki][] yet we
+sometimes get duplicated questions and it seems the forum may be a
+barrier to entry for people.
+
+ [largest part of this wiki]: http://git-annex.branchable.com/devblog/day_268_stressed_out/#comment-e0814585df0047e6d4e11515aebe1dec
+
+A few alternatives have been proposed, from a mailing list to using a
+StackExchange site. This post is to discuss the possible
+alternatives. The requirement is that the system may be available
+offline and on low-bandwidth connections yet enable conversations
+better than a simple web forum or mailing list; which may end up being
+the only solution considering the first requirements, but let's give
+it a try. :)
+
+[[!toc]]
+
+Stack exchange
+==============
+
+i looked up how this works in stackexchange, and it turns out they
+provide [regular dumps][] of the data hosted. unfortunately, it's a
+gigantic zip file and not really designed for low-bandwidth
+use. There's also a [data explorer][] that was promising, until i
+realized that the query engine takes up 154KB, three times the space
+of the regular search engine (~54KB, which I guess is way too much for
+dialup).
+
+ [regular dumps]: http://blog.stackoverflow.com/category/cc-wiki-dump/
+ [data explorer]: http://data.stackexchange.com/
+
+Also: there is a [mobile version][] of all the stackexchange sites,
+which take up around 3KB, but still only works online. There's an app
+for mobile devices as well, but it [doesn't support offline access
+either][] - so another dead-end.
+
+ [mobile version]: http://meta.stackexchange.com/questions/104458/switch-to-mobile-site-on-standard-browser
+ [doesn't support offline access either]: http://meta.stackexchange.com/questions/220036/offline-features-in-stack-exchange-app
+
+Stackexchange runs a [garbled mess][] of IIS, MSSQL, ASP, Redis and
+Elasticsearch so there is probably little hope in integrating into
+something like git. I have asked for the [proverbial pony in this
+stackexchange question][] (yes, it's all very meta), describing the
+use case, but i am not holding my breath for a change.
+
+ [garbled mess]: http://en.wikipedia.org/wiki/Stack_Exchange#Technologies_used
+ [proverbial pony in this stackexchange question]: http://meta.stackexchange.com/questions/256573/best-way-to-use-stackexchange-sites-offline-or-on-dialup
+ 
+Askbot
+======
+
+Besides, SE sites are based on proprietary software, and i am not sure
+we'd want to advocate that here. There are free software alternatives,
+of which i made an [evaluation about 2 years ago][] after which we
+tried Askbot at [Koumbit][]. it never took off: staff didn't seem
+interested in it so much and we never made people aware of it too
+much. plus, it didn't integrate with existing authentication
+mechanisms (which are a little bit of a mess for us)...
+
+But it does seem like an interesting alternative, and has [primitive
+email integration][] where you can ask questions by email, but not
+answer (!). I haven't looked at such support in other software, but i
+suspect it is similarly not a priority as they struggle to monetize
+their free software...
+
+Most of those free software alternatives of Stackexchange are written
+in Python/Django or Ruby/Rails (iirc) with SQL backends, which would
+probably make git integration... also "challenging".
+
+ [evaluation about 2 years ago]: (https://wiki.koumbit.net/FaqService#A.2BAMk-valuation_logicielle)
+ [Koumbit]: http://koumbit.org/
+ [primitive email integration]: http://askbot.org/doc/sending-email-to-askbot.html
+
+Discourse
+=========
+
+From that point of view, maybe [discourse][] could be an interesting
+alternative. It has built-in email support, as it is designed as an
+alternative to mailing lists. With a simple setting, you can
+collaborate directly by email. What is interesting, compared to the
+mailing list model, is that posts can be collaboratively edited to
+(for example) arrive at a collective wisdom by refining an answer (or
+a question). There are also interesting community moderation and
+reputation systems.
+
+There seems to be some [offline tool][] for Discourse, but it's
+unclear to me how it works, as it seems to be a separate (nodejs!)
+application that connects with a discourse plugin. There's a
+[discussion about offline suport in discourse][] in the meta site...
+
+Discourse uses Ruby/Rails and PostgreSQL, and somewhat is only
+[officially supported in Docker][]...
+
+The discourse people do [warn against switching existing
+communities][] to Discourse because of the resulting friction, so it
+is also in that spirit that I open discussion about this here, that
+is, in the hope the change can be acknowledged, supported and
+discussed by everyone here, in a spirit of consensus building. :)
+
+ [offline tool]: https://github.com/etewiah/offcourse
+ [discussion about offline suport in discourse]: https://meta.discourse.org/t/offcourse-a-proof-of-concept-offline-reader-for-discourse/22356
+ [discourse]: http://discourse.org/
+ [warn against switching existing communities]: http://www.discourse.org/faq/#switch
+ [officially supported in Docker]: https://github.com/discourse/discourse/blob/master/docs/INSTALL.md
+
+Mailing lists
+=============
+
+Of course, the forum could simply be moved to a mailing list. The
+would have the advantage of reducing the barrier of entry to the site,
+reduce the load on the wiki, at the cost of adding the additionnal
+"how do i subscribe to a mailing list" barrier of entry, which, oddly
+enough, exists for a lot of mailing lists...
+
+Like it or not, web forums do enable a lot of less technical users to
+participate because they only need their web browser, and crossing
+that boundary can be hard for some people. Mailing lists also do not
+necessarily favor collaboration as much as the other systems, because
+they are articulated more towards discussion, as opposed to establishing
+common knowledge.
+
+A good option may be Mailman 3 which, with the new web interface, allows
+forum-like functionalities. Mailman 2 also used to have a usenet interface,
+not sure what became of that in Mailman 3.
+
+Web forums
+==========
+
+There's a plethora of "php-bb-like" software out there, i am just
+ignoring them for now, as I am not very familiar with them and they
+have never been too attractive for me, but people are of course free
+to edit this page to add suggestions! :)
diff --git a/doc/todo/enable_a_discussion_forum_or_support_system/comment_1_578c0ab40d53dd56bb3f2d98491c5e85._comment b/doc/todo/enable_a_discussion_forum_or_support_system/comment_1_578c0ab40d53dd56bb3f2d98491c5e85._comment
new file mode 100644
index 0000000000..4b57009bc2
--- /dev/null
+++ b/doc/todo/enable_a_discussion_forum_or_support_system/comment_1_578c0ab40d53dd56bb3f2d98491c5e85._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-19T21:32:58Z"
+ content="""
+Of these, only Discourse seems interesting to me. (Or email list.)
+As long as it supports responding by email, it would work for me, and
+collaboratively editing is a good thing. Of course, we try to do that on
+the tips pages already..
+
+Note that as of today, users can log into this website using
+just their email address.
+"""]]
diff --git a/doc/todo/enable_a_discussion_forum_or_support_system/comment_2_b1129b4cdfe39e740c4f7cf0d6ff2b91._comment b/doc/todo/enable_a_discussion_forum_or_support_system/comment_2_b1129b4cdfe39e740c4f7cf0d6ff2b91._comment
new file mode 100644
index 0000000000..c0252718bb
--- /dev/null
+++ b/doc/todo/enable_a_discussion_forum_or_support_system/comment_2_b1129b4cdfe39e740c4f7cf0d6ff2b91._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-05-22T17:26:08Z"
+ content="""
+I think that mailman 3 could be a good solution for lots of different
+users.
+
+It is emphatically not the kind of thing I enjoy maintaining though! :)
+
+Example: <https://lists.stg.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/>
+"""]]
diff --git a/doc/todo/enable_a_discussion_forum_or_support_system/comment_3_52598af3d7b050981e32ad1569f69db9._comment b/doc/todo/enable_a_discussion_forum_or_support_system/comment_3_52598af3d7b050981e32ad1569f69db9._comment
new file mode 100644
index 0000000000..263753ba7d
--- /dev/null
+++ b/doc/todo/enable_a_discussion_forum_or_support_system/comment_3_52598af3d7b050981e32ad1569f69db9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-06-02T17:22:49Z"
+ content="""
+FWIW, now that logging in by email address is supported, I've seen traffic
+to this website tick back up. 
+"""]]
diff --git a/doc/todo/encrypt_only_the_credentials.mdwn b/doc/todo/encrypt_only_the_credentials.mdwn
new file mode 100644
index 0000000000..d510f45002
--- /dev/null
+++ b/doc/todo/encrypt_only_the_credentials.mdwn
@@ -0,0 +1,3 @@
+Is it possible to add an option, for initremote/enableremote, to encrypt the credentials but not the contents?  Then it would be possible to have an exporttree remote while using embedcreds.  It would also be good if locally stored credentials could be stored in encrypted form, and decrypted for use as needed.  I'm uneasy about keeping credentials accessible without a passphrase.
+
+[[!tag confirmed]]
diff --git a/doc/todo/encrypt_only_the_credentials/comment_1_7c3911e8fbc981c7e1f32b1464ce4122._comment b/doc/todo/encrypt_only_the_credentials/comment_1_7c3911e8fbc981c7e1f32b1464ce4122._comment
new file mode 100644
index 0000000000..cd11a687c2
--- /dev/null
+++ b/doc/todo/encrypt_only_the_credentials/comment_1_7c3911e8fbc981c7e1f32b1464ce4122._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-04T17:18:19Z"
+ content="""
+I agree it would make sense to have some way to embedcreds without
+encrypting content stored on the remote.
+
+I suppose one way to express it is as encryption=onlycreds embedcreds=yes
+with one or more keyids.
+
+Note that the tahoe special remote supports embedcreds,
+but disallows setting any encryption (because tahoe handles that)
+so the creds can only be stored in the clear currently. It would make sense for
+tahoe to support encryption=onlycreds while disallowing other encryption
+methods.
+
+----
+
+As for storing creds locally only in encrypted form, it would suffice to
+have an option that makes git-annex not write anything to
+.git/annex/creds/, so it would not use those files as a cache, and would
+pull the creds out of the repository and decrypt each time needed
+(or use environment varibles for creds when applicable.) In some cases
+that would cause more gpg prompts. I think that S3 and WebDAV special
+remotes only call getRemoteCredPair once per run, but external may
+call it repeatedly, and glacier calls it once per request.
+
+Implemented as annex.cachecreds.
+"""]]
diff --git a/doc/todo/encrypt_only_the_credentials/comment_2_76fdfa927562d33dfea9630b3b729220._comment b/doc/todo/encrypt_only_the_credentials/comment_2_76fdfa927562d33dfea9630b3b729220._comment
new file mode 100644
index 0000000000..2a8d87bb3c
--- /dev/null
+++ b/doc/todo/encrypt_only_the_credentials/comment_2_76fdfa927562d33dfea9630b3b729220._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2018-12-04T18:40:01Z"
+ content="""
+thanks!  \"that would cause more gpg prompts\" -- wouldn't gpg-agent prevent that?
+"""]]
diff --git a/doc/todo/encrypt_only_the_credentials/comment_3_6f0ba120ef655d5250fdf3db53464fe6._comment b/doc/todo/encrypt_only_the_credentials/comment_3_6f0ba120ef655d5250fdf3db53464fe6._comment
new file mode 100644
index 0000000000..bed73a5f75
--- /dev/null
+++ b/doc/todo/encrypt_only_the_credentials/comment_3_6f0ba120ef655d5250fdf3db53464fe6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-12-04T19:20:11Z"
+ content="""
+Yes, gpg-agent is why I'm not stressing the potential extra gpg use by that
+setting.
+"""]]
diff --git a/doc/todo/encrypted_keys_in_git_repository.mdwn b/doc/todo/encrypted_keys_in_git_repository.mdwn
new file mode 100644
index 0000000000..38dd27ddcc
--- /dev/null
+++ b/doc/todo/encrypted_keys_in_git_repository.mdwn
@@ -0,0 +1,61 @@
+The idea is to have a type of key that is based on a hash of the annexed
+file, but with some form of encryption or password protection. 
+
+So someone who can access the git repository is prevented from checking
+known hashes of files, and learning about content in the repository that is
+not available to them. (However, they would be able to see filenames
+and commit metadata, which might also expose information about what the
+files are. This is not a fully encrypted git repository like can be made
+with gcrypt.)
+
+This might be an added layer of security, or the git repository might be
+made public, including perhaps some of the annexed files, while this is
+used to obscure the hashes of some other annexed files. For example, a
+scientific dataset might make public files that are derived from patient
+data, and use this for the patient data files.
+
+----
+
+If two such repositories were merged, git-annex would need to somehow
+be able to tell how to decrypt a key, which could have come from either
+repository. So it seems that the key needs to include within it some
+identifier of the secret that is used to encrypt it. For example:
+
+    ENC--ident--foo
+
+Where ident would be something like a UUID of the secret, and foo is the
+file's hash (and perhaps size, or indeed a whole regular key) that is
+encrypted by the secret.
+
+----
+
+Should the key's size be included only in encrypted form, or in plaintext?
+
+Since git-annex constructs a Key without using the associated Backend,
+it currently parses the size field the same way for each type of key.
+So, it does not seem to be possible to encrypt the size field and 
+use that encrypted size to populate keySize. What would be
+doable though, is to replace uses of keySize with a new Backend method that
+returns the size.
+
+----
+
+Should the encryption method be reversible?
+
+If the encryption method is not reversible, the key's size would need to be
+included in plaintext, or left out entirely.
+
+But it does not seem necessary for the encryption method to be reversible
+otherwise. Consider if scrypt was used. When adding a file, git-annex would
+first hash it, and then run it through scrypt. That is not reversible,
+so when fscking a file, just repeat the same process and compare the
+resulting scrypt keys.
+
+Not being reversible is a nice benefit, because it makes it much harder
+for an attacker to brute-force. If it's reversible the attacker can
+brute-force the user's password, looking for a password that decrypts
+to something that looks right.
+
+--[[Joey]]
+
+> [[wontfix|done]]; see description --[[Joey]]
diff --git a/doc/todo/encrypted_keys_in_git_repository/comment_1_4d17c427756127f22dc472984259f8d7._comment b/doc/todo/encrypted_keys_in_git_repository/comment_1_4d17c427756127f22dc472984259f8d7._comment
new file mode 100644
index 0000000000..58c4f3366d
--- /dev/null
+++ b/doc/todo/encrypted_keys_in_git_repository/comment_1_4d17c427756127f22dc472984259f8d7._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Maybe add a very slow KDF first?"
+ date="2022-12-27T20:26:45Z"
+ content="""
+Hey joey,
+
+As a simple-to-implement yet quite effective approach to the problem of storing some secrets in a public git-annex repo, wouldn't a very slow hash/key derivation function (like scrypt) as keys for those specific files be enough? The hash can be public when brute-forcing is infeasible. So for git-annex:
+
+- add an scrypt key backend
+- makes the params n,r,p configurable (slowness of hashing) and put them i to the key name (e.g. `SCRYPT-n10-r100-p1--...`)
+- the salt could also be configurable or generated randomly per file but needs to be present in the key name (base64-encoded?) and uses either the file content or as such or some cryptographically secure hash of it as scrypt 'password'
+- file size shouldn't be included in the key
+
+With sane defaults (maybe settings that make hashing take several seconds?), this would make git-annex a very nice way of hiding some files' content in public repositories while still tracking it.
+
+Some resources:
+
+- https://stackoverflow.com/questions/23985540/whats-the-is-maximum-length-of-scrypt-output#23985541
+- https://words.filippo.io/the-scrypt-parameters/
+
+"""]]
diff --git a/doc/todo/encrypted_keys_in_git_repository/comment_2_6679caba100bee0a0fe32c8eef50758e._comment b/doc/todo/encrypted_keys_in_git_repository/comment_2_6679caba100bee0a0fe32c8eef50758e._comment
new file mode 100644
index 0000000000..6bc238b1f6
--- /dev/null
+++ b/doc/todo/encrypted_keys_in_git_repository/comment_2_6679caba100bee0a0fe32c8eef50758e._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-12-27T20:43:35Z"
+ content="""
+Including the salt in the key is an interesting idea. I am not sure I buy
+that it would be secure.
+
+Normally with scrypt (or argon2 etc), and a strong password, the attacker has
+to make a huge number of guesses, and so the comparatively modest amount of
+work per guess is enough to make it infeasible for them to succeed.
+
+Here though, the attacker will only be interested in guessing the hashes of
+known files that they care about. That might be millions of files and so be
+a reasonable amount of work to try them all. Probably less work than a good
+password, so the hash difficulty parameters would need to be turned up to
+secure against that attacker.
+
+But... If the attacker only cares about a single file, they only have to run
+scrypt once.
+"""]]
diff --git a/doc/todo/encrypted_keys_in_git_repository/comment_3_a79ea55e2f8a1095f0110f2f0853dee1._comment b/doc/todo/encrypted_keys_in_git_repository/comment_3_a79ea55e2f8a1095f0110f2f0853dee1._comment
new file mode 100644
index 0000000000..2455fcf1b0
--- /dev/null
+++ b/doc/todo/encrypted_keys_in_git_repository/comment_3_a79ea55e2f8a1095f0110f2f0853dee1._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 3"
+ date="2022-12-29T10:49:27Z"
+ content="""
+> But... If the attacker only cares about a single file, they only have to run scrypt **once.**
+
+Well, the attacker would still need to run scrypt many times to brute-force the actual content, IIUC.
+
+I understand it like this (might be wrong, I'm no security expert):
+
+- scrypt is an arbitrarily-slow key derivation function taking an input (the „password” - or for us: the file content) and some parameters (salt, n, r, p)
+- knowing the parameters (salt, n, r, p) is necessary to verify file integrity so storing those in an easily accessible way (e.g. directly in the key) would simplify things and we wouldn't need to teach git-annex much more to handle this.
+- A (public) git-annex repo that has some files „scrypt”-ed like this then contains the scrypt hash and the parameters used to generate that hash. So this is equivalent to a database breach where user credentials were secured with scrypt. (right?)
+- An attacker thus now still has to brute-force the content of the desired file. With little information about how that file looks in detail („how exactly is that YAML containing the password structured? How big is it even? What key order? Are there comments? That comment could even contain a random salt itself...”), this brute-forcing should be pretty infeasible if the scrypt parameters are tuned to hash *ridiculously* slow (like multiple seconds even on a beefy machine with much RAM - doesn't bother us if `git annex fsck` is slow on that one file. Big files hash slowly anyway as well...). It should definitely be harder than cracking a breached password database where it is clear that the passwords don't contain newlines and there most likely is a size limit, etc.
+
+If my above assumptions are correct, an `scrypt` key backend for git-annex should make for a nice way of hiding the content of *some* files in a public repo, right?
+
+P.S: Thinking about the 'that secured file could contain potentially large random comments acting as a salt next to the actual secret' together with removing the size from the key ([`git annex migrate --remove-size`](https://git-annex.branchable.com/git-annex-migrate/)) should already be pretty safe with the default SHA256-backend, right? 🤔
+"""]]
diff --git a/doc/todo/encrypted_keys_in_git_repository/comment_4_e88664a0939b7bca730a61efb47d34ab._comment b/doc/todo/encrypted_keys_in_git_repository/comment_4_e88664a0939b7bca730a61efb47d34ab._comment
new file mode 100644
index 0000000000..df0611bf0f
--- /dev/null
+++ b/doc/todo/encrypted_keys_in_git_repository/comment_4_e88664a0939b7bca730a61efb47d34ab._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-01-02T19:03:34Z"
+ content="""
+I'm talking about a single file that the attacker already knows the content
+of, and wishes to determine if it's present in the repository. That takes a
+single scrypt operation, so scrypt's added difficulty is not relevant.
+
+If the attacker doesn't know the file content, and is trying to hash random
+values until they find one that matches the git-annex key, then a sha2 is
+equally good protection as scrypt, because the amount of work is
+computationally infeasible in both cases.
+"""]]
diff --git a/doc/todo/encrypted_keys_in_git_repository/comment_5_05b0e2e88b233691b403d4c908b50c52._comment b/doc/todo/encrypted_keys_in_git_repository/comment_5_05b0e2e88b233691b403d4c908b50c52._comment
new file mode 100644
index 0000000000..d0b388b8f1
--- /dev/null
+++ b/doc/todo/encrypted_keys_in_git_repository/comment_5_05b0e2e88b233691b403d4c908b50c52._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 5"
+ date="2023-01-02T22:58:08Z"
+ content="""
+> I'm talking about a single file that the attacker already knows the content of, and wishes to determine if it's present in the repository. 
+
+Ah alright, in that case scrypt doesn't help, I agree. Among the large userbase for such a versatile software as git-annex there surely are people that could make use of hiding the presence of some 'common' files from their public repos. Though it rather seems like quite an edge case to me 😅 Better go full-gcrypt in that case I'd say...
+
+> sha2 is equally good protection as scrypt
+
+In that case, this'll be enough for my application, thanks! 🙏
+"""]]
diff --git a/doc/todo/encrypted_keys_in_git_repository/comment_6_9e25b4d05d61fc3a3cca4f7111681a5f._comment b/doc/todo/encrypted_keys_in_git_repository/comment_6_9e25b4d05d61fc3a3cca4f7111681a5f._comment
new file mode 100644
index 0000000000..59c3692e7a
--- /dev/null
+++ b/doc/todo/encrypted_keys_in_git_repository/comment_6_9e25b4d05d61fc3a3cca4f7111681a5f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2023-01-16T18:39:38Z"
+ content="""
+Ok, I think we've concluded there is nothing to do here! I'll close this
+todo then.
+"""]]
diff --git a/doc/todo/encrypting_URLs.mdwn b/doc/todo/encrypting_URLs.mdwn
new file mode 100644
index 0000000000..ec295c3ecf
--- /dev/null
+++ b/doc/todo/encrypting_URLs.mdwn
@@ -0,0 +1,10 @@
+When recording a URL from which a key may be fetched, add an option to store that URL in encrypted form (encrypted to a given public key).
+E.g. record the URL as encryptedurl://key_id/[base64-encoded encryption of the original URL].
+
+Many cloud services let you create a pre-signed URL for a non-public file.  Anyone with the URL can get the file, so the URL is "public" in that sense;
+but you only share the URL with intended recipient(s), not the public.  Or you might store files in a bucket that can be publicly read but not listed, and
+store files under paths like s3://mybucket/randomstring/myfile ; the URL is "public" but in practice it can't be guessed.
+If the URLs could be stored encrypted in the git-annex branch, one could track such files using the ordinary web remote.  One could use an S3 export-tree
+remote to share a directory with specific recipient(s), without them needing either AWS credentials or git-annex.
+
+[[!tag unlikely moreinfo]]
diff --git a/doc/todo/encrypting_URLs/comment_1_9d0dda82d1f3907e6478a95608388836._comment b/doc/todo/encrypting_URLs/comment_1_9d0dda82d1f3907e6478a95608388836._comment
new file mode 100644
index 0000000000..d86408df35
--- /dev/null
+++ b/doc/todo/encrypting_URLs/comment_1_9d0dda82d1f3907e6478a95608388836._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-30T18:25:58Z"
+ content="""
+Is this about SETURLPRESENT in an external special remote, or is addurl
+also supposed to enctypt an url? And how would addurl know if the user
+wants to encrypt it, and using what gpg keys?
+
+If your git-annex repo contains information about files you want to remain
+private, why not just keep that repo private?
+"""]]
diff --git a/doc/todo/explicit_metadata_needed_for_view_inclusion_or_not.mdwn b/doc/todo/explicit_metadata_needed_for_view_inclusion_or_not.mdwn
new file mode 100644
index 0000000000..6ec6332a4a
--- /dev/null
+++ b/doc/todo/explicit_metadata_needed_for_view_inclusion_or_not.mdwn
@@ -0,0 +1,116 @@
+I'm not sure if this is a bug or a feature but the question is should files have (some/any)
+explicit metadata set with `git-annex metadata` for them to be included in a view branch?
+I mean if you create a view with just path-based fields (say, restrict to a subdirectory
+with a criterion like 'subdir/=*'), do you expect files to match even if they don't have
+any metadata fields manually set? In release version 10.20230214 the behavior has changed
+in that files that don't have manual metadata set don't seem to be included in 
+(directory-based) view branches. The inverse seems to be true of the unreleased version
+10.20230127-gc209e0f64 committed a week before.
+
+In my opinion, this *could* be a feature if it's documented but it could also be construed
+as violating the principle of least surprise as not all users routinely tag all annexed files
+with metadata.
+
+The following is a transcript that illustrates how the recent release version behaves. See
+how the file `subdir/c` is excluded from the view branch (my apologies for this being a
+PowerShell session on Windows):
+
+[[!format sh """
+X:\> cd git-annex-tests
+X:\git-annex-tests> git init annex-view-test-a
+X:\git-annex-tests> cd .\annex-view-test-a\
+X:\git-annex-tests\annex-view-test-a [master]> git config annex.thin true
+X:\git-annex-tests\annex-view-test-a [master]> git annex init Annex-view-test-a
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked)]> echo Aaa > a
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +1 ~0 -0 !]> mkdir subdir
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +1 ~0 -0 !]> echo Bbb > subdir\b
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +2 ~0 -0 !]> echo Ccc > subdir\c
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +2 ~0 -0 !]> mkdir subdir\subsubdir
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +2 ~0 -0 !]> echo Ddd > .\subdir\subsubdir\d
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +2 ~0 -0 !]> git annex add .
+add a
+ok
+add subdir/b
+ok
+add subdir/c
+ok
+add subdir/subsubdir/d
+ok
+(recording state in git...)
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +4 ~0 -0 ~]> ls -r
+
+    Directory: X:\git-annex-tests\annex-view-test-a
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+d----           15.2.2023    12:37                subdir
+-a---           15.2.2023    12:31              5 a
+
+    Directory: X:\git-annex-tests\annex-view-test-a\subdir
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+d----           15.2.2023    12:38                subsubdir
+-a---           15.2.2023    12:34              5 b
+-a---           15.2.2023    12:37              5 c
+
+    Directory: X:\git-annex-tests\annex-view-test-a\subdir\subsubdir
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           15.2.2023    12:38              5 d
+
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +4 ~0 -0 ~]> fsutil hardlink list a
+\git-annex-tests\annex-view-test-a\.git\annex\objects\b29\a20\SHA256E-s5--e3c555b2205407e76d3a460513cf44c1c62e48ba83ec4948ed05d0f87b957051\SHA256E-s5--e3c555b2205407e76d3a460513cf44c1c62e48ba83ec4948ed05d0f87b957051
+\git-annex-tests\annex-view-test-a\a
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked) +4 ~0 -0 ~]> git commit -m 'Add test files'
+[adjusted/master(unlocked) 56b11c9] Add test files
+ 4 files changed, 4 insertions(+)
+ create mode 100644 a
+ create mode 100644 subdir/b
+ create mode 100644 subdir/c
+ create mode 100644 subdir/subsubdir/d
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked)]> git annex metadata -t test subdir\b
+metadata subdir/b
+  lastchanged=2023-02-15@10-52-31
+  tag=test
+  tag-lastchanged=2023-02-15@10-52-31
+ok
+(recording state in git...)
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked)]> git annex metadata -t test subdir\subsubdir\d
+metadata subdir/subsubdir/d
+  lastchanged=2023-02-15@10-53-00
+  tag=test
+  tag-lastchanged=2023-02-15@10-53-00
+ok
+(recording state in git...)
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked)]> git annex metadata subdir\c
+metadata subdir/c
+
+ok
+X:\git-annex-tests\annex-view-test-a [adjusted/master(unlocked)]> git annex view 'subdir\=*'
+view (searching...)
+Switched to branch 'views/adjusted/master(unlocked)(subdir_=_)'
+ok
+X:\git-annex-tests\annex-view-test-a [views/adjusted/master(unlocked)(subdir_=_)]> ls -r
+
+    Directory: X:\git-annex-tests\annex-view-test-a
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+d----           15.2.2023    12:55                subsubdir
+-a---           15.2.2023    12:55            178 b_%subdir%
+
+    Directory: X:\git-annex-tests\annex-view-test-a\subsubdir
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           15.2.2023    12:55            181 d_%subdir%subsubdir%
+
+# End of transcript or log.
+"""]]
+
+
+[[!meta author=jkniiv]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/explicit_metadata_needed_for_view_inclusion_or_not/comment_1_17f8adc8555ea0a2716308e3f5188a25._comment b/doc/todo/explicit_metadata_needed_for_view_inclusion_or_not/comment_1_17f8adc8555ea0a2716308e3f5188a25._comment
new file mode 100644
index 0000000000..00d42ef5a6
--- /dev/null
+++ b/doc/todo/explicit_metadata_needed_for_view_inclusion_or_not/comment_1_17f8adc8555ea0a2716308e3f5188a25._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-02-16T18:55:06Z"
+ content="""
+I'm surprised by this behavior change! (And I replicated it on linux, no
+apologies necessary for also testing Windows support..)
+
+[[!commit 826b225ca81d469640e51628865dbd64a1d37773]] is the buggy commit.
+When there is no metadata log, it accidentially skips calling
+getfilemetadata.
+
+I've fixed that. I wonder if I should push up the shedule of the next
+release because of this reversion? Currently I'm inclined to treat it as
+medium urgency for release (1-2 weeks).
+"""]]
diff --git a/doc/todo/export_--json_--json-progress_--json-error-messages.mdwn b/doc/todo/export_--json_--json-progress_--json-error-messages.mdwn
new file mode 100644
index 0000000000..86f8a3bb2d
--- /dev/null
+++ b/doc/todo/export_--json_--json-progress_--json-error-messages.mdwn
@@ -0,0 +1,6 @@
+Pretty much to mimic `copy` in terms of its interfaceability with external commands.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> easy one.. [[done]] --[[Joey]]
diff --git a/doc/todo/export_paired_rename_innefficenctcy.mdwn b/doc/todo/export_paired_rename_innefficenctcy.mdwn
new file mode 100644
index 0000000000..029a062c90
--- /dev/null
+++ b/doc/todo/export_paired_rename_innefficenctcy.mdwn
@@ -0,0 +1,12 @@
+`git annex export` can efficiently handle renames, including renames that swap
+content between files. However, when there are two pairs of duplicate files,
+and the filenames are swapped around, the current rename handling renames both
+dups to a single  temp file, and so the other file in the pair gets re-uploaded
+unncessarily. This could be improved.
+
+Perhaps: Find pairs of renames that swap content between two files.
+Run each pair in turn. Then run the current rename code. Although this
+still probably misses cases, where eg, content cycles amoung 3 files, and
+the same content amoung 3 other files. Is there a general algorythm?
+
+[[!tag needsthought]]
diff --git a/doc/todo/expose_fsck_last_run_information.mdwn b/doc/todo/expose_fsck_last_run_information.mdwn
new file mode 100644
index 0000000000..9e629c2072
--- /dev/null
+++ b/doc/todo/expose_fsck_last_run_information.mdwn
@@ -0,0 +1,5 @@
+I don't run fsck much on my git-annex repos, and I think I should do it more often. Part of the problem is I have lots of repos scattered all over the place and I'm not sure i want to run the assistant everywhere, so there's no clear way for me to "run `git annex foo` everywhere". (I have crude replacements like [git-annex-sync-all](https://gitlab.com/anarcat/scripts/-/blob/main/git-annex-sync-all?ref_type=heads) but anyway, that is not the point here...)
+
+One thing with fsck is I don't know if I've ever ran it on a repo. I have *just* noticed, after running it on a local repo, that the `activity.log` file on the `git-annex` branch gets bumped when a fsck runs, which I find interesting. Why wouldn't this precious information be displayed somewhere? Maybe in [[git-annex-info]], for the local repository (or added to the repositories table)?
+
+Thanks! -- [[anarcat]]
diff --git a/doc/todo/expose_fsck_last_run_information/comment_1_44f5eb2e601ba1a6cb22f5de7a6d3ff6._comment b/doc/todo/expose_fsck_last_run_information/comment_1_44f5eb2e601ba1a6cb22f5de7a6d3ff6._comment
new file mode 100644
index 0000000000..b22feac1f4
--- /dev/null
+++ b/doc/todo/expose_fsck_last_run_information/comment_1_44f5eb2e601ba1a6cb22f5de7a6d3ff6._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-08-16T17:01:21Z"
+ content="""
+The activity log was built for something else (git-annex expire) and there
+would be several problems with repurposing it for this:
+
+* A fsck activity is logged when the fsck starts, if the fsck is
+  interrupted part way through, or is an incremental fsck, or is a fsck
+  of only a few specific files, it is still logged.
+* The activity log is designed to also support other activities, and only
+  the most recent activity is recorded. While currently it only has a fsck
+  activity, it's possible that additional activities be added to support
+  git-annex expire. That would prevent displaying a fsck after such an
+  activity was recorded.
+
+It seems like your use case would need a log to be updated only once a
+complete fsck was done. Since fsck supports ad-hoc running on specific
+files, incremental fscks, fscking of other branches, etc, it's kind of hard
+to tell when that has happened.
+"""]]
diff --git a/doc/todo/expose_fsck_last_run_information/comment_2_9a1729dfbec291159000d3412dd147d7._comment b/doc/todo/expose_fsck_last_run_information/comment_2_9a1729dfbec291159000d3412dd147d7._comment
new file mode 100644
index 0000000000..2d3cc931cf
--- /dev/null
+++ b/doc/todo/expose_fsck_last_run_information/comment_2_9a1729dfbec291159000d3412dd147d7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="just show start time?"
+ date="2023-09-12T15:51:22Z"
+ content="""
+I guess one could just show the start time then, if that's what is being recorded... :)
+"""]]
diff --git a/doc/todo/external_backends.mdwn b/doc/todo/external_backends.mdwn
new file mode 100644
index 0000000000..af13e8b335
--- /dev/null
+++ b/doc/todo/external_backends.mdwn
@@ -0,0 +1,9 @@
+It would be good if one could define custom external [[backends]], the way one can define external custom remotes.   This would solve [[todo/consider_meow_backend]] but also have other uses.  For instance, sometimes files contain details irrelevant to the file's semantics (e.g. comments), but that change the file's checksum; with a custom backend, one could "canonicalize" a file before computing the checksum.
+
+@joey pointed out a potential problem: "needing to deal with the backend being missing or failing to work could have wide repurcussions in the code base."  I wonder if there are ways around that.  Suppose you specified a default backend to use in case a custom one was unavailable?  Then you could always compute a key from a file, even if it's not in the right backend.  And once a key is stored in git-annex, most of git-annex treats the key as just a string.  If the custom backend supports checksum verification, without the backend's implementation, keys from that backend would be treated like WORM/URL keys that do not support checksum checking.
+
+Thoughts?
+
+[[!tag projects/datalad]]
+
+> fully implemented. [[done]] --[[Joey]]
diff --git a/doc/todo/external_backends/comment_10_4c0f8a338a58cef8e239613292d5aa38._comment b/doc/todo/external_backends/comment_10_4c0f8a338a58cef8e239613292d5aa38._comment
new file mode 100644
index 0000000000..06d29cd0bf
--- /dev/null
+++ b/doc/todo/external_backends/comment_10_4c0f8a338a58cef8e239613292d5aa38._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="external backends"
+ date="2020-07-16T17:30:55Z"
+ content="""
+\"the user trusts the backend program as much as they do the git-annex program, when it comes to whether a hash is cryptographically secure\" -- I'd trust git-annex more because it has many more users than any one niche backend program, so gets more testing and scrutiny.
+
+\"just have a name registry on this site, first come first served\" -- seems fair; there may be more complex/robust solutions but doubt they're needed in practice.
+
+"""]]
diff --git a/doc/todo/external_backends/comment_11_56224638fde7b46ee6f52211474cd047._comment b/doc/todo/external_backends/comment_11_56224638fde7b46ee6f52211474cd047._comment
new file mode 100644
index 0000000000..7a78ef77b5
--- /dev/null
+++ b/doc/todo/external_backends/comment_11_56224638fde7b46ee6f52211474cd047._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2020-07-20T18:01:27Z"
+ content="""
+Wrote a draft [[design/external_backend_protocol]].
+
+I wonder if it makes sense to require the programs to format and parse
+their own keys; git-annex could break up the key and send the peices in.
+The advantage though is that this lets a program decide whether or not to
+include information like the size and mtime fields in the key or not.
+And if more fields ever got added it would not need changes to the
+protocol. I guess it's simple enough for format and parse, as shown by the
+example shell program that does it.
+"""]]
diff --git a/doc/todo/external_backends/comment_12_268cd038b7beb9d42cf0bd8803efce94._comment b/doc/todo/external_backends/comment_12_268cd038b7beb9d42cf0bd8803efce94._comment
new file mode 100644
index 0000000000..4944516847
--- /dev/null
+++ b/doc/todo/external_backends/comment_12_268cd038b7beb9d42cf0bd8803efce94._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2020-07-20T18:06:54Z"
+ content="""
+Moved isCryptographicallySecure into the Backend data structure. And
+it looks at whether verifyKeyContent is Nothing to decide if a given key
+is verifiable.
+
+If an external backend is not installed at all (or fails to start up
+correctly or speaks an unknown protocol version), what can be done is make a
+Backend data structure where genKey is Nothing, verifyKeyContent is
+Nothing, isCryptographicallySecure is False, and isStableKey is False.
+When annex.verify=true, git-annex will refuse to download such keys,
+but that can be changed if necessary. (annex.securehashesonly too)
+
+The isStableKey False will prevent chunking the key when storing on special
+remotes, but it can still be stored on them in unchunked form, the
+same as is done for URL keys. So, this seems like a reasonable enough
+fallback mode, although something will need to be done to warn the user
+about it. (Alternatively, could require that external backends generate
+stable keys, but that seems like it might get in the way of some
+things people might want to do with them.)
+
+If an external backend is broken and replies to VERIFYKEYCONTENT
+with ERROR, or crashes, downloaded content would get thrown away when it
+fails to verify, as I discussed above.
+"""]]
diff --git a/doc/todo/external_backends/comment_13_6e8452f06da80458bb2cccde05cc9813._comment b/doc/todo/external_backends/comment_13_6e8452f06da80458bb2cccde05cc9813._comment
new file mode 100644
index 0000000000..1192c61140
--- /dev/null
+++ b/doc/todo/external_backends/comment_13_6e8452f06da80458bb2cccde05cc9813._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="external backend protocol"
+ date="2020-07-21T17:43:27Z"
+ content="""
+1. What is the advantage of a separate `VERIFYCONTENT` request, vs calling `GENKEY` and comparing the result?
+2. Can the protocol specify that the file passed to `GENKEY` may be a named pipe?  Or, add a `CANPIPE` request where the external backend program tells git-annex that it can take pipes; if the program can't, git-annex can always drain the pipe to a tempfile before passing it to the program.
+3. \"While stderr is connected to the console and so visible to the user, the program should avoid using it\" -- then maybe add `DEBUG` and `INFO` requests as in the [[design/external_special_remote_protocol]]?
+"""]]
diff --git a/doc/todo/external_backends/comment_14_6edc4008ce8eec17e283dd7db8dbcbf0._comment b/doc/todo/external_backends/comment_14_6edc4008ce8eec17e283dd7db8dbcbf0._comment
new file mode 100644
index 0000000000..bb43080df2
--- /dev/null
+++ b/doc/todo/external_backends/comment_14_6edc4008ce8eec17e283dd7db8dbcbf0._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2020-07-27T15:20:00Z"
+ content="""
+> What is the advantage of a separate VERIFYCONTENT request, vs calling
+> GENKEY and comparing the result?
+
+Nothing for remotes using a hash. However, if the remote is using something
+other than a hash, or a hash combined with something else, it might not be
+able to regenerate the same key. It may still be able to detect
+corrupted content, eg using the hash part of the key.
+
+> Can the protocol specify that the file passed to GENKEY may be a named pipe
+
+I can't think of any situation where git-annex would GENKEY before
+it has the full content of a file available.
+
+> add DEBUG and INFO requests
+
+For INFO I'd rather wait for a use case. None of the current backends ever
+need to display any messages, except for in the case of an exceptional error,
+eg a hardware faulure where hashing. And ERROR would be fine for that.
+
+DEBUG sure.
+"""]]
diff --git a/doc/todo/external_backends/comment_15_7880557cb94706d82a6d2bfc785288ea._comment b/doc/todo/external_backends/comment_15_7880557cb94706d82a6d2bfc785288ea._comment
new file mode 100644
index 0000000000..322e52f08e
--- /dev/null
+++ b/doc/todo/external_backends/comment_15_7880557cb94706d82a6d2bfc785288ea._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="streaming data and external backends"
+ date="2020-07-30T15:58:21Z"
+ content="""
+\"I can't think of any situation where git-annex would GENKEY before it has the full content of a file available\" -- if [[todo/git-annex-cat]] were implemented, could then e.g. `git fsck --from REMOTE` without the data ever touching the disk.
+"""]]
diff --git a/doc/todo/external_backends/comment_1_9d73d6dbfabe3d58a41b661825bf3dcb._comment b/doc/todo/external_backends/comment_1_9d73d6dbfabe3d58a41b661825bf3dcb._comment
new file mode 100644
index 0000000000..f59787ea0a
--- /dev/null
+++ b/doc/todo/external_backends/comment_1_9d73d6dbfabe3d58a41b661825bf3dcb._comment
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-06-26T14:54:01Z"
+ content="""
+The main operations on keys are:
+
+* generate
+* verify
+* is stable (always refers to the same data, used only to determine if
+  chunks can be used when storing the content on a special remote)
+* is verifiable with a hash (for annex.security.allow-unverified-downloads)
+* is cryptographically secure hash
+
+Note that the last two of those are not currently part of the Backend
+object but would need to be moved to it to implement external backends.
+
+Now, if a external backend is not installed or is broken, how would those
+operations failing be handled?
+
+* generate: Not a problem, git-annex already falls back to another backend
+  if a backend fails to generate a key.
+* verify: This would need to return False. Since verification
+  is done after download in the default configuration, this would make 
+  the downloaded content be thrown away. Seems likely it would result in
+  repeated downloads of the same content when git-annex is run
+  repeatedly, or when using the assistant.  
+  fsck and reinject would also fail, so if a repo contained content using
+  an external backend and the program broken, fsck could move all the
+  content to .git/annex/bad/
+* is verifiable with a hash: Affects downloads same as verify.
+* is cryptographically secure hash: Similar to verify, but also affects
+  uploads when annex.securehashesonly is set.
+
+So I think that all these operations except for generate would need to have
+their type changed from Bool to Maybe Bool, and all code that uses them
+handle the case where the operation was unable to be performed.
+
+For fsck, it might need to start checking files it had previously moved to
+bad, and move them back into the annex if they now verify due to the
+external backend having gotten fixed.
+
+For downloads, if it can't verify, it might move to some holding location,
+and avoid re-downloading objects that are already located there. This would
+add more problems though; what if all the objects in that holding location
+use too much disk space? Should drop also drop them?
+
+Or the external backend could be tested somehow before starting a download
+(or a fsck) and skip its key if it's not installed or broken. But such a test
+can't catch every possible breakage. It's hard to see how such a test
+can do more than checking that it can start the program and that the
+program seems to be speaking the right protocol version.
+
+I suppose we could say that, if a external backend works to that extent but
+then breaks, the resulting bad behavior is its fault and not really the
+concern of git-annex. Or I could rationalize, that an external special
+remote can break in ways that eg, prevent content being moved to it, so it
+piles up in the local repo and uses too much disk space, and that this new
+potential breakage is not much worse -- though it seems the scenarios where
+it would have an adverse affect are likely to be more common.
+"""]]
diff --git a/doc/todo/external_backends/comment_2_a2528865e48f85feab5569951f13caa9._comment b/doc/todo/external_backends/comment_2_a2528865e48f85feab5569951f13caa9._comment
new file mode 100644
index 0000000000..34adbddf1f
--- /dev/null
+++ b/doc/todo/external_backends/comment_2_a2528865e48f85feab5569951f13caa9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-06-26T15:55:36Z"
+ content="""
+Occurs to me that the same problems discussed above also can happen when a
+new hash is added to git-annex and is used in a repo, that then gets used
+by an older version of git-annex.
+
+The blake2 hashes are one such.
+
+So, external backends shouldn't really be blocked by that bad behavior,
+agurably.
+"""]]
diff --git a/doc/todo/external_backends/comment_3_9451d002f6768dd5975d5816c12b1350._comment b/doc/todo/external_backends/comment_3_9451d002f6768dd5975d5816c12b1350._comment
new file mode 100644
index 0000000000..4fad8219e6
--- /dev/null
+++ b/doc/todo/external_backends/comment_3_9451d002f6768dd5975d5816c12b1350._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2019-06-26T20:15:19Z"
+ content="""
+Thanks a lot @joeyh for looking again at supporting external backends.
+
+I think the issues with missing backend implementations are similar to issues with a missing external special remote implementation: something that the repo owner/maintainer needs to deal with.  I periodically forget to put mine into the PATH, and then `git-annex` tells me to a special remote available.  Fixing these issues has been manageable in practice.
+
+For reference, these are some of the todos that support for external backends would obviate: [[todo/key_checksum_from_chunk_checksums]] [[todo/MD5E_keys_without_file_size]] [[todo/preserve_file_extensions_in_WORM_and_URL_keys]] [[todo/option_to_add_user-specified_string_to_key]] [[todo/add_xxHash_backend]] .
+
+
+
+"""]]
diff --git a/doc/todo/external_backends/comment_4_2983bbf5e1cc485da3e8e9628a4bea89._comment b/doc/todo/external_backends/comment_4_2983bbf5e1cc485da3e8e9628a4bea89._comment
new file mode 100644
index 0000000000..a29d478d1e
--- /dev/null
+++ b/doc/todo/external_backends/comment_4_2983bbf5e1cc485da3e8e9628a4bea89._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="some todos that external backends would obviate (fix formatting, add one)"
+ date="2019-06-26T20:25:50Z"
+ content="""
+* [[todo/key_checksum_from_chunk_checksums]]
+* [[todo/MD5E_keys_without_file_size]]
+* [[todo/preserve_file_extensions_in_WORM_and_URL_keys]]
+* [[todo/option_to_add_user-specified_string_to_key]]
+* [[todo/shorter_keys_through_better_encoding]]
+
+"""]]
diff --git a/doc/todo/external_backends/comment_5_37fd824cf9f2dcc59616b9d49e38c262._comment b/doc/todo/external_backends/comment_5_37fd824cf9f2dcc59616b9d49e38c262._comment
new file mode 100644
index 0000000000..fae1136126
--- /dev/null
+++ b/doc/todo/external_backends/comment_5_37fd824cf9f2dcc59616b9d49e38c262._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 5"
+ date="2019-06-26T20:38:19Z"
+ content="""
+P.S. It seems that in case of missing backend implementation, the handling should revert to exactly what currently happens for WORM/URL keys?  Except with a different warning message, as custom backends are _potentially_ verifiable.
+
+If git-annex could support [[todo/alternate_keys_for_same_content]], then for a download from an external backend key you could also compute a standard checksum-based key (e.g. MD5 or SHA256), and record its presence in the remote you got the contents from, and the correspondence to the external backend key.  Then, at least, if this contents gets uploaded somewhere else, it would be verifiable even without the external backend implementation.
+"""]]
diff --git a/doc/todo/external_backends/comment_6_d871bdf09932035acc6260c839f45757._comment b/doc/todo/external_backends/comment_6_d871bdf09932035acc6260c839f45757._comment
new file mode 100644
index 0000000000..42c82a5d82
--- /dev/null
+++ b/doc/todo/external_backends/comment_6_d871bdf09932035acc6260c839f45757._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="dockerized external backends"
+ date="2019-06-28T16:36:10Z"
+ content="""
+Similar to [[todo/dockerized_external_special_remotes]], you could support dockerized external backends.  You could run a docker container with [networking disabled](https://docs.docker.com/network/none/) and with file access only to the to-be-annexed file(s), through a [read-only volume](https://docs.docker.com/storage/volumes/#use-a-read-only-volume).  You could also require the docker image to be [signed](https://docs.docker.com/engine/security/trust/content_trust/) by someone you trust.  Then git-annex repos with external-backend keys could still be self-contained.
+"""]]
diff --git a/doc/todo/external_backends/comment_7_090e62b5d37beb5d62d56cfb3b1e2134._comment b/doc/todo/external_backends/comment_7_090e62b5d37beb5d62d56cfb3b1e2134._comment
new file mode 100644
index 0000000000..eef3d91ecf
--- /dev/null
+++ b/doc/todo/external_backends/comment_7_090e62b5d37beb5d62d56cfb3b1e2134._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="verifying and external backends"
+ date="2019-06-28T17:14:17Z"
+ content="""
+In fact, it seems you'd _always_ have to treat external-backend keys as unverified by default, and require explicit configuration to override that?  Even if an external backend claims to compute a cryptographically secure hash, you can't guarantee that it does.  It seems that the handling should be exactly as for URL/WORM keys, except that, instead of completely disabling verification with `annex.security.allow-unverified-downloads`, the user could enable verification by an external backend implementation which the user trusts.
+"""]]
diff --git a/doc/todo/external_backends/comment_8_e3c66820da36fe255d07059226690ca4._comment b/doc/todo/external_backends/comment_8_e3c66820da36fe255d07059226690ca4._comment
new file mode 100644
index 0000000000..4738b20fa4
--- /dev/null
+++ b/doc/todo/external_backends/comment_8_e3c66820da36fe255d07059226690ca4._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: verifying and external backends"""
+ date="2020-07-15T13:55:15Z"
+ content="""
+It seems reasonable to assume the user trusts the backend program as much
+as they do the git-annex program, when it comes to whether a hash is
+cryptographically secure. They're both programs the user has decided to
+use, which could do far more mischief than pretending that md5 is secure.
+
+The suggestion that this could be used for
+[[todo/option_to_add_user-specified_string_to_key]] raises its own security
+concerns. (Although git's sha1 collision hardening probably will survive
+until git sha256, so git-annex's attempts to prevent sha1 collisions via
+user-supplied data in the content of keys are probably unnecessary.)
+"""]]
diff --git a/doc/todo/external_backends/comment_9_bf2de8fdc134684f0af2b53bc9b78f08._comment b/doc/todo/external_backends/comment_9_bf2de8fdc134684f0af2b53bc9b78f08._comment
new file mode 100644
index 0000000000..0d240b181b
--- /dev/null
+++ b/doc/todo/external_backends/comment_9_bf2de8fdc134684f0af2b53bc9b78f08._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2020-07-15T17:52:03Z"
+ content="""
+Seems that this has a naming problem. Each backend needs a unique name. The
+length of the name has to be short enough to not make the key length
+excessive. The longest backend name in git-annex is "BLAKE2SP256E" (12).
+A UUID seems too long, domain name probably too long.
+
+If two external backends picked the same name and the wrong one
+got installed, bad things could happen, like failing to verify content
+because it used an unexpected hash.
+
+Maybe just have a name registry on this site, first come first served and
+if you chose to overlap, you get to keep all 100 pieces?
+
+(Note that external special remote programs must have unique names too,
+which does not seem to have been a problem in practice.)
+"""]]
diff --git a/doc/todo/external_remote_querying_transition.mdwn b/doc/todo/external_remote_querying_transition.mdwn
new file mode 100644
index 0000000000..d18e23f157
--- /dev/null
+++ b/doc/todo/external_remote_querying_transition.mdwn
@@ -0,0 +1,53 @@
+The problem: WHEREIS must come after PREPARE, and external remotes are
+encouraged to establish network connections in PREPARE to simplify their
+implementations. So `git annex whereis` with such an external remote
+enabled and content on that remote is slowed down by an unnecessary network
+connection.
+
+Note that this even happens when the external remote does not implement
+support for WHEREIS.
+
+So, we want to deprecate WHEREIS needing to come after PREPARE.
+
+GETINFO has the same problem. (GETCOST and GETAVAILABILITY also, but
+those are cached to avoid needing to be run more than once per remote.)
+
+The transition: 
+
+* Add an extension to the protocol that lets WHEREIS come before/without
+  PREPARE. The external remote can indicate it supports this by negotiating
+  EXTENSIONS WHEREIS.
+
+  And similarly for GETINFO, with EXTENSIONS GETINFO.
+
+* For a while, git-annex can continue to send WHEREIS after PREPARE when
+  the external remote doesn't support the protocol extension. If the
+  external remote replies with WHEREIS-SUCCESS, then git-annex can warn
+  that it needs to be updated for the transition. (If it replies with
+  WHEREIS-FAILURE, it may be that it only has stub whereis support that
+  doesn't do anything, so probably git-annex should avoid warning in that
+  case).
+
+  And similarly for GETINFO, warning when it is sent after PREPARE and
+  there are any INFOFIELD replies, but not warning if there's only an
+  INFOEND.
+
+* Eventually, git-annex can stop sending WHEREIS unless the protocol
+  extension was negotiated. So WHEREIS stops being part of the
+  base protocol and becomes an extension.
+
+  Ditto for GETINFO.
+
+Possible complications:
+
+An external remote may need to do some kind of expensive setup to prepare
+to reply to WHEREIS, such as querying with GETCONFIG or looking at its own
+internal state or whatever. With WHEREIS run before PREPARE, such a remote
+will need to defer that setup until the first WHEREIS and cache it for
+subsequent WHEREIS, which may complicate its code slightly.
+
+Note that the protocol does allow querying with GETCONFIG etc before
+responding to a WHEREIS request.
+
+[[!tag confirmed]]
+[[!tag projects/datalad/potential]]
diff --git a/doc/todo/external_remote_querying_transition/comment_1_838311ffa7f00d65c9ab23717dd117aa._comment b/doc/todo/external_remote_querying_transition/comment_1_838311ffa7f00d65c9ab23717dd117aa._comment
new file mode 100644
index 0000000000..27bdb21a1a
--- /dev/null
+++ b/doc/todo/external_remote_querying_transition/comment_1_838311ffa7f00d65c9ab23717dd117aa._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 1"
+ date="2019-01-21T11:40:07Z"
+ content="""
+Great idea! I like it that this way all remotes benefit speed wise while only the ones which actually use these commands will have to be updated. That's a huge plus over something like PREPARE-LOCAL.
+"""]]
diff --git a/doc/todo/external_remotes__58___Add_support_for_ErrorMsg_to_-FAILURE_messages_lacking_it.mdwn b/doc/todo/external_remotes__58___Add_support_for_ErrorMsg_to_-FAILURE_messages_lacking_it.mdwn
new file mode 100644
index 0000000000..4d3ca9793a
--- /dev/null
+++ b/doc/todo/external_remotes__58___Add_support_for_ErrorMsg_to_-FAILURE_messages_lacking_it.mdwn
@@ -0,0 +1,32 @@
+ATM
+
+[[!format sh """
+$> grep -e -FAILURE doc/design/external_special_remote_protocol.mdwn
+  * `INITREMOTE-FAILURE ErrorMsg`  
+  * `PREPARE-FAILURE ErrorMsg`  
+  * `TRANSFER-FAILURE STORE|RETRIEVE Key ErrorMsg`  
+  * `CHECKPRESENT-FAILURE Key`  
+  * `REMOVE-FAILURE Key ErrorMsg`  
+  * `CLAIMURL-FAILURE`  
+  * `CHECKURL-FAILURE`  
+  * `WHEREIS-FAILURE` 
+"""]]
+
+so some commands have a way to report why action failed and some do not.
+
+I have been running into an error message `CHECKURL failed with no reason given` and I thought our special remote is just not letting know details but apparently I just followed the spec and thus did not provide description of the reason why CHECKURL has failed.  That complicates debugging/fixing.
+
+Unfortunately it seems that adding such support would not be backward compatible, ie older versions of git annex would puke if external remote starts to provide error message, so I guess it would be up to the remote to check annex version (or protocol features?) on either it can report an error:
+
+[[!format sh """
+  external special remote protocol error, unexpectedly received "CLAIMURL-FAILURE IT IS FAILURE" (unable to parse command)
+git-annex: unable to use special remote due to protocol error
+
+$> git annex version
+git-annex version: 8.20200810+git143-gdee38c54d-1~ndall+1
+"""]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] the documentation --[[Joey]]
diff --git a/doc/todo/external_remotes__58___Add_support_for_ErrorMsg_to_-FAILURE_messages_lacking_it/comment_1_a096df37d5bc5543b574b32554311af9._comment b/doc/todo/external_remotes__58___Add_support_for_ErrorMsg_to_-FAILURE_messages_lacking_it/comment_1_a096df37d5bc5543b574b32554311af9._comment
new file mode 100644
index 0000000000..dae25a2b4c
--- /dev/null
+++ b/doc/todo/external_remotes__58___Add_support_for_ErrorMsg_to_-FAILURE_messages_lacking_it/comment_1_a096df37d5bc5543b574b32554311af9._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-09-18T15:50:11Z"
+ content="""
+CHECKURL-FAILURE actually supports an error message,
+always has. The docs were just wrong.
+
+CHECKPRESENT-FAILURE is not for an exceptional case,
+but a usual case. CHECKPRESENT-UNKNOWN is for the exceptional case and
+includes an error message.
+
+CLAIMURL-FAILURE means the remote does not claim the url, so there is no
+need for an error message since git-annex will use web as usual.
+
+WHEREIS-FAILURE means the remote does not have information for whereis,
+it's not an exceptional case. Especially since WHEREIS is not supposed to
+use network access or anything.
+"""]]
diff --git a/doc/todo/external_special_remotes_not_using_git-annex-remote_in_name.mdwn b/doc/todo/external_special_remotes_not_using_git-annex-remote_in_name.mdwn
new file mode 100644
index 0000000000..5956cccdbe
--- /dev/null
+++ b/doc/todo/external_special_remotes_not_using_git-annex-remote_in_name.mdwn
@@ -0,0 +1,48 @@
+rclone now supports being run as a git-annex special remote natively
+see <https://github.com/rclone/rclone/pull/7654>. "rclone gitannex"
+is the command to run. But git-annex needs a git-annex-remote-rclone or similar,
+so to use it needs a git-annex-remote-rclone-builtin symlink to rclone,
+and when run under that name it behaves as if "rclone gitannex" were run.
+
+rclone won't be shipping that symlink, so users will have to create it
+themselves, which complicates using it. So could git-annex instead
+support running "rclone gitannex" itself?
+
+From the pull request, @dmcardle wrote:
+
+> My taste would be to implement a more generic mechanism rather than adding a special case for rclone gitannex. 
+> What if externaltype could be repeated, so that git annex initremote MyRemote type=external externaltype=rclone >
+> externaltype=gitannex ... would cause git-annex to exec rclone with the additional gitannex arg?
+
+But, that seems to present a security problem. Consider an attacker who runs
+`git-annex initremote foo type=external autoenable=true externaltype=rm externaltype=/foo`
+
+My conclusion is that git-annex can't provide a generic way to run a different
+command for an external special remote. Any such commands need to be
+whitelisted in some way. And if they're whitelisted, it seems better to not
+require the user to enter additional parameters at all.
+
+So one way would be to make "git-annex initremote foo type=external externaltype=rclone-builtin"
+run "rclone gitannex".
+
+Or, git-annex add an internal rclone special remote, that is just
+a wrapper around the external special remote, that makes it use
+"rclone gitannex". "git-annex initremote foo type=rclone" --[[Joey]]
+
+> Considering those two approaches again, the first would let the new
+> rclone be used with old git-annex with the user making the
+> git-annex-remote-rclone-builtin symlink. Then later, that same
+> special remote could be used with the new git-annex on a system
+> where that symlink was not set up.
+> 
+> The second approach would make a special remote that can't be used with
+> old git-annex. But if the user wanted to use the new rclone with old
+> git-annex, they can still make the symlink. To later migrate away from
+> the symlink, they would need to initremote another special remote using
+> --sameas.
+>
+> I feel that the simplicity of the type=rclone config will pay off in the
+> long term, vs short term complication for probably a small subset of users
+> who somehow can upgrade rclone but can't upgrade git-annex. --[[Joey]]
+
+> > [[done]] 
diff --git a/doc/todo/external_special_remotes_not_using_git-annex-remote_in_name/comment_1_8bb17f1a8297b500dcc5bdf9412a5d6c._comment b/doc/todo/external_special_remotes_not_using_git-annex-remote_in_name/comment_1_8bb17f1a8297b500dcc5bdf9412a5d6c._comment
new file mode 100644
index 0000000000..e5e87eaf0b
--- /dev/null
+++ b/doc/todo/external_special_remotes_not_using_git-annex-remote_in_name/comment_1_8bb17f1a8297b500dcc5bdf9412a5d6c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2024-03-26T19:13:15Z"
+ content="""
+my 1c: since `git-annex` is pretty much following git's own `git-remote-` paradigm here, I think it is ok to require `git-annex-remote-` to even simply be able to check what are the available `git-annex` remotes etc. Providing a shim to pass through to some tool specific interface is IMHO trivial enough. And as you outline, such approach also helps to avoid a security concern.
+"""]]
diff --git a/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__.mdwn b/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__.mdwn
new file mode 100644
index 0000000000..f71c7af5c3
--- /dev/null
+++ b/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__.mdwn
@@ -0,0 +1,219 @@
+<details>
+<summary>full log</summary> 
+
+```shell
+[yhalchen@discovery7 tmp]$ ( PS4='[$(date)] > '; set -x; mkdir test; cd test; git init; git annex --debug init; cat .git/config; )
+[Thu Jun  4 22:03:14 EDT 2020] > mkdir test
+[Thu Jun  4 22:03:14 EDT 2020] > cd test
+[Thu Jun  4 22:03:14 EDT 2020] > git init
+Initialized empty Git repository in /ihome/yhalchen/tmp/test/.git/
+[Thu Jun  4 22:03:15 EDT 2020] > git annex --debug init
+init  [2020-06-04 22:03:15.148337333] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2020-06-04 22:03:15.160519651] process done ExitFailure 1
+[2020-06-04 22:03:15.160710842] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","origin/git-annex"]
+[2020-06-04 22:03:15.170626699] process done ExitFailure 1
+[2020-06-04 22:03:15.173741089] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2020-06-04 22:03:15.193985902] process done ExitSuccess
+[2020-06-04 22:03:15.194151767] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","4b825dc642cb6eb9a060e54bf8d69288fbee4904","--no-gpg-sign"]
+[2020-06-04 22:03:15.211084581] process done ExitSuccess
+[2020-06-04 22:03:15.211219476] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","c2a44ece57b7a7c9105efec702a3fcd5118c16a5"]
+[2020-06-04 22:03:15.251272209] process done ExitSuccess
+[2020-06-04 22:03:15.257790738] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.uuid","17782290-31aa-4bdf-a18d-7808ffe7c977"]
+[2020-06-04 22:03:15.272462579] process done ExitSuccess
+[2020-06-04 22:03:15.272624366] read: git ["config","--null","--list"]
+[2020-06-04 22:03:15.283187109] process done ExitSuccess
+
+  Detected a filesystem without POSIX fcntl lock support.
+
+  Enabling annex.pidlock.
+[2020-06-04 22:05:15.34524884] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.pidlock","true"]
+[2020-06-04 22:05:15.372408603] process done ExitSuccess
+[2020-06-04 22:05:15.372568858] read: git ["config","--null","--list"]
+[2020-06-04 22:05:15.382733867] process done ExitSuccess
+[2020-06-04 22:05:15.409269066] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2020-06-04 22:05:15.422429606] process done ExitSuccess
+[2020-06-04 22:05:15.422580683] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2020-06-04 22:05:15.433488294] process done ExitSuccess
+[2020-06-04 22:05:15.434294861] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..c2a44ece57b7a7c9105efec702a3fcd5118c16a5","--pretty=%H","-n1"]
+[2020-06-04 22:05:15.447151633] process done ExitSuccess
+[2020-06-04 22:05:15.448153606] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2020-06-04 22:05:15.449404288] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2020-06-04 22:05:15.45912651] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.version","8"]
+[2020-06-04 22:05:15.473144196] process done ExitSuccess
+[2020-06-04 22:05:15.473323633] read: git ["config","--null","--list"]
+[2020-06-04 22:05:15.484002445] process done ExitSuccess
+[2020-06-04 22:05:15.484194067] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","status","--porcelain"]
+[2020-06-04 22:05:15.500626848] process done ExitSuccess
+[2020-06-04 22:05:15.500774482] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","filter.annex.smudge","git-annex smudge -- %f"]
+[2020-06-04 22:05:15.514966575] process done ExitSuccess
+[2020-06-04 22:05:15.515111682] read: git ["config","--null","--list"]
+[2020-06-04 22:05:15.525620475] process done ExitSuccess
+[2020-06-04 22:05:15.526092889] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","filter.annex.clean","git-annex smudge --clean -- %f"]
+[2020-06-04 22:05:15.540331882] process done ExitSuccess
+[2020-06-04 22:05:15.540500706] read: git ["config","--null","--list"]
+[2020-06-04 22:05:15.550791736] process done ExitSuccess
+(scanning for unlocked files...)
+[2020-06-04 22:05:15.554116957] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--head"]
+[2020-06-04 22:05:15.564970531] process done ExitSuccess
+[2020-06-04 22:05:15.579478389] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2020-06-04 22:05:15.589809596] process done ExitSuccess
+[2020-06-04 22:05:15.589951516] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2020-06-04 22:05:15.601255052] process done ExitFailure 1
+[2020-06-04 22:05:15.601424674] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2020-06-04 22:05:15.611496747] process done ExitSuccess
+[2020-06-04 22:05:15.611639271] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2020-06-04 22:05:15.622536266] process done ExitFailure 1
+[2020-06-04 22:05:15.622929217] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","checkout","-q","-B","master"]
+[2020-06-04 22:05:15.638313905] process done ExitSuccess
+[2020-06-04 22:05:15.645385428] read: uname ["-n"]
+[2020-06-04 22:05:15.651959283] process done ExitSuccess
+ok
+[2020-06-04 22:05:15.704393232] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]
+[2020-06-04 22:05:15.705996303] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+[2020-06-04 22:05:15.72599264] process done ExitSuccess
+[2020-06-04 22:05:15.726142726] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2020-06-04 22:05:15.737436564] process done ExitSuccess
+(recording state in git...)
+[2020-06-04 22:05:15.737859056] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2020-06-04 22:05:15.758832639] process done ExitSuccess
+[2020-06-04 22:05:15.758982175] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","1767824d19ab44b9b0f2a156663e4f3bc37e902f","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2020-06-04 22:05:15.777364836] process done ExitSuccess
+[2020-06-04 22:05:15.777525965] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","6dc63f68c7036fbef7a4afeead658ab42433ad55"]
+[2020-06-04 22:05:15.797354413] process done ExitSuccess
+[2020-06-04 22:05:15.828091917] process done ExitSuccess
+[2020-06-04 22:05:15.828520537] process done ExitSuccess
+[2020-06-04 22:05:15.828968133] process done ExitSuccess
+[Thu Jun  4 22:05:15 EDT 2020] > cat .git/config
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+[annex]
+	uuid = 17782290-31aa-4bdf-a18d-7808ffe7c977
+	pidlock = true
+	version = 8
+[filter "annex"]
+	smudge = git-annex smudge -- %f
+	clean = git-annex smudge --clean -- %f
+[yhalchen@discovery7 tmp]$ git annex version
+git-annex version: 8.20200502-g55acb2e52
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+
+```
+</details>
+
+the excerpt for running `git-annex init` of 8.20200502-g55acb2e52 on an NFS mounted isilon volume:
+[[!format sh """
+[2020-06-04 22:03:15.283187109] process done ExitSuccess
+
+  Detected a filesystem without POSIX fcntl lock support.
+
+  Enabling annex.pidlock.
+[2020-06-04 22:05:15.34524884] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.pidlock","true"]
+"""]]
+
+so  - 2 minutes. Running with `strace -f` showed a long flood of `[pid  2890] read(4, "\1\0\0\0\0\0\0\0", 8) = 8`
+
+<details>
+<summary>here is an excerpt where it begins with timing stamps</summary> 
+
+```shell
+[pid  7661] 22:12:42.464620 futex(0x2abd17039ad0, FUTEX_WAKE_PRIVATE, 1) = 0
+[pid  7661] 22:12:42.464705 openat(AT_FDCWD, "./.noannex", O_RDONLY|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
+[pid  7661] 22:12:42.464828 getcwd("/ihome/yhalchen/tmp/test", 4096) = 25
+[pid  7661] 22:12:42.464913 getcwd("/ihome/yhalchen/tmp/test", 4096) = 25
+[pid  7661] 22:12:42.465045 mkdir(".git/annex/misctmp", 0777) = 0
+[pid  7661] 22:12:42.466273 unlink(".git/annex/misctmp/lockprobe") = -1 ENOENT (No such file or directory)
+[pid  7661] 22:12:42.466699 openat(AT_FDCWD, ".git/annex/misctmp/lockprobe", O_RDWR|O_CREAT, 0666) = 11
+[pid  7661] 22:12:42.467692 fcntl(11, F_GETFD) = 0
+[pid  7661] 22:12:42.467768 fcntl(11, F_SETFD, FD_CLOEXEC) = 0
+[pid  7661] 22:12:42.467841 fcntl(11, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0} <unfinished ...>
+[pid  7703] 22:12:42.473082 <... read resumed>"\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.473137 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.483143 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.493202 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.503215 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.513202 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.523178 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.533202 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.543191 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.553186 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.563219 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.573212 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.583215 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.593206 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.603168 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.613209 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.623150 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.633193 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.643242 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.653170 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.663189 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.673182 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.683183 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.693190 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.703184 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.713203 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.723212 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.733202 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.743181 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.753220 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.763179 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.773207 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.783204 write(10, "\377\0\0\0\0\0\0\0", 8) = 8
+[pid  7705] 22:12:42.783323 <... poll resumed>) = 1 ([{fd=10, revents=POLLIN}])
+[pid  7703] 22:12:42.783367 read(4,  <unfinished ...>
+[pid  7705] 22:12:42.783441 futex(0x2abd17039cbc, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
+[pid  7703] 22:12:42.793162 <... read resumed>"\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.793241 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.803209 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.813218 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.823185 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.833206 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+[pid  7703] 22:12:42.843189 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
+
+```
+</details>
+
+I wonder if there is a way to "speed up" pidlock detection?
+
+At least adding some debug message before running the detection could be of help, it could help troubleshoot what I thought was some "ssh" stall since it just got stuck at
+
+<details>
+<summary>with the last line just saying "process done ExitSuccess" for that long and I kept killing it impatiently</summary> 
+
+```shell
+*[yhalchen@discovery7 containers]$ git annex --debug get --from origin images/bids/bids-fmriprep--20.1.0.sing
+[2020-06-04 22:14:49.036738929] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2020-06-04 22:14:49.053892561] process done ExitSuccess
+[2020-06-04 22:14:49.054443458] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2020-06-04 22:14:49.066856316] process done ExitFailure 1
+[2020-06-04 22:14:49.06701345] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","origin/git-annex"]
+[2020-06-04 22:14:49.07703984] process done ExitFailure 1
+[2020-06-04 22:14:49.079889542] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2020-06-04 22:14:49.097069694] process done ExitSuccess
+[2020-06-04 22:14:49.097233049] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","4b825dc642cb6eb9a060e54bf8d69288fbee4904","--no-gpg-sign"]
+[2020-06-04 22:14:49.131741755] process done ExitSuccess
+[2020-06-04 22:14:49.131910038] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","8cab5728da95189f68c785bd4bb59ca754e133fd"]
+[2020-06-04 22:14:49.153852043] process done ExitSuccess
+[2020-06-04 22:14:49.159730902] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.uuid","fd97689f-716d-4e82-87ce-5b96c2421dd6"]
+[2020-06-04 22:14:49.175319685] process done ExitSuccess
+[2020-06-04 22:14:49.175479616] read: git ["config","--null","--list"]
+[2020-06-04 22:14:49.184803048] process done ExitSuccess
+# here I kept killing it but then eventually it shows that it is enabling pidlock
+
+```
+</details>
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> what I mentioned in the comments is [[done]] --[[Joey]]
+
diff --git a/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_1_9c77d8cf628025308c2561a8a46d2365._comment b/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_1_9c77d8cf628025308c2561a8a46d2365._comment
new file mode 100644
index 0000000000..857c471709
--- /dev/null
+++ b/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_1_9c77d8cf628025308c2561a8a46d2365._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-05T14:43:13Z"
+ content="""
+So your nfs filesystem is making a posix lock operation block for 2 minutes
+before, I suppose, it makes it fail.
+
+Since git-annex has to do a posix lock operation, the only way to make it
+faster would be to fix the nfs filesystem to not do that. Perhaps by disabling
+posix locking altogether since it's apparently broken.
+
+But as far as what git-annex can do, I don't see any possible way to speed it up.
+
+I agree it could make sense to display a message, although that will also
+be a message the vast majority of users who are not in this situation would
+see. Maybe it could wait 1-10 seconds (probably 1000 times as long as it
+will take in most situations) and if the probe is still ongoing, display a
+message.
+"""]]
diff --git a/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_2_0d7eb254ec9ff7ba8b1831898008747f._comment b/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_2_0d7eb254ec9ff7ba8b1831898008747f._comment
new file mode 100644
index 0000000000..bc80eaa103
--- /dev/null
+++ b/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_2_0d7eb254ec9ff7ba8b1831898008747f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-06-05T14:54:31Z"
+ content="""
+Also, it could check if annex.pidlock is already set globally, and skip the
+probe. Which maybe would work for you? 
+
+I'm going to implement both the delayed message, and checking
+annex.pidlock.
+
+(Timing out the probe after some period of time less than 2 minutes would
+also be a possibility, but then there could be false positives on
+filesystems that are just legitimately very slow. Doesn't seem a good
+idea.)
+"""]]
diff --git a/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_3_26f82b5ef0ce9dc0a5a8fc64f4a3b335._comment b/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_3_26f82b5ef0ce9dc0a5a8fc64f4a3b335._comment
new file mode 100644
index 0000000000..1ff45ff2bc
--- /dev/null
+++ b/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_3_26f82b5ef0ce9dc0a5a8fc64f4a3b335._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-06-05T15:11:44Z"
+ content="""
+Is this related to your other bug about something seeming to hang/stall?
+"""]]
diff --git a/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_4_3e2b49710772340238358041ba91bc25._comment b/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_4_3e2b49710772340238358041ba91bc25._comment
new file mode 100644
index 0000000000..8eff3de586
--- /dev/null
+++ b/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_4_3e2b49710772340238358041ba91bc25._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="reply to Joey's comments"
+ date="2020-06-05T22:11:47Z"
+ content="""
+> Also, it could check if annex.pidlock is already set globally, and skip the probe...
+
+<details>
+<summary>I would assume it already does it since with globally set pidlock it proceeds fine</summary> 
+
+```shell
+[d31548v@discovery7 tmp]$ git config annex.pidlock
+1
+[d31548v@discovery7 tmp]$ ( export PS4='[$(date)] > '; set -x ; mkdir test; cd test; git init; git annex  init; echo done; )
+[Fri Jun  5 18:04:28 EDT 2020] > mkdir test
+[Fri Jun  5 18:04:28 EDT 2020] > cd test
+[Fri Jun  5 18:04:28 EDT 2020] > git init
+Initialized empty Git repository in /dartfs-hpc/rc/home/v/d31548v/tmp/test/.git/
+[Fri Jun  5 18:04:28 EDT 2020] > git annex init
+init  (scanning for unlocked files...)
+ok
+(recording state in git...)
+[Fri Jun  5 18:04:30 EDT 2020] > echo done
+done
+
+```
+</details>
+
+The problem somewhat that global pidlock is not generally needed - some partitions do have proper POSIX file systems, so setting it globally is \"suboptimal\", needs to be provisioned for every node (by an admin) and/or user.
+
+> I agree it could make sense to display a message, although that will also be a message the vast majority of users who are not in this situation would see
+
+Sure - that would be ideal, but if anything - debug message before sensing for the log would at least suffice to help with troubleshooting.
+
+> Is this related to your other bug about something seeming to hang/stall?
+
+It might depend to which one? ;-)  if [this one (upon enableremote)](https://git-annex.branchable.com/bugs/enableremote_stuck_with_a_recentish_git-annex/) - unlikely since that one happens I believe on non-crippled FS
+"""]]
diff --git a/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_5_009ffc560a14061feb8d748e1d2d9b71._comment b/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_5_009ffc560a14061feb8d748e1d2d9b71._comment
new file mode 100644
index 0000000000..a0dc495e4b
--- /dev/null
+++ b/doc/todo/faster___40__took_2_min__41___way_to_realize_the_need_in_pidlock__63__/comment_5_009ffc560a14061feb8d748e1d2d9b71._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2020-06-05T22:15:09Z"
+ content="""
+> I would assume it already does it since with globally set pidlock it proceeds fine
+
+SCRAP that!  I do not know what has changed since yesterday to my home directory (may be admin turned it into a POSIX one... I should have not let him know! ;)) since it works even without global pidlock set.  I will inquire.
+"""]]
diff --git a/doc/todo/faster_incremental_update_of_view_branch_by_git-annex_sync.mdwn b/doc/todo/faster_incremental_update_of_view_branch_by_git-annex_sync.mdwn
new file mode 100644
index 0000000000..7745bb7af3
--- /dev/null
+++ b/doc/todo/faster_incremental_update_of_view_branch_by_git-annex_sync.mdwn
@@ -0,0 +1,27 @@
+git-annex sync, when run in a view branch, regenerates the view branch from
+scratch. That is as expensive as entering the view branch in the first
+place, which can take quite a long time when there are a lot of files.
+
+And users with a lot of files are just the kind of user a view branch
+appeals to..
+
+There is probably a lot of scope for optimisation in updating the view
+branch, that might be able to get it reasonably quick. 
+I have not fully thought through it, but basically diffing from the old
+parent branch to the new parent to find files that have changed, and
+adding/removing those from the view. And also diffing from the old
+git-annex branch tree to the new one to get changes to metadata logs,
+parsing those and using changes to metadata to also move/delete/add
+files to the view branch.
+
+It may also be that just improving the precaching of metadata logs
+would improve the speed a lot. The streaming precaching of location logs
+sped up some commands around 2x before IIRC.
+
+> catObjectStream of metadata logs sped view constriction up by ~50%.
+> More streaming should speed it up more; it still uses
+> lookupKey/catKey once per file. --[[Joey]]
+
+> Seems like this was implemented in
+> [[!commit 5f9bf51438a16b73d6fcf30f3ca43fbb894ea5df]]
+> ... so [[done]]! --[[Joey]]
diff --git a/doc/todo/filter-branch_for_objects.mdwn b/doc/todo/filter-branch_for_objects.mdwn
new file mode 100644
index 0000000000..3483470895
--- /dev/null
+++ b/doc/todo/filter-branch_for_objects.mdwn
@@ -0,0 +1,14 @@
+`git-annex filter-branch` can be used to split a git-annex repository.
+However, the approach in [[tips/splitting_a_repository]] then copies all
+objects into the new repository and drops unused objects. And dropunused
+updates location log in that situation, even when the location log didn't
+exist in that repository before. So, that approach leaks information about
+objects that were in the original repository into the split repository.
+
+Splitting a git-annex repository is something that, when you need to do it,
+you may have good reasons to want to avoid any such leakage of
+information.
+
+So perhaps add a feature that copies only the needed objects over to the
+split repository? Or update the tip with a better method that avoids this
+problem. --[[Joey]]
diff --git a/doc/todo/find__47__prefer_keys_by_file_extension_in_key.mdwn b/doc/todo/find__47__prefer_keys_by_file_extension_in_key.mdwn
new file mode 100644
index 0000000000..635f6a7ba4
--- /dev/null
+++ b/doc/todo/find__47__prefer_keys_by_file_extension_in_key.mdwn
@@ -0,0 +1 @@
+Add [[preferred content expression|git-annex-preferred-content]] and [[matching option|git-annex-matching-options]] to match the file extension incorporated into a `*E` [[key|backends]], e.g. `keyext=.mp3` .  This would help address the limitation that `include=*.mp3` does not work with `--all` or `--unused`.
diff --git a/doc/todo/find__47__prefer_keys_by_file_extension_in_key/comment_1_fcf6f2c6ecf49930f4ddbf9b35301bf3._comment b/doc/todo/find__47__prefer_keys_by_file_extension_in_key/comment_1_fcf6f2c6ecf49930f4ddbf9b35301bf3._comment
new file mode 100644
index 0000000000..de97e81f7c
--- /dev/null
+++ b/doc/todo/find__47__prefer_keys_by_file_extension_in_key/comment_1_fcf6f2c6ecf49930f4ddbf9b35301bf3._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-07-06T13:47:31Z"
+ content="""
+I don't like the idea much. Keys with extensions are really a hack to work
+around the limitations of certian programs, and adding this feature would
+make it harder to deprecate them, which is a long term goal. Though
+admittedly not a likely one to be achieved entirely, it certianly seems possible
+right now for git-annex to eventually default to a non-extension backend..
+And adding this feature would work against that.
+
+But.. After recent changes, it would be perfectly possible for include= to match
+on filenames in the current branch when used with --all etc. I'll copy some
+thoughts on it from
+<https://git-annex.branchable.com/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/>:
+
+---
+
+I'm feeling a bit cautious about adding a preferred content expression for
+this brand new capability.
+
+And also unfortunately, it turned out not to be possible to prevent the
+associated files db from sometimes having stale filenames in it (see
+[[!commit c1b50282118520350d5328153fceedac2b8d8ed5]]). Which all current
+uses of the associated files db deal with by checking the list of
+associated files to see if all of them are in HEAD tree. A preferred
+content expression would also have to deal with that, and that risks
+slowing down evaluation of preferred content expressions generally.
+
+So I think it's best to not add a preferred content expression,
+at least until there's a use case and this has had
+some time to soak.
+
+---
+
+Although as far as slow down goes, that would only need to affect cases
+where --all/--key/--unused is used, and preferred content matches on 
+include=/exclude=. Which is a combination noone should be using now,
+since it doesn't match on anything. So a slow down is not a problem.
+
+When those options are not used, include=/exclude= could skip looking
+at the associated files db. Consider `git-annex get --auto .` -- If the
+preferred content expression matches foo and not bar, and they have the same 
+content, it will not get bar, but will get foo, which has the desired result.
+And it's ok for `git annex get --auto bar` to not get the content of foo;
+the user didn't request it. And in the case of `git-annex drop --auto bar`,
+the preferred content expression not matching bar doesn't matter, because
+dropping checks if other files using the content are preferred content
+and so would skip dropping bar in order not to drop foo.
+
+So this would only need a way for preferred content matching to know if
+an option like --all was used, and check the keys database then.
+I think it could probably just check for `providedFilePath == Nothing`
+"""]]
diff --git a/doc/todo/find__47__prefer_keys_by_file_extension_in_key/comment_2_751137f0fd1815adfef69bec6a2cbe22._comment b/doc/todo/find__47__prefer_keys_by_file_extension_in_key/comment_2_751137f0fd1815adfef69bec6a2cbe22._comment
new file mode 100644
index 0000000000..4baa182686
--- /dev/null
+++ b/doc/todo/find__47__prefer_keys_by_file_extension_in_key/comment_2_751137f0fd1815adfef69bec6a2cbe22._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="about keys with extensions"
+ date="2021-07-06T14:59:24Z"
+ content="""
+>It would be perfectly possible for include= to match on filenames in the current branch when used with --all etc
+
+I think the ability of `--all` to operate on all files regardless of branch is important.  I often have many branches, and have files on the current branch that I've overwritten but may want to revert.  It's useful to e.g. copy the content of all `*.bam` files ever created to a given S3 remote, or to generate a report of how much total space is used by content with different extensions.
+
+>Keys with extensions are really a hack to work around the limitations of certain programs
+
+Which still have them ;)  Worse, it's hard to know which do.  So please don't deprecate.   But also, even if started as a hack, letting keys encode metadata like file type -- and then efficiently matching on it -- is separately useful.
+
+"""]]
diff --git a/doc/todo/findkeys.mdwn b/doc/todo/findkeys.mdwn
new file mode 100644
index 0000000000..d6f688cae8
--- /dev/null
+++ b/doc/todo/findkeys.mdwn
@@ -0,0 +1,20 @@
+`git-annex findkeys` would be similar to `git-annex find`, but would find
+all keys in the repository, or all known keys.
+
+[[git-annex-find]] has a long comment section with users wanting some way
+to do this, but I am strongly of the opinion that `git-annex find` should
+list files, not keys, like `find(1)` does.
+--[[Joey]]
+
+findkeys could support --format like find, but without `${file}`, and
+--print0 and the json options. --batch does not seem very likely to be
+useful? The other options wouldn't apply to it, except for matching options
+like --in that can operate on keys.
+
+Like `git-annex find`, findkeys should default to listing only keys
+whose content is present. But when an option like --in=remote
+or --anything is used, it should, like find, not be limited to that.
+
+[[!tag projects/dandi]]
+
+> [[done]]! --[[Joey]]
diff --git a/doc/todo/findkeys/comment_1_da758b20bca40e0580526e52ea3e9a61._comment b/doc/todo/findkeys/comment_1_da758b20bca40e0580526e52ea3e9a61._comment
new file mode 100644
index 0000000000..fe50efadff
--- /dev/null
+++ b/doc/todo/findkeys/comment_1_da758b20bca40e0580526e52ea3e9a61._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2023-01-16T21:32:09Z"
+ content="""
+As it was hinted in the original [comment](http://git-annex.branchable.com/git-annex-find/#comment-531cc60d68272ab0e48c7f78242c1a95) -- needed for DANDI project to ensure thorough backup of files.
+"""]]
diff --git a/doc/todo/finish_sync_content_transition.mdwn b/doc/todo/finish_sync_content_transition.mdwn
new file mode 100644
index 0000000000..55994a2915
--- /dev/null
+++ b/doc/todo/finish_sync_content_transition.mdwn
@@ -0,0 +1,14 @@
+This transition is from `git-annex sync` needing `--content` to send
+content to repositories that have preferred content configured, to sending
+content by default to such repositories.
+
+There should be no change in behavior with repositories that don't have
+preferred content configured. `sync` without `--content` won't populate them
+since that would be a surprising thing and a warning based transition was
+judged by the community to be not sufficient to avoid that possible large
+surprise. (See [[bugs/Changing_sync_to_include_content_breaks_UX]])
+
+A warning was added in August 2023 when it's run in a way that will change
+behavior. It would be good to wait until all git-annex users have gotten
+the version with the warning, and used it for a while, before finishing the
+transition.
diff --git a/doc/todo/force_star_topology_on_a_repository.mdwn b/doc/todo/force_star_topology_on_a_repository.mdwn
new file mode 100644
index 0000000000..6398906343
--- /dev/null
+++ b/doc/todo/force_star_topology_on_a_repository.mdwn
@@ -0,0 +1,27 @@
+# What is a star-topology
+
+Basically having only one remote with `private = false` (the default) setting and having all other machines with `private = true`.
+
+In this setup, all users and clones have to pull from the central `private = false` remote, and they can't get/copy/sync directly between each other.
+
+In exchange, the situation is easy to understand, easy to explain to non-technical people and easy to automate in a team where people who are not interested in git also have to participate.  Also, the content of the `git-annex` branch stays very simple and therefore gives way to easier debugging/hacking.
+
+In some sense, you can call this git-annex stupidified back to git-lfs levels, but if you think about it, it's still a lot better, e.g. you can manage partial clones easily (by just not downloading the files that you are not interested in with `git annex get`), and you also get the symlinks way of life without any git filters, which is honestly simply better than git-lfs.
+
+# Difficulties implementing a star-topology
+
+The only problem with this, is that it's hard to enforce it, because to keep your `git-annex` branch completely clean even in face of novice users, you have to ensure that EVERYBODY, ALWAYS, ON ALL THEIR MACHINES issue a `git config annex.private true` command first, before starting to play around with git-annex based on tutorials/forums/email-threads/etc.  In practice, this is not possible.
+
+# Feature request
+
+I would like to have an `uuid-allowlist.log` file in the root folder of the `git-annex` branch, that if exists, is always read during startup of `git-annex` for any operation that operates on the branch, and every line contains exactly one UUID.
+
+If any output file is written anywhere into the `git-annex` branch (trusted.log, uuid.log, remote.log, and also every file, e.g. xxx/yyy/SHA256E-...), this list is always consulted and if during writing the file `git-annex` wants to write a non-allowlisted UUID for any reason, then it immediately stops with an error message, without committing to the branch.  Of course, if we can make the check sooner, e.g. before adding it to the index of annex, that is even better.
+
+This of course should work for all SSH git remotes, but also for all special remotes, if the UUID is allowlisted.
+
+If there is no `uuid-allowlist.log` file found, then nothing should change compared to the current implementation.
+
+# UI
+
+Regarding the UI, I don't care too much, for me it's even good enough if it's implemented as an expert feature, and when I start the repository, I have to create the `git-annex` branch by hand the first time and add this file.
diff --git a/doc/todo/force_star_topology_on_a_repository/comment_1_cffe5ae2b85022ac9f58ce668ec9bf97._comment b/doc/todo/force_star_topology_on_a_repository/comment_1_cffe5ae2b85022ac9f58ce668ec9bf97._comment
new file mode 100644
index 0000000000..c032ec2125
--- /dev/null
+++ b/doc/todo/force_star_topology_on_a_repository/comment_1_cffe5ae2b85022ac9f58ce668ec9bf97._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-03-10T17:11:59Z"
+ content="""
+It seems to me that making annex.private a global
+configuration that can be set with `git-annex config` and overridden
+locally with .git/config on the repository you want to record
+to the git-annex branch would have the same effects.
+
+While a user could override it in their clone with .git/config, 
+they could also use a version of git-annex that ignores your
+uuid-allowlist.log.
+
+Also, uuid-allowlist.log would imply that merging two git-annex
+branches could fail, if one of them referred to uuids that are not
+allowed in another one. Since git-annex does such merges in the backend,
+that would mean that git-annex could just start failing without any
+apparent reason why or anything for the user to do to fix it. I would
+not want to support the bug reports that would result from that.
+"""]]
diff --git a/doc/todo/force_star_topology_on_a_repository/comment_2_6e735205024588497a116ce9e7e621a9._comment b/doc/todo/force_star_topology_on_a_repository/comment_2_6e735205024588497a116ce9e7e621a9._comment
new file mode 100644
index 0000000000..e7038489dc
--- /dev/null
+++ b/doc/todo/force_star_topology_on_a_repository/comment_2_6e735205024588497a116ce9e7e621a9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="ErrGe"
+ avatar="http://cdn.libravatar.org/avatar/37423d3bfd69af2cda23d194ec74f991"
+ subject="comment 2"
+ date="2022-03-11T02:23:20Z"
+ content="""
+Thank you for reading and replying to my feature request.
+
+I agree with most of what you have said, and I agree that making `annex.private` `git-annex config`urable is 99% of my feature request.
+
+I wrote the rest of the text, because I actually had a case, while testing this star topology thing where an uuid crept into the git-annex branch and it was coming from testing a special remote with rclone and not being careful enough with it.  So, I think the global `annex.private` variable somehow also has to support special remotes and then there has to be a way to opt-out the one special remote, that is the real center of the star topology.
+"""]]
diff --git a/doc/todo/force_star_topology_on_a_repository/comment_3_154614345d2b8f4260c88e9061bf4255._comment b/doc/todo/force_star_topology_on_a_repository/comment_3_154614345d2b8f4260c88e9061bf4255._comment
new file mode 100644
index 0000000000..c5807bcf11
--- /dev/null
+++ b/doc/todo/force_star_topology_on_a_repository/comment_3_154614345d2b8f4260c88e9061bf4255._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ErrGe"
+ avatar="http://cdn.libravatar.org/avatar/37423d3bfd69af2cda23d194ec74f991"
+ subject="comment 3"
+ date="2022-03-11T02:26:56Z"
+ content="""
+Just one addition to my previous comment: I agree with the notion, that this is under no circumstances a security or a kindergarten feature.  So if someone intentionally overrides it, then of course, that's the fact of life, and I have to handle those team members in other social ways, not via technological overengineering.  So if the final proposal provides a way to protect against accidental git clones and accidental special remotes both, then I'm good.  It only has to protect against accidents, not against malice.
+"""]]
diff --git a/doc/todo/force_star_topology_on_a_repository/comment_4_a722bce9ea8c94864657415395eadb43._comment b/doc/todo/force_star_topology_on_a_repository/comment_4_a722bce9ea8c94864657415395eadb43._comment
new file mode 100644
index 0000000000..bd4ba737f3
--- /dev/null
+++ b/doc/todo/force_star_topology_on_a_repository/comment_4_a722bce9ea8c94864657415395eadb43._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-03-29T18:06:51Z"
+ content="""
+`git-annex initremote --private` is the equivilant of annex.private for a
+special remote, and sets remote.name.annex-private.
+
+And remote.name.annex-private can also be set to avoid recording anything
+about a git-annex remote.
+
+Setting annex.private with `git config` does not affect the remotes.
+Which for many use cases of annex.private, is a good thing.
+
+`git-annex config` settings should have the same effect as if the 
+corresponding `git config` were set. So `git-annex config` of annex.private
+is not quite the right thing, since that would not set
+remote.name.annex-private.
+
+So, I think you were somewhat on the right track, that there needs to be a
+list of uuids of repositories that are not private. And then all other
+repositories would behave the same as if annex.private were set for them,
+when git-annex is running on them or using them as a remote.
+
+Concretely, this could look like `git-annex config --set annex.privateexcept "uuid1 uuid2"`
+
+Implementation would just involve the two places that currently
+check annexPrivateRepos also checking that.
+
+One small problem with this idea is, if you want to add a new non-private
+repository or special remote after setting that git-annex config, you would
+need to run `git-annex config` to add it to the list first. Otherwise,
+information about it won't get recorded publically when it's initialized.
+So you would need to generate a uuid by hand, then update the list, then
+run `git-annex reinit` with that uuid, or `git-annex initremote` with the
+`uuid=` parameter.
+"""]]
diff --git a/doc/todo/force_star_topology_on_a_repository/comment_5_60d832d97923d3aac047dd525dc8df12._comment b/doc/todo/force_star_topology_on_a_repository/comment_5_60d832d97923d3aac047dd525dc8df12._comment
new file mode 100644
index 0000000000..4fecff3366
--- /dev/null
+++ b/doc/todo/force_star_topology_on_a_repository/comment_5_60d832d97923d3aac047dd525dc8df12._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-03-29T18:43:11Z"
+ content="""
+What happens if someone sets this git-annex config, but the repo is also
+used by someone else, who does not want to honor that, and wants to have
+their own group of git-annex repos that work together as usual? 
+
+This is a reasonable difference of opinion to have, and this kind of
+disagreement needs to be considered when adding a `git-annex config`
+setting.
+
+Usually, `git-annex config` settings can be overridden by
+`git config`. So there would need to be a annex.privateexcept
+git config as well.
+"""]]
diff --git a/doc/todo/force_star_topology_on_a_repository/comment_6_8bb1f37233055c53d98c73fed4224b50._comment b/doc/todo/force_star_topology_on_a_repository/comment_6_8bb1f37233055c53d98c73fed4224b50._comment
new file mode 100644
index 0000000000..bda7d5421b
--- /dev/null
+++ b/doc/todo/force_star_topology_on_a_repository/comment_6_8bb1f37233055c53d98c73fed4224b50._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-03-29T21:23:09Z"
+ content="""
+An alternative way to get the same result would be for your centralized git
+repository to have a hook that filters unwanted uuids out of git-annex
+branch pushes.
+
+To do the filtering, you could use git-annex filter-branch.
+
+	git-annex filter-branch --all --include-key-information-for=$uuid \
+		--include-global-config --include-repo-config-for=$uuid
+
+That reads the current git-annex branch and outputs the hash of a filtered
+commit.
+
+For example, as a post-receive hook:
+
+	#!/bin/sh
+	uuid=06ba602a-afa8-11ec-a6b9-87c2c2ae9296
+	ref=$(git-annex filter-branch --all --include-key-information-for=$uuid \
+		--include-global-config --include-repo-config-for=$uuid)
+	git update-ref refs/heads/git-annex $ref
+	# Necessary since the git-annex branch has been changed
+	rm .git/annex/index
+
+This post-receive hook is suboptimal because there is a period of time
+before it finishes filtering where a pull will see the unfiltered git-annex
+branch. Although maybe that would be ok, since a later push of that
+information back would get filtered again.
+
+It would be better to use a git hook that let the information be filtered
+before it became active. Looking at githooks(5), the proc-receive hook may
+be able to do that. Not sure. To be used by such a hook, git-annex
+filter-branch would still need to see the information in a git-annex
+branch, so it might need to be run in a lightweight clone of the
+repository. Or, it might be possible to improve git-annex filter-branch
+to be able to filter a ref other than the git-annex branch.
+"""]]
diff --git a/doc/todo/force_star_topology_on_a_repository/comment_7_6b08f09f690f7791f59cb90db01c4cf0._comment b/doc/todo/force_star_topology_on_a_repository/comment_7_6b08f09f690f7791f59cb90db01c4cf0._comment
new file mode 100644
index 0000000000..bc2c785d26
--- /dev/null
+++ b/doc/todo/force_star_topology_on_a_repository/comment_7_6b08f09f690f7791f59cb90db01c4cf0._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-03-29T21:49:26Z"
+ content="""
+But.. Using filter-branch like that seems like it would lead to a series of
+commits when no changes are really being made. 
+
+Consider a clone that has a git-annex branch with commit A.
+It pushes it to origin, which runs it through filter-branch,
+yeilding B. Then the clone pulls B, and git-annex merges B into A,
+yielding A'. If A contained nothing that got filtered out, A' and A
+have the same tree, but in any case they will be different commits.
+Then A' gets pushed, yielding B', and the clone pulls B', resulting in A'',
+and so on.
+
+A solution to that would be to check, after filtering, if the tree
+sha is the same as the local git-annex branch currently has, or had
+at a point in the recent past. If so, it can avoid updating the git-annex 
+branch at all, since no new information was received. 
+
+I think that would work both when there was nothing that got filtered out,
+and when there was. The only problem with it might be that since
+origin/git-annex would not be updated after a push, a subsequent push would
+waste a little bandwidth re-sending the local git-annex branch again.
+"""]]
diff --git a/doc/todo/force_star_topology_on_a_repository/comment_8_f840a405028df2630a7c8eac5091833f._comment b/doc/todo/force_star_topology_on_a_repository/comment_8_f840a405028df2630a7c8eac5091833f._comment
new file mode 100644
index 0000000000..d54aa94285
--- /dev/null
+++ b/doc/todo/force_star_topology_on_a_repository/comment_8_f840a405028df2630a7c8eac5091833f._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="ErrGe"
+ avatar="http://cdn.libravatar.org/avatar/37423d3bfd69af2cda23d194ec74f991"
+ subject="hook idea implementation is cool, but usage is not so simple for the enduser"
+ date="2024-04-18T01:17:02Z"
+ content="""
+Sorry for resurrecting this after 2 years, I somehow forgot this discussion was ongoing.
+
+So, first of all, thank you so much for taking the time to writing up a very cool server side solution for the problem.  Do I understand your proposal correctly, that basically on the server we would always store a git-annex rewritten branch as if it was correctly written by the client, no matter what the clients do on their own in their own git-annex branches, right?
+
+And since all the merging in git-annex is line based, this constant rewrite wouldn't confuse the clients when they `git fetch --all` + `git annex merge`?  Wouldn't the merge commits in `gitk git-annex` be very weird to understand?
+
+So what I don't understand, is that if we do this on the central server side, then yes, the rewrite on the server is good, but when the offending client does a `git fetch` + `git annex merge`, it will create a merge commit with 2 parents.  Will we also straighten that out automatically and delete the \"stupid\" side on the next push?  Doesn't this mean, that debugging just becomes more confusing and this client will create longer and longer side branches on its graphical branch view of `gitk git-annex`?
+
+Let me reflect back to your \"comment 5\", where you asked the very valid question of what to do in case of difference of opinions.  I think the correct solution is to implement the override feature (in .git/config, as you said), and let it completely happen.  If the only way for unwanted UUIDs to appear in my central repo is for someone to use this extra feature, I'm OK with that.  I want to prevent accidents, and I certainly don't want to prevent expert power-users achieving their goals when needed, so local override (even if the end result is pushed back), is 100% fine.
+
+Now, that I'm thinking about this as a \"reasonable difference of opinion to have\", an interesting \"solution\" comes to mind, that opens up of course a very big discussion: why in the design of git-annex there is only ONE AND ONLY git-annex branch?  Git has orphan branches, and it would be legit to say, that different group of people working in a repo, have different opinion of \"view of the annex\", e.g. they think different repos (or special remotes) are important or unimportant for them. I mention this question not really seriously as a proposal to redesign, but I'm sure that you had this idea sometime in the past, and if you have some insight or revelations, I'd be happy to read it.
+"""]]
diff --git a/doc/todo/forget_dead_keys.mdwn b/doc/todo/forget_dead_keys.mdwn
new file mode 100644
index 0000000000..c9447666ae
--- /dev/null
+++ b/doc/todo/forget_dead_keys.mdwn
@@ -0,0 +1,25 @@
+Make git-annex forget --drop-dead also remove log files for keys that have
+been marked as dead.
+
+This would have the benefit of reducing the size of the git-annex branch. 
+Also it would eliminate mention of the key in the git-annex branch's
+history. 
+
+Although whether it would actually delete *all* mention of a key is a bit
+hard to guarantee. Can remove all the log files that are specific to a key,
+like presence and metadata and chunks and remote state. But, the export.log
+refers to trees, and somewhere in a tree there could be a reference to a
+dead key. 
+
+Eg, if a file was exported to a remote, and then its key marked dead, the
+file could still be on the remote, and the export.log needs to keep its
+reference to that tree, until some other tree is exported that deletes that
+file. So this is a not very likely, but possible, way for the git-annex
+branch to still mention a dead key after --drop-dead. Could rewrite the
+tree as well, but now it's getting complicated indeed.
+
+> Let's leave out the idea that all references to the dead key get
+> scrubbed from the branch. In any case a key is probably referred to in
+> the master branch too.
+> 
+> It'd still be useful to implement this, just to reduce branch size.
diff --git a/doc/todo/forget_dead_keys/comment_1_e4c7db734087dc4c2f6b86bb774136fd._comment b/doc/todo/forget_dead_keys/comment_1_e4c7db734087dc4c2f6b86bb774136fd._comment
new file mode 100644
index 0000000000..49daf1a220
--- /dev/null
+++ b/doc/todo/forget_dead_keys/comment_1_e4c7db734087dc4c2f6b86bb774136fd._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-04-05T18:39:44Z"
+ content="""
+Took a look at implementing this, and found a challenging problem.
+A TransitionCalculator for this would need a way to check if a given key is
+dead. Which means that the TransitionCalculator would need to run in Annex,
+and read the location log for the key in order to decide whether to keep
+a log file associated with that key.
+
+That would make this transition be a lot slower to calculate than
+transitions are now -- currently transitions only need the content of the
+file they are acting on, and information that can be looked up before
+starting like the TrustMap. This new transition would be doing a lot of
+git-annex branch queries.
+
+The other problem is that, if a key is dead, the location log for it ought
+to be removed by the transition. But then calculating transitions for other
+log files associated with that key would not be able to read the location
+log to know it's dead. 
+
+Just caching in memory what dead keys have had their location logs removed
+would not necessarily be enough either -- if a clone added information to a
+log file associated with a dead key, then on merge from that clone, if
+the transition is re-run it would no longer know that the key was dead.
+"""]]
diff --git a/doc/todo/free_space_checking_for_local_special_remotes.mdwn b/doc/todo/free_space_checking_for_local_special_remotes.mdwn
new file mode 100644
index 0000000000..0fd2eac595
--- /dev/null
+++ b/doc/todo/free_space_checking_for_local_special_remotes.mdwn
@@ -0,0 +1,4 @@
+Should be possible to configure an annex.diskreserve setting for local
+special remotes, such as a directory special remote or possibly a bup
+special remote. (Although bup's deltas will make storing some versions of
+files take less space than git-annex would have to assume it would take.)
diff --git a/doc/todo/free_space_checking_for_local_special_remotes/comment_1_47c254cec58cbbb3ea84c93ef8282f01._comment b/doc/todo/free_space_checking_for_local_special_remotes/comment_1_47c254cec58cbbb3ea84c93ef8282f01._comment
new file mode 100644
index 0000000000..00c4c56254
--- /dev/null
+++ b/doc/todo/free_space_checking_for_local_special_remotes/comment_1_47c254cec58cbbb3ea84c93ef8282f01._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.235"
+ subject="comment 1"
+ date="2013-07-11T16:19:26Z"
+ content="""
+Directory special remotes do already honor annex.diskreserve, it turns out. Let's repurpose this bug to be about adding a per-remote configuration, in case the main annex.diskreserve is not appropriate.
+"""]]
diff --git a/doc/todo/fsck_scrub.mdwn b/doc/todo/fsck_scrub.mdwn
new file mode 100644
index 0000000000..7f5f3c0934
--- /dev/null
+++ b/doc/todo/fsck_scrub.mdwn
@@ -0,0 +1,18 @@
+When a git-annex repository is on eg, a zfs or btrfs filesystem, the
+filesystem has built-in checksum verification of file. So a "scrub"
+operation that just reads all annexed files can detect when a file has
+gotten corrupt.
+
+This could be an enhancement to git-annex fsck, or a separate command.
+
+Note that this could detect corruption of files whose key does not
+contain a checksum.
+
+Since fsck reads the file content anyway when checksumming, 
+the enhancement could be an option to scrub files that don't use 
+checksums.
+
+It would make sense to move a file that is detected as corrupt to
+.git/annex/bad/ the same as fsck does.
+
+(Idea from Timothy Sanders.)
diff --git a/doc/todo/fsverify.mdwn b/doc/todo/fsverify.mdwn
new file mode 100644
index 0000000000..4c16044172
--- /dev/null
+++ b/doc/todo/fsverify.mdwn
@@ -0,0 +1,53 @@
+git-annex could use linux's [fsverify](https://www.kernel.org/doc/html/latest/filesystems/fsverity.html)
+feature as an alternative to hashing and verifying hashes of files itself.
+
+Benefits would include:
+
+* Any read of an annexed file that uses fsverify would check the blocks
+  that are read, and the read would fail if the file had gotten corrupted.
+* Avoiding any theoretical cases where `git-annex add` is hashing a file
+  and something modifies it, causing the file to be added with the wrong
+  hash (which `git-annex fsck` will later detect). The
+  `FS_IOC_ENABLE_VERITY` ioctl prevents anything else from possibly
+  modifying the file while it's hashing it.
+* Slightly faster git-annex fsck, because it would not need to hash
+  verified files. It would suffice to read the file, and if it all read
+  successfully, it's valid!
+
+Since fsverify uses a merkle tree, its hashes are not the same as simply
+using SHA on the whole file. So for git-annex to use the fsverify hash as
+the key for the file, it would need to be a separate type of key. That's a
+bit problimatic because then git-annex would need a way to verify that
+merkle hash itself on systems that do not support fsverify. Also, for large
+files, the merkle tree can get relatively large (1/127th the size of the
+file the docs say). So with a terabyte of annexed files, that's gigabytes
+of merkle hashes, which seems too large to want to stote them in git.
+
+Alternatively, git-annex could hash as usual for the key. This would mean
+that `git-annex add` would hash a file twice, once for the git-annex key
+and the second time calling the `FS_IOC_ENABLE_VERITY` ioctl. Slower, but
+perhaps these could parallelize and only use 2x the CPU or so.
+
+Since fsverified files are readonly, this would only be useful for locked
+files. Unlocking a file would need to either remove the fsverify from it
+(if possible?) or copy it.
+
+Using fsverify in this way would not work if the sysctl 
+`fs.verity.require_signatures` is set, because the annexed files would
+not have signatures.
+
+---
+
+Putting all this together, fsverify is not too compelling for use by
+git-annex. A user who wants the verification on all reads of a file can
+just call `FS_IOC_ENABLE_VERITY` on it themselves after git-annex add.
+The annex.freezecontent-command hook could be used to to that.
+
+Then the only benefit of supporting it in git-annex is that perhaps `git-annex
+add` could parallize enabling verification with checksumming, or avoid its
+own checksumming, and so run faster than if a hook were used to enable
+fsverify. And fsck would use less CPU. Is that worth complicating git-annex for?
+--[[Joey]]
+
+> After investigating that, I currently don't think it's compelling, so I'm
+> gonna close this. [[done]] --[[Joey]]
diff --git a/doc/todo/generic_readonly_http_remote/comment_1_5fcd23950ed5409e52d7954abf71afa9._comment b/doc/todo/generic_readonly_http_remote/comment_1_5fcd23950ed5409e52d7954abf71afa9._comment
new file mode 100644
index 0000000000..1199d859ef
--- /dev/null
+++ b/doc/todo/generic_readonly_http_remote/comment_1_5fcd23950ed5409e52d7954abf71afa9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-07-01T19:05:44Z"
+ content="""
+This overlaps with [[publicurl_config_for_all_special_remotes]]
+but I think is a better approach, at least for most special remotes that is
+could support.
+"""]]
diff --git a/doc/todo/generic_readonly_http_remote/comment_2_c81b458a8ee0f15950adbd32dd168972._comment b/doc/todo/generic_readonly_http_remote/comment_2_c81b458a8ee0f15950adbd32dd168972._comment
new file mode 100644
index 0000000000..8326ad851c
--- /dev/null
+++ b/doc/todo/generic_readonly_http_remote/comment_2_c81b458a8ee0f15950adbd32dd168972._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-07-02T17:45:18Z"
+ content="""
+The publicurl config approach is more general; it lets almost any special
+remote whose data can be published over http be supported.
+
+So it can support a eg, a special remote that mangles key names in some way,
+or uses an unusual directory hashing structure. Or even a special remote like
+git-lfs that uses a different key than the annex key for storage and maps
+between them.
+
+By contrast, the generic special remote's approach can't support the
+extreme edge cases, and is more ad-hoc, trying a few common path forms
+that almost everything uses. But in its favor:
+
+* --sameas already relies on special remotes using the same path form, and so
+  it seems we're going to end up documenting which special remotes are
+  compatable. That information could even be encoded in the remotes and
+  git-annex sanity check uses of --sameas. 
+
+  Perhaps --sameas is a slippery slope and this should not continue down it,
+  but alternatively perhaps by encouraging compatability of path forms,
+  it's a good thing. Although there are good reasons for different path
+  forms. <https://github.com/DanielDent/git-annex-remote-rclone>
+  has a nice overview of the common paths forms.
+
+* If people start using some other protocol (ipfs, or ftp, or gopher, or ...),
+  special remotes could also have their data published over it. It's much
+  cleaner to just add a readonly generic ipfs special remote than, than
+  it is to add a ipfs config to every remote along with the publicurl config.
+
+  (Even if the implementation of the publicurl config and ipfs config
+  is a Remote -> Remote transformer, there's cognitive load in
+  having things like the directory special remote having a publicurl
+  config, and the prospect of lots of configs for different protocols
+  suggests this would be a slippery slope too.)
+
+* External special remotes could be published over http and be used by
+  this new special remote w/o needing a protocol extension and w/o
+  needing the external special remote program to be installed at all.
+  The latter especially is important if this is intended for publishing
+  git-annex repositories.
+
+Of course, nothing is stopping us from mixing the two. S3 and git-lfs
+already support anonymous http access.
+"""]]
diff --git a/doc/todo/generic_readonly_http_remote/comment_3_6d95fc858ca780f087c48e4a6a4ab25b._comment b/doc/todo/generic_readonly_http_remote/comment_3_6d95fc858ca780f087c48e4a6a4ab25b._comment
new file mode 100644
index 0000000000..5126bcb91b
--- /dev/null
+++ b/doc/todo/generic_readonly_http_remote/comment_3_6d95fc858ca780f087c48e4a6a4ab25b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="map2url?"
+ date="2020-07-02T20:41:15Z"
+ content="""
+> readonly access of other special remotes whose data stores are exposed via http.
+...
+> It's much cleaner to just add a readonly generic ipfs special remote than, than it is to add a ipfs config to every remote along with the publicurl config.
+
+> The publicurl config approach is more general; it lets almost any special remote whose data can be published over http be supported.
+
+Even if currently may be only supports, http for the protocol, isn't it more general - i.e. \"map2url\" functionality which then could fetch data via any protocol (http, https, ftp, and potentially some URLs supported by external special remotes).  My point is that I do not see why it needs to be \"http\" special remote, and not some \"map2url\"?
+"""]]
diff --git a/doc/todo/generic_readonly_http_remote/comment_4_551bbaf8f22add6ad1e2774e76a1d078._comment b/doc/todo/generic_readonly_http_remote/comment_4_551bbaf8f22add6ad1e2774e76a1d078._comment
new file mode 100644
index 0000000000..e0b4be0622
--- /dev/null
+++ b/doc/todo/generic_readonly_http_remote/comment_4_551bbaf8f22add6ad1e2774e76a1d078._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: map2url?"""
+ date="2020-07-03T00:07:25Z"
+ content="""
+[[publicurl_config_for_all_special_remotes]] talks about adding an API
+for querying a remote for such a mapping.
+
+But each protocol still would need its own configuration of the base url,
+etc.
+
+(Also potentially its own authentication information come to think of it.)
+"""]]
diff --git a/doc/todo/generic_readonly_http_remote/comment_5_bfbec043d803ff1aa649f2661f6918f4._comment b/doc/todo/generic_readonly_http_remote/comment_5_bfbec043d803ff1aa649f2661f6918f4._comment
new file mode 100644
index 0000000000..7a56cba643
--- /dev/null
+++ b/doc/todo/generic_readonly_http_remote/comment_5_bfbec043d803ff1aa649f2661f6918f4._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-09-01T19:00:05Z"
+ content="""
+I'm implementing this with an automatic learning of the layout that a
+special remote uses. 
+
+It looks like it will probably be sufficiently fast
+for it to remember only for the duration of the command, although it would
+be possible to cache what it's learned in .git/config or something.
+
+Usually, the learning will add 6 extra http requests to learn 
+the most unlikely layout (hashDirMixed with 1 hash level, which I doubt
+anything actually uses). Since the first file it tries to access is almost
+certainly present in the special remote, it will then learn the layout and
+keep using it with no added overhead.
+
+The unusual case would be if a lot of files are not present in the
+remote any longer. Then it will fail to learn, on each file, and so will
+always make 6 extra http requests per file processed. (Reusing the same
+http connection at least.) This seems unusual enough to not worry about
+remembering what it's learned for longer than a single run, or making the
+layout explicitly configurable. Content would have to be dropped from the
+other special remote and the git-annex branch not be synced up for it to
+happen.
+"""]]
diff --git a/doc/todo/get_--batch.mdwn b/doc/todo/get_--batch.mdwn
new file mode 100644
index 0000000000..750b328174
--- /dev/null
+++ b/doc/todo/get_--batch.mdwn
@@ -0,0 +1,8 @@
+It seems that it would be tremendously useful, see e.g. our [datalad install](https://github.com/datalad/datalad/issues/553)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] although the output while getting a file is not
+> machine-parseable. So, I made --json also work for get, but enabling
+> json output disables any progress display. --[[Joey]]
diff --git a/doc/todo/git-annex-addunused-historical.mdwn b/doc/todo/git-annex-addunused-historical.mdwn
new file mode 100644
index 0000000000..17e66c2b2f
--- /dev/null
+++ b/doc/todo/git-annex-addunused-historical.mdwn
@@ -0,0 +1,7 @@
+`git-annex addunused` could have a --historical option that adds back to
+the last-seen filename, like whereused does.
+
+Something would need to be done to handle the case where several unused
+keys use the same filename, or a file by that name already exists. Probably
+the simplest thing would be to add the key to the end of the filename.
+--[[Joey]]
diff --git a/doc/todo/git-annex-cat.mdwn b/doc/todo/git-annex-cat.mdwn
new file mode 100644
index 0000000000..e21fd83062
--- /dev/null
+++ b/doc/todo/git-annex-cat.mdwn
@@ -0,0 +1,7 @@
+It would be useful to have a [[`git-annex-cat`|forum/Is_there_a___34__git_annex_cat-file__34___type_command__63__/]] command that outputs the contents of an annexed file without storing it in the annex.  This [[can be faster|OPT: "bundle" get + check (of checksum) in a single operation]] than `git-annex-get` followed by `cat`, even if file is already present.  It avoids some failure modes of `git-annex-get` (like running out of local space, or contending for locks).  It supports a common use case of just needing a file for some operation, without needing to remember to drop it later.  It could be used to implement a web server or FUSE filesystem that serves git-annex repo files on demand.
+
+If file is not present, or `remote.here.cost` is higher than `remote.someremote.cost` where file is present, `someremote` would get a `TRANSFER` request where the `FILE` argument is a named pipe, and a `cat` of that named pipe would be started.
+
+If file is not annexed, for uniformity `git-annex-cat file` would just call `cat file`.
+
+[[!tag needsthought]]
diff --git a/doc/todo/git-annex-cat/comment_1_a5da8264c2d662e96802535820cb2249._comment b/doc/todo/git-annex-cat/comment_1_a5da8264c2d662e96802535820cb2249._comment
new file mode 100644
index 0000000000..03d33376d6
--- /dev/null
+++ b/doc/todo/git-annex-cat/comment_1_a5da8264c2d662e96802535820cb2249._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Would be useful"
+ date="2019-12-17T09:08:08Z"
+ content="""
+A `git annex cat` would be useful for the very web server purpose you describe (WIP at https://gitlab.com/chrysn/annex-to-web, though I'm not sure it's going anywhere).
+
+Unlike `git annex inprogress` that I (will) use for a workaround, this could take a `--skip` argument that usually just seeks into the file.
+If the data is served from a remote that allows seeking access (eg. IPFS),
+then that access could be priorized and that part downloaded first.
+(Implementing this would require another tmp pool for sparse files as they couldn't go with the `git annex inprogress` files for there is the expectation that those would grow to completion,
+but anyway this would be an entry point for such a feature if it is ever added).
+"""]]
diff --git a/doc/todo/git-annex-cat/comment_2_a43a3568e48e6b5e93998bc473178d5c._comment b/doc/todo/git-annex-cat/comment_2_a43a3568e48e6b5e93998bc473178d5c._comment
new file mode 100644
index 0000000000..346e8b785e
--- /dev/null
+++ b/doc/todo/git-annex-cat/comment_2_a43a3568e48e6b5e93998bc473178d5c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-12-18T17:49:47Z"
+ content="""
+git-annex's API for getting object content from remotes involve a
+destination file that is written to. That limits the efficiency of such a
+command. There would need to be a separate API for streaming, which some
+remotes will not have any hope of supporting.
+"""]]
diff --git a/doc/todo/git-annex-cat/comment_3_347a33a4a77fd385ab8f3551138b75e1._comment b/doc/todo/git-annex-cat/comment_3_347a33a4a77fd385ab8f3551138b75e1._comment
new file mode 100644
index 0000000000..8c5929974c
--- /dev/null
+++ b/doc/todo/git-annex-cat/comment_3_347a33a4a77fd385ab8f3551138b75e1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="named pipes as destination files"
+ date="2019-12-18T18:41:57Z"
+ content="""
+\"getting object content from remotes involve a destination file that is written to\" -- what happens if git-annex makes a named pipe, and passes that as the destination file name to the remote?
+"""]]
diff --git a/doc/todo/git-annex-cat/comment_4_8708bf0aef0025e2ed1a8b9d2a7f0112._comment b/doc/todo/git-annex-cat/comment_4_8708bf0aef0025e2ed1a8b9d2a7f0112._comment
new file mode 100644
index 0000000000..7c602eb537
--- /dev/null
+++ b/doc/todo/git-annex-cat/comment_4_8708bf0aef0025e2ed1a8b9d2a7f0112._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-01-01T18:44:37Z"
+ content="""
+@Ilya_Shlyakhter, I'd assume:
+
+* some remotes would write to the named pipe
+* some remotes would overwrite it with a file
+* some remotes would open it, try to seek around as they do non-sequential
+  recieves, and hang or something
+* some remotes would maybe open and write to it, but would no longer be
+  able to resume interrupted transfers, since they would I guess see its
+  size as 0
+"""]]
diff --git a/doc/todo/git-annex-cat/comment_5_f78a6a136610f3fca7a02a3af9c19e25._comment b/doc/todo/git-annex-cat/comment_5_f78a6a136610f3fca7a02a3af9c19e25._comment
new file mode 100644
index 0000000000..8929fb4c5d
--- /dev/null
+++ b/doc/todo/git-annex-cat/comment_5_f78a6a136610f3fca7a02a3af9c19e25._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="re: git-annex-cat"
+ date="2020-07-09T01:06:37Z"
+ content="""
+\"There would need to be a separate API for streaming, which some remotes will not have any hope of supporting\" -- there could be a default implementation using the current protocol (`TRANSFER RETRIEVE` to tempfile then `cat` and `rm`), which some remotes could override with a true streaming implementation.
+
+\"(1) some remotes would write to the named pipe; (2) some remotes would overwrite it with a file; (3) some remotes would open it, try to seek around as they do non-sequential recieves, and hang or something; (3) some remotes would maybe open and write to it, but would no longer be able to resume interrupted transfers, since they would I guess see its size as 0\" -- there could be a config flag to tell git-annex to assume that a given (legacy) remote does (1), at user's own risk.  Am I wrong to think (1) holds for most legacy remotes?
+ 
+"""]]
diff --git a/doc/todo/git-annex-export_--from_option.mdwn b/doc/todo/git-annex-export_--from_option.mdwn
new file mode 100644
index 0000000000..372c3c8492
--- /dev/null
+++ b/doc/todo/git-annex-export_--from_option.mdwn
@@ -0,0 +1,10 @@
+I just wanted to have a way to manage data copying / syncing between a fileserver and my android phone. So I pushed some files on my fileserver into a git remote and added the files with the annex subcommands then cloned the git tree from my workstation which is connected to my smartphone.
+
+Now I followed the documentation about the special remote adb and created that remote with the initremote command. When I then export I get (not available) failed errors.
+
+Which is caused by the fact that I didn't have checked out the files on my workstation. I don't need the files on this pc so it would be stupid to checkout partially huge files there or in other words I don't need the files at that place, I don't get why the export command not has a --from option where it can get the files?
+
+Is there a reason that does not exist and if so what would be a way to do sending files to the android device without ssh-ing into my server?
+
+[[!tag confirmed]]
+[[!tag projects/datalad/potential]]
diff --git a/doc/todo/git-annex-export_--from_option/comment_1_10f107aa0094d5ee4886878f5b1aaf06._comment b/doc/todo/git-annex-export_--from_option/comment_1_10f107aa0094d5ee4886878f5b1aaf06._comment
new file mode 100644
index 0000000000..2f536eacde
--- /dev/null
+++ b/doc/todo/git-annex-export_--from_option/comment_1_10f107aa0094d5ee4886878f5b1aaf06._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-11-19T16:52:00Z"
+ content="""
+`git annex export --from` would be basically the same as
+[[transitive_transfers]] and the comments there detail
+the problems with trying to support that.
+
+What you can do is download the files onto the computer that is connected
+to the phone, export them to the phone, and then drop the files from the
+computer.
+"""]]
diff --git a/doc/todo/git-annex-export_--from_option/comment_2_72e7dc2a6b3cec21c941a5f7a2914050._comment b/doc/todo/git-annex-export_--from_option/comment_2_72e7dc2a6b3cec21c941a5f7a2914050._comment
new file mode 100644
index 0000000000..cc429a9264
--- /dev/null
+++ b/doc/todo/git-annex-export_--from_option/comment_2_72e7dc2a6b3cec21c941a5f7a2914050._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-06-23T20:05:45Z"
+ content="""
+`git-annex copy --from foo --to bar`  is implemented now, with caveats.
+(Eg, needs to temporarily store each file on disk.)
+
+So I think it would make sense to implement `git-annex export --from foo
+--to bar`, with the same caveats.
+"""]]
diff --git a/doc/todo/git-annex-migrate_using_git-replace.mdwn b/doc/todo/git-annex-migrate_using_git-replace.mdwn
new file mode 100644
index 0000000000..783b294541
--- /dev/null
+++ b/doc/todo/git-annex-migrate_using_git-replace.mdwn
@@ -0,0 +1,7 @@
+Currently, git-annex-migrate leads to content (and metadata) being stored under both old and new keys.  git-annex-unused can drop the contents under the old key, but then you can't access the content if you check out an older commit.  Maybe, an option can be added to migrate keys using [git-replace](https://git-scm.com/docs/git-replace) ?  You'd git-replace the blob .git/annex/objects/old_key with the blob .git/annex/objects/new_key, the blob ../.git/annex/objects/old_key with the blob ../.git/annex/objects/new_key , etc.  You could then also have a setting to auto-migrate non-checksum keys to checksum keys whenever the contents gets downloaded.
+
+More generally, git-annex-replace could be implemented this way, doing what git-replace does, but for git-annex keys rather than git hashes.  [[git-annex-pre-commit]] might need to be changed to implement replacement of keys added later.
+
+[[!tag needsthought]]
+
+> [[wontfix|done]], use distributed migration instead --[[Joey]]
diff --git a/doc/todo/git-annex-migrate_using_git-replace/comment_1_6a317be851dfb72c4aaaf5786dd1a1ff._comment b/doc/todo/git-annex-migrate_using_git-replace/comment_1_6a317be851dfb72c4aaaf5786dd1a1ff._comment
new file mode 100644
index 0000000000..2240298a3a
--- /dev/null
+++ b/doc/todo/git-annex-migrate_using_git-replace/comment_1_6a317be851dfb72c4aaaf5786dd1a1ff._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Chel"
+ avatar="http://cdn.libravatar.org/avatar/a42feb5169f70b3edf7f7611f7e3640c"
+ subject="comment 1"
+ date="2020-02-01T02:55:03Z"
+ content="""
+Very interesting idea! But some problems:
+
+- As mentioned, not only `.git/annex/<...>` blobs need to be replaces for every key, but also `/annex/<...>`
+and all `../.git/annex/<...>`, `../../.git/annex/<...>`, etc.
+
+- In big repositories it can create a giant amount of *refs/replace/* refs.
+I don't know how it affects the performance if they are stored in .git/packed-refs,
+but it can interfere with the normal operation on a repo.
+For example `git show-ref` will not work without ` | grep` or something.
+"""]]
diff --git a/doc/todo/git-annex-migrate_using_git-replace/comment_2_e760213fc51f6a2cfc68dec711622f25._comment b/doc/todo/git-annex-migrate_using_git-replace/comment_2_e760213fc51f6a2cfc68dec711622f25._comment
new file mode 100644
index 0000000000..9e4b0be36c
--- /dev/null
+++ b/doc/todo/git-annex-migrate_using_git-replace/comment_2_e760213fc51f6a2cfc68dec711622f25._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2024-02-10T14:22:31Z"
+ content="""
+In the meantime, distributed migration has been implemented, allowing
+to `git-annex migrate --update` to catch up with all migrations that were
+started elsewhere.
+
+This is essentially the same goal, and it is much more efficient in terms
+of storage than git-replace of a large number of refs.
+
+So, I'm going to close this.
+"""]]
diff --git a/doc/todo/git-annex-sync_handling_of_linked_worktrees.mdwn b/doc/todo/git-annex-sync_handling_of_linked_worktrees.mdwn
new file mode 100644
index 0000000000..2bd322cede
--- /dev/null
+++ b/doc/todo/git-annex-sync_handling_of_linked_worktrees.mdwn
@@ -0,0 +1,3 @@
+When using [[linked worktrees|tips/Using_git-worktree_with_annex]], the main tree is currently handled differently from the linked trees: "if there is change in the tree then syncing doesn't update git worktrees and their indices, but updates the checked out branches. This is different to the handling of the main working directory as it's either got updated or left behind with its branch if there is a conflict."   Is there a reason for this?  Could linked worktrees be treated same as main one?
+
+[[!tag moreinfo]]
diff --git a/doc/todo/git-annex-sync_handling_of_linked_worktrees/comment_1_3e542583247177f9cdf44122ec483a0c._comment b/doc/todo/git-annex-sync_handling_of_linked_worktrees/comment_1_3e542583247177f9cdf44122ec483a0c._comment
new file mode 100644
index 0000000000..eaf6675861
--- /dev/null
+++ b/doc/todo/git-annex-sync_handling_of_linked_worktrees/comment_1_3e542583247177f9cdf44122ec483a0c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-30T17:12:40Z"
+ content="""
+That tip was written by leni536, and I don't really understand what it's
+talking about with a difference in sync behavior. I'm not sure it's
+accurate or describes what happens clearly.
+
+To me it seems really simple, no matter if you have a regular work tree, or
+are using git-worktree or whatever: sync fetches, merges, and pushes. Merging
+updates the current work tree, and AFAIK not whatever other work trees might
+be using the same .git repository. In any case, sync should behave the same
+as git pull as far as updating work trees goes.
+
+Can you please show an example of whatever problem you may have with the
+current behavior?
+"""]]
diff --git a/doc/todo/git-annex-test___58___skip_tests_if_external_utils_have_problems.mdwn b/doc/todo/git-annex-test___58___skip_tests_if_external_utils_have_problems.mdwn
new file mode 100644
index 0000000000..1e6a677d2d
--- /dev/null
+++ b/doc/todo/git-annex-test___58___skip_tests_if_external_utils_have_problems.mdwn
@@ -0,0 +1,3 @@
+git-annex-test failures sometimes reflect failures not of git-annex but of externals utils on which it relies.  E.g. when my installation or configuration of gpg has problems, git-annex test suite fails due to the tests that rely on gpg.  (And there doesn't seem to be a simple way to skip tests that match a regexp.)  git-annex could avoid that by running some simple sanity checks (beyond just existence) on gpg or other optional dependencies, and skipping tests if these checks fail.  E.g. if simple test commands to encrypt/sign a small file with gpg fail, then skip gpg-based tests (and warn the user).
+
+[[!tag unlikely]]
diff --git a/doc/todo/git-annex-test___58___skip_tests_if_external_utils_have_problems/comment_1_240c9c45a629124dc35f4ed0dddd7355._comment b/doc/todo/git-annex-test___58___skip_tests_if_external_utils_have_problems/comment_1_240c9c45a629124dc35f4ed0dddd7355._comment
new file mode 100644
index 0000000000..42cfd40ee1
--- /dev/null
+++ b/doc/todo/git-annex-test___58___skip_tests_if_external_utils_have_problems/comment_1_240c9c45a629124dc35f4ed0dddd7355._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-03-22T14:18:48Z"
+ content="""
+I kind of like that the test suite will fail if git-annex is being used in
+some broken environment, because it gives an easy way to check if git-annex
+is able to fully work.
+
+Note that, the test suite does try a self-test of its ability to use gpg
+before proceeding with other gpg tests; if that self-test fails it does
+abort the other tests in that test block. That self-test does not currently
+test encryption or decrpryption, only that gpg can access the test key
+pair.
+"""]]
diff --git a/doc/todo/git-annex-unused_--history.mdwn b/doc/todo/git-annex-unused_--history.mdwn
new file mode 100644
index 0000000000..515754d9c8
--- /dev/null
+++ b/doc/todo/git-annex-unused_--history.mdwn
@@ -0,0 +1,15 @@
+Add to git-annex unused a --history or similar switch, that makes it look at
+the full history of all specified refs, and only consider files unused if
+they never appeared in a git commit at all.
+
+This would, like `git gc`, find files that were added, but then
+deleted/changed before being committed. Which git-annex unused already
+does, but it also finds files in past versions. If the user wants to keep
+past versions, but gc any dangling objects, this would be useful.
+
+To traverse the whole history and get the list of changes, could use `git
+log --raw`. That is reasonably performant but then it needs to feed every
+sha into cat-file to find the annex objects, which would probably take a
+while. Alternatively perhaps git log --diff and parsing might be faster.
+
+[[!tag confirmed]]
diff --git a/doc/todo/git-annex-unused_--history/comment_1_9b9518a88e5f90d68b4131c430e66881._comment b/doc/todo/git-annex-unused_--history/comment_1_9b9518a88e5f90d68b4131c430e66881._comment
new file mode 100644
index 0000000000..5892139eac
--- /dev/null
+++ b/doc/todo/git-annex-unused_--history/comment_1_9b9518a88e5f90d68b4131c430e66881._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-11T16:59:59Z"
+ content="""
+Alternate name, `git-annex gc` since this would be very analagous to `git
+gc`.
+
+I wonder if someone might want to keep all versions of files from one branch,
+but only the current version of another branch? For such a person it would
+be better if the interface was all in `git-annex unused`
+as part of the `--used-refspec` with a way to indicate if past versions
+of a ref should be examined.
+"""]]
diff --git a/doc/todo/git-annex-unused_--history/comment_2_d0aa8cc29e38510b2bb1c4ce356aa2ac._comment b/doc/todo/git-annex-unused_--history/comment_2_d0aa8cc29e38510b2bb1c4ce356aa2ac._comment
new file mode 100644
index 0000000000..f4f7be7b50
--- /dev/null
+++ b/doc/todo/git-annex-unused_--history/comment_2_d0aa8cc29e38510b2bb1c4ce356aa2ac._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="meribold"
+ avatar="http://cdn.libravatar.org/avatar/8cfdfc37c8459a7320aa6bb9f2689112"
+ subject="comment 2"
+ date="2021-03-12T03:58:03Z"
+ content="""
+Another name for a `git-annex unused` switch could be `--unreachable`. I suppose `git-annex gc` would drop unreachable files without a separate `git-annex dropunused` invocation? That would work for me as well.
+
+> I wonder if someone might want to keep all versions of files from one branch, but only the current version of another branch?
+
+Personally I don't have the use case of `git-annex unused` only looking at the history of some refs and treating other refs normally.
+"""]]
diff --git a/doc/todo/git-annex-unused_--history/comment_3_21797e55d27356411430b3ec07af5264._comment b/doc/todo/git-annex-unused_--history/comment_3_21797e55d27356411430b3ec07af5264._comment
new file mode 100644
index 0000000000..ff9da61d0b
--- /dev/null
+++ b/doc/todo/git-annex-unused_--history/comment_3_21797e55d27356411430b3ec07af5264._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-03-12T15:43:16Z"
+ content="""
+Since dropunused, --unused, etc refer to what git-annex unused finds,
+it probably makes sense to keep it in there.
+
+`git-annex unused --ever` is another name idea.
+"""]]
diff --git a/doc/todo/git-hook_to_sanity-check_git-annex_branch_pushes.mdwn b/doc/todo/git-hook_to_sanity-check_git-annex_branch_pushes.mdwn
new file mode 100644
index 0000000000..bee234e107
--- /dev/null
+++ b/doc/todo/git-hook_to_sanity-check_git-annex_branch_pushes.mdwn
@@ -0,0 +1,57 @@
+IA.BAK and another project both need a way to let untrusted clients push
+git-annex branch changes to a central server. It's desired to only
+let a client make non-malicious pushes; a malicious client could screw
+up a lot of info in the branch.
+
+I propose adding a git-annex command that can be used in a git pre-receive
+hook to do this. --[[Joey]]
+
+There are two levels of checking it seems such a command could do:
+
+1. Only allow certain files to be changed. For example, maybe clients are only
+   expected to change location tracking files, and the activity.log
+   file, but not others like trust.log.
+
+2. Only allow modifications of data about a specific UUID. The UUID
+   would be provided to the command (and could be determined based on a
+   per-client ssh key or etc).
+
+  The changes to the branch would be checked, so this needs centralized
+  knowledge about the format of each file on the branch. I think this
+  mostly exists already in Logs.hs.
+
+Of these the second seems more likely to be useful, but the first would
+be by far the easier to add. So, do both?
+
+This might be too limiting for some situations:
+
+* If someone has 2 clients, that are talking with one-another,
+  then a push would include changes involving the UUIDs of both clients.
+  The command could be given multiple UUIDs to allow, to allow
+  for these kinds of setups.
+
+* A client might add a special remote somewhere, but this would need
+  changes to remote.log, which the first level of checking would not allow.
+  And, it would add another UUID, which the second level of checking would
+  need to be configured to allow.
+
+Python implementation
+---------------------
+
+I started doing an implementation of this in Python here. The code is
+available in [pre-receive-gitannex-check.py](https://gitlab.com/anarcat/puppet-git-annex/raw/a7333fd26af19eb5ee662c261a498c868b8b67e3/files/pre-receive-gitannex-check.py) (permalink, see also
+the [latest version](https://gitlab.com/anarcat/puppet-git-annex/blob/master/files/pre-receive-gitannex-check.py)).
+
+I went through what seems to be a rather convoluted design with libgit
+because I wanted to have some proper unit tests and generating git
+commands by hand in a shell script is rather painful. Also, it
+currently adopts a "blocking" approach, ie. it blocks known problems,
+but maybe it should be based on an "allow" approach, that is: only
+allow certain things to go through. 
+
+So far it only forbids removals and changes to trust.log.  A bunch of
+stuff is still missing like parameters (to allow changing the list of
+protected files) and checking the log tracking info. Feedback
+welcome. --[[anarcat]]
+
+Similar: [[todo/append-only_mode]]
diff --git a/doc/todo/git-lfs_special_remote_simpler_setup.mdwn b/doc/todo/git-lfs_special_remote_simpler_setup.mdwn
new file mode 100644
index 0000000000..ebaf25bf21
--- /dev/null
+++ b/doc/todo/git-lfs_special_remote_simpler_setup.mdwn
@@ -0,0 +1,27 @@
+It would be nice if a clone from eg, gitlab could autoenable the git-lfs
+special remote. Currently, autoenable doesn't work for git-lfs special
+remotes at all, because the url is not stored.
+
+What if, an url or urls passed to initremote were stored. Then when
+enableremote/autoenable runs, if it sees a git remote with a known url,
+it sets that remote up with annex-uuid and annex-git-lfs set, instead of
+adding a new remote. That might need changes to the Remote setup method,
+not sure.
+
+Or, Remote.Git could, when enumerating remotes, call into Remote.GitLFS
+to check if the url is one it knows about, and if so, autoenable
+the special remote. Although that would mean reading remote.log when
+enumerating remotes, which I think is currently avoided, and might be too
+much overhead to add to git-annex generally for the value of this feature.
+
+Many urls could be used to clone the same LFS repo. http(s) and ssh are the
+obvious two or three. Now that `initremote --sameas`
+[[is available|support_multiple_special_remotes_with_same_uuid]],
+special remotes can be initialized for all the urls. The user would need to
+do that themselves probably.
+
+> [[done]], the url is stored, and when there's a remote that has an url
+> that's known to be to a git-lfs repo, that remote is automatically
+> enabled to be used as a git-lfs special remote. --[[Joey]]
+
+[[!tag projects/dandi]]
diff --git a/doc/todo/git-lfs_special_remote_simpler_setup/comment_1_4e9f8b60dd1b705d4755200dada8801c._comment b/doc/todo/git-lfs_special_remote_simpler_setup/comment_1_4e9f8b60dd1b705d4755200dada8801c._comment
new file mode 100644
index 0000000000..f9af1d11c4
--- /dev/null
+++ b/doc/todo/git-lfs_special_remote_simpler_setup/comment_1_4e9f8b60dd1b705d4755200dada8801c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="reference original bug report"
+ date="2019-11-29T17:58:28Z"
+ content="""
+original bug report was https://git-annex.branchable.com/bugs/git-lfs_remote_URL_is_not_recorded__63__/ for an attempt to share some NWB data on github's LFS
+"""]]
diff --git a/doc/todo/git-remote-annex.mdwn b/doc/todo/git-remote-annex.mdwn
new file mode 100644
index 0000000000..05ea923975
--- /dev/null
+++ b/doc/todo/git-remote-annex.mdwn
@@ -0,0 +1,24 @@
+git-remote-annex will be a program that allows push/pull of a git
+repository to any git-annex special remote.
+
+This is a redesign and reimplementation of git-remote-datalad-annex. 
+It will be a safer implementation, will support incremental pushes, and
+will be available to users who don't use datalad. 
+
+Work is in the `git-remote-annex` branch, currently we have a design for
+the core data files and operations.
+<http://source.git-annex.branchable.com/?p=source.git;a=blob;f=doc/internals/git-remote-annex.mdwn;hb=git-remote-annex>
+
+Also, that branch has a proof of concept implementation in a shell script.
+Though it doesn't yet use special remotes at all, it is able to do
+incremental pushes to git bundles with a manifest.
+
+I still need to do some design work around using the git-annex branch to
+detect concurrent push situations where changes to the manifest get lost,
+and re-add those changes to it later.
+
+Also, it's not clear what will happen when two people make conflicting pushes
+to a ref, the goal would be to replicate git push to a regular git remote,
+but that may not be entirely possible. This will need to be investigated
+further.
+--[[Joey]]
diff --git a/doc/todo/git_annex_info___60__remote__62___does_not_list_all_the_parameters_for_the_remote.mdwn b/doc/todo/git_annex_info___60__remote__62___does_not_list_all_the_parameters_for_the_remote.mdwn
new file mode 100644
index 0000000000..12aeca9db8
--- /dev/null
+++ b/doc/todo/git_annex_info___60__remote__62___does_not_list_all_the_parameters_for_the_remote.mdwn
@@ -0,0 +1,34 @@
+[[!format sh """
+$> git annex info  gdrive2 --verbose    
+remote: gdrive2   
+description: [gdrive2]
+uuid: d7e13bf3-0c0e-44c9-a626-c7af6a628df7
+trust: semitrusted
+cost: 200.0
+type: external
+externaltype: rclone
+encryption: none
+chunking: 52.43 megabyteschunks
+remote annex keys: 3
+remote annex size: 112.51 megabytes
+(dev) 2 29865.....................................:Fri 21 Jul 2017 12:35:35 PM EDT:.
+hopa:/tmp/testds1
+$> git co git-annex
+Switched to branch 'git-annex'
+W: git-annex repositories not (yet) supported in the prompt                                                     
+(dev) 2 29866.....................................:Fri 21 Jul 2017 12:35:40 PM EDT:.
+hopa:/tmp/testds1
+$> cat remote.log 
+ace2983e-5e2b-4c6a-8251-5344392d563c chunk=50MiB encryption=none externaltype=rclone mac=HMACSHA512 name=gdrive1 prefix=git-annex/testds1 rclone_layout=lower target=google-drive1 type=external timestamp=1500494328.845312147s
+d7e13bf3-0c0e-44c9-a626-c7af6a628df7 chunk=50MiB encryption=none externaltype=rclone mac=HMACSHA512 name=gdrive2 prefix=git-annex/raiders2 rclone_layout=lower target=google-drive1 type=external timestamp=1500654564.923893997s
+
+"""]]
+
+needed to see what is the prefix -- which is stored in remote.log -- but not printed by 'git annex info' neither in --verbose nor --json mode
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> This got fixed already it turns out, GETINFO.
+> Of course this and other special remotes will need changes to use it,
+> but that's outside the scope of git-annex, so [[done]]. --[[Joey]]
diff --git a/doc/todo/git_annex_info___60__remote__62___does_not_list_all_the_parameters_for_the_remote/comment_1_875fdf1aacff3cc2c3732450f052d711._comment b/doc/todo/git_annex_info___60__remote__62___does_not_list_all_the_parameters_for_the_remote/comment_1_875fdf1aacff3cc2c3732450f052d711._comment
new file mode 100644
index 0000000000..a9ca1a645c
--- /dev/null
+++ b/doc/todo/git_annex_info___60__remote__62___does_not_list_all_the_parameters_for_the_remote/comment_1_875fdf1aacff3cc2c3732450f052d711._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-15T17:20:10Z"
+ content="""
+This is an external special remote, and the meaning of prefix= and other
+parameters used when initializing an external special remote is up to that
+special remote. 
+
+For all git-annex knows, that may be some kind of binary
+value, or access token that you don't want scrawled on the screen. It makes
+sense for `git-annex info` not to display this stuff since it does not know
+what it is.
+
+It might make sense to extend the external special remote protocol
+with a command to get additional info to display.
+"""]]
diff --git a/doc/todo/git_annex_info_to_include_information_about_repo_version__63__.mdwn b/doc/todo/git_annex_info_to_include_information_about_repo_version__63__.mdwn
new file mode 100644
index 0000000000..0f434efe50
--- /dev/null
+++ b/doc/todo/git_annex_info_to_include_information_about_repo_version__63__.mdwn
@@ -0,0 +1,6 @@
+I thought that 'git annex info' should be the best location to report current version (6 or before ATM?) of the repository, which seems to be stored only within .git/config.  so I see how it somewhat possibly doesn't fit 'git annex info' which reports primarily from the state of git-annex branch, but since even "available local disk space" is in there, version better be reported there as well imho
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> Closing because it seems I don't need to do anything. [[done]] --[[Joey]]
diff --git a/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_1_783c53fd99747bc65bd832f918c50a59._comment b/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_1_783c53fd99747bc65bd832f918c50a59._comment
new file mode 100644
index 0000000000..ae1514dad9
--- /dev/null
+++ b/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_1_783c53fd99747bc65bd832f918c50a59._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-06T17:11:42Z"
+ content="""
+Currently `git annex version` shows the repo version. I think this makes
+sense since it also shows repo versions that can be upgraded to, etc.
+
+It seems redundant to report it in two places.
+"""]]
diff --git a/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_2_60d3b088de83c86243b19c3d0d050080._comment b/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_2_60d3b088de83c86243b19c3d0d050080._comment
new file mode 100644
index 0000000000..4cf5c5f487
--- /dev/null
+++ b/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_2_60d3b088de83c86243b19c3d0d050080._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 2"
+ date="2016-07-06T19:27:24Z"
+ content="""
+yikes, I never thought that 'git annex version', which works outside of repos as well, shows any information about the repository itself.  IMHO any such information should be within 'git annex info', not 'git annex version'  (does 'git version' show any repo specific version information? ;) )  Moreover there is no --json for 'annex version' ;)
+"""]]
diff --git a/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_3_d6e84551319439ba50bc10edbd25335c._comment b/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_3_d6e84551319439ba50bc10edbd25335c._comment
new file mode 100644
index 0000000000..209f9bfc7c
--- /dev/null
+++ b/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_3_d6e84551319439ba50bc10edbd25335c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-07-11T16:52:33Z"
+ content="""
+git doesn't provide any command that outputs the repo version AFAIK, so
+it's not a useful precedent.
+
+Good point about --json. But, you can get the annex repo version 
+in machine parsable format using `git config annex.version`
+"""]]
diff --git a/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_4_5b3e45c746e6cfa7f511790bbd9f6c9f._comment b/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_4_5b3e45c746e6cfa7f511790bbd9f6c9f._comment
new file mode 100644
index 0000000000..3d5860fd0c
--- /dev/null
+++ b/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_4_5b3e45c746e6cfa7f511790bbd9f6c9f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 4"
+ date="2016-07-11T17:25:28Z"
+ content="""
+> git doesn't provide any command that outputs the repo version AFAIK, so it's not a useful precedent.
+
+well -- exactly that -- `git version` DOES NOT output repos (its index or whatnot) version HERE. It only provides information about git's version
+Either there is some git command which outputs repo (index, ...) version is somewhat independent.  But ok -- I don't care much enough, can take version from git config I guess indeed, even though 'annex info' seems to be the most logical location for that information to be provided from as well IMHO ;-)
+"""]]
diff --git a/doc/todo/git_annex_repair__58___performance_can_be_abysmal__44___huge_improvements_possible.mdwn b/doc/todo/git_annex_repair__58___performance_can_be_abysmal__44___huge_improvements_possible.mdwn
new file mode 100644
index 0000000000..2dae2270f7
--- /dev/null
+++ b/doc/todo/git_annex_repair__58___performance_can_be_abysmal__44___huge_improvements_possible.mdwn
@@ -0,0 +1,30 @@
+# Situation
+
+Since yesterday evening (18 hours ago), `git annex repair --verbose` is repairing a repository from a remote.  This is on a fast machine (i7 4 physical cores, 8 logical CPUs @2.6Ghz sitting idle, 16GB RAM mostly unused, hard drive with measured 111MB/s sustained capacity). `.git` folder to repair grew to 8Gb while remote was only about 640MB.
+
+# What `git annex repair` does
+
+Currently, `git annex repair` appears to :
+
+* make a complete local clone from the remotes it finds, 
+* expand all packs into individual objects files,
+* then pour (with rsync) all those objects into the repository
+* and I guess it ends with a git fsck/gc/whatever to glue things back.
+
+The expected result (a complete repaired repo) is great but it didn't work without help and the performance is disappointing.
+
+# Suggested room for improvements
+
+I would be willing to contribute some patches and although I have a respectable experience in programming, including some functional traits, I'm not savvy enough in Haskell at the time.
+
+(1) a complete clone in this case means *between one and two hours* of download and easily gets interrupted losing all eforts (just like a plain git clone). Actually I tried several times and it never completed.  I worked around this by doing a `git clone` on the server and `rsync`ing that to a local storage and adding that locally as a git remote.
+
+(2) Even when a local "git remote" is available, `git annex repair` first tried the network one instead. Perhaps it would be better if it sorted git remotes and first try the ones that appear to be available locally (no URL or file:// URL scheme)? Workaround: manually break the transfer to that `git repair` switches to the next remote.
+
+(3) does `git annex repair` really have to explode the repository into individual objects? In my case it took about one hour to create 1454978 (one million four hundred thousands) object files for a total of 6.8GB. (I should have put `TEMP` and `TMPDIR` to point to a SSD-based storage as a workaround or even dare a tmpfs.) `git-annex` then runs a `rsync` that has been going on thrashing the disk (I can hear and feel it) for 7 hours and a half, with an expected total time of 8 hours 20 minutes. That's a very inefficient way to copy 6.8GB (incidentally, rsync does it in alphabetical order of hash as shown by `strace` and confirmed by man page and [here](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640492) and [there](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=160982)). There must be a more efficient way, right? 
+
+A a sidenote, I don't know how a repo containing about 300k files jumped to 1400k git objects within the last 2 months.
+
+Any feedback welcome, thanks.
+
+[[!tag needsthought unlikely]]
diff --git a/doc/todo/git_annex_repair__58___performance_can_be_abysmal__44___huge_improvements_possible/comment_1_4828098be3e7cd6109bd1934bf029f1f._comment b/doc/todo/git_annex_repair__58___performance_can_be_abysmal__44___huge_improvements_possible/comment_1_4828098be3e7cd6109bd1934bf029f1f._comment
new file mode 100644
index 0000000000..0765bcedc9
--- /dev/null
+++ b/doc/todo/git_annex_repair__58___performance_can_be_abysmal__44___huge_improvements_possible/comment_1_4828098be3e7cd6109bd1934bf029f1f._comment
@@ -0,0 +1,90 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Experiment to run git-annex-repair as fast as possible."
+ date="2017-07-28T04:27:06Z"
+ content="""
+# Introduction
+
+There has been some progress somehow. I managed to have `git-annex-repair` somehow succeed while complaining (see details in [git-annex-repair claims success then failure](https://git-annex.branchable.com/todo/git-annex-repair_claims_success_then_failure/)).
+
+I've had a look at:
+
+* [repair stuck on ls-tree command](http://git-annex.branchable.com/forum/repair_stuck_on_ls-tree_command/)
+* [git-annex branch shows commit with looong commitlog](http://git-annex.branchable.com/bugs/git-annex_branch_shows_commit_with_looong_commitlog/)
+* [git-annex wants to repair because of duplicateEntries in git fsck](https://git-annex.branchable.com/bugs/git-annex_wants_to_repair_because_of_duplicateEntries_in_git_fsck/)
+
+Perhaps I'll use `git-annex-forget` after I've rebuilt the repo.
+
+# Approach: how to speed up git-annex-repair with warm filesystem cache
+
+With a rather \"violent\" approach I could have it run in 78 minutes instead of thrashing for tens of hours.  The approach is:
+
+* copy `.git` folder (without `.git/annex/objects`, yet copied `.git/objects` takes about 9GB) to a SSD,
+* have a shell command line repeatedly make a `tar` of that to keep all that data warm in the filesystem cache (it repeatedly made a 4.3GB `tar` to `/dev/null` nearly always under one minute, even down to 7 seconds quite a few times)
+* use a tmpfs as temp directory `mkdir /dev/shm/tmp/ ; export TMPDIR=/dev/shm/tmp/ ; export TEMP=/dev/shm/tmp/`
+* then in that context `git-annex-repair --force`
+
+This approach is intended to ensure the fastest processing time for git-annex-repair by providing it fully warm filesystem cache.  Since no L1 L2 or L3 cache is gigabyte-sized, that means all this runs at RAM speed.
+
+# Performance result
+
+That machine capable of processing (make a tar of) the whole repo in 7 seconds ran the `git-annex-repair` process for 78 minutes (never more than one core busy at a time) and completed.  78 minutes is enough to make between 70 and 600 `tar`s of the full content that git-annex is supposed to repair.  IIRC the CPU was not active all the time.
+
+In other words, currently, repairing a repository looks as costly somehow as reading it many tens or hundreds of time.  Intuition says it probably doesn't have to be, even considering costs like computations and launching external processes.
+
+# Quick analysis
+
+I have seen with `strace` that `git-annex-repair` runs a number of `git show` commands.  Actually, most of the processing time appears to be in those `git-show` commands.
+
+# Hunch about what happens
+
+`git-show` (at least sometimes) first walks a lot of (all ?) `.git/object` content.
+
+`git-show` (at least sometimes) spit tens of megabytes of data, including **full-text patches of changed files**.
+
+Adding `--stat` to the git show command makes it much much quicker.
+
+# A few figures
+
+I took one example of git-show command and ran it separately.
+
+With `--stat`, cold cache: 41 seconds to produce 10MB.
+
+    $ git --literal-pathspecs show somehash --stat | pv | wc
+
+    10,2MiO 0:00:41 [ 251KiB/s]
+     134215  536851 10736844
+
+With `--stat`, warm cache: 2.5 seconds to produce 10MB.
+
+    $ time git --literal-pathspecs show somehash --stat | pv | wc
+
+    10,2MiO 0:00:02 [4,08MiB/s]
+     134215  536851 10736844
+
+    real	0m2.514s
+    user	0m1.492s
+    sys	0m1.044s
+
+Without `--stat`, 502 seconds to produce 57MB.
+
+    $ time git --literal-pathspecs show somehash | pv | wc
+
+     2243  time git --literal-pathspecs show somehash | pv | wc
+
+    57,4MiO 0:08:22 [ 116KiB/s]
+     939462 2818382 60230220
+
+    real	8m22.846s
+    user	0m57.716s
+    sys	7m25.912s
+
+# Summary
+
+* Does `git-annex-repair` need to ask git to reconstruct text-diff-style information from compressed data? Is that the source of the bad performance?
+* What does `git-annex-repair` need in `git-show` output?
+* Can `git-annex-repair` be made faster (much faster?) by tuning the way it calls git?
+
+"""]]
diff --git a/doc/todo/git_annex_upgrade_to_not_care_about_submod_status__63__.mdwn b/doc/todo/git_annex_upgrade_to_not_care_about_submod_status__63__.mdwn
new file mode 100644
index 0000000000..cc419a8ab5
--- /dev/null
+++ b/doc/todo/git_annex_upgrade_to_not_care_about_submod_status__63__.mdwn
@@ -0,0 +1,21 @@
+I ran `git annex upgrade` in some datalad super dataset (produced by heudiconv with reproin heuristic layout), and then (after it didn't return for ages)  in the process tree saw that it goes to subdatasets (git submodules) to check on the status
+
+```
+bids     38757  0.0  0.0 1074049444 11552 pts/2 Sl+ 17:14   0:00             /usr/lib/git-annex.linux/exe/git-annex --library-path /usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git-annex/git-annex upgrade
+bids     38787  0.0  0.0  10316  1980 pts/2    S+   17:14   0:00               /usr/lib/git-annex.linux/exe/git --library-path /usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+bids     38790  0.0  0.0  11156  2204 pts/2    S+   17:14   0:00               /usr/lib/git-annex.linux/exe/git --library-path /usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs status --porcelain
+bids     49130  0.0  0.0  11156  2192 pts/2    S+   17:43   0:00                 /usr/lib/git-annex.linux/exe/git --library-path /usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git status --porcelain=2
+bids     49139  0.0  0.0  11156  2192 pts/2    S+   17:43   0:00                   /usr/lib/git-annex.linux/exe/git --library-path /usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git status --porcelain=2
+bids     49162  0.8  0.0 1047612 11840 pts/2   Sl+  17:44   0:07                     /usr/lib/git-annex.linux/exe/git --library-path /usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git status --porcelain=2
+bids     15704  0.0  0.0   2404   376 pts/2    S+   17:59   0:00                       /bin/sh -c git-annex smudge --clean -- 'sub-sid001830/func/sub-sid001830_task-viewing_acq-638tr_run-06_bold.json' git-annex smudge --clean -- 'sub-sid001830/func/sub-sid001830_task-viewing_acq-638tr_run-06_bold.json'
+bids     15705  2.0  0.0 1074123208 7608 pts/2 Rl+  17:59   0:00                         /usr/lib/git-annex.linux/exe/git-annex --library-path /usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git-annex/git-annex smudge --clean -- sub-sid001830/func/sub-sid001830_task-viewing_acq-638tr_run-06_bold.json
+bids     15711  1.0  0.0  13452  3632 pts/2    S+   17:59   0:00                           /usr/lib/git-annex.linux/exe/git --library-path /usr/lib/git-annex.linux//lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+
+```
+
+I guess it could have used some flavor of `--ignore-submodules` with its invocation of `status` -- couldn't it?
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/git_annex_upgrade_to_not_care_about_submod_status__63__/comment_1_607ec43498187636312693932f66cc6d._comment b/doc/todo/git_annex_upgrade_to_not_care_about_submod_status__63__/comment_1_607ec43498187636312693932f66cc6d._comment
new file mode 100644
index 0000000000..b7c1ba8400
--- /dev/null
+++ b/doc/todo/git_annex_upgrade_to_not_care_about_submod_status__63__/comment_1_607ec43498187636312693932f66cc6d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-12-20T19:48:52Z"
+ content="""
+This happens on upgrade from a v5 repository, which calls 
+configureSmudgeFilter. [[!commit 401a79675ba2f125545ec9ec77376cb4b965fa4a]]
+explains why it needs to run status there.
+
+So, it will indeed be ok to pass --ignore-submodules, since each submodule
+that is a git-annex repository will get upgraded in its own time, 
+and will run configureSmudgeFilter then.
+"""]]
diff --git a/doc/todo/git_fetch_and_push_to_import_export_remote.mdwn b/doc/todo/git_fetch_and_push_to_import_export_remote.mdwn
new file mode 100644
index 0000000000..47ccc4afc0
--- /dev/null
+++ b/doc/todo/git_fetch_and_push_to_import_export_remote.mdwn
@@ -0,0 +1,17 @@
+It should be possible for `git fetch foo` to work when foo is a special
+remote with importtree=yes. This would have the same effect as running
+`git-annex import --from foo`.
+
+Also `git push foo` when it supports export, would have the same effect as
+running `git annex export --to foo`
+
+It would need `remote.foo.url` to be set to something like `annex::foo`
+which would make fetch and pull run `git-remote-annex`. Currently, special
+remote's don't get an url configured. (`annex::uuid` was my first thought,
+but `annex::foo` avoids repeating the remote's uuid and git-annex can
+look up the uuid from the name) --[[Joey]]
+
+> While this seems possible, I wonder if it's a good idea. It seems, that,
+> the justify the added code and new executable (or symlink to git-annex),
+> there would need to be a real benefit. Is it enough benefit to unify
+> import/export with pull/push? Is it really a benefit at al? --[[Joey]]
diff --git a/doc/todo/git_repo_tracking___40__not_storage__41__.mdwn b/doc/todo/git_repo_tracking___40__not_storage__41__.mdwn
new file mode 100644
index 0000000000..5630f17d56
--- /dev/null
+++ b/doc/todo/git_repo_tracking___40__not_storage__41__.mdwn
@@ -0,0 +1,10 @@
+If git-annex tracked some information like the repo's remotes, current checkout hash, whether there are uncommitted modifications, branch states, stash state, etc., it seems like it could treat the repo similar to a URL registered for downloading a key. (I've seen the previous threads and agree git-annex should not "store" the repo). With such tracking, I think git-annex could support compelling workflows for managing code/project directories.
+
+A few possibilities:
+
+- Drop a repo for space if the current commit is available in at least N remotes (and all of the repo state is pushed/clean).
+- Create branches or tags in an annex that collect a set of version-compatible checkouts for related projects. The commit/tag messages provide a natural place for meta-commentary
+- Save and version files that aren't quite junk but don't belong *in* a repo (logs, dumps, backups, editor project/workspace files, notes/to-do lists, build-artifacts, test-coverage/linter stat databases, shell history) alongside the repo, making it easier to have a consistent environment for working on one project across multiple systems.
+- Make separate system-specific "master" branches for the main projects directory on each system, then edit and push changes from any other. For example, prep the projects directory on an infrequently-used laptop from your desktop and push/pull the changes.
+
+[[!tag unlikely moreinfo]]
diff --git a/doc/todo/git_repo_tracking___40__not_storage__41__/comment_1_e47bc088880a9e839f5c437117c58b68._comment b/doc/todo/git_repo_tracking___40__not_storage__41__/comment_1_e47bc088880a9e839f5c437117c58b68._comment
new file mode 100644
index 0000000000..0aa2878efa
--- /dev/null
+++ b/doc/todo/git_repo_tracking___40__not_storage__41__/comment_1_e47bc088880a9e839f5c437117c58b68._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2019-01-01T20:02:57Z"
+ content="""
+#1
+*|| Drop a repo for space if the current commit is available in at least N remotes (and all of the repo state is pushed/clean).*
+
+Did you mean \"drop a remote for space\"? If so there are already a lot of ways of conditionally dropping content from remotes or locally.
+
+#2
+*|| Create branches or tags in an annex that collect a set of version-compatible checkouts for related projects. The commit/tag messages provide a natural place for meta-commentary*
+
+You can create branches or tags in an annex and check them out as needed. The working directory always just refers to content in the .git/annex directory which would be shared across all branches.
+
+#3
+*|| Save and version files that aren't quite junk but don't belong in a repo (logs, dumps, backups, editor project/workspace files, notes/to-do lists, build-artifacts, test-coverage/linter stat databases, shell history) alongside the repo, making it easier to have a consistent environment for working on one project across multiple systems.*
+
+Couldn't you put these in another branch? Or add [metadata](https://git-annex.branchable.com/design/metadata/) to track them separately and use [metadata driven views](https://git-annex.branchable.com/tips/metadata_driven_views/).
+
+#4
+*|| Make separate system-specific \"master\" branches for the main projects directory on each system, then edit and push changes from any other. For example, prep the projects directory on an infrequently-used laptop from your desktop and push/pull the changes.*
+
+You can use any commands that work with git to manage your working directory including branches.
+"""]]
diff --git a/doc/todo/git_repo_tracking___40__not_storage__41__/comment_2_4af24f7207f63eb4cc127a64c1fc5fc3._comment b/doc/todo/git_repo_tracking___40__not_storage__41__/comment_2_4af24f7207f63eb4cc127a64c1fc5fc3._comment
new file mode 100644
index 0000000000..318ced2b37
--- /dev/null
+++ b/doc/todo/git_repo_tracking___40__not_storage__41__/comment_2_4af24f7207f63eb4cc127a64c1fc5fc3._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-01-30T18:20:42Z"
+ content="""
+This seems, at first glance, entirely out of scope for git-annex.
+
+There are other things that manage lots of git repositories. I've written one
+even (myrepos).
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal.mdwn b/doc/todo/git_smudge_clean_interface_suboptiomal.mdwn
new file mode 100644
index 0000000000..a8e4fee4e5
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal.mdwn
@@ -0,0 +1,123 @@
+git-annex uses git's smudge/clean interface to implement v6 unlocked
+files. However, the interface is suboptimal for git-annex's needs. While
+git-annex works around most of the problems with the interface, it can't
+avoid some consequences of this poor fit, and it has to do some surprising
+things to make it work as well as it does.
+
+First, how git's smudge/clean interface is meant to work: The smudge filter
+is run on the content of files as stored in a repo before they are written to
+the work tree, and can alter the content in arbitrary ways. The clean filter
+reverses the smudge filter, so git can use it to get the content to store
+in the repo. See gitattributes(5) for details.
+
+It was originally used for minor textual changes (eg line ending
+conversion), but it's general enough to be used to add large file support
+to git. git-lfs uses it that way.
+
+The first problem with the interface was that it ran a command once per
+file. This was later fixed by extending it to support long-running filter
+processes, which git-lfs uses. git-annex can also use that interface,
+when `git-annex filter-process` is enabled. That is the case in v9
+repositories and above.
+
+A second problem with the interface, which affects git-lfs AFAIK, is that
+git buffers the output of the smudge filter in memory before updating the
+working tree. If the smudge filter emits a large file, git can use a lot of
+memory. Of course, on modern computers this needs to be hundreds of
+megabytes to be very noticable. git-lfs may tend to be used with
+files not that large. git-annex avoids this problem by not using the smudge
+filter in the usual way, as described below.
+
+A third problem with the interface is that piping large file contents
+between git and filters is innefficient. Seems this must affect git-lfs
+too, but perhaps it's used on less enourmous data sets than git-annex.
+
+To avoid the problem, `git-annex smudge --clean` relies on a not very well
+documented trick: It is fed a possibly large file on stdin,
+but when it closes the FD without reading. git gets a SIGPIPE and stops
+reading and sending the file. Instead of reading from stdin, git-annex
+abuses the fact that git provides the clean filter with the work tree
+filename, and reads and cleans the file itself, more efficiently.
+
+git-lfs differs from git-annex in that all the large files in the
+repository are usually present in the working tree; it doesn't have a way
+to drop content that is not wanted locally while keeping other content
+locally available, as git-annex does. And so it does not need to be able to
+get content like git-annex can do either. It also differs in that it uses a
+central server, which is trusted to retain content, so it doesn't try to
+avoid losing the local copy, which could be the only copy, as git-annex
+does. (All AFAIK; have not looked at git-lfs recently.) 
+
+Those properties of git-lfs make it fit fairly well into the smudge/clean
+interface. Conversely, the different properties of git-annex make it a poor
+fit. 
+
+* git-annex needs to be able to update the working tree itself,
+  to make large file content available or not available. But this would cause
+  git to think the file is modified. 
+  
+  The way git-annex works around this is to run git update-index on files
+  after updating them. Git then runs the clean filter, and the clean filter
+  tells git there's not been any real modification of the file.
+
+* git-annex needs to hard link from its object store to a work tree
+  file, to avoid keeping two copies of the file on disk while preventing
+  a rm or git checkout from deleting the only local copy. But the smudge
+  interface does not provide a way to update the worktree itself.
+
+  So, git-annex's smudge filter does not actually provide the large file
+  content. It just echos back the file as checked into git, and
+  remembers that git wanted to check out that file.
+  git-annex installs post-checkout, post-merge, and pre-commit
+  hooks, which update the working tree files to make content from
+  git-annex available. Of course, that means git sees modifications to the
+  working tree, so git-annex then has to run git update-index on the files,
+  which runs the clean filter, as described above.
+  
+  (Not emitting large files from the smudge filter also avoids the problem with git
+  leaking memory described earlier.)
+
+And here's the consequences of git-annex's workarounds:
+
+* It doesn't use the long-running filter process interface by default, 
+  so `git add` of a lot of files runs `git-annex smudge --clean` once per file,
+  which is slower than it could be. Using `git-annex add` avoids this problem.
+  So does enabling `git-annex filter-process`, which is default in v9.
+
+* After a git-annex get/drop or a git checkout or pull that affects a lot
+  of files, the clean filter gets run once per file, which is again, slower
+  than ideal. Enabling `git-annex filter-process` can speed this up
+  in some cases, and is default in v9.
+
+* When `git-annex filter-process` is enabled, it cannot use the trick
+  described above that `git-annex smudge --clean` uses to avoid git
+  piping the whole content of large files through it. The whole file
+  content has to be read, even when git-annex does not need to see it.
+  This mainly slows down `git add` when it is being used with an
+  annex.largefiles confguration to add a large file to the annex,
+  by about 5%. ([[todo/incremental_hashing_for_add]] would improve
+  performance)
+
+* In a rare situation, git-annex would like to get git to run the clean
+  filter, but it cannot because git has the index locked. So, git-annex has
+  to print an ugly warning message saying that git status will show
+  modififcations to files that are not really modified, and giving a command to
+  fix the git status display.
+
+* git does not run any hook after a `git stash` or `git reset --hard`,
+  or `git cherry-pick`, so after these operations, annexed files remain unpopulated
+  until the user runs `git annex fix`.
+
+The best fix would be to improve git's smudge/clean interface:
+
+* Add hooks run after every work tree update or after `git stash` and
+  `git reset --hard`
+
+* Avoid buffering smudge filter output in memory.
+
+* Allow smudge filter to modify the work tree itself.
+  (I developed a patch series for this in 2016, but it didn't land.
+  --[[Joey]])
+
+* Allow clean filter to read work tree files itself, to avoid overhead of
+  sending huge files through a pipe.
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_10_2247cea7e7ca09389073fb32e98394e7._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_10_2247cea7e7ca09389073fb32e98394e7._comment
new file mode 100644
index 0000000000..fd0e9e44fb
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_10_2247cea7e7ca09389073fb32e98394e7._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2022-07-25T16:27:36Z"
+ content="""
+Well, there has been one bug noticed in v9 so far, it happens to be fixed
+in the upcoming release, and it only affected an edge case involving empty
+files.
+
+I'm not waiting to make v9 the default because of a lack of testing.
+There were some complaints that v8 became the default too
+quickly and caused problems when a mixture of git-annex versions was in
+use, and so it made sense to slow down the upgrade speed.
+
+Anyway, you can enable the speedup in v8 repositories:
+
+	git config filter.annex.process "git-annex filter-process"
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_11_39e671908522b79b8054ed9ddcaf918c._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_11_39e671908522b79b8054ed9ddcaf918c._comment
new file mode 100644
index 0000000000..a5fc406717
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_11_39e671908522b79b8054ed9ddcaf918c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 11"
+ date="2022-07-25T19:03:42Z"
+ content="""
+What about v10? ;-)  FWIW, [I added a test run for DataLad](https://github.com/datalad/datalad/pull/6881) to operate on v10 by default --  remains green.
+
+> `git-annex upgrade --version=9`
+
+FWIW 10.20220624-g769be12 seems to not have `--version` for `upgrade` and I see nothing
+
+> `git config filter.annex.process \"git-annex filter-process\"`
+
+cool -- seems to work (as commit took only 3m on that slow box).  I will go this route for now.
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_12_bb2bf0e82985bf2045741205c4682813._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_12_bb2bf0e82985bf2045741205c4682813._comment
new file mode 100644
index 0000000000..ae3ba11005
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_12_bb2bf0e82985bf2045741205c4682813._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2022-07-25T20:29:11Z"
+ content="""
+v10 only differs in a locking mechanic, anyway I'm using it myself so.
+
+`git-annex upgrade` will go from v8 to v9, no --version needed.
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_1_b41830b59c47ce5041c6005d41baf550._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_1_b41830b59c47ce5041c6005d41baf550._comment
new file mode 100644
index 0000000000..6cd48a9831
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_1_b41830b59c47ce5041c6005d41baf550._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="status?"
+ date="2018-11-30T19:46:20Z"
+ content="""
+Why was the smudge filter improvements not accepted upstream? All I could find was [this post](https://public-inbox.org/git/xmqqwpjqdh7w.fsf@gitster.mtv.corp.google.com/) which explains it was \"discarded\" because of \"bitrot\"...
+
+Also: the third \"suboptimal\" point is that \"piping large file contents between git and filters is innefficient\". Why? Aren't there ways to efficiently pipe contents around processes? For example, pv uses the splice(2) system call instead of just read/write on the pipes... 
+
+Thanks for any details!
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_2_8ad0fa4f67af60313d3195bc8c0acfb8._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_2_8ad0fa4f67af60313d3195bc8c0acfb8._comment
new file mode 100644
index 0000000000..a13eb93c95
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_2_8ad0fa4f67af60313d3195bc8c0acfb8._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-12-01T15:47:48Z"
+ content="""
+At the same time I was working on that patch set, there was another patch
+being developed that affected the same filters (adding the long-running
+filter interface to git). I think there may have also been some
+uncertianty, on the part of the git developers, in taking the filter
+interface in the direction I wanted to.
+
+(Also honestly, I can only rebase large C patch sets some many times before my
+time feels better spent doing something else. :-/)
+
+On piping efficiency, `splice()` doesn't avoid the whole file needing to be
+read in and and written to the pipe, which is the main bottleneck.
+And the way the smudge/clean filters are used by git-annex 
+(and git-lfs), bouncing the unaltered file content back out the other side
+using `splice()` doesn't seem like it would be useful.
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_3_778d21703afc5c08bfbc387b442cc193._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_3_778d21703afc5c08bfbc387b442cc193._comment
new file mode 100644
index 0000000000..2b258612a4
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_3_778d21703afc5c08bfbc387b442cc193._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2019-09-20T20:46:41Z"
+ content="""
+[git docs](https://git-scm.com/docs/gitattributes#_code_filter_code) say \"Depending on the version that is being filtered, the corresponding file on disk may not exist, or may have different contents. So, smudge and clean commands should not try to access the file on disk, but only act as filters on the content provided to them on standard input.\"  Are there cases where this could cause problems?
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_4_ef42e80aac54e02000c1a61b1f42aed0._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_4_ef42e80aac54e02000c1a61b1f42aed0._comment
new file mode 100644
index 0000000000..8edb2cffb9
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_4_ef42e80aac54e02000c1a61b1f42aed0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="git docs on &quot;%f&quot;"
+ date="2019-09-24T18:10:16Z"
+ content="""
+Ilya, the patch that added the text you quote (52db4b0467, clarify %f documentation, 2016-07-11) was written by Joey, so I think it's safe to say that git-annex filters don't rely on \"%f\" being an actual file on disk.
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_5_8da190f9f0cece7215df28b0bc47b151._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_5_8da190f9f0cece7215df28b0bc47b151._comment
new file mode 100644
index 0000000000..ecf06403f1
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_5_8da190f9f0cece7215df28b0bc47b151._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-09-30T19:24:53Z"
+ content="""
+The way git-annex uses the '%f' file, the smudge filter does
+not actually write to it, so that's fine. The clean filter
+does directly access the file, but this would only be a problem if git ran
+the clean filter with stdin not matching the file. As far as I know git never
+does, because the clean filter is only used by `git add` (or `commit -a`).
+
+However, the lack of clarity regarding when it's safe to really access
+'%f' is indeed a problem with git's interface; git-annex has to very
+carefully work around git's current, not fully specified behavior.
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_6_69b4455c0e54834503794f6f65de1fc8._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_6_69b4455c0e54834503794f6f65de1fc8._comment
new file mode 100644
index 0000000000..e8f54a54df
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_6_69b4455c0e54834503794f6f65de1fc8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="hello@6d9a437cebceb2fc657f93c4f30a7ba859e9309c"
+ nickname="hello"
+ avatar="http://cdn.libravatar.org/avatar/9b5d33d2215b906588426e1cac41bc0d"
+ subject="Other benefits of proposed improvements to the smudge/clean API"
+ date="2021-01-26T14:25:59Z"
+ content="""
+You forgot to mention that direct work-tree access would enable GA-like systems to use filesystem copy-on-write support to make smudge/clean filters nearly instant, and such tools much more usable.
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_7_d52b1ab7d6a186919b3edfd51347e161._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_7_d52b1ab7d6a186919b3edfd51347e161._comment
new file mode 100644
index 0000000000..6bec8cff7d
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_7_d52b1ab7d6a186919b3edfd51347e161._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="tomdhunt"
+ avatar="http://cdn.libravatar.org/avatar/02694633d0fb05bb89f025cf779218a3"
+ subject="comment 7"
+ date="2022-03-07T18:27:38Z"
+ content="""
+If you're dealing with a repository where you never intend to use unlocked files at all, does it work to just disable the smudge filter entirely?
+
+I'm currently running into the speed issues on `git add`, but I don't have any use for unlocked files in this particular use case, so I'd be happy just to turn off that whole step.
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_8_e99ecb0ac561dd670f3ea7b2915de872._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_8_e99ecb0ac561dd670f3ea7b2915de872._comment
new file mode 100644
index 0000000000..c5ed1cec56
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_8_e99ecb0ac561dd670f3ea7b2915de872._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-03-07T19:20:33Z"
+ content="""
+@tomdhunt yes:
+
+	git config --unset filter.annex.smudge
+	git config --unset filter.annex.clean
+
+But, it seems likely that `git add` would not be slow if you upgraded
+the repository version to v9 instead. Most scenarios where it is slow
+have been fixed in that version.
+
+	git-annex upgrade
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_9_ccea12d55706ab2fc1b0ba46818354a3._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_9_ccea12d55706ab2fc1b0ba46818354a3._comment
new file mode 100644
index 0000000000..e7abebedee
--- /dev/null
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_9_ccea12d55706ab2fc1b0ba46818354a3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 9"
+ date="2022-07-24T16:52:33Z"
+ content="""
+FWIW, [in dandisets/000026](https://github.com/dandi/dandisets/issues/229#issuecomment-1192971292) I provide provide some timings on committing files renames. Overall rough: pure git (no git-annex) - 1 sec, v8 - 1500 minutes, v9 - 1 minute.  The question is, since v9 is not default, how well was it tested/used in real life?  
+"""]]
diff --git a/doc/todo/git_status_smudges_unncessarily_after_unlock.mdwn b/doc/todo/git_status_smudges_unncessarily_after_unlock.mdwn
new file mode 100644
index 0000000000..2cd819e742
--- /dev/null
+++ b/doc/todo/git_status_smudges_unncessarily_after_unlock.mdwn
@@ -0,0 +1,39 @@
+After unlocking a file, `git status` runs the smudge filter. That is
+unnecessary, and when many files were unlocked, it can take a long time
+because [[git_smudge_clean_interface_suboptiomal]] means it runs git-annex
+once per file.
+
+It should be possible to avoid that, as was done with git drop in [[!commit
+1113caa53efedbe7ab1d98b74010160f20473e8d]]. I tried making Command.Unlock
+use restagePointerFile, but that did not help; git update-index does then
+smudge it during the `git annex unlock`, which is no faster (but at least
+doing it then would avoid the surprise of a slow `git status` or `git
+commit -a`). Afterwards, `git status` then smudged it again, unsure why!
+--[[Joey]]
+
+[[!tag confirmed]]
+
+> I wondered if this was still a problem in a v9 repository with
+> filter-process used instead of smudge. It's not really -- after unlocking
+> 1000 files, git status did need to refresh all 1000, but it ran
+> relatively quickly because it was able to use filter-process.
+> 
+> But, those were small files. Large files would make it slower as it pipes
+> their content though. It would be better for Command.Unlock to use 
+> restagePointerFile, so whatever price there is is paid during unlocking
+> and not unexpectedly later on.
+> 
+> I tried again making Command.Unlock use restagePointerFile, and this
+> slowed git-annex unlock. But git status did then avoid doing any more
+> smudgeing. It seems that each call to restagePointerFile is running
+> git update-index, so still one git-annex smudge per file, rather
+> than combining several together. In a v8 repo, the same amount of work
+> is done either way. In v9+, this is actually slower than before when the
+> files are small.
+> 
+> restagePointerFile was running git update-index once per file 
+> because restagePointerFile uses the git queue, and unlock 
+> also queues a git add or something, so the queue isn't able to built
+> up because two dissimilar things are being queued. This seems an
+> unnecessary behavior; it could queue up all the git adds and then
+> run restagePointerFile after them all. Implemented that, and [[done]]! --[[Joey]]
diff --git a/doc/todo/globus_special_remote_as_a___34__transport__34___layer.mdwn b/doc/todo/globus_special_remote_as_a___34__transport__34___layer.mdwn
new file mode 100644
index 0000000000..041be7edb0
--- /dev/null
+++ b/doc/todo/globus_special_remote_as_a___34__transport__34___layer.mdwn
@@ -0,0 +1,6 @@
+One of my collaborators needs to orchestrate data between local desktop and HPC cluster (you probably have heard enough already about some of the "experiences" with that NFS). Connection to the cluster goes through VPN, which is flaky (can fall within an hour or two) and requires 2FA to get in - so not that easy to transfer large amounts of data back and forth. BUT we were told that the same data is available via globus, without requiring VPNC.  So looking at https://docs.globus.org/cli/examples/ I wonder if there would be anything which would preclude having an additional special remote to provide an alternative access to the same remote (same UUID) to just take care about depositing, obtaining, and may be removing files via globus, instead of ssh.  We kinda have already similarish scenarios where we publish annex via ssh, but making it available via http for downloads.  If remote location is a typical indirect annex (not a super thin version of it without duplicate copy under .git/annex/objects), it should be quite easy I guess to figure out full path to the key (although might need to watch out for bare ones) -- should be as it was locally -- and just get the file via globus cli instead of ssh session.
+Decided to ask before jumping into trying to implement it (not that I have any globus access ATM - I think all life signs of it were gone from dartmouth sites awhile back).
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+[[!tag moreinfo]]
diff --git a/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_1_f2c68afc949f54939fc760bd0d916b89._comment b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_1_f2c68afc949f54939fc760bd0d916b89._comment
new file mode 100644
index 0000000000..b3ad72aaae
--- /dev/null
+++ b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_1_f2c68afc949f54939fc760bd0d916b89._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-04-09T14:54:51Z"
+ content="""
+It's not currently possible for two special remotes to have the same uuid,
+because the remote.log is indexed by uuid, and so their configurations would
+overlap, including the type= and remotetype= settings.
+
+But I think in this case, that may not be a problem, it seems you have a
+regular remote accessed via ssh, and you want to add a special remote with
+the same uuid that transfers from the same remote using globus. This is
+like accessing the same repo via two ssh remotes etc, should work ok.
+
+You can pass uuid=whatever to git-annex initremote to force it to use the
+same uuid as the ssh remote.
+
+(Returning to the question of two special remotes with the same uuid,
+supporting that would need some way to separate their configurations
+in remote.log into different namespaces. Seems doable.)
+"""]]
diff --git a/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_2_89be9eea4304897c639fa80db92cfe2c._comment b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_2_89be9eea4304897c639fa80db92cfe2c._comment
new file mode 100644
index 0000000000..e248e0ea41
--- /dev/null
+++ b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_2_89be9eea4304897c639fa80db92cfe2c._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-04-15T16:55:36Z"
+ content="""
+See [[todo/support_multiple_special_remotes_with_same_uuid]]
+"""]]
diff --git a/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_3_43107f1bec1ad141af2e97f715a70fe9._comment b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_3_43107f1bec1ad141af2e97f715a70fe9._comment
new file mode 100644
index 0000000000..a9b7c3ebb9
--- /dev/null
+++ b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_3_43107f1bec1ad141af2e97f715a70fe9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="RFC: how would it work for regular git remote + special remote"
+ date="2019-11-08T19:19:18Z"
+ content="""
+Added recently `--sameas` functionality provides support at the \"UUID logistics\" level, and examples in the comments exercise it for two external remotes (rsync + directory) with the same layout of annex objects.
+The original use case I am pursuing is for a regular git repository (e.g. non-bare) with \"git repository\" layout of the store (i.e. under `.git/annex/objects/`) use a special remote primarily as a transport mechanism. In our case it will be `globus`.  I really doubt it would work \"out of the box\" since AFAIK any special remote has only two possible ideas about layout of objects: its regular \"special remote layout\" (e.g. a flat list of keys or with some hash directories) or exported (such as a file tree). Only in case of `git` special remote layout would be the same, but otherwise special remote layout would be different, and \"export\" wouldn't really be the one desired (especially for placing files to the remote).
+So it seems that the only way to accomplish my mission would be to implement in the `globus` custom special remote the support of additional layout by parametrizing special remote upon initremote with e.g. `layout=local`, which would lookup location for the key in the local repository (under `.git/annex/objects`), and use it as the path for the key on the remote.
+
+Is that a correct idea Joey?  or you see a better way?
+"""]]
diff --git a/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_3_9c557a788841bd34e5fa902e171d2b52._comment b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_3_9c557a788841bd34e5fa902e171d2b52._comment
new file mode 100644
index 0000000000..20f4c5c537
--- /dev/null
+++ b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_3_9c557a788841bd34e5fa902e171d2b52._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-11-04T15:46:31Z"
+ content="""
+`initremote --sameas` can now be used to tell git-annex that two special
+remotes use the same underlying data.
+
+Is there anything else needing to be done in git-annex to let this globus
+special remote be implemented?
+"""]]
diff --git a/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_4_3bea0473d4805b1ef56b955ba30166e8._comment b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_4_3bea0473d4805b1ef56b955ba30166e8._comment
new file mode 100644
index 0000000000..63877c943e
--- /dev/null
+++ b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_4_3bea0473d4805b1ef56b955ba30166e8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-11-12T20:34:23Z"
+ content="""
+If the repository being accessed over globus uses .git/annex/objects/ 
+locations, it sounds to me like it's a git-annex repo, being accessed over
+a protocol other than ssh. A special remote that accesses remote annex
+objects could be created, and --sameas used to make the special remote have
+the same uuid as the (remote) git-annex repo.
+"""]]
diff --git a/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_5_28aabb525a1a487eaecdfe591cc7108b._comment b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_5_28aabb525a1a487eaecdfe591cc7108b._comment
new file mode 100644
index 0000000000..329cd3c40e
--- /dev/null
+++ b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_5_28aabb525a1a487eaecdfe591cc7108b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2019-11-13T04:41:56Z"
+ content="""
+> If the repository being accessed over globus uses .git/annex/objects/ locations, it sounds to me like it's a git-annex repo, being accessed over a protocol other than ssh. 
+
+That is correct.
+
+> A special remote that accesses remote annex objects could be created, and --sameas used to make the special remote have the same uuid as the (remote) git-annex repo.
+
+That is correct too. The question is either it should be a dedicated `git-annex-remote-globus-gitannex` special remote which would need to probably use the same functionality of a `git-annex-remote-globus` for actual authentication and interaction with globus (with difference largely in paths to assume) or just an option to the `git-annex-remote-globus`...?
+"""]]
diff --git a/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_6_51b2078904c6a7c0fff2dd7d38791e6b._comment b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_6_51b2078904c6a7c0fff2dd7d38791e6b._comment
new file mode 100644
index 0000000000..1f93114bef
--- /dev/null
+++ b/doc/todo/globus_special_remote_as_a___34__transport__34___layer/comment_6_51b2078904c6a7c0fff2dd7d38791e6b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-01-29T15:02:27Z"
+ content="""
+I'm not clear how the answer to that question would impact git-annex.
+
+Assuming this is built with external special remotes and/or plain git
+remotes, is there something lacking in git-annex to implement it now?
+"""]]
diff --git a/doc/todo/hidden_files.mdwn b/doc/todo/hidden_files.mdwn
new file mode 100644
index 0000000000..28832b28a2
--- /dev/null
+++ b/doc/todo/hidden_files.mdwn
@@ -0,0 +1,38 @@
+Add a `git annex hide $file` that behaves like drop, checking counter info
+and updating location log to say the current repo no longer has a file --
+but does not actually remove the content.
+
+Then `git annex unused` can be used to clean it up later. And in the
+meantime, it's still locally accessible. This can be useful if you're
+planning to need to free up space later, but want to hold onto the content
+for a while. Possibly you'll be disconnected later, so it's easier to push
+out that intent now.
+
+--
+
+TODO:
+
+* Make 100% sure this is safe. Drop, etc should never check content files
+  are present on other repos if the location log doesn't say the repo
+  has the content.
+
+* What will `git annex get` do if it's asked to get a file that has been
+  hidden?
+
+> Unless I am missing something: Make sure the data is correct (for SHA1 or other tracking) and restore locally. If that's not the case, delete and restore from remote. -- RichiH
+
+----
+
+Is 'unused' a good name? 'clean' and 'autoclean' would make more sense, imo. 'clean' deletes everything, whereas an optional 'autoclean' could try to be smart based on disk usage and/or SHA1, etc. -- RichiH
+
+> Nah, `git annex unused/dropunused` already exist.  --[[Joey]] 
+
+>> OK, in that case forget what I said. No idea about your internal policy, but feel free to delete this part of the page, then. -- RichiH
+
+
+---
+
+Revisiting old todos, I noticed this and 
+[[todo/wishlist: `git annex drop --relaxed`]]
+are basically the same idea. So gonna
+close this as a dup. [[done]] --[[Joey]]
diff --git a/doc/todo/hiding_a_repository.mdwn b/doc/todo/hiding_a_repository.mdwn
new file mode 100644
index 0000000000..55815104c2
--- /dev/null
+++ b/doc/todo/hiding_a_repository.mdwn
@@ -0,0 +1,240 @@
+In some situations it can be useful for a reposistory to not store its
+state on the git-annex branch. One example is a temporary clone that's
+going to be deleted. One way is just to not push the git-annex branch
+from the repository to anywhere, but that limits what can be done in the
+repository. For example, files might be added, and copied to public
+repositories, but then the git-annex branch would need to be pushed to
+publish them.
+
+There could be a git config to hide the current repository.
+
+## location tracking effects
+
+The main logs this would affect are for location tracking. 
+
+git-annex will mostly work the same without location tracking information
+being recorded for the local repo. Often, git-annex uses inAnnex to
+directly check if an annex object is present, rather than looking at
+location tracking. For example --in=here uses inAnnex so would still work;
+
+Of course, `git annex whereis`reports on location tracking info, so if a
+file were added to such a repo, whereis on it would report no copies. And
+I said "of course", but this may not be obvious to all users. 
+
+And there are parts of git-annex that do look at location tracking for
+the current repo, even though it's generally slower than inAnnex. Since the
+two are generally equivilant now, some general-purpose code that looks at
+locations generally has no real need to use inAnnex. One example of this
+is --copies.
+
+One thing that would certainly need to be changed is git-annex
+fsck, which notices when the location tracking information is wrong/missing and
+corrects it. (Note that unsetting the git config followed by a fsck would
+update the location logs, which could be useful to stop hiding the repo,
+but if other stuff like annex.uuid is also affected, fsck would not do
+anything about that stuff.)
+
+git-annex info is a bit of a mess from this perspecitve. Its repo list
+would not include the repo (if it was also hidden from uuid.log), but it
+would report on the number of locally present objects, while other info
+like numcopies stats and combined size of repositories are based on
+location tracking, so would not include the current repo.
+
+Looks like git-annex drop --from remote relies on the location log
+to see if there's a local copy, so a hidden repo would not be treated as a
+copy. This could be changed, but checking inAnnex here would actually slow
+it down. It could also be argued that this is a good thing since dropping
+from a remote could leave the only copy in a hidden repo. But then move
+--from should also prevent that, and I think it might not.
+
+So the question is, would adding this feature complicate git-annex too
+much, in needing to pick the right choice of inAnnex or location log
+querying, or in the user's mental model of how git-annex works? 
+
+## uuid.log
+
+To really hide a repository, it needs to not be written to uuid.log.
+
+So the config would need to be set before git-annex init.
+
+If a repository is also hidden from uuid.log, it follows that this option
+is not given a name specific to location tracking. Eg annex.hidden rather
+than annex.omit-location-logs. But that does raise the
+question about all the other places a repo's uuid could crop up in the
+git-annex branch.
+
+## everything else
+
+* remote.log: A special remote is not usable without this, and this does
+  not seem to be a config that affects what is stored about remotes, but only
+  the current repo.
+
+* trust.log: If the user sets this config, are things
+  like `git-annex trust here` supposed to refuse to work? Seems limiting,
+  and a significant source of scope creep. Maybe it would be better to
+  let the uuid be written to these, if the user chooses to set a trust.
+  After all, having some uuids in these logs, that are not described in
+  uuid.log, does not tell anyone else much, except that someone had a
+  hidden repository.
+
+* group.log, preferred-content.log, required-content.log: Same as trust.log;
+  Names in group.log do hint about how a hidden repo might be used, but if
+  the user is concerned about that they can not add their repo to groups
+  that expose information.
+
+* export.log: Same as remote.log
+
+* `*.log.rmt`, `*.log.rmet`, `*.log.cid`, `*.log.cnk`: Same as remote.log
+
+* schedule.log: Same as trust.log
+
+* activity.log: A user might be surprised that fscking a hidden repo
+  mentions its uuid here. Also it seems unnecessary info to log for a
+  hidden repo. Should be special cased if uuid.log is.
+
+* multicast.log: This includes the uuid of the current repo, when using
+  git-annex multicast. That could be surprising to a user, so probably
+  git-annex multicast would need to refuse to run in hidden repos.
+
+* difference.log: Surprisingly to me, in a clone of a repo that was initialized
+  with tunings, git-annex init adds the new repo's uuid to this log file.
+  Should be special cased if uuid.log is. Unsure yet if it will be possible
+  to avoid writing it, or if tunings and hidden repos need to be
+  incompatible features.
+
+That seems to be all. --[[Joey]]
+
+---
+
+## alternative: public/private git-annex branch separation
+
+This would need a separate index file in addition to .git/annex/index,
+call it index-private. Any logging of information that includes a hidden
+uuid would modify index-private instead. When index-private exists,
+git-annex branch queries have to read from both index and index-private,
+and can just concacentate the two. (But writes are more complicated, see below.)
+
+index-private could be committed to a git-annex-private branch, but this is
+not necessary for the single repo case. But doing that could allow for a
+group of repos that are all hidden but share information via that branch.
+
+Performance overhead seems like it would mostly be in determining if
+index-private exists and needs to be read from. And that should be
+cacheable for the life of git-annex. 
+
+Or, it could only read from index-private when the git config has the
+feature enabled. Then turning off the feature would need the user to do
+something to merge index-private into index, in order to keep using the
+repo with the info stored there. This approach also means that the user can
+temporarily disable the feature and see how the git-annex info will appear
+to others, eg see that whereis and info do not list their hidden repository.
+
+In a lot of ways this seems simpler than the approach of not writing to the
+branch. Main complication is log writes. All the log modules need to
+indicate when writes are adding information that needs to be kept private.
+
+Often a log file will be read, and then written with a new line added
+and perhaps an old line removed. Eg:
+
+	addLog file line = Annex.Branch.change file $ \b ->
+	        buildLog $ compactLog (line : parseLog b)
+
+This seems like it would need Annex.Branch.change to be passed a parameter
+indicating if it's changing the public or private log. Luckily, I think 
+all reads followed by writes do go via Annex.Branch.change, so Annex.Branch.get
+can just concacenate the two without worrying about it leaking back out in a
+later write.
+
+## networks of hidden repos
+
+There are a lot of complications involving using hidden repos as remotes.
+It may be best to not support doing it at all. Some of the complications
+are discussed below.
+
+If location tracking and other data is not stored for a hidden remote, it
+will be hard to do much useful with that remote. For example, git-annex get
+from that remote would not work. (Without setting annex-speculate-present.)
+Also some remotes depend on state being stored, like chunking data,
+encryption, etc. So setting up networks of repos that know about
+one-another but are hidden from the wider world would need some kind of
+public/private git-annex branch separation.
+
+If there's a branch such as git-annex-private that should only be pushed
+to remotes that know about the hidden repo, it invites mistakes. git push
+of matching branches would push it to any remote that happens to have a
+branch by the same name, which could even be done maliciously. Avoiding
+that would need to avoid using a named branch, and only let 
+git-annex sync push the information, to remotes it knows should receive it.
+
+A related problem is, git-annex move will update location tracking for the
+remote. If the remote is hidden, that would expose its uuid, unless
+git-annex move knew that it was and either avoided doing that, or wrote to
+the private git-annex branch. So, setting up a network of hidden repos
+would need some way to tell each of them which of the others were also
+hidden. A per-remote git config is one way, but the user would need to
+remember to set them up when setting up the remotes.
+
+Would storing a list of the uuids of hidden repos be acceptable? If there
+were a list in the git-annex branch, then it would be easier to support
+networks of hidden repos. The only information exposed would be the number
+of hidden repos and when they were added. Space used would generally be
+small, although in situations where temporary repos are being created
+frequently, and are hidden to avoid bloating the branch, there would be a
+small amount of bloat. 
+
+Alternatively, the UUID of a hidden repo could somehow encode the fact that
+it's hidden. Although this would make it hard to convert a repo from/to
+being hidden.
+
+None of the above allows for a network of hidden repos, one of which is
+part of a *different* network of hidden repos. Supporting that would be a
+major complication.
+
+Things other than the git-annex branch that can expose the existence of the
+repository:
+
+* The p2p protocol has an AUTH that includes the repository that is
+  connecting. This should be ok, since links between repositories have to be
+  set up explicitly.
+* git-annex-shell configlist will list the UUID. User has to know/guess
+  the repo exists and have an accepted ssh key.
+
+# alternative: git-annex branch filtering
+
+Different angle on this: Let the git-annex branch grow as usual. But
+provide a way to filter uuids out of the git-annex branch, producing a new
+branch.
+
+Then the user can push the filtered branch back to origin or whatever they
+want to do with it. It would be up to them to avoid making a mistake and
+letting git push automatically send git-annex to origin/git-annex.
+Maybe git has sufficient configs to let it be configured to avoid such
+mistakes, dunno. (git-annex sync would certianly be a foot shooting
+opportunity too.)
+
+> Setting remote.name.push = simple would avoid accidental pushes.
+> But if the user wanted to otherwise push matching branches, they would
+> not be able to express that with a git config. Also, `git push origin :`
+> would override that config.
+> 
+> Using a different branch name than git-annex when branch filtering is
+> enabled would be avoid most accidental pushes. And then the filtering
+> could produce the git-annex branch.
+
+The filtering would need to go back from the top commit to the last commit
+that was filtered, and remove all mentions of the uuid. The transition
+code (mostly) knows how to do that, but it doesn't preserve the history of
+commits currently, and filtering would need to preserve that.
+
+Any commits that were made elsewhere or that don't contain the UUIDs would
+keep the same trees, and should keep the same commit hashes too, as long
+as their parents are the same.
+
+This would support any networks of hidden repos that might be wanted.
+And it's *clean*.. Except it punts the potential foot shooting of
+keeping the unfiltered branch private and unpushed to the user, and it
+adds a step of needing to do the filtering before pushing.
+
+[[!tag projects/datalad]]
+
+> [[done]]; see [[tips/cloning_a_repository_privately]] --[[Joey]]
diff --git a/doc/todo/hiding_a_repository/comment_1_68636f0a35a1cd62e0390d1a752eba47._comment b/doc/todo/hiding_a_repository/comment_1_68636f0a35a1cd62e0390d1a752eba47._comment
new file mode 100644
index 0000000000..f548cd54e4
--- /dev/null
+++ b/doc/todo/hiding_a_repository/comment_1_68636f0a35a1cd62e0390d1a752eba47._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-04-16T18:29:19Z"
+ content="""
+Good Idea. In cases with a centralized repo and a lot of clients that don't directly exchange files with each other, this can be used to disable (useless) location tracking on the clients so the git-annex branch doesn't get bloated.
+
+Regarding `git annex add` in a hidden repo. I guess it will just add a empty location log for the new key to the git-annex branch, right?
+"""]]
diff --git a/doc/todo/hiding_a_repository/comment_2_5d8224fdb6c77834b3bf55b2148d9f97._comment b/doc/todo/hiding_a_repository/comment_2_5d8224fdb6c77834b3bf55b2148d9f97._comment
new file mode 100644
index 0000000000..0813b7fcd2
--- /dev/null
+++ b/doc/todo/hiding_a_repository/comment_2_5d8224fdb6c77834b3bf55b2148d9f97._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-04-16T18:42:29Z"
+ content="""
+Hmm, good point because --all looks at the location logs to get a list of
+keys, and so if it did not create the log at all, --all would not find it.
+
+So I guess it would need to write an empty log in that case, rather than
+omitting writing a log at all. Which does indicate a hidden repo added a
+file, if someone is curious about how they're being used.
+"""]]
diff --git a/doc/todo/hiding_a_repository/comment_3_64ba3f1d5099e066d554566ca818bdd6._comment b/doc/todo/hiding_a_repository/comment_3_64ba3f1d5099e066d554566ca818bdd6._comment
new file mode 100644
index 0000000000..fcc0579327
--- /dev/null
+++ b/doc/todo/hiding_a_repository/comment_3_64ba3f1d5099e066d554566ca818bdd6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="auto-expire temp repos"
+ date="2021-04-21T15:37:37Z"
+ content="""
+As a possible simpler alternative, maybe add an option to [[git-annex-dead]] to mark a repo dead from a future time onwards?  I often have temp repos created on temp cloud instances.   I mark them untrusted right after cloning, and then manually mark them dead after the cloud instance is gone.  If the latter part were automated, would that cover most of what hidden repos do?
+"""]]
diff --git a/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers.mdwn b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers.mdwn
new file mode 100644
index 0000000000..3fd55dede1
--- /dev/null
+++ b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers.mdwn
@@ -0,0 +1,12 @@
+ATM parallel download/upload is implemented via running multiple external special remotes.  If such special remote is also hungry on file ids etc we had already cases for this approach to be prohibitive and otherwise requiring various locking etc mechanisms.
+
+Some external remotes can natively support transfer of multiple files in parallel.  My use case is globus.  With globus I can queue up multiple transfers which would start happening in parallel, and then only poll on their status once in a while to see which finished and provide overall progress.  Setting up transfer queue and initiating transfer has notable overhead with globus, so transfer of many small files "one at a time" would also be very slow
+
+That is why I thought it would have been quite cool if special remotes protocol supported "queuing up" of the transfers, while reporting back to annex some transfer-id per each file, and then reporting back whenever any transfer-id is finished and potentially progress reports per each ID and/or overall. That can remove any burden from parallel execution of external special remotes and establish very efficient transfer mechanisms in some cases.
+
+Just an idea ;)
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[done]] --[[Joey]] 
diff --git a/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_1_64397d2700c9ab13885024b65d4d5adc._comment b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_1_64397d2700c9ab13885024b65d4d5adc._comment
new file mode 100644
index 0000000000..90d3b3fab1
--- /dev/null
+++ b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_1_64397d2700c9ab13885024b65d4d5adc._comment
@@ -0,0 +1,57 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-06-30T15:18:37Z"
+ content="""
+It could look like this:
+
+	> EXTENSIONS INFO ASYNC
+	< EXTENSIONS ASYNC
+	> TRANSFER RETRIEVE Key1 file
+	< TRANSFER-ASYNC Key1
+	< PROGRESS-ASYNC Key1 10
+	> TRANSFER RETRIEVE Key2 file
+	< PROGRESS-ASYNC Key1 100
+	< TRANSFER-ASYNC Key1
+	< PROGRESS-ASYNC Key2 10
+	< TRANSFER-SUCCESS RETRIEVE Key1
+	< TRANSFER-SUCCESS RETRIEVE Key2
+
+Having separate job ids does not seem necessary since it has the key.
+
+When both negotiate the ASYNC extension, then the special remote, for simplicity,
+should always use this async protocol, not mix in the non-async protocol.
+
+From when git-annex sends TRANSFER until the special remote sends TRANSFER-ASYNC,
+the special remote can use send of the other special remote messages it
+needs to in order to handle the transfer, eg DIRHASH and GETCREDS.
+git-annex will avoid starting up any other transfers until after
+TRANSFER-ASYNC. This avoids what seems like it could
+be a lot of complexity in the special remote. (Imagine if git-annex sent
+another TRANSFER at the same time the special remote had sent DIRHASH;
+the special remote would need to defer handling that TRANSFER until it
+got the reply.) 
+And after the TRANSFER-ASYNC, the special remote should refrain from 
+sending anything further for that transfer except for PROGRESS-ASYNC
+and TRANSFER-SUCCESS/TRANSFER-FAILURE.
+
+I don't think implementation in git-annex would be very hard, basically
+make a worker thread that's used for async transfers, that takes an
+external process from the pool and keeps it for its use as long as any
+transfers are running.
+
+---
+
+Note: This would be a further road block to implementating
+[[todo/more_extensive_retries_to_mask_transient_failures]], because there
+would be this one external process that's handling multiple transfers and
+killing it would stop them all rather than just the one that is wanted to
+be stopped.. 
+
+Unless the protocol included a way to cancel a
+single transfer, eg "TRANSFER CANCEL Key1".
+But then the external program would need to support canceling a transfer,
+which it could be some protocols or libraries can't do cleanly, leading to
+the same kind of resource cleanup issues that are blocking that todo
+in git-annex.
+"""]]
diff --git a/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_2_f2f2986f643c654c3d87be832687fc68._comment b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_2_f2f2986f643c654c3d87be832687fc68._comment
new file mode 100644
index 0000000000..bbf91e65c1
--- /dev/null
+++ b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_2_f2f2986f643c654c3d87be832687fc68._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="more ideas for async implementation"
+ date="2020-07-02T17:44:44Z"
+ content="""
+Thank you Joey for considering implementing this!  Some additional tune up might be desired for optimal \"performance\" if possible.  Having globus in mind: it is better to \"stage\" all the transfers TODO and then commence the transfer. So may be it could be something like this where if \"BATCH\" is appended to TRANSFER-ASYNC response from remote, at the end of \"scheduling\" all transfers for now, `git annex` would trigger actual transfer with an empty `TRANSFER-ASYNC`?:
+
+```
+> TRANSFER RETRIEVE Key1 file
+< TRANSFER-ASYNC Key1 BATCH
+> TRANSFER RETRIEVE Key2 file
+< TRANSFER-ASYNC Key2 BATCH
+> TRANSFER-ASYNC
+```
+
+Also per file progress might not be available (yet to check more details) -- there is a total progress for a job (multiple files). So may be `BATCH` could be the BATCH-ID of a kind and TRANSFER-PROGRESS be reported not for a key but for the BATCH-ID (absent overlap with KEYS values could be guaranteed by special remote by using UUIDs or alike)?
+
+Re retries and failures: may be if special remote would also return `TRANSFER-SUCCESS RETRIEVE BATCH-ID` at the end, annex could see if any KEY was not reported success on, and then retry only those?
+"""]]
diff --git a/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_3_7e07ab418734d22ab032bb655b4b3645._comment b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_3_7e07ab418734d22ab032bb655b4b3645._comment
new file mode 100644
index 0000000000..1983791958
--- /dev/null
+++ b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_3_7e07ab418734d22ab032bb655b4b3645._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-07-02T19:06:17Z"
+ content="""
+I see why you want this, but how is git-annex supposed to know when it has
+the right size batch of transfers ready?
+
+It could look at the -J number, and wait until it's sent that many
+TRANSFER requests, and call that a batch. But it could be that some jobs run
+transfers and other jobs do other things (eg CHECKPRESENT or checking
+that the content is locally present and skipping doing a download).
+Leading to either a deadlock or a long time stalled out before
+beginning any transfers.
+
+One strategy that would work for git-annex is to start the first transfer
+immediately. While that transfer is running, hold off on starting any more,
+batching up the requests. Send each batch of transfers after the last batch
+finishes. And with some messages for framing a batch of transfers for
+remotes that care.
+
+What that would naturally result in is, at -Jn, batches of size
+`[1, n-1, n-1, ..., m < n]` unless transfers were happening faster
+than git-annex was able to queue up new ones.
+
+So that's pretty good. But I don't know if it's ideal for every special
+remote.
+
+A special remote could implement the same strategy with no help from
+git-annex, and no changes to my proposed protocol. All you have to do is
+wait for that first TRANSFER request, call it a batch and start it, and
+gather the next batch, etc.
+
+Or, if you know your remote works well with a certian batch size of transfers,
+you could gather up TRANSFER requests until you have the optimal number,
+or until a timeout, and then start the batch.
+
+I don't know if that would work for globus, but it seems like a valid
+strategy for some hypothetical remotes. Since a remote can implement either
+strategy, maybe it's better to let them make use of remote-specific
+knowledge and not put the explicit batching in git-annex?
+"""]]
diff --git a/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_4_0c4110101bf810816d4568b37018211e._comment b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_4_0c4110101bf810816d4568b37018211e._comment
new file mode 100644
index 0000000000..7934e3a7f8
--- /dev/null
+++ b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_4_0c4110101bf810816d4568b37018211e._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2020-07-02T20:14:20Z"
+ content="""
+> One strategy that would work for git-annex is to start the first transfer immediately...
+
+Might be not really useful if that transfer is tiny, so I would have not bothered with complicating logic for that
+
+> Or, if you know your remote works well with a certian batch size of transfers, you could gather up TRANSFER requests until you have the optimal number, or until a timeout, and then start the batch.
+
+yes, could be done this way I guess, but would complicate special remotes implementation (reasonable tradeoff IMHO iff no easier solution is found).
+
+May be if `async` remotes were not \"parallelizable\" (i.e. only a single such remote would start even in the case of -J > 1) - it would simplify it?
+
+> I see why you want this, but how is git-annex supposed to know when it has the right size batch of transfers ready?
+
+Isn't there some point in time when `annex` knows that it is done issuing all possible TRANSFER requests it knew to issue and could just send out \"initiate TRANSFER\" to those special remotes it knows are waiting for it?  
+
+
+"""]]
diff --git a/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_5_ab2c969b5b561b75fec1d95c52598cb4._comment b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_5_ab2c969b5b561b75fec1d95c52598cb4._comment
new file mode 100644
index 0000000000..536272006d
--- /dev/null
+++ b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_5_ab2c969b5b561b75fec1d95c52598cb4._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-07-03T00:02:07Z"
+ content="""
+> May be if async remotes were not "parallelizable" (i.e. only a single
+> such remote would start even in the case of -J > 1) - it would simplify
+> it?
+
+I'm assuming only 1 that is used for transfers, others could be used for
+other things.
+
+> Isn't there some point in time when annex knows that it is done issuing all possible TRANSFER requests it knew to issue and could just send out "initiate TRANSFER" to those special remotes it knows are waiting for it?
+
+Not really, it starts as many threads as it's allowed to as soon as it has
+some files to work on, and as each thread finishes it starts a new one.
+Only time it knows it's done is after it's checked the whole tree of files,
+but that could be much much later.
+"""]]
diff --git a/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_6_877ae38938a279fa100e58c03990e81a._comment b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_6_877ae38938a279fa100e58c03990e81a._comment
new file mode 100644
index 0000000000..67853e013c
--- /dev/null
+++ b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_6_877ae38938a279fa100e58c03990e81a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-08-11T18:34:03Z"
+ content="""
+[[design/external_special_remote_protocol/async_appendix]] has a draft
+protocol extension.
+
+I improved on the design, so any and all requests can be handled async,
+or  sequentially, as the external special remote prefers. Had to add async
+job ids, but the protocol simplicity was worth it.
+
+(Implementation will be something like, a thread relaying to and from the
+special remote, with requests sent to it when it's not blocked, and with
+its async replies sent back to the corresponding requester based on the
+JobId.)
+"""]]
diff --git a/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_7_59aa5bd5ac6cfe5976666853b5ce9fdc._comment b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_7_59aa5bd5ac6cfe5976666853b5ce9fdc._comment
new file mode 100644
index 0000000000..4a1a115472
--- /dev/null
+++ b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_7_59aa5bd5ac6cfe5976666853b5ce9fdc._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2020-08-12T20:26:46Z"
+ content="""
+started implementation in the `asyncexternal` branch
+"""]]
diff --git a/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_7_c0f5b5098252df0f86528078f3c96ec7._comment b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_7_c0f5b5098252df0f86528078f3c96ec7._comment
new file mode 100644
index 0000000000..079368ed48
--- /dev/null
+++ b/doc/todo/idea__58___external_special_remote___34__async__34___protocol_for_transfers/comment_7_c0f5b5098252df0f86528078f3c96ec7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2020-08-14T18:59:37Z"
+ content="""
+ASYNC extension is implemented. The protocol went through several
+iterations and ended up at about the simplest and cleanest possible way to
+do it.
+"""]]
diff --git a/doc/todo/immediate_stream-to-sync.mdwn b/doc/todo/immediate_stream-to-sync.mdwn
new file mode 100644
index 0000000000..919651df50
--- /dev/null
+++ b/doc/todo/immediate_stream-to-sync.mdwn
@@ -0,0 +1,9 @@
+git-annex is really great for secure distributed archival, but it's missing a piece of the reliability portion: when data is generated and saved a system may crash before finishing, and some data may be lost, before the add is initiated.
+
+If there were a way to add a file at the same time as writing it -- and then at the same time stream that live data to a remote -- it would increase the utility of git-add for such uses as storing live recording and logfiles.
+
+I imagine e.g.
+
+$ cat /proc/kmsg | git annex addstreamsync livelogs/kernel-log-$(date)
+
+and kmsg would be streamed to enough remotes to meet numcopies, and hashed live .  If possible, if the system then crashed and even the entire source repo was lost, the remote would have some incomplete file and be able to complete the add properly at next sync.  Hashing the data at the same time as generating it would also speed adding any new file.
diff --git a/doc/todo/immediate_stream-to-sync/comment_1_457523845c5e63bae90ea5a84d57bf96._comment b/doc/todo/immediate_stream-to-sync/comment_1_457523845c5e63bae90ea5a84d57bf96._comment
new file mode 100644
index 0000000000..b208ded011
--- /dev/null
+++ b/doc/todo/immediate_stream-to-sync/comment_1_457523845c5e63bae90ea5a84d57bf96._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="comment 1"
+ date="2016-05-06T11:19:42Z"
+ content="""
+This could be even more powerfully implemented with a FUSE filesystem.  Then locking/unlocking concerns would go away too.
+"""]]
diff --git a/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___.mdwn b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___.mdwn
new file mode 100644
index 0000000000..2a0d724bde
--- /dev/null
+++ b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___.mdwn
@@ -0,0 +1,21 @@
+Need to import ~10TB of data from a content synced from a google storage. I have BTRFS file system (so CoW is available), and initialized it with
+
+```
+git annex initremote buckets type=directory importtree=yes encryption=none directory=../buckets/
+```
+
+and `../buckets` resides on the same mount point, so `cp --reflink=always ../buckets/....` works out nicely.
+
+But when I have ran `git annex import --from=buckets -J 10 master` I saw that
+
+- no `cp` is invoked by git-annex (according to `pstree`)
+- I have equal amount of output IO as input IO (in `dstat`), suggesting that I am actually copying data
+
+I have not done a really detailed look inside copied keys to see if they share storage extents etc, so my observation could still be wrong.
+
+Joey, is it expected to take advantage of CoW with git-annex 8.20210223-1~ndall+1 in such a case or it is still a TODO?  any "workaround"? (e.g. may be I could just cp --reflink=always, git annex add, and then do import and annex would just reuse keys already CoWed?)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_1_7a297f170720daf25f7ecf133aafc6a4._comment b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_1_7a297f170720daf25f7ecf133aafc6a4._comment
new file mode 100644
index 0000000000..d3d3918303
--- /dev/null
+++ b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_1_7a297f170720daf25f7ecf133aafc6a4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-14T17:25:26Z"
+ content="""
+It currently does not make reflinks. That should be relatively easy to fix.
+
+Of course, if you can get the content into the git-annex repository by
+other means like manual cp --reflink, git-annex will never have any reason
+to transfer the imported file from the remote, so that workaround would
+work.
+
+Also, git-annex import from directory special remote changed fairly
+recently to only hash the files and not get their contents. But an older
+version would. Anyway, when the contents do eventually need to be copied
+from it, the above still applies.
+"""]]
diff --git a/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_2_04b63e4e2092ed455d23657e2b396d3b._comment b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_2_04b63e4e2092ed455d23657e2b396d3b._comment
new file mode 100644
index 0000000000..3989117fba
--- /dev/null
+++ b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_2_04b63e4e2092ed455d23657e2b396d3b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-04-14T17:34:23Z"
+ content="""
+Er, actually the directory special remote never uses cp --reflink, even
+when it's a key/value store. That's only implemented for gets from git
+remotes currently. So some refactoring will be needed.
+"""]]
diff --git a/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_3_20e31ffc7c490215db7a3f1a0a3b813c._comment b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_3_20e31ffc7c490215db7a3f1a0a3b813c._comment
new file mode 100644
index 0000000000..db6a3d6999
--- /dev/null
+++ b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_3_20e31ffc7c490215db7a3f1a0a3b813c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment to joey response on cp --reflink workaround"
+ date="2021-04-14T18:04:49Z"
+ content="""
+> Of course, if you can get the content into the git-annex repository by other means like manual cp --reflink, git-annex will never have any reason to transfer the imported file from the remote, so that workaround would work.
+
+FWIW: doing that now.  Minor pain will come later when I will need to update it (only once again) with a new sync'ed data (some files will be added, some removed) -- to simplify my own life I will just `rm -rf` in target git-annex repo, redo `cp --reflink` and redo `datalad save` (which will take care about removing gone, and `git-annex add` on all others -- but that would take again many hours to complete even though only a handful of files will be changed)
+"""]]
diff --git a/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_3_50ae4126d701dbd3a0c9ed8770404228._comment b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_3_50ae4126d701dbd3a0c9ed8770404228._comment
new file mode 100644
index 0000000000..080f7ba901
--- /dev/null
+++ b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_3_50ae4126d701dbd3a0c9ed8770404228._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-04-14T18:09:28Z"
+ content="""
+Worth noting that `git annex import /dir` also does not use CoW. However,
+since that part of the import interface is desired to be replaced with
+importing from a special remote, I'm inclined not to go the extra mile for
+CoW there.
+
+I think I'll be able to implement the Cow before you have to workaround
+again, yarik.
+"""]]
diff --git a/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_4_fca845bb9869e8ce9a279952813ce481._comment b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_4_fca845bb9869e8ce9a279952813ce481._comment
new file mode 100644
index 0000000000..6328271bf5
--- /dev/null
+++ b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_4_fca845bb9869e8ce9a279952813ce481._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-04-14T19:33:13Z"
+ content="""
+Implemented CoW for directory special remote, comprehensively.
+"""]]
diff --git a/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_5_f1475420fd16e664b907c4f24910a8d1._comment b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_5_f1475420fd16e664b907c4f24910a8d1._comment
new file mode 100644
index 0000000000..adc6e6a7f3
--- /dev/null
+++ b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_5_f1475420fd16e664b907c4f24910a8d1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-04-14T20:07:33Z"
+ content="""
+Correction: Import from directory special remote copies the content by
+default still. But with --no-content it does not. Might be you could have
+used that, if you did not want to load the content up into your repo and
+were ok leaving it on the remote.
+"""]]
diff --git a/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_7_b57afb61d622d9f5b2555e7d80d0ff4e._comment b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_7_b57afb61d622d9f5b2555e7d80d0ff4e._comment
new file mode 100644
index 0000000000..cc412605b9
--- /dev/null
+++ b/doc/todo/import_from_directory_does_not_use_cp_--reflink__63___/comment_7_b57afb61d622d9f5b2555e7d80d0ff4e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2021-04-14T20:46:05Z"
+ content="""
+> Implemented CoW for directory special remote, comprehensively.
+
+woohoo -- I will give it a shot! (might as well just interrupt ongoing \"process\") 
+
+it is good that it copies content -- that is the point for use of CoW here - to gain a full copy of the content virtually at no (storage) cost, so if original directory gets it changed - its copy would be all nicely versioned etc in the git-annex land ;)
+"""]]
diff --git a/doc/todo/import_only_remotes_need_a_way_to_resolve_conflicts.mdwn b/doc/todo/import_only_remotes_need_a_way_to_resolve_conflicts.mdwn
new file mode 100644
index 0000000000..c0ac777658
--- /dev/null
+++ b/doc/todo/import_only_remotes_need_a_way_to_resolve_conflicts.mdwn
@@ -0,0 +1,9 @@
+If two conflicting trees get imported from an import-only remote, it can
+end up in conflict, the same as an export conflict. Except, git-annex
+export cannot be used to resolve it, as it's import-only.
+
+Seems that git-annex import should be able to resolve the conflict in this
+case. What ever tree it imports is, after all, the tree that's on the
+remote now, so just resolve the conflict to say it's the current one
+in the export log. But I've not thought through it in detail yet.
+--[[Joey]]
diff --git a/doc/todo/import_symlinks_when_importing_from_directory.mdwn b/doc/todo/import_symlinks_when_importing_from_directory.mdwn
new file mode 100644
index 0000000000..f01a47bf96
--- /dev/null
+++ b/doc/todo/import_symlinks_when_importing_from_directory.mdwn
@@ -0,0 +1,15 @@
+Following up on [[bugs/git-annex-import_imports_outside_of_directory]] (posting as a todo since the original bug was fixed):
+
+When [[`git-annex-import`|git-annex-import]] imports from a directory remote, if the tree being imported contains symlinks, import these symlinks into git as normal git symlinks.
+This way, the internal structure of the imported git tree mirrors the internal structure of the original tree, as it does when you archive the tree with `tar` or copy it with `cp -r`.
+If a tree gets imported with symlinks omitted, tools that expect files with specific names in specific subfolders may fail, if symlinks were used to meet these expectations in the original tree.
+
+At least, relative symlinks pointing into the tree being imported should be preserved.  This is the most common scenario; any reason not to include these?
+
+Absolute symlinks pointing into the tree being imported should be turned into relative symlinks to the same target, so that they still work in the repo's checkouts.
+
+Absolute symlinks pointing outside the tree are a harder case.  I would still suggest importing these as git symlinks, pointing to the same absolute target path.
+As long as the repo is checked out into a filesystem where the same absolute paths are mounted, the links will work.  That's a common scenario when all repo users use the same compute cluster with a shared filesystem.
+
+> I've decided to reject this idea, although I'm still open to discussion
+> about use cases for it. [[done]] --[[Joey]]
diff --git a/doc/todo/import_symlinks_when_importing_from_directory/comment_1_60b1a3ab291bc7eec2ba2ad6ee044bfe._comment b/doc/todo/import_symlinks_when_importing_from_directory/comment_1_60b1a3ab291bc7eec2ba2ad6ee044bfe._comment
new file mode 100644
index 0000000000..240c001570
--- /dev/null
+++ b/doc/todo/import_symlinks_when_importing_from_directory/comment_1_60b1a3ab291bc7eec2ba2ad6ee044bfe._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-01-16T17:10:22Z"
+ content="""
+This would complicate the special remote protocol with something that
+probably could only be used by the directory special remote.
+
+The unclearness about what to do about absolute symlinks suggests
+that different people might have very different opinions
+about what good behavior might be as well.
+
+I am not liking the benefit to complexity ratio of this.
+"""]]
diff --git a/doc/todo/import_tree_from_rsync_special_remote.mdwn b/doc/todo/import_tree_from_rsync_special_remote.mdwn
new file mode 100644
index 0000000000..d2238d79d3
--- /dev/null
+++ b/doc/todo/import_tree_from_rsync_special_remote.mdwn
@@ -0,0 +1,40 @@
+The rsync special remote supports exporttree; it would be useful to also
+support importtree.
+
+The adb special remote shows this is possible using just some fairly
+standard commands, although `find` and `stat` are not well enough
+standardized to work on all unixes, it would be easy to at least support
+linux.
+
+So far, the rsync special remote really only needs rsync on the server.
+And can be used with servers that lock down their shell to only 
+allow rsync to be run. It would be good to also only need rsync for
+importtree, but there are several roadblocks:
+
+* listing contents: Using rsync would involve a command like
+  `rsync --checksum -avz -i --dry-run --out-format='%C %l %M %f\n' $rsync-url empty-directory`;
+  that makes the remote rsync checksum all the files, which could be very
+  expensive. But without checksum, only mtime and size is available,
+  which is not really enough to be sure all edits to a file are imported
+  (eg a rename swap of two files that have the same mtime would not be
+  noticed).
+
+  It would be a lot nicer to use `find | stat`
+
+* retrieving file with a specific content identifier:
+  If rsync --checksum is used, git-annex can just do the same checksum
+  on the downloaded file and make sure rsync retrieved the same content
+  identifier that was requested.
+
+* store/remove/checkpresent with a content identifier:
+  If the only way available to check a content identifier is to run
+  rsync to get the current remote checksum of a file, very wide race
+  windows will be open when the file is large. So a file that is unmodified
+  at the start may get modified and that modification be overwritten.
+
+  **This is not acceptable**
+
+So, it seems that, importtree would need to be able to run commands
+other than rsync on the server. --[[Joey]]
+
+[[!tag needsthought]]
diff --git a/doc/todo/import_tree_from_rsync_special_remote/comment_1_b1f97f8d62c4e2f9bbe02955c7a4dec4._comment b/doc/todo/import_tree_from_rsync_special_remote/comment_1_b1f97f8d62c4e2f9bbe02955c7a4dec4._comment
new file mode 100644
index 0000000000..db9ea79158
--- /dev/null
+++ b/doc/todo/import_tree_from_rsync_special_remote/comment_1_b1f97f8d62c4e2f9bbe02955c7a4dec4._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-08-30T18:04:21Z"
+ content="""
+This seems more tractable if a rsync remote supports only importtree=yes
+but not also exporttree=yes.
+
+That would prevent needing to worry about git-annex making changes
+to the remote at the same time it's getting content from it. Any changes
+would be made by something else, and git-annex would only import them.
+
+store/remove would not do anything. checkpresent would perhaps always
+fail.
+"""]]
diff --git a/doc/todo/import_tree_from_rsync_special_remote/comment_2_7e62dbfc5540a8737d77f25ad2acc4af._comment b/doc/todo/import_tree_from_rsync_special_remote/comment_2_7e62dbfc5540a8737d77f25ad2acc4af._comment
new file mode 100644
index 0000000000..7d4671f077
--- /dev/null
+++ b/doc/todo/import_tree_from_rsync_special_remote/comment_2_7e62dbfc5540a8737d77f25ad2acc4af._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="importtree readonly remote folder?"
+ date="2023-01-06T14:21:35Z"
+ content="""
+I have ran into the same \"desire\" I think: to be able to `import` the read-only (to me) tree of DICOMs from a remote server reachable over ssh, and so that later on those who have a clone of the repository and have access to that server could easily `annex get` necessary load.  Am I right in my importtree-ignorant thinking that if `rsync` special remote supports `importtree` mode -- it would also work fine when I have only read-only access to the remote folder?
+"""]]
diff --git a/doc/todo/import_tree_from_rsync_special_remote/comment_3_1d3acf47e3eff3680c1639de12823940._comment b/doc/todo/import_tree_from_rsync_special_remote/comment_3_1d3acf47e3eff3680c1639de12823940._comment
new file mode 100644
index 0000000000..2420173ae5
--- /dev/null
+++ b/doc/todo/import_tree_from_rsync_special_remote/comment_3_1d3acf47e3eff3680c1639de12823940._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-06-23T16:33:32Z"
+ content="""
+@yarikoptic yes, importtree remotes can be read-only.
+
+I do think this would be a good reason to implement
+[[importtree_only_remotes]].
+"""]]
diff --git a/doc/todo/import_tree_preferred_content_expansions.mdwn b/doc/todo/import_tree_preferred_content_expansions.mdwn
new file mode 100644
index 0000000000..4ff04ffc82
--- /dev/null
+++ b/doc/todo/import_tree_preferred_content_expansions.mdwn
@@ -0,0 +1,17 @@
+Importing a tree from a special remote
+when it has a preferred content configured currently only works when the
+expression does not use any terms that operate on keys.
+(Eg things like copies=).
+
+[[!commit e06feb7316af35b1277b7159a74c216c8f2e7422]]
+implemented that. Could it be extended to also support
+using it with an expression that does operate on keys?
+
+This would probably entail making any term of the expression that needs a
+key evaluate to true. Then it would import all files
+(that match also terms that don't need a key). After the import, it may
+turn out that the special remote doesn't want to contain particular content
+that was imported from it, and it would make sense that an export to the
+special remote would remove those files. --[[Joey]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/import_tree_preferred_content_expansions/comment_1_df8ca8665e1dfc530a832b6d24d60ea4._comment b/doc/todo/import_tree_preferred_content_expansions/comment_1_df8ca8665e1dfc530a832b6d24d60ea4._comment
new file mode 100644
index 0000000000..7e9b4507a4
--- /dev/null
+++ b/doc/todo/import_tree_preferred_content_expansions/comment_1_df8ca8665e1dfc530a832b6d24d60ea4._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-12-18T18:02:40Z"
+ content="""
+Hmm, consider for example a camera. If the user wants to import all jpeg
+files from it, and not export to it jpeg files that have a copy in an
+archive, they might use:
+
+	not copies=archive:1 and include=*.jpeg
+
+But on import, if "copies=archive:1" were made to evaluate to true
+as suggested here, then this expression would not match, and so 
+nothing would be imported.
+
+Seems that the approach needs to be instead to traverse the expression
+and prune terms that operate on keys. So convert the example
+above to "include=*.jpeg".
+
+How to prune in some other cases:
+
+	not (copies=archive:1 and copies=backup:1) => anything
+
+	not (copies=archive:1 and include=*.jpeg) => not (include=*.jpeg)
+
+	not (copies=archive:1 or include=*.jpeg) => not (include=*.jpeg)
+	
+	not ((not copies=archive:1) or include=*.jpeg) => not (include=*.jpeg)
+"""]]
diff --git a/doc/todo/importfeed_needs_more_memory_the_more_urls_there_are.mdwn b/doc/todo/importfeed_needs_more_memory_the_more_urls_there_are.mdwn
new file mode 100644
index 0000000000..eaca6becb1
--- /dev/null
+++ b/doc/todo/importfeed_needs_more_memory_the_more_urls_there_are.mdwn
@@ -0,0 +1,19 @@
+git-annex tries to run in a constant amount of memory, however `knownUrls`
+loads all urls ever seen into a list, so the more urls there are, the more
+memory `git annex importfeed` will need.
+
+This is probably not a big problem in practice, but seems worth doing
+something about if somehow possible.
+
+Unfortunately, can't use a bloom filter, because a false positive would
+prevent importing an url that has not been imported before. A sqlite
+database would work, but would need to be updated whenever the git-annex
+branch is changed. --[[Joey]]
+
+> A sqlite database that is updated by diffing would probably also speed up
+> the stage of importfeed where it gathers known urls. That can be
+> significantly slow in large repos. So I think worth doing.
+
+[[!tag confirmed]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/importfeed_parallell.mdwn b/doc/todo/importfeed_parallell.mdwn
new file mode 100644
index 0000000000..832a2a217a
--- /dev/null
+++ b/doc/todo/importfeed_parallell.mdwn
@@ -0,0 +1,5 @@
+Make git-annex importfeed support -J. Ideally, when run with multiple feed
+utls, it would check them in parallel, and also parallelize download of new
+items found in the feeds. --[[Joey]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/importtree_only_remotes.mdwn b/doc/todo/importtree_only_remotes.mdwn
new file mode 100644
index 0000000000..8f140c9450
--- /dev/null
+++ b/doc/todo/importtree_only_remotes.mdwn
@@ -0,0 +1,79 @@
+Currently for a special remote to support being configured
+with exporttree=no importtree=yes, it needs to implement the
+ImportActions interface, which uses ContentIdentifiers
+for safety and includes some methods that are only needed
+for exporttree=yes.
+
+Few special remotes support that interface, and probably a lot of them 
+just can't; they don't have something that can be used as a ContentIdentifier,
+or lack the necessary atomicity properties to implement it safely.
+(For example, `storeExportWithContentIdentifier` has a list of old
+ContentIdentifiers that are allowed to be overwritten, and requires
+that other content does not get overwritten.)
+
+The external special remote protocol does not support that interface
+yet, due to its complexity and also because noone has requested it.
+(There is a draft protocol extension for export and import, see 
+<https://git-annex.branchable.com/design/external_special_remote_protocol/export_and_import_appendix/#index2h2>)
+(See also [[todo/add_import_tree_to_external_special_remote_protocol]])
+
+A simpler interface that supoorts only importtree=yes without needing to
+worry about exporttree=yes, could let a lot more special remotes support
+tree import. (For example [[todo/import_tree_from_rsync_special_remote]].)
+
+Such a special remote could be populated in any way by something outside
+git-annex, and `git annex import --from remote` would download the content
+and generate a remote tracking branch. Once imported, other clones could
+use `git annex get` to download files from the special remote.
+
+Bearing in mind that since something is writing to the special remote, any
+file on it could be overwritten at any point, so such a get may download
+the wrong content. (So the remote should have retrievalSecurityPolicy =
+RetrievalVerifiableKeysSecure to make downloads be verified well enough.)
+
+I said this would not use a ContentIdentifier, but it seems it needs some
+simple form of ContentIdentifier, which could be just an mtime.
+Without any ContentIdentifier, it seems that each time 
+`git annex import --from remote` is run, it would need to re-download
+all files from the remote, because it would have no way of knowing
+if it had seen a version of a file before. This ContentIdentifier would
+be used only to avoid re-downloading when importing. It would not be used
+by any other methods. It could even be a dummy value if re-downloading
+every file on import is acceptable.
+
+What is needed in such an interface?
+
+	listImportableContents :: Annex (Maybe (ContentIdentifier, ImportableContents ByteSize))
+	-- Retrieves content from an import location to a file.
+	-- The content retrieved could be anything; it needs to be
+	-- strongly verified if this is used to download a particular Key
+	-- that was at one point stored on the remote, since the content
+	-- of the remote could change at any time.
+	-- (The MeterUpdate does not need to be used if 
+        -- sequentially to the file.)
+	-- Throws exception on failure.
+	retrieveImport :: ImportLocation -> FilePath -> MeterUpdate -> Annex ()
+	-- Checks if anything is present on the remote at the specified
+	-- ImportLocation. It may check the size or other characteristics
+        -- of the Key, but does not need to guarantee that the content on
+        -- the remote is the same as the Key's content.
+        -- Throws an exception if the remote cannot be accessed.
+	checkPresentImport :: Key -> ImportLocation -> Annex Bool
+
+listImportableContents is unchanged, and checkPresentImport above
+is identical to checkPresentExport. retrieveImport is very similar
+to retrieveExport, except that the content retrieved is not guaranteed
+to be the same as the content of any key. Actually, it may be an identical
+interface; the only thing I can find that uses retrieveExport forces
+verification of the content retrived since it could have been changed by
+another writer.
+
+The similarity with interface that we already have suggests that
+perhaps this does not need changes to Types.Remote to implement.
+It could be done as a Remote.Helper.SimpleImport that takes those
+3 methods and translates them to the current interface.
+Or by complicating Remote.Helper.ExportImport further..
+--[[Joey]]
+
+[[!tag confirmed]]
+[[!tag projects/dandi/potential]]
diff --git a/doc/todo/improve_memory_usage_of_--all.mdwn b/doc/todo/improve_memory_usage_of_--all.mdwn
new file mode 100644
index 0000000000..13dbe6250f
--- /dev/null
+++ b/doc/todo/improve_memory_usage_of_--all.mdwn
@@ -0,0 +1,23 @@
+`git annex unused --from=$remote` and `git annex info $remote`
+buffer the list of keys that have uncommitted journalled changes
+in memory. This is due to Annex.Branch.files's which reads all the
+files in the journal into a buffer.
+
+Note that the list of keys in the branch *does* stream in, so this
+is only really a problem when using annex.alwayscommit=false to build
+up big git-annex branch commits via the journal. Or using annex.private,
+since the private journal can build up a lot of keys in it.
+
+An attempt at making it stream via unsafeInterleaveIO failed miserably
+and that is not the right approach. This would be a good place to use
+ResourceT, but it might need some changes to the Annex monad to allow
+combining the two. --[[Joey]]
+
+> This used to also affect --all and using git-annex in a bare repo, but
+> that was avoided by using the overBranchFileContents interface. This
+> suggests that changing to that interface in unused and info would be a
+> solution.
+
+[[!tag confirmed]]
+
+[[!meta title="improve memory usage of unused and info when the journal contains a lot of files"]]
diff --git a/doc/todo/improve_unused_for_special_remotes.mdwn b/doc/todo/improve_unused_for_special_remotes.mdwn
new file mode 100644
index 0000000000..88bf5373ca
--- /dev/null
+++ b/doc/todo/improve_unused_for_special_remotes.mdwn
@@ -0,0 +1,29 @@
+A remote like the directory special remote can have objects that have not
+been fully transferred to it by an interrupted copy, that linger until the
+copy is re-run and the content gets fully sent to the remote. It would be
+good if `git-annex unused` could find and clean up such things, like it
+does for incomplete transfers into a git-annex repository.
+
+In the directory special remote, these are files named "tmp/$key/$key".
+
+This would need to be an extension to the remote interface to add an action
+to find when a key has such a file, and an action to delete one of them.
+
+A problem is that any such file might actually still be in the process
+of being sent, perhaps from a different repository than the one where
+`git-annex unused` is being run. So deleting such a file could cause that
+transfer to fail. This problem seems unavoidable generally.
+
+----
+
+It's also possible for a special remote to get keys stored in it which
+git-annex does not know about. For example, in a temporary clone of the
+git-annex repository, add a new file. Send it to the special remote. Then
+delete the temporary clone.
+
+`git-annex unused --from` can't detect those keys, because it can only ask
+the special remote about presence of keys that it knows about.
+
+Might it be possible to solve both problems together? Eg, add an action
+that has the special remote list all keys and partial keys present in it.
+--[[Joey]]
diff --git a/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output.mdwn b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output.mdwn
new file mode 100644
index 0000000000..8603b0f591
--- /dev/null
+++ b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output.mdwn
@@ -0,0 +1,21 @@
+ATM errors are output into stderr while json record lacks any hints on what went wrong
+
+[[!format sh """
+$> git annex add --json longfilenametogetlotsoferrorsandevenlonger4 
+  longfilenametogetlotsoferrorsandevenlonger4: setFileMode: permission denied (Operation not permitted)
+{"command":"add","success":false,"file":"longfilenametogetlotsoferrorsandevenlonger4"}
+"""]]
+
+would be nice(r) to have
+
+[[!format sh """
+$> git annex add --json longfilenametogetlotsoferrorsandevenlonger4 
+{"command":"add","success":false,"file":"longfilenametogetlotsoferrorsandevenlonger4", "msg": "setFileMode: permission denied (Operation not permitted)"}
+"""]]
+or may be even an explicit "errormsg" or alike instead of just a generic "msg"
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_1_f02e43b68c219b2d7d65ea868fac125f._comment b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_1_f02e43b68c219b2d7d65ea868fac125f._comment
new file mode 100644
index 0000000000..eeaafa9ed1
--- /dev/null
+++ b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_1_f02e43b68c219b2d7d65ea868fac125f._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-02-08T16:59:16Z"
+ content="""
+Is the benefit of doing this being able to correlate the error message with
+the filename whose processing caused the error?
+
+For that benefit to be realized, the error message would have to be included
+in the same json object with the file being processed. If a separate json
+object were emitted containing only the error message it would not be clear
+what file it was related to (especially when git-annex is running
+concurrent jobs), and so that does not seem any better than
+output to stderr.
+
+Looks like implementation would just involve making outputError 
+check if there is a jsonBuffer, and add the error message to it,
+probably using an array since there could be multiple warning messages.
+
+I kind of feel like they should still go to stderr in addition to any json
+output, because any existing json consumers may rely on the current stderr
+behavior to let the user know what went wrong.
+"""]]
diff --git a/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_2_3a7043652c692796b1a438a2c4c26828._comment b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_2_3a7043652c692796b1a438a2c4c26828._comment
new file mode 100644
index 0000000000..0dbd715bf7
--- /dev/null
+++ b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_2_3a7043652c692796b1a438a2c4c26828._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-02-08T18:06:54Z"
+ content="""
+yes -- I could have been clearer that association to the file (if present, may be error is generic and still would be worth to communicate via a simple json message, alike recently added INFO passed from custom special remotes) would be valuable!
+As for stderr output -- would lead to duplication (we just changed to output at least a \"tip\" of stderr output which might be heavy).  If it is a matter of not breaking tools which would not support this new behavior, having a config or --option-hate-to-suggest-to-addone, would be  valuable so we could disable \"double-casting\" the error messages
+"""]]
diff --git a/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_3_2d41d67dcb6e700b1ecda3106e444a5e._comment b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_3_2d41d67dcb6e700b1ecda3106e444a5e._comment
new file mode 100644
index 0000000000..d3872b23e7
--- /dev/null
+++ b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_3_2d41d67dcb6e700b1ecda3106e444a5e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-02-16T16:50:27Z"
+ content="""
+A problem with this idea is that error messages are relatively uncommon,
+and if they're hidden away in an extra field of an existing json message,
+it would be easy for the consumer to forget to handle that uncommon case.
+
+Note that git-annex currently doesn't document the actual json structure it
+uses, which is more or less ok because any given git-annex subcommand will
+always output the same json structure (except some note fields that
+only sometimes appear, whose data is targeted at humans).
+It's self-documenting. Using json for errors breaks that pattern.
+"""]]
diff --git a/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_4_c2e5041a07787ae84f85b898b1aae6b7._comment b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_4_c2e5041a07787ae84f85b898b1aae6b7._comment
new file mode 100644
index 0000000000..8d0d2faa5b
--- /dev/null
+++ b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_4_c2e5041a07787ae84f85b898b1aae6b7._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-02-16T17:29:56Z"
+ content="""
+Currently when there's an exception in processing a file, the error is thrown
+and then caught and output to stderr, and this prevents the accumulated
+json buffer for the file from being output, since the processing never
+finishes. So, you get some error message on stderr, and no indication
+in the json what file it belongs to.
+
+So, perhaps an easier fix would be to emit the json buffer in this case
+after the error message. Then stderr output, whether error or warning,
+would always precede the json for the same file.
+
+The consumer would need to use select() over stdin+stderr to observe
+the order they were interleaved. May be too much to expect consumers
+to get that right. Oh, and still would not help untangle the stream
+when run with -J.
+"""]]
diff --git a/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_5_429e42b9c1989dade01300f08fc3c13c._comment b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_5_429e42b9c1989dade01300f08fc3c13c._comment
new file mode 100644
index 0000000000..a1d9edc00a
--- /dev/null
+++ b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_5_429e42b9c1989dade01300f08fc3c13c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-02-16T17:59:43Z"
+ content="""
+I think I'm tending toward adding a new --json-error-messages option, and
+making it add "error-messages:[]" to the json when there are no errors,
+thus keeping the json self-documenting.
+
+The json buffer will need to be flushed in the exception handler,
+as noted in my previous comment.
+"""]]
diff --git a/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_6_3d5a33476a3fa773fda1e5f7a2d8c453._comment b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_6_3d5a33476a3fa773fda1e5f7a2d8c453._comment
new file mode 100644
index 0000000000..f7d965f3b7
--- /dev/null
+++ b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_6_3d5a33476a3fa773fda1e5f7a2d8c453._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2018-02-16T18:42:28Z"
+ content="""
+FWIW `--json-error-messages` would be great to have. 
+
+`The consumer would need to use select() over stdin+stderr to observe the order they were interleaved.` would not work for us atm without major refactoring (if possible at all without significant pains)
+"""]]
diff --git a/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_7_246e35f32f77af3b2924577b1bf45001._comment b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_7_246e35f32f77af3b2924577b1bf45001._comment
new file mode 100644
index 0000000000..7bbe0e00cc
--- /dev/null
+++ b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_7_246e35f32f77af3b2924577b1bf45001._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2018-02-19T19:49:11Z"
+ content="""
+Basic --json-error-messages implemented after 4 hours work.
+
+Still needing to be done:
+
+* A few commands like `git annex info` have a custom json outputter,
+  and may not output the error-messages field by default, or may not make
+  sense to support the option.
+* Flush json buffer after fatal error.
+"""]]
diff --git a/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_8_2e0ec2bb51a2a06184b94710616f211c._comment b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_8_2e0ec2bb51a2a06184b94710616f211c._comment
new file mode 100644
index 0000000000..b66f78fef1
--- /dev/null
+++ b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_8_2e0ec2bb51a2a06184b94710616f211c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2018-02-20T17:00:12Z"
+ content="""
+Testing, both of the cases in my previous message were actually already
+working as desired. I think it's done!
+"""]]
diff --git a/doc/todo/incremental_hashing_for_add.mdwn b/doc/todo/incremental_hashing_for_add.mdwn
new file mode 100644
index 0000000000..fae818593a
--- /dev/null
+++ b/doc/todo/incremental_hashing_for_add.mdwn
@@ -0,0 +1,40 @@
+When `git-annex filter-process` is enabled (v9 and above), `git add` pipes
+the content of files into it, but that's thrown away, and the file is read
+again by git-annex to generate a hash. It would improve performance to hash
+the content provided via the pipe.
+
+When filter-process is not enabled, `git-annex smudge --clean` reads
+the file to hash it, then reads it a second time to copy it into
+.git/annex/objects. When annex.addunlocked is enabled, `git annex add`
+does the same. It would improve performance to read once and copy and
+hash at the same time.
+
+The `incrementalhash` branch has a start at implementing this.
+I lost steam on this branch when I realized that it would need to
+re-implement Annex.Ingest.ingest in order to populate
+.git/annex/objects/. And it's not as simple as writing an object file
+and moving it into place there, because annex.thin means a hard link should
+be made, and if the filesystem supports CoW, that should be used rather
+than writing the file again.
+
+A benchmark on Linux showed that `git add` of a 1 gb file 
+is about 5% slower with filter-process enabled than it is 
+with filter-process disabled. That's due to the piping overhead to 
+filter-process ([[todo/git_smudge_clean_interface_suboptiomal]]).
+`git-annex add` with `annex.addunlocked` has similar performance
+as `git add` with filter-process disabled.
+
+`git-annex add` without `annex.addunlocked` is about 25% faster than those,
+and only reads the file once, but it also does not copy the file, so of
+course it's faster, and always will be. 
+
+Probably disk cache helps them a fair amount, unless it's too small.
+So it's not clear how much implementing this would really speed them up.
+
+This does not really affect default configurations.
+Performance is only impacted when annex.addunlocked or 
+annex.largefiles is configured, and in a few cases 
+where an already annexed file is added by `git add` or `git commit -a`.
+
+So is the complication of implementing this worth it? Users who
+need maximum speed can use `git-annex add`.
diff --git a/doc/todo/incremental_hashing_for_add/comment_1_d00827f5edd7b270aa6dfc011e7c9f22._comment b/doc/todo/incremental_hashing_for_add/comment_1_d00827f5edd7b270aa6dfc011e7c9f22._comment
new file mode 100644
index 0000000000..690fb7d1e7
--- /dev/null
+++ b/doc/todo/incremental_hashing_for_add/comment_1_d00827f5edd7b270aa6dfc011e7c9f22._comment
@@ -0,0 +1,449 @@
+[[!comment format=mdwn
+ username="adina.wagner@2a4cac6443aada2bd2a329b8a33f4a7b87cc8eff"
+ nickname="adina.wagner"
+ avatar="http://cdn.libravatar.org/avatar/80b124ad61d6008fa0f6f0b4b0f7c2ef"
+ subject="A few Windows benchmarks"
+ date="2021-11-29T22:17:39Z"
+ content="""
+Following 
+ [https://git-annex.branchable.com/bugs/Windows__58___substantial_per-file_cost_for___96__add__96__/#comment-7e6fd13d8b60d99cbc5e642e1d76f10e](https://git-annex.branchable.com/bugs/Windows__58___substantial_per-file_cost_for___96__add__96__/#comment-7e6fd13d8b60d99cbc5e642e1d76f10e) I've run a few quick benchmarks for ``git add`` with and without the filter.annex.process setting.
+I'm using a Levono Thinkpad T14 with Windows 10 Pro Version 20H2, OS build 19042.1348. It has a AMD Ryzen 7 PRO 4750U with Radeon Graphics 1.70 GHz and 16GB RAM. It ran on battery when I tested this.
+
+<details><summary> Relevant software </summary>
+
+git-annex:
+
+```
+git-annex version: 8.20211117-gc3af94eff
+build flags: Assistant Webapp Pairing TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 2 3 4 5 6 7
+```
+
+Git:
+
+```
+git version 2.34.0.windows.1
+cpu: x86_64
+built from commit: 7dad2af5e8ae15d5f1e1ce1980d1d873b9e00cb5
+sizeof-long: 4
+sizeof-size_t: 8
+shell-path: /bin/sh
+feature: fsmonitor--daemon
+```
+
+The machine is pretty much brand new, there is no Antivirus, and very little other software other than git and git-annex. [It is sometimes moody](https://github.com/datalad/datalad/issues/5994#issuecomment-974205491) but today felt fast.
+
+</details>
+
+I created files of different sizes from 1MB to 50GB; added them sequentially into the same repo; on a busy machine running the datalad test suite in the background. There are more timings for \"with config\" because there was an additional global setting I forgot to remove initially, and I only added really large files in a later runs, so I have a few more timings for smaller files.
+
+<details><summary> What I ran </summary>
+
+```
+(sorry for this embarrassing script - I hate windows and have no clue how to use it productively)
+git config --system --unset  filter.annex.process
+git config --list
+git init withoutconfig
+cd withoutconfig
+git annex init 
+fsutil file createnew 1MB 1048576
+fsutil file createnew 100MB 104857600 
+fsutil file createnew 500MB 524288000
+fsutil file createnew 1GB 1073741824
+fsutil file createnew 5GB 5368709120
+fsutil file createnew 10GB 10737418240
+fsutil file createnew 20GB 21474836480
+fsutil file createnew 50GB 53687091200
+ptime git -c annex.largefiles=anything add 1MB
+ptime git -c annex.largefiles=anything add 100MB
+ptime git -c annex.largefiles=anything add 500MB
+ptime git -c annex.largefiles=anything add 1GB
+ptime git -c annex.largefiles=anything add 5GB
+ptime git -c annex.largefiles=anything add 10GB
+ptime git -c annex.largefiles=anything add 20GB
+ptime git -c annex.largefiles=anything add 50GB
+cd ..
+
+rmdir /s withoutconfig
+
+git config --system filter.annex.process \"git-annex filter-process\"
+git config --list
+git init withconfig
+cd withconfig
+git annex init 
+fsutil file createnew 1MB 1048576
+fsutil file createnew 100MB 104857600 
+fsutil file createnew 500MB 524288000
+fsutil file createnew 1GB 1073741824
+fsutil file createnew 5GB 5368709120
+fsutil file createnew 10GB 10737418240
+fsutil file createnew 20GB 21474836480
+fsutil file createnew 50GB 53687091200
+ptime git -c annex.largefiles=anything add 1MB
+ptime git -c annex.largefiles=anything add 100MB
+ptime git -c annex.largefiles=anything add 500MB
+ptime git -c annex.largefiles=anything add 1GB
+ptime git -c annex.largefiles=anything add 5GB
+ptime git -c annex.largefiles=anything add 10GB
+ptime git -c annex.largefiles=anything add 20GB
+ptime git -c annex.largefiles=anything add 50GB
+
+rmdir /s withconfig
+```
+</details>
+
+**without config:**
+
+- 1MB -> 0.969s / 1.027s
+- 100MB -> 1.676s / 1.760s
+- 500MB -> 4.607s / 4.645s
+- 1GB -> 5.473s / 5.834s
+- 5GB -> 29.869s / 26.916s
+- 10GB -> 54.708s / 54.275
+- 20GB -> 104.860s / 105.074s
+- 50GB -> 313.757s / 256.739 s
+
+**with config:**
+
+- 1MB ->  0.316s / 0.302s / 0.068s / 1.012s
+- 100MB -> 1.006s / 0.951s / 1.033s / 1.875s
+- 500MB -> 3.141s / 3.417s / 4.762s / 5.131s
+- 1GB -> 7.257s / 7.11s / 9.610s / 6.053s
+- 5GB ->  34.450s / 36.78 / 4.852s (really no clue why, not a typo) / 34.925s
+- 10GB -> 62.202 / 76.007s
+- 20GB -> 127.382s / 135.851s
+- 50GB -> 374.773 / 350.991s
+
+
+<details><summary> example run protocol </summary>
+
+
+```
+C:\Users\adina\temp\gitannexbenchmarks>git config --system filter.annex.process \"git-annex filter-process\"
+
+C:\Users\adina\temp\gitannexbenchmarks>git config --list
+diff.astextplain.textconv=astextplain
+filter.lfs.clean=git-lfs clean -- %f
+filter.lfs.smudge=git-lfs smudge -- %f
+filter.lfs.process=git-lfs filter-process
+filter.lfs.required=true
+http.sslbackend=openssl
+http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
+core.autocrlf=true
+core.fscache=true
+core.symlinks=true
+pull.rebase=false
+credential.helper=manager-core
+credential.https://dev.azure.com.usehttppath=true
+init.defaultbranch=master
+filter.annex.process=git-annex filter-process
+user.email=adina.wagner@t-online.de
+user.name=Adina Wagner
+hub.oauthtoken=cd2a3bdefd55af090f495e9f36454f73b5a404dc
+alias.co=checkout
+alias.st=status
+core.symlinks=true
+core.fscache=true
+filter.annex.process=git-annex filter-process
+
+C:\Users\adina\temp\gitannexbenchmarks>
+C:\Users\adina\temp\gitannexbenchmarks>git init withconfig
+Initialized empty Git repository in C:/Users/adina/temp/gitannexbenchmarks/withconfig/.git/
+
+C:\Users\adina\temp\gitannexbenchmarks>cd withconfig
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>git annex init
+init
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Disabling core.symlinks.
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Switched to branch 'adjusted/master(unlocked)'
+ok
+(recording state in git...)
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>fsutil file createnew 1MB 1048576
+File C:\Users\adina\temp\gitannexbenchmarks\withconfig\1MB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>fsutil file createnew 100MB 104857600
+File C:\Users\adina\temp\gitannexbenchmarks\withconfig\100MB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>fsutil file createnew 500MB 524288000
+File C:\Users\adina\temp\gitannexbenchmarks\withconfig\500MB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>fsutil file createnew 1GB 1073741824
+File C:\Users\adina\temp\gitannexbenchmarks\withconfig\1GB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>fsutil file createnew 5GB 5368709120
+File C:\Users\adina\temp\gitannexbenchmarks\withconfig\5GB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>fsutil file createnew 10GB 10737418240
+File C:\Users\adina\temp\gitannexbenchmarks\withconfig\10GB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>fsutil file createnew 20GB 21474836480
+File C:\Users\adina\temp\gitannexbenchmarks\withconfig\20GB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>fsutil file createnew 50GB 53687091200
+File C:\Users\adina\temp\gitannexbenchmarks\withconfig\50GB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>ptime git -c annex.largefiles=anything add 1MB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 1MB ===
+warning: LF will be replaced by CRLF in 1MB.
+The file will have its original line endings in your working directory
+
+Execution time: 1.012 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>ptime git -c annex.largefiles=anything add 100MB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 100MB ===
+warning: LF will be replaced by CRLF in 100MB.
+The file will have its original line endings in your working directory
+
+Execution time: 1.875 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>ptime git -c annex.largefiles=anything add 500MB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 500MB ===
+warning: LF will be replaced by CRLF in 500MB.
+The file will have its original line endings in your working directory
+
+Execution time: 5.131 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>ptime git -c annex.largefiles=anything add 1GB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 1GB ===
+warning: LF will be replaced by CRLF in 1GB.
+The file will have its original line endings in your working directory
+
+Execution time: 6.053 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>ptime git -c annex.largefiles=anything add 5GB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 5GB ===
+warning: LF will be replaced by CRLF in 5GB.
+The file will have its original line endings in your working directory
+
+Execution time: 34.925 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>ptime git -c annex.largefiles=anything add 10GB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 10GB ===
+warning: LF will be replaced by CRLF in 10GB.
+The file will have its original line endings in your working directory
+
+Execution time: 62.202 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>ptime git -c annex.largefiles=anything add 20GB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 20GB ===
+warning: LF will be replaced by CRLF in 20GB.
+The file will have its original line endings in your working directory
+
+Execution time: 127.382 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withconfig>ptime git -c annex.largefiles=anything add 50GB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 50GB ===
+warning: LF will be replaced by CRLF in 50GB.
+The file will have its original line endings in your working directory
+
+Execution time: 374.773 s
+
+
+C:\Users\adina\temp\gitannexbenchmarks>git config --list
+diff.astextplain.textconv=astextplain
+filter.lfs.clean=git-lfs clean -- %f
+filter.lfs.smudge=git-lfs smudge -- %f
+filter.lfs.process=git-lfs filter-process
+filter.lfs.required=true
+http.sslbackend=openssl
+http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
+core.autocrlf=true
+core.fscache=true
+core.symlinks=true
+pull.rebase=false
+credential.helper=manager-core
+credential.https://dev.azure.com.usehttppath=true
+init.defaultbranch=master
+user.email=adina.wagner@t-online.de
+user.name=Adina Wagner
+hub.oauthtoken=cd2a3bdefd55af090f495e9f36454f73b5a404dc
+alias.co=checkout
+alias.st=status
+core.symlinks=true
+core.fscache=true
+
+C:\Users\adina\temp\gitannexbenchmarks>git init withoutconfig
+Initialized empty Git repository in C:/Users/adina/temp/gitannexbenchmarks/withoutconfig/.git/
+
+C:\Users\adina\temp\gitannexbenchmarks>cd withoutconfig
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>git annex init
+init
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Disabling core.symlinks.
+
+  Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+Switched to branch 'adjusted/master(unlocked)'
+ok
+(recording state in git...)
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>fsutil file createnew 1MB 1048576
+File C:\Users\adina\temp\gitannexbenchmarks\withoutconfig\1MB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>fsutil file createnew 100MB 104857600
+File C:\Users\adina\temp\gitannexbenchmarks\withoutconfig\100MB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>fsutil file createnew 500MB 524288000
+File C:\Users\adina\temp\gitannexbenchmarks\withoutconfig\500MB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>fsutil file createnew 1GB 1073741824
+File C:\Users\adina\temp\gitannexbenchmarks\withoutconfig\1GB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>fsutil file createnew 5GB 5368709120
+File C:\Users\adina\temp\gitannexbenchmarks\withoutconfig\5GB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>fsutil file createnew 10GB 10737418240
+File C:\Users\adina\temp\gitannexbenchmarks\withoutconfig\10GB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>fsutil file createnew 20GB 21474836480
+File C:\Users\adina\temp\gitannexbenchmarks\withoutconfig\20GB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>fsutil file createnew 50GB 53687091200
+File C:\Users\adina\temp\gitannexbenchmarks\withoutconfig\50GB is created
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>ptime git -c annex.largefiles=anything add 1MB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 1MB ===
+warning: LF will be replaced by CRLF in 1MB.
+The file will have its original line endings in your working directory
+
+Execution time: 1.027 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>ptime git -c annex.largefiles=anything add 100MB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 100MB ===
+warning: LF will be replaced by CRLF in 100MB.
+The file will have its original line endings in your working directory
+
+Execution time: 1.760 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>ptime git -c annex.largefiles=anything add 500MB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 500MB ===
+warning: LF will be replaced by CRLF in 500MB.
+The file will have its original line endings in your working directory
+
+Execution time: 4.645 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>ptime git -c annex.largefiles=anything add 1GB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 1GB ===
+warning: LF will be replaced by CRLF in 1GB.
+The file will have its original line endings in your working directory
+
+Execution time: 5.834 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>ptime git -c annex.largefiles=anything add 5GB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 5GB ===
+warning: LF will be replaced by CRLF in 5GB.
+The file will have its original line endings in your working directory
+
+Execution time: 26.916 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>ptime git -c annex.largefiles=anything add 10GB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 10GB ===
+warning: LF will be replaced by CRLF in 10GB.
+The file will have its original line endings in your working directory
+
+Execution time: 54.275 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>ptime git -c annex.largefiles=anything add 20GB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 20GB ===
+warning: LF will be replaced by CRLF in 20GB.
+The file will have its original line endings in your working directory
+
+Execution time: 105.074 s
+
+C:\Users\adina\temp\gitannexbenchmarks\withoutconfig>ptime git -c annex.largefiles=anything add 50GB
+
+ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
+Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
+
+===  git -c annex.largefiles=anything add 50GB ===
+warning: LF will be replaced by CRLF in 50GB.
+The file will have its original line endings in your working directory
+
+Execution time: 256.739 s
+
+```
+</details>
+
+Hope this is helpful.
+"""]]
diff --git a/doc/todo/incremental_hashing_for_add/comment_2_30b4c0f3b1c13e9a1a2ddba5f88eb6ee._comment b/doc/todo/incremental_hashing_for_add/comment_2_30b4c0f3b1c13e9a1a2ddba5f88eb6ee._comment
new file mode 100644
index 0000000000..caaffbfc6b
--- /dev/null
+++ b/doc/todo/incremental_hashing_for_add/comment_2_30b4c0f3b1c13e9a1a2ddba5f88eb6ee._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-12-01T16:59:50Z"
+ content="""
+Thanks @adina.wagner that is very useful. Seems reliable enough despite the
+other workload, to say that the overhead on Windows is around 14%-33%.
+Interesting that the worst case is with the smallest file.
+"""]]
diff --git a/doc/todo/info_--size-history.mdwn b/doc/todo/info_--size-history.mdwn
new file mode 100644
index 0000000000..15c464ace8
--- /dev/null
+++ b/doc/todo/info_--size-history.mdwn
@@ -0,0 +1,62 @@
+Support eg `git-annex info --size-history=30d` which would display
+the combined size of all repositories every 30 days throughout the history
+of the git-annex branch. This would allow graphing, analysis, etc of repo
+growth patterns.
+
+Also, `git-annex info somerepo --size-history=30d` would display the size
+of only the selected repository.
+
+Maybe also a way to get the size of each repository plus total size in a
+single line of output?
+
+----
+
+Implementation of this is fairly subtle. My abandoned first try just went
+through `git log` and updated counters as the location logs were updated.
+That resulted in bad numbers. (The size went negative eventually in fact!)
+The problem is that the git-annex branch is often updated both locally and
+on a remote, eg when copying a file to a remote. And that results in 2
+changes to the git-annex branch that both record the same data. So it gets
+counted twice by my naive implementation.
+
+I think it is not possible for an accumulation based approach to work in
+constant memory and fast. In the worst case, there is a fork of the branch
+that diverges hugely over a long period of time. So that divergence either
+needs to be buffered in memory, or recalculated repeatedly.
+
+What I think needs to be done is use `git log --reverse --date-order git-annex`.
+Feed the changed annex log file refs into catObjectStream to get the log
+files. (Or use --patch and parse the diff to extract log file lines, 
+might be faster?) Parse the log files, and update a simple data structure:
+
+    Map Key [UUIDPointer]
+
+Where UUIDPointer is a number that points to the UUID in a Map. This
+avoids storing copies of the uuids in the map.
+
+This is essentially union merging all forks of the git-annex branch at
+each commit, but far faster and in memory. Since union merging a git-annex
+branch can be done at any point and always results in a consistent view of
+the data, this will be consistent as well.
+
+And when updating the data structure, then it can update a counter when
+something changed, and avoid updating it when a redundant log was logged.
+
+This approach will use an amount of memory that scales with
+the number of keys and numbers of copies. I mocked it up using my big
+repository. Storing every key in it in such a map, with 64 UUIDPointers
+in the list (many more than the usual number of copies) took 2 gb of
+memory. Which is a lot but also most users have that much if necessary.
+With a more usual 5 copies, memory use was only 0.5 gb. So I think this is
+an acceptable exception to git-annex's desire to use a constant amount of
+memory.
+
+(I considered a bloom filter, but a false positive would wreck the
+statistics. An in-memory sqlite db might be more efficient, but probably
+not worth the bother.)
+
+[[!tag confirmed]]
+
+--[[Joey]] 
+
+> [[done]]
diff --git a/doc/todo/info__58___allow_file_matching_options_for_all_keys.mdwn b/doc/todo/info__58___allow_file_matching_options_for_all_keys.mdwn
new file mode 100644
index 0000000000..365c6e0047
--- /dev/null
+++ b/doc/todo/info__58___allow_file_matching_options_for_all_keys.mdwn
@@ -0,0 +1,13 @@
+I want to see aggregate stats on all keys known to git-annex while using matching options like `--in here`, `--copies` etc.
+
+The obvious thing I tried was to use `git annex info --in here` but that complains:
+
+```
+git-annex: File matching options can only be used when getting info on a directory.
+```
+
+There should be a way to use `info` to query aggregate information properties of all keys instead of directories.
+
+I have used `git annex info .` in the repos I used up until now because every key was in the tree. Though I also have a feeling that operating on all keys could be significantly faster than filtering them to match some directory.
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_1_3b96becda1db6ae23adb5077b6332718._comment b/doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_1_3b96becda1db6ae23adb5077b6332718._comment
new file mode 100644
index 0000000000..45cbb1e736
--- /dev/null
+++ b/doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_1_3b96becda1db6ae23adb5077b6332718._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-02-21T16:19:27Z"
+ content="""
+You can use: `git-annex info . --in here`
+
+But, it should be possible when getting info for all keys
+to use the matching options like --in that do not match on a filename.
+It used to be that there was no way to tell which kind of matching options 
+where used, but now `matchNeedsFileName` is available and it could only
+reject those.
+
+So this can be implemented by making cachedPresentData
+and cachedRemoteData (etc) get the matcher, check if it's
+the right kind and apply it to the keys.
+
+done
+"""]]
diff --git a/doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_2_2d0a6abd5be8afce677eeea575aae548._comment b/doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_2_2d0a6abd5be8afce677eeea575aae548._comment
new file mode 100644
index 0000000000..5b91f004fa
--- /dev/null
+++ b/doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_2_2d0a6abd5be8afce677eeea575aae548._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/86b8c2d893dfdf2146e1bbb8ac4165fb"
+ subject="comment 2"
+ date="2023-12-25T13:37:58Z"
+ content="""
+Sorry for the late reply but this somehow didn't reach me.
+
+I just tried querying some basic stats such as `--not --copies 2` and running that with `git annex info .` works as expected:
+
+```
+directory: .
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 0
+size of annexed files in working tree: 0 bytes
+```
+
+
+`git annex info --not --copies 2` confusingly displays the repo overview and then starts calculating first local and then \"annexed files in working tree\" keys. It does not show the useful repo overview which displays how many matched keys are in each repo that has at least one however.
+
+With that filter, `git annex info .` takes 15s in my case while `git annex info` takes 20s, likely due to the local key lookup. Trying to avoid the local lookup using `--fast` unfortunately also avoids the working tree lookup; outputting the same info as `git annex info --fast` without any filters which doesn't seem very useful.
+
+Does the latter really query all keys however? It appears to me that it's the same as querying `.`. I have nearly 100 unused keys in that repo but both info commands show the same amount.
+"""]]
diff --git a/doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_3_aae866dc71811074d69b91c2390ccb01._comment b/doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_3_aae866dc71811074d69b91c2390ccb01._comment
new file mode 100644
index 0000000000..940d1e2801
--- /dev/null
+++ b/doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_3_aae866dc71811074d69b91c2390ccb01._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-12-29T14:24:45Z"
+ content="""
+`git annex info --not --copies 2` displays the global overview (because you
+have not specified a directory), and limits it to keys that have the
+specified number of copies.
+
+Unused keys are included in the "local annexed keys" count when using
+`git-annex info` without a directory.
+
+I agree it would make sense for `git-annex info` to display something
+similar to the "repositories containing these files". Although in
+the global overview it should show the total annex size of each repository.
+[[todo/info_show_total_annex_sizes_of_repositories]]
+"""]]
diff --git a/doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_4_371d53b4539bee6e3d595154033a2471._comment b/doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_4_371d53b4539bee6e3d595154033a2471._comment
new file mode 100644
index 0000000000..3dbdaf3a62
--- /dev/null
+++ b/doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_4_371d53b4539bee6e3d595154033a2471._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/86b8c2d893dfdf2146e1bbb8ac4165fb"
+ subject="comment 4"
+ date="2023-12-29T17:06:37Z"
+ content="""
+I may have been unclear in my wording but what I really want is `info` to be able to show me numbers on *all* keys of the git-annex branch, including keys not in the current working tree or repo.  
+The intent is that I want to preserve past versions and also want to be able to query copies, where they're located etc. of those together with the \"used\" keys. I don't care whether they're referenced in the current revision and want to be able to tell `git-annex info` to not care too.
+
+Ideally, this should skip any unused check; operating only on the git-annex branch's data and none of master's. (That might also yield a much needed performance benefit.)
+
+Total size of annex sounds amazing; I've been wanting that ever since I set up distributed cold storage. I'll give it a spin :)
+"""]]
diff --git a/doc/todo/info_show_total_annex_sizes_of_repositories.mdwn b/doc/todo/info_show_total_annex_sizes_of_repositories.mdwn
new file mode 100644
index 0000000000..d96e7e9b51
--- /dev/null
+++ b/doc/todo/info_show_total_annex_sizes_of_repositories.mdwn
@@ -0,0 +1,10 @@
+`git-annex info` when run with a path displays "repositories containing these files"
+with a list of repositories and sizes. It would be good for it, when not
+run with a path to display a corresponding "annex size of repositories".
+
+I think that this recently became possible to inplement cheaply.
+cachedAllRepoData is collected now, used for "combined annex size of all repositories".
+For this, it also needs to accumulate the size of each separate repository.
+--[[Joey]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch.mdwn b/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch.mdwn
new file mode 100644
index 0000000000..7fa159769b
--- /dev/null
+++ b/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch.mdwn
@@ -0,0 +1,34 @@
+a very minor and probably should not happen in real-life since noone should check out git-annex branch (besides may be to fix up something manually) but I still do not see the point of scanning for unlocked/annexed files if `init` ran in that branch.  ATM ([8.20210428-270-g651fe3f39](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=8.20210429-g651fe3f39)) I see
+
+```
+$> bash annex-scanning-git-annex
+> set -eu
+>> mktemp -d /home/yoh/.tmp/dl-XXXXXXX
+> cd /home/yoh/.tmp/dl-yHMtPGl
+> git clone --branch git-annex http://datasets.datalad.org/.git out
+Cloning into 'out'...
+Fetching objects: 11612, done.
+> cd out
+> git branch
+* git-annex
+> git annex init
+init  (scanning for annexed files...)
+ok
+(recording state in git...)
+
+real	0m0.622s
+user	0m0.435s
+sys	0m0.163s
+
+```
+
+so it reports scanning while in git-annex, although goes quickly (has only about 1000 keys there), so may be doesn't even actually do any scanning and it is just a matter of reporting?
+
+
+Actually -- it made me think: is that `scanning` branch specific? then what would happen if e.g. master has no unlocked files in the tree and some other branch has unlocked files in the tree -- I could checkout/switch between branches without causing `git-annex` to redo its scanning and would require manual `git annex init`?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> I feel this is unnecessary complexity and I've optimised the scans quite a
+> lot in the meantime, so [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch/comment_1_2ff094dd4ff1fb05db90782d381441d3._comment b/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch/comment_1_2ff094dd4ff1fb05db90782d381441d3._comment
new file mode 100644
index 0000000000..7e90b2c5f8
--- /dev/null
+++ b/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch/comment_1_2ff094dd4ff1fb05db90782d381441d3._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-06-04T16:03:34Z"
+ content="""
+Well, the init scanning is quite optimised by now, and since it will find no
+annexed objects, there are no database writes needed, which are the slower
+part of that.
+
+You will pay the price though when you later check out the master
+branch, since it then has to scan the delta. And that scanning is less
+optimised. It would be more beneficial to speed up that scanning
+(reconcileStaged), which should be doable by using the git cat-key --batch
+trick.
+
+I think the effect is somewhat psychological; if it says it's doing
+a scan then people are going to feel on guard that it's expensive. I know that
+sometimes git avoids displaying certain progress messages unless it's
+determined the operation is going to take a long time (eg git status will
+show a progress display in some circumstances but not commonly). That could
+be useful here, and probably in other parts of git-annex.
+"""]]
diff --git a/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch/comment_2_2cbfb22e8f1d89d4f78ade565554cb1c._comment b/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch/comment_2_2cbfb22e8f1d89d4f78ade565554cb1c._comment
new file mode 100644
index 0000000000..0142d78551
--- /dev/null
+++ b/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch/comment_2_2cbfb22e8f1d89d4f78ade565554cb1c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-06-04T17:14:42Z"
+ content="""
+Made the scanning message not be displayed unless it takes at least 1
+second. Of course, if some test suite is still looking at that message,
+it will break..
+"""]]
diff --git a/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch/comment_3_fe771be800a6b26157c3075e632ee1b7._comment b/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch/comment_3_fe771be800a6b26157c3075e632ee1b7._comment
new file mode 100644
index 0000000000..e92ccb75fc
--- /dev/null
+++ b/doc/todo/init__58__do_not_bother_scanning_if_in_git-annex_branch/comment_3_fe771be800a6b26157c3075e632ee1b7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-06-14T18:33:43Z"
+ content="""
+> It would be more beneficial to speed up that scanning (reconcileStaged), which should be doable by using the git cat-key --batch trick.
+
+That got implemented.
+"""]]
diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations.mdwn b/doc/todo/interface_to_the___34__progress__34___of_annex_operations.mdwn
new file mode 100644
index 0000000000..2141593e9e
--- /dev/null
+++ b/doc/todo/interface_to_the___34__progress__34___of_annex_operations.mdwn
@@ -0,0 +1,20 @@
+It would be really nice if external tools working with annex could obtain updates on the progress of operations so they could report using their own UI back to the user.  Especially relevant for --batch --json modes of operations (e.g. for get or addurl) whenever no progress is reported by annex itself at all.  
+
+Related:
+[datalad #478](https://github.com/datalad/datalad/issues/478)
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> --status-fd is one way, or the progress could be included as
+> part of the --batch protocol. In either case, it might make sense to
+> reuse part of the external special remote protocol. (Which would let you
+> relay the progress messages when datalad is doing a nested retrieval, I
+> suppose.) --[[Joey]]
+
+>> [[done]]; --json-progress implemented. I limited the frequency of json
+>> progress items to 10 per second max, and it's typically only 1 per
+>> second or less, so didn't implement
+>> --json-progress=N to tune it. Also added --json and --json-progress to
+>> copy, move, mirror commands. --[[Joey]]
diff --git a/doc/todo/keep_git-annex_branch_checked_out__63__.mdwn b/doc/todo/keep_git-annex_branch_checked_out__63__.mdwn
new file mode 100644
index 0000000000..8c21cb01a1
--- /dev/null
+++ b/doc/todo/keep_git-annex_branch_checked_out__63__.mdwn
@@ -0,0 +1,3 @@
+Currently, the git-annex branch is not checked out, but is accessed as needed with commands like git-cat.  Could git-annex work faster if it kept the git-annex branch checked out?  Especially if one could designate a fast location (like a ramdisk) for keeping the checked-out copy.   Maybe git-worktree could be used to tie the separate checkout to the repository.
+
+[[!tag unlikely]]
diff --git a/doc/todo/keep_git-annex_branch_checked_out__63__/comment_1_cd967b89dbebd431a14b0dcd08ebc67c._comment b/doc/todo/keep_git-annex_branch_checked_out__63__/comment_1_cd967b89dbebd431a14b0dcd08ebc67c._comment
new file mode 100644
index 0000000000..0d0f4156aa
--- /dev/null
+++ b/doc/todo/keep_git-annex_branch_checked_out__63__/comment_1_cd967b89dbebd431a14b0dcd08ebc67c._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-11-15T16:09:30Z"
+ content="""
+Interesting idea, though a ramdisk seems like overkill; filesystem caching
+tends to be quite good. 
+
+It would only speed up branch reads, not writes.
+
+I don't think it would be much faster to read individual files from the
+filesystem than reading the data directly out of the git repository.
+git pack files are designed for fast random access. On top of that,
+the git cat-file --batch interface adds extra context
+switches and buffer copies and parsing overhead; something like libgit2
+could potentially be quite a bit faster.
+
+Note that git-annex repository v0 did keep the git-annex data in the
+regular git tree. My notes during the conversion from that to the branch 
+include: "After all that, git-annex turned out to be nearly as fast as
+before when it was simply reading files from the filesystem, and actually
+faster in some cases." Although I didn't record more detailed benchmark
+information. Would be interesting to dig up git-annex 0.20110610 and benchmark
+it against the current version. :-)
+"""]]
diff --git a/doc/todo/keep_git-annex_branch_checked_out__63__/comment_2_620cfbb2e2507d340dfb25d1fcd2cdfa._comment b/doc/todo/keep_git-annex_branch_checked_out__63__/comment_2_620cfbb2e2507d340dfb25d1fcd2cdfa._comment
new file mode 100644
index 0000000000..5b33e3268a
--- /dev/null
+++ b/doc/todo/keep_git-annex_branch_checked_out__63__/comment_2_620cfbb2e2507d340dfb25d1fcd2cdfa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="git pack files"
+ date="2020-07-01T17:32:45Z"
+ content="""
+\"git pack files are designed for fast random access\" -- but also for representing slow-changing source code files; git-annex branch contents seems quite different from the typical source code repo.
+"""]]
diff --git a/doc/todo/key_checksum_from_chunk_checksums.mdwn b/doc/todo/key_checksum_from_chunk_checksums.mdwn
new file mode 100644
index 0000000000..e6c28f58ab
--- /dev/null
+++ b/doc/todo/key_checksum_from_chunk_checksums.mdwn
@@ -0,0 +1,4 @@
+Would it be hard to add a variantion to checksumming [[backends]], that would change how the checksum is computed: instead of computing it on the whole file, it would first be computed on file chunks of given size, and then the final checksum computed on the concatenation of the chunk checksums?  You'd add a new [[key field|internals/key_format]], say cNNNNN, specifying the chunking size (the last chunk might be shorter).  Then (1) for large files, checksum computation could be parallelized (there could be a config option specifying the default chunk size for newly added files); (2) I often have large files on a remote, for which I have md5 for each chunk, but not for the full file; this would enable me to register the location of these fies with git-annex without downloading them, while still using a checksum-based key.
+
+> Closing, because [[external_backends]] is implemented, so you should be
+> able to roll your own backend for your use case here. [[done]] --[[Joey]]
diff --git a/doc/todo/key_checksum_from_chunk_checksums/comment_1_946e2679cafd2c74a3b0b408e39f2d8d._comment b/doc/todo/key_checksum_from_chunk_checksums/comment_1_946e2679cafd2c74a3b0b408e39f2d8d._comment
new file mode 100644
index 0000000000..c112bc9c26
--- /dev/null
+++ b/doc/todo/key_checksum_from_chunk_checksums/comment_1_946e2679cafd2c74a3b0b408e39f2d8d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-05-06T16:10:17Z"
+ content="""
+Parallizable checksums exist, I would rather add support for a standard one
+to git-annex than roll my own. In fact, I already did when I added
+BLAKE2SP224 etc which are 8-way parallel and also can be optimised by SIMD
+instructions on less parallel systems.
+"""]]
diff --git a/doc/todo/key_checksum_from_chunk_checksums/comment_2_aaff896ff99366d3b96c523284c1248e._comment b/doc/todo/key_checksum_from_chunk_checksums/comment_2_aaff896ff99366d3b96c523284c1248e._comment
new file mode 100644
index 0000000000..9a02bff2de
--- /dev/null
+++ b/doc/todo/key_checksum_from_chunk_checksums/comment_2_aaff896ff99366d3b96c523284c1248e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-05-07T00:59:31Z"
+ content="""
+Thanks for the BLAKE2SP224 pointer; it does solve (1).  I'm still looking for the best way to solve (2): registering large remote files with git-annex, without downloading them.  `addurl --fast` does that, but creates a non-checksum key.  If I can get an MD5 without downloading, I can use `setpresentkey`.  But often I only have the MD5 for the fixed-size chunks of the file, not for the whole.  Adding a backend variant computable from MD5s of the chunks would solve the problem.  Maybe, there are other solutions?
+"""]]
diff --git a/doc/todo/key_checksum_from_chunk_checksums/comment_3_352bc3eb419184a4ec70ddaffd78968e._comment b/doc/todo/key_checksum_from_chunk_checksums/comment_3_352bc3eb419184a4ec70ddaffd78968e._comment
new file mode 100644
index 0000000000..fc9baaea47
--- /dev/null
+++ b/doc/todo/key_checksum_from_chunk_checksums/comment_3_352bc3eb419184a4ec70ddaffd78968e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-06-26T14:51:32Z"
+ content="""
+That seems like an unusual use case that would be unnecessary complication
+to add to git-annex, but that [[external_backends]] could be used to
+implenent as needed.
+"""]]
diff --git a/doc/todo/key_checksum_from_chunk_checksums/comment_4_e766f725e22ea0a38ac2277e08fd3839._comment b/doc/todo/key_checksum_from_chunk_checksums/comment_4_e766f725e22ea0a38ac2277e08fd3839._comment
new file mode 100644
index 0000000000..82e760c8cf
--- /dev/null
+++ b/doc/todo/key_checksum_from_chunk_checksums/comment_4_e766f725e22ea0a38ac2277e08fd3839._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Chel"
+ avatar="http://cdn.libravatar.org/avatar/a42feb5169f70b3edf7f7611f7e3640c"
+ subject="comment 4"
+ date="2020-01-26T22:48:07Z"
+ content="""
+Another theoretical use case (not available for now, but maybe for the future):
+verify with checksums parts of the file and re-download only those parts/chunks, that are bad.
+For this you need a checksum for each chunk and a \"global\" checksum in key, that somehow incorporates all these chunk checksums.
+An example of this is Tiger Tree Hash in file sharing.
+
+When I used the SHA256 backend in my downloads, I often wondered that the long process of checksumming a movie
+or an OS installation .iso is not ideal. Because if the file download is not finished, I get the wrong checksum,
+and the whole process needs to be repeated.
+
+And in the future git-annex can integrate a FUSE filesystem and literally store just chunks of files,
+but represent files as a whole in this virtual filesystem view.
+"""]]
diff --git a/doc/todo/key_checksum_from_chunk_checksums/comment_5_561b9bb28c5d375334ce915da75d5ce6._comment b/doc/todo/key_checksum_from_chunk_checksums/comment_5_561b9bb28c5d375334ce915da75d5ce6._comment
new file mode 100644
index 0000000000..afd7e7e4ef
--- /dev/null
+++ b/doc/todo/key_checksum_from_chunk_checksums/comment_5_561b9bb28c5d375334ce915da75d5ce6._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="chunks and checksums"
+ date="2020-01-28T18:20:34Z"
+ content="""
+\"verify with checksums parts of the file and re-download only those parts/chunks, that are bad.\" -- if I understand correctly, git-annex doesn't checksum [[chunks|chunking]], but can tell incompletely downloaded chunks based on size.
+
+My original use case (registering the presence of a chunked file in a remote without downloading it) might be implementable with [[todo/setpresentkey_option_to_record_chunked_state/]].  The checksums of the chunks would not be used though.
+
+"""]]
diff --git a/doc/todo/learn_about_remotes_that_are_currently_unavailable.mdwn b/doc/todo/learn_about_remotes_that_are_currently_unavailable.mdwn
new file mode 100644
index 0000000000..458db9b7fd
--- /dev/null
+++ b/doc/todo/learn_about_remotes_that_are_currently_unavailable.mdwn
@@ -0,0 +1,30 @@
+If a remote is only available on some networks, a command like `git annex drop`
+or `git annex get` may try to access the remote each time a file is
+processed, and suffer a long timeout each time. It seems git-annex could
+remember that a previous access of a remote failed, and automatically
+de-prioritize that remote, eg adjust its cost to below the next remote on
+the list. So it would learn about the current situation the process finds
+itself in.
+
+Seems this would be easy for checkPresent, since it throws an exception
+if the remote cannot be accessed.
+
+Other methods like storeKey and retrieveKeyFile don't differentiate between
+the remote not being accessible, and the action failing. It could be a lot
+of work and complication to add that distinction, including needing to
+change the external special remote protocol.
+
+Implementing it for at least checkPresent would be a good start. That would
+cover `git annex drop` and `git annex copy --to` and probably a few other
+commands.
+
+This learning could be unwanted behavior if git-annex is running while the
+computer is migrating between networks. Then it might de-prioritize a
+remote before it travels to the network where it can use that remote. This
+would mostly affect the assistant since it's run for long periods of time.
+It could undo the de-prioritization when it sees that the network has
+changed.
+
+--[[Joey]]
+
+[[!tag needsthought]]
diff --git a/doc/todo/let_external_remotes_declare_support_for_named_pipes.mdwn b/doc/todo/let_external_remotes_declare_support_for_named_pipes.mdwn
new file mode 100644
index 0000000000..d7a8bba6b5
--- /dev/null
+++ b/doc/todo/let_external_remotes_declare_support_for_named_pipes.mdwn
@@ -0,0 +1,5 @@
+In the [[design/external_special_remote_protocol]], the `File` parameter of various requests is specified to be a regular file.  If it could be a named pipe, this would open up useful possibilities: [[todo/git-annex-cat]], [[todo/transitive_transfers]], [[todo/git-annex-export_--from_option]], [[todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/]], [[todo/to_and_from_multiple_remotes]], faster [[`git-annex-fsck --from`|git-annex-fsck]], passing named pipes on `git-annex` command line (for streaming the outputs of a running command directly to a remote, or using `git-annex` as a building block of larger workflows), and maybe others.
+
+An optional protocol request `NAMEDPIPESSUPPORTED`, similar to [[`EXPORTSUPPORTED`|design/external_special_remote_protocol/export_and_import_appendix#index1h2]], could tell `git-annex` that the remote supports named pipes.  For remotes that don't declare such support, it could be emulated: before sending e.g. `TRANSFER STORE Key File`, if `File` is a pipe and the remote hasn't said it supports pipes, `git-annex` would drain the pipe to a `TempFile` and then send `TRANSFER STORE Key TempFile` instead.  Then the rest of `git-annex` can presume pipes support.
+
+[[!tag needsthought]]
diff --git a/doc/todo/let_git-annex-matching-options_query_gitattributes.mdwn b/doc/todo/let_git-annex-matching-options_query_gitattributes.mdwn
new file mode 100644
index 0000000000..bb6b72ddd8
--- /dev/null
+++ b/doc/todo/let_git-annex-matching-options_query_gitattributes.mdwn
@@ -0,0 +1,3 @@
+To [[git-annex-matching-options]], add `--gitattribute` option analogous to the current `--metadata` option but reading a value from [`.gitattributes`](https://git-scm.com/docs/gitattributes).
+
+Unclear what to do when different repo paths with conflicting `.gitattributes` point to the same content, but that can already happen with `--include=glob/--exclude=glob`?   How is it handled there?
diff --git a/doc/todo/let_git-annex-matching-options_query_gitattributes/comment_1_3e7c731037b8ce7148a6a597783d2ba3._comment b/doc/todo/let_git-annex-matching-options_query_gitattributes/comment_1_3e7c731037b8ce7148a6a597783d2ba3._comment
new file mode 100644
index 0000000000..63f38f7758
--- /dev/null
+++ b/doc/todo/let_git-annex-matching-options_query_gitattributes/comment_1_3e7c731037b8ce7148a6a597783d2ba3._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-06-25T17:56:02Z"
+ content="""
+I'm not super enthused by this idea. The git-check-attr interface would
+make it hard to avoid using one process per use of the option. 
+Checking attributes can be slow. Attributes are limited in what 
+they can contain. Some places where git-annex uses gitattributes I have
+ended up regretting it. A compelling use case would be good.
+
+Might also be possible to support this in preferred content. Although it
+looks a bit hard to do, because it would need to start up a git-check-attr
+process for each different attribute used, while parsing the preferred content
+expression.
+"""]]
diff --git a/doc/todo/lockContent_for_special_remotes.mdwn b/doc/todo/lockContent_for_special_remotes.mdwn
new file mode 100644
index 0000000000..fdb52de6f4
--- /dev/null
+++ b/doc/todo/lockContent_for_special_remotes.mdwn
@@ -0,0 +1,76 @@
+Support lockContent in more special remotes. This allows dropping
+content from a special remote when the only copies are in other special
+remotes, without needing to set mincopies to 0 and risk losing content.
+
+(All the easy ones, eg read-only special remotes, are implemented already.)
+
+* It might be possible for an external remote to lock content, but it would
+  be a tricky extension to the protocol, since lockContent needs to keep it
+  locked while running another action. There would need to be separate
+  actions for locking and unlocking.
+
+  If this were implemented in git-annex, and some special remote program
+  didn't used to support it, and implemented REMOVE w/o checking a lock,
+  then making that program support lockContent would run the risk
+  of a mixture of the old and new version being in use for the same remote,
+  which could result in data loss.
+
+  To avoid that, the author of the special remote would need to either
+  a) always do lock checking from the beginning or
+  b) wait long enough or document well enough to be sure that situation
+  never happens.
+
+  > Maybe this second part is not a problem actually? Analysis follows:
+  > 
+  > There are 2 git-annex
+  > instances A and B, and 2 special remotes X and Y. A is using the old
+  > program that does not support locking, B uses the new program that does.
+  > Both X and Y have a copy of an object.
+  > 
+  > If A is dropping from X, it will not trust Y to satisfy mincopies,
+  > since A cannot lockContent Y. So it will not drop from X.
+  > 
+  > If B is dropping from Y, it can lockContent X, and so the drop
+  > succeeds.
+  > 
+  > It seems it's ok for B to trust lockContent X, even though A does
+  > not check if X is locked when dropping from it. Because A will not
+  > drop from X unless it's able to satisfy mincopies by locking the
+  > content somewhere else. --[[Joey]]
+
+* directory could use fcntl locking
+
+  This would need a transition, because dropping from directory first needs
+  to support checking for locks. Only after we're sure that any git-annex
+  binaries that might be in use on a machine do that is it safe for
+  lockContent to take the lock. So git-annex would need to be released with
+  the first change, then wait several months or years before making the
+  second change.
+
+  > Update: See analysis above, should also apply here.
+
+  Also, the directory might be on a filesystem that does not support
+  locking, with various failure modes. And unlike a git-annex repo,
+  there's nowhere in a directory special remote to record information about
+  locking problems with it. Getting this right seems hard..
+
+  > If lockContent throws an exception, that remote is treated the same
+  > as if it did not support lockContent, so if these problems can be
+  > differentiated from a failure to lock at all, can just throw an
+  > exception. But need to avoid lockContent succeeding in any case
+  > where removeKey will not be prevented from removing the content.
+
+* S3 has an object lock feature, I don't know if it would be usable for
+  this.
+
+  It would need a transition, with dropKey first failing when the object
+  lock was in place, and then once that git-annex was in use everywhere,
+  lockContent setting the object lock.
+  
+  > Update: See analysis above, should also apply here.
+  
+  (S3 with versioning=yes already supports lockContent.)
+
+* adb could use some shell trick perhaps.. But it would depend on doing
+  locking in /sdcard, which seems likely to be a massive ball of POSIX
+  incompliance and pain.
diff --git a/doc/todo/lockContent_for_special_remotes/comment_1_835d075d22fd1544fc27b912ad3326d8._comment b/doc/todo/lockContent_for_special_remotes/comment_1_835d075d22fd1544fc27b912ad3326d8._comment
new file mode 100644
index 0000000000..007008d4d4
--- /dev/null
+++ b/doc/todo/lockContent_for_special_remotes/comment_1_835d075d22fd1544fc27b912ad3326d8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="lockContent for special remotes w/o changing the protocol"
+ date="2021-04-12T01:20:13Z"
+ content="""
+Maybe, can implement lockContent with the existing protocol?  To lock a key, use `TRANSFER STORE` to store a lockfile to the remote, with the lockfile's key derived from the key being locked, and the lockfile's content storing details like when was the lock set and by whom.  Before any `REMOVE` request, git-annex would use `CHECKPRESENT` on the lockfile key, and not count the key as present if the lockfile key exists.
+
+Or, simpler, just store one special key into the remote indicating \"prevent all removals by git-annex instances other than this one\" before doing a series of removals, and `REMOVE` the key when removals end.
+
+"""]]
diff --git a/doc/todo/lockContent_for_special_remotes/comment_2_948993c967f7908adaea068e352e0607._comment b/doc/todo/lockContent_for_special_remotes/comment_2_948993c967f7908adaea068e352e0607._comment
new file mode 100644
index 0000000000..2640ed9a13
--- /dev/null
+++ b/doc/todo/lockContent_for_special_remotes/comment_2_948993c967f7908adaea068e352e0607._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2021-04-12T14:42:11Z"
+ content="""
+Never mind, `TRANSFER STORE` is not specified to fail if the key is already stored, so not usable for locking.
+"""]]
diff --git a/doc/todo/lockContent_for_special_remotes/comment_3_432fc28c4e09fd514fd780ec16b9423e._comment b/doc/todo/lockContent_for_special_remotes/comment_3_432fc28c4e09fd514fd780ec16b9423e._comment
new file mode 100644
index 0000000000..398ac79748
--- /dev/null
+++ b/doc/todo/lockContent_for_special_remotes/comment_3_432fc28c4e09fd514fd780ec16b9423e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2021-04-12T15:39:27Z"
+ content="""
+Maybe, instead of `lockContent`, before dropping content from a remote, could temporarily untrust it, sync the `git-annex` branch, then -- only if the sync succeeds -- drop the content, then restore the trust level and sync again?
+"""]]
diff --git a/doc/todo/lockContent_for_special_remotes/comment_4_13f4b8e180c727b775807e8e2aa5a11f._comment b/doc/todo/lockContent_for_special_remotes/comment_4_13f4b8e180c727b775807e8e2aa5a11f._comment
new file mode 100644
index 0000000000..ad65c144e2
--- /dev/null
+++ b/doc/todo/lockContent_for_special_remotes/comment_4_13f4b8e180c727b775807e8e2aa5a11f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-04-12T16:30:06Z"
+ content="""
+Both of these ideas above seem to suffer from race conditions,
+which lockContent needs to prevent. lockContent needs the remote to
+support an actual exclusive locking operation.
+
+Do you have an external special remote that could actually support that?
+"""]]
diff --git a/doc/todo/lockContent_for_special_remotes/comment_5_b006d6bca93a50e1f23a2b6d20584c91._comment b/doc/todo/lockContent_for_special_remotes/comment_5_b006d6bca93a50e1f23a2b6d20584c91._comment
new file mode 100644
index 0000000000..11709cb449
--- /dev/null
+++ b/doc/todo/lockContent_for_special_remotes/comment_5_b006d6bca93a50e1f23a2b6d20584c91._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="lockContent for special remotes"
+ date="2021-04-15T16:32:32Z"
+ content="""
+\"lockContent needs the remote to support an actual exclusive locking operation.  Do you have an external special remote that could actually support that?\" -- I do, the [DNAnexus](https://www.dnanexus.com/) special remote.  But it'd better if `git-annex` itself handled locking, so that one didn't have to trust each external remote's implementation.  Locking for a remote doesn't have to be done through the remote itself; it can be done through another remote for which git-annex has built-in locking support. Doing it through the git remote itself seems simplest.
+
+\"ideas above seem to suffer from race conditions\" -- what is the race condition for syncing through the git-annex branch?  If two people try to push to git-annex branch one will fail, and require a pull first.  Let's say people P1 and P2 try to drop a file from remotes R1 and R2.  They both cloned the repo from git remote G.  P1's git-annex marks R1 untrusted on the git-annex branch, and pushes that branch to G.  P2's git-annex marks R2 untrusted on the git-annex branch, and tries to push that branch to G, but fails, so has to pull first.  Then P2's git-annex sees that R1 is now untrusted, and refuses to drop from R2.  P1's git-annex finishes the drop from R1, then restores R1's trust level.
+
+This does require there to be a shared git remote G, but that's often the case.   Maybe the URL of G could be stored in the remotes R1/R2 as contents of a special key?
+"""]]
diff --git a/doc/todo/lockContent_for_special_remotes/comment_6_01cc0fba0368fcda594d2835247dd884._comment b/doc/todo/lockContent_for_special_remotes/comment_6_01cc0fba0368fcda594d2835247dd884._comment
new file mode 100644
index 0000000000..e914d9916a
--- /dev/null
+++ b/doc/todo/lockContent_for_special_remotes/comment_6_01cc0fba0368fcda594d2835247dd884._comment
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-09-27T16:57:48Z"
+ content="""
+Nothing really prevents G from accepting both pushes and merging them,
+resulging in both R1 and R2 being untrusted, but P2 not
+seeing in time that R2 is untrusted.
+
+Nothing prevents G from letting the push from P2 overwrite the branch that
+was earlier pushed from P1.
+
+Nothing assues P1 and P2 that they are actually talking to the same git
+repository and not a split brain situation that normally presents as a
+single git repository.
+
+The above are all maybe unlikely, but it would be hard to rule them all 
+out. A perhaps more likely case is, what if some other process on P2
+happens to pull from G just before P2 modifies the git-annex branch?
+Then P2's push will not fail. That kind of race is probably what I was
+thinking of.
+
+----
+
+Doing locking via another git-annex remote is an interesting idea.
+That would involve having an empty dummy object file for some derived key
+stored in the git-annex remote, and lock that object file.
+
+It seems that, to avoid situations that drop both copies of an
+object stored in 2 such special remotes, dropping the object from the
+special remote would need to entail first dropping the dummy
+object file from the git-annex remote, and only when that succeeds can the
+object be safely dropped from the special remote. And this implies that,
+in order to store the object in the special remote, the dummy object file
+first has to be stored in the git-annex remote.
+
+But operation on the git-annex remote are not atomic with operations on the
+special remote. So I do not think it is possible to avoid all races.
+
+For example, let's have two objects A and B in two special remotes
+(2 copies of the content of the same key) and
+two corresponding dummy objects A' and B' in a git-annex remote.
+You are dropping A, so you first lock B', then remove A', and finally
+remove A. I am dropping B, so I first lock A', then remove B', and finally
+remove B.
+
+Seems safe, right -- either you remove A' before I can lock
+it and my drop fails, or I lock A' before you can remove it, and your drop
+fails. But.. There's a third actor, Mallory. Mallory thinks that A does
+not contain the object yet, and he's going to helpfully fix that.
+He decides he will first store A' in the git-annex remote, then store A.
+
+Then, this sequence of events could occur: 
+
+1. You lock B' and remove A'
+2. Mallory stores A'.
+3. Mallory tries to store A, but it's already present. So he declares success.
+3. You remove A
+4. I lock A' (which mallory helpfully put back in step #2)
+5. I remove B' and then B. Oops, lost the last copy.
+"""]]
diff --git a/doc/todo/lockContent_for_special_remotes/comment_7_463e336fd7f2cb21eff2d87d25851c39._comment b/doc/todo/lockContent_for_special_remotes/comment_7_463e336fd7f2cb21eff2d87d25851c39._comment
new file mode 100644
index 0000000000..d0f5a3cf9f
--- /dev/null
+++ b/doc/todo/lockContent_for_special_remotes/comment_7_463e336fd7f2cb21eff2d87d25851c39._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-09-27T18:11:49Z"
+ content="""
+It certainly must be possible to use a git-annex remote to handle locking
+for special remotes, after all if you inverted control and had that
+git-annex repository communicating to the user's reposities and telling
+them when to delete from the special remote, that would be race safe.
+
+But it seems that the usual git-annex remote operations are not sufficient
+to do it. It would need some new operations tailored to support it.
+"""]]
diff --git a/doc/todo/lockdown_hooks.mdwn b/doc/todo/lockdown_hooks.mdwn
new file mode 100644
index 0000000000..c8f812bb21
--- /dev/null
+++ b/doc/todo/lockdown_hooks.mdwn
@@ -0,0 +1,59 @@
+Add git hooks that are used to [[internals/lockdown]] annexed objects.
+--[[Joey]]
+
+Use cases include:
+
+* Setting immutable bit on systems where git-annex is given the ability to
+  do so, to fully guard against accidental deletion in all circumstances.
+
+* For systems that ignore the write bit, but have some other way to prevent
+  write to a file (eg, ACLs or something).
+
+  Note that in such a case, `git-annex init`'s probe of the write bit
+  handling fails; as long as the hook is configured globally, it should
+  run the hook instead, and if it works, can avoid direct mode.
+
+Design:
+
+Configs: annex.freezecontent-command, annex.thawcontent-command
+In these, "%path" is replaced with the file/directory to act on.
+
+Locking down a directory only needs to do the equivilant of removing its
+write bit, does not need to lockdown the files within it.
+
+It would be up to the command to decide how to handle the 
+core.sharedRepository configuration.
+
+These could be set in the global gitconfig file. The IncludeIf directive
+can be used to make them be used only for repositories located within a given
+mount point.
+
+git-annex test disables use of global gitconfig settings. There would need
+to be a way to let it use these.
+
+Perfomance:
+
+Hook would be called twice per store/drop of an annexed object, 
+once for the file and once for the parent directory.
+
+On windows, called four times per lock of an annexed object, to first thaw
+it and then freeze it. This could be reduced to 2, I think. 
+On posix, the file is locked without being thawed, 
+as only read access is needed.
+
+Probably running a shell script is not too much overhead in many cases,
+if it was too slow, there could be a variant that is run once and 
+fed the names of files to operate on via stdin.
+
+> These hooks may be too specific to this purpose, while a more generalized
+> hook could also support things like [[storing_xattrs|support_for_storing_xattrs]]
+> --[[Joey]]
+
+[[!tag projects/datalad]]
+
+> [[done]].. `git-annex init` does run annex.freezecontent-command and if it
+> prevents writing to a file, it will avoid setting
+> annex.crippledfilesystem.
+> 
+> I didn't make `git-annex test` use the global git config of the hooks
+> though, not sure if that really makes sense or is needed.
diff --git a/doc/todo/lockdown_hooks/comment_1_649dbc3c951bbabc550e12e87e45b319._comment b/doc/todo/lockdown_hooks/comment_1_649dbc3c951bbabc550e12e87e45b319._comment
new file mode 100644
index 0000000000..8c35613c43
--- /dev/null
+++ b/doc/todo/lockdown_hooks/comment_1_649dbc3c951bbabc550e12e87e45b319._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="any chance to avoid necessity to config the hook(s)?"
+ date="2018-02-01T18:54:18Z"
+ content="""
+Thank you Joey for looking into this issue!  I am though a bit worried that necessity to configure using some kind of a hook would be ... suboptimal for a number of reasons.  Before laying out my argumentation, let me first ask:  why alternative \"lockdown\" mechanisms could not be sensed/configured per each repository during `init` and implemented within git-annex?
+
+As you have noted ```git-annex init's probe of the write bit handling fails...``` so git-annex already checks for a possible way to establish the \"lockdown\" for a given repository location. It just tries one possible mechanism ATM. But it could as well try multiple ways to achieve it, starting from current \"POSIX\", and then trying \"ACL\" if appropriate (i.e. tools found). Then if non-POSIX handling is needed, would simple add yet another configuration to .git/config of that repository, and consult to it to switch to corresponding lockdown implementation **within git-annex**.  This would be much more user friendly, and it would allow 3rd party tools using git-annex (such as datalad) to not worry about necessity to configure some additional hooks for a particular location, etc.
+"""]]
diff --git a/doc/todo/lockdown_hooks/comment_2_575c33970014662c664d71e573e718e7._comment b/doc/todo/lockdown_hooks/comment_2_575c33970014662c664d71e573e718e7._comment
new file mode 100644
index 0000000000..f261801824
--- /dev/null
+++ b/doc/todo/lockdown_hooks/comment_2_575c33970014662c664d71e573e718e7._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-02-05T17:04:36Z"
+ content="""
+Seems likely that there are a couple of different ways to use
+ACLs to remove write access. In the simple case, any existing ACL can be
+overwritten. In other cases, some other existing ACLs will need to be
+preserved and only a single part changed. In some cases, the ACL for a user
+should be changed, in others the ACL for a group.
+
+And there are several different varieties of ACLs (POSIX, NFS, Windows). 
+And there's the immutable bit, which might be wanted in some specific
+circumstances but certianly not by most people.
+
+So it makes sense to me to not embed specific knowledge of this into git-annex.
+
+This feels to me like something that the system administrator is going to
+want to set up. It would mostly be limited to repositories inside a given
+mount point that needs the unusual lockdown method due to using NFS or
+whatever. The global gitconfig can be set up to switch on the config only
+for those repositories, and the system administrator can set up hooks
+for the particular use case.
+
+I don't see why something like datalad would need to worry about this
+detail, any more than they worry about the PATH to system programs or other
+such things that the administrator sets up.
+"""]]
diff --git a/doc/todo/lockdown_hooks/comment_3_f57299385578914f5bca05f06b76cd46._comment b/doc/todo/lockdown_hooks/comment_3_f57299385578914f5bca05f06b76cd46._comment
new file mode 100644
index 0000000000..906166d17d
--- /dev/null
+++ b/doc/todo/lockdown_hooks/comment_3_f57299385578914f5bca05f06b76cd46._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="ACLs keep fighting back"
+ date="2019-10-29T18:03:57Z"
+ content="""
+I am getting back to tackle a datalad/git-annex usecase on one of such (nfs4 ACL) usecases, so if hooks are still the way to go, I will be ready to test ;-)
+"""]]
diff --git a/doc/todo/lockdown_hooks/comment_4_614d2c8c758f9920cd84748f8f0d384e._comment b/doc/todo/lockdown_hooks/comment_4_614d2c8c758f9920cd84748f8f0d384e._comment
new file mode 100644
index 0000000000..8bd59334df
--- /dev/null
+++ b/doc/todo/lockdown_hooks/comment_4_614d2c8c758f9920cd84748f8f0d384e._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-06-21T17:41:54Z"
+ content="""
+There's a choice between the hook needing to replicate git-annex's
+use of permissions as well as doing whatever else it does, or git-annex
+setting the permissions first, and only then running the hook.
+
+Seems to me that git-annex setting the permissions is better, because then
+the hook does not need to worry about details like core.sharedrepository
+if it's doing something simple like setting immutable. (But if it adjusts
+ACLs, it might make sense for it to consider core.sharedrepository.) Also,
+the precise details of what file permissions git-annex uses don't need to
+be documented well enough for the hook to replicate them if git-annex just
+makes the permissions changes itself.
+
+It seems to make sense that when restoring permissions, it should run the
+that hook before changing the permissions. The freeze hook might do
+something that prevents changing permissions and the thaw hook undo that.
+"""]]
diff --git a/doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote.mdwn b/doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote.mdwn
new file mode 100644
index 0000000000..63901db2b4
--- /dev/null
+++ b/doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote.mdwn
@@ -0,0 +1,8 @@
+As initially brought up in https://github.com/datalad/datalad/pull/2515#issuecomment-391022075 it would be nice if there was a clear/robust way to programmatically obtain information why `enableremote` failed
+
+May be even more generally -- if there was a robust way to obtain errors for other commands as well, e.g. such as `fatal` messages such as `this operation must be run in a work tree`
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+[[!tag moreinfo]]
+[[!tag confirmed]]
diff --git a/doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote/comment_1_dbe339cb1860d27ebc7116ab4d6e50fb._comment b/doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote/comment_1_dbe339cb1860d27ebc7116ab4d6e50fb._comment
new file mode 100644
index 0000000000..9e15508505
--- /dev/null
+++ b/doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote/comment_1_dbe339cb1860d27ebc7116ab4d6e50fb._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""initial thoughts"""
+ date="2018-05-22T19:27:24Z"
+ content="""
+* Could be --json-errors, with one json object per line per error.
+
+* When git-annex is processing multiple files, there could be multiple
+  error messages output by a single command. If --json-errors goes to
+  stdout then it becomes easy to tell what file an error is associated
+  with, since it would be adjacent to the --json object for the file.
+
+  (If --json-errors goes to stderr it would probably need to include
+  the file or other thing being processed, otherwise a consumer would
+  need to read stdout and stderr in a select loop.)
+
+* Whether it goes to stdout or stderr, other non-json output could
+  be mixed in, which complicates parsing.
+  
+  A good way to keep parsing
+  simple would be to send the json error objects to stdout, and only
+  support them for commands that support --json. (Which might be an
+  annoying limitation since not all commands do, and adding --json to some
+  commands, eg initremote, might be pretty hard.)  
+
+  Or there could be a
+  prefix that is documented for programs to look for the tell if a line
+  of output is a json error object. Eg, `{"git-annex-json-error":`
+
+* There ought to be a unique id in each particular json error,
+  so consumers don't need to expect a particular error text.
+
+* For some errors it would be useful to have more structure
+  than just an error message. For example, HTTP status codes could
+  be broken out; `git annex drop` might want to break out the number
+  of copies it was unable to lock.
+"""]]
diff --git a/doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote/comment_2_06e98b0e0704dce8ced214600d0d6347._comment b/doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote/comment_2_06e98b0e0704dce8ced214600d0d6347._comment
new file mode 100644
index 0000000000..0c6f45591c
--- /dev/null
+++ b/doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote/comment_2_06e98b0e0704dce8ced214600d0d6347._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-05-22T19:56:15Z"
+ content="""
+datalad is looking for StatusCodeException and FailedConnectionException
+from http-client when enableremote fails. Which special remote is that,
+S3 or WebDAV or something?
+"""]]
diff --git a/doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote/comment_3_1c1aaecf15ee220ed5c39def48ccd734._comment b/doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote/comment_3_1c1aaecf15ee220ed5c39def48ccd734._comment
new file mode 100644
index 0000000000..96ff1c6ec9
--- /dev/null
+++ b/doc/todo/machine_readable_information_about_reason_of_failure_in_enableremote/comment_3_1c1aaecf15ee220ed5c39def48ccd734._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-06-23T20:13:10Z"
+ content="""
+enableremote supports --json-error-messages now. The error messages are not
+really machine parseable. But, json error messages can also now be tagged
+with a unique message-id. 
+
+So, this is entirely implementable, it just needs to determine which
+specific failures of which special remotes, and add a message-id to them.
+"""]]
diff --git a/doc/todo/make_add_--batch_add_directories_content.mdwn b/doc/todo/make_add_--batch_add_directories_content.mdwn
new file mode 100644
index 0000000000..9e4d33b5bf
--- /dev/null
+++ b/doc/todo/make_add_--batch_add_directories_content.mdwn
@@ -0,0 +1,54 @@
+`--batch` was added to `annex add` 6 years ago but only now we got to add usage of it in datalad (PR: [5722](https://github.com/datalad/datalad/pull/5722)). Unfortunately on the initial attempt we got tests failing and looking into it I found that its behavior differs from non-batched `annex add` when given directories. That is described in the [original issue in Implementation notes](https://git-annex.branchable.com/todo/--batch_for_add/) as "made it not recurse into directories".  Unfortunately, such a limitation forbids consistent use of `annex add --batch` as drop-in replacement for plain `annex add` without reimplementing git-annex logic on treating dotdirs etc to decide which files actually should be added to git-annex or not.
+
+For that reason I think it would be great if `add --batch` would gain the "super-power" to be able to handle directories as well.
+
+edit: I forgot to add my lovely reproducer to show inconsistency "just in case":
+
+```
+$> bash annex-add-batch-dir.sh
+> set -eu
+>> mktemp -d /home/yoh/.tmp/dl-XXXXXXX
+> cd /home/yoh/.tmp/dl-zmItF0C
+> git init
+Initialized empty Git repository in /home/yoh/.tmp/dl-zmItF0C/.git/
+> git annex init
+init  ok
+(recording state in git...)
+> mkdir d-cmd d-batch
+> touch d-cmd/file d-batch/file
+> git annex add d-cmd
+add d-cmd/file 
+ok
+(recording state in git...)
+> echo d-batch
+> git annex add --batch
+
+> git status
+On branch master
+
+No commits yet
+
+Changes to be committed:
+  (use "git rm --cached <file>..." to unstage)
+	new file:   d-cmd/file
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+	d-batch/
+
+```
+
+so `annex add` and `annex add --batch` behave differently on folder paths.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> Comments seem clear that this should not be changed, and there are easy
+> things users of --batch can do to recurse directories themselves.
+> 
+> Also I checked and the documentation of --batch for git-annex add
+> (and other commands) does say that it reads a file from stdin,
+> so there's at least that documentation that it does not support
+> directories.
+> 
+> So, [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/make_add_--batch_add_directories_content/comment_1_e5707f72bb086c342c89fc3b5ccf00e5._comment b/doc/todo/make_add_--batch_add_directories_content/comment_1_e5707f72bb086c342c89fc3b5ccf00e5._comment
new file mode 100644
index 0000000000..00cf9bfa7f
--- /dev/null
+++ b/doc/todo/make_add_--batch_add_directories_content/comment_1_e5707f72bb086c342c89fc3b5ccf00e5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2022-08-24T15:42:10Z"
+ content="""
+I see the \"difficulty\" in adding that functionality since it would break line-to-line correspondence between input and output, so probably cannot be done for non-`--json` mode. But in `--json` mode I would expect this to be doable.
+"""]]
diff --git a/doc/todo/make_add_--batch_add_directories_content/comment_2_5083e5a729f56dab76bdc97fb247b902._comment b/doc/todo/make_add_--batch_add_directories_content/comment_2_5083e5a729f56dab76bdc97fb247b902._comment
new file mode 100644
index 0000000000..981dd1825e
--- /dev/null
+++ b/doc/todo/make_add_--batch_add_directories_content/comment_2_5083e5a729f56dab76bdc97fb247b902._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-08-24T17:19:02Z"
+ content="""
+The reason it does not recurse is that would make the number of lines/json
+records of output vary depending on the number of files in the directory.
+Which would complicate parsing git-annex's output.
+
+`git-annex add` is not actually special here. You can't
+pass a directory to `git-annex drop --batch` either.
+
+It seems to me that it's not hard to recurse directories yourself, and so
+it's better to offload the need to do that onto users of --batch, rather
+than making them deal with increased parsing complexity.
+"""]]
diff --git a/doc/todo/make_add_--batch_add_directories_content/comment_3_e320d2c3b625f24e2b93c5dab21a1e0f._comment b/doc/todo/make_add_--batch_add_directories_content/comment_3_e320d2c3b625f24e2b93c5dab21a1e0f._comment
new file mode 100644
index 0000000000..867f5d4083
--- /dev/null
+++ b/doc/todo/make_add_--batch_add_directories_content/comment_3_e320d2c3b625f24e2b93c5dab21a1e0f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-08-24T17:26:57Z"
+ content="""
+Even in --json mode there would be difficulties. Consider the case of an
+empty directory or a directory that is all gitignored. 
+If you tried to read a response after sending such a directory, and it did
+not output anything, you'd block.
+"""]]
diff --git a/doc/todo/make_add_--batch_add_directories_content/comment_4_98c678aefbc62aed7ceec8c7519d343a._comment b/doc/todo/make_add_--batch_add_directories_content/comment_4_98c678aefbc62aed7ceec8c7519d343a._comment
new file mode 100644
index 0000000000..ccdadf7dab
--- /dev/null
+++ b/doc/todo/make_add_--batch_add_directories_content/comment_4_98c678aefbc62aed7ceec8c7519d343a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2022-08-24T18:32:53Z"
+ content="""
+I wish we were talking about a \"new functionality\" (as if in times of adding `add --batch`) -- then may be `--json` output could introduce some new semantic for `add --json` to respond with smth like
+
+```
+{\"command\":\"add\",\"success\":true,\"input\":[\"directory/\"],\"error-messages\":[],\"file\": []}
+
+```
+
+thus signaling with `\"file\": []` that no files were added for that `input`. For the files which were added, it would provide one response per file (cannot populate \"file\" since can be too long)
+"""]]
diff --git a/doc/todo/make_add_--batch_add_directories_content/comment_5_4cfd430f9e9196ec293fb118e5118160._comment b/doc/todo/make_add_--batch_add_directories_content/comment_5_4cfd430f9e9196ec293fb118e5118160._comment
new file mode 100644
index 0000000000..1ad4ed7ae5
--- /dev/null
+++ b/doc/todo/make_add_--batch_add_directories_content/comment_5_4cfd430f9e9196ec293fb118e5118160._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2022-08-24T18:35:25Z"
+ content="""
+> It seems to me that it's not hard to recurse directories yourself, and so it's better to offload the need to do that onto users of --batch, rather than making them deal with increased parsing complexity.
+
+reflecting on my initial argument for this feature: is there git-annex interface to announce which paths for a folder git-annex would consider to be added (in case of `add`) or dropped (in relation to comment that `drop` cannot do that either)?  without that IMHO it is unfair to require client to somehow duplicate logic of git-annex on what files/paths it would consider for that specific operation.
+"""]]
diff --git a/doc/todo/make_add_--batch_add_directories_content/comment_6_93cb877bf71acddcf15a6c1ed48d2768._comment b/doc/todo/make_add_--batch_add_directories_content/comment_6_93cb877bf71acddcf15a6c1ed48d2768._comment
new file mode 100644
index 0000000000..2a893eaadf
--- /dev/null
+++ b/doc/todo/make_add_--batch_add_directories_content/comment_6_93cb877bf71acddcf15a6c1ed48d2768._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2022-08-24T18:40:10Z"
+ content="""
+ok, I am doomed to retract the \"unfairness\" argument since now there is `annex add --dry-run`, so something like
+
+```
+git annex add --dry-run --json d-batch | jq '.file' | sed -e \"s,\\",,g\" | git annex add --batch
+```
+
+would work.
+"""]]
diff --git a/doc/todo/make_add_--batch_add_directories_content/comment_7_2155ce0ab07a84a4f36bcf92c29ec792._comment b/doc/todo/make_add_--batch_add_directories_content/comment_7_2155ce0ab07a84a4f36bcf92c29ec792._comment
new file mode 100644
index 0000000000..8246773408
--- /dev/null
+++ b/doc/todo/make_add_--batch_add_directories_content/comment_7_2155ce0ab07a84a4f36bcf92c29ec792._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-08-24T19:01:55Z"
+ content="""
+I do think there is value in the simplicity of the current json, even if a
+"better" one could be constructed if we did not need to worry about
+backwards compatability. A new JSON object that was only seen when
+recursing a directory would need to be documented, otherwise a JSON user
+would be likely to only implement support for the JSON objects they did see.
+"""]]
diff --git a/doc/todo/make_add_--batch_add_directories_content/comment_8_5d63312c2efe3f1a25f9254ed230c66b._comment b/doc/todo/make_add_--batch_add_directories_content/comment_8_5d63312c2efe3f1a25f9254ed230c66b._comment
new file mode 100644
index 0000000000..1bea823ec5
--- /dev/null
+++ b/doc/todo/make_add_--batch_add_directories_content/comment_8_5d63312c2efe3f1a25f9254ed230c66b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: comment 5"""
+ date="2022-08-24T19:06:20Z"
+ content="""
+git-annex uses git plumbing to handle this, so it's easy to do very close
+to the same thing:
+
+For most git-annex commands except `add`, you can get a list of files
+with `git ls-files --cached`. That will include annexed files and other
+files, but of course commands like `drop` will skip the non-annexed files
+and that can be handled with the existing `--batch` interface.
+
+For `add`, use `git ls-files --others --exclude-standard`
+
+(For `add`, it also looks at `git ls-files --modified`, but you only need
+that if you want to add files that got modified.)
+"""]]
diff --git a/doc/todo/make_add_--batch_add_directories_content/comment_9_0bbdcf13e0ea7869c1633a34457d9a86._comment b/doc/todo/make_add_--batch_add_directories_content/comment_9_0bbdcf13e0ea7869c1633a34457d9a86._comment
new file mode 100644
index 0000000000..25c9bef51a
--- /dev/null
+++ b/doc/todo/make_add_--batch_add_directories_content/comment_9_0bbdcf13e0ea7869c1633a34457d9a86._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 9"
+ date="2022-08-24T19:26:59Z"
+ content="""
+FWIW, for now in the [WiP PR at DataLad level](https://github.com/datalad/datalad/pull/6977/files#diff-ef96911487cac414f5a9ea27374ac1d75ffcc45289a9e1ec69157da6fcf1ad56R1744) I would even just go back to non-batch mode if I discover the directory being provided. In most typical invocations through top-level datalad interfaces we already do `ls-files` etc to first identify the files given the user-provided list of paths, so I do not expect that code to see directories that often ;-) 
+"""]]
diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option.mdwn b/doc/todo/make_addurl_respect_annex.largefiles_option.mdwn
new file mode 100644
index 0000000000..b5eeada180
--- /dev/null
+++ b/doc/todo/make_addurl_respect_annex.largefiles_option.mdwn
@@ -0,0 +1,7 @@
+ATM git annex addurl ignores  annex.largefiles option so to automate annexification or direct add to git for a list of files I need manually to download each one of them into a FILE and then "git annex add -c annex.largefiles='exclude=*.txt'  FILE".  But it would have been convenient if I could "addurl" some files directly from urls directly into git, as per largefiles settings.
+
+N.B. I do understand that use-case might be somewhat vague, let me know if I should expand reasoning
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg.mdwn b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg.mdwn
new file mode 100644
index 0000000000..44b9e7c603
--- /dev/null
+++ b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg.mdwn
@@ -0,0 +1,138 @@
+I am trying to work out a helper for creating more meaningful automated commit messages for reprostim where we collect videos and annex assistant moves them to the server.
+
+<details>
+<summary>I was about to file this TODO report describing more detail before I realized that in principle git has a hook I could use</summary> 
+
+ATM (git annex 10.20231227-1~ndall+1) git annex assistant just commits with a generic non-descript (besides location) commit message e.g.
+
+```
+git-annex in reprostim@reproiner:/data/reprostim
+```
+
+and to figure out what actually git-annex has done takes at least rerunning `git log --stat` but in git gui of some kind takes looking at each and every commit to identify the one of interest (which e.g. modified `config.yaml`) or specific filtering etc.
+
+I would have appreciated if commits became more descriptive. Since git-annex assistant is quite reactive and (at least in our case) mostly commits one file change at a time I would have appreciated commit messages like
+
+```
+Edited config.yaml
+```
+
+or `Addded` or `Removed`.  If file is under a folder and length of the path is over some limit, would have abbreviated path to smth like ```.../config.yaml```.
+
+In case of multiple files per "action", summarized in numbers and possibly again with a hint on location
+
+```
+Edited config.yaml, added 10 files under Videos/
+```
+
+Moreover, I would have still appreciated that information annex reports about location now, but I would have made it into the extended part of the commit message after a new line, and added a version info.  So altogether could have looked like
+
+```
+Edited config.yaml, added 10 files under Videos/
+
+---
+# git annex metadata
+repository: reprostim@reproiner:/data/reprostim
+version: 10.20231227-1~ndall+1
+```
+
+And even more "ideally", if it could pick up (if exists) an optional file (e.g. `.git/ANNEX_COMMIT_META.yaml`) or some `git config` field to add to the commit, I could have then added information about the system/software I care about, e.g.
+
+```
+reprostim-version: 0.20240202.0
+```
+
+and thus have commit carrying metadata about the version which produces those video files.  ATM the video capture is completely ignorant of git-annex so I cannot go and metadata annotate those files... but that would be a different issue ... ;)
+
+As some kind of testament to possibility and usability of such commits, could navigate through commits of our automated datalad dandisets e.g. [000108](https://github.com/dandisets/000108/commits/draft/) where now without any extra tools etc I can tell where we added or removed files or just modified some metadata. It is indeed custom and more specific to our use case, but I think aforementioned would already be better.
+
+</details>
+
+<details>
+<summary>But when I created this experimental version of the script to see what info I have available</summary> 
+
+```shell
+#!/bin/sh
+#
+# A hook to provide custom commit messages for
+# changes in the repo which would be better than default ones git-annex provides.
+
+COMMIT_MSG_FILE=$1
+COMMIT_SOURCE=$2
+SHA1=$3
+
+if [ -n "$COMMIT_MSG_FILE" ]; then
+	orig_msg=$(cat "$COMMIT_MSG_FILE")
+else
+	orig_msg=NONE
+fi
+
+cat <<EOF >| "$COMMIT_MSG_FILE"
+Custom commit msg for source=$COMMIT_SOURCE sha1=$SHA1
+
+orig_msg: $orig_msg
+git-annex version: `git annex version --raw`
+environment:
+`export`
+
+EOF
+
+```
+</details>
+
+I saw that `git-annex` somehow commits while avoiding this hook entirely!
+
+```
+❯ rm random && dd if=/dev/random of=random count=1 && git annex add random && git commit -m "Added random to annex without custom commit msg"; git show git-annex | head -n 5
+1+0 records in
+1+0 records out
+512 bytes copied, 0.000295152 s, 1.7 MB/s
+add random 
+ok                                
+(recording state in git...)
+[master 470d6ce] Custom commit msg for source=message sha1=
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+commit 97423356f56f1f16b6a9646614af1d3d4d3d8717
+Author: Yaroslav Halchenko <debian@onerussian.com>
+Date:   Fri Feb 2 12:03:18 2024 -0500
+
+    update
+
+```
+
+so we got hook working for `master` and commit to `git-annex` branch went without it.  FWIW if I use annex.commitmessage -- that one works but it is inflexible
+
+```shell
+❯ rm random && dd if=/dev/random of=random count=1 && git -c annex.commitmessage="custom one" annex add random && git commit -m "Added random to annex WITH custom commit msg"; git show git-annex | head -n 5
+1+0 records in
+1+0 records out
+512 bytes copied, 8.0667e-05 s, 6.3 MB/s
+add random 
+ok                                
+(recording state in git...)
+[master 65d4400] Custom commit msg for source=message sha1=
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+commit dff6b4833f4d0e2193d43576c834212f84e54f49
+Author: Yaroslav Halchenko <debian@onerussian.com>
+Date:   Fri Feb 2 12:05:08 2024 -0500
+
+    custom one
+```
+
+I think it would be great if I could just create a "generic" prepare-commit-msg hook I could use for any branch, git-annex included.
+
+The same applies to changes git-annex assistant commits to master -- apparently it seems to avoid that hook as well since even with the hook present I got 
+
+```shell
+commit 78c5dcb6bf91b056cba7dc4ee93dd5b31f15f297 (HEAD -> master, synced/master)
+Author: Yaroslav Halchenko <debian@onerussian.com>
+Date:   Fri Feb 2 12:06:41 2024 -0500
+
+    git-annex in yoh@bilena:~/proj/datalad/trash/try-commit-message
+```
+
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_1_e7f759dccbfa134a772f15bc5f9c4b29._comment b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_1_e7f759dccbfa134a772f15bc5f9c4b29._comment
new file mode 100644
index 0000000000..0a5ff2e239
--- /dev/null
+++ b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_1_e7f759dccbfa134a772f15bc5f9c4b29._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-02-07T18:59:34Z"
+ content="""
+Re the default messages, let's just say that any choice git-annex makes
+about a default commit message will not be to some people's liking.
+
+Re the hook not being run, this is due to it using `git commit-tree`.
+As well as being used for commits to the git-annex branch, it's also
+used in a few other places, including `git-annex import`, and
+generating adjusted branches and view branches, and the assistant
+and `git-annex undo`.
+"""]]
diff --git a/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_2_acd656bf30f7e0b5def7ad7a564cf914._comment b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_2_acd656bf30f7e0b5def7ad7a564cf914._comment
new file mode 100644
index 0000000000..bf511cc113
--- /dev/null
+++ b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_2_acd656bf30f7e0b5def7ad7a564cf914._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2024-02-07T19:09:44Z"
+ content="""
+Git has two hooks, prepare-commit-msg and commit-msg. prepare-commit-msg
+is used prior to interactive editing of the commit message. Since these
+commits do not involve interactive editing, I don't think it
+necesarily makes sense for git-annex to use that hook.
+
+The commit-msg hook is simpler, and it would certianly be possible for
+git-annex to call it everywhere it does a `git commit-tree`.
+
+But if git-annex called either of these hooks, how is the hook supposed to
+know what is being committed? In the usual case, the hook 
+is called with `GIT_INDEX_FILE` pointed at an index file that 
+has been modified to include whatever is going to be in the commit
+(which may be different than what is staged in the index), and it knows
+that the working directory is being committed. So it can
+do things like `git diff --name-stage --cached` to get the files that
+are being committed, for example.
+
+In the git-annex case, `GIT_INDEX_FILE` is pointed at .git/annex/index
+when committing the git-annex branch. If a commit-msg hook uses
+`git diff --name-stage --cached`, it will diff from the working directory
+to new git-annex branch contents, which will not be a useful set of file changes
+to summarize in a commit message!
+
+Even if the hook somehow knows that the git-annex branch is being
+committed, the best it could do is diff from git-annex branch to
+`GIT_INDEX_FILE` and then it has a bunch of git-annex branch filenames
+that have changed, and is supposed to somehow generate a useful commit
+message from that. How?
+
+It seems more likely to me that you know that git-annex branch changes are
+associated with an operation, so you might commit with "added 57 photos"
+to the master branch, and then use the same message for the git-annex
+branch commit. annex.commitmessage seems to already cover that case though?
+"""]]
diff --git a/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_3_0f49414f9b4a68a16a8d47a336242f13._comment b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_3_0f49414f9b4a68a16a8d47a336242f13._comment
new file mode 100644
index 0000000000..1fe2228d48
--- /dev/null
+++ b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_3_0f49414f9b4a68a16a8d47a336242f13._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2024-02-07T19:58:11Z"
+ content="""
+Irrespective of comment #2, I do think that it makes sense for the
+assistant and `git-annex undo`, when committing to the HEAD branch,
+to run all the usual commit hooks.
+
+Actually, I don't see any reason for those to not run `git commit`.
+It seems that the use of `git commit-tree` in those dates back to 
+[[!commit 03932212ecb8940e0fe2dd09c04951990bc29422]] which involved
+direct mode.
+
+Fixed those to run commits in the usual way (though noninteractive).
+"""]]
diff --git a/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_4_203a356c1edfaf8c0c9cf01bedc2ec5d._comment b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_4_203a356c1edfaf8c0c9cf01bedc2ec5d._comment
new file mode 100644
index 0000000000..085c25fdfd
--- /dev/null
+++ b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_4_203a356c1edfaf8c0c9cf01bedc2ec5d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2024-02-08T22:08:41Z"
+ content="""
+Thank you Joey!!!  Re
+
+> so you might commit with \"added 57 photos\" to the master branch, and then use the same message for the git-annex branch commit. annex.commitmessage seems to already cover that case though?
+
+how to implement it using that config setting for `git annex assistant` mode of operation when we do not have some kind of a wrapper helper and only hooks?
+
+"""]]
diff --git a/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_5_c7a888605dd063fe7df7c569f1193f8c._comment b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_5_c7a888605dd063fe7df7c569f1193f8c._comment
new file mode 100644
index 0000000000..6b250668f9
--- /dev/null
+++ b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_5_c7a888605dd063fe7df7c569f1193f8c._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2024-02-09T17:33:10Z"
+ content="""
+I think this needs two things:
+
+1. A hook to get the commit message when committing to
+   the git-annex branch. Apparently none of the git hooks
+   are well suited to be reused for that.
+2. Ensure that the assistant always waits to commit the git-annex branch
+   until after it's committed changes to the working tree.
+
+Then you could do a variety of things...
+
+You could make the git-annex branch commit hook look for the last
+change committed to the master branch, and reuse its commit message.
+(If it's sufficiently close to the present that it's probably for
+the same change.)
+
+You could use the git commit hook to generate a git commit message but also
+store the message or a list of files somewhere for later use in the
+git-annex branch commit hook.
+
+You could write a description of your current task to a file somewhere,
+and have both hooks use that as their commit message. (Note that this does
+not need #2 above actually, only needs the hook.)
+
+---
+
+Does the assistant always wait to commit to the git-annex branch until
+after committing changes to the working tree? I'm unsure. A quick test
+indiciated it usually does, but I'm not sure why or if that's always the
+case. It would take some analysis and making this behavior more explicit to
+be able to rely on it.
+"""]]
diff --git a/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_6_b8bb9e5c7156e4defd7a2e8b7777e1ba._comment b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_6_b8bb9e5c7156e4defd7a2e8b7777e1ba._comment
new file mode 100644
index 0000000000..257e7afd4f
--- /dev/null
+++ b/doc/todo/make_annex___34__respect__34___.git__47__hooks__47__prepare-commit-msg/comment_6_b8bb9e5c7156e4defd7a2e8b7777e1ba._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2024-02-12T17:36:32Z"
+ content="""
+I've implemented annex.commitmessage-command and made sure that the
+assistant calls it after committing the working tree changes.
+
+Example of using the prepare-commit-msg hook to generate a commit message
+and then reusing that message for the git-annex branch commit:
+
+	joey@darkstar:~/tmp/a>cat .git/hooks/prepare-commit-msg
+	#!/bin/sh
+	msg="files: $(git diff --name-only --cached)"
+	echo $msg > .git/last-commit-msg
+	echo $msg > $1
+	
+	joey@darkstar:~/tmp/a>git config annex.commitmessage-command
+	cat .git/last-commit-msg
+	
+	joey@darkstar:~/tmp/a>git-annex assistant
+	joey@darkstar:~/tmp/a>date > bar
+
+	joey@darkstar:~/tmp/a>git log -n1 master
+	commit 676f87d02f031192c7eb0b7d29a6ce2429b8c727 (HEAD -> master, synced/master)
+	Author: Joey Hess <joeyh@joeyh.name>
+	Date:   Mon Feb 12 14:29:12 2024 -0400
+	
+	    files: bar
+	joey@darkstar:~/tmp/a>git log -n1 git-annex
+	commit 676588dd6d921115782e61be85f75e395cc480b6 (git-annex)
+	Author: Joey Hess <joeyh@joeyh.name>
+	Date:   Mon Feb 12 14:29:12 2024 -0400
+	
+	    files: bar
+"""]]
diff --git a/doc/todo/make_annex_info_more_efficient.mdwn b/doc/todo/make_annex_info_more_efficient.mdwn
new file mode 100644
index 0000000000..274e0e8b64
--- /dev/null
+++ b/doc/todo/make_annex_info_more_efficient.mdwn
@@ -0,0 +1,6 @@
+ATM it takes about a minute for 'git annex info' on a sizeable but not huge repository with only ~450 files under annex but a few thousand of files  (~7000) in the tree.  I am not quite sure why it takes that long since it seems to care only about annexed files.  Also it might be of benefit to parallelize some traversal operations to take advantage of multiple cpu/cores
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> I sense this one has reached its end, it's fast enough, so [[done]] --[[Joey]]
diff --git a/doc/todo/make_annex_info_more_efficient/comment_1_afd5c806f7285442401b027f82a8c629._comment b/doc/todo/make_annex_info_more_efficient/comment_1_afd5c806f7285442401b027f82a8c629._comment
new file mode 100644
index 0000000000..77090b680a
--- /dev/null
+++ b/doc/todo/make_annex_info_more_efficient/comment_1_afd5c806f7285442401b027f82a8c629._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 1"
+ date="2016-02-15T15:28:40Z"
+ content="""
+actually it does indeed relate with all the files, since \"annexed files in working tree\"... if interested -- try on this repo https://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/repo/freesurfer.git . On a clean new clone it took only 30 seconds ;)
+ 
+"""]]
diff --git a/doc/todo/make_annex_info_more_efficient/comment_2_0770ef5c4c261949a565723073480dcb._comment b/doc/todo/make_annex_info_more_efficient/comment_2_0770ef5c4c261949a565723073480dcb._comment
new file mode 100644
index 0000000000..16f0bea930
--- /dev/null
+++ b/doc/todo/make_annex_info_more_efficient/comment_2_0770ef5c4c261949a565723073480dcb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-02-15T16:51:20Z"
+ content="""
+There's --fast if you don't need the expensive to obtain data.
+
+AFAIK, the working tree traversal that makes up most of the overhead of
+info is mostly disk-bound.
+"""]]
diff --git a/doc/todo/make_annex_info_more_efficient/comment_3_c022caab61061b1f77b78485089a9052._comment b/doc/todo/make_annex_info_more_efficient/comment_3_c022caab61061b1f77b78485089a9052._comment
new file mode 100644
index 0000000000..6bea4c6a6a
--- /dev/null
+++ b/doc/todo/make_annex_info_more_efficient/comment_3_c022caab61061b1f77b78485089a9052._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 3"
+ date="2016-02-15T17:02:59Z"
+ content="""
+yeap, saw fast but it is kinda of limited use. doesn't even go through git-annex branch to report amount of storage occupied.  I didn't check but \"working tree\" is probably a current checked out branch, and that is why requires traversal and thus slow.  What is often also desired to know what is the total number/size of annexed files I have locally in any given annex.  So something along of 'du -scm .git/annex/objects' (but via info in git-annex branch instead).  May be that could be included in the --fast portion?
+
+as for disk-bound:  in my case /tmp is in ram, there is no disk activities, git-annex is 100% (1 core) busy, FWIW:
+
+[[!format sh \"\"\"
+	Command being timed: \"git annex info\"
+	User time (seconds): 27.69
+	System time (seconds): 0.68
+	Percent of CPU this job got: 99%
+	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:28.42
+\"\"\"]]
+
+"""]]
diff --git a/doc/todo/make_annex_info_more_efficient/comment_4_923dd7c22920b389488ca2625225164c._comment b/doc/todo/make_annex_info_more_efficient/comment_4_923dd7c22920b389488ca2625225164c._comment
new file mode 100644
index 0000000000..54ecf5aa8b
--- /dev/null
+++ b/doc/todo/make_annex_info_more_efficient/comment_4_923dd7c22920b389488ca2625225164c._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 4"
+ date="2016-02-15T17:05:08Z"
+ content="""
+FWIW the acctual git ls-tree command annex invokes takes 0.01 sec ;)
+"""]]
diff --git a/doc/todo/make_annex_info_more_efficient/comment_5_c6c8850aefe3ab81f1f113daa734695b._comment b/doc/todo/make_annex_info_more_efficient/comment_5_c6c8850aefe3ab81f1f113daa734695b._comment
new file mode 100644
index 0000000000..9509195364
--- /dev/null
+++ b/doc/todo/make_annex_info_more_efficient/comment_5_c6c8850aefe3ab81f1f113daa734695b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-02-19T15:58:17Z"
+ content="""
+When run on a local repository, git-annex info does not look at the
+git-annex branch. That would be slower than traversing the directories.
+(Asking for info about a remote does look at the git-annex branch.)
+
+git ls-tree does not have to look at files on disk, so is not comparable.
+The work `git annex info` does is roughly the same as a du of
+.git/annex/objects and a readlink of each symlink in the work tree.
+
+If you just want the .git/annex/objects size, perhaps it would make sense
+to have a way to get only one stat from git-annex status. Or perhaps 
+it would be as good to `du .git/annex/objects`?
+"""]]
diff --git a/doc/todo/make_annex_info_more_efficient/comment_6_804dbb72757b09e3abad3e249f704da0._comment b/doc/todo/make_annex_info_more_efficient/comment_6_804dbb72757b09e3abad3e249f704da0._comment
new file mode 100644
index 0000000000..f4bedf504c
--- /dev/null
+++ b/doc/todo/make_annex_info_more_efficient/comment_6_804dbb72757b09e3abad3e249f704da0._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2016-02-19T18:49:38Z"
+ content="""
+Also, around the time you filed this, there was a change which turned out
+to cause all files in the work tree to be read in full, and buffered in
+memory for some time. This may have to do with some of the slowdown you
+saw, especially since you have a lot of non-annexed files in the tree.
+I fixed that problem in commit b0081598c7c580d6760374c42765e94e4750e793.
+"""]]
diff --git a/doc/todo/make_annex_info_more_efficient/comment_7_44efc2bfcdde576aaca002595476a2a2._comment b/doc/todo/make_annex_info_more_efficient/comment_7_44efc2bfcdde576aaca002595476a2a2._comment
new file mode 100644
index 0000000000..174ea100a5
--- /dev/null
+++ b/doc/todo/make_annex_info_more_efficient/comment_7_44efc2bfcdde576aaca002595476a2a2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="cache?"
+ date="2016-04-01T19:56:43Z"
+ content="""
+I was about to whine in a separate TODO but then remembered that the issue is not new...
+I wondered -- since sizes report depends on what is present or not locally, and that all directly relates to the state of git-annex branch, could may be annex cache collected information associated with a given annex / current branch treeishes?  Then subsequent invocations would be fast.
+
+In my case I would want to list information on multiple annexes e.g. in current directory.  If each one takes 3-4 seconds, for 30 of them -- minutes.  With caching, at least subsequent runs should be much faster (in case of no changes, which would be frequent case I think)
+"""]]
diff --git a/doc/todo/make_annex_info_more_efficient/comment_8_90a22c51b19707ee0cecbe652c6ffa98._comment b/doc/todo/make_annex_info_more_efficient/comment_8_90a22c51b19707ee0cecbe652c6ffa98._comment
new file mode 100644
index 0000000000..7122ce91f9
--- /dev/null
+++ b/doc/todo/make_annex_info_more_efficient/comment_8_90a22c51b19707ee0cecbe652c6ffa98._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2017-10-30T18:56:14Z"
+ content="""
+It's not clear to me what needs to be done here.
+
+I tried cloning the freesurfer repository, and in it with a cold
+disk cache, `git annex info` took 0.6 seconds (warm cache, 0.1 seconds).
+
+It seems like you wanted to get the "local annex size" value, perhaps
+without the overhead of the "size of annexed files in working tree"
+value? In an indirect mode repository, the former value is obtained
+the same as `du .git/annex/objects`, and should be similarly fast.
+"""]]
diff --git a/doc/todo/make_annex_info_more_efficient/comment_9_3bec13ce0c9f0932715d73106d576e86._comment b/doc/todo/make_annex_info_more_efficient/comment_9_3bec13ce0c9f0932715d73106d576e86._comment
new file mode 100644
index 0000000000..c3d0638976
--- /dev/null
+++ b/doc/todo/make_annex_info_more_efficient/comment_9_3bec13ce0c9f0932715d73106d576e86._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 9"
+ date="2017-12-05T18:51:49Z"
+ content="""
+rereading my previous comment (it has been awhile), I was suggesting a super-dooper-feature.  I am not sure if it is still needed/desired since upon a quick try again, info seems to be indeed relatively speedy when ran on \"hot\" (e.g. 2nd time in a row; not sure how long the effect lasts ;)).
+The idea was -- to cache \"status\" information locally so subsequent invocations (if git-annex branch didn't change) could just pick it up from the cache if nothing has changed in terms of the git-annex branch and current branch position. E.g. if I am at a commit ABC and at git-annex branch state XYZ, why not to have .git/annex/caches/info/XYZ-ABC.json which would pretty much have output of `git annex info --json` which it could reuse, without ANY traversal of git-annex branch or local files tree, on a subsequent call if still in XYZ state and that commit.  Whenever git-annex branch progresses away from XYZ, all previous ones in the cache could be let RiP.
+
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster.mdwn b/doc/todo/make_copy_--fast__faster.mdwn
new file mode 100644
index 0000000000..824daec34d
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster.mdwn
@@ -0,0 +1,8 @@
+I was trying to copy files which failed to copy (3 out of 6,000) to remote host after copy -J4.  Succeeded.  But with subsequent runs, apparently even with copy --fast it takes annex 10 sec for annex to realize there is nothing to copy. git ls-files  which annex calls returns list immediately, so it is really some parsing/access to data under git-annex branch which takes awhile.  I think we had similar discussion before but couldn't find.  So I wondered to whine again to see if some optimization is possible to make --fast copies faster, especially whenever there is nothing to copy.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> closing as yoh is happy. [[done]]. Note that I copied benechmarking
+> related comments to the [[/profiling]] page for future reference.
+> --[[Joey]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_10_1af4ac0d37c876912678522895c1656b._comment b/doc/todo/make_copy_--fast__faster/comment_10_1af4ac0d37c876912678522895c1656b._comment
new file mode 100644
index 0000000000..868b103646
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_10_1af4ac0d37c876912678522895c1656b._comment
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2016-09-29T18:33:33Z"
+ content="""
+* Optimised key2file and file2key. 18% scanning time speedup.
+* Optimised adjustGitEnv. 50% git-annex branch query speedup
+* Optimised parsePOSIXTime. 10% git-annex branch query speedup
+* Tried making catObjectDetails.receive use ByteString for parsing, 
+  but that did not seem to speed it up significantly.
+  So it parsing is already fairly optimal, it's just that a
+  lot of data passes through it when querying the git-annex
+  branch.
+
+After all that, profiling `git-annex find`:
+
+	        Thu Sep 29 16:51 2016 Time and Allocation Profiling Report  (Final)
+	
+	           git-annex.1 +RTS -p -RTS find
+	
+	        total time  =        1.73 secs   (1730 ticks @ 1000 us, 1 processor)
+	        total alloc = 1,812,406,632 bytes  (excludes profiling overheads)
+	
+	COST CENTRE            MODULE                  %time %alloc
+	
+	md5                    Data.Hash.MD5            28.0   37.9
+	catchIO                Utility.Exception        10.2   12.5
+	inAnnex'.checkindirect Annex.Content             9.9    3.7
+	catches                Control.Monad.Catch       8.7    5.7
+	readish                Utility.PartialPrelude    5.7    3.0
+	isAnnexLink            Annex.Link                5.0    8.4
+	keyFile                Annex.Locations           4.2    5.8
+	spanList               Data.List.Utils           4.0    6.3
+	startswith             Data.List.Utils           2.0    1.3
+
+And `git-annex find --not --in web`:
+
+	        Thu Sep 29 16:35 2016 Time and Allocation Profiling Report  (Final)
+	
+	           git-annex +RTS -p -RTS find --not --in web
+	
+	        total time  =        5.24 secs   (5238 ticks @ 1000 us, 1 processor)
+	        total alloc = 3,293,314,472 bytes  (excludes profiling overheads)
+	
+	COST CENTRE               MODULE                      %time %alloc
+	
+	catObjectDetails.receive  Git.CatFile                  12.9    5.5
+	md5                       Data.Hash.MD5                10.6   20.8
+	readish                   Utility.PartialPrelude        7.3    8.2
+	catchIO                   Utility.Exception             6.7    7.3
+	spanList                  Data.List.Utils               4.1    7.4
+	readFileStrictAnyEncoding Utility.Misc                  3.5    1.3
+	catches                   Control.Monad.Catch           3.3    3.2
+
+So, quite a large speedup overall!
+
+This leaves md5 still unoptimised at 10-28% of CPU use. I looked at switching
+it to cryptohash's implementation, but it would require quite a lot of
+bit-banging math to pull the used values out of the ByteString containing
+the md5sum.
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_11_1ca8d9765e6e3a18ae09df74bc390a00._comment b/doc/todo/make_copy_--fast__faster/comment_11_1ca8d9765e6e3a18ae09df74bc390a00._comment
new file mode 100644
index 0000000000..619351d4ca
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_11_1ca8d9765e6e3a18ae09df74bc390a00._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2017-05-15T21:56:52Z"
+ content="""
+Switched from MissingH to cryptonite for md5. It did move md5 out of the top CPU spot but
+the overall runtime didn't change much. Memory allocations did go down by a
+good amount.
+
+Updated profiles:
+
+	           git-annex +RTS -p -RTS find
+	
+	        total time  =        1.63 secs   (1629 ticks @ 1000 us, 1 processor)
+	        total alloc = 1,496,336,496 bytes  (excludes profiling overheads)
+	
+	COST CENTRE              MODULE                     SRC                                             %time %alloc
+	
+	catchIO                  Utility.Exception          Utility/Exception.hs:79:1-17                     14.1   15.1
+	inAnnex'.checkindirect   Annex.Content              Annex/Content.hs:(108,9)-(119,39)                10.6    4.8
+	catches                  Control.Monad.Catch        src/Control/Monad/Catch.hs:(432,1)-(436,76)       8.6    6.9
+	spanList                 Data.List.Utils            src/Data/List/Utils.hs:(150,1)-(155,36)           6.7   11.1
+	isAnnexLink              Annex.Link                 Annex/Link.hs:35:1-85                             5.0   10.2
+	keyFile                  Annex.Locations            Annex/Locations.hs:(456,1)-(462,19)               5.0    7.0
+	readish                  Utility.PartialPrelude     Utility/PartialPrelude.hs:(48,1)-(50,20)          3.8    2.0
+	startswith               Data.List.Utils            src/Data/List/Utils.hs:103:1-23                   3.6    2.3
+	splitc                   Utility.Misc               Utility/Misc.hs:(52,1)-(54,25)                    3.4    6.5
+	s2w8                     Data.Bits.Utils            src/Data/Bits/Utils.hs:65:1-15                    2.6    6.4
+	keyPath                  Annex.Locations            Annex/Locations.hs:(492,1)-(494,23)               2.5    4.4
+	fileKey.unesc            Annex.Locations            Annex/Locations.hs:(469,9)-(474,39)               2.0    3.5
+	copyAndFreeze            Data.ByteArray.Methods     Data/ByteArray/Methods.hs:(224,1)-(227,21)        1.8    0.5
+
+	           git-annex +RTS -p -RTS find --not --in web
+	
+	        total time  =        5.33 secs   (5327 ticks @ 1000 us, 1 processor)
+	        total alloc = 2,908,489,000 bytes  (excludes profiling overheads)
+	
+	COST CENTRE          MODULE                     SRC                                             %time %alloc
+	
+	catObjectDetails.\   Git.CatFile                Git/CatFile.hs:(80,72)-(88,97)                    7.8    2.8
+	catchIO              Utility.Exception          Utility/Exception.hs:79:1-17                      7.6    8.3
+	spanList             Data.List.Utils            src/Data/List/Utils.hs:(150,1)-(155,36)           5.8    9.1
+	readish              Utility.PartialPrelude     Utility/PartialPrelude.hs:(48,1)-(50,20)          4.5    4.0
+	parseResp            Git.CatFile                Git/CatFile.hs:(113,1)-(124,28)                   4.4    2.9
+	readFileStrict       Utility.Misc               Utility/Misc.hs:33:1-59                           3.7    1.6
+	catches              Control.Monad.Catch        src/Control/Monad/Catch.hs:(432,1)-(436,76)       3.1    3.6
+	encodeW8             Utility.FileSystemEncoding Utility/FileSystemEncoding.hs:(131,1)-(133,70)    3.1    2.3
+	
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_12_14856a2886cf73d1bee57ef9fad01661._comment b/doc/todo/make_copy_--fast__faster/comment_12_14856a2886cf73d1bee57ef9fad01661._comment
new file mode 100644
index 0000000000..4c5b6f7d9b
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_12_14856a2886cf73d1bee57ef9fad01661._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2017-10-30T18:48:21Z"
+ content="""
+There's of course always possibility of more speed improvements, but I'm
+wondering if this has already been addressed sufficient to close it?
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_13_0f8e2127cea96c4f9609fa7599b1eec9._comment b/doc/todo/make_copy_--fast__faster/comment_13_0f8e2127cea96c4f9609fa7599b1eec9._comment
new file mode 100644
index 0000000000..e52d1bc2f5
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_13_0f8e2127cea96c4f9609fa7599b1eec9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="thanks"
+ date="2017-10-30T20:04:48Z"
+ content="""
+I do think that things became smoother/faster since then.  I guess we could consider this one closed for now, and I will keep in mind that --from mode is faster.
+
+Cheers,
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_1_24a9ca652007a18f18b368232cf549da._comment b/doc/todo/make_copy_--fast__faster/comment_1_24a9ca652007a18f18b368232cf549da._comment
new file mode 100644
index 0000000000..b53e04fd9f
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_1_24a9ca652007a18f18b368232cf549da._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-21T13:53:15Z"
+ content="""
+--to or --from? The latter is faster due to locality..
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_2_0c67f467d730a0966b43171de0382c42._comment b/doc/todo/make_copy_--fast__faster/comment_2_0c67f467d730a0966b43171de0382c42._comment
new file mode 100644
index 0000000000..6c37e77e53
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_2_0c67f467d730a0966b43171de0382c42._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 2"
+ date="2016-05-25T01:09:56Z"
+ content="""
+\"to remote host \"  so it was \"--to\". annex is already aware of having those files in that remote (see below).
+
+[[!format sh \"\"\"
+$> git annex copy --to=datalad-public --fast .        
+git annex copy --to=datalad-public --fast .  7.33s user 0.91s system 55% cpu 14.772 total
+
+$> git annex info
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 5
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	123c73e5-a8dc-4cff-8ffc-679c7ea67f94 -- yoh@smaug:/mnt/datasets/datalad/crawl/neurovault [here]
+ 	48c1556f-6241-45de-9497-338d437fcb62 -- yoh@falkor:/srv/datasets.datalad.org/www/neurovault/snapshots [datalad-public]
+ 	af2785da-2538-4346-a6f6-f2f30fc3f025 -- [datalad-archives]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 31.42 terabytes (+1 megabyte reserved)
+local annex keys: 6615
+local annex size: 12.77 gigabytes
+annexed files in working tree: 6628
+size of annexed files in working tree: 6.31 gigabytes
+bloom filter size: 32 mebibytes (1.3% full)
+backend usage: 
+	SHA256E: 6628
+
+$> git annex whereis | head -30               
+whereis 1003/13873.nii.gz (3 copies) 
+  	123c73e5-a8dc-4cff-8ffc-679c7ea67f94 -- yoh@smaug:/mnt/datasets/datalad/crawl/neurovault [here]
+   	48c1556f-6241-45de-9497-338d437fcb62 -- yoh@falkor:/srv/datasets.datalad.org/www/neurovault/snapshots [datalad-public]
+   	af2785da-2538-4346-a6f6-f2f30fc3f025 -- [datalad-archives]
+
+  datalad-archives: dl+archive:SHA256E-s6460020224--710cc05117e2290e2f793271d11e26452cdc111121e09a937dbf5a34b3cc0107.tar/neurovault_snapshot/1003/13873.nii.gz#size=23262
+ok
+whereis 1003/13874.nii.gz (3 copies) 
+  	123c73e5-a8dc-4cff-8ffc-679c7ea67f94 -- yoh@smaug:/mnt/datasets/datalad/crawl/neurovault [here]
+   	48c1556f-6241-45de-9497-338d437fcb62 -- yoh@falkor:/srv/datasets.datalad.org/www/neurovault/snapshots [datalad-public]
+   	af2785da-2538-4346-a6f6-f2f30fc3f025 -- [datalad-archives]
+...
+> git annex copy --to=datalad-public .       
+copy 1003/13873.nii.gz (checking datalad-public...) yoh@datasets.datalad.org's password: 
+
+\"\"\"]]
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_3_5cd9e6b5d6d015120b5852bd212314aa._comment b/doc/todo/make_copy_--fast__faster/comment_3_5cd9e6b5d6d015120b5852bd212314aa._comment
new file mode 100644
index 0000000000..d4aa80ecb3
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_3_5cd9e6b5d6d015120b5852bd212314aa._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-05-31T16:02:01Z"
+ content="""
+copy --to has to query the git-annex branch to see if the file is on the remote.
+So it has worse locality than copy --from, which can simply stat the local
+file to see if it's present.
+
+Whatever inneficiencies git-annex has here are well swamped by the overhead
+of git querying the branch. 
+
+When the remote has most of the files already, `git annex copy --to remote` is
+similar to `git annex find --not --in remote`.
+
+Here I've ran that under /usr/bin/time, and it looks like git-annex
+ran for 89 seconds out of the 260 second runtime. So at least 65% of the total
+runtime is spent by git querying the branch.
+
+	89.26user 6.92system 4:20.80elapsed 36%CPU (0avgtext+0avgdata 75584maxresident)k
+	516432inputs+0outputs (0major+31156minor)pagefaults 0swaps
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_4_3ac10a07c74e5debafc9ae574d26c955._comment b/doc/todo/make_copy_--fast__faster/comment_4_3ac10a07c74e5debafc9ae574d26c955._comment
new file mode 100644
index 0000000000..bb9258b45c
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_4_3ac10a07c74e5debafc9ae574d26c955._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-08-03T16:02:46Z"
+ content="""
+--failed can now be used to retry only failed transfers. So that will be a
+lot faster in that specific case. 
+
+Leaving this bug open for the general wishlist that copy --fast be somehow
+a lot faster than it is at finding things that need to be copied.
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_5_eb7008151a59e35c7850df3a86cf3587._comment b/doc/todo/make_copy_--fast__faster/comment_5_eb7008151a59e35c7850df3a86cf3587._comment
new file mode 100644
index 0000000000..8fbd3beba8
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_5_eb7008151a59e35c7850df3a86cf3587._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="also CPU (on git and git-annex processes) doesn't go to 100%"
+ date="2016-09-08T16:32:08Z"
+ content="""
+seems to wobble around 50% for each one of git and git-annex processes... probably would be an overkill but may be it is easy in haskell (so throwing idea around) if communication was done in async fashion (git-annex wouldn't wait for git to respond but would process its own queue of already returned from git results, while submitting new ones as soon as previous comes out from the --batch). That might make both processes busy to a 100%.
+
+another idea -- could may be 'annex find' get a -J flag thus starting multiple git ls-files querying processes?
+
+or both ideas are too overengineered/not tractable? ;)
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_6_3a08de49e9661f9df5bab272e170461a._comment b/doc/todo/make_copy_--fast__faster/comment_6_3a08de49e9661f9df5bab272e170461a._comment
new file mode 100644
index 0000000000..07cf33a546
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_6_3a08de49e9661f9df5bab272e170461a._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 6"
+ date="2016-09-09T12:47:30Z"
+ content="""
+ha -- a wild idea:  instead of   git ls-files git-annex | git cat-file   you could be much  better off  with using \"git archive\" to dump the content of all the files under git-annex branch!
+
+[[!format sh \"\"\"
+$> GIT_TRACE_PACKET=true GIT_TRACE_PERFORMANCE=true git annex find --not --in here >/dev/null                                      
+08:46:11.246625 trace.c:420             performance: 0.000291504 s: git command: '/usr/lib/git-annex.linux/shimmed/git/git' 'config' '--null' '--list'
+08:46:11.267559 trace.c:420             performance: 0.000466198 s: git command: '/usr/lib/git-annex.linux/shimmed/git/git' '--git-dir=.git' '--work-tree=.' '--literal-pathspecs' 'show-ref' 'git-annex'
+08:46:11.271522 trace.c:420             performance: 0.000434572 s: git command: '/usr/lib/git-annex.linux/shimmed/git/git' '--git-dir=.git' '--work-tree=.' '--literal-pathspecs' 'show-ref' '--hash' 'refs/heads/git-annex'
+08:46:22.647051 trace.c:420             performance: 11.387079176 s: git command: '/usr/lib/git-annex.linux/shimmed/git/git' '--git-dir=.git' '--work-tree=.' '--literal-pathspecs' 'ls-files' '--cached' '-z' '--'
+08:46:23.616005 trace.c:420             performance: 12.339791892 s: git command: '/usr/lib/git-annex.linux/shimmed/git/git' '--git-dir=.git' '--work-tree=.' '--literal-pathspecs' 'cat-file' '--batch'
+08:46:23.616052 trace.c:420             performance: 12.391364205 s: git command: 'git' 'annex' 'find' '--not' '--in' 'here'
+
+
+$> git ls-tree -r --name-only git-annex | sed -e \"s/^/git-annex:/g\" | time git --git-dir=.git cat-file --buffer --batch >| /tmp/111
+git --git-dir=.git cat-file --buffer --batch >| /tmp/111  7.80s user 0.40s system 99% cpu 8.214 total
+                
+
+$> time git archive git-annex > /dev/null                                                                                          
+git archive git-annex > /dev/null  0.20s user 0.00s system 97% cpu 0.212 total
+
+\"\"\"]]
+
+x40 times faster (if we disregard time to parse/split tar, but it should not be way too much I think)
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_7_3f52b6e19035d3c891356c6d98035987._comment b/doc/todo/make_copy_--fast__faster/comment_7_3f52b6e19035d3c891356c6d98035987._comment
new file mode 100644
index 0000000000..c47132591d
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_7_3f52b6e19035d3c891356c6d98035987._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2016-09-14T15:28:23Z"
+ content="""
+First, note that git-annex 6.20160619 sped up the git-annex 
+command startup time significantly. Please be sure to use a current
+version in benchmarks, and state the version.
+
+`git archive` (and `git cat-file --batch --batch-all-objects`) are just
+reading packs and loose objects in disk order and dumping out the contents.
+`git cat-file --batch` has to look up objects in the pack index files, seek
+in the pack, etc. It's not a fair comparison.
+
+Note that `git annex find`, when used without options like --in or --copies, 
+does not need to read anything from `git cat-file` at all. The
+`GIT_TRACE_PERFORMANCE` you show is misleading; it's just showing how long
+the git command is left running, idle.
+
+`git annex find`'s overhead should be purely traversing the filesystem tree
+and checking what symlinks point to files. You can write programs that do
+the same thing without using git at all (or only `git ls-files`), and
+compare them to git-annex's time; that would be a fairer comparison.
+Ideally, `git annex find` would be entirely system call bound and would use
+very little CPU itself.
+
+By contrast, `git annex copy` makes significant use of `git cat-file --batch`,
+since it needs to look up location log information to see if the
+--to/--from remote has the files.
+
+`git annex copy -J` already parallelizes the parts of the code that look at
+the location log. Including spinning up a separate `git cat-file --batch`
+processes for each thread, so they won't contend on such queries. So I
+would expect that to make it faster, even leaving aside the speed benefits
+of doing the actual copies in parallel.
+
+My feeling is that the best way to speed these up is going to be in one 
+of these classes:
+
+* It's possible that `git cat-file --batch` is somehow slower than it needs
+  to be. Perhaps it's not doing good caching between queries or has
+  inneficient seralization/bad stdio buffering. It might just be the case 
+  that using something  like libgit2 instead would be faster.
+  (Due to libgit2's poor interface stability, it would have to be an
+  optional build flag.)
+
+* Many small optimisations to the code. The use of Strings throughout
+  git-annex could well be a source of systematic small innefficiences,
+  and using ByteString might eliminate those. (But this would be a huge job.)
+  (The `git cat-file --batch` communication is already done using
+  bytestrings.)
+
+* A completely lateral move. For example, if git-annex kept its own
+  database recording which files are present, then `git annex find`
+  could do a simple database query and not need to chase all the symlinks.
+  But such a database needs to somehow be kept in sync or reconciled
+  with the git index, it's not an easy thing.
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_8_c1f99493f5e5c362d5c39f048280b11b._comment b/doc/todo/make_copy_--fast__faster/comment_8_c1f99493f5e5c362d5c39f048280b11b._comment
new file mode 100644
index 0000000000..e0f4987a02
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_8_c1f99493f5e5c362d5c39f048280b11b._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""profiling"""
+ date="2016-09-26T19:20:36Z"
+ content="""
+Built git-annex with profiling, using `stack build --profile`
+
+(For reproduciblity, running git-annex in a clone of the git-annex repo
+https://github.com/RichiH/conference_proceedings with rev
+2797a49023fc24aff6fcaec55421572e1eddcfa2 checked out. It has 9496 annexed
+objects.)
+
+Profiling `git-annex find +RTS -p`:
+
+	        total time  =        3.53 secs   (3530 ticks @ 1000 us, 1 processor)
+	        total alloc = 3,772,700,720 bytes  (excludes profiling overheads)
+	
+	COST CENTRE            MODULE                  %time %alloc
+	
+	spanList               Data.List.Utils          32.6   37.7
+	startswith             Data.List.Utils          14.3    8.1
+	md5                    Data.Hash.MD5            12.4   18.2
+	join                   Data.List.Utils           6.9   13.7
+	catchIO                Utility.Exception         5.9    6.0
+	catches                Control.Monad.Catch       5.0    2.8
+	inAnnex'.checkindirect Annex.Content             4.6    1.8
+	readish                Utility.PartialPrelude    3.0    1.4
+	isAnnexLink            Annex.Link                2.6    4.0
+	split                  Data.List.Utils           1.5    0.8
+	keyPath                Annex.Locations           1.2    1.7
+
+
+This is interesting!
+
+Fully 40% of CPU time and allocations are in list (really String) processing,
+and the details of the profiling report show that `spanList` and `startsWith`
+and `join` are all coming from calls to `replace` in `keyFile` and `fileKey`.
+Both functions nest several calls to replace, so perhaps that could be unwound
+into a single pass and/or a ByteString used to do it more efficiently.
+
+12% of run time is spent calculating the md5 hashes for the hash
+directories for .git/annex/objects. Data.Hash.MD5 is from missingh, and
+it is probably a quite unoptimised version. Switching to the version
+if cryptonite would probably speed it up a lot.
+"""]]
diff --git a/doc/todo/make_copy_--fast__faster/comment_9_f4d802a28b79905da0cb24af6cb65b0a._comment b/doc/todo/make_copy_--fast__faster/comment_9_f4d802a28b79905da0cb24af6cb65b0a._comment
new file mode 100644
index 0000000000..9692ad2d73
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_9_f4d802a28b79905da0cb24af6cb65b0a._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""more profiling"""
+ date="2016-09-26T19:59:43Z"
+ content="""
+Instead of profiling `git annex copy --to remote`, I profiled `git annex
+find --not --in web`, which needs to do the same kind of location log lookup.
+
+	        total time  =       12.41 secs   (12413 ticks @ 1000 us, 1 processor)
+	        total alloc = 8,645,057,104 bytes  (excludes profiling overheads)
+	
+	COST CENTRE               MODULE                      %time %alloc
+	
+	adjustGitEnv              Git.Env                      21.4   37.0
+	catchIO                   Utility.Exception            13.2    2.8
+	spanList                  Data.List.Utils              12.6   17.9
+	parsePOSIXTime            Logs.TimeStamp                6.1    5.0
+	catObjectDetails.receive  Git.CatFile                   5.9    2.1
+	startswith                Data.List.Utils               5.7    3.8
+	md5                       Data.Hash.MD5                 5.1    7.9
+	join                      Data.List.Utils               2.4    6.0
+	readFileStrictAnyEncoding Utility.Misc                  2.2    0.5
+
+The adjustGitEnv overhead is a surprise! It seems it is getting called once
+per file, and allocating a new copy of the environment each time. Call stack:
+withIndex calls withIndexFile calls addGitEnv calls adjustGitEnv.
+Looks like simply making gitEnv be cached at startup would avoid most of
+the adjustGitEnv slowdown.
+
+(The catchIO overhead is a false reading; the detailed profile shows
+that all its time and allocations are inherited. getAnnexLinkTarget
+is running catchIO in the expensive case, so readSymbolicLink is
+the actual expensive bit.)
+
+The parsePOSIXTime comes from reading location logs. It's implemented
+using a generic Data.Time.Format.parseTime, which uses a format string
+"%s%Qs". A custom parser that splits into seconds and picoseconds
+and simply reads both numbers might be more efficient.
+
+catObjectDetails.receive is implemented using mostly String and could
+probably be sped up by being converted to use ByteString.
+"""]]
diff --git a/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__.mdwn b/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__.mdwn
new file mode 100644
index 0000000000..eb0ce7a329
--- /dev/null
+++ b/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__.mdwn
@@ -0,0 +1,33 @@
+I am running addurl (via `datalad addurls`) on a quite heavy in number of files git/annex repo.
+
+Here is the htop I see (git annex is `8.20200908-gcfc74c2f4` I believe ;))
+
+
+[[!format sh """
+ CPU% MEM%   TIME+  Command                                                                                                                                                                                                                                                                                                               
+  0.0  0.0  0:12.62 │  └─ zsh
+  2.0  3.1  0:59.03 │     ├─ python3 datalad-nda/scripts/datalad-nda --pdb add2datalad -i /proc/self/fd/15 -d testds-fast-full2 --fast
+  0.0  0.0  0:00.09 │     │  ├─ git --library-path /home/yoh/.tmp/ga-RIFzW89/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-RIFzW89/git-annex.linux/shimmed/git/git annex addurl --fast --with-files --json --json-error-messages --batch
+  4.6  0.1  0:40.33 │     │  │  └─ git-annex --library-path /home/yoh/.tmp/ga-RIFzW89/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-RIFzW89/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+ 45.2  0.2 10:27.06 │     │  │     ├─ git --library-path /home/yoh/.tmp/ga-RIFzW89/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-RIFzW89/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. check-ignore -z --stdin --verbose --non-matching                                                                         
+  3.3  0.0  0:27.42 │     │  │     ├─ python3 /mnt/scrap/tmp/abcd/datalad/venvs/dev3/bin/git-annex-remote-datalad
+  0.0  0.0  0:00.00 │     │  │     ├─ git --library-path /home/yoh/.tmp/ga-RIFzW89/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-RIFzW89/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch-check=%(objectname) %(objecttype) %(objectsize)
+  2.0  0.1  0:24.46 │     │  │     ├─ git --library-path /home/yoh/.tmp/ga-RIFzW89/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-RIFzW89/git-annex.linux/shimmed/git/git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+  0.0  0.1  0:02.17 │     │  │     ├─ git-annex --library-path /home/yoh/.tmp/ga-RIFzW89/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-RIFzW89/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+  0.0  0.1  0:00.00 │     │  │     ├─ git-annex --library-path /home/yoh/.tmp/ga-RIFzW89/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-RIFzW89/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+  0.0  0.1  0:04.55 │     │  │     ├─ git-annex --library-path /home/yoh/.tmp/ga-RIFzW89/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-RIFzW89/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+  0.0  0.1  0:02.35 │     │  │     └─ git-annex --library-path /home/yoh/.tmp/ga-RIFzW89/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-RIFzW89/git-annex.linux/shimmed/git-annex/git-annex addurl --fast --with-files --json --json-error-messages --batch
+  0.0  0.0  0:00.08 │     │  ├─ git --library-path /home/yoh/.tmp/ga-RIFzW89/git-annex.linux//lib/x86_64-linux-gnu: /home/yoh/.tmp/ga-RIFzW89/git-annex.linux/shimmed/git/git annex addurl --fast --with-files --json --json-error-messages --batch
+
+"""]]
+
+so -- `git check-ignore --batch` is the busiest in cpu process (30-60%). 
+I do not mind it to be CPU heavy, but I am afraid that its use is not `async` so while it is "processing", annex is waiting before proceeding to the next entry.
+If it is not so -- please just close this.
+
+If annex does wait, since it is a --batch operation, I wonder if somehow invocation of `git check-ignore` could be delayed to be done in a single shot at the end of the batched process or something like that? or may be it relates to [batch_async](https://git-annex.branchable.com/todo/batch_async/) WiP TODO, i.e. internally annex would make it an async call.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> I think my comments address this, so [[done]].. --[[Joey]]
diff --git a/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_1_f8ea668cd8a405226113ef2edeb9e678._comment b/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_1_f8ea668cd8a405226113ef2edeb9e678._comment
new file mode 100644
index 0000000000..8b58d56412
--- /dev/null
+++ b/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_1_f8ea668cd8a405226113ef2edeb9e678._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-09-18T16:01:59Z"
+ content="""
+You can use --force to disable the ignores check.
+
+It might be a good idea to have an explict option to do it, since --force
+might also have other effects.
+
+With -J, git-annex will run more check-ignore processes, and so won't
+bottleneck on one, but IDK how much if any that actually speeds it up.
+Since batch async is implemented already, you can try and find out now!
+"""]]
diff --git a/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_2_50d04e85c0504f920ed7d2ccb9cdb6dd._comment b/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_2_50d04e85c0504f920ed7d2ccb9cdb6dd._comment
new file mode 100644
index 0000000000..1d3947e8bf
--- /dev/null
+++ b/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_2_50d04e85c0504f920ed7d2ccb9cdb6dd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-09-18T17:20:26Z"
+ content="""
+implemented --no-check-gitignore option, but I guess you might want to use
+--force to avoid depending on a new git-annex.
+"""]]
diff --git a/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_3_2ebd0de2fe55230f4e589bd295c828a2._comment b/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_3_2ebd0de2fe55230f4e589bd295c828a2._comment
new file mode 100644
index 0000000000..b486c128a8
--- /dev/null
+++ b/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_3_2ebd0de2fe55230f4e589bd295c828a2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2020-09-18T20:11:25Z"
+ content="""
+thanks Joey.  I am yet to digest though if I would like (would be safe) to avoid `git check-ignore` call in general in my use-cases.  Originally I was wondering more about some kind of \"optimization\" ;) async --batch could help indeed, we just might need to change our code to support it (have not yet looked into the code)
+"""]]
diff --git a/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_4_7d1154d80feca270f6226374a51a0609._comment b/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_4_7d1154d80feca270f6226374a51a0609._comment
new file mode 100644
index 0000000000..938553d46c
--- /dev/null
+++ b/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_4_7d1154d80feca270f6226374a51a0609._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-09-29T15:48:52Z"
+ content="""
+Should I reopen this? 
+
+Skipping checking ignores seems like a likely approach for you, because
+any url you want to add seems likely to have an extension that is not
+ignored, and it's very unlikely that the filename that addurl picks will be
+ignored either.
+
+I can see two further ways to optimise it... 
+
+The ignores check currently runs in the same stage as the download. Making
+the download happen in perform stage and the ignores check and git add
+happen in cleanup would improve parallelization because it would not block
+other downloads on the ignores check.
+
+Or, the ignores could not be checked by git-annex before git add,
+and instead git add be relied on to check, and if it fails,
+just clean up the annex link from the working tree. But the problem with
+that is, it does batch up calls to git add, and so if git add failed, it
+would be difficult to know which file(s) it rejected due to being ignored
+in order to clean them up. Also, I guess git add probably does an
+equivilant amount of work as git check-ignore to check the ignores, so
+at most this would halve that work, and eliminate a little overhead in
+talking to git check-ignore.
+
+Oh hmm, that suggests a third possibility: Run git add -f, since we've
+already checked the ignores, which would probably avoid it doing the ignore
+checking work.
+
+(Another other problem with skipping git check-ignore is it would need
+to download the url before git add checks if it's ignored ...
+but in fact it already does download the file before check-ignore, because
+it needs to determine if youtube-dl should be used, which needs the content
+of the url, and when youtube-dl is used, a different filename will be used.)
+"""]]
diff --git a/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_5_8e931e54738640cecf0bbaf80a3e8660._comment b/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_5_8e931e54738640cecf0bbaf80a3e8660._comment
new file mode 100644
index 0000000000..ade7b88321
--- /dev/null
+++ b/doc/todo/make_git_check-ignore_less___34__cpu_heavy__34___while_addurl_--batch_--fast___63__/comment_5_8e931e54738640cecf0bbaf80a3e8660._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-09-29T16:58:18Z"
+ content="""
+Implemented the git add -f optimisation. Unsure how much of an optimisation
+it really is tho.
+"""]]
diff --git a/doc/todo/make_status_show_staged_files/comment_1_3874f5da5a300b7d443e1ad6373b4099._comment b/doc/todo/make_status_show_staged_files/comment_1_3874f5da5a300b7d443e1ad6373b4099._comment
new file mode 100644
index 0000000000..7e7cc139b1
--- /dev/null
+++ b/doc/todo/make_status_show_staged_files/comment_1_3874f5da5a300b7d443e1ad6373b4099._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-11-03T17:03:34Z"
+ content="""
+It's documentation says it shows files that have been deleted/modified/are
+not checked into git. Not staged files.
+
+So, this is not a bug report, it's a request to make git annex status list
+more files.
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__.mdwn b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__.mdwn
new file mode 100644
index 0000000000..96fc9e0d22
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__.mdwn
@@ -0,0 +1,65 @@
+Original TODO issue was [reincarnated](https://git-annex.branchable.com/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__/#comment-0a78eeecf21ae7778436e233f9df22c2) and (thank you `git log -S`)  and originally marked fixed by [6.20160613-81-gc4229be9a AKA 6.20160619~60](https://git.kitenet.net/index.cgi/git-annex.git/commit/?id=c4229be9a7a2318ef71b9ae433bc14bf604c9caf). Using standalone build of annex is notably (~30%) slower than any other.  I was stracing running of a sample datalad test and looked inside to see e.g.
+
+```
+4188353 1595043333.316032 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
+4188353 1595043333.316089 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
+4188353 1595043333.316524 openat(AT_FDCWD, "/usr/lib/git-annex.linux/bin/git", O_RDONLY) = 3
+4188353 1595043333.316818 openat(AT_FDCWD, "/usr/lib/git-annex.linux/shimmed/git/git", O_RDONLY|O_CLOEXEC) = 3
+4188353 1595043333.316992 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/tls/haswell/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317022 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/tls/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317049 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/tls/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317079 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/tls/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317106 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/haswell/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317133 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317160 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317187 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317216 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/tls/haswell/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317248 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/tls/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317278 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/tls/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317306 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/tls/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317336 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/haswell/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317367 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317395 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317426 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317455 openat(AT_FDCWD, "/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317482 openat(AT_FDCWD, "/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317509 openat(AT_FDCWD, "/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317536 openat(AT_FDCWD, "/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317562 openat(AT_FDCWD, "/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317589 openat(AT_FDCWD, "/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317615 openat(AT_FDCWD, "/usr/lib/git-annex.linux//etc/ld.so.conf.d/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317642 openat(AT_FDCWD, "/usr/lib/git-annex.linux//etc/ld.so.conf.d/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317670 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/tls/haswell/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317697 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/tls/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317724 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/tls/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317750 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/tls/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317778 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/haswell/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317805 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317832 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317858 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317889 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/haswell/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317917 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317943 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317970 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.317997 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/haswell/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.318024 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.318051 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.318077 openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.318105 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/tls/haswell/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.318135 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/tls/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.318162 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/tls/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.318189 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/tls/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.318216 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/haswell/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.318243 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.318270 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+4188353 1595043333.318299 openat(AT_FDCWD, "/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = 3
+
+```
+so there is about 40 unsuccessful attempts to find/open libpcre2-8.so.0 . Other libraries might be less or more likely -- I didn't check... this one alone starts at 1595043333.316992 and finally succeeds at 1595043333.318299 -- so ~1.3 msec to just find this single library in a single invocation of git-annex (and we do many of them)... may be prelink or some other trick could be tried again?  or if that is the lost effect of the original patch -- could there be some regression test added ?
+
+git annex build: 8.20200617+git192-g5849bd634-1~ndall+1
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_10_20db4ecf9debcc2662ec69a6ad9b37c6._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_10_20db4ecf9debcc2662ec69a6ad9b37c6._comment
new file mode 100644
index 0000000000..2522a8f7a0
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_10_20db4ecf9debcc2662ec69a6ad9b37c6._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 10"
+ date="2020-07-28T15:18:40Z"
+ content="""
+WOW -- a random discovery and possible note to myself:  I am getting all those libpcre misses when I run `git annex version` within a git repository and not otherwise:
+
+```
+$> strace -f git-annex version 2>&1 | awk '/libpcre.*so.*/{print}' | nl | tail -n 1
+     1	[pid 3702554] openat(AT_FDCWD, \"/lib/x86_64-linux-gnu/libpcre.so.3\", O_RDONLY|O_CLOEXEC) = 3
+
+$> mkdir repo; cd repo; git init
+Initialized empty Git repository in /tmp/repo/.git/
+
+$> strace -f git-annex version 2>&1 | awk '/libpcre.*so.*/{print}' | nl | tail -n 1
+    41	[pid 3702907] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = 3
+```
+
+Not sure why `git annex version` needs to run `git` when inside a git repo for its `version`. (same happens for `git annex --help`)
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_11_b3c5851c3603976d59927b591ba1d126._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_11_b3c5851c3603976d59927b591ba1d126._comment
new file mode 100644
index 0000000000..b4394c0c7a
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_11_b3c5851c3603976d59927b591ba1d126._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 11"
+ date="2020-07-28T15:26:41Z"
+ content="""
+that was with a bit dated (8.20200501+git61-g64e081d58-1~ndall+1) version, with 8.20200720.1-1~ndall+1 it looks a bit better:
+
+```
+$> strace -f git-annex version 2>&1 | awk '/libpcre.*so.*ENOENT/{print}' | wc -l
+39
+```
+
+but still a more pertinent test/demonstration of current situation would be
+
+```shell
+$> strace -f git-annex init 2>&1 | awk '/libpcre.*so.*ENOENT/{print}' | wc -l   
+651
+```
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_12_2363dac7701b9c36eb1896a09e68c17d._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_12_2363dac7701b9c36eb1896a09e68c17d._comment
new file mode 100644
index 0000000000..f7eafe1ec5
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_12_2363dac7701b9c36eb1896a09e68c17d._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2020-07-31T17:10:08Z"
+ content="""
+It is premature optimisation to try to reduce these seeks when they have
+not been shown to reduce performance, and at least in my tests, have been
+shown to not affect it to the limits I can measure.
+
+I don't think it would be safe to consolidate all the libs into one
+directory, as I did in my test. Because it seems possible that there could
+be two versions of a .so file with the same name, in eg lib64/tls
+and lib64/x86_64. Installing only one of them would either lose actual
+optimisations in the other .so file, or cause breakage. I don't know when
+those optimised .so files exist, but implementating this consolidation
+would make the build more fragile.
+
+I don't know if `prelink(8)` is able to prelink things such that they can
+be relocated, as git-annex.linux can. I think it hardcodes a fixed path in
+the binary. Similarly, ld.so.cache (which is why this seeking doesn't
+happen on Debian AFAICS, not preliking) contains a list of directories and
+the libraries in them, so unless it were created by runshell the first
+time, it would not work. And creating it by runshell the first time would
+make the thing more complicated, and thus more fragile. (Also
+/sbin/ldconfig is 1mb in size so would increase the bundle rather a lot.)
+Also, I benchmarked prelinking back in 
+[[!commit c4229be9a7a2318ef71b9ae433bc14bf604c9caf]] and the speedup was not
+measurable.
+
+So these are not appealing with the information I have. It's a very
+different situation than the ghc bug that was adding one directory
+to rpath for every haskell library, which had an easily measurable
+performance impact because there are hundreds of those libraries and 30000
+seeks did add up to a measurable time.
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_13_5d65192366f7690c22d1a209fb1e8f78._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_13_5d65192366f7690c22d1a209fb1e8f78._comment
new file mode 100644
index 0000000000..b9f24ce52f
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_13_5d65192366f7690c22d1a209fb1e8f78._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2020-07-31T17:41:55Z"
+ content="""
+`git-annex init` runs git something like 30 times, so it's close to the worst
+case for a single git-annex command, other than when smudge filters are run.
+
+I tried inlining runshell into both git and git-annex scripts, thinking
+that the overhead of starting the second shell script might be measurable.
+It was not; I saw `git-annex init` taking 0.10-0.14s before and after.
+
+I also tried trimming out some parts of the script that normally
+don't run, like the android support, but that didn't speed it up.
+
+With the consolidated lib dirs, I did see `git-annex init` drop to 0.07-0.10s.
+
+Ok, I found a way to consolidate the directories that will not include
+directories for optimised libs. Implemented that.
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_14_16aae09d0e1d80240fc3ae81e5b06972._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_14_16aae09d0e1d80240fc3ae81e5b06972._comment
new file mode 100644
index 0000000000..2d0f855a95
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_14_16aae09d0e1d80240fc3ae81e5b06972._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2020-07-31T20:25:01Z"
+ content="""
+Setting `LD_HWCAP_MASK=0` prevents the linker from looking for hardware
+optimised libraries. I compared with and without it, and there was a
+savings of 280 failed seeks across `git-annex init`.
+
+In particular ones with a double `x86_64` like this one:
+
+	git-annex.linux//lib/x86_64-linux-gnu/tls/x86_64/x86_64/libm.so.6
+
+While it still does ones like this, which I would have thought would also
+be disabled:
+
+	git-annex.linux//lib/x86_64-linux-gnu/tls/x86_64/libm.so.6
+
+And, it eliminates looking for libpcre twice in the same place
+(git-annex.linux//lib/x86_64-linux-gnu/tls/x86_64/libpcre2-8.so.0)
+that it otherwise does while linking git.
+
+This is some weird behavior from the linker. I get the impression
+that it's looking in `x86_64` for two different reasons, hwcap and
+something else. And tls is not being filtered either.
+Found this message that I think explains why:
+<https://sourceware.org/pipermail/libc-alpha/2020-May/113878.html>
+
+> Two fake hwcap bits and corresponding subdirectory are added by the loader: the TLS
+> bit with the directory name "tls", and the platform bit, with the
+> AT_PLATFROM string provided by the kernel as the directory name.
+
+So, the kernel provides hwcaps, which we can filter, but then these
+fake ones are added on top of it.
+
+It seems likely that's a bug... What if I actually had a good
+reason to want to mask out those libraries from being used, and the linker
+used them anyway?
+
+Anyway, that reduces the runtime to 0.08-0.09s from 0.10-0.11s.
+
+Enabling this would need some way to detect that there are no hwcap
+optimised libs being included in the bundle, otherwise it would probably
+be a pessimisation. 
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_15_013afa9d45970397bfcd60e57a519d67._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_15_013afa9d45970397bfcd60e57a519d67._comment
new file mode 100644
index 0000000000..fab2af08a9
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_15_013afa9d45970397bfcd60e57a519d67._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 15"
+ date="2020-07-31T21:23:55Z"
+ content="""
+Just a brief one:
+
+> It is premature optimisation to try to reduce these seeks when they have not been shown to reduce performance ...
+
+Have a look at the original issue description.  They introduced 1.3ms to seek a single library... We saved about 30% of runtime switching Travis CI from standalone to conda build of annex. So performance reduction is obvious IMHO.
+
+>  Implemented that.
+
+Awesome!  I have restarted [gh workflows job](https://github.com/datalad/datalad-extensions/pull/25/checks?check_run_id=919624426) which runs perspectively [added test](https://github.com/datalad/datalad-extensions/pull/25/files#diff-8364c688b76bfaf5df947cfd4d74eef7R111) running `annex init` and counting missing seeks for libpcre (was over 90)... unfortunately regular `git annex test` failed before it tried added \"custom\" ones (I should isolate them I guess), so dunno what is the status on that github action.  
+FTR: testing of git annex started to show some failures 2 days ago : https://github.com/datalad/datalad-extensions/actions/runs/187943962 (although only in crippled fs runs, although might be just the sign of lakiness)  so not necessarily a fresh one.  yet to download a fresh built package and see what it brings locally
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_16_c43788c8730619c3590d1a0a2bb87148._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_16_c43788c8730619c3590d1a0a2bb87148._comment
new file mode 100644
index 0000000000..bcb2af0e78
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_16_c43788c8730619c3590d1a0a2bb87148._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 16"
+ date="2020-07-31T21:30:31Z"
+ content="""
+> FTR: testing of git annex started to show some failures 2 days ago
+
+Already reported [here] and fixed by Joey with 5a5873e05 (fix bug
+caught by test suite, 2020-07-31).
+
+[here]: https://git-annex.branchable.com/bugs/prop__95__isomorphic__95__key__95__encode_fails_with_external_backend_changes/
+
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_17_77a2f7d18cbcf780d8e2bb4a3e40b4fa._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_17_77a2f7d18cbcf780d8e2bb4a3e40b4fa._comment
new file mode 100644
index 0000000000..25ce4863f8
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_17_77a2f7d18cbcf780d8e2bb4a3e40b4fa._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 17"
+ date="2020-07-31T21:37:45Z"
+ content="""
+> ... that there are no hwcap optimised libs being included in the bundle, otherwise it would probably be a pessimisation.
+
+Kyle, get ready for me to use a new word I just have learned! ;)
+
+as for \"... included in the bundle\".  For neurodebian git-annex-standalone ideally any check of such kinda should be done at package build time since it is when it could check just once and avoid any checks later when installed.
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_18_7650d349ba50972b64cd6d81673bf1c9._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_18_7650d349ba50972b64cd6d81673bf1c9._comment
new file mode 100644
index 0000000000..0551aac62f
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_18_7650d349ba50972b64cd6d81673bf1c9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 18"
+ date="2020-07-31T21:48:19Z"
+ content="""
+FWIW, [it did drop from 90 to 15!](https://github.com/datalad/datalad-extensions/pull/25/checks?check_run_id=933718043#step:4:1) so there is progress ;-)
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_19_13b21a0523b8837f4e27bb78e35ad5e0._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_19_13b21a0523b8837f4e27bb78e35ad5e0._comment
new file mode 100644
index 0000000000..a22e029140
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_19_13b21a0523b8837f4e27bb78e35ad5e0._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2020-08-03T18:16:50Z"
+ content="""
+Implemented the `LD_HWCAP_MASK=0` optimisation, which left only these:
+
+	strace -f ./git-annex version 2>&1 | grep ENOENT | grep openat
+	openat(AT_FDCWD, "/home/joey/src/git-annex/tmp/git-annex.linux//lib/x86_64-linux-gnu/tls/x86_64/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	openat(AT_FDCWD, "/home/joey/src/git-annex/tmp/git-annex.linux//lib/x86_64-linux-gnu/tls/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	openat(AT_FDCWD, "/home/joey/src/git-annex/tmp/git-annex.linux//lib/x86_64-linux-gnu/x86_64/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	[pid 697752] openat(AT_FDCWD, "/home/joey/src/git-annex/tmp/git-annex.linux//lib/x86_64-linux-gnu/tls/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	[pid 697752] openat(AT_FDCWD, "/home/joey/src/git-annex/tmp/git-annex.linux//lib/x86_64-linux-gnu/tls/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	[pid 697752] openat(AT_FDCWD, "/home/joey/src/git-annex/tmp/git-annex.linux//lib/x86_64-linux-gnu/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+
+There are more failed opens now for locale files for commands like
+grep when running it than there are for libraries. So, no need to
+consider further prelinking.
+
+I think that rewriting runshell in C would be the
+logical next choice, but dunno if it would speed it up by enough to be 
+worth the effort. So I'm going to close this now.
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_1_c67d403cb5bb67c3486ff9ade9607b2f._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_1_c67d403cb5bb67c3486ff9ade9607b2f._comment
new file mode 100644
index 0000000000..89be386df6
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_1_c67d403cb5bb67c3486ff9ade9607b2f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2020-07-18T03:57:20Z"
+ content="""
+a test could be I guess as simple as
+
+```
+[ `strace -f git annex version 2>&1 1>/dev/null | grep open.*libpcre.*ENOENT | wc -l` -lt 2 ]
+```
+or some other number than the ideal `2` (i.e. a direct hit right away ;)) but something less than current 47
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_2_c67fe4be932b8e7e365ed336e612b526._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_2_c67fe4be932b8e7e365ed336e612b526._comment
new file mode 100644
index 0000000000..f04472d8f5
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_2_c67fe4be932b8e7e365ed336e612b526._comment
@@ -0,0 +1,72 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-07-18T04:34:05Z"
+ content="""
+
+<details>
+<summary>also for some reason paths like `ld.so.conf.d` are consulted</summary> 
+
+```shell
+$> strace -f git annex version 2>&1 1>/dev/null | grep ld.so    
+access(\"/etc/ld.so.preload\", R_OK)      = -1 ENOENT (No such file or directory)
+openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5629] access(\"/etc/ld.so.preload\", R_OK <unfinished ...>
+[pid  5629] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5631] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5631] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5632] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5632] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5629] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5636] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5636] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5637] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5637] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5641] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5641] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5642] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5642] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5643] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5643] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5629] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5629] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell/x86_64/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell/x86_64\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/x86_64/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/x86_64\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell/x86_64/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell/x86_64\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/x86_64/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/x86_64\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d\", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libsqlite3.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libpthread.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libmagic.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libxml2.so.2\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libz.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+....
+```
+</details>
+
+I thought that somehow may be ld.so.conf could indeed be used to actually configure paths for libraries to index at debian package installation level... 
+
+interestingly, if I do directly what you are doing in the ld.so symlink shim, I get a \"direct hit\":
+
+```
+$> ( GIT_ANNEX_PROGRAMPATH=/usr/lib/git-annex.linux/bin/git-annex strace -f /usr/lib/git-annex.linux/exe/git-annex --library-path /usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/usr/lib/git-annex.linux//etc/ld.so.conf.d:/usr/lib/git-annex.linux//lib64:/usr/lib/git-annex.linux//lib/x86_64-linux-gnu:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git-annex/git-annex version 2>&1 ; ) | grep pcre
+[pid  8539] openat(AT_FDCWD, \"/usr/lib/git-annex.linux/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC <unfinished ...>
+
+```
+but something I guess throws it off in the \"top level\" runshell (sorry -- dunno a better word) since I do observe all those numerous attempts stracing the `/usr/lib/git-annex.linux/git-annex`
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_3_6ae9e999b6af6b6bfe078dd187f7ff22._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_3_6ae9e999b6af6b6bfe078dd187f7ff22._comment
new file mode 100644
index 0000000000..ea25cff3f8
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_3_6ae9e999b6af6b6bfe078dd187f7ff22._comment
@@ -0,0 +1,72 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2020-07-18T04:34:26Z"
+ content="""
+
+<details>
+<summary>also for some reason paths like `ld.so.conf.d` are consulted</summary> 
+
+```shell
+$> strace -f git annex version 2>&1 1>/dev/null | grep ld.so    
+access(\"/etc/ld.so.preload\", R_OK)      = -1 ENOENT (No such file or directory)
+openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5629] access(\"/etc/ld.so.preload\", R_OK <unfinished ...>
+[pid  5629] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5631] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5631] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5632] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5632] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5629] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5636] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5636] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5637] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5637] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5641] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5641] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5642] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5642] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5643] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5643] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5629] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/etc/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3
+[pid  5629] access(\"/etc/ld.so.preload\", R_OK) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell/x86_64/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell/x86_64\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/x86_64/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/x86_64\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell/x86_64/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell/x86_64\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/x86_64/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d/x86_64\", 0x7ffd99c76b60) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libm.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] stat(\"/usr/lib/git-annex.linux//etc/ld.so.conf.d\", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libsqlite3.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libpthread.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libmagic.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libxml2.so.2\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libz.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  5629] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+....
+```
+</details>
+
+I thought that somehow may be ld.so.conf could indeed be used to actually configure paths for libraries to index at debian package installation level... 
+
+interestingly, if I do directly what you are doing in the ld.so symlink shim, I get a \"direct hit\":
+
+```
+$> ( GIT_ANNEX_PROGRAMPATH=/usr/lib/git-annex.linux/bin/git-annex strace -f /usr/lib/git-annex.linux/exe/git-annex --library-path /usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/usr/lib/git-annex.linux//etc/ld.so.conf.d:/usr/lib/git-annex.linux//lib64:/usr/lib/git-annex.linux//lib/x86_64-linux-gnu:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu: /usr/lib/git-annex.linux/shimmed/git-annex/git-annex version 2>&1 ; ) | grep pcre
+[pid  8539] openat(AT_FDCWD, \"/usr/lib/git-annex.linux/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC <unfinished ...>
+
+```
+but something I guess throws it off in the \"top level\" runshell (sorry -- dunno a better word) since I do observe all those numerous attempts stracing the `/usr/lib/git-annex.linux/git-annex`
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_4_bfb9b94048fc239f29351a9d38c8d4e3._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_4_bfb9b94048fc239f29351a9d38c8d4e3._comment
new file mode 100644
index 0000000000..fa4bc12558
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_4_bfb9b94048fc239f29351a9d38c8d4e3._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2020-07-18T04:49:49Z"
+ content="""
+and since debian standalone is a \"static\" installation, most likely all the dance in `runshell` could be avoided upon every invocation and paths could be computed/recorded at installation time and then shim could be as lean as what I get with
+
+```shell
+$> rm -rf /tmp/fastannex; mkdir /tmp/fastannex; for f in /usr/lib/git-annex.linux/bin/git-annex{,-shell}; do echo -e \"#\!/bin/sh\nGIT_ANNEX_DIR=/usr/lib/git-annex.linux/ GIT_ANNEX_LD_LIBRARY_PATH=/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/usr/lib/git-annex.linux//etc/ld.so.conf.d:/usr/lib/git-annex.linux//lib64:/usr/lib/git-annex.linux//lib/x86_64-linux-gnu:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu: $f \\"\$@\\"\" > /tmp/fastannex/$(basename $f); done; chmod a+x /tmp/fastannex/*
+```
+
+and speed up on a random sample test is already obvious:
+
+
+```
+$> time PATH=/tmp/fastannex:$PATH python -m nose datalad/support/tests/test_annexrepo.py:test_annex_version_handling_bad_git_annex
+.
+----------------------------------------------------------------------
+Ran 1 test in 0.280s
+
+OK
+PATH=/tmp/fastannex:$PATH python -m nose   0.78s user 0.25s system 100% cpu 1.029 total
+```
+
+vs
+
+```
+$> time python -m nose datalad/support/tests/test_annexrepo.py:test_annex_version_handling_bad_git_annex      
+.
+----------------------------------------------------------------------
+Ran 1 test in 0.498s
+
+OK
+python -m nose   0.98s user 0.29s system 101% cpu 1.254 total
+```
+
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_5_7a57b6713788778f6a6e8144cf3931b2._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_5_7a57b6713788778f6a6e8144cf3931b2._comment
new file mode 100644
index 0000000000..b57fcab42d
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_5_7a57b6713788778f6a6e8144cf3931b2._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2020-07-18T04:50:12Z"
+ content="""
+and since debian standalone is a \"static\" installation, most likely all the dance in `runshell` could be avoided upon every invocation and paths could be computed/recorded at installation time and then shim could be as lean as what I get with
+
+```shell
+$> rm -rf /tmp/fastannex; mkdir /tmp/fastannex; for f in /usr/lib/git-annex.linux/bin/git-annex{,-shell}; do echo -e \"#\!/bin/sh\nGIT_ANNEX_DIR=/usr/lib/git-annex.linux/ GIT_ANNEX_LD_LIBRARY_PATH=/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit:/usr/lib/git-annex.linux//etc/ld.so.conf.d:/usr/lib/git-annex.linux//lib64:/usr/lib/git-annex.linux//lib/x86_64-linux-gnu:/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu: $f \\"\$@\\"\" > /tmp/fastannex/$(basename $f); done; chmod a+x /tmp/fastannex/*
+```
+
+and speed up on a random sample test is already obvious:
+
+
+```
+$> time PATH=/tmp/fastannex:$PATH python -m nose datalad/support/tests/test_annexrepo.py:test_annex_version_handling_bad_git_annex
+.
+----------------------------------------------------------------------
+Ran 1 test in 0.280s
+
+OK
+PATH=/tmp/fastannex:$PATH python -m nose   0.78s user 0.25s system 100% cpu 1.029 total
+```
+
+vs
+
+```
+$> time python -m nose datalad/support/tests/test_annexrepo.py:test_annex_version_handling_bad_git_annex      
+.
+----------------------------------------------------------------------
+Ran 1 test in 0.498s
+
+OK
+python -m nose   0.98s user 0.29s system 101% cpu 1.254 total
+```
+
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_6_3a849428b335964f80a8503d44d51c5a._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_6_3a849428b335964f80a8503d44d51c5a._comment
new file mode 100644
index 0000000000..0542a19a4f
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_6_3a849428b335964f80a8503d44d51c5a._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2020-07-18T05:09:32Z"
+ content="""
+<details>
+<summary>bundled git is also a victim on many counts (bringing locale question back as well)</summary> 
+
+```shell
+$> strace -f /usr/lib/git-annex.linux/git --version 2>&1 | grep open.*ENOE | nl | tail
+   155	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   156	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   157	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   158	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   159	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   160	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   161	openat(AT_FDCWD, \"/usr/lib/locale/locale-archive\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   162	openat(AT_FDCWD, \"/usr/lib/locale/en_US.UTF-8/LC_MESSAGES\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   163	openat(AT_FDCWD, \"/usr/lib/locale/en_US.UTF-8/LC_TIME\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   164	openat(AT_FDCWD, \"/usr/lib/locale/en_US.UTF-8/LC_CTYPE\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+1 47553.....................................:Sat 18 Jul 2020 01:07:51 AM EDT:.
+(git)lena:~datalad/datalad-maint[maint]git
+$> strace -f /usr/lib/git-annex.linux/git --version 2>&1 | grep open.*ENOE | grep -v locale | nl | tail
+    54	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libpthread.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    55	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/libpthread.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    56	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    57	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    58	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    59	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    60	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    61	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    62	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    63	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+
+```
+</details>
+
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_7_5f5d9af7ed807b8ef203426f717822b2._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_7_5f5d9af7ed807b8ef203426f717822b2._comment
new file mode 100644
index 0000000000..78e5a70663
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_7_5f5d9af7ed807b8ef203426f717822b2._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2020-07-18T05:09:54Z"
+ content="""
+<details>
+<summary>bundled git is also a victim on many counts (bringing locale question back as well)</summary> 
+
+```shell
+$> strace -f /usr/lib/git-annex.linux/git --version 2>&1 | grep open.*ENOE | nl | tail
+   155	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   156	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   157	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   158	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   159	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   160	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   161	openat(AT_FDCWD, \"/usr/lib/locale/locale-archive\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   162	openat(AT_FDCWD, \"/usr/lib/locale/en_US.UTF-8/LC_MESSAGES\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   163	openat(AT_FDCWD, \"/usr/lib/locale/en_US.UTF-8/LC_TIME\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+   164	openat(AT_FDCWD, \"/usr/lib/locale/en_US.UTF-8/LC_CTYPE\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+1 47553.....................................:Sat 18 Jul 2020 01:07:51 AM EDT:.
+(git)lena:~datalad/datalad-maint[maint]git
+$> strace -f /usr/lib/git-annex.linux/git --version 2>&1 | grep open.*ENOE | grep -v locale | nl | tail
+    54	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libpthread.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    55	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/libpthread.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    56	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    57	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    58	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    59	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/librt.so.1\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    60	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    61	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    62	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    63	openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/libc.so.6\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+
+```
+</details>
+
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_8_b45863d81e3790ea44714a18c1721abd._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_8_b45863d81e3790ea44714a18c1721abd._comment
new file mode 100644
index 0000000000..013d634029
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_8_b45863d81e3790ea44714a18c1721abd._comment
@@ -0,0 +1,72 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2020-07-27T15:44:39Z"
+ content="""
+For details of the older todo, including some timings with and without
+prelinking, see [[!commit c4229be9a7a2318ef71b9ae433bc14bf604c9caf]].
+
+A ghc bug, since fixed, was causing it to look in IIRC, thousands of
+unnecessary directories per library. This todo, by contrast, complains about
+less than 100 extra lookups total.
+
+The way you run the shim does not put the bundled git in PATH. That kind of
+throws off your results, because git, not git-annex is what links to pcre.
+I was not actually able to reproduce your result of it finding pcre without
+any failed seeks, but perhaps it ran a different git binary than the ones I
+have access to. Anyway, that all seems like a bit of a red herring due to
+that problem and puts your timings in doubt too.
+
+Simply moving all the libraries to a single directory would cut down on the
+failed seeking a lot:
+
+	strace -f ./git-annex version 2>&1 | grep ENOENT | grep openat
+	openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/tls/x86_64/x86_64/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/tls/x86_64/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/tls/x86_64/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/tls/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/x86_64/x86_64/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/x86_64/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/x86_64/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	[pid 481279] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/tls/x86_64/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	[pid 481279] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/tls/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	[pid 481279] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/tls/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	[pid 481279] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/tls/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	[pid 481279] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/x86_64/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	[pid 481279] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+	[pid 481279] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib64/x86_64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+
+The /lib64/tls/x86_64/x86_64/ seems like kind of weird behavior from
+ld-linux.so, I wonder if that's a bug on its part. The rest of the seeking
+seems reasonable. I guess these extra 14 seeks are not a major performance hit.
+
+But, that library consolidation does not seem to speed it up appreciably at
+all. Timings were almost identical before and after. 100 failed opens, when
+cache is hot, is just not that much overhead compared with the script's
+overhead. I don't think it's even worth implementing the library
+consolidiation based on this.
+
+Running `git-annex.linux/git-annex version`
+takes 0.060s. Compare with around 0.030s to run `/usr/bin/git-annex version`.
+(Sometimes it runs in more like 0.020s, but not often.. Probably have to
+catch the cache in the right mood.) 
+So, runshell and the other 2 shell scripts have around
+0.030s overhead themsevles.
+
+(This is with runshell modified so `GIT_ANNEX_PACKAGE_INSTALL` is set.
+IIRC the way the git-annex-standalone deb is built sets that. Otherwise,
+runshell does an additional 0.060s of locale setup stuff.)
+
+I tried putting set -x in all 3 levels of shell scripts and time stamping
+the output to see what was expensive. This was a bit surprising,
+because other than the abovementioned locale setup stuff, all the rest
+of the set -x output happened within 0.000965s. Which is 30 times faster
+than the timings above say it should be. Could be that the time stamping,
+which used `ts`, is not accurate enough.
+
+Anyway, runshell uses several unix utilities (and at least dirname is run
+redundantly between the git-annex script and runshell), 
+and there are 3 levels of shell scripts for the shell to parse and run.
+Combining them into a single shell script would eliminate some redundant work.
+Probably rewriting in C would be a bigger win.
+"""]]
diff --git a/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_9_ce5fb75f944816b134fd2dc7a389b913._comment b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_9_ce5fb75f944816b134fd2dc7a389b913._comment
new file mode 100644
index 0000000000..6e326dad16
--- /dev/null
+++ b/doc/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/comment_9_ce5fb75f944816b134fd2dc7a389b913._comment
@@ -0,0 +1,180 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 9"
+ date="2020-07-27T21:40:53Z"
+ content="""
+quick comment:
+
+>  The rest of the seeking seems reasonable.
+
+note that some directories seems to be considered twice, e.g.
+
+```
+[pid 481279] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid 481279] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+```
+
+and
+
+```
+[pid 481279] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid 481279] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+```
+
+I guess some paths get listed multiple times.
+
+> I guess these extra 14 seeks are not a major performance hit. ... 2 shell scripts have around 0.030s overhead themsevles
+
+sure not major but still wasteful if could be avoided.   
+
+> The way you run the shim does not put the bundled git in PATH. That kind of throws off your results, because git, not git-annex is what links to pcre.
+
+I do not think I did anything special, and here is my reproduced full example:
+
+<details>
+<summary>installing bleeding edge build (8.20200720.1+git52-gf5e65d680-1~ndall+1) from datalad-extensions</summary> 
+
+```shell
+(git)lena:~datalad/datalad[maint]
+$> tools/ci/install-annex.sh datalad-extensions-build
+I: top directory /home/yoh/.tmp/ga-4b1Aue7
+Using curl as \"curl --silent\"
+Getting artifacts_url from https://api.github.com/repos/datalad/datalad-extensions/actions/workflows/build-git-annex-debianstandalone.yaml/runs?status=success&branch=master into '/home/yoh/.tmp/tmp.n7XrEmCr3L'
+Getting archive download url from https://api.github.com/repos/datalad/datalad-extensions/actions/runs/183638203/artifacts
+Getting download url from https://api.github.com/repos/datalad/datalad-extensions/actions/artifacts/12229676/zip
+Downloading artifact package from https://pipelines.actions.githubusercontent.com/2UPlDxaVvvbkeFX4btxWorCjpJvj40zvWY5ogH2yZibhOMcU7O/_apis/pipelines/1/runs/1100/signedartifactscontent?artifactName=git-annex-debianstandalone-packages&urlExpires=2020-07-27T21%3A31%3A09.8843916Z&urlSigningMethod=HMACV1&urlSignature=K83aXlzZZoZcxFrz2diweljTVcdOsNv101ISfiNMcwk%3D
+Archive:  .artifact.zip
+  inflating: git-annex-build.log     
+  inflating: git-annex-standalone_8.20200720.1+git52-gf5e65d680-1~ndall+1_amd64.deb  
+  inflating: git-annex_8.20200720.1+git52-gf5e65d680-1~ndall+1.dsc  
+  inflating: git-annex_8.20200720.1+git52-gf5e65d680-1~ndall+1.tar.gz  
+  inflating: git-annex_8.20200720.1+git52-gf5e65d680-1~ndall+1_amd64.buildinfo  
+  inflating: git-annex_8.20200720.1+git52-gf5e65d680-1~ndall+1_amd64.changes  
+  inflating: git-annex_8.20200720.1+git52-gf5e65d680-1~ndall+1_source.buildinfo  
+  inflating: git-annex_8.20200720.1+git52-gf5e65d680-1~ndall+1_source.changes  
+[sudo] password for yoh: 
+(Reading database ... 760196 files and directories currently installed.)
+Preparing to unpack .../git-annex-standalone_8.20200720.1+git52-gf5e65d680-1~ndall+1_amd64.deb ...
+Unpacking git-annex-standalone (8.20200720.1+git52-gf5e65d680-1~ndall+1) over (8.20200617+git192-g5849bd634-1~ndall+1) ...
+Setting up git-annex-standalone (8.20200720.1+git52-gf5e65d680-1~ndall+1) ...
+Processing triggers for gnome-menus (3.36.0-1) ...
+Processing triggers for desktop-file-utils (0.24-1) ...
+Processing triggers for mime-support (3.64) ...
+Processing triggers for hicolor-icon-theme (0.17-2) ...
+Processing triggers for man-db (2.9.1-1) ...
+I: git-annex is available under '/usr/bin'
+
+$> grep GIT_ANNEX_PACK /usr/lib/git-annex.linux/runshell
+GIT_ANNEX_PACKAGE_INSTALL=1
+
+```
+</details>
+
+and it does not matter how I invoke (via outside git or directly through git-annex bundle)
+
+<details>
+<summary>I get those 46 failed lookups</summary> 
+
+```shell
+$> strace -f git annex version  2>&1 | grep 'libpcre2-8.*ENOENT' | nl
+     1	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/tls/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     2	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     3	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     4	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     5	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     6	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     7	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     8	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     9	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/tls/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    10	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    11	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    12	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    13	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    14	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    15	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    16	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    17	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    18	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    19	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    20	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    21	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    22	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    23	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    24	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    25	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/tls/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    26	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    27	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    28	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    29	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    30	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    31	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    32	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    33	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    34	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    35	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    36	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    37	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    38	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    39	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    40	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/tls/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    41	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    42	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    43	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    44	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    45	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    46	[pid 3664792] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+
+$> strace -f /usr/lib/git-annex.linux/git-annex version 2>&1 | grep 'libpcre2-8.*ENOENT' | nl 
+     1	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/tls/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     2	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     3	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     4	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     5	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     6	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     7	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     8	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+     9	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/tls/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    10	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    11	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    12	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    13	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    14	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    15	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    16	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/audit/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    17	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    18	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    19	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    20	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    21	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    22	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    23	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    24	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//etc/ld.so.conf.d/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    25	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/tls/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    26	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    27	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    28	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    29	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    30	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    31	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    32	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    33	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    34	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    35	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    36	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    37	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    38	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    39	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    40	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    41	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/tls/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    42	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    43	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    44	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/haswell/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    45	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+    46	[pid 3665083] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//usr/lib/x86_64-linux-gnu/x86_64/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+
+```
+</details>
+
+
+"""]]
diff --git a/doc/todo/metadata_--batch.mdwn b/doc/todo/metadata_--batch.mdwn
new file mode 100644
index 0000000000..e30f82340a
--- /dev/null
+++ b/doc/todo/metadata_--batch.mdwn
@@ -0,0 +1,4 @@
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] (using json input) --[[Joey]]
diff --git a/doc/todo/migration_to_VURL_by_default.mdwn b/doc/todo/migration_to_VURL_by_default.mdwn
new file mode 100644
index 0000000000..7d1c4b4385
--- /dev/null
+++ b/doc/todo/migration_to_VURL_by_default.mdwn
@@ -0,0 +1,29 @@
+`git-annex addurl --fast/--relaxed --verifiable` now uses VURL keys,
+which is an improvement over the old, un-verifiable URL keys. But users
+have to know to use it, and can have URL keys in their repository.
+
+Note that old git-annex, when in a repo with VURL keys, is still able to
+operate on them fine, even though it doesn't know what they are.
+Only fsck warns about them. So --verifiable could become the default
+reasonably soon. It's not necessary to wait for everyone to have the new
+version of git-annex.
+
+It might be good to nudge users to migrate their existing files to VURL
+eventually. Could be a fsck warning about URL keys, at some point after
+--verifiable becomes the default for addurl. Or could be a warning when
+transferring the content between repositories that it's not possible to
+verify it.
+
+Of course if users want to continue to use their existing URL keys and 
+not be able to verify content, that's fine. Users can also choose to use 
+WORM keys if they really want to. 
+
+However, I don't think there's enough reason to want to use URL keys to add
+configuration of which kind of keys addurl uses, once VURL is the default.
+--[[Joey]]
+
+> One way this might cause trouble is that current `git-annex registerurl`
+> and `unregisterurl` (and `fromkey`)  when passed an url rather than a key,
+> generates an URL key. If that is changed to generate a VURL key, then
+> it might break some workflow, particularly one where an url was
+> registered as an URL key and is now being unregistered.
diff --git a/doc/todo/more___34__filesystem_efficient__34___journalling__63___.mdwn b/doc/todo/more___34__filesystem_efficient__34___journalling__63___.mdwn
new file mode 100644
index 0000000000..e722945c56
--- /dev/null
+++ b/doc/todo/more___34__filesystem_efficient__34___journalling__63___.mdwn
@@ -0,0 +1,39 @@
+ATM the `.git/annex/journal` is a flat dump of files.  In our DANDI use case where we create git-annex repos possibly with hundred thousand entries (without content being downloaded) it seems that process(es) (we run a number in parallel) are quite slow.  Could be attributed to slow-ish filesystem not tuned for that purpose (will try resolving by moving to SDD, [issue in dandisets](https://github.com/dandi/dandisets/issues/222)), but also may be because `.git/annex/journal` accumulates those hundred thousands of files in a flat listing:
+
+```
+(base) dandi@drogon:/proc/1006503/cwd/.git$ ls -l /mnt/backup/dandi/partial-zarrs/c870fffc-0631-403c-884c-8e72e0ea0ff6/.git/annex/journal | nl | tail
+142544  -rw-r--r-- 1 dandi dandi      58 Jul 13 10:07 fff_b65_MD5E-s1508088--cb779895508c24d25eef3aafc846ba7c.log
+142545  -rw-r--r-- 1 dandi dandi     273 Jul 13 10:07 fff_b65_MD5E-s1508088--cb779895508c24d25eef3aafc846ba7c.log.web
+142546  -rw-r--r-- 1 dandi dandi      58 Jul 13 11:47 fff_b93_MD5E-s1581690--45d0e91e6641c1d0a27bcaf59e92cb5b.log
+142547  -rw-r--r-- 1 dandi dandi     273 Jul 13 11:47 fff_b93_MD5E-s1581690--45d0e91e6641c1d0a27bcaf59e92cb5b.log.web
+142548  -rw-r--r-- 1 dandi dandi      57 Jul 13 10:20 fff_bdf_MD5E-s869056--7d2874f3997f3625f37bee0ea01daaf0.log
+142549  -rw-r--r-- 1 dandi dandi     277 Jul 13 10:20 fff_bdf_MD5E-s869056--7d2874f3997f3625f37bee0ea01daaf0.log.web
+142550  -rw-r--r-- 1 dandi dandi      58 Jul 13 10:45 fff_c6e_MD5E-s2258--8758b6c839dd5f77e187a692093321f1.log
+142551  -rw-r--r-- 1 dandi dandi     273 Jul 13 10:45 fff_c6e_MD5E-s2258--8758b6c839dd5f77e187a692093321f1.log.web
+142552  -rw-r--r-- 1 dandi dandi      57 Jul 13 11:09 fff_d36_MD5E-s133521--d7856d85429f13faca9cbc26f0b391f4.log
+142553  -rw-r--r-- 1 dandi dandi     271 Jul 13 11:09 fff_d36_MD5E-s133521--d7856d85429f13faca9cbc26f0b391f4.log.web
+```
+
+so I wondered if may be there would be some benefit from making journal directory also (optionally is ok) be carry those leading directories, so that `fff_d36_MD5E-s133521--d7856d85429f13faca9cbc26f0b391f4.log.web` would become `fff/d36/MD5E-s133521--d7856d85429f13faca9cbc26f0b391f4.log.web` .  Not sure if would be of any benefit, might even be the opposite since would need even more inodes and then logic to clean up whenever any given file is removed.
+
+Or may be there could be some mode which "forces" journal to be processed whenever it reaches some specific size (e.g. 10k entries)?
+
+FWIW, here is a list of processes involved here:
+
+```shell
+(base) dandi@drogon:/proc/1006503/cwd/.git$ fuser -v /mnt/backup/dandi/partial-zarrs/c870fffc-0631-403c-884c-8e72e0ea0ff6/ 2>&1 | awk '/\.\.c/{print $2;}'   | while read p; do ps -p $p -u | grep -v USER; done
+dandi    2540282  0.2  0.0 1074052896 23268 pts/14 Sl+ 10:07   0:17 git-annex examinekey --batch --migrate-to-backend=MD5E
+dandi    2540289  0.4  0.0 1074053052 40428 pts/14 Sl+ 10:07   0:33 git-annex whereis --batch-keys --json --json-error-messages
+dandi    2540299  0.1  0.0  10640  4660 pts/14   S+   10:07   0:09 git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+dandi    2540300  0.7  0.0 1074053052 53652 pts/14 Sl+ 10:07   0:59 git-annex fromkey --force --batch --json --json-error-messages
+dandi    2540310  0.0  0.0  10640  4332 pts/14   S+   10:07   0:00 git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+dandi    2540313  0.2  0.0  10684  4296 pts/14   S+   10:07   0:19 git --git-dir=.git --work-tree=. --literal-pathspecs hash-object -w --stdin-paths --no-filters
+dandi    2540314 18.7  0.1 1074126764 76184 pts/14 Sl+ 10:07  23:35 git-annex registerurl --batch --json --json-error-messages
+dandi    2540322  0.3  0.0  10640  4336 pts/14   S+   10:07   0:30 git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch
+dandi    2540323  0.3  0.0   6888  3388 pts/14   S+   10:07   0:26 /bin/bash /usr/bin/git-annex-remote-rclone
+```
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> [[notabug|done]], as confirmed by yarikoptic --[[Joey]]
diff --git a/doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_1_5bbc2d651e4ce0ea5b20f199be5cb717._comment b/doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_1_5bbc2d651e4ce0ea5b20f199be5cb717._comment
new file mode 100644
index 0000000000..d59cdca6fd
--- /dev/null
+++ b/doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_1_5bbc2d651e4ce0ea5b20f199be5cb717._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-07-13T17:09:59Z"
+ content="""
+Is this the same machine that is 60x slower than my laptop at `git-annex
+init`?
+
+Is catting a single file from the journal measurably
+slower when the directory has so many files in it vs a small number?
+
+200k files in a directory does not produce a measurable slow down at reading a
+random file for me:
+
+	root@darkstar:/home/joey/tmp/d>ls -1 |wc -l
+	200000
+	root@darkstar:/home/joey/tmp/d>sync; echo 3 > /proc/sys/vm/drop_caches
+	root@darkstar:/home/joey/tmp/d>/usr/bin/time cat 99999
+	99999
+	0.00user 0.00system 0:00.00elapsed 66%CPU (0avgtext+0avgdata 1868maxresident)k
+
+At 2 million files, that cat is still running in 0s here. Writing to a new
+file and overwriting an existing file also are still very fast.
+
+It does take around 3 seconds to list the contents of the directory (37 seconds
+with 2 million files), but the only time git-annex does that is when it commits
+the journal, which is done only once per command.
+
+Committing the journal more frequently to keep the number of files down would
+mean more commits to the git-annex branch. Also committing has overhead, and
+probably more overhead than listing a directory with a lot of files in it has.
+
+What might be worth considering is periodically staging the journal to the
+annex index file without immediately committing it (still making one commit at
+the end). That seems like it would probably be safe to do, although I have not
+fully analized it. But I'm not convinced it would be an optmisation; it would
+mean repeatedly re-writing the index file, which gets expensive.
+"""]]
diff --git a/doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_2_5a29f3bc596b463b6710a6654b2e271e._comment b/doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_2_5a29f3bc596b463b6710a6654b2e271e._comment
new file mode 100644
index 0000000000..1a89d2db96
--- /dev/null
+++ b/doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_2_5a29f3bc596b463b6710a6654b2e271e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-07-13T19:04:40Z"
+ content="""
+> Is this the same machine that is 60x slower than my laptop at git-annex init?
+
+FWIW: most likely (IIRC I have reported from that machine - drogon, and another one - falkor  in the past few days with some timing results across different issues/etc).
+
+
+"""]]
diff --git a/doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_3_6486a0cf500f6ba3a9306cdc137f7b4d._comment b/doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_3_6486a0cf500f6ba3a9306cdc137f7b4d._comment
new file mode 100644
index 0000000000..28363e0870
--- /dev/null
+++ b/doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_3_6486a0cf500f6ba3a9306cdc137f7b4d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-07-13T21:26:38Z"
+ content="""
+I'll need to see some timings like the ones I gave, but a lot slower, to
+take this suggestion seriously..
+"""]]
diff --git a/doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_4_3d1a1ede9d1b5048723a542996121dd4._comment b/doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_4_3d1a1ede9d1b5048723a542996121dd4._comment
new file mode 100644
index 0000000000..d05c7e15d8
--- /dev/null
+++ b/doc/todo/more___34__filesystem_efficient__34___journalling__63___/comment_4_3d1a1ede9d1b5048723a542996121dd4._comment
@@ -0,0 +1,59 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2022-07-14T17:00:40Z"
+ content="""
+here are some timings although I think you are right that it should not be any major effect. most likely my slow system is due to [another issue with registerurl](https://git-annex.branchable.com/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/#comment-85131966a882ff24431566d146b5634b). But here are some timings showing that it is ok (23ms) to cat 1MB file, and list those 173k files in 17 seconds
+
+```
+root@drogon:/mnt/backup/dandi/partial-zarrs/db99e810-3bcf-434f-89cb-ae7476224607/.git/annex/journal# time cat 5a4_81f_MD5E-s560--82188063b1988362cc3050918f493320.log.web >/dev/null
+
+real    0m0.023s
+user    0m0.001s
+sys     0m0.001s
+root@drogon:/mnt/backup/dandi/partial-zarrs/db99e810-3bcf-434f-89cb-ae7476224607/.git/annex/journal# time cat 5a4_81f_MD5E-s560--82188063b1988362cc3050918f493320.log.web >/dev/null
+
+real    0m0.001s
+user    0m0.001s
+sys     0m0.000s
+root@drogon:/mnt/backup/dandi/partial-zarrs/db99e810-3bcf-434f-89cb-ae7476224607/.git/annex/journal# time /bin/ls -1 | wc -l
+173882
+
+real    0m17.103s
+user    0m0.535s
+sys     0m0.173s
+root@drogon:/mnt/backup/dandi/partial-zarrs/db99e810-3bcf-434f-89cb-ae7476224607/.git/annex/journal# time touch 1
+
+real    0m0.005s
+user    0m0.001s
+sys     0m0.000s
+root@drogon:/mnt/backup/dandi/partial-zarrs/db99e810-3bcf-434f-89cb-ae7476224607/.git/annex/journal# time bash -c 'echo 2 >> 1'
+
+real    0m0.132s
+user    0m0.017s
+sys     0m0.010s
+root@drogon:/mnt/backup/dandi/partial-zarrs/db99e810-3bcf-434f-89cb-ae7476224607/.git/annex/journal# time rm 1
+
+real    0m0.015s
+user    0m0.001s
+sys     0m0.000s
+
+# repeated ls
+root@drogon:/mnt/backup/dandi/partial-zarrs/db99e810-3bcf-434f-89cb-ae7476224607/.git/annex/journal# time /bin/ls -1 | wc -l
+177908
+
+real    0m0.789s
+user    0m0.577s
+sys     0m0.067s
+root@drogon:/mnt/backup/dandi/partial-zarrs/db99e810-3bcf-434f-89cb-ae7476224607/.git/annex/journal# time /bin/ls -1 | wc -l
+177978
+
+real    0m1.074s
+user    0m0.547s
+sys     0m0.077s
+
+```
+
+so if registerurl and others do not list that folder indeed until the point when journal is committed, should be all good
+"""]]
diff --git a/doc/todo/more_efficient_resolution_of_trivial_export_conflicts.mdwn b/doc/todo/more_efficient_resolution_of_trivial_export_conflicts.mdwn
new file mode 100644
index 0000000000..5a6fe0d1e0
--- /dev/null
+++ b/doc/todo/more_efficient_resolution_of_trivial_export_conflicts.mdwn
@@ -0,0 +1,20 @@
+Export conflicts happen whenever two repos export different trees 
+to the same special remote.
+
+Some conflicts that seem trivial currently involve unnecessary unexporting
+and re-uploading in their resolution.
+
+For example, if A exports a tree containing `[foo]`, and B exports a tree
+containing `[foo, bar]`, bar gets unexported when resolving the conflict.
+
+Bear in mind that A could have first exported a tree containing `[foo, bar]`
+then B exported a tree containing `[foo, bar]`, and then A exported
+`[foo]`, so unexported bar.
+
+So, if one exported tree is a subset of the other, it's not necessary to
+unexport files added by the other tree. It's sufficient to check that files
+are present in the export and upload any that are missing. --[[Joey]]
+
+[[!tag confirmed]]
+
+> I proved this is not a safe optimisation, so [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_1_5a2d7ea060f5e1be11c39521c0a5631d._comment b/doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_1_5a2d7ea060f5e1be11c39521c0a5631d._comment
new file mode 100644
index 0000000000..2db042e03c
--- /dev/null
+++ b/doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_1_5a2d7ea060f5e1be11c39521c0a5631d._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="thk"
+ avatar="http://cdn.libravatar.org/avatar/bfef10a428769701aeee1db978951461"
+ subject="sponsoring?"
+ date="2020-03-19T08:40:31Z"
+ content="""
+I am running into this problem right now. I exported a movie collection from laptop A and then a huge collection of photos from laptop B to an USB drive. Both exports ran many hours.
+Now when I want to export the next collection of files, I see:
+
+> git annex export master --to usb-sg2
+>
+>  Resolving export conflict..
+>
+> unexport usb-sg2 path/to/some/picture/file.jpg ok
+
+Do you already have a solution for this in mind? Could I speed up the implementation with sponsorship? This is a hard blocker now for me in my consolidation of our data with git-annex. I would rather not spend many nights to keep exporting and unexporting the same files over and over.
+
+Maybe I could hack this as a temporary workaround by manually changing the exported trees in the exports.log file? The \"conflicting\" exports are in two separate sub-trees.
+"""]]
diff --git a/doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_2_70c3cfa9b95f3aa6c2e2e2f6dbbc50d0._comment b/doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_2_70c3cfa9b95f3aa6c2e2e2f6dbbc50d0._comment
new file mode 100644
index 0000000000..6f8c923df9
--- /dev/null
+++ b/doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_2_70c3cfa9b95f3aa6c2e2e2f6dbbc50d0._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-05-04T17:30:59Z"
+ content="""
+I took a look at this, the relevant code is here:
+
+                        warning "Resolving export conflict.."
+                        forM_ ts $ \oldtreesha -> do
+                                -- Unexport both the srcsha and the dstsha,
+                                -- because the wrong content may have
+                                -- been renamed to the dstsha due to the
+                                -- export conflict.
+                                let unexportboth d =
+                                        [ Git.DiffTree.srcsha d
+                                        , Git.DiffTree.dstsha d
+                                        ]
+                                -- Don't rename to temp, because the
+                                -- content is unknown; delete instead.
+                                mapdiff
+                                        (\diff -> commandAction $ startUnexport r db (Git.DiffTree.file diff) (unexportboth diff))
+                                        oldtreesha new
+
+So, it diffs from the tree in the export conflict to the new, resolved tree.
+Any file that differs -- eg, any file that was involved in the conflict -- 
+gets removed from the export.
+
+> In the todo, I said:
+> 
+> For example, if A exports a tree containing `[foo]`, and B exports a tree
+> containing `[foo, bar]`, bar gets unexported when resolving the conflict.
+
+Let's be more clear about the content of the trees, and say A exports
+`[(foo, 1)]` and B exports `[(foo, 1), (bar, 1)]`.
+
+If the export is then resolved to `[(foo, 1), (bar, 1)]`,
+we can see nothing needs to be done. But what it currently does is
+diff from `[(foo, 1)]` to the resolution and so unexports bar.
+
+If B had instead exported `[(foo, 1), (bar, 2)]`, then
+it would still need to diff from that the the resolution, and so would
+unexport bar, and so it should.
+
+But.. but.. ugh. Consider an export conflict that started with `[(bar, 1)]`
+exported. A exported `[(bar, 2)]` and B exported `[(baz, 1)]` (by renaming bar
+to baz). So the export remote might contain `[(baz, 2)]` (A uploaded 2 to bar,
+and then B renamed bar to baz) or it might contain `[(bar, 2), (baz, 1)]`;
+we do not know ordering between A and B.
+
+If the export conflict resolution is `[(bar, 2), (baz 1)]` then the tree
+exported by B is a subset, so it skips that one. And the tree
+exported by A is a subset, so ummm... it skips that one. And so nothing gets
+unexported. Then, it proceeds to try to upload any missing files
+to the export. If the export remote contains `[(bar, 2), (baz, 1)]` nothing is
+missing, nothing gets uploaded, all is well. But if the export remote
+contains `[(baz, 2)]`, it will upload `(bar, 2)`, resulting in 
+`[(bar, 2), (baz 2)]`. That is not what it's supposed to contain.
+
+So, no, this optimisation will not work!
+
+The only way to make this optimisation work, I think, is to not do renaming
+when updating export remotes. But file renaming is more common than export
+conflicts; you can always adjust your workflow to avoid export conflicts,
+by pulling from the remote you tend to conflict with, before performing an
+export.
+"""]]
diff --git a/doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_3_d0549f8a07032ce61e88b4ccb2c6ef3b._comment b/doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_3_d0549f8a07032ce61e88b4ccb2c6ef3b._comment
new file mode 100644
index 0000000000..2b2b8314fc
--- /dev/null
+++ b/doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_3_d0549f8a07032ce61e88b4ccb2c6ef3b._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-05-04T18:36:30Z"
+ content="""
+Hmm, but.. What if both A and B's trees are subsets
+of the resolved tree? Safe then?
+
+A exports `[(foo, 1)]`, while B exports `[(bar, 2)]`
+the resolved tree is `[(foo, 1), (bar, 2)]`.
+
+Well, what was in the export before? Suppose it was `[(foo, 2)]`..
+Then B would have renamed foo to bar, and A exported 1 to foo.
+Order is unknown, so the export has either of `[(foo, 1), (bar, 2)]`
+or `[(bar, 1)]`
+
+Yeah, still not safe even when both trees are subsets.
+
+----
+
+An optimisation like this needs some way to detect if there's been a rename
+like B keeps doing in these examples. If there has not been any rename,
+the optimisation is safe.
+
+export.log contains only the sha of the tree that has been exported
+by each repo to the export remote. It might contains some trees that
+were exported before, but when it gets compacted, that information is
+lost, and anyway there's no way to know if B exported some old tree before
+or after A exported its most recently exported tree. So, I don't think
+retrospective rename detection is possible.
+"""]]
diff --git a/doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism.mdwn b/doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism.mdwn
new file mode 100644
index 0000000000..e2fa117913
--- /dev/null
+++ b/doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism.mdwn
@@ -0,0 +1,15 @@
+ATM git-annex heavily relies on credentials needed by special remote(s) (S3, WEBDAV) to be passed via environment variables. 
+
+- main shortcoming: those environment variables (e.g. AWS_ACCESS_KEY_ID) do not allow for different set of credentials to be provided to be used e.g. by multiple special remotes of the same `type` and would require multiple git-annex invocations to get through all of them
+- user experience:
+  - there is no UI to prompt user to enter needed/desired secrets.  That also relates to software relying on git-annex, such as datalad, as it somehow needs to know/discover that underlying call to `git-annex` apparently needs some credentials to be passed via env vars
+  - users then (typically)  need to hardcode values of those secrets verbatim in their scripts (instead of using some more secure credentials store)
+
+Given those (and possibly other) shortcomings, I thought it would have been great if git-annex supported some "credentials" storage/prompting/querying mechanism which would address main shortcoming and improve user experience. May be git-annex could use [git-credential](https://git-scm.com/docs/git-credential) mechanism. If not, then may be have some protocol created to allow for external git-annex-credential-* helpers?
+
+For reference, here is a PR in DataLad [https://github.com/datalad/datalad/pull/5796](https://github.com/datalad/datalad/pull/5796) to provide `git-credential-datalad` helper so `git` could query our (datalad) credentials store.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[[!tag moreinfo]]
diff --git a/doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism/comment_1_7078d380be9e78fea9fd5bec4ef9594b._comment b/doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism/comment_1_7078d380be9e78fea9fd5bec4ef9594b._comment
new file mode 100644
index 0000000000..1f16892f83
--- /dev/null
+++ b/doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism/comment_1_7078d380be9e78fea9fd5bec4ef9594b._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-12-08T16:48:15Z"
+ content="""
+But git-annex does allow for multiple special remotes of the same type
+that need different creds. At least for S3, when you run `git-annex
+initremote` it copies the env var values into a file, so you only need to
+have the env var set when running initremote, and all subsequent use of
+the remote will use the value it cached (unless you keep the env vars set,
+then it does use the env var).
+
+And there is a UI to prompt the user for the creds:
+
+	joey@darkstar:/tmp/foo>git annex initremote s3 type=S3  encryption=none
+	initremote s3 (checking bucket...)
+	  Set both AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to use S3
+	git-annex: No S3 credentials configured
+	failed
+
+Perhaps initremote of S3/glacier/webdav remotes could query git credential when
+the env vars are not set. Those are the only 3 built-in remotes that use the
+env var creds system actually.
+
+Fundamentally, what kind of authentication information a special remote needs
+depends on the service it's talking to, and there is a very large scope
+of possibilities, not only the simple username+password that git credential
+is designed for. Even S3 has a third possible credential that
+is sometimes needed and would not fit into git credential (`AWS_SESSION_TOKEN`).
+Other remotes such a borg don't even use git-annex to handle credentials,
+but run a program that prompts for whatever it needs, or rely on
+other stored data like ssh keys. A remote could just as well need a hardware
+token, or one time password, or biometric id, whatever. So git-annex
+has to leave authentication up to the remotes to prompt for in whatever
+way makes sense for them, aside from the simple username+password case.
+"""]]
diff --git a/doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism/comment_2_9e2c1d58f0d91dc55524d2e164b89b97._comment b/doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism/comment_2_9e2c1d58f0d91dc55524d2e164b89b97._comment
new file mode 100644
index 0000000000..d5f479a8b0
--- /dev/null
+++ b/doc/todo/more_flexible___40____34__external__34____63____41___credentials_mechanism/comment_2_9e2c1d58f0d91dc55524d2e164b89b97._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-01-11T16:19:09Z"
+ content="""
+> That also relates to software relying on git-annex, such as datalad, as it somehow needs to know/discover that underlying call to git-annex apparently needs some credentials to be passed via env vars
+
+Since `git-annex initremote` displays an error message when it needs
+creds, does datalad not forward that error message to the user?
+
+There seems to be a significant disconnect between what you're describing
+and what I've seen of and know of creds usage in git-annex. Gonna need more
+information.
+"""]]
diff --git a/doc/todo/moreinfo.mdwn b/doc/todo/moreinfo.mdwn
new file mode 100644
index 0000000000..47e9041ceb
--- /dev/null
+++ b/doc/todo/moreinfo.mdwn
@@ -0,0 +1,5 @@
+This tags is for todo items needing followup from their submitter to better
+explain why this should be on git-annex's todo list.
+
+Feel free to remove this tag from the todo item if you've responded to a
+question.
diff --git a/doc/todo/move_readonly_values_to_AnnexRead.mdwn b/doc/todo/move_readonly_values_to_AnnexRead.mdwn
new file mode 100644
index 0000000000..8aabd70b37
--- /dev/null
+++ b/doc/todo/move_readonly_values_to_AnnexRead.mdwn
@@ -0,0 +1,8 @@
+AnnexRead has recently been split out of AnnexState,
+and reading values from it is faster (no MVar). So,
+anything that never needs to be modified while git-annex is running can be
+moved to AnnexRead for a performance win and also to make clean how it's
+used. --[[Joey]]
+
+> [[done]]; all AnnexState fields have been checked and all that can be
+> made readonly are. --[[Joey]]
diff --git a/doc/todo/multiple_-m.mdwn b/doc/todo/multiple_-m.mdwn
new file mode 100644
index 0000000000..14cb9189e3
--- /dev/null
+++ b/doc/todo/multiple_-m.mdwn
@@ -0,0 +1,4 @@
+git-annex sync etc -m should be able to be specified multiple times. In git
+commit, multiple -m can be used to make a multiparagraph commit. --[[Joey]]
+
+> [[done]]
diff --git a/doc/todo/need_a_clear_criteria_for_adding_git-annex-config_settings.mdwn b/doc/todo/need_a_clear_criteria_for_adding_git-annex-config_settings.mdwn
new file mode 100644
index 0000000000..fdb4e968b6
--- /dev/null
+++ b/doc/todo/need_a_clear_criteria_for_adding_git-annex-config_settings.mdwn
@@ -0,0 +1,108 @@
+There are often requests to add various git-annex gitconfig settings 
+to git-annex-config. Probably, if every such request were implemented
+indesciminately, almost all settings would end up added to it. But adding
+settings to git-annex-config can be an imposition on users who don't want
+to have to override unusual settings. 
+
+git's own gitconfigs cannot be set by git-annex-config, and git users do
+not seem to be clamoring for ways to set gitconfigs across all clones of a
+repo. Instead, git users probably use a variety of ways to manage the same
+thing, all of which also work for git-annex configs too.
+
+So, git-annex-config, though it started out for good reasons, risks
+becoming a slippery slope toward an inconsistent mess. To avoid that,
+a clear criteria is needed for when it's appropriate to add a new setting
+to it.
+
+----
+
+It's worth considering gitattributes, since they also set somewhat
+repo-global configs. (Though less global since they can change in branch.)
+git-annex uses gitattributes some too, though less so.
+
+One good thing about gitattributes is that it applies the attribute to a
+set of files, and so it only makes sense for things that are related
+to individual files. So there is a gitattribute that controls how 3-way
+merging of a file happens, but not a gitattribute that controls whether
+git commits are gpg signed.
+
+git-annex-config does not have such a scope limiter currently.
+
+----
+
+The settings that git-annex-config supports are, in the order they were
+added:
+
+* annex.autocommit  
+  This was suggested because someone had a problem of cloning a repo
+  where annex.autocommit was usually set, but forgetting to set it,
+  resulting in an unwanted commit. This does not seem like a good
+  justification, couldn't someone run `git commit -a` accidentially
+  and have the same result?
+* annex.synccontent  
+  This was made a global because there is a hope for `git-annex sync
+  --content` to perhaps eventually because the default, and this lets
+  users get ahead of that. But that is not really a good justification
+  because if that behavior change did happen, there could be a transition
+  period where `git-annex sync` warned that its behavior was going to
+  change, which would give users an opportunity to choose the behavior
+  they want, and configure it locally.
+* annex.securehashesonly  
+  This is a global because a user who is relying on cryptographically
+  secure hashes for their security should not need to remember to set
+  the config in each new clone of the repo. Also, their collaborators
+  should not need to remember to set the config to avoid committing
+  things that do not use secure hashes, which would result in a mess
+  that would be painful to get out of. I do think this needs to be a
+  global.
+* annex.resolvemerge  
+  This is a global because, when git-annex's automatic merge conflict
+  resulution is not appropriate for a repository, it needs to be disabled
+  globally, since one can happen in any clone and would result in the wrong
+  thing being commited by git-annex.
+* annex.largefiles  
+  This is a global because it was already a (semi-)global in .gitattributes
+  files, but the syntax of those files made more complex expressions
+  hard to use in them. And so also putting the config here avoids that
+  problem and does not make it more global. This seems reasonable.
+* annex.addunlocked  
+  This would be suitable for a gitattribute, since it applies to an
+  individual file. But, like annex.largefiles, the syntax of .gitattributes
+  files makes more complex expressions a problem in them. So, it was added
+  to git-annex-config instead.
+* annex.dotfiles  
+  One reason this was made a global is probably that there was a large
+  amount of user complaint about git-annex add's handing of dotfiles,
+  with no one choice that would avoid it, but it did seem that each repo
+  probably had a choice that would satisfy the users of that repo.  
+  Besides being sick of navigating that maze of complaints, the only
+  other justification for it being a global seems to be that setting
+  annex.dotfiles works with annex.largfiles to control which particular
+  dotfiles to add to the annex (when users for some reason care),
+  and annex.largefiles is a global.
+* annex.synconlyannex  
+  I don't see a justification for this being global.
+
+At this point, we do seem to be a ways down a slippery slope. I started
+pushing back at adding them in 2020, and so no more have been added.
+--[[Joey]]
+
+---
+
+Looking at the settings that were added and why, here are some possible
+criteria that could be extracted from that:
+
+1. The config is for behavior that needs to happen in every clone of the
+   repository, to avoid situations where varying the config would lead
+   to difficult to resolve situations (annex.securehashesonly)  
+2. The config is something that would be suitable for .gitattributes,
+   but limitations of .gitattributes makes it convenient to have another way
+   to set it globally (when not actually targeting specific files).
+   (annex.largefiles, annex.addunlocked, annex.dotfiles)
+
+Things like annex.autocommit do not meet criteria #1, because it's
+easy to fix up a git commit history to remove an unwanted commit. 
+Does annex.resolvemerge meet criteria #1? --[[Joey]]
+
+[[!tag confirmed]]
+[[!tag projects/datalad/potential]]
diff --git a/doc/todo/need_a_clear_criteria_for_adding_git-annex-config_settings/comment_1_bcc5d69426fc6af6affdaf251dd9dd5d._comment b/doc/todo/need_a_clear_criteria_for_adding_git-annex-config_settings/comment_1_bcc5d69426fc6af6affdaf251dd9dd5d._comment
new file mode 100644
index 0000000000..7193d07f8c
--- /dev/null
+++ b/doc/todo/need_a_clear_criteria_for_adding_git-annex-config_settings/comment_1_bcc5d69426fc6af6affdaf251dd9dd5d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-04-04T17:59:39Z"
+ content="""
+See prior discussion in this old todo:
+<https://git-annex.branchable.com/todo/additional_git-annex-config_settings__63__/>
+"""]]
diff --git a/doc/todo/needsthought.mdwn b/doc/todo/needsthought.mdwn
new file mode 100644
index 0000000000..e6cb3313ea
--- /dev/null
+++ b/doc/todo/needsthought.mdwn
@@ -0,0 +1,3 @@
+This tag is for todo items that we have not had time to develop a plan to
+address. Someone needs to look at such a todo and think about it and
+suggest a way to move it forward.
diff --git a/doc/todo/network_test_suite.mdwn b/doc/todo/network_test_suite.mdwn
new file mode 100644
index 0000000000..5faffa75e7
--- /dev/null
+++ b/doc/todo/network_test_suite.mdwn
@@ -0,0 +1,34 @@
+`git annex test` is not allowed to make network connections. (It does do some
+mocking to eg, test ssh special remotes without actually using ssh.)
+
+`git annex testremote` is allowed to use the network, but only when the
+user has set up a remote to test. Some parts of git-annex involve network
+connections, but not as part of accessing a remote, or are specific to a
+particular special remote. There outght to be a test suite for that stuff
+as well.
+
+A motivating example is `git annex p2p --pair`, which was 
+[[broken for years due to lack of testing|apparent_regression_in_git_annex_p2p_--pair_usage_of_magic_wormhole_invocaction]]. 
+Fully testing that would involve setting up tor hidden services which is far
+too extreme for a test suite (and needs root), but it should at least be
+possible to test the interface to magic-wormhole, allowing it to make a
+connection to the wormhole server.
+
+More examples: 
+
+* git-annex multicast (would need two hosts on a lan ideally but
+  could at least try to multicast back to the same host)
+* git-annex addurl and git-annex importfeed with http urls.
+  And testing the various security configs that affect them.
+* The reversions where git-annex forgot to encrypt content stored
+  on gcrypt and git-lfs remotes could have been detected if there was a
+  test suite that tested them.
+
+This could be done as a new command or a flag to `git annex test`.
+In any case, the new test suite would need to be run somewhere;
+running it on at least some of the autobuilders might be a good way.
+
+--[[Joey]] 
+
+[[!tag confirmed]]
+[[!tag projects/datalad/potential]]
diff --git a/doc/todo/new_command_for_syncing_content_only.mdwn b/doc/todo/new_command_for_syncing_content_only.mdwn
new file mode 100644
index 0000000000..834a9808c7
--- /dev/null
+++ b/doc/todo/new_command_for_syncing_content_only.mdwn
@@ -0,0 +1,23 @@
+`git-annex sync` has been split into push/pull, but there is another split
+possible: `git-annex sync --no-commit --no-pull --no-push --content`.
+
+That is a mouthful, so maybe it could be a separate command? 
+
+> Actually, that used to sync content with older git-annex at least some
+> of the time, but [[!commit 2e984c51b65165e79c2fcd5212712ac4e73850de]]
+> changed/fixed --no-pull and --no-push to also prevent syncing content.
+> This new command would be the content-syncing part of sync only.
+
+Also, such a command could be perhaps be more like `git-annex get/drop/copy`
+in operating on the listed files or current directory and below by default.
+Although that might make it difficult for it to handle sending files to
+exporttree remotes, which sync does with `seekExportContent` which operates
+on the whole exported tree.
+
+What would be a good name for such a command?  --[[Joey]]
+
+> How about `git-annex port` as it carries content over like a luggage carrier aka. porter?
+> Another one that comes to mind is `git-annex shuttle` but that could be semantically too
+> similar to `git-annex assist`, perhaps. --[[jkniiv]]
+
+>> `git-annex satisfy` [[done]] --[[Joey]]
diff --git a/doc/todo/new_command_for_syncing_content_only/comment_1_7f983de645430d970c75f25fee27b2ed._comment b/doc/todo/new_command_for_syncing_content_only/comment_1_7f983de645430d970c75f25fee27b2ed._comment
new file mode 100644
index 0000000000..234a8d3120
--- /dev/null
+++ b/doc/todo/new_command_for_syncing_content_only/comment_1_7f983de645430d970c75f25fee27b2ed._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-06-29T05:20:56Z"
+ content="""
+It would also be awesome if there was something like `git annex synconlycontent --recent` or `--since=HEAD~10` or `--since=\"1 week ago\"` to just operate on the latest changed files.
+In contrast to `--accessedwithin` this would look at the git history to check when files were touched. This is currently possible with something like `git diff --name-only | sort -u | xargs git annex ...` or `git log --since=... --format... | ... | xargs git annex` but it's far from convenient.
+
+This might be a general new matching option for other subcommands as well.
+"""]]
diff --git a/doc/todo/new_command_for_syncing_content_only/comment_2_311cd71d61bea5782c71ee33282d152e._comment b/doc/todo/new_command_for_syncing_content_only/comment_2_311cd71d61bea5782c71ee33282d152e._comment
new file mode 100644
index 0000000000..ad4e368e0a
--- /dev/null
+++ b/doc/todo/new_command_for_syncing_content_only/comment_2_311cd71d61bea5782c71ee33282d152e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="How about `git annex transfer`?"
+ date="2023-06-29T05:25:50Z"
+ content="""
+Throwing `git annex transfer` into the ring for an alias for `git annex sync --content --no-commit --no-push --no-pull`.
+"""]]
diff --git a/doc/todo/new_command_for_syncing_content_only/comment_3_19398beb81c56b3b7cc3aff7081a2886._comment b/doc/todo/new_command_for_syncing_content_only/comment_3_19398beb81c56b3b7cc3aff7081a2886._comment
new file mode 100644
index 0000000000..5d238a7a99
--- /dev/null
+++ b/doc/todo/new_command_for_syncing_content_only/comment_3_19398beb81c56b3b7cc3aff7081a2886._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-06-29T17:49:32Z"
+ content="""
+@nobodyinperson open another todo for the --recent or similar idea.
+Something like that would be just another matching option.
+(However, getting and parsing `git log --since` seems like it would be hard
+to do efficiently..)
+"""]]
diff --git a/doc/todo/new_command_for_syncing_content_only/comment_4_c72cbc566af9585b4701f833883f878e._comment b/doc/todo/new_command_for_syncing_content_only/comment_4_c72cbc566af9585b4701f833883f878e._comment
new file mode 100644
index 0000000000..ed40e20c9f
--- /dev/null
+++ b/doc/todo/new_command_for_syncing_content_only/comment_4_c72cbc566af9585b4701f833883f878e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-06-29T17:51:30Z"
+ content="""
+@nobodyinperson `git-annex transfer` is not bad. Although I was envisioning
+this also handling dropping content from repos that don't want it, same as
+sync does.
+
+Well, I suppose getting a file from a remote and dropping it from the
+remote can also be seen as a "transfer". Just because git-annex internally
+uses "transfer" specifically for copying an object around doesn't mean the
+command line interface has to.
+"""]]
diff --git a/doc/todo/new_command_for_syncing_content_only/comment_5_857157a775711330df39b57828cf9bd4._comment b/doc/todo/new_command_for_syncing_content_only/comment_5_857157a775711330df39b57828cf9bd4._comment
new file mode 100644
index 0000000000..09317dc85e
--- /dev/null
+++ b/doc/todo/new_command_for_syncing_content_only/comment_5_857157a775711330df39b57828cf9bd4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-06-29T17:58:01Z"
+ content="""
+How about `satisfy`? It satisfies preferred content configuration.
+
+(Not numcopies configuration though, as implemented.)
+"""]]
diff --git a/doc/todo/new_command_for_syncing_content_only/comment_6_3ca0ef151b73781d2fe168c56d54faad._comment b/doc/todo/new_command_for_syncing_content_only/comment_6_3ca0ef151b73781d2fe168c56d54faad._comment
new file mode 100644
index 0000000000..3134158dfc
--- /dev/null
+++ b/doc/todo/new_command_for_syncing_content_only/comment_6_3ca0ef151b73781d2fe168c56d54faad._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Thanks for git annex satisfy, numcopies question"
+ date="2023-06-30T05:37:06Z"
+ content="""
+Marvellous! I was wondering, if `git annex sync` doesn't satisfy numcopies, what does? Is numcopies just for drop/move? `sync`/`satisfy` won't override the preferred content to satisfy numcopies, right? Then my mental model ”git annex ensures there's always at least `numcopies` copies of your files” wasn't really true. It just ”won't by itself reduce the amount of copies of a file below numcopies/mincopies”, right? If that's true, would a command or option to sync/satisfy make sense that enforces numcopies and potentionally overrides the preferred content? 
+"""]]
diff --git a/doc/todo/new_command_for_syncing_content_only/comment_7_084e139c8325bb8607f6c0a9f3873afe._comment b/doc/todo/new_command_for_syncing_content_only/comment_7_084e139c8325bb8607f6c0a9f3873afe._comment
new file mode 100644
index 0000000000..36ebe85763
--- /dev/null
+++ b/doc/todo/new_command_for_syncing_content_only/comment_7_084e139c8325bb8607f6c0a9f3873afe._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: numcopies question"""
+ date="2023-07-05T21:22:10Z"
+ content="""
+It won't send content that is otherwise not wanted just to satisfy
+numcopies. Of course, like all commands, it refuses to drop a file if
+numcopies is not satisfied.
+
+Comsider a remote foo that only wants `include=foo/*`. And another remote 
+bar that wants `include=bar/*`. And numcopies=2. If `git-annex satisfy`
+was only able to access foo, and worked to satisfy numcopies, foo would end
+up with files in bar/* that it doesn't want. But there's a better
+place for those files to go, namly bar, which wants them. So over time it
+would do a large amount of unncessary work, sending files to foo, only
+to later drop those same files from foo once it was able to populate bar.
+
+If the user wants to, they can configure foo to want
+`include=foo/* or lackingcopies=1` and then `git-annex satisfy` will know
+this is a repository that wants any files that don't have enough copies,
+and when bar is not accessible, it will send its files to foo.
+
+I think this could stand to be better documented. Especially since
+things like `git-annex copy --auto` *do* work to satisfy numcopies in
+addition to preferred content.
+"""]]
diff --git a/doc/todo/new_command_for_syncing_content_only/comment_8_c666e3ef20e823230392a70d6b588e7d._comment b/doc/todo/new_command_for_syncing_content_only/comment_8_c666e3ef20e823230392a70d6b588e7d._comment
new file mode 100644
index 0000000000..b2fd3654f6
--- /dev/null
+++ b/doc/todo/new_command_for_syncing_content_only/comment_8_c666e3ef20e823230392a70d6b588e7d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 8"
+ date="2023-07-06T05:52:50Z"
+ content="""
+Aah okay, I forgot there's `lackingcopies`. So if one adds `or lackingcopies=1` to every (sensible) remote's preferred content, then git annex is allowed to put \"fragile\" files there which haven't been copied enough yet (until there eventually are and they're removed again). I was missing that link, now everything makes sense. 
+
+And now I see that this is exactly what the `client` group does 😅
+"""]]
diff --git a/doc/todo/nitpick__58___show_one_column_per_UUID_in_git_annex_lis.mdwn b/doc/todo/nitpick__58___show_one_column_per_UUID_in_git_annex_lis.mdwn
new file mode 100644
index 0000000000..0a6d34eff1
--- /dev/null
+++ b/doc/todo/nitpick__58___show_one_column_per_UUID_in_git_annex_lis.mdwn
@@ -0,0 +1,13 @@
+Hi Joey
+
+Thanks for an amazing tool!
+
+I have a minor nitpick regarding git annex list output when using "alternative" git remotes for the same repository.
+
+My use case: I have a several devices which can be accessed either remotely via a ssh jump host, or locally via a 192.168.x.x address (git remotes like deviceN-local, deviceN-remote). This means I have two remotes for every unique repo. As git annex list outputs one column of Xs per remote, this means I have duplicates in there for every device, which causes the list to be very wide and hard to read with more than a couple of remotes (I have 8 unique=16 remotes in one repo).
+
+
+Would it be possible to get git annex list to (optionally) output one column per unique remote/UUID, e.g. by taking the name of the lowest cost remote with each UUID? This could be behind a flag, e.g. --unique-repos or similar.
+
+Best,
+KM
diff --git a/doc/todo/nitpick__58___show_one_column_per_UUID_in_git_annex_lis/comment_1_e6d9efa01ddeb129469b3b8a4205cb3f._comment b/doc/todo/nitpick__58___show_one_column_per_UUID_in_git_annex_lis/comment_1_e6d9efa01ddeb129469b3b8a4205cb3f._comment
new file mode 100644
index 0000000000..dec51638b8
--- /dev/null
+++ b/doc/todo/nitpick__58___show_one_column_per_UUID_in_git_annex_lis/comment_1_e6d9efa01ddeb129469b3b8a4205cb3f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-05-02T18:22:37Z"
+ content="""
+I think you would be better off using `git-annex whereis` in 
+this kind of situation.
+
+--unique-repos would be a fix specific to your own situation of having
+multiple names for a repo, but it would not help a user who had similar
+difficulty reading the output just because they have a lot of different
+repos. 
+
+The output of `git-annex whereis` is better suited to scaling to a lot of
+repos.
+"""]]
diff --git a/doc/todo/nitpick__58___show_one_column_per_UUID_in_git_annex_lis/comment_2_049625685f6147f38392e2df1dadac33._comment b/doc/todo/nitpick__58___show_one_column_per_UUID_in_git_annex_lis/comment_2_049625685f6147f38392e2df1dadac33._comment
new file mode 100644
index 0000000000..670ced7a8a
--- /dev/null
+++ b/doc/todo/nitpick__58___show_one_column_per_UUID_in_git_annex_lis/comment_2_049625685f6147f38392e2df1dadac33._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2023-01-23T22:55:10Z"
+ content="""
++1 for `--unique-repos` and a config `annex.listuniquerepos` as I have the same setup as OP. `git annex list` is a very compact view that can't always be swapped for the verbose `git annex whereis`.
+"""]]
diff --git a/doc/todo/not_ask_git_credentials_for_password_per_each_file.mdwn b/doc/todo/not_ask_git_credentials_for_password_per_each_file.mdwn
new file mode 100644
index 0000000000..1848e92093
--- /dev/null
+++ b/doc/todo/not_ask_git_credentials_for_password_per_each_file.mdwn
@@ -0,0 +1,35 @@
+ATM, git-annex asks for a possibly stored credential for a remote per each file, even if they are to come from the same remote. IMHO it should cache for that `get` run the password to be reused if some next file is to be obtained from the same (git) remote. 
+
+```
+lena:/tmp
+$> git clone http://data.pymvpa.org/tmp/sampleds/.git/    
+Cloning into 'sampleds'...
+Username for 'http://data.pymvpa.org': yoh
+Password for 'http://yoh@data.pymvpa.org': 
+Fetching objects: 50, done.
+
+$> cd sampleds 
+
+$> git annex get *dat
+Username for 'http://data.pymvpa.org': yoh
+Password for 'http://yoh@data.pymvpa.org': 
+get 123.dat (from origin...) 
+Username for 'http://data.pymvpa.org': yoh
+Password for 'http://yoh@data.pymvpa.org': 
+ok
+get 1.dat (from origin...) 
+Username for 'http://data.pymvpa.org': ^C
+```
+
+and `annex --debug` shows that each password prompt due to 
+
+```
+[2022-09-06 16:58:31.99087915] (Utility.Process) process [139934] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","credential","fill"]
+```
+
+and wondered if such excessive prompting could be avoided without engaging `git` credentials caching functionality.
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_1_ae15355f54b5137e696aaf5d2111806b._comment b/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_1_ae15355f54b5137e696aaf5d2111806b._comment
new file mode 100644
index 0000000000..5f2da4d3a2
--- /dev/null
+++ b/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_1_ae15355f54b5137e696aaf5d2111806b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-09T16:02:29Z"
+ content="""
+Is this a git-lfs special remote, or a git remote with an annex/objects
+directory? Probably does not matter, but also is unclear.
+
+`git credential` is doing the prompting here, and it supports caching, if
+you choose to enable that, by eg `git config credential.helper cache`.
+
+It feels redundant to add another layer of caching to git's existing cache.
+On the other hand, I suppose that `git pull` can make multiple http accesses
+and reuse the same credential for them, so that's kind of a precedent for
+caching during the lifetime of the process.
+"""]]
diff --git a/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_2_0c60c791513acff3910a29513f7f2f78._comment b/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_2_0c60c791513acff3910a29513f7f2f78._comment
new file mode 100644
index 0000000000..3ad2a1e0e7
--- /dev/null
+++ b/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_2_0c60c791513acff3910a29513f7f2f78._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-09-09T16:51:47Z"
+ content="""
+Regular git remote. IIRC Login yoh, password 123
+"""]]
diff --git a/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_2_2d8902e343e65a39b5a23278793ec921._comment b/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_2_2d8902e343e65a39b5a23278793ec921._comment
new file mode 100644
index 0000000000..48fd1d1e1d
--- /dev/null
+++ b/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_2_2d8902e343e65a39b5a23278793ec921._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-09T16:37:04Z"
+ content="""
+Seems that the git-lfs special remote already implements something like
+this. When discovering the LFS endpoint, it checks if a credential is
+needed, and that credential is included in the endpoint, so will be used
+for all requests, and it only prompts once.
+
+So it's only the git remote when accessing annex/objects over http that
+prompts repeatedly for credentials.
+"""]]
diff --git a/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_3_39ccd0fe773200166d0727dc903c34e3._comment b/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_3_39ccd0fe773200166d0727dc903c34e3._comment
new file mode 100644
index 0000000000..9dca59723c
--- /dev/null
+++ b/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_3_39ccd0fe773200166d0727dc903c34e3._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-09-09T18:11:28Z"
+ content="""
+I've implemented this, and a get of multiple files will prompt once.
+
+However, there is one case where the password is prompted twice.
+In a freshly cloned repo, where you have not run `git-annex init` manually,
+`git-annex get foo` will prompt twice.
+
+That is because autoinit causes `git-annex init --autoenable` to be run,
+and that infortunately probes for the UUID of the http remote, 
+which needs the password. Since the cache is necessarily only for a single
+process, that subprocess adds an additional prompt.
+
+There might also be other cases where git-annex starts
+subprocesses, that legitimately each need to prompt once for the password.
+I expect that, when `git-annex transferrer` is used 
+(due to annex.stalldetection being configured), and -J is used,
+each transferrer process will end up prompting once for the password.
+
+I don't think it makes sense to convert this from a simple in-process cache
+to a cache that is shared amoung all subprocesses. That would reimplement
+what `git-credential-cache` already does. And if you need that,
+you can just enable it.
+
+But I would like to fix the autoinit case to not prompt twice, and am
+leaving this open for now to do that.
+"""]]
diff --git a/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_4_4dca41df7506fa7aedf88d7618bbcf39._comment b/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_4_4dca41df7506fa7aedf88d7618bbcf39._comment
new file mode 100644
index 0000000000..fc72aba8ff
--- /dev/null
+++ b/doc/todo/not_ask_git_credentials_for_password_per_each_file/comment_4_4dca41df7506fa7aedf88d7618bbcf39._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-09-09T18:39:06Z"
+ content="""
+Fixed the autoinit case.
+
+I'm going to close this as done, despite the cases mentioned above where
+subprocesses might redundantly prompt for the credentials. 
+
+Another reason
+to not worry about those is that `git-annex sync` runs `git fetch` and `git
+push` (more than once), so there will be several password prompts there.
+So when git-annex runs a git-annex subprocess, it follows it's just as ok
+for it to do its own password prompts as it is for a git subprocess to do
+so. The solution to either is certianly to enable git's credential cache.
+So the scope of this todo has to be limited to prompting done by a single
+git-annex process.
+"""]]
diff --git a/doc/todo/onlyingroup_preferred_content_expression.mdwn b/doc/todo/onlyingroup_preferred_content_expression.mdwn
new file mode 100644
index 0000000000..54abb4db0e
--- /dev/null
+++ b/doc/todo/onlyingroup_preferred_content_expression.mdwn
@@ -0,0 +1,24 @@
+Hi joey,
+
+While writing a more complex preferred content expression today I noticed that a `onlyingroup=GROUPNAME` condition would be handy.
+
+Consider a sneakernet where clumps of nodes can communicate quickly with each other but the inter-clump communication is not so great. This is the case for my setup where a raspberry pi in the field has a USB stick attached (so two repos in `field` group), but their uplink is slow mobile data. Then I have an `offsite-backup` group for other disks/servers that I have access to.
+
+When I sync content from within an `offsite-backup` repo, I don't want it to copy data via the slow mobile data - this I do via sneakernet by swapping the USB drive in the field from time to time. Not setting up the `field` repos here is possible but prevents syncing of metadata, which is not ideal.
+
+If I could do `git annex groupwanted offsite-backup 'anything and not onlyingroup=field'`, the preferred content expression would be quite consise and short. `onlyingroup` would match if no other group has the file in question, only the given group. This would extend the functionality already provided by `inallgroup`.
+
+Without `onlyingroup`, one has to basically hard-code the amount of repos in the group with a rather complex expression ( 2 in this case, the Pi and the USB drive):
+
+```
+(anything and not copies=field:1 or copies=untrusted+:2) or (anything and not copies=field:2 or copies=untrusted+:3)
+```
+
+One also has to specifically catch each combination case where files between the `field` group are (only on the Pi? Only on the USB drive? on both?). The `copies=untrusted+:2` is then needed to allow copying other files that are around (e.g. because they were indeed copied over mobile data) but still in the `field` group.
+
+Maybe you see an easier way, but this is what I came up with. I think an `onlyingroup` expression would be very helpful.
+
+Cheers,
+Yann
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/onlyingroup_preferred_content_expression/comment_1_eddf28997789400398fbdd58ec64861d._comment b/doc/todo/onlyingroup_preferred_content_expression/comment_1_eddf28997789400398fbdd58ec64861d._comment
new file mode 100644
index 0000000000..dee6f17dc3
--- /dev/null
+++ b/doc/todo/onlyingroup_preferred_content_expression/comment_1_eddf28997789400398fbdd58ec64861d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="onlyingroup also useful for offline backup drives"
+ date="2023-07-31T04:40:42Z"
+ content="""
+Such an `onlyingroup` group would also be useful to match (and ignore from standard sync operations) files that are only available on hard-to-reach `offline-backup` repos, say offline backup drives or those in a safe. Normal repos can want `include=* and not onlyingroup=offline-backup` and then won't bother with unreachable files. This is an alternative to the `archive/` directory, which might be undesired or impractical to use (original file location is 'lost' when moving files into the archive).
+"""]]
diff --git a/doc/todo/onlyingroup_preferred_content_expression/comment_2_b1a22e4fbc594c3085e7fbc6fbaab69a._comment b/doc/todo/onlyingroup_preferred_content_expression/comment_2_b1a22e4fbc594c3085e7fbc6fbaab69a._comment
new file mode 100644
index 0000000000..1f5658d5fb
--- /dev/null
+++ b/doc/todo/onlyingroup_preferred_content_expression/comment_2_b1a22e4fbc594c3085e7fbc6fbaab69a._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-07-31T17:12:52Z"
+ content="""
+This seems like a pretty good idea. In particular, I think that the
+`not onlyingroup=offline-backup` example is persuasive. The
+`field` group example might be able to be dealt with by having
+a `collected` group and using `copies=collected:1` in repositories
+that only want a copy of data once it's been collected from the field.
+
+Hmm, one problem is that if you have 2 groups that you are using
+onlyingroup with, eg
+`(not onlyingroup=offline-backup) and (not onlyingroup=offline-archive)`.
+A file that is in two repositories, one for each group, will not match.
+
+One way to address that would be something like
+`onlyingroups=offline-backup,offline-archive` which would match
+on presence in any listed groups. I don't really like that this has
+its own ANDing happening inside a term of a preferred content expression
+though.
+
+What is onlyingroup supposed to do when a repository is in the
+specified group, but also in another group? My first reaction was that
+it should never match when content is in such a repository, since the
+content is indeed present in another group. 
+But that doesn't really seem useful.
+
+If it treated a repository that's in the specified group, but also is 
+in other groups, as matching, then it would be possible to put a repository
+in groups offline and backup and match on `not onlyingroup=offline`.
+I like this better than the `onlyingroups=offline-backup,offline-archive`
+because it's simpler and more composable.
+"""]]
diff --git a/doc/todo/onlyingroup_preferred_content_expression/comment_3_8f205160e62aa1312b8e2ef4cafe8c50._comment b/doc/todo/onlyingroup_preferred_content_expression/comment_3_8f205160e62aa1312b8e2ef4cafe8c50._comment
new file mode 100644
index 0000000000..e59f4a66ff
--- /dev/null
+++ b/doc/todo/onlyingroup_preferred_content_expression/comment_3_8f205160e62aa1312b8e2ef4cafe8c50._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-07-31T17:51:00Z"
+ content="""
+Another way to look at this is that preffered content allows expressing
+`copies=offline:1`, but there's no way to express a match on the
+number of copies that are in repositories that are not in the offline group.
+
+That might be expressed as say, `copies=!offline:1`
+
+Then `not copies=!offline:0` would be useful to only want files that are
+available in some repository that is not offline.
+
+This would avoid the question of what to do with onlyingroup when a
+repository is in the specified group but also another one.
+
+I really don't like the `copies=!offline:1` syntax though. (I already
+disliked copies=group:n` and this takes it in an even worse direction.)
+
+So while this is more generic, I kind of prefer the onlyingroup name..
+"""]]
diff --git a/doc/todo/openwrt_package.mdwn b/doc/todo/openwrt_package.mdwn
new file mode 100644
index 0000000000..70a4ae03fb
--- /dev/null
+++ b/doc/todo/openwrt_package.mdwn
@@ -0,0 +1,6 @@
+hi
+
+recently i have installed openwrt on my mikrotik routerboard. i am verry suprised how well it works. it lacks git-annex package. openwrt has git and i can install it.
+
+how can i build one on a mips arch ?
+is it possible to build multiple architecture standalone binaries ?
diff --git a/doc/todo/openwrt_package/comment_1_100d76109e04bc43979775d71b4152ac._comment b/doc/todo/openwrt_package/comment_1_100d76109e04bc43979775d71b4152ac._comment
new file mode 100644
index 0000000000..78029694a5
--- /dev/null
+++ b/doc/todo/openwrt_package/comment_1_100d76109e04bc43979775d71b4152ac._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="206.74.132.139"
+ subject="comment 1"
+ date="2014-02-06T17:26:58Z"
+ content="""
+I would be quite happy if someone took care of adding git-annex to openwrt.
+
+I don't have time to personally handle packaging for different linux distributions myself. What I could do is add mips builds of git-annex to the existing standalone linux builds. These would need to be built the same way the arm builds are done, using a Debian chroot and qemu to run tools from it. This is rather a lot of work for me to set up, and I don't know if I'd have to do it for both little and big endian mips.
+
+Also, it seems that Debian does not currently have a working haskell toolchain for mips. Which may well mean that ghc is not in a working state on mips at all.
+"""]]
diff --git a/doc/todo/openwrt_package/comment_2_2cb7dd4c0cc4413a4588b13cf7700de2._comment b/doc/todo/openwrt_package/comment_2_2cb7dd4c0cc4413a4588b13cf7700de2._comment
new file mode 100644
index 0000000000..d99fa13f1d
--- /dev/null
+++ b/doc/todo/openwrt_package/comment_2_2cb7dd4c0cc4413a4588b13cf7700de2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkNE-H4vEcbcGndxq5daT8qUb7yIf7r1OE"
+ nickname="Łukasz"
+ subject="comment 2"
+ date="2014-02-11T21:05:00Z"
+ content="""
+if debian does not have working toolchain for mips then there is no way to port it into mips machines.
+am i correct ?
+"""]]
diff --git a/doc/todo/openwrt_package/comment_3_5ba8a325a683ff543d81a366c873070d._comment b/doc/todo/openwrt_package/comment_3_5ba8a325a683ff543d81a366c873070d._comment
new file mode 100644
index 0000000000..9c9157d18f
--- /dev/null
+++ b/doc/todo/openwrt_package/comment_3_5ba8a325a683ff543d81a366c873070d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 3"
+ date="2014-02-11T21:39:34Z"
+ content="""
+Actually, debian stable does still have ghc building for mips/mipsel. It's just newer versions that have failed to build and nobody has fixed it yet.
+"""]]
diff --git a/doc/todo/openwrt_package/comment_4_132e67b34f9c616217e037e4ecac70a4._comment b/doc/todo/openwrt_package/comment_4_132e67b34f9c616217e037e4ecac70a4._comment
new file mode 100644
index 0000000000..6e5411dc36
--- /dev/null
+++ b/doc/todo/openwrt_package/comment_4_132e67b34f9c616217e037e4ecac70a4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-01-13T20:39:53Z"
+ content="""
+I checked, and the current status is that mips and mipsel in Debian have
+up-to-date builds of ghc and git-annex.
+"""]]
diff --git a/doc/todo/optimise_by_converting_Map_to_HashMap.mdwn b/doc/todo/optimise_by_converting_Map_to_HashMap.mdwn
new file mode 100644
index 0000000000..4db7ec8e2b
--- /dev/null
+++ b/doc/todo/optimise_by_converting_Map_to_HashMap.mdwn
@@ -0,0 +1,12 @@
+Map is used in lots of places, but HashMap is faster, at least sometimes.
+It would be worth benchmarking some of the more performance critical
+parts with HashMap. The uses in AnnexRead especially.
+
+(Set and HashSet too.)
+
+--[[Joey]]
+
+> Note that HashMap perfomance can degrade if an attacker provides keys
+> that collide. This has been used to DOS aeson parsing. (Which could
+> affect a few parts of git-annex in theory; fixed in aeson-2.0.1.0). 
+> So if converting to HashMap, need to consider this. --[[Joey]]
diff --git a/doc/todo/optimise_use_of_keys_db_on_local_remote.mdwn b/doc/todo/optimise_use_of_keys_db_on_local_remote.mdwn
new file mode 100644
index 0000000000..5a926bc5c7
--- /dev/null
+++ b/doc/todo/optimise_use_of_keys_db_on_local_remote.mdwn
@@ -0,0 +1,7 @@
+I noticed a git-annex copy -J4 --to a local remote was opening and closing the
+keysdb of the remote repository repeatedly. This probably slows it down
+some.
+
+Not immediately clear why, Remote.Git.onLocal reuses the same Annex state, so
+should  keep the keysdbhandle open, unless something is closing it, but I
+can't see what might be. --[[Joey]]
diff --git a/doc/todo/optimization_needed__58___slow_uninit.mdwn b/doc/todo/optimization_needed__58___slow_uninit.mdwn
new file mode 100644
index 0000000000..aeae0cbf1b
--- /dev/null
+++ b/doc/todo/optimization_needed__58___slow_uninit.mdwn
@@ -0,0 +1,24 @@
+I am running `git annex uninit` on  a quite heavy in number of annexed (text) files repository (can share a tarball if needed -- the product of https://github.com/con/tinuous/ to please those hating CI log navigation UIs ;-) ).
+
+the box on which it runs is very IO busy ATM, but the fact that I saw no progress from `uninit` for almost 10 minutes made me look into:
+
+```
+$> px | grep -A7 git-anne[x]
+yoh      30339  0.2  0.0 1074123060 38060 pts/4 Sl+ 11:49   0:01  |       \_ /home/yoh/miniconda3/envs/tinuous/bin/git-annex uninit
+yoh      30396  0.0  0.0  13892  5492 pts/4    S+   11:49   0:00  |           \_ git --git-dir=.git --work-tree=. --literal-pathspecs ls-files --stage -z --
+yoh      30398  0.0  0.0  14720  2988 pts/4    S+   11:49   0:00  |           \_ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch-check=%(objectname) %(objecttype) %(objectsize) --buffer
+yoh      30399  0.0  0.0  14848  4108 pts/4    S+   11:49   0:00  |           \_ git --git-dir=.git --work-tree=. --literal-pathspecs cat-file --batch=%(objectname) %(objecttype) %(objectsize) --buffer
+yoh      30417  0.0  0.0      0     0 pts/4    Z+   11:49   0:00  |           \_ [git] <defunct>
+yoh      30421  0.0  0.0      0     0 pts/4    Z+   11:49   0:00  |           \_ [git] <defunct>
+yoh      27761  0.0  0.0 112028  6892 pts/4    D+   11:51   0:00  |           \_ git --git-dir=.git --work-tree=. --literal-pathspecs rm --cached --force --quiet -- 01/21/github/pr/UNK/5f6fe634a863281742c0eb7d238c111da6e2e52e/Test on macOS/758/test (brew)/5_Set up Python 3.6.txt
+
+```
+
+so `git annex` invokes separate `git rm` on each file.  Having thousands of those is doomed to make it slow.  Unfortunately I have not spotted a `--batch` mode in `git rm --help` but I wondered if may be at least multiple files could be requested to be removed in a single call instead of running that rm per each file?
+
+git annex 8.20210127-g42239bc
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/optimization_needed__58___slow_uninit/comment_1_3d01d125ffea8dd247e68f716a9c636a._comment b/doc/todo/optimization_needed__58___slow_uninit/comment_1_3d01d125ffea8dd247e68f716a9c636a._comment
new file mode 100644
index 0000000000..3c81325ad1
--- /dev/null
+++ b/doc/todo/optimization_needed__58___slow_uninit/comment_1_3d01d125ffea8dd247e68f716a9c636a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-02-22T16:45:46Z"
+ content="""
+Also unannex is slow the same way. Looks like it can easily be fixed using
+git command queueing; I see no reason the rm needs to happen before
+changes to the working tree, as --cached makes the rm only operate on the
+index.
+
+Rest seem fast enough.
+"""]]
diff --git a/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__.mdwn b/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__.mdwn
new file mode 100644
index 0000000000..9410d3149b
--- /dev/null
+++ b/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__.mdwn
@@ -0,0 +1,9 @@
+Despite the possibility to [compress data on a special remote with encryption](http://git-annex.branchable.com/forum/huge_text_files___40__not_binary__41___-_compress/#comment-189a7960c1ed7fb6b8bb2345e3ea8c07)
+there are use-cases in which it would come in handy to have an option for a special remote like "directory" just for compression. 
+
+For example, I use git annex for very large scientific tomographic datasets and files originating from their processing like segmentations, distance maps, skeletons. While compressing the raw data makes little sense, compression e.g. segmentations and skeletons has a huge impact on the effective files size. Since compressing files of a few GBs to TBs is time consuming, I prefer to have an uncompressed version in the working tree (so I do not use file formats that are using compression by default e.g. .nii.gz) but it would be very helpful to have the option to push precious or older versions to a remote that then uses compression. Using encryption for this is a bit of an overkill and takes considerably longer than compressing with e.g. `pbzip`. A compressed file system for this purpose is no option, because the special remote is supposed to live on a restrictive archive server.
+
+Though, I guess, it would be possible to write a special remote wrapper for this, I wonder if this might qualify as an officially supported option to the already existing special remotes like "directory" or "rsync". E.g. in conjunction to `encryption` something like `compression` with possible values like `pbzip`, `bzip`, `pigz` and `gzip`.
+
+[[!tag confirmed]]
+[[!tag projects/datalad/potential]]
diff --git a/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_1_8620167702725aa8fb0e42dfe3820520._comment b/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_1_8620167702725aa8fb0e42dfe3820520._comment
new file mode 100644
index 0000000000..eb37df8c04
--- /dev/null
+++ b/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_1_8620167702725aa8fb0e42dfe3820520._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2019-02-13T16:48:08Z"
+ content="""
++1 for this.  Maybe, add a config option to pipe a file through a particular program before sending it to a remote?
+"""]]
diff --git a/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_2_f964bb1a14f099e69f1e780ee7c7ef68._comment b/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_2_f964bb1a14f099e69f1e780ee7c7ef68._comment
new file mode 100644
index 0000000000..509eab21c0
--- /dev/null
+++ b/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_2_f964bb1a14f099e69f1e780ee7c7ef68._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-03-19T17:35:52Z"
+ content="""
+Does seem like a good idea.
+
+Piping avoids needing to link git-annex with multiple compression
+libraries, or picking the wrong compression libraries. 
+I suppose that it's no big deal for a special remote to require that
+everyone who uses it has xz or whatever installed.
+
+But: The *name* of the command that is used cannot be stored in the remote
+config in the git-annex branch because that would be insecure. A mapping in
+the git-annex code from compression formats to known-safe command names
+would be one way, or a git config setting that has to be manually set when
+enabling the remote. Or both.
+"""]]
diff --git a/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_3_d4672f72a00509186cfc5dd85e1da140._comment b/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_3_d4672f72a00509186cfc5dd85e1da140._comment
new file mode 100644
index 0000000000..84959361e3
--- /dev/null
+++ b/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_3_d4672f72a00509186cfc5dd85e1da140._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 3"
+ date="2021-04-20T18:05:27Z"
+ content="""
+Would it perhaps be possible to set the compression using filters like file name/extension?  
+For example, I wouldn't want GA to waste time on compressing multimedia files that are already at entropy and, since they make up the majority of my special remote's content, re-writing them would be very time intensive (even more so when remote solutions are involved).
+Certain compressors might also work better on some files types compared to others.   
+This could be very important to scientists using datalad as they are likely to A. be working very specific kinds of data where certain compressors might significantly outperform others and B. have large quantities of data where compression is essential.
+
+If compressors are going to be limited to a known-safe selection, an important aspect to keep in mind would be compression levels as some compressors like zstd can range from lzo-like performance characteristics to lzma ones.
+
+Definitely a +1 on this one though, it would be very useful for my use-case aswell.
+"""]]
diff --git a/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_4_4560eff896578ac2779b03ec3484d0b2._comment b/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_4_4560eff896578ac2779b03ec3484d0b2._comment
new file mode 100644
index 0000000000..1c89c746e2
--- /dev/null
+++ b/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_4_4560eff896578ac2779b03ec3484d0b2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="lucas.gautheron@09f1983993dfb0907d02ba268b3ca672f1dc3eea"
+ nickname="lucas.gautheron"
+ avatar="http://cdn.libravatar.org/avatar/ae142c662ed23018ca47390ab00f7374"
+ subject="comment 4"
+ date="2021-06-05T10:10:57Z"
+ content="""
+This would be _extremely_ useful!
+
+Especially if it was possible to turn compression on/off based on each file name or metadata.
+
+"""]]
diff --git a/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_5_a154a025d441db4e0140fee821d1791c._comment b/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_5_a154a025d441db4e0140fee821d1791c._comment
new file mode 100644
index 0000000000..48ed25bbf9
--- /dev/null
+++ b/doc/todo/option_for___40__fast__41___compression_on_special_remotes_like___34__directory__34__/comment_5_a154a025d441db4e0140fee821d1791c._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2024-01-23T16:25:28Z"
+ content="""
+There would need to be a way for git-annex to tell if an object on a remote
+was compressed or not, and with what compressor. The two reaonable ways to
+do it are to use different namespaces for objects, or to make compression
+an immutable part of a special remote's configuration that is set at
+initremote time. 
+
+(A less reasonable way (IMHO) would be to record in the remote's state
+for each object what compression was used for it; this would bloat the
+git-annex branch.)
+
+A problem with using different namespaces is that git-annex then will
+have to do extra work to check for each one when retriving or checking
+presence of an object.
+
+When chunking is enabled, git-annex already has to check for chunked and
+unchunked versions of an object. This can include several different chunk
+sizes that have been in use at different times.
+
+So, we have a bit of an expontential blowup when combining chunking with
+compression namespaces. Probably the number of chunk sizes tried is less
+than 4 (eg logged chunk size, currently configured chunk size (when
+different), unchunked), and the number of possible compressors is less than
+10. So 20x or so increase in overhead. So I'm cautious of the namespaces approach.
+
+It would be possible to configure a single compressor that may be used at
+initremote time, but let some objects be chunked and others not. That would
+only double the overhead, and only for remotes with a compressor
+configured.
+
+As far as enabling compression based on filename though, it seems to me
+that an easier way to do that would be to have one remote with compression
+enabled, and a second one without it, and use preferred content to control
+which files are stored in which.
+"""]]
diff --git a/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__.mdwn b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__.mdwn
new file mode 100644
index 0000000000..0c636ad297
--- /dev/null
+++ b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__.mdwn
@@ -0,0 +1,10 @@
+Well, may be there is already a way, I could not find via search or look at `drop --help`.
+
+In our repositories/workflows we quite often encounter cases where multiple subfolders might contain the same (in content, and thus linking to the same key) file.  At times it is desired to drop content in specific folders while still retaining annexed content for other folders in the tree (for further processing etc).
+
+`git annex drop path1` would drop a key path1 points to regardless either there is another path2 within a tree which points to it and might still be "needed".  So what I am looking is some option (can't even come up with a good name for it, smth like `--not-used-elsewhere`?) for `drop`, so it would not drop keys which are used in the tree not pointed by `path`s provided to `drop` command.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_1_8f40b2663c9f48ddb07969af1b6632a8._comment b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_1_8f40b2663c9f48ddb07969af1b6632a8._comment
new file mode 100644
index 0000000000..3d2196c96a
--- /dev/null
+++ b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_1_8f40b2663c9f48ddb07969af1b6632a8._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-04-16T17:33:39Z"
+ content="""
+Problem is git-annex does not keep track of the information it would need
+in order to do this. Same problem as in
+[[bugs/indeterminite_preferred_content_state_for_duplicated_file]].
+
+Unlike that bug, I think it's actually rather ambiguous whether the user
+wants the file to be dropped in this case. Obviously you want it not to,
+the way your file tree is arranged, but other could 
+rely on the current behavior.
+
+Here's one way: Imagine a repo storing music. It has directories for
+albums, and also directories containing playlists, which are copies of
+files from albums. If I was in a mood for Brazilian music, but have gotten
+over it for now, I might want to drop Brazilian_playlist (which got very
+long in my travels there) to free up some space. If it refused to drop
+files because the same files were also in the corresponding album
+directories, I would wonder why git-annex had gotten broken.
+
+But the --not-used-elsewhere switch seems reasonable, if the needed info
+was available. I suppose git-annex could scan the index for changes and
+update state when this switch was used. Could be slow to update
+that state though.
+"""]]
diff --git a/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_2_32383ff5db43f0f4dc9e7470613f04fd._comment b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_2_32383ff5db43f0f4dc9e7470613f04fd._comment
new file mode 100644
index 0000000000..37d0332c60
--- /dev/null
+++ b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_2_32383ff5db43f0f4dc9e7470613f04fd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="drop --not-used-elsewhere"
+ date="2021-04-17T22:31:52Z"
+ content="""
++1 for `drop --not-used-elsewhere`.  Would be good if \"elsewhere\" included [[linked worktrees|tips/Using_git-worktree_with_annex]].
+For unlocked files, could just look at the hardlink count to the content file?   (But would be odd if only worked for unlocked files.)
+
+"""]]
diff --git a/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_3_2665f3fc268dff1de24d6ee9648c5d8c._comment b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_3_2665f3fc268dff1de24d6ee9648c5d8c._comment
new file mode 100644
index 0000000000..b4fc1a93df
--- /dev/null
+++ b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_3_2665f3fc268dff1de24d6ee9648c5d8c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2021-04-18T23:45:25Z"
+ content="""
+As a more general solution, suppose [[git-annex-matching-options]] were extended with the expressions `—includeifany=glob` (true for a key if *any* file using that key matches `glob`), `—includeifall=glob` (true for a key if *all* files using that key match `glob`), and similarly `—excludeifany/all`.  Then use `drop —includeifall=path/*`.
+"""]]
diff --git a/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_4_5fb82eb18c6d935ac07ec9220d9037c0._comment b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_4_5fb82eb18c6d935ac07ec9220d9037c0._comment
new file mode 100644
index 0000000000..b2b2ff83a0
--- /dev/null
+++ b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_4_5fb82eb18c6d935ac07ec9220d9037c0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-05-21T17:29:09Z"
+ content="""
+I have a plan over in [[bugs/indeterminite_preferred_content_state_for_duplicated_file]]
+and will be working on it over there.
+
+Linked worktrees seems out of scope for this though.
+"""]]
diff --git a/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_5_c7b9cbdbc4be36ea4d56a1eec13c6f34._comment b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_5_c7b9cbdbc4be36ea4d56a1eec13c6f34._comment
new file mode 100644
index 0000000000..0b8f189617
--- /dev/null
+++ b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_5_c7b9cbdbc4be36ea4d56a1eec13c6f34._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-05-25T15:14:49Z"
+ content="""
+On the --includeifany=glob idea, that seems to suggest a preferred content
+expression like includeifany=, analagous to how --include matches include=
+
+I'm feeling a bit cautious about adding a preferred content expression for
+this brand new capability. 
+
+And also unfortunately, it turned out not to be possible to prevent the
+associated files db from sometimes having stale filenames in it (see
+[[!commit c1b50282118520350d5328153fceedac2b8d8ed5]]). Which all current
+uses of the associated files db deal with by checking the list of
+associated files to see if all of them are in HEAD tree. A preferred
+content expression would also have to deal with that, and that risks
+slowing down evaluation of preferred content expressions generally.
+
+So I think it's best to not add a preferred content expression,
+at least until there's a use case and this has had
+some time to soak.
+"""]]
diff --git a/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_6_aa58624e8d0de174a06c6c2c0e33dc14._comment b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_6_aa58624e8d0de174a06c6c2c0e33dc14._comment
new file mode 100644
index 0000000000..488c3e61bc
--- /dev/null
+++ b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_6_aa58624e8d0de174a06c6c2c0e33dc14._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-05-25T15:32:40Z"
+ content="""
+What happens if I run `git annex drop --not-used-elsewhere foo bar` and foo
+and bar have the same content?
+
+The content is not used except for in the files I listed, so it could be
+argued that the --not-used-elsewhere does not apply, and it should drop it.
+But of course, that becomes a problem when dropping large directory trees.
+
+This also makes me thing that not-used-elsewhere is too broad, maybe I want
+to only avoid dropping content shared by files in bardir while dropping
+foodir, and the option does not allow it.
+
+So I do think @Ilya's on to something with his suggestion.
+`git annex drop foo --excludeifany=bar` does not have the ambiguity.
+
+I guess it's also useful for querying, potentially. Eg, if I have an inbox
+and an outbox and think perhaps some things from the inbox are things I've
+already dealt with before, I can find such files:
+
+	git annex find inbox --includeifany='outbox/*'
+"""]]
diff --git a/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_7_150a87dea1bd24e3d4e18cf3bcfb937f._comment b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_7_150a87dea1bd24e3d4e18cf3bcfb937f._comment
new file mode 100644
index 0000000000..01138d1dd2
--- /dev/null
+++ b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_7_150a87dea1bd24e3d4e18cf3bcfb937f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-05-25T16:44:56Z"
+ content="""
+Going with --includesamecontent=glob and --excludesamecontent=glob
+"""]]
diff --git a/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_8_1e87a33fe71ec2d5f4df887b94dae7c6._comment b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_8_1e87a33fe71ec2d5f4df887b94dae7c6._comment
new file mode 100644
index 0000000000..4469228e5a
--- /dev/null
+++ b/doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_8_1e87a33fe71ec2d5f4df887b94dae7c6._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2021-05-25T20:34:00Z"
+ content="""
+Thinking about preferred content expression some more, there should not
+be much reason to use this in one. includesamecontent=foo would have the
+same effect as include=foo, because when it operates on bar, it already
+checks if foo is the same content and is preferred content, and if so
+avoids dropping it. And when getting files, the effect would also be the
+same, because include=foo makes it get foo, same as includesamecontent=foo
+would.
+"""]]
diff --git a/doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents.mdwn b/doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents.mdwn
new file mode 100644
index 0000000000..d90d8b1b56
--- /dev/null
+++ b/doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents.mdwn
@@ -0,0 +1,5 @@
+One way I've lost data is to git-annex-add it in an untrusted temp clone of a repo, then commit and push the git branch, but forget to git-annex-copy the annexed contents referenced by that branch to a GloballyAvailable, (semi-)trusted remote.  Then, when the temp clone is gone, the branch pushed to the repo is referencing permanently dead files. Maybe, git-annex-init could install a pre-push hook to check for this, and abort the push if it happens?  Basically, to ensure that whatever data is referenced by pushed branches will actually be at least potentially get-table.
+
+Even if the current repo is not temp/untrusted, when sharing data with someone, you may want to ensure that any annexed files referenced by a pushed branch are actually potentially available.
+
+[[!tag moreinfo]]
diff --git a/doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents/comment_1_4e813660a7743ecc3378b87adb0cd0f8._comment b/doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents/comment_1_4e813660a7743ecc3378b87adb0cd0f8._comment
new file mode 100644
index 0000000000..3a2658b6da
--- /dev/null
+++ b/doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents/comment_1_4e813660a7743ecc3378b87adb0cd0f8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="automaticallly sync content on git push/pull"
+ date="2019-10-08T06:43:33Z"
+ content="""
+Even better would be an option to automatically sync copy the content referenced by any pushed commits, to a specified remote; and/or, to automatically `git-annex-get` content referenced by any pulled commits.  Then can use git-annex like git without needing to remember to `git-annex-sync`.  [[todo/operate_on_files_affected_by_a_commit_range]] could be useful in implementing the hooks.
+"""]]
diff --git a/doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents/comment_2_8aec191966e5633ae6b1b008f8990d3e._comment b/doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents/comment_2_8aec191966e5633ae6b1b008f8990d3e._comment
new file mode 100644
index 0000000000..3be3783922
--- /dev/null
+++ b/doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents/comment_2_8aec191966e5633ae6b1b008f8990d3e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-10-08T16:12:24Z"
+ content="""
+Installing such a pre-push hook by default is certianly going to break
+existing workflows, so I don't see that happening. It would break my own
+workflows, unless perhaps the hook only does something when the repository
+is untrusted.
+
+But I don't see anything preventing you from writing such a hook yourself.
+It should be easy enough to use `git annex whereis` or something like that
+to determine when you want to blick the push. If you need some additional
+query facility in git-annex to write it, we can talk about that.
+"""]]
diff --git a/doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents/comment_3_7337c487d7118e0bfdf931a741f3d5a4._comment b/doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents/comment_3_7337c487d7118e0bfdf931a741f3d5a4._comment
new file mode 100644
index 0000000000..ec912940ab
--- /dev/null
+++ b/doc/todo/option_to_block_git_from_pushing_references_to_not-yet-saved_contents/comment_3_7337c487d7118e0bfdf931a741f3d5a4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="issue of pushing refs to annexed files but not info on how to fetch them"
+ date="2021-03-01T16:46:56Z"
+ content="""
+Just got burned by a (variation of) this issue, after coming back to git-annex after a break. This time, I did `git-annex-copy` the files to a remote, but forgot to `git-annex-sync` the new location information, so a new clone could not access the files.   Maybe, a [pre-push hook](https://git-scm.com/docs/githooks#_pre_push) could be installed to print a warning (that can be turned off by a config setting), whenever you push refs to annexed files to a remote that has no (semi-)trusted location information for them?  Basically, as a git user you get used to thinking that `git push` saves your work, and forgetting that it doesn't with `git-annex` can lead to data loss/inaccessibility.
+"""]]
diff --git a/doc/todo/option_to_explain.mdwn b/doc/todo/option_to_explain.mdwn
new file mode 100644
index 0000000000..29b6e3f496
--- /dev/null
+++ b/doc/todo/option_to_explain.mdwn
@@ -0,0 +1,42 @@
+Add an --explain option that displays human readable descriptions of why
+git-annex decides whether or not to transfer or drop a file. Eg:
+
+    git-annex get bar foo --explain
+    [bar is not present here]
+    [foo is present here]
+    get bar
+
+    git-get get --auto --explain baz meep
+    [baz is not present here]
+    (baz has 1 copy, and its numcopies is 2)
+    get baz
+    [meep is not present here]
+    [meep matches preferred content: include==* and exclude==archive/*]
+    get meep
+
+    git-annex drop --explain archive/foo
+    [archive/foo is present here]
+    [archive/foo has 2 copies, and its numcopies is 1]
+    [archive/foo does not march preferred content: include==* and exclude!=archive/*]
+    drop foo (checking origin...) ok
+
+Implementation would be to output these extra lines when checking if
+content is present, and when checking if preferred content expressions
+match.
+
+It could also display the actions taken while attempting to drop a file,
+and the drop safety proof that is constructed. --debug already contains
+that, but it could be made more human readable and included in --explain.
+
+It should be possible, while matching a preferred content expression, to
+accumulate a version of it with "=" replaced by "==" and "!=" depending on
+whether a term matches. That seems clear enough to understand why it
+matched. What to do about terms like "present"? Maybe "!present" when it
+doesn't match?" And a term like "standard" would ideally expand out the
+included expression, eg: "standard(group==backup, include==*)" 
+
+[[!tag confirmed]] --[[Joey]]
+
+[[!tag projects/dandi]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/option_to_explain/comment_1_81644886e14851a276dc3c89965df62e._comment b/doc/todo/option_to_explain/comment_1_81644886e14851a276dc3c89965df62e._comment
new file mode 100644
index 0000000000..b702a50c81
--- /dev/null
+++ b/doc/todo/option_to_explain/comment_1_81644886e14851a276dc3c89965df62e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-07-05T20:46:13Z"
+ content="""
+Sounds absolutely awesome! The new `git annex satisfy` would also benefit from this. 
+
+Also when thinking about a potential future `--dry-run` mode that wouldn't actually do stuff but in combination with `--explain` would display what it would do and why. I know dry-running can be nontrivial to implement, especially when actions change state. But imagine how cool it would be to do `git annex assist --dry-run --explain` and to see what exactly it *would* do (what files go to git, which to the annex, what files will be copied where, etc.) 🤩
+"""]]
diff --git a/doc/todo/option_to_explain/comment_2_71616074104ab70eb76ad5edb9207b5c._comment b/doc/todo/option_to_explain/comment_2_71616074104ab70eb76ad5edb9207b5c._comment
new file mode 100644
index 0000000000..cb9bdbe995
--- /dev/null
+++ b/doc/todo/option_to_explain/comment_2_71616074104ab70eb76ad5edb9207b5c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-07-26T19:31:40Z"
+ content="""
+--explain is implemented and expanations for preferred content expressions,
+annex.largefiles, and annex.addunlocked are now displayed.
+
+Leaving this open because I do think that explanations of numcopies and
+content presence checking should be added, as well as perhaps explanations
+of drop proofs.
+"""]]
diff --git a/doc/todo/option_to_explain/comment_3_2179a7fec079045d82a58993d3f09995._comment b/doc/todo/option_to_explain/comment_3_2179a7fec079045d82a58993d3f09995._comment
new file mode 100644
index 0000000000..c0aad322d0
--- /dev/null
+++ b/doc/todo/option_to_explain/comment_3_2179a7fec079045d82a58993d3f09995._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="--explain is very helpful 👍"
+ date="2023-07-27T15:22:47Z"
+ content="""
+Thank you joey for `--explain`, this will be very helpful when debugging preferred content expressions and the like. 👏
+"""]]
diff --git a/doc/todo/option_to_explain/comment_4_28919c6f816f11811b1e8c73b07403f7._comment b/doc/todo/option_to_explain/comment_4_28919c6f816f11811b1e8c73b07403f7._comment
new file mode 100644
index 0000000000..fbeec53b7f
--- /dev/null
+++ b/doc/todo/option_to_explain/comment_4_28919c6f816f11811b1e8c73b07403f7._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-07-31T16:38:05Z"
+ content="""
+--explain now also shows when numcopies is taken into account when not
+dropping, eg `get --auto`.
+
+When dropping, git-annex already explains when numcopies is not satisfied
+of course. As to displaying the drop safety proof, I think it's too much in
+the weeds for a user to want it explained? Users probably don't want to
+worry about the distinction between RecentlyVerifiedCopy and LockedCopy,
+for example; those details are git-annex's job. It already gives a well
+calibrated explanation when it can't drop, so explaining when it can drop
+seems unncessary.
+
+I also looked at adding it for file content checking, but inAnnex is pretty core
+and is used in a lot of situations where --explain output would not be
+useful, eg after git-annex has downloaded a file, it will check inAnnex.
+While it would be possible to add something that explains that is only
+called when deciding whether to operate on a file, that would be an
+intrusive code change and would add complexity.
+
+Also, while it can be confusing to users sometimes why eg `git-annex get
+foo` doesn't output anything due to the file being present already, it
+seems like adding --explain output to that would generally not be useful to
+more experienced users. Explain needs to remain relatively concise, or it's
+just more debug output.
+
+So, closing this as completed, although of course more can be added
+to --explain later..
+"""]]
diff --git a/doc/todo/option_to_individually_hash_chunks.mdwn b/doc/todo/option_to_individually_hash_chunks.mdwn
new file mode 100644
index 0000000000..559bb79d8a
--- /dev/null
+++ b/doc/todo/option_to_individually_hash_chunks.mdwn
@@ -0,0 +1,5 @@
+Hey, I'm not sure whether todo is the right place for feature requests.
+
+When breaking files into chunks, it would be nice to have an option to hash the chunks based on their own content, rather than the content they are a part of.  This would provide for deduplicating data.
+
+I'm using git-annex with an append-only log where adding this would avoid the need to break logs into separate files to not reupload content.  Separate files eventually taxes git's tree size.
diff --git a/doc/todo/option_to_individually_hash_chunks/comment_1_c6d5133efb3ddc9ac632530600257bdf._comment b/doc/todo/option_to_individually_hash_chunks/comment_1_c6d5133efb3ddc9ac632530600257bdf._comment
new file mode 100644
index 0000000000..e4b610479b
--- /dev/null
+++ b/doc/todo/option_to_individually_hash_chunks/comment_1_c6d5133efb3ddc9ac632530600257bdf._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="re: individually hash chunks"
+ date="2021-03-15T15:23:08Z"
+ content="""
+If [[todo/alternate_keys_for_same_content]] were implemented, git-annex could store chunk content using regular keys (providing deduplication) and mark the chunk keys as alternate keys for the same content.
+
+I've also wanted this option, for a separate reason: to be able to quickly import files from a special remote that stores files in separate parts, and lets you read the checksums of the parts without downloading the files.
+
+I had thought of implementing a custom special remote that would store, for a given key A, the key B of a manifest file that listed the keys C1, ..., Cn of chunks of the content of key A.
+
+"""]]
diff --git a/doc/todo/option_to_individually_hash_chunks/comment_2_29821c673e5e8ce88c62086a67346357._comment b/doc/todo/option_to_individually_hash_chunks/comment_2_29821c673e5e8ce88c62086a67346357._comment
new file mode 100644
index 0000000000..d372e659f8
--- /dev/null
+++ b/doc/todo/option_to_individually_hash_chunks/comment_2_29821c673e5e8ce88c62086a67346357._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="another deduplication option"
+ date="2021-03-22T13:51:33Z"
+ content="""
+See also [[tips/using_borg_for_efficient_storage_of_old_annexed_files]].
+"""]]
diff --git a/doc/todo/option_to_individually_hash_chunks/comment_3_3cd814797e837fae3dba8d6d99f41ec1._comment b/doc/todo/option_to_individually_hash_chunks/comment_3_3cd814797e837fae3dba8d6d99f41ec1._comment
new file mode 100644
index 0000000000..3784170a81
--- /dev/null
+++ b/doc/todo/option_to_individually_hash_chunks/comment_3_3cd814797e837fae3dba8d6d99f41ec1._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-07-13T17:09:11Z"
+ content="""
+Hashing fixed sized chunks does not get very far toward
+deduplication, it really needs a rolling hash.
+
+The chunk design was designed to support this kind of thing from the
+beginning, see [[design/assistant/chunks]]. Each chunk has its own Key, and
+the chunk log only needs to somehow store data to get from an object's Key
+to a list of chunk Keys. Which is currently just a chunk size and number of
+chunks, but could be a list of Keys, or a pointer to where to find the
+list.
+
+So it's doable, but I have never quite found the tuits to attempt it.
+"""]]
diff --git a/doc/todo/option_to_individually_hash_chunks/comment_4_b2a78d90e7e2ee8a98f12663c9e1041a._comment b/doc/todo/option_to_individually_hash_chunks/comment_4_b2a78d90e7e2ee8a98f12663c9e1041a._comment
new file mode 100644
index 0000000000..806fcfcdc1
--- /dev/null
+++ b/doc/todo/option_to_individually_hash_chunks/comment_4_b2a78d90e7e2ee8a98f12663c9e1041a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-07-13T17:18:49Z"
+ content="""
+Dropping does present a problem though -- If a single chunk is used by
+multiple keys, then dropping one key would drop the chunk and make the
+other key no longer be stored on the remote. So it would somehow need to
+check if the chunk is used by other keys still stored on the remote,
+and the chunk logs don't let that be done efficiently.
+"""]]
diff --git a/doc/todo/option_to_limit_to_files_that_are_expected_to_be_present.mdwn b/doc/todo/option_to_limit_to_files_that_are_expected_to_be_present.mdwn
new file mode 100644
index 0000000000..2ed8715fc5
--- /dev/null
+++ b/doc/todo/option_to_limit_to_files_that_are_expected_to_be_present.mdwn
@@ -0,0 +1,7 @@
+--in=here checks if the object file is actually present. I recently had a
+situation where my repo was copied from elsewhere but missing the object
+files, and I wanted to get back the same objects. So I had to disable that
+check. So an option that checks for files expected to be here would be
+useful. --[[Joey]]
+
+> [[done]] as --expected-present --[[Joey]]
diff --git a/doc/todo/option_to_put_temp_files_on_a_RAM_disk.mdwn b/doc/todo/option_to_put_temp_files_on_a_RAM_disk.mdwn
new file mode 100644
index 0000000000..04a612dcf6
--- /dev/null
+++ b/doc/todo/option_to_put_temp_files_on_a_RAM_disk.mdwn
@@ -0,0 +1,5 @@
+Add an option to give git-annex a path to a RAM disk, and an option to set the maximum space to be used there.  git-annex often knows the size of the files it is downloading, since it's part of the key, so can determine in advance if a tempfile of that size would fit on the RAM disk.  One could instead symlink `.git/annex/tmp/` to a RAM disk, but this could cause memory overflow if a large file is transferred.
+
+Related: [[todo/keep_git-annex_branch_checked_out__63__]], [[todo/transitive_transfers]]
+
+[[!tag unlikely]]
diff --git a/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_1_28a5627604d2d4b25c51779a7216931d._comment b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_1_28a5627604d2d4b25c51779a7216931d._comment
new file mode 100644
index 0000000000..0e044d5008
--- /dev/null
+++ b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_1_28a5627604d2d4b25c51779a7216931d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Use of the RAM disk"
+ date="2020-01-28T14:03:15Z"
+ content="""
+What benefit would that give?
+
+When the transfer is complete, the file will be moved over to `.git/annex/objects`. On the same file system, that's a simple operation; across file systems, that's effectively a copy.
+
+In both cases, the file gets written to disk once. In the original case, it's up to the operating system when to start writing the data to disk (that is, unless the file is flushed by git-annex, which I don't have reason to assume it does). With a RAM disk inbetween, the file would be copied only when it's transferred completely (and then needs to be moved once more to not show up as an incomplete file at its final location). With the original setup, if the operating system has RAM to spare, it can do roughly that already (not start writing until the file is closed). When it's under pressure, it will flush the file out as soon as possible.
+
+Is there any performance issue you see that'd be solved using the RAM disk? If so, that might be indicative of something git-annex can do without starting to mount around (eg. remove any syncs / flushes that sneaked into the tempfile saving process, or use fallocate to tell the OS of the size to come).
+"""]]
diff --git a/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_2_1df752ac3b9cb2cc0e4a7dd4af71897f._comment b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_2_1df752ac3b9cb2cc0e4a7dd4af71897f._comment
new file mode 100644
index 0000000000..5840e4f35d
--- /dev/null
+++ b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_2_1df752ac3b9cb2cc0e4a7dd4af71897f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="use of RAM disk"
+ date="2020-01-28T17:23:28Z"
+ content="""
+You're right in general. There may be cases though, where a temp file doesn't just get moved into [[`.git/annex/objects`|internals]]: e.g. when [[chunking]] is used along with parallel downloads, chunks might go into separate temp files before being merged.  I was also thinking of use cases from [[todo/let_external_remotes_declare_support_for_named_pipes]], like [[todo/git-annex-cat]], where key contents is processed but not saved.
+"""]]
diff --git a/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_3_12a1b6f9fd616f5c498d5aff1cf1bcb6._comment b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_3_12a1b6f9fd616f5c498d5aff1cf1bcb6._comment
new file mode 100644
index 0000000000..a7c70bfbb7
--- /dev/null
+++ b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_3_12a1b6f9fd616f5c498d5aff1cf1bcb6._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Re: use of RAM disk"
+ date="2020-01-29T07:49:08Z"
+ content="""
+The chunks case should fold into the original one if git-annex merges the chunks using [ioctl_ficlonerange](https://manpages.debian.org/buster/manpages-dev/ioctl_ficlonerange.2.en.html), but admittedly that is a) not portable (but neither is mounting a RAM-disk) and b) will only work on some file systems.
+
+I don't understand the applications in named pipes well enough to comment there (will have to read up a bit).
+
+But more generally, I'd gut-feeling-expect that if all is properly advertised (possibly by a fcntl, but [RWH_WRITE_LIFE_SHORT](https://manpages.debian.org/buster/manpages-dev/fcntl.2.en.html) doesn't quite seem to be it) and no fsyncs are sent (like [eatmydata](https://www.flamingspork.com/projects/libeatmydata/) does), any file should behave like that until a file system action is performed that forces it to be committed to disk -- or the kernel decides that it'd better use that RAM for something else, but that's what it can probably do best.
+
+I'm not sure the approach of screening (and possibly patching) data producers to not fsync (on some systems, closing might be an issue too, and that's where it gets more complex) is better than putting things to a RAM disk, I just think it's an alternative worth exploring.
+"""]]
diff --git a/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment
new file mode 100644
index 0000000000..65f4961309
--- /dev/null
+++ b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-01-30T16:44:52Z"
+ content="""
+When git-annex downloads chunks, it downloads one chunk at a time
+(no parallelisation downloads of chunks of the same key) to either a temp
+file or a memory buffer, decrypts if necessary, and then appends the
+chunk to the destination file.
+
+Since chunks are often stored entirely in ram, the chunk size is typically
+a small fraction of ram. It seems unlikely to me that the kernel would
+often decide to unncessarily flush a small write to a temp file out to disk
+and drop it from the cache when the very next operation after writing the
+file is reading it back in.
+
+chrysn's analysis seems right.
+
+Also, this smells of premature optimisation, and tying it to features that
+have not even been agreed on, let alone implemented, makes it kind of super
+low priority?
+"""]]
diff --git a/doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages.mdwn b/doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages.mdwn
new file mode 100644
index 0000000000..ffc6e8e95f
--- /dev/null
+++ b/doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages.mdwn
@@ -0,0 +1,14 @@
+[[!format sh """
+$> git  clone http://datasets.datalad.org/labs/haxby/raiders/.git ; cd raiders; git annex wanted origin 2>/dev/null     
+Cloning into 'raiders'...
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+not metadata=distribution-restrictions=*
+"""]]
+
+so it is necessary to avoid considering all the merging and recording messages, complicating using wanted in the scripts etc
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages/comment_1_bfbf428da46eaea52cc54878f119512a._comment b/doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages/comment_1_bfbf428da46eaea52cc54878f119512a._comment
new file mode 100644
index 0000000000..60a7036552
--- /dev/null
+++ b/doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages/comment_1_bfbf428da46eaea52cc54878f119512a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2017-02-16T14:10:56Z"
+ content="""
+In your example, it is polluted by these messages because git-annex is initialising the repository as a git-annex. There should be a 'git annex init' after the 'cd', before you run git-annex commands (e.g. wanted).
+"""]]
diff --git a/doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages/comment_2_c43e838b750448fe4d1519e72c43242f._comment b/doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages/comment_2_c43e838b750448fe4d1519e72c43242f._comment
new file mode 100644
index 0000000000..dbd8edbbe4
--- /dev/null
+++ b/doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages/comment_2_c43e838b750448fe4d1519e72c43242f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2017-02-16T15:54:18Z"
+ content="""
+Thank you CandyAngel for the feedback.  I do know how to avoid it, but my point is that git-annex here uses stdout for both \"log messages\" and the output of the log command. IIRC some other commands, and git uses stderr for log/informational messages in cases where stdout is used for communicating output
+"""]]
diff --git a/doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages/comment_3_e006b8efab713d4965316c9846ec437c._comment b/doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages/comment_3_e006b8efab713d4965316c9846ec437c._comment
new file mode 100644
index 0000000000..7174ab82a9
--- /dev/null
+++ b/doc/todo/output_of_wanted___40__and_possibly_group_etc__41___should_not_be_polluted_with___34__informational__34___messages/comment_3_e006b8efab713d4965316c9846ec437c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-02-16T16:53:30Z"
+ content="""
+This can happen at other times than repository auto-init too.
+
+Generally plumbing commands just turn off all such messages very early,
+but in this case, the command has one mode where it's supposed to get data,
+which is plumbing-like, and another mode where it sets data, which is
+supposed to display normal messages about what it's doing. So it didn't
+turn messages off until after parsing the command line, which is too late.
+
+Affected commands: config group groupwanted numcopies schedule wanted required
+
+Fairly sure that's a complete set, at least it's all the commands with
+both a get and a set mode.
+"""]]
diff --git a/doc/todo/parallel_get.mdwn b/doc/todo/parallel_get.mdwn
new file mode 100644
index 0000000000..ac7343d526
--- /dev/null
+++ b/doc/todo/parallel_get.mdwn
@@ -0,0 +1,86 @@
+Wish: `git annex get [files] -jN` should run up to N downloads of files
+concurrently.
+
+This can already be done by just starting up N separate git-annex
+processes all trying to get the same files. They'll coordinate themselves
+to avoid downloading the same file twice.
+
+But, the output of concurrent git annex get's in a single teminal is a
+mess.
+
+It would be nice to have something similar to docker's output when fetching
+layers of an image. Something like:
+
+	get foo1 ok
+	get foo2 ok
+	get foo3 -> 5% 100 KiB/s
+	get foo4 -> 3% 90 KiB/s
+	get foo5 -> 20% 1 MiB/s
+
+Where the bottom N lines are progress displays for the downloads that are
+currently in progress. When a download finishes, it can scroll up the
+screen with "ok".
+
+	get foo1 ok
+	get foo2 ok
+	get foo5 ok
+	get foo3 -> 5% 100 KiB/s
+	get foo4 -> 3% 90 KiB/s
+	get foo6 -> 0% 110 Kib/S
+
+This display could perhaps be generalized for other concurrent actions.
+For example, drop:
+
+	drop foo1 ok
+	drop foo2 failed
+	  Not enough copies ...
+	drop foo3 -> (checking r1...)
+	drop foo4 -> (checking r2...)
+
+But, do get first.
+
+Pain points: 
+
+1. Currently, git-annex lets tools like rsync and wget display their own
+   progress. This makes sense for the single-file at a time get, because
+   rsync can display better output than just a percentage. (This is especially
+   the case with aria2c for torrents, which displays seeder/leecher info in
+   addition to percentage.)
+
+   But in multi-get mode, the progress display would be simplified. git-annex
+   can already get percent done information, either as reported by individiual
+   backends, or by falling back to polling the file as it's downloaded.
+
+2. The mechanics of updating the screen for a multi-line progress output
+   require some terminal handling code. Using eg, curses, in a mode that
+   doesn't take over the whole screen display, but just moves the cursor
+   up to the line for the progress that needs updating and redraws that
+   line. Doing this portably is probably going to be a pain, especially
+   I have no idea if it can be done on Windows.
+
+   An alternative would be a display more like apt uses for concurrent
+   downloads, all on one line:
+
+	get foo1 ok
+	get foo2 ok
+	get [foo3 -> 5% 100 KiB/s] [foo4 -> 3% 90 KiB/s] [foo5 -> 20% 1 MiB/s]
+
+   The problem with that is it has to avoid scrolling off the right
+   side, so it probably has to truncate the line. Since filenames
+   are often longer than "fooN", it probably has to elipsise the filename.
+   This approach is just not as flexible or nice in general.
+
+See also: [[parallel_possibilities]]
+
+> I am looking at using the ascii-progress library for this.
+> It has nice support for multiple progress bars, and is portable.
+> I have filed 7 issues on it, around 4 of which need to get fixed before
+> it's suitable for git-annex to use.. --[[Joey]]
+
+>> `git annex get -JN` works now, but lacks any progress display.
+>> Waiting on some updates to ascii-progress. --[[Joey]]
+
+>>> Wrote concurrent-output; [[done]] --[[Joey]]
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
diff --git a/doc/todo/patch_generation_with_annexed_files.mdwn b/doc/todo/patch_generation_with_annexed_files.mdwn
new file mode 100644
index 0000000000..dfe86e5de9
--- /dev/null
+++ b/doc/todo/patch_generation_with_annexed_files.mdwn
@@ -0,0 +1,121 @@
+It would be nice if something like `git format-patch` 
+could be done that supports sending annex objects along with the git patch.
+Then something like `git am` would apply the patch and at the same time
+extract the annex objects, verify them, and inject them into the
+repository.
+
+Some email servers have size limitations, which could limit the
+use cases.
+
+## UI
+
+This could be done with either a wrapper around git format-patch 
+or a subsequent command. Either way, it would examine the patch file
+to find the git-annex objects added in it, then modify it to include those
+objects.
+
+Similarly, a wrapper around git-am or a subsequent command to extract those
+objects and inject them into the repository.
+
+Which would be better, wrappers or post-processing commands?
+
+## optimal objects to include
+
+It seems that only objects added in a patch need to be included, not
+objects that are removed.
+
+If an object is removed and also added, we can assume that the receiver
+already has a copy, so no need to include that object in the patch. This
+will make renames of existing files avoid a redundant attachment of an
+object.
+
+When adding objects to a set of patch files, it can remember which objects
+it's added already, and avoid adding those to subsequent patches.
+
+That's close to optimal. But here are two non-optimal cases:
+
+1. A copy if made of a file. So the reciever already has the object,
+   but the patch only adds the new file, so the object gets added to it.
+2. A special remote has a copy of some of the objects, and the reciever
+   has access to it. Including any objects that are present in that special
+   remote would be non-optimal. But other objects should be included.
+
+Both cases could be handled by adding an option to specify a repository,
+and if an object is in that repository, skip adding it to the patch.
+
+## patch mangling
+
+git uses base-85 encoding for binary patches, which is more efficient than
+MIME's base64. git-annex could do the same (sandi provides a base-85 module).
+
+The git patch format has two expansion points.
+
+	From 4a3d9cb8f775036b0e0253730ea381d963e1684b Mon Sep 17 00:00:00 2001
+	From: Joey Hess <joeyh@joeyh.name>
+	Date: Fri, 19 Jul 2019 14:10:14 -0400
+	Subject: [PATCH] add
+	
+	---
+	 bash | 1 +
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 bash
+	
+	expansion point 1
+	
+	diff --git a/bash b/bash
+	new file mode 120000
+	index 0000000..a30f89b
+	--- /dev/null
+	+++ b/bash
+	@@ -0,0 +1 @@
+	+.git/annex/objects/k5/Zv/SHA256E-s1168776--059fce560704769f9ee72e095e85c77cbcd528dc21cc51d9255cfe46856b5f02/SHA256E-s1168776--059fce560704769f9ee72e095e85c77cbcd528dc21cc51d9255cfe46856b5f02
+	\ No newline at end of file
+	-- 
+	2.22.0
+	
+	expansion point 2
+
+The second seems better, because it puts the big binary chunk after
+the diff so makes it easier to read. Although the ending git version
+is formatted as an email signature, so the annex part would go inside
+the signature in a way. 
+
+git ignores anything after the signature, so putting it there also avoids any
+risk of confusing git if the annex object content looks too much like a patch
+to it.
+
+`git format-patch --attach` generates a MIME message. That would need
+a MIME library to deal with, and git-annex would need to add one or more
+attachments to it. But that option seems rarely used; I've never seen it used
+in the wild.
+
+## git-annex branch patches
+
+Patches to the git-annex branch are not handled by this. One consequence
+is that the receiver, upon applying the patch, doesn't add location
+tracking info for the sender's git-annex repo. Often that's fine;
+you don't want to bloat your repo with information about some random
+repo belonging to someone else when you can't directly access that repo.
+
+In some cases, other git-annex branch files could need to be modified as 
+part of a patch. This should not be raw git-annex branch patches because
+the format of that branch is optimised for union merging and machine
+readability, not manual patch review.
+
+A diff between `git annex vicfg` might work, as a way to include config
+changes in a patch. But does not seem very necessary.
+
+More useful would be location tracking information for the web
+remote and perhaps other remotes that the receiver has access to.
+And remote state files: log.web, log.rmt, log.rmet, log.cid, and log.cnk.
+
+Also, it would be nice to be able to include git-annex metadata changes
+in a patch.
+
+Not clear how to know when to include these, because they're not tied 
+to a change to the master branch. 
+
+But room needs to be left to add this kind of thing. Ie, what git-annex
+adds to the git patch needs to have its own expansion point.
+
+[[!tag needsthought]]
diff --git a/doc/todo/preserve_file_extensions_in_WORM_and_URL_keys.mdwn b/doc/todo/preserve_file_extensions_in_WORM_and_URL_keys.mdwn
new file mode 100644
index 0000000000..c24e0c12e9
--- /dev/null
+++ b/doc/todo/preserve_file_extensions_in_WORM_and_URL_keys.mdwn
@@ -0,0 +1,3 @@
+Right now, when computing a WORM key from a relative path or a URL key from a URL, if the original string is longer than a SHA256 checksum, its tail is replaced with its md5.  Unfortunately, this eats up the file extension(s) at the end, causing the issues that \*E backends solve.   It would be better to keep the tail of the path and replace the start or the middle with the md5, preserving extensions (as configured in annex.maxextensionlength) the same way \*E backends do.  Maybe also, add a config option for the length beyond which the replacement-with-checksum happens?
+
+[[!tag confirmed]]
diff --git a/doc/todo/preserve_file_extensions_in_WORM_and_URL_keys/comment_1_3cf91bca8e01f98644b0d25a45ecf092._comment b/doc/todo/preserve_file_extensions_in_WORM_and_URL_keys/comment_1_3cf91bca8e01f98644b0d25a45ecf092._comment
new file mode 100644
index 0000000000..03b9ab9f67
--- /dev/null
+++ b/doc/todo/preserve_file_extensions_in_WORM_and_URL_keys/comment_1_3cf91bca8e01f98644b0d25a45ecf092._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-30T18:43:19Z"
+ content="""
+I think it would be safe to make this change for WORM keys, which 
+certianly don't need to generate the same key for 2 files with the same
+name.
+
+Less sure about URL keys, if two git-annex addurls versions pick different
+keys for the same url, then there would be a merge conflict, where
+currently there is not. I think I've addurled the same url in different
+clones of a repo before, probably. Although addurl with and without --fast
+or --relaxed also causes that problem and maybe it's not worth worrying
+about it.
+"""]]
diff --git a/doc/todo/prevent_directly_printing_to_stderr_error_from_an_attempt_to_download_remote___47__config_file.mdwn b/doc/todo/prevent_directly_printing_to_stderr_error_from_an_attempt_to_download_remote___47__config_file.mdwn
new file mode 100644
index 0000000000..d09a853ceb
--- /dev/null
+++ b/doc/todo/prevent_directly_printing_to_stderr_error_from_an_attempt_to_download_remote___47__config_file.mdwn
@@ -0,0 +1,42 @@
+ATM git-annex init on a new clone would try to sense the remote regarding git-annex support and would try to fetch its /config.  If that fails it would announce that remote ignored for annex.
+
+[[!format sh """
+...
+Switched to branch 'adjusted/master(unlocked)'
+download failed: Not Found
+
+  Remote origin not usable by git-annex; setting annex-ignore
+
+"""]]
+and that download failed, thanks to --debug output comes from
+[[!format sh """
+[2018-09-28 12:52:12.541757374] Request {
+  host                 = "github.com"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Range","bytes=0-"),("Accept-Encoding","identity")]
+  path                 = "/psychoinformatics-de/studyforrest-data-structural/config"
+  queryString          = ""
+  method               = "GET"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+}
+
+download failed: Not Found
+
+  Remote origin not usable by git-annex; setting annex-ignore
+
+"""]]
+
+IMHO that "download failed: " message output should be provided only in `--debug` mode.  Otherwise, if exposed to naive user it is an uninformative alarm, which (if he/she knows) is clarified by the follow up message ("Remote origin not usable ...")
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+ref: [https://github.com/datalad/datalad/pull/2881#issue-218977359](https://github.com/datalad/datalad/pull/2881#issue-218977359)
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn b/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn
new file mode 100644
index 0000000000..75c6ad6153
--- /dev/null
+++ b/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn
@@ -0,0 +1,18 @@
+As seen in [[forum/Not_enough_free_space]], pulling
+a commit that unlocks a lot of large files whose content is present in the
+repository can result in an unexpected doubling of the disk space used by
+git-annex.
+
+annex.diskreserve avoids that using up the entire disk, but it's not
+uncommon for users to not have it set, and the 1 mb default can easily
+be eaten up by other non-object uses of disk.
+
+Perhaps 1 mb is too small for the default for annex.diskreserve. Even
+10 or 100 mb would leave a lot more margin for other minor uses of disk space.
+(Update: increased default to 100 mb)
+
+Perhaps there could be another config like annex.diskreserve but that
+applies only to populating unlocked files. It could default to some larger
+size, like 1 gb. Probably most users are not going to want to populate
+unlocked files when their disk space gets that low. Although, the same
+could be argued about just getting files. --[[Joey]]
diff --git a/doc/todo/provide___39__file__39___in_--json-progress_record_for_addurl.mdwn b/doc/todo/provide___39__file__39___in_--json-progress_record_for_addurl.mdwn
new file mode 100644
index 0000000000..12203f589f
--- /dev/null
+++ b/doc/todo/provide___39__file__39___in_--json-progress_record_for_addurl.mdwn
@@ -0,0 +1,20 @@
+Would it be sensibly easy to provide "file" field in progress json records for addurl?  I guess in any usecase (provided or deduced from url filename) it should be known at that stage.
+ATM it is just "null" and I guess (didn't try ATM) it would be impossible to associate particular progress reports with corresponding files in the `--batch -J` mode
+
+[[!format sh """
+$> git annex addurl --file bigone --json --json-progress https://s3.amazonaws.com/fcp-indi/data/Projects/ABIDE_Initiative/Outputs/freesurfer/5.1/UCLA_1_0051257/mri/T1.mgz                                              
+{"byte-progress":259645,"action":{"command":"addurl","file":null},"total-size":2459677,"percent-progress":"10.56%"}
+{"byte-progress":1304125,"action":{"command":"addurl","file":null},"total-size":2459677,"percent-progress":"53.02%"}
+{"command":"addurl","note":"to bigone","success":true,"key":"MD5E-s2459677--ad5bf54490212c7e9d88f15e16c4b0c1","file":"bigone"}
+"""]]
+
+Thanks in advance
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> In general addurl doesn't know the filename until after it's downloaded
+> the url (due to running youtube-dl on html urls), but when --file
+> or --batch --with-files is used, it does know the filename early.
+> So, made the json-progress include the filename when it's known.
+> [[done]] --[[Joey]]
diff --git a/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse.mdwn b/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse.mdwn
new file mode 100644
index 0000000000..006aed1ce4
--- /dev/null
+++ b/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse.mdwn
@@ -0,0 +1,61 @@
+<details>
+<summary>ATM it is a formatted text (click to expand)</summary> 
+
+```shell
+$> git annex initremote myrsync type=rsync --whatelse
+shellescape
+	avoid usual shell escaping (not recommended)
+	(yes or no)
+rsyncurl
+	(required) url or hostname:/directory for rsync to use
+chunk
+	size of chunks (eg, 1MiB)
+encryption
+	how to encrypt data stored in the special remote
+	(hybrid or none or pubkey or shared or sharedpubkey)
+embedcreds
+	embed credentials into git repository
+	(yes or no)
+mac
+	how to encrypt filenames used on the remote
+	(HMACSHA1 or HMACSHA224 or HMACSHA256 or HMACSHA384 or HMACSHA512)
+keyid
+	gpg key id
+keyid+
+	add additional gpg key
+keyid-
+	remove gpg key
+exporttree
+	export trees of files to this remote
+	(yes or no)
+importtree
+	import trees of files from this remote
+	(yes or no)
+```
+</details>
+
+which would make it necessary to establish a possibly fragile parsing by any tool which would like to programmatically obtain/use/expose those options.
+
+It would be great if there was a way to trigger such listing be output in more friendly for machines form? e.g. a json dictionary alike
+
+```json
+{
+ "rsyncurl": {
+   "required": True,
+   "description": "url or hostname:/directory for rsync to use"
+ },
+ "shellescape": {
+   "description": "avoid usual shell escaping (not recommended)",
+   "choices": ["yes", "no"]
+   },
+   ...
+}
+```
+
+Looking at the [protocol](https://git-annex.branchable.com/design/external_special_remote_protocol/) I see no indication of "required" or "choices" to be actually explicitly provided by the remote fields, so I guess just supposed to be included in the text, so may be given current state of things, aforementioned dictionary would be simply ```{"NAME": "DESCRIPTION"}```,  which someone makes this proposed TODO less valuable.
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse/comment_1_5ed9864ef616d9e9b77a3d62561363fd._comment b/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse/comment_1_5ed9864ef616d9e9b77a3d62561363fd._comment
new file mode 100644
index 0000000000..f5065c5461
--- /dev/null
+++ b/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse/comment_1_5ed9864ef616d9e9b77a3d62561363fd._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-17T16:06:26Z"
+ content="""
+My design process for this feature included almost getting stuck on wanting
+some kind of types for the values, and way to track which options are
+required, or exclusive of other options, or dependencies of other options,
+etc. All stuff that eg, an applicative option parser can support quite
+well, but it would complicate the external protocol enourmously, if it
+could be represented at all in it. So I had to eliminate all that.
+
+I think it's fairly uncommon for tab completion to do anything special
+about required parameters, or even mutually exclusive options (although
+git-annex tab completion does handle the latter), and while I can imagine
+a gui interface marking an input field as required, it seems
+that would be the least of its problems if it doesn't know what kind of
+control to use for the field?
+
+It would be easy to add --whatelse-json, but it would be limited to the
+name, a description of the purpose of the field, and maybe a description
+of the expected value or list of valid values.
+I'm unsure about the utility of that..
+"""]]
diff --git a/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse/comment_2_e9647b34aa79c414faf0f57ba17e6af4._comment b/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse/comment_2_e9647b34aa79c414faf0f57ba17e6af4._comment
new file mode 100644
index 0000000000..afa657703f
--- /dev/null
+++ b/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse/comment_2_e9647b34aa79c414faf0f57ba17e6af4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-05-10T16:56:37Z"
+ content="""
+I'm still not seeing much of an application for this, but since I've been
+adding --json support to most git-annex commands anyway recently, and got
+to initremote, I did go ahead and make --whatelse --json work.
+
+Currently only the field name and description, and a description of the
+allowed values are in there. It might be possible to add more information
+like type or required or not, but I'd want to work with someone who was
+consuming that information to do that.
+"""]]
diff --git a/doc/todo/provide_windows_build_with_MagicMime.mdwn b/doc/todo/provide_windows_build_with_MagicMime.mdwn
new file mode 100644
index 0000000000..79de2f64f4
--- /dev/null
+++ b/doc/todo/provide_windows_build_with_MagicMime.mdwn
@@ -0,0 +1,9 @@
+I forgot already why windows build is without having MagicMime support added, and failed to find a reason in the archives.
+But [there is demand](https://github.com/datalad/datalad/pull/3956#pullrequestreview-335604805) from Windows users! ;)
+
+Without such functionality we cannot consistently (cross-platform) use git-annex for many DataLad datasets, where text files (well -- soon "non-binary files") are configured to be committed directly to git.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]] 
diff --git a/doc/todo/provide_windows_build_with_MagicMime/comment_1_11adb1623314e8a43c50704c5e6e62d4._comment b/doc/todo/provide_windows_build_with_MagicMime/comment_1_11adb1623314e8a43c50704c5e6e62d4._comment
new file mode 100644
index 0000000000..a86e88b100
--- /dev/null
+++ b/doc/todo/provide_windows_build_with_MagicMime/comment_1_11adb1623314e8a43c50704c5e6e62d4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-06T16:55:36Z"
+ content="""
+It's a C library and it's not vendored into the haskell library as is often
+the case, so it has be be linked in. I don't know what would be involved in
+getting it installed on windows and bundled with git-annex in a usable state,
+and I'm a bit afraid to find out.
+
+WSL can be used to run linux git-annex on windows, so that's a way already
+available to use MagicMime.
+
+(The entire future of the windows port is currently TBD, it seems likely
+that it will go away and WSL be used, aside from the current bugs in WSL
+that make sqlite crash.)
+"""]]
diff --git a/doc/todo/provide_windows_build_with_MagicMime/comment_2_8f2d350c853f8827e1d5f95897dc2bd8._comment b/doc/todo/provide_windows_build_with_MagicMime/comment_2_8f2d350c853f8827e1d5f95897dc2bd8._comment
new file mode 100644
index 0000000000..e04f76ca28
--- /dev/null
+++ b/doc/todo/provide_windows_build_with_MagicMime/comment_2_8f2d350c853f8827e1d5f95897dc2bd8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-01-06T19:27:23Z"
+ content="""
+FWIW:
+
+- I am not yet sure if WSL would ever become a panacea. So far in my attempts I kept running into issues which related to how you (user) expose Windows file system(s) inside WSL, and there might be no \"one setup which fits all the use cases\".
+
+- There seems to be efforts like https://github.com/nscaife/file-windows which seems to promise building Windows binaries of file and libmagic for Windows - may be it could be used here.
+
+- IMHO an ideal way for git-annex deployment on windows would have been a conda-forge build of it.  Unfortunately it would not facilitate solution here since I do not see [windows build for libmagic](https://anaconda.org/search?q=libmagic). (meanwhile [filed an issue](https://github.com/conda-forge/libmagic-feedstock/issues/11), if resolved - could give an additional motivation to approach [git-annex-feedstock/issues/15](https://github.com/conda-forge/git-annex-feedstock/issues/15)
+"""]]
diff --git a/doc/todo/provide_windows_build_with_MagicMime/comment_3_15509110c5900aee2cc977372da16f0b._comment b/doc/todo/provide_windows_build_with_MagicMime/comment_3_15509110c5900aee2cc977372da16f0b._comment
new file mode 100644
index 0000000000..9921aa6436
--- /dev/null
+++ b/doc/todo/provide_windows_build_with_MagicMime/comment_3_15509110c5900aee2cc977372da16f0b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="michael.hanke@c60e12358aa3fc6060531bdead1f530ac4d582ec"
+ nickname="michael.hanke"
+ avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
+ subject="WSL 1/2 experience"
+ date="2020-01-08T15:20:04Z"
+ content="""
+I looked into WSL 1 and 2 in the context (and with the hope) of trying to avoid having windows-specific code and documentation in and for datalad. My conclusion was that neither of them is practical (maybe: yet), because with a unix-like default setup of a repository (lock, symlinks) no repository content was accessible from outside the WSL environment. I think the main motivation for running on Windows is using Windows apps. And that specifically is not possible/easily achievable for any random app.
+"""]]
diff --git a/doc/todo/provide_windows_build_with_MagicMime/comment_4_4727291eefa07a40da13dace75a2e255._comment b/doc/todo/provide_windows_build_with_MagicMime/comment_4_4727291eefa07a40da13dace75a2e255._comment
new file mode 100644
index 0000000000..2f1b5b9260
--- /dev/null
+++ b/doc/todo/provide_windows_build_with_MagicMime/comment_4_4727291eefa07a40da13dace75a2e255._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="git-annex in docker on Windows"
+ date="2020-01-08T16:16:31Z"
+ content="""
+Maybe, git-annex on Windows could be run in a Docker container, operating on Windows files via bind mounts?  A conda-forge package could be made that translates git-annex command invocations into 'docker run' commands.
+"""]]
diff --git a/doc/todo/provide_windows_build_with_MagicMime/comment_5_4633d2a40bca1ba8fa93f7038569715f._comment b/doc/todo/provide_windows_build_with_MagicMime/comment_5_4633d2a40bca1ba8fa93f7038569715f._comment
new file mode 100644
index 0000000000..b32a7200b7
--- /dev/null
+++ b/doc/todo/provide_windows_build_with_MagicMime/comment_5_4633d2a40bca1ba8fa93f7038569715f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-01-08T18:26:17Z"
+ content="""
+I guess that `git annex adjust --unlock` would avoid whatever the problem
+is with the symlinks.
+"""]]
diff --git a/doc/todo/provide_windows_build_with_MagicMime/comment_6_5542a421c6c7c878394d7dd7a3bce9c1._comment b/doc/todo/provide_windows_build_with_MagicMime/comment_6_5542a421c6c7c878394d7dd7a3bce9c1._comment
new file mode 100644
index 0000000000..6afc07dc34
--- /dev/null
+++ b/doc/todo/provide_windows_build_with_MagicMime/comment_6_5542a421c6c7c878394d7dd7a3bce9c1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="Windows build of file (which includes libmagic)"
+ date="2020-07-16T22:01:17Z"
+ content="""
+- I have successfully cross-built (well -- it produced binaries, didn't test if they are usable) built `file` using/as shown in https://github.com/nscaife/file-windows/pull/9
+- There is https://github.com/julian-r/file-windows with a visual studio built `file`.  releases provide builds using difference VS versions, not sure if it needs any VS runtime
+- In conda apparently there is already `m2-file` package (a bit dated from 3 years ago) 
+
+so may be one of those ways could assist in establishing a built with MAGIC support on windows?
+"""]]
diff --git a/doc/todo/provide_windows_build_with_MagicMime/comment_7_d16e4fb3d0be2acd23d158272171b842._comment b/doc/todo/provide_windows_build_with_MagicMime/comment_7_d16e4fb3d0be2acd23d158272171b842._comment
new file mode 100644
index 0000000000..df8797e746
--- /dev/null
+++ b/doc/todo/provide_windows_build_with_MagicMime/comment_7_d16e4fb3d0be2acd23d158272171b842._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="windows build with magic"
+ date="2020-10-22T19:32:55Z"
+ content="""
+FWIW, the mission of automated building of windows installer for annex with libmagic support is accomplished.  
+
+- It is 64bit build, works on Windows 10 **but in my experience does not work on Windows 7**. [info/pain to share if interested](https://github.com/datalad/datalad-extensions/pull/40#issuecomment-713853822)
+- Not sure if artifacts are publicly available [from github](https://github.com/datalad/datalad-extensions/runs/1294145386?check_suite_focus=true), but current copy could be fetched from [my personal website](http://www.onerussian.com/tmp/git-annex-windows-installer_20201022.zip).  We are [thinking](https://github.com/datalad/datalad-extensions/issues/46) about organizing public consistent distribution for them
+- libmagic is cross-build on Linux, based on [file-windows](https://github.com/nscaife/file-windows) with some fixups (?) in [our clone](https://github.com/datalad/file-windows)
+"""]]
diff --git a/doc/todo/proving_preferred_content_behavior.mdwn b/doc/todo/proving_preferred_content_behavior.mdwn
new file mode 100644
index 0000000000..73f181bc0d
--- /dev/null
+++ b/doc/todo/proving_preferred_content_behavior.mdwn
@@ -0,0 +1,75 @@
+Preferred content expressions can be complicated to write and reason about.
+A complex expression can involve lots of repositories that can get into
+different states, and needs to be written to avoid unwanted behavior.
+
+It would be very handy to provide some way to prove things about behavior
+of preferred content expressions, or a way to simulate the behavior of a
+network of git-annex repositories with a given preferred content configuration 
+
+## motivating examples
+
+For example, consider two reposities A and B. A is in group M and B is in
+group N. A has preferred content `not inallgroup=N` and B has `not inallgroup=M`.
+
+If A contains a file, then B will want to also get a copy. And things
+stabilize there. But if the file is removed from A, then B also wants to
+remove it. And once B has removed it, A wants a copy of it. And then B also
+wants a copy of it. So the result is that the file got transferred twice,
+to end up right back where we started.
+
+The worst case of this is `not present`, where the file gets dropped and
+transferred over and over again. The docs warn against using that one. But
+they can't warn about every bad preferred content expression.
+
+## balanced preferred content
+
+When [[design/balanced_preferred_content]] is added, a whole new level of
+complexity will exist in preferred content expressions, because now an
+expression does not make a file be wanted by a single repository, but
+shards the files amoung repositories in a group. 
+
+And up until this point preferred content expressions have behaved the same no
+matter the sizes of the underlying repositories, but balanced preferred
+content does take repository fullness into account, which further
+complicates fully understanding the behavior.
+
+Notice that `balanced()` (in the current design) is not stable when used
+on its own, and has to be used as part of a larger expression to make it
+stable, eg:
+
+    ((balanced(backup) and not (copies=backup:1)) or present
+
+So perhaps `balanced()` should include the other checks in it,
+to avoid the user shooting themselves in the foot. On the other 
+hand, if `balanced()` implicitly contains `present`, then `not balanced()`
+would include `not present`, which is bad!
+
+(For that matter, what does `not balanced()` even do currently?)
+
+## proof
+
+What could be proved about a preferred content expression?
+
+No idea really. Would be interesting to consider what formal methods can
+do here. Could a SAT solver be used somehow for example?
+
+## static analysis
+
+Clearly `not present` is an problematic preferred content expression. It
+would be good if git-annex warned and/or refused to set such an expression
+if it could detect it. Similarly `not groupwanted` could be detected as a
+problem when the group's preferred content expression contains `present`.
+
+Is there is a more general purpose and not expensive way to detect such
+problematic expressions, that can find problems such as the 
+`not inallgroup=N` example above?
+
+## simulation
+
+Simulation seems fairly straightforward, just simulate the network of
+git-annex repositories with random files with different sizes and
+metadata. Be sure to enforce invariants like numcopies the same as
+git-annex does.
+
+Since users can write preferred content expressions, this should be
+targeted at being used by end users.
diff --git a/doc/todo/publicurl_config_for_all_special_remotes.mdwn b/doc/todo/publicurl_config_for_all_special_remotes.mdwn
new file mode 100644
index 0000000000..7d275330c5
--- /dev/null
+++ b/doc/todo/publicurl_config_for_all_special_remotes.mdwn
@@ -0,0 +1,8 @@
+`publicurl` configuration option was added to S3 special remote to facilitate public access to the files deposited to S3 via their HTTP "frontend".  For many remotes (e.g. `rsync`, `directory`, etc) it might happen that the remote location directory is also served by a regular HTTP server. So it sounds very reasonable to enable regular HTTP(/https) access to those files publicly by providing those special remotes with `publicurl` setting so annex could simply try to access those files via http.  In particular relevant for the special remotes with `exporttree=true`.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+[[!tag needsthought]]
+
+> [[done]] by implementing another design, not the one suggested here
+> --[[Joey]]
diff --git a/doc/todo/publicurl_config_for_all_special_remotes/comment_1_58b2ec259bd3d9e368240e459330a738._comment b/doc/todo/publicurl_config_for_all_special_remotes/comment_1_58b2ec259bd3d9e368240e459330a738._comment
new file mode 100644
index 0000000000..e2dd5e77ca
--- /dev/null
+++ b/doc/todo/publicurl_config_for_all_special_remotes/comment_1_58b2ec259bd3d9e368240e459330a738._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2019-01-25T21:34:15Z"
+ content="""
+Maybe, it'll suffice to just register the URL with the built-in web remote (via addurl, or registerurl and setpresentkey)?
+
+"""]]
diff --git a/doc/todo/publicurl_config_for_all_special_remotes/comment_2_d9933855e8521ebed00406a6350837b7._comment b/doc/todo/publicurl_config_for_all_special_remotes/comment_2_d9933855e8521ebed00406a6350837b7._comment
new file mode 100644
index 0000000000..d1be43a8a1
--- /dev/null
+++ b/doc/todo/publicurl_config_for_all_special_remotes/comment_2_d9933855e8521ebed00406a6350837b7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2019-01-26T00:46:03Z"
+ content="""
+Yes, it is possible to register a url per each file as a workaround but it is somewhat  unnecessary and inflexible: if top url changes, all urls will need to be adjusted.
+"""]]
diff --git a/doc/todo/publicurl_config_for_all_special_remotes/comment_3_42ac954b120205650a2a5f03872085c2._comment b/doc/todo/publicurl_config_for_all_special_remotes/comment_3_42ac954b120205650a2a5f03872085c2._comment
new file mode 100644
index 0000000000..41bb7a369c
--- /dev/null
+++ b/doc/todo/publicurl_config_for_all_special_remotes/comment_3_42ac954b120205650a2a5f03872085c2._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-01-29T15:04:06Z"
+ content="""
+I'm not sure how to implement this in git-annex's Remote API.
+retrieveKeyFile/retrieveExport would need to check it and download
+the url, so that would need modifications of those methods of every
+remote that implements this. And it would need to be possible to
+enable the remote in readonly mode.
+
+It might be possible to use a mixin to modify a Remote to support this?
+"""]]
diff --git a/doc/todo/publicurl_config_for_all_special_remotes/comment_4_3c144c0323d49f7ca2d6b9971ad3160a._comment b/doc/todo/publicurl_config_for_all_special_remotes/comment_4_3c144c0323d49f7ca2d6b9971ad3160a._comment
new file mode 100644
index 0000000000..f9e23994b0
--- /dev/null
+++ b/doc/todo/publicurl_config_for_all_special_remotes/comment_4_3c144c0323d49f7ca2d6b9971ad3160a._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-01-30T15:19:55Z"
+ content="""
+This will need the remote to provide a function `Key -> FilePath`,
+in order to support whatever hash directories or filename mangling the
+remote does. It might be better to generalize the function to
+`Url -> Key -> Url` where the first url is the publicurl value.
+(When exporttree=true, the function is probably not needed.)
+
+To support that function in external special remotes, the protocol would
+need to be extended. Hmm, that means that, in order to get a file, the
+external program would need to be installed, even though the actual file
+download only needs http. Contrast with the current readonly mode that
+doesn't need the external program to be installed since the url is recorded
+on the git-annex branch.
+
+I think that the only built-in remotes that would make sense to support
+this are rsync, directory[1], and webdav. s3 already supports it but could
+be refactored. git remotes already support http access which is effectively
+the same result, and git-lfs already supports unauthed downloads, assuming
+the server allows it.
+
+[1] a bit problimatic because old versions used a different
+hash directory than current versions, so unless it can return two urls,
+things stored with an old version won't be accessible
+"""]]
diff --git a/doc/todo/publicurl_config_for_all_special_remotes/comment_5_1d9186506f8f44415706f3b4394c9008._comment b/doc/todo/publicurl_config_for_all_special_remotes/comment_5_1d9186506f8f44415706f3b4394c9008._comment
new file mode 100644
index 0000000000..aef3f989d9
--- /dev/null
+++ b/doc/todo/publicurl_config_for_all_special_remotes/comment_5_1d9186506f8f44415706f3b4394c9008._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-07-01T18:59:48Z"
+ content="""
+[[generic_readonly_http_remote]] if implemented would accomplish the same
+thing as this todo.
+
+The advantage to that idea is, it doesn't need modifications be made to every
+special remote that might end up exposed over http. As long as the special
+remote is not *too* special about how it mangles keys into paths, it
+can work for a lot of special remotes.
+
+The directory special remote is a good example.. It would be weird for that to
+have http-specific configuration and complications.
+
+And, that approach doesn't complicate the external special remote protocol,
+and avoids the problems discussed in comment #4.
+
+So, I'm inclined to that approach over this one.
+"""]]
diff --git a/doc/todo/publicurl_config_for_all_special_remotes/comment_6_7f027aa4b5b495a93aee3cd3417862a8._comment b/doc/todo/publicurl_config_for_all_special_remotes/comment_6_7f027aa4b5b495a93aee3cd3417862a8._comment
new file mode 100644
index 0000000000..a38c50478f
--- /dev/null
+++ b/doc/todo/publicurl_config_for_all_special_remotes/comment_6_7f027aa4b5b495a93aee3cd3417862a8._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-09-01T19:09:30Z"
+ content="""
+I've implemented the http special remote, that can be combined with other
+special remotes to access them using anonymous http.
+
+I think that probably addresses this todo well enough to close it.
+(Although I didn't get around to
+[[todo/make_http_special_remote_support_exporttree_remotes]] yet, and this
+todo mentions supporting exporttree. Should be easy to add later though.)
+
+There are probably some special remotes that are unusual enough that the
+http special remote can't support them, which it would make sense to add a
+publicurl= config to, like S3 has. (Although I think S3 itself could now be
+used with the http special remote so its option is vestigal now.)
+
+I guess that publicurl= config would best be added to the individual
+special remote, so it doesn't need any particular support in git-annex to
+add it.
+"""]]
diff --git a/doc/todo/publicurl_config_for_all_special_remotes/comment_7_c35df3621c7b6a1b518787fdc8967ee7._comment b/doc/todo/publicurl_config_for_all_special_remotes/comment_7_c35df3621c7b6a1b518787fdc8967ee7._comment
new file mode 100644
index 0000000000..15f30598a9
--- /dev/null
+++ b/doc/todo/publicurl_config_for_all_special_remotes/comment_7_c35df3621c7b6a1b518787fdc8967ee7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2020-09-01T20:49:59Z"
+ content="""
+Awesome, Thank you!  I [still](https://git-annex.branchable.com/todo/generic_readonly_http_remote/#comment-f6e076370814fcfab3a4d203a1adf326) think that it could be named more generically than `http` (e.g. probably could remap to public `rsync://`, `ftp://` or `s3://` to which git-annex knows how to \"talk to\") even if ATM supporting only `http/https`, but I guess time will show if that would be needed.
+"""]]
diff --git a/doc/todo/read-only_removable_drives.mdwn b/doc/todo/read-only_removable_drives.mdwn
new file mode 100644
index 0000000000..9dfc3569c0
--- /dev/null
+++ b/doc/todo/read-only_removable_drives.mdwn
@@ -0,0 +1,17 @@
+Here's yet another weird use case. I have a ext3 external drive for storing media that i brought to the office. Naturally, all files on the drive are owned by my desktop user (uid = 1000). In the office, my userid is different (say 1001), so git-annex doesn't see the removable drive at all (which is a little confusing). But even if i try to add the repo on the drive as an external repo, it says it can't write to it (which is true).
+
+I would expect it to at least be able to leech the files off of it.
+
+Otherwise, I would welcome advice on how to fix this problem without doing a `sudo chown -R` every time i plug this drive somewhere ... --[[anarcat]]
+
+> Workaround: `sudo setfacl -R -m u:anarcat:rwx /media/foo/annex`
+
+Note: this seems like there was at least one dupe opened about this in [[bugs/annex_get_fails_from_read-only_filesystem]].
+
+I concede that this may refer to many different issues, so here's a short inventory of issues with readonly repositories:
+
+* trying to add an external readonly drive through the webapp: not detected: see [[todo/show_readonly_removable_drives_in_the_webapp]]
+* trying to add an external readonly drive through the commandline: fails to sync? - couldn't reproduce locally, i will need to go back to that machine for more tests :(
+* trying to add a ssh readonly remote through the webapp: fails to sync and considers the remote "git-only" (which also fails) - couldn't reproduce locally either - maybe this is related to the upgrade option in [[bugs/annex_get_fails_from_read-only_filesystem/]] 
+* trying to add a local readonly remote through the webapp: fails to add, see [[bugs/cannot_add_local_readonly_repo_through_the_webapp]]
+* failing to sync with a readonly remote of a different version: still an issue, see [[bugs/annex_get_fails_from_read-only_filesystem/]] - at least content should be syncable even if the upgrade fails (think of failure conditions such as broken hard drives that are put in readonly mode or ddrescue'd disk images)
diff --git a/doc/todo/read-only_removable_drives/comment_1_979455e3694ae2403134ed6fa2add2fa._comment b/doc/todo/read-only_removable_drives/comment_1_979455e3694ae2403134ed6fa2add2fa._comment
new file mode 100644
index 0000000000..ac98d68450
--- /dev/null
+++ b/doc/todo/read-only_removable_drives/comment_1_979455e3694ae2403134ed6fa2add2fa._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-05-16T18:10:28Z"
+ content="""
+The assistant ignores drives that it cannot write to. This is a very good heuristic to avoid listing every special device in linux, OSX, etc as possible removable drives. I don't think it makes sense for the assistant to try to handle this use case.
+
+Is there some problem using git-annex at the command line with a remote that is read-only? I don't see any problem in my tests.
+
+<pre>
+joey@darkstar:~/tmp/r>git annex drop
+drop foo ok
+(Recording state in git...)
+joey@darkstar:~/tmp/r>ls -ld ../readonly
+drwxr-xr-x 3 root root 4096 May 16 14:08 ../readonly/
+joey@darkstar:~/tmp/r>git annex get --from readonly
+get foo (from readonly...) ok
+(Recording state in git...)
+</pre>
+"""]]
diff --git a/doc/todo/read-only_removable_drives/comment_2_08fced29b86b21f63bb0868747227e08._comment b/doc/todo/read-only_removable_drives/comment_2_08fced29b86b21f63bb0868747227e08._comment
new file mode 100644
index 0000000000..e89e4a5467
--- /dev/null
+++ b/doc/todo/read-only_removable_drives/comment_2_08fced29b86b21f63bb0868747227e08._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="this also affects ssh remotes"
+ date="2014-10-05T15:26:52Z"
+ content="""
+so i tried another experiment today: i tried to allow access to a remote user to my /srv/foo annex. the annex is writable by me, but not by the user, yet i was expecting the user to be able to sync with it. not push, mind you, but at least pull: in a \"git-only\" scenario, that would be perfectly possible. yet the assistant freaks out because it can't run git-annex on the repo because of a write failure on some pack files, and downgrades the repository to a \"git-only\" repo, which is also inaccurate: it can't sync the metadata either...
+
+i would have expected this repository to be marked as \"readonly\" and the user be capable of fetching new changes automatically from the \"central repo\".
+
+maybe that's the essence of the todo here... --[[anarcat]]
+"""]]
diff --git a/doc/todo/read-only_removable_drives/comment_3_2675e211c7bd248b7f7c1bbc6fd46679._comment b/doc/todo/read-only_removable_drives/comment_3_2675e211c7bd248b7f7c1bbc6fd46679._comment
new file mode 100644
index 0000000000..3ce119e67c
--- /dev/null
+++ b/doc/todo/read-only_removable_drives/comment_3_2675e211c7bd248b7f7c1bbc6fd46679._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 3"
+ date="2014-10-06T16:03:04Z"
+ content="""
+Note that I still don't have a test case that reproduces this. I have tried and failed a second time to reproduce the original reported problem.
+
+Also, one issue per bug report tends to result in happier developers.
+"""]]
diff --git a/doc/todo/read-only_removable_drives/comment_4_9e9bc6dd5fa8c4cf7f2511b771bd1bc7._comment b/doc/todo/read-only_removable_drives/comment_4_9e9bc6dd5fa8c4cf7f2511b771bd1bc7._comment
new file mode 100644
index 0000000000..2f79d2f4a7
--- /dev/null
+++ b/doc/todo/read-only_removable_drives/comment_4_9e9bc6dd5fa8c4cf7f2511b771bd1bc7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 4"
+ date="2014-10-06T16:06:52Z"
+ content="""
+Of course, git-annex sync fails when it tries to git push to the removable repo. I don't see that causing any problems in practice.
+"""]]
diff --git a/doc/todo/read-only_removable_drives/comment_5_a693c5744bfc6c33f5605aa9d9c0bfe0._comment b/doc/todo/read-only_removable_drives/comment_5_a693c5744bfc6c33f5605aa9d9c0bfe0._comment
new file mode 100644
index 0000000000..ed24a1054d
--- /dev/null
+++ b/doc/todo/read-only_removable_drives/comment_5_a693c5744bfc6c33f5605aa9d9c0bfe0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 5"
+ date="2014-10-06T16:10:02Z"
+ content="""
+I guess that the actual problem encountered is entirely limited to the webapp, where if the user chooses \"Add another repository\", then enters the path to an existing, read-only repository, and clicks Make Repository, the webapp replies \"Cannot write a repository there.\"
+"""]]
diff --git a/doc/todo/read-only_removable_drives/comment_6_737e3d315f29a4fc61597ce4f9ec6206._comment b/doc/todo/read-only_removable_drives/comment_6_737e3d315f29a4fc61597ce4f9ec6206._comment
new file mode 100644
index 0000000000..de662d9a5e
--- /dev/null
+++ b/doc/todo/read-only_removable_drives/comment_6_737e3d315f29a4fc61597ce4f9ec6206._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="anarcat"
+ ip="70.83.139.100"
+ subject="maybe this should be split up, here are the issues i know about"
+ date="2014-10-06T16:14:36Z"
+ content="""
+well this specific issue is more about how git-annex cannot get files off readonly medium, whether it is webapp or not.
+
+maybe it would be wiser to split this up in separate bug reports, because I had at least three different situations:
+
+* trying to add an external readonly drive through the webapp: not detected
+* trying to add an external readonly drive through the commandline: fails to sync? - to be confirmed
+* trying to add a ssh readonly remote through the webapp: fails to sync and considers the remote \"git-only\" (which also fails)
+
+I would need to try the third case through the commandline.
+
+And then there's the upgrade scenario in [[bugs/annex_get_fails_from_read-only_filesystem/]].
+
+Did i miss anything?
+"""]]
diff --git a/doc/todo/read-only_removable_drives/comment_7_16c8652d38ae57db4ed1860a4733a18b._comment b/doc/todo/read-only_removable_drives/comment_7_16c8652d38ae57db4ed1860a4733a18b._comment
new file mode 100644
index 0000000000..121d6768d3
--- /dev/null
+++ b/doc/todo/read-only_removable_drives/comment_7_16c8652d38ae57db4ed1860a4733a18b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 7"
+ date="2014-10-20T20:04:09Z"
+ content="""
+alright, i documented those issues more distinctively in the summary. hopefully that will clear things up a little. i still need to do some work to reproduce two of those issues, maybe a lot of this is related to the upgrade problem mentionned in [[bugs/annex_get_fails_from_read-only_filesystem/]].
+"""]]
diff --git a/doc/todo/read-only_removable_drives/comment_8_a802e0617c9ef72eb8d3842de99e44ae._comment b/doc/todo/read-only_removable_drives/comment_8_a802e0617c9ef72eb8d3842de99e44ae._comment
new file mode 100644
index 0000000000..f198658894
--- /dev/null
+++ b/doc/todo/read-only_removable_drives/comment_8_a802e0617c9ef72eb8d3842de99e44ae._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2016-02-12T18:08:18Z"
+ content="""
+I've made some changes today, which let files be downloaded from readonly
+repositories (both on local drives and remote, as long as git-annex-shell
+is updated to a version with the changes).
+
+The issues with the webapp probably remain.
+"""]]
diff --git a/doc/todo/record_ETag_when_using_addurl_--fast.mdwn b/doc/todo/record_ETag_when_using_addurl_--fast.mdwn
new file mode 100644
index 0000000000..b15a9a202d
--- /dev/null
+++ b/doc/todo/record_ETag_when_using_addurl_--fast.mdwn
@@ -0,0 +1,3 @@
+Many websites return an Etag in the http response header, indicating the version of the resource.  Could the etag (or a checksum of it) be recorded in the URL- key, the way size is now?  Then e.g. `fsck --from web` could do a stronger check that the same file is still downloadable from the web, and the situation where different remotes have different versions of a file with the same URL- key could be better prevented.
+
+> Closing as this does not seem like a useful idea. [[done]] --[[Joey]]
diff --git a/doc/todo/record_ETag_when_using_addurl_--fast/comment_1_cf15e943ba9405240aecc3dc83b4ef08._comment b/doc/todo/record_ETag_when_using_addurl_--fast/comment_1_cf15e943ba9405240aecc3dc83b4ef08._comment
new file mode 100644
index 0000000000..e00c59fb35
--- /dev/null
+++ b/doc/todo/record_ETag_when_using_addurl_--fast/comment_1_cf15e943ba9405240aecc3dc83b4ef08._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-07-25T16:40:50Z"
+ content="""
+Etags are intended to help http clients with caching. It would
+not be considered much of a problem if a web server only returned the same
+Etag for a little while and then generated a new one later, since clients
+only cache so long anyway. But then git-annex would treat the file as no
+longer present on the website.
+
+Apache uses the inode, size, and mtime for its Etag generation. So just
+moving a website to a different drive would change the Etag.
+"""]]
diff --git a/doc/todo/registerurl_--remote_REMOTE.mdwn b/doc/todo/registerurl_--remote_REMOTE.mdwn
new file mode 100644
index 0000000000..e2fa249138
--- /dev/null
+++ b/doc/todo/registerurl_--remote_REMOTE.mdwn
@@ -0,0 +1,7 @@
+ATM `registerurl` would consider external special remotes via CLAIMURL and might then associate that URL with a specific remote.
+If a remote can handle some urls (e.g. regular http) which annex can handle as well, but user wants to not associate url with that special remote, having this dedicated option would be great to have.
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/registerurl_--remote_REMOTE/comment_1_9d99569edd7ee8331626ec9fffeaa1b7._comment b/doc/todo/registerurl_--remote_REMOTE/comment_1_9d99569edd7ee8331626ec9fffeaa1b7._comment
new file mode 100644
index 0000000000..92e64ef9dc
--- /dev/null
+++ b/doc/todo/registerurl_--remote_REMOTE/comment_1_9d99569edd7ee8331626ec9fffeaa1b7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-04-04T17:54:11Z"
+ content="""
+Note that git-annex does not store urls associated with any particular
+remote. The url log is simply a list of urls. This was probably not a great
+design choice, but we're essentially stuck with it.
+
+So, `registerurl` can update the location tracking (which it currently does
+only for the web special remote and not others). But an association
+between url and special remote cannot be recorded by it.
+"""]]
diff --git a/doc/todo/registerurl_--remote_REMOTE/comment_2_59f6ff108c40b4597a7a870fafdaabc2._comment b/doc/todo/registerurl_--remote_REMOTE/comment_2_59f6ff108c40b4597a7a870fafdaabc2._comment
new file mode 100644
index 0000000000..e36648670f
--- /dev/null
+++ b/doc/todo/registerurl_--remote_REMOTE/comment_2_59f6ff108c40b4597a7a870fafdaabc2._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2023-04-05T01:03:38Z"
+ content="""
+`registerurl`, besides modifying `.log.web` and adding URLs (with `:` prefix if being claimed by external remote), it also modifies `.log` and registers availability from web remote 
+
+```
+> git annex registerurl --json SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat http://www.oneukrainian.com/tmp/124.dat
+{\"command\":\"registerurl\",\"error-messages\":[],\"file\":null,\"input\":[\"SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat\",\"http://www.oneukrainian.com/tmp/124.dat\"],\"success\":true}
+> git show -p git-annex
+commit 22a29debc107ccdf85fb08161bdfa31f581cedeb (git-annex)
+Author: Yaroslav Halchenko <debian@onerussian.com>
+Date:   Tue Apr 4 20:59:29 2023 -0400
+
+    update
+
+diff --git a/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log b/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log
+index dbe5653..3384a1a 100644
+--- a/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log
++++ b/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log
+@@ -1 +1,2 @@
++1680656369.682872384s 1 00000000-0000-0000-0000-000000000001
+ 1680656369.621247138s 1 56425bae-be83-44d1-bb22-9f37ce9507a5
+diff --git a/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log.web b/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log.web
+new file mode 100644
+index 0000000..022fcec
+--- /dev/null
++++ b/060/68b/SHA256E-s4--ca2ebdf97d7469496b1f4b78958f9dc8447efdcb623953fee7b6996b762f6fff.dat.log.web
+@@ -0,0 +1 @@
++1680656369.682162693s 1 http://www.oneukrainian.com/tmp/124.dat
+
+```
+
+The fact that it doesn't do that currently (but did in the past) for external remotes is currently discussed in [https://git-annex.branchable.com/bugs/registerurl_does_not_register_if_external_remote/](https://git-annex.branchable.com/bugs/registerurl_does_not_register_if_external_remote/)
+
+So, my desire here ATM to be able to say `registerurl --remote web` and get it registered to `web` remote, thus to have web remote listed in .log and url added without `:`.
+"""]]
diff --git a/doc/todo/registerurl_--remote_REMOTE/comment_3_70244d4f7f81b6799cd541ad14b38ee0._comment b/doc/todo/registerurl_--remote_REMOTE/comment_3_70244d4f7f81b6799cd541ad14b38ee0._comment
new file mode 100644
index 0000000000..7c0d396031
--- /dev/null
+++ b/doc/todo/registerurl_--remote_REMOTE/comment_3_70244d4f7f81b6799cd541ad14b38ee0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-04-05T17:46:54Z"
+ content="""
+What it could do is with --remote=foo, check if foo claims the url. If not,
+fail to register the url. The discussion in
+[[bugs/registerurl_does_not_register_if_external_remote]]
+is inclining me toward an option that works like that.
+
+I suppose that --remote=web could, as a special case, force use of the web
+special remote, bypassing any CLAIMURL. `addurl --raw` does the same thing,
+but it makes sense to have a plumbing level way to do that.
+"""]]
diff --git a/doc/todo/registerurl_--remote_REMOTE/comment_4_334ce2eb815d6d8489f9cb00c09b0bd7._comment b/doc/todo/registerurl_--remote_REMOTE/comment_4_334ce2eb815d6d8489f9cb00c09b0bd7._comment
new file mode 100644
index 0000000000..99069ea64e
--- /dev/null
+++ b/doc/todo/registerurl_--remote_REMOTE/comment_4_334ce2eb815d6d8489f9cb00c09b0bd7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-04-05T19:52:38Z"
+ content="""
+Implemented --remote for registerurl and unregisterurl. Including the --remote=web
+special case.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__.mdwn b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__.mdwn
new file mode 100644
index 0000000000..8d4b2887b9
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__.mdwn
@@ -0,0 +1,33 @@
+Tracing "slow performance" of our git-annex'ification of zarr archives in [dandisets](https://github.com/dandi/dandisets/). Initially I thought that may be a [flat directory structure of the journal](https://git-annex.branchable.com/todo/more___34__filesystem_efficient__34___journalling__63___/) is a culprit but Joey showed that it is unlikely the case.
+
+I think that part of the heavy IO/CPU of `git-annex registerurl --batch --json --json-error-messages` call comes from the fact that some files in those zarr trees are identical through hierarchy, leading to over 8k URLs to be added for that annex key.  In turn, according to strace, I think that git-annex to update listing of urls for a key first creates a copy of prior version of .web under `othertmp/` and then moves it over under journal location, e.g.
+
+```
+$> grep journal registerurl-3644019.log | head
+3644019 openat(AT_FDCWD, ".git/annex/journal.lck", O_RDWR|O_CREAT, 0666) = 11
+3644019 openat(AT_FDCWD, ".git/annex/journal/5a4_81f_MD5E-s560--82188063b1988362cc3050918f493320.log", O_RDONLY|O_NOCTTY|O_NONBLOCK <unfinished ...>
+3644019 openat(AT_FDCWD, ".git/annex/journal/5a4_81f_MD5E-s560--82188063b1988362cc3050918f493320.log.web", O_RDONLY|O_NOCTTY|O_NONBLOCK <unfinished ...>
+3644019 openat(AT_FDCWD, ".git/annex/journal.lck", O_RDWR|O_CREAT, 0666) = 11
+3644019 openat(AT_FDCWD, ".git/annex/journal/5a4_81f_MD5E-s560--82188063b1988362cc3050918f493320.log.web", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 16
+3644019 mkdir(".git/annex/journal", 0777) = -1 EEXIST (File exists)
+3644019 stat(".git/annex/journal", {st_mode=S_IFDIR|S_ISGID|0755, st_size=24299080, ...}) = 0
+3644019 rename(".git/annex/othertmp/5a4_81f_MD5E-s560--82188063b1988362cc3050918f493320.log.web", ".git/annex/journal/5a4_81f_MD5E-s560--82188063b1988362cc3050918f493320.log.web") = 0
+3644019 openat(AT_FDCWD, ".git/annex/journal.lck", O_RDWR|O_CREAT, 0666) = 11
+3644019 openat(AT_FDCWD, ".git/annex/journal/5a4_81f_MD5E-s560--82188063b1988362cc3050918f493320.log", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 16
+```
+ 
+and that file/key eventually grows into 1MB in size. So for 8k URLs it would take about 4000MBs = 4GB of write IO to produce such growing file while adding those 8k URLs.
+
+Full strace output for those few seconds could be found [here](http://www.onerussian.com/tmp/registerurl-3644019.log).
+
+I wonder how we/git-annex could improve its performance for such cases?
+
+May be changes to those .web files in journal could be done "in place" by appending to those files, without needing to copy/move?
+
+may be there is a way to "stagger" those --batch additions somehow so all thousands of URLs are added in a single "run" thus having a single "copy/move" and locking/stat'ing syscalls?
+
+PS More information could be found at [dandisets/issues/225](https://github.com/dandi/dandisets/issues/225 )
+
+[[!tag projects/dandi]]
+
+> [[fixed|done]], see my last comment for what you need to do. --[[Joey]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_10_0de07ff7054e7d71a6cf1d08051664f9._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_10_0de07ff7054e7d71a6cf1d08051664f9._comment
new file mode 100644
index 0000000000..4fd29a617e
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_10_0de07ff7054e7d71a6cf1d08051664f9._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2022-07-15T15:50:00Z"
+ content="""
+Ran `git-annex whereis --quiet` over 10000 annexed files. With journal
+locking on read, it took 11.71 seconds. Without journal locking, 
+it took 11.73 seconds. No speed difference.
+
+And strace showed why: This only opened the journal directory once, noticed
+it was empty, and skipped ever trying to read any files from it! If there
+are files, it stages them and still manages to not need to read from the
+journal after that. Nice optimisation from earlier this year. :-)
+
+I thought that --batch commands would still check the journal files,
+but surprisingly, they don't seem to. That was a bug:
+[[bugs/batch_commands_miss_journalled_changes_made_while_running]]
+
+After fixing that, I benchmarked feeding 10000 filenames into `git-annex
+whereis --batch`. With journal locking on read, it took 18.43 seconds. 
+Without journal locking, it took 17.22 seconds. Before that bug fix, 
+with or without journal locking, it took 16.59 seconds.
+
+So, if the slow down caused by journal locking on read is a problem for
+anyone, a mode could be added that makes --batch not check the journal for
+changes made after the command started. That would make it run as fast as
+before that bug fix.
+
+There might be other commands than --batch commands, that both read and
+write git-annex branch data, and so end up checking the journal on every
+read, since writing invalidates the above optimisation. Not sure what
+commands that would be, maybe `git-annex drop`? Anyway, such commands are
+probably doing more expensive things than locking the journal; they're not
+query commands.
+
+That makes me ok with adding the locking on read, if needed for append.
+(Or similar added overheads to journal reads.)
+For now, I've committed it to the `append` branch.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_11_b41f6266e341ec05586e6ec32b6cf68a._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_11_b41f6266e341ec05586e6ec32b6cf68a._comment
new file mode 100644
index 0000000000..ed5c575681
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_11_b41f6266e341ec05586e6ec32b6cf68a._comment
@@ -0,0 +1,73 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2022-07-15T17:58:27Z"
+ content="""
+The remaining problem with appending is crash safety. If an append is
+not atomic, a journal file could end up having a truncated line written to
+it.
+
+That seems unlikely, but see the bugzilla page above; it can happen on a
+kill signal at least.
+
+So, can append somehow be made atomic? How about this:
+
+Make `.git/annex/journal-append/` which contains append files,
+that are the same as journal files, but in the process of being appended.
+And make it also contain size files, which contain a number, the size of
+the append file before anything got appended to it.
+
+Then, to append to a journal file:
+
+1. When the journal file exists, and the append file does not,
+   move the journal file to the append file.
+2. When the journal file does not exist and the append file does,
+   truncate it to the size in the size file. (If the size file does not
+   exist, skip truncating.)
+3. When the journal and append file both exist, truncate the append file,
+   and add the journal file's content to what is going to be appended.
+   (This is in case an old git-annex wrote a new value to the
+   journal file, not knowing about the append file.)
+2. Write the current size of the append file to the size file.
+3. Append to the append file.
+4. Move the append file back to the journal file.
+5. Delete the size file.
+
+When reading journalled files, it would need to also check the append
+file, and only read the recorded size. When both the append file and the
+journal file exist, it would read both and combine them. This change would 
+slow down reads slightly, though as seen in comment #10, mostly only for
+--batch commands.
+
+(It may not be necessary to lock on read actually. It can check for the
+append file and read the size file. If a write is happening at the
+same time, the size file may not exist yet, or may have been deleted
+already. In either case, reading the whole append file is ok.
+Should be possible to make this race-safe without locking.)
+
+When staging the journal, it would need to first handle any interrupted
+appends, by checking if any append files exist.
+
+1. Truncate the append file to the value in the size file
+2. Read the value of the file from the branch.
+3. Append the value of the file from the branch to the append file.
+   (This is to handle a case with old git-annex having written
+   divergent data to the branch, see below.)
+4. Move the append file back to the journal.
+5. Delete the size file.
+
+----
+
+When a new git-annex is doing an append and an old git-annex is also in use,
+the old git-annex will not see files in the journal that are in the process
+of being appended to. So it might use out of date information for queries.
+When it's making a write, it always did first read with the journal locked,
+so it will block until the append is complete. So it will not use out of
+date information for writes.
+
+Only when something was written to the journal, but not committed to the
+branch, and then an append happened but got interruped will the old
+git-annex miss data. It will not see that data, and might make its own
+divergent changes, that get committed to the branch. The new git-annex
+will need to deal with this when handling interrupted appends.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_12_3994a27f274ef2025300291ff1bce8bb._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_12_3994a27f274ef2025300291ff1bce8bb._comment
new file mode 100644
index 0000000000..db9a6b6a25
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_12_3994a27f274ef2025300291ff1bce8bb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 12"
+ date="2022-07-15T19:33:50Z"
+ content="""
+> It will not see that data, and might make its own divergent changes, that get committed to the branch. 
+
+FWIW, not sure when/if I would use that mode then fearing for introducing some inconsistencies. Or do you see legit use case (like mine) where it should be safe?
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_13_0154b05e0b0edccd8e69657501938d92._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_13_0154b05e0b0edccd8e69657501938d92._comment
new file mode 100644
index 0000000000..7f1b63f7fb
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_13_0154b05e0b0edccd8e69657501938d92._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2022-07-18T18:01:09Z"
+ content="""
+The `append` branch has basic appending implemented, but it's not yet
+done atomically.
+
+For benchmarking, I'm using this command.
+
+	perl -e 'for (1..'$ITER') { print "WORM--foo http://example.com/$_\n" }' | /usr/bin/time git-annex registerurl --batch
+
+ITER=2000  
+Old: 52s  
+Appending:  28s  
+
+ITER=4000  
+Old: 190s  
+Appending:  111s  
+
+
+So an improvement of 50%. But remains nonlinear even when appending,
+because it needs to read the existing log file each time to determine if it
+can append, or if it needs to compact it. (Disk cache didn't work as well
+as I had hoped.)
+
+What this suggests to me is that it would be good to also add a mode that
+blindly appends without compacting. Or, possibly, to blindly append,
+but then compact the journalled file before committing it to the git-annex
+branch.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_14_aafc89e24d5640dad3b8f6134c1ac26b._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_14_aafc89e24d5640dad3b8f6134c1ac26b._comment
new file mode 100644
index 0000000000..e472855d58
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_14_aafc89e24d5640dad3b8f6134c1ac26b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: comment 12"""
+ date="2022-07-18T18:40:20Z"
+ content="""
+@yarikoptic, the new git-annex would resolve the insonsistency the next
+time it ran. Only when annex.alwayscommit=false would there be any time
+window where the old git-annex missed something written by git-annex
+process that ran before the one that got interrupted. This does not seem
+like a large problem.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_15_41ba5600367f6893e8ed0bf01be3d539._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_15_41ba5600367f6893e8ed0bf01be3d539._comment
new file mode 100644
index 0000000000..0953bd9127
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_15_41ba5600367f6893e8ed0bf01be3d539._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2022-07-18T20:53:29Z"
+ content="""
+Added the mode that appends without first reading. Enable with
+`-c annex.alwayscompact=false`. 
+
+Now some real speed on the benchmark!
+
+ITER=2000  
+Appending, annex.alwayscompact=false:  2.6s
+
+ITER=4000  
+Appending, annex.alwayscompact=false:  2.8s
+
+ITER=8000  
+Appending, annex.alwayscompact=false:  3.14s
+
+I think annex.alwayscompact=false will be ok for what you're doing
+in this case. It's probably not a good idea to set it generally,
+although worst case is bloat of the git-annex branch causing slow reads
+from it.
+
+An example of when not to use it is, if you have annex.alwayscommit=false
+and annex.alwayscompact=false, and you run git-annex get followed by
+git-annex drop, the location log will be larger than it needs to be. Which
+does not cause any problem except for slow reads from the git-annex branch,
+and will be cleared up by the first update of that log when
+annex.alwayscompact=true.
+
+Still need to implement the atomic appending.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_15_b120af2367cc3667934c088b496331f6._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_15_b120af2367cc3667934c088b496331f6._comment
new file mode 100644
index 0000000000..880abf666f
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_15_b120af2367cc3667934c088b496331f6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 15"
+ date="2022-07-18T19:23:01Z"
+ content="""
+I was not thinking about interrupts but more about running `whereis` and the `registerurl --batch` at the same time -- i.e. would `whereis` have up-to-date information about the most recent `registerurl` added url?  Although may be in our particular case that particular `whereis + registerurl` would not be used.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_17_fe41f306edfb0ae608dfb3a8f153bcbf._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_17_fe41f306edfb0ae608dfb3a8f153bcbf._comment
new file mode 100644
index 0000000000..e0a004ddba
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_17_fe41f306edfb0ae608dfb3a8f153bcbf._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 17"""
+ date="2022-07-18T20:56:48Z"
+ content="""
+whereis would have up-to-date information, except when it was the old
+git-annex that does not understand atomic appends. Then there would be
+a narrow window, during each atomic append, where it would not see any of the
+changes that registerurl had written to the log file, and would instead see
+an old value from the git-annex branch.
+
+Hmm. Maybe that is a problem. I dunno.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_18_6b4df9d81c523e090b83c56bfdce373a._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_18_6b4df9d81c523e090b83c56bfdce373a._comment
new file mode 100644
index 0000000000..556d08adec
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_18_6b4df9d81c523e090b83c56bfdce373a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 18"""
+ date="2022-07-19T18:28:15Z"
+ content="""
+This could be repository version 11, but there is unfortunately not a way to
+guarantee that an old git-annex process from before the repository upgrade
+is not still running and getting confused. The `v9-v10` upgrade waits an
+entire year to ensure no such processes are left, and a similar wait would
+be needed here.
+
+Still, you could force upgrade the repositories that you need to be fast right
+away, or initialize new repositories at the new repository version. Since
+most people are not hit by this kind of performance problem, waiting a
+while before it's available everywhere is not a problem.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_19_b23a39f88879b3c770e112f9e82c4607._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_19_b23a39f88879b3c770e112f9e82c4607._comment
new file mode 100644
index 0000000000..b5d9b73418
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_19_b23a39f88879b3c770e112f9e82c4607._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2022-07-19T18:38:33Z"
+ content="""
+If we don't need to worry about breaking an old git-annex process, thanks
+to an upgrade process that makes sure there are not any, a simpler and
+faster method for atomic appends is as follows:
+
+On upgrade, add a trailing NUL to all existing journal files.
+
+When writing to a journal file, use a temp file that is renamed into place
+atomically like now, but add a trailing NUL to it.
+
+When appending to a journal file first read the last byte.
+If it's a trailing NUL, write the current size of the journal file to the size
+file. Then rewind back before the NUL and append to there, followed
+by a trailing NUL. Then delete the size file.
+
+On append, if the last byte is not a trailing NUL, read the size file,
+and seek to that size, so discarding a previous partial append. Then
+proceed to append to it, write the trailing NUL, and delete the size file.
+
+When reading from a journal file, discard the trailing NUL. If there is no
+trailing NUL, a partial append has been detected. Get the size from the
+size file, and read only that much of the journal file, to discard the
+partial append.
+
+Reading may not need the journal lock, if it can otherwise recover from
+races with append. Treating an append that is still in progress as an
+interrupted append is fine for the purposes of reading. And
+when there's no trailing NUL and it reads the size
+file, the append may have finished and so deleted the size file. If so,
+retry the read of the journal file, and look again for a trailing NUL.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_1_98cd9e5dd449cbd834f53d97fd5dfc13._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_1_98cd9e5dd449cbd834f53d97fd5dfc13._comment
new file mode 100644
index 0000000000..2d0d6eb3a1
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_1_98cd9e5dd449cbd834f53d97fd5dfc13._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-07-14T15:17:41Z"
+ content="""
+You have not ruled out the flat directory structure being a problem,
+if your system has different performance than mine. It would be good if you
+could try the simple test I showed there to check if reading/writing a file
+to a large directory is indeed a problem.
+
+Anyway, nice observation here; growing such a large log file
+one line at a time with rewrites is of course gonna be slow.
+That would be a nice optimisation target.
+
+(Also the redundant mkdir/stat/etc on every write are not helping
+performance. git-annex never rmdirs the journal, so those should be able to
+easily be eliminated by only doing a mkdir when a write fails due to the
+journal directory not existing.)
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_20_532690bc7b9707aa053814c3e84b1dca._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_20_532690bc7b9707aa053814c3e84b1dca._comment
new file mode 100644
index 0000000000..54cd9daa50
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_20_532690bc7b9707aa053814c3e84b1dca._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 20"
+ date="2022-07-19T21:29:02Z"
+ content="""
+is there some housekeeping command (`annex fsck` or `annex repack`? ;) ) we could run after an extensive `git annex registerurl -c annex.alwayscompact=false ` and friends to potentiall re-compact all the .log etc files in git-annex branch?
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_20_fc54794546e8e14b31aa063d93c328de._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_20_fc54794546e8e14b31aa063d93c328de._comment
new file mode 100644
index 0000000000..9dd0cba938
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_20_fc54794546e8e14b31aa063d93c328de._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 20"""
+ date="2022-07-19T22:03:07Z"
+ content="""
+Oh, even simpler -- let the journal assume that all the files are a series of
+lines. Which they always will be, I'm sure. Then:
+
+When appending to a journal file, first read the last byte.
+If it's not a newline, then seek back to the previous newline, to discard
+a previous interrupted append.
+
+When reading from a journal file, similarly check the last byte and if not a
+newline, discard back to the previous newline.
+
+Reading would not need any locking either. A read that happened while an
+append was in progress and read an incomplete line would discard it.
+
+Old versions of git-annex would not get confused by NULs with this method,
+the format of the branch files is not changed. So it's significantly safer,
+but not fully since old git-annex versions would not deal well with an
+interrupted append. So it would still be good to upgrade the repo version
+in a way that prevents an old git-annex process from lingering around.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_21_953eaa6ca651597897a6c6ad7a259d1d._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_21_953eaa6ca651597897a6c6ad7a259d1d._comment
new file mode 100644
index 0000000000..b417b0a756
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_21_953eaa6ca651597897a6c6ad7a259d1d._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 21"""
+ date="2022-07-20T17:24:25Z"
+ content="""
+I've finished implementing appending.
+
+In order to avoid stacking up a year-long v10-v12 upgrade behind the current 
+v8-v10 upgrade, appending will for now only be done when
+annex.alwayscompact=false. ([[todo/v11_changes]] has been made to remind
+me to revisit this later.)
+
+That config is necessary for optimal speed in your situation anyway.
+
+You should avoid setting annex.alwayscompact=false if there is an older
+git-annex also installed on the machine, that could be run in the
+repository at the same time as a git-annex process that is doing appends.
+Otherwise, you do risk the old process seeing partial/interrupted appends
+and getting confused.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_23_4b576c9c33ff2a322cd832027484606b._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_23_4b576c9c33ff2a322cd832027484606b._comment
new file mode 100644
index 0000000000..e7ef924e9a
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_23_4b576c9c33ff2a322cd832027484606b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 23"""
+ date="2022-07-20T17:40:37Z"
+ content="""
+@yarikoptic let's discuss such a hypothetical command in another todo if
+you turn out to need it.
+
+If you have a way to avoid feeding too much redundant data into git-annex
+registerurl, you won't need it. I guess that the 8k redundant urls would
+not be enough to be a problem, since it would only slow down reading a bit.
+
+If you had a cron job that was adding the same url 8k times every run, so
+accumulating an growing number over time, then such a command would be useful.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_24_fb760c2566b6f37ed7378bbcca5875c5._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_24_fb760c2566b6f37ed7378bbcca5875c5._comment
new file mode 100644
index 0000000000..3621a27538
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_24_fb760c2566b6f37ed7378bbcca5875c5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 24"
+ date="2022-07-21T14:03:56Z"
+ content="""
+Thank you Joey -- we will give it a shot soonish! (may be we should somehow add \"conda\" devel builds to datalad/git-annex repo ;) ). Possibly unnecessary question just for myself to feel better ;) :
+
+> When appending to a journal file, first read the last byte. If it's not a newline, then seek back to the previous newline, to discard a previous interrupted append.
+
+isn't it racy between \"first read the last byte.\" and then \"If\"? i.e. if some process dumps/flushes more into that file interim, wouldn't you potentially end up with some garbled line? (or there is a lock)
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_25_148392f465864f19593de0b1aa56f7f8._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_25_148392f465864f19593de0b1aa56f7f8._comment
new file mode 100644
index 0000000000..393e5dcb44
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_25_148392f465864f19593de0b1aa56f7f8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 25"""
+ date="2022-07-22T15:38:17Z"
+ content="""
+There is a write lock around this, of course..
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_2_a4fce84f5777ed582fa599778835455f._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_2_a4fce84f5777ed582fa599778835455f._comment
new file mode 100644
index 0000000000..9d09c64d4b
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_2_a4fce84f5777ed582fa599778835455f._comment
@@ -0,0 +1,56 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-07-14T15:23:04Z"
+ content="""
+@yoh is your use of registerurl typically going to add all the urls for a
+given key in succession, and then move on to the next key? Or are the keys
+randomly distributed?
+
+It sounds like it's more randomly distributed, if you're walking a tree and
+adding each file you encounter, and some of them have the same content so
+the same key.
+
+But your stace shows repeated writes for the same key, so maybe they bunch
+up? If it was not randomly distributed, a nice optimisation would be for
+registerurl to buffer urls as long as the key is the same, and then do a
+single write for that key of all the urls. But it can't really buffer like
+that if it's randomly distributed; the buffer could use a large amount of
+memory then.
+
+----
+
+Simply appending would be a nice optimisation, but setUrlPresent currently
+compacts the log after adding the new url to it. That handles the case
+where the url was already in the log, so it does not get logged twice.
+Compacting here is not strictly necessary (the log is also compacted when
+its queried), but committing a log file with many copies of the same url
+would slow down later accesses of the log file.
+
+So it needs to check before appending if the url is already in the log
+(with the same or newer vector clock). This would still be worth doing,
+it avoids the repeated rewrites. But there would still be the overhead
+of rereading the file each time.
+
+Hmm... git-annex could cache the last journal file it wrote, and only use
+that cache to check if line it's writing is already in the file before
+appending to the file. Using the cache this way seems like it could avoid
+needing to invalidate the cache when some other process modifies the
+journal file. There are two cases:
+
+1. The other process removes the line that was already in the file, which
+   is being logged a second time. In this case the line stays removed.
+   This is the same as if the other process had waited until after the
+   second time and removed it then, and so I think this is ok.
+2. The other process adds the same line itself. This is unlikely due to
+   vector clocks, but it could happen. In this case, the file gets two
+   copies of the same line, which is a little innefficient but does not
+   change any behavior.
+
+Unfortunately, with random distrubution, as discussed above, that caching
+would not help since git-annex can't cache every log for every key.
+
+Anyway, writes are the more expensive thing, so it's still worth
+implementing appending, even if it still needs to read the log file
+first.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_3_56c313fdcb88e95abaa10647678bc108._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_3_56c313fdcb88e95abaa10647678bc108._comment
new file mode 100644
index 0000000000..fdeb636ab4
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_3_56c313fdcb88e95abaa10647678bc108._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-07-14T16:16:35Z"
+ content="""
+I've optimised away the repeated mkdir of the journal.
+
+Probably not a big win in this particular edge case, but a nice general
+win..
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_4_13c0eecd57ea56bb1e21e130d7343778._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_4_13c0eecd57ea56bb1e21e130d7343778._comment
new file mode 100644
index 0000000000..c6bfc83a6c
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_4_13c0eecd57ea56bb1e21e130d7343778._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2022-07-14T16:50:15Z"
+ content="""
+FWIW, I think (but will check with John) that we can sort additions so that we are adding urls to the same key in a sequence if that would be the only way to gain performance.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_4_52a1fe104856968488b386b701c4a4bd._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_4_52a1fe104856968488b386b701c4a4bd._comment
new file mode 100644
index 0000000000..01138a7ea6
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_4_52a1fe104856968488b386b701c4a4bd._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-07-14T17:07:59Z"
+ content="""
+Writing to the journal is currently atomic. And git-annex does take
+advantage of that atomicity, by not locking the journal when it's reading
+from it in some cases, the most used of which is Annex.Branch.get.
+
+But, it's not guaranteed that an append is atomic. A short enough append
+may be, but how short may vary, and it's not well defined. Here is an
+example of a short write append that gets interrupted in the middle by a
+kill signal: <https://bugzilla.kernel.org/show_bug.cgi?id=55651>
+
+> Unfortunately as far as I can determine, in the POSIX and Linux
+> standards, there is no way to work around this new behavior.
+> There's no way to ensure that some amount of data no matter now small,
+> even just two bytes, are written out to a file as an atomic transfer
+> (either aborted and no bytes written or is completely written out.)
+
+So appending would need more locking of the journal, which would add
+some overhead to everything. And especially would hurt concurrency.
+
+Also, the journal is currently crash-safe. Even if there's a sudden
+power loss, the write either completed or didn't happen. Appending
+would lose that nice property.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_6_29a487203bf620e44c3e9db2d22f5ee3._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_6_29a487203bf620e44c3e9db2d22f5ee3._comment
new file mode 100644
index 0000000000..449c185690
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_6_29a487203bf620e44c3e9db2d22f5ee3._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-07-14T17:45:31Z"
+ content="""
+@yarikoptic ok, please check and, if you can do that, 
+I'll implement the buffering of urls for a key.
+
+It looks like appending is not feasible..
+
+Only other approach I can think of would be to have a switch that makes
+git-annex buffer branch writes in memory, rather than using the journal,
+and commit at the end, or when the buffer got too large.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_7_6bf718a1c6185b6aed0b6d0d5c4c9cf8._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_7_6bf718a1c6185b6aed0b6d0d5c4c9cf8._comment
new file mode 100644
index 0000000000..a1518a6100
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_7_6bf718a1c6185b6aed0b6d0d5c4c9cf8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2022-07-14T19:42:58Z"
+ content="""
+> @yarikoptic ok, please check and, if you can do that, I'll implement the buffering of urls for a key.
+
+[apparently (according to John)](https://github.com/dandi/dandisets/issues/225#issuecomment-1184674717) it would require us to prefetch entire listing of the bucket instead of starting to work on the obtained information as soon as first page comes in. So, \"no free lunch\" again.
+
+Re append: I wonder if it would anyhow be faster, at least for me, if append was done through `cp --reflink=auto` of that file first into `othertmp/`, append there, and then `mv`...   most likely not or not as much as worth it.
+
+Operating (optionally) a journal in memory (if I got \"git-annex buffer branch writes in memory\" correctly) sounds like a possible cool speedup overall but not sure how that could work across multiple git-annex instances. 
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_8_e041fcd11c50d47eada124368a5bb7b5._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_8_e041fcd11c50d47eada124368a5bb7b5._comment
new file mode 100644
index 0000000000..72e9a48acf
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_8_e041fcd11c50d47eada124368a5bb7b5._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-07-14T19:50:30Z"
+ content="""
+I think that CoW and append could indeed speed it up. An append on a CoW
+filesystem should be able to keep the original file without copying it, and
+just add a new block for the append to the other file. I did a quick test
+on btrfs, starting with a 100 mb file, making a cp --reflink, and
+appending to it. All operations were less than 10 ms.
+
+----
+
+The buffering in memory would be while the process was running, then it
+would commit it to the git-annex branch. So if no other process needs to
+see that data while the process is running, you'd be ok.
+"""]]
diff --git a/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_9_dd5a1bdc1cc3ecd6ac68cc83fb2195ed._comment b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_9_dd5a1bdc1cc3ecd6ac68cc83fb2195ed._comment
new file mode 100644
index 0000000000..120e2e1f4c
--- /dev/null
+++ b/doc/todo/registerurl__58___do_changes_in_journal___34__in_place__34____63__/comment_9_dd5a1bdc1cc3ecd6ac68cc83fb2195ed._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-07-15T15:05:32Z"
+ content="""
+Rather than buffering in memory, it could buffer to a temporary journal,
+and merge that with the main journal at the end. That would let it append
+in place without worrying about locking, and memory use would not matter
+either. In the common case, files could just be moved from the temp journal
+to the main journal, which would be cheap.
+
+Same as buffering in memory, this would change the normal behavior where
+other processes can see the changes made by a --batch process while it's
+running. So it would need to be a non-default mode.
+
+I think though, that before implementing any of these things, I should
+first benchmark how much overhead there would be in locking the journal
+around read operations.
+"""]]
diff --git a/doc/todo/reinit_current_repo_to_new_uuid.mdwn b/doc/todo/reinit_current_repo_to_new_uuid.mdwn
new file mode 100644
index 0000000000..faa7810b0a
--- /dev/null
+++ b/doc/todo/reinit_current_repo_to_new_uuid.mdwn
@@ -0,0 +1,3 @@
+If a git-annex repo is copied (e.g. by creating an AWS volume from a snapshot), there is a possibility of different repo copies with the same UUID.  It would help if there was an option to [[`git-annex-reinit`|git-annex-reinit]] that would create a new uuid for the current repo.
+
+[[!tag moreinfo]]
diff --git a/doc/todo/reinit_current_repo_to_new_uuid/comment_1_2274082a0d130127eb2fcc12e3404d08._comment b/doc/todo/reinit_current_repo_to_new_uuid/comment_1_2274082a0d130127eb2fcc12e3404d08._comment
new file mode 100644
index 0000000000..8fbb1ecf6d
--- /dev/null
+++ b/doc/todo/reinit_current_repo_to_new_uuid/comment_1_2274082a0d130127eb2fcc12e3404d08._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-09-16T17:24:35Z"
+ content="""
+You can unset annex.uuid and then re-run `git annex init`.
+Will work ok.
+
+You would probably also want to run `git annex fsck --fast`
+so that any annexed content in the repo gets recorded as being present in
+the new uuid.
+"""]]
diff --git a/doc/todo/reinit_current_repo_to_new_uuid/comment_2_d7f2a6de08a3559a1d76ae8aba5a6702._comment b/doc/todo/reinit_current_repo_to_new_uuid/comment_2_d7f2a6de08a3559a1d76ae8aba5a6702._comment
new file mode 100644
index 0000000000..3a4150e70e
--- /dev/null
+++ b/doc/todo/reinit_current_repo_to_new_uuid/comment_2_d7f2a6de08a3559a1d76ae8aba5a6702._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-10-11T16:23:08Z"
+ content="""
+>You would probably also want to run git annex fsck --fast so that any annexed content in the repo gets recorded as being present in the new uuid
+
+This takes very long on my repo, even with `--fast`.  Maybe, there's a way to make a fast dedicated command for this scenario?  Or, a version of [[sameas|todo/support_multiple_special_remotes_with_same_uuid/]] which represents the fact that all presence info in this repo *up to this timestamp* is same as in old repo, but from that point on this repo is separate?
+"""]]
diff --git a/doc/todo/reinit_current_repo_to_new_uuid/comment_3_94434f7e76df4a25d922eed28ca6b559._comment b/doc/todo/reinit_current_repo_to_new_uuid/comment_3_94434f7e76df4a25d922eed28ca6b559._comment
new file mode 100644
index 0000000000..5c0a85d0c8
--- /dev/null
+++ b/doc/todo/reinit_current_repo_to_new_uuid/comment_3_94434f7e76df4a25d922eed28ca6b559._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-01-30T17:36:09Z"
+ content="""
+I don't want to complicate the location logs with time-dependent sameas
+hacks.
+
+Is this repo that's been copied a special remote? fsck --fast --from would
+then not be very fast since it has to talk to the special remote. A
+dedicated command could be faster than that.
+
+If the repo is a git-annex repo though, I'd expect git annex fsck --fast 
+to be nearly optimal, the only extra work it does over such a dedicated
+command, I think, is a stat of the object file to check if it's present.
+"""]]
diff --git a/doc/todo/reinit_current_repo_to_new_uuid/comment_4_9d2b98c15d78781f943f0f2ddf775706._comment b/doc/todo/reinit_current_repo_to_new_uuid/comment_4_9d2b98c15d78781f943f0f2ddf775706._comment
new file mode 100644
index 0000000000..166df8e01e
--- /dev/null
+++ b/doc/todo/reinit_current_repo_to_new_uuid/comment_4_9d2b98c15d78781f943f0f2ddf775706._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-01-30T19:21:00Z"
+ content="""
+See [[todo/reinit_should_work_without_arguments]] for another argument for
+the same thing.
+"""]]
diff --git a/doc/todo/remote-ready-command.mdwn b/doc/todo/remote-ready-command.mdwn
new file mode 100644
index 0000000000..50873d5524
--- /dev/null
+++ b/doc/todo/remote-ready-command.mdwn
@@ -0,0 +1,21 @@
+I did some searching and couldn't find documentation of anything like this, but let me know if I missed it.
+
+I have a remote for git-annex that can get overwhelmed if I try to upload too many files at once.  Specifically in this case, the remote is the Keybase Filesystem (KBFS).  When saving files to KBFS, the files are encrypted and saved to the local disk, and then uploaded in the background.  Currently, when I do `git annex sync --content`, git-annex tries to transfer all my files to the KBFS remote, which can quickly fill up the queue.  (I have run into bugs in Keybase that cause uploads to stop, but it'd still be useful to ensure I'm not filling up the queue, if for no other reason than to save disk space.)
+
+I've created a script that allows me to wait until the queue is empty [here](https://github.com/501st-alpha1/scott-script/blob/master/kbfs-status).
+
+I would like to be able to set a config option, e.g. `remote.kbfs.annex-remote-ready-command` that will check whether the remote is ready for more files.  git-annex could either query the command regularly until it returns 0, or it could call it once and I could handle the sleeping and retrying in the script.
+
+My current workaround is something like:
+
+```
+git annex find . --in here --and --not --in kbfs | while read filename
+  do
+    kbfs-status wait
+    git annex copy --to kbfs "$filename"
+  done
+```
+
+but this means that every `git annex copy` command creates a new commit per file transferred, rather than a single commit at the end of the transfer.  This may not seem like a big deal, but multiplying that over hundreds of files, it adds up to quite a bit of wasted disk space.  (I'll also be looking into ways to squash or prune such commits, but it'd be nice to not have to do that.)
+
+[[!tag confirmed needsthought]]
diff --git a/doc/todo/remote-ready-command/comment_1_55cbea73adb94e85fc2e2252d6f2f03c._comment b/doc/todo/remote-ready-command/comment_1_55cbea73adb94e85fc2e2252d6f2f03c._comment
new file mode 100644
index 0000000000..1fa5a0d0c5
--- /dev/null
+++ b/doc/todo/remote-ready-command/comment_1_55cbea73adb94e85fc2e2252d6f2f03c._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-09-13T22:15:03Z"
+ content="""
+The command that blocks until the remote is ready sounds like a pretty good
+idea.
+
+I wonder, what about downloads from the remote, those could also overload
+some remote.
+
+Is your KBFS remote an external special remote, or are you just using a
+directory special remote on that filesystem? If it were an external special
+remote, you could just make it delay until ready when it receives a
+TRANSFER request.
+
+(BTW, the solution to each git-annex copy creating a git-annex branch
+commit is annex.alwayscommit=false. Or perhaps usng --batch to drive a
+single copy command.)
+"""]]
diff --git a/doc/todo/remote-ready-command/comment_2_0e79b93a9c614a259b9a7d7c1f6cb6dc._comment b/doc/todo/remote-ready-command/comment_2_0e79b93a9c614a259b9a7d7c1f6cb6dc._comment
new file mode 100644
index 0000000000..b2882e1099
--- /dev/null
+++ b/doc/todo/remote-ready-command/comment_2_0e79b93a9c614a259b9a7d7c1f6cb6dc._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="forums+git-annex@d2ec818a5e37440c45fa5f3cbd82fe5110b32020"
+ nickname="forums+git-annex"
+ avatar="http://cdn.libravatar.org/avatar/b6fde94dbf127b822f7b6109399d50c9"
+ subject="comment 2"
+ date="2019-09-13T23:17:37Z"
+ content="""
+> I wonder, what about downloads from the remote, those could also overload some remote.
+
+That is a good point, but it's not needed for my use case; KBFS hasn't had any trouble so far keeping up with reading data, only with writing.
+
+> Is your KBFS remote an external special remote, or are you just using a directory special remote on that filesystem? If it were an external special remote, you could just make it delay until ready when it receives a TRANSFER request.
+
+I originally had a directory special remote pointing to the FUSE-mounted KBFS, but I was having some issues with that, so I switched to an rsync special remote (also pointing to FUSE-mounted KBFS).
+
+> (BTW, the solution to each git-annex copy creating a git-annex branch commit is annex.alwayscommit=false. Or perhaps usng --batch to drive a single copy command.)
+
+Awesome, looks like either of those would be better workarounds than I have right now.  Thanks!
+"""]]
diff --git a/doc/todo/remove_legacy_import_directory_interface.mdwn b/doc/todo/remove_legacy_import_directory_interface.mdwn
new file mode 100644
index 0000000000..f1439db07f
--- /dev/null
+++ b/doc/todo/remove_legacy_import_directory_interface.mdwn
@@ -0,0 +1,148 @@
+The old `git annex import /dir` interface should be removed, in favor of
+the new import from special remote interface, which can be used with a
+directory special remote to do the same kind of operation.
+
+There have always been complaints about the old interface being surprising
+and/or not doing quite what some users want.
+Tried to find a principled way to address some of that with the "duplicate"
+options, but users just complain they're confusing (which they certianly
+are) and don't quite do what they want.
+
+The fundamental mistake that the old interface made is it conflated
+copying content into the repository, deleting content from the directory, 
+and updating the working tree. The new interface decouples all 3,
+only doing the first, and updating a tracking branch. The user is then free
+to merge the tracking branch as-is, or otherwise modify before merging.
+There are some options to manipulate the tracking branch in commonly
+wanted ways, which just boil down do git branch manipulation. Less common
+desires can be handled using all of git's facilities. As for deleting from
+the directory, that's an export of a branch, which can just be an empty
+branch if they want to delete everything, or again they can use all of git
+to construct the branch with the changes they desire.
+
+So while it's not been used as much as the old interface, I think the new
+interface will be much more flexible to the varied needs of users. What's
+less clear is if it can well support every way that the old interface can
+be used.
+
+Of course the first pain point is that the user has to set up a directory
+special remote. Which may be annoying if they are importing from a variety
+of different directories ad-hoc.
+
+Another likely pain point is ad-hoc importing of individual files or
+files matched by wildcard. The new interface is much more about importing
+whole trees, perhaps configured by preferred content settings
+
+> This is now addressed; `--fast` import from directory special remotes
+> followed by `git-annex get` of the files that are wanted. --[[Joey]]
+
+>> By `--fast` do you actually mean `--no-content` because I can't
+>> seem to find `--fast` documented in the manual page of [[git-annex-import]]?
+>> Otherwise, what would a `--fast` operation mean in this context? --[[jkniiv]]
+
+>>> Err, yes, I meant `--no-content`. --[[Joey]]
+
+Another pain point is that to remove files from an export, 
+the user has to create trees that lack the files they want to remove.
+[[drop_from_export_remote]] will resolve that.
+
+One approach would be to make the old interface be implemented using the
+new interface, and paper over the cracks, by eg setting up a directory
+special remote automatically.
+
+Or, the old interface could warn when used, linking to some documentation
+about how to accomplish the same tasks with the new interface.
+
+Either could be done incrementally, eg start with the most common import
+cases, convert to the new interface, and keep others using the old
+interface.
+
+--[[Joey]]
+
+> Just a small plea. 🙏
+> I'd rather see the the old functionality spared, although in a gutted
+> form as a command called `git-annex-ingest` (as the name was suggested by
+> [[Ilya_Shlyakhter]] in [[change git-annex-import not to delete original files by default]]).
+> It would have none of the presumably confusing `--*duplicate*` options.
+> It would still *move* files into the annex thus saving a lot of disk space
+> when you're in a tight spot; as I see it for instance the "import with no options"
+> case as suggested below would pretty much double the disk space
+> requirements during the import. Also ingesting/importing huge files
+> by moving instead of copying them into the annex saves a lot of time, too.
+> --[[jkniiv]]
+
+Let's consider the cases:
+
+## import with no options
+
+This deletes all files from the directory. So, the equivilant would be:
+
+    git-annex import master --from directory
+    git merge directory/master
+    git-annex export $emptytree --to directory
+
+Actually the git merge is not quite right because on subseqent runs, that
+would merge the empty tree, so deleting from master the files imported
+before. So what's really needed is to diff from the empty tree to
+directory/master, and create a tree that has all new/changed files, and
+merge that into master. Which is something git-annex could pretty easily
+do, although so could a simple script.
+
+## import --duplicate
+
+This is the simplest one, it's just:
+
+    git-annex import master --from directory
+    git merge directory/master
+
+## import --deduplicate
+
+This needs to deletes duplicate files from the special remote, and import
+the other files. The easiest way to do that seems to be to first
+implement [[drop_from_export_remote]]. That will allow first an import
+--from --fast, followed by iterating over the new/changed files in the import,
+and dropping any that use keys whose content is present anywhere other
+than in the directory special remote.
+
+And following that, the same kind of creation of a tree that has all
+(remaining) new/changed files, and mergeing that into mater.
+
+## import --skip-duplicates
+
+This will be very similar in implementation to --deduplicate. But avoid
+dropping any files from the directory special remote. Just build a tree
+of files that are new/changed and whose content is not present anywhere
+else, and merge that.
+
+## import --clean-duplicates
+
+    git-annex import master --from directory
+
+Followed by interating over the new/changed files in the import, and
+if they have content anywhere else, dropping from the directory
+special remote. Needs [[drop_from_export_remote]] to be implemented.
+
+## import --reinject-duplicates
+
+This takes care of most of it:
+
+    git-annex import master --from directory
+
+Then all that's needed is to iterate over new/changed files, and filter out
+any that use a key that is present anywhere else. Create a tree from that,
+and merge it into master.
+
+## import --include= (and other file matching options)
+
+Using these options will add another pass over the imported tree,
+that filters out files that don't match.
+
+## --force
+
+This makes existing files be overwritten by imported files. But with
+import tree, there's a tree that gets merged by git, and so regular git
+conflict handling can be used. Which is a better interface than just always
+overwriting. If desired though, this could be implemented by merging
+with the "theirs" conflict resolution strategy.
+
+[[!tag confirmed]]
diff --git a/doc/todo/remove_legacy_import_directory_interface/comment_1_335ab41b3539f605ace1830577794913._comment b/doc/todo/remove_legacy_import_directory_interface/comment_1_335ab41b3539f605ace1830577794913._comment
new file mode 100644
index 0000000000..c8bf5475d1
--- /dev/null
+++ b/doc/todo/remove_legacy_import_directory_interface/comment_1_335ab41b3539f605ace1830577794913._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 1"
+ date="2023-06-24T22:23:09Z"
+ content="""
+@Joey Please, I'd rather see the legacy import functionality still *saved* as a sub-command
+that would have a new name than deleted altogether. You could de-emphasize this command
+in the documentation and rather consider it like a plumbing command on the level of `git-annex-reinject`.
+See my inline comment for further justification.
+"""]]
diff --git a/doc/todo/report_PID___40__and_may_be_failure_details__63____41___in___34__process_done__34___debug_messages.mdwn b/doc/todo/report_PID___40__and_may_be_failure_details__63____41___in___34__process_done__34___debug_messages.mdwn
new file mode 100644
index 0000000000..4ef9396ef4
--- /dev/null
+++ b/doc/todo/report_PID___40__and_may_be_failure_details__63____41___in___34__process_done__34___debug_messages.mdwn
@@ -0,0 +1,50 @@
+With a recent [overhaul of config management in datalad](https://github.com/datalad/datalad/pull/4829) we got some weird inability to properly finish batched `annex addurl` processes... We tried but could not figure it out, and neither had come up with a minimal reproducer so it was not reported against git-annex yet.  We just decided to let those annex processes be and not wait for them to finish, and they eventually do.
+
+While using that code and debugging other issues, I looked into stderr output (redirected to a file) which collects debug output from that git-annex and underlying datalad external special remote, and it reports at the end (`| ` prefix is added by our logger; copy pasting from GNU screen, some oddities with formatting etc might be present):
+
+```
+| [2020-09-23 08:25:27.029200973] Claiming url 's3://NDAR_Central_3/submission_23318/derivatives/abcd-hcp-pipeline/sub-SENSORED/ses-baselineYear1Arm1/anat/sub-SENSORED_ses-baselineYear1Arm1_space-fsLR32k_myelinmap.dscalar.nii'
+| [2020-09-23 08:25:27.029300065] /mnt/scrap/tmp/abcd/datalad/venvs/dev3/bin/git-annex-remote-datalad[1] --> CLAIMURL-SUCCESS
+| [2020-09-23 08:25:27.029415237] /mnt/scrap/tmp/abcd/datalad/venvs/dev3/bin/git-annex-remote-datalad[1] <-- CHECKURL s3://NDAR_Central_3/submission_23318/derivatives/abcd-hcp-pipeline/sub-SENSORED/ses-baselineYear1Arm1/anat/sub-SENSORED_ses-baselineYear1Arm1_space-fsLR32k_myelinmap.dscalar.nii
+| Level 4:datalad.customremotes:Received ['CHECKURL', 's3://NDAR_Central_3/submission_23318/derivatives/abcd-hcp-pipeline/sub-SENSORED/ses-baselineYear1Arm1/anat/sub-SENSORED_ses-baselineYear1Arm1_space-fsLR32k_myelinmap.dscalar.nii']
+| DEBUG:datalad.downloaders.providers:Returning provider Provider(authenticator=<<S3Authenticato++56 chars++com)>>, credential=<<NDA_S3(name='N++40 chars++'>>)>>, name='NDA', url_res=<<['s3://(ndar_c++27 chars++*)']>>) for url s3://NDAR_Central_3/submission_23318/derivatives/abcd-hcp-pipeline/sub-SENSORED/ses-baselineYear1Arm1/anat/sub-SENSORED_ses-baselineYear1Arm1_space-fsLR32k_myelinmap.dscalar.nii
+| DEBUG:datalad.downloaders:Acquiring a currently existing lock to establish download session. If stalls - check which process holds b'/home/yoh/.cache/datalad/locks/downloader-auth.lck'
+| DEBUG:datalad.downloaders.credentials:Credential NDA:1 will expire in 11.58h
+| DEBUG:datalad.s3:S3 session: Reusing previous connection to bucket NDAR_Central_3
+| Level 5:datalad.downloaders:Calling out into <bound method BaseDownloader._get_status of S3Downloader(authenticator=<<S3Authenticato++56 chars++com)>>, credential=<<NDA_S3(name='N++40 chars++'>>)>>)> for s3://NDAR_Central_3/submission_23318/derivatives/abcd-hcp-pipeline/sub-SENSORED/ses-baselineYear1Arm1/anat/sub-SENSORED_ses-baselineYear1Arm1_space-fsLR32k_myelinmap.dscalar.nii
+| Level 3:datalad.downloaders:_fetch('s3://NDAR_Central_3/submission_23318/derivatives/abcd-hcp-pipeline/sub-SENSORED/ses-baselineYear1Arm1/anat/sub-SENSORED_ses-baselineYear1Arm1_space-fsLR32k_myelinmap.dscalar.nii', cache=False, size=0, allow_redirects=True)
+| DEBUG:datalad.downloaders.credentials:Credential NDA:1 will expire in 11.58h
+| Level 4:datalad.customremotes:Sending 'CHECKURL-CONTENTS 583456 submission_23318/derivatives/abcd-hcp-pipeline/sub-SENSORED/ses-baselineYear1Arm1/anat/sub-SENSORED_ses-baselineYear1Arm1_space-fsLR32k_myelinmap.dscalar.nii'
+| [2020-09-23 08:25:27.075528502] /mnt/scrap/tmp/abcd/datalad/venvs/dev3/bin/git-annex-remote-datalad[1] --> CHECKURL-CONTENTS 583456 submission_23318/derivatives/abcd-hcp-pipeline/sub-SENSORED/ses-baselineYear1Arm1/anat/sub-SENSORED_ses-baselineYear1Arm1_space-fsLR32k_myelinmap.dscalar.nii
+| [2020-09-23 08:25:45.175701347] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"]
+| [2020-09-23 08:25:59.100380237] process done ExitSuccess
+| [2020-09-23 08:25:59.230028383] process done ExitFailure 120
+| [2020-09-23 08:25:59.856175419] process done ExitSuccess
+| [2020-09-23 08:25:59.857000087] process done ExitSuccess
+| [2020-09-23 08:25:59.876480876] process done ExitFailure 1
+```
+
+<details>
+<summary>and just FTR here is log from the top level datalad process which invoked that addurls --batch process</summary>
+
+```
+2020-09-23 08:25:44,106 datalad.plugin.addurls {3367135}[DEBUG] from datalad; to sub-SENSORED/ses-baselineYear1Arm1/anat/sub-SENSORED_ses-baselineYear1Arm1_space-fsLR32k_myelinmap.dscalar.nii [addurl(/mnt/scrap/tmp/abcd/testds-fast-full2/derivatives/abcd-hcp-pipeline/sub-SENSORED/ses-baselineYear1Arm1/anat/sub-SENSORED_ses-baselineYear1Arm1_space-fsLR32k_myelinmap.dscalar.nii)]
+2020-09-23 08:25:44,610 datalad.cmd     {3367135}[DEBUG] Closing stderr of <subprocess.Popen object at 0x7f3a5e597c18>
+2020-09-23 08:25:44,611 datalad.cmd     {3367135}[DEBUG] Closing stdin of <subprocess.Popen object at 0x7f3a5e597c18> and waiting process to finish
+2020-09-23 08:25:47,656 datalad.utils   {3367135}[WARNING] Caught Command '['git', 'annex', 'addurl', '--fast', '--with-files', '--json', '--json-error-messages', '--batch', '--debug']' timed out after 3.0 seconds [subprocess.py:_wait:1616] on trial #1. Sleeping 1.000000 and retrying
+2020-09-23 08:25:51,657 datalad.utils   {3367135}[WARNING] Caught Command '['git', 'annex', 'addurl', '--fast', '--with-files', '--json', '--json-error-messages', '--batch', '--debug']' timed out after 3.0 seconds [subprocess.py:_wait:1616] on trial #2. Sleeping 1.000000 and retrying
+2020-09-23 08:25:55,659 datalad.cmd     {3367135}[WARNING] Batched process <subprocess.Popen object at 0x7f3a5e597c18> did not finish, abandoning it without killing it
+2020-09-23 08:25:55,659 datalad.cmd     {3367135}[DEBUG] Process <subprocess.Popen object at 0x7f3a5e597c18> has finished
+2020-09-23 08:25:59,159 datalad.customremotes {3368204}[Level 4] Received []
+2020-09-23 08:25:59,160 datalad.customremotes {3368204}[DEBUG] Stopping communications of <datalad.customremotes.datalad.DataladAnnexCustomRemote object at 0x7f9d580fd5c0>
+2020-09-23 08:25:59,161 datalad         {3368204}[Level 5] Exiting
+```
+</details>
+
+so I wondered if those `process done ExitFailure ERR` could be made a bit more informative -- what process (PID? command?) has failed and if any information present -- why/how?  That might help to debug what process might have potentially caused a trouble.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> pid added, so [[done]] .. please open something else if there's a
+> specific place you need more detail about a nonzero exit. --[[Joey]]
diff --git a/doc/todo/report_PID___40__and_may_be_failure_details__63____41___in___34__process_done__34___debug_messages/comment_1_3b069234f20378fc231802c594eb213d._comment b/doc/todo/report_PID___40__and_may_be_failure_details__63____41___in___34__process_done__34___debug_messages/comment_1_3b069234f20378fc231802c594eb213d._comment
new file mode 100644
index 0000000000..99cc831cba
--- /dev/null
+++ b/doc/todo/report_PID___40__and_may_be_failure_details__63____41___in___34__process_done__34___debug_messages/comment_1_3b069234f20378fc231802c594eb213d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-09-24T16:32:14Z"
+ content="""
+I've added the pid.
+
+This happens at a layer that only knows the process exited, not what it was
+used for. Of course if we know the process in question the higher layer
+that uses it could be made to log something more informative, if
+the nonzero exit is really unexpected.
+"""]]
diff --git a/doc/todo/repositories_that_count_as_more_than_one_copy.mdwn b/doc/todo/repositories_that_count_as_more_than_one_copy.mdwn
new file mode 100644
index 0000000000..8fcc87d6e1
--- /dev/null
+++ b/doc/todo/repositories_that_count_as_more_than_one_copy.mdwn
@@ -0,0 +1,9 @@
+It may be useful for a repository to count as more than 1 copy of a file.
+
+Examples could include: A repository on S3, when a bucket is configured to be
+sufficiently durable. A --sameas special remote that accesses data copied
+from the other remote to another storage media (eg by a backup process).
+A repository on a RAID array.
+
+If this were made configurable, it might also make sense to allow a
+repository to count as less than 1 copy, eg 0.5 copies.
diff --git a/doc/todo/repositories_that_count_as_more_than_one_copy/comment_1_cc1ea7d1c6aac3749b4ecd789594e3f9._comment b/doc/todo/repositories_that_count_as_more_than_one_copy/comment_1_cc1ea7d1c6aac3749b4ecd789594e3f9._comment
new file mode 100644
index 0000000000..d40de05bb8
--- /dev/null
+++ b/doc/todo/repositories_that_count_as_more_than_one_copy/comment_1_cc1ea7d1c6aac3749b4ecd789594e3f9._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-06-19T15:39:08Z"
+ content="""
+See discussion in [[/copies]] requesting a feature like this.
+"""]]
diff --git a/doc/todo/required_content.mdwn b/doc/todo/required_content.mdwn
new file mode 100644
index 0000000000..e58994111d
--- /dev/null
+++ b/doc/todo/required_content.mdwn
@@ -0,0 +1,25 @@
+We have preferred content, which is advisory, and numcopies, which is
+enforced (except by `git annex move`). What is missing is an expression
+like preferred content, which is enforced. So, required content.
+
+For example, I might want a repository that is required to contain
+`*.jpeg`. This would make get --auto get it (it's implicitly part of the
+preferred content), and would make drop refuse to drop it.
+
+> I've implemented the basic required content. Currently only configurable
+> via `vicfg`, because I don't think a lot of people are going to want to
+> use it.
+> 
+> Note that I did not yet add the active verification discussed below.
+> So if required content is set to `not inallgroup=backup`, or
+> `not copies=10`, trying to drop a file will not go off and prove
+> that there are 10 copies or that the file is in every repository in 
+> the backup group. It will assume that the location log is accurate
+> and go by that.
+> 
+> I think this is enough to cover Richard's case, at least.
+> In his example, A B and C are in group anchor and have required
+> content set to `include=*`, and D E F have it set to
+> `not inallgroup=anchor`. --[[Joey]]
+
+[[!meta title="actively verify required content during drop"]]
diff --git a/doc/todo/required_content/comment_1_42620a3c958666be2a0d5f5b8eadf7b4._comment b/doc/todo/required_content/comment_1_42620a3c958666be2a0d5f5b8eadf7b4._comment
new file mode 100644
index 0000000000..7d490a9d75
--- /dev/null
+++ b/doc/todo/required_content/comment_1_42620a3c958666be2a0d5f5b8eadf7b4._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2014-03-10T17:15:54Z"
+ content="""
+To give a specific example of what I want to do:
+
+I have a bunch of repos
+
+* A, Machine1 -- anchor repository and sometimes used to add new content
+* B, Machine2 -- anchor repository, offsite
+* C, External1 -- anchor repository, stored off-site
+* D, Laptop -- transient repo to carry data around and to add new content
+* E, USB1 -- transient, travel backups
+* F, USB2 -- transient, travel backups
+
+A-C should get _all_ data. A-F trust A-C to always retain all data, online checks for availability are not needed because A-C run frequent fsck. Ideally, `git annex drop` should be no-op in A-C.
+
+D-F should retain data as long as it's not been saved in _all_ of A-C. As soon as A-C have copies, `git annex drop` in D-F should drop that content; before that, they _must not_ drop said content.
+
+Richard
+"""]]
diff --git a/doc/todo/required_content/comment_2_132ec6378db63af6281569cf5748b9d3._comment b/doc/todo/required_content/comment_2_132ec6378db63af6281569cf5748b9d3._comment
new file mode 100644
index 0000000000..dece48c01b
--- /dev/null
+++ b/doc/todo/required_content/comment_2_132ec6378db63af6281569cf5748b9d3._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.154"
+ subject="partial implementation plan"
+ date="2014-03-19T16:37:05Z"
+ content="""
+* When there is a required content expression, OR it with the preferred content expression. This will make the assistant, --auto etc want to get required content.
+* When checking if something can be dropped, check the required content expression. Only Command.Drop does this so nicely centralized in one place.
+* When checking required content expression for drop, must do active verification of terminals that relate to other copies, for the same reason the numcopies check when dropping does active validation. This includes `copies=`, `lackingcopies=`, `approxlackingcopies=`, `inallgroup=`.
+
+The last is where the complication comes in. Seems to need a cache of places the key was just now verified to be present, which can be used to avoid unnecessary redundant active verification (for example \"not (copies=2 and inallgroup=bar)\" would otherwise redundantly check some remotes). The numcopies checking code should use the same cache too.
+
+* Finally, if the required content cannot be satisfied, it would be nice to know which terminal failed in order to show the user a useful error message. The current Matcher does not provide a way to do that though. Or could just say, \"unable to satisfy required content: $expression\"
+"""]]
diff --git a/doc/todo/required_content/comment_3_b16a8e8b45ceee887c8c0167b7859654._comment b/doc/todo/required_content/comment_3_b16a8e8b45ceee887c8c0167b7859654._comment
new file mode 100644
index 0000000000..f4047baf5f
--- /dev/null
+++ b/doc/todo/required_content/comment_3_b16a8e8b45ceee887c8c0167b7859654._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 3"
+ date="2014-05-18T06:49:35Z"
+ content="""
+    22:34:10 < joeyh> required content is implemented, though active verification is not
+"""]]
diff --git a/doc/todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__.mdwn b/doc/todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__.mdwn
new file mode 100644
index 0000000000..46414d84ff
--- /dev/null
+++ b/doc/todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__.mdwn
@@ -0,0 +1,3 @@
+When [[standalone|install/Linux_standalone]] git-annex runs external special remote, it does so in the standalone environment.  I wonder if it makes more sense to run them in the original environment (by restoring PATH from ORIG_PATH)?   If the external special remote has been packaged with a package manager like conda, it expects its dependencies to come from the environment set up by that package manager, not the git-annex standalone environment.
+
+Also, maybe rename exported vars like ORIG_PATH to GIT_ANNEX_ORIG_PATH.
diff --git a/doc/todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__/comment_1_8a59da3012b9d177b4baa72610b72fc9._comment b/doc/todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__/comment_1_8a59da3012b9d177b4baa72610b72fc9._comment
new file mode 100644
index 0000000000..7c7d2fc8db
--- /dev/null
+++ b/doc/todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__/comment_1_8a59da3012b9d177b4baa72610b72fc9._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-04T20:50:08Z"
+ content="""
+Is this causing something not to work for you?
+
+It clearly ought to be fixed, but it extends rather beyond external remote
+programs. Eg, gpg is not bundled but is run with the bundled locales.
+ssh is bundled but is only used if the system does not have ssh, and if the
+system does, that also is run with the bundled locales. git is bundled, but
+may run other programs that are not bundled (git-remote-gcrypt comes to
+mind), which would run with the bundled locales etc. Only the webapp
+currently sanitizes the environment when starting a web browser.
+
+Probably the cleanest way to solve it would be to make git-annex
+unset the problem parts of the bundled environment when running
+all commands. (I think that would be `GCONV_PATH` and `LOCPATH`;
+others like `PATH` and `MANPATH` need to be seen by non-bundled programs.)
+And have the wrapper scripts in bin/ restore the bundled environment back
+again for their programs to use. Eg, have runshell also
+set `ANNEX_GCONV_PATH`, and the wrapper scripts have
+`GCONV_PATH="$ANNEX_GCONV_PATH"`.
+
+It might be possible to have git-annex just unset those env vars on startup, 
+instead of needing to do it every time in the System.Process wrapper.
+That would avoid slowing down non-standalone git-annex with checking,
+on every command invocation, if it needs to sanitize its environment.
+I'm not sure if a program that unsets `GCONV_PATH` and `LOCPATH` on startup
+will prevent glibc from using them or not, would have to test or code dive
+glibc to find out.
+
+(That would not make the bundled git run non-bundled git-remote-gcrypt
+w/o the bundled environment. If that kind of thing were really a problem,
+the only solution would seem to be to modify git.)
+"""]]
diff --git a/doc/todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__/comment_2_96f1138462fecac628751d872e2ceb9e._comment b/doc/todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__/comment_2_96f1138462fecac628751d872e2ceb9e._comment
new file mode 100644
index 0000000000..0520b4eaf3
--- /dev/null
+++ b/doc/todo/restore_original_environment_when_running_external_special_remotes_from_standalone_git-annex__63__/comment_2_96f1138462fecac628751d872e2ceb9e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2020-03-04T21:34:42Z"
+ content="""
+\"Is this causing something not to work for you?\" -- not so far, it just occurred to me that this could potentially cause problems.
+"""]]
diff --git a/doc/todo/return___34__key__34___entry_in_--json_output_for_addurl___40__and_future_add__41___--batch.mdwn b/doc/todo/return___34__key__34___entry_in_--json_output_for_addurl___40__and_future_add__41___--batch.mdwn
new file mode 100644
index 0000000000..8ab71421b7
--- /dev/null
+++ b/doc/todo/return___34__key__34___entry_in_--json_output_for_addurl___40__and_future_add__41___--batch.mdwn
@@ -0,0 +1,6 @@
+You have noted that somewhere (may be in email), that it might help us to pipeline things if 'add' was returning the key if file was added to the annex.  I guess the same could apply to 'addurl' so decided to mark this separate todo
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> already done earlier today [[done]] --[[Joey]]
diff --git a/doc/todo/reuse_desktop_notifications.mdwn b/doc/todo/reuse_desktop_notifications.mdwn
new file mode 100644
index 0000000000..6ea3a14eec
--- /dev/null
+++ b/doc/todo/reuse_desktop_notifications.mdwn
@@ -0,0 +1,30 @@
+When using --notify-start or --notify-finish with many files that are able
+to be downloaded quickly, the desktop notifications can cover the whole
+screen (in xfce at least).
+
+It's possible to update a desktop notification to contain some new
+information. That's done when a transfer is finished, to update the start
+notification. Also, if the notification has been closed, updating causes it
+to re-display.
+
+So, it would be possible to reuse desktop notifications, so only one is
+displayed, and it runs through all the files that are being processed.
+
+When only --notify-start or --notify-finish is used, the notification would
+show the last thing started or finished. When both are used, the
+finish notification would be quickly overwritten by the next thing started.
+That seems ok?
+
+The complication to this is jobs. With -J, it seems like it ought to
+display one notification per transfer thread, so the user knows git-annex
+is working on multiple things. Implementing that would need some way to get
+the notification handle associated with a given Transferrer. As the code is
+structured, notifyTransfer is run before the Transferrer that will be used
+is known. So this would need some refactoring.
+
+Maybe that complexity is unwarranted though? Desktip notifications only are
+displayed for a short amount of time (again on xfce). So if a long-duration
+download is run, the notification will appear for a short time, and then
+vanish while it continues downloading. So the user is not likely to see
+notifications for all the -J jobs that are running be displayed at the same
+time. So reusing a single notification does not seem much worse? --[[Joey]]
diff --git a/doc/todo/reuse_desktop_notifications/comment_1_6193ed5a4ad0a908af82da33d14bd654._comment b/doc/todo/reuse_desktop_notifications/comment_1_6193ed5a4ad0a908af82da33d14bd654._comment
new file mode 100644
index 0000000000..a5b26326c6
--- /dev/null
+++ b/doc/todo/reuse_desktop_notifications/comment_1_6193ed5a4ad0a908af82da33d14bd654._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 1"
+ date="2023-01-02T21:58:25Z"
+ content="""
+I'd consider a single 'persistent' notification for git-annex sufficient. When a transfer starts/finishes the notification is updated. Maybe show a configurable amount of last items (`git config annex.notification-max-items` with a default of 5 or so). `-J` Worker threads would just add to that notification, I don't see a need for one notification per worker thread (that can easily go up to another 16 with `--jobs=cpus` on modern CPUs, filling the screen again 🙃).
+"""]]
diff --git a/doc/todo/reuse_desktop_notifications/comment_2_3fb10a432a57ce14cb7bc2946467ab22._comment b/doc/todo/reuse_desktop_notifications/comment_2_3fb10a432a57ce14cb7bc2946467ab22._comment
new file mode 100644
index 0000000000..5b4a8ea689
--- /dev/null
+++ b/doc/todo/reuse_desktop_notifications/comment_2_3fb10a432a57ce14cb7bc2946467ab22._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 2"
+ date="2023-02-23T08:59:28Z"
+ content="""
+I think perhaps the notify options should be revamped as I don't get what their purpose is.
+
+Receiving one desktop notification for each and every transfer sounds like insanity to me. I'd get constant notifications doing anything at all.
+
+To me, notifications are for things that require immediate attention. An email for example or an assistant fsck that found corrupted files or perhaps a failed git-annex transfer. That sort of thing.  
+What's the use-case of constantly requiring immediate attention the entire time for every benign thing happening? In my mind, I might as well just watch the git-annex progress log at that point.
+
+Before reading what the options actually did, I would have expected `--notify-finish` to produce exactly one notification when the git-annex command I set off is done. Perhaps with a summary in it what it had done (successes/errors).
+"""]]
diff --git a/doc/todo/reuse_desktop_notifications/comment_3_ac0e5f437b5d2677e916224d6dfaf666._comment b/doc/todo/reuse_desktop_notifications/comment_3_ac0e5f437b5d2677e916224d6dfaf666._comment
new file mode 100644
index 0000000000..cd0e778683
--- /dev/null
+++ b/doc/todo/reuse_desktop_notifications/comment_3_ac0e5f437b5d2677e916224d6dfaf666._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-02-27T15:51:48Z"
+ content="""
+If you only want a notification at the end of the command,
+you can use: `git-annex whatever; notify-send done`
+
+So there is more value in git-annex notifying after each transfer than at
+the end of the command. Just because it would not be valuable in your
+particular case doesn't mean it's a useless feature. It's not unusual to
+have files large enough that transferring them takes some time.
+"""]]
diff --git a/doc/todo/setpresentkey_option_to_record_chunked_state.mdwn b/doc/todo/setpresentkey_option_to_record_chunked_state.mdwn
new file mode 100644
index 0000000000..72bea1b1a3
--- /dev/null
+++ b/doc/todo/setpresentkey_option_to_record_chunked_state.mdwn
@@ -0,0 +1,3 @@
+In [[git-annex-setpresentkey]], could an option be added to record in [[`aaa/bbb/*.log.cnk`|internals]] that the key contents is present in chunked state, with a given number of chunks of a given size?
+
+[[!tag moreinfo]]
diff --git a/doc/todo/setpresentkey_option_to_record_chunked_state/comment_1_99bf00b8f78d75888dc7bc69d36cd112._comment b/doc/todo/setpresentkey_option_to_record_chunked_state/comment_1_99bf00b8f78d75888dc7bc69d36cd112._comment
new file mode 100644
index 0000000000..a422ae3c66
--- /dev/null
+++ b/doc/todo/setpresentkey_option_to_record_chunked_state/comment_1_99bf00b8f78d75888dc7bc69d36cd112._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-29T14:39:06Z"
+ content="""
+I would rather not complicate setpresentkey with things not related to
+presence information.
+
+This seems pretty deep into messing with git-annex's internals to seem
+plausible to me as a separate command. At some point, you may as well just
+write data to the branch yourself. What is the use case?
+"""]]
diff --git a/doc/todo/setpresentkey_option_to_record_chunked_state/comment_2_42e9309fff6a71c1a0a625dd2bc6aae2._comment b/doc/todo/setpresentkey_option_to_record_chunked_state/comment_2_42e9309fff6a71c1a0a625dd2bc6aae2._comment
new file mode 100644
index 0000000000..c53025642f
--- /dev/null
+++ b/doc/todo/setpresentkey_option_to_record_chunked_state/comment_2_42e9309fff6a71c1a0a625dd2bc6aae2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="use case to record chunked state"
+ date="2020-01-29T17:48:40Z"
+ content="""
+\"What is the use case?\" -- to register with git-annex the presence of a file in a remote, that is already split into chunks, without downloading the file.
+\"I would rather not complicate setpresentkey with things not related to presence information\" -- makes sense.
+\"you may as well just write data to the branch yourself\" -- yes; just wasn't sure if that might break some invariant, e.g. between the branch and the SQL databases derived from it.
+
+Don't worry about this todo, I'll figure it out.
+"""]]
diff --git a/doc/todo/setpresentkey_option_to_record_chunked_state/comment_3_97ed902a268ebad53f534dd48a6f5fc9._comment b/doc/todo/setpresentkey_option_to_record_chunked_state/comment_3_97ed902a268ebad53f534dd48a6f5fc9._comment
new file mode 100644
index 0000000000..ebcf5df6cf
--- /dev/null
+++ b/doc/todo/setpresentkey_option_to_record_chunked_state/comment_3_97ed902a268ebad53f534dd48a6f5fc9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-01-30T16:41:42Z"
+ content="""
+That's the use case I'd guessed, but it seems things would have to line up
+exactly for it to work. Ie, I think git-annex requires all the chunks to be
+the same size, and may fail in unexpected ways if they are not.
+
+You do not need to worry about any internal caching when modifying the
+git-annex branch, because updates to the git-annex branch are always being
+merged from remotes, so any such caching has to detect changes and update
+itself.
+"""]]
diff --git a/doc/todo/sharedRepository_mode_not_supported_by_git-annex.mdwn b/doc/todo/sharedRepository_mode_not_supported_by_git-annex.mdwn
new file mode 100644
index 0000000000..14ab5fd529
--- /dev/null
+++ b/doc/todo/sharedRepository_mode_not_supported_by_git-annex.mdwn
@@ -0,0 +1,9 @@
+git's core.SharedRepository is supported by git-annex, but only
+with the group/all/world/everybody settings. core.SharedRepository=0644
+etc is not supported.
+
+There's no insormountable reason why not, Joey just hates umask mode math
+stuff and nobody has sent a patch. Note that Annex.Content.freezeContent
+should remove the write bit from files, no matter what.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/sharedRepository_mode_not_supported_by_git-annex/comment_1_b219d62cd7d21002ae73d0dbd4b792be._comment b/doc/todo/sharedRepository_mode_not_supported_by_git-annex/comment_1_b219d62cd7d21002ae73d0dbd4b792be._comment
new file mode 100644
index 0000000000..8584a60423
--- /dev/null
+++ b/doc/todo/sharedRepository_mode_not_supported_by_git-annex/comment_1_b219d62cd7d21002ae73d0dbd4b792be._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2023-04-26T14:34:31Z"
+ content="""
+Hi Joey, We just [now (re)discovered for ourselves in DataLad](https://github.com/psychoinformatics-de/knowledge-base/issues/15) that octal modes are not supported by git-annex **at all**.  We wonder if you are planing to add support for them, or should we may be just start [warning users](https://github.com/datalad/datalad/pull/7375) if there is an unsupported configuration of shared setup is encountered.
+"""]]
diff --git a/doc/todo/sharedRepository_mode_not_supported_by_git-annex/comment_2_7140ad0abbb54f5a4e20b165a08793e2._comment b/doc/todo/sharedRepository_mode_not_supported_by_git-annex/comment_2_7140ad0abbb54f5a4e20b165a08793e2._comment
new file mode 100644
index 0000000000..e9b4680cd8
--- /dev/null
+++ b/doc/todo/sharedRepository_mode_not_supported_by_git-annex/comment_2_7140ad0abbb54f5a4e20b165a08793e2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-04-26T16:50:23Z"
+ content="""
+I don't think it would be that hard to implement, I count 6 places, all in
+Annex.Perms that don't handle UmaskShared.
+
+For now I've made all of them display a warning.
+
+(Note that your warning patch to datalad is probably buggy, 
+since core.sharedrepository=1 and =2 are supported by git-annex.
+(As legacy alternatives to "group" and "everybody".))
+"""]]
diff --git a/doc/todo/sharedRepository_mode_not_supported_by_git-annex/comment_3_c3dff87829e3f055881829eb4598f903._comment b/doc/todo/sharedRepository_mode_not_supported_by_git-annex/comment_3_c3dff87829e3f055881829eb4598f903._comment
new file mode 100644
index 0000000000..3ea11b49c1
--- /dev/null
+++ b/doc/todo/sharedRepository_mode_not_supported_by_git-annex/comment_3_c3dff87829e3f055881829eb4598f903._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-04-26T17:39:21Z"
+ content="""
+I've implemented this today!
+
+(Did notice a bug,
+[[wrong_modes_for_some_lock_files_withcoresharedrepository]])
+"""]]
diff --git a/doc/todo/shorten_git-annex_manpage.mdwn b/doc/todo/shorten_git-annex_manpage.mdwn
new file mode 100644
index 0000000000..97d04eca80
--- /dev/null
+++ b/doc/todo/shorten_git-annex_manpage.mdwn
@@ -0,0 +1,38 @@
+the [[git-annex]] manpage is still pretty long. i wonder if work shouldn't be done to shorten it further.
+
+what i'm thinking of is that this entry, for example, takes up three lines where it could take two, reducing the size by 30% since most commands have only one line explaining it:
+
+<pre>
+ * undo `[filename|directory] ...`
+
+   Undo last change to a file or directory.
+
+   See [[git-annex-undo]](1) for details.
+</pre>
+
+the `git(1)` manpage resolves this by putting the reference in the first line:
+
+<pre>
+       git-init(1)
+           Create an empty Git repository or reinitialize an existing one.
+</pre>
+
+So i would think there are two options here:
+
+1. do like git, but preserving the usage:
+
+<pre>
+ * [[git-annex-undo]](1) `[filename|directory]`
+
+   Undo last change to a file or directory.
+</pre>
+
+2. Put the reference on the same line:
+
+<pre>
+ * undo `[filename|directory] ...`
+
+   Undo last change to a file or directory. See [[git-annex-undo]](1) for details.
+</pre>
+
+Opinions? --[[anarcat]]
diff --git a/doc/todo/shorten_git-annex_manpage/comment_1_4b82eb4af9b923b23c6ecd8d355c0651._comment b/doc/todo/shorten_git-annex_manpage/comment_1_4b82eb4af9b923b23c6ecd8d355c0651._comment
new file mode 100644
index 0000000000..a0a1b6d266
--- /dev/null
+++ b/doc/todo/shorten_git-annex_manpage/comment_1_4b82eb4af9b923b23c6ecd8d355c0651._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-30T15:36:45Z"
+ content="""
+I don't like the "git-init" approach; git-init used to be in PATH,
+but no longer is, so the git man page is really a bit broken now.
+And of course, git-annex-undo is not actually a filename.
+
+The second approach doesn't shorten it much and makes it harder
+to skip over the boilerplate in the links when reading since it's moved
+into the same paragraph as the description and will appear at differing
+positions depending on the description length.
+
+I'd rather make the command name be a hyperlink. However,
+it's difficult to reconcile this with the limitations of man
+pages.
+
+Maybe aim for something like this in the man page display,
+although I don't know if it can be accomplished:
+
+	undo [filename|directory] ...                            git-annex-undo(1)
+	  Undo last change to a file or directory.
+"""]]
diff --git a/doc/todo/shorten_git-annex_manpage/comment_2_859444d7e2826ac4448b0ba0f716328f._comment b/doc/todo/shorten_git-annex_manpage/comment_2_859444d7e2826ac4448b0ba0f716328f._comment
new file mode 100644
index 0000000000..a0ec1c77cf
--- /dev/null
+++ b/doc/todo/shorten_git-annex_manpage/comment_2_859444d7e2826ac4448b0ba0f716328f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="no easy fix, i guess then"
+ date="2015-05-31T16:51:36Z"
+ content="""
+right, that would be great. unfortunately, we use the `.IP` macro in the rendered groff output, which only has a leader and nothing on the right. i don't believe there's a macro that would answer the requirement, and i looked at `man(7)`, `mdoc(7)`, `man-pages(7)`, `groff_man(7)`, `groff_mdoc(7)`... which probably covers most of the man material i am aware of.
+
+there *is* the `\h'N'` macro that allows moving `N` spaces to the right, but that wouldn't align the references, so we'd be better off with something like:
+
+<pre>
+ * undo `[filename|directory]` # git-annex-undo(1)
+
+   Undo last change to a file or directory.
+</pre>
+
+... or something like that...
+"""]]
diff --git a/doc/todo/shorten_git-annex_manpage/comment_3_3543a2edda668c3f0a90c46aeee94812._comment b/doc/todo/shorten_git-annex_manpage/comment_3_3543a2edda668c3f0a90c46aeee94812._comment
new file mode 100644
index 0000000000..7952d4d53b
--- /dev/null
+++ b/doc/todo/shorten_git-annex_manpage/comment_3_3543a2edda668c3f0a90c46aeee94812._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-06-02T17:41:12Z"
+ content="""
+I'm not sure if it's clear enough that is a man-link and not some
+complexity added to the command line options.
+"""]]
diff --git a/doc/todo/shorten_git-annex_manpage/comment_4_fa6c2870f4a83d0f5680b76b05009e4b._comment b/doc/todo/shorten_git-annex_manpage/comment_4_fa6c2870f4a83d0f5680b76b05009e4b._comment
new file mode 100644
index 0000000000..57e91fd7e4
--- /dev/null
+++ b/doc/todo/shorten_git-annex_manpage/comment_4_fa6c2870f4a83d0f5680b76b05009e4b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2023-01-16T18:22:16Z"
+ content="""
+Reviewing this, I think what we've shown is that there's no good way to
+shorten it, that does not have other tradeoffs!
+
+And what's the real problem with the man page being a bit longer?
+Most users are probably not reading through all that, but are searching.
+And users who do read through it get to see around 5 commands summarized
+per page on their 25 line dumb terminal. Those of us with modern hardware
+can often see considerably more commands per page.
+"""]]
diff --git a/doc/todo/shorter_keys_through_better_encoding.mdwn b/doc/todo/shorter_keys_through_better_encoding.mdwn
new file mode 100644
index 0000000000..3b33d0cad8
--- /dev/null
+++ b/doc/todo/shorter_keys_through_better_encoding.mdwn
@@ -0,0 +1,7 @@
+The link targets of annexed files are currently very long.   This creates problems e.g. when browsing directories in Emacs (I mostly work through a text terminal).  Ideally, the key would not be repeated twice in the link, but I understand this is hard to do compatibly.  Maybe, the following simpler alternative could be implemented?   Key checksums are currently represented in base16 using only the characters 0-9a-f .  The same information could be represented with shorter strings using base64url or other encoding, where a larger range of chars is used.  So for each backend you'd add a corresponding one that does the same thing, but encodes the checksum part of the key with shorter strings.
+
+
+Or, if you're tired of backend requests, maybe implement a scheme for external backends, like the one for external special remotes?  For external backend EXTNNN the user would put  a script git-annex-external-backend-NNN in the path; the script would support commands like calckey, examinekey .   Then I could also implement e.g. canonicalizing backends that strip away variable but semantically irrelevant information before computing the checksum.
+
+[[!meta title="avoid duplicating key twice in symlink to object file"]]
+[[!tag unlikely]]
diff --git a/doc/todo/shorter_keys_through_better_encoding/comment_1_4bd588a3cdca5cb94132549b7d78e6af._comment b/doc/todo/shorter_keys_through_better_encoding/comment_1_4bd588a3cdca5cb94132549b7d78e6af._comment
new file mode 100644
index 0000000000..94f752cab1
--- /dev/null
+++ b/doc/todo/shorter_keys_through_better_encoding/comment_1_4bd588a3cdca5cb94132549b7d78e6af._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2018-09-27T07:39:57Z"
+ content="""
+The key is in the path twice as a security measure (the write bit is removed from the directory, to prevent `rm -rf`ing all the files away by mistake).
+
+This is known to cause slowness while traversing the objects directory, which is why there is repository [[tuning]]. Perhaps you want to set some of these?
+"""]]
diff --git a/doc/todo/shorter_keys_through_better_encoding/comment_2_454cb3b2b1102ce4da18f245bc583e7c._comment b/doc/todo/shorter_keys_through_better_encoding/comment_2_454cb3b2b1102ce4da18f245bc583e7c._comment
new file mode 100644
index 0000000000..4687afe8a3
--- /dev/null
+++ b/doc/todo/shorter_keys_through_better_encoding/comment_2_454cb3b2b1102ce4da18f245bc583e7c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2018-09-27T11:09:04Z"
+ content="""
+\"The key is in the path twice as a security measure\" -- would key/f.txt be less secure than key/key.txt?  I thought the security comes from having both a dir and a file, not from them both having the key in their name?
+"""]]
diff --git a/doc/todo/shorter_keys_through_better_encoding/comment_3_9f5f16a7ab5d3e28cdddc333d97b87ea._comment b/doc/todo/shorter_keys_through_better_encoding/comment_3_9f5f16a7ab5d3e28cdddc333d97b87ea._comment
new file mode 100644
index 0000000000..2e67b62598
--- /dev/null
+++ b/doc/todo/shorter_keys_through_better_encoding/comment_3_9f5f16a7ab5d3e28cdddc333d97b87ea._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-10-04T18:35:28Z"
+ content="""
+I'm not convinced that git-annex should try to make the symlinks shorter
+just because some programs have UIs that don't work well with longer
+symlinks. UIs can be improved.
+
+I like to use `ls -lL` for example, which conveniently
+avoids displaying the symlink target and also shows the size of the annexed
+file.
+
+Using the MD5 backend will also give you much shorter symlinks..
+
+External backends is an interesting idea, but needing to deal with the
+backend being missing or failing to work could have wide repurcussions in
+the code base. It feels like too much complexity for too little gain.
+"""]]
diff --git a/doc/todo/shorter_keys_through_better_encoding/comment_4_720012572e1d748bc628fdb17a55a3bd._comment b/doc/todo/shorter_keys_through_better_encoding/comment_4_720012572e1d748bc628fdb17a55a3bd._comment
new file mode 100644
index 0000000000..ea89550a08
--- /dev/null
+++ b/doc/todo/shorter_keys_through_better_encoding/comment_4_720012572e1d748bc628fdb17a55a3bd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2018-10-12T01:05:30Z"
+ content="""
+\"I'm not convinced that git-annex should try to make the symlinks shorter just because some programs have UIs that don't work well with longer symlinks\" -- UI is just one plus of shorter keys. Another is that some systems can't handle long paths; e.g. backends says don't use 512 or 384 hashes on Windows. Another is that long keys and symlinks increase the amount of data git deals with, which can matter for large repos. Using base64 encoding for hashes would shorten key lengths by a third; not repeating the hash twice in symlinks would give another factor of 2.
+"""]]
diff --git a/doc/todo/shorter_keys_through_better_encoding/comment_5_41857b7f25f8a922640378a41574b84d._comment b/doc/todo/shorter_keys_through_better_encoding/comment_5_41857b7f25f8a922640378a41574b84d._comment
new file mode 100644
index 0000000000..97c0b7a8c7
--- /dev/null
+++ b/doc/todo/shorter_keys_through_better_encoding/comment_5_41857b7f25f8a922640378a41574b84d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 5"
+ date="2018-10-12T13:42:07Z"
+ content="""
+I was arguing for removal of the KEY-directory/ for a while ;) See e.g. as old as https://github.com/datalad/datalad/issues/32 . There is an issue/discussion on this website too somewhere, couldn't find quickly.
+IMHO it is just a \"tech\" problem, i.e. no design principle forbids fixing it. It might though lead to performance issues since the containing directory then needs to be chmod'ed back and forth to introduce changes to the KEY-file under it, but it is probably very similar to what it is now anyways.  
+
+FWIW in DataLad we moved to use MD5E backend as the default to at least somewhat relief the burden of long symlinks.  I think we are \"secure\" enough for what we use DataLad here ;)
+"""]]
diff --git a/doc/todo/shorter_keys_through_better_encoding/comment_6_de3f0be0f6b560ca7bb66f7b5c8f0592._comment b/doc/todo/shorter_keys_through_better_encoding/comment_6_de3f0be0f6b560ca7bb66f7b5c8f0592._comment
new file mode 100644
index 0000000000..1f7dc490d1
--- /dev/null
+++ b/doc/todo/shorter_keys_through_better_encoding/comment_6_de3f0be0f6b560ca7bb66f7b5c8f0592._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 6"
+ date="2018-10-12T13:58:05Z"
+ content="""
+Removing KEY/directory could give more savings, but sometimes there is more than one file there (eg key metadata), so the dir makes sense.  But the content filename in the dir needn’t repeat the key.   But, changing that could be hard.  Adding backend variamts with base64-encoded checksums seems possible though?
+"""]]
diff --git a/doc/todo/shorter_keys_through_better_encoding/comment_7_d499c66c9a1981bb14d0ce63f4983ea5._comment b/doc/todo/shorter_keys_through_better_encoding/comment_7_d499c66c9a1981bb14d0ce63f4983ea5._comment
new file mode 100644
index 0000000000..97479bec0d
--- /dev/null
+++ b/doc/todo/shorter_keys_through_better_encoding/comment_7_d499c66c9a1981bb14d0ce63f4983ea5._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2020-01-30T18:49:47Z"
+ content="""
+Since there is a separate todo item [[external_backends]], let's not
+discuss that idea here.
+
+key/f would have been a great idea to have had 10 years ago.
+(Although it does mean that if the object file somehow gets moved out of
+its directory, there's no indication in its name that it's a git-annex
+object file)
+
+But if that's all this todo is about, we'd need some kind of transition
+plan for existing repos with history containing symlinks to key/key. 
+I doubt there is a good way to make that transition.
+"""]]
diff --git a/doc/todo/shorter_keys_through_better_encoding/comment_8_5592ac9d1887183daf3173a0c27b672f._comment b/doc/todo/shorter_keys_through_better_encoding/comment_8_5592ac9d1887183daf3173a0c27b672f._comment
new file mode 100644
index 0000000000..b3435bca6a
--- /dev/null
+++ b/doc/todo/shorter_keys_through_better_encoding/comment_8_5592ac9d1887183daf3173a0c27b672f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="amerlyq+annex@12121d70a602f094228689a0a24d348d478a8af1"
+ nickname="amerlyq+annex"
+ avatar="http://cdn.libravatar.org/avatar/3d63c9f436b45570d45bd003e468cbd3"
+ subject="re: shorter symlinks"
+ date="2020-03-04T00:48:02Z"
+ content="""
+I don't need strategy nor safety.
+Create a tunable for new repos to disable directory sha completely (and if not sustainable - even readonly bit safety) - and that is enough.
+I will replay whole my history again onto new repo and make fs snapshotting more frequently.
+I can even live without base64.
+Changing defaults is undesirable - and that is understandable. 
+But we would still prefer to have an option, even if to bear the whole grunt of consequences ourselves.
+Sometimes I wonder if it worth to learn Haskell only to fork gitannex for specific needs, but the reason for this encompassing endeavor seems lame :(
+"""]]
diff --git a/doc/todo/shorter_keys_through_better_encoding/comment_9_75f611c63bf1e9c8b4885fea8e9d467f._comment b/doc/todo/shorter_keys_through_better_encoding/comment_9_75f611c63bf1e9c8b4885fea8e9d467f._comment
new file mode 100644
index 0000000000..7c226eb341
--- /dev/null
+++ b/doc/todo/shorter_keys_through_better_encoding/comment_9_75f611c63bf1e9c8b4885fea8e9d467f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2020-07-29T21:22:42Z"
+ content="""
+[[external_backends]] is now implemented, so you can write a program that
+makes keys use some other, shorter hash encoding.
+
+I don't know if that's really sufficient to close this.
+"""]]
diff --git a/doc/todo/show_dead_in_info___40__behind_option__63____41__.mdwn b/doc/todo/show_dead_in_info___40__behind_option__63____41__.mdwn
new file mode 100644
index 0000000000..ebb40443e3
--- /dev/null
+++ b/doc/todo/show_dead_in_info___40__behind_option__63____41__.mdwn
@@ -0,0 +1,3 @@
+Would it be possible for `git annex info` to also show dead remotes (behind an option is fine), to make it easy to find what dead remotes there are? I needed to check what I had done for a service that was going away (AARNET Cloudstor, which used webdav), and was confused as to why it wasn't appearing anywhere.
+
+> Implemented `git-annex info --dead-repositories` [[done]] --[[Joey]]
diff --git a/doc/todo/show_dead_in_info___40__behind_option__63____41__/comment_1_74c3bbb7819368a894ff1189988e4cd3._comment b/doc/todo/show_dead_in_info___40__behind_option__63____41__/comment_1_74c3bbb7819368a894ff1189988e4cd3._comment
new file mode 100644
index 0000000000..de77f57b16
--- /dev/null
+++ b/doc/todo/show_dead_in_info___40__behind_option__63____41__/comment_1_74c3bbb7819368a894ff1189988e4cd3._comment
@@ -0,0 +1,44 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Workaround for listing dead remotes"
+ date="2023-07-26T17:40:56Z"
+ content="""
+Current workaround is to do some shell magic:
+
+[[!format  bash \"\"\"
+❯ git show git-annex:trust.log | grep ' X ' | sort -r -k3,3 | sort -u -k1,1 | sort -k3,3
+00000000-0000-0000-0000-000000000001 X timestamp=1665735093.590311882s
+00000000-0000-0000-0000-000000000002 X timestamp=1665735096.60698876s
+bccdc354-3e91-434d-b558-92bda037262f X timestamp=1665756359.672362517s
+07e1a2c4-6a48-4149-8c1d-578d01d101ca X timestamp=1666190795.982309234s
+6f2f88b1-75b0-4628-aca0-b7e404881787 X timestamp=1666190981.07615739s
+c15fa203-2c18-4925-ba00-bf2896c837b8 X timestamp=1666191690.101011744s
+9b0e8fa2-6516-489a-a765-535185fd13da X timestamp=1666252027.044902201s
+6eece6e9-af12-4493-812b-a93ef37d1c97 X timestamp=1666773713.866014699s
+556463c4-498b-4c48-86cf-891d5d350d92 X timestamp=1666773716.613288244s
+699550a9-8927-4e39-860f-9391dadf658a X timestamp=1666773720.004014314s
+
+\"\"\"]]
+
+This should be a time-sorted overview of all dead git annex remote IDs (read: get all trust level info from `git-annex`-branch, keep only dead ones, sort reversely by time to then keep only the most up-to-date entry per remote, finally sorting by time again). Unfortunately, `git annex info DEADREMOTEID` doesn't work (Temporarily setting the trustlevel back to something undead e.g. with `git -c remote.DEAD.annex-trustlevel=untrust -c remote.DEAD.annex-uuid=6f2f88b1-75b0-4628-aca0-b7e404881787 annex info` or putting the equivalent in `.git/config` also doesn't work.), so to get the description we need to read it manually from the `git-annex`-branch (provided you didn't run `git annex forget --drop-dead` of course...):
+
+[[!format  bash \"\"\"
+$ git show git-annex:uuid.log | grep -f <(git show git-annex:trust.log | grep ' X ' | cut -d' ' -f1)
+12239c61-893b-409b-8593-242b3bd06d59 hetzner timestamp=1681837014.563205098s
+1f010ad0-66f5-4b4d-abb6-c995639ddb8d also broken on Yann IdeaPad timestamp=1674395012.267824079s
+1f010ad0-66f5-4b4d-abb6-c995639ddb8d yann@yann-ideapad:~/Sync-broken timestamp=1674392076.605762565s
+6726366a-3417-4d87-a5e0-e6c6e174611e broken on Yann IdeaPad timestamp=1674395003.447162736s
+6726366a-3417-4d87-a5e0-e6c6e174611e yann@yann-ideapad:~/Sync timestamp=1674392895.243361127s
+7eacb3f6-668f-4c76-8a93-e60bb83195e9 yann@yann-ideapad:~/Sync2 timestamp=1672691029.638810716s
+92f1c925-5360-4d35-8876-97724e5e8d68 hetzner timestamp=1681841459.689233275s
+a295b60b-440e-43be-8d63-a1251b939039 hetzner timestamp=1681837210.139095335s
+cc849692-1dca-4d07-889a-2c0b37fef154 hetzner timestamp=1681836822.12092766s
+\"\"\"]]
+
+
+This is as far as it gets in terms of prettiness I'm afraid. 
+
+I'd also like an option to show dead remotes, e.g. with `git annex info --all` or `git annex info --show-dead`. And having `git annex info DEADREMOTEID` work would also be nice 🙂
+
+"""]]
diff --git a/doc/todo/show_dead_in_info___40__behind_option__63____41__/comment_2_0cc7a3c53ffbabcb13807956541d83ec._comment b/doc/todo/show_dead_in_info___40__behind_option__63____41__/comment_2_0cc7a3c53ffbabcb13807956541d83ec._comment
new file mode 100644
index 0000000000..09e8ebdb85
--- /dev/null
+++ b/doc/todo/show_dead_in_info___40__behind_option__63____41__/comment_2_0cc7a3c53ffbabcb13807956541d83ec._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="aragilar"
+ avatar="http://cdn.libravatar.org/avatar/7390f7c0dd07d43ca827a5446b65c102"
+ subject="comment 2"
+ date="2023-07-28T02:47:42Z"
+ content="""
+Yep, I realised I could grep trust.log to see that I'd marked it as dead, but it did take me a bit of time to realise this (I was thinking \"did I enable cloudstor on this machine, maybe it only shows up on machines you enable it on, but I though I did that previously...\").
+
+I think even a count of dead remotes (so you know what you need to look for) would be helpful, if minimal changes are required.
+"""]]
diff --git a/doc/todo/show_me_where_unused_file_was__44___i_can_wait.mdwn b/doc/todo/show_me_where_unused_file_was__44___i_can_wait.mdwn
new file mode 100644
index 0000000000..e4b34aa223
--- /dev/null
+++ b/doc/todo/show_me_where_unused_file_was__44___i_can_wait.mdwn
@@ -0,0 +1,9 @@
+i know that `git annex unused` would be slower if, instead of just showing the hash, it would also show the pathname where the file was. it does tell me that i can use `git log --stat -SKEY` to find that out myself, but then i would need to make some silly shell script to loop over multiple files. i'm hoping that git-annex has more efficient and clever ways of doing that, and even if it's slower, i'd be ready to wait if there was an extra flag to show me where it was...
+
+i have used this oneliner so far, but it's ugly and painful, especially since `git annex unused` doesn't have a very parseable output format...
+
+    git annex unused 2>&1 | grep '^  *[0-9][0-9]*' | sed 's/^ *[0-9][0-9]* *//' | xargs -I'{}' git log --oneline --stat -S'{}' -1
+
+any way to do this more easily? --[[anarcat]]
+
+> [[done]]; use `git-annex whereused --unused` --[[Joey]]
diff --git a/doc/todo/show_me_where_unused_file_was__44___i_can_wait/comment_1_732f726f72f2540372d434974fda60f2._comment b/doc/todo/show_me_where_unused_file_was__44___i_can_wait/comment_1_732f726f72f2540372d434974fda60f2._comment
new file mode 100644
index 0000000000..522696b18e
--- /dev/null
+++ b/doc/todo/show_me_where_unused_file_was__44___i_can_wait/comment_1_732f726f72f2540372d434974fda60f2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-10-26T19:29:12Z"
+ content="""
+git-annex has no better way to find files that linked to that key than the
+given log -S.
+
+However, your script can be improved by reading the list of unused keys
+from `.git/annex/unused`
+"""]]
diff --git a/doc/todo/show_readonly_removable_drives_in_the_webapp.mdwn b/doc/todo/show_readonly_removable_drives_in_the_webapp.mdwn
new file mode 100644
index 0000000000..e0e570fe03
--- /dev/null
+++ b/doc/todo/show_readonly_removable_drives_in_the_webapp.mdwn
@@ -0,0 +1,15 @@
+Coming from [[todo/read-only_removable_drives/]], this is use case 1: use inserts an `ext` formatted filesystem that he built at home (so files are owned by uid `1000`)  in the office computer (where he is uid `1001`). Now, this is a limitation of UNIX-style removable drives, admittedly, but I would expect to be able to sync "down" from the hard drives to copy the contents locally.
+
+So in short, expected behavior:
+
+1. insert the drive
+2. drive is shown in the webapp menu
+3. add the drive as a remote for the local repo
+4. sync the content from the drive to the local repo
+
+Actual behavior:
+
+1. insert the drive
+2. drive is not shown in the webapp menu
+
+--[[anarcat]]
diff --git a/doc/todo/show_readonly_removable_drives_in_the_webapp/comment_1_c41140289f9b062e96cfd5d9d5382155._comment b/doc/todo/show_readonly_removable_drives_in_the_webapp/comment_1_c41140289f9b062e96cfd5d9d5382155._comment
new file mode 100644
index 0000000000..faa49bf149
--- /dev/null
+++ b/doc/todo/show_readonly_removable_drives_in_the_webapp/comment_1_c41140289f9b062e96cfd5d9d5382155._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-10-21T16:33:25Z"
+ content="""
+The webapp only shows drives the user can write to, because
+in general, there are a vast number of mounted things in modern
+OS's that the user would be very puzzled to see listed as removable
+drives. Such as tmpfs and cgroup mount points, and efi boot partitions.
+Complicating the webapp with knowledge to filter such things out would be a
+constantly losing battle.
+
+I guess it would be ok to add a "not listed here?" link in the webapp
+that allowed chosing from a full list or entering the path by hand.
+"""]]
diff --git a/doc/todo/show_readonly_removable_drives_in_the_webapp/comment_2_b9236ea884a2934dd0c8e511a80f4fda._comment b/doc/todo/show_readonly_removable_drives_in_the_webapp/comment_2_b9236ea884a2934dd0c8e511a80f4fda._comment
new file mode 100644
index 0000000000..9aa4c179e6
--- /dev/null
+++ b/doc/todo/show_readonly_removable_drives_in_the_webapp/comment_2_b9236ea884a2934dd0c8e511a80f4fda._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ ip="70.83.139.100"
+ subject="comment 2"
+ date="2014-10-30T15:15:57Z"
+ content="""
+yep, that would be fine.
+"""]]
diff --git a/doc/todo/show_time_of_last_interaction_with_a_repo.mdwn b/doc/todo/show_time_of_last_interaction_with_a_repo.mdwn
new file mode 100644
index 0000000000..315fdf91f8
--- /dev/null
+++ b/doc/todo/show_time_of_last_interaction_with_a_repo.mdwn
@@ -0,0 +1 @@
+When [[`git-annex-info`|git-annex-info]] lists repos, it can be unclear which ones are still "active".   It would help if the info command showed the time of last interaction for each repo.  Seems like the code to determine that already exists in [[`git-annex-expire`|git-annex-expire]]?
diff --git a/doc/todo/show_time_of_last_interaction_with_a_repo/comment_1_4ec9597df62dc4a2f7320f13f6a0ee8e._comment b/doc/todo/show_time_of_last_interaction_with_a_repo/comment_1_4ec9597df62dc4a2f7320f13f6a0ee8e._comment
new file mode 100644
index 0000000000..bfe89f7e60
--- /dev/null
+++ b/doc/todo/show_time_of_last_interaction_with_a_repo/comment_1_4ec9597df62dc4a2f7320f13f6a0ee8e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Lukey"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="comment 1"
+ date="2021-03-30T16:01:03Z"
+ content="""
+You can use `git annex expire` with a small expire time period to list the last (fsck) activity of all repos. Like `git annex expire --no-act 1s`.
+"""]]
diff --git a/doc/todo/show_time_of_last_interaction_with_a_repo/comment_1_997d9968782f7fd96d9edd9c380a3ee9._comment b/doc/todo/show_time_of_last_interaction_with_a_repo/comment_1_997d9968782f7fd96d9edd9c380a3ee9._comment
new file mode 100644
index 0000000000..2108cea942
--- /dev/null
+++ b/doc/todo/show_time_of_last_interaction_with_a_repo/comment_1_997d9968782f7fd96d9edd9c380a3ee9._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-03-30T15:46:54Z"
+ content="""
+That is limited to fsck activities, so adding a display of specifically the
+last time a repo was fscked seems better than a more open-ended thing if
+it's going to use that information.
+
+But, I don't think that indicating which repos were fscked recently is
+likely to really determine which repos are active.
+
+And I don't think there's any cheap enough way to get at perhaps more general
+activity, such as changes to the content of a remote. Also a remote could
+have its contents unchanging and still be actively used frequently to
+access the data stored in it.
+
+I wonder if perhaps using group information in git-annex info's list of
+repositories could address the same need. If nothing else you could
+put repos into an "active" group manually.
+
+Maybe something like this:
+
+	semitrusted repositories:
+		uuid -- foo@bar [origin] (active, transfer)
+		uuid -- foo@bla
+		uuid -- foo@baz [here] (active, client)
+		uuid -- foo@whatever
+		uuid -- foo@xyzzy (backup)
+
+There could be a switch to filter to a specific group.
+"""]]
diff --git a/doc/todo/simpler__44___trusted_export_remotes.mdwn b/doc/todo/simpler__44___trusted_export_remotes.mdwn
new file mode 100644
index 0000000000..33944b11ee
--- /dev/null
+++ b/doc/todo/simpler__44___trusted_export_remotes.mdwn
@@ -0,0 +1,5 @@
+Currently, some issues impede the use of export remotes: (1) they're untrusted, except for versioned ones -- and from  those keys cannot be dropped; (2) using them is different than using normal remotes: one can't just copy or move keys to them, one has to first make a tree-ish.   Maybe this could be fixed, as follows.   To copy a key to an export remote, if the key is not yet present in it, put it under .keys/aaa/bbb/keyname on the remote.  That is, take the tree-ish currently on the remote, merge .keys/aaa/bbb/keyname with it, and put that on the remote.   To drop a key from an external remote, take the tree-ish currently on the remote, drop all instances of the key from it, and push the changed tree-ish to the remote.  To git-annex-export add an option --add , which will add the tree-ish to the tree-ish currently on the remote, without losing any keys currently on the remote: take the tree-ish currently on the remote; overlay on it the treeish being exported; for any files that would be overwritten, if no copies of that key would be left, move it to .keys/aaa/bbb/keyname in the tree-ish that is then pushed to the remote.
+
+This way, can always just copy any tree to the remote, without worrying about losing data.
+
+[[!tag needsthought]]
diff --git a/doc/todo/simpler__44___trusted_export_remotes/comment_1_cc6a862519677ea18f78d24f40a48be1._comment b/doc/todo/simpler__44___trusted_export_remotes/comment_1_cc6a862519677ea18f78d24f40a48be1._comment
new file mode 100644
index 0000000000..787de28131
--- /dev/null
+++ b/doc/todo/simpler__44___trusted_export_remotes/comment_1_cc6a862519677ea18f78d24f40a48be1._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-03-19T17:06:50Z"
+ content="""
+This is essentially using namespacing on the remote to implement an
+equivilant of S3 versioning, though with less efficiency.
+
+A remote's implementation could do the same thing and claim it supports
+versioning, without any change to the current remote interface or user
+interface.
+
+Except for removing versioned content, which indeed would need to update
+the tree to reflect the removal. From Remote.Helper.ExportImport:
+
+                -- Removing a key from an export would need to
+                -- change the tree in the export log to not include
+                -- the file. Otherwise, conflicts when removing
+                -- files would not be dealt with correctly.
+                -- There does not seem to be a good use case for
+                -- removing a key from an export in any case.
+                , removeKey = \_k -> do
+                        warning "dropping content from an export is not supported; use `git annex export` to export a tree that lacks the
+                        return False
+
+I think that there are two separate things here that of course would work
+well together, but neither depends on the other. Generic versioning via
+namespacing could be done with or without support for removeKey (and vice-versa).
+"""]]
diff --git a/doc/todo/simpler__44___trusted_export_remotes/comment_2_5528a5dd5f8d7746b175552a077ba313._comment b/doc/todo/simpler__44___trusted_export_remotes/comment_2_5528a5dd5f8d7746b175552a077ba313._comment
new file mode 100644
index 0000000000..850ea00103
--- /dev/null
+++ b/doc/todo/simpler__44___trusted_export_remotes/comment_2_5528a5dd5f8d7746b175552a077ba313._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-03-19T20:40:49Z"
+ content="""
+\"A remote's implementation could do the same thing\" -- right, but if git-annex implements this (through the current special remote protocol) then one implementation covers all export-supporting remotes.  Also, implementing special remotes would become simpler, since they could just implement the export part of the protocol, and the key-value store then gets implemented in terms of that. But the main plus would be the uniformity: export remotes would be key-value remotes with an added ability (to store files in human-readable locations), rather than a separate untrustworthy species.
+"""]]
diff --git a/doc/todo/simpler__44___trusted_export_remotes/comment_3_3e7be2ba92559a767ea09b764daef2db._comment b/doc/todo/simpler__44___trusted_export_remotes/comment_3_3e7be2ba92559a767ea09b764daef2db._comment
new file mode 100644
index 0000000000..0506ae72a8
--- /dev/null
+++ b/doc/todo/simpler__44___trusted_export_remotes/comment_3_3e7be2ba92559a767ea09b764daef2db._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-03-22T14:10:41Z"
+ content="""
+I'm doubtful that this would actually let the interface be simplified,
+there are too many differences in the capabilities of different remotes.
+
+For example, if a S3 bucket has versioning disabled, and git-annex imports
+from it, then in this scheme it would need to re-upload the import to the
+key-value location. But, if a S3 bucket has versioning enabled, that upload
+would be redundant and should not be done. And, if a S3 bucket is
+read-only, then an import can't re-upload.
+
+Also, not all users are going to want export remotes to store past versions 
+of files; if they're used for some kind of publication, you may not want
+the exposure/cost of publishing old versions of files there. Of course, you
+could drop the old versions from the remote later, but this would be a
+workflow change from how export remotes work now.
+
+So it seems to me that this would need to be an optional thing.
+"""]]
diff --git a/doc/todo/simpler__44___trusted_export_remotes/comment_4_be525962211e8c4da681279aba132c71._comment b/doc/todo/simpler__44___trusted_export_remotes/comment_4_be525962211e8c4da681279aba132c71._comment
new file mode 100644
index 0000000000..c011b98d1a
--- /dev/null
+++ b/doc/todo/simpler__44___trusted_export_remotes/comment_4_be525962211e8c4da681279aba132c71._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="simplifying the interface"
+ date="2019-03-26T17:40:32Z"
+ content="""
+\"I'm doubtful that this would actually let the interface be simplified\" -- I only meant that the minimum required interface would be simplified, in that git-annex could provide a default implementation of key-value remote methods in terms of the export remote interface; but any given remote could provide a more efficient implementation of these methods, overriding the default ones.
+
+But the main benefit would be to simplify the user-facing interface: as far as the user is concerned, all special remotes could be trusted, and accessed with the same basic commands, whether configured as export or not.
+
+\"if a S3 bucket is read-only, then an import can't re-upload.\" -- if the special remote is configured as read-only, then git-annex itself would not attempt to upload things there, no?
+
+\"not all users are going to want export remotes to store past versions of files\" -- maybe, there could be an option to store past versions encrypted, while storing current versions plain?
+"""]]
diff --git a/doc/todo/simpler__44___trusted_export_remotes/comment_5_aeefb4803340ff993a1d6673c8e5e97b._comment b/doc/todo/simpler__44___trusted_export_remotes/comment_5_aeefb4803340ff993a1d6673c8e5e97b._comment
new file mode 100644
index 0000000000..254da7d79a
--- /dev/null
+++ b/doc/todo/simpler__44___trusted_export_remotes/comment_5_aeefb4803340ff993a1d6673c8e5e97b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 5"
+ date="2019-03-26T18:27:04Z"
+ content="""
+Another approach would be to let a key-value remote and an export remote be combined into one \"combo\" remote.  To the user, this would look like one trusted, versioned remote supporting both key-value and export operations.  Keys overwritten in the export remote would be stored in the key-value remote. Either keys or trees could be copied to the combo remote, keys going to the key-value remote and trees to the export remote.  The downside is that files could not be moved directly between the backing remotes.  But the inefficiency might not always matter. Also, TRANSFER and TRANSFEREXPORT could be extended to optionally accept URIs in lieu of content, and to do the transfer in the cloud.
+
+More generically, maybe repository groups could be treated as special remotes?  You'd configure the minimum number of copies of a key in a group.  You could then put a key-value remote and an export remote in a group.  When copying a tree to the group, if this would cause old keys to be overwritten, git-annex would first copy them to a key-value remote in the group, to preserve the per-group minimum number of copies constraint.
+
+"""]]
diff --git a/doc/todo/simpler__44___trusted_export_remotes/comment_6_0d27b08792112cbee7a368bc94044bb4._comment b/doc/todo/simpler__44___trusted_export_remotes/comment_6_0d27b08792112cbee7a368bc94044bb4._comment
new file mode 100644
index 0000000000..066a51aeee
--- /dev/null
+++ b/doc/todo/simpler__44___trusted_export_remotes/comment_6_0d27b08792112cbee7a368bc94044bb4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2020-01-30T18:05:29Z"
+ content="""
+I think that the --sameas feature could be used to implement those combo remotes?
+"""]]
diff --git a/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type.mdwn b/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type.mdwn
new file mode 100644
index 0000000000..bcc9dc9ff2
--- /dev/null
+++ b/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type.mdwn
@@ -0,0 +1,17 @@
+ATM I do not see any obvious way to get a list of options supported by a special remote of a given type.
+
+manpage says
+
+       The remote's configuration is specified by the parameters passed to this command. Different types of special remotes need  different  configura‐
+       tion values. The command will prompt for parameters as needed.
+
+and indeed I get asked for e.g. encryption to be explicitly specified (why not to default to none). But it would not even complain if I specify some bogus (mistyped etc) option.  I do not see any way (tried different --help's etc) to figure out what options any given special remote actually supports without going online to e.g. https://git-annex.branchable.com/special_remotes/rsync/ for `rsync` special remote.  It makes configuration of special remotes not a trivial matter for new users.  IMHO there should be some way (mentioned in man of initremote and enableremote) to get information about supported by the remote options, e.g. `git annex getremoteopts TYPE` or alike.  I am not sure how it should/would work for custom special remotes since I think protocol ATM doesn't support querying for a list of configuration options.  May be `GETCONFIG` interface command could be extended to return a list with of options with description? or some new command be added?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[done]] as eg `git annex initremote type=rsync --whatelse`.
+> 
+> External special remotes that implement LISTCONFIGS can also be queried:
+> 
+> 	git annex inittype type=external externaltype=foo --whatelse
diff --git a/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_1_8ea993d1acc92f3aa9594ed8e2d3ec7d._comment b/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_1_8ea993d1acc92f3aa9594ed8e2d3ec7d._comment
new file mode 100644
index 0000000000..56431892f7
--- /dev/null
+++ b/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_1_8ea993d1acc92f3aa9594ed8e2d3ec7d._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-02-07T15:57:26Z"
+ content="""
+The remote options could be part of option parsing, and then --help would
+list them.
+
+That was not originally done because the option parser was too crude
+to support options specific not only to a given command but to a given type
+of special remote, but with optparse-applicative, it could certianly be done.
+
+I don't know about supporting it in the external special remote protocol
+though. Communicating the full power of applicative option parsing over
+that pipe would add a great deal of complexity. 
+And it would need to retain backwards compatibility.
+
+Also, since git-annex doesn't know the name of the external special remote
+to use until it's parsed the command line options, it wouldn't really
+be possible to use any information from externals to configure the option
+parsing.
+
+Kind of feels like the simplest thing with externals would be best, and
+that's probably something like a "CONFIGSYNOPSIS" that lets the external
+answer with a preformatted string describing its options for display to the
+user.
+
+(Encryption needing to be explicitly disabled is a good thing, I think; it
+avoids any confusion about it.)
+"""]]
diff --git a/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_2_96fae68472f7f9ef720c27149556f7a0._comment b/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_2_96fae68472f7f9ef720c27149556f7a0._comment
new file mode 100644
index 0000000000..47fd2773dc
--- /dev/null
+++ b/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_2_96fae68472f7f9ef720c27149556f7a0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-02-14T17:20:27Z"
+ content="""
+Sweet, thanks for the feature!
+
+I wondered, why `--whatelse` which has no semantic relation to \"parameter\" or \"config\", and not something like `--help-params`, `--help-configs`, or `--listconfigs` to relate it to either PARAMS (as --help reports configs) or LISTCONFIGS protocol command?
+"""]]
diff --git a/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_3_b75ffc63f0e9a85c3d1f01bdce21c97c._comment b/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_3_b75ffc63f0e9a85c3d1f01bdce21c97c._comment
new file mode 100644
index 0000000000..34ccd48f6d
--- /dev/null
+++ b/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_3_b75ffc63f0e9a85c3d1f01bdce21c97c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-02-17T15:57:28Z"
+ content="""
+I stuggled with naming this option. I did consider something 
+with "config" (redundant with other configs), or "parameter"
+or "option" (redundant with other options). It was 
+--describe-other-params for a while but that was too long to type.
+
+--help would be the best name, but tying it into the main option parser is
+impractical; amoung other things it would make tab completion need to
+somehow run external special remotes to get a list of their parameters!
+
+The mnemonic for --whatelse, such as it is: You've gotten at least as
+far as type= (without which it won't work and will prompt for that),
+and want to know what else you can configure.
+"""]]
diff --git a/doc/todo/specify_gitconfig_for_test_suite.mdwn b/doc/todo/specify_gitconfig_for_test_suite.mdwn
new file mode 100644
index 0000000000..78cf7d78f5
--- /dev/null
+++ b/doc/todo/specify_gitconfig_for_test_suite.mdwn
@@ -0,0 +1,8 @@
+`git-annex test` prevents ~/.gitconfig or /etc/gitconfig from being read.
+The `-c` option also doesn't propagate into the test suite. 
+
+It would sometimes be useful to test git-annex with a given git config set.
+Although some might break the test suite, others might expose actual bugs
+in git-annex. --[[Joey]]
+
+> Added "--test-git-config" option, [[done]] --[[Joey]]
diff --git a/doc/todo/speculate-can-get___58___extension_of_speculate-present.mdwn b/doc/todo/speculate-can-get___58___extension_of_speculate-present.mdwn
new file mode 100644
index 0000000000..4d920d2123
--- /dev/null
+++ b/doc/todo/speculate-can-get___58___extension_of_speculate-present.mdwn
@@ -0,0 +1,6 @@
+Add `remote.<name>.annex-speculate-can-get` config setting for non-special remotes, with the meaning "speculate that the remote knows how to get the key".  It's like `remote.<name>.annex-speculate-present`, except you'd first try [[`git-annex-get`|git-annex-get]] in the remote before looking in its annex.
+
+Then one can make a quick clone of the current repo, and instead of re-configuring all its remotes in the new clone, just configure the origin to be a `speculate-can-get` remote.
+This would also be useful when you have unconnected but related repos, and want to occasionally share files between them without merging their histories.
+
+[[!tag needsthought]]
diff --git a/doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_1_264538d1cbf07254a2857ca4cf40e9ac._comment b/doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_1_264538d1cbf07254a2857ca4cf40e9ac._comment
new file mode 100644
index 0000000000..9447c5118b
--- /dev/null
+++ b/doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_1_264538d1cbf07254a2857ca4cf40e9ac._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-05-03T15:39:07Z"
+ content="""
+This would involve an extension to the P2P protocol to ask a remote to
+git-annex get a key from its remotes.
+
+But, I'd worry this could be abused. Imagine for example that you have
+published a sanitized dataset by cloning the complete dataset and getting
+only the files you wish to publish, and then exposed that over the P2P
+protocol, with a locked-down ssh key. Such a new feature would make this
+previously secure setup be exploitable to expose the unsantizied data.
+
+In such a scenario, `GIT_ANNEX_SHELL_READONLY` might be set, and could be
+used to avoid the unwanted behavior. But consider, the repo might be
+publishing the sanitized dataset and also accepting uploads of derived data
+from the people who have been given ssh keys to use it and so not have
+readonly set.
+
+A DOS attack seems even more likely, where you've only gotten a subset of
+files into a particular clone to avoid using up too much disk space,
+and then this is used to get many more files than you want there. This
+could happen without a trust boundary as well. Of course, git-annex repos with
+the assistant running and a bad preferred content configuration can
+similarly download too much data, but that takes an explicit configuration.
+This would change a scenario where "git annex get --from remote" had just
+failed into one where it suddenly ran the remote out of disk.
+
+---
+
+There's also the problem that it could take the remote arbitrarily long to
+perform the get, and so would it need to send back progress information?
+And how would that indirect download progress info be presented to the
+user? Consider there could be a chain of several transfers. If it was
+possible to stream the file back to the requestor as the remote received
+it, the progress display would work as-is, but many file retrievals are not
+streamable.
+"""]]
diff --git a/doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_2_93450de83c4843f6828e971a948d12e3._comment b/doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_2_93450de83c4843f6828e971a948d12e3._comment
new file mode 100644
index 0000000000..148bbee123
--- /dev/null
+++ b/doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_2_93450de83c4843f6828e971a948d12e3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2019-05-03T16:11:06Z"
+ content="""
+How about limiting this to just the local non-special remotes, i.e. git clones of the repo?  Not ones accessible over ssh. And requiring the origin repo to have an explicitly set config setting, like annex.allow-speculate-can-get-from-this-repo, before it can be used that way.
+
+I was thinking of something much simpler / less powerful than what you're describing, but it would address the real use cases I have.
+
+git-annex already has several security settings that can expose data or enable attacks if used badly, but require enough explicit configuration that people who use them likely know what they're doing.
+"""]]
diff --git a/doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_3_272d66c3549892687879ef20e0cd9cf1._comment b/doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_3_272d66c3549892687879ef20e0cd9cf1._comment
new file mode 100644
index 0000000000..c30130f128
--- /dev/null
+++ b/doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_3_272d66c3549892687879ef20e0cd9cf1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2019-05-03T16:26:40Z"
+ content="""
+Re: disk space problem, can just drop the file from the `speculate-can-get` repo, after getting the file from it?  In my usage scenarios, `annex.hardlink` would also be on, so only one copy of the file would exist.
+"""]]
diff --git a/doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_4_8627a8073fe0b4c144f26d32626e0c1b._comment b/doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_4_8627a8073fe0b4c144f26d32626e0c1b._comment
new file mode 100644
index 0000000000..2e495ce3b5
--- /dev/null
+++ b/doc/todo/speculate-can-get___58___extension_of_speculate-present/comment_4_8627a8073fe0b4c144f26d32626e0c1b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2019-05-03T16:31:18Z"
+ content="""
+I guess this could also be implemented with a read-only external special remote, which has the path to the `speculate-can-get` clone as a config param, and `speculate-present` is then set to true for this external special remote.
+"""]]
diff --git a/doc/todo/speed_up_VURL_by_avoiding_redundant_hashing.mdwn b/doc/todo/speed_up_VURL_by_avoiding_redundant_hashing.mdwn
new file mode 100644
index 0000000000..56fdeced8b
--- /dev/null
+++ b/doc/todo/speed_up_VURL_by_avoiding_redundant_hashing.mdwn
@@ -0,0 +1,10 @@
+When a VURL key has multiple equivilant keys that all use the same hash,
+verifying the VURL key currently has to verify each equivilant key.
+Usually that is done incrementally, so it only has to read the file once. But it
+still does redundant work, updating each incremental verifier with each
+chunk.
+
+This could be improved by caclulating a hash once, and then compare it
+with a hash value exposed by the Backend. That seems doable but will mean
+extending the Backend interface, to expose the hash value and type.
+--[[Joey]] 
diff --git a/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests.mdwn b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests.mdwn
new file mode 100644
index 0000000000..3476c8e73e
--- /dev/null
+++ b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests.mdwn
@@ -0,0 +1,41 @@
+As part of the [datalad/git-annex](https://github.com/datalad/git-annex) builds setup there is work to enable testing on some target deployments, but there is problem (see [git-annex/pull/102#issuecomment-1054561966](https://github.com/datalad/git-annex/pull/102#issuecomment-1054561966)) that overall sweep of `git annex test` of the standalone build on a target system takes over 5,000 seconds (over an hour!).
+
+Clearly that system is "unique" in its "performance" (most likely due to nfs4'ed filesystem tests go under, not due to "Standalone" but I can't change the issue title at this moment) and here is the timing spread we see from other runs on CI:
+
+```shell
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2022/02[master]git
+$> git grep 'All 9.. tests passed (' | sort -t '(' -n -k 3 | head -n 5
+cron-20220222/build-ubuntu.yaml-586-85dd9355-failed/1_test-annex (normal, ubuntu-latest).txt:2022-02-22T02:57:08.4002055Z All 994 tests passed (239.44s)
+cron-20220222/build-ubuntu.yaml-586-85dd9355-failed/test-annex (normal, ubuntu-latest)/7_Run tests.txt:2022-02-22T02:57:08.4002052Z All 994 tests passed (239.44s)
+pr-102/build-ubuntu.yaml-600-12c9bb39-failed/1_test-annex (normal, ubuntu-latest).txt:2022-02-25T18:47:54.5577129Z All 994 tests passed (240.31s)
+pr-102/build-ubuntu.yaml-600-12c9bb39-failed/test-annex (normal, ubuntu-latest)/7_Run tests.txt:2022-02-25T18:47:54.5577125Z All 994 tests passed (240.31s)
+cron-20220225/build-ubuntu.yaml-595-85dd9355-failed/1_test-annex (normal, ubuntu-latest).txt:2022-02-25T03:01:16.8138190Z All 994 tests passed (240.87s)
+
+$> git grep 'All 9.. tests passed (' | sort -t '(' -n -k 3 | tail -n 5
+cron-20220227/build-macos.yaml-604-85dd9355-failed/test-annex (normal, macos-latest)/8_Run tests.txt:2022-02-27T02:32:31.2444240Z All 994 tests passed (1284.60s)
+cron-20220203/build-macos.yaml-578-85dd9355-success/3_test-annex (normal, macos-latest).txt:2022-02-03T02:27:38.5945050Z All 991 tests passed (1292.09s)
+cron-20220203/build-macos.yaml-578-85dd9355-success/test-annex (normal, macos-latest)/8_Run tests.txt:2022-02-03T02:27:38.5945040Z All 991 tests passed (1292.09s)
+manual-20220222/build-macos.yaml-599-85dd9355-failed/3_test-annex (normal, macos-latest).txt:2022-02-22T18:44:42.5220730Z All 994 tests passed (1340.62s)
+manual-20220222/build-macos.yaml-599-85dd9355-failed/test-annex (normal, macos-latest)/8_Run tests.txt:2022-02-22T18:44:42.5220720Z All 994 tests passed (1340.62s)
+```
+
+so we have runs as short as 4 minutes (`cron-20220222/build-ubuntu.yaml-586-85dd9355-failed`) and as "long" as 20 minutes (`manual-20220222/build-macos.yaml-599-85dd9355-failed`) .
+
+but at >5k seconds it made me wonder if worth looking into making operation on such system a bit more "snappy".  FWIW, here are the slowest tests:
+
+```
+[d31548v@discovery7 git-annex]$ grep 's)' tests.out | sort -t '(' -n -k 2 | tail -n 10
+    conflict resolution:                                  OK (55.24s)
+    adjusted branch merge regression:                     OK (56.63s)
+    conflict resolution movein regression:                OK (60.02s)
+    transition propagation:                               OK (60.61s)
+OK (61.00s)
+OK (70.30s)
+OK (78.37s)
+    union merge regression:                               OK (91.15s)
+    transition propagation:                               OK (97.68s)
+All 994 tests passed (5576.99s)
+
+```
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_10_0e070bc39eb0b8d9cf307af8a06504dc._comment b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_10_0e070bc39eb0b8d9cf307af8a06504dc._comment
new file mode 100644
index 0000000000..0c2d092239
--- /dev/null
+++ b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_10_0e070bc39eb0b8d9cf307af8a06504dc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 10"
+ date="2022-03-16T20:32:57Z"
+ content="""
+Awesome -- thank you ! I will give it a test use after the next daily build.
+"""]]
diff --git a/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_1_41749c4c9b317a58e02df99f748844a1._comment b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_1_41749c4c9b317a58e02df99f748844a1._comment
new file mode 100644
index 0000000000..bcf8307548
--- /dev/null
+++ b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_1_41749c4c9b317a58e02df99f748844a1._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-03-01T18:06:32Z"
+ content="""
+Since you mentioned standalone builds, I suspect you are running
+something like: "cd git-annex.linux; ./git-annex test"
+
+I have verified that is much much slower than running git-annex not
+from the standalone build. On the order of 1+ hours vs 5 minutes.
+
+There is a simple workaround, run "git-annex.linux/git-annex"
+from somewhere outside the standalone build. That will make it much faster.
+Here it takes about 5 minutes.
+
+With that said, there's still a lot of room to speed up git-annex
+test, and the main thing would probably be to parallelize its tests.
+Which can be done, but needs tasty-1.2. That finally made it into debian
+stable, so it should be able to depend on it now. I would not be surprised
+if it can be sped up 10x that way, because tests often have to wait one or
+more seconds after writing a file due to time stamp issues etc.
+I have created a `paralleltest` branch with a start on that, not yet working.
+"""]]
diff --git a/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_2_f462ee4719b4c459c12e36ce29ab82b5._comment b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_2_f462ee4719b4c459c12e36ce29ab82b5._comment
new file mode 100644
index 0000000000..03a1db490a
--- /dev/null
+++ b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_2_f462ee4719b4c459c12e36ce29ab82b5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-03-01T19:58:37Z"
+ content="""
+I have fixed the problem I identified, which was due to git-annex test adding
+the cwd to PATH, which caused it to run git-annex.linux/git, so runshell
+was being run repeatedly and unncessarily.
+
+Now it will run git-annex.linux/bin/git and avoid the repeated runshell
+overhead, so will be about as fast as git-annex not run from the standalone
+tarball.
+"""]]
diff --git a/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_3_dfd20b6c6a49c99243945a267e041d58._comment b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_3_dfd20b6c6a49c99243945a267e041d58._comment
new file mode 100644
index 0000000000..82b3acb149
--- /dev/null
+++ b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_3_dfd20b6c6a49c99243945a267e041d58._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="still slow"
+ date="2022-03-08T00:27:59Z"
+ content="""
+I have ran tests with \"bleeding edge\" build of `git-annex` on ndoli (less busy node) of discovery and unfortunately it is still quite slow -- took 50 minutes
+
+<details>
+<summary>more details</summary> 
+
+```shell
+> time git annex test 2>&1 | tee 10.20220222+git62-gce523f756-1~ndall+1-tests.log
+...
+OK (71.94s)
+    preferred content:                                    OK (34.75s)
+    required_content:                                     OK (17.34s)
+    add subdirs:                                          OK (12.63s)
+    addurl:                                               OK (10.71s)
+
+All 840 tests passed (2670.47s)
+
+real    48m52.802s
+user    3m23.073s
+sys     4m53.776s
+
+[d31548v@ndoli tmp]$ git annex version | head
+git-annex version: 10.20220222+git62-gce523f756-1~ndall+1
+...
+
+[d31548v@ndoli tmp]$ pwd
+/dartfs-hpc/rc/lab/C/CANlab/labdata/data/tmp
+
+```
+</details>
+
+so there is probably more to the story (NFS), or probably  needing nfs4_*etfacl?  well -- I ran under a folder which should be proper POSIX -- took  5075.48s (the same 10.20220222+git62-gce523f756-1~ndall+1)
+"""]]
diff --git a/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_4_650e5dd2471cdfd0223d712771067d55._comment b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_4_650e5dd2471cdfd0223d712771067d55._comment
new file mode 100644
index 0000000000..678bd3cd5a
--- /dev/null
+++ b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_4_650e5dd2471cdfd0223d712771067d55._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-03-08T18:16:40Z"
+ content="""
+One thing I notice is that the test suite reports
+it took 44 minutes (2670 seconds), but time reports
+49 minutes. Those additional 5 minutes must be the test
+suite cleaning up the test directories. Which fits with NFS.
+That is 5 minutes to effectively `rm -rf` maybe 20k directories/files.
+
+Also, you originally said it took more than 1 hour (or perhaps more
+than 5000 seconds, which would be 1.4 hours). So it seems that my fix did 
+have a significant impact on speed. 
+
+What I see benchmarking locally is that the standalone tarball takes 1016 
+seconds (down from 3600+), while a bare git-annex binary takes 614 seconds.
+That is probably due to the small overhead (100 failed opens) discussed in
+[[this_old_todo|todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__]],
+multiplied by the thousands of times the test suite runs git-annex.
+
+Parallelizing the test suite seems like the only way to get a substantial
+speedup.
+"""]]
diff --git a/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_5_0ee51fffee1f591173418212919bcd30._comment b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_5_0ee51fffee1f591173418212919bcd30._comment
new file mode 100644
index 0000000000..388e95c0b5
--- /dev/null
+++ b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_5_0ee51fffee1f591173418212919bcd30._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-03-08T19:43:01Z"
+ content="""
+Re that 5 minutes to clean up, I tried making it clean up test directories
+in the background while running other tests. Interestingly, that slowed
+it down here by 33 seconds (5%). Due to disk IO contention I suppose?
+(SSD)
+
+Makes me wonder how much benefit parallelism would be..
+"""]]
diff --git a/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_6_b4aecfd9f1b7f0e16d5f1dcb3c16af3e._comment b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_6_b4aecfd9f1b7f0e16d5f1dcb3c16af3e._comment
new file mode 100644
index 0000000000..5bdd08053d
--- /dev/null
+++ b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_6_b4aecfd9f1b7f0e16d5f1dcb3c16af3e._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-03-08T19:47:12Z"
+ content="""
+@yoh It would be interesting if you could check the speed on NFS when bypassing
+the standalone build's overhead by running
+`git-annex.linux/shimmed/git-annex/git-annex test`
+
+That will not use the bundled libraries and programs, but if the test
+system is reasonably similar to the build system it would still work.
+
+It's good you're testing the standalone build works, but I think this
+test is about testing NFS really, so you could leave the standalone build
+testing to other test runs than this one, if that is a significant speedup.
+"""]]
diff --git a/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_7_e11ae8ba6dd6e6c53891db954d28bfff._comment b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_7_e11ae8ba6dd6e6c53891db954d28bfff._comment
new file mode 100644
index 0000000000..517af1ead8
--- /dev/null
+++ b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_7_e11ae8ba6dd6e6c53891db954d28bfff._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-03-10T17:58:07Z"
+ content="""
+I tried as an experiment, opening 5 terminals, and running each of the 5
+main groups of tests in parallel manually, each command in a different
+directory:
+
+	git-annex test -p Tests.QuickCheck
+	git-annex test -p Tests.Remote
+	git-annex test -p 'Tests.Unit Tests v8 locked'
+	git-annex test -p 'Tests.Unit Tests v8 unlocked'
+	git-annex test -p 'Tests.Unit Tests v8 adjusted unlocked branch'
+
+They took, respectively, 34, 58, 159, 154, and 220 seconds. Compared to a
+sequential runtime of 444 seconds, this shows it can be sped up well by
+parallelism at least in some cases. Seems likely that splitting up the
+slower blocks further and having 8 groups of tests could make it faster yet.
+
+@yoh, it would be interesting if you could try this on the NFS system and
+see if it speeds it up enough.
+
+---
+
+Tasty does not seem to have a way for parallel forks of the test program
+to report back their status in a way that will be combined together. That
+does seem like something that could perhaps be added to it in a nice clean
+way. 
+
+But, a quick hack is also possible: Have git-annex test fork off one child
+process per each of these groups, and serialize the output. Using
+--color=always when at the console and using concurrent-output to stream
+one of the currently running tests while buffering the rest for later
+display should make this almost indistinguishable from the "right" way.
+Would also need to detect some tasty options and fall back to running it
+normally.
+
+This approach would avoid the problem I hit on the `paralleltest` branch of
+needing to rewrite all the testing code to not run chdired into the repo
+in order to make it able to be run in parallel. That would be a lot of
+work, and would also make it harder to write new tests, since it would be
+easy to make a mistake that caused a test to write outside the test
+repo.
+"""]]
diff --git a/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_8_b06360071e05df18b895322382357b61._comment b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_8_b06360071e05df18b895322382357b61._comment
new file mode 100644
index 0000000000..da6246634c
--- /dev/null
+++ b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_8_b06360071e05df18b895322382357b61._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-03-14T18:52:09Z"
+ content="""
+I have implemented parallelism as described in comment 7. 
+
+Currently there are 5 child processes, and the test runtime
+dropped from 444 to 334 seconds on my laptop.
+Splitting up the test groups further, so there are more child
+processes will probably improve that more.
+Remains to be seen if it helps on NFS much..
+
+The `git-annex test` output is currently a mess, it needs to be serialized.
+Ran out of time to do that today, but the speed improvement is worth
+temporarily ugly output.
+"""]]
diff --git a/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_9_2253c6916a1c6e4f1393b8656617aa10._comment b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_9_2253c6916a1c6e4f1393b8656617aa10._comment
new file mode 100644
index 0000000000..3050c2dd35
--- /dev/null
+++ b/doc/todo/speed_up___34__standalone_build__34___and__47__or_tests/comment_9_2253c6916a1c6e4f1393b8656617aa10._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-03-16T17:55:52Z"
+ content="""
+I've finished up parallelizing git-annex test.
+
+Splitting up the test groups further and improved scheduling sped it up more.
+On my laptop, it's dropped from 444 to 334 to now 289 seconds.
+
+Also, the `-J` option is now supported by git-annex test, so you can experiment
+to find the number of jobs where it runs fastest in your particular situation.
+The default is one job per CPU core.
+
+My guess is that on NFS, it's not CPU bound but is network latency bound,
+and so a rather high -J value like -J10 may behave better.
+"""]]
diff --git a/doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn b/doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn
new file mode 100644
index 0000000000..a4fc7a1938
--- /dev/null
+++ b/doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn
@@ -0,0 +1,105 @@
+The --hide-missing and --unlock-present adjusted branches
+depend on whether the content of a file is present. So after a get or drop,
+the branch needs to be updated to reflect the change. 
+
+To avoid the user needing to do it manually, the 
+annex.adjustedbranchrefresh config automates it now. That is not yet
+enabled by default, because it can be slow. 
+
+Can it be done efficiently enough to become default?
+And how frequently can it update without being too slow?
+After every file or after some number of files, or after processing
+all files in a (sub-)tree, or only once at the end of a command?
+
+The config was designed as a numeric scale with the hope that it might
+later become a simple boolean if it got fast enough. Since 0 is false
+and > 0 is true, in git config, the old values will still work.
+
+Investigation of the obvious things that make it slow follows:
+
+## efficient branch adjustment
+
+updateAdjustedBranch re-adjusts the whole branch. That is inneficient for a
+branch with a large number of files in it. We need a way to incrementally
+adjust part of the branch.
+
+(Or maybe not *need* because maybe it's acceptable for it to be slow; slow
+is still better than manual, probably.)
+
+Git.Tree.adjustTree recursively lists the tree and applies
+the adjustment to each item in it. What's needed is a way to
+adjust only the subtree containing a file, and then use 
+Git.Tree.graftTree to graft that into the existing tree. Seems quite
+doable!
+
+graftTree does use getTree, so buffers the whole tree object in memory.
+adjustTree avoids doing that. I think it's probably ok though; git probably
+also buffers tree objects in memory. Only the tree objects down to the
+graft point need to be buffered.
+
+Oh, also, it can cache a few tree objects to speed
+this up more. Eg after dropping foo/bar/1 buffer foo and foo/bar's
+objects, and use that when dropping foo/bar/2.
+
+## efficient checkout
+
+updateAdjustedBranch checks out the new version of the branch.
+
+git checkout needs to diff the old and new tree, and while git is fast,
+it's not magic. Consider if, after every file dropped, we checked out a new
+branch that did not contain that file. Dropping can be quite fast,
+thousands of files per second.. How much would those git checkouts
+slow it down?
+
+I benchmarked to find out. (On an SSD)
+
+	for x in $(seq 1 10000); do echo $x > $x; git add $x; git commit -m add; done
+
+	time while git checkout --quiet HEAD^;do : ; done
+	real	5m59.489s
+	user	4m34.775s
+	sys	3m39.665s
+
+Seems like git-annex could do the equivilant of checkout more quickly,
+since it knows the part of the branch that changed. Eg, git rm the file,
+and update the sha1 that HEAD points to.
+
+## dangling git objects
+
+Incremental adjusting would generate new trees each time, and a new commit.
+If it's done a lot, those will pile up. They get deleted by gc, but
+normally would only be deleted after some time. Perhaps git-annex could
+delete them itself. (At least if they remain loose git objects; deleting
+them once they reach a pack file seems hard.)
+
+(The tree object buffer mentioned above suggests the approach of,
+when an object in the buffer gets replaced with another object for the same
+tree position, delete the old object from .git/objects.)
+
+A git repo containing 10000 commits, starting with 10000 files and ending
+with 0, deleting 1 file per commit, weighs in at 99mb. That's with
+short filenames, more typical filenames would add to it. (It packs down to
+9 mb, but that's just extra work for objects that will get gc'ed away
+eventually.)
+
+## slowness in writing git objects
+
+git-annex uses git commit-tree to create new commits on the adjusted
+branch. That is not batched, so running once per file may get slow.
+
+And to write trees, it uses git mktree --batch. But, a new process is
+started each time by Git.Tree.adjustTree (and other things). 
+Making that a long-running process would speed it up, probably.
+
+## queue flush slowness
+
+It uses Annex.Queue.flush to avoid a problem with dropping files,
+which depopuates the pointer file, which git sees as modified until
+restaged, which then prevents checking out the version of the branch where
+the pointer file is a symlink. There must be a less expensive way to handle
+that.
+
+(All the extra "(recording state in git...)" when dropping
+are due to it doing that too.)
+
+[[!tag confirmed]]
diff --git a/doc/todo/speed_up_drop_on___34__heavy__34___repo.mdwn b/doc/todo/speed_up_drop_on___34__heavy__34___repo.mdwn
new file mode 100644
index 0000000000..0944b862ef
--- /dev/null
+++ b/doc/todo/speed_up_drop_on___34__heavy__34___repo.mdwn
@@ -0,0 +1,38 @@
+On [this monster repo](https://github.com/dandisets/000108.git) with only 2290 files in worktree covering 168.57TB, it spends many seconds for each key drop
+
+Here running serially with `--debug` I see
+
+```
+[2022-01-03 13:07:53.229582] (Command.Drop) Dropping from here proof: Just (SafeDropProof (NumCopies 1) (MinCopies 1) [RecentlyVerifiedCopy UUID "00000000-0000-0000-0000-000000000001"] (Just (ContentRemovalLock (MkKey {keyData = Key {keyName = "32376dfb94d171b1b51c0829d4071fee14be0bbde6f270d2c102312851fbdfb3.h5", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 45210151184, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s45210151184--32376dfb94d171b1b51c0829d4071fee14be0bbde6f270d2c102312851fbdfb3.h5"}))))
+[2022-01-03 13:08:02.026986] (Annex.Branch) read 381/7a1/SHA256E-s45210151184--32376dfb94d171b1b51c0829d4071fee14be0bbde6f270d2c102312851fbdfb3.h5.log
+[2022-01-03 13:08:02.058449] (Annex.Branch) set 381/7a1/SHA256E-s45210151184--32376dfb94d171b1b51c0829d4071fee14be0bbde6f270d2c102312851fbdfb3.h5.log
+```
+
+so took 8 seconds to come out from "Dropping" to the next one... and I think time it takes grows with every next file, here is a sample for some one after a few:
+
+```
+[2022-01-03 13:10:12.39011] (Command.Drop) Dropping from here proof: Just (SafeDropProof (NumCopies 1) (MinCopies 1) [RecentlyVerifiedCopy UUID "00000000-0000-0000-0000-000000000001"] (Just (ContentRemovalLock (MkKey {keyData = Key {keyName = "ee77e5c090543ab2128961cec827d1d07aa955ad60aa6843331ffdfc5fa2eeaf.h5", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 97264091411, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s97264091411--ee77e5c090543ab2128961cec827d1d07aa955ad60aa6843331ffdfc5fa2eeaf.h5"}))))
+[2022-01-03 13:10:37.962407] (Annex.Branch) read 47a/7fa/SHA256E-s97264091411--ee77e5c090543ab2128961cec827d1d07aa955ad60aa6843331ffdfc5fa2eeaf.h5.log
+[2022-01-03 13:10:37.982222] (Annex.Branch) set 47a/7fa/SHA256E-s97264091411--ee77e5c090543ab2128961cec827d1d07aa955ad60aa6843331ffdfc5fa2eeaf.h5.log
+
+```
+which is 25 seconds... then 40 ... although some go quickly
+
+```
+[2022-01-03 13:12:02.61183] (Command.Drop) Dropping from here proof: Just (SafeDropProof (NumCopies 1) (MinCopies 1) [RecentlyVerifiedCopy UUID "00000000-0000-0000-0000-000000000001"] (Just (ContentRemovalLock (MkKey {keyData = Key {keyName = "3a7397803d7af7ffaf323bd9b34f06e2e2b743c0687d911cd04352e6851e193f.h5", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 18094051444, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s18094051444--3a7397803d7af7ffaf323bd9b34f06e2e2b743c0687d911cd04352e6851e193f.h5"}))))
+[2022-01-03 13:12:04.213675] (Annex.Branch) read 4a1/f2c/SHA256E-s18094051444--3a7397803d7af7ffaf323bd9b34f06e2e2b743c0687d911cd04352e6851e193f.h5.log
+[2022-01-03 13:12:04.231074] (Annex.Branch) set 4a1/f2c/SHA256E-s18094051444--3a7397803d7af7ffaf323bd9b34f06e2e2b743c0687d911cd04352e6851e193f.h5.log
+```
+
+well -- filesystem (BTRFS) was busy doing its maintenance meanwhile (had to free up space), but still -- quite long wait times.  I interrupted that `drop`, waited for filesystem to settle down, repeated for some files -- still quite a long time, e.g.
+
+```
+[2022-01-03 14:58:09.411661] (Command.Drop) Dropping from here proof: Just (SafeDropProof (NumCopies 1) (MinCopies 1) [RecentlyVerifiedCopy UUID "00000000-0000-0000-0000-000000000001"] (Just (ContentRemovalLock (MkKey {keyData = Key {keyName = "3b0d2deef0223146e6edec86b7b96521349def252e9e26c25b46fc18067350ad.h5", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 25859843418, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = "SHA256E-s25859843418--3b0d2deef0223146e6edec86b7b96521349def252e9e26c25b46fc18067350ad.h5"}))))
+[2022-01-03 14:58:18.857103] (Annex.Branch) read 4e4/a95/SHA256E-s25859843418--3b0d2deef0223146e6edec86b7b96521349def252e9e26c25b46fc18067350ad.h5.log
+```
+
+NB not sure if related, prior long run with `-J3` was also getting CPU busy which made little sense to me for `drop`.  I will monitor CPU consumption in the next attempt.
+
+git annex 8.20211028-g1c76278
+
+[here is a full log](http://www.onerussian.com/tmp/long-drop-20220103-1.log).
diff --git a/doc/todo/speed_up_drop_on___34__heavy__34___repo/comment_1_5c92b3e7c2fc0e8a8e943690c1806322._comment b/doc/todo/speed_up_drop_on___34__heavy__34___repo/comment_1_5c92b3e7c2fc0e8a8e943690c1806322._comment
new file mode 100644
index 0000000000..95318f69c3
--- /dev/null
+++ b/doc/todo/speed_up_drop_on___34__heavy__34___repo/comment_1_5c92b3e7c2fc0e8a8e943690c1806322._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2022-01-03T20:03:38Z"
+ content="""
+FWIW: Re-running with -J3 right away made git-annex 200% CPU busy while --debug was showing
+
+```
+[2022-01-03 14:59:56.323517] (Command.Drop) Dropping from here proof: Just (SafeDropProof (NumCopies 1) (MinCopies 1) [RecentlyVerifiedCopy UUID \"00000000-0000-0000-0000-000000000001\"] (Just (ContentRemovalLock (MkKey {keyData = Key {keyName = \"c7e4ea78ccd5486983b9185b22cc67fa1f96df84630ae23e6bb2b63f3726f0d9.h5\", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 147972754129, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = \"SHA256E-s147972754129--c7e4ea78ccd5486983b9185b22cc67fa1f96df84630ae23e6bb2b63f3726f0d9.h5\"}))))
+[2022-01-03 14:59:56.347374] (Command.Drop) Dropping from here proof: Just (SafeDropProof (NumCopies 1) (MinCopies 1) [RecentlyVerifiedCopy UUID \"00000000-0000-0000-0000-000000000001\"] (Just (ContentRemovalLock (MkKey {keyData = Key {keyName = \"c658b317bf9bf35a8dc69eaff18899c7db5336d5b230ba8fbad88bd702344f6c.h5\", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 79593126729, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, keySerialization = \"SHA256E-s79593126729--c658b317bf9bf35a8dc69eaff18899c7db5336d5b230ba8fbad88bd702344f6c.h5\"}))))
+```
+
+-J2 makes it 100% busy .  -J1 - only 2% CPU and in D state.
+"""]]
diff --git a/doc/todo/speed_up_drop_on___34__heavy__34___repo/comment_2_a5587ebc2a406d52855868cdeb39b83e._comment b/doc/todo/speed_up_drop_on___34__heavy__34___repo/comment_2_a5587ebc2a406d52855868cdeb39b83e._comment
new file mode 100644
index 0000000000..60180fddb2
--- /dev/null
+++ b/doc/todo/speed_up_drop_on___34__heavy__34___repo/comment_2_a5587ebc2a406d52855868cdeb39b83e._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-01-05T16:59:08Z"
+ content="""
+Well, this could be anything that it happens to do in some situation to
+actually drop the file. That's what happens in the interval there.
+
+Are the files unlocked? It might be running git to update the index,
+which can take a long time.
+
+Is annex.secure-erase-command set? Such a command can take a long time.
+
+Otherwise, strace ...
+"""]]
diff --git a/doc/todo/speed_up_import_tree.mdwn b/doc/todo/speed_up_import_tree.mdwn
new file mode 100644
index 0000000000..7ec81d89cf
--- /dev/null
+++ b/doc/todo/speed_up_import_tree.mdwn
@@ -0,0 +1,50 @@
+Users sometimes expect `git-annex import --from remote` to be faster than
+it is, when importing hundreds of thousands of files, particularly
+from a directory special remote.
+
+I think generally, they're expecting something that is not achievable.
+It is always going to be slower than using git in a repository with that
+many files, because git operates at a lower level of abstraction (the
+filesystem), so has more optimisations available to it. (Also git has its
+own scalability limits with many files.)
+
+Still, it would be good to find some ways to speed it up.
+
+In particular, speeding up repeated imports from the same special remote,
+when only a few files have changed, would make it much more useful. It's ok
+to pay a somewhat expensive price to import a lot of new files, if updates
+are quick after that.
+
+---
+
+A major thing that makes it slow, when a remote contains 
+many files, is converting from ContentIdentifiers to Keys.
+It does a cidsdb lookup for every file, before it knows if the file has
+changed or not, which gets slow with a lot of files.
+
+What if it generated a git tree, where each file in the tree is
+a sha1 hash of the ContentIdentifier. The tree can just be recorded locally
+somewhere. It's ok if it gets garbage collected; it's only an optimisation.
+On the next sync, diff from the old to the new tree. It only needs to
+import the changed files, and can avoid the cidsdb lookup for the
+unchanged files!
+
+(That is assuming that ContentIdentifiers don't tend to sha1 collide.
+If there was a collision it would fail to import the new file. But it seems
+reasonable, because git loses data on sha1 collisions anyway, and ContentIdentifiers
+are no more likely to collide than the content of files, and probably less
+likely overall..)
+
+> I implemented this optimisation. Importing from a special remote that
+> has 10000 files, that have all been imported before, and 1 new file
+> sped up from 26.06 to 2.59 seconds. An import with no changes sped
+> up from 24.3 to 1.99 seconds. Going up to 20000 files, an import with
+> no changes sped up from 125.95 to 3.84 seconds.
+> (All measured with warm cache.)
+
+> (Note that I have only implemented this optimisation for imports that
+> do not include History. So importing from versioned S3 buckets will
+> still be slow. It would be possible to do a similar optimisation for
+> History, but it seemed complicated so I punted.) --[[Joey]]
+
+[[!meta title="speed up import tree from special remotes with history (eg S3 versioned bucket)"]]
diff --git a/doc/todo/speed_up_import_tree_with_many_excluded_files.mdwn b/doc/todo/speed_up_import_tree_with_many_excluded_files.mdwn
new file mode 100644
index 0000000000..8c1971d67e
--- /dev/null
+++ b/doc/todo/speed_up_import_tree_with_many_excluded_files.mdwn
@@ -0,0 +1,89 @@
+git-annex import from a special remote has a stage where
+addBackExportExcluded is run, to add back files that were excluded from
+being exported to the special remote to the tree of files imported from it. 
+
+This is quite slow when there are a lot of files in the tree. 
+Eg, in my sound repo, exporting to my phone, I have 50k excluded files, and
+it takes about 2 minutes to run this step.
+
+Can it be optimised?
+
+## speed up adjustTree
+
+It currently uses adjustTree with a big list of files to add back 
+to the tree. That performs badly when the list is large.
+
+This seems to be the bottleneck; git-annex is using 100% cpu,
+and the two helper processes `git mktree` and `git ls-tree` are barely active.
+
+At each level of the tree, it partitions the list to find files present
+in that subtree. It also filters the list. So the list gets traversed
+many times. 
+
+What's needed is a data structure, eg a tree, that avoids needing to
+repeatedly traverse the list like that.
+
+Note that adjustTree is also used with a possibly big list of files to add
+in Annex.Import.buildImportTrees. No other calls of adjustTree pass files
+to add.
+
+> [[done]] --[[Joey]]
+
+## git merge-tree
+
+Would it be possible to use `git merge-tree` instead?
+
+That command needs commits, and one commit cannot be a parent of the other
+in this case, so it seems it would be used like this:
+
+* Make a commit of the tree imported from the remote. This is a temporary
+  commit, and should have no parent.
+* Make a commit of the full tree from the remote tracking branch. This is a
+  temporary commit and should have no parent.
+* `git merge-tree` with the two temporary commits.
+  (Needs `--allow-unrelated-histories`)
+
+The cases are:
+
+1. new file added to remote
+2. file is present in the full tree, but was excluded out of the tree
+   exported to the remote
+3. file is modified on the remote
+4. file is present in the full tree, was excluded out of the tree exported
+   to the remote, but then got created separately on the remote
+5. file is present in the full tree, and got deleted from the remote
+
+In case 1, the new file will just be included in the merged tree.
+
+In case 2, the excluded file will also be just included in the merged tree.
+This is the point of this exercise.
+
+In case 3, there will be a conflict output. The right resolution of this
+conflict is to force in the version of the file from the imported tree.
+
+In case 4, there will be a conflict output. The right resolution of this
+conflict is same as in case 3.
+
+In case 5, the deleted file will be included in the merged tree.
+Oops, this is not what we want. Seems that this won't work?
+
+--- 
+
+What if the commit of the tree imported from the remote has as its parent a
+commit of the previous tree that was on the remote?
+
+Then in case 5, the deleted file will be in conflict; it was deleted from
+the import, and added from the full tree. Resolving this import in favor of
+the deletion will work.
+
+In case 4, there will be an add/add conflict. Force in the file from the
+imported tree.
+
+In case 3, same.
+
+In case 2, the excluded file will also be just included in the merged tree.
+This is the point of this exercise.
+
+In case 1, the new file will just be included in the merged tree.
+
+If that analysis is correct, this would work.. --[[Joey]]
diff --git a/doc/todo/ssh_special_remote.mdwn b/doc/todo/ssh_special_remote.mdwn
new file mode 100644
index 0000000000..be38f42090
--- /dev/null
+++ b/doc/todo/ssh_special_remote.mdwn
@@ -0,0 +1,44 @@
+ssh:// remotes are not special remotes. Perhaps it would be useful to have
+a special remote that wraps a ssh:// remote? This would allow setting up a
+ssh:// remote that can be enabled using the webapp's normal UI for enabling
+special remotes.
+
+Enabling such a special remote would just make a regular git remote, so
+there would be no need to implement the methods to get/put data. (Although
+it might need to provide stubs to appease the compiler.)
+
+> Above is done. The command line interface in initremote and enableremote
+> is not too easy or perhaps useful, but it works great in the webapp.
+> --[[Joey]]
+
+It could optionally embed the ssh private key into the git-annex branch as
+a credential, for when you want anyone who has access to the git repo to be
+able to use the (locked-down) git-annex-shell on that server.
+
+> Leaving this todo open for this ssh private key embedcreds part.
+> I think it makes sense to do, but it it probably not too easy.
+> ([[webapp_ssh_setup_should_work_with_locked_down_git-annex-shell_account]]
+> needs to be fixed first). --[[Joey]]
+
+[[!meta title="remember ssh remote including optionally ssh key"]]
+
+----
+
+I am on the fence about whether this would be useful, and would appreciate
+use cases.
+
+One use case I was thinking about was a LAN with a central server, with a
+shared account with a git-annex repository on it. But then I realized this
+wouldn't really help set up git-annex in that situation, most of the time,
+because new clients would have the central server added as their first
+remote. 
+
+(It would help if one client paired with another new client, but
+that is unncessarily round-about most of the time.) 
+
+It might help in a more complex situation, where the LAN is not the whole
+network an a client might come onto the LAN already knowing about the
+central server there. --[[Joey]]
+
+A very compelling use case is switching from XMPP to a ssh server,
+and wanting to make it easy for users. --[[Joey]]
diff --git a/doc/todo/stalldetection_for_import_and_export.mdwn b/doc/todo/stalldetection_for_import_and_export.mdwn
new file mode 100644
index 0000000000..6943918fb9
--- /dev/null
+++ b/doc/todo/stalldetection_for_import_and_export.mdwn
@@ -0,0 +1,13 @@
+The new annex.stalldetection is used for transfers from remotes, but not
+import and export from remotes.
+
+This should be doable, but it will need the transferkeys protocol to be
+extended to cover the additional actions. --[[Joey]] 
+
+> Note that, the protocol is designed so new requests can be added.
+> The old transferkeys will exit with an error if the new git-annex
+> happens to run it somehow. So it should be fine to add this stuff later
+> on. --[[Joey]]
+
+[[!tag confirmed]]
+[[!tag projects/datalad/potential]]
diff --git a/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups.mdwn b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups.mdwn
new file mode 100644
index 0000000000..2127dc66de
--- /dev/null
+++ b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups.mdwn
@@ -0,0 +1,55 @@
+standalone build is known to be slower than "proper" one and one of the reasons we identified in the past was result in excessive lookups for dynamic libraries due to all the shims and LD* tuneups iirc. So we added a test for `git annex init` to not exceed 130 lookups for `libpcre.*so` [here](https://github.com/datalad/git-annex/blob/41b4226d7ac740f3844a9dedced75993b69af74a/.github/workflows/template/build-%7B%7Bostype%7D%7D.yaml.j2#L546). Well, today that test failed with 131. It seems that number of those lookups was growing
+
+<details>
+<summary>was about 110 in Jan</summary> 
+
+```shell
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2022/01[master]git
+$> git grep '> test .* -lt 130' | grep ubuntu.*Seek
+cron-20220104/build-ubuntu.yaml-532-280a49ed-success/test-annex-more/6_Seek of dynlibs.txt:2022-01-04T02:59:06.2777397Z > test 109 -lt 130
+cron-20220105/build-ubuntu.yaml-534-d2f63758-success/test-annex-more/6_Seek of dynlibs.txt:2022-01-05T02:59:31.3381111Z > test 110 -lt 130
+...
+```
+</details>
+
+and was in >120 in Aug:
+
+```
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2022/08[master]git
+$> git grep '> test .* -lt 130' | grep ubuntu.*Seek
+cron-20220801/build-ubuntu.yaml-780-841b46fb-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-01T03:34:08.8366192Z > test 122 -lt 130
+cron-20220802/build-ubuntu.yaml-781-841b46fb-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-02T03:35:33.8514595Z > test 120 -lt 130
+cron-20220803/build-ubuntu.yaml-782-841b46fb-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-03T03:32:27.6511541Z > test 124 -lt 130
+cron-20220804/build-ubuntu.yaml-783-841b46fb-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-04T03:27:48.0776987Z > test 120 -lt 130
+cron-20220805/build-ubuntu.yaml-784-841b46fb-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-05T03:31:10.4380896Z > test 126 -lt 130
+cron-20220806/build-ubuntu.yaml-785-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-06T03:18:23.3003314Z > test 128 -lt 130
+cron-20220807/build-ubuntu.yaml-786-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-07T03:22:13.8922352Z > test 127 -lt 130
+cron-20220808/build-ubuntu.yaml-787-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-08T03:27:25.2816456Z > test 126 -lt 130
+cron-20220809/build-ubuntu.yaml-788-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-09T03:29:40.2487978Z > test 127 -lt 130
+cron-20220810/build-ubuntu.yaml-789-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-10T03:10:28.9067625Z > test 126 -lt 130
+cron-20220811/build-ubuntu.yaml-790-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-11T03:20:27.1936625Z > test 127 -lt 130
+cron-20220812/build-ubuntu.yaml-791-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-12T03:25:42.9069031Z > test 127 -lt 130
+cron-20220813/build-ubuntu.yaml-792-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-13T03:19:17.5307096Z > test 124 -lt 130
+cron-20220814/build-ubuntu.yaml-793-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-14T03:28:08.1891666Z > test 128 -lt 130
+cron-20220815/build-ubuntu.yaml-794-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-15T03:36:22.6735643Z > test 127 -lt 130
+cron-20220816/build-ubuntu.yaml-795-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-16T03:31:06.9664034Z > test 127 -lt 130
+cron-20220817/build-ubuntu.yaml-797-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-17T03:34:55.5031993Z > test 128 -lt 130
+cron-20220818/build-ubuntu.yaml-798-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-18T03:34:18.7936294Z > test 128 -lt 130
+cron-20220819/build-ubuntu.yaml-800-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-19T03:31:21.6241453Z > test 126 -lt 130
+cron-20220820/build-ubuntu.yaml-801-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-20T03:28:08.2721924Z > test 126 -lt 130
+cron-20220821/build-ubuntu.yaml-802-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-21T03:29:24.9739245Z > test 125 -lt 130
+cron-20220822/build-ubuntu.yaml-803-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-22T03:34:06.7771514Z > test 126 -lt 130
+cron-20220823/build-ubuntu.yaml-805-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-23T03:35:41.5831076Z > test 127 -lt 130
+cron-20220824/build-ubuntu.yaml-806-41b4226d-success/test-annex-more/6_Seek of dynlibs.txt:2022-08-24T03:41:06.5345006Z > test 126 -lt 130
+cron-20220825/build-ubuntu.yaml-807-41b4226d-success/test-annex-more/6_Seek of dynlibs.txt:2022-08-25T03:36:47.4347632Z > test 125 -lt 130
+cron-20220826/build-ubuntu.yaml-808-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-26T03:39:23.5398288Z > test 131 -lt 130
+manual-20220822/build-ubuntu.yaml-804-41b4226d-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-22T18:16:44.8256532Z > test 129 -lt 130
+pr-132/build-ubuntu.yaml-796-e482990a-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-16T19:03:13.1484274Z > test 128 -lt 130
+pr-55/build-ubuntu.yaml-799-32886238-failed/test-annex-more/6_Seek of dynlibs.txt:2022-08-18T18:11:38.9535820Z > test 127 -lt 130
+```
+
+anything to be done or should we just raise the bar to 140 in that test?
+
+[[!tag projects/datalad]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_1_ef6645a9b6d69a652cd042185c864677._comment b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_1_ef6645a9b6d69a652cd042185c864677._comment
new file mode 100644
index 0000000000..4d63b737c4
--- /dev/null
+++ b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_1_ef6645a9b6d69a652cd042185c864677._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-08-29T16:52:18Z"
+ content="""
+I compared current master with Nov 21, and the total number of git
+processes run by init increased from 29 to 34.
+
+One is that it now runs `git config --local --list` to handle a change in
+git's security model. (For some reason init runs that twice.)
+
+Another such change is it now runs `git config filter.annex.process`.
+
+And then there's a `git update-index` that I had to add to work around
+a (still unfixed) segfault in git.
+
+I think that `git-annex init` is more likely than other git-annex commands
+to get such added calls to git, since it has to detect and work around
+problems. You might be better off looking at a different command. For
+example, the number of libpcre opens by `git-annex version` has increased
+by only 1 since 2020.
+
+That one is because the dynamic linker has started looking in yet another
+hwcap directory, `x86_64-linux-gnu/glibc-hwcaps/x86-64-v2/`.
+As well as the other 5 or so it already looked in.
+(For `git-annex init`, that adds another 34 or so opens..)
+There seems to be no way to prevent
+the linker from doing that excess work, even though it's already setting
+`LD_HWCAP_MASK`, as was previously observed over
+[here](https://git-annex.branchable.com/todo/may_be___40__again__41___to_prelink_or_somehow_avoid_all_the_failing_opens__63__/#comment-51389bc9e65b7eba6a075270bd1e7870))
+
+Anyway, I think you should just raise the bar in your test..
+"""]]
diff --git a/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_2_181175a281f3a4298341d109064eeff8._comment b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_2_181175a281f3a4298341d109064eeff8._comment
new file mode 100644
index 0000000000..b4987ecec0
--- /dev/null
+++ b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_2_181175a281f3a4298341d109064eeff8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-08-29T17:51:49Z"
+ content="""
+I was able to eliminate one of the calls to `git config --local --list`
+anyway..
+"""]]
diff --git a/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_3_0358f9e216271ba0be8684eea4a3e1d1._comment b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_3_0358f9e216271ba0be8684eea4a3e1d1._comment
new file mode 100644
index 0000000000..8243cb4bd6
--- /dev/null
+++ b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_3_0358f9e216271ba0be8684eea4a3e1d1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2022-08-29T20:46:12Z"
+ content="""
+> Anyway, I think you should just raise the bar in your test..
+
+ok, did in [datalad/git-annex/commit/e26581b6](http://github.com/datalad/git-annex/commit/e26581b6a2e18c7b32034b94c16b43eee77a20eb)
+"""]]
diff --git a/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_3_5e3c73faeaefee8f0ec1227c672f2be5._comment b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_3_5e3c73faeaefee8f0ec1227c672f2be5._comment
new file mode 100644
index 0000000000..9b94cdedcb
--- /dev/null
+++ b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_3_5e3c73faeaefee8f0ec1227c672f2be5._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-08-30T17:19:35Z"
+ content="""
+Had an idea: ld-linux.so hardcodes some search paths like 
+x86_64-linux-gnu/glibc-hwcaps/x86-64-v2/ and x86_64-linux-gnu/x86_64/.
+There is no way to prevent it doing that short of a recompile. And no way
+to make it use a custom ld.so.cache either.
+
+But.. If those directories are made symlinks back to x86_64-linux-gnu, then
+it will find the library in the first path it looks in, every time!
+
+On my laptop, it searches x86_64-linux-gnu/glibc-hwcaps/x86-64-v2/ first,
+but this will vary depending on the hardware capabilities. I made that a
+symlink, and that reduces the number of ENOENT by some 300 when running
+git-annex init. And reduces the libpcre opens back down to 35.
+"""]]
diff --git a/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_4_91ab4b860a074c90e5cbeb03e3515ad4._comment b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_4_91ab4b860a074c90e5cbeb03e3515ad4._comment
new file mode 100644
index 0000000000..3588cbaf7b
--- /dev/null
+++ b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_4_91ab4b860a074c90e5cbeb03e3515ad4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-08-30T19:14:50Z"
+ content="""
+Implemented that idea now, so you may want to drop your test
+back down to 40 or 50. Or even better, make the test only look at the
+number of ENOENT opens of libpcre.. which should be 0 now.
+
+So far it's only implemented for amd64, i386, and arm. Other architectures
+might also have such directories that could be symlinked, I have not
+investigated.
+"""]]
diff --git a/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_6_2e435cc8fe61c7ca7c59f2a63fbbee20._comment b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_6_2e435cc8fe61c7ca7c59f2a63fbbee20._comment
new file mode 100644
index 0000000000..e8049861de
--- /dev/null
+++ b/doc/todo/standlone__58___growing_number_of_libpcre.so_lookups/comment_6_2e435cc8fe61c7ca7c59f2a63fbbee20._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2022-08-30T19:38:49Z"
+ content="""
+and as a result, I guess, making standalone build \"faster\" (it is known to lag behind a \"proper\" build) -- cool, thanks!
+"""]]
diff --git a/doc/todo/stop_after_these_files.mdwn b/doc/todo/stop_after_these_files.mdwn
new file mode 100644
index 0000000000..117f926d95
--- /dev/null
+++ b/doc/todo/stop_after_these_files.mdwn
@@ -0,0 +1,27 @@
+It would be useful if there was a way to make git-annex stop transferring
+after the current files finish being transferred. Sometimes I am
+moving files to a remote, and I might not pick the same remote to move them
+to next time, so interrupting a transfer unfinished can result in wasted
+work and space used temporarily storing partially transferred files.
+
+This should not be ctrl-c, because it could take a very long time for the
+current transfer to finish. Maybe SIGUSR1 or something like that?
+--[[Joey]]
+
+> An alternative approach, which avoids the complexity of needing to send a
+> signal, would be for git-annex to remember what transfers got
+> interrupted, and provide a simple command to resume them. --[[Joey]]
+> 
+> > That could not be something like the (existing) 
+> > `git-annex get --incomplete`, because for that you have to remember
+> > you were running a get and run effectively the same command again.
+> >
+> > For an interrupted `git-annex move --to foo`, it would not do to need 
+> > to remember what remote a file was being sent to. The goal would be
+> > something like `git-annex resume` that remembers for you.
+> >
+> > For this, the transfer logs would need to be extended with the operation
+> > and remote.
+
+[[!meta title="resume interrupted move/copy"]]
+[[!tag confirmed]]
diff --git a/doc/todo/support___126____47__.netrc_for_http_access_authentication_specs_as_was_done_when_wget_was_used.mdwn b/doc/todo/support___126____47__.netrc_for_http_access_authentication_specs_as_was_done_when_wget_was_used.mdwn
new file mode 100644
index 0000000000..72eaa72289
--- /dev/null
+++ b/doc/todo/support___126____47__.netrc_for_http_access_authentication_specs_as_was_done_when_wget_was_used.mdwn
@@ -0,0 +1,29 @@
+Recent git-annex started to handle http connections internally (instead of relying on `wget` and `curl`) which is great in general.  But I wondered if it is relatively easy to retain support for authentication via "standard" `~/.netrc` which `wget` supports nicely.  But ATM (e.g. with 6.20180416) it wouldn't work
+
+Example:
+[[!format sh """
+$> git annex addurl --debug http://onerussian.com/tmp/secret/index.html --file testDemo.mnc           
+[2018-04-27 21:10:52.699047352] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-04-27 21:10:52.707407583] process done ExitSuccess
+[2018-04-27 21:10:52.707650197] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-04-27 21:10:52.711677639] process done ExitSuccess
+[2018-04-27 21:10:52.711863237] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..1aef0c7917a50ea5a23702f04c6e7778ea5c8843","--pretty=%H","-n1"]
+[2018-04-27 21:10:52.719171987] process done ExitSuccess
+[2018-04-27 21:10:52.719903748] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-04-27 21:10:52.721168737] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+addurl http://onerussian.com/tmp/secret/index.html 
+
+failed
+[2018-04-27 21:10:53.010687336] process done ExitSuccess
+[2018-04-27 21:10:53.011302754] process done ExitSuccess
+"""]]
+
+whenever works with e.g. 6.20180316 if corresponding settings are setup in `~/.netrc`
+
+Or may be there is some other alternative support for such cases now?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> closing as there is a documented way to make a netrc work. [[done]]
+> --[[Joey]]
diff --git a/doc/todo/support___126____47__.netrc_for_http_access_authentication_specs_as_was_done_when_wget_was_used/comment_1_0f2f5b58020879252d716930f2396b81._comment b/doc/todo/support___126____47__.netrc_for_http_access_authentication_specs_as_was_done_when_wget_was_used/comment_1_0f2f5b58020879252d716930f2396b81._comment
new file mode 100644
index 0000000000..661453a4b3
--- /dev/null
+++ b/doc/todo/support___126____47__.netrc_for_http_access_authentication_specs_as_was_done_when_wget_was_used/comment_1_0f2f5b58020879252d716930f2396b81._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-04-30T20:09:20Z"
+ content="""
+.netrc was considered in [[stop_using_curl_and_wget]]. The changelog for
+the release recommends that users who need a netrc do "git config
+annex.web-options --netrc"
+
+I don't anticipate adding support for netrc files to git-annex.
+Adding a dependency on http://hackage.haskell.org/package/netrc for such a
+relatively little-used feature which can be supported as above does not
+seem worth it.
+"""]]
diff --git a/doc/todo/support_for_storing_xattrs.mdwn b/doc/todo/support_for_storing_xattrs.mdwn
new file mode 100644
index 0000000000..4bdcfefe6c
--- /dev/null
+++ b/doc/todo/support_for_storing_xattrs.mdwn
@@ -0,0 +1,17 @@
+It would be nice to have support for storing extended attributes in git-annex.
+
+There are some useful [proposed metadata attributes](https://www.freedesktop.org/wiki/CommonExtendedAttributes/#proposedmetadataattributes):
+
+* user.xdg.comment: A comment specified by the user. This comment could be displayed by file managers
+* user.xdg.origin.url: Set on a file downloaded from a url. Its value should equal the url it was downloaded from.
+* user.xdg.origin.email.subject: Set on an email attachment when saved to disk. It should get its value from the originating message's "Subject" header
+* user.xdg.origin.email.from: Set on an email attachment when saved to disk. It should get its value from the originating messsage's "From" header. For example '"John Doe" <jdoe@example.com>', or 'jdoe@example.com'
+* user.xdg.origin.email.message-id: Set on an email attachment when saved to disk. It should get its value from the originating message's "Message-Id" header. 
+
+At least `curl --xattr` saves `xdg.origin.url`.
+
+Perhaps `git-annex-metadata` could be leveraged to automatically store and restore xattrs? Might even work that addition of xattrs would always have to be done through a git-annex command, but restoration would be done automatically if git-annex noticed there are xattrs stored in metadata, and the file system is mounted with `user_xattr`.
+
+The `user` namespace is used for user xattrs and thus for "proposed metadata attributes" above. These attributes are valid git-annex metadata fields as-is.
+
+[[!tag unlikely]]
diff --git a/doc/todo/support_for_storing_xattrs/comment_1_55c839d1b8af5150a5df29f0314e4b79._comment b/doc/todo/support_for_storing_xattrs/comment_1_55c839d1b8af5150a5df29f0314e4b79._comment
new file mode 100644
index 0000000000..5708a10062
--- /dev/null
+++ b/doc/todo/support_for_storing_xattrs/comment_1_55c839d1b8af5150a5df29f0314e4b79._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="unqueued"
+ avatar="http://cdn.libravatar.org/avatar/3bcbe0c9e9825637ad7efa70f458640d"
+ subject="comment 1"
+ date="2018-05-28T14:55:34Z"
+ content="""
+I wrote a quick and dirty script to store xattrs in a git repo, because I wanted to keep my OSX labels and other metadata like resource forks in my annex. But it only works on OSX at the moment.
+
+https://github.com/unqueued/git-xattr
+
+I think maybe metadata storage would be best implemented as a hook.
+"""]]
diff --git a/doc/todo/support_for_storing_xattrs/comment_2_c10f87259aef110510014ba16d0792ad._comment b/doc/todo/support_for_storing_xattrs/comment_2_c10f87259aef110510014ba16d0792ad._comment
new file mode 100644
index 0000000000..f35944910f
--- /dev/null
+++ b/doc/todo/support_for_storing_xattrs/comment_2_c10f87259aef110510014ba16d0792ad._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-05-29T16:51:48Z"
+ content="""
+I also would rather see this as a hook than built into git-annex. It's
+something that git-annex's metadata can be leveraged for, perhaps,
+but different use cases call for different amounts of data.
+
+I suppose the thing to provide a hook into is whenever git-annex adds an
+object content to .git/annex/objects. That will allow the hook
+to store the current xattrs after `git annex add`, and to restore them
+after eg `git annex get`.
+
+But, suppose you run: `git annex add file; git annex move file --to remote`
+Then the remote won't have the updated git-annex branch yet when it stores the
+object content, and so the hook run on it won't be able to do anything.
+
+When new git-annex branch version adds/changes xattr values,
+the local repository would need to be updated to reflect them.
+So, there would also need to be a hook that's run when git-annex
+metadata has changed.
+
+See also: [[lockdown_hooks]] which have different use cases, but seem to
+call for the same kind of hooks.
+"""]]
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__.mdwn b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__.mdwn
new file mode 100644
index 0000000000..fd28ed7aa8
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__.mdwn
@@ -0,0 +1,3 @@
+macOS has CoW copies too but they're only available via the `/bin/cp` binary as GNU coreutils doesn't support using macOS' calls for this unfortunately.
+
+One trouble here is that it doesn't automatically fall back to a non-reflink copy when a reflink copy is not possible, so that would have to be handled by us somehow.
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_10_d94d813bdd6bea17347c87597788aec7._comment b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_10_d94d813bdd6bea17347c87597788aec7._comment
new file mode 100644
index 0000000000..263c857a8e
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_10_d94d813bdd6bea17347c87597788aec7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 10"
+ date="2022-03-08T13:21:02Z"
+ content="""
+GNU coreutils will implement reflink copies on macOS in the next major version, so we will get this for free: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=5e36c0ce078a65c7dac6ac5ebdfb0cf096856427
+
+I use GNU coreutils system-wide because they're much better but not all users do that. We might need extra logic to handle odd aliases some distros give to GNU coreutils use like `gcp`. Is there a build-time way to specify which coreutils git-annex should use at runtime?
+"""]]
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_11_e5b9898f69fa9143519e58378ac668f8._comment b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_11_e5b9898f69fa9143519e58378ac668f8._comment
new file mode 100644
index 0000000000..950942d373
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_11_e5b9898f69fa9143519e58378ac668f8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2022-03-08T17:44:05Z"
+ content="""
+`Build/Configure.hs` probes for supported cp options,
+and could be extended to try gcp.
+"""]]
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_12_9fd59c3ec54d54790050eb8860964783._comment b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_12_9fd59c3ec54d54790050eb8860964783._comment
new file mode 100644
index 0000000000..e98a8407a3
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_12_9fd59c3ec54d54790050eb8860964783._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 12"
+ date="2022-03-09T12:07:45Z"
+ content="""
+Problem is that in our Nix sandbox, `cp` is always coreutils' while on the actual system, it might be macOS'. 
+
+It'd be nice to have a way to declare what binary to use (with absolute path or just binary name) for `cp` and the like, that way we can get rid of our runtime wrapper that puts coreutils in git-annex' PATH in anticipation of features that rely on GNU coreutils.
+"""]]
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_1_1b23963d04c5bd53d3de09970816fad8._comment b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_1_1b23963d04c5bd53d3de09970816fad8._comment
new file mode 100644
index 0000000000..6adef9d9ef
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_1_1b23963d04c5bd53d3de09970816fad8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 1"
+ date="2021-05-04T12:46:59Z"
+ content="""
+I've got a fix done for this locally but it's unconditional for now. What's the best way of making this a configure flag or something similar so that users can disable it should they not want it? Not too familiar with Haskell standards on this sort of thing.
+"""]]
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_2_e506d7b173bd04ad7f32db52dcc1ea03._comment b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_2_e506d7b173bd04ad7f32db52dcc1ea03._comment
new file mode 100644
index 0000000000..31780a3a18
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_2_e506d7b173bd04ad7f32db52dcc1ea03._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-05-04T14:15:38Z"
+ content="""
+The cp command not falling back is ok, as long as it exits nonzero in a
+situation where it can't make a CoW copy and doesn't misbehave badly. In
+Annex/CopyFile.hs, tryCopyCoW probes to see if cp can make a CoW copy, and
+if not it falls back to copying itself, without cp.
+
+So what you can do is change copyCow in Utility/CopyFile.hs to support the
+OSX cp command and parameters (inside a `#ifdef darwin_HOST_OS`).
+
+Notice that the probe deals with discarding error messages from the
+command, also also deals with linux's cp failing after creating an empty
+file when it doesn't support CoW.
+
+That would leave copyFileExternal not using CoW; it could be made to probe
+too on OSX, but that's not really used in many places and it would probably
+make more sense to convert any of those places that matter to use
+Annex/CopyFile.hs's tryCopyCoW. This could be deferred until later.
+
+I don't think it needs to be a configure flag unless this feature is
+somehow flakey.
+"""]]
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_3_d812c6dbd672e3dcdeb5c87806dcef91._comment b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_3_d812c6dbd672e3dcdeb5c87806dcef91._comment
new file mode 100644
index 0000000000..a62f1cac0b
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_3_d812c6dbd672e3dcdeb5c87806dcef91._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 3"
+ date="2021-05-04T17:37:04Z"
+ content="""
+Oh, I've already got all of that implemented; it's just the flag for disabling that behaviour at build time that's missing.
+
+What I did is to conditionally set the executable to `/bin/cp` and the reflink param to `-c`.
+
+The problem with using it without a fallback is that when you use it on a FS that doesn't support CoW, `/bin/cp` will hard-fail and make unlocking impossible. GNU coreutils actually fall back automatically by themselves, GA couldn't handle reflink cp failing before AFAICT. I refactored the copy functions a bit to make it fall back properly.
+
+The reason I want it to be a configure flag is that some users might use GA exclusively on non-APFS FSs (trying to reflink copy here would be a waste of time) and some might prefer to use their $PATH's uutils-coreutils whose `cp` can handle `--reflink` just like the GNU ones.
+
+~~I originally wanted to add it as a cabal configure flag but apparently you can't reference those anywhere?~~ Found this: https://stackoverflow.com/questions/48157516/conditional-compilation-in-haskell-submodule, that's probably what I'll end up doing. Will default to true on macOS.
+"""]]
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_4_8fbd3cdc5a077cbd51d41db30c19a005._comment b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_4_8fbd3cdc5a077cbd51d41db30c19a005._comment
new file mode 100644
index 0000000000..5e0f5feb43
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_4_8fbd3cdc5a077cbd51d41db30c19a005._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 4"
+ date="2021-05-05T05:43:56Z"
+ content="""
+https://github.com/Atemu/git-annex/tree/feature/macOS-reflinks
+"""]]
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_5_4580926755ee2802c80baa9f9bcc0661._comment b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_5_4580926755ee2802c80baa9f9bcc0661._comment
new file mode 100644
index 0000000000..9aad31075a
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_5_4580926755ee2802c80baa9f9bcc0661._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 5"
+ date="2021-05-05T06:04:49Z"
+ content="""
+I've also got some small fixes for things that came up during development:
+
+https://github.com/Atemu/git-annex/tree/misc-fixes
+"""]]
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_6_bd610770eff9ef1eb68085e28c1175fa._comment b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_6_bd610770eff9ef1eb68085e28c1175fa._comment
new file mode 100644
index 0000000000..b2cc02ad88
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_6_bd610770eff9ef1eb68085e28c1175fa._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2021-05-07T15:28:34Z"
+ content="""
+misc-fixes merged
+"""]]
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_7_f09b99a17d52a55e609bb3ca02db781a._comment b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_7_f09b99a17d52a55e609bb3ca02db781a._comment
new file mode 100644
index 0000000000..3aa49e2c97
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_7_f09b99a17d52a55e609bb3ca02db781a._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2021-05-07T15:28:46Z"
+ content="""
+The patch makes copyFileExternal slower on linux when CoW is not supported,
+as it will try cp --reflink=always every time, and then when it fails, 
+run cp a second time. This is why I discussed in my comment above that
+it would make sense to switch code using copyFileExternal to instead use
+tryCopyCoW.
+
+> GA couldn't handle reflink cp failing before AFAICT 
+
+Yes, it could, this is done in tryCopyCoW.
+
+> The reason I want it to be a configure flag is that some users might use
+> GA exclusively on non-APFS FSs (trying to reflink copy here would be a
+> waste of time)
+
+Current places that use tryCopyCoW maintain state, so it only
+pays the overhead of running cp one extra time to probe if reflinks work.
+That should also be possible on OSX. 
+
+I do not see a need for a build flag, also I doubt that many users in such
+a situation would rebuild with that flag.
+
+> some might prefer to use their $PATH's uutils-coreutils whose cp can
+> handle --reflink just like the GNU ones
+
+The system /bin/cp will always be there, right? So I don't see a need to
+bother about other cp implementations.
+"""]]
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_8_f1c3cf11cddb9e5c7747e5824cd4b608._comment b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_8_f1c3cf11cddb9e5c7747e5824cd4b608._comment
new file mode 100644
index 0000000000..1a39531821
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_8_f1c3cf11cddb9e5c7747e5824cd4b608._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 8"
+ date="2021-05-13T10:26:53Z"
+ content="""
+I missed `copyFileExternal` actually using `--reflink=auto` instead of `always`, thus letting `cp` handle falling back. Although, `cp` would have to do the check and fallback internally for every call we make to it too so there might not be that much of an performance impact of doing the same in GA.
+
+Tracking the reflinkability for a batch of `cp`s is a good idea though and I like it as a generally cleaner solution but I'm not so sure about any real performance benefits of that.
+
+I tried using tryCopyCoW in copyFileExternal (seemed like the most obvious thing to do) but it doesn't seem to support the `CopyMetaData` arg `copyFileExternal` is supposed to be able to handle, right?
+"""]]
diff --git a/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_9_5097e4ac096d1b0b9c06c544b9217e22._comment b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_9_5097e4ac096d1b0b9c06c544b9217e22._comment
new file mode 100644
index 0000000000..a1f1e67f93
--- /dev/null
+++ b/doc/todo/support_macOS__39___cp_-c___40__cp_--reflink_equivalent__41__/comment_9_5097e4ac096d1b0b9c06c544b9217e22._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2021-05-13T15:51:41Z"
+ content="""
+fork/exec can end up being fairly significant overhead when the files are
+small enough. And, at least on linux systems, most people are probably not
+using a filesystem supporting CoW, so most people would pay that perf
+penalty. That's why the current code is optimised to avoid it,
+at least in places where it's seemed worthwhile.
+
+I'll suggest again: Just start with copyCoW, leave copyFileExternal
+not doing CoW copies, I'll accept that easy patch. And then if any of
+the 6 or so call sites of copyFileExternal end up being ones you want to
+make support CoW on OSX, convert them to use tryCopyCoW.
+
+(Alternatively, if there were a haskell library that provided the syscall
+that does a CoW copy, it could just use it.)
+"""]]
diff --git a/doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support.mdwn b/doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support.mdwn
new file mode 100644
index 0000000000..9523279557
--- /dev/null
+++ b/doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support.mdwn
@@ -0,0 +1,40 @@
+ATM git-annex passes sftp:// urls to be handled with curl.
+But that one does not (re)use established ssh control sockets and/or credentials
+
+E.g.
+
+[[!format sh """
+$> git annex addurl --debug sftp://localhost/tmp/123  
+[2018-01-12 09:53:35.195801836] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2018-01-12 09:53:35.199709648] process done ExitSuccess
+[2018-01-12 09:53:35.199781091] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2018-01-12 09:53:35.203370157] process done ExitSuccess
+[2018-01-12 09:53:35.204373706] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2018-01-12 09:53:35.204819259] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+addurl sftp://localhost/tmp/123 [2018-01-12 09:53:35.208782745] read: curl ["-s","--head","-L","sftp://localhost/tmp/123","-w","%{http_code}","--user-agent","git-annex/6.20171211+gitgba511f4de-1~ndall+1"]
+[2018-01-12 09:53:35.290168768] process done ExitFailure 51
+
+[2018-01-12 09:53:35.290835362] call: wget ["-nv","--show-progress","--clobber","-c","-O","/tmp/bu/.git/annex/tmp/URL--sftp&c%%localhost%tmp%123","sftp://localhost/tmp/123","--user-agent","git-annex/6.20171211+gitgba511f4de-1~ndall+1"]
+sftp://localhost/tmp/123: Unsupported scheme ‘sftp’.
+[2018-01-12 09:53:35.299065531] process done ExitFailure 1
+failed
+[2018-01-12 09:53:35.299781408] process done ExitSuccess
+[2018-01-12 09:53:35.299993431] process done ExitSuccess
+git-annex: addurl: 1 failed
+
+
+"""]]
+
+So far we haven't managed to make curl behave sanely with sftp urls without us passing explicitly the login name and then a password and then it still failed:
+
+[[!format sh """
+$> curl sftp://localhost/tmp/123 -u yoh            
+Enter host password for user 'yoh':
+curl: (51) SSL peer certificate or SSH remote key was not OK
+"""]]
+
+I wondered if it would be feasible for git annex natively support ssh (scp) and/or sftp urls?  All the machinery is there since it deals with copying files over ssh already.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+[[!tag unlikely moreinfo]]
diff --git a/doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support/comment_1_7932fd28b14898a0b4846856a27405b8._comment b/doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support/comment_1_7932fd28b14898a0b4846856a27405b8._comment
new file mode 100644
index 0000000000..13887bb87a
--- /dev/null
+++ b/doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support/comment_1_7932fd28b14898a0b4846856a27405b8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-01-15T17:28:16Z"
+ content="""
+I don't think that all the machinery *is* there, because
+for urls there needs to be a way to check the file size,
+and it's not clear how to do that with a sftp or ssh url.
+"""]]
diff --git a/doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support/comment_2_048a8f7b52a0baf4c0abbae37de00257._comment b/doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support/comment_2_048a8f7b52a0baf4c0abbae37de00257._comment
new file mode 100644
index 0000000000..9749c61503
--- /dev/null
+++ b/doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support/comment_2_048a8f7b52a0baf4c0abbae37de00257._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="size"
+ date="2018-07-31T14:19:15Z"
+ content="""
+> to check the file size, and it's not clear how to do that with a sftp or ssh url
+
+what do you mean?  why something as simple as \"ssh host stat filepath\" wouldn't work?  or it seems e.g. libssh2 provides file size information via sftp: https://curl.haxx.se/mail/lib-2011-01/0094.html
+"""]]
diff --git a/doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support/comment_3_04be2f010aeb792e070f1ff93435fabc._comment b/doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support/comment_3_04be2f010aeb792e070f1ff93435fabc._comment
new file mode 100644
index 0000000000..372aa680f7
--- /dev/null
+++ b/doc/todo/support_ssh__58____47____47___or_sftp__58____47____47___urls_via___34__built-in__34___ssh_support/comment_3_04be2f010aeb792e070f1ff93435fabc._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-08-02T17:21:13Z"
+ content="""
+Well, depends on coreutils and needs a stat(1) parser. Also, will sftp
+servers necessarily let arbitrary commands be run over ssh? Driving sftp
+interactive and parsing its ls -l would add more complexity to getting file
+size.
+
+The url security fixes also mean these uris can't be used without relaxing
+the security policy.. Makes me wonder how much special-casing makes sense
+for such an edge feature.
+"""]]
diff --git a/doc/todo/support_using_Stateless_OpenPGP_instead_of_gpg.mdwn b/doc/todo/support_using_Stateless_OpenPGP_instead_of_gpg.mdwn
new file mode 100644
index 0000000000..e6600e88a5
--- /dev/null
+++ b/doc/todo/support_using_Stateless_OpenPGP_instead_of_gpg.mdwn
@@ -0,0 +1,52 @@
+<https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/> or "sop" is
+a standard for a command-line interface for OpenPGP. There are several
+implementations available in Debian already, like sqop (using Sequoia), gosop,
+gpainless-cli, and hop from hopenpgp-tools (haskell).
+
+It's possible to use this in a way that interoperates with gpg. For example:
+
+	joey@darkstar:~>cat pw
+	hunter1
+	joey@darkstar:~>cat foo
+	Tue Jan  9 15:10:32 JEST 2024
+	joey@darkstar:~>sqop encrypt --with-password=pw < foo > bar
+	joey@darkstar:~>gpg --passphrase-file pw --decrypt bar
+	gpg: AES256.CFB encrypted session key
+	gpg: encrypted with 1 passphrase
+	Tue Jan  9 15:10:32 JEST 2024
+
+That example uses symmetric encryption, which is what git-annex uses
+for encryption=shared. So git-annex could use this or gpg to access the
+same encrypted special remote.
+
+Update: That's implemented now, when annex.shared-sop-command is configured
+it will be used for encryption=shared special remotes. It interoperates
+fine with using gpg, as long as the sop command uses a compatable profile
+(setting annex.shared-sop-profile = rfc4880 is probably a good idea).
+
+Leaving this todo open because there are other encryption schemes than 
+encryption=shared, for which using sop is not yet supported.
+
+For the public key encryption used by the other encryption= schemes,
+sop would be harder to use, because it does not define any location
+to store private keys. Though it is possible to export gpg private keys
+and use them with sop to encrypt/decrypt files, it wouldn't make sense
+for git-annex to do that for the user. So there would need to be some way
+to map from keyid= value to a file containing the key. Which could be as
+simple as files named `.git/annex/sop/$keyid.sec`, which would be installed
+by the user using whatever means they prefer.
+
+Since sop also supports hardware-backed secret keys, and using one avoids
+the problem of where to store the secret key file, it would be good to
+support using those. This could be something like `keyid=@HARDWARE:xxx`
+making `@HARDWARE:xxx` be passed to sop.
+
+It seems that git-annex would need to prompt for the secret key's password
+itself, since sop doesn't prompt, and feed it in via `--with-key-password`.
+It can detect if a password is needed by trying the sop operation without a
+password and checking for an exit code of 67.
+See [this issue on sop password prompting](https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/64)
+
+See also: [[todo/whishlist__58___GPG_alternatives_like_AGE]]
+
+[[!meta title="support using Stateless OpenPGP instead of gpg for encryption methods other than encryption=shared"]]
diff --git a/doc/todo/symlinks_to_symlinks_to_the_annex.mdwn b/doc/todo/symlinks_to_symlinks_to_the_annex.mdwn
new file mode 100644
index 0000000000..d0d60f0286
--- /dev/null
+++ b/doc/todo/symlinks_to_symlinks_to_the_annex.mdwn
@@ -0,0 +1,5 @@
+If file A is annexed and dropped, and B is a relative symlink to A, then git annex get B should result in A being fetched, but currently doesn't.
+This would especially help if B is deep within some dir 'mydir', and you do git annex get mydir: annexed files under mydir get fetched,
+but not annexed files elsewhere in the repository to which symlinks under mydir point.   So such symlinks under mydir will continue to remain broken.
+
+[[!tag unlikely]]
diff --git a/doc/todo/symlinks_to_symlinks_to_the_annex/comment_1_54bae401b8de13c9973ef5e6d2cf7e88._comment b/doc/todo/symlinks_to_symlinks_to_the_annex/comment_1_54bae401b8de13c9973ef5e6d2cf7e88._comment
new file mode 100644
index 0000000000..b015f5f316
--- /dev/null
+++ b/doc/todo/symlinks_to_symlinks_to_the_annex/comment_1_54bae401b8de13c9973ef5e6d2cf7e88._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/iOGTltEpmOTQ.xZ99NFP5c7Zdcc-#6a7ba"
+ nickname="Ilya S"
+ avatar="http://cdn.libravatar.org/avatar/8a133555cc739a35b83b07d5724d28d9e2f7852c224e949eec6fd4fb7693331e"
+ subject="comment 1"
+ date="2018-09-07T18:04:51Z"
+ content="""
+Also relative symlinks can point to other subdirs in the repository, in addition to pointing to files.  Basically, it would be good to add a command-line flag so that when git-annex-get or other command operates on a path in the repository, it would also operate on paths pointed to by relative symlinks under the given path.
+"""]]
diff --git a/doc/todo/symlinks_to_symlinks_to_the_annex/comment_2_f5c08ecd3b0b4099186d78c85b7f1e6f._comment b/doc/todo/symlinks_to_symlinks_to_the_annex/comment_2_f5c08ecd3b0b4099186d78c85b7f1e6f._comment
new file mode 100644
index 0000000000..fe80bd7821
--- /dev/null
+++ b/doc/todo/symlinks_to_symlinks_to_the_annex/comment_2_f5c08ecd3b0b4099186d78c85b7f1e6f._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-09-11T17:04:29Z"
+ content="""
+Supporting this would require that git-annex stat every
+file that non-git-annex symlinks point to, which seems
+like it could have a performance impact. 
+
+Also, git-annex is often processing information from git in a pipe,
+which can include the link target. In such cases it can very efficiently
+see if the link target is an annex object, but to support symlinks to
+symlinks it would have to do an additonal round trip through git, which
+would be much more innefficient than statting a symlink.
+
+And then there's the question of symlinks which point outside the git
+repository, or to another git-annex repository, or symlink loops. 
+Now we have potentially security sensitive filename parsing.
+
+It seems like a really big can of worms to open, I am not eager to do this.
+You'd have to have some *extemely* compelling use cases. So far, my
+response to the use cases provided is:
+"Doctor, Doctor… It Hurts When I Do This!"
+"""]]
diff --git a/doc/todo/symlinks_to_symlinks_to_the_annex/comment_3_409de39da33b7ecfe5b8c7b2e866225e._comment b/doc/todo/symlinks_to_symlinks_to_the_annex/comment_3_409de39da33b7ecfe5b8c7b2e866225e._comment
new file mode 100644
index 0000000000..fbab813592
--- /dev/null
+++ b/doc/todo/symlinks_to_symlinks_to_the_annex/comment_3_409de39da33b7ecfe5b8c7b2e866225e._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2018-09-18T18:41:01Z"
+ content="""
+The main reason for wanting git-annex to follow symlinks, is that the semantics of its commands (get/add/copy) operating on directories would be much more intuitive.
+I want to know that after 'git annex get subdir' all annexed files accessible under subdir/ are available; that after 'git annex add subdir && git annex move subdir --to my-remote' all
+large files accessible under subdir/ are at my-remote; etc.   I want to be able to treat a subdirectory as a self-contained unit.  But this isn't possible if relative symlinks stored
+undir subdir/ but pointing outside subdir/ might still be broken after 'git annex get subdir', etc.
+
+E.g. I have
+
+proj1/
+      big_file.dat: symlink to ../.git/annex/objects/....
+proj2/
+      big_file.dat: symlink to ../proj1/big_file.dat
+then if I do 'git annex get proj1', I can safely work on proj1 knowing all its files have been fetched; but if I do 'git annex get proj2', I can't safely work on it because
+the symlink proj2/big_file.dat is still broken.   I can of course make proje2/big_file.dat a direct link to the annex, but that loses the relationship between proj1 and proj2.
+It's pretty common to want to create a \"variant\" of a project by making most files in proj2/ symlinks to corresponding files in proj1/ , except for a few files that differ.
+
+With 'git annex add', it'd help a lot to know that 'git annex add /my/dir' will definitely store _everything_ under /my/dir.   In fact, if a symlink under /my/dir points outside the
+repository, git-annex could still store the target file in the annex and check in a symlink to that (or perhaps warn the user about the situation).   Then I can 'git annex add' my local
+setup, even if it points to some absolute paths, and check it out on another machine, with all links working.
+
+\"Supporting this would require that git-annex stat every file that non-git-annex symlinks point to\" -- only ones that point outside the subdir being worked on.  If the target of
+such a symlink is a directory, you'd need to process that directory too.  But if this all is off by default, and turned on by a flag, then the normal operation won't be affected.
+"""]]
diff --git a/doc/todo/symlinks_to_symlinks_to_the_annex/comment_4_818c85d1a199d40daca7371fefb18bc3._comment b/doc/todo/symlinks_to_symlinks_to_the_annex/comment_4_818c85d1a199d40daca7371fefb18bc3._comment
new file mode 100644
index 0000000000..997ad4f78b
--- /dev/null
+++ b/doc/todo/symlinks_to_symlinks_to_the_annex/comment_4_818c85d1a199d40daca7371fefb18bc3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2018-09-18T18:48:06Z"
+ content="""
+p.s. you're right that symlinks to outside the repository would be a security risk.   They should not be added to the annex without explicit options. But it's important to at least warn about them, so e.g. the user knows that 'git annex add' did not add everything, or that 'git annex get subdir/' did not get everything under subdir/ .  It  _would_ be useful to handle relative symlinks into submodules though.
+Symlink loops would of course be errors.  
+"""]]
diff --git a/doc/todo/symlinks_to_symlinks_to_the_annex/comment_5_94b84cd27c36d14dc16837484d232d72._comment b/doc/todo/symlinks_to_symlinks_to_the_annex/comment_5_94b84cd27c36d14dc16837484d232d72._comment
new file mode 100644
index 0000000000..680d252d44
--- /dev/null
+++ b/doc/todo/symlinks_to_symlinks_to_the_annex/comment_5_94b84cd27c36d14dc16837484d232d72._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="symlinks into git-annex"
+ date="2018-09-18T19:15:11Z"
+ content="""
+I often work with scenarios where I want to `git annex get` files where I'm not actually in a git annex repository but in a symlink farm that fans out (often via directory-level indirections) into git annices (is there a canonical plural?). There, what I use is a short script that `readlink`s the to-be-fetched files until it contains a `.git/annex/objects` part and then fetches that in its original annex. If there were a way to do that with a standard `git annex get`, possibly (if after some deliberation there remain security concerns) behind a --follow-symlinks switch, I'd appreciate that.
+"""]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__.mdwn b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__.mdwn
new file mode 100644
index 0000000000..0e0dc0c5aa
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__.mdwn
@@ -0,0 +1,6 @@
+As we briefly discussed via email, it would be nice if sync could sync only some branches (e.g. git-annex) not all at once.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_10_06fd59c8bdd451b5608e1e0191f4d5cb._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_10_06fd59c8bdd451b5608e1e0191f4d5cb._comment
new file mode 100644
index 0000000000..d40c0915d2
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_10_06fd59c8bdd451b5608e1e0191f4d5cb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="thanks"
+ date="2020-02-18T20:00:11Z"
+ content="""
+\"--no-content combined with --only-annex. Now implemented\" -- thanks a lot, I was also looking for that.
+"""]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_11_436fd00970867a8bb0806a753ac24963._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_11_436fd00970867a8bb0806a753ac24963._comment
new file mode 100644
index 0000000000..569b3c3b2a
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_11_436fd00970867a8bb0806a753ac24963._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="Interaction with config annex.synccontent"
+ date="2020-02-24T21:34:50Z"
+ content="""
+So far, the new `--only-annex` option (and related `annex.synconlyannex` set to `true` config setting) are working beautifully for me, thanks!
+
+As described previously, `--only-annex` now implies `--content`, but this can be overridden with something like `git annex sync --only-annex --no-content` (and this works successfully for me). I wanted to configure it so it will *always* not sync content. For example, when on a new clone, running `git annex sync --only-annex` without first configuring [wanted](https://git-annex.branchable.com/git-annex-wanted/)/[group assignments](https://git-annex.branchable.com/preferred_content/standard_groups/)/etc can result in a lot of files moving around on a big repository, which I'd rather not interrupt brusquely with `C-c`.
+
+I thought that perhaps setting `annex.synccontent` to `false` might achieve this, but from some experimenting it doesn't: doing `git annex config --set annex.synccontent false` and then `git annex sync --only-annex` will still sync content). This isn't a huge surprise, since it's not a documented feature for [git annex config](https://git-annex.branchable.com/git-annex-config/) which only described what setting `annex.synccontent` to `true` will accomplish (and doesn't mention what setting it to `false` would do). However, it seems like it would be in the spirit of letting users override the `--only-annex` implies `--content` option, if desired.
+
+Apologies if this is better to discuss over at the [git annex config](https://git-annex.branchable.com/git-annex-config/) page, or if @joeyh doesn't want to implement it at all, but just wanted to suggest it.
+"""]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_12_2e768899c332cacffcb1fa6edb195325._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_12_2e768899c332cacffcb1fa6edb195325._comment
new file mode 100644
index 0000000000..017634efd3
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_12_2e768899c332cacffcb1fa6edb195325._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2020-02-25T16:31:55Z"
+ content="""
+Generally, command-line options should override other configuration,
+so --only-annex seems like it should enable content syncing even if
+annex.synccontent=false were a documented setting, the same as --content
+should.
+
+I think a case could be made for annex.synccontent=false +
+annex.synconlyannex=true not syncing content.
+
+I do wonder though if that's the best approach. It kind of seems like what
+you really want is a way to configure a default preferred content
+expression for clones that do not have a specific one configured. And
+that seems more broadly useful than fine-tuning the interaction of two
+git-annex sync configurations.
+"""]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_1_741720c1b65fff2f8ecb87abbcf16223._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_1_741720c1b65fff2f8ecb87abbcf16223._comment
new file mode 100644
index 0000000000..a45ae84c38
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_1_741720c1b65fff2f8ecb87abbcf16223._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-08-08T15:40:55Z"
+ content="""
+As I suggested in email, this could be something like `git annex sync --branch B`
+and --branch could be repeated to add other branches, with the default
+being to sync them all. `git annex sync --branch git-annex` would need to
+be special cased I think.
+"""]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_2_73bd5d343286f61c9ac753ed3b00c149._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_2_73bd5d343286f61c9ac753ed3b00c149._comment
new file mode 100644
index 0000000000..ae5c7ec7e6
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_2_73bd5d343286f61c9ac753ed3b00c149._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-08-06T15:55:56Z"
+ content="""
+This is quite old, is it still wanted?
+
+git's remote.name.fetch config can make it only fetch a particular branch,
+so that's one way to do this without adding an option.
+"""]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_3_bab52f2fd4f66cac6a178cdd9ef71c6d._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_3_bab52f2fd4f66cac6a178cdd9ef71c6d._comment
new file mode 100644
index 0000000000..8c6c7d389b
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_3_bab52f2fd4f66cac6a178cdd9ef71c6d._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/45b0925215b6b772921a50eca1f55b55"
+ subject="Still Wanted"
+ date="2019-07-22T17:06:20Z"
+ content="""
+Thanks for directing me here from our conversation on the [git-sync page](http://git-annex.branchable.com/sync/).
+
+RE your [first comment here](http://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/#comment-f5d79cf275bac5578a05cfb9f5b66292) this sounds like the behavior I'm looking for, and in particular for `git annex sync --branch git-annex` to be a special case (ideally configurable so I don't have to type it all the time); not sure if it should be handled by `git`'s config or tracked in the `git-annex` branch, but probably the former (since otherwise the behavior could change pre and post sync, which might be surprising).
+
+I'm trying to understand your [second comment](http://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/#comment-96120307c5584a563e4bf3ca3c4c3df3). I'm not 100% clear on what `git annex sync` actually does under the hood; if it's pushing and pulling, then presumably I'd need to tweak the git config entries for `remote.name.{push,pull}`, no? OTOH, with the `synced/` branch workflow, perhaps it's fetching, then merging, then pushing, and that's why I should tweak the fetch settings? This would need to get set for *all* of my remotes too, right?
+
+Assuming I'm understanding correctly, the downside to this approach is that it would also change the way base `git` works. Really, I'm looking for a workflow where `git annex` is (insofar as possible) narrowly responsible for managing the annex, and base `git` is responsible for everything it normally is. This would let me minimally modify my git-habits and just run `git annex add` and `git annex sync --content` from time to time to make sure that things are propagating in a sensible way based on how I've configured wanted/preferences. In particular, I'd like `git fetch` to still behave in the way that it used to, I just don't want `git annex sync` pulling and pushing around my code.
+"""]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_4_a765e998ffaecc2af681947263cd80d7._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_4_a765e998ffaecc2af681947263cd80d7._comment
new file mode 100644
index 0000000000..3d40958271
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_4_a765e998ffaecc2af681947263cd80d7._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="git annex sync commits changes, too?"
+ date="2019-07-22T17:25:39Z"
+ content="""
+I took a closer look at the [man page for `git-annex-sync`](http://git-annex.branchable.com/git-annex-sync/).
+
+My understanding is that running it without any options will
+
+1. commit any changes (presumably something like `commit -am 'some default message?'`)
+2. fetch and merge `synced/$(currentbranch)` and `git-annex` branches (presumably from *all* remotes unless o/w configured)
+3. push the branches from (2) back to the remotes
+
+I'm realizing that what I really want is a `git-annex-sync` command that will *just* sync `git-annex` content. The workflow I'd like is
+
+1. fetch and merge `git-annex` branch from all remotes (or as specified by arguments)
+2. push `git-annex` branch back to remotes from (1)
+3. If _content_ related flags in the style of arguments from `git-annex-sync` (e.g., `--content`) are passed, sync them around.
+
+So the command I think I'm looking for is something like `git annex sync --no-commit --branch git-annex`, but since it's still in todo, I assume the `--branch git-annex` behavior is not yet implemented. 
+Moreover, it seems I can configure the `--no-commit` option to be the default by setting the `annex.autocommit` option to false (and this setting is handled by the `git-annex` branch, with options for local override via local gitconfig). If `--branch` gets implemented, I'd love for there to be a similar config-level option like `annex.synccurrentbranch` with true giving the current (default) behavior wherein the current branch is fetch/merge/pushed, and `annex.synccurrentbranch` giving an alternate behavior akin to the hypothetical `git annex sync --branch git-annex`.
+
+Of course I think both features (adding `--branch` option to `git-annex-sync`; supporting `annex.synccurrentbranch` config) would be useful, but really just the latter would be enough for what I'm looking to do.
+
+Thanks for your consideration and for such an excellent tool; it's really been a gamechanger for me.
+"""]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_5_8f19d38c815dd3051004301a15657cf6._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_5_8f19d38c815dd3051004301a15657cf6._comment
new file mode 100644
index 0000000000..47e2061fd4
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_5_8f19d38c815dd3051004301a15657cf6._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="Still wanted (update with example)"
+ date="2020-02-13T20:08:45Z"
+ content="""
+I see this page recently was edited (when todo's were tagged) and so I wanted to chime in that this is still a feature I'm looking for, and I have a much less hypothetical use case for it.
+
+I'm a PhD student working on a research project where I supervise several undergraduates. We have a git repository that manages all of our code, and I let git-annex manage the large datafiles (also in the same repository) on which we run our code. The main repository is hosted on GitHub, and my students have read-only access to it. They've each made forks to which they have write access. We use a special remote that we all have write-access to, with wanted set to standard and group set to archive, so that it gets all of the content and distributes it as needed (the data is massive so git-annex is vital here since the student laptops can't realistically download it all at any one time).
+
+They use pull requests to the main GitHub repository to integrate their code changes, but we need a way to get the content of the git-annex branches in their forks (which are pushed to from their local repos) into the git-annex branch in the main GitHub repository. The natural solution seems for me (who has read/write access to the main repo and the fork) to do this, essentially pulling in git-annex branches from their forks to my local repo, and then pushing it to the main repo on GitHub. It'd also be nice if I can then push this back to all of their forks, too. I can do this manually, but I think I'd need to actually check out the git-annex branch (or stuff it in another worktree) and then do lots of work manually (or automate it in a script).
+
+First I tried `git annex sync --no-commit --no-push --no-pull` which (somewhat to my surprise) *did* pull the git-annex branches from their forks into my local repo, but didn't push `git-annex` back anywhere, and it neither pushed nor pulled `master`. So this was a good start, but I wanted to also push *only* the git-annex branch to the main repo (and ideally to their forks, too). So then I (foolishly) started dropping flags, and ended up in inadvertently pulling their work-in-progress `master` branches into the mainline and pushing this super-merged thing back to all of them. I was able to do some reseting and quick force-pushes before anyone noticed, but I should've known better :)
+
+Throughout this process I'm trying to teach them how to use git-annex (it's pretty clearly the right tool for the job :) but need to be really careful with what `git annex sync` commands I encourage them to run since I don't want the, 
+
+I'd love it if there was like a `--git-annex-branch-only` option that I could pass that would then do all the pushing/pulling goodness of `git annex sync` but *without* touching `master` (or whatever branch happens to be checked out). I could then teach the students to always use this flag to avoid actually introducing changes to their master branch (they're still learning git, too, so they'd have a hard time recovering from this). Even better if this was configurable, and something I could stick in the `git-annex-config` options so that when they clone the repo this setting would propagate to them along with the git-annex branch. 
+
+Is something like this in the pipeline? Also, is there a simpler workaround I can do for now that doesn't involve tons of (manual) merges and pushes?
+
+Thanks so much for such an excellent tool; if we didn't have this, we'd essentially just give up on version control for our scientific data, which would be a real bummer. 
+"""]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_6_15e336ea35f0233e22f7c5b656b616d2._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_6_15e336ea35f0233e22f7c5b656b616d2._comment
new file mode 100644
index 0000000000..bb5af0160b
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_6_15e336ea35f0233e22f7c5b656b616d2._comment
@@ -0,0 +1,56 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Still wanted (update with example)"""
+ date="2020-02-17T17:15:10Z"
+ content="""
+@Dan, thanks for explaining your use case.
+
+In particular, I see why you don't want to pull their master
+branches with the unfinished whatever, but do want to pull
+their git-annex branch, and probably fetch their feature branches
+too.
+
+I'm still unclear on why, after merging someone's feature
+branch into your branch (master I suppose), you would not
+want sync to push that updated branch back to origin? Is the issue not
+about pushing master to origin, but that you don't want it to push 
+master to their forks? But if their forks contain other changes in
+their master branches, it would not overwrite the changes.
+
+It does seem like setting remote.name.fetch would work in your use case,
+but I also understand why you might not want to use it -- refspecs are
+hard! -- and when you're dealing with feature branches that might be named
+anything, it's hard to write a refspec that does what you want, other than
+one that fetches everything and merges nothing.
+
+So I do see the appeal of a git-annex sync --only-annex that separates
+concerns, letting you use whatever git commands you normally would to
+commit and pull and push everything, except for the git-annex branch.
+
+And, that name implies it also syncs the annexed content, so no need to
+remember to use --content with it. (I want --content to be sync default,
+but there are backcompat issues with that so annex.synccontent is only an
+option.)
+
+Soo, I'm leaning toward adding that option and not some other --branches
+option that lists branches to sync or whatever.
+
+----
+
+And, since `git-annex config` can set repo-wide annex.synccontent and
+annex.autocommit that change the behavior of `git-annex sync`,
+it could make sense to also have a setting that enables --only-annex
+by default. I don't know if I'd encourage setting that in your repo though;,
+it might teach the students a non-standard git-annex behavior.
+Re that, it would be helpful if you could finish this interrupted
+thought of yours:
+
+> Throughout this process I'm trying to teach them how to use git-annex (it's
+> pretty clearly the right tool for the job :) but need to be really careful
+> with what `git annex sync` commands I encourage them to run since I don't
+> want the, 
+
+Because I'm not yet seeing how any use of git-annex sync by the students
+could be problimatic; it won't be able to push their master branch
+to your repo or anything.
+"""]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_7_757f97ac10035ec6b28720c0570b19f0._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_7_757f97ac10035ec6b28720c0570b19f0._comment
new file mode 100644
index 0000000000..b38f8bab06
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_7_757f97ac10035ec6b28720c0570b19f0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2020-02-17T19:07:47Z"
+ content="""
+Implemented --only-annex.
+
+I'm going to close this todo, but do follow up if that does not adequately
+cover your use case.
+"""]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_8_6c683fcba5d69a4c0051eb42b8c558a0._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_8_6c683fcba5d69a4c0051eb42b8c558a0._comment
new file mode 100644
index 0000000000..cd07856915
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_8_6c683fcba5d69a4c0051eb42b8c558a0._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="An overdue and overlong reply"
+ date="2020-02-17T22:59:19Z"
+ content="""
+It looks like this functionality was implemented before I could get my comment writen, but I thought it might be useful to post it anyway. It seems like the implementing changes are now in master, so if I build from source I'll get these new features, right? I assume they'll also make it into the next release of git-annex (at which point I'll version bump at homebrew, which is what I'm having my students use to install git-annex).
+
+Thanks for your thoughtful response. I also agree that having an --only-annex option is perfectly satisfactory and more nuanced --branch-to-sync options are probably overkill. As to whether --only-annex should imply --content, I'm more agnostic and defer to your wisdom. However, if I call git-annex with --only-annex --no-content, will it push/pull the git-annex branches and leave the content alone? From looking at your commit message, it sounds like there is now a --not-only-annex option which can override a configured only-annex property, but it's not clear how --no-content might enter the picture.
+
+Let me try to finish my dangling thought from the last comment thread. For clarity, I'll introduce some labels for repositories and assume the only people working on this project are me (Dan) and two students, Alice and Bob. Let Dan-local refer to the repository on my laptop (and similar for {Alice,Bob}-local), let Dan-github refer to my repo on GitHub, and {Alice,Bob}-github refer to my student's forks. Dan has push access to {Dan,Alice,Bob}-github. Alice and Bob can fetch from {Dan,Alice,Bob}-github, but can *only* push to their own github repositories (Alice can push to Alice-github, Bob to Bob-github).
+
+Without an --only-annex option, I have two primary concerns. The first is the thought I left dangling, which I'll now complete:
+Throughout this process I'm trying to teach them how to use git-annex (it's pretty clearly the right tool for the job :) ) but need to be really careful with what git annex sync commands I encourage them to run since I don't want them to inadvertantly pull changes into their local branches (especially integrating changes from one another) and then wind up being confused as to how things got there. Like many newcomers to git, they're still at the rote learning stage where they are memorizing commands to type and are still developing a mental model of what's happening when they fetch/pull/push. For this reason, I think that avoiding their local branches changing as a side-effect of a git-annex command (i.e., by specifying this option in the config that travels in git-annex branch) will make it easier for them to understand base git. There's some risk that they'll learn bad git-annex habits from this and be surprised at all the things git annex sync does when they use it elsewhere, but for now it seems easier to help them understand git but use git-annex mechanically, and once they're comfortable with that I can help them to understand what git-annex is actually doing and the nuances of git annex sync.
+
+The second problem is that because I'm the only one with push access to Dan-GitHub, everything has to get there either via a pull request (which I  can accept after review) or I need to push it there myself via Dan-local. In particular, to keep the git-annex branch in Dan-GitHub up to date, I need to be integrating {Alice,Bob}-github/git-annex (or perhaps synced/git-annex?) into Dan-local/git-annex and then push it to Dan-GitHub/git-annex. I can do this manually, but it's a lot of typing (especially if there are many more students than just Alice and Bob), so git annex sync seems like a nice way to accomplish this. However, it has the side effect of *also* pulling in {Alice,Bob}-GitHub/{synced/master,master} and then pushing that up to Dan-GitHub/synced/master, and if Alice and Bob are also running git annex sync, changes from Alice will show up in Bob-local/master and vice versa. Moreover, if they're also pushing e.g. Alice-local/master -> Alice-GitHub/master, their pull requests will suddenly get very noisy as they'll incorporate more than just their own changes, and for them to remedy this it will require careful use of git reset which is a dangerous command for them to run at this stage of their learning.
+
+Git that I am, after running git annex sync I saw that my Dan-local/master was now ahead of Dan-GitHub/master, and I foolishly pushed, which now plopped half-baked code from Alice and Bob into the primary branch of our primary repository on github.
+It also had the unfortunate side-effect of closing out open pull requests from Alice and Bob (since github saw that their changes were now reachable from Dan-Github/master). I did some reset-ing, git annex sync --cleanup, and some force pushes to clean everything up before Alice or Bob could fetch, so other than having to re-open their pull requests, this didn't screw them up too much.
+
+
+Finally, I want to clarify my understanding of the synced/branch workflow, which seems clever but I never fully understood it. From some simple experimenting (I have not waded very far into the source code), it seems that if I just run git annex sync (with no flags and assuming I haven't configured anything to do otherwise), and assuming that BRANCH is checked out locally, it will do the following, *I think*:
+
+1. Stage and commit any changes in tracked files
+1. Merge synced/BRANCH into BRANCH
+2. Loop over remotes, for each
+   2. Pull from the remote (seems like it just fetches all branches)
+   2. Merge REMOTE/BRANCH into BRANCH
+   3. If REMOTE/synced/BRANCH exists, merge it into BRANCH
+7. Do octopus merge of all REMOTE/git-annex and REMOTE/synced/git-annex branches into local git-annex branch
+4. Loop over remotes again, for each
+   5. Push git-annex -> REMOTE/synced/git-annex
+   6. Push git-annex -> REMOTE/git-annex
+   6. Push BRANCH -> REMOTE/synced/BRANCH
+
+
+
+
+I'm a little confused by what the synced/git-annex branches are for, but I suppose they're even less likely to ever be checkoued out that git-annex and provide a safeguard. I *think* they will be included in the octopus merge described above.
+
+Step 3.2 (merge REMOTE/BRANCH into BRANCH) was a surprise to me based on my reading of the git annex sync documentation since I only expected it to only integrate changes from REMOTE/synced/BRANCH.
+
+
+It seems like neither the sync documentation on [branchable](https://git-annex.branchable.com/sync/) nor what is obtained with `man git-annex-sync` enumerate all of these steps, although reading them together gives an almost complete picture of what is going on. Since the documentation suggests the end user can just run these steps manually as an alternative to using `git annex sync`, it seems like it'd be helpful to very concretely document what those steps are.
+I'd be happy to take a crack at updating the documentation to be more thorough, but wanted to make sure I actually understand what is going on before doing so. 
+
+Again, I want to re-articulate how much I enjoy git annex and how difficult it would be to do any sort of version control for our data without it. I deeply appreciate the time and energy that you put into this very valuable and useful tool.
+"""]]
diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_9_5bef9faa4df40b84c991b9ea5e1ab7a3._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_9_5bef9faa4df40b84c991b9ea5e1ab7a3._comment
new file mode 100644
index 0000000000..17f14eddd8
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_9_5bef9faa4df40b84c991b9ea5e1ab7a3._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2020-02-18T16:23:28Z"
+ content="""
+Indeed, I had missed the case of --no-content combined with --only-annex.
+Now implemented.
+
+It will be in the next release, which has slipped one day due to the above.
+;-)
+
+--
+
+I've improved the documentation of synced/ branches on the git-annex-sync
+man page, although users normally should not need to concern themselves
+with them.
+
+I see where the man page confused you about REMOTE/synced/BRANCH,
+that was some particularly poor wording and is fixed.
+
+The difficulty with documenting what git-annex sync does in extreme detail
+is that there are quite a lot of little hacks like synced branches that
+most users just don't need to know about, but help users in particular
+situations (who also generally don't know about or even notice it either).
+
+Just for example, sync sometimes pulls from the same remote twice. Why
+a second pull? Well, it knows it has spent a long time at the --content
+step, and so pulling again before it pushes makes it much less likely that
+the push will fail due to some other change having been made on the remote
+in the meantime. If a user were manually pulling and pushing, they would
+most likely pull again if their push failed due to such a situation, so
+there's not much point documenting what sync does (which could also change
+if I find a better approach).
+
+So I prefer to keep the description of sync as high level as possible.
+"""]]
diff --git a/doc/todo/syncthing_special_remote.mdwn b/doc/todo/syncthing_special_remote.mdwn
new file mode 100644
index 0000000000..36c284e2f2
--- /dev/null
+++ b/doc/todo/syncthing_special_remote.mdwn
@@ -0,0 +1,110 @@
+Among all possible [[todo/Bittorrent-like_features]] implementations,
+i think [Syncthing][] is one of the most interesting ones.
+
+First off, it is already [packaged for Debian][] with an [ITP
+underway][]. Second, it seems to use a fairly simple protocol, the
+[Block Exchange Protocol][]. It doesn't try to do everything under the
+sun and keeps things simple: NAT transversal, reuse TLS primitives and
+TCP, etc. It also seems to scale pretty well, if we are to believe the
+[usage statistics][].
+
+ [Syncthing]: https://syncthing.net/
+ [packaged for Debian]: http://apt.syncthing.net/
+ [ITP underway]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749887
+ [Block Exchange Protocol]: https://github.com/syncthing/specs/blob/master/BEPv1.md
+ [usage statistics]: https://data.syncthing.net/
+
+It does require the syncthing daemon to be running in order to
+transfer files so it could have similar problems than the
+[[special_remotes/ipfs]] remote which is that files get locally copied
+between the git-annex repository and the special remote.
+
+Furthermore, one of the main problems with this remote is that [public
+shares are not supported][], that is, in order to share with another
+remote, both remotes need to explicitely add each other, in syncthing!
+That makes pairing a little more difficult that it needs to.
+
+ [public shares are not supported]: https://forum.syncthing.net/t/implementing-public-shares/1186
+
+[[!toc levels=2]]
+
+Possible implementations
+========================
+
+I can think of a few different ways of implementing such a remote:
+
+ 1. share the `.git/annex/objects` directory through syncthing
+ 2. copy objects to the `~/Sync` directory (or elsewhere)
+ 3. interoperate with syncthing through the API
+ 4. reimplement the [Block Exchange Protocol][] natively
+
+Sharing the objects
+-------------------
+
+This is the easiest, but maybe the most dangerous: start syncthing and
+expose the `.git/annex/objects` directory to other peers.
+
+This of course has the downside that syncthing could technically start
+destroying objects without git-annex's knowledge, which is really
+bad. Hopefully, the readonly permissions on files could keep that from
+happening, but it still seems pretty unsafe.
+
+There is a way to mark a folder as "master" which makes it ignore
+changes from other nodes, but then that breaks the peer to peer nature
+of the protocol, which is hardly what we want. Marking the repo as
+untrusted would also be an important requirement here.
+
+Copying objects
+---------------
+
+Copying objects is the safest and easiest way to implement this. Add a
+new key? You just copy it to the sync directory. Remove a key? Just
+remove the file, and syncthing picks up the change.
+
+The main problem with this approach is of course the duplication of
+data, doubling the disk usage of all objects stored in the syncthing
+remote locally.
+
+There's also the problem that we do not reflect the fact that the
+git-annex objects are (potentially) in multiple syncthing remotes, and
+thus changing the number of copies. Even worse, once a file is dropped
+on one syncthing remote, it gets dropped everywhere. The solution for
+this of course is simply treat syncthing as a single copy of the
+objects. Note that this also applies to the shared objects method
+above.
+
+This can be easily implemented with the [[special_remotes/directory]]
+special remote:
+
+    git annex initremote syncthing type=directory directory=$HOME/Sync/ encryption=none
+    git annex describe syncthing "default syncthing directory"
+    git annex untrust syncthing
+
+Note that the last step isn't necessary if the syncthing folder is
+marked as "master".
+
+Communicate with the API
+------------------------
+
+Another way would be to talk directly to the [REST API][] (there's
+also a separate [event API][] for GUIs). Currently, this doesn't seem
+to hold much promise because the APIs are mostly read-only and don't
+allow adding objects at all, for example.
+
+ [REST API]: http://docs.syncthing.net/dev/rest.html
+ [event API]: http://docs.syncthing.net/dev/events.html
+
+Reimplement the protocol
+------------------------
+
+This would involve writing a syncthing client using the
+[Block Exchange Protocol][] specification. This would allow more
+complete control over the distribution of objects and so on,
+respecting git-annex's wanted/required content policies while at the
+same time sharing the data with other syncthing endpoints. It would
+also allow for tracking the number of copies of the objects and so on.
+
+Of course, this is a major undertaking and probably the hardest
+approach, but also the one potentially giving the most benefits.
+
+-- [[anarcat]]
diff --git a/doc/todo/tahoe_lfs_for_reals.mdwn b/doc/todo/tahoe_lfs_for_reals.mdwn
new file mode 100644
index 0000000000..2caeef11d3
--- /dev/null
+++ b/doc/todo/tahoe_lfs_for_reals.mdwn
@@ -0,0 +1,23 @@
+[[forum/tips:_special__95__remotes__47__hook_with_tahoe-lafs]] is a good
+start, but Zooko points out that using Tahoe's directory translation layer
+incurs O(N^2) overhead as the number of objects grows. Also, making
+hash subdirectories in Tahoe is expensive. Instead it would be good to use
+it as a key/value store directly. The catch is that doing so involves
+sending the content to Tahoe, and getting back a key identifier.
+
+This would be fairly easy to do as a [[backend|backends]], which can assign its
+own key names (although typically done before data is stored in it),
+but a tahoe-lafs special remote would be more flexible.
+
+To support a special remote, a mapping is needed from git-annex keys to
+Tahoe keys, stored in the git-annex branch.
+
+> This is now done, however, there are 3 known
+> problems: 
+> 
+> * tahoe start run unncessarily <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2149>
+> * web.port can conflict <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2147>
+> * Nothing renews leases, which is a problem on grids that expire.
+>   <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2212>
+
+> --[[Joey]] 
diff --git a/doc/todo/tahoe_lfs_for_reals/comment_1_0a4793ce6a867638f6e510e71dd4bb44._comment b/doc/todo/tahoe_lfs_for_reals/comment_1_0a4793ce6a867638f6e510e71dd4bb44._comment
new file mode 100644
index 0000000000..16ef882a42
--- /dev/null
+++ b/doc/todo/tahoe_lfs_for_reals/comment_1_0a4793ce6a867638f6e510e71dd4bb44._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="zooko"
+ ip="97.118.97.117"
+ subject="performance"
+ date="2011-05-17T19:20:39Z"
+ content="""
+Hm... O(N^2)? I think it just takes O(N). To read an entry out of a directory you have to download the entire directory (and store it in RAM and parse it). The constants are basically \"too big to be good but not big enough to be prohibitive\", I think. jctang has reported that his special remote hook performs well enough to use, but it would be nice if it were faster.
+
+The Tahoe-LAFS folks are working on speeding up mutable files, by the way, after which we would be able to speed up directories.
+"""]]
diff --git a/doc/todo/tahoe_lfs_for_reals/comment_2_80b9e848edfdc7be21baab7d0cef0e3a._comment b/doc/todo/tahoe_lfs_for_reals/comment_2_80b9e848edfdc7be21baab7d0cef0e3a._comment
new file mode 100644
index 0000000000..6dba86c47c
--- /dev/null
+++ b/doc/todo/tahoe_lfs_for_reals/comment_2_80b9e848edfdc7be21baab7d0cef0e3a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-05-17T19:57:33Z"
+ content="""
+Whoops! You'd only told me O(N) twice before..
+
+So this is not too high priority. I think I would like to get the per-remote storage sorted out anyway, since probably it will be the thing needed to convert the URL backend into a special remote, which would then allow ripping out the otherwise unused pluggable backend infrastructure.
+
+Update: Per-remote storage is now sorted out, so this could be implemented
+if it actually made sense to do so.
+"""]]
diff --git a/doc/todo/terminal_escapes_in_filenames.mdwn b/doc/todo/terminal_escapes_in_filenames.mdwn
new file mode 100644
index 0000000000..ed56ea37b0
--- /dev/null
+++ b/doc/todo/terminal_escapes_in_filenames.mdwn
@@ -0,0 +1,70 @@
+    touch $(echo -e "\e[31mfoo\e[0m")
+    git-annex add
+    git-annex whereis
+
+That displays "foo" in red twice. Compare with behavior of git commands that
+display that filename, which display it escaped.
+
+git-annex should probably do the same, when displaying filenames that it's
+working on or in messages.
+
+`git-annex find` is an interesting case because it's expected to be
+pipeable, and so should have raw filenames. Note that `find` actually
+escapes such filenames when outputting to a terminal, but not a pipe.
+
+git porcelain also accepts the escaped form of files as input, necessary for
+round-tripping though. git-annex currently does not. (git plumbing doesn't
+either)
+
+While terminals mostly protect against escape sequences doing very bad
+things, there are security holes in terminals still being found.
+
+Of course, such files in git repos can also be exploited by other commands
+eg `echo *`. 
+
+So this does not seem like a security hole in git-annex, but it would be
+useful defense in depth against terminal security holes, and also good to
+behave more like git.
+
+--[[Joey]]
+
+> Git.Filename.encode is implemented, and only needs to be used.
+> Note that core.quotePath controls whether git quotes unicode characters
+> (by default it does), so once this gets implemented, some users may want
+> to set that config to false. --[[Joey]]
+
+> Update: Messages now handles quoting of filenames, and also filtering
+> out any escape sequences in other things that get displayed (like Keys..)
+> 
+> Update: git-annex find and others that output directly all do
+> escaping/filtering.
+
+----
+
+Also: 
+It's possible that keys can also contain an escape sequence, eg in the
+extension of a SHA-E key. So commands like `git-annex lookupkey` 
+and `git-annex find` that output keys might need to handle
+that, when outputting to a terminal?
+
+> Fixed this with filtering of control characters in output.
+
+Also: git-annex initremote with autoenable may be able to cause a remote
+with a malicious name to be set up?
+
+> Fixed this by silently skipping autoenable, which seems fine since only
+> an attacker would ever try this.
+
+Also: Any place that an exception is thrown with an attacker-controlled value.
+`giveup` has been made to filter out control characters, but that leaves
+other exceptions, including ones thrown by libraries. Catch all exceptions
+at top-level (of program and/or worker threads) and filter out control
+characters?
+
+> Fixed with a top-level exception catcher; assuming all worker threads
+> have something waiting on them that displays or propagates their
+> exceptions.
+
+----
+
+> all [[fixed|done]]! --[[Joey]]
diff --git a/doc/todo/test_suite_unsafe_use_of_setEnv.mdwn b/doc/todo/test_suite_unsafe_use_of_setEnv.mdwn
new file mode 100644
index 0000000000..859d9ea428
--- /dev/null
+++ b/doc/todo/test_suite_unsafe_use_of_setEnv.mdwn
@@ -0,0 +1,22 @@
+The test suite uses setEnv in several places. (No other part of git-annex
+does, basically.) However, setEnv is not thread safe, if another thread
+runs getEnv at the same time it can crash. Or another setEnv, probably.
+
+This actually does segfault the test suite runners from time to time.
+The test suite currently notices if there was a segfault and re-runs it.
+While that works well enough, it's always possible there could be some
+other behavior than just a segfault.
+
+See <https://gitlab.haskell.org/ghc/ghc/-/issues/21243> for a test case and
+some analysis. See also <https://github.com/UnkindPartition/tasty/issues/326>. 
+Tasty uses getEnv, and that can apparently run while a test case is using setEnv.
+
+The main places that setEnv is used are in setTestMode. Fixing it will mean
+plumbing a value all through the test suite. Or perhaps, using a single
+toplevel MVar would be ok, since tests don't run concurrently?
+
+There is also Utility.Gpg.testHarness, which sets GNUPGHOME. It seems that
+instead, every place that git-annex is run inside the gpg test harness
+would need to add GNUPGHOME to the environment of the git-annex process.
+
+> [[fixed|done]] --[[Joey]] 
diff --git a/doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so.mdwn b/doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so.mdwn
new file mode 100644
index 0000000000..c4584eaf55
--- /dev/null
+++ b/doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so.mdwn
@@ -0,0 +1,41 @@
+I have upgraded our build environment for https://github.com/datalad/git-annex from bullseye (now old stable). to bookworm (now stable). Docker images are at https://hub.docker.com/repository/docker/datalad/buildenv-git-annex/tags (prior ones at https://hub.docker.com/repository/docker/datalad/buildenv-git-annex-buster/tags) .
+
+The git-annex (`10.20230828+git2-g50300a47fe-1~ndall+1`) has built fine and all testing passed, but one [extra test has failed](https://github.com/datalad/git-annex/actions/runs/6029623735/job/16366573859#step:6:33):
+
+```
+>> nfailed version 'libpcre.*so'
+>> strace -f git-annex version
+>> tee /dev/fd/2
+>> wc -l
+>> awk '/libpcre.*so.*ENOENT/{print}'
+[pid  1843] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v4/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  1843] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v3/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  1843] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  1843] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  1843] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  1843] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+> test 6 -lt 5
+Error: Process completed with exit code 1.
+```
+
+[previously (`10.20230828-1~ndall+1`was the last successful build) it was just 3](https://github.com/datalad/git-annex/actions/runs/6003338461/job/16282128434):
+
+```
+>> nfailed version 'libpcre.*so'
+>> strace -f git-annex version
+>> tee /dev/fd/2
+>> wc -l
+>> awk '/libpcre.*so.*ENOENT/{print}'
+[pid  1932] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  1932] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  1932] openat(AT_FDCWD, "/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/haswell/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+> test 3 -lt 5
+```
+
+where those 3 extra (identical) looks up are coming from now?
+
+PS Since not critical, I will workaround for now by raising max count to 7.
+
+[[!tag projects/datalad]]
+
+> [[done]] per my earlier comment --[[Joey]]
diff --git a/doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so/comment_1_35e85e3088c4453751ebffb7357a9f9b._comment b/doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so/comment_1_35e85e3088c4453751ebffb7357a9f9b._comment
new file mode 100644
index 0000000000..d45c3faa50
--- /dev/null
+++ b/doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so/comment_1_35e85e3088c4453751ebffb7357a9f9b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2023-08-31T13:57:21Z"
+ content="""
+oops -- I was blind. It is different directories - `x86-64-v4`, `x86-64-v3` and so on... Might be nothing for us to fix, just adding slowness... 
+"""]]
diff --git a/doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so/comment_2_61d70f4a06edaa593a17d47019be53de._comment b/doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so/comment_2_61d70f4a06edaa593a17d47019be53de._comment
new file mode 100644
index 0000000000..bc31ebfb8a
--- /dev/null
+++ b/doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so/comment_2_61d70f4a06edaa593a17d47019be53de._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2023-08-31T16:48:34Z"
+ content="""
+I looked at it \"wrong way\" - it is not 3 more, it is twice more!  after changing first threshold we get to the second check
+
+```
+>> nfailed init 'libpcre.*so'
+>> wc -l
+>> awk '/libpcre.*so.*ENOENT/{print}'
+>> strace -f git-annex init
+>> tee /dev/fd/2
+...
+[pid  1893] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v4/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  1893] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v3/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  1893] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  1893] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  1893] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/tls/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+[pid  1893] openat(AT_FDCWD, \"/usr/lib/git-annex.linux//lib/x86_64-linux-gnu/haswell/libpcre2-8.so.0\", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
+> test 251 -lt 140
+Error: Process completed with exit code 1.
+```
+
+so we are now getting twice more lookups for that single library for `annex init` as well, and that reaches 250. I will need to boost that threshold too. Overall -- sounds like some overhead would be \"twice slower\" now. Ideally we should find a way to workaround.
+"""]]
diff --git a/doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so/comment_3_89701d7011c3c9085afaab33aa16c39f._comment b/doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so/comment_3_89701d7011c3c9085afaab33aa16c39f._comment
new file mode 100644
index 0000000000..be04a64ac3
--- /dev/null
+++ b/doc/todo/the_same_path_looked_up_3_times_for_libpcre__42__.so/comment_3_89701d7011c3c9085afaab33aa16c39f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-09-07T16:50:20Z"
+ content="""
+I tracked this down: The /usr merge broke the optimisation,
+since it was symlinking the tls and hwcaps directories only
+when there was a /usr directory.
+
+Here I was seeing 3 failed stats for libpcre in a `git-annex version`
+and with the fix, it's down to 0.
+"""]]
diff --git a/doc/todo/timeout_support_for_importfeed.mdwn b/doc/todo/timeout_support_for_importfeed.mdwn
new file mode 100644
index 0000000000..f89da8d2e0
--- /dev/null
+++ b/doc/todo/timeout_support_for_importfeed.mdwn
@@ -0,0 +1,7 @@
+I have a git-annex importfeed of a bunch of podcasts that sometimes seems to
+get stalled and hang forever on one of them.
+
+It should be possible to time out the http requests in importfeed. Or even
+move the work into git-annex transferrer like has been done for transfers.
+Configurable by annex.stalldetection..
+--[[Joey]]
diff --git a/doc/todo/to_and_from_multiple_remotes.mdwn b/doc/todo/to_and_from_multiple_remotes.mdwn
new file mode 100644
index 0000000000..d8fc28acb2
--- /dev/null
+++ b/doc/todo/to_and_from_multiple_remotes.mdwn
@@ -0,0 +1,69 @@
+git annex sync supports git remote groups, that should be expanded to all
+commands supporting --to and --from. And since there will be a [Remote]
+list, could also support --to foo --to bar etc.
+
+--[[Joey]]
+
+Started working on this in multifromto branch.
+
+Problem: Command.Move uses onlyActionOn, so only allows one remote to
+process a key at a time. Seems that onlyActionOn needs to be expanded to
+include the remote.
+
+Problem: The concurrency is not right yet. For example,
+`git-annex copy --to foo --to bar -J2` will start actions copying a
+file to both remotes. Assume the copy to bar finishes first.
+Then it will start an action copying the next file to foo, despite a
+copy to foo already running. 
+
+To fix this, it would help to look at Annex.activeremotes when starting the
+next action. If foo is busy, start the action on bar instead. It would
+be possible to build up a queue of actions that have not yet been started on
+a remote. That risks using a lot of memory if one remote is very slow.
+The queue would need to be capped at some amount, and when full,
+delay until the laggard remotes catches up.
+
+Bonus: git annex sync --content -J2 already works, but it has the same
+problem described above and ought to be able to be fixed the same way.
+
+Also worth noting that with --auto and -J, git-annex may make more transfers
+than preferred content settings demand, because it will start several
+transfers to different remotes at once. If only one copy is needed
+amoung all the remotes, it won't notice and a copy will be sent to all
+remotes. I think this is something the user can understand though?
+
+----
+
+Looking at commands that support --to and --from and what each should do,
+there is a lot of diversity.
+
+git annex move --to of course removes the local copy. So if moving to
+multiple remotes it would need to delay that removal until it's sent to all
+of them. And it really only ought to try to remove the local copy once
+at the end, not once per remote moved to.
+
+git annex move --from ought to spread the load amoung remotes with -Jn,
+and once a file is downloaded, it needs to try to remove it from all the
+remotes.
+
+git annex mirror --from mirrors one remote; mirroring from 
+multiple remotes does not really make any sense. mirror --to multiple
+could be done.
+
+git annex unused --from seems unlikely to make sense with multiple remotes,
+since it would result in a list of keys distributed amoung them, and what
+would be done with that? Perhaps a git annex drop --from multiple remotes,
+but that would be innefficient. A shell script looping over remotes makes
+more sense if the user wants to drop unused from multiple remotes.
+
+git annex get/fsck/copy/export/transferkey/drop/dropunused all make sense to
+support multiple remotes. But with -Jn the operations that get files behave
+differently than the operations that drop files. The gets want to balance
+load amoung the remotes, while the drops and uploads need to run each
+action over each remote.
+
+Seems two runners are needed with different concurrency behavior, one that
+balances the load amoung remotes, and one that runs the same action against
+multiple remotes concurrently.
+
+[[!tag needsthought]]
diff --git a/doc/todo/to_and_from_multiple_remotes/comment_1_2c055c3f55e0796b6842df8c2733726b._comment b/doc/todo/to_and_from_multiple_remotes/comment_1_2c055c3f55e0796b6842df8c2733726b._comment
new file mode 100644
index 0000000000..d9bd491854
--- /dev/null
+++ b/doc/todo/to_and_from_multiple_remotes/comment_1_2c055c3f55e0796b6842df8c2733726b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-10-04T01:11:10Z"
+ content="""
+Maybe also, implement git-annex-put that's like git-annex-get but ensures a file or key exists on a remote, rather than locally?   Use case is to ensure, before starting an AWS job, that its inputs exist in an S3 bucket, getting copied from other remotes as needed.   Also if they're in another S3 bucket can do the copy without downloading locally.
+"""]]
diff --git a/doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3.mdwn b/doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3.mdwn
new file mode 100644
index 0000000000..949fe95714
--- /dev/null
+++ b/doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3.mdwn
@@ -0,0 +1,8 @@
+it might already be the case but I still cannot read haskel and don't know how to simulate quickly.  But I am following up [on a statement from openneuro folks](https://github.com/OpenNeuroOrg/openneuro/issues/1791#issuecomment-685024674) that they observed some exports failing due to 500 errors and thus needing to re-export.  Since 500 could be very intermittent, I expect git-annex be resilient to them and sleep-a-little/retry at least for some reasonable amount of time.
+
+If git-annex already does that, please pardon my noise and close this TODO.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+[[fixed|done]] --[[Joey]]
diff --git a/doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3/comment_1_42256576a4b5e8312b12e785fbc8fb1f._comment b/doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3/comment_1_42256576a4b5e8312b12e785fbc8fb1f._comment
new file mode 100644
index 0000000000..a533214178
--- /dev/null
+++ b/doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3/comment_1_42256576a4b5e8312b12e785fbc8fb1f._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-09-01T19:38:00Z"
+ content="""
+It doesn't, but what it is supposed to do is resume a failed export
+efficiently. It remembers which files it has already exported, and
+should jump right to the one that failed. Necessarily starting from the
+beginning in uploading it because the API does not allow resuming at the
+byte it left off.
+
+So I'd like to first check that works, because it seems more important that
+work well.
+
+That said, seems like if annex.retry is configured, it should honor it.
+At first glance, this may be all that's needed:
+
+	diff --git a/Command/Export.hs b/Command/Export.hs
+	index d1fde25d1..db52609a7 100644
+	--- a/Command/Export.hs
+	+++ b/Command/Export.hs
+	@@ -281,9 +281,7 @@ performExport r db ek af contentsha loc allfilledvar = do
+	 	sent <- tryNonAsync $ case ek of
+	 		AnnexKey k -> ifM (inAnnex k)
+	 			( notifyTransfer Upload af $
+	-				-- Using noRetry here because interrupted
+	-				-- exports cannot be resumed.
+	-				upload (uuid r) k af noRetry $ \pm -> do
+	+				upload (uuid r) k af configuredRetry $ \pm -> do
+	 					let rollback = void $
+	 						performUnexport r db [ek] loc
+	 					sendAnnex k rollback $ \f ->
+
+
+(stdRetry might be ok too, just a question of whether forwardRetry would
+retry excessively in some cases. Now that I think about it, need
+to [[limit_forwardRetry]].)
+"""]]
diff --git a/doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3/comment_2_6b655d30bf07518f33ec42cdeabef4ef._comment b/doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3/comment_2_6b655d30bf07518f33ec42cdeabef4ef._comment
new file mode 100644
index 0000000000..ff9f82d315
--- /dev/null
+++ b/doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3/comment_2_6b655d30bf07518f33ec42cdeabef4ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-09-04T17:00:11Z"
+ content="""
+What about the other side of export, import? Looks to me that does not
+retry either.
+"""]]
diff --git a/doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3/comment_3_fb3e0585f6700050db7a06e27d8e1099._comment b/doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3/comment_3_fb3e0585f6700050db7a06e27d8e1099._comment
new file mode 100644
index 0000000000..e4fea93de0
--- /dev/null
+++ b/doc/todo/tolerate_intermittent_errors_upon___34__export__34_____40__and_probably_copy__41___to_S3/comment_3_fb3e0585f6700050db7a06e27d8e1099._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-09-04T17:40:07Z"
+ content="""
+Both retry now.
+"""]]
diff --git a/doc/todo/tor.mdwn b/doc/todo/tor.mdwn
new file mode 100644
index 0000000000..b1197643e7
--- /dev/null
+++ b/doc/todo/tor.mdwn
@@ -0,0 +1,28 @@
+git-annex sync over tor
+
+Mostly working!
+
+Current todo list:
+
+* When a transfer can't be done because another transfer of the same 
+  object is already in progress, the message about this is output by the
+  remotedaemon --debug, but not forwarded to the peer, which shows
+  "Connection reset by peer"
+* Think about locking some more. What happens if the connection to the peer
+  is dropped while we think we're locking content there from being dropped?
+
+Eventually:
+
+* Windows and Android support.
+* Limiting authtokens to read-only access.
+* Revoking authtokens. (This and read-only need a name associated with an
+  authtoken, so the user can adjust its configuration after creating it.)
+* friend-of-a-friend peer discovery to build more interconnected networks
+  of nodes
+* Discovery of nodes on same LAN, and direct connection to them.
+* Make `git annex map` show a peer's remotes?  
+  Would it be surprising if peers can learn this information?
+
+> While the above "eventually" todo list is not implemented, the main
+> todo has been implemented for a long time. I think if users need
+> such things, they should be in separate todos. So, [[done]] --[[Joey]]
diff --git a/doc/todo/track_free_space_in_repos_via_git-annex_branch.mdwn b/doc/todo/track_free_space_in_repos_via_git-annex_branch.mdwn
new file mode 100644
index 0000000000..3b0acecbcc
--- /dev/null
+++ b/doc/todo/track_free_space_in_repos_via_git-annex_branch.mdwn
@@ -0,0 +1,88 @@
+If the total space available in a repository for annex objects is recorded
+on the git-annex branch (by the user running a command probably, or perhaps
+automatically), then it is possible to examine the git-annex branch and
+tell how much free space a remote has available.
+
+One use case is just to display it in `git-annex info`. But a more
+compelling use case is [[design/balanced_preferred_content]], which needs a
+way to tell when an object is too large to store on a repository, so that
+it can be redirected to be stored on another repository in the same group.
+
+This was actually a fairly common feature request early on in git-annex
+and I probably should have thought about it more back then!
+
+`git-annex info` has recently started summing up the sizes of repositories
+from location logs, and is well optimised. In my big repository, that takes
+8.54 seconds of its total runtime.
+
+Since info already knows the repo sizes, just adding a `git-annex maxsize
+here 200gb` type of command would let it display the free space of all
+repos that had a maxsize recorded, essentially for free.
+
+But 8 seconds is rather a long time to block a `git-annex push`
+type command. Which would be needed if any remote's preferred content
+expression used the free space information.
+
+Would it be possible to update incrementally from the previous git-annex
+branch to the current one? That's essentially what `git-annex log
+--sizesof` does for each commit on the git-annex branch, so could
+imagine adapting that to store its state on disk, so it can resume
+at a new git-annex branch commit.
+
+Perhaps a less expensive implementation than `git-annex log --sizesof`
+is possible, to get only the current sizes, if the past sizes are known at a
+particular git-annex branch commit. We don't care about sizes at
+intermediate points in time, which that command does calculate.
+
+See [[todo/info_--size-history]] for the subtleties that had to be handled.
+In particular, compating the previous git-annex branch commit to current may
+yield lines that seem to indicate content was added to a repo, but in fact
+that repo already had that content at the previous git-annex branch commit
+and another log line was recorded elsewhere redundantly.
+So it needs to look at the location log's value at the 
+previous commit in order to determine if a change to a log should be
+counted.
+
+Worst case, that's queries of the location log file for every single key.
+If queried from git, that would be slow -- slower than `git-annex info`'s
+streaming approach. If they were all cached in a sqlite database, it might
+manage to be faster?
+
+## incremental update via git diff
+
+Could `git diff -U1000000` be used and the patch parsed to get the complete
+old and new location log? (Assuming no log file ever reaches a million
+lines.) I tried this in my big repo, and even diffing from the first
+git-annex branch commit to the last took 7.54 seconds. 
+
+Compare that with the method used by `git-annex info`'s size gathering, of
+dumping out the content of all files on the branch with `git ls-tree -r
+git-annex |awk '{print $3}'|git cat-file --batch --buffer`, which only
+takes 3 seconds. So, this is not ideal when diffing to too old a point.
+
+Diffing in my big repo to the git-annex branch from 2020 takes 4 seconds.  
+... from 3 months ago takes 2 seconds.  
+... from 1 week ago takes 1 second.  
+
+## incremental update when merging git-annex branch
+
+When merging git-annex branch changes into .git/annex/index, 
+it already diffs between the branch and the index and uses `git cat-file`
+to get both versions of the file in order to union merge them.
+
+That's essentially the same information needed to do the incremental update
+of the repo sizes. So could update sizes at the same time as merging the
+git-annex branch. That would be essentially free!
+
+Note that the use of `git cat-file` in union merge is not --buffer
+streaming, so is slower than the patch parsing method that was discussed in
+the previous section. So it might be possible to speed up git-annex branch
+merging using patch parsing.
+
+Note that Database.ContentIdentifier and Database.ImportFeed also update
+by diffing from the old to new git-annex branch (with `git cat-file` to
+read log files) so could also be sped up by being done at git-annex branch
+merge time. Those are less expensive than diffing the location logs only
+because the logs they diff are less often used, and the work is only 
+done when relevant commands are run.
+
diff --git a/doc/todo/tracking_changes_to_metadata.mdwn b/doc/todo/tracking_changes_to_metadata.mdwn
new file mode 100644
index 0000000000..81cfb13a8a
--- /dev/null
+++ b/doc/todo/tracking_changes_to_metadata.mdwn
@@ -0,0 +1,14 @@
+I use git-annex to store my music collection, which includes many albums I've ripped but don't like, as well as many albums I do like to listen to regularly but can't put on all my devices because of storage space limits. Previously I've used a `Now Playing` directory to track this, with copies of all the symlinks, but when I edit files (to correct file tags or whatever), things can get out of sync, so now I'm trying to use metadata instead. I was thinking to add a `NowPlaying=machinename` scheme and then on each machine I can `git annex get --metadata NowPlaying=machinename`.
+
+While migrating to this scheme, I've discovered a few places where a file wasn't in `Now Playing` when I expected it to be. A good example is that some songs exist both on an artist's album as well as a compilation album, and I've `drop`ped the track from the compilation album because I already had it on the artist's album.
+
+This has made me think that it would be nice to track changes to metadata, the same way we do with git commits on the files themselves. Right now this is almost possible using the `git-annex` branch. However:
+
+1. Every change to metadata just has the commit message "update". It would be nice if I could pass a commit message using something like `git annex metadata -s 'NowPlaying-=machinename' -m "This already exists on Artist - Album"`.
+2. Looking at the metadata history for a given file requires dereferencing the git-annex symlink and knowing some git-annex internals. It would be nice if there was a `git annex metadata log <filename>` command.
+
+From reading the documentation about [[tips/metadata_driven_views]], it seems almost like #1 would be possible using views and doing a `git commit` myself, but that still just generates an "update" message on the `git-annex` branch. Even if it did work, using `git annex view 'NowPlaying=*'` excludes all files that aren't tagged with any machine, which makes adding new files harder.
+
+What do you think? Is this abuse of the `git-annex` branch? Would this interfere with [[design/caching_database]]?
+
+[[!tag needsthought moreinfo]]
diff --git a/doc/todo/tracking_changes_to_metadata/comment_1_825c15ba36324aad58faf643057b256a._comment b/doc/todo/tracking_changes_to_metadata/comment_1_825c15ba36324aad58faf643057b256a._comment
new file mode 100644
index 0000000000..2942dbb413
--- /dev/null
+++ b/doc/todo/tracking_changes_to_metadata/comment_1_825c15ba36324aad58faf643057b256a._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-26T16:58:17Z"
+ content="""
+I don't see the benefit to having custom commit messages for metadata
+changes. The changes are there in machine-readable format, so why
+involve a human?
+
+I agree that it would be useful to have a way to look at the metadata
+history, much as `git annex log` looks at the location history.
+
+Indeed, a lot of `git annex log` could be reused; `getAllLog` and
+`getKeyLog` are the hard part and would be reusable for metadata logs.
+The result might be something like this, when run on a file "foo":
+
+	+ Thu, 22 Jun 2017 17:07:43 EST foo | author=foo
+	- Thu, 22 Jun 2017 17:07:43 EST foo | author=bar
+	+ Thu, 11 Jun 2017 11:11:11 EST foo | author=bar
+
+Note that git-annex log is necessarily slow when run on a lot of files,
+because it has to run a git command per file to get the log. `git-annex log
+--all` shows a fast stream of changes from newest first, but displays the
+git-annex key that was changed, not a filename. A version of `git annex
+log` for metadata would have these same limitations.
+
+Would this help with your use case?
+"""]]
diff --git a/doc/todo/tracking_changes_to_metadata/comment_2_03a631beaa20a479f5016def7585d363._comment b/doc/todo/tracking_changes_to_metadata/comment_2_03a631beaa20a479f5016def7585d363._comment
new file mode 100644
index 0000000000..96120ce6c5
--- /dev/null
+++ b/doc/todo/tracking_changes_to_metadata/comment_2_03a631beaa20a479f5016def7585d363._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="glasserc"
+ avatar="http://cdn.libravatar.org/avatar/8e865c04033751520601e9c15e58ddc4"
+ subject="comment 2"
+ date="2017-07-02T02:56:19Z"
+ content="""
+I agree that a human-readable commit message is probably the wrong place to put it. I didn't know about `git annex log` but that sounds helpful. I wouldn't need it to be fast -- it would be for rare interactive use.
+
+I'd like to not just be able to see what changed with the metadata but store a description of why as well, which is why I thought of commit messages. Would your design support that?
+
+Thanks for your consideration.
+"""]]
diff --git a/doc/todo/tracking_changes_to_metadata/comment_3_a05652472c37c463eca22f11cf6596a4._comment b/doc/todo/tracking_changes_to_metadata/comment_3_a05652472c37c463eca22f11cf6596a4._comment
new file mode 100644
index 0000000000..d95a6553f2
--- /dev/null
+++ b/doc/todo/tracking_changes_to_metadata/comment_3_a05652472c37c463eca22f11cf6596a4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-09-06T17:17:38Z"
+ content="""
+While git-annex does now let annex.commitmessage be set to specify
+a commit message, it seems to me that you could include your reason for the
+metadata value as yet more metadata. Ie:
+
+	annex metadata -s 'NowPlaying-=machinename' -s 'message=This already exists on Artist - Album'
+
+And a metadata log display would then naturally include those messages next
+to the change they describe.
+"""]]
diff --git a/doc/todo/transitive_transfers.mdwn b/doc/todo/transitive_transfers.mdwn
new file mode 100644
index 0000000000..ff0e57ba9f
--- /dev/null
+++ b/doc/todo/transitive_transfers.mdwn
@@ -0,0 +1,29 @@
+[[!meta title="streaming for transitive transfers"]]
+
+This todo was originally about `git-annex copy --from --to`, which got
+implemented, but without the ability to stream content between the two
+remotes.
+
+So this todo remains open, but is now only concerned with
+streaming an object that is being received from one remote out to another
+remote without first needing to buffer the whole object on disk.
+
+git-annex's remote interface does not currently support that.
+`retrieveKeyFile` stores the object into a file. And `storeKey`
+sends an object file to a remote.
+
+The interface would need to be extended to support this, and the external
+special remote interface as well. As well as git remotes and special
+remotes needing to be updated to support the new interface.
+
+There's also a question of buffering. If a object is being received from a
+remote faster than it is being sent to the other remote, it has to be
+buffered somewhere, eg not in memory. Or the receive interface needs to
+include a way to get the sender to pause.
+
+----
+
+Recieving to a file, and sending from the same file as it grows is one
+possibility, since that would handle buffering, and it might avoid needing
+to change interfaces as much. It would still need a new interface since the
+current one does not guarantee the file is written in-order.
diff --git a/doc/todo/transitive_transfers/comment_1_d244295696be5a8164db45f7fad1701a._comment b/doc/todo/transitive_transfers/comment_1_d244295696be5a8164db45f7fad1701a._comment
new file mode 100644
index 0000000000..48995dcb86
--- /dev/null
+++ b/doc/todo/transitive_transfers/comment_1_d244295696be5a8164db45f7fad1701a._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-09-21T17:53:12Z"
+ content="""
+(Let's not discuss the behavior of copy --to when the file is not locally
+present here; there is plenty of other discussion of that in eg
+<http://bugs.debian.org/671179>)
+
+git-annex's special remote API does not allow remote-to-remote transfers
+without spooling it to a file on disk first. And it's not possible to do
+using rsync on either end, AFAICS. It would be possible in some other cases
+but this would need to be implemented for each type of remote as a new API
+call.
+
+Modern systems tend to have quite a large disk cache, so it's quite
+possible that going via a temp file on disk is not going to use a lot of
+disk IO to write and read it when the read and write occur fairly close
+together.
+
+The main benefit from streaming would probably be if it could run the
+download and the upload concurrently. But that would only be a benefit
+sometimes. With an asymmetric connection, saturating the uplink tends to
+swamp downloads. Also, if download is faster than upload, it would have to
+throttle downloads (which complicates the remote API much more), or buffer
+them to memory (which has its own complications).
+
+Streaming the download to the upload would at best speed things up by a
+factor of 2. It would probably work nearly as well to upload the previously
+downloaded file while downloading the next file.
+
+It would not be super hard to make `git annex copy --from --to` download a file,
+upload it, and then drop it, and parallelizing it with -J2 would
+keep both the --from and --to remotes bandwidth saturated pretty well.
+
+Alhough not perfectly, because two jobs could both be downloading while
+the uplink is left idle. To make it optimal, it would need to do the
+download and when done, push the upload+drop into another queue of actions
+that is processed concurrently with other downloads.
+
+And there is a complication with running that at the same time as eg `git
+annex get` of the same file. It would be surprising for get to succeed
+(because copy has already temporarily downloaded the file) and then have
+the file later get dropped. So, it seems that `copy --from --to` would need
+to stash the content away in a temp file somewhere instead of storing it
+in the annex proper.
+"""]]
diff --git a/doc/todo/transitive_transfers/comment_2_7255f5083283b0ae7e7fc41e127bd829._comment b/doc/todo/transitive_transfers/comment_2_7255f5083283b0ae7e7fc41e127bd829._comment
new file mode 100644
index 0000000000..54d9c8029d
--- /dev/null
+++ b/doc/todo/transitive_transfers/comment_2_7255f5083283b0ae7e7fc41e127bd829._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="JasonWoof"
+ subject="simpler use case"
+ date="2016-09-22T00:40:07Z"
+ content="""
+Here's my use case (much simpler)
+
+Three git repos:
+
+desktop: normal checkout, source of almost all annexd files, commits, etc.. The only place I run git annex commands. Not enough space to stored all annexed files
+
+main_external: bare git repo, stores all annext file contents, but no file tree. Usually connected. Purpose: primary backups
+
+old_external: like main_external, except connected only occasionally.
+
+
+I periodically copy from desktop to main_external. That's all well and good.
+
+The tricky part is when I plug in old_external and want to get everything on there. It's hard to get content onto old_external that is stored only on main_external. That's when I want to:
+
+    git annex copy --from=main_external --to=old_external --not --in old_external
+
+Note that this would _not_ copy obsolete data (ie only referenced from old git commits)  stored in old_external. I like that.
+
+To work around the lack of that feature, I try to keep coppies on desktop until I've had a chance to copy them to both external drives. It's good for numcopies, but I don't like trying to keep track of it, and I wish I could choose to let there be just one copy of things on main_external for replaceable data.
+"""]]
diff --git a/doc/todo/transitive_transfers/comment_3_e5c2ede203e7bdb5af8432df6c09268f._comment b/doc/todo/transitive_transfers/comment_3_e5c2ede203e7bdb5af8432df6c09268f._comment
new file mode 100644
index 0000000000..7023cd26a5
--- /dev/null
+++ b/doc/todo/transitive_transfers/comment_3_e5c2ede203e7bdb5af8432df6c09268f._comment
@@ -0,0 +1,81 @@
+[[!comment format=mdwn
+ username="https://anarc.at/openid/"
+ nickname="anarcat"
+ subject="thanks for considering this!"
+ date="2016-09-22T12:43:11Z"
+ content="""
+> (Let's not discuss the behavior of copy --to when the file is not
+> locally present here; there is plenty of other discussion of that in
+> eg http://bugs.debian.org/671179)
+
+Agreed, it's kind of secondary.
+
+> git-annex's special remote API does not allow remote-to-remote
+> transfers without spooling it to a file on disk first.
+
+yeah, i noticed that when writing my own special remote.
+
+> And it's not possible to do using rsync on either end, AFAICS.
+
+That is correct.
+
+> It would be possible in some other cases but this would need to be
+> implemented for each type of remote as a new API call.
+
+... and would fail for most, so there's little benefit there.
+
+how about a socket or FIFO of some sort? i know those break a lot of
+semantics (e.g. `[ -f /tmp/fifo ]` fails in bash) but they could be a
+solution...
+
+> Modern systems tend to have quite a large disk cache, so it's quite
+> possible that going via a temp file on disk is not going to use a
+> lot of disk IO to write and read it when the read and write occur
+> fairly close together.
+
+true. there are also in-memory files that could be used, although I
+don't think this would work across different process spaces.
+
+> The main benefit from streaming would probably be if it could run
+> the download and the upload concurrently.
+
+for me, the main benefit would be to deal with low disk space
+conditions, which is quite common on my machines: i often cram the
+disk almost to capacity with good stuff i want to listen to
+later... git-annex allows me to freely remove stuff when i need the
+space, but it often means i am close to 99% capacity on the media
+drives i use.
+
+>  But that would only be a benefit sometimes. With an asymmetric
+>  connection, saturating the uplink tends to swamp downloads. Also,
+>  if download is faster than upload, it would have to throttle
+>  downloads (which complicates the remote API much more), or buffer
+>  them to memory (which has its own complications).
+
+that is true.
+
+> Streaming the download to the upload would at best speed things up
+> by a factor of 2. It would probably work nearly as well to upload
+> the previously downloaded file while downloading the next file.
+
+presented like that, it's true that the benefits of streaming are not
+good enough to justify the complexity - the only problem is large
+files and low local disk space... but maybe we can delegate that
+solution to the user: \"free up at least enough space for one of those
+files you want to transfer\".
+
+[... -J magic stuff ...]
+
+> And there is a complication with running that at the same time as eg
+> git annex get of the same file. It would be surprising for get to
+> succeed (because copy has already temporarily downloaded the file)
+> and then have the file later get dropped. So, it seems that copy
+> --from --to would need to stash the content away in a temp file
+> somewhere instead of storing it in the annex proper.
+
+My thoughts exactly: actually copying the files to the local repo
+introduces all sorts of weird --numcopies nastiness and race
+conditions, it seems to me.
+
+thanks for considering this!
+"""]]
diff --git a/doc/todo/transitive_transfers/comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment b/doc/todo/transitive_transfers/comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment
new file mode 100644
index 0000000000..bf6887ec52
--- /dev/null
+++ b/doc/todo/transitive_transfers/comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="erics"
+ subject="comment 4"
+ date="2016-09-25T00:33:56Z"
+ content="""
+> And there is a complication with running [`git annex copy --from --to`] at the same time as eg `git annex get` of the same file. It would be surprising for get to succeed (because copy has already temporarily downloaded the file) and then have the file later get dropped.
+
+A solution to this subproblem would transparently fall out of a facility for [logically dropping files](http://git-annex.branchable.com/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/#comment-9672d46a18a381971dd818cde6efbc33), which was briefly talked about a long time ago.  Just mark the file as *logically dropped*.  If the user `git annex get`s it while the copy-out is in progress, its status will change to \"present\", so *copy* will know not to physically delete it.
+
+(Of course there are race conditions involved, but I presume/hope that they're no worse than git-annex already has to deal with.)
+"""]]
diff --git a/doc/todo/transitive_transfers/comment_5_50670cb52b29dc9c0c6c981e6f6d198b._comment b/doc/todo/transitive_transfers/comment_5_50670cb52b29dc9c0c6c981e6f6d198b._comment
new file mode 100644
index 0000000000..5cc5cf25ef
--- /dev/null
+++ b/doc/todo/transitive_transfers/comment_5_50670cb52b29dc9c0c6c981e6f6d198b._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-10-05T19:59:13Z"
+ content="""
+@JasonWoof re your use case, you don't need transitive transfers.
+You can simply go to `old_external` and run:
+
+	git annex sync main_external
+	git annex get --branch main_external/master
+
+(Assuming that the `old_external` has a `main_external` remote.)
+
+This --branch option was added in a recent git-annex release.
+"""]]
diff --git a/doc/todo/transitive_transfers/comment_6_ddef2f127a49c2eb8a15b5848756d888._comment b/doc/todo/transitive_transfers/comment_6_ddef2f127a49c2eb8a15b5848756d888._comment
new file mode 100644
index 0000000000..323dcbae9c
--- /dev/null
+++ b/doc/todo/transitive_transfers/comment_6_ddef2f127a49c2eb8a15b5848756d888._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="annex2384@290036d126d86bcec28ee2f2ead549de1f59e90e"
+ nickname="annex2384"
+ avatar="http://cdn.libravatar.org/avatar/ad36fdc55abd8b9913b774fcd0177709"
+ subject="Similar use case"
+ date="2020-02-04T03:48:39Z"
+ content="""
+I have a similar use case, wanting to sync files to my music player from a machine that doesn't store a local copy of my music collection. I'm using a directory special remote with exporttree=yes since the player uses a FAT filesystem. Spooling locally would be absolutely fine with me; I just don't want to fetch any content that's already on the player. I suppose I could so something clever with the preferred content expression to accomplish this, but it seems like it might be complicated. For example, I think I could put the laptop and player each in a \"playersync\" group, with the player additionally in a \"player\" group, set the groupwanted expression on the playersync gorup to the files I want on the player, set the player's wanted to groupwanted and the laptop's wanted to \"groupwanted and not inallgroup=player\". But that seems pretty convoluted.
+"""]]
diff --git a/doc/todo/transitive_transfers/comment_7_6417ec94a5723776b6688ccbb0453ffc._comment b/doc/todo/transitive_transfers/comment_7_6417ec94a5723776b6688ccbb0453ffc._comment
new file mode 100644
index 0000000000..3fe5bc28bf
--- /dev/null
+++ b/doc/todo/transitive_transfers/comment_7_6417ec94a5723776b6688ccbb0453ffc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="copying directly from directory special remote to the cloud"
+ date="2020-10-18T21:00:58Z"
+ content="""
+One more use case: running git-annex inside a VirtualBox VM (Linux guest on Windows host), with the repo inside the VM, operating on files on the host through [shared folders](https://help.ubuntu.com/community/VirtualBox/SharedFolders).  Shared folder is too large to copy inside the VM.  With the recent addition of [[importing from directory special remote without downloading|https://git-annex.branchable.com/todo/importing_from_special_remote_without_downloading/]] (thanks @joeyh for implementing that!), can import the files into the repo, bypassing [[issues with VirtualBox shared folder filesystem|bugs/removeLink_failed_when_initializing_a_repo_in_a_VirtualBox_shared_folder]].  But can't upload the files to a cloud special remote, without first [[`git-annex-get`|git-annex-get]]ting them into the VM, and I unfortunately don't have space for two local copies of each file.  So a direct transfer from a directory special remote to a cloud special remote would help a lot.  
+
+The alternative, of course, is to run git-annex directly on Windows, but I've run into speed issues with that, and using WSL means losing ability to run VirtualBox, so running git-annex from a guest VM and operating on host files through the shared folder filesystem -- broken as that is -- seems like the best option right now.
+"""]]
diff --git a/doc/todo/transitive_transfers/comment_8_7ffe073c582fc9392213ce52ba6ba398._comment b/doc/todo/transitive_transfers/comment_8_7ffe073c582fc9392213ce52ba6ba398._comment
new file mode 100644
index 0000000000..2b1b6830d3
--- /dev/null
+++ b/doc/todo/transitive_transfers/comment_8_7ffe073c582fc9392213ce52ba6ba398._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="transitive transfers"
+ date="2022-04-22T16:59:59Z"
+ content="""
+One more use case [here](https://git-annex.branchable.com/forum/Rebuild__47__populate_archive_bypassing___34__here__34___repo/).
+"""]]
diff --git a/doc/todo/transitive_transfers/comment_9_6d5c2697bc985627199e425962f23189._comment b/doc/todo/transitive_transfers/comment_9_6d5c2697bc985627199e425962f23189._comment
new file mode 100644
index 0000000000..a71c0fd3e2
--- /dev/null
+++ b/doc/todo/transitive_transfers/comment_9_6d5c2697bc985627199e425962f23189._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2023-01-23T22:06:32Z"
+ content="""
+`git-annex copy --from foo --to bar` is implemented now (and move too).
+
+But it does need to download a copy of each file in turn, before uploading
+it. Then the local copy can be deleted. Without streaming, that's the best
+that can be done. And I think it's probably good enough for most uses.
+
+So this todo is only about streaming now.
+"""]]
diff --git a/doc/todo/trust_based_on_time_since_last_fsck.mdwn b/doc/todo/trust_based_on_time_since_last_fsck.mdwn
new file mode 100644
index 0000000000..2edee94a59
--- /dev/null
+++ b/doc/todo/trust_based_on_time_since_last_fsck.mdwn
@@ -0,0 +1,5 @@
+It'd be really useful if I could specify my level of trust in a remote holding a file as a function of the time since the file has last been fsck'd in that remote.
+
+This way, if I haven't fsck'd say my off-site cold storage in x amount of time, git-annex would automatically try to create additional copies of its files in other remotes for example.
+
+Expiry can be used in a similar way but declaring the remote as dead is overkill and has unwanted side-effects.
diff --git a/doc/todo/trust_based_on_time_since_last_fsck/comment_1_3805e8dd9e6dd986c097c6f1b78ab244._comment b/doc/todo/trust_based_on_time_since_last_fsck/comment_1_3805e8dd9e6dd986c097c6f1b78ab244._comment
new file mode 100644
index 0000000000..84e1bbf7ec
--- /dev/null
+++ b/doc/todo/trust_based_on_time_since_last_fsck/comment_1_3805e8dd9e6dd986c097c6f1b78ab244._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-06-14T17:14:44Z"
+ content="""
+You can query for repositories that have not been fscked
+for some amount of time:
+
+	git annex expire 10d --no-act --activity=Fsck
+
+From there, it's a simple script to set the unfscked ones to untrusted, or
+whatever.
+
+	| grep '^expire' | awk '{print $2}' | xargs git-annex untrust
+
+I suppose `git-annex expire` could have an option added, like `--untrust`
+to specify *how* to expire, rather than the default of marking the repo
+dead.
+
+I suppose you'd want a way to also go the other way, to stop untrusting a
+repo once it's been fscked.. There is not currently a way to do that.
+
+Note that a fsck that is interrupted does not count as a fsck activity,
+and it's not keeping track of what files were fscked. That would bloat the
+git-annex branch. On the other hand, if you `git annex fsck onefile`
+that counts as a fsck activity, even though other files in the repo didn't get
+fscked. So you would have to limit the ways you use fsck to ones that
+generate the activity you want, perhaps to `git annex fsck --all`. 
+
+Perhaps fsck should also have a way to control whether it records an
+activity or not..
+"""]]
diff --git a/doc/todo/trust_based_on_time_since_last_fsck/comment_2_ec1b87b389dc06440df04c9a719e0cbc._comment b/doc/todo/trust_based_on_time_since_last_fsck/comment_2_ec1b87b389dc06440df04c9a719e0cbc._comment
new file mode 100644
index 0000000000..d410d2f455
--- /dev/null
+++ b/doc/todo/trust_based_on_time_since_last_fsck/comment_2_ec1b87b389dc06440df04c9a719e0cbc._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-06-14T17:29:29Z"
+ content="""
+What if `git annex fsck --all` recorded an additional activity, eg FsckAll.
+Then there could be a command, or a config that untrusts repos that do not
+have a FsckAll activity that happened recently enough.
+
+A git config would be simplest, eg:
+
+	git config annex.untrustLastFscked 10d
+"""]]
diff --git a/doc/todo/trust_based_on_time_since_last_fsck/comment_3_23f37b9d8b877b829e34e6c8ea6b40c4._comment b/doc/todo/trust_based_on_time_since_last_fsck/comment_3_23f37b9d8b877b829e34e6c8ea6b40c4._comment
new file mode 100644
index 0000000000..6f55fbda2f
--- /dev/null
+++ b/doc/todo/trust_based_on_time_since_last_fsck/comment_3_23f37b9d8b877b829e34e6c8ea6b40c4._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-06-14T17:56:23Z"
+ content="""
+Tried to implement this, but ran into a problem adding FsckAll:
+If it only logs FsckAll and not also Fsck, then old git-annex expire
+will see the FsckAll and not understand it, and treats it as no activity,
+so expires. (I did fix git-annex now so an unknown activity is not treated
+as no activity.)
+
+And, the way recordActivity is implemented, it
+removes previous activities, and adds the current activity. So a FsckAll
+followed by a Fsck would remove the FsckAll activity.
+
+That could be fixed, and both be logged, but old git-annex would probably
+not be able to parse the result. And if old git-annex is then used to do a
+fsck, it would log Fsck and remove the previously added FsckAll.
+
+So, it seems this will need to use some log other than activity.log
+to keep track of fsck --all.
+"""]]
diff --git a/doc/todo/trust_based_on_time_since_last_fsck/comment_4_29729772f7600dfb459e3be9cf2c43ea._comment b/doc/todo/trust_based_on_time_since_last_fsck/comment_4_29729772f7600dfb459e3be9cf2c43ea._comment
new file mode 100644
index 0000000000..b2795a163a
--- /dev/null
+++ b/doc/todo/trust_based_on_time_since_last_fsck/comment_4_29729772f7600dfb459e3be9cf2c43ea._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-06-14T18:20:06Z"
+ content="""
+Maybe it's better to not tie this directly in to fsck. Another way
+would be:
+
+	git annex untrust foo --after=100days
+
+The first time this is run, it would record that the trust level will
+change to untrust after 100 days. The next time it's run, it would advance
+the timeout.
+
+So, you could do whatever fsck or other checks make you still trust the
+repo, and then run this again.
+
+Implementation would I guess need a separate future-trust.log in addition
+to trust.log, and when loading trust levels, if there was a value in
+future-trust.log that has a newer timestamp than the value in trust.log,
+and enough time has passed, use it instead of the value from trust.log.
+That way it avoids breaking older git-annex with changes to trust.log.
+
+No need to change what's in trust.log, although it could, which would also
+let older git-annex versions learn about the change to trust.
+"""]]
diff --git a/doc/todo/trust_presence_info_for_specific_remotes_for_specified_time.mdwn b/doc/todo/trust_presence_info_for_specific_remotes_for_specified_time.mdwn
new file mode 100644
index 0000000000..67f11490e7
--- /dev/null
+++ b/doc/todo/trust_presence_info_for_specific_remotes_for_specified_time.mdwn
@@ -0,0 +1,5 @@
+Add config setting `remote.<name>.annex-presence-ttl`, such that the result of `CHECKPRESENT|CHECKPRESENTEXPORT Key` from that remote for that key will be cached locally and reused, with the cache entry invalidated after the specified duration.  The cache can just be the [[location_tracking]] info: if it has been most recently updated within this duration, just assume the key is present without contacting the remote.  Maybe also, on a cache miss update the location tracking info with the more recent timestamp reconfirming the presence.
+
+Then can also extend the [[design/external_special_remote_protocol]] to let a remote send a batch inventory of its contents, which will batch-update the presence info, which will then be valid for the specified time.
+
+Related: [[todo/CHECKPRESENT-MULTI]]; [[design/external_special_remote_protocol/export_and_import_appendix/#index2h2]]; [[trust]].
diff --git a/doc/todo/trust_presence_info_for_specific_remotes_for_specified_time/comment_1_96e12b8ecba4bacfbfa5c58025bedaab._comment b/doc/todo/trust_presence_info_for_specific_remotes_for_specified_time/comment_1_96e12b8ecba4bacfbfa5c58025bedaab._comment
new file mode 100644
index 0000000000..5bcb738a57
--- /dev/null
+++ b/doc/todo/trust_presence_info_for_specific_remotes_for_specified_time/comment_1_96e12b8ecba4bacfbfa5c58025bedaab._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-04-04T18:26:00Z"
+ content="""
+Using location tracking for this seems to trade off the time to contact the
+remote and check presence with bloat of the git repository. This does not
+strike me as a good tradeoff. If I were going to implement this, I suppose
+I'd store the information in sqlite instead.
+
+I'm not clear what the use case or benefit of this would be?
+"""]]
diff --git a/doc/todo/unify_adjust_with_view.mdwn b/doc/todo/unify_adjust_with_view.mdwn
new file mode 100644
index 0000000000..d9e9b46570
--- /dev/null
+++ b/doc/todo/unify_adjust_with_view.mdwn
@@ -0,0 +1,73 @@
+`git annex adjust` and `git annex view` (et all) both derive a branch from
+the main branch and enter it. They have different capabilies. It would be
+useful to be able to compose them. For example, to enter a view based on
+metadata that also has all files unlocked.
+--[[Joey]]
+
+> Now that `git-annex sync` supports view branches, this is more apparently
+> a problem.
+> 
+> It's possible to check out a view branch, and then
+> `git-annex adjust --unlock`, and the result will be a view branch with
+> unlocked files. But then `git-annex sync` doesn't work; it neither syncs
+> back to the parent view branch, nor all the way back to the parent master
+> branch. It seems that git-annex gets confused about what this strangely
+> named branch is (`"adjusted/views/master(author=_)(unlocked)"`),
+> and does not treat it as either kind of branch.
+> 
+> Conversely, first doing `git-annex adjust --unlock`, followed by checking
+> out a view branch from there results in a view branch that does not have
+> the files unlocked. (`"views/adjusted/master(unlocked)(author=_)"`). And
+> syncing fails from there:
+> 
+> fatal: not a valid object name: 'adjusted/master'
+> git-annex: failed to update refs/heads/synced/adjusted/master
+---
+
+There's also probably a fair amount of overlap in their implementations.
+
+> I now think not really so much. View branches are constructed using a
+> temporary index file (and need it), while adjusted branches are able to
+> stream to `git mktree`.
+> 
+> The main overlap is that there is a basis branch that gets transformed 
+> to a new branch. And a way for `git-annex sync` to update the branch when
+> the basis branch (or other info) changes.
+
+----
+
+Consider a branch that is a view branch, where `git-annex adjust --hide-missing`
+was then run. After `git-annex drop`, updating the adjusted branch
+should cause the dropped file to be removed. But removing a file
+from a view branch means removing that metadata from the object.
+
+So, it seems that composing that kind of adjusted branch with
+view branches is unlikely to work.
+
+----
+
+Considering all the the above, I think this would be a good plan:
+
+Implemented adjusted view branches. Not views of adjusted branches.
+Although running `git-annex adjust` with a view branch checked out could
+be one way to get into an adjusted view branch. Or running `git-annex view`
+with an adjusted branch checked out.
+
+Prohibit entering a view branch with the --hide-missing adjustment.
+Update: Actually, I was able to implement support for that adjustment that
+seems to work ok in a view branch.
+
+Building the branch seems simple: Construct the view branch like it does
+now, using the master branch as the basis. And apply the adjustment to each
+file that gets added to it.
+
+It seems it would make sense for an adjusted view branch to 
+have a name like  `"views/adjusted/master(unlocked)(author=_)"` if
+that can be parsed unambiguously. Update: Actually
+`"adjusted/views/master(author=_)(unlocked)"` worked better.
+
+When `git-annex sync` runs in an adjusted view branch, it does not need to
+do the usual adjusted branch propagation at all. Because the only change
+that gets synced from a view branch is changes to metadata.
+
+> [[done]]! --[[Joey]]
diff --git a/doc/todo/union_mounting.mdwn b/doc/todo/union_mounting.mdwn
new file mode 100644
index 0000000000..c42a055021
--- /dev/null
+++ b/doc/todo/union_mounting.mdwn
@@ -0,0 +1,10 @@
+It should be possible to union mount annexes. So if multiple drives have
+content, an annex mounting them both would have available all the 
+content from all the drives.
+
+This could be done by just making .git/annex/KEY link to the actual content
+on the mounted annex.
+
+(Need to make sure the [[copy_tracking|copies]] code does not
+confused and think the symlink is a copy of the content.. Also need to make
+sure that code that writes to .git/annex does not follow symlinks.))
diff --git a/doc/todo/union_mounting/comment_1_cb08435812dd7766de26199c73f38e8b._comment b/doc/todo/union_mounting/comment_1_cb08435812dd7766de26199c73f38e8b._comment
new file mode 100644
index 0000000000..3fadf6fa3c
--- /dev/null
+++ b/doc/todo/union_mounting/comment_1_cb08435812dd7766de26199c73f38e8b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
+ nickname="Michael"
+ subject="comment 1"
+ date="2013-03-01T01:26:36Z"
+ content="""
+This would indeed be very helpful when remotely mounting a photo/video collection over samba.
+"""]]
diff --git a/doc/todo/union_mounting/comment_2_240b1736f6bd4fbf87c372d3a46e661b._comment b/doc/todo/union_mounting/comment_2_240b1736f6bd4fbf87c372d3a46e661b._comment
new file mode 100644
index 0000000000..08901ee178
--- /dev/null
+++ b/doc/todo/union_mounting/comment_2_240b1736f6bd4fbf87c372d3a46e661b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 2"
+ date="2013-03-01T04:50:28Z"
+ content="""
++1 this would be sweet as hell
+
+"""]]
diff --git a/doc/todo/union_mounting/comment_3_cf0a0d4fbd929f24f7056115b2acb7de._comment b/doc/todo/union_mounting/comment_3_cf0a0d4fbd929f24f7056115b2acb7de._comment
new file mode 100644
index 0000000000..ae925adf05
--- /dev/null
+++ b/doc/todo/union_mounting/comment_3_cf0a0d4fbd929f24f7056115b2acb7de._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://ypid.wordpress.com/"
+ nickname="ypid"
+ subject="Please add this ;)"
+ date="2014-03-13T19:10:17Z"
+ content="""
++1 This would be so great. For me the only thing which is missing in this awesome project.
+"""]]
diff --git a/doc/todo/union_mounting/comment_4_2f02fe00a84bf94b7c8e437d8b80293f._comment b/doc/todo/union_mounting/comment_4_2f02fe00a84bf94b7c8e437d8b80293f._comment
new file mode 100644
index 0000000000..009355299d
--- /dev/null
+++ b/doc/todo/union_mounting/comment_4_2f02fe00a84bf94b7c8e437d8b80293f._comment
@@ -0,0 +1,67 @@
+[[!comment format=mdwn
+ username="chkno@50332f55d5ef2f4b7c6bec5253b853a8f2dc770e"
+ nickname="chkno"
+ avatar="http://cdn.libravatar.org/avatar/8194377c81da838dda761a5d93b9c25c"
+ subject="Interim shell script"
+ date="2020-02-04T07:26:10Z"
+ content="""
+Until this feature is available in git annex proper, here is a small shell script that uses [lndir](https://gitlab.freedesktop.org/xorg/util/lndir) to create a merged view of the .git/annex/objects areas of multiple git-annex repositories.
+
+* [union-link-annexes](https://chkno.net/union-link-annexes)
+
+Demo:
+
+    $ git init repo1
+    $ cd repo1
+    $ git annex init repo1
+    $ echo from1 > from1
+    $ echo both > both
+    $ git annex add from1 both
+    $ git commit -m .
+
+    $ cd ..
+    $ git clone repo1 repo2
+    $ cd repo2
+    $ echo from2 > from2
+    $ git annex add from2
+    $ git annex copy --from origin both
+    $ git annex sync
+    $ git annex list
+    here
+    |origin
+    ||
+    XX both
+    _X from1
+    X_ from2
+
+    $ cd ../repo1
+    $ git annex sync
+    $ cd ..
+
+
+    $ union-link-annexes merged repo1 repo2
+
+
+    $ grep . repo1/*
+    repo1/both:both
+    repo1/from1:from1
+    grep: repo1/from2: No such file or directory
+
+    $ grep . repo2/*
+    repo2/both:both
+    grep: repo2/from1: No such file or directory
+    repo2/from2:from2
+
+    $ grep . merged/*
+    merged/both:both
+    merged/from1:from1
+    merged/from2:from2
+
+    $ find merged -not -type d -printf '%p -&gt; %l\n'
+    merged/both -> .git/annex/objects/XV/zk/SHA256E-s5--f6d...
+    merged/from1 -> .git/annex/objects/vf/8W/SHA256E-s6--16e...
+    merged/from2 -> .git/annex/objects/3M/P2/SHA256E-s6--21e...
+    merged/.git/annex/objects/vf/8W/SHA256E-s6--16e... -> ../../../../../../../repo1/.git/annex/objects/vf/8W/SHA256E-s6--16e...
+    merged/.git/annex/objects/XV/zk/SHA256E-s5--f6d... -> ../../../../../../../repo1/.git/annex/objects/XV/zk/SHA256E-s5--f6d...
+    merged/.git/annex/objects/3M/P2/SHA256E-s6--21e... -> ../../../../../../../repo2/.git/annex/objects/3M/P2/SHA256E-s6--21e...
+"""]]
diff --git a/doc/todo/union_mounting/comment_5_58c38383a7ac2df843772960fa10204f._comment b/doc/todo/union_mounting/comment_5_58c38383a7ac2df843772960fa10204f._comment
new file mode 100644
index 0000000000..8f253a793c
--- /dev/null
+++ b/doc/todo/union_mounting/comment_5_58c38383a7ac2df843772960fa10204f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="union mounting and hidemissing"
+ date="2020-02-04T09:01:52Z"
+ content="""
+One easy way to achieve this with git-annex as is would be actual operating-system union mounting. This'll work as long as all (but the lowest / most costly) checkouts [have their missing files hidden](https://git-annex.branchable.com/tips/hiding_missing_files/). Just be sure not to call `git-annex` on the resulting directory (and if there's any danger of it, you might want to consider whiteing out the git configuration in an additional top layer), but only inside one of the supplying repositories.
+"""]]
diff --git a/doc/todo/union_mounting/comment_6_65055977d7c8db3c9c29d90e033e5bb4._comment b/doc/todo/union_mounting/comment_6_65055977d7c8db3c9c29d90e033e5bb4._comment
new file mode 100644
index 0000000000..650808c636
--- /dev/null
+++ b/doc/todo/union_mounting/comment_6_65055977d7c8db3c9c29d90e033e5bb4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="chkno@50332f55d5ef2f4b7c6bec5253b853a8f2dc770e"
+ nickname="chkno"
+ avatar="http://cdn.libravatar.org/avatar/8194377c81da838dda761a5d93b9c25c"
+ subject="Three union-mounting methods that *don't* work"
+ date="2020-02-08T06:21:03Z"
+ content="""
+Linux's in-tree union-mounting option overlayfs [does not support modifications to underlying filesystems while an overlayfs mount is active](https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt):
+
+> Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed.  If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock.
+
+I.e., it's great for the LiveCD case of combining a read-only squashfs and a private tmpfs into something that behaves just like a normal filesystem, but it cannot be used to export a read-only view of multiple mutable resources.
+
+I can report that [aufs](http://aufs.sourceforge.net/) also doesn't work for this use case, at least as of 2014 when I last tried it.  Writes to underlying filesystems cause kernel panics that bring the whole machine down.
+
+I can also report that [hanwen/go-fuse's unionfs](https://github.com/hanwen/go-fuse/blob/master/example/unionfs/main.go) doesn't work for this use case.  Example problem: Growing files' sizes get stuck at the size they were the first time they were viewed through the union mount.
+"""]]
diff --git a/doc/todo/universal_batch_mode.mdwn b/doc/todo/universal_batch_mode.mdwn
new file mode 100644
index 0000000000..37ebc1e88e
--- /dev/null
+++ b/doc/todo/universal_batch_mode.mdwn
@@ -0,0 +1,4 @@
+It would help if there was a universal batch mode, where git-annex command lines are given as lines in an input file, and are executed as a batch.  A batch could contain different git-annex commands (as opposed to different parameters for one command). git-annex could intelligently group, reorder and parallelize the execution, as long as the overall effect of the batch is unchanged.  (I.e. commands affecting different keys/paths could be run in parallel; commands repeatedly doing the same thing could be collapsed; git command batching could span different git-annex commands; etc.)  I find myself implementing something like that in python on top of git-annex, but it would be much more efficient and robust if supported natively.  Maybe, the DataLad project would also find this useful?
+
+[[!tag needsthought]]
+
diff --git a/doc/todo/universal_batch_mode/comment_1_83264867c7f58d92148d1585e4361ee5._comment b/doc/todo/universal_batch_mode/comment_1_83264867c7f58d92148d1585e4361ee5._comment
new file mode 100644
index 0000000000..e56ad0e73b
--- /dev/null
+++ b/doc/todo/universal_batch_mode/comment_1_83264867c7f58d92148d1585e4361ee5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-03-19T17:28:45Z"
+ content="""
+Datalad did request something like this, but IIRC I shot the idea down with
+a good reason. I can't remember why or where we discussed it.. @yoh might.
+"""]]
diff --git a/doc/todo/universal_batch_mode/comment_2_c662c1e2410285e9bf6d01135851fdc8._comment b/doc/todo/universal_batch_mode/comment_2_c662c1e2410285e9bf6d01135851fdc8._comment
new file mode 100644
index 0000000000..3a2f74d274
--- /dev/null
+++ b/doc/todo/universal_batch_mode/comment_2_c662c1e2410285e9bf6d01135851fdc8._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="found it"
+ date="2019-09-20T18:56:52Z"
+ content="""
+see [datalad/issues/139](https://github.com/datalad/datalad/issues/139#issuecomment-97948143). Quoting a part of it:
+
+*But I'd like to investigate adding --batch to individual commands first,
+since this seems more git-like, and also simpler. It would probably be
+helpful to talk about the specific commands you need to call a lot.*
+
+*Things like `git annex lookupkey --batch`, `git-annex readpresentkey --batch`
+etc should be able to be spun up and run as long-duration servers, which
+you could query as needed, not batched up all at once. This is how
+git-annex uses `git cat-file --batch` etc.*
+
+*There's some potential for such a long-running command to either
+buffer stale data so it doesn't answer with the current state of the
+repository, or for it to buffer changes and not commit them to disk
+immediately. For example, a `git annex add --batch` would have the
+latter problem.*
+
+*That is actually an argument for only adding --batch mode to specific
+commands though, since that would be an opportunity to check thier
+behavior. A single `git-annex shell` interface would expose any such
+problems in all commands.*
+"""]]
diff --git a/doc/todo/universal_batch_mode/comment_3_c8232195fa3db718dc2b246d528e6c00._comment b/doc/todo/universal_batch_mode/comment_3_c8232195fa3db718dc2b246d528e6c00._comment
new file mode 100644
index 0000000000..5f694569ab
--- /dev/null
+++ b/doc/todo/universal_batch_mode/comment_3_c8232195fa3db718dc2b246d528e6c00._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-01-06T18:53:02Z"
+ content="""
+Thanks for digging that up.
+
+Hmm, if the goal was to check each command for such problems when adding
+--batch, it didn't stop `git-annex add --batch` from being added, despite
+indeed having such a buffering behavior. You can currently shoot your foot
+combining that with `git annex readpresentkey --batch`, the same way as you
+could with a hypothetical universal batch mode that let you run add
+followed by readpresentkey.
+
+I don't see a universal batch mode being really able to detect
+and avoid such problems either. How is it supposed to know that an add of
+"dir/" will amoung other things add the content of key FOO, which was not
+present before, and so a readpresentkey FOO should be delayed until after
+the add, and the add's buffer flushed. It would have to model the
+behavior of commands and insert barriers/flush points, and the modeling
+could necessarily not be that fine-grained, so it would need to flush
+the add buffer every time before readpresentkey. But there are surely
+ways to combine batch use of add and readpresentkey that you know won't be
+affected by the add buffering, and that would make those unncessarily slow.
+
+Anyway, looking at the implementation of --batch for different commands,
+sometimes it's trivial enough to wish it were generalized, but other times
+there is batch-specific behavior. `add --batch` errors out if --update
+is also used. `checkpresentkey --batch` outputs status codes rather than
+the command's normal behavior of exiting 1/0. So we need batch-specific
+implementations.
+
+---
+
+idea: What might be good is a mode that lets any batch-capable commands
+be combined together, not trying to support every possible command, and
+perhaps with some added commands that the user can use to flush buffers
+etc between operations as desired. Eg:
+
+	git annex batch <<EOF
+	add dir/
+	add whatever
+	flush
+	readpresentkey FOO
+	EOF
+"""]]
diff --git a/doc/todo/unlikely.mdwn b/doc/todo/unlikely.mdwn
new file mode 100644
index 0000000000..74780d1038
--- /dev/null
+++ b/doc/todo/unlikely.mdwn
@@ -0,0 +1,6 @@
+This tags is for todo items that seem unlikely to be implemented, and are
+in danger of being closed as wontfix.
+
+There's generally an objection to the goal of the todo item, or a reason
+it's not feasible to implement, which will need to be addressed to get it
+back on track.
diff --git a/doc/todo/unlock_--json.mdwn b/doc/todo/unlock_--json.mdwn
new file mode 100644
index 0000000000..b6b4d3e4f4
--- /dev/null
+++ b/doc/todo/unlock_--json.mdwn
@@ -0,0 +1,10 @@
+Unlock is quite heavy in terms of I/O and thus waiting time, so we (in datalad) probably should provide also a progress bar indicator.
+
+1. how could I obtain a list of files which would be unlocked given a set of paths?
+
+2. could there be a --json mode of output (consistent with add --json etc)?
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+
+> added --json option [[done]] --[[Joey]]
diff --git a/doc/todo/unlock_--json/comment_1_4cd41dca533de8147027eeb9a8ad89db._comment b/doc/todo/unlock_--json/comment_1_4cd41dca533de8147027eeb9a8ad89db._comment
new file mode 100644
index 0000000000..5a7136a23d
--- /dev/null
+++ b/doc/todo/unlock_--json/comment_1_4cd41dca533de8147027eeb9a8ad89db._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-10-31T18:04:04Z"
+ content="""
+`git annex unlock` only operates on files that are symlinks and link to
+.git/annex/objects.
+I don't think that `find` provides a way to check the link target
+of a symlink, so you'd have to write a program to do it. I suppose
+that `git annex find --locked` could be made to do that.
+
+`git annex unlock` often has to make a copy of the content of a file,
+which would be the majority of its IO. Only if you're using
+`annex.thin` with v6 might it not need to copy the file, and then a batch
+mode could speed it up. Are you?
+"""]]
diff --git a/doc/todo/unlock_--json/comment_2_f00fda45d300ce14a5ea6fd32a20defe._comment b/doc/todo/unlock_--json/comment_2_f00fda45d300ce14a5ea6fd32a20defe._comment
new file mode 100644
index 0000000000..294bbcfea9
--- /dev/null
+++ b/doc/todo/unlock_--json/comment_2_f00fda45d300ce14a5ea6fd32a20defe._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-10-30T18:40:53Z"
+ content="""
+Why was I talking about batch mode here before? --json of course makes
+sense to support for unlock (and lock). Adding that now.
+
+And, to find the files that `git annex unlock` would operate on, you
+can simply use `git annex find`, because that does not list already
+unlocked files, and only files with their content present can be unlocked.
+""]]
diff --git a/doc/todo/unlock_--read-only.mdwn b/doc/todo/unlock_--read-only.mdwn
new file mode 100644
index 0000000000..97fbcabf57
--- /dev/null
+++ b/doc/todo/unlock_--read-only.mdwn
@@ -0,0 +1,8 @@
+"annex unlock" in thin mode of v6 hard-links key into the file location and makes it RW.  This is obviously for the case where modifications to the file need to be done and danger is understood. In my case, I need unlock to avoid having symlinks in the files since some software doesn't digest them well (might copy without dereferencing or dereference and look for neighboring files in the directory), and I want to use unlock to pretty much provide "symlink-free" view of the tree BUT at least with some protection, which could be given if files are unlocked read-only, so no inplace modifications could happen without explicit change of the permissions.
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]
+[[!tag moreinfo]]
+
+> [[closing|done]] because this never got to a concrete proposal that
+> didn't have fatal problems. --[[Joey]]
diff --git a/doc/todo/unlock_--read-only/comment_10_c2a1f402a28c44f842d88747fa3741cc._comment b/doc/todo/unlock_--read-only/comment_10_c2a1f402a28c44f842d88747fa3741cc._comment
new file mode 100644
index 0000000000..cc5f96276d
--- /dev/null
+++ b/doc/todo/unlock_--read-only/comment_10_c2a1f402a28c44f842d88747fa3741cc._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="ct.git-annex@230092d9bd3cf09ced2b9605cdb14ad0a3db265d"
+ nickname="ct.git-annex"
+ avatar="http://cdn.libravatar.org/avatar/271d3b6a528ac0320c7ac9f296ea9b31"
+ subject="comment 10"
+ date="2020-04-26T20:18:48Z"
+ content="""
+joeyh, could you please elaborate what v7/v8 does different to v5 when unlocking? I don't get it.
+
+I need this feature (checked out real/hardlinked files while being immutable) as well. Even if it is only a thin layer of protection it may help. Where supported, git annex may use the file immutable attributes (as discussed in https://git-annex.branchable.com/internals/lockdown/) for better protection.
+
+Imo it's lock/unlock which isn't clear about naming/semantics. We have to things here: 1. symlink vs. direct files  2. protection against mutation.  These 2 things mingle together in the current implementation they are different concepts. We can not choose any free combination of these (writable symlink into the object store makes no sense). But a little finer control would be appreciated. No idea how to do this in a concrete way.
+
+Maybe some 'git annex protect' command to set different protection modes on content (which could be abstract, no need to comply to unix semantics. for example: appendable, writable, immutable, deletable etc. git-annex could enforce the mode lazily if not supported directly)
+
+or 'git annex rolock' (needs better name) .. which is like unlock but makes the file immutable/write protected somehow.
+
+"""]]
diff --git a/doc/todo/unlock_--read-only/comment_11_e8f1576e67d6368eb28aa89c30aaa34c._comment b/doc/todo/unlock_--read-only/comment_11_e8f1576e67d6368eb28aa89c30aaa34c._comment
new file mode 100644
index 0000000000..d952848495
--- /dev/null
+++ b/doc/todo/unlock_--read-only/comment_11_e8f1576e67d6368eb28aa89c30aaa34c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="read-only view of repo clone with symlinks as normal files"
+ date="2021-07-01T17:17:20Z"
+ content="""
+I've used [bindfs](https://bindfs.org/) with `-o ro` and `--resolve-symlinks` to create a read-only view of a repo where symlinks look like regular files.
+"""]]
diff --git a/doc/todo/unlock_--read-only/comment_1_19da9b33836df34b7d747039e6863586._comment b/doc/todo/unlock_--read-only/comment_1_19da9b33836df34b7d747039e6863586._comment
new file mode 100644
index 0000000000..6047827eac
--- /dev/null
+++ b/doc/todo/unlock_--read-only/comment_1_19da9b33836df34b7d747039e6863586._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-10-17T18:09:44Z"
+ content="""
+The protection offered by a read-only mode is pretty minimal; any program
+that writes a file atomically using rename will bypass it. So, as programs
+are implemented better, they'll bypass this "protection" more -- not much of
+a protection!
+
+Also, it doesn't make much sense to call this operation "unlock" if it's
+intended to not let programs modify the files.
+"""]]
diff --git a/doc/todo/unlock_--read-only/comment_2_1658f775ef9340e65711512049085dd7._comment b/doc/todo/unlock_--read-only/comment_2_1658f775ef9340e65711512049085dd7._comment
new file mode 100644
index 0000000000..7047c19075
--- /dev/null
+++ b/doc/todo/unlock_--read-only/comment_2_1658f775ef9340e65711512049085dd7._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-10-17T21:07:31Z"
+ content="""
+Actually, yoh is right: read-only would be sufficient protection here.
+Because, with annex.thin, the worktree file is a hard link to the annex
+object, and the annex object lives in a mode 400 directory. So, even if the
+file is deleted and a new version renamed into place, the annex object will
+still have captured the old version.
+
+Still don't like the self-contradition of "unlock read-only".
+
+Of course, you can do this yourself:
+
+	git annex unlock file
+	chmod 400 file
+
+So I wonder if there's any need for a git-annex command to do this.
+"""]]
diff --git a/doc/todo/unlock_--read-only/comment_3_305c1b867c38edf74cdff1638e5b1cfa._comment b/doc/todo/unlock_--read-only/comment_3_305c1b867c38edf74cdff1638e5b1cfa._comment
new file mode 100644
index 0000000000..f1628d4c89
--- /dev/null
+++ b/doc/todo/unlock_--read-only/comment_3_305c1b867c38edf74cdff1638e5b1cfa._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ avatar="http://cdn.libravatar.org/avatar/8122123b4c2bc77187e32d7e025f7d445d7a08de1ba532237876a31159ac01da"
+ subject="why option vs manual chmod"
+ date="2016-10-17T23:11:10Z"
+ content="""
+as far as I see it
+
+- much easier to specify the option instead of figuring out which files were unlocked and need to be chmodded (some might be under git, etc)
+- probably would be notably (avoiding double file-tree traversal) faster in case of unlocking large number of files
+"""]]
diff --git a/doc/todo/unlock_--read-only/comment_4_515e21cf5c2dfbf9fd780af9cef2e726._comment b/doc/todo/unlock_--read-only/comment_4_515e21cf5c2dfbf9fd780af9cef2e726._comment
new file mode 100644
index 0000000000..50ee172c85
--- /dev/null
+++ b/doc/todo/unlock_--read-only/comment_4_515e21cf5c2dfbf9fd780af9cef2e726._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2019-06-27T14:36:59Z"
+ content="""
+It sounds like you would want to unlock all files in the repo this
+way, is that right?
+
+If so, it seems like a case for `git-annex adjust`, eg 
+`git annex adjust --hardlink`. And it would perhaps make sense to do
+that on a crippled filesystem by default instead of the current default of
+--unlock.
+
+Keeping it in adjust only avoids needing to make the unlock command do
+something that is not an unlocking, and it avoids needing to add a new
+command. 
+
+It also neatly avoids the problem that, while `git annex unlock`
+makes a change that can be committed to git (in v7 mode), this new
+operation is not something that can be committed to git
+(at least w/o some change to indicate it in the pointer file).
+"""]]
diff --git a/doc/todo/unlock_--read-only/comment_5_645bccbcd3499eb552a24563cb613af2._comment b/doc/todo/unlock_--read-only/comment_5_645bccbcd3499eb552a24563cb613af2._comment
new file mode 100644
index 0000000000..06aea71a48
--- /dev/null
+++ b/doc/todo/unlock_--read-only/comment_5_645bccbcd3499eb552a24563cb613af2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="read-only unlock of only some files"
+ date="2019-06-28T15:57:04Z"
+ content="""
+There are still use cases for read-only unlock of just some files.  One issue with symlinks is that Docker doesn't follow them.  So if I want to let Dockerized code read annexed files, I have to unlock them first.  But, if these files are to be only used as input, unlocking them for modification is not really what I want to do.  I don't want `git status` to list these files as modified.
+"""]]
diff --git a/doc/todo/unlock_--read-only/comment_6_eda5475b89536726ec29a831e2748f43._comment b/doc/todo/unlock_--read-only/comment_6_eda5475b89536726ec29a831e2748f43._comment
new file mode 100644
index 0000000000..094b85d2c0
--- /dev/null
+++ b/doc/todo/unlock_--read-only/comment_6_eda5475b89536726ec29a831e2748f43._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="I wonder if &quot;thin mode&quot; could generalize beyond hardlinks"
+ date="2019-07-01T16:19:47Z"
+ content="""
+Was not sure if  I should file a new issue for related discussion, but I thought it might align with the last comment from Ilya, but let me know if it is off-topic too much.
+
+One of the most common \"consumer\" use cases across platforms is just to get the dataset and files to be processed, and then possibly even wipe it all out.  Not all file systems support hard linking or CoW.  I wondered if \"thin\" mode could be something explicit like `hardlink`, or even a new mode -- `mv`.  In `mv` I would see annex just moving the file in its needed location upon `unlock` (and probably marking in `git-annex` branch it to be not present \"here\") (and probably retaining their \"read-only\" for some level of protection? or have `mv` and `mv-rw` modes?).
+
+And then may be if `annex get` would get an option `--unlocked`, then in `thin=mv` mode, annex could take a shortcut and just place the file in a target location right away without even bothering to change any availability information in \"git-annex\" branch?  That would also avoid stressing file systems with consuming all the inodes for `.git/annex/objects` tree in such scenarios.
+
+"""]]
diff --git a/doc/todo/unlock_--read-only/comment_7_3ea1a354bb631539df1ac941e76988e1._comment b/doc/todo/unlock_--read-only/comment_7_3ea1a354bb631539df1ac941e76988e1._comment
new file mode 100644
index 0000000000..276a5bb591
--- /dev/null
+++ b/doc/todo/unlock_--read-only/comment_7_3ea1a354bb631539df1ac941e76988e1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 7"
+ date="2019-07-02T18:36:15Z"
+ content="""
+To \"just to get the dataset and files to be processed, and then possibly even wipe it all out\", maybe you could just use the [[directory special remote|special_remotes/directory]]?
+
+Which common file systems do not support hardlinking?  It seems that [Windows does](https://docs.microsoft.com/en-us/windows/desktop/fileio/hard-links-and-junctions).
+
+To fix the problem that unlocking a file causes `git status` to report it as changed (\"typechange\"), maybe git-annex could [tell git to locally ignore the change](https://dev.to/nishina555/how-to-ignore-files-already-managed-with-git-locally-19oo)?
+
+
+"""]]
diff --git a/doc/todo/unlock_--read-only/comment_8_c39e204047bd9a1999b69a433b22b16d._comment b/doc/todo/unlock_--read-only/comment_8_c39e204047bd9a1999b69a433b22b16d._comment
new file mode 100644
index 0000000000..18735491d2
--- /dev/null
+++ b/doc/todo/unlock_--read-only/comment_8_c39e204047bd9a1999b69a433b22b16d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: I wonder if "thin mode" could generalize beyond hardlinks"""
+ date="2020-01-29T15:15:06Z"
+ content="""
+The ideas in that comment won't work, and here's why: 
+
+If git-annex does not maintain a hardlink in .git/annex/objects,
+then when you run git checkout and it replaces the working tree file
+with some other version, or deletes it, it's deleted the only copy
+of the annex object that is stored on your disk. So you lose data.
+"""]]
diff --git a/doc/todo/unlock_--read-only/comment_9_82a8bfe07d78fc29d306fa5545e866a7._comment b/doc/todo/unlock_--read-only/comment_9_82a8bfe07d78fc29d306fa5545e866a7._comment
new file mode 100644
index 0000000000..694a8faa54
--- /dev/null
+++ b/doc/todo/unlock_--read-only/comment_9_82a8bfe07d78fc29d306fa5545e866a7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2020-01-29T15:18:28Z"
+ content="""
+Much of this discussion seems irrelevant given that v7 is the
+default now and half of the discussion above is about v5 unlock.
+
+In general, this todo suffers from far too many unrelated or only
+tangentially related suggestions.
+
+Any concrete proposals, or shall I close this?
+"""]]
diff --git a/doc/todo/unregisterurl_KEY_URL.mdwn b/doc/todo/unregisterurl_KEY_URL.mdwn
new file mode 100644
index 0000000000..87c8da1bcd
--- /dev/null
+++ b/doc/todo/unregisterurl_KEY_URL.mdwn
@@ -0,0 +1,19 @@
+```
+$> git annex --mumba 2>&1 | grep -e url 
+  addurl          URL ...                   add urls to annex
+  rmurl           FILE URL ...              record file is not available at url
+  registerurl     KEY URL                   registers an url for a key
+
+$> git annex version | head -n 1
+git-annex version: 8.20210223-1~ndall+1
+
+```
+
+So ATM there is addurl/rmurl when operating on a FILE, and there is `registerurl` when operating on a KEY, but there seems to be no way to `unregisterurl` as to `rmurl` from a KEY.  I have not found how could it be possibly done ATM without direct editing of .web files in the git-annex branch.
+
+edit 1: well, instead of adding `unregisterurl` could be done by adding `--key` flag to `rmurl` I think.
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]
+
+> unregisterurl [[done]] --[[Joey]]
diff --git a/doc/todo/unregisterurl_KEY_URL/comment_1_9562b4583203b49ec68162f3a4816ad7._comment b/doc/todo/unregisterurl_KEY_URL/comment_1_9562b4583203b49ec68162f3a4816ad7._comment
new file mode 100644
index 0000000000..26e989a04b
--- /dev/null
+++ b/doc/todo/unregisterurl_KEY_URL/comment_1_9562b4583203b49ec68162f3a4816ad7._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="setpresentkey 0"
+ date="2021-02-25T21:18:48Z"
+ content="""
+Fwiw adding `--key` to `rmurl` sounds nice to me, and, since it looks
+like RmUrl.hs already maps from file to key, I'd guess that be a
+natural addition.
+
+> I have not found how could it be possibly done ATM without direct
+> editing of .web files in the git-annex branch.
+
+I think you could use `setpresentkey`.  So for a plain web URL:
+
+```
+git annex setpresentkey $key 00000000-0000-0000-0000-000000000001 0
+```
+
+"""]]
diff --git a/doc/todo/unregisterurl_KEY_URL/comment_2_87ec9a2037eaa84011f7e7ecf43d31aa._comment b/doc/todo/unregisterurl_KEY_URL/comment_2_87ec9a2037eaa84011f7e7ecf43d31aa._comment
new file mode 100644
index 0000000000..71cce2db4f
--- /dev/null
+++ b/doc/todo/unregisterurl_KEY_URL/comment_2_87ec9a2037eaa84011f7e7ecf43d31aa._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 2"
+ date="2021-02-25T21:25:51Z"
+ content="""
+I said:
+
+> I think you could use setpresentkey.
+
+Never mind, I don't think that's a good idea, since it's not operating
+on a particular URL and adjusting the log.web file.
+"""]]
diff --git a/doc/todo/unregisterurl_KEY_URL/comment_3_22edc4e69a686511c76c7c7608da5793._comment b/doc/todo/unregisterurl_KEY_URL/comment_3_22edc4e69a686511c76c7c7608da5793._comment
new file mode 100644
index 0000000000..bc381ba005
--- /dev/null
+++ b/doc/todo/unregisterurl_KEY_URL/comment_3_22edc4e69a686511c76c7c7608da5793._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2021-03-01T17:39:31Z"
+ content="""
+After using setpresentkey git-annex still has the url
+registered and a later addurl of a new url would make git-annex also
+start trying the old url. Also, if there are several urls, you might only
+want to remove one, not remove it from the web special remote entirely
+as setpresentkey does.
+
+`rmurl --key` would be fine until a batch version was wanted, and then
+something would need to be done about [[todo/git-annex-get_--batch_--key]].
+Which would be good to solve generally somehow, but otoh, `git-annex
+unregisterurl` neatly avoids that more general problem. Also, it makes
+sense that a registerurl user would look for a dual command like
+unregisterurl before looking in rmurl for a way to do it.
+
+So I think unregisterurl is the right thing to add.
+"""]]
diff --git a/doc/todo/upload_large_chunks_without_buffering_in_memory.mdwn b/doc/todo/upload_large_chunks_without_buffering_in_memory.mdwn
new file mode 100644
index 0000000000..2c5c96c1f6
--- /dev/null
+++ b/doc/todo/upload_large_chunks_without_buffering_in_memory.mdwn
@@ -0,0 +1,26 @@
+Currently, when chunk=100MiB is used with a special remote, git-annex will
+use 100 mb ram when uploading a large file to it. The current chunk is
+buffered in ram.
+
+See comment in Remote.Helper.Chunked:
+
+	- More optimal versions of this can be written, that rely
+	- on L.toChunks to split the lazy bytestring into chunks (typically
+	- smaller than the ChunkSize), and eg, write those chunks to a Handle.
+	- But this is the best that can be done with the storer interface that
+	- writes a whole L.ByteString at a time.
+
+The buffering is probably fine for smaller chunks, in the < 10 mb or
+whatever range. Reading such a chunk from gpg and converting it into a http
+request will generally need to buffer it all in memory anyway. But, for
+eg external special remotes, the content is going to be written to a file
+anyway, so there's no point in buffering the content in memory first.
+
+So, need something like:
+
+	prefersFileContent :: Storer -> Bool
+
+And then when storeChunks is given such a Storer, it can then avoid buffering
+and write chunk data to a temp file to pass it to the Storer.
+
+--[[Joey]]
diff --git a/doc/todo/use_git-mktree_rather_than_index_file.mdwn b/doc/todo/use_git-mktree_rather_than_index_file.mdwn
new file mode 100644
index 0000000000..f02fafb08a
--- /dev/null
+++ b/doc/todo/use_git-mktree_rather_than_index_file.mdwn
@@ -0,0 +1,29 @@
+When git-annex is updating the git-annex branch, it currently
+uses a separate index file. This adds overhead and complexity to the code.
+Especially when there are many files, the index file gets large and writing
+it gets slow.
+
+It might be an improvement to use `git mktree --batch` to inject a
+tree object into git, without using the index file. `git hash-object`
+is already used to add the files to git. All that would be needed is to
+generate an updated tree containing the new file(s), and then update each
+parent tree up to the root tree. This new tree can then be committed using
+`git commit-tree`
+
+The only thing I can see that might make this slow at all is reading the old
+tree contents, in order to update it. This would need a `git ls-tree` for
+each tree; it does not have a batch mode, so 4 processes would need to be
+spawned when generating a tree that changes 1 file. For any repo that's not
+very small, that's probably still faster than rewriting the index file.
+
+Notes:
+
+* The union merge code currently uses the index. No particular reason
+  it needs to; that's just how the code is written, and it might be a large
+  rewrite to change it.
+* A new git-annex branch can be pushed into the repository at any time.
+  The current code uses the index to detect when this happens, and
+  union merges the new branch head into the index. Would need something
+  like a `GIT_ANNEX_HEAD` ref to do the same if the index is removed.
+
+Thanks to sm for indirectly suggesting this. --[[Joey]] 
diff --git a/doc/todo/use_systemd_credential_system_for_git-annex_credentials.mdwn b/doc/todo/use_systemd_credential_system_for_git-annex_credentials.mdwn
new file mode 100644
index 0000000000..3a69bfcff9
--- /dev/null
+++ b/doc/todo/use_systemd_credential_system_for_git-annex_credentials.mdwn
@@ -0,0 +1,15 @@
+systemd v256 will have support for credentials that are encrypted at rest,
+locked against the system's TPM, and can be used by a per-user service
+(prior versions only supported it for system services).
+
+<https://mastodon.social/@pid_eins/112336318532407967>
+
+This is a much more secure way to store credentials than git-annex's
+current `.git/annex/creds/` which is only protected by unix permissions,
+and so it would make sense for git-annex to use it.
+It would need a way for git-annex to start a systemd user service when
+it needs access to a credential.
+
+Note that GNOME/XDG desktop secret managers have work underway to support
+this systemd feature, so git-annex might be able to alternatively use them
+to access creds rather than using a systemd unit directly. --[[Joey]]
diff --git a/doc/todo/using_file_metadata_for_preferred___40__wanted__41___content.mdwn b/doc/todo/using_file_metadata_for_preferred___40__wanted__41___content.mdwn
new file mode 100644
index 0000000000..d9226d21f8
--- /dev/null
+++ b/doc/todo/using_file_metadata_for_preferred___40__wanted__41___content.mdwn
@@ -0,0 +1,12 @@
+Having the option of choosing for every file if we want it in our repository or not would be a great feature. It is currently possible using the wanted expression, but it is not very flexible, or it becomes unmaintainable.
+
+I tried with two repositories a and b, with the following wanted expressions :
+
+* for a: `not metadata=unwanted=<uuid-of-a>`
+* for b: `not metadata=unwanted=<uuid-of-b>`
+
+I think those expressions should be included in standard wanted expressions.
+
+Also, to improbe the feature, it should be possible to set (or remove) metadata in directories, and those should automatically affect their content.
+
+And we could imagine a `git annex unwant` command that would add the unwanted metadata to a file, copy it to other repositories, and attempt to drop it.
diff --git a/doc/todo/using_file_metadata_for_preferred___40__wanted__41___content/comment_1_8c377382b772e4c2d0c1f981010b8d91._comment b/doc/todo/using_file_metadata_for_preferred___40__wanted__41___content/comment_1_8c377382b772e4c2d0c1f981010b8d91._comment
new file mode 100644
index 0000000000..02a7cfec42
--- /dev/null
+++ b/doc/todo/using_file_metadata_for_preferred___40__wanted__41___content/comment_1_8c377382b772e4c2d0c1f981010b8d91._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="wanted content commands"
+ date="2019-10-10T08:16:59Z"
+ content="""
+I've often thought it would be handy to have a preferred content expression and a requested files list that work together. Which is, I think, similar to what you're saying?
+
+So you could do something like \"git annex wanted . --request <somefile>\" which would add it to a list of wanted files, that overrides the preferred content. Then you'd remove them also.
+
+Use case for this would be requesting a file. Syncing the request to, say, a usb. Plugging that usb in somewhere else later, and having those files be automatically transferred. Then when the file reaches the destination it's dropped.
+
+I guess this is possible already with the wanted expressions? What would that look like?
+
+
+"""]]
diff --git a/doc/todo/v11_changes.mdwn b/doc/todo/v11_changes.mdwn
new file mode 100644
index 0000000000..79f5647d1b
--- /dev/null
+++ b/doc/todo/v11_changes.mdwn
@@ -0,0 +1,30 @@
+This is a todo for collecting changes that could lead to a v11 repository
+version.
+
+* Append to journal files even when annex.alwayscompact=true.
+  This can make it a lot faster in some cases.
+  See note in Annex.Branch.changeOrAppend.
+
+  It's important that this only happen when no git-annex version
+  older than 10.20220724 can plausibly be running in a repository
+  after upgrading to the repo version that enables this. Depending on the
+  timing of v11, this may need to be put in a v12 upgrade that is delayed
+  some amount of time (eg 1 year) after v11.
+
+* Avoid locking old transfer lock file. transferFileAndLockFile
+  currently returns two lock files for Download transfers,
+  and locking both of them is unncessary work, which is only needed to
+  interoperate with old git-annex versions that only lock the old lock file
+  and not the new one.
+
+  See [[!commit f04d9574d6a56cfdf034a974f9714f0a3b8c49fa]].
+
+  (Note that the old lock file should still be deleted when cleaning up the
+  new lock file, to make sure that all the old lock files get deleted.)
+
+  It would not be great if this change were made when a git-annex version
+  10.20240227 or older was running in the repository. But it wouldn't be
+  the end of the world either, because the effect would be effectively
+  the same as the bug that the second transfer lock was added to fix.
+  Still, it would make sense to put this in a v12 upgrade that is delayed
+  some amount of time (eg 1 year) after v11.
diff --git a/doc/todo/v9_changes.mdwn b/doc/todo/v9_changes.mdwn
new file mode 100644
index 0000000000..4b242359f1
--- /dev/null
+++ b/doc/todo/v9_changes.mdwn
@@ -0,0 +1,22 @@
+This is a todo for collecting changes that could lead to a v9 repository
+version.
+
+Currently, there does not seem to be enough reason to warrant one, but that
+could change and if it does, these things could be included.
+
+* Change locking of annexed files to use a separate lock file
+  rather than posix locking the file itself.
+
+  This would let write bits be removed from the file when
+  core.sharedRepository is set. See <https://git-annex.branchable.com/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/>
+
+  Note that windows already uses a separate lock file.
+
+  This is being implemented in git branch `v9-locking`.
+
+* Possibly enable `git-annex filter-process` by default. If the tradeoffs
+  seem worth it.
+
+  May want to implement [[incremental_hashing_for_add]] first.
+
+[[done]] --[[Joey]]
diff --git a/doc/todo/verified_relaxed_urls.mdwn b/doc/todo/verified_relaxed_urls.mdwn
new file mode 100644
index 0000000000..98881a8f13
--- /dev/null
+++ b/doc/todo/verified_relaxed_urls.mdwn
@@ -0,0 +1,127 @@
+Adding a relaxed url currently prevents verifying the content of the object
+when transferring it between repositories. This risks data corruption going
+unnoticed. Could the hash be recorded when a relaxed url is downloaded from
+the web, and then used for verification of other transfers?
+
+This would need a new per-key file in the git-annex branch, that can list
+one or more hash-based keys. Then implement verification for url keys, that
+checks if hash-based keys are recorded in the file, and if so uses them to
+verify the content.
+
+The web special remote can hash the content as it's downloading it from the
+web, and record the resulting hash-based key.
+
+> [[done]] --[[Joey]]
+
+## handling upgrades
+
+A repository that currently contains the content of a relaxed url needs to
+keep working. So, the object stored in the repository has to be treated as
+valid, even though it does not correspond to any hash-based keys listed for
+the url key. 
+
+This presents a problem; there is no way to tell the difference between
+a valid object in such a repository and an object that was downloaded from
+the web with its hash recorded, but has since gotten corrupted.
+
+Seems that the only possible way to resolve this problem is to change to a
+new type of url key, that is known to always have its hash recorded on
+download from the web. (Call this a verifiable url key: a VURL.)
+And handle all existing relaxed url keys as before.
+
+That would leave it up to the user to migrate their URL keys to
+VURL keys, if desired. Now that distributed migration is
+implemented, that seems sufficiently easy.
+
+See [[migration_to_VURL_by_default]]
+
+## addurl --fast 
+
+Using addurl --fast rather than --relaxed records the size but doesn't
+hash. So it has the same problem that data corruption can go unnoticed,
+only the data corruption has to involve bit flips and not truncation.
+
+So it seems that --fast ought to also be handled. The difference being that
+an url added with --fast is expected to always be the same on re-download
+from the web, while an url added with --relaxed may change its content on
+re-download from the web while being still considered the same object.
+
+This can also use a VURL key, but include the size in it. When downloading
+a sized VURL, the web special remote will hash the content, and verify
+that either no hash has been recorded before (and record the hash when the
+size matches), or that it matches the previously recorded hash.
+
+Note that, if an url is added with --fast and that gets committed and
+pulled by another repo, and then later both repos download the content
+from the web, it would be possible for the web to serve up different
+content to the two, and in that case either hash would be treated as
+valid.
+
+## other special remotes
+
+If the web special remote is what takes care of hashing the content on
+download and recording the hash-based key, what about other special remotes
+that claim an url?
+
+This could also be implemented in the bittorrent special remote
+(though ), but what
+about external special remotes?
+
+An alternative would be to add a downloadVerifiedUrl that is called instead
+of retrieveKeyFile and returns a hash-based key (allowing hashing the
+download on the fly). Then git-annex would take
+care of recording the hash-based key. The external special remote interface
+could be extended to include that.
+
+> For now, gonna punt on this. It would be possible to support other
+> special remotes later, but implemented it in the web special remote only
+> for now. When using `git-annex addurl --verified` with others, it creates
+> a VURL, but never generates a hash key, so the VURL works just like an
+> URL key.
+
+## hash-based key choice
+
+Should annex.backend gitconfig be used to pick which hash-based key to use?
+The risk is that config changes and several different hash-based keys get
+recorded for a VURL. Not really a problem, but would increase the
+size of the git-annex branch unncessarily, and require extra work when
+verifying the key.)
+
+> It will let annex.backend gitconfig and --backend be used,
+> but it didn't seem worth supporting annex.backend gitattribute, or really
+> even appropriate to since this is not really related to any particular
+> work tree file. --[[Joey]]
+
+What if annex.backend uses WORM or something that is not hash-based?
+Seems it ought to fall back to SHA256 or something then.
+
+To support annex.securehashesonly it would be good if only
+cryptographically secure hashes were recorded for a VURL. But of course,
+which hashes are considered secure can change. Still, let's start by
+only allowing currently secure hashes to be used for VURLs. This way,
+when there are multiple hashes recorded for a VURL, they will all be
+cryptographically secure normally, and so the VURL can be considered
+cryptographically secure itself. If any of the hashes later becomes
+broken, the VURL will no longer be treated as cryptographically secure,
+because the broken hash can be used to verify its content.
+In that case, the user would probably just migrate to a hash-based key,
+although perhaps something VURL-specific could be built to upgrade its
+hashes.
+
+## use for other types of keys
+
+It would also be possible to use these new git-annex branch log files
+for other types of keys, like WORM, or perhaps SHA1. But, the same upgrade
+problem would apply. So, there's problably no benefit in doing that,
+compared with migrating the key to the desired hash backend.
+
+Does seem to be some chance this could help implementing 
+[[wishlist_degraded_files]].
+
+## security
+
+There is the potential for a loop, where a VURL has recorded an equivilant
+key what is the same VURL, or another VURL in a loop. Leading to a crafted
+git-annex branch that DOSes git-annex.
+
+To avoid this, any VURL in equivilant keys will be ignored.
diff --git a/doc/todo/warn_of_breaking_changes_same_way_git_does.mdwn b/doc/todo/warn_of_breaking_changes_same_way_git_does.mdwn
new file mode 100644
index 0000000000..762a79ab60
--- /dev/null
+++ b/doc/todo/warn_of_breaking_changes_same_way_git_does.mdwn
@@ -0,0 +1,31 @@
+When git introduces a breaking change, it prints a warning describing the change and saying "to turn off this warning set advice.warnaboutthis=false".  This adds the hassle of setting the config (once, globally), but the reduced confusion might be worth it.
+
+git also uses this mechanism to start warning of upcoming breaking changes in future versions, before these versions become current.
+
+Another way to signal breaking changes can be to use some form of [semantic versioning](https://semver.org/) for git-annex versions, bumping the major version number to indicate incompatible changes.  [[7.20190912|news/version_7.20190912]] would then be 8.20190912 .  This would help when specifying [package dependencies](https://docs.conda.io/projects/conda-build/en/latest/resources/package-spec.html#package-match-specifications).
+
+Of course, best is to avoid breaking changes, as @joeyh ultimately [[managed to do with v7|news/version_7.20191024]].  But they'll happen, and some people miss the [[current scheme for announcing them|forum/lets_discuss_git_add_behavior/#comment-727918fd9abda5445891f2022ac225c8]], so low-cost ways to extend the scheme might help.
+
+> This todo item was prompted by the `git add` behavior
+> change. But that was caused by an automatic upgrade to repo version 7,
+> not by any particular recent version of git-annex. It was actually
+> implemented in 2016 or something like that and repo versions v6 (and v7)
+> always had that behavior. Warning about it back then would not have helped
+> with people who encountered the change in behavior in 2019.
+> And, before a user upgraded to v6/v7, `git add` did not run git-annex, so
+> there is no way that git-annex could have made `git add` warn about a
+> upcoming behavior change.
+> 
+> The major version number of git-annex indicates what repository version
+> number it supports. 8.20190912 would not support v8 repositories, so
+> that's not the right version number for it.
+> 
+> Intentional changes to git-annex behavior have been very scant if you
+> look back over the changelog. If I were making one today, I'd maybe think
+> about warning first for a while. But that also slows down the development
+> velocity if something is dependent on that behavior change, since you
+> then have to wait some period of time for users to see the warning.
+> 
+> Anyway, I don't see any point leaving a todo item open about a
+> hypothetical future change, and I'm not willing to commit to always doing
+> it, so [[done]] I guess? --[[Joey]]
diff --git a/doc/todo/way_to_instruct_on_how_to_decide_on_extension__63__.mdwn b/doc/todo/way_to_instruct_on_how_to_decide_on_extension__63__.mdwn
new file mode 100644
index 0000000000..1c2e8dfd93
--- /dev/null
+++ b/doc/todo/way_to_instruct_on_how_to_decide_on_extension__63__.mdwn
@@ -0,0 +1,16 @@
+In our case we are storing videos using timestamp in the filename, e.g.
+
+```
+2024.03.08.09.31.09.041_2024.03.08.09.34.53.759.mkv
+```
+
+where last number is `ms`.  `git-annex` for MD5E decides that extension is `.759.mkv`, so if we rename file (adjust timing), it seems to produce a new key.
+
+I wonder if you have any ideas Joey on how to overcome it (smarter extension deduction? some config to "hardcode" target extension to be .mkv?)?
+
+Just throwing against the wall to see if sticks
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]
+
+> added annex.maxextensions config, [[done]] --[[Joey]]
diff --git a/doc/todo/way_to_instruct_on_how_to_decide_on_extension__63__/comment_1_b3e9fcb09b6455301a5f7a9bf50a8a49._comment b/doc/todo/way_to_instruct_on_how_to_decide_on_extension__63__/comment_1_b3e9fcb09b6455301a5f7a9bf50a8a49._comment
new file mode 100644
index 0000000000..1bc0b84b5d
--- /dev/null
+++ b/doc/todo/way_to_instruct_on_how_to_decide_on_extension__63__/comment_1_b3e9fcb09b6455301a5f7a9bf50a8a49._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-04-18T17:39:52Z"
+ content="""
+Of course, choosing a backend that does not include extension is something
+worth considering. Unless something needs the object file to preserve the
+extension. For a .mkv file, I'd guess most video players don't care about
+the extension.
+
+annex.maxextensionlength won't help here, but I think it makes sense to add
+an analagous annex.maxextensions which would default to 2 (as it
+currently does to handle .tar.gz) but you could set to 1.
+
+It might also be a reasonable argument that filename extensions are not
+just numbers, but then again, foo.1.pdf foo.2.pdf is a pretty common kind
+of pattern, although the extent that the numbers in that are extensions
+with any meaning to a program would depend. Some archivers do eg split
+files into foo.1 foo.2 foo.3 and use the extensions to get them back.
+Anyway, the same kind of problem could happen when not using only
+numbers.
+"""]]
diff --git a/doc/todo/way_to_untrust_without_unncessary_branch_update.mdwn b/doc/todo/way_to_untrust_without_unncessary_branch_update.mdwn
new file mode 100644
index 0000000000..04d9e28af4
--- /dev/null
+++ b/doc/todo/way_to_untrust_without_unncessary_branch_update.mdwn
@@ -0,0 +1,15 @@
+Currently running `git annex untrust` on a remote that is already untrusted
+will still update the git-annex branch. And that should not change, because
+one use case is overriding a change made elsewhere, in a semi-split brain
+situation, and so indication it's still untrusted is useful.
+
+But, if a program, or even an external special remote wants to untrust
+itself, it currently needs to parse `git annex info` to see if it's
+currently untrusted, and only run untrust if not, otherwise each time it
+runs it will pile up a change in the git-annex branch.
+
+So, suggest a flag to avoid generally unnecessary branch update.
+It would also make sense to add it to the other trust level commands,
+and possibly other config setting commands. --[[Joey]]
+
+[[!tag needsthought]]
diff --git a/doc/todo/webapp__58___show_times_of_events.mdwn b/doc/todo/webapp__58___show_times_of_events.mdwn
new file mode 100644
index 0000000000..b58e52e9d4
--- /dev/null
+++ b/doc/todo/webapp__58___show_times_of_events.mdwn
@@ -0,0 +1,5 @@
+In the webapp 'dashboard' page there is a column of 'message boxes' on the right hand side that appear as events occur.
+
+I would find it helpful to be able to hover over a message box and have a timestamp appear so that I know whether the event is a recent one that I might need to go look in the log for more detail about, or that I can click on the 'X' to dismiss the message.
+
+A further improvement that occurred to me is adding a link within the message box (link text something like "view log entry") that takes you to the corresponding part of the 'view log' page.
diff --git a/doc/todo/webapp_export_remote_configuration_interface.mdwn b/doc/todo/webapp_export_remote_configuration_interface.mdwn
new file mode 100644
index 0000000000..1ab60d875d
--- /dev/null
+++ b/doc/todo/webapp_export_remote_configuration_interface.mdwn
@@ -0,0 +1,12 @@
+Support configuring export remotes in the webapp
+
+Remember the little-used preferreddir= preferred content
+setting and the "public" repository group. The webapp uses
+those for IA, which could be replaced with setting up an export
+tracking branch.
+
+The UI for S3, WebDAV, directory special remote setup could also have a way
+to make it an export, and configure the directory to export. This would
+complicate the UI, so needs thought. --[[Joey]]
+
+[[!tag needsthought]]
diff --git a/doc/todo/webapp_nudge_when_less_than_numcopies_clones.mdwn b/doc/todo/webapp_nudge_when_less_than_numcopies_clones.mdwn
new file mode 100644
index 0000000000..ee38d0fffb
--- /dev/null
+++ b/doc/todo/webapp_nudge_when_less_than_numcopies_clones.mdwn
@@ -0,0 +1,7 @@
+Currently, nothing stops a user from setting up ~/annex, adding some special remote, and never once ending up with a clone of their repository, so there is really no backup of the repository as a whole, despite the special remotes.
+
+Potentially adding to the confusion, they might have remotes in repository groups "full backup" or "backup", and so think everything is backed up.
+
+Webapp could count the number of known remote uuids that are not special remotes, and require there to be at least numcopies of them (excluding the current repo I suppose), and pop up a nudge with a button that presents the various available ways to make a non-special remote.
+
+Working out if a remote uuid is a special remote is probably the hard bit. A special remote will be listed in uuid.log, with a type other than gcrypt or git. Any other uuid, that is not dead, can count as 1 clone. This does not handle git remotes that are not using git-annex (eg github), so it could also look through the git remote list and count any that don't have an annex-uuid.
diff --git a/doc/todo/webapp_ssh_setup_should_work_with_locked_down_git-annex-shell_account.mdwn b/doc/todo/webapp_ssh_setup_should_work_with_locked_down_git-annex-shell_account.mdwn
new file mode 100644
index 0000000000..d91bd4be5a
--- /dev/null
+++ b/doc/todo/webapp_ssh_setup_should_work_with_locked_down_git-annex-shell_account.mdwn
@@ -0,0 +1,7 @@
+When the webapp is used to set up a ssh repository, it should detect if
+there is already a repository, and sshing in to the server forces running
+git-annex-shell (perhaps by it being set to the user's login shell). 
+
+In this case it should just use the already set up repository. Note that
+it would not be possible to add a new repository on the server using only
+git-annex-shell. --[[Joey]]
diff --git a/doc/todo/wherewas.mdwn b/doc/todo/wherewas.mdwn
new file mode 100644
index 0000000000..4061af5c98
--- /dev/null
+++ b/doc/todo/wherewas.mdwn
@@ -0,0 +1,29 @@
+Repo that contains the latest/current version of a file is not accessible.
+Can git annex whereis find the last available version of a file in other
+repos (or a specific repo)?
+
+I can looping through commit log and running whereis for each commit until
+an earlier version of a file is found, but perhaps there is a better way to
+do it with a single command?
+
+> Not currently, but I think it would be a useful command to have available
+> without scripting.
+> 
+> So the use case seems to be that the most recent version of a file is not
+> accessible currently, but you want to access some version of the file,
+> and will settle for an older version.
+> 
+> One interface could be:
+> 
+>   git-annex findversion thefile --in=foo
+> 
+> Which would look at past versions of thefile that are present in remote
+> foo, and output something like "master@{10}", or just a bare
+> git commit sha. Which you can `git checkout`
+> and then `git-annex get thefile --from=foo` will work to access the
+> content.
+> 
+> One problem with this interface is it would need to be limited to a
+> single file, because there may be no commit that has the latest
+> versions of several files that are all in the specified remote.
+> --[[Joey]]
diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE.mdwn b/doc/todo/whishlist__58___GPG_alternatives_like_AGE.mdwn
new file mode 100644
index 0000000000..ccad035141
--- /dev/null
+++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE.mdwn
@@ -0,0 +1,8 @@
+GA uses GPG for encryption but it's neither fast, user friendly or particularly secure (C software from the 90s with huge legacy debt...).
+
+It'd be really nice if you could use a faster, simpler/leaner, modern and reasonably secure piece of software instead for encryption in GA.
+
+I'm not too deep into this but https://github.com/FiloSottile/age looks like an ideal replacement for what GA currently needs GPG for:  
+It's fast (encrypts `/dev/zero` at 1.4GiB/s on my machine), modern, simple and designed to integrate well with other tools via the command line. Its creator is the Golang security lead, so the crypto is probably good too ;)
+
+Age seems to be closing in on its "production-ready" 1.0.0 release, so it might be worth having a look at now.
diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_1_92a7d08946a3ed95d0f0413e6c6208ae._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_1_92a7d08946a3ed95d0f0413e6c6208ae._comment
new file mode 100644
index 0000000000..bad191d246
--- /dev/null
+++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_1_92a7d08946a3ed95d0f0413e6c6208ae._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 1"
+ date="2021-09-22T14:17:59Z"
+ content="""
+age v1.0.0 has been released: https://github.com/FiloSottile/age/releases/tag/v1.0.0
+"""]]
diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_2_18ae790f59a9dbeda745e6f6f45384cb._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_2_18ae790f59a9dbeda745e6f6f45384cb._comment
new file mode 100644
index 0000000000..a3a92baa37
--- /dev/null
+++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_2_18ae790f59a9dbeda745e6f6f45384cb._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-10-15T16:45:46Z"
+ content="""
+Mostly people pick on gpg's public key crypto implementation, and mostly
+I think, because public key crypto is easy to pick at. I have not seen
+many such arguments about gpg that seem very convincing to me.
+I see that AGE also implements public key crypto.
+
+The way git-annex uses gpg for encryption=shared does not involve public
+key crypto at all, but uses AES-128, which is about as close as there is
+to a standard for encrypting things. (If you prefer AES-256, gpg can be
+configured to use that instead.)
+
+git-annex already links to an AES implementation for other purposes
+and could probably bypass gpg and use that, but that smells of implementing
+your own crypto. (AES ECB penguin comes to mind.) 
+AGE does not seem to expose any non-public key encryption, 
+so it could not be used for encryption=shared, I think. (Unless perhaps
+the public/private key pair were stored in the repo as the shared
+cipher?)
+
+While encryption=hybrid uses public key crypto, it's only for encrypting
+a cipher file, which then gets used as an AES key. So if encryption=shared
+can't be done with AGE, encryption=hybrid can't either.
+
+That leaves encryption=pubkey and encryption=sharedpubkey, which I
+suppose could have variants implemented using AGE.
+
+I don't like the idea of git-annex supporting more than 2 encryption
+programs, and even 2 seems like 1 too many. Every one will be an ongoing
+cost. It's not clear to me that there's enough of a benefit to support AGE,
+or that it would be the best choice for a +1.
+"""]]
diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_3_09b89df28a3a3dab2f0fbf2f56feafe1._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_3_09b89df28a3a3dab2f0fbf2f56feafe1._comment
new file mode 100644
index 0000000000..e6946ee5f6
--- /dev/null
+++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_3_09b89df28a3a3dab2f0fbf2f56feafe1._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 3"
+ date="2021-10-19T13:05:50Z"
+ content="""
+> Mostly people pick on gpg's public key crypto implementation, and mostly I think, because public key crypto is easy to pick at. I have not seen many such arguments about gpg that seem very convincing to me.
+
+Ah, this is not about the underlying algorithms and theories. Those are more than sufficient in our pre-quantum world and, as you said, AGE isn't fundamentally different here.
+
+What I'm mostly concerned about is the quality of the implementation; especially the non-functional aspects like speed, UI and simplicity (some of which also have security implications).
+
+> The way git-annex uses gpg for encryption=shared does not involve public key crypto at all, but uses AES-128, which is about as close as there is to a standard for encrypting things.
+
+The actual encryption is done symmetrically but the encryption of the symmetric key is done asymmetrically if I'm not mistaken.
+
+This is not what age aims to replace though, it functions the exact same from a high level AFAIK; just with a different implementation that satisfies different goals from GPG.
+
+> git-annex already links to an AES implementation for other purposes and could probably bypass gpg and use that, but that smells of implementing your own crypto.
+
+That definitely smells of homebrewed crypto. This is why I would love to see something like age used: It's a pre-made, (supposedly) secure, standardised crypto system/library that you can feed files into and it simply gives you encrypted files back. No faffing about with complex key setups or other brilliant UX anno 1999.
+
+> AGE does not seem to expose any non-public key encryption, so it could not be used for encryption=shared, I think. (Unless perhaps the public/private key pair were stored in the repo as the shared cipher?)
+
+I'm not sure I follow, couldn't you just generate an age keypair and simply store that in the repo?
+
+Does the current gpg-based implementation not do it just like that?
+
+> I don't like the idea of git-annex supporting more than 2 encryption programs, and even 2 seems like 1 too many. Every one will be an ongoing cost. It's not clear to me that there's enough of a benefit to support AGE, or that it would be the best choice for a +1.
+
+Me neither and I understand your point but the problem with that approach is that it leaves absolutely no way to migrate away from GPG.
+
+GPG is a complex beast that will likely need replacement within the next decade and age seems like the most obvious alternative for use-cases like git-annex.  
+Only time can tell whether it actually becomes the new file encryption standard but it seems like the most likely candidate right now.
+
+"""]]
diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_4_b9de19ba8382225ac8c65ee1ad8110a8._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_4_b9de19ba8382225ac8c65ee1ad8110a8._comment
new file mode 100644
index 0000000000..3bb4de0e27
--- /dev/null
+++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_4_b9de19ba8382225ac8c65ee1ad8110a8._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2021-10-19T13:58:24Z"
+ content="""
+Sequoia-PGP could be another contender (OpenPGP in rust). There is a sq
+command line interface that is equivilant to gpg.
+
+It should be able to decrypt objects in repositories encrypted using gpg.
+If that works well, git-annex could support it in parallel with gpg for
+some time, then deprecate the gpg support and eventually remove it. This is
+a more appealing path than supporting multiple encryption tools
+indefinitely.
+
+This issue is a pre-requisite for using sq, although presumably the
+low-level library could be used directly to avoid the issue.
+<https://gitlab.com/sequoia-pgp/sequoia/-/issues/766>
+"""]]
diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_5_c81d61a221fd93eb25765998b67bbde7._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_5_c81d61a221fd93eb25765998b67bbde7._comment
new file mode 100644
index 0000000000..d3aee173b4
--- /dev/null
+++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_5_c81d61a221fd93eb25765998b67bbde7._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-10-19T16:33:01Z"
+ content="""
+> I'm not sure I follow, couldn't you just generate an age keypair and simply store that in the repo?
+> 
+> Does the current gpg-based implementation not do it just like that?
+
+No, it uses gpg --symmetric which is much simpler and also likely more
+secure.
+
+As far as gpg's UI complexity, it's a problem to some extent (although every
+one of those options presumably has a user), but notice that a git-annex user
+who uses encryption=shared never has to touch gpg's interface at all.
+This is by design. It's only with encryption=hybrid and pubkey that the user
+is exposed to  the complexities of public key crypto, and I expect that mostly
+users who already are familiar with that and need the inherent complexity of it
+will use those.
+
+> age seems like the most obvious alternative for use-cases like
+> git-annex. Only time can tell whether it actually becomes the new file encryption
+> standard but it seems like the most likely candidate right now.
+
+I don't follow this reasoning; the openpgp standard is a well-established
+standard with many implementations, and so it seems likely that an implementation
+of that standard will be what replaces gpg, if anything.
+
+(It also is possible that gpg eventually ends up being reimplemented using
+something like Sequoia-PGP under the hood to gain the protections from C-level
+security holes, which are certainly a real concern.)
+"""]]
diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_6_991bf6846513818c00b75b7962b0fb2e._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_6_991bf6846513818c00b75b7962b0fb2e._comment
new file mode 100644
index 0000000000..f88671cbe7
--- /dev/null
+++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_6_991bf6846513818c00b75b7962b0fb2e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="aurelia@b44312a63326710de6cea9c43290e5debbd55607"
+ nickname="aurelia"
+ avatar="http://cdn.libravatar.org/avatar/818bf579caf9992f9123bd9b58321b2b"
+ subject="comment 6"
+ date="2022-06-06T12:38:26Z"
+ content="""
+The biggest reason to use age over PGP seems to be in the simplicity / attack surface. It deliberately does not include options to combat complexity and insecure configurations. It also has a lot less baggage and complexity than PGP: obscure packet-based format, web of trust, subkeys - age does a single thing, and it does it well. I do have a use case for hybrid encryption, but I'd rather not touch GPG ever again if I don't need to. Just the squabble about importing keys without identities makes me want to stay far far away. Age keys handle like SSH keys, so if you have a strategy for those age fits into your workflow very easily.
+
+Age also supports passphrase derived keys now, so the \"shared\" use case is covered.
+
+
+"""]]
diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_7_d86cf1376fbbd85e9ea63d7b7afbd1fc._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_7_d86cf1376fbbd85e9ea63d7b7afbd1fc._comment
new file mode 100644
index 0000000000..c0fb79a5e0
--- /dev/null
+++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_7_d86cf1376fbbd85e9ea63d7b7afbd1fc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jpds"
+ avatar="http://cdn.libravatar.org/avatar/24d746ec6a7726b162c12ecceb3ee267"
+ subject="comment 7"
+ date="2023-01-28T00:00:13Z"
+ content="""
+There's also https://github.com/str4d/rage if anyone prefers Rust implementations of things.
+"""]]
diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_8_d784886328bc00b2adaba2391776d2c8._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_8_d784886328bc00b2adaba2391776d2c8._comment
new file mode 100644
index 0000000000..9d0e56feed
--- /dev/null
+++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_8_d784886328bc00b2adaba2391776d2c8._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2024-01-09T20:28:58Z"
+ content="""
+<https://crates.io/crates/sequoia-chameleon-gnupg> should be possible to
+use as a drop-in replacement for gpg. Assuming they implemented enough of
+gpg's interface.
+
+To try using it with git-annex, it should be sufficient to run:
+
+	git config gpg.program gpg-sq
+"""]]
diff --git a/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_9_18861f94b677a40c2d1c0014338231c6._comment b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_9_18861f94b677a40c2d1c0014338231c6._comment
new file mode 100644
index 0000000000..7635074db3
--- /dev/null
+++ b/doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_9_18861f94b677a40c2d1c0014338231c6._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2024-01-09T20:33:08Z"
+ content="""
+git-annex now supports using any program that implements the
+Stateless OpenPGP standard for remotes using encryption=shared
+
+Eg, to use Sequoia's sqpop:
+
+	git config annex.shared-sop-command sqop
+
+That fully interoperates with gpg, though it's probably a good idea
+to specify an enryption profile that is backwards compatable if interop
+is a concern. Eg:
+
+	git config annex.shared-sop-profile rfc4880
+
+For other encryption= schemes, Stateless OpenPGP is not yet supported,
+mostly because it's not clear how to manage the encryption keys.
+See this todo [[support_using_Stateless_OpenPGP_instead_of_gpg]]
+"""]]
diff --git a/doc/todo/whishlist__58___kde-connect_as_a_transport.mdwn b/doc/todo/whishlist__58___kde-connect_as_a_transport.mdwn
new file mode 100644
index 0000000000..003d79b62d
--- /dev/null
+++ b/doc/todo/whishlist__58___kde-connect_as_a_transport.mdwn
@@ -0,0 +1,9 @@
+Running an SSH server on a phone is quite some setup and could perhaps even be considered insecure.
+
+KDE-connect provides a an easy to set up method of creating a transport tunnel between phone and computer. Many users might actually have it set up already.
+
+Apparently, it can even be used to connect multiple desktops with another but I haven't tested that. This could be an alternative (or perhaps even replacement?) to git-annex' current pairing mechanism.
+
+KDE-connect offers remote command execution and file sharing, so it should be possible to use it for git-annex' purposes.
+
+> [[rejected|done]] --[[Joey]]
diff --git a/doc/todo/whishlist__58___kde-connect_as_a_transport/comment_1_14426ad1fa5dfc32d290da484c1e4c7b._comment b/doc/todo/whishlist__58___kde-connect_as_a_transport/comment_1_14426ad1fa5dfc32d290da484c1e4c7b._comment
new file mode 100644
index 0000000000..a6a412057a
--- /dev/null
+++ b/doc/todo/whishlist__58___kde-connect_as_a_transport/comment_1_14426ad1fa5dfc32d290da484c1e4c7b._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-06-04T17:23:06Z"
+ content="""
+From what I can see, kde-connect lets the phone be used to run specific,
+pre-selected commands on the linux computer it's paired with. Not the other
+way around. <https://userbase.kde.org/KDE_Connect/Tutorials/Adding_commands>
+Also being able to run a command on a phone is rather a long way from what
+git-annex actually needs.
+
+It seems like it would be possible to use the remote filesystem via sftp part
+of it. <https://rafaelc.org/tech/p/mounting-kde-connect-filesystem-via-cli/>
+That would be a useful alternative to adb. I don't think git-annex needs
+any changes to use it that way, just mount it with sshfs and
+initremote a directory special remote with exporttree=yes and
+importtree=yes.
+
+See also [[add_sftp_special_remote]] which if it were implemented would
+avoid needing to use sshfs.
+"""]]
diff --git a/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities.mdwn b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities.mdwn
new file mode 100644
index 0000000000..9442fa50ac
--- /dev/null
+++ b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities.mdwn
@@ -0,0 +1,57 @@
+I was going to report a bug with the transition to lts-19.13 in stack.yaml as I couldn't
+get for instance commit [[!commit d2bc2683173ca1ade437aa294b26fd5e54353a55]] "lts-19.13 (ghc 9.0.2)"
+that introduced it to compile on windows (with stack). But then I procrastinated too long and commit
+[[!commit d01530ac21aead6607085b5cc90b62a52acd03a9]] came along which reverted the transition and
+went back to lts-18.13 due to Joey having trouble getting ghc 9.0.2 to install. That was kind of fortunate
+to me because I didn't want to be the bringer of bad news regarding Windows in a bug report setting.
+
+The problem with compiling with LTS 19 on Windows is the following:
+
+[[!format sh """
+[...]
+[109 of 670] Compiling Utility.LockFile.Windows
+
+Utility\LockFile\Windows.hs:64:17: error:
+    * Variable not in scope:
+        c_CreateFile
+          :: LPTSTR
+             -> AccessMode
+             -> ShareMode
+             -> GHC.Ptr.Ptr a0
+             -> CreateMode
+             -> FileAttributeOrFlag
+             -> GHC.Ptr.Ptr a1
+             -> IO HANDLE
+    * Perhaps you meant `createFile' (imported from System.Win32.File)
+   |
+64 |                 c_CreateFile c_f gENERIC_READ sharemode security_attributes
+
+   |                 ^^^^^^^^^^^^
+Completed 229 action(s).
+
+--  While building package git-annex-10.20220624 (scroll up to its section to see the error) using:
+      C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-220630-d2bc26831\.stack-work\dist\d53b6a14\setup\setup --builddir=.stack-work\dist\d53b6a14 build exe:git-annex --ghc-options " -fdiagnostics-color=always"
+    Process exited with code: ExitFailure 1
+"""]]
+
+I digged into this and it turned out that as of Win32-2.12.0.0 it does not include those bindings
+anymore that begin with `c_` in its exports and considers them as internal details. Unfortunately in
+System.Win32.File the alternative, `createFile`, is a "cooked" API in the sense that if there are
+intermittent errors opening the file there is some Haskell code that busy-waits on behalf of the user.
+But according to Joey that is undesirable for a lockfile implementation (.\Utility\LockFile\Windows.hs:53):
+
+```
+ - Note that createFile busy-waits to try to avoid failing when some other
+ - process briefly has a file open. But that would make checking locks
+ - much more expensive, so is not done here. Thus, the use of c_CreateFile.
+ 
+```
+
+So what to do when the authors of package Win32 pull the rug from under you? Should we perhaps weave
+our own tiny c_CreateFile API with FFI, or, could we do without it and use one of the implementations
+using Windows LockFileEx, for instance the one by my compatriot: <https://hackage.haskell.org/package/lukko>
+
+[[!meta title="windows: prepare for System.Win32.File not exporting c_ entities"]]
+[[!meta author=jkniiv]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_1_40985c5919f20fd47fa57caec09bfa3c._comment b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_1_40985c5919f20fd47fa57caec09bfa3c._comment
new file mode 100644
index 0000000000..a034ce08f5
--- /dev/null
+++ b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_1_40985c5919f20fd47fa57caec09bfa3c._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-07-12T19:59:54Z"
+ content="""
+We could go argue with the Win32 maintainer to put it back in.
+I have: <https://github.com/haskell/win32/issues/208>
+
+But it is a simple FFI implementation so I would not mind just including it
+in git-annex.
+
+... But also git-annex can depend on a version of Win32 before this
+breakage. I've made that change. It's perhaps only a stopgap, if something
+else that git-annex uses begins depending on the newer version of Win32
+later.
+
+Switching to LockFileEx seems like it might break interoperation with older
+git-annex versions?
+"""]]
diff --git a/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_2_1d9c331e774138ceb89b1f7920bb76d4._comment b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_2_1d9c331e774138ceb89b1f7920bb76d4._comment
new file mode 100644
index 0000000000..c0323240a2
--- /dev/null
+++ b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_2_1d9c331e774138ceb89b1f7920bb76d4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 2"
+ date="2022-07-14T20:32:06Z"
+ content="""
+> We could go argue with the Win32 maintainer to put it back in. I have: https://github.com/haskell/win32/issues/208
+
+Thanks. I see they seem be rather receptive to your suggestion. (I put in a thumbs up, too) The only issue I see is deciding on
+how to name the raw version of createFile. Is there some precedent in Haskell land as to naming conventions? C and Python
+would just prepend an underscore or two to the name without necessarily indicating that they would be thereby off limits (\"internal\").
+Maybe something like `_raw_CreateFile` with or without the underscore in the beginning?
+
+"""]]
diff --git a/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_3_88b58dd27cbff3f046b6f8d1c612f87f._comment b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_3_88b58dd27cbff3f046b6f8d1c612f87f._comment
new file mode 100644
index 0000000000..00662ed0d9
--- /dev/null
+++ b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_3_88b58dd27cbff3f046b6f8d1c612f87f._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 3"
+ date="2022-07-21T20:08:54Z"
+ content="""
+I see that things are slowly moving ahead in that github issue. On a somewhat related note
+I was able to compile with stack on Windows with lts-19.13 by adding the following extra-deps
+to stack.yaml (starting from Win32 onward in the following patch):
+
+[[!format diff \"\"\"
+diff --git a/stack.yaml b/stack.yaml
+index 9b067c82f..27b0fe53c 100644
+--- a/stack.yaml
++++ b/stack.yaml
+@@ -12,19 +12,21 @@ flags:
+     gitlfs: true
+ packages:
+ - '.'
+-resolver: lts-18.13
++resolver: lts-19.13
+ extra-deps:
+ - IfElse-0.85
+ - aws-0.22
+ - bloomfilter-2.0.1.0
+ - git-lfs-1.2.0
+-- http-client-restricted-0.0.4
++- http-client-restricted-0.0.5
+ - network-multicast-0.3.2
+ - sandi-0.5
+ - torrent-10000.1.1
+-- base16-bytestring-0.1.1.7
+-- base64-bytestring-1.0.0.3
+-- bencode-0.6.1.1
+-- http-client-0.7.9
++- aeson-1.5.6.0
++- Win32-2.9.0.0
++- Cabal-3.6.3.0
++- directory-1.3.7.0
++- process-1.6.14.0
++- time-1.11.1.2
+ explicit-setup-deps:
+   git-annex: true
+\"\"\"]]
+
+Yes, that was the newest Win32 I was able to make things work with as stack wasn't able
+to resolve the cross-dependencies involving `Win32`, `directory`, `process` and `time` packages otherwise.
+And if I remember correctly there was something called `haskeline` that also had specific
+requirements.
+"""]]
diff --git a/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_4_28e5593e0a58fb7d7a2a297fa63e8208._comment b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_4_28e5593e0a58fb7d7a2a297fa63e8208._comment
new file mode 100644
index 0000000000..5365531c7f
--- /dev/null
+++ b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_4_28e5593e0a58fb7d7a2a297fa63e8208._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-08-02T14:43:47Z"
+ content="""
+The necessary change will be in win32 2.13.3.1, which should be released
+in due course. And I've made a (so far untested) change to git-annex to
+support that version.
+"""]]
diff --git a/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_5_43603d84801cfe0ecfcdc408db97ae22._comment b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_5_43603d84801cfe0ecfcdc408db97ae22._comment
new file mode 100644
index 0000000000..8021baf121
--- /dev/null
+++ b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_5_43603d84801cfe0ecfcdc408db97ae22._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 5"
+ date="2022-08-03T15:14:22Z"
+ content="""
+Thanks, Joey, for making the pull request in Win32 with the necessary changes to support git-annex's
+use case. I will be on the lookout for its next release and then as soon as possible try building
+git-annex with LTS 19 via stack. I'll then report my findings here if you have not already done
+something to that effect before me.
+"""]]
diff --git a/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_6_a623b2e131dd85f50e04483d262abc9a._comment b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_6_a623b2e131dd85f50e04483d262abc9a._comment
new file mode 100644
index 0000000000..59f1c522a8
--- /dev/null
+++ b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_6_a623b2e131dd85f50e04483d262abc9a._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="typo in Utility/LockFile/Windows.hs"
+ date="2022-08-03T20:46:14Z"
+ content="""
+It seems there was a tiny typo in commit [[!commit 472f5c142b063053828358a3031a2ca09a373127]], hence
+the following simple correction is needed for the build to complete:
+
+[[!format diff \"\"\"
+diff --git a/Utility/LockFile/Windows.hs b/Utility/LockFile/Windows.hs
+index 9ec34c9a7..6985f408c 100644
+--- a/Utility/LockFile/Windows.hs
++++ b/Utility/LockFile/Windows.hs
+@@ -61,7 +61,7 @@ lockExclusive = openLock fILE_SHARE_NONE
+ openLock :: ShareMode -> LockFile -> IO (Maybe LockHandle)
+ openLock sharemode f = do
+        f' <- convertToNativeNamespace f
+-#if MIN_VERSION_win32(2,13,3)
++#if MIN_VERSION_Win32(2,13,3)
+        r <- tryNonAsync $ createFile_NoRetry f' gENERIC_READ sharemode
+                security_attributes oPEN_ALWAYS fILE_ATTRIBUTE_NORMAL
+                (maybePtr Nothing)
+\"\"\"]]
+
+"""]]
diff --git a/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_7_91c17601eed0936bab17cdf9ec5f3ecb._comment b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_7_91c17601eed0936bab17cdf9ec5f3ecb._comment
new file mode 100644
index 0000000000..24bf69ed23
--- /dev/null
+++ b/doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities/comment_7_91c17601eed0936bab17cdf9ec5f3ecb._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-08-04T16:16:59Z"
+ content="""
+Ah yes, case-sensativity urk. Thanks, fixed.
+"""]]
diff --git a/doc/todo/windows_support.mdwn b/doc/todo/windows_support.mdwn
new file mode 100644
index 0000000000..eb498e2aa4
--- /dev/null
+++ b/doc/todo/windows_support.mdwn
@@ -0,0 +1,136 @@
+The git-annex Windows port is beta, but rapidly becoming polished and
+usable!
+
+
+## status
+
+* Local pairing seems to fail, after acking on Linux box, it stalls.
+  (Also, of course, the Windows box is unlikely to have a ssh server,
+  so only pairing with a !Windows box will work.)
+
+* gcrypt is not ported to windows (and as a shell script, may need
+  to be rewritten)
+
+* Deleting a git repository from inside the webapp fails "RemoveDirectory
+  permision denied ... file is being used by another process"
+
+* Tor remotes are not supported yet. Should not be very hard to get it working.
+
+## potential encoding problems
+
+[[bugs/Unicode_file_names_ignored_on_Windows]] is fixed, but some potential
+problems remain, since the FileSystemEncoding that git-annex relies on
+seems unreliable/broken on Windows.
+
+* When git-annex displays a filename that it's acting on, there
+  can be mojibake on Windows. For example, "háčky.txt" displays
+  the accented characters as instead the pairs of bytes making
+  up the utf-8. Tried doing various things to the stdout handle
+  to avoid this, but only ended up with encoding crashes, or worse
+  mojibake than this.
+
+  > This may be use to windows actually using utf-16, but git-annex uses
+  > utf-8 for filename encoding when on windows.
+
+* If interoperating with a git-annex repository from a unix system, it's
+  possible for a key to contain some invalid utf-8, which means its filename
+  cannot even be represented on Windows, so who knows what will happen in that
+  case -- probably it will fail in some way when adding the object file
+  to the Windows repo. 
+
+* If data from the git repo does not have a unicode encoding, it will be
+  mangled in various places on Windows, which can lead to undefined behavior.
+
+## minor problems
+
+* webapp lets user choose to encrypt repo, and generate gpg key,
+  before checking that gcrypt is not installed
+* Ssh connection caching does not work on Windows, so `git annex get`
+  has to connect twice to the remote system over ssh per file, which
+  is much slower than on systems supporting connection caching.
+* glacier-cli is not easily available (probably)
+
+## stuff needing testing
+
+* test that adding a repo on a removable drive works; that git is synced to
+  it and files can be transferred to it and back
+* Does stopping in progress transfers work in the webapp?
+
+## do we need this port anymore?
+
+See <http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html>
+
+If windows has transparent support for running linux executables, and those
+executables can access files in "." which are on the windows system, then
+you could just use this to run linux git-annex on windows. No port needed.
+
+That would be great!
+
+Seems like this would need Windows 10.
+
+> The latest builds of Windows 10 (build 15063) can run git-annex in the
+> Windows Subsystem for Linux. After following the instructions at
+> <https://msdn.microsoft.com/en-us/commandline/wsl/about>, run:
+> `sudo apt-get install git-annex`
+> 
+> git-annex in WSL passes its full test suite, and it avoids all
+> the problems discussed in sections above.
+> 
+> git-annex can access Windows files in eg `/mnt/c`, so a git-annex
+> repository can be stored there. However, if the git-annex repository uses
+> indirect mode, the symlinks used by git-annex won't be usable by Windows
+> programs. Use either direct mode, or v6 mode to avoid the symlink
+> problem.
+> 
+> Also, see this important caveat:
+> <https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/>
+> 
+> March 2017: WSL is currently rather annoying to enable. *If* it became easy enough
+> to enable, note that "bash -c git-annex" works from a windows command
+> prompt, and would probably work in a .bat file as well, so git-annex from
+> the WSL could be transparently used on the windows side.
+> 
+> The webapp does not currently work. It doesn't know how to open a web
+> browser from the linux side. There are also what look like some emulation
+> problems around the daemonization code. `git annex assistant
+> --foreground` does run, but while it notices when new files are added, it
+> does not notice when existing files get modified. Probably an inotify
+> emulation bug. --[[Joey]]
+> 
+> > Update May 2018: With the latest MS Edge VirtualBox image, 
+> > enabling WSL was much easier than before, just a matter of checking a
+> > single box and a reboot. No need to enable developer mode first.
+> > (Don't know if this will apply to commercial Windows 10 or only this
+> > VM image.)
+> > 
+> > Then bash was available in the menu, but it said no distro installed,
+> > and gave an url to a "Store" where Ubuntu, Debian, etc 
+> > could be installed.
+> > 
+> > git-annex test had a failure this time, something to do with disk
+> > IO error and sqlite.
+> > 
+> > The assistant can run as a daemon now. It still doesn't notice some changes. 
+> > Eg with "rm foo; echo new > foo", it got an inotify event for the removal,
+> > but missed the new creation.
+> >
+> > Running `git annex assistant` when the assistant is running
+> > complains of a stale pid file, with the wrong pid number, but it
+> > doesn't start a second one.
+> > 
+> > webapp still can't open a web browser, but there's a way to do
+> > it from within WSL that it should be possible for it to use:
+> > `powershell.exe Start http://google.com`
+> > ("powershell.exe" is in PATH)
+> > 
+> > --[[Joey]]
+> > 
+> > > The sqlite problem may be fixed in git-annex 7. I fixed some similar,
+> > > less frequent crashes on Linux. Need to test on windows. --[[Joey]]
+
+> > > > But here's a bug about sqlite in WSL:
+> > > > [[bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol]] --[[Joey]]
+
+## update Sept 2022:
+
+Git-annex has become more reliable on WSL1 recently, see [[tips/Using_git-annex_on_NTFS_with_WSL1]].
diff --git a/doc/todo/windows_support/comment_10_394127e34e07ab3dc0e7b94ee6898866._comment b/doc/todo/windows_support/comment_10_394127e34e07ab3dc0e7b94ee6898866._comment
new file mode 100644
index 0000000000..fb061962e5
--- /dev/null
+++ b/doc/todo/windows_support/comment_10_394127e34e07ab3dc0e7b94ee6898866._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.145"
+ subject="comment 10"
+ date="2013-08-04T18:23:00Z"
+ content="""
+Encryption is now working on Windows.
+"""]]
diff --git a/doc/todo/windows_support/comment_11_c91eb7da8ee05064a5bc4a6e2203314b._comment b/doc/todo/windows_support/comment_11_c91eb7da8ee05064a5bc4a6e2203314b._comment
new file mode 100644
index 0000000000..f4a2eaa7f3
--- /dev/null
+++ b/doc/todo/windows_support/comment_11_c91eb7da8ee05064a5bc4a6e2203314b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 11"
+ date="2014-06-16T23:48:03Z"
+ content="""
+service stuff moved to [[todo/windows_git-annex_service]]
+"""]]
diff --git a/doc/todo/windows_support/comment_12_0775dc22516cfa8c5e7deea954084947._comment b/doc/todo/windows_support/comment_12_0775dc22516cfa8c5e7deea954084947._comment
new file mode 100644
index 0000000000..0c3aa46d4f
--- /dev/null
+++ b/doc/todo/windows_support/comment_12_0775dc22516cfa8c5e7deea954084947._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQOUUx4LVAk6EnstSLvdv7gZc0NsRlHXw"
+ nickname="Dave"
+ subject="windows port volunteer tester"
+ date="2014-09-08T15:39:03Z"
+ content="""
+Hello.
+
+I volunteer to test the Windows port.  I can only do so on the work computer.  :)
+
+I know how to produce a Minimal Reproducible Example.  Are there some areas that need attention?
+
+I've enabled the 'email replies to me' ikiwiki feature.  (Nice plugin.)
+
+Cheers,
+
+--Dave
+"""]]
diff --git a/doc/todo/windows_support/comment_13_4dfb65242280c2e28796f1ab8f022dea._comment b/doc/todo/windows_support/comment_13_4dfb65242280c2e28796f1ab8f022dea._comment
new file mode 100644
index 0000000000..65b24f25f4
--- /dev/null
+++ b/doc/todo/windows_support/comment_13_4dfb65242280c2e28796f1ab8f022dea._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="tomekwi"
+ subject="Linux-Windows repo"
+ date="2015-08-10T18:22:22Z"
+ content="""
+Hi, what’s the recommended way to manage a repo accessed from both a Linux and a Windows box? Has anyone had success with that?
+
+I’m dual-booting Fedora 22 and Windows 8.1. I do most of my work on Linux, but I need Windows programs to edit some of my files. I’ve had a go at two approaches:
+
+1) Have a “central” repo on an NTFS external drive which also holds the contents of files. This fails because Windows fails to check out the contents of most files. It isn’t random – specific files at specific points of the commit history fail to check out. Perhaps it has something to do with filenames? Characters in filenames?
+
+2) Keep a “direct” clone of my repo on a Windows NTFS partition. I do my work on Windows, and after rebooting to Linux I mount the partition and commit my changes directly in the repo. Here Windows seems to outsmart me. git-annex sometimes takes many files without content as modified – and commits them as empty.
+"""]]
diff --git a/doc/todo/windows_support/comment_14_a8519b722cb94f9363d4a8a8bd40e942._comment b/doc/todo/windows_support/comment_14_a8519b722cb94f9363d4a8a8bd40e942._comment
new file mode 100644
index 0000000000..587ea02277
--- /dev/null
+++ b/doc/todo/windows_support/comment_14_a8519b722cb94f9363d4a8a8bd40e942._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tomekwi"
+ subject="Linux-Windows repo"
+ date="2016-01-26T20:46:58Z"
+ content="""
+Ping!
+
+I’m trying to organize my Linux + Windows workflow again. Has anyone had success managing an annex repo from Linux and Windows?
+"""]]
diff --git a/doc/todo/windows_support/comment_15_61d1281072de2bb418cf96fd8b563d45._comment b/doc/todo/windows_support/comment_15_61d1281072de2bb418cf96fd8b563d45._comment
new file mode 100644
index 0000000000..9eae2b7b12
--- /dev/null
+++ b/doc/todo/windows_support/comment_15_61d1281072de2bb418cf96fd8b563d45._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="ztl8702"
+ subject="Bash on Windows"
+ date="2016-09-30T19:14:34Z"
+ content="""
+Currently there is a bug that stops all Haskell programs from running on Bash on Windows:
+https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13572504-add-support-for-timer-create
+
+https://github.com/Microsoft/BashOnWindows/issues/307
+"""]]
diff --git a/doc/todo/windows_support/comment_16_6bbcf900874e950b08cdf0410f7a75d2._comment b/doc/todo/windows_support/comment_16_6bbcf900874e950b08cdf0410f7a75d2._comment
new file mode 100644
index 0000000000..3e534d6d44
--- /dev/null
+++ b/doc/todo/windows_support/comment_16_6bbcf900874e950b08cdf0410f7a75d2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/26f3c692-0460-4cbc-8712-e9bfb5889fb2"
+ nickname="Tobias Kienzler"
+ avatar="http://cdn.libravatar.org/avatar/f66be680ced3f9dc4786e308ceade73902e185d407be873e98266fc745c8c075"
+ subject="&quot;WSL adds inotify & filesystem change notification support&quot;"
+ date="2017-08-07T06:22:07Z"
+ content="""
+https://blogs.msdn.microsoft.com/commandline/2016/10/07/wsl-adds-inotify-filesystem-change-notification-support/
+
+So it should work now, right?
+"""]]
diff --git a/doc/todo/windows_support/comment_17_653b36e0838308dd85d38b05d3df5077._comment b/doc/todo/windows_support/comment_17_653b36e0838308dd85d38b05d3df5077._comment
new file mode 100644
index 0000000000..756bc328c2
--- /dev/null
+++ b/doc/todo/windows_support/comment_17_653b36e0838308dd85d38b05d3df5077._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="May be it is time?"
+ date="2019-01-20T15:32:38Z"
+ content="""
+> ... Postponed until old versions of git-annex-shell are less common
+
+I find installation on windows unnecessarily complicated with current demand of using x86 git.  Not that it is impossible but it makes it more elaborate, even for old timers.
+Would be nice if it was streamlined more.  I even wondered if there is a way to provide (additional) bundles which would come with git itself.  This way it could be just the git-annex installer to install all needed for working with git-annex (instead of this multistep process)
+"""]]
diff --git a/doc/todo/windows_support/comment_18_fbd19cd8365808daa007f44ff167c635._comment b/doc/todo/windows_support/comment_18_fbd19cd8365808daa007f44ff167c635._comment
new file mode 100644
index 0000000000..7733e82e96
--- /dev/null
+++ b/doc/todo/windows_support/comment_18_fbd19cd8365808daa007f44ff167c635._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="neil.okamoto@6ca5b1b6563bc71ce13ec235852d23e6ac86e331"
+ nickname="neil.okamoto"
+ avatar="http://cdn.libravatar.org/avatar/d9ced27b5d480416c9c3134b365e96d2"
+ subject="comment 18"
+ date="2021-07-20T23:22:28Z"
+ content="""
+Is there any chance of getting ssh connection caching supported on Windows?
+
+I didn’t realize the full impact of this until I started syncing a larger repo, but now I understand if you start a sync you have to hand around and be ready with a passphrase when asked, because the sync will pause multiple times waiting for that input.  For testing that’s fine but in production that’s too inconvenient. 
+"""]]
diff --git a/doc/todo/windows_support/comment_19_87e06eb2968856ce97b6162bc14203c1._comment b/doc/todo/windows_support/comment_19_87e06eb2968856ce97b6162bc14203c1._comment
new file mode 100644
index 0000000000..bd3b16fc09
--- /dev/null
+++ b/doc/todo/windows_support/comment_19_87e06eb2968856ce97b6162bc14203c1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="neil.okamoto@6ca5b1b6563bc71ce13ec235852d23e6ac86e331"
+ nickname="neil.okamoto"
+ avatar="http://cdn.libravatar.org/avatar/d9ced27b5d480416c9c3134b365e96d2"
+ subject="comment 19"
+ date="2021-07-21T07:13:01Z"
+ content="""
+Turns out ssh-agent works just fine in the git bash shell on Windows, and at least I'm not prompted over and over.
+"""]]
diff --git a/doc/todo/windows_support/comment_1_3cc26ad8101a22e95a8c60cf0c4dedcc._comment b/doc/todo/windows_support/comment_1_3cc26ad8101a22e95a8c60cf0c4dedcc._comment
new file mode 100644
index 0000000000..fd5b6f5cd3
--- /dev/null
+++ b/doc/todo/windows_support/comment_1_3cc26ad8101a22e95a8c60cf0c4dedcc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkRITTYYsN0TFKN7G5sZ6BWGZOTQ88Pz4s"
+ nickname="Zoltán"
+ subject="cygwin"
+ date="2012-05-15T00:14:08Z"
+ content="""
+What about [Cygwin](http://cygwin.com/)? It emulates POSIX fairly well under Windows (including signals, forking, fs (also things like /dev/null, /proc), unix file permissions), has all standard gnu utilities. It also emulates symlinks, but they are unfortunately incompatible with NTFS symlinks introduced in Vista [due to some stupid restrictions on Windows](http://cygwin.com/ml/cygwin/2009-10/msg00756.html).
+
+If git-annex could be modified to not require symlinks to work, the it would be a pretty neat solution (and you get a real shell, not some command.com on drugs (aka cmd.exe))
+"""]]
diff --git a/doc/todo/windows_support/comment_20_7d83963db52d5dedd65f8cf7937dff4f._comment b/doc/todo/windows_support/comment_20_7d83963db52d5dedd65f8cf7937dff4f._comment
new file mode 100644
index 0000000000..d4df63ee7d
--- /dev/null
+++ b/doc/todo/windows_support/comment_20_7d83963db52d5dedd65f8cf7937dff4f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 20"""
+ date="2021-07-21T15:03:52Z"
+ content="""
+Enabling the ssh agent avoids password prompts, but not the latency
+of making a ssh connection per transfer.
+
+You can try setting the environment variable `GIT_ANNEX_SSH_SOCKET_DIR`
+to point to a directory where ssh can try to put its socket. I don't know
+if ssh on windows is able to use a socket or not. It might just work.
+"""]]
diff --git a/doc/todo/windows_support/comment_21_49ef5997d36ade4797ef77b1b62f5405._comment b/doc/todo/windows_support/comment_21_49ef5997d36ade4797ef77b1b62f5405._comment
new file mode 100644
index 0000000000..47e7471e90
--- /dev/null
+++ b/doc/todo/windows_support/comment_21_49ef5997d36ade4797ef77b1b62f5405._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="the WSL1 use case"
+ date="2021-10-07T04:12:48Z"
+ content="""
+User asakurareiko added some instructions to this page how to use git-annex in Ubuntu 20 (presumably
+20.04) in WSL1 and I tested them out in my older Ubuntu 18.04 installation and found out that they
+amazingly work although my Windows apps couldn't access any of the files that were still locked.
+Somehow the symlinks were only in a form that only WSL1 and Cygwin/MSYS2/Git Bash could access
+(mind you I have developer mode active and my Windows 10 is also version 21H1 so the environment
+was otherwise similar). An interesting use case nonetheless. I edited the section with my corrections
+ -- I hope asakurareiko doesn't mind. :)
+
+"""]]
diff --git a/doc/todo/windows_support/comment_22_8e5b8ec9e6a63bcde7390511c92d2940._comment b/doc/todo/windows_support/comment_22_8e5b8ec9e6a63bcde7390511c92d2940._comment
new file mode 100644
index 0000000000..7f47b03b8e
--- /dev/null
+++ b/doc/todo/windows_support/comment_22_8e5b8ec9e6a63bcde7390511c92d2940._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 22"
+ date="2021-10-07T06:17:30Z"
+ content="""
+For me I tried git on windows at first but when checking out the working tree after a clone it slowed down so much that it would not complete in a reasonable amount of time. So that's why I decided to try using WSL1.
+
+In my opinion it's not necessary to use `case=dir`. `case=dir` was at one point the default but was removed as the default due to the potential to cause problems with windows programs ([[https://devblogs.microsoft.com/commandline/improved-per-directory-case-sensitivity-support-in-wsl]]). But if you do have `case=dir` then it is not necessary to set the attribute.
+
+If your symlinks are not working, make sure to have deleted and recreated the symlinks after doing `git annex get` and that the NT symlink requirements listed [here](https://github.com/MicrosoftDocs/WSL/releases/tag/17046) have been met. If the symlink target has changed from file to directory or vice versa the symlink also has to be recreated. However there are other reports of symlinks not working despite following these requirements:
+
+* [[https://github.com/microsoft/WSL/issues/353#issuecomment-544857020]] Commenter is using Windows 10 Home 1903. (I'm using Windows 10 Enterprise)
+* [[https://github.com/microsoft/WSL/issues/353#issuecomment-478953190]] Commenter updated to Windows 10 1809 and it stopped working.
+* [[https://github.com/microsoft/WSL/issues/353#issuecomment-478048780]] Commenter mounted with UNC rather than drive letter.
+"""]]
diff --git a/doc/todo/windows_support/comment_23_616a7d579730e5a4f5cc314d6328bfd0._comment b/doc/todo/windows_support/comment_23_616a7d579730e5a4f5cc314d6328bfd0._comment
new file mode 100644
index 0000000000..ba8529ba5c
--- /dev/null
+++ b/doc/todo/windows_support/comment_23_616a7d579730e5a4f5cc314d6328bfd0._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 23"
+ date="2021-10-07T11:36:48Z"
+ content="""
+@asakurareiko: Oh, based on [[https://docs.microsoft.com/en-us/windows/wsl/case-sensitivity#case-sensitivity-options-for-mounting-a-drive-in-wsl-configuration-file]]
+I got the impression that `case=dir` was a prerequisite to make the attribute `system.wsl_case_sensitive`
+work as per the heading \"Default setting: dir for enabling case sensitivity per directory\". I guess
+I was wrong, `case=off` works too. I'll remove `case=dir` it from the instructions once again.
+
+Also the NT symlink requirements are fulfilled in my case simply by way of me having developer mode
+enabled in 21H1 (Windows 10 Pro). I create symlinks all the time with
+\"cmd /c mklink ...\" in Powershell without elevation. Git-annex also creates only relative symlinks
+which was also a requirement in the WSL release news you mentioned. No, this must be one of those
+miscellanous problems mentioned in [[WSL issue 353|https://github.com/microsoft/WSL/issues/353]].
+
+_Edit_: Oh, in fact recreating the symlink after getting the file with `git-annex get` by deleting the symlink
+with rm and then checking it out again with `git checkout -- <file>` seems to allow me to access
+the file in Windows just fine. Interesting. Maybe it's git-annex itself that creates the wrong
+kind of symlink that a later call to plain git can repair. Quite convoluted it seems.
+
+"""]]
diff --git a/doc/todo/windows_support/comment_24_f50de72a082476e0a2e7587368191788._comment b/doc/todo/windows_support/comment_24_f50de72a082476e0a2e7587368191788._comment
new file mode 100644
index 0000000000..2ae8a5be33
--- /dev/null
+++ b/doc/todo/windows_support/comment_24_f50de72a082476e0a2e7587368191788._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 24"
+ date="2021-10-07T16:27:39Z"
+ content="""
+One of the requirements in particular is that the link target must exist. In a freshly cloned repo the link targets do not exist so it's important to recreate the symlinks after you get the annexed files.
+
+NT symlinks must have either file or directory target type. If the link target does not exist at the time when the symlink is created, it's not possible to determine the target type.
+"""]]
diff --git a/doc/todo/windows_support/comment_25_5eb1a4693db88a9e05500ad66edce61d._comment b/doc/todo/windows_support/comment_25_5eb1a4693db88a9e05500ad66edce61d._comment
new file mode 100644
index 0000000000..b9befe759e
--- /dev/null
+++ b/doc/todo/windows_support/comment_25_5eb1a4693db88a9e05500ad66edce61d._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 25"
+ date="2021-10-07T18:27:19Z"
+ content="""
+> _asakurareiko_: One of the requirements in particular is that the link target must exist. ...
+
+That's useful info. :) Many thanks for your input regarding WSL1 use! For me that opens up new avenues by way of
+borg special remotes (borg support on Windows is very lacking and there are no recent binaries for it).
+I still think git -- and to a lesser extent git-annex -- is performant enough on native Windows, so I'm
+going to continue using it that way for those repos that need to be foolproof and in a supported configuration.
+But for more experimental uses WSL1 still holds quite some promise wrt git-annex. DrvFs is still many times faster
+than 9p of WSL2 *for Windows native files on NTFS* which is an important use case for exchanging data between
+Windows and POSIXland. In fact while WSL2 boots incredibly fast for a Hyper-V virtual machine, in many file-level
+use cases it can't hold candle to the almost seamless nature of WSL1. The latter has its warts in API compatibility
+but in my mind it's quite a undervalued little performer. I hope Microsoft doesn't remove it too soon in favor of WSL2.
+"""]]
diff --git a/doc/todo/windows_support/comment_26_99d0541d1c7f7c82a67d481c61209670._comment b/doc/todo/windows_support/comment_26_99d0541d1c7f7c82a67d481c61209670._comment
new file mode 100644
index 0000000000..2a586da213
--- /dev/null
+++ b/doc/todo/windows_support/comment_26_99d0541d1c7f7c82a67d481c61209670._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="NewUser"
+ nickname="dont.post.me"
+ avatar="http://cdn.libravatar.org/avatar/90f59ddc341eaf9b2657422206c06901"
+ subject="Is `annex.tune.objecthashlower=true` recommended for interop with windows?"
+ date="2023-11-20T04:24:35Z"
+ content="""
+I've been adding stuff to git annex on my linux server and now I'm thinking that I need to uninit and re-init with `annex.tune.objecthashlower=true`. I'll want to use git-annex from windows as well.
+
+Should I use `annex.tune.objecthashlower=true`? Also, what's the advice around the other tuning options `objecthash1` and `branchhash1`?
+
+Thanks!
+"""]]
diff --git a/doc/todo/windows_support/comment_2_8acae818ce468967499050bbe3c532ea._comment b/doc/todo/windows_support/comment_2_8acae818ce468967499050bbe3c532ea._comment
new file mode 100644
index 0000000000..e37a555756
--- /dev/null
+++ b/doc/todo/windows_support/comment_2_8acae818ce468967499050bbe3c532ea._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk5cj-itfFHq_yhJHdzk3QOPp-PNW_MjPU"
+ nickname="Michael"
+ subject="+1 Cygwin"
+ date="2012-05-23T19:30:21Z"
+ content="""
+Windows support is a must. In my experience, binary file means proprietary editor, which means Windows.
+
+Unfortunately, there's not much overlap between people who use graphical editors in Windows all day vs. people who are willing to tolerate Cygwin's setup.exe, compile a Haskell program, learn git and git-annex's 90-odd subcommands, and use a mintty terminal to manage their repository, especially now that there's a sexy GitHub app for Windows.
+
+That aside, I think Windows-based content producers are still *the* audience for git-annex. First Windows support, then a GUI, then the world.
+"""]]
diff --git a/doc/todo/windows_support/comment_3_bd0a12f4c9b884ab8a06082842381a01._comment b/doc/todo/windows_support/comment_3_bd0a12f4c9b884ab8a06082842381a01._comment
new file mode 100644
index 0000000000..0b48db7502
--- /dev/null
+++ b/doc/todo/windows_support/comment_3_bd0a12f4c9b884ab8a06082842381a01._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://xolus.net/openid/max"
+ nickname="B0FH"
+ subject="What about NTFS support ?"
+ date="2012-08-02T17:45:10Z"
+ content="""
+Has git-annex been tested with an NTFS-formatted disk under Linux ? NTFS is supposed to be case-sensitive and to allow symlinks, and these are supposed to work with ntfs3g.
+"""]]
diff --git a/doc/todo/windows_support/comment_4_ad06b98b2ddac866ffee334e41fee6a8._comment b/doc/todo/windows_support/comment_4_ad06b98b2ddac866ffee334e41fee6a8._comment
new file mode 100644
index 0000000000..66f9ca71fd
--- /dev/null
+++ b/doc/todo/windows_support/comment_4_ad06b98b2ddac866ffee334e41fee6a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlc1og3PqIGudOMkFNrCCNg66vB7s-jLpc"
+ nickname="Paul"
+ subject="Re: What about NTFS support?"
+ date="2012-08-16T19:30:38Z"
+ content="""
+I successfully use git-annex on an NTFS formatted external USB drive, so yes, it is possible and works well.
+"""]]
diff --git a/doc/todo/windows_support/comment_5_444fc7251f57db241b6e80abae41851c._comment b/doc/todo/windows_support/comment_5_444fc7251f57db241b6e80abae41851c._comment
new file mode 100644
index 0000000000..8f76ee2587
--- /dev/null
+++ b/doc/todo/windows_support/comment_5_444fc7251f57db241b6e80abae41851c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/dASECLNzvckz4VwqUGYsvthiplY.#d2c27"
+ nickname="A. D. Sicks"
+ subject="comment 5"
+ date="2012-09-09T23:48:21Z"
+ content="""
+Haskell has C++ binding, so it should be possible to port it to .net/Mono with a VB GUI for Windows users.  Windows has a primitive form of symlinks called shortcuts.  Perhaps shortcut support in Windows could replace the use of symlinks.  I've used shortcuts since XP to put my home Windows directory on another partition and never had a hitch...
+
+If anyone is interested in working on this, hit me up.  I would like to use this in my XP vbox to have access to files on my host OS...I have a student edition of Visual Studio 2005 to do an open source port...
+"""]]
diff --git a/doc/todo/windows_support/comment_6_34f1f60b570c389bb1e741b990064a7e._comment b/doc/todo/windows_support/comment_6_34f1f60b570c389bb1e741b990064a7e._comment
new file mode 100644
index 0000000000..bf9f86f419
--- /dev/null
+++ b/doc/todo/windows_support/comment_6_34f1f60b570c389bb1e741b990064a7e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnlwEMhiNYv__mEUABW4scn83yMraC3hqE"
+ nickname="Sean"
+ subject="NTFS symlinks"
+ date="2013-01-11T21:44:21Z"
+ content="""
+It seems that NTFS (from Vista forward) has full POSIX support for symlinks. At least, Wikipedia [seems to think so.](http://en.wikipedia.org/wiki/NTFS_symbolic_link). What about doing like GitHub and using MinGW for compatibility? Cygwin absolutely blows in terms of installation size and compatability with the rest of Windows.
+"""]]
diff --git a/doc/todo/windows_support/comment_7_a5ca56c487257434650420acfa60e39f._comment b/doc/todo/windows_support/comment_7_a5ca56c487257434650420acfa60e39f._comment
new file mode 100644
index 0000000000..0ee09ac5a2
--- /dev/null
+++ b/doc/todo/windows_support/comment_7_a5ca56c487257434650420acfa60e39f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlpSOjMH7Iaz56v6Pr9KCFSpbvMXvg-y9o"
+ nickname="Dominik"
+ subject="So close :-)"
+ date="2013-06-30T12:46:40Z"
+ content="""
+I was fighting my way forward until I read here that special remote with ssh+rsync and encryption doesn't work. Interestingly I got everything working so far, ssh login is keybased, gpg -k works and the remote setup also correctly cooperated with gpg... but it just didn't sync. Any ideas how complex it is to get this last missing piece moving?
+"""]]
diff --git a/doc/todo/windows_support/comment_8_61214de7d967740d42905f3823ce2f65._comment b/doc/todo/windows_support/comment_8_61214de7d967740d42905f3823ce2f65._comment
new file mode 100644
index 0000000000..fe193f7e07
--- /dev/null
+++ b/doc/todo/windows_support/comment_8_61214de7d967740d42905f3823ce2f65._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.4.193"
+ subject="comment 8"
+ date="2013-06-30T17:58:08Z"
+ content="""
+It should be easy to fix whatever's wrong the the rsync special remote. Just a matter of debugging that.
+
+Adding encryption support on Windows is stuck at a roadblock I don't know the way around. To drive gpg, git-annex uses the `--passphrase-fd` option, and sends the \"passphrase\" (really a big block of binary foo!) over a file descriptor of a pipe that it set up.
+
+Windows, AFAIK, doesn't have file descriptors, or at least there is no equivilant to them that I have access to in the Haskell POSIX compatability layer for Windows. I am reluctant to fall back to using `--passphrase-file` on Windows, since that would be a massive security hole (as would passing the passphrase as a parameter via `--passphrase=`).
+"""]]
diff --git a/doc/todo/windows_support/comment_9_259a0b1a6f4d8d1944173380adc5e7c8._comment b/doc/todo/windows_support/comment_9_259a0b1a6f4d8d1944173380adc5e7c8._comment
new file mode 100644
index 0000000000..9ae337886e
--- /dev/null
+++ b/doc/todo/windows_support/comment_9_259a0b1a6f4d8d1944173380adc5e7c8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlpSOjMH7Iaz56v6Pr9KCFSpbvMXvg-y9o"
+ nickname="Dominik"
+ subject="comment 9"
+ date="2013-07-31T10:29:51Z"
+ content="""
+The tradeoff for me is a \"local\" security hole (where I can secure my own laptop) vs. a remotely exploitable thing... If it needs to go through a file, so be it -- it would however be good if that file would be overwritten with garbage before being deleted :-)
+"""]]
diff --git a/doc/todo/wishlist__58___--dry-run_option_for_all_commands.mdwn b/doc/todo/wishlist__58___--dry-run_option_for_all_commands.mdwn
new file mode 100644
index 0000000000..dd2a6263e5
--- /dev/null
+++ b/doc/todo/wishlist__58___--dry-run_option_for_all_commands.mdwn
@@ -0,0 +1,6 @@
+Could a --dry-run option be added to the git annex commands? Or, at least, to the most common ones like `git annex add`.
+
+Given that there is no undo command, it would be nice to have the ability to simulate what git annex will do.
+
+> [[wontfix|done]], see comments. Instead, options like --want-get and
+> --want-drop can be used to simulate things. --[[Joey]]
diff --git a/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_1_03bf493d5a7f957339f9aa388ba85ef8._comment b/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_1_03bf493d5a7f957339f9aa388ba85ef8._comment
new file mode 100644
index 0000000000..7725747388
--- /dev/null
+++ b/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_1_03bf493d5a7f957339f9aa388ba85ef8._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2014-11-03T16:44:45Z"
+ content="""
+This would add a lot of complexity; it's not like I could switch off
+running all external commands, since many external commands are run to
+query state to decide what to do. And then there's large chunks of code
+that actually do stuff and would have to all be guarded to not run.
+
+I don't see the benefit to justify this work. `git annex add` is entirely
+predictable; it's very similar to `git add`. Which itself lacks a dry-run
+option. And like `git add`, you can certianly undo the effects of `git
+annex add`.
+
+Matching options can make commands like `git annex find` list the same
+set of files that are acted on by commands like `git annex drop`
+(`git annex find --in here`)
+and `git annex get` (`git annex find --not --in here`).
+"""]]
diff --git a/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_2_8ac7ae6937d219854bc60b56b8646d8b._comment b/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_2_8ac7ae6937d219854bc60b56b8646d8b._comment
new file mode 100644
index 0000000000..d484d5559f
--- /dev/null
+++ b/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_2_8ac7ae6937d219854bc60b56b8646d8b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Chris"
+ avatar="http://cdn.libravatar.org/avatar/02b67b7ebace8cb6433504ba9a17d4a4"
+ subject="comment 2"
+ date="2018-10-20T08:09:40Z"
+ content="""
+Hm, IMHO such a “dry-run” flag would be most beneficial for better understanding the preferred/required content settings and try their effect while working on finding the right expression. Therefore, the “drop”, “get” and “sync --content” commands would benefit from such a flag, especially in combination with flags such as “--auto”. Maybe it's just me, but I am not able to utilize the “find” command in a way that it respects preferred content and numcopies and further settings in the same way as the three commands above would do, and testing preferred content expressions is therefore a blind flight.
+"""]]
diff --git a/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_3_411cabdfebe353d35f8dc78364f4a507._comment b/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_3_411cabdfebe353d35f8dc78364f4a507._comment
new file mode 100644
index 0000000000..a3d41b7244
--- /dev/null
+++ b/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_3_411cabdfebe353d35f8dc78364f4a507._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="git-annex.branchable.com@1c3a8a83c15a19620a0a1a2e653d7c662fc8fe50"
+ nickname="git-annex.branchable.com"
+ avatar="http://cdn.libravatar.org/avatar/fd46557ea8b9b21ae4ce66517076fbcb"
+ subject="get dry-run-ish option"
+ date="2019-01-11T16:18:13Z"
+ content="""
+You can find out what would be done by a get (ish), but running something like this:
+
+    git annex find --not --in here <path>
+
+..which will show files which are known about but aren't in this annexed copy.
+I've been using this to see what needs to be 'got' to a location.
+
+It does, however, need an annex repo to have a remote set up if you wish to check against it, as they aren't automatically bi-directional (which makes sense as firewalls and similar may not make this possible).
+"""]]
diff --git a/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_4_2824eb6fd3fe9a44d48639c38d478351._comment b/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_4_2824eb6fd3fe9a44d48639c38d478351._comment
new file mode 100644
index 0000000000..51b7f316ca
--- /dev/null
+++ b/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_4_2824eb6fd3fe9a44d48639c38d478351._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-04-23T20:13:39Z"
+ content="""
+`git annex find --want-get --not --in here` should simulate get --auto/sync well
+
+`git annex find --want-drop --in here` will simulate what drop --auto/sync would
+try to drop
+
+What would be nice to have is a way to simulate `copy --auto --to foo`
+and `drop --auto --from foo` which are of course also things sync does.
+That could be something like:
+
+	git annex find --want-get-by remote --not --in remote
+	git annex find --want-drop-by remote --in remote
+"""]]
diff --git a/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_5_e139434d88638d05c84b721abdbb406c._comment b/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_5_e139434d88638d05c84b721abdbb406c._comment
new file mode 100644
index 0000000000..9f2dc9aee4
--- /dev/null
+++ b/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_5_e139434d88638d05c84b721abdbb406c._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="Bump for --want-get/drop-by"
+ date="2022-07-26T18:19:36Z"
+ content="""
+Hi Joey,
+
+A million thanks for a fantastic tool.
+
+I came across the need today for the aforementioned  --want-get-by/ --want-drop-by REMOTE options. Is this something that has since been developed/worked around, or is it still in the infinite TODO?
+
+In the mean time, some more explicit documentation that --want-get/want-drop only ever applies to . would be good. I'll see if I can make a PR for this since I can write docs (but alas Haskell not so much).
+
+best,
+Kevin
+"""]]
diff --git a/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_6_cd430ea90286759eb5311ef376f63929._comment b/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_6_cd430ea90286759eb5311ef376f63929._comment
new file mode 100644
index 0000000000..0d21988e6d
--- /dev/null
+++ b/doc/todo/wishlist__58___--dry-run_option_for_all_commands/comment_6_cd430ea90286759eb5311ef376f63929._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-07-28T16:39:58Z"
+ content="""
+Thanks for the bump. I've implemented both.
+"""]]
diff --git a/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find.mdwn b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find.mdwn
new file mode 100644
index 0000000000..d997ca6e2c
--- /dev/null
+++ b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find.mdwn
@@ -0,0 +1,24 @@
+`git annex find` currently makes for a great way to find which files are already local, and don't need to get `git annex get` gotten; obviously `ls` just shows me all the files in a given directory, disregarding git-annex (and without recursing to subdirectories). I think that adding a '--maxdepth' option to `git annex find` would make it much easier to use at directories high up in the directory structure, since currently `git annex find` recurses all subdirectories necessarily, when I really just want to see whether or not there are git-annex files present from a given directory.
+
+Obviously, since directories themselves are not git-annex objects, there is no way to say whether or not they are "present", but perhaps the most intuitive would be to say whether or not any git-annex files under a given directory are present.
+
+For example, if I have:  
+./  
++-- subdir0/  
+|  +-- file0 (present in local git-annex repo)  
+|  +-- file1 (present in local git-annex repo)  
++-- subdir1/  
+|  +-- file0 (not present in local git-annex repo)  
+|  +-- file1 (not present in local git-annex repo)  
++-- file2 (present in local git-annex repo)  
+
+and I type `git annex find --maxdepth 1 .`, the output might look something like:  
+subdir0/  
+file2  
+
+rather than:  
+subdir0/file0  
+subdir0/file1  
+file2  
+
+> [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_1_c355878ac49bbb23a4cf82fe685da9ee._comment b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_1_c355878ac49bbb23a4cf82fe685da9ee._comment
new file mode 100644
index 0000000000..73d4cba5f8
--- /dev/null
+++ b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_1_c355878ac49bbb23a4cf82fe685da9ee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-21T17:28:53Z"
+ content="""
+`find --maxdepth` is a nice optimisation because it can short-circuit when it gets deep in the tree. However, `git annex find` is built on top of `git ls-files --cached`, which has no equivilant way to short-circuit. I am not sure if the format of the index makes it practical for it to get a --maxdepth option (it may need to traverse the whole index, or might be able to short-circuit).
+
+I don't see any point in adding a --matdepth to git-annex if it doesn't actually make it any faster, so getting such a thing into `git ls-files` would be the first step. So, suggest filing a feature request on git.
+"""]]
diff --git a/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_2_da30a066c4de465fe172ad01057e2380._comment b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_2_da30a066c4de465fe172ad01057e2380._comment
new file mode 100644
index 0000000000..944f36088e
--- /dev/null
+++ b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_2_da30a066c4de465fe172ad01057e2380._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlScsufvQF7s8TVTwPd-h_QiP5Hn_i-hrs"
+ nickname="Jason"
+ subject="comment 2"
+ date="2014-07-21T18:37:19Z"
+ content="""
+I see your point, `git ls-files` may still have to walk the whole tree, precluding a speed advantage.
+But I guess the point of what I was saying was more that a way summarize from a high level what is here and what is not would be nice.
+I certainly understand if this is not something you see as worthwhile, but if someone were inclined to write a patch (if ever I find the time) that would add a `--maxdepth` option that would merely summarize the results of `git annex find` would it be something you would be inclined to include in the main repo (providing, of course, that you find the behavior sensible)?
+"""]]
diff --git a/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_3_f3eadd6241f5cc2886515b2826dc5cf9._comment b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_3_f3eadd6241f5cc2886515b2826dc5cf9._comment
new file mode 100644
index 0000000000..8da436e09e
--- /dev/null
+++ b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_3_f3eadd6241f5cc2886515b2826dc5cf9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-07-21T18:40:00Z"
+ content="""
+I think that --maxdepth has a well-defined meaning and this summary option would need to be named something else.
+
+I don't object to the idea of implementing it. However, I don't know that it would be very easy to implement either.
+"""]]
diff --git a/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_4_c766c1465407324fc933db78be325b33._comment b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_4_c766c1465407324fc933db78be325b33._comment
new file mode 100644
index 0000000000..6025101e2e
--- /dev/null
+++ b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_4_c766c1465407324fc933db78be325b33._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlScsufvQF7s8TVTwPd-h_QiP5Hn_i-hrs"
+ nickname="Jason"
+ subject="good point"
+ date="2014-07-21T19:22:30Z"
+ content="""
+You make another good point `--maxdepth` is vague in this context...
+I guess if we were to decide to come up with a summary option, it will have be named something else, like `--summary-depth`, where the default would be to represent all files of whatever depth, and specifying the option would take the output that would otherwise get from `git annex find <opts>`, truncate the paths to a certain depth, and then make a set thereof (to remove the many dups), that way any directory that had any files that would have been output by `git annex find <opts>`, that would also be at or above a certain depth, would be listed.
+
+I think if I get a chance I'll try to implement something like this.
+
+"""]]
diff --git a/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_5_dcda795ff29de150ced0c839c85f7837._comment b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_5_dcda795ff29de150ced0c839c85f7837._comment
new file mode 100644
index 0000000000..20d2c3fd23
--- /dev/null
+++ b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_5_dcda795ff29de150ced0c839c85f7837._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-01-16T18:03:26Z"
+ content="""
+Occurs to me that you can do this with existing options, eg to filter
+out directories that are 3 or more deep:
+
+	git-annex find --exclude='*/*/*'
+
+It won't display subdirectories that contain filtered out files of course.
+
+It would also be easy enough to write a wrapper around `git-annex find`
+that processed its output and generated output like that.
+
+So I'm going to close this.
+"""]]
diff --git a/doc/todo/wishlist__58___Add_--byte-limit_option.mdwn b/doc/todo/wishlist__58___Add_--byte-limit_option.mdwn
new file mode 100644
index 0000000000..5c2c5fd50e
--- /dev/null
+++ b/doc/todo/wishlist__58___Add_--byte-limit_option.mdwn
@@ -0,0 +1,16 @@
+This option is related to `--time-limit`, but stops after processing X 
+bytes. For example, I often need to free up a certain amount of space on 
+a disk and want `git-annex move` to stop after it has copied a specified 
+amount of data:
+
+    git annex move --to otherdisk --byte-limit 3G
+    git annex drop --auto --byte-limit 500m
+    git annex get --byte-limit 500m
+
+I've been using some `annex.diskreserve` trickery now and then to 
+accomplish this, but it's a bit cumbersome and also not a very precise 
+way to specify the amount I want to copy/move/get. The last example 
+would also be a useful command to limit the traffic when I'm connecting 
+via mobile – get as much as possible, but don't blow the mobile quota.
+
+> [[done]] as --size-limit --[[Joey]]
diff --git a/doc/todo/wishlist__58___Freeing_X_space_on_remote_Y.mdwn b/doc/todo/wishlist__58___Freeing_X_space_on_remote_Y.mdwn
new file mode 100644
index 0000000000..b577c2ae69
--- /dev/null
+++ b/doc/todo/wishlist__58___Freeing_X_space_on_remote_Y.mdwn
@@ -0,0 +1,5 @@
+As suggested during the first Gitify BoF during DebConf13: Adding a way to have on-demand dropping of content in a given remote would allow a user to quickly free up disk space on demand while still heeding numcopies etc.
+
+> [[done]] as --size-limit. This does affect dropping, so eg
+> `git-annex drom --from foo --size-limit=10gb` frees up 10gb from remote
+> foo. --[[Joey]] 
diff --git a/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate.mdwn b/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate.mdwn
new file mode 100644
index 0000000000..127e4832e5
--- /dev/null
+++ b/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate.mdwn
@@ -0,0 +1,5 @@
+A big part of my online use is done via a low-speed connection over my mobile phone, this is limited to 16KB/sec because I always use up my 500MB quota the very first day of the month. `;-/` So when I need to download big files, I first download them to my online server, then transfer the files to my laptop with git-annex. If I'm connected via GSM, this occupies all the bandwidth and everything else moves like a heavily sedated slug. So if I want to work via VNC or SSH, I have to terminate ongoing transfers with Ctrl-C and then hopefully remember to restart it when I work locally. I know git-annex is robust enough to handle this gracefully, but it would be really nice to have a continuous connection going on in the background, limited to a value I choose.
+
+rsync(1) has a `--bwlimit` (bandwidth limit) where you can specify max download/upload speed in kilobytes/sec. It would be great if a similar option was integrated into git-annex. Thanks in advance.
+
+> [[done]] generally as annex.bwlimit and related options. --[[Joey]]
diff --git a/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_1_4fd870e14b5b70c8a6ade41406294387._comment b/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_1_4fd870e14b5b70c8a6ade41406294387._comment
new file mode 100644
index 0000000000..78ca76939a
--- /dev/null
+++ b/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_1_4fd870e14b5b70c8a6ade41406294387._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="trickle"
+ date="2013-01-22T22:44:52Z"
+ content="""
+not exactly integrated, but you can easily use trickle for this.
+
+    trickle -d 50 git annex ...
+"""]]
diff --git a/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_2_dd854f297ad6a94b54be9f3edfd0f766._comment b/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_2_dd854f297ad6a94b54be9f3edfd0f766._comment
new file mode 100644
index 0000000000..70f04c6168
--- /dev/null
+++ b/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_2_dd854f297ad6a94b54be9f3edfd0f766._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://sunny256.sunbase.org/"
+ nickname="sunny256"
+ subject="Yay, trickle works"
+ date="2013-01-23T01:36:21Z"
+ content="""
+Justin, thanks a lot! trickle(1) works great. I didn't know about this program, but I'm not surprised that such a program is available. It never ceases to amaze me what's possible in a *NIX environment.
+"""]]
diff --git a/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_3_a8b7e90a473d5937807cc7eb456efe33._comment b/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_3_a8b7e90a473d5937807cc7eb456efe33._comment
new file mode 100644
index 0000000000..a5f8f6a1bf
--- /dev/null
+++ b/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_3_a8b7e90a473d5937807cc7eb456efe33._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="2001:4978:f:21a::2"
+ subject="comment 3"
+ date="2013-01-24T01:55:10Z"
+ content="""
+In addition to trickle, the git-annex man page has examples of how to make rsync use --bwlimit
+
+Something like trickle is needed to limit rates for remotes not using rsync, however.
+"""]]
diff --git a/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_4_53c43e480a37b20bc8fed9d38527651b._comment b/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_4_53c43e480a37b20bc8fed9d38527651b._comment
new file mode 100644
index 0000000000..9b2cb64bf7
--- /dev/null
+++ b/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_4_53c43e480a37b20bc8fed9d38527651b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="gerzoyayde@85d55f6dec266753698f42d1c8e06917ef6674a3"
+ nickname="gerzoyayde"
+ avatar="http://cdn.libravatar.org/avatar/0866019bf4d6741b2f4a2c288356513f"
+ subject="annex.bwlimit and jobs"
+ date="2023-03-28T00:00:43Z"
+ content="""
+Does annex.bwlimit limit across multiple jobs? E.g. I have a annex.bwlimit of \"30MiB\" and run a copy with --jobs 3, will the maximum possible bandwidth be 30MB/s or 90MB/s?
+"""]]
diff --git a/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_5_428d638e1f41d84df7e6c51675fe65da._comment b/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_5_428d638e1f41d84df7e6c51675fe65da._comment
new file mode 100644
index 0000000000..232eda99e0
--- /dev/null
+++ b/doc/todo/wishlist__58___Option_to_specify_max_transfer_rate/comment_5_428d638e1f41d84df7e6c51675fe65da._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2023-03-28T16:10:43Z"
+ content="""
+annex.bwlimit is the limit for each transfer, it doesn't take into account
+how many transfers might be running whether by --jobs or multiple git-annex
+processes.
+"""]]
diff --git a/doc/todo/wishlist__58___Parity_files_for_encrypted_remotes.mdwn b/doc/todo/wishlist__58___Parity_files_for_encrypted_remotes.mdwn
new file mode 100644
index 0000000000..34f06ad633
--- /dev/null
+++ b/doc/todo/wishlist__58___Parity_files_for_encrypted_remotes.mdwn
@@ -0,0 +1,7 @@
+I have data that has accompanying parity files.  This is supposed to add some
+security to file integrity; however, it only works as long as the files are
+available unencrypted.  In case of encrypted special remotes the existing parity files
+won't be of any use if the encrypted versions of files get corrupted in the remote location.
+
+Would it be worthwhile for git-annex to generate its own
+parity files for the encrypted data in encrypted special remotes?
diff --git a/doc/todo/wishlist__58___Parity_files_for_encrypted_remotes/comment_1_5fbffd74f9d89857b807093cd7a5941e._comment b/doc/todo/wishlist__58___Parity_files_for_encrypted_remotes/comment_1_5fbffd74f9d89857b807093cd7a5941e._comment
new file mode 100644
index 0000000000..b440d64d2f
--- /dev/null
+++ b/doc/todo/wishlist__58___Parity_files_for_encrypted_remotes/comment_1_5fbffd74f9d89857b807093cd7a5941e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="git-annex@31849d241f10c295b30a9707352ae5c7d743adb7"
+ nickname="git-annex"
+ avatar="http://cdn.libravatar.org/avatar/180f1a763647bfc099e97ac88b8f7b37"
+ subject="comment 1"
+ date="2017-03-02T16:16:05Z"
+ content="""
+If you're generating parity files for the content anyway, why not encrypt locally, generate parity files for the encrypted content, then check that in to git-annex?
+"""]]
diff --git a/doc/todo/wishlist__58___Restore_s3_files_moved_to_Glacier.mdwn b/doc/todo/wishlist__58___Restore_s3_files_moved_to_Glacier.mdwn
new file mode 100644
index 0000000000..85fc2785c4
--- /dev/null
+++ b/doc/todo/wishlist__58___Restore_s3_files_moved_to_Glacier.mdwn
@@ -0,0 +1,7 @@
+I would like to use the automated AWS lifecycle rules to move the git annex files store on S3 to Glacier after a bit of time. Git annex need must support this kind of S3 files explicitly in order for it to work.
+
+This is different from the adding a Glacier remote to git annex because of the reasons explained in <http://aws.typepad.com/aws/2012/11/archive-s3-to-glacier.html>.
+
+Basically, the files moved by AWS from S3 to Glacier are not available under the normal Glacier API. In fact, the moved S3 files are listed as available but under the `GLACIER` storage class and need a RESTORE request before they can be GET like other S3 files. Trying to GET an S3 file that has been moved to Glacier will not restore it from Glacier and will result in an 403 error.
+
+I suppose DELETE needs special care as well.
diff --git a/doc/todo/wishlist__58___Restore_s3_files_moved_to_Glacier/comment_1_eb934756cb2af7fa13ad3b5fad7f85b2._comment b/doc/todo/wishlist__58___Restore_s3_files_moved_to_Glacier/comment_1_eb934756cb2af7fa13ad3b5fad7f85b2._comment
new file mode 100644
index 0000000000..92554aa318
--- /dev/null
+++ b/doc/todo/wishlist__58___Restore_s3_files_moved_to_Glacier/comment_1_eb934756cb2af7fa13ad3b5fad7f85b2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
+ nickname="Ovidiu"
+ subject="Keen to see this happen too!"
+ date="2014-05-08T21:44:30Z"
+ content="""
+Or alternatively support for S3 Lifecycle Rules. 
+I'm not exactly sure what git-annex assistant does if it backs up into a S3 bucket with i.e. a rule to archive everything 1 month later into Glacier. Can it restore/access?
+"""]]
diff --git a/doc/todo/wishlist__58_____39__get__39___queue_and_schedule.mdwn b/doc/todo/wishlist__58_____39__get__39___queue_and_schedule.mdwn
new file mode 100644
index 0000000000..8166479b8b
--- /dev/null
+++ b/doc/todo/wishlist__58_____39__get__39___queue_and_schedule.mdwn
@@ -0,0 +1,32 @@
+During the campaign adding a chunking feature to obscure filesize for encrypted files was added to the roadmap.  But there is still one potentially valuable set* of data that git-annex can help obscure: when you access your remotes.
+
+This data can be used to determine when a user is actively using a remote, but if a remote is always accessed at the same time that data becomes less useful.  Somebody could still monitor total traffic over a long period and figure out that a remote was more active in a given week or month, but scheduling reduces the resolution of your access times and their data.  Maybe this isn't the most important feature to add, but it would be nice to have, and could possibly be built on top of the existing git-annex scheduler.  It could work by queuing inter-remote transactions ('get', 'copy', 'sync', etc.), so that jobs start at the same time every day, or even the same time and day every week.
+
+Possible syntax examples:
+###Setting up the schedule:
+git annex queue schedule Monday:1730 (starts every monday at 5:30PM)
+
+git annex queue schedule 1400 (starts every day at 2PM)
+
+###Queuing git-annex commands:
+git annex queue prepend sync (pretends 'sync' to the very front of the queue)
+
+git annex queue append get file.ISO (appends to queue file.ISO for retrieval from a repo)
+
+###Viewing/editing queue:
+git annex queue view (view the current queue, jobs displayed with corresponding numbers)
+
+git annex queue rm 20 (removes job 20 from queue)
+
+
+\*The four I can think of are:
+
+* File contents (solved by crypto)
+
+* File size (solved on the remote by chunking, but total traffic usage can't be helped)
+
+* User IP/Remote IP (solved by VPN - outside scope of git-annex, unless someone writes a plugin)
+
+* Access times (obscured by a queue and scheduling)
+
+Note, there is a [[git-annex-schedule]] command now, but it only does `fsck`.
diff --git a/doc/todo/wishlist__58_____39__get__39___queue_and_schedule/comment_1_d6ab311beee2ce5f73ae325a4ae463d4._comment b/doc/todo/wishlist__58_____39__get__39___queue_and_schedule/comment_1_d6ab311beee2ce5f73ae325a4ae463d4._comment
new file mode 100644
index 0000000000..df273afb2c
--- /dev/null
+++ b/doc/todo/wishlist__58_____39__get__39___queue_and_schedule/comment_1_d6ab311beee2ce5f73ae325a4ae463d4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="how does the queue get built now?"
+ date="2015-04-28T21:32:36Z"
+ content="""
+how does the queue get created now? is it random or is there some deterministic thing that could be abuse to prioritise some content already (say alphabetical order or some similar hack)?
+
+the scheduling I think i can work around with clunky cron jobs to start/stop the assistant, but the queue I feel is a different beast. would you be available for hire to implement this feature in priority?
+
+thanks!
+"""]]
diff --git a/doc/todo/wishlist__58_____39__get__39___queue_and_schedule/comment_2_c2e9ab3ff49c22f27dd800512e7b7961._comment b/doc/todo/wishlist__58_____39__get__39___queue_and_schedule/comment_2_c2e9ab3ff49c22f27dd800512e7b7961._comment
new file mode 100644
index 0000000000..13c0fbd835
--- /dev/null
+++ b/doc/todo/wishlist__58_____39__get__39___queue_and_schedule/comment_2_c2e9ab3ff49c22f27dd800512e7b7961._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-01-16T17:48:04Z"
+ content="""
+This never got followed up on, but there is no queue currently.
+
+I dunno, this feels like something that can be implemented outside of
+git-annex with a cron job or what have you.
+"""]]
diff --git a/doc/todo/wishlist__58_____39__whereis__39___support_in_the_webapp.mdwn b/doc/todo/wishlist__58_____39__whereis__39___support_in_the_webapp.mdwn
new file mode 100644
index 0000000000..c074988b08
--- /dev/null
+++ b/doc/todo/wishlist__58_____39__whereis__39___support_in_the_webapp.mdwn
@@ -0,0 +1,4 @@
+I've looked for this feature in the webapp but can't find it...
+
+I mainly use the webapp and have been wondering 'how many copies of file X are there' and 'where are the copies of file Y'?
+This is available in the commandline interface but it would be nice to have this in the webapp too.
diff --git a/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__.mdwn b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__.mdwn
new file mode 100644
index 0000000000..626f5a03f9
--- /dev/null
+++ b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__.mdwn
@@ -0,0 +1,5 @@
+Also suggested during the first Gitify BoF during DebConf13:
+
+`git annex drop` deletes immediately. In some situations a mechanism to tell git-annex "I would like to hold onto this data if possible, but if you need the space, please delete it" could be nice.
+
+An obvious question would be how to do cleanups. With the assistant, that's easy. On CLI, at the very least `git annex fsck` should list, and optionally delete, that data.
diff --git a/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_1_c83a6cddd0ce222205a149cfa41ca395._comment b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_1_c83a6cddd0ce222205a149cfa41ca395._comment
new file mode 100644
index 0000000000..32d0c01126
--- /dev/null
+++ b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_1_c83a6cddd0ce222205a149cfa41ca395._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://cstork.org/"
+ nickname="Chris Stork"
+ subject="How should this interact with the trust model and location tracking?"
+ date="2013-10-04T11:13:11Z"
+ content="""
+This could become complicated.  AFAIU, right now git-annex keeps track of files as either present or absent.  With this feature it's tempting to introduce a third state 'potentially dropped' (or 'dropped in a relaxed fashion') but do you then treat them as if they were dropped depending in wether they are on a trusted or untrusted repo?  Or maybe a potentially dropped file in a trusted repo is treated as a file in a semitrusted repo?  This becomes convoluted.  You also need a command to undrop a file in case you decide that you really want to keep it and in order to do this you need a command to see which files are up for relaxed dropping....
+
+As an alternative approach maybe it makes sense to extend [[preferred content]] expressions to take file sizes and disk usage into account.
+"""]]
diff --git a/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_2_353fbc2bcc40cb8c9af42907a34c6e5a._comment b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_2_353fbc2bcc40cb8c9af42907a34c6e5a._comment
new file mode 100644
index 0000000000..40f299fa02
--- /dev/null
+++ b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_2_353fbc2bcc40cb8c9af42907a34c6e5a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.243"
+ subject="comment 2"
+ date="2013-10-04T20:17:07Z"
+ content="""
+I don't think that a third state would be necessary. Actually dropping the file when it happens would need to do the same numcopies verification that `git annex drop` does now.
+
+I agree it might be simpler to first improve the power of preferred content expressions. Unfortunately one thing that cannot be put in them is anything that probes the current state of the system. This is because repo A on machine X needs to be able to calculate the preferred content of repo B on machine Y.
+But I could certainly add file size as a preferred content term, since that info is known throughout the network.
+"""]]
diff --git a/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_3_3e830035df580601f038ce3a7003c39d._comment b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_3_3e830035df580601f038ce3a7003c39d._comment
new file mode 100644
index 0000000000..8b4b132cba
--- /dev/null
+++ b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_3_3e830035df580601f038ce3a7003c39d._comment
@@ -0,0 +1,63 @@
+[[!comment format=mdwn
+ username="erics"
+ ip="76.10.136.8"
+ subject="comment 3"
+ date="2014-05-04T00:48:55Z"
+ content="""
+I think things would be simpler if a \"drop --relaxed\" file were to look to
+the outside world just like one that was dropped without \"--relaxed\".
+In particular, even if a file is dropped with \"--relaxed\":
+
+  - the file's work-tree symlink should be broken synchronously by the
+   \"drop --relaxed\" command (as opposed to only being broken later,
+   if and when the file physically goes away)
+
+  - other repos should no longer see the file as available from this repo
+
+Basically, the idea is to add a third state, but **not** a user-visible one.
+Rather, it should be a well hidden implementation detail, which doesn't
+affect the conceptual model (very much like git's own distinction between
+loose and packed objects).  Thus, *logically dropped* would be a
+better name than *potentially dropped*.
+
+Corollaries:
+
+  - A logically (but not physically) dropped file should *not* count towards
+    satisfying the numcopies limit, i.e. if some other repo has been asked
+    to drop the file too
+
+  - That in turn means that \"git annex drop --relaxed\" needs to satisfy a
+    numcopies check at the time the user runs it; it's not enough to only do
+    the check later, at physical-deletion time.  (At that point, there should probably be
+    a second numcopies check.  I don't know whether the model requires it,
+    but even if not, paranoia is good :-) )
+
+  - If the user wants to use the file again, they have to \"git annex get\" it
+    again, just like usual -- but if the file hasn't been physically deleted yet,
+    the \"get\" will be nearly instantaneous, since the data won't have to be copied
+
+One possible implementation would be to have \"drop --relaxed\" behave almost identically
+to a non-relaxed drop -- do all the same safety checks, bookkeeping, etc.  The only
+difference would be to have it rename the file at the end, rather
+than deleting it outright.  (Logically dropped files could stay in their same
+directory, but with a distinguishing filename, or they could be moved to a
+parallel tree, e.g. *.git/annex/dropped*.  I don't have an opinion on that choice;
+I've just picked one arbitrarily to keep talking about.)
+
+\"get\" would simply search .git/annex/dropped before going off to remote
+repos, and if the file is found there, would move (not copy) it back into
+.git/annex/objects.
+
+An alternative might be to set some kind of *logically dropped* flag, but
+that would probably be a much more intrusive change; a lot of places in the
+code would have to check the flag.  Doing it as a file rename would make for a much more
+localized change; most of git-annex would completely ignore .git/annex/dropped, and just go
+about its business as it has always done.
+
+(It might be tempting to think of (or even implement) .git/annex/dropped as a
+very low-cost remote, but that's not accurate; the semantics are different.)
+
+I'm just starting to experiment with git-annex, so I can only hope that what 
+I'm saying isn't completely silly...
+
+"""]]
diff --git a/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_4_e5516689bc128c061dcd66649dc69584._comment b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_4_e5516689bc128c061dcd66649dc69584._comment
new file mode 100644
index 0000000000..3e2d6689c2
--- /dev/null
+++ b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_4_e5516689bc128c061dcd66649dc69584._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="216.145.95.162"
+ subject="comment 4"
+ date="2014-05-19T16:56:15Z"
+ content="""
+erics, that all makes a lot of sense, except I don't know if there's actually a use case for a git-annex that behaves that way. It doesn't seem to solve the original use case.
+
+I'd be inclinded to instead use the new metadata support. A file could have a tag that indicates it's not strongly wanted, and if git-annex get doesn't have enough space it could seek out and drop such files.
+"""]]
diff --git a/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_5_be740e4b06d9130ae6afc5783da3c0e0._comment b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_5_be740e4b06d9130ae6afc5783da3c0e0._comment
new file mode 100644
index 0000000000..32beef4271
--- /dev/null
+++ b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_5_be740e4b06d9130ae6afc5783da3c0e0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="erics"
+ ip="76.10.136.8"
+ subject="comment 5"
+ date="2014-06-03T17:49:10Z"
+ content="""
+> It doesn't seem to solve the original use case.
+
+It doesn't?  The OP requested:
+
+> I would like to hold onto this data if possible, but if you need the space, please delete it
+
+It looks to me as though my suggestion does just that -- or am I misunderstanding what they asked for?
+"""]]
diff --git a/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_6_79d115f95cec46bb51e7fba078524db1._comment b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_6_79d115f95cec46bb51e7fba078524db1._comment
new file mode 100644
index 0000000000..6e376e3167
--- /dev/null
+++ b/doc/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/comment_6_79d115f95cec46bb51e7fba078524db1._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="erics"
+ ip="76.10.136.8"
+ subject="Metadata vs &quot;drop --relaxed&quot;"
+ date="2014-06-03T18:20:50Z"
+ content="""
+[This isn't as much about my suggested implementation for \"drop --relaxed\" as about whether the feature is worth providing in the first place.  I'm not arguing strongly for it, actually; just continuing the discussion.]
+
+> I'd be inclinded to instead use the new metadata support.
+
+I see metadata as more for static attributes of a given file -- this thing is \"a picture\", \"related to project X\", \"from Mary\".  Thus, the combination of metadata plus preferred-content settings seems to me more suitable for static preferences (likely ones that implement some kind of policy, however informal); e.g. \"this repo wants pictures but not mp3s\", or \"Mary's stuff but not Alex's\".
+
+\"drop --relaxed\", on the other hand, would be good for more ad-hoc usage: \"disk space is getting tight; hmm, I'm not using *foo* today, so git-annex, please delete my local copy of *${myrepo}/foo* -- but only as much as you have to, because I'm going to want it again tomorrow\".
+
+One reason not to want to use metadata and preferred-content settings for such short-term, ad-hoc needs is that you then have to remember to go undo the changes later.  That's even worse if you had to add ad-hoc metadata, and now have to go delete it all again.  Undoing a \"drop --relaxed\", on the other hand, consists of a simple \"git annex get\".
+
+"""]]
diff --git a/doc/todo/wishlist__58_____96__git_annex_optimize__96__.mdwn b/doc/todo/wishlist__58_____96__git_annex_optimize__96__.mdwn
new file mode 100644
index 0000000000..3f7fc0edfc
--- /dev/null
+++ b/doc/todo/wishlist__58_____96__git_annex_optimize__96__.mdwn
@@ -0,0 +1,12 @@
+Given [this tip](https://git-annex.branchable.com/forum/__34__git_annex_sync__34___synced_after_8_hours/#comment-890ca1381d800ac833ccbb8c5db175ea), [this comment](https://git-annex.branchable.com/todo/wishlist:_rsync_efficiency/#comment-870ae805efd35343edefdbed792dac04) and possibly others, it would be nice if git-annex could look at any given repo and make suggestions for improvements. As a second step, it could look at remotes as well. And as a third, maybe even change repo settings and not just make suggestions.
+
+Having a few old repos with terabytes of data on various disks, I would just toss this stanza into my mr templates to eventually optimize all my repos to current best practices.
+
+
+-- Richard
+
+> One of those was fixed by improvements to git-annex, the other
+> is not something that a command like the mooted one would be able to
+> safely do since it has to happen at repository init time.
+> 
+> [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/wishlist__58___allow_custom_S3_url_in_webapp.mdwn b/doc/todo/wishlist__58___allow_custom_S3_url_in_webapp.mdwn
new file mode 100644
index 0000000000..2d291608b0
--- /dev/null
+++ b/doc/todo/wishlist__58___allow_custom_S3_url_in_webapp.mdwn
@@ -0,0 +1,3 @@
+It is now relatively easy to build your own S3-compatible storage system with software such as Ceph radosgw or Openstack Swift.
+
+So a way for users to specify their own S3 url would come pretty handy in the webapp's "add S3 remote" page.
diff --git a/doc/todo/wishlist__58___allow_custom_S3_url_in_webapp/comment_1_3d1ea5579a6ad0c0efde58dca11c10aa._comment b/doc/todo/wishlist__58___allow_custom_S3_url_in_webapp/comment_1_3d1ea5579a6ad0c0efde58dca11c10aa._comment
new file mode 100644
index 0000000000..b6125fd6eb
--- /dev/null
+++ b/doc/todo/wishlist__58___allow_custom_S3_url_in_webapp/comment_1_3d1ea5579a6ad0c0efde58dca11c10aa._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.227"
+ subject="comment 1"
+ date="2013-12-29T20:16:43Z"
+ content="""
+Such S3 clones are supported if you make the repository at the command line. See [[S3_special_remote_documentation|special_remotes/S3]].
+
+I think the question comes down to, is it worth adding UI in the webapp for this, or is it likely that someone who is using a S3 clone knows the endpoint url to use? Similarly, the webapp only offers box.com as a WebDAV remote, although there are many other DAV servers. What I'm trying to do with the UI is guide the user through finding a place to store their data, and covering every step as easily as possible.
+"""]]
diff --git a/doc/todo/wishlist__58___allow_custom_S3_url_in_webapp/comment_2_f96bb81fde4185368dc6ea5a5aed87da._comment b/doc/todo/wishlist__58___allow_custom_S3_url_in_webapp/comment_2_f96bb81fde4185368dc6ea5a5aed87da._comment
new file mode 100644
index 0000000000..bd3885a966
--- /dev/null
+++ b/doc/todo/wishlist__58___allow_custom_S3_url_in_webapp/comment_2_f96bb81fde4185368dc6ea5a5aed87da._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkgy5Qf4bivpTfYPw_yh92OcDlesrVTREg"
+ nickname="François"
+ subject="comment 2"
+ date="2014-01-12T20:31:44Z"
+ content="""
+I understand your concerns about keeping the UI straightforward.
+
+It makes sense however to allow users to add a custom backend without using the CLI. What about a new \"Custom backend (expert only)\" option which directly asks for a string with the arguments to 'git annex initremote'?
+"""]]
diff --git a/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads.mdwn b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads.mdwn
new file mode 100644
index 0000000000..8b13789179
--- /dev/null
+++ b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads.mdwn
@@ -0,0 +1 @@
+
diff --git a/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_1_36ae3c75053d5ec278b5e6eb2084d57a._comment b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_1_36ae3c75053d5ec278b5e6eb2084d57a._comment
new file mode 100644
index 0000000000..4c20561c75
--- /dev/null
+++ b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_1_36ae3c75053d5ec278b5e6eb2084d57a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2012-09-25T23:55:44Z"
+ content="""
+You know about `git annex addurl` right?  It doesn't help with the browser integration (though I bet there are existing download manager extensions you could re-use for this) but it takes care of the other use cases.
+"""]]
diff --git a/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_3_be8eb800523db8cf7a2c68a28fbf5ea5._comment b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_3_be8eb800523db8cf7a2c68a28fbf5ea5._comment
new file mode 100644
index 0000000000..c958fd08f7
--- /dev/null
+++ b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_3_be8eb800523db8cf7a2c68a28fbf5ea5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://m-f-k.myopenid.com/"
+ ip="93.207.162.28"
+ subject="+1"
+ date="2012-10-05T20:00:31Z"
+ content="""
+Copy+Paste+Open is to much for lazy people like me;)  I like the idea of a direct browser download manager integration.  This would make it so much easier to find find the original source of a downloaded file when you're to lazy to write it down somewhere in the first place …
+"""]]
diff --git a/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_3_d9f725de41a8572c85e4c6d9b4bcc927._comment b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_3_d9f725de41a8572c85e4c6d9b4bcc927._comment
new file mode 100644
index 0000000000..30515a49b5
--- /dev/null
+++ b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_3_d9f725de41a8572c85e4c6d9b4bcc927._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://lj.rossia.org/users/imz/"
+ ip="79.165.56.162"
+ subject="the scheme to follow to use the addurl command is longer"
+ date="2012-09-26T00:07:11Z"
+ content="""
+Justin, yes, I know. To use [[addurl|tips/using the web as a special remote]], I should force myself not to click on a link to view it, but rather to copy it, paste into the command line with addurl (then it will be downloaded, and I can run a command to view it...). Not terrible, probably learnable.
+"""]]
diff --git a/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_4_f52492e4cc6f965515800bd1c0e05c90._comment b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_4_f52492e4cc6f965515800bd1c0e05c90._comment
new file mode 100644
index 0000000000..7efd583c0f
--- /dev/null
+++ b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_4_f52492e4cc6f965515800bd1c0e05c90._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andy"
+ ip="99.48.75.171"
+ subject="I've just written a script that does this (with a Firefox download manager)"
+ date="2013-04-09T02:51:26Z"
+ content="""
+So I've just written a two-line shell script that makes [FlashGot](http://flashgot.net/) able to do this. It's available on GitHub at <https://gist.github.com/andyg0808/5342434>.
+
+This could be even neater if Git-annex had the ability to set the download manager... Wishlist created: [[wishlist:_allow_configuration_of_downloader_for_addurl]]
+"""]]
diff --git a/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_5_5b36656fc5fa124e763f06711d9da32b._comment b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_5_5b36656fc5fa124e763f06711d9da32b._comment
new file mode 100644
index 0000000000..494aab7a80
--- /dev/null
+++ b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_5_5b36656fc5fa124e763f06711d9da32b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 5"
+ date="2013-04-09T03:36:29Z"
+ content="""
+Wishlist implemented ;)
+
+A full example of doing this would make a nice addition to [[tips]] ...
+"""]]
diff --git a/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_6_285215a4466806baf85b8606f680494a._comment b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_6_285215a4466806baf85b8606f680494a._comment
new file mode 100644
index 0000000000..d0545153f9
--- /dev/null
+++ b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_6_285215a4466806baf85b8606f680494a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 6"
+ date="2013-04-11T15:12:00Z"
+ content="""
+See [[tips/Using_Git-annex_as_a_web_browsing_assistant]].
+
+I am leaving this bug open for now, as some javascript that passes the url off to the webapp is still a nice idea to build.
+
+A solution to the webapp's url always changing could be to have a file:/// url that the webapp creates, and javascript submits to, that then passes the request off to the webapp, probably by using additional javadcript in the html file. Assuming javascript security allows this.
+"""]]
diff --git a/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_7_15bf62e46db4b84ed3156f550f03de42._comment b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_7_15bf62e46db4b84ed3156f550f03de42._comment
new file mode 100644
index 0000000000..484db1e818
--- /dev/null
+++ b/doc/todo/wishlist__58___an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_7_15bf62e46db4b84ed3156f550f03de42._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 7"
+ date="2013-04-11T15:41:16Z"
+ content="""
+A less round-about method would be to have the webapp listen for links dropped into its page. You could then have the webapp open in a tab, and just drag urls there to add them to the annex.
+
+I'm not sure if it's possible to intercept drags into a tab. Default browser behavior is certainly to redirect the tab to the url dropped into it.
+
+If someone finds out how to do this, I will build it.
+"""]]
diff --git a/doc/todo/wishlist__58___annex.largefiles_configuration_in_webapp_and_sync.mdwn b/doc/todo/wishlist__58___annex.largefiles_configuration_in_webapp_and_sync.mdwn
new file mode 100644
index 0000000000..ce0a6161af
--- /dev/null
+++ b/doc/todo/wishlist__58___annex.largefiles_configuration_in_webapp_and_sync.mdwn
@@ -0,0 +1,4 @@
+The `annex.largefiles` feature is very nice to mix annexed files with normal git managed files. I'd like to be able to configure this setting on the webapp and that the configuration directive would be synchronized accross all remotes.
+
+> annex.largefiles can be configured in .gitattributes or by `git-annex
+> config` and will sync across remotes either way. [[done]] 
diff --git a/doc/todo/wishlist__58___annex.largefiles_configuration_in_webapp_and_sync/comment_1_db632de391ce9fce42af51a770ed3aeb._comment b/doc/todo/wishlist__58___annex.largefiles_configuration_in_webapp_and_sync/comment_1_db632de391ce9fce42af51a770ed3aeb._comment
new file mode 100644
index 0000000000..e402d26c3b
--- /dev/null
+++ b/doc/todo/wishlist__58___annex.largefiles_configuration_in_webapp_and_sync/comment_1_db632de391ce9fce42af51a770ed3aeb._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-05T16:46:28Z"
+ content="""
+It might make sense to sync this across remotes and have it edited with `git annex vicfg`
+
+Putting it in the webapp would need some nice interface for constructing the underlying expression. Might be doable for at least simple filtering (ie, files larger than XX or with extensions .A, .B, .C). I tend to think of this as a setting for people comfortable with the command line though.
+"""]]
diff --git a/doc/todo/wishlist__58___annex.largefiles_configuration_in_webapp_and_sync/comment_2_4a0931d9884054d764fde315d4fe4851._comment b/doc/todo/wishlist__58___annex.largefiles_configuration_in_webapp_and_sync/comment_2_4a0931d9884054d764fde315d4fe4851._comment
new file mode 100644
index 0000000000..0e24014d21
--- /dev/null
+++ b/doc/todo/wishlist__58___annex.largefiles_configuration_in_webapp_and_sync/comment_2_4a0931d9884054d764fde315d4fe4851._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawne_amN4fko4p5cRY_9EYwaYuJKNn7LRio"
+ nickname="Tobias"
+ subject="feedback"
+ date="2013-11-05T21:23:11Z"
+ content="""
+> It might make sense to sync this across remotes and have it edited with git annex vicfg
+
+That would be great!
+
+> Putting it in the webapp would need some nice interface for constructing the underlying expression. Might be doable for at least simple filtering (ie, files larger than XX or with extensions .A, .B, .C). I tend to think of this as a setting for people comfortable with the command line though.
+
+I could live with a simple filtering interface without too many fancy stuff. The fancy stuff could be done on the command line if needed...
+"""]]
diff --git a/doc/todo/wishlist__58___archive_from_remote_with_the_least_free_space.mdwn b/doc/todo/wishlist__58___archive_from_remote_with_the_least_free_space.mdwn
new file mode 100644
index 0000000000..acc8b363e2
--- /dev/null
+++ b/doc/todo/wishlist__58___archive_from_remote_with_the_least_free_space.mdwn
@@ -0,0 +1 @@
+An interesting feature, when an archived file cannot be removed from all clients because of the minimum number of copies required, would be to remove it from the repositories with the smallest amount of free space available.
diff --git a/doc/todo/wishlist__58___archive_from_remote_with_the_least_free_space/comment_1_6813fdc7ecc98765a5d35d34163a1712._comment b/doc/todo/wishlist__58___archive_from_remote_with_the_least_free_space/comment_1_6813fdc7ecc98765a5d35d34163a1712._comment
new file mode 100644
index 0000000000..89fe4c0690
--- /dev/null
+++ b/doc/todo/wishlist__58___archive_from_remote_with_the_least_free_space/comment_1_6813fdc7ecc98765a5d35d34163a1712._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.14.105"
+ subject="comment 1"
+ date="2013-09-19T21:01:30Z"
+ content="""
+That might be useful in some cases. git-annex can only tell how much free space is available on remotes that are mounted to the local filesystem. Did you use case involve removable drives?
+"""]]
diff --git a/doc/todo/wishlist__58___archive_from_remote_with_the_least_free_space/comment_2_21a249cedca1ceb80d10784004735524._comment b/doc/todo/wishlist__58___archive_from_remote_with_the_least_free_space/comment_2_21a249cedca1ceb80d10784004735524._comment
new file mode 100644
index 0000000000..d2b29c2396
--- /dev/null
+++ b/doc/todo/wishlist__58___archive_from_remote_with_the_least_free_space/comment_2_21a249cedca1ceb80d10784004735524._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmOsy6nbvPyXLd--qqjPMLnVIzxgZwtKlQ"
+ nickname="Nicolas"
+ subject="comment 2"
+ date="2013-09-20T19:03:13Z"
+ content="""
+I was not thinking of removable drives, but only of \"client\" repositories. Ideally, git-annex would query the remaining space of all connected client repositories to choose on which repositories to drop a copy.
+"""]]
diff --git a/doc/todo/wishlist__58___assistant_logging_improvements.mdwn b/doc/todo/wishlist__58___assistant_logging_improvements.mdwn
new file mode 100644
index 0000000000..bbc3588012
--- /dev/null
+++ b/doc/todo/wishlist__58___assistant_logging_improvements.mdwn
@@ -0,0 +1,3 @@
+1. Timestamps in daemon.log would be useful.
+
+2. An easy way to get annex/assistant to periodically mail daemon.log (or even better, only the new additions to daemon.log) to the local user would be great. This would seem to me like a good use of git-annex-schedule, which at the moment only does fsck, or it could be an optional part of log rotation. With this, when running annex on a remote server, one could easily get periodic confirmations that everything's working out as it should, that fscks are not failing, etc.
diff --git a/doc/todo/wishlist__58___assistant_logging_improvements/comment_1_683e2e3c94345cb6f35028cd130a4dcc._comment b/doc/todo/wishlist__58___assistant_logging_improvements/comment_1_683e2e3c94345cb6f35028cd130a4dcc._comment
new file mode 100644
index 0000000000..80075d33c3
--- /dev/null
+++ b/doc/todo/wishlist__58___assistant_logging_improvements/comment_1_683e2e3c94345cb6f35028cd130a4dcc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mhauru"
+ avatar="http://cdn.libravatar.org/avatar/2532433a0207ba772e6ca964e61899c0"
+ subject="comment 1"
+ date="2016-12-29T18:00:10Z"
+ content="""
+Just noticed that 1. has already been wished for here: https://git-annex.branchable.com/todo/wishlist__91__minor__93____58___add_time_stamps_to_annex_log_popups_in_webapp/
+"""]]
diff --git a/doc/todo/wishlist__58___derived_content_support.mdwn b/doc/todo/wishlist__58___derived_content_support.mdwn
new file mode 100644
index 0000000000..19556a13ec
--- /dev/null
+++ b/doc/todo/wishlist__58___derived_content_support.mdwn
@@ -0,0 +1,8 @@
+I handle some video and music files with git annex and it would be awesome if git annex supported tracking of relations between files.
+
+Example:
+I have music in flac on my htpc, but i think flac is way overkill to have on my Android device, so i transcode them to ogg/mp3 on my htpc and then sync them to my Android device.
+
+Transcoding is a good example for this type of feature, but there might be other uses too.
+
+The basic thing is to know a file is a "copy" of another file, but its a generated result, so the actual file is not important, but the source is.
diff --git a/doc/todo/wishlist__58___disable_automatic_commits.mdwn b/doc/todo/wishlist__58___disable_automatic_commits.mdwn
new file mode 100644
index 0000000000..ae8d6b72f5
--- /dev/null
+++ b/doc/todo/wishlist__58___disable_automatic_commits.mdwn
@@ -0,0 +1,37 @@
+When using the [[/assistant]] on some of my repositories, I would like to
+retain manual control over the granularity and contents of the commit
+history.  Some motivating reasons:
+
+* manually specified commit messages makes the history easier to follow
+* make a series of minor changes to a file over a period of a few hours would result in a single commit rather than capturing intermediate incomplete edits
+
+* manual choice of which files to annex (based on predicted usage) could be useful, e.g. a repo might contain a 4MB PDF which you want available in *every* remote even without `git annex get`, and also some 2MB images which are only required in some remotes
+
+> This particular case is now catered to by the ["manual" repository group](/preferred_content/standard_groups/)
+> in [[preferred content]] settings. --[[Joey]]
+
+Obviously this needs to be configurable at least per repository, and
+ideally perhaps even per remote, since usage habits can vary from machine
+to machine (e.g. I could choose to commit manually from my desktop machine
+which has a nice comfy keyboard and large screen, but this would be too
+much pain to do from my tiny netbook).
+
+In fact, this is vaguely related to [[design/assistant/partial_content]],
+since the usefulness of the commit history depends on the context of the
+data being manipulated, which in turn depends on which subdirectories are
+being touched.  So any mechanism for disabling sync per directory could
+potentially be reused for disabling auto-commit per directory.
+
+According to Joey, it should be easy to arrange for the watcher thread not
+to run, but would need some more work for the assistant to notice manual
+commits in order to sync them; however the assistant already does some
+crazy inotify watching of git refs, in order to detect incoming pushes, so
+detecting manual commits wouldn't be a stretch.
+
+[[!tag design/assistant]]
+
+> You can do this now by pausing committing via the webapp,
+> or setting `annex.autocommit=false`.
+> 
+> When configured this way, the assistant doesn't push commits
+> that you manually make, of course you can also manually push. --[[Joey]]
diff --git a/doc/todo/wishlist__58___disable_automatic_commits/comment_1_3f76bc558b59f90d0276be8cd24c6797._comment b/doc/todo/wishlist__58___disable_automatic_commits/comment_1_3f76bc558b59f90d0276be8cd24c6797._comment
new file mode 100644
index 0000000000..9defbcf25d
--- /dev/null
+++ b/doc/todo/wishlist__58___disable_automatic_commits/comment_1_3f76bc558b59f90d0276be8cd24c6797._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject=".gitattributes could solve this"
+ date="2019-09-29T22:59:48Z"
+ content="""
+Revisiting this topic 3.5 years later ...
+
+The assistant will still commit a change as soon as it notices it.  This obviously has the advantage of synchronising changes to peers quicker, but it also has downsides:
+
+- It pollutes the git history with every single (saved) edit.
+- Consequently it bloats the git object store.
+
+I find this undesirable even when editing my TODO list, but it could be particularly problematic with large files, e.g. using `ffmpeg` to transcode a video between formats would presumably capture lots of intermediate states of the unfinished transcoding process.  Similarly for rendering from a video editor.
+
+So it would be helpful if there was a configurable option to determine how often changes get committed.  Ideally this would be configurable via `.gitattributes`, e.g.
+
+```
+*      annex.autocommit=anything
+*.webm annex.autocommit=(mtimebefore=10mins)
+```
+
+would autocommit most stuff immediately, but would only autocommit webm files if they haven't changed within the last 10 minutes.
+"""]]
diff --git a/doc/todo/wishlist__58___disable_automatic_commits/comment_2_a031373f7251b5395100bcfc57519049._comment b/doc/todo/wishlist__58___disable_automatic_commits/comment_2_a031373f7251b5395100bcfc57519049._comment
new file mode 100644
index 0000000000..a07f96ffb3
--- /dev/null
+++ b/doc/todo/wishlist__58___disable_automatic_commits/comment_2_a031373f7251b5395100bcfc57519049._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-30T18:25:08Z"
+ content="""
+The assistant does not commit files that are open for write.
+
+So unless ffmpeg partially writes the file, then closes the file, then
+reopens it and writes some more, the assistant will only make a single
+commit.
+"""]]
diff --git a/doc/todo/wishlist__58___disable_automatic_commits/comment_3_53b1321d5bcaf4139f9fbbd17f26fe75._comment b/doc/todo/wishlist__58___disable_automatic_commits/comment_3_53b1321d5bcaf4139f9fbbd17f26fe75._comment
new file mode 100644
index 0000000000..b86a9cba47
--- /dev/null
+++ b/doc/todo/wishlist__58___disable_automatic_commits/comment_3_53b1321d5bcaf4139f9fbbd17f26fe75._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="There are still benefits to commit throttling"
+ date="2019-09-30T22:16:10Z"
+ content="""
+> The assistant does not commit files that are open for write.
+
+Interesting; I see it uses lsof for this.
+
+> So unless ffmpeg partially writes the file, then closes the file, then reopens it and writes some more, the assistant will only make a single commit.
+
+OK, so that probably wasn't a good example.  But that still doesn't negate my TODO list editing example, and it is not hard to think of other scenarios where partial results are written by one process and then rewritten in-place by another.
+
+It also doesn't negate the fact that throttling the commit speed would also help reduce I/O between remotes in some cases simply by reducing \"churn\" within any given repo, as noted in [my comment on design/assistant/rate_limiting](https://git-annex.branchable.com/design/assistant/rate_limiting/#comment-c88bc709792c79037a41292c1db70889).
+"""]]
diff --git a/doc/todo/wishlist__58___disable_automatic_commits/comment_4_e021de3647a00aa0259a247441de50eb._comment b/doc/todo/wishlist__58___disable_automatic_commits/comment_4_e021de3647a00aa0259a247441de50eb._comment
new file mode 100644
index 0000000000..56be81e356
--- /dev/null
+++ b/doc/todo/wishlist__58___disable_automatic_commits/comment_4_e021de3647a00aa0259a247441de50eb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="AdamSpiers"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="Would you accept a patch implementing an annex.autocommit gitattribute?"
+ date="2020-01-06T16:12:54Z"
+ content="""
+In a semi-mythical future where I find the time to learn Haskell, in principle would you consider accepting a patch implementing my above suggestion of a new `annex.autocommit` gitattribute which offers finer control of autocommit than the current binary toggle?  It would be very useful to me, and maybe I'm not the only one.
+"""]]
diff --git a/doc/todo/wishlist__58___disable_automatic_commits/comment_5_701ef8d7bca858150bc0ae070d21755d._comment b/doc/todo/wishlist__58___disable_automatic_commits/comment_5_701ef8d7bca858150bc0ae070d21755d._comment
new file mode 100644
index 0000000000..a517ea2255
--- /dev/null
+++ b/doc/todo/wishlist__58___disable_automatic_commits/comment_5_701ef8d7bca858150bc0ae070d21755d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="I've hacked up a Python script for policy-based automatic commits"
+ date="2020-06-11T10:10:52Z"
+ content="""
+Since I haven't learnt Haskell yet (and even if I was able to hack a patch to git-annex I'm not sure whether it would be accepted), I've hacked up [a simple `git-auto-commit` Python script for automatically committing based on a simple policy](https://github.com/aspiers/pim/blob/master/bin/git-auto-commit), together with [a shell script which invokes it every `$n` seconds](https://github.com/aspiers/pim/blob/master/bin/auto-commit-daemon).
+
+Currently the policy is hardcoded to only stage and commit files ending in `.org` which have unstaged changes and an `mtime` over a minimum threshold, in order to throttle the rate at which automatic commits are made.  Maybe at some point I'll change it to honour `.gitattributes` such as
+
+    *.org annex.autocommit=(mtimebefore=5mins)
+
+but of course it would be far nicer if the assistant could do this natively, since that would also solve [forum/Can the assistant sync files if committed manually (autocommit=false)?](https://git-annex.branchable.com/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/).
+"""]]
diff --git a/doc/todo/wishlist__58___disable_automatic_commits/comment_6_195815446f3ec78901c1ddd245b86c4c._comment b/doc/todo/wishlist__58___disable_automatic_commits/comment_6_195815446f3ec78901c1ddd245b86c4c._comment
new file mode 100644
index 0000000000..811c6eec42
--- /dev/null
+++ b/doc/todo/wishlist__58___disable_automatic_commits/comment_6_195815446f3ec78901c1ddd245b86c4c._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="Update on my auto-commit / auto-sync scripts"
+ date="2020-07-09T14:23:14Z"
+ content="""
+I've moved the location of my [`git-auto-commit`](https://github.com/aspiers/git-config/blob/master/bin/git-auto-commit) and [`auto-commit-daemon` wrapper](https://github.com/aspiers/git-config/blob/master/bin/auto-commit-daemon), and [added support for autocommit policy](https://github.com/aspiers/git-config/commit/f1898f3c6476dd06b68ca35c79a0e95e4fb4b0cb) based an `autocommit` [git attribute](https://git-scm.com/docs/gitattributes).
+
+For example:
+
+    $ echo \"*.org autocommit=min-age=+5m\" > .gitattributes
+
+will ensure that all `.org` files last committed and modified more than 5 minutes ago will be automatically committed by the next `git auto-commit` run in this repo.
+
+In the future I can imagine adding support for more sophisticated auto-commit policies.
+
+Here's an example of the kind of systemd unit service file I put in `~/.config/systemd/user` so that I can control the daemon via `systemctl --user`:
+
+```  
+[Service]
+ExecStart=/bin/sh -c \"/home/adam/bin/auto-commit-daemon /home/adam/myrepo\"
+Restart=always
+NoNewPrivileges=true
+SyslogIdentifier=auto-commit-myrepo
+EnvironmentFile=/home/adam/myrepo/.autocommit
+
+[Install]
+WantedBy=multi-user.target
+```
+
+and `~/myrepo/.autocommit` contains `SLEEP=1m` so that the daemon wrapper runs `git auto-commit` every minute.
+
+I couple this with another simple [`auto-sync-daemon` script](https://github.com/aspiers/git-config/blob/master/bin/auto-sync-daemon) which uses `inotifywait` to trigger invocations of `git annex sync` whenever `master` or `synced/master` change.  Doing this across multiple remotes effectively achieves a poor man's [[assistant]].  (Incidentally, I use `mr`, one of Joey's other hacks, to [automatically set up and manage a systemd daemon for each repo](https://github.com/aspiers/mr-config/commit/80739c1e7f94423d588c4172e39508692d89f913)).
+
+... **BUT**, I really wish this was supported natively in `git-annex` instead.  I've kind of had to reinvent the base functionality of the assistant just to get this autocommit policy feature.  It was painful, but still easier than learning Haskell and the `git-annex` codebase.
+"""]]
diff --git a/doc/todo/wishlist__58___display_status_of_remotes_in_the_webapp.mdwn b/doc/todo/wishlist__58___display_status_of_remotes_in_the_webapp.mdwn
new file mode 100644
index 0000000000..7414669944
--- /dev/null
+++ b/doc/todo/wishlist__58___display_status_of_remotes_in_the_webapp.mdwn
@@ -0,0 +1 @@
+It would be nice to have an indication of the status of the remotes in the webapp, for example with a field showing "In Sync", "Syncing", or the date of the last successful synchronization for unreachable remotes.
diff --git a/doc/todo/wishlist__58___encrypted_git_remote_on_hosting_site_from_webapp.mdwn b/doc/todo/wishlist__58___encrypted_git_remote_on_hosting_site_from_webapp.mdwn
new file mode 100644
index 0000000000..b7b1bad0c9
--- /dev/null
+++ b/doc/todo/wishlist__58___encrypted_git_remote_on_hosting_site_from_webapp.mdwn
@@ -0,0 +1 @@
+It would be great to be able to do **private encrypted git remote on hosting site** and **multiuser encrypted git remote on hosting site** as explained in [[tips/fully encrypted git repositories with gcrypt]] through the webapp. I think it's a pretty common usecase that can be very useful for people not owning a proper server.
diff --git a/doc/todo/wishlist__58___generic_annex.cost-command.mdwn b/doc/todo/wishlist__58___generic_annex.cost-command.mdwn
new file mode 100644
index 0000000000..6adf1460e8
--- /dev/null
+++ b/doc/todo/wishlist__58___generic_annex.cost-command.mdwn
@@ -0,0 +1,17 @@
+### Current setup
+
+ATM git-annex has
+
+remote.<name>.annex-cost
+remote.<name>.annex-cost-command  # command is not provided cmdline options by annex
+
+to set the cost for a given remote.  That requires setting up one of those variables per each host, and possibly hardcoding options for the annex-cost-command providing e.g. the remote name.
+
+### Suggestion
+
+wouldn't it be more general and thus more flexible to have a repository-wide
+
+annex.cost-command
+
+which could take options %remote, %file and assessed accordingly per each file upon '--get' request to allow maximal flexibility: e.g. some files might better be fetched from remotes supporting transfer compression, some from the web, etc.  Also it might be worth providing %remote_kind ("special" vs "git") to disambiguate %remote's?
+
diff --git a/doc/todo/wishlist__58___generic_annex.cost-command/comment_1_b2060ec194e3ae53bd286f2bae799984._comment b/doc/todo/wishlist__58___generic_annex.cost-command/comment_1_b2060ec194e3ae53bd286f2bae799984._comment
new file mode 100644
index 0000000000..d4d212b1d3
--- /dev/null
+++ b/doc/todo/wishlist__58___generic_annex.cost-command/comment_1_b2060ec194e3ae53bd286f2bae799984._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-01-16T18:11:25Z"
+ content="""
+Then remote.name.annex-cost-command and annex.cost-command would not be
+able to be set to the same value with the same result. That is an asymmetry
+that no other pair of remote.name.foo and annex.foo have. 
+
+I think it's better to avoid such asymmetry.
+
+(Also the idea of different costs for different files is right out,
+that would make it sloooow.)
+"""]]
diff --git a/doc/todo/wishlist__58___global_progress_status.mdwn b/doc/todo/wishlist__58___global_progress_status.mdwn
new file mode 100644
index 0000000000..3c6611af4f
--- /dev/null
+++ b/doc/todo/wishlist__58___global_progress_status.mdwn
@@ -0,0 +1,3 @@
+similar to [[do_not_bug_me_about_intermediate_files]] - i feel that massive `git annex get` operations should have better progress information than the current individual `rsync --progress` bits. i wonder if this couldn't be accomplished with `rsync --info=PROGRESS2`, which gives overall rsync progress, combined with copying multiple files at once with rsync (which would have the side-effect of speeding up `git annex get` for large number of small files).
+
+once this is done, it could be sent back to the webapp UI to give the user a global sense of the overall sync progress (as opposed to per-file progress). --[[anarcat]]
diff --git a/doc/todo/wishlist__58___global_progress_status/comment_1_d915dce144071f768ee9bcdead07a0e5._comment b/doc/todo/wishlist__58___global_progress_status/comment_1_d915dce144071f768ee9bcdead07a0e5._comment
new file mode 100644
index 0000000000..8a733f90bc
--- /dev/null
+++ b/doc/todo/wishlist__58___global_progress_status/comment_1_d915dce144071f768ee9bcdead07a0e5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-03T15:23:48Z"
+ content="""
+To display global progress, git-annex would have to make 2
+passes over all the files to be processed. 
+That is the main reason it does not try to do that.
+"""]]
diff --git a/doc/todo/wishlist__58___global_progress_status/comment_2_816f41f5436543fc09e7d7df82a8c8d5._comment b/doc/todo/wishlist__58___global_progress_status/comment_2_816f41f5436543fc09e7d7df82a8c8d5._comment
new file mode 100644
index 0000000000..a75aea4c23
--- /dev/null
+++ b/doc/todo/wishlist__58___global_progress_status/comment_2_816f41f5436543fc09e7d7df82a8c8d5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="atrent"
+ subject="adding a simple counter?"
+ date="2016-02-03T07:48:10Z"
+ content="""
+could you add a simple file counter?
+
+i.e. for a single \"git annex copy/get/etc.\" operation initiating a file counter and incrementing it on every examined file (transferred or not), thus giving a very rough idea of the progress on the whole set (the user should know the amount of files in the annex)
+"""]]
diff --git a/doc/todo/wishlist__58___global_progress_status/comment_3_587e8befa0e52d8880362a32799df492._comment b/doc/todo/wishlist__58___global_progress_status/comment_3_587e8befa0e52d8880362a32799df492._comment
new file mode 100644
index 0000000000..37effc4f9a
--- /dev/null
+++ b/doc/todo/wishlist__58___global_progress_status/comment_3_587e8befa0e52d8880362a32799df492._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-03-12T21:38:17Z"
+ content="""
+git-annex does not display rsync progress any longer, but you do still 
+get the progress display on a per-file basis. This is at least a lot more
+compact than the rsync output.
+
+Any kind of global progress display would require a separate pass to
+identify all the files that git-annex will be operating on. That would make
+it slower in large repos, and people already complain about seek speed in
+large repos.
+"""]]
diff --git a/doc/todo/wishlist__58___global_progress_status/comment_4_60b7597af2b86ce6bcb31731f6d8c54e._comment b/doc/todo/wishlist__58___global_progress_status/comment_4_60b7597af2b86ce6bcb31731f6d8c54e._comment
new file mode 100644
index 0000000000..106c6c6d8d
--- /dev/null
+++ b/doc/todo/wishlist__58___global_progress_status/comment_4_60b7597af2b86ce6bcb31731f6d8c54e._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="rsync can do this on its own"
+ date="2018-11-04T19:29:19Z"
+ content="""
+i understand, thanks for taking the time to explain the tradeoffs! :)
+
+i know that rsync is not used anymore, but I figured I should document this here since it's the first thing that it made me think of when i found out about it. as it turns out, rsync *does* have its own \"global status\", which has similar tradeoffs than git-annex (namely that it doesn't work in \"incremental mode\"). from #debian-til on OFTC:
+
+[[!format txt \"\"\"
+13:30:15 <juliank> TIL: rsync  --partial --no-inc-recursive -ah --info=progress2 
+13:30:32 <lamby> explanation?
+13:30:33  * juliank apologizes for the :
+13:30:45 <juliank> So, --info=progress2 gives you overall progress
+13:30:53 <lamby> overall?
+13:30:58 <lamby> Oh, w/ multiple files?
+13:31:00 <juliank> and --no-inc-recursive makes it really overall by doing scanning up front
+13:31:08 <juliank> s/scanning/recursion/
+13:31:09 <lamby> Oh, now that's very neat.
+13:31:16 <juliank> and -h gives you human-readable sizes
+13:31:16 <lamby> WTB that in debmirror :3
+\"\"\"]]
+
+So rsync allows you to switch back to the \"costly mode\" which *does* a full scan before starting. It's slower, but it allows you to get global progress info. It's a nice tradeoff and it's especially useful to be able to enable it on deman. I understand this might be complicated to implement in git-annex because there are many places where such an option would be required (and it's unclear how it would be named), but it's something that would certainly be useful for my use cases, where some repos have large files but not so many so are fairly fast to scan (e.g. i could do this on my video repo, but not the music repo). -- [[anarcat]]
+"""]]
diff --git a/doc/todo/wishlist__58___history_of_operations.mdwn b/doc/todo/wishlist__58___history_of_operations.mdwn
new file mode 100644
index 0000000000..a79f500ff6
--- /dev/null
+++ b/doc/todo/wishlist__58___history_of_operations.mdwn
@@ -0,0 +1,8 @@
+Hi,
+
+I would love to have a page of "history" or "events" in the webapp. Similar to how Dropbox or Box show it.
+I've been using git-annex for my personal files for a few months now, and I feel like this is the only feature missing to start using it in a production multi-user environment.
+
+Thanks
+
+[[!tag design/assistant]]
diff --git a/doc/todo/wishlist__58___history_of_operations/comment_1_f9a77ce83c6f39b6272d5c577ffbb9f9._comment b/doc/todo/wishlist__58___history_of_operations/comment_1_f9a77ce83c6f39b6272d5c577ffbb9f9._comment
new file mode 100644
index 0000000000..bb872532d7
--- /dev/null
+++ b/doc/todo/wishlist__58___history_of_operations/comment_1_f9a77ce83c6f39b6272d5c577ffbb9f9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlJEI45rGczFAnuM7gRSj4C6s9AS9yPZDc"
+ nickname="Kevin"
+ subject="I second this wishlist item"
+ date="2013-07-24T16:48:59Z"
+ content="""
+I too would like to see a recent history of events in the assistant webapp.  A simple listing of what changed when and by whom would be sufficient.
+"""]]
diff --git a/doc/todo/wishlist__58___matching_options_for_branches.mdwn b/doc/todo/wishlist__58___matching_options_for_branches.mdwn
new file mode 100644
index 0000000000..03086e0f92
--- /dev/null
+++ b/doc/todo/wishlist__58___matching_options_for_branches.mdwn
@@ -0,0 +1 @@
+I have a repository layout where I have multiple unrelated branches in a single repository. Different branches have different policies regarding where their content should be replicated. It would be nice to be able to reflect this with git-annex's matching and preferred content options, but currently there seems to be no way to say "include/exclude files referred to in these branches".
diff --git a/doc/todo/wishlist__58___matching_options_for_branches/comment_1_c0d442b646dc40d870b10098a0ee5408._comment b/doc/todo/wishlist__58___matching_options_for_branches/comment_1_c0d442b646dc40d870b10098a0ee5408._comment
new file mode 100644
index 0000000000..d606d80e11
--- /dev/null
+++ b/doc/todo/wishlist__58___matching_options_for_branches/comment_1_c0d442b646dc40d870b10098a0ee5408._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-09T18:34:29Z"
+ content="""
+It's hard to add this kind of thing to the preferred content expressions.
+
+First, it would be quite slow to check if a given key
+was present in some file in a given branch. There's no index for that
+information.
+
+Second, even if that were implemented, there's no guarantee at all that
+different repositories have the same git branches. If repo Foo wants files in
+branch B, and repo Bar sees that, and has no branch B, or a different
+version of branch B, how is it supposed to know which files to send to
+repo Foo?
+
+So, I can see the use case, but I don't see how preferred content can
+support it.
+"""]]
diff --git a/doc/todo/wishlist__58___move_pending_transfers_for_a_host_to_the_end_of_the_queue_when_one_fails.mdwn b/doc/todo/wishlist__58___move_pending_transfers_for_a_host_to_the_end_of_the_queue_when_one_fails.mdwn
new file mode 100644
index 0000000000..e50ebbde5e
--- /dev/null
+++ b/doc/todo/wishlist__58___move_pending_transfers_for_a_host_to_the_end_of_the_queue_when_one_fails.mdwn
@@ -0,0 +1,7 @@
+Right now the assistant can have a huge list of pending transfers for certain hosts if its data is a bit outdated, or a host hasn't been synced lately. When starting up it will then attempt each transfer to said host (which will in turn fail, but at times take time to time out), possibly before doing other stuff like attempting to download new files, or copy files to online hosts.
+
+I suggest that if a transfer fails for host X, and there are other pending transfers, say to host Y and from Z, then all other pending transfers to/from X gets pushed to the back of the queue, to avoid having to wait a long time for several transfers to time out before doing useful stuff.
+
+The prime example for me was this morning, when a laptop that was turned off had a huge amount of queued transfers to it, resulting in the assistant attempting a load of transfers to that host before it retrieved a new file that I had created on another machine yesterday.
+
+[[!tag design/assistant]]
diff --git a/doc/todo/wishlist__58___move_pending_transfers_for_a_host_to_the_end_of_the_queue_when_one_fails/comment_1_82ee9de610a0ac55cd1c27c211079e5b._comment b/doc/todo/wishlist__58___move_pending_transfers_for_a_host_to_the_end_of_the_queue_when_one_fails/comment_1_82ee9de610a0ac55cd1c27c211079e5b._comment
new file mode 100644
index 0000000000..3b6101ed58
--- /dev/null
+++ b/doc/todo/wishlist__58___move_pending_transfers_for_a_host_to_the_end_of_the_queue_when_one_fails/comment_1_82ee9de610a0ac55cd1c27c211079e5b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.6.49"
+ subject="comment 1"
+ date="2012-12-01T19:22:03Z"
+ content="""
+There are several difficulties with reordering the queue that way. One is that the failure may be intermittent; another is that the queue is fed by a scanning process, so doesn't always have a well-defined end.
+
+Another way to deal with this problem, which I think I prefer, is to allow multiple actions from the queue to run at once. Then slow or unreachable remotes don't block it from using other remotes. 
+"""]]
diff --git a/doc/todo/wishlist__58___move_pending_transfers_for_a_host_to_the_end_of_the_queue_when_one_fails/comment_2_bea55156bd32cf9e6dd9b946ba1bb8c1._comment b/doc/todo/wishlist__58___move_pending_transfers_for_a_host_to_the_end_of_the_queue_when_one_fails/comment_2_bea55156bd32cf9e6dd9b946ba1bb8c1._comment
new file mode 100644
index 0000000000..62d46bccd0
--- /dev/null
+++ b/doc/todo/wishlist__58___move_pending_transfers_for_a_host_to_the_end_of_the_queue_when_one_fails/comment_2_bea55156bd32cf9e6dd9b946ba1bb8c1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="84.48.83.221"
+ subject="comment 2"
+ date="2012-12-01T19:31:18Z"
+ content="""
+I agree your method might be preferable, the end result is the same, and would have avoided the issues I had (and, of course, running multiple transfers at once has other benefits as well).
+
+An alternate way would be to push every transfer NOT from host X to the front of the queue (avoiding most of the \"no defined end\" issue and largely solving the problem), but if multiple actions at once is feasible then that'd still be much nicer.
+"""]]
diff --git a/doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode.mdwn b/doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode.mdwn
new file mode 100644
index 0000000000..b1e63f1251
--- /dev/null
+++ b/doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode.mdwn
@@ -0,0 +1,3 @@
+For batch mode of `checkpresentkey`, it could be useful to have the option of outputting the key in a second (space- or tab-delimited?) column in addition to the `0/1` status indicator for that key; this could be useful for reporting, error recovery, or further key-specific action based on output. Presently it seems the only way to accomplish this would be to independently track corresponding input and output line indices, or externally join input and output (e.g., via the *nix `paste` command). 
+
+Thank you!
diff --git a/doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_1_f95f2c92a46c1bd00c627aa19b08c875._comment b/doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_1_f95f2c92a46c1bd00c627aa19b08c875._comment
new file mode 100644
index 0000000000..db469b88e2
--- /dev/null
+++ b/doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_1_f95f2c92a46c1bd00c627aa19b08c875._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-07-11T16:36:11Z"
+ content="""
+Hmm, my assumption is that use of checkpresentkey --batch is in some kind
+of loop, or function call, where you'd write a key to it, read a response
+back, and now you know whether that key is present.
+
+Does your use case involve something like shell scripting? I suppose if you
+have a big list of keys and want to narrow it to only keys that are present
+or missing, you could be trying to pipe it through checkpresentkey --batch.
+"""]]
diff --git a/doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_2_bb756ddf06c52ca52d73af319f0265b0._comment b/doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_2_bb756ddf06c52ca52d73af319f0265b0._comment
new file mode 100644
index 0000000000..b871a772d0
--- /dev/null
+++ b/doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_2_bb756ddf06c52ca52d73af319f0265b0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="magibney@908c3d4677b9e87e203538d4d5e8c296255749a0"
+ nickname="magibney"
+ subject="comment 2"
+ date="2016-07-11T18:45:10Z"
+ content="""
+Exactly: shell scripting, \"big list of keys and want to narrow it to only keys that are present or missing\". 
+
+My motivating use case is as a sanity check that all keys have been successfully transferred on a Ceph S3 instance internally (i.e., `s3cmd cp s3://sourcebucket/[annex-key] s3://destbucket/[annex-key]`, without being read back to the local machine and separately written back up to a different bucket on the same server and locally deleted).  Post-transfer, I want to check that all keys are present as expected, but in the event that a failed transfer is detected, I'd like to be able to report a specific key back to the operator/calling script. 
+
+I'm thinking that if one is running `checkpresentkey` in batch mode (with multiple keys at once), there are many useful things one might want to do with the output that would require associating output status indicators with input keys; and since the output of `checkpresentkey --batch` is so terse, it could optionally be extended without too much parsing/escaping/etc complication. 
+
+Thanks for considering this, and apologies that the initial request was a bit cryptic about the use case! 
+"""]]
diff --git a/doc/todo/wishlist__58___perform_fsck_remotely.mdwn b/doc/todo/wishlist__58___perform_fsck_remotely.mdwn
new file mode 100644
index 0000000000..f2187d9122
--- /dev/null
+++ b/doc/todo/wishlist__58___perform_fsck_remotely.mdwn
@@ -0,0 +1,39 @@
+Currently, when `fsck`'ing a remote, files are first downloaded to a temporary 
+file locally, decrypted if needed, and finally digested; the temporary file is
+then either thrown away, or quarantined, depending on the value of that digest.
+
+Whereas this approach works with any kind of remote, in the particular case 
+where the user is granted execution rights on the digest command, one could
+avoid cluttering the network and digest the file remotely. I propose the
+addition of a per-remote git option `annex-remote-fsck` to switch between the
+two behaviors.
+
+
+There is an issue with encrypted specialremotes, though. As hinted at 
+[[here|tips/beware_of_SSD_wear_when_doing_fsck_on_large_special_remotes/#comment-70055f166f7eeca976021d24a736b471]],
+since the digest of a ciphertext can't be deduced from that of a plaintext in 
+general one would needs, before sending an encrypted file to such a remote, to
+digest it and store that digest somewhere (together with the cipher's size and
+perhaps other meta-information).
+
+The usual directory structure (`.../.../{backend}-s{size}--{digest}.log`) seems
+perfectly suitable to store these informations. Lines there would look like
+`{timestamp}s {numcopy} {UUID} {remote digest}`. Of course, it implies that
+remote digest commands are trustworthy (are doing the right thing), and that
+the digest output are not tampered by others who have access to the git repo.
+But that's outside the current threat model, I guess.
+
+Actually, since git-annex always includes a MDC in the ciphertexts, we could do
+something clever and even avoid running a digest algorithm. According to the
+[[OpenPGP standard|https://tools.ietf.org/html/rfc4880#section-5.14]] the MDC
+is essentially a SHA-1 hash of the plaintext. I'm still investigating if it's
+even possible, but in theory it would be enough (with non-chained ciphers at
+least) to download a few bytes from the encrypted remote, decrypt those bytes
+to retrieve the hash, and compare that hash with the known value. Of course
+there is a downside here, namely that files tampered anywhere but on the MDC
+packets would not be detected by `fsck` (but gpg will warn when decrypting the
+file).
+
+
+My 2 cents :-) Is there something I missed? I suppose there was a reason to 
+perform `fsck` locally at the first place...
diff --git a/doc/todo/wishlist__58___perform_fsck_remotely/comment_1_db92311dcdb1ef0ab0413f83e191c70c._comment b/doc/todo/wishlist__58___perform_fsck_remotely/comment_1_db92311dcdb1ef0ab0413f83e191c70c._comment
new file mode 100644
index 0000000000..6bf6af23ae
--- /dev/null
+++ b/doc/todo/wishlist__58___perform_fsck_remotely/comment_1_db92311dcdb1ef0ab0413f83e191c70c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 1"
+ date="2013-08-22T15:18:35Z"
+ content="""
+The only reason fsck is done locally for remotes is ease of implementation and it being a generic operation that supports any kind of special remote.
+
+Seems that the the only types of remotes where a remote fsck is a possibility are some rsync remotes and git remotes.
+git remotes already have git-annex installed, so the fsck could be run locally on the remote system using it.
+
+I don't know if I see a benefit with the MDC check. Any non-malicious data corruption on the remote is likely to affect the body of the file and not the small portion that holds the MDC. So checking the MDC does not seem much better than the current existence check done by `git annex fsck --fast --from remote`.
+
+As for storing the remote digest on the git-annex branch, my initial reaction was just that it's potentially a lot of bloat. Thinking about it some more, when using non-shared encryption, there is currently no way, given just a clone of a git repository, to match up files in git with encrypted objects stored on a special remote. So storing the remote digest might be considered to weaken the security.
+"""]]
diff --git a/doc/todo/wishlist__58___perform_fsck_remotely/comment_2_2f0dbaf143d94290bfbebb6869eb7241._comment b/doc/todo/wishlist__58___perform_fsck_remotely/comment_2_2f0dbaf143d94290bfbebb6869eb7241._comment
new file mode 100644
index 0000000000..5418ff991e
--- /dev/null
+++ b/doc/todo/wishlist__58___perform_fsck_remotely/comment_2_2f0dbaf143d94290bfbebb6869eb7241._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="guilhem"
+ ip="129.16.20.209"
+ subject="comment 2"
+ date="2013-08-22T16:56:55Z"
+ content="""
+Oh yeah, the MDC paragraph was pretty much pointless indeed. Oops :-P
+
+I agree that this would potentially add some noise to the index, and weaken the 
+security, but depending on the threat model and people's preferences that's an
+option that's worth considering IMHO.
+"""]]
diff --git a/doc/todo/wishlist__58___perform_fsck_remotely/comment_3_5ec2e0e248dfd4ca46aef89cc5658d18._comment b/doc/todo/wishlist__58___perform_fsck_remotely/comment_3_5ec2e0e248dfd4ca46aef89cc5658d18._comment
new file mode 100644
index 0000000000..91d07b7659
--- /dev/null
+++ b/doc/todo/wishlist__58___perform_fsck_remotely/comment_3_5ec2e0e248dfd4ca46aef89cc5658d18._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="68.119.96.78"
+ subject="comment 3"
+ date="2013-12-21T16:27:16Z"
+ content="""
+There is now a remoteFsck action in the Remote data structure. So far it is only implemented for git remotes, and `git annex fsck` does not use it; only the assistant does.
+"""]]
diff --git a/doc/todo/wishlist__58___provide_a_config_option_for_using_new_hashing_scheme_in_non-bare_remotes.mdwn b/doc/todo/wishlist__58___provide_a_config_option_for_using_new_hashing_scheme_in_non-bare_remotes.mdwn
new file mode 100644
index 0000000000..d987d03e15
--- /dev/null
+++ b/doc/todo/wishlist__58___provide_a_config_option_for_using_new_hashing_scheme_in_non-bare_remotes.mdwn
@@ -0,0 +1,8 @@
+I understand that for backwards compatibility the non-bare remotes use the old "mixed" case scheme. However, for new annexes, it'd make sense to be able to use the new one so the scheme matches in all remotes.
+
+> If this option existed then every clone of a repository would need to set
+> it, or files would be hashed into the wrong location and would appear not
+> visible. Sounds like a bug magnet to me; not attractive. --[[Joey]]
+
+> > Actually, `git-anex init -c annex.tune.objecthashlower=true`
+> > does just this. So, [[done]] --[[Joey]]
diff --git a/doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl.mdwn b/doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl.mdwn
new file mode 100644
index 0000000000..9c9d7ce75d
--- /dev/null
+++ b/doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl.mdwn
@@ -0,0 +1,10 @@
+I think it would be interesting to have a way to recursively import a local directory without actually moving files around. And to be able to checksum these files as well (without moving them into the annex).
+
+This would work somewhat similar to looping over a directory and adding file:// remotes for each file.
+
+A use case is importing optical media (read-only), whilst keeping that media as a remote, and being able to calculate checksums directly without moving any files around.
+
+For single files, it would also be interesting if addurl had a "--localchecksum" option that would only work for file:// urls, and make it checksum files directly from their source location?)
+
+> A directory special remote with importtree=yes and `git-annex import`--no-content`
+> can be used to do this. [[done]] --[[Joey]]
diff --git a/doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl/comment_1_b79976afc2242791523e63831f30af71._comment b/doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl/comment_1_b79976afc2242791523e63831f30af71._comment
new file mode 100644
index 0000000000..caefee9a82
--- /dev/null
+++ b/doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl/comment_1_b79976afc2242791523e63831f30af71._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~arand"
+ nickname="arand"
+ subject="comment 1"
+ date="2013-03-10T23:29:55Z"
+ content="""
+Recursively adding urls is already feasiable with some simple scripting:
+
+[https://gitorious.org/arand-scripts/arand-scripts/blobs/master/annex-importdir](https://gitorious.org/arand-scripts/arand-scripts/blobs/master/annex-importdir)
+
+but this is obviously missing the checksumming bit though.
+"""]]
diff --git a/doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl/comment_2_1741d2392006a9af9cfd1f3b847600b9._comment b/doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl/comment_2_1741d2392006a9af9cfd1f3b847600b9._comment
new file mode 100644
index 0000000000..64d5924795
--- /dev/null
+++ b/doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl/comment_2_1741d2392006a9af9cfd1f3b847600b9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-03-11T03:04:44Z"
+ content="""
+See also: [[forum/Managing a large number of files archived on many pieces of read-only medium (E.G. DVDs)]]
+particularly [[this comment|forum/Managing a large number of files archived on many pieces of read-only medium (E.G. DVDs)#comment-908dbe02f29e011f030bba4ab5ef73d1]]
+"""]]
diff --git a/doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl/comment_3_b6fb39030f98bbc9915712e3d35d1838._comment b/doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl/comment_3_b6fb39030f98bbc9915712e3d35d1838._comment
new file mode 100644
index 0000000000..fd5dc9e051
--- /dev/null
+++ b/doc/todo/wishlist__58___recursive_directory_remote_setup__47__addurl/comment_3_b6fb39030f98bbc9915712e3d35d1838._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730"
+ nickname="0xloem"
+ subject="Assistant support"
+ date="2016-04-16T11:52:14Z"
+ content="""
+This would be really augmented if the assistant and webapp could watch external folders and automatically add new files that appeared.  Then e.g. your system logs and family photos could be archived together without maintenance needed.
+I'm running into this on android, wherw I'd like to store files my phone produces alongside my other files.
+"""]]
diff --git a/doc/todo/wishlist__58___traffic_accounting_for_git-annex.mdwn b/doc/todo/wishlist__58___traffic_accounting_for_git-annex.mdwn
new file mode 100644
index 0000000000..4b661101d7
--- /dev/null
+++ b/doc/todo/wishlist__58___traffic_accounting_for_git-annex.mdwn
@@ -0,0 +1,3 @@
+As git annex keeps logs about file transfers anyway, it should be relatively easy to add traffic accounting to a repo. That would allow me to monitor how much traffic a given repo generates. As I might end up hosting git-annex repos for a few personal friends, I need/want a way to track the heavy hitters. -- RichiH
+
+PS: If you ever plan to host git-annex similar branchable, this would probably be of interest to you, as well :)
diff --git a/doc/todo/wishlist__58___unify_directory_scheme_for_the_store.mdwn b/doc/todo/wishlist__58___unify_directory_scheme_for_the_store.mdwn
new file mode 100644
index 0000000000..83ce531278
--- /dev/null
+++ b/doc/todo/wishlist__58___unify_directory_scheme_for_the_store.mdwn
@@ -0,0 +1,20 @@
+In regular repos, objects are stored in files of the form: .git/annex/objects/xY/z1/SHA1-.../SHA1-.... (scheme 1)
+
+On (some) special remotes, the corresponding file is stored at: .../abc/def/SHA1-... (scheme 2)
+
+I'm not sure why the same scheme as in .git/objects isn't used, but it would be useful that the two-directory prefix were the same for all objects stores.
+
+My use case is: I synchronize a git repo, say containing photos, to a server on which I can't install git-annex. I want the server to store all annexed files. For the photos to be viewed online, the annex store must use the scheme 1 (because the symlinks point to files with scheme 1). So I need to rsync .git/annex/objects manually from my desktop, because a git-annex rsync remote uses scheme 2. On the other hand, the repo on this server is not known by git-annex (like it would if I used a rsync remote).
+
+At least it would be valuable (to get around above problem) to have a plumbing command giving the 2-directory prefix from a given key, for example:
+
+$ git annex prefix-dir SHA1-s2--3f786850e387550fdab836ed7e6dc881
+
+7w/88
+
+f18/122
+
+
+Even if the 2 schemes were unified, this prefix-dir command would still be useful when hacking around git-annex (for now I need to maintain a dictionary structure).
+
+Thanks a lot.
diff --git a/doc/todo/wishlist__58___unify_directory_scheme_for_the_store/comment_1_44da58beaaab359ecaba7fb905ca4ae1._comment b/doc/todo/wishlist__58___unify_directory_scheme_for_the_store/comment_1_44da58beaaab359ecaba7fb905ca4ae1._comment
new file mode 100644
index 0000000000..86c33d4349
--- /dev/null
+++ b/doc/todo/wishlist__58___unify_directory_scheme_for_the_store/comment_1_44da58beaaab359ecaba7fb905ca4ae1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.243"
+ subject="comment 1"
+ date="2013-10-04T20:50:33Z"
+ content="""
+Using the mixed case hash directory names is not desirable because people want to use git-annex on a variety of filesystems and operating systems that treat them in a variety of broken ways. However, migrating to the all lower case hash directory names would require changing every git-annex symlink in every git repository, and I do not want to inflict that on my users.
+
+It seems to me that the best solution to your problem is to install git-annex on your server, which should not be very hard. 
+"""]]
diff --git a/doc/todo/wishlist__58___unify_directory_scheme_for_the_store/comment_2_bc698c501ecdb56df57171f4f3bb831a._comment b/doc/todo/wishlist__58___unify_directory_scheme_for_the_store/comment_2_bc698c501ecdb56df57171f4f3bb831a._comment
new file mode 100644
index 0000000000..5c5269f8cb
--- /dev/null
+++ b/doc/todo/wishlist__58___unify_directory_scheme_for_the_store/comment_2_bc698c501ecdb56df57171f4f3bb831a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"
+ nickname="Rafaël"
+ subject="comment 2"
+ date="2013-10-05T10:45:16Z"
+ content="""
+Thank you for prompt answer. I didn't know there were tarballs,
+and indeed I managed to install them easily (although I had to
+manually install glibc version 2.9, only 2.7 was installed).
+
+I found that bare git repos also use lower case hash directory
+names... I still would be happy with an optional migration to all
+lower case, with a new key-value backend, to avoid this little
+complication which happens sometimes (say when converting a repo
+from non-bare to bare).
+"""]]
diff --git a/doc/todo/wishlist__58___unify_directory_scheme_for_the_store/comment_3_e555d0dbbaa05528806905c6a940724b._comment b/doc/todo/wishlist__58___unify_directory_scheme_for_the_store/comment_3_e555d0dbbaa05528806905c6a940724b._comment
new file mode 100644
index 0000000000..e6acad3b94
--- /dev/null
+++ b/doc/todo/wishlist__58___unify_directory_scheme_for_the_store/comment_3_e555d0dbbaa05528806905c6a940724b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"
+ nickname="Rafaël"
+ subject="comment 3"
+ date="2013-10-07T13:33:40Z"
+ content="""
+By the way, I just had the case above, i.e. convert a bare repo to non-bare. In order to keep the annex files, I cloned the bare one, and git-annex move'ed all annex content to the new repo, and to my surprise it was slow, as if all files where copied (or maybe they were only checksummed?), instead of being only renamed (old and new repos were on the same partition). So I restate that at least a command line tool giving the prefix dirs would be useful, to allow scripting for this kind of situation.
+"""]]
diff --git a/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__.mdwn b/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__.mdwn
new file mode 100644
index 0000000000..425948efd6
--- /dev/null
+++ b/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__.mdwn
@@ -0,0 +1,5 @@
+I believe cloning a repository on the same filesystem already makes use of cp --reflink=auto, but it appears that git-annex-{get,copy} use rsync even when both repositories involved in the copy/get are on the same filesystem.
+
+Would it be possible for git-annex-get and git-annex-copy to use cp --reflink=auto when the source and destination repositories are on the same filesystem?
+
+[[!meta title="allow remotes to do their own, smarter diskreserve checking"]]
diff --git a/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_1_bbbb9c4c71b8c56eaf134b794d2345c3._comment b/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_1_bbbb9c4c71b8c56eaf134b794d2345c3._comment
new file mode 100644
index 0000000000..316e45a505
--- /dev/null
+++ b/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_1_bbbb9c4c71b8c56eaf134b794d2345c3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jscinoz@dc383eb6c5526eeb832a38ef5e5e626cf282ee6c"
+ nickname="jscinoz"
+ subject="comment 1"
+ date="2016-07-18T06:17:57Z"
+ content="""
+Oh, my mistake. It appears git-annex already does this - I mistakenly had one of the repositories in a different btrfs subvolume.
+"""]]
diff --git a/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_2_1eb09a234616cb0df7fed9016827dd0c._comment b/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_2_1eb09a234616cb0df7fed9016827dd0c._comment
new file mode 100644
index 0000000000..1669938332
--- /dev/null
+++ b/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_2_1eb09a234616cb0df7fed9016827dd0c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jscinoz@dc383eb6c5526eeb832a38ef5e5e626cf282ee6c"
+ nickname="jscinoz"
+ subject="comment 2"
+ date="2016-07-18T06:32:53Z"
+ content="""
+I suppose one enhancement could be to ignore annex.diskreserve when content is obtained by reflink copy, but I can imagine this would be difficult to achieve, since we don't know in advance whether or not --reflink=auto will actually result in a reflink copy. I imagine you could try reflink=always first, ignoring annex.diskreserve, then if it fails, fallback to reflink=auto where annex.diskreserve is checked, but perhaps this is too much filesystem-specific logic to be appropriate in git-annex.
+"""]]
diff --git a/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_3_942c2decd6dda0730e2efe4ed6e6cd16._comment b/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_3_942c2decd6dda0730e2efe4ed6e6cd16._comment
new file mode 100644
index 0000000000..92766fc275
--- /dev/null
+++ b/doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_3_942c2decd6dda0730e2efe4ed6e6cd16._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-07-19T14:57:14Z"
+ content="""
+Yes, reflink is used instead of rsync when it's able to determine it's the
+same filesystem.
+
+Not checking diskreserve for reflink (and also for hard link when
+annex.hardlink is set) would be nice. But, it's a layering problem
+since currently the diskreserve check is done separately from the transfer.
+
+The same layering problem also makes downloads from encrypted special
+remotes not check if there's space for both the encrypted and de-encrypted
+file content, in cases where both files are present on disk at the same
+time.
+
+So, there would be multiple benefits to improving the api somehow so more
+smart diskreserve checks can be done. Although I'd then worry that if
+remotes were responsible for doing diskreserve checks, they might be buggy
+and forget to check. 
+"""]]
diff --git a/doc/todo/wishlist__91__minor__93____58___add_time_stamps_to_annex_log_popups_in_webapp.mdwn b/doc/todo/wishlist__91__minor__93____58___add_time_stamps_to_annex_log_popups_in_webapp.mdwn
new file mode 100644
index 0000000000..e0b1b5f5fd
--- /dev/null
+++ b/doc/todo/wishlist__91__minor__93____58___add_time_stamps_to_annex_log_popups_in_webapp.mdwn
@@ -0,0 +1 @@
+otherwise now it is impossible to judge how old those are when opening the dashboard
diff --git a/doc/todo/wishlist__91__minor__93____58___add_time_stamps_to_annex_log_popups_in_webapp/comment_1_ec90432a7d46383071401b05243d621f._comment b/doc/todo/wishlist__91__minor__93____58___add_time_stamps_to_annex_log_popups_in_webapp/comment_1_ec90432a7d46383071401b05243d621f._comment
new file mode 100644
index 0000000000..97760e7391
--- /dev/null
+++ b/doc/todo/wishlist__91__minor__93____58___add_time_stamps_to_annex_log_popups_in_webapp/comment_1_ec90432a7d46383071401b05243d621f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://olivier.mehani.name/"
+ nickname="olivier-mehani"
+ subject="comment 1"
+ date="2014-01-16T02:22:18Z"
+ content="""
++1
+"""]]
diff --git a/doc/todo/wishlist_degraded_files.mdwn b/doc/todo/wishlist_degraded_files.mdwn
new file mode 100644
index 0000000000..0b265c5eba
--- /dev/null
+++ b/doc/todo/wishlist_degraded_files.mdwn
@@ -0,0 +1,5 @@
+This is an idea to have a small placeholder file that is put into
+place when the file's actual content is not available in the local
+annex.
+
+Details being discussed here: <http://bugs.debian.org/728552>
diff --git a/doc/todo/withExclusiveLock_blocking_issue.mdwn b/doc/todo/withExclusiveLock_blocking_issue.mdwn
new file mode 100644
index 0000000000..32c750ed7b
--- /dev/null
+++ b/doc/todo/withExclusiveLock_blocking_issue.mdwn
@@ -0,0 +1,83 @@
+Some parts of git-annex wait for an exclusive lock, and once they take it,
+hold it while performing an operation. Now consider what happens if the
+git-annex process is suspended. Another git-annex process that is running
+and that waits to take the same exclusive lock (or a shared lock of the
+same file) will stall forever, until the git-annex process is resumed.
+
+These time windows tend to be small, but may not always be.
+
+Is there any better way git-annex could handle this? Is it a significant
+problem at all? I don't think I've ever seen it happen, but I rarely ^Z
+git-annex either. How do other programs handle this, if at all?
+--[[Joey]]
+
+----
+
+Would it be better for the second git-annex process, rather than hanging
+indefinitely, to timeout after a few seconds?
+
+But how many seconds? What if the system is under heavy load?
+
+> What could be done is, update the lock's file's mtime after successfully
+> taking the lock. Then, as long as the mtime is advancing, some other
+> process is actively using it, and it's ok for our process to wait
+> longer.
+> 
+> (Updating the mtime would be a problem when locking annex object files
+> in v9 and earlier. Luckily, that locking is not done with a blocking
+> lock anyway.)
+
+> If the lock file's mtime is being checked, the process that is
+> blocking with the lock held could periodically update the mtime.
+> A background thread could manage that. If that's done every ten seconds,
+> then an mtime more than 20 seconds old indicates that the lock is
+> held by a suspended process. So git-annex would stall for up to 20-30
+> seconds before erroring out when a lock is held by a suspended process.
+> That seems acceptible, it doesn't need to deal with this situation
+> instantly, it just needs to not block indefinitely. And updating the
+> mtime every 10 seconds should not be too much IO.
+> 
+> When an old version of git-annex has the lock held, it won't be updating
+> the mtime. So if it takes longer than 10 seconds to do the operation with
+> the lock held, a new version may complain that it's suspended when it's
+> really not. This could be avoided by checking what process holds the
+> lock, and whether it's suspended. But probably 10 seconds is enough
+> time for all the operations git-annex takes a blocking lock for
+> currently to finish, and if so we don't need to worry about this situation?
+> 
+> >  Unfortunately not: importKeys takes an exclusive lock and holds it while
+> > downloading all the content! This seems like a bug though, because it can
+> > cause other git-annex processes that are eg storing content in a remote
+> > to block for a long time.
+> > 
+> > Another one is Database.Export.writeLockDbWhile, which takes an
+> > exclusive lock while running eg, Command.Export.changeExport,
+> > which may sometimes need to do a lot of work.
+> >
+> > Another one is Annex.Queue.flush, which probably mostly runs in under
+> > 10 seconds, but maybe not always, and when annex.queuesize is changed,
+> > could surely take longer.
+> 
+> To avoid problems when old git-annex's are also being used, it could
+> update and check the mtime of a different file than the lock file.
+> 
+> Start by trying to take the lock for up to 10 seconds. If it takes the
+> lock, create the mtime file and start a thread that updates the mtime 
+> every 10 seconds until the lock is closed, and delete the mtime file
+> before closing the lock handle. 
+> 
+> When it times out taking the lock, if the mtime file does not exist, an
+> old git-annex has the lock; if the mtime file does exist, then check
+> if its timestamp has advanced; if not then a new git-annex has the lock
+> and is suspended and it can error out.
+> 
+> Oops: There's a race in the method above; a timeout may occur
+> right when the other process has taken the lock, but has not updated
+> the mtime file yet. Then that process would incorrectly be treated
+> as an old git-annex process.
+> 
+> So: To support old git-annex, it seems it will need to check, when the
+> lock is held, what process has the lock. And then check if that process
+> is suspended or not. Which means looking in /proc. Ugh.
+> 
+> Or: Change to checking lock mtimes only in git-annex v11..
diff --git a/doc/todo/worktree_overwrite_races.mdwn b/doc/todo/worktree_overwrite_races.mdwn
new file mode 100644
index 0000000000..d11bb3c7e8
--- /dev/null
+++ b/doc/todo/worktree_overwrite_races.mdwn
@@ -0,0 +1,45 @@
+Similar to [[bugs/add_overwrite_race]], several callers of
+replaceWorkTreeFile are susceptable to a race. They do some check of the
+current content of the file, and then they call that to replace it with
+something else. But in between, the file could be overwritten with other
+content. And that content then gets overwritten.
+
+This is probably not a bug, because `git checkout` actually has the same
+problem, IIRC. And if git does that, it's ok for git-annex to also.
+
+Still, this affects several git-annex commands, and it would be better to
+avoid it. To avoid it, replaceWorkTreeFile could be provided with a
+Maybe FileStatus of the content that was in the worktree that is ok to
+overwrite. Then atomically swap the current worktree file and the new 
+file, and afterwards check if the old worktree file is unmodifified,
+moving it back if it is modified.
+
+(Note that, this will not help with situations where the worktree file
+is opened for append, but gets replaced by git-annex before being written
+to. A later write will be to a deleted file.)
+
+The atomic swap would need a call to `renameat2()` with
+`RENAME_EXCHANGE`. There does not seem to be a binding for that
+in any haskell library. Also, it is linux-specific, though may also
+have reached freebsd?
+
+Hmm, but even this could lead to file corruption. Suppose that a process
+is opening the worktree file for append, writing a byte, closing it, and
+repeating. The bytes are `[1,2,3,...]`. The worktree file
+has 1 appended to it. Then renameat2 swaps the files. The new file gets
+2 appended to it. The worktree file was modified, so is moved back into
+place. It gets 3 appended to it. So the worktree file ends up containing
+`1,3`.
+
+So, perhaps there is really no good solution to this. --[[Joey]]
+
+> I suppose the balance of probabilities is that a worktree file being
+> overwritten in the current race window is fairly plausibly likely, 
+> while a file being repeatedly appended to in that way is very unlikely.
+> 
+> But the balance of ill effects is that in the current case you lose data
+> in a way that is easy to understand (and that git is also subject to),
+> and in the repeated append case, a file gets into a state it never ought
+> to possibly be in.
+> 
+> So I think it makes sense to abandon this idea. [[done]] --[[Joey]]
diff --git a/doc/todo/yt-dlp__58___parse__47__handle___40__error__41_____34__Video_unavailable__34__.mdwn b/doc/todo/yt-dlp__58___parse__47__handle___40__error__41_____34__Video_unavailable__34__.mdwn
new file mode 100644
index 0000000000..9b2ac720d8
--- /dev/null
+++ b/doc/todo/yt-dlp__58___parse__47__handle___40__error__41_____34__Video_unavailable__34__.mdwn
@@ -0,0 +1,94 @@
+ATM `git-annex addurl` would happily download HTML from youtube instead of errorring, which would probably a better behavior, if video was removed from YouTube or made private.  E.g.
+
+<details>
+<summary>here is a detailed git annex --debug addurl output</summary> 
+
+```shell
+$> git annex --debug addurl --file Комендантські_балачки/2024-01-28-___Стрім_20_30_28.01.2024_чат_рулетка_LIVE_стрим._Андрій_Попик.mkv https://www.youtube.com/watch?v=jy01CnsQ9ec
+[2024-01-29 16:55:36.511153059] (Utility.Process) process [2205617] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","git-annex"]
+[2024-01-29 16:55:36.515415282] (Utility.Process) process [2205617] done ExitSuccess
+[2024-01-29 16:55:36.515888181] (Utility.Process) process [2205618] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/heads/git-annex"]
+[2024-01-29 16:55:36.519652103] (Utility.Process) process [2205618] done ExitSuccess
+[2024-01-29 16:55:36.521989271] (Utility.Process) process [2205619] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+addurl https://www.youtube.com/watch?v=jy01CnsQ9ec
+[2024-01-29 16:55:36.546921281] (Utility.Url) Request {
+  host                 = "www.youtube.com"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding",""),("User-Agent","git-annex/10.20231227-1~ndall+1")]
+  path                 = "/watch"
+  queryString          = "?v=jy01CnsQ9ec"
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+  proxySecureMode      = ProxySecureWithConnect
+}
+
+[2024-01-29 16:55:36.767345074] (Utility.Process) process [2205641] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","symbolic-ref","-q","HEAD"]
+[2024-01-29 16:55:36.771989935] (Utility.Process) process [2205641] done ExitSuccess
+[2024-01-29 16:55:36.772619847] (Utility.Process) process [2205642] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","refs/heads/master"]
+[2024-01-29 16:55:36.777260151] (Utility.Process) process [2205642] done ExitSuccess
+[2024-01-29 16:55:36.778775886] (Utility.Process) process [2205643] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","check-attr","-z","--stdin","annex.backend","annex.largefiles","annex.numcopies","annex.mincopies","--"]
+[2024-01-29 16:55:36.78290662] (Utility.Url) Request {
+  host                 = "www.youtube.com"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding","identity"),("User-Agent","git-annex/10.20231227-1~ndall+1")]
+  path                 = "/watch"
+  queryString          = "?v=jy01CnsQ9ec"
+  method               = "GET"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+  proxySecureMode      = ProxySecureWithConnect
+}
+
+[2024-01-29 16:55:36.982919787] (Utility.Process) process [2205644] read: yt-dlp ["https://www.youtube.com/watch?v=jy01CnsQ9ec","--get-filename","--no-warnings","--no-playlist"]
+[2024-01-29 16:55:38.035161914] (Utility.Process) process [2205644] done ExitFailure 1
+[2024-01-29 16:55:38.036097212] (Utility.Process) p(to Комендантські_балачки/2024-01-28-___Стрім_20_30_28.01.2024_чат_рулетка_LIVE_стрим._Андрій_Попик.mkv) "--stdin","--verbose","--non-matching"]
+[2024-01-29 16:55:38.054030685] (Messages.explain) [ Комендантські_балачки/2024-01-28-___Стрім_20_30_28.01.2024_чат_рулетка_LIVE_стрим._Андрій_Попик.mkv does not match annex.largefiles: mimeencoding=binary[FALSE] ]
+                                                                                                                                                            (non-large file; adding content to git repository)
+[2024-01-29 16:55:38.054895156] (Utility.Process) process [2205761] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","hash-object","-w","--no-filters","--stdin-paths"]
+[2024-01-29 16:55:38.072695867] (Utility.Process) process [2205762] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","-c","filter.annex.smudge=","-c","filter.annex.clean=","-c","filter.annex.process=","write-tree"]
+[2024-01-29 16:55:38.078372317] (Utility.Process) process [2205762] done ExitSuccess
+[2024-01-29 16:55:38.07887887] (Utility.Process) process [2205763] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","show-ref","--hash","refs/annex/last-index"]
+addurl https://www.youtube.com/watch?v=jy01CnsQ9ec (to Комендантські_балачки/2024-01-28-___Стрім_20_30_28.01.2024_чат_рулетка_LIVE_стрим._Андрій_Попик.mkv) (non-large file; adding content to git repository) ok
+(recording state in git...)
+[2024-01-29 16:55:38.083368582] (Utility.Process) process [2205764] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","update-index","-z","--index-info"]
+[2024-01-29 16:55:38.129969795] (Utility.Process) process [2205764] done ExitSuccess
+[2024-01-29 16:55:38.130183526] (Database.Handle) commitDb start
+[2024-01-29 16:55:38.130668768] (Database.Handle) commitDb done
+[2024-01-29 16:55:38.131339954] (Utility.Process) process [2205619] done ExitSuccess
+[2024-01-29 16:55:38.131872474] (Utility.Process) process [2205643] done ExitSuccess
+[2024-01-29 16:55:38.132363417] (Utility.Process) process [2205761] done ExitSuccess
+[2024-01-29 16:55:38.132786755] (Utility.Process) process [2205760] done ExitFailure 1
+
+$> file -L Комендантські_балачки/2024-01-28-___Стрім_20_30_28.01.2024_чат_рулетка_LIVE_стрим._Андрій_Попик.mkv
+Комендантські_балачки/2024-01-28-___Стрім_20_30_28.01.2024_чат_рулетка_LIVE_стрим._Андрій_Попик.mkv: HTML document, ASCII text, with very long lines (56909)
+
+```
+</details>
+
+whenever that video is now announced to be Private if you go to that youtube url or `yt-dlp` saying that 
+
+```shell
+❯ yt-dlp https://www.youtube.com/watch?v=jy01CnsQ9ec --get-filename --no-warnings --no-playlist
+ERROR: [youtube] jy01CnsQ9ec: Video unavailable. This video has been removed by the uploader
+❯ yt-dlp --version
+2023.11.16
+```
+
+note that if I fake up that youtube url by changing letter to the next `d` - response does not include any reason
+
+```shell
+❯ yt-dlp https://www.youtube.com/watch?v=jy01CnsQ9ed --get-filename --no-warnings --no-playlist
+ERROR: [youtube] jy01CnsQ9ed: Video unavailable
+```
+
+> I don't consider this a bug because with --no-raw it will do what you
+> want. [[done]] --[[Joey]]
diff --git a/doc/todo/yt-dlp__58___parse__47__handle___40__error__41_____34__Video_unavailable__34__/comment_1_8b761cfc9b2ca784efc15b39689c31f5._comment b/doc/todo/yt-dlp__58___parse__47__handle___40__error__41_____34__Video_unavailable__34__/comment_1_8b761cfc9b2ca784efc15b39689c31f5._comment
new file mode 100644
index 0000000000..59cc38f565
--- /dev/null
+++ b/doc/todo/yt-dlp__58___parse__47__handle___40__error__41_____34__Video_unavailable__34__/comment_1_8b761cfc9b2ca784efc15b39689c31f5._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-01-30T19:43:50Z"
+ content="""
+To get the behavior you want, use `--no-raw`:
+
+	git-annex addurl --no-raw 'https://www.youtube.com/watch?v=jy01CnsQ9ec'
+	addurl https://www.youtube.com/watch?v=jy01CnsQ9ec
+	
+	  Unable to use youtube-dl or a special remote and --no-raw was specified: no media in url
+	failed
+	addurl: 1 failed
+
+Bear in mind that yt-dlp supports many websites, not just youtube, and youtube
+probably has many domains (eg `youtu.be`). And addurl can legitimately be used
+when you want to archive the current content of an url. So in this case
+git-annex can't distinguish between a webpage with a withdrawn or private video
+and any other url that a user would expect it to download.
+"""]]
diff --git a/doc/transferring_data.mdwn b/doc/transferring_data.mdwn
new file mode 100644
index 0000000000..2aab3b01f9
--- /dev/null
+++ b/doc/transferring_data.mdwn
@@ -0,0 +1,19 @@
+git-annex can transfer data to or from any of a repository's git remotes.
+Depending on where the remote is, the data transfer is done using rsync
+(over ssh or locally), or plain cp (with copy-on-write
+optimisations on supported filesystems), or using curl (for repositories
+on the web). Some [[special_remotes]] are also supported that are not
+traditional git remotes.
+
+If a data transfer is interrupted, git-annex retains the partial transfer
+to allow it to be automatically resumed later.
+
+It's equally easy to transfer a single file to or from a repository,
+or to launch a retrieval of a massive pile of files from whatever
+repositories they are scattered amongst.
+
+git-annex automatically uses whatever remotes are currently accessible,
+preferring ones that are less expensive to talk to.
+
+[[!img repomap.png caption="A real-world repository interconnection map
+(generated by git-annex map)"]]
diff --git a/doc/trust.mdwn b/doc/trust.mdwn
new file mode 100644
index 0000000000..b348a6dc06
--- /dev/null
+++ b/doc/trust.mdwn
@@ -0,0 +1,65 @@
+Git-annex supports several levels of trust of a repository:
+
+* semitrusted (default)
+* untrusted
+* trusted
+* dead
+
+## semitrusted
+
+Normally, git-annex does not fully trust its stored [[location_tracking]]
+information. When removing content, it will directly check
+that other repositories have enough [[copies]].
+
+Generally that explicit checking is a good idea. Consider that the current
+[[location_tracking]] information for a remote may not yet have propagated
+out. Or, a remote may have suffered a catastrophic loss of data, or itself
+been lost.
+
+There is still some trust involved here. A semitrusted repository is
+depended on to retain a copy of the file content; possibly the only
+[[copy|copies]].
+
+(Being semitrusted is the default. The [[git-annex semitrust|git-annex-semitrust]] command
+restores a repository to this default, when it has been overridden.
+The `--semitrust` option can temporarily restore a repository to this
+default.)
+
+## untrusted
+
+An untrusted repository is not trusted to retain data at all. Git-annex
+will retain sufficient [[copies]] of data elsewhere.
+
+This is a good choice for eg, portable drives that could get lost. Or,
+if a disk is known to be dying, you can set it to untrusted and let
+`git annex fsck` warn about data that needs to be copied off it.
+
+To configure a repository as untrusted, use the [[git-annex untrust|git-annex-untrust]]
+command.
+
+## trusted
+
+Sometimes, you may have reasons to fully trust the location tracking
+information for a repository. For example, it may be an offline
+archival drive, from which you rarely or never remove content. Deciding
+when it makes sense to trust the tracking info is up to you.
+
+To configure a repository as fully and permanently trusted,
+use the [[git-annex-trust]] command.
+
+Note that after dropping content from a trusted repo, other repos
+that are out of sync and trust it to still contain the content
+can drop copies, even though that will violate [[numcopies]]. So
+using trusted repositories can lead to data loss. It is best to take
+extreme care when dropping content from trusted repositories,
+the same as if you were using `--force`.
+
+## dead
+
+This is used to indicate that you have no trust that the repository
+exists at all. It's appropriate to use when a drive has been lost,
+or a directory irretrievably deleted. It will make git-annex avoid
+even showing the repository as a place where data might still reside.
+
+To configure a repository as dead and lost, use the [[git-annex-dead]]
+command.
diff --git a/doc/trust/comment_1_305e4e7c6b75db29212b758e8504d8c9._comment b/doc/trust/comment_1_305e4e7c6b75db29212b758e8504d8c9._comment
new file mode 100644
index 0000000000..11c6ce1335
--- /dev/null
+++ b/doc/trust/comment_1_305e4e7c6b75db29212b758e8504d8c9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlJl0OCe6AJEnIFIcg-t5Rhk-lI_Y-tWUs"
+ nickname="Michael"
+ subject="default trust for hosts"
+ date="2015-05-01T21:41:05Z"
+ content="""
+Is it possible to set a default trust per host (e.g. in `~/.gitconfig`)?
+
+I have one server that does its own backups, and a client that I'd like to keep thin across multiple repositories.
+"""]]
diff --git a/doc/trust/comment_2_2262eaa830306d3dc75999bc0433b6a8._comment b/doc/trust/comment_2_2262eaa830306d3dc75999bc0433b6a8._comment
new file mode 100644
index 0000000000..b2136f43ea
--- /dev/null
+++ b/doc/trust/comment_2_2262eaa830306d3dc75999bc0433b6a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-05-05T18:07:02Z"
+ content="""
+You can use `remote.<name>.annex-trustlevel` as documented in the git-annex
+man page.
+"""]]
diff --git a/doc/tuning.mdwn b/doc/tuning.mdwn
new file mode 100644
index 0000000000..1860295465
--- /dev/null
+++ b/doc/tuning.mdwn
@@ -0,0 +1,47 @@
+git-annex now has experimental support for tuning a repository for
+different work loads. 
+
+For example, a repository with a very large number of files in it may work
+better if git-annex uses some nonstandard hash format, for either the
+`.git/annex/objects/` directory, or for the log files in the git-annex
+branch.
+
+A repository can currently only be tuned when it is first created; this is
+done by passing `-c name=value` parameters to `git annex init`.
+
+For example, this will make git-annex use only 1 level for hash directories
+in `.git/annex/objects`:
+
+	git -c annex.tune.objecthash1=true annex init
+
+It's very important to keep in mind that this makes a nonstandard format
+git-annex repository. In general, this cannot safely be used with
+git-annex older than version 5.20150128. Older version of git-annex will
+not understand and will get confused and perhaps do bad things.
+
+Also, it's not safe to merge two separate git repositories that have been
+tuned differently (or one tuned and the other one not). git-annex will
+prevent merging their git-annex branches together, but it cannot prevent
+`git merge remote/master` merging two branches, and the result will be ugly
+at best (`git annex fix` can fix up the mess somewhat).
+
+Again, tuned repositories are an experimental feature; use with caution!
+
+The following tuning parameters are available:
+
+* `annex.tune.objecthash1=true`  
+  Use just one level of hash directories in `.git/annex/objects/`,
+  instead of the default two levels.
+
+* `annex.tune.objecthashlower=true`  
+  Make the hash directories in `.git/annex/objects/` use
+  all lower-case, instead of the default mixed-case.
+
+* `annex.tune.branchhash1=true`  
+  Use just one level of hash directories in the git-annex branch,
+  instead of the default two levels.
+
+Note that git-annex will automatically propagate these settings to
+`.git/config` for tuned repositories. You should never directly change
+these settings in `.git/config`, and should never set them in global
+gitconfig.
diff --git a/doc/tuning/comment_1_f8af8e9b696d32d238ebd56a3b8058c4._comment b/doc/tuning/comment_1_f8af8e9b696d32d238ebd56a3b8058c4._comment
new file mode 100644
index 0000000000..92a26fb1de
--- /dev/null
+++ b/doc/tuning/comment_1_f8af8e9b696d32d238ebd56a3b8058c4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="annex.tune.objecthashlower=true is not just &quot;lower&quot; letters used but a different strategy altogether"
+ date="2015-02-01T02:58:26Z"
+ content="""
+it starts to use 2 levels (even if annex.tune.objecthash1=true) of hash directories having 3 characters in the filename at each level.  So it is not just \"taken existing hash directories (1 or 2 levels) and use their lower-case version.  It is a different way to create the hash directories:
+
+e.g.  one with objecthas1=true
+
+1 -> .git/annex/objects/qj/SHA256E-s6--ecdc5536f73bdae8816f0ea40726ef5e9b810d914493075903bb90623d97b1d8/SHA256E-s6--ecdc5536f73bdae8816f0ea40726ef5e9b810d914493075903bb90623d97b1d8
+
+and if I provide all three options at once:
+
+1 -> .git/annex/objects/ccf/a40/SHA256E-s6--ecdc5536f73bdae8816f0ea40726ef5e9b810d914493075903bb90623d97b1d8/SHA256E-s6--ecdc5536f73bdae8816f0ea40726ef5e9b810d914493075903bb90623d97b1d8
+
+"""]]
diff --git a/doc/tuning/comment_2_a0091dbb39b79dfe101d05f9a5db216f._comment b/doc/tuning/comment_2_a0091dbb39b79dfe101d05f9a5db216f._comment
new file mode 100644
index 0000000000..364d2c9da1
--- /dev/null
+++ b/doc/tuning/comment_2_a0091dbb39b79dfe101d05f9a5db216f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-02-04T17:09:41Z"
+ content="""
+Right, it's not simply lower-casing but a different hash strategy
+as described in [[internals/hashing]].
+
+Combining annex.tune.objecthashlower and annex.tune.objecthash1 will
+result in one level of hash directories. If you get two levels then
+you probabaly typoed "objecthas1" ...
+"""]]
diff --git a/doc/tuning/comment_4_1c576f9a5e0a0b5d7d8edf9d40462874._comment b/doc/tuning/comment_4_1c576f9a5e0a0b5d7d8edf9d40462874._comment
new file mode 100644
index 0000000000..5d3d2f0a47
--- /dev/null
+++ b/doc/tuning/comment_4_1c576f9a5e0a0b5d7d8edf9d40462874._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-08-28T17:40:06Z"
+ content="""
+It should be possible to write a `git-filter-branch` that converts
+a repository from one tuning to aonther, but it would not be trivial, and
+noone has done it yet. You'd still have to run it in every clone of the
+repository. Tuned and non-tuned repositories can't interoperate.
+"""]]
diff --git a/doc/tuning/comment_4_5b782975263480a405c5e8dcfe058007._comment b/doc/tuning/comment_4_5b782975263480a405c5e8dcfe058007._comment
new file mode 100644
index 0000000000..d7ee5b4a87
--- /dev/null
+++ b/doc/tuning/comment_4_5b782975263480a405c5e8dcfe058007._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Syncing between untuned and tuned repo?"
+ date="2017-07-18T11:49:10Z"
+ content="""
+> Also, it's not safe to merge two separate git repositories that have been tuned differently (or one tuned and the other one not). git-annex will prevent merging their git-annex branches together, but it cannot prevent git merge remote/master merging two branches, and the result will be ugly at best (git annex fix can fix up the mess somewhat).
+
+My main use repo is 1.7TB large and holds 172.000+ annexed files.
+Variations in filename case has lead to a number of file duplications that are still not solved (I have base scripts that can be used to flatten filename case and fix references in other files, but it will probably mean handling some corner cases and there are more urgent matters for now).  
+
+For these reasons I'm highly interested in the lowercase option and I'm probably not the only one in a similar case.
+
+Does migrating to a tuned repository mean unannexing everything and reimporting into a newly created annex, replica by replica then sync again? That's a high price in some setup.  Or is there a way to somehow `git annex sync` between a newly created repo and an old, untuned one?
+
+"""]]
diff --git a/doc/tuning/comment_5_0143b798e75ad25c5917794a49a879fb._comment b/doc/tuning/comment_5_0143b798e75ad25c5917794a49a879fb._comment
new file mode 100644
index 0000000000..aee3de42db
--- /dev/null
+++ b/doc/tuning/comment_5_0143b798e75ad25c5917794a49a879fb._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="imlew"
+ avatar="http://cdn.libravatar.org/avatar/23858c3eed3c3ea9e21522f4c999f1ed"
+ subject="Still experimental?"
+ date="2024-03-06T12:26:56Z"
+ content="""
+`annex.tune.objecthash1=true` and `annex.tune.branchhash1=true` seem like they could be helpful in reducing git annex's inode usage, but the disclaimer about this feature being experimental is a little worrying.
+
+Since this it is over 10 years old though, is it still considered experimental or has it graduated to being a stable feature? I.e. will using this meaningfully increase the chance of losing data?
+
+
+Also, what is the (potential) benefit of using lowercase for the hashes?
+"""]]
diff --git a/doc/upgrades.mdwn b/doc/upgrades.mdwn
new file mode 100644
index 0000000000..7d48547d82
--- /dev/null
+++ b/doc/upgrades.mdwn
@@ -0,0 +1,179 @@
+[[!toc levels=3]]
+
+# Software upgrades
+
+Upgrading the code base of git-annex will be done differently depending on
+your [[install]] method. For most distribution-based packages, it is
+handled by the package management software.
+
+For the standalone distribution, the [[git-annex-webapp]](1) will ask the
+user for confirmation when it detects a new version. Once that is
+confirmed, or if `annex.autoupgrade` is enabled (see the [[git-annex]](1)
+manpage) the assistant will start the upgrade. The upgrade process is
+fairly simple: the assistant will move the `git-annex.linux` directory out
+of the way and replace it with the new version, then re-execute itself. It
+therefore needs write access to the parent directory of the
+`git-annex.linux` directory.
+
+Note that "upgrading" from a distribution-based package to the
+[[install/Linux_standalone/]] version may cause weird problems, as an
+unexpected version of git-annex (e.g. the old one from packages) may be
+ran.
+
+# Repository upgrades
+
+Occasionally improvements are made to how git-annex stores its data,
+that require an upgrade process to convert repositories made with an older
+version to be used by a newer version. It's annoying, it should happen
+rarely, but sometimes, it's worth it.
+
+There's a commitment that git-annex will always support upgrades from all
+past versions. After all, you may have offline drives from an earlier
+git-annex, and might want to use them with a newer git-annex.
+
+git-annex will notice if it is run in a repository that
+needs an upgrade, and either automatically upgrade it or
+refuse to do anything. To upgrade, use the "git annex upgrade" command.
+
+To prevent automatic upgrades in a repository, run:
+`git config annex.autoupgraderepository false`
+
+The upgrade process is guaranteed to be conflict-free. Unless you
+already have git conflicts in your repository or between repositories.
+Upgrading a repository with conflicts is not recommended; resolve the
+conflicts first before upgrading git-annex.
+
+The upgrade process needs to write to the repository. If the original
+repository cannot be written to (due to eg being on readonly media),
+the upgrade would need to be run in a copy of the repository.
+
+The upgrade events, so far:
+
+## v9 -> v10 (git-annex version 10.x)
+
+v10 repositories change a fundamental part of how git-annex does locking.
+
+v9 repositories are automatically upgraded to v10, but with a delay.
+The upgrade happens one year after the repository was upgraded to v9.
+This delay is because it would not be safe to upgrade to v10 if a
+git-annex process version 8.x was still running. Waiting a year makes
+it very unlikely that such a process is still running.
+
+## v8 -> v9 (git-annex version 10.x)
+
+v8 repositories are automatically upgraded to v9.
+
+v9 is a stepping stone to the v10 upgrade. By adding this intermediate
+version, old versions of git-annex that only support v8 will not be able to
+start new processes in the repository after the v9 upgrade.
+
+v9 also enables using `git-annex filter-process`. This can significantly
+speed up git operations involving unlocked files.
+
+## v7 -> v8 (git-annex version 8.x)
+
+v7 repositories are automatically upgraded to v8.
+
+Some sqlite databases that git-annex uses were changed in v8 and have to be
+re-populated. As a consequence:
+
+* Any incremental fscks that were started in v7 won't resume where they left
+  off in v8, but will instead begin again from the first file.
+
+* An interrupted export that was started in v7 won't resume where it left off
+  after upgrade to v8; files will be re-uploaded to the export remote.
+
+* After the upgrade, git-annex will in some situations have to do extra
+  work while it finishes populating the new databases. After this one-time
+  speed cost, git-annex's speed will improve when using the new and improved
+  databases.
+
+Also, there are some behavior changes around adding dotfiles. While before
+git-annex add skipped adding dotfiles when operating on whole directories,
+and added dotfiles that were explicitly listed to the annex, it now adds
+dotfiles to git by default, unless annex.dotfiles is set to true.
+
+## v6 -> v7 (git-annex version 7.x)
+
+v6 repositories are automatically upgraded to v7.
+
+The only difference between v6 and v7 is that some additional git hooks
+were added in v7.
+
+## v5 -> v6 (git-annex version 6.x)
+
+v5 repositories are automatically upgraded to v6.
+
+A v6 git-annex repository can have some files locked while other files are
+unlocked, and all git and git-annex commands can be used on both locked and
+unlocked files. It's a good idea to make sure that all users of the
+repository have upgraded git-annex and upgraded their repositories
+to the new version before starting to use this feature, since old
+versions of git-annex will ignore the new unlocked files.
+
+Direct mode repositories are upgraded to instead use the new 
+[[adjusted branches feature|git-annex-adjust]], which transparently unlocks
+all locked files in the local repository.
+
+The behavior of some commands changes in an upgraded repository:
+
+* When `annex.largefiles` is configured, git add` will add matching 
+   files to the annex, rather than adding them directly to the git
+   repository.
+
+* `git annex unlock` and `git annex lock` change how the pointer to 
+  the annexed content is stored in git. If you commit the change,
+  that will impact all clones of the repository. This means all clones of the
+  repository will need to run at least v6 to correctly synchronise.
+
+There is also a new `annex.thin` setting, which makes unlocked files in v6
+repositories be hard linked to their content, instead of a copy. This saves
+disk space but means any modification of an unlocked file will lose the
+local (and possibly only) copy of the old version. This is automatically
+enabled when upgrading a direct mode repository, since direct mode made the
+same tradeoff.
+
+See [[tips/unlocked_files/]] for more details about locked files and thin
+mode.
+
+## v4 -> v5 (git-annex version 5.x)
+
+The upgrade from v4 to v5 is handled
+automatically, and only affects [[direct mode]] repositories.
+
+This upgrade involves changing direct mode repositories to operate with
+core.bare=true.
+
+## v3 -> v4 (git-annex version 4.x)
+
+v4 was only used for [[direct_mode]], to ensure that a version of git-annex
+that understands direct mode was used with a direct mode repository. 
+
+## v2 -> v3 (git-annex version 3.x)
+
+Involved moving the .git-annex/ directory into a separate git-annex branch.
+
+After this upgrade, you should make sure you include the git-annex branch
+when git pushing and pulling.
+
+## v1 -> v2 (git-annex version 0.20110316)
+
+Involved adding hashing to .git/annex/ and changing the names of all keys.
+Symlinks changed.
+
+Also, hashing was added to location log files in .git-annex/.
+And .gitattributes needed to have another line added to it.
+
+Previously, files added to the SHA [[backends]] did not have their file
+size tracked, while files added to the WORM backend did. Files added to
+the SHA backends after the conversion will have their file size tracked,
+and that information will be used by git-annex for disk free space checking.
+To ensure that information is available for all your annexed files, see
+[[upgrades/SHA_size]].
+
+## v0 -> v1 (git-annex version 0.04)
+
+Involved a reorganisation of the layout of .git/annex/. Symlinks changed.
+
+Handled more or less transparently, although git-annex was just 2 weeks
+old at the time, and had few users other than Joey.
diff --git a/doc/upgrades/SHA_size.mdwn b/doc/upgrades/SHA_size.mdwn
new file mode 100644
index 0000000000..97603ba913
--- /dev/null
+++ b/doc/upgrades/SHA_size.mdwn
@@ -0,0 +1,20 @@
+Before version 2 of the git-annex repository, files added to the SHA
+[[backends]] did not have their file size tracked, while files added to the
+WORM backend did. The file size information is used for disk free space
+checking.
+
+Files added to the SHA backends after the conversion will have their file
+size tracked automatically. This disk free space checking is an optional
+feature and since you're more likely to be using more recently added files,
+you're unlikely to see any bad effect if you do nothing.
+
+That said, if you have old files added to SHA backends that lack file size
+tracking info, here's how you can add that info. After [[upgrading|upgrades]]
+to repository version 2, in each repository run:
+
+	git annex migrate
+	git commit -m 'migrated keys for v2'
+
+The usual caveats about [[tips/migrating_data_to_a_new_backend]]
+apply; you will end up with unused keys that you can later clean up with
+`git annex unused`.
diff --git a/doc/upgrades/SHA_size/comment_1_20f9b7b75786075de666b2146dc13a60._comment b/doc/upgrades/SHA_size/comment_1_20f9b7b75786075de666b2146dc13a60._comment
new file mode 100644
index 0000000000..7b6be15321
--- /dev/null
+++ b/doc/upgrades/SHA_size/comment_1_20f9b7b75786075de666b2146dc13a60._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkjvjLHW9Omza7x1VEzIFQ8Z5honhRB90I"
+ nickname="Asheesh"
+ subject="The fact that the keys changed causes merge conflicts"
+ date="2012-06-25T00:28:59Z"
+ content="""
+FYI, I have run into a problem where if you 'git annex sync' between various 'git annex v3' repositories, if the different repositories are using different encodings of the SHA1 information (one including size, one not), then the 'git merge' will declare that they conflict.
+
+There's no indication that 'git annex migrate' is the right tool to run, except from perusing the 'git annex' man page. In my opinion this is a major user interface problem.
+
+-- Asheesh.
+"""]]
diff --git a/doc/upgrades/gcrypt.mdwn b/doc/upgrades/gcrypt.mdwn
new file mode 100644
index 0000000000..65f80f86e0
--- /dev/null
+++ b/doc/upgrades/gcrypt.mdwn
@@ -0,0 +1,25 @@
+Unfortunately the initial gcrypt repository layout had to be changed
+after git-annex version 4.20130920. If you have an encrypted git repository
+created using version 4.20130920 or 4.20130909, you need to manually
+upgrade it.
+
+If you look at the contents of your gcrypt repository, you will
+see a bare git repository, with a few three-letter subdirectories,
+which are where git-annex stores its encrypted file contents:
+
+<pre>
+27f/  branches/  description  hooks/  objects/
+HEAD  config     f37/         info/   refs/
+</pre>
+
+In the example above, the subdirectories are `27f` and `f37`.
+
+All you need to do to transition is move those subdirectories
+into an `annex/objects` directory.
+
+	mkdir annex ; mkdir annex/objects ; mv 27f f37 annex/objects
+
+Probably those are the only 3 letter things inside your git repository,
+so this will probably work:
+
+	mkdir annex ; mkdir annex/objects ; mv ??? annex/objects
diff --git a/doc/upgrades/gcrypt/comment_1_606c1527735996ae671f78948e4ad84b._comment b/doc/upgrades/gcrypt/comment_1_606c1527735996ae671f78948e4ad84b._comment
new file mode 100644
index 0000000000..8805f4a8d3
--- /dev/null
+++ b/doc/upgrades/gcrypt/comment_1_606c1527735996ae671f78948e4ad84b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmj3kEGlCiy_Y-wb6AIBBnJ0B_SiPHV5Bo"
+ nickname="Thomas"
+ subject="small omission"
+ date="2013-09-25T04:59:03Z"
+ content="""
+In your second example, `mv ??? annex` has to be `mv ??? annex/objects`, I think.
+"""]]
diff --git a/doc/upgrades/insecure_embedded_creds.mdwn b/doc/upgrades/insecure_embedded_creds.mdwn
new file mode 100644
index 0000000000..a221fb51f4
--- /dev/null
+++ b/doc/upgrades/insecure_embedded_creds.mdwn
@@ -0,0 +1,42 @@
+git-annex had a bug in the S3 and Glacier remotes where if embedcreds=yes
+was set, and the remote used encryption=pubkey or encryption=hybrid,
+the embedded AWS credentials were stored in the git repository
+in (effectively) plaintext, not encrypted as they were supposed to be.
+
+That means that anyone who gets a copy of the git repository can extract the
+AWS credentials from it. Which would be bad..
+
+A remote with this problem cannot be enabled using `git annex
+enableremote`. Old versions of git-annex will fail with a gpg error;
+the current version will fail with a pointer to this web page.
+
+If your repository has this problem, chose from one of these approaches
+to deal with it:
+
+1. Change your AWS credentials, so the ones stored in the clear in git
+   won't be used. 
+   
+   After changing the credentials, make sure you have a
+   fixed version of git-annex, and you can then re-embed the new creds
+   into the repository, encrypted this time, by setting the
+   `AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID` environment variables,
+   and running `git annex enableremote $remotename embedcreds=yes`
+
+2. Fix the problem and then remove the history of the git-annex branch
+   of the repository.
+
+   Make sure you have a fixed version of git-annex, and force git-annex
+   to rewrite the embedded creds, with encryption this time, by setting
+   by setting the `AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID`
+   environment variables, and running `git annex enableremote $remotename embedcreds=yes`
+
+   Then, to get rid of old versions of the git-annex branch that still
+   contain the creds in cleartext, you can use `git annex forget`;
+   note that it will remove other historical data too.
+   
+   Keep in mind that this will not necessarily delete data from clones
+   you do not control.
+
+3. If you're sure that you're the only one who has access to the repository,
+   you could decide to leave it as-is. It's no more insecure than if you
+   had used encryption=shared in the first place when setting it up.
diff --git a/doc/use_case/Alice.mdwn b/doc/use_case/Alice.mdwn
new file mode 100644
index 0000000000..cdd3ea546d
--- /dev/null
+++ b/doc/use_case/Alice.mdwn
@@ -0,0 +1,24 @@
+### use case: The Nomad
+
+Alice is always on the move, often with her trusty netbook and a small
+handheld terabyte USB drive, or a smaller USB keydrive. She has a server
+out there on the net. She stores data, encrypted in the Cloud.
+
+All these things can have different files on them, but Alice no longer
+has to deal with the tedious process of keeping them manually in sync,
+or remembering where she put a file. git-annex manages all these data
+sources as if they were git remotes.  
+<small>[[more about special remotes|special_remotes]]</small>
+
+When she has 1 bar on her cell, Alice queues up interesting files on her
+server for later. At a coffee shop, she has git-annex download them to her
+USB drive. High in the sky or in a remote cabin, she catches up on
+podcasts, videos, and games, first letting git-annex copy them from
+her USB drive to the netbook (this saves battery power).  
+<small>[[more about transferring data|transferring_data]]</small>
+
+When she's done, she tells git-annex which to keep and which to remove.
+They're all removed from her netbook to save space, and Alice knows
+that next time she syncs up to the net, her changes will be synced back 
+to her server.  
+<small>[[more about distributed version control|distributed_version_control]]</small>
diff --git a/doc/use_case/Bob.mdwn b/doc/use_case/Bob.mdwn
new file mode 100644
index 0000000000..9477dbd3dc
--- /dev/null
+++ b/doc/use_case/Bob.mdwn
@@ -0,0 +1,25 @@
+### use case: The Archivist
+
+Bob has many drives to archive his data, most of them 
+[[kept offline|tips/offline_archive_drives]], in a safe place.
+
+With git-annex, Bob has a single directory tree that includes all
+his files, even if their content is being stored offline. He can
+reorganize his files using that tree, committing new versions to git,
+without worry about accidentally deleting anything. 
+
+When Bob needs access to some files, git-annex can tell him which drive(s)
+they're on, and easily make them available. Indeed, every drive knows what
+is on every other drive.  
+<small>[[more about location tracking|location_tracking]]</small>
+
+Bob thinks long-term, and so he appreciates that git-annex uses a simple
+repository format. He knows his files will be accessible in the future
+even if the world has forgotten about git-annex and git.  
+<small>[[more about future-proofing|future_proofing]]</small>
+
+Run in a cron job, git-annex adds new files to archival drives at night. It
+also helps Bob keep track of intentional and unintentional copies of
+files, and logs information he can use to decide when it's time to duplicate
+the content of old drives.  
+<small>[[more about backup copies|copies]]</small>
diff --git a/doc/users.mdwn b/doc/users.mdwn
new file mode 100644
index 0000000000..b9bab48ecf
--- /dev/null
+++ b/doc/users.mdwn
@@ -0,0 +1,9 @@
+Users of this wiki, feel free to create a subpage of this one and talk
+about yourself on it, within reason. You can link to it to sign your
+comments.
+
+List of users
+=============
+[[!inline pages="users/* and !users/*/* and !*/Discussion" 
+feeds=no archive=yes sort=title template=titlepage
+rootpage="users" postformtext="Add yourself as an git-annex user:"]]
diff --git a/doc/users/Ilya__95__Shlyakhter.mdwn b/doc/users/Ilya__95__Shlyakhter.mdwn
new file mode 100644
index 0000000000..01de939b7d
--- /dev/null
+++ b/doc/users/Ilya__95__Shlyakhter.mdwn
@@ -0,0 +1 @@
+I use git-annex to manage data for various bioinformatics projects.
diff --git a/doc/users/anarcat.mdwn b/doc/users/anarcat.mdwn
new file mode 100644
index 0000000000..7611e4b0b5
--- /dev/null
+++ b/doc/users/anarcat.mdwn
@@ -0,0 +1,55 @@
+I use git-annex to manage huge files, mostly video and audio attached to other git repositories (such as presentations), but I also use git-annex to manage my music collection across multiple devices. I also use it to manage the `ISO` images I download, podcasts, and youtube videos.
+
+See <http://anarc.at/>.
+
+[[!toc]]
+
+My tips
+=======
+
+... or the ones I commented it, to be more precise.
+
+[[!inline pages="tips/* and and link(users/anarcat)" sort=mtime feeds=no actions=yes archive=yes show=0]]
+
+
+My todos
+========
+
+... same.
+
+[[!inline pages="todo/* and !todo/done and !link(todo/done) and
+link(users/anarcat)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]]
+
+Done
+----
+
+[[!inline pages="todo/* and !todo/done and link(todo/done) and
+link(users/anarcat)" feeds=no actions=yes archive=yes show=0 template=buglist]]
+
+My bugs
+=======
+
+... same.
+
+[[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and
+link(users/anarcat)" sort=mtime feeds=no actions=yes archive=yes show=0  template=buglist]]
+
+Fixed
+-----
+
+[[!inline pages="bugs/* and !bugs/done and link(bugs/done) and
+link(users/anarcat)" feeds=no actions=yes archive=yes show=0  template=buglist]]
+
+Forum posts
+===========
+
+Forums where I posted.
+
+[[!inline pages="forum/* and link(users/anarcat)" sort=mtime feeds=no actions=yes archive=yes show=0]]
+
+Git annex dev news
+==================
+
+I find the recent changes a little too noisy, but i want more than just the [[news]], so i made up this little hybrid feed:
+
+[[!inline pages="(news/* and !news/*/* and !*/Discussion) or (devblog/* and !devblog/*/*)" feedonly="yes"]]
diff --git a/doc/users/andrew.mdwn b/doc/users/andrew.mdwn
new file mode 100644
index 0000000000..b2ce48d23f
--- /dev/null
+++ b/doc/users/andrew.mdwn
@@ -0,0 +1,4 @@
+Andrew Ringler <a href="mailto:public@andrewringler.com">public@andrewringler.com</a>
+<br><https://andrewringler.com/>
+
+[git-annex-turtle](https://github.com/andrewringler/git-annex-turtle) —Apple Finder integration for git-annex on macOS, including custom badge icons, contextual menus and a Menubar icon
diff --git a/doc/users/ben.mdwn b/doc/users/ben.mdwn
new file mode 100644
index 0000000000..1e6295cbd8
--- /dev/null
+++ b/doc/users/ben.mdwn
@@ -0,0 +1 @@
+No idea yet
diff --git a/doc/users/chris.mdwn b/doc/users/chris.mdwn
new file mode 100644
index 0000000000..3320ddcaa5
--- /dev/null
+++ b/doc/users/chris.mdwn
@@ -0,0 +1 @@
+Visit my page <a href="http://www.cybr.eu">Cybr</a> or my private page <a href="http://www.ca84.com">ca84</a> if you like to contact me.
diff --git a/doc/users/chrysn.mdwn b/doc/users/chrysn.mdwn
new file mode 100644
index 0000000000..ba42615678
--- /dev/null
+++ b/doc/users/chrysn.mdwn
@@ -0,0 +1,11 @@
+* **name**: chrysn
+* **website**: <http://christian.amsuess.com/>
+* **uses git-annex for** managing the family's photos (and possibly videos and music in the future).
+* **likes git-annex because** it adds a layer of commit semantics over a regular file system without keeping everything in duplicate locally.
+* **would like git-annex not to** be required any more at all when
+  * git itself learns to use cow filesystems to avoid abundant disk usage, and
+  * git gets better with shallow clones.
+
+    git-annex might then still be a simpler tool that watches over what can be safely dropped from a particular shallow clone
+
+    (the issues with shallow clones seem to relate primarily to shallow history; i haven't read anything about what would happen if all commits were checked out, but not all trees and blobs)
diff --git a/doc/users/clacke.mdwn b/doc/users/clacke.mdwn
new file mode 100644
index 0000000000..c48cd311fc
--- /dev/null
+++ b/doc/users/clacke.mdwn
@@ -0,0 +1,3 @@
+Claes Wallin (韋嘉誠)
+
+[[https://microca.st/clacke]]
diff --git a/doc/users/claes.wallin.mdwn b/doc/users/claes.wallin.mdwn
new file mode 100644
index 0000000000..9e79a5fc9e
--- /dev/null
+++ b/doc/users/claes.wallin.mdwn
@@ -0,0 +1 @@
+[[!meta redir=clacke]]
diff --git a/doc/users/dandi.mdwn b/doc/users/dandi.mdwn
new file mode 100644
index 0000000000..b1a1773bf9
--- /dev/null
+++ b/doc/users/dandi.mdwn
@@ -0,0 +1 @@
+Moved to [[projects/dandi]]
diff --git a/doc/users/datalad.mdwn b/doc/users/datalad.mdwn
new file mode 100644
index 0000000000..8ada70426f
--- /dev/null
+++ b/doc/users/datalad.mdwn
@@ -0,0 +1 @@
+[[!meta redir=projects/datalad]]
diff --git a/doc/users/dave.mdwn b/doc/users/dave.mdwn
new file mode 100644
index 0000000000..0a18da5d4e
--- /dev/null
+++ b/doc/users/dave.mdwn
@@ -0,0 +1 @@
+IM DAVE
diff --git a/doc/users/dckc.mdwn b/doc/users/dckc.mdwn
new file mode 100644
index 0000000000..47ca2ab309
--- /dev/null
+++ b/doc/users/dckc.mdwn
@@ -0,0 +1 @@
+See: [MadMode: Dan Connolly's tinkering lab notebook](https://www.madmode.com/), [dckc on github](https://github.com/dckc)
diff --git a/doc/users/falsifian.mdwn b/doc/users/falsifian.mdwn
new file mode 100644
index 0000000000..9b7f818384
--- /dev/null
+++ b/doc/users/falsifian.mdwn
@@ -0,0 +1 @@
+Hi, I'm [James Cook](https://www.falsifian.org/).
diff --git a/doc/users/fmarier.mdwn b/doc/users/fmarier.mdwn
new file mode 100644
index 0000000000..d04b6968df
--- /dev/null
+++ b/doc/users/fmarier.mdwn
@@ -0,0 +1,6 @@
+# François Marier
+
+Free Software and Debian Developer. Lead developer of [Libravatar](https://www.libravatar.org)
+
+* [Blog](http://feeding.cloud.geek.nz) and [homepage](http://fmarier.org)
+* [Identica](http://identi.ca/fmarier) / [Twitter](https://twitter.com/fmarier)
diff --git a/doc/users/frederik.mdwn b/doc/users/frederik.mdwn
new file mode 100644
index 0000000000..110e4fd5b5
--- /dev/null
+++ b/doc/users/frederik.mdwn
@@ -0,0 +1 @@
+Hi, I am Frederik Vanrenterghem. I use git annex to manage my documents (mainly to have a backup and easy access) and my collection of ripped audio CDs (mainly to be able to save space on my laptop).
diff --git a/doc/users/gebi.mdwn b/doc/users/gebi.mdwn
new file mode 100644
index 0000000000..121bedbdd7
--- /dev/null
+++ b/doc/users/gebi.mdwn
@@ -0,0 +1 @@
+Michael Gebetsroither <michael@mgeb.org>
diff --git a/doc/users/greg.mdwn b/doc/users/greg.mdwn
new file mode 100644
index 0000000000..95873c5750
--- /dev/null
+++ b/doc/users/greg.mdwn
@@ -0,0 +1,3 @@
+Greg Grossmeier
+
+<http://grossmeier.net/about>
diff --git a/doc/users/james.mdwn b/doc/users/james.mdwn
new file mode 100644
index 0000000000..4dc6223870
--- /dev/null
+++ b/doc/users/james.mdwn
@@ -0,0 +1 @@
+hello, I am [[James Richardson|http://jamestechnotes.com/]].
diff --git a/doc/users/jgoerzen.mdwn b/doc/users/jgoerzen.mdwn
new file mode 100644
index 0000000000..1310545d18
--- /dev/null
+++ b/doc/users/jgoerzen.mdwn
@@ -0,0 +1 @@
+Hi.  I'm John Goerzen.  I have a [homepage](https://www.complete.org/jgoerzen).  I [write a lot](https://www.complete.org/interesting-topics/) about [asynchronous networks](https://www.complete.org/asynchronous-communication/) and [offline communication](https://www.complete.org/tools-for-communicating-offline-and-in-difficult-circumstances/), especially with [NNCP](https://www.complete.org/nncp/).  I'm particularly interested in git-annex's NNCP special remote.
diff --git a/doc/users/jkniiv.mdwn b/doc/users/jkniiv.mdwn
new file mode 100644
index 0000000000..6e401e56ed
--- /dev/null
+++ b/doc/users/jkniiv.mdwn
@@ -0,0 +1,10 @@
+This is the git-annex wiki page for the user jkniiv aka. Jarkko Kniivilä.
+
+I'm a gen-X Windows/Linux geek from Hämeenlinna, Finland (the EU), who has been using git-annex on and off
+for a few years now but only since late 2019 or so in earnest. I finally found a use case with managing the
+relatively huge files that are the backup images of my laptops. I also tend to add whole external hdds into
+their respective annexes (with an annex.largefiles setting at 1 megabytes) then cloning those to my laptops
+secondary drive E: (on an ssd) without getting the annex objects and thus keeping a rudimentary catalog of my
+offline files always at hand.
+
+In a past life I used to be a systems specialist (Linux servers and FOSS) for an internet consultancy.
diff --git a/doc/users/joey.mdwn b/doc/users/joey.mdwn
new file mode 100644
index 0000000000..2180dd64f9
--- /dev/null
+++ b/doc/users/joey.mdwn
@@ -0,0 +1,2 @@
+Joey Hess <id@joeyh.name>  
+<https://joeyh.name/>
diff --git a/doc/users/joey/comment_1_0ccf207fd817f9b5555aad030bd4957f._comment b/doc/users/joey/comment_1_0ccf207fd817f9b5555aad030bd4957f._comment
new file mode 100644
index 0000000000..19d63ea1bb
--- /dev/null
+++ b/doc/users/joey/comment_1_0ccf207fd817f9b5555aad030bd4957f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="4omecha@fff0ca6fa5307d92706e5ee6812d8db8f8067df0"
+ nickname="4omecha"
+ avatar="http://cdn.libravatar.org/avatar/9345d7ff12c24cf55ce343c0e58a6188"
+ subject="git-annex"
+ date="2018-10-04T14:19:17Z"
+ content="""
+Hey Joey,
+
+figured this might be the right place to drop a heartily \"Thank You!\" for your work regarding git-annex (as well for your contributions to Debian and the FLOSS universe in general).
+
+I'm still in the process of trying to wrap my head around the git-annex complex to find the right(TM) implementation for my use case. For me, git-annex strives for essentials, i.e. future-proving, wide applicability and others. Steep learning curve for the diligent user trying to find the right way the first time w/o losing data while using it.
+
+Best prove of a successful and sustainable piece of software seems to be the diversity of use cases others find to apply it to. Looking around the web and seeing the diversity of real and serious git-annex applications is just plain amazing.
+
+cheers
+"""]]
diff --git a/doc/users/joey/comment_2_7e0b8d499d2bededf01591a7c5686f8f._comment b/doc/users/joey/comment_2_7e0b8d499d2bededf01591a7c5686f8f._comment
new file mode 100644
index 0000000000..a76ada4f51
--- /dev/null
+++ b/doc/users/joey/comment_2_7e0b8d499d2bededf01591a7c5686f8f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jrayguinn@616789b2aec6c923cd9897c86987f05581df3601"
+ nickname="jrayguinn"
+ avatar="http://cdn.libravatar.org/avatar/1e5178cead330a7be3840415663ba8dc"
+ subject="I Am."
+ date="2021-05-17T09:42:12Z"
+ content="""
+I freaking love you man
+"""]]
diff --git a/doc/users/kolam.mdwn b/doc/users/kolam.mdwn
new file mode 100644
index 0000000000..1333ed77b7
--- /dev/null
+++ b/doc/users/kolam.mdwn
@@ -0,0 +1 @@
+TODO
diff --git a/doc/users/mih.mdwn b/doc/users/mih.mdwn
new file mode 100644
index 0000000000..8b3670bf12
--- /dev/null
+++ b/doc/users/mih.mdwn
@@ -0,0 +1,23 @@
+My todos
+========
+
+[[!inline pages="todo/* and !todo/done and !link(todo/done) and
+author(mih)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]]
+
+Done
+----
+
+[[!inline pages="todo/* and !todo/done and link(todo/done) and
+author(mih)" feeds=no actions=yes archive=yes show=0 template=buglist]]
+
+My bugs
+=======
+
+[[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and
+author(mih)" sort=mtime feeds=no actions=yes archive=yes show=0  template=buglist]]
+
+Fixed
+-----
+
+[[!inline pages="bugs/* and !bugs/done and link(bugs/done) and
+author(mih)" feeds=no actions=yes archive=yes show=0  template=buglist]]
diff --git a/doc/users/nobodyinperson.mdwn b/doc/users/nobodyinperson.mdwn
new file mode 100644
index 0000000000..b6eff5393c
--- /dev/null
+++ b/doc/users/nobodyinperson.mdwn
@@ -0,0 +1,13 @@
+I use git-annex to:
+
+- manage my research data, partly also with [DataLad](https://datalad.org)
+- sync and backup personal documents
+- sync media files to and from my SailfishOS phone
+- sync, organise and backup a huge media collection
+- experiment doing inventory management
+
+I made a [Thunar plugin](https://gitlab.com/nobodyinperson/thunar-plugins) for git-annex, here's a [📹 screencast](https://fosstodon.org/@nobodyinperson/109836827575976439).
+
+In an attempt to [#gitAnnexAllTheThings](https://fosstodon.org/tags/gitAnnexAllTheThings), I used git annex as a backend for a cli time tracker [annextimelog](https://pypi.org/project/annextimelog/). It has similarities with timewarrior but adresses many of its inconveniences. I talked about it a bit at my [distribits 2024](https://distribits.live) talk, of which there is a recording [📹 on YouTube](https://www.youtube.com/watch?v=IdRUsn-zB2s).
+
+At the [Tübix 2023](https://www.tuebix.org/) I gave a git annex workshop, of which you can find a recording of the initial talk [📹 here (🇩🇪 German)](https://tube.tchncs.de/w/db1ec5ca-94ad-4f49-a507-2124fd699ff1) or [📹 here (English)](https://tube.tchncs.de/w/1U4vbTAhSEje3KQ1dGqvxh) in the fediverse and [📹 here on Odysee (🇩🇪 German)](https://odysee.com/@nobodyinperson:6/T%C3%BCbix2023-Yann-B%C3%BCchau-git-annex:6). 
diff --git a/doc/users/parhuzamos.mdwn b/doc/users/parhuzamos.mdwn
new file mode 100644
index 0000000000..32bd05275a
--- /dev/null
+++ b/doc/users/parhuzamos.mdwn
@@ -0,0 +1,8 @@
+My life with git-annex
+
+Todos: 
+
+- publish git-annex scripts
+
+[[!inline pages="todo/* and !todo/done and !link(todo/done) and
+link(users/parhuzamos)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]]
diff --git a/doc/users/petersjt014.mdwn b/doc/users/petersjt014.mdwn
new file mode 100644
index 0000000000..b41938b38b
--- /dev/null
+++ b/doc/users/petersjt014.mdwn
@@ -0,0 +1 @@
+git-annex noob who is too lazy to have a bio here yet :)
diff --git a/doc/users/ptilopteri.mdwn b/doc/users/ptilopteri.mdwn
new file mode 100644
index 0000000000..a88cab4f23
--- /dev/null
+++ b/doc/users/ptilopteri.mdwn
@@ -0,0 +1 @@
+darktable user
diff --git a/doc/users/sameerds.mdwn b/doc/users/sameerds.mdwn
new file mode 100644
index 0000000000..6df5f181c4
--- /dev/null
+++ b/doc/users/sameerds.mdwn
@@ -0,0 +1,3 @@
+Extremely grateful user of git-annex.
+
+[[http://sameer.sbuddhe.net/]]
diff --git a/doc/users/thk.mdwn b/doc/users/thk.mdwn
new file mode 100644
index 0000000000..d44ca28c72
--- /dev/null
+++ b/doc/users/thk.mdwn
@@ -0,0 +1,26 @@
+I'm thk at debian org
+
+
+# My TODO items
+
+- write a tip on using git worktree to inspect the git-annex branch
+  - Is there a way to filter out the directories?
+- write a tip on how to deal with permission issues on ext formatted USB drives
+  - works of course only on Debian and derivatives
+  - use a common group defined in /usr/share/base-passwd/group.master, e.g. "floppy"
+  - use setgid bit: https://en.wikipedia.org/wiki/Setuid#SGID
+  - make sure all users on all machines are part of the common group
+- Collect problems with NTFS tree exports, e.g.
+  - Spaces at the end in filenames
+  - single quotes in filenames
+  - dots?
+- more experiences with ext4 encryption feature:
+
+  <https://www.techort.com/encryption-in-ext4-how-it-works-habrahabr/>
+
+# Bugs that affect me
+
+- [[todo/sharedRepository_mode_not_supported_by_git-annex]] - some pain
+- [[tips/shared_git_annex_directory_between_multiple_users]]
+- [[todo/support_concurrency_for_export]] (maybe nice?)
+- [[todo/more_efficient_resolution_of_trivial_export_conflicts]] - endless pain!
diff --git a/doc/users/timothe.mdwn b/doc/users/timothe.mdwn
new file mode 100644
index 0000000000..3ddbfa54fb
--- /dev/null
+++ b/doc/users/timothe.mdwn
@@ -0,0 +1,5 @@
+Coucou Mijhito !
+
+Oui, c'est bien ici que le brainstorm se passe !
+
+Tim
diff --git a/doc/users/tobiastheviking.mdwn b/doc/users/tobiastheviking.mdwn
new file mode 100644
index 0000000000..31398dae90
--- /dev/null
+++ b/doc/users/tobiastheviking.mdwn
@@ -0,0 +1,13 @@
+Tobias Ussing
+
+See:
+
+* [[tips/flickrannex]] - [[https://github.com/TobiasTheViking/flickrannex/]]
+* [[tips/imapannex]] - [[https://github.com/TobiasTheViking/imapannex]]
+* [[tips/dropboxannex]] - [[https://github.com/TobiasTheViking/dropboxannex]]
+* [[tips/skydriveannex]] - [[https://github.com/TobiasTheViking/skydriveannex]]
+* [[tips/googledriveannex]] - [[https://github.com/TobiasTheViking/googledriveannex]]
+* [[tips/owncloudannex]] - [[https://github.com/TobiasTheViking/owncloudannex]]
+* [[tips/megaannex]] - [[https://github.com/TobiasTheViking/megaannex]]
+* [[forum/nntp__47__usenet_special_remote/]]
+
diff --git a/doc/users/unqueued.mdwn b/doc/users/unqueued.mdwn
new file mode 100644
index 0000000000..7ae93d8608
--- /dev/null
+++ b/doc/users/unqueued.mdwn
@@ -0,0 +1,7 @@
+Hello.
+
+I have been using git-annex since 2017, and it has been a huge boon.
+
+I mostly consider myself a hobbyist, but I have used git-annex professionally. Along the way, I've learned a lot about unix system programming, git, and automation.
+
+I personally find managing large sets of files to be very annoying. So being able to wrangle giant sets of files with the precision of git is awesome. I used to spend a lot of time checksumming files, making download queues, and trying to catalog where stuff was.
diff --git a/doc/users/wzhd.mdwn b/doc/users/wzhd.mdwn
new file mode 100644
index 0000000000..9b25e9bb32
--- /dev/null
+++ b/doc/users/wzhd.mdwn
@@ -0,0 +1 @@
+Learned some Haskell because of git-annex and propellor
diff --git a/doc/users/yarikoptic.mdwn b/doc/users/yarikoptic.mdwn
new file mode 100644
index 0000000000..0f93005ba9
--- /dev/null
+++ b/doc/users/yarikoptic.mdwn
@@ -0,0 +1,15 @@
+Hi,
+
+I am Yaroslav Olegovich Halchenko, or just Yarik.  I also got my first MS degree in Laser and Optoelectronic Engineering, and that is how I became `yarikoptic`.
+
+Through the past two decades I have been pursuing a variety of problems in neuroimaging and neuroinformatics, to solve many of which we have provide many solutions to our scientific community (e.g. [NeuroDebian](http://neuro.debian.net), [PyMVPA](http://pymvpa.org), etc). git-annex became the ideological and technological core for our [DataLad](http://datalad.org) project to provide a data distribution for existing data resources, and a versatile management platform for all digital objects of science (code, data, computational environments, etc).  DataLad development was funded by NSF (USA) and BMBF (Germany), which allowed us to support development and maintenance of the core piece of git-annex for over 4 years now.
+
+To discover more, visit
+
+- [Center for Open Neuroscience](http://centerforopenneuroscience.org)
+- [yarikoptic@GitHub](https://github.com/yarikoptic)
+- [yarikoptic@Twitter](http://twitter.com/yarikoptic)
+
+# TODO/BUGs pages which should likely be tagged with one of the projects
+
+[[!inline pages="(todo/* or bugs/*) and (author(yoh) or author(mih) or author(ben) or author(yarikoptic) or author(kyle)) and !tagged(projects/*)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]]
diff --git a/doc/users/yoh.mdwn b/doc/users/yoh.mdwn
new file mode 100644
index 0000000000..fca9c5553b
--- /dev/null
+++ b/doc/users/yoh.mdwn
@@ -0,0 +1,23 @@
+My todos
+========
+
+[[!inline pages="todo/* and !todo/done and !link(todo/done) and
+author(yoh)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]]
+
+Done
+----
+
+[[!inline pages="todo/* and !todo/done and link(todo/done) and
+author(yoh)" feeds=no actions=yes archive=yes show=0 template=buglist]]
+
+My bugs
+=======
+
+[[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and
+author(yoh)" sort=mtime feeds=no actions=yes archive=yes show=0  template=buglist]]
+
+Fixed
+-----
+
+[[!inline pages="bugs/* and !bugs/done and link(bugs/done) and
+author(yoh)" feeds=no actions=yes archive=yes show=0  template=buglist]]
diff --git a/doc/videos.mdwn b/doc/videos.mdwn
new file mode 100644
index 0000000000..ddb2604f23
--- /dev/null
+++ b/doc/videos.mdwn
@@ -0,0 +1,8 @@
+Talks and screencasts about git-annex.
+
+Several of these videos are also available in a public git-annex repository
+`git clone https://downloads.kitenet.net/.git/`
+
+[[!inline pages="./videos/* and !./videos/*/* and !*/Discussion" show="3"]]
+
+[[!inline pages="./videos/* and !./videos/*/* and !*/Discussion" show="0" archive=yes skip=2 feeds=no]]
diff --git a/doc/videos/FOSDEM2012.mdwn b/doc/videos/FOSDEM2012.mdwn
new file mode 100644
index 0000000000..30d1e37d51
--- /dev/null
+++ b/doc/videos/FOSDEM2012.mdwn
@@ -0,0 +1,7 @@
+<video controls
+src="http://video.fosdem.org/2012/lightningtalks/git_annex___manage_files_with_git,_without_checking_their_contents_into_git.webm"></video><br>
+A <a href="http://video.fosdem.org/2012/lightningtalks/git_annex___manage_files_with_git,_without_checking_their_contents_into_git.webm">15 minute introduction to git-annex</a>,
+presented by Richard Hartmann at FOSDEM 2012.
+
+[[!meta date="1 Jan 2012"]]
+[[!meta title="git-annex presentation by Richard Hartmann at FOSDEM 2012"]]
diff --git a/doc/videos/LCA2013.mdwn b/doc/videos/LCA2013.mdwn
new file mode 100644
index 0000000000..0f29ce0523
--- /dev/null
+++ b/doc/videos/LCA2013.mdwn
@@ -0,0 +1,8 @@
+<video controls>
+<source type="video/mp4" src="http://mirror.linux.org.au/linux.conf.au/2013/mp4/gitannex.mp4">
+<source type="video/ogg" src="http://mirror.linux.org.au/linux.conf.au/2013/ogv/gitannex.ogv">
+</video><br>
+A <a href="http://mirror.linux.org.au/linux.conf.au/2013/mp4/gitannex.mp4">45 minute talk and demo of git-annex and the assistant</a>), presented by Joey Hess at LCA 2013.
+
+[[!meta date="1 Feb 2013"]]
+[[!meta title="git-annex presentation by Joey Hess at Linux.Conf.Au 2013"]]
diff --git a/doc/videos/git-annex_assistant_archiving.mdwn b/doc/videos/git-annex_assistant_archiving.mdwn
new file mode 100644
index 0000000000..7e891c2f77
--- /dev/null
+++ b/doc/videos/git-annex_assistant_archiving.mdwn
@@ -0,0 +1,5 @@
+<video controls width=400>
+<source src="https://downloads.kitenet.net/videos/git-annex/git-annex-assistant-archiving.ogv">
+</video><br>
+A <a href="https://downloads.kitenet.net/videos/git-annex/git-annex-assistant-archiving.ogv">9 minute screencast</a>
+covering archiving your files with the [[git-annex assistant|/assistant]]</a>.
diff --git a/doc/videos/git-annex_assistant_introduction.mdwn b/doc/videos/git-annex_assistant_introduction.mdwn
new file mode 100644
index 0000000000..93f9df1bad
--- /dev/null
+++ b/doc/videos/git-annex_assistant_introduction.mdwn
@@ -0,0 +1,5 @@
+<video controls width=400>
+<source src="https://downloads.kitenet.net/videos/git-annex/git-annex-assistant-intro.ogv">
+</video><br>
+A <a href="https://downloads.kitenet.net/videos/git-annex/git-annex-assistant-intro.ogv">8 minute screencast</a>
+introducing the [[git-annex assistant|/assistant]]</a>.
diff --git a/doc/videos/git-annex_assistant_introduction/comment_1_f42ad4183c2c28319d3705a82fceb82f._comment b/doc/videos/git-annex_assistant_introduction/comment_1_f42ad4183c2c28319d3705a82fceb82f._comment
new file mode 100644
index 0000000000..c969bacbcb
--- /dev/null
+++ b/doc/videos/git-annex_assistant_introduction/comment_1_f42ad4183c2c28319d3705a82fceb82f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="modules"
+ ip="85.16.227.39"
+ subject="Great screencast"
+ date="2013-03-16T14:16:37Z"
+ content="""
+I am starting to understand the concept :) Thank you.
+
+The assistant is working perfect with local repos and removable drives but i have problems to setup a remote repos. On a fresh debian server with base setup and rsync installed and ssh-keys for login. I got a green \"Scanned 93.xxx.xx.xxx_annex\" message on dashboard, but there is never a finished transfer. Its \"queued\" on all files and nothing seems to happens on clicking the \"play\" button behind files (x-ing files removes them from dashboard). Also i saw there is a second option in your screencast for remote servers (\"Use a git reposoitory on the server\") which does not show up on my side. Do i need to setup git-annex on server for second option? (with git-annex version 4.20130314).
+
+
+
+
+
+"""]]
diff --git a/doc/videos/git-annex_assistant_introduction/comment_2_b62f4eeeac1138570f7cb8c98d41c2cb._comment b/doc/videos/git-annex_assistant_introduction/comment_2_b62f4eeeac1138570f7cb8c98d41c2cb._comment
new file mode 100644
index 0000000000..8b6d2a1e95
--- /dev/null
+++ b/doc/videos/git-annex_assistant_introduction/comment_2_b62f4eeeac1138570f7cb8c98d41c2cb._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 2"
+ date="2013-03-16T16:04:30Z"
+ content="""
+@modules: Yes, you're only given the option to use a git repository on the server if it has both git and git-annex installed. You can install any version of git-annex there. For example, Debian stable ships with one that will work.
+I plan to make that screen clearer when the git repository option is not available.
+
+I'm not sure what'd going on with your rsync transfers not running. I can say that if the \"play\" icon is visible, the transfer has been paused. While a transfer is running, the \"pause\" icon is visible instead, to let you pause it. 
+This may be as simple as you having misunderstood the icons and paused the currently running transfer, which prevents any transfers from running. If not, suggest you enable debug logs in the Preferences page, and consider filing a [[bug_report|bugs]].
+"""]]
diff --git a/doc/videos/git-annex_assistant_lan.mdwn b/doc/videos/git-annex_assistant_lan.mdwn
new file mode 100644
index 0000000000..aa9245fe56
--- /dev/null
+++ b/doc/videos/git-annex_assistant_lan.mdwn
@@ -0,0 +1,6 @@
+<video controls width=400>
+<source src="https://downloads.kitenet.net/videos/git-annex/git-annex-lan.webm">
+</video><br>
+A <a href="https://downloads.kitenet.net/videos/git-annex/git-annex-lan.webm">10 minute screencast</a>
+showing how to get started using the [[git-annex assistant|/assistant]],
+including sharing files on a local network, and installation on a server.
diff --git a/doc/videos/git-annex_assistant_lan/comment_1_df8c8b6d9d63fbf5462b225edbb23c82._comment b/doc/videos/git-annex_assistant_lan/comment_1_df8c8b6d9d63fbf5462b225edbb23c82._comment
new file mode 100644
index 0000000000..8c67a5cfbc
--- /dev/null
+++ b/doc/videos/git-annex_assistant_lan/comment_1_df8c8b6d9d63fbf5462b225edbb23c82._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://alan.petitepomme.net/"
+ nickname="Alan Schmitt"
+ subject="How is the binary found on the server?"
+ date="2014-06-05T12:05:40Z"
+ content="""
+Great screencast! There is one thing that intrigues me: since you simply uncompress the binary in some folder, how does gitannex figures out where the binary lives there?
+"""]]
diff --git a/doc/videos/git-annex_assistant_lan/comment_2_d4e3122da9c9e27fbe872e09fcde762b._comment b/doc/videos/git-annex_assistant_lan/comment_2_d4e3122da9c9e27fbe872e09fcde762b._comment
new file mode 100644
index 0000000000..c62f1d0160
--- /dev/null
+++ b/doc/videos/git-annex_assistant_lan/comment_2_d4e3122da9c9e27fbe872e09fcde762b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="magic"
+ date="2014-06-10T16:13:35Z"
+ content="""
+In the screencast, I run git-annex after unpacking it, and this lets it register where it's installed at.
+
+So it is important to run git-annex after you unpack it.
+"""]]
diff --git a/doc/videos/git-annex_assistant_lan/comment_3_d43ee0a335c2f010b437cf28437455c2._comment b/doc/videos/git-annex_assistant_lan/comment_3_d43ee0a335c2f010b437cf28437455c2._comment
new file mode 100644
index 0000000000..39fb1aefcb
--- /dev/null
+++ b/doc/videos/git-annex_assistant_lan/comment_3_d43ee0a335c2f010b437cf28437455c2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://alan.petitepomme.net/"
+ nickname="Alan Schmitt"
+ subject="Where is it registered?"
+ date="2014-06-11T11:27:02Z"
+ content="""
+I'm curious: how do you register it? Does it only work on Linux? (I've had to add paths to my setup under OS X, so it would be great if there was such a simpler way.)
+"""]]
diff --git a/doc/videos/git-annex_assistant_lan/comment_4_c710e27db41311b157d8caaafc32dc7e._comment b/doc/videos/git-annex_assistant_lan/comment_4_c710e27db41311b157d8caaafc32dc7e._comment
new file mode 100644
index 0000000000..1035f6348c
--- /dev/null
+++ b/doc/videos/git-annex_assistant_lan/comment_4_c710e27db41311b157d8caaafc32dc7e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 4"
+ date="2014-06-11T19:56:49Z"
+ content="""
+Running git-annex will also register it on OSX. The registration just consists of making a ~/.ssh/git-annex-shell that runs the real git-annex-shell. The assistant detects when it needs to use that wrapper when setting up a repository.
+"""]]
diff --git a/doc/videos/git-annex_assistant_sync_demo.mdwn b/doc/videos/git-annex_assistant_sync_demo.mdwn
new file mode 100644
index 0000000000..2df2a3a91a
--- /dev/null
+++ b/doc/videos/git-annex_assistant_sync_demo.mdwn
@@ -0,0 +1,8 @@
+A screencast demoing the git-annex assistant syncing between Nicaragua
+and the United Kingdom for the first time.
+
+<video controls src="http://joeyh.name/screencasts/git-annex-assistant.ogg"></video>
+
+[video](http://joeyh.name/screencasts/git-annex-assistant.ogg)
+
+[[!meta date="Thu Jul 5 16:36:06 2012 -0600"]]
diff --git a/doc/videos/git-annex_views_demo.mdwn b/doc/videos/git-annex_views_demo.mdwn
new file mode 100644
index 0000000000..c860129fd0
--- /dev/null
+++ b/doc/videos/git-annex_views_demo.mdwn
@@ -0,0 +1,11 @@
+A quick screencast demoing an experimental new feature,
+[[tips/metadata_driven_views]].
+
+<video controls src="https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg"></video>
+
+[video](https://downloads.kitenet.net/videos/git-annex/git-annex_views_demo.ogg)
+
+Credits: 
+
+* RichiH for <https://github.com/RichiH/conference_proceedings>
+* Michi for keyboard cat cameo
diff --git a/doc/videos/git-annex_watch_demo.mdwn b/doc/videos/git-annex_watch_demo.mdwn
new file mode 100644
index 0000000000..3909f73b5b
--- /dev/null
+++ b/doc/videos/git-annex_watch_demo.mdwn
@@ -0,0 +1,7 @@
+A quick screencast demoing the `git annex watch` daemon.
+
+<video controls src="http://joeyh.name/screencasts/git-annex-watch.ogg"></video>
+
+[video](http://joeyh.name/screencasts/git-annex-watch.ogg)
+
+[[!meta date="Mon Jun 11 16:02:14 2012 -0400"]]
diff --git a/doc/videos/git-annex_weppapp_demo.mdwn b/doc/videos/git-annex_weppapp_demo.mdwn
new file mode 100644
index 0000000000..b982d32fd4
--- /dev/null
+++ b/doc/videos/git-annex_weppapp_demo.mdwn
@@ -0,0 +1,8 @@
+A quick screencast demoing the early `git annex webapp` and
+automatic USB drive mount detection and syncing.
+
+<video controls src="http://joeyh.name/screencasts/git-annex-webapp.ogg"></video>
+
+[video](http://joeyh.name/screencasts/git-annex-webapp.ogg)
+
+[[!meta date="Sun Jul 29 14:41:41 2012 -0400"]]
diff --git a/doc/videos/tuebix.mdwn b/doc/videos/tuebix.mdwn
new file mode 100644
index 0000000000..95e9fce42c
--- /dev/null
+++ b/doc/videos/tuebix.mdwn
@@ -0,0 +1,11 @@
+Yann Büchau's (German) talk about Git Annex on the [Tübix2023 Linux Day](https://tuebix.org) in Tübingen, Germany:
+
+- [on PeerTube](https://tube.tchncs.de/w/t4mLqLM2YdFZf21SoW9gQn)
+- [on Odysee](https://odysee.com/@nobodyinperson:6/T%C3%BCbix2023-Yann-B%C3%BCchau-git-annex:6)
+
+Yann re-recorded the talk in English later, it is available here:
+
+- [on PeerTube](https://tube.tchncs.de/w/1U4vbTAhSEje3KQ1dGqvxh)
+
+[[!meta date="1 Jul 2023"]]
+[[!meta title="git-annex presentation by Yann Büchau at Tübix2023"]]
diff --git a/doc/walkthrough.mdwn b/doc/walkthrough.mdwn
new file mode 100644
index 0000000000..4745ca1172
--- /dev/null
+++ b/doc/walkthrough.mdwn
@@ -0,0 +1,32 @@
+A walkthrough of some of the basic features of git-annex, using the command
+line. If you don't want to use the command line, see [[assistant/quickstart]]
+instead.
+
+What follows is only one possible [[workflow]] for using git-annex,
+but following along will teach you the basic concepts from the ground up.
+
+[[!toc]]
+
+[[!inline feeds=no trail=yes show=0 template=walkthrough pagenames="""
+	walkthrough/creating_a_repository
+	walkthrough/adding_files
+	walkthrough/adding_a_remote
+	walkthrough/renaming_files
+	walkthrough/getting_file_content
+	walkthrough/syncing
+	walkthrough/transferring_files__58___When_things_go_wrong
+	walkthrough/removing_files
+	walkthrough/removing_files__58___When_things_go_wrong
+	walkthrough/modifying_annexed_files
+	walkthrough/using_ssh_remotes
+	walkthrough/using_special_remotes
+	walkthrough/moving_file_content_between_repositories
+	walkthrough/quiet_please__58___When_git-annex_seems_to_skip_files
+	walkthrough/using_tags_and_branches
+	walkthrough/unused_data
+	walkthrough/fsck__58___verifying_your_data
+	walkthrough/fsck__58___when_things_go_wrong
+	walkthrough/backups
+	walkthrough/automatically_managing_content
+	walkthrough/more
+"""]]
diff --git a/doc/walkthrough/adding_a_remote.mdwn b/doc/walkthrough/adding_a_remote.mdwn
new file mode 100644
index 0000000000..8a1141db0a
--- /dev/null
+++ b/doc/walkthrough/adding_a_remote.mdwn
@@ -0,0 +1,22 @@
+Like any other git repository, git-annex repositories have remotes.
+Let's start by adding a USB drive as a remote.
+
+	$ sudo mount /media/usb
+	$ cd /media/usb
+	$ git clone ~/annex
+	$ cd annex
+	$ git annex init "portable USB drive"
+	$ git remote add laptop ~/annex
+	$ cd ~/annex
+	$ git remote add usbdrive /media/usb/annex
+
+This is all standard ad-hoc distributed git repository setup.
+
+The only git-annex specific part is telling it a description
+of the new repository created on the USB drive. This is optional, but
+giving the repository a description helps when git-annex talks about it
+later.
+
+Notice that both repos are set up as remotes of one another. This lets
+either get annexed files from the other. You'll often want to do that
+even when you are using git in a more centralized fashion.
diff --git a/doc/walkthrough/adding_a_remote/comment_1_0a59355bd33a796aec97173607e6adc9._comment b/doc/walkthrough/adding_a_remote/comment_1_0a59355bd33a796aec97173607e6adc9._comment
new file mode 100644
index 0000000000..4b0b9c0fd2
--- /dev/null
+++ b/doc/walkthrough/adding_a_remote/comment_1_0a59355bd33a796aec97173607e6adc9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2011-03-19T01:18:49Z"
+ content="""
+After doing the above with two required copy per file, `git annex fsck` complained that I had only one copy per file even though I had created my clone, already. Once I `git pull`ed from the second repo, not getting any changes for obvious reasons, `git annex fsck` was happy. So I am not sure how my addition was incorrect. -- RichiH
+"""]]
diff --git a/doc/walkthrough/adding_a_remote/comment_2_f8cd79ef1593a8181a7f1086a87713e8._comment b/doc/walkthrough/adding_a_remote/comment_2_f8cd79ef1593a8181a7f1086a87713e8._comment
new file mode 100644
index 0000000000..015417a4f7
--- /dev/null
+++ b/doc/walkthrough/adding_a_remote/comment_2_f8cd79ef1593a8181a7f1086a87713e8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-03-19T15:35:38Z"
+ content="""
+Yes, you have to pull down location tracking information in order for fsck to be satisfied in that situation. But since this is a walkthrough, and neither fsck or numcopies settings are mentioned until later, it's ok for this pull to be described a few steps along in [[getting file content]].
+
+"""]]
diff --git a/doc/walkthrough/adding_a_remote/comment_3_60691af4400521b5a8c8d75efe3b44cb._comment b/doc/walkthrough/adding_a_remote/comment_3_60691af4400521b5a8c8d75efe3b44cb._comment
new file mode 100644
index 0000000000..9280f2dccf
--- /dev/null
+++ b/doc/walkthrough/adding_a_remote/comment_3_60691af4400521b5a8c8d75efe3b44cb._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://dieter-be.myopenid.com/"
+ nickname="dieter"
+ subject="comment 3"
+ date="2011-04-02T20:24:33Z"
+ content="""
+ * why the `git remote add laptop ~/annex` ? this remote already exists under the name origin.
+ * doesn't the last command need to be `git remote add usbdrive /media/usb/annex`? because the actual repo would be in /media/usb/annex, not /media/usb?
+"""]]
diff --git a/doc/walkthrough/adding_a_remote/comment_4_6f7cf5c330272c96b3abeb6612075c9d._comment b/doc/walkthrough/adding_a_remote/comment_4_6f7cf5c330272c96b3abeb6612075c9d._comment
new file mode 100644
index 0000000000..b4dcb6422a
--- /dev/null
+++ b/doc/walkthrough/adding_a_remote/comment_4_6f7cf5c330272c96b3abeb6612075c9d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 4"
+ date="2011-04-03T02:32:17Z"
+ content="""
+Good spotting on the last line, fixed.
+
+The laptop remote is indeed redundant, but it leads to clearer views of what is going on later in the walkthrough (\"git pull laptop master\", \"(copying from laptop...)\"). And if the original clone is made from a central bare repo, this reinforces that you'll want to set up remotes for other repos on the computer.
+"""]]
diff --git a/doc/walkthrough/adding_a_remote/comment_5_bcbe480aa710ce693ee03d86884f1820._comment b/doc/walkthrough/adding_a_remote/comment_5_bcbe480aa710ce693ee03d86884f1820._comment
new file mode 100644
index 0000000000..bb8271a841
--- /dev/null
+++ b/doc/walkthrough/adding_a_remote/comment_5_bcbe480aa710ce693ee03d86884f1820._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="elmimmo"
+ avatar="http://cdn.libravatar.org/avatar/4f00dfc3ad590ef7492788b854ceba78"
+ subject="Remotes when using multiple repos"
+ date="2018-01-18T07:02:18Z"
+ content="""
+I see that you manually add the first repo as a remote of the external drive, and the external drive as a remote of the original.
+
+What about when you add a second external drive? Should you then be adding the first two repos as remotes of the new one, and then go to the first two ones and add the new drive as a remote of them too? Doesn't this permutation scale out of control when you add a new drive to, say, a git annex made of 10 disks, 20 disks, etc?
+"""]]
diff --git a/doc/walkthrough/adding_a_remote/comment_6_15ea28114e69dddac82fddaf009079ca._comment b/doc/walkthrough/adding_a_remote/comment_6_15ea28114e69dddac82fddaf009079ca._comment
new file mode 100644
index 0000000000..a57115c80c
--- /dev/null
+++ b/doc/walkthrough/adding_a_remote/comment_6_15ea28114e69dddac82fddaf009079ca._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2018-03-02T19:09:36Z"
+ content="""
+@elmimmo, you could add all those permutations, but there's no need to
+connect repositories that you don't need git-annex to transfer data
+between.
+"""]]
diff --git a/doc/walkthrough/adding_a_remote/comment_7_caea7e4e9ec904617c6ec1a33368090f._comment b/doc/walkthrough/adding_a_remote/comment_7_caea7e4e9ec904617c6ec1a33368090f._comment
new file mode 100644
index 0000000000..5226919b2f
--- /dev/null
+++ b/doc/walkthrough/adding_a_remote/comment_7_caea7e4e9ec904617c6ec1a33368090f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="slackermesut@265fdbc657a03028da3a213cbb9f74a9d621c8ab"
+ avatar="http://cdn.libravatar.org/avatar/7c78d1b3bc3ae0e6c00d49c92b573162"
+ subject="comment 7"
+ date="2018-10-13T20:47:44Z"
+ content="""
+Hi, 
+
+I have a laptop and desktop pc.
+I initialized git-annex repo on laptop and mounted laptop to desktop.
+I added mounted laptop directory to desktop as a remote.
+After I synced files with content with laptop on desktop.
+I want to get files and commits on laptop but I can't.
+
+On laptop there is a .git directory but I don't know how to get files from it.
+"""]]
diff --git a/doc/walkthrough/adding_files.mdwn b/doc/walkthrough/adding_files.mdwn
new file mode 100644
index 0000000000..e20151dc28
--- /dev/null
+++ b/doc/walkthrough/adding_files.mdwn
@@ -0,0 +1,11 @@
+	$ cd ~/annex
+	$ cp /tmp/big_file .
+	$ cp /tmp/debian.iso .
+	$ git annex add .
+	add big_file (checksum...) ok
+	add debian.iso (checksum...) ok
+	$ git commit -a -m added
+
+When you add a file to the annex and commit it, only a symlink to
+the content is committed to git. The content itself is stored in
+`.git/annex/objects/`
diff --git a/doc/walkthrough/automatically_managing_content.mdwn b/doc/walkthrough/automatically_managing_content.mdwn
new file mode 100644
index 0000000000..1f29674dc3
--- /dev/null
+++ b/doc/walkthrough/automatically_managing_content.mdwn
@@ -0,0 +1,45 @@
+Once you have multiple repositories, and have perhaps configured numcopies,
+any given file can have many more copies than is needed, or perhaps fewer
+than you would like. How to manage this?
+
+The whereis subcommand can be used to see how many copies of a file are known,
+but then you have to decide what to get or drop. In this example, there
+are perhaps not enough copies of the first file, and too many of the second
+file.
+
+	$ cd /media/usbdrive
+	$ git annex whereis
+	whereis my_cool_big_file (1 copy)
+		0c443de8-e644-11df-acbf-f7cd7ca6210d  -- laptop
+	whereis other_file (3 copies)
+		0c443de8-e644-11df-acbf-f7cd7ca6210d  -- laptop
+		62b39bbe-4149-11e0-af01-bb89245a1e61  -- usb drive [here]
+		7570b02e-15e9-11e0-adf0-9f3f94cb2eaa  -- backup drive
+
+What would be handy is some automated versions of get and drop, that only
+gets a file if there are not yet enough copies of it, or only drops a file
+if there are too many copies. Well, these exist, just use the --auto option.
+
+	$ git annex get --auto --numcopies=2
+	get my_cool_big_file (from laptop...) ok
+	$ git annex drop --auto --numcopies=2
+	drop other_file ok
+
+With two quick commands, git-annex was able to decide for you how to
+work toward having two copies of your files.
+
+	$ git annex whereis
+	whereis my_cool_big_file (2 copies)
+		0c443de8-e644-11df-acbf-f7cd7ca6210d  -- laptop
+		62b39bbe-4149-11e0-af01-bb89245a1e61  -- usb drive [here]
+	whereis other_file (2 copies)
+		0c443de8-e644-11df-acbf-f7cd7ca6210d  -- laptop
+		7570b02e-15e9-11e0-adf0-9f3f94cb2eaa  -- backup drive
+
+The --auto option can also be used with the copy command,
+again this lets git-annex decide whether to actually copy content.
+
+The above shows how to use --auto to manage content based on the number
+of copies. It's also possible to configure, on a per-repository basis,
+which content is desired. Then --auto also takes that into account
+see [[preferred_content]] for details.
diff --git a/doc/walkthrough/backups.mdwn b/doc/walkthrough/backups.mdwn
new file mode 100644
index 0000000000..e346a6a570
--- /dev/null
+++ b/doc/walkthrough/backups.mdwn
@@ -0,0 +1,27 @@
+git-annex can be configured to require that more than one copy of a file exists,
+as a simple backup for your data. This is controlled by the
+numcopies setting, which defaults to 1 copy. Let's
+change that to require 2 copies, and send a copy of every file
+to a USB drive.
+
+	$ git annex numcopies 2
+	$ git annex copy . --to usbdrive
+
+Now when we try to `git annex drop` a file, it will verify that it
+knows of 2 other repositories that have a copy before removing its
+content from the current repository.
+
+The numcopies setting used above is the global default.
+You can also vary the number of copies needed, depending on the file name.
+So, if you want 3 copies of all your flac files, but only 1 copy of oggs:
+
+	$ echo "*.ogg annex.numcopies=1" >> .gitattributes
+	$ echo "*.flac annex.numcopies=3" >> .gitattributes
+
+Or, you might want to make a directory for important stuff, and configure
+it so anything put in there is backed up more thoroughly:
+
+	$ mkdir important_stuff
+	$ echo "* annex.numcopies=3" > important_stuff/.gitattributes
+
+For more details about the numcopies setting, see [[copies]].
diff --git a/doc/walkthrough/backups/comment_1_d0244791d2abbf29553546a6a6568a0f._comment b/doc/walkthrough/backups/comment_1_d0244791d2abbf29553546a6a6568a0f._comment
new file mode 100644
index 0000000000..466b3d3694
--- /dev/null
+++ b/doc/walkthrough/backups/comment_1_d0244791d2abbf29553546a6a6568a0f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="madduck"
+ ip="2001:a60:f0fb:0:224:d7ff:fe04:c82c"
+ subject="Warn while inconsistent"
+ date="2014-04-06T20:44:17Z"
+ content="""
+Sure, git-annex prevents me from dropping files unless there are numcopies around elsewhere, but shouldn't it also ensure that numcopies cannot be set unless that requirement is already met?
+
+Furthermore, shouldn't it ensure that when new files are added, they are automatically distributed to fulfill the requirement?
+"""]]
diff --git a/doc/walkthrough/creating_a_repository.mdwn b/doc/walkthrough/creating_a_repository.mdwn
new file mode 100644
index 0000000000..270d2e44ed
--- /dev/null
+++ b/doc/walkthrough/creating_a_repository.mdwn
@@ -0,0 +1,6 @@
+This is very straightforward.
+
+	$ mkdir ~/annex
+	$ cd ~/annex
+	$ git init
+	$ git annex init
diff --git a/doc/walkthrough/fsck__58___verifying_your_data.mdwn b/doc/walkthrough/fsck__58___verifying_your_data.mdwn
new file mode 100644
index 0000000000..b4356e9ce3
--- /dev/null
+++ b/doc/walkthrough/fsck__58___verifying_your_data.mdwn
@@ -0,0 +1,36 @@
+You can use the fsck subcommand to check for problems in your data. What
+can be checked depends on the key-value [[backend|backends]] you've used
+for the data. For example, when you use the SHA1 backend, fsck will verify
+that the checksums of your files are good. Fsck also checks that the
+[[numcopies|copies]] setting is satisfied for all files.
+
+	$ git annex fsck
+	fsck some_file (checksum...) ok
+	fsck my_cool_big_file (checksum...) ok
+	...
+
+You can also specify the files to check.  This is particularly useful if 
+you're using sha1 and don't want to spend a long time checksumming everything.
+
+	$ git annex fsck my_cool_big_file
+	fsck my_cool_big_file (checksum...) ok
+
+If you have a large repo, you may want to check it in smaller steps. You may
+start and continue an aborted or time-limited check.
+
+	$ git annex fsck -S <optional-directory> --time-limit=1m
+	fsck some_file (checksum...) ok
+	fsck my_cool_big_file (checksum...) ok
+	
+	  Time limit (1m) reached!
+
+	$ git annex fsck -m <optional-directory>
+	fsck my_other_big_file (checksum...) ok
+	...
+
+Use `-S` or `--incremental` to start the incremental check. Use `-m` 
+or `--more` to continue the started check and continue where it left 
+off. Note that saving the progress of `fsck` is performed after every 
+1000 files or 5 minutes or when `--time-limit` occours. There may be 
+files that will be checked again when `git-annex` exists abnormally 
+eg. Ctrl+C and the check is restarted.
diff --git a/doc/walkthrough/fsck__58___when_things_go_wrong.mdwn b/doc/walkthrough/fsck__58___when_things_go_wrong.mdwn
new file mode 100644
index 0000000000..348add5705
--- /dev/null
+++ b/doc/walkthrough/fsck__58___when_things_go_wrong.mdwn
@@ -0,0 +1,13 @@
+Fsck never deletes possibly bad data; instead it will be moved to
+`.git/annex/bad/` for you to recover. Here is a sample of what fsck
+might say about a badly messed up annex:
+
+	$ git annex fsck
+	fsck my_cool_big_file (checksum...)
+	git-annex: Bad file content; moved to .git/annex/bad/SHA1:7da006579dd64330eb2456001fd01948430572f2
+	git-annex: ** No known copies exist of my_cool_big_file
+	failed
+	fsck important_file
+	git-annex: Only 1 of 2 copies exist. Run git annex get somewhere else to back it up.
+	failed
+	git-annex: 2 failed
diff --git a/doc/walkthrough/getting_file_content.mdwn b/doc/walkthrough/getting_file_content.mdwn
new file mode 100644
index 0000000000..c95dca128e
--- /dev/null
+++ b/doc/walkthrough/getting_file_content.mdwn
@@ -0,0 +1,12 @@
+A repository does not always have all annexed file contents available.
+When you need the content of a file, you can use "git annex get" to
+make it available.
+
+We can use this to copy everything in the laptop's annex to the
+USB drive.
+
+	$ cd /media/usb/annex
+	$ git annex sync laptop
+	$ git annex get .
+	get my_cool_big_file (from laptop...) ok
+	get iso/debian.iso (from laptop...) ok
diff --git a/doc/walkthrough/modifying_annexed_files.mdwn b/doc/walkthrough/modifying_annexed_files.mdwn
new file mode 100644
index 0000000000..4dc17f2215
--- /dev/null
+++ b/doc/walkthrough/modifying_annexed_files.mdwn
@@ -0,0 +1,31 @@
+Normally, the content of files in the annex is prevented from being modified.
+
+That's a good thing, because it might be the only copy, you wouldn't
+want to lose it in a fumblefingered mistake.
+
+	$ echo oops > my_cool_big_file
+	bash: my_cool_big_file: Permission denied
+
+In order to modify a file, it should first be unlocked.
+
+	$ git annex unlock my_cool_big_file
+	unlock my_cool_big_file (copying...) ok
+
+That replaces the symlink that normally points at its content with a copy
+of the content. You can then modify the file like any regular file. Because
+it is a regular file.
+
+(If you decide you don't need to modify the file after all, or want to discard
+modifications, just use `git annex lock`.)
+
+When you commit an unlocked file, all that gets committed to git is a
+pointer to the content. The content of the file is stored by git-annex.
+
+	$ echo "now smaller, but even cooler" > my_cool_big_file
+	$ git commit my_cool_big_file -m "changed an annexed file"
+	add my_cool_big_file ok
+	[master 64cda67] changed an annexed file
+	 1 files changed, 1 insertions(+), 1 deletions(-)
+
+For more details on working with unlocked files vs the regular locked
+files, see [[tips/unlocked_files]].
diff --git a/doc/walkthrough/modifying_annexed_files/comment_1_624b4a0b521b553d68ab6049f7dbaf8c._comment b/doc/walkthrough/modifying_annexed_files/comment_1_624b4a0b521b553d68ab6049f7dbaf8c._comment
new file mode 100644
index 0000000000..5fc26496e0
--- /dev/null
+++ b/doc/walkthrough/modifying_annexed_files/comment_1_624b4a0b521b553d68ab6049f7dbaf8c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://lj.rossia.org/users/imz/"
+ ip="79.165.56.162"
+ subject="sorta why git-annex exists in the first place -- not only the slow index "
+ date="2012-09-25T22:04:01Z"
+ content="""
+> Git wants to first stage the entire contents of the file in its index. That can be slow for big files (sorta why git-annex exists in the first place)
+
+I think that git-annex's usefulness is not only because of the Git's index overhead: I like its idea because it will help track the copies in the \"[[special remotes]]\", which are not Git because 
+
+* they are either not under my control (e.g., web URLs), 
+* or because it's not convenient to hold a Git repo there (an external disk/DVD with files can be viewed easily by a human, but imposing a Git repo structure on it would either at least double the consume space: for the history of the commits and for the working dir, or make it \"unreadable\" for a human, if it is a bare repo);
+* or because it's nearly impossible to put a Git repo on a storage like peer networks without special tools.
+"""]]
diff --git a/doc/walkthrough/modifying_annexed_files/comment_2_b000622304535d32b69db17d51156b21._comment b/doc/walkthrough/modifying_annexed_files/comment_2_b000622304535d32b69db17d51156b21._comment
new file mode 100644
index 0000000000..6a2d2c2a60
--- /dev/null
+++ b/doc/walkthrough/modifying_annexed_files/comment_2_b000622304535d32b69db17d51156b21._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://yarikoptic.myopenid.com/"
+ nickname="site-myopenid"
+ subject="feature request: unlock --drop"
+ date="2013-05-30T20:26:52Z"
+ content="""
+ATM unlock copies original file for modifications, so that original copy remains under annex and possibly to-be-edited copy created.
+But if I am \"unlock\"ing file I might simply not be interested in a previous copy and want to maintain only a single (possibly edited) new copy.
+What if there was a mode where the actual file is simply moved into \"unlocked\" location for editing, thus effectively dropping the actual content from git annex.  That would allow to not inquire lengthy copying/wasting local space.  If then I would need a previous copy I would just \"get\" it again.
+"""]]
diff --git a/doc/walkthrough/more.mdwn b/doc/walkthrough/more.mdwn
new file mode 100644
index 0000000000..0a4a5b94e8
--- /dev/null
+++ b/doc/walkthrough/more.mdwn
@@ -0,0 +1,3 @@
+So ends the walkthrough. By now you should be able to use git-annex.
+
+Want more? See [[tips]] for lots more features and advice.
diff --git a/doc/walkthrough/moving_file_content_between_repositories.mdwn b/doc/walkthrough/moving_file_content_between_repositories.mdwn
new file mode 100644
index 0000000000..ba6f08d8ad
--- /dev/null
+++ b/doc/walkthrough/moving_file_content_between_repositories.mdwn
@@ -0,0 +1,13 @@
+Often you will want to move some file contents from a repository to some
+other one. For example, your laptop's disk is getting full; time to move
+some files to an external disk before moving another file from a file
+server to your laptop. Doing that by hand (by using `git annex get` and
+`git annex drop`) is possible, but a bit of a pain. `git annex move`
+makes it very easy.
+
+	$ git annex move my_cool_big_file --to usbdrive
+	move my_cool_big_file (to usbdrive...) ok
+	$ git annex move video/hackity_hack_and_kaxxt.mov --from fileserver
+	move video/hackity_hack_and_kaxxt.mov (from fileserver...)
+	SHA256-s86050597--6ae2688bc533437766a48aa19f2c06be14d1bab9c70b468af445d4f07b65f41e   100%   82MB 199.1KB/s   07:02
+	ok
diff --git a/doc/walkthrough/moving_file_content_between_repositories/comment_1_4c30ade91fc7113a95960aa3bd1d5427._comment b/doc/walkthrough/moving_file_content_between_repositories/comment_1_4c30ade91fc7113a95960aa3bd1d5427._comment
new file mode 100644
index 0000000000..b3dc8fe7a2
--- /dev/null
+++ b/doc/walkthrough/moving_file_content_between_repositories/comment_1_4c30ade91fc7113a95960aa3bd1d5427._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2011-03-22T23:41:51Z"
+ content="""
+I may be missing something obvious, but when I copy to a remote repository, the object files are created, but no softlinks are created. When I pull everything from the remote, it pulls only files the local repo knows about already.
+
+        A
+       / \
+      B   C
+
+Moving from B to A creates no symlinks in A but the object files are moved to A. Copying back from A to B restores the object files in B and keeps them in A.
+
+Copying from A to an empty C does not create any object files nor symlinks. Copying from C to A creates no symlinks in A but the object files are copied to A.
+
+-- RichiH
+
+"""]]
diff --git a/doc/walkthrough/moving_file_content_between_repositories/comment_2_7d90e1e150e7524ba31687108fcc38d6._comment b/doc/walkthrough/moving_file_content_between_repositories/comment_2_7d90e1e150e7524ba31687108fcc38d6._comment
new file mode 100644
index 0000000000..a6f8e9cf97
--- /dev/null
+++ b/doc/walkthrough/moving_file_content_between_repositories/comment_2_7d90e1e150e7524ba31687108fcc38d6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-03-23T00:38:10Z"
+ content="""
+`git annex move` only moves content. All symlink management is handled by git, so you have to keep repositories in sync using git as you would any other repo. When you `git pull B` in A, it will get whatever symlinks were added to B.
+
+(It can be useful to use a central bare repo and avoid needing to git pull from one repo to another, then you can just always push commits to the central repo, and pull down all changes from other repos.)
+"""]]
diff --git a/doc/walkthrough/moving_file_content_between_repositories/comment_3_558d80384434207b9cfc033763863de3._comment b/doc/walkthrough/moving_file_content_between_repositories/comment_3_558d80384434207b9cfc033763863de3._comment
new file mode 100644
index 0000000000..9a128f1ed6
--- /dev/null
+++ b/doc/walkthrough/moving_file_content_between_repositories/comment_3_558d80384434207b9cfc033763863de3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 3"
+ date="2011-03-23T02:07:49Z"
+ content="""
+Ah yes, I feel kinda stupid in hindsight.
+
+As the central server is most likely a common use case, would you object if I added that to the walkthrough? If you have any best practices on how to automate a push with every copy to a bare remote? AFAIK, git does not store information about bare/non-bare remotes, but this could easily be put into .git/config by git annex.
+
+-- RichiH
+"""]]
diff --git a/doc/walkthrough/moving_file_content_between_repositories/comment_4_a2f343eceed9e9fba1670f21e0fc6af4._comment b/doc/walkthrough/moving_file_content_between_repositories/comment_4_a2f343eceed9e9fba1670f21e0fc6af4._comment
new file mode 100644
index 0000000000..8b4d9a0538
--- /dev/null
+++ b/doc/walkthrough/moving_file_content_between_repositories/comment_4_a2f343eceed9e9fba1670f21e0fc6af4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 4"
+ date="2011-03-23T15:28:00Z"
+ content="""
+I would not mind if the walkthrough documented the central git repo case. But I don't want to complicate it unduely (it's long enough), and it's important that the fully distributed case be shown to work, and I assume that people already have basic git knowledge, so documenting the details of set up of a bare git repo is sorta out of scope. (There are also a lot of way to do it, using github, or gitosis, or raw git, etc.)
+"""]]
diff --git a/doc/walkthrough/quiet_please__58___When_git-annex_seems_to_skip_files.mdwn b/doc/walkthrough/quiet_please__58___When_git-annex_seems_to_skip_files.mdwn
new file mode 100644
index 0000000000..6909e5248a
--- /dev/null
+++ b/doc/walkthrough/quiet_please__58___When_git-annex_seems_to_skip_files.mdwn
@@ -0,0 +1,27 @@
+One behavior of git-annex is sometimes confusing at first, but it turns out
+to be useful once you get to know it.
+
+	$ git annex drop *
+	$ 
+
+Why didn't git-annex seem to do anything despite being asked to drop all the
+files? Because it checked them all, and none of them are present.
+
+Most git-annex commands will behave this way when they're able to quickly
+check that nothing needs to be done about a file.
+
+Running a git-annex command without specifying any file name will
+make git-annex look for files in the current directory and its
+subdirectories. So, we can add all new files to the annex easily:
+
+	$ echo hi > subdir/subsubdir/newfile
+	$ git annex add
+	add subdir/subsubdir/newfile ok
+
+When doing this kind of thing, having nothing shown for files
+that it doesn't need to act on is useful because it prevents swamping
+you with output. You only see the files it finds it does need to act on.
+
+So remember: If git-annex seems to not do anything when you tell it to, it's
+not being lazy -- It's checked that nothing needs to be done to get to the
+state you asked for!
diff --git a/doc/walkthrough/removing_files.mdwn b/doc/walkthrough/removing_files.mdwn
new file mode 100644
index 0000000000..d3dd926ade
--- /dev/null
+++ b/doc/walkthrough/removing_files.mdwn
@@ -0,0 +1,17 @@
+When you're using git-annex you can `git rm` a file just like you usually
+would with git. Just like with git, this removes the file from your work
+tree, but it does not remove the file's content from the git repository.
+If you check the file back out, or revert the removal, you can get it back.
+
+Git-annex adds the ability to remove the content of a file from your local
+repository to save space. This is called "dropping" the file. 
+
+You can always drop files safely. Git-annex checks that some other
+repository still has the file before removing it.
+
+	$ git annex drop iso/debian.iso
+	drop iso/Debian_5.0.iso ok
+
+Once dropped, the file will still appear in your work tree as a broken symlink.
+You can use `git annex get` to as usual to get this file back to your local
+repository.
diff --git a/doc/walkthrough/removing_files/comment_1_cb65e7c510b75be1c51f655b058667c6._comment b/doc/walkthrough/removing_files/comment_1_cb65e7c510b75be1c51f655b058667c6._comment
new file mode 100644
index 0000000000..1c8719cecd
--- /dev/null
+++ b/doc/walkthrough/removing_files/comment_1_cb65e7c510b75be1c51f655b058667c6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="DavidEdmondson"
+ subject="Is it necessary to commit after the 'drop'?"
+ date="2011-09-05T15:43:25Z"
+ content="""
+In fact is it possible? Nothing changed as far as git is concerned.
+
+"""]]
diff --git a/doc/walkthrough/removing_files/comment_2_64709ea4558915edd5c8ca4486965b07._comment b/doc/walkthrough/removing_files/comment_2_64709ea4558915edd5c8ca4486965b07._comment
new file mode 100644
index 0000000000..f5fb8dc7f5
--- /dev/null
+++ b/doc/walkthrough/removing_files/comment_2_64709ea4558915edd5c8ca4486965b07._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-09-05T15:59:27Z"
+ content="""
+Good catch. It used to be necessary before there was a git-annex branch, but not now.
+"""]]
diff --git a/doc/walkthrough/removing_files/comment_3_91e995867a731325dfdf3331f69a238c._comment b/doc/walkthrough/removing_files/comment_3_91e995867a731325dfdf3331f69a238c._comment
new file mode 100644
index 0000000000..abea8c740c
--- /dev/null
+++ b/doc/walkthrough/removing_files/comment_3_91e995867a731325dfdf3331f69a238c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="fbicknel@01ede624a1a56b3998b823e9b60da0ff81cccb16"
+ nickname="fbicknel"
+ subject="Complete removal"
+ date="2015-12-10T16:16:43Z"
+ content="""
+So, and I hope this isn't too Captain Obvious, if we drop the file at each repo, we essentially remove it from existence as far as this git-annex cluster is concerned?
+"""]]
diff --git a/doc/walkthrough/removing_files/comment_4_9b575f7f2b67b36599890dd5455dcf47._comment b/doc/walkthrough/removing_files/comment_4_9b575f7f2b67b36599890dd5455dcf47._comment
new file mode 100644
index 0000000000..45cd29937f
--- /dev/null
+++ b/doc/walkthrough/removing_files/comment_4_9b575f7f2b67b36599890dd5455dcf47._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 4"
+ date="2015-12-10T18:58:46Z"
+ content="""
+Correct, dropping a file from everywhere will lose its content entirely.
+
+But, git-annex has a [[copies]] tracking feature that prevents such foot-shooting. If you ask it to drop the last copy, it will refuse, although there is a way to override this if you really want to.
+"""]]
diff --git a/doc/walkthrough/removing_files__58___When_things_go_wrong.mdwn b/doc/walkthrough/removing_files__58___When_things_go_wrong.mdwn
new file mode 100644
index 0000000000..3baf0a55a6
--- /dev/null
+++ b/doc/walkthrough/removing_files__58___When_things_go_wrong.mdwn
@@ -0,0 +1,24 @@
+Before dropping a file, git-annex wants to be able to look at other
+remotes, and verify that they still have a file. After all, it could
+have been dropped from them too. If the remotes are not mounted/available,
+you'll see something like this.
+
+	$ git annex drop important_file other.iso
+	drop important_file (unsafe)
+	  Could only verify the existence of 0 out of 1 necessary copies
+	  Unable to access these remotes: usbdrive
+	  Try making some of these repositories available:
+	   	58d84e8a-d9ae-11df-a1aa-ab9aa8c00826  -- portable USB drive
+	   	ca20064c-dbb5-11df-b2fe-002170d25c55  -- backup SATA drive
+	  (Use --force to override this check, or adjust numcopies.)
+	failed
+	drop other.iso (unsafe)
+	  Could only verify the existence of 0 out of 1 necessary copies
+          No other repository is known to contain the file.
+	  (Use --force to override this check, or adjust numcopies.)
+	failed
+
+Here you might --force it to drop `important_file` if you [[trust]] your backup.
+But `other.iso` looks to have never been copied to anywhere else, so if
+it's something you want to hold onto, you'd need to transfer it to
+some other repository before dropping it.
diff --git a/doc/walkthrough/renaming_files.mdwn b/doc/walkthrough/renaming_files.mdwn
new file mode 100644
index 0000000000..3fe1866360
--- /dev/null
+++ b/doc/walkthrough/renaming_files.mdwn
@@ -0,0 +1,13 @@
+	$ cd ~/annex
+	$ git mv big_file my_cool_big_file
+	$ mkdir iso
+	$ git mv debian.iso iso/
+	$ git commit -m moved
+
+You can use any normal git operations to move files around, or even
+make copies or delete them.
+
+Notice that, since annexed files are represented by symlinks,
+the symlink will break when the file is moved into a subdirectory.
+But, git-annex will fix this up for you when you commit --
+it has a pre-commit hook that watches for and corrects broken symlinks.
diff --git a/doc/walkthrough/renaming_files/comment_1_c05f70079c265d23e882f92aaa4d28f8._comment b/doc/walkthrough/renaming_files/comment_1_c05f70079c265d23e882f92aaa4d28f8._comment
new file mode 100644
index 0000000000..9173399aef
--- /dev/null
+++ b/doc/walkthrough/renaming_files/comment_1_c05f70079c265d23e882f92aaa4d28f8._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="ptspts@d0db5f2b8c4e6befae8899f31c117d093913f43e"
+ nickname="ptspts"
+ subject="renaming oesn't work as expected when changing the extension"
+ date="2015-10-15T08:54:08Z"
+ content="""
+I tried to rename a `.gif` file to `.jpg`:
+
+    $ git annex version
+    git-annex version: 5.20140127
+    build flags: S3 DBus Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web tahoe glacier hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+    $ find .git/annex/objects -type f
+    .git/annex/objects/JW/wq/SHA256E-s231374848--01ca5e0bb09d068f15ccbf9b064b72f573198bd7516ff8edc72e455a09bf9bd4.gif/SHA256E-s231374848--01ca5e0bb09d068f15ccbf9b064b72f573198bd7516ff8edc72e455a09bf9bd4.gif
+    $ git mv foo.gif foo.jpg
+    $ git commit -a -m renamed
+    ...
+    $ git annex fsck
+    ...
+    $ find .git/annex/objects -type f
+    .git/annex/objects/JW/wq/SHA256E-s231374848--01ca5e0bb09d068f15ccbf9b064b72f573198bd7516ff8edc72e455a09bf9bd4.gif/SHA256E-s231374848--01ca5e0bb09d068f15ccbf9b064b72f573198bd7516ff8edc72e455a09bf9bd4.gif
+    $ ls -l foo.jpg
+    lrwxrwxrwx 1 pts pts 202 Oct 15 10:36 foo.jpg -> .git/annex/objects/JW/wq/SHA256E-s231374848--01ca5e0bb09d068f15ccbf9b064b72f573198bd7516ff8edc72e455a09bf9bd4.gif/SHA256E-s231374848--01ca5e0bb09d068f15ccbf9b064b72f573198bd7516ff8edc72e455a09bf9bd4.gif
+
+I would expect that the last extension printed is .jpg, rather than .gif. How do I make git-annex fix that, preferably without calling `git annex fsck`, which is very slow, because it rehashes the file?
+
+"""]]
diff --git a/doc/walkthrough/renaming_files/comment_2_fe83c600e080131b3109fe616940a25e._comment b/doc/walkthrough/renaming_files/comment_2_fe83c600e080131b3109fe616940a25e._comment
new file mode 100644
index 0000000000..7afbd1e03a
--- /dev/null
+++ b/doc/walkthrough/renaming_files/comment_2_fe83c600e080131b3109fe616940a25e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2015-10-15T10:59:59Z"
+ content="""
+*migrate* takes the *--force* option (introduced 5.20150327), allowing you to migrate files to the backend they are already using, but using the new extension. It was actually added for this use case!
+
+This may still incur a hash of the file though as, I believe, *migrate* will check the file at the old key is valid. You will also end up with 2 versions of the file in .git/annex/objects though (you can clean it up with *unused*).
+"""]]
diff --git a/doc/walkthrough/renaming_files/comment_3_6b579a4f2990a28b33a8170ebd39da5c._comment b/doc/walkthrough/renaming_files/comment_3_6b579a4f2990a28b33a8170ebd39da5c._comment
new file mode 100644
index 0000000000..a5edbcf2d8
--- /dev/null
+++ b/doc/walkthrough/renaming_files/comment_3_6b579a4f2990a28b33a8170ebd39da5c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-10-15T18:46:50Z"
+ content="""
+This is basically the same as thinking that git should change the SHA1
+used to refer to a file in the repository just because it was renamed.
+That does not normally make sense.
+
+Including the original extension in the git-annex key is done to avoid
+confusing some poorly-behaved programs that expect to follow the symlink
+and find a file with an extension. It's best to ignore the extension part
+of the key, or if you like, you can change the [[backend|doc/backends]] from SHA256E to
+SHA256, and then new keys won't include that extension.
+"""]]
diff --git a/doc/walkthrough/renaming_files/comment_4_1cf4cb6be73223755cb611ec097d1498._comment b/doc/walkthrough/renaming_files/comment_4_1cf4cb6be73223755cb611ec097d1498._comment
new file mode 100644
index 0000000000..beeccc6acf
--- /dev/null
+++ b/doc/walkthrough/renaming_files/comment_4_1cf4cb6be73223755cb611ec097d1498._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="dusty@dba9614abc02e013134f95c2c59181a6c12a8468"
+ nickname="dusty"
+ subject="moving files with git mv can yield broken symlink"
+ date="2016-08-23T21:48:59Z"
+ content="""
+Hey Joey,
+
+Just wondering how we rename/move files around into different directories within a repository without breaking the symbolic links. If we move to a different directory and the depth is different than where the files were originally in the repo then the symbolic link is broken.
+
+Thanks
+"""]]
diff --git a/doc/walkthrough/renaming_files/comment_5_bc3e37868b276c52a51586641cdb92ae._comment b/doc/walkthrough/renaming_files/comment_5_bc3e37868b276c52a51586641cdb92ae._comment
new file mode 100644
index 0000000000..5ca3bad944
--- /dev/null
+++ b/doc/walkthrough/renaming_files/comment_5_bc3e37868b276c52a51586641cdb92ae._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="dusty@dba9614abc02e013134f95c2c59181a6c12a8468"
+ nickname="dusty"
+ subject="Nevermind - broken symlinks will be fixed on commit"
+ date="2016-08-23T21:53:05Z"
+ content="""
+
+Didn't catch this from the docs above: 
+
+\"Notice that, since annexed files are represented by symlinks, the symlink will break when the file is moved into a subdirectory. But, git-annex will fix this up for you when you commit -- it has a pre-commit hook that watches for and corrects broken symlinks.\"
+
+
+"""]]
diff --git a/doc/walkthrough/renaming_files/comment_6_2ae2cc3dba5db4d4354a5b49c490272e._comment b/doc/walkthrough/renaming_files/comment_6_2ae2cc3dba5db4d4354a5b49c490272e._comment
new file mode 100644
index 0000000000..d6db355683
--- /dev/null
+++ b/doc/walkthrough/renaming_files/comment_6_2ae2cc3dba5db4d4354a5b49c490272e._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Bitten again by &quot;E&quot; backend, wish &quot;e&quot; backend."
+ date="2016-10-30T19:19:21Z"
+ content="""
+Changing file extension is arguably not a very common use case.  But changing extension case is more common, especially when copying files from FAT filesystems through different ways (Card reader, plugging device directly), and causes troubles.
+
+# Concrete case
+
+A set of files were imported with extension NEF and JPG, by mistake (forgot to rename them first), using default (or is it?) backend SHA256E.
+
+When using `git annex reinject --known` to cleanup another copy, files were not detected as known.
+
+This will happen again and feels not very good.
+
+# Workaround
+
+Thanks to CandyAngel I know I can rename then use `git annex migrate --force` and `reinject` again.
+
+# Better solution
+
+A SHA256e backend (that squashes extensions to lowercase) would not have this problem.
+
+# Additional information
+
+Why not switch to plain SHA256 backend?  I'm a little paranoid (which makes me a good fit for using git-annex overall).  
+
+One of the reason I use git-annex is that its storage format is actually simple, and files can be accessed even on a computer that can read the plain filesystem, without git or git-annex required.  But in the lifetime of a filesystem, many bad things can happen and details of storage format may make a difference in case of major recovery (or even sanity check) scenario.  Hashes without extension feel somehow uncomfortable.  Lowercase extension backends feel much better.
+
+"""]]
diff --git a/doc/walkthrough/syncing.mdwn b/doc/walkthrough/syncing.mdwn
new file mode 100644
index 0000000000..149d6d0d0c
--- /dev/null
+++ b/doc/walkthrough/syncing.mdwn
@@ -0,0 +1,32 @@
+Notice that in the [[previous example|getting_file_content]], `git annex
+sync` was used. This lets git-annex know what has changed in the other
+repositories like the laptop, and so it knows about the files present there and can
+get them.
+
+Let's look at what the sync command does in more detail:
+
+	$ cd /media/usb/annex
+	$ git annex sync
+	commit
+	nothing to commit (working directory clean)
+	ok
+	pull laptop
+	ok
+	push laptop
+	ok
+
+After you run sync, the git repository will be updated with all changes
+made to its remotes, and any changes in the git repository will be pushed
+out to its remotes, where a sync will get them. This is especially useful
+when using git in a distributed fashion, without a [[central bare
+repository|tips/centralized_git_repository_tutorial]]. See [[sync]] for
+details.
+
+By default `git annex sync` only syncs the metadata about your
+files that is stored in git. It does not sync the contents of annexed
+files, that are managed by git-annex. To do that, you can use
+`git annex sync --content`
+
+There are also commands `git-annex pull` and `git-annex push` that are like
+`git-annex sync`, but only transfer in one direction, do not commit, and
+operate on the content of annexed files by default.
diff --git a/doc/walkthrough/transferring_files__58___When_things_go_wrong.mdwn b/doc/walkthrough/transferring_files__58___When_things_go_wrong.mdwn
new file mode 100644
index 0000000000..8fe3f03e0a
--- /dev/null
+++ b/doc/walkthrough/transferring_files__58___When_things_go_wrong.mdwn
@@ -0,0 +1,17 @@
+After a while, you'll have several annexes, with different file contents.
+You don't have to try to keep all that straight; git-annex does 
+[[location_tracking]] for you. If you ask it to get a file and the drive
+or file server is not accessible, it will let you know what it needs to get
+it:
+
+	$ git annex get video/hackity_hack_and_kaxxt.mov
+	get video/hackity_hack_and_kaxxt.mov (not available)
+	  Unable to access these remotes: usbdrive, server
+	  Try making some of these repositories available:
+	  	5863d8c0-d9a9-11df-adb2-af51e6559a49  -- my home file server
+	   	58d84e8a-d9ae-11df-a1aa-ab9aa8c00826  -- portable USB drive
+	   	ca20064c-dbb5-11df-b2fe-002170d25c55  -- backup SATA drive
+	failed
+	$ sudo mount /media/usb
+	$ git annex get video/hackity_hack_and_kaxxt.mov
+	get video/hackity_hack_and_kaxxt.mov (from usbdrive...) ok
diff --git a/doc/walkthrough/unused_data.mdwn b/doc/walkthrough/unused_data.mdwn
new file mode 100644
index 0000000000..0dd0f004db
--- /dev/null
+++ b/doc/walkthrough/unused_data.mdwn
@@ -0,0 +1,35 @@
+It's possible for data to accumulate in the annex that no files in any
+branch point to anymore. One way it can happen is if you `git rm` a file
+without first calling `git annex drop`. And, when you modify an annexed
+file, the old content of the file remains in the annex. Another way is when
+migrating between key-value [[backends]].
+
+This might be historical data you want to preserve, so git-annex defaults to
+preserving it. So from time to time, you may want to check for such data:
+
+	$ git annex unused
+	unused . (checking for unused data...) 
+	  Some annexed data is no longer used by any files in the repository.
+	    NUMBER  KEY
+	    1       SHA256-s86050597--6ae2688bc533437766a48aa19f2c06be14d1bab9c70b468af445d4f07b65f41e
+	    2       SHA1-s14--f1358ec1873d57350e3dc62054dc232bc93c2bd1
+	  (To see where data was previously used, try: git log --stat -S'KEY')
+	  (To remove unwanted data: git-annex dropunused NUMBER)
+	ok
+
+After running `git annex unused`, you can follow the instructions to examine
+the history of files that used the data, and if you decide you don't need that
+data anymore, you can easily remove it from your local repository.
+
+	$ git annex dropunused 1
+	dropunused 1 ok
+
+Hint: To drop a lot of unused data, use a command like this:
+
+	$ git annex dropunused 1-1000
+
+Rather than removing the data, you can instead send it to other
+repositories:
+
+	$ git annex copy --unused --to backup
+	$ git annex move --unused --to archive
diff --git a/doc/walkthrough/unused_data/comment_1_684b7b652d3a8ec04f32129c5528f1ab._comment b/doc/walkthrough/unused_data/comment_1_684b7b652d3a8ec04f32129c5528f1ab._comment
new file mode 100644
index 0000000000..2be2a6463f
--- /dev/null
+++ b/doc/walkthrough/unused_data/comment_1_684b7b652d3a8ec04f32129c5528f1ab._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="bremner"
+ ip="156.34.89.108"
+ subject="finding data that isn't unused, but should be."
+ date="2012-10-17T20:32:11Z"
+ content="""
+Sometimes links to annexed data still exists on some branch, when it was supposed to be dropped. Here is how I found these; perhaps there is a simpler way.
+
+    % git annex find --format '${key}\n' | sort > /tmp/known-keys
+    % find .git/annex/objects -type f -exec basename {} \; | sort  > /tmp/local-keys
+    % comm -23 /tmp/local-keys /tmp/known-keys
+
+to look for what branch these are on, try 
+
+    % git log --stat --all -S$key
+
+for one of the keys output above. In my case it was the same remote branch keeping them all alive.
+
+
+*EDIT* sort key lists to make comm work properly
+
+"""]]
diff --git a/doc/walkthrough/unused_data/comment_2_e2ccd9a209c7a104004e998135d4b675._comment b/doc/walkthrough/unused_data/comment_2_e2ccd9a209c7a104004e998135d4b675._comment
new file mode 100644
index 0000000000..91075ce24b
--- /dev/null
+++ b/doc/walkthrough/unused_data/comment_2_e2ccd9a209c7a104004e998135d4b675._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
+ nickname="Matthias"
+ subject="Keep historical data, but delete data never referenced"
+ date="2014-10-26T12:06:25Z"
+ content="""
+Is there an easy solution for the following? There are two kinds of \"unused\" I would like to treat differently:
+
+1. Kind \"really unused\": Was added once to the annex, but symlink was never committed
+2. Kind \"only history\": A commit contains a symlink to the data, but no active branch
+
+I want to preserve \"only history\", and only drop \"really unused\". What is an elegant way to do this? Thanks for your suggestions.
+"""]]
diff --git a/doc/walkthrough/unused_data/comment_3_5f973eb7c265015fcd400b6b0bbdf235._comment b/doc/walkthrough/unused_data/comment_3_5f973eb7c265015fcd400b6b0bbdf235._comment
new file mode 100644
index 0000000000..dcca0b0959
--- /dev/null
+++ b/doc/walkthrough/unused_data/comment_3_5f973eb7c265015fcd400b6b0bbdf235._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2014-10-31T20:31:39Z"
+ content="""
+`git-annex unused` looks at what data is used by git branches and tags, but
+not by other commits. It's a reasonable request and I have made a todo for
+it: [[todo/find_unused_in_any_commit]] .. But I am unure if it can be
+implemented to run fast enough to be usable.
+"""]]
diff --git a/doc/walkthrough/unused_data/comment_4_2110ed6316b6a0df4ef3e1c8bc97ab99._comment b/doc/walkthrough/unused_data/comment_4_2110ed6316b6a0df4ef3e1c8bc97ab99._comment
new file mode 100644
index 0000000000..8c6f04e274
--- /dev/null
+++ b/doc/walkthrough/unused_data/comment_4_2110ed6316b6a0df4ef3e1c8bc97ab99._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="tom_clune"
+ subject="dropping files after changing branches/tags"
+ date="2016-02-24T22:19:00Z"
+ content="""
+I have a use case in which a colleague wishes to have a working copy of my data repository to use with the current version of my model.    When a new version of the model is available they would likewise update their git-annex clone of my data.    The colleague wants to drop any files that have been made obsolete by this change, but I do not see an efficient way to make this determination.   They could of course drop everything and then do git annex get .   but that could be very expensive if only a small subset of the files have actually changed.
+
+I'm probably just missing something basic, as this seems to be a reasonably frequent use case.
+
+
+"""]]
diff --git a/doc/walkthrough/unused_data/comment_5_46acb9fbbd5ef19f65115723888f3eb6._comment b/doc/walkthrough/unused_data/comment_5_46acb9fbbd5ef19f65115723888f3eb6._comment
new file mode 100644
index 0000000000..2e8af7ff55
--- /dev/null
+++ b/doc/walkthrough/unused_data/comment_5_46acb9fbbd5ef19f65115723888f3eb6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-03-14T20:33:13Z"
+ content="""
+Tom, it should suffice for your colleague to pull the new
+version from you, and then run `git annex unused` to find unused files.
+
+Now, if you have other branches or tags pointing at older versions
+of the data, those files will still be considered to be used, even if 
+the current version doesn't use them. There's a new
+`--used-refspec` option for [[git-annex unused|git-annex-unused]] that 
+you can use to specify which branches to consider to be used.
+"""]]
diff --git a/doc/walkthrough/using_bup.mdwn b/doc/walkthrough/using_bup.mdwn
new file mode 100644
index 0000000000..9826685e6d
--- /dev/null
+++ b/doc/walkthrough/using_bup.mdwn
@@ -0,0 +1,37 @@
+Another [[special_remote|special_remotes]] that git-annex can use is
+a [[special_remotes/bup]] repository. Bup stores large file contents
+in a git repository of its own, with deduplication. Combined with
+git-annex, you can have git on both the frontend and the backend.
+
+Here's how to create a bup remote, and describe it.
+
+[[!template id=note text="""
+Instead of specifying a remote system, you could choose to make a bup
+remote that is only accessible on the current system, by passing
+"buprepo=/big/mybup".
+"""]]
+
+	$ git annex initremote mybup type=bup encryption=none buprepo=example.com:/big/mybup
+	initremote bup (bup init)
+	Initialized empty Git repository in /big/mybup/
+	ok
+	$ git annex describe mybup "my bup repository at example.com"
+	describe mybup ok
+
+Now the remote can be used like any other remote.
+
+	$ git annex move my_cool_big_file --to mybup
+	move my_cool_big_file (to mybup...)
+	Receiving index from server: 1100/1100, done.
+	ok
+
+Note that, unlike other remotes, bup does not really support removing
+content from its git repositories. This is a feature. :)
+
+	$ git annex move my_cool_big_file --from mybup
+	move my_cool_big_file (from mybup...)
+	  content cannot be removed from bup remote
+	failed
+	git-annex: 1 failed
+
+See [[special_remotes/bup]] for details.
diff --git a/doc/walkthrough/using_ddar.mdwn b/doc/walkthrough/using_ddar.mdwn
new file mode 100644
index 0000000000..83661b9620
--- /dev/null
+++ b/doc/walkthrough/using_ddar.mdwn
@@ -0,0 +1,32 @@
+Another [[special_remote|special_remotes]] that git-annex can use is
+a [[special_remotes/ddar]] repository. ddar stores large file contents
+in a directory structure of its own, with deduplication. For remote
+repositories, ddar requires that ssh is available on the remote, with ddar also
+installed remotely. When copying files to the remote, ddar only needs to send
+over the network the parts of the files that are not already present remotely.
+
+Unlike bup, ddar uses its own storage format, which allows for both creation
+and deletion of de-deduplicated files.
+
+Here's how to create a ddar remote, and describe it.
+
+[[!template id=note text="""
+Instead of specifying a remote system, you could choose to make a ddar
+remote that is only accessible on the current system, by passing
+"ddarrepo=/big/myddar".
+"""]]
+
+	$ git annex initremote myddar type=ddar encryption=none ddarrepo=example.com:/big/myddar
+	initremote ddar (ddar init)
+	Initialized empty Git repository in /big/myddar/
+	ok
+	$ git annex describe myddar "my ddar repository at example.com"
+	describe myddar ok
+
+Now the remote can be used like any other remote.
+
+	$ git annex move my_cool_big_file --to myddar
+	move my_cool_big_file (to myddar...)
+	ok
+
+See [[special_remotes/ddar]] for details.
diff --git a/doc/walkthrough/using_special_remotes.mdwn b/doc/walkthrough/using_special_remotes.mdwn
new file mode 100644
index 0000000000..bf55fd2ef2
--- /dev/null
+++ b/doc/walkthrough/using_special_remotes.mdwn
@@ -0,0 +1,53 @@
+We've seen above that git-annex can be used to store files in
+regular git remotes, accessed either via ssh, or on a removable drive. But
+git-annex can also store files in Amazon S3, Glacier, on a rsync server, in
+WebDAV, or even pull files down from the web and bittorrent.
+This and much more is made possible by [[special_remotes]].
+
+These are not normal git repositories; indeed the git repository is not
+stored on a special remote. But git-annex can store the contents of files
+in special remotes, and operate on them much as it would on any other
+remote. Bonus: Files stored on special remotes can easily be
+[[encrypted|encryption]]!
+
+All you need to get started using a special remote is to initialize it.
+This is done using the `git annex initremote` command, which needs to be
+passed different parameters depending on the type of special remote.
+
+Some special remotes also need things like passwords to be set in
+environment variables. Don't worry -- it will prompt if you leave anything off.
+So feel free to make any kind of special remote instead of the S3 remote
+used in this example.
+
+	$ export AWS_ACCESS_KEY_ID="somethingotherthanthis"
+	$ export AWS_SECRET_ACCESS_KEY="s3kr1t"
+	$ git annex initremote mys3 type=S3 chunk=1MiB encryption=shared
+	initremote mys3 (shared encryption) (checking bucket) (creating bucket in US) ok
+
+Now you can store files on the newly initialized special remote.
+
+	$ git annex copy my_cool_big_file --to mys3
+	copy my_cool_big_file (to mys3...) ok
+
+Once you've initialized a special remote in one repository, you can enable
+use of the same special remote in other clones of the repository.
+If the mys3 remote above was initialized on your laptop, you'll also want
+to enable it on your desktop.
+
+To do so, first get git-annex in sync (so it knows about
+the special remote that was added in the other repository), and then
+use `git annex enableremote`.
+
+	desktop$ git annex sync
+	desktop$ export AWS_ACCESS_KEY_ID="somethingotherthanthis"
+	desktop$ export AWS_SECRET_ACCESS_KEY="s3kr1t"
+	desktop$ git annex enableremote mys3
+	enableremote mys3 (checking bucket) ok
+
+And now you can download files from the special remote:
+
+	desktop$ git annex get my_cool_big_file --from mys3
+	get my_cool_big_file (from mys3...) ok
+
+This has only scratched the surface of what can be done with
+[[special_remotes]].
diff --git a/doc/walkthrough/using_ssh_remotes.mdwn b/doc/walkthrough/using_ssh_remotes.mdwn
new file mode 100644
index 0000000000..a20c9597e5
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes.mdwn
@@ -0,0 +1,36 @@
+So far in this walkthrough, git-annex has been used with a remote
+repository on a USB drive. But it can also be used with a git remote
+that is truly remote, a host accessed by ssh.
+
+Say you have a desktop on the same network as your laptop and want
+to clone the laptop's annex to it:
+
+	desktop$ git clone ssh://mylaptop/home/me/annex ~/annex
+	desktop$ cd ~/annex
+	desktop$ git annex init "my desktop"
+
+Now you can get files and they will be transferred (using `rsync` via `ssh`):
+
+	desktop$ git annex get my_cool_big_file
+	get my_cool_big_file (getting UUID for origin...) (from origin...)
+	SHA256-s86050597--6ae2688bc533437766a48aa19f2c06be14d1bab9c70b468af445d4f07b65f41e  100% 2159     2.1KB/s   00:00
+	ok
+
+When you drop files, git-annex will ssh over to the remote and make
+sure the file's content is still there before removing it locally:
+
+	desktop$ git annex drop my_cool_big_file
+	drop my_cool_big_file (checking origin..) ok
+
+Note that normally git-annex prefers to use non-ssh remotes, like
+a USB drive, before ssh remotes. They are assumed to be faster/cheaper to
+access, if available. There is a annex-cost setting you can configure in
+`.git/config` to adjust which repositories it prefers. See
+[[the_man_page|git-annex]] for details.
+
+Also, note that you need full shell access for this to work -- 
+git-annex needs to be able to ssh in and run commands. Or at least,
+your shell needs to be able to run the [[git-annex-shell]] command.
+
+For details on setting up ssh remotes, see the
+[[tips/centralized_git_repository_tutorial]].
diff --git a/doc/walkthrough/using_ssh_remotes/comment_10_98e97c4d7fbbcd449eddf683967a71d6._comment b/doc/walkthrough/using_ssh_remotes/comment_10_98e97c4d7fbbcd449eddf683967a71d6._comment
new file mode 100644
index 0000000000..6cd9bb8485
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes/comment_10_98e97c4d7fbbcd449eddf683967a71d6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawla7u6eLKNYZ09Z7xwBffqLaXquMQC07fU"
+ nickname="Matthias"
+ subject="Hint for Debian/Ubuntu"
+ date="2012-11-07T13:10:15Z"
+ content="""
+In Debian/Ubuntu the default .bashrc returns immediately if the shell is non-interactive. Make sure to setup the PATH such that it is updated with the location of git-annex-shell before this check! This just cost me an hour of debugging as I didn't notice the return statement early on...
+"""]]
diff --git a/doc/walkthrough/using_ssh_remotes/comment_11_f2775a151ed50caba27057bd9c38bae2._comment b/doc/walkthrough/using_ssh_remotes/comment_11_f2775a151ed50caba27057bd9c38bae2._comment
new file mode 100644
index 0000000000..9768300dc6
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes/comment_11_f2775a151ed50caba27057bd9c38bae2._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniXLhO9mLn-7EDfawdENZ2fQwlGy5w_oc"
+ nickname="Michał"
+ subject="unrecognized command"
+ date="2013-03-12T06:32:56Z"
+ content="""
+Thanks Matthias, I fought with this as well, this was the tip I needed to move on.  I'm using the Linux standalone, and I had 2 issues getting everything to work without getting git-annex-shell errors.
+
+1. The autoinstalled wrapper could not be found, I had to comment the \"Ubuntu exit\" line and add the $HOME/.ssh to path to get rid of \"command not found\"
+2. Had to modify the wrapper by replacing the \"$SSH_ORIGINAL_COMMAND\" by \"$@\" to get rid of \"fatal: unrecognized command ''\"
+
+
+"""]]
diff --git a/doc/walkthrough/using_ssh_remotes/comment_12_a8bc6110128431ca2a8624ddc75ea364._comment b/doc/walkthrough/using_ssh_remotes/comment_12_a8bc6110128431ca2a8624ddc75ea364._comment
new file mode 100644
index 0000000000..28c3aa92dd
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes/comment_12_a8bc6110128431ca2a8624ddc75ea364._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 12"
+ date="2013-03-12T11:15:11Z"
+ content="""
+@Michael, the standalone tarball is really meant to run the git-annex assistant. The first time \"git annex webapp\" is run, it will set up the ssh wrapper for you.
+
+I have updated the wrapper to work when ssh is not configured to force a key to run a command.
+"""]]
diff --git a/doc/walkthrough/using_ssh_remotes/comment_2_365db5820d96d5daa62c19fd76fcdf1e._comment b/doc/walkthrough/using_ssh_remotes/comment_2_365db5820d96d5daa62c19fd76fcdf1e._comment
new file mode 100644
index 0000000000..8973978ad8
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes/comment_2_365db5820d96d5daa62c19fd76fcdf1e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.81.112"
+ subject="comment 2"
+ date="2012-05-27T20:53:05Z"
+ content="""
+When `git annex get` does nothing, it's because it doesn't know a place to get the file from.
+
+This can happen if the `git-annex` branch has not propigated from the place where the file was added.
+For example, if on the laptop you had run `git pull ssh master`, that would only pull the master branch, not the git-annex branch. 
+
+An easy way to ensure the git-annex branch is kept in sync is to run `git annex sync`
+"""]]
diff --git a/doc/walkthrough/using_ssh_remotes/comment_2_451fd0c6a25ee61ef137e8e5be0c286b._comment b/doc/walkthrough/using_ssh_remotes/comment_2_451fd0c6a25ee61ef137e8e5be0c286b._comment
new file mode 100644
index 0000000000..2121401968
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes/comment_2_451fd0c6a25ee61ef137e8e5be0c286b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkaT0B6s9jQuMzQUYRVBgWqtO7BhT_ZSaE"
+ nickname="Fernando Seabra"
+ subject="cannot get files"
+ date="2012-05-27T20:33:09Z"
+ content="""
+Hi,
+
+I could successfully clone my ssh repo's annex to my laptop, following these instructions.
+I'm also able to sync the repositories (laptop and ssh) when I commit new files in the ssh repo.
+
+However, every time I try to get files from the ssh repo (using 'git annex get some_file'), nothing happens.
+Do you know what can be happening?
+
+Thanks!
+"""]]
diff --git a/doc/walkthrough/using_ssh_remotes/comment_3_b2f15a46620385da26d5fe8f11ebfc1a._comment b/doc/walkthrough/using_ssh_remotes/comment_3_b2f15a46620385da26d5fe8f11ebfc1a._comment
new file mode 100644
index 0000000000..75a133d840
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes/comment_3_b2f15a46620385da26d5fe8f11ebfc1a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkaT0B6s9jQuMzQUYRVBgWqtO7BhT_ZSaE"
+ nickname="Fernando Seabra"
+ subject="comment 3"
+ date="2012-05-27T21:13:50Z"
+ content="""
+Thanks for the quick replay!
+
+I already did 'git annex sync', but it didn't work. The steps were: 'git clone ssh...', then 'cd annex', then 'git annex init \"laptop\"'
+
+After that, I did a 'git annex sync', and tried to get the file, but nothing happens. That's why I found it weird.
+Any other thing that might have happened?
+
+Thanks again!
+"""]]
diff --git a/doc/walkthrough/using_ssh_remotes/comment_4_433ccc87fbb0a13e32d59d77f0b4e56c._comment b/doc/walkthrough/using_ssh_remotes/comment_4_433ccc87fbb0a13e32d59d77f0b4e56c._comment
new file mode 100644
index 0000000000..3df03abc2c
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes/comment_4_433ccc87fbb0a13e32d59d77f0b4e56c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.81.112"
+ subject="comment 4"
+ date="2012-05-27T21:33:11Z"
+ content="""
+Try running `git annex whereis` on the file and see where it says it is.
+"""]]
diff --git a/doc/walkthrough/using_ssh_remotes/comment_5_a9805c7965da0b88a1c9f7f207c450a1._comment b/doc/walkthrough/using_ssh_remotes/comment_5_a9805c7965da0b88a1c9f7f207c450a1._comment
new file mode 100644
index 0000000000..703b89ebfa
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes/comment_5_a9805c7965da0b88a1c9f7f207c450a1._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkaT0B6s9jQuMzQUYRVBgWqtO7BhT_ZSaE"
+ nickname="Fernando Seabra"
+ subject="comment 5"
+ date="2012-05-27T21:42:56Z"
+ content="""
+Hi,
+
+I guess the problem is with git-annex-shell. I tried to do 'git annex get file --from name_ssh_repo', and I got the following:
+
+bash: git-annex-shell: command not found; failed; exit code 127
+
+The same thing happens if I try to do 'git annex whereis'
+
+git-annex-shell is indeed installed. How can I make my shell recognize this command?
+
+Thanks a lot!
+"""]]
diff --git a/doc/walkthrough/using_ssh_remotes/comment_6_9d5c12c056892b706cf100ea01866685._comment b/doc/walkthrough/using_ssh_remotes/comment_6_9d5c12c056892b706cf100ea01866685._comment
new file mode 100644
index 0000000000..4d5961ca90
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes/comment_6_9d5c12c056892b706cf100ea01866685._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.153.81.112"
+ subject="comment 6"
+ date="2012-05-27T22:08:50Z"
+ content="""
+git-annex-shell needs to be installed in the `PATH` on any host that will hold annexed files. 
+
+If you installed with cabal, it might be `.cabal/bin/`. Whereever it was installed to is apparently not on the PATH that is set when you ssh into that host. 
+
+
+"""]]
diff --git a/doc/walkthrough/using_ssh_remotes/comment_7_725e7dbb2d0a74a035127cb01ee0442c._comment b/doc/walkthrough/using_ssh_remotes/comment_7_725e7dbb2d0a74a035127cb01ee0442c._comment
new file mode 100644
index 0000000000..700b170ad6
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes/comment_7_725e7dbb2d0a74a035127cb01ee0442c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkaT0B6s9jQuMzQUYRVBgWqtO7BhT_ZSaE"
+ nickname="Fernando Seabra"
+ subject="comment 7"
+ date="2012-05-27T23:35:17Z"
+ content="""
+Hi,
+
+It was already installed in PATH. In fact, I can call it from the command line, and it is recognized (e.g. calling 'git-annex-shell' gives me 'git-annex-shell: bad parameters'). However, every time I do a 'git annex whereis' or 'git annex get file --from repo', it gives me the following error:
+
+bash: git-annex-shell: command not found
+Command ssh [\"-S\",\"/Users/username/annex/.git/annex/ssh/username@example.edu\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"username@example.edu\",\"git-annex-shell 'configlist' '/~/annex'\"] failed; exit code 127
+
+I tried to run this ssh command, but it gives me the same 'command not found' error. It seems that the problem is with the ssh repo?
+The ssh repo has a git-annex-shell working and installed in PATH.
+"""]]
diff --git a/doc/walkthrough/using_ssh_remotes/comment_8_8448e55026d2c2b50d8da41707686bea._comment b/doc/walkthrough/using_ssh_remotes/comment_8_8448e55026d2c2b50d8da41707686bea._comment
new file mode 100644
index 0000000000..148f016db7
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes/comment_8_8448e55026d2c2b50d8da41707686bea._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmB-gCGEs--zfmvYU-__Hj2FbliUXgxMDs"
+ nickname="Jakub"
+ subject="Path problems"
+ date="2012-07-13T19:15:15Z"
+ content="""
+Hi,
+
+I have a same 'git-annex-shell command not found' problem as above. I've installed git annex via cabal into my ~/.haskell_bin directory. Then I've added this dir both to ~/.bashrc and ~/.zshrc. I can run git annex or 'git annex-shell' and everything is fine. My guess is that haskell is trying to spawn git-annex-shell with some current $PATH unaware shell like dash maybe?
+
+I've fixed this behavior by using a really ugly hack - I've symlinked ~/.haskell_bin/git-annex-shell to /usr/bin/git-annex-shell on all my machines and the problem is gone. Somehow haskell (or whatever is trying to call git-annex-shell) is unaware of path modifications from .bashrc/.zshrc
+
+Here is the path modification I've used:
+
+export PATH=~/.haskell_bin:$PATH
+"""]]
diff --git a/doc/walkthrough/using_ssh_remotes/comment_9_61833299a9878f23ac57598fa6da8839._comment b/doc/walkthrough/using_ssh_remotes/comment_9_61833299a9878f23ac57598fa6da8839._comment
new file mode 100644
index 0000000000..ddb96da369
--- /dev/null
+++ b/doc/walkthrough/using_ssh_remotes/comment_9_61833299a9878f23ac57598fa6da8839._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmB-gCGEs--zfmvYU-__Hj2FbliUXgxMDs"
+ nickname="Jakub"
+ subject="Fixed"
+ date="2012-07-13T19:27:46Z"
+ content="""
+Found the problem:
+
+One should never use ~ in such path:
+
+WRONG export PATH=~/somedir:$PATH
+
+Instead one should use $HOME:
+
+GOOD export PATH=$HOME/somedir:$PATH
+
+Can I surpress the message that shell failed with status 255 when a repo is unavailible? I've got two repos pointing to one machine - either via vpn or local lan and I keep getting erros if one is unavailible:
+
+ssh: connect to host 10.9.0.1 port 39882: No route to host
+Command ssh [\"-S\",\"/home/pielgrzym/annex/.git/annex/ssh/nas\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"nas\",\"git-annex-shell 'configlist' '/~/annex'\"] failed; exit code 255
+
+
+"""]]
diff --git a/doc/walkthrough/using_tags_and_branches.mdwn b/doc/walkthrough/using_tags_and_branches.mdwn
new file mode 100644
index 0000000000..d048bfce83
--- /dev/null
+++ b/doc/walkthrough/using_tags_and_branches.mdwn
@@ -0,0 +1,14 @@
+Like git, git-annex hangs on to every old version of a file (by default),
+so you can make tags and branches, and can check them out later to look at
+the old files.
+
+	$ git tag 1.0
+	$ rm -f my_cool_big_file
+	$ git commit -m deleted
+	$ git checkout 1.0
+	$ cat my_cool_big_file
+	yay! old version still here
+
+Of course, when you `git checkout` an old branch, some old versions of
+files may not be locally available, and may be stored in some other
+repository. You can use `git annex get` to get them as usual.
diff --git a/doc/workflow.mdwn b/doc/workflow.mdwn
new file mode 100644
index 0000000000..e5d440c6de
--- /dev/null
+++ b/doc/workflow.mdwn
@@ -0,0 +1,102 @@
+Git-annex supports a wide variety of workflows, a spectrum that ranges from
+completely automatic behavior where git-annex handles everything, through
+manual behavior where git-annex does only what you say when you tell it to,
+all the way down to internal behavior, where you have complete control and
+understand how everything is stored and exactly what changes are happening.
+
+I will proceed to summarize all of these. I will begin at the automatic
+end, hoping that this is most useful, and drill down to the low level
+approaches. Note, however, that this is the opposite order of how git-annex
+was developed. A list of workflows that started from manual,
+commandline usage would be much more intuitive, but you'd have to be
+willing to read the man page and wiki pages to get started, and that's
+pretty much what's already out there anyway.
+
+Note that for each of these levels of interaction, all the levels following
+will also work as well. So you can actually manually move annexed files
+around while the webapp is running, etc.
+
+# 1. [[git annex webapp|git-annex-webapp]]
+
+The [[`git annex webapp`|git-annex-webapp]] command launches a local web
+server which serves a graphical user interface and automatically manages
+git annex. It will attempt to guide you through the whole process and do
+everything for you. [[You do not even need to type the command.
+|assistant/quickstart]] This should be run on every machine that may
+produce file changes.  When you move files into or out of your repository
+folder, git-annex should record the changes and automatically propagate
+them to other connected machines.
+
+The webapp is part of the larger [[assistant]].
+
+# 2. [[git annex assistant|git-annex-assistant]] without the webapp
+
+You could call [[`git annex assistant`|git-annex-assistant]] the
+command-line version of the webapp, giving you more control over creating
+and connecting your repositories, and configuring how files are moved
+between them.
+
+The assistant, when running, will automatically watch for file changes and
+synchronize them to other repositories, but you must manually create the
+repositories and configure the rules for syncing. To create a repository,
+use `git init` and then [[`git annex init`|git-annex-init]], and then `git
+remote add` it to any other repositories. If you want more than one annex,
+you can add their paths to `~/.config/git-annex/autostart` if you would
+like them to automatically begin syncing when `git annex assistant
+--autostart` is run, perhaps on boot or login. You can configure rules for
+where files are copied using the repository setup commands such as [[git
+annex preferred-content|git-annex-preferred-content]] to configure
+[[content preferences|preferred content]] for what goes where, [[`git annex
+numcopies`|git-annex-numcopies]] for how many [[copies]] must be kept of
+each file, and [[`git config annex.largefiles`|tips/largefiles]] to define
+small files that should be stored straight in git; most of the settings are
+accessible in one place with [[`git annex vicfg`|git-annex-vicfg]].
+
+# 3. [[git annex watch|git-annex-watch]] without the assistant
+
+The [[`git annex watch`|git-annex-watch]] command is like the assistant but
+has no automatic network behavior, giving you complete control over when
+repositories are pushed and pulled, and when files are moved between
+systems. The local repository is watched, and any file changes are added to
+git-annex. In order to synchronize between repositories, you must run
+[[`git annex sync --content`|git-annex-sync]] in the repository with the
+changes, which will merge the git history and logs with your remotes, and
+automatically transfer files to match your preferred and required content
+expressions.
+
+# 4. No background processes
+
+This allows you to decide when and what files are annexed. In order to tell
+git-annex to manage files, you must [[`git annex add`|git-annex-add]] the
+files.
+
+# 5. Plain [[git annex sync|git-annex-sync]] without `--content`
+
+This gives you fine-grained control of where copies of your files are
+stored. [[`git annex sync`|git-annex-sync]] without `--content` tells
+git-annex to merge git histories, but it does not automatically transfer
+your large files between systems. To transfer files and directories, you
+can use [[`git annex get`|git-annex-get]], [[`git annex
+drop`|git-annex-drop]], [[`git annex move`|git-annex-move]], and [[`git
+annex copy`|git-annex-copy]]. Git-annex will not violate a required content
+expression or your numcopies setting unless you pass `--force`, so your
+files are still safe.
+
+# 6. Manual management of git history without the synchronizer
+
+This allows you to control precisely what is committed to git, what commit
+message is used, and how your history is merged between repositories. You
+must have an understanding of git, and run `git commit` after `git annex
+add` to store the change. You must manage the git history yourself, using
+`git pull` and `git push`, to synchronize repositories. You may freely use
+git normally side-by-side with git-annex.
+
+# 7. Manual management of git annex keys
+
+This gives you control of what and where git annex stores your files under
+the hood, and how they are associated with your working tree, rather than
+using the `git annex add` and `git annex get` commands which reference
+files automatically. Git-annex has a variety of plumbing commands listed in
+the [[man page|git-annex]] that let you directly store and retrieve data in
+an annex associated with your git repository, where every datafile is
+enumerated by a unique hashkey.
diff --git a/doc/workflow/comment_1_e4b2199944c3a248562bddf3cf9e2829._comment b/doc/workflow/comment_1_e4b2199944c3a248562bddf3cf9e2829._comment
new file mode 100644
index 0000000000..ff12c0eca4
--- /dev/null
+++ b/doc/workflow/comment_1_e4b2199944c3a248562bddf3cf9e2829._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="amindfv@6f75355c5dad3450ed73d1f01715be90dfdd6cd6"
+ nickname="amindfv"
+ avatar="http://cdn.libravatar.org/avatar/9cdda587f634ea9a85b34b25be421676"
+ subject="comment 1"
+ date="2019-09-26T15:19:12Z"
+ content="""
+For workflow 6 (\"Manual management of git history without the synchronizer\"), how can files be synchronized across repositories?
+
+Do you still need the workflow of adding remotes and using `git annex get --from=<remote-name>`?
+
+Is it possible to do some variant of `git annex get --from=</path/to/repo>`? How about `git annex get --from=<UUID>`? (And if so, side question: what's the best way to get a repo's UUID?)
+
+Is it possible to transfer files between repos without explicitly creating remotes? If so, how? Are there gotchas when moving files \"by hand\" like permissions to be set?
+
+Thanks!
+"""]]
diff --git a/doc/workflow/comment_2_67edac29c0e7b5a768511a0fd0878947._comment b/doc/workflow/comment_2_67edac29c0e7b5a768511a0fd0878947._comment
new file mode 100644
index 0000000000..26704ca5ad
--- /dev/null
+++ b/doc/workflow/comment_2_67edac29c0e7b5a768511a0fd0878947._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="why not git-annex-sync"
+ date="2019-09-26T17:47:55Z"
+ content="""
+Just curious, what makes you want to avoid using [[`git-annex-sync`|git-annex-sync]]?  Without it you'd need to manually sync the [[git-annex branch|internals#The_git-annex_branch]], and merge it using [[`git-annex-merge`|git-annex-merge]].
+
+\"what's the best way to get a repo's UUID\" -- [[`git-annex-info --fast`|git-annex-info]] prints it.
+"""]]
diff --git a/git-annex.cabal b/git-annex.cabal
new file mode 100644
index 0000000000..2098cd556d
--- /dev/null
+++ b/git-annex.cabal
@@ -0,0 +1,1101 @@
+Name: git-annex
+Version: 10.20240430
+Cabal-Version: 1.12
+License: AGPL-3
+Maintainer: Joey Hess <id@joeyh.name>
+Author: Joey Hess
+Stability: Stable
+Copyright: 2010-2024 Joey Hess
+License-File: COPYRIGHT
+Homepage: http://git-annex.branchable.com/
+Build-type: Custom
+Category: Utility
+Synopsis: manage files with git, without checking their contents into git
+Description:
+ git-annex allows managing files with git, without checking the file
+ contents into git. While that may seem paradoxical, it is useful when
+ dealing with files larger than git can currently easily handle, whether due
+ to limitations in memory, time, or disk space.
+ .
+ It can store large files in many places, from local hard drives, to a
+ large number of cloud storage services, including S3, WebDAV,
+ and rsync, and many other usable via plugins.
+ Files can be stored encrypted with gpg, so that the cloud storage
+ provider cannot see your data. git-annex keeps track of where each file
+ is stored, so it knows how many copies are available, and has many
+ facilities to ensure your data is preserved.
+ .
+ git-annex can also be used to keep a folder in sync between computers,
+ noticing when files are changed, and automatically committing them
+ to git and transferring them to other computers. The git-annex webapp
+ makes it easy to set up and use git-annex this way.
+-- The tarball uploaded to hackage does not include every non-haskell
+-- file in the git repo. The website is left out, as are man pages, 
+-- so is build machinery for standalone apps, and packages. 
+-- Include only files that are needed make cabal install git-annex work.
+Extra-Source-Files:
+  stack.yaml
+  stack-lts-18.13.yaml
+  README
+  CHANGELOG
+  NEWS
+  doc/license/GPL
+  doc/license/AGPL
+  doc/logo.svg
+  doc/logo_16x16.png
+  Assistant/WebApp/routes
+  static/activityicon.gif
+  static/css/bootstrap.css
+  static/css/bootstrap-theme.css
+  static/js/jquery.ui.core.js
+  static/js/longpolling.js
+  static/js/jquery.full.js
+  static/js/jquery.ui.sortable.js
+  static/js/jquery.ui.mouse.js
+  static/js/jquery.ui.widget.js
+  static/js/bootstrap.js
+  static/syncicon.gif
+  static/favicon.ico
+  static/fonts/glyphicons-halflings-regular.woff
+  static/fonts/glyphicons-halflings-regular.eot
+  static/fonts/glyphicons-halflings-regular.svg
+  static/fonts/glyphicons-halflings-regular.ttf
+  templates/sidebar/main.hamlet
+  templates/sidebar/alert.hamlet
+  templates/bootstrap.hamlet
+  templates/error.cassius
+  templates/README
+  templates/error.hamlet
+  templates/documentation/license.hamlet
+  templates/documentation/repogroup.hamlet
+  templates/documentation/about.hamlet
+  templates/dashboard/main.hamlet
+  templates/dashboard/transfers.cassius
+  templates/dashboard/transfers.hamlet
+  templates/dashboard/metarefresh.hamlet
+  templates/page.cassius
+  templates/page.hamlet
+  templates/control/repairrepository.hamlet
+  templates/control/repairrepository/done.hamlet
+  templates/control/notrunning.julius
+  templates/control/notrunning.hamlet
+  templates/control/repositoryswitcher.hamlet
+  templates/control/shutdown.hamlet
+  templates/control/log.hamlet
+  templates/page.julius
+  templates/repolist.julius
+  templates/configurators/adddrive/combine.hamlet
+  templates/configurators/adddrive/setupmodal.hamlet
+  templates/configurators/adddrive/encrypt.hamlet
+  templates/configurators/newrepository.hamlet
+  templates/configurators/needglaciercli.hamlet
+  templates/configurators/adds3.hamlet
+  templates/configurators/genkeymodal.hamlet
+  templates/configurators/main.hamlet
+  templates/configurators/needconnection.hamlet
+  templates/configurators/newrepository/form.hamlet
+  templates/configurators/newrepository/first.hamlet
+  templates/configurators/newrepository/combine.hamlet
+  templates/configurators/enablewebdav.hamlet
+  templates/configurators/pairing/local/inprogress.hamlet
+  templates/configurators/pairing/local/prompt.hamlet
+  templates/configurators/pairing/wormhole/prompt.hamlet
+  templates/configurators/pairing/wormhole/start.hamlet
+  templates/configurators/pairing/disabled.hamlet
+  templates/configurators/addglacier.hamlet
+  templates/configurators/fsck.cassius
+  templates/configurators/edit/nonannexremote.hamlet
+  templates/configurators/edit/webrepository.hamlet
+  templates/configurators/edit/repository.hamlet
+  templates/configurators/unused.hamlet
+  templates/configurators/ssh/testmodal.hamlet
+  templates/configurators/ssh/expiredpassword.hamlet
+  templates/configurators/ssh/error.hamlet
+  templates/configurators/ssh/combine.hamlet
+  templates/configurators/ssh/enable.hamlet
+  templates/configurators/ssh/add.hamlet
+  templates/configurators/ssh/setupmodal.hamlet
+  templates/configurators/ssh/confirm.hamlet
+  templates/configurators/enableia.hamlet
+  templates/configurators/fsck.hamlet
+  templates/configurators/addrepository/archive.hamlet
+  templates/configurators/addrepository/cloud.hamlet
+  templates/configurators/addrepository/connection.hamlet
+  templates/configurators/addrepository/ssh.hamlet
+  templates/configurators/addrepository/misc.hamlet
+  templates/configurators/addrepository/wormholepairing.hamlet
+  templates/configurators/rsync.net/add.hamlet
+  templates/configurators/rsync.net/encrypt.hamlet
+  templates/configurators/needgcrypt.hamlet
+  templates/configurators/needtor.hamlet
+  templates/configurators/needmagicwormhole.hamlet
+  templates/configurators/enabledirectory.hamlet
+  templates/configurators/fsck/status.hamlet
+  templates/configurators/fsck/form.hamlet
+  templates/configurators/fsck/preferencesform.hamlet
+  templates/configurators/fsck/formcontent.hamlet
+  templates/configurators/delete/finished.hamlet
+  templates/configurators/delete/start.hamlet
+  templates/configurators/delete/currentrepository.hamlet
+  templates/configurators/unused/form.hamlet
+  templates/configurators/adddrive.hamlet
+  templates/configurators/preferences.hamlet
+  templates/configurators/addia.hamlet
+  templates/configurators/enableaws.hamlet
+  templates/configurators/addrepository.hamlet
+  templates/actionbutton.hamlet
+  templates/repolist.hamlet
+  templates/controlmenu.hamlet
+  templates/notifications/longpolling.julius
+  Utility/libkqueue.h
+
+Flag Assistant
+  Description: Enable git-annex assistant, webapp, and watch command
+  Default: True
+
+Flag Pairing
+  Description: Enable pairing
+
+Flag Production
+  Description: Enable production build (slower build; faster binary)
+
+Flag ParallelBuild
+  Description: Enable production build (slower build; faster binary)
+  Default: False
+  Manual: True
+
+Flag TorrentParser
+  Description: Use haskell torrent library to parse torrent files
+
+Flag MagicMime
+  Description: Use libmagic to determine file MIME types
+
+Flag Crypton
+  Description: Use the crypton library rather than the no longer maintained cryptonite
+
+Flag Benchmark
+  Description: Enable benchmarking
+  Default: True
+
+Flag DebugLocks
+  Description: Debug location of MVar/STM deadlocks
+  Default: False
+
+Flag Dbus
+  Description: Enable dbus support
+
+source-repository head
+  type: git
+  location: git://git-annex.branchable.com/
+
+custom-setup
+  Setup-Depends:
+    base (>= 4.11.1.0 && < 5.0),
+    split,
+    filepath,
+    exceptions,
+    bytestring,
+    filepath-bytestring (>= 1.4.2.1.4),
+    process (>= 1.6.3),
+    time (>= 1.5.0),
+    directory (>= 1.2.7.0),
+    async,
+    utf8-string,
+    Cabal (< 4.0)
+
+Executable git-annex
+  Main-Is: git-annex.hs
+  Build-Depends:
+   base (>= 4.11.1.0 && < 5.0),
+   network-uri (>= 2.6),
+   optparse-applicative (>= 0.14.2),
+   containers (>= 0.5.8),
+   exceptions (>= 0.6),
+   stm (>= 2.3),
+   mtl (>= 2),
+   uuid (>= 1.2.6),
+   process (>= 1.6.3),
+   data-default,
+   case-insensitive,
+   random,
+   dlist,
+   unix-compat (>= 0.5 && < 0.8),
+   SafeSemaphore,
+   async,
+   directory (>= 1.2.7.0),
+   disk-free-space,
+   filepath,
+   filepath-bytestring (>= 1.4.2.1.1),
+   IfElse,
+   monad-logger (>= 0.3.10),
+   free,
+   utf8-string,
+   bytestring,
+   text,
+   sandi,
+   monad-control,
+   transformers,
+   bloomfilter (>= 2.0.0),
+   edit-distance,
+   resourcet,
+   http-client (>= 0.5.3),
+   http-client-tls,
+   http-types (>= 0.7),
+   http-conduit (>= 2.3.0),
+   http-client-restricted (>= 0.0.2),
+   conduit,
+   time (>= 1.5.0),
+   old-locale,
+   persistent-sqlite (>= 2.8.1),
+   persistent (>= 2.8.1),
+   persistent-template,
+   unliftio-core,
+   microlens,
+   aeson,
+   vector,
+   tagsoup,
+   unordered-containers,
+   feed (>= 1.0.0),
+   regex-tdfa,
+   socks,
+   byteable,
+   stm-chans,
+   securemem,
+   crypto-api,
+   memory,
+   deepseq,
+   split,
+   attoparsec (>= 0.13.2.2),
+   concurrent-output (>= 1.10),
+   unbounded-delays,
+   QuickCheck (>= 2.10.0),
+   tasty (>= 1.2),
+   tasty-hunit,
+   tasty-quickcheck,
+   tasty-rerun,
+   ansi-terminal >= 0.9,
+   aws (>= 0.20),
+   DAV (>= 1.0),
+   network (>= 3.0.0.0),
+   network-bsd,
+   git-lfs (>= 1.2.0)
+  CC-Options: -Wall
+  GHC-Options: -Wall -fno-warn-tabs  -Wincomplete-uni-patterns
+  Default-Language: Haskell2010
+  Default-Extensions: LambdaCase
+  Other-Extensions: TemplateHaskell
+  -- Some things don't work with the non-threaded RTS.
+  GHC-Options: -threaded
+
+  -- Fully optimize for production.
+  if flag(Production)
+    -- Lower memory systems can run out of memory with -O2, so
+    -- optimise slightly less.
+    if arch(arm)
+      GHC-Options: -O2 -optlo-O2
+    else
+      GHC-Options: -O2
+  else
+    GHC-Options: -O0
+
+  if flag(ParallelBuild)
+    GHC-Options: -j
+
+  -- Avoid linking with unused dynamic libraries.
+  if os(linux) || os(freebsd)
+    GHC-Options: -optl-Wl,--as-needed
+
+  if flag(Crypton)
+    Build-Depends: crypton
+    CPP-Options: -DWITH_CRYPTON
+  else
+    Build-Depends: cryptonite (>= 0.23)
+
+  if (os(windows))
+    Build-Depends:
+      Win32 ((>= 2.6.1.0 && < 2.12.0.0) || >= 2.13.4.0),
+      setenv,
+      process (>= 1.6.2.0),
+      silently (>= 1.2.5.1)
+  else
+    Build-Depends: unix (>= 2.7.2)
+
+  if flag(Assistant) && ! os(solaris) && ! os(gnu)
+    CPP-Options: -DWITH_ASSISTANT -DWITH_WEBAPP
+    Build-Depends:
+      mountpoints,
+      yesod (>= 1.4.3), 
+      yesod-static (>= 1.5.1),
+      yesod-form (>= 1.4.8),
+      yesod-core (>= 1.6.0),
+      path-pieces (>= 0.2.1),
+      warp (>= 3.2.8),
+      warp-tls (>= 3.2.2),
+      wai,
+      wai-extra,
+      blaze-builder,
+      clientsession,
+      template-haskell,
+      shakespeare (>= 2.0.11)
+    Other-Modules:
+      Assistant
+      Assistant.Alert
+      Assistant.Alert.Utility
+      Assistant.BranchChange
+      Assistant.Changes
+      Assistant.Commits
+      Assistant.Common
+      Assistant.CredPairCache
+      Assistant.DaemonStatus
+      Assistant.DeleteRemote
+      Assistant.Drop
+      Assistant.Fsck
+      Assistant.Gpg
+      Assistant.Install
+      Assistant.MakeRemote
+      Assistant.MakeRepo
+      Assistant.Monad
+      Assistant.NamedThread
+      Assistant.Pairing
+      Assistant.Pairing.MakeRemote
+      Assistant.Pairing.Network
+      Assistant.Pushes
+      Assistant.RemoteControl
+      Assistant.Repair
+      Assistant.RepoProblem
+      Assistant.Restart
+      Assistant.ScanRemotes
+      Assistant.Ssh
+      Assistant.Sync
+      Assistant.Threads.Committer
+      Assistant.Threads.ConfigMonitor
+      Assistant.Threads.Cronner
+      Assistant.Threads.DaemonStatus
+      Assistant.Threads.Exporter
+      Assistant.Threads.Glacier
+      Assistant.Threads.Merger
+      Assistant.Threads.MountWatcher
+      Assistant.Threads.NetWatcher
+      Assistant.Threads.PairListener
+      Assistant.Threads.ProblemFixer
+      Assistant.Threads.Pusher
+      Assistant.Threads.RemoteControl
+      Assistant.Threads.SanityChecker
+      Assistant.Threads.TransferPoller
+      Assistant.Threads.TransferScanner
+      Assistant.Threads.TransferWatcher
+      Assistant.Threads.Transferrer
+      Assistant.Threads.UpgradeWatcher
+      Assistant.Threads.Upgrader
+      Assistant.Threads.Watcher
+      Assistant.Threads.WebApp
+      Assistant.TransferQueue
+      Assistant.TransferSlots
+      Assistant.Types.Alert
+      Assistant.Types.BranchChange
+      Assistant.Types.Changes
+      Assistant.Types.Commits
+      Assistant.Types.CredPairCache
+      Assistant.Types.DaemonStatus
+      Assistant.Types.NamedThread
+      Assistant.Types.Pushes
+      Assistant.Types.RemoteControl
+      Assistant.Types.RepoProblem
+      Assistant.Types.ScanRemotes
+      Assistant.Types.ThreadName
+      Assistant.Types.ThreadedMonad
+      Assistant.Types.TransferQueue
+      Assistant.Types.TransferSlots
+      Assistant.Types.UrlRenderer
+      Assistant.Unused
+      Assistant.Upgrade
+      Assistant.WebApp
+      Assistant.WebApp.Common
+      Assistant.WebApp.Configurators
+      Assistant.WebApp.Configurators.AWS
+      Assistant.WebApp.Configurators.Delete
+      Assistant.WebApp.Configurators.Edit
+      Assistant.WebApp.Configurators.Fsck
+      Assistant.WebApp.Configurators.IA
+      Assistant.WebApp.Configurators.Local
+      Assistant.WebApp.Configurators.Pairing
+      Assistant.WebApp.Configurators.Preferences
+      Assistant.WebApp.Configurators.Ssh
+      Assistant.WebApp.Configurators.Unused
+      Assistant.WebApp.Configurators.Upgrade
+      Assistant.WebApp.Configurators.WebDAV
+      Assistant.WebApp.Control
+      Assistant.WebApp.DashBoard
+      Assistant.WebApp.Documentation
+      Assistant.WebApp.Form
+      Assistant.WebApp.Gpg
+      Assistant.WebApp.MakeRemote
+      Assistant.WebApp.Notifications
+      Assistant.WebApp.OtherRepos
+      Assistant.WebApp.Page
+      Assistant.WebApp.Pairing
+      Assistant.WebApp.Repair
+      Assistant.WebApp.RepoId
+      Assistant.WebApp.RepoList
+      Assistant.WebApp.SideBar
+      Assistant.WebApp.Types
+      Command.Assistant
+      Command.Watch
+      Command.WebApp
+      Utility.Mounts
+      Utility.Yesod
+      Utility.WebApp
+    
+    if os(linux)
+      Build-Depends: hinotify (>= 0.3.10)
+      CPP-Options: -DWITH_INOTIFY
+      Other-Modules: Utility.DirWatcher.INotify
+    else
+      if os(darwin)
+        Build-Depends: hfsevents
+        CPP-Options: -DWITH_FSEVENTS
+        Other-Modules:
+          Utility.DirWatcher.FSEvents
+      else
+        if os(windows)
+          Build-Depends: Win32-notify
+          CPP-Options: -DWITH_WIN32NOTIFY
+          Other-Modules: Utility.DirWatcher.Win32Notify
+        else
+          if (! os(solaris) && ! os(gnu) && ! os(linux))
+            CPP-Options: -DWITH_KQUEUE
+            C-Sources: Utility/libkqueue.c
+            Includes: Utility/libkqueue.h
+            Other-Modules: Utility.DirWatcher.Kqueue
+  
+  if flag(Dbus)
+    if (os(linux))
+      Build-Depends: dbus (>= 0.10.7), fdo-notify (>= 0.3)
+      CPP-Options: -DWITH_DBUS -DWITH_DESKTOP_NOTIFY -DWITH_DBUS_NOTIFICATIONS
+      Other-Modules: Utility.DBus
+
+  if flag(Pairing)
+    Build-Depends: network-multicast, network-info
+    CPP-Options: -DWITH_PAIRING
+
+  if flag(TorrentParser)
+    Build-Depends: torrent (>= 10000.0.0)
+    CPP-Options: -DWITH_TORRENTPARSER
+
+  if flag(MagicMime)
+    Build-Depends: magic
+    CPP-Options: -DWITH_MAGICMIME
+
+  if flag(Benchmark)
+    Build-Depends: criterion
+    CPP-Options: -DWITH_BENCHMARK
+  
+  if flag(DebugLocks)
+    CPP-Options: -DDEBUGLOCKS
+
+  Other-Modules:
+    Annex
+    Annex.Action
+    Annex.AdjustedBranch
+    Annex.AdjustedBranch.Merge
+    Annex.AdjustedBranch.Name
+    Annex.AutoMerge
+    Annex.BloomFilter
+    Annex.Branch
+    Annex.Branch.Transitions
+    Annex.BranchState
+    Annex.CatFile
+    Annex.ChangedRefs
+    Annex.CheckAttr
+    Annex.CheckIgnore
+    Annex.Common
+    Annex.Concurrent
+    Annex.Concurrent.Utility
+    Annex.Content
+    Annex.Content.Presence
+    Annex.Content.Presence.LowLevel
+    Annex.Content.LowLevel
+    Annex.Content.PointerFile
+    Annex.CopyFile
+    Annex.CurrentBranch
+    Annex.Debug
+    Annex.Debug.Utility
+    Annex.Difference
+    Annex.DirHashes
+    Annex.Drop
+    Annex.Environment
+    Annex.Export
+    Annex.ExternalAddonProcess
+    Annex.FileMatcher
+    Annex.Fixup
+    Annex.GitOverlay
+    Annex.HashObject
+    Annex.Hook
+    Annex.Import
+    Annex.Ingest
+    Annex.Init
+    Annex.InodeSentinal
+    Annex.Journal
+    Annex.Link
+    Annex.Locations
+    Annex.LockFile
+    Annex.LockPool
+    Annex.Magic
+    Annex.MetaData
+    Annex.MetaData.StandardFields
+    Annex.Multicast
+    Annex.Notification
+    Annex.NumCopies
+    Annex.Path
+    Annex.Perms
+    Annex.PidLock
+    Annex.Queue
+    Annex.ReplaceFile
+    Annex.RemoteTrackingBranch
+    Annex.SpecialRemote
+    Annex.SpecialRemote.Config
+    Annex.Ssh
+    Annex.StallDetection
+    Annex.TaggedPush
+    Annex.Tmp
+    Annex.Transfer
+    Annex.TransferrerPool
+    Annex.UntrustedFilePath
+    Annex.UpdateInstead
+    Annex.UUID
+    Annex.Url
+    Annex.VariantFile
+    Annex.VectorClock
+    Annex.VectorClock.Utility
+    Annex.Verify
+    Annex.Version
+    Annex.View
+    Annex.View.ViewedFile
+    Annex.Wanted
+    Annex.WorkerPool
+    Annex.WorkTree
+    Annex.YoutubeDl
+    Assistant.Install.AutoStart
+    Assistant.Install.Menu
+    Author
+    Backend
+    Backend.External
+    Backend.Hash
+    Backend.URL
+    Backend.Utilities
+    Backend.Variety
+    Backend.VURL
+    Backend.VURL.Utilities
+    Backend.WORM
+    Benchmark
+    Build.BundledPrograms
+    Build.Configure
+    Build.DesktopFile
+    Build.Mans
+    Build.TestConfig
+    Build.Version
+    BuildInfo
+    BuildFlags
+    CmdLine
+    CmdLine.Action
+    CmdLine.Batch
+    CmdLine.GitAnnex
+    CmdLine.GitAnnex.Options
+    CmdLine.GitAnnexShell
+    CmdLine.GitAnnexShell.Checks
+    CmdLine.GitAnnexShell.Fields
+    CmdLine.AnnexSetter
+    CmdLine.Option
+    CmdLine.GitRemoteTorAnnex
+    CmdLine.Seek
+    CmdLine.Usage
+    Command
+    Command.Add
+    Command.AddUnused
+    Command.AddUrl
+    Command.Adjust
+    Command.Assist
+    Command.Benchmark
+    Command.CalcKey
+    Command.CheckPresentKey
+    Command.Config
+    Command.ConfigList
+    Command.ConfigRemote
+    Command.ContentLocation
+    Command.Copy
+    Command.Dead
+    Command.Describe
+    Command.DiffDriver
+    Command.Direct
+    Command.Drop
+    Command.DropKey
+    Command.DropUnused
+    Command.EnableRemote
+    Command.EnableTor
+    Command.ExamineKey
+    Command.Expire
+    Command.Export
+    Command.FilterBranch
+    Command.FilterProcess
+    Command.Find
+    Command.FindKeys
+    Command.FindRef
+    Command.Fix
+    Command.Forget
+    Command.FromKey
+    Command.Fsck
+    Command.FuzzTest
+    Command.GCryptSetup
+    Command.Get
+    Command.Group
+    Command.GroupWanted
+    Command.Help
+    Command.Import
+    Command.ImportFeed
+    Command.InAnnex
+    Command.Indirect
+    Command.Info
+    Command.Init
+    Command.InitRemote
+    Command.Inprogress
+    Command.List
+    Command.Lock
+    Command.Log
+    Command.LookupKey
+    Command.Map
+    Command.MatchExpression
+    Command.Merge
+    Command.MetaData
+    Command.Migrate
+    Command.Mirror
+    Command.Move
+    Command.Multicast
+    Command.NotifyChanges
+    Command.NumCopies
+    Command.MinCopies
+    Command.OldKeys
+    Command.P2P
+    Command.P2PStdIO
+    Command.PostReceive
+    Command.PreCommit
+    Command.Proxy
+    Command.Pull
+    Command.Push
+    Command.ReKey
+    Command.ReadPresentKey
+    Command.RecvKey
+    Command.RegisterUrl
+    Command.ReregisterUrl
+    Command.Reinit
+    Command.Reinject
+    Command.RemoteDaemon
+    Command.RenameRemote
+    Command.Repair
+    Command.Required
+    Command.ResolveMerge
+    Command.Restage
+    Command.RmUrl
+    Command.Satisfy
+    Command.Schedule
+    Command.Semitrust
+    Command.SendKey
+    Command.SetKey
+    Command.SetPresentKey
+    Command.Smudge
+    Command.Status
+    Command.Sync
+    Command.Test
+    Command.TestRemote
+    Command.Transferrer
+    Command.TransferKey
+    Command.TransferKeys
+    Command.Trust
+    Command.Unannex
+    Command.Undo
+    Command.Ungroup
+    Command.Uninit
+    Command.Unlock
+    Command.UnregisterUrl
+    Command.Untrust
+    Command.Unused
+    Command.Upgrade
+    Command.VAdd
+    Command.VCycle
+    Command.VFilter
+    Command.VPop
+    Command.Version
+    Command.Vicfg
+    Command.View
+    Command.Wanted
+    Command.Whereis
+    Command.WhereUsed
+    Common
+    Config
+    Config.Cost
+    Config.Files
+    Config.Files.AutoStart
+    Config.DynamicConfig
+    Config.GitConfig
+    Config.Smudge
+    Creds
+    Crypto
+    Database.Benchmark
+    Database.ContentIdentifier
+    Database.Export
+    Database.Fsck
+    Database.Handle
+    Database.ImportFeed
+    Database.Init
+    Database.Keys
+    Database.Keys.Handle
+    Database.Keys.Tables
+    Database.Keys.SQL
+    Database.Queue
+    Database.RawFilePath
+    Database.Types
+    Database.Utility
+    Git
+    Git.AutoCorrect
+    Git.Branch
+    Git.BuildVersion
+    Git.CatFile
+    Git.CheckAttr
+    Git.CheckIgnore
+    Git.Command
+    Git.Command.Batch
+    Git.Config
+    Git.ConfigTypes
+    Git.Construct
+    Git.Credential
+    Git.CurrentRepo
+    Git.DiffTree
+    Git.DiffTreeItem
+    Git.Env
+    Git.FileMode
+    Git.FilePath
+    Git.FilterProcess
+    Git.Fsck
+    Git.GCrypt
+    Git.HashObject
+    Git.History
+    Git.Hook
+    Git.Index
+    Git.LockFile
+    Git.Log
+    Git.LsFiles
+    Git.LsTree
+    Git.Merge
+    Git.Objects
+    Git.PktLine
+    Git.Queue
+    Git.Quote
+    Git.Ref
+    Git.RefLog
+    Git.Remote
+    Git.Remote.Remove
+    Git.Repair
+    Git.Sha
+    Git.Ssh
+    Git.Status
+    Git.Tree
+    Git.Types
+    Git.UnionMerge
+    Git.UpdateIndex
+    Git.Url
+    Git.Version
+    Key
+    Limit
+    Limit.Wanted
+    Logs
+    Logs.Activity
+    Logs.AdjustedBranchUpdate
+    Logs.Chunk
+    Logs.Chunk.Pure
+    Logs.Config
+    Logs.ContentIdentifier
+    Logs.ContentIdentifier.Pure
+    Logs.Difference
+    Logs.Difference.Pure
+    Logs.EquivilantKeys
+    Logs.Export
+    Logs.Export.Pure
+    Logs.File
+    Logs.FsckResults
+    Logs.Group
+    Logs.Import
+    Logs.Line
+    Logs.Location
+    Logs.MapLog
+    Logs.MetaData
+    Logs.MetaData.Pure
+    Logs.Migrate
+    Logs.Multicast
+    Logs.NumCopies
+    Logs.PreferredContent
+    Logs.PreferredContent.Raw
+    Logs.Presence
+    Logs.Presence.Pure
+    Logs.Remote
+    Logs.Remote.Pure
+    Logs.RemoteState
+    Logs.Restage
+    Logs.Schedule
+    Logs.SingleValue
+    Logs.SingleValue.Pure
+    Logs.Smudge
+    Logs.Transfer
+    Logs.Transitions
+    Logs.Trust
+    Logs.Trust.Basic
+    Logs.Trust.Pure
+    Logs.UUID
+    Logs.UUIDBased
+    Logs.Unused
+    Logs.Upgrade
+    Logs.View
+    Logs.Web
+    Messages
+    Messages.Concurrent
+    Messages.Internal
+    Messages.JSON
+    Messages.Progress
+    Messages.Serialized
+    P2P.Address
+    P2P.Annex
+    P2P.Auth
+    P2P.IO
+    P2P.Protocol
+    Remote
+    Remote.Adb
+    Remote.BitTorrent
+    Remote.Borg
+    Remote.Bup
+    Remote.Ddar
+    Remote.Directory
+    Remote.Directory.LegacyChunked
+    Remote.External
+    Remote.External.AsyncExtension
+    Remote.External.Types
+    Remote.GCrypt
+    Remote.Git
+    Remote.GitLFS
+    Remote.Glacier
+    Remote.Helper.AWS
+    Remote.Helper.Chunked
+    Remote.Helper.Chunked.Legacy
+    Remote.Helper.Encryptable
+    Remote.Helper.ExportImport
+    Remote.Helper.Git
+    Remote.Helper.Hooks
+    Remote.Helper.Http
+    Remote.Helper.Messages
+    Remote.Helper.P2P
+    Remote.Helper.Path
+    Remote.Helper.ReadOnly
+    Remote.Helper.ThirdPartyPopulated
+    Remote.Helper.Special
+    Remote.Helper.Ssh
+    Remote.HttpAlso
+    Remote.Hook
+    Remote.List
+    Remote.List.Util
+    Remote.P2P
+    Remote.Rclone
+    Remote.Rsync
+    Remote.Rsync.RsyncUrl
+    Remote.S3
+    Remote.Tahoe
+    Remote.Web
+    Remote.WebDAV
+    Remote.WebDAV.DavLocation
+    RemoteDaemon.Common
+    RemoteDaemon.Core
+    RemoteDaemon.Transport
+    RemoteDaemon.Transport.GCrypt
+    RemoteDaemon.Transport.Tor
+    RemoteDaemon.Transport.Ssh
+    RemoteDaemon.Transport.Ssh.Types
+    RemoteDaemon.Types
+    Test
+    Test.Framework
+    Types
+    Types.ActionItem
+    Types.AdjustedBranch
+    Types.Availability
+    Types.Backend
+    Types.Benchmark
+    Types.BranchState
+    Types.CatFileHandles
+    Types.CleanupActions
+    Types.Command
+    Types.Concurrency
+    Types.Creds
+    Types.Crypto
+    Types.DeferredParse
+    Types.DesktopNotify
+    Types.Difference
+    Types.Direction
+    Types.Distribution
+    Types.Export
+    Types.FileMatcher
+    Types.GitConfig
+    Types.Group
+    Types.Import
+    Types.IndexFiles
+    Types.Key
+    Types.KeySource
+    Types.Link
+    Types.LockCache
+    Types.Messages
+    Types.MetaData
+    Types.Mime
+    Types.NumCopies
+    Types.ProposedAccepted
+    Types.RefSpec
+    Types.Remote
+    Types.RemoteConfig
+    Types.RemoteState
+    Types.RepoVersion
+    Types.ScheduledActivity
+    Types.StandardGroups
+    Types.StallDetection
+    Types.StoreRetrieve
+    Types.Test
+    Types.Transfer
+    Types.Transferrer
+    Types.TransferrerPool
+    Types.Transitions
+    Types.TrustLevel
+    Types.UUID
+    Types.Upgrade
+    Types.UrlContents
+    Types.VectorClock
+    Types.View
+    Types.WorkerPool
+    Upgrade
+    Upgrade.V0
+    Upgrade.V1
+    Upgrade.V2
+    Upgrade.V3
+    Upgrade.V4
+    Upgrade.V5
+    Upgrade.V5.Direct
+    Upgrade.V6
+    Upgrade.V7
+    Upgrade.V8
+    Upgrade.V9
+    Utility.Aeson
+    Utility.Android
+    Utility.Applicative
+    Utility.Attoparsec
+    Utility.AuthToken
+    Utility.Base64
+    Utility.Batch
+    Utility.Bloom
+    Utility.CoProcess
+    Utility.CopyFile
+    Utility.Daemon
+    Utility.Data
+    Utility.DataUnits
+    Utility.Debug
+    Utility.DebugLocks
+    Utility.DirWatcher
+    Utility.DirWatcher.Types
+    Utility.Directory
+    Utility.Directory.Create
+    Utility.Directory.Stream
+    Utility.DiskFree
+    Utility.Dot
+    Utility.DottedVersion
+    Utility.Env
+    Utility.Env.Basic
+    Utility.Env.Set
+    Utility.Exception
+    Utility.FileMode
+    Utility.FileSize
+    Utility.FileSystemEncoding
+    Utility.Format
+    Utility.FreeDesktop
+    Utility.Glob
+    Utility.Gpg
+    Utility.Hash
+    Utility.HtmlDetect
+    Utility.HumanNumber
+    Utility.HumanTime
+    Utility.InodeCache
+    Utility.IPAddress
+    Utility.LockFile
+    Utility.LockPool
+    Utility.LockPool.LockHandle
+    Utility.LockPool.STM
+    Utility.LogFile
+    Utility.Lsof
+    Utility.MagicWormhole
+    Utility.Matcher
+    Utility.MD5
+    Utility.Metered
+    Utility.Misc
+    Utility.Monad
+    Utility.MoveFile
+    Utility.Network
+    Utility.NotificationBroadcaster
+    Utility.OpenFd
+    Utility.OptParse
+    Utility.OSX
+    Utility.PID
+    Utility.PartialPrelude
+    Utility.Path
+    Utility.Path.AbsRel
+    Utility.Path.Max
+    Utility.Path.Tests
+    Utility.Path.Windows
+    Utility.Percentage
+    Utility.Process
+    Utility.Process.Shim
+    Utility.Process.Transcript
+    Utility.QuickCheck
+    Utility.RawFilePath
+    Utility.ResourcePool
+    Utility.Rsync
+    Utility.SafeCommand
+    Utility.SafeOutput
+    Utility.Scheduled
+    Utility.Scheduled.QuickCheck
+    Utility.Shell
+    Utility.ShellEscape
+    Utility.SimpleProtocol
+    Utility.Split
+    Utility.SshConfig
+    Utility.SshHost
+    Utility.StatelessOpenPGP
+    Utility.Su
+    Utility.SystemDirectory
+    Utility.Terminal
+    Utility.TimeStamp
+    Utility.TList
+    Utility.Tense
+    Utility.ThreadLock
+    Utility.ThreadScheduler
+    Utility.Tmp
+    Utility.Tmp.Dir
+    Utility.Tor
+    Utility.Touch
+    Utility.Tuple
+    Utility.Url
+    Utility.Url.Parse
+    Utility.UserInfo
+    Utility.Verifiable
+
+  if (os(windows))
+    Other-Modules:
+      Utility.LockFile.Windows
+      Utility.LockPool.Windows
+  else
+    Other-Modules:
+      Utility.LockFile.Posix
+      Utility.LockPool.Posix
+      Annex.LockPool.PosixOrPid
+      Utility.LockFile.LockStatus
+      Utility.LockFile.PidLock
+      Utility.LockPool.PidLock
+      Utility.LinuxMkLibs
diff --git a/git-annex.hs b/git-annex.hs
new file mode 100644
index 0000000000..89a9350b40
--- /dev/null
+++ b/git-annex.hs
@@ -0,0 +1,56 @@
+{- git-annex main program dispatch
+ -
+ - Copyright 2010-2016 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+{-# LANGUAGE CPP #-}
+
+import System.Environment (getArgs, getProgName)
+import System.FilePath
+import Network.Socket (withSocketsDo)
+
+import qualified CmdLine.GitAnnex
+import qualified CmdLine.GitAnnexShell
+import qualified CmdLine.GitRemoteTorAnnex
+import qualified Test
+import qualified Benchmark
+import Messages
+import Utility.FileSystemEncoding
+
+#ifdef mingw32_HOST_OS
+import Utility.UserInfo
+import Utility.Env.Set
+#endif
+
+main :: IO ()
+main = sanitizeTopLevelExceptionMessages $ withSocketsDo $ do
+	useFileSystemEncoding
+	ps <- getArgs
+#ifdef mingw32_HOST_OS
+	winEnv
+#endif
+	run ps =<< getProgName
+  where
+	run ps n = case takeFileName n of
+		"git-annex-shell" -> CmdLine.GitAnnexShell.run ps
+		"git-remote-tor-annex" -> CmdLine.GitRemoteTorAnnex.run ps
+		_  -> CmdLine.GitAnnex.run Test.optParser Test.runner Benchmark.mkGenerator ps
+
+#ifdef mingw32_HOST_OS
+{- On Windows, if HOME is not set, probe it and set it.
+ - This is a workaround for some Cygwin commands needing HOME to be set.
+ -
+ - If TZ is set, unset it.
+ - TZ being set can interfere with workarounds for Windows timezone
+ - horribleness, and prevents getCurrentTimeZone from seeing the system
+ - time zone.
+ -}
+winEnv :: IO ()
+winEnv = do
+	home <- myHomeDir
+	setEnv "HOME" home False
+	setEnv "CYGWIN" "nodosfilewarning" True
+	unsetEnv "TZ"
+#endif
diff --git a/git-union-merge.hs b/git-union-merge.hs
new file mode 100644
index 0000000000..c499c530df
--- /dev/null
+++ b/git-union-merge.hs
@@ -0,0 +1,50 @@
+{- git-union-merge program
+ -
+ - Copyright 2011 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+import System.Environment
+
+import Common
+import qualified Git.UnionMerge
+import qualified Git.Config
+import qualified Git.CurrentRepo
+import qualified Git.Branch
+import qualified Git.Index
+import qualified Git
+import Utility.FileSystemEncoding
+
+header :: String
+header = "Usage: git-union-merge ref ref newref"
+
+usage :: IO a
+usage = error $ "bad parameters\n\n" ++ header
+
+tmpIndex :: Git.Repo -> FilePath
+tmpIndex g = Git.localGitDir g </> "index.git-union-merge"
+
+setup :: Git.Repo -> IO ()
+setup = cleanup -- idempotency
+
+cleanup :: Git.Repo -> IO ()
+cleanup g = nukeFile $ tmpIndex g
+
+parseArgs :: IO [String]
+parseArgs = do
+	args <- getArgs
+	if length args /= 3
+		then usage
+		else return args
+
+main :: IO ()
+main = do
+	useFileSystemEncoding
+	[aref, bref, newref] <- map Git.Ref <$> parseArgs
+	g <- Git.Config.read =<< Git.CurrentRepo.get
+	_ <- Git.Index.override (tmpIndex g) g
+	setup g
+	Git.UnionMerge.merge aref bref g
+	_ <- Git.Branch.commit Git.Branch.ManualCommit False "union merge" newref [aref, bref] g
+	cleanup g
diff --git a/stack-lts-18.13.yaml b/stack-lts-18.13.yaml
new file mode 100644
index 0000000000..5ee274f930
--- /dev/null
+++ b/stack-lts-18.13.yaml
@@ -0,0 +1,28 @@
+flags:
+  git-annex:
+    production: true
+    parallelbuild: true
+    assistant: true
+    pairing: true
+    torrentparser: true
+    magicmime: false
+    dbus: false
+    debuglocks: false
+    benchmark: true
+    crypton: false
+packages:
+- '.'
+resolver: lts-18.13
+extra-deps:
+- IfElse-0.85
+- aws-0.22
+- bloomfilter-2.0.1.0
+- git-lfs-1.2.0
+- http-client-restricted-0.0.4
+- network-multicast-0.3.2
+- sandi-0.5
+- torrent-10000.1.1
+- base16-bytestring-0.1.1.7
+- base64-bytestring-1.0.0.3
+- bencode-0.6.1.1
+- http-client-0.7.9
diff --git a/stack.yaml b/stack.yaml
new file mode 100644
index 0000000000..077028faa5
--- /dev/null
+++ b/stack.yaml
@@ -0,0 +1,17 @@
+flags:
+  git-annex:
+    production: true
+    parallelbuild: true
+    assistant: true
+    pairing: true
+    torrentparser: true
+    magicmime: false
+    dbus: false
+    debuglocks: false
+    benchmark: true
+    crypton: true
+packages:
+- '.'
+resolver: lts-22.9
+extra-deps:
+allow-newer: true
diff --git a/standalone/licences.gz b/standalone/licences.gz
new file mode 100644
index 0000000000000000000000000000000000000000..27c06f9f19e717b04ac8490a3194eb02e6002296
GIT binary patch
literal 58148
zcmV(-K-|9{iwFpmiQiiS18iwyWo~0-a{#<s+jiSHvVCrS1(shrIYTM7bLk{AYu53t
z9VfozMDAo}-XIc^5Rrr$04*zjbbeqy;LMMmT?LS$C`EC1dUe)HVv9tfP?uf10O)qA
zotS9fmu0E$h4Zq^WNu0&<a{nhRhi|=31`NBA*~V%?We*|l^B~mHw#@(L~7<st0z<M
zdKfEmovP9)_qx~nua)4};-r2}yftbm-YDk;y`P%WTRp10v92e?dt<#erK{y+0xBpg
zluW0>jCt<!_m};re@Vnq`~kyA((&-L|FoaxvT~|XBN0})xk|mhQ~44q-C_wI0*{UH
z&RaQes}>(7;-XB2fZWR<=C!!RyrX(Z|LWqlo?!r)Z-1?nU9Jhj>!;?k5kDK~FKJ1e
z@<@uYyqv?fI9RPM>r$7M6Sv0R$vg{2Gcbd7Eb*ZRJ50nS|35hROZ{Ua&Q34;2ZMbw
zA%B8LWX8j2M%WnAo!4pq07e;}BxE<|6OrYGL<FP>>vMKLmmV^{YIW<DW!hfUQJGn_
z5Vuxm6P4$Q_#~GIx>I?lohg&<DjU18%gILbNn6~{Rw*&8qjY8TEuIWP6C(L$uFB!?
zQmFe>&FOtePK{NS*SY&H`4Dt3?d0J?wu(qAo3|yL%2KOb481Bx%1(sxLguTHweQL2
zG_-aZC&o$i=!fA^_~=>vQOqAQ#@U_DRGF^w2TJ66G*7K+>+wqo$6BZTl0xi679;j!
zBF>GO<f^-#wgN#Q+}Bsu8rzmSIoQW<8RE4Vz1hC1CWM0+t7MkzQvH4_$Mu={TFQOE
zq;I5OiRlcb?EOdo1ZhXvR~5Cn;^NB6=fBVMo%M~r9Ihc}m1|jwp@NvKYv5;V26is*
z;!z#!@2&Za)a<UOe!R96ot14dLtOyK-WsRI4r%%u@w!GB3btmUok;W2m4AfgCaGPn
z`}C8tB@}ySpx6ps9u#J}^!e`&vBN0jOIyN~^q6NMJ`BV;gq6FqrE;V70y?Fl>cpAN
z#wzz+7}zj|Mv=Yy4y!_nL3B7bZ3{Vg_3F8}mA(@HB*IW`wQ7j1IJ%Q2PP+V$@b!I>
zA8tX(k4ooxCs9b5IHIM@X0RN8Hns!|C{PJnRtI>$=Ho(6^jev_K)U`sz;Fw$l!%k5
zMKv`}{L56iM42Rgu9b(&yXzfvL*j5PBxJf~x<@CE#o_+`L8z<JA*w2<iX>Eao8_Vq
z@9p<XQB?f9Vwe$#LLznWw-XW|K6RF+-%%j@RKxp_(Qnsph@GkBMg_;Zp7#&;51u78
zx_`}y`Ikbz7VoPO0z_nn*03dn=&kj5b_%7ay8rgj_~QC#ugkINq}NMQ_~paRLh?%#
zexPY1ym!0C)~C|Vz_++~N~`fA$<$?<R~gKrOUA!dLjdfPptelrr)jsOw0OXYsjRON
zf1MwkBh)8m(bY753|9n|PE0Y^IS}}=ZI|&_cdYUPR@r|kYBvT7wjFzXFgRqi`SsN0
zW-?LRLjM`benALZg3BoTWgVKEFv+w<2{m?^h`BW>nwdnHJnMrI%N#t&LLXDKCV-UD
z^6Rz<MKP4u_iE|6$^zndRM>}@u%>qNugD;M>ank0!lLwI+f-vnLn5!?{xxt_Txkzf
zz_2E-HcMDq;}!LI0R=i4`7HTU!l?4&mwj|@NPvz4KZ$d6yJ&$CLkWLC0q_cy6$yN$
zEb!iu5&6Rld53mw2sqagtDor|OD=rABUx6f*{t0iL8GNto2s88Kv0YT2o19Bze>bu
zRi>yoFrxR49#F0vpmoCp)LLcY1EI%~9zCTo&yyH*S4zWVczK^k>`=(-VvTP<N*{|O
zH_g%1|5L&PYMIoT1h9pmKiuP_K?^(qhElC}m!uOpGXc?>aQ6&kC}G1L>l(f}dM*C%
ze`(yyB!<QIO57Us87z3)#371Su{B_uybK@HOP8uF$$3ZBq;j6fbPTf>{J7=cT|s6_
zne}-G#UR|sd*T>n`wlU1sz1*XD&*8czmrZGyKD7L1?{Bh!BcUTQM)1D70P>B#=&8$
z&090h(VVCPn87~92{6!&jV(6Q{(u!*igQh!e^@s@yRmA5b)Q?ARnn7q=e4i!6JlYQ
zYHmyk&TdsYEe${%p|+7f55$Cv@mcOvM=?15ts0NT8?~juI&9^Dy7%3o!MC@jz^ryo
zn@IElXOlR#OSt6b$6=M{8s4cF9S5zYZ5UUlrL;L!2d;P@KqyK?j+>@aUAmcGhM0lZ
zxg`*{AY)`vp7ToT{DUlKNrP=nClDc@|MPE<+c*FD_tZjQxnrIGQ|WYeGF9oUz1nvM
zWFKS{RZn3lTrA&IlPT@{d=t)cV+vFizg~WW?E{DfB|8?|6}lPNN~US+GTm?}%y6#@
z&3*H+0q>fOteL4@I3UMrs0uls8rt+=L?8%d?k?U{vs^87`elcNs?yn(=r|x=?G5Un
zxRksHxz$)L^Jh6$)sgg~|LTG0P?h@r^`BW~F(1IF;BFuQDF8ThQpZ%l)J}C}cZ)D!
z>A_*LmJ2&1IA3hR;%6LJ&v)7YLbqCB7xYuv>1S#ztGweQgzsfF0}dkvcd;UXavyn&
zhnhA@J3<cDpnQj%srPd#0$HUu6}i&sR8r?!nq{#wjaZCd&XwCx<cPXfkcVTdw4Yg3
zeW@|#!O~0R7sk$BN2tfYhrc5#zl|?(o_=NZmRLAs1pMt2uhW=Tktbno?A@W+CtW^0
z?COMehPlF1R7A`KmTbYob@uIrvN$xpD6?)`){t_L>Oj(^O_#gUMuFwtZIclb?~Ow4
zZq(Q?ti{7T^j~hUhfuUoL+1HX&SdgXRA!<_66+b_nE=p}nv!lO(<P}ivOfhR`7I0E
z&}!$zjksT_8m8T9_<b_1vQ^nJ+B0#JQw%~DAWyj+zB6+_m+1HVaz2M>xdlfK#d`^^
zBu?bqYUBM*NTPi(17RD<b34WA9GJ>+rJ1dYpTX}^?NTF-5xL^x3(TWzX2b{lCwEK&
zmZ$FfJ{!xgGUsNeY(Awe+XvL#AhfPN8-4u?(GTt3H|3J6+QM2M3)Y!R+6JwAt9|iN
zgLaf2m9hM_QoD4V4xg?HBd5VRW@57G-B_zU+f^PH+tPeLiR>g4%1xl&A@TI+<3^}}
z)@iKeD3gWTdLk8yO%5*ZUx%>YQ3JxUAO`8ucs*X$tAEwBKkrOlm`v}iOJk?*Fdde^
zVg#3{b&5F9MD4CS0VeC|ul0;#_1GHP#SK{WS0WZO6j|?!z}gQEca{B7<z6?`{xGoL
zD>O2Crpv7+W1^tS3}Cm#g9mX_@=DL9VC>?fvF6LvJ9D=~iKTJ|HG==^qiT4a*1u85
zRsWnCt9~mZXwlDw)Cv6)s?2u@vh#%h?eoDH4<7~>n!Mt+bI0&eF2AV$sM2}X?HaiL
zN{4n!d<6JXC3vf<iT`H#oXR3sp6a8V(NVSRS_(n>@CAm1aA=6MDK}e?2g~uQnCEDH
z`*EALBZ`VTaq2&V&7-^PE~UnqE$!@P$GM9-(~e?)u2tIQn!m~DPNkJqg(@~U$HO6+
zcGu)6SKlF`W}F53090VdxELC~Lvd8uOfAK&T;F;+IqCmPSwoxZ8)wB0sr&}4+!y&)
zy1r|0IC#m*Ev1Bt?#0DhxUMvJ;lj#l|K%J094nPIl`ZVfKXCsHt&iKaw;XxwS0(gr
zN`m;zEW(AObU9h*a?4SESCjS*c>6}k2@6=e5K@4iE;cIVl`hXe4UC=80l@lsdRsOR
zZgGg~;l;4aPtXK#F?oj1SC^q^i)g46SKQZ6o{*&m4w;@RK>S1v5O+`NbnP9%TH&Ec
z=>~;%Lf#=ADYnJfnu3)%RU=~D=m(|%iA0S3e30>Hw2*}EZ#^+Ky#Gd~Gf7uErs0P{
zgd~1*bq}mDRE<A3!+-RMInjwQZDuW|nhxBp>MC>u#u`a|FnaxNTlXHn8ch(KJAm{j
zz23!GEKS9NtCFR9BV?L}du7X7ot9A&9#F_-IFEqGRyWZw7H*`=FG4~+rTALgK%8kh
zQxYH<h|9k<$71~;_P;+vz;sZ`Lj67I!E)&3GYA+S4bLDF5&1(iMem2_uYMA5jPc@T
zk>dwCk?Z~NZb|p+el`~6{Pw!{!_%LBdhxvX!!N_5UOc)3#-c9R!qJl2*DB=5+^sI^
zuqCX*DzYj?2%;OM{fl1bx{KKM=luE?aej7v_TlJKy#M9+^5R6`@7eY6Z2SB8^O0%{
zyp9(0@RfL5p)I52?}@>Bs~qU}PrJ`B2jXwh#bY<70DJOxNI63tTT;J=fIxvS=xSa@
zo+8(9+|Z^Ur;8GJcLae2J=EMXv6Xal<RvnbRs~`*5f~s)WXcI0h-y#rK@bJqXIrRj
z5Z18c&wHz6LBSbb<bp~TR3#dpygvSohUakRkV;tbT#cKaLLifStIL(m8KwYiXY6mP
zEN;-6sBt%jio!U*ZTQ?Gx>1YrFrGsrQ%+Axg%$%A^dLRxD3A(B3Cr4Lgb{}LP!z=$
zQXFYP3n7j}>R1%Hq!*xb=ep5KAR&U&CY40P=n(~-DSMl9!V}^y1Q=UEQgTkLEc$&&
zDoA-((Xq8h#M2?WV|gu8l66Rm_D-NqSknFzJU}{sJrwEUDDMXDSXN_q=tT>ur~E5v
z!(BM#V(tttjgg3bLN<i9xsp^MI5Nrpqb2JoD?c@?<v)Q@bQnOQ=oyP)lSLZ<Q@t^D
zOnjQEQY>H(P}mvi#NbscmC&OA3}a<!50+dJZJ$uo_aGK4!^Ah3V*8rc14yj7z)#U4
zL%kmA#9fG%Ry4H|H00%mhT>85J4#we2Z$(y4(PtnZu&TBCc!dNh03*7>fjHu*9458
za(NuISs>Q%duuGc)Qagw0gNZV2Rcgnk(3g&4y>6~UD=&fZRE{L5a?QPW=JT94~)FZ
zSS~9b>>#)>+>>Unlq#5VZn?XyFS~NR%T&1}U-3$U+%S@qMH!CIIA1GkRl_#ITLXp)
zOFSVKJ@QRYq{`AUJm1YlX6cd6wI`=UYj5>d+g1t9ugASmNYS^CDMDXw3WQ?u0`OWy
zP|EN!Yx|(?fkDWEnZPbBTty_Jb_Fp7<@r()e)XE|!YNNwG}ieFIXai9?Wj`T1oNm=
z&$&|z%R=4m)ylbzD9d6tvZPMLWB8KuFsa|}wF9xkJRs-@q0^}4rU)I5^B6Q--W@Bs
z?1jj}kGc+++FYjymE6oJPFRbGR{^fxUv7)F$kY~y6tCtW$>Pz$W5f_J(XX!VvyIjq
zO`-ni@G)!;;0VD+kW~{-G0}H*6y|CI$lwai{cl~OleQ}(wQPc>9RW0R)-3Huo;w2K
zkM)`upCegEyN!Mw=&0_|Eo<64sGVX}sOGfUK;>r1VZo}e!OkGeJVH2z`oOdHR?|B8
zdo`g|zgF6+Xm(zNM*222Y6PM$?F=7DC=*ZygpNHL6w{2~APoh%1eJ*x2ZqrVJho6K
z=st9*Oy#gLt{p)a3V#9#jVH~FwfTmoVB6_*3rZ7=gw@r=7$3r1o+=|&Z!0v1n~Uir
zJ&hn<O!11i$e~m<3FIIBc{K*rKw2ObBMv&l_(SC%MyKLRtP4{v>6#huscNF@O$#A4
zAw#e6G{P#nq*Y0_Aa{T{;g*Q(g0{eVw6TC(Dp!axq7*SH-HEI3wqc|UHYKL)1Cs*Z
zLO^E~3OC!HZ^}3A$ee(~DXd@-LX0^hvjFrSDRn^9fvn^1LdBZ6atRqFnz?m1IyN6u
zz-K^?NZ(Y9T|@a+Yl}H9;^LZkk`~J0vk@JEdmT+3c}KW~=z>1{^&UaD<|)LGKg7?1
zUfllF>C2PWLrK=SA}2R7(rc-Ym~dRp>UtJ1sDt}~gw;u}OHwisiYR`K>SR+tg>q0z
z@fU-5Jvo!4CK~7Tm?3fK@uMR!t@3Qe;OjSH5kh)Fn+Puyi3~3s7ULFSGz8pCe){vu
z&T07+t4K`iLdU@2V_Yl%nc*r<1SKTvozYncPn13QKx7oKHoRS{6!;<ANv@F#OjgnM
zKbIMVfdcHtZ_m&x;AqNAyBtJH5hw%sZG}<5^s0uaUNa+-G9pdo!o)4QP)}Z(vQOHy
z8;uzAu{OnTYGpcHBc#A2h)1rrP@aN^Q8Zvm8g`Mw-P4_2)$Q4btD!i$J{2c7*QXb^
z7dO|#`2PL?Rd1}zFmWwq@3vKp_5!<Qhu7Klv<c9!GWkYU)2;3W-d-q)B{sFOpKJIe
zmy3x0ftX{i^;WGHx}+om58_f4nos5Fo+upaW^MHqeGP+*-`1YGg=Svf)8MXQ<I<)^
z0@kZQpG<oK@tx3aW|^hCIaH0r9!m5c-r9=;l-mnV+FP-qJ>C@=sWljc(&)rxslUiI
z+amz?LK%mkpkT0A-I+6mB{G)DIp-w(GMB3@Y8um{d_oRLHzj|C0=xEg!WN@QqOCn0
zw1>jO9GF@|lrS*J)W;2*cz)+-GZt^KdYaN8&&eK9^;W&xYp#G0r_gn$#$=Lz+8c4l
zMsM<lSL?0XBu8Q|HIRqb=;OU;5T&Emv_;j-8~xszfhXwI94tO>o0||oPLR=?7SA|p
zxa$ZNm1_v?chYaBA}DCtalu&0C=<9gU1LT#^WGIjD{4tjr_^Dej`}fOj`{KqV`qrK
zc-Ty@tlWhRN#b@O{!?k?<Ms-nLa#wn(Xc>zOq5>VNnh``(dv1r6cq7Rx@(}Ow~jTB
zc)^etm%4^KXd7dcto9v48vu(i5CoEoFmyzs0Kl~OO6>-FjY{xc=w^^b3)=Z?d4#@D
zqq+$|=}T}B*+sJsh7HA=lu>$*^C5Oh><yx0vAGRh4{UM8T%&~1BopA^V9B+VDkbqS
zRGyV-<55K1o&^gIcQDE5V}6fFdED&^D}a5PATC#P-Kj7Me*lK3$nfCWOW?`TJQO5y
z+9gx}YeQ_s?e*$Di+M$e!_ZAfKguv`sp~QfNrk43V#FM=58hN8g8?*+7IiDl++ka!
znSB*|C2P=hEl>ph3Qb-#*6#Ko0_~$1zIB|m*AYk5-<XKI#aX>OQRA<xH<)4EAcQ5a
zkh{5>&&qNmh_a>CB08wqw_E}I#W-xXt-OKa>;j<>bVaZxSQH81<XHgkaGiHmkdTDP
z;VKDzbg(<zL%S_y{H6pox=L|-OrUA;)IvxdA_oIB9Ng8?*EHK~VXxKg?!{KT4OD?p
z&>j>JkdCO=YXNVng=}r-aA;UORj->7ov}put8^pg5~l7oVr3Vbhy0~>n~96sfGZI#
zqlPpMn63F4nqN&^E)r)Fkr5f8?e!(*LB^U13M787UqCNtvL$VlB(+)To*xs0W-1p*
zBA0_;D~5x#%4M_7M+Zm1)N)esDGcp{2WCebhlsp<85o@`3|?Hd&%Ag>-UvLkj5T)+
zxoJX-#cu)ag<2Ycdqq8B>NYhdsqw2R#rzsY7kVR;tC$Xt<m0dby#BqS5-tK@L{AY4
z(%Did1XuDiOmR{l9R<?ev|t2TD-I!jc)iztpOb&|7=_H<5zv-_rUl@QjDMwaY(L4O
z8#5CoAn<5gDs&9u|J(bw<u<Y`Z4kVcTR((1&DumpfryaekQt%qu!KlRLMBD3NGg>2
z%gQ>PfRpqT2xq|oF_72u0CUk#&^9-7-DdLu({D0nb1`o*>%7<Y14xR<s;nx?sxl-J
z*uH%q*Wp{=*IYt0agy8u8^k^=S69`zcI4LK3nzpxaV#)C1O{2HA6v45a3_{Cgq-(u
z*}`VQj}ibI9lq2uZb`cR2@74PcnM%$RQzKe9<XlVW;73<7vUJoGck+?)4(5wMhaXG
zs~x<&`6c;Wk5|WhiRTL~;ISeI#LZBTH6#%DgRrT>PUal}2g4$K5gT>!AzH0_<(xx|
z6YL`&LD4Bw#Ld$BlA%IOW-T1&yjAx378rfxxQHyHbM9++VLr!qsCU?$e;kE{OO0)X
z_vO`3!wN^~^@2kSQm!G+WH2*e5xgmH&?D~Qr8y~cUiG>KwcV#+{MWZHjcwh3U6du8
z@$w7U4n75&b5wys+b&DHWJklyRTx@W9XO(tJ*agWH)-O&9dA?aaK9GkZJW&`7zxhi
zFvpJ|pJ<3x<ruI232$GSQ~sqU4`lE;R-f1R8Yi13zWxytiK|(5g$c9iDuG|kFp^g-
z&un<qelUMRw+@Y}kGV;t5KL9Qb}_>PoAe4T7KDP)CB2-fdrY1*uZVMuUYvmqm*+E$
z`}khC1Ro*>qcL{drEPpU-Qbs#c?}v##>z<y;UV~uHw8u@ONy+~YqDS0e17!2L>_o+
zhvMB^KM^?=goiT*>7!SC-bY|OoLcY9uQA^gVGt7czMyR5q{Z^0g{r?+`wzn$bR{)n
z;_o!)Kw)XLAmMF3m+bzi8OTcw15%U32TJhsSNTFCqS^xtT!UqSW^V>I21ZyYX1|<G
zi>rbfiR0;d>@@vIae2Z00Uv<p2tGWcI~BVU+*0y`<=<3`>N-T1Wx?~wP4zIupW{(n
z@tH+8BL(FM6U5ehXubZ5aI??K8*sWWa(=nQa#-i!_7|LWLpzlb7O-tTXH&k&t1zx-
ztJuZVnf@qHjw_1O<M4<-!H#m&HJ91}cbSr&Y@nNy?57Ow$SImsnaqji>ZzYM7!s45
zGlei<{ZRJwV}O>R<zIVzY3V&#ZdHkkhYxBBre0>Bc{9SXP7Yyg2ZLiWT~-_q#5SO3
zbml8)g>#;GCc??7S-5kK@z27+Eg>qmYBf0u*Efc@p@qcuLsj=h@P*B9q{t4QYV(3k
zI=KdTm=kp}>14Ahq*cN})MaI19N*2_)Ft}5oH?WXLNpq%KWLiH^2=;`-jn@KKjP>H
zg17?HR5|U@#-`Wf*sKe^U-1UgzyXKjI0Y$5czct45?&rwkfum5XO~ZT)-H={o)h?{
zuG>8uJ_)55Kww<V$IC0OVyj}z3$7Nl_wgHvj8Ryxbm|D+CrwYt%EX!?^Z_Dd%L|P0
z(53V28xA#BXlcOEW9qxY__Fl!+ddvInvHqS*%)^Ak9iZnA_y1UYrA{YZwyFd%LieL
z9+vU(12-?Mm@~ZB!BU=>oq%?hhPz>6q_h(+9duYTO1g%@a<L~k4iFx7jzC9TM)2Yn
zvR~x$=v1NY_UxHnRv$+1j@*f|z;pvNIstE)f_&-oZ_<4jj;k~HK9UXKHiKITt5v``
zqcE_p7+t%PWT5C}G#HYGve&30)CTW6Ixga)loQxD8IA|OvLskx3dt{l4RKcBHB*09
zG<NpPT2O|}lIW}CQt}M&feTjed|c21k|Vq25~YQ0N&YfvY+b%EC8Ix{VwMkIhA=@3
zxz^~mQ}=_6p<435du-%nvQ>{rxEUV3<dVXPkJfu+A(KJV<2}n6;Q2&@Zck-I<>hQh
z8zY)@45?1zcYU{?e^mt99>?!$7nRI(4X36rD3|%uDzb$53Q8<8h<FwZo5L`|1}c_U
z?ML~nx-P~`P9$?yI|R)zpM)nwb%~3e;DiFFTN_$?k))sU{2FHuW9=Cyuqo?I<p*j<
z#&#AOOtV!&Q5v;pK3hs@B7uQyJTB*I(aQn#yO3t#bv0Sn1p`D@R3c7i%F1GVFQ_9I
zw42ZybSRMakXxFO0bmL0T14JvltD}QD8f+TI-8a9cf7U2==#Y)yCbo^fekUnqFP=P
z`vzX58l4Q_hX8NUZhY?--&?f`#k&5rh7+i*LZ5hO*tue&)B|zBqc0W#Qf%Ln2#*Hg
z{4zE)bP~)8o#^k{mawGZa>*W@3rr?ldOuk<G20>Ymt&1+A&g<{RxZHVx=anfRG_Ji
ze+mg839cn0sNQD;k%7;ahwSCq7d?*v1KfZ?0NWfB-Y}5^LA!)MTd6gJe}1P1w|JZs
zsFHW81nm@lfi9MgIL#&g+3MI&Tj6!bI{^ZvhA>?wa750{)ppT8pQ6M+`f8lr#3&|w
z5Y0{Y^kKV{mDJ6IB!#?M+ybFy7K*Rn^P%UrYRx*ZqeK?UgoiW}G<8qU7V5aaXvEVK
z^eDNyJ)OIYY>tGew1fr3wc>mLqvR)bHwcd%G{U%n*s1das*bP&jAknV9)w_!tkoHK
zN(HV<0fK~91w%);lPZV4^O3KJHWye+)5#7(N$la5S+ynsgwzgroUs+o2^nstGavK<
zM@ZsX(Jfbhl)jZk#|2?QwyQj=`!PN7F7Xe&h=n@Hk0Ps{VM&$|;9#X$7_s%mi;3qz
zhfp$wll&UN6BuO`Pb!XlF~bwM05i^Dk;xT-sv-l4Z-KZ8=-L@27&MuyVI;Ovt}x?+
z*N){0dgO+pAC39+&*gM^#Wx_FK;;~kB>pZ+o2u#H(&BKYY-JZ0xV|yTTxe&*Fwp=k
zDwkRhCW7=mu@Eksb#x^&?hLvRnOtS#0Z%K9L7nArOyICc$Sq(J#G7Wn2=ihyas%5Y
zk>LgKfBI4(o;uDLHt9Ag9!}oea5>swTxd(WjDGO<?;%(?a`nD~S?a!b<A6*{*gBLB
z(J_^{%d&#A8|UHs&O6iR9j`KEiOF{n?L`M-YZ$KfxVkAMt812rTNuuz`2O9qht^{I
zWJ-W11(y<8dX#y*TvcRC3!sf#*$$y{_mP%WyVE0c@#-4+7$uA)=SO>#vG|QGoGhIz
z=Nz)r=D9_==ipc?uNeG5tC&K?0Rahv!wAI468MjO^GwdXIR*)4Y(@4`x*FJ8gex0N
zjRk?~@^qDFbB-aqkH{VC0$ys3Uh}OsXV5v1kF!!akj3GX@HSw7VCD%EE8@KBjW5@{
zm?nO-B;!i3WSI=J$=Ah>*&6VZ6xM=tN{p}0uxGD*WyrhGu-|=U^fZ-A_P^fvS0y7E
zBua&>n&nK8Gn}~Br=n-(6D?~0gn*lw)wH}2ogHAk;%2Pf3uv=v3KHQoDXo%ODZWf(
z_sQaR$8YSi`Z*L}ikrBWwdsrOx~4X={4!*Tnh~c3B~&?z#j)ygJkBaI=h(?b9}^QR
z7`b3<DS5v5M`PO_+TZ>LeAn7mGT&5QhCgzqhUE`ukuBA67@UcJM?0LSOD2NTMw~LB
zMLWf$*LJ<4fv09i=uc=ML$KVffc29v?ipuOvX#Pz!VmfBv>LdX^W~i5lDstdE;HLo
zoQtTW;!dlu=3Bd=VrVmE%Be5vrf8$_8Cx}$a<6k$$yQ{HBX9Wv2a@7pybZQF2*qav
z9fLUbA#AkT;YR30kwdWZ6CoHi7k_uRG<*8Yg)1+GB@7`#jR@-B7G{6A7p*dCmVxJJ
z1Qwjw>>lDiQlolDg-j`V&r3LUs`cOR$xguzYfzQ#Iyf^8nB`nrmsO@a#jcZ(XRmNg
zb8@_jJku)dp}cbsEh!dxo#*r2MY)UrWn`Pd8g-z#A?!Y~>CP=(nG-OEhp;7iU&~;o
zR9Hc)HHtsNx6g7uh|lRdk?E5Bx&l1h9+D7|xbN=hm;`5peGIyPn5DJlfJH|GvnI6?
zZ_0zvYg;^~eb3=$i7*3jKH6433)%NcoZ)F4k}<9d^8)D8;Z?gu{c%@0VI-^N6?-c5
z5p|agzLlg4tiq*thZ!R09KF08_M3<PAZW;6zxrXga<ePAn0r)wby>m(z?q+DVyz1I
zq$ay9RZo}rbRxwcaLB{pXA%vc5j=l_m`}t<qN4#{MEkgy$zEiLsM#5XU>l?NMYw9Y
zJX@SEr-T8kLIwn;sGNT0;XWr;S(tM&QnCxJP4b{HtN#cW7y-~6Yz)1pUb+<xR)j5w
z!CqaHby+e{5LTLjqF~LAr&(3G!kAty+@TrnWvKqBJwE04pbe8z2}*zt)jpaahGeN7
z<%!CF!(0O0e6+T&IUxakr)nH2Sir6!UMd)#t%G0dyiS>GgrX3xXoeulVn5*BKUty;
z&clTPY<mKCcsZlC$z;HvQ0+aTGC37ORtGLN3ZimsE*GGtji0=ZmIaI$gQV;mc!JU2
z73<_ToC85#!Ml|c3{nvn^#oHCJt-d(^nUs&U-2mOiCBcj^)#Ni>M)K>F#0KPFA;0H
zvb2h#F5;<#0OfiETxDBzTY!1gL5w*e5(d$jdHo)eZ0MqxE%9_%&gg^{b2-GZam$}E
zO^2SISmawWI#ViY_*~#X6u%myj41nhmQ&=QmY~8#bcT4Ht1KX5g_}a1{#oM?^}%1g
z6U1x8M@r7oV~ozFOqqR2Kgt2><U9qgctiKjvaEb%X8JI<HwEr;?qji`NQ#YxXkHPV
zBgk@h4Voz^n6c}8u_PKIv1AkR#tCY(-5N`c`&iNa3I77?`ELTX&Xe{lj^8~FtLw;8
z%<?Sv{&S*i>|I+9*$$SH&+>tE3nNj$C_%qsCf6QL`K;tDwKE*y>kBHQ;}jJdhpT9-
z)fT8!wX?k*4LhL{4Myh!w+XL7X_D`i<D<7b9);!K!g*p{1JDE@W=Xvb-FLn{4G^Hc
zNtk?1X3^?iUSrr=P#uzmqHP@Zk&VXOy^qY6EwP@gs-!tewzP}eTE%O`+$VTDbtlA8
znB){`xw*_|jf5B;U-|UhARv}$o!}9dGp>tnvjxka%%gm^J_&mBxhSVp$4KwDoH8Pj
zt6|GAA~?_Gz7CkdY&<Wk%C{8YC2RHupA?-Fu0}M+{CrlnbvJSS7Jb{|ENlVezEHLm
z7(ilpkPJ;7C*2K_P8yg%ae?Xi>VCojuJx8!>wkk?hT($Sj#tNWhKU(M31A#l5F6sF
z>7f0tpAJHH=rnin+b#EtkY>RWx_RzFM7Zh&EZ&HvTCE<gVu2O~x^;n7&T=k{n&)~s
zh9n^Lq`ezbkSN(O$$Kf>gEMrRav{?bj|qmnaBW~H<py&*Z|H#dKv@JL3HA1z{NjLO
zqc#lTdUP3Pt-Vhq=&nG0j~lkMvXsxx7rHCS2?(jJ#14G)k6i1VJ8KyUWsJE%^My+}
zk|wkTL4kZl>8rQD#5zO|2gBO1J@_t}@HB9p4xX)7r2u}~AEi!Swvb9LrRpLC0uNro
z<ucnH>qW*;!*T(yEP1Q)MmqvuL|0H4L)d+}(RZvN-TONs(Lte`r0Wgv_>dE`C#h`-
zw~)(K%Z|mELdt0>#|A~0Tk$I4aRG<6z!{|q9fkENPm<QW*V7(SktFy&0^vY+TY72J
zNfi@fa)%2m^a~x+e9lNhW|5HAch(*rG2V)P6(wKx1zSaaslrAu-G(VRDj_P==CGKT
zV!15}R7Yi0>9g<YtbO)Fy&o^gGz}?`V=LSx?`Qtm?zvFn<bvLu1vK1_q-}ZJj0=N$
zpbkX<S<W?x*+>O*E0Pb^j4@9Frwm1ah6_@oR~YZ$!C-JcSUTp%MK?A~>qRj$XF055
zeTPuN+`$o|oD}v#fiy&ef^ML0sNS)1fl3SUa91*;$co-)vI8?EQ!nL@95SJM6_<eq
zN3cW4Tt|OlC<3vKL~~-EzxFzMSiXZ;$te#kCVg=E)i8r|@Qd&@8LcT^3}rH|boJp!
zxGTNzdG=Ptill+6qGzA`wTG$st62ma3~%J<WOV*CAgnX7ioq#(f>+UNr`uY#T$@ux
z5AE;<WqLFUZ4e>Dm0a@FA!q#8jM;M=_1VgQP;ObqKD9P%72IH0l?3G1ICW_%xV1s>
z#S(lD*6?|Cs0`il82$k35D&gBNev_c`bsttj(}`Y3{Ggu$}q<vz^`|44d6H-7?!wD
zY7P`!cECPVCTB-0yvp6^op`>C-A^@Gv$XA9!l^EoGEYQKm3nB;G)M)lhe>GCw@Aha
z0~gSr3<zy5|A`>sk<IArg|_=AEYSGnJ$k^`Cp#9z7(zhUy_SBX7sy!tY6)BMvp|lz
zUZEBNp+2*fT((4vx_pctuL`E{LW9EKg@(%WrC&V)yTCxuOlZWSv5I5%4&EU0eR4)+
zWnsc|Op7aNW?dpf+dB$_2E5E|sItDrdTNOYcwckZp@i9ix71oQ9RxfV7iz-?PvS-5
zXhD67MP6FM6mYX>r+?okZ>N}X$fJf?p;|sGs0rj<wRx19dFl$@oD~}7wz!%oM<PQ*
z^B2jk7p|;^g9!GxB#?#SPDOqlb^r+o7?-9k<Sp`u`poJj+)?217IerEDBf5#>s4bp
zM{+2PmccKtFQX&vnMGLMIH()B0SNMBB1>}cTaC<x7}WD5FoJS!*oDjMCS*zxDGFk+
zcfFGYLzYwD5}T$N9ymYKR#P-8Lc@r|IkPf_!Hf%_LV-1|<BVAwdI2kDLWk1)Ie7N8
z@0omGuqE{2FeJq6bd`I{hvM2qOUY%}KYWu;$QU|bsI)Z}tN0cB7To5NMn9_9y3<%D
zelXpeHC{}=La$Tgm3yJ&4sX=sxi8qRI4|Z1%t0Z$z|Uy6pqxa|c<18L66KZDC7W-U
zG<qBgF~&<tfQDvmn7{SIoG4laI&^JLId{uqis9tI4>UGj95u3NV%VxQaJKU>{4AU(
zXoQisX9J?h6MF)^F1}LB9`Eb*W1ptRC=O^(p9pAV;pg11g`TSyO#cncF7kLwtHqe*
zH!&G+V3f2wIf8AY0VG5BW1j+#*Hr6;ev6p0lHPp7wSdh!5(SC+j1AMzHOlnhUS-6M
z_7@LSDwB-hRiTJ<FdLIx@+zXPX#rMJZh@?BNsMHge}i6W{lzUA`^5K5dW1AvbPw24
z(bz<0W94e($ta<mZp01cq1Skp^EQof*R8h<<L+zqthp4svqQ=}NN#^AW2sa-woFA#
z35fAOqdwy5O&;lHv2IUL3}lPQwHC&qaT+iaRKPf+u|3c$Qa&a2_<nf<OB^YzVbv*k
zN54m0Vs<QbRHwzsp6DjFL#%Q}a?^7)zoaL{&Al)U9Q&3DV(J}wYPIC_2-$AY2*+DP
zsA#8bPK7!#u5m4B_|8^wMVK=|YwU1?S-OP*MD)f&Zfc8t2cNC7gcv`H>t2PR%=4(R
z`4(|CqLqM*tPC~=H&j1E$U8PwS{k{^=NG(?JWCrLeqCEQQ5tFlaVrpQmNs8d(Egmj
zT9k6L`1i#_+Re2;R2VITcx3wkLXdFVx&vR!FE|Cn2!Yj8BHNr$Jt_x$C>sk72^``R
zb~T77ks^Rg$7Co3sb;5v0X|(~&!o_^UTM;uO7w4GOShv}J)%Rde}L*67ByySDVQ{?
zAU{7x3|X7iExtS+Ni9BErO835(+o-48ubAh2*fVXWrs(!9O7ptQ4hi%MqcH4xyq)J
z$txW=kT+WBO>#R4Locd;<1`~UP`Kw2J$E5koCqFGS+89#CFPYs=v(?XWuve<cZsnW
zOz&N2cp&kXzI-|y=aZ0?>G8D%M-3x?dI7n~MExY~jSJw4pjr}Q^Mro*pn&2E)i%$b
z_0xC8TpCCNP3~h$VJtOk6StX#m8nLeElN<k&K<X4#NYES5Uo<_AKy-i?!l$g2M@&|
z3b2rl!VdNQHX21=T@!sckQDhTkQ5poebJ8-%t7Q6M~gD`(R6FM7f@JJ=CjSlVie(2
z;hoD4gZ{XucL@?8Qu@-(KUwUkg^Sj*)!ip8c=7Z4TA?5%7obblu0Awis$ld-Oi9hA
z^XqnYijrbX+Ez2I^h9W@lWuuBZ}TJy`_elFcAcKgXgS>qG&}(qqJdo{mBpLMPI20I
zJaQZ&tmq?#?~URRocm~AvO_ME4Sjc}TSlQ1V|+jg%lUMI3}|*9?FyMu<jcFuAzqLj
z>#;|8W2O@!yjew3$_%(B%s=gZ-ui)xhY3N}88ErBr&KPp+n6Pdn`sp-V%_<GA(mjh
z)hO1r6~8GT9kZ3jU*NpEnCB7<W9UG!;FzBj<RP@76hElPURf!IQceytCwaGxIdG<J
zH!Nvks@5;@13%}pj7woz-(x8`2>ysC6y0G)<1L!-Eu;C5XOhtwY>OE2sSxrrV87#q
z8?R=I#8U=P!yVAAn&pd>HqdpdsGPDDKWp??>iRm-xZb`{f{qwLO}U69@aPj$G$KT`
z;(T&z-If9Tv&2vt?lH9@5WCL_B!QnKTuc$77l{R{I4tX+zFJV%@w)I980aL9Y<YaZ
z<zm9}g58%KnPAz|A!v;Z(^)=)gDQk|Yiq;k{auvD*ygsswMX>)NtN8?sA>Wrj4nO5
zEi(1~m-$tpC<3V~|5RTz%03w)Ka$un#w4Ne#cM-D3$-<-Y%~t4oiyX?!fMMFn}&3_
zYg};IR+pO8zRI_gxxXH&QeZJG+(Har7s_$T+$P#Ws8N)l4w}HcET%>NIS&w$unBv3
zUscPDab|3D!^_U{hzJ*N;AspR#H&uGoR2)my5L=I@&OSpyHtk_J|V7kujz~vH2`Hd
z+fFAkA3P>HuhbE4BQ-LE&KRE*<7~at>m&);6?|VMZ1mn%!#AI`tQVGS;WsF%TJ)UP
zwS<$9K`qqu#Lo~*k%I7)S2qHQVCfF(;{%V|LI#+5K{rl0Ur~W^8^s|f5QVQ1-qB&9
z7#iO*?wzXc0kL6TIrg<cZNU~qaF%LltDu}?fT|k$w%d>C$DUjL-jES1f>>P^oNAKd
zv!!bJNe3O3G-aacuQN0{1u`3IL@5-f!Y$mz0GpwE@;X~xF>b32Ney{ML;@ltK^o5$
zqQ@1NC&*b-XIb=5tT)bvTu;gE!yz6by?nfAFtD*#G}7Cnsx7~a8g~Ja&Nk19xNI>#
z=?pe3Fr;lp2NuNRJh9Lf%R%6eclct#EC}?3%0dOqI-9gT+_tRAjj)BHb?=p(m6Shj
z+0l~B!QSN*b(nC4iY(P|)Fo*d$xYa}++^m7_d>w`IjXSFVa`yW&tau5jXc=J7p-!I
z2mt3x%RP#7?hr@pZX?dKAf8QeP}RZ!x5MH;5w*PFYVgQ2!}=_b5uz6H_jy=-+rT{b
z?0FyA$4*Qe3+Dca2>70o`rD+ua`s-0u8~6@6CsvMx7E)iCPEV0opVyf*_^J=JBrXl
zyvC#$FY0`4ZCSvT5fj3Y;<b!Vw%Akmm;1qBWt|T_e`>ZsRSJcK*5OqJ%GG8nH^e~1
z27g){V^DS)t*OHZ2)%yzp4>l;j6f7yl0Kqb9?{P9+jYQbeCfan*?X-<6lFBDkEc@%
z3TNsI(q6RERWpy=K8A0>v2*1NgQN~QmFgYQN92&B4IODlNmHhc5|5Pm^OWT{pX0`6
z6skh+;u^ae!PK*F`v_?dmMMyu4A2oRZ_zUOBB*09L+kW3vrlqbAtgy8L!uW}q*0=H
z+*To$weO&HcWl%pjtM33`Fe(nn#zaN4Rs)|2{Yi!6(YV5f*M)9VGB=-LWvb?-gFi2
z@Pfz*tf|0n3DY#r=Zr~o8V}~TnUBVJ2iIR68-dVs5t=QY@A~O+4s#8?|22~IYQ|ko
z*QjAKnpdde=F*_3xMA)y!ob}k1<Jb*vr6~^@L%Gogwc)~!uKSEx{@s-Y1MTxFRU(F
zfSDFpqj|x8GD;G^Fu`J*DN8c33=TcSw6fTo#(|G>Ub<dkkeK(DtPNaUOBev0B>lu}
ziQJHeWlI9YUI4FZMH+gVzY&+e)kZ9-580MPld(1=1X)dBlynio*5!_rCdBOHM;#JQ
z;=n6DO#7IGPR^A`FY1G?i4c{IR#4)WP!sQG7C(;_8p`ponuXZCnw*UDWvOWrZH1y+
z*2AQ=i@t}!3h>=*%p@$I-&QPe2fsm2g$@f=MN1med26-;wjosvJtI*0ZH1JTQu-1h
z+2WLM7%dM}ap?iO7I|c-ef^3C5^9&t0Zp!&Y4#>Kz84aY@lZM<lM+aB5*0!?4AiWQ
zzT)hPnt??%;DY`xTi`ilNbostJ_)^>D%sLHM{_4yqjna4-#36fudNRPk+&1@&G2}b
zj!x3Uqx8ez_;_%5`Z0ZVbd0}9-yI*lJ|4X7rKd;q@8O?Mhli)>yW#QM(dp@MKYjTz
zNeA!V9gOw{FAs+4!QcbRas7F3`0h0Q@Md_J9%1_*MkmAc<aB`F7#*e`jz_1X!`IZ}
z-qE{{$D`M8PLuS_(ZT-km{icdhUe2a(|3d8)6wt*d-CgOf9QLaZVgVL<6G&6(dnC`
z_ovqVBt3cst$a-XG&<bxrNa@mH2m|s<Kf8(bO9P4y@fsx;g_Ssy@U7r(3@WR5}G(X
zI!zBo@N)36(<8XA@OkoKZ6CV>4|qE~-g^W89K0MIj9|=AyzSNK^bnpw<2T^G@4Y`5
z9K+%E{`lR|$*`aDI6^Bh>c^v#Kc(;zGP?i#eqb%Z5JMwx2Zwt@e3*Of1Sbn$IsJI_
z9<LF2_k;atU~sU8>HhH5aPM^V>#&EPgy)>Re>;>xKRJa~Vd@SJ(!=2%ba`<6F+CX`
z|2o>Eu{a*S8;p)|r1p-EkFlAfLt9fn^ci7qiI)S#YujmZh|6jCD=wDzhX*($$HRYq
z5ATdirnX}6DTCL?LmG0oJ`#9K=pRm`trA%zJ^Bv(A}o@Ru-=Z+w@3S<S2#hki1v;S
ze;s~2NuuF_5f3YP@bU;p=p}SzL_LB&;Bes-?hoD$UJp;)D#3>)subT#Pu>mpM)()_
z0IW_}3<o@BhbQp5ILq(@X(b)NbYl~^RC!91^gV10T#kpjis0$^GvD3q@bu;qO%IMv
zPG~Oo2d9ISIt~AQImC}24-a9mXwwb$_TC@E2E<R`SD-&9?_o=h4tYxOm1)zDj`tJW
zb+n9M4Mqp=kL$}2pM3<wh;7npbko6~IN5>ygKHoiy@H4By^+aFqs{#>eFO9HatI$A
z?EgBV{V5NEZjNMF@CB&}8BAM?zw5Ig4N9okdOT?q@zk!lNpvJy)ewGm8m;V5i4X`@
z7+xG?CD~e<mPjnY)jdolE#PiBsJXn1k<kg6llcwDU6;tC!{G(Caiyv3Mhj_>WOZ6{
zQ7u;f{6<<DnC6-x<!?DfjsjxKW{U+a{o->mb=_|X%y`o+AZDW)s!(SU4@RgXm;7u4
zPnVL)HW&vjyuB@dV4>2qcgtXgKW|tuY(Qhh2(?p1*nh<P@es^i=|&YNwL~O}T#K8a
zrL8~=kxZ9_jl9qWRf{730>WnsRZ@zob$gPisTNEvg`mVsitHQYwNz!(q$dB)h7{?*
zVpNs|NMhY+)&8}VS5?E_p9=V`hoJIIqL9G^)@n0zA{6pCqF8v9ozweax9#g!`f0Gn
zxD18xP_F8L6@RKosx@KbO(Lm|oHC}OrlzP3(XJ&EUg`SSo7x%&RnjSY-zZ;sU6QZJ
zK@6ocI$s)hFKI5Lc^g*S&p58sgwpc4QFvNW;gz(0HZSsXOzLDt8zo`-{x8ZGr54)u
z-cI^6ati(ekDxY6Er9&Ro_#9H!iqYH=Kd!QT*Wh9EMl>6t*~lOd9F3Kvnujdv@)vO
zALyxD)CgY$1c+2>ZO8SyJ55ii-#HB7ZA}^N60;pz%tRhPdkHYNLOzVXuG)Hd+o-+w
z!s?Zg!-OeQCHNW+GpSRnTWv7NT}GR;*-r92)QYZi^EIc!PPn7?!W4;L>jvzOfrH&`
zD<PocjtfJ|ekN=H1a0K$&zFnE^-o`aeRFfuznCri<^1An#jAY%3wLUO=tQhe@;oz0
z=fbBeMdQbuv_wG!j4{s38IpUU%1m~R_#1e|+QoY9-CTj1PknT!X9CZn*OTF}%omAn
zU(y<;ccWr!<o{g|2Pf0ndVXf)6AGokKg+X!x%(b%tW0L*rr{mDJUKdee>yz)=slws
zG{rKzNGFx2f2nZDZl3y;Uf<~9ilGxfpW=f!HX7}FZi2VDRi0bK;)Q?U_^Iy-PXk7?
zE?3tW@1)FTP{Y(tQa`K#S&)@-&$xQ>8uxEU&^1ku&dGwYe0(@n_1Q^!MN@%%BI-B4
z5ToGr`%z%M7SRvt(vqSY=@!^putv_x-?ltTRQgQ-Tf~;qlXKYe<q8oQ5<U--87e55
z&vyu|h7L3yDlG9wxjE#iV#+pMI>AQV3J?V2`bW~6AQ|(@-~jPvVtsNabIJxD{y-de
z+w>?SUm=L=E}NGFmun6p3o|j4&l9}C`Qc|u*xsDPx@qFMG7@)mXNZ2AmzZ_UMMQ3;
z<%-PnOjWYDb7@HU2q&x*_XVTsTrM9TDaovbgh5q<Nt)L%8t<$d1ykGzI0BXE6@Y_d
za)1E0d1qh|VNZEBX~`rZ-x1X%A#|F`*ANZVJ|)+e1(@XJ_2ug8o6FTMjP>sH;(FS@
zTwG0ImJ(_8rxb|^ZUPFyolWDN^!Yc>o~Lh%+3OG3C=LlTbio|IbDZ`S!8y-XA&D6S
zqAb14yntzWrp5k|b&j^4UioD21T{geip`wZ;5M0IY9wr-J4Y}jX2!r@ngJ0ALtF`Q
zKrZXAgL9Qcm;(WSFxHEWo*tq55%0kEOV8O1JqN&Ktl8HBLan8`PoncTEI}To$}(Ye
zx7*9$=?#tx8%+x{t)ub_Z(i3`IZmwxwW-g{w|1CXx%Ct-M;cb{=t)A}*)!8*?oFdw
z3dLSGMnEnIaH~&_UY){qMlnB$s_knit=EX9)k0|;Ljw;!X$hgVg(vWdYvX1xf43Q6
z<PaVn9gYrP9m8XWZ-<Ac{V2wC@&+SW6j2$xhZi_L;V?`bH9B!oo>vk;+B+DG-u5g;
zqoIj}KF1xzKqiGN;E4nHKMIE7n}CmcdJO->@aXZWeHWvhJ&pFj+Z`Xl10?7}u^#;5
zA;;7>bP`RAgkB{wB)!=m4i2ET6a2RSv_ELz3fcYkpV)fYTV32>%2i9F6Zy&i=l}M9
zG>j9>mQB((2)7%}#{E#AB8^0-gL+~8eY}sgj>n7SZqCr%{Gi66-{sZ#lJahcCgg;+
zVU$0A`%gQ)I*oG&-wy|eSei}`2R>qayxlOI!C+LlF&A5)Gvg0bI<RU^j+}d6<l&s4
z<#AgMv(>p7R0_+(z?ZH!Tr@mVJzZVh)re>iBt9S#h<-U=;=M%yzc}d_Bp)MWg3A6J
zUFS1ZVNLgggf7h$m=t4L*Zr*L?j`%7^4cM$*G4)d+SL%^5Rqfm=eN~4hN)EDch$Xu
zg)P8&>Yy<b2g?T=wQVZ&?QSQqI(rbH#u6(=5f+o#Q^!(hH@<%@*7Ox?4=J(^%SG-a
z%VJtbz2w5Fu@46<4^3aJ!l-jux-H?cm9fO^)YH9DYrO!a&L+Y#k+f`TSw+#>@1k<l
zMI-ilQh%aDk};VU*-7Mu>k<y%@W^I+(WGryX2P%!s~bTH^A&5Fcbv^Q`zI#{{&0Rh
zTfTeUIGA7D^F&M@5*o6@IcYte?-CZW12nlUBxLV<&p40|0VQ7$18O-OlY7K})`n-=
zkH^u>ZU&JFYn+w6wfABo0$MG|B-I7fsX&Hf;keJI*Aycyr)ZO2Twmbt{<rBQyYAV)
z#>@GXVcqhB%TL$gKGRhyE(xaRx8!GA>X#8%l)lkQ_EjuQTHA30OvCyk|DxWgkX%Lw
zUv9@&IRC&sHDR{$Ob}6P);pWci7IwhrlDf6*okl}x^jB!ogR7?lBGiv{iJ}#u<D4S
zif=+PDr#pTeU))lD_6Z8sSR*JyCpBUeC`I}NamHmA)HV1MP7euz)&cB*lodZF1<Y2
z-~AQ~N{QF`E4-_{@Q!jI2Yqt<i96$}o`{9bb^l>2zA&%H;&7(q+d{h3;z(gDq8$Dc
z{{30M*0riGu_&ad1|hCFVAu%!iQF(a`xb)hHu$UfVWCgK7wcmi&zl{A2f7i_j;K`R
z-={Cemqaba&bwR=yo!~H!wHJp7Wc0~FZV521#-?)(Lff8I^NF;T0V;vF+8ljV{;{3
zz%AGvtJAS<+cr+nIk9nK+v?c1ZQHhUVp|=v<Mcf9&X<{*y0_-TRIRH06ZT$v>7s6v
z?v3tGN*R3#S~L6yQyN+_eX|e}Dsmb&^bmCMIg*j3+)sB{DruB9G;zt~G=qJ2#ogcD
zo9E}fA2LKscek7#v8gr!f<yt&k+FvcUt+zti)AnLHVAbYdoQi|qITj5^~P_@Fb))6
zl)$#Vp1;!6NBzjp@0MNSHa8RX!MB+w2*x_+KW^esE&^`Qze@XI!rXAaJmKotc)r%G
z^9k!YT}#{Sak0`9d!EORW)DUFd+mBU@$vck^T`_!6JF&Rs>}-%DTh)sW1Ro4b&NAa
ze)O<_4n_3);qU)S<YPzB4&MKB`||S1|JdMOU%)L*Y-p0-6!Z+o+Ak`^SL_}t%EwpA
zBi%Jc-2H)$)6=73GvkZ4?fUpd2sm_jc{7A6>gA3GLGXuu!zGNox=+{v-;!KD_C;db
z&#_>%?UDE1!@>KH4~5&)WT!7Z1>WE*$`^VZV27e7rFtCn3`NLl2;33v51T0b&v6uW
z7!lfS4^L~g$MPy2PC&&-edbFZCQI((Q8sSmG&a9)n=o_~TQIaq7B-<L9(F+<HnA-h
z<{n9aT-$VK+WX%9PXSh7>~nu^RO`=Q;lLi)q(A@hkTIK93G_d&+`B%juas$K6KAZB
z_i`!*j3lI)7@gR$Vf7r(yNftaXDSY|_bt*zqxB8FQHUK3zMZc5(GcCfEa8hWB-m`b
zxf$MwR9z@!o3hoQ4ERH+uFda7X3#%{VayPCg|Y<2bCb1K2Mc}=lR}YW@fC%~=xkWN
zhdK=`xaO0lYL`H{2F%-vTXlnDj;B4j(+i{%{r|vL$;z?Yq%YJV88Ths3sP?UXr`7|
z;M2H8pW>301F%tIF@}zv1^5ES*#xSx9>jMi(}j6JZF-lt8dLZZPV7A_*oF_ge>NHu
z{VhjaF3YRAvP`i<4XGpl%SY|m6ln8Nad3$!&=ee60KN+rz*qj~OQf@+nZ<UYjcfRG
zb<_81;AW-Py)o}(gsH@$;EV}DUoU%to{uB3)Ok^s=i<=VHVz)^n`v|V=td_QT4LR2
z_Y0AMRCb%T@nB+Mf*#=v#QkRy8*kU3qo!lKT6{t26QCic{>#$z#;4MzBZ{bSD8`N>
z1DR~5jJxH5+PeXse5U-RJR9<KWW?!Oo?!QtymLD%hZ;ctp%qS>wCbEfKF%CohmfN!
zf)3}Ok9~y<s@Ldw!7Pc{h;mxCt!`RGzv~TMKAB^!<W1^FZbYrOhWB%jicdZp5l(*i
z6*Cl&k&fXNM9*XsG6>plMfJEn8YxHO#TW=Z`bDx(8BINZ0l_^(DR|Z`Io$m2u_-S=
zp2g9iFwLx*mVq@Jfh_T{w~E#07-~KiHzf4d%&;9Pu57!k@m=GoB_^=DuX(sAU#|`H
zWGnU$sxRYL%}>BDlw$J1hHvOFU%Y8Ij*JuqDuxct9-LvUShyn0saRLEmeZ;b6t(c7
zH_5G1B)m4WUJoWK=vDejTEs%QJ>d)ieu|JoiBz3(3ct|CBr_mT1r>}`2-?|AnnF_o
zS)&Pa+{DTDUBS-JB|of+RCxG2J+DuFf02`_)~>LfKKbr_;CX}e_C;>gF5oM6UbPBb
z1sZN~+bB5ii6ty6s@?_LSnCsYEs|Y%(#+Aig8nWc0M}(iUnbr1VL5|^&r-pjxlJqm
znchQLj2?W8hmIq8$1LfmFvm9DliPM*E>k;}avKQRfs-OcByob-A?&H0_3<jz(j%2&
zM)MCWN<4~))Uh&$22U&cvTlB_=7x?2zm3RV5|<U|iqmcjlsKd47WivEM3LKW63;*~
zXaHeU)#NoN)~>0aUUP&LU^<5)#%h8?Q#HrCC#WVC53@+%Yrt%`gDCV@@QYrM&HrW2
zWLm&(KoLxxS5|(QN-mcDw3)ppzM@Bst70rBm{so6c-OJbYB#grjJhD|UjDcfA0G&K
zX%H=#LCktP4YnP(fsmN7^$>zT>-<q327d5+%RIB&8~E;OX3>^}GrM%Y*IsinXBK$V
zMH)FMs~r~5E|)4YjnRLVabcD1*5ssN{3~}6xfLGAGf(cI!(!{4N!<Fo`_Xg%gRp(B
z+rARF5DRefPe@)kgfBUTs+^3hxEoQ@-IfPvs)VV+D7Vml8-tbi#6RG59oY*`e~VP9
z;HDWxhV_bs@)*3ch|HMbbf1kVlpY`dFU=Cpo0CZFm;^a2rWcnK$s(2EJ8jBQWiJ(k
zRW2G(=t3X4f-S8D+_I=bIskp8G*&A+Vz3an`?0x<ydUn=fh}0|efMRg`wQBabmm|l
zt+<~Y&)f0z2$j3~VTzmR7+sjmM_ix?L6Kf}nTr-6WK9qtQ8Vt|R93Y7`C?k!yz**@
zyQDbk8b+{qt2CwtLDPJg2(03om87(^oHUTZKhK_2v`o~W7%6MT+(nV9sl%=vQ3l?t
zVCTiu9>vut{ps?uYOo*HCe6|0k0^X;7EW5x^wyPaAp2+Qxt!Q<8bsq%l(JRv#8E~6
zCwRm)<upnsaPz?QD%eCwZWGsDE-6Yue?9~izfN0DCEW#Iuk7y<`?D(Y8B`Nq4;?^9
zsos3H{)PVJJ;94_H9#gBe)A}@C!*x7>aA()dOf@KI)o#<;|U-F^cQ`$@GhP+mr2jN
znaHhnDq~!64uxi1CJ``S4jk=Oz4-NM5p%^OBw2HS!cW~FVohrS-by^@?Bur8-*__0
zy0oYO!<KqrH0~hDcNQ&zcN`E~_w5mxn5OB<3XaF7Z`j;%nlIBw*CMgnKH<yxt1(IH
z7O`DgepIvM9Q#2Wc@(h+8c6h0y5nfA%D>~Z#WFku047WUE>(Y}S?OA>WrHf;WV<pf
ziH9`#DbfrymN$gDZ^yivr$4S^hm_&GnjcDG25nmnX1!;CvrE^`4a|3#+ERbITQ$a$
zMUpWUupB?H*jDpqXON2ARBBgd*&P7C2w|O^)3<$+a0hBzLcUnI&1Wy=TOzm4=C7S1
zi_OIRTm~&waesWp86?zVUUf##>$wGr<Tq@L^)2eYBm%cwxU{qh9h*Uq7DoOoODkh#
zcuDxMhOQT8jeI`jCsC^g^Z1r?R?W!Dx2zEHfT^j&dbxC@!YDKnD_8^hdJmoISCngO
zSvp5{rYzOmwnr+AQ@R+ZFyjMqx7LjE9#hj%_pJaaA^Ogk83^;31l_83-Tcw+)JzSf
zti+p%C$I_EYwZA4_1hos(c6P&-cKeb{-5v|QJ&T3TqTGO9rNnuJoIay#9GDN2-ljf
ziaiwjcCncUI97>c5c@e}2y1kAcz2t)-PPt+A|3+!YGQg-so@Ia)QY{c3Xw)3mL=hP
z`VR5YyFk>~qdZoq#a3LxUM`Yq9EFCGPHK==An~3EN5Y~|(J_8V)btX5kv^sjz%06y
zC$q95!KBiO=#URNo>MrY2PF!v&GovaJlhanfll||F=lBaG!FdA7>+*J3i=2G3Dm)4
zRmD%|KsJXZ+5k3yQq1TH>XYRTbp30imPGV3?EB17FuXJ;-wI+96}1Q^Usnyo57)9~
zf4regFw_l8Q3@)14?%XcqKk+13raznBkf1|g1ljP0fN-_vJ|6y9rTZ-L&L7Bs0{9(
z+BnmT;6DTPVc!z;;!yr@CQv=m;aL{_V5|knlOdlxrZ<DKK88I8+83-#xb-Vr%f<h_
z^HhRrQ-}2nHof#!U3&2`qW)47Ugdt<C<E#6<OB(rVK1VSZJJXSTw%vT;ra~|@XX8I
z_UgSzHt8ZV1Uec8Yx%J<GR0H4mYMV3>0=zVSj^YZ??B;Gy*BfZFDj-_$)z42v5ON$
zU<gJ<I-OndOK5t2PzDCz<uqFsG<Wlya&)Y#xuHrw-)$lgz@b1?KsdZwf)djxf>_7U
z*yQk*o$(GG=IxP8=6LI7>1dtI>D6>GYWu;u8@x?Nc^K?vV+2FEFDRN>oU8i#*1zQR
z8?jA!2NHi^|N4N^aQ5_7SUR@AXTUCujsQd_x8&tAn-7c^RMkT>2flvS?e!CQ8IX`w
zP$M4kB<G>F)r=R+Vu>qrT2`4s`xz)kQv4dKN*X%^D;;|TWxw6};t*lx(`|ZDG2Bwo
z9>>~7Ub+ePie9)Y3=Aj+@O<^)$&u;45fCgdq~)FmG22LM+i}<PNpgfB1!72;sxTCm
z7pkK0;EVoqrP^ktCpnPj^2SeKZmO6{N`GR6M@P7tjJsp`Ax-;~=BmTcho<<1!oTt0
zB)dg$k?HsNI9ZuvXDp7ijZSHouBZ)hzWxz8OUBt`i!l_cKYL1=M0IC^(UFz(mnux%
zd&c5^9UvcjE2j9a^b6xnTVfeg{jgba%$>h$WpA7RW&UhVn6@ib^*h?|0OVJ7_VK7`
zW_rN6qJgD(xiWcIa1VRmXdr7<EX(d!_jp+nT}TuNaFoHKXr4YM0q(Eye_gHFYc{MF
zyY5M0q6PoaWL>X+UHNqJ?sFMQvMaMX{Pz%hPZxAZH%)GMt0UaJGwfWZ`8RdAP~D;S
zpIL>n(?bWOgZ2>>x=dawTxIUbqn5s4%3%d4Y0+by<Mmt?Vlsn&rs0-uJ8%}Lgg<w{
z$k=BkVj?rnRE03LRy7!5V#a8QK1eiP5XWn)hfKQu!c712Q1_?Lf>M?d{k?9ozcSN$
zASyCVX)Z`MBuy+Klb^XBzOHCYBO`cqxtf}aFsZLu4HGFB1>UgTJ0@ddk_tOE{u-<Q
z{JZ8u7_~Ue%0k*TsL6euOdU0;6+_~kY2}=*%jO;y@5m~0(c3b>B%5eLyl0jpOOL^5
zKOo{(i>I##o(`C7IG{1}d>?)c$x!aQ14BUtkq(|Rrr^NLRb-hl7*s80Bb=!Def%Hq
zIA-{j_xW<jp4*nLgy7#BD)K`XV~>CL(7bWIjJ8w(>(-Lz(g5?c{#su_t~*XY)ev{!
zbQgKyG3#_L*SG2Ya??I{0FPJn22>vW8{ygjC;Y}s?H44fkSS1CR)_}Pqq5?4nLzv)
zO?y(Y-Y^f|VINpMQSQ%cOXE7{3>vmn^020*kq<{h7(9%*edo;vWNQaV>m^Utmc$6G
znuXJ-Y`(7A70SFmAgh(q&|BNcBw%pfp@kk`R8C3;hZ}yx2Qr{L2Jxb^DFPx@(X>~b
znLrgjZ_40K%u{5YbNLuc1DafOQ6L<a&@sB?u*b}z)mD60m*|N?Ix@Y18rz(66-d&Y
zAk>qHhjjb#*@SpP)wMp7-^z8#8L%WPnk~`4>auXG;o3;(1Xvy)mX6x{ky{w;ufpbd
zCu~tI44CPv#$6!91bSOSeqSqn`1qd0&F!*a0##FmTDN`s$gZm?+vEx3l`Rn9o#4_E
zm--M}P=QB3{tE%ShgwSfhPs_o4gbO4jz20_Up*g<U`Uy%sjzeF4>T7%CgOd4os124
zgFRcBC9_#!{0LzUO)P)e{8Yn=YvLuEa>;+~cG#C8$%L}r<?CiYegTfDM>LD6X+rFo
z@9zeu78Wn3ow$n=#+e1bhaOd@Q;@-rV;ZxoQ|`k?L=7eiX+1^whqQ|>_rjML>B_4u
z=aIKtS?O6mlNl7n8;4*_%w<%R(jyY{fNx_TB@Y$Js}-(~|H5!aIt9ROM=r%i>#l+=
zaYicSa?pheO7EeA{6#CNZxz(;25(lexGNv#Q!myVo#kTEP-+K*Q;krLNb747ZlIH<
zoJa2<DGSr<LqeA?A(YyXe6DOO*<2Lh*pgBA=`20b5cdHA-|Bp=)tOmh=h!52b<y}@
zU@F1UpQ?q!^m7AKIRSq2LWbk9HC&lC0-CjkCjbQgaUm8Wp$yb$B?ddgb*B4^bL!L-
zB<RDtO_4k${zOM$H~N;^oCt|oOulEohpyg6s5QB9rja!5!Nl{DWHxA-tP2*05?q&9
zT-}SY!Oq>m`Tzzb5~j$6#BOk!>;j338YhmtZPj7sR?-tR_gkglaLnq;A?(DDqVGsw
zRZX&L!4Fb8IPYm^6`HS-(4Q%^!#ze*QL(P9i2@w_@MH{~1hmJseDu(P4yaAygoW1e
znEK_E?Qt@#vKhBXw~X9}DlR5zAjF}Uf4^L;Fp^sj&RT^N*Hy_2t-AAR&@)k$l1Ie|
zVZmj=;P-g^IElX<3{-*2fxfJ(fegpbv7k8t#DGe818Nb&vJ?JgLp8yb6)7pUgGfa&
z*C?sxD}{5L<bcv>d(>DS^d_@F>lv0H3&!XHnVhbPJ-hi6!Kt8D?i!F*__&RjF)a{?
z>^uo8nJ3rUuhUEiendQxgiA<-Ds2KrPA-aj;=A{>BHHibM;b*9h|=zd+|ASTp3+M0
zlcC3T=XGUywsPk9n%B+8*~<8k-fCmVj&dH|4OI<<_maSqcM1c<M&h$r$y4nn$W^8#
zov`_IO1m`b(F>AUb$8Ic;TKDzlgca4Bge&rR7^~}4ebQ9x_#M%%#G&c)11l2Y0Shj
z;t+#Zd2+1GUk_j)C%@~Hi1Ki;HVvzD3<QC-^ko5IOsSAYqBVN)8C_SHappVPE{IAk
zFnuy32q9m%F^EMZ9lvd~^^@f?-(Q_ZkqVwlB$*F1Cm_a}5%0**zex?FyeKxpCqGsU
z0!#*p<}}n<7?@W$<k~|c$oEeWC$(^TL@p`a;#msbSezu8&kGHiM-bKea87aBO0y1f
z@jKsw61mvA>;0%40uMU&({E#rC<yw_u7EVsdZ2q{$)s=gu(nbUTYmI@Bo8t}-k`n#
zvBwAnBkfk|hX;oWrtscSsX;17UKRRuH$mpH`|SALgdXPX>B?UUj*?ECo*eL;HN=>&
z@XOV$kb%BL?Q^N$Yw$*Y+E&u#`5}kRzKKr*Qm8zKhxSGrpCpIpiitam-e8=$;G?Q$
zgtJUb{Rjd~Z$lU*kMLb;liPrSZdj6#1c@1QY+JuJiI3{ZL|FtBlBqJ6$%nBiBp?Rq
z=$iBjV&r%<SyMu(*rZ)A&kpT>nc$DRqyICl0FQ20t#gM(8RE+w><o{os|L`q>|6Us
z!t(PiYPFE4so;4rdc}sV<t?sSIH_6For5__Y?aFj0c7<_CO-{vc8ywX07fAp`QA(I
zt5sG6$TmDqtu)NI6JL|SCQ3e(4|r4Ns=~PXSu)gKy}Q3d{LLWh?oksAUi;#V0O3Kq
zS;|*R$>?L~E;rZRkw4ln>H<jcm00lnzpY@nEoiOXq~GlVT`i-{wc~0yTpjYNUSC5B
zRup?-Ox8)9Nap56h)r<IdIE}UUP@sw@Njr0*4dMBRSs3hf{`jIrd3KSkYzDAD~Bb#
zX4r}gh*(j9r*t~9kE$}Y8<6)27-iR0vs!DV@+gzG;^aC)zI`o=*a=b%Mozu6T003T
z;ca{48whAeI<5I7jld8PrHgeDMr)tP?<5=1QAA9jLZAZ^Im5sUQ#+IblSiv|<_W~3
zeU`#HWkUyD3Xa|4S;k{O;Ywqcfh3gw_0n1*c=Oz`!ZnWE%V;HyLQy5_&55aHYYScc
zd$VF%#QFRSXKc6xwNls;YYAcSDe4w^I>%CUy>sVa%jF4ml_LcZ#NqTZ)Tjt)$jOmI
zBl}bOv|Al9?4L2;sAKk28_Oz`n%4>LU#L(57#p!C07oKPZHmp09iTm&q6})XzJzFh
z<s~S-nS~8AfR}RnUU1|5W_%i91d=dE$0-?1LgQ%{bS8RDgC#X)VTpesPKVKkVdjk0
z5|T!CAmXD6`p))`KBh+eaEkW(&LxIu$Ztw)B-m;-G{CrCM}t225!wri(w^RUbkR$X
zIx<&g;D@ICVnrRSwS=i=UT$H?KFUqE*de~E40Y1W;O!IJ(NCa*M~6s0_lP{5g%Ea&
zk(gsP^=y_BGa1ezEUDB`!Os>x=%fKL77t@8h}XZ4Kd!RGxRY(;L0kn0@*2pt>k@UY
zzK>iWf%wXS0>&9a2f^WL=El<djRn2~Pyp;LY((!yZw|9#W`i2kiO%@Awm1X*uj0?i
zvm)}TLH__VHJ(T$1Q+kgy1!I7OBQ-pTA0T_BPHwfk+GJYDCy9yE9)o35G=whQDjFE
zT)Rt(`y&2n^1Ewwq3lLIs^l6RnoY8(7wfRo`4$)l%m|oc%A7<1!D_XY4e8;LnB!#U
z=dIce+LjSHU;1I8M%t`cQDv`AY6;(d+W(}N%Xz>m*s}&@iUfy7mY-5KTLb4&^c6Ce
z^L%5SdoeV%Z~PN8?XS`$oU~X|^&NJ4)gM<9yC}g^A!2TLg%4d-tsTk8r(VnX3}xF}
z`4w>PAREe@axRa;_`mJ7@g7cKslvuVk!_vh8nqBZ)jfDqBconT77QAU8*>cG%5|jg
zi%ZqW&7j`-Gu!0=pwV7s4a<BWzA6PCOYUvOe43-RLHTd;PPBE!hyAIHc-e8j5xLw}
z71q3X)~JhuO;8Qyl*1EY^^=WFV<MvPXlHS@quEMsI!ka};ct{g$=_GhIa2cns)Ns(
zLQ5R9Llw9#m(A3I{-3hn7d`?>e&W4T3$p$r1TTw+y*R%{9GCBtSJC`TMJ>lft#Uv)
zIz0{7r{dC)i-)&T3Kjbf1|vc(-%th|Ss1iCIu<QNb;4c1`r0B{=EG6ia~9ATQc|qE
z|7}V35T&Dt_H@*Y{+7D`>V!w-%nuOj^gJlM+5;lkaMyg<%2qr!9{Hr$uzRQLN1p|v
zZ_g?S<y_O9>OH_HV!YNK4s$_Q=b(vSP|J7>2zm(t$5l=D4@TSEZJ}Q=$K-6acrQl%
z2m!pn>xaz!B;kSt((v9{cm^ogLGeM`z4l?-smqp_y!8Ie7%t8rx)p=)pLI$tlJNDz
z^`4KhYS)K6IK;&_a19>hECprUyW)kDb|Xxp<5gU)7&9y5Z!z_{6ik8CT{KKCWY%uL
zh_9LzhE5GeRxfLNhoW~Ds_lFw-46%g)dDkx>y8J2M6;`wKn+G&Ks-{xeKW2H#-KH)
zb19rEeNxLMlIqEcIW~oFYqKNBsL9*_H^yheJJ?+%e>L-VB-$KhLtC{xsDi<d9r>?9
zNib9|l$1?Gyy^&1_F$Sf@^i_sMw1dpeiw3^Py-KCI5h6gGFgQ3s*F&8c-fLn>%Y12
z4-eA2l3ahR*B)6KSyr1s_wWsv?J~sivXk;rbG>L=EI<?nBwAp}`UrGv8tQq(vmCRy
zWC^1!B@w^2im0YBg`=hFTSqn%En47fk`-_k6-|rz%0x~eo7db~PA>S1cjV{&SSQn!
zeUKy^wJy?CY_XWwWD)-6N=eQbwxBiPNWPZBYLb{ESzx&6iz&dA!M*i{bvc*kEbM)L
z0~>CadyjNdxHFCRLi_io$=UQhKDC$Fs3c)$`quFPhS$M=?#|hM<22SrdQWCseg4yL
zhByhkX;$`Z3e~fs4Us-5u&Li%5o67a10*h}>18wK3OyHt0%Uya$<d4yF))4;S6mBh
z0WGjDJR!nTI?0gC;|5I^I6KOZ8c-{N*~Nv*j<Q|M7)v5i^Xxyv6#>f5&z9R#CnbYM
z7hnDE7u$Dlp79|{+ugZ`5{Cf_c26F;Hz??)hQ}0WyYYOI&dgeeY@|^vZf700!EG-J
zg=@V4O?By5mMGNdDPHm&ngHJr+G4F<>trlc_DZOwr-d%czuVxEL^f8ZB}<^K=&QA;
z08}~s9lRtF_^jKJ^##0m9Mg~gSUeF#NY0zY6dSy%agy*e`Dgr$rGfb3r8CztNOTwC
z=95OZyc83ca7kMsgCVuX3Xk3|S#m5qy};OgCgiHN))|1^E|j4xCm*vPI;OVq^I*iD
zH&IJVr-@0#@H7`!I^Bn%5{_gFM)b3EI5S6g?JGFKEmtA~3PDCK6Wa3EFk!I77JLXI
zx+pq{TQObPBzhr#2T^PsGj+kBR{7!g-c=WEt^S7<#FhI$D&j8H7cRz1hIsJpl0sFR
z4_<htjBxP$mJsbbl<nv8U$9iwN9eva+wxXgvv_{wNXpW~I8qXG&BW<RqBefDu{E|@
zX4!UBK5&b^Q!ER=RJWzLo2DYDxqg4)g<pF5gDj3>gCw$-q6TOg<;q&64`t|?g+206
zxKlF`qVbEe2=<=Z?P;V!QyUOZ>ou^hP~;mW><4L#-vK~N4|-<{S%4<FSbd?Fl(?GH
znWVP_gF<#L^>kmt@~<X*_j{*kzZ20;0YZ$zynq1yvOVfIOAXDdSR!Im%!EAC?*9G>
z4xN4ELqoQls$<<j{AJ8zUAChXXJHyM7KC)SwxfM6KKvJPCg{;7T*YrZmCRU3sc9Z@
zh>vMv)$+bl??(UCqr0BUTCG@OqV~fV?b<2ab_9(curM6(1ca?b>X;=%R$l$$m%-H-
zV1*P2wvrnBnaahFAaK`GVc@KpuBdgm@n;Lx8q_SD|46+6;nveWLd;^g`IjqvCm9uM
zsf04iq{F#JU^L<UIUEic>H037rz&IKaE1p2WE{@jnMAd!l;+%!bOl~}J4D@5EZ$Sb
z9NCW1Zi!LRiJQXY#&U*TGf#oG;6lQ9jgC});HgX{HdaV;smEH_GKA{^T7!T1MzZVn
ztAmQdJn3drv9Z;M2qo`|D8f?+mc;i2K&0dt(3QuGXnBOX06|82-B4~p2Nd55XS4#i
zp5VmJcQe7H-+JDO)O+Ke5L9xluNFX+tvJuYN~yn--VK27(shg4O87m)Y7;vjn5bpO
z(aDhBN7JB5Iv^+f-5b0Y6@BL+BTlxxU}m!Xnb|99?P!D(Iph=EVDZ)g7KNDe@)bUZ
z{)%kBT=hmHDwJf`0L%133Q$EDif7@Ep#%O^><IGlb0(~@iB3hPiA1s2UO?L&3&##G
z0Y=3A(r6j<OpUOnn%ZR6OKtQ>=Kf@6_zWY1U*|&e%1Dk77PX?PllX3PC{+cu70rCZ
zURL}h>!ed66a<%!FOE!eC$6;F7%H#ILPE6qe&k$H*N<PGzY?RQQd!C^{wV0j^-xb%
z)@m_(!#*2!;nCWzwluRN0@+HW5MuQPR^k;Ynn(*vlFO<DvQ!$3%FD^-VxP(XN{nDq
zu8xh&cBkw8JqW8V!$uL;rND+&!~(Rfc~oWpq!$IGj!lPWY8%TSwZ07c9q*pQp@T)z
z*ry}TS`=CObbR3gZ%v|f2uv~jL*~HR&xo-HrYc+ZRU*+uYDe_X-X8JF_nF;ITuPQB
zaBVq~sFZ_nuZsnzdQUiROXsZ6n(2K=aIm543I|e^nD$Cw^0pifnE{_I*s$1m`4dw&
z3pnZ@|Az81RgM3Yuvc%94R@zEvPJZ^#aKX&rmKy9TnsC^4{CX)e5M@UX*lT2gX<ab
z@%TPz^X8l?KFe?IHduqQ*|J2Vej^mhw++XQ_(YV`7yNF-qx4Gk6fmaO0azJuKbw+D
zxY2AK9L@Qfgv#|$k9ZXH8~n%6Dy3MDB*+h=QmoeOC!9kDW(t!kzV5N+9rX5szZLFN
z=*uS%3n0z`h~DVMQJ{t%2hUoy0})yTGBUw^h^UIOdX@;9iD1;i9?E4@d0wRK%iJ0_
zT-MN90nk8cha8=EdlNJ2Sii0Z0kXbyae<Mv2A`9zVItI;!J<nm0qAs~f;pAr+EA~(
zcd>U)@_3mxx>Hp7Ii}x+CcT%|o_n#{XS9FDr_S>|Gj^TCXbE}!JM{*gV>$d3<(j~J
zkKs*82(Ekd+r}qxmmzBBiEG>9{9ElLAe(lT{|Cs>qt@I}#}P1&TL~%^#rXyv3%MlQ
zENW-n=6Q|kA6;WT_I1JFXm~77OC;I+vCCTOGIJP$)lL)QVA_dbT^3UJ6EWq^BOt{M
zde=D+?pW_V(WQiak5!Xwa!A@tw{_U!6Cy|;T~>9&+h{Sq+QFLn3U5)93oq40W0P_&
zqJT)Pjb7omReBriU6xVB2ja*U_*Lih?4TgNT{Tn-8;86IIx?1WoVDNA1?|cVSE&Gb
zMukyY%dm5%8ilW(l8tEhcybM(Hc2)cU=StOGJ>tiE>6a(I#=YlRR`jf+6YvI5@2SI
zY62N02p$rnC`mn}fOL_)Hi65=K{;%I;EHp#3$=zJ#j46S&r){ErmE8nNujjBzW^Vn
zJZ-Y;rXCSx;t9NH5(h4U_tH5@oTvjjY>cZ;q&-_^B1gQXzsZ-Ok%8^Xjx=U22N&ca
z{VgT=yI0p7wHIyO;+VA4F3BcOi)V)7>zH6!9)sDt^olIWCOoa7#c=l}N2T&{m<P-u
zl(8%ZGliLiCfn)?a-%y?QordamZ|bD>3GYBOWgl#Mt3$xnGncQBWUenU!B>y4o@4|
zApnNtQMDsk3R2J(zG7M6d0d+{M+Tj6;GoX3BJ&-6a$*)oezTB+tgSRe!CIY@5NX%$
zdCo0KJ*3~*pR&XrP3lcMxC>yiS_tG`uBZxHo{gRMa~fn@*haz5*Mb<SqGutdM@#k~
z*DNmA?5&wJEAH$)#h`r{sU#<4>kl#**%j;ZUzA!co$~yDOOhYBUp3gWOpL+#nHu1l
z{tabjZ;U%{m?_p`Ud(2FG-7E>4{uRHO_R-uNi?dkkl*`iFN`7h5Q}t!>LF1OZzaa^
zLcc@gK5NPaLfR?!j&ct%&HEWLFF5T<epjS6*9C<oM1Noe5fVs=CI;f(EN;=dqMiKa
zI`iP2*^^;9IXqUAJmn`2G+*Z+_}gK>+hl=iBRe1YW&9mu{p|;YI*ZJxpeET`5gg2^
z#N{~;PkM35)}KdaA-KnF3JflHWTRNqKmu5-^Iw9c@FHXXwXNrrsE<?Z$MuF2`_rn%
zNCcd}orRm6Y4>aNrORa%oM;0vz%EfuHG5;h;~!@pMosxr84fYQLr^q;#kOXudo)a7
zj5oOv<&R=49B(NH6;;V!4vO>S20l0up=amje_*c-2lf^9iP-1FFTfoT9tuY~%){84
z`Z|noYX4d8Xw3x>#rR?H^M1=)y2?huD#&udPrjHWU0eMef~VX*Dm0>>U0MV($q5zE
z#uedAd*HuH%8fH!G77;PwGUf36`j|y;HYlIY`!tr@0j^Kt4A?44>q0pDtIng5A|X}
z)O#tY9@DkLfl4v7iXSBhkRwoYYCg<(bV5wvd{vg!ygAuRfu2#+RP?hFf|jgblI`UC
zEU;Cg{mR2Mn@^OK1x0Nx%Mq@6gx(qYAjj9UF4Ujo*hP-AkjKu0nzxpX)o7kjbhV^^
zles-cHR`>g$A0ARQ(aK7<z-W2wWJbEXz^;f&fc_Db1hCRNbeI?tde0GMpxY*&E4aZ
zb6R1*yOMmYS&0PUwBdbVqmsOoj^mlzCd9c(VNgQve3#L6((Bjx1A}R+TBHhqQwjDx
zM)1SZ{;kGc5|o3O_Xl^hZTQSYGb=NfLT7s~Ii;U~z2Ku=a}aLt@q+rl`@#e&D1(93
zw%h#RC-)Y*&@aOCgt`-oZL(O4XjN-;ot`~XCkCas#{5o<i3o|*A{!pbH+<?--3D!N
zlgl8Z+D4BM-pvhw7^f_<!>$MWU?1+)b)RW0_Ds56@%Z{vY3j49cOyIU$^}34GO|)@
z#1ij#dK@)e-l9r+v(qkij^?F_WK3KfSS<4UKb4Oe!<0Zmn&jmYqz{wG&}H)JNK*~D
z&Cv*c&<A@r`&>gi8l-CQUiU=W|C~Zlg?TjcnhIv>jkL`6lpf?t58g3Ex-Tr&o$M$R
zuV8Jb06d_PArt(>UceaZ=2MyNs#+L?9F$9f`x3b(ct^H&3c%j#OM&@&E3+OYeE$0E
zE9}d=h2JfVTUurxI{J&152zUV`M7-N5Pmf3Z4Wb67bf_zb%!GC=#i}HJ*>2^{X32j
z+!y9AL`alddJ{TkFI`qPzcm#nlZRaMQ=h1R43_xz^7UcocH8o8f994&aPY5ibiO!s
z8RW;{8Ox`G03RV?Zz)Uy%%R8Q+l=Mg$(f<QhrBNCe^x;14}}#R+}z@u*f>AJtFgM0
z>RC>v)40LyY&g#c2MNX>|30ogJOahP-Ees!`VtK?ONV*G-aJQyA5wBSdbl9W40R2R
zDaKj2pnW<FV}4fFCW<W)CIBKArDX#}5Pp(3LlpT5@V%-aFp~zo&)vYTphdHA+`Bon
zOE*b=IxI%iW%~(u#mS=ozfwB%@@zh6xz6`rjLm~ZeolZQ7l(Kv<mddUmzJdcySgGl
zyr{$du7R_3+J?CQN$7N$`kx&#4Bq2^MMmv^?tkxnxVz2U9g=HdfVVNb#akharS;)#
zz`QkrA{5EIdSg2SyYFEeVfq9^yC(M%`j`Y_r0eU`-WnDuMXbU`+h~>trAhOkG2g8&
zv7R9y$%#3)2z&5*2nsk(1rRZHGxa<kZ9CWp`v>d}(FMy2%Q(hd6At9Qoj&vA+@k-V
zv7BxYdOMZpwenU%`z5k#OaG#2TBzqX@-O?^k;lEW;FayKJ(qapy!}4ru-iXSp?fGW
zF>b4d_BWrbmmD8(e$a2u_e6hp&f?2p(jaWF!FRn^Oju8zoH&Ht!YfZ^+kxi913aLt
z=F7q6Y=R!X5Czt)KVW4U>AJmizrJTFD%7l}hi4e7qhk~y?zMle68H(kQ22)?6o(MP
zgIH*U)0|^_+D2jNP0}ueFh}UlnlH)nh$$`nP{!vXi)r64WfP1}+z!0b(^F=ENQmjG
zOoxatoaB9t%9xDwU2|)F6t(jtz9gzd68NdocGz!jQUsGeb*!%c<zispED+F>qz9$=
z^>|w96@uQNA=?CN0hy-LhbtG;cH3f7ZHMh~HAevAC8i)$x_mOLjs7Zq)6=uff^{PU
z?f}X5EM9b}aQ=x^^!b!TI5ml1X)GCYfQ2JEAM6B{au^(LvIT6UYE2v^7#PshWhP_b
zVI;qgUgFf)#!|;^no6W3o3CbMRH(e>p77y^GCGk9yP9HD{_g}MpsrsmbUm)IYX)u<
z4u_wtMALNA-+$2-xdwZvm68KgTg-oL_B%PsxV3|rtF`I1J#BXUYoNFOlMfoqR_2|l
z^yS0ORdXu3SCoB7XTP=0ldQD0GiwHJvQ7;vE~=clBZtjBM-l_39VTT<VJJ0BWEBMX
z9IZ0<GAd3c5Q7>K1BEm=;ma(^k1t)xi)x2gDhJF0F<1^*k!z;nN(kT^x{K1ZLIV0B
zN9sP^I2N|cR??1xN&Nx_Xx6Y9-TD;xxK-0K&jgh$Ap*AG!lXV`%A$kzxs1pukVx6v
z4nflmdv5x(hL7o5ubJ&Fhy_><hmtJT6!2w|X+ub9^e>mKD;(MiT|5>Vui3+EJaM`O
z*u0qE^+6<M40MCd;=?p3<2JZ297@H5Xv*!R|9RAc4f%#XKA$k2`YXPrME(Ne-BS;7
z)=f@WrCz`t-nq6mhN(65a)q@zLHN_&in`Al=+8_wmDN8$s6u&1EaiCY`Ddn>FULZA
z?BV)TL`)jvtl!i52BAreZoRSxJ;?A}2?$C8JDvW@G5f-_y>+J-GEH#1?BCjZl_vr*
z0qwWeth1DF>5RE}<N|SUA#`7-q5Xh=>%y*R{|d+*KSt2#Kh5i<9-3a!!l3xRjML@;
zaenVKZG~gJXkRly8<DDP3|gAn?9g%*<(B-}o%Dr98R&1>y~<H81HpomjUPECS|$ME
z;z<x;dnh^NF=9bdm9;234xOXBM$GE$3yY);!4;*r%Z95q8uOAE1ge<04kI(utw3=%
zTa7tXr=j2`K@DW}7!Q3$Ymh>k#ltwOUzBgnd&qiB#)3nFL3(=0eCF#kIrJ{M1x~?$
zSz<gDXyV7&WW5LdC{joMb-_KGECKBo$TNdt>9b{Gs=K|a8!07z?4FI;E-j6epm{Y-
zHW=%R%NKX2ZMc;`f_Nwz&HrZ$ZkZj>x8ekeG*k<Y!Z-d>o~)DIT{*&2H7CQDZDLKf
zS9U#PN6^*$E6CJb=*YH91a&AX%L%*1Od=x`)7(x#p@<pwXCXVcXV|s;%?+i%p_{Xw
zXDKb0iV~a6aj;0D>mVB{_Qxc`pUBR3c_(w%j80`#Z!sR(3B454%t5w>Yb1l|U-Z<d
z=t}i)2>C2=-*`C$0ax`x{kTDrc;_5HGH}gR9n|w0{7ae1Gub<fA9mrgSh4(yGNlx%
z`BXNqv?^)bM-)A1p#`~W1j1cmK=9e@n0W<w)M0>+>@gg`h!^|@2~67#${0`-3$d24
zjLi51UQkj7(8wexF)%^RxG{kS9aR(3?lo;+JySln6;WEgYnGSzAi`zk^iv^2T^2Xs
zYDZGGv@49*;>VJW6vX>vQcmqu^nMc5unA6HqYK<|_P@(Q8-Uaj4J`q)<FNluH)F(0
z(v1D!vcq7KUX<*M2aQWOT^lRvg$(RCT#BonhEhk+???yFtx8CgGeM7fC>r|>lEMB<
z%RfH5bBKxh0V!dm)t(6zoCsCAoha{oKh!XN86*!%*X;`^S9B8mhTFUs+$?>@BgCon
zDXQ`1_14buAm_@(=EERq-Iw@f=JLzb>W5q09=O(VPMf0cfV}yELnF|H=sp6co3h<R
zih707@ABjht~ty+_DTk=R*r+Fmb+qX=N%gsbg9K^Ep47UN4@CE;Hm{p+8}2WNDHMM
z7MI_u>1xh^C>$M!3{DkHFFtCtd)9V`(C@jYQcED)2+z1Fbns#Z4=J3mM9`dhA<i2i
zA#Rn!A(n^7(6`0>0iR3IGHT_+!1vS{>S+sVG5SHP)#R)Oevv}K-pKU~g6^%k)5+*m
zHBkr3sE`{ES#9VAgDLg{l;5i=Ckz)Md8J@^hm}ZS^dLB&Xz0^0rP$naQ4}96Q6U0U
z8->pwbC7tfZP6<*?A36KBptXBLnByZ4g4N`zIbcvPgew`)OoD$GE}r<9gybm^2>NR
z%G)h_r&homKDzF8+8(55f(07O47V#VCb;s!@%$atL!6c$SO@W6lj$wT2hw8tj9B=^
zMG&a<gVE=gW1VOP7>HJrgQ5%R(o37Vc8vn`@WN|$qU<`!h!gMNvMt4n)0e+I{;nNq
z!4*Im;G&X=BAlZjSs-t7qNzeMPsmYN#5uR$*RrJ)8`h0Y0O~ws*U(zO)$AF78tPMj
zJzat7_iw(9gSZdEAoead$cIYiDE{3m4=?lI6oTDki<pS4INTW!_WyytbY!J}K$x@t
zzc6L;8wKf(2J-R$4g)EeGeIMvD$@aD6!DvZ(_wDf$|^V=BD9{`)nKSbw?XVX^}LDy
z!UrlGpE%9hv+3x-d)=?KrcP#XDez>-=_KJekzOefIKk-IrI$|_px%E;ieNr`POaWs
zVl7CK6kOwGrHrPxHW{ua`e4^g2bC)pB#NkS`M1atK|VT@20eV*4)HKIu7z=HA~`}j
zE-z}K@Lvo?9@W1I%Dj8&iLxI6p^yec>TCVRUlFqCf|El38+?`}_%6`hO7EBbuMh?&
zTvG$|U-I?(|A6x)U#o{QE~fV-|GzXJs_1^&H)D1Z&wr3r-f7++|3e(}JBP@6nf<?t
zq09ajA&)034<8qUZEAGCH>{`Zg`s=r*+#Klp9g-=nU}RugDtYR<S(BNP2GQwPphZP
zo_*N{J_@J*AVac=%8y)#T`3S&!SSHtDqV5#Bt^fVSBRxw?``$zyz-^1$_J$SdT>=5
zOU?G8=E~Xx%w0K4fI=XSX+Q}up2X0xHkEzsR(xxC{*u99o@-P@ln6xR`_JkkIj_1X
z(eU@`2~@YnpzJ~^-I6wtCd5&V)0PI~tW(nWRB=#=XXVNK!0*05g@4(K4wx>3fklL@
z$a_A+R8t-nj`GAa*Y*9CRI%Pp#9t<re!W)TqugC%zaam==Hu{ZaF?E^%mO}@0ESCg
zB8NKB`N*U=MGe|;sCG-}!e{?-EzN#QRgGj4CHOuG-vno_j$YkZw72qgP>%<q5$>U`
zkO68vR9!xa5?OwgLdy<lB1+g1N+o9;_LC(}jSQD>#eVw!0Ys`s!kYxERAVqqT2p*-
z>&x<X;sL8PIZi_}{BIJ!11^J@@l-Uquok1xtxsy6+tLo++B?%1W=cX9{ixcp`mH%l
zPef}m>zX_!CHkK~{45j!MmApnRkYd8rE9x)+9EW$`lZCvS=|f8(`mo*9?9Ll_7g^B
z^beKvPu+XckJ9quP-mwNy5Fly>L`>EW~MNG3mgWT!|II#%HNb2(tD(kea$E4B<tes
zM<ey=Z1%>VZ+74RHYL$^4qLzoe&SK4aV(EkjNV4}@(*4Rr-pB_fAt!#ZYIRgTIsMc
zJ|V_?k;}|T!M8IUjC#;(oQpM-+el>g|2Q4`^PLsrSLui<(mCTZ+<<(t&5LNYcQGzQ
zI<bx7Mf}f@69#Kl(WRD^UNN2@{f_xawE^-Wo!|Rf{6amKCH<KF3#5;QzVt!iOr|WH
zMKW55(6lO+z!O!|YVPT8z$%LczaD<WL&dL|WH+k*jMrqdhbpJx^J}qr2%#j=Vcp_2
zs*?vpyEk>Gw-zo7@8<ZvTLt3l1|_L7;hp>G3!T_mVA!F~4NP6m>HLX)I39eAIhS)v
zOV{E7IvV7b#d<*F&`2udP6lXG8T#7+T`dAZ-?4|NHsx~JnWR&F-yf{?N?_<_(x1+J
zJ=^IFqRNwg2loQQUkO#Z<6EsJv#k(9PI7-JQD9)kMwKTs`V%J1Ms^P%tfMK}T)6-+
z5=(0bYf3^ySL3p7jK$>-;rC*6kmU@A0#!_Zz7;;i+|aeK2HK)HS~}JIoVv+IuV5ZL
z8y%b+p5oQ@)egsc(K)9cQ!mH*P4B8rlc$ycwWIv)3TupRyDS^EvBZ_^<pE3T@9}gl
z!{QAQDTTk4#sqAksI-iR+jlH6=Phc}@-nmqypD(?vti?z7%K9I@m4d%p>NQtDwQNc
zpVMcppreZZbDV#}YCW+sy=BXg%B{1CbPx0)UdnL+R0hxw?H#iR{GK{yMC2%PreP=?
z=!D{%2yE)&{dqEmOH~C%sp;Denb3xI&REcJJa|BDxZo3IBH|fD=?3ehz%JZ5SXsf%
zs(IeRN(M4`qdlW1_xfuR2<t+Hbov_%<3BCeQj?<am695<F?DOu%7Q}lF%Md(W5czj
zl!`CNEK*;1EoHu~=h{Vy8d!lf0pv?UBuQWK>~J~*sia@yAt9EweC*V_`6IHrk&sb0
z&Z1HfZ<4%W+12gqxwFNsIl()<D;^2PS`H-4@nY3>oKm&#X(2WjBYlxR|0(6od{Q~%
z{dp4@wwV|47lqJ((a)6h(^H7+H%<yvvRJ|siEr}JYvzxH8aF|d8DNDHQFnKh{n%i_
zo=eAO5rhJS0YN7Q^oX#BYyc{vimEf#YLg#bA-s3&R1_y$C2TqE-cs7blM{lDbO6|J
z>Pj$KjI9fZKZ_^*HzM4kgq(16J{(_rr^P3k-4(LE0~%|9ssi58)2lGrDH5AK(H#6!
zH8^vKK_=<~Ge4p>Is<n4dm5*_!tvk2aB$P)KMGSQ%lJKzVZJk^<F_+`)S__{&O$AI
zBbkb0P@BZl%(CNsk2d|u)p~*%w`&ZQ=HF4b)}eeA@Ok|H9-CSYGaoKcESovJO>-Af
zP99(<xvw+f1W#!%1tW04m<IXIJa6gHI^-7?FAm&ebq3hDUZdiz{3jB6nueR6={wVc
zAK{7YM-yPanj=#<m?)n7&!{4K<m=hof1BylQ0oXTo>6E%+ehV2TqudUM7EL;D6ey<
z(u?zNYNPl<reP59ls+$)$Ej<y0qLV_9L!9@TBx-D8|ozKu*>X#Ehf<kky=xu)a{Dp
z_h&oFEuQ%fJ3{7@l+Gw-iBY%N6V9Iav*c{8!clucENNeiYd*A(A>|$?f>Hw{3Md<9
zC7t@yt>4c)_KvJ#zcgMg@ncZ3DVchHNkuXuWRz+iIZavOSxe4H9K{^<HX-&o3{MIi
z)7+b3`5St_)mr|K>4a3D=&sLJWYIA4kc_qVp~P%`$X!f2`GMVG?8tsY-B=cv#(iTs
zTj_rVhoDg@iMHODq=EgJ%Wv>%;oqvfDpp*U#)HUevB<;qW*X^{{~2aSt`AfmXZ!%l
zV=1d{TmFo=%vY#NyT|=56GdP7QyL2v9>%g_U<+%Mw|%4ZhAR6QD6H!>bf{Y7jnbyL
zNwX`pAp$1VEeV#L|Djw(Zem}*9@K*uhc0~oS7;=w!w=BeZdW9NS0bZthM8@01F`GL
z0@MGiCI!0H@DrYZu1{S&VX646)hc*w*RnqS8@YuwS&ZWZQ&QEixhg&HZ%&q5wch#o
z#J{4}NDfhfn1OeA2z$)t%J<m3-d?J$-uZN6_>ZxHHfXL?9?d@p%~vU@$LMXJpe|-f
zHA&6Sc^xTQzr-J&+Jd9})pveR`3<~6Y*kOb`NbNU(_(<by+|So(B$xS4Za^}kq6QJ
z@X!^+BfAq>n~3GpkhFo%o&g2z2-pZa*3M>`jUIK@(CFXW6F?VOacUgX)r!?XqPbSu
zY`<z(2RDwSWr&s3ttCX;nhj_s#J=(d5u7p28#Yih-4?sppuJ3>5S4<&kli>lC}=1;
z6Y<vUp0E;k)WVXMr=vNS8K{V?Eu^+o63CM>ikAmn738MKB?xO2@?X$$<B-iJ;^46R
zX7@RIrb|yFJBo<mUkRlfc{w7tNjVMu#8Y5OI^F)ulgQ(F?5z=*Q}Xh1#pS<neTzM6
z%U6Y&+ctHaL5JLJ#_TpXwor?;H4SC`_@*)AattvDY+xi7uQr#_WiclWB?v;&*SuR}
z5BAw}s={%@x@Fn`+rNA4SQPAe&kj4*@1?gr(i2pF-}3x#0OM(n%*<<#>(U4}PuhW%
zeakvfav~|eh!v4WJU#dBxH>x(+k-HnE(@4T6`hU<BE=kdb@G~}^k57bJPJ>Uc%JUJ
z{h#Rz)FzR6TCCuJsu|wq)7|2C778df&%cLp!Ys=nB|m7otL3EA8djQ&1vv0f_Gysq
zm8a&Tc<^$G?_M|1vl);PM6Y>1wRczq(7495M4x|sI)dRgRICdKXWd@w8kr~22gd3#
z_7C}8(OhoH^3YLP(G$5_oxXk2;Y99)sR<kn7DciAph3gCRTNUbS6oLFIjdZGHSXaj
zT8LW9rm8BV#u@e0{raaG$~hi?+s-AG0-<bsXw~$pw|jMCfJx9iw%`9oNX5QW&`<6D
zxmYRbK37s_ud-u}y(72KC3{ozW2xu2dUik2Havnv?BgWff)_(qFqnwbQ%DERnk)f&
zdU<9UI$r$3y`d5{cDz$@TxJx(k29Ms;J+^pq>hv>%U8~WPgh1^26w4PBy{wt-H4RI
z(6wKvcvMarmVyK-e@LHgWP_1wl>KaUo4knKkG%Vkb}OG~TH8tf@U0r-V<u({gGQEy
zyqL(87$8W4eHF+g@fIHFH&Eu9yM}M);s0F+Z1~dcU~|0lss7D`@MguNyJFX3CRiK%
zxHb<)DcH%C%g*%$qeq3@X@^cbX3>*#VDIdwLphaAGUO&_tgi_?Gq~RCE0DswOuMXk
z0%-5n8#-FI=)KiMTQdJ-qE65X{nO)Mos9HKW;a)5Wdq1JKsDu8%2z{A(9h(XlUlD?
z1nwP)8vdRj{+O-F`03Vq7Kv(0og9A}iD*hzUPTcZMAOfIpXALIlKVZ^2@(L99ROBd
z#p+Urs+3QIX0RWND)n7h2<+J~=iq>pdad#e3AErGYjqSCs3{dtSB3GcixJ;3Qp*^5
zlZ1OA{AjcyPwP7G75SA5Rj&RXjjRnr=eLWwM(n2Xt}^-LGFRcUGCSIY_5`uCQMq6d
z(ms&zkSRfSej}5x`2ruC7&+Y0bn(PCbiF8nl<_q73sT@5)ewVNt)x`)7P2EgE2%+4
z{qJPD0&~NfL0=Qka3cQtvtVg$P#YjZGLg<>+@|7QtGA@-Bn;rWB3P`T0EeE}Fwc_Z
zKUgfyZ%%}7W_k$!iyqPZzj+B8o`9p@ktiD3IkX^E2T8fR{{y)|M!!@FzF}sHZh45(
zs$6PKt<2jaJ~JGw4{gfU(+~c3J_I93F6LJ##@T%<$6=k8ka(?jh@%UpS@<1I$M>BV
zYLx115S6z^^={F7)pa(@!zB$zRqcA-3*}^S@_>vDaKPZcB8!lcohpdT)`p&P+aVI~
zKGU*-cY2QORUwzsNPFP2_>HZg3`zYt0;uhClX?f<S9*#~h5z8U&-5Vd=D2RsThl^v
zAJH4wMbFf5z2+NlE~<|r9bpFTxzaDkF9aqECb_hf&shXw1}LJ^jhN(l3HGd0;;O8=
zqtYT8=%&i83F((<0CkeewyqF;oqLLtDdji&3uX~el^JDd8TqXetB(F#o;zLDnZRvC
z^w=>YoXh*3@3g9tt=Sh${#`?{l1{X^Ke2r%>)f5nvA64|vdK-`wn{~~zyPyt-Ha_n
zSDs60Tn>qG7`z;hvx=-fQKkpyl*)_eEUhHOk@QF7=C0mg(*6>raKzinyjp!9{!Ac!
zKZ`A{j>Dman7zTpuIrZwnYS-6qEZ?2pv=%tPiQte>Dq5u1me|k&L&$q9<E5c&Z&nh
z`J=88zUIsV6L-XW;&)t+YgFotn1*{}o{e$Q*A)NitGd^@ymVtS4wH`ngAU7<*cO?D
ziKy6eMm@xzRwAh&U~N7aD?c47)DWWk?hfZbK|$gi`d-BQWzlbBJNnJ|lKi_?*@_ia
zYD~s!#u*0lxF&985OXl#t3`E713lR_M4c<4T3<-k^oHX?3?~i|vi!<vxM-+gyZw}R
z?x!V1H?Q-2zPl)Q@xKhZGvK9;wzR~|vmDD1wn+l%Sgm>;JFwSOztMFYMKtHR$Qsg?
z%vHNtv-^g#cl${~P2&B#qht~l+MriLH&Z0N=sT*a(lzNhWg<(`5Y=hlfVgoY&;p#9
zwz1D#@_!O%k{SnR4eW)92lNH;9^RrZxtpGFoE0j?=~ca@E|#InFs_6}m-PNHQRLbi
z)1reSiI9Qa&H7=ukF%?SC?s+BUY76)lE0HQUKQ?8&9oa-fUbB^$_wQ}5@~1I*a>1&
z5yVMkZ<Cy<r)6g{l-2BzLb*%*D-*D`T%IjZ!j_6xLY4(4s+@l2F+a~fbM*;XF&Q1d
zuWDGeB-lK5wGlGT!P(H|>ZM!JfJK;i9P!mPS)nB(8OvD!YGp)hSqW7Xzd<cvqPg{@
zI5Bj3#~l#LGTJ;Dm6rx6Q|+VZHIEld?JG}L{u?GM=uV_%e$5#V)(7fo(HM4)#Cw8)
z+ByXtl7Frh3S-~~U1WsoVobHz7d@g0MSGox3?t+A2=1~7Sdc|QIwB|mLeNpkwvbig
z1t71a?#3bH^o^{lVZ^8?cGpLtieKSZe)Bn;<`ukNIiYA5G&#;Em;~twGltY2q@VH?
z4|OS;5`iPYQ=tnmOF|or$Z8e}RV{HBMMFlN#8Zk8)on6F7>ww&6Z5Ex7`q}=4njur
z`UR!hRmE(HhlNNdiD4ZTI;m2mov2tiS~7(68b$L6l~QW-jNgu7Pn7Z%W!8Eo3|G?`
z!iTW-(dJV*mL+5`YaFaTq-->z>}v)-{}}ajF4eE>g8H!z=qu+}jK@p#5Gx6T@U+o&
zn(5=*P8HnExsUIX_>HYuXeXLq5<X=_yt^R-A39^%uJgr`_-w`E#p{bad4m0Hw}xlq
zUXsK)h8)4p{+qzV^Q6Q2<oAyw_By;OeBnHA3|Fxk(zXAv{(RXYF=NpviaX(Hgr)R+
zA>z!>gjn3!m+*a-^W{_+iwZ^iuC`XCV2^G4XzU3#X%Igj45k2FKGR0|zBxX6yAwgf
zV%ci*-ns^%iIB`FOBXewyU;hN;RRwLM4MByX0*_k*BB00Y)R&HB*Uh%5t+MJvI1RM
zYdu+BasbE6R9AU%TeEn*n8SrHsNRRT6_cETH8-k48yy28V5C5lkldY+8YhFzaup<U
zsdYZ3^ij~C&jkuzYg%YI%_}XeoR^Doj5yPCxy%Emk+gLy-;{&7tl1}ga&*qS+S?L9
z^qJt+t;IEI^!1?DES0Nd8!-b13RAHb31xxm$nI`fcdZ<m6s-6as0Zq`!m+L*Ti0OU
z++e3+$lxB7RkEC6@`peQ7+4k9i1>Fla=+`RgOGzFuC;JsyWfOV4weVba}R1FwNlw5
z_3&&cM8p*>SSL^YN!U*kwB?wST%1nZ0h(y<h!c7W88!u-a5hlWI%J~KxxwfgE`1Cl
z*ee$GjEfB-IRcMmNrKWOr`b3@*{FC!EFs;KS!@3p7eTl(4(ofIvt_e`evs@@av4Gn
zji#C}f>I0TxqVL4wTy;Rdt9J_GZUWMCddXMi+p(*p=|4Wtc4eGSgj3cM5Nde(-$4M
zSEay@+8?H#VW#>;cq~#t3IPy2fVh*<lHTrEH!_eK;R^_B$&Zyc)|G5Z4y00vlfQGL
zuUW(B_jl4*oGeMZUV<2|`55g<PF*54<fYZ~a53hQlBmivLNV)B+>GP;4fwbPPApX$
zDd^C|06rI$*H5se&jnTjK4d%)(r`69YO_i;A7Y+|tE|qSE<i_`N^O5<?O_r_!01<T
zdS_qYUgXajL))CQeXKvKMv2AF6o4K=Np)aIl|K8P4&Y}$)O+%RY*?3KIkqBYAttsf
zFqCY$U^=H94ML=;Vj*tM7EYo-9gu(nooh_Ak$;wEBnz#1YMu&CP&$d-ViCW^cn1#(
z!y3XGGVd?C&zTtC-0ZNP?KMKhHh-ec&0?KyeWx?5+n#?C27hV9M(c(OIx83Vv@nse
z^h?|ED@}G_!ej|ZeJ2N9=+Y(OONp)!T@<mK!CzFms4+7ZH_(p9kIQ!u&N&qY<C4n(
zYKX=;xKjA4j3^D723TIK>kvP~z3GK7u$wE^CXH4VKmFXVLWBie%_2}^cq>Ab_!r77
zDP|M0iZL>Hu2<2kla5r|)Ebsa1UQ-Ciee*JcC);?HuavcE$c2;Pplal``OBWQf^=d
zW3{$yMeCw)VOS-;Dq9C4s`lWsu?8KiV|GN<eTJZHJPWr>b1D*@+M-dA9gEQo&5RjF
zIwTMDqOJolCxi?Ww<~B0_H;W_K7naVTLEA0!tcZyX6&}AX`7|3uM-Y?xv_aVa;ic^
zi>E<JXMLoAiKb>;lVq*5F_UmHQ-ouWO-pA_v|UVLsmAXgK^J^IwxiK&%5t{#9DPTr
zL#URpF+U3cs_QN4F%;^y@*Fn<PhCDqPgVyx2BL>tsI-{?27N(Wk3cst7*|5K$ah|2
zLB~ucyji3Ha$=Pkmj&@S&CnuI>5THouNX8yZ*F&$_5IdUb4>~lEM*=_wjH2MZMv!B
zla()$PNg~?FT{@~!Otj*BQGv-4!Clx-@osZgM><r-l+1*bD=gU5R%pAvqd#CurYP(
zX12>_`sXE{+V_5Xn9<!-cLhA+W2VwMfiJOM3YT*{h(mH2DcnTI+_Mm-dE-EM<TfA@
zl{pG2K+tNAF2wqtQ&pwYcZt#l4Y3}IZBZPAUGp6sbWOxt)SE(r;4n>Ft=6cvj$#()
z#Vj7uxTGu8l;fJtn7X1D5Ny&sau)IfkS~o60^DZjlE>vwhhc#OjEG2_bwm+!=1}C)
z^B=xRCuA|5D}O9i-9(G`E%@B!XHi9&-)}(aMzA4uZ`XJ^{SLiRkyq}Wppo0(N=W4j
zwmi;@IbwuV;1b;-e?`ja1kHD@BCW|@NgcNNlu?BycRCc4jF*yf4ei=kf9uCu%eSaY
z*XGi5$3l=YoF({)#y*V0PZpjGJC{e#HX=ztt{1Ega<w(J+S;Bs1x5QfwMKD8CsxbQ
zm4%=BXifCIWb40ybw=KDkQrp2e#g72SdPS5pb^#_tt1`4ANv%`6cJYNb;RtIgz6iv
zbZjYyxuZrd!&WB@{?RVeF-w)85#lS<$_{2@IBhcq;Txw<8~Bs57i6SM_N7hs^A@-O
z6X<B?q)$jmMi+#w84Yg)(OO3jz=jKDk|PQ&4;Sx}{cXR0xMrYMxa&23O_|WqQ=iB6
zoOe+8jRk&fxLXR7zfiz8(AR)%KG6G9J|^b-et83{9l4TW`6-adz8FjKc2wQ1(bx^=
zTARvlQ)HJ52w;8o!dysPUFL~tiRihJv~D!a9U`|9iMqSYZL9Vh@<wf8L=v62kOkXf
zZ^P%sEceFG;sReKbo116Z03c0H*TgW`GPrPqsv*YpCL>j8#8UKT;=l%UQwRej?Tlb
z4XtcVj67F-9P60I?<l1ToGM$Cdgb_cb~3D0?T}&I4#KDH1Bi&iP3-Rhtsvn{69W`b
zmI92;3Dw<l;K=ykFS7|dC(9|m3PluyF^6g60tGY8ngervy2QRoHEX?IW=-nSzlbg3
zj(#ySe&Z8Vps}dYEK5nK84daQIRe{SP4uQXbgMRWO%FOy3#h$|1_W^{bQ$dtMTt15
za=2+9!j4A5bdm0LFowWH?fcX0OBYYr%D*@Ap5O_9u)Yh01x0XfO0ey6!7Q%`!U@yA
zDeZ-Y$V&|9kn*&K7n0OF2J-Q6$WKD%r^ojh96gLe>IH16ki%zF-l#Z2bBot`GQ?Qw
z*VPT7diFck^^7SOMd-DhZz-OpMaa|Q)l}ut8fK_n_Kun{;x^J>7b4Kk*Ond<#71C@
zouR}<K_1do*ss3lMnoCa2}Pd{Bu;)JBwL54Vf14>`fda>CMWCEhw82AUI2zoF^`Ds
zyka)djNygM4u<}`r+17<J4fq)%zH2vXJ}X(<$z)oB9QxeebG?Zlk4s!MOYsmv}G`g
zBqpb3@<k7$t6P+Q6QaAC`K2dBTVZ(1^Lf`3XJiN`(`yCdp`J`^Io%2jMFF0o;bQWi
zrEvbt&UV^`JbYed*r3Q!AVbnCEjRFxOM*lHoq?B8{KaT5kO_1?ogiaeFA^6I9n?cC
zTpIDx>{yvSMn^Nb3gO^zcI8OmdIdTS_$UZ8Ma+(}*2Kw`PNs7C<i=!K5N=izxZ?5?
zyYMJ(wiUlDA0@Mu266BVyqM<_S!3uzvEUe@)EXkVq7>JOIi3mUMbs`%**)Dh;>DS^
z-mtn^=i0u-PyC$EGA{WQ^@pWoIruZ4opq<r#H2LuTT(hupHG2^u(e`DvLd&@wFVvU
z+<3dNSUh0@wcLd#s~O2i^#i@9n$aoS{If=vwPvvsIP47&B`b*`-<0fNw~F)2M5~WD
zR;{z2+**nj6u6B(HX=)_6|&fMPdJU3|D3}gYzNH(H;scOYpGzz8?)S9h3mmO5Fo^J
z7CR@cab(wJ--uv7GE`12LFjPfMWWiRK2~HLecRvKGkX5)l7se^)2j)=Ao#^Z){bnK
zsdw7U7Yjul$N>7M`r=UvPZvLu{E<;g2|F@gCmNclEjH!oap3X>Ar=P;kSv((I*ki)
z=eVS_t@>8UukE{hZ<*ulAv2_&1lJRT?nT*L(#6yvY9dr%N@NJFWnLa6)*gT?Zbu?}
z|GZje41Z$-9bR~rM+C!oJx^muBi({B^?V9C-U;unljn%I-lckZ@CotCdo7MU(IQYj
zwe7qj^TK1e^U7T4Hqs|E`-~JzG1=BXy=EAXZ>N)SUV0C$;n&Yv){Q8i@Jrw=5(VaY
ziAzul3Fks}Qv47#C@H{CIejD1a7OW<K1lGuEo8-+7jzYs^A%N7w^2lLzEUYK$0(y`
zw<%-#d&Wvs)tx4`;ww*A7Z^U+!Uzsl4FG1=P=I*Vfx_LMPd|3|>eq=5o5Y*QI1Uau
zUTI;`T0+zTTqQ5c`;!hxv`z)w8_HlQs;9y?+{pmop)2${TU`m3tPE)rc}m2GA_Phr
zBNnpE6&F{?;nU!$^v|rf&emQ}B?a8k9>T|b-e_d8v2Qed++(SFx15?+1TpzG&yBby
zvv&9y$XQ@f+l*Z-auMK>=s{U2|M?DIIGAREzEI(-f^KJ%w#VBBmO6z>Oc*Wqufq9B
zdFz%9E(s&-Urter376T(q78>1pB;kai^c{;Lu4)YLN?*~@6)&09A*xM<ve=p(ukQ|
zxYFuxh&pk;v|Oh+_6`6guDYsN8tY&X9XhulQpDyj5Fa`P%?LlsV;rlc6MXJhU)a&K
zJ$v3qs<x9Q*empLSOZ7IT=<k!^d{w%w+d@~mmEBq2peCzt^O&|I4+5~h|@OCHuc@!
zQS=~!Mkd90QD?YoOF6Crt0N37UfTF<i(z$tyB`c&Fn!#CR5uk+-LmophE;L3oG!9i
z&O};_lWg$K)j||X*`u|B7(<~U2w#+osgZ4nLsZgD)Q%-8o_at_&rcj=I>7>RKr1Z;
zoj{iK6!kbUX2>2SZA>fAH4Dn^YSQDC6cv9!jyMO5l{zF*+v5nP4c}QwR%IC}*3?GJ
zf&r97IiKS;XRNHE0^`!bItSOYZ~N(SepSM|9*Rvr3i=B#5Tzfi+itb1hv742CIT2W
zNy8w~s%cawF<`_gDX`CNB4|oBpE19na=pyyRi~l$x+x{0x~b-6lOHN|#^g0Rfr=ff
z8lqpaZllX(brS&FMW}DX2Bb#yBVDMDLh9QI1%eMpCZ!Sh8?i)2H=R)eO1*Su#52Zw
zAWC#Xz|_$pKEgdWcQ=QGWUW0tgb5sl3dS|sY6|UgigJ_4&R2Ym#zQO;^00;KoUJ<H
z)a;YozGtk=y=oyn%3`%6!@akvJ9P=PaTP2(EL;^SbVh;T+q2WuRDz^*udBj=a5lb1
zC?f13yq;A6x6v&rTtB?CmGuxEh*2+*UqDsu9?=$d+#QA@oMGSL83uC(jr<xZ8MXut
zPuFOCGwxle9p}=bXfrxdGK)*zMNp3~1k9h}Ai{r%aTbQeH%N@cYyl}_D$>hc7xTiX
z2n4_!H0N-vvBQid#xJm@HiyncA&VXZD;n&WE3psZrku}e30_@+Fknn+O*S#Enk9?{
zE*|~FY>6DN2J{RkwZX&H<*}Lr{z_b0+CF&LT0DGPa$ZE@>04}_iIKMm`%-$uwHS1$
zxrk_o?wbUn6hNt+O@hd~Xb{$Waf^0*;x)vZz*zHDdDvD?E|0qqoSIt~SwN4Xmbat^
zwKWRdT316YW!EO~cB}7jV|rm#{kCGMR`|_C#ZS+d3syL;i;CX9SFkN959%4w(Qhka
zq?PKj2>clXAi@B8AeYOE1!Im!iJqX}(Fj@HKsul)S2x4n2?zT^qKzJYN=$Hq?T>DW
zNX}wbM&EHJam_toJ_aeKC|fXWWCM#-sah5Eda6!L8-Q%}Xz_-_^ZULPo$#XjAY~`v
z$b2(A9;Ty{^zbPCFgQLQ9G-qmUmYFeFVc6%N3V|uZ+q$K5&e7k=hNZgY5Hz>{C0GD
zI^0iRe#G*(ckd2HdxMt;!}MVA0TuoJyf=JzntpgQJWP-90Ut&u!}R2IfL|FMrXP++
zr=!Ey)a2gLyN}1C*Kbatp*Ked`@>_BRs0%yKwnMY4USJo!xQYwucQ5;?^n7tIDxKj
zr5{G8Z;sxd+6zEiN3WonkLjOAhx@&BIHIP8e|~p7JUM|*K<lHo(CZ=ma&)+N@O~fq
z(@S4M8;3`y>A?uz4?cE!g!djkQ9i9tzz)F^-VTrV-oQTxFGmL>7&p{|d^I{fgon@=
z4!HMw?+*sYc>KLTes^>->~oVak|P-U<I%~VQg{y;;(vZWu%=*~p_R9T!@VIs&AmA^
z22+NwoqjxekGBrI|G|DVI5=R#bbt72xOY1Gb=bpC!h=rUza7fRpPWLoIDrQT>EUn>
zdObM)n4S!ee;w`7cpMMk4MxW}T6;&w$Jox%VOU&0^to)s(vAmO{Sc0sLtIzGUvbsE
zKRm#3IUfG=dw6eLJGGUA&l$Wv9@4<ObpkDY7(o|tK5e<kV(HPB;1^-Be1wH}l)gRM
zAHBk9lEt)lbolG=<B3eCjuDJ|Sj>Z$M>tF`p)(`u6Z8Vd3}<qG@OJQec;Z$IJ{8aJ
z;o<OjaL`Ln-VOIg_!syDtW#JN2Rv|xC-BBN+3*8tCLO@6V;i_=d1kS;A2tat%tKvH
z@O=E4@9=hbesi&=2S+C-Jf-`C(?Lr8hX1}C;^&WthcIBY0|$G1?~h?O;wSJs(4&+0
zus=tKJTLgxbOel!_i^3I7NiyZYA`x@e_UUX`1B(fN^F#trJED}#K{isC0q*W=oLI}
z?~P1h8g2ED=^L1omqYm2VE@+<ZB}^_baW&mL+?m!$cTnj`MW+lxhS?|EAymLDp$V=
zC($u!)p_{gX|%{giI1Z~Vw}E&P|k9(v!*4|zHkv8^T<oBgq+`8&dEgvlm|e?JoeC*
z<dBlv#a6nsmECBu8nP)*ORj6j0=wTxZHF?wGo<-0r^p>bbop%Jpz&XPE~f4cTH=m1
z2VFtuQN3a)Vu}YO&^jnup#ed~N5aG`=WSHoEq`Fm()_QH+YNu-u<qc128<z{r&_l1
z5iid}u$QGHRV}Y83Ui`ReC=g#SayI!1tni8?{q=6+Qf~57_&k(*rJ;Gp5!U31@poo
znD>%0S_T@ItaY&<-`~rmv(<%m1r@omPEk;oXLFZ`5<}Lvsu#4J3SP8_MH-m|+=KC~
z<(=k=C{}nxeqEKF^DAP{?fX|IZM~2>FM<xbavoL*!(^~ZSy0HEY&^*uIPTe)h@RS_
zMygASfsy^M{F~yQZH<HW@s#~?RL8w8DTKojI%Od{Um9CCzSB7x#BSOBjDt&UD9@%F
ziKi76IZE?q^CCaToMvW}Z<3tq|6*KkYR7Hw?W8{=Pv|f33~Hp*(&Jyk(<$<D9bj3}
z68K4jv+=|i3-w(s{m0de?b-jk80c9QIXza3*zHa9)W2%PI08&ct0TALTKb))%hm55
zk?`Usw0Md6KCK>9{~9(Q%(N1ZqYtf?Aznvn9lkL70HhpZhGfY&gi}uIL+d6UjChxY
z=j^+aJa-k_cL*eCdXc?+&((+7Lca^FW+F!4-uet9{&eJ!VU*d2g&l%0r#$`na<RDn
z>Fcj=Zf^P)vt_@WUwo}7udjcR-VG4zi?xBCD+>9T_!y?d)R=SnD4v2L_IWu&(ms@_
z%B~T(1}|Gf*f<{8aTX+exyuy(T^HyLoH6V-%gC`z0z-owv7+4Ie7_mJ(_B;>7`>~S
zBkdW6xnHKxN`9uvCEg&c9u^e-I0>N4>{+^{5|0#Q<SNfRn^e{h&iTTP@i`CCQ{nQY
zasw7wV=<3a<uVOIJ1kU_r1|HZSF#VtB+|`umM<29Yzr0aD#Q1JmW7qMe5)?COMJJJ
zO@6FR0uCyTTMolmt`H?88G@i>qZ+aKe1}k#==0L9X0cAn3?sW6a~|qp8!Wi30Esct
z4djLjs!lYOj82KyF7Am)#F(uw{DFAew%K04JD|-1t=+a=64`@4rGxnbLvQ2VXG!|x
z$rBd+)F0|r-J-#RUq5+=Xdx<XfFGQSSh5z!;=!oZ%WOu3%hkoee5xI+vUjYxpk=F+
zo}P%DvQ-g>E9?!2B9vFP5(a=Ohi+MLM*D9?5TE4=606D;^s43qOeb_{nyZM2>RMN|
z&&Al&rQ{I9g^;jyDIaDK7tHH!Io~DA)zTs9c~)IAg(=ntM9t#KkVIvDUekrw^1eZ2
zh1KK9mORz-J@VL7I#HvPq}AzfFlAbQQXgg6r8()yQvrpML^hj*?~jEm$hd~{-v}h;
zd*7G7nz-+;8fFch7JQ`*;<++)u{V>?paD(N5ssnB;$>yvv?eU6c!SmicGalIYwIfW
zV$m$xCLOMSlpw7)mnDTf3%1G38gROma~v4`XXU_g^m5ud981(7VMO=<dP)}q9K)0`
zI%7q|Ypvh%*coVmcHg_W&126(E<D9~F8$_07&GSn3d<4$!=;pqKRL^)g610;(leql
z@1>KaT_uwE!}NH;cI0(l!bOCtCd6tA8|sN^A0xXEp1gFni%;t73H9+sNT{`}Ml_(5
z{7Ka&mXbmw>azt=B$1*9KAk0-=bv%~WH2XL#xsDP-i{0vT9nZ4K;ao%Ca2C>PWY_S
z4qiB+(t<>rpD@!~&k<zJ?L0fr35WjKm|np<noRYC!3MAcqlGFb*;AWHHqwx14vEO}
zhVKU>o4CE*X-i;?hHlKWex%mv)V9#>=ukbYEUS8D`GWd3wwpjVZ(zo9WEc&Zi^P^z
z?u4U4!Cqb7OgKn_8gaO6<#>D^-jJ`%v*iWxOd@|mIbUdufPUmeeWQ~$;lmGS++?%Z
zh}|!lC426vm*e$H+_W+bNpv#F`G!NyAr)Bs0g@!VDA;6ubotf34X+l!MS^EA9n8i=
zh$<235rs&Rp<LlA&F7M7iNvt*i>!%8e*HxJV9DL1RYC;?#`2{fqn7crJ(Yp2DVt2n
zpkQ%yIJ6~Yk$^x}mF);Yyu)Xxz?q!5jd^iHquN2-SbeYeyh`+SSuq+hD<%ykH3X=D
zHE&KNRvZK_c-7%Sv@Ud3w|Lx0IWrmgU`3~>U8yQi(2wO3p3+|~`|uxX?`*}22-;@j
z+9LcJp&=5bLGKu+_6?iIcZaZZDN;UY9Lri_91-*L$ci)aY#Mu44H{Y;@4zV_p^FuP
zS`8->#NJ8kmq4#XD<!2#urJPGdWCO^0f{Z&HGXkC=;=T`3#!o3I+O_vqEO(mEUDz?
z!pQ)3^ihej;U<|%TtW@sigpA>V8~^u!tv0)mxXSNmZ)F~y*7+PMOMLzX`D3F)OX=n
zaMy$LI;yraA>x&Vb?x2~5BlDnH*Uwi^})f;#pkD=Biuw%FDyFT)}p*%;3C7T2)Zdj
z^lhbya&uUE*^C`7In3v|wncv5`e`}au>kT)L-Ju}Y%&^hOqIf}5(`-Q%dll{Mq7lg
z;m*ww{X)3TDCpX@7^T<jJCC^@&W%w;Fkv@JJsV`V&!UmmVZ7T2ZfIeD-*2dQ#tJ)T
z+Zy64dX^!N^o(m&1I4fN{YCkDDyUO!&+Z23aMDg`58^#W#$iMtv1;3<wX51h&YXhX
zwnX(|ngc)mPT1aA<#@eCSI)i@eWfzoNHkKdd!4Gjkh6GERJD$B6{xc4D<q)2nYj@{
zndV9KwWp#Ph#4{2&saA>^?P>sNMo=@&sG$Sf+^m4AtW!Y2yRpyo|F9`L{~C|Ef%Lb
z4^!ws*P)a|oh;~HqIZE-cwPR`rw|CD`L7o(2N#ob7TmjHcD>Z9AdzF85EVNZ$M_pp
z-`{aq>r_PbFXu$m>q|+^@r=LD-V=JXoa<B1mGw&&YzyX+VNwb)RL5v2E$MG<i8`t^
zzePsER;lAdxOzW4R7|q2k@RzsiRZB^b>Ca?s>`eEEo=?`jtgc>B@cpVg^-$@f$uP1
z`Bhb1Wfw|{RX-!NNRvLJ6v#^8-dt>LM~rnGx!wh&3O36*A%$&@V*Z44_>xx6rr**4
zf7gENCPFZx;5_Yc{ryDmrNc8zVpH#T{d5m&rspMk(sC!zt%s^KD=G0n3T5{hv>W)E
zn8GQ(#JglCtahnE;r%fC6v{kmmWPl9fz5HXoU#gPcm(U%%?rNv#7@wsaea6oW(+Ha
z2VEiz&YKEc(e*8n%_TMBOnI!^qWwx6H%w6aLo_p(+Vp+aDUu9m)Z^fO`NDdxM&+o-
zdBz-S82G!G3qc5`b3@QbTjQzweLo$9Gp^P1=1hd_-+0NA${L2~lRzxca!gvmrJuaY
zPQn)okM4;JI4ddIx-bI1LQ0S{tK4=IuvRPrp((a(q~sHklQD78wl`6X>#~ZcKe^A2
z<q`dnPjt<Uc0`_6y1rB$6*^kZxh@F3=Mtm9Rwh-8Akamk*>s7GxY{bLXi`$fIwLjG
zDxJO=ouuyudw&|dCX}3@(Dn^_hL{AOWE6~9dUTw$fW{)UnSPA`JOjiu^gPxq=>VIJ
z?f^EkRHS7RaGZy;iAzPies{3@yd8HzxNHVCK}#<WMtji7z2V`>unVVQr{42k`bW4Y
z(q}*Z_>2wHI351%$KU_hqu;JcE01R5KDr^_<A<`@CpgyNe1(sLd;Y38hkf>HS|a(!
z%d%SF7v2uiZ=OGU_Ra3IZ@+n#zCRft)JRbiMdfy!YUssTgn9^0Q*A}nLb{5l7#%rG
z^<kCztf9CL&BA}8qz;4DBbqrvP1vH%C@U-yTDVgwekesna3h>^MH<ENFX;;b6GAle
zFIQ4bh7sj<)O`{v5cq`95??s|sQOPLLF=Byq#N4p-Q7i;aP_L90&!5uQOvPY>c=E1
zyATQi7=9%(pDoDju#ld*y)U&BQ6&iFZCUC~d8U~pf^JFXwqvIL6Dr)M?{(G}`1cFN
zFNqEL0TPYOyGuW+1$eYd(vLX;j-yI%e6E>lV~zfeWDRa|Jk_#KlpgZ<kskgkBOOVl
zD#N>vC$h&igCwpBuX(iW>R#1YhP7lm#grAL@7IajV<Ea7gPgWy6$zJAqRf&^A+Fis
zqPpDa1@lY`vAh^b#JZK(HyOI+zKb7nHiLCUXwIRR<6Nj&64I#3Z@9}L8_v~w(jJmB
zSi_T2L0DK?VX=l&Vk2DS<Ao=#q}d^5KpoP^Sml^*IX^2Vi4vU?8OBW17+B;{B*7^x
znN^=usG+g~)=;s|Y2>Q@9Hd4dlMs(bsq8RjJyF`E{Ys(hb4ekzO|2hLF0zm6|3dA5
zTe)Uyi^~3@seCD@P13rOE3uRr2Z_PBTw+HBj$QSBV)Z5JL*tigs~eL#wC8$`Y17sk
z*^q7>63yl$^rR9|tt*etld$WG7Y`vplQ2iTvGcYiBYxWrX8ZH&>L+Gdu{$;%e@Yb~
zl?sDFc+I#=jl;JWlxxOcGFCM%e<PlmXtpEdS@cBhIzoebA+F1(E0O%s`>3=T1{`P$
z+(>C3jk_#BNtPJ+ksLaT#Z@*deA<EyY``sx2gUbMsL}Dqv<2FQ`U@YEPX%Lux<yo|
zfjvz07^!N4yfS_0VVLF)or7W(__SJ&h;F#TX0{5ITLq#fI6`qI*HaZzw{UP%b+XVc
zXk&@qSx?bLT`uC#=Br|+0fbd_c5!hZ0S9J8ygMUSN=(?TT$oCDTKcpK@$99u1v$Gp
z$ccyNTob3ZG(@Q(lfkzuwxH@!mAl4*-ZMI4YGmC+!XrRw(PE;#rR}hcNWMS}kDRC^
z8Yrk8SVuJS<o*<rFtFj)cQU0cW4WVcDy!_N*e1(LxZW4xb5d#U%(iP>3spz$*?G{j
z>eYg=xGN*hHjd?Yn~t{_<ZbY1@(Hk9f_#nr(aGuY=;eF-6@8HFBlgJckjJ9C6R9o)
zb4!-1@(Qvg#C4!_f&}pdqu-|lVyC)}3N9C>8|4r(NhgI>N3kf+#+E?4w|a~u=_Ou>
z72beu689RRsy0iv=xrim6KyULn1F<)S{NS#WXCH@hIgK3H$Np-*i0k}xHYv<+O%#O
z^o<dfB)m_++p@PJT9vibqnyunt4lyAo7I9yXxYBWkr10G5_|RyiC383m^#j`5`xcX
zo}YBfKYt5tSSmb~ox@7vT(Zisfi1Xege!8ubTM?-2YTnueG_jRApuT&v3ab2WEyDD
zeT+>ppcBc0WYJ_}mgJf*XN@T+l%ASRB~5A4DO`&p%U2R_{8QGp2n2t0Wzd0JEI2>c
zSaXRzdmE*3uF-ts_}C@$g`3VPzG_RKQN7@UDelU8n=jFJ$HpY1B(Wx6uBvB`L#o`t
zPp(yWU@@mR$XOu9Y$i0qB`&AQ`xayhj?i^6UNWx;?am+|H4Qb~rQ#&GoBmTt1Hhv1
z(Ng2{BK?%-*SJM+Er^Mjgt7>}<IXwjAIs9rg7n;3rKFr3c9gag2lX-6vk5gaMV%N+
zV$kgfwOy-YZRF}gS`1F%%T-0<)4a}O&gx7!1nE9%*Sr(M(abAnz~No}n>zpXS{?@n
zY9eLk?W?E8pPQ(95OLCCmWlh^c~DDcR#t6fv9gR;j0~B_D!}flIZ>E%!i8OJ=>dU{
z<qL<Osyq@b%F3H#5$F)j_T=OY8rm?(s|FsZ62OWVOp0+ox#o9fYMd=>A@Zl9Bzvtd
zM%WQDA7R`|t1cJ!S#{5D;2O_`agSpCCh^1~;!PY^G{@WseUYqqBxK{#s$gvqo}M1#
znNO5>PE}mezzcQ@?`4$rAJwF()haL{_c@{PF&sn=hta}F850cw9K}TRx{5~>*DU>#
zYNJq5PtIx1agQ(g`>sh5m6k45#1X~0G=h&2r)t40rdB#IQ%uyXT*Ar2C~zl*(;>U)
zj>C*wke_tBRD@cX5(93wiq>Ea+@s&v3E>fjbT>ehF7av#AB^3I_K@7S!m6wgafRk%
zwPfwY<Yt0dxII)!rJq#w#V&W23ofF$#n`T5I)uW(Rs>IhQOmk<7apVNU~*uTx-}7C
zxZGr|H37+Ln5H59BsY#N-B33{yM;X6Bxc<-rAWn-^LIo-p=+=9`0^6s219_Xe4fu+
zDTF>&d>3;*ij{Z;L;X3gjB~P11WyEwthJ?C_ekC=32$Jy$9Of77+w5u(GAxxBz2S)
zA$P6a2+P68j*;Q`J11#eIt{3jviMRX>TSxm^khnEqi|DK$ECx9%>^~1D<hZ{$hPR_
z(u34AUD8#;Q5USFM8B5bEEakv5=FesEhKje-|e}4#-dqnqV+#`SrLzZ2tAU4TP>0(
zRE4+)auOxOX5?j@vVM`mY+aJ$5uR0W^_B5&Mui$$VA3|`&I!XHvX)GI&g=Z64GU^C
zGscb{fm%G4g>O>l@lrCfrLCl4pV7(b$)Vc5w!;|J&*gM^#V9sZ!7Jwis*B!|t>$nx
zoz3-Jbp4a_G-5?<y9d8rZ|T?Hqy7rykMfnP_R{m6Cc?1}aBR7y6IY&3y?8G5^c_~$
zq+~|cbuh?*Aqfk|;A|MAaYSEMhZKs%6&#re=NiW<*4U478^!O$fMlLWtxZBw?WIPd
zLVS|cEy#XD1=XIn;hL|P*(M{4y(gmIWSA>>l!)U6u$*V2#$&#TqhRfcK`$oPtmIlb
za?M5C4$UaZ!KsgdcVs?SLtTc?uiu^&YT^_mBIH^FbH;SVev+c;AX`x`>buQF_cX}M
zeA!%#yOx@-D|9~aL|8Ow&*DTGKsL&Kbi6oPG!&xCrqG`mA9iZ>NdB3_4(BXX*#$<S
z;Jbt;m^mqR5_R4>yM045I^4|K%vNAc8uVm&ruWAg&qA<tqNu@nIBm2(heECBw(`VW
z#Zo<Z+)KQ;Q9?lZ+gIdu_?~m<&(4ENm=5Xr{7}smHF`Fs0=p%8Tt)DERCWk`8&@Y2
zDu08-hKiM19ik%k1mBX_HRt$#g(nzXis>}c`3NuNNvIepN<bGRA5kl~*LWqreJBy>
zD7Go*$fUj+OEPQNe-H8C5}8ym_FTY#3=iG$@a?|};H{jIQM)aOH|X>y<O-a!B|~Lw
zJBAH~du+}QaJ8ziE-TWsaT5!^R%Ns$QadTnO4R1}JSDXuWP9MeVO)5m>^#~Linlsj
znOacdXg=vc6GBhUpEI8&%i)qeY$8Je5!Yy;u@co*Co7hVb%;s7B9LpFJsKUL!h9h0
zb6yzD#Z<4Za~A(;cA^%Las#5~g)5KXiV}=8aV)6kL}Pl9k(0*;Rf`zy-KA)gSc|r+
z1KrQ3ll4nwYU?JK?abRmFnd7-v)7QpjKYtWAynK&F?TX+K?f7I63tdt$uX^65Ry*#
zKjKFTa(Oz3QVDQJMamu$myUz#DK8^|jL<pkIP&;dp=4{Pe4|7T@p$i;Aq+Mt<}c)5
zs)nK?=QKqOfb#@MrDUp(chz)EVo}G4P`_a?YhbN4z`yf_qK^`-Rov8lGLPJ6dx4}r
zlASUQKlE!#k&Rf+z219`pyWC^$)u?#8TNG?vvkM=W4JUm$s~ed#6#D=O^h#TRpSc*
z{ik(hzPc9PCFR>BY~Lbcc@GIoewC(UhYV=vy;i-}OgQNOx}037E)t35nMt9-H4(kO
zLTp?HgXCGZIX`|?2(nV8oT_Sxk_X9VxbZhdjsGxa{5YTR5H|eHkl`n`N;~#qCoz5y
z^O{CP^Qx7MRO(Ji&F^+!z$%ZyLy>Lek^n`4BVCd_6Sy+Q#Ns}u<4*piq!q-#fNz=H
zi87ywuWA=z;K@%qi1OFGf!TaD?ZznL1%JKFN#Th7YJ>{TL_dtILb;$>X)?%?7xVG*
zs-h!Zh~TnmINx*MzQf%nj&{a>%H>3AKwZI#TAhf0u;g|}QDjdf0NX-)FiA_f#+}ZF
z$Iw&(1cEt+993I5MkiW^dNfl^kV6q72}7+=5S>5zB7QtFi?EqFjryp0M}-98yI;(u
zO@*8We?6LR_858=&rOK#i_RA|1%!TBcZ2HJ;cf7iCX|^r3|y3O6&K3RnsA@`o6LFw
z7CK9pIgb4p;bNREc%q3<L!e7J?aP_hAak5j8pBWITQ4MJyS%nsG~vR&o|H4524Qf9
zolo$ww7R6_gXSZf0cCu&Nq3E0%Z@1NCIe;++@Z&#T$X%9UzVmNe_Go|e%VTeN=Z+`
z%mP8SZp7IX=`Y?9XL<8F)9S9S5a;jvj@~nheta!h-#R;G<<K6Ky-+kP%aq}HrWI-{
zzZuR}A;;$3em=pIHf9Z{?n?e!74@X)MDT%+d~2+{2onG^f036|Dn&{D=q(*s$HaCL
z6D5+j=`jv9TQrK5LdgUNiil_+yDG7fFc^HCELG2k<YY&}xG~Q73XU}EP1B*`^WOCm
zi@(k-jH&un<z&@0y;45(P{#knIP@OC@=x0-*&xaP-8lXqM(`gz?LYwEPF3%3TV@jT
zB>i+GY|+skbNR>Y{rBSTPwM3TU&Pp-w6frT5n+GQq8D-}TK*0NfhH?I7MzVjxr4Bb
z=!PM?qH6N#VvREmR0O)MB&8T_>zX-kG=DwXb$NV&Bw9{DBCVk|jt$BhMJ>VJ!ufaG
z4AdUjwS!+!T}yeD<F2a`zAh}7SsB<{YFF^0tC%c;>(ycXPeN}HGk;NLQ{M2j8|TJ7
z$Myr9M9WIql50e4S^yQ*6iHK9gs3fHWfVg&P@qmO8T$^`e}k)gd!3kL<ktoAte?Id
z?hWd!;G+|T1MjD=j)z3fz4vBt{Ce1HCHPP7!|=bB-#@uK!T(x%|Kwi${_ENOlY7wn
zca!@k_hR>7%k7`skKDhL+CRB3w|^(If3lX^9|iC>#N7V{#QlSh3{L+j3kCaX@b%%t
z==+nHzyD$E{fVRRe;|2(;@JBi#@(Mp<oyq$?oS+d{{xu&lNxn@J8}QRxZl5o`h6qJ
z@0%ii-#qX8W@z6x!uswM%O1e`zFE@ujdH%<lk$Bn<NJ&IFut!Re7_IV`+7U9M)dx?
zlj!|EJntK!dEW%f`vyqf*9><zx%)l1-Mgl8N)EZPhj~u-7sPs9F79Y-2ik@7A<PR>
z*0V`&cyZR;N^y|go}Qsvlat|)&JF22ErbL`2vgvLbb3`>iV~rJVQ1w5M)rCJX1%CI
z>caow$6jr-<6ckWjo$qFxI}VAnxVnVlcNJLWDY)hi~I%iuJZy(7b{rxf1$eJo2P!W
z)X$1=P0_89Pw_#lQ(B{}#XnM(W)UrQ24DCGj-UFj^bMhNxw=L-lM;0S7q6Y9epmyt
zrnT@nF3pMD*v^8!qjO3LNfIYKkdom<GP<H@i||yDlSrWsS4Gy^IjITb)B+t1XG9kZ
zjqZ-251%N?a+S}PL;zgv?izV>wJbPKZA=WI0_TAo_l&9&ruzr++$WCc9_%8)^JfSY
zxt_x1LeR0m_^HeNW4S6Pt646m0OcvqR`xK)LxoPzu0hjA&gp9nB&F$J+`@l~IX*&8
z!XB--q`FE4l!Kt3YR3Y8@U%Y?2kDz^{7Jb8;Sy!c4A$bqnmJv;_A6(<^wMWw?9GcQ
z5z3Ic!@ubvy-HPR+1#(iI1f?ijziR<Ka%|lK^I(5vC6{?V{@($+2SqzAYc(mLIlDp
zrDN*_Eo(*6QynZ`5qz~#E|vQtRD97RT{fU{s!h_oMz{F5xKZe=me^0gAk-S9CM`+Q
z!AsH%!3H9smnZwX&tdOi@e4R>c>`%E)h!Agf}aRe99|7rxJ{IcbG@+R+UOn~ZR;qr
zf=%nAha`)UFMcBO?YL7+E8);ogzH7UFj>ta=cTJX31u?d)lN?-6gcnTV``GF3mpo3
zHQ@u;sy5s)MNh<UP$E&0=oE6A37kQQR2#J1OuSuxJ9rB>!1{K=g827(K`jlVY>RLu
zWj@^^eBWpa7H~|4iFCSSY0NanI~OUqPL5uk!d)42aJ~H48e!T#*-8KM7YZFceM*ia
zN%aM0uG@&YI^smhMpPiheoXOY_D3gs2ZPbu;eJ2XN<4Xkk(;iUdkI~U7{@D#qU?__
zhJ$Yr{-%Kp7u^{Cc?hpCIR4lpg0lAT#`Y~k0pq{-{&@HnJBo3#llL!APDiI0oOyk8
zv`-_<p{C)<3yW&JKN<EYq(PA%Xaj}_evRFD`Tk@?qcu7NXaD&9JM{5);DtZHXdI^$
z@7$+hCGrBA^`m17CEzg7sDs`5;mweO5ipSOVyDLg90rUV?VY;MQEcSs_|!*Z4u`J~
zMz4p5d&9(H8W_^tF`>rMp*R;G8$q8}@d|~GXsBeZfT53q_|p`Y1T2yW2e(8kD8?@~
ziZwjX-MJQ7Y687>z^c50-0=cUY9no>bE2b~nq7_1QT^5Rb<Wu@u^0*kAmA9Z?qkoT
zM@!&vcp5&5ixlQ-^!}~wmy?7dn{FFY;OcnzdT_kY!Pe-^2r)nSR&x_4x9sA6%ie7C
zGw~e_K}g-8wgsCzwH{|oY$xjGmVbVDGdMjtqCEj8+4}>EvA;S#dfVJ&w6A27_598l
z!2eOOmvRKQO~MWcK|S0hqoemY*n7-QSd%S1(!F-b@nfC^7Y%L1xJS^K4wzr`!{4qE
z(cpEI!114n@>V3L1ZKdl{G)$;dHo9;ux`V&ENt?b@G7HvmYy-1fc=RV?V0j#u-lyk
zP>g4f^XeDT{l?YT+Z3Kszj}+vy}^q@lS-uk>O7Q@Mn|aKZDHF8K*FTsK!6(<-^{AD
z!{HF4t>rSVa?Do8W%wtNQyEN99;QlIjIZK%LBINZIiGPbDWFsX-m=q1`^kLEnmKZZ
zQ^qK%jiZDpt?k4ioXhfzxQ(y^LU3J;cfH%m)VnPM)g=A&O2I8kz4*knRs>ulw}qhS
zh&ntv938$ohR4u_+;2A{U<<#87dSpig%l{x$Tg2EI%a$RAd-xLyGU<8Rp_4e7iu^{
z@Yw1lx1S_7Et0U5lZ8*H{o&vM8biY&p2X;E*+1BQ*8k=qo=IYR@(Vqa1`?J%6Ign?
z8}LndPkfo#-tXwe9es$T#Vff-M-sO9g9~wg_aO<P&%DKZ*i8=|Z<A*l9*(EQb=8c3
z5}CNTBP@zi1`Z#iITO~Zb(F;E14xPKtvYy#@9hv#_AKFjiAhvE2fWP{^A@*xN6D9^
z(UbeSM|!j+4fp6a@95~mAtfYhuh~4=)_O`whpTiqPbs;@Ra);UCAYguw|Gj)9bKhX
zPbs;ts}y@m$(OiF>M12(<|@4`OUw&$!qSLiLOzUsA54`Pz=nc*TysM8o{1-LwX#Rz
z#KZ&wOS3G5A<qJaF(U^CamM{||1#k;CO?R)tSZmZDTpoci#ocwYn<9}d%?d3%L_b&
zpZ#tD=H2sezWMgyhHtDKl{75jI-x7u!CLQ37fEzf$F#?eXS8k{n-ObQN>7<>BGXm%
zk<=zd_A26MZZ%iu$p4Wys=<PIUWb88Wi`8@tftk>jjY_nQtPND*J0`g`?e{kS9b}_
z)D=z-QgUT(8FLI0cmM0a(oD;R>)eU8S3ZoY5*aw_IWnH>4nZ+%Fh03Lw2lFH-<Nt^
zh6S5}9=?~z7jY;M`p<x4egUrbR;B=7i0i6wO;&~LQPhGmIS5!~m=r1J|CtSbxMoME
z2WI#0b{hW4ngF6k6;Memu!0I$&&I^=%_Ll$HDBPi3#G;SPh#``Vb*`*&Hqm8e=_A`
zIk5z4fc9=@pECQv4zDu&>(_W}em&3WA1*%yPb`-g=|P?exD$aX`6Pz@z{!B;eNU>E
zVav^kJ2purxIwDDu;wwPi6w_obc5UACJ15x&-u3{Y;39q6CJ7<mIhO0AgVGWlK|6h
zP~ixevRN<97h`h9r+*m36RMm1qU`6BrO@335WcG>M;78@_P_o1`ycw3S}cR&tyL><
zh!3|tya^VCXnX$boA?DTqiiCA;;;Ai(%oJ9PbhL{!<xQQp$5U*VmvSLs!4w>DilrI
z`=@_`Q+GC&(##{Np+NQl#%wuh*yB7KFOI<C-1b4FIsUZdG5&>V$xe&e>QD38H2&ZM
ze)<W1DxahjAD%99MZ1(gEEKqWe@OrI$3Ok_)0-6xJuao6FSGHdv*m2I`hz|bCg_(<
z#-@^(8}dQ1sYHWQ506bH5u^G;VpE9^PJMZ7D(SqnA7fLGv8g-6rjmcZ+vymUYFvrG
z5pgZ6dQztdHRN%ii9{+YBm5JJA>8oLdb$tS0g@msu~<?99B=o(OWz_y<RahQFD?k@
zIhbCQ@R7@_Ewu$T)Ph(TT%W=pKs-G8O!RhL50liW_vOsy1?;3{7#$;Tq3BnA-G&ue
zQ%xr0F_?+*`))Nz4E5!c+uwf8%O`8!KDWRQ_KRP)YtR`1Gb@9joB%kapo{1*3a;KI
zZ;}b8OgOu7?#so8prqPol13`f*Cb0)urGeIEv7B3zpJ)FtW!8w$mVY%C#l&_g+gi>
zbFJ=;`WGCx6#rtja)-KhD)hNE>KBA1!lpU8&SyjH^KASNi8twQ7IM-VPVKGp@Q8_P
z605r7z@3~N&@bS>dA8!si8Drw`6lJQNkqvP^#2RH|969+eA|a3Vrr_a%o(VSxC7!m
zC!kuD`s!lgXR|FygQqmU@d$toIV*3bIg@js5dwd<6edlguVPcUb0FBlQs;)_l*|6W
zng_IXsHJo1mMl5HkJ8h!oPNRp*LE!jt1Xdbyt9>f;P!obgfn+bXYeD^k487DYI=JQ
z#`D$nLhGSjh&><-hhWnpUQ<BR+pviKK;Oa-qshM0zxDN8bEgH<2fkTOh!17)*UNfy
zTPhZQY9i}fZ6m+MMYPecWW2U`&8W;G0?9hl4)@79P*a^6h*aj;{5kU0q1&q%Zfe9Y
zlwI&H^FP#=j!8?uyF>q+=A-J+`f=Hk(}l$$<6k-a2{U5xkn5cmy)D0gu;0c0ZkqyA
zAZ|I<i5`fU5aEWXSmw8Wyhj<Y4es;d7w+?0w)x{O|Ds)fYi2H<vg4yaf=jUmtB47a
z|5Rwj*7qaN^YrAuVPY=1Cx-DKE-|Nhx#WI{IdFWY37Je17vfrb6-V6&x>5a@<bmi$
zZ?pbA(T)Fk;xw`xq<Z*cO7R#1K_+c`{)?hF$z9V4>!UYGC$#8`qBlt^w5S%nA=(uq
zCKdi)typA+twPzptS+oY08OQ{6T^|<s&X!dIxNaysumv8z9N~MsMN7rgW+6M98Ihz
zji7F9>v6G~B!2_xcHGZ;p~rW-d;hS79{*mB_Z<LL|6V@yZ6z7Osr@2<xZM}-LR5`R
z+Dsr+-T0}5+23!$P~F9uNwoI$9?I_Db-%;U9ue`2$AUcs3}!FFbFndr`dbao(V^Nk
zLZA>Vu*mF8?f?S&cQQJ=F<>1=XLv`p2V0EH<UxfpUGV(-70NV>%;cVhGJj7aQ*6xS
z3ysVc8#B4Lk=brzCS6A6pLh34BmrKKhQnh4z+(ZxW0Dn<tX)~wKd&!P>d30L9~{Y-
zBK{+@Jb4h}e*<PY{vC$Jj*(!LQ=s)f-YB<hrtf7v7j|+2cM@$Q4X-UEyaua(rQFk5
zirU+$odZQb?=z)xg9kfFqhMVmcj^-|l7yK$y=Vi&N*Az%A9+$ZKcirsY`k!NNf-HV
zC^bHypH7A7*^~@$tkCnQ7Aulw!fwF<HX+I0C^EiJKGa9jQREvnYDh~uBNaJ9wKB;$
zhY^e8*r~)HL-<;Pkucn8`t?`o|GI%cX#RawLlZsw@yFlqKL6&M@1iNxxO3VOMuB#?
zu}!#P*v=+gF>EKeW7fruIAvcw*fC38mp0{}eYF7}&Dwcb-tw!K+@-zm1~QmmeOVUs
zC;RT!1`-Ni-JVqF-;!035ou=RTpKPK=Q<GO;euL|^y=ZcxUV*qkNZk<a_#3?7=(xA
z<6vmE+$M18IQ-3hGjU&aXXE^V=z71Qblg|Xl-$4jqP^Riy;FXP9^Rc=!ge;2Uc!bp
zkz&Gjz97xyU-L+sd3cryTX|Tf30rtrwh3GK@?Zdddm~vV8j6Qyp0J6HWS_91J7l2f
za~reMWY29R2mRHilF(nR%R+~4e+~bOe>tkz>ZT=-rn~Kb#M+HX?!ZR<eisc@_gZal
zBvZcLV&!*+0~ZT(5EVMZ-UU$(HhrR-AsWxtq12}HMmyjQ>M)vY58RbOyYet!RO9R#
z#vQsL4Y{5Qt(I}`vAUM&YNDYqD`&gzM@#0|6wx(qs>^65dpWy=i;}Df793k=UaOPE
zp$-zIT+V`<8|$r}5iugcVfVi4AvRSu_VhBtAkjV^_W1${->|J0bj$yBSxJQ*%!<g4
zp2|NX^OT#i08AjDtZPYxy1<}W=*l6Hwv^iv!9Q~|Bv%Ga!1BL!<)?M`N=q-p+IcFP
z@}h-D#=>4pbzYb>8e<jeViI6zwzM^EWNU6kTi`&qcF!+gp$bHPdRA*#*kH*VSB{2X
z?VyM@QP(6ssPERQXtmdB=Q8rJmjvY|+%q!pDM=lXVJ@$Q!1XIqp@@8t?Q%vmx#+ud
zGdnGbB6<60BL1OW(=YH!H|&r8<9VX7E4h)3;Rc+~DAh+@yOZ;o-^q}_^&+<hZn=Si
zCv?if#FO-C)c8}~ozwiB$ZC=1lj8d2682XWf_<{Pt--S#-;53wJ&59NYk2FYT|EiE
zGbIsuQ#$EB6yT%YR3W=a%beBSUHJvhabBM9aF3$!1YAF==vKn|-1fp$*w_wpTP~}G
zd+@y{rNjPNa{+8c*Y-L$X$TfAa^!<aTFZcv>9UzD=w^JQkO^f&`cA$P!*SN7Lb0(;
zrbDs4jip4%(%(#4bVHtyrAEmw+gy5--gHALQu5Uro=~ufr(7oy1M4WSNR;sbQipj$
zios`}vtmkR_Ca@v+j9qn9?*1*unru>h)9_LrNAi3(D+D&Ci+US>|b%hZo<spOXaiA
zW|BaOCC$cM^n+jfmyj@3E?duCJI?$6Dy~pSmvCeSmFo9MyL*PJj$lmm|7CpnuV}di
zTX2L7$FqEqzFby#JY(i&x(wGS1x2j{Tyrdce)fzL6@mJq%JWDe!Le)8X$}9kJ=g*J
zT=c|e>3sZMONaKes{)R~x5add!R!%Qqa|6J{A_6F%bt#vX}d5gyLd>?b}!3nQN@ow
z&F5wMr{Xi}lcqo8zxwj8KU^*s{qy1%bSrpNA{PI^#q#>y!JRr2(`9JF$fca#*n;Fs
zzhcP>6plR0$zL>%U9w63MN8)Ym3h(6r@0Ep(lV`r<%nUWmnZw!@F$#I6MXzh`-VPX
z!Rni#cuj+OZ(OySy~|W9l(?YY3Ewv`2IuI~$z-Bah+PQp_^Oy!NaZiO-_`Q!Dw`L7
z<2_xG9mI;S?in~K^V}9EzMJ%iRK_zq7l?bByjx);&KB|x`f8F;r3yxzOOblVk38E^
zEtZzl*7xZt7<K8#X-R8mH7${mKvzvVtgg!vr3GeFq7%_}TK=>|73}ljivyUUY>qC}
zC<X6EiYpNVV$R%%Csu6>6%mUOWqdNR!A6!Bj?Q#dM<0viyvEK=4bWG9QB!f^1P@7+
zx<vM&Z2l=Xhm^fjF${fiY3dt8f^sHanC8v}o0p4nTp}M!HJ%r&wI{C2@vA*rxjkYU
z=Pvm7q@ey8>fUi~Jg`%5!O5_Nt7VG{TJ!V-j?C$n%su}37n)&QAjNE%SO4l}(FEUV
zGDK2)O3Xp3y5h36mEm$sSkv`USC%O8*5$B!K`qyyDQZu$@64*H+MZg{yg9B`V%0LR
zuSDHszm)K3WVRm-clfCdE~9t;$765;h?B#n2=9x}NW^YAb5*)_vrFPWx2`<K8{w^|
zZLym`wZp`VrR^EY=ySgFBCVoqe2{st*|a&E5&gKRFQTEq@~H9#bY|i?h|)W>%vc!{
zx2fu?h%Axoz;vZ&&Lqr}I~4hpMEpQD#X|2hEmM=z7>{_3zp#5E2NVMudf`2g)9_@#
zlE)N^BM+D7uIGbhAs6HPE^Yt};m#Hi1iIw1_6b&WkF!Ns6uTH%<8R)i`EO`RWYgZQ
z&wKs$UHmwle>oC_hyR9CaOulKN8J)I4bss6fTmj?pEVzPO4Ma7CIBBI?eFit4u-d0
zzB)7Ew{Q2qzyC0xEmSS95whi*CY4;d)d&7F?PKr~*7!NfXx{z#cAz<vIXc(m1BZ<G
z!TWZ$iX?7m??%3PrrZMIWN<e_02t1dKqxZ41^Q>kD8(-Mu~*q&?R-2d%TE<}<cRef
z7fg&W4tf(Ts<U8CjB|v~!Id(dpiVVvT$gs|`B#x6h<8ffzv$zGw_KXi?(whrjs2ZK
zBbZ-+#TGO*7d5#j)NH}MkFhQ-L0~2MywVPZd~hY4ONN+4qv(Alit(m8b%QGfjEY$$
ztVAjl_mNap88c{~n1*s9?yVD;W~G-ZpPs+4>r2{#?ZOJ5D-}Gyxy)G(y+nl*MT#ve
zW68jH96bTWhw&bqNn6xy7F3p*vb%B-9uvP4E(`kJS$>&K&t=@<|DHT~(ohc7DcOv0
zDE---dMN$bl!Pe#*`$sr_iiI%qOCe(4^R~4UA7@vQ60DqX^YaI4uMf!jT_Pzr9T@H
z8I?|NPH9wLbAxiDyc{>DIjU=DL&Bqc%x+M9)Gy12N|16}YjsF*X+Ga^7udJYchA6G
z+B@DO6BUeXx#Uq0^Ap<66b5JEcK%_1j0tCH!)k=sw}O2DC*1xhJ?Rhn-YJh`Hg1!k
zLme9vwI}1{1!fyqJI)Dd@rs*>)3`UVnBmSVt8@TP5V%r<`2`vgv#j6dVz;FC@005b
zEwv~8?w;=pElG^ARzE=g3gf`rUZguu(7;W#Bn3h{?x??=wmMz~FNdL-2TJ;+c8cMI
zx1J<5)ev`vyd9mm0CZ@_;p?00U|!_Y^c9xCWwYwjD*gE!{{9EV8}3$<LI@D`)1Gay
z{t@`UZ*}957m}|kG(T^$s=kT#GnoGLZT7bU_2-(qNLp#%OSV2RFxA8V{h_7JpC?y;
zn1XQ&D-Jm`e`$O7w{D4wVH$%TI&<7nAg3#jJz2t5#wN-AVwivc>jf1c!H&?B1}}xU
z65nf@XP?agZEg;Ni^>Rn=g+<4;;*ww26J13(m<2Hf&++d1bhU34hO|-QNnLtqS-sm
z^0~encJE!boR;a!Yz}*{WYx|lPin2!UtLFwn1sx(OzBV2l>R}3!Qb}3Nw@d&aej3M
z3*z}V-+Z&vGHplKivs)!80Nv@$tc}Z1dVWr>U)oiYc%G!(QO<IPug1ggUmxbAnDJa
z`QQCH{re9&Tp9gO%W1xZDePzC{#pJ@vysLqrax!&qyCxw=#EXrgZ}e1{<D9^|NH|u
zk@E~UUH@$UOWT2HnVL{TCti2k+}-a?6^N?R1w4J)am2dW`qBjK+9Ub_N!axMiP)2t
zOzg&v{N5eT{QIi8*~$M<RX1&DL+WlelN(Wab4%=@YH!-q7pT6`N%p-SFGn*M3N`Be
z>ar1FmOJlT(cBDq9U{@?V5x=3^Ys0!pi`1*8~3tl0SDf!$a-m2P;?r%H6;KzT+7jN
z45~?EmVJAf&p+i;QqP@q-mPq5{{CCKU%#RMeNO+&Kl#3v<e>{EzX&O@?hdahhN_)H
zn?atX8$_R_4Fp=cx!S07V|cW5qnNaG!??6`)7Z3B@o8Oj5N;{njnl#)Y8&IW&=&7Q
z4RQZ#`FIE?<LSw*G!b?QZVD)s{vE(l_qwO`&DSEP(!T?0D%~`4D%~u4D*ZbksM5`&
zsL~B1snRwy75v{1Iw;44D(53UMswt~e2yMKdSfFS!6cijlk<F+vZ@Z2(dPH?d6QKQ
zYNkqDp(k&%`KM)-z5;)IGQ}Ujor=^G>2a1#@F0G22%dU{C25~aJf@!PFE7%Ql1fva
z46-?#p?lfY^%-$Oz;8X$2!HUW9Ne1pWRZW)`RmyXUH?D9EmhDrKI9de1+VAD`8j1a
zp1gw>hRZseRTaV7p$pK1!*V{k%IM!G#T7jELoxkS%=jZ3q$}sF@1oEXRm3J-S^(}^
z_OpKN#ut!`RgcNX10bnB_~uzYc?s`+P|PN9SC9$x1fi$LBqR@`HJhMD({fBvz9)N^
zb2zUDlkAHB38vC)mZ4WzjV}p}^ki=iR{>Ih)5zsB`20J>e9*|g&gYACzl0lrC*zOV
zr}8X48DCCU3;x6(GlabEmp5cbJo)4DGD|<s|N4LZzo!4!|AQvK7+<2#da{6(NCTZO
zm?eFnd?i(SnvXAM<+QvIHgcMP64}7_^QyR*@uN=5$t2zDyNUmht-vUS?##=4B0qv(
z7THz$M|hkp25>HC>FIJT?{u=9iI&HzTI4)1R6nwJ1S_OmUb`jq0cHi^cu&CINZ(`&
z>RwnLzalVYk$#Qx^koH8n@2|HqnY<;=H1!MyLXIYZ4`K&>C*dBwM4tjzRdKgTRg6h
z>!9LyD3bLp-OtcjS16l4xL7u_Z@f))Z|%gUedE{5{S2KJ`zAE@Wrj}EzUf%by)TYK
z{C=l-^&0B4R%By0vO)J;ST@^9uO{CUCZs>^g}-0Q{R&;)!XCXG4v%+f3kn8dE8RW@
zOM~LM-#y>?Nk07Z_2s8Oz};2M`jbzyd;$Oa3%EU{GQ%RSk>Pq$aY;2Oc9c@Q9ovz(
zx6^q<h5+IRz@Ob9sx8zoR*U8NIaSfz;9;IGq!mJ~Oftc0;1^LU@{{`##%SOMCc(&_
zJ??CYN|OZB#%9iPKJuWO%Q;GY!Qd~ayKnLtS(bkSb1aPL*-l!`z}=fI&J_oR$D)j<
z55Bz15FYah8oNOeC5g8@sfBjW2(vCFJHE&!{yKki`#QU(fBqq(T0yF}LCCdtaqHm3
zQ2uH&U=yHKnT7D~Fqf{s3!^(J48wS*CO9VLOR!kas>v>6Vt1T{0E>cP+GZwR&tZL)
z%ZgM#sqPH=u1mO=e$M9j+w{7~$L!<#d}^ve@c4mWBhOeUiNd?zv`Di`5!^pT-8y0D
z6VFCXxfBC?b<?!hpiv8Lb-D#jbFSeRG%S6paeGJgdSa*FBR<C#@QgXvz+dR6C!bNE
zt~@`trMeN5?a7ABwI`9O_GB|=+LMi#Xiqj~o;}&1Y4&83X4#WXM&6!mH0t)`{t>q)
zU&%qcu}IsK%|+RsY&gR9WTVlwCmW8eJ=tVb?aAgMYEL#CO?$H0NZOMPM$w+MMbPeY
z`ORPl?8ShnFS`5;F>QQ{o<Onnc0A5kpVC*;GMC89-eopP->znt1^t`fY9rbO+?3i%
z57RH;w(din+M!|KPO$Z4sI+QNkM{Rz_(lf@$jd1w!3n}bxfyrR5U>wUg2AzHpGHSy
zfJnlb(drgIxy>bRm6nWq*m2<4k<vVQI$haV5Lw>#&EWLpi1v03Wz{$^+<DP1bzpBC
z_I%4urrka|dVeC{3QVgp$0|7pEj+7&{AvJ(-Q3(`-@-7T)@o0`VAsCF5=7gvudwt$
zEIf%?Ha6jd$ez=$!tVKU&S&>W+G}HhzAp*1Z*MIj^d0%2eS4l8+MQK&5P8G8>ZFd2
z-*+Q4(yqNP<&$pIjDBUd+-Cmh3ArK4YHcq%ito%^-QB;9zwd_Vv9-O{l8U>rWViOO
zPM!Uw%-PyrN4OMW|MyWSw)Qrnb>rT5Gom-~{N9ab`)=!H)9dd(yx!Z@j_#ED7Pa=|
z)`{r8@6Gn@`nQJo`>wp-(fdXu;Qa@W-v<A9GL30*_S@C;xzVoQ;6?1l3&u47M|})s
z8!nuZZ_pkVcwY9$bZ%l;qCehAJYQUfY#{|^Dm6t8R~6q>a8HpK^P<V%#>xUs5<?=|
zex6G5@z)$||7<=HT-h;Sr^j7dWskZN|Gv5sXa?*i>7%m5rj;e|dW3=9pti*R;BYiN
zNPiuIuZ2$DL*ylrJ6wf#z5wYp|KkKEY6s2VNAztM4}!bjG%X4fmj%W|*3seOiH*rT
z`tK!dujbL3zWi%BpTY5&i&liZ{0ThtELR2K4aHA36+78L++?i`R}3N0t=?5o))Cj$
zuhAwSu&=+S)L6Is=w4OEzGQ*o&r!H`ut!DPu=k<U?~V>F+9wf2`0(Cv^eb)ow*#;{
zkMFRcu3J_TR_;8mq{o$X_m#v3<h>S>8Gero>2V?1LSpx$eIdQZoa;LVXDlRd{kWJO
z7t`ANZIYk&FWF|AWivIO@UN}+-m~bq`uS{*|NR3jp?TG3_ZgPQMc$v~i(eks+T&V_
z)*4K*E-?J-9TwQ5VfDDILNM>FEEh1N+4U~GKvFB`eE!X|XS?t}-=(KF=tRy1rvDfp
zd(>Th)LoU>SVw3qq5-&b>Zl$kOTH{+)D<U7?w2WA7bQz-VX|<fyq;#&MR}9H$*ND7
zGDhq!?AW;zA=(HU^x;rYj{?QK!B-DNfod!;VGh(ULx8q-<lYF-2lqu!(T4QTmm@#<
z)fD;prKnFqds0^(hWL!C!S00i#Q(n)>G}R}^egOgyo2|S-X8~OUHCbH<z62QPF^2<
zU|bb3>~*0+?*Ir*(l2HyY(rQ<bN4Mf>N*MUHXb$_a_)4ZMmGu>-4I@s3&S1`7FC=m
z<}f#b6x}3DbTb%Hf`{6`_v5tk`FR1q+K6e16!;IrcR>q(`HPw@PoI7<qAN)^f#XWj
zyI7dF7???Vj}+`03sZ!`J8VooBsXJaCg~S~r0lF7-s1h;VrnL7%ei}BTQf;F1XW7z
zL^^e=wTZ{eo%6EY<|dBseG{{FdlQe%FU!k@lS2*7AAb*K6Rrqxawy?R^=7#)IsQHC
z`B9;oxJy_R1}k4$N=WE&IRkTqw@y`JH6Wcqe$|qqBpfldz(_#?CW$YMtH(K*;Li*=
zN(ZBz!~KBACaIUXDUd<|cL>pTi_A$~bV6Sa%_AZ`ILi|+vf~9>YIS>UVHlNDNlbVJ
zD+xut;u=|)@Ia0QEcD$bWnQsf8QPL`V!)<Gv9WVFofl5#+0ETSHoI7omSC7#oJSNG
zP;l`^e22e-=dimW&mnNcf1&5F+iG4nfY*1kvJ+OJ`^U7hTiL;5vr(c6(AwQ>=(`nF
zZLXpUEoiibZnL4?yB>Ww9IjD$!$;BUZo)oxl@1TLk0Yh)huX)nbu2HunR5M2)#)pt
z?t=>S<AbouVXJ(0N8x6Ju$zv;Za56P$vEt$0<jN>#BMYW`-K+rCd05BjKgj=5WBHR
z?50Dpn~cSF+Qwu+Wz}N!cx?RFI5ztK7)QtB@$uj0_?YJx`ENpc;&M3YrfAsKd1HaM
zj}>cWB_c)2L7@6)#;Z+ooo<fibi)j%8znd0Ft6z*DNQ%WX1ZY_)6H_2ZjipT!*ST#
z+x;K;yiC$liFEx&dT=OMMmlJ`!=~9yFa7`i@BjDz-~ai4lJwq9M$Ww44RXbhQmbmt
zqn=p~KR!e1%L^CFo-q&Q?$vS%*AAE-lJdV~daO?*qRZE=h6_%!;wGE%=Tt9bJkLpN
z8Y6Ki`c}>_zGf8y79sfhZ}3)MKkI)(LLwpg{O(})+ke`{^JVv9Jl@Tza)UFMD4O{?
zpXGD7+q`5nifVrT7T*Y8ZN9^&R8W|BrpM0fy*&&-EoT&xI$)VSDGtGpZrjaDN}D@!
zG{M)><M*&n-s0|id5oehtcJ!#|M;0-!_#`{x6jhI*?fG7;H@9!0}WKykLmiVc^k>|
z>YPUJ7inn-Z?-~>Pqh;0r0s}h!e`H*(W}VxAsa@^{nfndQH36fE8~JFL_w0YiOU=2
zYwxR?G7U-hIBwbBw|20ZZ05M<5-$%Z>$l3uE=+%CQ`I@wJ)K!ppMgigiuwHQ)($Ca
zXV=%$LiA`weuZ?O*<7u47`i56L}z(6uTVpm4K0z*5E}k^>`i+}4WmjThj^(W`#Gw=
zU@_#3+o3+fK$c?fvWaJdq(l4RGADsRx`uIxX;KM&0lgCm#vc6!gT$=Cn0q@9ZQOiL
zQA+&OWu9S=*=8rX8yNzYn8cy7WWPKJQ#SIXKA8`S2UIs9Omo2ljmty6t$L6N5?9T3
zNjyAQ`q1n(JaYkKzoX9x=`$^Zx<QUU&fndk`>y1)eN4aUr~4MQuJoq^n<kV>9>E&C
z&f$OHV0~LomeYI-wVYuKNGx`q|JxE3wpeb4JAoFVtbB~d=fCA+v7^ox#H_LBhUDG6
z9OqR<^4%!f${MsNoH-+p3BGZjjUDy0EWX;3<vl9<GSr(9FCcnyv$ikkJ8!{?*aF8X
z!%(yxk8Zyi&}R>Pms}jR^|&2)Bfrk=%uTmRr(B}NNY;lZv;KaEm&p2ko^HeP*$L~j
zyw<z}%X2ax5BfVK{J9AElyE!AD84#*6$Sw=7^lK*E^Hb_yf1OZyU;y66<2R|!3T70
z6wGwKDVNiUx{+QYmEHn(qzO#Zk7N+^D2AuNXRNEI=)hx@^aQ#$&(AUL54#0s;d&|L
zh$LmI(?&@l_#ms5elF&VC7relZs(fUAbtq$rUIqtmUG^Cym&LwRlQ<Ivalb}62)gy
zECFK!`4#+X-b<$??ojw|G5bU`P~>gfUcj>i%#pm0=`Va?Vp7)w6O8Qeh9T!9mv9P~
zVMgOc6U_p*lA#h!-mIc1hP*!QqAT!eV5w1Rj#6B5qn0en%neD_L!%(Kf4}b>_pO$F
zy_GIdOO1uXC||^h!09S9r2aY{jM1Z}k~hN~43T<sdhc?1mCbfF!GeuiG=tjtWA+&d
z%W0Cq+<+N{tKe+4$mO%}jM5J<p61J{Cx=yr5@EQG<s9<4t_#|altdy0VoG!J(t#Pu
zp?^ZXfU3K2TFv>=K*mlvO<IpWR;}sywa6A@htMFX7G=q~Nu(|<!nK*}@|P#MzS264
zIvY;=wkN_W+8R!a3p@w(yhl}VG_ClEfz8;XTRZ2*`7ERxp>~W^7D~eDiJH>*mOr(~
zjy5(|-1A`mg=vw`$`#snTrr5FBw4h-<#Y`2>C(A`D><BS>i%ts+@CAjKe&{16xxPK
z$M9J{eNFju82CZp5q{T5{GnhoX}-sac0E4PlA+g!cKr6oy+bE9h3W9*<YS_7o$)L*
zuWVRhIU0O0`k2sWGe%ErdHHZ<elAM9lH$+=nQ6U-Rwa5-zN;v2DC>^zn04cqSA86k
zgh?(Jm$a8>pYs*<lFuKzCL~;<{b7yi%TjQlwB0Il|7<t#)j<{L=OQ`Y7#N+I=XeaK
zA9AoiX7UYOH0YU3^Yev2<V49_RI3}7UpT8_y{>5a@qkQu3s%dkYl-C2nO)2$yLdjV
z!WBz`SlRhG+(NOfja`9O#N@j21h(~iG6J7X|8|8;w&||^qf5HbFVx!zrE@Vp={;yw
zlc+r&KzP2&{T(-t+|$?&7@d=vXd+386a1ot<${9k;~rhmpYn+3IHd~%k4w7Z^t~y@
zZ|zqLltss<s2PD8vjjO%kEQK-^j&%tIAdW^(t$M1ZdSQFF!6$gL!wv93=|F}yp`b*
zy4AA-4p#wu3j1g_r*xG(Q@q>AWP;(%u24Ch?W$;mf;`Bd|3~^B-mqf(xa7?sDw%L9
zk3Y@I8*o=H3}J%|-^^uGh|GEw1?{g(Sj}Ko=46$!Dv6%d&Nb=Lxl36T{r(Qw-FSCr
zU^4MH%?#HumIXWMr*HDPx)ySxlcf)qaydzq(wELeSw=9HXE=gq<!@Vbfy^ka;L<KX
zg(zt}Ax&8o9XE>~ES8_LY*tVV;kUni{Y!1%R5=)L%iq+qpUNq_9e%ZAAs?HjaNiYu
zuq+5Fq^mB33O>kcz>{OT6rX*!@kjPzc7bEACq}&LGBKPmnv~CF_9n1pr{y(+e$biZ
zFSBb*G#}~K+42Icv+b-h7ab|O)qs@a0k+VxTA)|zK~UHZzS#M4#=(h9v1t5;r(QS6
zQ!C2OfYbJ5Al}}r<Rp_M>+;|5kgTRFhJ_LasKR@ur#q;i`;0%<qhq$f<Q~Qw5Z<%u
zMT{eAo6Ko#TMo+2k~!fpipA_4V}5kD8YoE~fh}1NaM|K;U&252GQiKD7mFEMQ0#Ev
z!Cs7)$n_+#0-gVZkkW&e4hm_bbrI-F7-7DPZgM<?;ef+IJj1hJy%9QSCfOC5%>K=$
zWko$kzX4BG_%}H{(Ax^rhl<Dgj1G&{KgeM~4HbB6!r$etWxtYs$vpAAH|6ir18}C8
z0mjJcZB3BPh(AFa8y}XJ=e_i@yrHXRoUsoxBO4Ik2|j{M^w7zv4ppBvB}MCOC}~tM
z(zP;!2geA*zH~Wdlg}iTE0-omign;iwvMFtecpI>miq07yAGYn3hX=_d5rUnU4RE(
z`;(#8Huwimxi>sUFikTFsBJItO#3?fJjN~1AMdChv&B_^!l3GRsTU;b_rOa+eB9e|
zj(Sf&|MiOg@&`DkFSCUyUE>^}x$Xd#WQjHMR%@b?*p7xjp8F$qHeSvvl3Z%4xnptW
z@6%h^Q^Obk-~Uf82u96^Ik?{Wb^0!wWYbJ0VnfgXPL)3hd%poL)xQh!{>yk%|I1+q
z{%*kh`(X!?^dB3Re^2UASCRA}&QKhdO>l+EMBSAsjnhjTA?-}kjj(lMg!jQDo#?_x
z%$)M3tyGiWrGIvm^P4?ZH;uT$qwNbQs@o4$y3+4KOuZg)g%fvsLDM7R>OV8$suObc
zX9AZX&Hekg58{+$aMPwpCE=t*>vA)!lJ`C<bxru=#S=?zmRa(l)RMlZ*qrKbw49r)
z8_$aI&%AE@J!Po6W#aq)IFtjp{X^-{hU7sXDmt|}LC}pUfo@1^YNHbG8`O5cm&DYa
z%AxKIZv4k9gGx3EYy3y#2S_#tXxu2A@gI*LAW7>2Qq3C!?uH*Y@&Q)#DcE~(e-8WU
zelh-(uPo5r{-=fT{W0|MNILKs+xWuR#=+<WyHF2tY@h7>7o{Ee?-S(s{{zbqbD7n%
F0|2wW6J7uS

literal 0
HcmV?d00001

diff --git a/standalone/linux/skel/README b/standalone/linux/skel/README
new file mode 100644
index 0000000000..2a321845f0
--- /dev/null
+++ b/standalone/linux/skel/README
@@ -0,0 +1,20 @@
+You can put this directory into your PATH, or symlink the programs in this
+directory to anyplace already in your PATH, and use git-annex the same
+as if you'd installed it using a package manager.
+
+Or, you can use the runshell script in this directory to start a shell
+that is configured to use git-annex and the other utilities included in
+this bundle, including git, gpg, rsync, ssh, etc.
+
+This should work on any Linux system of the appropriate architecture.
+More or less.
+
+
+How it works: This directory tree contains a lot of libraries and programs
+that git-annex needs. But it's not a chroot. Instead, runshell sets a lot
+of environment variables to cause files from here to be used, and a shim
+around the binaries arranges for them to be run with the libraries in here.
+
+It shouldn't even be dependent on the host system's glibc libraries.
+All that's needed is a kernel that supports the glibc included in this
+bundle.
diff --git a/standalone/linux/skel/git b/standalone/linux/skel/git
new file mode 100755
index 0000000000..8a6860f43a
--- /dev/null
+++ b/standalone/linux/skel/git
@@ -0,0 +1,24 @@
+#!/bin/sh
+link="$(readlink -f "$0" 2>/dev/null || readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+exec "$base/runshell" git "$@"
diff --git a/standalone/linux/skel/git-annex b/standalone/linux/skel/git-annex
new file mode 100755
index 0000000000..ec9739a8bc
--- /dev/null
+++ b/standalone/linux/skel/git-annex
@@ -0,0 +1,24 @@
+#!/bin/sh
+link="$(readlink -f "$0" 2>/dev/null || readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+exec "$base/runshell" git-annex "$@"
diff --git a/standalone/linux/skel/git-annex-shell b/standalone/linux/skel/git-annex-shell
new file mode 100755
index 0000000000..d663384915
--- /dev/null
+++ b/standalone/linux/skel/git-annex-shell
@@ -0,0 +1,24 @@
+#!/bin/sh
+link="$(readlink -f "$0" 2>/dev/null || readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+exec "$base/runshell" git-annex-shell "$@"
diff --git a/standalone/linux/skel/git-annex-webapp b/standalone/linux/skel/git-annex-webapp
new file mode 100755
index 0000000000..914c5923c1
--- /dev/null
+++ b/standalone/linux/skel/git-annex-webapp
@@ -0,0 +1,24 @@
+#!/bin/sh
+link="$(readlink -f "$0" 2>/dev/null || readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+exec "$base/runshell" git-annex webapp "$@"
diff --git a/standalone/linux/skel/git-receive-pack b/standalone/linux/skel/git-receive-pack
new file mode 100755
index 0000000000..f4f9f262aa
--- /dev/null
+++ b/standalone/linux/skel/git-receive-pack
@@ -0,0 +1,24 @@
+#!/bin/sh
+link="$(readlink -f "$0" 2>/dev/null || readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+exec "$base/runshell" git-receive-pack "$@"
diff --git a/standalone/linux/skel/git-shell b/standalone/linux/skel/git-shell
new file mode 100755
index 0000000000..0fc5cd7bdf
--- /dev/null
+++ b/standalone/linux/skel/git-shell
@@ -0,0 +1,24 @@
+#!/bin/sh
+link="$(readlink -f "$0" 2>/dev/null || readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+exec "$base/runshell" git-shell "$@"
diff --git a/standalone/linux/skel/git-upload-pack b/standalone/linux/skel/git-upload-pack
new file mode 100755
index 0000000000..312996cec5
--- /dev/null
+++ b/standalone/linux/skel/git-upload-pack
@@ -0,0 +1,24 @@
+#!/bin/sh
+link="$(readlink -f "$0" 2>/dev/null || readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+exec "$base/runshell" git-upload-pack "$@"
diff --git a/standalone/linux/skel/runshell b/standalone/linux/skel/runshell
new file mode 100755
index 0000000000..4413be9853
--- /dev/null
+++ b/standalone/linux/skel/runshell
@@ -0,0 +1,274 @@
+#!/bin/sh
+# Runs a shell command (or interactive shell) using the binaries and
+# libraries bundled with this app.
+
+# Set this variable when using this script inside a package of git-annex,
+# which arranges for git-annex, git-annex-shell, and git to all be in the
+# standard PATH. This also makes the system locales be used.
+GIT_ANNEX_PACKAGE_INSTALL=
+
+set -e
+
+orig_IFS="${IFS}"
+unset IFS
+
+os="$(uname -o 2>/dev/null || true)"
+base="$(dirname "$0")"
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+
+if [ ! -e "$base/bin/git-annex" ]; then
+	echo "** base directory $base does not contain bin/git-annex" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+# --library-path won't work if $base contains : or ;
+# Detect this problem, and work around it by using a temp directory.
+if echo "$base" | grep -q '[:;]'; then
+	tbase=$(mktemp -d -p /tmp annexshimXXXXXXXXX 2>/dev/null || true)
+	if [ -z "$tbase" ]; then
+		tbase="/tmp/annexshim.$$"
+		mkdir "$tbase"
+	fi
+	ln -s "$base" "$tbase/link"
+	base="$tbase/link"
+	cleanuptbase () {
+		rm -rf "$tbase"
+	}
+	trap cleanuptbase EXIT
+else
+	tbase=""
+fi
+
+if [ -z "$GIT_ANNEX_PACKAGE_INSTALL" ]; then
+	# Install shim that's used to run git-annex-shell from ssh authorized
+	# keys. The assistant also does this when run, but the user may not
+	# be using the assistant.
+	if [ ! -e "$HOME/.ssh/git-annex-shell" ]; then
+		mkdir "$HOME/.ssh" >/dev/null 2>&1 || true
+		if [ -e "$HOME/.ssh" ]; then
+			(
+				echo "#!/bin/sh"
+				echo "set -e"
+				echo "if [ \"x\$SSH_ORIGINAL_COMMAND\" != \"x\" ]; then"
+				echo "exec '$base/runshell' git-annex-shell -c \"\$SSH_ORIGINAL_COMMAND\""
+				echo "else"
+				echo "exec '$base/runshell' git-annex-shell -c \"\$@\""
+				echo "fi"
+			) > "$HOME/.ssh/git-annex-shell.$$"
+			chmod +x "$HOME/.ssh/git-annex-shell.$$"
+			mv -f "$HOME/.ssh/git-annex-shell.$$" "$HOME/.ssh/git-annex-shell"
+		fi
+	fi
+
+	# And this shim is used by the webapp when adding a remote ssh server.
+	if [ ! -e "$HOME/.ssh/git-annex-wrapper" ]; then
+		mkdir "$HOME/.ssh" >/dev/null 2>&1 || true
+		if [ -e "$HOME/.ssh" ]; then
+			(
+				echo "#!/bin/sh"
+				echo "set -e"
+				echo "exec '$base/runshell' \"\$@\""
+			) > "$HOME/.ssh/git-annex-wrapper.$$"
+			chmod +x "$HOME/.ssh/git-annex-wrapper.$$"
+			mv -f "$HOME/.ssh/git-annex-wrapper.$$" "$HOME/.ssh/git-annex-wrapper"
+		fi
+	fi
+fi
+
+# Used by git-annex assistant to further install itself.
+GIT_ANNEX_APP_BASE="$base"
+export GIT_ANNEX_APP_BASE
+
+# Put our binaries first, to avoid issues with out of date or incompatible
+# system binaries. Extra binaries come after system path.
+ORIG_PATH="$PATH"
+export ORIG_PATH
+PATH="$base/bin:$PATH:$base/extra"
+export PATH
+
+# These env vars are used by the shim wrapper around each binary.
+for lib in $(cat "$base/libdirs"); do
+	GIT_ANNEX_LD_LIBRARY_PATH="$base/$lib:$GIT_ANNEX_LD_LIBRARY_PATH"
+done
+export GIT_ANNEX_LD_LIBRARY_PATH
+GIT_ANNEX_DIR="$base"
+export GIT_ANNEX_DIR
+
+ORIG_GCONV_PATH="$GCONV_PATH"
+export ORIG_GCONV_PATH
+GCONV_PATH="$base/$(cat "$base/gconvdir")"
+export GCONV_PATH
+
+ORIG_GIT_EXEC_PATH="$GIT_EXEC_PATH"
+export ORIG_GIT_EXEC_PATH
+GIT_EXEC_PATH="$base/git-core"
+export GIT_EXEC_PATH
+
+ORIG_GIT_TEMPLATE_DIR="$GIT_TEMPLATE_DIR"
+export ORIG_GIT_TEMPLATE_DIR
+GIT_TEMPLATE_DIR="$base/templates"
+export GIT_TEMPLATE_DIR
+
+ORIG_MANPATH="$MANPATH"
+export ORIG_MANPATH
+MANPATH="$base/usr/share/man:$MANPATH"
+export MANPATH
+
+# LD_PRELOAD may interact badly with the bundled libc and other libraries,
+# which may have a different subarchitecture than the preloaded library.
+unset LD_PRELOAD
+
+# Avoid using system locales, which may interact badly with bundled libc.
+# (But if LOCPATH is set, don't override it.
+ORIG_LOCPATH="$LOCPATH"
+export ORIG_LOCPATH
+if [ -z "${LOCPATH+set}" ] && [ -z "$GIT_ANNEX_PACKAGE_INSTALL" ]; then
+	locpathbase="$(cat "$base/buildid")_$(echo "$base" | tr / _ )"
+	# try to generate a short version, if md5sum is available
+	locpathmd5=$( (echo "$locpathbase" | md5sum | cut -d ' ' -f 1 2>/dev/null) || true)
+	if [ -n "$locpathmd5" ]; then
+		locpathbase="$locpathmd5"
+	fi
+	LOCPATH="$HOME/.cache/git-annex/locales/$locpathbase"
+	export LOCPATH
+	
+	# Clean up locale caches when their standalone bundle no longer exists.
+	for localecache in $HOME/.cache/git-annex/locales/*; do
+		cachebase=$(cat "$localecache/base" 2>/dev/null || true)
+		if [ ! -d "$cachebase" ] || [ "$(cat "$localecache/buildid" 2>/dev/null || true)" != "$(cat "$cachebase/buildid" 2>/dev/null || true)" ]; then
+			rm -rf "$localecache" >/dev/null 2>&1 || true
+		fi
+	done
+	
+	if [ ! -d "$LOCPATH" ]; then
+		if ! mkdir -p "$HOME/.cache/git-annex/locales"; then
+			echo "Unable to write to $HOME/.cache/git-annex/locales; can't continue!" >&2
+			exit 1
+		fi
+		locpathtmp="$HOME/.cache/git-annex/locales.tmp/$locpathbase.$$"
+		if ! mkdir -p "$locpathtmp"; then
+			echo "Unable to write to $locpathtmp; can't continue!" >&2
+			exit 1
+		fi
+		echo "$base" > "$locpathtmp/base"
+		# Not using cp to avoid using the one bundled with git-annex
+		# before the environment is set up to run it.
+		cat < "$base/buildid" > "$locpathtmp/buildid"
+
+		# Generate locale definition files for the locales in use,
+		# using the localedef and locale files from the bundle.
+		# Currently only utf-8 locales are handled.
+		lastlocaleenv=""
+		for localeenv in "$LANG" "$LANGUAGE" "$LC_CTYPE" "$LC_NUMERIC" "$LC_TIME" \
+				"$LC_COLLATE" "$LC_MONETARY" "$LC_MESSAGES" "$LC_PAPER" \
+				"$LC_NAME" "$LC_ADDRESS" "$LC_TELEPHONE" "$LC_MEASUREMENT" \
+				"$LC_IDENTIFICATION" "$LC_ALL"; do
+			if [ -n "$localeenv" ] && [ "$localeenv" != "$lastlocaleenv" ]; then
+				lastlocaleenv="$localeenv"
+				if [ ! -d "$locpathtmp/$localeenv" ]; then
+					if [ "${localeenv##[!.]*.}" = "utf8" ] || [ "${localeenv##[!.]*.}" = "UTF-8" ]; then
+						(
+							mkdir -p "$locpathtmp/$localeenv" &&
+							# cd to $base since localedef reads files from pwd
+							cd "$base" &&
+							# Run localedef using the bundled i18n files;
+							# use LANG=C to avoid it reading the system locale archive.
+							I18NPATH="$base/i18n" LANG=C localedef -i "${localeenv%%.*}" -c -f UTF-8 "$locpathtmp/$localeenv"
+						) >/dev/null 2>/dev/null || true
+					fi
+				fi
+			fi
+		done
+		
+		mv "$locpathtmp" "$LOCPATH"
+		# In a race, LOCPATH may get created by another process,
+		# in which cache the mv above would put it here.
+		rm -rf "$LOCPATH/$locpathbase.$$"
+	fi
+fi
+
+useproot=""
+case "$os" in
+	# Make this bundle work well on Android.
+	Android)
+		if [ -e "$base/git" ]; then
+			echo "Running on Android.. Tuning for optimal behavior." >&2
+			# The bundled git does not work well on sdcard, so delete
+			# it and use termux's git which works better.
+			cd "$base"
+			find . | grep git | grep -v git-annex | grep -v git-remote-tor-annex | grep -v git-remote-gcrypt | xargs rm -rf
+			# Use termux's uname, which knows it's on android,
+			# not the bundled one.
+			rm -f bin/uname
+			# Fix shell scripts to work when run inside proot.
+			termux-fix-shebang bin/* runshell git-annex git-annex-shell git-annex-webapp 
+			cd "$orig"
+			# Save the poor Android user the typing.
+			if echo "$SHELL" | grep -q '/bash'; then
+				if ! [ -e "$HOME/.profile" ] || ! grep -q "$base" "$HOME/.profile"; then
+					echo "Adding git-annex to PATH for you, in $HOME/.profile"
+					echo 'PATH=$PATH:'"$base" >> $HOME/.profile
+				fi
+			else
+				echo "To use git-annex, you will need to add $base to your shell's PATH."
+			fi
+		fi
+		
+		# Work around Android 8's seccomp filtering of some crucial
+		# system calls, using termux's version of proot.
+		useproot=1
+		
+		# Store ssh connection caching sockets outside of sdcard.
+		GIT_ANNEX_SSH_SOCKET_DIR="$TMPDIR"
+		export GIT_ANNEX_SSH_SOCKET_DIR
+
+		GIT_ANNEX_STANDLONE_ENV="PATH GCONV_PATH MANPATH LOCPATH"
+		export GIT_ANNEX_STANDLONE_ENV
+		;;
+	*)
+		# Indicate which variables were exported above and should be cleaned
+		# when running non-bundled programs.
+		GIT_ANNEX_STANDLONE_ENV="PATH GCONV_PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR MANPATH LOCPATH"
+		export GIT_ANNEX_STANDLONE_ENV
+		;;
+esac
+
+if [ "$1" ]; then
+	cmd="$1"
+	shift 1
+else
+	cmd=sh
+fi
+
+LD_HWCAP_MASK=
+export LD_HWCAP_MASK
+
+if [ -n "${orig_IFS}" ]; then
+	IFS="${orig_IFS}"
+	export IFS
+fi
+
+if [ -z "$tbase" ]; then
+	if [ "$useproot" ]; then
+		exec proot "$cmd" "$@"
+	else
+		exec "$cmd" "$@"
+	fi
+else
+	# allow EXIT trap to cleanup
+	if [ "$useproot" ]; then
+		proot "$cmd" "$@"
+	else
+		"$cmd" "$@"
+	fi
+fi
diff --git a/standalone/linux/stack-i386ancient.yaml b/standalone/linux/stack-i386ancient.yaml
new file mode 100644
index 0000000000..4ad5330fc0
--- /dev/null
+++ b/standalone/linux/stack-i386ancient.yaml
@@ -0,0 +1,44 @@
+flags:
+  git-annex:
+    production: true
+    parallelbuild: true
+    assistant: true
+    pairing: true
+    torrentparser: true
+    magicmime: false
+    dbus: false
+    debuglocks: false
+    benchmark: false
+    crypton: false
+packages:
+- '.'
+extra-deps:
+- IfElse-0.85
+- aws-0.22
+- bloomfilter-2.0.1.0
+- tasty-1.2
+- tasty-rerun-1.1.14
+- torrent-10000.1.1
+- sandi-0.5
+- filepath-bytestring-1.4.2.1.6
+- ansi-terminal-0.9.1
+- ansi-wl-pprint-0.6.9
+- concurrent-output-1.10.15
+- git-lfs-1.2.0
+- http-client-restricted-0.0.5
+- http-client-0.7.11
+- http-client-tls-0.3.6.1
+- http-conduit-2.3.8
+- network-3.0.1.0
+- network-bsd-2.8.1.0
+- dbus-1.2.4
+- simple-sendfile-0.2.30
+- network-multicast-0.3.2
+- socks-0.6.1
+- wai-extra-3.0.25
+- warp-3.2.26
+- connection-0.3.0
+- DAV-1.3.4
+explicit-setup-deps:
+  git-annex: true
+resolver: lts-12.14
diff --git a/standalone/osx/Info.plist.template b/standalone/osx/Info.plist.template
new file mode 100644
index 0000000000..389630fc2b
--- /dev/null
+++ b/standalone/osx/Info.plist.template
@@ -0,0 +1,41 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+	<key>CFBundleDevelopmentRegion</key>
+	<string>English</string>
+	<key>CFBundleExecutable</key>
+	<string>git-annex-webapp</string>
+	<key>NSHumanReadableCopyright</key>
+	<string>GPL 3</string>
+	<key>CFBundleGetInfoString</key>
+	<string>0.0.1</string>
+	<key>CFBundleIconFile</key>
+	<string>git-annex</string>
+	<key>CFBundleIdentifier</key>
+	<string>com.branchable.git-annex</string>
+	<key>CFBundleInfoDictionaryVersion</key>
+	<string>6.0</string>
+	<key>CFBundleName</key>
+	<string>GIT-ANNEX</string>
+	<key>CFBundlePackageType</key>
+	<string>APPL</string>
+	<key>CFBundleShortVersionString</key>
+	<string>GIT_ANNEX_VERSION</string>
+	<key>CFBundleSignature</key>
+	<string>git-annex</string>
+	<key>CFBundleVersion</key>
+	<string>GIT_ANNEX_VERSION</string>
+	<key>LSMinimumSystemVersion</key>
+	<string>10.5</string>
+	<key>CFBundleDisplayName</key>
+	<string>Start git-annex webapp</string>
+	<key>LSMinimumSystemVersionByArchitecture</key>
+	<dict>
+		<key>i386</key>
+		<string>10.5.0</string>
+		<key>x86_64</key>
+		<string>10.6.0</string>
+	</dict>
+</dict>
+</plist>
diff --git a/standalone/osx/git-annex.app/Contents/MacOS/README b/standalone/osx/git-annex.app/Contents/MacOS/README
new file mode 100644
index 0000000000..c4bcea383c
--- /dev/null
+++ b/standalone/osx/git-annex.app/Contents/MacOS/README
@@ -0,0 +1,9 @@
+This is a app bundle for git-annex. Most users are going to want to
+just click on the icon to start up the git-annex webapp.
+
+To use git-annex at the command line, you can put the directory containing
+this README into your PATH.
+
+Or, you can use the runshell script in this directory to start a shell
+that is configured to use git-annex and the other utilities included in
+this bundle, including git, gpg, rsync, ssh, etc.
diff --git a/standalone/osx/git-annex.app/Contents/MacOS/git b/standalone/osx/git-annex.app/Contents/MacOS/git
new file mode 100755
index 0000000000..ccf2cd7411
--- /dev/null
+++ b/standalone/osx/git-annex.app/Contents/MacOS/git
@@ -0,0 +1,31 @@
+#!/bin/sh
+link="$(readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+# If this is a standalone app, set a variable that git-annex can use to
+# install itself.
+if [ -e "$base/git-annex" ]; then
+	GIT_ANNEX_APP_BASE="$base"
+	export GIT_ANNEX_APP_BASE
+fi
+
+exec "$base/runshell" git "$@"
diff --git a/standalone/osx/git-annex.app/Contents/MacOS/git-annex b/standalone/osx/git-annex.app/Contents/MacOS/git-annex
new file mode 100755
index 0000000000..bb82a2bd9f
--- /dev/null
+++ b/standalone/osx/git-annex.app/Contents/MacOS/git-annex
@@ -0,0 +1,31 @@
+#!/bin/sh
+link="$(readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+# If this is a standalone app, set a variable that git-annex can use to
+# install itself.
+if [ -e "$base/git-annex" ]; then
+	GIT_ANNEX_APP_BASE="$base"
+	export GIT_ANNEX_APP_BASE
+fi
+
+exec "$base/runshell" git-annex "$@"
diff --git a/standalone/osx/git-annex.app/Contents/MacOS/git-annex-shell b/standalone/osx/git-annex.app/Contents/MacOS/git-annex-shell
new file mode 100755
index 0000000000..29ebc25887
--- /dev/null
+++ b/standalone/osx/git-annex.app/Contents/MacOS/git-annex-shell
@@ -0,0 +1,31 @@
+#!/bin/sh
+link="$(readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+# If this is a standalone app, set a variable that git-annex can use to
+# install itself.
+if [ -e "$base/git-annex" ]; then
+	GIT_ANNEX_APP_BASE="$base"
+	export GIT_ANNEX_APP_BASE
+fi
+
+exec "$base/runshell" git-annex-shell "$@"
diff --git a/standalone/osx/git-annex.app/Contents/MacOS/git-annex-webapp b/standalone/osx/git-annex.app/Contents/MacOS/git-annex-webapp
new file mode 100755
index 0000000000..7ff18bada3
--- /dev/null
+++ b/standalone/osx/git-annex.app/Contents/MacOS/git-annex-webapp
@@ -0,0 +1,32 @@
+#!/bin/sh
+link="$(readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+# If this is a standalone app, set a variable that git-annex can use to
+# install itself.
+if [ -e "$base/git-annex" ]; then
+	GIT_ANNEX_APP_BASE="$base"
+	export GIT_ANNEX_APP_BASE
+fi
+
+# OSX wants this to run in the background.
+exec "$base/runshell" git-annex webapp "$@" &
diff --git a/standalone/osx/git-annex.app/Contents/MacOS/git-receive-pack b/standalone/osx/git-annex.app/Contents/MacOS/git-receive-pack
new file mode 100755
index 0000000000..efbbf2bb30
--- /dev/null
+++ b/standalone/osx/git-annex.app/Contents/MacOS/git-receive-pack
@@ -0,0 +1,31 @@
+#!/bin/sh
+link="$(readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+# If this is a standalone app, set a variable that git-annex can use to
+# install itself.
+if [ -e "$base/git-annex" ]; then
+	GIT_ANNEX_APP_BASE="$base"
+	export GIT_ANNEX_APP_BASE
+fi
+
+exec "$base/runshell" git-receive-pack "$@"
diff --git a/standalone/osx/git-annex.app/Contents/MacOS/git-shell b/standalone/osx/git-annex.app/Contents/MacOS/git-shell
new file mode 100755
index 0000000000..7a74904f28
--- /dev/null
+++ b/standalone/osx/git-annex.app/Contents/MacOS/git-shell
@@ -0,0 +1,31 @@
+#!/bin/sh
+link="$(readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+# If this is a standalone app, set a variable that git-annex can use to
+# install itself.
+if [ -e "$base/git-annex" ]; then
+	GIT_ANNEX_APP_BASE="$base"
+	export GIT_ANNEX_APP_BASE
+fi
+
+exec "$base/runshell" git-shell "$@"
diff --git a/standalone/osx/git-annex.app/Contents/MacOS/git-upload-pack b/standalone/osx/git-annex.app/Contents/MacOS/git-upload-pack
new file mode 100755
index 0000000000..5049371c9e
--- /dev/null
+++ b/standalone/osx/git-annex.app/Contents/MacOS/git-upload-pack
@@ -0,0 +1,31 @@
+#!/bin/sh
+link="$(readlink "$0")" || true
+if [ -n "$link" ]; then
+	base="$(dirname "$link")"
+else
+	base="$(dirname "$0")"
+fi
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+if [ ! -e "$base/runshell" ]; then
+	echo "** cannot find $base/runshell" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+# If this is a standalone app, set a variable that git-annex can use to
+# install itself.
+if [ -e "$base/git-annex" ]; then
+	GIT_ANNEX_APP_BASE="$base"
+	export GIT_ANNEX_APP_BASE
+fi
+
+exec "$base/runshell" git-upload-pack "$@"
diff --git a/standalone/osx/git-annex.app/Contents/MacOS/runshell b/standalone/osx/git-annex.app/Contents/MacOS/runshell
new file mode 100755
index 0000000000..4a3b504020
--- /dev/null
+++ b/standalone/osx/git-annex.app/Contents/MacOS/runshell
@@ -0,0 +1,104 @@
+#!/bin/sh
+# Runs a shell command (or interactive shell) using the binaries 
+# bundled with this app.
+
+set -e
+
+orig_IFS="${IFS}"
+unset IFS
+
+base="$(dirname "$0")"
+
+if [ ! -d "$base" ]; then
+	echo "** cannot find base directory (I seem to be $0)" >&2
+	exit 1
+fi
+
+bundle="$base/bundle"
+
+if [ ! -e "$bundle/git-annex" ]; then
+	echo "** bundle directory $bundle does not contain git-annex" >&2
+	exit 1
+fi
+if [ ! -e "$bundle/git" ]; then
+	echo "** bundle directory $bundle does not contain git" >&2
+	exit 1
+fi
+
+# Get absolute path to base, to avoid breakage when things change directories.
+orig="$(pwd)"
+cd "$base"
+base="$(pwd)"
+cd "$orig"
+
+# Install shim that's used to run git-annex-shell from ssh authorized_keys.
+# The assistant also does this when run, but the user may not be using the
+# assistant.
+if [ ! -e "$HOME/.ssh/git-annex-shell" ]; then
+	mkdir "$HOME/.ssh" >/dev/null 2>&1 || true
+	if [ -e "$HOME/.ssh" ]; then
+		(
+			echo "#!/bin/sh"
+			echo "set -e"
+			echo "if [ \"x\$SSH_ORIGINAL_COMMAND\" != \"x\" ]; then"
+			echo "exec '$base/runshell' git-annex-shell -c \"\$SSH_ORIGINAL_COMMAND\""
+			echo "else"
+			echo "exec '$base/runshell' git-annex-shell -c \"\$@\""
+			echo "fi"
+		) > "$HOME/.ssh/git-annex-shell.$$"
+		chmod +x "$HOME/.ssh/git-annex-shell.$$"
+		mv "$HOME/.ssh/git-annex-shell.$$" "$HOME/.ssh/git-annex-shell"
+	fi
+fi
+
+# And this shim is used by the webapp when adding a remote ssh server.
+if [ ! -e "$HOME/.ssh/git-annex-wrapper" ]; then
+	mkdir "$HOME/.ssh" >/dev/null 2>&1 || true
+	if [ -e "$HOME/.ssh" ]; then
+		(
+			echo "#!/bin/sh"
+			echo "set -e"
+			echo "exec '$base/runshell' \"\$@\""
+		) > "$HOME/.ssh/git-annex-wrapper.$$"
+		chmod +x "$HOME/.ssh/git-annex-wrapper.$$"
+		mv "$HOME/.ssh/git-annex-wrapper.$$" "$HOME/.ssh/git-annex-wrapper"
+	fi
+fi
+
+# Put our binaries first, to avoid issues with out of date or incompatible
+# system binaries. Extra binaries come after system path.
+ORIG_PATH="$PATH"
+export ORIG_PATH
+PATH="$bundle:$PATH:$bundle/extra"
+export PATH
+
+ORIG_GIT_EXEC_PATH="$GIT_EXEC_PATH"
+export ORIG_GIT_EXEC_PATH
+GIT_EXEC_PATH="$bundle/git-core"
+export GIT_EXEC_PATH
+
+ORIG_GIT_TEMPLATE_DIR="$GIT_TEMPLATE_DIR"
+export ORIG_GIT_TEMPLATE_DIR
+GIT_TEMPLATE_DIR="$bundle/templates"
+export GIT_TEMPLATE_DIR
+
+GIT_ANNEX_DIR="$bundle"
+export GIT_ANNEX_DIR
+
+# Indicate which variables were exported above and should be cleaned
+# when running non-bundled programs.
+GIT_ANNEX_STANDLONE_ENV="PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR"
+export GIT_ANNEX_STANDLONE_ENV
+
+if [ -n "${orig_IFS}" ]; then
+	IFS="${orig_IFS}"
+	export IFS
+fi
+
+if [ "$1" ]; then
+	cmd="$1"
+	shift 1
+	exec "$cmd" "$@"
+else
+	$SHELL
+fi
diff --git a/standalone/osx/git-annex.app/Contents/Resources/git-annex.icns b/standalone/osx/git-annex.app/Contents/Resources/git-annex.icns
new file mode 100644
index 0000000000000000000000000000000000000000..a79c6d9e7d22ef8815674b6a22ba4fb3f5198ef5
GIT binary patch
literal 77548
zcmeEvcR*9i@^BKG2-vW9#a^)hN)6IY=oS<UpmecZd&AHL#fH71SP*-mmn7H~K|tvs
zO?vMk<?J`-gaBT>?_S^2_xt{Md#^cLW_M<HXJ==2_8goyY~D^H&#7HzsxzKMA{jbw
zUof9UqFmU%$jy~RBKL9Lgr}tjY$DR)eVljT>DhKWh%~j2^9IF5B+^Q2crGT9tOtqe
zyLUz)gkfF(qX<s8W&xfM2=L!8T2CL@mSF-O4<Q~;fK}K%XggI86$JTt0t}(XpjH&V
zIh)7Bj(B4{Ue4C12&>s}>&=OvrTRgEZ|~SvLnFnRFAsSb8hY$|omB*l3J~gSY6|dc
zs_#Tdz`$hq7;5Dwr|~-x#`ne~%F3!Lax;7}Db#qb=*;m@<O9(sTk~lL4iVAy%#KSb
z_C$13Jiqm|4H13k5_rb-DG^0c_a8*?kO#I|P~N+56@oHmOIJsMtQKb3*Z1wv6(C3e
zo#}XA%F6?iFs!*5icx1C50#}fK}k*)Ks2Y6A&iq$T>JTReB9^s+T!;dfNE>1$uD^S
zK0mjnsTDzA5aJ_LTu3~;fbO%G{f=BYLy)!E)yZM~G9sGg{%Y@zBSbX8y=IkvAQ81;
zaV~#!Afm2uyp~t%iRh0y=H40GyJNAOn5Bhy$AptsM2ie}t>~GwDz~TY7aH&iUkZpx
zyU>PWcIU#Jo(hCn&D$G=uv)i!NvBSm(a#+F@L*F7G*z1O_V~%QYfc2b&n<zP_@rUz
z@&zR5nY0Vnx9+%cUN~v?w)PuW(C|si*#Bzp_5gx(=AoKZM~?OMO*m<I-(LT9-$V@U
ze(=yC27}S{bI=|ADYUk=b#geIPU5Gny;aZ-BM;*){Ou5+4jv!Fu+9#gdL9Qa>EvO+
zq=?Vu;sb>Qd@d&7BVcYm&g?Md@WbI@_!vP-n8AfKk%S+-4G1`obP<DB6?F7a#)D#f
zghYYM6LfN+K7>v@w6?XkwYL*d5s2t{2oHFt54sak(SjDo&}$?J!ukr(3xx5S_3k3U
zNlZq79_uvl(ar@*h3F(Ei%J(Q+=}i^G14?|L&q^W)UjO6XiDhAEo0`xY##@Jj`J#G
zobRLDXW<BDL=1W@@WJ^tDm(-6&_$nOSbJW`8<XQ#c%O$H!OBaKh$rwuVg<*JXLzB3
z0xpWYvH~9|{)4qaAP+DPu2{s_@u41EDGcPp*;V%i9+(7LK7M{sHdM>d(0t>CB=XM8
zn`i=yv5%m}W!flqMDrcSbunLcb$5^JQXP-qjhN<GA@Icdq4EH|_F=8_Cn_k+($=2C
zP>`C)8NfC4EkRz`2$<72WQFWkTdy(G(lS|Ny?QmW60l%Cys>^T<NO*yYI1VQZB5PK
z6h^WHRtx0weKBz$83{a)*jojK=N?ELCW0#nz{q?I@;-0d_Q?a0G5&Fk)XZoUt1m9D
zXEc(UPGA)DC5MqqE-duOCFj7{NuiuiX&=*4lRZ9?Qy?va>MI-hjg11BYnTcK60eJ@
zs(Q+ZAU_Mor{a^>iWjfx=F2Ts=%Evs3}>^oNovYQ*VQh&-<^Qs#MNu>)_>UG8NSA)
z%n$QJGKcNG5PD&_4|&-zP9m9oHnE+8(!0z~rtMZg<O?Ip*bs=gKysMfCO|Ka!fZFB
zKzDN8oOS~O*_zcGx8IA2x$kakl7u5f32T-au3Twku`C!^12`q_$aa@aJNzFb!6~c{
zAJrwld6!a+{4p^M)u1z2ANYkO!Y)C;W#}urQ-D%q<5~%}YKxEih)N@$GhgxmwH)HV
zN_ZYw{PpA0*aAF57V-1ro+g)~mNF2vz8C{|sxLz2<xNO{3NqV#fTese*^Z0?NMmmb
z%8>wa#9DH48oiJd#zz%jUSl9PCBMGSg{i_k1Y+gS!izlwk^qnL-;{bn_g{y{<~BpE
zCT2pd2h>6>`7z-yktZg_Nsf9}UCu3G6pCdgBz*QLl;nS{dm5S4fs5YuY&QQ1FP0G@
z7R_QsGa{tI1rG&@S#7{jQqXuMdV`V}Z^d4+ST7iFrQV=7SQU`qjY-1#7jUo!M!i@u
zi&f}RFM)AD8VLL_StudoLgnMf<-pPufIotf1(+uymzTqjKmg3dW<-j`#Ky*WMB=Qp
zMw_8S*41U`P?k_(z@(7Yxbb7hj~~q#OBpi)G9*#hx$6(EU-P_Az6VJL>WjVW<UW7>
z>eb6v_~i0Fx?8ZG8yK6LSZM$M%}pSv-gOD8H?S$Rm;t{L>=$9$$VcwfCB+0sebv+6
ziykjrzI1Jupt3PszTp1Ty)(70bqT6q-I;$pK?Tt<-wLYum@E)W*8@wt1y$9NU|dky
zU5^tAs=_m8vxI^w?uHE^sGd1q#03?DE5VDMHRnE$Arw_tHa;OlmCYQ@3wgj<*@m<v
zg0l)PYbvgWne8vA-L5?2WlYP%+o7R>hDLrKp;DZP<Y~%Vs|aCLanihfa;ui&ym^a_
zjnx?Qq!c^HahDzY+9j;m$PR6>w|B6n(N;Oy+iyf01TT7oRjuGtYHHd&8trx(BUJ*c
z|C6wKJ$rVdP+0N0g;nkG<24|x1h}wDU_2Fzx_>{)<0;NxmMV-zWDO0EMPy}yy%x&L
z50oF&pD~a!K#s_`dFoQ=#fzaHx5>94?SZ7<^LQ`cym|fVwTQi#i3Y}ICKlBHzu8Nq
z*dFrOBitZ~UGm!>_gx-`MEmJqJv$n?t<7A}8~z+P+~!tZV@C^AYy(~AyMT2<5!TA-
z<aG#sTrOzmc5o1f+XB4TRUMwaqOF~vhw%9DE6N0oLKMXiw^P7_mD9{?;fnw|1cEkU
zQy`RDI$J@5K^;IjY-~imW`sZ;Cv+8lJEs%WS@^FRw6qS;dLT3+R0k2L%!N9wcqI(u
zg2vL)!G-;c-wvG>@C96M2cYTX;yMq&Ktnv95HFE~IPE-K)xxV20Nf5<2agD#VZpPN
z-_GT5yNU_Y1nr<&@^~<0csU2P<CuxsT}=p6KtG`#eOoF5L8!I06-fN1Dp81M@uA_4
z<|dpF5YXQRq8u6rO^4U|T`ANj>Ii>(sc=1zpuB;8hpTja81C-_A8Y4;E(t+2N8iA}
zFmgZ{guxeZK>PkKU^p{y@Ciq45c@u~B7P^A2h7M9{II+Ob@CAxHGl&8qyC{b1l{7n
zM6{u9ChLu*9WMt37;68pybbX>pcIIJ7Jd*Qzk|!=aXS&<=nmb>iqqND%<lv(o!8a^
ztSJiJfPWF`UeOFt|Mwo)dtm>5cZhapiws*Zf=PY|bh&aw;+;SwtO8MB+4v$qjPe2T
zN-;4$iblsU2_B+*BYrU^AwZ|q+PFtygGYYzrbeS;*nD44Tf7<ZkHEehIYmcDy^dRm
z_2Kdjmn@n15DEM-X>P5WE|se4fcOQNv;cW7q*C=3<ns^XtvjePsNzc|haf>dCWao(
z&|y%;G^`QN6QnHYn%Ac+@t}(9&-g6Ba*#O2D_^J!=_Rv|f|3DgLE20`Zz^RO;^iPQ
z9<tN$qKfNIibJ3RFfa-anfXw~wdV#PeirDl=)$xm-c&JNO%B%+PX;Jz`#^F^9LfUJ
z@2BedQpHrZA-)HsqNeKjL77$~Hv<#nA{wOn>P&b7+7-raP}A|JiZ6DC2~S620_3y6
zpV~)XsfZ6u=)5?9DzRkJEm)8rLF>ZM)9C=*S4(XzY_fM}80hKyQYE$Z^k|9&C=G_L
zPR&qHPurI&tEXo$?=(snI(Pc?sX!K4bsA$jMY{p}2)bIQ@#N{#r>Xf+<+Nu{pFX?a
z-7B7+9v%Uz-qb!?rhXnCURyH(TOU;F;_cz#W1{6vl~z9h5WWFz_(+iEdQ-_7YZ!=v
zp~f_f(uil0H)%kwa)$>ZaXgWXU>23Ct-VA~-(WFbhyihA9IP+4RZm}U$r5d<)&ei&
zDUiYD8t79s7SEV8dNAfGNP~Ye*y522GZw2+^$q7k(hK#~9HXF4TX*p6$xB!slEp5c
zIDg2-LT%!hp$If}$;UzGpCo?b0y!WGa}Wt)lKhOfPtKn@?gd*vSUXr7zNT_PNk^Pk
zz85Ij68z4Njy68jDGEV37=<5^!9WuH_Vx}AF90J6pb0_R=_B@&xj8VX3#|RlCGeo*
zu=UHr`AYnG#>(+i=j%LyiIznfs>;(Q>L0xDxDG+fvgpGOU4`jNhIF0rRCE*C^5c^D
zHzD7C+!DH>+Vn|_w>|?nIg~n5UEjb+bBx}x5R88V^G7$p%)_3ZGMKc;&`@7%>N6Ao
z7MOvq!D0o|pjZ&uaEfsqBUi`zB#`5>u0xps@=*K*tBDKrbmxMV=!N=Yf;)33tUCW3
zdfJYv5q2Gs<FtHq$xGa?Lm}jFK`Nx2bDA=5D@K?Ba&5L}KSJXmOhO#1`PV>ud8*>0
zMp^8Jf&m2=a|(h36%chrmo`)eLe3Yk*Fdr-2h5!Ah`7N3AF1K9grc<*hv%ZbGsYfb
zB9K7{6@r!F112hLHbCb!i%B|q(@%nI#I7K61aKc&WBU~}2zFQ$JW<bZs{WZake$#=
z%o~iB{<!pGd(KeShs8bh3gTP=On5Dd#&&cC>(513rs-3)^wq}id5mv6Coze-3kFkk
zbv&pNx>JH7=Tff<mte-Z=;~Bh>=H{1W-hu=atgSiPEtePn<}9*?Gy~a#a`eSF$tXF
zsk+`&aXoF>baV=qu!j<?BT3ycKIsVKp6>;H9+TwpP|1lII=)njx^w4gjM8bU35(xw
z^2(bGbnY8a350IhE9ih6(bCl_L8pO?WK}&_VzOHL3uk-Y22O<|5#GsOl|WzT^E$zp
z?~FV;cdot<RYFT|N-Pqb#--=8DSBE!mX6NUd9M)2I0kTBAdkX-CLAh$AdkdnK)xh~
z%9N)p(Isk6yMp*<aUpzpnjUnjueRR&Yz!;97@LWmMC4dvZg!qPG8k48dodlu8W!VV
zfOgtt1YMWlqRTThbwDg=QSD*NKCZCD92WW8z@sN9C%0(A9BC~JI(nktv3nq}EOaKh
z!hU{S3;HObt&6t+!wZw4rKImg?WeV%5ELODJ@qjF8#M9gRPvPheju)<9G%*4(rU<4
zSJP7g9QAXxyr>d->WWbRGA7xHBGxJBYkN}VmO>$CCRJ-0z=miC>XSgUlHl22XB*@k
z)TGX<g6Br676SyO!E}?Gh#QC<Ly}yS<vmSZpFx#YNdyWK)u|eLp%cMsVZfMf3^X_h
za;^YteOaJIrRr-=-unVpLogZyoPF73vW`Ag3EIVWX;9Tq_pUdHy_l+Lh$}KiRDInE
zh8H-f^EhbnLwN%9{IuFc&9i_FscTUeCqjK3-B1lTh?OW)sk7j4Ou$xFP(7RgtLy|!
z#sCb^JqTEc>$Y`@RH|}W7p@^t2~M7rw5V#S5J6P02lzosD3S+WME4;FouKL&EW(#j
zuv(zDKQ&NWUSl&3I>kVbx*Z~XK*Hw+!C}KdE*#eY#d|bnj~R@U9;|Upn*@AC)`Ds>
zT0kF$=8u`JY6tu!25Kwt-dT|9AZjJB+{f2X_<$XBQ~RhMMPCzYQM9P~NA<`$J3WxZ
z-DB4urs7)w4+{r<z!NF}>MxOj(d6SA0IInr=4iA;)CWA*696uu%a}Ny+t~@*=5a)R
zgY%;LvEyL=i3>o(=COdkJunhKkW1k`!FgQmIxmn*;z6DO1i4T|s0E{j?s!PA_|0DN
z+r8p<dd2S&@hGZ~9)<dlh(Dd~GnX>`9%{tMU#|Itkgw$zVSxe?h-?x(Q?L`rk52+>
zli}E*J*<P=&iw$`Ir(8<C<PTL3E~}}?q-k+h0%<#EJ}89SNv`k`RAfHv0I4D$qdUO
zXO|=+az|>|CvtkhEp!Vb^Q!!6u2qv8VAr_`lnLOUzd#&R!A_osfW$k~N#;VqV*uoO
z!g!uTnQ%@A>{S$h?{)@0!&$e3?odLR=rb-}QSyC{^(F>)@PY>hK{Sfd9+Zv^1l2VE
z-d2-!POeT7cu|~FkSoRI1nlpFfUln%FxlV=#<d-|9557Z7i3S_cobJm1nAbXb*>H`
z_EL7?y^B%_DP-p2=+#ql%%1G%!f>WI9S1E0^r~wXE<R97po_K(wD03!O}DVHG(QN%
zV(7Vvi!YQ$3R^v9Pw|ZoVT6*IP)OmeclCp^XknSRJ;~A6p6mt35h*Yy7wmlPr5#)x
zyXf(<7jv+2aRxdZR&96%1|k0zb{mOdt(Fcx_TtX=X7pHK@@PA6d-1L27ETVH_To+(
z?Mpzo-bA4oDazMg!g;mLjr*0LC_>M@?8R55J-oi$+g`%aZV#-w6i|R1eeA^?tr%=V
zn<Rip7NCPXTjv7U9hW5tZUah6!wLs)dr2G5udq7dpcHTdQOo!sKUn4t0O)LufC*s2
zQ3O!tw4oC5yt;5offR&eUq450d&=5eU`Pr&vjIqPSn&owmK74#2M0p@CJR7AI*QZf
z>|;;)1Hmz&5P-Z4*LD%w?qg53BN{OVycFAaaD3Yh;fayo+Tw$@l7l`#8*2gOnoiic
zDJaI#%Y}@e*icX#o^6v$a650Ew>{YkHwDlmx|bPQ6(GbAvcTK6V-X-N08U!zkCF55
zdp#tDcw^-CL}?`OH1Iu9Y<(CQ+ZX=9;VXs?Z1e&mpTSb#<IS(HJ`5)^TrVDp3rBw#
zhWFs9aIn@uvE2)NH#Q^Md<JAwkSQMD=mSEKf|{WP3h)`;9cORo+8PW59Vmw|=@j51
z9R3_JoOZ;qEtod0FmiVBM2$q43<sNfOmG4d=b?zzFuIft`2^v>ML14L2RmQ<<m(9R
z#vr9rRypBF%mmm6yeC^BCGEKUJgC#)zyRe;8V>bg(h<uI=NktXL~t4<e<idm=3*Ym
zhTWb^=E3<Hm^L3nZEb;3DeFGqjE~%$eC#D%tn98weB$^ZDQ;Hyjcs&CXoupw4yA&p
zA!9i}$U8e&tk`kp{+-b0FYeyCcW&<r3p-a|oE2HHXvNTl)lg%QgNu{h3X`Qq8|`UJ
zjhEXvxj1aZ>Dh1)<N=849UC0{>}4FBT{gMe+q-UZadtQi17W|moF9ta!Nq;<T6+h7
zdx?$q4i5Gk17JPauVo`F6x{*UT7cMV?VT>zOKx<wTgycJ3{cb%bNw3Eb1+()Ryr{e
zFALNw#Bw)vat?yE>AJxv@Ew?ESRWoLzP@5LpgU^cccX)o>jqPo+s%lVhsnVP7~yYb
zW$)_j<mBkca3I5vQ(xyz_EvP4Tkl{73gE<@k7^&DvZY%xtOu>Pv)iz4jkUFvIn6dO
z3;?)-B5Wjxz*ctHWj}AvJ)1XgI^gN!f9l2^HXIu8!Hy;KVbEnN%Sy99Bq!yUmRGgF
zLgn%*FbW(`1b`I>=M>MdNSsRr3_gfo*xw?MAEYbb9}oT=CYDM)Dudaoz)fOsC1oH1
zVG`#i@CAfPoD~~c0Vc5os*Q|KK}W$NE{|lhnVo_{I4;K$S?utyU?ubsbSAKw%!CgJ
zvQb7Xi<ubP5`amg4+$(LlO0)z3UD7n6r06lG2bFMEG3psVWcNZoE_DOfz<@2Z+k4;
zlO-0Nja$MJpz}qsnO-chS74%M<5uZ=rYB2+$&RSR%{UMb0`$_CMS<hrY~Uu8ALYXm
zV>9^zToPr)_^`wQZzb4Apk+t0nLaE^{6}yOh@%Q<))xom3cwNum56<qMF}s%^$Gzu
zf$h%{k52~i1copMJvq#hW+ukBfmVc);{%uytO#&c1B2t1a9I>9fGLvz$J?kR>N$)G
zkSoPxvDwdKT7i3|P-nvPMCh_Nw83U4#^j-@$1#j365EGGO7MuHusXpQ7Q+NDA|W%u
zmn9b+6&3xkq#)ySMn-l5%bQ7lnaRkYd~75ZR9iA5gPi%omr42rnVDHUP*$S7S!Cv0
zh;*i5guF=xWaKzL*uVl$XgZq3WI$Khi3z|QT_!M${Kv#ZHiJcBvSJAf7{w&AnF;Yx
z5ziijL5y3#vMBy(cvO5mll?pvbb8zbW<HHbc>eBFer^F_0vF`we}4ZeA>!E+!UX=B
zTToWr2v#e8*a9Xn7`BpFQ(aj>ZjQ(V=EI^8n!tP>$d&-uSot7bph{~I%Eid#O`xL*
zcnm&n<Pruj){vK-6bVX|B#M2Lm0tz0T?TMxW&Y>a;gPZIGQt3EN{EY!V1Fw33RWU+
z0N1CoBckG-zhH$kLHhX%aO3wwIO|1XLR3UNIP7ubx8Z3*V&Ze=Gj?_%Cg?JL1z1^b
zVnqD&#6)IP8Dab;vJ>MYUgTB6nuA#e<CjzETSaQdZC}{Hz+F`ECL%VG71L$=VkI%*
zZ}O}0(?vK%!)@P6mJgfE`b5~i9O785KL0~x>_<e{zOwxHd9a=V8WkmRt^?<m#rq^s
zV5Q-vuK<0>!$1#!!`OnP4&3yG13dxg)AiZWQAtREo4(~tA2x-RhQkX`dUW__@K)g>
zyH#lV0+Ha<Muo2;S?s7>Xc0Gk%M*Z!QVGjffWCyY6QdIIpnGuGBM@4?xP4Ha5fzsR
z>p1cY65y6EUWuHF8@>Wm7?sFmCMJZZm4VJI0K>PlATf%~_5fCcr7nbq1;<RqRcSyG
z1?yV;d31b1+bLK$o%fk+mKRe3CkXLztGBCdu*#sXg^_G;rZ}7Rpn))YL6~?mrC6+I
znXoMhaI3cq`aCXxP<t*26)&bZi<yv&Z<T_Vu++tw&m-Ox2@T)!1R*70G{O~(qzG7i
zAQ_nLgyCBcQp<-WlNcABQ4FZz$QyctV-VKC{Zx<#1r^ybF^NK%QUN<Ph{`fTs7SKe
zk+I+>#m(Mh0t(hu6XIPaZ+kq9ybmt7qF^A;b`6IgOPU?qgkh}(l})(8TL}os%(N45
zI)$}Y7JxwPj8F6x)dJG-L1eOhnNmr>cR3NPm#`FSkL8e3{Fvm|xq&${a2o@?Vnu-D
zLOH%5rU-Nwv5`=b8JEap;ewYL+X}@X44%OwFCs9K6zd0)=vd?k@XVovgv5B5&dwO7
z5SpD30~BAz-R$M>B7qg)Kh|@QjQnUO6D)mH$O;73hVdgaS;yGJQy}XTix~@i52Bg?
zPmFq5gao*;D=$FJnNj#2!HUN(|5PV1ndz|Jza-pcl9Hh_xeO-h3uLs$GMG|qW<+`o
zFeBKyF!*0yMzRxGa0H65G-x-Es1^oTq28dXcoq{U3O#2fvcsPjfEh{Hy1*JWc?sdn
zd?-Q*EWir&za)f#D8|RA4XQ=M?SrcLh=eTM!7DU%0b6NyEYAL&F;J%+P!&R*Ay5aH
zFOJDdz;8JrRz@jQ0R=)HUtFb-gK}6PDR5jkygUJqB0>1$rZMh8#sq|!3(O<{s5E9Y
z$XbYeNjSzL!4Q&|$5=8rWf+Qm7M<{(P=7K08N$c~xhH|OlojP<f)p>pN1X{(Kzt`2
zg$YOn8@Dv4=xYOR;|jWLT=2SrQ|ed+DaVgVdK*|FQC^Sdi0oT2U~9f7Zr;`=_%O){
zImcmZ#3k=bf{V)_laf#b@h`&F0I5R45C#739cKYlul(NeVo^T8lnCP>3Ms6wMEq-%
zPc$W}1UG0~3w?^ng)N03^8<Nsa1Y8gab}c^J;3c*PI_1d`Ewbr`F=4Cv!bl<CiL{r
z6T@axX09RPS#!fwDT|zmc;>7y6^fFBFuzwkr&m0?S6q}&X!rT^!_>*DE}+V14LmpY
z_&D-tOG0z63-Y@Vc>c&)$#ZAVoIU-p$GjCB=E!umx3#u*;5UvsT2Hr;J46<)7q0!E
z|DTEbKNI(VChq@C-2a)l|2-4;TkkLEyoC4nW0&_gLFoNmd9=&>d(ohsN0_?DH5Voj
z-rsjhdb@?*-`ItwrbhL+_m{`FG%-<pMtFaDbq1z%y8hNK?{9!Moo=pODD?hrF<{We
zO%{X-y}!>EnK0;LM)uv_-_Qld9&~YYm8>rBZza_f(#EPmUEbeMi_E=fV)S){`<IV4
z8F|sf&E~O$7B3v?SR2zJ$5{PTmjgIh*#y#bv!xvHFM~0AQp1-nX1b6?IDnHEnnOx=
zuh0P;r)26!6EmeX;SOLPw!*}Z*4JciB(9He8x2hT=#n(L{&qNpPe-6`25K48eCg6O
z^Ccy?7kIlqgGK_>edsir@qD;z3MOeE(0d|POlUN^H%%7u4V}Ov{AiJ-nYk}bl5S?U
zLZc9@U`bSOU}<hf_od02nOSOFM2VBtRaBIWedtmK$|}mr^hTjac-4Fr6=g#odLLs|
z6&1BHk3#|&{^XMeJ~S!oWB&dDd$R$f6e`<(#NR(~l@G0tp?844|FKhTgr=lU^P*Fh
zIzXI^JA}ziMD8vlZ#qSX194I(?h#%Lq#7HWnOo}Ps!}hH@LqFsGh<`u0+q0bF?CCG
znxUS`yqOB!9$~#{b5-;VXy%qwp+}fDQ_*mxlh5Vz*9mht<lNQ6E^7@HXHF)};m8YD
zBVT3y$s?TgA@b^lvm$f2y~iWmCh`b#I@)oMaLFCQBOIFrdLJJg!kyh7;m?<Xwk&|7
zCrPAbf9&e>9*=Mn`|4raISaK+BME~z+hB>3qPcHy1gNXHLHzNc={)5n%dAZ1&_Q{D
z<4Ip|%HdY=*4f4@Ee%xW>Ftdstm04849zW;8_hI76WYrq9Cg8Rp58JT6s2gwDz-2+
z*PFNM0u$6^p-Z@y<&#Ke=XSe<*})qWsb;3?BA4((wYeLwz6S6P{8A~H#Vopy8QH{_
zFpF#8LJ2}?SGO(H+}q_6Zg;($4$$B!zO%K4a0y50_!v<1b`f?l7u$9LEI%;zi?6#?
z<92ZooS1=2IPKJ8m90XTaGa5k35Dj4!*h}6qFH|6kj7oY#XT-zNZnpL-_%^?e3wf&
z*1(5OHagJd627HqX1UP(Qv07>!Y}<*mRQhf=1MnFCvNKEwJ1gh5aANOp=?2;o9oYE
zM1Z!9yM*h5Ef<=>8kaCry4B?p7F7V3Fc|(f7viPHmW%X)zv3?8`k_YV-T<zA9{PkE
z$0BgTXNhhrnR$Z%F&>pcSjYa_#@;k3y6McL;6EXJ!T=7Qk^>0LV>me|JFjAfOAI>Q
zXge2Nz1-DCG$L&|-}bK1K<=p^iO{_*^Gu;!f=)A|e<e)hRDE-rH(i!yp{*8hABJ4y
z8y1lz^bLdY%#90DSGVw?OVG?0GI8H9SpHEUfoPH@CQ2G_d%K3C2^#nJb`4i7Szv7H
z4RV8Ku6zUc4a1S^4JC6r&4VsSqr;eL<$^Ex8Z!qsmzl&w9XtV7F|e<!YZ(~Us0W~)
zbOue_TsZ{y5KD1Uh{{q^8r_p7O{Z-E!|LojlQppHlTIH!N4c<PsV|MZ{=(67{mz0N
zhSr+S-vOrASsYx7PBS)Bf<}k|zqwS~+?ysxEe4~|#N2Qu0AHMYREe@s%NWL)uD{@@
zlHB}_kZWjQt_xTiG`wjNW`-J2A57;?6yr3{!WcS0qc4Y2&LSFZ9RS~<2bz;jXuxhX
z<3RHfCi@`IXDLk+H&Wf`&|R9bh4QMqLPxPY7v&yRHZ+Gemb?NoUK`SkJfJ7H48mw+
zqg@OneGzhQ0K*kh88j*Lr3*aYbUTVeRxL2Kpld_B*dZgj;U!@`U~{N9=%pTgDdCD)
zPB%B3yX;yg;))!_Z!Q|lU3wL_gbislJ>1;K(G4})1+lL>boyfO)(T$g%+o)f2nSBx
zj^bx0wYgBIL7h(1sUUD2qm!VYB-%0h5U32E1#KGL02VifjE_74t`Rwm;T#d6^K^4d
zT^uPOqstrZ#=#a?n$r(JL;#5RJdv{)x1v3aRA(vRCi5+$V{|{jAVUN4Fr+n8Ro@k)
zelI^UNJ<H;AR_c!Aehj1Va&-(fhr1(ZgJF{Y<dt(=trkRpMApjg>T%%MX`bL<g-RF
z)l2P}N8=^pJ_2#wW;7gg!qpnWO`HTQO*TA3*wNq&?&T!rN8;RW5DE@s5>MnLCKjE+
zEy5NiRuZ^5afh)mKde{$Ua$CrUhzjnJf7}jPN9br@kkXPb&ASk+@>zN?Q@5G`-{+~
zCh@^d+}ot?NIm+Al<p7zj)Lp96gRE&^ukOj#s>+rIdy2*M9O$eBK~<&*j&nNTO$5x
zLf9<IjCI2NUh&Moh-Y=>6Q*_U)Uf$vMLRI9GbH>51`i?+SW1}IwSj&?fhPk`h#x<G
z>~1f^+Mgqi+tuwJ98$Yy>xuu_)&FxH6YlE&xsLzmI{u&Q`2WInEP7>FvO7q0$9{XH
z7b^UQ_y1)$Bn%99Z@cXtU5VfQ*ty0BZo3OZ&joq#J^Ysf{!W4@bluqRXw5~9nea}?
zZx0-lS%p5;b#|c=(g6-Ecp<SGcYFQj0Qzn*y!lsxdsVvwWWqHB3}wP);_l4f6A^U4
zTaxfDd~q*K7}k-ECk1@`Ho|WW7=rs4U_GGfI$SXq25?+~CkxlkYYTrb0dUKr62=)v
zl?kU#BJ_FnLbMoycS^g->MH()4-9MR>L7+Sed)r4p}KCqgYOu8!x+C1H{O&0AAMn)
zFy^><h-dN(MVVk0wHN%p0RWtJ-K`5yP8*(p`&69XtWZTbK!rs9+FxSnb<ZwzwG=Kt
zKxSDtO@I#=gV#I#3rP@k<aZA=fvFYd9c#<^7Ts@Kgk4Lor$ev^8w4m1mR|RuK>s24
zw@3lF5sojt9#j|%Mke~&L=e=KEqqir^+5HI`ya-zmg3%+goLz|XSOvpH8qMD5RQHz
z)n51?;`(9ryjEztrApK_>}zvVQ)^ZmWHvR5Uai9_iDZii=!Xscdzn}RAZlt!?`j&u
z;&8-WJ2AclF#J{;9Hrplci<PcTnFMG7!Kd;gqR?T!G%#_XoQ<gc<4(0(uc6&)Vi)l
zTRVGUD#EH;>Iymv8*6_H>YjdJxpk%O*=-G#oV?zHoZBeGkBjKv8lZU`e|;tAZ7)1n
zk%$3*%hdN^>NUD$z2XohR-mA|F0Tjp*T*oFUk=|h0c?P-7k=3H;8t8iO*!C)OK86>
zV9ojEjSczjI1lzl56QC1hK8D2h-CaW?9gxt{A<l?uPv>Eccy!Xy7EeVTwqj0OR;z9
z597r0>H7I0zz;H$_`-gFt%1vWy~8I+z?|@FT8jVS>i=f^zDe|M_nSC|6;~C)Oyj)v
zEq<)79`bo*<u&bpo|tc1=#{|gT5y4ihvxEsgdg8$8w;B&!4Jj%+V)Kqcvl5Al{J=u
zgAHL7|7-+4_TXprqU$fC!2EbwM`c+ZTmk-5Hw9I>)nz~!D4?|!U;kA2<0jz}n<&6p
z`rif&RpeDv;4Qb*HRV)((|sIoF7O{*w<{@bLgoKR3a9ii;6K5STC-72MH%j5g!^^h
zy~~fY1<1xGSRn%30r>YJr3d7n;Ky(a6O~oNCv0&3`&0jkOm0bO2Nc2^FZEsPqzA?K
zv7f;YD=Vu3wpIaZEiVEV2THyRSW6|*d7QT9#<suRiGBh<yfT|7R4VZ?u5JFV^8_)~
z^&*_$jx7UO_+u~;;r|#v^tPf&q~t?_-=*Y;8tQstydKjB4CLA(umk=T1^*O3bh)4$
zK3^b0gYv6?*eqBgg}tCqQ9a!J{vo8WrGJPYY}%><oT-HY)ceA}Xca?+pq+`};8tsO
z2`HktveuRN?c;Cp<7^H+sHlJ!Rz*z!`n+x&-?oR-SWwYZ2$WR52U0;b5!L>t0=(rd
z3gC_ZK0u{5aLR+3+tVg6RuR4o{~`!Fa%y{k@naect7)pvg$wn(4)_jS@6g#xfr{t%
zF2Un~11tPm3m>^F;|j+CM+xfyzEbqV-VhXFs58H`n*iKk!{D8y>U_Y@ZSVL~=-G6z
z5_tRn+W>cj5&LUrE;R6=8=(NTG~t`jUkCW^OQ~q30AL}&f<o4VsaMTj3KY&He+u|k
zQvt8|HeiC%)-H?!RQ~nvY-<2513QhVffaQCyR=}~w|lh+Q&+2avRAaL6xsml;R}OM
zMx1ToFvaD6zq^BcC@yXxL^P;k7+lA}(3h@8f8v4fAX!iy?+Y$g06VW#)Ukiv4!jJ|
zTmaPsW%#!ri=ig29Q|a#@#8!I+9bv)f_4P86~I~0*xv`3%z`R-M+Lt>UJvh+AlR~g
zHsJWPq1%mcu8BS))Kpv3_&t~WMXNw=Rb};Oe47B$iTZy5`Ip%^e*AS3;Q(Z}G{Z5&
zcTD=1wQ<mTpqgj{p|5zXN81p^@LXXK<@7uYaoo5qL&)%K_!<TD<0k^XL*o@*G`F|m
z^Z296-Fe-S9t1!#Fn<T972X)YEB_pJyd9hZ;N6C%X51pcI_ew#6hzA!3VDAjYG}y9
zo5<*BYbd~p`-zdq>-7Yv%opHCCO^PW%#RTC`FHqn{Sx~OcHR$1t_Q*2#R$srw!Q~U
z>d8v$iHc%GogY^ef&9~_5O)u6b;Ww^e}BQ8|Msx|Bg%U1|FA#(_d_rIaN+O2A9~?$
z{_kUluio?^6`g7I<op+6z3{_k@!t=<@WcC4|NVeV)~<l>HvjeTngidhgV5a4{$qpY
zH&awpRY8QZvU2=b>34_k<R5Bo5r$@X_3^v#i^=(c{QuV&e!9ZnG{<Xb{F(3<CicHZ
z@-IqZi~kw)jlX(D{OoYz`v0#D-*MQ#%=q>F|G5$P<@o=Z>CipozZyT>ssE|)%klrD
ziu23y!}r^MCj4^za5nri;g_$!R{TS=|197OlQ`=B8G`=~wnKQ-PyBZ6JEBKxd)qew
zKPkd(wqF_q?LFb!qaJvp=iAe#PWV{t&q<44N-5FUZ^Vxqro?9ya76fN`47Txw0xlH
z#?pow;TMA&+C)t7?XwLx{eMRQJHEBPy0oRS1CB-EWQNnj6}@Ae#NUCOFoVC=fpY=^
zaiUQFS7?4<5&sqFPvpbdTwN((2kyd%4e2ippI*knPqhCxpy0mChx0HYZxb8Re-%Gm
zj{|(7l||g#_yK-ldGEu4zv<OKE*5~(wC5a&;J@$jcbx_IIvoGU?f(rRh6;N-O&f9W
zAK-rnU#b=ee);|bqNck0WE?PK1nZ0Ng9z%P9!r5Mb^>CBbmjb_2mXf-L`d*yfFs53
z{^R*w6u^mbC7ic)L;fP{(0*xkw^W5l6|uv0^&jhOgqRQ~eBb4t`Hz2&GH`@+cS?Y2
zo8bc`J^e>njaA@16cPX*@9NDbKZoWop)qcqXiVXNz6!2S^v3@Z4tfh~y9ns*a{0^l
ze!8GYbZHtK>G;VuL5+z2-b1pzh!_&Q;bQzl_`f*3?`jXwmv_&E2>&~LIJo)U`8mHB
zIW#BIs4#9$&v|k$`~XtZ*wt+eJU73V0$5g}21|M=SKs32b!(k<J%{6>YX8}@8$X5$
zdbL#7rTcV=+dPpF5Qs*r7wmr)70oEPlY2Ep2w_NfZ8wEo!w$DOdI9~C=xfo0w)N)i
zvL@nGqB&BCqrLkeF!Prn?bS&4)VBA!Is$hph4?eOsOwfcgtuCI)&EbUB8Bpsp%smZ
zP#D24c$<hI)Q<jBoW1MgA9uzBycXXpTcmmmcLu`S)&<o=S}*W_KZ@Z_RAI;$MZRkd
z<BAq3#`{a4?`r*{452fR02ML$_w}$Z-9!@F(f1JlevUx2qOiuEefZnv@Vf${ZiAZo
zi-YJ+7Cy<{ioiEG;0ukSG`QY=br6Ykc!vW1z}NS!L)SA!!;kO4zdDrRpFG0@hKk@u
zfoPzGc|^Jfq_HrG{nZtxF6e*bfnOyMwT{wZ55SjR7d9f+SPkF85M|)^K7MV0UW?iU
zyaly{%Lk`GNJUvob#?cwz()grHG05P*ZpD$oB-5THdfZb1rwa6n!5VBGPtQE!U=bF
zYDDp0Hwd`k6&-@&M-Vvv`Y-TT25NEqLP~_#1aRTu*W(8-d#~3=a0=j#0)Zcoi7108
z{u0v<)&~yt9|d@Uqw9?!q8VU191C<5V!gWi=ND@JBb?t<1_H{ud8~^D9Q!vw0@T*c
zC*KtOf&`eAJxu<?_Fzbwx=e!~mj7p&(9??ECir))!Gsin74q$fd<XUKXF$uj1>Z1R
z@3w#k+e(NFJH2y%X&eYBr~uun7rP7F7qVb!1$ZKVTki=>aF?{Q68HDxqm2LcGyFk}
zxS#}H?f8~Ie`(*l8WSL1WpyQ7r28hcmABTHfE4=ah5z&K+rr;;Yb*IuUir0&Q<R#P
zTGiR`wXpJQQ9az=#lKtmli{0Q{B)wZ6;|7S6#kuet>N8icTX>Gk3&BGhYx!l^7Quc
z@_;`VD0-#(r<(k~eD@s3{oCKQ{~H9NKN;?CW?~@McVu56NzTYn*8=|BI7G>$K9cZQ
z^T!<r5=nfLvyP6Lk&e!Ivp=>tz~}Etq(uXLmKScxTQ*qJe~ZP<p<3gu4EzFKJz8#Q
z9W!d=gV&NqLAUCb4!u>CJ!8^WRTclRQBrwTk#|k^d#FhA$<!RN{)Xxk<RtC(=d`oK
zjV%3U+%+=XU-`2Cgei3r%ZuZ7*-f>4xu%Vqw776_g<8eBJY9|T&Jh<!EI)kq-oq;&
zC!Glj9eVnzaX|XB&or^m_o_^0pG-;~G$(OLM@micn1DV>btmgFlXeBxz9ac*{u52v
zn}>`!ID#W<{^7H0ByBKDipOz|lFV-z-S|maoN|wH?%?G?d(z%a)i9Z$C4DS)M$M21
zec~n6<Fg&+M%k_x8~!$^c=_g0u@fCmK6`M=_K%OnbB}L}nuq$&xwNyjcCD8c@A9pf
z4blDmzszi3#`M?9ifA3(NPE2gQH+u8AqmcLZu$Yro^j@_VW$r6_)=l8e*J^NUnIXs
z>`&VoDr3xZ**S0j=;2S&+9ubWf2*)4Yp3I&XE%p28dh+^vo}<pyz|!5xyZICap}Rk
z7uH|gwxZm-AnDoa3m+&7$2YP<lfN>g7+T>E;_pZ#r>m+g2pQT;Tj{#_VVHLA!;7oT
zWd!ptsI5ExcDh^Kndhg+CH0Hlb$vwA(50`_s-_%z;IPkeU~aZV+|^;ZCxQ#oYj;Qv
z-<z!!uR6C}a&+F>&lYx(H`oT1y1EJ`LucD%ge_IOX?At~>6Z!m%IcHnzxDQckz_k>
zqG|e|O$B=wA1{65ee~(DgxMkHx76M|+RA$O#7fIDhs+;m_pDZNl%xF3$12&EYWvU<
zRTKM3^!>w4b;yiQ2dA~Q#GCG1HdNKbteH<eIPI``N>0N_Zt`)=_u^yP%vJ@{)Oic7
z>*U8v$vf>-N!JW@b=9ivr~Y0tj+0Wybamaq-_{aXaK!D6^5e~~BcF4!A3d4Pce9|V
z+3X8Ad;NXmuIJKw6vk+*A%B`ISF@#PRcfw9?voq0syjVW6{aL=z194X9#fop7Yo6{
zHs4u)XV~XLH5cy@YPTmHoN;ibVA{c{2j>dt0XtU3P83X9dxm*(j>O`)hJ@hB+4~=@
zx0NplSnHJG8mu(c(&YXAufxht^W*tX)ki%Z9J79GQ0Ui$##-t2WLd$OgyB2-K65dS
z*gv~TeE7otlO?Z6X1!ka%KP4qp{w$OgKk?WzkQwEst~$s&E>MQ0ee)h223^dZ#ZK5
z@=eJCO4QYO&N|MN$G64WupoIwRn;Q5S@g+o7nEF4-L^unweOBgsmW{IB@6q77~R{I
zsr-J(%A7}cA5E7&@IHF}+6)7~A;}Aed@P%$ygNGK`H>rwm|hc)Rce3XG4*y8$hy^A
z>-wSRYBejItnbJltQ*kA8ky_cXmX%@LC6uQw%CM{iW`PsB~MzaJ}%^qsiKt>?1)O+
z!{}K4ajLG`IF*s;p~^_L^%K$1H2W5<RitfuHjSDoPa;uCM!MR|_K@oiO4*Fgh-m*%
zd$+?*X_!&{+1bPLpCrC+wOKvQBUO4Xf5L#G#2fLAW2bwkE-~$M!aL>0?mpQ?zJdGC
z%zn4LUN0f5;0ogD$Js^Xp4qkA;Z{a<zx%tDwpZlu|Cmsb|EWIa>D{}hqQxb}B_*dw
zp7zLbOLO%gdyws@illk{AyZNEL*@SHG(pszp_f)ECoz(a6Tq#uRJVwTu;QiXix*BF
z<tFy{?uvJlF5OhVq}SK-?fRFK6~`-HlM)-6dV0jdGESygQrp@bhi4j<`#ybSy}PpM
z>8w!Zp~|4Lb8-nz;v+}fo*FD)FGIT#Y&hhRoRjR^yEj)4S+$t+GNr;KU!y!y_L9q}
zDYW^^ck4I>$g&4eN8eV?nCNylHx|n@-hF)a`Mvc|3XP+8k1nFw^cCATSg%4tlK+b2
zT#+ZA6uJHhcbHMb75;mF3FpwO8*hF#kxVVwQhND|<pl0MhgbPKQUYi!mxzdU68evu
zyn@!>(^7E5)VDryI6XwtV5+x&FhxwmhU#XS_d&@mf=1<UxMtG-S@!+?tVLx7GxW}e
zdcU(B8vkg&y^=14WbkxGfF0MeSe~Y($t`o<R&M2bdiwj%o7~nVY{VQLjwH_?vx~fR
zWbCMXvGkW4JUmXYNkf;-9Qyh7C6)Y`0|stQOB6{nWj$_>FtR+Sp;Tr%)#G-Ewq<PK
zCjI;Gl?S1yTS=LG`>gfP2E7<`->T`1zUz&MSDC6j%u{Q$w!zZ-caujBQczHxpg6!r
zmf^nX+K5l%WX7%MAMETeqd>P+zQbR7bI@iUKbuv7F&oq7HeP=D$ogPb5^33R?%?55
zlr`6IHgfKtcHU4#S@!sYWzEWo#sf2V_dBpBB}AUq|H6<!>+1?7gN6?nUMVT2_&)4?
z`qMLo8Y}qpl+-(kGb)dqdiJ4V;FB1K{BcbObE+RrnB2&mb20rE<r;bD){xSU&4Pl=
zGecZcZk+cVnpWKqT@)vKu6WS>y^~O)UQkf;T(A0x%g9o@UPiI0j<Ts|r+D4&H`mI&
zIAz-8l2(1%jlQogct2b_eyq~#!3t4U)=X>{HnrtiU)?J6M{S0rh1?5Ts(ig-o}ZSc
ze2KJw;gGAcUgMv8&XQ)$Jn)j@kjm&+U1HTw_wW`E53?7f6?+1($^D0DKI!j$XrI_;
zC&v=UL)shu@QO&Za1B$dI2jTeuxhOGB9`;}Gd2mYrt2O$5+7?Pcyqk|z`o~qq6Zc`
zsoU<{I%6vJkMr*~&2*d28l;*$W8v^js;=^3nhn*4Jwi-5$ZmdOSyW5IespG->#=Q7
z*Idf9H{RZ}{c>4O!Q9((rmr=pjv76d^Gcj=PM&t#aQwz-{+!OfzD(MLGp&;{?@h_s
zWW7EnhVud#Qcd9?HcKt5`5bw%f(d`<@XChaW_g?3{s_FaYw;TQ4cC{3MrE&#4V`{J
zWZ-SX5$SEV$x74Sb=n3rR7ZRiH+(M9lr+FHb9wlRb$#2sFTW{x-=IEiexTQO3&&%J
zqAQKQtnWYNd2Ei+HfdQ|Ct0)E{ZxFiG|U=9_szOfl^l8Ys&ij&sVTN@PnG(|u!=g)
z>|te&Ys+0JnOfhh_GD9XP#kvg!nGLwLK*wxVul4i54E$!9j+(7xf9nX%jUR~yu^~x
zVpeajtZ~2hQEWm7oj+!ghwFecEv@#p%UZR2T4{H)_I&*mQY|BP?Mwf2!8;XJH1&z)
z-{*`P(jLy;y>OVskR7Sql*HpHt9KlDXInh7mKw;Jr#P=@Yv*j|-JSM{WsbLG3al@t
zukljY@JI6Tp;`<0yr<)s9)sDt6C$PdxQUT$V)^gu3)+jy&y=|yDtTR2kuktiBW$2n
ztmLp4N_)b#%I)(}HJ=u)SXA4bCvmQjvhrMTRDsXxhp*3XC?2^9E6?i;zFK|6HPu?0
zy1g@Dd*ch^hH>219sTEMJ<6rk-;R-7UOck3uWg8#p&k2GSrq$9(#O1G8(y3!P_jDI
zuJFpV?&dyY>nkb^`(Kc9*SeS0XzmT?RH;YvC&q5;+-o^C>Fr~ybfrB$K*y2!=5xFi
zQ*+831KKN_TOvPNSs6FkZd(y6$!bYd$`0yVG{ACX$}0DFSr07oCfm#^h?^SkHg6dj
z@Q+;;vhl4ABaZ*I`Rw~wS@#q6hLkrydtO#CxGwZYsM#Zh5qtM@k}SW3SxmZRkYy7!
zi1ez@Vfh(H-AB#Hy*tO_V44(6U%}RGa(ACAWh=bb^}vpilgmQAvjiX8wUl;5^N&t&
z57FN)r|kMLQES=W(vh{t$l1F)XRq%(xAvpsWbaoS&IRwDqqRlKzn#%9t0+>dPu8`l
z!}4X^$&#1XxEDSQvpQtXgAtpJt!rPkd?J0|RylW_tfG|~F_IedNXcc65vx>e&#iy{
z;cM89N{X&brJZ6cg*tgj;=@Fp=Soh~>?9uBykL|!Td&{>ETU_lN*Op#7&dHv<p@*D
zt#Yf&PR?6=+u%s>7-mSVpI$+XWI--z^c>dyNX_UnzkrAe&m*aZ#qmiWt-g9HEm?ED
z-h$^?JM!|xHD0evR#IzRWfyI7=A~HeDkk4g4Na_mB+1~Yai!bVLU&hP8aDd^s+xXv
zjaU67l3&u67AXVGwF8c62-e(E8!uHNwPSpotK!%=$p>~>HsepsvS}Y837EA8YpzST
zaaDaVcHk3_N$%}I4-@yfCP<(wK5M<kuJwB8{UC<#e#fe?zWK<lB-0}~2K&X_ZO836
z|KR>DzT;Loj9MV!>5;88d~5iTzLcXL{mvEAc<ZhVatr9o_jG9(keRV7t7xoSR?)8A
zagtY-ll;!7Z*32tF+J{;gi6Np<DbvFA^swFw_N>!adDC#>A_l`#-<j%zZ35{wXd{n
z>pV%-HSSpt6ZQ@o8nJLwtMr}9hTQe(%O<UXKLK~_fcty3GlriE-zjBlTkSfxe!&{|
zOEauz9&&k{^f6-XW^~)i+jqv)(3B6Zg-UleGc-KiHr9H8I=~$wxn_;K^HyG3VCJaw
z9a2}Vf)8dD6`?P%Kx(q*7?7pJQrEcCmY#dG@BN##?)|8~2X!`IcYU0ksoKJ%Br8R)
zuN}EiHjZL8*OvXRtfS!K`?g^|&T;%`PRFZ^t7fe-v63=sagq@kXXa?eCCxp!y4grU
ztgN}^dQI-b#NAI^8!ySzPAs>gO`CC(G;YAOfcEK<(a&elikn}|Vbvy@@8~p#S9vlD
zrNsce_{k1A&7hjvk*D+SyXBXybpM!%3c~N&6~tim&D-yOI1&7LZEc*S>$s~N))CXC
zmv>0lifyDEe5of_b(S=UJA7+)dVtA#_q1)BF3UtGeY8HkWQO*VG^-I6J7;lI>PIef
zay!(*-hWSPF}KWf`1WuKzX8o!FROM7iY{Egr<kH{Dg9~fTH8gkCu94L9D~e?OAV)u
zT;X@@sk=^I(d=g3#UA9j^QbCZre6SNLCI=&PG!x$oK#=FsKG;0wRPLv;@#Fq8`U#>
z<l`oLOGhcKzLc_WQ^ocja`h)!i<uj%0&BJ;>tju8hEIPSzwh?k0XMw8v>s2ODzQ&Z
zzenx&X;jDO31JT(n8a>v+&gpJ6%H>(b}L(EN#Dw$t|hkPY^m^vt#7;to-1W+JZ_B2
z#F6bY7rt6xJfU1KV4+?JV_-YE!Kv@1#+%P`uiR?*z;(RNFKX99&u&N5hYpQ+Ft9yp
zv$RawzUtiffg>Cm7Z_z`*|hI5({<@AdMkUx_=fXG9my2?wJRf<*u%CLj=4Des^a}C
zQhVmiz1l~%RYH==Q-8UES9hu52sM1Y#gT}N^fB5eSJ}`GWIQP^-C+JOE@a(KzlCSU
zUWlBkFmZMY(=7Jjahb*EO%@%Frfa5dy)!g+=a_Z%Pspk7G8U{@Gy06pG1DdM3n(4!
zQ~If%o->a7>1mSh8XFJYv{Kha_S5>67*C#b;(Fzp<8E~WuT2}TXrm}OTDHihw0P63
zvu)=y3sNlSL|?iWb+Dx(Wa=ZY>(;wn4K2|E?CQ$q(w3B4%tA5h#)+E)7xq6gc95SZ
zf6vYd2b*l~V@B(S)ZZQulUj7==;xz%S~s8kN|_j`mQrr9f<Ij`_1^Gn8w2!aXiaq(
zUK7}HyE*;rhh^!W1BVsU>BF}qAEqZY4!t^}Uh9#ol%E34HT~wHD}zX~L(;W65}Gpg
zygtSS9BwIhdBobU^lH?ikfUrWLvj3uIj(X1c#n^r2SQ?Iy}tDH%jpR_J;`UZ<(l?g
zSy(FZXr+zvaQ4jcjN{GR$^B;=B&0V#UG8(ga9Y30>oc}l+gwwbcWvwD{o7AoJ+W&4
z9TofiGrT4bt~a=JdC=9t4Kl`^2bhbZ=@C<&aNd!rwQK56TI()1cqteB#q!O|?Vw4$
zW;dO+7}e)&{pMZrv&e|IxA??>Skm0^xoBNt)3N1?mG0b+II!~LiHMZPmMa3dt!<x9
z^*`q~yYDFZ5W4x&O;(q~LT>$WQ{Jh`(#D2uTXbRVq4geTto@bsW|}WOEj!Y7v`5C+
zab9JEWYqfgPrMj5@XS<k?b!yJfsq#K<4VGg#_=?1q)zG58v|x+QrQx+*Xe@v#QqWe
zx6b8iZ(DlDu3S!X>}97pw{pivc?=uh5aWGwoc)0P{W4Znw+9Ee1?{aLIk_H`p24z5
zk0vXrtiH5+^WEIl<dSiHx3E)(TZT&yjQLz~>%&{wpjVl<-$`v0zc!h_B20Nf$%%T!
zStYISoF(7tu&qaGuA5t{xqxxccWq=*n^=R5Qh%|;4Sw^cF;gt&Dy_OWNv7mV@oKZ`
z2gZR;mBkk`FD7V>+SRn`$?fwurVpGh^=YDIkhPmzm{au7{O!gmL;Brw|G4B8^}@iA
zU@=Lt!5QnXw%0DsbJ?|Q%bomLi94qyPF^p$FZYj-81>M^bj9Wj!Ip!kMqZt7ane|a
zJ^0js2Q>fHo`YvA$Sv|}URcbYk#m2!-10mR_2ADg!6T^p8}}tQmCF|`9U7+Rrk3mC
zrlC05*{*MXf9J-uaid2nZ9J~`^s-LQwb%!%xqI8~2MuS4OI}kNEjM~2y8QCwltG-?
zb38me4tv~eeA&9!tGuza(tX6CW#KD~Y)F01(oR}5UAOIjq(0?_@zlGI*J|zFa?q&r
z_50cOHX~nbTs6Y8^yLdbJ-J=%MsD8X35Lh#rn#(2-&*u3s$YCCBjdmTyDJ0hKJT(|
zX}&r5vgujhX$f9W%CiedJN(sbQq4z;_rJT+d6=U4hk@tVZ0al0B>TQ?xvY!BWuJ^R
zDAT^Pd*<K<U5@&2>dyN5*o3m087gNcEZTDZ{xqG{vuCeAetg^|_g&>x^pH{|)q{2<
z#?mop_~Bu`)C)5^_hen1HsZ16teWwE@b;&!3^$Pu*sXVwV{KDpAbVnS<=d%O8f#^1
z6*8mAhNk8ItF_M7@@p3G-zChKP2ZlRp*m~}N^+E>7Dd~9__ShsV0uiz3)#a<?Q1uu
zPxOutaMj%~Fg}~PijvN-k*(J^%$G5e4S&Q}P7QoM#-sLzN=xw3#CLt1o{b_;mcA;M
zK5lyOkuB`uq)~UbO;cOhd^_#Hn{CeK7VW2X>D;t5v-x6!n}=K#d&mJ3z;t-(E;-ea
zA6^ZXB|p@9rf~R<*PPMz`?!+UHk7rxZ82G6)Ds%+i5E$m?CvmX?W;Fpt7^20`(WD>
z=WWU^2FSfLB(K<O@_NMfv^~MmD|ep>aHNQ7A0=By+=_HLSa#dj*(m7JsTV=BobKH=
zQJdsyd{>_-o9ewXJ)Cv0Ek~xvSkEf?<j&OB3w1va8$3wEV&Y>3y)zG%r)?R%XZKV)
zDTmW4E0?;?P+^y>%HafkcxF<h!Bu=US#iMo;n&0;<UehCXnK-@WH-j1GI(9K^j5Mx
z?a(~_#p#W_mDgGnM)zTylY1j|a*SC*`|9Oe<G++fnafgT%t&cET4wf#+o!CSsLkTu
zFn;q|aPR8_<JQr&5A&w74mOHa&YCiP`YhYcqYqqQ8;&(m%o!A>+efm9eUZ~|l`P{#
z$1GLm#(a+VlNUqJ%?Z-fY>x4cC*9&0$`5*N6nOS_i1WLkOXW8|l#qi%^9CjwY8Bk|
zoN2K$jI?kgHQaI5_Ni%O6E$aMuDEZSZ<U}lNNU38!OMmndvTW~t(k1O;f3AgNwZRO
zwIi;rwJ@`vWWvvLU4XT_j?`;RbsY0HVnYeoo!4HH+CMFiT;>+n>Q^&G$J()0Q_jO;
z__Ru^Pus#GAFT6Sx@Lz(`pw%xL5|Dx{9e(|pFWYLxY*fZyPcJK-A4KBxsJ=piiUID
z(~gdnEZX!oo1CUOS~bwkvEb_Gi;)+{q}IttE!%Qjm+{=`z|9YLc1TMb+O|bav`bww
z5vAFXjU9C|%3tl&(zx7TdSXFgN|6Q_eBuiv7ha5UNuHZE)<so)jLTN3;`GA?3gegA
z4{3^6I%c@`?1`HaXPM9qhvz9y-)5I|IJ;KaJM$d&rm@Ck33c6MRn_#gRjGmNWkTmj
zn&nz#a+;Z0S#kk%<2>t?gP2cTj<~H9d^!EK@#W`5+wTwd%eb0pym=S({k)M2Ra+?r
zFFFHn=h;j(!_=D+kJ}7R^w+ID0=ndqeqtL*`=7GjZh04&JXWfDw`-Bug2yz;Y~9fF
z^tQ8-VNAJkisE1UTOH7;Uv7C_bD6T$#f#TwEKD)foUXQ}Ux#aP>m{<{(4waqSzCPO
zSo-I?hn~zXP2Oe^zBpi%`(v+nQx=pL%BO92$}!)n;s0{|r`0pZIIFg|dH6`I9=`3Z
zTta0k;|<BVJm0>e(A?g6-^J@q50qb~-F3S;FzP6yk6577rMmDv<gX>(cgHJ?w#uV<
z$@|LOo@^|=|4{o(zY|`K^g}~U*6Onp<ankZjIQh*`n0ceh{glVICIL5X9+r-U22t+
z4s6<Y;`y0AWmYZHtEtC7F1^64iU05{gkR;IxAdj4hsXFAr1HpsGw6d+ahTe={EpQv
zsg;SAetP}So>$Fxcs5ZhdZ-{PEaTdQJ)a(5UaD^Oaz=#J>iZ`ipV2OUch_iM*`sOJ
z5pplJd>=Q3?Dwn@f6_88b~syJeq1hRYg(z}wqfI4GG}z?w%#8)CVa`VlM{<3FG}CD
zO!f1g@W$B7Gedk|$p&7$GGE7Y+6(Vs_nkMlM@hD?w|V*DRZ+{vN@>@HR>kv2Z#Hf7
zO>bct@5kb+BQJ(<8uv)+vdYu0d{lNY=)a0#tUV}_eD49L|2gaBF=INPO6OHgmh6}P
z*pxH%g5%gXAN@I;TPnN<l*daBFQiEw(wt+zBj0c#yTw~)vGsXxWK*S{z12!Jdk4qQ
z+JJ8`>$7BwT+B*?TY5LkDPwg*R&4T<m6v6_ZA5=4r*QkfdU459dq4H)xu|(>W?Map
z@EO(`S6*BaI<oY`w&eBWtS_@duWy_-sBEcWKgy9+Goz!cS1FD6d()O!o3-nv?xYIa
zHGI1dvBOE3l+J(*mX*|o@$KVXW$#!jJf6!Q>1%v+k-x6ymt`|1piY(kUkk>_`6nLW
z-MMt*$@Z;-nqJ#TMGxA$WI$m<kvrq<x}Ba?ldnqsF|UnUdfn@cTgFNHC%exQ9|I`|
zgIYft+q@<#-}Ok8@q4INa!<_hbShPB#$?<5&seMfu+zgHay24NkGW?suDI`Ab#la@
z4(wC%vHls=$2uZ*pOD|UAvtq-#IP~+7w3=u;k(7JD&yQ(N%k}?*Hzm)Q?|2Mv-;nQ
z(SKB@FC)K$uPA?XaJo51`DEM12EA1>3MWlA@lbhzeBjwD&ohgQ#D|lsWUDTpKdoqE
zc(X}|Y&l@Rc>Kus?MsHsS3Mo~aKFqVjT>q^KS-TeZT@oCw1yP-GRsM~qNU|iva+OH
z_Bzy^yv}`||H$cjW6ELDST{w=T}4l|$XDa6R<|E~k&^rW*n6v}ID)QibPTt_-7WYa
z!QCAa+y{pQ*909Lf`$Zl3xS{!+}$l$a0$U(gPzIze(RjG)_?b3e{<DctGa4e_10&1
z?OC28?I)SpxX2|(Pt}=XMC+_cz@OlAcgz)#N6ECw{&U&W{z)oWs4oLNl_4W+Fg@yO
zCJ6A74#AqhmI`Lml+wV^>9WlZ`!sDtp>damr((UK=<>Ikx4t*=9VLBEu3%!kIAzZ$
zF|DN55UM5hm)6#J3j6TiaFDM}R6^L3Edt|axzpvA=4)bVO64oi&k~b?8Y~VHC*it>
zNFWse(J*D5wnFcf;weJezsAeMvfZLs0iVrJche4khfa?5)6X_faEAyZPvUJf`qB%X
z?^QK++cmy;fzzT)q8zOJeAKAj`W&WvQ!$^W`l|o5`HDna%z?^cfo|B7gOlj$Z%z-p
zX_o_9PSbT)jE(q3=!5t5ex))0=}k=igOfRI#Ykltx8|cBumcUeQE!fhK*hof-5y)F
z-*1!}%Uu4rPHg=)X!nhNKgQlbMGSIU4F)UI+rHyd`ddmQif9Pn56AkJI+fMX(v85;
z_xp(iW>w$4@@2MoesESk9sPUIu)kn)h=lVM^>;J|LEcePZjCb(t~l}M-hxsJ=tXHr
z$&M_o2)J%nU2&qK$a(JQaG|Y|pxYM4wa&oVWlHtXCQ7l+3fW_+8;&v;f6UyPYkSDL
z7t^F97ixK{y20eAxfiG0K{bl|4g3D##)I;vLyxu=U`OzjTVl&WS*K6jBW`|Ab(X7;
zkeMOiJrjDN<9SFuBV3y2Obx5%og#?)rQkR{7udlFIHV0sLhV^3I!xJ1T_FC4+~H5w
zx<^qY67^*kwm&R~-!<;@{M4hUu}0A?{M89x>nBs)YpD3FzT4h+A4&Pgr&OMa{@U)m
zFA9_Pi<x)dh93;m?2FX?^e_M&Y@|Bkc}(elx7beZTN-X1L$;Imnl*q7_(Ptys!(z@
z?4l!_P9I&tQoyI;?|yFZbYS3p^Y_5ZJEbwzjK0mzlBn1`aYvVhicuJvCXjQPdX}B!
z2^|}P3!c8?E$!x@oqyD(J}_nbi}7|Ud5ZW$!D4V0P0Gr<cB!l^(S49=FCFbCfNx5)
z<K4!qL3BzRl&|G%>w`r{l>V$6PMJb=zl@8G27iuq6@K=YnYM*^twFN~Kt&(=)bm&Q
zL+HoB@XaLx$s<of{CL`cwqs-xqlA`yHnr{h^~_{rt;pcyCuPb|#*^rbD9)jSkB-B6
z=@%13ZoO|T@c_n6jSdj1%bDq5oP@EK7uN@F<x%V%$$#@C!($#0nq@yRUhO<UYK?2@
zj-H0cw$&bu&icrO?~=uAEl>Ft-59DdA|=>(f)4EYlS@B6X{{`GhlI!oL~c^64(0Ad
zlnXxVd*%5CR~joCYuc5PUls)K9*x%i+Of7iPrNfUDXK`Z^u83Bm7z~nJGz)ZClKK7
z^+J>ZWWUAw$59dYMzvGIMwDbmS*PLfC!@vaaP)|w?{&HfTF7g=*L(74@~3ieI$>Bx
zBaW;fk7TXaagkUaIj;yW?aIA=xz)&_eU}m0?2FoN4ZX@4Qt`I)Uq1%dF{T=BYKKXR
zbNKSuNiddNuy(r8ci6D{t4!v*1;#_Z@xIVH#<2uA0WPj{;rQfhaAT<aAZdRaZzZ<{
zM{Cg9vPvWGugQ!Tj{4g$t1hOE==Am4#wkLvyx~v-%hkU|+rL9GCO%D|s01jPg1~_x
zKmsWe>GQ8&Q(|e@{QUN&dsNso>R1MLq%y5e7Uc&8mx$~{yeAGav=04%+-K`kO+)bt
z*YT}Ixbl)=1Ok5qWnV8-wo>PUi*Dx$Cn;Xy^)hh&aXVB<*EgsL4p#H-41W^4kx_Rx
zS?<A@NHne(rP~#Bp7GTwz%DM+Avli`H@^3x@=-bz6WSbEe>Q&jfrc4J$gPJfBm@EP
zkh%ZDG24oEtjF-j4%5j*5Zbb+fcc4szu00wdfpVJmhYT)^{*+u!DE?<4yLAB7G;ED
zLipbP3kuj*!Vo(^f?i&@-^O)B;?YWIw_4qd6Ri*=ii}Psx-xL)+JR%@R#hdx@nNkS
z;x>n=z~?L`X5A@Ik3l9v4B-rht<gQk>zP;t7Vl*2_^E9g8Lm67`l#I}h(5!C3(>V&
z%o+{qyyxB5*li}{z?7!Eb0t5G#hmZAn@Ymfp)0gm<|jbolvoY10SH_SnqInN-w2^Q
z43xfheYp`noR9WmE~*GzCwFX8t$-q%NrubajC1TP!eQNM6NwKt3ZLTYYOPlMNJMsm
z3;yU-cD@;&J4eG7WX$eb)*wDb71DZA6XK5s;;j}W)C7E`pHOnHnGI9SrGB|={Oz^o
zUPUth)Q`2sbyySX$Q`jVYDeH>YSg>j`L?Ej99`3TF{}*@ePn6~^gj3UR=sAPs7x9q
zKhcW;+J+Ln;_LD!quWxUch;&lW?)!^_1$hifRu-3%F<Y`?ayYZ?*nxsXM#DcZGw}W
zypw-u5ba*RIi6!`<AXCSoHg*x&9@8=j@eYAS)!B`f%_)Wo^H2sb?HLOKo(ioy9mv}
zxvGa5JeZf^Yc6kl&zVwUq9t|Gp9KyI@|FOWZWg-Mrl%*&bqbLIAkgWLB57KOG#xMC
zM;#9C0qk${)Yfo8vT9UTqIuMS8niv$b8)e^U5%1AnD}!~oflb;3Fl~I4UT$4^_s6E
zT?s=#(?_8V#edN!nw0H+Pk2iiZ1%_0tx9WuwBiR0ZC{WY74CZ#KaV+!SYA3}<r2F>
z4ixVbM(z-x9Itd>9u^KscCu>%4;$mD_1spka=>DweN*)6q&5X^t;Re=Wlr?@TaSa=
z^3g1+anLC>3>Dz=sf};*EzQ*_F#&ZrqoK0F$k*4~oz5C?SY5^E3-KG>^Sob|vVmbG
z?$61<y==uKBvS~Ev7Xf+Yeb(D$8vz7!%*(h-?^MbVkyRTc-Gr!o!T45E8jVSzIHm3
zRE!vJA#tItTGXT|;eaOp-eY^9HNXj9zGPrEv3)$8E8#U1rFVcv&R-@AP^Y}W!m2qE
z;BmeB_0jZ#iL-3jmyyMiC!jnD73w)%CH6O-?sNmuhrr<wJG=Tp`OP4;`Vo75k0kn!
zP7R|gwBkX()vBHHfR6_?dH=|<)%Sq9If?1o<KwzGZZvMb8m;foH`^xI!Ma-HUT43q
z<60jo4b)aL`NUaBv+gQ&!PxuQ02$X;-?w_>F_7umxo__?1Fo+Y3d8E-Z@1jt_C>r(
z;MaOu1%qRUB<(1uWPWNJ+kaDf`gj{^u3bJaF%ZujjbtZ(9G}Uftipcbm@^q4p@!o0
z(^iiA@j9m{*t@RRu6L~S3g*A<q4<Ey1cp=E8Xi>Q{aJ2?;>QiwK0o6mQ-h;V2Na|7
z0gWuDiC@P4%5)kn$|t~<HNT|h*ZD*(&L1e*XrGYgPZZbn1@Tjh7f@(7BJu4Kru3A1
zJZzBWTFpkGPAbSWiUn;63lqzP{@!dR{lfZDT3k^&TOo$Gmovy_<LQ&!p>l2M!2YgY
zdmdUQa02=naYGO!wf=Z<sh1_GkZ_LGIq6U-^wGa-How<|v2ZAISwH5O=JpNl1|IHF
z<*L2R_jUGzHdTcj>u31Ve7r3|?Ml)uWCCRQx#JDQ(6+cY4_4u2w0BoMQ_q~%$o-5L
zvI}r#S+GKVcmD93dPn*=#l9>g>gk_;xNdkV?hFu(&WlZ3_ZDFkU&98ZOj-<4zxWU&
zc2xC%M|59CCmS<hZ)1UgmNmYtsRtD5?!$IoF9muR(tWGJ-L9&XWcK!9h-Y^oJ;aYx
zp&wHwZogwjt=UsbA2MdYqGzxE@wMco-~JjJ>sBAOnuD+993zjA$1k+C!VvKxq7u4H
zx8p2+b8!JF=c9~#(pmc*hTW=N;BHdZyMf+{XqTpwHg{hl)Apme#ZOEc+0pzHpe_ia
z;i>~u8B8YL*!05>SCFvm?Wwi?F+~gOEotMNlY&1>ld=Ax;E=gY3nf*INk~5+-e*K+
z*GI4Q_4&hV=H8FD3y)79A{B6GvhsuzGRiC6EIsp7rK8{X&^o?LuGc$$*6cfScn4j6
zH|j#-D*^(AQrAbL%WKHf9RO3m@oSE^`yL#k2rD}Ieq_r$5`8BEY}{c++WzkwFqiId
zLj%t<jW1Oa>jiwm#?TnxF>on5a}n)>!eUhX9Ye<ecq;Tp@aHR?v+3ycJ4N_3KfMO&
zb^xg>5qM5g<g9mgtK^H~h<dIl$uHjqEoQn%NwhKH)ta;6fd>Q6?H!YZ<>!B9%ktm9
z*S7YL=k`|vP26JpBQn75{W}&pxN^g{tUeN?BFyd^+Qz4iuf(9%7eXw+I!nPX%I55=
zf{(eqh$oYZM>7`SLjUGSTgcY6(?|OLxoL<d)%Wot$;fRpIQcS~>v}=XJr7-j4Kz;W
zd81rT{V4x;s`Te~dz$fbRm*~QTa$ZXn#YE%QoZE<-G!r*gr~`y=1N(q*;g|Y!*fe?
zmQlGZ83Z3fnw0NN|JKhD3ElhkXz2MSHgcg&DF(RiJd6eI>7jPK!zX@LR79?P#7ih=
z0GM2Y?7z~_&j2{Hq0ET+Jl;)T^YmgLy@JSp?4r&(eiGo~d(KYJ*;e=Uhu`uK5rb@+
z*Y9Mw>we3&c+zK9^Fr()XEY#rkdTfk`}rR&=&KJxTLBzJXC3eKTL_h#PAXNNId3bP
zo#1V(>e`nHSzC|J2Os!9td`-k{e1t;nEf*sr~hMdKecJarbO3Z0=X!6AJGqRa<}2d
z)Ux5-lB6#WpeAsO$E9nmJ@c+_IU_QHx2ZlR&w1Y)6(NdG3yo|=R66>`w>_r~CZW%s
z^Lt6a9Kw?Lr9w>J&p#2pKUI}{P$AL!YK-yP`)yhb<wyJLmU&dXE(PJHGLk(I9!JXC
z@5ls^`qmh4J<(bYMmj5ZwW{(?&2D-Y(YD#pWgm_zFYljpdcL2%j=LN2WhuIeEk443
zMaqbv%?zFCuUaBO7zBOGyzVblnXbp1&Ck9yKbiZrG;(4o%?ww6Y~d=2WL2xR<R$IW
zSi0(;MN4Il>>c+E#3(h~zSmljh^1i<uo5r4o0digr27k&w=KTLq;w&7*I9npJW>yx
zr;UhsFN_oY`_F>bc00}>#t!yG)T;3xUAH~LfxJ4Lw!8J3sl@yh#pPu*VF?lxyP3UN
z<3*&uO>DK+|6$(D{N?L~JwfxDy?2fdiFSz2a&GGW&JqVaJf0NXJc}JTfcgunC8GMX
zeRaccVLUgtkYB99nRJ%aE~4*h)I@MK_NVnFa2RmkcRvEi058Lu*F*gfcc<LTjVJ8X
z3N7M^9D5L;HN)U>?~}jB#&6Gck5oSQC6Z|D?Ol56oY7a0-8ZX2qV^Lb=cl>*>GUaI
zP061olgxBJu#AJiZh<RhG!{=Cdv+1wmJ9l=tw(h)o~kM8YKXpbP^f27!<;Gt91Sd#
z0SQ-@QYkDL#oagW@v!etu0pQ$vS9)Ql=M)GN(CeG5F)A?yJWY*J<$LU*p3<8ql-@2
z5sN|)XX9IFH>q9|8(}v=KI_mM3$~tb0WFJfKm9_2d+TsJE?i&iNGuNQsWPQ?i)-i0
z`uL9k#D{EfJlX?_<&HlY>!+cWb&Q?HjBTo@aq|z)8nKAClKeqHI<oFkpC>LypFOX~
zL)ACmfhFc52UDciLNwy!ryL(aO(UdQ-afvxEj=VyNS<%~agjS&ueT!dXHHJ}UU<F#
z2hMT`@4b-)AHb)t6XHOaE-B3ZZEGvAnxrE*k2Wk?<}(HrQx2HUn$n~7K5Y<>8bv3=
znbyl*erk%Nz2*1^k))ihao|n7j-iOF&D-G30@{<XTJVuRgj|vN`NDxFfp^s>-=J@&
zP}^S^m9%{`<$U(7Tq9IeSGWyBOv+5gEM&fcEe<Ddzpc(c;hrl2kl&)5jJSaqxXiGz
zqwhMfJj_-iTJq-~B@fGnBLh+m#6^RClQDj$p0*9a>x%QMmrU|CctDzU36dUKwGE-5
zY*WAK?z|%wFT859M?-6n@*eNSkY!q24=OsF2<NHw&gxp)3vq){S5hiNj+iXeG!F>C
z-JZc9oIAX8&@F#`0utc+R*@KBPt>z1k=Vch#z@7B&I{a`!edm#c^N^#`Cuc~^uZ&t
z-^LmZC#v~8;#Bv2v?u$YITz)iqZ4@)tBc*;^P!U@29SY6JNNf-)D!}sBbOajM*Vhs
z--`Zu9+Fhho*HIvP}en9O$g81>}k~5b)083xS>h0f|Q#OIB`l9wNGzf=w6p7RZd(O
zp)F0+(OpD=oLAb}@cLX}^h~z>mbZ*BYv<`F!hUxEqn6<z-~2~V)nJ=d-Em5+&@BP@
z7cx75kbr2o)rMQ4c68X^o$Ux=&}sX|Vr4WQX0Rpp=>C}T+M+Y}dB-5t!ZOr$3-<7M
zbJjl(WnE8i*4Y7mqjmdf%k77;Fk#i%1(;`J`3r~SIcx5X#2!=oq9w{Nv{qc)Z3*K}
z#+_KA*SVmLFv=n<iBZ!k#hc;^sWE+IL|HqfR975&_{EQ9pBk*g9_Y$OteH1tCM*H5
zEt!NLByz;AOf~4!0qEa&*^a4i(>YohXNz=b-7GXQwbWHGwTzYS@T;l_i+)l{J$7PR
zO7{VC^=;KIug**qS0F;G)C44T?~^>9<B_SN;Vh$Q$Wc8D7lV+$NP457SGpp3`(%4!
zDsZ#azGT*p$K7a1I92+V1Lw0cv^YB>Xh9H0lB>NCapR6>mF{%AGq9a3AzPtCZiuK6
zTI7sRq<n}e3fyQ8h6AjFkm+J~ZI@DB+kM_Y?55$}>pqVoI<9mmHjHV#_zQ_k2)8>5
zgTV4i*32P#-^k<c!TGG(5`)|ieCJl&PFF1{G76qDGh}G`1+<-P<z49Wsh4Xv{@X7C
zWIx;d8u~gzna`q4u|{|GEO#A!tEpY{VVE4wlKFfbxcZkeXd_r>bi3HCZG2UkFZ$bj
zCTGTE#<zy@21(LjG%i%-3;iC?3is+iUkEh!s3Bs~klbcU164G^g?I-k5dYd*Ge;>s
z!jqVC<xSI%udPiD>s=L|LO)X@M8rUMe>WTR-7V$Txko-%^OAkUMksdz($lrWOF!p|
z?)*M?q5ezDR|32_Wy3jH(`K=g2T9kz0#dcGV7v%a+Ze6Q0BqOgQQddPD-~^YTUql)
zoAn{_Mk-?u^zpI%GwmgGAMA9uWFl{X?_tlLrB1NP3Dh^z!=-^kJ`FB<phP>F@Vg2E
z|3c?P8QQCk1i8+XugnZD>+gM6f>o7wN1bN6@uNDhr2-F~J)^*fxh7pFhE3PB12u)O
zvZCo^OOPUeEuadP_TW9D6`k^0l1KjOu+lt<I)plnlb*2l-t950X2XG_UTjRQt%}ZB
zBwoga>#L~*9Niep?)Qt(ozE}t(M7RM`F@9H2%F70H<Q6G4`XaE$u?VEun>QLx<Kw;
z&>SkKOH-?do}<V+%T=j07M7?Q>9x5qlA-87ES9XswTXaVb`#|u$aM?Co3s3B$`2kE
zWrj1dUs!JEe?)cqh<d_iX_q=WgECCR?Z-zzvT7t($j=OMp$n!=FpWH;u}_cyTvI1%
z`=HM33bkO}kysPZ-Os%Z5F3K$mrS}Bkv*;0ZYnF$pE5e|CK2*ur&>(G=hnmA4RX?j
zA1}WCIZH%U_>^!0(@Gld5-0U37D^PP%?k(c=BmW-KkG^%9JM_w=<B|79cXP5q32B4
zkUWKD;=i*SoPNFd_L8C90tWDB6)Of->@|`h!QIv*>|(*!`+Z1fq}U4Y`a3;uSVo*~
zll_P*CS6w!9`{iy7;!#~e#w;$&8wgI0O^?7EYBXc+fn%Xrri~Wkf5UNdiRu<@ON_w
zlY7{-q+PU5__1k;V~}}CrF+4MFgWM7hupJG;!BX>$b?~Jl-!ck&ADaTkZ`D3S0^<=
zS4ZiT8FtJR>W>tpQW9>V3^xe20#MvO!vQq2qvzeu1@we<YtOad`%xrPE}mRek!IHB
z=$L!$DJ?Z@I>IrAZ?`5DFwohy@*7hC4Ss9CH|VGYCyR4o9mIk1ODBV)18Dd~$kg-B
zSKJOx`{Y&On}h(3vGJt{6tQycjZt@U6?_%is>*rc-OPi$2zv#4n4tU+^79i*`h_xh
zVi%`Jo<k4t8Cm-sHMoWme?YK1080y)fYLpwqI0Z7^Sr0rwc`<l@k*Lm_>4;Hixk{V
zFnvYxhMon8Ryq8;!+I3u8Gk+`SR9eqa7&7+OEvE<`c*T9Ufn-QOd&g$)+w7J9(}?Y
zPBx#hcVz`ny4{Y!>+8T`Hp@Hrd@jMqmBnoN`={nfNzTw=*29`zuq}Y%)h-+0jM;`N
zQXDQ58ZqG5KH3~R4$EDxdgMIk?P(;Rc%ozW`bDgWZoFrY`VmSt)SM+3&R9j)3m`>T
zj_X}J4qJ++(QBVRnJy6i)W#`^<d3$+TzIa^$yQ!Sq9Tt^SClHnA5CXBEJj1ut2<n1
zt@bv#suKfazHnbO$I4Z>*WME)yAVfM5g)1&pAGm(-o>j^6;U|=zy3}8CNG2u``IZ(
zX$kKYw!{0N=KU+KzJ|gADxKd&QTwFoA(MWo&zNOHuncc^%fDo7<}YHk1@L3g`p{=D
z5PoV{6q@2f&;`y{GXo5=U&Tq!PDx)jSTUx;Z*n6a)ZB3w$v#7kc>g$HxKOj<l9*xQ
zL9v|Nn5z`2M<COc(f0OaRinG#+B^S>^GW5zpVcVth41z6AI<G?Bc@}cIK{W*&oN*(
z%8KuYE>r!=Ca2KlYI{vzmnm$d?fpRdfqK4gzn$Y08_Do}Hy@dqYrO4vAbyG6fuXTX
zfJ}!GzcAN$k~q?A9Gp_8?8+=$Fxyq|Zl<WUXy%qpAPY$e*4DQ{O-pczp&c)KJ!Ghn
zU4Go1w<8i)I8v)j<rRxYYciOU*yc`afu-)Q>@>f&dLAP(0FXFLqYMg@uNE#gcIFt=
zqN0r#|A^6D80CVv5UMZ#q1xpAn}=sTdk1KtxWNZgJ_Wz}%!i<P!OJB2x=*8VPIQQx
z)3q$gXZq-)pssT=*(+>D>-CczCq?|LH_nyZ!pS5e&z?OCBYdmA^qDidVrgi?da;#D
zTB4!&G5?2xb4bI|_4kgX6Gb&0t*q}hu+tQD8abMwy0>2B$TKchVv4E_<5iwn*BSSg
z_JDhl{Hiu}jM>uYKdD-8Fa@f#W`HhKb5}4dsGPzeq$%rk4+&CBzKd6t=>#;aKFlNw
z;q^r^k9g4jIa<&-ezX&~M`nM5qdCP`eG_qy*LJxgYWXdayj|XEUewegwj2X=;|}q~
z?dwV-#=Joq(O`$}cJ?rTS;bP{qavYpG)}Oa4DNY9|6g=Y#Fdk1x(E?}?U^?R#mgr=
z!7%MH(!W|;J$9?RG3=(dM>BcYRmMNovi!Agc&p8KN@TB67Ih4M)LP%d{6%1pOh_5s
zpza61m&bl(q=5#b2tA;w_82i@q4GQ%4#j6pEgdWgS<?+&4Ox6=CVe%Ump+fK7q2YX
z<l_?C_s$5V!N-`d33YXS5*FpYuX(nS??CAT6KC?-mZ3Q5(Tc-DmF8?{Z^|;vS&`-p
zJ@47OsHlIU10!@dg3#g;`UFfebw8_+zVJdNM^OuIbwnFRx4MR1nQM9A9mg($A>e`1
z@!WULlk|csp}_EY1nMWTL(56TsFV6iMN^1lB;u7YDg+FpDk;F!#;PPK^oqu*h6CsY
z^FwxUoiM#3=q5uAAHX52ZQ*QW(iT?j?bA54Xz2jLqG*mD7#*2(G>!vZ)6XDn?(E$S
zOc88!RH%m>MLKTh9V-)}Bfn0o026hhbmy2h<vd*7R2H;D+r6d3fdW3kFav*wsUx(J
z6ry*olVa0B&}MeHc~9`n0R<qk_<1@6E15JDTlPc<D2Z%=Ji-1>%60<or5B|AQF;=&
zp38#Jd)<-G5h=}_NWMThaqCG~_r^f9#sE73euRq;-?<}!3?$0)fZN?0?>VPVKvQ?Z
zn@^UAkdA>=h86(5FzvsYWuCXFeFVrqt66uzK}9goE5qVKJDsJk%$bg1CJ(Fi`)4e_
zpI|x-+CXfYQaAuf(|<Y$PrP}CnlYq)$a~)gwg*j&rE#vKSEi3$_gEAlkOatD5}Dn)
zji)bOuOmJj(={}|{Hius6?`VHP%OMTYf-9}vd4w9=)Or*nzdn%4wtq;!3~k|+6C!Y
z^7Kj&w2xzVJSJd)9jbwU0pq<qq!0NI88`L8$df~eM-i9hADL)br=~4OLtb}rWs_z+
z9t6cI+i6b-vygY~cT`|ml$~>WSPPIT$jm6@z00Cbk+|f^MQ8)<5*ZYmuA#rbdNu@z
zE_;dP2|i}-1jLbfQjQayEw9<h&w$AzeOS=(WT9!R$i5w})7~wghgh=3xx6-U!!Q2e
ziER?AcW4!3p{}uRWLtd87B*k?*pUX0<#@Jn1))K~<ueQl8tFu=N(u@nHJM3hTx5tb
z`cDw!`hXbS(_1NKk&0oAZqb6+ISI>-*#!pMhokiz-k<hb_zP*QoR<L>Fhs8Vv^9pB
zf|1kyV{7eKBN&3_y{$G-6_9%Nl^QjKvIY(TPe@&SrJ~_x<E<^XA?Wjc*tx(Bb*feM
zcoV+Xuu?E=&DIGJFYJp#^8y&wUMrFn2TEs-6^>{z*aYV&e`K=!F%>Thl!oU&{bxJH
zd<wTf;3i%=GK32eCIAF}AO(j4FIH;_xk$+-;*syttEk3$xKhf*^>U7z4jp@^0|5t!
zCe59eS2Qe3t)80RL&?xzA{jqF7@icMW({DVF_Yp(2{-RU_UofFg|_p)A=36E|2HaM
zmx4D4+!>A>HPlf+-UNdBpLVhkH{zIc<ab;Xc>n0Y5BrqfTR^V3_M&6Q8#yo>GNkbi
z4*37y>*=jcqKjjawI%>-spru@a=c^D8WkLL5*EFit((}cjb9c(B-)g?o?7=T?OKyX
zj?YUTY31ow3krnOi^Vgb&@mh4F}Kd3SK#fceaU=kum`=$Qg~^S>75fi!TN!DfSnk-
z0|AU7d;W>#@!(t&A`MDnie+9xu-xK;zLy$TS|;P{#kZHn-J0(wy4ILy#ghjwc>uCX
zG;r0%i7;e>d(ti1dnVyQ1(iS5%BN@bEh{UlLX{VGLyn}99F-5{P!XI;mJT4XtyFaH
z>uNDT`REwH=GuGF$-~etl`|rW6{Jr4j(ypi;U*6Qxv_C?$V$@@x2HR#5O;2bg~R?E
zmCpd`&nI_L6$?&=<zNrKq^Pa&<GRS{Sc+BR5resOOblt#+n!<M>!bvua#TK0k{4cr
zz+jwz!V%2qQdDQz9a4NRe1JC{(cRV6VzuM!>@3*t|4@A=RX1<LS4+DAi==(Aan4f!
zx{3QL`4;%y<wK?Z7mXK0AAZSo;Aa4g=RU~r700ETUo~o>R!ZrzlS#WJ5}2OqkGZ3K
zX)Y>>@b>neI$Ca?>FVlIT^jER+d)=e-J^7Eai<Ep9soR^CI&mjBqnOf7+rG<Drv~v
z<3y7Ati0VmOpJ}qI#kFDYhVpr6es{)a6L-Q9I4+h?R1rwmlr2WJ-%_Zva&jR&#3fU
z!vE^Cf`S6Nq?0|it*xzd`%N#;Zy)*&LPIw+Q=YaPD<eNYQF7__R!)*wf!DJYdT<-o
z>*?*F#X)n21~{M<VMAM9^UENB5IrlrJ-9m(C;smG*j3bPNBgWaFQ}Y_nR)9}-YKXr
zf%?l^S`|PTD$dYZUG8Z^jR)>kT>vZ<oC|&9IELO=cUdZkfeK|RLSbMz6_bAe@6T3#
z3*AYv9Zpq2!=uTjprqu`$P{1$bI=|FGl4Z_Wigd=2XAkd5v#Q;UQxD;3=FrGH{+7Y
zK!801<u@VliUv7SU(0CnNW64R!NbE7>g=fZ-Rz6^Hay)-<1}KRmJAR^<7gH@QmXmJ
z#M+v%thIY8ag|!5$F=$zd*1T?#siJ$)H>f1sW2s}+@U{EzNBaLSeTfYTx_LT=vSGy
zivH;c0e2sUYyHWutE)@iA+`_obrj^fvjMEU0h*c<2jkixC2vBh2ydfaHj4Q%vGrm~
zt#@>El-wft;qv#$$Ou`*%~<&Hq3UwA!mT7lB+#M~4hV#yJR1wU(s0{sjTvXFZhvh0
zn3E&n(i4qOpzqHiiS2Tldh!cw{A6-M-6@4U$+^abw7n-JI;bh%s_$70uhUwtSNx~O
za>TxsYUSnPV01*{F}-bPT$J~~4(oHE3&F?ECskUMxt}<%Z@-*1c_}B?JwtSj-%}Lv
z-KS{N|EH=26RPW43?CQ(rY6|}PRvOjGMM_3yn8^t{9pHbU#e9N4@o<S?L!*0hTHH@
z4|IY5h#>q&1cq4<seY|{Z%fd_?G{rIEDQsVsvn>O;(xV8!j4$&=6ACoVwYa)&$Vnl
zJKgMG4ctmG;5+fh^sQazvzoyR*!M3*^@DvkOX!F{FZ}&pq-*CF4RA*65bKvQ($1bt
zBu~{Y)H6J`RhE?4(#Qrho>6Mv(?vh}3CGlly%&y2NJxd^O};n9xV~A$UtGJHRm6@X
z`umdW;m0^I*Lx+56uZOU^smlTB=IOj>WSiDrI~{At@8aCN46A9qSgBRf-e2|=LrTy
zHHx)q*t3Di41RmfaA&4euS9=dcrI_kRgn{=<N<5FA_p%oZy42hPkrz|11Ht;_MC*^
z*7&3IVqN8%yTkgQ=VxaX_mn(-M6X+c3mO?gg8-@rne_9k=HoW8_&e$vgM!p@0GV{Z
zi&84%H#buoC>tAF>00v#o3%IGZLQr%oxid^nD<gp9gd|R?6NV~U5tAnf0$+tnBqYf
zqe-6hp5Gnd8lnv~GT#VyLxzmrObRutWH$DIgzb$*C2WW))nzR?y+O8L<t~y{9|1>g
zIx_c}^Av05R|a-t&lHJogNKR|C13eJ{@u>PXRS?bu+nAXes{NojXVtO13Jsixd|r1
z0>!OqLwLxf;fg5`i)iR-=Y-B~F4hjykJ!Ek5$yDgGN<k+ytJg7-|TA|iY-0*F3F%H
z&Ut3G#ybc_HG=jm4QaaYYU^&L&ITAQG&A^YgAkWNm6wJX<SGulZ5%Z8Qw=JUIaOjs
zPI#F50p#+oowx(!acPFlK8F<3a)W(FI4ASZPCI;&GPEW(=I0mo!TYdKA$AP0$OG>b
zVG@U;9b&(-u_*=>?p6|6*tlUXdqca4XX6EHxIPYC60kD^$sR`m&N=cdh*kpE(3qE@
zQ&`QV?vzR6C}5b+yogGQ@5)<y3~VDEX}q55f(@ydxNy82qq4HH7YQ^H?4+cm)#0)3
zv9)HW*f>3JIi;lXRMhJ_TN}wmFbAPFFz^Ygk<d>tp){$6KJ154bY4wpr$Eu7q6$T>
zm>?kU!l3)b1THZ;d|Qb&&<h`Z%B`C=x&xDeUr%3us6T<4L-^_bT&Fg^Aub~{i53<*
z0*vPUxZWW19lP&*8AoX8#M6d5`RZtyqd=qg?&?tO?x^|rV?{-UJS<WWhB3y~z6fH;
z*Cu$z#np<dz80J1+V-{}2P0Zxcr^dUUkwHb=H31y0d3bcGh0UOUWMGVNZe`ws@5za
zo2m|=&gZ$FV<J)SaSWPv3S*gI6a+n{srC_7$0!@FZv=<l>lt?1Gk|;z72MyxZ4`KO
zvc@&y0C9wi#^)J!UMfrLq7hyEJo}U7YDbT9Bg&+f0TjPL{eT5o2qpNm_NfmiR`DcJ
z;>u9O+ltZgeNW<WxbE8Ps@AK8js5C&^Db7}o;-|)H=t$P8$r{JlW>aftW-UN+NPAz
z+1`m7$Y0yp5Jyz4^Zdp=!<D3il{kFIQk4&$rP+1ag~js`v}UR0OmO}1PfQ-yM-NR5
zFR$VK76NUT6#+T$uz4pYP;@tCRpTFu-FF;SWZ`=50?{-A4nGfoAF<so{}`4#r1gkS
za?e(l@T2jQ;Tq>?vedY(cU?vY=ZBZgvCx4NyyvRS>|Iye9`;v~Jw$P2(Vr%>KCpyO
zqT7;^Y92Tu6?l&28q?NLHC;uz2^#=Fu=1}KfMC#H?>RHphx=`*JQM~>)giP=ewAl>
zad0xZ6R-j*Ki#*l3_pI2*5D5$X|HtuMX>?-6$8d7QB+=b=lUNt>gwA7#Jh+{VNmQ3
zth%UOxBXI&?qboa&t5+-+DvC}L2$5Zc4jELQ_6p8Tn{C3#OwvaDh1apDKy!W1zlHK
zlARU(FJZuP5PMu+Y4@X>I%@@;g4wD7k`=5^#s-~@YpoQ11V&7~zAtj9w(?zKA&~Mw
z9ornjl;ta+X|0Lhbr;e`gu#$U+)X3W<UD>QezadM5jaMDxvf;g-}A7m73@dq8$mQd
z{ygZ3nGCV|dH-xfNZ5U!BCIF)4~DL^IP*9A@iEp@Pus(n*3eaikE}`uh;7a4Gtkzj
zWhWT~&_el;gFWvb+OYpn?idOrgPBhEx~KOmRs_62Md%cqa|kydcW1dY?W#lDNr<fh
zOXg_6fb{&j9>n`VoZa4}#>h8Of1`2c<+88+qGW4i<xrU+ryH-+bZ<J3H!veey*1Rw
zUPERM<kr+6(X2FB?c8tLe0tW-GA&Pjf6$_dO<I{zoZxhGGHdj(Wms_hSlPSAea+*B
zq(s1+HsGWa6&$T+P51MY2J$FgNQB{Y|IvC^D8*8UrTp}Ti07Y!kn_-S?=s*=_O^#B
zlSow0qrH%=s!H%tE>g{5H)1b)wVFTA;b1b2(YNWde8%;#T>z8(2zR<(4Ss?I?5EmA
zGeXGYd#+`yBVFKf7!eq=bBv!WWkp0p?B@-H+ZV(1G$Kp<c`kyZ+8137Wv&Xb<>2}+
zUQ9+Ac6##yDG1+-IH2oR9d|;!Ix+dEE>%2{0XO;~Y<3Iqk^B9}*hi!h+L5Dm*8UcX
zihcVrXs@hPF+Z`%&E`1iodkYS=qJyI2KrFo4wZP7Z2A%{T*<Uz3`GU2I^waNz)e=>
z+PAMF^3$Sgdrp6W=ge$31YNC<<oC)@@Y+&h(j77a1IoQyb~UL%A@MXBZ%Jihg4V*7
zmbJy+lTGkl(;eX0T0h+0{Cu&2TF}XIVCjJJ(Bzt)=3Ahs981dc*g3pWXedMmT?}cK
zNvKa`XJ_w|drI@B0NRE(&UTzV5eB1=EY^Lcx;T9X<7_X3ngkXFmW{t4ImOv#^zFpe
zm0EEh&vWI2{$@C7et4WFFF!`cGaUm~Tew01Y$2lOAWd<}s@>{%z$&n)rp8Un*f`T7
z%WFar<(Sk5aQ=vfG5c<&8H%k*3eFdJpOggayDL{v(fVh)3GD(J@WAk5yxwLGRYlp2
zQU{tO;)E%b&^Xl2pA%+c;*y(tSP%Y^>o=2%gfG*bBZ;5BUd>79Z;pc9*^`6}_X^_R
z013K*tbRBkvSJ?k^x?%SeL&<Jo$7X5s8z*l6vbBcaRt=1^XJ}s)9&-D$LIcIJV_Yq
za;7nAtf=Am+N_|zqUdwca_o9LTb4EN149O>lV(;|^fCtJp>`Fwcb#|YGDljJGg#aW
zYZR?j(qiW^3Y7O&vOeO`JaB1c0IE6|TGhrpx`Jw4k4G!%v<@T>X-QX?XANlI#wol}
z?O65jnjN3}g@z148D1XCPZ$L{wBYXhWC0~C#X}%k9kvMKazYdHCa>LXzan4=ZPdm3
zjUeCwOc)LapvH+!={a{5vrO(Wm^R_BzS)eAM-Y~aE$b=^vw#Jt&~m9)QR6l`AoR!x
z-Mv&2v;79t0P_BFqzkN(JpwATJfZ&>)X*JNcJL!;^R}WMc%ipI-%~<}jAD1>^B*qr
zq`j)QAah{c<1a|Rycs{+CX7b7^OpPe2OjFr7>7J_TxoHkwIZz5&Ud9NPDpp+wsury
zARv(0Pv(U{A1m%4Pvs3R+jGE!W#%`Qc{Qtxjlst@`bdMYg(=rgB#VqpWI(CDg)+3{
zVu1jjhhLC!k8p<SvoavNY)MKKjh_P{8M8sK8HW%#vzu-By56{3L{Iaros)8YN4n-(
zbVcpb*q8I<LHQ(AlTOGJZq3EJA<-=BrTv|`T-u-;dh*q#=sYflq8?@^Ku_oxQqkt1
zd$lA0(sV9R8=xetLb$W(k=Sx#jjzs9ixM7h<AdgtIyM0Zl-mWtkr!z2y;}~+(6Z%!
z3W#Fh_c>nlvFWmxmYd>UE7H~*0L>#_K&-We9)Lx*&x6heSvNb;ykeD|5N0UPE=zeg
za>kGhoX;<Le;X_RPS2mnK(rm;6%_LdfgNT9N?7FXa7}oR?<O`kB^F#Z&src|VifNA
z5V>$yXo3R&>5h56u(B)bFvmcKklBnqS@;$k8@t-SSL`1emZu!eRf9CvuN&QXj_B|U
zG9D5zw3$KXuPg#iduJ`XBW-Ie6ivVX;54jRBVvT(c#$Djzz;?y0DqtJ|LQeu<u~hN
zN?Yd}4nlgD9MbZ75AhiJ4}ymGDZ!8Dc^pX)8~PcFHDw`B2=<1)1kwrWT|!~FFbBo>
z@!o9Su@tw_;PB4XFt)(KHI>FcUR@zQn??-vHDRCQOEeW}G4|{pyf06=a~8o8tb&5G
z&o+GFCSxNbHbFA2akD_zjvy>l_{4-KAH$%cfM$o0ErO&&e=v!~<~KSvBfbo^;XAV^
zB{qzFcDXo5RPR<Wb_s1AUJp;Td8^;um+Cflja>1!pd<G!A*;($pmt>W<y%$Nq5Fh)
zy?E{aU=^g<yJbN4WO`}AKOga7IeJE=j|NP<y&m7eQh;$&5y9k^{t{KeX&Rr%2MCq)
z#B!Jo`d&@egT%^NC6n&MMuwmpzH3Cnc6(lo>!6E{mWClR-WO;rS4~$7sG$-*ziiVo
zzJC2W#jApoaf7gqO-QigZd(>wd1F13VqiW9Ve*vmGR0SU<D}xs?@6qVuAyTKZJpJk
za%><{%2ev|=Oq|NeG$=VYuG$t@S~tWCTKl^R8VGt&qn9P96gnx@4e;$tY+f3x2tV7
z9_-CVPt1N2Te`k0pTV*^fY4%HH8U+u2=k>hmpFLQjp*+YIlmqBN;!I-09`{&mTC%U
zpxAu?<(9Blu9n{odl_vu^&SZ)Tm@hKvL}H79FeB;Cm$bQR~$>w_b~58xYo0ha$6!7
zvs<CHM<N15r(8meBlwi3aWg?|ET02!4aWos97Y{Sgl^U{Lud{q55NCh@bL7k9Qf8>
zTwF9y3}wv-!BLm{nZ`z+6tebyJPti@oj@xK-1|1gP5PoD(g5TBu4JM=ig8%0JIx}<
zk(|$FKpFZO5-D$W+1Tb&L-S-iBtSkjo+a#j^XemCc%xs1GeR7x^>0F03O?TN8MGUt
zSv7`=ikHLU$dsd@jm~agGKPkRiVqGBLjRs`E6q+%>vEYkz-R|mQj6L=vzrz4fN6F-
zHH2S(?^SjLp5fHxIL|B$6SqB#<2v}`Pi4i;1fk*nC5v<0nlfwl!O_yxqzO+97c>HP
z^Vt1-5q3w*zEJ40Sm#WhfSM?0Qd*e)K5izk61-ORFH-udXl+vOVg{*SyUEVZR=<1Y
zKt>4vAd@b*x1x<><3wv`v()4{E+Itw7h-@|>$iMfrFalXg8pGLoOL}V+@)zRMkNqu
zep5|V)p%`LyI|!R^!!8n%?1`9qOqn&twzJGw|;W!c!;a1Y<y0Mov;eN6?~W0e!n$-
z`nB}x7Sp#Q4GDz9bfgKJYb&ocq6Z9gXceCWjcNzbpQUaVNnfs=S`lE|qOG%5M_$um
z$s2cYifiLgbVMg?He-r<Ef%YM__LV<bK{72lUd`aEkVjGGX^#zwGco2wP7f6u(;;B
z<F8i#ddy2}qG^h9THM0Y`Fu#yiHPXOH#V?zaP%{(k*f{!d?%_3S820QAjF|ThRl>8
z)}?VPwG$2)G)w_Ey$XR1pf@B+^H2OD53wTz$mN@@eGUUkYq<`OkI#_-nyO>&{jUy;
zV&ud!0Yzaz#C-Q@eRzt6$?mBn4?&R~9y)X{yYs9=m-z5i;7KPMX^5j4z!a4zaV!Nd
zd=)vT%f}xj-iHf6hLg~(1wnozbh*+y{bqjB)ZyV_crhl{=x{|{%I|pShFx}y{cV12
z)v_P$cWQm`s$awCx!lGj0^i!uwJKZ~FJA>uK)ztCB)T3q?N?1Y%xNzP>85y8Inh0m
zVAItUjZK?J<-YxsK@EfFM9oYqE?_&Q&=eHCivOxIU>1j<bF0%ZF+0s>8~VG2Z<tS8
z!<8id%=sfA_|ow2`QWs+>*{m%iJT+wP2h9#yZkSKFH1s+Ik)Q;U4{`@vHeDbtAWI=
zN}-?HG#`G|mV4UHNjg#H)nW&2emUM5k-0~rea)^7>ybGf)G>K)_L~(8&a_*Q_{za&
zQLnSI^Z^3SD^>@Ue#kKg3v_;k0&HgT*Yd;XmZPS9Rp@~Liu$`w4XY}OuvJZM$V;&T
zM!Mi<*&XQvtp6~r#WiAKhIE9#xaU?BwQS^<+EaU}JEPv`bEf<_1Vj=9R=G_|8Ar{a
z+NKxt`~Y=0p_kEqC<>OMh5zA?JE*vhA`3z&f(fofTf(q+PxqLr#@$#<GU5RfXH{ol
zmw(DFO<!de-4K0<q%*(31jDS@;Gkay7J=T_WL?06Q=vqP=j<45KAI=M(dfgT>VxIx
z`mHH7p33IaK1#xnFUk}eXreAHnWmzcNI)3;R<eyf4CBP`X!=W4(>otT5gb%ES)^3z
zR)kjqp<R!VcfZKuXa|*jrf`3ZpSb%#f2FkW@Bq%_z3KyC3Bg_Ajh@ulS$fcA{fAi-
z*F(jxiR$48xb%bo9Wrfoz=njjB`+-!2ZiYty@d6>pnDWvKiU_!1pP%iG9f)x_Veml
zy*b_`Ngzyfzugk$@WZjra{JCezK|pz-;hZo%L9IT1G*yYM7q9ULfs;AIO^_Iid6C4
z@mu4IM?z$Jigr7JB7-k$P#~f8{%rWJ=7(TKRh5gPtSo5rubdvUb{XpXo7zt0P@Lap
zOj;SSIw_pm@n1Wk3i*lFJ{ME<Na!})0dGcl8i+yPy`Rcy<Utf8z=JG~g_$m$?>qn2
z;U(NfXAbR~PRDO1=+mBwYwL4T`nF+K_4E^dsFV;tMwkU$dzDKUiLokZRf|ub?b0ud
zdL7KyYSpX;-v88+3Z!FY-Nx>xxqEb?tRZYeYP}eBPGpQ|o{^eL;{H=Zh&M!qy*R&3
z)p3?1jPf7_ne}60ge>PN#pygry>qUPnD0yrS@L5{GUvb~&4AoU=N&ShV5k|(t+#K#
z!xJiX(lY((e6-Y<iVV)Ct*oa5ppurx`2^@%AGPM6*VQ0Z>V^)ffIPPG32&Gi6Vt|g
z+ndu3iqDYu^NCW#8A0Ej8|kRd-bo*KUN_SE6mGLHx~K`dWAU96uF2<H*>Lj76gtZ8
zeI*0XbdJc_;NEb>1xi{k%#$L+E|NS&>3wYsfD>M_)2y_;rg@!{(L-k#+IdD?cWy+~
zZoP0&($_n?ZQSTwlX#U2^<TE396E)zv?{WA-9L;%XC!ghhNqF{GNOp5yKKLxf;bPj
zbtGW*5`r0tWR0#0%?3Ir^Egtv;$$33!D(7yH))x%hXraepW;pvSm>{}1K7_95M&~$
z2|0md;+?B{`f8Yfh9!ytl-!<Sy!H1djgu<$ogYr#Cs$zh4O2Am4_h`5gon7&61=e~
zJWwW(grl3~F_POL`A|lXj(c=6;TPyM;~)<1D<dN#BI!6$iRbd`D>GJEQx}|(EFtj|
zLlRq(;a~T*6Cs|&D93pbRJ~ZuD&hOePEaNPOnRzE+^yK&w*7uOuQl1!5@gVZiTe*d
zryS*{Z!WA|tUpiE@I`#(?ghz^Za-Pv1R%tds%t$7y<v}s87z(NOcv@mgs&t8VVC9d
zxSI(zLORS{(k=LOenC2r<AIw^2gaBz(jkZBuw|H%q70T9V;kiS&R`+_rMtIQ7?1}C
zL&mq81s@A_BGTV3oL`83bY7rq1Ep(jD!IFZ6}_FBS>_Izi<S`+aG_L;k!Cb(#vgs*
zK%MOS3L8+0=7<g85F`vzL=2S4g>N?FRP`mgCEBAqkis)gdDnyZqXV7=ZLhx-pqbj5
zhycR9wdCq7<AHSPtR!1!3-pfi#{&Y>q-EVyqtI1JD+G3aZ@;hnDP0EuU6&uUk#+mr
zcT6Pq=zbJ0>^0S@IMo_sfG8Ot=qHNOYw>Ns`C)u_6gJ|Tiq>E<=M|)0=mY-q0+$8Q
zJZdVbfmAml32^%h@%9xr4#EcY9+kI=>(7zo@u@^mQ}fM|<_<-GZ%vcGg*cWbb`nsW
zEL(%Hk`D_0jb7|lwNjO~N#5T0PVCW#i}ev#2798NFm#!~>|b%f6IAdt(2<@btpm}~
z0q8+ag1VL;%Z-IC45Q<$$5sDVf)5ytOfCMu%_mPlc`>e{riPG8WU*X;ih`zml`K3I
zSz1>F05Bo=KTGR^ki9_vEv<X;X8QJjOY8n`Y2E)Vt^2>Fb^k9)>*io&Qz`s<Dzz7)
zdPl`xJ-}RwfsP)%WRu8b+Su?yGlU7M{b<TCPyoUVEu@3W%A<qYRG}X9(67xHQPJoF
z1rTB=(Md0symj*O?o)O0vW?KMU%R_iM^#6USKB|u_?PvxB*yFQN^`3=*~YIQ2+$yO
z03f<F0MyH%&7In4i1nWvC;~x`0C!viKu`n#LZ>Ya5(c1Dc&SGsZ;;*B04LP{+L4z;
zNdR1FAP4ma`u`3i3<yB`pAk`*5Mb>N)qb0Q!z0JRMPilzy_5!GtO1B>rg+K!J3ewM
z-~Vr__^%>_wFpv!)Dh%YKyr`slLF@rpjko|xqn>{n-JqgrJUdXE6s<a{Kp=qGbMYr
zpU~j#f1_Hq{+4VSi}snOqtxu6|94UJ69T~({WCWfjIpk-GJ_{R8P$jr;vy&>2qEVK
zF8LOY&a{pGBx{9?|6NR&bmPk=xzwr>&sL9;{W?y=!xr$w6tB<g_?H2$DC)sU$0@EB
zry0Kg*%d&@1^RcdxHj36;HEUxQ9n0{_BngjRncR>jd@A`mpvRej?SEgJJ9j}Y>f(`
zL#|M{o^4QVo(GR(u8`eaP?ebHpd*^}Nn3&Y6FcBxbIUuhk39Jq=s(0qFx1p|uIr9p
zk90e9mq*@(iLbVM&g>tVy3Ya~oN0e@zOg6|+3T}(W)%AJK63HDGy(S^xB<VTuhn)~
z!00RGKLRhfz)M<}sUL6=MrQ_Wcl9yqQs#QJ=KDU+1=78!{%0XQ=niCl*_dJ#`XOxw
zqB7kOrD@f)zCc!LL?Er?4bR>!-uF1!R*0M)J|~X)=AvB2zvnQO;Wta~!=8&QbN<Eh
za!7}Nja38ZcmguF<0W6z>|LbZSAP|NO<X6*|7RBHdxT%^=x?u|540CBHE=MQfcwkc
zY!ARlvXsPM3(Bq=#Z?nydit-)DF0;&Xk5ov=HN%}&X?CJGsS32JlBoMXK1BVh?iwn
zcIuhZnDn^8YMrfI@`_*o%U_UJ1TeKnflt9Mqv3i4pMCFMcP}U&>u>pNq~*8+1a!_k
zj8?^xWS3#75tuZWznb`yf&ZNe1_(J~4z4fDiJ5S@4P)Ob!3U!~V{0_Q$F40cHaa8i
z{j&EZMkuBvBrxU#<3EoS;!h+?{S<3;7hqHK<VafnY{E4V!^z-{*1`GrTw+x{;q#B*
zJfCa#^@nV?Sxg{$xnBR-f;AFgr2r*QJnoOulxq=*o2vs?Yb~do<d?pHtGwWyCzb6G
z5Zkol)YR`ghr&JuOTJ{Z|57+1m+wEg>gzAL=r<E~9M4EYan5UU)-|9q12k;%^%#^A
zkJ|vA)x3rSl$k>Q31-M1q={n4&cjba?Xetd-`~D<tgi%kd~2?8qVoz@y1MnlCSUyv
zIiP00Wx}xAZ`psMCG7>;yM6jp9KhaGTuzXAK^Gu1)6Bc7JPO?T;p^eV@~Z9+iLqHn
z0Ae1Uk?dc8NeoVtv+e8p;XJ*tAFY9}LJnTKBON%gU+fbrUEiD53=i4g=pMgriTbaq
z&}E!x{e2uYnR>7Hq3z5&I4K*kXwa6~v)w}tc>c)6$LUjDE+l?P>IPN=`xCB9{6{2p
z8QnUHl!BzM1<QS;BKOOX{5K6mzGldgU`}1?JxV3oHvt$i9>?d<;;{cL`~u@y;Q>TK
zfF`+xWo7#Uai767tT7FocYUOH9Tr|xdkj5WFtHXTMbl6h{f{<!MiMf6RVz1r_>@Cb
zsVR_TW`+CzF!$C$QGRi}@b0ooC~eT)-6^mLNOyyDcSuMtDBUI9-4aR*iXsgnjfB$O
z9ebZefA`Lvd1v04_no<O|6F*UbH3*rpKqM+IS*_E;19G$VBo2ItjHf0l<7O^#VJBQ
zX_tAXh|Pvnm&|XLeGJx0ObJ85(WVHteSzt0(0c!}I7sjx`1PZgZXx9S!d~?*9M;*k
z*^Iu~4CWoxY0e5m$%SE9UW+WV1!!%*WP4i_*sr>O|4z)3#yYd9Cf<VINeTR^<WbB#
zK?yGppEev0jKaQ|hzePIkBZ;PNfbSmHXyl<+$BY9%YICM4#&sIy%GzKUP!?b&UW!Y
z50eO^=~L0t;^3QNdeS>CF2}+>F7)-aXq%VWDI^2rG4Fj9BB$U(%@vLdQWf2x4FLas
zH^G`L6plxb^kf6Mgykssm;G#(L@bX<7R0$g%Kh$DklS8X=0rkA?n!fF2;>tU59i&J
zFbZ<$v0Hoeo|m>&XFBl`hWXP-6pHst(D6U>y$71{ArQ9F?O~B6W^nIcBOn7WC@966
z0emd3o*f@?&Tz<kk?oF()No!G2I9nl7gZ0#{OY6>TBx7g@nw@HSMg7^+LNb%yhmTg
zqleluEat<)w`9!cz;PuB9u&bs14h|yuTJ!Em|hEF%_HHUhaSv(+r_*xI!)NH%UrcX
z?b%q?sEKMkogfzQGy{W<zF#b)C=j^0ga)YuviPs94q8*J3D3vOJud1U4GQw1^ET?`
zyub_dy+yAam{J;8{5TzrZH!097_pJc&jrQu-d-owNO%LN)U*?1+Gc3R;j`MLlEpXh
zy5ZrP9!2oXL`}jMqY@3hFDji(FPo4Kl42Ixl5$O&<iIRPD+vDn!7b{t5>vQR05s=A
z?_@8LcWm+6r<RA~Mh}L9r0XNvoupG%*#bT)Y`k02o#y4JLo)X#U}apxhJPA(_D$d2
zKZShJM?OwSXUrG)Gx6w(%l=DWc}>LyC>~{6$`wR1v*KhSpen}SQ&uZ9O;!GU`OYK*
zFOiC5d+k{*R&peG`r}t?WPvqdFL;D4pg4ZuIYlr|RNG)fdEhySvL_yi%J2tJ0Id~w
zJ*-p2S~Z?6wCc3)`@BsingOfiEokJWp%>!djr?H2d?*`ZkCe3<jq$r{n|6eQ+Glyy
z=%&bt>OlW>)NvIoB(i@>Y`vZ?u5zHFujLux(_BXCc34WMcr59Otow}<ffM6~d`h%_
zX$ke1FT8~m4nVY+MxOhcBDv-bQP0o^zZ&j_P|bkw<-15EkO4X-;TJ)6{ryFJd{G<G
zs=!CD`P72V@#ftZzvkK#w|GTfdkcbnY(+b@->gy4-kC+AI4ruu<Kn3PJpf_P(wqDx
z+FS1fyUW%#zo0hT`}4h8Uezqy`6dnpr+ODuId^`%lNNHD<!#;n6EFnl!O_kZ$n-rA
zklyTfEZi}YdunKXZeA_-6&XwzjQ?q(b0nN<*-xHmXZf90xNW_sNZ>X^81zY-GulWg
z1pqJ#C+?FV9C8W<wmb8d2?HE;i3@^d_s}XiE<}tCgQ$ls4u!%*Tdu2({o;WJ`sO`B
zxg&54dQ$2?$0{6X(R%G=N#~mljJGmX`Zh2GVk-pdn(2O+`2N>@H8i;fPazM?ZN)cd
zNU4m{a-6P7@98jIkSl6G@RXZ;W1CwPh#~~)hcKQCPOS_(enZ=xDN>`C0DII@VIq}%
z4mw6HtlH6QwmFn~^w84AxC-V0yf7o|<-^&xJ>SbYxkrW(<|aE}K|ywBvgJ5BAD3&6
zcbFO<1n3@ttH~MS3^V}~-&@WH5bF4wD#_}D1|icuShy_oF4%d8el9lpGXNL4f+okZ
zhQdu>xIZb}!Z2C835FpaekwP)=wqPy`&91xovP!!mx1jhc^ytpiGA;cwzZeDVs1}@
zN6ayPmOl3FUFek2{$*jai1DNi=@oFqz*T4Dc^;dU=kk5h=m0!6brc0w2!Jg2%+m%E
zI)pY23{>=p1U9FH>f#>VE#NuMYqQ__^vQB7vq{Oc0iQ2;OSAN7<FdY>Uirs9#Fr8O
zu}h}$MU&)BHc#8BGK`yT;Y7sgyO)Gj+phqO>c9R}1LB>KmB$yMi^zj{H#YJQ>yUl7
z^paSp_vDHWU?`_`(Qkc;-ogH=Nv-!Dz=T`@Xv5*A1`&ecWQY8xkIkYhDop;?183^j
zUKYtc19%%?SfFqkqzE@@fw*?;<K_u}?X4gc&N^w2V;Kt4yXK;C_0A}EvS5yFkNJWA
z#*wE$o3o*+=S4lLOBqc7>B81aA@WW;M{*HKZfHPJNx+1fUe|VqP@~O@vh8I4dOAFD
z<P;cku%%n=ifGe`j=4)j`Q#YqW(K6S-k{m9FbyVXcijA^J2Y5r>BqUoL9tEUx9Edj
zX)eI10<ZC{)5R<!U5mJM=MXM~mkY2*jjxiHBS*KCIX5Q8tscWjf_q;1C}MRNyY$3R
zsV`B~xbqCUDb+CW#Xr4c{U&uT-=^dTRk2cbZMCv?^*_FGFGbNg*j_<DGP6yqF56c6
zXE9v#{>@aT>2vw|rgJ?<cZ^){V&=dqje|ZeL^y^Y_w0*88^be^OQBF92Rl_=j?$;-
zxp=+%z7bw91|@+DjD4i4{}J)%Ez(`UVIk<}L#OxccDq_#f)qQ!VUutMXNCQO|1}X^
z?r&o&pEt}auCz)m=mMZ3#8(^Gqv_CRhq}`A{*tv3ZFh6wWWx8hao~K<F0Gt}H<bxn
zQ5KW?YKc@jdYN5c`xn$3h%q-T|MkjWrE=9gJVjGYkH60NckhCdu3uw@9Tu(Iv-r`-
z`5*pOqL1j-Xp05adbweKgq|R|A|1>yH5ZH^7zvyKbjJgVD`=(z>gwJr1hLDX=yp_C
zKfx_-30T$q%JAECM6BskuRGkL;0TO{lqhiI1&y=Dv^GtVf*j(nQktUCn2p4rID@`?
zp(aO)FA5M}K%5QAO9Q-HtzWN!7{t6YXNixh(s$wLe|u`()tf*78w>ul71yNW%`xaL
zt+Xi82TjuhcAC*-8$44oMV@W82NrPck{GD=VI#A2{gc7Q6r%K(O=95adb=8;J#41l
zZz6W4Ss?56?oY(IjFPRatnc{i)4g)Gf3yA&>eJRZh1}B^(KS@5c58S0`XaR5{csWg
zI1S}aS144NFmrrH=!J+|?^mc^H-&_XRZo7lr3wuj3?2QwWKfy~VvnrfmZTFa1>Y7#
zO$o6{EPuPn={v6)O3`o;y15sfm3$8yGsA)CBGxmfV2O#m`Hs9e2M9K1>sjzE3kT)W
z_uK3BD|e@`nN-6eaT{g>{q~M$eAQ)@+V(w!GB2n^K&+%@(BXvu3Mt4hZV7aDFIwLH
zq6ngkLx|#{4o8W_Wo*BpS3T%L_OCtSynkW*^_Qx?2VW}Ln-GV0CnQN@uihW$y;>>_
zUjOVd98;VYE0xTxax3W#YM8&ZkkTiTiOu%0-0GTKW@#&|ewtPEwEyv5kzDidqSIBM
zDE{N#U3K>VQn_Qa0Ybk10rK@Tf(gD=^<-Bmk&)~WJUNLm=&1l|;3=8)HcQ8^8so^P
z_?ut?_ZSLayWshG;eMiv1e^5$X4K!bKSvrr4ES0~5zXI)n;__+RBq8yr($1ncdQ*Y
zgnPL2AtS*W>=m{gd14Xf+{CBJ`Dfg51vtS<04vn?!G!14Hp}jx&PU#FSlTR>v<@>|
zCjPZ-ia0{Z&fr<Qq2lz!Dd%jmT=Hk4KexG~3T5wxCQg9m+A~IyAe9IygKeBJ5iB?<
zZ~Q;5!QqNP6@t%(>cL;h$Ke7$3CkG9-u_K5rhsyTaUxyazW|&NC}70JM?6>jJKq1(
z%jKmLr$2<5ULFKL?l`o4v5Cq1*HWP1st;nLnUr;_Z1N^cAO?jc|A?<VFL;IIO2Rue
z)ZXXgKlZsmT^0FTJ3+?QC7RZkqfai|`CG?^v{NtB3^0q*jzWgQM2@TNcpfZ)p4|*v
zNoSr6r0}b)o76Ke`U_n>s6U5)VNdt@E4Mgq$X&9^nBuSct#ZxXPpkRQaOSMg)(<8d
zS9ifOmCiC4x5?v`m9oz@>x>IOW8NAnXRa_^zOHg&@!cxKocy)8%7otZ@XnVK(&p0N
zP@jw$?WhpUk9s86c^b-pUvErye0Lda_2I)nORHW;rO~hfHoW^NG~>lWW^qQzJcimQ
zbfWuBW%Is;fAh6Q^imUkmvjCy^?oV2g}l5VLQI1q-B%&Q=Vn<KS&G?SsKzF1U&>HL
zUC$-FTlkePuKLaN>8W;_iS83TQN2I?H(H{Eq_4Nf&V+`tmYRE1jjM>uO5EeFz@*n<
zp!3H~a|4A8lL|If<cZ^-`|@5EwY&4_NRE$>XwH}Ve19Hkii`A%Aczg_NZkIJ?=T{0
z<#2H5WBpj%(3r|+xBfb_rzvTIpv@K=-P5F+v@6V&d$!k0K|e>v7s-iJ{!42Qp=0L(
zd?9N5aRV-&)}qykKd3lpWQY!rNq*7YBt2JuxT5=b!yX&1n<!>KKXt@I=k#uKr{=)7
zUd&bPJ2TP!sb^(h82%>Wf2e_K(B>=KOsD9Yx0*B=^kXG%eT4fw8XQa76@|`=LF!nY
z??0k6mM8V6cdn(O`$~MH|3HQjNSN`BjTH5hdMPpo=wyTtAp+FeyITuOle|%`r)?((
zR06f0Hn|k;f>Of?H`9Npi3B8B>N;-Se^;c3gWs9g2YZa<g9%z`^t8lI|8UoGG<B@^
z2L!eBqWFnS5AJ&U-2AhvL4iJWDsEm>m;slb-ClHZ0?=?^jbXE#lGJEpmv(E4VWCcQ
z7x(H=<QDxF(<s<lZe!cfj1N~Xr~H)L?lnR3V0D6)>I0jHO>>!&HgN#TkHpE>>0Vvn
zJ1I<48&h>M9p-F!dmhFaT8d>G@Y*=L5MdO5B#e8O<1@<96vNfJ460O>_D;C-U2qBL
zkk@9A=ZV`*hy>F~NuSZ`$D!=Wh3KZ5qE(PaU)Gt2XTVnnv-U$oMKfArUvl+l2UhOy
zlNo8pcOblYAB<lrZLpQG!GB|IV-7hNczu3WT%=+93KaEuCV7L?J#ahi-9dYQGWVh9
z=hWl0STgU~-Z#oBnP99ttM9=FQhU`a<_Sczt*4$rZU0%{l?RXFWMSuWY!WG)(@Hk5
zB9XsUIXnV$$B32vK-jPP@NZ4XRW`TCY`LUet*iO*uvmi+i72ZuqCAzmY%o~f0j+c7
z^tzgSL&|KYjAXdtPwdlcMeA$z-^zJNvehVai#$8*?Xq2(w7fAVP!`P@4;FYH{TTUb
zV3RbfZdon@dV!9K@~kxE^#WNi-fKUd7Xd$uj31&;Dd65MTP3)2zuAm`-TqivdzM30
zcA_F-;L-w9WUp+_ioBjpAQy&80_XfL8$Ju!BxXuWvuB`}Am)9o{gHpznT|q|!K~+R
zNL`Do@(W%+Zkd?};R~<ALDwQ=uQ*ts8sf6;Rhk2HV3a@YlzicB#A+e&%ZO&6(Z|0_
z6MBp;9?PPHtMgJfp-(N314oM)+ZH1+_8E?IFnn4J7TrMiu=`2gDHo==QEG9!k^tzi
z$q{!Q-###|(vx<pd;CdCjhFM+W3kx;0LTlaVESofRU=8Bg_{2DD_VWYq^p=&H}>rp
zGT7irv~{q16q!l~L;GoMQN~PZ#A(~K?feKK`)mT?3#IgUP|8+?jG{VJ07!UCosyV~
z?3OkC)V~bxh^C};5&uPXm<V)CQLL+we1gxG{e$M3hm+P*8%TS0+nStXd2~lDV*>6A
zc(mCx4ccBaT3v(V0x`WHG1Kc<o9qATG!tk84p}FqT2axO%D+6kr>+BsMt=Kzxa_Qa
zCUfJQk7`VK4?)-NU!z17TY*=t(S=Z7x$@8QlEu0+37pc%&bGXIe>1LaVXN&I^7q}d
z%E$uIH$NM;Vo?SFM#otdb6iX7o{!q8!{2CgIqmJm4lkOS_?*GYZeQAR>AB~4jbdJ(
zA*ru`M>oZ$R*3Ytr5W&`%k8mI&X%IxC|vH;3yV!$ff9%H;|{yJ3opDgEm*udq&QL}
zjT;L#&7ARiuu-FNN<Y8kW)|v=%DO^4{e#EO|D@qyjx&$u#KK3)Tj9rY9R3nB`rrDC
zN+dkHb8va;<EodLWBGZqwp~%9-$H|dE3|q9W#hhW0o}T9nI2(FV^f7mFXs3zz26)m
zY9~Q;M4J|T;I^k7`vl|lLRC_~{-zB=ATWkYJGb#y%RKw`O94&g8}*{4o4%&z-b%+D
zyY$uA>3lYEn!lR{%+O;T4~H`@5oP=>x`rY0)^z_8?2lB>-r{^v<=?n&aud{Wn8v>e
zJ72iC`n5N(`xa{u%#b{jQG!siV^{1XQ*2<k$zeL3xjMZ)n6Trkwh7`&<xZ9m@|zH#
zWV)tiX50twEcwpLO`iWP{c|F#?H)!VZ$(C03H;_&ViV39JffQW+1<0M<2sy9Kjn=1
zNTs*WCXI{mm}nL5)Tk@!O*c?~-*EfmTn>mm{_ru;f|#b^7^1WS!Nq&~y+q1ZXLdb$
z#l#jp%<7ayr}<z{)y_!}&GI_*Z!C&OVeD-#(qS4B)qWdsB!Bx`Z}~K%A=HMKWu*ED
z^zGYuq4zzuRDQQh^_z{13Eqw6E1So=uFZo-FS5#uh*J79UY5MewtOjV)IGQCAZozO
zdPa#80t$qGQK42gL|;F<p!d!crAqa?&FrooWqcJfcq#Gz_?zsCF*dAaKNRqzI*GEY
zTm41hL?4I)3aVPNw6?Ot5~>fAkh)5-2IaxMDqM{22>czbGrBHfWqQ3vqBytu8+81<
zn0?}&0p^O;7%Nx9<O<B`B>0!slE@iUPJ!yq&Pp?2c2_-f%oa{+?Sv<Br=llg{`wLS
zW$U#L<%tZjnhh6_Mm<n&@Rf@`<Mxg~w1`#{=G9@p%dC0PqpWo|#Cj+ky{$mj%`<~+
z(%%uarLe8lgZEr{)AO<pM(CPdx{n2?+xM$bI}OP5p8ug{5I{R<!SK!=_7Lf?O3+vc
zH8{Dq_#>*5#ALYGlJNIuftsz4bV`Z=dayf4<APNvpynX&m4+W*ii9msXHL1S{;b8B
zUEnGbQGZe9R$r0JWX!SJHAGvk4QmTKw_7x);c5$@c1lK!sv`!=^Z2s#zp1KkTI%U5
zb++3`7DaTCnIoN;OeEa$I;VPJ41bBi$W@W}bvjAZB#*4KIf+FROT7vfd?TGdKL2<u
zAc3i9;iTXRvt5PBQTHcDRkD0!Ao?f*?yZKcma^&jhfgo2vpAhbKtHB4OBr!Ajq8%K
z7IFPt05rq$r$BF}gcRk*M+3-5lc#E9TT=Yr>DW9%;y498lt<7fb=B%da+Qb1B4H-9
zV90wlNcg1HPeIM1SXXJ66y)VbpB|>7H{&TImy69I&aB3iVTugD%wyoXyCu_?+~X9X
z*$3pG*H4nqJdXDH{^W6zM^b#hsBCrzy%-?<P(*~_^9vkUjz1Z#M8|K)_n8+@w^iXo
zvVIMnXOO)4%^vTw+=bn<qRMS>R`l(WEA&%b9a-(;9C?6)zFhG+$M<ZbqhHPiwI?pe
zy)^LT<3a}U3}}JxVrunMm{*#`3*OVgS5TOid@gtVD{XE|9q<|0e^9xufKt(v)7Q@m
z!_SxDXH9ZaawYZ4nbraS9Qe9o=UWr@WF|}ZcN;;Tn<GwV*((ue4I!`CJ>+V``j)%F
zD*S^MbYBvmeK(-u3g>OjOg!Qx;Sij7j&rB<5>N#mtzeTJ_GEq+ot<&sOrLNvuAHAr
zwXK4cR>tF8d!SOT0fno3b?47{Z|T0M-^bcBuQzhP{|Go746L9QZ$z!bQl#xeMVzgE
z^>;o0n=dyzKuy_fMwsq&CH!Pd%P2-c7-V~1qurV1#ieT?JuNigKR$}cv$u)<h*Z68
zToq~|t&ZPk6_I`pK5F>!W4Y~SLt{?o%!5bWyBRX!oR1Q8QDMrr-Db}ejWP#jC~iXS
zTzm2NSp3ft2sWR@BL~T(&CMGbF2m(LxS4d;>Ya&j*u6+b4fzmlU!FDA{wU4i*$S^A
zMW(?nWtB3uAV(|N@zf7#TlEOalNB0XWKwUBr^A;v)G9SI`zw@|l>mFlA<Mx#pWD-X
z0=#aWevz7g;m`l->y`HF_k2aKzqo~-1Y}eoCq5L1wP$k=m<#FRdkUOF;a+>|f^IJ%
z_r9q~T9Se!3fjH80guM{gbV!vubJ^CR;xC?DVt)Gb;MoKO&DAsGp{f;;WU>z^+3KF
z&OMW{*T0?3p5_5kAWdN|S~?j`d+GOGFM-4iLFLtRR-0&CnTZR?jYbC6o)KzGdc&?^
zzDfr~<~GG-&j&ePSjG+rgI?)d-9C4@?MRp=T9<b5>Or-o|Ez>RRhl#VG6+Znfedpd
zY=?MrE|V@;QKLPRWIjWC@BGBB-cezd6r>JzV6FdDoq}~FD*au{05h4MNBy*oWcn>5
zPyrH0vo4z86B<OBNwILn>b^?R%nWMQd{n#Nlr=GDqBK##^%N*v%dHD(Jw7_C)b5eH
ztf@w1F!MN`9u;2{h<zFr5k(?~a{`>~<&cK)#}c<yDpNzJ9-@-=@^&w+RpJ0Mbw?5q
zH?D-40(~D{ho{BL@(mf$lh-fgt(1ntMN)w<dpQpF^O{qCJy1&i&og{lr@^+g($E2V
zo?S#y+f*_!YNv*bet(qDxQahBd-Bg&tmzX`uk1<NAY*;`@1HZyK7IE=>a7j_h-61%
z|6|1DXaS>xfhiMWM_j(G%Pb))V(O(JD8yL5e}KL3%3e9x5)#~pYdxMHy3o^qs|Wd}
z3PtJ*7~MKE0Q-haq&nQ+GO?aS@p#M3BV{i+Hk;eGoBZnK;CbjTK~S-1_54Ad)B1`s
zVNFKh7{7s?k*ZUtUAl?S7!17`6^UI~5DD`60EwIXbH%FK_bixq$fOCYd&VTYBZbq8
z#nvN4KOXlKp%`0QF^L|T5Y_0~KS+vn9V32U_9@kKGiSfH_`=N7Lsi-hknEu}O!?+1
zpBtvPY=`*wULp2?C#SXR*}KV>er&71CD;Jrast97pG-NDY#&@I>=a!PnQks2$)?wz
zm0mEV`+eNpi;85<J2VEhjUSu40a9WWDYDCY@4gDLbo&6GA6)&6#Y`ak;g=97B!X$z
zgEvN7k}4^Fpsv1>EEb;!eT~*@O<i$nFsd{r{jLvz=kp#7?{$ZI;izz-ttuU5N702A
zs*oXX{8;}76yqLiwZ#i>PSw%~S8GpJ#Oo@8*PlL^4H#@bo~mUCF{6i47^eVz2*Vl8
zFVYu1>uH=Ev|Cz7k2y}rPs+)XRs;~@>#Or%4xBN3=hTog1(MA#B=SB`x!d2DRAN;D
ze{@+%Q61F?mN<cOb(kcqJ#5MC6C>s1Mx*&pnJ;xIx}>DHvX%sbKIM}oE|esoH<HXK
zY-9a<TV08fW0pZf^Im7>uT<3uz+g|b%98A_u`LBkuIZ&GVv6y%{z)&xH<C37P&+Fh
zGH5e(1q%)Lqg41NUhio)f3`rfumY#atT97D=Onn|R}UhXSt#9dE-rvOMOO!SDOI@9
z{j>t8J0%LWc}A#xuB)%Ft-o%EOh=XhMkWaXj;Veg+`Q}%$xn^4IHR{~YEsFldE5u)
zSm*}I=VDtv$v-TC&oF(;${W-4oKQY`($4e<jSC2j-EkSTi9S_4Y&Lo^hiQ@Ca-&@R
zKm`l$=@6L1y_hZg;?gjdDF}b@;&;xi;!E((rh802=5G3%Js~<+E(es3y~*PJ#5Q^H
zk&h5IhS|A9*RG%Vh3nHBM~f%6sFo}l44)3Ot^+0#YE8*pAu|BFPS>cNT7|(s&JC^{
zG<Z~d3q)B|?U;qGlP^i(FUxbA%InGQv$qFmh+rIj_`3i5y=&L{b22oTu`z@Wq$8ni
zgMAaQTactE^z``a+RqQM4>MaY4Q}=Vq~$?p71>lrp8gX*cwQ;2R-xIzOh`dpc8*(7
zsE-y+HHx-xG?ol1g3Z_M`KHZV_KQQ*M~p6V3^RPsujE&6i?vm-0@+c2KfZxIqrVug
zDEU3@T6FDurY_M$h1^GYDD$^2^UV8PL-2QwN>^L^Ey6=3M7fmt%;H8&ORx?2=>1q*
zB~H`XR)Ak19#(alfDby^Xd(hUtv;LG9qa*m_`>hARavAyKFUq&38(axwvUso&vIOJ
zKv`jS{LR=Dw%hBLj$rS5ZtuD`84JdWq;cx$Key%m%pqbh3pjfMbna~J2~EDkRq<=<
zc;P1yT%K3q;;`A^om{C!W}ZE|B?`2t?7NTCPg-)NXE#%Xe&Q$B;K&g<DYWC;DZ3g$
zoSwJ}R96WX%o6%*9d|EiDE}q}q2v|Vbo(8;>K}U)4`qIBJRMYfC+{92bX;Kadd%;w
z&9x%s)u0&77`Evgh9%FNlv<Gq-XEv9<2EmBzSn#t8k2P$p$}o$@T5HK(PgOmRq#|N
zDn!0!d~ZoC*<`LWjYO$5J27XIKZm_!Q$|FZBm~~}*~2|=r=oE+GW*2rH)*S)7j-2r
z;I)acOuQxLvGnOK0HmaVwuwPyKiCo}OL(frw0*@pa4b16IuPju>wJDL0xpiMG|l$?
zfG+8QEy(4W=H6z)sxoOhRT50~LhoT@nlCcf+XIpq&@G!K@*}GrR_igeqlA1N)ECv0
z%PVFiKfa;!I)k*zLrzzxmF>*Uu?_g}jkvtlrN1cLMmoQB2YnIEl2l2q#9_bzM}H4>
zuOmiw|KtQqS(t{GZs&vy=D3P-n_Tp7u86Q&h-5O8q2}f=**JY#O9t|&-lfaYQfZ1;
z($Z5dugz@Eip6Jx>xGVE)tmnG+zSlC1#*?{{`A{Mn#^hcLK9HcVeiYZmp38o6RC)U
z&AFQw0+ts;!6+(4{*(4EfBM>-^5DNHr*S!~qkAgld+8K)NR4~C@m2O6!#(g*^mW<m
zWDf6*#({wybU*7+(@?I8P#)q?B7`UJphHskwNrmccduPIipm?{(@fO2lgTVo=@~?a
zrk`$nZW8B-iyjX0Vc$^a1qg^_IRgm9iI28oZAaS~qIe{o-UQCW?hQMK<F>2|aeD_?
zZ`)556xew0QWH*~7c0Axz(oZv5xE3Eo~{pBxwm{0o^Zd>$GI*yI+Q@gY<@M#I16PD
zPXe%s0Al-ALU;ya>Tyx1vWvQ<Emhu`B|$s>0QcFa_JC_N@m^c}@8HrwYa0wjiVLH`
z7=9Bz#3K&*(cbxtS)Q9HhF~l^;twf@cI5jUp=U}-$*3lBG}zDx8CaKZo+;R^K4KZf
zl32^r9agbk^V8{sgZu4Pc@WzMz(Z*V2HV9%WTb+>3~ro^XN@nsRBb8(_TwVeQnj$(
z-nxu5nfI*7s`AjW0|VybT?Qz&qjvYkx~=n%D8w0($cC*9jIN2*?Y!o_&1qy2n*8Go
z+N_*MMlLZE2_H*8w`&-+$Yo8N$vPg7Ky!NXglOrH&pU1}@}DJt{c<l4r-wRlzZUdv
zRA+8G053T50#oA_5lz+QI{$QBxOKMfH+p}<D>f`t3iEq*b#qeLMucVC0S_3z=<)eo
zSbgMIjvWJKP*4K7pPNomew2I&Yoad>0~J^Vey!!<8T`Qj`vL0P!P!K1@5*>G*&l`{
z87KH6C)hupvDPyZN@qa<Vxbel%|Z7W-@llQY2j-;J6T?kHn`MgBHdq)$1cT<-S?xo
z4?8?j3cp8(W5K32C6m+d;`yCuL&u-;f`8A3!K3YzQGn_q|47~RE&25|EX-8a=g6-n
zLze!M%U{*?iB$Y!uDu6LVuzVf-rIQpM`I6gZEe(KGJ5X^=HrJQB0i2I3%3y%DqXo{
zEa+n@EBJZ~9f{u0izPqgtzWo+So~0qE!yO+(6+1D$`*9+2xX#f39HeQ-oK#Q5Xpa$
zK-AdP%}_)64(P*!i9z!Pe*p>g$dR9S(ngFR-Z$J0+{ecs)X~}1;U5hOu)OZGa_nt5
zgIFfsPfNoL)MhtrE?vWUjV796J2rEE7ncS%e2kq}6>=ibiph*a03|BIB6%+RAIooG
zl<3wZV#jhI6b0qI_%$#K%ATT9DI}X+Th6Df@#xFjK4wWy0T8D~y=6hRQT6NAG813E
z`v>h(^HWz6Q)k|n*zMQDNsMchZpI1kg%YtL_vmp>dRxEU?`T#$OULx!AtRss&C1DK
zJ+|*u5*lUnRZ~uN<qznq#t{&BU&|@4375LG>quQsdT_e3J@MpascjIH792hA$fuF^
zCaN90?}gJN40aeMJ_&HFTJ<W>D{$qil^%mF;Atu)Uw4fD%2&>KtgX5GN{|Xn0uKY(
zSxm-t(x$(!Yab1skErk98Y4Yj0xCd=7XfFR9jkk~0okI0RIK9L)Zy3wXBB~Mxs2Pb
z^l)1m6`jSf7(^XJ;US(#+*DNfp|XfTR(Z*-avA?g8j+>5Fa($YZ9mA87hmhxLKHT?
zop&ki#cKU2aC9SQsPAXMQQHqQjiF7HWX&tXhJ&7&Ls=jIuT+3_(BhJV@-c5t*3JAE
z6j&0nhj9(ZcT*gj%^Df4wm$dv?dd}eFybGhQhc`6V))(4%ksXgWuT)vU>+gKaOqMd
zbnf-`y1niN0ym5xtulqJEf@q1!c#FLbSE$l^;?UYW3cw(9hI63+jbeGn^9N3rhi`|
zgE{)dX$hqBmQW*U+TgvKVO?@2oP52qbxXm_aRFUVtICb91-$Z6Ix9{?UU3&_g{{B|
zdv?~X&sEC&=WxM7ZiC+;#vj$cJ|f}+d+I{WaA~NUrw=yohX=IZxPW~!MnC+4^LB3(
zr7@k`p+nz2?D7zjkVziK)$igzv6HHc%(f>sqo-VRc|PoU$pb~&1J@n5LLdXQ$5X+E
zEjRNgm{^c?a<y(^JS@c7ycM)PZyeni{RH8w=<(78M%Ru{Tc#S;?%!|o8*6GDSCdvo
zEL0@Zo!`hU2l#v4)Iix|0f2?GLR8Jb1R^xluCQD(pBA%(>kn(Mk|zV!FQsgc#R?7I
zIBCjut-J;Li)o-OTAZ#BvI#L2yJj^TwV4>Eji;g<$GbAZUR5;wqn8LrT{lDxG&vSW
zCJ0`%KTB>4bn>=J`Bi+QyC~^9FDJS^aWk~7eI_YI0Y||B8<Oa*0ecT60dbZhy4cCr
zx<WVEu44wCSGFtS-Qw@vd88lHWUb%EV#HtLpouT$trGrxZmv%&Uu0kNwDT*Ss`Ba|
z!{D}}ocBk^86T^MYED~*^icsi1ys;)%5p6@j!v+-fhfmB_y%RJoF}p``MzC-(?dJr
z0?a5myAy2>kx3pJTrZNk>_Zu#Z-Ir{IB0*}V0ov<VF*R%NygU>ZEx0*_p7gOLL73d
zZ<*iO3>ZzK@w61<TprWzkG%IW;?REL!Is%#xs)!yaHfd6tFHZ~Bj@&jl_a@TKAvSA
zj)wN=9o(f;?9rgN)7iIV+9UfDwp;s})+d{dw(s52@f6uzzbnGY;7#cI2{i$wORV8~
zOfQsowfImd@52Z6#Ge3PSTpVdJ58Paep6G^y39mqkI>R&4C#M@HiBXdHl2`U!Mx?{
zX{_}zN}*%F<+D32V22()hrJ5ErLYpM6HG91;Dwo6;KUJty+L>qJ4)j6_b*m+L@sMy
zl$m#hJEJ~Khf%zO_I=d)Eoq3CDd@)V@(Y+@IfcUee8JKFqrWeP?gIkMz)~ntOXc9_
z>B1tjr0IsJ0vO;JFf^t`ip#%`$ek-!DRqL^1N)evY81{uC&2BvY3(sY=WW_ORRNH0
zDQ%<>;D6g|EfF1b^tpJNmC-Whs_qnG&<KUa<<ImiBZ$M+Cj{3LuJcynSX5k+a9KEE
zISX+)Pz`Bz`*j-~?3CpOl=*IHtzZYBXZUW`VME?)_kiUWsKtQ;(V)j-_CYQ?IwfHN
zj5lVR-|Qv@8{553*-tJKge>BoEdiu*83vk+^Xoe@O^qCG(+zd@gkpEdD}#NK<W@vZ
z3f?C=R<}MA7jq&K?&o_)aYCIY4<MQf#IW}&%jmE|2vppttQ7R;-s{*a!<DB%ohx<v
zjpU(XirCz(xcC|eDHaTinKw$-a>r4>zf!dJKC-_4{Gj`!>(5@P#q-&%&}Dq@xtBSp
zX<TGPd^eLOeN@;$k{JspLd?gUFB}K7z*?i2tW(dT*0i(JfURZKWWJ`W?ISTq<p(qt
z@jx5@6FXMQtO|#tS!8b!u-VI6*d4+4_N`k!0nnVp4jyJ-&|~zRJIhk`H#@ltEOyIL
zoi?WVDRU^^;{jls4BxNi3j~t5n_`dh7WHQuo-w8tQ?ONAqp$&zSoxo4Tm=q?5udCp
zdOp6}m@uCnMHif=$R#se7!E17Mi2ah2XwW+YRLaI7ylTN>}nB;Ob0U_`~AR&NYQk1
zby7_T@!g#Pfc-`uAGl=(fzYPt-_QIB@!Xb|q5{^M2*QFZruQK0K*;LnTVPEum@xkC
z>VqJBz*|#=;VeLk#uzx%UHvT=0JvXtaFj)ln_N;Tmn<yLVqu{04+CZ(1h*5+pkiUh
zbT<$zHxw8N8{P13OB)2aM+F>g$nERaK<2`L2(f{+li{`9?Rf%?Q<5OmTv&26knJMr
z2qXjGSA^y@-~{Y(jRSD?Y2r}=2>?>QqCNeA!$1e#n=_q>9>?i<0*qom{&eQwFqJr+
z;P*kel>bJt2Po>%^2=j|W&#a1w^VD%lH!0=-lBA-05rT;T<rLGj|yl^eXk5c?G#m~
z`8P@?J+M6A$9WWg7t$#TCIMY3#G?fU;qNan3xEbfVRQhDndhgg;6bJ-7cW+-x2+?K
zaTwSDYW_@!y!*@WKqSMP4mn972RQp1;4oAcHA>@TfZLjxXh5w`5-tex#iWP>BReum
zX*B-p$N+e2oWXF26b8U4LI8>50_C1dp_xa4;z8V6CZ+lcz#HExJu5?CQP5|nkg#~R
zd`ja;U|`mSp1VeNK#XAk^Fx>(X#V5=M}Xcbs&JrBBsT+&U{?V~-o@_(J9os4;6T!-
z7JZ83iXXkuMSGM4yeG~~R)6<i?i6635e5hy>_7oDw{FTuz!3(x0WiCV7trDuOs`V?
z8o~Aq3W8CfAPreXw)F2d62Mx3p?s=$?Wur3xnLkv3Y6rx5jZ_~fpXJEskDAS9z&#P
z0gV_-|L%zPRkHI)KGF;?S_jzZ2SOZBB*(ud2Am!YfTxvXkG%iMh6N9hFdDupKnUex
zI|@*o>huE$+MUED`cDV&tsB^I1AzzJA%Hzf3lZPoPTWJqS--$cA740G0LiA%9klo5
zoU9(^ZpZ=^w?c`|Blkjeo}zyPP{cg}hk!<@l>c@$fdU@^f-FSK$^XYo8$hdMBA>1N
zdt41@p^2mNjre!Wr%(!5E9+s>zcWEHNQ{WsXC(U9e}h!mh8}gczp4c^KLLTjmlErL
zMxh6=@&Eh8@Hx;=fa(gIQWnE!PRWrk;V>-pByIgF#!yQWwQjWc#KzrBEW?{@Q)Z#h
zGD012)}=agc+S^`6}R038*yYZK@y;F>Jr#LVlI)y)S&R(StL+kRst60vi#_uh-Gqs
zg<ZPC@Bg#4uK<&1VlpBBn6v?CmrMuN2-4P(6=nfo-CyI?|Ctm8Qf3>IV4^!L073Bp
zi;EL*#rS6fg@8R$+z9<`=LWFi4?qc?v=SiGJ8(Eg%EJiN`mco`>BfTn>0!kAHx*#6
z@Z&8I=06JxM^Zu}c<-OMMv+tbljef|Nx%i5<o|uq0-(UN`%T|j?^yF*2GDLQ1xYEo
zk;l3a$lW{?IKZs1RGGhB1UNlUfuFwP^b`LUh{Q&;x8Z+#k3oUHNMO?TGsXNz#Q%Yp
z(Q#k%=eaT<4^8~%3Kk!M78o5=?*0@5@N~J!l@r;y3@}+G8sI4}*UNvWP?l4HpE1l&
zfBxg?H~=Ra)LriXH0A&2%RH-7d<y*p;05M6#@ORGx~j8h@^1>a^mKnr7H1pw>es6s
zPQGX4X0B^X=<q08=9T<0dDK3czf8{#wa3}_CFO%s{%dRm1#aUQqfrRE2N(a<6|fzk
zI+b~nIR6+e4E(H9*S5yE16QD_5RfF19Q0q$UY!J>cmH?3OjKXMl>QtzHKHVXu^ii*
zu;cDn_KG`e%P0HHe`nwZ+>VGH5>p25B+56eB4s*KLnk&>qzKB#YtnMRcGjR=4uw4e
z6kT;4Xcq>fMG^BmZiR$|;My(%70`~@x@(se`<BV8QM-0A9q$DyK_C5u;M8^KZZsPN
z9VZN65(SZ%t3<95q$Ja|&zW}<bz}9`_By}{uk2ut-$Cr@<n|g-3Q{+808BT2O#dZ9
zA-B~I@tTukO#)Y^@(CroE)o}@Kn#F`h96F$k_FE`{jR~3tbY6!QK!bMq1;P~)TLd(
ze><13jnJ4u=@e3(qlj*f3QwbiTF$sFX*U4__5y~Fn@s;!J%t7|7#!jG#}M7jnlVE^
zBc*K$cupK{<F9L>aH8Ac-gJ34!xZw0_fTL@l?kxM{E25CsC2oUw<tUX2;x3xyG4Z`
zc-4<tg`1J2jR7yKWZ*Ia9o(1*dY<OJ*3C_X?iaLFnN$wvh&M1?z&;+;PSiHjf!)uH
z$|RL54y<Gi74>L<iR%D7poshsGE|E@GH}~9wr*4f8H%pLfg<AoXW$Gc93>f!v4Ni|
z;PR)NXstsv8qsk4LHzEp$^n2*VL6<%0!qM64Sm_~0CC&urLb~KiQF^6{0FuGPXv)`
z{u%MDat5lfZpeGhztPt0u_>v}BHO@&0mKm)vOwq*Hy-n2>3b}>9$QL|RwDv657~W|
z8wO~5gwEEzM&14^(Sq)P7>-Iq=SQj7z!p2wpaYpZ!ip<q5%P6c(n2VEgZh$6Q$RE1
zG7{Nuw+J4zqObQN?zi92!S2jHSAz)!43VP9rAO%V%m>)Mus2A>6;Z_p&JA$@{C%iR
zR*p)YYvI43-iIGl<UuuVO5XrO2R5`O0Ww?-+6hV=5&a(q_8!Fjh4D|opDzy=)nm{~
zXA#fcuX1vz6FKfq%<w`KAPpgS;%vAoO9;V@R~7O?c@K~loC4rZlLqm+X)rwKdOP3!
z_NWR?0uA_2U?v`5_a%?@HR=t4+sANiulM3_bYqGThN@fGt(2g^W#CPk@97D66wW8(
z+D5sie6qQv0+H(x>H>90`4a%v;fw7m0qei1o`^!M{vvowd8bq~og{FA-&8_^5ZmjF
z@$*J{Z7N!EV;BT6K4%Ng68az%Y?2K=aN$M=29Q-Lj+#O*J?M}M##s>a7;R>SIn*H}
zbUiK1%$5#AuKJj3p7}@fPFQaa+ZJt|d3(<A9@`Gtem}P5Z^8;JM3N|#?rKUsLb@cz
zY~ugMxfCiZNmKz{mhk>A`zJdqD+}MLWrMC>p9U4`stCl7&DHbQ#3kJUP1(QbRtH7{
zRtB<J((02*0#P4J|7l@ijIPE(Lt@%P-a`QiSTsUWEu=cY%9iG71aN`z+6uHS_f^G9
zowv9+>&ReTOr<Fa6LRUoXX4-36Y|kIO&pRFH>8|uSp0A^rVpnSsc3Xmcug|KGYvLx
zinI-vu4|U4j)FFi#ZS2A*y$IKgJxo<1p!NnTk0FEw|TWXAgF&@m1RX-J4gtLc7;^$
zWZQ2>sWCu+oYfhWk4F>m2TG@u+0>39!gvtG_<jVs49$$dS6Q!t?M8hE_ZTFvF67D;
zxdvC-_jDBLtP=$~(k~KC9zQ2Xdkb_b<Ae}-sZr;K2MCw$qo}LHgB~culsXaICM6HB
zA)qv*qrYHcc?Z@jxS`d}JhKR}ds3lQZ&mdv)T$R<fZ8X$fD@_(Adb%GAkP^5ktxKg
z_odLN3$H_IV>%{fPgn{(6JEhXZ=CDgdB6mBLz4s|Jsez$=|t+>+5qmOoc-}$%96rB
z^oI!&-jnACOZA^_jyttn`5Te?uK(eJYrFkyzE$$cV~bUU@I`t1%0yd{r_=htPo>w0
zf^2weihd9Af024cPkFZA>2yHijTZ^=nZ=~Ktt8uzpUY_N3(kkjy_RWaWU(%FgHw$Y
z!1Y;%tSSA%{ktx})iH!uC6z=h#2(|zWAgRoV%|?vKyzi^s;(+^vl~kgV&xD=HEIFP
z=scTik0HHa$sgJtPIRp~o2(Lvn;zpQ!@ZOOFDC1sEN?uke=apNSl{mOM+Ev35a6Qg
zPVTH4gve}83bQLw@bf_?QB#d|>vT?Ec8zC_ASY`&q3NMyER?tS>DG;|(Bw|@>iHJM
z2LCq~QdMk-9~uXA1QnJ1B~5O(7`8H^rmW)p_0RT&x%1Yr8N#fu8wt47FSh9{8-)rq
z9HcxFms~A(%nRXgVt{eKN>LjKQai0sKkXbFaCZl^6E!G0wH<VqDcNnNx`vW^OhGug
zB_L)+Ge)H9HR(b|lM%yvAkdR!<kh-c+3)psL?<a19|B2)RXIfJk~){Z{EfQ^^IRu$
z#(oP?%@f|+k}BUf!=KShzngn&YfqB(9b7FotI0Qiq^n$Ysk60(F$#zRwtP@4Rd)}v
z3E@)?NE0sfoK3UJ_R1%!i5Xzr%l)!|xIGIf5y0_@+^QkbaI#1it;y9SuJMf@#&M1Y
zC4vkpaE~`6V9Fx}moIy|L+!@h{aQ2}218n=M_l`o80lhQvhB~0PPoQQswR`_T?4x=
z^N67D@N!Y%>_PR=maa<wDcyTl+S?HKi;V6ZYC6cKE~nkD0XY_d^xMwVPoS_5{{ok3
zy4;dd7I#EOuYXDT0l)l}fGG`!c~6`mUO<>q3N;<psPng8PE!~UlnUu+qHw@2xFgu>
z>rLk0Db6Boubslg*{H54DJF(DuUve^8Z(<|Zn}jF9!9`&$pI$Zz<#S;LY0Iz3Zo0Z
zO>EfV$-H46qwr%^k;Bua&h>h7RvzEpl@7ZK63t%^`9AeDQW9+nFihi6YBd&oYkPb9
zk1SklE@E0s0fsNX#0zr-{_YAj%726)5YY7YT*-Y8<q^3~die&x9!%ITrD%A6eVb42
zvyyH^Pd0WNopLAifm+!by^-r8-q}cba22G4juMK8%(p1)Bg!M;TUec~7)oYz`7VVD
zFr}$zwa)?&B{ID}@3)B&c^dx;9*bmf;0h(ocUrSeCDRzu#|8ey=t}i}F!n}iaxc$4
z(pRuGK8Ap?$k#>BkeT0IdgiDJ!4^GVj4S7#YdYYTI_LJ8dL{52cH)w#;q?>OT}#W1
z{#(QOdEe8Ehk*^qY{UR1sRIMNbKBU(^c484XZ9a_1!rkeo(;-edIzf%lk(6%BV;08
z!Ek0k!(W!6AL}T=Ft_Pb0-U#_{d;QEWM(Ew)gQP^E&`X3`AM)pAPwdmP;FPK=mZ|e
zczIEsUQI8k?E|_k%wDZ&?yFk&uIjkG<lkz2)mlJu>Z-v$#)S015baN0#lp?@a?z3D
z;={i=z*PfHL#iheW3HWA((V#fK|t=zVEwJt_M<<IXNn`6Kl_5(a&vFBt3-_jl;_!z
zUAxa$RkAM9@dqC;<T}5R&je}Rvm}Oi_jzz#*BrNG6ZJg|6eb-{G66|57nj=p20i+)
zI`_ec8&y+3KdxTPMTK2sGqlqp#o(h%O3Lvo<{f$Ak}A-OL@qx-+&s_g93gNOXo|(1
zR!ej7^KM*y#r*GxSI_}-7~@IYtB7Pda)FaEb%R)!-xPcr5kNfy_R>6_I09}8vL|CQ
zYfF2%qZTu{`A~i`Zm^xLyhb)6$5oZxjfoBz+;pO~Udt})#xjO+vP|cQ%}H>JfQ^4F
z9%Vn5IQ@A1`GOM({FBUi5_0?G(QkFP4k+KonXTN@@wjJcYCj$k2X-Q1Rn=qd)OO^o
zcSD4Yih|zmJ|I~0_oIj9hrng>#eE;e*``bAKVqdEi>I`pHBCKOTxLpXDNPXIN5Z{&
z@-+W)!%wBw0bb_gucu9RLV3!@kl1@lX)nJFCNM`NP;ekc6nNpxFAhluH5mqdyT{ts
z?6{m8kyw44^yVSaG~vi+J;qWw;L?z)*V2Qxxn|z(OqUA}Vm96i0lh_st4_(s?eJcF
z`QoB#rH~e-hoF0cfN$?iD~I8_HwN@@VmJvFV{eWrFQ#4Af6b5(F(B^Nhm2C<L;;-S
zP%4xQ=@jaHgx~Z?yYU^SJ?sa5U)goL-9w(*N2r}2<QPju|4nSz#o2zll`2}QP7ii(
z%vga}lajkAQXVt@V|0a9&2Fk`R?Nm5A$L3#&#MY|OIfN5=|qONTofviFtaM?uTWSZ
zdea0oZV{6Ltf0Y%=a%RjoWpB;?$$fi*Jbs``>&TSebRiu{!S+tO)kPs76<sE>GMs7
zr5pD`ccC)NuQ|WrL0yRx;u4?$b#~b3H!Pj(%mjB-g-%5@8p+NoMAX};Vgf649)aTN
znZI-ZSmWC`#3D<BfZ+wJ+=to%33jPe*p(FBqF$_I{1#Qxj<$jOIC>secLw@*F2heU
z*vO!rf+69XGR&Z$TCv4W<FzTB{WqhN+T`~WdUggR8T<P|8(_5In9L`DBIvvgFSQ1m
zN;emN&`b@t12@D)1NBqW&*%alertZ-${$%>0zGQE%;Nsk&l|m*G=j3ISCoq^B?klH
z|KljMTFK7lrk!;0PtCNmIEfH&734K<uqh)RBn?^M3%6woN${RIC2epEdn1&m27}<!
zDOh8rCYj?fkN|4)MYFl}{+7+oUbRh0c=&8nG5#f#KGy;cokNd_Ou9!6<Sy?qJb%4h
zBLN+J0XtvIt4oNiI*)<A?)*X8yyKj(l^5{&j)hG1a*Y||>+^#Qfzqc;_b74=i!dQH
z)ad^u5xd1d(w$RYSDsVQET?Xh(U98w0$`ptqq*cUk$5L2;1L|hQ1rq&PbQ5J>5&x2
zkD5axz4O#5AhY-6lI`<76If$LDMrKqif@~pc|{-(eloWp62`e}tq`6~>0n5Xn~L;P
z?N)&>^yELtY>nS!c~ZW!*$`9(JwHZT*@PY1Mi#|BCw;?u#oI{YM<?TP%E17KRKjeB
zV&aMF{l>)|h?T@{j!{X+9wgtVaPDI)A>ruU;c*gtdcdVfkd#FROnyA2?kWa7Zn&`(
zOEGBT8NEk4lE((=+LX(BX}U&bNM|KP+YA((JBwyuPbE5=DdD@ef^nO@Pr!nS)OAIi
zGtVh>fu;5y7B|d54Xd(fk{@lA%U|qk$Q6&Ypu0IOwMono_JaN^cw2qe7zDrmrYUkF
z=~Y?LlBaD1F)%Rb);+p3bYI1n01atK)js|VX7IQXwz>gs{`YKtC0C`g4o_4T_3C;|
z?zP4Q{+`842X49i#+YgdSYd_p<ly)!tK#T^gY*eWVaSRG61^QE7;|k^^ZqlM6q_rT
zjmU{=fsEl%#V2l)Dt`(iH%-+Ij|kw;lU%@)zWMzu%aXTU7B?eR0sufos86QVYKX-t
z3s-K3@)GWwhn_Gu*a8{F(eaJToa`%?pB2vooFZ(WVZl`G=1p2pP;LvmHj@h%?y+rY
zo6jkUoQ&~Jcf9L=I2L*QuKzMm-vv2$Nj0}wnLkCqMpIpeQYy#q$e1l1nUmwWi=eHL
z{y^VpchVm<1jyM{htuj@fk3t+`HPZgVtL+0-G<}Pqp3`0=929Uu7j@XjIzC$dU*o_
zt5AOrz}%)*!g+k4LfhdHQls7&d`sKr-*i|!bV}b@ITnPRu!L&9tezpX$~?GTA%BhX
zKMS;|G$W#m2K<gnK&EXPNnHNOFp^l(Smi!L8z(X*A{@bg`~WCL=Yo<mRq@v>VNNw_
zWxir4-m7|2?l(DfDD{8Bn%ln6PA=d_=>vuO&T@sOKfpCNUZ4jgDn;)w^vka<P(R?g
zh><}y1E+Nj5Zd3V=RRpDg1&;^$370H1n7PXmHsG+HXu`&v>u$vKyU2p#wk;p0{1rd
zuY6W9nZf?;IJQuSPf8*ex&0w3aK4BK7Ga&+N)Y9BYgRJ&(K;d1<q!#d6le49tAm58
z`LFyZ3vNFZ&%PU=9a7>TYx62<h4Ptje-?7hya0u^Mdy3f)z$0Mz^&;0YHuD5siC@-
z9dt-w{b4}WD3cDR-;`C*L;DI8<0%}!^u$WSqBpbRp)?s@e&6z(ep>Qm(C7o7GW+S=
zPs4jFZ8c(>eao$5<E2H2N-_K)1AEqSIF&FXsec9aF}3l}sEsUicisWl`bSx*=oZ>)
zYD3#1%m#m`p=z{?y@{vl<M1z(DsSNa$K>O&YlgfD%^p|Eu28I09-Glu)r{{n{eZh-
z;QrO8{iU}L8tN>ZU${%}WC9T{khEuT*V9>zWJmK#+?cp)H(IKAmT2%DF?~Hqd&qwq
zvc^-AoBt3B*ekpy@CeF7xX;IUp}qFlK=ZS^`-Zqkvth#~YxNk_{^_h!4vh!Dwc)o1
za;;`n$5;zz<8OG!O>R`Ga-jqeAo8&qv=;&UYYJs>Cx#Ni`9waG6*w;PbJ@VY$W?qA
zR*iqU$)luEj6HtS1>B^)B$~ztS$QQ3YyiL1vb&9HxxL&{ES(In7zYlvSTZc~+fLmY
zX*tL|cM>_sVS5pvrn@kjcG11S@lypSo(dBUYYo^1UVNFHtHKMhC8!>0KPsOa9yu|x
z3tA*hr$`OPjK%w0-oh(<;itMLjnBx@{Cr-cMtR;|E{2Tun;alAtv0kq*}GJGZ6NI^
z%Dmb}-7%tWwZiAz)g2qbB1NjktXCm?zaLjfvz<C85pS!oSSIRTg+II6jUka4ZdeG+
z8bGnUAMrp@*IVtnx=(~Uy3UN{$cFb3|GaY-=30gLFP3iCOq?pm+peM>0p9DY&GA>y
z%U&nxyaw(U_w&CwndGm1AV9GQxFFD4IW+h_Rqouvz+sCRgW@|rIAKrW{MnO@H`AaE
zC3oUAChMrps-lXDEdoKI(B4lkMR(4sdv?zjv_!J!hTYl3JCPL<B@Gn0F$oIkSK#|x
zS7I#}x!DO;+3pj%HJHGq+(WQ%gSHa-8;K$Wcy#dV_Clu=soB`Z0`-fisf+hrSo%0-
zgutq3fN|pY;{{nEu8`ZxI)1r|>$m+?rEOLx$Ip~&b^w5#ON)+<Rz%-Ysc+gXxy~E?
z$>K#^{^~<|nrk}j;lQt$qgS?MmMh4eP9>%~Ys(%mN5<!0sywZ&JG@x`qqZymhid)f
zvl;6!V@L+y#x|B15xI1kV<{>XF}K3hge(#ARiVom`^(Z*C|Sp)OeATsFLQGZrL0LM
zOZN&PWJ|-C`%KIC`xo5v+d0oUuk*Z~^EsdA^LfAD&*x!=-~ZKh()mn4LES`-|7BX_
z%D`{)&D+*f*5>b)uB*7LO6vyr<QKj)(_W2v;KXs8<{7yDX1D7MT7Mlt2~)ALGRM_e
z<cY)qF&zE$o|}AH(DRKXN>b<i3h!1|%M@SW7xHc>C%t+yVy5EaTc}AiWs81JSz0RD
zdAUhOXH+yx(0XRvw138Xf;xDudC<orNz6LSvr#!(hdOso5z!??NN?#nmYhJi?yb%s
z+|<gdEE;JnIk|tVkk_#Hv$(7zYB_QvtA3Mm+DcB1h}{iuTziFchTKsP?V^ucnwpWn
zh@>~%4KS95C8{9ur&Vvz?c|OKt9?Yk{_=4UH^ldZJ^ZjbVl?4_l>wr5_9wxuygma=
zc2X`jI0<F}lcu7};?!9uqCK-7Y<CX~vEoQDulsIP1l!uj09P*?chKn*wkLZA2vyR;
zO4Q{MCgOU%{Q^T1=PNM8WgK0MQzc=Qzko89TR8B3S7+}}#B>ejlF5u<QA4ssPwW*D
zl8MG7cLc{kpPgT|<U67@ldb9GG=@`|Ipe}#u<^=6lKxk?bOm2aj)H_FtTltQzyry-
zUp0Fo8X^H7>~;T*V?6=>Ty%|@7wum*JZX;7!yPO6PpQp=TDw@ybzBA#@eJN!rRnjw
z3}w7+OqHh6JgssUA{xOT@i(ic&(&Mp*FZsln_K=$`~9sR4E}`N+GUb5Srm0g7GRR+
z35;@k+%+M8pUH6!Xhb<QUc!i^Qg!D4bd&8%v4uu&?|!j%@|Z?$l}QU2lts6i_!@^L
z_=%qWoa2Q}B?~)X*c(7&aGZDO22I<Hm@Wxyx{kd!mAw}_?7wrR^=$PM%_DRZdv_UY
z7A;M{CW`MvGKK7R$NqywKE4RvyJqJbhkHLHZn5U7;lmvK`EJQlu%RUY(Gd$*lBwH4
zmS6k2kbftOyo5s_WgX{xTX}P{W^}bcYhp3zk&){;HjM)3r!(v*Qwjrx8OkD>^m_hh
z9rnj;8VvMCgze?vZUs@Mu0Iv8^=gwJu>$aaP5;MH0|oMgkX^p4i+7H}rQ?IE@}m2*
z>SgsrZ%f#6p5edb5Eu_4;*f|s5~RU#KWf0m*p6j7A2QqDi3+0T450V7H$BE4(`#SQ
zFiWE7rM7K#75b_8yHTk}JI467?*jAvt%`e4n`EB_tiIAmZDWyC1356#)>KpOsvZ4t
zoOr|Zlc4IkiqX-?yYCA)OJxF^<#EB0IsG<BY#C4tJ(B34lmm3IYeDW&UHN|ez5kxm
zk?RhzSQ%xPM&Z?CkcfC;#9XV}KE@RDwIACuOgY6ee%mR+WK7*=<Q4GJ`rF}5YgxKH
zq*|_0T#oCRoyWh};qZdLXP__GVhFVi);H?Cy27Oltt74XiuWL~`Kq!Z_K*d<q4SQP
zxoKBX_#Trd&lX#(F@m-|BGJRxDKH1KOfe%iECpuGXw-U%q(NgagJ#}1czVP;9q<*2
zCheZTbJq*ISv<BB^B4%O{)~|?3Rh!|M5}vsW6UXeS`88&ohMIEni1aAJtD4pkWdH!
z>4>E!$L%5Qh}u}gJbi!v970;hC{gNlpc-#@<6{tGJ?+s;*A%iqimF^jvIDkZ_A)aQ
ziAYuqPOZ;q+3q}r39hl+=A@EeUbWf&mWq2$O#i{28tsKVpH%7w0-v!ek{^e=P`Vj)
zTX9ptFHaD4(Zw1sR(k+M(8KjsJKM#-@=07Scl*GU@@#Ec_|f^-a|w)y5low<*pCVm
z68oTB3CvMsXhrI1bvmqXCvR|iy2YKw7vvU5WJ)n-L88(TI9ycci87{)*_+s(yy_Z<
zzg!u3&3<{9kWhCD;ATsIZ%04Db_nx}jX}dLBnQsy4qs*Xio`>bduTz*C7YkMQfB1z
zKU`ApPVi7dT?Mv~F6Z}DM;U%l?(M<DWs^@A49!L5rJ>MRg|a_P@w_<~Qvt2FO%<$P
z|KArPq7h(&3Z<WYy7I2bp53MR#xg-|Q6r=%weIlY^?u`AfnB(flpAr304Bx3GpNXr
zgAhFaf)iBa={4?TF3=j}qD|-YHS<eL`IoYL6qE@%s#p+ALM}0YgtJGuTHGrw2$gYM
zeP@1g;5GJ$%gg&s<oMm8T|vISVQUFWfnkRJXco|k2{jWkkCHGqwC?%#{(c+mk;w~C
z^vGk<LUT0Z{imKSo_hSLnXEM#ZZS+5iroCQuVi1P*K6(2MCb&tp7EQcD)oyfWA}R%
zgy$d6M;+mwEnPxJv{W0qq)kUmP!qodL`aWR?(Aa6c?WE^m<x)QX!-M@g`J}ZOqVvd
z<*fO7&kC$Mm!pciL9vZ!q03ON*!m&{I))G?4G$6TI;>*RilwYk8$ZH;J%crQtFO8A
zvv*qLhd2I}d}cT`vz4^;RJb||2#g@h8Ts<>+%ZyCTPEy!u8>?2UKzg%n#twz#Xp*X
zQE$zbx%gd2P$xwDI?uFef1{c?92DXFkkU`$KiaV!N?_tz{H6F6@*AZK?gO<{HLiXq
z-WP@BWspg-#kcnXc}y@20jY_9eK$l55<2I9>)|m0GP1_ea)!%c!@%+Xir9g_fKw?O
HGz|6+lUj`x

literal 0
HcmV?d00001

diff --git a/standalone/rpm/git-annex-standalone.spec b/standalone/rpm/git-annex-standalone.spec
new file mode 100644
index 0000000000..1e44d79dcd
--- /dev/null
+++ b/standalone/rpm/git-annex-standalone.spec
@@ -0,0 +1,44 @@
+Name: git-annex-standalone
+Version: %{version}
+Release: %{release}
+Summary: manage files with git, without checking their contents into git
+License: AGPL
+AutoReqProv: no
+Requires: git
+
+%description
+git-annex allows managing files with git, without checking the file
+contents into git. While that may seem paradoxical, it is useful when
+dealing with files larger than git can currently easily handle, whether due
+to limitations in memory, time, or disk space.
+
+It can store large files in many places, from local hard drives, to a
+large number of cloud storage services, including S3, WebDAV,
+and rsync, with a dozen cloud storage providers usable via plugins.
+Files can be stored encrypted with gpg, so that the cloud storage
+provider cannot see your data. git-annex keeps track of where each file
+is stored, so it knows how many copies are available, and has many
+facilities to ensure your data is preserved.
+
+git-annex can also be used to keep a folder in sync between computers,
+noticing when files are changed, and automatically committing them
+to git and transferring them to other computers. The git-annex webapp
+makes it easy to set up and use git-annex this way.
+
+%build
+# Need to have run make linuxstandalone (or untarred the standalone
+# tarball) before building this rpm; the git-annex source code is not built
+# here. --build-root has to be pointed at the git-annex.linux directory.
+
+%install
+mkdir -p %{buildroot}/usr/lib/
+cp -a %{buildroot}/../git-annex.linux %{buildroot}/usr/lib
+mkdir -p %{buildroot}/usr/bin/
+ln -sf /usr/lib/git-annex.linux/git-annex %{buildroot}/usr/bin/git-annex
+ln -sf /usr/lib/git-annex.linux/git-annex-shell %{buildroot}/usr/bin/git-annex-shell
+
+%files
+%attr(-, root, root)
+/usr/bin/git-annex
+/usr/bin/git-annex-shell
+/usr/lib/git-annex.linux
diff --git a/standalone/rpm/rpmbuild-from-standalone-tarball b/standalone/rpm/rpmbuild-from-standalone-tarball
new file mode 100755
index 0000000000..6e636d9709
--- /dev/null
+++ b/standalone/rpm/rpmbuild-from-standalone-tarball
@@ -0,0 +1,38 @@
+#!/bin/sh
+# Create a standalone rpm from a standalone tarball.
+# 
+# This can build a rpm for any architecture you have a standalone tarball
+# for, and does not need to be run on a machine of the same architecture.
+set -e
+rpmarch="$1"
+tarball="$2"
+version="$(echo "$3" | sed 's/-.*//')"
+release=1
+rpmrepo="$4"
+if [ -z "$rpmarch" ] || [ -z "$tarball" ] || [ -z "$version" ] || [ -z "$rpmrepo" ]; then
+	echo "usage: rpmbuild-from-standalone-tarball rpmarch file.tar.gz version rpmrepo"
+fi
+
+basedir="$(dirname "$0")"
+
+tmpdir=$(mktemp -d)
+trap cleanup exit
+cleanup () {
+	rm -rf "$tmpdir"
+}
+
+cat "$tarball" | (cd "$tmpdir" && tar zx)
+buildroot="$tmpdir/rpmbuild"
+mkdir -p "$buildroot"
+
+rpmbuild \
+	--buildroot="$buildroot" \
+	--define="_rpmdir `pwd`" \
+	--define="_rpmfilename git-annex-standalone.rpm" \
+	--define="version $version" \
+	--define="release $release" \
+	--target="$rpmarch" \
+	-bb "$basedir/git-annex-standalone.spec" \
+	--quiet
+package="git-annex-standalone-$version-$release.$rpmarch.rpm"
+mv git-annex-standalone.rpm "$rpmrepo/$package"
diff --git a/standalone/trustedkeys.gpg b/standalone/trustedkeys.gpg
new file mode 100644
index 0000000000000000000000000000000000000000..0742182ae1d240ceacc2ae955139de1636da1096
GIT binary patch
literal 4979
zcmai$Ra6w-zJMnfU>LfG5QbDzX^?Jd1Qh8;q+|#|QVAJSx*L?Pp}QLi0qK;I5(H^D
z=w0{T|5@kZJnXghe%kxt+u!d?0&`(#>F`z)VFT*pu0z>y=U^cI9PNx-5wuBIS5QF2
zq}3EChe_VTO*KWfT282nNmHJ{+aJP1DB{u)<XOodWAy&@<CU$QK8BJP)Sm9PB7EV>
zswYHyQvv)hKfpSVO6lY#@vP-J#2J-GFsIm6GB{I9lk33~_5qJ=iU`YaFrm>Tavk^z
z=99XlM2_-yPc~;DG8yJQ-BDb5xsLQ)UqAMFP!SeXBVWst50!t<SY1`k5e$O%I6FVP
z?RvmUk^MXc9VmAZ*`y;oTQt<%1Zhbw!`hf7tzH}sz`JTQq=43s&r#n-+q1Pcun4&c
zqPy!>r8_<0(|o`L*enU%*{`m?o~YFM^shj`;C-zD1@DSa(j>_RdC~6qRXP^>h{-V)
zu<)i>xOUKUY(P%zm4G(?z22kjb!ndi>{pHJG1HQx7_P#yk2sFvzwDzO^ClDxn2#S;
zQ0@t;46vlT@2)$@CnDThg5I=zHILG20foy5rDU&l*TWPl$tD(pb%&!;(sz@1>aKCy
z%6N#FGVt_>vc!2W4FVU4m<arh?$N8asl}f4o>cgfabw^JDg={lT;JX=vOp<2;4^Uq
zixPb?W`gqm$hl~Z%Z;*TW~Qns!xZqz6Kb+q{AiZl^sOeoOMdLzR}LOv##x{RiA^YE
z^XKsekHl`a%dkB0ZdzkpvJ}6nQ%KE=%3k&14804>1gPdvr~YpBz^7d|1>!Uj=Kc;<
z`p~BC@VJjyHwga#So(e3!d08GR7EwDJlE%2(=XlN3n{KrKN{Xw>`i5NAsLv1PP|7P
zGV~BM3?aI!GIBk~Vt5#@f0estxd`hUZ<DB##q8_8fIzTOzViH(lE3?CwS<5D)bc+S
z!kn*eEy57Nr+wkC3AE}uwMEbam6sk2KTsLgo7l2qzvL8aK`ow(=ab*-EMBolPW-$z
z6(%+-{%U&C`GYZWVlN^){vKo9qp@b{CHz$Mw~GojfY1$p!`g=z1XHFfN8-;USG95(
z^Re)5O$u3%m)0D1=)yx0{_=)_UNZcvH%%m+Bf?6+u>&$4;*PNP3$yCdGJfagH!M9v
zdsf(N<X2VF);2DjrVb94?(`Nm&MrtBGglWIM+bUm8*2v}2Wxs;OAq?{R*pz|CC9s+
zqNTI*1A0*#3&~e^$Cq3VruLTN!EZ50?mip?1oY?YfvCZlFeo+_7=%fN4T9ppFvvk*
zAm|<tMBxX(ff5?6%zZ}nK?kd{0XM9SW`*8dCw2;|n&i6*hbi!n7z^S%V7yo)ym#6T
z#{&rP*T5LG0?I*n*GR|lbfDi(N@gW9Tfw=J@~iTc8e!ma5CDt<(O{4OK>*A@4-ka@
zxul<PhJl%Qt=D0i5D-W)*iQv7nk>=CuPThLE3pvBTYhr3`SOS?u|P?xbQr)EOp|Ok
zL4lOx1RjiR`5OyMFaJPo!6p#_m=$@=hn6laM|2ED@)N=umFQt_6}?Dh+@<3Ot;<e>
z49tx9jr|UrKO`=dDA^)<ZNZoqON#lv<F1VL&~uUM449pcL~7B!o+GBgj((_%ddPd~
ztKVy2%@urE%7stObH+}E>>lqG5<?qDK66c9*}DH06ZBAY2zTN5xm|?y0!~VtrOh3L
zS~ewWeHUrNO*b+Dx9~fvLMEZc4bL3cI0*#l36_7+ew!^zC`z}Z@@o;Cu-{li&!89I
z@_8)I)XYpAKW_7kLFwk^I6R=fWNRtwkgl|E+H(%$6A+=<H|W=uFG7;oDkC&@g)X8C
zm9VAO86<z&aR<;8)-x(7crQEa9<Cd7b~04XQOmekZ*D_p6{;kz>!Zay6F!qEsY$D5
z^G~AWT%9Y70W-0+geMhpYA{}I3Dsf2y|8gZvuq-9TGjDFCMkKBz#441Q^;ORik5-;
zj<SsC6q}I|Y%KbHXJ$nlbA2{X-DqZZckBnG7d#b)Uhe`#*9JUmea7it#xwhj7}+yJ
zJbd(#WvL}Kk0#Em##}X(kW}jQQ=Ghox}^zm&?E7SL@DaX$gGabrj~8hf<P}D4%?zh
zf~U0b>^npNNgzB7C1D19AR(aMLR$w_QodWhv=cm{V{t$D-VR|~8dowKdy;Tgzd^%}
z3ULc~HqivY-ltDoLhy-P7MTHP_|}dToXJ{8zOKB<@O)SQD#3_b7vTAD&DT$Px%{xY
z@xARtjp2o$M+dt&W}<%m45eJK<9?0DwE$Pe^LDLKp&3tn=jV=o-oz+-yy%oQsCUr1
zxe+;jHHy)(Yz(5ro|fStlOJ|l(QJ63CTCTw*}?^yG5LH{Ho4outSF{JQ2Z7PDzlR1
zCtAtG#A8m&z{>Ly^W8!2K)}$)N*r0_aA3ibmGZ>HzPR^=JqD}E^f+B$u6dRgz6;%z
zAAABhO>aw9{0geSA6w%L`_))pV2Ksg*Vn<rDRFD4RwzxF$>UGIF?$G$T76v{IW-{P
z&n#A(x+dvK<DIm4ibCtC*-68{5A`Jq^EN4tCj5RVfSu&^t1H%|$-979-3#P}a~Q4?
zzj-e7==&-!)9+s;j9J{ZOXNkhkDs=IR3uC|WpXFnO6k*fn|89q(q;wyXU4BEmcMe?
z?4YhS-%Z57@!Lr=hBg17nPffCsY$i&Nod(K;2YZL5SP>q6K+wsmy7vBkJ|dW;XPZO
zJFWg#VkZOim*0+KRK1~*Fi%FZV7-F-1?=}t2$H0N;)0(ASnc|-C`KSfSV#L*z7sc<
z`Fb!nVi0FA4~o;`#sG+b0ALl(|LKfg^smY!EiBD!OdYr!k=EiUkjR}-umMbWF8d#G
zLH-&ILWTpyhC%-L3;+Qs2{Sr@;J|<CCKf>m$h$a{IF`WWf4z#DUV~UpXu?m*(WVAC
zl;zIq2I8`ga6M};fjtpiqc!fueeI=UYXygw6oi-u1`!wV4c&O}L?iLM2$EXdf^FlB
zqEi`bA&du$V!trU<bM?=X$M`8;<QGcf?6bF*0%F1bijdFrj>i()(K@xYh(N#NLPgL
zU|?``ENock`|Q2U*W~lOs~g>q29jnUd!Tu=;hE;|7CFBDPQM!8?N5K=J8^DmWu(JX
zsjGeEvZCu<dRa~J{VJfZwDTyJ@4`{ld<8BT7i`17BcQY6;3e;#7>RrCW0bI#l<Cgy
z(R$O(_vpJj6npl-_$l6Cp5nGc*fhN4v%1}y=X@X5<JMCO{Qbw$MJ$G3OZUD`$($0I
z<kOFZxOw4oijms7&R}t}vKe1ahmQ}<kqedOljYQ~a<Wd(OJIiUaB3K*Z?yVhurA(p
z`PZPWjKbI~%f}r*G%0EFKUu^`z+l@>0Vm5)QJ1J+S$wyTVp)}HxwLS#%_KD_6E6n#
z<F5=aJIHcAL>(?>NvJ-Y{QUY-c?-?Hn?fa^=$6Lxe4jbV?$zjn411H+MHy`F;P!ej
zd~j!zRX9k@Nl1k++l9)5_{+7K>(y40NNuE}B&lyHlYO|8Tl41*S*$u(if#5;Yr33t
ztK5i@CS~udF&N$f38B1>LC!?uQv08Y^dERh+S<5SI#{}J-K{&k1pnfN_<y|qz@+h?
zko}V_97BRDD5m$v=P8;=z}3@ndS?V`^u<Xg3CBaB=jN+{2AQcu<%C`}dL*fm_8Nn+
zX|Gi3CV6<8u6oI^g%kt@h3rXz`P9B%s*_WcV{S0T!Gt#fNoC6$$Nh^3-dDaPI*-K}
z!8FCsXbFC9!v?65;)@Nk>{**7&m@J;!(aTUi7N2%q)~C$NAR9nmd?Nv3*i#{0eXY9
z+k6Wp(YBsSeg=c*bbugU!Bomn1=?<?QRZ62u2wr?6ktX^Y}Nn1lE&{IwcklrFC=`B
z5VOYotcHPiFTae@XSI&=D1fYt4O?<4=#zeMD`8FsYZ{hoQH57C#ik_rDaq7XXtc9&
z8#Wu3oax#^plF1ujmeWT?9`GTD=IYtwy>E+rK_LHv8cxzQ~Ix{>X0`oJ`1F|)Ywnh
zqEd9y1<oDIfRh+={qbz>RNKdMA&Xp#Jaw*dgduMV29@PrgbSo^G{_`g6JkvW|K_#4
zL2%UG|G;vfpL=>cO1f^H-0n{6GBRINMu)riR!2Qwb=RIe(2}4348Nl#h7@D5Z4CTF
z<Uw-o!E<lV1cK3=<rqCX`Zui1W9Q&7@L|E1;$43730l@uvR_K6>#9-bSKF`5i+8F#
z*-=aw2x>gyK%?f6Aq}jWtz4zWZOYo|B#tksxI8{=(6(B>Bf{}R6DrN{6Nn+(Fwz#e
z`<E^FKh*W_A%+48{RQi;#ME<M8veHu``<|NYbUs2DGnZOJdtd`9x9-&-5H}Ws|g{+
zB+vUTkV`?vsW>_dp3-Fc<>7uZkFItj8#!1lfGX6MWG@&|wkCU*<)_2|jp^>)xW0dJ
zS{*`}y+(OT9KjmyKuw5viU(=c5T)kfF;B^}K28rYJ>sCje3TJLS+B~Le3L1hYGXoK
z@>7U6OqKL;5ySVW+tnH0*jOR)gQ@mg_UW`Ie5^d5hSk!ZZ(*+sk|q>)+aTpPeFD#%
zYA8^Mz<Td_ZsIOo{o}L=8O$%SQ>;gmLTopOsLVNuwfz|;1_U;k`sx{$XpZmU2BE%X
zp2OanRVjeRk~o{RV|d6Itp5gju3Lorv?=-B8TO6!TY0k$XxG8~cd7Bf==~1hCj=Vm
z-&n|No2%@pLQi+!6SBGe^-^M;mtwrh^|eD)7Is(@r(P2O$1aw2qb5C4p9?^K1yeEo
z;e_5vWqt~RJJp6Clr+^m9#(>_jaP9lFf(_B#;Va)Spw!iQbcy?7#<e3quYIE+SXY#
zSEVp_E@|>&hU#jS*5ruO5OfX%kL+YrXr8`Y?-wgc+<cv55-GUFpABozZGBBJpsq>A
zw^6lPD`#2AN$*p#&^P>sLgLf5@k3ux<(>S?+0T+sS>=yL6-+jpZS~Wpo%VmavS_8P
z=oWN+SbIbqd9$@(BQkd4CS2P5V0N@K?+;n^e<O+U?Oh}dY3EfI$RpCVY&6q}Jk*g^
zu(3dk`-TQTrQRMId;!-yeAto{J<UXQAcuI^ua|3jmwCh9+K%IC-`36QpP<d!8b3!)
zJc9%smmhbRbC4D%2!=%W&)fAnsqPZ3EZQ087RGiVctZkoys}sXm4mh2A2gk!!_S!3
zjx<<A0*WXkPMrNVBr9vs2cnvOu)T#7T+T3A@UUMzA*Ye5><wg7KOIZDkK1a(UR;G9
ze@0RK5Q9I`Q12IEuvo~V5<l_d0F-jBM`Fd+tJ;|(yp#BkwI66Ls!w(+Y&tO$(6gre
z$d+R)R!yAD&M1Qzpb(vYbDpX4fIg2s)&b-V1s&K(!)84xQ-*Yu8XkFaal3W~PZDn+
zzZ|zzaf_y>nHwEExl4c`O8K|Z)<k+-dK^B&I2l7v)-0-|tTA#71%H-wB9cwQ%9X48
zGk%%kU+{VzzO5n=1r#ERAYyQu5@!Z3%O_IexzOI^h^%fA#-S>NIx7)JgM|=*bnlx?
zNtCC56%7*asP9NtjUxA6SZk!c;jIy?!sBtS%is^c-_g%Gu8wR!n6xlj281%v)4>F~
zc_I6}B={`XPT}#@Zj~QzGFfo+y{RoBNAK;otJFdnw!bV#3mDEt94Hp8bS&va1sqZY
zn?xL?zZBnirQ9Z`-bc~1z$8M7YhLS^4S)AHl29Nz49dF<g8prtw;*cVf6gOyDS~Ti
z;#Sx^p`ei>^JeQ$clcpdAt9~e7T#It8Ym(&acsdTV9;_cK@@SmvECgLCD*81E6ZT^
z$+_FRP0-zH(l(gIzb`K<gPWVhSSNNjrhsPqEzoIMUsaYbg49UdlgSfxYS+#c7#DmR
zD1#+E2_GY|E3P8<b@YVunGH<_bq+e&I9=j-^kIKR((z+gLiR6Wpyu6F^D;3hncUHe
z#Y#Q#<3V2M*6+3S&fH%&pqVQ*2`ztbgrPaZk4F3l*m0!t<JuXW`CFL9YU@kUWZ5I$
z9rYWg^rgK17p5FovZDCX(0gURocTfCK?Ld1W-WV^k<YsnC(|Y5HPA{A&8$NuYY5X-
z=Er!qsMhm+4cn?Pj`Szd7d_twjx0jOWbDa0Ul>-ypLIrqZgre5B3&;UjeuD12M}IR
zeYLMdvb(G!m=jWg`(&f?>WDGigbA&wvgw^hX8lu*92^rlgD#vVP88Y%s_VZIox@49
z=;glil{M_8puPmv{Hv=RQ=Kg1C*2dkLN#ZcCEhng-+XkcYS)MSTbreCB|lgMhpOY~
z`K69{LPeHS2L+2YW~!`)y{Vgx7$3$A`?APt>_UFDSbcE_eWD>Tq9hec5VuD1$t{9G
ym35i&FuNC<PxnM7`{yn<3(rCI0drVPhD0n$Ahnm-3BcX|o@%KAiSDOA*7z5iVg4%s

literal 0
HcmV?d00001

diff --git a/static/activityicon.gif b/static/activityicon.gif
new file mode 100644
index 0000000000000000000000000000000000000000..c14d37553e505f4f01749f4f5635d7e10cb0298e
GIT binary patch
literal 529
zcmZ?wbhEHb6krfw_{6~Q|Nnmm28Kh24mCA30U2<h_@CR)H6+;CF~HSG&w!Z`D53aI
z%DE^tu_QG`p**uBLm@FMu_7lwF-0#kFD;)z@h1x>7f_WB$Ow?(49wCTyNpbdJYSxe
zeIv`}_0t~a#+1x?8LQUiyxzr$O}z}qt~-256BOkpr`($QJ8Z@`*Wj;n!Rq(rGvU(k
zFQC)0t)pvF*TH{tk0l0|mO?aSV$}e2(Vc$=r%oPGa6aSx;mrd!zR9hbAs`p|VRaEy
zz31w+KxZveyUo&f&%)>Cwb-23T3FRfLCp7Dz1QNkCY$7;CxZ7~<~_13kh`IR&HXUt
zuSJ@942>^dRxf*0kUD$mx}4isl|x+PW_UtCC?v`F|IKTjQ(9BO-ra=NHTc8R8Wd4r
F000zFq_F@1

literal 0
HcmV?d00001

diff --git a/static/css/bootstrap-theme.css b/static/css/bootstrap-theme.css
new file mode 100644
index 0000000000..a4069929bc
--- /dev/null
+++ b/static/css/bootstrap-theme.css
@@ -0,0 +1,347 @@
+/*!
+ * Bootstrap v3.1.1 (http://getbootstrap.com)
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ */
+
+.btn-default,
+.btn-primary,
+.btn-success,
+.btn-info,
+.btn-warning,
+.btn-danger {
+  text-shadow: 0 -1px 0 rgba(0, 0, 0, .2);
+  -webkit-box-shadow: inset 0 1px 0 rgba(255, 255, 255, .15), 0 1px 1px rgba(0, 0, 0, .075);
+          box-shadow: inset 0 1px 0 rgba(255, 255, 255, .15), 0 1px 1px rgba(0, 0, 0, .075);
+}
+.btn-default:active,
+.btn-primary:active,
+.btn-success:active,
+.btn-info:active,
+.btn-warning:active,
+.btn-danger:active,
+.btn-default.active,
+.btn-primary.active,
+.btn-success.active,
+.btn-info.active,
+.btn-warning.active,
+.btn-danger.active {
+  -webkit-box-shadow: inset 0 3px 5px rgba(0, 0, 0, .125);
+          box-shadow: inset 0 3px 5px rgba(0, 0, 0, .125);
+}
+.btn:active,
+.btn.active {
+  background-image: none;
+}
+.btn-default {
+  text-shadow: 0 1px 0 #fff;
+  background-image: -webkit-linear-gradient(top, #fff 0%, #e0e0e0 100%);
+  background-image:         linear-gradient(to bottom, #fff 0%, #e0e0e0 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffffff', endColorstr='#ffe0e0e0', GradientType=0);
+  filter: progid:DXImageTransform.Microsoft.gradient(enabled = false);
+  background-repeat: repeat-x;
+  border-color: #dbdbdb;
+  border-color: #ccc;
+}
+.btn-default:hover,
+.btn-default:focus {
+  background-color: #e0e0e0;
+  background-position: 0 -15px;
+}
+.btn-default:active,
+.btn-default.active {
+  background-color: #e0e0e0;
+  border-color: #dbdbdb;
+}
+.btn-primary {
+  background-image: -webkit-linear-gradient(top, #428bca 0%, #2d6ca2 100%);
+  background-image:         linear-gradient(to bottom, #428bca 0%, #2d6ca2 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ff428bca', endColorstr='#ff2d6ca2', GradientType=0);
+  filter: progid:DXImageTransform.Microsoft.gradient(enabled = false);
+  background-repeat: repeat-x;
+  border-color: #2b669a;
+}
+.btn-primary:hover,
+.btn-primary:focus {
+  background-color: #2d6ca2;
+  background-position: 0 -15px;
+}
+.btn-primary:active,
+.btn-primary.active {
+  background-color: #2d6ca2;
+  border-color: #2b669a;
+}
+.btn-success {
+  background-image: -webkit-linear-gradient(top, #5cb85c 0%, #419641 100%);
+  background-image:         linear-gradient(to bottom, #5cb85c 0%, #419641 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ff5cb85c', endColorstr='#ff419641', GradientType=0);
+  filter: progid:DXImageTransform.Microsoft.gradient(enabled = false);
+  background-repeat: repeat-x;
+  border-color: #3e8f3e;
+}
+.btn-success:hover,
+.btn-success:focus {
+  background-color: #419641;
+  background-position: 0 -15px;
+}
+.btn-success:active,
+.btn-success.active {
+  background-color: #419641;
+  border-color: #3e8f3e;
+}
+.btn-info {
+  background-image: -webkit-linear-gradient(top, #5bc0de 0%, #2aabd2 100%);
+  background-image:         linear-gradient(to bottom, #5bc0de 0%, #2aabd2 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ff5bc0de', endColorstr='#ff2aabd2', GradientType=0);
+  filter: progid:DXImageTransform.Microsoft.gradient(enabled = false);
+  background-repeat: repeat-x;
+  border-color: #28a4c9;
+}
+.btn-info:hover,
+.btn-info:focus {
+  background-color: #2aabd2;
+  background-position: 0 -15px;
+}
+.btn-info:active,
+.btn-info.active {
+  background-color: #2aabd2;
+  border-color: #28a4c9;
+}
+.btn-warning {
+  background-image: -webkit-linear-gradient(top, #f0ad4e 0%, #eb9316 100%);
+  background-image:         linear-gradient(to bottom, #f0ad4e 0%, #eb9316 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#fff0ad4e', endColorstr='#ffeb9316', GradientType=0);
+  filter: progid:DXImageTransform.Microsoft.gradient(enabled = false);
+  background-repeat: repeat-x;
+  border-color: #e38d13;
+}
+.btn-warning:hover,
+.btn-warning:focus {
+  background-color: #eb9316;
+  background-position: 0 -15px;
+}
+.btn-warning:active,
+.btn-warning.active {
+  background-color: #eb9316;
+  border-color: #e38d13;
+}
+.btn-danger {
+  background-image: -webkit-linear-gradient(top, #d9534f 0%, #c12e2a 100%);
+  background-image:         linear-gradient(to bottom, #d9534f 0%, #c12e2a 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffd9534f', endColorstr='#ffc12e2a', GradientType=0);
+  filter: progid:DXImageTransform.Microsoft.gradient(enabled = false);
+  background-repeat: repeat-x;
+  border-color: #b92c28;
+}
+.btn-danger:hover,
+.btn-danger:focus {
+  background-color: #c12e2a;
+  background-position: 0 -15px;
+}
+.btn-danger:active,
+.btn-danger.active {
+  background-color: #c12e2a;
+  border-color: #b92c28;
+}
+.thumbnail,
+.img-thumbnail {
+  -webkit-box-shadow: 0 1px 2px rgba(0, 0, 0, .075);
+          box-shadow: 0 1px 2px rgba(0, 0, 0, .075);
+}
+.dropdown-menu > li > a:hover,
+.dropdown-menu > li > a:focus {
+  background-color: #e8e8e8;
+  background-image: -webkit-linear-gradient(top, #f5f5f5 0%, #e8e8e8 100%);
+  background-image:         linear-gradient(to bottom, #f5f5f5 0%, #e8e8e8 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#fff5f5f5', endColorstr='#ffe8e8e8', GradientType=0);
+  background-repeat: repeat-x;
+}
+.dropdown-menu > .active > a,
+.dropdown-menu > .active > a:hover,
+.dropdown-menu > .active > a:focus {
+  background-color: #357ebd;
+  background-image: -webkit-linear-gradient(top, #428bca 0%, #357ebd 100%);
+  background-image:         linear-gradient(to bottom, #428bca 0%, #357ebd 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ff428bca', endColorstr='#ff357ebd', GradientType=0);
+  background-repeat: repeat-x;
+}
+.navbar-default {
+  background-image: -webkit-linear-gradient(top, #fff 0%, #f8f8f8 100%);
+  background-image:         linear-gradient(to bottom, #fff 0%, #f8f8f8 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffffff', endColorstr='#fff8f8f8', GradientType=0);
+  filter: progid:DXImageTransform.Microsoft.gradient(enabled = false);
+  background-repeat: repeat-x;
+  border-radius: 4px;
+  -webkit-box-shadow: inset 0 1px 0 rgba(255, 255, 255, .15), 0 1px 5px rgba(0, 0, 0, .075);
+          box-shadow: inset 0 1px 0 rgba(255, 255, 255, .15), 0 1px 5px rgba(0, 0, 0, .075);
+}
+.navbar-default .navbar-nav > .active > a {
+  background-image: -webkit-linear-gradient(top, #ebebeb 0%, #f3f3f3 100%);
+  background-image:         linear-gradient(to bottom, #ebebeb 0%, #f3f3f3 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffebebeb', endColorstr='#fff3f3f3', GradientType=0);
+  background-repeat: repeat-x;
+  -webkit-box-shadow: inset 0 3px 9px rgba(0, 0, 0, .075);
+          box-shadow: inset 0 3px 9px rgba(0, 0, 0, .075);
+}
+.navbar-brand,
+.navbar-nav > li > a {
+  text-shadow: 0 1px 0 rgba(255, 255, 255, .25);
+}
+.navbar-inverse {
+  background-image: -webkit-linear-gradient(top, #3c3c3c 0%, #222 100%);
+  background-image:         linear-gradient(to bottom, #3c3c3c 0%, #222 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ff3c3c3c', endColorstr='#ff222222', GradientType=0);
+  filter: progid:DXImageTransform.Microsoft.gradient(enabled = false);
+  background-repeat: repeat-x;
+}
+.navbar-inverse .navbar-nav > .active > a {
+  background-image: -webkit-linear-gradient(top, #222 0%, #282828 100%);
+  background-image:         linear-gradient(to bottom, #222 0%, #282828 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ff222222', endColorstr='#ff282828', GradientType=0);
+  background-repeat: repeat-x;
+  -webkit-box-shadow: inset 0 3px 9px rgba(0, 0, 0, .25);
+          box-shadow: inset 0 3px 9px rgba(0, 0, 0, .25);
+}
+.navbar-inverse .navbar-brand,
+.navbar-inverse .navbar-nav > li > a {
+  text-shadow: 0 -1px 0 rgba(0, 0, 0, .25);
+}
+.navbar-static-top,
+.navbar-fixed-top,
+.navbar-fixed-bottom {
+  border-radius: 0;
+}
+.alert {
+  text-shadow: 0 1px 0 rgba(255, 255, 255, .2);
+  -webkit-box-shadow: inset 0 1px 0 rgba(255, 255, 255, .25), 0 1px 2px rgba(0, 0, 0, .05);
+          box-shadow: inset 0 1px 0 rgba(255, 255, 255, .25), 0 1px 2px rgba(0, 0, 0, .05);
+}
+.alert-success {
+  background-image: -webkit-linear-gradient(top, #dff0d8 0%, #c8e5bc 100%);
+  background-image:         linear-gradient(to bottom, #dff0d8 0%, #c8e5bc 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffdff0d8', endColorstr='#ffc8e5bc', GradientType=0);
+  background-repeat: repeat-x;
+  border-color: #b2dba1;
+}
+.alert-info {
+  background-image: -webkit-linear-gradient(top, #d9edf7 0%, #b9def0 100%);
+  background-image:         linear-gradient(to bottom, #d9edf7 0%, #b9def0 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffd9edf7', endColorstr='#ffb9def0', GradientType=0);
+  background-repeat: repeat-x;
+  border-color: #9acfea;
+}
+.alert-warning {
+  background-image: -webkit-linear-gradient(top, #fcf8e3 0%, #f8efc0 100%);
+  background-image:         linear-gradient(to bottom, #fcf8e3 0%, #f8efc0 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#fffcf8e3', endColorstr='#fff8efc0', GradientType=0);
+  background-repeat: repeat-x;
+  border-color: #f5e79e;
+}
+.alert-danger {
+  background-image: -webkit-linear-gradient(top, #f2dede 0%, #e7c3c3 100%);
+  background-image:         linear-gradient(to bottom, #f2dede 0%, #e7c3c3 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#fff2dede', endColorstr='#ffe7c3c3', GradientType=0);
+  background-repeat: repeat-x;
+  border-color: #dca7a7;
+}
+.progress {
+  background-image: -webkit-linear-gradient(top, #ebebeb 0%, #f5f5f5 100%);
+  background-image:         linear-gradient(to bottom, #ebebeb 0%, #f5f5f5 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffebebeb', endColorstr='#fff5f5f5', GradientType=0);
+  background-repeat: repeat-x;
+}
+.progress-bar {
+  background-image: -webkit-linear-gradient(top, #428bca 0%, #3071a9 100%);
+  background-image:         linear-gradient(to bottom, #428bca 0%, #3071a9 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ff428bca', endColorstr='#ff3071a9', GradientType=0);
+  background-repeat: repeat-x;
+}
+.progress-bar-success {
+  background-image: -webkit-linear-gradient(top, #5cb85c 0%, #449d44 100%);
+  background-image:         linear-gradient(to bottom, #5cb85c 0%, #449d44 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ff5cb85c', endColorstr='#ff449d44', GradientType=0);
+  background-repeat: repeat-x;
+}
+.progress-bar-info {
+  background-image: -webkit-linear-gradient(top, #5bc0de 0%, #31b0d5 100%);
+  background-image:         linear-gradient(to bottom, #5bc0de 0%, #31b0d5 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ff5bc0de', endColorstr='#ff31b0d5', GradientType=0);
+  background-repeat: repeat-x;
+}
+.progress-bar-warning {
+  background-image: -webkit-linear-gradient(top, #f0ad4e 0%, #ec971f 100%);
+  background-image:         linear-gradient(to bottom, #f0ad4e 0%, #ec971f 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#fff0ad4e', endColorstr='#ffec971f', GradientType=0);
+  background-repeat: repeat-x;
+}
+.progress-bar-danger {
+  background-image: -webkit-linear-gradient(top, #d9534f 0%, #c9302c 100%);
+  background-image:         linear-gradient(to bottom, #d9534f 0%, #c9302c 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffd9534f', endColorstr='#ffc9302c', GradientType=0);
+  background-repeat: repeat-x;
+}
+.list-group {
+  border-radius: 4px;
+  -webkit-box-shadow: 0 1px 2px rgba(0, 0, 0, .075);
+          box-shadow: 0 1px 2px rgba(0, 0, 0, .075);
+}
+.list-group-item.active,
+.list-group-item.active:hover,
+.list-group-item.active:focus {
+  text-shadow: 0 -1px 0 #3071a9;
+  background-image: -webkit-linear-gradient(top, #428bca 0%, #3278b3 100%);
+  background-image:         linear-gradient(to bottom, #428bca 0%, #3278b3 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ff428bca', endColorstr='#ff3278b3', GradientType=0);
+  background-repeat: repeat-x;
+  border-color: #3278b3;
+}
+.panel {
+  -webkit-box-shadow: 0 1px 2px rgba(0, 0, 0, .05);
+          box-shadow: 0 1px 2px rgba(0, 0, 0, .05);
+}
+.panel-default > .panel-heading {
+  background-image: -webkit-linear-gradient(top, #f5f5f5 0%, #e8e8e8 100%);
+  background-image:         linear-gradient(to bottom, #f5f5f5 0%, #e8e8e8 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#fff5f5f5', endColorstr='#ffe8e8e8', GradientType=0);
+  background-repeat: repeat-x;
+}
+.panel-primary > .panel-heading {
+  background-image: -webkit-linear-gradient(top, #428bca 0%, #357ebd 100%);
+  background-image:         linear-gradient(to bottom, #428bca 0%, #357ebd 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ff428bca', endColorstr='#ff357ebd', GradientType=0);
+  background-repeat: repeat-x;
+}
+.panel-success > .panel-heading {
+  background-image: -webkit-linear-gradient(top, #dff0d8 0%, #d0e9c6 100%);
+  background-image:         linear-gradient(to bottom, #dff0d8 0%, #d0e9c6 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffdff0d8', endColorstr='#ffd0e9c6', GradientType=0);
+  background-repeat: repeat-x;
+}
+.panel-info > .panel-heading {
+  background-image: -webkit-linear-gradient(top, #d9edf7 0%, #c4e3f3 100%);
+  background-image:         linear-gradient(to bottom, #d9edf7 0%, #c4e3f3 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffd9edf7', endColorstr='#ffc4e3f3', GradientType=0);
+  background-repeat: repeat-x;
+}
+.panel-warning > .panel-heading {
+  background-image: -webkit-linear-gradient(top, #fcf8e3 0%, #faf2cc 100%);
+  background-image:         linear-gradient(to bottom, #fcf8e3 0%, #faf2cc 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#fffcf8e3', endColorstr='#fffaf2cc', GradientType=0);
+  background-repeat: repeat-x;
+}
+.panel-danger > .panel-heading {
+  background-image: -webkit-linear-gradient(top, #f2dede 0%, #ebcccc 100%);
+  background-image:         linear-gradient(to bottom, #f2dede 0%, #ebcccc 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#fff2dede', endColorstr='#ffebcccc', GradientType=0);
+  background-repeat: repeat-x;
+}
+.well {
+  background-image: -webkit-linear-gradient(top, #e8e8e8 0%, #f5f5f5 100%);
+  background-image:         linear-gradient(to bottom, #e8e8e8 0%, #f5f5f5 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffe8e8e8', endColorstr='#fff5f5f5', GradientType=0);
+  background-repeat: repeat-x;
+  border-color: #dcdcdc;
+  -webkit-box-shadow: inset 0 1px 3px rgba(0, 0, 0, .05), 0 1px 0 rgba(255, 255, 255, .1);
+          box-shadow: inset 0 1px 3px rgba(0, 0, 0, .05), 0 1px 0 rgba(255, 255, 255, .1);
+}
+/*# sourceMappingURL=bootstrap-theme.css.map */
diff --git a/static/css/bootstrap.css b/static/css/bootstrap.css
new file mode 100644
index 0000000000..7f36651961
--- /dev/null
+++ b/static/css/bootstrap.css
@@ -0,0 +1,5785 @@
+/*!
+ * Bootstrap v3.1.1 (http://getbootstrap.com)
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ */
+
+/*! normalize.css v3.0.0 | MIT License | git.io/normalize */
+html {
+  font-family: sans-serif;
+  -webkit-text-size-adjust: 100%;
+      -ms-text-size-adjust: 100%;
+}
+body {
+  margin: 0;
+}
+article,
+aside,
+details,
+figcaption,
+figure,
+footer,
+header,
+hgroup,
+main,
+nav,
+section,
+summary {
+  display: block;
+}
+audio,
+canvas,
+progress,
+video {
+  display: inline-block;
+  vertical-align: baseline;
+}
+audio:not([controls]) {
+  display: none;
+  height: 0;
+}
+[hidden],
+template {
+  display: none;
+}
+a {
+  background: transparent;
+}
+a:active,
+a:hover {
+  outline: 0;
+}
+abbr[title] {
+  border-bottom: 1px dotted;
+}
+b,
+strong {
+  font-weight: bold;
+}
+dfn {
+  font-style: italic;
+}
+h1 {
+  margin: .67em 0;
+  font-size: 2em;
+}
+mark {
+  color: #000;
+  background: #ff0;
+}
+small {
+  font-size: 80%;
+}
+sub,
+sup {
+  position: relative;
+  font-size: 75%;
+  line-height: 0;
+  vertical-align: baseline;
+}
+sup {
+  top: -.5em;
+}
+sub {
+  bottom: -.25em;
+}
+img {
+  border: 0;
+}
+svg:not(:root) {
+  overflow: hidden;
+}
+figure {
+  margin: 1em 40px;
+}
+hr {
+  height: 0;
+  -moz-box-sizing: content-box;
+       box-sizing: content-box;
+}
+pre {
+  overflow: auto;
+}
+code,
+kbd,
+pre,
+samp {
+  font-family: monospace, monospace;
+  font-size: 1em;
+}
+button,
+input,
+optgroup,
+select,
+textarea {
+  margin: 0;
+  font: inherit;
+  color: inherit;
+}
+button {
+  overflow: visible;
+}
+button,
+select {
+  text-transform: none;
+}
+button,
+html input[type="button"],
+input[type="reset"],
+input[type="submit"] {
+  -webkit-appearance: button;
+  cursor: pointer;
+}
+button[disabled],
+html input[disabled] {
+  cursor: default;
+}
+button::-moz-focus-inner,
+input::-moz-focus-inner {
+  padding: 0;
+  border: 0;
+}
+input {
+  line-height: normal;
+}
+input[type="checkbox"],
+input[type="radio"] {
+  box-sizing: border-box;
+  padding: 0;
+}
+input[type="number"]::-webkit-inner-spin-button,
+input[type="number"]::-webkit-outer-spin-button {
+  height: auto;
+}
+input[type="search"] {
+  -webkit-box-sizing: content-box;
+     -moz-box-sizing: content-box;
+          box-sizing: content-box;
+  -webkit-appearance: textfield;
+}
+input[type="search"]::-webkit-search-cancel-button,
+input[type="search"]::-webkit-search-decoration {
+  -webkit-appearance: none;
+}
+fieldset {
+  padding: .35em .625em .75em;
+  margin: 0 2px;
+  border: 1px solid #c0c0c0;
+}
+legend {
+  padding: 0;
+  border: 0;
+}
+textarea {
+  overflow: auto;
+}
+optgroup {
+  font-weight: bold;
+}
+table {
+  border-spacing: 0;
+  border-collapse: collapse;
+}
+td,
+th {
+  padding: 0;
+}
+@media print {
+  * {
+    color: #000 !important;
+    text-shadow: none !important;
+    background: transparent !important;
+    box-shadow: none !important;
+  }
+  a,
+  a:visited {
+    text-decoration: underline;
+  }
+  a[href]:after {
+    content: " (" attr(href) ")";
+  }
+  abbr[title]:after {
+    content: " (" attr(title) ")";
+  }
+  a[href^="javascript:"]:after,
+  a[href^="#"]:after {
+    content: "";
+  }
+  pre,
+  blockquote {
+    border: 1px solid #999;
+
+    page-break-inside: avoid;
+  }
+  thead {
+    display: table-header-group;
+  }
+  tr,
+  img {
+    page-break-inside: avoid;
+  }
+  img {
+    max-width: 100% !important;
+  }
+  p,
+  h2,
+  h3 {
+    orphans: 3;
+    widows: 3;
+  }
+  h2,
+  h3 {
+    page-break-after: avoid;
+  }
+  select {
+    background: #fff !important;
+  }
+  .navbar {
+    display: none;
+  }
+  .table td,
+  .table th {
+    background-color: #fff !important;
+  }
+  .btn > .caret,
+  .dropup > .btn > .caret {
+    border-top-color: #000 !important;
+  }
+  .label {
+    border: 1px solid #000;
+  }
+  .table {
+    border-collapse: collapse !important;
+  }
+  .table-bordered th,
+  .table-bordered td {
+    border: 1px solid #ddd !important;
+  }
+}
+* {
+  -webkit-box-sizing: border-box;
+     -moz-box-sizing: border-box;
+          box-sizing: border-box;
+}
+*:before,
+*:after {
+  -webkit-box-sizing: border-box;
+     -moz-box-sizing: border-box;
+          box-sizing: border-box;
+}
+html {
+  font-size: 62.5%;
+
+  -webkit-tap-highlight-color: rgba(0, 0, 0, 0);
+}
+body {
+  font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
+  font-size: 14px;
+  line-height: 1.42857143;
+  color: #333;
+  background-color: #fff;
+}
+input,
+button,
+select,
+textarea {
+  font-family: inherit;
+  font-size: inherit;
+  line-height: inherit;
+}
+a {
+  color: #428bca;
+  text-decoration: none;
+}
+a:hover,
+a:focus {
+  color: #2a6496;
+  text-decoration: underline;
+}
+a:focus {
+  outline: thin dotted;
+  outline: 5px auto -webkit-focus-ring-color;
+  outline-offset: -2px;
+}
+figure {
+  margin: 0;
+}
+img {
+  vertical-align: middle;
+}
+.img-responsive,
+.thumbnail > img,
+.thumbnail a > img,
+.carousel-inner > .item > img,
+.carousel-inner > .item > a > img {
+  display: block;
+  max-width: 100%;
+  height: auto;
+}
+.img-rounded {
+  border-radius: 6px;
+}
+.img-thumbnail {
+  display: inline-block;
+  max-width: 100%;
+  height: auto;
+  padding: 4px;
+  line-height: 1.42857143;
+  background-color: #fff;
+  border: 1px solid #ddd;
+  border-radius: 4px;
+  -webkit-transition: all .2s ease-in-out;
+          transition: all .2s ease-in-out;
+}
+.img-circle {
+  border-radius: 50%;
+}
+hr {
+  margin-top: 20px;
+  margin-bottom: 20px;
+  border: 0;
+  border-top: 1px solid #eee;
+}
+.sr-only {
+  position: absolute;
+  width: 1px;
+  height: 1px;
+  padding: 0;
+  margin: -1px;
+  overflow: hidden;
+  clip: rect(0, 0, 0, 0);
+  border: 0;
+}
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+.h1,
+.h2,
+.h3,
+.h4,
+.h5,
+.h6 {
+  font-family: inherit;
+  font-weight: 500;
+  line-height: 1.1;
+  color: inherit;
+}
+h1 small,
+h2 small,
+h3 small,
+h4 small,
+h5 small,
+h6 small,
+.h1 small,
+.h2 small,
+.h3 small,
+.h4 small,
+.h5 small,
+.h6 small,
+h1 .small,
+h2 .small,
+h3 .small,
+h4 .small,
+h5 .small,
+h6 .small,
+.h1 .small,
+.h2 .small,
+.h3 .small,
+.h4 .small,
+.h5 .small,
+.h6 .small {
+  font-weight: normal;
+  line-height: 1;
+  color: #999;
+}
+h1,
+.h1,
+h2,
+.h2,
+h3,
+.h3 {
+  margin-top: 20px;
+  margin-bottom: 10px;
+}
+h1 small,
+.h1 small,
+h2 small,
+.h2 small,
+h3 small,
+.h3 small,
+h1 .small,
+.h1 .small,
+h2 .small,
+.h2 .small,
+h3 .small,
+.h3 .small {
+  font-size: 65%;
+}
+h4,
+.h4,
+h5,
+.h5,
+h6,
+.h6 {
+  margin-top: 10px;
+  margin-bottom: 10px;
+}
+h4 small,
+.h4 small,
+h5 small,
+.h5 small,
+h6 small,
+.h6 small,
+h4 .small,
+.h4 .small,
+h5 .small,
+.h5 .small,
+h6 .small,
+.h6 .small {
+  font-size: 75%;
+}
+h1,
+.h1 {
+  font-size: 36px;
+}
+h2,
+.h2 {
+  font-size: 30px;
+}
+h3,
+.h3 {
+  font-size: 24px;
+}
+h4,
+.h4 {
+  font-size: 18px;
+}
+h5,
+.h5 {
+  font-size: 14px;
+}
+h6,
+.h6 {
+  font-size: 12px;
+}
+p {
+  margin: 0 0 10px;
+}
+.lead {
+  margin-bottom: 20px;
+  font-size: 16px;
+  font-weight: 200;
+  line-height: 1.4;
+}
+@media (min-width: 768px) {
+  .lead {
+    font-size: 21px;
+  }
+}
+small,
+.small {
+  font-size: 85%;
+}
+cite {
+  font-style: normal;
+}
+.text-left {
+  text-align: left;
+}
+.text-right {
+  text-align: right;
+}
+.text-center {
+  text-align: center;
+}
+.text-justify {
+  text-align: justify;
+}
+.text-muted {
+  color: #999;
+}
+.text-primary {
+  color: #428bca;
+}
+a.text-primary:hover {
+  color: #3071a9;
+}
+.text-success {
+  color: #3c763d;
+}
+a.text-success:hover {
+  color: #2b542c;
+}
+.text-info {
+  color: #31708f;
+}
+a.text-info:hover {
+  color: #245269;
+}
+.text-warning {
+  color: #8a6d3b;
+}
+a.text-warning:hover {
+  color: #66512c;
+}
+.text-danger {
+  color: #a94442;
+}
+a.text-danger:hover {
+  color: #843534;
+}
+.bg-primary {
+  color: #fff;
+  background-color: #428bca;
+}
+a.bg-primary:hover {
+  background-color: #3071a9;
+}
+.bg-success {
+  background-color: #dff0d8;
+}
+a.bg-success:hover {
+  background-color: #c1e2b3;
+}
+.bg-info {
+  background-color: #d9edf7;
+}
+a.bg-info:hover {
+  background-color: #afd9ee;
+}
+.bg-warning {
+  background-color: #fcf8e3;
+}
+a.bg-warning:hover {
+  background-color: #f7ecb5;
+}
+.bg-danger {
+  background-color: #f2dede;
+}
+a.bg-danger:hover {
+  background-color: #e4b9b9;
+}
+.page-header {
+  padding-bottom: 9px;
+  margin: 40px 0 20px;
+  border-bottom: 1px solid #eee;
+}
+ul,
+ol {
+  margin-top: 0;
+  margin-bottom: 10px;
+}
+ul ul,
+ol ul,
+ul ol,
+ol ol {
+  margin-bottom: 0;
+}
+.list-unstyled {
+  padding-left: 0;
+  list-style: none;
+}
+.list-inline {
+  padding-left: 0;
+  margin-left: -5px;
+  list-style: none;
+}
+.list-inline > li {
+  display: inline-block;
+  padding-right: 5px;
+  padding-left: 5px;
+}
+dl {
+  margin-top: 0;
+  margin-bottom: 20px;
+}
+dt,
+dd {
+  line-height: 1.42857143;
+}
+dt {
+  font-weight: bold;
+}
+dd {
+  margin-left: 0;
+}
+@media (min-width: 768px) {
+  .dl-horizontal dt {
+    float: left;
+    width: 160px;
+    overflow: hidden;
+    clear: left;
+    text-align: right;
+    text-overflow: ellipsis;
+    white-space: nowrap;
+  }
+  .dl-horizontal dd {
+    margin-left: 180px;
+  }
+}
+abbr[title],
+abbr[data-original-title] {
+  cursor: help;
+  border-bottom: 1px dotted #999;
+}
+.initialism {
+  font-size: 90%;
+  text-transform: uppercase;
+}
+blockquote {
+  padding: 10px 20px;
+  margin: 0 0 20px;
+  font-size: 17.5px;
+  border-left: 5px solid #eee;
+}
+blockquote p:last-child,
+blockquote ul:last-child,
+blockquote ol:last-child {
+  margin-bottom: 0;
+}
+blockquote footer,
+blockquote small,
+blockquote .small {
+  display: block;
+  font-size: 80%;
+  line-height: 1.42857143;
+  color: #999;
+}
+blockquote footer:before,
+blockquote small:before,
+blockquote .small:before {
+  content: '\2014 \00A0';
+}
+.blockquote-reverse,
+blockquote.pull-right {
+  padding-right: 15px;
+  padding-left: 0;
+  text-align: right;
+  border-right: 5px solid #eee;
+  border-left: 0;
+}
+.blockquote-reverse footer:before,
+blockquote.pull-right footer:before,
+.blockquote-reverse small:before,
+blockquote.pull-right small:before,
+.blockquote-reverse .small:before,
+blockquote.pull-right .small:before {
+  content: '';
+}
+.blockquote-reverse footer:after,
+blockquote.pull-right footer:after,
+.blockquote-reverse small:after,
+blockquote.pull-right small:after,
+.blockquote-reverse .small:after,
+blockquote.pull-right .small:after {
+  content: '\00A0 \2014';
+}
+blockquote:before,
+blockquote:after {
+  content: "";
+}
+address {
+  margin-bottom: 20px;
+  font-style: normal;
+  line-height: 1.42857143;
+}
+code,
+kbd,
+pre,
+samp {
+  font-family: Menlo, Monaco, Consolas, "Courier New", monospace;
+}
+code {
+  padding: 2px 4px;
+  font-size: 90%;
+  color: #c7254e;
+  white-space: nowrap;
+  background-color: #f9f2f4;
+  border-radius: 4px;
+}
+kbd {
+  padding: 2px 4px;
+  font-size: 90%;
+  color: #fff;
+  background-color: #333;
+  border-radius: 3px;
+  box-shadow: inset 0 -1px 0 rgba(0, 0, 0, .25);
+}
+pre {
+  display: block;
+  padding: 9.5px;
+  margin: 0 0 10px;
+  font-size: 13px;
+  line-height: 1.42857143;
+  color: #333;
+  word-break: break-all;
+  word-wrap: break-word;
+  background-color: #f5f5f5;
+  border: 1px solid #ccc;
+  border-radius: 4px;
+}
+pre code {
+  padding: 0;
+  font-size: inherit;
+  color: inherit;
+  white-space: pre-wrap;
+  background-color: transparent;
+  border-radius: 0;
+}
+.pre-scrollable {
+  max-height: 340px;
+  overflow-y: scroll;
+}
+.container {
+  padding-right: 15px;
+  padding-left: 15px;
+  margin-right: auto;
+  margin-left: auto;
+}
+@media (min-width: 768px) {
+  .container {
+    width: 750px;
+  }
+}
+@media (min-width: 992px) {
+  .container {
+    width: 970px;
+  }
+}
+@media (min-width: 1200px) {
+  .container {
+    width: 1170px;
+  }
+}
+.container-fluid {
+  padding-right: 15px;
+  padding-left: 15px;
+  margin-right: auto;
+  margin-left: auto;
+}
+.row {
+  margin-right: -15px;
+  margin-left: -15px;
+}
+.col-xs-1, .col-sm-1, .col-md-1, .col-lg-1, .col-xs-2, .col-sm-2, .col-md-2, .col-lg-2, .col-xs-3, .col-sm-3, .col-md-3, .col-lg-3, .col-xs-4, .col-sm-4, .col-md-4, .col-lg-4, .col-xs-5, .col-sm-5, .col-md-5, .col-lg-5, .col-xs-6, .col-sm-6, .col-md-6, .col-lg-6, .col-xs-7, .col-sm-7, .col-md-7, .col-lg-7, .col-xs-8, .col-sm-8, .col-md-8, .col-lg-8, .col-xs-9, .col-sm-9, .col-md-9, .col-lg-9, .col-xs-10, .col-sm-10, .col-md-10, .col-lg-10, .col-xs-11, .col-sm-11, .col-md-11, .col-lg-11, .col-xs-12, .col-sm-12, .col-md-12, .col-lg-12 {
+  position: relative;
+  min-height: 1px;
+  padding-right: 15px;
+  padding-left: 15px;
+}
+.col-xs-1, .col-xs-2, .col-xs-3, .col-xs-4, .col-xs-5, .col-xs-6, .col-xs-7, .col-xs-8, .col-xs-9, .col-xs-10, .col-xs-11, .col-xs-12 {
+  float: left;
+}
+.col-xs-12 {
+  width: 100%;
+}
+.col-xs-11 {
+  width: 91.66666667%;
+}
+.col-xs-10 {
+  width: 83.33333333%;
+}
+.col-xs-9 {
+  width: 75%;
+}
+.col-xs-8 {
+  width: 66.66666667%;
+}
+.col-xs-7 {
+  width: 58.33333333%;
+}
+.col-xs-6 {
+  width: 50%;
+}
+.col-xs-5 {
+  width: 41.66666667%;
+}
+.col-xs-4 {
+  width: 33.33333333%;
+}
+.col-xs-3 {
+  width: 25%;
+}
+.col-xs-2 {
+  width: 16.66666667%;
+}
+.col-xs-1 {
+  width: 8.33333333%;
+}
+.col-xs-pull-12 {
+  right: 100%;
+}
+.col-xs-pull-11 {
+  right: 91.66666667%;
+}
+.col-xs-pull-10 {
+  right: 83.33333333%;
+}
+.col-xs-pull-9 {
+  right: 75%;
+}
+.col-xs-pull-8 {
+  right: 66.66666667%;
+}
+.col-xs-pull-7 {
+  right: 58.33333333%;
+}
+.col-xs-pull-6 {
+  right: 50%;
+}
+.col-xs-pull-5 {
+  right: 41.66666667%;
+}
+.col-xs-pull-4 {
+  right: 33.33333333%;
+}
+.col-xs-pull-3 {
+  right: 25%;
+}
+.col-xs-pull-2 {
+  right: 16.66666667%;
+}
+.col-xs-pull-1 {
+  right: 8.33333333%;
+}
+.col-xs-pull-0 {
+  right: 0;
+}
+.col-xs-push-12 {
+  left: 100%;
+}
+.col-xs-push-11 {
+  left: 91.66666667%;
+}
+.col-xs-push-10 {
+  left: 83.33333333%;
+}
+.col-xs-push-9 {
+  left: 75%;
+}
+.col-xs-push-8 {
+  left: 66.66666667%;
+}
+.col-xs-push-7 {
+  left: 58.33333333%;
+}
+.col-xs-push-6 {
+  left: 50%;
+}
+.col-xs-push-5 {
+  left: 41.66666667%;
+}
+.col-xs-push-4 {
+  left: 33.33333333%;
+}
+.col-xs-push-3 {
+  left: 25%;
+}
+.col-xs-push-2 {
+  left: 16.66666667%;
+}
+.col-xs-push-1 {
+  left: 8.33333333%;
+}
+.col-xs-push-0 {
+  left: 0;
+}
+.col-xs-offset-12 {
+  margin-left: 100%;
+}
+.col-xs-offset-11 {
+  margin-left: 91.66666667%;
+}
+.col-xs-offset-10 {
+  margin-left: 83.33333333%;
+}
+.col-xs-offset-9 {
+  margin-left: 75%;
+}
+.col-xs-offset-8 {
+  margin-left: 66.66666667%;
+}
+.col-xs-offset-7 {
+  margin-left: 58.33333333%;
+}
+.col-xs-offset-6 {
+  margin-left: 50%;
+}
+.col-xs-offset-5 {
+  margin-left: 41.66666667%;
+}
+.col-xs-offset-4 {
+  margin-left: 33.33333333%;
+}
+.col-xs-offset-3 {
+  margin-left: 25%;
+}
+.col-xs-offset-2 {
+  margin-left: 16.66666667%;
+}
+.col-xs-offset-1 {
+  margin-left: 8.33333333%;
+}
+.col-xs-offset-0 {
+  margin-left: 0;
+}
+@media (min-width: 768px) {
+  .col-sm-1, .col-sm-2, .col-sm-3, .col-sm-4, .col-sm-5, .col-sm-6, .col-sm-7, .col-sm-8, .col-sm-9, .col-sm-10, .col-sm-11, .col-sm-12 {
+    float: left;
+  }
+  .col-sm-12 {
+    width: 100%;
+  }
+  .col-sm-11 {
+    width: 91.66666667%;
+  }
+  .col-sm-10 {
+    width: 83.33333333%;
+  }
+  .col-sm-9 {
+    width: 75%;
+  }
+  .col-sm-8 {
+    width: 66.66666667%;
+  }
+  .col-sm-7 {
+    width: 58.33333333%;
+  }
+  .col-sm-6 {
+    width: 50%;
+  }
+  .col-sm-5 {
+    width: 41.66666667%;
+  }
+  .col-sm-4 {
+    width: 33.33333333%;
+  }
+  .col-sm-3 {
+    width: 25%;
+  }
+  .col-sm-2 {
+    width: 16.66666667%;
+  }
+  .col-sm-1 {
+    width: 8.33333333%;
+  }
+  .col-sm-pull-12 {
+    right: 100%;
+  }
+  .col-sm-pull-11 {
+    right: 91.66666667%;
+  }
+  .col-sm-pull-10 {
+    right: 83.33333333%;
+  }
+  .col-sm-pull-9 {
+    right: 75%;
+  }
+  .col-sm-pull-8 {
+    right: 66.66666667%;
+  }
+  .col-sm-pull-7 {
+    right: 58.33333333%;
+  }
+  .col-sm-pull-6 {
+    right: 50%;
+  }
+  .col-sm-pull-5 {
+    right: 41.66666667%;
+  }
+  .col-sm-pull-4 {
+    right: 33.33333333%;
+  }
+  .col-sm-pull-3 {
+    right: 25%;
+  }
+  .col-sm-pull-2 {
+    right: 16.66666667%;
+  }
+  .col-sm-pull-1 {
+    right: 8.33333333%;
+  }
+  .col-sm-pull-0 {
+    right: 0;
+  }
+  .col-sm-push-12 {
+    left: 100%;
+  }
+  .col-sm-push-11 {
+    left: 91.66666667%;
+  }
+  .col-sm-push-10 {
+    left: 83.33333333%;
+  }
+  .col-sm-push-9 {
+    left: 75%;
+  }
+  .col-sm-push-8 {
+    left: 66.66666667%;
+  }
+  .col-sm-push-7 {
+    left: 58.33333333%;
+  }
+  .col-sm-push-6 {
+    left: 50%;
+  }
+  .col-sm-push-5 {
+    left: 41.66666667%;
+  }
+  .col-sm-push-4 {
+    left: 33.33333333%;
+  }
+  .col-sm-push-3 {
+    left: 25%;
+  }
+  .col-sm-push-2 {
+    left: 16.66666667%;
+  }
+  .col-sm-push-1 {
+    left: 8.33333333%;
+  }
+  .col-sm-push-0 {
+    left: 0;
+  }
+  .col-sm-offset-12 {
+    margin-left: 100%;
+  }
+  .col-sm-offset-11 {
+    margin-left: 91.66666667%;
+  }
+  .col-sm-offset-10 {
+    margin-left: 83.33333333%;
+  }
+  .col-sm-offset-9 {
+    margin-left: 75%;
+  }
+  .col-sm-offset-8 {
+    margin-left: 66.66666667%;
+  }
+  .col-sm-offset-7 {
+    margin-left: 58.33333333%;
+  }
+  .col-sm-offset-6 {
+    margin-left: 50%;
+  }
+  .col-sm-offset-5 {
+    margin-left: 41.66666667%;
+  }
+  .col-sm-offset-4 {
+    margin-left: 33.33333333%;
+  }
+  .col-sm-offset-3 {
+    margin-left: 25%;
+  }
+  .col-sm-offset-2 {
+    margin-left: 16.66666667%;
+  }
+  .col-sm-offset-1 {
+    margin-left: 8.33333333%;
+  }
+  .col-sm-offset-0 {
+    margin-left: 0;
+  }
+}
+@media (min-width: 992px) {
+  .col-md-1, .col-md-2, .col-md-3, .col-md-4, .col-md-5, .col-md-6, .col-md-7, .col-md-8, .col-md-9, .col-md-10, .col-md-11, .col-md-12 {
+    float: left;
+  }
+  .col-md-12 {
+    width: 100%;
+  }
+  .col-md-11 {
+    width: 91.66666667%;
+  }
+  .col-md-10 {
+    width: 83.33333333%;
+  }
+  .col-md-9 {
+    width: 75%;
+  }
+  .col-md-8 {
+    width: 66.66666667%;
+  }
+  .col-md-7 {
+    width: 58.33333333%;
+  }
+  .col-md-6 {
+    width: 50%;
+  }
+  .col-md-5 {
+    width: 41.66666667%;
+  }
+  .col-md-4 {
+    width: 33.33333333%;
+  }
+  .col-md-3 {
+    width: 25%;
+  }
+  .col-md-2 {
+    width: 16.66666667%;
+  }
+  .col-md-1 {
+    width: 8.33333333%;
+  }
+  .col-md-pull-12 {
+    right: 100%;
+  }
+  .col-md-pull-11 {
+    right: 91.66666667%;
+  }
+  .col-md-pull-10 {
+    right: 83.33333333%;
+  }
+  .col-md-pull-9 {
+    right: 75%;
+  }
+  .col-md-pull-8 {
+    right: 66.66666667%;
+  }
+  .col-md-pull-7 {
+    right: 58.33333333%;
+  }
+  .col-md-pull-6 {
+    right: 50%;
+  }
+  .col-md-pull-5 {
+    right: 41.66666667%;
+  }
+  .col-md-pull-4 {
+    right: 33.33333333%;
+  }
+  .col-md-pull-3 {
+    right: 25%;
+  }
+  .col-md-pull-2 {
+    right: 16.66666667%;
+  }
+  .col-md-pull-1 {
+    right: 8.33333333%;
+  }
+  .col-md-pull-0 {
+    right: 0;
+  }
+  .col-md-push-12 {
+    left: 100%;
+  }
+  .col-md-push-11 {
+    left: 91.66666667%;
+  }
+  .col-md-push-10 {
+    left: 83.33333333%;
+  }
+  .col-md-push-9 {
+    left: 75%;
+  }
+  .col-md-push-8 {
+    left: 66.66666667%;
+  }
+  .col-md-push-7 {
+    left: 58.33333333%;
+  }
+  .col-md-push-6 {
+    left: 50%;
+  }
+  .col-md-push-5 {
+    left: 41.66666667%;
+  }
+  .col-md-push-4 {
+    left: 33.33333333%;
+  }
+  .col-md-push-3 {
+    left: 25%;
+  }
+  .col-md-push-2 {
+    left: 16.66666667%;
+  }
+  .col-md-push-1 {
+    left: 8.33333333%;
+  }
+  .col-md-push-0 {
+    left: 0;
+  }
+  .col-md-offset-12 {
+    margin-left: 100%;
+  }
+  .col-md-offset-11 {
+    margin-left: 91.66666667%;
+  }
+  .col-md-offset-10 {
+    margin-left: 83.33333333%;
+  }
+  .col-md-offset-9 {
+    margin-left: 75%;
+  }
+  .col-md-offset-8 {
+    margin-left: 66.66666667%;
+  }
+  .col-md-offset-7 {
+    margin-left: 58.33333333%;
+  }
+  .col-md-offset-6 {
+    margin-left: 50%;
+  }
+  .col-md-offset-5 {
+    margin-left: 41.66666667%;
+  }
+  .col-md-offset-4 {
+    margin-left: 33.33333333%;
+  }
+  .col-md-offset-3 {
+    margin-left: 25%;
+  }
+  .col-md-offset-2 {
+    margin-left: 16.66666667%;
+  }
+  .col-md-offset-1 {
+    margin-left: 8.33333333%;
+  }
+  .col-md-offset-0 {
+    margin-left: 0;
+  }
+}
+@media (min-width: 1200px) {
+  .col-lg-1, .col-lg-2, .col-lg-3, .col-lg-4, .col-lg-5, .col-lg-6, .col-lg-7, .col-lg-8, .col-lg-9, .col-lg-10, .col-lg-11, .col-lg-12 {
+    float: left;
+  }
+  .col-lg-12 {
+    width: 100%;
+  }
+  .col-lg-11 {
+    width: 91.66666667%;
+  }
+  .col-lg-10 {
+    width: 83.33333333%;
+  }
+  .col-lg-9 {
+    width: 75%;
+  }
+  .col-lg-8 {
+    width: 66.66666667%;
+  }
+  .col-lg-7 {
+    width: 58.33333333%;
+  }
+  .col-lg-6 {
+    width: 50%;
+  }
+  .col-lg-5 {
+    width: 41.66666667%;
+  }
+  .col-lg-4 {
+    width: 33.33333333%;
+  }
+  .col-lg-3 {
+    width: 25%;
+  }
+  .col-lg-2 {
+    width: 16.66666667%;
+  }
+  .col-lg-1 {
+    width: 8.33333333%;
+  }
+  .col-lg-pull-12 {
+    right: 100%;
+  }
+  .col-lg-pull-11 {
+    right: 91.66666667%;
+  }
+  .col-lg-pull-10 {
+    right: 83.33333333%;
+  }
+  .col-lg-pull-9 {
+    right: 75%;
+  }
+  .col-lg-pull-8 {
+    right: 66.66666667%;
+  }
+  .col-lg-pull-7 {
+    right: 58.33333333%;
+  }
+  .col-lg-pull-6 {
+    right: 50%;
+  }
+  .col-lg-pull-5 {
+    right: 41.66666667%;
+  }
+  .col-lg-pull-4 {
+    right: 33.33333333%;
+  }
+  .col-lg-pull-3 {
+    right: 25%;
+  }
+  .col-lg-pull-2 {
+    right: 16.66666667%;
+  }
+  .col-lg-pull-1 {
+    right: 8.33333333%;
+  }
+  .col-lg-pull-0 {
+    right: 0;
+  }
+  .col-lg-push-12 {
+    left: 100%;
+  }
+  .col-lg-push-11 {
+    left: 91.66666667%;
+  }
+  .col-lg-push-10 {
+    left: 83.33333333%;
+  }
+  .col-lg-push-9 {
+    left: 75%;
+  }
+  .col-lg-push-8 {
+    left: 66.66666667%;
+  }
+  .col-lg-push-7 {
+    left: 58.33333333%;
+  }
+  .col-lg-push-6 {
+    left: 50%;
+  }
+  .col-lg-push-5 {
+    left: 41.66666667%;
+  }
+  .col-lg-push-4 {
+    left: 33.33333333%;
+  }
+  .col-lg-push-3 {
+    left: 25%;
+  }
+  .col-lg-push-2 {
+    left: 16.66666667%;
+  }
+  .col-lg-push-1 {
+    left: 8.33333333%;
+  }
+  .col-lg-push-0 {
+    left: 0;
+  }
+  .col-lg-offset-12 {
+    margin-left: 100%;
+  }
+  .col-lg-offset-11 {
+    margin-left: 91.66666667%;
+  }
+  .col-lg-offset-10 {
+    margin-left: 83.33333333%;
+  }
+  .col-lg-offset-9 {
+    margin-left: 75%;
+  }
+  .col-lg-offset-8 {
+    margin-left: 66.66666667%;
+  }
+  .col-lg-offset-7 {
+    margin-left: 58.33333333%;
+  }
+  .col-lg-offset-6 {
+    margin-left: 50%;
+  }
+  .col-lg-offset-5 {
+    margin-left: 41.66666667%;
+  }
+  .col-lg-offset-4 {
+    margin-left: 33.33333333%;
+  }
+  .col-lg-offset-3 {
+    margin-left: 25%;
+  }
+  .col-lg-offset-2 {
+    margin-left: 16.66666667%;
+  }
+  .col-lg-offset-1 {
+    margin-left: 8.33333333%;
+  }
+  .col-lg-offset-0 {
+    margin-left: 0;
+  }
+}
+table {
+  max-width: 100%;
+  background-color: transparent;
+}
+th {
+  text-align: left;
+}
+.table {
+  width: 100%;
+  margin-bottom: 20px;
+}
+.table > thead > tr > th,
+.table > tbody > tr > th,
+.table > tfoot > tr > th,
+.table > thead > tr > td,
+.table > tbody > tr > td,
+.table > tfoot > tr > td {
+  padding: 8px;
+  line-height: 1.42857143;
+  vertical-align: top;
+  border-top: 1px solid #ddd;
+}
+.table > thead > tr > th {
+  vertical-align: bottom;
+  border-bottom: 2px solid #ddd;
+}
+.table > caption + thead > tr:first-child > th,
+.table > colgroup + thead > tr:first-child > th,
+.table > thead:first-child > tr:first-child > th,
+.table > caption + thead > tr:first-child > td,
+.table > colgroup + thead > tr:first-child > td,
+.table > thead:first-child > tr:first-child > td {
+  border-top: 0;
+}
+.table > tbody + tbody {
+  border-top: 2px solid #ddd;
+}
+.table .table {
+  background-color: #fff;
+}
+.table-condensed > thead > tr > th,
+.table-condensed > tbody > tr > th,
+.table-condensed > tfoot > tr > th,
+.table-condensed > thead > tr > td,
+.table-condensed > tbody > tr > td,
+.table-condensed > tfoot > tr > td {
+  padding: 5px;
+}
+.table-bordered {
+  border: 1px solid #ddd;
+}
+.table-bordered > thead > tr > th,
+.table-bordered > tbody > tr > th,
+.table-bordered > tfoot > tr > th,
+.table-bordered > thead > tr > td,
+.table-bordered > tbody > tr > td,
+.table-bordered > tfoot > tr > td {
+  border: 1px solid #ddd;
+}
+.table-bordered > thead > tr > th,
+.table-bordered > thead > tr > td {
+  border-bottom-width: 2px;
+}
+.table-striped > tbody > tr:nth-child(odd) > td,
+.table-striped > tbody > tr:nth-child(odd) > th {
+  background-color: #f9f9f9;
+}
+.table-hover > tbody > tr:hover > td,
+.table-hover > tbody > tr:hover > th {
+  background-color: #f5f5f5;
+}
+table col[class*="col-"] {
+  position: static;
+  display: table-column;
+  float: none;
+}
+table td[class*="col-"],
+table th[class*="col-"] {
+  position: static;
+  display: table-cell;
+  float: none;
+}
+.table > thead > tr > td.active,
+.table > tbody > tr > td.active,
+.table > tfoot > tr > td.active,
+.table > thead > tr > th.active,
+.table > tbody > tr > th.active,
+.table > tfoot > tr > th.active,
+.table > thead > tr.active > td,
+.table > tbody > tr.active > td,
+.table > tfoot > tr.active > td,
+.table > thead > tr.active > th,
+.table > tbody > tr.active > th,
+.table > tfoot > tr.active > th {
+  background-color: #f5f5f5;
+}
+.table-hover > tbody > tr > td.active:hover,
+.table-hover > tbody > tr > th.active:hover,
+.table-hover > tbody > tr.active:hover > td,
+.table-hover > tbody > tr.active:hover > th {
+  background-color: #e8e8e8;
+}
+.table > thead > tr > td.success,
+.table > tbody > tr > td.success,
+.table > tfoot > tr > td.success,
+.table > thead > tr > th.success,
+.table > tbody > tr > th.success,
+.table > tfoot > tr > th.success,
+.table > thead > tr.success > td,
+.table > tbody > tr.success > td,
+.table > tfoot > tr.success > td,
+.table > thead > tr.success > th,
+.table > tbody > tr.success > th,
+.table > tfoot > tr.success > th {
+  background-color: #dff0d8;
+}
+.table-hover > tbody > tr > td.success:hover,
+.table-hover > tbody > tr > th.success:hover,
+.table-hover > tbody > tr.success:hover > td,
+.table-hover > tbody > tr.success:hover > th {
+  background-color: #d0e9c6;
+}
+.table > thead > tr > td.info,
+.table > tbody > tr > td.info,
+.table > tfoot > tr > td.info,
+.table > thead > tr > th.info,
+.table > tbody > tr > th.info,
+.table > tfoot > tr > th.info,
+.table > thead > tr.info > td,
+.table > tbody > tr.info > td,
+.table > tfoot > tr.info > td,
+.table > thead > tr.info > th,
+.table > tbody > tr.info > th,
+.table > tfoot > tr.info > th {
+  background-color: #d9edf7;
+}
+.table-hover > tbody > tr > td.info:hover,
+.table-hover > tbody > tr > th.info:hover,
+.table-hover > tbody > tr.info:hover > td,
+.table-hover > tbody > tr.info:hover > th {
+  background-color: #c4e3f3;
+}
+.table > thead > tr > td.warning,
+.table > tbody > tr > td.warning,
+.table > tfoot > tr > td.warning,
+.table > thead > tr > th.warning,
+.table > tbody > tr > th.warning,
+.table > tfoot > tr > th.warning,
+.table > thead > tr.warning > td,
+.table > tbody > tr.warning > td,
+.table > tfoot > tr.warning > td,
+.table > thead > tr.warning > th,
+.table > tbody > tr.warning > th,
+.table > tfoot > tr.warning > th {
+  background-color: #fcf8e3;
+}
+.table-hover > tbody > tr > td.warning:hover,
+.table-hover > tbody > tr > th.warning:hover,
+.table-hover > tbody > tr.warning:hover > td,
+.table-hover > tbody > tr.warning:hover > th {
+  background-color: #faf2cc;
+}
+.table > thead > tr > td.danger,
+.table > tbody > tr > td.danger,
+.table > tfoot > tr > td.danger,
+.table > thead > tr > th.danger,
+.table > tbody > tr > th.danger,
+.table > tfoot > tr > th.danger,
+.table > thead > tr.danger > td,
+.table > tbody > tr.danger > td,
+.table > tfoot > tr.danger > td,
+.table > thead > tr.danger > th,
+.table > tbody > tr.danger > th,
+.table > tfoot > tr.danger > th {
+  background-color: #f2dede;
+}
+.table-hover > tbody > tr > td.danger:hover,
+.table-hover > tbody > tr > th.danger:hover,
+.table-hover > tbody > tr.danger:hover > td,
+.table-hover > tbody > tr.danger:hover > th {
+  background-color: #ebcccc;
+}
+@media (max-width: 767px) {
+  .table-responsive {
+    width: 100%;
+    margin-bottom: 15px;
+    overflow-x: scroll;
+    overflow-y: hidden;
+    -webkit-overflow-scrolling: touch;
+    -ms-overflow-style: -ms-autohiding-scrollbar;
+    border: 1px solid #ddd;
+  }
+  .table-responsive > .table {
+    margin-bottom: 0;
+  }
+  .table-responsive > .table > thead > tr > th,
+  .table-responsive > .table > tbody > tr > th,
+  .table-responsive > .table > tfoot > tr > th,
+  .table-responsive > .table > thead > tr > td,
+  .table-responsive > .table > tbody > tr > td,
+  .table-responsive > .table > tfoot > tr > td {
+    white-space: nowrap;
+  }
+  .table-responsive > .table-bordered {
+    border: 0;
+  }
+  .table-responsive > .table-bordered > thead > tr > th:first-child,
+  .table-responsive > .table-bordered > tbody > tr > th:first-child,
+  .table-responsive > .table-bordered > tfoot > tr > th:first-child,
+  .table-responsive > .table-bordered > thead > tr > td:first-child,
+  .table-responsive > .table-bordered > tbody > tr > td:first-child,
+  .table-responsive > .table-bordered > tfoot > tr > td:first-child {
+    border-left: 0;
+  }
+  .table-responsive > .table-bordered > thead > tr > th:last-child,
+  .table-responsive > .table-bordered > tbody > tr > th:last-child,
+  .table-responsive > .table-bordered > tfoot > tr > th:last-child,
+  .table-responsive > .table-bordered > thead > tr > td:last-child,
+  .table-responsive > .table-bordered > tbody > tr > td:last-child,
+  .table-responsive > .table-bordered > tfoot > tr > td:last-child {
+    border-right: 0;
+  }
+  .table-responsive > .table-bordered > tbody > tr:last-child > th,
+  .table-responsive > .table-bordered > tfoot > tr:last-child > th,
+  .table-responsive > .table-bordered > tbody > tr:last-child > td,
+  .table-responsive > .table-bordered > tfoot > tr:last-child > td {
+    border-bottom: 0;
+  }
+}
+fieldset {
+  min-width: 0;
+  padding: 0;
+  margin: 0;
+  border: 0;
+}
+legend {
+  display: block;
+  width: 100%;
+  padding: 0;
+  margin-bottom: 20px;
+  font-size: 21px;
+  line-height: inherit;
+  color: #333;
+  border: 0;
+  border-bottom: 1px solid #e5e5e5;
+}
+label {
+  display: inline-block;
+  margin-bottom: 5px;
+  font-weight: bold;
+}
+input[type="search"] {
+  -webkit-box-sizing: border-box;
+     -moz-box-sizing: border-box;
+          box-sizing: border-box;
+}
+input[type="radio"],
+input[type="checkbox"] {
+  margin: 4px 0 0;
+  margin-top: 1px \9;
+  /* IE8-9 */
+  line-height: normal;
+}
+input[type="file"] {
+  display: block;
+}
+input[type="range"] {
+  display: block;
+  width: 100%;
+}
+select[multiple],
+select[size] {
+  height: auto;
+}
+input[type="file"]:focus,
+input[type="radio"]:focus,
+input[type="checkbox"]:focus {
+  outline: thin dotted;
+  outline: 5px auto -webkit-focus-ring-color;
+  outline-offset: -2px;
+}
+output {
+  display: block;
+  padding-top: 7px;
+  font-size: 14px;
+  line-height: 1.42857143;
+  color: #555;
+}
+.form-control {
+  display: block;
+  width: 100%;
+  height: 34px;
+  padding: 6px 12px;
+  font-size: 14px;
+  line-height: 1.42857143;
+  color: #555;
+  background-color: #fff;
+  background-image: none;
+  border: 1px solid #ccc;
+  border-radius: 4px;
+  -webkit-box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075);
+          box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075);
+  -webkit-transition: border-color ease-in-out .15s, box-shadow ease-in-out .15s;
+          transition: border-color ease-in-out .15s, box-shadow ease-in-out .15s;
+}
+.form-control:focus {
+  border-color: #66afe9;
+  outline: 0;
+  -webkit-box-shadow: inset 0 1px 1px rgba(0,0,0,.075), 0 0 8px rgba(102, 175, 233, .6);
+          box-shadow: inset 0 1px 1px rgba(0,0,0,.075), 0 0 8px rgba(102, 175, 233, .6);
+}
+.form-control::-moz-placeholder {
+  color: #999;
+  opacity: 1;
+}
+.form-control:-ms-input-placeholder {
+  color: #999;
+}
+.form-control::-webkit-input-placeholder {
+  color: #999;
+}
+.form-control[disabled],
+.form-control[readonly],
+fieldset[disabled] .form-control {
+  cursor: not-allowed;
+  background-color: #eee;
+  opacity: 1;
+}
+textarea.form-control {
+  height: auto;
+}
+input[type="search"] {
+  -webkit-appearance: none;
+}
+input[type="date"] {
+  line-height: 34px;
+}
+.form-group {
+  margin-bottom: 15px;
+}
+.radio,
+.checkbox {
+  display: block;
+  min-height: 20px;
+  padding-left: 20px;
+  margin-top: 10px;
+  margin-bottom: 10px;
+}
+.radio label,
+.checkbox label {
+  display: inline;
+  font-weight: normal;
+  cursor: pointer;
+}
+.radio input[type="radio"],
+.radio-inline input[type="radio"],
+.checkbox input[type="checkbox"],
+.checkbox-inline input[type="checkbox"] {
+  float: left;
+  margin-left: -20px;
+}
+.radio + .radio,
+.checkbox + .checkbox {
+  margin-top: -5px;
+}
+.radio-inline,
+.checkbox-inline {
+  display: inline-block;
+  padding-left: 20px;
+  margin-bottom: 0;
+  font-weight: normal;
+  vertical-align: middle;
+  cursor: pointer;
+}
+.radio-inline + .radio-inline,
+.checkbox-inline + .checkbox-inline {
+  margin-top: 0;
+  margin-left: 10px;
+}
+input[type="radio"][disabled],
+input[type="checkbox"][disabled],
+.radio[disabled],
+.radio-inline[disabled],
+.checkbox[disabled],
+.checkbox-inline[disabled],
+fieldset[disabled] input[type="radio"],
+fieldset[disabled] input[type="checkbox"],
+fieldset[disabled] .radio,
+fieldset[disabled] .radio-inline,
+fieldset[disabled] .checkbox,
+fieldset[disabled] .checkbox-inline {
+  cursor: not-allowed;
+}
+.input-sm {
+  height: 30px;
+  padding: 5px 10px;
+  font-size: 12px;
+  line-height: 1.5;
+  border-radius: 3px;
+}
+select.input-sm {
+  height: 30px;
+  line-height: 30px;
+}
+textarea.input-sm,
+select[multiple].input-sm {
+  height: auto;
+}
+.input-lg {
+  height: 46px;
+  padding: 10px 16px;
+  font-size: 18px;
+  line-height: 1.33;
+  border-radius: 6px;
+}
+select.input-lg {
+  height: 46px;
+  line-height: 46px;
+}
+textarea.input-lg,
+select[multiple].input-lg {
+  height: auto;
+}
+.has-feedback {
+  position: relative;
+}
+.has-feedback .form-control {
+  padding-right: 42.5px;
+}
+.has-feedback .form-control-feedback {
+  position: absolute;
+  top: 25px;
+  right: 0;
+  display: block;
+  width: 34px;
+  height: 34px;
+  line-height: 34px;
+  text-align: center;
+}
+.has-success .help-block,
+.has-success .control-label,
+.has-success .radio,
+.has-success .checkbox,
+.has-success .radio-inline,
+.has-success .checkbox-inline {
+  color: #3c763d;
+}
+.has-success .form-control {
+  border-color: #3c763d;
+  -webkit-box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075);
+          box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075);
+}
+.has-success .form-control:focus {
+  border-color: #2b542c;
+  -webkit-box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075), 0 0 6px #67b168;
+          box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075), 0 0 6px #67b168;
+}
+.has-success .input-group-addon {
+  color: #3c763d;
+  background-color: #dff0d8;
+  border-color: #3c763d;
+}
+.has-success .form-control-feedback {
+  color: #3c763d;
+}
+.has-warning .help-block,
+.has-warning .control-label,
+.has-warning .radio,
+.has-warning .checkbox,
+.has-warning .radio-inline,
+.has-warning .checkbox-inline {
+  color: #8a6d3b;
+}
+.has-warning .form-control {
+  border-color: #8a6d3b;
+  -webkit-box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075);
+          box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075);
+}
+.has-warning .form-control:focus {
+  border-color: #66512c;
+  -webkit-box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075), 0 0 6px #c0a16b;
+          box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075), 0 0 6px #c0a16b;
+}
+.has-warning .input-group-addon {
+  color: #8a6d3b;
+  background-color: #fcf8e3;
+  border-color: #8a6d3b;
+}
+.has-warning .form-control-feedback {
+  color: #8a6d3b;
+}
+.has-error .help-block,
+.has-error .control-label,
+.has-error .radio,
+.has-error .checkbox,
+.has-error .radio-inline,
+.has-error .checkbox-inline {
+  color: #a94442;
+}
+.has-error .form-control {
+  border-color: #a94442;
+  -webkit-box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075);
+          box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075);
+}
+.has-error .form-control:focus {
+  border-color: #843534;
+  -webkit-box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075), 0 0 6px #ce8483;
+          box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075), 0 0 6px #ce8483;
+}
+.has-error .input-group-addon {
+  color: #a94442;
+  background-color: #f2dede;
+  border-color: #a94442;
+}
+.has-error .form-control-feedback {
+  color: #a94442;
+}
+.form-control-static {
+  margin-bottom: 0;
+}
+.help-block {
+  display: block;
+  margin-top: 5px;
+  margin-bottom: 10px;
+  color: #737373;
+}
+@media (min-width: 768px) {
+  .form-inline .form-group {
+    display: inline-block;
+    margin-bottom: 0;
+    vertical-align: middle;
+  }
+  .form-inline .form-control {
+    display: inline-block;
+    width: auto;
+    vertical-align: middle;
+  }
+  .form-inline .input-group > .form-control {
+    width: 100%;
+  }
+  .form-inline .control-label {
+    margin-bottom: 0;
+    vertical-align: middle;
+  }
+  .form-inline .radio,
+  .form-inline .checkbox {
+    display: inline-block;
+    padding-left: 0;
+    margin-top: 0;
+    margin-bottom: 0;
+    vertical-align: middle;
+  }
+  .form-inline .radio input[type="radio"],
+  .form-inline .checkbox input[type="checkbox"] {
+    float: none;
+    margin-left: 0;
+  }
+  .form-inline .has-feedback .form-control-feedback {
+    top: 0;
+  }
+}
+.form-horizontal .control-label,
+.form-horizontal .radio,
+.form-horizontal .checkbox,
+.form-horizontal .radio-inline,
+.form-horizontal .checkbox-inline {
+  padding-top: 7px;
+  margin-top: 0;
+  margin-bottom: 0;
+}
+.form-horizontal .radio,
+.form-horizontal .checkbox {
+  min-height: 27px;
+}
+.form-horizontal .form-group {
+  margin-right: -15px;
+  margin-left: -15px;
+}
+.form-horizontal .form-control-static {
+  padding-top: 7px;
+}
+@media (min-width: 768px) {
+  .form-horizontal .control-label {
+    text-align: right;
+  }
+}
+.form-horizontal .has-feedback .form-control-feedback {
+  top: 0;
+  right: 15px;
+}
+.btn {
+  display: inline-block;
+  padding: 6px 12px;
+  margin-bottom: 0;
+  font-size: 14px;
+  font-weight: normal;
+  line-height: 1.42857143;
+  text-align: center;
+  white-space: nowrap;
+  vertical-align: middle;
+  cursor: pointer;
+  -webkit-user-select: none;
+     -moz-user-select: none;
+      -ms-user-select: none;
+          user-select: none;
+  background-image: none;
+  border: 1px solid transparent;
+  border-radius: 4px;
+}
+.btn:focus,
+.btn:active:focus,
+.btn.active:focus {
+  outline: thin dotted;
+  outline: 5px auto -webkit-focus-ring-color;
+  outline-offset: -2px;
+}
+.btn:hover,
+.btn:focus {
+  color: #333;
+  text-decoration: none;
+}
+.btn:active,
+.btn.active {
+  background-image: none;
+  outline: 0;
+  -webkit-box-shadow: inset 0 3px 5px rgba(0, 0, 0, .125);
+          box-shadow: inset 0 3px 5px rgba(0, 0, 0, .125);
+}
+.btn.disabled,
+.btn[disabled],
+fieldset[disabled] .btn {
+  pointer-events: none;
+  cursor: not-allowed;
+  filter: alpha(opacity=65);
+  -webkit-box-shadow: none;
+          box-shadow: none;
+  opacity: .65;
+}
+.btn-default {
+  color: #333;
+  background-color: #fff;
+  border-color: #ccc;
+}
+.btn-default:hover,
+.btn-default:focus,
+.btn-default:active,
+.btn-default.active,
+.open .dropdown-toggle.btn-default {
+  color: #333;
+  background-color: #ebebeb;
+  border-color: #adadad;
+}
+.btn-default:active,
+.btn-default.active,
+.open .dropdown-toggle.btn-default {
+  background-image: none;
+}
+.btn-default.disabled,
+.btn-default[disabled],
+fieldset[disabled] .btn-default,
+.btn-default.disabled:hover,
+.btn-default[disabled]:hover,
+fieldset[disabled] .btn-default:hover,
+.btn-default.disabled:focus,
+.btn-default[disabled]:focus,
+fieldset[disabled] .btn-default:focus,
+.btn-default.disabled:active,
+.btn-default[disabled]:active,
+fieldset[disabled] .btn-default:active,
+.btn-default.disabled.active,
+.btn-default[disabled].active,
+fieldset[disabled] .btn-default.active {
+  background-color: #fff;
+  border-color: #ccc;
+}
+.btn-default .badge {
+  color: #fff;
+  background-color: #333;
+}
+.btn-primary {
+  color: #fff;
+  background-color: #428bca;
+  border-color: #357ebd;
+}
+.btn-primary:hover,
+.btn-primary:focus,
+.btn-primary:active,
+.btn-primary.active,
+.open .dropdown-toggle.btn-primary {
+  color: #fff;
+  background-color: #3276b1;
+  border-color: #285e8e;
+}
+.btn-primary:active,
+.btn-primary.active,
+.open .dropdown-toggle.btn-primary {
+  background-image: none;
+}
+.btn-primary.disabled,
+.btn-primary[disabled],
+fieldset[disabled] .btn-primary,
+.btn-primary.disabled:hover,
+.btn-primary[disabled]:hover,
+fieldset[disabled] .btn-primary:hover,
+.btn-primary.disabled:focus,
+.btn-primary[disabled]:focus,
+fieldset[disabled] .btn-primary:focus,
+.btn-primary.disabled:active,
+.btn-primary[disabled]:active,
+fieldset[disabled] .btn-primary:active,
+.btn-primary.disabled.active,
+.btn-primary[disabled].active,
+fieldset[disabled] .btn-primary.active {
+  background-color: #428bca;
+  border-color: #357ebd;
+}
+.btn-primary .badge {
+  color: #428bca;
+  background-color: #fff;
+}
+.btn-success {
+  color: #fff;
+  background-color: #5cb85c;
+  border-color: #4cae4c;
+}
+.btn-success:hover,
+.btn-success:focus,
+.btn-success:active,
+.btn-success.active,
+.open .dropdown-toggle.btn-success {
+  color: #fff;
+  background-color: #47a447;
+  border-color: #398439;
+}
+.btn-success:active,
+.btn-success.active,
+.open .dropdown-toggle.btn-success {
+  background-image: none;
+}
+.btn-success.disabled,
+.btn-success[disabled],
+fieldset[disabled] .btn-success,
+.btn-success.disabled:hover,
+.btn-success[disabled]:hover,
+fieldset[disabled] .btn-success:hover,
+.btn-success.disabled:focus,
+.btn-success[disabled]:focus,
+fieldset[disabled] .btn-success:focus,
+.btn-success.disabled:active,
+.btn-success[disabled]:active,
+fieldset[disabled] .btn-success:active,
+.btn-success.disabled.active,
+.btn-success[disabled].active,
+fieldset[disabled] .btn-success.active {
+  background-color: #5cb85c;
+  border-color: #4cae4c;
+}
+.btn-success .badge {
+  color: #5cb85c;
+  background-color: #fff;
+}
+.btn-info {
+  color: #fff;
+  background-color: #5bc0de;
+  border-color: #46b8da;
+}
+.btn-info:hover,
+.btn-info:focus,
+.btn-info:active,
+.btn-info.active,
+.open .dropdown-toggle.btn-info {
+  color: #fff;
+  background-color: #39b3d7;
+  border-color: #269abc;
+}
+.btn-info:active,
+.btn-info.active,
+.open .dropdown-toggle.btn-info {
+  background-image: none;
+}
+.btn-info.disabled,
+.btn-info[disabled],
+fieldset[disabled] .btn-info,
+.btn-info.disabled:hover,
+.btn-info[disabled]:hover,
+fieldset[disabled] .btn-info:hover,
+.btn-info.disabled:focus,
+.btn-info[disabled]:focus,
+fieldset[disabled] .btn-info:focus,
+.btn-info.disabled:active,
+.btn-info[disabled]:active,
+fieldset[disabled] .btn-info:active,
+.btn-info.disabled.active,
+.btn-info[disabled].active,
+fieldset[disabled] .btn-info.active {
+  background-color: #5bc0de;
+  border-color: #46b8da;
+}
+.btn-info .badge {
+  color: #5bc0de;
+  background-color: #fff;
+}
+.btn-warning {
+  color: #fff;
+  background-color: #f0ad4e;
+  border-color: #eea236;
+}
+.btn-warning:hover,
+.btn-warning:focus,
+.btn-warning:active,
+.btn-warning.active,
+.open .dropdown-toggle.btn-warning {
+  color: #fff;
+  background-color: #ed9c28;
+  border-color: #d58512;
+}
+.btn-warning:active,
+.btn-warning.active,
+.open .dropdown-toggle.btn-warning {
+  background-image: none;
+}
+.btn-warning.disabled,
+.btn-warning[disabled],
+fieldset[disabled] .btn-warning,
+.btn-warning.disabled:hover,
+.btn-warning[disabled]:hover,
+fieldset[disabled] .btn-warning:hover,
+.btn-warning.disabled:focus,
+.btn-warning[disabled]:focus,
+fieldset[disabled] .btn-warning:focus,
+.btn-warning.disabled:active,
+.btn-warning[disabled]:active,
+fieldset[disabled] .btn-warning:active,
+.btn-warning.disabled.active,
+.btn-warning[disabled].active,
+fieldset[disabled] .btn-warning.active {
+  background-color: #f0ad4e;
+  border-color: #eea236;
+}
+.btn-warning .badge {
+  color: #f0ad4e;
+  background-color: #fff;
+}
+.btn-danger {
+  color: #fff;
+  background-color: #d9534f;
+  border-color: #d43f3a;
+}
+.btn-danger:hover,
+.btn-danger:focus,
+.btn-danger:active,
+.btn-danger.active,
+.open .dropdown-toggle.btn-danger {
+  color: #fff;
+  background-color: #d2322d;
+  border-color: #ac2925;
+}
+.btn-danger:active,
+.btn-danger.active,
+.open .dropdown-toggle.btn-danger {
+  background-image: none;
+}
+.btn-danger.disabled,
+.btn-danger[disabled],
+fieldset[disabled] .btn-danger,
+.btn-danger.disabled:hover,
+.btn-danger[disabled]:hover,
+fieldset[disabled] .btn-danger:hover,
+.btn-danger.disabled:focus,
+.btn-danger[disabled]:focus,
+fieldset[disabled] .btn-danger:focus,
+.btn-danger.disabled:active,
+.btn-danger[disabled]:active,
+fieldset[disabled] .btn-danger:active,
+.btn-danger.disabled.active,
+.btn-danger[disabled].active,
+fieldset[disabled] .btn-danger.active {
+  background-color: #d9534f;
+  border-color: #d43f3a;
+}
+.btn-danger .badge {
+  color: #d9534f;
+  background-color: #fff;
+}
+.btn-link {
+  font-weight: normal;
+  color: #428bca;
+  cursor: pointer;
+  border-radius: 0;
+}
+.btn-link,
+.btn-link:active,
+.btn-link[disabled],
+fieldset[disabled] .btn-link {
+  background-color: transparent;
+  -webkit-box-shadow: none;
+          box-shadow: none;
+}
+.btn-link,
+.btn-link:hover,
+.btn-link:focus,
+.btn-link:active {
+  border-color: transparent;
+}
+.btn-link:hover,
+.btn-link:focus {
+  color: #2a6496;
+  text-decoration: underline;
+  background-color: transparent;
+}
+.btn-link[disabled]:hover,
+fieldset[disabled] .btn-link:hover,
+.btn-link[disabled]:focus,
+fieldset[disabled] .btn-link:focus {
+  color: #999;
+  text-decoration: none;
+}
+.btn-lg,
+.btn-group-lg > .btn {
+  padding: 10px 16px;
+  font-size: 18px;
+  line-height: 1.33;
+  border-radius: 6px;
+}
+.btn-sm,
+.btn-group-sm > .btn {
+  padding: 5px 10px;
+  font-size: 12px;
+  line-height: 1.5;
+  border-radius: 3px;
+}
+.btn-xs,
+.btn-group-xs > .btn {
+  padding: 1px 5px;
+  font-size: 12px;
+  line-height: 1.5;
+  border-radius: 3px;
+}
+.btn-block {
+  display: block;
+  width: 100%;
+  padding-right: 0;
+  padding-left: 0;
+}
+.btn-block + .btn-block {
+  margin-top: 5px;
+}
+input[type="submit"].btn-block,
+input[type="reset"].btn-block,
+input[type="button"].btn-block {
+  width: 100%;
+}
+.fade {
+  opacity: 0;
+  -webkit-transition: opacity .15s linear;
+          transition: opacity .15s linear;
+}
+.fade.in {
+  opacity: 1;
+}
+.collapse {
+  display: none;
+}
+.collapse.in {
+  display: block;
+}
+.collapsing {
+  position: relative;
+  height: 0;
+  overflow: hidden;
+  -webkit-transition: height .35s ease;
+          transition: height .35s ease;
+}
+@font-face {
+  font-family: 'Glyphicons Halflings';
+
+  src: url('../fonts/glyphicons-halflings-regular.eot');
+  src: url('../fonts/glyphicons-halflings-regular.eot?#iefix') format('embedded-opentype'), url('../fonts/glyphicons-halflings-regular.woff') format('woff'), url('../fonts/glyphicons-halflings-regular.ttf') format('truetype'), url('../fonts/glyphicons-halflings-regular.svg#glyphicons_halflingsregular') format('svg');
+}
+.glyphicon {
+  position: relative;
+  top: 1px;
+  display: inline-block;
+  font-family: 'Glyphicons Halflings';
+  font-style: normal;
+  font-weight: normal;
+  line-height: 1;
+
+  -webkit-font-smoothing: antialiased;
+  -moz-osx-font-smoothing: grayscale;
+}
+.glyphicon-asterisk:before {
+  content: "\2a";
+}
+.glyphicon-plus:before {
+  content: "\2b";
+}
+.glyphicon-euro:before {
+  content: "\20ac";
+}
+.glyphicon-minus:before {
+  content: "\2212";
+}
+.glyphicon-cloud:before {
+  content: "\2601";
+}
+.glyphicon-envelope:before {
+  content: "\2709";
+}
+.glyphicon-pencil:before {
+  content: "\270f";
+}
+.glyphicon-glass:before {
+  content: "\e001";
+}
+.glyphicon-music:before {
+  content: "\e002";
+}
+.glyphicon-search:before {
+  content: "\e003";
+}
+.glyphicon-heart:before {
+  content: "\e005";
+}
+.glyphicon-star:before {
+  content: "\e006";
+}
+.glyphicon-star-empty:before {
+  content: "\e007";
+}
+.glyphicon-user:before {
+  content: "\e008";
+}
+.glyphicon-film:before {
+  content: "\e009";
+}
+.glyphicon-th-large:before {
+  content: "\e010";
+}
+.glyphicon-th:before {
+  content: "\e011";
+}
+.glyphicon-th-list:before {
+  content: "\e012";
+}
+.glyphicon-ok:before {
+  content: "\e013";
+}
+.glyphicon-remove:before {
+  content: "\e014";
+}
+.glyphicon-zoom-in:before {
+  content: "\e015";
+}
+.glyphicon-zoom-out:before {
+  content: "\e016";
+}
+.glyphicon-off:before {
+  content: "\e017";
+}
+.glyphicon-signal:before {
+  content: "\e018";
+}
+.glyphicon-cog:before {
+  content: "\e019";
+}
+.glyphicon-trash:before {
+  content: "\e020";
+}
+.glyphicon-home:before {
+  content: "\e021";
+}
+.glyphicon-file:before {
+  content: "\e022";
+}
+.glyphicon-time:before {
+  content: "\e023";
+}
+.glyphicon-road:before {
+  content: "\e024";
+}
+.glyphicon-download-alt:before {
+  content: "\e025";
+}
+.glyphicon-download:before {
+  content: "\e026";
+}
+.glyphicon-upload:before {
+  content: "\e027";
+}
+.glyphicon-inbox:before {
+  content: "\e028";
+}
+.glyphicon-play-circle:before {
+  content: "\e029";
+}
+.glyphicon-repeat:before {
+  content: "\e030";
+}
+.glyphicon-refresh:before {
+  content: "\e031";
+}
+.glyphicon-list-alt:before {
+  content: "\e032";
+}
+.glyphicon-lock:before {
+  content: "\e033";
+}
+.glyphicon-flag:before {
+  content: "\e034";
+}
+.glyphicon-headphones:before {
+  content: "\e035";
+}
+.glyphicon-volume-off:before {
+  content: "\e036";
+}
+.glyphicon-volume-down:before {
+  content: "\e037";
+}
+.glyphicon-volume-up:before {
+  content: "\e038";
+}
+.glyphicon-qrcode:before {
+  content: "\e039";
+}
+.glyphicon-barcode:before {
+  content: "\e040";
+}
+.glyphicon-tag:before {
+  content: "\e041";
+}
+.glyphicon-tags:before {
+  content: "\e042";
+}
+.glyphicon-book:before {
+  content: "\e043";
+}
+.glyphicon-bookmark:before {
+  content: "\e044";
+}
+.glyphicon-print:before {
+  content: "\e045";
+}
+.glyphicon-camera:before {
+  content: "\e046";
+}
+.glyphicon-font:before {
+  content: "\e047";
+}
+.glyphicon-bold:before {
+  content: "\e048";
+}
+.glyphicon-italic:before {
+  content: "\e049";
+}
+.glyphicon-text-height:before {
+  content: "\e050";
+}
+.glyphicon-text-width:before {
+  content: "\e051";
+}
+.glyphicon-align-left:before {
+  content: "\e052";
+}
+.glyphicon-align-center:before {
+  content: "\e053";
+}
+.glyphicon-align-right:before {
+  content: "\e054";
+}
+.glyphicon-align-justify:before {
+  content: "\e055";
+}
+.glyphicon-list:before {
+  content: "\e056";
+}
+.glyphicon-indent-left:before {
+  content: "\e057";
+}
+.glyphicon-indent-right:before {
+  content: "\e058";
+}
+.glyphicon-facetime-video:before {
+  content: "\e059";
+}
+.glyphicon-picture:before {
+  content: "\e060";
+}
+.glyphicon-map-marker:before {
+  content: "\e062";
+}
+.glyphicon-adjust:before {
+  content: "\e063";
+}
+.glyphicon-tint:before {
+  content: "\e064";
+}
+.glyphicon-edit:before {
+  content: "\e065";
+}
+.glyphicon-share:before {
+  content: "\e066";
+}
+.glyphicon-check:before {
+  content: "\e067";
+}
+.glyphicon-move:before {
+  content: "\e068";
+}
+.glyphicon-step-backward:before {
+  content: "\e069";
+}
+.glyphicon-fast-backward:before {
+  content: "\e070";
+}
+.glyphicon-backward:before {
+  content: "\e071";
+}
+.glyphicon-play:before {
+  content: "\e072";
+}
+.glyphicon-pause:before {
+  content: "\e073";
+}
+.glyphicon-stop:before {
+  content: "\e074";
+}
+.glyphicon-forward:before {
+  content: "\e075";
+}
+.glyphicon-fast-forward:before {
+  content: "\e076";
+}
+.glyphicon-step-forward:before {
+  content: "\e077";
+}
+.glyphicon-eject:before {
+  content: "\e078";
+}
+.glyphicon-chevron-left:before {
+  content: "\e079";
+}
+.glyphicon-chevron-right:before {
+  content: "\e080";
+}
+.glyphicon-plus-sign:before {
+  content: "\e081";
+}
+.glyphicon-minus-sign:before {
+  content: "\e082";
+}
+.glyphicon-remove-sign:before {
+  content: "\e083";
+}
+.glyphicon-ok-sign:before {
+  content: "\e084";
+}
+.glyphicon-question-sign:before {
+  content: "\e085";
+}
+.glyphicon-info-sign:before {
+  content: "\e086";
+}
+.glyphicon-screenshot:before {
+  content: "\e087";
+}
+.glyphicon-remove-circle:before {
+  content: "\e088";
+}
+.glyphicon-ok-circle:before {
+  content: "\e089";
+}
+.glyphicon-ban-circle:before {
+  content: "\e090";
+}
+.glyphicon-arrow-left:before {
+  content: "\e091";
+}
+.glyphicon-arrow-right:before {
+  content: "\e092";
+}
+.glyphicon-arrow-up:before {
+  content: "\e093";
+}
+.glyphicon-arrow-down:before {
+  content: "\e094";
+}
+.glyphicon-share-alt:before {
+  content: "\e095";
+}
+.glyphicon-resize-full:before {
+  content: "\e096";
+}
+.glyphicon-resize-small:before {
+  content: "\e097";
+}
+.glyphicon-exclamation-sign:before {
+  content: "\e101";
+}
+.glyphicon-gift:before {
+  content: "\e102";
+}
+.glyphicon-leaf:before {
+  content: "\e103";
+}
+.glyphicon-fire:before {
+  content: "\e104";
+}
+.glyphicon-eye-open:before {
+  content: "\e105";
+}
+.glyphicon-eye-close:before {
+  content: "\e106";
+}
+.glyphicon-warning-sign:before {
+  content: "\e107";
+}
+.glyphicon-plane:before {
+  content: "\e108";
+}
+.glyphicon-calendar:before {
+  content: "\e109";
+}
+.glyphicon-random:before {
+  content: "\e110";
+}
+.glyphicon-comment:before {
+  content: "\e111";
+}
+.glyphicon-magnet:before {
+  content: "\e112";
+}
+.glyphicon-chevron-up:before {
+  content: "\e113";
+}
+.glyphicon-chevron-down:before {
+  content: "\e114";
+}
+.glyphicon-retweet:before {
+  content: "\e115";
+}
+.glyphicon-shopping-cart:before {
+  content: "\e116";
+}
+.glyphicon-folder-close:before {
+  content: "\e117";
+}
+.glyphicon-folder-open:before {
+  content: "\e118";
+}
+.glyphicon-resize-vertical:before {
+  content: "\e119";
+}
+.glyphicon-resize-horizontal:before {
+  content: "\e120";
+}
+.glyphicon-hdd:before {
+  content: "\e121";
+}
+.glyphicon-bullhorn:before {
+  content: "\e122";
+}
+.glyphicon-bell:before {
+  content: "\e123";
+}
+.glyphicon-certificate:before {
+  content: "\e124";
+}
+.glyphicon-thumbs-up:before {
+  content: "\e125";
+}
+.glyphicon-thumbs-down:before {
+  content: "\e126";
+}
+.glyphicon-hand-right:before {
+  content: "\e127";
+}
+.glyphicon-hand-left:before {
+  content: "\e128";
+}
+.glyphicon-hand-up:before {
+  content: "\e129";
+}
+.glyphicon-hand-down:before {
+  content: "\e130";
+}
+.glyphicon-circle-arrow-right:before {
+  content: "\e131";
+}
+.glyphicon-circle-arrow-left:before {
+  content: "\e132";
+}
+.glyphicon-circle-arrow-up:before {
+  content: "\e133";
+}
+.glyphicon-circle-arrow-down:before {
+  content: "\e134";
+}
+.glyphicon-globe:before {
+  content: "\e135";
+}
+.glyphicon-wrench:before {
+  content: "\e136";
+}
+.glyphicon-tasks:before {
+  content: "\e137";
+}
+.glyphicon-filter:before {
+  content: "\e138";
+}
+.glyphicon-briefcase:before {
+  content: "\e139";
+}
+.glyphicon-fullscreen:before {
+  content: "\e140";
+}
+.glyphicon-dashboard:before {
+  content: "\e141";
+}
+.glyphicon-paperclip:before {
+  content: "\e142";
+}
+.glyphicon-heart-empty:before {
+  content: "\e143";
+}
+.glyphicon-link:before {
+  content: "\e144";
+}
+.glyphicon-phone:before {
+  content: "\e145";
+}
+.glyphicon-pushpin:before {
+  content: "\e146";
+}
+.glyphicon-usd:before {
+  content: "\e148";
+}
+.glyphicon-gbp:before {
+  content: "\e149";
+}
+.glyphicon-sort:before {
+  content: "\e150";
+}
+.glyphicon-sort-by-alphabet:before {
+  content: "\e151";
+}
+.glyphicon-sort-by-alphabet-alt:before {
+  content: "\e152";
+}
+.glyphicon-sort-by-order:before {
+  content: "\e153";
+}
+.glyphicon-sort-by-order-alt:before {
+  content: "\e154";
+}
+.glyphicon-sort-by-attributes:before {
+  content: "\e155";
+}
+.glyphicon-sort-by-attributes-alt:before {
+  content: "\e156";
+}
+.glyphicon-unchecked:before {
+  content: "\e157";
+}
+.glyphicon-expand:before {
+  content: "\e158";
+}
+.glyphicon-collapse-down:before {
+  content: "\e159";
+}
+.glyphicon-collapse-up:before {
+  content: "\e160";
+}
+.glyphicon-log-in:before {
+  content: "\e161";
+}
+.glyphicon-flash:before {
+  content: "\e162";
+}
+.glyphicon-log-out:before {
+  content: "\e163";
+}
+.glyphicon-new-window:before {
+  content: "\e164";
+}
+.glyphicon-record:before {
+  content: "\e165";
+}
+.glyphicon-save:before {
+  content: "\e166";
+}
+.glyphicon-open:before {
+  content: "\e167";
+}
+.glyphicon-saved:before {
+  content: "\e168";
+}
+.glyphicon-import:before {
+  content: "\e169";
+}
+.glyphicon-export:before {
+  content: "\e170";
+}
+.glyphicon-send:before {
+  content: "\e171";
+}
+.glyphicon-floppy-disk:before {
+  content: "\e172";
+}
+.glyphicon-floppy-saved:before {
+  content: "\e173";
+}
+.glyphicon-floppy-remove:before {
+  content: "\e174";
+}
+.glyphicon-floppy-save:before {
+  content: "\e175";
+}
+.glyphicon-floppy-open:before {
+  content: "\e176";
+}
+.glyphicon-credit-card:before {
+  content: "\e177";
+}
+.glyphicon-transfer:before {
+  content: "\e178";
+}
+.glyphicon-cutlery:before {
+  content: "\e179";
+}
+.glyphicon-header:before {
+  content: "\e180";
+}
+.glyphicon-compressed:before {
+  content: "\e181";
+}
+.glyphicon-earphone:before {
+  content: "\e182";
+}
+.glyphicon-phone-alt:before {
+  content: "\e183";
+}
+.glyphicon-tower:before {
+  content: "\e184";
+}
+.glyphicon-stats:before {
+  content: "\e185";
+}
+.glyphicon-sd-video:before {
+  content: "\e186";
+}
+.glyphicon-hd-video:before {
+  content: "\e187";
+}
+.glyphicon-subtitles:before {
+  content: "\e188";
+}
+.glyphicon-sound-stereo:before {
+  content: "\e189";
+}
+.glyphicon-sound-dolby:before {
+  content: "\e190";
+}
+.glyphicon-sound-5-1:before {
+  content: "\e191";
+}
+.glyphicon-sound-6-1:before {
+  content: "\e192";
+}
+.glyphicon-sound-7-1:before {
+  content: "\e193";
+}
+.glyphicon-copyright-mark:before {
+  content: "\e194";
+}
+.glyphicon-registration-mark:before {
+  content: "\e195";
+}
+.glyphicon-cloud-download:before {
+  content: "\e197";
+}
+.glyphicon-cloud-upload:before {
+  content: "\e198";
+}
+.glyphicon-tree-conifer:before {
+  content: "\e199";
+}
+.glyphicon-tree-deciduous:before {
+  content: "\e200";
+}
+.caret {
+  display: inline-block;
+  width: 0;
+  height: 0;
+  margin-left: 2px;
+  vertical-align: middle;
+  border-top: 4px solid;
+  border-right: 4px solid transparent;
+  border-left: 4px solid transparent;
+}
+.dropdown {
+  position: relative;
+}
+.dropdown-toggle:focus {
+  outline: 0;
+}
+.dropdown-menu {
+  position: absolute;
+  top: 100%;
+  left: 0;
+  z-index: 1000;
+  display: none;
+  float: left;
+  min-width: 160px;
+  padding: 5px 0;
+  margin: 2px 0 0;
+  font-size: 14px;
+  list-style: none;
+  background-color: #fff;
+  background-clip: padding-box;
+  border: 1px solid #ccc;
+  border: 1px solid rgba(0, 0, 0, .15);
+  border-radius: 4px;
+  -webkit-box-shadow: 0 6px 12px rgba(0, 0, 0, .175);
+          box-shadow: 0 6px 12px rgba(0, 0, 0, .175);
+}
+.dropdown-menu.pull-right {
+  right: 0;
+  left: auto;
+}
+.dropdown-menu .divider {
+  height: 1px;
+  margin: 9px 0;
+  overflow: hidden;
+  background-color: #e5e5e5;
+}
+.dropdown-menu > li > a {
+  display: block;
+  padding: 3px 20px;
+  clear: both;
+  font-weight: normal;
+  line-height: 1.42857143;
+  color: #333;
+  white-space: nowrap;
+}
+.dropdown-menu > li > a:hover,
+.dropdown-menu > li > a:focus {
+  color: #262626;
+  text-decoration: none;
+  background-color: #f5f5f5;
+}
+.dropdown-menu > .active > a,
+.dropdown-menu > .active > a:hover,
+.dropdown-menu > .active > a:focus {
+  color: #fff;
+  text-decoration: none;
+  background-color: #428bca;
+  outline: 0;
+}
+.dropdown-menu > .disabled > a,
+.dropdown-menu > .disabled > a:hover,
+.dropdown-menu > .disabled > a:focus {
+  color: #999;
+}
+.dropdown-menu > .disabled > a:hover,
+.dropdown-menu > .disabled > a:focus {
+  text-decoration: none;
+  cursor: not-allowed;
+  background-color: transparent;
+  background-image: none;
+  filter: progid:DXImageTransform.Microsoft.gradient(enabled = false);
+}
+.open > .dropdown-menu {
+  display: block;
+}
+.open > a {
+  outline: 0;
+}
+.dropdown-menu-right {
+  right: 0;
+  left: auto;
+}
+.dropdown-menu-left {
+  right: auto;
+  left: 0;
+}
+.dropdown-header {
+  display: block;
+  padding: 3px 20px;
+  font-size: 12px;
+  line-height: 1.42857143;
+  color: #999;
+}
+.dropdown-backdrop {
+  position: fixed;
+  top: 0;
+  right: 0;
+  bottom: 0;
+  left: 0;
+  z-index: 990;
+}
+.pull-right > .dropdown-menu {
+  right: 0;
+  left: auto;
+}
+.dropup .caret,
+.navbar-fixed-bottom .dropdown .caret {
+  content: "";
+  border-top: 0;
+  border-bottom: 4px solid;
+}
+.dropup .dropdown-menu,
+.navbar-fixed-bottom .dropdown .dropdown-menu {
+  top: auto;
+  bottom: 100%;
+  margin-bottom: 1px;
+}
+@media (min-width: 768px) {
+  .navbar-right .dropdown-menu {
+    right: 0;
+    left: auto;
+  }
+  .navbar-right .dropdown-menu-left {
+    right: auto;
+    left: 0;
+  }
+}
+.btn-group,
+.btn-group-vertical {
+  position: relative;
+  display: inline-block;
+  vertical-align: middle;
+}
+.btn-group > .btn,
+.btn-group-vertical > .btn {
+  position: relative;
+  float: left;
+}
+.btn-group > .btn:hover,
+.btn-group-vertical > .btn:hover,
+.btn-group > .btn:focus,
+.btn-group-vertical > .btn:focus,
+.btn-group > .btn:active,
+.btn-group-vertical > .btn:active,
+.btn-group > .btn.active,
+.btn-group-vertical > .btn.active {
+  z-index: 2;
+}
+.btn-group > .btn:focus,
+.btn-group-vertical > .btn:focus {
+  outline: none;
+}
+.btn-group .btn + .btn,
+.btn-group .btn + .btn-group,
+.btn-group .btn-group + .btn,
+.btn-group .btn-group + .btn-group {
+  margin-left: -1px;
+}
+.btn-toolbar {
+  margin-left: -5px;
+}
+.btn-toolbar .btn-group,
+.btn-toolbar .input-group {
+  float: left;
+}
+.btn-toolbar > .btn,
+.btn-toolbar > .btn-group,
+.btn-toolbar > .input-group {
+  margin-left: 5px;
+}
+.btn-group > .btn:not(:first-child):not(:last-child):not(.dropdown-toggle) {
+  border-radius: 0;
+}
+.btn-group > .btn:first-child {
+  margin-left: 0;
+}
+.btn-group > .btn:first-child:not(:last-child):not(.dropdown-toggle) {
+  border-top-right-radius: 0;
+  border-bottom-right-radius: 0;
+}
+.btn-group > .btn:last-child:not(:first-child),
+.btn-group > .dropdown-toggle:not(:first-child) {
+  border-top-left-radius: 0;
+  border-bottom-left-radius: 0;
+}
+.btn-group > .btn-group {
+  float: left;
+}
+.btn-group > .btn-group:not(:first-child):not(:last-child) > .btn {
+  border-radius: 0;
+}
+.btn-group > .btn-group:first-child > .btn:last-child,
+.btn-group > .btn-group:first-child > .dropdown-toggle {
+  border-top-right-radius: 0;
+  border-bottom-right-radius: 0;
+}
+.btn-group > .btn-group:last-child > .btn:first-child {
+  border-top-left-radius: 0;
+  border-bottom-left-radius: 0;
+}
+.btn-group .dropdown-toggle:active,
+.btn-group.open .dropdown-toggle {
+  outline: 0;
+}
+.btn-group > .btn + .dropdown-toggle {
+  padding-right: 8px;
+  padding-left: 8px;
+}
+.btn-group > .btn-lg + .dropdown-toggle {
+  padding-right: 12px;
+  padding-left: 12px;
+}
+.btn-group.open .dropdown-toggle {
+  -webkit-box-shadow: inset 0 3px 5px rgba(0, 0, 0, .125);
+          box-shadow: inset 0 3px 5px rgba(0, 0, 0, .125);
+}
+.btn-group.open .dropdown-toggle.btn-link {
+  -webkit-box-shadow: none;
+          box-shadow: none;
+}
+.btn .caret {
+  margin-left: 0;
+}
+.btn-lg .caret {
+  border-width: 5px 5px 0;
+  border-bottom-width: 0;
+}
+.dropup .btn-lg .caret {
+  border-width: 0 5px 5px;
+}
+.btn-group-vertical > .btn,
+.btn-group-vertical > .btn-group,
+.btn-group-vertical > .btn-group > .btn {
+  display: block;
+  float: none;
+  width: 100%;
+  max-width: 100%;
+}
+.btn-group-vertical > .btn-group > .btn {
+  float: none;
+}
+.btn-group-vertical > .btn + .btn,
+.btn-group-vertical > .btn + .btn-group,
+.btn-group-vertical > .btn-group + .btn,
+.btn-group-vertical > .btn-group + .btn-group {
+  margin-top: -1px;
+  margin-left: 0;
+}
+.btn-group-vertical > .btn:not(:first-child):not(:last-child) {
+  border-radius: 0;
+}
+.btn-group-vertical > .btn:first-child:not(:last-child) {
+  border-top-right-radius: 4px;
+  border-bottom-right-radius: 0;
+  border-bottom-left-radius: 0;
+}
+.btn-group-vertical > .btn:last-child:not(:first-child) {
+  border-top-left-radius: 0;
+  border-top-right-radius: 0;
+  border-bottom-left-radius: 4px;
+}
+.btn-group-vertical > .btn-group:not(:first-child):not(:last-child) > .btn {
+  border-radius: 0;
+}
+.btn-group-vertical > .btn-group:first-child:not(:last-child) > .btn:last-child,
+.btn-group-vertical > .btn-group:first-child:not(:last-child) > .dropdown-toggle {
+  border-bottom-right-radius: 0;
+  border-bottom-left-radius: 0;
+}
+.btn-group-vertical > .btn-group:last-child:not(:first-child) > .btn:first-child {
+  border-top-left-radius: 0;
+  border-top-right-radius: 0;
+}
+.btn-group-justified {
+  display: table;
+  width: 100%;
+  table-layout: fixed;
+  border-collapse: separate;
+}
+.btn-group-justified > .btn,
+.btn-group-justified > .btn-group {
+  display: table-cell;
+  float: none;
+  width: 1%;
+}
+.btn-group-justified > .btn-group .btn {
+  width: 100%;
+}
+[data-toggle="buttons"] > .btn > input[type="radio"],
+[data-toggle="buttons"] > .btn > input[type="checkbox"] {
+  display: none;
+}
+.input-group {
+  position: relative;
+  display: table;
+  border-collapse: separate;
+}
+.input-group[class*="col-"] {
+  float: none;
+  padding-right: 0;
+  padding-left: 0;
+}
+.input-group .form-control {
+  position: relative;
+  z-index: 2;
+  float: left;
+  width: 100%;
+  margin-bottom: 0;
+}
+.input-group-lg > .form-control,
+.input-group-lg > .input-group-addon,
+.input-group-lg > .input-group-btn > .btn {
+  height: 46px;
+  padding: 10px 16px;
+  font-size: 18px;
+  line-height: 1.33;
+  border-radius: 6px;
+}
+select.input-group-lg > .form-control,
+select.input-group-lg > .input-group-addon,
+select.input-group-lg > .input-group-btn > .btn {
+  height: 46px;
+  line-height: 46px;
+}
+textarea.input-group-lg > .form-control,
+textarea.input-group-lg > .input-group-addon,
+textarea.input-group-lg > .input-group-btn > .btn,
+select[multiple].input-group-lg > .form-control,
+select[multiple].input-group-lg > .input-group-addon,
+select[multiple].input-group-lg > .input-group-btn > .btn {
+  height: auto;
+}
+.input-group-sm > .form-control,
+.input-group-sm > .input-group-addon,
+.input-group-sm > .input-group-btn > .btn {
+  height: 30px;
+  padding: 5px 10px;
+  font-size: 12px;
+  line-height: 1.5;
+  border-radius: 3px;
+}
+select.input-group-sm > .form-control,
+select.input-group-sm > .input-group-addon,
+select.input-group-sm > .input-group-btn > .btn {
+  height: 30px;
+  line-height: 30px;
+}
+textarea.input-group-sm > .form-control,
+textarea.input-group-sm > .input-group-addon,
+textarea.input-group-sm > .input-group-btn > .btn,
+select[multiple].input-group-sm > .form-control,
+select[multiple].input-group-sm > .input-group-addon,
+select[multiple].input-group-sm > .input-group-btn > .btn {
+  height: auto;
+}
+.input-group-addon,
+.input-group-btn,
+.input-group .form-control {
+  display: table-cell;
+}
+.input-group-addon:not(:first-child):not(:last-child),
+.input-group-btn:not(:first-child):not(:last-child),
+.input-group .form-control:not(:first-child):not(:last-child) {
+  border-radius: 0;
+}
+.input-group-addon,
+.input-group-btn {
+  width: 1%;
+  white-space: nowrap;
+  vertical-align: middle;
+}
+.input-group-addon {
+  padding: 6px 12px;
+  font-size: 14px;
+  font-weight: normal;
+  line-height: 1;
+  color: #555;
+  text-align: center;
+  background-color: #eee;
+  border: 1px solid #ccc;
+  border-radius: 4px;
+}
+.input-group-addon.input-sm {
+  padding: 5px 10px;
+  font-size: 12px;
+  border-radius: 3px;
+}
+.input-group-addon.input-lg {
+  padding: 10px 16px;
+  font-size: 18px;
+  border-radius: 6px;
+}
+.input-group-addon input[type="radio"],
+.input-group-addon input[type="checkbox"] {
+  margin-top: 0;
+}
+.input-group .form-control:first-child,
+.input-group-addon:first-child,
+.input-group-btn:first-child > .btn,
+.input-group-btn:first-child > .btn-group > .btn,
+.input-group-btn:first-child > .dropdown-toggle,
+.input-group-btn:last-child > .btn:not(:last-child):not(.dropdown-toggle),
+.input-group-btn:last-child > .btn-group:not(:last-child) > .btn {
+  border-top-right-radius: 0;
+  border-bottom-right-radius: 0;
+}
+.input-group-addon:first-child {
+  border-right: 0;
+}
+.input-group .form-control:last-child,
+.input-group-addon:last-child,
+.input-group-btn:last-child > .btn,
+.input-group-btn:last-child > .btn-group > .btn,
+.input-group-btn:last-child > .dropdown-toggle,
+.input-group-btn:first-child > .btn:not(:first-child),
+.input-group-btn:first-child > .btn-group:not(:first-child) > .btn {
+  border-top-left-radius: 0;
+  border-bottom-left-radius: 0;
+}
+.input-group-addon:last-child {
+  border-left: 0;
+}
+.input-group-btn {
+  position: relative;
+  font-size: 0;
+  white-space: nowrap;
+}
+.input-group-btn > .btn {
+  position: relative;
+}
+.input-group-btn > .btn + .btn {
+  margin-left: -1px;
+}
+.input-group-btn > .btn:hover,
+.input-group-btn > .btn:focus,
+.input-group-btn > .btn:active {
+  z-index: 2;
+}
+.input-group-btn:first-child > .btn,
+.input-group-btn:first-child > .btn-group {
+  margin-right: -1px;
+}
+.input-group-btn:last-child > .btn,
+.input-group-btn:last-child > .btn-group {
+  margin-left: -1px;
+}
+.nav {
+  padding-left: 0;
+  margin-bottom: 0;
+  list-style: none;
+}
+.nav > li {
+  position: relative;
+  display: block;
+}
+.nav > li > a {
+  position: relative;
+  display: block;
+  padding: 10px 15px;
+}
+.nav > li > a:hover,
+.nav > li > a:focus {
+  text-decoration: none;
+  background-color: #eee;
+}
+.nav > li.disabled > a {
+  color: #999;
+}
+.nav > li.disabled > a:hover,
+.nav > li.disabled > a:focus {
+  color: #999;
+  text-decoration: none;
+  cursor: not-allowed;
+  background-color: transparent;
+}
+.nav .open > a,
+.nav .open > a:hover,
+.nav .open > a:focus {
+  background-color: #eee;
+  border-color: #428bca;
+}
+.nav .nav-divider {
+  height: 1px;
+  margin: 9px 0;
+  overflow: hidden;
+  background-color: #e5e5e5;
+}
+.nav > li > a > img {
+  max-width: none;
+}
+.nav-tabs {
+  border-bottom: 1px solid #ddd;
+}
+.nav-tabs > li {
+  float: left;
+  margin-bottom: -1px;
+}
+.nav-tabs > li > a {
+  margin-right: 2px;
+  line-height: 1.42857143;
+  border: 1px solid transparent;
+  border-radius: 4px 4px 0 0;
+}
+.nav-tabs > li > a:hover {
+  border-color: #eee #eee #ddd;
+}
+.nav-tabs > li.active > a,
+.nav-tabs > li.active > a:hover,
+.nav-tabs > li.active > a:focus {
+  color: #555;
+  cursor: default;
+  background-color: #fff;
+  border: 1px solid #ddd;
+  border-bottom-color: transparent;
+}
+.nav-tabs.nav-justified {
+  width: 100%;
+  border-bottom: 0;
+}
+.nav-tabs.nav-justified > li {
+  float: none;
+}
+.nav-tabs.nav-justified > li > a {
+  margin-bottom: 5px;
+  text-align: center;
+}
+.nav-tabs.nav-justified > .dropdown .dropdown-menu {
+  top: auto;
+  left: auto;
+}
+@media (min-width: 768px) {
+  .nav-tabs.nav-justified > li {
+    display: table-cell;
+    width: 1%;
+  }
+  .nav-tabs.nav-justified > li > a {
+    margin-bottom: 0;
+  }
+}
+.nav-tabs.nav-justified > li > a {
+  margin-right: 0;
+  border-radius: 4px;
+}
+.nav-tabs.nav-justified > .active > a,
+.nav-tabs.nav-justified > .active > a:hover,
+.nav-tabs.nav-justified > .active > a:focus {
+  border: 1px solid #ddd;
+}
+@media (min-width: 768px) {
+  .nav-tabs.nav-justified > li > a {
+    border-bottom: 1px solid #ddd;
+    border-radius: 4px 4px 0 0;
+  }
+  .nav-tabs.nav-justified > .active > a,
+  .nav-tabs.nav-justified > .active > a:hover,
+  .nav-tabs.nav-justified > .active > a:focus {
+    border-bottom-color: #fff;
+  }
+}
+.nav-pills > li {
+  float: left;
+}
+.nav-pills > li > a {
+  border-radius: 4px;
+}
+.nav-pills > li + li {
+  margin-left: 2px;
+}
+.nav-pills > li.active > a,
+.nav-pills > li.active > a:hover,
+.nav-pills > li.active > a:focus {
+  color: #fff;
+  background-color: #428bca;
+}
+.nav-stacked > li {
+  float: none;
+}
+.nav-stacked > li + li {
+  margin-top: 2px;
+  margin-left: 0;
+}
+.nav-justified {
+  width: 100%;
+}
+.nav-justified > li {
+  float: none;
+}
+.nav-justified > li > a {
+  margin-bottom: 5px;
+  text-align: center;
+}
+.nav-justified > .dropdown .dropdown-menu {
+  top: auto;
+  left: auto;
+}
+@media (min-width: 768px) {
+  .nav-justified > li {
+    display: table-cell;
+    width: 1%;
+  }
+  .nav-justified > li > a {
+    margin-bottom: 0;
+  }
+}
+.nav-tabs-justified {
+  border-bottom: 0;
+}
+.nav-tabs-justified > li > a {
+  margin-right: 0;
+  border-radius: 4px;
+}
+.nav-tabs-justified > .active > a,
+.nav-tabs-justified > .active > a:hover,
+.nav-tabs-justified > .active > a:focus {
+  border: 1px solid #ddd;
+}
+@media (min-width: 768px) {
+  .nav-tabs-justified > li > a {
+    border-bottom: 1px solid #ddd;
+    border-radius: 4px 4px 0 0;
+  }
+  .nav-tabs-justified > .active > a,
+  .nav-tabs-justified > .active > a:hover,
+  .nav-tabs-justified > .active > a:focus {
+    border-bottom-color: #fff;
+  }
+}
+.tab-content > .tab-pane {
+  display: none;
+}
+.tab-content > .active {
+  display: block;
+}
+.nav-tabs .dropdown-menu {
+  margin-top: -1px;
+  border-top-left-radius: 0;
+  border-top-right-radius: 0;
+}
+.navbar {
+  position: relative;
+  min-height: 50px;
+  margin-bottom: 20px;
+  border: 1px solid transparent;
+}
+@media (min-width: 768px) {
+  .navbar {
+    border-radius: 4px;
+  }
+}
+@media (min-width: 768px) {
+  .navbar-header {
+    float: left;
+  }
+}
+.navbar-collapse {
+  max-height: 340px;
+  padding-right: 15px;
+  padding-left: 15px;
+  overflow-x: visible;
+  -webkit-overflow-scrolling: touch;
+  border-top: 1px solid transparent;
+  box-shadow: inset 0 1px 0 rgba(255, 255, 255, .1);
+}
+.navbar-collapse.in {
+  overflow-y: auto;
+}
+@media (min-width: 768px) {
+  .navbar-collapse {
+    width: auto;
+    border-top: 0;
+    box-shadow: none;
+  }
+  .navbar-collapse.collapse {
+    display: block !important;
+    height: auto !important;
+    padding-bottom: 0;
+    overflow: visible !important;
+  }
+  .navbar-collapse.in {
+    overflow-y: visible;
+  }
+  .navbar-fixed-top .navbar-collapse,
+  .navbar-static-top .navbar-collapse,
+  .navbar-fixed-bottom .navbar-collapse {
+    padding-right: 0;
+    padding-left: 0;
+  }
+}
+.container > .navbar-header,
+.container-fluid > .navbar-header,
+.container > .navbar-collapse,
+.container-fluid > .navbar-collapse {
+  margin-right: -15px;
+  margin-left: -15px;
+}
+@media (min-width: 768px) {
+  .container > .navbar-header,
+  .container-fluid > .navbar-header,
+  .container > .navbar-collapse,
+  .container-fluid > .navbar-collapse {
+    margin-right: 0;
+    margin-left: 0;
+  }
+}
+.navbar-static-top {
+  z-index: 1000;
+  border-width: 0 0 1px;
+}
+@media (min-width: 768px) {
+  .navbar-static-top {
+    border-radius: 0;
+  }
+}
+.navbar-fixed-top,
+.navbar-fixed-bottom {
+  position: fixed;
+  right: 0;
+  left: 0;
+  z-index: 1030;
+}
+@media (min-width: 768px) {
+  .navbar-fixed-top,
+  .navbar-fixed-bottom {
+    border-radius: 0;
+  }
+}
+.navbar-fixed-top {
+  top: 0;
+  border-width: 0 0 1px;
+}
+.navbar-fixed-bottom {
+  bottom: 0;
+  margin-bottom: 0;
+  border-width: 1px 0 0;
+}
+.navbar-brand {
+  float: left;
+  height: 50px;
+  padding: 15px 15px;
+  font-size: 18px;
+  line-height: 20px;
+}
+.navbar-brand:hover,
+.navbar-brand:focus {
+  text-decoration: none;
+}
+@media (min-width: 768px) {
+  .navbar > .container .navbar-brand,
+  .navbar > .container-fluid .navbar-brand {
+    margin-left: -15px;
+  }
+}
+.navbar-toggle {
+  position: relative;
+  float: right;
+  padding: 9px 10px;
+  margin-top: 8px;
+  margin-right: 15px;
+  margin-bottom: 8px;
+  background-color: transparent;
+  background-image: none;
+  border: 1px solid transparent;
+  border-radius: 4px;
+}
+.navbar-toggle:focus {
+  outline: none;
+}
+.navbar-toggle .icon-bar {
+  display: block;
+  width: 22px;
+  height: 2px;
+  border-radius: 1px;
+}
+.navbar-toggle .icon-bar + .icon-bar {
+  margin-top: 4px;
+}
+@media (min-width: 768px) {
+  .navbar-toggle {
+    display: none;
+  }
+}
+.navbar-nav {
+  margin: 7.5px -15px;
+}
+.navbar-nav > li > a {
+  padding-top: 10px;
+  padding-bottom: 10px;
+  line-height: 20px;
+}
+@media (max-width: 767px) {
+  .navbar-nav .open .dropdown-menu {
+    position: static;
+    float: none;
+    width: auto;
+    margin-top: 0;
+    background-color: transparent;
+    border: 0;
+    box-shadow: none;
+  }
+  .navbar-nav .open .dropdown-menu > li > a,
+  .navbar-nav .open .dropdown-menu .dropdown-header {
+    padding: 5px 15px 5px 25px;
+  }
+  .navbar-nav .open .dropdown-menu > li > a {
+    line-height: 20px;
+  }
+  .navbar-nav .open .dropdown-menu > li > a:hover,
+  .navbar-nav .open .dropdown-menu > li > a:focus {
+    background-image: none;
+  }
+}
+@media (min-width: 768px) {
+  .navbar-nav {
+    float: left;
+    margin: 0;
+  }
+  .navbar-nav > li {
+    float: left;
+  }
+  .navbar-nav > li > a {
+    padding-top: 15px;
+    padding-bottom: 15px;
+  }
+  .navbar-nav.navbar-right:last-child {
+    margin-right: -15px;
+  }
+}
+@media (min-width: 768px) {
+  .navbar-left {
+    float: left !important;
+  }
+  .navbar-right {
+    float: right !important;
+  }
+}
+.navbar-form {
+  padding: 10px 15px;
+  margin-top: 8px;
+  margin-right: -15px;
+  margin-bottom: 8px;
+  margin-left: -15px;
+  border-top: 1px solid transparent;
+  border-bottom: 1px solid transparent;
+  -webkit-box-shadow: inset 0 1px 0 rgba(255, 255, 255, .1), 0 1px 0 rgba(255, 255, 255, .1);
+          box-shadow: inset 0 1px 0 rgba(255, 255, 255, .1), 0 1px 0 rgba(255, 255, 255, .1);
+}
+@media (min-width: 768px) {
+  .navbar-form .form-group {
+    display: inline-block;
+    margin-bottom: 0;
+    vertical-align: middle;
+  }
+  .navbar-form .form-control {
+    display: inline-block;
+    width: auto;
+    vertical-align: middle;
+  }
+  .navbar-form .input-group > .form-control {
+    width: 100%;
+  }
+  .navbar-form .control-label {
+    margin-bottom: 0;
+    vertical-align: middle;
+  }
+  .navbar-form .radio,
+  .navbar-form .checkbox {
+    display: inline-block;
+    padding-left: 0;
+    margin-top: 0;
+    margin-bottom: 0;
+    vertical-align: middle;
+  }
+  .navbar-form .radio input[type="radio"],
+  .navbar-form .checkbox input[type="checkbox"] {
+    float: none;
+    margin-left: 0;
+  }
+  .navbar-form .has-feedback .form-control-feedback {
+    top: 0;
+  }
+}
+@media (max-width: 767px) {
+  .navbar-form .form-group {
+    margin-bottom: 5px;
+  }
+}
+@media (min-width: 768px) {
+  .navbar-form {
+    width: auto;
+    padding-top: 0;
+    padding-bottom: 0;
+    margin-right: 0;
+    margin-left: 0;
+    border: 0;
+    -webkit-box-shadow: none;
+            box-shadow: none;
+  }
+  .navbar-form.navbar-right:last-child {
+    margin-right: -15px;
+  }
+}
+.navbar-nav > li > .dropdown-menu {
+  margin-top: 0;
+  border-top-left-radius: 0;
+  border-top-right-radius: 0;
+}
+.navbar-fixed-bottom .navbar-nav > li > .dropdown-menu {
+  border-bottom-right-radius: 0;
+  border-bottom-left-radius: 0;
+}
+.navbar-btn {
+  margin-top: 8px;
+  margin-bottom: 8px;
+}
+.navbar-btn.btn-sm {
+  margin-top: 10px;
+  margin-bottom: 10px;
+}
+.navbar-btn.btn-xs {
+  margin-top: 14px;
+  margin-bottom: 14px;
+}
+.navbar-text {
+  margin-top: 15px;
+  margin-bottom: 15px;
+}
+@media (min-width: 768px) {
+  .navbar-text {
+    float: left;
+    margin-right: 15px;
+    margin-left: 15px;
+  }
+  .navbar-text.navbar-right:last-child {
+    margin-right: 0;
+  }
+}
+.navbar-default {
+  background-color: #f8f8f8;
+  border-color: #e7e7e7;
+}
+.navbar-default .navbar-brand {
+  color: #777;
+}
+.navbar-default .navbar-brand:hover,
+.navbar-default .navbar-brand:focus {
+  color: #5e5e5e;
+  background-color: transparent;
+}
+.navbar-default .navbar-text {
+  color: #777;
+}
+.navbar-default .navbar-nav > li > a {
+  color: #777;
+}
+.navbar-default .navbar-nav > li > a:hover,
+.navbar-default .navbar-nav > li > a:focus {
+  color: #333;
+  background-color: transparent;
+}
+.navbar-default .navbar-nav > .active > a,
+.navbar-default .navbar-nav > .active > a:hover,
+.navbar-default .navbar-nav > .active > a:focus {
+  color: #555;
+  background-color: #e7e7e7;
+}
+.navbar-default .navbar-nav > .disabled > a,
+.navbar-default .navbar-nav > .disabled > a:hover,
+.navbar-default .navbar-nav > .disabled > a:focus {
+  color: #ccc;
+  background-color: transparent;
+}
+.navbar-default .navbar-toggle {
+  border-color: #ddd;
+}
+.navbar-default .navbar-toggle:hover,
+.navbar-default .navbar-toggle:focus {
+  background-color: #ddd;
+}
+.navbar-default .navbar-toggle .icon-bar {
+  background-color: #888;
+}
+.navbar-default .navbar-collapse,
+.navbar-default .navbar-form {
+  border-color: #e7e7e7;
+}
+.navbar-default .navbar-nav > .open > a,
+.navbar-default .navbar-nav > .open > a:hover,
+.navbar-default .navbar-nav > .open > a:focus {
+  color: #555;
+  background-color: #e7e7e7;
+}
+@media (max-width: 767px) {
+  .navbar-default .navbar-nav .open .dropdown-menu > li > a {
+    color: #777;
+  }
+  .navbar-default .navbar-nav .open .dropdown-menu > li > a:hover,
+  .navbar-default .navbar-nav .open .dropdown-menu > li > a:focus {
+    color: #333;
+    background-color: transparent;
+  }
+  .navbar-default .navbar-nav .open .dropdown-menu > .active > a,
+  .navbar-default .navbar-nav .open .dropdown-menu > .active > a:hover,
+  .navbar-default .navbar-nav .open .dropdown-menu > .active > a:focus {
+    color: #555;
+    background-color: #e7e7e7;
+  }
+  .navbar-default .navbar-nav .open .dropdown-menu > .disabled > a,
+  .navbar-default .navbar-nav .open .dropdown-menu > .disabled > a:hover,
+  .navbar-default .navbar-nav .open .dropdown-menu > .disabled > a:focus {
+    color: #ccc;
+    background-color: transparent;
+  }
+}
+.navbar-default .navbar-link {
+  color: #777;
+}
+.navbar-default .navbar-link:hover {
+  color: #333;
+}
+.navbar-inverse {
+  background-color: #222;
+  border-color: #080808;
+}
+.navbar-inverse .navbar-brand {
+  color: #999;
+}
+.navbar-inverse .navbar-brand:hover,
+.navbar-inverse .navbar-brand:focus {
+  color: #fff;
+  background-color: transparent;
+}
+.navbar-inverse .navbar-text {
+  color: #999;
+}
+.navbar-inverse .navbar-nav > li > a {
+  color: #999;
+}
+.navbar-inverse .navbar-nav > li > a:hover,
+.navbar-inverse .navbar-nav > li > a:focus {
+  color: #fff;
+  background-color: transparent;
+}
+.navbar-inverse .navbar-nav > .active > a,
+.navbar-inverse .navbar-nav > .active > a:hover,
+.navbar-inverse .navbar-nav > .active > a:focus {
+  color: #fff;
+  background-color: #080808;
+}
+.navbar-inverse .navbar-nav > .disabled > a,
+.navbar-inverse .navbar-nav > .disabled > a:hover,
+.navbar-inverse .navbar-nav > .disabled > a:focus {
+  color: #444;
+  background-color: transparent;
+}
+.navbar-inverse .navbar-toggle {
+  border-color: #333;
+}
+.navbar-inverse .navbar-toggle:hover,
+.navbar-inverse .navbar-toggle:focus {
+  background-color: #333;
+}
+.navbar-inverse .navbar-toggle .icon-bar {
+  background-color: #fff;
+}
+.navbar-inverse .navbar-collapse,
+.navbar-inverse .navbar-form {
+  border-color: #101010;
+}
+.navbar-inverse .navbar-nav > .open > a,
+.navbar-inverse .navbar-nav > .open > a:hover,
+.navbar-inverse .navbar-nav > .open > a:focus {
+  color: #fff;
+  background-color: #080808;
+}
+@media (max-width: 767px) {
+  .navbar-inverse .navbar-nav .open .dropdown-menu > .dropdown-header {
+    border-color: #080808;
+  }
+  .navbar-inverse .navbar-nav .open .dropdown-menu .divider {
+    background-color: #080808;
+  }
+  .navbar-inverse .navbar-nav .open .dropdown-menu > li > a {
+    color: #999;
+  }
+  .navbar-inverse .navbar-nav .open .dropdown-menu > li > a:hover,
+  .navbar-inverse .navbar-nav .open .dropdown-menu > li > a:focus {
+    color: #fff;
+    background-color: transparent;
+  }
+  .navbar-inverse .navbar-nav .open .dropdown-menu > .active > a,
+  .navbar-inverse .navbar-nav .open .dropdown-menu > .active > a:hover,
+  .navbar-inverse .navbar-nav .open .dropdown-menu > .active > a:focus {
+    color: #fff;
+    background-color: #080808;
+  }
+  .navbar-inverse .navbar-nav .open .dropdown-menu > .disabled > a,
+  .navbar-inverse .navbar-nav .open .dropdown-menu > .disabled > a:hover,
+  .navbar-inverse .navbar-nav .open .dropdown-menu > .disabled > a:focus {
+    color: #444;
+    background-color: transparent;
+  }
+}
+.navbar-inverse .navbar-link {
+  color: #999;
+}
+.navbar-inverse .navbar-link:hover {
+  color: #fff;
+}
+.breadcrumb {
+  padding: 8px 15px;
+  margin-bottom: 20px;
+  list-style: none;
+  background-color: #f5f5f5;
+  border-radius: 4px;
+}
+.breadcrumb > li {
+  display: inline-block;
+}
+.breadcrumb > li + li:before {
+  padding: 0 5px;
+  color: #ccc;
+  content: "/\00a0";
+}
+.breadcrumb > .active {
+  color: #999;
+}
+.pagination {
+  display: inline-block;
+  padding-left: 0;
+  margin: 20px 0;
+  border-radius: 4px;
+}
+.pagination > li {
+  display: inline;
+}
+.pagination > li > a,
+.pagination > li > span {
+  position: relative;
+  float: left;
+  padding: 6px 12px;
+  margin-left: -1px;
+  line-height: 1.42857143;
+  color: #428bca;
+  text-decoration: none;
+  background-color: #fff;
+  border: 1px solid #ddd;
+}
+.pagination > li:first-child > a,
+.pagination > li:first-child > span {
+  margin-left: 0;
+  border-top-left-radius: 4px;
+  border-bottom-left-radius: 4px;
+}
+.pagination > li:last-child > a,
+.pagination > li:last-child > span {
+  border-top-right-radius: 4px;
+  border-bottom-right-radius: 4px;
+}
+.pagination > li > a:hover,
+.pagination > li > span:hover,
+.pagination > li > a:focus,
+.pagination > li > span:focus {
+  color: #2a6496;
+  background-color: #eee;
+  border-color: #ddd;
+}
+.pagination > .active > a,
+.pagination > .active > span,
+.pagination > .active > a:hover,
+.pagination > .active > span:hover,
+.pagination > .active > a:focus,
+.pagination > .active > span:focus {
+  z-index: 2;
+  color: #fff;
+  cursor: default;
+  background-color: #428bca;
+  border-color: #428bca;
+}
+.pagination > .disabled > span,
+.pagination > .disabled > span:hover,
+.pagination > .disabled > span:focus,
+.pagination > .disabled > a,
+.pagination > .disabled > a:hover,
+.pagination > .disabled > a:focus {
+  color: #999;
+  cursor: not-allowed;
+  background-color: #fff;
+  border-color: #ddd;
+}
+.pagination-lg > li > a,
+.pagination-lg > li > span {
+  padding: 10px 16px;
+  font-size: 18px;
+}
+.pagination-lg > li:first-child > a,
+.pagination-lg > li:first-child > span {
+  border-top-left-radius: 6px;
+  border-bottom-left-radius: 6px;
+}
+.pagination-lg > li:last-child > a,
+.pagination-lg > li:last-child > span {
+  border-top-right-radius: 6px;
+  border-bottom-right-radius: 6px;
+}
+.pagination-sm > li > a,
+.pagination-sm > li > span {
+  padding: 5px 10px;
+  font-size: 12px;
+}
+.pagination-sm > li:first-child > a,
+.pagination-sm > li:first-child > span {
+  border-top-left-radius: 3px;
+  border-bottom-left-radius: 3px;
+}
+.pagination-sm > li:last-child > a,
+.pagination-sm > li:last-child > span {
+  border-top-right-radius: 3px;
+  border-bottom-right-radius: 3px;
+}
+.pager {
+  padding-left: 0;
+  margin: 20px 0;
+  text-align: center;
+  list-style: none;
+}
+.pager li {
+  display: inline;
+}
+.pager li > a,
+.pager li > span {
+  display: inline-block;
+  padding: 5px 14px;
+  background-color: #fff;
+  border: 1px solid #ddd;
+  border-radius: 15px;
+}
+.pager li > a:hover,
+.pager li > a:focus {
+  text-decoration: none;
+  background-color: #eee;
+}
+.pager .next > a,
+.pager .next > span {
+  float: right;
+}
+.pager .previous > a,
+.pager .previous > span {
+  float: left;
+}
+.pager .disabled > a,
+.pager .disabled > a:hover,
+.pager .disabled > a:focus,
+.pager .disabled > span {
+  color: #999;
+  cursor: not-allowed;
+  background-color: #fff;
+}
+.label {
+  display: inline;
+  padding: .2em .6em .3em;
+  font-size: 75%;
+  font-weight: bold;
+  line-height: 1;
+  color: #fff;
+  text-align: center;
+  white-space: nowrap;
+  vertical-align: baseline;
+  border-radius: .25em;
+}
+.label[href]:hover,
+.label[href]:focus {
+  color: #fff;
+  text-decoration: none;
+  cursor: pointer;
+}
+.label:empty {
+  display: none;
+}
+.btn .label {
+  position: relative;
+  top: -1px;
+}
+.label-default {
+  background-color: #999;
+}
+.label-default[href]:hover,
+.label-default[href]:focus {
+  background-color: #808080;
+}
+.label-primary {
+  background-color: #428bca;
+}
+.label-primary[href]:hover,
+.label-primary[href]:focus {
+  background-color: #3071a9;
+}
+.label-success {
+  background-color: #5cb85c;
+}
+.label-success[href]:hover,
+.label-success[href]:focus {
+  background-color: #449d44;
+}
+.label-info {
+  background-color: #5bc0de;
+}
+.label-info[href]:hover,
+.label-info[href]:focus {
+  background-color: #31b0d5;
+}
+.label-warning {
+  background-color: #f0ad4e;
+}
+.label-warning[href]:hover,
+.label-warning[href]:focus {
+  background-color: #ec971f;
+}
+.label-danger {
+  background-color: #d9534f;
+}
+.label-danger[href]:hover,
+.label-danger[href]:focus {
+  background-color: #c9302c;
+}
+.badge {
+  display: inline-block;
+  min-width: 10px;
+  padding: 3px 7px;
+  font-size: 12px;
+  font-weight: bold;
+  line-height: 1;
+  color: #fff;
+  text-align: center;
+  white-space: nowrap;
+  vertical-align: baseline;
+  background-color: #999;
+  border-radius: 10px;
+}
+.badge:empty {
+  display: none;
+}
+.btn .badge {
+  position: relative;
+  top: -1px;
+}
+.btn-xs .badge {
+  top: 0;
+  padding: 1px 5px;
+}
+a.badge:hover,
+a.badge:focus {
+  color: #fff;
+  text-decoration: none;
+  cursor: pointer;
+}
+a.list-group-item.active > .badge,
+.nav-pills > .active > a > .badge {
+  color: #428bca;
+  background-color: #fff;
+}
+.nav-pills > li > a > .badge {
+  margin-left: 3px;
+}
+.jumbotron {
+  padding: 30px;
+  margin-bottom: 30px;
+  color: inherit;
+  background-color: #eee;
+}
+.jumbotron h1,
+.jumbotron .h1 {
+  color: inherit;
+}
+.jumbotron p {
+  margin-bottom: 15px;
+  font-size: 21px;
+  font-weight: 200;
+}
+.container .jumbotron {
+  border-radius: 6px;
+}
+.jumbotron .container {
+  max-width: 100%;
+}
+@media screen and (min-width: 768px) {
+  .jumbotron {
+    padding-top: 48px;
+    padding-bottom: 48px;
+  }
+  .container .jumbotron {
+    padding-right: 60px;
+    padding-left: 60px;
+  }
+  .jumbotron h1,
+  .jumbotron .h1 {
+    font-size: 63px;
+  }
+}
+.thumbnail {
+  display: block;
+  padding: 4px;
+  margin-bottom: 20px;
+  line-height: 1.42857143;
+  background-color: #fff;
+  border: 1px solid #ddd;
+  border-radius: 4px;
+  -webkit-transition: all .2s ease-in-out;
+          transition: all .2s ease-in-out;
+}
+.thumbnail > img,
+.thumbnail a > img {
+  margin-right: auto;
+  margin-left: auto;
+}
+a.thumbnail:hover,
+a.thumbnail:focus,
+a.thumbnail.active {
+  border-color: #428bca;
+}
+.thumbnail .caption {
+  padding: 9px;
+  color: #333;
+}
+.alert {
+  padding: 15px;
+  margin-bottom: 20px;
+  border: 1px solid transparent;
+  border-radius: 4px;
+}
+.alert h4 {
+  margin-top: 0;
+  color: inherit;
+}
+.alert .alert-link {
+  font-weight: bold;
+}
+.alert > p,
+.alert > ul {
+  margin-bottom: 0;
+}
+.alert > p + p {
+  margin-top: 5px;
+}
+.alert-dismissable {
+  padding-right: 35px;
+}
+.alert-dismissable .close {
+  position: relative;
+  top: -2px;
+  right: -21px;
+  color: inherit;
+}
+.alert-success {
+  color: #3c763d;
+  background-color: #dff0d8;
+  border-color: #d6e9c6;
+}
+.alert-success hr {
+  border-top-color: #c9e2b3;
+}
+.alert-success .alert-link {
+  color: #2b542c;
+}
+.alert-info {
+  color: #31708f;
+  background-color: #d9edf7;
+  border-color: #bce8f1;
+}
+.alert-info hr {
+  border-top-color: #a6e1ec;
+}
+.alert-info .alert-link {
+  color: #245269;
+}
+.alert-warning {
+  color: #8a6d3b;
+  background-color: #fcf8e3;
+  border-color: #faebcc;
+}
+.alert-warning hr {
+  border-top-color: #f7e1b5;
+}
+.alert-warning .alert-link {
+  color: #66512c;
+}
+.alert-danger {
+  color: #a94442;
+  background-color: #f2dede;
+  border-color: #ebccd1;
+}
+.alert-danger hr {
+  border-top-color: #e4b9c0;
+}
+.alert-danger .alert-link {
+  color: #843534;
+}
+@-webkit-keyframes progress-bar-stripes {
+  from {
+    background-position: 40px 0;
+  }
+  to {
+    background-position: 0 0;
+  }
+}
+@keyframes progress-bar-stripes {
+  from {
+    background-position: 40px 0;
+  }
+  to {
+    background-position: 0 0;
+  }
+}
+.progress {
+  height: 20px;
+  margin-bottom: 20px;
+  overflow: hidden;
+  background-color: #f5f5f5;
+  border-radius: 4px;
+  -webkit-box-shadow: inset 0 1px 2px rgba(0, 0, 0, .1);
+          box-shadow: inset 0 1px 2px rgba(0, 0, 0, .1);
+}
+.progress-bar {
+  float: left;
+  width: 0;
+  height: 100%;
+  font-size: 12px;
+  line-height: 20px;
+  color: #fff;
+  text-align: center;
+  background-color: #428bca;
+  -webkit-box-shadow: inset 0 -1px 0 rgba(0, 0, 0, .15);
+          box-shadow: inset 0 -1px 0 rgba(0, 0, 0, .15);
+  -webkit-transition: width .6s ease;
+          transition: width .6s ease;
+}
+.progress-striped .progress-bar {
+  background-image: -webkit-linear-gradient(45deg, rgba(255, 255, 255, .15) 25%, transparent 25%, transparent 50%, rgba(255, 255, 255, .15) 50%, rgba(255, 255, 255, .15) 75%, transparent 75%, transparent);
+  background-image:         linear-gradient(45deg, rgba(255, 255, 255, .15) 25%, transparent 25%, transparent 50%, rgba(255, 255, 255, .15) 50%, rgba(255, 255, 255, .15) 75%, transparent 75%, transparent);
+  background-size: 40px 40px;
+}
+.progress.active .progress-bar {
+  -webkit-animation: progress-bar-stripes 2s linear infinite;
+          animation: progress-bar-stripes 2s linear infinite;
+}
+.progress-bar-success {
+  background-color: #5cb85c;
+}
+.progress-striped .progress-bar-success {
+  background-image: -webkit-linear-gradient(45deg, rgba(255, 255, 255, .15) 25%, transparent 25%, transparent 50%, rgba(255, 255, 255, .15) 50%, rgba(255, 255, 255, .15) 75%, transparent 75%, transparent);
+  background-image:         linear-gradient(45deg, rgba(255, 255, 255, .15) 25%, transparent 25%, transparent 50%, rgba(255, 255, 255, .15) 50%, rgba(255, 255, 255, .15) 75%, transparent 75%, transparent);
+}
+.progress-bar-info {
+  background-color: #5bc0de;
+}
+.progress-striped .progress-bar-info {
+  background-image: -webkit-linear-gradient(45deg, rgba(255, 255, 255, .15) 25%, transparent 25%, transparent 50%, rgba(255, 255, 255, .15) 50%, rgba(255, 255, 255, .15) 75%, transparent 75%, transparent);
+  background-image:         linear-gradient(45deg, rgba(255, 255, 255, .15) 25%, transparent 25%, transparent 50%, rgba(255, 255, 255, .15) 50%, rgba(255, 255, 255, .15) 75%, transparent 75%, transparent);
+}
+.progress-bar-warning {
+  background-color: #f0ad4e;
+}
+.progress-striped .progress-bar-warning {
+  background-image: -webkit-linear-gradient(45deg, rgba(255, 255, 255, .15) 25%, transparent 25%, transparent 50%, rgba(255, 255, 255, .15) 50%, rgba(255, 255, 255, .15) 75%, transparent 75%, transparent);
+  background-image:         linear-gradient(45deg, rgba(255, 255, 255, .15) 25%, transparent 25%, transparent 50%, rgba(255, 255, 255, .15) 50%, rgba(255, 255, 255, .15) 75%, transparent 75%, transparent);
+}
+.progress-bar-danger {
+  background-color: #d9534f;
+}
+.progress-striped .progress-bar-danger {
+  background-image: -webkit-linear-gradient(45deg, rgba(255, 255, 255, .15) 25%, transparent 25%, transparent 50%, rgba(255, 255, 255, .15) 50%, rgba(255, 255, 255, .15) 75%, transparent 75%, transparent);
+  background-image:         linear-gradient(45deg, rgba(255, 255, 255, .15) 25%, transparent 25%, transparent 50%, rgba(255, 255, 255, .15) 50%, rgba(255, 255, 255, .15) 75%, transparent 75%, transparent);
+}
+.media,
+.media-body {
+  overflow: hidden;
+  zoom: 1;
+}
+.media,
+.media .media {
+  margin-top: 15px;
+}
+.media:first-child {
+  margin-top: 0;
+}
+.media-object {
+  display: block;
+}
+.media-heading {
+  margin: 0 0 5px;
+}
+.media > .pull-left {
+  margin-right: 10px;
+}
+.media > .pull-right {
+  margin-left: 10px;
+}
+.media-list {
+  padding-left: 0;
+  list-style: none;
+}
+.list-group {
+  padding-left: 0;
+  margin-bottom: 20px;
+}
+.list-group-item {
+  position: relative;
+  display: block;
+  padding: 10px 15px;
+  margin-bottom: -1px;
+  background-color: #fff;
+  border: 1px solid #ddd;
+}
+.list-group-item:first-child {
+  border-top-left-radius: 4px;
+  border-top-right-radius: 4px;
+}
+.list-group-item:last-child {
+  margin-bottom: 0;
+  border-bottom-right-radius: 4px;
+  border-bottom-left-radius: 4px;
+}
+.list-group-item > .badge {
+  float: right;
+}
+.list-group-item > .badge + .badge {
+  margin-right: 5px;
+}
+a.list-group-item {
+  color: #555;
+}
+a.list-group-item .list-group-item-heading {
+  color: #333;
+}
+a.list-group-item:hover,
+a.list-group-item:focus {
+  text-decoration: none;
+  background-color: #f5f5f5;
+}
+a.list-group-item.active,
+a.list-group-item.active:hover,
+a.list-group-item.active:focus {
+  z-index: 2;
+  color: #fff;
+  background-color: #428bca;
+  border-color: #428bca;
+}
+a.list-group-item.active .list-group-item-heading,
+a.list-group-item.active:hover .list-group-item-heading,
+a.list-group-item.active:focus .list-group-item-heading {
+  color: inherit;
+}
+a.list-group-item.active .list-group-item-text,
+a.list-group-item.active:hover .list-group-item-text,
+a.list-group-item.active:focus .list-group-item-text {
+  color: #e1edf7;
+}
+.list-group-item-success {
+  color: #3c763d;
+  background-color: #dff0d8;
+}
+a.list-group-item-success {
+  color: #3c763d;
+}
+a.list-group-item-success .list-group-item-heading {
+  color: inherit;
+}
+a.list-group-item-success:hover,
+a.list-group-item-success:focus {
+  color: #3c763d;
+  background-color: #d0e9c6;
+}
+a.list-group-item-success.active,
+a.list-group-item-success.active:hover,
+a.list-group-item-success.active:focus {
+  color: #fff;
+  background-color: #3c763d;
+  border-color: #3c763d;
+}
+.list-group-item-info {
+  color: #31708f;
+  background-color: #d9edf7;
+}
+a.list-group-item-info {
+  color: #31708f;
+}
+a.list-group-item-info .list-group-item-heading {
+  color: inherit;
+}
+a.list-group-item-info:hover,
+a.list-group-item-info:focus {
+  color: #31708f;
+  background-color: #c4e3f3;
+}
+a.list-group-item-info.active,
+a.list-group-item-info.active:hover,
+a.list-group-item-info.active:focus {
+  color: #fff;
+  background-color: #31708f;
+  border-color: #31708f;
+}
+.list-group-item-warning {
+  color: #8a6d3b;
+  background-color: #fcf8e3;
+}
+a.list-group-item-warning {
+  color: #8a6d3b;
+}
+a.list-group-item-warning .list-group-item-heading {
+  color: inherit;
+}
+a.list-group-item-warning:hover,
+a.list-group-item-warning:focus {
+  color: #8a6d3b;
+  background-color: #faf2cc;
+}
+a.list-group-item-warning.active,
+a.list-group-item-warning.active:hover,
+a.list-group-item-warning.active:focus {
+  color: #fff;
+  background-color: #8a6d3b;
+  border-color: #8a6d3b;
+}
+.list-group-item-danger {
+  color: #a94442;
+  background-color: #f2dede;
+}
+a.list-group-item-danger {
+  color: #a94442;
+}
+a.list-group-item-danger .list-group-item-heading {
+  color: inherit;
+}
+a.list-group-item-danger:hover,
+a.list-group-item-danger:focus {
+  color: #a94442;
+  background-color: #ebcccc;
+}
+a.list-group-item-danger.active,
+a.list-group-item-danger.active:hover,
+a.list-group-item-danger.active:focus {
+  color: #fff;
+  background-color: #a94442;
+  border-color: #a94442;
+}
+.list-group-item-heading {
+  margin-top: 0;
+  margin-bottom: 5px;
+}
+.list-group-item-text {
+  margin-bottom: 0;
+  line-height: 1.3;
+}
+.panel {
+  margin-bottom: 20px;
+  background-color: #fff;
+  border: 1px solid transparent;
+  border-radius: 4px;
+  -webkit-box-shadow: 0 1px 1px rgba(0, 0, 0, .05);
+          box-shadow: 0 1px 1px rgba(0, 0, 0, .05);
+}
+.panel-body {
+  padding: 15px;
+}
+.panel-heading {
+  padding: 10px 15px;
+  border-bottom: 1px solid transparent;
+  border-top-left-radius: 3px;
+  border-top-right-radius: 3px;
+}
+.panel-heading > .dropdown .dropdown-toggle {
+  color: inherit;
+}
+.panel-title {
+  margin-top: 0;
+  margin-bottom: 0;
+  font-size: 16px;
+  color: inherit;
+}
+.panel-title > a {
+  color: inherit;
+}
+.panel-footer {
+  padding: 10px 15px;
+  background-color: #f5f5f5;
+  border-top: 1px solid #ddd;
+  border-bottom-right-radius: 3px;
+  border-bottom-left-radius: 3px;
+}
+.panel > .list-group {
+  margin-bottom: 0;
+}
+.panel > .list-group .list-group-item {
+  border-width: 1px 0;
+  border-radius: 0;
+}
+.panel > .list-group:first-child .list-group-item:first-child {
+  border-top: 0;
+  border-top-left-radius: 3px;
+  border-top-right-radius: 3px;
+}
+.panel > .list-group:last-child .list-group-item:last-child {
+  border-bottom: 0;
+  border-bottom-right-radius: 3px;
+  border-bottom-left-radius: 3px;
+}
+.panel-heading + .list-group .list-group-item:first-child {
+  border-top-width: 0;
+}
+.panel > .table,
+.panel > .table-responsive > .table {
+  margin-bottom: 0;
+}
+.panel > .table:first-child,
+.panel > .table-responsive:first-child > .table:first-child {
+  border-top-left-radius: 3px;
+  border-top-right-radius: 3px;
+}
+.panel > .table:first-child > thead:first-child > tr:first-child td:first-child,
+.panel > .table-responsive:first-child > .table:first-child > thead:first-child > tr:first-child td:first-child,
+.panel > .table:first-child > tbody:first-child > tr:first-child td:first-child,
+.panel > .table-responsive:first-child > .table:first-child > tbody:first-child > tr:first-child td:first-child,
+.panel > .table:first-child > thead:first-child > tr:first-child th:first-child,
+.panel > .table-responsive:first-child > .table:first-child > thead:first-child > tr:first-child th:first-child,
+.panel > .table:first-child > tbody:first-child > tr:first-child th:first-child,
+.panel > .table-responsive:first-child > .table:first-child > tbody:first-child > tr:first-child th:first-child {
+  border-top-left-radius: 3px;
+}
+.panel > .table:first-child > thead:first-child > tr:first-child td:last-child,
+.panel > .table-responsive:first-child > .table:first-child > thead:first-child > tr:first-child td:last-child,
+.panel > .table:first-child > tbody:first-child > tr:first-child td:last-child,
+.panel > .table-responsive:first-child > .table:first-child > tbody:first-child > tr:first-child td:last-child,
+.panel > .table:first-child > thead:first-child > tr:first-child th:last-child,
+.panel > .table-responsive:first-child > .table:first-child > thead:first-child > tr:first-child th:last-child,
+.panel > .table:first-child > tbody:first-child > tr:first-child th:last-child,
+.panel > .table-responsive:first-child > .table:first-child > tbody:first-child > tr:first-child th:last-child {
+  border-top-right-radius: 3px;
+}
+.panel > .table:last-child,
+.panel > .table-responsive:last-child > .table:last-child {
+  border-bottom-right-radius: 3px;
+  border-bottom-left-radius: 3px;
+}
+.panel > .table:last-child > tbody:last-child > tr:last-child td:first-child,
+.panel > .table-responsive:last-child > .table:last-child > tbody:last-child > tr:last-child td:first-child,
+.panel > .table:last-child > tfoot:last-child > tr:last-child td:first-child,
+.panel > .table-responsive:last-child > .table:last-child > tfoot:last-child > tr:last-child td:first-child,
+.panel > .table:last-child > tbody:last-child > tr:last-child th:first-child,
+.panel > .table-responsive:last-child > .table:last-child > tbody:last-child > tr:last-child th:first-child,
+.panel > .table:last-child > tfoot:last-child > tr:last-child th:first-child,
+.panel > .table-responsive:last-child > .table:last-child > tfoot:last-child > tr:last-child th:first-child {
+  border-bottom-left-radius: 3px;
+}
+.panel > .table:last-child > tbody:last-child > tr:last-child td:last-child,
+.panel > .table-responsive:last-child > .table:last-child > tbody:last-child > tr:last-child td:last-child,
+.panel > .table:last-child > tfoot:last-child > tr:last-child td:last-child,
+.panel > .table-responsive:last-child > .table:last-child > tfoot:last-child > tr:last-child td:last-child,
+.panel > .table:last-child > tbody:last-child > tr:last-child th:last-child,
+.panel > .table-responsive:last-child > .table:last-child > tbody:last-child > tr:last-child th:last-child,
+.panel > .table:last-child > tfoot:last-child > tr:last-child th:last-child,
+.panel > .table-responsive:last-child > .table:last-child > tfoot:last-child > tr:last-child th:last-child {
+  border-bottom-right-radius: 3px;
+}
+.panel > .panel-body + .table,
+.panel > .panel-body + .table-responsive {
+  border-top: 1px solid #ddd;
+}
+.panel > .table > tbody:first-child > tr:first-child th,
+.panel > .table > tbody:first-child > tr:first-child td {
+  border-top: 0;
+}
+.panel > .table-bordered,
+.panel > .table-responsive > .table-bordered {
+  border: 0;
+}
+.panel > .table-bordered > thead > tr > th:first-child,
+.panel > .table-responsive > .table-bordered > thead > tr > th:first-child,
+.panel > .table-bordered > tbody > tr > th:first-child,
+.panel > .table-responsive > .table-bordered > tbody > tr > th:first-child,
+.panel > .table-bordered > tfoot > tr > th:first-child,
+.panel > .table-responsive > .table-bordered > tfoot > tr > th:first-child,
+.panel > .table-bordered > thead > tr > td:first-child,
+.panel > .table-responsive > .table-bordered > thead > tr > td:first-child,
+.panel > .table-bordered > tbody > tr > td:first-child,
+.panel > .table-responsive > .table-bordered > tbody > tr > td:first-child,
+.panel > .table-bordered > tfoot > tr > td:first-child,
+.panel > .table-responsive > .table-bordered > tfoot > tr > td:first-child {
+  border-left: 0;
+}
+.panel > .table-bordered > thead > tr > th:last-child,
+.panel > .table-responsive > .table-bordered > thead > tr > th:last-child,
+.panel > .table-bordered > tbody > tr > th:last-child,
+.panel > .table-responsive > .table-bordered > tbody > tr > th:last-child,
+.panel > .table-bordered > tfoot > tr > th:last-child,
+.panel > .table-responsive > .table-bordered > tfoot > tr > th:last-child,
+.panel > .table-bordered > thead > tr > td:last-child,
+.panel > .table-responsive > .table-bordered > thead > tr > td:last-child,
+.panel > .table-bordered > tbody > tr > td:last-child,
+.panel > .table-responsive > .table-bordered > tbody > tr > td:last-child,
+.panel > .table-bordered > tfoot > tr > td:last-child,
+.panel > .table-responsive > .table-bordered > tfoot > tr > td:last-child {
+  border-right: 0;
+}
+.panel > .table-bordered > thead > tr:first-child > td,
+.panel > .table-responsive > .table-bordered > thead > tr:first-child > td,
+.panel > .table-bordered > tbody > tr:first-child > td,
+.panel > .table-responsive > .table-bordered > tbody > tr:first-child > td,
+.panel > .table-bordered > thead > tr:first-child > th,
+.panel > .table-responsive > .table-bordered > thead > tr:first-child > th,
+.panel > .table-bordered > tbody > tr:first-child > th,
+.panel > .table-responsive > .table-bordered > tbody > tr:first-child > th {
+  border-bottom: 0;
+}
+.panel > .table-bordered > tbody > tr:last-child > td,
+.panel > .table-responsive > .table-bordered > tbody > tr:last-child > td,
+.panel > .table-bordered > tfoot > tr:last-child > td,
+.panel > .table-responsive > .table-bordered > tfoot > tr:last-child > td,
+.panel > .table-bordered > tbody > tr:last-child > th,
+.panel > .table-responsive > .table-bordered > tbody > tr:last-child > th,
+.panel > .table-bordered > tfoot > tr:last-child > th,
+.panel > .table-responsive > .table-bordered > tfoot > tr:last-child > th {
+  border-bottom: 0;
+}
+.panel > .table-responsive {
+  margin-bottom: 0;
+  border: 0;
+}
+.panel-group {
+  margin-bottom: 20px;
+}
+.panel-group .panel {
+  margin-bottom: 0;
+  overflow: hidden;
+  border-radius: 4px;
+}
+.panel-group .panel + .panel {
+  margin-top: 5px;
+}
+.panel-group .panel-heading {
+  border-bottom: 0;
+}
+.panel-group .panel-heading + .panel-collapse .panel-body {
+  border-top: 1px solid #ddd;
+}
+.panel-group .panel-footer {
+  border-top: 0;
+}
+.panel-group .panel-footer + .panel-collapse .panel-body {
+  border-bottom: 1px solid #ddd;
+}
+.panel-default {
+  border-color: #ddd;
+}
+.panel-default > .panel-heading {
+  color: #333;
+  background-color: #f5f5f5;
+  border-color: #ddd;
+}
+.panel-default > .panel-heading + .panel-collapse .panel-body {
+  border-top-color: #ddd;
+}
+.panel-default > .panel-footer + .panel-collapse .panel-body {
+  border-bottom-color: #ddd;
+}
+.panel-primary {
+  border-color: #428bca;
+}
+.panel-primary > .panel-heading {
+  color: #fff;
+  background-color: #428bca;
+  border-color: #428bca;
+}
+.panel-primary > .panel-heading + .panel-collapse .panel-body {
+  border-top-color: #428bca;
+}
+.panel-primary > .panel-footer + .panel-collapse .panel-body {
+  border-bottom-color: #428bca;
+}
+.panel-success {
+  border-color: #d6e9c6;
+}
+.panel-success > .panel-heading {
+  color: #3c763d;
+  background-color: #dff0d8;
+  border-color: #d6e9c6;
+}
+.panel-success > .panel-heading + .panel-collapse .panel-body {
+  border-top-color: #d6e9c6;
+}
+.panel-success > .panel-footer + .panel-collapse .panel-body {
+  border-bottom-color: #d6e9c6;
+}
+.panel-info {
+  border-color: #bce8f1;
+}
+.panel-info > .panel-heading {
+  color: #31708f;
+  background-color: #d9edf7;
+  border-color: #bce8f1;
+}
+.panel-info > .panel-heading + .panel-collapse .panel-body {
+  border-top-color: #bce8f1;
+}
+.panel-info > .panel-footer + .panel-collapse .panel-body {
+  border-bottom-color: #bce8f1;
+}
+.panel-warning {
+  border-color: #faebcc;
+}
+.panel-warning > .panel-heading {
+  color: #8a6d3b;
+  background-color: #fcf8e3;
+  border-color: #faebcc;
+}
+.panel-warning > .panel-heading + .panel-collapse .panel-body {
+  border-top-color: #faebcc;
+}
+.panel-warning > .panel-footer + .panel-collapse .panel-body {
+  border-bottom-color: #faebcc;
+}
+.panel-danger {
+  border-color: #ebccd1;
+}
+.panel-danger > .panel-heading {
+  color: #a94442;
+  background-color: #f2dede;
+  border-color: #ebccd1;
+}
+.panel-danger > .panel-heading + .panel-collapse .panel-body {
+  border-top-color: #ebccd1;
+}
+.panel-danger > .panel-footer + .panel-collapse .panel-body {
+  border-bottom-color: #ebccd1;
+}
+.well {
+  min-height: 20px;
+  padding: 19px;
+  margin-bottom: 20px;
+  background-color: #f5f5f5;
+  border: 1px solid #e3e3e3;
+  border-radius: 4px;
+  -webkit-box-shadow: inset 0 1px 1px rgba(0, 0, 0, .05);
+          box-shadow: inset 0 1px 1px rgba(0, 0, 0, .05);
+}
+.well blockquote {
+  border-color: #ddd;
+  border-color: rgba(0, 0, 0, .15);
+}
+.well-lg {
+  padding: 24px;
+  border-radius: 6px;
+}
+.well-sm {
+  padding: 9px;
+  border-radius: 3px;
+}
+.close {
+  float: right;
+  font-size: 21px;
+  font-weight: bold;
+  line-height: 1;
+  color: #000;
+  text-shadow: 0 1px 0 #fff;
+  filter: alpha(opacity=20);
+  opacity: .2;
+}
+.close:hover,
+.close:focus {
+  color: #000;
+  text-decoration: none;
+  cursor: pointer;
+  filter: alpha(opacity=50);
+  opacity: .5;
+}
+button.close {
+  -webkit-appearance: none;
+  padding: 0;
+  cursor: pointer;
+  background: transparent;
+  border: 0;
+}
+.modal-open {
+  overflow: hidden;
+}
+.modal {
+  position: fixed;
+  top: 0;
+  right: 0;
+  bottom: 0;
+  left: 0;
+  z-index: 1050;
+  display: none;
+  overflow: auto;
+  overflow-y: scroll;
+  -webkit-overflow-scrolling: touch;
+  outline: 0;
+}
+.modal.fade .modal-dialog {
+  -webkit-transition: -webkit-transform .3s ease-out;
+     -moz-transition:    -moz-transform .3s ease-out;
+       -o-transition:      -o-transform .3s ease-out;
+          transition:         transform .3s ease-out;
+  -webkit-transform: translate(0, -25%);
+      -ms-transform: translate(0, -25%);
+          transform: translate(0, -25%);
+}
+.modal.in .modal-dialog {
+  -webkit-transform: translate(0, 0);
+      -ms-transform: translate(0, 0);
+          transform: translate(0, 0);
+}
+.modal-dialog {
+  position: relative;
+  width: auto;
+  margin: 10px;
+}
+.modal-content {
+  position: relative;
+  background-color: #fff;
+  background-clip: padding-box;
+  border: 1px solid #999;
+  border: 1px solid rgba(0, 0, 0, .2);
+  border-radius: 6px;
+  outline: none;
+  -webkit-box-shadow: 0 3px 9px rgba(0, 0, 0, .5);
+          box-shadow: 0 3px 9px rgba(0, 0, 0, .5);
+}
+.modal-backdrop {
+  position: fixed;
+  top: 0;
+  right: 0;
+  bottom: 0;
+  left: 0;
+  z-index: 1040;
+  background-color: #000;
+}
+.modal-backdrop.fade {
+  filter: alpha(opacity=0);
+  opacity: 0;
+}
+.modal-backdrop.in {
+  filter: alpha(opacity=50);
+  opacity: .5;
+}
+.modal-header {
+  min-height: 16.42857143px;
+  padding: 15px;
+  border-bottom: 1px solid #e5e5e5;
+}
+.modal-header .close {
+  margin-top: -2px;
+}
+.modal-title {
+  margin: 0;
+  line-height: 1.42857143;
+}
+.modal-body {
+  position: relative;
+  padding: 20px;
+}
+.modal-footer {
+  padding: 19px 20px 20px;
+  margin-top: 15px;
+  text-align: right;
+  border-top: 1px solid #e5e5e5;
+}
+.modal-footer .btn + .btn {
+  margin-bottom: 0;
+  margin-left: 5px;
+}
+.modal-footer .btn-group .btn + .btn {
+  margin-left: -1px;
+}
+.modal-footer .btn-block + .btn-block {
+  margin-left: 0;
+}
+@media (min-width: 768px) {
+  .modal-dialog {
+    width: 600px;
+    margin: 30px auto;
+  }
+  .modal-content {
+    -webkit-box-shadow: 0 5px 15px rgba(0, 0, 0, .5);
+            box-shadow: 0 5px 15px rgba(0, 0, 0, .5);
+  }
+  .modal-sm {
+    width: 300px;
+  }
+}
+@media (min-width: 992px) {
+  .modal-lg {
+    width: 900px;
+  }
+}
+.tooltip {
+  position: absolute;
+  z-index: 1030;
+  display: block;
+  font-size: 12px;
+  line-height: 1.4;
+  visibility: visible;
+  filter: alpha(opacity=0);
+  opacity: 0;
+}
+.tooltip.in {
+  filter: alpha(opacity=90);
+  opacity: .9;
+}
+.tooltip.top {
+  padding: 5px 0;
+  margin-top: -3px;
+}
+.tooltip.right {
+  padding: 0 5px;
+  margin-left: 3px;
+}
+.tooltip.bottom {
+  padding: 5px 0;
+  margin-top: 3px;
+}
+.tooltip.left {
+  padding: 0 5px;
+  margin-left: -3px;
+}
+.tooltip-inner {
+  max-width: 200px;
+  padding: 3px 8px;
+  color: #fff;
+  text-align: center;
+  text-decoration: none;
+  background-color: #000;
+  border-radius: 4px;
+}
+.tooltip-arrow {
+  position: absolute;
+  width: 0;
+  height: 0;
+  border-color: transparent;
+  border-style: solid;
+}
+.tooltip.top .tooltip-arrow {
+  bottom: 0;
+  left: 50%;
+  margin-left: -5px;
+  border-width: 5px 5px 0;
+  border-top-color: #000;
+}
+.tooltip.top-left .tooltip-arrow {
+  bottom: 0;
+  left: 5px;
+  border-width: 5px 5px 0;
+  border-top-color: #000;
+}
+.tooltip.top-right .tooltip-arrow {
+  right: 5px;
+  bottom: 0;
+  border-width: 5px 5px 0;
+  border-top-color: #000;
+}
+.tooltip.right .tooltip-arrow {
+  top: 50%;
+  left: 0;
+  margin-top: -5px;
+  border-width: 5px 5px 5px 0;
+  border-right-color: #000;
+}
+.tooltip.left .tooltip-arrow {
+  top: 50%;
+  right: 0;
+  margin-top: -5px;
+  border-width: 5px 0 5px 5px;
+  border-left-color: #000;
+}
+.tooltip.bottom .tooltip-arrow {
+  top: 0;
+  left: 50%;
+  margin-left: -5px;
+  border-width: 0 5px 5px;
+  border-bottom-color: #000;
+}
+.tooltip.bottom-left .tooltip-arrow {
+  top: 0;
+  left: 5px;
+  border-width: 0 5px 5px;
+  border-bottom-color: #000;
+}
+.tooltip.bottom-right .tooltip-arrow {
+  top: 0;
+  right: 5px;
+  border-width: 0 5px 5px;
+  border-bottom-color: #000;
+}
+.popover {
+  position: absolute;
+  top: 0;
+  left: 0;
+  z-index: 1010;
+  display: none;
+  max-width: 276px;
+  padding: 1px;
+  text-align: left;
+  white-space: normal;
+  background-color: #fff;
+  background-clip: padding-box;
+  border: 1px solid #ccc;
+  border: 1px solid rgba(0, 0, 0, .2);
+  border-radius: 6px;
+  -webkit-box-shadow: 0 5px 10px rgba(0, 0, 0, .2);
+          box-shadow: 0 5px 10px rgba(0, 0, 0, .2);
+}
+.popover.top {
+  margin-top: -10px;
+}
+.popover.right {
+  margin-left: 10px;
+}
+.popover.bottom {
+  margin-top: 10px;
+}
+.popover.left {
+  margin-left: -10px;
+}
+.popover-title {
+  padding: 8px 14px;
+  margin: 0;
+  font-size: 14px;
+  font-weight: normal;
+  line-height: 18px;
+  background-color: #f7f7f7;
+  border-bottom: 1px solid #ebebeb;
+  border-radius: 5px 5px 0 0;
+}
+.popover-content {
+  padding: 9px 14px;
+}
+.popover > .arrow,
+.popover > .arrow:after {
+  position: absolute;
+  display: block;
+  width: 0;
+  height: 0;
+  border-color: transparent;
+  border-style: solid;
+}
+.popover > .arrow {
+  border-width: 11px;
+}
+.popover > .arrow:after {
+  content: "";
+  border-width: 10px;
+}
+.popover.top > .arrow {
+  bottom: -11px;
+  left: 50%;
+  margin-left: -11px;
+  border-top-color: #999;
+  border-top-color: rgba(0, 0, 0, .25);
+  border-bottom-width: 0;
+}
+.popover.top > .arrow:after {
+  bottom: 1px;
+  margin-left: -10px;
+  content: " ";
+  border-top-color: #fff;
+  border-bottom-width: 0;
+}
+.popover.right > .arrow {
+  top: 50%;
+  left: -11px;
+  margin-top: -11px;
+  border-right-color: #999;
+  border-right-color: rgba(0, 0, 0, .25);
+  border-left-width: 0;
+}
+.popover.right > .arrow:after {
+  bottom: -10px;
+  left: 1px;
+  content: " ";
+  border-right-color: #fff;
+  border-left-width: 0;
+}
+.popover.bottom > .arrow {
+  top: -11px;
+  left: 50%;
+  margin-left: -11px;
+  border-top-width: 0;
+  border-bottom-color: #999;
+  border-bottom-color: rgba(0, 0, 0, .25);
+}
+.popover.bottom > .arrow:after {
+  top: 1px;
+  margin-left: -10px;
+  content: " ";
+  border-top-width: 0;
+  border-bottom-color: #fff;
+}
+.popover.left > .arrow {
+  top: 50%;
+  right: -11px;
+  margin-top: -11px;
+  border-right-width: 0;
+  border-left-color: #999;
+  border-left-color: rgba(0, 0, 0, .25);
+}
+.popover.left > .arrow:after {
+  right: 1px;
+  bottom: -10px;
+  content: " ";
+  border-right-width: 0;
+  border-left-color: #fff;
+}
+.carousel {
+  position: relative;
+}
+.carousel-inner {
+  position: relative;
+  width: 100%;
+  overflow: hidden;
+}
+.carousel-inner > .item {
+  position: relative;
+  display: none;
+  -webkit-transition: .6s ease-in-out left;
+          transition: .6s ease-in-out left;
+}
+.carousel-inner > .item > img,
+.carousel-inner > .item > a > img {
+  line-height: 1;
+}
+.carousel-inner > .active,
+.carousel-inner > .next,
+.carousel-inner > .prev {
+  display: block;
+}
+.carousel-inner > .active {
+  left: 0;
+}
+.carousel-inner > .next,
+.carousel-inner > .prev {
+  position: absolute;
+  top: 0;
+  width: 100%;
+}
+.carousel-inner > .next {
+  left: 100%;
+}
+.carousel-inner > .prev {
+  left: -100%;
+}
+.carousel-inner > .next.left,
+.carousel-inner > .prev.right {
+  left: 0;
+}
+.carousel-inner > .active.left {
+  left: -100%;
+}
+.carousel-inner > .active.right {
+  left: 100%;
+}
+.carousel-control {
+  position: absolute;
+  top: 0;
+  bottom: 0;
+  left: 0;
+  width: 15%;
+  font-size: 20px;
+  color: #fff;
+  text-align: center;
+  text-shadow: 0 1px 2px rgba(0, 0, 0, .6);
+  filter: alpha(opacity=50);
+  opacity: .5;
+}
+.carousel-control.left {
+  background-image: -webkit-linear-gradient(left, color-stop(rgba(0, 0, 0, .5) 0%), color-stop(rgba(0, 0, 0, .0001) 100%));
+  background-image:         linear-gradient(to right, rgba(0, 0, 0, .5) 0%, rgba(0, 0, 0, .0001) 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#80000000', endColorstr='#00000000', GradientType=1);
+  background-repeat: repeat-x;
+}
+.carousel-control.right {
+  right: 0;
+  left: auto;
+  background-image: -webkit-linear-gradient(left, color-stop(rgba(0, 0, 0, .0001) 0%), color-stop(rgba(0, 0, 0, .5) 100%));
+  background-image:         linear-gradient(to right, rgba(0, 0, 0, .0001) 0%, rgba(0, 0, 0, .5) 100%);
+  filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#00000000', endColorstr='#80000000', GradientType=1);
+  background-repeat: repeat-x;
+}
+.carousel-control:hover,
+.carousel-control:focus {
+  color: #fff;
+  text-decoration: none;
+  filter: alpha(opacity=90);
+  outline: none;
+  opacity: .9;
+}
+.carousel-control .icon-prev,
+.carousel-control .icon-next,
+.carousel-control .glyphicon-chevron-left,
+.carousel-control .glyphicon-chevron-right {
+  position: absolute;
+  top: 50%;
+  z-index: 5;
+  display: inline-block;
+}
+.carousel-control .icon-prev,
+.carousel-control .glyphicon-chevron-left {
+  left: 50%;
+}
+.carousel-control .icon-next,
+.carousel-control .glyphicon-chevron-right {
+  right: 50%;
+}
+.carousel-control .icon-prev,
+.carousel-control .icon-next {
+  width: 20px;
+  height: 20px;
+  margin-top: -10px;
+  margin-left: -10px;
+  font-family: serif;
+}
+.carousel-control .icon-prev:before {
+  content: '\2039';
+}
+.carousel-control .icon-next:before {
+  content: '\203a';
+}
+.carousel-indicators {
+  position: absolute;
+  bottom: 10px;
+  left: 50%;
+  z-index: 15;
+  width: 60%;
+  padding-left: 0;
+  margin-left: -30%;
+  text-align: center;
+  list-style: none;
+}
+.carousel-indicators li {
+  display: inline-block;
+  width: 10px;
+  height: 10px;
+  margin: 1px;
+  text-indent: -999px;
+  cursor: pointer;
+  background-color: #000 \9;
+  background-color: rgba(0, 0, 0, 0);
+  border: 1px solid #fff;
+  border-radius: 10px;
+}
+.carousel-indicators .active {
+  width: 12px;
+  height: 12px;
+  margin: 0;
+  background-color: #fff;
+}
+.carousel-caption {
+  position: absolute;
+  right: 15%;
+  bottom: 20px;
+  left: 15%;
+  z-index: 10;
+  padding-top: 20px;
+  padding-bottom: 20px;
+  color: #fff;
+  text-align: center;
+  text-shadow: 0 1px 2px rgba(0, 0, 0, .6);
+}
+.carousel-caption .btn {
+  text-shadow: none;
+}
+@media screen and (min-width: 768px) {
+  .carousel-control .glyphicon-chevron-left,
+  .carousel-control .glyphicon-chevron-right,
+  .carousel-control .icon-prev,
+  .carousel-control .icon-next {
+    width: 30px;
+    height: 30px;
+    margin-top: -15px;
+    margin-left: -15px;
+    font-size: 30px;
+  }
+  .carousel-caption {
+    right: 20%;
+    left: 20%;
+    padding-bottom: 30px;
+  }
+  .carousel-indicators {
+    bottom: 20px;
+  }
+}
+.clearfix:before,
+.clearfix:after,
+.container:before,
+.container:after,
+.container-fluid:before,
+.container-fluid:after,
+.row:before,
+.row:after,
+.form-horizontal .form-group:before,
+.form-horizontal .form-group:after,
+.btn-toolbar:before,
+.btn-toolbar:after,
+.btn-group-vertical > .btn-group:before,
+.btn-group-vertical > .btn-group:after,
+.nav:before,
+.nav:after,
+.navbar:before,
+.navbar:after,
+.navbar-header:before,
+.navbar-header:after,
+.navbar-collapse:before,
+.navbar-collapse:after,
+.pager:before,
+.pager:after,
+.panel-body:before,
+.panel-body:after,
+.modal-footer:before,
+.modal-footer:after {
+  display: table;
+  content: " ";
+}
+.clearfix:after,
+.container:after,
+.container-fluid:after,
+.row:after,
+.form-horizontal .form-group:after,
+.btn-toolbar:after,
+.btn-group-vertical > .btn-group:after,
+.nav:after,
+.navbar:after,
+.navbar-header:after,
+.navbar-collapse:after,
+.pager:after,
+.panel-body:after,
+.modal-footer:after {
+  clear: both;
+}
+.center-block {
+  display: block;
+  margin-right: auto;
+  margin-left: auto;
+}
+.pull-right {
+  float: right !important;
+}
+.pull-left {
+  float: left !important;
+}
+.hide {
+  display: none !important;
+}
+.show {
+  display: block !important;
+}
+.invisible {
+  visibility: hidden;
+}
+.text-hide {
+  font: 0/0 a;
+  color: transparent;
+  text-shadow: none;
+  background-color: transparent;
+  border: 0;
+}
+.hidden {
+  display: none !important;
+  visibility: hidden !important;
+}
+.affix {
+  position: fixed;
+}
+@-ms-viewport {
+  width: device-width;
+}
+.visible-xs,
+.visible-sm,
+.visible-md,
+.visible-lg {
+  display: none !important;
+}
+@media (max-width: 767px) {
+  .visible-xs {
+    display: block !important;
+  }
+  table.visible-xs {
+    display: table;
+  }
+  tr.visible-xs {
+    display: table-row !important;
+  }
+  th.visible-xs,
+  td.visible-xs {
+    display: table-cell !important;
+  }
+}
+@media (min-width: 768px) and (max-width: 991px) {
+  .visible-sm {
+    display: block !important;
+  }
+  table.visible-sm {
+    display: table;
+  }
+  tr.visible-sm {
+    display: table-row !important;
+  }
+  th.visible-sm,
+  td.visible-sm {
+    display: table-cell !important;
+  }
+}
+@media (min-width: 992px) and (max-width: 1199px) {
+  .visible-md {
+    display: block !important;
+  }
+  table.visible-md {
+    display: table;
+  }
+  tr.visible-md {
+    display: table-row !important;
+  }
+  th.visible-md,
+  td.visible-md {
+    display: table-cell !important;
+  }
+}
+@media (min-width: 1200px) {
+  .visible-lg {
+    display: block !important;
+  }
+  table.visible-lg {
+    display: table;
+  }
+  tr.visible-lg {
+    display: table-row !important;
+  }
+  th.visible-lg,
+  td.visible-lg {
+    display: table-cell !important;
+  }
+}
+@media (max-width: 767px) {
+  .hidden-xs {
+    display: none !important;
+  }
+}
+@media (min-width: 768px) and (max-width: 991px) {
+  .hidden-sm {
+    display: none !important;
+  }
+}
+@media (min-width: 992px) and (max-width: 1199px) {
+  .hidden-md {
+    display: none !important;
+  }
+}
+@media (min-width: 1200px) {
+  .hidden-lg {
+    display: none !important;
+  }
+}
+.visible-print {
+  display: none !important;
+}
+@media print {
+  .visible-print {
+    display: block !important;
+  }
+  table.visible-print {
+    display: table;
+  }
+  tr.visible-print {
+    display: table-row !important;
+  }
+  th.visible-print,
+  td.visible-print {
+    display: table-cell !important;
+  }
+}
+@media print {
+  .hidden-print {
+    display: none !important;
+  }
+}
+/*# sourceMappingURL=bootstrap.css.map */
diff --git a/static/favicon.ico b/static/favicon.ico
new file mode 100644
index 0000000000000000000000000000000000000000..e754f5a48b1782620b743e3e9096f3cd40333edb
GIT binary patch
literal 2550
zcmeH{Pj3=Y6vYov6>UXE)Y_^QwIKEH!^+B-xG-IsRKo}821p1bEJ!hF8pFzjm8rF@
zDM1Y>(l(}c0}D1Ju%XD>9qAWn8j@Oq2;Mit0A-M*Cc5fL=HC0x@4k6&?qUEH)X?ko
zl>1;&0cHS3BWSI~XD#rIJPUbx?$g8jxL%1-3Y>9mZRJs~*OAZXvADQ|FB^4Ot>c)V
ze@EUojEvSXvGEwu?;phe&L9YahEWg%gWYcB*)%0Q=h-F*FQhyvu1!-CH%$8N+?Vx~
z#Ov22*%R~78)@0dOC)Zr#^0}sK=eEBbJ#VXlaZb$^ziwKlEx*~G)u0zxjB?dB}{yM
z1eeQ&<>h7gd_GK1zeFODz}{X7)!I+QVlm9j%wS<*fo8iU&ereuBOZ@qc6JukY7Lv4
zo5*A`D3{Cddc7F46|uIqhGMY@r_+f_rGjWQitX)f1cO0@LLr31VXUmIAel@eolYZ{
z%fan-qgJaS5{cl`$G6zo*@4I7LHSo1G)$yYDeUg<BAd;^;c%c(C?F6BV1NGy*4NkR
zzE$btj^fb-jwaA^0=hO?!MLsswRx@5JRnjYPPN=tb*G6LL(7({ha6wk8;t$DxGvjr
zR*~6%MO=*zGiJIZgGRo=m}aa|pQGLmtfSWtG`(X=ewncoO)e<;Mfz^eIXQ1qays)C
zKcADkj9qBHt5MveJDoW#a;t{1`<+~OlNx9*kBs#xux|V~W5Y5Zd7y02S{O4o_ABqF
z?C<TI?Zkrz)roZn@!+AkVnbI$tyXvSW%J*0dULzv1Dm-WQr-0BqBp<YXzR9<&`Dcw
SE+3-%!~VbLJ%0}W0saQKoa2-L

literal 0
HcmV?d00001

diff --git a/static/fonts/glyphicons-halflings-regular.eot b/static/fonts/glyphicons-halflings-regular.eot
new file mode 100644
index 0000000000000000000000000000000000000000..4a4ca865d67e86f961bc6e2ef00bffa4e34bb9ed
GIT binary patch
literal 20335
zcma%iRa9Lu*X_aGIXLtH2X}XOcXxM};>BGK?k>gMi@Uo+afec%&=$Y_zI(@iAMVRd
zMzYtMnVHGh`(bBgBrYld0G2WU0R1n+0{)ZW{#ye8Pyh%N;2)-_`hS4`dHjR_o8s?3
z%Kr!aAA=Sk15gC$0aO9906BmJKn0)-&;Wq`d1e4dfc3v(2XF@106hNnKnJJ;tp3?v
z|4=i4`#;17p#2YV|JP~<aQVjr0oVY{0M>t*4IuDO^FK=e+xx$$?LVd`z~aAr@Bit+
z4B+|46aYB=Q+D{L`5%t;Kdt|aZw_GpXL0?v@B%pgd3^uI=KcSkIq3hHHvk~6A@l#d
zDHwovCxFWvz!d;sGQ^&}h@CLq(3!MVaFhSyL!rg*&d8F%X_&hML`QYBTiRZ}i=N8C
zfX|m2SCm$2B^?XKJ=3POS<xXNB{p2XXK+_wMOGVZnBZVi5e}6Y|6&<yQ)U%t_?I)|
z$UxGPI3f<gbzDcS=uvd*F-hJ48@*B~rQ%a$ce$2W*h2m|CL*EzQysJG(21!-486pi
z9Op(2E~L-}(eO7?`oQPh!vSmW(NSH=-))ZKL~;2xY%vBbW>}r1sVM9Nj*l5q`5#S%
zQ}FD^zy1Pj*xUGOm4;*C;l80oktO?~%SdX8H^8@@idBFWyOINSr_!xo{REWRlXgw|
z3-(h5XcHaEdPKzyy2-P+Rljn4lR?IelEOtWLiC?_9FW&x@kpuRtfsn*-QLS4E<Fz)
zG9ld#Bnh;*Rbk?ER9!Ta)FqrS7@C4{EAs~A!V%DK>oN{{q0u8pt_^hD_!V);D{hen
z-XpV~5QeQTYTIl1+B^5r72`!7FRQQ$Jh74=Gm*OkaIoNUC<v*|(E(8Aj*LvEM{1C?
zyZ{#C??5QU&iBe&ZNxqGYA?UnmFg=wgvPZ$3)LsZ<b+4p4zbj9^8U=85Dk&+ntVHr
z-r%wsOFM1J-)x^j=IMDx@M(3Dm-KN|ZXVOBlKmw$OFqyu(Llh8E3%Y~Y1Zon!|%`h
zMcSPk^tyruyKs(okWegQr7FUGWbEIh%zF!S#n>7!wk7rRZVuVK6urnp@}QDpB~9*S
zkVWg8LyXz8-%53>GXb$%*H0(bqkUIN`Oz8g=bse?bAumC8`5XqA+(_y{fV^j(1$BZ
za*@mJ(&?Dl2k;8tW}O6OaavJE|17u#1t>M^0!@SDJc2)cLZL`m7!-)74CQUXoksM*
z9m|Sjh}@dm-Tnc8<77&TfjT<DBnM~uOZbdpn&3nTeG7&uB2JuE_!o?tRkNOzP3&=A
zEDuTrGt7%gwS6eHB2ZxuiO)~H$16mlbPgX8`65kyA_0q9Jew6Q1?oKNFm36(NeDbT
zyoAZuFs$gjT7S+q9g&=H<@4}a3NYbc%Huc5)Gu8~{PLXe11y!f4`DxY+GU7$<OPgI
zKA&H2TehO}XUXyf6XLWE)!&2|tW?qu6)DUjXH&lLih<2cjkXGyG^Kb@F}{FN`O7_A
zha#<!6v2V|85wmU=0->6H{3)kXMM774`D!eA0|(<upEfJww;oFGKR9TK`B-XFHDiJ
zgfovK8YC}?nt?-yJ3&V9yEw2GTcsxSag$w)zxt#lHbo&aNr)yz=t;gG@-99WW(#3&
zouaUeY$ja)`Gzz_iZln>RuQz@iQO(4-7lX|aK*M`Y=f%R{_&<<ZCpgesc!3o%>*A?
zB(AZUl6JXgz^9c9q7ZW~Lpncpv1I^6O4mGX@3P^Q)?jBgx(f#RD_4y0q5aC_beGG>
zn%RbEy_vdx`sL?|Jvlgyxal-}XM^FDQYp|Euiu=%8o(=wic+XSimJ4(Adn3`QH6^D
zQ}H@oBN{|Zg^2u|@8c~h7Kv&HCx??xy^J$3{B0{XnlrThDaoQqjXjXHi#b!KIjA7(
z$hT;Ah_VP&j)(Z6&(xn;KF3rHsF^A#il?$)q4Pp#sly?|%OmoRG|MiNW3+)?3Wd9=
zgbUjzTLX+!G&oYj9P;jnHmT91qKPzxkj@>rsqi|=M5$PfrRCY%E7${xLDZFtYcC%k
zorpLj$T65dN+HV@=yRlKSS8W~SMxFkK1~U-XW2@DXcG`4-V)z|605uD4Q{MP10fD5
zc!T#)n57))zXXfg=dwnZuD_`DCJc3cHE6HuA(>36o_neqgoF0pRK0eEc~{rD8%Pfh
z@dtE6ovkazKj3fd{)*&tB0YA^1d^^?2oeNyB7u(P+O4$@lCNc~%mb5iP)dLGM|z;x
zEkRYM_^U`g%s5j<P^+nOOTy8^iNh+21HwPm!4tDZXyB_m{E__A7TT$++afF&z$%d5
zdbJfD%=H6{Yf~cV?+Rzx^RMpdNs;Rbegf65K#JCFs?Aj|Pp-_KSh;iZ)`&d5KF8sA
zSTK1}bE2=(sOE}r@EuJD5`xOEryD%18G?xM;om|M5-F!#&|Y)1#1=-H$E8L9ld~*p
z`={=|ZfPBqdY-{($JY@KNU3*2U3j;NB|GEwg&yTp_<`fG+2#^DECE%f(&>iH=8Q2h
zlS%BdC6DaYEWi0UNhnc*zFT$fV`4_VMNU~nH;q(Ld?!#lIvm)K;W_4C(l3+4TZ=QI
zD%siB%cY+Y7vMFM_KAg?sxm(^nJsMIV?v|vAS8l;zotv$#Ml-Y!n7|X5Y5C)=TiGZ
zQ+=(9%lk0&L&hDtwRD=Ua6wQeS{g2mvwc>^|4$ot-2Hi`z)|V$N{mNAEZC3gw_8%z
zq(L3Bcwr2gin62<CFE6*m7X=38JYv0`R+-1aFSbE%?6(FH>dXM8cG-D-auD7HayLz
zJI2|m=8$F?Ko>v@P4{(W5g=}-b$%tJgfywp`6&A96|Zx{9N;1@_>hto7TQf3EIMm+
zJ`;@@4ycXnHM>|iJ?FXkWGc8YuGviO&L*^ajd+vyLIxAAT{isADQQM5S;YP+jAYp7
z3E1Nm1HDd%SXi``NR*so7XidvRPj#BM7A`S{cU%VISQOhrMLr08;N36AYg9}40Ml#
zU)GUxQy(D1%P`@`HDaXn&%m8`hOu~_2a`%P{v7w2;KUNhll)N(y4wD#p#{+($uLOB
z!X;K=sci1erRm1=Qcx#ja(r=E8*89RNH8`C7T4|#uVRc=Kaf}0Xw)>8g0(4H!ZrK^
zh-Kf(V#NQcMU79on9bk?`U7eI{Nu-CdboLYH-7lJI|7VCob2872$p->3n)-J>N|b%
zIn3vzKet~nvHB=bP6rDRV|&&4LL}S7`iu2ok&r8ecw~yUROul?44VSV3;<PPWZ~5!
z_|9gZYsa;uPFf1MZVUgTD4Fk3FD8RN+a+VIvQkXq2WiEoh9-D5rq2+~kYwFByFH0V
zmHBgwt2=Um#HqKIE8^q*HOkzSb3#IJqMAe+j8?%H+JkNk9xlmNWT?fmFz7?eR#L2R
zp($LHR$)v1K2`$HpZoUZ#WqP3-t6C)MpAtsT1cc2)CUfH#!oyXo<noD#b!SlX%D&X
zhuWjVqw@fXq<RZa15$&L!{AKrHIJFY`&jXv7?sAhaU_dse&o*RNB(ip($=~<v#*(~
z?lmG+0~@igA~er}*y6#PA6I-!k;^$fAg#%n>z7qSQWl+y^cX=$j~O<Bq?IYYtt*Av
zr`(RTVdzagmx?Srl~9;7Pzk3?abKG2R}WIw<Z=}$WIZ}_#0FlU31&cp!!iS}79B$!
zH<OV9U;Iy3cs0)u>Q;o~0+_)5WDRF0^JbuD_umr4Mn$EPEyB-_e<pQ3H010%gdgQ9
zH0;sXO{u1bNMkXf4|e&kIYW{QvjZ>og^1*P#Ui}dCDH6-GndXgi$XV2SNHe#HHQoU
z`2f{kT*~Y-Gtyd}I#v=*PbShJzp4hgaK>cr++;2GSGr7^2gA_3H1F;=<l9$`^knte
zpQ^;CAfUc8JdE2Jgu={Rs`bMCvm#r_W3-mRiZjX=QJ@T*0UVz%hey|>06B{L4@fTs
zD?F!vb_51Hnzb3BJlYiI4qZ5fDt|CaKX-N&2aP_DVX`bH*FN93cV*3fPvociz|dFF
zDI@_;;4`*j9yW7pmnXjE<g**}4Sp!*=R~NKa2H(U*twWCy6bfcYbY3I%V(c!2|r{7
zY31<}TcSMa)NDLaz|=u;BON-McI&lS$B}9Qio7;d+%{vkxIcB`O&Byf=^ODKX}vXE
zF{&$m8RE37?XNMPViooY02Ob3_b`fD>wqe@BEQw*5Kcl$=zJxCo$}$5>0aU8*UXir
zlo6vuHSn81M=rz-M|tYukSa7I2M$#Q-7`8&2-+UvW25@8gOf1VSR}3RdVFr|-&}4T
zky0u`XuQc%0#b=LJWu5hm&cbB$Zk<Hwb(>2FeYD~v-Cc92u|%sI<e~IKs@PAPBFWb
zlR*CsinQd$1x+D9hF|0+awrW08Mg>Uh-6<!tT`|@EG}TQY7ag)w=g`+g5$LeDEOl*
zhZ0f(LyYXxp_<HTr91$1QKsLh42R0!XSK4JDUG~Y=w5Ju2P=rh3jA{D(CfDrtt6bq
z!!67fVC;8^+g%as8;~hF!vyz}g%6k#-(ash9?6;-)s}HWjB}Z3&?dxmQsg_h>5dJR
zZ3)g?oGWe-H6(Dl5E)k2)Hal?$9R73FM9`l`qB^<^f4kuce&|T)yCo{^=_a`TY*c$
zRRh_284jJjLoW$Wjv_@n$8LbXuW0pZw;g`-3$XUHD0Me!pbdD8z$3+L^KKYOabFdl
zZW8&J8yRWfjLh?e7QJEkgl<&QwDnZ2^WwgBH0{AjxI^@Q)51nlGRVgj8j^jL0%{L5
zg~N&QybX0(ldaaot?}x4%vuVeTbZ96fpg*k(_p?a+IFGn!YUuS;~_Z0CLyGFeQ=ow
zhS}^5R4dLfu9Q@MFw7c5_Tg`%mq$XF81YXSFD~rt=E6o|lVBQmHpMG(*<)M(E(4f*
zifS(;Yjenr?~y*l>F20zQ%mciliU45f-wznJZdw(tS7t6>004*2#X3Ej3pco3fi`a
z?|gM_ckVQxZ*D!nTeU<CtC+)eWn7Cp-#HuV`z@+~X*h<KA_>+|gbdPEj(!rKUXu)|
zkLqUGanZqn25Ek?PHa9%4W|%Ad_<Af42^|XZBP@V-(-P{AzOtc=k{RfE0lAHndD3w
zCorJ5w>2AJ^C4ZsK(9AW?d?fe_y54j#ceCX7%ZMmS`{x=_0fcCjb0L>U_D>5f4kNy
zHQQg5@4aYV)6gpTnv`z06M5a}w7=9Zxp`bcn&i(EOAPWj!?Z(2O?^DESnGfRDGcs1
z?IvJ*{LKonl7#robcFc@OJ<~_Nrt1&v@ePe#wEFKMxfTA!AwJm2~n9HG8Q3?YR-Yz
z9Qm3kx|c48;)6Kyoo?<`!|@@xwp~u#ofuQm>ip4bLvO_8W)9{2phqI7{WR9NLgJ5S
zHO8hXtJ(CY)mUG&o(gGo!3Qk!=#XUS13O&o{vweBJ4o1y<~#&5^$s69ECV9xM}=+2
z3!NJW8%Q`f_Ja)nexErX5!VB@V=TLVghSEjRt5vdJ8zuRg0R+Y>(Wb*7ED)es#R7<
zyy<hf-A~;fzE_Vhzy_lJJ_hS5C_Fn-Ys8&4`90}V(U6AdcX;ahv0V0|D$%GVTo}%d
z%`Xq11N@_+QTEFC8kq^^q<^$qHbz{`pXRyMV!^rx(?*Detg(%?lJ-%GNxD*UPY)8T
z{zwpVSO1CZ4|w*uRQ(o0TX(GnCrSa6xB9WZTTVS+WF#0<=gQ&#ApBqkhtln9(AI@3
zPaBm+C7>j>az=m}1XQ+E7Z@KG=Cs|{!+EejQ_B-7_Z_Y<Xf-uVv_(PTS2Sw=Q4|;&
zgu$v5i<{QHHtZ<)O|z_n0Tow~R##jqG)Ko>;kETxVVJOayFzr&scDu#RzsdT7?ZD(
zjt$GiPqMQDN##jNA(UuHMgjopqE;pkUTep+3YhG2G!BnK?~X#v<ppz1GopVhVk~iJ
z9)J}bWR2N4McPD8cAjR)(es%iC15{NvDk*ur_>(Hh{G+w3pu5aBF+5$)Hq);#9CbG
zsE7UhKwvg;w*V(0K7kvgnm5CXt2oMK#y!&dqW6^CO`o-9h;rpe8sX@M7vdNHrSI)y
z9KlvS+@+-`CzlS3h}P)VbJn)MN&1rZJDgsR=F2FHZMpd&S1VRKi;7W;=|X`v`iwr;
z6={w%x(Bj(^(a<%?7PB*S%}>sft}U!!qdscsQgT@3X5WihmLBxuS7?1$@SvvJ3<<|
zt}Y%yqH_W&6!_(na-jr#Zv7W*Cu#c6Hqr$o{eMTHmIWfcuI+rsXc1x$ibc)|lxs`|
z^lhQp&^b^BTL(xEI!6k8bxom-D8C}+6_a%`?CYjSuFcEh5J1&Y`Z-6Dj-I`%()n$9
zg*b<&Zs^xdC{p2ab~}fxiuobr7XT7pIefDq+B0S-e*#Ncv}xLJi{{yPWu)?Esyu0;
z1qsK_FAEg-C+$p0cp*xgs1s4btkM&3lqqeQRpD2eomd(OP0Q@*e&Xas38amh5^boC
zOw$(pnvN$4MdoQ_u*a%EGU#34!L8h;hCq2qu>vma`dr@6OJ$uR*Uy0|v+9(q#{vUE
z-6#WJn9K=D1b|=3z9t2tlyis<332BeH7r+zY@~b=^WA5yu<fPm7RjBbbuqrcXHVKv
zw+nPMm=KzG8)-dK<z$0Pt6Ui8{T0zsuyDZ}B`O{xKE&IvZtp6*up2w)J@gX?S9Oqy
zCS5`6J&kx=5j&$*J^v(F;@(WC?74P&!ks4Yd!<9(*N%gDX&Bc(3)tLgvT;OY=1_7_
zj70d-6D}2OF$6th?$0z7wX0p7u+;C=j&lCgh?r{D&rp#NcC$1?MZ_dJu}SsqkU?TK
z=qE|t<m4~g{3P3t-VJkRb}};PpGkMyk%<t0AF^a&-6ybu*Hu`lNpdM4WcezZTxb`5
z-XD9Yjn)34Aj}!N$N3;qy8Zh;9^Fq^`$_SV^f`B&XF-t*4w<;XH?t?0elq8<A8Amp
zJB%m<lWH91bDt*zIu{w2eg|zT-NtNe$TFe0H-^%;M}@;qR(|m6^w76OUUF<!bkYMc
z^Sj0z`C&>vSMiyU=H97SQ7PJ=xDq8^5h@!5s)7NwIC(^9c}UqFKh>XnFPu|+L@P;S
z3sSA!`G>+GcF}A^nfl|n_2P=oi#0>A$BphJo^niV$39q>jBn7=yG3jodFC|0-)C$R
z@AvsPawzRcdI+N@#+XCUhE-bV6R(fb0#L8<{kZo-bBF0d_eb2=Oq%CRy|M%BGBmTi
z*(vF=mDqfB)Ffbr1WObL5rtaXXn7h$vMIMyd!!E!)5Fe{yHa{ZKHpGwQ9J-@cQ$OX
z8Bux&6WJ%|zF+jJZ&(g-&u~QV-Y_~q?DJ>#3~9WiBeIU_uh)eb{b{VUn_K9kFfYXL
z#W?5L8z;XrA?Kc&ua35Hi_uhWghl9)h*)J}%wG+Xnnp2ZOl*YtK3VQxUMfBM+z>E2
zeI`!tBDijjXYxlLEZu<O@O=5)cfidSSht6%IB`qR^SRi%>7t_T<~!mR0{o>6W*Ejr
z6v8z^G$W!dDq*^y$WbyhI)x}-s>tdk0<Cc3ioO1pJ{fP6Y(F$trRT2*j0^mu@xips
z)8yfpsJ|GZpA*8m?W)5OAKs486ubh`#8%{HZQ7h)9%|@<)1g|^V9S{Ud3i&m5k;ry
z5$istivD`~Kx@|!1j%2HedK9<<`!dy4v&fNjAM1C$4sWcKL@Zey?!dG<4WO6w{&}5
zgKHE4{N%dHQp5v73Lb9fcx$k|yQz_nf&<E4Cf8EsIM1uVvPU&jMv1jo`rnnb>{-;A
z91U?k6Rg*%T*U)Uv_P<mYJ~IjZKh?I?nr?S?oQgvx#teX-mCJ%f4hb>P_}4jhJ6|~
z)$B}m4(d`YtCBcrVbz?cQGo|NhMK(@OnGsU7<Jm>OAKgUB<ntwP0|xtI#IR3rhRUm
zB}lRG%Hqg|8^>JLh?E@OO@sfUG8M``oQbcDgDKEy^t6!AhE@HqgSG<3Q{ND7tH!G1
zQFCZgl=Ykxr~0pdq)`n2y3~Y0cvkO5i!CLTAc68-9cOMi2c29BTcg!W5=XzHR68tT
zH%o4w$B?>YF0Aq0w*Q@DIf|UyjajcxO2`!Av{p;s2#z_Xfp*{$2fM>65~br|rCyhX
zcrN@r4!w~3imlj-eew7qq8d&vtYnSAT9&|&Y&=~}zF5=-5at@Gr1s6~`eBk{nJh+@
z#(=xEI>c6xXU(ucS*a_!ww@WYvo?~@3dBjqAUH~h9mW5q!R#);8l<ku!%jS!9Y6-o
z`uOWoJ&>%8+oJnb+-ydqv)LHQJSgY=p%{@~Fk(V6=o{<5fV>)fPWOyXSo|G?G=*~>
z?z><)(Ss@<re!j_43?Cd9-d~0STy;Ikqe~!)>lE|vU-2vhORxCM>@LEx4O{!kmzI5
zFUOuOX^BHASj%#FATqS(FnqPTp^|Sq;eg3wKvIzUJ%FNpoCY`^OPv(^>&j{V#RFzE
z@3Y)bA(4m_iaS`J&gG(v^)Jth;W$iESCeCBA1#B(N63V{dggoJ%RQn}c>a@^%gazJ
zI$Shg5<N22t2lIl;+e)HfO+hN<$(&_ug@>yVpcpnJOOWY^dBUI=3iC>#a1p2NQs|b
zgZHukR9HwV8Sgp{#+jN7ZB3DI6<m99=;3fkN{smAXFJsq^M|0vAEBpFy_o0U=vD?t
z?zmE8_}ZmDiu0CYKf!?6jGmiuXjf_hP<2fs8IP)4%~i1W79743#nNSJ&>~hIHv@&%
z=$?K2gzM;xC?K<9N0|-BMSk4bLI)uB*!ugfY0qP3R%y5O?&{Xfzojfbw?zj^P+_;e
zRVm>&GsN)=H<Py%__i1^7|tOxuE&!af_os_K8Kc7^4GqKwMnuX?hv?wl+viMTYHy1
z?Xzc(PF<I|uv`C8l-?8wk8jGK;dR!zb`y5%6?tXlXrqPk_62k72ki(<(YNuOTrNj!
z2{9#lK#um1_upuZc=!#Efe)@&Et@FqiEbt6$IpFhlCiH1Gp6VMJ(1r+i6Sv;hob#<
zBWHJD^gTk(__$MsTj}G4^QARKgAd^4W6~cYFvhAmio;J&%K}-3N%2UhHR{bme?<_V
z<3O}lC#vJ^*)+_=d4d+GQKgkUzBbI~h1D8#2}eLNbb<W;vcdQ3dBlXk4qd*5P85k^
z^<d`z@}nh%>BH+0BHxJo&ckuL8w0=_w~q6R{ghxeMmsDh;9@n%VFE`Zx%pQglC=A4
zmJFxIgNwqP)8^b#RwBGP+eI;wi}{^<jUT6)>pYMTtQ4h21k5DL#G?TZ4VCjrqHlXx
z5GWyy1)M+9Im*H1Nb!*p1miCdMHEs>^!0KnPX60;FztLJwN}7vh;E>|7i^aSKwZPp
zbmc@;Z{n(|)caxrl1<CFphzpY;P}JW9V&YY%V}bcpLg7B{&;!0Wku&3Fh)b@+WPh3
z%uyrV0vM2R)&++)NU>Z94YDTS$mif`TC>B#m4S#$l?uReS>1@v!TRjv$vg^osFiop
z3Ec1yBx|_DM8|$B+gdt2+Wo8>VSiOZMk{KxbsETEqXrMe43bz3J;k2|bk1|VfW}}N
ziBRxsE0VSSOf}i%^gY0FFMldwBHt78EjW?Hs`TiH)s0WX#E(VMU>!x(pRNEl0?(%d
z(09!|c3J9g+xi&)MKNr%Lz~VacC(%gKWoY@ID6_>a>(E=mVmuqrKtH5d$d}xX&NeD
z5RiuBXo9`O{xL>+V-49mRc(3kT+>qNP814Xc&F=6k?M%@t6NOb@@_X`d3htI>|zGN
z&z3d$7^TV;cV+eyHCzB+pyNz1atbYX3gZfiSjHB<0Ehv&M)7xxzlJu32@Iosx5?qd
z-7Ka#WS9+1pr}6b%d2z-ZT+Fzpf`63fy)jTb-|y39hX-WFKTi7kn^+4(;QJI%l!pK
ze2L!7r+ad0PfD2bsar6XgD>XWJxwwoHCORf9r0VEIM_<BWND<pEI5=QaS)gGF}@1R
znH|v!Z&(5!-9pejNy+g(h8$6$1Y__L`z*OvF2iqdO8c)js=PclmH;D-Cnm?*f^>qM
zCzw=0@8aB8TV{tjzE5zvR&0MR>so`xq~rHSLBuI)mS!Dh1{CI~)~Nb^?^R@Gb*0A1
z=&MnM%PG*qmrKBjp8ZIYS@DFDNwe5Ww=2e65vs{7<p%KtHF2F3Blir)Z<5b=;%pun
zKrxw#sJ%83soGV`tbKALGcfhXP8-ZWTi4{o)mVBuvW!BuyJ`KPLF439_<%%#bA7Q&
zp72T9-<8K_mT$v9&)zzxLEMqBt+Tz5J=bB1W1Otu2VF8Vpl>e0?Ou*xB{?A9P$i{y
zM|4xJ3)%!G%8d{u-AC5&>)0?3EeMgln4Yut1`I~s-Cl*~G*Ri1k>5}JY295;&pq@-
z#Lm^4Hp$Vz)X?2y^sW@;*ClyG-%gBU|LBB2+bG$zX%YcrI$cSa$$Sdz2EBDDiX$!I
z{_-)%I3e)hC3KOBqNUpTOsPtReVV3GD|?sDzlE<cZB*G{Ydue?ezLGN{6bFMbmW-r
zw)Q*vo+foQLpFc;$L~RxkCGuIY`BhQDYOu%dzULfTnIGlI(s4wBDp{&G1YN0HvYt}
zCpFsDioRlY8MeBK9Wmi7dm-f)XBLIb%nu6Pv{6I_7UT0ATHB|WAcn{TC`PxUeWV-*
zhdK9<bP{mPv`$gSdL#zbV!LWzbq4pNn2}y&iy`ogaY?A!C5r`8Jcp0<Zw)3EEN-~R
zLLW;)Y6+&JsViQ4#!(yp6a<>Y;lsV>UYEWf_58h)t*RN0JkrGu0p9p8L{s_RPwvTR
zXR9)eJN*RNMO^RZbZOXGNdieWgVSs&xvqTIv}1x>vCDtEk6_WWAVXu?Nu7sREv!;U
zh%KMgdA}u72`Xz6{1nx8ud@3we5$9_>x#f2Ci}@h{1$Fh&}3<tbk38~&rUa<5)0^F
z^Qb;FS*o<SguKe@X&a1LVx~X!UMwbTR)aw`9oiQ*f`d)}`LPRR8bdG?2mL4>CiF{d
z+}gjEHbU-5+06vi&lbqcVU4dKyM_2lgko*<ReACrRdJ>2LU$@58M9ER0>@8%8{Q`H
zM^pmfKp*!)YkLi|P(GT%H`-^=EmrEUhQ4I?ux{(gb8Cfs3Y;=$r!4-O%2yn10(6sR
zU6x<wcSlR3=Xy>mo^&_$SnfCEbTemLPST3#%z3J!5Y}po{ihZicg?6_ADfUcz?o1}
zmJxCzhnNT~o!=vhmRTEXGQ4OT$Zvhr5{5Midj2y-p}oGVqRFwQiNxp#2-*sjF6fsF
zV6X<GK@F!wePUU;7xT5>hhsSL>wR!QmL`QcBPeEpof>)1LNkZE`AL+G5)@6qC>qR!
z8+){akxki?kaFfX6i}pXp_`Xlck94~S-?9*q=QqL2z=I4B@Zvi@4?yJho3QIdNI8l
z#4QKGd<)2;6Vy;X#e*x_gP*hHWyFFgqukOJH7ndQUKry!7s+}S>|FP?VT3DlK1qQQ
zk=oA%rP<Di#}0$a?hQK@^jNC2+{{nOa{1-JuGN-u{`9VO-+ywu6Afn5!+)vInz}{!
zBl0(x?R(%zB>%@u3Q)BH<r|^Paa2MPE=FFo3z*x4C<&P&<>2;)Li&oL3#M*r$!{Ih
zASM=(#VCobo1BhR#*@dO*~PX)#gN9<0l;rNRKG4|p!^Nocw@Iy>-~ZJ?0T#CqSxD+
zevj?m@H}89TT2L<6HsC#BB(?}DykVK9k*1%F~}N9y4KadeB)RvJq;@3pmQntjRuyp
zd+bH2w#~~?gnNl>cBMwx5@vUCsl~4k*^~r4aR!EORAjW02r1eGW<}-vIl3BCwVUEw
zh(xbpj>h?!;M4gDxV}8^il-Ur;r34S_`LeD#vXa-JKk@`B;%!=m}ILfo6GC<dZvO?
zS7(QZPL+pBE8);iH4PKjVa_*y6Zt2g>RP-vnwGMvS1TCwL(fwPc-To}O1cyV3K?4x
z{_{<Fg{d@#rjB5}AEg<^=qEQRpIA97HMxux`4p1VPC2C@z2faqsTOl$2-|+8kh&a3
zbrd^IFP)$co672tU{8;er@;7LZqm#|XEur)a+_u~rnVETrT<E4$EH3X^TuOrTC%TE
zc@b^#eTC{a+k)_}X@_ugF0$jzW7TGbtt}NG>-<pm*;sEvkI76dH5uivPuy+3TYCiF
zwZQ^BDoqoqsG>2*jZ}zOd{hm(Z%1afi9LPcXUtDSf?C9Eh3I80lt-6uc=&~q`FuW)
zKHDvFXfegSj8LcxD#zUuF<lZDwF2cd8MqiH=n+}$F4<UvUKgt0VO&vaIwj!MS7uhG
zACQ5QGZ!fEFC+eW0rja@5v|a!zf3zhNh5MRk1)K$J~DKxqme{)-x*>PYuggI{ZvI5
zj|TJPpX&$cTSpufZ23uYl>m#4Uva-%N<10wTI1Mav~)-=p+fo(j6RRxz{*!Z9U-)C
z9>Fg)gf&-?LrVVy@(_wx>%nb~#fWvMjZ<K2yhtV7T(tpP?anusB-trf%NM~yT`jjT
zXZIu<$DGmp{vWQ}{T?~D<8bi6D`5!o9MLFX(azod6iahGu?|%r7YXp_25ce!<7I+z
zdr{_0jli`OqO(qQlE6cRj6Z@iI09z^i-FLJf@3klwfN=mcKQ$BgEcHyT&a6QkUR`R
zU87{V`XVeB{1EP08nE9gEL_AOTa!DXuz4Kb$(mQC+Pxt4fxasUtoF&`Ad)0uD`_l5
zK)gSH0amD9$|PSYwtfin-1grFUYRKfPB`eBpeP4ty`~H#JB8TnnzwZhx6zx_dgbFc
z^{$LTcfHng8ZMPA?lTjHuBs>~3snIE4PjYc%6*#^HD>*h`@M=No(8gEO?tGG;DGL!
zIknN6VVIpLepd7%^9kPQ=@m~$#G`d&22uBd7N`xiP7nd~8%zL8zY7$6HJXuC?e(YU
zo|ZhfFlXWkh}8`aNOTEuicNS}80_)bI`FU)e}Gw)H(>SGZcAB2IjJ%f(xjS0D3g$f
zpKWvE6C}I95gE5ucsGJw!I(^u@Qq2m!}b62JC2|pO%)yPHM(i^a4hL6s!^uhSYDQ(
zs6-SU+3-3w$KoVN{lR=H^hVSP#<mTjt&w+5$(ctAUFxIZurQIiFcp;M8%2K_=Jv?_
z>EnRfCNooS9%oP_bri+sHqLwpN!J;gB#HbCT*wP$kPMWfp>3s$!F>BG0nI}(tOBcS
z`;|a~gZLF43#h#S#h9K<bvS-?439-?rOv?zBZqMoDO)8m(}QWECutrkfa?*Is@T<O
z_&jfAiFL_!j%tT}KF9GMHjvg-?(sD}e=&tm?rVzY0?dj#$<o98aBEy#sGWl@eCQ&<
zuX_2pLGi*8F6sN!-M$d5HTXuHH7~<mrr&q;EKpi-9-r4=cadSsugA<m_$nj)<xVdu
zgqs&1m0`|;+JE0lmQkS{2ZC;^gkmx&$+7`Otgu0UZiHf~)0;bg(clJ~R1uB9MW@DC
zS@iDss&sLFhO!7{zhcsBzjs+@Tt7;tY)Og!98tADI$YXMvWgm#G8*hgxmNa9fI*96
zAZ;`oqa`)sTa&j`De_`tYY^rvf?alzBdN*1Z(|Oq?^I;UU~5GJs2RpVO9_Ehf0fp$
zcg@T0?@Ov2V8mtsTu*c{?^jA!5T!4QcbYZA&ul|HG_K^p2({}{<g=QyIA6z5t<d%Y
zpo8Ici{k$tK^<S*&i#bS1t?OxX@XYVA`!?fOl@4jLKa2nq8w9Hi1`ZXT<{1_<QZML
zRE@b95tIwo8q>-xNW62tdPsD6m#K0iM?V&GbYaL+Tv1R7X)gj~#SmUb78qLnlqoP^
zSe`gkIP@zojM0&GO=h@|U1Brj_A5+?CK^Vl?qgjE)=Mo|Man|gckYv`pkbSNoKK!l
zI{10#kbR9{p%uRJ4wx<2MtMI>or0N#cP<&(WR_(NRzrNObQ6E4VtUzc?fH?Q`SmTe
ze9vOyJ~XZ1o3+9UPw0YlgJEIwL%gBxaQO=tjEqDxu@8q>P<_RrX#GyAh7*w=e!%zM
zvmm+X4>-{%3kZ>L>`>A9e(Oe^W8*8imEKjvrX~B9Z?mF4pdgAW0GcqQ8K?PWbOtli
z6v1wXRcjUM?UkNSiRv~-lG&n<e--rauQ9#NC1=FP*xvXf62yZe-(g1=ElX!ljP>=6
z$-Xti>!AZ`H4B7vrP6?>0{7UrywB2v>KcE_pW4LIO&E1X8z-=<F0PfslW&!6IV5+!
zqWqqqE?X)B5Y}b&<wa2KA9JTXGe<G0ugB@Y;<ejIkgztLNM19ut6|sb_HD8hD#9IR
zuZ1RpHvx`Gnn&<8O^IGc@VgbIQf$R*xJF2K2GwkBQ*fheO4?L=A}&V`lHnt_b~1QI
z-9r|Le#_eOpb9T(7PTra#Um|&-^9k%7*eo6v7!P3xFzd<lp2A(tqAu)E=A~N8iM@H
z<u(IP)cNtI;C2d$PE~U?M$<m<v1xYiZopLT<`<Z*4xM#2-p4g8L85)ah@e;S@HNA|
z=Ol8NurlG_jBO((r<gie1VCws6;hKp*WIM*YybG(ma>J<qFb_5pz}6L?%UnRtvEMt
z$pjZt++<)(td{kmU=tnslLn^wky>L#R3C|YNnMkc!*60bMHvnH<`ilEG%{J&Fe*%+
zjTZG$y6;1$L>`qR_sp}wV<hTsgOfV;QwuVw7e|k8cB|9Nf;n9Hbf?HHIQP-fE$pV1
z#JkN^-|$Xv_HeIllkdMG_H);mUPU)3zG7&CNP!iDh>!83lNr^{s08V1fY$}RtDBk_
zY{PKqIRP(E+njlJ>;-Ne9DTE9Yc-7W#!7e7F3YVtOg2yK#&M<)w#4K*c(bn^FnHGi
zOO53p1ce|18`isRiPy2)Cp&cXWCMewS7U(<3?fr$6<2fP(VAkoOk?Mn;n6cy6eoEN
zcTNR*-IloNR3v5#qTkK~&Q92!hf<Hg;5*feGaQW9#5h~%v>f@mt5?U>fQ)(sn9?kZ
zoELH=@&o-m=!`QtVP*4!Zq3MI*C)c*169O@A6{Sw1BrU77bX<7)o+B=OKOT3M_qUu
z)G%1v*Dw$3!{WTWe}2o~d*W7}{itvohqK!zI4HNk!NALAmrWckmSUmNsWC3}z589I
z?(Ph?T0sx*T5P5eOv%MYbRzUJ)6Kn!@@StdaavA^up>Bu#v(VH%nlM5iNgY!YUrMi
ze_F{-tA~K?Z+>D_Z`ea`+x(I<v}`yjSJ@f>5S4r<h?^0#X=%Wal|me=zQo6%Ws{Zl
z=}+-u8|cSCJ!T@_UYH<%$YX<TRjg$Zl<$DRvW$!jEr@(;cl8%tv5L0M$dqu_cE`17
zMI9u>c!$&2G#xZi5!P+od8TU36$-U+2lUz(G)^M=`)XHCub}p+?s<^N%UM4vVLX!W
z3!0^;2XT5crok6h1={vUZ6hmQ4N20z`>5mfN}W4i2ah$KgcnPPpEs_(#;Q{)27f<(
z*y2iflq`qB-OJXu(8w@R=)->-a6|4bNxNMnft?20HkuCy$6$L09kd)G)W4O=9BM|{
z0njynOnyNaTVrFARb&?Wz)KO0c=aeIrmJGdj2T21U*d{=r&%WGB_fB}!Crdq%$!h6
zTYHZU91PZ_u6~E*gTy3XA#JV7W1QF6sjN;@hLE{nCX07QHTpvH15PaG$-!bfNO#d#
zL<U}`Qn>z-yQ&tSY!D@K{1sPCqy(XopWKKD^Su(X0yAdtrAPbwvb;0KzwfBiTWK|Q
z=@~d0^<3M_hSR&Ce?AW}16N8iRRYrnJD8B8G!k~7@GQoI<#32mT-zRtY2CpF2f(XA
zMU6CkH@0EN1UN@jBxhBao0Y7;t{jc1e4a+0fB6N7b2yPo(8A@@2haBnasAf%nJCjH
zql`!qJ9zbokA$A+Li$D^=r%*k928%W0a#o<gs&`x3@ms*43R~6)ynuL*qETxc54Nv
z^pBjRgAQ+@bKw`5;mQ|kZCg0Gw@KQe)8%EVGk1lJ<f4_oO2bud96F<Au}P+y9pZ5_
zadu@Z;OMTx@X}Sm_JkwiZ42|}V<KTUgwsLX9z^4Jf!Wc-X9FRs6DjJM?42@;z_eC5
zUJ21(owhni(My_rYDNMIf>K{oyi-%i#({q!i0)WJ1(aFJgY*$gn{8I=(Ww04qI1{H
zye0i*Mr`~uq|h*1yj(Kb6ltw^K@0a<ye8X(oRqDde~yan6YYyu-Fn2RK#X_5K=Ppq
z-rpjOTr`I4OJ;W(>m&(EmI`#hR*0ct8#{B~3BSz88+3Bzg4k81*^8%KE#*02QR*UK
z2M-^JFu#z+ux)Gj9-Ypn7I{$oQ)oL1`l&|nToNk4Tamb^hRS)nuoZIEjHOtFqfhay
zZUTan1jXVWhNrTYA$UlLl2*5w4DdkB`Zffs@;~cY=26uyjz?2T9bVi&2sRpcJQEc}
zsw<xl^KlN5{CdJGgdh3YfK~~bf@i6+a1k`1n_L0^rf&!;tv*PXSF_&+QjFzMV+z*{
z3z<A(vf-IEV-EC<-lk{Xp?}FhdX1TA65X2fDfyy*7Pf@qRpgF~XW4FwZNf&>q*+P-
zDN^CmeDw%s_1+%}Im49+!#OjZ;j(Q*hfk#Bm}vcixtLUk-l>q@`BV7ppOrG2W#Z%&
zW()~2c*wbgWlG&}uVk<U0$Y?beTsvTbSNqYPCD97tBNC!-8~e57?YUrlBx*ZLKn{g
zcBPw`%8s^Su5C+b#GMET{v_#pq(#hqKNXW8uxJr!mWcI^<`7UR<IWE}EZ{43a!Oy)
z$w_WC9xi}v>UND;LEy@?#C{}77N~WYzz)?Az@B@SyxF&QfwgRVOOn%0aye75&&}>S
zzXc$D2{D5sKzp?kZ^aDn`*nF+3|f|e(o$M#yR)s_4THwu&3vi*JPwOBR)%9|cQ^)g
z4XHCFEsKY{w1K@z=AIAvPKl3~tb_^UIhBwmBDl`00~fq=Sz&xh<>PA2hJCH!hGwUW
zSgtprf2*L$jmE;I<{4F(Ggnc%YAXfr=SqhudnSKgbgU~un2Z{YIR{ZU&<I3x!^_iT
zd6J4u;Fn@-WyexQ3?V<(Usett3C++vK)`ux$MaZS7UG<_$O=<e&c7X8n$ReU`wY8q
z?n`O;^Nm-AThR0xjbj)g0!weYObHM-BE)A+;z{bkS&M>6?3OUcSLAaY@eW`eEgpt7
zlUlHem*R=;T?P@87+ei=K*i)c(`M7rgYp~;1v3UAroT0zo2b1J>$(E72e7wJRJ^j+
zfwa{lP}t<C*rwUgoVd5LVnEn5EM1ks_wbZY3vFSs=#|3cw@9}Pkfq3AF7h7aR#sC8
zxsEs|MsOzJ5XuyRfK3#A9}Un2qYDGT3x>eWV2Cat(t`GRp|FvPh+q_fqDrDbm_Mgv
ze11tcDh~Zxw+#nx2(x{He?+>B8}7!V`sarmVDe6{$$s5`AD)NF!*)Lkxhe86X@8YJ
zUKj5XynC5Tkh`933miE2XeIrq<MiFpQF2nV|K7lzL|8v?M%9Tq9N#$?4}FL6Wg+_Q
z&7!?a`a3PR^Vppce;!n(2=H?W$eoi0I?xqdaa3c^+-`wjPE~=QkHXl|{#vtX@JW?i
zB5JNRT2b-_T&XiT0qbrq6QHR}zG^P5NqGXJt;oz71|{K&DhM9Ir`H>#2DMX^k7QLZ
zL|1DDSCs`<i3V58E^0J|R#1$}OU0%k0x2=+r9qmGyp;oHYM`NF)1jh)l72Hdzrom>
zP~b8wgEc_A<xbya)Vd!S=|g{ht(CM<-QT2nCjNC!N<IKNg$GD@Nl&$+8B<w#gr&v}
zT|6x%)*c&N2fT08Y3}X<u6EZ~PF0uq^+nk~V}Ct|FYMzCJSx0V+;g^m;m^E!7peET
zY%Qs7kF6Fas?fDhC$E+Ztz1K{)updBt}gJdy4Wh$u}{gb=J&2F-zq+{58J7}cCO*-
zu8FL!(66?!uhPpYYqw9>KuOkS68=kJJcC!<yf)I-%phM1Am{Jw6V&AVcK9geu!_;3
zNztZCv>LEhv(jc*PJc+JDJEZntc9XnDeon^R1KS8VypEKVS=!F?4_G(KTNE3yww1&
z<<4Fsm#(W&-EE|$ep#8R2{KX@^9n+)nbR_CuKu2`y-?j&_Et#qL+_J4;tN=2WAJ?_
z>GAwa1Ld2`rz_J{-N+hUE`7D?$vACB{U+#Df4rK7HY2#|H7ad3`gquCdhAM5`64&^
zml&N+{;t8*A@sURFNd(28=x_y`ZPiZmZ*JTwE@14fXfD|h6GL5)jmGBn&D0L=Vf@m
zCfsvhVa?!2*QXbkyXRHMl<ZCH{j?F+zPGq&hEgSZ&=(wb@UcLs>vIPVI=m<zbw(|3
zh!~I^EDuDbU<H%>yUYfFf`Kvx;HNNg+~nfLnniq{U32A~2`%1Vz|wmTEs2e$)WSRz
z)ul1TY;;WAQl)z-Kdg2cN`8In{^lIY0O)kQ^I2SoQWf~F>*MJp!pVm!TB9y-tC8z^
zo;bCQ?{j%6p6`I;Hk8t!SYr(BA&><YJPn!Vfv_1bci>}DrGx<Rk~V(OXz^s~%l^1L
zNs5F|1DJoS9X=rV^Ei{UhI7Sa>g2UYggV|Zk#`Og7%@FQAPviijGoxn3uBn010T08
zQ!nF<YbEU>ZtP~|hjSMd!(1+p*Ez!^!t-}`5!<GW`N3w9{opB;L!0<0{){=Qf0!sd
zdJZ21P^{l-D9VyQS)>O{-R&*GB$6p41JkhO#U#<lJ4wKTdjsZpyVjnYBjmC3Y1Abb
zL}+_=q^VTKFx|qWC{qo9C!}CNsimA{RMI-G`?I>f{uNj#66xGL$#dz~=tSkpT%4i1
zgjkQKiEa<V8V&OZfnTe+HLLN9bvb%P5(qZD6th4Q4psZS0g)$^JCVnlr2=1=B^pnz
zHkEjoK!<?g6-lg*C<~Q_JN=V#vDjAEP-wFaMHVVaIw_Lp@ug<v^HP_jA`H=G{$EQ`
z2?MstlR2dsX5Z5S-G4`oWRj8u>nt8(H)O7-+8ZSoA)7^JvjbKP-NF5#si838FETR9
z{>F}aEty|AxCF?_9K2a!PCD&{mLIaLn~rY9PkVlT{$&jW-^9L(DZPjb!3!(?6gP<p
zSnHDlJ|Ei{)+mi-zA8QS{Uldi*T{fvj~1f;;~TBD5&0tcY#q@+SKR4<>!oRptb@n+
zj;Sj1EzP&rTH|dsUF5T#cGro6G4AR2oYP4A6C$$HZsMhb-}MgVJ|9Df9nr7lJz}vl
z148Mpnh9;=>i)2Bv@-|m)b&vQU&MMd0hk@(3OOg^&bfmPD_5YKI;h1GgnmUyKMvNS
z*Dl@jFEe{GgQYV82Q5l}U@Y#R&i56es!fO#KF~6>m8^j5_VYi$aL3MIurDD=iV!Y#
zw)C$KqzsWw6ml!_bkB58+Pnr)j72yJ19dZ;QpeC@=Ysqc6~m1XlxJ}t=Y?#A9ovZP
z4*s&io?KSB=5X_Mq0Qr!nZ-97Pc{p8>NN2hw6L1$?|*wdwE()u@GV+8cRmVu4i|nF
z2YCia`{H&dzX+@+F~z3}&2HZ~A$J#(3rizQU8HeGveHLO?>XOiq=P#{F`>io&|}#}
z+qQJb#$=b8bg=Ps!<e=*Q1NgtcRPDjv(skV{LWDb2qM%@0jkAdR|YXU0)}J-VZ(VO
zv{x7b=rlg@Lz!+#pLF{TdI%25r;P3_tLf~a<1m~dWu^)9X|!-0660VwNc|xU#^vge
z@^(9+jgIL+eQIJRI$f4Bvf&oE!3Tlij2W+dFrJlUF}JLwhCMn|&0t0&QiAZsfXGG{
zjVgYBHlRRYDA$rq63PP+5>{v58DK!Z#EWBz+L4AD9zp%|)i>xTf3e{0+~^1&1o6#K
zwr3ZRDa!hJPfU|eB7lm6qeNDi)%|oq=$rtSjhii9m6^WZH{st=9fQ#dhr52sEKcDV
z){U(4C-G#*1B4TJGjp`CK?-PIECS&zl`y!FXqtN(X=qEa*gBq3^TFm}Cpj!<Z{cv#
z;p5tQI%$Z$20OlQviaF0JElDg#~SU^X~`l_pY%vASZ0xn9S0Yw$2u3igP1lXelC%Z
z2*Nof*G5IpJ`LAQfra2br^_S`U+d$_|6|HwCI3FVcFQm=9DfPaw@B4Y8{dT0y+k4E
zlgVOJAdU3x>nLubX7V)$@?A?AU0HyDi|)^#d;oP?m&OB|M4~*^s!BC_{@R=DqVy`)
z^iz3jFK^wAHbnd?@;r6FdFZxmHA=CJY>9NY7`vW2a@8_3y<&DFpgBkW@T`=eFK8oO
zT(y#eS}lrO`ZBfcPaK>$9u2=+_Mtg1J;2yBN4^5}D8XEx0WdGci3PQk{1UaB<UE<p
z8D`qI;@`ZcO@RWg>gCLjA8J&l$QM)18CRi~T;S54ZH(@Xo~$ZF&Js?~!|%D|ZX{Jj
z*pc-L3P~#WkVf!P51DxQ^K}CDD=Y?hNA?;=vpqJIB;E8g<Grx~XB0mj5jVCYFvz3m
zozDa>GMv4?>|>Zb{znXRL*?)Qk_|}2j?T(<E&w89hKoiSXZPI-lh9uBE~nB`%*8Y#
z0*Mb7{70kelul8q(i?D38kQ;^)BGIT#K;2Gc0O-)-=R8XhCD-fRvj!KI&~!nB-tRG
z6%kRhp-(a38yn%fxx|3}2(9<WM#3p+PG7FznDP&kSXY4la!18Kyf5=Ze)I7u!bdJ(
zu?5bwDq0yf-U=#2@w}%y&$HLPl6$#(8-eKuK@GsLtjyl^z3cs%=|~N9Fg8@Hk?0sO
zFcH?lo!^oJ&7L(?lfC9U1Xsda3V1RB)6)_cQU>SeEif3wmvZ0!0BKWR*&#M-@We+n
zd!Y-D_)%BP<+!zHM-WgMA-<|E26O*5#V&wF-H?7K{bi0t!Ja@<#T11p`z7kR9bL^I
zxiX|bgk@gG;U~e3#Vwfd>bW+G#e;04x)I0s4A&VgI(Fju_0T|cY>fvK^f~+n#M)-I
zKA?@0B{P@33F-*DS_^ETL0XcaOIRdDW5V4B_zY`Nd?M#7>oeG!Z^6Ba-dCk{J;lsy
ziiSUhyO+>s{C7)Dns`2Rf*jY`gHkmU5gRa2MLAKjTZu0mAO#oAut#vEzYF_C!?|MG
zQb|RYeITrDng~^K9yR@$=Tu)pB6?55gtAr{5~EPTj*pnXeR>Z%m;6GME0_TE(4-rw
zME3E8f@iqWlgt=}U9DMBcpA3%b9qbF|E~5M9NWd;*ghbr%TH)&^)5!yC%XZ`v?wJT
zr0zUE{g^+XtUw(U<CES&(3<db-ms$#xRyo&i|iLUnwfO!GBc62%3?D8j2l>kwXI0C
z{Oks!jZS1P^C2&m%)dTuRCl66MJ9OSvo;iOkk@*49_fS4UK2sIg}$oN5`T)WV_j~$
z#*y;(_hW2|toQ1WCxQ6-vCr-?6*3i$CB?T(Iy(Uu4B{Jjn3Fs5)HYKiwn<7UMvAhM
ztl~cib)k*j3wl0-&k>Du))lCI$!YL3LpY?I>g)lzF_iS&;YrENcF9<pGPareaKQ_u
zk;9qaZ5X`WZ}92U{WL!Q3MCp_?{n!Yd&lr1)Boh%g|Xxi1SaS4j?y{-XsDM?QC&ZG
z1C!MO!N?iNJ%CMtP+Z^lbl9d`GfLmgia1Po*<g1)0qa?4#NUk37pPWwGKaoPxaGKE
zlC=XR0&?TC4_PvoZuC)-t<rLGRTQ$iP`5hay$5HoqRo_Na|Pnr`tU#HHc07|;74Hj
z!qm;VWU@G*IT(xCLhhak8R26E?%PS0ZvBuA*UK2NMgLa-ln!h0y)n3$^pz2`t8-vW
z_$nTKKXezOjOw48006+*nwmFJO1`#&fdGWCiqkD7sasUfz;_pVMBcRwH{1}QD`~wD
z3f{p}D|=i$neFMFyRFp(a3=Mu7kqE95mqL_urHCyiPQ)u55VgID%`}l`e(;=enO4K
zO%min#Pd)4c^Ha7g-73~U~Y*Re}w@G-v)?<N(pl{g+kn$^z->RH%gj>X+U<l5{R#i
zeRb_z)DtHChjKhzSXdd2hJuFVx-!?UZ<{Bv&F=~~Smfx8c91VFSwMcY!r~gQh;_4J
zOUX5)w190A)A~Ii(mm$Wdjz7+@!Zbw)y`;qFC#onmdMN*Scb&IMQx0<4lOaVs8c46
z!IMGIM-vi&2Wu+U&QQ#StkB27f*;S9WR3)~LZK5_XE#vZ^VVau69ZT*OE>NtpO7cW
z=y9bt<!tR_1N{UV6(xx*jJ0I+P{#hKL*kwh1!Ez^Yy~o>%UHUm14b%KvB>fmkT=b_
zigd)xBgK2#{h33=bql4K;;83zkU~UB12jdN28+Nt#W^PWf(SsT=lZwNXYAXwH8p+D
z2T-wD1`6V}x`JJU5)g?l{KfbY3U{K*jkF9_;!&pOj7b7b<4O5g2XbEfm_g;#Ldp;i
zD<HAyfJD^t!cs~WCSJOZK#3RVPGsup88C`7Rf3=cAq^6&T7fs%O63r?XE~yi1!mA7
zna;{J9Qkw1-3UMA0wD%}%n!-Y!Xj9=+iWqffz)Qr7>-*QR?1x>UX&lEA{7w}jiYCK
zu00NA=#@F<vg;mbDp+u2Cm`^pB9D$SuF?1*ev~tQ*g(VAhomo-nH)TCcp+8*-Yg6!
zLi{f4nxX{d2{LSYa3e26(CocWi^ygemrkhSURI982(!+05zXQl!4QP&O!;PCt+s1Z
zWR_PxUi3&Yixw5M8nCHkDg6_=f+hk<NnN9L+cM@b=#dgGpHK)@8o3Tu8lzbqo_cep
zfkrzRw<d0IDq5HAtvFClU_=X?$v_a?KO=Yoh36u0OxZ$S!+WUQ>mB`CEgOPGL>*m*
z6L!@dqJzFD(40JE-qoB9C0HFL3|4tOJ91pPVZFhw7eu;Rz0}w$sh&XNz#XOq2TvIr
zi{~9k7L7M7L#!M~crc`I6W5)r$aG3}pV7pj%;E`lEP-KW&v?w!L}n}ma35b;S~Q7u
zWn6QD1W4v?bv$l;!Bx=gbOuF)QJieN_M$nWNG4939a7d{0~7Bj<(#O7(pw&_f1Hi_
z;$$f3(K$+laQ-ssV9rcZ7sUxH?h(ODxMpu8`~q0R@3V<5ZUR7N0B>X7i^k1P11+>c
z0#{3cU70M%f?eOzWe+MNx@4`<J(Dw-w@YU)iGhI=G%cAjvj9+hKt~smnz&+Oe@r!<
zV6?O;tlzihz6-JNHINBuQ5fDw>O6KfNE}>-%Ay*gOP`j%nlT#j2qpj#<ZF-?C*ig5
zk8s^+=$=7F69S>O3UrUg4^id>oy3kT*kQp^XA&x9M7QbcQ+v;w05OGe_zv}@RU3qi
z$Z4Z<QLq}U0KqK8lA(HvUg?_>BchBcVa$fo1DFN}YOT80bTTwDSQdcHnV+giyD-Lt
zKm&qZyc%9CTM%PKoN%g{XgsPsNM}kO0}&4>JwWdya=9)5Ash~^0(uV>M^ySibGCwz
z5$PN+Ml%p<d(<uKY~w&;a`wo<<>$>JJ^#x6tLs0KGyLupO&M$44kv!@+P4tPv-(Q)
znW!s-B&%<X1rutuz;h!IMzv0su=E`}4cMUKQY-DkXd~rMVw?iG_$~;jzM?dERP5pX
z@Y#?cvzEl%35fhKmUs0)0Sqmu3AkeDVMk@C6hoiH97G5`0^;F&iLxet#G@4-dX>k8
zp97OXN@#wwog-#6l6D~%M86snd|3)a+4OKr(u$6rle32G24##}>NW&kj7TOs3VXJL
z<NyvrA~J%pX_!2TaZ%Mn4nO))0T5>c4+@7K%h<|@DEF@-){fDoU^iaDFf32}t$^lA
zpl+iL|J2M+g9i#^{QP|PQi<;e0S?)xbB1g1_`<>Y)*w#P&y}I!c21Uq3Lc<XiLreo
zCi(N(DRN-CGN=F_tqsA*{+t+Vy@iPEhscS5^dUHMT)VyoJ8lf8MK)z>PcH;4bqI0F
zG%ZQswtudr3r3w}tQ`@KXB^ZxMGFdmidyI|W43A#-3$(6N2%hin*<U#`Vsw|3K*e*
z+Xq8pJwmOUD0D<I**m0DZ_Ezzaz5l>4IsSIG5R3xLv0o-OG?OH@C^*jHSMd|)m^=k
z8q!UF2K{Nd9S!5tX!S5^0(g18+nY#vy3{(tRE6@P4?zeK<>TM)kmGd_VPnQA7kRXf
zk$~)TlH+gOn7m=j2vbKXB-!<?3w3xF`M3AFy&?>=9II_qaR7Fbv(Ms=PC#2#w`w#W
z=rj4$Sqg431ZfI;P81F=%2aAK&1MMC_yLxuW9PMtShb@O%)R9~IY2N4HjJUXmwXHl
z=J7qh5e!n|i23lJ3Aori$qjbqY+@PGGUPbj6mN#$9u42-kWv1HK)Xf*7du4zI&Ap;
z+W-ZUfh=WXWVbD>z!yT90&Ktv@`?P+^ljzwm*<EOSQ!YkOiVo<Be{j1h`=k}S%4(M
zeFL&?6~d#gd+G70xDqLF@j_G33z6kCr3QxYN_Q?~t3=z>P~Gn%)O?gB<ADH558H4S
zE5cL+`0b!oSp)CyG_W>56rc2k8*yqZ<hgU@nH;7{RA7%vVjvt$C^wM09t&}apn3UA
z!L9@*O|!YI!hQ<rU1vA*#s^oY)!+}EJcLz(c^@;wOG6E9v7#p#04m_B3DD!iQ5N{d
zjARRIM%n#>4@7nX_L)j_!4bYw280A2s4z^0{)=R3vJz7Qz(N>0jX`Il$M5BbQk_^?
zmb=2DwO)gQyg->t3JD)mBx;B)gI6cNIfElwxl5wF%+%+FNg$PFXf~%ubeSK6L2;*k
z-ZS~l5;+l-wl6{w7Dyq}{-FV>Nn6E;24mwA6(n)DhTzooXGRi@WQFLUlc&&iO=I^T
zivywJNawc^=E=0XFqsVRR01*<Ms0+Qte(862=!p!HfwwNy3sm3nig*3uWQ6)M8nNw
z;zr&c4RH@kO+!!ZWJceGKI)c54md@nvT_ox-E^9HF1$yC=N5RO`I|yDLuRLk5~ld=
zav}M<1ZaB)`08RK$`BHIa9Y#Zka|vJvMh>cO<5HEij|eEmVK8g?IfsAJNmq~EgQff
zwRv%UW^p&6vzpem6AVaGtc3Q>G5wiRktPK3ep>JKPbd%NiVnQsT{NC%oJLL-qJ!8-
zP-h)BwRyVw&H(-~!<FC{mXwl9ti39ohEf4rK?9XBq~H>h9FwJlK~Tt)s~GW9=N{%H
zkHahpK^rHdVncAWv!My;Py*&Okv>@=Pj<^*TyrRLzrxUph})=cnGJ9$3I}j$lr?}=
zz=2t)jatn_^K@B=I_NPS=#K1BtCqqQnsGNTQfmt49zY^Or3XLIkcNQ*9`Dm{tm+te
zGzr-e8FMH~?kI6@V_qIbW6`2CEQp*Gn9!4LSZEWt8?F-u?T9E8^I{i=*dP+gY2|H`
zMGdiKCZIJ#i3pZ4sls`onRd=e0U%n#Ca`${WrC4WU~lwxS=8N0NZz<u`9cKid(NN<
zFsfY7BSEJ$B<7F*#5mA{&Zx}{jpGKTwORvcvQB+y*s1I#P`iCV?+xGzr9b*LWQvI~
zrhhpch%QjYplTjtZ|uO1%ml?(NWxbMN0G3Y$01InG)n-fngI@h=<$y!X45_xzYZ<;
z4|EpnZuD8WG#tw++2doVPQwY<VfNOCe?%wX9=RS1CSNe=7ELA~UfP(%Vg@b3Ie@4?
zWgW4dy>6!0k>0lr7=-Wgf`_F=oh+|pA(=&dOHWYHAe`np>Wv*)f@;~V6i<7s3mijc
zZ4@C`gzXJ?yt*=6ewBc>XeQn}>W!UeP|~t^p?bStnK{#S5dlPbxd9>u#Kz1>gvttK
zd3?&C7ALU8TXCu$a(pA?no^B&vR|6~ij}sirp*p(@KQZ_I24%eSY5C<cj*<5x2O(1
zQ7zNg%?Dm)>Jm0AN|Z&CLzOTfN7OG#0F=>!FqSk3<=Di4`u1Z0Ib8selOlzIIm3id
zjw-_NQX_~=kIB1OdIh4uG&6)a$uAeQ-?@5aMkFz+U%>fER>c2C))6vM$q`s74=$Kg
z<YQ)MSJLzORlSA*>iBjcvbZ75zzxgoHpoIECg8=M24@g-g`GL-3<#WPqoB05WJPdl
z87<p^%7H7OewkiI<Lq+-QYB$D?Js>W0Pv(0o1vBq6^KzM1C(IlMdk&y!2xc`xZBy4
zbk(td%vXIm4b=}{q%u%bFrCz%#{%S}5bPliB~ozxLV*SG38`@jJQSBCAc+;i@e`;N
zt0M8yifw!cxT+TeLU39XDrBSe#GhY&)-T|b;$R9N<h$qwC8QBId4VfUBKq>G^AM<x
zW{qZS-ENHrsSdf5S-ouDAX9k*0%67<Rphyn%_~k&k6OP#jbGb=pA)02JE-dS`b1O+
zr1=;C6wFyiI!Tq?@<bwOp$VQ6<}27az_&?Ed(ewMf%20<^Z~F$y);Gm$3>HI2^Lq9
zN)VG}(M5cuIe|8Czv84=B1p?kNhb&-+kCJ~Cp@^WbcRlQNgg+8V1=ctJWBX)kq0fd
zAfF&H0wQim;D^RNLt*)8>Blbt34>^ZniMi^9|qnB%ES;E!kSQ!IK8Y>A1x=m76zre
zZ2g#{aC_l);B}ZbGf3Y$5Pf?Ha!#0t3<5F`ED$p<#rl0e5CFtqc!!Oi7M~UH7I8~>
zKcNUu8%}Z~Bb?-HK-;xoKCjL8>_&0cLO;{MS&3$vA|)_!KSn*s%ug690fdLcraD7-
fD&x8tjE$WbXjs&snU8)|^B;s6yTptcKAzx$Qp3K0

literal 0
HcmV?d00001

diff --git a/static/fonts/glyphicons-halflings-regular.svg b/static/fonts/glyphicons-halflings-regular.svg
new file mode 100644
index 0000000000..e3e2dc739d
--- /dev/null
+++ b/static/fonts/glyphicons-halflings-regular.svg
@@ -0,0 +1,229 @@
+<?xml version="1.0" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" >
+<svg xmlns="http://www.w3.org/2000/svg">
+<metadata></metadata>
+<defs>
+<font id="glyphicons_halflingsregular" horiz-adv-x="1200" >
+<font-face units-per-em="1200" ascent="960" descent="-240" />
+<missing-glyph horiz-adv-x="500" />
+<glyph />
+<glyph />
+<glyph unicode="&#xd;" />
+<glyph unicode=" " />
+<glyph unicode="*" d="M100 500v200h259l-183 183l141 141l183 -183v259h200v-259l183 183l141 -141l-183 -183h259v-200h-259l183 -183l-141 -141l-183 183v-259h-200v259l-183 -183l-141 141l183 183h-259z" />
+<glyph unicode="+" d="M0 400v300h400v400h300v-400h400v-300h-400v-400h-300v400h-400z" />
+<glyph unicode="&#xa0;" />
+<glyph unicode="&#x2000;" horiz-adv-x="652" />
+<glyph unicode="&#x2001;" horiz-adv-x="1304" />
+<glyph unicode="&#x2002;" horiz-adv-x="652" />
+<glyph unicode="&#x2003;" horiz-adv-x="1304" />
+<glyph unicode="&#x2004;" horiz-adv-x="434" />
+<glyph unicode="&#x2005;" horiz-adv-x="326" />
+<glyph unicode="&#x2006;" horiz-adv-x="217" />
+<glyph unicode="&#x2007;" horiz-adv-x="217" />
+<glyph unicode="&#x2008;" horiz-adv-x="163" />
+<glyph unicode="&#x2009;" horiz-adv-x="260" />
+<glyph unicode="&#x200a;" horiz-adv-x="72" />
+<glyph unicode="&#x202f;" horiz-adv-x="260" />
+<glyph unicode="&#x205f;" horiz-adv-x="326" />
+<glyph unicode="&#x20ac;" d="M100 500l100 100h113q0 47 5 100h-218l100 100h135q37 167 112 257q117 141 297 141q242 0 354 -189q60 -103 66 -209h-181q0 55 -25.5 99t-63.5 68t-75 36.5t-67 12.5q-24 0 -52.5 -10t-62.5 -32t-65.5 -67t-50.5 -107h379l-100 -100h-300q-6 -46 -6 -100h406l-100 -100 h-300q9 -74 33 -132t52.5 -91t62 -54.5t59 -29t46.5 -7.5q29 0 66 13t75 37t63.5 67.5t25.5 96.5h174q-31 -172 -128 -278q-107 -117 -274 -117q-205 0 -324 158q-36 46 -69 131.5t-45 205.5h-217z" />
+<glyph unicode="&#x2212;" d="M200 400h900v300h-900v-300z" />
+<glyph unicode="&#x25fc;" horiz-adv-x="500" d="M0 0z" />
+<glyph unicode="&#x2601;" d="M-14 494q0 -80 56.5 -137t135.5 -57h750q120 0 205 86.5t85 207.5t-85 207t-205 86q-46 0 -90 -14q-44 97 -134.5 156.5t-200.5 59.5q-152 0 -260 -107.5t-108 -260.5q0 -25 2 -37q-66 -14 -108.5 -67.5t-42.5 -122.5z" />
+<glyph unicode="&#x2709;" d="M0 100l400 400l200 -200l200 200l400 -400h-1200zM0 300v600l300 -300zM0 1100l600 -603l600 603h-1200zM900 600l300 300v-600z" />
+<glyph unicode="&#x270f;" d="M-13 -13l333 112l-223 223zM187 403l214 -214l614 614l-214 214zM887 1103l214 -214l99 92q13 13 13 32.5t-13 33.5l-153 153q-15 13 -33 13t-33 -13z" />
+<glyph unicode="&#xe001;" d="M0 1200h1200l-500 -550v-550h300v-100h-800v100h300v550z" />
+<glyph unicode="&#xe002;" d="M14 84q18 -55 86 -75.5t147 5.5q65 21 109 69t44 90v606l600 155v-521q-64 16 -138 -7q-79 -26 -122.5 -83t-25.5 -111q18 -55 86 -75.5t147 4.5q70 23 111.5 63.5t41.5 95.5v881q0 10 -7 15.5t-17 2.5l-752 -193q-10 -3 -17 -12.5t-7 -19.5v-689q-64 17 -138 -7 q-79 -25 -122.5 -82t-25.5 -112z" />
+<glyph unicode="&#xe003;" d="M23 693q0 200 142 342t342 142t342 -142t142 -342q0 -142 -78 -261l300 -300q7 -8 7 -18t-7 -18l-109 -109q-8 -7 -18 -7t-18 7l-300 300q-119 -78 -261 -78q-200 0 -342 142t-142 342zM176 693q0 -136 97 -233t234 -97t233.5 96.5t96.5 233.5t-96.5 233.5t-233.5 96.5 t-234 -97t-97 -233z" />
+<glyph unicode="&#xe005;" d="M100 784q0 64 28 123t73 100.5t104.5 64t119 20.5t120 -38.5t104.5 -104.5q48 69 109.5 105t121.5 38t118.5 -20.5t102.5 -64t71 -100.5t27 -123q0 -57 -33.5 -117.5t-94 -124.5t-126.5 -127.5t-150 -152.5t-146 -174q-62 85 -145.5 174t-149.5 152.5t-126.5 127.5 t-94 124.5t-33.5 117.5z" />
+<glyph unicode="&#xe006;" d="M-72 800h479l146 400h2l146 -400h472l-382 -278l145 -449l-384 275l-382 -275l146 447zM168 71l2 1z" />
+<glyph unicode="&#xe007;" d="M-72 800h479l146 400h2l146 -400h472l-382 -278l145 -449l-384 275l-382 -275l146 447zM168 71l2 1zM237 700l196 -142l-73 -226l192 140l195 -141l-74 229l193 140h-235l-77 211l-78 -211h-239z" />
+<glyph unicode="&#xe008;" d="M0 0v143l400 257v100q-37 0 -68.5 74.5t-31.5 125.5v200q0 124 88 212t212 88t212 -88t88 -212v-200q0 -51 -31.5 -125.5t-68.5 -74.5v-100l400 -257v-143h-1200z" />
+<glyph unicode="&#xe009;" d="M0 0v1100h1200v-1100h-1200zM100 100h100v100h-100v-100zM100 300h100v100h-100v-100zM100 500h100v100h-100v-100zM100 700h100v100h-100v-100zM100 900h100v100h-100v-100zM300 100h600v400h-600v-400zM300 600h600v400h-600v-400zM1000 100h100v100h-100v-100z M1000 300h100v100h-100v-100zM1000 500h100v100h-100v-100zM1000 700h100v100h-100v-100zM1000 900h100v100h-100v-100z" />
+<glyph unicode="&#xe010;" d="M0 50v400q0 21 14.5 35.5t35.5 14.5h400q21 0 35.5 -14.5t14.5 -35.5v-400q0 -21 -14.5 -35.5t-35.5 -14.5h-400q-21 0 -35.5 14.5t-14.5 35.5zM0 650v400q0 21 14.5 35.5t35.5 14.5h400q21 0 35.5 -14.5t14.5 -35.5v-400q0 -21 -14.5 -35.5t-35.5 -14.5h-400 q-21 0 -35.5 14.5t-14.5 35.5zM600 50v400q0 21 14.5 35.5t35.5 14.5h400q21 0 35.5 -14.5t14.5 -35.5v-400q0 -21 -14.5 -35.5t-35.5 -14.5h-400q-21 0 -35.5 14.5t-14.5 35.5zM600 650v400q0 21 14.5 35.5t35.5 14.5h400q21 0 35.5 -14.5t14.5 -35.5v-400 q0 -21 -14.5 -35.5t-35.5 -14.5h-400q-21 0 -35.5 14.5t-14.5 35.5z" />
+<glyph unicode="&#xe011;" d="M0 50v200q0 21 14.5 35.5t35.5 14.5h200q21 0 35.5 -14.5t14.5 -35.5v-200q0 -21 -14.5 -35.5t-35.5 -14.5h-200q-21 0 -35.5 14.5t-14.5 35.5zM0 450v200q0 21 14.5 35.5t35.5 14.5h200q21 0 35.5 -14.5t14.5 -35.5v-200q0 -21 -14.5 -35.5t-35.5 -14.5h-200 q-21 0 -35.5 14.5t-14.5 35.5zM0 850v200q0 21 14.5 35.5t35.5 14.5h200q21 0 35.5 -14.5t14.5 -35.5v-200q0 -21 -14.5 -35.5t-35.5 -14.5h-200q-21 0 -35.5 14.5t-14.5 35.5zM400 50v200q0 21 14.5 35.5t35.5 14.5h200q21 0 35.5 -14.5t14.5 -35.5v-200q0 -21 -14.5 -35.5 t-35.5 -14.5h-200q-21 0 -35.5 14.5t-14.5 35.5zM400 450v200q0 21 14.5 35.5t35.5 14.5h200q21 0 35.5 -14.5t14.5 -35.5v-200q0 -21 -14.5 -35.5t-35.5 -14.5h-200q-21 0 -35.5 14.5t-14.5 35.5zM400 850v200q0 21 14.5 35.5t35.5 14.5h200q21 0 35.5 -14.5t14.5 -35.5 v-200q0 -21 -14.5 -35.5t-35.5 -14.5h-200q-21 0 -35.5 14.5t-14.5 35.5zM800 50v200q0 21 14.5 35.5t35.5 14.5h200q21 0 35.5 -14.5t14.5 -35.5v-200q0 -21 -14.5 -35.5t-35.5 -14.5h-200q-21 0 -35.5 14.5t-14.5 35.5zM800 450v200q0 21 14.5 35.5t35.5 14.5h200 q21 0 35.5 -14.5t14.5 -35.5v-200q0 -21 -14.5 -35.5t-35.5 -14.5h-200q-21 0 -35.5 14.5t-14.5 35.5zM800 850v200q0 21 14.5 35.5t35.5 14.5h200q21 0 35.5 -14.5t14.5 -35.5v-200q0 -21 -14.5 -35.5t-35.5 -14.5h-200q-21 0 -35.5 14.5t-14.5 35.5z" />
+<glyph unicode="&#xe012;" d="M0 50v200q0 21 14.5 35.5t35.5 14.5h200q21 0 35.5 -14.5t14.5 -35.5v-200q0 -21 -14.5 -35.5t-35.5 -14.5h-200q-21 0 -35.5 14.5t-14.5 35.5zM0 450q0 -21 14.5 -35.5t35.5 -14.5h200q21 0 35.5 14.5t14.5 35.5v200q0 21 -14.5 35.5t-35.5 14.5h-200q-21 0 -35.5 -14.5 t-14.5 -35.5v-200zM0 850v200q0 21 14.5 35.5t35.5 14.5h200q21 0 35.5 -14.5t14.5 -35.5v-200q0 -21 -14.5 -35.5t-35.5 -14.5h-200q-21 0 -35.5 14.5t-14.5 35.5zM400 50v200q0 21 14.5 35.5t35.5 14.5h700q21 0 35.5 -14.5t14.5 -35.5v-200q0 -21 -14.5 -35.5 t-35.5 -14.5h-700q-21 0 -35.5 14.5t-14.5 35.5zM400 450v200q0 21 14.5 35.5t35.5 14.5h700q21 0 35.5 -14.5t14.5 -35.5v-200q0 -21 -14.5 -35.5t-35.5 -14.5h-700q-21 0 -35.5 14.5t-14.5 35.5zM400 850v200q0 21 14.5 35.5t35.5 14.5h700q21 0 35.5 -14.5t14.5 -35.5 v-200q0 -21 -14.5 -35.5t-35.5 -14.5h-700q-21 0 -35.5 14.5t-14.5 35.5z" />
+<glyph unicode="&#xe013;" d="M29 454l419 -420l818 820l-212 212l-607 -607l-206 207z" />
+<glyph unicode="&#xe014;" d="M106 318l282 282l-282 282l212 212l282 -282l282 282l212 -212l-282 -282l282 -282l-212 -212l-282 282l-282 -282z" />
+<glyph unicode="&#xe015;" d="M23 693q0 200 142 342t342 142t342 -142t142 -342q0 -142 -78 -261l300 -300q7 -8 7 -18t-7 -18l-109 -109q-8 -7 -18 -7t-18 7l-300 300q-119 -78 -261 -78q-200 0 -342 142t-142 342zM176 693q0 -136 97 -233t234 -97t233.5 96.5t96.5 233.5t-96.5 233.5t-233.5 96.5 t-234 -97t-97 -233zM300 600v200h100v100h200v-100h100v-200h-100v-100h-200v100h-100z" />
+<glyph unicode="&#xe016;" d="M23 694q0 200 142 342t342 142t342 -142t142 -342q0 -141 -78 -262l300 -299q7 -7 7 -18t-7 -18l-109 -109q-8 -8 -18 -8t-18 8l-300 300q-119 -78 -261 -78q-200 0 -342 142t-142 342zM176 694q0 -136 97 -233t234 -97t233.5 97t96.5 233t-96.5 233t-233.5 97t-234 -97 t-97 -233zM300 601h400v200h-400v-200z" />
+<glyph unicode="&#xe017;" d="M23 600q0 183 105 331t272 210v-166q-103 -55 -165 -155t-62 -220q0 -177 125 -302t302 -125t302 125t125 302q0 120 -62 220t-165 155v166q167 -62 272 -210t105 -331q0 -118 -45.5 -224.5t-123 -184t-184 -123t-224.5 -45.5t-224.5 45.5t-184 123t-123 184t-45.5 224.5 zM500 750q0 -21 14.5 -35.5t35.5 -14.5h100q21 0 35.5 14.5t14.5 35.5v400q0 21 -14.5 35.5t-35.5 14.5h-100q-21 0 -35.5 -14.5t-14.5 -35.5v-400z" />
+<glyph unicode="&#xe018;" d="M100 1h200v300h-200v-300zM400 1v500h200v-500h-200zM700 1v800h200v-800h-200zM1000 1v1200h200v-1200h-200z" />
+<glyph unicode="&#xe019;" d="M26 601q0 -33 6 -74l151 -38l2 -6q14 -49 38 -93l3 -5l-80 -134q45 -59 105 -105l133 81l5 -3q45 -26 94 -39l5 -2l38 -151q40 -5 74 -5q27 0 74 5l38 151l6 2q46 13 93 39l5 3l134 -81q56 44 104 105l-80 134l3 5q24 44 39 93l1 6l152 38q5 40 5 74q0 28 -5 73l-152 38 l-1 6q-16 51 -39 93l-3 5l80 134q-44 58 -104 105l-134 -81l-5 3q-45 25 -93 39l-6 1l-38 152q-40 5 -74 5q-27 0 -74 -5l-38 -152l-5 -1q-50 -14 -94 -39l-5 -3l-133 81q-59 -47 -105 -105l80 -134l-3 -5q-25 -47 -38 -93l-2 -6l-151 -38q-6 -48 -6 -73zM385 601 q0 88 63 151t152 63t152 -63t63 -151q0 -89 -63 -152t-152 -63t-152 63t-63 152z" />
+<glyph unicode="&#xe020;" d="M100 1025v50q0 10 7.5 17.5t17.5 7.5h275v100q0 41 29.5 70.5t70.5 29.5h300q41 0 70.5 -29.5t29.5 -70.5v-100h275q10 0 17.5 -7.5t7.5 -17.5v-50q0 -11 -7 -18t-18 -7h-1050q-11 0 -18 7t-7 18zM200 100v800h900v-800q0 -41 -29.5 -71t-70.5 -30h-700q-41 0 -70.5 30 t-29.5 71zM300 100h100v700h-100v-700zM500 100h100v700h-100v-700zM500 1100h300v100h-300v-100zM700 100h100v700h-100v-700zM900 100h100v700h-100v-700z" />
+<glyph unicode="&#xe021;" d="M1 601l656 644l644 -644h-200v-600h-300v400h-300v-400h-300v600h-200z" />
+<glyph unicode="&#xe022;" d="M100 25v1150q0 11 7 18t18 7h475v-500h400v-675q0 -11 -7 -18t-18 -7h-850q-11 0 -18 7t-7 18zM700 800v300l300 -300h-300z" />
+<glyph unicode="&#xe023;" d="M4 600q0 162 80 299t217 217t299 80t299 -80t217 -217t80 -299t-80 -299t-217 -217t-299 -80t-299 80t-217 217t-80 299zM186 600q0 -171 121.5 -292.5t292.5 -121.5t292.5 121.5t121.5 292.5t-121.5 292.5t-292.5 121.5t-292.5 -121.5t-121.5 -292.5zM500 500v400h100 v-300h200v-100h-300z" />
+<glyph unicode="&#xe024;" d="M-100 0l431 1200h209l-21 -300h162l-20 300h208l431 -1200h-538l-41 400h-242l-40 -400h-539zM488 500h224l-27 300h-170z" />
+<glyph unicode="&#xe025;" d="M0 0v400h490l-290 300h200v500h300v-500h200l-290 -300h490v-400h-1100zM813 200h175v100h-175v-100z" />
+<glyph unicode="&#xe026;" d="M1 600q0 122 47.5 233t127.5 191t191 127.5t233 47.5t233 -47.5t191 -127.5t127.5 -191t47.5 -233t-47.5 -233t-127.5 -191t-191 -127.5t-233 -47.5t-233 47.5t-191 127.5t-127.5 191t-47.5 233zM188 600q0 -170 121 -291t291 -121t291 121t121 291t-121 291t-291 121 t-291 -121t-121 -291zM350 600h150v300h200v-300h150l-250 -300z" />
+<glyph unicode="&#xe027;" d="M4 600q0 162 80 299t217 217t299 80t299 -80t217 -217t80 -299t-80 -299t-217 -217t-299 -80t-299 80t-217 217t-80 299zM186 600q0 -171 121.5 -292.5t292.5 -121.5t292.5 121.5t121.5 292.5t-121.5 292.5t-292.5 121.5t-292.5 -121.5t-121.5 -292.5zM350 600l250 300 l250 -300h-150v-300h-200v300h-150z" />
+<glyph unicode="&#xe028;" d="M0 25v475l200 700h800l199 -700l1 -475q0 -11 -7 -18t-18 -7h-1150q-11 0 -18 7t-7 18zM200 500h200l50 -200h300l50 200h200l-97 500h-606z" />
+<glyph unicode="&#xe029;" d="M4 600q0 162 80 299t217 217t299 80t299 -80t217 -217t80 -299t-80 -299t-217 -217t-299 -80t-299 80t-217 217t-80 299zM186 600q0 -172 121.5 -293t292.5 -121t292.5 121t121.5 293q0 171 -121.5 292.5t-292.5 121.5t-292.5 -121.5t-121.5 -292.5zM500 397v401 l297 -200z" />
+<glyph unicode="&#xe030;" d="M23 600q0 -118 45.5 -224.5t123 -184t184 -123t224.5 -45.5t224.5 45.5t184 123t123 184t45.5 224.5h-150q0 -177 -125 -302t-302 -125t-302 125t-125 302t125 302t302 125q136 0 246 -81l-146 -146h400v400l-145 -145q-157 122 -355 122q-118 0 -224.5 -45.5t-184 -123 t-123 -184t-45.5 -224.5z" />
+<glyph unicode="&#xe031;" d="M23 600q0 118 45.5 224.5t123 184t184 123t224.5 45.5q198 0 355 -122l145 145v-400h-400l147 147q-112 80 -247 80q-177 0 -302 -125t-125 -302h-150zM100 0v400h400l-147 -147q112 -80 247 -80q177 0 302 125t125 302h150q0 -118 -45.5 -224.5t-123 -184t-184 -123 t-224.5 -45.5q-198 0 -355 122z" />
+<glyph unicode="&#xe032;" d="M100 0h1100v1200h-1100v-1200zM200 100v900h900v-900h-900zM300 200v100h100v-100h-100zM300 400v100h100v-100h-100zM300 600v100h100v-100h-100zM300 800v100h100v-100h-100zM500 200h500v100h-500v-100zM500 400v100h500v-100h-500zM500 600v100h500v-100h-500z M500 800v100h500v-100h-500z" />
+<glyph unicode="&#xe033;" d="M0 100v600q0 41 29.5 70.5t70.5 29.5h100v200q0 82 59 141t141 59h300q82 0 141 -59t59 -141v-200h100q41 0 70.5 -29.5t29.5 -70.5v-600q0 -41 -29.5 -70.5t-70.5 -29.5h-900q-41 0 -70.5 29.5t-29.5 70.5zM400 800h300v150q0 21 -14.5 35.5t-35.5 14.5h-200 q-21 0 -35.5 -14.5t-14.5 -35.5v-150z" />
+<glyph unicode="&#xe034;" d="M100 0v1100h100v-1100h-100zM300 400q60 60 127.5 84t127.5 17.5t122 -23t119 -30t110 -11t103 42t91 120.5v500q-40 -81 -101.5 -115.5t-127.5 -29.5t-138 25t-139.5 40t-125.5 25t-103 -29.5t-65 -115.5v-500z" />
+<glyph unicode="&#xe035;" d="M0 275q0 -11 7 -18t18 -7h50q11 0 18 7t7 18v300q0 127 70.5 231.5t184.5 161.5t245 57t245 -57t184.5 -161.5t70.5 -231.5v-300q0 -11 7 -18t18 -7h50q11 0 18 7t7 18v300q0 116 -49.5 227t-131 192.5t-192.5 131t-227 49.5t-227 -49.5t-192.5 -131t-131 -192.5 t-49.5 -227v-300zM200 20v460q0 8 6 14t14 6h160q8 0 14 -6t6 -14v-460q0 -8 -6 -14t-14 -6h-160q-8 0 -14 6t-6 14zM800 20v460q0 8 6 14t14 6h160q8 0 14 -6t6 -14v-460q0 -8 -6 -14t-14 -6h-160q-8 0 -14 6t-6 14z" />
+<glyph unicode="&#xe036;" d="M0 400h300l300 -200v800l-300 -200h-300v-400zM688 459l141 141l-141 141l71 71l141 -141l141 141l71 -71l-141 -141l141 -141l-71 -71l-141 141l-141 -141z" />
+<glyph unicode="&#xe037;" d="M0 400h300l300 -200v800l-300 -200h-300v-400zM700 857l69 53q111 -135 111 -310q0 -169 -106 -302l-67 54q86 110 86 248q0 146 -93 257z" />
+<glyph unicode="&#xe038;" d="M0 401v400h300l300 200v-800l-300 200h-300zM702 858l69 53q111 -135 111 -310q0 -170 -106 -303l-67 55q86 110 86 248q0 145 -93 257zM889 951l7 -8q123 -151 123 -344q0 -189 -119 -339l-7 -8l81 -66l6 8q142 178 142 405q0 230 -144 408l-6 8z" />
+<glyph unicode="&#xe039;" d="M0 0h500v500h-200v100h-100v-100h-200v-500zM0 600h100v100h400v100h100v100h-100v300h-500v-600zM100 100v300h300v-300h-300zM100 800v300h300v-300h-300zM200 200v100h100v-100h-100zM200 900h100v100h-100v-100zM500 500v100h300v-300h200v-100h-100v-100h-200v100 h-100v100h100v200h-200zM600 0v100h100v-100h-100zM600 1000h100v-300h200v-300h300v200h-200v100h200v500h-600v-200zM800 800v300h300v-300h-300zM900 0v100h300v-100h-300zM900 900v100h100v-100h-100zM1100 200v100h100v-100h-100z" />
+<glyph unicode="&#xe040;" d="M0 200h100v1000h-100v-1000zM100 0v100h300v-100h-300zM200 200v1000h100v-1000h-100zM500 0v91h100v-91h-100zM500 200v1000h200v-1000h-200zM700 0v91h100v-91h-100zM800 200v1000h100v-1000h-100zM900 0v91h200v-91h-200zM1000 200v1000h200v-1000h-200z" />
+<glyph unicode="&#xe041;" d="M0 700l1 475q0 10 7.5 17.5t17.5 7.5h474l700 -700l-500 -500zM148 953q0 -42 29 -71q30 -30 71.5 -30t71.5 30q29 29 29 71t-29 71q-30 30 -71.5 30t-71.5 -30q-29 -29 -29 -71z" />
+<glyph unicode="&#xe042;" d="M1 700l1 475q0 11 7 18t18 7h474l700 -700l-500 -500zM148 953q0 -42 30 -71q29 -30 71 -30t71 30q30 29 30 71t-30 71q-29 30 -71 30t-71 -30q-30 -29 -30 -71zM701 1200h100l700 -700l-500 -500l-50 50l450 450z" />
+<glyph unicode="&#xe043;" d="M100 0v1025l175 175h925v-1000l-100 -100v1000h-750l-100 -100h750v-1000h-900z" />
+<glyph unicode="&#xe044;" d="M200 0l450 444l450 -443v1150q0 20 -14.5 35t-35.5 15h-800q-21 0 -35.5 -15t-14.5 -35v-1151z" />
+<glyph unicode="&#xe045;" d="M0 100v700h200l100 -200h600l100 200h200v-700h-200v200h-800v-200h-200zM253 829l40 -124h592l62 124l-94 346q-2 11 -10 18t-18 7h-450q-10 0 -18 -7t-10 -18zM281 24l38 152q2 10 11.5 17t19.5 7h500q10 0 19.5 -7t11.5 -17l38 -152q2 -10 -3.5 -17t-15.5 -7h-600 q-10 0 -15.5 7t-3.5 17z" />
+<glyph unicode="&#xe046;" d="M0 200q0 -41 29.5 -70.5t70.5 -29.5h1000q41 0 70.5 29.5t29.5 70.5v600q0 41 -29.5 70.5t-70.5 29.5h-150q-4 8 -11.5 21.5t-33 48t-53 61t-69 48t-83.5 21.5h-200q-41 0 -82 -20.5t-70 -50t-52 -59t-34 -50.5l-12 -20h-150q-41 0 -70.5 -29.5t-29.5 -70.5v-600z M356 500q0 100 72 172t172 72t172 -72t72 -172t-72 -172t-172 -72t-172 72t-72 172zM494 500q0 -44 31 -75t75 -31t75 31t31 75t-31 75t-75 31t-75 -31t-31 -75zM900 700v100h100v-100h-100z" />
+<glyph unicode="&#xe047;" d="M53 0h365v66q-41 0 -72 11t-49 38t1 71l92 234h391l82 -222q16 -45 -5.5 -88.5t-74.5 -43.5v-66h417v66q-34 1 -74 43q-18 19 -33 42t-21 37l-6 13l-385 998h-93l-399 -1006q-24 -48 -52 -75q-12 -12 -33 -25t-36 -20l-15 -7v-66zM416 521l178 457l46 -140l116 -317h-340 z" />
+<glyph unicode="&#xe048;" d="M100 0v89q41 7 70.5 32.5t29.5 65.5v827q0 28 -1 39.5t-5.5 26t-15.5 21t-29 14t-49 14.5v71l471 -1q120 0 213 -88t93 -228q0 -55 -11.5 -101.5t-28 -74t-33.5 -47.5t-28 -28l-12 -7q8 -3 21.5 -9t48 -31.5t60.5 -58t47.5 -91.5t21.5 -129q0 -84 -59 -156.5t-142 -111 t-162 -38.5h-500zM400 200h161q89 0 153 48.5t64 132.5q0 90 -62.5 154.5t-156.5 64.5h-159v-400zM400 700h139q76 0 130 61.5t54 138.5q0 82 -84 130.5t-239 48.5v-379z" />
+<glyph unicode="&#xe049;" d="M200 0v57q77 7 134.5 40.5t65.5 80.5l173 849q10 56 -10 74t-91 37q-6 1 -10.5 2.5t-9.5 2.5v57h425l2 -57q-33 -8 -62 -25.5t-46 -37t-29.5 -38t-17.5 -30.5l-5 -12l-128 -825q-10 -52 14 -82t95 -36v-57h-500z" />
+<glyph unicode="&#xe050;" d="M-75 200h75v800h-75l125 167l125 -167h-75v-800h75l-125 -167zM300 900v300h150h700h150v-300h-50q0 29 -8 48.5t-18.5 30t-33.5 15t-39.5 5.5t-50.5 1h-200v-850l100 -50v-100h-400v100l100 50v850h-200q-34 0 -50.5 -1t-40 -5.5t-33.5 -15t-18.5 -30t-8.5 -48.5h-49z " />
+<glyph unicode="&#xe051;" d="M33 51l167 125v-75h800v75l167 -125l-167 -125v75h-800v-75zM100 901v300h150h700h150v-300h-50q0 29 -8 48.5t-18 30t-33.5 15t-40 5.5t-50.5 1h-200v-650l100 -50v-100h-400v100l100 50v650h-200q-34 0 -50.5 -1t-39.5 -5.5t-33.5 -15t-18.5 -30t-8 -48.5h-50z" />
+<glyph unicode="&#xe052;" d="M0 50q0 -20 14.5 -35t35.5 -15h1100q21 0 35.5 15t14.5 35v100q0 21 -14.5 35.5t-35.5 14.5h-1100q-21 0 -35.5 -14.5t-14.5 -35.5v-100zM0 350q0 -20 14.5 -35t35.5 -15h800q21 0 35.5 15t14.5 35v100q0 21 -14.5 35.5t-35.5 14.5h-800q-21 0 -35.5 -14.5t-14.5 -35.5 v-100zM0 650q0 -20 14.5 -35t35.5 -15h1000q21 0 35.5 15t14.5 35v100q0 21 -14.5 35.5t-35.5 14.5h-1000q-21 0 -35.5 -14.5t-14.5 -35.5v-100zM0 950q0 -20 14.5 -35t35.5 -15h600q21 0 35.5 15t14.5 35v100q0 21 -14.5 35.5t-35.5 14.5h-600q-21 0 -35.5 -14.5 t-14.5 -35.5v-100z" />
+<glyph unicode="&#xe053;" d="M0 50q0 -20 14.5 -35t35.5 -15h1100q21 0 35.5 15t14.5 35v100q0 21 -14.5 35.5t-35.5 14.5h-1100q-21 0 -35.5 -14.5t-14.5 -35.5v-100zM0 650q0 -20 14.5 -35t35.5 -15h1100q21 0 35.5 15t14.5 35v100q0 21 -14.5 35.5t-35.5 14.5h-1100q-21 0 -35.5 -14.5t-14.5 -35.5 v-100zM200 350q0 -20 14.5 -35t35.5 -15h700q21 0 35.5 15t14.5 35v100q0 21 -14.5 35.5t-35.5 14.5h-700q-21 0 -35.5 -14.5t-14.5 -35.5v-100zM200 950q0 -20 14.5 -35t35.5 -15h700q21 0 35.5 15t14.5 35v100q0 21 -14.5 35.5t-35.5 14.5h-700q-21 0 -35.5 -14.5 t-14.5 -35.5v-100z" />
+<glyph unicode="&#xe054;" d="M0 50v100q0 21 14.5 35.5t35.5 14.5h1100q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-1100q-21 0 -35.5 15t-14.5 35zM100 650v100q0 21 14.5 35.5t35.5 14.5h1000q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-1000q-21 0 -35.5 15 t-14.5 35zM300 350v100q0 21 14.5 35.5t35.5 14.5h800q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-800q-21 0 -35.5 15t-14.5 35zM500 950v100q0 21 14.5 35.5t35.5 14.5h600q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-600 q-21 0 -35.5 15t-14.5 35z" />
+<glyph unicode="&#xe055;" d="M0 50v100q0 21 14.5 35.5t35.5 14.5h1100q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-1100q-21 0 -35.5 15t-14.5 35zM0 350v100q0 21 14.5 35.5t35.5 14.5h1100q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-1100q-21 0 -35.5 15 t-14.5 35zM0 650v100q0 21 14.5 35.5t35.5 14.5h1100q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-1100q-21 0 -35.5 15t-14.5 35zM0 950v100q0 21 14.5 35.5t35.5 14.5h1100q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-1100 q-21 0 -35.5 15t-14.5 35z" />
+<glyph unicode="&#xe056;" d="M0 50v100q0 21 14.5 35.5t35.5 14.5h100q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-100q-21 0 -35.5 15t-14.5 35zM0 350v100q0 21 14.5 35.5t35.5 14.5h100q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-100q-21 0 -35.5 15 t-14.5 35zM0 650v100q0 21 14.5 35.5t35.5 14.5h100q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-100q-21 0 -35.5 15t-14.5 35zM0 950v100q0 21 14.5 35.5t35.5 14.5h100q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-100q-21 0 -35.5 15 t-14.5 35zM300 50v100q0 21 14.5 35.5t35.5 14.5h800q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-800q-21 0 -35.5 15t-14.5 35zM300 350v100q0 21 14.5 35.5t35.5 14.5h800q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-800 q-21 0 -35.5 15t-14.5 35zM300 650v100q0 21 14.5 35.5t35.5 14.5h800q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15h-800q-21 0 -35.5 15t-14.5 35zM300 950v100q0 21 14.5 35.5t35.5 14.5h800q21 0 35.5 -14.5t14.5 -35.5v-100q0 -20 -14.5 -35t-35.5 -15 h-800q-21 0 -35.5 15t-14.5 35z" />
+<glyph unicode="&#xe057;" d="M-101 500v100h201v75l166 -125l-166 -125v75h-201zM300 0h100v1100h-100v-1100zM500 50q0 -20 14.5 -35t35.5 -15h600q20 0 35 15t15 35v100q0 21 -15 35.5t-35 14.5h-600q-21 0 -35.5 -14.5t-14.5 -35.5v-100zM500 350q0 -20 14.5 -35t35.5 -15h300q20 0 35 15t15 35 v100q0 21 -15 35.5t-35 14.5h-300q-21 0 -35.5 -14.5t-14.5 -35.5v-100zM500 650q0 -20 14.5 -35t35.5 -15h500q20 0 35 15t15 35v100q0 21 -15 35.5t-35 14.5h-500q-21 0 -35.5 -14.5t-14.5 -35.5v-100zM500 950q0 -20 14.5 -35t35.5 -15h100q20 0 35 15t15 35v100 q0 21 -15 35.5t-35 14.5h-100q-21 0 -35.5 -14.5t-14.5 -35.5v-100z" />
+<glyph unicode="&#xe058;" d="M1 50q0 -20 14.5 -35t35.5 -15h600q20 0 35 15t15 35v100q0 21 -15 35.5t-35 14.5h-600q-21 0 -35.5 -14.5t-14.5 -35.5v-100zM1 350q0 -20 14.5 -35t35.5 -15h300q20 0 35 15t15 35v100q0 21 -15 35.5t-35 14.5h-300q-21 0 -35.5 -14.5t-14.5 -35.5v-100zM1 650 q0 -20 14.5 -35t35.5 -15h500q20 0 35 15t15 35v100q0 21 -15 35.5t-35 14.5h-500q-21 0 -35.5 -14.5t-14.5 -35.5v-100zM1 950q0 -20 14.5 -35t35.5 -15h100q20 0 35 15t15 35v100q0 21 -15 35.5t-35 14.5h-100q-21 0 -35.5 -14.5t-14.5 -35.5v-100zM801 0v1100h100v-1100 h-100zM934 550l167 -125v75h200v100h-200v75z" />
+<glyph unicode="&#xe059;" d="M0 275v650q0 31 22 53t53 22h750q31 0 53 -22t22 -53v-650q0 -31 -22 -53t-53 -22h-750q-31 0 -53 22t-22 53zM900 600l300 300v-600z" />
+<glyph unicode="&#xe060;" d="M0 44v1012q0 18 13 31t31 13h1112q19 0 31.5 -13t12.5 -31v-1012q0 -18 -12.5 -31t-31.5 -13h-1112q-18 0 -31 13t-13 31zM100 263l247 182l298 -131l-74 156l293 318l236 -288v500h-1000v-737zM208 750q0 56 39 95t95 39t95 -39t39 -95t-39 -95t-95 -39t-95 39t-39 95z " />
+<glyph unicode="&#xe062;" d="M148 745q0 124 60.5 231.5t165 172t226.5 64.5q123 0 227 -63t164.5 -169.5t60.5 -229.5t-73 -272q-73 -114 -166.5 -237t-150.5 -189l-57 -66q-10 9 -27 26t-66.5 70.5t-96 109t-104 135.5t-100.5 155q-63 139 -63 262zM342 772q0 -107 75.5 -182.5t181.5 -75.5 q107 0 182.5 75.5t75.5 182.5t-75.5 182t-182.5 75t-182 -75.5t-75 -181.5z" />
+<glyph unicode="&#xe063;" d="M1 600q0 122 47.5 233t127.5 191t191 127.5t233 47.5t233 -47.5t191 -127.5t127.5 -191t47.5 -233t-47.5 -233t-127.5 -191t-191 -127.5t-233 -47.5t-233 47.5t-191 127.5t-127.5 191t-47.5 233zM173 600q0 -177 125.5 -302t301.5 -125v854q-176 0 -301.5 -125 t-125.5 -302z" />
+<glyph unicode="&#xe064;" d="M117 406q0 94 34 186t88.5 172.5t112 159t115 177t87.5 194.5q21 -71 57.5 -142.5t76 -130.5t83 -118.5t82 -117t70 -116t50 -125.5t18.5 -136q0 -89 -39 -165.5t-102 -126.5t-140 -79.5t-156 -33.5q-114 6 -211.5 53t-161.5 139t-64 210zM243 414q14 -82 59.5 -136 t136.5 -80l16 98q-7 6 -18 17t-34 48t-33 77q-15 73 -14 143.5t10 122.5l9 51q-92 -110 -119.5 -185t-12.5 -156z" />
+<glyph unicode="&#xe065;" d="M0 400v300q0 165 117.5 282.5t282.5 117.5q366 -6 397 -14l-186 -186h-311q-41 0 -70.5 -29.5t-29.5 -70.5v-500q0 -41 29.5 -70.5t70.5 -29.5h500q41 0 70.5 29.5t29.5 70.5v125l200 200v-225q0 -165 -117.5 -282.5t-282.5 -117.5h-300q-165 0 -282.5 117.5 t-117.5 282.5zM436 341l161 50l412 412l-114 113l-405 -405zM995 1015l113 -113l113 113l-21 85l-92 28z" />
+<glyph unicode="&#xe066;" d="M0 400v300q0 165 117.5 282.5t282.5 117.5h261l2 -80q-133 -32 -218 -120h-145q-41 0 -70.5 -29.5t-29.5 -70.5v-500q0 -41 29.5 -70.5t70.5 -29.5h500q41 0 70.5 29.5t29.5 70.5l200 153v-53q0 -165 -117.5 -282.5t-282.5 -117.5h-300q-165 0 -282.5 117.5t-117.5 282.5 zM423 524q30 38 81.5 64t103 35.5t99 14t77.5 3.5l29 -1v-209l360 324l-359 318v-216q-7 0 -19 -1t-48 -8t-69.5 -18.5t-76.5 -37t-76.5 -59t-62 -88t-39.5 -121.5z" />
+<glyph unicode="&#xe067;" d="M0 400v300q0 165 117.5 282.5t282.5 117.5h300q61 0 127 -23l-178 -177h-349q-41 0 -70.5 -29.5t-29.5 -70.5v-500q0 -41 29.5 -70.5t70.5 -29.5h500q41 0 70.5 29.5t29.5 70.5v69l200 200v-169q0 -165 -117.5 -282.5t-282.5 -117.5h-300q-165 0 -282.5 117.5 t-117.5 282.5zM342 632l283 -284l567 567l-137 137l-430 -431l-146 147z" />
+<glyph unicode="&#xe068;" d="M0 603l300 296v-198h200v200h-200l300 300l295 -300h-195v-200h200v198l300 -296l-300 -300v198h-200v-200h195l-295 -300l-300 300h200v200h-200v-198z" />
+<glyph unicode="&#xe069;" d="M200 50v1000q0 21 14.5 35.5t35.5 14.5h100q21 0 35.5 -14.5t14.5 -35.5v-437l500 487v-1100l-500 488v-438q0 -21 -14.5 -35.5t-35.5 -14.5h-100q-21 0 -35.5 14.5t-14.5 35.5z" />
+<glyph unicode="&#xe070;" d="M0 50v1000q0 21 14.5 35.5t35.5 14.5h100q21 0 35.5 -14.5t14.5 -35.5v-437l500 487v-487l500 487v-1100l-500 488v-488l-500 488v-438q0 -21 -14.5 -35.5t-35.5 -14.5h-100q-21 0 -35.5 14.5t-14.5 35.5z" />
+<glyph unicode="&#xe071;" d="M136 550l564 550v-487l500 487v-1100l-500 488v-488z" />
+<glyph unicode="&#xe072;" d="M200 0l900 550l-900 550v-1100z" />
+<glyph unicode="&#xe073;" d="M200 150q0 -21 14.5 -35.5t35.5 -14.5h200q21 0 35.5 14.5t14.5 35.5v800q0 21 -14.5 35.5t-35.5 14.5h-200q-21 0 -35.5 -14.5t-14.5 -35.5v-800zM600 150q0 -21 14.5 -35.5t35.5 -14.5h200q21 0 35.5 14.5t14.5 35.5v800q0 21 -14.5 35.5t-35.5 14.5h-200 q-21 0 -35.5 -14.5t-14.5 -35.5v-800z" />
+<glyph unicode="&#xe074;" d="M200 150q0 -20 14.5 -35t35.5 -15h800q21 0 35.5 15t14.5 35v800q0 21 -14.5 35.5t-35.5 14.5h-800q-21 0 -35.5 -14.5t-14.5 -35.5v-800z" />
+<glyph unicode="&#xe075;" d="M0 0v1100l500 -487v487l564 -550l-564 -550v488z" />
+<glyph unicode="&#xe076;" d="M0 0v1100l500 -487v487l500 -487v437q0 21 14.5 35.5t35.5 14.5h100q21 0 35.5 -14.5t14.5 -35.5v-1000q0 -21 -14.5 -35.5t-35.5 -14.5h-100q-21 0 -35.5 14.5t-14.5 35.5v438l-500 -488v488z" />
+<glyph unicode="&#xe077;" d="M300 0v1100l500 -487v437q0 21 14.5 35.5t35.5 14.5h100q21 0 35.5 -14.5t14.5 -35.5v-1000q0 -21 -14.5 -35.5t-35.5 -14.5h-100q-21 0 -35.5 14.5t-14.5 35.5v438z" />
+<glyph unicode="&#xe078;" d="M100 250v100q0 21 14.5 35.5t35.5 14.5h1000q21 0 35.5 -14.5t14.5 -35.5v-100q0 -21 -14.5 -35.5t-35.5 -14.5h-1000q-21 0 -35.5 14.5t-14.5 35.5zM100 500h1100l-550 564z" />
+<glyph unicode="&#xe079;" d="M185 599l592 -592l240 240l-353 353l353 353l-240 240z" />
+<glyph unicode="&#xe080;" d="M272 194l353 353l-353 353l241 240l572 -571l21 -22l-1 -1v-1l-592 -591z" />
+<glyph unicode="&#xe081;" d="M3 600q0 162 80 299.5t217.5 217.5t299.5 80t299.5 -80t217.5 -217.5t80 -299.5t-80 -299.5t-217.5 -217.5t-299.5 -80t-299.5 80t-217.5 217.5t-80 299.5zM300 500h200v-200h200v200h200v200h-200v200h-200v-200h-200v-200z" />
+<glyph unicode="&#xe082;" d="M3 600q0 162 80 299.5t217.5 217.5t299.5 80t299.5 -80t217.5 -217.5t80 -299.5t-80 -299.5t-217.5 -217.5t-299.5 -80t-299.5 80t-217.5 217.5t-80 299.5zM300 500h600v200h-600v-200z" />
+<glyph unicode="&#xe083;" d="M3 600q0 162 80 299.5t217.5 217.5t299.5 80t299.5 -80t217.5 -217.5t80 -299.5t-80 -299.5t-217.5 -217.5t-299.5 -80t-299.5 80t-217.5 217.5t-80 299.5zM246 459l213 -213l141 142l141 -142l213 213l-142 141l142 141l-213 212l-141 -141l-141 142l-212 -213l141 -141 z" />
+<glyph unicode="&#xe084;" d="M3 600q0 162 80 299.5t217.5 217.5t299.5 80t299.5 -80t217.5 -217.5t80 -299.5t-80 -299.5t-217.5 -217.5t-299.5 -80t-299.5 80t-217.5 217.5t-80 299.5zM270 551l276 -277l411 411l-175 174l-236 -236l-102 102z" />
+<glyph unicode="&#xe085;" d="M3 600q0 162 80 299.5t217.5 217.5t299.5 80t299.5 -80t217.5 -217.5t80 -299.5t-80 -299.5t-217.5 -217.5t-299.5 -80t-299.5 80t-217.5 217.5t-80 299.5zM364 700h143q4 0 11.5 -1t11 -1t6.5 3t3 9t1 11t3.5 8.5t3.5 6t5.5 4t6.5 2.5t9 1.5t9 0.5h11.5h12.5 q19 0 30 -10t11 -26q0 -22 -4 -28t-27 -22q-5 -1 -12.5 -3t-27 -13.5t-34 -27t-26.5 -46t-11 -68.5h200q5 3 14 8t31.5 25.5t39.5 45.5t31 69t14 94q0 51 -17.5 89t-42 58t-58.5 32t-58.5 15t-51.5 3q-50 0 -90.5 -12t-75 -38.5t-53.5 -74.5t-19 -114zM500 300h200v100h-200 v-100z" />
+<glyph unicode="&#xe086;" d="M3 600q0 162 80 299.5t217.5 217.5t299.5 80t299.5 -80t217.5 -217.5t80 -299.5t-80 -299.5t-217.5 -217.5t-299.5 -80t-299.5 80t-217.5 217.5t-80 299.5zM400 300h400v100h-100v300h-300v-100h100v-200h-100v-100zM500 800h200v100h-200v-100z" />
+<glyph unicode="&#xe087;" d="M0 500v200h195q31 125 98.5 199.5t206.5 100.5v200h200v-200q54 -20 113 -60t112.5 -105.5t71.5 -134.5h203v-200h-203q-25 -102 -116.5 -186t-180.5 -117v-197h-200v197q-140 27 -208 102.5t-98 200.5h-194zM290 500q24 -73 79.5 -127.5t130.5 -78.5v206h200v-206 q149 48 201 206h-201v200h200q-25 74 -75.5 127t-124.5 77v-204h-200v203q-75 -23 -130 -77t-79 -126h209v-200h-210z" />
+<glyph unicode="&#xe088;" d="M4 600q0 162 80 299t217 217t299 80t299 -80t217 -217t80 -299t-80 -299t-217 -217t-299 -80t-299 80t-217 217t-80 299zM186 600q0 -171 121.5 -292.5t292.5 -121.5t292.5 121.5t121.5 292.5t-121.5 292.5t-292.5 121.5t-292.5 -121.5t-121.5 -292.5zM356 465l135 135 l-135 135l109 109l135 -135l135 135l109 -109l-135 -135l135 -135l-109 -109l-135 135l-135 -135z" />
+<glyph unicode="&#xe089;" d="M4 600q0 162 80 299t217 217t299 80t299 -80t217 -217t80 -299t-80 -299t-217 -217t-299 -80t-299 80t-217 217t-80 299zM186 600q0 -171 121.5 -292.5t292.5 -121.5t292.5 121.5t121.5 292.5t-121.5 292.5t-292.5 121.5t-292.5 -121.5t-121.5 -292.5zM322 537l141 141 l87 -87l204 205l142 -142l-346 -345z" />
+<glyph unicode="&#xe090;" d="M4 600q0 162 80 299t217 217t299 80t299 -80t217 -217t80 -299t-80 -299t-217 -217t-299 -80t-299 80t-217 217t-80 299zM186 600q0 -115 62 -215l568 567q-100 62 -216 62q-171 0 -292.5 -121.5t-121.5 -292.5zM391 245q97 -59 209 -59q171 0 292.5 121.5t121.5 292.5 q0 112 -59 209z" />
+<glyph unicode="&#xe091;" d="M0 547l600 453v-300h600v-300h-600v-301z" />
+<glyph unicode="&#xe092;" d="M0 400v300h600v300l600 -453l-600 -448v301h-600z" />
+<glyph unicode="&#xe093;" d="M204 600l450 600l444 -600h-298v-600h-300v600h-296z" />
+<glyph unicode="&#xe094;" d="M104 600h296v600h300v-600h298l-449 -600z" />
+<glyph unicode="&#xe095;" d="M0 200q6 132 41 238.5t103.5 193t184 138t271.5 59.5v271l600 -453l-600 -448v301q-95 -2 -183 -20t-170 -52t-147 -92.5t-100 -135.5z" />
+<glyph unicode="&#xe096;" d="M0 0v400l129 -129l294 294l142 -142l-294 -294l129 -129h-400zM635 777l142 -142l294 294l129 -129v400h-400l129 -129z" />
+<glyph unicode="&#xe097;" d="M34 176l295 295l-129 129h400v-400l-129 130l-295 -295zM600 600v400l129 -129l295 295l142 -141l-295 -295l129 -130h-400z" />
+<glyph unicode="&#xe101;" d="M23 600q0 118 45.5 224.5t123 184t184 123t224.5 45.5t224.5 -45.5t184 -123t123 -184t45.5 -224.5t-45.5 -224.5t-123 -184t-184 -123t-224.5 -45.5t-224.5 45.5t-184 123t-123 184t-45.5 224.5zM456 851l58 -302q4 -20 21.5 -34.5t37.5 -14.5h54q20 0 37.5 14.5 t21.5 34.5l58 302q4 20 -8 34.5t-32 14.5h-207q-21 0 -33 -14.5t-8 -34.5zM500 300h200v100h-200v-100z" />
+<glyph unicode="&#xe102;" d="M0 800h100v-200h400v300h200v-300h400v200h100v100h-111q1 1 1 6.5t-1.5 15t-3.5 17.5l-34 172q-11 39 -41.5 63t-69.5 24q-32 0 -61 -17l-239 -144q-22 -13 -40 -35q-19 24 -40 36l-238 144q-33 18 -62 18q-39 0 -69.5 -23t-40.5 -61l-35 -177q-2 -8 -3 -18t-1 -15v-6 h-111v-100zM100 0h400v400h-400v-400zM200 900q-3 0 14 48t36 96l18 47l213 -191h-281zM700 0v400h400v-400h-400zM731 900l202 197q5 -12 12 -32.5t23 -64t25 -72t7 -28.5h-269z" />
+<glyph unicode="&#xe103;" d="M0 -22v143l216 193q-9 53 -13 83t-5.5 94t9 113t38.5 114t74 124q47 60 99.5 102.5t103 68t127.5 48t145.5 37.5t184.5 43.5t220 58.5q0 -189 -22 -343t-59 -258t-89 -181.5t-108.5 -120t-122 -68t-125.5 -30t-121.5 -1.5t-107.5 12.5t-87.5 17t-56.5 7.5l-99 -55z M238.5 300.5q19.5 -6.5 86.5 76.5q55 66 367 234q70 38 118.5 69.5t102 79t99 111.5t86.5 148q22 50 24 60t-6 19q-7 5 -17 5t-26.5 -14.5t-33.5 -39.5q-35 -51 -113.5 -108.5t-139.5 -89.5l-61 -32q-369 -197 -458 -401q-48 -111 -28.5 -117.5z" />
+<glyph unicode="&#xe104;" d="M111 408q0 -33 5 -63q9 -56 44 -119.5t105 -108.5q31 -21 64 -16t62 23.5t57 49.5t48 61.5t35 60.5q32 66 39 184.5t-13 157.5q79 -80 122 -164t26 -184q-5 -33 -20.5 -69.5t-37.5 -80.5q-10 -19 -14.5 -29t-12 -26t-9 -23.5t-3 -19t2.5 -15.5t11 -9.5t19.5 -5t30.5 2.5 t42 8q57 20 91 34t87.5 44.5t87 64t65.5 88.5t47 122q38 172 -44.5 341.5t-246.5 278.5q22 -44 43 -129q39 -159 -32 -154q-15 2 -33 9q-79 33 -120.5 100t-44 175.5t48.5 257.5q-13 -8 -34 -23.5t-72.5 -66.5t-88.5 -105.5t-60 -138t-8 -166.5q2 -12 8 -41.5t8 -43t6 -39.5 t3.5 -39.5t-1 -33.5t-6 -31.5t-13.5 -24t-21 -20.5t-31 -12q-38 -10 -67 13t-40.5 61.5t-15 81.5t10.5 75q-52 -46 -83.5 -101t-39 -107t-7.5 -85z" />
+<glyph unicode="&#xe105;" d="M-61 600l26 40q6 10 20 30t49 63.5t74.5 85.5t97 90t116.5 83.5t132.5 59t145.5 23.5t145.5 -23.5t132.5 -59t116.5 -83.5t97 -90t74.5 -85.5t49 -63.5t20 -30l26 -40l-26 -40q-6 -10 -20 -30t-49 -63.5t-74.5 -85.5t-97 -90t-116.5 -83.5t-132.5 -59t-145.5 -23.5 t-145.5 23.5t-132.5 59t-116.5 83.5t-97 90t-74.5 85.5t-49 63.5t-20 30zM120 600q7 -10 40.5 -58t56 -78.5t68 -77.5t87.5 -75t103 -49.5t125 -21.5t123.5 20t100.5 45.5t85.5 71.5t66.5 75.5t58 81.5t47 66q-1 1 -28.5 37.5t-42 55t-43.5 53t-57.5 63.5t-58.5 54 q49 -74 49 -163q0 -124 -88 -212t-212 -88t-212 88t-88 212q0 85 46 158q-102 -87 -226 -258zM377 656q49 -124 154 -191l105 105q-37 24 -75 72t-57 84l-20 36z" />
+<glyph unicode="&#xe106;" d="M-61 600l26 40q6 10 20 30t49 63.5t74.5 85.5t97 90t116.5 83.5t132.5 59t145.5 23.5q61 0 121 -17l37 142h148l-314 -1200h-148l37 143q-82 21 -165 71.5t-140 102t-109.5 112t-72 88.5t-29.5 43zM120 600q210 -282 393 -336l37 141q-107 18 -178.5 101.5t-71.5 193.5 q0 85 46 158q-102 -87 -226 -258zM377 656q49 -124 154 -191l47 47l23 87q-30 28 -59 69t-44 68l-14 26zM780 161l38 145q22 15 44.5 34t46 44t40.5 44t41 50.5t33.5 43.5t33 44t24.5 34q-97 127 -140 175l39 146q67 -54 131.5 -125.5t87.5 -103.5t36 -52l26 -40l-26 -40 q-7 -12 -25.5 -38t-63.5 -79.5t-95.5 -102.5t-124 -100t-146.5 -79z" />
+<glyph unicode="&#xe107;" d="M-97.5 34q13.5 -34 50.5 -34h1294q37 0 50.5 35.5t-7.5 67.5l-642 1056q-20 34 -48 36.5t-48 -29.5l-642 -1066q-21 -32 -7.5 -66zM155 200l445 723l445 -723h-345v100h-200v-100h-345zM500 600l100 -300l100 300v100h-200v-100z" />
+<glyph unicode="&#xe108;" d="M100 262v41q0 20 11 44.5t26 38.5l363 325v339q0 62 44 106t106 44t106 -44t44 -106v-339l363 -325q15 -14 26 -38.5t11 -44.5v-41q0 -20 -12 -26.5t-29 5.5l-359 249v-263q100 -91 100 -113v-64q0 -20 -13 -28.5t-32 0.5l-94 78h-222l-94 -78q-19 -9 -32 -0.5t-13 28.5 v64q0 22 100 113v263l-359 -249q-17 -12 -29 -5.5t-12 26.5z" />
+<glyph unicode="&#xe109;" d="M0 50q0 -20 14.5 -35t35.5 -15h1000q21 0 35.5 15t14.5 35v750h-1100v-750zM0 900h1100v150q0 21 -14.5 35.5t-35.5 14.5h-150v100h-100v-100h-500v100h-100v-100h-150q-21 0 -35.5 -14.5t-14.5 -35.5v-150zM100 100v100h100v-100h-100zM100 300v100h100v-100h-100z M100 500v100h100v-100h-100zM300 100v100h100v-100h-100zM300 300v100h100v-100h-100zM300 500v100h100v-100h-100zM500 100v100h100v-100h-100zM500 300v100h100v-100h-100zM500 500v100h100v-100h-100zM700 100v100h100v-100h-100zM700 300v100h100v-100h-100zM700 500 v100h100v-100h-100zM900 100v100h100v-100h-100zM900 300v100h100v-100h-100zM900 500v100h100v-100h-100z" />
+<glyph unicode="&#xe110;" d="M0 200v200h259l600 600h241v198l300 -295l-300 -300v197h-159l-600 -600h-341zM0 800h259l122 -122l141 142l-181 180h-341v-200zM678 381l141 142l122 -123h159v198l300 -295l-300 -300v197h-241z" />
+<glyph unicode="&#xe111;" d="M0 400v600q0 41 29.5 70.5t70.5 29.5h1000q41 0 70.5 -29.5t29.5 -70.5v-600q0 -41 -29.5 -70.5t-70.5 -29.5h-596l-304 -300v300h-100q-41 0 -70.5 29.5t-29.5 70.5z" />
+<glyph unicode="&#xe112;" d="M100 600v200h300v-250q0 -113 6 -145q17 -92 102 -117q39 -11 92 -11q37 0 66.5 5.5t50 15.5t36 24t24 31.5t14 37.5t7 42t2.5 45t0 47v25v250h300v-200q0 -42 -3 -83t-15 -104t-31.5 -116t-58 -109.5t-89 -96.5t-129 -65.5t-174.5 -25.5t-174.5 25.5t-129 65.5t-89 96.5 t-58 109.5t-31.5 116t-15 104t-3 83zM100 900v300h300v-300h-300zM800 900v300h300v-300h-300z" />
+<glyph unicode="&#xe113;" d="M-30 411l227 -227l352 353l353 -353l226 227l-578 579z" />
+<glyph unicode="&#xe114;" d="M70 797l580 -579l578 579l-226 227l-353 -353l-352 353z" />
+<glyph unicode="&#xe115;" d="M-198 700l299 283l300 -283h-203v-400h385l215 -200h-800v600h-196zM402 1000l215 -200h381v-400h-198l299 -283l299 283h-200v600h-796z" />
+<glyph unicode="&#xe116;" d="M18 939q-5 24 10 42q14 19 39 19h896l38 162q5 17 18.5 27.5t30.5 10.5h94q20 0 35 -14.5t15 -35.5t-15 -35.5t-35 -14.5h-54l-201 -961q-2 -4 -6 -10.5t-19 -17.5t-33 -11h-31v-50q0 -20 -14.5 -35t-35.5 -15t-35.5 15t-14.5 35v50h-300v-50q0 -20 -14.5 -35t-35.5 -15 t-35.5 15t-14.5 35v50h-50q-21 0 -35.5 15t-14.5 35q0 21 14.5 35.5t35.5 14.5h535l48 200h-633q-32 0 -54.5 21t-27.5 43z" />
+<glyph unicode="&#xe117;" d="M0 0v800h1200v-800h-1200zM0 900v100h200q0 41 29.5 70.5t70.5 29.5h300q41 0 70.5 -29.5t29.5 -70.5h500v-100h-1200z" />
+<glyph unicode="&#xe118;" d="M1 0l300 700h1200l-300 -700h-1200zM1 400v600h200q0 41 29.5 70.5t70.5 29.5h300q41 0 70.5 -29.5t29.5 -70.5h500v-200h-1000z" />
+<glyph unicode="&#xe119;" d="M302 300h198v600h-198l298 300l298 -300h-198v-600h198l-298 -300z" />
+<glyph unicode="&#xe120;" d="M0 600l300 298v-198h600v198l300 -298l-300 -297v197h-600v-197z" />
+<glyph unicode="&#xe121;" d="M0 100v100q0 41 29.5 70.5t70.5 29.5h1000q41 0 70.5 -29.5t29.5 -70.5v-100q0 -41 -29.5 -70.5t-70.5 -29.5h-1000q-41 0 -70.5 29.5t-29.5 70.5zM31 400l172 739q5 22 23 41.5t38 19.5h672q19 0 37.5 -22.5t23.5 -45.5l172 -732h-1138zM800 100h100v100h-100v-100z M1000 100h100v100h-100v-100z" />
+<glyph unicode="&#xe122;" d="M-101 600v50q0 24 25 49t50 38l25 13v-250l-11 5.5t-24 14t-30 21.5t-24 27.5t-11 31.5zM100 500v250v8v8v7t0.5 7t1.5 5.5t2 5t3 4t4.5 3.5t6 1.5t7.5 0.5h200l675 250v-850l-675 200h-38l47 -276q2 -12 -3 -17.5t-11 -6t-21 -0.5h-8h-83q-20 0 -34.5 14t-18.5 35 q-55 337 -55 351zM1100 200v850q0 21 14.5 35.5t35.5 14.5q20 0 35 -14.5t15 -35.5v-850q0 -20 -15 -35t-35 -15q-21 0 -35.5 15t-14.5 35z" />
+<glyph unicode="&#xe123;" d="M74 350q0 21 13.5 35.5t33.5 14.5h18l117 173l63 327q15 77 76 140t144 83l-18 32q-6 19 3 32t29 13h94q20 0 29 -10.5t3 -29.5q-18 -36 -18 -37q83 -19 144 -82.5t76 -140.5l63 -327l118 -173h17q20 0 33.5 -14.5t13.5 -35.5q0 -20 -13 -40t-31 -27q-8 -3 -23 -8.5 t-65 -20t-103 -25t-132.5 -19.5t-158.5 -9q-125 0 -245.5 20.5t-178.5 40.5l-58 20q-18 7 -31 27.5t-13 40.5zM497 110q12 -49 40 -79.5t63 -30.5t63 30.5t39 79.5q-48 -6 -102 -6t-103 6z" />
+<glyph unicode="&#xe124;" d="M21 445l233 -45l-78 -224l224 78l45 -233l155 179l155 -179l45 233l224 -78l-78 224l234 45l-180 155l180 156l-234 44l78 225l-224 -78l-45 233l-155 -180l-155 180l-45 -233l-224 78l78 -225l-233 -44l179 -156z" />
+<glyph unicode="&#xe125;" d="M0 200h200v600h-200v-600zM300 275q0 -75 100 -75h61q124 -100 139 -100h250q46 0 83 57l238 344q29 31 29 74v100q0 44 -30.5 84.5t-69.5 40.5h-328q28 118 28 125v150q0 44 -30.5 84.5t-69.5 40.5h-50q-27 0 -51 -20t-38 -48l-96 -198l-145 -196q-20 -26 -20 -63v-400z M400 300v375l150 213l100 212h50v-175l-50 -225h450v-125l-250 -375h-214l-136 100h-100z" />
+<glyph unicode="&#xe126;" d="M0 400v600h200v-600h-200zM300 525v400q0 75 100 75h61q124 100 139 100h250q46 0 83 -57l238 -344q29 -31 29 -74v-100q0 -44 -30.5 -84.5t-69.5 -40.5h-328q28 -118 28 -125v-150q0 -44 -30.5 -84.5t-69.5 -40.5h-50q-27 0 -51 20t-38 48l-96 198l-145 196 q-20 26 -20 63zM400 525l150 -212l100 -213h50v175l-50 225h450v125l-250 375h-214l-136 -100h-100v-375z" />
+<glyph unicode="&#xe127;" d="M8 200v600h200v-600h-200zM308 275v525q0 17 14 35.5t28 28.5l14 9l362 230q14 6 25 6q17 0 29 -12l109 -112q14 -14 14 -34q0 -18 -11 -32l-85 -121h302q85 0 138.5 -38t53.5 -110t-54.5 -111t-138.5 -39h-107l-130 -339q-7 -22 -20.5 -41.5t-28.5 -19.5h-341 q-7 0 -90 81t-83 94zM408 289l100 -89h293l131 339q6 21 19.5 41t28.5 20h203q16 0 25 15t9 36q0 20 -9 34.5t-25 14.5h-457h-6.5h-7.5t-6.5 0.5t-6 1t-5 1.5t-5.5 2.5t-4 4t-4 5.5q-5 12 -5 20q0 14 10 27l147 183l-86 83l-339 -236v-503z" />
+<glyph unicode="&#xe128;" d="M-101 651q0 72 54 110t139 38l302 -1l-85 121q-11 16 -11 32q0 21 14 34l109 113q13 12 29 12q11 0 25 -6l365 -230q7 -4 17 -10.5t26.5 -26t16.5 -36.5v-526q0 -13 -86 -93.5t-94 -80.5h-341q-16 0 -29.5 20t-19.5 41l-130 339h-107q-84 0 -139 39t-55 111zM-1 601h222 q15 0 28.5 -20.5t19.5 -40.5l131 -339h293l107 89v502l-343 237l-87 -83l145 -184q10 -11 10 -26q0 -11 -5 -20q-1 -3 -3.5 -5.5l-4 -4t-5 -2.5t-5.5 -1.5t-6.5 -1t-6.5 -0.5h-7.5h-6.5h-476v-100zM1000 201v600h200v-600h-200z" />
+<glyph unicode="&#xe129;" d="M97 719l230 -363q4 -6 10.5 -15.5t26 -25t36.5 -15.5h525q13 0 94 83t81 90v342q0 15 -20 28.5t-41 19.5l-339 131v106q0 84 -39 139t-111 55t-110 -53.5t-38 -138.5v-302l-121 84q-15 12 -33.5 11.5t-32.5 -13.5l-112 -110q-22 -22 -6 -53zM172 739l83 86l183 -146 q22 -18 47 -5q3 1 5.5 3.5l4 4t2.5 5t1.5 5.5t1 6.5t0.5 6.5v7.5v6.5v456q0 22 25 31t50 -0.5t25 -30.5v-202q0 -16 20 -29.5t41 -19.5l339 -130v-294l-89 -100h-503zM400 0v200h600v-200h-600z" />
+<glyph unicode="&#xe130;" d="M2 585q-16 -31 6 -53l112 -110q13 -13 32 -13.5t34 10.5l121 85q0 -51 -0.5 -153.5t-0.5 -148.5q0 -84 38.5 -138t110.5 -54t111 55t39 139v106l339 131q20 6 40.5 19.5t20.5 28.5v342q0 7 -81 90t-94 83h-525q-17 0 -35.5 -14t-28.5 -28l-10 -15zM77 565l236 339h503 l89 -100v-294l-340 -130q-20 -6 -40 -20t-20 -29v-202q0 -22 -25 -31t-50 0t-25 31v456v14.5t-1.5 11.5t-5 12t-9.5 7q-24 13 -46 -5l-184 -146zM305 1104v200h600v-200h-600z" />
+<glyph unicode="&#xe131;" d="M5 597q0 122 47.5 232.5t127.5 190.5t190.5 127.5t232.5 47.5q162 0 299.5 -80t217.5 -218t80 -300t-80 -299.5t-217.5 -217.5t-299.5 -80t-300 80t-218 217.5t-80 299.5zM298 701l2 -201h300l-2 -194l402 294l-402 298v-197h-300z" />
+<glyph unicode="&#xe132;" d="M0 597q0 122 47.5 232.5t127.5 190.5t190.5 127.5t231.5 47.5q122 0 232.5 -47.5t190.5 -127.5t127.5 -190.5t47.5 -232.5q0 -162 -80 -299.5t-218 -217.5t-300 -80t-299.5 80t-217.5 217.5t-80 299.5zM200 600l402 -294l-2 194h300l2 201h-300v197z" />
+<glyph unicode="&#xe133;" d="M5 597q0 122 47.5 232.5t127.5 190.5t190.5 127.5t232.5 47.5q162 0 299.5 -80t217.5 -218t80 -300t-80 -299.5t-217.5 -217.5t-299.5 -80t-300 80t-218 217.5t-80 299.5zM300 600h200v-300h200v300h200l-300 400z" />
+<glyph unicode="&#xe134;" d="M5 597q0 122 47.5 232.5t127.5 190.5t190.5 127.5t232.5 47.5q162 0 299.5 -80t217.5 -218t80 -300t-80 -299.5t-217.5 -217.5t-299.5 -80t-300 80t-218 217.5t-80 299.5zM300 600l300 -400l300 400h-200v300h-200v-300h-200z" />
+<glyph unicode="&#xe135;" d="M5 597q0 122 47.5 232.5t127.5 190.5t190.5 127.5t232.5 47.5q121 0 231.5 -47.5t190.5 -127.5t127.5 -190.5t47.5 -232.5q0 -162 -80 -299.5t-217.5 -217.5t-299.5 -80t-300 80t-218 217.5t-80 299.5zM254 780q-8 -33 5.5 -92.5t7.5 -87.5q0 -9 17 -44t16 -60 q12 0 23 -5.5t23 -15t20 -13.5q24 -12 108 -42q22 -8 53 -31.5t59.5 -38.5t57.5 -11q8 -18 -15 -55t-20 -57q42 -71 87 -80q0 -6 -3 -15.5t-3.5 -14.5t4.5 -17q104 -3 221 112q30 29 47 47t34.5 49t20.5 62q-14 9 -37 9.5t-36 7.5q-14 7 -49 15t-52 19q-9 0 -39.5 -0.5 t-46.5 -1.5t-39 -6.5t-39 -16.5q-50 -35 -66 -12q-4 2 -3.5 25.5t0.5 25.5q-6 13 -26.5 17t-24.5 7q2 22 -2 41t-16.5 28t-38.5 -20q-23 -25 -42 4q-19 28 -8 58q6 16 22 22q6 -1 26 -1.5t33.5 -4t19.5 -13.5q12 -19 32 -37.5t34 -27.5l14 -8q0 3 9.5 39.5t5.5 57.5 q-4 23 14.5 44.5t22.5 31.5q5 14 10 35t8.5 31t15.5 22.5t34 21.5q-6 18 10 37q8 0 23.5 -1.5t24.5 -1.5t20.5 4.5t20.5 15.5q-10 23 -30.5 42.5t-38 30t-49 26.5t-43.5 23q11 39 2 44q31 -13 58 -14.5t39 3.5l11 4q7 36 -16.5 53.5t-64.5 28.5t-56 23q-19 -3 -37 0 q-15 -12 -36.5 -21t-34.5 -12t-44 -8t-39 -6q-15 -3 -45.5 0.5t-45.5 -2.5q-21 -7 -52 -26.5t-34 -34.5q-3 -11 6.5 -22.5t8.5 -18.5q-3 -34 -27.5 -90.5t-29.5 -79.5zM518 916q3 12 16 30t16 25q10 -10 18.5 -10t14 6t14.5 14.5t16 12.5q0 -24 17 -66.5t17 -43.5 q-9 2 -31 5t-36 5t-32 8t-30 14zM692 1003h1h-1z" />
+<glyph unicode="&#xe136;" d="M0 164.5q0 21.5 15 37.5l600 599q-33 101 6 201.5t135 154.5q164 92 306 -9l-259 -138l145 -232l251 126q13 -175 -151 -267q-123 -70 -253 -23l-596 -596q-15 -16 -36.5 -16t-36.5 16l-111 110q-15 15 -15 36.5z" />
+<glyph unicode="&#xe137;" horiz-adv-x="1220" d="M0 196v100q0 41 29.5 70.5t70.5 29.5h1000q41 0 70.5 -29.5t29.5 -70.5v-100q0 -41 -29.5 -70.5t-70.5 -29.5h-1000q-41 0 -70.5 29.5t-29.5 70.5zM0 596v100q0 41 29.5 70.5t70.5 29.5h1000q41 0 70.5 -29.5t29.5 -70.5v-100q0 -41 -29.5 -70.5t-70.5 -29.5h-1000 q-41 0 -70.5 29.5t-29.5 70.5zM0 996v100q0 41 29.5 70.5t70.5 29.5h1000q41 0 70.5 -29.5t29.5 -70.5v-100q0 -41 -29.5 -70.5t-70.5 -29.5h-1000q-41 0 -70.5 29.5t-29.5 70.5zM600 596h500v100h-500v-100zM800 196h300v100h-300v-100zM900 996h200v100h-200v-100z" />
+<glyph unicode="&#xe138;" d="M100 1100v100h1000v-100h-1000zM150 1000h900l-350 -500v-300l-200 -200v500z" />
+<glyph unicode="&#xe139;" d="M0 200v200h1200v-200q0 -41 -29.5 -70.5t-70.5 -29.5h-1000q-41 0 -70.5 29.5t-29.5 70.5zM0 500v400q0 41 29.5 70.5t70.5 29.5h300v100q0 41 29.5 70.5t70.5 29.5h200q41 0 70.5 -29.5t29.5 -70.5v-100h300q41 0 70.5 -29.5t29.5 -70.5v-400h-500v100h-200v-100h-500z M500 1000h200v100h-200v-100z" />
+<glyph unicode="&#xe140;" d="M0 0v400l129 -129l200 200l142 -142l-200 -200l129 -129h-400zM0 800l129 129l200 -200l142 142l-200 200l129 129h-400v-400zM729 329l142 142l200 -200l129 129v-400h-400l129 129zM729 871l200 200l-129 129h400v-400l-129 129l-200 -200z" />
+<glyph unicode="&#xe141;" d="M0 596q0 162 80 299t217 217t299 80t299 -80t217 -217t80 -299t-80 -299t-217 -217t-299 -80t-299 80t-217 217t-80 299zM182 596q0 -172 121.5 -293t292.5 -121t292.5 121t121.5 293q0 171 -121.5 292.5t-292.5 121.5t-292.5 -121.5t-121.5 -292.5zM291 655 q0 23 15.5 38.5t38.5 15.5t39 -16t16 -38q0 -23 -16 -39t-39 -16q-22 0 -38 16t-16 39zM400 850q0 22 16 38.5t39 16.5q22 0 38 -16t16 -39t-16 -39t-38 -16q-23 0 -39 16.5t-16 38.5zM514 609q0 32 20.5 56.5t51.5 29.5l122 126l1 1q-9 14 -9 28q0 22 16 38.5t39 16.5 q22 0 38 -16t16 -39t-16 -39t-38 -16q-14 0 -29 10l-55 -145q17 -22 17 -51q0 -36 -25.5 -61.5t-61.5 -25.5t-61.5 25.5t-25.5 61.5zM800 655q0 22 16 38t39 16t38.5 -15.5t15.5 -38.5t-16 -39t-38 -16q-23 0 -39 16t-16 39z" />
+<glyph unicode="&#xe142;" d="M-40 375q-13 -95 35 -173q35 -57 94 -89t129 -32q63 0 119 28q33 16 65 40.5t52.5 45.5t59.5 64q40 44 57 61l394 394q35 35 47 84t-3 96q-27 87 -117 104q-20 2 -29 2q-46 0 -78.5 -16.5t-67.5 -51.5l-389 -396l-7 -7l69 -67l377 373q20 22 39 38q23 23 50 23 q38 0 53 -36q16 -39 -20 -75l-547 -547q-52 -52 -125 -52q-55 0 -100 33t-54 96q-5 35 2.5 66t31.5 63t42 50t56 54q24 21 44 41l348 348q52 52 82.5 79.5t84 54t107.5 26.5q25 0 48 -4q95 -17 154 -94.5t51 -175.5q-7 -101 -98 -192l-252 -249l-253 -256l7 -7l69 -60 l517 511q67 67 95 157t11 183q-16 87 -67 154t-130 103q-69 33 -152 33q-107 0 -197 -55q-40 -24 -111 -95l-512 -512q-68 -68 -81 -163z" />
+<glyph unicode="&#xe143;" d="M80 784q0 131 98.5 229.5t230.5 98.5q143 0 241 -129q103 129 246 129q129 0 226 -98.5t97 -229.5q0 -46 -17.5 -91t-61 -99t-77 -89.5t-104.5 -105.5q-197 -191 -293 -322l-17 -23l-16 23q-43 58 -100 122.5t-92 99.5t-101 100q-71 70 -104.5 105.5t-77 89.5t-61 99 t-17.5 91zM250 784q0 -27 30.5 -70t61.5 -75.5t95 -94.5l22 -22q93 -90 190 -201q82 92 195 203l12 12q64 62 97.5 97t64.5 79t31 72q0 71 -48 119.5t-105 48.5q-74 0 -132 -83l-118 -171l-114 174q-51 80 -123 80q-60 0 -109.5 -49.5t-49.5 -118.5z" />
+<glyph unicode="&#xe144;" d="M57 353q0 -95 66 -159l141 -142q68 -66 159 -66q93 0 159 66l283 283q66 66 66 159t-66 159l-141 141q-8 9 -19 17l-105 -105l212 -212l-389 -389l-247 248l95 95l-18 18q-46 45 -75 101l-55 -55q-66 -66 -66 -159zM269 706q0 -93 66 -159l141 -141q7 -7 19 -17l105 105 l-212 212l389 389l247 -247l-95 -96l18 -17q47 -49 77 -100l29 29q35 35 62.5 88t27.5 96q0 93 -66 159l-141 141q-66 66 -159 66q-95 0 -159 -66l-283 -283q-66 -64 -66 -159z" />
+<glyph unicode="&#xe145;" d="M200 100v953q0 21 30 46t81 48t129 38t163 15t162 -15t127 -38t79 -48t29 -46v-953q0 -41 -29.5 -70.5t-70.5 -29.5h-600q-41 0 -70.5 29.5t-29.5 70.5zM300 300h600v700h-600v-700zM496 150q0 -43 30.5 -73.5t73.5 -30.5t73.5 30.5t30.5 73.5t-30.5 73.5t-73.5 30.5 t-73.5 -30.5t-30.5 -73.5z" />
+<glyph unicode="&#xe146;" d="M0 0l303 380l207 208l-210 212h300l267 279l-35 36q-15 14 -15 35t15 35q14 15 35 15t35 -15l283 -282q15 -15 15 -36t-15 -35q-14 -15 -35 -15t-35 15l-36 35l-279 -267v-300l-212 210l-208 -207z" />
+<glyph unicode="&#xe148;" d="M295 433h139q5 -77 48.5 -126.5t117.5 -64.5v335q-6 1 -15.5 4t-11.5 3q-46 14 -79 26.5t-72 36t-62.5 52t-40 72.5t-16.5 99q0 92 44 159.5t109 101t144 40.5v78h100v-79q38 -4 72.5 -13.5t75.5 -31.5t71 -53.5t51.5 -84t24.5 -118.5h-159q-8 72 -35 109.5t-101 50.5 v-307l64 -14q34 -7 64 -16.5t70 -31.5t67.5 -52t47.5 -80.5t20 -112.5q0 -139 -89 -224t-244 -96v-77h-100v78q-152 17 -237 104q-40 40 -52.5 93.5t-15.5 139.5zM466 889q0 -29 8 -51t16.5 -34t29.5 -22.5t31 -13.5t38 -10q7 -2 11 -3v274q-61 -8 -97.5 -37.5t-36.5 -102.5 zM700 237q170 18 170 151q0 64 -44 99.5t-126 60.5v-311z" />
+<glyph unicode="&#xe149;" d="M100 600v100h166q-24 49 -44 104q-10 26 -14.5 55.5t-3 72.5t25 90t68.5 87q97 88 263 88q129 0 230 -89t101 -208h-153q0 52 -34 89.5t-74 51.5t-76 14q-37 0 -79 -14.5t-62 -35.5q-41 -44 -41 -101q0 -28 16.5 -69.5t28 -62.5t41.5 -72h241v-100h-197q8 -50 -2.5 -115 t-31.5 -94q-41 -59 -99 -113q35 11 84 18t70 7q33 1 103 -16t103 -17q76 0 136 30l50 -147q-41 -25 -80.5 -36.5t-59 -13t-61.5 -1.5q-23 0 -128 33t-155 29q-39 -4 -82 -17t-66 -25l-24 -11l-55 145l16.5 11t15.5 10t13.5 9.5t14.5 12t14.5 14t17.5 18.5q48 55 54 126.5 t-30 142.5h-221z" />
+<glyph unicode="&#xe150;" d="M2 300l298 -300l298 300h-198v900h-200v-900h-198zM602 900l298 300l298 -300h-198v-900h-200v900h-198z" />
+<glyph unicode="&#xe151;" d="M2 300h198v900h200v-900h198l-298 -300zM700 0v200h100v-100h200v-100h-300zM700 400v100h300v-200h-99v-100h-100v100h99v100h-200zM700 700v500h300v-500h-100v100h-100v-100h-100zM801 900h100v200h-100v-200z" />
+<glyph unicode="&#xe152;" d="M2 300h198v900h200v-900h198l-298 -300zM700 0v500h300v-500h-100v100h-100v-100h-100zM700 700v200h100v-100h200v-100h-300zM700 1100v100h300v-200h-99v-100h-100v100h99v100h-200zM801 200h100v200h-100v-200z" />
+<glyph unicode="&#xe153;" d="M2 300l298 -300l298 300h-198v900h-200v-900h-198zM800 100v400h300v-500h-100v100h-200zM800 1100v100h200v-500h-100v400h-100zM901 200h100v200h-100v-200z" />
+<glyph unicode="&#xe154;" d="M2 300l298 -300l298 300h-198v900h-200v-900h-198zM800 400v100h200v-500h-100v400h-100zM800 800v400h300v-500h-100v100h-200zM901 900h100v200h-100v-200z" />
+<glyph unicode="&#xe155;" d="M2 300l298 -300l298 300h-198v900h-200v-900h-198zM700 100v200h500v-200h-500zM700 400v200h400v-200h-400zM700 700v200h300v-200h-300zM700 1000v200h200v-200h-200z" />
+<glyph unicode="&#xe156;" d="M2 300l298 -300l298 300h-198v900h-200v-900h-198zM700 100v200h200v-200h-200zM700 400v200h300v-200h-300zM700 700v200h400v-200h-400zM700 1000v200h500v-200h-500z" />
+<glyph unicode="&#xe157;" d="M0 400v300q0 165 117.5 282.5t282.5 117.5h300q162 0 281 -118.5t119 -281.5v-300q0 -165 -118.5 -282.5t-281.5 -117.5h-300q-165 0 -282.5 117.5t-117.5 282.5zM200 300q0 -41 29.5 -70.5t70.5 -29.5h500q41 0 70.5 29.5t29.5 70.5v500q0 41 -29.5 70.5t-70.5 29.5 h-500q-41 0 -70.5 -29.5t-29.5 -70.5v-500z" />
+<glyph unicode="&#xe158;" d="M0 400v300q0 163 119 281.5t281 118.5h300q165 0 282.5 -117.5t117.5 -282.5v-300q0 -165 -117.5 -282.5t-282.5 -117.5h-300q-163 0 -281.5 117.5t-118.5 282.5zM200 300q0 -41 29.5 -70.5t70.5 -29.5h500q41 0 70.5 29.5t29.5 70.5v500q0 41 -29.5 70.5t-70.5 29.5 h-500q-41 0 -70.5 -29.5t-29.5 -70.5v-500zM400 300l333 250l-333 250v-500z" />
+<glyph unicode="&#xe159;" d="M0 400v300q0 163 117.5 281.5t282.5 118.5h300q163 0 281.5 -119t118.5 -281v-300q0 -165 -117.5 -282.5t-282.5 -117.5h-300q-165 0 -282.5 117.5t-117.5 282.5zM200 300q0 -41 29.5 -70.5t70.5 -29.5h500q41 0 70.5 29.5t29.5 70.5v500q0 41 -29.5 70.5t-70.5 29.5 h-500q-41 0 -70.5 -29.5t-29.5 -70.5v-500zM300 700l250 -333l250 333h-500z" />
+<glyph unicode="&#xe160;" d="M0 400v300q0 165 117.5 282.5t282.5 117.5h300q165 0 282.5 -117.5t117.5 -282.5v-300q0 -162 -118.5 -281t-281.5 -119h-300q-165 0 -282.5 118.5t-117.5 281.5zM200 300q0 -41 29.5 -70.5t70.5 -29.5h500q41 0 70.5 29.5t29.5 70.5v500q0 41 -29.5 70.5t-70.5 29.5 h-500q-41 0 -70.5 -29.5t-29.5 -70.5v-500zM300 400h500l-250 333z" />
+<glyph unicode="&#xe161;" d="M0 400v300h300v200l400 -350l-400 -350v200h-300zM500 0v200h500q41 0 70.5 29.5t29.5 70.5v500q0 41 -29.5 70.5t-70.5 29.5h-500v200h400q165 0 282.5 -117.5t117.5 -282.5v-300q0 -165 -117.5 -282.5t-282.5 -117.5h-400z" />
+<glyph unicode="&#xe162;" d="M217 519q8 -19 31 -19h302q-155 -438 -160 -458q-5 -21 4 -32l9 -8h9q14 0 26 15q11 13 274.5 321.5t264.5 308.5q14 19 5 36q-8 17 -31 17l-301 -1q1 4 78 219.5t79 227.5q2 15 -5 27l-9 9h-9q-15 0 -25 -16q-4 -6 -98 -111.5t-228.5 -257t-209.5 -237.5q-16 -19 -6 -41 z" />
+<glyph unicode="&#xe163;" d="M0 400q0 -165 117.5 -282.5t282.5 -117.5h300q47 0 100 15v185h-500q-41 0 -70.5 29.5t-29.5 70.5v500q0 41 29.5 70.5t70.5 29.5h500v185q-14 4 -114 7.5t-193 5.5l-93 2q-165 0 -282.5 -117.5t-117.5 -282.5v-300zM600 400v300h300v200l400 -350l-400 -350v200h-300z " />
+<glyph unicode="&#xe164;" d="M0 400q0 -165 117.5 -282.5t282.5 -117.5h300q163 0 281.5 117.5t118.5 282.5v98l-78 73l-122 -123v-148q0 -41 -29.5 -70.5t-70.5 -29.5h-500q-41 0 -70.5 29.5t-29.5 70.5v500q0 41 29.5 70.5t70.5 29.5h156l118 122l-74 78h-100q-165 0 -282.5 -117.5t-117.5 -282.5 v-300zM496 709l353 342l-149 149h500v-500l-149 149l-342 -353z" />
+<glyph unicode="&#xe165;" d="M4 600q0 162 80 299t217 217t299 80t299 -80t217 -217t80 -299t-80 -299t-217 -217t-299 -80t-299 80t-217 217t-80 299zM186 600q0 -171 121.5 -292.5t292.5 -121.5t292.5 121.5t121.5 292.5t-121.5 292.5t-292.5 121.5t-292.5 -121.5t-121.5 -292.5zM406 600 q0 80 57 137t137 57t137 -57t57 -137t-57 -137t-137 -57t-137 57t-57 137z" />
+<glyph unicode="&#xe166;" d="M0 0v275q0 11 7 18t18 7h1048q11 0 19 -7.5t8 -17.5v-275h-1100zM100 800l445 -500l450 500h-295v400h-300v-400h-300zM900 150h100v50h-100v-50z" />
+<glyph unicode="&#xe167;" d="M0 0v275q0 11 7 18t18 7h1048q11 0 19 -7.5t8 -17.5v-275h-1100zM100 700h300v-300h300v300h295l-445 500zM900 150h100v50h-100v-50z" />
+<glyph unicode="&#xe168;" d="M0 0v275q0 11 7 18t18 7h1048q11 0 19 -7.5t8 -17.5v-275h-1100zM100 705l305 -305l596 596l-154 155l-442 -442l-150 151zM900 150h100v50h-100v-50z" />
+<glyph unicode="&#xe169;" d="M0 0v275q0 11 7 18t18 7h1048q11 0 19 -7.5t8 -17.5v-275h-1100zM100 988l97 -98l212 213l-97 97zM200 400l697 1l3 699l-250 -239l-149 149l-212 -212l149 -149zM900 150h100v50h-100v-50z" />
+<glyph unicode="&#xe170;" d="M0 0v275q0 11 7 18t18 7h1048q11 0 19 -7.5t8 -17.5v-275h-1100zM200 612l212 -212l98 97l-213 212zM300 1200l239 -250l-149 -149l212 -212l149 148l249 -237l-1 697zM900 150h100v50h-100v-50z" />
+<glyph unicode="&#xe171;" d="M23 415l1177 784v-1079l-475 272l-310 -393v416h-392zM494 210l672 938l-672 -712v-226z" />
+<glyph unicode="&#xe172;" d="M0 150v1000q0 20 14.5 35t35.5 15h250v-300h500v300h100l200 -200v-850q0 -21 -15 -35.5t-35 -14.5h-150v400h-700v-400h-150q-21 0 -35.5 14.5t-14.5 35.5zM600 1000h100v200h-100v-200z" />
+<glyph unicode="&#xe173;" d="M0 150v1000q0 20 14.5 35t35.5 15h250v-300h500v300h100l200 -200v-218l-276 -275l-120 120l-126 -127h-378v-400h-150q-21 0 -35.5 14.5t-14.5 35.5zM581 306l123 123l120 -120l353 352l123 -123l-475 -476zM600 1000h100v200h-100v-200z" />
+<glyph unicode="&#xe174;" d="M0 150v1000q0 20 14.5 35t35.5 15h250v-300h500v300h100l200 -200v-269l-103 -103l-170 170l-298 -298h-329v-400h-150q-21 0 -35.5 14.5t-14.5 35.5zM600 1000h100v200h-100v-200zM700 133l170 170l-170 170l127 127l170 -170l170 170l127 -128l-170 -169l170 -170 l-127 -127l-170 170l-170 -170z" />
+<glyph unicode="&#xe175;" d="M0 150v1000q0 20 14.5 35t35.5 15h250v-300h500v300h100l200 -200v-300h-400v-200h-500v-400h-150q-21 0 -35.5 14.5t-14.5 35.5zM600 300l300 -300l300 300h-200v300h-200v-300h-200zM600 1000v200h100v-200h-100z" />
+<glyph unicode="&#xe176;" d="M0 150v1000q0 20 14.5 35t35.5 15h250v-300h500v300h100l200 -200v-402l-200 200l-298 -298h-402v-400h-150q-21 0 -35.5 14.5t-14.5 35.5zM600 300h200v-300h200v300h200l-300 300zM600 1000v200h100v-200h-100z" />
+<glyph unicode="&#xe177;" d="M0 250q0 -21 14.5 -35.5t35.5 -14.5h1100q21 0 35.5 14.5t14.5 35.5v550h-1200v-550zM0 900h1200v150q0 21 -14.5 35.5t-35.5 14.5h-1100q-21 0 -35.5 -14.5t-14.5 -35.5v-150zM100 300v200h400v-200h-400z" />
+<glyph unicode="&#xe178;" d="M0 400l300 298v-198h400v-200h-400v-198zM100 800v200h100v-200h-100zM300 800v200h100v-200h-100zM500 800v200h400v198l300 -298l-300 -298v198h-400zM800 300v200h100v-200h-100zM1000 300h100v200h-100v-200z" />
+<glyph unicode="&#xe179;" d="M100 700v400l50 100l50 -100v-300h100v300l50 100l50 -100v-300h100v300l50 100l50 -100v-400l-100 -203v-447q0 -21 -14.5 -35.5t-35.5 -14.5h-200q-21 0 -35.5 14.5t-14.5 35.5v447zM800 597q0 -29 10.5 -55.5t25 -43t29 -28.5t25.5 -18l10 -5v-397q0 -21 14.5 -35.5 t35.5 -14.5h200q21 0 35.5 14.5t14.5 35.5v1106q0 31 -18 40.5t-44 -7.5l-276 -116q-25 -17 -43.5 -51.5t-18.5 -65.5v-359z" />
+<glyph unicode="&#xe180;" d="M100 0h400v56q-75 0 -87.5 6t-12.5 44v394h500v-394q0 -38 -12.5 -44t-87.5 -6v-56h400v56q-4 0 -11 0.5t-24 3t-30 7t-24 15t-11 24.5v888q0 22 25 34.5t50 13.5l25 2v56h-400v-56q75 0 87.5 -6t12.5 -44v-394h-500v394q0 38 12.5 44t87.5 6v56h-400v-56q4 0 11 -0.5 t24 -3t30 -7t24 -15t11 -24.5v-888q0 -22 -25 -34.5t-50 -13.5l-25 -2v-56z" />
+<glyph unicode="&#xe181;" d="M0 300q0 -41 29.5 -70.5t70.5 -29.5h300q41 0 70.5 29.5t29.5 70.5v500q0 41 -29.5 70.5t-70.5 29.5h-300q-41 0 -70.5 -29.5t-29.5 -70.5v-500zM100 100h400l200 200h105l295 98v-298h-425l-100 -100h-375zM100 300v200h300v-200h-300zM100 600v200h300v-200h-300z M100 1000h400l200 -200v-98l295 98h105v200h-425l-100 100h-375zM700 402v163l400 133v-163z" />
+<glyph unicode="&#xe182;" d="M16.5 974.5q0.5 -21.5 16 -90t46.5 -140t104 -177.5t175 -208q103 -103 207.5 -176t180 -103.5t137 -47t92.5 -16.5l31 1l163 162q17 18 13.5 41t-22.5 37l-192 136q-19 14 -45 12t-42 -19l-118 -118q-142 101 -268 227t-227 268l118 118q17 17 20 41.5t-11 44.5 l-139 194q-14 19 -36.5 22t-40.5 -14l-162 -162q-1 -11 -0.5 -32.5z" />
+<glyph unicode="&#xe183;" d="M0 50v212q0 20 10.5 45.5t24.5 39.5l365 303v50q0 4 1 10.5t12 22.5t30 28.5t60 23t97 10.5t97 -10t60 -23.5t30 -27.5t12 -24l1 -10v-50l365 -303q14 -14 24.5 -39.5t10.5 -45.5v-212q0 -21 -14.5 -35.5t-35.5 -14.5h-1100q-20 0 -35 14.5t-15 35.5zM0 712 q0 -21 14.5 -33.5t34.5 -8.5l202 33q20 4 34.5 21t14.5 38v146q141 24 300 24t300 -24v-146q0 -21 14.5 -38t34.5 -21l202 -33q20 -4 34.5 8.5t14.5 33.5v200q-6 8 -19 20.5t-63 45t-112 57t-171 45t-235 20.5q-92 0 -175 -10.5t-141.5 -27t-108.5 -36.5t-81.5 -40 t-53.5 -36.5t-31 -27.5l-9 -10v-200z" />
+<glyph unicode="&#xe184;" d="M100 0v100h1100v-100h-1100zM175 200h950l-125 150v250l100 100v400h-100v-200h-100v200h-200v-200h-100v200h-200v-200h-100v200h-100v-400l100 -100v-250z" />
+<glyph unicode="&#xe185;" d="M100 0h300v400q0 41 -29.5 70.5t-70.5 29.5h-100q-41 0 -70.5 -29.5t-29.5 -70.5v-400zM500 0v1000q0 41 29.5 70.5t70.5 29.5h100q41 0 70.5 -29.5t29.5 -70.5v-1000h-300zM900 0v700q0 41 29.5 70.5t70.5 29.5h100q41 0 70.5 -29.5t29.5 -70.5v-700h-300z" />
+<glyph unicode="&#xe186;" d="M-100 300v500q0 124 88 212t212 88h700q124 0 212 -88t88 -212v-500q0 -124 -88 -212t-212 -88h-700q-124 0 -212 88t-88 212zM100 200h900v700h-900v-700zM200 300h300v300h-200v100h200v100h-300v-300h200v-100h-200v-100zM600 300h200v100h100v300h-100v100h-200v-500 zM700 400v300h100v-300h-100z" />
+<glyph unicode="&#xe187;" d="M-100 300v500q0 124 88 212t212 88h700q124 0 212 -88t88 -212v-500q0 -124 -88 -212t-212 -88h-700q-124 0 -212 88t-88 212zM100 200h900v700h-900v-700zM200 300h100v200h100v-200h100v500h-100v-200h-100v200h-100v-500zM600 300h200v100h100v300h-100v100h-200v-500 zM700 400v300h100v-300h-100z" />
+<glyph unicode="&#xe188;" d="M-100 300v500q0 124 88 212t212 88h700q124 0 212 -88t88 -212v-500q0 -124 -88 -212t-212 -88h-700q-124 0 -212 88t-88 212zM100 200h900v700h-900v-700zM200 300h300v100h-200v300h200v100h-300v-500zM600 300h300v100h-200v300h200v100h-300v-500z" />
+<glyph unicode="&#xe189;" d="M-100 300v500q0 124 88 212t212 88h700q124 0 212 -88t88 -212v-500q0 -124 -88 -212t-212 -88h-700q-124 0 -212 88t-88 212zM100 200h900v700h-900v-700zM200 550l300 -150v300zM600 400l300 150l-300 150v-300z" />
+<glyph unicode="&#xe190;" d="M-100 300v500q0 124 88 212t212 88h700q124 0 212 -88t88 -212v-500q0 -124 -88 -212t-212 -88h-700q-124 0 -212 88t-88 212zM100 200h900v700h-900v-700zM200 300v500h700v-500h-700zM300 400h130q41 0 68 42t27 107t-28.5 108t-66.5 43h-130v-300zM575 549 q0 -65 27 -107t68 -42h130v300h-130q-38 0 -66.5 -43t-28.5 -108z" />
+<glyph unicode="&#xe191;" d="M-100 300v500q0 124 88 212t212 88h700q124 0 212 -88t88 -212v-500q0 -124 -88 -212t-212 -88h-700q-124 0 -212 88t-88 212zM100 200h900v700h-900v-700zM200 300h300v300h-200v100h200v100h-300v-300h200v-100h-200v-100zM601 300h100v100h-100v-100zM700 700h100 v-400h100v500h-200v-100z" />
+<glyph unicode="&#xe192;" d="M-100 300v500q0 124 88 212t212 88h700q124 0 212 -88t88 -212v-500q0 -124 -88 -212t-212 -88h-700q-124 0 -212 88t-88 212zM100 200h900v700h-900v-700zM200 300h300v400h-200v100h-100v-500zM301 400v200h100v-200h-100zM601 300h100v100h-100v-100zM700 700h100 v-400h100v500h-200v-100z" />
+<glyph unicode="&#xe193;" d="M-100 300v500q0 124 88 212t212 88h700q124 0 212 -88t88 -212v-500q0 -124 -88 -212t-212 -88h-700q-124 0 -212 88t-88 212zM100 200h900v700h-900v-700zM200 700v100h300v-300h-99v-100h-100v100h99v200h-200zM201 300v100h100v-100h-100zM601 300v100h100v-100h-100z M700 700v100h200v-500h-100v400h-100z" />
+<glyph unicode="&#xe194;" d="M4 600q0 162 80 299t217 217t299 80t299 -80t217 -217t80 -299t-80 -299t-217 -217t-299 -80t-299 80t-217 217t-80 299zM186 600q0 -171 121.5 -292.5t292.5 -121.5t292.5 121.5t121.5 292.5t-121.5 292.5t-292.5 121.5t-292.5 -121.5t-121.5 -292.5zM400 500v200 l100 100h300v-100h-300v-200h300v-100h-300z" />
+<glyph unicode="&#xe195;" d="M0 600q0 162 80 299t217 217t299 80t299 -80t217 -217t80 -299t-80 -299t-217 -217t-299 -80t-299 80t-217 217t-80 299zM182 600q0 -171 121.5 -292.5t292.5 -121.5t292.5 121.5t121.5 292.5t-121.5 292.5t-292.5 121.5t-292.5 -121.5t-121.5 -292.5zM400 400v400h300 l100 -100v-100h-100v100h-200v-100h200v-100h-200v-100h-100zM700 400v100h100v-100h-100z" />
+<glyph unicode="&#xe197;" d="M-14 494q0 -80 56.5 -137t135.5 -57h222v300h400v-300h128q120 0 205 86.5t85 207.5t-85 207t-205 86q-46 0 -90 -14q-44 97 -134.5 156.5t-200.5 59.5q-152 0 -260 -107.5t-108 -260.5q0 -25 2 -37q-66 -14 -108.5 -67.5t-42.5 -122.5zM300 200h200v300h200v-300h200 l-300 -300z" />
+<glyph unicode="&#xe198;" d="M-14 494q0 -80 56.5 -137t135.5 -57h8l414 414l403 -403q94 26 154.5 104.5t60.5 178.5q0 120 -85 206.5t-205 86.5q-46 0 -90 -14q-44 97 -134.5 156.5t-200.5 59.5q-152 0 -260 -107.5t-108 -260.5q0 -25 2 -37q-66 -14 -108.5 -67.5t-42.5 -122.5zM300 200l300 300 l300 -300h-200v-300h-200v300h-200z" />
+<glyph unicode="&#xe199;" d="M100 200h400v-155l-75 -45h350l-75 45v155h400l-270 300h170l-270 300h170l-300 333l-300 -333h170l-270 -300h170z" />
+<glyph unicode="&#xe200;" d="M121 700q0 -53 28.5 -97t75.5 -65q-4 -16 -4 -38q0 -74 52.5 -126.5t126.5 -52.5q56 0 100 30v-306l-75 -45h350l-75 45v306q46 -30 100 -30q74 0 126.5 52.5t52.5 126.5q0 24 -9 55q50 32 79.5 83t29.5 112q0 90 -61.5 155.5t-150.5 71.5q-26 89 -99.5 145.5 t-167.5 56.5q-116 0 -197.5 -81.5t-81.5 -197.5q0 -4 1 -11.5t1 -11.5q-14 2 -23 2q-74 0 -126.5 -52.5t-52.5 -126.5z" />
+</font>
+</defs></svg> 
\ No newline at end of file
diff --git a/static/fonts/glyphicons-halflings-regular.ttf b/static/fonts/glyphicons-halflings-regular.ttf
new file mode 100644
index 0000000000000000000000000000000000000000..67fa00bf83801d2fa568546b982c80d27f6ef74e
GIT binary patch
literal 41280
zcmc${2b>$#wLd<0X4JKkMs=IoY9(#guC%-Ix~!LV@5XgawLzwtVoFRi&4B<;Yzzq|
z1QHw)z@da0*@PsIyqA!`6G@b6oWOe_b_$P#@)GbXG2Zd-d+unfZAkvV-{<pRThcUX
z?mhS1bI<vnG6E9>LBX3Wc;?Pswd9i3FaAXkSUrx`&zn7GF0<l{z@}h7wrpi4d*Ks{
zZpZ!*_Sc_(*@n#v|6=<B_P;3z;#KEwxh5twNq6GM+Hl@_!R8AuTe&~;1opdee&dB3
zuHKB}9zifaOy@7W^!f`Tkz5@6UloMAr(d*jLqR-mNEd{A4&i+7ML1y3%5Fi}RgL||
zi!Qt7y6=5Y*@^w>_`M^SUUB}0?t9iO6@<@rQX4MYaNTB6W_twTb8q4L*yS58+j!vF
z2j3Nh`>lc?ZQXpu)z^G$?&B8=!spQk>+PGb+PGPLztt}YU&eW%<JyhqT`=_QiZ`)O
z{War7)DeC><I$he=TDu%_l-|m2S4M&9<>aO!9EjS$4lmWxSf0(+a;I;S#pX$!?81r
zPxe(ID}q`APM!R3^`f;)g#n@JcY^fY<DiwPTG)y!c}ptai19rMd-SR|&aq3eM_1Jg
zGFy(%<@gm7QCp}IVnVC1CuWajV&}%5Zty0LrC8dQb{~=s*$&klYChC=Xu+X%ht?mu
z_|Wx-?mqOuVcX%F!_9~L4$nQj;PAS`7azX<@ZE>+Km6eDgyYBYd&V!e;1`7xevutA
z9r7HC9qK$ZaA-Mx@w`Ku58Zlb*I{<pb2xUm^YFmo`G=PuUVnJ=;ad;yI{X0tMRxqZ
zj{pAn>&GuRWclsyf4l#;7ri09Ui*6RHTP@wSWT=t=8ZXH=9myY8a)#IAo_0fKca`D
z*F~?2UK+h1x;}btbX|01bV+nx^t9+egvQ|i`5yx>jQlJU@$>W=|A&(_6vm%?s-YdZ
z;Q!}OV(bZjm;rz1-#tQ;_`j;qrV74A>f+@?>cTDSR3S05S~a&0%~;2e-Lx)tKxMv;
z>UNd2#a>sPt?jDVwrIuBoW#0#yDGI^Tpd#fmJh|%fpzVw+(uuGC*n5@{id$Gt`64?
z4cEQ9t}YQ*O|3)f+%4<)iFNDnd#1Lkv(9K&&23r(y9;-Z-F4Pkb*g}$v9xK8{LsMY
zA#0mgiS=dLRa;x^Cc4QF@cS`UN-jvmR5`U!6_yWe-?)84j5em!#pCPhw)4Fe#va|!
zZnVx*=ZWJcj<(n@cz2v_v5abIJ!>cyo0pio;gZ-;tZ<(36Leh_-5IxzZI8{{K6gW6
zdu)4x-!7pFD~8koT#5eCZPkH|w1e-s_?>1Ptd7U)Vh6W_4EWLlv~6{zZD=1ZbGId8
z2P-#E#D*5Ftc$B`-OzS)XhC9oBDQ_O_QVEi33Z3wsXZPV1}}y|p$^c7cTxw?(8S!t
zhD+9u?+Ja?*M?4Pzmv$eu#nhpQDe)8rq_KJXZ&sZgaI}%ILH=#(<7WO@OQd+HCi6q
zzG5hG9$KFmtiuOO41)3lD~5_fOqg~4V3EZbKGfLxYR$%a-ctNxpiRY5&;@Vp#E_7w
zkT-73wkGUcB*ievEJBCIgv|7!MHb)9YG%{FPcKR$HU&+h!zMahw3wx1(~FFb=ajgT
z%qfW`HlV-tm%m7{V~3g`k(p2s3i4uku@Dj(1y#tXRXLTFRY#Vo)fv@yP&H*$Z&|fu
zwHnqcbawfA;^}-y$tn4eB_4=}ENLa7Skn0dlb+x4d<icm>BA$NM<yN6hxujHC;ajI
zI)sHn(JlzBbaM;8xhY#@g1vR$0F!L3Om${d`$1LAs<yH!XNxvFow8YMtwp<yHtm9~
zRjcByt6_2U)A+}Bu{O3#->e@P+tN3)UA)gG`7`p@g}ksuP_r4esa$Nz(oZ#Y*myhQ
zydBZ3YRahfIn`WNYqM$~qdLmPfP*d!c&KGlGHRZ;tf8!hquH$5;L+MytLn+B9c9&>
z)%sYg){s}cs-;hDSBj2Uwy&>`sF=@n=M(u{Z@xE|4FyAq?hY~0;1VryOWYj5TSU%f
z`^BD|*<wyKq&rx;P`J|cdg0FGqEGC9fAe(nbGgL}Bh`JgXZqNU1^s}T?Z&&Uvu{=|
z5MH=A_x0$8O;41sZ5(v6BZW*);fXVLeCNVT@<W|9{<bsv3mv_Mh1U$Wx@$Yv_B?&b
zC%)A2)ODQCN^F<BSbPEe<>kB}m6<AMG?Ov%AZtmw{n%C_Ck@}oQb5~67xs_8&)Vb{
z<<o?K5EWD@qq@o%Go}VJS_nU(*(AlQIh4M>&MwIx%*C_4-Kj)_rGq6J%mIJM#ave|
z6W_b;$tSPtXlr}!^3VTT99+%bTYl9u??3I@aP6-itZ}+F;Z~$u6l4`VD`Otmv91d}
zER<(S#b#32t`d6j;d0id9}tJcA&h=ofez}MOMLIh@MGecx|6jH@5S#($3Hm!f&3l$
zJD6Q&(h@95us6di-`kyGsRm0GTk_j84vH5XTyyaJs;URwjqa+=zdhYJa8^~?^<Wk5
zU*Ts}Rt1}o6N*?{T2)I~l`xI$8P$4FmC8lQN}MB^z_?b4Hmznbu7eX-i8BS$sVA<;
zDmCudA&^oXetr1$LP1Q?@4Eym=F78?96~C>^8KtwNh&Fei-jtC-6@O7#R52HmK*O{
zb{aZAuyEO0ulKHHb62|T!ydZ}`=7qNxi+xAMLg%B;s5c3YOm_eH`jzt&r4U@9n$wC
zpM7|lQe8tUd+7K(@(<((1)oqStP_e*@>*4IMh%tKx(s^5)cTCd4yu8&8t{;8P)(Qv
zVE3AU;@u~S9&cl)Pc<pvd_nWNFa>OVYDiH%eQKR|9}_GlobT-NdeEVO-@<}^H#0Y+
z8Q5L)1Y^CPR4l~m!D{tOS)0XjnbmLA4_v#m^vM^Q_j}*d-(&C6IsFf%o!9CIaPl&X
zg|#geFV+9@;`eX`hJ?@aA^BN(won6(WNK|j6%G<ly2@Ie!P4FRVuXe8CI<X2$<iSg
zrkru@wb!?G-gw<7hI(gRfBWA4{wHp~ewO4J*s`)+UNC#ke7Sw)mVv(OZ@s0sdUf%Z
zTdxPLj(<~_C*O~;w+l|NRNR;I#hK5>d{TZs`|W+=eeBozwtMwk^=<ckPLyI?DE(QV
z$$a{|>|gMSwn`IzBM5z3t%CUFVn_xPg)&+-Z}Nm+_k}F^P&%JTTTZ;stRF1+?)Mjd
z@9iZ^PjW}`nw`J<%#J^P=9j<Zbiy0v6SNu3;~v)2keb1|d$YkX^P3X^7GS%QGu8i9
zXC~RMdl)O+pDS%u)vcx6{RRE_J){L2-(SqvB?ne2A6An($bf{9hQ^)2j8KIlE^1Zf
zvQ`~~ptNMvhMa0GtBqOJkx^4Q)mc`XvZ_0yw&YY#S#8UzzKq(DQ~hPNGfVxCWOGCg
zrgrmjl*{|9PLIDalvQO9iKu<HDkVU>)n&CF?*><fvudooud%7ElTO7vS{zp<o7=l+
zS1M~gB$%8I2&US)zCP8hX!T(dP+fez>`C<GCcb=-f|#XoHt9HBC#xUsFO2>{+zjvK
zuNOv-VW}N|3CU6jr(;`3FW{u)Z?q=6LBotNQy3JAAabkPmIDEaWZ{fDos*^;yfMJ(
zfi(x~V>RAAS`5<>L~AaqQ?lA=oNs!R?p{dTU_il`#v4*K7~%2z>|@S{!3BYEIG}H)
z_pxnpX#C#z?d;e^VeztYJHy`@w=?040O^T8t{05-eVK5saD{M-a1YjMP6ciHrC<aw
zQg;E26wYXiw_@L4)@EOW{q~G@)@QKaSk_kEo&|Mw5p^^VF`W&}*F>KltrL=JU^%w?
z%G&%P`t)e)acuLg*uJ=|U3XVDtKG{fM{{8sGiF08Ye*?QAHB~$=KSRE|D)H310@=Q
zQ@pWVr#!_^eBAl$=<l+}PPTdMzfN{^+_fKj0Y?-_-i+}#jq#cakAttl<K2AvFV3m;
zWpy@<s(KcUsk#ayx_-ilhE6e}+J=*lo<E4e?8Ts_Fqr1R<k6+kpn1V%ALa>-)<^As
zJhjCaXt;)F)BDM{$J2alXh-S%@f4-CE-W<2@5?O&s9@<yvvin!Mamu+{_;=Q%lcVT
zH?{!ZFyRv65_zsXS8(v_@-`N-F^i2|!fN$553pKRdq97azu}{Q;yzC6Z(^;Qpc|xx
z=O<_fPzw?{HC$HX*<yW|)SUVhG@fuhZHA-JuPgdP(>VPh1%VaGs>!k%%NCO<x-^-<
zw^B*kOx5FC$x$t%8S^v+Eu$y~A+r0_q@sHJ)Ea0VAy4f%ts~@x*5T>X!q7hU38p|b
zovTxd{u+j_eYEZ&L7wLVxj-V2==n%JWNx8UD3m@%8`0O%MTNo`?Y_YEs;F@G1lm<7
z6B|dFie`mXi)&WTk!DpN9@opsy47=}Th&KCR=bk0jD2*^NKaw!Rn)8<*XyrZg3!aP
zBWl)*%=02T#&ty@BtHoKp$@D49Dxi+JJ#tozAjnHMJVYQMGK5M)#A~d7;9g-==9M+
zC+sLPnKY*bgA}T+PoUvsAa#550cf*+sDeG+sdP`!3k^+d=n$DPfw7($6FBsXCobH2
zl%02U>xEDJ;>?F$edpDO&Sbv{2MRQk@FosD&zkxl&zG*#jvm#nE9D>W*MI%|7F>mk
znUk(EmLpgb1%W{>X`^~fr%;5k(W+UUxg1kH8C5<=T0J^pMJF6Ela21U%bLQaO&%6D
zgK<3auK;7Dt%RX3F)~Ql5#33aHxvaxlcG>7)XBT$-NHQKbm2UK)a&JCbx}s`1@%^N
z>dh~!^F7)U+zkubO3-P(KsMA2u>BHcpF5E2BUWhiYBd=cmfCW#yk>y{qb^eRN%8a?
zI@{~jT2CW}_xYn@Fv={!P(BpIW-dEZ?48L%z4>&$7n?oZ88MY%`Bd7HPGK|A;1<np
zmNr{L7Be<Yq!b4H=7v<Q`2o>YEiG@Keut^O%am$rsLQ0x9U0T7rgScss@?4KCe!Dc
zCnPOzoBk<Nd#BmB!jx?@-7&3Wxl~gnK44}S-dwyH|HXCj=9Ias&Ge~h9j8mRIAt<D
zAXe2%r?<`cl&P(YzFgm)GUr-MpPHIEU8->zKkurMPR~sJlqu6;PIcA{-F)-Vx|?r?
z`d|?X$B)aZ$q&7MOasjecMHWhX;F=^_B*??Sm@K4VoSC+2X&#Y3>A}<3RfGBXENMw
zg?V3lkXD^WkCwy`019a$&9s<o;t~qDgWBZLAdl2eXsI5p3tR13wY#iVWsBWibWyht
z7j=6`&xBAUK!AfNw5W`(EaR3NAJk4mK_gc3;YI2uebTGowlm+fX4cj`jrr_um*c}X
z9j=0O`?Tia+0E0SL_)?8pBd6dW?8$t&^&EgGrpH~xLn6BC+2IOKD}9dVR*Lq0xaVX
z_Zyp}b`f^ZOab{fuw&YUB2+Qx>)?Cn=eC2St6RCAO;o}h)=XB2SH>r+jiH(R9}{<p
zx0mz-^iNzT-afo_crVEjaftYx1mIhc6D~m!8iXQ@C4ea4df1WXa?#9)U}h^Mg3p*u
zTqhl+2vb<W<zWBDcDWqKzV2{|L#(YvzS-f@ox^9Ndy<#>PBK;&Wcg|NX{>QR@W3{K
zY;bp3^^^Hp4EgCcp#a7O7KV(e2E!07sKTguG(W~^?4lZ66!OsI#=Iw^QS(<pPT3`w
z4>L<sLfEm%ZnAX+&F{vZMX2)7DIc9OGsTG=T57zFG1==8<yfP)V&3{lN(AIR%*$po
z@18ySd-@Cdd%+Lbnh!qEpPUDg@s05(_UsYQ)t~%;P7muK=>ZUvY)|-*On%Um?5>WA
zl?50LJ%&XEbBcfmH}zOz=!^;alP6P=Rtc7q@Q=l%gyhRfi2{4}=YdE4KV#1hzuEkL
zQ`e!oCxJ!)KmnXWYrzo%_u;5NbadmMK<}VRv{vp06NK?w7^1Q$Tj<s@%@jyYfOJ?H
z=<b?DhNKd0kW^I)<SR$TU~@6TDbXTel|2deXZ;P5pZXivI{fUj1U!)l1#@jK6)?`=
zSJ?N@qURwY0`S$al6-tFn=r6ZKCntzRSe|;%4EGq3!oJ+1z;p;HHzZhUnP4(TsNp!
z)JUHi@a}h-d_h`c1uf)Lyw5SKO{lG`s6Y&|5s@!NY-A)QF773E?w&V}ys_t8<KwLN
z*{b*7*PmX#yR`c#8+QWdMNxnHeLAo6=?bQu$g{P=h7q2vuqZTxQ5GeY05&cR+zMaT
zQ%}H``-v}M5%;OpiW=xsafFyN$a~@gcRt6=7J=(QCud2i4ih<{oQfxx9X-1H)Lf~b
zN7Ikkh4_+~lVb`r2b(L>1RM!76<rcBIQ|Tc1dMMRR5_WsxK7ri_~La0J3#gJ<wEg%
zP6Fr{`&R~8x6R=ym9nfYTiP)EXbt-}l3aQc6Q8|_W%kGf8U}!%%pIX2<~>dG8csvB
z!8uB~T2M}Lf-thpE(M7RjA_gX6%1j2BB6X0eI$mNZ8{a1K44Q>^W@3P_G84KehO22
zJG-|8&J9&`rg~weKrl1JkCIVq&`ucl7;DHYw@0%Zyc$6}?KFTU+2;?{&=A`cEfAzN
zU!jp_g3S-`18T6M@<#h3A_2$=zd4rj5XfwaD;BKizzZu%((a@Bm!J{db@_d4*S%kS
z85)uJ6H=aVdJ9w~XjG@unH$c0h>vFo<4HQ6M~DkI2t|eFJmy!hTnt8Ojt6To$AMXy
z%Ec-Z9jL;jXKDjiV*u!Qj44=K))MH9htwFwi|JpZJZ~{M?9ff()c#tpX0uYaf>A6l
zaV{Qgbe)MnbW#laMf4`G#PjHlIUp%<3ly2&o*d>RpmOTnmY2VHufF-SoA1<)E?~R(
z=WgS$I7Euy4Rm(-QH_=+`sBw1ta=csoM*|uG8xBOE~wUwTAd@51<n9CCEysqpaEcl
zVi?P*5Hs;Ctuc)`LPe7hgD`Qd2a7<dNZEkzz~v2MixdVZ0XeLgwA?3QXr#xzd|2>j
zuy`QZW4sK^2*CTH5tN8z;Mj{$CxYdT<=<HPhxgL8#&%^clDsB;2=W?3*{Z_GAZ)%7
zBX&@&Ef-C-G-xK0)U_U3>Hw1#U3GNO1s#SIAVG`KswTTkWM*}C5vDY4%wW!qp-T+P
zjiH`H`Pj08wXN8~6_I0Gp}9bcbE~-^4mD3Jt=O_<MF|SbUMMQ!A9s^J&iReTf-o=%
z*loyI*T|DV5H4Ul@+W|VSVDdMEF$)^yy9XVlG%c8PrviJtyf)AXl}ak_FZ>gbB3QV
zH@0hfXH~q;wCr?t<n%fArY8HG(@8{ecQwZR0dRGfaGG$TP|Of@`g3ZktoHJ84uedC
z6<dZ@u?EnlwXC*!v@Eu!mDOn;&4aB_S(^pc&bER^PDi*NG!nE_2D8)R@%bg<ZYS0{
zH>u*vs1?)CViBPBqx&5q{6GO8C#^wH0-chR_FWDrbUXgQ%zxOyH_!jd8*jbwmGetZ
z>mI9<zllR*+sp?k>0oWQ{QRn`etwI7z}UM6U%>aS8Ge=hn7*WU)BCt>J`RFVl82<X
zfGc3iD{+%ziZj>?Fd<+Sqyf4cQeRYe?3g$5AO038R??pu*~f{I-;y@--*Usl#4Re<
zL0XHkkYPBDUr**?V_4F#Mn-@8g*jJTGHZ?Tt9?CpKKr#hdN1F8-^loVTRu<vAGFU6
z3}ia@TM<eef%}Pmo6tU}lVEWziqY|5wb|zhhK%K%K@9D)xqJpc!+V%il5F(;u#y6B
zOTZNb%LoP>^_1Pm+j5TO#%nF7n|JOqvwP95V~0xY6*TP0JMx!rzqf3C;CtWMZ5^~0
zfB$CDI*O00kSYqexd!cwb5wk$FblTdB4HV028U~%vtf*Q%f;rdIV3Y`GsSf4V#7cw
zCfk?Lv4)H$nsHSE3V9aY)Liqi7Y81?fbh=cWVC3e2(E;^A(2-yY~Y<$WZLA)Y7gE$
zT8E=mZQ+p1K(^Syah8q-KrYPTrn>-c$%9<8=VN<XSxYUXPmi`3lpM^e%gV*R8FNXN
zosNq-!&sU8f$Ey>nP74)pTvUR)I5b;omxX3DD3l3;dW|5Dauo)5oQzd4%ke=n%?~M
z83VJpFzJdbi5`Mmay@YZ(+%OsARvLo1SC=ifx8=s3|(X#g#d^XKyO?vL1Z#q?Zb;5
zA-fy+dO>$`EsG3s{LwJd8U9DwWodXXebC_2=_AG&D82jX5Lrq30g|WU3-n9;qCyE<
z1?eqPcW{p*(2a2s325o|LSc9|Aw45lHu+UfTu(L|)=yFP*VE`$m9;=Po8=Y}R!}aM
z;WRW529hmKs7+7^%Bl}03PuiYIM^lC*n;I+XCVHGG6`wTL(U9~xvx*FgS6)E49qQ%
zC;{JnAPtIzXtlv-0G~aTPufS%E41M&N2w&e_2F_XBhp*Ps!L~{dD73yyf)TNi=pdT
zNP@zwBc%)LA(R<Rajxrmf$|guvxDn;ijS;d8x#DYU>5GyG`y`07Vhif3$W;Z9geJw
zgy{`K@NafEbUml^`&HpcBusC(FOTyw{RZ@<`_@2y18KsYLzqEybJdUOVAyuJKY9E#
zy8nLMKS(N6XIC9}f=p~dGDqksgTh&9$ghkW;;y0tOrSfn>_uvl!!@Z%D(&MWjXlLx
z7&NiNe`EN*;PWEA7v?n9Fnd|GPcWzL5Jg4N0^J9*27<y{WU`6V39%N?-Js{hmBO>q
z7YoDQg7}`yo;_9#7Azd&p?6FG5Qp_rgBBy82SCT5LYo66_9A;R95{9;5N0pvbL5--
zkqE^(jjVfQ!-e3bgNHXsw1b5N%MmuCoqMP$v;wgoMTy5;j9QS;YtRL7CxS8nfe{!6
zYy=iEL9<ry-#({1-2f63<0)K?$K;L&d{F2mxckvEiv$-o0qao~<l24->Hy%fV~2X0
z#O3|xh#tG%Z}*6UDbZ(VN9;Z^B|7ZGd+js^n6tA>CGoYbTiF@3mVJ2J=j|?+o!-zl
z880I~AS@(>cJRd&JQ@M$a&ty)hnfb@Dh49Udl4-cqa2@%X3*EDM@yqOtz|8Tu0$~m
zYE7Tknnsu6jma2wNo#M$UbG=W7NHtfw2m$aG@p0Bqoy_kFC!^NMs$OLQFh2!z+Ix7
zM>z-tp#eb?{XvR;XdvZpTC?;Pp)|W?cP_uOrPRD)YKOzQ8=6vKS83O-lDU7Vzki5<
zI&>8&P1d?OJ+0UY_@_0)6vj2XSd1>}KL?^m6nZ%CJqw$-0WX955Z4na7eyyYccvyX
z2oy84(4K}4Hj~9e7zP9&q!4U^wJrfm(Z$@1`9i)Pc3E?Oqwg$s=L%125BqXMlQ&{E
z>$jY(Us+x6Y;n8Ureeo6gTdamKflqw7Liabz7AKF^yV>dXPvVae))f8uY5-TK6nmu
zLi#@DYYY})m#|SN#)#+QW#bcJM;M=$vf9P1p(+nJjE@pf*Lay0t2mY|j1H`cWbB{<
zX62)l?7%1mF)+<>Y}EIuEedwkE&~6dBlb|JM0baj?lBR1Nh1-F@yQZtvKvTG?J+hI
z&{0KOurbPhb=|i^@dk$zgzj$L^7yjSm)G5T(>afPdhw-uA6jS0HA&OzL*Xj7Wgb&M
zlRrD(WVJ}n+-Y0puDW+gX~U{BZY$ilWW@%sA>;t&rE~??y<?S;KtJK8g&1&=*PBEX
z7fwb~^S)jhf;7N+m*i%WIT#9*mRxOp#@;l~Y%{U1iSeloH73)o_Re{ImRT9;^eK%#
zCc&d&O{9}f=dpk7o^I{~F7#Xl7qVdv+$<F9h|<waQ8Wc<!Eu7?ouu1G0l=$va72m=
zY6IOSs}r*YIshU%fHf4Wxg)0<CSEaIO<xPw;cGx3Xl(-ejX9&)AzJ|olK6^Z(WiJ1
zr=rRjf;85id?=yhEWo_t*uiMDG9?6d%PTNRrNE*^i*C9JucN!g7j|bofsS}Xsi1Ez
zlp5k0zXE0Qi6@R7dO|v%mf3JRU=xphJzFSbr4^zrkPd^+q7Xm+4f!6(Kk6@#UMuxi
zEOQfee0S|=x7+A0g3A8kPKKe|>=UgvhIy`es<9(OlyR{j0uR*$h-@{gKz7%1**%k?
zlOYRapLB|@$Dc5IS1`Kn&y01wBjCvqRq&F2I@<N&E!1^!`$*ThyrZ>d%%3V$1Q2;S
z`7-d2?uP^NVzR_O+)wXPjNWMt!S-8xyPDp`A$lL)3)O{|74C5<edN~P(^i;5SQog5
zmbV?4%Y^;O=O?yxtlgzkx?4w^$c~I|>YGP5#~nRMds7vZ5&8wZ(r^v{u0f2-j0|9Z
zip8kJTaaIQyx-V2iuPB)t&iCs->brSvZGsL<3W8K8wA7Ug?@;aj&AC2jc$%R`qBL|
zdSvwO<NEb+{_)A@$M@^++0KqOpACG>Cdpe&d%pIK&4rQpkrkD3LrejN4lxDjC1MIN
zbgOuL!KFODppd1J+?pdF&NUDdw~~%f^u#*JCbB^gHccU`=Qh4}PL3Uz9NF=4`(x0F
z!4s2d^>O=SPR@_sBD`gcXa1h;e}L-8c74pSj2ky(lN<+{$Yqronrf}kB1{D$72{Sr
zg21pec7W=O5Y$8JI+^Eu1%a_gQk46_CW(W;L$pl@_}KW$<ByYhLo<h_Jc%#3fZJ$W
zKft%SRM5F=xKNP_Fbhcz>rQ}4Z&r>0#QMlBVns7F0E8Zllg+cxU*K5-Sf8k)>cByD
zR+)FVvn&69**9`M`(WL{B4+<s|D;$U{shqVkL=J`cRzfSKs7OS)1ty6jxUyE6}S$e
zI_*4i5mSt;KS2F36kvV9t)|&%G(AucWFXcY{O#<T9EJwVr7bGH7j0{c4tt|*((N$U
zed2b$zXk6M7Aghqj@U0W&qIikgZ;uI<bX(zxN;dmoVfcK_KctuKp_?P4@FdjYtSME
zE+0kn0b_>Zf|eCMz5v#4M2e_>(&f1matzv>$xLYm+}2ys<ZHe1kgul3_u*b|ZQ*}d
z%R-iX=UDZnOE)iFy17j{;;pUq9&_UT-EVyIVb-r70$T7BI=2*b`y67A>k)hGhn7C0
z(gTPkq8vJcwj0s41jbqohgBWoUbHHi+8U;|T7+t@X8;ywxom{_xz^qxr&GjB+{7?{
z?)snKaO2OeU$Eex`ugk*=bwFb>&zD)xMb4<4;<Vr{%Py4ZoB!_|GxjK{~jE)HEg<K
z&!SK7=4T!toodX#77!Lx+6Nc{Ha%e!0Apd=8{RcS*f7k1Wi_8tX(G8OOyt?q{P3df
zBQF}aj=Yn6XgQ@}qU&tQhpIZ+V`hW1LRy11eFC{;zcsmqAoM%|-InqZ1dk(hzC+9-
zmN(xarc(%NaIsI!zU=C&BY_3W)-IWuTzc~tmR<GzTW@xqd8Wq_?6A8<o9(PT+kMVA
zzx>6Q*3Y|V%e7a3;!|_hJy@6~o6q^?%_}agJ<l9m*tB3rckc4tn8yacy(C|Ryt25E
z64naETGB9q$iOQ=1D56kW_Xu~8o{#GMAU$HX`eY9A=6O}Dq6IG2x28yaUg8CJY;2G
ztRa!)wBhqXhO-8?`>3LmN6ZCOp;R)DbTxD_!`^<3T^{|m{t6j{><Ccww;$6FJoYx*
z|7G^@Rr)6Ow=1s<oJBzUV{e<S--eOsq$_VK9e(WXw=c=Ehp)sn|9j<?tLsTd8NRyv
zA*1TyL7rdf8Kw<<H)-If97~ZsaM3f0i~w5#uIeQD+~5HV2EvVCLCsc+xs>eFWHUZf
zm^jAN4w)_Frm6I$XQV5vUy8DTjRhK9CUnLm-m&`L$(?y3a^Z#NM#AhO{Xt9h{8?*e
z^%*@{9vd3z(Stqc5R0b}Wx?3b;V$q0wde}vW?eScuf6D37=90||J(*bzj%*0#>V?H
z=Jx0K8Tas8B2mIGC}KU1@v@<#`+~6f>6ol&u{eSF72$P?(XxpM!b9KMW(*efuT1XT
z8dfLf@77nq#YUqP(nh*8r}Q=I(+>R)bpG_uk`0L$)=UkOZjMm&65nC&!Fq&!W5aTZ
zcq>1=B5*_zBuv5hn#YexXy!64NHIZGAxJb)(FDv#0PQS*H3Cr^_^>gcu0V`%0IMLy
zE3x$VIT~8}zWy5U&60Q~YkJu@^0NMG{lLqJ@4%HW6O9e~_IA+N2Pzw0K?h<+AR-Lf
zqCJHCVQm}rU?7eIF)rlQz#<Igfm~U9BWoBJ`Xcrp0AJtI7h*N$_rM$18A#F>;T}S|
zkDDU0&~e-a63FN^N1Ke`+yL%j{4?%Uxe?v!#GC0gl^a%%-joS<jp`}>N<Ih0!dNnd
zcHu@o<Ja#JyXiLpPNl|vWrQx=e}&lv>hi=Hx(eq+U;+S&`Fa@@1PE$UPz<mLQ)P01
z8;CR#3OYV`mwU=i)aokthSQM$KK(jbPxR~Dn!>M*eQ7r>_r@;&9^T|8jHMYXl7SkT
z#`hU~qhNt%N5t;oAIpoW!<3=I-ZFS}+!*19z=J><MwnC1lF$HWf^_sV6mCvI)esDv
z6ME>_5q4xuktJ1&?ts^Gq?H}xCMWxbjzPlxD9Qk_L>0cH`(Z+GzVq^oEQf(Ocfzf3
zl6xVHWb97-J`?UiV^o0OOO>0rPUEfUG^EgwDnsl%$$mrV$^<h_UOfEzQA0CE>zP~Z
z#$5T9V3GbNe~riJGKAiyza=jJi~b1P@E39Iu=*Fa0bA5J&+%W#E97g)nn~JNo`oy{
z9Aq2xNB$~K53phNMSkh<OF_nlHFO^Bm5^)wjQos1c<vyNd_blPQr2i~!aTuBJt6Xe
zgak!C?4!sBNHswVP?#(Qi13AIe8iFuk+58;gnLHX!+emlKEx}%i+H7X?=JB_9_}!D
zaL*ogIzK$2U2f<QV{u8;E;!Cd+eNWKK#(amsA@vHoOZ}Bi-09Y#;U0?cs4pG1XPj3
z{Dfvv;>AfCbt0{@yiFB-)gTmsV4PVs3&S0q9$K<xYDN__!$~)XBNXmXL`+&jlN+(}
z)g3!t-MJI*2X>s$mZp(2I6rax6k$S}jQBXCO;9W<Z9=%rNSnArdBS*svn=V!t=Yu<
z?4f7hx!{DB+^)aP9{Tz_7Z7d0MWcK)1>V$4Id%HV>U6FP06B+x-ED9c3}wu<NLh^-
zuq<fSkM>1qy@_{Yz3EU8f7CQ}8fUNcbR4E(RO5=;LRnx%r@Mm`?QTUg1HYU^S40y)
zeeE|*g<eZRrxuqS%Js`Vzz!)>(uehGat~j*M|NAxqDi#LF4-sfg4U49oeo#ClF8fN
zP@m|U-Bp)8eNO5wta21vH;!M$8qw^uTTBw-i#<W7hsmMnjFe<=&JJaBi<_#=)jjL=
z4vIM&qYrs<r;TtlW*Qb`WXd9lCs?LfBVzChw5xeZZRb23B<=Xb?&jgeL;@h(n<wiS
za@`Ea<B1Kw8wL?V1$O~jAB(xFhIjd5p$JD0_rpbbLX?mxx@zJC{xU>gC)&9mpp#UG
zqN%=_@C`&|TOw(~H@Yy6KBy4;8WJ5DK73y6A*M_dC@d%3r!u7&X=>)ShtiWn`~@5t
z5ix`gxR?cATtL`4sN*==n}>fEyEuqbxxn|McYeCmyJeI2M?b20eqHG^cSY7$U$Llk
zfA=e;nvDxfi!QJJIefP_-CtWO`ImokPU(WZ@t0nzd*G%8msS7dC!Jp^Exe@q$3F^P
zI=^J_>-bpD=vd5GC2r0Lr8h!5AzEl&li^1(Q#|I&Po9548x4-*aRC!KaWu+rT-3v<
zLcbQ=dFN##|2d0|#&wPl-~6|cOK>fpbL0C^b3z}+ho@HhK#{0peK6wI#`<75H^)na
zu|7atu~W5v(~h-2-l;!+%7*KS9c#-w^(Rhfb6us)V0^GYF}{%;YOFXEuL!#H<j|2=
zJ2!<XB6cl^aiBHFRfqkFbVr~YqYy725AW(upU~=laZ2Hur#>ie*!<K7(<V2X?Z3Jp
z=KDVwet+5rPi?OFVg%uQj#HR{JW<RYxnnCDohF*V*aF%BeF2eK3MCICe=osaA}_!G
zOGC#Q_k972*SPPGVpWub4lT*}K56$r?x*PkteyCk2|tF8wGjRwGwHHO)&U9x$1q~B
z5LOM<Qj@72tP)mD4f!#95w6>VMmqEGUdkz?-?<3F`puEwF^~KXmeY~n!P2F|69iS2
zekIN>VohjEi$2q68Bc%4?+C)ba@`v6Ne_%^YPw4@&%OIU9;W`EtA2G`>GoHjxzNho
zMlZz1*`F9MYs`pmQ4DR7sjiIXuIP9nhJQZ1lz8YimfESme%sqSS?V@@Gb+MV4oEgS
zf?de21|cEuly`zIXbBA6xB^>O;lI+r(sYsj8ryptOYhWQyG_Lree*W`HL-_&EWJa2
zZ5t%B5mWgfbT-O8UB<PxSQ*Yvf_VX~R3a-tBv?uwBOno|1w~ENz`}dZ<gAk8Wa9y{
zNI*{8Xt@d_X3JQf#^V;u7h$BflfMq8jG4stNMxlEV9C}@l@tD6e?p!rSNne&sP2UH
z{#_-)()bYP>c8-Z!+zF*_u-cy!@&^T?ofd-v<RI-H&&Q#p_nE~-jyTgD0y$O7<ci?
z3_z(-nPCRn-`$1C28YwvGnJYTF3trIErZ|~v<r^r45KW2q*z<9Nwdlggv5{42Att*
zpd=7LS_;cYC<=TRttVG7No;V;NXNqe8T9%B@5RIE8TN!IUV-!Q%t;MC@2d#K*YEkE
z$rbY=t=X^;3(VoOKArAVc2xzdox8jpDb4D)GhQ{|$okIAztEPxS-SltXY*S4DFxy9
zpAo}NxkFiuAGbP~nuE4MA+TCE=cYgpU>&S6{ieKMbjhfdVCfC!dz0YTeul6S!&fa^
zer>Z#fhirCi#LAZ?zb*#TX@lxpS<qIvsSv#_oip%*_62(Hl5iVl&uy&VvW8yV}^du
zy5K$E>zRJ*dE2H<U!7}@^hLg-|M+JQt<KrZK6n0>s+EI#Q!~%Kbye1HGlgq%SI1&6
zVfr$}6FBAB@_zs;Ng#@C0oP*Zl+`&NZ90ZxAzstxfPJR+LP>*A^CLw+6f_zeVL<4h
z%S4b|m+zPJy<$2T3Z~)n74y(=B9cqCm}#3`VY1Dg8y%cFrO6$0`IoIxOwpj-=9VO@
ztELg9A2!VzaHk&oYA}$V=k_jJY06c#T)42qEjnc@V-8QPH#Ie6adppR-x`cexurc|
zPxjA<48EIQzPAux(B|{U+##!j$!353j9Hh@dYY}gtZnrpCX}G~)NA)!qZeHE#7gJ1
zy6(EBP>n~ncPv>G>$n^u=lJ)9o8))p98j>Ch+Uf{P=pN<ji(ynr1O!Od{E7owFMwT
z9xC5}-Bwd;ZEou6=W$+uQl={2=LMy)qo;px9vAu;L~}M`LSmB3+|Xf4=Od;pC<73a
z^uC5vPj}vo8X0*COqfw?uAjT?>Mft$_1P^~FPmF$uAO|~A<L}xGgsYk>$NM^was_1
ze0XYKq)Yu@wc~<2x-Pyrx!C6yhnnn7YgetGm&wdqziKUZChyzV&p2mFYg6v5X&1TJ
zg5;d3H4E2K%KPdCYp>oq>*DJ5jg2%-K??!2P=Q5KM8j#qmxZF6W-3{tgBgkjReNi{
zJ>x(B^EX1E)vmfbT&nZCCe6kE=2EM^i}>z+4!6_Sy3fPkYxsLDe{baPNqR5hER~W;
zm|>tHUK%md$oN9qW1s5i6P|ZCt2{NejmeJ69~-dakjp*cU`K~KP|LuJL~9D4&ang$
zIPWF0RtP*3G6JC=xB?kq`G`mZB99V${*39#&*?9JF1h0It1eF4ANs}f$xZigqGm#o
zscsi*N(I|94V}IW+t8Yxbz4VOZLKAF#>UT%kz3jM;qrR|8!x<min~dFvv-I0iOUU&
zX4clPsH+`*;$C+uo0?fYAl}k>U++Bw{-!2p_onm6Fp-Xb3Bu9Kb9%gx6GDo^8fi4y
zLY6et=YUcNDC>&4q{)@63k=`vpW+|B`M=nA*mv|N$l)`4_Pm%JYcRz=JXjEaIoyt5
zH)PR3dnS=f@mc|_gDS>xzCgjF6dc`>QIlNGLa}jVi$NYG8LUPWL^4QG5R{{;wSv=w
z2n*1{5wgi_5o`vNWY3V#H&5sT;T$Z&D5p4`RCsQ2h9xX!s<V(+Oy*P}h#;DwtwU^+
zJ6Nsg4;E^D=e%)_ueP8+s8lm^v%ky5=CGChLqq-gGx|Tdy8O-lD(BzyznvKz@GG{Z
zOKpmOAb2LT{LM+LG5&adj%`vEhCEi2(U?=@9jwKgKY|azh&EzjC<+LMK9DF1qa2A$
z|3|k0Ga*vo!~OE&Z~(PwoCV-jh%fwzKkj=H-y69Qh|fZd8vl>==I`1f`xP(Kb*SxQ
zN2Wpz<|LIBLexGyi#{H7W98)~s4&ZjaYmXOG*K+|4rQOE%FFX8Jh0MWV|R8T6d%|q
zp`_q4nEHr*4jKDcAcy`+VHuAM@714T(hWPF)1ML_-*LkubnveLPKRD51ob6S*>2dm
zfB62LHyQ_s-)M{|X2T0z)TpikG{i~H>2WC2ME4j&uuN(sT5R}f{bz_*V!J3H%!r>S
zZk|Ro088`nPlB7<h4lg=+#r?UzP9mH4I5>G1+o<KgJK(i_*+4Z4vwX!s3-;%;*dO=
z7vc*+R|qw2%W4^LxkL^;NFJ}EMWP^Ah=Sut!9;iqVmL!k)ceipZc1M8yG#(}BjuQ2
zqnee~>7L}Y=BVO;jg9^4^pcHV{O%VwE=gCLp_f8W7KchluZ*2l<8b)v6HRR$)r$3K
zsb$5@mt46#ms@`2B{#2NYlyP+BJ#20zZ1SGUnIRjT9bq{_B@OHo~>saemDHj?4jQi
zT=si$7SVdH@VfkCnQK>Y6hN<>E6x@Nf2Tj9?~%g8-w|j1o<KPIP4W0tp<vnq?9_^R
z)FhB@P9p*k#==!=LSSS>I+2QQY`DNA63>7PL4(4JfOX|%*2>y`#BTc)D*1fwSL`O*
zZ!IBiv`+scFGU0d9kr?c2sZ%Kd9)F*zKnD`XhCy@Vgrp=O-^kC?LEju;L*Y4d;v}c
zHX+#r6{+!{3ez4Ti%0;Y>;ouETBsgvYv-eqLUE}$6ePk~31yXBVk_e-Djy-NtTUh!
zVtJ*@;9g35O>X4W-kLJiDd!L}-1~}Xjd-KsmN25OTEba^VZ~7A@SU-Clk`-z*Y~Ir
z!0}@<<*Fc`y;<Wu;tzyNEkRCCdgFX9K`S2@0Vk6-jx<@`m(h$wqyQ+0#xp`^0&z&>
z50@i3geSZnq2yKRb|azH_-)K0#Q#!`hzDb3Al8`Z$a;jukBC&Flae7u9v4f1>_Qk8
zWA})I8!63k+?|e9Q*PPF)FPmPu@3OqHjIxAnh(#7<&~XaO2D*54JQMZlabJf34ts|
z&ICDp?d6wQ3u}4#W&I#=IPor|g~7l0*$nK_ZTQW4o?S%ts6E3=LTRJnWZYd7Ckce$
z_R*ifPw^ksfA!K!L}DTcU%%XtdX!%Pf31_as22Df4|YL{5-1Mt@#8LV?bVH7cSwsM
z*%0N$)S`&^<r!Kw0($uLo*c?l2i28An?gQv8bKH)Mr6{l>gH+Dr%jE1agQ%)dRo7S
zi|v9jWROy9wfOsBx;-@9$iwK-WC`&gMy##_vMLX&hgVgDR|hrM%pR=;ZOihsX{`m0
zMa_w@I#Of6v<R*1kV8GwrGC>i)c#5)d_lx?HjrN_Ez+txl8@Ao+L*1WkzEb7!B<cV
zPc~WPlK7S3vytL%ce+i|N`F|+OK*h(#Pd`zAX}ZSsyZrK0>Sv|qtK`AvPCk9?C7zt
zm-Kg>4ptvvr|Z9yR&ck(*YPc~hZlnW7l1!nQSGRwl0}4M3q-U=b0kx%v&Ci}Q{9}T
zytwX+QF^F3hhDWIf*4|yTq1eoGv(pIrb%lt2Vgk(LZbjEW-A$TrU)6H=7xoJe(xt{
zx^GzNHGBQ%`0>8-2KUS@iodSbYmF2xd1Tp5f1NtjTg#qsPMJH!(RnF5ClG#y&0BJ_
zKjy0q_!^n-mL>YPo<Yx>ERrJ}@HYGXmgax&nlYmbhyp{dN<e;Cewg$vUTTW6et>o3
zAK-5MLkdvfPfHKAKlD)hp{0M`zyHr8+ke`}zJo)5+P9CNez@)M(m(Cr|EHyg+mNnI
zYc!2H<wZ2W<6Mg|hiGd$NIrA;m9=0KSkF)6Oj!%eKaG)x43;)H5nim(;w>mifJCX8
zEEhm2LMf3Z=Vf8WR`=14<a^;6Y5kk^Gt$|*PS^T-{e|5q7Q|jWdhjl+%EKQlD)h0T
zXltSE^evX%ZKpTYzx;#Rq<%NM_SFN=9==Jxo9l$s&Jo!~?L^K7{N+3{7HF@KqhbJ9
zHG#~tEET(;niqzD9K((EQwHxMNhjgasJw}hu}ifA6r-0ZAPhxoQyW3xM!s&dS8c_r
z(m^7;1q@LGIRdxoG)CMILP|1EjO8E1<*3k*k75d@<2_Qsl7Oo8aearzOQ6n8Y!?Wi
z@10D51Fxd<>{{x)g!Qk0xTV#6j7}4-7bu#hkr#i1wTB38ASx_d?BdDvT|Cv($dQ}e
z_jca*Vml8TZl4b6LP>J%==^@CQs<|PAwjEaM3)nNYO|tN_i27$8O6}_(>S`E2Z}+y
z<C!dp8I5cKO38xsF;+B2aS{1Y9J2;AqG;|!yhWt=mmXNYX_K{7s7HeEB`$~Jyv*fT
z%{o?Zx@^^^ZI(K>{*>i$*Z|2-n(N#@@_4--J<lAnO|r<cXtIBHjs6U=%HBm{m6EjE
z-ZVQmyZm0)^^12c)t?EbAFW%*RtB0P0e_e=Q8GzRtE=kymG2PkAk#L2zt<qDhkPiY
z9sEk59S|t2*Hb9JLY<l|PT}HUN*{>>_)@TxP%Z*5f)H(khK7Zm7zc#*d#G@PI^A%v
zq#&91Tb%WBGpAjcXqTd>W5Ac1GzGL{Y2vERE)hb|WRL>13z<;nu2Nkh4JQi1-yy@}
zc_nF~L^q4e)B<u+4B5s@iBJyLWmO)Bi(Ll1<Y}w^l&8+TZPP0I8}2&uCs}fn{<XFD
z+D*&^g4tvT(;KBfmBd-Q7PIR;o<P-=PV<{`RazN-zv|0P0k*Qx?AM=J$Nu}>mEUx@
z9X1dQS|A+fpfF7{2^sIuSxqijEWL;coF^3XG}oqJPEE_G0bmML&#c%SAiJx1D#(+=
z0T1b=RL_ramu7OZc!9ZSE+kzdt_uRB4#}Y-{_k`W>_M?8=@j5EGh|s1h|+Y*4(O#x
z6%3gaOPq4ZHt?p4RaK8R1@vc@?pl1kJL%dSJagsq!5X9G*(`Nxoo=%NP5r5Uzu6ak
z+``rnX)alH`KHzSFIG8O)#X9Qn)|#}qcmbAg3^9Sgw$V0e0!<l!w?0#^e!q~hk^A?
zp$a-ZMh%!gUilRHdadPRD^I~`or0bt%^1n2l&1oOY$|%*O1?=aRC3LYOck|?dhRnv
zVRFud$Ourb$qbg{c@UT%1pZ0Bct}CHND?Wj9%VXKm2}F@NRvnT#m!YI_w{VauBB|H
zzxmOs;SVqa>|c0?{m(l6X+P?1NfvW;@SFFc>kFd6%d41Ub*|j8>e9<sT|$$It+6~_
z?{e$gFzWj2+syUu9|pbNAS*d69;;O4y-&Q7cU&aB9rNTV)B_1%%nf}7$Sm}?N_-jg
z0FROEt9jr$(0C>|YV-*{2u+h0(4w($QcifKyoLxB9QCXMrgQiF=7vW{eSGiiVM!6{
z6T45pTwHy_Z}yzKM}LPL*zi^RnEjO(S&Fs1RPmubg*JJx>P@LwW|)EqxS=*-A|uoW
zH7qEULGuHVq1sbH1r=-+66DBICqIV5v(%}oBvt$n3C@Ox4=uWW{GCheK57z>ecmA6
zV532g>94=|3h8wdY1Ch#k%E>OsnACB9a(CX=sSgsStne=WTlzlu2yZR7X&g9OYl~W
z&<WLm@sFKIC#<80@Hv4<h%h5NZE~BIRN6Ea6o^4H;ugm>D=?v1aH#WUfn*>e1{UcW
zIL39L@k5E=2dYPLk|vT@1qSxyfqaY#{Epa%@+g0K5Y6*>;R~oBZ&=!Z(U)b^&t#bT
z5Vv{_5jzAbVq_o2gz}T6i-8?d23#(a4?cnE3s+xv`yF?G4kA~z1J$f*NOev-<H9Wu
zet`?&Wi3E8gPpz8=gwcfmah4XGGMa{{-I0n*s+toG(!DRp75E27Jtx!m`zyD5iuVm
zj1yT&B$Pyea+Cx_6@krA2FaV+3#1F%`CcG%z>}lMFTj~RP~}vfT;+LWIQ6D!#^cJg
zIgN6r<`iMgxQ~k_e?FMSn?D%nkn%ZB((CywpfHYi_WaFSXKrB5V70Y+Rj|J=Z0(R*
z+Re;#(I+Ae3CYz_<(jM5X2d!?S&s}rN*1j(wIQF+VfL7t>dek2m&+&1N!et#R0qu-
zYt$RE*_#tHoeo>H*XgiiR=9m$cWZ6G)jh)<=$9nqEOjwSs+H`D!)s}<wbeI1%1)RE
zY+d}?dfVI@hfj7!teJ@HUFe?&aNh2et`0Z$M^U=Y;&Cw1;YftUj96urf+=sfCR`u!
zm>IL!eMxu(76d}Ac2|qP#^&`&Hb*EOh*{F6D#;`_CW1~$a(c~n25MQ-Zb!({aOIWG
zMvL94$knTvXqKJl()t8TQxM^&xC4<<!gL@FAboGh6v{(MN734b3?h7n;!D?mb*Daj
z?}t@iy>Z*{)9zOH75B7y#I+k=={;-X_P1_+_N=*?;io+w;OJ1Vh4qkqPjg=tRY)al
z4mBoFSE9SD=DBqYCu(Pz41G)|=$BJaX#jvE=05yCJqNX}KAw}nYg!h2xb@aU)*IEj
zB%csw{AAPZ<1z|>qsA$mhP+whjk;59!wN<88~6Mmck>5hhTgYMwh3GlKp^s{NrvE!
zV^k8)*fR39DlS!Ipd$I%u&V`4pgL2OMn;PhiVq+a7J0A77D~74kCx=cKoqGW5EX#I
z-<WMdc6w4+&k-D80{G2vjx>ep22d?&WPkzyb01V2c-29718EjeO;7-w7xG4#60)2r
z`z=AIs;LU0n5A`B&|Fw?)hHTeKq;h!8dx0+Q!?Gcq@o5WH$9+$ma;mnnT%tCGNv^n
zkCPA$5RU(G!<g+t0WZ3sKq;NjOOJ3HM5a!0TZ#OlerQJ{k$GPD80s_RRmV7YDbQvt
zAwZL`%?P2)E6B73SgE8fx0QC5$m?o+h_6-lO5{?7qmLh#V*KOSgT_hmP2(E|p9=C`
zd9UEW8Xbj=J}4{}eo?8|j_79~<qLBtTcgfFakPxu$LkVwXNygoW=*GoW>^^rLR&H}
z*b8yumBjTpQrJ;xBW0NS{bjY^!~G`n%lq>4XIbI(<km)>*TJhqKP-iWPElO}yNj3A
z(E1^Lwf5=IfATOLp0l}qa>j@{icp}nMQ|!4lWUZHE$!3$X|u@)!ch~7mO(*+&aP@U
zR-tRG%1@AE_lUl3=;e3<ZG~Wqh#WN|BLr%+#c)$4jf4Q$=%*;@^}%J)j#w-dT!L3D
z77VRuj^4m*#*WJkJ7<25MPeOMoQkpH#M)n@<%8}t&i|n;9_xsGJJw~onYmm++Ogk@
znpL^nieQXx1GZtue=SUtzYRNk8MG^kcL3B2D-P167o&zDS)QT#4T6@Yn1h*pYE0Sh
zaM#wMHZqmL(y}>jM3}MM<g&CX!J9$;)-*YgEe!ltsb6oQvfVgbxr7Szz|To)W|Yx4
zupr?pkg%+-wllG1?#wCif#!6R!nP->-F0X9Z5^j2^cyX6*!6y2s4nI9G!Fl!dqMsT
zo5|hTn5y=(v$|(&>a7W#yTxib^VqOuj%b=SMe$s)Y|hF}XEe>z1$OYCm-Y?Rd%9X$
z+vr!%%dAzzctXF%GK+m8=m|BZ=@$oQCi({&8w2!v`5sw$=)8?*{_VJ6na+;S+JE-i
zPc_E#)%Y>`6CsOx<?qWwm~lPG%^)e<&T$+IuyT+ON{&%Yj1Vel4OA?n1%~@R$>KKR
zaZnY^tD5-2PsSIAqbN@SWP!6cjaArB%XlyZ(-xJQV7bCS&q=%drQ7d0@4|a-doi(g
z*1VV2E1uS?<_^xAwKnnOjQ)Y(*&9||=^U8VzrJtb)Gb%#=1)Ig@_h28+irX5lO1PV
zI&bd3d@>Z8dfVL7=FYqHjE=fBr}YQVxZ<oUoc(i$>gR1(`PA2!pKtW9@A&)jwemls
zPF4=+jvo!d7&Bh<9-)k=fRAyunE43^6@;KdJpq_Zl~8Cb5r#RqWA>S653;(!!5vn|
z#Rv2o|L0t9M>s!tU~q@UdGP^u2lg|Oa3VjrWAN;A2lPJ<vJK}B>>Q-8e0y+*%}U?-
z-*dg~Q}TmMJ{#Y%^KY$Jx^m&fC9OCzIH><|fZ8kZJZh>PNEKAV6bH{etq?r0su6Yv
zM27McAdWCH*!LP$Uw8!#E^0Eo{7W5z6N_dOoIRuv16SbX+(xWo)LDpoE1CJF=@&fw
z<QEE44c7{a6AbVD!HhLCW~?bl-wI?qB9V@4;MhD!?7xaH9D9vU%s@LyPcY<l^;lF)
zO-4hZF%r{&_Tm`h?tE`Hgp&6bQXCj$G|T+-7f@*(3AfwT;$n6Dqf!6UfuFIhKRdue
zjX3Id>u<X0BccD7e&82B6(p7xys*6wBbR;#Jn;_*l#vRL4x9x2*<!m)t5!Q92~ZmV
zLZYmUcN!h@qMj2|XY&F%SnIMtau8SI(b`yRQT9%yP(T=*{%Akn@@NBKafpt3%DJyA
zYjeQrS&A+a`_wiCdERh@v}3oqPo1WG1EE~$sodAEdMRR%&~WIu3gS;X5WNW%lp+P?
zPy#|h2~j4#nc@X0>D}j#NZ>M5a`F+9gY=0{o7OHg`^1jHrJ4B9wq=FXoE6hsrAMs2
z3kMpeFV8m>A1Zu)byLk=kJ93=x5zUV{Q1eD6---lzMCy$W*3U04&~3fbCzZ4GTGNQ
z^Wwqzi>map%i?RBzOnz)Pdb(?Rn|6b5+mWZ>VVk-K*DRCHr(pHV_+U0fq=0r2p347
zLrnE7VTVAN7wiV8C=u>WM2UGHe;|mDKM=&{s?Zc}qCQ@OzA;;@=G70YBXAg7IR0g!
zdKyTZN01chB1Fk*IFt5?QwC>|&~+=%Iij(at{m;SylNY0+kz!cYbWDUP_#BIa-<36
zh+d#2mnz7or{WTTiy=`c1T%<j3qbl_n$sbwi$<0JqzeLQAdU-<SNrWYDbv2;@!Nj*
z;Oym%$yNU5cqsDMm#l$6^VGz7f%s?Qi>GIsm!(@mzsRQ7gsSuAfF0rDwoYdw%5-$)
zYp1O_r)j8oZTF)3aG<TPeq~FpklhxZ)(gC-A@bRpkTfXEwNA&qvddiMQ0)18=0T<+
z+DHC6<}m3ph<+pg1jUT0PAVosM9~~D230FJRt?+FCXxjxavuup<;o}b0#ea4!=rL+
zt8_bg_wf6?zNi_`VF&_!YY-l<)PymkA|@3g2Bd^SrWiQXix*@tdKG3t1(_>`xpy=i
z!Wf~#8(bv7Y(<EB#E<c~I(pCmh3Hj<@I}ac{>T?paY2HMR!0TqfmJwave|uJPXL+=
zGUae1Z<#7>01QUQ%zdg=!I}W0my}vO3!_Q_PK5zAY;i<u1yH#Ndah9j3B~PrQKURn
zNb%(o`H*&@_7Lpw^9$z_*j-@wk1WY!TY1q}ItzUmk_1{gd@rR5G;u+9B%16o@>w*C
zohlD;OcH$sS%AAhasq&<LvcGUQW5tsnE)1a#vMRs!M_SsmvVWy|0_%c08xA(&c0f^
z0|cPbM5snJkpLEh01W^!_o2cKWgBSq2)+aGi#$wtoW`h8={;3?nn0Ct)F2w5qZN{z
zKSm9M0w@)OLk3ljZ3WsUa~`Bxc*G-KaLJ~T`lVzN5UK(~aHc3$xky-6DKxQB99SVN
zYM;-epl87R;TT3q6?_G8gjA8q!Fx{+>EIP`_6wq9=2aqGh&9$sNZCZkDtHF(7`g?{
zCQGZr-NefnGh<AtM>MX`&@q&#^MjIqcu)iZhNtcW+Jx4_SB*$+FR!odrScx=lnZMk
z`rsh!YM+mf4h2Q?CoZ86U}EZn!daO2!G|h7<NAO&-HClb;Tp8wV9@mVJ`lm%3Vb9+
z`al*MU>W@5TuDnLpQ{zS#t!_CMq&lG)zATyMnU8-xDl+#rz&r|`(V-H@X?Y4CZ)2I
zys9li;xI@-NMHVd6wQH&wGX5>vRFn4jv2+>r~ES)7!fB(IHHyr<-52QTOm4mlEz;D
z-`eXyd)>Uf5HJuvcD_#7z0_WN@MGGGif7~6JlbAr6R1ipKEk&Q9vN#YHJj)QNeD(+
z4Bt4#!nTa%?gCRFV+>{h$5x4Z$ruBAh`4yDC=(-2;9D7q531ykQ9|RR@4fpKN;f6X
zJd#h1%tgZ89(&t3@%CwS)Hr9@<YR4V5P)JL#Fxv*N^2lsC%1-VW(Z<Iqf|>lt49X0
z7DMjr$G6be&fa^J+Cn+8UwL;zBTH<FzK>e^m3NJd+3_vaokx!n*$ltm2<`si_VNT@
zqrGVQ$G10BN9nwyEt=5Y0_w2x*1q>B5qx}W3+Tv_|J%0y!?cY{)Yg%4p4e7)gg4e8
zJa}a07!!bBml!;WTGf<aSPQ?{=yJ?qAIco?f-|vVKpj9d3xZl8N-5OF)HhNILRA!1
z;xy#}5kQ1SQX8>lJlh6~AEpQ3AcHa4E@}@Ev7|o=zzC-d&a9+NW4xL08ie&h`Aa~I
z5b*<jgsOvKNv!7{Y2ZLwkX*7g;6ooF{%#WG!CV}+9Q>~+T_@y##U@O>-h40O`Wm2X
z2^RBf))4D>$YiqFY%Zq*Ri|7wYe@ek`+_K1Y&N%DenJ0Wkw>)n^o9O_!|JXQFGlJ-
zLt!_k+iCNdf2sd`jgR<|&t*=xYRqL+lLLctHO5Lg*_3L87!SmCKrB*dhcUIGPtk<d
zYU!D46q%@cP%sM(H!`vFJwU9C(gpyRGYDW0FrZZkGNJL!^cV@_?1-y$_SuiUO)C=@
zIv}R|TL%5UC0j(1Cea9GD>8@t`e8gva8;$9z=*K^)S_Vk-9~LQM9dJt2mhw#fJydT
zbxkB1Yb31~`auGO4g$D&&T0er%#YS89Bms-iBDT#HxTMZeL&Pin&K6cJZqpbo0i@%
zl2QHemW2i6#v{G*es<)3{Yir*&RcNf=SCRxhNW*mW@Bsa*PZw4k6=!X&&R0~&fqy-
z=m%I6!EjiSNP<FiK`Asci>RaoEYX_Ly3#z?1@6e_kzMI>19nEwP)r<{)$<6!N5rmj
zVwUAdjt-o*yhPjy`7V{p@S&^rTy@o+$@wm$#o=`?oxW<E9HW>e4|G3Nhvzl@;WOgS
z8vc++*v&}dvqE3sPp9(|fE?s20i0L}45L|P6JZxC6zt=2$kh(dv1&xszDS{sR4tQ=
z%ew9QyHbp*5)+%CLKX4th#Vccf9s_CGcwvg_U6c@!9Sj#K6-aJe^^?d#Zc{T<nAcU
z2u@^2K74b+y>CI^>3L)$eK#};^5lU8(CAQC6Ma{B-xcb+k*q$x?=V9rbiGSl^#y(I
zZt;$BH~*ggQ*qTp`rHSGr)Dd$SfpdxIA&Xom>`4lK;Ga$q`PC%207V-{MJFbbp<0B
zB|9oTq@|<}fi|J>4cKsC!)EbY($V`5+|Pb8)&}X{&wF(Pf(^xg`cItEt4`LA5h_e>
z2O?uZg^y_pB7gugJH|C->w)uLmFRANW2Em@_&_Wi*l>WojrM)+UGZBV{)vwVJx>tN
z<dC0*=4Yim4*=Uxt5JyonNQ|2)j5aqfuwrM`9X~f`9VFY|8SYOXLvn(MDl$23iIgK
zvOQ(#$>Ax)TO<>a;|>~A7UmLxRu4QvLNSxduFx|#T-l;op*^#VJu8p*t;in;O~6BB
zgF{MEDxDjlWkp*MH4@13G(-xxE*Ik2>7=bUq^RHFz)^5~DdOKfJR9-Mu!IY{rMLVM
zE(DK#9i<Gw{bA|C66gJX{#*vCOd1vj1kz{GLN{-r8%9OZ%oW(t<{8ix7!>3{NS>gX
zAp(nzkWt`eT%!WW?&VENB9|}3s5EY+Vfs7Q-K>9#S~lm#>)3`H_2l94Eqq;n_qtoq
zKn*9?--v*XCoAy>!1+xs(2}0pmjFdaYGW9UL3-3As#wyPl@*%!;Bny22k>d785cf@
zbhYOz1S&lF<Sirr$B3nWz%Sy&`tVhL{?@P2g`;wV))6nK-KBg@2JKv&b}lk$%pNik
zka_|<O14r?ltDf>D9o#Q8jc*kK%$I3rWQSt%9-ULU@es>@j)Ovv6^c{V2vNLV|g4$
zXL=wf^|IoHCNp$|&YN{7?;a!$6z<YEE`S{l3O~h#5ma@mRZ9G7$ilHcoq3Wzovb%t
z26_yD(f;v`M_L-ic_2ugn8aB__z)J!$z7-nl;P{g>OR_q5{Bq<-UsgOM?B`Z!MU8y
zj`jliV55DYnh1*_*N9Ul=MGS0333MFpb}N#`*69e8WjX#fgk0u!zl{xN5w!d|3UJB
zB4SehI`l!Z0gcMow~?np3)TXg5E1%O4|@+Onhw<afQ&*eer2oyv)Q@bN}2>c)6+xC
z7FJ<SBnRAc`$UsrfCoXMeX<0v0@MrmfV}<yxr2m}luxJ}8bgGHY9+2P!fgWxC?wc{
zzqnpRyC`;_Ff<{8S<o%A!Dx#%TL93A-{u}Y05$r-m$`oreKdTXH1?F2jW`#$kRkgz
zxjF=_7N}AP#y7wPn<oTt0a3c})u3`YY%@Df0BGql#3LTMOwn+aH_K@4j3l1+5Jgdy
zAdi7VsSo}nSVTNl{__eVyilOS&bJ$D^>=ELh(_N9+Z^lW==<g$>8H^Uv41Iqd*an*
zlYTYr$}6Hi<r-xU@(2uElrZka@EjmQ21ihzI)}>QMbY6R`@AVrtgcT|ra4gKTFlLn
zVAm!Jb~VSyD#GKBNO|K=J3_)qLx)5&Zzfsk+;K{)AZ<q^0_WYR`?YIP4Lee^2#+YH
zNM1zr>YEqU=+2r&`sR@%Q=BQbUEh*&PMN|?wt!2zE?C3FDLAZeVcSO!AG?bVgX{2D
zv5~70fgOXL+=2M}A}T8LBD2t22{Y%ZK3+e;K$(nD_{dB3fMltLYW$C=)MGVP5L1^+
zQoZI;8$KQi;DI)Afd4&7)cYmxFSOGGaQR|#T?}1jZ2>{2hDDF@Kmum^Vt$MiD&uOy
zph4Z^^YnwbvSRY@DxG&;sW3eED|dVac8o{x$dAa6peKSCP<lklAsU1dK0!dh?ZAF1
zeAvxAEZTqH1sDGOfg7XIuP7GZcYWQSEjy2G+@hFWpLVr-AC>;ldiOmCF1YZ%8FBWg
zx5IUpOIEgQJhpR-(&c~AXI361(s8?l^8u}InM!>nh-LVJDQ@qyj5bK?m=kKR7Q^$&
z)Fx$LsyREriAJFbdAO7MB|J|DwV*2bQKZv@k>L_!Ggxmdgy1!}rVzf?A*1Yr>}CN3
zB#Ob*ip?uhsD8pOb3xpExZfWM`+w*U?_m8q_=dT*u=Vwu&wBh5g_&(OTlRoI=VF<x
zTotPc`0MKJ_N@MMSI$r6{=}yOHF8{T2;5g)eP5sfn>B%wwdS<0=0LouDekb3&R@zi
zs2TOYQ||Y;%Ds42M?6jCY~jloeJP;;J-y?&^o^S!BSxyu<9R?d?EDX|{tD&*cmJqt
zCHu*ECb}P9eynULRZD0xP&&Slas7bi(8xpZ#!B4eFmWgVA)tUs5KTZCLi_`91$>8d
z9v;F#pOoi7pTo0hJWcd0Dc%Osn4|pJz4I$rjiEP_-Ge}sQLKji@j#9c;;Si?KkX01
z5=|{!wgM-`er+t(L{X}U*dJAE4ZDq8ZAd;&AU_$3Rv=-5s3ol12LV@5w~8-NzUA=j
zttzja#2KDyQGsqmNbIvCbcOE3J7sI^HG~+6;x<H9(p36?)Tf$%tWSK&FxUVp<45(0
z)(u)YPSqpy_6Q>J=;;NcJ(4GkQ603k*(Zz;9_cc9geb$EMrfZuz#kq7AcODK)>D<U
zQ;iNvl3;Www~{_jIVvQfC}Qx$G2t!e?WeJr*!Cdi(ur+{4m7##yw-)$cK(>IO4|cL
z{v4!JwB4it20Uqt(WVodsz17$4)3N?f0O0`)f`I$128a4%mWyX@CzlfRH8A-AN5l~
z1R(ZC+fMV;i1?@6tT<}Ud&mt$_yL~VP?<NzbAV1dGq5lwdHKdxCeyMGJ@h2KA-><%
z+}oGh29Ig;wr!~shk*M*R&86eX4@(%nKgNiCwRW=Xx}P5LEh_VPbzIi_S)zik0YFd
z^rw+I-jHhg2rim1$LTSKm=h=Ii@`(S`FjiGJpj=C5i^|dZ`6_<FRzTOr!=CICiiCi
zxQtPr_vU$jptc^R{;2q((Vyr2)wOk~)|mR}9^qLUxd5d;eN=x68%b21qBE%IgZOU}
zSG+UeyNUgw9IhmggNMfYgJ-=oG()RG5&_tcn+wE^sGAFeKAjywrp8NXJU9%G!Kg4G
zv0|vauO?IvEfbg_egUWz_>rDyl;ri^DVhcO9nF+<Nco|Nupblh$kU*tFlf<!%F{Uc
z)C)nLSG<=X5qUJBIm1<S(jkW%^Iu6wFnGNtjW_DQL$!u6We7>`LLxhAJT@1m+zLeY
z0h>b<2zo@Y$|ypIb#oM<qxncZ9!2QrSwOX@Y4n`k<&*fs{(vnbatzM`q*62hPVrEi
z{gx^KXV|63s^NipL6q`zD&*BeRfm&2(oyQk!)By^rvmT774ZWRbn2%&@&y6%l4K@g
z?~LbI#-J1I8R;$RaQSl-xClrRV_%uJ09Yq<7^P3@vc(ur(TO1lL5+C`6jp1pl#LR?
z`zSdGh>cOfCn5)R7)849424EK9m(yLIYAoY6@u{RUf?;(p=x9tP@vctQN~Bnjo_K^
z5r()@gjJp!RHq1!tDzN~l%m3^N%I9VSd2gDpU2-n{;>R_d>U4gm~a)3a03SJ^{7=8
zsRBnLWqE^CkY$FMMTK;YdS&op6Ziwh*JQ+c7Xu-x*RMrLRrSI^(Hw9*Xl`^+;14?8
zC)karE>|h2*$^<E3@CBQ4E2TT>;m@ZQ5eXCb}=Mw;U9Bdx$F(L>(=X@eDb=EwzlUk
z|NO7T!PRUk`iSv=Z~6ae?P`Ofy3X)@*98F)Q4tXo*AGDD!+rOA0f{J5gTzwXM6lK%
zB7zDS!4DdnrY5n}8f(?0CK^qnX%nj!t+B*9Hcf2DwvOo}*0lNPbexRikBsd&X{Y04
zpwGGYS;fSD{K)Q}ecyBLInQ~|-RIuD_uO;dv)26Q9KCTQW$A`@o*9#zva0VXlVYx1
zZnw?!`Ddd?2HpDEm(7w+#(&i~I2kxGJkzWXgRU9djznBB+k?mknBfebfE5X{Uv@3&
zy3-6CappF{*s;H_HS@W~jYmIYiTTfP*0QN~x8nZ70>KC4LKk!5#g9%|@tYenS%TZL
zz8i<l2j&}jes5vnUQ>g4;uf3l+66*~-Fxw$gAr%xqs`0|JU+pso4nyrFy<%EZUct4
znC^TGRmWb9?}|=$w^T(6Of5yBs+L4w$-{M-yOwkwbfqL#wYbg%Ye%J~SG8pKT`VjV
zUv^7X#&}QDj75*d*FAKw(>=`XYB6mvq5Q@E8`~ZnR{9TXJnqKvdNVl@^LicGU);Yh
z?gPxiF<#{DdmCsd7njlhxcyz+_jcR|Hj*h4dmWHoYl=Y|5HP#ZiMzI$lK43(1$WC*
ziK2gIIEc78&gVMPY(rU7-X75G?!hQM8w;MI9Zb_tHyQzX`g@&lN8K?y#v#v2<~8|Q
z#>#Zc8jrGeJ#Jv^gKo;1G{kM)$bsczcE#}TCS#cBCAwu(5ISr%-ZcAPft)a4+W?II
zy+}9ZV`;k?UpF8vwk?L=jcrDc1#UO<x$Qb%b@xar^g;h2nEa-lu@J+*fV5_WSbQRM
zvoB(Ctmo4I2EzfQoA$-F8HsrR7061+V#pEPj`ra`_EuiI&BhlP=DFW0pMWxEUo1s%
zA;fW;k+ER8&)NAK9TH-kZ;cf-BP1~*uo2uH_;#|GZ^Jnhv%j4$^x@s{YBZzr%~1~7
z*uU@2w<(D;?hS0iag4qa=iOu-`fqRX%3P_D$K|kGls;F;wa0bAb$w95pz1*%yVu4w
z#>3}Nd`0|~!PSF%2473qo#;)hPu!i9lvI(_opgQ314DKUxtd&-+%t6S(Dg$Prxd5u
zr)*7mf7qW=t5dsEFAq-{o;!T^h_n&)Bi<dEK5~0na#};$=~20(cBVI^zdO2m^p?@r
zG9nq9GtQ1F7_(>0Cz(~5n=(&jUe5e5D=o{LH9u=h)~T$&W_>(1W$dD{hsItX=NtEW
zc53$4?2pD*j(>jqYvZqY;yu$mm7X@w4$qAVD<_<rIBVkhNsmlAHaTtb&dFDE(sH_U
z_T`+&xt_Zyw>$T2?zOy>yp?$ur$nYSPU)Q*ntEwk+q94JoAXcP-z=yo*i(46@M=+0
z(axfq(~G?s-cy>ZkLX*z1YfVe-oGP|8F(S+4mJhPhSEceLnp&Y;rj5A@F$U)$jN9%
zv^M&5^ipv~@si>##g|J8N;*saQaZD=x%B-R6*FEcOD&sQcBbt5J>Gkso#~ocKl5by
z#PaU)zt7q{>tD0GXaBRJw4%OZzkT+457(5oj~MVo5a6gm;NSqisd){vPV*c$()gsn
z6_>d2*w9*un4=4xl5e8!Lci@H>VwR+H+4692K%VTSsNupJ>Ck*G3p6cx_n4I5&BK)
zL#)ZJRO-pl1Jp-Cucdz8N_WL<_^su2?cA_oL(z)WU2B?KmbJHa6fJ9S#i-48%-Qb3
zl|c*E^=!5}ah32gg3t0|#H=4$1GaiFbAPGT200J;*F!h?SD`1+1Me}b@ix~MF@z2~
zw%qE#>Q!rzdpVAVBFt8;#tH;AIE&wlTEA$`hi@GZVoOoF384k}D^O+u@~?mg`_*<W
zijrR2mJ;iJ)V>hqO74pFS){^GVg0`rcs^C`0lOU?u&~|U2Lo-Yv0LF-c-zuu<m|*+
z+a~{dw9+Y2g!xNeSl^14tpcXW(}eb!wl`pp7hx2=2@&jfAI?>Gv-f|u^6tOX-BUMM
z=3RvSy&Avr8vOn(w7LVS#{O12$LEn}AzIvk_L_ZSSmx}L`|S8_e)+JEJlIPSJOeNc
zEXKYFAjRQh07s(z!pdFtBU2|f;QKusr!FxbXop%U7$*`Z@o;{XAc>MBLj==};nL6a
z?GBd_*55FxH4UAr>3BexA!8&{vSch~`<fXC9(XjGD3fHe<Y3Zk9^67s#jskqtC2$V
z4o}A!Td{__Ujh=85T?3CB#ITSOQaM%vSpZGI8(}HmdwTkl{r!=U%>hOUa69KQZ4t%
ze2lxUkuS*t`LcXP?uWykg;FbZvPixvi{)#wL>@FAdZa;?p-X?cG|37$rfiXwvPxD<
ztF%eGtdWOgt#nAItdsS!K{iU4d|e)vP4W$SM7}AH%C}^*Jcj?2CuEC!Te{^tvQ@q-
z+vG{vF5g3U)b}w^c$e&!r{rn*f$WiI<XPD(`{X%X1|N{;<%jZu9F#-yqWnmHEHBB+
z_;>n=9Fe1POnxdoavaldekLd772JvZTzchIIW51CGZ^)7R(>h3$*<&fc|*?0ujMyb
z+zv~>%J1a&asge!7v)X)16Cq<OWu}C@<+KW@5I}uB^|u3t;Os0RyeZUYoreel=gPS
zeT@4l1C&9^5M`J$LK&qjccib<k-<v$oONs4?MSe4wk<<mr?RluDHQhFndf+&bV%C>
zNZSZVyK+doa!9*!NV{@K8)uGJ?Z!ab_>ja=;;7viq!Ukxr^Hj@De-*7^AXQSJRk9V
z#Pbo)M?4?#e8lq+&rdu*@%+T|6VFdPKk@v;^ApccJU{UQ#0wBFK)e9)0>ldtFF?Ei
z@dCsP5HCo)An}643lc9#ydd#{#0wHHNW38NLc|LZCq$eOaYDoi5hp~P5OG4p2@@ww
zyTZf^6E94>F!92~3llF)yfE=1#ETFwLc9p^BE*XjFG9Qs@gl^F5HCu+DDk4iixMwN
zyeRRa#EUw3O5Q7ZujIXYopMV4EBUYFzmoq-{ww*f<iC>tO8zVPujIdy|4RNV`LE=^
zlK)EnEBUYFzmoq-{ww*f<iC>tO8zVPujIdy|4RNV`Hv+t&3R&ulK)EnEBUYFzmoq-
z{ww*f<iC>tO8zVPujIXw_e$O?d9UO>y#F|MkoQX7D|xTvy^{Az-Ya>pA%_o2{ww*f
z<iC>tO8zVPujIdy|4RNV`LE=^lK)EnV@(LhUh-ebe<lBw{8#c{$$usPmHb!oU&((Z
z|CRh#@?Xh+CI6ND$GmXI4)R~ge<lAl#`~yq9BI@!j_~i(EB#OO$dlH*o`jm(<09MZ
pj#tL#*G}k3t((`AwgAebb>n*C^B33F^`zzF+C&yytvzO0{|1%B6xsj)

literal 0
HcmV?d00001

diff --git a/static/fonts/glyphicons-halflings-regular.woff b/static/fonts/glyphicons-halflings-regular.woff
new file mode 100644
index 0000000000000000000000000000000000000000..8c54182aa5d4d1ab3c9171976b615c1dcb1dc187
GIT binary patch
literal 23320
zcmY&<V{j&2v~_ITn%EQDwryvUOl&(7+qP}nwr%T)@#Xz))vdaxYSlh#^~UKsfBJOq
zc9j<s0|Ey68QNGt$p6_qf&bzE&HwKZ6H}1|0s{8?QStu6AJzU_aS>6mA1(8T6a0V(
z7zzkXUYUXEN9+9I!ap!DFOd#1wlTB=0s{G=z_>rwLFyJd-Ppy62nY!Dzg$rNAC#b>
zW_IQ_KN{(eU)_(Nsd6JjiMgTUPb}E#|M~#|A(>mdoBe3JKtOVEKtTU^2nd*oEldqf
zfPj=PfBaZ}zy@NZ@n!KN0s$!#{qX<lkisy5AzIitx&3H7KQ+*PYCQJ!AxB%=8vppI
zDEw#@KWJr%QIoSVbo;5R`tcL@Upx^A7;x@iLmN{dAhn-dzyUw&^jfS*yRx%&bOHiW
z&;8*7KerOpCRS`|=V1C1tF`+RNB<vc?`hCnO^trmtc~=;A^w9#jneUt1^xlhByaxA
ze|82A<NkjvG`-upv4M$!!7iu~Gz5}?kpWo0w!kFF@oyj?_)=haAfW%Qn^~G<_V$kV
z_D>Et`TP45!w50c8!{TL10RAG)dniu*zrR^LTrn}O+tRb0xd~0E&>H($0brSGJ*iX
z8bUAs<d}-%mmV-c8osevmk6I%5UC7vh0-by)a@7&y&?k3<Z9wTgT)U|*lKsVAQ_rM
z+&xXPgm8?(&&*sD4SGrU6V}DU^V<FD+WbVgCL;-D+8{ONP3x|b(K?Z}FqQyDA8lEK
zfxcR(LOT*zcWBYweqCi%t<h2v=dH4k#a&-ac4;gT#=k%#pf1hx|HU#VgeV+oAC)04
z6<?!EWj}**203RT=#5@wm77PFeIX#u<?oLuhz~4>lphEzmTHiWB72`anLv4VuEY~_
za}WVZu^zT;R-~y&T~BYSiJ>00^O~gpl9q$zHI%Y>Lhsr-MaOrb%y%q|(42pX<4bce
z&%S(EIYGx}q8~@4pX*EKdS?h=SI&tEv`GGM8)AScL0;U}brn10v;~p2;1NOn2Um$W
z*U=i%VuwBRz@Z11qKr(qgO8vr*&X5{?12dd{6*l`Yp`?k3MDcih%qI+g!qV2n61L{
zS-80y9H-NmrN`sSUC*p$lut-w`?nyb*goYXni_zf3okCBA{zrCwXDq^$DQB5U?DQ*
z61o2X9r4;yA!5sN`)f6pe9e8pguH(cK5%0-vMf9<azURFgB@qsO9$RyPqj}Vz6C7p
z88I>zrWWth^A{_9wXmH0nW$}wo9hf@Mt&V*5m2_W0Zac{Bwl*3N0W}7D6V5mO|AbT
zMePe7b5d1qntWOB)2(kfH3+1h@`qd<P;-YPKtLo%n{Oc<r-es;GO8GaLQcSg;XK+L
z`zjQ8l|UKpl$7E=2x)>Cj$7%?Ws`6C=E;z?vBmFy(ZuU>?ZKAjdKnE_$3iyZHlp%_
z77-FteGS2x>7s==RC=EgNc20pi}B5ZYP?<*;Yn$7M)<7;<>9ljc|Q@}q1HAXA>?XX
z{-<=FYU*8Yx_bmPn*eq|(6}#S=KV{`|BZ*Xn#BSEOxT0n<2%3UJglM<ldqm)p{Gvk
zznudH0{;F6LUdd2>Vh`FJxT)N*_o6m(8iH0h%=F{CzZaZ8j3d^x{KT0bRC__^79ko
z=tr+cA_{hBgbop+gr}pTjdh4lR9OGJYID{f-h7TdFVsTYrJ)sVL)@`Nes|mRJSCBQ
z1vY;D{cTS=MK<Mm<GJ&`%?mft_#5sOZl&KYvbRt=XbdhHJlmT=n+fO3rgpNfb}W&D
z$GUgGv~Lt2mll;L8@0fQgkpGOlooKs|D9&V`DBLsjvB%!T0F|Im%_-jFit5WR(FD?
zq*|$&|H2%85^FR{eO*psA`Lu0CUbFjSWp%~dpsCGD^gTSTR7NCSqLNA&)akG3eyQy
z61~KRD9@D}JvRXa5Aikku9YS#v)0d;<>u(Wy%|e~Iy~QIi?KJEB~oXKHbERbMSWb}
zZ$4oLo6Q7!JY7E&nSn99sadal3PMV~{548>MpAHY2H1T`ZcmF;%7p*Gd@)Z2X$V%V
z$1bYU`a7{N-&8b(7EKxaD_#{2yNI&{t3rygLIQh8i%wdtQ^A4QWPw@AUkIZjStyRy
zt6gfVP}$xz$w}4TO!~910gWc?ujr|I`%rxo*~ZRJj0)|c2kf0tb<J$b#5f=4c81x(
zZ%7)E;8Mka7RH<jgof8lMaE&{G8Renh!ku+hV5hxuca?UHbk792|7)*r{|fpGvXD@
zr9iQI*zKu>H}jLi*?h7#a}r#3UcIh%=Rq+9Oy<}9gOY2vy$@K}ixTio-4X=M1@9qI
z^=K!qz=h?boc7!Dn&O<!kiOq#v5G#>o<J`XvhMyBD8Vy{aO<O>iZq*aBh4h7*kXhO
z>pcXk->0DSLp`H8gAy`9imj3RrTwYMLn%~ax2R;y6z$S#bv?dXh$n!f{I%|F6CUzH
zNglJr&iX(OdhO|M-zijiorLRikL!4b&v<-I;cb2U*9AhJqg6Km0|C@3UPi3VuIeHB
zE<VAre{dbMO!g>vJkk^d768V;-U<9n39<fS4Z!%OE6P*)w|cf~z&NJ9q>OEzwHebV
z^!;=ohVM{+SKmNmc(fHuOajOg)eZg4gP9Z?_0r_5C&wd<_hxoo_+<48kwZJ{Y3kdj
z-euRxbNtS4ORoUDw~*0{d?YbybVf*Z&j3f0Df|p6wtg}#){z60vHIVDYyvXYiqt<E
zv42ntRD|g6;QriC<grTFp5B)Lqd3|98*VJr$rST6j1b8XNyF5`p`cVWJdx#RkA#3e
zK~fI0Lv34q9~2^ftGRpUzt2|_Cshs_!#Ws{m%d-|Pq~eGfxM2-tNOYQxA)ybo&tPr
zy}D*~4m(FY$#qBh{JlV|hcVkn-@(3qcZ{-=R5EM+SZ&PVI;!a`!xqz&hp{B8=wre4
zg1>w5fLstI@;wPh+Bd5ldW?|#AJXDCfR%eUYew_;&(+g6-=ThC?S3>8w7??8cY@rx
zXANRWBOACbA6cC_l4+aF!&NSKMmj<F50TeM^11=0$IbOguWx+Ry>mK4PZoF7UG%C5
zf)X%cLC&;>^$NdUhi>}OaeOh-03Qt>c;rBMl8FXlh6u#+T;)aNQAM7iYm9MwQAwQ$
zauN?iXC->xfF|9A>Yn3rfOkVpm+8&z?LmtUcZTECdVP6@K8N`=NVn%wvgYT?wv(~@
zRQi1syDn_w+iAw6*B2j_C#*4Oa=3>>HsxLFzfc-lqHiBWPsG=v_Rqfna_4v6=XxDj
zbWvX=bCj4jf>-mGLa)^qT)yEMN*AOa6}Y=z5r^W#5+eB*=NMYFLlxp|l;Umkrykmm
z>1Pb@=d7ZMXh-p<@vNTD{%C%$y%YYN-VTD)5%>5QvQP<I{bfuNJ!2gb6l~c^l`rwM
zG@=4mWTj39^|f+JZJM_C@N;q3-yGkk&ndIcW8)lqt|q(bP^jigG875^*m;bm5S(E(
z$scq?l);fG6I8|J^XaOU*kozS)~ZEx6&%b`;&S$?N!6A6W0Yr^`&HBn^<lmo8Nv=o
zMJdt0^ta6G+d8Wp)b?~K^PkeL@`F0Q%ID#3aMVNUrKFwpt+ZEIc$W65Mfb)<JY5m5
z9hQ^`z!Rom0;pCOcWO9>lpLYJRS<O<9_~I0F{K1kixeF)9XlPIeCxgt2d7r`-nbZj
zV)f_UpvRSv<VKp8V;I}L7M8^*W*G-2O~g{`@yk|{KpW#s@*<feBo|;ie@Dy@h^~n9
zcXmk8`Eejsb(PD^B+KP{f!^mKl2*&37|ImXnfS?UQsmh2f$0zh3&po%?~Jsp0Vuc<
zY&a(MHfx!m`u|Nc67f<TbZ2r#v?aF1wZSg`kqVyQ73C}xE^A2@l}b#uo+74`a;y&e
zyp}n8Wa#y=YHEB-rd2RUD^qqLUP$wQU9V3RS`bj0(gNQ2T$&F6yqr<n_!(!|23*0G
z7g_zCF_U&x9^cc!B3idTC9Nw={eJO||Nee@i&YT}$l8sH{Mwl|zwkVqJFp>mulc?J
zubo~#6g|MIS#tM^y?0~C`jU2#a#T$VEGW;6HZHFWLEd6C6gfhTw6Hw56Q8*V+~VWN
z4AL!NdF6?QxaUpsR*ZThZ22BrG(+5-Ud8j`|8n^?HPZ7*MH$Y-GdTEy_<}Ip%UH`%
zC_ybkuvZT`(*5-7zTSgt1y-AX_=4Vq{_y1PK|t=n8Jsz8N`x^1R#L(Hf(SZ(R}et=
z20=K0`i!{GTB{~I3$HZ!fZ7PE0K3mgrlOj^=HLjmlzB{Q!INjU2`4JhvkVArhWI3g
z2BFDRMNusx)0QK>n-{_BPLkO*tH<t6Dz(DCVw{(pWg4$U6mjW^M?!b)K>?}~b^*t2
zL|B8@3a#it1GzFLG>-jntCpno1TF0OMs-3&ICPgAm$awK{?_0%(W?W=|3Ym<2B399
z6?sOv=odFeFq-4ZH~dK}*A#W0I_F%hOcy3B(B=(oS9N?rZK6R)u8SFgYl67%j$Vzn
zT2com)G;k5ej>5&f(ldAjf;DQ6!5hOSn{C{3@HGgJ<Y#}SD=GkOhxTYRR&WZgTQhx
zH_d=VT<?t*N+>fyHHbCwb;JWINl)t_@@KmMH+bk8Q`tU&fRBnQ(#)4NSadxDOZI(w
zdDV`IZHTev{l3e|YJOjG)!*{Qd3Bbc-oK>W2LbR{;`&r7v=uuYN}Q!j?bR6qQf6%Z
zD|U^HaP=Duw&<9^4wcHPM`Vo0d8#?cwduvt)W!CY2}SzBBsBVDmS^qNq)C$4z-w!v
zu|}GDNU(nCqGP?m2nGh>so7Y#2j<s;oMD)xzvzC@oAEg^IkE-H)aIAdPE&ddbR{Kv
zz?P4Ls9REPf?_nP3Y37utt$xkK1mOG%TcYwRL-8$gEJXuB&z{Uq<|?HBo6KK(Wj?J
zn7?lpO((?e@oqz1L?HE1V44tGAJ;Rlb*G73(-gvZ*QVV})sDeYktz#OLucHjCa`iz
zj#G{XAhW@jqDko)(_*u1&v1QghF|w-!*B71m}pm0C9o7Ths?<4GzUCzkEOtcFd(N)
zR-NK}WafFMD|Yn9UNLQQ#p?BeUtWHSIeazWv%Sn@qu9vfc(%jk;7a67g6}2v+3{N;
zI#9U6dr!|U1?vC3mcwzx51E-7&71_sTc6<u*&Iv5&S5s0A3kjCeY4qE&Z)P-9ToDY
z@_9tA!RpL?j<L!GKSn6V8){pIS^jF=rlmzMlWF_4kpk+RR|Z2(PK_Q-&yhW*(1AYr
zzDum*tfgB7Ha$=|AChj#IVVPj1`4-zEaYA&14_4~dhTC!T{*9<db#Fci>SAF;UD3l
zTWTJlAQB4XoWDz=q%Vn+jEY#AwT@9A52;uB*W>Xje?f=`^s2DJ+s}<wE);O8ttKAV
zVVdi0E%z=EH;#44EW3V7YGseH0SU3b=c!pSV1J2X(*4xe=knCMiuVMhF)aRUm66^B
z<_q!fn{|~)S7uEH;JoWOJ2Mrkpw6zyi(3XJqtBEoaErvHIYp}H*j`(3Nrw&~`l>6b
zZHctO--vJs(vA6u2D!C~MMV%ZF_OWKERqY*L7bn~pu>emnX~};w>xKsx+HmlModD*
zRe7jxvS`Tr6uHz_O`!|yld+VyK0FQd$icoJ&6I5J_C@tYl{!GM>wg8ezB^sMFG{SP
z+~tO=8DM|68>>8kL{vLa+9stZVE2&^q(j<a=P=MIUQl<~6qs3Whk!U)8BaM7o#vWf
zHIdjUw~C6@0W0r*n-~|yri;{}t?kwlaip!a)eiKO8x;G(J1BdM^qkFm{(cS&@ZJeE
zxe6sLm!E`;yNen|^?a%|FO&BQD;ZHCIurauQ%lG@$_T+Qi*}@{)lwgXX9S0l#4L=D
zD0l8gWM*QRXx!cyo`47GOFBNpDIXnyIo80RMDX+##KZlh_6}*oYs<#lM{_E`*&a|0
z9?IH-SaET>&WrimlxADG12>h3l$)M<qSLSC7+dyn!#^5>nnoG~F+Q9%u&_RYNWV-S
zu8Zij1T3udO7yF++y7qK8?@Qy;j&>d29gBr(=CZ4lKGZq^?3#ajS1CkdX7~BF>3+>
zYZVG#qpmz`T?l5}q@jYe4}&tAuC*{c-?JynbwY*R0wc+;hotR!1CBsHEV}H{pEV_Q
zQbs{v@#pEsI<-g|xh#rQJeXH}di`N|kNqjL$UE~3So5<F@?4q5Mb!nL7@lG`&~&MU
zulIpEtGc%l)tznBy7I1aI$su^HayiY>Z0bsl-UTxtBvq=J|gu+RP<bZ7mBGQ#%SN3
zgj~!&&tvvZGu|rTA0DRsV8TQU-kP&fwaU!0U7k$;vNuead<VU(pSX@nojEX>Erd8o
zq%Cu)1CPBz7A=EEzAUR|YC=IU9%hvt-M5s$vP}yYbrS8_xEfnDFCI~k&{z?<!G1!E
zK^iZQe+bHf`7!IHXQ83rJd#1}5)~%c_&+uxINN4BK3{JfWuezYs-XMRHwoBD>w$lx
zkHl$$>l6w9E<=%h&m}p0DcU+fGPM`d($iGo+S3fJhaypcIE2yU{5H<0HCgoFK{GLe
zCVD+P9e_etX_H9_t6xc?c?>7@pb;TOf<dm}8%_nHJ)`I(F}c!$ODTK9uZilbNw2u_
zeb8C*HyGMNBey@3QUre)`94+`W7q(zLbH@7+)X-{T$!=p$K>6%r&2oND`VL682Y@H
zo9cs|v@$?BZbm;;TeI&1a|hDjryghe`LAHHYtRh=V`G;8&hH=u_R(Y1pv%n=LH^3^
zFkvIs>V~3aP^2c9bjt$HI!&KIsHF;<6GGV<&cs3&h&!7&F_0TJrW*V^F`?h4z4b9P
z)shrVOIq;gnBtPE8xy|c?B+5Qhe9v=A{q0$_8i?gn>U-#3cMhdDV#r)gg$jBSHuwk
zk}gryawT5)H|i8gP1CW0tGr3sKVvSH=C;mKYmExi&<#lKQbxbVfh72pcQ7oRvXB%=
zj1OXzBoz0nqSwe)?dUE|N0dA`Jm0((=&k$p`<hR}4eiPswo$9aPyxLO4i~!g=mnTx
zE>L1c)=>Mo*a}LJx~+>;2tcjSh+G1pg5Y6PO}pj8+;D<i%(EpdjDHzVa5^P(H!aRN
zDG9aJ;;WOiOGzB8X)Nf8hRU|IOjcSDRn-2j)z^c-OzLsWd>LXc4La-kzxi{dPSiJ7
z8<GOI{i~RF1BpdCtTs;#S~FBa!Y7@=1{d(WZMJIG^D(UJx_Z+Vv+cN7VVIAJM38F`
z&w!hdCl8g+wz9NpnB>JC>pyci_t`xsI3_*zD$W!<hdW6$Q9Ua-zyo25I&FrlHu{|_
zYp#0clvH2Ks-Oy?Lx!n}E7joN)Q~0cD}!}Wrbv<rv_aX<y%W!&1%8=}Vw|(??+{!<
zGGpBE^MdtcpA><jqcoA=99>*$<4tXVP|Lyd;LAI{(?h2Cw%dD@_;lH-jHe9S+i*4E
z4mm+=yxP3;fjmRcM+tj5WK$Q-9_(!w&4?Zu{~+v=o|o<F@{wDx{!G^tmVmkOV5uOB
zh$QgAFD4CeDn>`vvKeY_m&uw>iUOhrn)3ws&_6vxHpM+hCYx}osCc0Y-Tyq0z<hZX
zfpCQ-{8OvGpZwcW^f)}Lo+>_HH?lw9s=QM+-Q{gQx~FocK9j!8!mtbNX&zBR0Xt$l
zvErya$XNJ@m2B@ie45(Z(19?S0|j@Eej=zw0gE??YVlwp4LSl7VHUHoo|LraFf00W
znbw<}e@I<Hbw;);W7UCbDgM&wIGk*$E`08I8>Uzes(fu}n<{VdSNo|T`)7axnJ2E3
zGN-K>ywjN_qvqSYS+3(Tift}Ac+Th~V)w~#F13j;D~$iUE^?zyrm7R;K!FVAfwf4+
zgEe5#q65&2_@2P9Xi0@IzKK<kAr!<DPjQ=xFOaLN-rrtR7gc3RK{~fhjwdfH&csKj
zaZe1M4|b616oGh|PlK!ylqSbV+%BkUfh6LMQBPDHedW1RPRNBs6bBoa-b;N6+{mbS
z!$ND!ZmgFWmo}hTfxvinE|g{AU`~8Q0za+=Z8c0n=;zija<Evjk@?80M4rrT#ZQRO
zrBy?VgD@Zjk%XQb5U2>B$Mr=t77zjDw^ry*`L~i%3hjv^6l}?gMTjnmHPNyRD!RE?
zVzeC>gkFuW>V5P|ms&5GT4O@NM-mhCx+a!f0)LQsDAs{!i(cE9Ov8j9Ot~S$SX^Tu
zbvv@~cen9fE3YI>r2~|YyQVnWpZ-X~m^M6OE$L`m&MG`G=33X8DprYlBgvrAjN>#)
zf7F5}TO}Od#i%Pvr08HxB1L|F7Lms;vt;^z`LYoE^HAlcM$*80N!_Nc@Z0C)>z37!
zB*8pC&7s#0b$L(fb6zzb_{hxyz+_iYonkQLn|M^r48oOlXXt>e7{zFo03wLhcxL@>
zruxmZD;ZM5U?3RR7ni`br#{#)H87#K@FBbE7!;=-Y}c+8!h3d5JExlz2JatQJ+?rH
zEiUGqC0jaoW>(Evnh`H^?>C|E?;wdM>7y!8D4dVkC<+|T0zP?LNZT4#$T22k5m50<
zzoALNpZ84Yo=WEiK^k;g##y>nq*73%RqJFJOX%P{Sin)USV69lwgt`-QDJjC{IgNf
zBW4`*siNB=F5h|FpHc}mY9&H}jGvvlX!|~~dIc_J`?;(WsSic(jU>39iqS|Q7u!DA
zY&kA%G@cdsQv^FWgQ+Nx#A;({7tI>&nigS1N0T`xz+mg6@_{zT%;E%P(``j&bsETN
zs(q(bWF8KI1M_eY6S%3}4I-pbgJgDL2EYIzP<M(+c_8ONwVQS94>p(Kd(4_CqWI0N
zt8t_kb+H2&h#4kT$#q>Ac%Z2bj@0N+O;y@sWv$8hU9Zv@p#uT7sP~{kG6820-K~jc
zzx+zAW+=CEi%kufkYzrAXi1hFg5D^8VfWJSQx~1y>x~0bBV$33&FY`a087m+i@@r#
zv~L(PphOgimWm81wL^lXk96(eK$#U=hQ}pu<-Srb@X)RzEK4@vVL9cwNBv&D7`P0@
zqV@&7+T19`yV}oc>o1R%dLPHOtgykfkQ$mBKeZU*==5=O;{`t7RV`&nOFus5HWa@{
zXbhx+TZxRv=(Ko|DZe>7Tjhggvxn2ed0umrYSl8cq1^h1GLxv~Ovi$ld?|yHWQbL0
z!Ivh5s&TPz0K^%VfE05%mJqQKs?A%Hu%Xt@^>Aoa$L6|fp<>G;+%>slePPEnR_yRL
zj;yc0lCyoP$Ic|g#bX(o<$00nsg*!S33aGHMx(FL1IZKmm2(3;)8v<UYB+5=P6wsg
zSniF&#fPt2L{XsG-fQTT_#$ivPp_t^(ahKd(Rh(8Ou|TmUnGJfHU<g0KoA^t>{BEh
zq+0};_3dYnO)g&8rn2p~Esgh&5iy4}Tc`s#l(NQVP*B`-s(Tsgb%=E*x!`vNJk-`k
z+fm(7Qcae_0=zlj<0~2F)s}a7tknTT`cdo_)g;9@CX6}Sx(tZ<L{_8e_IXE&8e26V
z;CLS(t^T)iM*3Q*+_UBMm!L%|#-JZ)!8T?7qZ1fd)9%>-vBXh9eV`-C^l3uT_&kk_
zy!QGr?i9qmGaJ`03`VTK^)eYd43pD#6!NwJr0B=zjQz5pDVIxqPspfGxc527cKuN}
zM+02tzw?((Ojfsh0mh)!EsE8yz$@B*zv5LC{@~DSWie_CKtd_%3$Mw8a()p(IDD|g
zE`aGjSXm`BggX|S0Iz8=DQwWq7Y>nH=l2gF6&gHY9=4{U@)*&>a5Lg$i6r`O!H}dD
zW;VLr?c@ISTZz-X^w-r)NsJz*7Ik*4Ly0i!Bq{Zd;rF?m8fkO1OM@>WW%j&Gv#v`$
zQmZ$kLeIBScr38Jb@l%c_PQ|;xB~H7qh?jaoofQxl!Mou$divTfpW_5t{jt5n6rPK
z!vRqg8v?Nc`M^e6lM(@2!!NA&BnKun1vVjc1z9YJv06oEUF=G;UtEZ%aSas1z8-O2
z9BC#xzszD?1bF!myHOXw5=A=9o9-@Lhm!h0YZ-|@A8@Y(+_Z-DK5aN{$p1>cump2t
zD5Y<$oDGvcGH&@I&=`_@&z9%lM_#_W8iyXJa<&`Ydn;~#brX*PwN-j%3h<fB>f05d
z4E%>Bj9t_c-iGDTJ%p5oMe%gVzvc6bd`PTb9cQF~$q=bA787VjPi04Chi`i>W<+{G
zV&FRA7KPur^W&w!IseMOaI{i>RU}bnWQwl$BQA-{N7}-t4=-KVk!vbXQ}zLtKK~Vb
zh}Ni+HS~8TjiAhC5SP%}5)++t1N`_`^O*%;^P^`Rj#KY=<U1<4iRfgcC$Gn}AMb1M
zN?s6PT##cH6iIlsJTd~6{wMa#z>G1%z*MAySF&MiUH~wJ&BDU^kXcQH6%9!xbzqRA
z*C;FT!ttCmLLmGAVU95En90d_(qX5~%fa`pstx}K4cq`D|L4WUM|^?pXIDSM7j{_`
z3G3~Fb+5YFcta__mAzP+vqYM1(W%@8)d!*dz-)tf@tMWp!rn*|T0x9DwQmg`{~HF^
z(&{06L_~x$VO)QgY!}xSiz9L|mX<F;xlthCD7a~1a@Gs3cyPn{grQxByg1GOXdc~g
zC&tNHba*q4{u+aEh4(Vc$rrXWAwRiwf_2gno6<9!ufwpdCfLD}U<ho-u{69IiT5KA
z8$Az5fb@wbUgN&CY#$^xNtXax7fm*Q|0*Y)gFOLDY4DfWRy#SN)58U?zu(EJo@?!k
z`g~m&={E0ikHy-t=>(gredtzS?t3cy_RjmTIU(u5dB$Pw+b^CLxKo!Kal-ql57<b|
z#z$iOz*q>+p#JJ3zg*_!Lh#CTQlhLZaSdUpir$y9?7cH^D{5SFz4E4#R}~cZf9Y7m
zo;9Cm&MV)C>%p+!bv-*M+$WJVT;|<w-@zHzJ>RqRPchoQ_7BbK-|yWM-<~FecpFY<
z*+V%yqBEN@TuW|VvPKxu;wzn6PE#vLx(^m2Npl0_=R`(f{eE#>@hhO=C}MNbxWW_v
z>i*?56p5poIt)%$`T(F>Fbvwm_u72fIj{*&-QjYl(EG&}&x2XCp-|gm&6LNw(*^~r
z(;e^7)q{$HCsydP(lnZ{CMFoZw`Di*O0teoyeuOUSTp1qVs*`Z9<21;EeAe2nsvN~
zRC6*s$3cgHx807}TdF!K-J0iGN^SO{w>QZ;&Y$k3Kg?6j$YHFGxQg*a{%}-aq4xqy
z&jBywOH07(H!X%N)*9k*pouLg-u)|*fP*&bSExgq7b56vts%pZKc$!0Wz)kTr{n^c
zH0~1dFP!u<3h8{HY$Lt50id%$jqN@8k8{VALlSz2UVh`a-#R#>zHXSNNR|{7e9pN>
z7TX5KSq#wFmVO-1xo)>HN)vR#Rlnv;&}%R75X^KT9xE{?m|>iz_BH-9O;l0+ZPl<=
zgateSH#Dy&8cL!Z-sT5hq(D<^FoqY@mUzl=C-x$<T+(cfwtvuiXjK|(NH0Xn9A|_8
zN@Q$ctLyk|VnTqJ<NKw#hx8ix=C`ZQ=y`SN17CnncVUIa8w(jE!LoMo8}(k9DHQHI
z-g&fb4KwDTDdi1#zx9j#%q^`6*=ori8}VKF8$0S2b`R=}fw6)b=D-v}<oUJtcxAX^
z5yb{cj{=L1IfI0%x5~<*u#%4nyRE74AKhkNb*K1%B>j>?y7nvAexvXwZ#MsHgqBZp
zatbN4V_H3K-L2vU@+EGATIm6Ap`GU7lnAV|6g`8C(61y*zDel%2}VNAy1~`blPHN=
zu~bPszDZI<LbFNp<XK!85Ox6XIee9uyf^$d&821GmFd;!#5u!KAcJ}-GvLVn{Rtzt
z4zjdT6ugS_{As}g_ErL5f<PA_xGS&hN1g8BpwToJRatyg9x>*Nw<W)=hPmW`YgJD`
z=B+8j-?sG+Thqq_vo3^H8CG)Xn#qUaQ;fyaV0>!P&qvtzvpA@&tGdJu;DIn1jLdX;
z)t`xZwPI`TdB?s+nt}J71mU}hawwEbPnX$OL8-5nO5zHu%kT?MIW=*XjkB-H;p1>i
zcVuPz(G&BP?D09Rzm-PH5sJ;n5|jQEen*(AWy!9%8%FrobT2yz?d&1r2KSS&4>U<6
zI`!cdm9dC1Hqn|R>+xX&B?|~3hd5zh)13!mfVsLczdYF0Z^iL|oZ=M%0c8`h0j{;h
z%1hkP*~06j7+rI@eA;#HV5_3yPVSKp^*V2eP_Sfgqg3u-*%?R0LP3RyTYh<}z$74T
zm;u}KQ$iP(LarIp;*m~l_iNZU>-f~@+~!>SGMv8xF)qs2Y$b}ymmJp+*51+kk=cjL
zmrRQpnwbhoGj^9~t(5N((?x;Acs$~9zAnWpC^CsfbL2PPH_JB*;3Rr>5>gypdKu}@
z_u^!zU-oM)A~Rv>w@^Qe=A>t8Iv^I5(_hL|C*0994Dztje1-tP3-Ei}#z%jPDdt{8
zyj~NQD-NaTJp#iw;$eW^b71W?UD@s5BzgyHwZ@1vXRIB(t^Jc6R_Dv)Hs|F8qoLtu
zkC$6KPc3aY4^Z{pf-Y8+AhHwBfE}WYF<334Vo!l}AXb%trV`AC8!T6My>xRvk#pm3
zHHM+JX=1+RLngN;k-3IQ<#A5MJ7DB2=>^LqD<l_g_~$luZN9^63q#scdK0@f)9IOw
zA&(zw%*8yaBSL&uLmjAs8KwkiSI6xl=341jC97;R1@1QVV~D(vZNyy8Xl&h?Y?;E!
z9Z1Dl3|0IWE(K{uonkZ1LcQK)G$v8J8#|F7>b1%kc#Q5A6%d%>IN;UIK4n-`2>D{q
z6jHM}#0~z-%3!K9@Y#+aN0N<0nV7!}Yjdma*li{=yZCa<F`-5NNS&=0#|ERXw{Gy_
zeoZGR<(IJJ^nA8%&J>;H1McT5{GWCXe?F`+{8IZy5lj<y+5J1!-z#B+u2;#MN>QQS
zrTFrqEl5LQ6y%wNh;`4Sr5J9RFfaH9Na!?n-M<k|Af+EbiZ7QA?2xsPhD^qz1z5x*
zO2?bs*rPyYgwJ%?SXv5v2bAex_t4(hJro?l(T((Jv!`eG90#&V04Z296VLz}5!%p=
z^(GEIK6V+H*Gx1sQ-NMVFsf|%1QmoudyaMWuoK5xSjasUxi`JT<{9<3W^0G<T}b~E
z`7*D)r(1~cq6nI2K(`WfW=CoL3(B|r*xoq&GdK<UP58`oRb~tO+q|^w^G@xp(RYjw
z%T+~^DCV2*3+QV;IC_*m?!z(30jGX;JG913#sV23j!!DHsAG3$-@h??7KUB0F?)DT
zL<*@-Ew>FD%$2Vk4(|tbc=g}P52_RgNSWcn3t)I333gCka0q_DoXC$EE|u?la)3Hi
z^Oqsl%8F|h!W<CC1cZi|dVYNdge6i>fxtA3&}E0KOg)%}(*;8p7JP~oIr7x~qr5ZS
zt}-eG#D;|kb-q_a=YwMke!SFlTUXIIIyhgBr@r1$`M=v573zGUZ&Z;ovB#T+9BM0n
zr7D53GV;cMPnitw@6~l#XLgD-r1|n4y?bO!UcEc(qc7(MCKr0=6j!>Gfu7UOSM}Wr
zrxrvQMB^yRGbu2{3OLrjP=6`>V`nK;{YAu2$`B8FPF$7gZq2ZawtwRV0kK!LeuHJz
zBRuR2nG8L&T7&sF(BmF^9-`K%l-a6BxnQhEsSCcMv@ca`7C+N|8~^)`NY6R>9&v-F
zrSt9am3)7()<FA2XNl4(@>aGkIp=6JF|$3I0`=vgS2}W>J>gIe0La)`lZ<Dt$gm|Z
zcmtk}6gR;1VHh5K&H9jg^Mu1{S46hfy;3(K4aO|1iR)rdSd;@aWuSB9|J|<c9zMPs
zQQ}@)X*RZjpDOe6J72Ol<6K(TDwoQ9YY<M;G6T1Cf=OeoVA$=yl*-788E&GT<ruYO
zrdKCMK3(HqvlZkq4EVz}e4!vKUZ*=zxyU!Vj_tL%aT4{w?AG%<67P#6akCSh6N>1P
z{l;udc}QmIM(7D`(wZl?Lb}i=W9(rVd}caMm3YX@2^XEe7&6ov>SA_Ul!YAv^tDYe
z*R}KK;n3W|(DgTksHFp3@6t-fBvNI)YrjgMY^JK*K9SzP<OUBT4KSew8yLe$5W*qA
zp;CX{?+b-;vd0|07I6=L94UCseOgaTWXHY;oyh|qfO@U_$}@a42Kz*l1%^?a25)hR
z(!!u($BZqmb4dbO!itc^ir)ZkvFR6f%i`1~9mCrC3g8!^_anuZrWSW1{>;OKf3rVT
zZIRx%tWtOEFkX+LaNh*i3kxphn^$o6AR{?)Vf=48wJF#hmJAL{4=%^PHvR5{s~IP{
zw@K5SuH&}_b<P?45;M%vM|WKItmW$i*#LIx;T|TI!fog9o9dfmNLwz?_uk!f9oJU=
zkASy<oJ+j~W?bIs{-`I_U!DofGwqhn%T{bbAZ;{ST6%B9(`nM!xcs5th-Scc*oqiR
z(dpW%$L&&qjA#+NtQ?rD=3<1hUG|=)8qnT2wT2+I0raTkVTk&t#>#waDN@Dr*1#;8
zj3>L`zy2mj!ymgpko;mUZsF9%+di@q6&^JI&CNM|2-W!Zeqx=@JCWw~Na&^Xr+cBx
zD~Z_rhQn8JeQezgl~_%EHY<}DHhMelQ2W>38M}*g^5Ct4+hNyYc-PQrKYdKg5LHHH
z5W7c4sF^;~J5~Mpel;s1wg&NA+sZYw=yb=+oocgx@pdsA=k7k;S&^0Ye2PKV+jA=J
z%kv8!s;L>%L)sb~z5JD`X-KkMJ5d1~ffCHpybzHPuu8Wkh9i;1AKMAU1s;ZClWgMl
z9P`0tCm%NxKJ+&MOk+0dFd)syx<+DEDBOC1G?twC@TmJP@Pf+(*wj=;G#0iQZJ(iJ
zhG-xA3G|5*R@}e@#7hh_*PQ0J_Ka#hcc~Q+8mb_($57A2Z^ikOt#!vf@PA|k3?1E5
z^UZ$&A+KqZAMh0`O@?fzgWeM%dCVoQ%|~*CFOh+?GLu=z8cs0Doi&=R*WpzS47aux
zHba&$jRt-gFb4(L@D#uGjmM|c$++VCtQCqFUas=KKW6lql}beIi}Ay+xI^LtKc@0l
zdkQ#o-z()ZN*r?{x*<<JW4l}CpTW9Q_N*te=v;@R3~~W9{yt=@HH}X+|9pnlXLxLz
z)^z<1tVpW9e>KqloOm<s7_-#Oz@ZD~a284&Nu$B&TjMIZ{LN9)-+<N8;u)c65uo%b
zUIOy^2D{EDp2^ktTwcMcCa!aMb5@-&$^M8T%-C^BXwR=?{gZt#86BQpyv$g5GEk7n
z^ti?x8Kb-AY2T+m+kB|Wy0%u{Ip5gx`9O)vPjjB4$p|ox*}0N2OJM$NSj8>bT5w&V
zwbjn3a$Q(Enfrp$2j4p_eha~MoJ&}&iUWxSZ!8q_P97wWkI`RGWaL1RonK|Uak^P;
z{w86F#atZuy~}Jq{ejU<W@f?ZQ9AnNRoM|10M`+?c;7@y?Yd#8W_(ZS;3zI8sla(L
z5Y1sqI2Hf+I+b-4RHIg)bq*%?OlHs?+HaANHc)#etx)3C-BRPX4S5~|gZhYGh(ZFu
zHj&U_G|CAMuwW#Q;G<Y;^tte;A3J-9I0qfdJ(*;megylO=I3B-bnzlErBveR_4sIb
zYki7~$Fyu&wS3BcZdi6}>dkdpr)fS;-)D&h^{m;kRv&q0P&gY>_Wn_t;WSnIeQ`eb
z%#)mE*~XX(4i>^EwvF2`&wtc>49nS`qmL5rVz_@uPo?s)>dW#p*sb5eNQ$qmB5fE7
zIKEk*|9H&Y!}-D<?r#-H;rn-P>4T&BI9rH|YQxZHIugY!WQFWiyQn?n9k3;PL8)U<
z#A$~V3iae6z(8e(o%*Jz6x-yjLA3G>j@cDD{8TQFa@~$UQzl;@bJcoH%=3~W6|DQs
z<e{K1lyude^*(aF;ojwvJEwmPp{rB@?BY+HmT_vDjz#dxh$p$yG$M+(=&LYn?J*Up
z_-N)AJ0hc2Hah+{n4KeggFlt{?eo-9eOmIL)Za1k<3<QF;s{f3a=BvZZ%PTPXrQ?E
zcGdA2vv7vk(gf1jyABAdI<Y)|>(HWs+Dv4k7d(U{^^k~iOA&FEyEHm?ov{QGSJr>~
zNBu!tDZKyZ{}g5cj*I*BSypu7bHuIB>1sJ{JNP717@@1r>7Y4r23)bUfoFRm^)9*)
zCp9u|gQ?d{lA>+D7QCSr-=sytp!RCmlefdPbI3o?<*$WGQBXkp!Cmif{c*L*AGg&b
z?7DWdx+ZbqK6&wh=w7UbYfJvH%6U0zyA-;}t7CBq?(%dq3th6bFl7)PLYI4xVL;II
zyHxo?4$HrM`P6?8Tvl|24X-t54n_i-h0-n0Sl27fDZZL8HpAEcQr6*yVHCb~N7E27
zmK=cCh>pD6WTW;ikgkvgiM7ROCf}QC3cT(BH$oGu-0t^8PgZ6MX?z=8Lz0ne4T4^V
z-thAcyiPMh&#zu3J_ES$FBkO~$SuMt-s!u@48@57H?*$e8Pwbi2Yrp3CQGtR8@!yj
zUk8<?1<K6e*y=Nk6->vkyy#dDr0sf^D6wod7j5Ylf6w`wCmvcUyN^|w?dyUD_KL31
zE~V1>J!2e)z`E#xwN&7d0=DYa2DB6pQ4$wj;@8aSM@4AZA{vjr3qxAHqrY=7T1`94
z_r7;6x{PXo9hdnJ!N8{tBM9uaKE8=KN-T_n=P(rOra}Vi)`j2v%gIZ{7+g3|lAtj*
zB}}a4stt3~a*NENyqPR5c(%njgkzR6v4J&RA53RN_zXRj1VRWa@ng<k!Qa@m6fFa`
zYzyZkjpB6J>nMMCvLZvQ@+s}}=U?P|DLxeem<(Nuv7p63NlkA7!CE10D3wO$!ANw9
zObXX`YL=R6%2TeGd1?xrLK$VEwP`qN7HPlo`MM}dK3I_H9Mzu;W}$)%JINEGUpF90
z<gvB7E(zrOZxcP#6{UX~`yp&i;NQ9R%e4utineLnt8bPaovVl{U<?4W^;QtD0q6x4
zi@>#}mTOLB17SWhL}ZMRGTaFgmU`2O4g(>;@kprlF*Cp)kpy38(i>~14$R3s?6^?3
z(HgVQFov4jM7QWqadph`*vm$aIIXJNNcy|m2$G|ntBgb!GwWC48iMztD|o=(>;15q
z{$%3Oyvm9@O`4JoB64cJ6IF%XU*;BiuoJW(Z#j^UH$l#9HR{Mm7GhSUp-f9TbS(>+
z=TBhELjbeJW#KE%-tr3Zh`nd{*Z|1O0F`(MTCf5%G2HfRAaIr0SmvO)Tb5xAR`)IS
zDJQ*_aT_PknaBS3@{3I7may&O+zm8(y_ea0+%G2M5N-*A7TFy3Ev_pPhhj93^hy2p
zsf~STscg0VHv6)-suJJ_HvfhYQrC_Zn#OPKnOTJx<X2^otW&`+!NnGf3aSt3yp|54
z+yQPf*!ss2Q(Kpt?XAz_dj6}O?~?T=!sj^5(-A(8x4!Bf+V_L6PhXv<jB3ax*7njB
z(ZN)fN?(@hO&2KRV~x^%E70YK<#LQLS3d(0I9eOJyQ1uyeG@@(Wb^n;QV}xx?EYO-
zdy9$(39dUI3(6v&26xINoAl#VyOx&L3aF5W2yuk1Xqz-X9i2;xi(gqo)d?+79qn>|
zt$bef1E2v24uA^CoX;uvbNr#<^;$Bn%#1V#=IB2G9-e7<Y@mLs%DwUC)-Hx+BO`{b
zhM$L)vLPrd>lqg49ji0~i?uStqONO;%fa+^ReCL3RZjio@nXo^g1nNPbwp1HNQV$>
z1@gTfZyF)87$l6~%5yxJnEQ+ie9+G%;f-}&?6HbOe(kPIzzE$iqX`vfok4&ai`W-d
zwC99WD{QBt=6MXVD;D962#XX?i!3ihIshIg{q>fXgAMys=@kLkS%9d+mfwd@#_C~~
zWK@5#ngAyP8WOs%@7M-tVjQG={`OIT#6O?~USMV}Aqz>h#^!wFb!x$Ak5eY`gw_Il
z+T)(XzI$10nIxlz0YQ2v4bhDugbSQ_y@s>>rHp1+Svi2@-tSsqlpIzzPTyUJ4&6Wg
z8t%*#w>(z0UiMXQELXctsZ9~k5wCOwHVp$8E;=11PHAtA3;??YDwCu|jO0#YA&u$Y
zH5r8Whl=eb)AhDqcB?eTs5~8M?tF{1{8~NvkvAAqv1XpE@W8WAi4NlSL<2eyn*gM<
z`9H|9_I|T^m{J0!3b3`LzciFAtd2LRu7s*s_Jsb0!7S+S7aJc*lt;`*gA-fKO8ArY
zhA?VR7)jaRX;6nU@n|8Tf?%{mBM3tZ{xr8|dm^KZpSP}F*K>^y1+c#*N_x*PnQV4j
zHXXs6C)_oV)=7T8wRg}#7y$*Oxzi|WxACj3t`$g+Hqob;^h}z0MYNO*)*)W%TP2K^
z8+E9AzoFgl+*G|4FIloWVp$TG!&6mGHAR&+;NTh5J^p6y6{5nltCkJrWQ|oU6qW*h
zPfOY$qZTp;a(A%n4fddVdJyiB=7!MR^#1%L6Aw9d{;jcxYG!qJqe2pMrVyVhg_AWH
zCaVB55F%KKa5^A)lmMTPG=x(hh32&U*SA$xDMyd3{ZPxizi!QSz5K)*82;WGBaTay
zHDeWU8ME{rnLTO@q8U-xW(Oe4ST5z)w)yoW?X}$W+<N7V69>~i-yIXAq7T_olt03#
zG2Gu}eml^<1&ha=qIj=`nCg>Wm_0+Cwd6oS*LRkQkSgAw;gvpLKW`3noP`D1=r5(`
zPz>bAt@<5_%*bgTP#IghY!XJ=NFJ98zDt@(K^*}B$ts!PZjYpvq%tq5kYKLcJ@r)h
zpjGeWgspjG<GafDL_GP^8o5K}%PZ<VzL7lT5HNT1e$4Cl)*p6*!d+KArn*qU&~5?<
z=13dW+N(1QRo+4<sP69GTD|<}p1FF83s<#E<LG!Ncw!3Yh<M|eOrXGqtYl$!`uRHo
zz|PwfS$tzTC9KQlG}_)o;2jyN7L+2h{pBIsO2B3y2#z@^!j#!`va-UfgP7FS5lX6|
zkTc4APIj4o;nQ_e$$Q@60kkMgThl2KUwA;KtM83s;LumjuG=zc0Q1I@+Gq_Ckvy(&
zZ*)V(e(an?7r9!aT2>$}U5I3;E(wFu-T*ttBj99nkVSJy04B*>3M>M=4CJBW{W+wr
zmo8Lbm?dVE#ijL><;n9dCt|#Od|9HFF4#}Y<2rV})IKejs~q4`MWlQNc41Kjp$r;F
zAUY8dDHmc{hLF%=Kik+j1W{WEZP4aaE0T_9G2k3)50J+n4@!F~;6Mm#3~zA2!(uNW
zD?3~9!k5Ez<bEJKo|shg=HV_MzmL2RhEsG=wqr%^(7TYkCpz}~z1~}mY0ilUA<weS
z)oL-t+Op{}(shbk+iI?PS$EjzuRODJ-<wi~q__QZ411Qnz|CwinBwX@hTW%a2)?WC
zIbFu*zA5@EHzSgLi{%}#LSZt;N*lTsfT(My2Pv30h+)9h?|TVl4Q7f|Q08qJuo2uX
zl$ta^3L?dsNd@N^YyvEN6wH!xF1;5SN~1iS2ue=X9E!fnhmiRJu8*<Z$wxJX?vPlx
zqO@;G`k7HShV_drXXjA=3ilc@ZC*#bB@T<vQI!MZ1kbX=INO5Yk7P$ZeKyvH`!X8T
zI6=(PDN{2mwv7!!Xy^%QXCKLnw^$0*e)3fE(~C^T65d&ZX7Hp`$;j0u970B>u$*P;
z0Z-5cF&^e2ZT=G7;H2(U6=DL_gI^{}SNj?dg8|^Sxt0p`cq^jwVM;7!Xjm8d4}Ns&
zKcd#kpeC&YrVPU?^63<(P>{Ui+6jp;gFDhm^1pecu3C8b+kR_Tdy{IMWKB?1fmzJA
zRrWbi2iAWJf`OWX5*Mgp>n7+MnqV+8M&DPEmPa?H%ZJ7^zBIqoh9?*U3kCchz3T<(
z{o=DphBZPs)&O&+xL<}PTrSUw@BBJF-j`J7B@go*T)LO-j{0ZZpPSq}+fSEg4@}1L
zZ8|B8jgb2gyHh2Popw{~EdhN#pk1m(0#ygca8F4f!i2@Brzr~+t!U)sEME!yD(7c}
zH<p^y$`^Do%eXFLgQ>IM`C5Sn4OHuPfASSw^KEK{5G&ZKT-udhQ|yIrv`02n2nEE6
zJaaj=cYtkxDp%*vn;v7!mw#(ERHUI8&%?XwWWwd<KpDk(zORy8V*vJGdJ4n9x6cKw
zfd*LCF)T_bQsEZ^g)LOAC_~c&_(PViw7@Nx3OEp{ey=;vVhe)=`~fkT72CG2q9Dcy
z8L~9Qav?TpXuW14gRE?o5^+S7io#dEAR}0`65pC{WVViSDYVM%n&<QLfgr;B6o)rv
zTIb6}hLPs7#OGq}s~%}B#cV9lGRx);Rdk6gx7t&ilp$ilgyv0LB@Cu9KvHdOt8WNU
zRKE)Jmffi^kZ1~E;OK3djWI^Fpjc~Zw8H9AKhg7Hm~#E+7sc04Yv@z#YVE2vr`%0h
z0#-i0Nt+D*ywDBSwdR0Zq`4t^JgxPfRRm83TuXWye4%JX;j%9Ar})cG729R5bu8e#
zyFXy9Sgt5k3m1GHQhvrqBSebv3B8uXLOW`nQDR5wndp=soDn~pnVZ*3Y=R5Minq-=
ze;L<YU;KHO@o%%GB!`p^tto`v-d)0h^XuIi{>^?J-?@A*9kw-cvd2{8XJT$}8H$!5
z(CR70IjoaC>DD~Sdvbq8(GW$Ab&QVq<a+b~w99k=9&}6LFT3*KMEP01Q?{#*n~r?C
zvt-+rN33S#(1B3y<PPt=Wu3o8HQ=_wp9MW85HGf%H?)vfFc0`js*U>s>5qM-s&(pM
zPqqe9RFj;kYc-8w?^V+V%7{u54k`7Ve?+hh+r~`oRnKXVB3p_X{b-SP*}HtZ{G!PA
zYJH&DPN4_-LI0Qq?XoMhMUDvc#~1H5z9hRdmx!A;m8^?6m~Y-#b1hlP<)Eq8U>?U?
zbrG~tojEl{f3~|C?x{5NaaOUOJ;yJ2hOz;`4;z|OgBGHrpdB>_F3<8WI*%OHZMd3j
zy2oRMzZ)xk)fy^F3L0R20hg0paZ$rdG{I|!)H%|BW%n4OCnFJO{@5hlKEt@{ZF)bo
zm3&_P62l@ToZ9vsZl7rqgY|j&J=M}0aCXo$QWJ`uVjhB(*uS+H^UDM}9<dRkDnlc*
znAM;mGTO}Ao1UY|3y&UBgw?_ap9soX+%OBoMMb88N+Y<dHS*nr(I!;0QO8(LisB$V
z<!{@?<-<+;>(ER4+JpW&Q9Bny4m*?YQ~L|5@IZr?xwVdan$7a%9{gv7nROdai@`14
zG+-^|Z})4_OtE~I#aE~AS0(LCtNXU(!?C{8pLWYD$$@TV2HsDljoVJZ)B}69$9)?5
ziNy=R_Yv5a^;<rYaG7BE09?Qz657Ti2c;I2FS5a)kV2poDVF{gnp}ioiqH@FhH&lo
zNh7nE#KPz(LINNl@EqXFJCTKeE`|_&iDZq5N7~ZwLyi}YDdrNHX}?ShK>THLpxNLO
zy{q2MTR&jkfAcY;d3}8rjNG3Cyi-4GYlGzJkoOXtWoKd{@;N{&Tdn@M?Y}BW7UX`*
zGLMt1)|BC45~;O<iG{uDYNd+R7zlyRioO0-GzLFjJh!_*Fra|clo*|^suLEj*rJ!F
zkIi$_N71d5nHQ`UZc+L*F}t3Z*Ccwat;B|pP|`48_exav-A};rgp-YxJ}bS&pN)<>
zYEbYSZ2{~+yv)QlkAVg?M_pjZ-!GCpjqn>zMaydQ%*lyE0`=2E_1o>1!sJ380i_My
zB})!KN8vNL^sR*WbvXhjt`v!TIljZl+nd*r_Ksa?e3=XQf1O-aR2;mzg<{2Bixzj6
z!AsHN?hb=%ahKw5#bL1GFgQgEgBN$VL0hCa#pd##a~|%x_wD3M@@21Y<s~o4TG@Li
zKvvuZRmC`t6i7fS^4={cls_z;u{+2QrjY^QMeFKzNuY5V$E^Or1}_&O4u*=0RhIMj
zPfa1o)WSIp2R)SrIdRH~T%FOUx*gJk@uA7DqTX{|<N+71#BcK$WWROSv$&%-U8mg!
z`C`id2GkcYkNkAQK`V~WxR)I#9w_!s5*&xmjKSJ1QZ`librtCu7f&f5*2so$+#Bf2
z4e;JKW4ueQbeXAH-j0<r^!2__bXa}kZ)_3OroSCU^l}_?!>V9+3{YvzBcTXYf<5#f
zw@nazWj_=%=H(>O2QSy@P=u8`{8`_bk}x;!P%>I-jlqoScuG}=Yua=oBl+#ICF~F+
znS@$6yzx^4vw5R$n+4Gep@PYrOxf{U!b#0SW0W|~0Cd`pg<Rvo4*OxzaYeP0>H+d9
z<CT0ieN&>HF2Y}rq%oV6;IeW|n{J_U0dOcSD`AWh!D^dDYCb*c8^ladlx6e8v=7}U
zpGCJ-DErivDK7O9PLYZ!KW$fh`Bl7Ghke)_A2^fB_mP3$@dtVOu4PdD;J9^%pt#r7
z9aUCSF@MAA8f69~*msmp;gomRMsbEyIuir9mRT;mS7@#2U>)4Yq%WOoTL5&hULy8K
z>kDnMX|3fn-RNuw(0Sen*8dtIY+Cz>5U7I^6VXeO{2jLdd$q><>Xl&1Vu0p7fs&1|
z$PbIJ`zdYzEI~m!7&#%G%tX&h5*}N*sl~^UqaR>nhk<lr{hTHXZ>NBS8AZM}wh=ZX
zrjv;)`|w%_y2#qZAId_YsddV+wJ2*du<$W+5t&FUFZk{rEi3ntr&SUnt|%1C=Jd5_
ze_<yanX6@z147LHKx@j@TnwK7aynuRYD8{a33Sf1D$a1HOjlmEEBTsOo+Yh^|Ko^%
z#z20MgXKL|1u#y|Zpseh+BP9sNZlb;3yv@~@Ov0{>CF4u9zeMdmT+erqTwwyjqRMS
zXmyK_a6D!#O9m>R+q5u*q)F~4F&iq;iKuj7YDjg=gR!K0M@3p&cI+#a>do7bc+EFf
zp}{hAArKj;X%SHZ6D9Rz4`|SSmahv#VAGy11cXaX)Mt;d8M1&}1|-hAvZVNiXA6o<
z6cfy5!JL;QBlt}Ru*oAMLs~|FY5`ga72TPzIc9tZFpU~37kdem-*}k9(J*PIpJJ^J
zsSU)i+YsOesy~Wy%t%w6zMqz(_qC;@@v>^vIJuyqXhxU}irkNHR{VlcZHy_J-_{`!
z{(i{Z^`o?+;-T}NH3_eik^=@7nJ{&KH>NC>I8$+d06Es1h|Pqo^o{1;)^}_EW(|57
zyJj+53*y)m6e5F~AR#?Ia_O;t0+cCf@_;lqd9@>cWM%$cNkbgsDZ7Cp`OsmBv5a<U
zjh^{aGIUo4i-y!0T=1g3w9$iB8CV261F0G%lg>=TQADA0^??l-fO1^j=fqzmv>$Ik
zsF<+b%&B*pk!HX9Wifnau{En>S<+**we#g+tIq++C!fFshl@IZ%_AS&j%yNkj=w#j
zV1zL4>BCBv?8m!_A8vU5w_+jRJAUa*K$Sh=>u;o)@%gZm(Hl#>>H9yA=VD<p@r1Rd
z>eWW`zerl}&-1icy~%Cs2WRZT1JiK;)SUZQ>Vwq?HIZ#4y{7%`Ht@uU9-2mT?U8mz
zC94OXy-c}dfYYZ@TnK!7OnYwUnU#=S)k-Tj1Py{Y_*g>!$igUn_8Hg?Yd`YAZ|<hh
zk~N=8h?1_pr*6E4d9TU>zO)ET;+xY)CD|&4M8hSGJ5rwlLozN)`xJkphmTWhnkH7R
zp|GN?8<bnBp;)ahkVscbCR7;QM!t_lE8kzXl={MGio#(UZs0#}ScXhYD&vDw7yAHy
z;1Wl6l%nBSxH3Wb;2jNP!5@sLiaK}~M&FPvTgpw^zf?p2F<tcN!h2T<sXv6B_`}ck
zq|uwu9pKSt;s+j3OlaNU+o2^T9))uOl5t=Y1ZbT<U@kEFYicx8UxzC<pXepzVaI})
z)n{JDWYpe$bp>6tSl;KdX2OoQGhRYBxMNYX@MpSn5D7F}DSPf1*q`Ib#*a4Jg@qHh
z`7qyVkKaMCcRemWNY651aHvi)D<vKqkvwl1p<meSi&(~-=)zFH@IDQaI7VtC`hZoZ
zq;&+xoxe4EbjNODw&HE8CRyV6QCTwD&RXY{f_q#{hWG;yvo%}$YL8BRA0h1o5KK*O
zXD3rjd>t;N!*0nRH%gv3csv7=?{>O*|2rMzztJ4FC53iHh~I24S*ZN8u3B45qTO2k
zV#a%<aCGQ#Wan|7k?*UJ|IW?bBFS}!^|`1$gTuL|(_JODa-|cXMJH)anre2(uEuqy
z${k#Ws8<}?5mj|d-F)cVG`Qp8-~37TJ8B|MiCI&p^uZT?;hIgoU1@FM%YA>2-hio?
zIFEIohf8EYWRDv0QIK6XdRv9JD+t>+-4?eH^&08HLs(EaIj}>ufdPG-&FK`ox(hP)
zSX*Zqbos^?mzT7`kU=2R(_sFto#;e1-jS!3{wMk2OMcoJ>~6zIk%mvT-Jh7Kvbt$B
z8|rO?J^g2Xr^H3M{Vu`P<)l*|Vr*E1X<+$j`p8kgt6ScMbN952xjmdzc;`Uu<QHf4
zl~+TX!1`0?ucVcQ&IRAQq=}Km!mS9OlBq@0VWTPwxEavR`#bgV!0ScvE>BmU19zH1
zdQm<7)we%}!ruutZS5wmd;bx?EJ416t*z8Mi{3Jr!!9It;_W3U$&c}W?2NupfPAbz
zaEvS>tF=;!K5Ao~-wL{`AaKW`2vX9W!v);+3<v!_qH4;)NV~`;e`*3LWP>Ne%UcVx
zb;L=lm)%rYtA=x^cwa@f^IsmG_fHBMF!yLCJ+BFOHR>7stJd)?=Nxz%<lP`F<7F6i
zl(Ho9v=s6I2a&Xf0<qVjc%moSjV*_;&?jyU+`ZB>8iP-Ve6eSZD~t{%G|HvhpWj*;
za3=~ov&HyCmD2vW$N+mUE$10$G3&6M?QY&iR^o`>Vh|lw=YCxOOE?w`X@(U<9Y7~6
z)Fcq!<`YOUk`P*#e17Azvnu6Onjf2;iYsll!t!`CbngkGOAaC^m4^RW((d+S-n)L~
zTM!mauKzQ?74*h_S1<vmr>@6)A_2|}RmHj8#A&~vV*Vg@W*Y<^Q_2%(ZD@hdlKyCe
zl)xetJ8!pZ#}qf;Cj>*iNq*>30qx?euIoKYV8uSrbVuX;KB~UnQ#KvGL+w`BNcSS1
z;U~2{1T}vKDOh?GjZqA^@8P+OEsh={qVYmQ$vY&4jYp=IpNGGesr;aBWx6o41JoSQ
z(}BH4cv2?sB~?BFm6;E1bvk7aC#n*P%Oi?dG5L^1-hlm5(P&r2+cnG+!{_XV`;L8<
zl|p)Pedy^d3gl4Zq{eg%;hsN&<yB-qP%*JDx-dYQv_c*-)yQp|O~sa@A@qd80>VW1
z*YjjpggMwY-|~3Adr8jW^cl@Ov{4xMvHHP;dHlW{U@^uuI}B#!zEBT+oebadmu;(T
zo?I5REG^zcKLB?tC^&z^j$_l$2Lu>djULQa(#{(k8C0@jcH@Y5plQC>XSdZR<%2Fn
zC1CnY9?x1zI@i<LQ@m?QRaFCg8bH71r7>^uFuX5uMtLaq!#%??TkQR2I!ifI;x}j8
zfr`BP^Q6sA8vDu}yITqBe`9jn(s4p+U@XAi4YXGwT!~ej6K_%!Fo)U1FJx5?IX7s?
znI|z&$~=$$T+LNGw@LY9(K6|S?R%;K9(2@!slJPxmJQWG-*CpPI!DGkfnTM3=U`@k
zo*N7*koGrw`pli4^pJpjgSMLFVm&}>!aSM4cPn7hzsL14QkK>UK(EW*q=T~B>6G2r
z3kc0PU=Gmf_i1!^$IwY;XsZc*z39uQZd1T0?3v{XK|jR#Tw@inoudHrzw!~8x`ZUL
zP>9mhb4GJ95$7l35USY0dK*R}JR4u>ysHdTTaV{r`q%*N4gv7}Dp8PMMD8}ve;U><
zz?5tAj*Jp><IN%YdB8@cm3jxX9*mppISr~d;tk2{_{IB?(_%J4+iwPWLW7@J_VAYL
zzdJ+ZteN4DN{i_VlbhK-Ppe=T&+r+1hx5qxl(|W?sBMQw=h7sewyaRI({(_eSk4<;
z`Bh}Gu})Q+7wA<cBygT$NEPbl#?A3U^Fk9K3l<q4HRljayEgA*#Nkrbh%gU3hN$em
zPucOG6oHlBnNr1wzDFxK_wh3}^r95;j<fX$*qk{H%6beur0}K?J%93#EZ#HsUUlmX
zCvMC0cRVC&7=A1sW)c_WZlhXii{CUwErjM2`T8?jf1<sH=Tx>e1)7Dm#5|^+uIQ)R
zX62|+|J^j_h#O};zES66?fadp5IKr-?2tmw=@pHfATcp)iM6Rfhw?q^hF;g%B>Ngy
zio;8u$*OB7`R;LZ8jGhZ+?gbNu(sYs<hh|bmbY{K;N*kL<Od%8%}u=IF69X#MV;qL
z+QUIFpOZ9=kfclQW6E9_B{Om^e5D0i-uxVg%-U+Pj$+`81*I#9GMEux<W9CsnlD1k
zn7%enEHH*A&~I37UC<en1fA}f)b*k$QY{?{{&i4%_PJsMq9n4~{0rC1CGnHUPnuuK
ziw|0M=%KfWDSpsigScFy!0PBq<YuYpAc7l;3G(_fS1<}+T`>cLxZ<bt%BXGvu)SmG
znX2o;X+a%wa9G7({6BvKi{r!*K=hl7MV_>v$G)#thMhWlfXW2Q$W_rJ(Q!NDXH0+x
zQ<!jQ;88~H34Bc(d2W+-QGOZ|#FCQ*l>3s->rPUy=JY3Vfy|$uMz(uPW}@g0hNlv$
z8ijAn!zVyZm6Y}Z3dOh3D#DU@xDFGReL@V#ku=QZMao^QT&DAIy!9<RP@~8U+%)@q
zVkwJ4LLwV=RLDq9_{*r$_FzdGgK3W-h=qmW$65GyKEm5=t>xSy^UP-`SW&!tYS7JG
zFuK6m-6-0VSp-+>X2;maXQ{4IlvcA2;7P8*nSegnv|P;nf$F9NvbhM?*;a6o)S^Gb
z(#qjN-*PB$lw~&sFU;|DeLP1Jbw(%3@f$Qif%2~O;`X-ZWzTE(*kP+j%s0<2)Gc{o
zZK-afhs+SDT!8Ina4zgiAp9*+$_7H7)cTEKJW8+e^gJKxMz$6cypGY^89fs|HazKi
z9n3p~+HR|@$_yMOa9sUnF;{1K)uoFj5JlS{O;LE*{bHusUdI3Tf@H8^QTqikAog%~
zKpdW@gb&u4i17=8{|9yEsYL~NCnUb3#Jq@Qp#7zhik~?7U0OP-<_c7yiHiuw$`g5h
z4Dk+W4~Sojj=p;}luTuL6Lg+6F>9i|YRt#X8cuo(eUrk>Z>~;aJ7ZEaCnWA`MdBc)
zf<hNND~}u*o2Xd)Iri|0H9swb`LbSWn2cDSh0gA+o%>cc&Z3TO&v%@gFl5^ijq;B^
zvz8RN(2l6Y91W9g(>MrZChD2F_&#rCv~!<f45JT6M}OHkUN^WVXTJV^{V`r3C9l0(
zr3a_1_2aelWao5ys`qZW$Sl%_pU=?0-NJS3ApDa`^LG;=z>t_Y<!og5^sFzg=y_9L
z4Q*po6iL{|iHL<GG9-zr)%V!Mm$b;e2U>mXK2dn;Sfp`KiR*b4t{fjQf3Q%`r#62E
zj5SJx>6Fh)rVp`o2&;!MR!DuBI_q1wKrBVwev-|v@UfT;AjKp)rCR(I^k*jgDeg((
zdIc?W4ny#lvCc_WrNwMjR|zJNNMLrso)T%|FFxc4pSXieYJ+Job9`0RJB;*H!b0G7
zyjcJul}ATXgRQD@Yuqc@Nx`3oT8^GKT7Y2wB1^J~i?05JS~|{5gv0O!nY8;jhq0iY
zVPoNDo!<0;UZgQ{97H7O8$7r_f}$GyC*2ad(Cb5O_SsS6e2xlbCFI@169mKacNBKf
zncO?#D0m>Z?KHU#0TyrHUQLXd?I=E6L`*<Nz{R)&V^|S@lZo6^n-eRj%x7Xwle&*T
z{OEfJad==KTsS)DNLC@yY)&opBP2c#6`1|dhksAi^QACjV`HPU^3JTXqh9CSkNrs{
zbPLk~3wrTjRiiX&jsE@#R3YeFEL7@&5r7AT7_SxXaO&}Oqo1dq8G3{QL|mVl`#1}H
z_i1Y&T}N+jC4;*6F4;S%YhEfkbFCo6Y?pEdlkbFYnuatv{P#X>jy4f<!LT_BWAOgt
zr)Xy7YV-ipR2A)=&_(wBiYbX3c_o_X$Mw*=00Y!`>(hrAVIealGr`&NqObgCPsaV$
z8;05!V_^4BID!xGSMV_+$cnGE^*&HvV`wNmYWa_4B{2+)8oakTZumHz++1AiUv>v2
z#nF>*L#C+#6)*VlrjjSHLTcbM41+%nJ9?1D{^dNxjG)t8k0`ncWIu@OM^XynqfH0G
z=WwG`Md9|NH0e)Y7u}<yL}vTGQ5YwnxeaDb))}a~gE>|NWi1mh^%BJSW&Nd4yG7L!
zA@u}#ogp?Nh4ArWVO%kyr}loh$H1|nzQ_RWz(EfYHvCCq4=quN)z(Gd%sNZ1qRFGv
z^hc><PfVFevc;BWBCr&^9Z-@SM<cY6>BnG`qrT+|>4Uw)fXDcX!5DHZN5M4o<qhsO
zLzdMCJX{+|BxW;wB<dR2XEhr6LzpT|0)C$bUW2SI;Ggp{n-1&ei=@A&E`cvWv4pck
zhq4TPj)!H9X92nL&HaXJASaNgh_Yz@h=e5Nn2Cr}+)nIA<Xd8LO(9Gne4%nzH@EMu
zp03?cENH=x=lJ178-#ic7t(VUan>Hh9*!Q7CqcvjL}A1_)JxPVR25u2+)p?i^lS|4
zjQzB!bd8Ey${wkDsmttcR2Kpl#CSw_%6N}-o^&?yFDaL)RVk|sp31*snxmUTn+rX1
zuLX`#W=*Z`t%|L_j&!B*r;5=rQZLcp$!;nKg+9Uml|yqxGeC1j^F_la5N8H5Q>wdb
z2p1WZcd5uoTc?ikYU3_oEdZ)=wYDl{Dm^PsHT{bw%L~eaR3K8cGL})_vJVJrMQa6D
zNmp~5gOA&f#-}&RAC)+jT~aqW16dJJ!<{1SBRwNC<AvhANEk^}xl(xat;Q^JfE`mx
z<7`8Yaez$Uu)kzi5=8JshHUg~v~1=2CJm|J*e3g?4q&aNu|?q2P#**2Ah9;?6iozP
z1iMqr>-+@s#0J0xpc8U*({ev?ecGPiyM}y+{LPI^Pz?Ji3a8#5efn?b(KWc-fBU|^
znzO>c4x)cqC;rQm)MvF;V?w20k|d9a4=;gCLFjI~FAkIXegCKr4lG7?rbLS=Ln@|L
z3$L)>=Fje6xLl#+7Nq=-S)MTw-AEsaotO9R?|`NzO}OzLB(ed{M5IYv+ZmE2)-yjn
z2;LdNB6l201nn}Usb78XPvsv(=a!oOv=Mt%G*z0SZdP*I7d0QUxQDKO-T~4G=ztAc
z@B5-Vu`Zg*ttfNbRp&NiZ?^jV+^<Um45H05gZ$*n6|^Cta*2GY^5zj0{cXrzuAxLr
z#+M=kVOt@iW5`D0L&;&B-r9BAbrh4CR?Zg(hfGD$P6d9^2;^zHrC;O7qCN)ZiplM*
zwVTW2rCQi%_%UyPDbHNdC8@sAwDXnz-G&vP(xd5%U3e~*-3KmDoj*G5srKYS&`aGS
z^~lnL8cC*AVcMgqBxt+2N5tgnWzY_<&*{OS?8Cv87Yl0Q44uY7`vQR?V=Yrvk`uwu
z^y5aU!(uWFo)z8f+vl?Elo8&ju5q3zHlA>p<pFxaXmrFs9<NRd+DqxyaI!lqA!eZ)
z8?~Q%uNIfzUaf3wyon8AV)62RZRXzI!=V!Wg`oS1+wr?S6J7_P#8e-@gRrG=$<!9Q
zu*@N>KthCKh^v*imA8R6#*MAthXKqK*C3<_ro+!3&|sV3VO#qfx35<~sF#wVm#wXr
zv7ndFub0-Mm+PsQd81c|xtyG^oTa>+{`$UVUrwz(!b9^**P7>RzFx_3TK;;vTtKm$
zGI}yV@QugpOa4lP@k+wRO1RicT=z;;;7ZanAOryr9S->N5fBdngwX<GO8}9UfJ7)D
z6dw>{r(}c7_!*5CkfA>g#46{`oCAdW=8fv-O$1Et7)?S0IJTuYb}cw|G&rE{b=#ln
zcJ1qS4C<hM&fBuiyFlk19cQT5*|y5ruJhTB$r&_=a{B}2t~uq7IwjPtU|XSJ*REhk
zzX0lMvMpn>Yi+WlZDI*ue}(LFN#t^cb$&^Ceg#i;iA!~bT6jrXc!gwoNoab7xphgg
zb%h{ti7#=5-h273_iFgwj`wgXy8!hHIC13FsTn2m{qdX#eajU}<UGZ`F;=@V<h0Qv
z;@dtr;#!^J7Vi7mCaI@F_FKI3sd<8_eMbourB6&~Cdum*g)JJey@P;F<#P|pt$Y2u
zv|ucA;JmeX?e$>YW!4kITQvWO?tT;Vf8g(x{~xTU8MmMO%erSx?CP6!SO0-5{u$k4
zCf4<hx+~Qu+W&&9CQjw8nroG(^IrBME%~b|mgN^F3Ee{`mh}xw%MK^}w`Bgc-HRp;
z^({-Q4yP@*2LFOvCjUEvm*dV#9*@K!R9pSE>#NV_{<R`qa@SPPa<G};|2}QV-OU7g
zQ2n1&-dYYjl6XjZDfw>_?ECrJF}4UgOzZ`I+?ZFg9Uc||hEIS~1iw|&Yk-GO)NhbQ
mX4Rts<LE1b2{c|8A^H?xWL6_ReJ}y*KfbXV2YPjIaQ_1m_8C<G

literal 0
HcmV?d00001

diff --git a/static/js/bootstrap.js b/static/js/bootstrap.js
new file mode 100644
index 0000000000..8ae571b6da
--- /dev/null
+++ b/static/js/bootstrap.js
@@ -0,0 +1,1951 @@
+/*!
+ * Bootstrap v3.1.1 (http://getbootstrap.com)
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ */
+
+if (typeof jQuery === 'undefined') { throw new Error('Bootstrap\'s JavaScript requires jQuery') }
+
+/* ========================================================================
+ * Bootstrap: transition.js v3.1.1
+ * http://getbootstrap.com/javascript/#transitions
+ * ========================================================================
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // CSS TRANSITION SUPPORT (Shoutout: http://www.modernizr.com/)
+  // ============================================================
+
+  function transitionEnd() {
+    var el = document.createElement('bootstrap')
+
+    var transEndEventNames = {
+      'WebkitTransition' : 'webkitTransitionEnd',
+      'MozTransition'    : 'transitionend',
+      'OTransition'      : 'oTransitionEnd otransitionend',
+      'transition'       : 'transitionend'
+    }
+
+    for (var name in transEndEventNames) {
+      if (el.style[name] !== undefined) {
+        return { end: transEndEventNames[name] }
+      }
+    }
+
+    return false // explicit for ie8 (  ._.)
+  }
+
+  // http://blog.alexmaccaw.com/css-transitions
+  $.fn.emulateTransitionEnd = function (duration) {
+    var called = false, $el = this
+    $(this).one($.support.transition.end, function () { called = true })
+    var callback = function () { if (!called) $($el).trigger($.support.transition.end) }
+    setTimeout(callback, duration)
+    return this
+  }
+
+  $(function () {
+    $.support.transition = transitionEnd()
+  })
+
+}(jQuery);
+
+/* ========================================================================
+ * Bootstrap: alert.js v3.1.1
+ * http://getbootstrap.com/javascript/#alerts
+ * ========================================================================
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // ALERT CLASS DEFINITION
+  // ======================
+
+  var dismiss = '[data-dismiss="alert"]'
+  var Alert   = function (el) {
+    $(el).on('click', dismiss, this.close)
+  }
+
+  Alert.prototype.close = function (e) {
+    var $this    = $(this)
+    var selector = $this.attr('data-target')
+
+    if (!selector) {
+      selector = $this.attr('href')
+      selector = selector && selector.replace(/.*(?=#[^\s]*$)/, '') // strip for ie7
+    }
+
+    var $parent = $(selector)
+
+    if (e) e.preventDefault()
+
+    if (!$parent.length) {
+      $parent = $this.hasClass('alert') ? $this : $this.parent()
+    }
+
+    $parent.trigger(e = $.Event('close.bs.alert'))
+
+    if (e.isDefaultPrevented()) return
+
+    $parent.removeClass('in')
+
+    function removeElement() {
+      $parent.trigger('closed.bs.alert').remove()
+    }
+
+    $.support.transition && $parent.hasClass('fade') ?
+      $parent
+        .one($.support.transition.end, removeElement)
+        .emulateTransitionEnd(150) :
+      removeElement()
+  }
+
+
+  // ALERT PLUGIN DEFINITION
+  // =======================
+
+  var old = $.fn.alert
+
+  $.fn.alert = function (option) {
+    return this.each(function () {
+      var $this = $(this)
+      var data  = $this.data('bs.alert')
+
+      if (!data) $this.data('bs.alert', (data = new Alert(this)))
+      if (typeof option == 'string') data[option].call($this)
+    })
+  }
+
+  $.fn.alert.Constructor = Alert
+
+
+  // ALERT NO CONFLICT
+  // =================
+
+  $.fn.alert.noConflict = function () {
+    $.fn.alert = old
+    return this
+  }
+
+
+  // ALERT DATA-API
+  // ==============
+
+  $(document).on('click.bs.alert.data-api', dismiss, Alert.prototype.close)
+
+}(jQuery);
+
+/* ========================================================================
+ * Bootstrap: button.js v3.1.1
+ * http://getbootstrap.com/javascript/#buttons
+ * ========================================================================
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // BUTTON PUBLIC CLASS DEFINITION
+  // ==============================
+
+  var Button = function (element, options) {
+    this.$element  = $(element)
+    this.options   = $.extend({}, Button.DEFAULTS, options)
+    this.isLoading = false
+  }
+
+  Button.DEFAULTS = {
+    loadingText: 'loading...'
+  }
+
+  Button.prototype.setState = function (state) {
+    var d    = 'disabled'
+    var $el  = this.$element
+    var val  = $el.is('input') ? 'val' : 'html'
+    var data = $el.data()
+
+    state = state + 'Text'
+
+    if (!data.resetText) $el.data('resetText', $el[val]())
+
+    $el[val](data[state] || this.options[state])
+
+    // push to event loop to allow forms to submit
+    setTimeout($.proxy(function () {
+      if (state == 'loadingText') {
+        this.isLoading = true
+        $el.addClass(d).attr(d, d)
+      } else if (this.isLoading) {
+        this.isLoading = false
+        $el.removeClass(d).removeAttr(d)
+      }
+    }, this), 0)
+  }
+
+  Button.prototype.toggle = function () {
+    var changed = true
+    var $parent = this.$element.closest('[data-toggle="buttons"]')
+
+    if ($parent.length) {
+      var $input = this.$element.find('input')
+      if ($input.prop('type') == 'radio') {
+        if ($input.prop('checked') && this.$element.hasClass('active')) changed = false
+        else $parent.find('.active').removeClass('active')
+      }
+      if (changed) $input.prop('checked', !this.$element.hasClass('active')).trigger('change')
+    }
+
+    if (changed) this.$element.toggleClass('active')
+  }
+
+
+  // BUTTON PLUGIN DEFINITION
+  // ========================
+
+  var old = $.fn.button
+
+  $.fn.button = function (option) {
+    return this.each(function () {
+      var $this   = $(this)
+      var data    = $this.data('bs.button')
+      var options = typeof option == 'object' && option
+
+      if (!data) $this.data('bs.button', (data = new Button(this, options)))
+
+      if (option == 'toggle') data.toggle()
+      else if (option) data.setState(option)
+    })
+  }
+
+  $.fn.button.Constructor = Button
+
+
+  // BUTTON NO CONFLICT
+  // ==================
+
+  $.fn.button.noConflict = function () {
+    $.fn.button = old
+    return this
+  }
+
+
+  // BUTTON DATA-API
+  // ===============
+
+  $(document).on('click.bs.button.data-api', '[data-toggle^=button]', function (e) {
+    var $btn = $(e.target)
+    if (!$btn.hasClass('btn')) $btn = $btn.closest('.btn')
+    $btn.button('toggle')
+    e.preventDefault()
+  })
+
+}(jQuery);
+
+/* ========================================================================
+ * Bootstrap: carousel.js v3.1.1
+ * http://getbootstrap.com/javascript/#carousel
+ * ========================================================================
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // CAROUSEL CLASS DEFINITION
+  // =========================
+
+  var Carousel = function (element, options) {
+    this.$element    = $(element)
+    this.$indicators = this.$element.find('.carousel-indicators')
+    this.options     = options
+    this.paused      =
+    this.sliding     =
+    this.interval    =
+    this.$active     =
+    this.$items      = null
+
+    this.options.pause == 'hover' && this.$element
+      .on('mouseenter', $.proxy(this.pause, this))
+      .on('mouseleave', $.proxy(this.cycle, this))
+  }
+
+  Carousel.DEFAULTS = {
+    interval: 5000,
+    pause: 'hover',
+    wrap: true
+  }
+
+  Carousel.prototype.cycle =  function (e) {
+    e || (this.paused = false)
+
+    this.interval && clearInterval(this.interval)
+
+    this.options.interval
+      && !this.paused
+      && (this.interval = setInterval($.proxy(this.next, this), this.options.interval))
+
+    return this
+  }
+
+  Carousel.prototype.getActiveIndex = function () {
+    this.$active = this.$element.find('.item.active')
+    this.$items  = this.$active.parent().children()
+
+    return this.$items.index(this.$active)
+  }
+
+  Carousel.prototype.to = function (pos) {
+    var that        = this
+    var activeIndex = this.getActiveIndex()
+
+    if (pos > (this.$items.length - 1) || pos < 0) return
+
+    if (this.sliding)       return this.$element.one('slid.bs.carousel', function () { that.to(pos) })
+    if (activeIndex == pos) return this.pause().cycle()
+
+    return this.slide(pos > activeIndex ? 'next' : 'prev', $(this.$items[pos]))
+  }
+
+  Carousel.prototype.pause = function (e) {
+    e || (this.paused = true)
+
+    if (this.$element.find('.next, .prev').length && $.support.transition) {
+      this.$element.trigger($.support.transition.end)
+      this.cycle(true)
+    }
+
+    this.interval = clearInterval(this.interval)
+
+    return this
+  }
+
+  Carousel.prototype.next = function () {
+    if (this.sliding) return
+    return this.slide('next')
+  }
+
+  Carousel.prototype.prev = function () {
+    if (this.sliding) return
+    return this.slide('prev')
+  }
+
+  Carousel.prototype.slide = function (type, next) {
+    var $active   = this.$element.find('.item.active')
+    var $next     = next || $active[type]()
+    var isCycling = this.interval
+    var direction = type == 'next' ? 'left' : 'right'
+    var fallback  = type == 'next' ? 'first' : 'last'
+    var that      = this
+
+    if (!$next.length) {
+      if (!this.options.wrap) return
+      $next = this.$element.find('.item')[fallback]()
+    }
+
+    if ($next.hasClass('active')) return this.sliding = false
+
+    var e = $.Event('slide.bs.carousel', { relatedTarget: $next[0], direction: direction })
+    this.$element.trigger(e)
+    if (e.isDefaultPrevented()) return
+
+    this.sliding = true
+
+    isCycling && this.pause()
+
+    if (this.$indicators.length) {
+      this.$indicators.find('.active').removeClass('active')
+      this.$element.one('slid.bs.carousel', function () {
+        var $nextIndicator = $(that.$indicators.children()[that.getActiveIndex()])
+        $nextIndicator && $nextIndicator.addClass('active')
+      })
+    }
+
+    if ($.support.transition && this.$element.hasClass('slide')) {
+      $next.addClass(type)
+      $next[0].offsetWidth // force reflow
+      $active.addClass(direction)
+      $next.addClass(direction)
+      $active
+        .one($.support.transition.end, function () {
+          $next.removeClass([type, direction].join(' ')).addClass('active')
+          $active.removeClass(['active', direction].join(' '))
+          that.sliding = false
+          setTimeout(function () { that.$element.trigger('slid.bs.carousel') }, 0)
+        })
+        .emulateTransitionEnd($active.css('transition-duration').slice(0, -1) * 1000)
+    } else {
+      $active.removeClass('active')
+      $next.addClass('active')
+      this.sliding = false
+      this.$element.trigger('slid.bs.carousel')
+    }
+
+    isCycling && this.cycle()
+
+    return this
+  }
+
+
+  // CAROUSEL PLUGIN DEFINITION
+  // ==========================
+
+  var old = $.fn.carousel
+
+  $.fn.carousel = function (option) {
+    return this.each(function () {
+      var $this   = $(this)
+      var data    = $this.data('bs.carousel')
+      var options = $.extend({}, Carousel.DEFAULTS, $this.data(), typeof option == 'object' && option)
+      var action  = typeof option == 'string' ? option : options.slide
+
+      if (!data) $this.data('bs.carousel', (data = new Carousel(this, options)))
+      if (typeof option == 'number') data.to(option)
+      else if (action) data[action]()
+      else if (options.interval) data.pause().cycle()
+    })
+  }
+
+  $.fn.carousel.Constructor = Carousel
+
+
+  // CAROUSEL NO CONFLICT
+  // ====================
+
+  $.fn.carousel.noConflict = function () {
+    $.fn.carousel = old
+    return this
+  }
+
+
+  // CAROUSEL DATA-API
+  // =================
+
+  $(document).on('click.bs.carousel.data-api', '[data-slide], [data-slide-to]', function (e) {
+    var $this   = $(this), href
+    var $target = $($this.attr('data-target') || (href = $this.attr('href')) && href.replace(/.*(?=#[^\s]+$)/, '')) //strip for ie7
+    var options = $.extend({}, $target.data(), $this.data())
+    var slideIndex = $this.attr('data-slide-to')
+    if (slideIndex) options.interval = false
+
+    $target.carousel(options)
+
+    if (slideIndex = $this.attr('data-slide-to')) {
+      $target.data('bs.carousel').to(slideIndex)
+    }
+
+    e.preventDefault()
+  })
+
+  $(window).on('load', function () {
+    $('[data-ride="carousel"]').each(function () {
+      var $carousel = $(this)
+      $carousel.carousel($carousel.data())
+    })
+  })
+
+}(jQuery);
+
+/* ========================================================================
+ * Bootstrap: collapse.js v3.1.1
+ * http://getbootstrap.com/javascript/#collapse
+ * ========================================================================
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // COLLAPSE PUBLIC CLASS DEFINITION
+  // ================================
+
+  var Collapse = function (element, options) {
+    this.$element      = $(element)
+    this.options       = $.extend({}, Collapse.DEFAULTS, options)
+    this.transitioning = null
+
+    if (this.options.parent) this.$parent = $(this.options.parent)
+    if (this.options.toggle) this.toggle()
+  }
+
+  Collapse.DEFAULTS = {
+    toggle: true
+  }
+
+  Collapse.prototype.dimension = function () {
+    var hasWidth = this.$element.hasClass('width')
+    return hasWidth ? 'width' : 'height'
+  }
+
+  Collapse.prototype.show = function () {
+    if (this.transitioning || this.$element.hasClass('in')) return
+
+    var startEvent = $.Event('show.bs.collapse')
+    this.$element.trigger(startEvent)
+    if (startEvent.isDefaultPrevented()) return
+
+    var actives = this.$parent && this.$parent.find('> .panel > .in')
+
+    if (actives && actives.length) {
+      var hasData = actives.data('bs.collapse')
+      if (hasData && hasData.transitioning) return
+      actives.collapse('hide')
+      hasData || actives.data('bs.collapse', null)
+    }
+
+    var dimension = this.dimension()
+
+    this.$element
+      .removeClass('collapse')
+      .addClass('collapsing')
+      [dimension](0)
+
+    this.transitioning = 1
+
+    var complete = function () {
+      this.$element
+        .removeClass('collapsing')
+        .addClass('collapse in')
+        [dimension]('auto')
+      this.transitioning = 0
+      this.$element.trigger('shown.bs.collapse')
+    }
+
+    if (!$.support.transition) return complete.call(this)
+
+    var scrollSize = $.camelCase(['scroll', dimension].join('-'))
+
+    this.$element
+      .one($.support.transition.end, $.proxy(complete, this))
+      .emulateTransitionEnd(350)
+      [dimension](this.$element[0][scrollSize])
+  }
+
+  Collapse.prototype.hide = function () {
+    if (this.transitioning || !this.$element.hasClass('in')) return
+
+    var startEvent = $.Event('hide.bs.collapse')
+    this.$element.trigger(startEvent)
+    if (startEvent.isDefaultPrevented()) return
+
+    var dimension = this.dimension()
+
+    this.$element
+      [dimension](this.$element[dimension]())
+      [0].offsetHeight
+
+    this.$element
+      .addClass('collapsing')
+      .removeClass('collapse')
+      .removeClass('in')
+
+    this.transitioning = 1
+
+    var complete = function () {
+      this.transitioning = 0
+      this.$element
+        .trigger('hidden.bs.collapse')
+        .removeClass('collapsing')
+        .addClass('collapse')
+    }
+
+    if (!$.support.transition) return complete.call(this)
+
+    this.$element
+      [dimension](0)
+      .one($.support.transition.end, $.proxy(complete, this))
+      .emulateTransitionEnd(350)
+  }
+
+  Collapse.prototype.toggle = function () {
+    this[this.$element.hasClass('in') ? 'hide' : 'show']()
+  }
+
+
+  // COLLAPSE PLUGIN DEFINITION
+  // ==========================
+
+  var old = $.fn.collapse
+
+  $.fn.collapse = function (option) {
+    return this.each(function () {
+      var $this   = $(this)
+      var data    = $this.data('bs.collapse')
+      var options = $.extend({}, Collapse.DEFAULTS, $this.data(), typeof option == 'object' && option)
+
+      if (!data && options.toggle && option == 'show') option = !option
+      if (!data) $this.data('bs.collapse', (data = new Collapse(this, options)))
+      if (typeof option == 'string') data[option]()
+    })
+  }
+
+  $.fn.collapse.Constructor = Collapse
+
+
+  // COLLAPSE NO CONFLICT
+  // ====================
+
+  $.fn.collapse.noConflict = function () {
+    $.fn.collapse = old
+    return this
+  }
+
+
+  // COLLAPSE DATA-API
+  // =================
+
+  $(document).on('click.bs.collapse.data-api', '[data-toggle=collapse]', function (e) {
+    var $this   = $(this), href
+    var target  = $this.attr('data-target')
+        || e.preventDefault()
+        || (href = $this.attr('href')) && href.replace(/.*(?=#[^\s]+$)/, '') //strip for ie7
+    var $target = $(target)
+    var data    = $target.data('bs.collapse')
+    var option  = data ? 'toggle' : $this.data()
+    var parent  = $this.attr('data-parent')
+    var $parent = parent && $(parent)
+
+    if (!data || !data.transitioning) {
+      if ($parent) $parent.find('[data-toggle=collapse][data-parent="' + parent + '"]').not($this).addClass('collapsed')
+      $this[$target.hasClass('in') ? 'addClass' : 'removeClass']('collapsed')
+    }
+
+    $target.collapse(option)
+  })
+
+}(jQuery);
+
+/* ========================================================================
+ * Bootstrap: dropdown.js v3.1.1
+ * http://getbootstrap.com/javascript/#dropdowns
+ * ========================================================================
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // DROPDOWN CLASS DEFINITION
+  // =========================
+
+  var backdrop = '.dropdown-backdrop'
+  var toggle   = '[data-toggle=dropdown]'
+  var Dropdown = function (element) {
+    $(element).on('click.bs.dropdown', this.toggle)
+  }
+
+  Dropdown.prototype.toggle = function (e) {
+    var $this = $(this)
+
+    if ($this.is('.disabled, :disabled')) return
+
+    var $parent  = getParent($this)
+    var isActive = $parent.hasClass('open')
+
+    clearMenus()
+
+    if (!isActive) {
+      if ('ontouchstart' in document.documentElement && !$parent.closest('.navbar-nav').length) {
+        // if mobile we use a backdrop because click events don't delegate
+        $('<div class="dropdown-backdrop"/>').insertAfter($(this)).on('click', clearMenus)
+      }
+
+      var relatedTarget = { relatedTarget: this }
+      $parent.trigger(e = $.Event('show.bs.dropdown', relatedTarget))
+
+      if (e.isDefaultPrevented()) return
+
+      $parent
+        .toggleClass('open')
+        .trigger('shown.bs.dropdown', relatedTarget)
+
+      $this.focus()
+    }
+
+    return false
+  }
+
+  Dropdown.prototype.keydown = function (e) {
+    if (!/(38|40|27)/.test(e.keyCode)) return
+
+    var $this = $(this)
+
+    e.preventDefault()
+    e.stopPropagation()
+
+    if ($this.is('.disabled, :disabled')) return
+
+    var $parent  = getParent($this)
+    var isActive = $parent.hasClass('open')
+
+    if (!isActive || (isActive && e.keyCode == 27)) {
+      if (e.which == 27) $parent.find(toggle).focus()
+      return $this.click()
+    }
+
+    var desc = ' li:not(.divider):visible a'
+    var $items = $parent.find('[role=menu]' + desc + ', [role=listbox]' + desc)
+
+    if (!$items.length) return
+
+    var index = $items.index($items.filter(':focus'))
+
+    if (e.keyCode == 38 && index > 0)                 index--                        // up
+    if (e.keyCode == 40 && index < $items.length - 1) index++                        // down
+    if (!~index)                                      index = 0
+
+    $items.eq(index).focus()
+  }
+
+  function clearMenus(e) {
+    $(backdrop).remove()
+    $(toggle).each(function () {
+      var $parent = getParent($(this))
+      var relatedTarget = { relatedTarget: this }
+      if (!$parent.hasClass('open')) return
+      $parent.trigger(e = $.Event('hide.bs.dropdown', relatedTarget))
+      if (e.isDefaultPrevented()) return
+      $parent.removeClass('open').trigger('hidden.bs.dropdown', relatedTarget)
+    })
+  }
+
+  function getParent($this) {
+    var selector = $this.attr('data-target')
+
+    if (!selector) {
+      selector = $this.attr('href')
+      selector = selector && /#[A-Za-z]/.test(selector) && selector.replace(/.*(?=#[^\s]*$)/, '') //strip for ie7
+    }
+
+    var $parent = selector && $(selector)
+
+    return $parent && $parent.length ? $parent : $this.parent()
+  }
+
+
+  // DROPDOWN PLUGIN DEFINITION
+  // ==========================
+
+  var old = $.fn.dropdown
+
+  $.fn.dropdown = function (option) {
+    return this.each(function () {
+      var $this = $(this)
+      var data  = $this.data('bs.dropdown')
+
+      if (!data) $this.data('bs.dropdown', (data = new Dropdown(this)))
+      if (typeof option == 'string') data[option].call($this)
+    })
+  }
+
+  $.fn.dropdown.Constructor = Dropdown
+
+
+  // DROPDOWN NO CONFLICT
+  // ====================
+
+  $.fn.dropdown.noConflict = function () {
+    $.fn.dropdown = old
+    return this
+  }
+
+
+  // APPLY TO STANDARD DROPDOWN ELEMENTS
+  // ===================================
+
+  $(document)
+    .on('click.bs.dropdown.data-api', clearMenus)
+    .on('click.bs.dropdown.data-api', '.dropdown form', function (e) { e.stopPropagation() })
+    .on('click.bs.dropdown.data-api', toggle, Dropdown.prototype.toggle)
+    .on('keydown.bs.dropdown.data-api', toggle + ', [role=menu], [role=listbox]', Dropdown.prototype.keydown)
+
+}(jQuery);
+
+/* ========================================================================
+ * Bootstrap: modal.js v3.1.1
+ * http://getbootstrap.com/javascript/#modals
+ * ========================================================================
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // MODAL CLASS DEFINITION
+  // ======================
+
+  var Modal = function (element, options) {
+    this.options   = options
+    this.$element  = $(element)
+    this.$backdrop =
+    this.isShown   = null
+
+    if (this.options.remote) {
+      this.$element
+        .find('.modal-content')
+        .load(this.options.remote, $.proxy(function () {
+          this.$element.trigger('loaded.bs.modal')
+        }, this))
+    }
+  }
+
+  Modal.DEFAULTS = {
+    backdrop: true,
+    keyboard: true,
+    show: true
+  }
+
+  Modal.prototype.toggle = function (_relatedTarget) {
+    return this[!this.isShown ? 'show' : 'hide'](_relatedTarget)
+  }
+
+  Modal.prototype.show = function (_relatedTarget) {
+    var that = this
+    var e    = $.Event('show.bs.modal', { relatedTarget: _relatedTarget })
+
+    this.$element.trigger(e)
+
+    if (this.isShown || e.isDefaultPrevented()) return
+
+    this.isShown = true
+
+    this.escape()
+
+    this.$element.on('click.dismiss.bs.modal', '[data-dismiss="modal"]', $.proxy(this.hide, this))
+
+    this.backdrop(function () {
+      var transition = $.support.transition && that.$element.hasClass('fade')
+
+      if (!that.$element.parent().length) {
+        that.$element.appendTo(document.body) // don't move modals dom position
+      }
+
+      that.$element
+        .show()
+        .scrollTop(0)
+
+      if (transition) {
+        that.$element[0].offsetWidth // force reflow
+      }
+
+      that.$element
+        .addClass('in')
+        .attr('aria-hidden', false)
+
+      that.enforceFocus()
+
+      var e = $.Event('shown.bs.modal', { relatedTarget: _relatedTarget })
+
+      transition ?
+        that.$element.find('.modal-dialog') // wait for modal to slide in
+          .one($.support.transition.end, function () {
+            that.$element.focus().trigger(e)
+          })
+          .emulateTransitionEnd(300) :
+        that.$element.focus().trigger(e)
+    })
+  }
+
+  Modal.prototype.hide = function (e) {
+    if (e) e.preventDefault()
+
+    e = $.Event('hide.bs.modal')
+
+    this.$element.trigger(e)
+
+    if (!this.isShown || e.isDefaultPrevented()) return
+
+    this.isShown = false
+
+    this.escape()
+
+    $(document).off('focusin.bs.modal')
+
+    this.$element
+      .removeClass('in')
+      .attr('aria-hidden', true)
+      .off('click.dismiss.bs.modal')
+
+    $.support.transition && this.$element.hasClass('fade') ?
+      this.$element
+        .one($.support.transition.end, $.proxy(this.hideModal, this))
+        .emulateTransitionEnd(300) :
+      this.hideModal()
+  }
+
+  Modal.prototype.enforceFocus = function () {
+    $(document)
+      .off('focusin.bs.modal') // guard against infinite focus loop
+      .on('focusin.bs.modal', $.proxy(function (e) {
+        if (this.$element[0] !== e.target && !this.$element.has(e.target).length) {
+          this.$element.focus()
+        }
+      }, this))
+  }
+
+  Modal.prototype.escape = function () {
+    if (this.isShown && this.options.keyboard) {
+      this.$element.on('keyup.dismiss.bs.modal', $.proxy(function (e) {
+        e.which == 27 && this.hide()
+      }, this))
+    } else if (!this.isShown) {
+      this.$element.off('keyup.dismiss.bs.modal')
+    }
+  }
+
+  Modal.prototype.hideModal = function () {
+    var that = this
+    this.$element.hide()
+    this.backdrop(function () {
+      that.removeBackdrop()
+      that.$element.trigger('hidden.bs.modal')
+    })
+  }
+
+  Modal.prototype.removeBackdrop = function () {
+    this.$backdrop && this.$backdrop.remove()
+    this.$backdrop = null
+  }
+
+  Modal.prototype.backdrop = function (callback) {
+    var animate = this.$element.hasClass('fade') ? 'fade' : ''
+
+    if (this.isShown && this.options.backdrop) {
+      var doAnimate = $.support.transition && animate
+
+      this.$backdrop = $('<div class="modal-backdrop ' + animate + '" />')
+        .appendTo(document.body)
+
+      this.$element.on('click.dismiss.bs.modal', $.proxy(function (e) {
+        if (e.target !== e.currentTarget) return
+        this.options.backdrop == 'static'
+          ? this.$element[0].focus.call(this.$element[0])
+          : this.hide.call(this)
+      }, this))
+
+      if (doAnimate) this.$backdrop[0].offsetWidth // force reflow
+
+      this.$backdrop.addClass('in')
+
+      if (!callback) return
+
+      doAnimate ?
+        this.$backdrop
+          .one($.support.transition.end, callback)
+          .emulateTransitionEnd(150) :
+        callback()
+
+    } else if (!this.isShown && this.$backdrop) {
+      this.$backdrop.removeClass('in')
+
+      $.support.transition && this.$element.hasClass('fade') ?
+        this.$backdrop
+          .one($.support.transition.end, callback)
+          .emulateTransitionEnd(150) :
+        callback()
+
+    } else if (callback) {
+      callback()
+    }
+  }
+
+
+  // MODAL PLUGIN DEFINITION
+  // =======================
+
+  var old = $.fn.modal
+
+  $.fn.modal = function (option, _relatedTarget) {
+    return this.each(function () {
+      var $this   = $(this)
+      var data    = $this.data('bs.modal')
+      var options = $.extend({}, Modal.DEFAULTS, $this.data(), typeof option == 'object' && option)
+
+      if (!data) $this.data('bs.modal', (data = new Modal(this, options)))
+      if (typeof option == 'string') data[option](_relatedTarget)
+      else if (options.show) data.show(_relatedTarget)
+    })
+  }
+
+  $.fn.modal.Constructor = Modal
+
+
+  // MODAL NO CONFLICT
+  // =================
+
+  $.fn.modal.noConflict = function () {
+    $.fn.modal = old
+    return this
+  }
+
+
+  // MODAL DATA-API
+  // ==============
+
+  $(document).on('click.bs.modal.data-api', '[data-toggle="modal"]', function (e) {
+    var $this   = $(this)
+    var href    = $this.attr('href')
+    var $target = $($this.attr('data-target') || (href && href.replace(/.*(?=#[^\s]+$)/, ''))) //strip for ie7
+    var option  = $target.data('bs.modal') ? 'toggle' : $.extend({ remote: !/#/.test(href) && href }, $target.data(), $this.data())
+
+    if ($this.is('a')) e.preventDefault()
+
+    $target
+      .modal(option, this)
+      .one('hide', function () {
+        $this.is(':visible') && $this.focus()
+      })
+  })
+
+  $(document)
+    .on('show.bs.modal', '.modal', function () { $(document.body).addClass('modal-open') })
+    .on('hidden.bs.modal', '.modal', function () { $(document.body).removeClass('modal-open') })
+
+}(jQuery);
+
+/* ========================================================================
+ * Bootstrap: tooltip.js v3.1.1
+ * http://getbootstrap.com/javascript/#tooltip
+ * Inspired by the original jQuery.tipsy by Jason Frame
+ * ========================================================================
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // TOOLTIP PUBLIC CLASS DEFINITION
+  // ===============================
+
+  var Tooltip = function (element, options) {
+    this.type       =
+    this.options    =
+    this.enabled    =
+    this.timeout    =
+    this.hoverState =
+    this.$element   = null
+
+    this.init('tooltip', element, options)
+  }
+
+  Tooltip.DEFAULTS = {
+    animation: true,
+    placement: 'top',
+    selector: false,
+    template: '<div class="tooltip"><div class="tooltip-arrow"></div><div class="tooltip-inner"></div></div>',
+    trigger: 'hover focus',
+    title: '',
+    delay: 0,
+    html: false,
+    container: false
+  }
+
+  Tooltip.prototype.init = function (type, element, options) {
+    this.enabled  = true
+    this.type     = type
+    this.$element = $(element)
+    this.options  = this.getOptions(options)
+
+    var triggers = this.options.trigger.split(' ')
+
+    for (var i = triggers.length; i--;) {
+      var trigger = triggers[i]
+
+      if (trigger == 'click') {
+        this.$element.on('click.' + this.type, this.options.selector, $.proxy(this.toggle, this))
+      } else if (trigger != 'manual') {
+        var eventIn  = trigger == 'hover' ? 'mouseenter' : 'focusin'
+        var eventOut = trigger == 'hover' ? 'mouseleave' : 'focusout'
+
+        this.$element.on(eventIn  + '.' + this.type, this.options.selector, $.proxy(this.enter, this))
+        this.$element.on(eventOut + '.' + this.type, this.options.selector, $.proxy(this.leave, this))
+      }
+    }
+
+    this.options.selector ?
+      (this._options = $.extend({}, this.options, { trigger: 'manual', selector: '' })) :
+      this.fixTitle()
+  }
+
+  Tooltip.prototype.getDefaults = function () {
+    return Tooltip.DEFAULTS
+  }
+
+  Tooltip.prototype.getOptions = function (options) {
+    options = $.extend({}, this.getDefaults(), this.$element.data(), options)
+
+    if (options.delay && typeof options.delay == 'number') {
+      options.delay = {
+        show: options.delay,
+        hide: options.delay
+      }
+    }
+
+    return options
+  }
+
+  Tooltip.prototype.getDelegateOptions = function () {
+    var options  = {}
+    var defaults = this.getDefaults()
+
+    this._options && $.each(this._options, function (key, value) {
+      if (defaults[key] != value) options[key] = value
+    })
+
+    return options
+  }
+
+  Tooltip.prototype.enter = function (obj) {
+    var self = obj instanceof this.constructor ?
+      obj : $(obj.currentTarget)[this.type](this.getDelegateOptions()).data('bs.' + this.type)
+
+    clearTimeout(self.timeout)
+
+    self.hoverState = 'in'
+
+    if (!self.options.delay || !self.options.delay.show) return self.show()
+
+    self.timeout = setTimeout(function () {
+      if (self.hoverState == 'in') self.show()
+    }, self.options.delay.show)
+  }
+
+  Tooltip.prototype.leave = function (obj) {
+    var self = obj instanceof this.constructor ?
+      obj : $(obj.currentTarget)[this.type](this.getDelegateOptions()).data('bs.' + this.type)
+
+    clearTimeout(self.timeout)
+
+    self.hoverState = 'out'
+
+    if (!self.options.delay || !self.options.delay.hide) return self.hide()
+
+    self.timeout = setTimeout(function () {
+      if (self.hoverState == 'out') self.hide()
+    }, self.options.delay.hide)
+  }
+
+  Tooltip.prototype.show = function () {
+    var e = $.Event('show.bs.' + this.type)
+
+    if (this.hasContent() && this.enabled) {
+      this.$element.trigger(e)
+
+      if (e.isDefaultPrevented()) return
+      var that = this;
+
+      var $tip = this.tip()
+
+      this.setContent()
+
+      if (this.options.animation) $tip.addClass('fade')
+
+      var placement = typeof this.options.placement == 'function' ?
+        this.options.placement.call(this, $tip[0], this.$element[0]) :
+        this.options.placement
+
+      var autoToken = /\s?auto?\s?/i
+      var autoPlace = autoToken.test(placement)
+      if (autoPlace) placement = placement.replace(autoToken, '') || 'top'
+
+      $tip
+        .detach()
+        .css({ top: 0, left: 0, display: 'block' })
+        .addClass(placement)
+
+      this.options.container ? $tip.appendTo(this.options.container) : $tip.insertAfter(this.$element)
+
+      var pos          = this.getPosition()
+      var actualWidth  = $tip[0].offsetWidth
+      var actualHeight = $tip[0].offsetHeight
+
+      if (autoPlace) {
+        var $parent = this.$element.parent()
+
+        var orgPlacement = placement
+        var docScroll    = document.documentElement.scrollTop || document.body.scrollTop
+        var parentWidth  = this.options.container == 'body' ? window.innerWidth  : $parent.outerWidth()
+        var parentHeight = this.options.container == 'body' ? window.innerHeight : $parent.outerHeight()
+        var parentLeft   = this.options.container == 'body' ? 0 : $parent.offset().left
+
+        placement = placement == 'bottom' && pos.top   + pos.height  + actualHeight - docScroll > parentHeight  ? 'top'    :
+                    placement == 'top'    && pos.top   - docScroll   - actualHeight < 0                         ? 'bottom' :
+                    placement == 'right'  && pos.right + actualWidth > parentWidth                              ? 'left'   :
+                    placement == 'left'   && pos.left  - actualWidth < parentLeft                               ? 'right'  :
+                    placement
+
+        $tip
+          .removeClass(orgPlacement)
+          .addClass(placement)
+      }
+
+      var calculatedOffset = this.getCalculatedOffset(placement, pos, actualWidth, actualHeight)
+
+      this.applyPlacement(calculatedOffset, placement)
+      this.hoverState = null
+
+      var complete = function() {
+        that.$element.trigger('shown.bs.' + that.type)
+      }
+
+      $.support.transition && this.$tip.hasClass('fade') ?
+        $tip
+          .one($.support.transition.end, complete)
+          .emulateTransitionEnd(150) :
+        complete()
+    }
+  }
+
+  Tooltip.prototype.applyPlacement = function (offset, placement) {
+    var replace
+    var $tip   = this.tip()
+    var width  = $tip[0].offsetWidth
+    var height = $tip[0].offsetHeight
+
+    // manually read margins because getBoundingClientRect includes difference
+    var marginTop = parseInt($tip.css('margin-top'), 10)
+    var marginLeft = parseInt($tip.css('margin-left'), 10)
+
+    // we must check for NaN for ie 8/9
+    if (isNaN(marginTop))  marginTop  = 0
+    if (isNaN(marginLeft)) marginLeft = 0
+
+    offset.top  = offset.top  + marginTop
+    offset.left = offset.left + marginLeft
+
+    // $.fn.offset doesn't round pixel values
+    // so we use setOffset directly with our own function B-0
+    $.offset.setOffset($tip[0], $.extend({
+      using: function (props) {
+        $tip.css({
+          top: Math.round(props.top),
+          left: Math.round(props.left)
+        })
+      }
+    }, offset), 0)
+
+    $tip.addClass('in')
+
+    // check to see if placing tip in new offset caused the tip to resize itself
+    var actualWidth  = $tip[0].offsetWidth
+    var actualHeight = $tip[0].offsetHeight
+
+    if (placement == 'top' && actualHeight != height) {
+      replace = true
+      offset.top = offset.top + height - actualHeight
+    }
+
+    if (/bottom|top/.test(placement)) {
+      var delta = 0
+
+      if (offset.left < 0) {
+        delta       = offset.left * -2
+        offset.left = 0
+
+        $tip.offset(offset)
+
+        actualWidth  = $tip[0].offsetWidth
+        actualHeight = $tip[0].offsetHeight
+      }
+
+      this.replaceArrow(delta - width + actualWidth, actualWidth, 'left')
+    } else {
+      this.replaceArrow(actualHeight - height, actualHeight, 'top')
+    }
+
+    if (replace) $tip.offset(offset)
+  }
+
+  Tooltip.prototype.replaceArrow = function (delta, dimension, position) {
+    this.arrow().css(position, delta ? (50 * (1 - delta / dimension) + '%') : '')
+  }
+
+  Tooltip.prototype.setContent = function () {
+    var $tip  = this.tip()
+    var title = this.getTitle()
+
+    $tip.find('.tooltip-inner')[this.options.html ? 'html' : 'text'](title)
+    $tip.removeClass('fade in top bottom left right')
+  }
+
+  Tooltip.prototype.hide = function () {
+    var that = this
+    var $tip = this.tip()
+    var e    = $.Event('hide.bs.' + this.type)
+
+    function complete() {
+      if (that.hoverState != 'in') $tip.detach()
+      that.$element.trigger('hidden.bs.' + that.type)
+    }
+
+    this.$element.trigger(e)
+
+    if (e.isDefaultPrevented()) return
+
+    $tip.removeClass('in')
+
+    $.support.transition && this.$tip.hasClass('fade') ?
+      $tip
+        .one($.support.transition.end, complete)
+        .emulateTransitionEnd(150) :
+      complete()
+
+    this.hoverState = null
+
+    return this
+  }
+
+  Tooltip.prototype.fixTitle = function () {
+    var $e = this.$element
+    if ($e.attr('title') || typeof($e.attr('data-original-title')) != 'string') {
+      $e.attr('data-original-title', $e.attr('title') || '').attr('title', '')
+    }
+  }
+
+  Tooltip.prototype.hasContent = function () {
+    return this.getTitle()
+  }
+
+  Tooltip.prototype.getPosition = function () {
+    var el = this.$element[0]
+    return $.extend({}, (typeof el.getBoundingClientRect == 'function') ? el.getBoundingClientRect() : {
+      width: el.offsetWidth,
+      height: el.offsetHeight
+    }, this.$element.offset())
+  }
+
+  Tooltip.prototype.getCalculatedOffset = function (placement, pos, actualWidth, actualHeight) {
+    return placement == 'bottom' ? { top: pos.top + pos.height,   left: pos.left + pos.width / 2 - actualWidth / 2  } :
+           placement == 'top'    ? { top: pos.top - actualHeight, left: pos.left + pos.width / 2 - actualWidth / 2  } :
+           placement == 'left'   ? { top: pos.top + pos.height / 2 - actualHeight / 2, left: pos.left - actualWidth } :
+        /* placement == 'right' */ { top: pos.top + pos.height / 2 - actualHeight / 2, left: pos.left + pos.width   }
+  }
+
+  Tooltip.prototype.getTitle = function () {
+    var title
+    var $e = this.$element
+    var o  = this.options
+
+    title = $e.attr('data-original-title')
+      || (typeof o.title == 'function' ? o.title.call($e[0]) :  o.title)
+
+    return title
+  }
+
+  Tooltip.prototype.tip = function () {
+    return this.$tip = this.$tip || $(this.options.template)
+  }
+
+  Tooltip.prototype.arrow = function () {
+    return this.$arrow = this.$arrow || this.tip().find('.tooltip-arrow')
+  }
+
+  Tooltip.prototype.validate = function () {
+    if (!this.$element[0].parentNode) {
+      this.hide()
+      this.$element = null
+      this.options  = null
+    }
+  }
+
+  Tooltip.prototype.enable = function () {
+    this.enabled = true
+  }
+
+  Tooltip.prototype.disable = function () {
+    this.enabled = false
+  }
+
+  Tooltip.prototype.toggleEnabled = function () {
+    this.enabled = !this.enabled
+  }
+
+  Tooltip.prototype.toggle = function (e) {
+    var self = e ? $(e.currentTarget)[this.type](this.getDelegateOptions()).data('bs.' + this.type) : this
+    self.tip().hasClass('in') ? self.leave(self) : self.enter(self)
+  }
+
+  Tooltip.prototype.destroy = function () {
+    clearTimeout(this.timeout)
+    this.hide().$element.off('.' + this.type).removeData('bs.' + this.type)
+  }
+
+
+  // TOOLTIP PLUGIN DEFINITION
+  // =========================
+
+  var old = $.fn.tooltip
+
+  $.fn.tooltip = function (option) {
+    return this.each(function () {
+      var $this   = $(this)
+      var data    = $this.data('bs.tooltip')
+      var options = typeof option == 'object' && option
+
+      if (!data && option == 'destroy') return
+      if (!data) $this.data('bs.tooltip', (data = new Tooltip(this, options)))
+      if (typeof option == 'string') data[option]()
+    })
+  }
+
+  $.fn.tooltip.Constructor = Tooltip
+
+
+  // TOOLTIP NO CONFLICT
+  // ===================
+
+  $.fn.tooltip.noConflict = function () {
+    $.fn.tooltip = old
+    return this
+  }
+
+}(jQuery);
+
+/* ========================================================================
+ * Bootstrap: popover.js v3.1.1
+ * http://getbootstrap.com/javascript/#popovers
+ * ========================================================================
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // POPOVER PUBLIC CLASS DEFINITION
+  // ===============================
+
+  var Popover = function (element, options) {
+    this.init('popover', element, options)
+  }
+
+  if (!$.fn.tooltip) throw new Error('Popover requires tooltip.js')
+
+  Popover.DEFAULTS = $.extend({}, $.fn.tooltip.Constructor.DEFAULTS, {
+    placement: 'right',
+    trigger: 'click',
+    content: '',
+    template: '<div class="popover"><div class="arrow"></div><h3 class="popover-title"></h3><div class="popover-content"></div></div>'
+  })
+
+
+  // NOTE: POPOVER EXTENDS tooltip.js
+  // ================================
+
+  Popover.prototype = $.extend({}, $.fn.tooltip.Constructor.prototype)
+
+  Popover.prototype.constructor = Popover
+
+  Popover.prototype.getDefaults = function () {
+    return Popover.DEFAULTS
+  }
+
+  Popover.prototype.setContent = function () {
+    var $tip    = this.tip()
+    var title   = this.getTitle()
+    var content = this.getContent()
+
+    $tip.find('.popover-title')[this.options.html ? 'html' : 'text'](title)
+    $tip.find('.popover-content')[ // we use append for html objects to maintain js events
+      this.options.html ? (typeof content == 'string' ? 'html' : 'append') : 'text'
+    ](content)
+
+    $tip.removeClass('fade top bottom left right in')
+
+    // IE8 doesn't accept hiding via the `:empty` pseudo selector, we have to do
+    // this manually by checking the contents.
+    if (!$tip.find('.popover-title').html()) $tip.find('.popover-title').hide()
+  }
+
+  Popover.prototype.hasContent = function () {
+    return this.getTitle() || this.getContent()
+  }
+
+  Popover.prototype.getContent = function () {
+    var $e = this.$element
+    var o  = this.options
+
+    return $e.attr('data-content')
+      || (typeof o.content == 'function' ?
+            o.content.call($e[0]) :
+            o.content)
+  }
+
+  Popover.prototype.arrow = function () {
+    return this.$arrow = this.$arrow || this.tip().find('.arrow')
+  }
+
+  Popover.prototype.tip = function () {
+    if (!this.$tip) this.$tip = $(this.options.template)
+    return this.$tip
+  }
+
+
+  // POPOVER PLUGIN DEFINITION
+  // =========================
+
+  var old = $.fn.popover
+
+  $.fn.popover = function (option) {
+    return this.each(function () {
+      var $this   = $(this)
+      var data    = $this.data('bs.popover')
+      var options = typeof option == 'object' && option
+
+      if (!data && option == 'destroy') return
+      if (!data) $this.data('bs.popover', (data = new Popover(this, options)))
+      if (typeof option == 'string') data[option]()
+    })
+  }
+
+  $.fn.popover.Constructor = Popover
+
+
+  // POPOVER NO CONFLICT
+  // ===================
+
+  $.fn.popover.noConflict = function () {
+    $.fn.popover = old
+    return this
+  }
+
+}(jQuery);
+
+/* ========================================================================
+ * Bootstrap: scrollspy.js v3.1.1
+ * http://getbootstrap.com/javascript/#scrollspy
+ * ========================================================================
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // SCROLLSPY CLASS DEFINITION
+  // ==========================
+
+  function ScrollSpy(element, options) {
+    var href
+    var process  = $.proxy(this.process, this)
+
+    this.$element       = $(element).is('body') ? $(window) : $(element)
+    this.$body          = $('body')
+    this.$scrollElement = this.$element.on('scroll.bs.scroll-spy.data-api', process)
+    this.options        = $.extend({}, ScrollSpy.DEFAULTS, options)
+    this.selector       = (this.options.target
+      || ((href = $(element).attr('href')) && href.replace(/.*(?=#[^\s]+$)/, '')) //strip for ie7
+      || '') + ' .nav li > a'
+    this.offsets        = $([])
+    this.targets        = $([])
+    this.activeTarget   = null
+
+    this.refresh()
+    this.process()
+  }
+
+  ScrollSpy.DEFAULTS = {
+    offset: 10
+  }
+
+  ScrollSpy.prototype.refresh = function () {
+    var offsetMethod = this.$element[0] == window ? 'offset' : 'position'
+
+    this.offsets = $([])
+    this.targets = $([])
+
+    var self     = this
+    var $targets = this.$body
+      .find(this.selector)
+      .map(function () {
+        var $el   = $(this)
+        var href  = $el.data('target') || $el.attr('href')
+        var $href = /^#./.test(href) && $(href)
+
+        return ($href
+          && $href.length
+          && $href.is(':visible')
+          && [[ $href[offsetMethod]().top + (!$.isWindow(self.$scrollElement.get(0)) && self.$scrollElement.scrollTop()), href ]]) || null
+      })
+      .sort(function (a, b) { return a[0] - b[0] })
+      .each(function () {
+        self.offsets.push(this[0])
+        self.targets.push(this[1])
+      })
+  }
+
+  ScrollSpy.prototype.process = function () {
+    var scrollTop    = this.$scrollElement.scrollTop() + this.options.offset
+    var scrollHeight = this.$scrollElement[0].scrollHeight || this.$body[0].scrollHeight
+    var maxScroll    = scrollHeight - this.$scrollElement.height()
+    var offsets      = this.offsets
+    var targets      = this.targets
+    var activeTarget = this.activeTarget
+    var i
+
+    if (scrollTop >= maxScroll) {
+      return activeTarget != (i = targets.last()[0]) && this.activate(i)
+    }
+
+    if (activeTarget && scrollTop <= offsets[0]) {
+      return activeTarget != (i = targets[0]) && this.activate(i)
+    }
+
+    for (i = offsets.length; i--;) {
+      activeTarget != targets[i]
+        && scrollTop >= offsets[i]
+        && (!offsets[i + 1] || scrollTop <= offsets[i + 1])
+        && this.activate( targets[i] )
+    }
+  }
+
+  ScrollSpy.prototype.activate = function (target) {
+    this.activeTarget = target
+
+    $(this.selector)
+      .parentsUntil(this.options.target, '.active')
+      .removeClass('active')
+
+    var selector = this.selector +
+        '[data-target="' + target + '"],' +
+        this.selector + '[href="' + target + '"]'
+
+    var active = $(selector)
+      .parents('li')
+      .addClass('active')
+
+    if (active.parent('.dropdown-menu').length) {
+      active = active
+        .closest('li.dropdown')
+        .addClass('active')
+    }
+
+    active.trigger('activate.bs.scrollspy')
+  }
+
+
+  // SCROLLSPY PLUGIN DEFINITION
+  // ===========================
+
+  var old = $.fn.scrollspy
+
+  $.fn.scrollspy = function (option) {
+    return this.each(function () {
+      var $this   = $(this)
+      var data    = $this.data('bs.scrollspy')
+      var options = typeof option == 'object' && option
+
+      if (!data) $this.data('bs.scrollspy', (data = new ScrollSpy(this, options)))
+      if (typeof option == 'string') data[option]()
+    })
+  }
+
+  $.fn.scrollspy.Constructor = ScrollSpy
+
+
+  // SCROLLSPY NO CONFLICT
+  // =====================
+
+  $.fn.scrollspy.noConflict = function () {
+    $.fn.scrollspy = old
+    return this
+  }
+
+
+  // SCROLLSPY DATA-API
+  // ==================
+
+  $(window).on('load', function () {
+    $('[data-spy="scroll"]').each(function () {
+      var $spy = $(this)
+      $spy.scrollspy($spy.data())
+    })
+  })
+
+}(jQuery);
+
+/* ========================================================================
+ * Bootstrap: tab.js v3.1.1
+ * http://getbootstrap.com/javascript/#tabs
+ * ========================================================================
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // TAB CLASS DEFINITION
+  // ====================
+
+  var Tab = function (element) {
+    this.element = $(element)
+  }
+
+  Tab.prototype.show = function () {
+    var $this    = this.element
+    var $ul      = $this.closest('ul:not(.dropdown-menu)')
+    var selector = $this.data('target')
+
+    if (!selector) {
+      selector = $this.attr('href')
+      selector = selector && selector.replace(/.*(?=#[^\s]*$)/, '') //strip for ie7
+    }
+
+    if ($this.parent('li').hasClass('active')) return
+
+    var previous = $ul.find('.active:last a')[0]
+    var e        = $.Event('show.bs.tab', {
+      relatedTarget: previous
+    })
+
+    $this.trigger(e)
+
+    if (e.isDefaultPrevented()) return
+
+    var $target = $(selector)
+
+    this.activate($this.parent('li'), $ul)
+    this.activate($target, $target.parent(), function () {
+      $this.trigger({
+        type: 'shown.bs.tab',
+        relatedTarget: previous
+      })
+    })
+  }
+
+  Tab.prototype.activate = function (element, container, callback) {
+    var $active    = container.find('> .active')
+    var transition = callback
+      && $.support.transition
+      && $active.hasClass('fade')
+
+    function next() {
+      $active
+        .removeClass('active')
+        .find('> .dropdown-menu > .active')
+        .removeClass('active')
+
+      element.addClass('active')
+
+      if (transition) {
+        element[0].offsetWidth // reflow for transition
+        element.addClass('in')
+      } else {
+        element.removeClass('fade')
+      }
+
+      if (element.parent('.dropdown-menu')) {
+        element.closest('li.dropdown').addClass('active')
+      }
+
+      callback && callback()
+    }
+
+    transition ?
+      $active
+        .one($.support.transition.end, next)
+        .emulateTransitionEnd(150) :
+      next()
+
+    $active.removeClass('in')
+  }
+
+
+  // TAB PLUGIN DEFINITION
+  // =====================
+
+  var old = $.fn.tab
+
+  $.fn.tab = function ( option ) {
+    return this.each(function () {
+      var $this = $(this)
+      var data  = $this.data('bs.tab')
+
+      if (!data) $this.data('bs.tab', (data = new Tab(this)))
+      if (typeof option == 'string') data[option]()
+    })
+  }
+
+  $.fn.tab.Constructor = Tab
+
+
+  // TAB NO CONFLICT
+  // ===============
+
+  $.fn.tab.noConflict = function () {
+    $.fn.tab = old
+    return this
+  }
+
+
+  // TAB DATA-API
+  // ============
+
+  $(document).on('click.bs.tab.data-api', '[data-toggle="tab"], [data-toggle="pill"]', function (e) {
+    e.preventDefault()
+    $(this).tab('show')
+  })
+
+}(jQuery);
+
+/* ========================================================================
+ * Bootstrap: affix.js v3.1.1
+ * http://getbootstrap.com/javascript/#affix
+ * ========================================================================
+ * Copyright 2011-2014 Twitter, Inc.
+ * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE)
+ * ======================================================================== */
+
+
++function ($) {
+  'use strict';
+
+  // AFFIX CLASS DEFINITION
+  // ======================
+
+  var Affix = function (element, options) {
+    this.options = $.extend({}, Affix.DEFAULTS, options)
+    this.$window = $(window)
+      .on('scroll.bs.affix.data-api', $.proxy(this.checkPosition, this))
+      .on('click.bs.affix.data-api',  $.proxy(this.checkPositionWithEventLoop, this))
+
+    this.$element     = $(element)
+    this.affixed      =
+    this.unpin        =
+    this.pinnedOffset = null
+
+    this.checkPosition()
+  }
+
+  Affix.RESET = 'affix affix-top affix-bottom'
+
+  Affix.DEFAULTS = {
+    offset: 0
+  }
+
+  Affix.prototype.getPinnedOffset = function () {
+    if (this.pinnedOffset) return this.pinnedOffset
+    this.$element.removeClass(Affix.RESET).addClass('affix')
+    var scrollTop = this.$window.scrollTop()
+    var position  = this.$element.offset()
+    return (this.pinnedOffset = position.top - scrollTop)
+  }
+
+  Affix.prototype.checkPositionWithEventLoop = function () {
+    setTimeout($.proxy(this.checkPosition, this), 1)
+  }
+
+  Affix.prototype.checkPosition = function () {
+    if (!this.$element.is(':visible')) return
+
+    var scrollHeight = $(document).height()
+    var scrollTop    = this.$window.scrollTop()
+    var position     = this.$element.offset()
+    var offset       = this.options.offset
+    var offsetTop    = offset.top
+    var offsetBottom = offset.bottom
+
+    if (this.affixed == 'top') position.top += scrollTop
+
+    if (typeof offset != 'object')         offsetBottom = offsetTop = offset
+    if (typeof offsetTop == 'function')    offsetTop    = offset.top(this.$element)
+    if (typeof offsetBottom == 'function') offsetBottom = offset.bottom(this.$element)
+
+    var affix = this.unpin   != null && (scrollTop + this.unpin <= position.top) ? false :
+                offsetBottom != null && (position.top + this.$element.height() >= scrollHeight - offsetBottom) ? 'bottom' :
+                offsetTop    != null && (scrollTop <= offsetTop) ? 'top' : false
+
+    if (this.affixed === affix) return
+    if (this.unpin) this.$element.css('top', '')
+
+    var affixType = 'affix' + (affix ? '-' + affix : '')
+    var e         = $.Event(affixType + '.bs.affix')
+
+    this.$element.trigger(e)
+
+    if (e.isDefaultPrevented()) return
+
+    this.affixed = affix
+    this.unpin = affix == 'bottom' ? this.getPinnedOffset() : null
+
+    this.$element
+      .removeClass(Affix.RESET)
+      .addClass(affixType)
+      .trigger($.Event(affixType.replace('affix', 'affixed')))
+
+    if (affix == 'bottom') {
+      this.$element.offset({ top: scrollHeight - offsetBottom - this.$element.height() })
+    }
+  }
+
+
+  // AFFIX PLUGIN DEFINITION
+  // =======================
+
+  var old = $.fn.affix
+
+  $.fn.affix = function (option) {
+    return this.each(function () {
+      var $this   = $(this)
+      var data    = $this.data('bs.affix')
+      var options = typeof option == 'object' && option
+
+      if (!data) $this.data('bs.affix', (data = new Affix(this, options)))
+      if (typeof option == 'string') data[option]()
+    })
+  }
+
+  $.fn.affix.Constructor = Affix
+
+
+  // AFFIX NO CONFLICT
+  // =================
+
+  $.fn.affix.noConflict = function () {
+    $.fn.affix = old
+    return this
+  }
+
+
+  // AFFIX DATA-API
+  // ==============
+
+  $(window).on('load', function () {
+    $('[data-spy="affix"]').each(function () {
+      var $spy = $(this)
+      var data = $spy.data()
+
+      data.offset = data.offset || {}
+
+      if (data.offsetBottom) data.offset.bottom = data.offsetBottom
+      if (data.offsetTop)    data.offset.top    = data.offsetTop
+
+      $spy.affix(data)
+    })
+  })
+
+}(jQuery);
diff --git a/static/js/jquery.full.js b/static/js/jquery.full.js
new file mode 100644
index 0000000000..f7f422773d
--- /dev/null
+++ b/static/js/jquery.full.js
@@ -0,0 +1,9111 @@
+/*!
+ * jQuery JavaScript Library v2.1.0
+ * http://jquery.com/
+ *
+ * Includes Sizzle.js
+ * http://sizzlejs.com/
+ *
+ * Copyright 2005, 2014 jQuery Foundation, Inc. and other contributors
+ * Released under the MIT license
+ * http://jquery.org/license
+ *
+ * Date: 2014-01-23T21:10Z
+ */
+
+(function( global, factory ) {
+
+	if ( typeof module === "object" && typeof module.exports === "object" ) {
+		// For CommonJS and CommonJS-like environments where a proper window is present,
+		// execute the factory and get jQuery
+		// For environments that do not inherently posses a window with a document
+		// (such as Node.js), expose a jQuery-making factory as module.exports
+		// This accentuates the need for the creation of a real window
+		// e.g. var jQuery = require("jquery")(window);
+		// See ticket #14549 for more info
+		module.exports = global.document ?
+			factory( global, true ) :
+			function( w ) {
+				if ( !w.document ) {
+					throw new Error( "jQuery requires a window with a document" );
+				}
+				return factory( w );
+			};
+	} else {
+		factory( global );
+	}
+
+// Pass this if window is not defined yet
+}(typeof window !== "undefined" ? window : this, function( window, noGlobal ) {
+
+// Can't do this because several apps including ASP.NET trace
+// the stack via arguments.caller.callee and Firefox dies if
+// you try to trace through "use strict" call chains. (#13335)
+// Support: Firefox 18+
+//
+
+var arr = [];
+
+var slice = arr.slice;
+
+var concat = arr.concat;
+
+var push = arr.push;
+
+var indexOf = arr.indexOf;
+
+var class2type = {};
+
+var toString = class2type.toString;
+
+var hasOwn = class2type.hasOwnProperty;
+
+var trim = "".trim;
+
+var support = {};
+
+
+
+var
+	// Use the correct document accordingly with window argument (sandbox)
+	document = window.document,
+
+	version = "2.1.0",
+
+	// Define a local copy of jQuery
+	jQuery = function( selector, context ) {
+		// The jQuery object is actually just the init constructor 'enhanced'
+		// Need init if jQuery is called (just allow error to be thrown if not included)
+		return new jQuery.fn.init( selector, context );
+	},
+
+	// Matches dashed string for camelizing
+	rmsPrefix = /^-ms-/,
+	rdashAlpha = /-([\da-z])/gi,
+
+	// Used by jQuery.camelCase as callback to replace()
+	fcamelCase = function( all, letter ) {
+		return letter.toUpperCase();
+	};
+
+jQuery.fn = jQuery.prototype = {
+	// The current version of jQuery being used
+	jquery: version,
+
+	constructor: jQuery,
+
+	// Start with an empty selector
+	selector: "",
+
+	// The default length of a jQuery object is 0
+	length: 0,
+
+	toArray: function() {
+		return slice.call( this );
+	},
+
+	// Get the Nth element in the matched element set OR
+	// Get the whole matched element set as a clean array
+	get: function( num ) {
+		return num != null ?
+
+			// Return a 'clean' array
+			( num < 0 ? this[ num + this.length ] : this[ num ] ) :
+
+			// Return just the object
+			slice.call( this );
+	},
+
+	// Take an array of elements and push it onto the stack
+	// (returning the new matched element set)
+	pushStack: function( elems ) {
+
+		// Build a new jQuery matched element set
+		var ret = jQuery.merge( this.constructor(), elems );
+
+		// Add the old object onto the stack (as a reference)
+		ret.prevObject = this;
+		ret.context = this.context;
+
+		// Return the newly-formed element set
+		return ret;
+	},
+
+	// Execute a callback for every element in the matched set.
+	// (You can seed the arguments with an array of args, but this is
+	// only used internally.)
+	each: function( callback, args ) {
+		return jQuery.each( this, callback, args );
+	},
+
+	map: function( callback ) {
+		return this.pushStack( jQuery.map(this, function( elem, i ) {
+			return callback.call( elem, i, elem );
+		}));
+	},
+
+	slice: function() {
+		return this.pushStack( slice.apply( this, arguments ) );
+	},
+
+	first: function() {
+		return this.eq( 0 );
+	},
+
+	last: function() {
+		return this.eq( -1 );
+	},
+
+	eq: function( i ) {
+		var len = this.length,
+			j = +i + ( i < 0 ? len : 0 );
+		return this.pushStack( j >= 0 && j < len ? [ this[j] ] : [] );
+	},
+
+	end: function() {
+		return this.prevObject || this.constructor(null);
+	},
+
+	// For internal use only.
+	// Behaves like an Array's method, not like a jQuery method.
+	push: push,
+	sort: arr.sort,
+	splice: arr.splice
+};
+
+jQuery.extend = jQuery.fn.extend = function() {
+	var options, name, src, copy, copyIsArray, clone,
+		target = arguments[0] || {},
+		i = 1,
+		length = arguments.length,
+		deep = false;
+
+	// Handle a deep copy situation
+	if ( typeof target === "boolean" ) {
+		deep = target;
+
+		// skip the boolean and the target
+		target = arguments[ i ] || {};
+		i++;
+	}
+
+	// Handle case when target is a string or something (possible in deep copy)
+	if ( typeof target !== "object" && !jQuery.isFunction(target) ) {
+		target = {};
+	}
+
+	// extend jQuery itself if only one argument is passed
+	if ( i === length ) {
+		target = this;
+		i--;
+	}
+
+	for ( ; i < length; i++ ) {
+		// Only deal with non-null/undefined values
+		if ( (options = arguments[ i ]) != null ) {
+			// Extend the base object
+			for ( name in options ) {
+				src = target[ name ];
+				copy = options[ name ];
+
+				// Prevent never-ending loop
+				if ( target === copy ) {
+					continue;
+				}
+
+				// Recurse if we're merging plain objects or arrays
+				if ( deep && copy && ( jQuery.isPlainObject(copy) || (copyIsArray = jQuery.isArray(copy)) ) ) {
+					if ( copyIsArray ) {
+						copyIsArray = false;
+						clone = src && jQuery.isArray(src) ? src : [];
+
+					} else {
+						clone = src && jQuery.isPlainObject(src) ? src : {};
+					}
+
+					// Never move original objects, clone them
+					target[ name ] = jQuery.extend( deep, clone, copy );
+
+				// Don't bring in undefined values
+				} else if ( copy !== undefined ) {
+					target[ name ] = copy;
+				}
+			}
+		}
+	}
+
+	// Return the modified object
+	return target;
+};
+
+jQuery.extend({
+	// Unique for each copy of jQuery on the page
+	expando: "jQuery" + ( version + Math.random() ).replace( /\D/g, "" ),
+
+	// Assume jQuery is ready without the ready module
+	isReady: true,
+
+	error: function( msg ) {
+		throw new Error( msg );
+	},
+
+	noop: function() {},
+
+	// See test/unit/core.js for details concerning isFunction.
+	// Since version 1.3, DOM methods and functions like alert
+	// aren't supported. They return false on IE (#2968).
+	isFunction: function( obj ) {
+		return jQuery.type(obj) === "function";
+	},
+
+	isArray: Array.isArray,
+
+	isWindow: function( obj ) {
+		return obj != null && obj === obj.window;
+	},
+
+	isNumeric: function( obj ) {
+		// parseFloat NaNs numeric-cast false positives (null|true|false|"")
+		// ...but misinterprets leading-number strings, particularly hex literals ("0x...")
+		// subtraction forces infinities to NaN
+		return obj - parseFloat( obj ) >= 0;
+	},
+
+	isPlainObject: function( obj ) {
+		// Not plain objects:
+		// - Any object or value whose internal [[Class]] property is not "[object Object]"
+		// - DOM nodes
+		// - window
+		if ( jQuery.type( obj ) !== "object" || obj.nodeType || jQuery.isWindow( obj ) ) {
+			return false;
+		}
+
+		// Support: Firefox <20
+		// The try/catch suppresses exceptions thrown when attempting to access
+		// the "constructor" property of certain host objects, ie. |window.location|
+		// https://bugzilla.mozilla.org/show_bug.cgi?id=814622
+		try {
+			if ( obj.constructor &&
+					!hasOwn.call( obj.constructor.prototype, "isPrototypeOf" ) ) {
+				return false;
+			}
+		} catch ( e ) {
+			return false;
+		}
+
+		// If the function hasn't returned already, we're confident that
+		// |obj| is a plain object, created by {} or constructed with new Object
+		return true;
+	},
+
+	isEmptyObject: function( obj ) {
+		var name;
+		for ( name in obj ) {
+			return false;
+		}
+		return true;
+	},
+
+	type: function( obj ) {
+		if ( obj == null ) {
+			return obj + "";
+		}
+		// Support: Android < 4.0, iOS < 6 (functionish RegExp)
+		return typeof obj === "object" || typeof obj === "function" ?
+			class2type[ toString.call(obj) ] || "object" :
+			typeof obj;
+	},
+
+	// Evaluates a script in a global context
+	globalEval: function( code ) {
+		var script,
+			indirect = eval;
+
+		code = jQuery.trim( code );
+
+		if ( code ) {
+			// If the code includes a valid, prologue position
+			// strict mode pragma, execute code by injecting a
+			// script tag into the document.
+			if ( code.indexOf("use strict") === 1 ) {
+				script = document.createElement("script");
+				script.text = code;
+				document.head.appendChild( script ).parentNode.removeChild( script );
+			} else {
+			// Otherwise, avoid the DOM node creation, insertion
+			// and removal by using an indirect global eval
+				indirect( code );
+			}
+		}
+	},
+
+	// Convert dashed to camelCase; used by the css and data modules
+	// Microsoft forgot to hump their vendor prefix (#9572)
+	camelCase: function( string ) {
+		return string.replace( rmsPrefix, "ms-" ).replace( rdashAlpha, fcamelCase );
+	},
+
+	nodeName: function( elem, name ) {
+		return elem.nodeName && elem.nodeName.toLowerCase() === name.toLowerCase();
+	},
+
+	// args is for internal usage only
+	each: function( obj, callback, args ) {
+		var value,
+			i = 0,
+			length = obj.length,
+			isArray = isArraylike( obj );
+
+		if ( args ) {
+			if ( isArray ) {
+				for ( ; i < length; i++ ) {
+					value = callback.apply( obj[ i ], args );
+
+					if ( value === false ) {
+						break;
+					}
+				}
+			} else {
+				for ( i in obj ) {
+					value = callback.apply( obj[ i ], args );
+
+					if ( value === false ) {
+						break;
+					}
+				}
+			}
+
+		// A special, fast, case for the most common use of each
+		} else {
+			if ( isArray ) {
+				for ( ; i < length; i++ ) {
+					value = callback.call( obj[ i ], i, obj[ i ] );
+
+					if ( value === false ) {
+						break;
+					}
+				}
+			} else {
+				for ( i in obj ) {
+					value = callback.call( obj[ i ], i, obj[ i ] );
+
+					if ( value === false ) {
+						break;
+					}
+				}
+			}
+		}
+
+		return obj;
+	},
+
+	trim: function( text ) {
+		return text == null ? "" : trim.call( text );
+	},
+
+	// results is for internal usage only
+	makeArray: function( arr, results ) {
+		var ret = results || [];
+
+		if ( arr != null ) {
+			if ( isArraylike( Object(arr) ) ) {
+				jQuery.merge( ret,
+					typeof arr === "string" ?
+					[ arr ] : arr
+				);
+			} else {
+				push.call( ret, arr );
+			}
+		}
+
+		return ret;
+	},
+
+	inArray: function( elem, arr, i ) {
+		return arr == null ? -1 : indexOf.call( arr, elem, i );
+	},
+
+	merge: function( first, second ) {
+		var len = +second.length,
+			j = 0,
+			i = first.length;
+
+		for ( ; j < len; j++ ) {
+			first[ i++ ] = second[ j ];
+		}
+
+		first.length = i;
+
+		return first;
+	},
+
+	grep: function( elems, callback, invert ) {
+		var callbackInverse,
+			matches = [],
+			i = 0,
+			length = elems.length,
+			callbackExpect = !invert;
+
+		// Go through the array, only saving the items
+		// that pass the validator function
+		for ( ; i < length; i++ ) {
+			callbackInverse = !callback( elems[ i ], i );
+			if ( callbackInverse !== callbackExpect ) {
+				matches.push( elems[ i ] );
+			}
+		}
+
+		return matches;
+	},
+
+	// arg is for internal usage only
+	map: function( elems, callback, arg ) {
+		var value,
+			i = 0,
+			length = elems.length,
+			isArray = isArraylike( elems ),
+			ret = [];
+
+		// Go through the array, translating each of the items to their new values
+		if ( isArray ) {
+			for ( ; i < length; i++ ) {
+				value = callback( elems[ i ], i, arg );
+
+				if ( value != null ) {
+					ret.push( value );
+				}
+			}
+
+		// Go through every key on the object,
+		} else {
+			for ( i in elems ) {
+				value = callback( elems[ i ], i, arg );
+
+				if ( value != null ) {
+					ret.push( value );
+				}
+			}
+		}
+
+		// Flatten any nested arrays
+		return concat.apply( [], ret );
+	},
+
+	// A global GUID counter for objects
+	guid: 1,
+
+	// Bind a function to a context, optionally partially applying any
+	// arguments.
+	proxy: function( fn, context ) {
+		var tmp, args, proxy;
+
+		if ( typeof context === "string" ) {
+			tmp = fn[ context ];
+			context = fn;
+			fn = tmp;
+		}
+
+		// Quick check to determine if target is callable, in the spec
+		// this throws a TypeError, but we will just return undefined.
+		if ( !jQuery.isFunction( fn ) ) {
+			return undefined;
+		}
+
+		// Simulated bind
+		args = slice.call( arguments, 2 );
+		proxy = function() {
+			return fn.apply( context || this, args.concat( slice.call( arguments ) ) );
+		};
+
+		// Set the guid of unique handler to the same of original handler, so it can be removed
+		proxy.guid = fn.guid = fn.guid || jQuery.guid++;
+
+		return proxy;
+	},
+
+	now: Date.now,
+
+	// jQuery.support is not used in Core but other projects attach their
+	// properties to it so it needs to exist.
+	support: support
+});
+
+// Populate the class2type map
+jQuery.each("Boolean Number String Function Array Date RegExp Object Error".split(" "), function(i, name) {
+	class2type[ "[object " + name + "]" ] = name.toLowerCase();
+});
+
+function isArraylike( obj ) {
+	var length = obj.length,
+		type = jQuery.type( obj );
+
+	if ( type === "function" || jQuery.isWindow( obj ) ) {
+		return false;
+	}
+
+	if ( obj.nodeType === 1 && length ) {
+		return true;
+	}
+
+	return type === "array" || length === 0 ||
+		typeof length === "number" && length > 0 && ( length - 1 ) in obj;
+}
+var Sizzle =
+/*!
+ * Sizzle CSS Selector Engine v1.10.16
+ * http://sizzlejs.com/
+ *
+ * Copyright 2013 jQuery Foundation, Inc. and other contributors
+ * Released under the MIT license
+ * http://jquery.org/license
+ *
+ * Date: 2014-01-13
+ */
+(function( window ) {
+
+var i,
+	support,
+	Expr,
+	getText,
+	isXML,
+	compile,
+	outermostContext,
+	sortInput,
+	hasDuplicate,
+
+	// Local document vars
+	setDocument,
+	document,
+	docElem,
+	documentIsHTML,
+	rbuggyQSA,
+	rbuggyMatches,
+	matches,
+	contains,
+
+	// Instance-specific data
+	expando = "sizzle" + -(new Date()),
+	preferredDoc = window.document,
+	dirruns = 0,
+	done = 0,
+	classCache = createCache(),
+	tokenCache = createCache(),
+	compilerCache = createCache(),
+	sortOrder = function( a, b ) {
+		if ( a === b ) {
+			hasDuplicate = true;
+		}
+		return 0;
+	},
+
+	// General-purpose constants
+	strundefined = typeof undefined,
+	MAX_NEGATIVE = 1 << 31,
+
+	// Instance methods
+	hasOwn = ({}).hasOwnProperty,
+	arr = [],
+	pop = arr.pop,
+	push_native = arr.push,
+	push = arr.push,
+	slice = arr.slice,
+	// Use a stripped-down indexOf if we can't use a native one
+	indexOf = arr.indexOf || function( elem ) {
+		var i = 0,
+			len = this.length;
+		for ( ; i < len; i++ ) {
+			if ( this[i] === elem ) {
+				return i;
+			}
+		}
+		return -1;
+	},
+
+	booleans = "checked|selected|async|autofocus|autoplay|controls|defer|disabled|hidden|ismap|loop|multiple|open|readonly|required|scoped",
+
+	// Regular expressions
+
+	// Whitespace characters http://www.w3.org/TR/css3-selectors/#whitespace
+	whitespace = "[\\x20\\t\\r\\n\\f]",
+	// http://www.w3.org/TR/css3-syntax/#characters
+	characterEncoding = "(?:\\\\.|[\\w-]|[^\\x00-\\xa0])+",
+
+	// Loosely modeled on CSS identifier characters
+	// An unquoted value should be a CSS identifier http://www.w3.org/TR/css3-selectors/#attribute-selectors
+	// Proper syntax: http://www.w3.org/TR/CSS21/syndata.html#value-def-identifier
+	identifier = characterEncoding.replace( "w", "w#" ),
+
+	// Acceptable operators http://www.w3.org/TR/selectors/#attribute-selectors
+	attributes = "\\[" + whitespace + "*(" + characterEncoding + ")" + whitespace +
+		"*(?:([*^$|!~]?=)" + whitespace + "*(?:(['\"])((?:\\\\.|[^\\\\])*?)\\3|(" + identifier + ")|)|)" + whitespace + "*\\]",
+
+	// Prefer arguments quoted,
+	//   then not containing pseudos/brackets,
+	//   then attribute selectors/non-parenthetical expressions,
+	//   then anything else
+	// These preferences are here to reduce the number of selectors
+	//   needing tokenize in the PSEUDO preFilter
+	pseudos = ":(" + characterEncoding + ")(?:\\(((['\"])((?:\\\\.|[^\\\\])*?)\\3|((?:\\\\.|[^\\\\()[\\]]|" + attributes.replace( 3, 8 ) + ")*)|.*)\\)|)",
+
+	// Leading and non-escaped trailing whitespace, capturing some non-whitespace characters preceding the latter
+	rtrim = new RegExp( "^" + whitespace + "+|((?:^|[^\\\\])(?:\\\\.)*)" + whitespace + "+$", "g" ),
+
+	rcomma = new RegExp( "^" + whitespace + "*," + whitespace + "*" ),
+	rcombinators = new RegExp( "^" + whitespace + "*([>+~]|" + whitespace + ")" + whitespace + "*" ),
+
+	rattributeQuotes = new RegExp( "=" + whitespace + "*([^\\]'\"]*?)" + whitespace + "*\\]", "g" ),
+
+	rpseudo = new RegExp( pseudos ),
+	ridentifier = new RegExp( "^" + identifier + "$" ),
+
+	matchExpr = {
+		"ID": new RegExp( "^#(" + characterEncoding + ")" ),
+		"CLASS": new RegExp( "^\\.(" + characterEncoding + ")" ),
+		"TAG": new RegExp( "^(" + characterEncoding.replace( "w", "w*" ) + ")" ),
+		"ATTR": new RegExp( "^" + attributes ),
+		"PSEUDO": new RegExp( "^" + pseudos ),
+		"CHILD": new RegExp( "^:(only|first|last|nth|nth-last)-(child|of-type)(?:\\(" + whitespace +
+			"*(even|odd|(([+-]|)(\\d*)n|)" + whitespace + "*(?:([+-]|)" + whitespace +
+			"*(\\d+)|))" + whitespace + "*\\)|)", "i" ),
+		"bool": new RegExp( "^(?:" + booleans + ")$", "i" ),
+		// For use in libraries implementing .is()
+		// We use this for POS matching in `select`
+		"needsContext": new RegExp( "^" + whitespace + "*[>+~]|:(even|odd|eq|gt|lt|nth|first|last)(?:\\(" +
+			whitespace + "*((?:-\\d)?\\d*)" + whitespace + "*\\)|)(?=[^-]|$)", "i" )
+	},
+
+	rinputs = /^(?:input|select|textarea|button)$/i,
+	rheader = /^h\d$/i,
+
+	rnative = /^[^{]+\{\s*\[native \w/,
+
+	// Easily-parseable/retrievable ID or TAG or CLASS selectors
+	rquickExpr = /^(?:#([\w-]+)|(\w+)|\.([\w-]+))$/,
+
+	rsibling = /[+~]/,
+	rescape = /'|\\/g,
+
+	// CSS escapes http://www.w3.org/TR/CSS21/syndata.html#escaped-characters
+	runescape = new RegExp( "\\\\([\\da-f]{1,6}" + whitespace + "?|(" + whitespace + ")|.)", "ig" ),
+	funescape = function( _, escaped, escapedWhitespace ) {
+		var high = "0x" + escaped - 0x10000;
+		// NaN means non-codepoint
+		// Support: Firefox
+		// Workaround erroneous numeric interpretation of +"0x"
+		return high !== high || escapedWhitespace ?
+			escaped :
+			high < 0 ?
+				// BMP codepoint
+				String.fromCharCode( high + 0x10000 ) :
+				// Supplemental Plane codepoint (surrogate pair)
+				String.fromCharCode( high >> 10 | 0xD800, high & 0x3FF | 0xDC00 );
+	};
+
+// Optimize for push.apply( _, NodeList )
+try {
+	push.apply(
+		(arr = slice.call( preferredDoc.childNodes )),
+		preferredDoc.childNodes
+	);
+	// Support: Android<4.0
+	// Detect silently failing push.apply
+	arr[ preferredDoc.childNodes.length ].nodeType;
+} catch ( e ) {
+	push = { apply: arr.length ?
+
+		// Leverage slice if possible
+		function( target, els ) {
+			push_native.apply( target, slice.call(els) );
+		} :
+
+		// Support: IE<9
+		// Otherwise append directly
+		function( target, els ) {
+			var j = target.length,
+				i = 0;
+			// Can't trust NodeList.length
+			while ( (target[j++] = els[i++]) ) {}
+			target.length = j - 1;
+		}
+	};
+}
+
+function Sizzle( selector, context, results, seed ) {
+	var match, elem, m, nodeType,
+		// QSA vars
+		i, groups, old, nid, newContext, newSelector;
+
+	if ( ( context ? context.ownerDocument || context : preferredDoc ) !== document ) {
+		setDocument( context );
+	}
+
+	context = context || document;
+	results = results || [];
+
+	if ( !selector || typeof selector !== "string" ) {
+		return results;
+	}
+
+	if ( (nodeType = context.nodeType) !== 1 && nodeType !== 9 ) {
+		return [];
+	}
+
+	if ( documentIsHTML && !seed ) {
+
+		// Shortcuts
+		if ( (match = rquickExpr.exec( selector )) ) {
+			// Speed-up: Sizzle("#ID")
+			if ( (m = match[1]) ) {
+				if ( nodeType === 9 ) {
+					elem = context.getElementById( m );
+					// Check parentNode to catch when Blackberry 4.6 returns
+					// nodes that are no longer in the document (jQuery #6963)
+					if ( elem && elem.parentNode ) {
+						// Handle the case where IE, Opera, and Webkit return items
+						// by name instead of ID
+						if ( elem.id === m ) {
+							results.push( elem );
+							return results;
+						}
+					} else {
+						return results;
+					}
+				} else {
+					// Context is not a document
+					if ( context.ownerDocument && (elem = context.ownerDocument.getElementById( m )) &&
+						contains( context, elem ) && elem.id === m ) {
+						results.push( elem );
+						return results;
+					}
+				}
+
+			// Speed-up: Sizzle("TAG")
+			} else if ( match[2] ) {
+				push.apply( results, context.getElementsByTagName( selector ) );
+				return results;
+
+			// Speed-up: Sizzle(".CLASS")
+			} else if ( (m = match[3]) && support.getElementsByClassName && context.getElementsByClassName ) {
+				push.apply( results, context.getElementsByClassName( m ) );
+				return results;
+			}
+		}
+
+		// QSA path
+		if ( support.qsa && (!rbuggyQSA || !rbuggyQSA.test( selector )) ) {
+			nid = old = expando;
+			newContext = context;
+			newSelector = nodeType === 9 && selector;
+
+			// qSA works strangely on Element-rooted queries
+			// We can work around this by specifying an extra ID on the root
+			// and working up from there (Thanks to Andrew Dupont for the technique)
+			// IE 8 doesn't work on object elements
+			if ( nodeType === 1 && context.nodeName.toLowerCase() !== "object" ) {
+				groups = tokenize( selector );
+
+				if ( (old = context.getAttribute("id")) ) {
+					nid = old.replace( rescape, "\\$&" );
+				} else {
+					context.setAttribute( "id", nid );
+				}
+				nid = "[id='" + nid + "'] ";
+
+				i = groups.length;
+				while ( i-- ) {
+					groups[i] = nid + toSelector( groups[i] );
+				}
+				newContext = rsibling.test( selector ) && testContext( context.parentNode ) || context;
+				newSelector = groups.join(",");
+			}
+
+			if ( newSelector ) {
+				try {
+					push.apply( results,
+						newContext.querySelectorAll( newSelector )
+					);
+					return results;
+				} catch(qsaError) {
+				} finally {
+					if ( !old ) {
+						context.removeAttribute("id");
+					}
+				}
+			}
+		}
+	}
+
+	// All others
+	return select( selector.replace( rtrim, "$1" ), context, results, seed );
+}
+
+/**
+ * Create key-value caches of limited size
+ * @returns {Function(string, Object)} Returns the Object data after storing it on itself with
+ *	property name the (space-suffixed) string and (if the cache is larger than Expr.cacheLength)
+ *	deleting the oldest entry
+ */
+function createCache() {
+	var keys = [];
+
+	function cache( key, value ) {
+		// Use (key + " ") to avoid collision with native prototype properties (see Issue #157)
+		if ( keys.push( key + " " ) > Expr.cacheLength ) {
+			// Only keep the most recent entries
+			delete cache[ keys.shift() ];
+		}
+		return (cache[ key + " " ] = value);
+	}
+	return cache;
+}
+
+/**
+ * Mark a function for special use by Sizzle
+ * @param {Function} fn The function to mark
+ */
+function markFunction( fn ) {
+	fn[ expando ] = true;
+	return fn;
+}
+
+/**
+ * Support testing using an element
+ * @param {Function} fn Passed the created div and expects a boolean result
+ */
+function assert( fn ) {
+	var div = document.createElement("div");
+
+	try {
+		return !!fn( div );
+	} catch (e) {
+		return false;
+	} finally {
+		// Remove from its parent by default
+		if ( div.parentNode ) {
+			div.parentNode.removeChild( div );
+		}
+		// release memory in IE
+		div = null;
+	}
+}
+
+/**
+ * Adds the same handler for all of the specified attrs
+ * @param {String} attrs Pipe-separated list of attributes
+ * @param {Function} handler The method that will be applied
+ */
+function addHandle( attrs, handler ) {
+	var arr = attrs.split("|"),
+		i = attrs.length;
+
+	while ( i-- ) {
+		Expr.attrHandle[ arr[i] ] = handler;
+	}
+}
+
+/**
+ * Checks document order of two siblings
+ * @param {Element} a
+ * @param {Element} b
+ * @returns {Number} Returns less than 0 if a precedes b, greater than 0 if a follows b
+ */
+function siblingCheck( a, b ) {
+	var cur = b && a,
+		diff = cur && a.nodeType === 1 && b.nodeType === 1 &&
+			( ~b.sourceIndex || MAX_NEGATIVE ) -
+			( ~a.sourceIndex || MAX_NEGATIVE );
+
+	// Use IE sourceIndex if available on both nodes
+	if ( diff ) {
+		return diff;
+	}
+
+	// Check if b follows a
+	if ( cur ) {
+		while ( (cur = cur.nextSibling) ) {
+			if ( cur === b ) {
+				return -1;
+			}
+		}
+	}
+
+	return a ? 1 : -1;
+}
+
+/**
+ * Returns a function to use in pseudos for input types
+ * @param {String} type
+ */
+function createInputPseudo( type ) {
+	return function( elem ) {
+		var name = elem.nodeName.toLowerCase();
+		return name === "input" && elem.type === type;
+	};
+}
+
+/**
+ * Returns a function to use in pseudos for buttons
+ * @param {String} type
+ */
+function createButtonPseudo( type ) {
+	return function( elem ) {
+		var name = elem.nodeName.toLowerCase();
+		return (name === "input" || name === "button") && elem.type === type;
+	};
+}
+
+/**
+ * Returns a function to use in pseudos for positionals
+ * @param {Function} fn
+ */
+function createPositionalPseudo( fn ) {
+	return markFunction(function( argument ) {
+		argument = +argument;
+		return markFunction(function( seed, matches ) {
+			var j,
+				matchIndexes = fn( [], seed.length, argument ),
+				i = matchIndexes.length;
+
+			// Match elements found at the specified indexes
+			while ( i-- ) {
+				if ( seed[ (j = matchIndexes[i]) ] ) {
+					seed[j] = !(matches[j] = seed[j]);
+				}
+			}
+		});
+	});
+}
+
+/**
+ * Checks a node for validity as a Sizzle context
+ * @param {Element|Object=} context
+ * @returns {Element|Object|Boolean} The input node if acceptable, otherwise a falsy value
+ */
+function testContext( context ) {
+	return context && typeof context.getElementsByTagName !== strundefined && context;
+}
+
+// Expose support vars for convenience
+support = Sizzle.support = {};
+
+/**
+ * Detects XML nodes
+ * @param {Element|Object} elem An element or a document
+ * @returns {Boolean} True iff elem is a non-HTML XML node
+ */
+isXML = Sizzle.isXML = function( elem ) {
+	// documentElement is verified for cases where it doesn't yet exist
+	// (such as loading iframes in IE - #4833)
+	var documentElement = elem && (elem.ownerDocument || elem).documentElement;
+	return documentElement ? documentElement.nodeName !== "HTML" : false;
+};
+
+/**
+ * Sets document-related variables once based on the current document
+ * @param {Element|Object} [doc] An element or document object to use to set the document
+ * @returns {Object} Returns the current document
+ */
+setDocument = Sizzle.setDocument = function( node ) {
+	var hasCompare,
+		doc = node ? node.ownerDocument || node : preferredDoc,
+		parent = doc.defaultView;
+
+	// If no document and documentElement is available, return
+	if ( doc === document || doc.nodeType !== 9 || !doc.documentElement ) {
+		return document;
+	}
+
+	// Set our document
+	document = doc;
+	docElem = doc.documentElement;
+
+	// Support tests
+	documentIsHTML = !isXML( doc );
+
+	// Support: IE>8
+	// If iframe document is assigned to "document" variable and if iframe has been reloaded,
+	// IE will throw "permission denied" error when accessing "document" variable, see jQuery #13936
+	// IE6-8 do not support the defaultView property so parent will be undefined
+	if ( parent && parent !== parent.top ) {
+		// IE11 does not have attachEvent, so all must suffer
+		if ( parent.addEventListener ) {
+			parent.addEventListener( "unload", function() {
+				setDocument();
+			}, false );
+		} else if ( parent.attachEvent ) {
+			parent.attachEvent( "onunload", function() {
+				setDocument();
+			});
+		}
+	}
+
+	/* Attributes
+	---------------------------------------------------------------------- */
+
+	// Support: IE<8
+	// Verify that getAttribute really returns attributes and not properties (excepting IE8 booleans)
+	support.attributes = assert(function( div ) {
+		div.className = "i";
+		return !div.getAttribute("className");
+	});
+
+	/* getElement(s)By*
+	---------------------------------------------------------------------- */
+
+	// Check if getElementsByTagName("*") returns only elements
+	support.getElementsByTagName = assert(function( div ) {
+		div.appendChild( doc.createComment("") );
+		return !div.getElementsByTagName("*").length;
+	});
+
+	// Check if getElementsByClassName can be trusted
+	support.getElementsByClassName = rnative.test( doc.getElementsByClassName ) && assert(function( div ) {
+		div.innerHTML = "<div class='a'></div><div class='a i'></div>";
+
+		// Support: Safari<4
+		// Catch class over-caching
+		div.firstChild.className = "i";
+		// Support: Opera<10
+		// Catch gEBCN failure to find non-leading classes
+		return div.getElementsByClassName("i").length === 2;
+	});
+
+	// Support: IE<10
+	// Check if getElementById returns elements by name
+	// The broken getElementById methods don't pick up programatically-set names,
+	// so use a roundabout getElementsByName test
+	support.getById = assert(function( div ) {
+		docElem.appendChild( div ).id = expando;
+		return !doc.getElementsByName || !doc.getElementsByName( expando ).length;
+	});
+
+	// ID find and filter
+	if ( support.getById ) {
+		Expr.find["ID"] = function( id, context ) {
+			if ( typeof context.getElementById !== strundefined && documentIsHTML ) {
+				var m = context.getElementById( id );
+				// Check parentNode to catch when Blackberry 4.6 returns
+				// nodes that are no longer in the document #6963
+				return m && m.parentNode ? [m] : [];
+			}
+		};
+		Expr.filter["ID"] = function( id ) {
+			var attrId = id.replace( runescape, funescape );
+			return function( elem ) {
+				return elem.getAttribute("id") === attrId;
+			};
+		};
+	} else {
+		// Support: IE6/7
+		// getElementById is not reliable as a find shortcut
+		delete Expr.find["ID"];
+
+		Expr.filter["ID"] =  function( id ) {
+			var attrId = id.replace( runescape, funescape );
+			return function( elem ) {
+				var node = typeof elem.getAttributeNode !== strundefined && elem.getAttributeNode("id");
+				return node && node.value === attrId;
+			};
+		};
+	}
+
+	// Tag
+	Expr.find["TAG"] = support.getElementsByTagName ?
+		function( tag, context ) {
+			if ( typeof context.getElementsByTagName !== strundefined ) {
+				return context.getElementsByTagName( tag );
+			}
+		} :
+		function( tag, context ) {
+			var elem,
+				tmp = [],
+				i = 0,
+				results = context.getElementsByTagName( tag );
+
+			// Filter out possible comments
+			if ( tag === "*" ) {
+				while ( (elem = results[i++]) ) {
+					if ( elem.nodeType === 1 ) {
+						tmp.push( elem );
+					}
+				}
+
+				return tmp;
+			}
+			return results;
+		};
+
+	// Class
+	Expr.find["CLASS"] = support.getElementsByClassName && function( className, context ) {
+		if ( typeof context.getElementsByClassName !== strundefined && documentIsHTML ) {
+			return context.getElementsByClassName( className );
+		}
+	};
+
+	/* QSA/matchesSelector
+	---------------------------------------------------------------------- */
+
+	// QSA and matchesSelector support
+
+	// matchesSelector(:active) reports false when true (IE9/Opera 11.5)
+	rbuggyMatches = [];
+
+	// qSa(:focus) reports false when true (Chrome 21)
+	// We allow this because of a bug in IE8/9 that throws an error
+	// whenever `document.activeElement` is accessed on an iframe
+	// So, we allow :focus to pass through QSA all the time to avoid the IE error
+	// See http://bugs.jquery.com/ticket/13378
+	rbuggyQSA = [];
+
+	if ( (support.qsa = rnative.test( doc.querySelectorAll )) ) {
+		// Build QSA regex
+		// Regex strategy adopted from Diego Perini
+		assert(function( div ) {
+			// Select is set to empty string on purpose
+			// This is to test IE's treatment of not explicitly
+			// setting a boolean content attribute,
+			// since its presence should be enough
+			// http://bugs.jquery.com/ticket/12359
+			div.innerHTML = "<select t=''><option selected=''></option></select>";
+
+			// Support: IE8, Opera 10-12
+			// Nothing should be selected when empty strings follow ^= or $= or *=
+			if ( div.querySelectorAll("[t^='']").length ) {
+				rbuggyQSA.push( "[*^$]=" + whitespace + "*(?:''|\"\")" );
+			}
+
+			// Support: IE8
+			// Boolean attributes and "value" are not treated correctly
+			if ( !div.querySelectorAll("[selected]").length ) {
+				rbuggyQSA.push( "\\[" + whitespace + "*(?:value|" + booleans + ")" );
+			}
+
+			// Webkit/Opera - :checked should return selected option elements
+			// http://www.w3.org/TR/2011/REC-css3-selectors-20110929/#checked
+			// IE8 throws error here and will not see later tests
+			if ( !div.querySelectorAll(":checked").length ) {
+				rbuggyQSA.push(":checked");
+			}
+		});
+
+		assert(function( div ) {
+			// Support: Windows 8 Native Apps
+			// The type and name attributes are restricted during .innerHTML assignment
+			var input = doc.createElement("input");
+			input.setAttribute( "type", "hidden" );
+			div.appendChild( input ).setAttribute( "name", "D" );
+
+			// Support: IE8
+			// Enforce case-sensitivity of name attribute
+			if ( div.querySelectorAll("[name=d]").length ) {
+				rbuggyQSA.push( "name" + whitespace + "*[*^$|!~]?=" );
+			}
+
+			// FF 3.5 - :enabled/:disabled and hidden elements (hidden elements are still enabled)
+			// IE8 throws error here and will not see later tests
+			if ( !div.querySelectorAll(":enabled").length ) {
+				rbuggyQSA.push( ":enabled", ":disabled" );
+			}
+
+			// Opera 10-11 does not throw on post-comma invalid pseudos
+			div.querySelectorAll("*,:x");
+			rbuggyQSA.push(",.*:");
+		});
+	}
+
+	if ( (support.matchesSelector = rnative.test( (matches = docElem.webkitMatchesSelector ||
+		docElem.mozMatchesSelector ||
+		docElem.oMatchesSelector ||
+		docElem.msMatchesSelector) )) ) {
+
+		assert(function( div ) {
+			// Check to see if it's possible to do matchesSelector
+			// on a disconnected node (IE 9)
+			support.disconnectedMatch = matches.call( div, "div" );
+
+			// This should fail with an exception
+			// Gecko does not error, returns false instead
+			matches.call( div, "[s!='']:x" );
+			rbuggyMatches.push( "!=", pseudos );
+		});
+	}
+
+	rbuggyQSA = rbuggyQSA.length && new RegExp( rbuggyQSA.join("|") );
+	rbuggyMatches = rbuggyMatches.length && new RegExp( rbuggyMatches.join("|") );
+
+	/* Contains
+	---------------------------------------------------------------------- */
+	hasCompare = rnative.test( docElem.compareDocumentPosition );
+
+	// Element contains another
+	// Purposefully does not implement inclusive descendent
+	// As in, an element does not contain itself
+	contains = hasCompare || rnative.test( docElem.contains ) ?
+		function( a, b ) {
+			var adown = a.nodeType === 9 ? a.documentElement : a,
+				bup = b && b.parentNode;
+			return a === bup || !!( bup && bup.nodeType === 1 && (
+				adown.contains ?
+					adown.contains( bup ) :
+					a.compareDocumentPosition && a.compareDocumentPosition( bup ) & 16
+			));
+		} :
+		function( a, b ) {
+			if ( b ) {
+				while ( (b = b.parentNode) ) {
+					if ( b === a ) {
+						return true;
+					}
+				}
+			}
+			return false;
+		};
+
+	/* Sorting
+	---------------------------------------------------------------------- */
+
+	// Document order sorting
+	sortOrder = hasCompare ?
+	function( a, b ) {
+
+		// Flag for duplicate removal
+		if ( a === b ) {
+			hasDuplicate = true;
+			return 0;
+		}
+
+		// Sort on method existence if only one input has compareDocumentPosition
+		var compare = !a.compareDocumentPosition - !b.compareDocumentPosition;
+		if ( compare ) {
+			return compare;
+		}
+
+		// Calculate position if both inputs belong to the same document
+		compare = ( a.ownerDocument || a ) === ( b.ownerDocument || b ) ?
+			a.compareDocumentPosition( b ) :
+
+			// Otherwise we know they are disconnected
+			1;
+
+		// Disconnected nodes
+		if ( compare & 1 ||
+			(!support.sortDetached && b.compareDocumentPosition( a ) === compare) ) {
+
+			// Choose the first element that is related to our preferred document
+			if ( a === doc || a.ownerDocument === preferredDoc && contains(preferredDoc, a) ) {
+				return -1;
+			}
+			if ( b === doc || b.ownerDocument === preferredDoc && contains(preferredDoc, b) ) {
+				return 1;
+			}
+
+			// Maintain original order
+			return sortInput ?
+				( indexOf.call( sortInput, a ) - indexOf.call( sortInput, b ) ) :
+				0;
+		}
+
+		return compare & 4 ? -1 : 1;
+	} :
+	function( a, b ) {
+		// Exit early if the nodes are identical
+		if ( a === b ) {
+			hasDuplicate = true;
+			return 0;
+		}
+
+		var cur,
+			i = 0,
+			aup = a.parentNode,
+			bup = b.parentNode,
+			ap = [ a ],
+			bp = [ b ];
+
+		// Parentless nodes are either documents or disconnected
+		if ( !aup || !bup ) {
+			return a === doc ? -1 :
+				b === doc ? 1 :
+				aup ? -1 :
+				bup ? 1 :
+				sortInput ?
+				( indexOf.call( sortInput, a ) - indexOf.call( sortInput, b ) ) :
+				0;
+
+		// If the nodes are siblings, we can do a quick check
+		} else if ( aup === bup ) {
+			return siblingCheck( a, b );
+		}
+
+		// Otherwise we need full lists of their ancestors for comparison
+		cur = a;
+		while ( (cur = cur.parentNode) ) {
+			ap.unshift( cur );
+		}
+		cur = b;
+		while ( (cur = cur.parentNode) ) {
+			bp.unshift( cur );
+		}
+
+		// Walk down the tree looking for a discrepancy
+		while ( ap[i] === bp[i] ) {
+			i++;
+		}
+
+		return i ?
+			// Do a sibling check if the nodes have a common ancestor
+			siblingCheck( ap[i], bp[i] ) :
+
+			// Otherwise nodes in our document sort first
+			ap[i] === preferredDoc ? -1 :
+			bp[i] === preferredDoc ? 1 :
+			0;
+	};
+
+	return doc;
+};
+
+Sizzle.matches = function( expr, elements ) {
+	return Sizzle( expr, null, null, elements );
+};
+
+Sizzle.matchesSelector = function( elem, expr ) {
+	// Set document vars if needed
+	if ( ( elem.ownerDocument || elem ) !== document ) {
+		setDocument( elem );
+	}
+
+	// Make sure that attribute selectors are quoted
+	expr = expr.replace( rattributeQuotes, "='$1']" );
+
+	if ( support.matchesSelector && documentIsHTML &&
+		( !rbuggyMatches || !rbuggyMatches.test( expr ) ) &&
+		( !rbuggyQSA     || !rbuggyQSA.test( expr ) ) ) {
+
+		try {
+			var ret = matches.call( elem, expr );
+
+			// IE 9's matchesSelector returns false on disconnected nodes
+			if ( ret || support.disconnectedMatch ||
+					// As well, disconnected nodes are said to be in a document
+					// fragment in IE 9
+					elem.document && elem.document.nodeType !== 11 ) {
+				return ret;
+			}
+		} catch(e) {}
+	}
+
+	return Sizzle( expr, document, null, [elem] ).length > 0;
+};
+
+Sizzle.contains = function( context, elem ) {
+	// Set document vars if needed
+	if ( ( context.ownerDocument || context ) !== document ) {
+		setDocument( context );
+	}
+	return contains( context, elem );
+};
+
+Sizzle.attr = function( elem, name ) {
+	// Set document vars if needed
+	if ( ( elem.ownerDocument || elem ) !== document ) {
+		setDocument( elem );
+	}
+
+	var fn = Expr.attrHandle[ name.toLowerCase() ],
+		// Don't get fooled by Object.prototype properties (jQuery #13807)
+		val = fn && hasOwn.call( Expr.attrHandle, name.toLowerCase() ) ?
+			fn( elem, name, !documentIsHTML ) :
+			undefined;
+
+	return val !== undefined ?
+		val :
+		support.attributes || !documentIsHTML ?
+			elem.getAttribute( name ) :
+			(val = elem.getAttributeNode(name)) && val.specified ?
+				val.value :
+				null;
+};
+
+Sizzle.error = function( msg ) {
+	throw new Error( "Syntax error, unrecognized expression: " + msg );
+};
+
+/**
+ * Document sorting and removing duplicates
+ * @param {ArrayLike} results
+ */
+Sizzle.uniqueSort = function( results ) {
+	var elem,
+		duplicates = [],
+		j = 0,
+		i = 0;
+
+	// Unless we *know* we can detect duplicates, assume their presence
+	hasDuplicate = !support.detectDuplicates;
+	sortInput = !support.sortStable && results.slice( 0 );
+	results.sort( sortOrder );
+
+	if ( hasDuplicate ) {
+		while ( (elem = results[i++]) ) {
+			if ( elem === results[ i ] ) {
+				j = duplicates.push( i );
+			}
+		}
+		while ( j-- ) {
+			results.splice( duplicates[ j ], 1 );
+		}
+	}
+
+	// Clear input after sorting to release objects
+	// See https://github.com/jquery/sizzle/pull/225
+	sortInput = null;
+
+	return results;
+};
+
+/**
+ * Utility function for retrieving the text value of an array of DOM nodes
+ * @param {Array|Element} elem
+ */
+getText = Sizzle.getText = function( elem ) {
+	var node,
+		ret = "",
+		i = 0,
+		nodeType = elem.nodeType;
+
+	if ( !nodeType ) {
+		// If no nodeType, this is expected to be an array
+		while ( (node = elem[i++]) ) {
+			// Do not traverse comment nodes
+			ret += getText( node );
+		}
+	} else if ( nodeType === 1 || nodeType === 9 || nodeType === 11 ) {
+		// Use textContent for elements
+		// innerText usage removed for consistency of new lines (jQuery #11153)
+		if ( typeof elem.textContent === "string" ) {
+			return elem.textContent;
+		} else {
+			// Traverse its children
+			for ( elem = elem.firstChild; elem; elem = elem.nextSibling ) {
+				ret += getText( elem );
+			}
+		}
+	} else if ( nodeType === 3 || nodeType === 4 ) {
+		return elem.nodeValue;
+	}
+	// Do not include comment or processing instruction nodes
+
+	return ret;
+};
+
+Expr = Sizzle.selectors = {
+
+	// Can be adjusted by the user
+	cacheLength: 50,
+
+	createPseudo: markFunction,
+
+	match: matchExpr,
+
+	attrHandle: {},
+
+	find: {},
+
+	relative: {
+		">": { dir: "parentNode", first: true },
+		" ": { dir: "parentNode" },
+		"+": { dir: "previousSibling", first: true },
+		"~": { dir: "previousSibling" }
+	},
+
+	preFilter: {
+		"ATTR": function( match ) {
+			match[1] = match[1].replace( runescape, funescape );
+
+			// Move the given value to match[3] whether quoted or unquoted
+			match[3] = ( match[4] || match[5] || "" ).replace( runescape, funescape );
+
+			if ( match[2] === "~=" ) {
+				match[3] = " " + match[3] + " ";
+			}
+
+			return match.slice( 0, 4 );
+		},
+
+		"CHILD": function( match ) {
+			/* matches from matchExpr["CHILD"]
+				1 type (only|nth|...)
+				2 what (child|of-type)
+				3 argument (even|odd|\d*|\d*n([+-]\d+)?|...)
+				4 xn-component of xn+y argument ([+-]?\d*n|)
+				5 sign of xn-component
+				6 x of xn-component
+				7 sign of y-component
+				8 y of y-component
+			*/
+			match[1] = match[1].toLowerCase();
+
+			if ( match[1].slice( 0, 3 ) === "nth" ) {
+				// nth-* requires argument
+				if ( !match[3] ) {
+					Sizzle.error( match[0] );
+				}
+
+				// numeric x and y parameters for Expr.filter.CHILD
+				// remember that false/true cast respectively to 0/1
+				match[4] = +( match[4] ? match[5] + (match[6] || 1) : 2 * ( match[3] === "even" || match[3] === "odd" ) );
+				match[5] = +( ( match[7] + match[8] ) || match[3] === "odd" );
+
+			// other types prohibit arguments
+			} else if ( match[3] ) {
+				Sizzle.error( match[0] );
+			}
+
+			return match;
+		},
+
+		"PSEUDO": function( match ) {
+			var excess,
+				unquoted = !match[5] && match[2];
+
+			if ( matchExpr["CHILD"].test( match[0] ) ) {
+				return null;
+			}
+
+			// Accept quoted arguments as-is
+			if ( match[3] && match[4] !== undefined ) {
+				match[2] = match[4];
+
+			// Strip excess characters from unquoted arguments
+			} else if ( unquoted && rpseudo.test( unquoted ) &&
+				// Get excess from tokenize (recursively)
+				(excess = tokenize( unquoted, true )) &&
+				// advance to the next closing parenthesis
+				(excess = unquoted.indexOf( ")", unquoted.length - excess ) - unquoted.length) ) {
+
+				// excess is a negative index
+				match[0] = match[0].slice( 0, excess );
+				match[2] = unquoted.slice( 0, excess );
+			}
+
+			// Return only captures needed by the pseudo filter method (type and argument)
+			return match.slice( 0, 3 );
+		}
+	},
+
+	filter: {
+
+		"TAG": function( nodeNameSelector ) {
+			var nodeName = nodeNameSelector.replace( runescape, funescape ).toLowerCase();
+			return nodeNameSelector === "*" ?
+				function() { return true; } :
+				function( elem ) {
+					return elem.nodeName && elem.nodeName.toLowerCase() === nodeName;
+				};
+		},
+
+		"CLASS": function( className ) {
+			var pattern = classCache[ className + " " ];
+
+			return pattern ||
+				(pattern = new RegExp( "(^|" + whitespace + ")" + className + "(" + whitespace + "|$)" )) &&
+				classCache( className, function( elem ) {
+					return pattern.test( typeof elem.className === "string" && elem.className || typeof elem.getAttribute !== strundefined && elem.getAttribute("class") || "" );
+				});
+		},
+
+		"ATTR": function( name, operator, check ) {
+			return function( elem ) {
+				var result = Sizzle.attr( elem, name );
+
+				if ( result == null ) {
+					return operator === "!=";
+				}
+				if ( !operator ) {
+					return true;
+				}
+
+				result += "";
+
+				return operator === "=" ? result === check :
+					operator === "!=" ? result !== check :
+					operator === "^=" ? check && result.indexOf( check ) === 0 :
+					operator === "*=" ? check && result.indexOf( check ) > -1 :
+					operator === "$=" ? check && result.slice( -check.length ) === check :
+					operator === "~=" ? ( " " + result + " " ).indexOf( check ) > -1 :
+					operator === "|=" ? result === check || result.slice( 0, check.length + 1 ) === check + "-" :
+					false;
+			};
+		},
+
+		"CHILD": function( type, what, argument, first, last ) {
+			var simple = type.slice( 0, 3 ) !== "nth",
+				forward = type.slice( -4 ) !== "last",
+				ofType = what === "of-type";
+
+			return first === 1 && last === 0 ?
+
+				// Shortcut for :nth-*(n)
+				function( elem ) {
+					return !!elem.parentNode;
+				} :
+
+				function( elem, context, xml ) {
+					var cache, outerCache, node, diff, nodeIndex, start,
+						dir = simple !== forward ? "nextSibling" : "previousSibling",
+						parent = elem.parentNode,
+						name = ofType && elem.nodeName.toLowerCase(),
+						useCache = !xml && !ofType;
+
+					if ( parent ) {
+
+						// :(first|last|only)-(child|of-type)
+						if ( simple ) {
+							while ( dir ) {
+								node = elem;
+								while ( (node = node[ dir ]) ) {
+									if ( ofType ? node.nodeName.toLowerCase() === name : node.nodeType === 1 ) {
+										return false;
+									}
+								}
+								// Reverse direction for :only-* (if we haven't yet done so)
+								start = dir = type === "only" && !start && "nextSibling";
+							}
+							return true;
+						}
+
+						start = [ forward ? parent.firstChild : parent.lastChild ];
+
+						// non-xml :nth-child(...) stores cache data on `parent`
+						if ( forward && useCache ) {
+							// Seek `elem` from a previously-cached index
+							outerCache = parent[ expando ] || (parent[ expando ] = {});
+							cache = outerCache[ type ] || [];
+							nodeIndex = cache[0] === dirruns && cache[1];
+							diff = cache[0] === dirruns && cache[2];
+							node = nodeIndex && parent.childNodes[ nodeIndex ];
+
+							while ( (node = ++nodeIndex && node && node[ dir ] ||
+
+								// Fallback to seeking `elem` from the start
+								(diff = nodeIndex = 0) || start.pop()) ) {
+
+								// When found, cache indexes on `parent` and break
+								if ( node.nodeType === 1 && ++diff && node === elem ) {
+									outerCache[ type ] = [ dirruns, nodeIndex, diff ];
+									break;
+								}
+							}
+
+						// Use previously-cached element index if available
+						} else if ( useCache && (cache = (elem[ expando ] || (elem[ expando ] = {}))[ type ]) && cache[0] === dirruns ) {
+							diff = cache[1];
+
+						// xml :nth-child(...) or :nth-last-child(...) or :nth(-last)?-of-type(...)
+						} else {
+							// Use the same loop as above to seek `elem` from the start
+							while ( (node = ++nodeIndex && node && node[ dir ] ||
+								(diff = nodeIndex = 0) || start.pop()) ) {
+
+								if ( ( ofType ? node.nodeName.toLowerCase() === name : node.nodeType === 1 ) && ++diff ) {
+									// Cache the index of each encountered element
+									if ( useCache ) {
+										(node[ expando ] || (node[ expando ] = {}))[ type ] = [ dirruns, diff ];
+									}
+
+									if ( node === elem ) {
+										break;
+									}
+								}
+							}
+						}
+
+						// Incorporate the offset, then check against cycle size
+						diff -= last;
+						return diff === first || ( diff % first === 0 && diff / first >= 0 );
+					}
+				};
+		},
+
+		"PSEUDO": function( pseudo, argument ) {
+			// pseudo-class names are case-insensitive
+			// http://www.w3.org/TR/selectors/#pseudo-classes
+			// Prioritize by case sensitivity in case custom pseudos are added with uppercase letters
+			// Remember that setFilters inherits from pseudos
+			var args,
+				fn = Expr.pseudos[ pseudo ] || Expr.setFilters[ pseudo.toLowerCase() ] ||
+					Sizzle.error( "unsupported pseudo: " + pseudo );
+
+			// The user may use createPseudo to indicate that
+			// arguments are needed to create the filter function
+			// just as Sizzle does
+			if ( fn[ expando ] ) {
+				return fn( argument );
+			}
+
+			// But maintain support for old signatures
+			if ( fn.length > 1 ) {
+				args = [ pseudo, pseudo, "", argument ];
+				return Expr.setFilters.hasOwnProperty( pseudo.toLowerCase() ) ?
+					markFunction(function( seed, matches ) {
+						var idx,
+							matched = fn( seed, argument ),
+							i = matched.length;
+						while ( i-- ) {
+							idx = indexOf.call( seed, matched[i] );
+							seed[ idx ] = !( matches[ idx ] = matched[i] );
+						}
+					}) :
+					function( elem ) {
+						return fn( elem, 0, args );
+					};
+			}
+
+			return fn;
+		}
+	},
+
+	pseudos: {
+		// Potentially complex pseudos
+		"not": markFunction(function( selector ) {
+			// Trim the selector passed to compile
+			// to avoid treating leading and trailing
+			// spaces as combinators
+			var input = [],
+				results = [],
+				matcher = compile( selector.replace( rtrim, "$1" ) );
+
+			return matcher[ expando ] ?
+				markFunction(function( seed, matches, context, xml ) {
+					var elem,
+						unmatched = matcher( seed, null, xml, [] ),
+						i = seed.length;
+
+					// Match elements unmatched by `matcher`
+					while ( i-- ) {
+						if ( (elem = unmatched[i]) ) {
+							seed[i] = !(matches[i] = elem);
+						}
+					}
+				}) :
+				function( elem, context, xml ) {
+					input[0] = elem;
+					matcher( input, null, xml, results );
+					return !results.pop();
+				};
+		}),
+
+		"has": markFunction(function( selector ) {
+			return function( elem ) {
+				return Sizzle( selector, elem ).length > 0;
+			};
+		}),
+
+		"contains": markFunction(function( text ) {
+			return function( elem ) {
+				return ( elem.textContent || elem.innerText || getText( elem ) ).indexOf( text ) > -1;
+			};
+		}),
+
+		// "Whether an element is represented by a :lang() selector
+		// is based solely on the element's language value
+		// being equal to the identifier C,
+		// or beginning with the identifier C immediately followed by "-".
+		// The matching of C against the element's language value is performed case-insensitively.
+		// The identifier C does not have to be a valid language name."
+		// http://www.w3.org/TR/selectors/#lang-pseudo
+		"lang": markFunction( function( lang ) {
+			// lang value must be a valid identifier
+			if ( !ridentifier.test(lang || "") ) {
+				Sizzle.error( "unsupported lang: " + lang );
+			}
+			lang = lang.replace( runescape, funescape ).toLowerCase();
+			return function( elem ) {
+				var elemLang;
+				do {
+					if ( (elemLang = documentIsHTML ?
+						elem.lang :
+						elem.getAttribute("xml:lang") || elem.getAttribute("lang")) ) {
+
+						elemLang = elemLang.toLowerCase();
+						return elemLang === lang || elemLang.indexOf( lang + "-" ) === 0;
+					}
+				} while ( (elem = elem.parentNode) && elem.nodeType === 1 );
+				return false;
+			};
+		}),
+
+		// Miscellaneous
+		"target": function( elem ) {
+			var hash = window.location && window.location.hash;
+			return hash && hash.slice( 1 ) === elem.id;
+		},
+
+		"root": function( elem ) {
+			return elem === docElem;
+		},
+
+		"focus": function( elem ) {
+			return elem === document.activeElement && (!document.hasFocus || document.hasFocus()) && !!(elem.type || elem.href || ~elem.tabIndex);
+		},
+
+		// Boolean properties
+		"enabled": function( elem ) {
+			return elem.disabled === false;
+		},
+
+		"disabled": function( elem ) {
+			return elem.disabled === true;
+		},
+
+		"checked": function( elem ) {
+			// In CSS3, :checked should return both checked and selected elements
+			// http://www.w3.org/TR/2011/REC-css3-selectors-20110929/#checked
+			var nodeName = elem.nodeName.toLowerCase();
+			return (nodeName === "input" && !!elem.checked) || (nodeName === "option" && !!elem.selected);
+		},
+
+		"selected": function( elem ) {
+			// Accessing this property makes selected-by-default
+			// options in Safari work properly
+			if ( elem.parentNode ) {
+				elem.parentNode.selectedIndex;
+			}
+
+			return elem.selected === true;
+		},
+
+		// Contents
+		"empty": function( elem ) {
+			// http://www.w3.org/TR/selectors/#empty-pseudo
+			// :empty is negated by element (1) or content nodes (text: 3; cdata: 4; entity ref: 5),
+			//   but not by others (comment: 8; processing instruction: 7; etc.)
+			// nodeType < 6 works because attributes (2) do not appear as children
+			for ( elem = elem.firstChild; elem; elem = elem.nextSibling ) {
+				if ( elem.nodeType < 6 ) {
+					return false;
+				}
+			}
+			return true;
+		},
+
+		"parent": function( elem ) {
+			return !Expr.pseudos["empty"]( elem );
+		},
+
+		// Element/input types
+		"header": function( elem ) {
+			return rheader.test( elem.nodeName );
+		},
+
+		"input": function( elem ) {
+			return rinputs.test( elem.nodeName );
+		},
+
+		"button": function( elem ) {
+			var name = elem.nodeName.toLowerCase();
+			return name === "input" && elem.type === "button" || name === "button";
+		},
+
+		"text": function( elem ) {
+			var attr;
+			return elem.nodeName.toLowerCase() === "input" &&
+				elem.type === "text" &&
+
+				// Support: IE<8
+				// New HTML5 attribute values (e.g., "search") appear with elem.type === "text"
+				( (attr = elem.getAttribute("type")) == null || attr.toLowerCase() === "text" );
+		},
+
+		// Position-in-collection
+		"first": createPositionalPseudo(function() {
+			return [ 0 ];
+		}),
+
+		"last": createPositionalPseudo(function( matchIndexes, length ) {
+			return [ length - 1 ];
+		}),
+
+		"eq": createPositionalPseudo(function( matchIndexes, length, argument ) {
+			return [ argument < 0 ? argument + length : argument ];
+		}),
+
+		"even": createPositionalPseudo(function( matchIndexes, length ) {
+			var i = 0;
+			for ( ; i < length; i += 2 ) {
+				matchIndexes.push( i );
+			}
+			return matchIndexes;
+		}),
+
+		"odd": createPositionalPseudo(function( matchIndexes, length ) {
+			var i = 1;
+			for ( ; i < length; i += 2 ) {
+				matchIndexes.push( i );
+			}
+			return matchIndexes;
+		}),
+
+		"lt": createPositionalPseudo(function( matchIndexes, length, argument ) {
+			var i = argument < 0 ? argument + length : argument;
+			for ( ; --i >= 0; ) {
+				matchIndexes.push( i );
+			}
+			return matchIndexes;
+		}),
+
+		"gt": createPositionalPseudo(function( matchIndexes, length, argument ) {
+			var i = argument < 0 ? argument + length : argument;
+			for ( ; ++i < length; ) {
+				matchIndexes.push( i );
+			}
+			return matchIndexes;
+		})
+	}
+};
+
+Expr.pseudos["nth"] = Expr.pseudos["eq"];
+
+// Add button/input type pseudos
+for ( i in { radio: true, checkbox: true, file: true, password: true, image: true } ) {
+	Expr.pseudos[ i ] = createInputPseudo( i );
+}
+for ( i in { submit: true, reset: true } ) {
+	Expr.pseudos[ i ] = createButtonPseudo( i );
+}
+
+// Easy API for creating new setFilters
+function setFilters() {}
+setFilters.prototype = Expr.filters = Expr.pseudos;
+Expr.setFilters = new setFilters();
+
+function tokenize( selector, parseOnly ) {
+	var matched, match, tokens, type,
+		soFar, groups, preFilters,
+		cached = tokenCache[ selector + " " ];
+
+	if ( cached ) {
+		return parseOnly ? 0 : cached.slice( 0 );
+	}
+
+	soFar = selector;
+	groups = [];
+	preFilters = Expr.preFilter;
+
+	while ( soFar ) {
+
+		// Comma and first run
+		if ( !matched || (match = rcomma.exec( soFar )) ) {
+			if ( match ) {
+				// Don't consume trailing commas as valid
+				soFar = soFar.slice( match[0].length ) || soFar;
+			}
+			groups.push( (tokens = []) );
+		}
+
+		matched = false;
+
+		// Combinators
+		if ( (match = rcombinators.exec( soFar )) ) {
+			matched = match.shift();
+			tokens.push({
+				value: matched,
+				// Cast descendant combinators to space
+				type: match[0].replace( rtrim, " " )
+			});
+			soFar = soFar.slice( matched.length );
+		}
+
+		// Filters
+		for ( type in Expr.filter ) {
+			if ( (match = matchExpr[ type ].exec( soFar )) && (!preFilters[ type ] ||
+				(match = preFilters[ type ]( match ))) ) {
+				matched = match.shift();
+				tokens.push({
+					value: matched,
+					type: type,
+					matches: match
+				});
+				soFar = soFar.slice( matched.length );
+			}
+		}
+
+		if ( !matched ) {
+			break;
+		}
+	}
+
+	// Return the length of the invalid excess
+	// if we're just parsing
+	// Otherwise, throw an error or return tokens
+	return parseOnly ?
+		soFar.length :
+		soFar ?
+			Sizzle.error( selector ) :
+			// Cache the tokens
+			tokenCache( selector, groups ).slice( 0 );
+}
+
+function toSelector( tokens ) {
+	var i = 0,
+		len = tokens.length,
+		selector = "";
+	for ( ; i < len; i++ ) {
+		selector += tokens[i].value;
+	}
+	return selector;
+}
+
+function addCombinator( matcher, combinator, base ) {
+	var dir = combinator.dir,
+		checkNonElements = base && dir === "parentNode",
+		doneName = done++;
+
+	return combinator.first ?
+		// Check against closest ancestor/preceding element
+		function( elem, context, xml ) {
+			while ( (elem = elem[ dir ]) ) {
+				if ( elem.nodeType === 1 || checkNonElements ) {
+					return matcher( elem, context, xml );
+				}
+			}
+		} :
+
+		// Check against all ancestor/preceding elements
+		function( elem, context, xml ) {
+			var oldCache, outerCache,
+				newCache = [ dirruns, doneName ];
+
+			// We can't set arbitrary data on XML nodes, so they don't benefit from dir caching
+			if ( xml ) {
+				while ( (elem = elem[ dir ]) ) {
+					if ( elem.nodeType === 1 || checkNonElements ) {
+						if ( matcher( elem, context, xml ) ) {
+							return true;
+						}
+					}
+				}
+			} else {
+				while ( (elem = elem[ dir ]) ) {
+					if ( elem.nodeType === 1 || checkNonElements ) {
+						outerCache = elem[ expando ] || (elem[ expando ] = {});
+						if ( (oldCache = outerCache[ dir ]) &&
+							oldCache[ 0 ] === dirruns && oldCache[ 1 ] === doneName ) {
+
+							// Assign to newCache so results back-propagate to previous elements
+							return (newCache[ 2 ] = oldCache[ 2 ]);
+						} else {
+							// Reuse newcache so results back-propagate to previous elements
+							outerCache[ dir ] = newCache;
+
+							// A match means we're done; a fail means we have to keep checking
+							if ( (newCache[ 2 ] = matcher( elem, context, xml )) ) {
+								return true;
+							}
+						}
+					}
+				}
+			}
+		};
+}
+
+function elementMatcher( matchers ) {
+	return matchers.length > 1 ?
+		function( elem, context, xml ) {
+			var i = matchers.length;
+			while ( i-- ) {
+				if ( !matchers[i]( elem, context, xml ) ) {
+					return false;
+				}
+			}
+			return true;
+		} :
+		matchers[0];
+}
+
+function condense( unmatched, map, filter, context, xml ) {
+	var elem,
+		newUnmatched = [],
+		i = 0,
+		len = unmatched.length,
+		mapped = map != null;
+
+	for ( ; i < len; i++ ) {
+		if ( (elem = unmatched[i]) ) {
+			if ( !filter || filter( elem, context, xml ) ) {
+				newUnmatched.push( elem );
+				if ( mapped ) {
+					map.push( i );
+				}
+			}
+		}
+	}
+
+	return newUnmatched;
+}
+
+function setMatcher( preFilter, selector, matcher, postFilter, postFinder, postSelector ) {
+	if ( postFilter && !postFilter[ expando ] ) {
+		postFilter = setMatcher( postFilter );
+	}
+	if ( postFinder && !postFinder[ expando ] ) {
+		postFinder = setMatcher( postFinder, postSelector );
+	}
+	return markFunction(function( seed, results, context, xml ) {
+		var temp, i, elem,
+			preMap = [],
+			postMap = [],
+			preexisting = results.length,
+
+			// Get initial elements from seed or context
+			elems = seed || multipleContexts( selector || "*", context.nodeType ? [ context ] : context, [] ),
+
+			// Prefilter to get matcher input, preserving a map for seed-results synchronization
+			matcherIn = preFilter && ( seed || !selector ) ?
+				condense( elems, preMap, preFilter, context, xml ) :
+				elems,
+
+			matcherOut = matcher ?
+				// If we have a postFinder, or filtered seed, or non-seed postFilter or preexisting results,
+				postFinder || ( seed ? preFilter : preexisting || postFilter ) ?
+
+					// ...intermediate processing is necessary
+					[] :
+
+					// ...otherwise use results directly
+					results :
+				matcherIn;
+
+		// Find primary matches
+		if ( matcher ) {
+			matcher( matcherIn, matcherOut, context, xml );
+		}
+
+		// Apply postFilter
+		if ( postFilter ) {
+			temp = condense( matcherOut, postMap );
+			postFilter( temp, [], context, xml );
+
+			// Un-match failing elements by moving them back to matcherIn
+			i = temp.length;
+			while ( i-- ) {
+				if ( (elem = temp[i]) ) {
+					matcherOut[ postMap[i] ] = !(matcherIn[ postMap[i] ] = elem);
+				}
+			}
+		}
+
+		if ( seed ) {
+			if ( postFinder || preFilter ) {
+				if ( postFinder ) {
+					// Get the final matcherOut by condensing this intermediate into postFinder contexts
+					temp = [];
+					i = matcherOut.length;
+					while ( i-- ) {
+						if ( (elem = matcherOut[i]) ) {
+							// Restore matcherIn since elem is not yet a final match
+							temp.push( (matcherIn[i] = elem) );
+						}
+					}
+					postFinder( null, (matcherOut = []), temp, xml );
+				}
+
+				// Move matched elements from seed to results to keep them synchronized
+				i = matcherOut.length;
+				while ( i-- ) {
+					if ( (elem = matcherOut[i]) &&
+						(temp = postFinder ? indexOf.call( seed, elem ) : preMap[i]) > -1 ) {
+
+						seed[temp] = !(results[temp] = elem);
+					}
+				}
+			}
+
+		// Add elements to results, through postFinder if defined
+		} else {
+			matcherOut = condense(
+				matcherOut === results ?
+					matcherOut.splice( preexisting, matcherOut.length ) :
+					matcherOut
+			);
+			if ( postFinder ) {
+				postFinder( null, results, matcherOut, xml );
+			} else {
+				push.apply( results, matcherOut );
+			}
+		}
+	});
+}
+
+function matcherFromTokens( tokens ) {
+	var checkContext, matcher, j,
+		len = tokens.length,
+		leadingRelative = Expr.relative[ tokens[0].type ],
+		implicitRelative = leadingRelative || Expr.relative[" "],
+		i = leadingRelative ? 1 : 0,
+
+		// The foundational matcher ensures that elements are reachable from top-level context(s)
+		matchContext = addCombinator( function( elem ) {
+			return elem === checkContext;
+		}, implicitRelative, true ),
+		matchAnyContext = addCombinator( function( elem ) {
+			return indexOf.call( checkContext, elem ) > -1;
+		}, implicitRelative, true ),
+		matchers = [ function( elem, context, xml ) {
+			return ( !leadingRelative && ( xml || context !== outermostContext ) ) || (
+				(checkContext = context).nodeType ?
+					matchContext( elem, context, xml ) :
+					matchAnyContext( elem, context, xml ) );
+		} ];
+
+	for ( ; i < len; i++ ) {
+		if ( (matcher = Expr.relative[ tokens[i].type ]) ) {
+			matchers = [ addCombinator(elementMatcher( matchers ), matcher) ];
+		} else {
+			matcher = Expr.filter[ tokens[i].type ].apply( null, tokens[i].matches );
+
+			// Return special upon seeing a positional matcher
+			if ( matcher[ expando ] ) {
+				// Find the next relative operator (if any) for proper handling
+				j = ++i;
+				for ( ; j < len; j++ ) {
+					if ( Expr.relative[ tokens[j].type ] ) {
+						break;
+					}
+				}
+				return setMatcher(
+					i > 1 && elementMatcher( matchers ),
+					i > 1 && toSelector(
+						// If the preceding token was a descendant combinator, insert an implicit any-element `*`
+						tokens.slice( 0, i - 1 ).concat({ value: tokens[ i - 2 ].type === " " ? "*" : "" })
+					).replace( rtrim, "$1" ),
+					matcher,
+					i < j && matcherFromTokens( tokens.slice( i, j ) ),
+					j < len && matcherFromTokens( (tokens = tokens.slice( j )) ),
+					j < len && toSelector( tokens )
+				);
+			}
+			matchers.push( matcher );
+		}
+	}
+
+	return elementMatcher( matchers );
+}
+
+function matcherFromGroupMatchers( elementMatchers, setMatchers ) {
+	var bySet = setMatchers.length > 0,
+		byElement = elementMatchers.length > 0,
+		superMatcher = function( seed, context, xml, results, outermost ) {
+			var elem, j, matcher,
+				matchedCount = 0,
+				i = "0",
+				unmatched = seed && [],
+				setMatched = [],
+				contextBackup = outermostContext,
+				// We must always have either seed elements or outermost context
+				elems = seed || byElement && Expr.find["TAG"]( "*", outermost ),
+				// Use integer dirruns iff this is the outermost matcher
+				dirrunsUnique = (dirruns += contextBackup == null ? 1 : Math.random() || 0.1),
+				len = elems.length;
+
+			if ( outermost ) {
+				outermostContext = context !== document && context;
+			}
+
+			// Add elements passing elementMatchers directly to results
+			// Keep `i` a string if there are no elements so `matchedCount` will be "00" below
+			// Support: IE<9, Safari
+			// Tolerate NodeList properties (IE: "length"; Safari: <number>) matching elements by id
+			for ( ; i !== len && (elem = elems[i]) != null; i++ ) {
+				if ( byElement && elem ) {
+					j = 0;
+					while ( (matcher = elementMatchers[j++]) ) {
+						if ( matcher( elem, context, xml ) ) {
+							results.push( elem );
+							break;
+						}
+					}
+					if ( outermost ) {
+						dirruns = dirrunsUnique;
+					}
+				}
+
+				// Track unmatched elements for set filters
+				if ( bySet ) {
+					// They will have gone through all possible matchers
+					if ( (elem = !matcher && elem) ) {
+						matchedCount--;
+					}
+
+					// Lengthen the array for every element, matched or not
+					if ( seed ) {
+						unmatched.push( elem );
+					}
+				}
+			}
+
+			// Apply set filters to unmatched elements
+			matchedCount += i;
+			if ( bySet && i !== matchedCount ) {
+				j = 0;
+				while ( (matcher = setMatchers[j++]) ) {
+					matcher( unmatched, setMatched, context, xml );
+				}
+
+				if ( seed ) {
+					// Reintegrate element matches to eliminate the need for sorting
+					if ( matchedCount > 0 ) {
+						while ( i-- ) {
+							if ( !(unmatched[i] || setMatched[i]) ) {
+								setMatched[i] = pop.call( results );
+							}
+						}
+					}
+
+					// Discard index placeholder values to get only actual matches
+					setMatched = condense( setMatched );
+				}
+
+				// Add matches to results
+				push.apply( results, setMatched );
+
+				// Seedless set matches succeeding multiple successful matchers stipulate sorting
+				if ( outermost && !seed && setMatched.length > 0 &&
+					( matchedCount + setMatchers.length ) > 1 ) {
+
+					Sizzle.uniqueSort( results );
+				}
+			}
+
+			// Override manipulation of globals by nested matchers
+			if ( outermost ) {
+				dirruns = dirrunsUnique;
+				outermostContext = contextBackup;
+			}
+
+			return unmatched;
+		};
+
+	return bySet ?
+		markFunction( superMatcher ) :
+		superMatcher;
+}
+
+compile = Sizzle.compile = function( selector, group /* Internal Use Only */ ) {
+	var i,
+		setMatchers = [],
+		elementMatchers = [],
+		cached = compilerCache[ selector + " " ];
+
+	if ( !cached ) {
+		// Generate a function of recursive functions that can be used to check each element
+		if ( !group ) {
+			group = tokenize( selector );
+		}
+		i = group.length;
+		while ( i-- ) {
+			cached = matcherFromTokens( group[i] );
+			if ( cached[ expando ] ) {
+				setMatchers.push( cached );
+			} else {
+				elementMatchers.push( cached );
+			}
+		}
+
+		// Cache the compiled function
+		cached = compilerCache( selector, matcherFromGroupMatchers( elementMatchers, setMatchers ) );
+	}
+	return cached;
+};
+
+function multipleContexts( selector, contexts, results ) {
+	var i = 0,
+		len = contexts.length;
+	for ( ; i < len; i++ ) {
+		Sizzle( selector, contexts[i], results );
+	}
+	return results;
+}
+
+function select( selector, context, results, seed ) {
+	var i, tokens, token, type, find,
+		match = tokenize( selector );
+
+	if ( !seed ) {
+		// Try to minimize operations if there is only one group
+		if ( match.length === 1 ) {
+
+			// Take a shortcut and set the context if the root selector is an ID
+			tokens = match[0] = match[0].slice( 0 );
+			if ( tokens.length > 2 && (token = tokens[0]).type === "ID" &&
+					support.getById && context.nodeType === 9 && documentIsHTML &&
+					Expr.relative[ tokens[1].type ] ) {
+
+				context = ( Expr.find["ID"]( token.matches[0].replace(runescape, funescape), context ) || [] )[0];
+				if ( !context ) {
+					return results;
+				}
+				selector = selector.slice( tokens.shift().value.length );
+			}
+
+			// Fetch a seed set for right-to-left matching
+			i = matchExpr["needsContext"].test( selector ) ? 0 : tokens.length;
+			while ( i-- ) {
+				token = tokens[i];
+
+				// Abort if we hit a combinator
+				if ( Expr.relative[ (type = token.type) ] ) {
+					break;
+				}
+				if ( (find = Expr.find[ type ]) ) {
+					// Search, expanding context for leading sibling combinators
+					if ( (seed = find(
+						token.matches[0].replace( runescape, funescape ),
+						rsibling.test( tokens[0].type ) && testContext( context.parentNode ) || context
+					)) ) {
+
+						// If seed is empty or no tokens remain, we can return early
+						tokens.splice( i, 1 );
+						selector = seed.length && toSelector( tokens );
+						if ( !selector ) {
+							push.apply( results, seed );
+							return results;
+						}
+
+						break;
+					}
+				}
+			}
+		}
+	}
+
+	// Compile and execute a filtering function
+	// Provide `match` to avoid retokenization if we modified the selector above
+	compile( selector, match )(
+		seed,
+		context,
+		!documentIsHTML,
+		results,
+		rsibling.test( selector ) && testContext( context.parentNode ) || context
+	);
+	return results;
+}
+
+// One-time assignments
+
+// Sort stability
+support.sortStable = expando.split("").sort( sortOrder ).join("") === expando;
+
+// Support: Chrome<14
+// Always assume duplicates if they aren't passed to the comparison function
+support.detectDuplicates = !!hasDuplicate;
+
+// Initialize against the default document
+setDocument();
+
+// Support: Webkit<537.32 - Safari 6.0.3/Chrome 25 (fixed in Chrome 27)
+// Detached nodes confoundingly follow *each other*
+support.sortDetached = assert(function( div1 ) {
+	// Should return 1, but returns 4 (following)
+	return div1.compareDocumentPosition( document.createElement("div") ) & 1;
+});
+
+// Support: IE<8
+// Prevent attribute/property "interpolation"
+// http://msdn.microsoft.com/en-us/library/ms536429%28VS.85%29.aspx
+if ( !assert(function( div ) {
+	div.innerHTML = "<a href='#'></a>";
+	return div.firstChild.getAttribute("href") === "#" ;
+}) ) {
+	addHandle( "type|href|height|width", function( elem, name, isXML ) {
+		if ( !isXML ) {
+			return elem.getAttribute( name, name.toLowerCase() === "type" ? 1 : 2 );
+		}
+	});
+}
+
+// Support: IE<9
+// Use defaultValue in place of getAttribute("value")
+if ( !support.attributes || !assert(function( div ) {
+	div.innerHTML = "<input/>";
+	div.firstChild.setAttribute( "value", "" );
+	return div.firstChild.getAttribute( "value" ) === "";
+}) ) {
+	addHandle( "value", function( elem, name, isXML ) {
+		if ( !isXML && elem.nodeName.toLowerCase() === "input" ) {
+			return elem.defaultValue;
+		}
+	});
+}
+
+// Support: IE<9
+// Use getAttributeNode to fetch booleans when getAttribute lies
+if ( !assert(function( div ) {
+	return div.getAttribute("disabled") == null;
+}) ) {
+	addHandle( booleans, function( elem, name, isXML ) {
+		var val;
+		if ( !isXML ) {
+			return elem[ name ] === true ? name.toLowerCase() :
+					(val = elem.getAttributeNode( name )) && val.specified ?
+					val.value :
+				null;
+		}
+	});
+}
+
+return Sizzle;
+
+})( window );
+
+
+
+jQuery.find = Sizzle;
+jQuery.expr = Sizzle.selectors;
+jQuery.expr[":"] = jQuery.expr.pseudos;
+jQuery.unique = Sizzle.uniqueSort;
+jQuery.text = Sizzle.getText;
+jQuery.isXMLDoc = Sizzle.isXML;
+jQuery.contains = Sizzle.contains;
+
+
+
+var rneedsContext = jQuery.expr.match.needsContext;
+
+var rsingleTag = (/^<(\w+)\s*\/?>(?:<\/\1>|)$/);
+
+
+
+var risSimple = /^.[^:#\[\.,]*$/;
+
+// Implement the identical functionality for filter and not
+function winnow( elements, qualifier, not ) {
+	if ( jQuery.isFunction( qualifier ) ) {
+		return jQuery.grep( elements, function( elem, i ) {
+			/* jshint -W018 */
+			return !!qualifier.call( elem, i, elem ) !== not;
+		});
+
+	}
+
+	if ( qualifier.nodeType ) {
+		return jQuery.grep( elements, function( elem ) {
+			return ( elem === qualifier ) !== not;
+		});
+
+	}
+
+	if ( typeof qualifier === "string" ) {
+		if ( risSimple.test( qualifier ) ) {
+			return jQuery.filter( qualifier, elements, not );
+		}
+
+		qualifier = jQuery.filter( qualifier, elements );
+	}
+
+	return jQuery.grep( elements, function( elem ) {
+		return ( indexOf.call( qualifier, elem ) >= 0 ) !== not;
+	});
+}
+
+jQuery.filter = function( expr, elems, not ) {
+	var elem = elems[ 0 ];
+
+	if ( not ) {
+		expr = ":not(" + expr + ")";
+	}
+
+	return elems.length === 1 && elem.nodeType === 1 ?
+		jQuery.find.matchesSelector( elem, expr ) ? [ elem ] : [] :
+		jQuery.find.matches( expr, jQuery.grep( elems, function( elem ) {
+			return elem.nodeType === 1;
+		}));
+};
+
+jQuery.fn.extend({
+	find: function( selector ) {
+		var i,
+			len = this.length,
+			ret = [],
+			self = this;
+
+		if ( typeof selector !== "string" ) {
+			return this.pushStack( jQuery( selector ).filter(function() {
+				for ( i = 0; i < len; i++ ) {
+					if ( jQuery.contains( self[ i ], this ) ) {
+						return true;
+					}
+				}
+			}) );
+		}
+
+		for ( i = 0; i < len; i++ ) {
+			jQuery.find( selector, self[ i ], ret );
+		}
+
+		// Needed because $( selector, context ) becomes $( context ).find( selector )
+		ret = this.pushStack( len > 1 ? jQuery.unique( ret ) : ret );
+		ret.selector = this.selector ? this.selector + " " + selector : selector;
+		return ret;
+	},
+	filter: function( selector ) {
+		return this.pushStack( winnow(this, selector || [], false) );
+	},
+	not: function( selector ) {
+		return this.pushStack( winnow(this, selector || [], true) );
+	},
+	is: function( selector ) {
+		return !!winnow(
+			this,
+
+			// If this is a positional/relative selector, check membership in the returned set
+			// so $("p:first").is("p:last") won't return true for a doc with two "p".
+			typeof selector === "string" && rneedsContext.test( selector ) ?
+				jQuery( selector ) :
+				selector || [],
+			false
+		).length;
+	}
+});
+
+
+// Initialize a jQuery object
+
+
+// A central reference to the root jQuery(document)
+var rootjQuery,
+
+	// A simple way to check for HTML strings
+	// Prioritize #id over <tag> to avoid XSS via location.hash (#9521)
+	// Strict HTML recognition (#11290: must start with <)
+	rquickExpr = /^(?:\s*(<[\w\W]+>)[^>]*|#([\w-]*))$/,
+
+	init = jQuery.fn.init = function( selector, context ) {
+		var match, elem;
+
+		// HANDLE: $(""), $(null), $(undefined), $(false)
+		if ( !selector ) {
+			return this;
+		}
+
+		// Handle HTML strings
+		if ( typeof selector === "string" ) {
+			if ( selector[0] === "<" && selector[ selector.length - 1 ] === ">" && selector.length >= 3 ) {
+				// Assume that strings that start and end with <> are HTML and skip the regex check
+				match = [ null, selector, null ];
+
+			} else {
+				match = rquickExpr.exec( selector );
+			}
+
+			// Match html or make sure no context is specified for #id
+			if ( match && (match[1] || !context) ) {
+
+				// HANDLE: $(html) -> $(array)
+				if ( match[1] ) {
+					context = context instanceof jQuery ? context[0] : context;
+
+					// scripts is true for back-compat
+					// Intentionally let the error be thrown if parseHTML is not present
+					jQuery.merge( this, jQuery.parseHTML(
+						match[1],
+						context && context.nodeType ? context.ownerDocument || context : document,
+						true
+					) );
+
+					// HANDLE: $(html, props)
+					if ( rsingleTag.test( match[1] ) && jQuery.isPlainObject( context ) ) {
+						for ( match in context ) {
+							// Properties of context are called as methods if possible
+							if ( jQuery.isFunction( this[ match ] ) ) {
+								this[ match ]( context[ match ] );
+
+							// ...and otherwise set as attributes
+							} else {
+								this.attr( match, context[ match ] );
+							}
+						}
+					}
+
+					return this;
+
+				// HANDLE: $(#id)
+				} else {
+					elem = document.getElementById( match[2] );
+
+					// Check parentNode to catch when Blackberry 4.6 returns
+					// nodes that are no longer in the document #6963
+					if ( elem && elem.parentNode ) {
+						// Inject the element directly into the jQuery object
+						this.length = 1;
+						this[0] = elem;
+					}
+
+					this.context = document;
+					this.selector = selector;
+					return this;
+				}
+
+			// HANDLE: $(expr, $(...))
+			} else if ( !context || context.jquery ) {
+				return ( context || rootjQuery ).find( selector );
+
+			// HANDLE: $(expr, context)
+			// (which is just equivalent to: $(context).find(expr)
+			} else {
+				return this.constructor( context ).find( selector );
+			}
+
+		// HANDLE: $(DOMElement)
+		} else if ( selector.nodeType ) {
+			this.context = this[0] = selector;
+			this.length = 1;
+			return this;
+
+		// HANDLE: $(function)
+		// Shortcut for document ready
+		} else if ( jQuery.isFunction( selector ) ) {
+			return typeof rootjQuery.ready !== "undefined" ?
+				rootjQuery.ready( selector ) :
+				// Execute immediately if ready is not present
+				selector( jQuery );
+		}
+
+		if ( selector.selector !== undefined ) {
+			this.selector = selector.selector;
+			this.context = selector.context;
+		}
+
+		return jQuery.makeArray( selector, this );
+	};
+
+// Give the init function the jQuery prototype for later instantiation
+init.prototype = jQuery.fn;
+
+// Initialize central reference
+rootjQuery = jQuery( document );
+
+
+var rparentsprev = /^(?:parents|prev(?:Until|All))/,
+	// methods guaranteed to produce a unique set when starting from a unique set
+	guaranteedUnique = {
+		children: true,
+		contents: true,
+		next: true,
+		prev: true
+	};
+
+jQuery.extend({
+	dir: function( elem, dir, until ) {
+		var matched = [],
+			truncate = until !== undefined;
+
+		while ( (elem = elem[ dir ]) && elem.nodeType !== 9 ) {
+			if ( elem.nodeType === 1 ) {
+				if ( truncate && jQuery( elem ).is( until ) ) {
+					break;
+				}
+				matched.push( elem );
+			}
+		}
+		return matched;
+	},
+
+	sibling: function( n, elem ) {
+		var matched = [];
+
+		for ( ; n; n = n.nextSibling ) {
+			if ( n.nodeType === 1 && n !== elem ) {
+				matched.push( n );
+			}
+		}
+
+		return matched;
+	}
+});
+
+jQuery.fn.extend({
+	has: function( target ) {
+		var targets = jQuery( target, this ),
+			l = targets.length;
+
+		return this.filter(function() {
+			var i = 0;
+			for ( ; i < l; i++ ) {
+				if ( jQuery.contains( this, targets[i] ) ) {
+					return true;
+				}
+			}
+		});
+	},
+
+	closest: function( selectors, context ) {
+		var cur,
+			i = 0,
+			l = this.length,
+			matched = [],
+			pos = rneedsContext.test( selectors ) || typeof selectors !== "string" ?
+				jQuery( selectors, context || this.context ) :
+				0;
+
+		for ( ; i < l; i++ ) {
+			for ( cur = this[i]; cur && cur !== context; cur = cur.parentNode ) {
+				// Always skip document fragments
+				if ( cur.nodeType < 11 && (pos ?
+					pos.index(cur) > -1 :
+
+					// Don't pass non-elements to Sizzle
+					cur.nodeType === 1 &&
+						jQuery.find.matchesSelector(cur, selectors)) ) {
+
+					matched.push( cur );
+					break;
+				}
+			}
+		}
+
+		return this.pushStack( matched.length > 1 ? jQuery.unique( matched ) : matched );
+	},
+
+	// Determine the position of an element within
+	// the matched set of elements
+	index: function( elem ) {
+
+		// No argument, return index in parent
+		if ( !elem ) {
+			return ( this[ 0 ] && this[ 0 ].parentNode ) ? this.first().prevAll().length : -1;
+		}
+
+		// index in selector
+		if ( typeof elem === "string" ) {
+			return indexOf.call( jQuery( elem ), this[ 0 ] );
+		}
+
+		// Locate the position of the desired element
+		return indexOf.call( this,
+
+			// If it receives a jQuery object, the first element is used
+			elem.jquery ? elem[ 0 ] : elem
+		);
+	},
+
+	add: function( selector, context ) {
+		return this.pushStack(
+			jQuery.unique(
+				jQuery.merge( this.get(), jQuery( selector, context ) )
+			)
+		);
+	},
+
+	addBack: function( selector ) {
+		return this.add( selector == null ?
+			this.prevObject : this.prevObject.filter(selector)
+		);
+	}
+});
+
+function sibling( cur, dir ) {
+	while ( (cur = cur[dir]) && cur.nodeType !== 1 ) {}
+	return cur;
+}
+
+jQuery.each({
+	parent: function( elem ) {
+		var parent = elem.parentNode;
+		return parent && parent.nodeType !== 11 ? parent : null;
+	},
+	parents: function( elem ) {
+		return jQuery.dir( elem, "parentNode" );
+	},
+	parentsUntil: function( elem, i, until ) {
+		return jQuery.dir( elem, "parentNode", until );
+	},
+	next: function( elem ) {
+		return sibling( elem, "nextSibling" );
+	},
+	prev: function( elem ) {
+		return sibling( elem, "previousSibling" );
+	},
+	nextAll: function( elem ) {
+		return jQuery.dir( elem, "nextSibling" );
+	},
+	prevAll: function( elem ) {
+		return jQuery.dir( elem, "previousSibling" );
+	},
+	nextUntil: function( elem, i, until ) {
+		return jQuery.dir( elem, "nextSibling", until );
+	},
+	prevUntil: function( elem, i, until ) {
+		return jQuery.dir( elem, "previousSibling", until );
+	},
+	siblings: function( elem ) {
+		return jQuery.sibling( ( elem.parentNode || {} ).firstChild, elem );
+	},
+	children: function( elem ) {
+		return jQuery.sibling( elem.firstChild );
+	},
+	contents: function( elem ) {
+		return elem.contentDocument || jQuery.merge( [], elem.childNodes );
+	}
+}, function( name, fn ) {
+	jQuery.fn[ name ] = function( until, selector ) {
+		var matched = jQuery.map( this, fn, until );
+
+		if ( name.slice( -5 ) !== "Until" ) {
+			selector = until;
+		}
+
+		if ( selector && typeof selector === "string" ) {
+			matched = jQuery.filter( selector, matched );
+		}
+
+		if ( this.length > 1 ) {
+			// Remove duplicates
+			if ( !guaranteedUnique[ name ] ) {
+				jQuery.unique( matched );
+			}
+
+			// Reverse order for parents* and prev-derivatives
+			if ( rparentsprev.test( name ) ) {
+				matched.reverse();
+			}
+		}
+
+		return this.pushStack( matched );
+	};
+});
+var rnotwhite = (/\S+/g);
+
+
+
+// String to Object options format cache
+var optionsCache = {};
+
+// Convert String-formatted options into Object-formatted ones and store in cache
+function createOptions( options ) {
+	var object = optionsCache[ options ] = {};
+	jQuery.each( options.match( rnotwhite ) || [], function( _, flag ) {
+		object[ flag ] = true;
+	});
+	return object;
+}
+
+/*
+ * Create a callback list using the following parameters:
+ *
+ *	options: an optional list of space-separated options that will change how
+ *			the callback list behaves or a more traditional option object
+ *
+ * By default a callback list will act like an event callback list and can be
+ * "fired" multiple times.
+ *
+ * Possible options:
+ *
+ *	once:			will ensure the callback list can only be fired once (like a Deferred)
+ *
+ *	memory:			will keep track of previous values and will call any callback added
+ *					after the list has been fired right away with the latest "memorized"
+ *					values (like a Deferred)
+ *
+ *	unique:			will ensure a callback can only be added once (no duplicate in the list)
+ *
+ *	stopOnFalse:	interrupt callings when a callback returns false
+ *
+ */
+jQuery.Callbacks = function( options ) {
+
+	// Convert options from String-formatted to Object-formatted if needed
+	// (we check in cache first)
+	options = typeof options === "string" ?
+		( optionsCache[ options ] || createOptions( options ) ) :
+		jQuery.extend( {}, options );
+
+	var // Last fire value (for non-forgettable lists)
+		memory,
+		// Flag to know if list was already fired
+		fired,
+		// Flag to know if list is currently firing
+		firing,
+		// First callback to fire (used internally by add and fireWith)
+		firingStart,
+		// End of the loop when firing
+		firingLength,
+		// Index of currently firing callback (modified by remove if needed)
+		firingIndex,
+		// Actual callback list
+		list = [],
+		// Stack of fire calls for repeatable lists
+		stack = !options.once && [],
+		// Fire callbacks
+		fire = function( data ) {
+			memory = options.memory && data;
+			fired = true;
+			firingIndex = firingStart || 0;
+			firingStart = 0;
+			firingLength = list.length;
+			firing = true;
+			for ( ; list && firingIndex < firingLength; firingIndex++ ) {
+				if ( list[ firingIndex ].apply( data[ 0 ], data[ 1 ] ) === false && options.stopOnFalse ) {
+					memory = false; // To prevent further calls using add
+					break;
+				}
+			}
+			firing = false;
+			if ( list ) {
+				if ( stack ) {
+					if ( stack.length ) {
+						fire( stack.shift() );
+					}
+				} else if ( memory ) {
+					list = [];
+				} else {
+					self.disable();
+				}
+			}
+		},
+		// Actual Callbacks object
+		self = {
+			// Add a callback or a collection of callbacks to the list
+			add: function() {
+				if ( list ) {
+					// First, we save the current length
+					var start = list.length;
+					(function add( args ) {
+						jQuery.each( args, function( _, arg ) {
+							var type = jQuery.type( arg );
+							if ( type === "function" ) {
+								if ( !options.unique || !self.has( arg ) ) {
+									list.push( arg );
+								}
+							} else if ( arg && arg.length && type !== "string" ) {
+								// Inspect recursively
+								add( arg );
+							}
+						});
+					})( arguments );
+					// Do we need to add the callbacks to the
+					// current firing batch?
+					if ( firing ) {
+						firingLength = list.length;
+					// With memory, if we're not firing then
+					// we should call right away
+					} else if ( memory ) {
+						firingStart = start;
+						fire( memory );
+					}
+				}
+				return this;
+			},
+			// Remove a callback from the list
+			remove: function() {
+				if ( list ) {
+					jQuery.each( arguments, function( _, arg ) {
+						var index;
+						while ( ( index = jQuery.inArray( arg, list, index ) ) > -1 ) {
+							list.splice( index, 1 );
+							// Handle firing indexes
+							if ( firing ) {
+								if ( index <= firingLength ) {
+									firingLength--;
+								}
+								if ( index <= firingIndex ) {
+									firingIndex--;
+								}
+							}
+						}
+					});
+				}
+				return this;
+			},
+			// Check if a given callback is in the list.
+			// If no argument is given, return whether or not list has callbacks attached.
+			has: function( fn ) {
+				return fn ? jQuery.inArray( fn, list ) > -1 : !!( list && list.length );
+			},
+			// Remove all callbacks from the list
+			empty: function() {
+				list = [];
+				firingLength = 0;
+				return this;
+			},
+			// Have the list do nothing anymore
+			disable: function() {
+				list = stack = memory = undefined;
+				return this;
+			},
+			// Is it disabled?
+			disabled: function() {
+				return !list;
+			},
+			// Lock the list in its current state
+			lock: function() {
+				stack = undefined;
+				if ( !memory ) {
+					self.disable();
+				}
+				return this;
+			},
+			// Is it locked?
+			locked: function() {
+				return !stack;
+			},
+			// Call all callbacks with the given context and arguments
+			fireWith: function( context, args ) {
+				if ( list && ( !fired || stack ) ) {
+					args = args || [];
+					args = [ context, args.slice ? args.slice() : args ];
+					if ( firing ) {
+						stack.push( args );
+					} else {
+						fire( args );
+					}
+				}
+				return this;
+			},
+			// Call all the callbacks with the given arguments
+			fire: function() {
+				self.fireWith( this, arguments );
+				return this;
+			},
+			// To know if the callbacks have already been called at least once
+			fired: function() {
+				return !!fired;
+			}
+		};
+
+	return self;
+};
+
+
+jQuery.extend({
+
+	Deferred: function( func ) {
+		var tuples = [
+				// action, add listener, listener list, final state
+				[ "resolve", "done", jQuery.Callbacks("once memory"), "resolved" ],
+				[ "reject", "fail", jQuery.Callbacks("once memory"), "rejected" ],
+				[ "notify", "progress", jQuery.Callbacks("memory") ]
+			],
+			state = "pending",
+			promise = {
+				state: function() {
+					return state;
+				},
+				always: function() {
+					deferred.done( arguments ).fail( arguments );
+					return this;
+				},
+				then: function( /* fnDone, fnFail, fnProgress */ ) {
+					var fns = arguments;
+					return jQuery.Deferred(function( newDefer ) {
+						jQuery.each( tuples, function( i, tuple ) {
+							var fn = jQuery.isFunction( fns[ i ] ) && fns[ i ];
+							// deferred[ done | fail | progress ] for forwarding actions to newDefer
+							deferred[ tuple[1] ](function() {
+								var returned = fn && fn.apply( this, arguments );
+								if ( returned && jQuery.isFunction( returned.promise ) ) {
+									returned.promise()
+										.done( newDefer.resolve )
+										.fail( newDefer.reject )
+										.progress( newDefer.notify );
+								} else {
+									newDefer[ tuple[ 0 ] + "With" ]( this === promise ? newDefer.promise() : this, fn ? [ returned ] : arguments );
+								}
+							});
+						});
+						fns = null;
+					}).promise();
+				},
+				// Get a promise for this deferred
+				// If obj is provided, the promise aspect is added to the object
+				promise: function( obj ) {
+					return obj != null ? jQuery.extend( obj, promise ) : promise;
+				}
+			},
+			deferred = {};
+
+		// Keep pipe for back-compat
+		promise.pipe = promise.then;
+
+		// Add list-specific methods
+		jQuery.each( tuples, function( i, tuple ) {
+			var list = tuple[ 2 ],
+				stateString = tuple[ 3 ];
+
+			// promise[ done | fail | progress ] = list.add
+			promise[ tuple[1] ] = list.add;
+
+			// Handle state
+			if ( stateString ) {
+				list.add(function() {
+					// state = [ resolved | rejected ]
+					state = stateString;
+
+				// [ reject_list | resolve_list ].disable; progress_list.lock
+				}, tuples[ i ^ 1 ][ 2 ].disable, tuples[ 2 ][ 2 ].lock );
+			}
+
+			// deferred[ resolve | reject | notify ]
+			deferred[ tuple[0] ] = function() {
+				deferred[ tuple[0] + "With" ]( this === deferred ? promise : this, arguments );
+				return this;
+			};
+			deferred[ tuple[0] + "With" ] = list.fireWith;
+		});
+
+		// Make the deferred a promise
+		promise.promise( deferred );
+
+		// Call given func if any
+		if ( func ) {
+			func.call( deferred, deferred );
+		}
+
+		// All done!
+		return deferred;
+	},
+
+	// Deferred helper
+	when: function( subordinate /* , ..., subordinateN */ ) {
+		var i = 0,
+			resolveValues = slice.call( arguments ),
+			length = resolveValues.length,
+
+			// the count of uncompleted subordinates
+			remaining = length !== 1 || ( subordinate && jQuery.isFunction( subordinate.promise ) ) ? length : 0,
+
+			// the master Deferred. If resolveValues consist of only a single Deferred, just use that.
+			deferred = remaining === 1 ? subordinate : jQuery.Deferred(),
+
+			// Update function for both resolve and progress values
+			updateFunc = function( i, contexts, values ) {
+				return function( value ) {
+					contexts[ i ] = this;
+					values[ i ] = arguments.length > 1 ? slice.call( arguments ) : value;
+					if ( values === progressValues ) {
+						deferred.notifyWith( contexts, values );
+					} else if ( !( --remaining ) ) {
+						deferred.resolveWith( contexts, values );
+					}
+				};
+			},
+
+			progressValues, progressContexts, resolveContexts;
+
+		// add listeners to Deferred subordinates; treat others as resolved
+		if ( length > 1 ) {
+			progressValues = new Array( length );
+			progressContexts = new Array( length );
+			resolveContexts = new Array( length );
+			for ( ; i < length; i++ ) {
+				if ( resolveValues[ i ] && jQuery.isFunction( resolveValues[ i ].promise ) ) {
+					resolveValues[ i ].promise()
+						.done( updateFunc( i, resolveContexts, resolveValues ) )
+						.fail( deferred.reject )
+						.progress( updateFunc( i, progressContexts, progressValues ) );
+				} else {
+					--remaining;
+				}
+			}
+		}
+
+		// if we're not waiting on anything, resolve the master
+		if ( !remaining ) {
+			deferred.resolveWith( resolveContexts, resolveValues );
+		}
+
+		return deferred.promise();
+	}
+});
+
+
+// The deferred used on DOM ready
+var readyList;
+
+jQuery.fn.ready = function( fn ) {
+	// Add the callback
+	jQuery.ready.promise().done( fn );
+
+	return this;
+};
+
+jQuery.extend({
+	// Is the DOM ready to be used? Set to true once it occurs.
+	isReady: false,
+
+	// A counter to track how many items to wait for before
+	// the ready event fires. See #6781
+	readyWait: 1,
+
+	// Hold (or release) the ready event
+	holdReady: function( hold ) {
+		if ( hold ) {
+			jQuery.readyWait++;
+		} else {
+			jQuery.ready( true );
+		}
+	},
+
+	// Handle when the DOM is ready
+	ready: function( wait ) {
+
+		// Abort if there are pending holds or we're already ready
+		if ( wait === true ? --jQuery.readyWait : jQuery.isReady ) {
+			return;
+		}
+
+		// Remember that the DOM is ready
+		jQuery.isReady = true;
+
+		// If a normal DOM Ready event fired, decrement, and wait if need be
+		if ( wait !== true && --jQuery.readyWait > 0 ) {
+			return;
+		}
+
+		// If there are functions bound, to execute
+		readyList.resolveWith( document, [ jQuery ] );
+
+		// Trigger any bound ready events
+		if ( jQuery.fn.trigger ) {
+			jQuery( document ).trigger("ready").off("ready");
+		}
+	}
+});
+
+/**
+ * The ready event handler and self cleanup method
+ */
+function completed() {
+	document.removeEventListener( "DOMContentLoaded", completed, false );
+	window.removeEventListener( "load", completed, false );
+	jQuery.ready();
+}
+
+jQuery.ready.promise = function( obj ) {
+	if ( !readyList ) {
+
+		readyList = jQuery.Deferred();
+
+		// Catch cases where $(document).ready() is called after the browser event has already occurred.
+		// we once tried to use readyState "interactive" here, but it caused issues like the one
+		// discovered by ChrisS here: http://bugs.jquery.com/ticket/12282#comment:15
+		if ( document.readyState === "complete" ) {
+			// Handle it asynchronously to allow scripts the opportunity to delay ready
+			setTimeout( jQuery.ready );
+
+		} else {
+
+			// Use the handy event callback
+			document.addEventListener( "DOMContentLoaded", completed, false );
+
+			// A fallback to window.onload, that will always work
+			window.addEventListener( "load", completed, false );
+		}
+	}
+	return readyList.promise( obj );
+};
+
+// Kick off the DOM ready check even if the user does not
+jQuery.ready.promise();
+
+
+
+
+// Multifunctional method to get and set values of a collection
+// The value/s can optionally be executed if it's a function
+var access = jQuery.access = function( elems, fn, key, value, chainable, emptyGet, raw ) {
+	var i = 0,
+		len = elems.length,
+		bulk = key == null;
+
+	// Sets many values
+	if ( jQuery.type( key ) === "object" ) {
+		chainable = true;
+		for ( i in key ) {
+			jQuery.access( elems, fn, i, key[i], true, emptyGet, raw );
+		}
+
+	// Sets one value
+	} else if ( value !== undefined ) {
+		chainable = true;
+
+		if ( !jQuery.isFunction( value ) ) {
+			raw = true;
+		}
+
+		if ( bulk ) {
+			// Bulk operations run against the entire set
+			if ( raw ) {
+				fn.call( elems, value );
+				fn = null;
+
+			// ...except when executing function values
+			} else {
+				bulk = fn;
+				fn = function( elem, key, value ) {
+					return bulk.call( jQuery( elem ), value );
+				};
+			}
+		}
+
+		if ( fn ) {
+			for ( ; i < len; i++ ) {
+				fn( elems[i], key, raw ? value : value.call( elems[i], i, fn( elems[i], key ) ) );
+			}
+		}
+	}
+
+	return chainable ?
+		elems :
+
+		// Gets
+		bulk ?
+			fn.call( elems ) :
+			len ? fn( elems[0], key ) : emptyGet;
+};
+
+
+/**
+ * Determines whether an object can have data
+ */
+jQuery.acceptData = function( owner ) {
+	// Accepts only:
+	//  - Node
+	//    - Node.ELEMENT_NODE
+	//    - Node.DOCUMENT_NODE
+	//  - Object
+	//    - Any
+	/* jshint -W018 */
+	return owner.nodeType === 1 || owner.nodeType === 9 || !( +owner.nodeType );
+};
+
+
+function Data() {
+	// Support: Android < 4,
+	// Old WebKit does not have Object.preventExtensions/freeze method,
+	// return new empty object instead with no [[set]] accessor
+	Object.defineProperty( this.cache = {}, 0, {
+		get: function() {
+			return {};
+		}
+	});
+
+	this.expando = jQuery.expando + Math.random();
+}
+
+Data.uid = 1;
+Data.accepts = jQuery.acceptData;
+
+Data.prototype = {
+	key: function( owner ) {
+		// We can accept data for non-element nodes in modern browsers,
+		// but we should not, see #8335.
+		// Always return the key for a frozen object.
+		if ( !Data.accepts( owner ) ) {
+			return 0;
+		}
+
+		var descriptor = {},
+			// Check if the owner object already has a cache key
+			unlock = owner[ this.expando ];
+
+		// If not, create one
+		if ( !unlock ) {
+			unlock = Data.uid++;
+
+			// Secure it in a non-enumerable, non-writable property
+			try {
+				descriptor[ this.expando ] = { value: unlock };
+				Object.defineProperties( owner, descriptor );
+
+			// Support: Android < 4
+			// Fallback to a less secure definition
+			} catch ( e ) {
+				descriptor[ this.expando ] = unlock;
+				jQuery.extend( owner, descriptor );
+			}
+		}
+
+		// Ensure the cache object
+		if ( !this.cache[ unlock ] ) {
+			this.cache[ unlock ] = {};
+		}
+
+		return unlock;
+	},
+	set: function( owner, data, value ) {
+		var prop,
+			// There may be an unlock assigned to this node,
+			// if there is no entry for this "owner", create one inline
+			// and set the unlock as though an owner entry had always existed
+			unlock = this.key( owner ),
+			cache = this.cache[ unlock ];
+
+		// Handle: [ owner, key, value ] args
+		if ( typeof data === "string" ) {
+			cache[ data ] = value;
+
+		// Handle: [ owner, { properties } ] args
+		} else {
+			// Fresh assignments by object are shallow copied
+			if ( jQuery.isEmptyObject( cache ) ) {
+				jQuery.extend( this.cache[ unlock ], data );
+			// Otherwise, copy the properties one-by-one to the cache object
+			} else {
+				for ( prop in data ) {
+					cache[ prop ] = data[ prop ];
+				}
+			}
+		}
+		return cache;
+	},
+	get: function( owner, key ) {
+		// Either a valid cache is found, or will be created.
+		// New caches will be created and the unlock returned,
+		// allowing direct access to the newly created
+		// empty data object. A valid owner object must be provided.
+		var cache = this.cache[ this.key( owner ) ];
+
+		return key === undefined ?
+			cache : cache[ key ];
+	},
+	access: function( owner, key, value ) {
+		var stored;
+		// In cases where either:
+		//
+		//   1. No key was specified
+		//   2. A string key was specified, but no value provided
+		//
+		// Take the "read" path and allow the get method to determine
+		// which value to return, respectively either:
+		//
+		//   1. The entire cache object
+		//   2. The data stored at the key
+		//
+		if ( key === undefined ||
+				((key && typeof key === "string") && value === undefined) ) {
+
+			stored = this.get( owner, key );
+
+			return stored !== undefined ?
+				stored : this.get( owner, jQuery.camelCase(key) );
+		}
+
+		// [*]When the key is not a string, or both a key and value
+		// are specified, set or extend (existing objects) with either:
+		//
+		//   1. An object of properties
+		//   2. A key and value
+		//
+		this.set( owner, key, value );
+
+		// Since the "set" path can have two possible entry points
+		// return the expected data based on which path was taken[*]
+		return value !== undefined ? value : key;
+	},
+	remove: function( owner, key ) {
+		var i, name, camel,
+			unlock = this.key( owner ),
+			cache = this.cache[ unlock ];
+
+		if ( key === undefined ) {
+			this.cache[ unlock ] = {};
+
+		} else {
+			// Support array or space separated string of keys
+			if ( jQuery.isArray( key ) ) {
+				// If "name" is an array of keys...
+				// When data is initially created, via ("key", "val") signature,
+				// keys will be converted to camelCase.
+				// Since there is no way to tell _how_ a key was added, remove
+				// both plain key and camelCase key. #12786
+				// This will only penalize the array argument path.
+				name = key.concat( key.map( jQuery.camelCase ) );
+			} else {
+				camel = jQuery.camelCase( key );
+				// Try the string as a key before any manipulation
+				if ( key in cache ) {
+					name = [ key, camel ];
+				} else {
+					// If a key with the spaces exists, use it.
+					// Otherwise, create an array by matching non-whitespace
+					name = camel;
+					name = name in cache ?
+						[ name ] : ( name.match( rnotwhite ) || [] );
+				}
+			}
+
+			i = name.length;
+			while ( i-- ) {
+				delete cache[ name[ i ] ];
+			}
+		}
+	},
+	hasData: function( owner ) {
+		return !jQuery.isEmptyObject(
+			this.cache[ owner[ this.expando ] ] || {}
+		);
+	},
+	discard: function( owner ) {
+		if ( owner[ this.expando ] ) {
+			delete this.cache[ owner[ this.expando ] ];
+		}
+	}
+};
+var data_priv = new Data();
+
+var data_user = new Data();
+
+
+
+/*
+	Implementation Summary
+
+	1. Enforce API surface and semantic compatibility with 1.9.x branch
+	2. Improve the module's maintainability by reducing the storage
+		paths to a single mechanism.
+	3. Use the same single mechanism to support "private" and "user" data.
+	4. _Never_ expose "private" data to user code (TODO: Drop _data, _removeData)
+	5. Avoid exposing implementation details on user objects (eg. expando properties)
+	6. Provide a clear path for implementation upgrade to WeakMap in 2014
+*/
+var rbrace = /^(?:\{[\w\W]*\}|\[[\w\W]*\])$/,
+	rmultiDash = /([A-Z])/g;
+
+function dataAttr( elem, key, data ) {
+	var name;
+
+	// If nothing was found internally, try to fetch any
+	// data from the HTML5 data-* attribute
+	if ( data === undefined && elem.nodeType === 1 ) {
+		name = "data-" + key.replace( rmultiDash, "-$1" ).toLowerCase();
+		data = elem.getAttribute( name );
+
+		if ( typeof data === "string" ) {
+			try {
+				data = data === "true" ? true :
+					data === "false" ? false :
+					data === "null" ? null :
+					// Only convert to a number if it doesn't change the string
+					+data + "" === data ? +data :
+					rbrace.test( data ) ? jQuery.parseJSON( data ) :
+					data;
+			} catch( e ) {}
+
+			// Make sure we set the data so it isn't changed later
+			data_user.set( elem, key, data );
+		} else {
+			data = undefined;
+		}
+	}
+	return data;
+}
+
+jQuery.extend({
+	hasData: function( elem ) {
+		return data_user.hasData( elem ) || data_priv.hasData( elem );
+	},
+
+	data: function( elem, name, data ) {
+		return data_user.access( elem, name, data );
+	},
+
+	removeData: function( elem, name ) {
+		data_user.remove( elem, name );
+	},
+
+	// TODO: Now that all calls to _data and _removeData have been replaced
+	// with direct calls to data_priv methods, these can be deprecated.
+	_data: function( elem, name, data ) {
+		return data_priv.access( elem, name, data );
+	},
+
+	_removeData: function( elem, name ) {
+		data_priv.remove( elem, name );
+	}
+});
+
+jQuery.fn.extend({
+	data: function( key, value ) {
+		var i, name, data,
+			elem = this[ 0 ],
+			attrs = elem && elem.attributes;
+
+		// Gets all values
+		if ( key === undefined ) {
+			if ( this.length ) {
+				data = data_user.get( elem );
+
+				if ( elem.nodeType === 1 && !data_priv.get( elem, "hasDataAttrs" ) ) {
+					i = attrs.length;
+					while ( i-- ) {
+						name = attrs[ i ].name;
+
+						if ( name.indexOf( "data-" ) === 0 ) {
+							name = jQuery.camelCase( name.slice(5) );
+							dataAttr( elem, name, data[ name ] );
+						}
+					}
+					data_priv.set( elem, "hasDataAttrs", true );
+				}
+			}
+
+			return data;
+		}
+
+		// Sets multiple values
+		if ( typeof key === "object" ) {
+			return this.each(function() {
+				data_user.set( this, key );
+			});
+		}
+
+		return access( this, function( value ) {
+			var data,
+				camelKey = jQuery.camelCase( key );
+
+			// The calling jQuery object (element matches) is not empty
+			// (and therefore has an element appears at this[ 0 ]) and the
+			// `value` parameter was not undefined. An empty jQuery object
+			// will result in `undefined` for elem = this[ 0 ] which will
+			// throw an exception if an attempt to read a data cache is made.
+			if ( elem && value === undefined ) {
+				// Attempt to get data from the cache
+				// with the key as-is
+				data = data_user.get( elem, key );
+				if ( data !== undefined ) {
+					return data;
+				}
+
+				// Attempt to get data from the cache
+				// with the key camelized
+				data = data_user.get( elem, camelKey );
+				if ( data !== undefined ) {
+					return data;
+				}
+
+				// Attempt to "discover" the data in
+				// HTML5 custom data-* attrs
+				data = dataAttr( elem, camelKey, undefined );
+				if ( data !== undefined ) {
+					return data;
+				}
+
+				// We tried really hard, but the data doesn't exist.
+				return;
+			}
+
+			// Set the data...
+			this.each(function() {
+				// First, attempt to store a copy or reference of any
+				// data that might've been store with a camelCased key.
+				var data = data_user.get( this, camelKey );
+
+				// For HTML5 data-* attribute interop, we have to
+				// store property names with dashes in a camelCase form.
+				// This might not apply to all properties...*
+				data_user.set( this, camelKey, value );
+
+				// *... In the case of properties that might _actually_
+				// have dashes, we need to also store a copy of that
+				// unchanged property.
+				if ( key.indexOf("-") !== -1 && data !== undefined ) {
+					data_user.set( this, key, value );
+				}
+			});
+		}, null, value, arguments.length > 1, null, true );
+	},
+
+	removeData: function( key ) {
+		return this.each(function() {
+			data_user.remove( this, key );
+		});
+	}
+});
+
+
+jQuery.extend({
+	queue: function( elem, type, data ) {
+		var queue;
+
+		if ( elem ) {
+			type = ( type || "fx" ) + "queue";
+			queue = data_priv.get( elem, type );
+
+			// Speed up dequeue by getting out quickly if this is just a lookup
+			if ( data ) {
+				if ( !queue || jQuery.isArray( data ) ) {
+					queue = data_priv.access( elem, type, jQuery.makeArray(data) );
+				} else {
+					queue.push( data );
+				}
+			}
+			return queue || [];
+		}
+	},
+
+	dequeue: function( elem, type ) {
+		type = type || "fx";
+
+		var queue = jQuery.queue( elem, type ),
+			startLength = queue.length,
+			fn = queue.shift(),
+			hooks = jQuery._queueHooks( elem, type ),
+			next = function() {
+				jQuery.dequeue( elem, type );
+			};
+
+		// If the fx queue is dequeued, always remove the progress sentinel
+		if ( fn === "inprogress" ) {
+			fn = queue.shift();
+			startLength--;
+		}
+
+		if ( fn ) {
+
+			// Add a progress sentinel to prevent the fx queue from being
+			// automatically dequeued
+			if ( type === "fx" ) {
+				queue.unshift( "inprogress" );
+			}
+
+			// clear up the last queue stop function
+			delete hooks.stop;
+			fn.call( elem, next, hooks );
+		}
+
+		if ( !startLength && hooks ) {
+			hooks.empty.fire();
+		}
+	},
+
+	// not intended for public consumption - generates a queueHooks object, or returns the current one
+	_queueHooks: function( elem, type ) {
+		var key = type + "queueHooks";
+		return data_priv.get( elem, key ) || data_priv.access( elem, key, {
+			empty: jQuery.Callbacks("once memory").add(function() {
+				data_priv.remove( elem, [ type + "queue", key ] );
+			})
+		});
+	}
+});
+
+jQuery.fn.extend({
+	queue: function( type, data ) {
+		var setter = 2;
+
+		if ( typeof type !== "string" ) {
+			data = type;
+			type = "fx";
+			setter--;
+		}
+
+		if ( arguments.length < setter ) {
+			return jQuery.queue( this[0], type );
+		}
+
+		return data === undefined ?
+			this :
+			this.each(function() {
+				var queue = jQuery.queue( this, type, data );
+
+				// ensure a hooks for this queue
+				jQuery._queueHooks( this, type );
+
+				if ( type === "fx" && queue[0] !== "inprogress" ) {
+					jQuery.dequeue( this, type );
+				}
+			});
+	},
+	dequeue: function( type ) {
+		return this.each(function() {
+			jQuery.dequeue( this, type );
+		});
+	},
+	clearQueue: function( type ) {
+		return this.queue( type || "fx", [] );
+	},
+	// Get a promise resolved when queues of a certain type
+	// are emptied (fx is the type by default)
+	promise: function( type, obj ) {
+		var tmp,
+			count = 1,
+			defer = jQuery.Deferred(),
+			elements = this,
+			i = this.length,
+			resolve = function() {
+				if ( !( --count ) ) {
+					defer.resolveWith( elements, [ elements ] );
+				}
+			};
+
+		if ( typeof type !== "string" ) {
+			obj = type;
+			type = undefined;
+		}
+		type = type || "fx";
+
+		while ( i-- ) {
+			tmp = data_priv.get( elements[ i ], type + "queueHooks" );
+			if ( tmp && tmp.empty ) {
+				count++;
+				tmp.empty.add( resolve );
+			}
+		}
+		resolve();
+		return defer.promise( obj );
+	}
+});
+var pnum = (/[+-]?(?:\d*\.|)\d+(?:[eE][+-]?\d+|)/).source;
+
+var cssExpand = [ "Top", "Right", "Bottom", "Left" ];
+
+var isHidden = function( elem, el ) {
+		// isHidden might be called from jQuery#filter function;
+		// in that case, element will be second argument
+		elem = el || elem;
+		return jQuery.css( elem, "display" ) === "none" || !jQuery.contains( elem.ownerDocument, elem );
+	};
+
+var rcheckableType = (/^(?:checkbox|radio)$/i);
+
+
+
+(function() {
+	var fragment = document.createDocumentFragment(),
+		div = fragment.appendChild( document.createElement( "div" ) );
+
+	// #11217 - WebKit loses check when the name is after the checked attribute
+	div.innerHTML = "<input type='radio' checked='checked' name='t'/>";
+
+	// Support: Safari 5.1, iOS 5.1, Android 4.x, Android 2.3
+	// old WebKit doesn't clone checked state correctly in fragments
+	support.checkClone = div.cloneNode( true ).cloneNode( true ).lastChild.checked;
+
+	// Make sure textarea (and checkbox) defaultValue is properly cloned
+	// Support: IE9-IE11+
+	div.innerHTML = "<textarea>x</textarea>";
+	support.noCloneChecked = !!div.cloneNode( true ).lastChild.defaultValue;
+})();
+var strundefined = typeof undefined;
+
+
+
+support.focusinBubbles = "onfocusin" in window;
+
+
+var
+	rkeyEvent = /^key/,
+	rmouseEvent = /^(?:mouse|contextmenu)|click/,
+	rfocusMorph = /^(?:focusinfocus|focusoutblur)$/,
+	rtypenamespace = /^([^.]*)(?:\.(.+)|)$/;
+
+function returnTrue() {
+	return true;
+}
+
+function returnFalse() {
+	return false;
+}
+
+function safeActiveElement() {
+	try {
+		return document.activeElement;
+	} catch ( err ) { }
+}
+
+/*
+ * Helper functions for managing events -- not part of the public interface.
+ * Props to Dean Edwards' addEvent library for many of the ideas.
+ */
+jQuery.event = {
+
+	global: {},
+
+	add: function( elem, types, handler, data, selector ) {
+
+		var handleObjIn, eventHandle, tmp,
+			events, t, handleObj,
+			special, handlers, type, namespaces, origType,
+			elemData = data_priv.get( elem );
+
+		// Don't attach events to noData or text/comment nodes (but allow plain objects)
+		if ( !elemData ) {
+			return;
+		}
+
+		// Caller can pass in an object of custom data in lieu of the handler
+		if ( handler.handler ) {
+			handleObjIn = handler;
+			handler = handleObjIn.handler;
+			selector = handleObjIn.selector;
+		}
+
+		// Make sure that the handler has a unique ID, used to find/remove it later
+		if ( !handler.guid ) {
+			handler.guid = jQuery.guid++;
+		}
+
+		// Init the element's event structure and main handler, if this is the first
+		if ( !(events = elemData.events) ) {
+			events = elemData.events = {};
+		}
+		if ( !(eventHandle = elemData.handle) ) {
+			eventHandle = elemData.handle = function( e ) {
+				// Discard the second event of a jQuery.event.trigger() and
+				// when an event is called after a page has unloaded
+				return typeof jQuery !== strundefined && jQuery.event.triggered !== e.type ?
+					jQuery.event.dispatch.apply( elem, arguments ) : undefined;
+			};
+		}
+
+		// Handle multiple events separated by a space
+		types = ( types || "" ).match( rnotwhite ) || [ "" ];
+		t = types.length;
+		while ( t-- ) {
+			tmp = rtypenamespace.exec( types[t] ) || [];
+			type = origType = tmp[1];
+			namespaces = ( tmp[2] || "" ).split( "." ).sort();
+
+			// There *must* be a type, no attaching namespace-only handlers
+			if ( !type ) {
+				continue;
+			}
+
+			// If event changes its type, use the special event handlers for the changed type
+			special = jQuery.event.special[ type ] || {};
+
+			// If selector defined, determine special event api type, otherwise given type
+			type = ( selector ? special.delegateType : special.bindType ) || type;
+
+			// Update special based on newly reset type
+			special = jQuery.event.special[ type ] || {};
+
+			// handleObj is passed to all event handlers
+			handleObj = jQuery.extend({
+				type: type,
+				origType: origType,
+				data: data,
+				handler: handler,
+				guid: handler.guid,
+				selector: selector,
+				needsContext: selector && jQuery.expr.match.needsContext.test( selector ),
+				namespace: namespaces.join(".")
+			}, handleObjIn );
+
+			// Init the event handler queue if we're the first
+			if ( !(handlers = events[ type ]) ) {
+				handlers = events[ type ] = [];
+				handlers.delegateCount = 0;
+
+				// Only use addEventListener if the special events handler returns false
+				if ( !special.setup || special.setup.call( elem, data, namespaces, eventHandle ) === false ) {
+					if ( elem.addEventListener ) {
+						elem.addEventListener( type, eventHandle, false );
+					}
+				}
+			}
+
+			if ( special.add ) {
+				special.add.call( elem, handleObj );
+
+				if ( !handleObj.handler.guid ) {
+					handleObj.handler.guid = handler.guid;
+				}
+			}
+
+			// Add to the element's handler list, delegates in front
+			if ( selector ) {
+				handlers.splice( handlers.delegateCount++, 0, handleObj );
+			} else {
+				handlers.push( handleObj );
+			}
+
+			// Keep track of which events have ever been used, for event optimization
+			jQuery.event.global[ type ] = true;
+		}
+
+	},
+
+	// Detach an event or set of events from an element
+	remove: function( elem, types, handler, selector, mappedTypes ) {
+
+		var j, origCount, tmp,
+			events, t, handleObj,
+			special, handlers, type, namespaces, origType,
+			elemData = data_priv.hasData( elem ) && data_priv.get( elem );
+
+		if ( !elemData || !(events = elemData.events) ) {
+			return;
+		}
+
+		// Once for each type.namespace in types; type may be omitted
+		types = ( types || "" ).match( rnotwhite ) || [ "" ];
+		t = types.length;
+		while ( t-- ) {
+			tmp = rtypenamespace.exec( types[t] ) || [];
+			type = origType = tmp[1];
+			namespaces = ( tmp[2] || "" ).split( "." ).sort();
+
+			// Unbind all events (on this namespace, if provided) for the element
+			if ( !type ) {
+				for ( type in events ) {
+					jQuery.event.remove( elem, type + types[ t ], handler, selector, true );
+				}
+				continue;
+			}
+
+			special = jQuery.event.special[ type ] || {};
+			type = ( selector ? special.delegateType : special.bindType ) || type;
+			handlers = events[ type ] || [];
+			tmp = tmp[2] && new RegExp( "(^|\\.)" + namespaces.join("\\.(?:.*\\.|)") + "(\\.|$)" );
+
+			// Remove matching events
+			origCount = j = handlers.length;
+			while ( j-- ) {
+				handleObj = handlers[ j ];
+
+				if ( ( mappedTypes || origType === handleObj.origType ) &&
+					( !handler || handler.guid === handleObj.guid ) &&
+					( !tmp || tmp.test( handleObj.namespace ) ) &&
+					( !selector || selector === handleObj.selector || selector === "**" && handleObj.selector ) ) {
+					handlers.splice( j, 1 );
+
+					if ( handleObj.selector ) {
+						handlers.delegateCount--;
+					}
+					if ( special.remove ) {
+						special.remove.call( elem, handleObj );
+					}
+				}
+			}
+
+			// Remove generic event handler if we removed something and no more handlers exist
+			// (avoids potential for endless recursion during removal of special event handlers)
+			if ( origCount && !handlers.length ) {
+				if ( !special.teardown || special.teardown.call( elem, namespaces, elemData.handle ) === false ) {
+					jQuery.removeEvent( elem, type, elemData.handle );
+				}
+
+				delete events[ type ];
+			}
+		}
+
+		// Remove the expando if it's no longer used
+		if ( jQuery.isEmptyObject( events ) ) {
+			delete elemData.handle;
+			data_priv.remove( elem, "events" );
+		}
+	},
+
+	trigger: function( event, data, elem, onlyHandlers ) {
+
+		var i, cur, tmp, bubbleType, ontype, handle, special,
+			eventPath = [ elem || document ],
+			type = hasOwn.call( event, "type" ) ? event.type : event,
+			namespaces = hasOwn.call( event, "namespace" ) ? event.namespace.split(".") : [];
+
+		cur = tmp = elem = elem || document;
+
+		// Don't do events on text and comment nodes
+		if ( elem.nodeType === 3 || elem.nodeType === 8 ) {
+			return;
+		}
+
+		// focus/blur morphs to focusin/out; ensure we're not firing them right now
+		if ( rfocusMorph.test( type + jQuery.event.triggered ) ) {
+			return;
+		}
+
+		if ( type.indexOf(".") >= 0 ) {
+			// Namespaced trigger; create a regexp to match event type in handle()
+			namespaces = type.split(".");
+			type = namespaces.shift();
+			namespaces.sort();
+		}
+		ontype = type.indexOf(":") < 0 && "on" + type;
+
+		// Caller can pass in a jQuery.Event object, Object, or just an event type string
+		event = event[ jQuery.expando ] ?
+			event :
+			new jQuery.Event( type, typeof event === "object" && event );
+
+		// Trigger bitmask: & 1 for native handlers; & 2 for jQuery (always true)
+		event.isTrigger = onlyHandlers ? 2 : 3;
+		event.namespace = namespaces.join(".");
+		event.namespace_re = event.namespace ?
+			new RegExp( "(^|\\.)" + namespaces.join("\\.(?:.*\\.|)") + "(\\.|$)" ) :
+			null;
+
+		// Clean up the event in case it is being reused
+		event.result = undefined;
+		if ( !event.target ) {
+			event.target = elem;
+		}
+
+		// Clone any incoming data and prepend the event, creating the handler arg list
+		data = data == null ?
+			[ event ] :
+			jQuery.makeArray( data, [ event ] );
+
+		// Allow special events to draw outside the lines
+		special = jQuery.event.special[ type ] || {};
+		if ( !onlyHandlers && special.trigger && special.trigger.apply( elem, data ) === false ) {
+			return;
+		}
+
+		// Determine event propagation path in advance, per W3C events spec (#9951)
+		// Bubble up to document, then to window; watch for a global ownerDocument var (#9724)
+		if ( !onlyHandlers && !special.noBubble && !jQuery.isWindow( elem ) ) {
+
+			bubbleType = special.delegateType || type;
+			if ( !rfocusMorph.test( bubbleType + type ) ) {
+				cur = cur.parentNode;
+			}
+			for ( ; cur; cur = cur.parentNode ) {
+				eventPath.push( cur );
+				tmp = cur;
+			}
+
+			// Only add window if we got to document (e.g., not plain obj or detached DOM)
+			if ( tmp === (elem.ownerDocument || document) ) {
+				eventPath.push( tmp.defaultView || tmp.parentWindow || window );
+			}
+		}
+
+		// Fire handlers on the event path
+		i = 0;
+		while ( (cur = eventPath[i++]) && !event.isPropagationStopped() ) {
+
+			event.type = i > 1 ?
+				bubbleType :
+				special.bindType || type;
+
+			// jQuery handler
+			handle = ( data_priv.get( cur, "events" ) || {} )[ event.type ] && data_priv.get( cur, "handle" );
+			if ( handle ) {
+				handle.apply( cur, data );
+			}
+
+			// Native handler
+			handle = ontype && cur[ ontype ];
+			if ( handle && handle.apply && jQuery.acceptData( cur ) ) {
+				event.result = handle.apply( cur, data );
+				if ( event.result === false ) {
+					event.preventDefault();
+				}
+			}
+		}
+		event.type = type;
+
+		// If nobody prevented the default action, do it now
+		if ( !onlyHandlers && !event.isDefaultPrevented() ) {
+
+			if ( (!special._default || special._default.apply( eventPath.pop(), data ) === false) &&
+				jQuery.acceptData( elem ) ) {
+
+				// Call a native DOM method on the target with the same name name as the event.
+				// Don't do default actions on window, that's where global variables be (#6170)
+				if ( ontype && jQuery.isFunction( elem[ type ] ) && !jQuery.isWindow( elem ) ) {
+
+					// Don't re-trigger an onFOO event when we call its FOO() method
+					tmp = elem[ ontype ];
+
+					if ( tmp ) {
+						elem[ ontype ] = null;
+					}
+
+					// Prevent re-triggering of the same event, since we already bubbled it above
+					jQuery.event.triggered = type;
+					elem[ type ]();
+					jQuery.event.triggered = undefined;
+
+					if ( tmp ) {
+						elem[ ontype ] = tmp;
+					}
+				}
+			}
+		}
+
+		return event.result;
+	},
+
+	dispatch: function( event ) {
+
+		// Make a writable jQuery.Event from the native event object
+		event = jQuery.event.fix( event );
+
+		var i, j, ret, matched, handleObj,
+			handlerQueue = [],
+			args = slice.call( arguments ),
+			handlers = ( data_priv.get( this, "events" ) || {} )[ event.type ] || [],
+			special = jQuery.event.special[ event.type ] || {};
+
+		// Use the fix-ed jQuery.Event rather than the (read-only) native event
+		args[0] = event;
+		event.delegateTarget = this;
+
+		// Call the preDispatch hook for the mapped type, and let it bail if desired
+		if ( special.preDispatch && special.preDispatch.call( this, event ) === false ) {
+			return;
+		}
+
+		// Determine handlers
+		handlerQueue = jQuery.event.handlers.call( this, event, handlers );
+
+		// Run delegates first; they may want to stop propagation beneath us
+		i = 0;
+		while ( (matched = handlerQueue[ i++ ]) && !event.isPropagationStopped() ) {
+			event.currentTarget = matched.elem;
+
+			j = 0;
+			while ( (handleObj = matched.handlers[ j++ ]) && !event.isImmediatePropagationStopped() ) {
+
+				// Triggered event must either 1) have no namespace, or
+				// 2) have namespace(s) a subset or equal to those in the bound event (both can have no namespace).
+				if ( !event.namespace_re || event.namespace_re.test( handleObj.namespace ) ) {
+
+					event.handleObj = handleObj;
+					event.data = handleObj.data;
+
+					ret = ( (jQuery.event.special[ handleObj.origType ] || {}).handle || handleObj.handler )
+							.apply( matched.elem, args );
+
+					if ( ret !== undefined ) {
+						if ( (event.result = ret) === false ) {
+							event.preventDefault();
+							event.stopPropagation();
+						}
+					}
+				}
+			}
+		}
+
+		// Call the postDispatch hook for the mapped type
+		if ( special.postDispatch ) {
+			special.postDispatch.call( this, event );
+		}
+
+		return event.result;
+	},
+
+	handlers: function( event, handlers ) {
+		var i, matches, sel, handleObj,
+			handlerQueue = [],
+			delegateCount = handlers.delegateCount,
+			cur = event.target;
+
+		// Find delegate handlers
+		// Black-hole SVG <use> instance trees (#13180)
+		// Avoid non-left-click bubbling in Firefox (#3861)
+		if ( delegateCount && cur.nodeType && (!event.button || event.type !== "click") ) {
+
+			for ( ; cur !== this; cur = cur.parentNode || this ) {
+
+				// Don't process clicks on disabled elements (#6911, #8165, #11382, #11764)
+				if ( cur.disabled !== true || event.type !== "click" ) {
+					matches = [];
+					for ( i = 0; i < delegateCount; i++ ) {
+						handleObj = handlers[ i ];
+
+						// Don't conflict with Object.prototype properties (#13203)
+						sel = handleObj.selector + " ";
+
+						if ( matches[ sel ] === undefined ) {
+							matches[ sel ] = handleObj.needsContext ?
+								jQuery( sel, this ).index( cur ) >= 0 :
+								jQuery.find( sel, this, null, [ cur ] ).length;
+						}
+						if ( matches[ sel ] ) {
+							matches.push( handleObj );
+						}
+					}
+					if ( matches.length ) {
+						handlerQueue.push({ elem: cur, handlers: matches });
+					}
+				}
+			}
+		}
+
+		// Add the remaining (directly-bound) handlers
+		if ( delegateCount < handlers.length ) {
+			handlerQueue.push({ elem: this, handlers: handlers.slice( delegateCount ) });
+		}
+
+		return handlerQueue;
+	},
+
+	// Includes some event props shared by KeyEvent and MouseEvent
+	props: "altKey bubbles cancelable ctrlKey currentTarget eventPhase metaKey relatedTarget shiftKey target timeStamp view which".split(" "),
+
+	fixHooks: {},
+
+	keyHooks: {
+		props: "char charCode key keyCode".split(" "),
+		filter: function( event, original ) {
+
+			// Add which for key events
+			if ( event.which == null ) {
+				event.which = original.charCode != null ? original.charCode : original.keyCode;
+			}
+
+			return event;
+		}
+	},
+
+	mouseHooks: {
+		props: "button buttons clientX clientY offsetX offsetY pageX pageY screenX screenY toElement".split(" "),
+		filter: function( event, original ) {
+			var eventDoc, doc, body,
+				button = original.button;
+
+			// Calculate pageX/Y if missing and clientX/Y available
+			if ( event.pageX == null && original.clientX != null ) {
+				eventDoc = event.target.ownerDocument || document;
+				doc = eventDoc.documentElement;
+				body = eventDoc.body;
+
+				event.pageX = original.clientX + ( doc && doc.scrollLeft || body && body.scrollLeft || 0 ) - ( doc && doc.clientLeft || body && body.clientLeft || 0 );
+				event.pageY = original.clientY + ( doc && doc.scrollTop  || body && body.scrollTop  || 0 ) - ( doc && doc.clientTop  || body && body.clientTop  || 0 );
+			}
+
+			// Add which for click: 1 === left; 2 === middle; 3 === right
+			// Note: button is not normalized, so don't use it
+			if ( !event.which && button !== undefined ) {
+				event.which = ( button & 1 ? 1 : ( button & 2 ? 3 : ( button & 4 ? 2 : 0 ) ) );
+			}
+
+			return event;
+		}
+	},
+
+	fix: function( event ) {
+		if ( event[ jQuery.expando ] ) {
+			return event;
+		}
+
+		// Create a writable copy of the event object and normalize some properties
+		var i, prop, copy,
+			type = event.type,
+			originalEvent = event,
+			fixHook = this.fixHooks[ type ];
+
+		if ( !fixHook ) {
+			this.fixHooks[ type ] = fixHook =
+				rmouseEvent.test( type ) ? this.mouseHooks :
+				rkeyEvent.test( type ) ? this.keyHooks :
+				{};
+		}
+		copy = fixHook.props ? this.props.concat( fixHook.props ) : this.props;
+
+		event = new jQuery.Event( originalEvent );
+
+		i = copy.length;
+		while ( i-- ) {
+			prop = copy[ i ];
+			event[ prop ] = originalEvent[ prop ];
+		}
+
+		// Support: Cordova 2.5 (WebKit) (#13255)
+		// All events should have a target; Cordova deviceready doesn't
+		if ( !event.target ) {
+			event.target = document;
+		}
+
+		// Support: Safari 6.0+, Chrome < 28
+		// Target should not be a text node (#504, #13143)
+		if ( event.target.nodeType === 3 ) {
+			event.target = event.target.parentNode;
+		}
+
+		return fixHook.filter ? fixHook.filter( event, originalEvent ) : event;
+	},
+
+	special: {
+		load: {
+			// Prevent triggered image.load events from bubbling to window.load
+			noBubble: true
+		},
+		focus: {
+			// Fire native event if possible so blur/focus sequence is correct
+			trigger: function() {
+				if ( this !== safeActiveElement() && this.focus ) {
+					this.focus();
+					return false;
+				}
+			},
+			delegateType: "focusin"
+		},
+		blur: {
+			trigger: function() {
+				if ( this === safeActiveElement() && this.blur ) {
+					this.blur();
+					return false;
+				}
+			},
+			delegateType: "focusout"
+		},
+		click: {
+			// For checkbox, fire native event so checked state will be right
+			trigger: function() {
+				if ( this.type === "checkbox" && this.click && jQuery.nodeName( this, "input" ) ) {
+					this.click();
+					return false;
+				}
+			},
+
+			// For cross-browser consistency, don't fire native .click() on links
+			_default: function( event ) {
+				return jQuery.nodeName( event.target, "a" );
+			}
+		},
+
+		beforeunload: {
+			postDispatch: function( event ) {
+
+				// Support: Firefox 20+
+				// Firefox doesn't alert if the returnValue field is not set.
+				if ( event.result !== undefined ) {
+					event.originalEvent.returnValue = event.result;
+				}
+			}
+		}
+	},
+
+	simulate: function( type, elem, event, bubble ) {
+		// Piggyback on a donor event to simulate a different one.
+		// Fake originalEvent to avoid donor's stopPropagation, but if the
+		// simulated event prevents default then we do the same on the donor.
+		var e = jQuery.extend(
+			new jQuery.Event(),
+			event,
+			{
+				type: type,
+				isSimulated: true,
+				originalEvent: {}
+			}
+		);
+		if ( bubble ) {
+			jQuery.event.trigger( e, null, elem );
+		} else {
+			jQuery.event.dispatch.call( elem, e );
+		}
+		if ( e.isDefaultPrevented() ) {
+			event.preventDefault();
+		}
+	}
+};
+
+jQuery.removeEvent = function( elem, type, handle ) {
+	if ( elem.removeEventListener ) {
+		elem.removeEventListener( type, handle, false );
+	}
+};
+
+jQuery.Event = function( src, props ) {
+	// Allow instantiation without the 'new' keyword
+	if ( !(this instanceof jQuery.Event) ) {
+		return new jQuery.Event( src, props );
+	}
+
+	// Event object
+	if ( src && src.type ) {
+		this.originalEvent = src;
+		this.type = src.type;
+
+		// Events bubbling up the document may have been marked as prevented
+		// by a handler lower down the tree; reflect the correct value.
+		this.isDefaultPrevented = src.defaultPrevented ||
+				// Support: Android < 4.0
+				src.defaultPrevented === undefined &&
+				src.getPreventDefault && src.getPreventDefault() ?
+			returnTrue :
+			returnFalse;
+
+	// Event type
+	} else {
+		this.type = src;
+	}
+
+	// Put explicitly provided properties onto the event object
+	if ( props ) {
+		jQuery.extend( this, props );
+	}
+
+	// Create a timestamp if incoming event doesn't have one
+	this.timeStamp = src && src.timeStamp || jQuery.now();
+
+	// Mark it as fixed
+	this[ jQuery.expando ] = true;
+};
+
+// jQuery.Event is based on DOM3 Events as specified by the ECMAScript Language Binding
+// http://www.w3.org/TR/2003/WD-DOM-Level-3-Events-20030331/ecma-script-binding.html
+jQuery.Event.prototype = {
+	isDefaultPrevented: returnFalse,
+	isPropagationStopped: returnFalse,
+	isImmediatePropagationStopped: returnFalse,
+
+	preventDefault: function() {
+		var e = this.originalEvent;
+
+		this.isDefaultPrevented = returnTrue;
+
+		if ( e && e.preventDefault ) {
+			e.preventDefault();
+		}
+	},
+	stopPropagation: function() {
+		var e = this.originalEvent;
+
+		this.isPropagationStopped = returnTrue;
+
+		if ( e && e.stopPropagation ) {
+			e.stopPropagation();
+		}
+	},
+	stopImmediatePropagation: function() {
+		this.isImmediatePropagationStopped = returnTrue;
+		this.stopPropagation();
+	}
+};
+
+// Create mouseenter/leave events using mouseover/out and event-time checks
+// Support: Chrome 15+
+jQuery.each({
+	mouseenter: "mouseover",
+	mouseleave: "mouseout"
+}, function( orig, fix ) {
+	jQuery.event.special[ orig ] = {
+		delegateType: fix,
+		bindType: fix,
+
+		handle: function( event ) {
+			var ret,
+				target = this,
+				related = event.relatedTarget,
+				handleObj = event.handleObj;
+
+			// For mousenter/leave call the handler if related is outside the target.
+			// NB: No relatedTarget if the mouse left/entered the browser window
+			if ( !related || (related !== target && !jQuery.contains( target, related )) ) {
+				event.type = handleObj.origType;
+				ret = handleObj.handler.apply( this, arguments );
+				event.type = fix;
+			}
+			return ret;
+		}
+	};
+});
+
+// Create "bubbling" focus and blur events
+// Support: Firefox, Chrome, Safari
+if ( !support.focusinBubbles ) {
+	jQuery.each({ focus: "focusin", blur: "focusout" }, function( orig, fix ) {
+
+		// Attach a single capturing handler on the document while someone wants focusin/focusout
+		var handler = function( event ) {
+				jQuery.event.simulate( fix, event.target, jQuery.event.fix( event ), true );
+			};
+
+		jQuery.event.special[ fix ] = {
+			setup: function() {
+				var doc = this.ownerDocument || this,
+					attaches = data_priv.access( doc, fix );
+
+				if ( !attaches ) {
+					doc.addEventListener( orig, handler, true );
+				}
+				data_priv.access( doc, fix, ( attaches || 0 ) + 1 );
+			},
+			teardown: function() {
+				var doc = this.ownerDocument || this,
+					attaches = data_priv.access( doc, fix ) - 1;
+
+				if ( !attaches ) {
+					doc.removeEventListener( orig, handler, true );
+					data_priv.remove( doc, fix );
+
+				} else {
+					data_priv.access( doc, fix, attaches );
+				}
+			}
+		};
+	});
+}
+
+jQuery.fn.extend({
+
+	on: function( types, selector, data, fn, /*INTERNAL*/ one ) {
+		var origFn, type;
+
+		// Types can be a map of types/handlers
+		if ( typeof types === "object" ) {
+			// ( types-Object, selector, data )
+			if ( typeof selector !== "string" ) {
+				// ( types-Object, data )
+				data = data || selector;
+				selector = undefined;
+			}
+			for ( type in types ) {
+				this.on( type, selector, data, types[ type ], one );
+			}
+			return this;
+		}
+
+		if ( data == null && fn == null ) {
+			// ( types, fn )
+			fn = selector;
+			data = selector = undefined;
+		} else if ( fn == null ) {
+			if ( typeof selector === "string" ) {
+				// ( types, selector, fn )
+				fn = data;
+				data = undefined;
+			} else {
+				// ( types, data, fn )
+				fn = data;
+				data = selector;
+				selector = undefined;
+			}
+		}
+		if ( fn === false ) {
+			fn = returnFalse;
+		} else if ( !fn ) {
+			return this;
+		}
+
+		if ( one === 1 ) {
+			origFn = fn;
+			fn = function( event ) {
+				// Can use an empty set, since event contains the info
+				jQuery().off( event );
+				return origFn.apply( this, arguments );
+			};
+			// Use same guid so caller can remove using origFn
+			fn.guid = origFn.guid || ( origFn.guid = jQuery.guid++ );
+		}
+		return this.each( function() {
+			jQuery.event.add( this, types, fn, data, selector );
+		});
+	},
+	one: function( types, selector, data, fn ) {
+		return this.on( types, selector, data, fn, 1 );
+	},
+	off: function( types, selector, fn ) {
+		var handleObj, type;
+		if ( types && types.preventDefault && types.handleObj ) {
+			// ( event )  dispatched jQuery.Event
+			handleObj = types.handleObj;
+			jQuery( types.delegateTarget ).off(
+				handleObj.namespace ? handleObj.origType + "." + handleObj.namespace : handleObj.origType,
+				handleObj.selector,
+				handleObj.handler
+			);
+			return this;
+		}
+		if ( typeof types === "object" ) {
+			// ( types-object [, selector] )
+			for ( type in types ) {
+				this.off( type, selector, types[ type ] );
+			}
+			return this;
+		}
+		if ( selector === false || typeof selector === "function" ) {
+			// ( types [, fn] )
+			fn = selector;
+			selector = undefined;
+		}
+		if ( fn === false ) {
+			fn = returnFalse;
+		}
+		return this.each(function() {
+			jQuery.event.remove( this, types, fn, selector );
+		});
+	},
+
+	trigger: function( type, data ) {
+		return this.each(function() {
+			jQuery.event.trigger( type, data, this );
+		});
+	},
+	triggerHandler: function( type, data ) {
+		var elem = this[0];
+		if ( elem ) {
+			return jQuery.event.trigger( type, data, elem, true );
+		}
+	}
+});
+
+
+var
+	rxhtmlTag = /<(?!area|br|col|embed|hr|img|input|link|meta|param)(([\w:]+)[^>]*)\/>/gi,
+	rtagName = /<([\w:]+)/,
+	rhtml = /<|&#?\w+;/,
+	rnoInnerhtml = /<(?:script|style|link)/i,
+	// checked="checked" or checked
+	rchecked = /checked\s*(?:[^=]|=\s*.checked.)/i,
+	rscriptType = /^$|\/(?:java|ecma)script/i,
+	rscriptTypeMasked = /^true\/(.*)/,
+	rcleanScript = /^\s*<!(?:\[CDATA\[|--)|(?:\]\]|--)>\s*$/g,
+
+	// We have to close these tags to support XHTML (#13200)
+	wrapMap = {
+
+		// Support: IE 9
+		option: [ 1, "<select multiple='multiple'>", "</select>" ],
+
+		thead: [ 1, "<table>", "</table>" ],
+		col: [ 2, "<table><colgroup>", "</colgroup></table>" ],
+		tr: [ 2, "<table><tbody>", "</tbody></table>" ],
+		td: [ 3, "<table><tbody><tr>", "</tr></tbody></table>" ],
+
+		_default: [ 0, "", "" ]
+	};
+
+// Support: IE 9
+wrapMap.optgroup = wrapMap.option;
+
+wrapMap.tbody = wrapMap.tfoot = wrapMap.colgroup = wrapMap.caption = wrapMap.thead;
+wrapMap.th = wrapMap.td;
+
+// Support: 1.x compatibility
+// Manipulating tables requires a tbody
+function manipulationTarget( elem, content ) {
+	return jQuery.nodeName( elem, "table" ) &&
+		jQuery.nodeName( content.nodeType !== 11 ? content : content.firstChild, "tr" ) ?
+
+		elem.getElementsByTagName("tbody")[0] ||
+			elem.appendChild( elem.ownerDocument.createElement("tbody") ) :
+		elem;
+}
+
+// Replace/restore the type attribute of script elements for safe DOM manipulation
+function disableScript( elem ) {
+	elem.type = (elem.getAttribute("type") !== null) + "/" + elem.type;
+	return elem;
+}
+function restoreScript( elem ) {
+	var match = rscriptTypeMasked.exec( elem.type );
+
+	if ( match ) {
+		elem.type = match[ 1 ];
+	} else {
+		elem.removeAttribute("type");
+	}
+
+	return elem;
+}
+
+// Mark scripts as having already been evaluated
+function setGlobalEval( elems, refElements ) {
+	var i = 0,
+		l = elems.length;
+
+	for ( ; i < l; i++ ) {
+		data_priv.set(
+			elems[ i ], "globalEval", !refElements || data_priv.get( refElements[ i ], "globalEval" )
+		);
+	}
+}
+
+function cloneCopyEvent( src, dest ) {
+	var i, l, type, pdataOld, pdataCur, udataOld, udataCur, events;
+
+	if ( dest.nodeType !== 1 ) {
+		return;
+	}
+
+	// 1. Copy private data: events, handlers, etc.
+	if ( data_priv.hasData( src ) ) {
+		pdataOld = data_priv.access( src );
+		pdataCur = data_priv.set( dest, pdataOld );
+		events = pdataOld.events;
+
+		if ( events ) {
+			delete pdataCur.handle;
+			pdataCur.events = {};
+
+			for ( type in events ) {
+				for ( i = 0, l = events[ type ].length; i < l; i++ ) {
+					jQuery.event.add( dest, type, events[ type ][ i ] );
+				}
+			}
+		}
+	}
+
+	// 2. Copy user data
+	if ( data_user.hasData( src ) ) {
+		udataOld = data_user.access( src );
+		udataCur = jQuery.extend( {}, udataOld );
+
+		data_user.set( dest, udataCur );
+	}
+}
+
+function getAll( context, tag ) {
+	var ret = context.getElementsByTagName ? context.getElementsByTagName( tag || "*" ) :
+			context.querySelectorAll ? context.querySelectorAll( tag || "*" ) :
+			[];
+
+	return tag === undefined || tag && jQuery.nodeName( context, tag ) ?
+		jQuery.merge( [ context ], ret ) :
+		ret;
+}
+
+// Support: IE >= 9
+function fixInput( src, dest ) {
+	var nodeName = dest.nodeName.toLowerCase();
+
+	// Fails to persist the checked state of a cloned checkbox or radio button.
+	if ( nodeName === "input" && rcheckableType.test( src.type ) ) {
+		dest.checked = src.checked;
+
+	// Fails to return the selected option to the default selected state when cloning options
+	} else if ( nodeName === "input" || nodeName === "textarea" ) {
+		dest.defaultValue = src.defaultValue;
+	}
+}
+
+jQuery.extend({
+	clone: function( elem, dataAndEvents, deepDataAndEvents ) {
+		var i, l, srcElements, destElements,
+			clone = elem.cloneNode( true ),
+			inPage = jQuery.contains( elem.ownerDocument, elem );
+
+		// Support: IE >= 9
+		// Fix Cloning issues
+		if ( !support.noCloneChecked && ( elem.nodeType === 1 || elem.nodeType === 11 ) &&
+				!jQuery.isXMLDoc( elem ) ) {
+
+			// We eschew Sizzle here for performance reasons: http://jsperf.com/getall-vs-sizzle/2
+			destElements = getAll( clone );
+			srcElements = getAll( elem );
+
+			for ( i = 0, l = srcElements.length; i < l; i++ ) {
+				fixInput( srcElements[ i ], destElements[ i ] );
+			}
+		}
+
+		// Copy the events from the original to the clone
+		if ( dataAndEvents ) {
+			if ( deepDataAndEvents ) {
+				srcElements = srcElements || getAll( elem );
+				destElements = destElements || getAll( clone );
+
+				for ( i = 0, l = srcElements.length; i < l; i++ ) {
+					cloneCopyEvent( srcElements[ i ], destElements[ i ] );
+				}
+			} else {
+				cloneCopyEvent( elem, clone );
+			}
+		}
+
+		// Preserve script evaluation history
+		destElements = getAll( clone, "script" );
+		if ( destElements.length > 0 ) {
+			setGlobalEval( destElements, !inPage && getAll( elem, "script" ) );
+		}
+
+		// Return the cloned set
+		return clone;
+	},
+
+	buildFragment: function( elems, context, scripts, selection ) {
+		var elem, tmp, tag, wrap, contains, j,
+			fragment = context.createDocumentFragment(),
+			nodes = [],
+			i = 0,
+			l = elems.length;
+
+		for ( ; i < l; i++ ) {
+			elem = elems[ i ];
+
+			if ( elem || elem === 0 ) {
+
+				// Add nodes directly
+				if ( jQuery.type( elem ) === "object" ) {
+					// Support: QtWebKit
+					// jQuery.merge because push.apply(_, arraylike) throws
+					jQuery.merge( nodes, elem.nodeType ? [ elem ] : elem );
+
+				// Convert non-html into a text node
+				} else if ( !rhtml.test( elem ) ) {
+					nodes.push( context.createTextNode( elem ) );
+
+				// Convert html into DOM nodes
+				} else {
+					tmp = tmp || fragment.appendChild( context.createElement("div") );
+
+					// Deserialize a standard representation
+					tag = ( rtagName.exec( elem ) || [ "", "" ] )[ 1 ].toLowerCase();
+					wrap = wrapMap[ tag ] || wrapMap._default;
+					tmp.innerHTML = wrap[ 1 ] + elem.replace( rxhtmlTag, "<$1></$2>" ) + wrap[ 2 ];
+
+					// Descend through wrappers to the right content
+					j = wrap[ 0 ];
+					while ( j-- ) {
+						tmp = tmp.lastChild;
+					}
+
+					// Support: QtWebKit
+					// jQuery.merge because push.apply(_, arraylike) throws
+					jQuery.merge( nodes, tmp.childNodes );
+
+					// Remember the top-level container
+					tmp = fragment.firstChild;
+
+					// Fixes #12346
+					// Support: Webkit, IE
+					tmp.textContent = "";
+				}
+			}
+		}
+
+		// Remove wrapper from fragment
+		fragment.textContent = "";
+
+		i = 0;
+		while ( (elem = nodes[ i++ ]) ) {
+
+			// #4087 - If origin and destination elements are the same, and this is
+			// that element, do not do anything
+			if ( selection && jQuery.inArray( elem, selection ) !== -1 ) {
+				continue;
+			}
+
+			contains = jQuery.contains( elem.ownerDocument, elem );
+
+			// Append to fragment
+			tmp = getAll( fragment.appendChild( elem ), "script" );
+
+			// Preserve script evaluation history
+			if ( contains ) {
+				setGlobalEval( tmp );
+			}
+
+			// Capture executables
+			if ( scripts ) {
+				j = 0;
+				while ( (elem = tmp[ j++ ]) ) {
+					if ( rscriptType.test( elem.type || "" ) ) {
+						scripts.push( elem );
+					}
+				}
+			}
+		}
+
+		return fragment;
+	},
+
+	cleanData: function( elems ) {
+		var data, elem, events, type, key, j,
+			special = jQuery.event.special,
+			i = 0;
+
+		for ( ; (elem = elems[ i ]) !== undefined; i++ ) {
+			if ( jQuery.acceptData( elem ) ) {
+				key = elem[ data_priv.expando ];
+
+				if ( key && (data = data_priv.cache[ key ]) ) {
+					events = Object.keys( data.events || {} );
+					if ( events.length ) {
+						for ( j = 0; (type = events[j]) !== undefined; j++ ) {
+							if ( special[ type ] ) {
+								jQuery.event.remove( elem, type );
+
+							// This is a shortcut to avoid jQuery.event.remove's overhead
+							} else {
+								jQuery.removeEvent( elem, type, data.handle );
+							}
+						}
+					}
+					if ( data_priv.cache[ key ] ) {
+						// Discard any remaining `private` data
+						delete data_priv.cache[ key ];
+					}
+				}
+			}
+			// Discard any remaining `user` data
+			delete data_user.cache[ elem[ data_user.expando ] ];
+		}
+	}
+});
+
+jQuery.fn.extend({
+	text: function( value ) {
+		return access( this, function( value ) {
+			return value === undefined ?
+				jQuery.text( this ) :
+				this.empty().each(function() {
+					if ( this.nodeType === 1 || this.nodeType === 11 || this.nodeType === 9 ) {
+						this.textContent = value;
+					}
+				});
+		}, null, value, arguments.length );
+	},
+
+	append: function() {
+		return this.domManip( arguments, function( elem ) {
+			if ( this.nodeType === 1 || this.nodeType === 11 || this.nodeType === 9 ) {
+				var target = manipulationTarget( this, elem );
+				target.appendChild( elem );
+			}
+		});
+	},
+
+	prepend: function() {
+		return this.domManip( arguments, function( elem ) {
+			if ( this.nodeType === 1 || this.nodeType === 11 || this.nodeType === 9 ) {
+				var target = manipulationTarget( this, elem );
+				target.insertBefore( elem, target.firstChild );
+			}
+		});
+	},
+
+	before: function() {
+		return this.domManip( arguments, function( elem ) {
+			if ( this.parentNode ) {
+				this.parentNode.insertBefore( elem, this );
+			}
+		});
+	},
+
+	after: function() {
+		return this.domManip( arguments, function( elem ) {
+			if ( this.parentNode ) {
+				this.parentNode.insertBefore( elem, this.nextSibling );
+			}
+		});
+	},
+
+	remove: function( selector, keepData /* Internal Use Only */ ) {
+		var elem,
+			elems = selector ? jQuery.filter( selector, this ) : this,
+			i = 0;
+
+		for ( ; (elem = elems[i]) != null; i++ ) {
+			if ( !keepData && elem.nodeType === 1 ) {
+				jQuery.cleanData( getAll( elem ) );
+			}
+
+			if ( elem.parentNode ) {
+				if ( keepData && jQuery.contains( elem.ownerDocument, elem ) ) {
+					setGlobalEval( getAll( elem, "script" ) );
+				}
+				elem.parentNode.removeChild( elem );
+			}
+		}
+
+		return this;
+	},
+
+	empty: function() {
+		var elem,
+			i = 0;
+
+		for ( ; (elem = this[i]) != null; i++ ) {
+			if ( elem.nodeType === 1 ) {
+
+				// Prevent memory leaks
+				jQuery.cleanData( getAll( elem, false ) );
+
+				// Remove any remaining nodes
+				elem.textContent = "";
+			}
+		}
+
+		return this;
+	},
+
+	clone: function( dataAndEvents, deepDataAndEvents ) {
+		dataAndEvents = dataAndEvents == null ? false : dataAndEvents;
+		deepDataAndEvents = deepDataAndEvents == null ? dataAndEvents : deepDataAndEvents;
+
+		return this.map(function() {
+			return jQuery.clone( this, dataAndEvents, deepDataAndEvents );
+		});
+	},
+
+	html: function( value ) {
+		return access( this, function( value ) {
+			var elem = this[ 0 ] || {},
+				i = 0,
+				l = this.length;
+
+			if ( value === undefined && elem.nodeType === 1 ) {
+				return elem.innerHTML;
+			}
+
+			// See if we can take a shortcut and just use innerHTML
+			if ( typeof value === "string" && !rnoInnerhtml.test( value ) &&
+				!wrapMap[ ( rtagName.exec( value ) || [ "", "" ] )[ 1 ].toLowerCase() ] ) {
+
+				value = value.replace( rxhtmlTag, "<$1></$2>" );
+
+				try {
+					for ( ; i < l; i++ ) {
+						elem = this[ i ] || {};
+
+						// Remove element nodes and prevent memory leaks
+						if ( elem.nodeType === 1 ) {
+							jQuery.cleanData( getAll( elem, false ) );
+							elem.innerHTML = value;
+						}
+					}
+
+					elem = 0;
+
+				// If using innerHTML throws an exception, use the fallback method
+				} catch( e ) {}
+			}
+
+			if ( elem ) {
+				this.empty().append( value );
+			}
+		}, null, value, arguments.length );
+	},
+
+	replaceWith: function() {
+		var arg = arguments[ 0 ];
+
+		// Make the changes, replacing each context element with the new content
+		this.domManip( arguments, function( elem ) {
+			arg = this.parentNode;
+
+			jQuery.cleanData( getAll( this ) );
+
+			if ( arg ) {
+				arg.replaceChild( elem, this );
+			}
+		});
+
+		// Force removal if there was no new content (e.g., from empty arguments)
+		return arg && (arg.length || arg.nodeType) ? this : this.remove();
+	},
+
+	detach: function( selector ) {
+		return this.remove( selector, true );
+	},
+
+	domManip: function( args, callback ) {
+
+		// Flatten any nested arrays
+		args = concat.apply( [], args );
+
+		var fragment, first, scripts, hasScripts, node, doc,
+			i = 0,
+			l = this.length,
+			set = this,
+			iNoClone = l - 1,
+			value = args[ 0 ],
+			isFunction = jQuery.isFunction( value );
+
+		// We can't cloneNode fragments that contain checked, in WebKit
+		if ( isFunction ||
+				( l > 1 && typeof value === "string" &&
+					!support.checkClone && rchecked.test( value ) ) ) {
+			return this.each(function( index ) {
+				var self = set.eq( index );
+				if ( isFunction ) {
+					args[ 0 ] = value.call( this, index, self.html() );
+				}
+				self.domManip( args, callback );
+			});
+		}
+
+		if ( l ) {
+			fragment = jQuery.buildFragment( args, this[ 0 ].ownerDocument, false, this );
+			first = fragment.firstChild;
+
+			if ( fragment.childNodes.length === 1 ) {
+				fragment = first;
+			}
+
+			if ( first ) {
+				scripts = jQuery.map( getAll( fragment, "script" ), disableScript );
+				hasScripts = scripts.length;
+
+				// Use the original fragment for the last item instead of the first because it can end up
+				// being emptied incorrectly in certain situations (#8070).
+				for ( ; i < l; i++ ) {
+					node = fragment;
+
+					if ( i !== iNoClone ) {
+						node = jQuery.clone( node, true, true );
+
+						// Keep references to cloned scripts for later restoration
+						if ( hasScripts ) {
+							// Support: QtWebKit
+							// jQuery.merge because push.apply(_, arraylike) throws
+							jQuery.merge( scripts, getAll( node, "script" ) );
+						}
+					}
+
+					callback.call( this[ i ], node, i );
+				}
+
+				if ( hasScripts ) {
+					doc = scripts[ scripts.length - 1 ].ownerDocument;
+
+					// Reenable scripts
+					jQuery.map( scripts, restoreScript );
+
+					// Evaluate executable scripts on first document insertion
+					for ( i = 0; i < hasScripts; i++ ) {
+						node = scripts[ i ];
+						if ( rscriptType.test( node.type || "" ) &&
+							!data_priv.access( node, "globalEval" ) && jQuery.contains( doc, node ) ) {
+
+							if ( node.src ) {
+								// Optional AJAX dependency, but won't run scripts if not present
+								if ( jQuery._evalUrl ) {
+									jQuery._evalUrl( node.src );
+								}
+							} else {
+								jQuery.globalEval( node.textContent.replace( rcleanScript, "" ) );
+							}
+						}
+					}
+				}
+			}
+		}
+
+		return this;
+	}
+});
+
+jQuery.each({
+	appendTo: "append",
+	prependTo: "prepend",
+	insertBefore: "before",
+	insertAfter: "after",
+	replaceAll: "replaceWith"
+}, function( name, original ) {
+	jQuery.fn[ name ] = function( selector ) {
+		var elems,
+			ret = [],
+			insert = jQuery( selector ),
+			last = insert.length - 1,
+			i = 0;
+
+		for ( ; i <= last; i++ ) {
+			elems = i === last ? this : this.clone( true );
+			jQuery( insert[ i ] )[ original ]( elems );
+
+			// Support: QtWebKit
+			// .get() because push.apply(_, arraylike) throws
+			push.apply( ret, elems.get() );
+		}
+
+		return this.pushStack( ret );
+	};
+});
+
+
+var iframe,
+	elemdisplay = {};
+
+/**
+ * Retrieve the actual display of a element
+ * @param {String} name nodeName of the element
+ * @param {Object} doc Document object
+ */
+// Called only from within defaultDisplay
+function actualDisplay( name, doc ) {
+	var elem = jQuery( doc.createElement( name ) ).appendTo( doc.body ),
+
+		// getDefaultComputedStyle might be reliably used only on attached element
+		display = window.getDefaultComputedStyle ?
+
+			// Use of this method is a temporary fix (more like optmization) until something better comes along,
+			// since it was removed from specification and supported only in FF
+			window.getDefaultComputedStyle( elem[ 0 ] ).display : jQuery.css( elem[ 0 ], "display" );
+
+	// We don't have any data stored on the element,
+	// so use "detach" method as fast way to get rid of the element
+	elem.detach();
+
+	return display;
+}
+
+/**
+ * Try to determine the default display value of an element
+ * @param {String} nodeName
+ */
+function defaultDisplay( nodeName ) {
+	var doc = document,
+		display = elemdisplay[ nodeName ];
+
+	if ( !display ) {
+		display = actualDisplay( nodeName, doc );
+
+		// If the simple way fails, read from inside an iframe
+		if ( display === "none" || !display ) {
+
+			// Use the already-created iframe if possible
+			iframe = (iframe || jQuery( "<iframe frameborder='0' width='0' height='0'/>" )).appendTo( doc.documentElement );
+
+			// Always write a new HTML skeleton so Webkit and Firefox don't choke on reuse
+			doc = iframe[ 0 ].contentDocument;
+
+			// Support: IE
+			doc.write();
+			doc.close();
+
+			display = actualDisplay( nodeName, doc );
+			iframe.detach();
+		}
+
+		// Store the correct default display
+		elemdisplay[ nodeName ] = display;
+	}
+
+	return display;
+}
+var rmargin = (/^margin/);
+
+var rnumnonpx = new RegExp( "^(" + pnum + ")(?!px)[a-z%]+$", "i" );
+
+var getStyles = function( elem ) {
+		return elem.ownerDocument.defaultView.getComputedStyle( elem, null );
+	};
+
+
+
+function curCSS( elem, name, computed ) {
+	var width, minWidth, maxWidth, ret,
+		style = elem.style;
+
+	computed = computed || getStyles( elem );
+
+	// Support: IE9
+	// getPropertyValue is only needed for .css('filter') in IE9, see #12537
+	if ( computed ) {
+		ret = computed.getPropertyValue( name ) || computed[ name ];
+	}
+
+	if ( computed ) {
+
+		if ( ret === "" && !jQuery.contains( elem.ownerDocument, elem ) ) {
+			ret = jQuery.style( elem, name );
+		}
+
+		// Support: iOS < 6
+		// A tribute to the "awesome hack by Dean Edwards"
+		// iOS < 6 (at least) returns percentage for a larger set of values, but width seems to be reliably pixels
+		// this is against the CSSOM draft spec: http://dev.w3.org/csswg/cssom/#resolved-values
+		if ( rnumnonpx.test( ret ) && rmargin.test( name ) ) {
+
+			// Remember the original values
+			width = style.width;
+			minWidth = style.minWidth;
+			maxWidth = style.maxWidth;
+
+			// Put in the new values to get a computed value out
+			style.minWidth = style.maxWidth = style.width = ret;
+			ret = computed.width;
+
+			// Revert the changed values
+			style.width = width;
+			style.minWidth = minWidth;
+			style.maxWidth = maxWidth;
+		}
+	}
+
+	return ret !== undefined ?
+		// Support: IE
+		// IE returns zIndex value as an integer.
+		ret + "" :
+		ret;
+}
+
+
+function addGetHookIf( conditionFn, hookFn ) {
+	// Define the hook, we'll check on the first run if it's really needed.
+	return {
+		get: function() {
+			if ( conditionFn() ) {
+				// Hook not needed (or it's not possible to use it due to missing dependency),
+				// remove it.
+				// Since there are no other hooks for marginRight, remove the whole object.
+				delete this.get;
+				return;
+			}
+
+			// Hook needed; redefine it so that the support test is not executed again.
+
+			return (this.get = hookFn).apply( this, arguments );
+		}
+	};
+}
+
+
+(function() {
+	var pixelPositionVal, boxSizingReliableVal,
+		// Support: Firefox, Android 2.3 (Prefixed box-sizing versions).
+		divReset = "padding:0;margin:0;border:0;display:block;-webkit-box-sizing:content-box;" +
+			"-moz-box-sizing:content-box;box-sizing:content-box",
+		docElem = document.documentElement,
+		container = document.createElement( "div" ),
+		div = document.createElement( "div" );
+
+	div.style.backgroundClip = "content-box";
+	div.cloneNode( true ).style.backgroundClip = "";
+	support.clearCloneStyle = div.style.backgroundClip === "content-box";
+
+	container.style.cssText = "border:0;width:0;height:0;position:absolute;top:0;left:-9999px;" +
+		"margin-top:1px";
+	container.appendChild( div );
+
+	// Executing both pixelPosition & boxSizingReliable tests require only one layout
+	// so they're executed at the same time to save the second computation.
+	function computePixelPositionAndBoxSizingReliable() {
+		// Support: Firefox, Android 2.3 (Prefixed box-sizing versions).
+		div.style.cssText = "-webkit-box-sizing:border-box;-moz-box-sizing:border-box;" +
+			"box-sizing:border-box;padding:1px;border:1px;display:block;width:4px;margin-top:1%;" +
+			"position:absolute;top:1%";
+		docElem.appendChild( container );
+
+		var divStyle = window.getComputedStyle( div, null );
+		pixelPositionVal = divStyle.top !== "1%";
+		boxSizingReliableVal = divStyle.width === "4px";
+
+		docElem.removeChild( container );
+	}
+
+	// Use window.getComputedStyle because jsdom on node.js will break without it.
+	if ( window.getComputedStyle ) {
+		jQuery.extend(support, {
+			pixelPosition: function() {
+				// This test is executed only once but we still do memoizing
+				// since we can use the boxSizingReliable pre-computing.
+				// No need to check if the test was already performed, though.
+				computePixelPositionAndBoxSizingReliable();
+				return pixelPositionVal;
+			},
+			boxSizingReliable: function() {
+				if ( boxSizingReliableVal == null ) {
+					computePixelPositionAndBoxSizingReliable();
+				}
+				return boxSizingReliableVal;
+			},
+			reliableMarginRight: function() {
+				// Support: Android 2.3
+				// Check if div with explicit width and no margin-right incorrectly
+				// gets computed margin-right based on width of container. (#3333)
+				// WebKit Bug 13343 - getComputedStyle returns wrong value for margin-right
+				// This support function is only executed once so no memoizing is needed.
+				var ret,
+					marginDiv = div.appendChild( document.createElement( "div" ) );
+				marginDiv.style.cssText = div.style.cssText = divReset;
+				marginDiv.style.marginRight = marginDiv.style.width = "0";
+				div.style.width = "1px";
+				docElem.appendChild( container );
+
+				ret = !parseFloat( window.getComputedStyle( marginDiv, null ).marginRight );
+
+				docElem.removeChild( container );
+
+				// Clean up the div for other support tests.
+				div.innerHTML = "";
+
+				return ret;
+			}
+		});
+	}
+})();
+
+
+// A method for quickly swapping in/out CSS properties to get correct calculations.
+jQuery.swap = function( elem, options, callback, args ) {
+	var ret, name,
+		old = {};
+
+	// Remember the old values, and insert the new ones
+	for ( name in options ) {
+		old[ name ] = elem.style[ name ];
+		elem.style[ name ] = options[ name ];
+	}
+
+	ret = callback.apply( elem, args || [] );
+
+	// Revert the old values
+	for ( name in options ) {
+		elem.style[ name ] = old[ name ];
+	}
+
+	return ret;
+};
+
+
+var
+	// swappable if display is none or starts with table except "table", "table-cell", or "table-caption"
+	// see here for display values: https://developer.mozilla.org/en-US/docs/CSS/display
+	rdisplayswap = /^(none|table(?!-c[ea]).+)/,
+	rnumsplit = new RegExp( "^(" + pnum + ")(.*)$", "i" ),
+	rrelNum = new RegExp( "^([+-])=(" + pnum + ")", "i" ),
+
+	cssShow = { position: "absolute", visibility: "hidden", display: "block" },
+	cssNormalTransform = {
+		letterSpacing: 0,
+		fontWeight: 400
+	},
+
+	cssPrefixes = [ "Webkit", "O", "Moz", "ms" ];
+
+// return a css property mapped to a potentially vendor prefixed property
+function vendorPropName( style, name ) {
+
+	// shortcut for names that are not vendor prefixed
+	if ( name in style ) {
+		return name;
+	}
+
+	// check for vendor prefixed names
+	var capName = name[0].toUpperCase() + name.slice(1),
+		origName = name,
+		i = cssPrefixes.length;
+
+	while ( i-- ) {
+		name = cssPrefixes[ i ] + capName;
+		if ( name in style ) {
+			return name;
+		}
+	}
+
+	return origName;
+}
+
+function setPositiveNumber( elem, value, subtract ) {
+	var matches = rnumsplit.exec( value );
+	return matches ?
+		// Guard against undefined "subtract", e.g., when used as in cssHooks
+		Math.max( 0, matches[ 1 ] - ( subtract || 0 ) ) + ( matches[ 2 ] || "px" ) :
+		value;
+}
+
+function augmentWidthOrHeight( elem, name, extra, isBorderBox, styles ) {
+	var i = extra === ( isBorderBox ? "border" : "content" ) ?
+		// If we already have the right measurement, avoid augmentation
+		4 :
+		// Otherwise initialize for horizontal or vertical properties
+		name === "width" ? 1 : 0,
+
+		val = 0;
+
+	for ( ; i < 4; i += 2 ) {
+		// both box models exclude margin, so add it if we want it
+		if ( extra === "margin" ) {
+			val += jQuery.css( elem, extra + cssExpand[ i ], true, styles );
+		}
+
+		if ( isBorderBox ) {
+			// border-box includes padding, so remove it if we want content
+			if ( extra === "content" ) {
+				val -= jQuery.css( elem, "padding" + cssExpand[ i ], true, styles );
+			}
+
+			// at this point, extra isn't border nor margin, so remove border
+			if ( extra !== "margin" ) {
+				val -= jQuery.css( elem, "border" + cssExpand[ i ] + "Width", true, styles );
+			}
+		} else {
+			// at this point, extra isn't content, so add padding
+			val += jQuery.css( elem, "padding" + cssExpand[ i ], true, styles );
+
+			// at this point, extra isn't content nor padding, so add border
+			if ( extra !== "padding" ) {
+				val += jQuery.css( elem, "border" + cssExpand[ i ] + "Width", true, styles );
+			}
+		}
+	}
+
+	return val;
+}
+
+function getWidthOrHeight( elem, name, extra ) {
+
+	// Start with offset property, which is equivalent to the border-box value
+	var valueIsBorderBox = true,
+		val = name === "width" ? elem.offsetWidth : elem.offsetHeight,
+		styles = getStyles( elem ),
+		isBorderBox = jQuery.css( elem, "boxSizing", false, styles ) === "border-box";
+
+	// some non-html elements return undefined for offsetWidth, so check for null/undefined
+	// svg - https://bugzilla.mozilla.org/show_bug.cgi?id=649285
+	// MathML - https://bugzilla.mozilla.org/show_bug.cgi?id=491668
+	if ( val <= 0 || val == null ) {
+		// Fall back to computed then uncomputed css if necessary
+		val = curCSS( elem, name, styles );
+		if ( val < 0 || val == null ) {
+			val = elem.style[ name ];
+		}
+
+		// Computed unit is not pixels. Stop here and return.
+		if ( rnumnonpx.test(val) ) {
+			return val;
+		}
+
+		// we need the check for style in case a browser which returns unreliable values
+		// for getComputedStyle silently falls back to the reliable elem.style
+		valueIsBorderBox = isBorderBox &&
+			( support.boxSizingReliable() || val === elem.style[ name ] );
+
+		// Normalize "", auto, and prepare for extra
+		val = parseFloat( val ) || 0;
+	}
+
+	// use the active box-sizing model to add/subtract irrelevant styles
+	return ( val +
+		augmentWidthOrHeight(
+			elem,
+			name,
+			extra || ( isBorderBox ? "border" : "content" ),
+			valueIsBorderBox,
+			styles
+		)
+	) + "px";
+}
+
+function showHide( elements, show ) {
+	var display, elem, hidden,
+		values = [],
+		index = 0,
+		length = elements.length;
+
+	for ( ; index < length; index++ ) {
+		elem = elements[ index ];
+		if ( !elem.style ) {
+			continue;
+		}
+
+		values[ index ] = data_priv.get( elem, "olddisplay" );
+		display = elem.style.display;
+		if ( show ) {
+			// Reset the inline display of this element to learn if it is
+			// being hidden by cascaded rules or not
+			if ( !values[ index ] && display === "none" ) {
+				elem.style.display = "";
+			}
+
+			// Set elements which have been overridden with display: none
+			// in a stylesheet to whatever the default browser style is
+			// for such an element
+			if ( elem.style.display === "" && isHidden( elem ) ) {
+				values[ index ] = data_priv.access( elem, "olddisplay", defaultDisplay(elem.nodeName) );
+			}
+		} else {
+
+			if ( !values[ index ] ) {
+				hidden = isHidden( elem );
+
+				if ( display && display !== "none" || !hidden ) {
+					data_priv.set( elem, "olddisplay", hidden ? display : jQuery.css(elem, "display") );
+				}
+			}
+		}
+	}
+
+	// Set the display of most of the elements in a second loop
+	// to avoid the constant reflow
+	for ( index = 0; index < length; index++ ) {
+		elem = elements[ index ];
+		if ( !elem.style ) {
+			continue;
+		}
+		if ( !show || elem.style.display === "none" || elem.style.display === "" ) {
+			elem.style.display = show ? values[ index ] || "" : "none";
+		}
+	}
+
+	return elements;
+}
+
+jQuery.extend({
+	// Add in style property hooks for overriding the default
+	// behavior of getting and setting a style property
+	cssHooks: {
+		opacity: {
+			get: function( elem, computed ) {
+				if ( computed ) {
+					// We should always get a number back from opacity
+					var ret = curCSS( elem, "opacity" );
+					return ret === "" ? "1" : ret;
+				}
+			}
+		}
+	},
+
+	// Don't automatically add "px" to these possibly-unitless properties
+	cssNumber: {
+		"columnCount": true,
+		"fillOpacity": true,
+		"fontWeight": true,
+		"lineHeight": true,
+		"opacity": true,
+		"order": true,
+		"orphans": true,
+		"widows": true,
+		"zIndex": true,
+		"zoom": true
+	},
+
+	// Add in properties whose names you wish to fix before
+	// setting or getting the value
+	cssProps: {
+		// normalize float css property
+		"float": "cssFloat"
+	},
+
+	// Get and set the style property on a DOM Node
+	style: function( elem, name, value, extra ) {
+		// Don't set styles on text and comment nodes
+		if ( !elem || elem.nodeType === 3 || elem.nodeType === 8 || !elem.style ) {
+			return;
+		}
+
+		// Make sure that we're working with the right name
+		var ret, type, hooks,
+			origName = jQuery.camelCase( name ),
+			style = elem.style;
+
+		name = jQuery.cssProps[ origName ] || ( jQuery.cssProps[ origName ] = vendorPropName( style, origName ) );
+
+		// gets hook for the prefixed version
+		// followed by the unprefixed version
+		hooks = jQuery.cssHooks[ name ] || jQuery.cssHooks[ origName ];
+
+		// Check if we're setting a value
+		if ( value !== undefined ) {
+			type = typeof value;
+
+			// convert relative number strings (+= or -=) to relative numbers. #7345
+			if ( type === "string" && (ret = rrelNum.exec( value )) ) {
+				value = ( ret[1] + 1 ) * ret[2] + parseFloat( jQuery.css( elem, name ) );
+				// Fixes bug #9237
+				type = "number";
+			}
+
+			// Make sure that null and NaN values aren't set. See: #7116
+			if ( value == null || value !== value ) {
+				return;
+			}
+
+			// If a number was passed in, add 'px' to the (except for certain CSS properties)
+			if ( type === "number" && !jQuery.cssNumber[ origName ] ) {
+				value += "px";
+			}
+
+			// Fixes #8908, it can be done more correctly by specifying setters in cssHooks,
+			// but it would mean to define eight (for every problematic property) identical functions
+			if ( !support.clearCloneStyle && value === "" && name.indexOf( "background" ) === 0 ) {
+				style[ name ] = "inherit";
+			}
+
+			// If a hook was provided, use that value, otherwise just set the specified value
+			if ( !hooks || !("set" in hooks) || (value = hooks.set( elem, value, extra )) !== undefined ) {
+				// Support: Chrome, Safari
+				// Setting style to blank string required to delete "style: x !important;"
+				style[ name ] = "";
+				style[ name ] = value;
+			}
+
+		} else {
+			// If a hook was provided get the non-computed value from there
+			if ( hooks && "get" in hooks && (ret = hooks.get( elem, false, extra )) !== undefined ) {
+				return ret;
+			}
+
+			// Otherwise just get the value from the style object
+			return style[ name ];
+		}
+	},
+
+	css: function( elem, name, extra, styles ) {
+		var val, num, hooks,
+			origName = jQuery.camelCase( name );
+
+		// Make sure that we're working with the right name
+		name = jQuery.cssProps[ origName ] || ( jQuery.cssProps[ origName ] = vendorPropName( elem.style, origName ) );
+
+		// gets hook for the prefixed version
+		// followed by the unprefixed version
+		hooks = jQuery.cssHooks[ name ] || jQuery.cssHooks[ origName ];
+
+		// If a hook was provided get the computed value from there
+		if ( hooks && "get" in hooks ) {
+			val = hooks.get( elem, true, extra );
+		}
+
+		// Otherwise, if a way to get the computed value exists, use that
+		if ( val === undefined ) {
+			val = curCSS( elem, name, styles );
+		}
+
+		//convert "normal" to computed value
+		if ( val === "normal" && name in cssNormalTransform ) {
+			val = cssNormalTransform[ name ];
+		}
+
+		// Return, converting to number if forced or a qualifier was provided and val looks numeric
+		if ( extra === "" || extra ) {
+			num = parseFloat( val );
+			return extra === true || jQuery.isNumeric( num ) ? num || 0 : val;
+		}
+		return val;
+	}
+});
+
+jQuery.each([ "height", "width" ], function( i, name ) {
+	jQuery.cssHooks[ name ] = {
+		get: function( elem, computed, extra ) {
+			if ( computed ) {
+				// certain elements can have dimension info if we invisibly show them
+				// however, it must have a current display style that would benefit from this
+				return elem.offsetWidth === 0 && rdisplayswap.test( jQuery.css( elem, "display" ) ) ?
+					jQuery.swap( elem, cssShow, function() {
+						return getWidthOrHeight( elem, name, extra );
+					}) :
+					getWidthOrHeight( elem, name, extra );
+			}
+		},
+
+		set: function( elem, value, extra ) {
+			var styles = extra && getStyles( elem );
+			return setPositiveNumber( elem, value, extra ?
+				augmentWidthOrHeight(
+					elem,
+					name,
+					extra,
+					jQuery.css( elem, "boxSizing", false, styles ) === "border-box",
+					styles
+				) : 0
+			);
+		}
+	};
+});
+
+// Support: Android 2.3
+jQuery.cssHooks.marginRight = addGetHookIf( support.reliableMarginRight,
+	function( elem, computed ) {
+		if ( computed ) {
+			// WebKit Bug 13343 - getComputedStyle returns wrong value for margin-right
+			// Work around by temporarily setting element display to inline-block
+			return jQuery.swap( elem, { "display": "inline-block" },
+				curCSS, [ elem, "marginRight" ] );
+		}
+	}
+);
+
+// These hooks are used by animate to expand properties
+jQuery.each({
+	margin: "",
+	padding: "",
+	border: "Width"
+}, function( prefix, suffix ) {
+	jQuery.cssHooks[ prefix + suffix ] = {
+		expand: function( value ) {
+			var i = 0,
+				expanded = {},
+
+				// assumes a single number if not a string
+				parts = typeof value === "string" ? value.split(" ") : [ value ];
+
+			for ( ; i < 4; i++ ) {
+				expanded[ prefix + cssExpand[ i ] + suffix ] =
+					parts[ i ] || parts[ i - 2 ] || parts[ 0 ];
+			}
+
+			return expanded;
+		}
+	};
+
+	if ( !rmargin.test( prefix ) ) {
+		jQuery.cssHooks[ prefix + suffix ].set = setPositiveNumber;
+	}
+});
+
+jQuery.fn.extend({
+	css: function( name, value ) {
+		return access( this, function( elem, name, value ) {
+			var styles, len,
+				map = {},
+				i = 0;
+
+			if ( jQuery.isArray( name ) ) {
+				styles = getStyles( elem );
+				len = name.length;
+
+				for ( ; i < len; i++ ) {
+					map[ name[ i ] ] = jQuery.css( elem, name[ i ], false, styles );
+				}
+
+				return map;
+			}
+
+			return value !== undefined ?
+				jQuery.style( elem, name, value ) :
+				jQuery.css( elem, name );
+		}, name, value, arguments.length > 1 );
+	},
+	show: function() {
+		return showHide( this, true );
+	},
+	hide: function() {
+		return showHide( this );
+	},
+	toggle: function( state ) {
+		if ( typeof state === "boolean" ) {
+			return state ? this.show() : this.hide();
+		}
+
+		return this.each(function() {
+			if ( isHidden( this ) ) {
+				jQuery( this ).show();
+			} else {
+				jQuery( this ).hide();
+			}
+		});
+	}
+});
+
+
+function Tween( elem, options, prop, end, easing ) {
+	return new Tween.prototype.init( elem, options, prop, end, easing );
+}
+jQuery.Tween = Tween;
+
+Tween.prototype = {
+	constructor: Tween,
+	init: function( elem, options, prop, end, easing, unit ) {
+		this.elem = elem;
+		this.prop = prop;
+		this.easing = easing || "swing";
+		this.options = options;
+		this.start = this.now = this.cur();
+		this.end = end;
+		this.unit = unit || ( jQuery.cssNumber[ prop ] ? "" : "px" );
+	},
+	cur: function() {
+		var hooks = Tween.propHooks[ this.prop ];
+
+		return hooks && hooks.get ?
+			hooks.get( this ) :
+			Tween.propHooks._default.get( this );
+	},
+	run: function( percent ) {
+		var eased,
+			hooks = Tween.propHooks[ this.prop ];
+
+		if ( this.options.duration ) {
+			this.pos = eased = jQuery.easing[ this.easing ](
+				percent, this.options.duration * percent, 0, 1, this.options.duration
+			);
+		} else {
+			this.pos = eased = percent;
+		}
+		this.now = ( this.end - this.start ) * eased + this.start;
+
+		if ( this.options.step ) {
+			this.options.step.call( this.elem, this.now, this );
+		}
+
+		if ( hooks && hooks.set ) {
+			hooks.set( this );
+		} else {
+			Tween.propHooks._default.set( this );
+		}
+		return this;
+	}
+};
+
+Tween.prototype.init.prototype = Tween.prototype;
+
+Tween.propHooks = {
+	_default: {
+		get: function( tween ) {
+			var result;
+
+			if ( tween.elem[ tween.prop ] != null &&
+				(!tween.elem.style || tween.elem.style[ tween.prop ] == null) ) {
+				return tween.elem[ tween.prop ];
+			}
+
+			// passing an empty string as a 3rd parameter to .css will automatically
+			// attempt a parseFloat and fallback to a string if the parse fails
+			// so, simple values such as "10px" are parsed to Float.
+			// complex values such as "rotate(1rad)" are returned as is.
+			result = jQuery.css( tween.elem, tween.prop, "" );
+			// Empty strings, null, undefined and "auto" are converted to 0.
+			return !result || result === "auto" ? 0 : result;
+		},
+		set: function( tween ) {
+			// use step hook for back compat - use cssHook if its there - use .style if its
+			// available and use plain properties where available
+			if ( jQuery.fx.step[ tween.prop ] ) {
+				jQuery.fx.step[ tween.prop ]( tween );
+			} else if ( tween.elem.style && ( tween.elem.style[ jQuery.cssProps[ tween.prop ] ] != null || jQuery.cssHooks[ tween.prop ] ) ) {
+				jQuery.style( tween.elem, tween.prop, tween.now + tween.unit );
+			} else {
+				tween.elem[ tween.prop ] = tween.now;
+			}
+		}
+	}
+};
+
+// Support: IE9
+// Panic based approach to setting things on disconnected nodes
+
+Tween.propHooks.scrollTop = Tween.propHooks.scrollLeft = {
+	set: function( tween ) {
+		if ( tween.elem.nodeType && tween.elem.parentNode ) {
+			tween.elem[ tween.prop ] = tween.now;
+		}
+	}
+};
+
+jQuery.easing = {
+	linear: function( p ) {
+		return p;
+	},
+	swing: function( p ) {
+		return 0.5 - Math.cos( p * Math.PI ) / 2;
+	}
+};
+
+jQuery.fx = Tween.prototype.init;
+
+// Back Compat <1.8 extension point
+jQuery.fx.step = {};
+
+
+
+
+var
+	fxNow, timerId,
+	rfxtypes = /^(?:toggle|show|hide)$/,
+	rfxnum = new RegExp( "^(?:([+-])=|)(" + pnum + ")([a-z%]*)$", "i" ),
+	rrun = /queueHooks$/,
+	animationPrefilters = [ defaultPrefilter ],
+	tweeners = {
+		"*": [ function( prop, value ) {
+			var tween = this.createTween( prop, value ),
+				target = tween.cur(),
+				parts = rfxnum.exec( value ),
+				unit = parts && parts[ 3 ] || ( jQuery.cssNumber[ prop ] ? "" : "px" ),
+
+				// Starting value computation is required for potential unit mismatches
+				start = ( jQuery.cssNumber[ prop ] || unit !== "px" && +target ) &&
+					rfxnum.exec( jQuery.css( tween.elem, prop ) ),
+				scale = 1,
+				maxIterations = 20;
+
+			if ( start && start[ 3 ] !== unit ) {
+				// Trust units reported by jQuery.css
+				unit = unit || start[ 3 ];
+
+				// Make sure we update the tween properties later on
+				parts = parts || [];
+
+				// Iteratively approximate from a nonzero starting point
+				start = +target || 1;
+
+				do {
+					// If previous iteration zeroed out, double until we get *something*
+					// Use a string for doubling factor so we don't accidentally see scale as unchanged below
+					scale = scale || ".5";
+
+					// Adjust and apply
+					start = start / scale;
+					jQuery.style( tween.elem, prop, start + unit );
+
+				// Update scale, tolerating zero or NaN from tween.cur()
+				// And breaking the loop if scale is unchanged or perfect, or if we've just had enough
+				} while ( scale !== (scale = tween.cur() / target) && scale !== 1 && --maxIterations );
+			}
+
+			// Update tween properties
+			if ( parts ) {
+				start = tween.start = +start || +target || 0;
+				tween.unit = unit;
+				// If a +=/-= token was provided, we're doing a relative animation
+				tween.end = parts[ 1 ] ?
+					start + ( parts[ 1 ] + 1 ) * parts[ 2 ] :
+					+parts[ 2 ];
+			}
+
+			return tween;
+		} ]
+	};
+
+// Animations created synchronously will run synchronously
+function createFxNow() {
+	setTimeout(function() {
+		fxNow = undefined;
+	});
+	return ( fxNow = jQuery.now() );
+}
+
+// Generate parameters to create a standard animation
+function genFx( type, includeWidth ) {
+	var which,
+		i = 0,
+		attrs = { height: type };
+
+	// if we include width, step value is 1 to do all cssExpand values,
+	// if we don't include width, step value is 2 to skip over Left and Right
+	includeWidth = includeWidth ? 1 : 0;
+	for ( ; i < 4 ; i += 2 - includeWidth ) {
+		which = cssExpand[ i ];
+		attrs[ "margin" + which ] = attrs[ "padding" + which ] = type;
+	}
+
+	if ( includeWidth ) {
+		attrs.opacity = attrs.width = type;
+	}
+
+	return attrs;
+}
+
+function createTween( value, prop, animation ) {
+	var tween,
+		collection = ( tweeners[ prop ] || [] ).concat( tweeners[ "*" ] ),
+		index = 0,
+		length = collection.length;
+	for ( ; index < length; index++ ) {
+		if ( (tween = collection[ index ].call( animation, prop, value )) ) {
+
+			// we're done with this property
+			return tween;
+		}
+	}
+}
+
+function defaultPrefilter( elem, props, opts ) {
+	/* jshint validthis: true */
+	var prop, value, toggle, tween, hooks, oldfire, display,
+		anim = this,
+		orig = {},
+		style = elem.style,
+		hidden = elem.nodeType && isHidden( elem ),
+		dataShow = data_priv.get( elem, "fxshow" );
+
+	// handle queue: false promises
+	if ( !opts.queue ) {
+		hooks = jQuery._queueHooks( elem, "fx" );
+		if ( hooks.unqueued == null ) {
+			hooks.unqueued = 0;
+			oldfire = hooks.empty.fire;
+			hooks.empty.fire = function() {
+				if ( !hooks.unqueued ) {
+					oldfire();
+				}
+			};
+		}
+		hooks.unqueued++;
+
+		anim.always(function() {
+			// doing this makes sure that the complete handler will be called
+			// before this completes
+			anim.always(function() {
+				hooks.unqueued--;
+				if ( !jQuery.queue( elem, "fx" ).length ) {
+					hooks.empty.fire();
+				}
+			});
+		});
+	}
+
+	// height/width overflow pass
+	if ( elem.nodeType === 1 && ( "height" in props || "width" in props ) ) {
+		// Make sure that nothing sneaks out
+		// Record all 3 overflow attributes because IE9-10 do not
+		// change the overflow attribute when overflowX and
+		// overflowY are set to the same value
+		opts.overflow = [ style.overflow, style.overflowX, style.overflowY ];
+
+		// Set display property to inline-block for height/width
+		// animations on inline elements that are having width/height animated
+		display = jQuery.css( elem, "display" );
+		// Get default display if display is currently "none"
+		if ( display === "none" ) {
+			display = defaultDisplay( elem.nodeName );
+		}
+		if ( display === "inline" &&
+				jQuery.css( elem, "float" ) === "none" ) {
+
+			style.display = "inline-block";
+		}
+	}
+
+	if ( opts.overflow ) {
+		style.overflow = "hidden";
+		anim.always(function() {
+			style.overflow = opts.overflow[ 0 ];
+			style.overflowX = opts.overflow[ 1 ];
+			style.overflowY = opts.overflow[ 2 ];
+		});
+	}
+
+	// show/hide pass
+	for ( prop in props ) {
+		value = props[ prop ];
+		if ( rfxtypes.exec( value ) ) {
+			delete props[ prop ];
+			toggle = toggle || value === "toggle";
+			if ( value === ( hidden ? "hide" : "show" ) ) {
+
+				// If there is dataShow left over from a stopped hide or show and we are going to proceed with show, we should pretend to be hidden
+				if ( value === "show" && dataShow && dataShow[ prop ] !== undefined ) {
+					hidden = true;
+				} else {
+					continue;
+				}
+			}
+			orig[ prop ] = dataShow && dataShow[ prop ] || jQuery.style( elem, prop );
+		}
+	}
+
+	if ( !jQuery.isEmptyObject( orig ) ) {
+		if ( dataShow ) {
+			if ( "hidden" in dataShow ) {
+				hidden = dataShow.hidden;
+			}
+		} else {
+			dataShow = data_priv.access( elem, "fxshow", {} );
+		}
+
+		// store state if its toggle - enables .stop().toggle() to "reverse"
+		if ( toggle ) {
+			dataShow.hidden = !hidden;
+		}
+		if ( hidden ) {
+			jQuery( elem ).show();
+		} else {
+			anim.done(function() {
+				jQuery( elem ).hide();
+			});
+		}
+		anim.done(function() {
+			var prop;
+
+			data_priv.remove( elem, "fxshow" );
+			for ( prop in orig ) {
+				jQuery.style( elem, prop, orig[ prop ] );
+			}
+		});
+		for ( prop in orig ) {
+			tween = createTween( hidden ? dataShow[ prop ] : 0, prop, anim );
+
+			if ( !( prop in dataShow ) ) {
+				dataShow[ prop ] = tween.start;
+				if ( hidden ) {
+					tween.end = tween.start;
+					tween.start = prop === "width" || prop === "height" ? 1 : 0;
+				}
+			}
+		}
+	}
+}
+
+function propFilter( props, specialEasing ) {
+	var index, name, easing, value, hooks;
+
+	// camelCase, specialEasing and expand cssHook pass
+	for ( index in props ) {
+		name = jQuery.camelCase( index );
+		easing = specialEasing[ name ];
+		value = props[ index ];
+		if ( jQuery.isArray( value ) ) {
+			easing = value[ 1 ];
+			value = props[ index ] = value[ 0 ];
+		}
+
+		if ( index !== name ) {
+			props[ name ] = value;
+			delete props[ index ];
+		}
+
+		hooks = jQuery.cssHooks[ name ];
+		if ( hooks && "expand" in hooks ) {
+			value = hooks.expand( value );
+			delete props[ name ];
+
+			// not quite $.extend, this wont overwrite keys already present.
+			// also - reusing 'index' from above because we have the correct "name"
+			for ( index in value ) {
+				if ( !( index in props ) ) {
+					props[ index ] = value[ index ];
+					specialEasing[ index ] = easing;
+				}
+			}
+		} else {
+			specialEasing[ name ] = easing;
+		}
+	}
+}
+
+function Animation( elem, properties, options ) {
+	var result,
+		stopped,
+		index = 0,
+		length = animationPrefilters.length,
+		deferred = jQuery.Deferred().always( function() {
+			// don't match elem in the :animated selector
+			delete tick.elem;
+		}),
+		tick = function() {
+			if ( stopped ) {
+				return false;
+			}
+			var currentTime = fxNow || createFxNow(),
+				remaining = Math.max( 0, animation.startTime + animation.duration - currentTime ),
+				// archaic crash bug won't allow us to use 1 - ( 0.5 || 0 ) (#12497)
+				temp = remaining / animation.duration || 0,
+				percent = 1 - temp,
+				index = 0,
+				length = animation.tweens.length;
+
+			for ( ; index < length ; index++ ) {
+				animation.tweens[ index ].run( percent );
+			}
+
+			deferred.notifyWith( elem, [ animation, percent, remaining ]);
+
+			if ( percent < 1 && length ) {
+				return remaining;
+			} else {
+				deferred.resolveWith( elem, [ animation ] );
+				return false;
+			}
+		},
+		animation = deferred.promise({
+			elem: elem,
+			props: jQuery.extend( {}, properties ),
+			opts: jQuery.extend( true, { specialEasing: {} }, options ),
+			originalProperties: properties,
+			originalOptions: options,
+			startTime: fxNow || createFxNow(),
+			duration: options.duration,
+			tweens: [],
+			createTween: function( prop, end ) {
+				var tween = jQuery.Tween( elem, animation.opts, prop, end,
+						animation.opts.specialEasing[ prop ] || animation.opts.easing );
+				animation.tweens.push( tween );
+				return tween;
+			},
+			stop: function( gotoEnd ) {
+				var index = 0,
+					// if we are going to the end, we want to run all the tweens
+					// otherwise we skip this part
+					length = gotoEnd ? animation.tweens.length : 0;
+				if ( stopped ) {
+					return this;
+				}
+				stopped = true;
+				for ( ; index < length ; index++ ) {
+					animation.tweens[ index ].run( 1 );
+				}
+
+				// resolve when we played the last frame
+				// otherwise, reject
+				if ( gotoEnd ) {
+					deferred.resolveWith( elem, [ animation, gotoEnd ] );
+				} else {
+					deferred.rejectWith( elem, [ animation, gotoEnd ] );
+				}
+				return this;
+			}
+		}),
+		props = animation.props;
+
+	propFilter( props, animation.opts.specialEasing );
+
+	for ( ; index < length ; index++ ) {
+		result = animationPrefilters[ index ].call( animation, elem, props, animation.opts );
+		if ( result ) {
+			return result;
+		}
+	}
+
+	jQuery.map( props, createTween, animation );
+
+	if ( jQuery.isFunction( animation.opts.start ) ) {
+		animation.opts.start.call( elem, animation );
+	}
+
+	jQuery.fx.timer(
+		jQuery.extend( tick, {
+			elem: elem,
+			anim: animation,
+			queue: animation.opts.queue
+		})
+	);
+
+	// attach callbacks from options
+	return animation.progress( animation.opts.progress )
+		.done( animation.opts.done, animation.opts.complete )
+		.fail( animation.opts.fail )
+		.always( animation.opts.always );
+}
+
+jQuery.Animation = jQuery.extend( Animation, {
+
+	tweener: function( props, callback ) {
+		if ( jQuery.isFunction( props ) ) {
+			callback = props;
+			props = [ "*" ];
+		} else {
+			props = props.split(" ");
+		}
+
+		var prop,
+			index = 0,
+			length = props.length;
+
+		for ( ; index < length ; index++ ) {
+			prop = props[ index ];
+			tweeners[ prop ] = tweeners[ prop ] || [];
+			tweeners[ prop ].unshift( callback );
+		}
+	},
+
+	prefilter: function( callback, prepend ) {
+		if ( prepend ) {
+			animationPrefilters.unshift( callback );
+		} else {
+			animationPrefilters.push( callback );
+		}
+	}
+});
+
+jQuery.speed = function( speed, easing, fn ) {
+	var opt = speed && typeof speed === "object" ? jQuery.extend( {}, speed ) : {
+		complete: fn || !fn && easing ||
+			jQuery.isFunction( speed ) && speed,
+		duration: speed,
+		easing: fn && easing || easing && !jQuery.isFunction( easing ) && easing
+	};
+
+	opt.duration = jQuery.fx.off ? 0 : typeof opt.duration === "number" ? opt.duration :
+		opt.duration in jQuery.fx.speeds ? jQuery.fx.speeds[ opt.duration ] : jQuery.fx.speeds._default;
+
+	// normalize opt.queue - true/undefined/null -> "fx"
+	if ( opt.queue == null || opt.queue === true ) {
+		opt.queue = "fx";
+	}
+
+	// Queueing
+	opt.old = opt.complete;
+
+	opt.complete = function() {
+		if ( jQuery.isFunction( opt.old ) ) {
+			opt.old.call( this );
+		}
+
+		if ( opt.queue ) {
+			jQuery.dequeue( this, opt.queue );
+		}
+	};
+
+	return opt;
+};
+
+jQuery.fn.extend({
+	fadeTo: function( speed, to, easing, callback ) {
+
+		// show any hidden elements after setting opacity to 0
+		return this.filter( isHidden ).css( "opacity", 0 ).show()
+
+			// animate to the value specified
+			.end().animate({ opacity: to }, speed, easing, callback );
+	},
+	animate: function( prop, speed, easing, callback ) {
+		var empty = jQuery.isEmptyObject( prop ),
+			optall = jQuery.speed( speed, easing, callback ),
+			doAnimation = function() {
+				// Operate on a copy of prop so per-property easing won't be lost
+				var anim = Animation( this, jQuery.extend( {}, prop ), optall );
+
+				// Empty animations, or finishing resolves immediately
+				if ( empty || data_priv.get( this, "finish" ) ) {
+					anim.stop( true );
+				}
+			};
+			doAnimation.finish = doAnimation;
+
+		return empty || optall.queue === false ?
+			this.each( doAnimation ) :
+			this.queue( optall.queue, doAnimation );
+	},
+	stop: function( type, clearQueue, gotoEnd ) {
+		var stopQueue = function( hooks ) {
+			var stop = hooks.stop;
+			delete hooks.stop;
+			stop( gotoEnd );
+		};
+
+		if ( typeof type !== "string" ) {
+			gotoEnd = clearQueue;
+			clearQueue = type;
+			type = undefined;
+		}
+		if ( clearQueue && type !== false ) {
+			this.queue( type || "fx", [] );
+		}
+
+		return this.each(function() {
+			var dequeue = true,
+				index = type != null && type + "queueHooks",
+				timers = jQuery.timers,
+				data = data_priv.get( this );
+
+			if ( index ) {
+				if ( data[ index ] && data[ index ].stop ) {
+					stopQueue( data[ index ] );
+				}
+			} else {
+				for ( index in data ) {
+					if ( data[ index ] && data[ index ].stop && rrun.test( index ) ) {
+						stopQueue( data[ index ] );
+					}
+				}
+			}
+
+			for ( index = timers.length; index--; ) {
+				if ( timers[ index ].elem === this && (type == null || timers[ index ].queue === type) ) {
+					timers[ index ].anim.stop( gotoEnd );
+					dequeue = false;
+					timers.splice( index, 1 );
+				}
+			}
+
+			// start the next in the queue if the last step wasn't forced
+			// timers currently will call their complete callbacks, which will dequeue
+			// but only if they were gotoEnd
+			if ( dequeue || !gotoEnd ) {
+				jQuery.dequeue( this, type );
+			}
+		});
+	},
+	finish: function( type ) {
+		if ( type !== false ) {
+			type = type || "fx";
+		}
+		return this.each(function() {
+			var index,
+				data = data_priv.get( this ),
+				queue = data[ type + "queue" ],
+				hooks = data[ type + "queueHooks" ],
+				timers = jQuery.timers,
+				length = queue ? queue.length : 0;
+
+			// enable finishing flag on private data
+			data.finish = true;
+
+			// empty the queue first
+			jQuery.queue( this, type, [] );
+
+			if ( hooks && hooks.stop ) {
+				hooks.stop.call( this, true );
+			}
+
+			// look for any active animations, and finish them
+			for ( index = timers.length; index--; ) {
+				if ( timers[ index ].elem === this && timers[ index ].queue === type ) {
+					timers[ index ].anim.stop( true );
+					timers.splice( index, 1 );
+				}
+			}
+
+			// look for any animations in the old queue and finish them
+			for ( index = 0; index < length; index++ ) {
+				if ( queue[ index ] && queue[ index ].finish ) {
+					queue[ index ].finish.call( this );
+				}
+			}
+
+			// turn off finishing flag
+			delete data.finish;
+		});
+	}
+});
+
+jQuery.each([ "toggle", "show", "hide" ], function( i, name ) {
+	var cssFn = jQuery.fn[ name ];
+	jQuery.fn[ name ] = function( speed, easing, callback ) {
+		return speed == null || typeof speed === "boolean" ?
+			cssFn.apply( this, arguments ) :
+			this.animate( genFx( name, true ), speed, easing, callback );
+	};
+});
+
+// Generate shortcuts for custom animations
+jQuery.each({
+	slideDown: genFx("show"),
+	slideUp: genFx("hide"),
+	slideToggle: genFx("toggle"),
+	fadeIn: { opacity: "show" },
+	fadeOut: { opacity: "hide" },
+	fadeToggle: { opacity: "toggle" }
+}, function( name, props ) {
+	jQuery.fn[ name ] = function( speed, easing, callback ) {
+		return this.animate( props, speed, easing, callback );
+	};
+});
+
+jQuery.timers = [];
+jQuery.fx.tick = function() {
+	var timer,
+		i = 0,
+		timers = jQuery.timers;
+
+	fxNow = jQuery.now();
+
+	for ( ; i < timers.length; i++ ) {
+		timer = timers[ i ];
+		// Checks the timer has not already been removed
+		if ( !timer() && timers[ i ] === timer ) {
+			timers.splice( i--, 1 );
+		}
+	}
+
+	if ( !timers.length ) {
+		jQuery.fx.stop();
+	}
+	fxNow = undefined;
+};
+
+jQuery.fx.timer = function( timer ) {
+	jQuery.timers.push( timer );
+	if ( timer() ) {
+		jQuery.fx.start();
+	} else {
+		jQuery.timers.pop();
+	}
+};
+
+jQuery.fx.interval = 13;
+
+jQuery.fx.start = function() {
+	if ( !timerId ) {
+		timerId = setInterval( jQuery.fx.tick, jQuery.fx.interval );
+	}
+};
+
+jQuery.fx.stop = function() {
+	clearInterval( timerId );
+	timerId = null;
+};
+
+jQuery.fx.speeds = {
+	slow: 600,
+	fast: 200,
+	// Default speed
+	_default: 400
+};
+
+
+// Based off of the plugin by Clint Helfers, with permission.
+// http://blindsignals.com/index.php/2009/07/jquery-delay/
+jQuery.fn.delay = function( time, type ) {
+	time = jQuery.fx ? jQuery.fx.speeds[ time ] || time : time;
+	type = type || "fx";
+
+	return this.queue( type, function( next, hooks ) {
+		var timeout = setTimeout( next, time );
+		hooks.stop = function() {
+			clearTimeout( timeout );
+		};
+	});
+};
+
+
+(function() {
+	var input = document.createElement( "input" ),
+		select = document.createElement( "select" ),
+		opt = select.appendChild( document.createElement( "option" ) );
+
+	input.type = "checkbox";
+
+	// Support: iOS 5.1, Android 4.x, Android 2.3
+	// Check the default checkbox/radio value ("" on old WebKit; "on" elsewhere)
+	support.checkOn = input.value !== "";
+
+	// Must access the parent to make an option select properly
+	// Support: IE9, IE10
+	support.optSelected = opt.selected;
+
+	// Make sure that the options inside disabled selects aren't marked as disabled
+	// (WebKit marks them as disabled)
+	select.disabled = true;
+	support.optDisabled = !opt.disabled;
+
+	// Check if an input maintains its value after becoming a radio
+	// Support: IE9, IE10
+	input = document.createElement( "input" );
+	input.value = "t";
+	input.type = "radio";
+	support.radioValue = input.value === "t";
+})();
+
+
+var nodeHook, boolHook,
+	attrHandle = jQuery.expr.attrHandle;
+
+jQuery.fn.extend({
+	attr: function( name, value ) {
+		return access( this, jQuery.attr, name, value, arguments.length > 1 );
+	},
+
+	removeAttr: function( name ) {
+		return this.each(function() {
+			jQuery.removeAttr( this, name );
+		});
+	}
+});
+
+jQuery.extend({
+	attr: function( elem, name, value ) {
+		var hooks, ret,
+			nType = elem.nodeType;
+
+		// don't get/set attributes on text, comment and attribute nodes
+		if ( !elem || nType === 3 || nType === 8 || nType === 2 ) {
+			return;
+		}
+
+		// Fallback to prop when attributes are not supported
+		if ( typeof elem.getAttribute === strundefined ) {
+			return jQuery.prop( elem, name, value );
+		}
+
+		// All attributes are lowercase
+		// Grab necessary hook if one is defined
+		if ( nType !== 1 || !jQuery.isXMLDoc( elem ) ) {
+			name = name.toLowerCase();
+			hooks = jQuery.attrHooks[ name ] ||
+				( jQuery.expr.match.bool.test( name ) ? boolHook : nodeHook );
+		}
+
+		if ( value !== undefined ) {
+
+			if ( value === null ) {
+				jQuery.removeAttr( elem, name );
+
+			} else if ( hooks && "set" in hooks && (ret = hooks.set( elem, value, name )) !== undefined ) {
+				return ret;
+
+			} else {
+				elem.setAttribute( name, value + "" );
+				return value;
+			}
+
+		} else if ( hooks && "get" in hooks && (ret = hooks.get( elem, name )) !== null ) {
+			return ret;
+
+		} else {
+			ret = jQuery.find.attr( elem, name );
+
+			// Non-existent attributes return null, we normalize to undefined
+			return ret == null ?
+				undefined :
+				ret;
+		}
+	},
+
+	removeAttr: function( elem, value ) {
+		var name, propName,
+			i = 0,
+			attrNames = value && value.match( rnotwhite );
+
+		if ( attrNames && elem.nodeType === 1 ) {
+			while ( (name = attrNames[i++]) ) {
+				propName = jQuery.propFix[ name ] || name;
+
+				// Boolean attributes get special treatment (#10870)
+				if ( jQuery.expr.match.bool.test( name ) ) {
+					// Set corresponding property to false
+					elem[ propName ] = false;
+				}
+
+				elem.removeAttribute( name );
+			}
+		}
+	},
+
+	attrHooks: {
+		type: {
+			set: function( elem, value ) {
+				if ( !support.radioValue && value === "radio" &&
+					jQuery.nodeName( elem, "input" ) ) {
+					// Setting the type on a radio button after the value resets the value in IE6-9
+					// Reset value to default in case type is set after value during creation
+					var val = elem.value;
+					elem.setAttribute( "type", value );
+					if ( val ) {
+						elem.value = val;
+					}
+					return value;
+				}
+			}
+		}
+	}
+});
+
+// Hooks for boolean attributes
+boolHook = {
+	set: function( elem, value, name ) {
+		if ( value === false ) {
+			// Remove boolean attributes when set to false
+			jQuery.removeAttr( elem, name );
+		} else {
+			elem.setAttribute( name, name );
+		}
+		return name;
+	}
+};
+jQuery.each( jQuery.expr.match.bool.source.match( /\w+/g ), function( i, name ) {
+	var getter = attrHandle[ name ] || jQuery.find.attr;
+
+	attrHandle[ name ] = function( elem, name, isXML ) {
+		var ret, handle;
+		if ( !isXML ) {
+			// Avoid an infinite loop by temporarily removing this function from the getter
+			handle = attrHandle[ name ];
+			attrHandle[ name ] = ret;
+			ret = getter( elem, name, isXML ) != null ?
+				name.toLowerCase() :
+				null;
+			attrHandle[ name ] = handle;
+		}
+		return ret;
+	};
+});
+
+
+
+
+var rfocusable = /^(?:input|select|textarea|button)$/i;
+
+jQuery.fn.extend({
+	prop: function( name, value ) {
+		return access( this, jQuery.prop, name, value, arguments.length > 1 );
+	},
+
+	removeProp: function( name ) {
+		return this.each(function() {
+			delete this[ jQuery.propFix[ name ] || name ];
+		});
+	}
+});
+
+jQuery.extend({
+	propFix: {
+		"for": "htmlFor",
+		"class": "className"
+	},
+
+	prop: function( elem, name, value ) {
+		var ret, hooks, notxml,
+			nType = elem.nodeType;
+
+		// don't get/set properties on text, comment and attribute nodes
+		if ( !elem || nType === 3 || nType === 8 || nType === 2 ) {
+			return;
+		}
+
+		notxml = nType !== 1 || !jQuery.isXMLDoc( elem );
+
+		if ( notxml ) {
+			// Fix name and attach hooks
+			name = jQuery.propFix[ name ] || name;
+			hooks = jQuery.propHooks[ name ];
+		}
+
+		if ( value !== undefined ) {
+			return hooks && "set" in hooks && (ret = hooks.set( elem, value, name )) !== undefined ?
+				ret :
+				( elem[ name ] = value );
+
+		} else {
+			return hooks && "get" in hooks && (ret = hooks.get( elem, name )) !== null ?
+				ret :
+				elem[ name ];
+		}
+	},
+
+	propHooks: {
+		tabIndex: {
+			get: function( elem ) {
+				return elem.hasAttribute( "tabindex" ) || rfocusable.test( elem.nodeName ) || elem.href ?
+					elem.tabIndex :
+					-1;
+			}
+		}
+	}
+});
+
+// Support: IE9+
+// Selectedness for an option in an optgroup can be inaccurate
+if ( !support.optSelected ) {
+	jQuery.propHooks.selected = {
+		get: function( elem ) {
+			var parent = elem.parentNode;
+			if ( parent && parent.parentNode ) {
+				parent.parentNode.selectedIndex;
+			}
+			return null;
+		}
+	};
+}
+
+jQuery.each([
+	"tabIndex",
+	"readOnly",
+	"maxLength",
+	"cellSpacing",
+	"cellPadding",
+	"rowSpan",
+	"colSpan",
+	"useMap",
+	"frameBorder",
+	"contentEditable"
+], function() {
+	jQuery.propFix[ this.toLowerCase() ] = this;
+});
+
+
+
+
+var rclass = /[\t\r\n\f]/g;
+
+jQuery.fn.extend({
+	addClass: function( value ) {
+		var classes, elem, cur, clazz, j, finalValue,
+			proceed = typeof value === "string" && value,
+			i = 0,
+			len = this.length;
+
+		if ( jQuery.isFunction( value ) ) {
+			return this.each(function( j ) {
+				jQuery( this ).addClass( value.call( this, j, this.className ) );
+			});
+		}
+
+		if ( proceed ) {
+			// The disjunction here is for better compressibility (see removeClass)
+			classes = ( value || "" ).match( rnotwhite ) || [];
+
+			for ( ; i < len; i++ ) {
+				elem = this[ i ];
+				cur = elem.nodeType === 1 && ( elem.className ?
+					( " " + elem.className + " " ).replace( rclass, " " ) :
+					" "
+				);
+
+				if ( cur ) {
+					j = 0;
+					while ( (clazz = classes[j++]) ) {
+						if ( cur.indexOf( " " + clazz + " " ) < 0 ) {
+							cur += clazz + " ";
+						}
+					}
+
+					// only assign if different to avoid unneeded rendering.
+					finalValue = jQuery.trim( cur );
+					if ( elem.className !== finalValue ) {
+						elem.className = finalValue;
+					}
+				}
+			}
+		}
+
+		return this;
+	},
+
+	removeClass: function( value ) {
+		var classes, elem, cur, clazz, j, finalValue,
+			proceed = arguments.length === 0 || typeof value === "string" && value,
+			i = 0,
+			len = this.length;
+
+		if ( jQuery.isFunction( value ) ) {
+			return this.each(function( j ) {
+				jQuery( this ).removeClass( value.call( this, j, this.className ) );
+			});
+		}
+		if ( proceed ) {
+			classes = ( value || "" ).match( rnotwhite ) || [];
+
+			for ( ; i < len; i++ ) {
+				elem = this[ i ];
+				// This expression is here for better compressibility (see addClass)
+				cur = elem.nodeType === 1 && ( elem.className ?
+					( " " + elem.className + " " ).replace( rclass, " " ) :
+					""
+				);
+
+				if ( cur ) {
+					j = 0;
+					while ( (clazz = classes[j++]) ) {
+						// Remove *all* instances
+						while ( cur.indexOf( " " + clazz + " " ) >= 0 ) {
+							cur = cur.replace( " " + clazz + " ", " " );
+						}
+					}
+
+					// only assign if different to avoid unneeded rendering.
+					finalValue = value ? jQuery.trim( cur ) : "";
+					if ( elem.className !== finalValue ) {
+						elem.className = finalValue;
+					}
+				}
+			}
+		}
+
+		return this;
+	},
+
+	toggleClass: function( value, stateVal ) {
+		var type = typeof value;
+
+		if ( typeof stateVal === "boolean" && type === "string" ) {
+			return stateVal ? this.addClass( value ) : this.removeClass( value );
+		}
+
+		if ( jQuery.isFunction( value ) ) {
+			return this.each(function( i ) {
+				jQuery( this ).toggleClass( value.call(this, i, this.className, stateVal), stateVal );
+			});
+		}
+
+		return this.each(function() {
+			if ( type === "string" ) {
+				// toggle individual class names
+				var className,
+					i = 0,
+					self = jQuery( this ),
+					classNames = value.match( rnotwhite ) || [];
+
+				while ( (className = classNames[ i++ ]) ) {
+					// check each className given, space separated list
+					if ( self.hasClass( className ) ) {
+						self.removeClass( className );
+					} else {
+						self.addClass( className );
+					}
+				}
+
+			// Toggle whole class name
+			} else if ( type === strundefined || type === "boolean" ) {
+				if ( this.className ) {
+					// store className if set
+					data_priv.set( this, "__className__", this.className );
+				}
+
+				// If the element has a class name or if we're passed "false",
+				// then remove the whole classname (if there was one, the above saved it).
+				// Otherwise bring back whatever was previously saved (if anything),
+				// falling back to the empty string if nothing was stored.
+				this.className = this.className || value === false ? "" : data_priv.get( this, "__className__" ) || "";
+			}
+		});
+	},
+
+	hasClass: function( selector ) {
+		var className = " " + selector + " ",
+			i = 0,
+			l = this.length;
+		for ( ; i < l; i++ ) {
+			if ( this[i].nodeType === 1 && (" " + this[i].className + " ").replace(rclass, " ").indexOf( className ) >= 0 ) {
+				return true;
+			}
+		}
+
+		return false;
+	}
+});
+
+
+
+
+var rreturn = /\r/g;
+
+jQuery.fn.extend({
+	val: function( value ) {
+		var hooks, ret, isFunction,
+			elem = this[0];
+
+		if ( !arguments.length ) {
+			if ( elem ) {
+				hooks = jQuery.valHooks[ elem.type ] || jQuery.valHooks[ elem.nodeName.toLowerCase() ];
+
+				if ( hooks && "get" in hooks && (ret = hooks.get( elem, "value" )) !== undefined ) {
+					return ret;
+				}
+
+				ret = elem.value;
+
+				return typeof ret === "string" ?
+					// handle most common string cases
+					ret.replace(rreturn, "") :
+					// handle cases where value is null/undef or number
+					ret == null ? "" : ret;
+			}
+
+			return;
+		}
+
+		isFunction = jQuery.isFunction( value );
+
+		return this.each(function( i ) {
+			var val;
+
+			if ( this.nodeType !== 1 ) {
+				return;
+			}
+
+			if ( isFunction ) {
+				val = value.call( this, i, jQuery( this ).val() );
+			} else {
+				val = value;
+			}
+
+			// Treat null/undefined as ""; convert numbers to string
+			if ( val == null ) {
+				val = "";
+
+			} else if ( typeof val === "number" ) {
+				val += "";
+
+			} else if ( jQuery.isArray( val ) ) {
+				val = jQuery.map( val, function( value ) {
+					return value == null ? "" : value + "";
+				});
+			}
+
+			hooks = jQuery.valHooks[ this.type ] || jQuery.valHooks[ this.nodeName.toLowerCase() ];
+
+			// If set returns undefined, fall back to normal setting
+			if ( !hooks || !("set" in hooks) || hooks.set( this, val, "value" ) === undefined ) {
+				this.value = val;
+			}
+		});
+	}
+});
+
+jQuery.extend({
+	valHooks: {
+		select: {
+			get: function( elem ) {
+				var value, option,
+					options = elem.options,
+					index = elem.selectedIndex,
+					one = elem.type === "select-one" || index < 0,
+					values = one ? null : [],
+					max = one ? index + 1 : options.length,
+					i = index < 0 ?
+						max :
+						one ? index : 0;
+
+				// Loop through all the selected options
+				for ( ; i < max; i++ ) {
+					option = options[ i ];
+
+					// IE6-9 doesn't update selected after form reset (#2551)
+					if ( ( option.selected || i === index ) &&
+							// Don't return options that are disabled or in a disabled optgroup
+							( support.optDisabled ? !option.disabled : option.getAttribute( "disabled" ) === null ) &&
+							( !option.parentNode.disabled || !jQuery.nodeName( option.parentNode, "optgroup" ) ) ) {
+
+						// Get the specific value for the option
+						value = jQuery( option ).val();
+
+						// We don't need an array for one selects
+						if ( one ) {
+							return value;
+						}
+
+						// Multi-Selects return an array
+						values.push( value );
+					}
+				}
+
+				return values;
+			},
+
+			set: function( elem, value ) {
+				var optionSet, option,
+					options = elem.options,
+					values = jQuery.makeArray( value ),
+					i = options.length;
+
+				while ( i-- ) {
+					option = options[ i ];
+					if ( (option.selected = jQuery.inArray( jQuery(option).val(), values ) >= 0) ) {
+						optionSet = true;
+					}
+				}
+
+				// force browsers to behave consistently when non-matching value is set
+				if ( !optionSet ) {
+					elem.selectedIndex = -1;
+				}
+				return values;
+			}
+		}
+	}
+});
+
+// Radios and checkboxes getter/setter
+jQuery.each([ "radio", "checkbox" ], function() {
+	jQuery.valHooks[ this ] = {
+		set: function( elem, value ) {
+			if ( jQuery.isArray( value ) ) {
+				return ( elem.checked = jQuery.inArray( jQuery(elem).val(), value ) >= 0 );
+			}
+		}
+	};
+	if ( !support.checkOn ) {
+		jQuery.valHooks[ this ].get = function( elem ) {
+			// Support: Webkit
+			// "" is returned instead of "on" if a value isn't specified
+			return elem.getAttribute("value") === null ? "on" : elem.value;
+		};
+	}
+});
+
+
+
+
+// Return jQuery for attributes-only inclusion
+
+
+jQuery.each( ("blur focus focusin focusout load resize scroll unload click dblclick " +
+	"mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave " +
+	"change select submit keydown keypress keyup error contextmenu").split(" "), function( i, name ) {
+
+	// Handle event binding
+	jQuery.fn[ name ] = function( data, fn ) {
+		return arguments.length > 0 ?
+			this.on( name, null, data, fn ) :
+			this.trigger( name );
+	};
+});
+
+jQuery.fn.extend({
+	hover: function( fnOver, fnOut ) {
+		return this.mouseenter( fnOver ).mouseleave( fnOut || fnOver );
+	},
+
+	bind: function( types, data, fn ) {
+		return this.on( types, null, data, fn );
+	},
+	unbind: function( types, fn ) {
+		return this.off( types, null, fn );
+	},
+
+	delegate: function( selector, types, data, fn ) {
+		return this.on( types, selector, data, fn );
+	},
+	undelegate: function( selector, types, fn ) {
+		// ( namespace ) or ( selector, types [, fn] )
+		return arguments.length === 1 ? this.off( selector, "**" ) : this.off( types, selector || "**", fn );
+	}
+});
+
+
+var nonce = jQuery.now();
+
+var rquery = (/\?/);
+
+
+
+// Support: Android 2.3
+// Workaround failure to string-cast null input
+jQuery.parseJSON = function( data ) {
+	return JSON.parse( data + "" );
+};
+
+
+// Cross-browser xml parsing
+jQuery.parseXML = function( data ) {
+	var xml, tmp;
+	if ( !data || typeof data !== "string" ) {
+		return null;
+	}
+
+	// Support: IE9
+	try {
+		tmp = new DOMParser();
+		xml = tmp.parseFromString( data, "text/xml" );
+	} catch ( e ) {
+		xml = undefined;
+	}
+
+	if ( !xml || xml.getElementsByTagName( "parsererror" ).length ) {
+		jQuery.error( "Invalid XML: " + data );
+	}
+	return xml;
+};
+
+
+var
+	// Document location
+	ajaxLocParts,
+	ajaxLocation,
+
+	rhash = /#.*$/,
+	rts = /([?&])_=[^&]*/,
+	rheaders = /^(.*?):[ \t]*([^\r\n]*)$/mg,
+	// #7653, #8125, #8152: local protocol detection
+	rlocalProtocol = /^(?:about|app|app-storage|.+-extension|file|res|widget):$/,
+	rnoContent = /^(?:GET|HEAD)$/,
+	rprotocol = /^\/\//,
+	rurl = /^([\w.+-]+:)(?:\/\/(?:[^\/?#]*@|)([^\/?#:]*)(?::(\d+)|)|)/,
+
+	/* Prefilters
+	 * 1) They are useful to introduce custom dataTypes (see ajax/jsonp.js for an example)
+	 * 2) These are called:
+	 *    - BEFORE asking for a transport
+	 *    - AFTER param serialization (s.data is a string if s.processData is true)
+	 * 3) key is the dataType
+	 * 4) the catchall symbol "*" can be used
+	 * 5) execution will start with transport dataType and THEN continue down to "*" if needed
+	 */
+	prefilters = {},
+
+	/* Transports bindings
+	 * 1) key is the dataType
+	 * 2) the catchall symbol "*" can be used
+	 * 3) selection will start with transport dataType and THEN go to "*" if needed
+	 */
+	transports = {},
+
+	// Avoid comment-prolog char sequence (#10098); must appease lint and evade compression
+	allTypes = "*/".concat("*");
+
+// #8138, IE may throw an exception when accessing
+// a field from window.location if document.domain has been set
+try {
+	ajaxLocation = location.href;
+} catch( e ) {
+	// Use the href attribute of an A element
+	// since IE will modify it given document.location
+	ajaxLocation = document.createElement( "a" );
+	ajaxLocation.href = "";
+	ajaxLocation = ajaxLocation.href;
+}
+
+// Segment location into parts
+ajaxLocParts = rurl.exec( ajaxLocation.toLowerCase() ) || [];
+
+// Base "constructor" for jQuery.ajaxPrefilter and jQuery.ajaxTransport
+function addToPrefiltersOrTransports( structure ) {
+
+	// dataTypeExpression is optional and defaults to "*"
+	return function( dataTypeExpression, func ) {
+
+		if ( typeof dataTypeExpression !== "string" ) {
+			func = dataTypeExpression;
+			dataTypeExpression = "*";
+		}
+
+		var dataType,
+			i = 0,
+			dataTypes = dataTypeExpression.toLowerCase().match( rnotwhite ) || [];
+
+		if ( jQuery.isFunction( func ) ) {
+			// For each dataType in the dataTypeExpression
+			while ( (dataType = dataTypes[i++]) ) {
+				// Prepend if requested
+				if ( dataType[0] === "+" ) {
+					dataType = dataType.slice( 1 ) || "*";
+					(structure[ dataType ] = structure[ dataType ] || []).unshift( func );
+
+				// Otherwise append
+				} else {
+					(structure[ dataType ] = structure[ dataType ] || []).push( func );
+				}
+			}
+		}
+	};
+}
+
+// Base inspection function for prefilters and transports
+function inspectPrefiltersOrTransports( structure, options, originalOptions, jqXHR ) {
+
+	var inspected = {},
+		seekingTransport = ( structure === transports );
+
+	function inspect( dataType ) {
+		var selected;
+		inspected[ dataType ] = true;
+		jQuery.each( structure[ dataType ] || [], function( _, prefilterOrFactory ) {
+			var dataTypeOrTransport = prefilterOrFactory( options, originalOptions, jqXHR );
+			if ( typeof dataTypeOrTransport === "string" && !seekingTransport && !inspected[ dataTypeOrTransport ] ) {
+				options.dataTypes.unshift( dataTypeOrTransport );
+				inspect( dataTypeOrTransport );
+				return false;
+			} else if ( seekingTransport ) {
+				return !( selected = dataTypeOrTransport );
+			}
+		});
+		return selected;
+	}
+
+	return inspect( options.dataTypes[ 0 ] ) || !inspected[ "*" ] && inspect( "*" );
+}
+
+// A special extend for ajax options
+// that takes "flat" options (not to be deep extended)
+// Fixes #9887
+function ajaxExtend( target, src ) {
+	var key, deep,
+		flatOptions = jQuery.ajaxSettings.flatOptions || {};
+
+	for ( key in src ) {
+		if ( src[ key ] !== undefined ) {
+			( flatOptions[ key ] ? target : ( deep || (deep = {}) ) )[ key ] = src[ key ];
+		}
+	}
+	if ( deep ) {
+		jQuery.extend( true, target, deep );
+	}
+
+	return target;
+}
+
+/* Handles responses to an ajax request:
+ * - finds the right dataType (mediates between content-type and expected dataType)
+ * - returns the corresponding response
+ */
+function ajaxHandleResponses( s, jqXHR, responses ) {
+
+	var ct, type, finalDataType, firstDataType,
+		contents = s.contents,
+		dataTypes = s.dataTypes;
+
+	// Remove auto dataType and get content-type in the process
+	while ( dataTypes[ 0 ] === "*" ) {
+		dataTypes.shift();
+		if ( ct === undefined ) {
+			ct = s.mimeType || jqXHR.getResponseHeader("Content-Type");
+		}
+	}
+
+	// Check if we're dealing with a known content-type
+	if ( ct ) {
+		for ( type in contents ) {
+			if ( contents[ type ] && contents[ type ].test( ct ) ) {
+				dataTypes.unshift( type );
+				break;
+			}
+		}
+	}
+
+	// Check to see if we have a response for the expected dataType
+	if ( dataTypes[ 0 ] in responses ) {
+		finalDataType = dataTypes[ 0 ];
+	} else {
+		// Try convertible dataTypes
+		for ( type in responses ) {
+			if ( !dataTypes[ 0 ] || s.converters[ type + " " + dataTypes[0] ] ) {
+				finalDataType = type;
+				break;
+			}
+			if ( !firstDataType ) {
+				firstDataType = type;
+			}
+		}
+		// Or just use first one
+		finalDataType = finalDataType || firstDataType;
+	}
+
+	// If we found a dataType
+	// We add the dataType to the list if needed
+	// and return the corresponding response
+	if ( finalDataType ) {
+		if ( finalDataType !== dataTypes[ 0 ] ) {
+			dataTypes.unshift( finalDataType );
+		}
+		return responses[ finalDataType ];
+	}
+}
+
+/* Chain conversions given the request and the original response
+ * Also sets the responseXXX fields on the jqXHR instance
+ */
+function ajaxConvert( s, response, jqXHR, isSuccess ) {
+	var conv2, current, conv, tmp, prev,
+		converters = {},
+		// Work with a copy of dataTypes in case we need to modify it for conversion
+		dataTypes = s.dataTypes.slice();
+
+	// Create converters map with lowercased keys
+	if ( dataTypes[ 1 ] ) {
+		for ( conv in s.converters ) {
+			converters[ conv.toLowerCase() ] = s.converters[ conv ];
+		}
+	}
+
+	current = dataTypes.shift();
+
+	// Convert to each sequential dataType
+	while ( current ) {
+
+		if ( s.responseFields[ current ] ) {
+			jqXHR[ s.responseFields[ current ] ] = response;
+		}
+
+		// Apply the dataFilter if provided
+		if ( !prev && isSuccess && s.dataFilter ) {
+			response = s.dataFilter( response, s.dataType );
+		}
+
+		prev = current;
+		current = dataTypes.shift();
+
+		if ( current ) {
+
+		// There's only work to do if current dataType is non-auto
+			if ( current === "*" ) {
+
+				current = prev;
+
+			// Convert response if prev dataType is non-auto and differs from current
+			} else if ( prev !== "*" && prev !== current ) {
+
+				// Seek a direct converter
+				conv = converters[ prev + " " + current ] || converters[ "* " + current ];
+
+				// If none found, seek a pair
+				if ( !conv ) {
+					for ( conv2 in converters ) {
+
+						// If conv2 outputs current
+						tmp = conv2.split( " " );
+						if ( tmp[ 1 ] === current ) {
+
+							// If prev can be converted to accepted input
+							conv = converters[ prev + " " + tmp[ 0 ] ] ||
+								converters[ "* " + tmp[ 0 ] ];
+							if ( conv ) {
+								// Condense equivalence converters
+								if ( conv === true ) {
+									conv = converters[ conv2 ];
+
+								// Otherwise, insert the intermediate dataType
+								} else if ( converters[ conv2 ] !== true ) {
+									current = tmp[ 0 ];
+									dataTypes.unshift( tmp[ 1 ] );
+								}
+								break;
+							}
+						}
+					}
+				}
+
+				// Apply converter (if not an equivalence)
+				if ( conv !== true ) {
+
+					// Unless errors are allowed to bubble, catch and return them
+					if ( conv && s[ "throws" ] ) {
+						response = conv( response );
+					} else {
+						try {
+							response = conv( response );
+						} catch ( e ) {
+							return { state: "parsererror", error: conv ? e : "No conversion from " + prev + " to " + current };
+						}
+					}
+				}
+			}
+		}
+	}
+
+	return { state: "success", data: response };
+}
+
+jQuery.extend({
+
+	// Counter for holding the number of active queries
+	active: 0,
+
+	// Last-Modified header cache for next request
+	lastModified: {},
+	etag: {},
+
+	ajaxSettings: {
+		url: ajaxLocation,
+		type: "GET",
+		isLocal: rlocalProtocol.test( ajaxLocParts[ 1 ] ),
+		global: true,
+		processData: true,
+		async: true,
+		contentType: "application/x-www-form-urlencoded; charset=UTF-8",
+		/*
+		timeout: 0,
+		data: null,
+		dataType: null,
+		username: null,
+		password: null,
+		cache: null,
+		throws: false,
+		traditional: false,
+		headers: {},
+		*/
+
+		accepts: {
+			"*": allTypes,
+			text: "text/plain",
+			html: "text/html",
+			xml: "application/xml, text/xml",
+			json: "application/json, text/javascript"
+		},
+
+		contents: {
+			xml: /xml/,
+			html: /html/,
+			json: /json/
+		},
+
+		responseFields: {
+			xml: "responseXML",
+			text: "responseText",
+			json: "responseJSON"
+		},
+
+		// Data converters
+		// Keys separate source (or catchall "*") and destination types with a single space
+		converters: {
+
+			// Convert anything to text
+			"* text": String,
+
+			// Text to html (true = no transformation)
+			"text html": true,
+
+			// Evaluate text as a json expression
+			"text json": jQuery.parseJSON,
+
+			// Parse text as xml
+			"text xml": jQuery.parseXML
+		},
+
+		// For options that shouldn't be deep extended:
+		// you can add your own custom options here if
+		// and when you create one that shouldn't be
+		// deep extended (see ajaxExtend)
+		flatOptions: {
+			url: true,
+			context: true
+		}
+	},
+
+	// Creates a full fledged settings object into target
+	// with both ajaxSettings and settings fields.
+	// If target is omitted, writes into ajaxSettings.
+	ajaxSetup: function( target, settings ) {
+		return settings ?
+
+			// Building a settings object
+			ajaxExtend( ajaxExtend( target, jQuery.ajaxSettings ), settings ) :
+
+			// Extending ajaxSettings
+			ajaxExtend( jQuery.ajaxSettings, target );
+	},
+
+	ajaxPrefilter: addToPrefiltersOrTransports( prefilters ),
+	ajaxTransport: addToPrefiltersOrTransports( transports ),
+
+	// Main method
+	ajax: function( url, options ) {
+
+		// If url is an object, simulate pre-1.5 signature
+		if ( typeof url === "object" ) {
+			options = url;
+			url = undefined;
+		}
+
+		// Force options to be an object
+		options = options || {};
+
+		var transport,
+			// URL without anti-cache param
+			cacheURL,
+			// Response headers
+			responseHeadersString,
+			responseHeaders,
+			// timeout handle
+			timeoutTimer,
+			// Cross-domain detection vars
+			parts,
+			// To know if global events are to be dispatched
+			fireGlobals,
+			// Loop variable
+			i,
+			// Create the final options object
+			s = jQuery.ajaxSetup( {}, options ),
+			// Callbacks context
+			callbackContext = s.context || s,
+			// Context for global events is callbackContext if it is a DOM node or jQuery collection
+			globalEventContext = s.context && ( callbackContext.nodeType || callbackContext.jquery ) ?
+				jQuery( callbackContext ) :
+				jQuery.event,
+			// Deferreds
+			deferred = jQuery.Deferred(),
+			completeDeferred = jQuery.Callbacks("once memory"),
+			// Status-dependent callbacks
+			statusCode = s.statusCode || {},
+			// Headers (they are sent all at once)
+			requestHeaders = {},
+			requestHeadersNames = {},
+			// The jqXHR state
+			state = 0,
+			// Default abort message
+			strAbort = "canceled",
+			// Fake xhr
+			jqXHR = {
+				readyState: 0,
+
+				// Builds headers hashtable if needed
+				getResponseHeader: function( key ) {
+					var match;
+					if ( state === 2 ) {
+						if ( !responseHeaders ) {
+							responseHeaders = {};
+							while ( (match = rheaders.exec( responseHeadersString )) ) {
+								responseHeaders[ match[1].toLowerCase() ] = match[ 2 ];
+							}
+						}
+						match = responseHeaders[ key.toLowerCase() ];
+					}
+					return match == null ? null : match;
+				},
+
+				// Raw string
+				getAllResponseHeaders: function() {
+					return state === 2 ? responseHeadersString : null;
+				},
+
+				// Caches the header
+				setRequestHeader: function( name, value ) {
+					var lname = name.toLowerCase();
+					if ( !state ) {
+						name = requestHeadersNames[ lname ] = requestHeadersNames[ lname ] || name;
+						requestHeaders[ name ] = value;
+					}
+					return this;
+				},
+
+				// Overrides response content-type header
+				overrideMimeType: function( type ) {
+					if ( !state ) {
+						s.mimeType = type;
+					}
+					return this;
+				},
+
+				// Status-dependent callbacks
+				statusCode: function( map ) {
+					var code;
+					if ( map ) {
+						if ( state < 2 ) {
+							for ( code in map ) {
+								// Lazy-add the new callback in a way that preserves old ones
+								statusCode[ code ] = [ statusCode[ code ], map[ code ] ];
+							}
+						} else {
+							// Execute the appropriate callbacks
+							jqXHR.always( map[ jqXHR.status ] );
+						}
+					}
+					return this;
+				},
+
+				// Cancel the request
+				abort: function( statusText ) {
+					var finalText = statusText || strAbort;
+					if ( transport ) {
+						transport.abort( finalText );
+					}
+					done( 0, finalText );
+					return this;
+				}
+			};
+
+		// Attach deferreds
+		deferred.promise( jqXHR ).complete = completeDeferred.add;
+		jqXHR.success = jqXHR.done;
+		jqXHR.error = jqXHR.fail;
+
+		// Remove hash character (#7531: and string promotion)
+		// Add protocol if not provided (prefilters might expect it)
+		// Handle falsy url in the settings object (#10093: consistency with old signature)
+		// We also use the url parameter if available
+		s.url = ( ( url || s.url || ajaxLocation ) + "" ).replace( rhash, "" )
+			.replace( rprotocol, ajaxLocParts[ 1 ] + "//" );
+
+		// Alias method option to type as per ticket #12004
+		s.type = options.method || options.type || s.method || s.type;
+
+		// Extract dataTypes list
+		s.dataTypes = jQuery.trim( s.dataType || "*" ).toLowerCase().match( rnotwhite ) || [ "" ];
+
+		// A cross-domain request is in order when we have a protocol:host:port mismatch
+		if ( s.crossDomain == null ) {
+			parts = rurl.exec( s.url.toLowerCase() );
+			s.crossDomain = !!( parts &&
+				( parts[ 1 ] !== ajaxLocParts[ 1 ] || parts[ 2 ] !== ajaxLocParts[ 2 ] ||
+					( parts[ 3 ] || ( parts[ 1 ] === "http:" ? "80" : "443" ) ) !==
+						( ajaxLocParts[ 3 ] || ( ajaxLocParts[ 1 ] === "http:" ? "80" : "443" ) ) )
+			);
+		}
+
+		// Convert data if not already a string
+		if ( s.data && s.processData && typeof s.data !== "string" ) {
+			s.data = jQuery.param( s.data, s.traditional );
+		}
+
+		// Apply prefilters
+		inspectPrefiltersOrTransports( prefilters, s, options, jqXHR );
+
+		// If request was aborted inside a prefilter, stop there
+		if ( state === 2 ) {
+			return jqXHR;
+		}
+
+		// We can fire global events as of now if asked to
+		fireGlobals = s.global;
+
+		// Watch for a new set of requests
+		if ( fireGlobals && jQuery.active++ === 0 ) {
+			jQuery.event.trigger("ajaxStart");
+		}
+
+		// Uppercase the type
+		s.type = s.type.toUpperCase();
+
+		// Determine if request has content
+		s.hasContent = !rnoContent.test( s.type );
+
+		// Save the URL in case we're toying with the If-Modified-Since
+		// and/or If-None-Match header later on
+		cacheURL = s.url;
+
+		// More options handling for requests with no content
+		if ( !s.hasContent ) {
+
+			// If data is available, append data to url
+			if ( s.data ) {
+				cacheURL = ( s.url += ( rquery.test( cacheURL ) ? "&" : "?" ) + s.data );
+				// #9682: remove data so that it's not used in an eventual retry
+				delete s.data;
+			}
+
+			// Add anti-cache in url if needed
+			if ( s.cache === false ) {
+				s.url = rts.test( cacheURL ) ?
+
+					// If there is already a '_' parameter, set its value
+					cacheURL.replace( rts, "$1_=" + nonce++ ) :
+
+					// Otherwise add one to the end
+					cacheURL + ( rquery.test( cacheURL ) ? "&" : "?" ) + "_=" + nonce++;
+			}
+		}
+
+		// Set the If-Modified-Since and/or If-None-Match header, if in ifModified mode.
+		if ( s.ifModified ) {
+			if ( jQuery.lastModified[ cacheURL ] ) {
+				jqXHR.setRequestHeader( "If-Modified-Since", jQuery.lastModified[ cacheURL ] );
+			}
+			if ( jQuery.etag[ cacheURL ] ) {
+				jqXHR.setRequestHeader( "If-None-Match", jQuery.etag[ cacheURL ] );
+			}
+		}
+
+		// Set the correct header, if data is being sent
+		if ( s.data && s.hasContent && s.contentType !== false || options.contentType ) {
+			jqXHR.setRequestHeader( "Content-Type", s.contentType );
+		}
+
+		// Set the Accepts header for the server, depending on the dataType
+		jqXHR.setRequestHeader(
+			"Accept",
+			s.dataTypes[ 0 ] && s.accepts[ s.dataTypes[0] ] ?
+				s.accepts[ s.dataTypes[0] ] + ( s.dataTypes[ 0 ] !== "*" ? ", " + allTypes + "; q=0.01" : "" ) :
+				s.accepts[ "*" ]
+		);
+
+		// Check for headers option
+		for ( i in s.headers ) {
+			jqXHR.setRequestHeader( i, s.headers[ i ] );
+		}
+
+		// Allow custom headers/mimetypes and early abort
+		if ( s.beforeSend && ( s.beforeSend.call( callbackContext, jqXHR, s ) === false || state === 2 ) ) {
+			// Abort if not done already and return
+			return jqXHR.abort();
+		}
+
+		// aborting is no longer a cancellation
+		strAbort = "abort";
+
+		// Install callbacks on deferreds
+		for ( i in { success: 1, error: 1, complete: 1 } ) {
+			jqXHR[ i ]( s[ i ] );
+		}
+
+		// Get transport
+		transport = inspectPrefiltersOrTransports( transports, s, options, jqXHR );
+
+		// If no transport, we auto-abort
+		if ( !transport ) {
+			done( -1, "No Transport" );
+		} else {
+			jqXHR.readyState = 1;
+
+			// Send global event
+			if ( fireGlobals ) {
+				globalEventContext.trigger( "ajaxSend", [ jqXHR, s ] );
+			}
+			// Timeout
+			if ( s.async && s.timeout > 0 ) {
+				timeoutTimer = setTimeout(function() {
+					jqXHR.abort("timeout");
+				}, s.timeout );
+			}
+
+			try {
+				state = 1;
+				transport.send( requestHeaders, done );
+			} catch ( e ) {
+				// Propagate exception as error if not done
+				if ( state < 2 ) {
+					done( -1, e );
+				// Simply rethrow otherwise
+				} else {
+					throw e;
+				}
+			}
+		}
+
+		// Callback for when everything is done
+		function done( status, nativeStatusText, responses, headers ) {
+			var isSuccess, success, error, response, modified,
+				statusText = nativeStatusText;
+
+			// Called once
+			if ( state === 2 ) {
+				return;
+			}
+
+			// State is "done" now
+			state = 2;
+
+			// Clear timeout if it exists
+			if ( timeoutTimer ) {
+				clearTimeout( timeoutTimer );
+			}
+
+			// Dereference transport for early garbage collection
+			// (no matter how long the jqXHR object will be used)
+			transport = undefined;
+
+			// Cache response headers
+			responseHeadersString = headers || "";
+
+			// Set readyState
+			jqXHR.readyState = status > 0 ? 4 : 0;
+
+			// Determine if successful
+			isSuccess = status >= 200 && status < 300 || status === 304;
+
+			// Get response data
+			if ( responses ) {
+				response = ajaxHandleResponses( s, jqXHR, responses );
+			}
+
+			// Convert no matter what (that way responseXXX fields are always set)
+			response = ajaxConvert( s, response, jqXHR, isSuccess );
+
+			// If successful, handle type chaining
+			if ( isSuccess ) {
+
+				// Set the If-Modified-Since and/or If-None-Match header, if in ifModified mode.
+				if ( s.ifModified ) {
+					modified = jqXHR.getResponseHeader("Last-Modified");
+					if ( modified ) {
+						jQuery.lastModified[ cacheURL ] = modified;
+					}
+					modified = jqXHR.getResponseHeader("etag");
+					if ( modified ) {
+						jQuery.etag[ cacheURL ] = modified;
+					}
+				}
+
+				// if no content
+				if ( status === 204 || s.type === "HEAD" ) {
+					statusText = "nocontent";
+
+				// if not modified
+				} else if ( status === 304 ) {
+					statusText = "notmodified";
+
+				// If we have data, let's convert it
+				} else {
+					statusText = response.state;
+					success = response.data;
+					error = response.error;
+					isSuccess = !error;
+				}
+			} else {
+				// We extract error from statusText
+				// then normalize statusText and status for non-aborts
+				error = statusText;
+				if ( status || !statusText ) {
+					statusText = "error";
+					if ( status < 0 ) {
+						status = 0;
+					}
+				}
+			}
+
+			// Set data for the fake xhr object
+			jqXHR.status = status;
+			jqXHR.statusText = ( nativeStatusText || statusText ) + "";
+
+			// Success/Error
+			if ( isSuccess ) {
+				deferred.resolveWith( callbackContext, [ success, statusText, jqXHR ] );
+			} else {
+				deferred.rejectWith( callbackContext, [ jqXHR, statusText, error ] );
+			}
+
+			// Status-dependent callbacks
+			jqXHR.statusCode( statusCode );
+			statusCode = undefined;
+
+			if ( fireGlobals ) {
+				globalEventContext.trigger( isSuccess ? "ajaxSuccess" : "ajaxError",
+					[ jqXHR, s, isSuccess ? success : error ] );
+			}
+
+			// Complete
+			completeDeferred.fireWith( callbackContext, [ jqXHR, statusText ] );
+
+			if ( fireGlobals ) {
+				globalEventContext.trigger( "ajaxComplete", [ jqXHR, s ] );
+				// Handle the global AJAX counter
+				if ( !( --jQuery.active ) ) {
+					jQuery.event.trigger("ajaxStop");
+				}
+			}
+		}
+
+		return jqXHR;
+	},
+
+	getJSON: function( url, data, callback ) {
+		return jQuery.get( url, data, callback, "json" );
+	},
+
+	getScript: function( url, callback ) {
+		return jQuery.get( url, undefined, callback, "script" );
+	}
+});
+
+jQuery.each( [ "get", "post" ], function( i, method ) {
+	jQuery[ method ] = function( url, data, callback, type ) {
+		// shift arguments if data argument was omitted
+		if ( jQuery.isFunction( data ) ) {
+			type = type || callback;
+			callback = data;
+			data = undefined;
+		}
+
+		return jQuery.ajax({
+			url: url,
+			type: method,
+			dataType: type,
+			data: data,
+			success: callback
+		});
+	};
+});
+
+// Attach a bunch of functions for handling common AJAX events
+jQuery.each( [ "ajaxStart", "ajaxStop", "ajaxComplete", "ajaxError", "ajaxSuccess", "ajaxSend" ], function( i, type ) {
+	jQuery.fn[ type ] = function( fn ) {
+		return this.on( type, fn );
+	};
+});
+
+
+jQuery._evalUrl = function( url ) {
+	return jQuery.ajax({
+		url: url,
+		type: "GET",
+		dataType: "script",
+		async: false,
+		global: false,
+		"throws": true
+	});
+};
+
+
+jQuery.fn.extend({
+	wrapAll: function( html ) {
+		var wrap;
+
+		if ( jQuery.isFunction( html ) ) {
+			return this.each(function( i ) {
+				jQuery( this ).wrapAll( html.call(this, i) );
+			});
+		}
+
+		if ( this[ 0 ] ) {
+
+			// The elements to wrap the target around
+			wrap = jQuery( html, this[ 0 ].ownerDocument ).eq( 0 ).clone( true );
+
+			if ( this[ 0 ].parentNode ) {
+				wrap.insertBefore( this[ 0 ] );
+			}
+
+			wrap.map(function() {
+				var elem = this;
+
+				while ( elem.firstElementChild ) {
+					elem = elem.firstElementChild;
+				}
+
+				return elem;
+			}).append( this );
+		}
+
+		return this;
+	},
+
+	wrapInner: function( html ) {
+		if ( jQuery.isFunction( html ) ) {
+			return this.each(function( i ) {
+				jQuery( this ).wrapInner( html.call(this, i) );
+			});
+		}
+
+		return this.each(function() {
+			var self = jQuery( this ),
+				contents = self.contents();
+
+			if ( contents.length ) {
+				contents.wrapAll( html );
+
+			} else {
+				self.append( html );
+			}
+		});
+	},
+
+	wrap: function( html ) {
+		var isFunction = jQuery.isFunction( html );
+
+		return this.each(function( i ) {
+			jQuery( this ).wrapAll( isFunction ? html.call(this, i) : html );
+		});
+	},
+
+	unwrap: function() {
+		return this.parent().each(function() {
+			if ( !jQuery.nodeName( this, "body" ) ) {
+				jQuery( this ).replaceWith( this.childNodes );
+			}
+		}).end();
+	}
+});
+
+
+jQuery.expr.filters.hidden = function( elem ) {
+	// Support: Opera <= 12.12
+	// Opera reports offsetWidths and offsetHeights less than zero on some elements
+	return elem.offsetWidth <= 0 && elem.offsetHeight <= 0;
+};
+jQuery.expr.filters.visible = function( elem ) {
+	return !jQuery.expr.filters.hidden( elem );
+};
+
+
+
+
+var r20 = /%20/g,
+	rbracket = /\[\]$/,
+	rCRLF = /\r?\n/g,
+	rsubmitterTypes = /^(?:submit|button|image|reset|file)$/i,
+	rsubmittable = /^(?:input|select|textarea|keygen)/i;
+
+function buildParams( prefix, obj, traditional, add ) {
+	var name;
+
+	if ( jQuery.isArray( obj ) ) {
+		// Serialize array item.
+		jQuery.each( obj, function( i, v ) {
+			if ( traditional || rbracket.test( prefix ) ) {
+				// Treat each array item as a scalar.
+				add( prefix, v );
+
+			} else {
+				// Item is non-scalar (array or object), encode its numeric index.
+				buildParams( prefix + "[" + ( typeof v === "object" ? i : "" ) + "]", v, traditional, add );
+			}
+		});
+
+	} else if ( !traditional && jQuery.type( obj ) === "object" ) {
+		// Serialize object item.
+		for ( name in obj ) {
+			buildParams( prefix + "[" + name + "]", obj[ name ], traditional, add );
+		}
+
+	} else {
+		// Serialize scalar item.
+		add( prefix, obj );
+	}
+}
+
+// Serialize an array of form elements or a set of
+// key/values into a query string
+jQuery.param = function( a, traditional ) {
+	var prefix,
+		s = [],
+		add = function( key, value ) {
+			// If value is a function, invoke it and return its value
+			value = jQuery.isFunction( value ) ? value() : ( value == null ? "" : value );
+			s[ s.length ] = encodeURIComponent( key ) + "=" + encodeURIComponent( value );
+		};
+
+	// Set traditional to true for jQuery <= 1.3.2 behavior.
+	if ( traditional === undefined ) {
+		traditional = jQuery.ajaxSettings && jQuery.ajaxSettings.traditional;
+	}
+
+	// If an array was passed in, assume that it is an array of form elements.
+	if ( jQuery.isArray( a ) || ( a.jquery && !jQuery.isPlainObject( a ) ) ) {
+		// Serialize the form elements
+		jQuery.each( a, function() {
+			add( this.name, this.value );
+		});
+
+	} else {
+		// If traditional, encode the "old" way (the way 1.3.2 or older
+		// did it), otherwise encode params recursively.
+		for ( prefix in a ) {
+			buildParams( prefix, a[ prefix ], traditional, add );
+		}
+	}
+
+	// Return the resulting serialization
+	return s.join( "&" ).replace( r20, "+" );
+};
+
+jQuery.fn.extend({
+	serialize: function() {
+		return jQuery.param( this.serializeArray() );
+	},
+	serializeArray: function() {
+		return this.map(function() {
+			// Can add propHook for "elements" to filter or add form elements
+			var elements = jQuery.prop( this, "elements" );
+			return elements ? jQuery.makeArray( elements ) : this;
+		})
+		.filter(function() {
+			var type = this.type;
+
+			// Use .is( ":disabled" ) so that fieldset[disabled] works
+			return this.name && !jQuery( this ).is( ":disabled" ) &&
+				rsubmittable.test( this.nodeName ) && !rsubmitterTypes.test( type ) &&
+				( this.checked || !rcheckableType.test( type ) );
+		})
+		.map(function( i, elem ) {
+			var val = jQuery( this ).val();
+
+			return val == null ?
+				null :
+				jQuery.isArray( val ) ?
+					jQuery.map( val, function( val ) {
+						return { name: elem.name, value: val.replace( rCRLF, "\r\n" ) };
+					}) :
+					{ name: elem.name, value: val.replace( rCRLF, "\r\n" ) };
+		}).get();
+	}
+});
+
+
+jQuery.ajaxSettings.xhr = function() {
+	try {
+		return new XMLHttpRequest();
+	} catch( e ) {}
+};
+
+var xhrId = 0,
+	xhrCallbacks = {},
+	xhrSuccessStatus = {
+		// file protocol always yields status code 0, assume 200
+		0: 200,
+		// Support: IE9
+		// #1450: sometimes IE returns 1223 when it should be 204
+		1223: 204
+	},
+	xhrSupported = jQuery.ajaxSettings.xhr();
+
+// Support: IE9
+// Open requests must be manually aborted on unload (#5280)
+if ( window.ActiveXObject ) {
+	jQuery( window ).on( "unload", function() {
+		for ( var key in xhrCallbacks ) {
+			xhrCallbacks[ key ]();
+		}
+	});
+}
+
+support.cors = !!xhrSupported && ( "withCredentials" in xhrSupported );
+support.ajax = xhrSupported = !!xhrSupported;
+
+jQuery.ajaxTransport(function( options ) {
+	var callback;
+
+	// Cross domain only allowed if supported through XMLHttpRequest
+	if ( support.cors || xhrSupported && !options.crossDomain ) {
+		return {
+			send: function( headers, complete ) {
+				var i,
+					xhr = options.xhr(),
+					id = ++xhrId;
+
+				xhr.open( options.type, options.url, options.async, options.username, options.password );
+
+				// Apply custom fields if provided
+				if ( options.xhrFields ) {
+					for ( i in options.xhrFields ) {
+						xhr[ i ] = options.xhrFields[ i ];
+					}
+				}
+
+				// Override mime type if needed
+				if ( options.mimeType && xhr.overrideMimeType ) {
+					xhr.overrideMimeType( options.mimeType );
+				}
+
+				// X-Requested-With header
+				// For cross-domain requests, seeing as conditions for a preflight are
+				// akin to a jigsaw puzzle, we simply never set it to be sure.
+				// (it can always be set on a per-request basis or even using ajaxSetup)
+				// For same-domain requests, won't change header if already provided.
+				if ( !options.crossDomain && !headers["X-Requested-With"] ) {
+					headers["X-Requested-With"] = "XMLHttpRequest";
+				}
+
+				// Set headers
+				for ( i in headers ) {
+					xhr.setRequestHeader( i, headers[ i ] );
+				}
+
+				// Callback
+				callback = function( type ) {
+					return function() {
+						if ( callback ) {
+							delete xhrCallbacks[ id ];
+							callback = xhr.onload = xhr.onerror = null;
+
+							if ( type === "abort" ) {
+								xhr.abort();
+							} else if ( type === "error" ) {
+								complete(
+									// file: protocol always yields status 0; see #8605, #14207
+									xhr.status,
+									xhr.statusText
+								);
+							} else {
+								complete(
+									xhrSuccessStatus[ xhr.status ] || xhr.status,
+									xhr.statusText,
+									// Support: IE9
+									// Accessing binary-data responseText throws an exception
+									// (#11426)
+									typeof xhr.responseText === "string" ? {
+										text: xhr.responseText
+									} : undefined,
+									xhr.getAllResponseHeaders()
+								);
+							}
+						}
+					};
+				};
+
+				// Listen to events
+				xhr.onload = callback();
+				xhr.onerror = callback("error");
+
+				// Create the abort callback
+				callback = xhrCallbacks[ id ] = callback("abort");
+
+				// Do send the request
+				// This may raise an exception which is actually
+				// handled in jQuery.ajax (so no try/catch here)
+				xhr.send( options.hasContent && options.data || null );
+			},
+
+			abort: function() {
+				if ( callback ) {
+					callback();
+				}
+			}
+		};
+	}
+});
+
+
+
+
+// Install script dataType
+jQuery.ajaxSetup({
+	accepts: {
+		script: "text/javascript, application/javascript, application/ecmascript, application/x-ecmascript"
+	},
+	contents: {
+		script: /(?:java|ecma)script/
+	},
+	converters: {
+		"text script": function( text ) {
+			jQuery.globalEval( text );
+			return text;
+		}
+	}
+});
+
+// Handle cache's special case and crossDomain
+jQuery.ajaxPrefilter( "script", function( s ) {
+	if ( s.cache === undefined ) {
+		s.cache = false;
+	}
+	if ( s.crossDomain ) {
+		s.type = "GET";
+	}
+});
+
+// Bind script tag hack transport
+jQuery.ajaxTransport( "script", function( s ) {
+	// This transport only deals with cross domain requests
+	if ( s.crossDomain ) {
+		var script, callback;
+		return {
+			send: function( _, complete ) {
+				script = jQuery("<script>").prop({
+					async: true,
+					charset: s.scriptCharset,
+					src: s.url
+				}).on(
+					"load error",
+					callback = function( evt ) {
+						script.remove();
+						callback = null;
+						if ( evt ) {
+							complete( evt.type === "error" ? 404 : 200, evt.type );
+						}
+					}
+				);
+				document.head.appendChild( script[ 0 ] );
+			},
+			abort: function() {
+				if ( callback ) {
+					callback();
+				}
+			}
+		};
+	}
+});
+
+
+
+
+var oldCallbacks = [],
+	rjsonp = /(=)\?(?=&|$)|\?\?/;
+
+// Default jsonp settings
+jQuery.ajaxSetup({
+	jsonp: "callback",
+	jsonpCallback: function() {
+		var callback = oldCallbacks.pop() || ( jQuery.expando + "_" + ( nonce++ ) );
+		this[ callback ] = true;
+		return callback;
+	}
+});
+
+// Detect, normalize options and install callbacks for jsonp requests
+jQuery.ajaxPrefilter( "json jsonp", function( s, originalSettings, jqXHR ) {
+
+	var callbackName, overwritten, responseContainer,
+		jsonProp = s.jsonp !== false && ( rjsonp.test( s.url ) ?
+			"url" :
+			typeof s.data === "string" && !( s.contentType || "" ).indexOf("application/x-www-form-urlencoded") && rjsonp.test( s.data ) && "data"
+		);
+
+	// Handle iff the expected data type is "jsonp" or we have a parameter to set
+	if ( jsonProp || s.dataTypes[ 0 ] === "jsonp" ) {
+
+		// Get callback name, remembering preexisting value associated with it
+		callbackName = s.jsonpCallback = jQuery.isFunction( s.jsonpCallback ) ?
+			s.jsonpCallback() :
+			s.jsonpCallback;
+
+		// Insert callback into url or form data
+		if ( jsonProp ) {
+			s[ jsonProp ] = s[ jsonProp ].replace( rjsonp, "$1" + callbackName );
+		} else if ( s.jsonp !== false ) {
+			s.url += ( rquery.test( s.url ) ? "&" : "?" ) + s.jsonp + "=" + callbackName;
+		}
+
+		// Use data converter to retrieve json after script execution
+		s.converters["script json"] = function() {
+			if ( !responseContainer ) {
+				jQuery.error( callbackName + " was not called" );
+			}
+			return responseContainer[ 0 ];
+		};
+
+		// force json dataType
+		s.dataTypes[ 0 ] = "json";
+
+		// Install callback
+		overwritten = window[ callbackName ];
+		window[ callbackName ] = function() {
+			responseContainer = arguments;
+		};
+
+		// Clean-up function (fires after converters)
+		jqXHR.always(function() {
+			// Restore preexisting value
+			window[ callbackName ] = overwritten;
+
+			// Save back as free
+			if ( s[ callbackName ] ) {
+				// make sure that re-using the options doesn't screw things around
+				s.jsonpCallback = originalSettings.jsonpCallback;
+
+				// save the callback name for future use
+				oldCallbacks.push( callbackName );
+			}
+
+			// Call if it was a function and we have a response
+			if ( responseContainer && jQuery.isFunction( overwritten ) ) {
+				overwritten( responseContainer[ 0 ] );
+			}
+
+			responseContainer = overwritten = undefined;
+		});
+
+		// Delegate to script
+		return "script";
+	}
+});
+
+
+
+
+// data: string of html
+// context (optional): If specified, the fragment will be created in this context, defaults to document
+// keepScripts (optional): If true, will include scripts passed in the html string
+jQuery.parseHTML = function( data, context, keepScripts ) {
+	if ( !data || typeof data !== "string" ) {
+		return null;
+	}
+	if ( typeof context === "boolean" ) {
+		keepScripts = context;
+		context = false;
+	}
+	context = context || document;
+
+	var parsed = rsingleTag.exec( data ),
+		scripts = !keepScripts && [];
+
+	// Single tag
+	if ( parsed ) {
+		return [ context.createElement( parsed[1] ) ];
+	}
+
+	parsed = jQuery.buildFragment( [ data ], context, scripts );
+
+	if ( scripts && scripts.length ) {
+		jQuery( scripts ).remove();
+	}
+
+	return jQuery.merge( [], parsed.childNodes );
+};
+
+
+// Keep a copy of the old load method
+var _load = jQuery.fn.load;
+
+/**
+ * Load a url into a page
+ */
+jQuery.fn.load = function( url, params, callback ) {
+	if ( typeof url !== "string" && _load ) {
+		return _load.apply( this, arguments );
+	}
+
+	var selector, type, response,
+		self = this,
+		off = url.indexOf(" ");
+
+	if ( off >= 0 ) {
+		selector = url.slice( off );
+		url = url.slice( 0, off );
+	}
+
+	// If it's a function
+	if ( jQuery.isFunction( params ) ) {
+
+		// We assume that it's the callback
+		callback = params;
+		params = undefined;
+
+	// Otherwise, build a param string
+	} else if ( params && typeof params === "object" ) {
+		type = "POST";
+	}
+
+	// If we have elements to modify, make the request
+	if ( self.length > 0 ) {
+		jQuery.ajax({
+			url: url,
+
+			// if "type" variable is undefined, then "GET" method will be used
+			type: type,
+			dataType: "html",
+			data: params
+		}).done(function( responseText ) {
+
+			// Save response for use in complete callback
+			response = arguments;
+
+			self.html( selector ?
+
+				// If a selector was specified, locate the right elements in a dummy div
+				// Exclude scripts to avoid IE 'Permission Denied' errors
+				jQuery("<div>").append( jQuery.parseHTML( responseText ) ).find( selector ) :
+
+				// Otherwise use the full result
+				responseText );
+
+		}).complete( callback && function( jqXHR, status ) {
+			self.each( callback, response || [ jqXHR.responseText, status, jqXHR ] );
+		});
+	}
+
+	return this;
+};
+
+
+
+
+jQuery.expr.filters.animated = function( elem ) {
+	return jQuery.grep(jQuery.timers, function( fn ) {
+		return elem === fn.elem;
+	}).length;
+};
+
+
+
+
+var docElem = window.document.documentElement;
+
+/**
+ * Gets a window from an element
+ */
+function getWindow( elem ) {
+	return jQuery.isWindow( elem ) ? elem : elem.nodeType === 9 && elem.defaultView;
+}
+
+jQuery.offset = {
+	setOffset: function( elem, options, i ) {
+		var curPosition, curLeft, curCSSTop, curTop, curOffset, curCSSLeft, calculatePosition,
+			position = jQuery.css( elem, "position" ),
+			curElem = jQuery( elem ),
+			props = {};
+
+		// Set position first, in-case top/left are set even on static elem
+		if ( position === "static" ) {
+			elem.style.position = "relative";
+		}
+
+		curOffset = curElem.offset();
+		curCSSTop = jQuery.css( elem, "top" );
+		curCSSLeft = jQuery.css( elem, "left" );
+		calculatePosition = ( position === "absolute" || position === "fixed" ) &&
+			( curCSSTop + curCSSLeft ).indexOf("auto") > -1;
+
+		// Need to be able to calculate position if either top or left is auto and position is either absolute or fixed
+		if ( calculatePosition ) {
+			curPosition = curElem.position();
+			curTop = curPosition.top;
+			curLeft = curPosition.left;
+
+		} else {
+			curTop = parseFloat( curCSSTop ) || 0;
+			curLeft = parseFloat( curCSSLeft ) || 0;
+		}
+
+		if ( jQuery.isFunction( options ) ) {
+			options = options.call( elem, i, curOffset );
+		}
+
+		if ( options.top != null ) {
+			props.top = ( options.top - curOffset.top ) + curTop;
+		}
+		if ( options.left != null ) {
+			props.left = ( options.left - curOffset.left ) + curLeft;
+		}
+
+		if ( "using" in options ) {
+			options.using.call( elem, props );
+
+		} else {
+			curElem.css( props );
+		}
+	}
+};
+
+jQuery.fn.extend({
+	offset: function( options ) {
+		if ( arguments.length ) {
+			return options === undefined ?
+				this :
+				this.each(function( i ) {
+					jQuery.offset.setOffset( this, options, i );
+				});
+		}
+
+		var docElem, win,
+			elem = this[ 0 ],
+			box = { top: 0, left: 0 },
+			doc = elem && elem.ownerDocument;
+
+		if ( !doc ) {
+			return;
+		}
+
+		docElem = doc.documentElement;
+
+		// Make sure it's not a disconnected DOM node
+		if ( !jQuery.contains( docElem, elem ) ) {
+			return box;
+		}
+
+		// If we don't have gBCR, just use 0,0 rather than error
+		// BlackBerry 5, iOS 3 (original iPhone)
+		if ( typeof elem.getBoundingClientRect !== strundefined ) {
+			box = elem.getBoundingClientRect();
+		}
+		win = getWindow( doc );
+		return {
+			top: box.top + win.pageYOffset - docElem.clientTop,
+			left: box.left + win.pageXOffset - docElem.clientLeft
+		};
+	},
+
+	position: function() {
+		if ( !this[ 0 ] ) {
+			return;
+		}
+
+		var offsetParent, offset,
+			elem = this[ 0 ],
+			parentOffset = { top: 0, left: 0 };
+
+		// Fixed elements are offset from window (parentOffset = {top:0, left: 0}, because it is its only offset parent
+		if ( jQuery.css( elem, "position" ) === "fixed" ) {
+			// We assume that getBoundingClientRect is available when computed position is fixed
+			offset = elem.getBoundingClientRect();
+
+		} else {
+			// Get *real* offsetParent
+			offsetParent = this.offsetParent();
+
+			// Get correct offsets
+			offset = this.offset();
+			if ( !jQuery.nodeName( offsetParent[ 0 ], "html" ) ) {
+				parentOffset = offsetParent.offset();
+			}
+
+			// Add offsetParent borders
+			parentOffset.top += jQuery.css( offsetParent[ 0 ], "borderTopWidth", true );
+			parentOffset.left += jQuery.css( offsetParent[ 0 ], "borderLeftWidth", true );
+		}
+
+		// Subtract parent offsets and element margins
+		return {
+			top: offset.top - parentOffset.top - jQuery.css( elem, "marginTop", true ),
+			left: offset.left - parentOffset.left - jQuery.css( elem, "marginLeft", true )
+		};
+	},
+
+	offsetParent: function() {
+		return this.map(function() {
+			var offsetParent = this.offsetParent || docElem;
+
+			while ( offsetParent && ( !jQuery.nodeName( offsetParent, "html" ) && jQuery.css( offsetParent, "position" ) === "static" ) ) {
+				offsetParent = offsetParent.offsetParent;
+			}
+
+			return offsetParent || docElem;
+		});
+	}
+});
+
+// Create scrollLeft and scrollTop methods
+jQuery.each( { scrollLeft: "pageXOffset", scrollTop: "pageYOffset" }, function( method, prop ) {
+	var top = "pageYOffset" === prop;
+
+	jQuery.fn[ method ] = function( val ) {
+		return access( this, function( elem, method, val ) {
+			var win = getWindow( elem );
+
+			if ( val === undefined ) {
+				return win ? win[ prop ] : elem[ method ];
+			}
+
+			if ( win ) {
+				win.scrollTo(
+					!top ? val : window.pageXOffset,
+					top ? val : window.pageYOffset
+				);
+
+			} else {
+				elem[ method ] = val;
+			}
+		}, method, val, arguments.length, null );
+	};
+});
+
+// Add the top/left cssHooks using jQuery.fn.position
+// Webkit bug: https://bugs.webkit.org/show_bug.cgi?id=29084
+// getComputedStyle returns percent when specified for top/left/bottom/right
+// rather than make the css module depend on the offset module, we just check for it here
+jQuery.each( [ "top", "left" ], function( i, prop ) {
+	jQuery.cssHooks[ prop ] = addGetHookIf( support.pixelPosition,
+		function( elem, computed ) {
+			if ( computed ) {
+				computed = curCSS( elem, prop );
+				// if curCSS returns percentage, fallback to offset
+				return rnumnonpx.test( computed ) ?
+					jQuery( elem ).position()[ prop ] + "px" :
+					computed;
+			}
+		}
+	);
+});
+
+
+// Create innerHeight, innerWidth, height, width, outerHeight and outerWidth methods
+jQuery.each( { Height: "height", Width: "width" }, function( name, type ) {
+	jQuery.each( { padding: "inner" + name, content: type, "": "outer" + name }, function( defaultExtra, funcName ) {
+		// margin is only for outerHeight, outerWidth
+		jQuery.fn[ funcName ] = function( margin, value ) {
+			var chainable = arguments.length && ( defaultExtra || typeof margin !== "boolean" ),
+				extra = defaultExtra || ( margin === true || value === true ? "margin" : "border" );
+
+			return access( this, function( elem, type, value ) {
+				var doc;
+
+				if ( jQuery.isWindow( elem ) ) {
+					// As of 5/8/2012 this will yield incorrect results for Mobile Safari, but there
+					// isn't a whole lot we can do. See pull request at this URL for discussion:
+					// https://github.com/jquery/jquery/pull/764
+					return elem.document.documentElement[ "client" + name ];
+				}
+
+				// Get document width or height
+				if ( elem.nodeType === 9 ) {
+					doc = elem.documentElement;
+
+					// Either scroll[Width/Height] or offset[Width/Height] or client[Width/Height],
+					// whichever is greatest
+					return Math.max(
+						elem.body[ "scroll" + name ], doc[ "scroll" + name ],
+						elem.body[ "offset" + name ], doc[ "offset" + name ],
+						doc[ "client" + name ]
+					);
+				}
+
+				return value === undefined ?
+					// Get width or height on the element, requesting but not forcing parseFloat
+					jQuery.css( elem, type, extra ) :
+
+					// Set width or height on the element
+					jQuery.style( elem, type, value, extra );
+			}, type, chainable ? margin : undefined, chainable, null );
+		};
+	});
+});
+
+
+// The number of elements contained in the matched element set
+jQuery.fn.size = function() {
+	return this.length;
+};
+
+jQuery.fn.andSelf = jQuery.fn.addBack;
+
+
+
+
+// Register as a named AMD module, since jQuery can be concatenated with other
+// files that may use define, but not via a proper concatenation script that
+// understands anonymous AMD modules. A named AMD is safest and most robust
+// way to register. Lowercase jquery is used because AMD module names are
+// derived from file names, and jQuery is normally delivered in a lowercase
+// file name. Do this after creating the global so that if an AMD module wants
+// to call noConflict to hide this version of jQuery, it will work.
+if ( typeof define === "function" && define.amd ) {
+	define( "jquery", [], function() {
+		return jQuery;
+	});
+}
+
+
+
+
+var
+	// Map over jQuery in case of overwrite
+	_jQuery = window.jQuery,
+
+	// Map over the $ in case of overwrite
+	_$ = window.$;
+
+jQuery.noConflict = function( deep ) {
+	if ( window.$ === jQuery ) {
+		window.$ = _$;
+	}
+
+	if ( deep && window.jQuery === jQuery ) {
+		window.jQuery = _jQuery;
+	}
+
+	return jQuery;
+};
+
+// Expose jQuery and $ identifiers, even in
+// AMD (#7102#comment:10, https://github.com/jquery/jquery/pull/557)
+// and CommonJS for browser emulators (#13566)
+if ( typeof noGlobal === strundefined ) {
+	window.jQuery = window.$ = jQuery;
+}
+
+
+
+
+return jQuery;
+
+}));
diff --git a/static/js/jquery.ui.core.js b/static/js/jquery.ui.core.js
new file mode 100644
index 0000000000..6df91628de
--- /dev/null
+++ b/static/js/jquery.ui.core.js
@@ -0,0 +1,320 @@
+/*!
+ * jQuery UI Core 1.10.4
+ * http://jqueryui.com
+ *
+ * Copyright 2014 jQuery Foundation and other contributors
+ * Released under the MIT license.
+ * http://jquery.org/license
+ *
+ * http://api.jqueryui.com/category/ui-core/
+ */
+(function( $, undefined ) {
+
+var uuid = 0,
+	runiqueId = /^ui-id-\d+$/;
+
+// $.ui might exist from components with no dependencies, e.g., $.ui.position
+$.ui = $.ui || {};
+
+$.extend( $.ui, {
+	version: "1.10.4",
+
+	keyCode: {
+		BACKSPACE: 8,
+		COMMA: 188,
+		DELETE: 46,
+		DOWN: 40,
+		END: 35,
+		ENTER: 13,
+		ESCAPE: 27,
+		HOME: 36,
+		LEFT: 37,
+		NUMPAD_ADD: 107,
+		NUMPAD_DECIMAL: 110,
+		NUMPAD_DIVIDE: 111,
+		NUMPAD_ENTER: 108,
+		NUMPAD_MULTIPLY: 106,
+		NUMPAD_SUBTRACT: 109,
+		PAGE_DOWN: 34,
+		PAGE_UP: 33,
+		PERIOD: 190,
+		RIGHT: 39,
+		SPACE: 32,
+		TAB: 9,
+		UP: 38
+	}
+});
+
+// plugins
+$.fn.extend({
+	focus: (function( orig ) {
+		return function( delay, fn ) {
+			return typeof delay === "number" ?
+				this.each(function() {
+					var elem = this;
+					setTimeout(function() {
+						$( elem ).focus();
+						if ( fn ) {
+							fn.call( elem );
+						}
+					}, delay );
+				}) :
+				orig.apply( this, arguments );
+		};
+	})( $.fn.focus ),
+
+	scrollParent: function() {
+		var scrollParent;
+		if (($.ui.ie && (/(static|relative)/).test(this.css("position"))) || (/absolute/).test(this.css("position"))) {
+			scrollParent = this.parents().filter(function() {
+				return (/(relative|absolute|fixed)/).test($.css(this,"position")) && (/(auto|scroll)/).test($.css(this,"overflow")+$.css(this,"overflow-y")+$.css(this,"overflow-x"));
+			}).eq(0);
+		} else {
+			scrollParent = this.parents().filter(function() {
+				return (/(auto|scroll)/).test($.css(this,"overflow")+$.css(this,"overflow-y")+$.css(this,"overflow-x"));
+			}).eq(0);
+		}
+
+		return (/fixed/).test(this.css("position")) || !scrollParent.length ? $(document) : scrollParent;
+	},
+
+	zIndex: function( zIndex ) {
+		if ( zIndex !== undefined ) {
+			return this.css( "zIndex", zIndex );
+		}
+
+		if ( this.length ) {
+			var elem = $( this[ 0 ] ), position, value;
+			while ( elem.length && elem[ 0 ] !== document ) {
+				// Ignore z-index if position is set to a value where z-index is ignored by the browser
+				// This makes behavior of this function consistent across browsers
+				// WebKit always returns auto if the element is positioned
+				position = elem.css( "position" );
+				if ( position === "absolute" || position === "relative" || position === "fixed" ) {
+					// IE returns 0 when zIndex is not specified
+					// other browsers return a string
+					// we ignore the case of nested elements with an explicit value of 0
+					// <div style="z-index: -10;"><div style="z-index: 0;"></div></div>
+					value = parseInt( elem.css( "zIndex" ), 10 );
+					if ( !isNaN( value ) && value !== 0 ) {
+						return value;
+					}
+				}
+				elem = elem.parent();
+			}
+		}
+
+		return 0;
+	},
+
+	uniqueId: function() {
+		return this.each(function() {
+			if ( !this.id ) {
+				this.id = "ui-id-" + (++uuid);
+			}
+		});
+	},
+
+	removeUniqueId: function() {
+		return this.each(function() {
+			if ( runiqueId.test( this.id ) ) {
+				$( this ).removeAttr( "id" );
+			}
+		});
+	}
+});
+
+// selectors
+function focusable( element, isTabIndexNotNaN ) {
+	var map, mapName, img,
+		nodeName = element.nodeName.toLowerCase();
+	if ( "area" === nodeName ) {
+		map = element.parentNode;
+		mapName = map.name;
+		if ( !element.href || !mapName || map.nodeName.toLowerCase() !== "map" ) {
+			return false;
+		}
+		img = $( "img[usemap=#" + mapName + "]" )[0];
+		return !!img && visible( img );
+	}
+	return ( /input|select|textarea|button|object/.test( nodeName ) ?
+		!element.disabled :
+		"a" === nodeName ?
+			element.href || isTabIndexNotNaN :
+			isTabIndexNotNaN) &&
+		// the element and all of its ancestors must be visible
+		visible( element );
+}
+
+function visible( element ) {
+	return $.expr.filters.visible( element ) &&
+		!$( element ).parents().addBack().filter(function() {
+			return $.css( this, "visibility" ) === "hidden";
+		}).length;
+}
+
+$.extend( $.expr[ ":" ], {
+	data: $.expr.createPseudo ?
+		$.expr.createPseudo(function( dataName ) {
+			return function( elem ) {
+				return !!$.data( elem, dataName );
+			};
+		}) :
+		// support: jQuery <1.8
+		function( elem, i, match ) {
+			return !!$.data( elem, match[ 3 ] );
+		},
+
+	focusable: function( element ) {
+		return focusable( element, !isNaN( $.attr( element, "tabindex" ) ) );
+	},
+
+	tabbable: function( element ) {
+		var tabIndex = $.attr( element, "tabindex" ),
+			isTabIndexNaN = isNaN( tabIndex );
+		return ( isTabIndexNaN || tabIndex >= 0 ) && focusable( element, !isTabIndexNaN );
+	}
+});
+
+// support: jQuery <1.8
+if ( !$( "<a>" ).outerWidth( 1 ).jquery ) {
+	$.each( [ "Width", "Height" ], function( i, name ) {
+		var side = name === "Width" ? [ "Left", "Right" ] : [ "Top", "Bottom" ],
+			type = name.toLowerCase(),
+			orig = {
+				innerWidth: $.fn.innerWidth,
+				innerHeight: $.fn.innerHeight,
+				outerWidth: $.fn.outerWidth,
+				outerHeight: $.fn.outerHeight
+			};
+
+		function reduce( elem, size, border, margin ) {
+			$.each( side, function() {
+				size -= parseFloat( $.css( elem, "padding" + this ) ) || 0;
+				if ( border ) {
+					size -= parseFloat( $.css( elem, "border" + this + "Width" ) ) || 0;
+				}
+				if ( margin ) {
+					size -= parseFloat( $.css( elem, "margin" + this ) ) || 0;
+				}
+			});
+			return size;
+		}
+
+		$.fn[ "inner" + name ] = function( size ) {
+			if ( size === undefined ) {
+				return orig[ "inner" + name ].call( this );
+			}
+
+			return this.each(function() {
+				$( this ).css( type, reduce( this, size ) + "px" );
+			});
+		};
+
+		$.fn[ "outer" + name] = function( size, margin ) {
+			if ( typeof size !== "number" ) {
+				return orig[ "outer" + name ].call( this, size );
+			}
+
+			return this.each(function() {
+				$( this).css( type, reduce( this, size, true, margin ) + "px" );
+			});
+		};
+	});
+}
+
+// support: jQuery <1.8
+if ( !$.fn.addBack ) {
+	$.fn.addBack = function( selector ) {
+		return this.add( selector == null ?
+			this.prevObject : this.prevObject.filter( selector )
+		);
+	};
+}
+
+// support: jQuery 1.6.1, 1.6.2 (http://bugs.jquery.com/ticket/9413)
+if ( $( "<a>" ).data( "a-b", "a" ).removeData( "a-b" ).data( "a-b" ) ) {
+	$.fn.removeData = (function( removeData ) {
+		return function( key ) {
+			if ( arguments.length ) {
+				return removeData.call( this, $.camelCase( key ) );
+			} else {
+				return removeData.call( this );
+			}
+		};
+	})( $.fn.removeData );
+}
+
+
+
+
+
+// deprecated
+$.ui.ie = !!/msie [\w.]+/.exec( navigator.userAgent.toLowerCase() );
+
+$.support.selectstart = "onselectstart" in document.createElement( "div" );
+$.fn.extend({
+	disableSelection: function() {
+		return this.bind( ( $.support.selectstart ? "selectstart" : "mousedown" ) +
+			".ui-disableSelection", function( event ) {
+				event.preventDefault();
+			});
+	},
+
+	enableSelection: function() {
+		return this.unbind( ".ui-disableSelection" );
+	}
+});
+
+$.extend( $.ui, {
+	// $.ui.plugin is deprecated. Use $.widget() extensions instead.
+	plugin: {
+		add: function( module, option, set ) {
+			var i,
+				proto = $.ui[ module ].prototype;
+			for ( i in set ) {
+				proto.plugins[ i ] = proto.plugins[ i ] || [];
+				proto.plugins[ i ].push( [ option, set[ i ] ] );
+			}
+		},
+		call: function( instance, name, args ) {
+			var i,
+				set = instance.plugins[ name ];
+			if ( !set || !instance.element[ 0 ].parentNode || instance.element[ 0 ].parentNode.nodeType === 11 ) {
+				return;
+			}
+
+			for ( i = 0; i < set.length; i++ ) {
+				if ( instance.options[ set[ i ][ 0 ] ] ) {
+					set[ i ][ 1 ].apply( instance.element, args );
+				}
+			}
+		}
+	},
+
+	// only used by resizable
+	hasScroll: function( el, a ) {
+
+		//If overflow is hidden, the element might have extra content, but the user wants to hide it
+		if ( $( el ).css( "overflow" ) === "hidden") {
+			return false;
+		}
+
+		var scroll = ( a && a === "left" ) ? "scrollLeft" : "scrollTop",
+			has = false;
+
+		if ( el[ scroll ] > 0 ) {
+			return true;
+		}
+
+		// TODO: determine which cases actually cause this to happen
+		// if the element doesn't have the scroll set, see if it's possible to
+		// set the scroll
+		el[ scroll ] = 1;
+		has = ( el[ scroll ] > 0 );
+		el[ scroll ] = 0;
+		return has;
+	}
+});
+
+})( jQuery );
diff --git a/static/js/jquery.ui.mouse.js b/static/js/jquery.ui.mouse.js
new file mode 100644
index 0000000000..7b0f25755f
--- /dev/null
+++ b/static/js/jquery.ui.mouse.js
@@ -0,0 +1,169 @@
+/*!
+ * jQuery UI Mouse 1.10.4
+ * http://jqueryui.com
+ *
+ * Copyright 2014 jQuery Foundation and other contributors
+ * Released under the MIT license.
+ * http://jquery.org/license
+ *
+ * http://api.jqueryui.com/mouse/
+ *
+ * Depends:
+ *	jquery.ui.widget.js
+ */
+(function( $, undefined ) {
+
+var mouseHandled = false;
+$( document ).mouseup( function() {
+	mouseHandled = false;
+});
+
+$.widget("ui.mouse", {
+	version: "1.10.4",
+	options: {
+		cancel: "input,textarea,button,select,option",
+		distance: 1,
+		delay: 0
+	},
+	_mouseInit: function() {
+		var that = this;
+
+		this.element
+			.bind("mousedown."+this.widgetName, function(event) {
+				return that._mouseDown(event);
+			})
+			.bind("click."+this.widgetName, function(event) {
+				if (true === $.data(event.target, that.widgetName + ".preventClickEvent")) {
+					$.removeData(event.target, that.widgetName + ".preventClickEvent");
+					event.stopImmediatePropagation();
+					return false;
+				}
+			});
+
+		this.started = false;
+	},
+
+	// TODO: make sure destroying one instance of mouse doesn't mess with
+	// other instances of mouse
+	_mouseDestroy: function() {
+		this.element.unbind("."+this.widgetName);
+		if ( this._mouseMoveDelegate ) {
+			$(document)
+				.unbind("mousemove."+this.widgetName, this._mouseMoveDelegate)
+				.unbind("mouseup."+this.widgetName, this._mouseUpDelegate);
+		}
+	},
+
+	_mouseDown: function(event) {
+		// don't let more than one widget handle mouseStart
+		if( mouseHandled ) { return; }
+
+		// we may have missed mouseup (out of window)
+		(this._mouseStarted && this._mouseUp(event));
+
+		this._mouseDownEvent = event;
+
+		var that = this,
+			btnIsLeft = (event.which === 1),
+			// event.target.nodeName works around a bug in IE 8 with
+			// disabled inputs (#7620)
+			elIsCancel = (typeof this.options.cancel === "string" && event.target.nodeName ? $(event.target).closest(this.options.cancel).length : false);
+		if (!btnIsLeft || elIsCancel || !this._mouseCapture(event)) {
+			return true;
+		}
+
+		this.mouseDelayMet = !this.options.delay;
+		if (!this.mouseDelayMet) {
+			this._mouseDelayTimer = setTimeout(function() {
+				that.mouseDelayMet = true;
+			}, this.options.delay);
+		}
+
+		if (this._mouseDistanceMet(event) && this._mouseDelayMet(event)) {
+			this._mouseStarted = (this._mouseStart(event) !== false);
+			if (!this._mouseStarted) {
+				event.preventDefault();
+				return true;
+			}
+		}
+
+		// Click event may never have fired (Gecko & Opera)
+		if (true === $.data(event.target, this.widgetName + ".preventClickEvent")) {
+			$.removeData(event.target, this.widgetName + ".preventClickEvent");
+		}
+
+		// these delegates are required to keep context
+		this._mouseMoveDelegate = function(event) {
+			return that._mouseMove(event);
+		};
+		this._mouseUpDelegate = function(event) {
+			return that._mouseUp(event);
+		};
+		$(document)
+			.bind("mousemove."+this.widgetName, this._mouseMoveDelegate)
+			.bind("mouseup."+this.widgetName, this._mouseUpDelegate);
+
+		event.preventDefault();
+
+		mouseHandled = true;
+		return true;
+	},
+
+	_mouseMove: function(event) {
+		// IE mouseup check - mouseup happened when mouse was out of window
+		if ($.ui.ie && ( !document.documentMode || document.documentMode < 9 ) && !event.button) {
+			return this._mouseUp(event);
+		}
+
+		if (this._mouseStarted) {
+			this._mouseDrag(event);
+			return event.preventDefault();
+		}
+
+		if (this._mouseDistanceMet(event) && this._mouseDelayMet(event)) {
+			this._mouseStarted =
+				(this._mouseStart(this._mouseDownEvent, event) !== false);
+			(this._mouseStarted ? this._mouseDrag(event) : this._mouseUp(event));
+		}
+
+		return !this._mouseStarted;
+	},
+
+	_mouseUp: function(event) {
+		$(document)
+			.unbind("mousemove."+this.widgetName, this._mouseMoveDelegate)
+			.unbind("mouseup."+this.widgetName, this._mouseUpDelegate);
+
+		if (this._mouseStarted) {
+			this._mouseStarted = false;
+
+			if (event.target === this._mouseDownEvent.target) {
+				$.data(event.target, this.widgetName + ".preventClickEvent", true);
+			}
+
+			this._mouseStop(event);
+		}
+
+		return false;
+	},
+
+	_mouseDistanceMet: function(event) {
+		return (Math.max(
+				Math.abs(this._mouseDownEvent.pageX - event.pageX),
+				Math.abs(this._mouseDownEvent.pageY - event.pageY)
+			) >= this.options.distance
+		);
+	},
+
+	_mouseDelayMet: function(/* event */) {
+		return this.mouseDelayMet;
+	},
+
+	// These are placeholder methods, to be overriden by extending plugin
+	_mouseStart: function(/* event */) {},
+	_mouseDrag: function(/* event */) {},
+	_mouseStop: function(/* event */) {},
+	_mouseCapture: function(/* event */) { return true; }
+});
+
+})(jQuery);
diff --git a/static/js/jquery.ui.sortable.js b/static/js/jquery.ui.sortable.js
new file mode 100644
index 0000000000..45393e4215
--- /dev/null
+++ b/static/js/jquery.ui.sortable.js
@@ -0,0 +1,1289 @@
+/*!
+ * jQuery UI Sortable 1.10.4
+ * http://jqueryui.com
+ *
+ * Copyright 2014 jQuery Foundation and other contributors
+ * Released under the MIT license.
+ * http://jquery.org/license
+ *
+ * http://api.jqueryui.com/sortable/
+ *
+ * Depends:
+ *	jquery.ui.core.js
+ *	jquery.ui.mouse.js
+ *	jquery.ui.widget.js
+ */
+(function( $, undefined ) {
+
+function isOverAxis( x, reference, size ) {
+	return ( x > reference ) && ( x < ( reference + size ) );
+}
+
+function isFloating(item) {
+	return (/left|right/).test(item.css("float")) || (/inline|table-cell/).test(item.css("display"));
+}
+
+$.widget("ui.sortable", $.ui.mouse, {
+	version: "1.10.4",
+	widgetEventPrefix: "sort",
+	ready: false,
+	options: {
+		appendTo: "parent",
+		axis: false,
+		connectWith: false,
+		containment: false,
+		cursor: "auto",
+		cursorAt: false,
+		dropOnEmpty: true,
+		forcePlaceholderSize: false,
+		forceHelperSize: false,
+		grid: false,
+		handle: false,
+		helper: "original",
+		items: "> *",
+		opacity: false,
+		placeholder: false,
+		revert: false,
+		scroll: true,
+		scrollSensitivity: 20,
+		scrollSpeed: 20,
+		scope: "default",
+		tolerance: "intersect",
+		zIndex: 1000,
+
+		// callbacks
+		activate: null,
+		beforeStop: null,
+		change: null,
+		deactivate: null,
+		out: null,
+		over: null,
+		receive: null,
+		remove: null,
+		sort: null,
+		start: null,
+		stop: null,
+		update: null
+	},
+	_create: function() {
+
+		var o = this.options;
+		this.containerCache = {};
+		this.element.addClass("ui-sortable");
+
+		//Get the items
+		this.refresh();
+
+		//Let's determine if the items are being displayed horizontally
+		this.floating = this.items.length ? o.axis === "x" || isFloating(this.items[0].item) : false;
+
+		//Let's determine the parent's offset
+		this.offset = this.element.offset();
+
+		//Initialize mouse events for interaction
+		this._mouseInit();
+
+		//We're ready to go
+		this.ready = true;
+
+	},
+
+	_destroy: function() {
+		this.element
+			.removeClass("ui-sortable ui-sortable-disabled");
+		this._mouseDestroy();
+
+		for ( var i = this.items.length - 1; i >= 0; i-- ) {
+			this.items[i].item.removeData(this.widgetName + "-item");
+		}
+
+		return this;
+	},
+
+	_setOption: function(key, value){
+		if ( key === "disabled" ) {
+			this.options[ key ] = value;
+
+			this.widget().toggleClass( "ui-sortable-disabled", !!value );
+		} else {
+			// Don't call widget base _setOption for disable as it adds ui-state-disabled class
+			$.Widget.prototype._setOption.apply(this, arguments);
+		}
+	},
+
+	_mouseCapture: function(event, overrideHandle) {
+		var currentItem = null,
+			validHandle = false,
+			that = this;
+
+		if (this.reverting) {
+			return false;
+		}
+
+		if(this.options.disabled || this.options.type === "static") {
+			return false;
+		}
+
+		//We have to refresh the items data once first
+		this._refreshItems(event);
+
+		//Find out if the clicked node (or one of its parents) is a actual item in this.items
+		$(event.target).parents().each(function() {
+			if($.data(this, that.widgetName + "-item") === that) {
+				currentItem = $(this);
+				return false;
+			}
+		});
+		if($.data(event.target, that.widgetName + "-item") === that) {
+			currentItem = $(event.target);
+		}
+
+		if(!currentItem) {
+			return false;
+		}
+		if(this.options.handle && !overrideHandle) {
+			$(this.options.handle, currentItem).find("*").addBack().each(function() {
+				if(this === event.target) {
+					validHandle = true;
+				}
+			});
+			if(!validHandle) {
+				return false;
+			}
+		}
+
+		this.currentItem = currentItem;
+		this._removeCurrentsFromItems();
+		return true;
+
+	},
+
+	_mouseStart: function(event, overrideHandle, noActivation) {
+
+		var i, body,
+			o = this.options;
+
+		this.currentContainer = this;
+
+		//We only need to call refreshPositions, because the refreshItems call has been moved to mouseCapture
+		this.refreshPositions();
+
+		//Create and append the visible helper
+		this.helper = this._createHelper(event);
+
+		//Cache the helper size
+		this._cacheHelperProportions();
+
+		/*
+		 * - Position generation -
+		 * This block generates everything position related - it's the core of draggables.
+		 */
+
+		//Cache the margins of the original element
+		this._cacheMargins();
+
+		//Get the next scrolling parent
+		this.scrollParent = this.helper.scrollParent();
+
+		//The element's absolute position on the page minus margins
+		this.offset = this.currentItem.offset();
+		this.offset = {
+			top: this.offset.top - this.margins.top,
+			left: this.offset.left - this.margins.left
+		};
+
+		$.extend(this.offset, {
+			click: { //Where the click happened, relative to the element
+				left: event.pageX - this.offset.left,
+				top: event.pageY - this.offset.top
+			},
+			parent: this._getParentOffset(),
+			relative: this._getRelativeOffset() //This is a relative to absolute position minus the actual position calculation - only used for relative positioned helper
+		});
+
+		// Only after we got the offset, we can change the helper's position to absolute
+		// TODO: Still need to figure out a way to make relative sorting possible
+		this.helper.css("position", "absolute");
+		this.cssPosition = this.helper.css("position");
+
+		//Generate the original position
+		this.originalPosition = this._generatePosition(event);
+		this.originalPageX = event.pageX;
+		this.originalPageY = event.pageY;
+
+		//Adjust the mouse offset relative to the helper if "cursorAt" is supplied
+		(o.cursorAt && this._adjustOffsetFromHelper(o.cursorAt));
+
+		//Cache the former DOM position
+		this.domPosition = { prev: this.currentItem.prev()[0], parent: this.currentItem.parent()[0] };
+
+		//If the helper is not the original, hide the original so it's not playing any role during the drag, won't cause anything bad this way
+		if(this.helper[0] !== this.currentItem[0]) {
+			this.currentItem.hide();
+		}
+
+		//Create the placeholder
+		this._createPlaceholder();
+
+		//Set a containment if given in the options
+		if(o.containment) {
+			this._setContainment();
+		}
+
+		if( o.cursor && o.cursor !== "auto" ) { // cursor option
+			body = this.document.find( "body" );
+
+			// support: IE
+			this.storedCursor = body.css( "cursor" );
+			body.css( "cursor", o.cursor );
+
+			this.storedStylesheet = $( "<style>*{ cursor: "+o.cursor+" !important; }</style>" ).appendTo( body );
+		}
+
+		if(o.opacity) { // opacity option
+			if (this.helper.css("opacity")) {
+				this._storedOpacity = this.helper.css("opacity");
+			}
+			this.helper.css("opacity", o.opacity);
+		}
+
+		if(o.zIndex) { // zIndex option
+			if (this.helper.css("zIndex")) {
+				this._storedZIndex = this.helper.css("zIndex");
+			}
+			this.helper.css("zIndex", o.zIndex);
+		}
+
+		//Prepare scrolling
+		if(this.scrollParent[0] !== document && this.scrollParent[0].tagName !== "HTML") {
+			this.overflowOffset = this.scrollParent.offset();
+		}
+
+		//Call callbacks
+		this._trigger("start", event, this._uiHash());
+
+		//Recache the helper size
+		if(!this._preserveHelperProportions) {
+			this._cacheHelperProportions();
+		}
+
+
+		//Post "activate" events to possible containers
+		if( !noActivation ) {
+			for ( i = this.containers.length - 1; i >= 0; i-- ) {
+				this.containers[ i ]._trigger( "activate", event, this._uiHash( this ) );
+			}
+		}
+
+		//Prepare possible droppables
+		if($.ui.ddmanager) {
+			$.ui.ddmanager.current = this;
+		}
+
+		if ($.ui.ddmanager && !o.dropBehaviour) {
+			$.ui.ddmanager.prepareOffsets(this, event);
+		}
+
+		this.dragging = true;
+
+		this.helper.addClass("ui-sortable-helper");
+		this._mouseDrag(event); //Execute the drag once - this causes the helper not to be visible before getting its correct position
+		return true;
+
+	},
+
+	_mouseDrag: function(event) {
+		var i, item, itemElement, intersection,
+			o = this.options,
+			scrolled = false;
+
+		//Compute the helpers position
+		this.position = this._generatePosition(event);
+		this.positionAbs = this._convertPositionTo("absolute");
+
+		if (!this.lastPositionAbs) {
+			this.lastPositionAbs = this.positionAbs;
+		}
+
+		//Do scrolling
+		if(this.options.scroll) {
+			if(this.scrollParent[0] !== document && this.scrollParent[0].tagName !== "HTML") {
+
+				if((this.overflowOffset.top + this.scrollParent[0].offsetHeight) - event.pageY < o.scrollSensitivity) {
+					this.scrollParent[0].scrollTop = scrolled = this.scrollParent[0].scrollTop + o.scrollSpeed;
+				} else if(event.pageY - this.overflowOffset.top < o.scrollSensitivity) {
+					this.scrollParent[0].scrollTop = scrolled = this.scrollParent[0].scrollTop - o.scrollSpeed;
+				}
+
+				if((this.overflowOffset.left + this.scrollParent[0].offsetWidth) - event.pageX < o.scrollSensitivity) {
+					this.scrollParent[0].scrollLeft = scrolled = this.scrollParent[0].scrollLeft + o.scrollSpeed;
+				} else if(event.pageX - this.overflowOffset.left < o.scrollSensitivity) {
+					this.scrollParent[0].scrollLeft = scrolled = this.scrollParent[0].scrollLeft - o.scrollSpeed;
+				}
+
+			} else {
+
+				if(event.pageY - $(document).scrollTop() < o.scrollSensitivity) {
+					scrolled = $(document).scrollTop($(document).scrollTop() - o.scrollSpeed);
+				} else if($(window).height() - (event.pageY - $(document).scrollTop()) < o.scrollSensitivity) {
+					scrolled = $(document).scrollTop($(document).scrollTop() + o.scrollSpeed);
+				}
+
+				if(event.pageX - $(document).scrollLeft() < o.scrollSensitivity) {
+					scrolled = $(document).scrollLeft($(document).scrollLeft() - o.scrollSpeed);
+				} else if($(window).width() - (event.pageX - $(document).scrollLeft()) < o.scrollSensitivity) {
+					scrolled = $(document).scrollLeft($(document).scrollLeft() + o.scrollSpeed);
+				}
+
+			}
+
+			if(scrolled !== false && $.ui.ddmanager && !o.dropBehaviour) {
+				$.ui.ddmanager.prepareOffsets(this, event);
+			}
+		}
+
+		//Regenerate the absolute position used for position checks
+		this.positionAbs = this._convertPositionTo("absolute");
+
+		//Set the helper position
+		if(!this.options.axis || this.options.axis !== "y") {
+			this.helper[0].style.left = this.position.left+"px";
+		}
+		if(!this.options.axis || this.options.axis !== "x") {
+			this.helper[0].style.top = this.position.top+"px";
+		}
+
+		//Rearrange
+		for (i = this.items.length - 1; i >= 0; i--) {
+
+			//Cache variables and intersection, continue if no intersection
+			item = this.items[i];
+			itemElement = item.item[0];
+			intersection = this._intersectsWithPointer(item);
+			if (!intersection) {
+				continue;
+			}
+
+			// Only put the placeholder inside the current Container, skip all
+			// items from other containers. This works because when moving
+			// an item from one container to another the
+			// currentContainer is switched before the placeholder is moved.
+			//
+			// Without this, moving items in "sub-sortables" can cause
+			// the placeholder to jitter beetween the outer and inner container.
+			if (item.instance !== this.currentContainer) {
+				continue;
+			}
+
+			// cannot intersect with itself
+			// no useless actions that have been done before
+			// no action if the item moved is the parent of the item checked
+			if (itemElement !== this.currentItem[0] &&
+				this.placeholder[intersection === 1 ? "next" : "prev"]()[0] !== itemElement &&
+				!$.contains(this.placeholder[0], itemElement) &&
+				(this.options.type === "semi-dynamic" ? !$.contains(this.element[0], itemElement) : true)
+			) {
+
+				this.direction = intersection === 1 ? "down" : "up";
+
+				if (this.options.tolerance === "pointer" || this._intersectsWithSides(item)) {
+					this._rearrange(event, item);
+				} else {
+					break;
+				}
+
+				this._trigger("change", event, this._uiHash());
+				break;
+			}
+		}
+
+		//Post events to containers
+		this._contactContainers(event);
+
+		//Interconnect with droppables
+		if($.ui.ddmanager) {
+			$.ui.ddmanager.drag(this, event);
+		}
+
+		//Call callbacks
+		this._trigger("sort", event, this._uiHash());
+
+		this.lastPositionAbs = this.positionAbs;
+		return false;
+
+	},
+
+	_mouseStop: function(event, noPropagation) {
+
+		if(!event) {
+			return;
+		}
+
+		//If we are using droppables, inform the manager about the drop
+		if ($.ui.ddmanager && !this.options.dropBehaviour) {
+			$.ui.ddmanager.drop(this, event);
+		}
+
+		if(this.options.revert) {
+			var that = this,
+				cur = this.placeholder.offset(),
+				axis = this.options.axis,
+				animation = {};
+
+			if ( !axis || axis === "x" ) {
+				animation.left = cur.left - this.offset.parent.left - this.margins.left + (this.offsetParent[0] === document.body ? 0 : this.offsetParent[0].scrollLeft);
+			}
+			if ( !axis || axis === "y" ) {
+				animation.top = cur.top - this.offset.parent.top - this.margins.top + (this.offsetParent[0] === document.body ? 0 : this.offsetParent[0].scrollTop);
+			}
+			this.reverting = true;
+			$(this.helper).animate( animation, parseInt(this.options.revert, 10) || 500, function() {
+				that._clear(event);
+			});
+		} else {
+			this._clear(event, noPropagation);
+		}
+
+		return false;
+
+	},
+
+	cancel: function() {
+
+		if(this.dragging) {
+
+			this._mouseUp({ target: null });
+
+			if(this.options.helper === "original") {
+				this.currentItem.css(this._storedCSS).removeClass("ui-sortable-helper");
+			} else {
+				this.currentItem.show();
+			}
+
+			//Post deactivating events to containers
+			for (var i = this.containers.length - 1; i >= 0; i--){
+				this.containers[i]._trigger("deactivate", null, this._uiHash(this));
+				if(this.containers[i].containerCache.over) {
+					this.containers[i]._trigger("out", null, this._uiHash(this));
+					this.containers[i].containerCache.over = 0;
+				}
+			}
+
+		}
+
+		if (this.placeholder) {
+			//$(this.placeholder[0]).remove(); would have been the jQuery way - unfortunately, it unbinds ALL events from the original node!
+			if(this.placeholder[0].parentNode) {
+				this.placeholder[0].parentNode.removeChild(this.placeholder[0]);
+			}
+			if(this.options.helper !== "original" && this.helper && this.helper[0].parentNode) {
+				this.helper.remove();
+			}
+
+			$.extend(this, {
+				helper: null,
+				dragging: false,
+				reverting: false,
+				_noFinalSort: null
+			});
+
+			if(this.domPosition.prev) {
+				$(this.domPosition.prev).after(this.currentItem);
+			} else {
+				$(this.domPosition.parent).prepend(this.currentItem);
+			}
+		}
+
+		return this;
+
+	},
+
+	serialize: function(o) {
+
+		var items = this._getItemsAsjQuery(o && o.connected),
+			str = [];
+		o = o || {};
+
+		$(items).each(function() {
+			var res = ($(o.item || this).attr(o.attribute || "id") || "").match(o.expression || (/(.+)[\-=_](.+)/));
+			if (res) {
+				str.push((o.key || res[1]+"[]")+"="+(o.key && o.expression ? res[1] : res[2]));
+			}
+		});
+
+		if(!str.length && o.key) {
+			str.push(o.key + "=");
+		}
+
+		return str.join("&");
+
+	},
+
+	toArray: function(o) {
+
+		var items = this._getItemsAsjQuery(o && o.connected),
+			ret = [];
+
+		o = o || {};
+
+		items.each(function() { ret.push($(o.item || this).attr(o.attribute || "id") || ""); });
+		return ret;
+
+	},
+
+	/* Be careful with the following core functions */
+	_intersectsWith: function(item) {
+
+		var x1 = this.positionAbs.left,
+			x2 = x1 + this.helperProportions.width,
+			y1 = this.positionAbs.top,
+			y2 = y1 + this.helperProportions.height,
+			l = item.left,
+			r = l + item.width,
+			t = item.top,
+			b = t + item.height,
+			dyClick = this.offset.click.top,
+			dxClick = this.offset.click.left,
+			isOverElementHeight = ( this.options.axis === "x" ) || ( ( y1 + dyClick ) > t && ( y1 + dyClick ) < b ),
+			isOverElementWidth = ( this.options.axis === "y" ) || ( ( x1 + dxClick ) > l && ( x1 + dxClick ) < r ),
+			isOverElement = isOverElementHeight && isOverElementWidth;
+
+		if ( this.options.tolerance === "pointer" ||
+			this.options.forcePointerForContainers ||
+			(this.options.tolerance !== "pointer" && this.helperProportions[this.floating ? "width" : "height"] > item[this.floating ? "width" : "height"])
+		) {
+			return isOverElement;
+		} else {
+
+			return (l < x1 + (this.helperProportions.width / 2) && // Right Half
+				x2 - (this.helperProportions.width / 2) < r && // Left Half
+				t < y1 + (this.helperProportions.height / 2) && // Bottom Half
+				y2 - (this.helperProportions.height / 2) < b ); // Top Half
+
+		}
+	},
+
+	_intersectsWithPointer: function(item) {
+
+		var isOverElementHeight = (this.options.axis === "x") || isOverAxis(this.positionAbs.top + this.offset.click.top, item.top, item.height),
+			isOverElementWidth = (this.options.axis === "y") || isOverAxis(this.positionAbs.left + this.offset.click.left, item.left, item.width),
+			isOverElement = isOverElementHeight && isOverElementWidth,
+			verticalDirection = this._getDragVerticalDirection(),
+			horizontalDirection = this._getDragHorizontalDirection();
+
+		if (!isOverElement) {
+			return false;
+		}
+
+		return this.floating ?
+			( ((horizontalDirection && horizontalDirection === "right") || verticalDirection === "down") ? 2 : 1 )
+			: ( verticalDirection && (verticalDirection === "down" ? 2 : 1) );
+
+	},
+
+	_intersectsWithSides: function(item) {
+
+		var isOverBottomHalf = isOverAxis(this.positionAbs.top + this.offset.click.top, item.top + (item.height/2), item.height),
+			isOverRightHalf = isOverAxis(this.positionAbs.left + this.offset.click.left, item.left + (item.width/2), item.width),
+			verticalDirection = this._getDragVerticalDirection(),
+			horizontalDirection = this._getDragHorizontalDirection();
+
+		if (this.floating && horizontalDirection) {
+			return ((horizontalDirection === "right" && isOverRightHalf) || (horizontalDirection === "left" && !isOverRightHalf));
+		} else {
+			return verticalDirection && ((verticalDirection === "down" && isOverBottomHalf) || (verticalDirection === "up" && !isOverBottomHalf));
+		}
+
+	},
+
+	_getDragVerticalDirection: function() {
+		var delta = this.positionAbs.top - this.lastPositionAbs.top;
+		return delta !== 0 && (delta > 0 ? "down" : "up");
+	},
+
+	_getDragHorizontalDirection: function() {
+		var delta = this.positionAbs.left - this.lastPositionAbs.left;
+		return delta !== 0 && (delta > 0 ? "right" : "left");
+	},
+
+	refresh: function(event) {
+		this._refreshItems(event);
+		this.refreshPositions();
+		return this;
+	},
+
+	_connectWith: function() {
+		var options = this.options;
+		return options.connectWith.constructor === String ? [options.connectWith] : options.connectWith;
+	},
+
+	_getItemsAsjQuery: function(connected) {
+
+		var i, j, cur, inst,
+			items = [],
+			queries = [],
+			connectWith = this._connectWith();
+
+		if(connectWith && connected) {
+			for (i = connectWith.length - 1; i >= 0; i--){
+				cur = $(connectWith[i]);
+				for ( j = cur.length - 1; j >= 0; j--){
+					inst = $.data(cur[j], this.widgetFullName);
+					if(inst && inst !== this && !inst.options.disabled) {
+						queries.push([$.isFunction(inst.options.items) ? inst.options.items.call(inst.element) : $(inst.options.items, inst.element).not(".ui-sortable-helper").not(".ui-sortable-placeholder"), inst]);
+					}
+				}
+			}
+		}
+
+		queries.push([$.isFunction(this.options.items) ? this.options.items.call(this.element, null, { options: this.options, item: this.currentItem }) : $(this.options.items, this.element).not(".ui-sortable-helper").not(".ui-sortable-placeholder"), this]);
+
+		function addItems() {
+			items.push( this );
+		}
+		for (i = queries.length - 1; i >= 0; i--){
+			queries[i][0].each( addItems );
+		}
+
+		return $(items);
+
+	},
+
+	_removeCurrentsFromItems: function() {
+
+		var list = this.currentItem.find(":data(" + this.widgetName + "-item)");
+
+		this.items = $.grep(this.items, function (item) {
+			for (var j=0; j < list.length; j++) {
+				if(list[j] === item.item[0]) {
+					return false;
+				}
+			}
+			return true;
+		});
+
+	},
+
+	_refreshItems: function(event) {
+
+		this.items = [];
+		this.containers = [this];
+
+		var i, j, cur, inst, targetData, _queries, item, queriesLength,
+			items = this.items,
+			queries = [[$.isFunction(this.options.items) ? this.options.items.call(this.element[0], event, { item: this.currentItem }) : $(this.options.items, this.element), this]],
+			connectWith = this._connectWith();
+
+		if(connectWith && this.ready) { //Shouldn't be run the first time through due to massive slow-down
+			for (i = connectWith.length - 1; i >= 0; i--){
+				cur = $(connectWith[i]);
+				for (j = cur.length - 1; j >= 0; j--){
+					inst = $.data(cur[j], this.widgetFullName);
+					if(inst && inst !== this && !inst.options.disabled) {
+						queries.push([$.isFunction(inst.options.items) ? inst.options.items.call(inst.element[0], event, { item: this.currentItem }) : $(inst.options.items, inst.element), inst]);
+						this.containers.push(inst);
+					}
+				}
+			}
+		}
+
+		for (i = queries.length - 1; i >= 0; i--) {
+			targetData = queries[i][1];
+			_queries = queries[i][0];
+
+			for (j=0, queriesLength = _queries.length; j < queriesLength; j++) {
+				item = $(_queries[j]);
+
+				item.data(this.widgetName + "-item", targetData); // Data for target checking (mouse manager)
+
+				items.push({
+					item: item,
+					instance: targetData,
+					width: 0, height: 0,
+					left: 0, top: 0
+				});
+			}
+		}
+
+	},
+
+	refreshPositions: function(fast) {
+
+		//This has to be redone because due to the item being moved out/into the offsetParent, the offsetParent's position will change
+		if(this.offsetParent && this.helper) {
+			this.offset.parent = this._getParentOffset();
+		}
+
+		var i, item, t, p;
+
+		for (i = this.items.length - 1; i >= 0; i--){
+			item = this.items[i];
+
+			//We ignore calculating positions of all connected containers when we're not over them
+			if(item.instance !== this.currentContainer && this.currentContainer && item.item[0] !== this.currentItem[0]) {
+				continue;
+			}
+
+			t = this.options.toleranceElement ? $(this.options.toleranceElement, item.item) : item.item;
+
+			if (!fast) {
+				item.width = t.outerWidth();
+				item.height = t.outerHeight();
+			}
+
+			p = t.offset();
+			item.left = p.left;
+			item.top = p.top;
+		}
+
+		if(this.options.custom && this.options.custom.refreshContainers) {
+			this.options.custom.refreshContainers.call(this);
+		} else {
+			for (i = this.containers.length - 1; i >= 0; i--){
+				p = this.containers[i].element.offset();
+				this.containers[i].containerCache.left = p.left;
+				this.containers[i].containerCache.top = p.top;
+				this.containers[i].containerCache.width	= this.containers[i].element.outerWidth();
+				this.containers[i].containerCache.height = this.containers[i].element.outerHeight();
+			}
+		}
+
+		return this;
+	},
+
+	_createPlaceholder: function(that) {
+		that = that || this;
+		var className,
+			o = that.options;
+
+		if(!o.placeholder || o.placeholder.constructor === String) {
+			className = o.placeholder;
+			o.placeholder = {
+				element: function() {
+
+					var nodeName = that.currentItem[0].nodeName.toLowerCase(),
+						element = $( "<" + nodeName + ">", that.document[0] )
+							.addClass(className || that.currentItem[0].className+" ui-sortable-placeholder")
+							.removeClass("ui-sortable-helper");
+
+					if ( nodeName === "tr" ) {
+						that.currentItem.children().each(function() {
+							$( "<td>&#160;</td>", that.document[0] )
+								.attr( "colspan", $( this ).attr( "colspan" ) || 1 )
+								.appendTo( element );
+						});
+					} else if ( nodeName === "img" ) {
+						element.attr( "src", that.currentItem.attr( "src" ) );
+					}
+
+					if ( !className ) {
+						element.css( "visibility", "hidden" );
+					}
+
+					return element;
+				},
+				update: function(container, p) {
+
+					// 1. If a className is set as 'placeholder option, we don't force sizes - the class is responsible for that
+					// 2. The option 'forcePlaceholderSize can be enabled to force it even if a class name is specified
+					if(className && !o.forcePlaceholderSize) {
+						return;
+					}
+
+					//If the element doesn't have a actual height by itself (without styles coming from a stylesheet), it receives the inline height from the dragged item
+					if(!p.height()) { p.height(that.currentItem.innerHeight() - parseInt(that.currentItem.css("paddingTop")||0, 10) - parseInt(that.currentItem.css("paddingBottom")||0, 10)); }
+					if(!p.width()) { p.width(that.currentItem.innerWidth() - parseInt(that.currentItem.css("paddingLeft")||0, 10) - parseInt(that.currentItem.css("paddingRight")||0, 10)); }
+				}
+			};
+		}
+
+		//Create the placeholder
+		that.placeholder = $(o.placeholder.element.call(that.element, that.currentItem));
+
+		//Append it after the actual current item
+		that.currentItem.after(that.placeholder);
+
+		//Update the size of the placeholder (TODO: Logic to fuzzy, see line 316/317)
+		o.placeholder.update(that, that.placeholder);
+
+	},
+
+	_contactContainers: function(event) {
+		var i, j, dist, itemWithLeastDistance, posProperty, sizeProperty, base, cur, nearBottom, floating,
+			innermostContainer = null,
+			innermostIndex = null;
+
+		// get innermost container that intersects with item
+		for (i = this.containers.length - 1; i >= 0; i--) {
+
+			// never consider a container that's located within the item itself
+			if($.contains(this.currentItem[0], this.containers[i].element[0])) {
+				continue;
+			}
+
+			if(this._intersectsWith(this.containers[i].containerCache)) {
+
+				// if we've already found a container and it's more "inner" than this, then continue
+				if(innermostContainer && $.contains(this.containers[i].element[0], innermostContainer.element[0])) {
+					continue;
+				}
+
+				innermostContainer = this.containers[i];
+				innermostIndex = i;
+
+			} else {
+				// container doesn't intersect. trigger "out" event if necessary
+				if(this.containers[i].containerCache.over) {
+					this.containers[i]._trigger("out", event, this._uiHash(this));
+					this.containers[i].containerCache.over = 0;
+				}
+			}
+
+		}
+
+		// if no intersecting containers found, return
+		if(!innermostContainer) {
+			return;
+		}
+
+		// move the item into the container if it's not there already
+		if(this.containers.length === 1) {
+			if (!this.containers[innermostIndex].containerCache.over) {
+				this.containers[innermostIndex]._trigger("over", event, this._uiHash(this));
+				this.containers[innermostIndex].containerCache.over = 1;
+			}
+		} else {
+
+			//When entering a new container, we will find the item with the least distance and append our item near it
+			dist = 10000;
+			itemWithLeastDistance = null;
+			floating = innermostContainer.floating || isFloating(this.currentItem);
+			posProperty = floating ? "left" : "top";
+			sizeProperty = floating ? "width" : "height";
+			base = this.positionAbs[posProperty] + this.offset.click[posProperty];
+			for (j = this.items.length - 1; j >= 0; j--) {
+				if(!$.contains(this.containers[innermostIndex].element[0], this.items[j].item[0])) {
+					continue;
+				}
+				if(this.items[j].item[0] === this.currentItem[0]) {
+					continue;
+				}
+				if (floating && !isOverAxis(this.positionAbs.top + this.offset.click.top, this.items[j].top, this.items[j].height)) {
+					continue;
+				}
+				cur = this.items[j].item.offset()[posProperty];
+				nearBottom = false;
+				if(Math.abs(cur - base) > Math.abs(cur + this.items[j][sizeProperty] - base)){
+					nearBottom = true;
+					cur += this.items[j][sizeProperty];
+				}
+
+				if(Math.abs(cur - base) < dist) {
+					dist = Math.abs(cur - base); itemWithLeastDistance = this.items[j];
+					this.direction = nearBottom ? "up": "down";
+				}
+			}
+
+			//Check if dropOnEmpty is enabled
+			if(!itemWithLeastDistance && !this.options.dropOnEmpty) {
+				return;
+			}
+
+			if(this.currentContainer === this.containers[innermostIndex]) {
+				return;
+			}
+
+			itemWithLeastDistance ? this._rearrange(event, itemWithLeastDistance, null, true) : this._rearrange(event, null, this.containers[innermostIndex].element, true);
+			this._trigger("change", event, this._uiHash());
+			this.containers[innermostIndex]._trigger("change", event, this._uiHash(this));
+			this.currentContainer = this.containers[innermostIndex];
+
+			//Update the placeholder
+			this.options.placeholder.update(this.currentContainer, this.placeholder);
+
+			this.containers[innermostIndex]._trigger("over", event, this._uiHash(this));
+			this.containers[innermostIndex].containerCache.over = 1;
+		}
+
+
+	},
+
+	_createHelper: function(event) {
+
+		var o = this.options,
+			helper = $.isFunction(o.helper) ? $(o.helper.apply(this.element[0], [event, this.currentItem])) : (o.helper === "clone" ? this.currentItem.clone() : this.currentItem);
+
+		//Add the helper to the DOM if that didn't happen already
+		if(!helper.parents("body").length) {
+			$(o.appendTo !== "parent" ? o.appendTo : this.currentItem[0].parentNode)[0].appendChild(helper[0]);
+		}
+
+		if(helper[0] === this.currentItem[0]) {
+			this._storedCSS = { width: this.currentItem[0].style.width, height: this.currentItem[0].style.height, position: this.currentItem.css("position"), top: this.currentItem.css("top"), left: this.currentItem.css("left") };
+		}
+
+		if(!helper[0].style.width || o.forceHelperSize) {
+			helper.width(this.currentItem.width());
+		}
+		if(!helper[0].style.height || o.forceHelperSize) {
+			helper.height(this.currentItem.height());
+		}
+
+		return helper;
+
+	},
+
+	_adjustOffsetFromHelper: function(obj) {
+		if (typeof obj === "string") {
+			obj = obj.split(" ");
+		}
+		if ($.isArray(obj)) {
+			obj = {left: +obj[0], top: +obj[1] || 0};
+		}
+		if ("left" in obj) {
+			this.offset.click.left = obj.left + this.margins.left;
+		}
+		if ("right" in obj) {
+			this.offset.click.left = this.helperProportions.width - obj.right + this.margins.left;
+		}
+		if ("top" in obj) {
+			this.offset.click.top = obj.top + this.margins.top;
+		}
+		if ("bottom" in obj) {
+			this.offset.click.top = this.helperProportions.height - obj.bottom + this.margins.top;
+		}
+	},
+
+	_getParentOffset: function() {
+
+
+		//Get the offsetParent and cache its position
+		this.offsetParent = this.helper.offsetParent();
+		var po = this.offsetParent.offset();
+
+		// This is a special case where we need to modify a offset calculated on start, since the following happened:
+		// 1. The position of the helper is absolute, so it's position is calculated based on the next positioned parent
+		// 2. The actual offset parent is a child of the scroll parent, and the scroll parent isn't the document, which means that
+		//    the scroll is included in the initial calculation of the offset of the parent, and never recalculated upon drag
+		if(this.cssPosition === "absolute" && this.scrollParent[0] !== document && $.contains(this.scrollParent[0], this.offsetParent[0])) {
+			po.left += this.scrollParent.scrollLeft();
+			po.top += this.scrollParent.scrollTop();
+		}
+
+		// This needs to be actually done for all browsers, since pageX/pageY includes this information
+		// with an ugly IE fix
+		if( this.offsetParent[0] === document.body || (this.offsetParent[0].tagName && this.offsetParent[0].tagName.toLowerCase() === "html" && $.ui.ie)) {
+			po = { top: 0, left: 0 };
+		}
+
+		return {
+			top: po.top + (parseInt(this.offsetParent.css("borderTopWidth"),10) || 0),
+			left: po.left + (parseInt(this.offsetParent.css("borderLeftWidth"),10) || 0)
+		};
+
+	},
+
+	_getRelativeOffset: function() {
+
+		if(this.cssPosition === "relative") {
+			var p = this.currentItem.position();
+			return {
+				top: p.top - (parseInt(this.helper.css("top"),10) || 0) + this.scrollParent.scrollTop(),
+				left: p.left - (parseInt(this.helper.css("left"),10) || 0) + this.scrollParent.scrollLeft()
+			};
+		} else {
+			return { top: 0, left: 0 };
+		}
+
+	},
+
+	_cacheMargins: function() {
+		this.margins = {
+			left: (parseInt(this.currentItem.css("marginLeft"),10) || 0),
+			top: (parseInt(this.currentItem.css("marginTop"),10) || 0)
+		};
+	},
+
+	_cacheHelperProportions: function() {
+		this.helperProportions = {
+			width: this.helper.outerWidth(),
+			height: this.helper.outerHeight()
+		};
+	},
+
+	_setContainment: function() {
+
+		var ce, co, over,
+			o = this.options;
+		if(o.containment === "parent") {
+			o.containment = this.helper[0].parentNode;
+		}
+		if(o.containment === "document" || o.containment === "window") {
+			this.containment = [
+				0 - this.offset.relative.left - this.offset.parent.left,
+				0 - this.offset.relative.top - this.offset.parent.top,
+				$(o.containment === "document" ? document : window).width() - this.helperProportions.width - this.margins.left,
+				($(o.containment === "document" ? document : window).height() || document.body.parentNode.scrollHeight) - this.helperProportions.height - this.margins.top
+			];
+		}
+
+		if(!(/^(document|window|parent)$/).test(o.containment)) {
+			ce = $(o.containment)[0];
+			co = $(o.containment).offset();
+			over = ($(ce).css("overflow") !== "hidden");
+
+			this.containment = [
+				co.left + (parseInt($(ce).css("borderLeftWidth"),10) || 0) + (parseInt($(ce).css("paddingLeft"),10) || 0) - this.margins.left,
+				co.top + (parseInt($(ce).css("borderTopWidth"),10) || 0) + (parseInt($(ce).css("paddingTop"),10) || 0) - this.margins.top,
+				co.left+(over ? Math.max(ce.scrollWidth,ce.offsetWidth) : ce.offsetWidth) - (parseInt($(ce).css("borderLeftWidth"),10) || 0) - (parseInt($(ce).css("paddingRight"),10) || 0) - this.helperProportions.width - this.margins.left,
+				co.top+(over ? Math.max(ce.scrollHeight,ce.offsetHeight) : ce.offsetHeight) - (parseInt($(ce).css("borderTopWidth"),10) || 0) - (parseInt($(ce).css("paddingBottom"),10) || 0) - this.helperProportions.height - this.margins.top
+			];
+		}
+
+	},
+
+	_convertPositionTo: function(d, pos) {
+
+		if(!pos) {
+			pos = this.position;
+		}
+		var mod = d === "absolute" ? 1 : -1,
+			scroll = this.cssPosition === "absolute" && !(this.scrollParent[0] !== document && $.contains(this.scrollParent[0], this.offsetParent[0])) ? this.offsetParent : this.scrollParent,
+			scrollIsRootNode = (/(html|body)/i).test(scroll[0].tagName);
+
+		return {
+			top: (
+				pos.top	+																// The absolute mouse position
+				this.offset.relative.top * mod +										// Only for relative positioned nodes: Relative offset from element to offset parent
+				this.offset.parent.top * mod -											// The offsetParent's offset without borders (offset + border)
+				( ( this.cssPosition === "fixed" ? -this.scrollParent.scrollTop() : ( scrollIsRootNode ? 0 : scroll.scrollTop() ) ) * mod)
+			),
+			left: (
+				pos.left +																// The absolute mouse position
+				this.offset.relative.left * mod +										// Only for relative positioned nodes: Relative offset from element to offset parent
+				this.offset.parent.left * mod	-										// The offsetParent's offset without borders (offset + border)
+				( ( this.cssPosition === "fixed" ? -this.scrollParent.scrollLeft() : scrollIsRootNode ? 0 : scroll.scrollLeft() ) * mod)
+			)
+		};
+
+	},
+
+	_generatePosition: function(event) {
+
+		var top, left,
+			o = this.options,
+			pageX = event.pageX,
+			pageY = event.pageY,
+			scroll = this.cssPosition === "absolute" && !(this.scrollParent[0] !== document && $.contains(this.scrollParent[0], this.offsetParent[0])) ? this.offsetParent : this.scrollParent, scrollIsRootNode = (/(html|body)/i).test(scroll[0].tagName);
+
+		// This is another very weird special case that only happens for relative elements:
+		// 1. If the css position is relative
+		// 2. and the scroll parent is the document or similar to the offset parent
+		// we have to refresh the relative offset during the scroll so there are no jumps
+		if(this.cssPosition === "relative" && !(this.scrollParent[0] !== document && this.scrollParent[0] !== this.offsetParent[0])) {
+			this.offset.relative = this._getRelativeOffset();
+		}
+
+		/*
+		 * - Position constraining -
+		 * Constrain the position to a mix of grid, containment.
+		 */
+
+		if(this.originalPosition) { //If we are not dragging yet, we won't check for options
+
+			if(this.containment) {
+				if(event.pageX - this.offset.click.left < this.containment[0]) {
+					pageX = this.containment[0] + this.offset.click.left;
+				}
+				if(event.pageY - this.offset.click.top < this.containment[1]) {
+					pageY = this.containment[1] + this.offset.click.top;
+				}
+				if(event.pageX - this.offset.click.left > this.containment[2]) {
+					pageX = this.containment[2] + this.offset.click.left;
+				}
+				if(event.pageY - this.offset.click.top > this.containment[3]) {
+					pageY = this.containment[3] + this.offset.click.top;
+				}
+			}
+
+			if(o.grid) {
+				top = this.originalPageY + Math.round((pageY - this.originalPageY) / o.grid[1]) * o.grid[1];
+				pageY = this.containment ? ( (top - this.offset.click.top >= this.containment[1] && top - this.offset.click.top <= this.containment[3]) ? top : ((top - this.offset.click.top >= this.containment[1]) ? top - o.grid[1] : top + o.grid[1])) : top;
+
+				left = this.originalPageX + Math.round((pageX - this.originalPageX) / o.grid[0]) * o.grid[0];
+				pageX = this.containment ? ( (left - this.offset.click.left >= this.containment[0] && left - this.offset.click.left <= this.containment[2]) ? left : ((left - this.offset.click.left >= this.containment[0]) ? left - o.grid[0] : left + o.grid[0])) : left;
+			}
+
+		}
+
+		return {
+			top: (
+				pageY -																// The absolute mouse position
+				this.offset.click.top -													// Click offset (relative to the element)
+				this.offset.relative.top	-											// Only for relative positioned nodes: Relative offset from element to offset parent
+				this.offset.parent.top +												// The offsetParent's offset without borders (offset + border)
+				( ( this.cssPosition === "fixed" ? -this.scrollParent.scrollTop() : ( scrollIsRootNode ? 0 : scroll.scrollTop() ) ))
+			),
+			left: (
+				pageX -																// The absolute mouse position
+				this.offset.click.left -												// Click offset (relative to the element)
+				this.offset.relative.left	-											// Only for relative positioned nodes: Relative offset from element to offset parent
+				this.offset.parent.left +												// The offsetParent's offset without borders (offset + border)
+				( ( this.cssPosition === "fixed" ? -this.scrollParent.scrollLeft() : scrollIsRootNode ? 0 : scroll.scrollLeft() ))
+			)
+		};
+
+	},
+
+	_rearrange: function(event, i, a, hardRefresh) {
+
+		a ? a[0].appendChild(this.placeholder[0]) : i.item[0].parentNode.insertBefore(this.placeholder[0], (this.direction === "down" ? i.item[0] : i.item[0].nextSibling));
+
+		//Various things done here to improve the performance:
+		// 1. we create a setTimeout, that calls refreshPositions
+		// 2. on the instance, we have a counter variable, that get's higher after every append
+		// 3. on the local scope, we copy the counter variable, and check in the timeout, if it's still the same
+		// 4. this lets only the last addition to the timeout stack through
+		this.counter = this.counter ? ++this.counter : 1;
+		var counter = this.counter;
+
+		this._delay(function() {
+			if(counter === this.counter) {
+				this.refreshPositions(!hardRefresh); //Precompute after each DOM insertion, NOT on mousemove
+			}
+		});
+
+	},
+
+	_clear: function(event, noPropagation) {
+
+		this.reverting = false;
+		// We delay all events that have to be triggered to after the point where the placeholder has been removed and
+		// everything else normalized again
+		var i,
+			delayedTriggers = [];
+
+		// We first have to update the dom position of the actual currentItem
+		// Note: don't do it if the current item is already removed (by a user), or it gets reappended (see #4088)
+		if(!this._noFinalSort && this.currentItem.parent().length) {
+			this.placeholder.before(this.currentItem);
+		}
+		this._noFinalSort = null;
+
+		if(this.helper[0] === this.currentItem[0]) {
+			for(i in this._storedCSS) {
+				if(this._storedCSS[i] === "auto" || this._storedCSS[i] === "static") {
+					this._storedCSS[i] = "";
+				}
+			}
+			this.currentItem.css(this._storedCSS).removeClass("ui-sortable-helper");
+		} else {
+			this.currentItem.show();
+		}
+
+		if(this.fromOutside && !noPropagation) {
+			delayedTriggers.push(function(event) { this._trigger("receive", event, this._uiHash(this.fromOutside)); });
+		}
+		if((this.fromOutside || this.domPosition.prev !== this.currentItem.prev().not(".ui-sortable-helper")[0] || this.domPosition.parent !== this.currentItem.parent()[0]) && !noPropagation) {
+			delayedTriggers.push(function(event) { this._trigger("update", event, this._uiHash()); }); //Trigger update callback if the DOM position has changed
+		}
+
+		// Check if the items Container has Changed and trigger appropriate
+		// events.
+		if (this !== this.currentContainer) {
+			if(!noPropagation) {
+				delayedTriggers.push(function(event) { this._trigger("remove", event, this._uiHash()); });
+				delayedTriggers.push((function(c) { return function(event) { c._trigger("receive", event, this._uiHash(this)); };  }).call(this, this.currentContainer));
+				delayedTriggers.push((function(c) { return function(event) { c._trigger("update", event, this._uiHash(this));  }; }).call(this, this.currentContainer));
+			}
+		}
+
+
+		//Post events to containers
+		function delayEvent( type, instance, container ) {
+			return function( event ) {
+				container._trigger( type, event, instance._uiHash( instance ) );
+			};
+		}
+		for (i = this.containers.length - 1; i >= 0; i--){
+			if (!noPropagation) {
+				delayedTriggers.push( delayEvent( "deactivate", this, this.containers[ i ] ) );
+			}
+			if(this.containers[i].containerCache.over) {
+				delayedTriggers.push( delayEvent( "out", this, this.containers[ i ] ) );
+				this.containers[i].containerCache.over = 0;
+			}
+		}
+
+		//Do what was originally in plugins
+		if ( this.storedCursor ) {
+			this.document.find( "body" ).css( "cursor", this.storedCursor );
+			this.storedStylesheet.remove();
+		}
+		if(this._storedOpacity) {
+			this.helper.css("opacity", this._storedOpacity);
+		}
+		if(this._storedZIndex) {
+			this.helper.css("zIndex", this._storedZIndex === "auto" ? "" : this._storedZIndex);
+		}
+
+		this.dragging = false;
+		if(this.cancelHelperRemoval) {
+			if(!noPropagation) {
+				this._trigger("beforeStop", event, this._uiHash());
+				for (i=0; i < delayedTriggers.length; i++) {
+					delayedTriggers[i].call(this, event);
+				} //Trigger all delayed events
+				this._trigger("stop", event, this._uiHash());
+			}
+
+			this.fromOutside = false;
+			return false;
+		}
+
+		if(!noPropagation) {
+			this._trigger("beforeStop", event, this._uiHash());
+		}
+
+		//$(this.placeholder[0]).remove(); would have been the jQuery way - unfortunately, it unbinds ALL events from the original node!
+		this.placeholder[0].parentNode.removeChild(this.placeholder[0]);
+
+		if(this.helper[0] !== this.currentItem[0]) {
+			this.helper.remove();
+		}
+		this.helper = null;
+
+		if(!noPropagation) {
+			for (i=0; i < delayedTriggers.length; i++) {
+				delayedTriggers[i].call(this, event);
+			} //Trigger all delayed events
+			this._trigger("stop", event, this._uiHash());
+		}
+
+		this.fromOutside = false;
+		return true;
+
+	},
+
+	_trigger: function() {
+		if ($.Widget.prototype._trigger.apply(this, arguments) === false) {
+			this.cancel();
+		}
+	},
+
+	_uiHash: function(_inst) {
+		var inst = _inst || this;
+		return {
+			helper: inst.helper,
+			placeholder: inst.placeholder || $([]),
+			position: inst.position,
+			originalPosition: inst.originalPosition,
+			offset: inst.positionAbs,
+			item: inst.currentItem,
+			sender: _inst ? _inst.element : null
+		};
+	}
+
+});
+
+})(jQuery);
diff --git a/static/js/jquery.ui.widget.js b/static/js/jquery.ui.widget.js
new file mode 100644
index 0000000000..1c0cbd1732
--- /dev/null
+++ b/static/js/jquery.ui.widget.js
@@ -0,0 +1,521 @@
+/*!
+ * jQuery UI Widget 1.10.4
+ * http://jqueryui.com
+ *
+ * Copyright 2014 jQuery Foundation and other contributors
+ * Released under the MIT license.
+ * http://jquery.org/license
+ *
+ * http://api.jqueryui.com/jQuery.widget/
+ */
+(function( $, undefined ) {
+
+var uuid = 0,
+	slice = Array.prototype.slice,
+	_cleanData = $.cleanData;
+$.cleanData = function( elems ) {
+	for ( var i = 0, elem; (elem = elems[i]) != null; i++ ) {
+		try {
+			$( elem ).triggerHandler( "remove" );
+		// http://bugs.jquery.com/ticket/8235
+		} catch( e ) {}
+	}
+	_cleanData( elems );
+};
+
+$.widget = function( name, base, prototype ) {
+	var fullName, existingConstructor, constructor, basePrototype,
+		// proxiedPrototype allows the provided prototype to remain unmodified
+		// so that it can be used as a mixin for multiple widgets (#8876)
+		proxiedPrototype = {},
+		namespace = name.split( "." )[ 0 ];
+
+	name = name.split( "." )[ 1 ];
+	fullName = namespace + "-" + name;
+
+	if ( !prototype ) {
+		prototype = base;
+		base = $.Widget;
+	}
+
+	// create selector for plugin
+	$.expr[ ":" ][ fullName.toLowerCase() ] = function( elem ) {
+		return !!$.data( elem, fullName );
+	};
+
+	$[ namespace ] = $[ namespace ] || {};
+	existingConstructor = $[ namespace ][ name ];
+	constructor = $[ namespace ][ name ] = function( options, element ) {
+		// allow instantiation without "new" keyword
+		if ( !this._createWidget ) {
+			return new constructor( options, element );
+		}
+
+		// allow instantiation without initializing for simple inheritance
+		// must use "new" keyword (the code above always passes args)
+		if ( arguments.length ) {
+			this._createWidget( options, element );
+		}
+	};
+	// extend with the existing constructor to carry over any static properties
+	$.extend( constructor, existingConstructor, {
+		version: prototype.version,
+		// copy the object used to create the prototype in case we need to
+		// redefine the widget later
+		_proto: $.extend( {}, prototype ),
+		// track widgets that inherit from this widget in case this widget is
+		// redefined after a widget inherits from it
+		_childConstructors: []
+	});
+
+	basePrototype = new base();
+	// we need to make the options hash a property directly on the new instance
+	// otherwise we'll modify the options hash on the prototype that we're
+	// inheriting from
+	basePrototype.options = $.widget.extend( {}, basePrototype.options );
+	$.each( prototype, function( prop, value ) {
+		if ( !$.isFunction( value ) ) {
+			proxiedPrototype[ prop ] = value;
+			return;
+		}
+		proxiedPrototype[ prop ] = (function() {
+			var _super = function() {
+					return base.prototype[ prop ].apply( this, arguments );
+				},
+				_superApply = function( args ) {
+					return base.prototype[ prop ].apply( this, args );
+				};
+			return function() {
+				var __super = this._super,
+					__superApply = this._superApply,
+					returnValue;
+
+				this._super = _super;
+				this._superApply = _superApply;
+
+				returnValue = value.apply( this, arguments );
+
+				this._super = __super;
+				this._superApply = __superApply;
+
+				return returnValue;
+			};
+		})();
+	});
+	constructor.prototype = $.widget.extend( basePrototype, {
+		// TODO: remove support for widgetEventPrefix
+		// always use the name + a colon as the prefix, e.g., draggable:start
+		// don't prefix for widgets that aren't DOM-based
+		widgetEventPrefix: existingConstructor ? (basePrototype.widgetEventPrefix || name) : name
+	}, proxiedPrototype, {
+		constructor: constructor,
+		namespace: namespace,
+		widgetName: name,
+		widgetFullName: fullName
+	});
+
+	// If this widget is being redefined then we need to find all widgets that
+	// are inheriting from it and redefine all of them so that they inherit from
+	// the new version of this widget. We're essentially trying to replace one
+	// level in the prototype chain.
+	if ( existingConstructor ) {
+		$.each( existingConstructor._childConstructors, function( i, child ) {
+			var childPrototype = child.prototype;
+
+			// redefine the child widget using the same prototype that was
+			// originally used, but inherit from the new version of the base
+			$.widget( childPrototype.namespace + "." + childPrototype.widgetName, constructor, child._proto );
+		});
+		// remove the list of existing child constructors from the old constructor
+		// so the old child constructors can be garbage collected
+		delete existingConstructor._childConstructors;
+	} else {
+		base._childConstructors.push( constructor );
+	}
+
+	$.widget.bridge( name, constructor );
+};
+
+$.widget.extend = function( target ) {
+	var input = slice.call( arguments, 1 ),
+		inputIndex = 0,
+		inputLength = input.length,
+		key,
+		value;
+	for ( ; inputIndex < inputLength; inputIndex++ ) {
+		for ( key in input[ inputIndex ] ) {
+			value = input[ inputIndex ][ key ];
+			if ( input[ inputIndex ].hasOwnProperty( key ) && value !== undefined ) {
+				// Clone objects
+				if ( $.isPlainObject( value ) ) {
+					target[ key ] = $.isPlainObject( target[ key ] ) ?
+						$.widget.extend( {}, target[ key ], value ) :
+						// Don't extend strings, arrays, etc. with objects
+						$.widget.extend( {}, value );
+				// Copy everything else by reference
+				} else {
+					target[ key ] = value;
+				}
+			}
+		}
+	}
+	return target;
+};
+
+$.widget.bridge = function( name, object ) {
+	var fullName = object.prototype.widgetFullName || name;
+	$.fn[ name ] = function( options ) {
+		var isMethodCall = typeof options === "string",
+			args = slice.call( arguments, 1 ),
+			returnValue = this;
+
+		// allow multiple hashes to be passed on init
+		options = !isMethodCall && args.length ?
+			$.widget.extend.apply( null, [ options ].concat(args) ) :
+			options;
+
+		if ( isMethodCall ) {
+			this.each(function() {
+				var methodValue,
+					instance = $.data( this, fullName );
+				if ( !instance ) {
+					return $.error( "cannot call methods on " + name + " prior to initialization; " +
+						"attempted to call method '" + options + "'" );
+				}
+				if ( !$.isFunction( instance[options] ) || options.charAt( 0 ) === "_" ) {
+					return $.error( "no such method '" + options + "' for " + name + " widget instance" );
+				}
+				methodValue = instance[ options ].apply( instance, args );
+				if ( methodValue !== instance && methodValue !== undefined ) {
+					returnValue = methodValue && methodValue.jquery ?
+						returnValue.pushStack( methodValue.get() ) :
+						methodValue;
+					return false;
+				}
+			});
+		} else {
+			this.each(function() {
+				var instance = $.data( this, fullName );
+				if ( instance ) {
+					instance.option( options || {} )._init();
+				} else {
+					$.data( this, fullName, new object( options, this ) );
+				}
+			});
+		}
+
+		return returnValue;
+	};
+};
+
+$.Widget = function( /* options, element */ ) {};
+$.Widget._childConstructors = [];
+
+$.Widget.prototype = {
+	widgetName: "widget",
+	widgetEventPrefix: "",
+	defaultElement: "<div>",
+	options: {
+		disabled: false,
+
+		// callbacks
+		create: null
+	},
+	_createWidget: function( options, element ) {
+		element = $( element || this.defaultElement || this )[ 0 ];
+		this.element = $( element );
+		this.uuid = uuid++;
+		this.eventNamespace = "." + this.widgetName + this.uuid;
+		this.options = $.widget.extend( {},
+			this.options,
+			this._getCreateOptions(),
+			options );
+
+		this.bindings = $();
+		this.hoverable = $();
+		this.focusable = $();
+
+		if ( element !== this ) {
+			$.data( element, this.widgetFullName, this );
+			this._on( true, this.element, {
+				remove: function( event ) {
+					if ( event.target === element ) {
+						this.destroy();
+					}
+				}
+			});
+			this.document = $( element.style ?
+				// element within the document
+				element.ownerDocument :
+				// element is window or document
+				element.document || element );
+			this.window = $( this.document[0].defaultView || this.document[0].parentWindow );
+		}
+
+		this._create();
+		this._trigger( "create", null, this._getCreateEventData() );
+		this._init();
+	},
+	_getCreateOptions: $.noop,
+	_getCreateEventData: $.noop,
+	_create: $.noop,
+	_init: $.noop,
+
+	destroy: function() {
+		this._destroy();
+		// we can probably remove the unbind calls in 2.0
+		// all event bindings should go through this._on()
+		this.element
+			.unbind( this.eventNamespace )
+			// 1.9 BC for #7810
+			// TODO remove dual storage
+			.removeData( this.widgetName )
+			.removeData( this.widgetFullName )
+			// support: jquery <1.6.3
+			// http://bugs.jquery.com/ticket/9413
+			.removeData( $.camelCase( this.widgetFullName ) );
+		this.widget()
+			.unbind( this.eventNamespace )
+			.removeAttr( "aria-disabled" )
+			.removeClass(
+				this.widgetFullName + "-disabled " +
+				"ui-state-disabled" );
+
+		// clean up events and states
+		this.bindings.unbind( this.eventNamespace );
+		this.hoverable.removeClass( "ui-state-hover" );
+		this.focusable.removeClass( "ui-state-focus" );
+	},
+	_destroy: $.noop,
+
+	widget: function() {
+		return this.element;
+	},
+
+	option: function( key, value ) {
+		var options = key,
+			parts,
+			curOption,
+			i;
+
+		if ( arguments.length === 0 ) {
+			// don't return a reference to the internal hash
+			return $.widget.extend( {}, this.options );
+		}
+
+		if ( typeof key === "string" ) {
+			// handle nested keys, e.g., "foo.bar" => { foo: { bar: ___ } }
+			options = {};
+			parts = key.split( "." );
+			key = parts.shift();
+			if ( parts.length ) {
+				curOption = options[ key ] = $.widget.extend( {}, this.options[ key ] );
+				for ( i = 0; i < parts.length - 1; i++ ) {
+					curOption[ parts[ i ] ] = curOption[ parts[ i ] ] || {};
+					curOption = curOption[ parts[ i ] ];
+				}
+				key = parts.pop();
+				if ( arguments.length === 1 ) {
+					return curOption[ key ] === undefined ? null : curOption[ key ];
+				}
+				curOption[ key ] = value;
+			} else {
+				if ( arguments.length === 1 ) {
+					return this.options[ key ] === undefined ? null : this.options[ key ];
+				}
+				options[ key ] = value;
+			}
+		}
+
+		this._setOptions( options );
+
+		return this;
+	},
+	_setOptions: function( options ) {
+		var key;
+
+		for ( key in options ) {
+			this._setOption( key, options[ key ] );
+		}
+
+		return this;
+	},
+	_setOption: function( key, value ) {
+		this.options[ key ] = value;
+
+		if ( key === "disabled" ) {
+			this.widget()
+				.toggleClass( this.widgetFullName + "-disabled ui-state-disabled", !!value )
+				.attr( "aria-disabled", value );
+			this.hoverable.removeClass( "ui-state-hover" );
+			this.focusable.removeClass( "ui-state-focus" );
+		}
+
+		return this;
+	},
+
+	enable: function() {
+		return this._setOption( "disabled", false );
+	},
+	disable: function() {
+		return this._setOption( "disabled", true );
+	},
+
+	_on: function( suppressDisabledCheck, element, handlers ) {
+		var delegateElement,
+			instance = this;
+
+		// no suppressDisabledCheck flag, shuffle arguments
+		if ( typeof suppressDisabledCheck !== "boolean" ) {
+			handlers = element;
+			element = suppressDisabledCheck;
+			suppressDisabledCheck = false;
+		}
+
+		// no element argument, shuffle and use this.element
+		if ( !handlers ) {
+			handlers = element;
+			element = this.element;
+			delegateElement = this.widget();
+		} else {
+			// accept selectors, DOM elements
+			element = delegateElement = $( element );
+			this.bindings = this.bindings.add( element );
+		}
+
+		$.each( handlers, function( event, handler ) {
+			function handlerProxy() {
+				// allow widgets to customize the disabled handling
+				// - disabled as an array instead of boolean
+				// - disabled class as method for disabling individual parts
+				if ( !suppressDisabledCheck &&
+						( instance.options.disabled === true ||
+							$( this ).hasClass( "ui-state-disabled" ) ) ) {
+					return;
+				}
+				return ( typeof handler === "string" ? instance[ handler ] : handler )
+					.apply( instance, arguments );
+			}
+
+			// copy the guid so direct unbinding works
+			if ( typeof handler !== "string" ) {
+				handlerProxy.guid = handler.guid =
+					handler.guid || handlerProxy.guid || $.guid++;
+			}
+
+			var match = event.match( /^(\w+)\s*(.*)$/ ),
+				eventName = match[1] + instance.eventNamespace,
+				selector = match[2];
+			if ( selector ) {
+				delegateElement.delegate( selector, eventName, handlerProxy );
+			} else {
+				element.bind( eventName, handlerProxy );
+			}
+		});
+	},
+
+	_off: function( element, eventName ) {
+		eventName = (eventName || "").split( " " ).join( this.eventNamespace + " " ) + this.eventNamespace;
+		element.unbind( eventName ).undelegate( eventName );
+	},
+
+	_delay: function( handler, delay ) {
+		function handlerProxy() {
+			return ( typeof handler === "string" ? instance[ handler ] : handler )
+				.apply( instance, arguments );
+		}
+		var instance = this;
+		return setTimeout( handlerProxy, delay || 0 );
+	},
+
+	_hoverable: function( element ) {
+		this.hoverable = this.hoverable.add( element );
+		this._on( element, {
+			mouseenter: function( event ) {
+				$( event.currentTarget ).addClass( "ui-state-hover" );
+			},
+			mouseleave: function( event ) {
+				$( event.currentTarget ).removeClass( "ui-state-hover" );
+			}
+		});
+	},
+
+	_focusable: function( element ) {
+		this.focusable = this.focusable.add( element );
+		this._on( element, {
+			focusin: function( event ) {
+				$( event.currentTarget ).addClass( "ui-state-focus" );
+			},
+			focusout: function( event ) {
+				$( event.currentTarget ).removeClass( "ui-state-focus" );
+			}
+		});
+	},
+
+	_trigger: function( type, event, data ) {
+		var prop, orig,
+			callback = this.options[ type ];
+
+		data = data || {};
+		event = $.Event( event );
+		event.type = ( type === this.widgetEventPrefix ?
+			type :
+			this.widgetEventPrefix + type ).toLowerCase();
+		// the original event may come from any element
+		// so we need to reset the target on the new event
+		event.target = this.element[ 0 ];
+
+		// copy original event properties over to the new event
+		orig = event.originalEvent;
+		if ( orig ) {
+			for ( prop in orig ) {
+				if ( !( prop in event ) ) {
+					event[ prop ] = orig[ prop ];
+				}
+			}
+		}
+
+		this.element.trigger( event, data );
+		return !( $.isFunction( callback ) &&
+			callback.apply( this.element[0], [ event ].concat( data ) ) === false ||
+			event.isDefaultPrevented() );
+	}
+};
+
+$.each( { show: "fadeIn", hide: "fadeOut" }, function( method, defaultEffect ) {
+	$.Widget.prototype[ "_" + method ] = function( element, options, callback ) {
+		if ( typeof options === "string" ) {
+			options = { effect: options };
+		}
+		var hasOptions,
+			effectName = !options ?
+				method :
+				options === true || typeof options === "number" ?
+					defaultEffect :
+					options.effect || defaultEffect;
+		options = options || {};
+		if ( typeof options === "number" ) {
+			options = { duration: options };
+		}
+		hasOptions = !$.isEmptyObject( options );
+		options.complete = callback;
+		if ( options.delay ) {
+			element.delay( options.delay );
+		}
+		if ( hasOptions && $.effects && $.effects.effect[ effectName ] ) {
+			element[ method ]( options );
+		} else if ( effectName !== method && element[ effectName ] ) {
+			element[ effectName ]( options.duration, options.easing, callback );
+		} else {
+			element.queue(function( next ) {
+				$( this )[ method ]();
+				if ( callback ) {
+					callback.call( element[ 0 ] );
+				}
+				next();
+			});
+		}
+	};
+});
+
+})( jQuery );
diff --git a/static/js/longpolling.js b/static/js/longpolling.js
new file mode 100644
index 0000000000..4499f20df2
--- /dev/null
+++ b/static/js/longpolling.js
@@ -0,0 +1,46 @@
+connfails=0;
+
+longpollcallbacks = $.Callbacks();
+
+// Updates a div with a specified id, by polling an url,
+// which should return a new div, with the same id.
+function longpoll_div(url, divid, cont, fail) {
+	$.ajax({
+		'url': url,
+		'dataType': 'html',
+		'success': function(data, status, jqxhr) {
+			$('#' + divid).replaceWith(data);
+			longpollcallbacks.fire();
+			connfails=0;
+			cont();
+		},
+		'error': function(jqxhr, msg, e) {
+			connfails=connfails+1;
+			// It's normal to get 1 failure per longpolling
+			// element when navigating away from a page.
+			// So 12 allows up to 4 longpolling elements per
+			// page.
+			if (connfails > 12) {
+				fail();
+			}
+			else {
+				cont();
+			}
+		}
+	});
+}
+
+function longpoll_data(url, cont) {
+	$.ajax({
+		'url': url,
+		'dataType': 'text',
+		'success': function(data, status, jqxhr) {
+			connfails=0;
+			cont(1, data);
+		},
+		'error': function(jqxhr, msg, e) {
+			connfails=connfails+1;
+			cont(0);
+		}
+	});
+}
diff --git a/static/syncicon.gif b/static/syncicon.gif
new file mode 100644
index 0000000000000000000000000000000000000000..e192ca895cd00d6b752ec84619b787188f30ee41
GIT binary patch
literal 847
zcmZ?wbhEHb6krfw_`<;O|Nnmm28JI$eppyow6wIav9YPCsa?BvZN-WeVq#)tWo2n;
zX-}R!nK5I=v17+PJUqg}!hq_D2a5l>{aizWogD*Qjr0td8G$+#|4BI)r6!i7rYMwW
zmSiX-W+hhS<R_-+W#*;jGbsLK;p76U(gE24awG$5fPz9_O6I(!1|m6%S}h5y*3J+)
zHc`s7;RD;vj)v%778|C_)_{out&E+mi~81R>NI#p{aB=u^kJ9BqzM)+D@@g7D>_ZH
z6>Nk>K2^#dec$hd&5{fSg)a9?JsDb3M<1+M;h^GLd*HyqYe$(ldZsj_W{3#!96X@l
zAjsu&py5MupnEfu)0U^(0!(Kp*sL-QO$pql{X%Kq;`Av7E5z0<TG;QHEpT4hk%8ML
zz}$e{hLfeifG?8GLW`HPU0D&E<q1F^Du14!aZAKQi|a^$2&e9ncEk6^ja*jFrwzTg
zc(gP<Wb@FQp>lI$B?E`RzKdsAZ)9=nHHN!5+~JF4SY+VADb}iE(C2i8t1nx?>)BhL
zP<zvIW|kV2Y~C16ex7cumIgtBwLxJDlcC5_hZW7va%^kFk7ai^&0$n@dXiwz(72sx
z-vnjXCW|Vkz=($A-MNd(xP_D!D!e?jIH572jW^V7nPkx&Nxr28uQflX{cpf(4ajf6
z*jwSi<7y~y=%hq$ti<u15*|Gl+HPpD3v{uVFeyCO(2-c?rkLo#5D`3sqcPWX$yUZB
z7mqD$46Ak~Ch2hXsWucCizOdX-k|=2_l**}iJ5tTnpT8<gGNuU3RX+wp_Y08J;t%j
z!Gz(^relsuo)bAX%vzYhVVBp+>S>_TA<--6ZN7=uLx=rfr*28JR#UU9l!(BR!@3s}
qR&*pBVEQRw*vTQWVY)*<pR;)ehrS_88f%PZcaNGPgEc65f&l>bLIMx~

literal 0
HcmV?d00001

diff --git a/templates/README b/templates/README
new file mode 100644
index 0000000000..eb0ca037b6
--- /dev/null
+++ b/templates/README
@@ -0,0 +1,7 @@
+These are template files for the git-annex webapp. They use the
+Shakespearean template library, which is documented here:
+http://www.yesodweb.com/book/shakespearean-templates
+
+Note that for most of the templates, it will use files ending in
+.hamlet, .julius, and .cassius if they exist. So if you need to add CSS,
+or javascript, you can create the missing template files.
diff --git a/templates/actionbutton.hamlet b/templates/actionbutton.hamlet
new file mode 100644
index 0000000000..b51d1dee86
--- /dev/null
+++ b/templates/actionbutton.hamlet
@@ -0,0 +1,3 @@
+<a title="#{fromMaybe "" tooltip}" class="#{buttonclass}" href="@{route}" onclick="(function( $ ) { $.post('@{route}'); })( jQuery ); return false;">
+  <span class="glyphicon #{iconclass}"> #
+  \ #{fromMaybe "" label}
diff --git a/templates/bootstrap.hamlet b/templates/bootstrap.hamlet
new file mode 100644
index 0000000000..36c0cabccb
--- /dev/null
+++ b/templates/bootstrap.hamlet
@@ -0,0 +1,14 @@
+$doctype 5
+<html>
+  <head>
+    <title>
+     $maybe reldir <- relDir webapp
+       #{reldir} #{pageTitle pageinfo}
+     $nothing
+       #{pageTitle pageinfo}
+    <link rel="icon" href=@{StaticR favicon_ico} type="image/x-icon">
+    <meta name="viewport" content="width=device-width,initial-scale=1.0">
+    ^{pageHead pageinfo}
+  <body>
+    ^{pageBody pageinfo}
+    <div #modal></div>
diff --git a/templates/configurators/adddrive.hamlet b/templates/configurators/adddrive.hamlet
new file mode 100644
index 0000000000..90f768f1eb
--- /dev/null
+++ b/templates/configurators/adddrive.hamlet
@@ -0,0 +1,36 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Adding a removable drive
+    <p>
+      Clone this repository to a USB drive, memory stick, or other #
+      removable media. Whenever the removable drive is plugged in, its #
+      content will be synced with the content of this repository.
+    <p>
+    $if (null writabledrives)
+      <div .row>
+        <div .col-sm-6 .col-sm-offset-2 .alert .alert-danger .alert-block>
+          $if (null removabledrives)
+            <h4 .alert-heading>
+              No removable drives found
+            Please make sure you have a removable drive plugged in and mounted.
+          $else
+            <h4 .alert-heading>
+              No usable removable drives found
+            Seems you cannot write to any of the removable drives that are #
+            currently mounted. Try plugging in a removable drive that you can #
+            write to, or correcting the write permissions.
+          <p>
+            <a .btn .btn-primary href="@{AddDriveR}">
+              Rescan for removable drives
+    $else
+      <form method="post" enctype=#{enctype} .form-horizontal>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit>Use this drive</button> #
+              <a .btn .btn-default href="@{AddDriveR}">
+                Rescan for removable drives
+  
\ No newline at end of file
diff --git a/templates/configurators/adddrive/combine.hamlet b/templates/configurators/adddrive/combine.hamlet
new file mode 100644
index 0000000000..5ca6b3269e
--- /dev/null
+++ b/templates/configurators/adddrive/combine.hamlet
@@ -0,0 +1,22 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Combine repositories?
+    <p>
+      The removable drive at <tt>#{mountPoint drive}</tt> already
+      has files in its repository <tt>#{driveRepoPath drive}</tt>
+    <p>
+      Do you want to combine these files into your repository?
+    <p>
+      <a .btn .btn-default onclick="$('#setupmodal').modal('show');" href="@{FinishAddDriveR drive NoRepoKey}">
+        <span .glyphicon .glyphicon-resize-small>
+        \ Combine the repositories #
+      The combined repositories will sync and share their files.
+    <p>
+    <p>
+      <a .btn .btn-default href="@{AddDriveR}">
+        <span .glyphicon .glyphicon-resize-full>
+        \ Go back #
+      Use a different directory than <tt>#{driveRepoPath drive}</tt> to #
+      avoid combining the repositories.
+^{setupDriveModal}
diff --git a/templates/configurators/adddrive/encrypt.hamlet b/templates/configurators/adddrive/encrypt.hamlet
new file mode 100644
index 0000000000..44c636087c
--- /dev/null
+++ b/templates/configurators/adddrive/encrypt.hamlet
@@ -0,0 +1,29 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Encrypt this drive?
+    <p>
+      Encrypting the repository stored on the removable drive at #
+      <tt>#{mountPoint drive}</tt> #
+      will prevent the data stored in it from being exposed if the drive #
+      falls into the wrong hands. However, encryption #
+      will also prevent you from sharing the repository with friends, or #
+      easily accessing its contents on another computer.
+    <p>
+      <a .btn .btn-default onclick="$('#setupmodal').modal('show');" href="@{FinishAddDriveR drive NoRepoKey}">
+        <span .glyphicon .glyphicon-minus-sign>
+        \ Do not encrypt repository #
+      Anyone who has the drive can see the files stored on it.
+      $forall (keyid, name) <- secretkeys
+        <p>
+          <a .btn .btn-default onclick="$('#setupmodal').modal('show');" href="@{FinishAddDriveR drive (RepoKey keyid)}">
+            <span .glyphicon .glyphicon-ok-sign>
+            \ Encrypt repository #
+          to ^{gpgKeyDisplay keyid (Just name)}
+    <p>
+      <a .btn .btn-default onclick="$('#genkeymodal').modal('show');" href="@{GenKeyForDriveR drive}">
+        <span .glyphicon .glyphicon-plus-sign>
+        \ Encrypt repository #
+      with a new encryption key
+^{setupDriveModal}
+^{genKeyModal}
diff --git a/templates/configurators/adddrive/setupmodal.hamlet b/templates/configurators/adddrive/setupmodal.hamlet
new file mode 100644
index 0000000000..fb541d9054
--- /dev/null
+++ b/templates/configurators/adddrive/setupmodal.hamlet
@@ -0,0 +1,9 @@
+<div .modal .fade #setupmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Setting up repository on removable drive.
+      <div .modal-body>
+        <p>
+          This may take a few minutes; do not remove the drive.
diff --git a/templates/configurators/addglacier.hamlet b/templates/configurators/addglacier.hamlet
new file mode 100644
index 0000000000..7e3cf47df2
--- /dev/null
+++ b/templates/configurators/addglacier.hamlet
@@ -0,0 +1,38 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Adding an Amazon Glacier repository
+    <p>
+      <a href="http://aws.amazon.com/glacier/">Amazon Glacier</a> is an #
+      offline cloud storage provider. It takes several hours for requested #
+      files to be retrieved from Glacier, making it mostly suitable for #
+      backups and long-term data archival. #
+    <p>
+      <span .glyphicon .glyphicon-warning-sign>
+      \ By default, only files you place in #
+      "archive" directories will be archived in Amazon Glacier.
+    <p>
+      <span .glyphicon .glyphicon-warning-sign>
+      \ You will be charged by Amazon for data #
+      uploaded to Glacier, as well as data downloaded from Glacier, and a #
+      monthly fee for data storage. #
+      <a href="http://aws.amazon.com/glacier/pricing/">
+        Pricing details
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit onclick="$('#workingmodal').modal('show');">
+                Add Glacier repository
+<div .modal .fade #workingmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Making repository ...
+      <div .modal-body>
+        <p>
+          Setting up your Amazon Glacier repository. This could take a minute.
diff --git a/templates/configurators/addia.hamlet b/templates/configurators/addia.hamlet
new file mode 100644
index 0000000000..ec4087453a
--- /dev/null
+++ b/templates/configurators/addia.hamlet
@@ -0,0 +1,36 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Adding an Internet Archive item
+    <p>
+      <a href="http://archive.org/">The Internet Archive</a> allows anyone #
+      to publicly archive their information, for free. All you need to #
+      get started is to #
+      <a href="http://archive.org/account/login.createaccount.php">
+        Create an account
+    <p>
+      The Internet Archive stores "items". An item can be a single file, or #
+      a related group of files. You can make as many different items as you #
+      like.
+    <p>
+      By default, only files that you place in a special directory #
+      will be uploaded to your Internet Archive item. Any other files #
+      in your repository will remain private.
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit onclick="$('#workingmodal').modal('show');">
+                Add Internet Archive item
+<div .modal .fade #workingmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Making item ...
+      <div .modal-body>
+        <p>
+          Setting up your Internet Archive item. This could take a minute.
diff --git a/templates/configurators/addrepository.hamlet b/templates/configurators/addrepository.hamlet
new file mode 100644
index 0000000000..f3609d3f5e
--- /dev/null
+++ b/templates/configurators/addrepository.hamlet
@@ -0,0 +1,19 @@
+<div .col-sm-9>
+  ^{repolist}
+  <div .row>
+    <div .col-sm-6>
+      <h2>
+        Add more repositories
+
+      ^{makeMiscRepositories}
+
+    <div .col-sm-6>
+      <h2>
+        Store your data in the cloud
+
+      ^{makeCloudRepositories}
+
+      <h2>
+        Archive your data
+
+      ^{makeArchiveRepositories}
diff --git a/templates/configurators/addrepository/archive.hamlet b/templates/configurators/addrepository/archive.hamlet
new file mode 100644
index 0000000000..7a266ed8bf
--- /dev/null
+++ b/templates/configurators/addrepository/archive.hamlet
@@ -0,0 +1,13 @@
+<h3>
+  <a href="@{AddGlacierR}">
+    <span .glyphicon .glyphicon-plus-sign>
+    \ Amazon Glacier
+<p>
+  Low cost offline data archival.
+
+<h3>
+  <a href="@{AddIAR}">
+    <span .glyphicon .glyphicon-plus-sign>
+    \ Internet Archive
+<p>
+  Free archival of public data.
diff --git a/templates/configurators/addrepository/cloud.hamlet b/templates/configurators/addrepository/cloud.hamlet
new file mode 100644
index 0000000000..59d37b771e
--- /dev/null
+++ b/templates/configurators/addrepository/cloud.hamlet
@@ -0,0 +1,17 @@
+<h3>
+  <a href="@{AddRsyncNetR}">
+    <span .glyphicon .glyphicon-plus-sign>
+    \ Rsync.net
+<p>
+  Works very well with git-annex for data storage.
+  <br>
+  Offers a discounted rate for git-annex users.
+
+<h3>
+  <a href="@{AddS3R}">
+    <span .glyphicon .glyphicon-plus-sign>
+    \ Amazon S3
+<p>
+  Good choice for professional quality storage.
+
+^{makeSshRepository}
diff --git a/templates/configurators/addrepository/connection.hamlet b/templates/configurators/addrepository/connection.hamlet
new file mode 100644
index 0000000000..7c528f7ccf
--- /dev/null
+++ b/templates/configurators/addrepository/connection.hamlet
@@ -0,0 +1,3 @@
+^{makeSshRepository}
+
+^{makeWormholePairing}
diff --git a/templates/configurators/addrepository/misc.hamlet b/templates/configurators/addrepository/misc.hamlet
new file mode 100644
index 0000000000..4a4c2aaea2
--- /dev/null
+++ b/templates/configurators/addrepository/misc.hamlet
@@ -0,0 +1,26 @@
+<h3>
+  <a href="@{AddDriveR}">
+    <span .glyphicon .glyphicon-plus-sign>
+    \ Removable drive
+<p>
+  Add a USB drive, memory stick, or other removable media. #
+  For offline archiving, backups, or to #
+  <a href="http://en.wikipedia.org/wiki/Sneakernet">SneakerNet</a> #
+  between computers. 
+
+^{makeWormholePairing}
+
+<h3>
+  <a href="@{StartLocalPairR}">
+    <span .glyphicon .glyphicon-plus-sign>
+    \ Local computer
+<p>
+  Pair with a computer to keep files in sync quickly, #
+  over your local network.
+
+<h3>
+  <a href="@{NewRepositoryR}">
+    <span .glyphicon .glyphicon-plus-sign>
+    \ Add another repository
+<p>
+  Make another repository on your computer.
diff --git a/templates/configurators/addrepository/ssh.hamlet b/templates/configurators/addrepository/ssh.hamlet
new file mode 100644
index 0000000000..b5ed1aa4cb
--- /dev/null
+++ b/templates/configurators/addrepository/ssh.hamlet
@@ -0,0 +1,7 @@
+<h3>
+  <a href="@{AddSshR}">
+    <span .glyphicon .glyphicon-plus-sign>
+    \ Remote server
+<p>
+  Set up a repository on a remote server using #
+  <tt>ssh</tt>.
diff --git a/templates/configurators/addrepository/wormholepairing.hamlet b/templates/configurators/addrepository/wormholepairing.hamlet
new file mode 100644
index 0000000000..d5cce64a8b
--- /dev/null
+++ b/templates/configurators/addrepository/wormholepairing.hamlet
@@ -0,0 +1,13 @@
+<h3>
+  <a href="@{StartWormholePairSelfR}">
+    <span .glyphicon .glyphicon-plus-sign>
+    \ Share with your other devices
+<p>
+  Keep files in sync between your devices running git-annex.
+
+<h3>
+  <a href="@{StartWormholePairFriendR}">
+    <span .glyphicon .glyphicon-plus-sign>
+    \ Share with a friend
+<p>
+  Combine your repository with a friend's repository, and share your files.
diff --git a/templates/configurators/adds3.hamlet b/templates/configurators/adds3.hamlet
new file mode 100644
index 0000000000..4b664f5b5e
--- /dev/null
+++ b/templates/configurators/adds3.hamlet
@@ -0,0 +1,33 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Adding an Amazon S3 repository
+    <p>
+      <a href="http://aws.amazon.com/s3/">Amazon S3</a> is a cloud storage #
+      provider. If you need a professional level of storage for your data, #
+      this is a good choice.
+    <p>
+      <span .glyphicon .glyphicon-warning-sign>
+      \ You will be charged by Amazon for data #
+      uploaded to S3, as well as data downloaded from S3, and a monthly fee #
+      for data storage. #
+      <a href="http://aws.amazon.com/s3/pricing/">
+        Pricing details, including one year Free Usage Tier promotion
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit onclick="$('#workingmodal').modal('show');">
+                Add S3 repository
+<div .modal .fade #workingmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Making repository ...
+      <div .modal-body>
+        <p>
+          Setting up your Amazon S3 repository. This could take a minute.
diff --git a/templates/configurators/delete/currentrepository.hamlet b/templates/configurators/delete/currentrepository.hamlet
new file mode 100644
index 0000000000..b144f5399b
--- /dev/null
+++ b/templates/configurators/delete/currentrepository.hamlet
@@ -0,0 +1,36 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Deleting #{reldir}
+    <p>
+      Deleting this repository will remove <tt>#{reldir}</tt> and all its #
+      ^{actionButton FileBrowserR (Just "files") (Just "Click to open a file browser") "" "glyphicon-folder-open"}.
+    $if havegitremotes
+      $if havedataremotes
+        <div .alert>
+          Since this repository is currently configured to sync to other #
+          repositories, you may be able to remove this repository without #
+          losing any data, if all files have been synced to them. #
+          No guarantees -- It's up to you to make sure before you continue.
+      $else
+        <div .alert .alert-danger>
+          This repository is not uploading its files to other repositories,
+          so you will lose data if you delete it!
+    $else
+      <div .alert .alert-danger>
+        This repository is not syncing to other git repositories, #
+        so you will lose data if you delete it!
+    <p>
+      If you choose to delete this repository, and potentially lose #
+      data, enter "#{magicphrase}" into the box.
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .col-md-2>
+            <button .btn .btn-danger type=submit>
+              <span .glyphicon .glyphicon-warning-sign>
+              \ Delete this repository #
+            <a .btn .btn-default href="@{DashboardR}">
+              Cancel
diff --git a/templates/configurators/delete/finished.hamlet b/templates/configurators/delete/finished.hamlet
new file mode 100644
index 0000000000..377f82e7c4
--- /dev/null
+++ b/templates/configurators/delete/finished.hamlet
@@ -0,0 +1,15 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Repository deleted
+    <p>
+      As much data as possible has been removed from the repository
+      "#{reponame}", and it has been removed from the list of repositories.
+    <p>
+      $if gitrepo
+       <div .alert>
+         Since "#{reponame}" is a git repository, it still contains
+         some data. To completely remove it, you should go delete that git
+         repository.
+      $else
+        Now you can safely go delete the underlying storage of the repository.
diff --git a/templates/configurators/delete/start.hamlet b/templates/configurators/delete/start.hamlet
new file mode 100644
index 0000000000..4f0f9aba0e
--- /dev/null
+++ b/templates/configurators/delete/start.hamlet
@@ -0,0 +1,13 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Delete repository #
+      <small>
+        #{reponame}
+    <p>
+      Before this repository can be deleted, all data must be moved #
+      off it, to other repositories.
+    <p>
+     <a .btn .btn-primary href="@{StartDeleteRepositoryR uuid}">
+       <span .glyphicon .glyphicon-minus>
+      \ Start deletion process
diff --git a/templates/configurators/edit/nonannexremote.hamlet b/templates/configurators/edit/nonannexremote.hamlet
new file mode 100644
index 0000000000..acfa10ec66
--- /dev/null
+++ b/templates/configurators/edit/nonannexremote.hamlet
@@ -0,0 +1,19 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Just a git repository
+    <p>
+      This repository is not currently set up as a git annex; #
+      only git metadata is synced with this repository.
+    $if sshrepo
+      <p>
+        If this repository's ssh server has git-annex installed, you can #
+        upgrade this repository to a full git annex, which will store the
+        contents of your files, not only their metadata.
+      <p>
+        <a .btn .btn-default href="@{UpgradeRepositoryR r}">
+          Upgrade Repository
+    <h2>
+      Repository information
+    <p>
+      ^{repoInfo}
diff --git a/templates/configurators/edit/repository.hamlet b/templates/configurators/edit/repository.hamlet
new file mode 100644
index 0000000000..4291534525
--- /dev/null
+++ b/templates/configurators/edit/repository.hamlet
@@ -0,0 +1,40 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      $if new
+        Setup complete
+      $else
+        Editing repository
+    $if new
+      <p>
+        This repository is set up and ready to go!
+      <p>
+        Now you can do a little more configuring of it, if you like. #
+        Perhaps enter a better name than the automatically generated one.
+      $if istransfer
+        <div .alert .alert-info>
+          This repository is currently in the transfer group. That's the #
+          right choice if you'll use it to shuttle data back and forth #
+          between other repositories. Otherwise, pick one of the other groups.
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit>
+                Save Changes
+              \ 
+              <a .btn .btn-default href="@{DashboardR}">
+                Cancel #
+    $if new
+      <p>
+        In a hurry? Feel free to skip this step! You can always come back #
+        and configure this repository later.
+    <h3>
+      Repository information
+    <p>
+      ^{repoInfo}
+    <p>
+      ^{repoEncryption}
diff --git a/templates/configurators/edit/webrepository.hamlet b/templates/configurators/edit/webrepository.hamlet
new file mode 100644
index 0000000000..f7d1243703
--- /dev/null
+++ b/templates/configurators/edit/webrepository.hamlet
@@ -0,0 +1,8 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      The world wide web
+    <p>
+      git-annex can download files from the web.
+    <p>
+      This is not a normal repository, and cannot be configured.
diff --git a/templates/configurators/enableaws.hamlet b/templates/configurators/enableaws.hamlet
new file mode 100644
index 0000000000..8e1b9943db
--- /dev/null
+++ b/templates/configurators/enableaws.hamlet
@@ -0,0 +1,34 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Enabling #{description}
+    <p>
+      To use this Amazon repository, you need an Access Key ID, and a #
+      Secret Access Key. These access keys will be stored in a file that #
+      only you can access.
+    <p>
+      If this repository uses your Amazon account, you can #
+      <a href="https://portal.aws.amazon.com/gp/aws/securityCredentials#id_block">
+        look up your access keys. #
+      If this repository uses someone else's Amazon account, they #
+      can generate access keys for you, using their #
+      <a href="https://console.aws.amazon.com/iam/home">
+        IAM Management Console.
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit onclick="$('#workingmodal').modal('show');">
+                Enable Amazon repository
+<div .modal .fade #workingmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Enabling repository ...
+      <div .modal-body>
+        <p>
+          Enabling this Amazon repository. This could take a minute.
diff --git a/templates/configurators/enabledirectory.hamlet b/templates/configurators/enabledirectory.hamlet
new file mode 100644
index 0000000000..dfae0dddc4
--- /dev/null
+++ b/templates/configurators/enabledirectory.hamlet
@@ -0,0 +1,11 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Enabling #{description}
+    <p>
+      Where is this repository located?
+    <p>
+      <a .btn .btn-default href="@{AddDriveR}">
+        On a removable drive
+      <a .btn href="@{DashboardR}">
+        Cancel
diff --git a/templates/configurators/enableia.hamlet b/templates/configurators/enableia.hamlet
new file mode 100644
index 0000000000..0d9169fd84
--- /dev/null
+++ b/templates/configurators/enableia.hamlet
@@ -0,0 +1,26 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Enabling #{description}
+    <p>
+      To use this Internet Archive repository, you need an Access Key ID, and a #
+      Secret Access Key. These access keys will be stored in a file that #
+      only you can access.
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit onclick="$('#workingmodal').modal('show');">
+                Enable Internet Archive repository
+<div .modal .fade #workingmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Enabling repository ...
+      <div .modal-body>
+        <p>
+          Enabling this Internet Archive repository. This could take a minute.
diff --git a/templates/configurators/enablewebdav.hamlet b/templates/configurators/enablewebdav.hamlet
new file mode 100644
index 0000000000..1573b38544
--- /dev/null
+++ b/templates/configurators/enablewebdav.hamlet
@@ -0,0 +1,26 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Enabling #{description}
+    <p>
+      This is a WebDAV repository located at #
+      <a href="#{url}">
+        #{url}
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit onclick="$('#workingmodal').modal('show');">
+                Enable repository
+<div .modal .fade #workingmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Enabling repository ...
+      <div .modal-body>
+        <p>
+          Enabling this WebDAV repository. This could take a minute.
diff --git a/templates/configurators/fsck.cassius b/templates/configurators/fsck.cassius
new file mode 100644
index 0000000000..80f405baf0
--- /dev/null
+++ b/templates/configurators/fsck.cassius
@@ -0,0 +1,4 @@
+.form-inline input[type=number]
+  width: 5em
+select
+  width: 10em
diff --git a/templates/configurators/fsck.hamlet b/templates/configurators/fsck.hamlet
new file mode 100644
index 0000000000..7e0a57cadd
--- /dev/null
+++ b/templates/configurators/fsck.hamlet
@@ -0,0 +1,32 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Consistency checks
+    <p>
+      Checking the contents of a repository periodically will ensure that #
+      your data is in good shape. Any problems that are detected will #
+      be automatically fixed.
+    <p>
+      Running the consistency check involves reading all the files in the #
+      repository, which can take a long time if it's large. Running just a #
+      little at a time will eventually check the whole repository.
+    $if (not (null scheduledchecks))
+      <p>
+        Currently scheduled checks:
+        $forall c <- scheduledchecks
+          ^{showFsckForm False c}
+          <div style="margin-left: 5em">
+            ^{showFsckStatus c}
+    <p>
+      $if null (recommendedchecks)
+        Add a check:
+        ^{showFsckForm True (defaultFsck Nothing)}
+      $else
+        <span .glyphicon .glyphicon-warning-sign>
+        \ Some repositories are not yet checked. #
+        Please consider adding these checks:
+        $forall c <- recommendedchecks
+          ^{showFsckForm True c}
+    <h3>
+      Configuration
+    ^{showFsckPreferencesForm}
diff --git a/templates/configurators/fsck/form.hamlet b/templates/configurators/fsck/form.hamlet
new file mode 100644
index 0000000000..cca9a915ce
--- /dev/null
+++ b/templates/configurators/fsck/form.hamlet
@@ -0,0 +1,2 @@
+<form method="post" .form-inline enctype=#{enctype} action="@{action}">
+  ^{form}
diff --git a/templates/configurators/fsck/formcontent.hamlet b/templates/configurators/fsck/formcontent.hamlet
new file mode 100644
index 0000000000..f1506946ec
--- /dev/null
+++ b/templates/configurators/fsck/formcontent.hamlet
@@ -0,0 +1,21 @@
+#{msg}
+<p>
+  <div .form-group>
+    Check ^{fvInput reposView} for #
+  <div .form-group>
+    \ 
+    ^{fvInput durationView} minutes #
+  <div .form-group>
+    \ 
+    ^{fvInput recurrenceView} #
+  \ 
+  starting at ^{fvInput timeView} #
+  $if new
+    <button type=submit .btn .btn-primary>
+      Add
+  $else
+    <button type=submit .btn .btn-default>
+      Save
+    \ 
+    <a .btn .btn-default href="@{RemoveActivityR u activity}">
+      Remove
diff --git a/templates/configurators/fsck/preferencesform.hamlet b/templates/configurators/fsck/preferencesform.hamlet
new file mode 100644
index 0000000000..e35897cced
--- /dev/null
+++ b/templates/configurators/fsck/preferencesform.hamlet
@@ -0,0 +1,7 @@
+<div .well>
+  <form method="post" .form-horizontal action=@{ConfigFsckPreferencesR} enctype=#{enctype}>
+    ^{form}
+    <div .form-group>
+      <div .col-sm-10 .col-sm-offset-2>
+        <button .btn .btn-primary type=submit>
+          Save
diff --git a/templates/configurators/fsck/status.hamlet b/templates/configurators/fsck/status.hamlet
new file mode 100644
index 0000000000..b27760ac65
--- /dev/null
+++ b/templates/configurators/fsck/status.hamlet
@@ -0,0 +1,5 @@
+<i>
+  $maybe t <- lastrun
+    (last run: #{show t})
+  $nothing
+    (not yet run)
diff --git a/templates/configurators/genkeymodal.hamlet b/templates/configurators/genkeymodal.hamlet
new file mode 100644
index 0000000000..b8f47cb513
--- /dev/null
+++ b/templates/configurators/genkeymodal.hamlet
@@ -0,0 +1,15 @@
+<div .modal .fade #genkeymodal>
+  <div .modal-header>
+    <div .modal-dialog>
+      <div .modal-content>
+        <div .modal-header>
+          <h3>
+            <img src="@{StaticR activityicon_gif}" alt=""> #
+            Generating a GnuPg key.
+        <div .modal-body>
+        <p>
+          Generating a GnuPg key can take a long time. To speed up the process, #
+          it actually helps to use your computer for other things, which helps #
+          generate random numbers that keep the GnuPg key secure.
+        <p>
+          So if this is taking too long, go play a game or something!
diff --git a/templates/configurators/main.hamlet b/templates/configurators/main.hamlet
new file mode 100644
index 0000000000..339b92713b
--- /dev/null
+++ b/templates/configurators/main.hamlet
@@ -0,0 +1,29 @@
+<div .col-sm-9>
+  <div .row>
+    <div .col-sm-4>
+      <h3>
+        <a href="@{AddRepositoryR}">
+          Repositories
+      <p>
+        Configure the repositories that git-annex syncs with.
+    <div .col-sm-4>
+      <h3>
+        <a href="@{PreferencesR}">
+          Preferences
+      <p>
+        Tune the behavior of git-annex, including how many copies #
+        to retain of each file, and how much disk space it can use.
+  <div .row>
+    <div .col-sm-4>
+      <h3>
+        <a href="@{ConfigFsckR}">
+          Consistency checks
+      <p>
+        Set up periodic checks of your data to detect and recover from #
+        disk problems.
+    <div .col-sm-4>
+      <h3>
+        <a href="@{ConfigUnusedR}">
+          Unused files
+      <p>
+        Configure what to do with old and deleted files.
diff --git a/templates/configurators/needconnection.hamlet b/templates/configurators/needconnection.hamlet
new file mode 100644
index 0000000000..dc57094f07
--- /dev/null
+++ b/templates/configurators/needconnection.hamlet
@@ -0,0 +1,14 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      <span .glyphicon .glyphicon-signal>
+      \ Connection needed
+      <p>
+        In order to quickly sync with other repositories, #
+        a direct connection is needed to another git-annex. #
+      <p>
+        You don't currently seem to have such a connection configured -- #
+        or if you do, it's not currently connected!
+    <h2>
+      Add a connection
+    ^{makeConnectionRepositories}
diff --git a/templates/configurators/needgcrypt.hamlet b/templates/configurators/needgcrypt.hamlet
new file mode 100644
index 0000000000..d6dab11ab3
--- /dev/null
+++ b/templates/configurators/needgcrypt.hamlet
@@ -0,0 +1,11 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Need git-remote-gcrypt
+    <p>
+      To encrypt git repositories, you need to install #
+      <a href="https://spwhitton.name/tech/code/git-remote-gcrypt/">
+        git-remote-gcrypt
+    <p>
+      <a .btn .btn-primary .btn-lg href="">
+        Retry
diff --git a/templates/configurators/needglaciercli.hamlet b/templates/configurators/needglaciercli.hamlet
new file mode 100644
index 0000000000..da9a8e00b1
--- /dev/null
+++ b/templates/configurators/needglaciercli.hamlet
@@ -0,0 +1,11 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Need glacier-cli
+    <p>
+      To use Amazon Glacier, you need to install #
+      <a href="https://github.com/basak/glacier-cli">
+        glacier-cli
+    <p>
+      <a .btn .btn-primary .btn-lg href="">
+        Retry
diff --git a/templates/configurators/needmagicwormhole.hamlet b/templates/configurators/needmagicwormhole.hamlet
new file mode 100644
index 0000000000..c10d3a1fe8
--- /dev/null
+++ b/templates/configurators/needmagicwormhole.hamlet
@@ -0,0 +1,11 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Need Magic Wormhole
+    <p>
+      You need to install #
+      <a href="https://github.com/warner/magic-wormhole">
+        Magic Wormhole
+    <p>
+      <a .btn .btn-primary .btn-lg href="">
+        Retry
diff --git a/templates/configurators/needtor.hamlet b/templates/configurators/needtor.hamlet
new file mode 100644
index 0000000000..808cbe9251
--- /dev/null
+++ b/templates/configurators/needtor.hamlet
@@ -0,0 +1,11 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Need Tor
+    <p>
+      You need to install #
+      <a href="https://torproject.org/">
+        Tor
+    <p>
+      <a .btn .btn-primary .btn-lg href="">
+        Retry
diff --git a/templates/configurators/newrepository.hamlet b/templates/configurators/newrepository.hamlet
new file mode 100644
index 0000000000..9e7b625640
--- /dev/null
+++ b/templates/configurators/newrepository.hamlet
@@ -0,0 +1,14 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Add another local repository
+    <p>
+      <span .glyphicon .glyphicon-asterisk>
+      \ Do you want to back your repository up to a #
+      removable drive?
+      <a .btn .btn-primary href="@{AddDriveR}">
+        Make a repository on a Removable Drive
+    <p>
+      Repository location:
+      <form method="post" .form-inline enctype=#{enctype}>
+        ^{form}
diff --git a/templates/configurators/newrepository/combine.hamlet b/templates/configurators/newrepository/combine.hamlet
new file mode 100644
index 0000000000..484180adc6
--- /dev/null
+++ b/templates/configurators/newrepository/combine.hamlet
@@ -0,0 +1,20 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Combine repositories?
+    <p>
+      The repository at #{newrepo} is set up.
+      <br>
+      Do you want to combine it with your existing repository at #{mainrepo}?
+    <p>
+      <a .btn .btn-default href="@{CombineRepositoryR newrepopath newrepouuid}">
+        <span .glyphicon .glyphicon-resize-small>
+        \ Combine the repositories #
+      The combined repositories will sync and share their files.
+    <p>
+      -or-
+    <p>
+      <a .btn .btn-default href="@{SwitchToRepositoryR newrepopath}">
+        <span .glyphicon .glyphicon-resize-full>
+        \ Keep the repositories separate #
+      Files placed in one will not be synced to the other.
diff --git a/templates/configurators/newrepository/first.hamlet b/templates/configurators/newrepository/first.hamlet
new file mode 100644
index 0000000000..2e2997d5d4
--- /dev/null
+++ b/templates/configurators/newrepository/first.hamlet
@@ -0,0 +1,21 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Welcome to git-annex!
+    <p>
+      To get started, let's create a git-annex repository.
+    $if androidspecial
+      <p>
+        Do you only want to share photos and videos you take?
+      <p>
+        <a .btn .btn-primary .btn-lg href="@{AndroidCameraRepositoryR}">
+          <span .glyphicon .glyphicon-camera>
+          \ Make Camera Repository
+    <p>
+      $if androidspecial
+        Want to share more files? #
+      Files in this repository will be kept in sync with your #
+      repositories on other devices.
+    <p>
+      <form method="post" .form-inline enctype=#{enctype}>
+        ^{form}
diff --git a/templates/configurators/newrepository/form.hamlet b/templates/configurators/newrepository/form.hamlet
new file mode 100644
index 0000000000..db0be87c46
--- /dev/null
+++ b/templates/configurators/newrepository/form.hamlet
@@ -0,0 +1,13 @@
+#{msg}
+<p>
+  <div .form-group>
+    <div .input-group>
+      <span .input-group-addon>
+        <span .glyphicon .glyphicon-folder-open>
+      ^{fvInput pathView}
+      <span .input-group-btn>
+        <button type=submit .btn .btn-primary>
+          Make Repository
+$if err
+  <div .alert .alert-danger>
+    #{errmsg}
diff --git a/templates/configurators/pairing/disabled.hamlet b/templates/configurators/pairing/disabled.hamlet
new file mode 100644
index 0000000000..05f59143d6
--- /dev/null
+++ b/templates/configurators/pairing/disabled.hamlet
@@ -0,0 +1,6 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      not supported
+    <p>
+      This build of git-annex does not support #{pairingtype} pairing. Sorry!
diff --git a/templates/configurators/pairing/local/inprogress.hamlet b/templates/configurators/pairing/local/inprogress.hamlet
new file mode 100644
index 0000000000..38e353a40f
--- /dev/null
+++ b/templates/configurators/pairing/local/inprogress.hamlet
@@ -0,0 +1,19 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Pairing in progress ..
+    $if T.null secret
+      <p>
+        You do not need to leave this page open; pairing will finish #
+        automatically.
+    $else
+      <p>
+        Now you should either go tell the owner of the computer you want to pair #
+        with the secret phrase you selected ("#{secret}"), or go enter it into #
+        the computer you want to pair with.
+      <p>
+        You do not need to leave this page open; pairing will finish automatically #
+        as soon as the secret phrase is entered into the other computer.
+      <p>
+        If you're not seeing a pair request on the other computer, try moving #
+        it to the same switch or wireless network as this one.
diff --git a/templates/configurators/pairing/local/prompt.hamlet b/templates/configurators/pairing/local/prompt.hamlet
new file mode 100644
index 0000000000..b75e2e2cd0
--- /dev/null
+++ b/templates/configurators/pairing/local/prompt.hamlet
@@ -0,0 +1,53 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Pairing with a local computer
+    <p>
+      $if start
+        Pair with a computer on your local network (or VPN), and the #
+        two git annex repositories will be combined into one, with changes #
+        kept in sync between them.
+      $else
+        Pairing with #{username}@#{hostname} will combine your two git annex #
+        repositories into one, allowing you to share files.
+    <p>
+      $if start
+        For security, enter a secret phrase. To verify that you're pairing #
+        with the right computer, its git-annex webapp will then prompt for the #
+        same secret phrase. That's all this secret phrase will be used for.
+      $else
+        $if sameusername
+          For security, you need to enter the same secret phrase that was #
+          entered on #{hostname} when the pairing was started.
+        $else
+          For security, a secret phrase has been selected, which you need #
+          to enter here to finish the pairing. If you don't know the #
+          phrase, go ask #{username} ...
+    $if badphrase
+      <div .alert .alert-danger>
+        <span .glyphicon .glyphicon-warning-sign>
+        \ #{problem}
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit>
+                $if start
+                  Start pairing
+                $else
+                  Finish pairing
+      <div .alert .alert-info>
+        $if start
+          <p>
+            A good secret phrase is reasonably long. You'll only #
+            type it a few times. Only letters and numbers matter; #
+            punctuation and white space is ignored.
+          <p>
+            A quotation is one good choice, something like: #
+            "#{sampleQuote}"
+        $else
+          Only letters and numbers matter; punctuation and spaces are #
+          ignored.
diff --git a/templates/configurators/pairing/wormhole/prompt.hamlet b/templates/configurators/pairing/wormhole/prompt.hamlet
new file mode 100644
index 0000000000..2708a7c943
--- /dev/null
+++ b/templates/configurators/pairing/wormhole/prompt.hamlet
@@ -0,0 +1,59 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      $case pairingwith
+        $of PairingWithSelf
+          Pairing your devices
+        $of PairingWithFriend
+          Pairing with a friend
+    <p>
+      Pairing will connect two git-annex repositories using #
+      <a href="https://torproject.org/">Tor</a>, #
+      allowing files to be shared between them.
+    <p>
+      $case pairingwith
+        $of PairingWithSelf
+          This device's #
+        $of PairingWithFriend
+          Your repository's #
+      pairing code is: <b><big>#{Wormhole.fromCode ourcode}</big></b>
+    <p>
+      $case pairingwith
+        $of PairingWithSelf
+          Enter that code into the device you want to pair with. #
+        $of PairingWithFriend
+          Tell that code to your friend. #
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit>
+                Finish pairing
+  <div .alert .alert-info>
+    <h3 .alert-heading>
+      ^{htmlIcon InfoIcon} Keep pairing codes safe
+    $case pairingwith
+      $of PairingWithSelf
+        <p>
+          Pairing codes can only be used a single time, but if someone #
+          saw the pairing codes before you use them, they could #
+          pair with your devices. So be careful with the pairing codes!
+      $of PairingWithFriend
+        <p>
+          Pairing codes can only be used a single time, but if someone #
+          overhears you exchanging them with your friend, they could #
+          pair with your repositories. #
+        <p>
+          Here are some suggestions for how to exchange the pairing #
+          code with your friend, with the safest ways first:
+          <ul>
+            <li>
+              In person.
+            <li>
+              In an encrypted message #
+              (gpg signed email, Off The Record (OTR) conversation, etc).
+            <li>
+              By a voice phone call.
diff --git a/templates/configurators/pairing/wormhole/start.hamlet b/templates/configurators/pairing/wormhole/start.hamlet
new file mode 100644
index 0000000000..2284cd0068
--- /dev/null
+++ b/templates/configurators/pairing/wormhole/start.hamlet
@@ -0,0 +1,35 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      $case pairingwith
+        $of PairingWithSelf
+          Preparing for pairing your devices
+        $of PairingWithFriend
+          Preparing for sharing with a friend
+    <p>
+      This will connect two git-annex repositories using #
+      <a href="https://torproject.org/">Tor</a>, #
+      allowing files to be shared between them.
+    <p>
+      First, a Tor hidden service needs to be set up on this computer.
+    <p>
+      <a .btn .btn-primary onclick="$('#setupmodal').modal('show');" href="@{PrepareWormholePairR pairingwith}">
+        <span .glyphicon .glyphicon-resize-small>
+        \ Let's get started #
+<div .modal .fade #setupmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Enabling Tor hidden service ...
+      <div .modal-body>
+        $case describePasswordPrompt' sucommand
+          $of Nothing
+            #
+          $of (Just promptdesc)
+            <p>
+              #{promptdesc} in order to enable the Tor hidden service.
+        <p>
+          This could take several minutes to finish. If it #
+          is taking too long, check that you are connected to the #
+          network, and that Tor is working.
diff --git a/templates/configurators/preferences.hamlet b/templates/configurators/preferences.hamlet
new file mode 100644
index 0000000000..ea056c09e7
--- /dev/null
+++ b/templates/configurators/preferences.hamlet
@@ -0,0 +1,16 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Preferences
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit>
+                Save Preferences
+              \ 
+              <a .btn .btn-default href="@{ConfigurationR}">
+                Cancel
diff --git a/templates/configurators/rsync.net/add.hamlet b/templates/configurators/rsync.net/add.hamlet
new file mode 100644
index 0000000000..6f46a79c5a
--- /dev/null
+++ b/templates/configurators/rsync.net/add.hamlet
@@ -0,0 +1,43 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Adding a Rsync.net repository
+    <p>
+      <a href="http://rsync.net/">
+        Rsync.net #
+      is a well-respected cloud storage provider. Its rsync repositories are #
+      supported very well by git-annex. #
+  
+    <p>
+      They have committed to support git-annex and offer a special
+      discounted rate for git-annex users.
+  
+      <a href="http://www.rsync.net/products/git-annex-pricing.html">
+        pricing details
+    <p>
+      $case status
+        $of UnusableServer msg
+          <div .alert .alert-danger>
+            <span .glyphicon .glyphicon-warning-sign>
+            \ #{msg}
+        $of _
+          <div>
+            Your data will be encrypted before it is sent to Rsync.net.
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit onclick="$('#setupmodal').modal('show');">
+                Use this rsync.net repository
+  <div .modal .fade #setupmodal>
+    <div .modal-dialog>
+      <div .modal-content>
+        <div .modal-header>
+          <h3>
+            Checking access to rsync.net ...
+        <div .modal-body>
+          <p>
+            This could take a minute.
diff --git a/templates/configurators/rsync.net/encrypt.hamlet b/templates/configurators/rsync.net/encrypt.hamlet
new file mode 100644
index 0000000000..7262edd546
--- /dev/null
+++ b/templates/configurators/rsync.net/encrypt.hamlet
@@ -0,0 +1,49 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Ready to use rsync.net
+    <p>
+      All data will be encrypted before it is sent to rsync.net. #
+      There are two options for how to encrypt your data.
+    <h3>
+      Simple shared encryption
+    <p>
+      This allows everyone who has a clone of this repository to decrypt the #
+      files stored on rsync.net. That makes it good for sharing. #
+      And it's easy to set up and use.
+    <p>
+      <a .btn .btn-default href="@{MakeRsyncNetSharedR sshdata}" onclick="$('#setupmodal').modal('show');">
+        <span .glyphicon .glyphicon-lock>
+        \ Use shared encryption
+    <p style="text-align: center">
+      -or-
+    <h3>
+      Encrypt with GnuPG key
+    <p>
+      This stores an encrypted clone of your repository on rsync.net, #
+      unlike shared encryption which only stores file contents on rsync.net. #
+      So it's good for backups. But the encryption will prevent you from #
+      sharing the rsync.net repository with friends, or easily accessing #
+      its contents on another computer.
+    <p>
+      $forall (keyid, name) <- secretkeys
+        <p>
+          <a .btn .btn-default href="@{MakeRsyncNetGCryptR sshdata (RepoKey keyid)}" onclick="$('#setupmodal').modal('show');">
+            <span .glyphicon .glyphicon-lock>
+            \ Encrypt repository #
+          to ^{gpgKeyDisplay keyid (Just name)}
+    <p>
+      <a .btn .btn-default href="@{MakeRsyncNetGCryptR sshdata NoRepoKey}" onclick="$('#genkeymodal').modal('show');">
+        <span .glyphicon .glyphicon-plus-sign>
+        \ Encrypt repository #
+      with a new encryption key
+^{genKeyModal}
+<div .modal .fade #setupmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Making repository ...
+      <div .modal-body>
+        <p>
+          Setting up your rsync.net repository. This could take a minute.
diff --git a/templates/configurators/ssh/add.hamlet b/templates/configurators/ssh/add.hamlet
new file mode 100644
index 0000000000..9048de6926
--- /dev/null
+++ b/templates/configurators/ssh/add.hamlet
@@ -0,0 +1,26 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Adding a remote server using ssh
+    <p>
+      You can use nearly any server that has ssh and rsync. For example, you #
+      could use a <a href="http://linode.com/">Linode</a> or #
+      <a href="http://vix.su/personalcolo/">another VPS</a>, or #
+      an account on a friend's server.
+    <p>
+      $case status
+        $of UnusableServer msg
+          <div .alert .alert-danger>
+            <span .glyphicon .glyphicon-warning-sign>
+            \ #{msg}
+        $of _
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit onclick="$('#testmodal').modal('show');">
+                Check this server
+^{sshTestModal}
diff --git a/templates/configurators/ssh/combine.hamlet b/templates/configurators/ssh/combine.hamlet
new file mode 100644
index 0000000000..ea0aa7a9d4
--- /dev/null
+++ b/templates/configurators/ssh/combine.hamlet
@@ -0,0 +1,22 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Combine repositories?
+    <p>
+      A repository already exists on #{sshHostName sshdata} in the #
+      <tt>#{sshDirectory sshdata}</tt> directory.
+    <p>
+      Do you want to merge this repository's contents into your repository?
+    <p>
+      <a .btn .btn-default onclick="$('#setupmodal').modal('show');" href="@{CombineSshR sshdata}">
+        <span .glyphicon .glyphicon-resize-small>
+        \ Combine the repositories #
+      The combined repositories will sync and share their files.
+    <p>
+    <p>
+      <a .btn .btn-default href="@{AddSshR}">
+        <span .glyphicon .glyphicon-resize-full>
+        \ Go back #
+      Use a different directory than <tt>#{sshDirectory sshdata}</tt> to #
+      avoid combining the repositories.
+^{sshSetupModal sshdata}
diff --git a/templates/configurators/ssh/confirm.hamlet b/templates/configurators/ssh/confirm.hamlet
new file mode 100644
index 0000000000..04d5e0b3e0
--- /dev/null
+++ b/templates/configurators/ssh/confirm.hamlet
@@ -0,0 +1,74 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Ready to add remote server
+    <div .row>
+      <div .col-sm-9>
+        $if not (hasCapability sshdata GitAnnexShellCapable)
+          <p>
+            <span .glyphicon .glyphicon-warning-sign>
+            \ The server #{sshHostName sshdata} can be used as is, but #
+            installing #
+            $if not (hasCapability sshdata GitCapable)
+              git and git-annex #
+            $else
+              git-annex #
+            on it would make it work better, and provide more options below. #
+          <p>
+            If you're able to install software on the server, do so and click
+            <a .btn .btn-default href="@{RetrySshR sshdata}" onclick="$('#testmodal').modal('show');">
+              Retry
+        $else
+          <p>
+            The server #{sshHostName sshdata} has been verified to be usable. #
+            Depending on whether you trust this server, you can choose between #
+            storing your data on it encrypted, or unencrypted.
+          <h3>
+            Unencrypted repository
+          <p>
+            All your data will be uploaded to the server, including a clone of #
+            the git repository. This is a good choice if you want to set up #
+            other devices to use the same server, or share the repository with #
+            others.
+          <p>
+            <a .btn .btn-default href="@{MakeSshGitR sshdata}" onclick="$('#setupmodal').modal('show');">
+              Make an unencrypted git repository on the server
+          <p style="text-align: center">
+            -or-
+        $if hasCapability sshdata RsyncCapable
+          <h3>
+            Simple shared encryption
+          <p>
+            This allows everyone who has a clone of this repository to #
+            decrypt the files stored on #{sshHostName sshdata}. That makes #
+            it good for sharing. And it's easy to set up and use.
+          <p>
+            <a .btn .btn-default href="@{MakeSshRsyncR sshdata}" onclick="$('#setupmodal').modal('show');">
+              <span .glyphicon .glyphicon-lock>
+              \ Use shared encryption
+          <p style="text-align: center">
+            -or-
+        $if hasCapability sshdata GitCapable
+          <h3>
+            Encrypt with GnuPG key
+          <p>
+            This stores an encrypted clone of your repository on #
+            #{sshHostName sshdata}, unlike shared encryption which only #
+            stores file contents there. So it's good for backups. But the #
+            encryption will prevent you from sharing the repository with #
+            friends, or easily accessing its contents on another computer.
+          <p>
+            $forall (keyid, name) <- secretkeys
+              <p>
+                <a .btn .btn-default href="@{MakeSshGCryptR sshdata (RepoKey keyid)}" onclick="$('#setupmodal').modal('show');" >
+                  <span .glyphicon .glyphicon-lock>
+                  \ Encrypt repository #
+                to ^{gpgKeyDisplay keyid (Just name)}
+          <p>
+            <a .btn .btn-default href="@{MakeSshGCryptR sshdata NoRepoKey}" onclick="$('#genkeymodal').modal('show');">
+              <span .glyphicon .glyphicon-plus-sign>
+              \ Encrypt repository #
+            with a new encryption key
+^{sshTestModal}
+^{sshSetupModal sshdata}
+^{genKeyModal}
diff --git a/templates/configurators/ssh/enable.hamlet b/templates/configurators/ssh/enable.hamlet
new file mode 100644
index 0000000000..c3edee3008
--- /dev/null
+++ b/templates/configurators/ssh/enable.hamlet
@@ -0,0 +1,28 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Enabling #{description}
+    <p>
+      <form method="post" .form-horizontal enctype=#{enctype}>
+        <fieldset>
+          $case status
+            $of UnusableServer msg
+              <div .alert .alert-danger>
+                <span .glyphicon .glyphicon-warning-sign>
+                \ #{msg}
+            $of _
+          ^{form}
+          ^{webAppFormAuthToken}
+          <div .form-group>
+            <div .col-sm-10 .col-sm-offset-2>
+              <button .btn .btn-primary type=submit onclick="$('#testmodal').modal('show');">
+                Check this server
+<div .modal .fade #testmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Testing server ...
+      <div .modal-body>
+        <p>
+          Checking ssh connection to the server. This could take a minute.
diff --git a/templates/configurators/ssh/error.hamlet b/templates/configurators/ssh/error.hamlet
new file mode 100644
index 0000000000..9be9852583
--- /dev/null
+++ b/templates/configurators/ssh/error.hamlet
@@ -0,0 +1,13 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      <span .glyphicon .glyphicon-warning-sign>
+      \ Failed to make repository
+    <p>
+      Something went wrong setting up the repository on the remote server.
+    <p>
+      Transcript:
+      <pre>
+        #{msg}
+    <p>
+      To retry setting up the repository, reload this page.
diff --git a/templates/configurators/ssh/expiredpassword.hamlet b/templates/configurators/ssh/expiredpassword.hamlet
new file mode 100644
index 0000000000..f3c1cd0330
--- /dev/null
+++ b/templates/configurators/ssh/expiredpassword.hamlet
@@ -0,0 +1,12 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      <span .glyphicon .glyphicon-warning-sign>
+      \ Failed to make repository
+    <p>
+      The password you entered has expired. Suggest you go back, #
+      re-enter the password, and try again.
+    <p>
+      Transcript:
+      <pre>
+        #{msg}
diff --git a/templates/configurators/ssh/setupmodal.hamlet b/templates/configurators/ssh/setupmodal.hamlet
new file mode 100644
index 0000000000..26506ec1ee
--- /dev/null
+++ b/templates/configurators/ssh/setupmodal.hamlet
@@ -0,0 +1,13 @@
+<div .modal .fade #setupmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Setting up repository ...
+      <div .modal-body>
+        <p>
+          Setting up repository on the remote server. This could take a minute.
+        $if needsPubKey sshdata
+          <p>
+            A ssh key is being installed on the server, allowing git-annex #
+            to access it securely without a password.
diff --git a/templates/configurators/ssh/testmodal.hamlet b/templates/configurators/ssh/testmodal.hamlet
new file mode 100644
index 0000000000..94a4ecf400
--- /dev/null
+++ b/templates/configurators/ssh/testmodal.hamlet
@@ -0,0 +1,9 @@
+<div .modal .fade #testmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Testing server ...
+      <div .modal-body>
+        <p>
+          Checking ssh connection to the server. This could take a minute.
diff --git a/templates/configurators/unused.hamlet b/templates/configurators/unused.hamlet
new file mode 100644
index 0000000000..a6f7c85fc2
--- /dev/null
+++ b/templates/configurators/unused.hamlet
@@ -0,0 +1,42 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Managing unused files
+    <p>
+      $maybe desc <- munuseddesc
+        Some old versions of files and deleted files have been preserved #
+        inside this repository.
+        <div .alert .alert-info>
+          <span .glyphicon .glyphicon-info-sign>
+          \ #{renderTense Past desc} #
+          $maybe lastchecked <- mlastchecked
+            (last checked #{fromDuration lastchecked} ago)
+      $nothing
+        Old versions of files and deleted files can be preserved inside #
+        this repository.
+    <p>
+      This might be useful, if you ever need to access those old or deleted #
+      files. But they'll also use up disk space. There are three ways to deal #
+      with this.
+    <ol>
+      <li>
+        <p>
+          Set up a backup or archive repository, on a removable drive #
+          or in the cloud, and the unused files will be moved to it, freeing #
+          up space.
+          <br>
+          <a .btn .btn-default href="@{AddRepositoryR}">
+            <span .glyphicon .glyphicon-plus>
+            \ Add a new repository
+      <li>
+        <p>
+          Or, you can let unused files expire after a period of time.
+          <form method="post" .form-inline enctype=#{enctype}>
+            ^{form}
+      <li>
+        <p>
+          Finally, you can clean up all unused files manually at any time.
+          <br>
+          <a .btn .btn-default href="@{CleanupUnusedR}">
+            <span .glyphicon .glyphicon-trash>
+            \ Clean up unused files now
diff --git a/templates/configurators/unused/form.hamlet b/templates/configurators/unused/form.hamlet
new file mode 100644
index 0000000000..081b667276
--- /dev/null
+++ b/templates/configurators/unused/form.hamlet
@@ -0,0 +1,6 @@
+#{msg}
+<p>
+  <div .form-group>
+    ^{fvInput enableView} after ^{fvInput whenView} days.&nbsp;
+    <button type=submit .btn .btn-default >
+      Save Changes
diff --git a/templates/control/log.hamlet b/templates/control/log.hamlet
new file mode 100644
index 0000000000..476c7f3390
--- /dev/null
+++ b/templates/control/log.hamlet
@@ -0,0 +1,7 @@
+<div .col-sm-9>
+  <div .content-box>
+    <p>
+      Here's everything that has been logged by the git-annex assistant, #
+      as well as by programs it has run.
+    <pre>
+      #{logcontent}
diff --git a/templates/control/notrunning.hamlet b/templates/control/notrunning.hamlet
new file mode 100644
index 0000000000..6bcb5b5a4b
--- /dev/null
+++ b/templates/control/notrunning.hamlet
@@ -0,0 +1,13 @@
+<div .col-sm-9>
+  <div .content-box>
+    <p>
+      Bye bye!
+<div .modal .fade #shutdownmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          git-annex has shut down
+      <div .modal-body>
+        <p>
+          You can now close this browser window.
diff --git a/templates/control/notrunning.julius b/templates/control/notrunning.julius
new file mode 100644
index 0000000000..7a6859f219
--- /dev/null
+++ b/templates/control/notrunning.julius
@@ -0,0 +1,3 @@
+$(function() {
+	$('#shutdownmodal').modal('show');
+});
diff --git a/templates/control/repairrepository.hamlet b/templates/control/repairrepository.hamlet
new file mode 100644
index 0000000000..0da44decfe
--- /dev/null
+++ b/templates/control/repairrepository.hamlet
@@ -0,0 +1,29 @@
+<div .col-sm-9>
+  <div .content-box>
+    <p>
+      A #
+      <a href="@{ConfigFsckR}">
+        consistency check #
+      found corrupt data in the git repository #{repodesc}.
+    <p>
+      While this is not good, this problem can be automatically repaired,
+      often without data loss.
+    $if repairingmainrepo
+      <p>
+        When possible, the corrupt data will be recovered from other #
+        repositories. You should make sure any other repositories that might #
+        have this data are available before continuing. So, plug in any #
+        removable drive that contains a repository, or make sure your network #
+        connection to other repositories is active.
+    <p>
+      <a .btn .btn-primary href="@{RepairRepositoryRunR u}" onclick="$('#workingmodal').modal('show');">
+        Start Repair Process
+<div .modal .fade #workingmodal>
+  <div .modal-dialog>
+    <div .modal-content>
+      <div .modal-header>
+        <h3>
+          Repairing #{repodesc} ...
+      <div .modal-body>
+        <p>
+          This may take some time.
diff --git a/templates/control/repairrepository/done.hamlet b/templates/control/repairrepository/done.hamlet
new file mode 100644
index 0000000000..7994121a3b
--- /dev/null
+++ b/templates/control/repairrepository/done.hamlet
@@ -0,0 +1,14 @@
+<div .col-sm-9>
+  <div .content-box>
+    <p>
+      Good news: Your repository has successfully been repaired!
+    <p>
+      This problem could have had a variety of causes. If your computer #
+      lost power, or the drive containing this repository #
+      was disconnected, it would explain this type of problem.
+    <p>
+      On the other hand, it's possible that you have a hardware problem.
+    <p>
+      Remember: Lots of copies keep stuff safe! The more repositories you #
+      have, the less likely you are to lose data no matter what goes wrong.
+    ^{repolist}
diff --git a/templates/control/repositoryswitcher.hamlet b/templates/control/repositoryswitcher.hamlet
new file mode 100644
index 0000000000..0d43f08173
--- /dev/null
+++ b/templates/control/repositoryswitcher.hamlet
@@ -0,0 +1,15 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Switch repository
+    <p>
+      $if null repolist
+        There are no other local repositories. Want to #
+        <a href="@{NewRepositoryR}">add one</a>?
+      $else
+        You can switch to any of these other local repositories:
+        <ul>
+          $forall (name, path) <- repolist
+            <li>
+              <a href="@{SwitchToRepositoryR path}">
+                #{name}
diff --git a/templates/control/shutdown.hamlet b/templates/control/shutdown.hamlet
new file mode 100644
index 0000000000..012582bbcb
--- /dev/null
+++ b/templates/control/shutdown.hamlet
@@ -0,0 +1,10 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Shutdown daemon?
+    <p>
+      <a .btn .btn-danger href="@{ShutdownConfirmedR}">
+        <span .glyphicon .glyphicon-off>
+        \ Confirm shutdown
+      <a .btn .btn-default href="@{DashboardR}">
+        Keep running
diff --git a/templates/controlmenu.hamlet b/templates/controlmenu.hamlet
new file mode 100644
index 0000000000..79dcbd100e
--- /dev/null
+++ b/templates/controlmenu.hamlet
@@ -0,0 +1,22 @@
+<ul .dropdown-menu>
+  <li>
+    <a href="@{NewRepositoryR}">
+      <span .glyphicon .glyphicon-plus-sign>
+      \ Add another local repository
+  <li>
+    <a href="@{RepositorySwitcherR}">
+      <span .glyphicon .glyphicon-folder-close>
+      \ Switch repository
+  <li>&nbsp;</li>
+  <li>
+    <a href="@{RestartR}">
+      <span .glyphicon .glyphicon-repeat>
+      \ Restart daemon
+  <li>
+    <a href="@{ShutdownR}">
+      <span .glyphicon .glyphicon-off>
+      \ Shutdown daemon
+  <li>
+    <a href="@{LogR}">
+      <span .glyphicon .glyphicon-list>
+      \ View log
diff --git a/templates/dashboard/main.hamlet b/templates/dashboard/main.hamlet
new file mode 100644
index 0000000000..cdefc82440
--- /dev/null
+++ b/templates/dashboard/main.hamlet
@@ -0,0 +1,11 @@
+<div .col-sm-9>
+  ^{repolist}
+  ^{transferlist}
+$if warnNoScript
+  <noscript>
+    <div .navbar .navbar-inverse .navbar-fixed-bottom>
+      <div .container>
+        Javascript is disabled; cannot update in real-time.
+        <div .btn-group>
+          <a .btn .btn-primary href="@{NoScriptAutoR}">Auto-refresh every 3 seconds #
+          <a .btn .btn-primary href="@{NoScriptR}">Manually refresh
diff --git a/templates/dashboard/metarefresh.hamlet b/templates/dashboard/metarefresh.hamlet
new file mode 100644
index 0000000000..89a2e0b2c6
--- /dev/null
+++ b/templates/dashboard/metarefresh.hamlet
@@ -0,0 +1,2 @@
+<noscript>
+  <meta http-equiv="refresh" content="#{show delayseconds}; URL=@{this}">
diff --git a/templates/dashboard/transfers.cassius b/templates/dashboard/transfers.cassius
new file mode 100644
index 0000000000..ae574a35c8
--- /dev/null
+++ b/templates/dashboard/transfers.cassius
@@ -0,0 +1,8 @@
+.forcewrap
+  word-wrap: break-word
+.small-margin-bottom
+  margin-bottom: 10px
+.small-margin-top
+  margin-top: 10px
+.tiny-margin-bottom
+  margin-bottom: 4px
\ No newline at end of file
diff --git a/templates/dashboard/transfers.hamlet b/templates/dashboard/transfers.hamlet
new file mode 100644
index 0000000000..c1b3e15eef
--- /dev/null
+++ b/templates/dashboard/transfers.hamlet
@@ -0,0 +1,40 @@
+<div ##{ident}>
+  <h2>Transfers
+  $if transfersrunning
+    $forall (transfer, info) <- transfers
+      $with percent <- maybe "unknown" (showPercentage 0) $ percentComplete transfer info
+        <div .row>
+          <div .col-sm-10>
+            <h3 .forcewrap .small-margin-top .tiny-margin-bottom>
+              #{desc transfer info}
+              $case transferDirection transfer
+                $of Upload
+                  &rarr;
+                $of Download
+                  &larr;
+              <small>
+                <a href="@{EditRepositoryR $ RepoUUID $ transferUUID transfer}">
+                  #{maybe "unknown" Remote.name $ transferRemote info}
+                $with size <- maybe "unknown" (roughSize dataUnits True) $ keySize $ transferKeyData transfer
+                  $if isJust $ startedTime info
+                    $if isrunning info
+                      <span .pull-right><b>#{percent} of #{size}</b>
+                    $else
+                      <span .pull-right>paused at #{percent} of #{size}
+                  $else
+                      <span .pull-right>queued (#{size})
+            <div .progress .progress-striped .small-margin-bottom>
+              <div .progress-bar style="width: #{percent};">
+          <div .btn-group .col-sm-2 .small-margin-top>
+            $if isrunning info
+              ^{actionButton (PauseTransferR transfer) Nothing (Just "pause") "btn btn-default btn-sm" "glyphicon-pause"}
+            $else
+              ^{actionButton (StartTransferR transfer) Nothing (Just "continue") "btn btn-default btn-sm" "glyphicon-play"}
+            ^{actionButton (CancelTransferR transfer) Nothing (Just "cancel") "btn btn-default btn-sm" "glyphicon-remove"}
+  $if scanrunning
+    <img src="@{StaticR activityicon_gif}" alt=""> #
+    Scanning for files to transfer
+  $else
+    $if (not transfersrunning)
+      <i>
+        (No file transfers running)
diff --git a/templates/documentation/about.hamlet b/templates/documentation/about.hamlet
new file mode 100644
index 0000000000..0379037697
--- /dev/null
+++ b/templates/documentation/about.hamlet
@@ -0,0 +1,35 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      git-annex watches over your files
+    <p>
+      It will automatically notice changes, and keep files in sync between #
+      here and repositories elsewhere.
+    <p>
+      For full details, see #
+      <a href="http://git-annex.branchable.com/">the git-annex website</a>.
+    <hr>
+      git-annex is © 2010-2017 Joey Hess. It is free software, licensed #
+      under the terms of the GNU General Public License, version 3 or above. #
+      This webapp is licensed under the terms of the GNU Affero General #
+      Public License, version 3 or above. #
+      For full license information, see #
+      $if builtinlicense
+        <a href="@{LicenseR}">
+          this page.
+      $else
+        <a href="http://git-annex.branchable.com/license">
+          this page.
+      <p>
+      The source code for git-annex can be downloaded #
+      <a href="http://source.git-annex.branchable.com/">here</a>.
+      <p>
+      Development of git-annex is made possible by #
+      <a href="http://git-annex.branchable.com/assistant/thanks/">
+        many excellent people
+      . &hearts;
+      <p>
+      Version: #{packageversion}
+      <br>
+      Build flags: #{unwords buildFlags}
+      Dependency versions: #{unwords dependencyVersions}
diff --git a/templates/documentation/license.hamlet b/templates/documentation/license.hamlet
new file mode 100644
index 0000000000..2b12b97bdc
--- /dev/null
+++ b/templates/documentation/license.hamlet
@@ -0,0 +1,2 @@
+<pre>
+  #{license}
diff --git a/templates/documentation/repogroup.hamlet b/templates/documentation/repogroup.hamlet
new file mode 100644
index 0000000000..85b62c960e
--- /dev/null
+++ b/templates/documentation/repogroup.hamlet
@@ -0,0 +1,61 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      Repository groups
+    <p>
+      Each repository you configure git-annex to use is a member of a #
+      repository group. Each group of repositories has a different #
+      purpose.
+    <p>
+      Let's start with the <b>client repositories</b>. These are the #
+      repositories that contain files that you can directly use. Generally #
+      you'll have one client repository per computer. The whole point of #
+      the git-annex assistant is to keep these repositories in sync as you #
+      change files, add files, delete files, etc.
+    <p>
+      The next most important repository group is the #
+      <b>transfer repositories</b>. #
+      These are used to transfer files between clients, when the clients #
+      cannot directly talk to one-another. Transfer repositories only #
+      hold the files that need to be synced to other repositories, so they #
+      are relatively small.
+    <p>
+      You can get along without any <b>full backup repositories</b>, but #
+      they're a useful safeguard. These repositories accumulate every file
+      they can get ahold of. A large removable drive makes a good full backup #
+      repository.
+    <p>
+      Similarly, the <b>incremental backup repositories</b> try to back up #
+      every file, but these only accumulate files that are not already #
+      present in a full or incremental backup.
+    <p>
+      Next we come to the <b>archive repositories</b>.
+      The archive repositories coordinate together, so that each file is #
+      archived in only one place. When you move files into a folder named #
+      "archive", the content of the files will be removed from all your #
+      client repositories (either immediately or as soon as an archive #
+      repository gets a copy of the file). This is handy if you have old files #
+      you don't need anymore, but want to keep archived for later. #
+      When you copy or move a file out of an "archive" folder, it'll be #
+      retrieved from the archive repository.
+    <p>
+      The <b>small archive repositories</b> are like other archive #
+      repositories, but smaller. While archive repositories normally accumulate #
+      every file they can, small archive repositories only accumulate files #
+      after you've put them in an "archive" directory. They otherwise behave #
+      the same
+    <p>
+      Sometimes useful for devices like cameras are the #
+      <b>source repositories</b>. Repositories in this group only retain #
+      files until they can be moved to some other repository, like a client #
+      or transfer repository.
+    <p>
+      If you configure a repository that can be viewed by the public, #
+      but you don't want all your files to show up there, you can #
+      configure it to be a <b>public repository</b>. Then only files #
+      located in a directory you choose will be sent to it.
+    <p>
+      Finally, repositories can be configured to be in <b>manual mode</b>. This #
+      prevents content being automatically synced to the repository, but #
+      you can use command-line tools like `git annex get` and `git annex drop` #
+      to control what content is present.
diff --git a/templates/error.cassius b/templates/error.cassius
new file mode 100644
index 0000000000..e05a73e7a1
--- /dev/null
+++ b/templates/error.cassius
@@ -0,0 +1,3 @@
+body
+  padding-top: 60px
+  padding-bottom: 40px
diff --git a/templates/error.hamlet b/templates/error.hamlet
new file mode 100644
index 0000000000..2253151d43
--- /dev/null
+++ b/templates/error.hamlet
@@ -0,0 +1,31 @@
+<div .navbar .navbar-inverse .navbar-fixed-top>
+  <div .container>
+    <div .navbar-header>
+      <button type="button" .navbar-toggle data-toggle="collapse" data-target=".navbar-collapse">
+        <span .sr-only>Toggle navigation
+        <span .icon-bar>
+        <span .icon-bar>
+        <span .icon-bar>
+      <a .navbar-brand>
+        git-annex
+    <div .navbar-collapse .collapse>
+      <ul .nav .navbar-nav>
+        <li .active>
+          <a href="">
+            Error
+        <li>
+          <a href="" onclick="history.back(-1);return false">
+            Go Back
+        <li>
+          <a href="@{LogR}">
+            View logs
+        <li>
+          <a href="http://git-annex.branchable.com/bugs/">
+            File a Bug
+<div .container-fluid>
+  <div .row>
+    <div .col-sm-6 .col-sm-offset-3>
+      <div .alert .alert-danger .alert-block>
+        ^{content}
+      <hr>
+      git-annex version #{packageversion}
diff --git a/templates/notifications/longpolling.julius b/templates/notifications/longpolling.julius
new file mode 100644
index 0000000000..4b3acc9f56
--- /dev/null
+++ b/templates/notifications/longpolling.julius
@@ -0,0 +1,11 @@
+$(function() {
+	$.get("@{geturl}", function(url){
+		var f = function() {
+			longpoll_div(url, #{ident}
+				, function() { setTimeout(f, #{delay}); }
+				, function() { window.location.reload(true); }
+			);	
+		};
+		setTimeout(f, #{startdelay});
+	});
+});
diff --git a/templates/page.cassius b/templates/page.cassius
new file mode 100644
index 0000000000..d5cd22bedf
--- /dev/null
+++ b/templates/page.cassius
@@ -0,0 +1,34 @@
+body
+  padding-top: 60px
+  padding-bottom: 40px
+.sidebar-nav
+  padding: 9px 0
+.icon-white
+  color: #FFF
+.navbar-inverse .navbar-brand:hover, .navbar-inverse .navbar-brand:focus
+  color: #999
+.form-horizontal .form-control
+  max-width: 300px
+  display: inline
+.form-horizontal input.form-control+span
+  width: 100%
+.content-box
+  padding: 30px
+  padding-top: 10px
+  margin-bottom: 30px
+  color: inherit
+  background-color: #eee
+  border-radius: 6px
+  
+h1
+  font-size: 30px
+h2
+  font-size: 24px
+h3
+  font-size: 18px
+h4
+  font-size: 14px
+h5
+  font-size: 12px
+h6
+  font-size: 11px
\ No newline at end of file
diff --git a/templates/page.hamlet b/templates/page.hamlet
new file mode 100644
index 0000000000..ac1c4f0989
--- /dev/null
+++ b/templates/page.hamlet
@@ -0,0 +1,29 @@
+<div .navbar .navbar-inverse .navbar-fixed-top role="navigation">
+  <div .container>
+    <div .navbar-header>
+      <button type="button" .navbar-toggle data-toggle="collapse" data-target=".navbar-collapse">
+        <span .sr-only>Toggle navigation
+        <span .icon-bar>
+        <span .icon-bar>
+        <span .icon-bar>
+      <a .navbar-brand>
+        git-annex
+    <div .navbar-collapse .collapse>
+      <ul .nav .navbar-nav>
+        $forall (name, route, isactive) <- navbar
+          <li :isactive:.active>
+            <a href="@{route}">
+              #{name}
+      $maybe reldir <- relDir webapp
+        <ul .nav .navbar-nav .navbar-right>
+          <li>
+            ^{actionButton FileBrowserR (Just "Files") (Just "Click to open a file browser") "" "glyphicon-folder-open icon-white"}
+          <li .dropdown #menu1>
+            <a .dropdown-toggle data-toggle="dropdown" href="#menu1">
+              Repository: #{reldir}
+              <b .caret>
+            ^{controlMenu}
+      $nothing
+<div .container-fluid>
+  <div .row>
+    ^{content}
diff --git a/templates/page.julius b/templates/page.julius
new file mode 100644
index 0000000000..dccde0c36f
--- /dev/null
+++ b/templates/page.julius
@@ -0,0 +1,22 @@
+$(function() {
+	$.get("@{NotifierGlobalRedirR}", function(url){
+		var f = function() {
+			longpoll_data(url,
+				function(ok, redirurl) {
+					if (ok) {
+						if (redirurl) {
+							window.location = redirurl;
+						}
+						else {
+							setTimeout(f, 10);
+						}
+					}
+					else {
+						setTimeout(f, 5000);
+					}
+				}
+			);
+		};
+		setTimeout(f, 500);
+	});
+});
diff --git a/templates/repolist.hamlet b/templates/repolist.hamlet
new file mode 100644
index 0000000000..77dbbfaeda
--- /dev/null
+++ b/templates/repolist.hamlet
@@ -0,0 +1,84 @@
+<div ##{ident}>
+  $if onlyCloud reposelector
+    $if not (null repolist)
+      <h2>
+        Cloud repositories
+    $else
+      No cloud repositories are configured yet.
+  $else
+    $if not (null repolist)
+      <h2>
+        Repositories
+  <table .table .table-condensed>
+    <tbody #costsortable>
+      $forall (name, repoid, currentlyconnected, actions) <- repolist
+        <tr .repoline ##{show repoid}>
+          <td .handle>
+            <a .btn .btn-default .btn-xs .disabled>
+              <span .glyphicon .glyphicon-resize-vertical>
+            &nbsp; #{name}
+          <td .draghide>
+            $if needsEnabled actions
+              <a href="@{setupRepoLink actions}">
+                <span .glyphicon .glyphicon-warning-sign>
+                \ not enabled
+            $else
+              $if notWanted actions
+                <span .glyphicon .glyphicon-trash>
+                \ cleaning out..
+              $else
+                <a href="@{syncToggleLink actions}">
+                  $if currentlyconnected
+                    <span title="connected; change notification enabled" .glyphicon .glyphicon-signal>
+                  $else
+                    $if notSyncing actions
+                      <span .glyphicon .glyphicon-ban-circle>
+                    $else
+                      <span .glyphicon .glyphicon-refresh>
+                  $if notSyncing actions
+                    \ syncing disabled
+                  $else
+                    \ syncing enabled #
+                      $if lacksUUID repoid
+                        (metadata only)
+          <td .draghide>
+            $if needsEnabled actions
+              <a href="@{setupRepoLink actions}">
+                enable
+            $else
+              <div .dropdown #menu-#{show repoid}>
+                <a data-toggle="dropdown" data-target="#" href="#menu-#{show repoid}">
+                  <span .glyphicon .glyphicon-cog>
+                  \ actions #
+                  <span .caret>
+                <ul .dropdown-menu>
+                  <li>
+                    <a href="@{setupRepoLink actions}">
+                      <span .glyphicon .glyphicon-pencil>
+                      \ Edit
+                    $if not (lacksUUID repoid)
+                      <a href="@{SyncNowRepositoryR $ asUUID repoid}">
+                        <span .glyphicon .glyphicon-refresh>
+                        \ Sync now
+                    $if notSyncing actions
+                      <a title="Not allowed when syncing is disabled." href="#" style="color: #999;">
+                        <span .glyphicon .glyphicon-trash>
+                        \ Delete
+                    $else
+                      <a href="@{DeleteRepositoryR $ asUUID repoid}">
+                        <span .glyphicon .glyphicon-trash>
+                        \ Delete
+      $if addmore
+        <tr>
+          <td colspan="3">
+            $if nootherrepos
+              <a .btn .btn-primary .btn-lg href="@{AddRepositoryR}">
+                <span .glyphicon .glyphicon-plus-sign>
+                \ Add another repository
+            $else
+              <a .btn .btn-default .btn-sm href="@{AddRepositoryR}">
+                <span .glyphicon .glyphicon-plus-sign>
+                \ Add another repository
+            <span>
+              &nbsp; Sync your files with another device, or #
+              share with a friend.
diff --git a/templates/repolist.julius b/templates/repolist.julius
new file mode 100644
index 0000000000..c5c3cfd461
--- /dev/null
+++ b/templates/repolist.julius
@@ -0,0 +1,28 @@
+$(function() {
+	var setup = function() {
+		$("#costsortable").sortable({
+			items: ".repoline",
+			handle: ".handle",
+			cursor: "move",
+			forceHelperSize: true,
+			start: function(event, ui) {
+				ui.item.children(".draghide").hide();
+			},
+			stop: function(event, ui) {
+				ui.item.children(".draghide").show();
+				var list = $("#costsortable").sortable("toArray");
+				var moved = ui.item.attr("id");
+				$.ajax({
+					'url': "@{RepositoriesReorderR}",
+					'data': {
+						'moved': moved,
+						'list': list
+					}
+				});
+			},
+		});
+	};
+	longpollcallbacks.add(setup);
+	setup();
+
+});
diff --git a/templates/sidebar/alert.hamlet b/templates/sidebar/alert.hamlet
new file mode 100644
index 0000000000..6b1b66e5f5
--- /dev/null
+++ b/templates/sidebar/alert.hamlet
@@ -0,0 +1,27 @@
+<div .alert .fade .in .#{divclass} :block:.alert-block ##{alertid}>
+  $if closable
+    <a .close onclick="(function( $ ) { $.get('@{CloseAlert aid}') })( jQuery );">&times;</a>
+  $maybe h <- renderAlertHeader alert
+    $if block
+      <h4 .alert-heading>
+        $maybe i <- alertIcon alert
+          ^{htmlIcon i} #
+        #{h}
+    $else
+      $maybe i <- alertIcon alert
+        ^{htmlIcon i} #
+      <strong>#{h}
+      \ 
+  $nothing
+    $maybe i <- alertIcon alert
+      ^{htmlIcon i} #
+  $if multiline
+    $forall l <- messagelines
+      #{l}<br>
+  $else
+    #{message}
+  $if not (null buttons)
+    <br>
+    $forall (button, bnum) <- buttons
+      <a .btn :buttonPrimary button:.btn-primary :not (buttonPrimary button):.btn-success href="@{ClickAlert aid bnum}">
+        #{buttonLabel button}
diff --git a/templates/sidebar/main.hamlet b/templates/sidebar/main.hamlet
new file mode 100644
index 0000000000..da4cd0d2cd
--- /dev/null
+++ b/templates/sidebar/main.hamlet
@@ -0,0 +1,3 @@
+<div .col-sm-3 ##{ident}>
+  <div .sidebar-nav>
+    ^{content}
-- 
2.30.2